oh-my-oop 0.2.0

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

@@ -0,0 +1,145 @@
+# PR #85 — [로또] 꼬상 2단계 미션 제출합니다
+
+- **Reviewee:** [@kkosang](https://github.com/kkosang)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/85
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 132 (가장 많은 코멘트)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` 값 객체 도입** — 원시 강박 탈출 (1단계 → 2단계 리팩토링의 핵심).
+- **`Rank` enum** — 등수 + 상금을 enum으로 묶음.
+- **`InputValidator` object로 검증 집중** — Validation 한 곳에 모음.
+- **`InputException` enum** — 에러 케이스를 enum으로 정형화.
+- **`require()` 활용** — 도메인 무결성.
+- **`ParameterizedTest + CsvSource`** — 케이스 풍부.
+
+## 못한 점 (설계 관점)
+
+### 1. `Buyer`가 mutable `var lottos: Lottos` 보유
+
+```kotlin
+class Buyer(private val purchaseAmount: Int) {
+    val numberOfLotto: Int = calculateNumberOfLotto()
+    var purchasedLotto: Lottos = Lottos(emptyList())  // ⚠ 초기엔 비어있다가 나중에 채워짐
+}
+```
+
+생성자에서 모두 채우지 않고 외부에서 `buyLottos(lottos)` 메서드를 통해 나중에 채움 → invariant ("Buyer는 구매한 로또를 가진다")가 시간차로 깨짐.
+
+### 2. `Controller`에 `var winningStatistics` 같은 lateinit 패턴 잔존
+
+```kotlin
+fun run() {
+    val purchaseAmount = InputView.inputPurchaseAmount()
+    buyer = Buyer(purchaseAmount)
+    val numberOfManualLotto = InputView.inputPurchaseSizeOfManualLotto(purchaseAmount)
+    publishLottos(numberOfManualLotto)              // buyer 멤버에 side-effect
+    val winningLotto = drawWinningLotto()
+    winningStatistics = makeWinningStatics(buyer.purchasedLotto, winningLotto)
+    displayWinningStatistics(purchaseAmount)
+}
+```
+
+`run()`이 너무 많은 단계를 직접 조율. 각 단계가 *Controller 멤버 변수*에 부수효과로 결과 저장.
+
+### 3. `INVALID_INPUT = -1`로 magic sentinel 값 사용
+
+```kotlin
+private const val INVALID_INPUT = -1
+
+fun validatePurchaseAmount(input: String): Int {
+    val purchaseAmount = input.toIntOrNull() ?: INVALID_INPUT  // ⚠ -1을 정상 흐름에 흘림
+    validatePurchaseAmountRange(purchaseAmount)
+    return purchaseAmount
+}
+```
+
+`null`이 의미하는 "변환 실패"를 `-1`이라는 정상 정수 자리에 끼워 넣음. 호출자가 검증을 안 하면 `-1`이 그대로 도메인에 들어감.
+
+### 4. View 안에서 try-catch + 재귀로 재입력
+
+```kotlin
+fun inputPurchaseSizeOfManualLotto(purchaseAmount: Int): Int {
+    val numberOfManualLotto = br.readLine()
+    return try {
+        InputValidator.validatePurchaseSizeOfManualLotto(numberOfManualLotto, purchaseAmount)
+    } catch (exception: IllegalArgumentException) {
+        println(exception.message)
+        inputPurchaseSizeOfManualLotto(purchaseAmount)  // ⚠ View가 재시도 흐름까지 보유
+    }
+}
+```
+
+InputView가 재시도 정책을 결정 — 입력 받기 책임 초과.
+
+### 5. `Constant.kt` 단일 파일에 모든 상수
+
+```kotlin
+object Constant {
+    // 모든 상수를 한 파일에.
+}
+```
+
+→ 리뷰어 지적: "`Constant`라는 네이밍은 무엇을 담당하는 것인지 혼란을 줄 수 있다. `LottoNumberConstants` 등으로."
+
+### 6. `Lotto.toString()`에 표현 형식
+
+```kotlin
+open class Lotto(val numbers: List<LottoNumber>) {
+    override fun toString(): String {
+        return numbers.map { it.number }.sorted().joinToString(", ", "[", "]")
+    }
+}
+```
+
+도메인 객체가 출력 형식 (`", "`, `"["`, `"]"`)을 직접 결정 → OutputView 책임 침범.
+
+### 7. `WinningStatistic`가 `Pair<Rank, Int>` 보유
+
+```kotlin
+class WinningStatistic(val result: Pair<Rank, Int>) {. }
+```
+
+`first`/`second`가 무엇인지 모름. data class 또는 명시적 필드 필요.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 핵심 가르침:
+
+1. **모호한 이름 = 책임 모호** — `Constant`, `WinningStatistic.result` 등 일반 어휘 회피.
+
+2. **try-catch + 재귀 회피** — `runCatching` 또는 `toIntOrNull() ?: return inputXxx()` 같은 코틀린 idiom.
+
+3. **표현 형식의 자리 = OutputView** — `joinToString(", ", "[", "]")`이 도메인에 있으면 표현 변경 시 도메인 변경.
+
+4. **`INVALID_INPUT = -1` 같은 sentinel 값은 위험** — null/Optional/Either 등 *타입으로 실패를 표현*.
+
+5. **mutable lateinit 패턴 회피** — `Buyer`가 생성 시점에 구매한 로또까지 받거나, 별도 팩토리 메서드 사용.
+
+- **대표 인용:**
+  > purchasedLotto를 mutable한 변수가 아닌 초기에 생성해서 사용하는 방법도 고민해보면 좋을 것 같습니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/model/Buyer.kt`
+
+  > 자칫하면 Constant라는 네이밍은 어떤 것을 담당하는 것인지에 대해서 혼란을 줄 수도 있겠다는 생각이 듭니다. LottoNumberConstants 등으로 수정하는 것도
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/util/Constant.kt`
+
+  > INVALID_INPUT = -1으로 지정하신 이유가 있을까요??
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/util/InputValidator.kt`
+
+  > 해당 내용을 try-catch를 사용안하는 방법으로 수정해보는 것도 고민해보면 좋을 것 같습니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/view/InputView.kt`
+
+## 얻은 교훈
+
+- **mutable lateinit 패턴 = invariant의 시간차 파괴**. 객체가 생성 시점부터 *완성된 상태*를 갖도록 설계. "나중에 채워진다"는 곧 "잠시 동안은 깨진 상태"라는 뜻.
+- **sentinel 값 (`-1`, `""`)은 타입 시스템의 함정**. `null` 또는 sealed class로 *실패를 타입으로* 표현해야 호출자가 강제로 처리.
+- **재시도 흐름의 자리 = Coordinator(Controller)**. View는 입력 받기만, 검증 실패 시 재시도 결정은 Controller가.
+- **표현 형식은 OutputView로**. `Lotto.toString()`이 표현을 결정하면 출력 변경이 도메인 변경. lotto 미션 특히 출력 포맷 변경 잦음.
+- **`Pair`는 일회용**. `WinningStatistic`처럼 영구적으로 들고 다니는 자료는 data class 또는 명시적 객체로.
+- **`Constant.kt`는 god-folder**. 어떤 상수든 다 들어가 응집도 0. 의미별 분리 (`LottoConstants`, `MoneyConstants`).

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

@@ -0,0 +1,97 @@
+# PR #70 — [로또 1단계] 케이엠
+
+- **Reviewee:** [@kmkim2689](https://github.com/kmkim2689)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/70
+- **단계:** 1단계
+- **리뷰어:** @ghojeong (파이로)
+- **라인 코멘트:** 20
+
+## 잘한 점 (설계 관점)
+
+- **`Rank` enum 도입 + `(countOfMatch, winningMoney)`** — 등수/상금 한 곳.
+- **`LottoNumber` `value class` + `private const val MIN/MAX` + 메시지에 *상수 참조***.
+- **`fun interface LottoGenerator`** — 테스트 가능 구조.
+- **`runCatching + onFailure { return retry() }`** — 재시도 흐름.
+- **README에 기능 요구사항 + 명세 잘 정리**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Rank.valueOf`의 *복잡한 분기*
+
+```kotlin
+companion object {
+    private const val MIN_COUNT = 0
+    private const val MISS_MAX_THRESHOLD = 2
+    private val NON_BONUS_COUNTS = listOf(3, 4, 6)
+    fun valueOf(countOfMatch: Int, matchBonus: Boolean): Rank = when {
+        countOfMatch in MISS_RANGE -> MISS
+        countOfMatch == SECOND.countOfMatch && matchBonus -> SECOND
+        countOfMatch == THIRD.countOfMatch -> THIRD
+        countOfMatch in NON_BONUS_COUNTS -> entries.first { it.countOfMatch == countOfMatch }
+        else -> throw IllegalArgumentException(.)
+    }
+}
+```
+
+학생 자가 정리: "Rank 객체에 대해 어디까지 책임을 부여해야 할 것인가에 대해 논의. 한 의견은 *발행된 로또와 비교까지* 부여, 다른 의견은 *상수로만 활용*. 결국 Rank라는 명사의 의미(*순위라는 정보*)에 초점을 맞추어, 상수로만 활용." 리뷰어: "이미 고민에 대해 *훌륭한 결론*. … 한눈에 각각이 무슨 값을 가지고 있는지 들어오는 Rank에 비해, Rank1이 더 많은 코드를 읽어야 하기 때문입니다."
+
+### 2. `runCatching + onFailure { return retry() }` — 무한 루프 + indentation 깊이
+
+```kotlin
+private fun getPurchaseExpense(): Int =
+    runCatching {
+        lottoGameInputView.inputPurchaseExpense()
+    }.onFailure {
+        if (it is IllegalArgumentException) return getPurchaseExpense()
+    }.getOrThrow()
+```
+
+리뷰어: "runCatching을 활용해 onFailure 처리를 해주시는 점 멋집니다. 하지만 예외 처리는 근본적으로 *if-else 처리와 다를 바 없다*는 점을 명심하세요. *만약 이러한 예외가 발생한다면, 이러한 로직을 처리한다*라는 조건문입니다. 즉 위와 같은 상황에서는 *조건문이 중첩되어 indentation depth가 깊어진 것*과 동일한 상황입니다. 로직을 더 작은 단위로 쪼갤 필요가 있어 보입니다. 뿐만 아니라 *조건문이 들어갔다는 것은, 곧 테스트할 로직이 있다는 의미*. Controller에 있는 로직들을 model로 옮겨서 테스트 용이하도록." + "만약 `inputPurchaseExpense()`에서 IllegalArgumentException이 계속 발생하면 *무한 루프*를 돌아야 하나요? 언제 탈출할 수 있을지에 관해서는 *조건*을 생각하면 좋을 것 같습니다. 안드로이드 개발에서 *폰이 갑자기 뜨거워지면서 벽돌*."
+
+### 3. 예외 메시지가 *사용자 안내*가 아님
+
+```kotlin
+private const val EXCEPTION_PURCHASE_EXPENSE = "로또 구매 금액은 정수여야 합니다."
+```
+
+리뷰어: "보통 예외상황에 따른 메시지를 사용자에게 던질 때는, *사용자가 무엇을 잘못했는지 어떻게 하면 제대로 프로그램을 사용할 수 있는지* 알려주는 게 좋습니다. 가령, *음수인 -1도 정수*입니다." — *정수 입력*만으로는 *양수 + 1000원 단위*를 의미하지 않음.
+
+### 4. `lottie`라는 별난 명명
+
+```kotlin
+val lottie: List<Lotto> = purchaseLottie(purchaseExpense)
+```
+
+리뷰어 농담: "Lotto의 복수형이 Lottie였나요? 신기하군요." — *Lottos*가 더 자연스러움.
+
+### 5. `value class LottoNumber` — 학생 기준 묻기
+
+리뷰어: "LottoNumber에서는 value class로 해주셨는데, 케이엠 님이 *value class를 언제 써야겠다*고 생각하는 본인만의 기준이 있으시나요?" — 기준 명시화 학습 유도.
+
+## 리뷰어 의견 요지
+
+- **runCatching = if-else** — *indentation depth*는 *조건문 중첩*과 같음. 로직 분리 + 테스트.
+- **`return retry()`는 *무한 루프* 위험** — *탈출 조건* 또는 *최대 시도 횟수* 고려.
+- **사용자 메시지 = *행동 안내*** — *정수여야 합니다*는 *너무 좁음*.
+- **명사형 명명 = 자연어 따라가기** — `Lottie` → `Lottos`.
+- **상수 + 메시지 = *상수 참조***로 변경 동기화.
+- **value class 도입의 *기준* 명시화**.
+
+- **대표 인용:**
+  > 예외 처리는 근본적으로 if-else 처리와 다를 바 없다는 점을 명심하세요. 즉 위와 같은 상황에서는 조건문이 중첩되어 indentation depth가 깊어진 것과 동일한 상황입니다.
+  > — @ghojeong on `src/main/kotlin/controller/LottoGameController.kt`
+
+  > 만약 `inputPurchaseExpense()`에서 IllegalArgumentException이 계속 발생하면 무한 루프를 돌아야 하나요? 안드로이드 개발에서 폰이 갑자기 뜨거워지면서 벽돌이 되는 현상.
+  > — @ghojeong on `src/main/kotlin/controller/LottoGameController.kt`
+
+  > 가령, 음수인 -1도 정수입니다. 안드로이드 개발자 관점에서 사용자 경험에 관련된 피드백.
+  > — @ghojeong on `src/main/kotlin/view/ConsoleLottoGameInputView.kt`
+
+## 얻은 교훈
+
+- ***runCatching은 if-else의 다른 표현*** — indentation은 같음, 테스트 가능성도 같음.
+- **재시도 = 탈출 조건 필요** — *무한 루프*는 *벽돌화 위험*.
+- **사용자 메시지 = *행동 안내*** — 도메인 invariant를 *행동으로 옮길 수 있게* 표현.
+- **명사형은 자연어 따라가기** — *Lottie* 같이 *별난 변형*은 *읽는 부담*.
+- **상수 + 메시지 = 상수 참조** — 변경 동기화.
+- **value class 도입은 *명시적 기준*** — 호출자에게 *왜 이 클래스가 value class인지* 보여야 함.

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

@@ -0,0 +1,157 @@
+# PR #82 — [로또 2단계] 케이엠
+
+- **Reviewee:** [@kmkim2689](https://github.com/kmkim2689)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/82
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @ghojeong (파이로)
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **`fun interface LotteriesGenerator { fun generate(): List<Lotto> }`** + `AutoLotteriesGenerator`/`ManualLotteriesGenerator` 구현체 — 인터페이스로 깔끔히 추상화.
+- **`ManualLotteriesGenerator(manualCount, onReceiveNumbers: () -> List<Int>)`** — *View 의존성 차단*하면서 *수동 번호 입력 시점*을 람다로 주입.
+- **`Count` 원시값 포장**으로 수동 검증 응집.
+- **`LottoMachine`을 *상태 보유 객체*로** — `availableCount`, `currentLotteries` 등 진행 상태 명시화.
+- **수동 로또 generator의 테스트 — `trial` 카운터로 *시나리오 검증***.
+- **자가 의문 PR에 풍부히 명시** — *MatchCount 원시값 포장 기준*, *view 테스트 생략의 의미*, *Manager의 추상 깊이* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lottie` vs `lotteries` 용어 혼용
+
+```kotlin
+private fun purchaseLottie(.) =.
+fun showPurchasedLottie(lottos: List<Lotto>) =.
+val lotteries = randomLottoGameManager.generateLotteries(.)
+```
+
+리뷰어: "어떨 때는 Lottie라는 용어를 쓰고 어떨 때는 lotteries라는 용어를 쓰는 것처럼 보이는군요. 이 둘을 *다른 의미로 쓰고 있나요? 아니면 같은 의미*로 쓰고 있나요?" 학생: "같은 의미의 변수들을 *다른 용어로 활용*하면 읽는 입장에서 혼란이 있을 것이라는 것을 알게 되었습니다. 통일성을 위하여 lotteries라는 용어로 변경하였습니다!" — 같은 개념은 *한 용어로 고정*.
+
+### 2. `RandomLottoGameManager` — *Random*이 어디서 나오는가
+
+```kotlin
+class RandomLottoGameManager(private val lottoGenerator: LottoGenerator) : LottoGameManager {
+    override fun generateLotteries(purchaseExpense: Int) = lottoGenerator.generate(Money(purchaseExpense))
+    override fun generateWinningLotto(winningNumbers: List<Int>) = Lotto(*(winningNumbers.toIntArray()))
+    override fun generateBonusLottoNumber(bonusNumber: Int, winningLotto: Lotto) = LottoNumber(bonusNumber, winningLotto)
+}
+```
+
+리뷰어: "솔직히 RandomLottoGameManager의 *어디가 Random*한 것인지, 코드를 처음 보는 사람 입장이라고 가정하면 *파악하기 어렵습니다*. 실제 랜덤을 담당하는 코드는 LotteryGenerator 중 AutoLottoGenerator 안의, NumbersGenerator 중 RandomNumbersGenerator까지로 이어지게 됩니다. 결국 *랜덤 요소를 가지고 있어 테스트하기 어려운 model*이 `RandomNumbersGenerator`, `AutoLottoGenerator`, `RandomLottoGameManager` *3개나 되어 버리게* 되었습니다. 이런 구조로는 프로젝트가 커질수록 (*Manager를 관리하는 Manager가 생기는 경우*가 많습니다), 점점 테스트 불가능한 model들이 많아지리라 생각됩니다." — *추상화 단계*가 *테스트 불가 영역*을 *3중*으로 늘림. 후속 라운드에서 학생: "랜덤적인 요소를 가진 클래스(RandomNumbersGenerator)를 controller에서 *직접 의존*하도록 함으로써 나머지 클래스들의 *테스트가 가능*하도록 변경." — *국소화*.
+
+### 3. `RandomLottoGameManager` 명명 — "*Wrapper 클래스를 가져오기 위한 용도*"
+
+학생 PR 설명: "입력값을 바탕으로 Wrapper 클래스를 가져오기 위한 용도의 객체 추가." 리뷰어: "model에 새로 추가된 것은 LottoGameManager 인터페이스와 RandomLottoGameManager가 유일한데 이것이 '*Wrapper 클래스를 가져오기 위한 용도의 객체*'인 건가요? 아마 `List<Lotto>`와 `LottoNumber`를 *원시값 '포장(wrapper)' 클래스*라고 표현하시는 것 같고, 입력받은 숫자들을 원시값으로 포장 객체들로 바꾸어 반환하시기 때문에 그렇게 하신 것 같습니다. 그냥 LottoGameManager라고 하면 *좀더 코드를 읽기 쉬웠을* 듯합니다. 혹시 다른 클래스가 있나, *다시 한 번 체크하며 읽어야* 했습니다." — *PR 설명 어휘*가 코드 이해를 어렵게 함.
+
+### 4. 랜덤 generator의 테스트 — `assertDoesNotThrow` 한정
+
+```kotlin
+@Test
+fun `유효한 금액이 입력되었다면, 금액에 맞는 개수의 로또가 생성된다`() {
+    val expectedSize = 6
+    val actualSize = randomLottoGameManager.generateLotteries(6100).size
+    assertThat(actualSize).isEqualTo(expectedSize)
+}
+
+@Test
+fun `유효한 우승 로또의 번호와 우승 번호와 중복되지 않는 보너스 번호가 입력되었다면, 보너스 번호를 위한 로또 숫자 객체가 생성된다`() {
+    assertDoesNotThrow {
+        randomLottoGameManager.generateBonusLottoNumber(7, Lotto(1, 2, 3, 4, 5, 6))
+    }
+}
+```
+
+리뷰어: "랜덤 요소 때문에 구체적인 아웃풋을 테스트하지 못하고, *assertDoesNotThrow*만을 테스트하고 있습니다. 사실 *모든 종류의 아웃풋을 검증하는 assertThat 테스트는 당연하게도 assertDoesNotThrow를 포함하는 테스트*입니다. 이 테스트 이름이 좀 더 *유의미해질 수 있도록 단순한 assertDoesNotThrow 말고* 더 좋은 테스트를 작성해 주시면 좋을 것 같습니다." — *결과 검증이 안 되는 테스트*는 *함수 이름*의 약속을 못 지킴.
+
+### 5. `ExceptionHandler` 인터페이스 도입의 의문
+
+```kotlin
+interface ExceptionHandler {
+    fun <T> handleInputValue(action: () -> T): T
+    fun handleOutputValue(action: () -> Unit)
+}
+```
+
+리뷰어: "ExceptionHandler를 *별도의 인터페이스로 선언*하신 이유가 궁금합니다. input을 콘솔 입력이 아니라, 안드로이드를 통한 입력, 블루투스를 통한 입력 등등을 가정하셨기에 추상화하신 건가요? 그렇다면 *입력받는 부분이 아닌 입력 값에 대한 검증이 왜 여러 개가 필요한 경우*가 있는지 궁금해서 여쭈어봅니다. 입력값 검증의 요구사항이 *바뀌었을 때를 대비*하기 위함이라면, 요구사항이 바뀌기 전의 *과거의 로직은 레거시 취급*받아 *없어지도록* 저는 구조를 짤 것 같아서요." — 추상화는 *현재의 다양성*이 있을 때 비로소 정당화.
+
+### 6. View 테스트 생략 — 학생 자가 의문
+
+학생: "view에 대한 테스트를 생략한다는 것이 *문제가 된다는 것으로 배우거나 들어본 바는 없었습니다*. 미션에서도 *UI 로직은 제외*하고 테스트를 진행하라는 요구 조건. 다만 *입력값이 null인지 여부를 검증*한다는 것이 저에게는 중요한 것으로 느껴졌던 것 같습니다." 후속: "수동 로또의 요구사항을 확인하면서 *논리적 오류에 대해서만 예외*를 던져야 한다는 Kotlin의 예외 처리 방식을 알게 되었습니다. 크루들과 이야기를 나누어 보았을 때, *사용자로부터 입력을 받는 부분은 논리적인 오류가 아니라는 결론*을 얻을 수 있었는데 이것으로 *입력값이 null일 때 예외를 던지는지 여부를 테스트로 확인할 필요가 없어*지게 되었다고 생각하였습니다."
+
+### 7. `LottoNumber(number: Int, winningLotto: Lotto)` 부생성자 — 보너스 검증
+
+```kotlin
+constructor(number: Int, winningLotto: Lotto) : this(number) {
+    val winningLottoNumbers = winningLotto.numbers.map { it.number }
+    require(number !in winningLottoNumbers) { EXCEPTION_DUPLICATE_BONUS_NUMBER_FORMAT }
+}
+```
+
+리뷰어: "로직의 일부를 domain으로 옮겼다는 게 이 부분을 말씀하시는 건가요? 하지만 *관련해서 추가된 테스트 코드는 보이지를 않*아서 여쭈어봅니다." 학생: "보너스 번호가 우승 번호와 중복될 때 예외를 던지는지에 관한 *테스트 케이스를 추가*하였습니다. 사실 미션 수행 과정에서 *TDD를 원활히 진행하지 못하여*, 도메인에서 들어가는 모든 로직에 대한 테스트 케이스를 작성하지 못하고 일부 로직에 대한 *테스트를 생략*하게 된 것 같습니다."
+
+### 8. `NumbersGenerator` → `LotteriesGenerator` 추상화 단계 상향
+
+리뷰어 제안: "기왕 NumbersGenerator라는 인터페이스를 선언해 주신 것처럼, *더 큰 단위로 Lotteries 그 자체를 만드는 인터페이스*를 선언해 보면 어떨까 제안해 봅니다. `fun interface LotteriesGenerator { fun generate(): List<Lotto> }`" — *추상의 단위*를 *Number*에서 *Lottery*로 한 단계 올림. 학생 후속 라운드에서 정확히 그렇게 구현:
+
+```kotlin
+class ManualLotteriesGenerator(
+    private val manualCount: Count,
+    private val onReceiveNumbers: () -> List<Int>,
+) : LotteriesGenerator {
+    override fun generate(): List<Lotto> = List(manualCount.value) { Lotto(*onReceiveNumbers().toIntArray()) }
+}
+```
+
+리뷰어 평가: "제 의도와 일치합니다. 수동 로또를 *무척 훌륭하게* 구현해 주셨습니다."
+
+### 9. `MatchCount` 원시값 포장 vs 단순 Int
+
+학생 README에서 *MatchCount 원시값 포장*을 TODO로 남김. 리뷰어: "Lotto 클래스의 `getMatchCount(other: Lotto): Int`에서 말하는 MatchCount를 말하는 것 같은데, *케이엠이 생각하는 원시값 포장을 해야 하는 값과 하지 말아야 하는 값을 구분하는 기준*이 있나요?" — *원시값 포장의 기준*을 학생 스스로 정리하도록.
+
+### 10. `LottoMachine`에 *발행된 lotteries 보관 + 추가* 패턴
+
+리뷰어: "lottoMachine에 *생성된 로또 번호를 넘겨주는 게 아니라*, 추상화된 LotteriesGenerator 자체를 넘겨서, *lottoMachine을 테스트*하는 것이었습니다. LotteriesGenerator가 인터페이스로 추상화되어 있기 때문에, *언제든 정해진 시나리오의 로또 번호를 생성하도록 강제*할 수 있고, 그렇게 하면 *LottoMachine의 상태가 어떻게 변하고 어떻게 동작하는지 그 결과를 예측*할 수 있게 됩니다." — `LottoMachine(generator: LotteriesGenerator)`이 더 깊은 추상.
+
+### 11. `LottoGameController` — 리뷰어 칭찬
+
+리뷰어: "저는 컨트롤러 코드가 비대하다고 생각하지 않습니다. 첫째로 컨트롤러의 *코드의 줄 수가 100줄 이하로 충분히 작고*, 둘째로 컨트롤러의 *그 어떤 메서드에서도 조건문과 반복문이 존재하지 않고*, 무슨 역할을 하는지 메서드가 충분히 작고 직관적입니다. 저는 *더 이상 분리하기 어려울 만큼* 정말 잘 분리를 해 주신 것 같습니다!"
+
+## 리뷰어 의견 요지
+
+- **용어 일관성** — 같은 개념은 한 용어로.
+- **랜덤은 *최외곽 1곳에 가두기*** — Random* Manager → Manager → Generator 3중은 *테스트 불가 영역 확장*.
+- **클래스명에 *역할이 명시*** — `RandomLottoGameManager`는 *랜덤*이 어디서 들어오는지 코드에서 안 보임.
+- **추상화 단위 상향** — `NumbersGenerator`(List<Int>)보다 `LotteriesGenerator`(List<Lotto>)가 *책임의 자연 단위*.
+- **`assertDoesNotThrow`는 *함수명*에만**, 본문은 *결과 검증* 포함.
+- **인터페이스 추상화의 정당화** = *현재의 다양성*. 미래 변경 대비 추상화는 *레거시 회피*가 더 자연.
+- **수동 로또 generator의 *람다 주입*** — `onReceiveNumbers: () -> List<Int>`로 View 의존 차단.
+- **LottoMachine에 *Generator 자체*를 주입** — 시나리오 강제 테스트.
+
+- **대표 인용:**
+  > 랜덤 요소를 가지고 있어 테스트 하기 어려운 model이 `RandomNumbersGenerator`, `AutoLottoGenerator`, `RandomLottoGameManager` *3개나 되어버리게* 되었습니다. … 점점 *테스트 불가능한 model*들이 많아지리라 생각됩니다.
+  > — @ghojeong on `src/main/kotlin/model/RandomLottoGameManager.kt`
+
+  > 솔직히 RandomLottoGameManager의 *어디가 Random*한 것인지, 코드를 처음 보는 사람 입장이라고 가정하면 파악하기 어렵습니다.
+  > — @ghojeong on `src/main/kotlin/model/RandomLottoGameManager.kt`
+
+  > 모든 종류의 아웃풋을 검증하는 assertThat 테스트는 *당연하게도 assertDoesNotThrow를 포함하는 테스트*입니다.
+  > — @ghojeong on `src/test/kotlin/model/RandomLottoGameManagerTest.kt`
+
+  > 기왕 NumbersGenerator라는 인터페이스를 선언해 주신 것처럼, *더 큰 단위로 Lotteries 그 자체를 만드는 인터페이스*를 선언해 보면 어떨까 제안해 봅니다.
+  > — @ghojeong on `src/main/kotlin/lotto/model/NumbersGenerator.kt`
+
+  > LotteriesGenerator가 인터페이스로 추상화되어 있기 때문에, 언제든 *정해진 시나리오의 로또 번호를 생성*하도록 강제할 수 있고, 그렇게 하면 *LottoMachine의 상태가 어떻게 변하고 어떻게 동작하는지 그 결과를 예측*할 수 있게 됩니다.
+  > — @ghojeong on `src/main/kotlin/lotto/controller/LottoGameController.kt`
+
+## 얻은 교훈
+
+- **용어 일관성 = 협업 비용 감소** — `Lottie`/`lotteries`처럼 같은 개념을 두 용어로 부르면 *읽는 사람이 매번 확인*.
+- **랜덤은 *최외곽 1곳*에 가두기** — Random Manager → Manager → Generator 같은 *3중 추상*은 *테스트 불가 영역을 확장*. Controller가 *직접 RandomNumbersGenerator만* 의존하고 나머지 도메인은 *번호를 받아 처리*.
+- **클래스명에 *역할의 핵심***이 노출되어야 함 — `RandomLottoGameManager`의 *Random*이 코드에서 안 보이면 *부정확한 이름*.
+- **추상화 단위는 *책임의 자연 단위*** — `List<Int>`보다 `List<Lotto>`가 도메인 책임의 단위. 추상이 *작은 단위*에 머무르면 *호출자가 한 번 더 변환* 필요.
+- **추상화의 정당화 = *현재의 다양성*** — 미래 변경 대비 추상화는 *과설계*. 요구 변경 시 *레거시 교체*가 더 자연.
+- **`assertDoesNotThrow`는 *함수 이름의 약속*만 지킬 뿐**, 본문은 *결과 검증*까지 포함해야 *함수명이 의미*를 가짐.
+- **수동 generator의 *람다 주입*** — `onReceiveNumbers: () -> List<Int>` 같이 *View 의존을 람다로 추출*하면 *도메인 단위 테스트* 가능 + 시나리오 제어.
+- **LottoMachine에 *Generator 자체*를 주입** — *로또 번호를 직접 받기*보다 *생성 정책*을 받으면, *상태 전이 시나리오*를 외부에서 강제할 수 있어 *기계 전체*를 단위 테스트 가능.
+- **MatchCount 원시값 포장의 *기준*** — *행위가 있어야* 정당화. Int 반환에 머무르면 *wrapping 비용*만.
+- **TDD 보존** — *일부 로직 테스트 생략*은 *후속 라운드에서 추가*되어야 하며, *변경 의도*가 PR에 명시되어야 함.

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

@@ -0,0 +1,161 @@
+# PR #19 — [끄롱] 1단계 로또
+
+- **Reviewee:** [@krrong](https://github.com/krrong)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/19
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 79
+
+## 잘한 점 (설계 관점)
+
+- **`WinningLotto`가 `Lotto`와 `BonusNumber`를 보유** — 역할 표현 잘됨.
+- **`RandomGenerator` 인터페이스** — 테스트 가능성.
+- **`Rank` enum + `valueOf(match, bonus)`** 팩토리.
+- **`InputViewInterface` 도입** — View 의존성 분리 시도.
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoNumber` 도메인 누락 → `Set<Int>` 그대로 노출
+
+```kotlin
+class Lotto(val numbers: Set<Int>) {. }
+```
+
+리뷰어 핵심 지적:
+
+> 로또에서 사용하는 숫자는 결국 Int 타입이라고 볼 수 있겠습니다. 그렇다면 외부에서 가져온 이 숫자들이 로또 번호라는 것을 어떻게 알 수 있을까요
+> ```kotlin
+> val lotto = Lotto(.)
+> val number = lotto.numbers.first()
+> foo(number)
+>
+> fun foo(number: Int) {
+>    // number가 로또 번호인가? 그럼 또 검증해야되나?
+> }
+> ```
+
+→ `LottoNumber` 값 객체로 추출하면 타입 시스템이 검증을 보장.
+
+### 2. `RandomGenerator` 이름의 모호함
+
+```kotlin
+interface RandomGenerator {
+    fun generate(): Set<Int>
+}
+```
+
+> 단순히 RandomGenerator라는 이름이 1부터 45 사이의 중복되지 않은 숫자 6개를 반환한다는 것을 알 수 있을까요?
+
+→ `LottoNumberGenerator`처럼 *무엇을* 생성하는지 명시. 인터페이스 계약을 시그니처/이름으로 드러내기.
+
+### 3. `LottoStatistics`의 `compareNumbers`/`compareBonusNumber`가 public — 테스트만 위해 노출
+
+```kotlin
+class LottoStatistics(val winningLotto: WinningLotto) {
+    fun compareNumbers(lotto: Lotto): Int {. }     // ⚠ 테스트만 호출
+    fun compareBonusNumber(lotto: Lotto): Boolean {. }   // ⚠ 테스트만 호출
+    fun compare(lotto: Lotto): Rank =.
+}
+```
+
+> 이 함수들은 테스트 코드에서만 사용되고 있어요. 테스트 코드를 위해 구현 코드가 public으로 노출되어서는 안됩니다.
+
+### 4. 함수 이름 모호 — `compare()`, `yield()`
+
+```kotlin
+fun compare(lotto: Lotto): Rank =.
+fun yield(): Double =.
+```
+
+> compare(), yield()라는 함수 이름으로 하여금, 어떤 결과를 반환하는지 알 수 있을까요?
+
+`compare`는 일반적으로 `-1/0/1` 반환을 시사. 도메인 어휘로 `match(lotto): Rank`, `profitRate(): Double`이 더 명확.
+
+### 5. **Tell-Don't-Ask 위반 — Statistics가 외부 객체의 정보로 직접 비교**
+
+```kotlin
+class LottoStatistics(val winningLotto: WinningLotto) {
+    fun compareNumbers(lotto: Lotto): Int {
+        val winningNumbers = winningLotto.getWinningNumbers()  // ⚠ winningLotto의 정보를 꺼냄
+        return lotto.numbers.filter { number ->                 // ⚠ lotto의 정보도 꺼냄
+            winningNumbers.contains(number)
+        }.size
+    }
+}
+```
+
+리뷰어 가이드 (Tell-Don't-Ask의 모범):
+
+> 몇개가 일치하는지 요청해서 결과를 받아오도록 해보세요. 객체지향 프로그래밍에서는 이 개념을 메시지를 보낸다 라고 표현합니다.
+> ```kotlin
+> val matchedRank: Rank = winningLotto.match(lotto)
+> ```
+
+→ Statistics가 직접 계산하지 말고 WinningLotto에게 메시지 전달.
+
+### 6. Rank 집계 자료구조 부재
+
+```kotlin
+fun compare(lotto: Lotto): Rank = Rank.valueOf(.)
+// ⚠ 각 Rank에 몇 개 일치하는지를 어떻게 셀까?
+```
+
+> Rank에 해당하는 값에 총 몇개의 당첨 갯수가 있는지를 확인하는 방법으로 적절한 자료구조는 무엇일까요?
+
+→ `Map<Rank, Int>` 또는 더 깔끔하게 `groupingBy { it }.eachCount()`.
+
+### 7. `WinningLotto`가 1~45 범위 검증 직접 수행 (중복)
+
+```kotlin
+class WinningLotto(val lotto: Lotto, val bonusNumber: Int) {
+    init {
+        require(!lotto.numbers.contains(bonusNumber)) { ERROR_CONTAIN_BONUS_NUMBER_IN_LOTTO }
+        require(bonusNumber in MINIMUM_LOTTO_RANGE..MAXIMUM_LOTTO_RANGE) { ERROR_BONUS_NUMBER_RANGE }
+    }
+}
+```
+
+`Lotto` 내부에서도 `numbers in 1..45` 검증. `LottoNumber` 값 객체가 있으면 양쪽에서 사라짐.
+
+### 8. `let` 오용
+
+```kotlin
+fun valueOf(countOfMatch: Int, matchBonus: Boolean): Rank {
+    return values().find { it.countOfMatch == countOfMatch }.let { matchResult ->
+        if (matchResult == SECOND && !matchBonus) return@let.
+    }
+}
+```
+
+> let에 대한 올바른 사용방법이 아닙니다. when 문을 이용해서 표현 해 보도록 하세요.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 메시지:
+
+1. **`LottoNumber` 도메인 추출**이 모든 안티패턴의 출발점 — 범위 검증 중복, 일반 Int 노출, "이 Int가 로또 번호인가?" 의문 모두 해결.
+
+2. **Tell-Don't-Ask = 메시지 전달**. Statistics가 두 객체의 정보를 꺼내서 비교 = feature-envy. `winningLotto.match(lotto): Rank` 한 메시지.
+
+3. **함수명 = 도메인 어휘**. `compare`처럼 일반 어휘 회피, `match`, `profitRate` 등.
+
+4. **테스트만을 위한 public 노출 금지** — racingcar에서도 반복 등장.
+
+5. **인터페이스 이름이 *계약*을 드러내야** — `RandomGenerator`만으로는 "무엇을 생성하는지" 모름.
+
+- **대표 인용:**
+  > 몇개가 일치하는지 요청해서 결과를 받아오도록 해보세요. 객체지향 프로그래밍에서는 이 개념을 메시지를 보낸다 라고 표현합니다. `val matchedRank: Rank = winningLotto.match(lotto)`
+  >
+  > — @laco-dev on `src/main/kotlin/domain/LottoStatistics.kt`
+
+  > 로또 번호라는 역할을 만들어서 가지도록 해 보면 어떨까요? 마찬가지로 로또 번호를 최대 6개 까지만 가져야 한다면, 그러한 역할을 가지는 객체를 만들어 볼 수 있겠습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/domain/Lotto.kt`
+
+## 얻은 교훈
+
+- **`LottoNumber`는 lotto 미션의 *마스터 키***. 1-45 범위, 중복 검증, 보너스 비교 모두 이 한 값 객체로 해결.
+- **Tell-Don't-Ask의 lotto 적용** = `winningLotto.match(lotto): Rank`. Statistics 같은 외부 객체가 비교 로직을 갖지 말고, 도메인 소유자(WinningLotto)에게 메시지.
+- **함수명 컨벤션 차이**: `compare()` = 비교(-1/0/1), `match()` = 일치 확인. 도메인 어휘를 신중히.
+- **인터페이스 이름 = 계약 요약**. `RandomGenerator`보다 `LottoNumberGenerator`가 의도 명확.
+- **`Map<Rank, Int>` 자료구조** = lotto 통계의 표준. 등수별 개수를 한 자료구조로.

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

@@ -0,0 +1,73 @@
+# PR #41 — [크롱] 2단계 로또
+
+- **Reviewee:** [@krrong](https://github.com/krrong)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/41
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 45
+
+## 못한 점 + 핵심 지적
+
+### 1. 함수명 `makeMoney()` vs `Money(.)`
+
+```kotlin
+fun makeMoney(input: String): Money =.
+```
+
+> 마이너한 내용인데, Money는 왜 makeMoney()가 아닐까요?
+
+→ 팩토리는 보통 `Money.of(input)` 또는 `Money(value)` 직접. `makeXxx` 패턴은 일관성 떨어짐.
+
+### 2. 0 이상 검증을 Controller에서
+
+```kotlin
+class LottoController {
+    fun run() {
+        val count = readManualCount()
+        require(count >= 0) {. }  // ⚠ Controller에서 비즈니스 로직
+    }
+}
+```
+
+> 항상 0 이상의 숫자를 받아야 한다는 것도 객체를 만들어서 처리해보세요. (비즈니스 로직을 도메인 모델로 옮긴다는 의미입니다)
+
+### 3. `runCatching` 중복 — Controller + UI
+
+```kotlin
+// Controller
+runCatching {. }.getOrElse {. }
+// UI
+runCatching {. }.getOrElse {. }
+```
+
+> `runCatching {. }` 로직이 컨트롤러, UI 두군데에 중복해서 있습니다. 올바르지 않은 값으로 Money를 만들었을때 누구의 잘못이 된다고 볼 수 있을까요?
+
+### 4. 수익률 계산이 Controller에
+
+```kotlin
+val profitRate = totalPrize.toDouble() / money.value  // ⚠ Controller가 계산
+```
+
+> 수익률을 계산하는 로직도 도메인 로직으로 분리해보세요.
+
+### 5. 로또 가격 1000원을 Controller가 앎
+
+```kotlin
+val count = money.value / 1000  // ⚠ Controller 안에 1000원
+```
+
+> 로또 한장의 가격을 컨트롤러가 알아야 할 필요가 있을까요?
+
+### 6. Lotto.toList 반환 타입
+
+```kotlin
+fun toList(): List<Int> =.  // ⚠ List<LottoNumber>여야 하지 않나?
+```
+
+> toList()는 `List<LottoNumber>`를 반환해야 하지 않을까요?
+
+## 얻은 교훈
+
+- **도메인 객체로 검증/계산 이동** — Controller에 0 이상, 1000원, 수익률 같은 *비즈니스 로직*이 모이면 god-controller.
+- **`runCatching` 중복 = 책임 위치 결정 필요**. Money 생성 실패는 *Money의 책임*. Controller/UI는 결과만.
+- **`toList()` 타입 — 도메인 타입 유지**.