oh-my-oop 0.2.0

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

@@ -0,0 +1,97 @@
+# PR #115 — [로또 1단계] 제리 미션 제출합니다
+
+- **Reviewee:** [@jerry8282](https://github.com/jerry8282)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/115
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 68
+
+## 잘한 점 (설계 관점)
+
+- **`BonusNumber`를 value class로** — inline + 단일 값 타입 안전성.
+- **`Retry` 유틸 분리** — 재시도 흐름 일반화.
+- **PR 본문에 자가 의문 명시** — 원시 값 포장 범위.
+
+## 못한 점 (설계 관점)
+
+### 1. `main()` 이름 모호 (다게임 확장 시)
+
+```kotlin
+fun main() {. }
+```
+
+> 추후 게임종류가 많아진다면, main() 이라는 네이밍이 다소 애매하게 느껴질 수 있겠네요~ 이를 로또에 맞게 바꾸려면 어떻게 바꿔보는 것이 좋을까요?
+
+→ `Application` 클래스 + `main()`이 그걸 호출하는 패턴 (이전 PR들에서도 자주 등장).
+
+### 2. Controller가 검증 직접
+
+```kotlin
+class LottoController {
+    fun run() {
+        val purchaseAmount = readPurchaseAmount()
+        validatePurchaseAmount(purchaseAmount)  // ⚠ Controller가 검증
+.
+    }
+}
+```
+
+> Validation Check 를 Controller 에서 작업을 하신 이유가 궁금합니다.
+
+→ 검증은 도메인 객체 init 또는 InputView 형식 검증으로.
+
+### 3. `1..45` 매직 범위 (LottoNumber.MIN/MAX 미상수화)
+
+```kotlin
+require(number in 1..45) {. }
+```
+
+→ `LottoNumber.MIN_VALUE..LottoNumber.MAX_VALUE` 같이 *도메인 객체*가 자기 범위 소유.
+
+### 4. `value class BonusNumber` 사용 — 이유 자가 의문
+
+> value class 를 사용하신 이유가 value class는 어떤 특징을 가지고 있을까요?
+
+학생이 자가 답:
+
+```kotlin
+@JvmInline
+value class BonusNumber(val value: Int) {
+    init { require(value in 1..45) }
+}
+```
+
+→ value class는 인라인되어 *런타임 박싱 없이* 타입 안전성. 단일 값 wrapper에 최적.
+
+### 5. `Retry` 유틸의 실서비스 사용처 자가 의문
+
+```kotlin
+object Retry {
+    fun <T> retry(input: () -> T): T =.
+}
+```
+
+> 실제 서비스에서 이 로직은 언제 사용을 하실건가요?
+
+→ racingcar에서도 같은 리뷰. *일반화는 사용처 명확할 때*.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 패턴 (racingcar의 같은 리뷰어):
+
+1. **사용처 명확한 일반화** — Retry 유틸이 미션 외 실서비스에서 어떻게 쓰일지.
+
+2. **value class 사용 이유의 자가 정리**.
+
+3. **검증 위치 - Controller인지 의문**.
+
+- **대표 인용:**
+  > Validation Check 를 Controller 에서 작업을 하신 이유가 궁금합니다~
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **`main()` 이름의 미래 모호함** — 다게임 확장 시 `lotto.main`, `racing.main`로 구분 어려움. `LottoApplication.run()`이 더 명확.
+- **value class > data class (단일 값)** — 런타임 박싱 없음 + 동치성. LottoNumber, BonusNumber 같은 도메인에 적합.
+- **재시도 유틸 일반화 = 사용처 명확할 때만** — Retry<T>가 미션에서 한 번 쓰면 추상화 비용 > 이득.

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

@@ -0,0 +1,145 @@
+# PR #134 — [로또 2단계] 제리
+
+- **Reviewee:** [@jerry8282](https://github.com/jerry8282)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/134
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 34
+
+## 잘한 점 (설계 관점)
+
+- **`LottoGeneratorType` 인터페이스 + `AutoLottoGenerator`/`ManualLottoGenerator`** — Strategy 적용.
+- **`BonusNumber`/`PurchasePrice` `value class`** — 원시값 포장.
+- **`ConvertMachine` → `Mapper` 명명 변경** — 일반 어휘 채택.
+- **`@BeforeEach` setup으로 테스트 픽스처 분리** — 테스트 가독성 개선.
+- **README에 피드백 반영 흐름 명시** — 학습 과정 가시화.
+
+## 못한 점 (설계 관점)
+
+### 1. `ManualLottoGenerator`가 단순 `map { Lotto(it) }` 래퍼
+
+```kotlin
+class ManualLottoGenerator(private val manualLottoNumber: List<List<LottoNumber>>) : LottoGeneratorType {
+    override fun generateNumber(): List<Lotto> = manualLottoNumber.map { Lotto(it) }
+}
+```
+
+학생 자가 의문: "현재 ManualLottoGenerator의 역할은 단순히 받아온 값을 Lotto 객체로 감싸는 것뿐인데 이러면 단순히 LottoGenerator 부분에서 `map { Lotto(it) }`을 쓰는 것과 뭐가 다른 건지 모르겠어서 수동 로또 생성기를 전략 패턴으로 구분하는 건 오버엔지니어링이라고 판단해." 리뷰어 답: "해당 객체를 보면 Generator라는 생성자입니다. `수동으로 체크한 로또번호들을 로또라는 객체로 만들어 준다.`가 해당 Generator의 역할이겠군요. 현재 미션에서는 Generator가 큰 역할을 하지 않지만, Generator를 만듦으로서 `수동/자동 로또 생성에 대한 테스트`도 가능해지는 장점도 있겠군요." — 추상화의 *현재 가치*는 약해도 *테스트 격리 + 미래 확장*에서 살아남음.
+
+### 2. `View`가 `Lotto` 객체를 생성
+
+```kotlin
+fun readWinningNumbers(): Lotto {  // ⚠ View가 도메인 객체 반환
+    val lotto = readln().split(",").map { it.trim().toInt() }.map { LottoNumber(it) }
+    return Lotto(lotto)
+}
+```
+
+리뷰어: "Controller에서 Lotto 객체로 만들어 주던 것을 View의 책임으로 이동시키셨군요! 제리가 보시기에는 이전과 지금 두 코드를 비교했을 때, 구현에 대해서 전혀 모르는 사람이 보기에 어떤 것이 더 로직이 잘 이해되실 것 같나요? 일례로 기존에는 Controller만 보고 Controller의 로직과 어떤 객체들을 활용하는지 한눈에 들어오지만, View로 옮겨지면서 Lotto 객체를 생성하는지 확인해 보려면 View까지 댑스를 이동해야 하는군요!" 학생 수긍: "View 부분에서 validate를 진행한다고 생각하여 다시 controller 부분으로 옮겼습니다!"
+
+### 3. `LottoGenerator`가 *가게* 책임 + Generator 책임 혼합
+
+```kotlin
+class LottoGenerator(private val money: PurchasePrice) {
+    fun makeLottos(manualLottoAmount: Int, manualLottoNumbers: List<List<LottoNumber>>): List<Lotto> {. }
+    fun getAutoLottoAmount(manualLottoAmount: Int): Int {. }
+}
+```
+
+리뷰어: "돈을 받고 로또를 발행하는 역할을 하는군요! 해당 내용은 실제 로또 가게와 같은 역할을 하는군요. LottoGenerator로 되어 있다 보니, 밑에 생성 전략과 조금 네이밍에서 혼동이 올 수도 있겠다는 생각이 듭니다. 한 가지 더 고민해 보면 좋을 내용이 있습니다! 만약 로또 가게로 바뀐다면, 로또 가게에서는 구매한 사람이 자동을 몇 개 수동을 몇 개 구매했는지를 반드시 알아야 한다? 는 고민해 보면 좋을 것 같습니다." — *Store*와 *Generator*는 다른 추상.
+
+### 4. `AutoLottoGenerator`의 *치명적 버그*
+
+```kotlin
+class AutoLottoGenerator(private val autoLottoAmount: Int) : LottoGeneratorType {
+    override fun generateNumber(): List<Lotto> {
+        val lottoMachine = (LOTTO_MIN..LOTTO_MAX).shuffled().toMutableList()
+        val lotto = lottoMachine.take(6).map { LottoNumber(it) }
+        return List(autoLottoAmount) { Lotto(lotto) }  // ⚠ 모든 Lotto가 동일
+    }
+}
+```
+
+`shuffled()`가 *반복문 밖*에 있어서 *N장의 자동 로또가 모두 같은 번호*. 리뷰어: "저도 뭔가 이상해서 돌려보다 찾았는데, 반영을 잘 해 주셨군요!" + "해당 Generator에 대한 테스트가 있었다면, 출력값이 동일하게 나오는 버그는 사전에 발견할 수 있었겠군요!" — *테스트가 없는 Generator*는 *루프 안/밖 실수*를 잡지 못함.
+
+### 5. `AutoLottoGenerator`가 `LOTTO_SIZE` 상수 보유
+
+```kotlin
+class AutoLottoGenerator(.) {
+    companion object {
+        const val LOTTO_MIN = 1
+        const val LOTTO_MAX = 45
+        const val LOTTO_SIZE = 6
+    }
+}
+```
+
+리뷰어: "로또 갯수는 Lotto에 있는 게 나을 것 같다는 생각이 드는데, Generator에 선언을 하신 이유가 궁금합니다!" 학생 답: "처음에는 `KoreaLottoGenerator`라는 클래스여서 한국에 맞추어 있는 것이 맞다고 생각하여 넣었지만 현재는 `AutoLottoGenerator`로 바뀌어서 Lotto 객체에서 관리하는 것이 더 깔끔해 보입니다!" — *상수의 소유*는 *도메인 정체성*과 같이 옮겨가야 함.
+
+### 6. `LottoGenerator`/`AutoLottoGenerator`/`ManualLottoGenerator` — 네이밍 혼동
+
+```
+domain/service/LottoGenerator        ← 가게 역할
+domain/strategy/AutoLottoGenerator   ← 자동 전략
+domain/strategy/ManualLottoGenerator ← 수동 전략
+```
+
+리뷰어: "LottoGenerator로 되어 있다 보니, 밑에 생성 전략과 조금 네이밍에서 혼동이 올 수도 있겠다는 생각이 듭니다." — 세 객체 모두 *Generator*면 호출자가 *어느 단계*에 있는지 헷갈림.
+
+### 7. `LottoGenerator(money).getAutoLottoAmount(manualAmount).also { Validator(it) }` — *검증 흐름*이 코드에 안 보임
+
+```kotlin
+val manualLottoAmount = inputView.readManualLottoAmount()
+LottoGenerator(purchasePrice).getAutoLottoAmount(manualLottoAmount).also { ManualLottoAmountValidator(it) }
+manualLottoAmount
+```
+
+`also`로 검증을 *부수효과*로 처리. 검증 실패 시 예외는 발생하지만 *코드를 읽을 때 검증이 어디 있는지* 안 보임.
+
+### 8. `Mapper` 명명의 일반성 — 다른 게임 추가 시?
+
+리뷰어: "현재는 로또 게임만 있어서, Input / Output / Mapper라는 네이밍으로도 역할이 드러나지만 자동차 게임 등 모두 하나의 프로젝트에 있다면 어떤 네이밍이 좋을까요?" 학생: "패키지로 구분하는 것이 좋아 보입니다. controller/domain/view를 lotto 패키지로, 자동차 게임은 racingcar 패키지로." — *책임 분류는 패키지로*, *역할 명명은 도메인 어휘로*.
+
+### 9. `displayBuyLotto`가 Controller에서 변환 + 정렬 + join
+
+```kotlin
+private fun displayBuyLotto(lotto: List<Lotto>) {
+    outputView.printPurchasedLotto(lotto.map { ConvertMachine.toNumberList(it).sorted() }.joinToString("\n"))
+}
+```
+
+Controller가 *Lotto → List<Int> → sorted → joinToString*까지 처리. Lotto.toString() 또는 OutputView에서 표현 처리.
+
+## 리뷰어 의견 요지
+
+1. **단순 매핑 추상화도 *테스트 격리 + 미래 확장* 가치 보유** — 오버엔지니어링 판단은 *나중에* 가능, 처음 도입은 옵션 열어두기.
+2. **`Tell, Don't Ask` 적용은 *호출자 깊이*로 측정 가능** — Lotto 객체를 어디서 만드는지 확인하려고 View까지 들어가야 하면 위치 잘못됨.
+3. **상수의 소유는 도메인 정체성과 함께 이동** — `LottoSize`가 `LottoGenerator`인가 `Lotto`인가는 *Lotto의 정체성*에 속함.
+4. **테스트 없는 Generator는 *루프 버그* 잡지 못함** — `shuffled().take(6)`가 루프 밖에 있으면 N장이 모두 같은데, 그 사실을 모름.
+5. **`also` 검증은 *부수효과*** — 가독성↓, 실패 시 *왜* 던지는지 흐름에서 보이지 않음.
+6. **이름이 같은 단어 *Generator*가 다른 추상 단계에 있으면 혼동** — Store vs Strategy를 구분.
+7. **패키지로 도메인 분류, 이름으로 역할 분류** — `lotto/`, `racingcar/`가 도메인, `Mapper`/`Generator`가 역할.
+
+- **대표 인용:**
+  > Generator를 만듦으로서 `수동/자동 로또 생성에 대한 테스트`도 가능해지는 장점도 있겠군요. 또한 자동로또 등에 요구사항들이 추가된다면, 해당 Generator에서의 처리만으로 Controller 및 Lotto에 대해서는 특별한 수정이 필요하지 않을 수 있겠군요.
+  > — @Gyuil-Hwnag on `src/main/kotlin/domain/strategy/ManualLottoGenerator.kt`
+
+  > 이전과 지금 두 코드를 비교했을 때, 구현에 대해서 전혀 모르는 사람이 보기에 어떤 것이 더 로직이 잘 이해되실 것 같나요?
+  > — @Gyuil-Hwnag on `src/main/kotlin/controller/LottoController.kt`
+
+  > 로또 갯수는 Lotto에 있는 게 나을 것 같다는 생각이 드는데, Generator에 선언을 하신 이유가 궁금합니다!
+  > — @Gyuil-Hwnag on `src/main/kotlin/domain/strategy/AutoLottoGenerator.kt`
+
+  > 해당 Generator에 대한 테스트가 있었다면, 출력값이 동일하게 나오는 버그는 사전에 발견할 수 있었겠군요!
+  > — @Gyuil-Hwnag on `src/main/kotlin/domain/strategy/AutoLottoGenerator.kt`
+
+## 얻은 교훈
+
+- **단순 매핑이라도 *Strategy 인터페이스 보유*가 옵션을 열어둠**. 오버엔지니어링은 *추상의 무게*가 *현재 비용*을 넘을 때 진단 — 도입 비용이 1~2줄이면 *옵션 가치*가 자주 더 큼.
+- **객체 생성 *위치 추적 깊이*가 책임 위치의 신호**. Lotto 생성을 찾으려고 View까지 들어가야 한다면 그 책임은 *상위 흐름 객체*(Controller)에 있어야 정상.
+- **상수 소유 = 도메인 정체성 소유**. `LOTTO_SIZE`는 *어디서 발행하든 변하지 않는 Lotto의 본질* → Lotto.
+- **테스트 없는 Generator는 *루프 안/밖* 실수에 무력**. shuffled가 루프 밖에 있으면 N장이 모두 동일 — 출력 검증이 없으면 production에서야 발견.
+- ***부수효과(`also`) 검증*은 가독성 비용**. `LottoGenerator(price).getAutoAmount(x).also { Validator(it) }`는 *반환값이 검증되지 않은 것처럼 보이고* 실제로는 검증됨 — 흐름과 의도가 어긋남.
+- **이름이 같은 단어가 다른 추상 단계에 등장하면 *맥락 스위칭*** — *Store*(가게 행위)와 *Generator*(번호 생성 전략)는 다른 이름으로.
+- **패키지 = 도메인, 이름 = 역할**. `lotto/`, `racingcar/`가 도메인 폴더, `Mapper`/`Generator`가 역할명.
+- ***구매 패턴 알 필요성*은 *추상화 위치*에 따라 다름**. 학생 의견: "로또 가게는 사용자가 자동 몇 개 수동 몇 개 구매했는지 알 필요 없다. 자동 개수는 `AutoLottoGenerator`에서 직접 생성." — 책임을 *가장 가까운 객체*로 위임하는 사례.

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

@@ -0,0 +1,144 @@
+# PR #63 — [로또] 누누 로또 미션
+
+- **Reviewee:** [@jinuemong](https://github.com/jinuemong)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/63
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 26
+
+## 잘한 점 (설계 관점)
+
+- **`Lottos` 일급 컬렉션** — 컬렉션에 행위 (`matchLottos`).
+- **`enum class LottoPrize(matchNumbers, price, message)`** — 등수+상금+메시지 한 곳.
+- **`Range` 재활용** — `(1..45)`를 generator + Lotto 양쪽에서 import.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller에 도메인 로직 + View 호출 혼재
+
+```kotlin
+fun run() {
+    val charge = Veilfier.inputCharge()
+    val count = charge / Constant.LOTTO_PRICE.toInt()  // ⚠ 계산
+    purchaseCountMessage(count)
+    val lottos = makeLottos(count)
+.
+}
+```
+
+리뷰어: "이 로직도 controller가 아닌 model에서 수행해 보면 어떨까요? 출력은 Lottos의 결과를 한번에 모아서 해도 괜찮지 않을까요?" — *나누기*는 도메인, Controller는 *조립*.
+
+### 2. `Constant` god-folder
+
+```kotlin
+object Constant {
+    val LOTTO_NUM_RANGE = (1..45)
+    const val LOTTO_LEN = 6
+    const val LOTTO_PRICE = 1000.0
+}
+```
+
+리뷰어: "Constant는 너무 광범위한 역할을 할 수 있는 object인 것 같아요. 실제로 사용되거나 어울리는 model 내부에 선언해 주는 것은 어떨까요?" — *어떤 상수든 다*는 응집도 0.
+
+### 3. `insertCostMessage` — 동사 주체 모호
+
+```kotlin
+fun insertCostMessage() { println(REQUEST_PURCHASE_PRICE) }
+fun winningStatistics() { println(START_RESULT) }
+```
+
+리뷰어: "`insertCostMessage`라는 네이밍에서 insert의 주체는 누구일까요? `show`와 `insert` 각각의 케이스가 있는데 네이밍을 붙이신 기준이 궁금합니다." + "함수명은 동사형으로 시작되는 것이 일반적인 컨벤션입니다." — *insert*는 *값 입력* 행위. View가 *보여주기*면 `show`/`print`.
+
+### 4. `Veilfier` (의도: Verifier) — 명명 + 책임 혼합
+
+```kotlin
+object Veilfier {  // ⚠ typo
+    fun inputCharge(): Int {. }
+    fun inputWinning(): Lotto {. }
+    fun inputBonusNumber(): Int {. }
+}
+```
+
+리뷰어: "검증의 역할을 하기 때문에, verifier라고 지어 주신 것으로 생각돼요. 그런데, 함수를 잘 들여다보면 *검증 외에 값을 입력받는 꽤나 중요한 역할*이 같이 있습니다. 현재의 네이밍으로는 object가 하는 일을 충분히 설명하지 못하는 것 같아요." — 객체명이 *일부 책임*만 가리키고 *다른 책임은 가려짐*.
+
+### 5. `LottoPrize.getDetails(): Triple<Int, Int, String>`
+
+```kotlin
+fun getDetails(): Triple<Int, Int, String> = Triple(matchNumbers, price, message)
+```
+
+리뷰어: "Pair, Triple 등의 경우 first, second 등의 네이밍으로 접근할 수 있기 때문에 *필드가 무엇을 의미하는지 알기 어려워요*. 리턴 타입을 봐도 쉽게 값을 유추하기 어려운 점 또한 있습니다. 저는 대부분 data class를 선언해서 사용하곤 합니다!" — Pair/Triple은 *임시*, 영구 사용은 data class.
+
+### 6. `LottoPrize`에 `message` 필드
+
+```kotlin
+enum class LottoPrize(private val matchNumbers: Int, private val price: Int, private val message: String)
+```
+
+리뷰어: "model에서 message라는 필드를 가지고 있을 필요가 있을까요? message는 어느 단계에서 필요한 필드일까요?" — *출력 메시지*는 View의 책임, 도메인 enum에 포함되면 *표현 변경이 도메인 변경*.
+
+### 7. View가 model 깊은 내부 호출
+
+```kotlin
+fun calculationOfYield(prize: UserPrize, charge: Double) {
+    println(YIELD_RESULT.format(prize.prizeRateCalculate(prize.prizeCalculate(), charge)))
+}
+```
+
+리뷰어: "`prize.prizeRateCalculate(prize.prizeCalculate(), charge)` 해당 호출은 View에서 굳이 알지 않아도 될 내용 같아요. model의 세부 구현사항이 view에 종속되지 않도록 고민해 보시면 좋을 것 같아요. **디미터 법칙**에 대해서도 한번 학습해 보셔도 좋겠습니다!"
+
+### 8. `matchlottos` — camelCase 위반
+
+```kotlin
+fun matchlottos(.) {. }  // ⚠ matchLottos
+```
+
+리뷰어: "camel case 잘 지켜주세요!" — 컨벤션은 *코드 읽기 부담*에 영향.
+
+### 9. `class` vs `object` vs top-level function — 일관성
+
+리뷰어: "InputView, OutputView의 경우 top level function으로 선언해 주셨는데, 해당 클래스는 object로 선언해 주신 기준이 궁금합니다!" + "class와 object를 선언하는 기준이 무엇이신지 궁금합니다!" — *기준 없는 혼용*은 협업 시 인지 부담.
+
+### 10. 테스트 데이터가 인덱스 기반 — 가독성↓
+
+```kotlin
+private val lottos = Lottos(lottos = listOf(
+    Lotto(setOf(12, 11, 7, 8, 9, 10)),  // index 0: 보너스 당첨 안 됨
+    Lotto(setOf(1, 11, 7, 8, 9, 10)),    // index 1
+.
+))
+// 사용처
+assertThat(lottos.getLottos()[0].matchBonusNumber(winning)).isTrue()
+```
+
+리뷰어: "이렇게 적혀 있을 경우 실제로 어떤 값이 보너스가 당첨되는지를 이해하기 어렵고 매번 선언된 부분으로 올라가서 확인을 해야 할 것 같아요. 차라리, 보너스 당첨이 되는 경우와 되지 않는 경우 2가지만 숫자로 기재해 놓는 것은 어떨까요?" — *테스트 데이터*는 *그 테스트 안*에 의미 명시.
+
+## 리뷰어 의견 요지
+
+- **함수명 = 주체와 행위 일관성** — `insert*`/`show*`/`print*` 중 통일.
+- **객체명 = *전체 책임*을 가리켜야** — Verifier가 입력까지 하면 *이름이 가려짐*.
+- **Pair/Triple = *임시***, 영구는 data class.
+- **enum에 *표현 메시지*** = 도메인이 View 책임 침범.
+- **디미터 법칙** — `obj.a().b()` 체이닝 피하기.
+- **상수 god-folder = 응집도 0** — 도메인별 분리.
+- **테스트 데이터는 *테스트 안*에서 의미 표현** — 인덱스 기반 회피.
+
+- **대표 인용:**
+  > Constant는 너무 광범위한 역할을 할 수 있는 object인 것 같아요. 실제로 사용되거나 어울리는 model 내부에 선언해 주는 것은 어떨까요?
+  > — @vagabond95 on `src/main/kotlin/lotto/util/Constant.kt`
+
+  > model에서 message라는 필드를 가지고 있을 필요가 있을까요? message는 어느 단계에서 필요한 필드일까요?
+  > — @vagabond95 on `src/main/kotlin/lotto/model/LottoPrize.kt`
+
+  > `prize.prizeRateCalculate(prize.prizeCalculate(), charge)` 해당 호출은 View에서 굳이 알지 않아도 될 내용 같아요. **디미터 법칙**에 대해서도 한번 학습해 보셔도 좋겠습니다!
+  > — @vagabond95 on `src/main/kotlin/lotto/view/ResultView.kt`
+
+## 얻은 교훈
+
+- **함수명 *주체와 행위 일관성*** — `insert`/`show` 혼용은 *호출자가 매번 의도 추론*.
+- **객체명이 *전체 책임*을 가려야** — `Verifier`가 입력도 하면 이름 = *부분*. 책임이 늘면 *이름 갱신* 또는 *분리*.
+- **`Pair`/`Triple`은 일회용** — 도메인을 영구히 들고 다닐 거면 `data class`.
+- **enum의 *표현 필드*는 도메인 침범** — 메시지 형식은 View, enum에는 *분류·수치*만.
+- **디미터 법칙** — `prize.calc1(prize.calc2(), x)`처럼 *자기 자신*에 두 번 묻는 호출은 *외부 계산 노출*.
+- **Constant god-folder = 응집도 0** — 변경 빈도/소속이 다른 상수를 한 곳에 두면 *변경 영향* 흩어짐.
+- **테스트 데이터는 *테스트 안*에서 자명** — 인덱스로 묶어서 *위로 올라가야 의미를 알 수 있는* 구조 회피.

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

@@ -0,0 +1,148 @@
+# PR #89 — [누누] 2단계 로또
+
+- **Reviewee:** [@jinuemong](https://github.com/jinuemong)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/89
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @vagabond95 (스카이)
+- **라인 코멘트:** 21 (리뷰어 17 + 학생 4)
+
+## 잘한 점 (설계 관점)
+
+- **`sealed class` + `sealed interface` 구분** — 칭찬: "*sealed class와 sealed interface를 잘 구분하여 사용해 주셨네요* 👍".
+- **검증 분리 시도** — 비판도 같이 받음.
+- **`UserEvent` 도입 시도**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Verifier` *모호 + Controller 위치*
+
+```kotlin
+object Verifier {. }  // ⚠ controller 안
+```
+
+리뷰어: "해당 object는 사실상 *InputView와 밀접한 연관이 있어 보이는데요*, 1. *Verifier라는 이름은 너무 모호합니다. 검증하려는 대상이 명확히 드러나는 것이 좋을 것 같*아요. *모호한 이름을 가진 클래스는 모호한 역할을 가질 수 있기 때문에, 금방 비대해지고 유지보수가 어려워질 수* 있습니다. 2. *controller와 실질적인 연관이 없어 보여요. 다른 패키지로 이동*해 보면 어떨까요?" 
+
+### 2. `TreeSet` 사용 *의도 모호*
+
+리뷰어: "*Set이 아닌 TreeSet 타입으로 선언해 주신 이유가 있을까요*?" — `TreeSet` = *정렬 자동*. 의도 명시 없으면 *과한 자료구조*.
+
+### 3. `prize > 0`인데 `charge == 0` *비정상 상태에 0 반환*
+
+```kotlin
+fun calculateProfitRate(prize: Int, charge: Int): Double {
+    if (charge == 0) return 0.0  // ⚠ 비정상이지만 정상값 반환
+    return prize.toDouble() / charge
+}
+```
+
+리뷰어: "*우리는 수익률을 구해야 하고, prize 값이 온전한 상황일 때 charge가 0으로 전달이 된다면, 이는 비정상적인 상황이기 때문에 예외를 던지는 것이 더 적절*하지 않을까요? *단순히 0으로 리턴할 경우 추후에 무엇이 잘못된 것인지 확인하기 어려울 것* 같아요." — *비정상 = 예외* (논리 오류 처리).
+
+### 4. `LottoMessage` *util 패키지*에
+
+리뷰어: "*LottoMessage는 View에서만 활용이 되고 있는데요, util 패키지에 넣어 주신 이유가 있을까요*~?" 
+
+### 5. *보너스 번호 중복 검증 누락*
+
+리뷰어: "*보너스 번호가 기존 로또 번호와 겹치는지 검증이 필요*하지 않을까요?"
+
+### 6. `UserEvent` *역할 설명 요청*
+
+리뷰어: "*UserEvent의 역할에 대해 얘기*해 주실 수 있을까요~?"
+
+### 7. *로또 번호 1개 원시값 포장*
+
+리뷰어: "*로또 번호 1개에 대한 원시값 포장 클래스를 구현*해 보면 어떨까요? *코드를 재사용할 수 있는 부분들이 있을 것* 같습니다." — `LottoNumber` 권유.
+
+### 8. *함수 호출 순서 의존* — `plusAutoLottos` 먼저 호출되면 버그
+
+```kotlin
+class Lottos {
+    fun makeManualLottos(.) {. }
+    fun plusAutoLottos(.) {. }  // ⚠ 순서 의존
+}
+```
+
+리뷰어: "*plusAutoLottos가 먼저 호출되고, makeManualLottos가 호출되면 버그가 발생하지 않을까요*?"
+
+### 9. *수동/자동 구분 필요?* — Lottos 입장
+
+리뷰어 (힌트): "*힌트를 조금 드려보면, 수동으로 구입한 로또와 자동으로 구입한 로또를 Lottos 입장에서 구별할 필요가 있을지 고민*해 보면 좋을 것 같아요." — *Lottos는 같은 로또일 뿐*.
+
+### 10. `Lottos`가 `LottoGenerator` *의존*
+
+리뷰어: "*Lottos가 LottoGenerator의 의존성을 가지게 될 때 생기는 단점은 무엇이 있을까요*?"
+
+### 11. `List` 인자 + size 비교 = 검증 불충분
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    init { require(numbers.size == 6) }  // ⚠ 중복 검증 X
+}
+```
+
+리뷰어: "*List는 중복된 숫자가 들어갈 수 있기 때문에 size로 비교하여도 valid 체크가 됐다고 보기 어려울 것 같*아요. *설령 외부에서 중복된 숫자를 검증하고 List로 넘겨주었다고 하더라도, 해당 클래스 기준에서는 이를 알지 못하므로 추가적인 검증이 필요*하다고 생각합니다." — *책임의 자급자족*.
+
+### 12. *생성자 인자 = List?* — Set 권유
+
+리뷰어: "*생성자로 주입받는 컬렉션이 'List'일 필요가 있을까요*?"
+
+### 13. *리턴 타입이 구체 구현체* — 인터페이스 권장
+
+```kotlin
+fun get(): TreeSet<Int> =.  // ⚠ 구체 타입 노출
+```
+
+리뷰어: "*배운 내용을 바로 학습해 주시는 것 좋*습니다 👍 다만, *리턴 타입이 인터페이스 타입이 아닌 구체적인 구현체의 타입으로 정의된다면 추후에 해당 컬렉션의 Set이 다른 구현체로 바뀌었을 때 해당 함수를 사용하는 모든 곳에서 변경이 발생*하게 됩니다. *변경에 유연하게 대처할 수 있도록 리턴 타입을 변경*해 보는 것은 어떨까요?" — *Liskov*: *반환은 super, 인자는 sub*.
+
+### 14. *검증/예외 패키지 분리* = god-object 위험
+
+리뷰어: "*검증을 해 주는 역할을 '분리'하는 시도 좋*습니다! 다만, *UserInputVerifier, UserEvent, ExceptionManager의 코드들이 조합되어 또 하나의 Controller가 만들어진 것* 같습니다. *입력에 대한 검증이 필요하다면 InputView, 모델 자체의 검증이 필요하다면 해당 모델에서 '스스로' 수행*해 보면 어떨까요? 이렇게 *일반적인 상황에 대해 (검증, 예외 등) 따로 분리하여 클래스로 관리하는 경우, 1) 코드가 금방 비대해지기 쉽고, 2) 이로 인해 필요한 코드를 찾기가 어렵고 유지보수하기 어려운 구조*가 되기 쉽습니다. [저의 경우]에도 한 번에 *보너스 번호에 대한 검증 로직을 찾지 못*했네요 ^^;. 이것은 제 부주의라고 하더라도, *추후에 요구사항이 추가되어 더 복잡한 모델, 더 복잡한 검증이 들어가면 현재 코드는 전반적인 구조를 이해하기 쉽지 않을 것* 같아요. *이러한 코드들을 해체하는 작업도 한 번 고려가 필요*할 것 같습니다."
+
+### 15. `ManualLottoCount` 네이밍
+
+리뷰어: "*ManualLottoCount라고 로또 개수를 드러내주면 더 역할이 명확하게 드러날 것* 같습니다 :)"
+
+### 16. `run` *함수 분리 필요*
+
+리뷰어: "*컨트롤러의 run 코드가 수행하는 일을 적절한 단위의 함수로 분리가 필요*할 것 같아요."
+
+## 리뷰어 의견 요지
+
+- **`Verifier` *모호 + 패키지 위치* 잘못**.
+- **`TreeSet` *의도 명시***.
+- **비정상 *예외 던지기*** (sentinel 0 반환 X).
+- **`LottoMessage` *View 패키지에***.
+- **보너스 번호 중복 검증**.
+- **원시값 포장 (`LottoNumber`)**.
+- **함수 *호출 순서 의존* 회피**.
+- **수동/자동 구분 *Lottos 입장* 무의미**.
+- **`List` size 비교 검증 불충분**.
+- **리턴 타입 *인터페이스 권장***.
+- **검증/예외 분리 = *또 다른 Controller 만들기***.
+
+- **대표 인용:**
+  > 검증을 해 주는 역할을 '분리'하는 시도 좋습니다! 다만, *UserInputVerifier, UserEvent, ExceptionManager의 코드들이 조합되어 또 하나의 Controller가 만들어진 것* 같습니다.
+  > — @vagabond95 on `src/main/kotlin/lotto/controller/UserInputVerifier.kt`
+
+  > 모호한 이름을 가진 클래스는 *모호한 역할을 가질 수 있기 때문에, 금방 비대해지고 유지보수가 어려워질 수* 있습니다.
+  > — @vagabond95 on `src/main/kotlin/lotto/controller/Verifier.kt`
+
+  > 단순히 0으로 리턴할 경우 추후에 *무엇이 잘못된 것인지 확인하기 어려울 것* 같아요.
+  > — @vagabond95 on `src/main/kotlin/lotto/domain/LottoStatistics.kt`
+
+  > 리턴 타입이 인터페이스 타입이 아닌 구체적인 구현체의 타입으로 정의된다면 *추후에 해당 컬렉션의 Set이 다른 구현체로 바뀌었을 때 해당 함수를 사용하는 모든 곳에서 변경*이 발생하게 됩니다.
+  > — @vagabond95 on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+## 얻은 교훈
+
+- **`Verifier`/`Validator` god-name** = *책임 비대*.
+- **`TreeSet` *의도 명시*** — *정렬 필요*면 명시, 단순 *Set 의미*면 `HashSet`/`LinkedHashSet`.
+- **비정상 = *예외*** — *논리 오류*는 *sentinel 반환*보다 *예외*가 *디버깅 가능*.
+- **`Message` *View 패키지*** — UI 어휘는 *Domain/util* X.
+- **함수 *호출 순서 의존 = 시간 결합***. *순서가 invariant*면 *명시 또는 통합*.
+- **수동/자동 *내부 구분 X*** — *Lottos*는 *발급 후 동등*. *입력 시 분기*만.
+- **`List` *size 비교* ≠ 중복 검증** — *자료구조*가 *invariant 표현*. `Set`이 자연.
+- **리턴 타입 *인터페이스*** — *Liskov*. *구체 구현체* 노출은 *호출자 결합*.
+- **검증/예외 *분리 클래스* = 또 다른 Controller** — 도메인이 *자기 검증*. 패턴.
+- **`ManualLottoCount` *역할 드러나는 네이밍*** — `Count`보다 *수식어 + Count*.
+- **`run` *함수 분리 적정 단위*** — PR #131 *분리 vs 분해* 경계.

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

@@ -0,0 +1,52 @@
+# PR #128 — [로또 1단계] 포르 미션
+
+- **Reviewee:** [@jiyuneel](https://github.com/jiyuneel)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/128
+- **단계:** 1단계
+- **리뷰어:** @krrong
+- **라인 코멘트:** 58
+
+## 잘한 점 (설계 관점)
+
+- **`WinningLotto`, `LottoNumber` 분리**.
+- **`Set`으로 중복 제거 + 교집합 시도**.
+- **테스트명 명확**.
+
+## 못한 점 (설계 관점)
+
+### 1. feature-envy — WinningLotto가 Lotto의 numbers 꺼내 비교
+
+```kotlin
+class WinningLotto(.) {
+    fun isWinning(lotto: Lotto): Boolean {
+        return winningNumbers.lottoNumbers.contains(.)  // ⚠ Lotto 내부 접근
+    }
+}
+```
+
+> `Lotto`에게 x가 포함되어 있어? 하고 메시지를 던져보는건 어떨까요?
+
+→ `lotto.contains(number)` 메시지.
+
+### 2. count 함수 미활용
+
+```kotlin
+val matchCount = lotto.numbers.filter { it in winningNumbers }.size  // ⚠ filter().size
+```
+
+→ `count {. }` 한 줄.
+
+### 3. 등수 테스트가 1등만
+
+```kotlin
+@Test fun `1등 매칭`() {. }
+// ⚠ 2,3,4,5등, 꽝 미테스트
+```
+
+> 다른 등수들도 테스트해보면 좋을 것 같네요!
+
+## 얻은 교훈
+
+- **Tell-Don't-Ask** 적용 — `lotto.contains(number)`로 메시지.
+- **컬렉션 함수의 의도 명시** — `filter().size` < `count {}`.
+- **enum 케이스 전부 테스트** — 각 등수가 다른 비즈니스 분기.