oh-my-oop 0.2.0

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

@@ -0,0 +1,158 @@
+# PR #114 — [로또 1단계] 토바에 미션
+
+- **Reviewee:** [@tobae-time](https://github.com/tobae-time)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/114
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 36
+
+## 잘한 점 (설계 관점)
+
+- **TODO + 기능 목록을 README에 상세 기록** — 자기 작업 흐름 가시화.
+- **`fun interface LottoGenerator`** 도입 — 랜덤 외부 주입 적용.
+- **검증 책임 *입력 vs 도메인*을 학생이 스스로 정리** — "형식 검증은 InputView, 도메인 요구사항은 객체 스스로".
+- **`data class Lotto`로 보일러플레이트 제거** — `equals`/`hashCode` override 직접 작성 후 리뷰 반영.
+- **`PurchaseAmountValidator`/`WinningNumberValidator`/`BonusNumberValidator` 분리** — 초기 시도는 분리 정신 잘 적용 (이후 객체 통합).
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto(randomNumbers: List<Int>)` — invariant 없음
+
+```kotlin
+class Lotto(randomNumbers: List<Int>) {
+    val numbers: List<Int> = randomNumbers.sorted()
+}
+```
+
+리뷰어: "Lotto 도메인에 대해 테스트가 이루어졌을까요? `Lotto(listOf(1,2,1,2,1,2))`와 같은 객체도 생성될 수 있겠네요." 이어서: "randomNumbers의 각 원소들이 1~45 사이에 들어간다는 걸 확신할 수 있을까요? *모든 원시 값과 문자열을 포장한다* 요구사항을 참고해 보시죠!" — 변수명만으로 invariant 보장 X. `List<LottoNumber>` 시그니처면 범위·중복이 *타입에 새겨짐*.
+
+### 2. `Validator` 클래스 남발 — 객체로의 위임 부재
+
+```kotlin
+class PurchaseAmountValidator(input: String) { init { require(.) } }
+class WinningNumberValidator(input: List<String>) { init {. } }
+class BonusNumberValidator(bonus: String, winning: List<Int>) { init {. } }
+```
+
+리뷰어: "구매 금액에 대한 검증은 어느 객체에게 역할을 부여할 수 있을까요? 만약, 검증해야 할 종류가 늘어난다면 그만큼 Validator 클래스가 생성되어야 할 텐데, 일급컬렉션을 통해 객체가 스스로 판단할 수 있게끔 해보는 건 어떨까요?" — Validator는 *행위*만 있고 *상태가 없음*. 도메인 객체의 `init`이 자기 검증을 가져야 응집.
+
+### 3. 테스트가 *Lotto가 아니라 RandomGenerator*를 검증
+
+```kotlin
+@Test
+fun `로또 번호는 1~45 사이이다`() {
+    val number: List<Int> = listOf(1, 2, 3, 4, 5, 6)
+    val lotto = Lotto(number)
+    assertThat(lotto.numbers.all { it in 1..45 }).isTrue()  // ⚠ 입력 그대로 검증
+}
+
+@Test
+fun `로또 번호는 중복되지 않는 6개의 숫자를 갖는다`() {
+    val randomGenerator = RandomGenerator()
+    val lotto = Lotto(randomGenerator.getRandomNumberList())
+    assertThat(lotto.numbers.size).isEqualTo(6)
+}
+```
+
+리뷰어: "이 테스트는 RandomGenerator()에 대한 테스트일까요? 언뜻 봐서는 랜덤요소를 테스트한 걸로 착각할 수 있을 거 같아요. '로또 번호는 중복되지 않아야 한다'는 누구의 역할이고 책임이 있을까요?" — 테스트 대상은 *입력으로 직접 깨뜨려*야 의미가 있음. `Lotto(listOf(1, 1,.))`를 넣어 예외를 확인.
+
+### 4. `LottoMachine.buyLottos`가 테스트 불가능 — 랜덤 내장
+
+```kotlin
+class LottoMachine {
+    fun buyLottos(purchaseAmount: Int): List<Lotto> {
+        val randomGenerator = RandomGenerator()  // ⚠ 내장
+.
+    }
+}
+```
+
+리뷰어: "buyLotto()에 대해 테스트가 불가능하네요. 실제로 테스트 코드 작성이 되어 있지 않습니다. 왜 테스트가 불가하고, 어떻게 개선할 수 있을까요?" — `LottoGenerator`를 인자/생성자로 주입받아야 *Fake*로 테스트 가능.
+
+### 5. `LottoNumber` 인스턴스 폭증
+
+```kotlin
+data class LottoNumber(val number: Int) {
+    init { validateLottoNumberRange() }
+}
+```
+
+리뷰어: "로또 번호는 1~45로 정해져 있습니다. 만약 동일한 로또 번호가 다른 게임에도 여러 번 사용이 된다면 해당 로또 번호는 다른 객체이어야만 할까요? 로또를 발행할 때마다 새로운 인스턴스가 생성이 된다면 리소스가 많이 들어갈 것 같아요." — *Flyweight*. `(1..45)`를 사전 캐싱 + `private constructor`.
+
+### 6. `Lotto`가 `val lotto: List<LottoNumber>` 외부 공개
+
+```kotlin
+class Lotto(val lotto: List<LottoNumber>) {. }
+```
+
+리뷰어: "외부에서 직접 lotto에 접근이 가능한데요. 외부에서 직접 접근하는 대신 Lotto 객체가 의미있는 값을 반환할 수 있다면 어떨까요?" — Tell, Don't Ask. `lotto.matchCount(other)`, `lotto.contains(number)` 같은 행위 메서드.
+
+### 7. `LottoPayment`가 검증만 — 일급 객체 의미 부재
+
+```kotlin
+class LottoPayment(private val amount: Int) {
+    init { require(amount >= MINIMUM_INPUT_PRICE) }
+    fun toInt() = amount
+}
+```
+
+리뷰어: "이 클래스의 역할은 무엇일까요? 단순 로또 구입 금액만 갖고 있는 클래스로 보이는데요!" — 학생 수긍: "검증만 필요한 거라면 클래스로 구현하지 않아도 될 것 같다는 생각이 들었습니다." → 도메인 객체로 살리려면 *수량 계산*, *잔돈 계산* 등 행위 추가 필요.
+
+### 8. `LottoMachine`이 `run()` 안에서 매번 생성
+
+```kotlin
+fun run() {
+    val lottos = LottoMachine().buyLottos(purchaseAmount)
+.
+}
+```
+
+리뷰어: "LottoMachine은 run()이 생성될 때마다 새로운 객체가 생성되어야 하는 존재일까요?" 학생 답: "LottoMachine은 게임 시작 전에 한 번만 생성되어도 됩니다!" → *상태 없는* 객체는 단일 인스턴스(생성자 주입 또는 `object`).
+
+### 9. `LottoMachine`을 클래스 바디로 옮긴 후 학생의 새로운 혼란
+
+학생: "로또 머신이 가지고 있는 것은 발행된 로또인데, run을 할 때마다 로또 머신 인스턴스가 생성되어야 하는 것이 아닌가? 하는 생각이 듭니다." — *발행물*을 기계 안에 두느냐 외부로 내보내느냐. 발행물을 보유하면 매 run마다 새 인스턴스, 발행 후 즉시 반환이면 단일 인스턴스.
+
+### 10. `runCatching` 적용에 학생의 자가 의문
+
+학생: "최소한의 입력 검증에 대해서는 runCatching 구문으로 변경하였으나, 객체가 가진 기능 요구사항에 대한 검증은 runCatching으로 변경하는 것이 고민됩니다. 첫 번째는 테스트 코드로 작성할 수 없다는 점이고 두 번째는 inputView를 호출하게 되지 않을까? 하는 생각이 듭니다."
+
+## 리뷰어 의견 요지
+
+1. **타입 시그니처가 invariant 표현** — `Set<LottoNumber>` 또는 `List<LottoNumber>`가 *List<Int>*보다 강력. "초기화 체크 vs 자료구조 선택"의 차이를 학생이 직접 정리.
+2. **Validator 클래스 = 상태 없는 행위 객체** — 같은 행위가 도메인 객체의 `init`으로 옮겨가야 응집도↑.
+3. **테스트는 *대상*을 *직접 깨뜨려*야 함** — Random을 거쳐 검증하면 Random을 테스트.
+4. **랜덤 요소는 *주입*해서 테스트 격리** — `fun interface LottoGenerator`로 자동/수동/테스트 fake.
+5. **Flyweight = 도메인 객체 수가 유한할 때의 표준** — 1~45 캐싱.
+6. **Tell, Don't Ask** — `lotto.lotto` 노출 대신 `lotto.matchCount`.
+7. **검증만 하는 클래스는 객체가 아님** — 도메인 메서드 없이는 *struct + factory*.
+8. **상태 없는 협력자는 단일 인스턴스** — `LottoMachine()`을 매 run마다 새로 만들 이유 없음.
+
+- **대표 인용:**
+  > Lotto 도메인에 대해 테스트가 이루어졌을까요? `Lotto(listOf(1,2,1,2,1,2))`와 같은 객체도 생성될 수 있겠네요.
+  > — @KwonDae on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+  > 2인승 자동차에 인원을 태우면서 더이상 타지 못함을 알리는 것 보다 2인승 자동차라는 것을 알려준다면 보다 효과적으로 외부에도 알리기도 쉽고 추가 검증도 필요 없겠죠?
+  > — @KwonDae on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+  > buyLotto()에 대해 테스트가 불가능하네요. … 왜 테스트가 불가하고, 어떻게 개선할 수 있을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/domain/LottoMachine.kt`
+
+  > 로또 번호는 1~45로 정해져 있습니다. 만약 동일한 로또 번호가 다른 게임에도 여러 번 사용이 된다면 해당 로또 번호는 다른 객체이어야만 할까요?
+  > — @KwonDae on `src/main/kotlin/lotto/domain/LottoNumber.kt`
+
+  > 이 클래스의 역할은 무엇일까요? 단순 로또 구입 금액만 갖고 있는 클래스로 보이는데요! 필요성에 대해 궁금합니다.
+  > — @KwonDae on `src/main/kotlin/lotto/domain/LottoPayment.kt`
+
+## 얻은 교훈
+
+- **타입 시그니처가 invariant**. `List<Int>` → `Set<LottoNumber>`로 가는 순간 *개수·범위·중복*이 타입으로 강제됨.
+- **2인승 자동차 비유** — 타고 나서 "더 못 타"라고 하는 대신 *2인승*이라고 말하는 것이 외부에도 친절. 자료구조 선택이 *말해주는* 도구.
+- **Validator 클래스는 도메인의 `init`이어야 한다** — Validator만 늘어나는 구조는 *행위 위주*. 도메인 객체로 위임하면 *위치-검증-사용* 한 곳.
+- **테스트 대상은 *입력으로 직접 깨뜨려야* 의미**. Random을 거쳐 검증하면 Random을 테스트. `Lotto(listOf(1, 1,.))`로 예외 발생을 확인.
+- **랜덤 요소는 *외부 주입*** — `fun interface LottoGenerator`에 자동/수동/테스트 fake를 다 끼울 수 있어야 격리 가능.
+- **유한 원시 도메인은 Flyweight**. `LottoNumber.from(value)`로 캐싱 인스턴스 조회 + `private constructor`.
+- ***Tell, Don't Ask*는 컬렉션도 동일**. `lotto.lotto` 공개는 외부가 컬렉션 메서드를 호출. `lotto.matchCount(other)`로 행위 위임.
+- **검증만 하는 클래스는 객체가 아니다**. `LottoPayment`가 검증만 하면 `data class` + 단순 함수가 더 정직. *상태로 무엇을 하는가*가 객체의 정체성.
+- ***상태 없는 협력자는 단일 인스턴스*** — `LottoMachine()`을 매 run마다 생성한다면 *상태가 있을 가능성*을 암시. 의도가 *상태 없음*이면 클래스 바디 또는 `object`.
+- **`runCatching`의 한계 = *검증 결과를 잃음***. 테스트에서 *오류 자체*가 검증 대상이면 `runCatching`이 아니라 `assertThrows`. 도메인 검증은 *예외를 던지는* 쪽으로 두고, 입력 단계만 `runCatching`.

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

@@ -0,0 +1,120 @@
+# PR #145 — [로또 2단계] 토바에 미션
+
+- **Reviewee:** [@tobae-time](https://github.com/tobae-time)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/145
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` `value class`** — 학생이 *data class vs value class* 차이를 정확히 정리.
+- **`Order` 도메인 객체 도입** — 구매 정보 묶기.
+- **`LottoManualGenerator` + `LottoRandomGenerator`** — Strategy 인터페이스 활용.
+- **리뷰 반영 커밋 해시 명시** — 변경 추적 용이.
+
+## 못한 점 (설계 관점)
+
+### 1. 1000원 미만 = 종료, 거스름돈 안내 부재
+
+리뷰어: "현재 1000원 미만을 입력하게 되면 프로그램이 종료되고 1500원과 같은 나머지 금액이 발생해도 별다른 안내가 이루어지지 않고 있습니다. 이것들을 모두 *논리 오류*라고 부르게 되는데요. 2단계의 요구사항은 *예외 처리를 통해 에러가 발생하지 않도록 한다. 논리적인 오류일 때만 예외를 던진다. 논리적인 오류가 아니면 예외를 던지지 말고 null을 반환한다*." + "만약 500원 단위의 돈이 남았다고 해도 사용자는 받을 수 없을 거예요." — 거스름돈은 *도메인 시나리오*. 단순 종료는 UX 부족.
+
+### 2. `Order`의 `var manualCount` + `setManualCount` 패턴
+
+```kotlin
+class Order(private val purchaseAmount: Int) {
+    var manualCount: Int = 0
+        private set
+    fun setManualCount(count: Int) {
+        require(count <= totalCount) { ERROR_OVER_MAX_COUNT }
+        manualCount = count
+    }
+}
+```
+
+학생: "처음에는 수동 개수도 생성자로 받았으나, 구매 금액에 대한 검증이 수동 로또 구매 이후라서 생성자에서 제거하고 코드의 순서를 변경하였습니다. 더 좋은 방법이 있을 것 같은데 잘 떠오르지 않습니다." 리뷰어: "현재 LottoMachine이라는 객체를 활용해 보면 어떨까요? `fun makeLottoTicket(purchaseAmount: Int, manualCount: Int): List<Lotto>`. 구매 금액에 대한 검증도 LottoMachine에서 가능할 것 같아요" — *생성 시 모든 정보*를 받게 만들면 setter 불필요.
+
+### 3. `LottoMachine`이 발행된 티켓 보유
+
+```kotlin
+class LottoMachine {
+    private val lottoTickets: MutableList<Lotto> = mutableListOf()
+    fun buyLottoTicket(lottoGenerator: LottoGenerator) { lottoTickets.add(.) }
+}
+```
+
+리뷰어: "LottoMachine이 티켓을 갖고 있는 게 어색해 보입니다. 실제로도 *로또 상점이 티켓에 대한 상태*를 갖고 있을까요? 로또 티켓의 데이터는 어디 있는 게 자연스러울까요?" — *발행 도구*가 *발행물*을 보유하는 것은 현실 비유와도 안 맞음.
+
+### 4. `Order`의 *manualCount만 사용*
+
+리뷰어: "사실상 현재 프로그램에서 manualCount만 사용되고 있어서 반드시 필요한가? 생각이 들었습니다. `val manualLotto: List<Lotto> =.; val autoLotto: List<Lotto> =.`로도 관리가 가능해 보이는데." — *도메인 객체*가 *한 필드만 사용*되면 *추상화 가치*가 약함.
+
+### 5. `prepareLottoTicket` — 한 함수가 많은 일
+
+```kotlin
+private fun prepareLottoTicket(purchaseAmount: Int): List<Lotto> {
+    val order = Order(purchaseAmount)
+    val manualLottoCount = getManualLottoCount()
+    order.setManualCount(manualLottoCount)
+    generateLottoTicket(order)
+    val lottoTickets = lottoMachine.getLottoTickets()
+    outputView.printPurchasedLottoTickets(manualLottoCount, lottoTickets)
+    return lottoTickets
+}
+```
+
+리뷰어: "현재 `prepareLottoTicket` 함수가 너무 많은 일을 하고 있습니다. *함수(또는 메서드)가 한 가지 일만 잘 하도록 구현*한다 요구사항을 만족해 볼까요?" + "`val ticket = lottoMachine.createLottoTicket(amount, manualCount)`. 객체에게 보다 *주체적으로 일하게끔* 메시지를 던져 볼 수 있을까요?"
+
+### 6. `toInt` vs `toIntOrNull` 의도
+
+```kotlin
+fun getManualLottoCount(): String {
+    val input = readln()
+    if (validateInteger(input)) { return input }
+    return getManualLottoCount()  // ⚠ 재귀
+}
+```
+
+리뷰어: "기존 kotlin에서 `toInt`와 `toIntOrNull` 둘 다 개발한 건 어떤 의도였을까요? *논리적인 오류가 아니면 예외를 던지지 말고 null을 반환*." — `toIntOrNull()` + `?:` 흐름.
+
+### 7. `data class` vs `value class` 학생 정리 (정확)
+
+학생: "data class에서 자동으로 생성되는 메서드는 toString(), equals(), hashCode(), copy(), componentN(). value class는 copy(), componentN()이 없음. data class는 var 허용, value class는 val만. data class는 property 제한 없음, value class는 하나의 property만." — *언어 특징의 명확한 비교*.
+
+### 8. 테스트 데이터 — `setOf` 직접 활용
+
+```kotlin
+Lotto(listOf(LottoNumber(1), LottoNumber(2),.).toSet())
+```
+
+리뷰어: "`setOf(..)` 함수로도 가능할 것 같아요. 또한, 테스트 내부 *팩토리 함수*를 통해 보다 간결하게도 테스트 코드 작성도 도전해 볼 수 있겠어요!"
+
+## 리뷰어 의견 요지
+
+- ***논리적 오류 처리* = 종료가 아니라 *재시도* 또는 *거스름돈*** — UX 시나리오 추가.
+- **setter 패턴 = 책임 누수** — 생성 시 모든 정보를 받는 객체로.
+- **상태(*발행된 티켓*) 보유 객체와 *발행 도구* 분리** — *Machine*은 *발행 행위만*.
+- **도메인 객체가 *한 필드만 사용*되면 추상화 약함** — 직접 List 보유도 옵션.
+- **함수 한 가지 일** — 조립/입력/출력이 한 함수에 섞이지 않게.
+- **`toInt` vs `toIntOrNull` 선택은 *오류 처리 전략***.
+
+- **대표 인용:**
+  > LottoMachine이 티켓을 갖고 있는 게 어색해 보입니다. 실제로도 로또 상점이 티켓에 대한 상태를 갖고 있을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/domain/LottoMachine.kt`
+
+  > 만약 500원 단위의 돈이 남았다고 해도 사용자는 받을 수 없을 거예요.
+  > — @KwonDae on `src/main/kotlin/lotto/domain/Order.kt`
+
+  > 객체에게 보다 주체적으로 일하게끔 메시지를 던져 볼 수 있을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **거스름돈 = 도메인 시나리오** — 1500원 입력 시 1장 + 500원 잔돈. UX 명세에 포함.
+- **`runCatching` 재시도**가 *종료*보다 사용자 친화.
+- **setter 패턴 회피** — `var + setManual()`은 *시간 결합*. 생성자에 *모든 정보*.
+- **객체의 *상태 보유*와 *행위*는 명확히 구분** — `LottoMachine`이 *티켓을 누적*하면 *발행 도구 + 저장소*가 됨.
+- **도메인 객체가 *한 필드만 사용*되면 *추상화 가치 약함*** — 직접 변수로 두고, *진짜 필요한 책임*을 묶을 때 객체로.
+- **함수 한 가지 일** — Controller 메서드도 *조립* 외 *반복 + 출력 + 검증*이 섞이면 분리.
+- **value class vs data class** — *불변성/한 필드*는 value, *copy/componentN/var* 필요면 data.
+- **테스트 팩토리 메서드**로 *반복 setup*을 짧게.

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

@@ -0,0 +1,21 @@
+# PR #42 — [베리] 2단계 로또
+
+- **Reviewee:** [@whk06061](https://github.com/whk06061)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/42
+- **단계:** 2단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 14
+
+## 핵심 지적
+
+- **`e.printStackTrace()` 추가** — 디버깅 정보.
+
+```kotlin
+try {. } catch (e: Exception) {
+    e.printStackTrace()  // ⚠ 누락 → 추가
+}
+```
+
+## 얻은 교훈
+
+- **예외 디버깅 정보 = stacktrace 보존**. catch에서 그냥 메시지만 출력하면 호출 경로 잃음.

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

@@ -0,0 +1,89 @@
+# PR #9 — [베리] 1단계 로또
+
+- **Reviewee:** [@whk06061](https://github.com/whk06061)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/9
+- **단계:** 1단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 21
+
+## 잘한 점 (설계 관점)
+
+- **`Rank` enum + factory** — 등수 결정 로직 캡슐화.
+- **`LottoMoney`/`LottoNumber` 원시값 포장 시도**.
+- **`TestNumberGenerator`로 랜덤 격리 시도**.
+
+## 못한 점 (설계 관점)
+
+### 1. 패키지 구분 — `constants` vs `domain`
+
+학생: "Rank enum class의 패키지가 constants 패키지가 맞는지 domain 패키지가 맞는지 잘 모르겠어서." 리뷰어: "패키지는 가능하면 *기능 단위*로 분리해 주시면 좋습니다." 학생: "view, domain, controller 구조로 분리하는 것이 좋을 것 같아 Rank 클래스의 패키지를 domain 패키지로 옮겼습니다."
+
+### 2. `LottoNumber`의 *일급 객체화* 의문
+
+학생: "로또 숫자 하나를 일급 객체로 감싸는 이유가 아직 잘 와닿지 않습니다. 데이터의 유효성 검증을 하기 위해 감싸는 걸까요?" 리뷰어 답: "객체지향적으로 사용하기 위함입니다. 로또 숫자가 *Int로 넘어오면* `1~45가 맞을까? 0이거나 음수로 넘어오면 어떡하지?` 로또 숫자가 *LottoNumber로 넘어오면* LottoNumber를 만들려면 *반드시 1~45*여야 하니까 안심하고 쓸 수 있겠구나. 위와 별개로 *도메인 관련 로직*을 LottoNumber에 포함시키면 조금 더 객체 지향적인 코드가 됩니다."
+
+### 3. `LottoNumber.LOTTO_NUMBER_RANGE_ERROR` 하드코딩
+
+```kotlin
+private const val LOTTO_NUMBER_RANGE_ERROR = "로또 번호는 1과 45 사이여야 합니다."
+```
+
+리뷰어: "만약 로또의 정책이 변경되어 1, 45가 바뀌는 경우 *2개 상수를 수정*해야 합니다. `LOTTO_NUMBER_RANGE_ERROR`에서는 하드코딩 대신 *기존에 선언되어 있는 상수*를 활용해 주세요."
+
+### 4. `Rank.valueOf`의 `!!` 강제 언패킹
+
+```kotlin
+return values().findLast { rank -> rank.countOfMatch == countOfMatch }!!
+```
+
+리뷰어: "`!!`을 사용하는 대신 null 처리 또는 *null을 처리하지 않아도 되는 코드*로 변경해 보세요." 학생: "예외를 던지도록 수정했습니다. 다만 한 가지 여쭤보고 싶은 점이 있는데, 만약 상응하는 Rank가 없어서 예외가 발생한 경우 이 예외를 따로 처리해 줘야 될까요?" 리뷰어: "이 경우는 *논리 오류*일 때 예외를 던지는 케이스이기 때문에 따로 예외 처리하기보다는 `setDefaultUncaughtExceptionHandler()`와 같이 *전역적으로 설정된 예외 처리*에 걸리도록 해 주셔야 합니다."
+
+### 5. *유효성 검사 vs 논리 오류 require* 학생 의문
+
+학생: "LottoMoney를 생성할 때 입력값 그대로를 (String 타입으로) 넘겨준 후, Int 변환 검사를 LottoMoney 클래스 내에서 진행하는 방식 중 어떤 방식이 나은지 판단이 잘 안 됩니다." 리뷰어: "*유효성 검사*는 보통 요구사항으로 입력이 잘못된 경우에 *다시 유저에게 입력*을 받아야 하므로 View에서 다시 입력받도록 만들어야 합니다. *논리 오류일 때 예외 던지기*는 개발자의 실수로 이러한 유효성 검사를 지나치면 *디버깅하기가 어려우므로 빠르게 실패*하도록 만들어 줘야 합니다. *최악 대신 차악*이 되도록 만드는 개념입니다."
+
+### 6. 테스트 데이터의 *본문 밖 정의*
+
+```kotlin
+@MethodSource("matchingCountNumbers")
+@ParameterizedTest
+fun `당첨 번호와 몇개 일치 하는지 판단 한다`(.) {. }
+```
+
+리뷰어: "좋은 테스트 코드는 *테스트 본문만 보아도 테스트하는 의도*를 모두 알 수 있어야 합니다. MethodSource는 테스트 본문에서 분리되므로 *두 곳을 모두 확인*해야 합니다. … 이러한 상황에는 `@CsvSource`를 추천드립니다." 후속: "CsvSource에서 내부적으로 `valueOf()`를 통해 enum을 가져올 수 있습니다."
+
+### 7. 테스트 코드의 *중복 제거 vs 가독성*
+
+학생: 중복 setup을 `makeUserLotto`/`makeWinningNumbers` 팩토리로 분리. 리뷰어: "훨씬 더 짧아져서 가독성이 좋아졌네요. 추가적으로 테스트 코드는 *어떻게 하면 어떻게 되는지*를 코드로 나누어 주시면 더 좋습니다. 흔히 *given, when, then* 주석으로 나누는 패턴입니다." + "테스트 코드에서는 *중복을 제거하는 것보다 가독성을 향상시키는 게 더 중요*합니다. 때에 따라서는 중복을 제거했을 때, *가독성을 해친다면 중복을 그대로* 두기도 합니다."
+
+## 리뷰어 의견 요지
+
+- **패키지는 *기능 단위*** — `constants`는 *모든 상수*면 god-folder, *기능별*로.
+- **일급 객체 = 검증 + 도메인 행위** — *둘 다* 갖춰야 의미.
+- **상수 + 메시지 = *상수 참조***로 변경 동기화.
+- **`!!` 회피** — null 처리 또는 *null이 안 되는 구조*.
+- **유효성 검사 (재입력) vs 논리 오류 (예외)** — *재입력*은 View, *디버깅*은 require.
+- **`@CsvSource` + enum 자동 변환** — 본문에 의도 명시.
+- **테스트 중복 제거는 *가독성 우선*** — 분리는 *서명만 보이게*.
+- **given-when-then 패턴**.
+
+- **대표 인용:**
+  > 로또 숫자가 LottoNumber로 넘어오면 LottoNumber를 만들려면 반드시 1~45여야 하니까 안심하고 쓸 수 있겠구나.
+  > — @galcyurio on `src/main/kotlin/lotto/domain/LottoNumber.kt`
+
+  > 좋은 테스트 코드는 테스트 본문만 보아도 테스트하는 의도를 모두 알 수 있어야 합니다.
+  > — @galcyurio on `src/test/kotlin/lotto/domain/LottoTest.kt`
+
+  > *유효성 검사*는 보통 요구사항으로 입력이 잘못된 경우에 다시 유저에게 입력을 받아야 하므로 View에서. *논리 오류*는 디버깅하기가 어려우므로 빠르게 실패하도록.
+  > — @galcyurio on `src/main/kotlin/lotto/domain/LottoMoney.kt`
+
+## 얻은 교훈
+
+- **패키지는 *기능 단위*** — *모든 상수*가 한 곳이면 god-folder. 도메인별로.
+- **일급 객체화의 *2가지 가치*** — 검증 + 도메인 행위. 둘 다 갖춰야 *비용 정당화*.
+- **상수 + 메시지 = 상수 참조** — 메시지 안의 숫자가 *하드코딩*이면 *변경 동기화 실패*.
+- **`!!`는 *코드의 자가 의심***. *null이 안 되는 구조*로 가거나, *명시적 null 처리*.
+- ***유효성 검사 vs 논리 오류*** — *재입력*은 View, *디버깅*은 require. 둘은 다른 흐름.
+- **테스트 본문에 *의도 명시*** — MethodSource보다 CsvSource로 *본문 안에서* 케이스 + 기대값.
+- **테스트 중복 제거는 *가독성 우선*** — 분리 시 *팩토리 메서드*로, 본문은 *given-when-then*.
+- **enum 자동 변환** — CsvSource가 `valueOf()`로 enum 자동 매핑.

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

@@ -0,0 +1,100 @@
+# PR #118 — [로또 1단계] 모찌 미션
+
+- **Reviewee:** [@wondroid-world](https://github.com/wondroid-world)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/118
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 60
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto`, `LottoMachine`, `Rank` 분리**.
+- **companion object 활용**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Constants.kt` 단일 파일
+
+```kotlin
+object Constants {
+    const val LOTTO_PRICE = 1000
+    const val MIN_NUMBER = 1
+    const val MAX_NUMBER = 45
+    //. 계속 늘어남
+}
+```
+
+> 상수화도 잘해주셨네요~ 추후 상수 관련된 내용이 많아진다면, 모두 Constants 내에 모이게 되는걸까요?
+
+→ god-folder 시뮬레이션 압박. 도메인별 분리.
+
+### 2. `Lotto`의 bonusNumber가 nullable
+
+```kotlin
+class Lotto(val numbers: List<Int>, val bonusNumber: Int? = null) {. }
+```
+
+> bonusNumber를 nullable 하게 설정하신 이유가 있을까요..?
+
+→ 당첨 로또에만 보너스 있음. `Lotto`/`WinningLotto` 분리가 더 자연스러움.
+
+### 3. `numbers.toList()` 중복
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    val sortedNumbers: List<Int> = numbers.toList().sorted()  // ⚠ 이미 List인데 toList()
+}
+```
+
+> 이미 numbers는 List Collection 인데, toList()를 붙히신 이유가 궁금합니다!
+
+→ 방어적 복사 의도였다면 명시적으로. 무의식 호출은 noise.
+
+### 4. Lotto가 자기 번호 생성까지
+
+```kotlin
+class Lotto(.) {
+    companion object {
+        fun create(): Lotto = Lotto((1..45).shuffled().take(6))  // ⚠ 자기 생성
+    }
+}
+```
+
+> 로또 번호 생성도 로또 객체의 책임이라고 지정을 하신 이유가 궁금합니다~
+
+→ 생성 책임은 *Factory*/*Generator*. Lotto 자체는 *주어진 번호의 검증/매칭/조회*만.
+
+### 5. `LottoMachine.lottos` — 책임 모호
+
+```kotlin
+class LottoMachine {
+    val lottos: List<Lotto> =.  // ⚠ "lottos"가 무엇을 의미?
+}
+```
+
+> LottoMachine.lottos로 보니까 뭔가 어떤기능을 담당하는지 잘 눈에 안들어오는 느낌이 들었는데
+> ```kotlin
+> val purchaseLottos = LottoMachine.purchase(count)
+> vs
+> val purchaseLottos = LottoMachine.lottos
+> ```
+
+→ 메서드 (`purchase`)가 *행위*를 명시. property는 *상태*만.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 가르침:
+
+1. **god-folder 시뮬레이션 — "추후 상수가 많아지면?"**
+
+2. **WinningLotto vs Lotto 분리** — Lotto가 bonus를 nullable로 가지면 *두 개념을 합친 상태*.
+
+3. **생성 책임의 분리** — Factory/Generator로.
+
+4. **메서드 vs property — 행위 vs 상태 구분**.
+
+## 얻은 교훈
+
+- **god-folder 시뮬레이션 = "추후 N배로 늘면?"** lotto에서도 racingcar에서도 동일 패턴. `Constants.kt` 시작은 깔끔해도 시간 갈수록 god-folder.
+- **nullable로 두 개념 합치기 회피**. `Lotto` (bonus 없음) vs `WinningLotto` (bonus 있음) → 두 클래스. nullable은 *부재의 표현*이지 *분기의 표현*이 아님.
+- **메서드와 property의 의미 차이** — `machine.lottos` (보유) vs `machine.purchase(count)` (행위). lotto 미션에서 "기계는 로또를 *준다*" 행위.

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

@@ -0,0 +1,142 @@
+# PR #150 — [로또 2단계] 모찌 미션
+
+- **Reviewee:** [@wondroid-world](https://github.com/wondroid-world)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/150
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 41
+
+## 잘한 점 (설계 관점)
+
+- **`LottoTicketGenerator` 인터페이스 + `AutoLottoTicketGenerator`/`ManualLottoTicketGenerator`** — 자동/수동을 인터페이스로 묶어 분리. Strategy.
+- **`LottoStoreCashier`로 금전 처리 분리** — 가능 수량 계산/잔돈/검증을 한 객체로.
+- **`LottoTicket.matchNumbersSize(other)`** — 매칭 개수 계산을 *내가 알고 있는 정보*에 위치시킴.
+- **각 객체에 *역할 정의 주석*을 남기는 습관** — 학생이 "객체 하나당 한 역할을 한다고 정의하고 싶어서"라고 동기를 명시.
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoTicket`이 `LottoIssueType`(자동/수동)을 필드로 보유
+
+```kotlin
+class LottoTicket(
+    private val lottoIssueType: LottoIssueType,
+    private val numbers: List<LottoNumber>,
+)
+```
+
+리뷰어: "type이 꼭 있어야 하는 이유가 있을까요? 현재 LottoTicket에서는 전혀 사용을 안 하고 있는 것 같은데, 추가를 하신 이유가 궁금합니다." 학생 답: "현실에서 로또를 발행했을 때, 번호 옆에 자동/수동이 표시" — *표시 정보*를 도메인 필드로 끌어들임. 표시 형식이 도메인의 정체성이 되면 표현 변경이 도메인 변경.
+
+### 2. `LottoTicketIssueManager` — 함수/필드명 비대
+
+```kotlin
+class LottoTicketIssueManager(
+    customerWantBuyLottoTicketCount: Int,
+    customerWantToBuyManualLottoTicketCount: Int,
+    manualLottoNumbers: List<List<Int>>,
+) {
+    fun getCustomerWantToBuyManualLottoTicketCount(): Int =.
+}
+```
+
+리뷰어: "함수명이 어마무시하게 길군요. 무조건 짧아야 한다는 아니지만, 엄청 긴데 무슨 기능을 하는지 한눈에도 안 들어오는 느낌이 살짝 드는군요." — *문장형 변수명*은 도메인 어휘 부재의 신호. `manualLottoCount`/`autoLottoCount`로 충분.
+
+### 3. 모든 메서드에 한 줄 주석
+
+```kotlin
+// 로또 발행하는 머신
+class LottoMachine {
+    // 로또 티켓을 발행한다.
+    fun issueLottoTickets(.) =.
+
+    // 자동 로또를 발행
+    private fun purchaseAutoLottoTickets(.) {. }
+
+    // 수동 로또를 발행
+    private fun purchaseManualLottoTickets(.) {. }
+}
+```
+
+리뷰어: "함수명 or 구현된 코드를 보고도 유추할 수 있는 모든 내용들에 주석이 존재한다면 오히려 구현을 이해하는데 혼동을 줄 수도 있기는 해서 추후 개발을 하면서 어떤 부분에 남겨야 할지 모찌만의 기준을 잘 잡으셨으면 좋겠습니다." — 함수명과 *완전히 동일한 정보*를 가진 주석은 잡음. 주석은 *왜*를 설명할 때만.
+
+### 4. `LottoTicketCount.toInt()` — 의미 없는 변환
+
+```kotlin
+class LottoTicketCount(private val count: Int) {
+    fun toInt() = count
+}
+```
+
+리뷰어: "`toInt()`로 표현을 하면, 어떤 것을 나타내는지에 대해서 불명확해질 수도 있겠다는 생각도 들긴 하네요!" — 원시값 포장의 의미가 `toInt()` 호출 시점에 다시 사라짐. 도메인 메서드(`value`, `count`)로 어휘 유지.
+
+### 5. `InputView`/`OutputView`가 사실상 위임만 함
+
+```kotlin
+object InputView { fun getUserInput(): String = readln().trim() }
+object OutputView {
+    fun printlnMessage(msg: Any) = println(msg)
+    fun printMessage(msg: Any) = print(msg)
+}
+```
+
+리뷰어: "OutputView와 InputView에서 너무 담당을 하는 것이 없다는 생각이 드네요. `UserInterface`에서 입출력에 대해서 모든 기능을 담당하고 있으므로, 해당 InputView/OutputView의 내용을 UserInterface의 하나의 함수로 만들어 보는 것이 나을 수도 있겠다는 생각이 듭니다!" — 단순 위임만 하는 객체는 *간접 계층*만 추가. 책임이 없으면 객체가 아님.
+
+### 6. `UserInterface` → `ViewFlow` 명명
+
+리뷰어: "ViewFlow로 변경이 되었군요. 사실 기대를 했던 건 LottoView 등의 이름을 기대했었어요." — `*Flow`는 구현 기법, 도메인 어휘 아님.
+
+### 7. `Result<Unit>` + `runCatching`로 Controller 흐름 감싸기
+
+```kotlin
+fun run(): Result<Unit> {
+    return kotlin.runCatching {
+.
+    }.map { Result.success(Unit) }
+.getOrElse { e -> Result.failure(Exception("(로또 실행 중 오류 발생) : ${e.message}")) }
+}
+```
+
+학생 자가 분석: "비논리적 오류와 논리적 오류를 잘 구분하지 못해서, 비즈니스 오류에서 나오는 것을 모두 출력하고 프로그램을 종료하고자 위와 같이 구현." — *최상위 try-catch with retry*가 비즈니스 오류와 시스템 오류를 한 그릇에 담아 책임 흐려짐.
+
+### 8. `Generator`가 `model` 패키지에
+
+```
+lotto/model/AutoLottoTicketGenerator.kt
+```
+
+리뷰어: "Generator는 생성자인데, model에 있는 것이 좋을까 싶긴 합니다! 다른 패키지로 옮긴다면 어떤 패키지로 옮겨볼 수 있을까요?" — *생성 서비스*는 도메인 데이터와 다른 계층. `service`/`factory` 패키지로 의도가 드러남.
+
+### 9. `class LottoMachine` vs `object`
+
+리뷰어 질문: "class 외에 object라는 키워드가 있는데, 이 둘은 어떤 차이점이 있을까요?" — `LottoMachine`이 *상태*를 가지지 않으면 `object`(singleton). 매번 `LottoMachine()`을 생성할 이유가 없음.
+
+## 리뷰어 의견 요지
+
+1. **표현용 정보는 도메인 필드에 넣지 말 것** — 자동/수동 *표시*는 출력 형식, 티켓의 정체성이 아님.
+2. ***문장형* 식별자는 도메인 어휘 부재의 신호** — `customerWantToBuy.Count` → `manualCount`로 압축.
+3. **자명한 주석 = 잡음** — 함수명과 같은 정보를 반복하는 주석은 가독성을 *낮춤*.
+4. **위임만 하는 객체는 객체가 아님** — `InputView`가 `readln()` 하나면 그 객체의 의미가 없음.
+5. **`object` vs `class`** — 상태 없으면 `object`로 단일 인스턴스화.
+
+- **대표 인용:**
+  > type이 꼭 있어야 하는 이유가 있을까요? 현재 LottoTicket에서는 전혀 사용을 안 하고 있는 것 같은데, 추가를 하신 이유가 궁금합니다.
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/model/AutoLottoTicketGenerator.kt`
+
+  > 함수명이 어마무시하게 길군요. 무조건 짧아야 한다는 아니지만, 엄청 긴데 무슨 기능을 하는지 한눈에도 안 들어오는 느낌이 살짝 드는군요.
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/model/LottoTicketIssueManager.kt`
+
+  > toInt()로 표현을 하면, 어떤 것을 나타내는지에 대해서 불명확해질 수도 있겠다는 생각도 들긴 하네요!
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/model/LottoTicketCount.kt`
+
+  > Generator는 생성자인데, model에 있는 것이 좋을까 싶긴 합니다! 다른 패키지로 옮긴다면 어떤 패키지로 옮겨볼 수 있을까요?
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/model/AutoLottoTicketGenerator.kt`
+
+## 얻은 교훈
+
+- **표시 형식은 도메인 필드가 아님**. `LottoIssueType`은 *출력 시 보여줄 라벨* — 티켓의 정체성이라면 매칭 로직에서 쓰여야 함. 안 쓰는 필드는 ViewModel/DTO로.
+- ***문장형 변수명*은 도메인 어휘 부재의 신호**. `customerWantToBuyManualLottoTicketCount` 같은 이름이 나타나면 *그 개념을 부르는 도메인 단어*가 없다는 뜻 — 새 객체나 새 단어를 찾아야 한다.
+- **주석은 *왜*에만**. `// 자동 로또를 발행` 같이 함수명과 정보가 똑같은 주석은 잡음. 본문 메서드는 잘 이름지어 *없어도 읽히도록*.
+- **원시값 포장의 의미는 *경계*에 있음**. `toInt()`로 빠져나오는 순간 포장 의미 소실 — Count를 받는 쪽도 `LottoTicketCount`로 받아 끝까지 어휘 유지.
+- **위임만 하는 객체는 객체가 아니라 함수**. `InputView`가 `readln()` 하나면 그 추상화는 *비용*만 만듦. 객체는 *상태 또는 정책*이 있어야 한다.
+- **`Result<Unit>` 같은 결과 타입은 *경계*에서만**. 도메인 내부 흐름을 `runCatching`으로 통째 감싸면 비즈니스 오류와 시스템 오류가 한 그릇에. *논리적 오류 = 비즈니스, 비논리적 오류 = 시스템* — 처리 위치가 다름.
+- **`object`는 *상태 없는 단일성*의 표시**. 매번 `LottoMachine()` 생성한다는 것은 "상태가 있을 수도 있다"는 약속 — 정말 상태가 없다면 `object`로 단언.
+- **패키지명도 책임 분류**. `model/Generator`는 *상태와 행위*를 섞은 패키지 — `service`/`factory`로 옮기면 호출 흐름이 패키지 트리에서 자체 설명.