oh-my-oop 0.2.0

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

@@ -0,0 +1,75 @@
+# PR #139 — [로또 2단계] 미플 미션
+
+- **Reviewee:** [@HamBeomJoon](https://github.com/HamBeomJoon)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/139
+- **단계:** 2단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 51
+
+## 못한 점 (설계 관점)
+
+### 1. View가 도메인 검증 (로또 개수 범위)
+
+```kotlin
+fun readManualCount(maxCount: Int): Int {
+    val count = readln().toInt()
+    require(count in 0..maxCount)  // ⚠ View가 도메인 invariant 검증
+}
+```
+
+> 로또 개수 범위에 대한 검증 로직은 뷰의 로직일까요?
+
+→ 도메인 invariant는 도메인 init.
+
+### 2. `Set`/`List` 혼용
+
+```kotlin
+fun match(lotto: Lotto): Rank {
+    val winningSet = winning.numbers.toSet()  // ⚠ 매번 변환
+    return.
+}
+```
+
+> 왜 Set으로 변환하는 함수가 들어가게 되었는지 궁금해요!
+> 여기가 `List`로 바뀐 이유는 편의성 때문일까요?
+
+→ 자료구조 선택 = 호출 위치마다 다르지 않게. 도메인 객체가 *적절한 자료구조*를 내부 보유.
+
+### 3. `Pair`로 자동/수동 로또 반환
+
+```kotlin
+fun purchaseLottos(.): Pair<LottoTicket, LottoTicket> {. }
+```
+
+> `Pair`를 사용할 수도 있어요! (긍정)
+> 구조 분해 활용 👍
+
+학생이 자가 의문:
+
+> 1. getResult 함수에 넘겨줄 때 LottoTicket 리스트를 합쳐서 넣어주기
+> 2. 자동 로또와 수동 로또를 구분해서 넣어주기
+> 어떤 방식이 더 좋을까요?
+
+→ 합쳐서 넘기는 게 *호출자 단순*, 구분해서 넘기는 게 *통계 표시 시 유리*. 둘 중 호출 패턴이 결정.
+
+### 4. `value class` 사용 의도?
+
+> `value class`는 어떤 특징이 있을까요?
+
+→ inline + 단일 값 wrapper. data class보다 런타임 오버헤드 적음.
+
+### 5. View 테스트 — 요구사항 아님
+
+```kotlin
+class InputTest {. }
+```
+
+> 이번 미션에서 View 테스트는 요구사항이 아니었다고 하더라구요
+
+→ Controller/View 테스트는 *통합 테스트* 자리.
+
+## 얻은 교훈
+
+- **자료구조 변환을 호출 위치마다 하지 말 것**. 도메인이 *적절한 형태*로 보관 (Set vs List).
+- **자동/수동 분리 vs 합치기 = 호출 패턴에 따라**. 통계 표시에 분리 필요하면 분리, 단순 매칭이면 합치기.
+- **View 테스트 회피** — 단위 테스트 부적합, 통합 테스트 자리.

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

@@ -0,0 +1,21 @@
+# PR #76 — [로또] 팡태 1단계 미션
+
+- **Reviewee:** [@Hevton](https://github.com/Hevton)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/76
+- **단계:** 1단계
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 12
+
+## 잘한 점
+
+- **`TicketGenerationStrategy` 전략 패턴** — 칭찬.
+
+학생:
+
+> 전략 패턴을 쉽게, 확장성있게 이용할 수 있도록 제공하고 있는가
+> 거창하게 전략 패턴이라고 말을 하지만, 실상은 티켓을 발행하는 로직을 interface 로 추상화한게.
+
+## 얻은 교훈
+
+- **전략 패턴의 본질 = 인터페이스 추상화** + 구현체 교체.
+- **거창한 이름 vs 단순 추상화** — 패턴 이름에 매몰되지 말고 본질에 집중.

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

@@ -0,0 +1,122 @@
+# PR #92 — [로또] 팡태 2단계 미션
+
+- **Reviewee:** [@Hevton](https://github.com/Hevton)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/92
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @ghojeong (파이로)
+- **라인 코멘트:** 38
+
+## 잘한 점 (설계 관점)
+
+- **`MixedTicketGenerationStrategy` 도입** — 자동/수동 통합 전략. `Ticket` 단위 발행이라는 도메인 제약을 인식.
+- **유효성 검증을 `LotteryPurchasePattern`로 캡슐화 시도** — 수동/자동 수 계산 + 검증을 한 곳에.
+- **`safe {. }` helper로 컨트롤러 흐름 통일** — 모든 입력을 동일한 패턴으로 감쌈.
+- **자가 의문 PR에 풍부히 명시** — 학생이 "처음부터 다시 구성해야 될지도 모르겠다"는 깨달음을 PR에 적음.
+
+## 못한 점 (설계 관점)
+
+### 1. 통합 전략 도입 후에도 `RandomTicketGenerationStrategy` 잔존
+
+```kotlin
+class RandomTicketGenerationStrategy(private val amount: Amount) : TicketGenerationStrategy {
+    override fun issueTicket(): Ticket {
+        val lotteries = mutableListOf<Lottery>()
+        repeat(amount.money / LOTTO_TICKET_PRICE) {
+            lotteries.add(Lottery(RandomLotteryGenerator.generateNumbers()))
+        }
+        return Ticket(lotteries, amount, LotteryPurchasePattern(0, lotteries.size))
+    }
+}
+```
+
+리뷰어: "만약 MixedTicketGenerationStrategy로 충분하다고 생각하셨다면, 기존의 RandomTicketGenerationStrategy를 왜 남겨두셨는지 궁금합니다. 추후에 어떻게 활용하겠다는 계획이 있으시나요?" 학생: "프로덕션이 아니라 학습 과정이라 흔적으로 남겨놓을까 생각" — 학습용은 양해될 수 있으나, *통합 후 남은 추상*은 미래 동료에게는 "어느 걸 써야 할지" 신호.
+
+### 2. `ExplicitTicketGenerationStrategy`는 *테스트 의존성 분리* 관점에서 살아남음
+
+리뷰어: "MixedTicketGenerationStrategy는 로또 티켓 발행의 핵심 로직 중 하나이고, 언제든 다른 개발자가 만든 Strategy로 변경될 수 있습니다. 단, 다른 Strategy로 변경되었을 때 팡태님이 작성하신 코드의 테스트가 실패해서는 안됩니다." — 테스트가 *프로덕션 전략*에 의존하면 프로덕션 변경 시 테스트 함께 깨짐. 테스트 전용 Strategy는 *의존성 차단*의 도구.
+
+### 3. `LotteryPurchasePattern` = data 컨테이너 + 검증
+
+```kotlin
+class LotteryPurchasePattern(val manualLottoCount: Int, val autoLottoCount: Int) {
+    companion object {
+        fun ofManual(amount: Amount, input: String): LotteryPurchasePattern {. }
+    }
+}
+```
+
+리뷰어 분석: "유효성 검사는 현재 객체가 상태를 갖기 전 '생성'할 때 적용되는 로직이고, 객체가 실제로 상태를 가진 후에 갖게 되는 로직은 현재 전혀 없습니다. 상태를 갖기 전의 로직은 극단적으로 말해서, 외부 유틸의 static 메서드로 제공되어도 아무 문제가 없습니다." — "구매 패턴"이라는 이름이라면 *현재 수동/자동이 가능한 상태인지 알려주는* boolean이나 *실제로 발행하는 로직*이 있어야 객체. 지금은 *struct + factory*에 가까움.
+
+### 4. Controller에 if/매직넘버 분기
+
+```kotlin
+private fun issueTicket(amount: Amount, lotteryPurchasePattern: LotteryPurchasePattern): Ticket {
+    var manualLotteryCandidates = listOf<String>()
+    if (lotteryPurchasePattern.manualLottoCount > 0) {
+        manualLotteryCandidates = readManualLotteryCandidates(lotteryPurchasePattern)
+    }
+.
+}
+```
+
+리뷰어: "모든 종류의 매직넘버 상수화 부탁드립니다. 그리고 Controller에 조건문 혹은 반복문이 있을 경우, 가능한 model의 테스트 가능한 비즈니스 로직으로 옮길 수 있도록 부탁드립니다." — Controller의 분기는 *조립*이지 *판단*이 아님. `lotteryPurchasePattern.hasManual()` 같은 메서드로 옮겨야 단위 테스트 가능.
+
+### 5. `safe {. }` — try-catch 일괄 흡수
+
+```kotlin
+val amount = safe { readAmount() }
+val lotteryPurchasePattern = safe { readPurchasePattern(amount) }
+```
+
+리뷰어가 길게 안내: "안드로이드 개발 시에는 핸들링되지 않는 모든 예외를 던지지 않도록 한다. 가능한 default 값이 반환되면 좋고, default 값이 없다면 null이 반환되어야 합니다. null 대신 default 값을 선호하는 이유는 null이 NullException 예외를 발생시켜, 마찬가지로 앱이 크래시 나게 만들 위험이 있기 때문입니다." — `safe`는 흐름을 통일했지만, *어떤 오류가 어떻게 핸들링되는지*는 호출자에게 보이지 않음 — 단지 "예외가 어딘가에서 사라진다."
+
+### 6. 가변 리스트로 누적
+
+```kotlin
+private fun generateRandomLotteries(): List<Lottery> {
+    val lotteries = mutableListOf<Lottery>()
+    repeat(lotteryPurchasePattern.autoLottoCount) {
+        lotteries.add(Lottery(RandomLotteryGenerator.generateNumbers()))
+    }
+    return lotteries
+}
+```
+
+리뷰어 제안: `List(count) { Lottery(.) }`로 *불변 리스트*. *누적*이라는 절차가 *생성*이라는 의도로 바뀜.
+
+### 7. `LotteryPurchasePattern`의 이름과 실체 불일치
+
+학생 의도: "수동 로또: 3, 자동 로또: 2 라는 결과를 계산해 주면서 각 값 또한 멤버로 갖고 있는 '구매 패턴에 대한 책임을 갖는' 클래스." 리뷰어: "이 숫자 데이터는 캡슐화되어 접근할 수 없고, 실제로 로또를 발행하거나, … boolean 값을 계산해서 보여주지 않을까 기대했습니다." — *Pattern*은 행위/규칙을 시사 — 단순 컨테이너라면 `LottoOrder` 같은 명사형.
+
+## 리뷰어 의견 요지
+
+1. **통합 추상 도입 후 *이전 추상* 정리** — 학습용으로 남겨도, 미래 동료가 "왜 살아 있나"를 묻는다.
+2. **테스트 의존성은 프로덕션 의존성과 분리** — 테스트 Strategy(`Explicit`)는 프로덕션이 어떻게 바뀌어도 깨지지 않는 *고정 기준*.
+3. **"객체"는 *상태 + 그 상태로 하는 일*** — 생성 시 검증만 있는 클래스는 C struct 수준. 클래스로 만들었으면 *상태로 무언가를 해야* 한다.
+4. **"앱이 죽지 않게"가 예외 처리의 1차 목표** — *논리 오류*/*비논리 오류* 구분에 매몰되지 말고, *던져지지 않는 길*을 먼저 모색.
+5. **테스트 코드 작성 가능성 = 논리 오류 판별 기준** — 학생이 헷갈리는 *논리 오류 vs 비논리 오류*에 대해, 리뷰어가 실용적 기준을 제시 — "테스트 코드로 작성 가능하면 논리 오류".
+6. **Controller에 조건문 = 테스트 불가 로직** — 조건은 도메인 메서드로 내려야 단위 테스트로 검증 가능.
+
+- **대표 인용:**
+  > 만약 MixedTicketGenerationStrategy로 충분하다고 생각하셨다면, 기존의 RandomTicketGenerationStrategy를 왜 남겨두셨는지 궁금합니다.
+  > — @ghojeong on `src/main/kotlin/utils/RandomTicketGenerationStrategy.kt`
+
+  > 객체는 상태(멤버)와 그에 따른 로직(메서드)를 통해 그 역할과 책임이 나타납니다. 유효성 검사는 현재 객체가 상태를 갖기 전 "생성"할 때 적용되는 로직이고, 객체가 실제로 상태를 가진 후에 갖게 되는 로직은 현재 전혀 없습니다.
+  > — @ghojeong on `src/main/kotlin/model/LotteryPurchasePattern.kt`
+
+  > 안드로이드 개발 시에는 핸들링되지 않는 모든 예외를 던지지 않도록 한다. 라고 생각해 주세요.
+  > — @ghojeong on `src/main/kotlin/controller/LotteryController.kt`
+
+  > 무엇이 논리 오류인지, 아닌지 판별하기 어려우시면, 저는 "테스트 코드"를 기준으로 판별하라고 하고 싶습니다.
+  > — @ghojeong on `src/main/kotlin/controller/LotteryController.kt`
+
+## 얻은 교훈
+
+- **통합 추상 후 이전 추상 정리**. 통합 객체와 개별 객체가 공존하면 사용자가 *둘 중 무엇*을 써야 할지 매번 판단해야 함. 학습 흔적은 README/위키로.
+- **테스트 Strategy는 *분리* 자산**. 프로덕션 Strategy를 테스트에 그대로 쓰면 프로덕션 변경이 테스트 검증을 깬다. 테스트 전용 객체는 *시간에 따라 안 변하는 기준점*.
+- **"클래스"는 *상태로 무엇을 하는가* 가 있어야**. 생성 검증만 있는 클래스는 C struct + factory. 진짜 객체가 되려면 *상태를 사용한 메서드*가 있어야 함 — 없으면 `data class`로 솔직히.
+- **이름이 *Pattern*/*Manager*/*Handler*면 *행위*가 있어야**. 명사형 이름과 실체가 *컨테이너*면 동료가 두 번 본다.
+- **Controller에 조건/반복 ≈ 테스트 불가 로직**. Controller는 *조립*만, 분기/반복은 도메인 메서드로 내림.
+- **예외 처리는 *논리/비논리 분류*가 아니라 *크래시 방지*가 1차 목표**. 분류는 *유용한 휴리스틱*이지 *교조*가 아님.
+- **테스트 가능성 = 논리 오류 판별 기준**. "이 오류가 발생하는 상황을 단위 테스트로 쓸 수 있는가?" — 가능하면 논리 오류 → 그 자체로 *명시적 핸들링*이 가능.
+- **콘솔 프로그램 ≠ Android 앱**. sealed class 결과 타입은 *옵저버 패턴이 있는 곳*에서 진가가 발휘됨. 콘솔에서는 try-catch + 재시도가 더 단순할 수 있음 — 패턴은 *맥락*에 종속.

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

@@ -0,0 +1,110 @@
+# PR #100 — [로또] 악어 2단계 미션
+
+- **Reviewee:** [@Hogu59](https://github.com/Hogu59)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/100
+- **단계:** 2단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 66
+
+## 잘한 점 (설계 관점)
+
+- **`Money` 검증 + `Count` 값 객체 도입**.
+- **`toIntOrNull() + require`** — 코틀린 idiom.
+- **1단계 피드백 흡수** — readln()을 InputView로 이동.
+
+## 못한 점 (설계 관점)
+
+### 1. try-catch 잔존 (`runCatching` 미적용)
+
+```kotlin
+fun readCount(): Int {
+    return try {
+        InputView.readCount()
+    } catch (e: IllegalArgumentException) {
+        println(e.message)
+        readCount()
+    }
+}
+```
+
+> 이번 미션 힌트에서 `try-catch`를 사용하지 않고 다른 방법을 사용하도록 적혀져 있는데, 과연 그말이 `runCatching`을 사용하도록 한 것인지 고민해보시면 좋을 것 같습니다.
+
+→ try-catch 회피 ≠ runCatching 사용. *예외 자체를 안 던지는* 설계가 더 본질.
+
+### 2. 수동 로또 입력이 Controller에
+
+```kotlin
+class LotteryController {
+    private fun inputManualLotteries(count: Count): List<Lottery> {
+        return List(count.value) {
+            val numbers = InputView.readWinningNumbers()  // ⚠ Controller가 직접 수동 입력
+            Lottery.of(numbers)
+        }
+    }
+}
+```
+
+> 수동으로 로또를 입력받는 부분이 과연 LottoController의 역활인지 고민해보시면 좋을 것 같습니다!
+
+→ 수동 로또 *생성 정책*은 도메인 (`ManualLotteryGenerator`). Controller는 *호출*만.
+
+### 3. `Lottery`에서 빈 입력 검증
+
+```kotlin
+class Lottery(val numbers: List<LotteryNumber>) {
+    init {
+        require(numbers.isNotEmpty()) { ERROR_BLANK_INPUT }  // ⚠ 도메인이 입력 형식 검증
+.
+    }
+}
+```
+
+> ERROR_BLANK_INPUT은 빈칸이 들어왔을 때의 오류를 검증하는 내용인데, 해당 내용이 Lottery에서 검증을 하는 것이 맞을까 라는 생각이 듭니다!
+
+→ 빈 입력은 UI 형식 검증 (InputView). Lottery 도메인은 *6개 + 1-45 + 중복 없음*만.
+
+### 4. data class vs value class 차이 자가 의문
+
+```kotlin
+data class Count(val value: Int) {. }
+```
+
+> data class와 value class가 존재하는데, 그 둘은 어떤 차이점을 가지고 있을까요?
+
+→ Count(Int) 같은 단일 값 wrapper는 value class가 인라인 이점.
+
+### 5. test fixture 개념 미인지
+
+```kotlin
+class CountTest {
+    @Test fun.() { val count = Count(5). }
+    @Test fun.() { val count = Count(3). }
+    // ⚠ 매번 새 인스턴스 생성, 중복
+}
+```
+
+> 테스트 코드에는 test fixture 라는 개념이 존재하는데 내용을 살펴보고 해당 내용을 어떻게 수정하면 좋을지 고민해보시면 좋을 것 같다는 생각이 듭니다!
+
+→ `@BeforeEach`로 fixture 준비.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 가르침:
+
+1. **try-catch 회피의 진짜 의미** — runCatching 사용이 아닌 *예외를 던질 일 자체를 줄이기*.
+
+2. **검증의 3분류 재확인** — 빈 입력 = UI, 도메인 = 6개/1-45/중복.
+
+3. **수동 입력 정책의 자리** — Controller에서 도메인으로.
+
+- **대표 인용:**
+  > 이번 미션 힌트에서 `try-catch`를 사용하지 않고 다른 방법을 사용하도록 적혀져 있는데, 과연 그말이 `runCatching`을 사용하도록 한 것인지 고민해보시면 좋을 것 같습니다
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/controller/LotteryController.kt`
+
+## 얻은 교훈
+
+- **"try-catch 회피"의 본질 = 예외 발생을 *설계로* 줄이기**. runCatching은 *catch의 다른 표현*. 그보다 도메인이 *유효한 값만 받게*.
+- **수동/자동 로또 생성 정책** = 도메인 (Generator 구현체). Controller는 어떤 Generator를 쓸지 *선택*만.
+- **value class > data class (단일 값)** — racingcar 카드에서도 언급. lotto에서도 동일.
+- **`@BeforeEach` test fixture** — 같은 setup 반복 제거.

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

@@ -0,0 +1,84 @@
+# PR #68 — [로또] 악어 step1 미션 제출합니다
+
+- **Reviewee:** [@Hogu59](https://github.com/Hogu59)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/68
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 64
+
+## 잘한 점 (설계 관점)
+
+- **`Lottery`, `LotteryNumber`, `Profit`, `LotteryRankEvaluator`, `LotteryGenerator` 분리**.
+- **`init {}` 블록 검증** — invariant.
+- **`companion object` 상수**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Profit` class 사용 이유 모호
+
+```kotlin
+class Profit(val rate: Double) {
+    fun show(): String =.
+}
+```
+
+> Profit을 Class로 구현하신 이유가 궁금합니다! Profit이 이윤이라는 의미에서 좋기는 하나 다른 좀 더 친숙한 표현이 있는지도 고민해봐도 좋을 것 같습니다.
+
+→ `Profit` (이윤) vs `ProfitRate` (수익률) — lotto 도메인에서는 후자가 의도. 이름이 정확해야 의도 표현.
+
+### 2. `LotteryRankEvaluator` 인터페이스 미적용
+
+```kotlin
+class LotteryRankEvaluator(.) {
+    fun evaluate(.): Rank =.
+}
+```
+
+> LotteryRankEvaluator는 확장성을 interface로 구현해봐도 좋겠다는 생각이 드네요.
+
+→ "Evaluator" 같은 행위 클래스는 인터페이스 후보. 등수 계산 정책이 바뀔 가능성 있음.
+
+### 3. 상수화 과잉
+
+```kotlin
+class LotteryNumber {
+    companion object {
+        const val MIN_LOTTERY_NUMBER = 1
+        const val MAX_LOTTERY_NUMBER = 45
+    }
+    init { require(value in MIN_LOTTERY_NUMBER..MAX_LOTTERY_NUMBER) }
+}
+```
+
+> MIN_LOTTERY_NUMBER, MAX_LOTTERY_NUMBER를 상수로 뽑아서 관리하는 것도 좋지만, 자칫 지나친 상수화는 가독성을 떨어뜨릴 수도 있는 것 같습니다.
+
+→ trade-off — 1, 45 같이 도메인 의미가 *영구한* 숫자는 상수화 가치 있음. 하지만 도메인 무지인이 봐도 1, 45가 *로또 번호 범위*라는 게 명확하면 인라인도 OK.
+
+### 4. 분기 기준 자가 의문
+
+학생 의문 (PR 본문):
+
+> 또한 함수를 구분할 때 어떤 기준을 가지고 구분하고 계시는지 궁급합니다.
+
+→ 리뷰어가 직접 답을 안 주고 학생 스스로 기준 정립 유도.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 가르침:
+
+1. **`Profit` vs `ProfitRate`** — 이름이 정확해야 도메인 의도 표현.
+
+2. **상수화 trade-off** — 의미 명확한 매직넘버는 인라인도 가능.
+
+3. **Evaluator 인터페이스 확장성**.
+
+- **대표 인용:**
+  > MIN_LOTTERY_NUMBER, MAX_LOTTERY_NUMBER를 상수로 뽑아서 관리하는 것도 좋지만, 자칫 지나친 상수화는 가독성을 떨어뜨릴 수도 있는 것 같습니다
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/model/LotteryNumber.kt`
+
+## 얻은 교훈
+
+- **이름의 정확성 = 도메인 의도 표현**. `Profit`보다 `ProfitRate`가 lotto에 더 맞음.
+- **상수화도 *과잉*이 있음**. 1, 45가 *로또 번호 범위*임이 자명한 컨텍스트라면 인라인도 OK. 무조건 상수화 ≠ 좋은 코드.
+- **"Evaluator/Calculator" 같은 행위 객체** = 인터페이스 후보. 정책 교체 가능성 시사.

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

@@ -0,0 +1,176 @@
+# PR #60 — [예니] 1단계 로또
+
+- **Reviewee:** [@JoYehyun99](https://github.com/JoYehyun99)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/60
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 43 (리뷰어 27 + 학생 16)
+
+> *PR #75 sh1mj1*과 같은 말리빈. *비유와 시 (詩)적 표현*으로 가르치는 스타일.
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` 값 객체** — 리뷰어 칭찬: "로또 번호를 *값 객체로 만들어 주셨네요* 👍".
+- **`LottoNumber` 캐싱** — 칭찬: "*캐싱 기능을 잘 구현해 주셨네요* 👍".
+- **전략 패턴 분리** — 칭찬: "*전략 패턴을 활용해서 랜덤의 요소를 잘 분리해 주셨네요* 👍".
+- **`LottoNumber` 값 객체 표현** — Lotto 안에서 *원시값 → 값 객체*.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller에 *비교 로직* — 도메인 로직 누출
+
+```kotlin
+fun run() {
+    val results = lottos.map { lotto -> compareWithWinning(lotto) }  // ⚠
+}
+```
+
+리뷰어: "*로또와 당첨번호를 비교해서 결과를 만들어내는 이 로직은 도메인 로직*이네요 :) *도메인 객체에 이 역할을 부여*해 보는 건 어떨까요?"
+
+### 2. `LotteryResult` *검증만, 행위 부재*
+
+```kotlin
+class LotteryResult(.) {
+    init { require(.) }
+    // ⚠ 행위 없음
+}
+```
+
+리뷰어: "*이 객체는 생성 검증을 하는 것 말고 큰 역할을 가지고 있지 않*네요. *이 객체가 맡을 만한 일이 무엇인지 찾아 이 객체에게 부여*해 보는 건 어떨까요? *이 객체에게 메시지를 던져 시킬 만한 일*이 무엇이 있을까요?"
+
+### 3. `check~` 일관성 없는 반환
+
+```kotlin
+fun checkSize(): Int = numbers.size
+fun checkDuplicate(): Boolean =.
+```
+
+리뷰어: "*check~로 시작하는데 어떤 건 숫자를 반환하고, 어떤 건 Boolean을 반환*하고 있네요! *check~ 이 메서드들을 보고 드는 생각은, 무언가 체크는 하겠구나. 정도이고, 무언가를 반환할 거라는 생각이 들지는 않았*어요. *더 명확한 이름을 지어보는 건* 어떨까요?"
+
+### 4. *List vs Set* — 자료구조로 invariant 표현
+
+리뷰어: "*Set을 활용해 보는 건 어떨까요*?" — PR #77 (hxeyexn)과 같은 *중복 방지 = Set*.
+
+### 5. *문자열 파싱 시나리오*
+
+리뷰어: "*입력 값으로 들어올 수 있는 로또 번호의 문자열 형식이 매우 많아지면 어떻게 변경*해야 할까요? *1, 2.. 뿐만 아니라, [1], [2] 혹은 one, two, 한자, 모든 언어별 숫자를 받게끔 된다면, 이 객체에서 모든 입력 문자열에 대한 검증을 수행해야 할까요*?" — 후속: "*여전히 유효한 피드백*이에요. *도메인에서 입력 값이 String이었다는 사실을 알 필요가 있을까요*?"
+
+### 6. *로또 번호 범위*가 *여러 곳*에 — 단일 위치
+
+리뷰어: "*로또 번호의 범위는 이곳에서 쓰고 있는데, Lotto가 가지고 있*네요! *게다가 LottoMachine에서도 사용*하고 있네요! *어디에서 가지는 게 좋을지 더 고민*해 보는 건 어떨까요?"
+
+### 7. *도메인 안의 View 로직*
+
+리뷰어: "*도메인 로직에 View를 그리는 로직이 들어 있*네요! *도메인 로직과 뷰 로직을 분리*해 주세요 :)"
+
+### 8. `LottoMachine` *개수만 테스트* — 랜덤 테스트 부재
+
+리뷰어: "개수만을 검증하는 것은 *이 객체를 완전히 테스트했다고 보기에는 어려워요*. *개발자가 제어 가능하도록, 원하는 상황에서 정확하게 원하는 반환 값이 나오는지 테스트*를 수행해야 해요. *자동차 경주 때 배웠던 랜덤 테스트를 잘 되새겨* 보시고, LottoMachine 객체를 *테스트 가능*하도록 변경해 보세요 :)"
+
+### 10. `match`, `compare` 등 *동사*는 반환값에 따라 다른가?
+
+학생: "*match와 compare로 수정*했습니다!"
+
+리뷰어 (관습 인용): "*혹시 반환값에 따라 메서드 이름 내의 동사가 달라져야 하는 걸까요*? *get()을 했는데 아무것도 반환하지 않으면 굉장히 이상한 코드라는 인식*이 있겠지요! *옛날부터 내리 써 온 단어들이 몇몇* 있어요. 조금 예를 들어드리자면, *isEmpty() 같은 is\~로 시작되는 메서드는 Boolean을 반환*한답니다. 나아가서 *has\~도 대부분 Boolean을 반환*하지요. *isEmpty()를 호출했는데 String이 반환된다면 많은 개발자들이 당황*할지도 모르겠어요! match~ 하면 어떤 결과가 반환될 것 같으신가요? *저는 숫자보다는 특정 결과를 담은 Enum이 반환될 거란 생각*이 드네요. 혹은 *Boolean이 나타날 것 같아요*. *정규표현식으로부터 match를 호출하면 Boolean이 반환되는 것* 처럼요. *두 메서드의 이름을 조금만 더 고민*해 볼까요 ?_?"
+
+### 11. *동일 LottoNumber 다른 인스턴스 생성 가능*
+
+리뷰어: "*캐싱 기능을 잘 구현해 주셨네요* 👍 하지만 *다른 개발자가 동일한 숫자에 대해 다른 인스턴스를 생성할 수 있는 구조*에요. *어떻게 해결*해 볼 수 있을까요?" — *private constructor + 팩토리* 또는 *value class*.
+
+### 12. *현실 비유* — *당첨티켓이 로또티켓 비교*
+
+리뷰어: "*당첨된 로또번호 6개와, 보너스 번호를 갖고 있는 이 객체의 이름은 '로또 결과'이네요? 현실 세계를 좀 더 반영한 이름으로 바꿔보는 건* 어떨까요?" + "*당첨티켓에게 비교할 로또티켓을 주면 알아서 결과물을 반환하게 만드는*". — *현실에서 사람이 수기*로 하는 일을 *객체에게 메시지*로.
+
+### 13. `WinningStatus` *직접 반환 X*
+
+리뷰어: "*WinningStatus를 직접 반환하지 않은 특별한 이유*가 있었나요?_?"
+
+### 14. *toSet 후 비교*가 *유효한 검증인가?*
+
+```kotlin
+require(numbers.toSet().size == numbers.size)
+```
+
+리뷰어: "*numbers는 이미 set인데, toSet을 해서 개수를 비교한들, 이 검증은 유효할까요*?" — *이미 Set이면 중복 불가*. *방어 코드의 무용성*.
+
+### 15. *에러 메시지에 입력값 포함*
+
+리뷰어: "*어떤 입력 값이 들어와서 발생한 예외인지 메시지에 담아보는 건* 어떨까요? *어떤 장점*이 생길까요?".
+
+### 16. `contains operator` — *연산자 오버로딩*
+
+리뷰어: "*contains operator를 활용*해 보는 건 어떨까요?_?" — `winningNumber in winningTicket`.
+
+### 17. `toString` *도메인에 View 의존*
+
+리뷰어: "*이 toString으로 도메인에서 너무 View에 의존적인 코드가 작성*되고 있는 것으로 보여요. *객체의 toString()을 사용하지 않고 View를 만들어* 주세요 :)" — *모든 PR 공통* 패턴.
+
+### 18. `List() { }` 가짜 생성자
+
+리뷰어: "*List() { } 가짜 생성자를 활용해 보는 건* 어떨까요? 혹은, *IntRange를 활용해서 함수 체이닝을 활용*해 보는 건 어떨까요? *mutableList를 만들고, 반복문으로 해당 컬렉션을 채우는 방법 대신*에 위 방법을 고민해 보세요 :)". idiom.
+
+### 19. *Lotto 가변 생성* `Lotto(1, 2, 3, 4, 5, 6)`
+
+리뷰어: "아래처럼 *생성할 수 있게 다양한 방법을 제공*해 보는 건 어떨까요? `val lotto = Lotto(1, 2, 3, 4, 5, 6)`. *테스트 코드를 쉽게 작성할 수 있을 뿐만 아니라, 다른 개발자가 Lotto 객체를 생성할 수 있는 여러 방법을 제공해 편리함을 높일 수* 있겠어요 :)" — `vararg Int` 팩토리.
+
+### 20. *test fixture* — jojoldu 블로그 참고
+
+리뷰어: "*테스트를 실행하기 전 준비하는 데이터들에 대해 '테스트 픽스처'라고 부른답니다*. 이 테스트 픽스처에 대한 *좋은 글을 공유드릴게요* :) https://jojoldu.tistory.com/611" — 우테코 공통 자료.
+
+### 21. *ParameterizedTest *두 경계값 한 함수*
+
+```kotlin
+@ParameterizedTest
+@ValueSource(strings = ["1,2,3,4,5", "1,2,3,4,5,6,7"])  // 5개 + 7개
+fun.
+```
+
+리뷰어: "*꼭 ParameterizedTest로 두 경우를 한 메서드에서 검증해야 하는 항목이었을까요*? 테스트 코드는 *최대한 직관적으로 읽히는 게 중요*해요. `input.split(", ").map`처럼, *머릿속에서 계산을 해 보아야 하는 부분은 읽는 사람으로 하여금 잠시 읽기를 멈추게* 되어요. *그러다가 데이터가 무엇이었는지 다시 위로 돌아가 읽어야 하는 경우*가 생길 수 있어요. 이런 *사소한 것들이 테스트 가독성을 해치는 요소*라 생각해요 :) 이 경우는 *5개 혹은 7개 하나만으로도 충분한 테스트*를 할 수 있을 거라 생각해요. *두 경계값을 모두 테스트해야 한다면, 테스트를 두 개로 나눠*보는 건 어떨까요?" — PR #61 (호두)와 같은 *명세 테스트* 강조.
+
+## 리뷰어 의견 요지
+
+- **Controller의 *비교 로직* → 도메인**.
+- **검증만 객체 = *행위 부여***.
+- **`check~` *일관성*** — 동사가 반환값 시사.
+- **`Set` *중복 방지 invariant***.
+- ***문자열 다국어 시나리오*** — 도메인 = 변환된 입력.
+- **상수 *단일 위치***.
+- **도메인 안 View 로직 제거**.
+- **랜덤 테스트 *제어 가능*하게**.
+- **`is~`/`has~` = Boolean, `match~` = Boolean/Enum 관습**.
+- **`LottoNumber` *동일 인스턴스 강제*** — private constructor + 팩토리.
+- **에러 메시지에 *입력값 포함***.
+- **`in` operator** ( 강사).
+- **`List() { }` 가짜 생성자**.
+- **`vararg` 팩토리로 테스트 편의**.
+- **test fixture *jojoldu 블로그***.
+- **`ParameterizedTest` *두 경계값 = 두 테스트***.
+
+- **대표 인용:**
+
+  > 현실세계에서는 사람이 수기로 비교해서 결과를 계산하지만, 프로그래밍 세계에서는 조금 마법을 부려서, *당첨티켓에게 비교할 로또티켓을 주면 알아서 결과물을 반환하게 만드는 신기한 프로그래밍 세계*를 접해 볼 수 있어요.
+
+  > 머릿속에서 *계산을 해 보아야 하는 부분은 읽는 사람으로 하여금 잠시 읽기를 멈추게* 되어요.
+  > — @malibinYun on `src/test/kotlin/lotto/domain/LottoTest.kt`
+
+  > 다른 개발자가 동일한 숫자에 대해 *다른 인스턴스를 생성할 수 있는 구조*에요. 어떻게 해결해 볼 수 있을까요?
+  > — @malibinYun on `src/main/kotlin/domain/LottoNumber.kt`
+
+## 얻은 교훈
+
+- **Controller *비교 로직 = 도메인 침범*** — *lotto.match(winningTicket)*이 자연.
+- ***검증만 객체 = 빈 껍데기*** — *행위 부여*가 객체의 본질. `init { require }` 만이면 *valuobject도 아니고 wrapper*.
+- **`check~` 일관성 없음** — *동사가 반환값 관습*에 맞아야. `size` (Int), `hasDuplicate` (Boolean), `validate` (예외/Unit).
+- **`Set` 자료구조 = invariant 표현** — *중복 불가*는 *검증*보다 *타입*.
+- **다국어 문자열 시나리오** — *도메인은 List<Int> 받기*. *String 파싱*은 *View*.
+- **상수 *단일 위치*** — *Lotto + LottoMachine 둘 다*면 *변경 누락*.
+- **도메인 안 View 로직 = 모든 PR 공통 안티**.
+- **랜덤 테스트 *제어 가능*하게** — *Random 외부 주입*.
+- **`get`, `is~`, `has~`, `match~` *관습 어휘*** — Boolean/Enum/특정 반환에 *내장 의미*.
+- **`LottoNumber` *동일 인스턴스 강제*** — `private constructor + Map<Int, LottoNumber>` 캐싱. 외부에서 *new*를 못 만들도록.
+- **에러 메시지에 *입력값 포함*** — *로그 수집 시대*에 유일한 데이터 보존.
+- **`contains operator`** — `winningNumber in lotto`. 도메인 어휘를 *언어 표현*으로 매핑.
+- **`List(n) { gen() }` 가짜 생성자** — *MutableList + repeat*보다 *불변*.
+- **`vararg Lotto(1,2,3,4,5,6)` 팩토리** — 테스트 편의 + *다양한 생성 경로*.
+- **test fixture *jojoldu 블로그*** — *공통 데이터 분리*. *지역성*과 *재사용*의 균형 (PR #21 *MethodSource* 같이 봐야).
+- **`ParameterizedTest` *경계값 분리*** — *5개*와 *7개*는 *다른 명세*. *한 함수*로 묶으면 *어느 입력이 어느 결과*인지 *지연 계산*.

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

@@ -0,0 +1,71 @@
+# PR #96 — [예니] 로또 2단계
+
+- **Reviewee:** [@JoYehyun99](https://github.com/JoYehyun99)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/96
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 49
+
+## 잘한 점
+
+- **랜덤 요소 분리 (Strategy)**.
+- **LottoNumber 캐싱 (flyweight 적용)** — 칭찬.
+- **PurchaseAmount + 팩토리 메서드 + 생성자 둘 다**.
+
+## 못한 점 + 핵심 지적
+
+### 1. `in` → `contains` 변경 이유?
+
+```kotlin
+fun hasNumber(n: LottoNumber): Boolean = numbers.contains(n)  // 이전엔 `n in numbers`
+```
+
+> in 연산자에서 contains 함수로 변경한 이유가 무엇이었나요?
+
+→ Kotlin에서 둘은 같음. *왜* 변경했는지가 더 중요.
+
+### 2. 자동/수동 발급 로직 중복
+
+```kotlin
+fun generateManual(numbers: List<Int>): Lotto = Lotto(numbers.map(::LottoNumber))
+fun generateAuto(): Lotto = Lotto(randomNumbers().map(::LottoNumber))
+```
+
+> 자동 발급 로직에서 수동 발급 로직을 재활용해보는 건 어떨까요?
+
+→ 자동 = "랜덤 번호로 수동 생성"으로 재해석.
+
+### 3. LottoNumber 캐싱 검증 테스트 부재
+
+> 늘 같은 인스턴스가 실제로 반환되고 있는지 테스트 코드로 검증해보는 건 어떨까요?
+
+→ `assertThat(LottoNumber.of(1)).isSameAs(LottoNumber.of(1))`.
+
+### 4. 생성자 + 팩토리 메서드 둘 다 — 의도?
+
+```kotlin
+class PurchaseAmount(val value: Int) {
+    init { require(.) }
+    companion object {
+        fun of(input: String): PurchaseAmount {
+            require(.)
+            return PurchaseAmount(input.toInt())
+        }
+    }
+}
+```
+
+> 생성자를 사용하는 것과 팩토리 메서드를 사용하는 것 두 가지 모두 구현한 이유가 무엇일까요? 검증 로직도 굉장히 비슷하네요!
+
+→ 둘 다 노출 = 호출자 혼란. 하나로 선택.
+
+### 5. View가 LottoNumber → Int 타입 변경
+
+> 요기에서 타입 반환을 LottoNumber -> Int로 바꾸게 된 생각의 변화가 궁금해요!
+
+## 얻은 교훈
+
+- **자동 = 랜덤 + 수동의 합성**. 재활용으로 코드 줄이기.
+- **flyweight 캐싱 검증** — `isSameAs` (참조 동일성)로 캐시 동작 확인.
+- **생성자 vs 팩토리 메서드** — 둘 다 노출 X. 하나만.
+- **변경 이유 PR에 명시** — 리뷰어가 왜 변경했는지 묻는 패턴이 반복.