oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-lotto/DYGames/34-2/353/213/250/352/263/204-/353/241/234/353/230/220.md

@@ -0,0 +1,88 @@
+# PR #34 — [코건] 2단계 로또
+
+- **Reviewee:** [@DYGames](https://github.com/DYGames)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/34
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 54
+
+## 못한 점 (설계 관점)
+
+### 1. 수동 티켓 생성을 World(Controller)에서
+
+```kotlin
+class World {
+    fun run() {
+        val manualLottos = manualNumbers.map { Lotto(it) }  // ⚠ Controller가 생성
+    }
+}
+```
+
+> 수동 티켓을 만들어주는 것 또한 도메인 로직입니다. 역할을 맡길 적절한 객체를 찾아볼까요?
+
+### 2. `LottoCount`가 PurchaseMoney의 값 꺼내 계산
+
+```kotlin
+class LottoCount(.) {
+    fun from(money: PurchaseMoney): LottoCount {
+        val count = money.value / LOTTO_PRICE  // ⚠ Money 내부 꺼내기
+        return LottoCount(count)
+    }
+}
+```
+
+> 결국 purchaseMoney의 값을 꺼내서 계산하고 있어요. 메시지를 던져서 LottoCount를 반환하게 만드는 것은 어떨까요?
+
+→ `purchaseMoney.numberOfLottos(): LottoCount` 메시지.
+
+### 3. `PurchasedLottos` 합치기 — `+` operator 미활용
+
+```kotlin
+val all = PurchasedLottos(manual.lottos + auto.lottos)
+```
+
+> 로또 끼리 합치는 로직은 `+ operator` 오버로딩 활용을 도전해보세요
+
+→ `manualLottos + autoLottos` 자연스러운 표현.
+
+### 4. `WinLotto`가 1개 비교만, 다수 결과 미수행
+
+```kotlin
+class WinLotto(.) {
+    fun match(lotto: Lotto): Rank =.  // ⚠ 1개씩
+}
+```
+
+> 1개의 로또를 비교하는 로직이 있다면, 여러 로또를 비교해서 모든 결과를 반환하는 역할도 담당해보는 것은 어떨까요?
+
+→ `winLotto.matchAll(lottos: List<Lotto>): Map<Rank, Int>` 한 호출.
+
+### 5. 등수 찾기를 외부에서
+
+```kotlin
+fun match(lotto: Lotto): Rank {
+    val count =.
+    return Rank.of(count, hasBonus)  // ⚠ 외부에서 호출
+}
+```
+
+> 등수를 찾는 것은 Rank에게 위임해보는 것은 어떨까요?
+
+### 6. LottoMachine이 수동 티켓 보유
+
+```kotlin
+class LottoMachine(val manualNumbers: List<List<Int>>) {
+    fun generate(.): List<Lotto> =.
+}
+```
+
+> 로또를 발급하는 기계가 수동 티켓을 미리 가지고 있어야 할까요? 또, 이 객체는 1번 생성되면 다시 재활용하기 어려워 보입니다.
+
+→ 기계는 *생성 정책*만, *수동 번호*는 호출 인자.
+
+## 얻은 교훈
+
+- **`+` operator 오버로딩** — 컬렉션 합치기를 도메인 어휘로. `manualLottos + autoLottos`.
+- **단일 vs 다수 메서드 — 다수가 더 자연스러울 때 다수만 노출**. `matchAll`로 한 호출에 모든 결과.
+- ***등수 찾기*는 Rank.of()로 위임** — Rank가 자기 인스턴스화 정책 소유.
+- **기계의 재활용성** — 한 번 만들면 영속적으로 사용 가능해야. 생성자에 *상태*를 받지 말고 *정책*만.

package/lessons/woowacourse-kotlin-lotto/EmilyCh0/12-1/353/213/250/352/263/204-/353/241/234/353/230/220.md

@@ -0,0 +1,107 @@
+# PR #12 — [해시] 1단계 로또
+
+- **Reviewee:** [@EmilyCh0](https://github.com/EmilyCh0)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/12
+- **단계:** 1단계
+- **리뷰어:** @namjackson (잭슨)
+- **라인 코멘트:** 20 (리뷰어 12 + 학생 8)
+
+## 잘한 점 (설계 관점)
+
+- **`Set` 활용** — 칭찬: "Set 👍".
+
+## 못한 점 (설계 관점)
+
+### 1. *불필요한 패키지 + 클래스명*
+
+리뷰어: "*불필요한 패키지 명과 클래스명을 제거*해 주세요!"
+
+### 2. `LottoResult` 2등/3등 *matchCount 동일*
+
+리뷰어: "*LottoResult 2등과 3등은 matchCount가 일치*하네요, *어떻게 구분할 수 있을까요? matchBonus에 대한 정보도 LottoResult에서 관리*해야 하지 않을까요?".
+
+리뷰어 후속: "*LottoResult에 보너스볼 일치 여부를 추가하게 되면, 다른 등수에서 불필요한 보너스 일치 여부 정보가 들어갈 수 있긴 한데, LottoResult valueOf 함수의 구현부를 확인하기 전에는 2~3등의 차이를 알 수 없기도* 해요! *val matchBonus: Boolean = false 보너스볼 일치 여부에 기본값을 설정*하면 불필요한 코드는 제거할 수 있기도 해요"
+```kotlin
+FIFTH(5_000, 3),
+FORTH(50_000, 4),
+THIRD(1_500_000, 5, matchBonus = false),
+SECOND(30_000_000, 5, matchBonus = true),
+```
+
+### 3. `catchNumbers`와 `Lotto` *책임 중복*
+
+리뷰어: "*catchNumbers와 Lotto는 비슷한 책임이 있는 것* 같아요!" + "*마찬가지로 보너스 번호와 로또 번호가 비슷한 책임이 있는 것* 같아요! *LottoNumber라는 클래스로 분리*해 보면 어떨까요?" — *원시값 포장 + 도메인 동일성 인식*.
+
+### 4. *리턴값 명시*
+
+리뷰어: "*리턴값을 명시해 주면 어떨까요? 구현부를 보기 전엔 무엇을 리턴할지, 구현부를 보더라도, 리턴값이 직관적이지 않기도 하고, 연산의 결과에 따라 리턴값이 달라지기도* 해요!"
+
+### 5. *예외 메시지 검증* — 다른 에러 통과 위험
+
+리뷰어: "*의도하지 않은 다른 에러로, 테스트가 통과될 수도 있을 거 같*아요! *에러 메시지까지 확인*해 보면 어떨까요?"
+
+### 6. *테스트 케이스 명세성*
+
+리뷰어: "*구체적인 테스트 케이스명을 작성*해 보면 어떨까요? *프로젝트가 커지고, 테스트 코드가 많아질수록, 테스트 케이스 명으로 관리되는 경우도* 있고, *테스트 케이스가 요구사항 명세서로 활용*되기도 해요! *'당첨 결과가 1등인 경우'라는 모호한 케이스보다, '로또 번호 6개가 일치할 경우, 결과를 확인하면, 1등이 되어야 한다'라는 케이스명*은 어떨까요?".
+
+### 7. *given/when/then*
+
+리뷰어: "*테스트 케이스 구현부의 가독성도 중요*해요! *준비, 실행, 검증을 나눠서 구현*해 보면 어떨까요?
+```kotlin
+// given
+private val testLotto = Lotto(setOf(1, 2, 3, 4, 5, 6))
+private val winningLotto = WinningNumbers(setOf(1, 2, 3, 4, 5, 6), 7)
+// when
+val actual = testLotto.getLottoResult(winningLotto)
+// then
+assertThat(actual).isEqualTo(LottoResult.FIRST)
+```
+*저는 given, when, then 표기법을 즐겨 사용*합니다!"
+
+### 8. *팩토리 함수* — Effective Kotlin
+
+리뷰어: "*팩토리 함수 형태의 함수는 자주 사용*합니다! 가볍게 읽어 보시면 좋을 거 같아요! https://kyucumber.github.io/posts/book/effective-kotlin/effective-kotlin-item-33"
+
+### 9. 학생 자가 의문 — *함수 위치 (companion vs 호출처)*
+
+학생: "*이 함수가 클래스 내부에서 사용되지는 않지만 LottoResult와 관련된 메서드라고 생각해서 해당 클래스 companion object에 작성*했는데 *valueOf() 메서드를 사용하는 Lotto 클래스에 작성*해야 할까요?"
+
+→ *함수 위치 = 호출처 + 책임*. *호출처가 다른 클래스*면 *그 클래스 메서드*로 자연.
+
+### 10. *Lotto 생성 길이* — 다음 미션 (수동)
+
+리뷰어: "*Lotto 생성 코드가 길어졌*네요! *테스트 코드 내 Lotto 생성하는 코드를 함수로 분리하거나 팩토리 메소드 패턴을 사용*해 보셔도 좋을 거 같아요! *다음 미션인 수동 로또 생성과도 연결된 포인트이니, 다음 미션 진행하면서 고민*해 보세요! 😄" — 학습 연속성.
+
+## 리뷰어 의견 요지
+
+- **불필요한 패키지/클래스명 제거**.
+- **`Rank.matchBonus` *기본값으로 노출 최소화***.
+- **도메인 중복 = *통합 후보***.
+- **리턴값 *명시***.
+- **에러 메시지 *검증 포함***.
+- **테스트 *요구사항 명세서*** — 구체적 케이스명.
+- **`given/when/then`**.
+- **팩토리 함수 *Effective Kotlin*** 참고.
+- **함수 위치 = *호출처/책임*** 일관성.
+
+- **대표 인용:**
+  > 테스트 케이스가 *요구사항 명세서로 활용*되기도 해요!
+  > — @namjackson on `src/test/kotlin/lotto/domain/LottoTest.kt`
+
+  > LottoResult valueOf 함수의 구현부를 *확인하기 전에는 2~3등의 차이를 알 수 없*기도 해요!
+  > — @namjackson on `src/main/kotlin/lotto/domain/LottoResult.kt`
+
+  > 다음 미션인 *수동 로또 생성과도 연결된 포인트이니, 다음 미션 진행하면서 고민*해 보세요!
+  > — @namjackson (학습 연속성)
+
+## 얻은 교훈
+
+- **불필요한 패키지/클래스 *제거*** — *YAGNI*.
+- **`Rank.matchBonus` *default 매개변수*** — *MISS/FIRST*에 *false noise* 제거. 패턴.
+- **도메인 중복** (`catchNumbers` ≈ `Lotto`, `BonusNumber` ≈ `LottoNumber`) = *통합 후보*. *동일 의미 = 동일 타입*.
+- **리턴값 *명시*** = *시그니처가 문서*.
+- **에러 메시지 *검증 포함*** — *원하지 않는 에러로 통과* 위험. assertj `hasMessage`.
+- **테스트 케이스명 = *요구사항 명세서*** — *프로젝트 커질수록* 명세 가치 ↑.
+- **`given/when/then`** — *3구역 분리*.
+- **팩토리 함수 *Effective Kotlin item 33*** = *생성자 대신 팩토리 5가지 이유*.
+- **함수 위치 = *호출처 + 책임 일관성*** — *companion object에 있어도 호출처가 다르면 어색*.

package/lessons/woowacourse-kotlin-lotto/EmilyCh0/40-2/353/213/250/352/263/204-/353/241/234/353/230/220.md

@@ -0,0 +1,135 @@
+# PR #40 — [해시] 2단계 로또
+
+- **Reviewee:** [@EmilyCh0](https://github.com/EmilyCh0)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/40
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @namjackson (잭슨)
+- **라인 코멘트:** 17
+
+## 잘한 점 (설계 관점)
+
+- **`LottoShop` 후속 도입** — 리뷰어 1라운드 요청에 정확히 응답: *수동 검증 + 자동 수 계산*을 한 객체로.
+- **`LottoTicket` 일급 컬렉션** — *발행 전 수동 입력*을 별도 타입.
+- **`WinningNumbers.findLottoResult` 후속** — `Lotto`가 *matchCount + hasBonus* 두 값을 받지 않고 *결과 객체*를 받음.
+- **`LottoShopTest` 추가** — 리뷰어 칭찬: "*LottoShop Test로 수동/자동 갯수를 테스트 할 수 있게 되었네요* 👍".
+
+## 못한 점 (설계 관점)
+
+### 1. Controller에 *비즈니스 로직 + View 출력* 혼재
+
+```kotlin
+private fun purchaseLottos(purchaseMoney: PurchaseMoney): PurchasedLottos {
+    val numberOfTotalLottos = purchaseMoney.money / LOTTO_PRICE  // ⚠ 비즈
+    val numberOfManualLottos = repeatWithRunCatching { getNumberOfManualLottos(numberOfTotalLottos) }
+    val manualLottos = repeatWithRunCatching { purchaseManualLottos(numberOfManualLottos) }
+    val autoLottoGenerator = LottoGenerator(numberOfLottos = numberOfTotalLottos - numberOfManualLottos)
+    val autoLottos = autoLottoGenerator.generateLottos()
+    ResultView.printPurchasedNumberOfLottos(numberOfManualLottos, numberOfTotalLottos - numberOfManualLottos)
+    return PurchasedLottos(manualLottos + autoLottos)
+}
+
+private fun getNumberOfManualLottos(maximumQuantity: Int): Int {
+    val numberOfManualLottos = InputView.requestNumberOfManualLottos()
+    require(numberOfManualLottos <= maximumQuantity) { NUMBER_OF_MANUAL_LOTTOS_ERROR }
+    require(numberOfManualLottos >= 0) { NEGATIVE_NUMBER_ERROR }
+    return numberOfManualLottos
+}
+```
+
+리뷰어: "Controller 내에서 *중요한 로직이 실행*되고 있어요! *View 관련 코드와 비즈니스 로직이 섞여*있는 거 같아요! *테스트하기도 어려운 구조*네요 ㅠㅠ! *로또를 몇 장 생성하는지 등의 여부는 다른 클래스를 생성하여 책임을 부여*해 보면 어떨까요?" + "검증 또한 Controller가 아닌 *LottoShop 같은 객체를 만들어 책임을 부여*해 보면 어떨까요?" 학생: "*LottoShop 클래스를 추가*하여 로또 생성 / 수동 로또 개수에 대한 검증 / 자동 로또 개수 구하기 역할을 수행하도록 했습니다!"
+
+### 2. `repeatWithRunCatching`을 *비입력 코드*에도 적용 — 무한루프 위험
+
+```kotlin
+val numberOfManualLottos = repeatWithRunCatching { getNumberOfManualLottos(numberOfTotalLottos) }
+val manualLottos = repeatWithRunCatching { purchaseManualLottos(numberOfManualLottos) }  // ⚠ 입력 외 코드
+```
+
+리뷰어: "repeatWithRunCatching는 *실패 시 재시도하는 함수*인데요, *입력 등의 경우가 아니라면 위험한 로직*인 거 같아요! *ManualLottos 생성 시에 문제가 있었다면, 사용자 입력과 상관없이 재귀 함수가 종료되지 않을 것*으로 보여요!" — *재시도 가능 영역*과 *결정적 영역* 구분. 학생: "*중복해서 repeatWithRunCatching하는 코드 제거*했습니다!"
+
+### 3. 함수 *리턴 타입 생략*
+
+```kotlin
+fun getMatchCount(numbers: Set<LottoNumber>) =
+.
+```
+
+리뷰어: "*리턴값을 명시적으로 작성*해 주세요! *구현부를 자세히 보지 않으면 리턴값을 파악하기가 힘들 것* 같아요!" — *공개 API* 리턴 타입은 *문서*.
+
+### 4. 테스트 케이스 *구체성 부족* — 명세서로서의 가치
+
+```kotlin
+@Test
+fun `당첨 번호가 6개인 경우`() {  // ⚠ 어떻게 동작?
+.
+}
+```
+
+리뷰어: "테스트 케이스는 *구체적으로 작성*해 주세요! *당첨 번호가 6개인 경우, 어떻게 동작해야 하는 건지는 내부 구현부를 살펴보아야 하는 구조*예요! *테스트 케이스를 하나의 프로그램 요구사항 명세서*라고 생각해 보셔도 좋을 거 같아요! 😄" 학생: "`당첨 번호가 6개인 경우 *예외가 발생하지 않고 WinningNumbers가 생성*된다`로 구체적인 테스트 케이스 작성했습니다!"
+
+### 5. `data class` vs `private constructor` 충돌 — 학생 자가 추론
+
+```kotlin
+class Lotto private constructor(val numbers: Set<LottoNumber>) {
+    override fun equals(other: Any?): Boolean {. }
+    override fun hashCode(): Int = numbers.hashCode()
+}
+```
+
+리뷰어: "data 클래스와 일반 클래스는 *어떤 차이*가 있을까요?" 학생: "*data class는 equals(), hashCode(), toString() 등의 메서드를 자동으로 구현*해 줍니다. Lotto 같은 클래스는 data class로 정의해서 자동으로 정의된 equals(), hashCode()를 사용하는 것을 좋을 것 같습니다! 다만 기존 Lotto 클래스는 *외부에서 인스턴스를 생성하지 못하도록 private constructor로 정의*했는데, *data class를 사용하면 copy()도 사용할 수 있어 외부에서 인스턴스를 생성*할 수 있게 되어 의도치 않은 문제가 생길 수 있을 것 같습니다." — *생성자 통제와 data class의 충돌*을 본인이 정리 (#49도 같은 결론).
+
+### 6. `Lotto`가 *matchCount + hasBonus* 두 값을 외부에서 받음
+
+```kotlin
+fun getLottoResult(winningNumbers: WinningNumbers): LottoResult {
+    val matchCount = winningNumbers.getMatchCount(numbers)
+    val hasBonusNumber = winningNumbers.checkMatchBonus(numbers)
+    return LottoResult.valueOf(matchCount, hasBonusNumber)
+}
+```
+
+리뷰어: "winningNumbers에서 *matchCount, hasBonusNumber를 따로 리턴하기보단, LottoResult를 리턴*하면 어떨까요?" — *클라이언트가 조립*은 *책임 분산*. 학생: "*WinningNumbers에 최종 결과 LottoResult를 리턴하는 findLottoResult()*를 추가했습니다!"
+
+### 7. `LottoShop.purchaseManualLotto(numbers: List<Int>)` — *원시 컬렉션* 인자
+
+```kotlin
+fun purchaseManualLotto(numbers: List<Int>): Lotto {. }
+```
+
+리뷰어: "*List<Int>는 무엇을 의미*하는 걸까요? *LottoTicket 같은 네이밍의 일급 컬렉션*으로 만들어 보아요!" 학생: "*LottoTicket를 추가*했고, *LottoTicket에서 숫자 개수와 중복 검증*을 합니다. Lotto 생성 시 LottoNumbers를 받아서 처리하도록 했기 때문에 Lotto에서 하던 검증은 제거했습니다!" — *검증의 거점이 LottoTicket*으로 이동.
+
+## 리뷰어 의견 요지
+
+- **Controller는 *흐름 조정*만** — 비즈니스 로직은 도메인.
+- **`LottoShop` 같은 *책임 객체*** — 수동 검증 + 자동 수 계산.
+- **`repeatWithRunCatching`은 *입력에만***. 결정적 코드 영역에 적용하면 *무한루프*.
+- **공개 함수 *리턴 타입 명시***.
+- **테스트는 *명세서*** — *어떻게 동작*하는지 케이스 제목에.
+- **`data class` vs *private constructor*** = 트레이드오프 (학생 자가 정리).
+- **클라이언트 조립 X** — `WinningNumbers.findLottoResult(lotto)`.
+- **원시 컬렉션 → 일급 컬렉션** — `List<Int>` → `LottoTicket`.
+
+- **대표 인용:**
+  > Controller내에서 *중요한 로직이 실행*되고 있어요! *View 관련 코드와 비즈니스 로직이 섞여*있는 거 같아요! *테스트하기도 어려운 구조*네요 ㅠㅠ!
+  > — @namjackson on `src/main/kotlin/controller/LottoController.kt`
+
+  > repeatWithRunCatching는 *실패 시 재시도하는 함수*인데요, 입력 등의 경우가 아니라면 *위험한 로직*인 거 같아요!
+  > — @namjackson on `src/main/kotlin/controller/LottoController.kt`
+
+  > 테스트 케이스를 *하나의 프로그램 요구사항 명세서*라고 생각해 보셔도 좋을 거 같아요!
+  > — @namjackson on `src/test/kotlin/WinningNumbersTest.kt`
+
+  > List<Int>는 무엇을 의미하는 걸까요? *LottoTicket 같은 네이밍의 일급 컬렉션*으로 만들어 보아요!
+  > — @namjackson on `src/main/kotlin/domain/model/lotto/LottoShop.kt`
+
+## 얻은 교훈
+
+- **Controller는 *얇게*** — 비즈니스 계산 + 검증은 도메인 객체에. *테스트 가능성*이 신호.
+- **재시도는 *입력 경계*에만** — *결정적 코드*에 적용하면 *무한 재귀*. `repeatWithRunCatching { generateLottos() }`은 안티.
+- **공개 함수 *리턴 타입 명시*** — *=식 함수*에서도 명시적이 *문서 + 안전*.
+- **테스트 제목 = 명세서** — `당첨 번호가 6개인 경우` X, `예외가 발생하지 않고 WinningNumbers가 생성된다` O.
+- **`data class` vs `private constructor`** — *copy 노출*이 부담이면 일반 class. (#49 써니와 동일한 결론을 학생이 *자가 추론*).
+- **`Tell, Don't Ask`** — `winningNumbers.getMatchCount(lotto.numbers)` + `winningNumbers.checkMatchBonus(lotto.numbers)` 분리 호출은 *클라이언트 조립*. `winningNumbers.findLottoResult(lotto)`가 응집.
+- **원시 컬렉션 → 일급 컬렉션** — `List<Int>`가 의미를 *호출 컨텍스트*에 두면, *어느 컨텍스트*는 자동 입력인지 수동 입력인지 모호.
+- **검증 위치 = *생성 시점*** — `LottoTicket(numbers).{ require(size==6) }`로 *Lotto 생성 전*에 거름.
+- **이전 라운드 응답을 *PR 본문*에 명시** — `LottoShop 추가했습니다` `리턴 타입 작성했습니다` 식의 *대화 흔적*이 리뷰 효율을 높임.

package/lessons/woowacourse-kotlin-lotto/HANDOVER.md

@@ -0,0 +1,217 @@
+# 다음 세션을 위한 인계 (kotlin-lotto OOP 교훈 보강)
+
+## 현재 상태 — 솔직한 보고
+
+이전 세션에서 `woowacourse/kotlin-lotto` 141개 PR을 분석한다고 시작했지만, **후반부로 갈수록 코멘트를 압축해서 읽어 부실한 파일이 다수 생겼다.**
+
+- **141개 PR 파일 작성됨** (`lessons/woowacourse-kotlin-lotto/<reviewee>/*-로또.md`)
+- **SUMMARY.md / README.md / PROGRESS.md** 작성됨
+- **MCP resources** 등록됨 (`oop://lessons/lotto/...`)
+- **메인 README** 링크 추가됨
+- 그러나 **약 51개 파일이 부실**: 실제 코멘트의 일부만 반영, 나머지는 *일반적 OOP 패턴*으로 채워짐
+- 양호한 파일은 racingcar 수준의 깊이 (kkosang/85, hyunji1203/15, krrong/19 등 초반 20-25개)
+
+## 구체적 부실도
+
+### 🔴 심각 (재작성 권장) — 18개
+
+실제 코멘트 30개 이상인데 파일이 35줄 미만. *사실상 미분석*에 가까움:
+
+```
+PR #132 | hwannow         | 58 코멘트 | 30줄 (코멘트 대비 51%)
+PR #91  | sh1mj1          | 42 코멘트 | 29줄
+PR #150 | wondroid-world  | 41 코멘트 | 30줄
+PR #129 | chanho0908      | 39 코멘트 | 20줄
+PR #92  | Hevton          | 38 코멘트 | 34줄
+PR #78  | gaeun5744       | 38 코멘트 | 34줄
+PR #127 | medAndro        | 36 코멘트 | 26줄
+PR #114 | tobae-time      | 36 코멘트 | 34줄
+PR #13  | otter66         | 35 코멘트 | 32줄
+PR #94  | kimhm0728       | 34 코멘트 | 30줄
+PR #134 | jerry8282       | 34 코멘트 | 34줄
+PR #122 | ijh1298         | 34 코멘트 | 26줄
+PR #81  | junjange        | 32 코멘트 | 31줄
+PR #133 | ijh1298         | 32 코멘트 | 26줄
+PR #116 | cucumber99      | 32 코멘트 | 28줄
+PR #58  | junjange        | 31 코멘트 | 31줄
+PR #32  | RightHennessy   | 31 코멘트 | 28줄
+PR #112 | etama123        | 31 코멘트 | 27줄
+```
+
+### 🟡 중간 (보강 권장) — 33개
+
+코멘트 15-29개, 파일 30줄 이하. *절반쯤만 반영*:
+
+```
+PR #143 | yrsel           | 27 코멘트 | 26줄
+PR #95  | haeum808        | 26 코멘트 | 25줄
+PR #63  | jinuemong       | 26 코멘트 | 28줄
+PR #51  | briandr97       | 24 코멘트 | 24줄
+PR #35  | sujin9          | 24 코멘트 | 26줄
+PR #145 | tobae-time      | 24 코멘트 | 22줄
+PR #117 | parkjiminnnn    | 24 코멘트 | 26줄
+PR #103 | s6m1n           | 23 코멘트 | 26줄
+PR #97  | chaehyuns       | 22 코멘트 | 30줄
+PR #71  | chaehyuns       | 22 코멘트 | 25줄
+PR #151 | m6z1            | 22 코멘트 | 21줄
+PR #9   | whk06061        | 21 코멘트 | 24줄
+PR #24  | chws0508        | 21 코멘트 | 28줄
+PR #70  | kmkim2689       | 20 코멘트 | 21줄
+PR #38  | rhkrwngud445    | 20 코멘트 | 30줄
+PR #152 | donghyun81      | 20 코멘트 | 28줄
+PR #98  | hxeyexn         | 19 코멘트 | 18줄
+PR #82  | kmkim2689       | 19 코멘트 | 22줄
+PR #53  | otter66         | 19 코멘트 | 17줄
+PR #52  | 2chang5         | 19 코멘트 | 30줄
+PR #61  | Junyoung-WON    | 18 코멘트 | 21줄
+PR #146 | parkjiminnnn    | 18 코멘트 | 18줄
+PR #49  | inseonyun       | 17 코멘트 | 24줄
+PR #40  | EmilyCh0        | 17 코멘트 | 18줄
+PR #25  | SeongHoonC      | 17 코멘트 | 24줄
+PR #148 | etama123        | 17 코멘트 | 20줄
+PR #36  | rhthrhrl0       | 16 코멘트 | 20줄
+PR #144 | jiyuneel        | 16 코멘트 | 30줄
+PR #80  | dpcks0509       | 15 코멘트 | 20줄
+PR #8   | ki960213        | 15 코멘트 | 28줄
+PR #77  | hxeyexn         | 15 코멘트 | 21줄
+PR #75  | sh1mj1          | 15 코멘트 | 20줄
+PR #21  | rhthrhrl0       | 15 코멘트 | 24줄
+```
+
+### 🟢 양호 (그대로 유지) — 90개
+
+코멘트 15개 미만 또는 파일이 충분히 길음.  
+양호 PR의 quality bar 참고: `kkosang/85-2단계-로또.md` (145줄), `hyunji1203/15-1단계-로또.md` (171줄), `krrong/19-1단계-로또.md` (161줄), `EmilyCh0/40-2단계-로또.md`는 부실하지만 racingcar에 있는 같은 학생의 `EmilyCh0/40-1단계-자동차-경주.md`는 양호 — 그 수준이 목표.
+
+## 캐시 위치
+
+`/tmp/oop-lessons-cache-lotto/` (재부팅 시 사라짐):
+- `prs.json` — 153개 PR 메타
+- `comments/<N>.json` — PR별 라인 코멘트 (diff_hunk 포함)
+- `grouped.tsv` — PR# / 코멘트 수 / 고유 리뷰어 / 작성자
+
+캐시 재생성 명령:
+```bash
+mkdir -p /tmp/oop-lessons-cache-lotto/comments
+gh api 'repos/woowacourse/kotlin-lotto/pulls?state=closed&per_page=100' --paginate > /tmp/oop-lessons-cache-lotto/prs.json
+for N in $(jq -r '.[].number' /tmp/oop-lessons-cache-lotto/prs.json); do
+  gh api "repos/woowacourse/kotlin-lotto/pulls/${N}/comments?per_page=100" --paginate > "/tmp/oop-lessons-cache-lotto/comments/${N}.json"
+done
+```
+
+## 다음 세션이 해야 할 일
+
+### 1. 부실 파일 보강 (또는 재작성)
+
+각 PR마다:
+
+```bash
+# 모든 코멘트를 한 번에 다 읽기 (압축 X)
+jq -r '.[] | "@\(.user.login) on `\(.path):\(.line // "?")`:\n```kotlin\n\(.diff_hunk)\n```\n\(.body)\n---"' /tmp/oop-lessons-cache-lotto/comments/<N>.json | less
+```
+
+→ **`head -10`, `body[:100]` 같은 압축 절대 X**. 전체 코멘트 다 읽고 분석.
+
+### 2. 파일 형식 (양호한 PR과 동일)
+
+```markdown
+# PR #<N> — <Title>
+
+- **Reviewee:** [@user](https://github.com/user)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/<N>
+- **단계:** N단계
+- **리뷰어:** @reviewer
+- **라인 코멘트:** <N>
+
+## 잘한 점 (설계 관점)
+- 항목 + 설명
+
+## 못한 점 (설계 관점)
+### 1. 안티패턴 이름
+```kotlin
+// 실제 diff_hunk 코드 인용
+```
+설명 — 왜 이게 문제인가.
+
+### 2. 다른 안티패턴
+...
+
+## 리뷰어 의견 요지
+1. **핵심 메시지 1** — 인용
+2. **핵심 메시지 2** — 인용
+
+- **대표 인용:**
+  > "리뷰어 코멘트 원문"
+  > — @reviewer on `path:line`
+
+## 얻은 교훈
+- **교훈 1** — 일반화된 설계 원칙
+- **교훈 2** — ...
+```
+
+목표 길이: PR당 **60-120줄** (코멘트 양에 비례). racingcar에서 깊이 분석한 PR들 (kkosang/73, ijh1298/144, hyunji1203/15 등) 참고.
+
+### 3. Kotlin 관용구 제외
+
+분석 시 다음은 *제외* (lotto OOP 학습이 아님):
+- scope function (apply/let/run/with/also)
+- smart cast
+- val/var 자체
+- data class 문법 자체 (단, *설계 결정*인 data class vs value class vs class 비교는 OK)
+- collection API 선택 (filter vs find 등)
+
+포함해야 할 것:
+- 책임 분배 / 응집 / 결합 / 캡슐화 / Tell-Don't-Ask
+- 테스터빌리티 / 도메인 모델링
+- 일급 컬렉션 / 원시 강박 / 의존 방향 / 명명 설계
+
+### 4. lotto 도메인 특화 어휘 (반복 패턴들)
+
+- LottoNumber 추출 (1-45 범위 + flyweight)
+- Rank enum의 matchBonus 위치 (필드 vs 판별 입력)
+- Statistics/Bank/Analyzer god-object
+- Map<Rank, Int> wrapping
+- 수동/자동 로또 통합 (Strategy 패턴)
+- Money/Profit/PurchaseAmount 원시값 포장
+- WinningLotto vs Lotto 분리
+- 거스름돈 UX
+
+### 5. 작업 흐름 권장
+
+1. 심각 18개 먼저 (각 60-90줄, 약 5-7개씩 batch + commit + push)
+2. 그 다음 중간 33개 (각 40-70줄, 약 8-10개씩)
+3. 최종 SUMMARY.md / README.md는 *내용 추가/수정 가능*하지만 기존 구조 유지
+4. 각 batch마다 `git commit && git push origin main`
+5. 작업 후 PROGRESS.md의 "완료" 섹션 업데이트
+
+### 6. 검증 (마지막 단계)
+
+```bash
+# 파일 줄 수 분포 — 양호 PR과 비교
+find lessons/woowacourse-kotlin-lotto -name "*-로또.md" | xargs wc -l | sort -n | head -20
+# 부실 재발 점검 (코멘트 ≥30 + 파일 ≤35줄)
+# Kotlin 관용구 누수
+grep -r -E "scope function|apply *\{|let *\{|smart cast" lessons/woowacourse-kotlin-lotto/
+# 무작위 3개 PR과 GitHub 원본 대조
+```
+
+## 빌드/테스트는 영향 없음
+
+`src/` 코드 변경은 없으므로 빌드/테스트 (38개) 그대로 유지됨.
+
+## 양호한 PR 예시 (벤치마크)
+
+각 파일 형식과 깊이의 *목표*:
+
+- `lessons/woowacourse-kotlin-lotto/kkosang/85-2단계-로또.md` (145줄, 132 코멘트)
+- `lessons/woowacourse-kotlin-lotto/hyunji1203/15-1단계-로또.md` (171줄, 85 코멘트)
+- `lessons/woowacourse-kotlin-lotto/krrong/19-1단계-로또.md` (161줄, 79 코멘트)
+- `lessons/woowacourse-racingcar/sh1mj1/115-2단계-자동차-경주.md` — racingcar의 잘된 사례
+
+이들 PR은:
+- 잘한 점 5-7개 항목
+- 못한 점 6-8개 항목 (각각 코드 스니펫 포함)
+- 리뷰어 의견 요지 3-5개 (각각 대표 인용)
+- 얻은 교훈 5-7개
+
+부실 파일은 이런 형식이 아닌 *2-3줄짜리 일반 원칙*만 적힘.

package/lessons/woowacourse-kotlin-lotto/HamBeomJoon/121-1/353/213/250/352/263/204-/353/241/234/353/230/220.md

@@ -0,0 +1,66 @@
+# PR #121 — [로또 1단계] 미플 미션
+
+- **Reviewee:** [@HamBeomJoon](https://github.com/HamBeomJoon)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/121
+- **단계:** 1단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 47
+
+## 못한 점 + 핵심 지적
+
+### 1. `Constants.kt` global
+
+> 상수는 공통으로 여러 곳에서 사용하는 것이 아니라면, 사용하는 곳에 정의해두면 어떨까요?
+
+### 2. `LottoStore` — Controller 역할? 도메인 이름?
+
+```kotlin
+class LottoStore {. }  // 실제는 Controller
+```
+
+> `LottoStore`가 컨트롤러 역할을 하고 있군요! 언뜻 보기에 `LottoStore`라는 네이밍은 도메인 이름 같은데. 이렇게 네이밍하게 된 이유가 있으실까요?
+
+→ "Store"는 도메인 어휘 (가게). Controller라면 `LottoController`가 명확.
+
+### 3. `map` vs `forEach`
+
+```kotlin
+lottos.map { it.print() }  // ⚠ 반환값 미사용
+```
+
+> 여기서 `map`은 람다식의 결과로 새로운 리스트를 만드는 함수에요. `forEach`가 더 적절해보입니다.
+
+→ 변환 ≠ 순회. map의 반환값 안 쓰면 forEach.
+
+### 4. `LottoTicket` — 당첨/일반 합침 + nullable bonus
+
+```kotlin
+class LottoTicket(val numbers: List<LottoNumber>, val bonus: LottoNumber? = null) {. }
+```
+
+> 당첨 로또 번호와 구입한 로또 번호를 같은 클래스로 사용하고 있네요! 이 둘은 겹치는 역할도 있지만, nullable로 해주신 것처럼 보너스 숫자를 모두 가지지는 않아요. 그렇다면 아예 분리를 해볼 수 있을까요? 당첨 로또와 그냥 로또, 그리고 이 둘의 관계를 연관지을 수 있지않을까요?
+
+### 5. `LottoScanner` feature-envy
+
+```kotlin
+class LottoScanner {
+    fun matchCount(ticket: LottoTicket, winning: LottoTicket): Int =.
+}
+```
+
+> 숫자가 몇 개가 일치하는지, 보너스 번호와 맞는지 로또에게 직접 메시지를 던질 수 있지 않을까요?
+
+### 6. `require` 메시지 누락
+
+```kotlin
+require(value in 1..45)  // ⚠ 메시지 없음
+```
+
+> 메시지가 없어서 에러가 난다면 왜 에러가 발생했는지 알 수 없을 것 같아요!
+
+## 얻은 교훈
+
+- **클래스명 = 역할 (Controller/Domain/View) 명확히** — "Store"는 도메인, "Controller"는 흐름. 헷갈리지 않게.
+- **`map` vs `forEach` — 반환값 사용 여부**.
+- **nullable로 두 개념 합치기 회피** = lotto 반복 패턴 (`Lotto` vs `WinningLotto`).
+- **require 메시지 = 디버깅 비용 ↓**.