oh-my-oop 0.2.0

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

@@ -0,0 +1,155 @@
+# PR #141 — [다이스] 2단계 로또
+
+- **Reviewee:** [@moondev03](https://github.com/moondev03)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/141
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @krrong
+- **라인 코멘트:** 27 (리뷰어 21 + 학생 6)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoBundle` 일급 컬렉션** — Strategy 시도.
+- **후속 라운드 반응 좋음** — 리뷰어 칭찬: "*의도했던 바를 정확히 파악해 주셨네요* 💯".
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoNumber.MIN/MAX` + `RandomLottoNumbersGenerator` *양쪽 보유*
+
+```kotlin
+class LottoNumber {
+    companion object { const val MIN = 1; const val MAX = 45 }
+}
+class RandomLottoNumbersGenerator {
+    val numbers = (1..45).shuffled().take(6)  // ⚠ 다시 1..45
+}
+```
+
+리뷰어: "*로또의 최대, 최소 값이 LottoNumber, RandomLottoNumbersGenerator 모두 가지고 있어요. 최대 최소 값은 누구의 관심사일까요? 🤔 LottoNumber에서 만들어 놓은 값을 잘 활용하려면 어떻게 해야 할까요*?"
+
+리뷰어 후속: "*LottoNumber의 최대, 최소 값은 LottoNumber만이 관심 있는 값이죠. 자동 숫자 생성기는 LottoNumber에게 이렇게 요청할 수 있겠어요. '너가 가진 모든 번호를 주겠니?'* 그러면 *인스턴스화 시켜 놓은 값들을 적절히 활용*할 수 있을 것 같아요". 강사 동일 가르침 (*LottoMachine은 범위에 관심 없다*).
+
+### 2. *Pair + nullable 반환* — 두 의미 손실
+
+```kotlin
+fun buyLottos(.): Pair<Lottos, Lottos>? =.
+```
+
+리뷰어: "*Pair로 반환을 하고 있는데 게다가 값이 있을지도 없을지도 모른다*..? *로또를 구매하는 일을 한다고 생각해 보고 조금 더 명확한 값을 반환*해 보도록 할까요? 🤠" + "nit: *Pair를 만들 때는 a to b처럼 사용*할 수도 있어요!"
+
+### 3. *디폴트 파라미터의 위험*
+
+리뷰어: "*디폴트 파라미터를 정의해 두면 어떤 문제가 생길 수 있을까요*?".
+
+### 4. *`service` 패키지 의도*
+
+리뷰어: "*service 패키지는 어떤 역할을 하나요? model과는 어떤 차이가 있기에 패키지를 구분*했나요? 🤔"
+
+### 5. *구매 수량 + 주문 클래스 분리* 전략
+
+```kotlin
+// 현재: 금액에서 수동/자동을 줄여 가며 계산
+```
+
+리뷰어 (제안): "자동 로또와 수동 로또의 *구매 수를 계산하기 위해 금액을 줄이는 전략을 사용했네요*! 다음과 같은 *클래스를 만드는 전략*은 어떤가요? 🤔
+1. *구매 수량 클래스* - 수동 구매 수 - 자동 구매 수
+2. *주문 클래스* - 금액 - 수동 구매 수 - 자동 구매 수"
+
+추가 (현실 비유): "실제로 *로또를 사러 가서 돈, 수동 번호를 주며 자동 몇 개요~ 하고 주문하는 것처럼 Order에 수동 로또 번호도 추가*해 보면 어떨까요? 🤔"
+
+### 6. *CsvSource 보다 분리*
+
+리뷰어: "테스트를 보다 *split이 왜 필요할까 하는 의문점*이 들었어요. *수익률을 계산하는 테스트를 진행하기 위해서는 테스트의 가독성을 위해 CsvSource를 사용하는 것보다 분리해서 작성하는 게 좋아* 보여요."
+
+### 7. *`Lotto.contains` 의도* — 보너스인지 모름
+
+리뷰어: "사실 의도는 *'로또가 x를 포함하면 true를 반환한다'와 같이 수정하기를 바*랐어요. *Lotto의 관점에서 바라봤을 때 들어오는 값이 보너스 번호인지 그냥 번호인지 알 필요가 없으니까요* 🤠" — *호출자가 의미 구분*, 도메인은 *순수 행위*.
+
+### 8. *테스트 가독성*
+
+리뷰어:
+```kotlin
+@Test
+fun `1등의 수익률은 2000000이다`() {
+    val result = mapOf(LottoRank.FIRST to 1)
+    val actual = LottoResult(result).calculateTotalReturn(1000).toDouble()
+    assertThat(actual).isEqualTo(2000000.00)
+}
+```
+"조금 더 가독성을 개선하고 싶다면 아래처럼 작성할 수도 있겠어요 🤠"
+
+### 9. `LottoMachine` *발급 책임* — 구조 변경
+
+리뷰어: "이 부분은 *구조적인 변경이 커질 수도 있을 것 같아 참고만 하셔도* 좋을 것 같아요 🤠 현재 *LottoMachine은 LottoNumbersGenerator에게 받아온 숫자들을 로또로 만들어 주고* 있는데요. *현실 세계에 대입해 보면 로또는 기계에게 로또 몇 장 줘!라고 이야기해서 로또를 받아 와요*. 즉, *LottoMachine이 Lotto를 혹은 LottoBundle을 발급한다!라고도 볼 수* 있죠. 그리고 *로또를 파는 상점에서는 돈과 어떤 로또 기계를 사용할지를 받아 로또를 판다*. 이렇게 구성하면 *LottoMachine의 뎁스가 낮아지고 ManualLottoNumbersGenerator는 불필요한 count 멤버변수를 갖지 않을 수* 있어요!".
+
+### 10. *출력 형식 불일치* — `Int` vs `List<LottoNumber>`
+
+리뷰어: "*로또 구매 수를 출력할 때는 Int를 따로따로 넘겨주고, 로또 번호를 출력할 때는 List<LottoNumber>의 형태를 넘겨주고* 있네요. *각각의 기준이 있는 걸까요*? 🤔" — *일관성 검토*.
+
+### 11. *테스트 = LottoMachine 진짜 책임 검증?*
+
+리뷰어: "*이 테스트는 정말 LottoMachine의 테스트가 맞을까요*? 🤔"
+
+### 12. *InputView가 Model을 모르는 이유*
+
+리뷰어: "*OutputView에서도 당연히 Model을 받아 사용할 수 있어요. 저 또한 Model을 넘겨주는 것이나 List를 넘겨주는 것 모두 가능하고, 둘 중 어느 방법을 선택해야 하느냐는 트레이드 오프의 영역이라고 생각*해요. 그런데, *다이스의 설계에서 OutputView는 Model을 알고 있는데, InputView는 왜 Model을 알지 못할까요? 이 부분은 앞으로 개발을 하면서 고민*해 보시면 좋을 것 같아요 😊" — *비대칭 점검*.
+
+### 13. *모든 LottoNumber 메시지* — 도메인 어휘
+
+리뷰어: "*모든 LottoNumber를 가져오는 것 또한 메시지를 넘길 수 있겠네요* 🤠"
+
+### 14. *generateLottoBundle 포함 가능*
+
+리뷰어: "*generateLottoBundle 안에 포함되어도 될 것처럼 보이네요* 🤠"
+
+### 15. *amount 가시성*
+
+리뷰어: "*amount는 외부에서 사용하지 않으니 가시성을 수정해 볼 수* 있겠어요"
+
+### 16. *테스트명 + 변수명 일치*
+
+리뷰어: "*테스트명과 변수명도 무엇을 테스트하는지에 맞춰 변경하면 좋겠어요* 🤠"
+
+## 리뷰어 의견 요지
+
+- **MIN/MAX *단일 출처 = LottoNumber***. *Generator는 메시지로 요청*.
+- **`Pair? + nullable` *두 의미 손실*** → data class.
+- **`a to b` *Pair Kotlin idiom***.
+- **디폴트 파라미터 *위험 검토***.
+- **`service` 패키지 *의도 검증***.
+- **구매 수량 + 주문 클래스 *책임 분배***.
+- **CsvSource *과사용 검토***.
+- **`Lotto.contains(x)` *의미 중립*** — 보너스/일반 호출자 의미.
+- **`LottoMachine = Lotto 발급* 현실 비유**.
+- **출력 형식 *일관성*** (Int vs List).
+- **InputView/OutputView *비대칭 점검***.
+- **가시성 *최소화***.
+
+- **대표 인용:**
+  > LottoNumber의 최대, 최소 값은 *LottoNumber만이 관심 있는 값*이죠. 자동 숫자 생성기는 LottoNumber에게 이렇게 요청할 수 있겠어요. *'너가 가진 모든 번호를 주겠니?'*
+  > — @krrong on `src/main/kotlin/lotto/service/RandomLottoNumbersGenerator.kt`
+
+  > 다이스의 설계에서 *OutputView는 Model을 알고 있는데, InputView는 왜 Model을 알지 못할까요*?
+  > — @krrong on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > 실제로 로또를 사러 가서 *돈, 수동 번호를 주며 자동 몇 개요~ 하고 주문하는 것처럼* Order에 수동 로또 번호도 추가해 보면 어떨까요?
+  > — @krrong on `src/main/kotlin/lotto/domain/Order.kt`
+
+  > Lotto의 관점에서 바라봤을 때 *들어오는 값이 보너스 번호인지 그냥 번호인지 알 필요가 없으니까요*.
+  > — @krrong on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+## 얻은 교훈
+
+- **MIN/MAX *단일 출처 = LottoNumber***. *Generator는 LottoNumber.getAll() 메시지*로 요청. 강사 동일 가르침.
+- **`Pair? + nullable`** = *두 의미 손실*. *data class*는 *필드 이름*, *Result 객체*는 *상태 표현*.
+- **`a to b` Kotlin idiom** = *Pair* 생성 자연.
+- **디폴트 파라미터 = *잘못된 추상화 신호***.
+- **`service` vs `model` 패키지 *의도 검증*** — *Layered Architecture*가 *DDD*인지 *책임 분배*인지.
+- **`Order` 도메인 객체** — *돈 + 수동 번호 + 자동 수*를 *하나의 메시지*로. *현실 메타포* 충실.
+- **CsvSource *과사용*** — *테스트 1개면 vanilla `@Test`*.
+- **`Lotto.contains(x)` *의미 중립*** — 도메인은 *값 검사*만, *의미 분류*는 호출자.
+- **`LottoMachine = Lotto 발급* 현실 비유** — *기계에게 로또 몇 장 줘* + *상점에서 어떤 기계 사용할지 결정*. PR #131 *Cashier-Machine 흐름*과 같은 결.
+- **출력 형식 *일관성*** — `Int`와 `List`가 *섞이면* 호출자 *어떤 형식 기대*에 혼란.
+- **InputView/OutputView *비대칭 점검*** — *OutputView는 Model 알고*, *InputView는 Model 모름*은 *비대칭 신호*. 둘 다 Model 가능.
+- **가시성 *최소화*** — *외부 사용 없으면 private*.
+- **테스트명 + 변수명 일치** — *변수명이 테스트 의도 드러내야*.
+- **함수 *포함 가능성*** — *별도 함수가 의미가 약하면* 통합 검토.

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

@@ -0,0 +1,143 @@
+# PR #69 — [오둥이] 1단계 로또
+
+- **Reviewee:** [@murjune](https://github.com/murjune)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/69
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag (규일)
+- **라인 코멘트:** 43 (리뷰어 31 + 학생 12)
+
+## 잘한 점 (설계 관점)
+
+- **원시값 포장** — 리뷰어 칭찬: "*원시값 포장 잘해 주셨네요*👍".
+- **`init` 검증** — "*init 블록을 통한 초기 Validation Check 아주 좋네요*👍".
+- **`companion object` 상수** — "companion object를 통한 *상수값 관리 좋습니다*💯".
+- **`operator fun contains`** — `number in lotto` 표현. 칭찬: "*operator 함수의 활용 좋습니다*~".
+- **`fun interface LottoGenerator`** — SAM. 칭찬: "interface의 활용 *정말 좋네요*💯".
+- **`value class`** — 사용.
+- **`LOTTO_NUMBER_RANGE`** — 칭찬: "범위 지정 좋습니다👍".
+- **테스트 정밀도** — "*Lotto에서 들어갈 수 있는 모든 경우에 대해서 테스트*해 주셨네요💯".
+- **`junit @ParameterizedTest`** 활용.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller가 *runCatching*으로 검증
+
+```kotlin
+fun run() {
+    val purchaseMoney = runCatching {. }.getOrElse {. }
+}
+```
+
+리뷰어: "*runCatching을 사용한 이유가 궁금*합니다🤔 *해당 내용을 보면 inputView에 대한 Validation 실패인데 과연 해당 내용을 체크해 주는 게 Controller에서 담당해야 할 기능인지에 대해서도 고민*해 볼 필요가 있을 것 같습니다!" — *Controller가 검증 책임*인가 *InputView/도메인*인가. PR #36 (galcyurio)과 같은 *Elizarov 글* 시리즈.
+
+### 2. `operator fun contains` *의도 메타-질문*
+
+```kotlin
+class Lotto {
+    operator fun contains(number: LottoNumber): Boolean =.
+}
+```
+
+리뷰어: "operator 함수의 활용 좋습니다~ 고민해 볼 내용이 *operator 함수로 작성하신 이유가 궁금*합니다🤔" — *Kotlin idiom* `number in lotto` 표현을 *도메인 어휘 일치*로 정당화해야.
+
+### 3. `let { }` 가독성 — *apply/forEach* 대안
+
+```kotlin
+return getRankMap().let {. }
+```
+
+리뷰어: "*let을 사용하는 것도 좋기는 하지만 좀 더 의미를 명확하게* 아래처럼 하는 방법도 있을 것 같아서 참고 부탁드립니다~ 1. *getRankMap().apply {. }* 2. *getRankMap().ranks.forEach {. }*" — *scope function*의 의도 (변환/this 설정/부수효과)를 *어휘 일치*로.
+
+### 4. `fun interface LottoGenerator` *키워드 이유*
+
+```kotlin
+fun interface LottoGenerator {
+    fun generate(): List<LottoNumber>
+}
+```
+
+리뷰어: "*LottoGenerator interface 앞에 fun 키워드가 붙은 이유가 궁금*합니다🤔" — *SAM (Single Abstract Method)*로 *람다 변환 가능*. 의도 명시.
+
+### 5. `value class` vs `data class` — 메타-질문 반복
+
+리뷰어: "*value class를 사용해 주셨군요*👍 수정이 필요한 것은 아니고 같이 고민해 보면 좋을 것 같아서 코멘트 남겨 두었습니다~ *value class와 data class는 어떤 차이점이 존재*할까요?? 해당 내용을 *value class로 작성하신 이유*가 궁금합니다!" 
+
+### 6. *1..45 변경 시 깨질 위험*
+
+리뷰어: "*그럴 일은 없겠지만 1..45라는 최소, 최대값이 만약 바뀌게 된다면, 해당 기능은 사용을 못하게 될 텐데, 확장성을 위해서 고민*을 해 보는 것도 좋을 것 같습니다💪"
+
+### 7. `ConsoleLottoGameInputView` *class* 선택 이유
+
+리뷰어: "*ConsoleLottoGameInputView를 class로 작성하신 이유가 궁금*합니다!🤔" + "*ConsoleLottoGameOutputView를 class로 작성하신 이유가 궁금*합니다!🤔" — *object vs class* 선택 정당화.
+
+### 8. 테스트 *랜덤 시나리오 부재*
+
+리뷰어: "*로또 번호 생성기에 대해서 주어진 값을 테스트하는 것도 좋지만, 랜덤으로 번호가 주여졌을 경우도 테스트해 보는 것도 좋은 경험*이 될 것 같다는 생각이 듭니다!💪" + "*해당 부분도 setUp을 랜덤하게 구현될 수 있도록 고민*해 보는 것도 좋을 것 같습니다!🤔"
+
+### 9. 매직 넘버 `-1, 10, 1` 상수화
+
+리뷰어: "*하드 코딩으로 들어간 -1, 10, 1에 대해서 상수 값으로 분류*를 해 보는 것도 고민해 볼 필요는 있을 것 같습니다!💪"
+
+### 10. EOF 설정 + 디버깅용 *println*
+
+리뷰어: "*다음 설정 옵션을 활성화하여 EOF 경고를 없애*주세요🥲 *File > Preferences > Editor > General > Ensure every saved file ends with a line break*" + 디버깅 코드: "*해당 내용이 들어간 이유가 있을까요*??😅"
+
+### 11. *공통 테스트 데이터* — `DEFAULT_LOTTO`
+
+리뷰어: "Lotto(1, 2, 3, 4, 5, 6)의 경우 *테스트에서 많이 사용*되고 있는데, *이를 재사용하기 위해서 DEFAULT_LOTTO = Lotto(1, 2, 3, 4, 5, 6) 등으로 작성*해 보시는 것도 고민해 보면 좋을 것 같습니다!" — test fixture.
+
+### 12. `BonusLottoNumber`의 `List<LottoNumber>` *의존*
+
+```kotlin
+class BonusLottoNumber(val lottoNumber: LottoNumber, winningNumbers: List<LottoNumber>) {. }
+```
+
+리뷰어: "*BonusLottoNumber가 List<LottoNumber>에 대한 의존성을 가지게* 되었군요! *보너스 번호의 경우 로또 결과에 대해서 중복값이면 안 된다는 이유로 인하여 발생한 것이라면 괜찮아 보이기*는 합니다~" — *의존 정당화*는 *도메인 invariant*가 기준.
+
+### 13. *예외 케이스 인식* — 리뷰어 격려
+
+리뷰어: "*개발자가 알고 있는 경우 외의 예외 케이스는 언제든 발생*할 수 있어서, 코멘트 남겨 둔 내용이었습니다~" — *알고 있는 예외 + 알 수 없는 예외*. *방어적 코딩*의 범위 인식.
+
+## 리뷰어 의견 요지
+
+- ***Controller의 검증 책임*** 점검 — *InputView/도메인*과 분리.
+- **`operator fun contains` *도메인 어휘 일치***.
+- **`let` 보다 *명확한 scope function* (apply/forEach)**.
+- **`fun interface` *SAM 의도 명시***.
+- **`value class` vs `data class` *근거 정리***.
+- **`1..45` 변경 *확장성***.
+- **`InputView/OutputView` *class vs object* 정당화**.
+- **테스트 *랜덤 시나리오***.
+- **매직 넘버 *상수화***.
+- **EOF / 디버깅 코드 *제거***.
+- **`DEFAULT_LOTTO` test fixture**.
+- **`BonusLottoNumber`의 *도메인 의존* 정당화 OK**.
+
+- **대표 인용:**
+  > runCatching을 사용한 이유가 궁금합니다🤔 *해당 내용을 보면 inputView에 대한 Validation 실패인데 과연 해당 내용을 체크해 주는 게 Controller에서 담당해야 할 기능인지*에 대해서도 고민해 볼 필요가 있을 것 같습니다!
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > let을 사용하는 것도 좋기는 하지만 *좀 더 의미를 명확하게* 아래처럼 하는 방법도 있을 것 같아서 참고 부탁드립니다.
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 1..45라는 *최소, 최대값이 만약 바뀌게 된다면, 해당 기능은 사용을 못하게 될 텐데, 확장성을 위해서 고민*을 해 보는 것도 좋을 것 같습니다.
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/LottoNumber.kt`
+
+  > 개발자가 알고 있는 경우 외의 *예외 케이스는 언제든 발생*할 수 있어서, 코멘트 남겨 둔 내용이었습니다.
+  > — @Gyuil-Hwnag (방어적 코딩 격려)
+
+## 얻은 교훈
+
+- **Controller *검증 책임*은 *얇아야*** — *InputView*는 *형식*, *도메인*은 *논리*. *Controller의 runCatching*은 *어느 단계 검증인지* 모호.
+- **`operator fun contains`는 *도메인 어휘 일치*가 정당화** — *Kotlin idiom*만 보고 도입하면 *어휘 충돌*.
+- **`let` 보다 *의도 명확*** — `apply` (this 설정), `forEach`, `also` (부수효과). *Kotlin scope function*은 *부수 의도 차이*가 핵심.
+- **`fun interface` = *SAM 명시*** — *람다로 즉시 사용* 가능. *명시적 단일 메서드*.
+- **`value class`는 *최적화 + 타입 안전*** — `data class`는 *힙 + copy/equals 자동*. *작은 래퍼*에 부적합.
+- **`1..45` *상수 확장성*** — *변경 가능성*이 *낮아도 단일 변경 지점* 가치.
+- **`InputView` *class vs object*** — *변경 가능성*이 *class* 선택 기준.
+- **테스트 *랜덤 시나리오*** — *주어진 값*과 *랜덤 시나리오* 모두. *Random 외부 주입*이 *재현 가능 랜덤*.
+- **매직 넘버 *모두 상수화*** — *-1, 10, 1*도 *의미*가 있으면 상수.
+- **EOF / 디버깅 코드 = *PR 셀프 리뷰 항목***.
+- **`DEFAULT_LOTTO` test fixture** — *공통 데이터 재사용*. PR #21 *MethodSource 지역성*과 함께 *테스트 가독성*의 균형.
+- ***도메인 의존 정당화 = invariant*** — `BonusLottoNumber`가 `winningNumbers` 의존하는 건 *중복 방지 invariant* 표명. 결합도라기보다 *모델링*.
+- **방어적 코딩 = *알 수 있는 + 알 수 없는 예외*** — *방어 범위 자각*이 *과방어 회피*.

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

@@ -0,0 +1,177 @@
+# PR #90 — [오둥이] 2단계 로또
+
+- **Reviewee:** [@murjune](https://github.com/murjune)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/90
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @Gyuil-Hwnag (규일)
+- **라인 코멘트:** 45 (리뷰어 33 + 학생 12)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoCount` value class + `require`** — 리뷰어 칭찬: "require에 대한 활용 *정말* 좋네요👍".
+- **`AutoLottieGenerator` / `ManualLottieGenerator` 인터페이스 분리** — Strategy 시도.
+- **`Thread.setDefaultUncaughtExceptionHandler` 도입** — 학생: "*추가된 이유를 알고 있습니다*🤔".
+- **`tailrec` 키워드** — 재귀 함수 최적화 의식.
+- **`data object` 사용** — Kotlin 1.9+ 어휘 활용.
+- **`@BeforeEach` 테스트 fixture 활용** — 칭찬: "*기능 활용 좋습니다*~👍".
+- **패키지 분리** — 칭찬: "패키지 분리 좋습니다~👍".
+- **`LottoResult` Success/Failure 상태값** — 학생 후속 도입.
+
+## 못한 점 (설계 관점)
+
+### 1. *try-catch 요구사항* — runCatching이 답인가?
+
+리뷰어: "*이번 미션 힌트에서 '일반적인 코틀린 코드에서 try-catch를 사용하지 않는다.'라는 요구사항*이 있는데, *이에 대한 요구사항이 try-catch 대신에 runCatching을 사용하는 것일까??* 고민해 보셔도 좋을 것 같습니다! 관련해서 읽어 보시면 좋은 글 있어서 첨부하였습니다~ https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07" — *Elizarov 글*은 PR #36과 같은 인용 (다른 강사). *catch의 다른 형태가 아닌 본질*: 정상 흐름은 *null + while 패턴*.
+
+### 2. `View`에서 `Int` 반환 — *Int → LottoNumber 추상화*
+
+```kotlin
+class ConsoleLottoGameInputView {
+    fun readWinning(): List<Int> {. }  // ⚠ 원시
+}
+```
+
+리뷰어: "*요구사항에 있는 대로 Int를 LottoNumber로 추상화*해 보는 것도 좋을 것 같습니다!! *과연 해당 로직은 View가 책임을 가지고 있는 게 맞는지도 고민*해 볼 필요도 있겠네요~💪" — *View → Domain 의존*은 허용. *원시값 포장*은 *경계가 명확한 곳*에.
+
+### 3. *Generator 인터페이스 2개* 통합?
+
+```kotlin
+interface AutoLottieGenerator { fun generate(.): List<Lotto> }
+interface ManualLottieGenerator { fun generate(.): List<Lotto> }
+```
+
+리뷰어: "AutoLottieGenerator과 ManualLottieGenerator의 *generate한다는 같은 기능을 가진 인터페이스가 두 가지가 존재*하는데 *두 가지의 인터페이스를 하나로 통합할 수* 있을까요??🤔"
+
+리뷰어 후속 (sealed class 제안):
+```kotlin
+sealed class LottoGeneratorType {
+    data class Manual(val cost: Money): LottoGeneratorType()
+    data class Auto(val lottoNumbers: List<List<LottoNumber>>): LottoGeneratorType()
+}
+
+interface LottoGenerator {
+    fun generate(type: LottoGeneratorType): List<Lotto>
+}
+
+class DefaultLottoGenerator: LottoGenerator {
+    override fun generate(type: LottoGeneratorType): List<Lotto> {
+        return when (type) {
+            is LottoGeneratorType.Manual -> {}
+            is LottoGeneratorType.Auto -> {}
+        }
+    }
+}
+```
+"다만 위와 같은 형태가 되려면 *Lotto와 LottoResult, 수동 & 자동 로또 생성기 등에 대한 코드를 통합하는 작업이 들어가야* 겠군요!"
+
+### 4. `BonusLottoNumber?`, `Count?` *nullable* — Result 타입 권장
+
+```kotlin
+class BonusLottoNumber(lottoNumber: GeneralLottoNumber?,.) {. }
+fun createBonusLottoNumber(): BonusLottoNumber? {. }  // ⚠ nullable
+```
+
+리뷰어 (3회 반복): "BonusLottoNumber를 *nullable하도록 작성하신 이유*가 있을까요??🤔" + "Count도 *nullable*하도록 작성하신 이유가 있을까요??🤔" + "*nullable하게 반환하는 것보다 성공, 실패 등의 상태 등으로 만들어 반영*해 보는 것도 좋을 것 같다는 생각이 듭니다!" 학생 후속: `LottoResult.Success` / `LottoResult.Failure` 도입. 리뷰어 추가: "*LottoResult에 대한 조건이 점점 증가하게 된다면, 그에 따라서 모든 내용을 작성하게 될 수 있으므로 LottoResult.Failure이라는 것으로 한 번에 묶는 것도 고민*해 보면 좋을 듯 싶습니다~"
+
+### 5. *재실행 패턴* — 사용하지 않는 반환값
+
+```kotlin
+private fun readBonusLottoNumber(): BonusLottoNumber? {
+    return runCatching {. }.getOrElse {
+        readBonusLottoNumber()  // ⚠ return을 다시 안 씀
+    }
+}
+```
+
+리뷰어: "사실상 아래의 내용들은 *return을 하지만 전혀 사용을 안 하고 있다*는 생각이 드네요🥲 *재실행을 하더라도 해당 내용들을 유의미하게 사용하여 재실행을 시키는 방법을 고민*해 볼 수 있을 것 같습니다!" + 후속 (오류 메시지 출력): "*BonusLottoNumber의 생성자에서 적용해 둔 '%s: 보너스 번호는 우승 로또 번호와 중복될 수 없습니다.'가 출력이 되도록 구현*해 보는 것도 좋을 것 같습니다~💪" + "*단순 재실행이 아닌 Money에서 정의한 오류 문구를 출력하고 재실행을 시키는 방식*으로 수정해 봐도 좋을 것 같다는 생각이 듭니다~💪" — *재시도와 사용자 피드백*은 별개 책임.
+
+### 6. *팩토리 함수 vs 부 생성자*
+
+```kotlin
+class BonusLottoNumber(.) {
+    companion object {
+        fun of(.): BonusLottoNumber? {. }
+    }
+}
+```
+
+리뷰어: "*팩토리 함수를 만들었지만 현재 팩토리 함수는 부 생성자를 사용하는 것보다 좋은 효과를 보여주지는 않는 것 같*아 보이긴 합니다! (companion object의 of로 해당 BonusLottoNumber를 만들어서 사용하는 것과 *BonumLottoNumber.lottoNumber로 사용하는 것을 비교*해 봤을 때입니다!)" + "*어떤 상황에서 생성자보다 팩토리 함수를 사용하는 것이 더 나을까요*?" + 후속:
+```kotlin
+val bonusLottoNumber = BonusLottoNumber(GeneralLottoNumber(bonusNumber), winningLottoNumbers)
+bonusLottoNumber.lottoNumber.toIntOrNull() ?: createBonusLottoNumber(winningLottoNumbers)
+```
+"*현재 작성해 주신 내용을 보면 팩토리 함수를 만들었지만, '팩토리 함수가 있음으로서 장점이 있는가?'라는 물음에는 해결이 되지 않는 것* 같습니다!!"
+
+→ *팩토리 함수 = 구분되는 의도 (네이밍, 분기, 검증)이 있을 때*.
+
+### 7. *Money/Count 무한 재귀* — 입력 없을 시
+
+리뷰어: "*Validation Check 너무 잘해 주셨네요*~👍 Money와 Count에 대한 *입력은 없을 경우 무한 재귀로 빠지*는군요~" — *재시도 종료 조건* 부재.
+
+### 8. `tailrec` *학생 의도*
+
+리뷰어: "tailrec 키워드를 통해서 *재귀 함수를 호출해 주셨군요*!! 고민해 보면 좋을 내용인 것 같아서 코멘트 남겨 두었습니다~ *tailrec을 사용함으로써 어떤 이점이 존재할까요*??🤔" — *꼬리 재귀 최적화* 이해 점검.
+
+### 9. `data object` vs `object`
+
+리뷰어: "*data object를 사용해 주셨군요*!! 고민해 보면 좋을 내용인 것 같아서 코멘트 남겨 두었습니다~ *object와 data object는 어떤 차이점이 있을까요*?🤔" — `data object`는 *toString, equals 명시 (Kotlin 1.9)*.
+
+### 10. `inline` 함수 *장점*
+
+리뷰어: "inline 함수로 *작성을 해 주셨군요*~ inline 함수를 사용함으로써 *얻을 수 있는 장점은 어떤 것이 있을까요*??🤔 고민해 보면 추후에 좋을 내용인 것 같아서 남겨 두었습니다!" — *고차 함수 호출 비용 회피*.
+
+### 11. `0` 매직 넘버 — `INIT_COUNT` 상수화
+
+리뷰어: "해당 내용에 들어간 *0도 INIT_COUNT (예시) 등으로 묶는 게 가독성 측면에서 이점이 있을지* 고민해 보는 것도 좋을 것 같습니다~"
+
+### 12. *테스트 fixture* 개념
+
+리뷰어: "테스트 코드에 대해서 전반적으로 고민해 보면 좋을 내용인 것 같아서 코멘트 남겨 두었습니다~ *테스트 코드에는 test fixture라는 개념이 존재*하는데 내용을 살펴 보고 해당 내용을 어떻게 수정하면 좋을지 고민해 보시면 좋을 것 같다는 생각이 듭니다!💪" — *공통 테스트 데이터 설정 + 재사용*.
+
+### 13. 테스트 함수명 *모호*
+
+리뷰어: "*해당 테스트 함수를 보고 어떤 기능을 테스트하는 함수인지 알 수 있게 네이밍 고민*해 보셔도 좋을 것 같습니다!🤔"
+
+### 14. *자동 vs 수동 generator 통합*
+
+리뷰어: "프로젝트의 많은 구성이 바뀌겠지만 추후에 *로또 자동, 수동 생성기를 하나의 generate 함수에서 하나로 통합해 보는 작업*을 해 보셔도 좋을 것 같습니다!💪"
+
+## 리뷰어 의견 요지
+
+- ***try-catch 미사용 = catch 표현 회피*** 아니라 *예외 발생 자체 줄이기*. Elizarov 글 권장.
+- **`View`가 *도메인 타입 반환* 가능** — *원시값 포장*은 *경계*에서.
+- **`AutoGenerator` + `ManualGenerator` → *sealed class + 단일 인터페이스***.
+- **`nullable` 반환 → *Result/Success/Failure***.
+- **재시도 패턴 + *오류 메시지 활용***.
+- **팩토리 함수 = *구분 의도가 있을 때***.
+- **`tailrec`, `data object`, `inline` *학습 점검***.
+- **테스트 fixture 활용**.
+- **자동/수동 generator 통합 가능**.
+
+- **대표 인용:**
+  > 이번 미션 힌트에서 "*일반적인 코틀린 코드에서 try-catch를 사용하지 않는다.*"라는 요구사항이 있는데, *이에 대한 요구사항이 try-catch 대신에 runCatching을 사용하는 것일까*??
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 사실상 아래의 내용들은 *return을 하지만 전혀 사용을 안 하고 있다*는 생각이 드네요🥲
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/view/ConsoleLottoGameInputView.kt`
+
+  > 현재 작성해 주신 내용을 보면 팩토리 함수를 만들었지만, *"팩토리 함수가 있음으로서 장점이 있는가?"라는 물음에는 해결이 되지 않는 것 같*습니다!!
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/BonusLottoNumber.kt`
+
+  > 두 가지의 인터페이스를 하나로 통합할 수 있을까요?🤔 (sealed class 예시 포함)
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/LottoGenerator.kt`
+
+## 얻은 교훈
+
+- **`try-catch 미사용` 요구사항 = *catch의 다른 형태가 아닌 본질***. *runCatching*도 *예외 사용*. 정상 흐름은 *null + while* 또는 *Result*.
+- **`View`가 도메인 타입 반환 OK** — *Presentation → Domain 의존*은 허용 (PR #21 galcyurio도 같은 의견).
+- **`sealed class` + *단일 인터페이스*가 *2개 인터페이스 + when 분기*보다 자연**.
+- **`nullable` 반환 → *Result/Success/Failure 상태***. nullable은 *원인 정보 손실*.
+- **재시도 ≠ 사용자 피드백** — `runCatching {. }.getOrElse { recurse() }`는 *오류 메시지 출력*과 *재시도*를 분리.
+- **팩토리 함수 = *생성자보다 의도가 명확*할 때만** — `BonusLottoNumber.of(n)`와 `BonusLottoNumber(n)`이 같은 효과면 *팩토리 무용*. 분기 (`Range A → typeA, Range B → typeB`)나 *서로 다른 입력 변환*일 때 가치.
+- **`tailrec` *꼬리 재귀 최적화*** — JVM에서 *스택 오버플로 회피*.
+- **`data object` = *toString/equals 자동* (Kotlin 1.9)** — *Sentinel 객체* (NONE, EMPTY 등)에 유용.
+- **`inline` 함수 *고차 함수 호출 비용 회피*** — 람다 객체 생성 → 인라인.
+- **재시도 *종료 조건*** — 입력이 없으면 *무한 재귀*. *try N times* 또는 *EOF 처리*.
+- **테스트 *fixture*** — `@BeforeEach`로 *공통 setup*. 또는 *factory function*.
+- **자동/수동 generator 통합 = *Open-Closed*** — *제 3 종류 추가*에도 인터페이스 무변경.

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

@@ -0,0 +1,69 @@
+# PR #20 — [반달] 1단계 로또
+
+- **Reviewee:** [@no1msh](https://github.com/no1msh)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/20
+- **단계:** 1단계
+- **리뷰어:** @woowajames
+- **라인 코멘트:** 49
+
+## 잘한 점
+
+- **`LottoNumber` value class** — 칭찬받음.
+- **`Rank` enum**, `Money`/`Bank`/`Lotto` 분리.
+
+## 못한 점 + 핵심 지적
+
+### 1. lint 실패 다수
+
+> 대부분의 테스트 코드에서 lint 테스트가 실패하고 있습니다. 인텔리제이에서 제공하는 정렬 기능을 습관화하고 이용해보세요.
+
+### 2. 정상 케이스 테스트 누락
+
+```kotlin
+@Test fun `범위 밖이면 예외`() {. }  // 예외만 테스트
+```
+
+> 범위 밖에 있는 경우에 대한 검증을 했다면 범위 내에 에러가 발생하지 않는 검증은 불필요한 검증으로 보입니다. 오히려 create()가 정상적으로 동작했는지에 대한 검증이 필요할 것 같아요. create()의 결과가 무엇이고 제대로 그 결과가 나왔는지 확인해볼까요?
+
+### 3. Money 테스트 — 정상 동작 미검증
+
+```kotlin
+@Test fun `1000원 단위가 아니면 에러`() {. }
+```
+
+> Money 클래스가 어떤 값을 넣어도 에러만 발생하고 있다면 제대로 동작하는 것일까요?
+
+→ *Happy path* 우선, *예외*는 부차.
+
+### 4. Rank 테스트 2등만
+
+→ 모든 등수 테스트.
+
+### 5. `check` 함수명 → Kotlin API와 충돌
+
+```kotlin
+fun check(.) {. }
+```
+
+> check는 코틀린 api로 존재하기 때문에 함수명에 사용하면 오해의 여지가 있을 수도 있을 것 같아요.
+
+→ stdlib과 *동명* 회피.
+
+### 6. RandomLottoGenerator가 다른 클래스 상수 참조
+
+```kotlin
+class RandomLottoGenerator {
+    fun generate(): Lotto {
+        (LottoNumber.MIN..LottoNumber.MAX).shuffled()  // ⚠ LottoNumber 상수 의존
+    }
+}
+```
+
+> 다른 클래스의 상수를 참조해서 사용하면 의존성이 생깁니다. 의존성 주입(메서드 주입)을 받으면 어떨까요?
+
+## 얻은 교훈
+
+- **Happy path 테스트 우선** — 예외만 검증 = 객체가 *제대로 동작하는지* 확신 못함.
+- **stdlib 동명 회피** — `check`, `apply`, `let` 같은 Kotlin 함수와 같은 이름.
+- **다른 클래스의 상수 참조 = 결합도 ↑**. 의존성 주입 또는 자기 상수 보유.
+- **Rank 케이스 전부 테스트** — 각 등수 = 비즈니스 분기.