oh-my-oop 0.2.0

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

@@ -0,0 +1,188 @@
+# PR #131 — [공백] 2단계 로또
+
+- **Reviewee:** [@junseo511](https://github.com/junseo511)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/131
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @krrong
+- **라인 코멘트:** 56
+
+## 잘한 점 (설계 관점)
+
+- **후속 라운드 적극 반영** — 학생이 *commit 링크*를 댓글에 첨부 (ae35853, f328b98, 52e52ae 등).
+- **`enum.from` *=when* 표현식 후속 리팩토링** — `else` 회피보다 *명확성* 선택.
+- **`getRawNumbers` View로 이동** — 학생이 *"정말로 뷰를 위한 도메인의 로직이 되어버렸네요 🥲"* 자가 인정.
+
+## 못한 점 (설계 관점)
+
+### 1. *2단계 요구사항 전부 Controller에* — 1단계 책임 분리 망각
+
+리뷰어: "*2단계 요구사항을 모두 컨트롤러에서 반영한 느낌*이에요. 🤔 마치 *자동차 경주와 1단계에서 배운 내용을 다 잊어버린 것처럼* 보여요. *오늘 수업에서 배운 내용을 잘 기억해 보시고 다시 구현*해 주시면 좋을 것 같습니다!" 학생: "아직 *컨트롤러의 함수명을 어떻게 지어야 하고, 얼만큼의 부피를 가지고 뷰와 모델을 작동시켜야 하는지 어렵*네요 🥲" — *전 단계 학습 망각* 인정.
+
+### 2. *수동 1장 + 자동 0장* 입력 시나리오 — *객체 생성 순서*
+
+```
+구입금액을 입력해 주세요.
+1400
+수동으로 구매할 로또 수를 입력해 주세요.
+1
+수동으로 구매할 번호를 입력해 주세요.
+1,2,3,4,5,6
+```
+
+리뷰어: "위처럼 입력하면 어떻게 될까요? *예상한 동작*일까요? 🤔" 학생: "*객체 생성의 순서를 조금 바꿔야 할 필요*가 있을 것 같네요 🧐" — *1400원 = 1장*인데 수동 1장 → 자동 0장이 *0인가 -*인가 검증 모호. *요구사항*: `예외 처리를 통해 에러가 발생하지 않도록 한다`. 1단계 요구사항을 *2단계 검증에도 일관*해야.
+
+### 3. `LottoWallet` 비대칭 — 수동만 *Wallet이 직접 추가*
+
+```kotlin
+class LottoWallet {
+    private val lottoBundle: MutableList<Lotto> = mutableListOf()
+
+    fun add(lottoNumbers: List<Int>) {  // ⚠ 수동: Wallet이 만듦
+        lottoBundle.add(Lotto.from(lottoNumbers))
+    }
+}
+```
+
+리뷰어: "*자동 로또는 LottoMachine이 발급해 주는데, 수동 로또는 왜 LottoWallet 스스로 추가*를 하고 있을까요? 🤔" + "*LottoWallet이 등장하게 된 배경*은 무엇일까요?" + "*LottoWallet을 만들어 주었는데 정작 컨트롤러에서는 값을 꺼내어서 전달*하고 있네요 🤔" + "*LottoMarket에서 로또를 구매하기 위해서는 지갑을 주고 거기에 로또를 담아주는 행위는 어색*하지 않나요? *로또를 구매하니 LottoWallet을 돌려주는 게 더 명확*해 보이네요 🤔" — *현실 비유의 비대칭* (지갑은 *결과 보유물*이지 *제작 도구* 아님).
+
+### 4. *함수 분리 vs 함수 분해* — 명언
+
+```kotlin
+private fun initWinningDiscriminator(): WinningDiscriminator {
+    val winningNumbers = getWinningNumbers()  // 6줄
+    val bonusNumber = getBonusNumber()        // 6줄
+    return WinningDiscriminator(winningNumbers, bonusNumber)  // 3줄
+}
+```
+
+리뷰어: "현재 세 줄, getWinningNumbers 6줄, getBonusNumber 6줄 *WinningDiscriminator 클래스 하나를 인스턴스 하기 위해 너무 많은 라인을 낭비*하고 있지는 않나요? 🤔 *함수는 하나의 일만 한다 라는 말이 정말 보너스 번호만 받아야 해, 당첨 번호만 받아야 해, 와 같은 시각으로 받아들여지지 않았으면* 좋겠어요. *WinningDiscriminator를 초기화하는 것도 하나의 일*로 볼 수 있으니까요. ***우리는 함수를 분리하는 것이지 분해하는 것이 아닙니다*** 😅" — *SRP 오해*에 대한 *한 줄 정의*. PR #80 *makeRandom+drawSix*와.
+
+### 5. `LottoCashier` *현실 메타포 부정합* + *책임 흩어짐*
+
+리뷰어: "현재의 구조는 *클래스들 간의 유기적인 관계가 조금 부족*해 보여요. *LottoCashier라는 네이밍만 봐서는 돈을 받고 로또를 팔 것처럼 느껴지거든요*. 😅 지금 *수동 로또는 LottoWallet이 스스로 만들고, LottoCashier는 로또를 몇 장 살 수 있는지만 알려주고, 그 결과와 숫자 생성기를 들고 달려가 어디선가 자동 로또를 만들어 오고* 있어요. 다음과 같이 변경해 볼까요? *LottoCashier는 돈을 받고 로또를 판매 → LottoCashier는 필요한 로또를 LottoMachine에서 출력 → 어떤 LottoMachine을 사용할지는 LottoCashier가 정할 수 있다 → LottoCashier는 Lotto뭉치를 반환*."
+
+### 6. `LottoMachine`이 *LottoNumber 범위에 관심* — 캐싱 전략 미활용
+
+```kotlin
+class LottoMachine {
+    fun getAutoNumbers(): List<LottoNumber> {
+        val range = (MIN_NUMBER..MAX_NUMBER).toList()  // ⚠ Machine이 범위 앎
+.
+    }
+}
+```
+
+리뷰어: "현재 LottoMachine은 *getAutoNumbers 함수에서 로또의 최대 최소 값을 가져와 리스트를 만들고*, 그를 바탕으로 로또 번호를 만들고 있는데요. *사실 LottoMachine은 로또의 최대, 최소 값에 대한 관심이 없을* 겁니다. *단지 모든 로또 번호 중에서 무작위로 값을 가져와야* 하죠. 이를 위해 *LottoNumber가 캐싱을 하고 있는 인스턴스들 전체를 반환*하도록 만들어 주고, *LottoMachine에서 가져다 사용*하면, *함수의 깊이 하나가 줄어들게 되고, 캐싱 전략을 적절하게 사용*하는 것이 아닐까 생각을 해 봤어요." — *Flyweight 적극 활용* + *책임 분리*.
+
+### 7. *Strategy 추상화 실패* — `default param`으로 인터페이스 오염
+
+```kotlin
+interface LottoMachine {
+    fun generate(quantity: Int, manualTicket: List<List<Int>> = emptyList()): List<Lotto>  // ⚠ default
+}
+```
+
+학생: "근데 *자동 로또와 수동 로또를 얻는 과정에서 필요한 값이 너무 달라서 generate 함수에 필요한 변수로 아래 커밋과 같이 받았는데, 이 방법도 괜찮은지 고민*이 조금 되네요 🤔"
+
+리뷰어 (*잘못된 추상화 정의*): "*디폴트 값을 넘기면 어떤 문제가 발생*할 수 있을까요? *인터페이스로 추상화하는 이유*가 무엇일까에 대해서 먼저 고민해봐면 좋을 것 같은데요. *우리는 인터페이스로 추상화함으로써 역할과 구현을 구분*할 수 있고, *이를 통해 유연성*을 가질 수 있어요. 공백이 작성해 준 방법은 *manualTicket: List<List<Int>> = emptyList()로 선언되어 있고, 구현에 대한 내용이 인터페이스에 정의*되어 있다고 볼 수 있죠. 만약 *반자동 발매기가 생긴다면 어떻게 해야 할까요? 이 역시도 인터페이스의 수정이 일어나야 할까요*? ***로또를 생성하는 구체적인 방법에 대해서는 구현체가 결정할 일입니다***."
+
+후속: "*AutoLottoMachine에서는 manualTicket을 사용하지 않고 있습니다. 즉, 잘못된 추상화*라고 이야기할 수 있어요. LottoMachine은 *자동이냐 수동이냐에 관계 없이 수량을 넘겨받아 그만큼의 로또를 만들어 주는 일*을 합니다. 그리고 *로또 번호를 자동으로 사용할 것이냐 수동으로 사용할 것이냐는 구현체에서 결정할 일*이죠."
+
+```kotlin
+interface LottoMachine {
+    fun generate(quantity: Int)  // 공통 시그니처만
+}
+class AutoLottoMachine: LottoMachine {. }
+class ManualLottoMachine(private val numbers: List<List<Int>>): LottoMachine {. }
+```
+
+### 8. `LottoMarket`이 *두 Machine 모두 직접 의존*
+
+```kotlin
+class LottoMarket(
+    private val autoMachine: AutoLottoMachine,
+    private val manualMachine: ManualLottoMachine,
+)  // ⚠ 추상화 무의미
+```
+
+리뷰어: "*LottoMarket이 ManualLottoMachine와 AutoLottoMachine를 모두 가지고 있어야 할까요*? *추상화한 LottoMachine을 잘 사용하지 못하고* 있는데요, *어떤 기계를 사용할지는 사용하는 곳에서 정할 수도 있*습니다. 의존성을 주입하는 방법은 *대표적으로 3가지*가 있으니 한 번 찾아 보시고, *어떤 기계를 사용할까를 어떻게 사용하는 곳에서 결정할 수 있을지 고민*해 보면 좋겠어요 🤠"
+
+### 9. *학생의 우회 제안* — 마켓이 모든 기계를 돌림
+
+학생: "마켓에서 buy를 실행하면 *모든 기계가 알아서 자동으로 돌아가게 해 보는 건* 어떨까요? 이렇게 *다 돌아가면서 쌓인 로또 지갑을 최종적으로 반환*하구요!!"
+
+리뷰어 (*추상화 목적 재정의*): "*LottoMachine을 추상화한 이유가 사라지게 되었네요*. 우리의 목적은 *LottoMarket이 로또를 발행할 때 어떤 기계를 사용하는지와 관계 없이 로또를 발행해 준다.* 입니다. 어떻게 하면 이렇게 만들어 줄 수 있을까요? *자동 로또와 수동 로또를 한 번에 구매해야만 할까요*?"
+
+### 10. *유효성 검증 함수* vs *인라인*
+
+```kotlin
+init {
+    validateLottoNumbersDuplicate()
+    validateWinningNumberAndBonusNumberDuplicate()  // ⚠ 긴 이름
+    validateLottoNumbersRange()
+.
+}
+```
+
+리뷰어: "유효성을 검증하는 것을 *한 눈에 알아볼 수 있도록 함수로 분리하고 init 블럭에서 호출한다. 동의*합니다. 하지만 *함수에 붙여 준 이름을 읽는 것보다 직접 작성된 코드를 읽는 것이 가독성이 더 좋다고 느껴지기도* 해요 😅"
+```
+validateWinningNumberAndBonusNumberDuplicate()
+require(!lotto.contains(bonusNumber)) {. }
+```
+"*유효성 검증이 많아질수록 init 블럭 하위에 유효성 검증 함수들이 늘어날 테고, 정작 중요한 로직들을 찾아보기 위해서는 스크롤*을 해야 하기도 하겠죠?" — *함수 추출의 비용*: *간접화*가 *직접 코드 가독성*보다 못할 수도.
+
+### 11. `else` 회피의 *오역*
+
+학생: "처음에는 *when으로 인해 생기는 else를 지양*하고 싶어서 위와 같이 분리를 했습니다."
+
+리뷰어: "*else를 지양하는 이유*는 무엇일까요? *enum class를 사용하면 when에서 else 분기문 없이 처리가 가능*한데요. 이렇게 처리하도록 한 *이유에 대해서 고민*해 보는 것도 좋겠어요 🤠 — 개인적으로는 *현재 코드가 더 가독성 넘치고 좋은 것 같아요* 👍"
+
+→ *else 회피 원칙*은 *enum 분기 누락 방지*가 본질. *함수 분해로 우회*는 잘못된 적용.
+
+### 12. *원시값 포장* + *PurchaseAmount* 미도입
+
+리뷰어: "금액이라는 *원시값도 포장*해 볼까요? 그러면 *어떤 장점*이 있을까요? 🤔"
+
+### 13. *테스트 부재*
+
+리뷰어: "*클래스를 만들었으니 테스트도 추가*하면 좋겠네요! 😊"
+
+## 리뷰어 의견 요지
+
+- ***1단계에서 배운 책임 분배*를 2단계에 *재적용*** — 새 요구사항이 *Controller에 쌓이면* 망각 신호.
+- **`Wallet`은 *결과 보유물*** — *제작 도구* 아님.
+- ***함수 분리 ≠ 함수 분해*** — *초기화 = 한 가지 일*.
+- **`Cashier` 메타포가 *책임 흐름*에 부합해야**.
+- **`LottoMachine`은 *범위/캐싱*에 무관** — `LottoNumber`가 인스턴스 캐시 보유.
+- **`Strategy` *공통 시그니처*만** — *default param*은 *잘못된 추상화*.
+- **DI 위치 = *사용하는 곳***. *Market이 두 Machine 다 의존*은 추상화 무의미.
+- **검증 함수 추출 *남용 회피*** — *직접 코드 가독성*도 신호.
+- **`else` 회피는 *enum 분기 누락 방지***. *함수 분해로 우회*는 오역.
+- **원시값 포장 + 테스트 추가**.
+
+- **대표 인용:**
+  > **우리는 함수를 분리하는 것이지 분해하는 것이 아닙니다** 😅
+  > — @krrong on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 마치 자동차 경주와 1단계에서 배운 내용을 *다 잊어버린 것처럼* 보여요.
+  > — @krrong on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > **로또를 생성하는 구체적인 방법에 대해서는 구현체가 결정할 일입니다**.
+  > — @krrong on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+  > LottoMarket에서 로또를 구매하기 위해서는 *지갑을 주고 거기에 로또를 담아 주는 행위는 어색*하지 않나요? *로또를 구매하니 LottoWallet을 돌려주는 게 더 명확*해 보이네요 🤔
+  > — @krrong on `src/main/kotlin/lotto/model/LottoMarket.kt`
+
+## 얻은 교훈
+
+- **단계 추가 = *책임 분배 재검토*** — *새 요구사항*은 *기존 도메인 객체*에 *분배*. Controller로 흘러들면 *전 단계 망각*.
+- **현실 비유의 *방향성*** — `Wallet`은 *지갑 = 결과 보유*. *돈 → 구매 → 결과 지갑* 순서. *지갑을 주고 담아 와*는 *역방향* 어색.
+- ***함수 분리 ≠ 함수 분해*** — *WinningDiscriminator 초기화 = 한 가지 일*. *6+6+3줄로 분해*는 *간접화의 늪*. 함수 *추출 비용*에 *직접 코드 가독성*도 측정.
+- **`Cashier` 메타포 정합** — *돈 받기 → 기계 사용 결정 → 로또 출력 → 묶음 반환*. 책임 흐름이 *현실 행위*와 일치.
+- **`Machine`은 *범위/캐싱*에 무관** — *LottoNumber* (값 자체)가 *캐싱 보유*. *Machine은 random select*만.
+- **`Strategy = 공통 시그니처*** — *default param*은 *구현 세부가 인터페이스로 누출*. *반자동 추가 시 인터페이스 수정*하면 *Open-Closed 위반*.
+- **DI 위치 = *사용하는 곳***. *Market이 두 Machine 다 의존*은 *추상화의 목적 (사용자 무관)을 깨뜨림*.
+- **검증 함수 *남용 회피*** — `validateA()` + `validateB()` + `validateC()` 가 *init 블럭을 가득 채워* 진짜 로직을 *스크롤로 밀어 냄*. *짧은 require*는 인라인이 *가독성 우위*.
+- **`else` 회피 = *enum 분기 누락 방지*** — *함수 분해로 우회*는 *원리 오역*. `enum.entries.find {. }`로 *Open-Closed*도 확보.
+- **`PurchaseAmount` 원시값 포장의 장점** — *검증 시점 일원화*, *도메인 어휘*, *Tell Don't Ask*.
+- **테스트 = *클래스를 만들었다는 신호***. *새 클래스 + 테스트 부재*는 *명세 부재*.

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

@@ -0,0 +1,24 @@
+# PR #43 — [토마스] 2단계 로또
+
+- **Reviewee:** [@ki960213](https://github.com/ki960213)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/43
+- **단계:** 2단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 12
+
+## 핵심 지적
+
+### 1. indent 깊음 → 함수 분리
+
+> indent가 너무 깊어지네요. 별도 함수로 분리하거나 지역 변수로 선언해서 가독성을 향상시켜보세요.
+
+### 2. Money → value class
+
+> value class를 활용해보면 어떨까요?
+
+### 3. 테스트 함수명 명확 — 칭찬
+
+## 얻은 교훈
+
+- **indent ≥ 3 = 함수 분리 시점**. 깊은 들여쓰기는 abstraction level 신호.
+- **Money 같은 단일 값 = value class** (inline + 동치성).

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

@@ -0,0 +1,159 @@
+# PR #8 — [토마스] 1단계 로또
+
+- **Reviewee:** [@ki960213](https://github.com/ki960213)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/8
+- **단계:** 1단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 15
+
+## 잘한 점 (설계 관점)
+
+- **`data class LottoNumber(val number: Int)`** → 후속 *Flyweight* (1-45 캐싱) + `valueOf()` 팩토리.
+- **`NumberGenerator` 인터페이스** — 랜덤 주입.
+- **`LottoResult` 도메인 객체** — `getRateOfReturn()` 메서드.
+- **테스트 케이스 *명세서 수준*** — 리뷰어 칭찬: "테스트 케이스 이름들이 *깔끔하고 명확*하네요! :+1: *테스트 케이스들만 보아도 이 프로그램이 어떻게 동작하는지 알 수 있겠*네요."
+- **`LottoNumber` 재사용** — 리뷰어 칭찬: "LottoNumber 재사용 :+1:".
+- **전반 칭찬**: "*전체적으로 역할과 책임에 맞게 객체들을 깔끔하게 잘 분리*해 주셨네요 :+1:".
+
+## 못한 점 (설계 관점)
+
+### 1. `1`, `45` *하드코딩* — 상수 미참조
+
+```kotlin
+data class LottoNumber(val number: Int) {
+    init {
+        require(number in MINIMUM_NUMBER..MAXIMUM_NUMBER) { ERROR_NUMBER_IN_RANGE.format(number) }
+    }
+
+    companion object {
+        private const val MINIMUM_NUMBER = 1
+        private const val MAXIMUM_NUMBER = 45
+        private const val ERROR_NUMBER_IN_RANGE = "로또 숫자는 1부터 45사이어야합니다. \n 잘못된 값: %d"  // ⚠ 1, 45 다시 등장
+    }
+}
+```
+
+리뷰어: "위의 상수에 따라 *정책이 변경될 수도 있으니 1, 45를 하드코딩하는 대신 상수를 참조*해 주세요." — *단일 변경 지점* 원칙. 후속: `"로또 숫자는 ${MINIMUM_NUMBER}부터 ${MAXIMUM_NUMBER}사이어야합니다."`.
+
+### 2. 인터페이스 이름 + 메서드 명 *중복*
+
+```kotlin
+interface NumberGenerator {
+    fun generateNumbers(): List<Int>  // ⚠ generateNumbers
+}
+```
+
+리뷰어: "인터페이스 이름이 `NumberGenerator`이므로 *generate()로도 충분*해 보여요." — *컨텍스트 어휘 중복*. `numberGenerator.generate()`가 자연.
+
+### 3. 일급 컬렉션이 *List 타입 자체 구현* — 전체 인터페이스 노출
+
+```kotlin
+data class Lotto(private val numbers: List<LottoNumber>) : List<LottoNumber> by numbers {
+.
+}
+```
+
+리뷰어: "일급 컬렉션에서 *컬렉션 타입을 구현하도록 되어 있는데* 이번 미션에서는 *모두 지워 보고 도메인에 어울리는 이름으로 함수*를 만들어 보시면 좋겠습니다. 그리고 *get(), set(), contains() 함수는 컬렉션을 구현하도록 하지 않더라도 여전히 operator overloading을 통해 재정의*할 수 있습니다." — *List 인터페이스 위임* = `forEach`, `map`, `iterator` 등 *모든 컬렉션 메서드 노출*. *일급 컬렉션 의도와 충돌*.
+
+### 4. List 자체 *외부에 직접 노출 시 방어적 복사*
+
+리뷰어: "간혹 *List 타입 자체가 필요한 경우*가 있는데 *그런 경우에는 아래와 같이 방어적 복사를 한 이후에 넘겨주시면* 됩니다."
+```kotlin
+fun toList(): List<LottoNumber> = numbers.toList()
+```
+
+### 5. `data class` + `private constructor` 충돌 → value class
+
+```kotlin
+class LottoNumber private constructor(val number: Int) {
+    override fun equals(other: Any?) =.
+    override fun hashCode() =.
+}
+```
+
+리뷰어: "data class로 선언하면 *생성자를 private으로 선언해도 copy() 함수를 통해 생성이 가능*해서 class로 변경하신 것 같네요. 이럴 때는 *value class를 활용*하시면 좋습니다. 아래와 같은 장점이 있습니다.
+> - data class의 equals(), hashCode(), toString()도 똑같이 구현된다.
+> - copy() 함수를 사용할 수 없어서 *value class의 생성자를 private으로 선언할 수 있다*.
+> - 컴파일러에서 *최적화를 할 수 있어서 성능상 이득*이다."
+
+→ *생성자 통제 + equals 자동*은 *value class*가 최적.
+
+### 6. `LottoStore.buyLotto` — *판매자가 사라고?*
+
+```kotlin
+class LottoStore {
+    fun buyLotto(amount: Int): List<Lotto> {. }  // ⚠ buyLotto
+}
+```
+
+리뷰어: "LottoStore 입장에서는 *로또는 판매하는 게 더 적절한 네이밍*으로 보여요." 학생: "공개된 *메서드의 시그니처는 클라이언트가 객체에게 보낼 수 있는 메시지*인데, *클라이언트 입장에서 볼 때 로또 상점에게 '로또를 사라'라고 명령하는 것은 어색*하군요!" — *공개 메서드 시그니처 = 메시지*.
+
+### 7. `!!` 사용 — null 처리 강제 회피
+
+```kotlin
+result[Rank.valueOf(winningLotto.getCountOfMatch(it), winningLotto.matchBonus(it))] =
+    result[Rank.valueOf(winningLotto.getCountOfMatch(it), winningLotto.matchBonus(it))]!! + 1
+```
+
+리뷰어: "*!!을 사용하는 대신에 null 처리*를 해 주시거나 *NonNull 타입으로 변경하여 null 처리가 필요 없게끔* 만들어 주세요." + "*중복을 제거*해 주세요." — *동일 표현식 2회 호출* + `!!` 모두 안티.
+
+### 8. Tell, Don't Ask — `numbers.contains` → `lotto.contains`
+
+```kotlin
+data class Lotto(.) : List<LottoNumber> by numbers {
+    private fun List<LottoNumber>.isNotDuplicated(): Boolean = this.distinct().size == this.size
+    fun contains(lottoNumber: LottoNumber): Boolean = numbers.contains(lottoNumber)
+    fun count(predicate: (LottoNumber) -> Boolean): Int = numbers.count { predicate(it) }
+}
+```
+
+리뷰어: "*바깥에 정보를 넘겨주는 대신에 Lotto에서 메시지를 받아 처리*하도록 만들어 보세요." + "*contains() 함수로 operator overloading이 가능*합니다. 이렇게 하면 외부에서 *lottoNumber in lotto*와 같이 작성할 수 있습니다."
+```kotlin
+operator fun contains(lottoNumber: LottoNumber): Boolean = numbers.contains(lottoNumber)
+```
+→ *Kotlin idiom* 사용해 *도메인 어휘*를 *언어 어휘*에 매핑.
+
+### 9. 테스트 클래스 *오타*
+
+```kotlin
+class gLottoResultTest {  // ⚠ 앞에 'g'
+```
+
+리뷰어: "오타 발견!"
+
+## 리뷰어 의견 요지
+
+- **상수 *모든 등장 자리* 참조**.
+- **인터페이스 이름 + 메서드 명 *컨텍스트 중복 회피***.
+- **일급 컬렉션은 *List 타입 자체 구현 X*** — 도메인 메서드만.
+- **List 노출 시 *방어적 복사***.
+- **`data class` + private constructor = *value class*** — copy 방지 + equals/hashCode/toString 자동.
+- **`LottoStore.buyLotto` → `sell`** — *메시지로서 어울리는 동사*.
+- **`!!` 회피** — null 처리 또는 NonNull 타입.
+- **`Tell, Don't Ask`** — `lottoNumber in lotto`.
+
+- **대표 인용:**
+  > 일급 컬렉션에서 컬렉션 타입을 구현하도록 되어 있는데 이번 미션에서는 모두 지워 보고 *도메인에 어울리는 이름으로 함수*를 만들어 보시면 좋겠습니다.
+  > — @galcyurio on `src/main/kotlin/domain/Lotto.kt`
+
+  > data class로 선언하면 생성자를 private으로 선언해도 copy() 함수를 통해 생성이 가능해서 class로 변경하신 것 같네요. 이럴 때는 *value class를 활용*하시면 좋습니다.
+  > — @galcyurio on `src/main/kotlin/domain/LottoNumber.kt`
+
+  > 공개된 메서드의 시그니처는 *클라이언트가 객체에게 보낼 수 있는 메시지*인데, *클라이언트 입장에서 볼 때 로또 상점에게 '로또를 사라'라고 명령하는 것은 어색*하군요!
+  > — @ki960213 on `src/main/kotlin/domain/LottoStore.kt`
+
+  > 바깥에 정보를 넘겨주는 대신에 *Lotto에서 메시지를 받아 처리*하도록 만들어 보세요.
+  > — @galcyurio on `src/main/kotlin/domain/Lotto.kt`
+
+## 얻은 교훈
+
+- **상수 *모든 등장 자리* 참조** — 에러 메시지 안에서도 `${MINIMUM_NUMBER}부터 ${MAXIMUM_NUMBER}`. *단일 변경 지점*.
+- **인터페이스 이름 + 메서드 명 중복 회피** — `NumberGenerator.generateNumbers()`는 *컨텍스트 어휘 반복*. `.generate()`로 충분.
+- **일급 컬렉션 ≠ `List` 인터페이스 위임** — `: List<T> by numbers`로 위임하면 *모든 컬렉션 메서드*가 외부 노출. *도메인 메서드만 선택적 노출*이 의도.
+- **List 자체 노출 시 *방어적 복사*** — `numbers.toList()`. *원본 컬렉션 누출*을 막음.
+- **`data class` + `private constructor` 충돌 → *value class*** — `copy()` 노출 막으면서 equals/hashCode 자동.
+- **`LottoStore.sell()`** — 메서드 이름은 *클라이언트가 보낼 메시지*. `buyLotto`는 *판매자에게 사라*가 되어 어색.
+- **`!!` 사용 회피** — null 처리 또는 NonNull 타입. `result[x]!!`는 *Map 초기화 가정*에 의존.
+- **`operator fun contains` 활용** — *Kotlin idiom*으로 도메인 어휘가 *언어 표현*에 자연스럽게 매핑. `if (lottoNumber in lotto)`.
+- **테스트 클래스 이름 오타** — `gLottoResultTest` 같은 *손가락 미끄러짐*은 *PR 셀프 리뷰*가 잡아야.
+- **`Flyweight` 패턴 학생 자발적 도입** — `valueOf(number)`로 1-45 *캐싱 객체*. *value class*와는 충돌 (가벼움 자체가 그 역할).

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

@@ -0,0 +1,50 @@
+# PR #74 — [로또] 올리브 1단계 미션
+
+- **Reviewee:** [@kimhm0728](https://github.com/kimhm0728)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/74
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 46
+
+## 못한 점 + 핵심 지적
+
+### 1. lint 실패
+
+```
+ModelTest.kt:13:1 Wildcard import (cannot be auto-corrected)
+ModelTest.kt:34:27 Newline expected after opening parenthesis
+```
+
+### 2. `LottoConstants` — 상수 분리 기준 자가 의문
+
+```kotlin
+object LottoConstants {. }
+```
+
+리뷰어:
+
+> 상수로 값이 분리되는 기준은 무엇일까요?? 2군데 이상에서 같이 사용되면 상수에 포함이 되는 것일까요? 그렇다면 향후 다시 1군데에서만 사용된다면 상수가 아니게 되는 것일까요? 클래스가 수백개 수천개가 된다면 2개 이상 사용하는지 어떻게 검사해야 할까요.. 각 상수에 대한 값을 표현하기에 적절한 객체는.
+
+→ "2군데 이상" 기준은 *유지 불가능*. 도메인 객체가 자기 상수 소유.
+
+### 3. LottoPrize 정의된 값을 또 하드코딩
+
+```kotlin
+enum class LottoPrize(val matchingCount: Int,.) {
+    FIRST(6,.),
+.
+}
+
+if (matched == 6) {. }  // ⚠ LottoPrize.FIRST.matchingCount 안 씀
+```
+
+> 하드코딩 대신 LottoPrize에 정의된 matchingCount 값을 활용해 볼 수 있지 않을까요?
+
+### 4. 복합 조건문 괄호 누락
+
+→ 가독성 + 우선순위 명시.
+
+## 얻은 교훈
+
+- **상수 분리 기준 = *2군데 이상*은 불안정**. 도메인 객체 소유가 안정적.
+- **enum 데이터 = enum 자신이 활용**. 외부에서 매직넘버 다시 쓰면 enum 가치 잃음.

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

@@ -0,0 +1,176 @@
+# PR #94 — [로또] 올리브 2단계 미션
+
+- **Reviewee:** [@kimhm0728](https://github.com/kimhm0728)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/94
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 34
+
+## 잘한 점 (설계 관점)
+
+- **`LottoMachine` 인터페이스 + `AutoLottoMachine`/`ManualLottoMachine`** — Strategy 적용.
+- **`LottoNumber.from(value)` Flyweight** — 1~45 캐싱 + `private constructor`.
+- **`PurchaseOrder`로 입력 정보 묶음** — 가격/수동수/자동수 한 객체에.
+- **자가 의문 PR에 풍부히 명시** — *팩토리 메서드 vs 주생성자*, *논리 오류 vs 비논리 오류*, *수동 발행 위치* 등을 학생이 먼저 논점화.
+- **MethodSource로 두 구현체 공통 테스트 시도** — 추상에 대한 공통 행위 검증.
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoStore`가 일급 컬렉션에서 `object`(함수 묶음)로 격하
+
+```kotlin
+// 변경 전
+class LottoStore private constructor(val lottos: List<Lotto>) {
+    companion object { fun buyLottos(.): LottoStore {. } }
+}
+
+// 변경 후
+object LottoStore {
+    fun buyAutoMaticLottos(.): List<Lotto> =.
+    fun combineLottos(manual: List<Lotto>, auto: List<Lotto>) = manual + auto
+}
+```
+
+리뷰어: "지금의 LottoStore에 있는 역할은 모두 함수로서 기능을 하고 있을 텐데, 단순히 코드만 따로 분리한 것처럼 느껴져요. 이 기능은 컨트롤러의 역할로서 구현이 되어 있을 텐데, 굳이 나뉘었다면 목적이 무엇이라고 생각하시나요?" → 학생 수긍, `LottoStore` 자체를 삭제. *함수만 모아둔 객체는 모듈*.
+
+### 2. `WinningStatistics.get(LottoPrize)` — 반환 의미 모호
+
+```kotlin
+operator fun get(lottoPrize: LottoPrize): Int =
+    statistics.getOrDefault(lottoPrize, DEFAULT_LOTTO_PRIZE_COUNT)
+```
+
+리뷰어: "`WinningStatistics.get(LottoPrize)`가 반환하는 값이 무엇일지 예측이 잘 될까요? 수량일 수도 있고, 전체 가격일 수도 있습니다." — `operator fun` overload는 *맥락*이 명확할 때만. `countOf(prize)` 같은 메서드명이 의도 명확.
+
+### 3. Controller 메서드가 *조립 + 출력* 혼재
+
+```kotlin
+private fun getWinningStatistics(.): WinningStatistics {
+    return winningLotto.calculateWinningStatistics(lottos).also {
+        OutputView.printWinningStatistics(it)  // ⚠ 사이드이펙트
+    }
+}
+```
+
+리뷰어: "get() 함수가 출력까지 담당한다면 여러가지 일을 한다고 볼 수 있지 않을까요? 정말 이 값들이 필요해서 호출할 때마다 매번 출력이 될 수 있습니다." → `get*()`는 *값 반환*만, 출력은 별도 호출.
+
+### 4. `ManualLottoMachine`이 *상태(idx)* 보유
+
+```kotlin
+class ManualLottoMachine(private val manualLottoNumbers: List<List<Int>>) : LottoMachine {
+    private var idx = 0
+    override fun generate(): List<Int> = manualLottoNumbers[idx++]
+}
+```
+
+리뷰어: "내부적으로 idx라는 상태를 사용하기 때문에 이 함수가 반환하는 값이 매번 바뀌게 됩니다. 한 개만 발행하도록 하는 대신에 여러 개를 반환하도록 할 수도 있지 않을까요? `fun generate(count: Int): List<Lotto>`." — *호출 순서*에 의존하는 객체는 시간 결합. 일괄 반환으로 결합 제거.
+
+### 5. `PurchaseOrder.isPurchaseManual` 추가 검증 — 자가 생산 가능
+
+```kotlin
+class PurchaseOrder(val price: Int, val manualLottoSize: Int = 0, lottoPrice: Int = Lotto.PRICE) {
+    val automaticLottoSize: Int
+    init {
+        require(price.divideByLottoPrice(lottoPrice) && price.isMoreThanMin(lottoPrice)) {. }
+        val totalLottoSize = price / lottoPrice
+        require(manualLottoSize.isPurchaseManual(totalLottoSize)) {. }
+        automaticLottoSize = totalLottoSize - manualLottoSize
+    }
+}
+```
+
+리뷰어: "구매 가능한 최소 갯수를 확인하면서, 구매 가능한 자동 로또 갯수와 수동 로또 갯수가 명확해졌는데. 다시 한번 더 검사할 필요가 있을까 했어요." — 학생 반박: "구매 금액이 13000원인데 수동 로또의 갯수를 100개를 입력한다면…" → 학생 주장이 사실은 타당. 실제로 *어떤 추가 검증이 필요한가*를 명확히 한 사례.
+
+### 6. `retryWhileNoException` — 유틸이 *논리적*일 수 있는가?
+
+```kotlin
+fun <T> retryWhileNoException(action: () -> T): T = try { action() } catch (e: Exception) {. }
+```
+
+리뷰어: "논리적인이라는 말을 하기에는 전제조건이 잘못되었어요. 유틸리티가 논리적일 수가 있을까요? 로또의 갯수가 유효하지 않으면 오류가 발생한다. // 유틸(?)" — *유틸리티는 행위 단위*, 도메인 검증을 흡수할 수 없음.
+
+### 7. `LottoMachine`에 *수동 로또까지* 끼워 넣는 어색함 — 학생 자가 의문
+
+학생: "ManualLottoMachine에서는 입력에 대한 `List<List<Int>>`를 프로퍼티로 가지고, generate()에서 이 프로퍼티를 인덱스 별로 하나씩 반환하기만 합니다. 수동 로또와 자동 로또의 인터페이스를 통일하기 위해 억지로 인터페이스의 구현체를 추가한 것 같은 느낌이 드는데, 리뷰어님은 어떻게 생각하시나요?" — 리뷰어: "`List<List<Int>>`가 불편한 것이라면 `List<Lotto>`를 사용하면 되는 것일까요?" + 시그니처 일괄 반환 제안.
+
+### 8. `InputView.validateAndConvertDigit()`가 *상수 반환*으로 변경
+
+```kotlin
+private fun String.validateAndConvertDigit(): Int {
+    return toIntOrNull() ?: INVALID_DIGIT  // ⚠ INVALID_DIGIT은 상수 Int
+}
+```
+
+리뷰어: "Invalid 한 숫자라는 것은 누가 결정하는 게 맞을까요? InputView에서 숫자를 받고 나서는 그 값이 유효한지 아닌지 알 방법이 없게 됩니다." — sentinel 값 안티패턴. `null` 또는 sealed 결과로 *실패를 타입화*.
+
+### 9. 인터페이스 두 구현체를 한 테스트 클래스에서
+
+```kotlin
+@MethodSource("로또 발행에 대한 테스트 데이터")
+fun `로또의 번호를 임의로 지정해주면 해당 번호로 로또가 발행된다`(lottoMachine: LottoMachine, lottoSize: Int) {. }
+
+companion object {
+    @JvmStatic fun `로또 발행에 대한 테스트 데이터`() = listOf(
+        Arguments.of(ManualLottoMachine(.), 2),
+        Arguments.of(LottoMachine {. }, 5),
+    )
+}
+```
+
+리뷰어: "일반적으로 인터페이스 구현체들을 하나의 테스트에 모두 작성하지 않습니다. 각 구현체에 대한 기능을 테스트하기 때문에 각 테스트로 분리합니다." — 추상 *계약*은 공통 테스트, *구현*은 개별 테스트.
+
+### 10. `Lotto.create()` 외에 다른 생성 경로 — 학생 자가 의문
+
+학생: "Lotto의 주생성자인 `Lotto(numbers: Set<Int>)`로 인스턴스를 생성하는 경우가 없고, 팩토리 메서드를 통해 인스턴스를 생성하는 경우만 존재합니다. 이런 경우에도 주생성자를 public으로 열어두는 것이 맞을까요?" — 리뷰어: "위 구현의 관점에서 본다면 생성하기 위한 여러가지 방법을 제시하는 것이 아닌, 시스템적으로 생성을 제약하는 방법에 가깝습니다." → 학생 수긍 후 `private constructor`로.
+
+### 11. `create()` 함수의 검증이 *create*를 거치지 않으면 누락
+
+```kotlin
+fun create(numbers: List<Int>): Lotto {
+    require(numbers.isValidSize()) { INVALID_SIZE }
+    return Lotto(numbers.sorted().map { LottoNumber.from(it) }.toSet())
+}
+```
+
+리뷰어: "create() 함수로 만들지 않았다면 isValidSize()를 거치지 않기 때문에 항상 통과하겠네요?" — `private constructor`로 강제하지 않으면 *검증이 우회됨*.
+
+## 리뷰어 의견 요지
+
+1. **함수만 모아둔 객체는 *모듈*** — 인스턴스 의미 없으면 `object` 또는 그냥 함수.
+2. **`operator fun get`은 *맥락이 명확*할 때만** — `winningStatistics[X]`가 무엇을 반환하는지 모르면 `countOf(X)`.
+3. **Controller 메서드 = *조립 + 반환*** — 출력은 별도 호출, 사이드이펙트 섞지 말 것.
+4. **호출 순서 의존 객체는 *시간 결합*** — `idx++`로 호출마다 다른 값 반환은 *내부 상태에 의존*.
+5. **팩토리 메서드 + private constructor = *생성 제약*** — 부생성자 의도면 public 주생성자도 OK.
+6. **`Lotto.create()` 외 경로는 검증 우회** — 강제하지 않을 거면 *팩토리를 사용하는 의미가 없음*.
+7. **유틸은 도메인 *판단*을 흡수하지 않음** — `retryWhileNoException`이 도메인 오류와 시스템 오류를 한 그릇에 담는 것.
+8. **인터페이스 구현체는 개별 테스트** — 공통 계약 테스트는 별도, 구현 동작은 각자.
+9. **InputView에서 sentinel 반환 X** — `null` 또는 sealed로 *실패를 타입화*.
+10. **입력 폼은 *별도 객체로* 만들 수도 있음** — 식당 비유: 한 번에 묶어 받기 vs 항목별 받기.
+11. **재시도 = 키오스크 안내**, 알 수 없음 시스템 오류 X.
+
+- **대표 인용:**
+  > 지금의 LottoStore에 있는 역할은 모두 함수로서 기능을 하고 있을 텐데, 단순히 코드만 따로 분리한 것처럼 느껴져요.
+  > — @laco-dev on `src/main/kotlin/lotto/model/LottoStore.kt`
+
+  > `WinningStatistics.get(LottoPrize)`가 반환하는 값이 무엇일지 예측이 잘 될까요? 수량일 수도 있고, 전체 가격일 수도 있습니다.
+  > — @laco-dev on `src/main/kotlin/lotto/model/WinningStatistics.kt`
+
+  > 내부적으로 idx라는 상태를 사용하기 때문에 이 함수가 반환하는 값이 매번 바뀌게 됩니다. 한 개만 발행하도록 하는 대신에 여러 개를 반환하도록 할 수도 있지 않을까요?
+  > — @laco-dev on `src/main/kotlin/lotto/model/ManualLottoMachine.kt`
+
+  > 미션에서 요구하는 논리적인 오류라고 하는 것은, 사용자가 경험하는 모든 과정에 있어서 정말로 Exception을 터트려야 하는 것인지, 아니면 어떠한 오류가 발생했을 때 적절하게 문제를 해결하도록 할 것인지를 이해하기를 기대하는 문제입니다.
+  > — @laco-dev on `src/main/kotlin/lotto/utils/Retry.kt`
+
+## 얻은 교훈
+
+- **객체의 *역할*이 함수 호출 위임만 되면 객체로서의 의미 없음**. `LottoStore`가 buyLottos/combineLottos만 가지면 사실상 함수 묶음. *상태로 무엇을 하는가*가 객체의 정체성.
+- **`operator fun get`은 *컬렉션-유사 객체*에서만 의미**. 도메인 객체에 붙이면 *반환 의미*가 호출자에게 안 보임.
+- **사이드이펙트 + 반환 = 두 책임**. `get*().also { print(it) }`는 호출자가 *반환만* 원할 때 강제로 출력 발생.
+- **호출 순서 의존 객체 회피**. `idx++` 같은 내부 카운터는 *시간 결합*. 일괄 호출 시그니처로 회피.
+- **`private constructor` + 팩토리 = *시스템적 제약*** — 부생성자 의도면 public 주생성자 유지. 두 용도를 혼동하지 말 것.
+- ***예외 사용 = 키오스크 안내 vs 시스템 오류*** — 사용자 입력 오류는 *재안내*, 정말 복구 불가능한 오류만 시스템 종료.
+- **`null`이나 sealed로 *실패 타입화***  — InputView에서 sentinel Int 반환은 호출자가 *알 수 없음 오류*를 일으킬 가능성.
+- **인터페이스 *구현체*는 개별 테스트**. 공통 *계약*은 추상 테스트 클래스로. 구현체별 *세부 행위*는 분리.
+- **로또 가격 확장성 = trade-off**. 단일 가격이면 상수, 다중 가격이면 외부 주입. 항상 추상화하면 *과설계*.
+- **검증을 객체가 받았다는 것 = 검증 완료**. `PurchaseOrder`가 `manualSize <= totalSize`를 보장하면 외부에서 다시 검증할 이유 없음.
+- ***도메인 오류 vs 시스템 오류 구분 = 사용자 경험 차이***. 유틸리티에 둘 다 흡수하면 *모든 오류가 같은 안내*.