oh-my-oop 0.2.0

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

@@ -0,0 +1,143 @@
+# PR #61 — [로또 1단계] 호두
+
+- **Reviewee:** [@Junyoung-WON](https://github.com/Junyoung-WON)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/61
+- **단계:** 1단계
+- **리뷰어:** @ghojeong (파이로)
+- **라인 코멘트:** 18
+
+## 잘한 점 (설계 관점)
+
+- **README 기능 목록 잘 정리**.
+- **`Lotto.init`에 *중복/개수* 검증** — `require` 활용.
+- **`enum class WinningRank(countOfMatch, winningMoney)`** — 등수+상금 응집.
+- **`object LottoMachine`** — 상태 없는 발행 객체.
+- **`shuffled().take().sorted()` 체이닝**.
+
+## 못한 점 (설계 관점)
+
+### 1. 테스트 케이스 *분리되지 않은 두 책임*
+
+```kotlin
+@ParameterizedTest
+@ValueSource(strings = ["1, 1, 1, 2, 3, 4", "1, 2, 3, 4, 5, 30, 1", "3, 4, 5, 30, 1"])
+fun `로또 번호는 1~45 사이의 6개의 서로 다른 자연수를 갖지 않으면 오류를 발생시킨다`(input: String) {. }
+```
+
+리뷰어: "로또 번호의 중복과, 로또 번호의 개수가 6이 아닌 것은 *별개의 로직*이라 생각되는데, 테스트 또한 *분리*하면 어떨지 제안해 봅니다. 가령 `3, 4, 5, 30, 1` 테스트 케이스의 경우 *로또 번호 개수가 5라서 발생*하는데, 앞의 케이스만 보고 있으면, *중복에 대한 테스트를 하고 있다고 넘겨 짚을 수 있을 것* 같아서요." — 테스트는 *한 가지 사실*만 검증.
+
+### 2. 매직 넘버 `1000` — 상수화 부재
+
+```kotlin
+fun getEarningRate(): Double {
+    val total: Long = status.entries.sumOf { it.key.winningMoney * it.value }
+    return (total / (status.values.sum() * 1000).toDouble())  // ⚠ 1000
+}
+```
+
+리뷰어: "0, 1, 1000과 같은 *매직 넘버*들은 상수화해 주시면, *나중에 유지보수*를 하게 편할 것 같습니다. 가령 *로또 한 장의 가격이 물가가 올라서 1500원으로* 오르게 되면, 어디서 값을 수정해야 하는지 *동료가 코드 전체를 읽고 로직을 파악*해야 할 것 같습니다." 학생: "수업 시간에서도 배웠던 내용이네요!"
+
+### 3. `WinningRank`가 `util` 패키지
+
+```
+lotto/util/WinningRank.kt
+```
+
+리뷰어: "멤버를 가지도록 enum class를 적극적으로 활용해 주신 점 멋집니다. 다만 *WinningRank를 ValidationUtils처럼 util 패키지 안에 배치한 의도*를 여쭈어봅니다. String으로 바꾸는 *formatByRank* 때문인가요?" 학생: "요구사항 형식에 맞춰 *출력할 수 있도록 문자열을 반환*해 주는 formatByString과 *로또 번호를 맞춘 개수에 따라 등수를 반환*해 주는 convert를 활용한다는 점에서, *일종의 도구로써 활용*되는 점이 크다고 생각해 util로 분류." 후속: "WinningRank는 *util보다는 model에서 다루는 것*도 좋아 보인다는 생각도 듭니다."
+
+### 4. `WinningRank.formatByRank` — 다국어/문구 변경?
+
+```kotlin
+override fun toString(): String =
+    WinningRank.entries.filter { it != WinningRank.MISS }.joinToString("\n") {
+        "${WinningRank.formatByRank(it)} - ${status.getOrDefault(it, 0)}개"
+    }
+```
+
+리뷰어: "혹시 toString을 하실 때 *어디까지를 model의 영역으로 생각하시고, 어디까지를 view의 영역*이라 생각하시는지 호두님만의 기준이 있으신지 여쭈어봅니다. *다국어 서비스를 지원*하는 안드로이드 개발을 하게 될 경우 *개수를 ~개*와 같은 부분은 여러 언어로 나타내고 싶다는 요구사항이 생긴다면 어떻게 대처를 하실 계획인가요?" + "formatByRank의 경우는 특히나 개발을 잘하는 개발자가 아니라, *영어나 글을 잘 쓰는 기획자가 유지보수*를 하게 될 가능성이 큽니다. 가령 *'할 일'이라는 단어를 Quest, Task, ToDo 중에서 무엇으로 할 것인지 한 달 넘게 싸우면서, A/B 테스트*를 하는 경우도 있습니다 ㅋㅋㅋㅋㅋ" 학생: "*model과 view의 역할에 따라 적절히 구분 지을 필요*가 있다는 것을 알게 되었습니다. checker는 model로써 *자신이 가진 데이터만을 view에게 넘겨주고*, *다른 나라의 언어로 변경 시에 출력 문자를 바꾸는 것은 view의 역할*을 하는 것이 적합할 것이라 생각이 듭니다."
+
+### 5. `LottoMachine` 랜덤 내장 — 테스트 불가
+
+```kotlin
+object LottoMachine {
+    fun issueTickets(count: Int): List<Lotto> {
+.
+        tickets.add(Lotto(Lotto.NUMBER_RANGE.shuffled().take(Lotto.NUMBER_COUNT).sorted().map { LottoNumber(it) }))
+.
+    }
+}
+```
+
+리뷰어: "shuffled, take, sorted를 잘 활용해 주신 점 멋집니다! 다만 *shuffled는 자동차 경주 미션 때와 마찬가지로 Random 요소*라 생각이 되는데, 자동차 경주 미션 때처럼 *테스트를 하기 어렵게 만드는 요인*이라 생각됩니다." 학생: "*지난 미션에서 피드백 받은 내용과 아주 흡사*한 것 같습니다. 그때에는 제대로 구현해 보지 못했지만, *functional interface를 활용*하면 테스트를 위한 로또 번호 생성 메서드를 테스트 코드에서 정의하여 *기능 구현과 테스트를 동시에 용이*하게 만들어 줄 수 있다는 피드백을 받았습니다. 이 경우에서도 *함수형 인터페이스를 활용*하면 적합할 것 같다."
+
+### 6. `WinningStatusChecker`의 `MutableMap` 누적
+
+```kotlin
+class WinningStatusChecker(results: List<WinningRank>) {
+    private val status: MutableMap<WinningRank, Int> = mutableMapOf()
+    init {
+        results.forEach { rank ->
+            status[rank] = status.getOrDefault(rank, 0) + 1
+        }
+    }
+}
+```
+
+`groupingBy { }.eachCount()`로 한 줄 압축 가능. *누적 절차*가 *함수형 어휘*로.
+
+### 7. Controller의 `makeResult` 흐름 — 테스트 가치
+
+```kotlin
+private fun makeResult(lottoTickets: List<Lotto>) {
+    val winningResult = lottoTickets.map {
+        WinningRank.convert(it.checkWinningNumbers(lotteryResult.winning), it.checkBonusNumbers(lotteryResult.bonusNumber))
+    }
+    val winningStatusChecker = WinningStatusChecker(winningResult)
+.
+}
+```
+
+리뷰어: "가령 winningResult가 의도한 대로 만들어졌는지는, *충분히 테스트할 가치가 있는 로직*이라 생각되는데, 이러한 로직은 어떻게 테스트를 할 수 있을까요?" — Controller에 *비즈니스 로직*이 있으면 *도메인으로 이동* 또는 *Controller 단위 테스트*.
+
+### 8. `Rank` 테스트 부분만
+
+```kotlin
+@CsvSource("6,False,FIRST", "5,True,SECOND", "5,False,THIRD", "2,False,MISS")
+```
+
+리뷰어: "기왕 테스트를 한다면 *FOURTH와 FIFTH에 대한 테스트까지* 해주시면 좋을 것 같습니다." — *모든 분기*를 명세서로.
+
+## 리뷰어 의견 요지
+
+- **테스트 한 가지 사실** — 중복과 개수는 다른 책임, 다른 테스트.
+- **매직 넘버 상수화** — 가격 변경에 유연.
+- **`util` 패키지의 god-folder 위험** — 도메인 객체는 *model*에.
+- **`toString` = View 책임** — *문구/다국어/A-B 테스트*는 도메인이 알면 안 됨.
+- **랜덤은 *함수형 인터페이스*로 주입** — TDD 정합.
+- **Controller의 비즈니스 로직 = 도메인으로 이동** 또는 *별도 테스트*.
+- **모든 enum 분기 테스트**.
+
+- **대표 인용:**
+  > 로또 번호의 중복과, 로또 번호의 개수가 6이 아닌 것은 *별개의 로직*이라 생각되는데, 테스트 또한 *분리*하면 어떨지 제안해 봅니다.
+  > — @ghojeong on `src/test/kotlin/lotto/model/LottoTest.kt`
+
+  > 어디까지를 model의 영역으로 생각하시고, 어디까지를 view의 영역이라 생각하시는지 호두님만의 기준이 있으신지 여쭈어봅니다. *다국어 서비스를 지원*하는 안드로이드 개발…
+  > — @ghojeong on `src/main/kotlin/lotto/model/WinningStatusChecker.kt`
+
+  > formatByRank의 경우는 특히나 *영어나 글을 잘 쓰는 기획자가 유지보수*를 하게 될 가능성이 큽니다. *'할 일'이라는 단어를 Quest, Task, ToDo 중에서 무엇으로 할 것인지 한 달 넘게 싸우면서, A/B 테스트*를 하는 경우도.
+  > — @ghojeong on `src/main/kotlin/lotto/util/WinningRank.kt`
+
+  > shuffled는 자동차 경주 미션 때와 마찬가지로 Random 요소라 생각이 되는데, *테스트를 하기 어렵게 만드는 요인*이라 생각됩니다.
+  > — @ghojeong on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+## 얻은 교훈
+
+- **테스트는 *한 가지 사실*** — 중복과 개수가 한 테스트에 섞이면 *실패 메시지가 어느 사실 위배*인지 모름.
+- **매직 넘버 상수화** — *유지보수 단위*를 한 곳에. 가격 변경이 *코드 전체 grep*이 되면 누락 위험.
+- **`util` 패키지에 *도메인 객체* 배치 회피** — `WinningRank`는 *도메인 모델*.
+- **`toString`은 View 책임** — 도메인이 *문구/다국어/A-B 테스트*를 알면 *기획자가 도메인을 수정*해야 함.
+- **랜덤은 *함수형 인터페이스*로 주입** — TDD 정합 + 시나리오 강제 테스트.
+- **누적 패턴은 `groupingBy { }.eachCount()`** — `MutableMap + getOrDefault`보다 함수형.
+- **Controller의 비즈니스 로직** = 테스트 가치 *있음*. 도메인으로 이동 또는 *Controller 단위 테스트*.
+- **enum의 *모든 분기*** 테스트 — 부분만 테스트하면 *나머지 분기*는 미보장.
+- **이전 미션 *피드백 누적*** — 학생이 *자동차 경주 미션*과 *동일 피드백*을 받음을 자가 인정. *반복 학습 신호*.

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

@@ -0,0 +1,16 @@
+# PR #93 — [로또] 호두 2단계 미션
+
+- **Reviewee:** [@Junyoung-WON](https://github.com/Junyoung-WON)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/93
+- **단계:** 2단계
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 12
+
+## 잘한 점
+
+- **로또 번호의 개수와 중복에 관한 테스트 분리** — 1단계 피드백 반영.
+- **WinningRank 등수 반환 테스트 세분화**.
+
+## 얻은 교훈
+
+- **테스트 시나리오 분리 = 1단계 피드백 흡수**. 각 검증을 별 테스트로.

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

@@ -0,0 +1,57 @@
+# PR #109 — [로또 1단계] 시아 미션
+
+- **Reviewee:** [@Leeyerin0210](https://github.com/Leeyerin0210)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/109
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 53
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto` 일급 클래스 (실제로는 일급 컬렉션)**.
+- **PR 본문 자가 의문 명시** — 일급 클래스 정의/개선점, 와일드카드 import 등.
+
+## 못한 점 (설계 관점)
+
+### 1. 일급 컬렉션 용어 — 일급 클래스로 잘못 부름
+
+학생 의문:
+
+> Lotto 클래스를 일급 클래스로 사용하였습니다. 일급클래스의 정의에 맞게 잘 사용되었나요?
+
+리뷰어:
+
+> 정확히는 일급 컬렉션이라고 부르는게 자연스럽겠네요. 지금도 충분히 잘 작성 해주셨습니다. 굳이 역할을 한번 더 나눠 본다면 Lotto, LottoNumbers 두개의 역할로 분리를 해 볼 수 있겠네요.
+
+→ "일급 클래스" = first-class citizen (다른 객체와 동등). "일급 컬렉션" = First-class Collection (Object Calisthenics 9번째 룰).
+
+### 2. `intersect()` 컬렉션 함수 미활용
+
+```kotlin
+val matched = lotto.numbers.filter { it in winning.numbers }.size
+```
+
+→ `lotto.numbers.intersect(winning.numbers).size`.
+
+### 3. `Lotto`가 보너스 관심사 보유
+
+```kotlin
+class Lotto(.) {
+    fun hasBonus(bonus: Int): Boolean =.  // ⚠ 보너스 자체는 Lotto의 관심사 아님
+}
+```
+
+> 로또 입장에서는 보너스 넘버라는 관심사는 아마 필요 없겠죠?
+
+→ Lotto는 *번호 6개 보유*만, 보너스 비교는 *WinningLotto*가.
+
+### 4. 와일드카드 import lint 위반
+
+→ Ktlint 자동 검사. IDE 설정에 따라 자동 import 후 ktlint 실패 — 환경 일관성 필요.
+
+## 얻은 교훈
+
+- **"일급 컬렉션"의 정확한 용어** — Object Calisthenics 9번째 룰. `List<T>` 그대로 노출 회피 + 컬렉션 자체에 도메인 행위 부여.
+- **`intersect()` 활용** — lotto 매칭 표준 함수.
+- **Lotto의 관심사 = 자기 번호**. 외부 (보너스, 당첨 기준) 비교는 *그 도메인이 시키는 일*.
+- **Lint 설정 + IDE 설정 일관화** — 충돌하면 매번 lint 수정 부담.

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

@@ -0,0 +1,115 @@
+# PR #135 — [로또 2단계] 시아 미션 제출합니다
+
+- **Reviewee:** [@Leeyerin0210](https://github.com/Leeyerin0210)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/135
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 67
+
+## 잘한 점 (설계 관점)
+
+- **`Amount` 값 객체 + `Amount.Zero` 같은 상수 추가** — 1단계 흡수.
+- **2단계 자가 의문 4개 PR에 명시** — 출력/도메인 결합, null 흐름, 예외 테스트, 재귀 vs 반복 일관성.
+
+## 못한 점 (설계 관점)
+
+### 1. enum에 출력 관련 정보 보유 (View-Domain 결합)
+
+```kotlin
+enum class Rank(val matchCount: Int, val winnings: Int, val message: String) {
+    FIRST(6, 2_000_000_000, "6개 일치"),
+.
+}
+```
+
+학생 자가 의문:
+
+> 출력 코드를 개선하기 위해 enum에 출력 관련 정보들을 넣어뒀는데, 이러면 뷰와 도메인이 너무 강하게 결합된 것일까요?
+
+리뷰어 답:
+
+> 넵, 결합된 것 같습니다. 물론 서버에서 출력 순서를 결정하는 경우도 있지만 프레젠테이션.
+
+→ 출력 메시지는 OutputView 책임. enum이 *영구한 데이터*만 (matchCount, winnings).
+
+### 2. null로 잘못된 입력 표현 → Controller에서 null 체크 + 재입력
+
+```kotlin
+class LottoController {
+    fun run() {
+        val amount = readAmount() ?: return run()  // ⚠ null → 재귀
+.
+    }
+    private fun readAmount(): Amount? {
+        return try { Amount(.) } catch (e: Exception) { null }
+    }
+}
+```
+
+학생 의문:
+
+> 요구사항은 에러가 생겼을 때 null을 리턴하라고 했으나, null을 사용하면 후속 코드가 전부 꼬이는 것 같습니다.
+
+→ null은 *부재*를 표현. *오류*는 sealed result type이 더 적절.
+
+### 3. 일관성 부족 — 한 곳은 재귀, 다른 곳은 반복
+
+```kotlin
+fun readAmount(): Amount = try {. } catch (e) { readAmount() }      // ⚠ 재귀
+fun readWinning(): Winning = while (true) { try { return. } catch. }   // ⚠ 반복
+```
+
+> 코드 작성할 때 가장 중요한 요소 중 하나는 일관성입니다. 다른 사람이 이어서 개발을 한다고 하면 뭐로 해야하지? 라는 착각에 빠지기 때문에 여러개로 구현이 나뉘는 것보다 하나의 일관된 흐름을 만드는것이 좋습니다.
+
+### 4. `Amount`의 invariant 표현 부족
+
+```kotlin
+class Amount(val value: Int) {
+    init { require(value >= 0) }
+}
+```
+
+리뷰어 가르침:
+
+> 돈이 마이너스로 내려가면 프로그램이 종료된다와 돈은 최소 Amount.Zero 까지만 내려간다. 라는 차이를 들 수 있겠네요
+
+→ 같은 invariant라도 *어떻게 표현하느냐*에 따라 도메인의 의미 명확도가 다름. *Amount.Zero* 같은 의미 있는 경계.
+
+### 5. `LottoMachine`이 돈을 받아 직접 차감
+
+```kotlin
+class LottoMachine(var money: Amount) {
+    fun buy(): Lotto {
+        money = money.minus(LOTTO_PRICE)  // ⚠ 기계가 돈을 소모
+        return Lotto(.)
+    }
+}
+```
+
+> 돈을 넣는다는 기능이 별도로 빠진 이점을 잘 모르겠어요! 로또 기계는 왜 스스로 가진 돈을 소모해버리는 건지도 잘 와닿지가 않아요.
+
+→ 현실 비유: 로또 기계는 *돈을 받고* 로또를 *준다*. 돈을 *소유*하지 않음.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 메시지:
+
+1. **enum의 *영구 데이터*와 *표현 정보*를 구분** — matchCount/winnings는 영구 데이터, message는 표현.
+
+2. **null = 부재. 오류 ≠ null**. sealed result로 오류 의미 명시.
+
+3. **일관성 > 미세 최적화** — 입력 흐름이 두 가지로 나뉘면 동료 혼란.
+
+4. **현실 모델링** — 로또 기계는 돈을 소유하지 않고 *교환*한다.
+
+- **대표 인용:**
+  > 돈을 넣는다는 기능이 별도로 빠진 이점을 잘 모르겠어요! 로또 기계는 왜 스스로 가진 돈을 소모해버리는 건지도 잘 와닿지가 않아요.
+  >
+  > — @laco-dev on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+## 얻은 교훈
+
+- **enum의 두 분류** — *영구 도메인 데이터* (matchCount, winnings) vs *표현 정보* (message). 후자는 OutputView로.
+- **null의 의미 = 부재**. 오류는 sealed result. `Amount?`로 null 흐름 만들면 후속 코드가 *부재 ≠ 오류*를 구분해야 함.
+- **일관성이 정답 없을 때의 기준**. 재귀와 반복 둘 다 가능하면 *팀 컨벤션*으로 하나만.
+- **현실 모델링의 비유 검증** — "로또 기계가 돈을 소유하나?" → 사용자 → 로또 기계 → 로또 교환. 기계는 매개체.

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

@@ -0,0 +1,160 @@
+# 진행 상황 (작업 일지) — kotlin-lotto
+
+이 문서는 `woowacourse/kotlin-lotto` PR 리뷰 분석 작업의 **상태 추적용**이다.
+
+## 데이터셋
+
+- 출처: https://github.com/woowacourse/kotlin-lotto/pulls?q=is:pr+is:closed
+- 전체 closed PR: **153개**
+- 분석 대상 필터: **라인 레벨 reviewer 코멘트 ≥ 5개**
+- 통과한 PR: **141개**, 고유 reviewee: **71명**
+
+## 분석 어휘
+
+- 유지: 책임/응집/결합/캡슐화/Tell-Don't-Ask/테스터빌리티/도메인 모델링/일급 컬렉션/원시 강박/의존 방향/명명 설계
+- 제외: Kotlin 관용구 (scope function, smart cast, null 처리, val/var, data class 사용 여부, init 블록 형태, collection API 선택, extension 위치)
+
+## 추가 지침 (racingcar와 다른 점)
+
+- **코드 스니펫 포함**: 안티패턴이 명확한 경우 `diff_hunk` 또는 인용 코드를 함께 기록해 가독성 향상.
+- **lotto 도메인 특화 어휘**: 당첨 등수 (Rank/Winning), 금액 계산 (Money/Profit), 통계 집계 (Statistics), 로또 번호 검증 (LottoNumber) 등.
+
+## ✅ 완료
+
+**141 PRs / 71 reviewees 완료** — 2026-05-22
+
+`SUMMARY.md` + `README.md` 작성 완료.
+
+### 부실 파일 보강 — Round 2 (2026-05-22)
+
+이전 세션에서 후반부 51개 파일이 부실하게 작성되어 보강 작업 진행 중. 부실 기준: 코멘트 ≥30개인데 파일 ≤35줄, 또는 코멘트 15-29개에 파일 ≤30줄.
+
+**심각 18개 PR 재작성 완료 (2026-05-22)** — 코멘트 30+ / 파일 35줄 미만:
+
+| PR | Reviewee | 코멘트 | 결과 길이 |
+|----|----------|--------|----------|
+| #132 | hwannow | 58 | ~140줄 |
+| #91  | sh1mj1 | 42 | ~140줄 |
+| #150 | wondroid-world | 41 | ~120줄 |
+| #129 | chanho0908 | 39 | ~150줄 |
+| #92  | Hevton | 38 | ~150줄 |
+| #78  | gaeun5744 | 38 | ~140줄 |
+| #127 | medAndro | 36 | ~160줄 |
+| #114 | tobae-time | 36 | ~140줄 |
+| #13  | otter66 | 35 | ~150줄 |
+| #94  | kimhm0728 | 34 | ~170줄 |
+| #134 | jerry8282 | 34 | ~160줄 |
+| #122 | ijh1298 | 34 | ~170줄 |
+| #81  | junjange | 32 | ~170줄 |
+| #133 | ijh1298 | 32 | ~170줄 |
+| #116 | cucumber99 | 32 | ~160줄 |
+| #58  | junjange | 31 | ~150줄 |
+| #32  | RightHennessy | 31 | ~150줄 |
+| #112 | etama123 | 31 | ~170줄 |
+
+작성 방식:
+- 전체 코멘트(jq dump) 완독 후 분석 (압축 X)
+- 잘한 점 (5-7개) + 못한 점 (9-13개) + 리뷰어 의견 요지 + 대표 인용 + 얻은 교훈
+- 안티패턴마다 `diff_hunk` 또는 인용 코드 스니펫 포함
+- 양호한 벤치마크 PR (kkosang/85, hyunji1203/15) 수준으로 깊이 맞춤
+- Kotlin idiom 제외, OOP 설계만 (책임/응집/결합/Tell-Don't-Ask/도메인 모델링)
+
+### 중간 33개 PR 보강 완료 (2026-05-22)
+
+코멘트 15-29개에 파일 ≤30줄이던 33개 PR. **모두 80-200줄로 보강 완료**.
+
+#143, 95, 63, 51, 35, 145, 117, 103, 97, 71, 151, 9, 24, 70, 38, 152, 98, 82, 53, 52, 61, 146, 49, 40, 25, 148, 36, 144, 80, 8, 77, 75, 21
+
+작성 방식 (심각 18개와 동일 수준):
+- 잘한 점 (3-7개) + 못한 점 (6-12개, 각 코드 스니펫 포함) + 리뷰어 의견 요지 + 대표 인용 (4개) + 얻은 교훈 (7-11개)
+- 모든 reviewer 코멘트를 *압축 없이* 전부 인용
+- 학생 자가 의문 + 리뷰어 응답 + 후속 라운드 응답 모두 캡처
+
+### 추가 27개 PR 보강 완료 — Round 3 (2026-05-23)
+
+원래 HANDOVER 51개 외 추가로 발견된 부실 PR. 댓글 15+, 분석 35-46줄이었던 27개를 모두 100-238줄로 보강.
+
+**심각 그룹 (댓글 30+, 댓글 49-56개 4개 PR):**
+- #131 junseo511 (56) — 함수 분리 vs 분해 명언, Wallet 메타포 비대칭
+- #64 aprilgom (50) — 키오스크 시나리오로 View 인터페이스 정당화
+- #113 hwannow (49) — 객체지향=현실 은유 ("객체지향의 사실과 오해" 직접 인용)
+- #90 murjune (45) — try-catch 본질 (Elizarov), sealed class 단일 인터페이스
+
+**중상 그룹 (댓글 30-44, 8개 PR):**
+- #123, #69, #60, #147, #3, #14, #48, #140
+
+**중하 그룹 (댓글 15-29, 15개 PR):**
+- #119, #87, #31, #141, #72, #5, #137, #50, #153, #89, #47, #55, #12, #46, #138
+
+## 진행 상태
+
+**심각 18 + 중간 33 + Round 3 추가 27 = 78개 PR 보강 완료 (2026-05-22 ~ 05-23)**
+
+전체 141 PR 분석 자료 정상 깊이로 정리 완료. 남은 17개 짧은 파일은 모두 댓글 6-14개의 저-댓글 PR로 적정 길이.
+
+## MCP에 반영된 lotto 안티패턴 (2026-05-23)
+
+이 코퍼스에서 도출한 안티패턴 중 5개가 oh-my-oop MCP 서버의 validate 룰로 코드화됨. 룰의 evidence/remedy에는 아래 PR의 *대표 인용*이 발췌되어 들어가 있다.
+
+| 신규 룰 ID | 인용 PR | 핵심 통찰 |
+|---|---|---|
+| `empty-object-external-fill` | [#14](Choisehyeon/14-1단계-로또.md) @malibinYun | "빈 껍데기를 만들어서 외부에서 값을 채우지 말 것." 도메인 객체는 생성 시점에 invariant 충족. |
+| `collection-wrapper-without-behavior` | [#144](jiyuneel/144-2단계-로또.md) @krrong | 일급 컬렉션이 *행동* 없이 `toString` 오버라이드 용도면 만들지 않는 것도 좋은 답. |
+| `primitive-wrapper-without-invariant` | [#58](junjange/58-1단계-로또.md) @junjange, [#77](hxeyexn/77-1단계-로또.md) @hxeyexn | `init`은 자기 invariant, factory는 입력 변환 + 생성 결정. invariant 없는 wrapper는 원시값과 동일. |
+| `strategy-default-param-pollution` | [#144](jiyuneel/144-2단계-로또.md) @krrong | 공통 인터페이스 = 공통 시그니처. 분기 인자(`manualNumbers`)는 생성자로 끌어올려야 호출 컨텍스트가 분리됨. |
+| `function-decomposition-excess` | lotto 일반 (@krrong 류 코멘트 다수) | 함수를 *분리*하는 것이지 *분해*하는 것이 아니다. 1-2줄짜리 private 헬퍼 남발은 가독성 저하. |
+
+룰을 추가하면서 함께 도입된 트레이드오프 heuristic 4종: `value_object_shape`, `strategy_or_policy`, `error_handling`, `collection_shape` (총 8개 typed heuristic + `free_form`).
+
+상세 룰 ↔ 안티패턴 매핑은 `../../MCP_STRUCTURE.md` §3 참조.
+
+## 캐시 위치
+
+`/tmp/oop-lessons-cache-lotto/`:
+- `prs.json` — 153개 PR 메타
+- `nums.txt` — PR 번호 목록 (1-153)
+- `counts.tsv` — PR# / 라인 코멘트 수
+- `filtered.tsv` — ≥5 코멘트 PR 목록
+- `authors.tsv` — PR# / 작성자
+- `grouped.tsv` — PR# / 코멘트 수 / 고유 리뷰어 수 / 작성자
+- `comments/<N>.json` — PR별 라인 코멘트 (diff_hunk 포함)
+
+**주의:** `/tmp`는 재부팅 시 사라질 수 있음. 시작 전 캐시 확인 후 없으면 재생성.
+
+## 우선순위 (코멘트 많은 PR 순)
+
+```
+85  (132)  kkosang     - [로또 2단계]
+15  ( 85)  hyunji1203  - [로또 1단계]
+19  ( 79)  krrong      - [로또 1단계]
+65  ( 75)  songpink    - [로또 1단계]
+16  ( 75)  ippnsj      - [로또 1단계]
+106 ( 75)  giovannijunseokim
+120 ( 71)  junseo511
+27  ( 70)  2chang5     - [로또 1단계]
+115 ( 68)  jerry8282
+135 ( 67)  Leeyerin0210
+... (계속 grouped.tsv 참조)
+```
+
+## 다음 세션 시작 시
+
+1. 이 파일 + 가장 최근 commit 확인
+2. 캐시 존재 여부 확인 (`ls /tmp/oop-lessons-cache-lotto/comments/ | wc -l == 153`)
+3. 캐시 있으면 미완 reviewee부터 진행
+4. 5-10 PR마다 commit + push로 안전 저장
+5. 전체 141개 완료 후 `SUMMARY.md` + `README.md` 작성
+
+## 작성 패턴
+
+- 1단계 PR이 비슷한 안티패턴(원시 강박, Statistics god-object 등) 반복 → 2단계는 짧게
+- 핵심 트레이드오프 또는 새로운 패턴에 더 집중
+- 사람마다 40-80 lines 정도가 적정 (1단계 = 60-100, 2단계/리팩토링 = 40-70)
+- **안티패턴 코드 스니펫** 인용 시 ` ```kotlin ... ``` ` 블록으로
+
+## 검증 — 최종 단계에서 수행
+
+- 무작위 3개 PR 파일을 GitHub 원본과 대조
+- Kotlin 관용구 누수 점검 (`grep -r -E "scope function|apply *\{|let *\{|smart cast"`)
+- `SUMMARY.md`의 PR 카운트 = 실제 `.md` 수
+- 모든 reviewee 폴더에 최소 1개 .md

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

@@ -0,0 +1,77 @@
+# 우아한테크코스 kotlin-lotto PR 리뷰 OOP 교훈
+
+[`woowacourse/kotlin-lotto`](https://github.com/woowacourse/kotlin-lotto) 리포의 closed PR 153개 중 라인 코멘트 ≥ 5개인 **141개 PR (71명 reviewee)**을 분석해 도출한 OOP 설계 교훈 모음.
+
+## 📖 시작하기
+
+- **[SUMMARY.md](SUMMARY.md)** — 전체 정리 (자주 하는 실수 TOP 10, 리뷰어 명언, 조영호 강의 토픽 매핑, 단계별 학습 곡선, **racingcar vs lotto 비교**)
+- **개별 PR 분석** — 각 reviewee 폴더 안에 `<PR번호>-<단계>-로또.md` 형태로 정리
+- **이전 미션**: [racingcar lessons](../woowacourse-racingcar/) — 같은 학생들의 이전 학습 흐름
+
+## 🎯 분석 범위
+
+**OOP 설계 관점만**:
+책임 분배 / 응집도 / 결합도 / 캡슐화 / Tell-Don't-Ask / 테스터빌리티 / 도메인 모델링 / 일급 컬렉션 / 원시 강박 / 의존 방향 / 명명 설계
+
+**제외**:
+Kotlin 관용구 (scope function, smart cast, null 처리 idiom, val/var, data class 문법 자체)
+
+**추가 (racingcar lessons와의 차이)**:
+**안티패턴 발견 시 실제 `diff_hunk` 코드 스니펫을 함께 인용** — 가독성과 즉시 파악 ↑.
+
+## 📂 폴더 구조
+
+```
+woowacourse-kotlin-lotto/
+├── README.md (이 문서)
+├── SUMMARY.md (총정리)
+├── PROGRESS.md (작업 진행 로그)
+└── <reviewee-name>/
+    └── <PR번호>-<단계>-로또.md
+```
+
+각 PR 분석은 다음 구조:
+- **잘한 점** (설계 관점)
+- **못한 점** (설계 관점) — *실제 코드 스니펫 포함*
+- **리뷰어 의견 요지** (대표 인용 1~3개 + 출처)
+- **얻은 교훈**
+
+## 🔥 lotto 도메인 특화 안티패턴 TOP 5
+
+racingcar와 다른 lotto만의 패턴:
+
+### 1. `LottoNumber` 도메인 누락
+`Lotto`가 `List<Int>` 노출 → 호출자가 매번 "이 Int가 로또 번호 맞나?" 의심
+
+### 2. `Rank` enum + `matchBonus` 처리
+5개 일치 두 가지 분기 (2등 vs 3등) 어떻게 표현?
+→ 필드 vs 검색 입력 vs `null` fallback
+
+### 3. `Map<Rank, Int>` wrapping 회피
+통계 자료구조를 그대로 노출 → 표현 책임이 View로 누수
+
+### 4. 수동/자동 로또 통합 (2단계)
+같은 *발급 협력*인데 다른 시그니처 → Strategy 패턴 미적용
+
+### 5. `Money`/`Profit`/`Yield` 금융 도메인
+원시값 그대로 노출 또는 wrapping만 (행위 부재)
+
+자세한 내용: [SUMMARY.md의 "자주 하는 설계 실수 TOP 10"](SUMMARY.md#자주-하는-설계-실수-top-10-lotto-도메인-특화)
+
+## 🎓 단계별 학습 곡선
+
+**1단계** = LottoNumber 추출, Rank enum 설계, Validator 위치, Statistics god-object
+**2단계** = 수동/자동 통합, Strategy 패턴, Map<Rank, Int> wrapping, flyweight 캐싱, 거스름돈 UX
+
+자세한 분석은 [SUMMARY.md의 "단계별 학습 곡선"](SUMMARY.md#단계별-학습-곡선-lotto) 참고.
+
+## 🔗 관련 리소스
+
+- 원본 리포: https://github.com/woowacourse/kotlin-lotto
+- 이전 미션: [woowacourse-racingcar/](../woowacourse-racingcar/) — racingcar lessons (133 PR)
+- 분석 도구 (Oh-My-OOP MCP): [상위 리포 README](../../README.md)
+- 조영호 "객체지향의 사실과 오해" — 책임/역할/협력 3요소가 본 분석의 주요 어휘
+
+## 📝 작업 로그
+
+분석 과정과 데이터 위치는 [PROGRESS.md](PROGRESS.md) 참고. 캐시된 PR 메타와 코멘트 JSON은 `/tmp/oop-lessons-cache-lotto/`에 저장됨 (재부팅 시 사라질 수 있음).