oh-my-oop 0.2.0

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

@@ -0,0 +1,179 @@
+# PR #122 — [로또 1단계] 크림 미션
+
+- **Reviewee:** [@ijh1298](https://github.com/ijh1298)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/122
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 34
+
+## 잘한 점 (설계 관점)
+
+- **`enum class Rank(countOfMatch, winningMoney, requiresBonusMatch)`** — 보너스 여부를 enum 필드로 흡수.
+- **`PurchasePrice`/`BonusNumber` `value class`** — 원시값 포장.
+- **`fun interface LottoNumbersGenerator`** 도입 (이후 라운드) — 함수형 인터페이스로 SAM 활용.
+- **자가 의문 PR에 풍부히 명시** — *enum의 책임 범위*, *일급 컬렉션 과사용*, *NumericValidator의 위치* 등 학생이 먼저 논점화.
+- **runCatching의 Result API 학습** — `getOrDefault`, `getOrNull`, `exceptionOrNull` 등 학습 흔적.
+
+## 못한 점 (설계 관점)
+
+### 1. `PurchaseLotto`(일급 컬렉션)이 `Lotto` 컬렉션 위에 또 일급 컬렉션
+
+```kotlin
+class PurchaseLotto(val values: List<Lotto>) {
+    override fun toString(): String =.
+}
+```
+
+학생 자가 의문: "단지 toString을 오버라이드 하기 위한 일급 컬렉션 사용에 대해 어떻게 생각하시나요? 이미 일급 컬렉션인 Lotto를 담는 컬렉션을 또 클래스로 감싸고 있는데다 유효성 검증 로직이 없다 보니, 사용하면서 장점보다 단점이 더 많다고 느꼈습니다." 리뷰어: "현재 케이스에서는 이미 Int라는 원시값을 감싼 일급 컬렉션(Lotto)을 만들어 주셨기 때문에, toString을 override 하기 위해 일급 컬렉션으로 다시 감싸는 건 과하다고 생각합니다. 다만, `LottoTicket` 같은 객체로 생성한다면(생성된 로또들의 집합) 해당 객체가 가질 수 있는 역할이 어떤 게 있을까요?" — *역할이 있으면 객체, 없으면 컬렉션*.
+
+### 2. `Lotto(numbers: List<Int>)` — `LottoNumber` 객체 부재 + 범위 검증 자체 수행
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    init {
+        require(numbers.size == LOTTO_SIZE) { INVALID_LOTTO_SIZE }
+        require(numbers.all { it in (1..45) }) { INVALID_LOTTO_NUMBERS }
+        require(numbers.size == numbers.toSet().size) { DUPLICATED_LOTTO_NUMBERS }
+    }
+}
+```
+
+리뷰어: "현재 구조에서는 numbers의 각 원소들이 1~45 사이에 들어간다는 걸 확신할 수 있을까요? 아마 Lotto의 초기화 부분을 보지 않는다면 해당 원소가 1..45에 해당함을 쉽게 알지 못할 겁니다. *로또 번호*라는 객체로 분리하면서 해당 객체가 스스로 할 수 있는 역할에 대해 고민해 보시죠!" — `LottoNumber`를 빼면 *범위*가 타입 책임.
+
+### 3. `NumericValidator` — Validator 클래스 분리
+
+```kotlin
+class NumericValidator(val value: String) {
+    init {
+        require(value.isNotBlank()) { EMPTY_INPUT_ERROR }
+        require(value.toIntOrNull() != null) { NOT_NUMERIC_ERROR }
+    }
+}
+```
+
+학생 답변: "단순 문자열 유효성 검사는 입력단에서 검증하는 게 좋다고 생각했고, 수의 범위나 비즈니스 로직과 관련된 유효성 검증은 모델 객체에서 진행하는 것이 적절하다 생각했습니다!" — 그러나 리뷰어는 추가: "LottoNumber에서 검증하는 건 어떻게 생각하시나요?" + 추가 의견 "지금 NumericValidator의 역할은 String에서 Int로 넘어가는 과정에 문제가 있는지에 대한 검증입니다. LottoNumber를 value class로 정의했기 때문에 Int형을 다루는 검증만 가능한 상태입니다." → 학생도 *value class*의 단일 인자 제약을 의식.
+
+### 4. `Rank` enum의 *책임* — 학생 자가 의문
+
+학생: "enum class는 이름에 맞게 열거만 하는 역할을 하는 것이 좋을까요? 프리코스에서 이 미션을 진행할 때는 Rank 클래스의 프로퍼티로 이 Rank에 해당하는 당첨 개수를 가지도록 두었습니다. 페어와 의견을 맞추면서 매번 enum class가 변경되는 것보다 Map 자료구조를 통해 다른 곳에서 저장하고 있는 게 좋을 것 같다고 생각했으나…" 리뷰어: "가장 중요한 건, **'당첨 개수'는 어느 객체의 역할에 해당하는가?** 입니다. 당첨 개수는 누구의 역할이고 어느 객체가 관심사가 가장 가까울까요?" — 결국 *Rank의 정체성*에 속하므로 enum 필드가 자연스러움.
+
+### 5. `LottoResult`가 `MutableMap`을 *공개*
+
+```kotlin
+class LottoResult(
+    val result: MutableMap<Rank, Int> =
+        Rank.entries.reversed().associateWith { 0 }.toMutableMap(),
+) {. }
+```
+
+리뷰어: "result에 MutableMap 타입이 필요한가요? 외부에서 해당 프로퍼티에 접근하여 내부 값에 직접 접근이 가능한데, 어떤 문제가 발생할 수 있을까요?" 후속: "외부에서 result에 직접 접근해야 할 일이 어떤 게 있을까요? 외부에서 LottoResult 객체 스스로 판단하여 필요로 하는 result 결과값을 함수를 통해 반환해볼 수 있지 않을까요? `private val result: Map<Rank, Int>` 이렇게 되었을 때 외부에서 이루어지는 역할을 LottoResult가 비로소 스스로 일을 하고…"
+
+### 6. `LottoMatchCalculator` — `WinningLotto`의 책임 흡수
+
+```kotlin
+class LottoMatchCalculator(
+    private val purchaseLotto: PurchaseLotto,
+    private val winningLotto: WinningLotto,
+) {
+    fun calculate(): LottoResult {
+        val result = LottoResult()
+        purchaseLotto.values.forEach {
+            result.result[getRank(it)] = result.result.getOrDefault(getRank(it), 0) + 1
+        }
+        return result
+    }
+}
+```
+
+리뷰어: "당첨로또를 계산하는 건 WinningLotto에게 책임을 주어도 가능할 것 같아요. WinningLotto는 당첨번호를 알고 있고, 구매한 로또 정보만 받으면 계산할 수 있지 않을까요?" 학생 결론: "페어와 상의해 보며 '당첨 로또', '구매한 로또들' 이 두 모델 간 의존성을 줄이기 위해 다른 새로운 클래스가 둘을 불러 계산하고 통계를 반영하자고 결론 내렸습니다. 재고해 보니, WinningLotto 클래스가 유효성 검사 외에 큰 역할이 없다는 생각이 듭니다!"
+
+### 7. `LottoGenerator`가 `shuffled()` 내장 — 테스트 불가
+
+```kotlin
+class LottoGenerator(private val money: PurchasePrice) {
+    private fun makeOneLotto(): Lotto {
+        val newLotto = (LOTTO_MIN..LOTTO_MAX).shuffled().take(6)  // ⚠ 내장
+        return Lotto(newLotto)
+    }
+}
+```
+
+리뷰어: "랜덤으로 생성되는 로또는 어떻게 테스트할 수 있을까요? … 테스트가 어려운 코드의 의존관계를 객체 그래프 상위로 이동시키는 내용이 있습니다." 학생 답변: "[Functional interface] 번호를 생성하는 함수 인터페이스만 정의하고, 자동 로또 Generator에서는 이것을 랜덤으로 생성하도록 하고, 수동 로또 Generator에서는 직접 값을 주입할 수 있도록 리팩토링." → `fun interface LottoNumbersGenerator { fun makeLottoNumbers(): Set<LottoNumber> }`.
+
+### 8. `PurchasePrice.STANDARD_AMOUNT_UNIT` 내부 상수
+
+리뷰어: "시간에 따라 가격이 변하거나 가격이 인상되어 비즈니스 로직이 변경됨 위 상황이 발생한다면 상수값을 변경해줘야 할까요? 어떻게 유연하게 대응이 가능할까요?" 후속: "`STANDARD_AMOUNT_UNIT` 자체에 대해 내부 상수로 갖고 있는 것 / 외부에서 주입받는 것 이 두 가지에 대해 고민해 보셔도 좋습니다." 학생 답: `value class PurchasePrice(val value: Int, private val unit: Int = DEFAULT_AMOUNT_UNIT)` — *하지만 value class는 단일 인자*이므로 `value` 키워드 제거 필요.
+
+### 9. `retryWhenException` — *다른 행동* 필요할 때 한계
+
+```kotlin
+fun <T> retryWhenException(action: () -> T, onError: (String?) -> Unit): T {
+    while (true) {
+        runCatching { return action() }.onFailure { onError(it.message) }
+    }
+}
+```
+
+리뷰어: "요구사항에 의해 에러가 발생했을 때 동일 로직이 아닌 다른 형태의 행동을 취해야 한다면 어떻게 될까요? 가령, `금액을 입력받고 올바르지 않은 값이라면 5000원을 기본 시작값으로 설정한다.` hint. runCatching의 반환형태를 살펴보기" — *재시도*만 가능한 함수는 *기본값 사용/조용한 무시* 같은 분기에 무력.
+
+### 10. `Lotto(val numbers: List<LottoNumber>)` — 자료구조로 중복 표현
+
+리뷰어: "Lotto는 하나의 게임(로또번호 6개 묶음)을 이야기하는 거겠죠? 그렇다면 하나의 Lotto 안에 중복되는 LottoNumber는 없다는 이야기가 됩니다. 이것을 자료구조를 사용하여 명확하게 표시하면서도, 로직으로도 중복을 허용하지 않도록 할 수 있을까요?" 학생: "Set 자료구조로 변경 가능할 것 같습니다."
+
+### 11. `LottoMatchCalculator()`가 매번 새로 인스턴스
+
+리뷰어: "LottoMatchCalculator는 매번 인스턴스가 새로 생성되어야 하는 걸까요?" — 상태 없는 협력자는 단일 인스턴스 or `object`.
+
+### 12. `Controller`가 `amount` 직접 계산
+
+```kotlin
+val amount = money.value / PurchasePrice.STANDARD_AMOUNT_UNIT
+return List(amount) { lottoGenerator.makeLotto() }
+```
+
+리뷰어: "Controller가 직접 amount를 계산하는 거에 대해 어떻게 생각하시나요? `val ticket = lottoGenerator.makeLotto(amount, lottoUnit)`" — *나누기*는 도메인 로직(가능 수량 계산), Controller가 알 필요 없음.
+
+### 13. `LottoNumber` Flyweight 부재 — 다음 미션 힌트
+
+리뷰어: "2단계에서 생각해 볼만한 재밌는 요소가 하나 있어요. 로또 번호는 1~45로 정해져 있습니다. 만약 동일한 로또 번호가 다른 게임에도 여러 번 사용이 된다면 해당 로또번호는 다른 객체이어야만 할까요? 로또를 발행할 때마다 새로운 인스턴스가 생성이 된다면 리소스가 많이 들어갈 것 같아요." — 차기 미션 학습 시드.
+
+## 리뷰어 의견 요지
+
+1. **일급 컬렉션은 *역할이 있을 때*** — Lotto 위에 한 번 더 감싸는 것은 *역할이 늘면* OK, 없으면 toString만으로 정당화 X.
+2. **`LottoNumber` 분리 = 범위가 타입 책임** — Lotto가 범위 검증을 하면 캡슐화 손실.
+3. **`Validator` 분리 vs *객체의 자기 검증*** — Validator는 *상태 없는 행위*. 검증을 객체로 옮기면 위치-검증-사용 한 곳.
+4. **Rank의 정체성에 속하는 정보 = enum 필드** — 매번 변경 우려는 *enum 변경에 익숙해지면* 해소.
+5. **`Map`을 외부 노출하지 말 것** — *get* 메서드로 캡슐화.
+6. **`WinningLotto`/`LottoMatchCalculator` 중 *책임의 자연스러운 자리***  — Calculator를 따로 두는 결정이 항상 옳지는 않음, 그러나 *공통 객체*를 만드는 것도 합리적 선택.
+7. **랜덤 의존은 인터페이스로 상위 주입** — `fun interface`로 SAM 활용.
+8. **`PurchasePrice` 상수 외부 주입** — 다중 가격 대응.
+9. **`runCatching`은 *분기*가 가능한 도구** — 재시도만 추출하지 말고 *기본값/조용한 실패*도.
+10. **상태 없는 협력자는 단일 인스턴스** — Calculator가 매번 새 인스턴스일 필요 없음.
+11. **Controller = 조립**, *계산*은 도메인.
+
+- **대표 인용:**
+  > 가장 중요한 건, "당첨 개수"는 어느 객체의 역할에 해당하는가? 입니다. 당첨 개수는 누구의 역할이고 어느 객체가 관심사가 가장 가까울까요?
+  > — @KwonDae on `src/main/kotlin/domain/model/Rank.kt`
+
+  > 다만, LottoTicket 같은 객체로 생성한다면(생성된 로또들의 집합) 해당 객체가 가질 수 있는 역할이 어떤 게 있을까요?
+  > — @KwonDae on `src/main/kotlin/domain/model/PurchaseLotto.kt`
+
+  > 외부에서 result에 직접 접근해야 할 일이 어떤 게 있을까요? 외부에서 LottoResult 객체 스스로 판단하여 필요로 하는 result 결과값을 함수를 통해 반환해 볼 수 있지 않을까요?
+  > — @KwonDae on `src/main/kotlin/domain/model/LottoResult.kt`
+
+  > 의존 관계란 무엇일까요? 현재 `makeLotto()` 함수는 shuffled() 함수에 의존적이어서, 우리는 결과를 예측할 수 없습니다.
+  > — @KwonDae on `src/main/kotlin/domain/service/LottoGenerator.kt`
+
+## 얻은 교훈
+
+- **일급 컬렉션은 *역할*이 있어야 정당화**. `toString`만 위해서면 *함수 확장*이나 `data class`로 충분. 역할이 생기면 그 때 일급 컬렉션으로 승격.
+- **`LottoNumber` 분리 = 범위가 타입에 표현**. `List<LottoNumber>`면 Lotto는 *범위*를 더 이상 검증하지 않음 — 책임이 *수직 단계*로 분리됨.
+- **Validator vs *객체의 자기 검증*** — Validator는 *행위만*. 객체가 검증을 직접 하면 *사용 시점에 보장*. value class의 *단일 인자* 제약이 분리를 강제하는 경우도 있음 — 그건 *제약*이지 *원칙*이 아님.
+- **enum의 필드 = enum이 *반드시* 알아야 하는 정보**. *변경 빈도*에 대한 두려움보다 *책임의 자연성*이 우선.
+- **`Map`/`MutableList`를 외부 노출하지 말 것** — *get*/*sumOf* 같은 함수로 캡슐화. 외부에서 *어떤 자료구조*인지 알 필요 없음.
+- **`WinningLotto`가 행위가 부재하면 *유효성 검사 클래스*** — *Tell, Don't Ask*. 매칭/통계까지 들고 가면 객체가 살아남.
+- **랜덤 의존은 *함수형 인터페이스*** — `fun interface LottoNumbersGenerator { fun makeLottoNumbers(): Set<LottoNumber> }` 한 줄.
+- ***`runCatching`은 try-catch 대체가 아니라 *결과 타입*** — `getOrDefault`/`getOrNull`/`fold`로 분기 표현 가능. 단순 *재시도*만 사용하면 가치 절반.
+- **상태 없는 협력자는 단일 인스턴스 or `object`** — Calculator/Mapper.
+- **Controller = 조립, *계산은 도메인***. `money.value / STANDARD_UNIT`을 Controller가 하면 *나누기 의미*가 도메인 외부로 흐름.
+- **차기 미션 학습 시드** — 1~45 캐싱(Flyweight)은 *원시 도메인이 유한할 때*의 표준 패턴.

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

@@ -0,0 +1,153 @@
+# PR #133 — [로또 2단계] 크림 미션
+
+- **Reviewee:** [@ijh1298](https://github.com/ijh1298)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/133
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 32
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` Flyweight + `private constructor` + `LottoNumber.from(value)`** — 1단계 미션 힌트 반영.
+- **`sealed class PurchasePriceResult` / `ManualLottoAmountResult`** — sealed로 *실패 케이스를 타입화*.
+- **`fun interface LottoGenerator`** + `AutoLottoGenerator`/`ManualLottoGenerator` — Strategy.
+- **runCatching + getOrElse 활용** — `try-catch` 대체.
+- **자가 의문 PR에 풍부히 명시** — *value class vs class*, *생성자 vs 팩토리*, *Exception vs sealed* 등 학생이 먼저 논점화.
+- **현실 비유로 설계 결정 정당화** — "로또 용지에 이상하게 작성해도 가게 주인에게 건네기 전까지는 오류를 인지하지 못한다" — *2번째 방법(일괄 검증)*의 도메인 정당성.
+
+## 못한 점 (설계 관점)
+
+### 1. `value class → class` 변경 — 이유 명시 부재
+
+```kotlin
+// 1단계
+@JvmInline value class LottoNumber(val value: Int)
+
+// 2단계
+class LottoNumber private constructor(val value: Int)
+```
+
+리뷰어: "기존의 value class에서 class로 변경이 되었네요? 어떤 배경이 있었을까요?" 학생 답: "미션 피드백에 주어진 코드를 참고하고 옮기다 보니 value 키워드를 실수로 제거하게 되었습니다. 다시 적용해 보겠습니다." — *실수성 변경*이지만 리뷰어는 *왜를 명시*하기를 기대.
+
+### 2. `ManualLottoGenerator`에 `setManualLottoNumbers` setter
+
+```kotlin
+class ManualLottoGenerator : LottoNumbersGenerator {
+    private var manualLottoNumbers = setOf<Int>()
+    fun setManualLottoNumbers(inputLottoNumbers: Set<Int>) {  // ⚠ setter 패턴
+        manualLottoNumbers = inputLottoNumbers
+    }
+    override fun makeLottoNumbers(): Set<LottoNumber> = manualLottoNumbers.map { LottoNumber.from(it) }.toSet()
+}
+```
+
+학생 의도: "Generator를 한 줄 입력을 단위로 매번 생성해야 하는 불편함이 있었습니다. 따라서 Generator 내에 private 필드를 선언해서, 외부에서 한 줄의 로또 번호를 넣을 수 있게 setter를 구현했습니다." 리뷰어: "수동 로또를 세트로 생성하는 것 또한 수동로또 객체의 역할입니다! 필요한 만큼 로또를 생성해 주도록 하면 어떨까요? `fun makeManualLotto(input:.): List<Lotto>`."
+
+### 3. `Controller`가 `NumericValidator` + `toInt()` 직접 호출
+
+```kotlin
+private fun getManualLottoAmount(purchasePrice: PurchasePrice): ManualLottoAmount =
+    retryWhenException(
+        action = {
+            val input = inputView.readManualLottoAmount()
+            NumericValidator(input)
+            ManualLottoAmount(input.toInt(), purchasePrice.toAmount())
+        },
+        onError = { outputView.printErrorMessage(it) },
+    )
+```
+
+리뷰어: "현재 Controller에서 변환을 직접 담당하고 있는데, `ManualLottoAmount` 객체 스스로가 input에 대해 검증하고, 논리적 오류가 존재하면 예외 처리, 논리 오류가 아니라면 예외 발생을 시키는 게 아닌 다양한 방법으로 대처가 가능할 것 같아요. `String.toInt()`와 `String.toIntOrNull()` 존재가 그 이유입니다." — 검증 + 변환은 *대상 객체의 자기 책임*으로.
+
+### 4. `NumericValidator` — null 처리 vs 예외 발생 혼재
+
+리뷰어: "`NumericValidator` 클래스 또한 논리 오류가 아닌 경우에 어떻게 처리하면 좋을지 고민해 보시죠! 현재는 null 처리와 예외 던지는 로직이 섞여 있네요!" — *비논리적 오류 = null + 재입력*, *논리적 오류 = 예외*. 한 객체 안에 두 흐름이 섞이면 호출자가 *무엇을 받는지* 불명확.
+
+### 5. `AutoLottoGenerator`/`ManualLottoGenerator` — 추상화 깊이가 충분하지 않음
+
+```kotlin
+class AutoLottoGenerator : LottoGenerator {
+    private fun makeRandomNumbers(): Set<Int> = (LOTTO_MIN..LOTTO_MAX).shuffled().take(6).toSet()
+    override fun getLottoNumbers(lottoNumbers: Set<Int>): Set<LottoNumber> = lottoNumbers.map { LottoNumber.from(it) }.toSet()
+    override fun makeLotto(amount: Int): List<Lotto> = List(amount) { Lotto(getLottoNumbers(makeRandomNumbers())) }
+}
+```
+
+리뷰어: "현재 LottoGenerator를 구현하는 AutoLottoGenerator, ManualLottoGenerator의 구현 부분이 정확히 같습니다. 본래의 LottoGenerator는 `로또 번호 생성`에 관심이 있었습니다. 그렇다면 예를 들어, LottoTicket이라는 객체가 존재하여 해당 객체가 Lotto를 관리할 수 있다면 어떨까요? 현실세계에서도 LottoTicket에 여러 개 Lotto가 존재하죠? (최대 5개)" — *Lotto 묶음*은 `LottoTicket`이라는 *자연어 객체*가 자연스럽다.
+
+### 6. 테스트가 *예외 발생*을 검증
+
+```kotlin
+@Test
+fun `구입 금액이 0 이하면 예외가 발생한다`() {
+    assertThrows<IllegalArgumentException> { PurchasePrice(0) }
+}
+```
+
+리뷰어: "이제 논리 오류에 대해 다뤄봤으니, 테스트를 작성하는 관점에서도 살펴볼 만한데요. *도메인을 테스트할 때 예외 발생하는 것*이 중요할까요? 아니면 *구입 금액은 0원 이상*이 의도였을까요?" — 테스트명은 *비즈니스 의도*에 맞춰야.
+
+### 7. `sealed class` 분기 시 모든 분기가 같은 동작
+
+```kotlin
+private fun getPurchasePrice(): PurchasePrice {
+    val input: Int = inputView.readPurchasePrice()
+    return when (val result = input.toPurchasePriceResult()) {
+        is PurchasePriceResult.Success -> result.purchasePrice
+        is PurchasePriceResult.InvalidMinimumPurchaseAmount -> {
+            outputView.printExceptionMessage(result.errorMsg)
+            getPurchasePrice()
+        }
+        is PurchasePriceResult.InvalidThousandWonUnit -> {
+            outputView.printExceptionMessage(result.errorMsg)
+            getPurchasePrice()
+        }
+    }
+}
+```
+
+리뷰어: "현재로서는 요구사항에 `PurchasePriceResult.InvalidThousandWonUnit`일 때 다른 동작을 요구하고 있진 않기에 같은 로직이 수행되고 있네요! 하지만 방향은 정말 좋았어요. … 현재 단계에서는 활용해 주신 것처럼 `runCatching {. }.getOrElse { outputView.printException; getPurchasePrice() }` 정도로도 가능할 것 같아요." — sealed의 가치는 *분기별 다른 동작*이 있을 때 발현. 같은 동작이면 *예외 + 재시도*가 더 간결.
+
+### 8. 학생 자가 의문 — Exception vs sealed
+
+학생: "생성자를 막아버리고 to자료형 같은 함수로만 생성하도록 하는 게 좋은 걸까? 이때까지 프로그래밍하면서 매번 생성자를 사용해 왔는데. 논리적 오류를 방지하는 게 좋지만 Exception 발생은 최대한 피하는 게 좋다 하니, require을 없애고 모두 if 조건문을 통해 sealed class 반환하는 방식으로 바꾸는 게 좋을까?" 리뷰어 답: "Exception 발생은 최대한 피하는 것보다는 *논리 오류가 발생했을 때 예외를 발생시켜 사용자로 하여금 어떤 logical 오류를 범했는지 알려주고자* 하는 의도가 큽니다. 적절한 예외 발생은 필요합니다(ex. 카드 결제 시 잔액부족). API에서 발생할 수 있는 모든 케이스를 Sealed Class로 대응이 가능할까?"
+
+### 9. 두 가지 *수동 로또 검증* 전략 — 학생의 도메인 비유
+
+학생: "1) 한 줄 입력 시 바로 로또 객체 생성 → 즉시 오류 발견 vs 2) 모든 입력 받은 후 Generator가 한꺼번에 생성하며 오류 발견." → "현실 세계에 빗대어보면 *로또 용지에 이상하게 작성하고 있더라도 마지막에 로또 가게 주인에게 건네기 전까지는 오류를 인지하지 못한다*는 점에서 2번도 잘못된 건 아니지 않을까?" 리뷰어: "현실세계에 대입해 고민해 보는 것도 정말 좋았어요. 만약 기능 요구사항에 *오류 발생 시 첫 번째 로또부터 다시 입력*이 요구되어야 한다면, 첫 번째 방법을 채택해야 겠네요. 현업에서 기능을 구현하다 보면 *개발에서의 논리와 현실 세계에서의 논리가 충돌*하는 경우가 종종 있습니다."
+
+## 리뷰어 의견 요지
+
+1. **언어 기능 변경은 *이유*도 함께** — value class → class는 *왜*가 동반되어야.
+2. **setter 패턴은 *시간 결합***  — 객체 생성 시점과 사용 시점 사이에 *순서*가 필요해짐.
+3. **검증 + 변환은 대상 객체의 자기 책임** — Controller에서 직접 toInt + Validator + 생성하는 흐름은 *모든 검증 책임*을 Controller로 끌어옴.
+4. **null vs Exception은 *원인 종류*에 따라** — *비논리적*(형식 X) = null + 재입력, *논리적*(범위 X) = 예외.
+5. **sealed class는 *분기별 다른 동작*이 있을 때 가치** — 동일 동작이면 `runCatching.getOrElse`로 충분.
+6. **예외 발생은 *나쁜 것*이 아니라 *의도된 도구*** — 카드 결제 잔액부족 같은 *비즈니스 오류*에 예외는 적합.
+7. **테스트명 = 의도, 본문 = 의도의 직접 검증** — *예외 발생*은 *수단*, *0원 이상*이 *목적*.
+8. **자연어 객체(`LottoTicket`)가 *반복되는 추상*을 흡수** — Auto/Manual Generator가 거의 같은 코드면 *Lotto 묶음*이라는 더 자연스러운 객체로.
+9. **현실 세계와 코드의 논리가 충돌할 때 = 케이스별 트레이드오프 명시화** — 양쪽 모두 옳을 수 있음.
+
+- **대표 인용:**
+  > 현재 Controller에서 변환을 직접 담당하고 있는데, `ManualLottoAmount` 객체 스스로가 input에 대해 검증하고, 논리적 오류가 존재하면 예외 처리, 논리 오류가 아니라면 예외 발생을 시키는 게 아닌 다양한 방법으로 대처가 가능할 것 같아요. `String.toInt()`와 `String.toIntOrNull()` 존재가 그 이유입니다.
+  > — @KwonDae on `src/main/kotlin/controller/LottoController.kt`
+
+  > `도메인을 테스트할 때 예외 발생하는 것`이 중요할까요? 아니면 `구입 금액은 0원 이상`이 의도였을까요?
+  > — @KwonDae on `src/test/kotlin/domain/model/PurchasePriceTest.kt`
+
+  > 현재 LottoGenerator를 구현하는 AutoLottoGenerator, ManualLottoGenerator의 구현 부분이 정확히 같습니다. … 예를 들어, LottoTicket이라는 객체가 존재하여 해당 객체가 Lotto를 관리할 수 있다면 어떨까요?
+  > — @KwonDae on `src/main/kotlin/domain/service/AutoLottoGenerator.kt`
+
+  > Exception은 좋지 않으니 발생시키지 말자 ❌ 적절한 예외 발생은 필요합니다(ex. 카드 결제시 잔액부족, 잔액 거스름돈)
+  > — @KwonDae on `src/main/kotlin/domain/model/PurchasePrice.kt`
+
+## 얻은 교훈
+
+- **언어 기능 *변경 이유*는 PR/주석에 남기기**. value class → class는 *왜*가 동반되어야 미래의 동료가 의도 추적 가능.
+- **setter 패턴 = *시간 결합***. 생성 시점에 완성되지 않은 객체는 *언제 set 되었는지*에 의존 — 호출자가 *순서*를 보장해야 함.
+- **검증 + 변환은 *대상 객체의 자기 책임***. `PurchasePrice.from(input)`이 `Result`를 반환하면 Controller는 *분기*만 함.
+- ***비논리적 오류*(형식)는 null + 재입력, *논리적 오류*(범위)는 예외**. 둘을 한 함수에서 같이 처리하면 호출자가 무엇을 받는지 모름.
+- **sealed의 가치는 *분기별 다른 행동*** — 모든 케이스가 같은 동작을 한다면 *runCatching 또는 예외*가 더 가벼움.
+- **예외는 *의도된 도구*** — *과도하게 회피*하면 *비즈니스 오류*도 무리해서 결과 타입으로 만들게 됨.
+- **테스트명은 *의도*, 본문은 *그 의도의 직접 검증*** — *예외*는 *수단*, *0원 이상*이 *목적*.
+- **자연어 객체가 *반복되는 추상*을 흡수** — Auto/Manual Generator 구현이 99% 같으면 *Lotto 묶음(LottoTicket)*이 한 단계 위 추상.
+- **현실 세계 vs 코드 논리** — *충돌* 자체가 *설계 의사결정 지점*. 양쪽 가능성을 *명시적으로* 평가하면 *케이스에 따른 정답*이 보임.

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

@@ -0,0 +1,222 @@
+# PR #3 — [써니] 1단계 로또 (초창기 PR)
+
+- **Reviewee:** [@inseonyun](https://github.com/inseonyun)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/3
+- **단계:** 1단계
+- **리뷰어:** @namjackson (잭슨)
+- **라인 코멘트:** 39 (리뷰어 33 + 학생 6)
+
+## 잘한 점 (설계 관점)
+
+- **테스트 케이스 구체** — 리뷰어 칭찬: "구체적인 테스트 케이스 👍".
+- **팩토리 메소드 활용** — 칭찬: "팩토리 메소드 👍 생성자와 같은 역할을 하고 있네요."
+- **자가 질문 풍부** — *InputView 책임*, *원시값 포장 위치*.
+
+## 못한 점 (설계 관점)
+
+### 1. `World` Controller — *god-naming*
+
+```kotlin
+class World(.) {
+    fun processLotto() {. }
+}
+```
+
+→ *"World"는 god-naming*. *책임이 무엇이든* 들어갈 수 있음. PR #2 (DYGames)와 같은 초창기 학생 패턴.
+
+리뷰어: "*makeWinStatistics라는 함수명이지만, 내부 동작은 lotto를 구매하여, 생성하고, 당첨 숫자를 입력받아서, 결과를 리턴하고 있어요! makeWinStatistics에 너무 많은 책임이 있는 것 같아요! 역할마다 분리*해 보면 어떨까요?" + "*써니님이 생각하시는 world 클래스의 역할은 무엇인가요*?"
+
+### 2. *함수 순서* — 코드 읽기 흐름
+
+리뷰어: "함수 순서에 대한 이야기입니다! *개발자들은 보통 코드를 작성하는 시간보다 작성을 위해 코드를 읽는 시간이 훨씬 많다고* 해요! *코드를 읽는 사람의 가독성을 위해, 위에서 아래로 흐름이 흐르도록 순서*를 바꿔 보면 어떨까요? 코틀린 *공식 컨벤션*을 가볍게 읽어 봐도 좋을 거 같아요! https://kotlinlang.org/docs/coding-conventions.html#class-layout"
+
+### 3. `Lotto`의 *범위 + 중복 검증 부재*
+
+```kotlin
+class Lotto(val numbers: List<Int>) {. }  // ⚠
+```
+
+리뷰어 (각각): "*numbers에 1~45 범위가 아닌 수가 들어올 수 있는 구조*네요!" + "*numbers에 중복된 숫자가 들어오는 케이스도 고려*해 보면 좋을 것 같아요!" + "*Lotto, Lottos에서 번호가 일치하는지는 중요한 로직*인 거 같아요! 해당 테스트도 작성해 주시면 좋을 거 같아요!"
+
+### 4. *몇 장 살지 Controller가 결정*
+
+리뷰어: "*정해진 Money에서 몇 장의 로또를 살지를 결정하는 것 또한 모델의 있어야 하는 로직*이 아닐까요? *(View와 도메인을 연결하는 작업 이외의 로직은 최소화로 해 보면 어떨까요?) Lottos 클래스 내의 중복된 로직 또한 있는 것으로 보여요*!"
+
+### 5. `WinNumber` vs `Lotto` *책임 중복*
+
+리뷰어: "*WinNumber와 Lotto와의 책임의 차이는 무엇인가요? 비슷한 책임을 가지고 있는 것 같*아요!"
+
+### 6. `Rank` *bonus 정보 부재* — 2등/3등 구별 불가
+
+```kotlin
+enum class Rank(val countOfMatch: Int,.) {. }
+```
+
+리뷰어: "*2등과 3등은 countOfMatch가 같은데, 어떻게 구별할 수 있을까요? Rank의 가지는 책임이 무엇일까요? bonus에 대한 정보가 없어서 모호*한 것 같아요!" 
+
+리뷰어: 기본값으로 노출 최소화
+```kotlin
+enum class Rank(val countOfMatch: Int, val winningMoney: Int, val matchBonus: Boolean = false) {
+    FIRST(6, 2_000_000_000),
+    SECOND(5, 30_000_000, matchBonus = true),
+    THIRD(5, 1_500_000),
+    FOURTH(4, 50_000),
+    FIFTH(3, 5_000),
+    MISS(0, 0);
+```
+"*기본값을 지정해 주면 불필요한 matchBonus를 노출하지 않아도 되서 좋아요*!"
+
+### 7. *싱글턴 = 강한 커플링*
+
+리뷰어: "*싱글턴 인스턴스로 접근하게 되면, 강한 커플링이 생겨서 결합도가 높아져요*! *싱글턴 인스턴스가 아닌 프로퍼티로 선언하고 참조*하면 어떨까요?"
+
+### 8. `tryAndRerun` 의도와 위험성 — *비입력 코드에 적용*
+
+리뷰어: "*tryAndRerun의 의도는 알겠지만, 조금 위험할 수도 있을 것 같*아요! *bonus볼을 추첨했는데, 이후 로직에서 문제가 생기면, 보너스 볼을 다시 받아야 하는 케이스가 생길 것* 같아요, *의도하지 않은 로직이 중복되어 실행되지 않도록 하는 게 좋지 않을까요*?" + "*tryAndRerun은 잘못된 입력을 다시 받기 위한 로직인 것* 같아요! *입력과 관련된 로직이라면, InputView에서 처리되어야 하지 않을까요*? 특히 이 부분은 *Domain에서 발생하는 로직을 처리하고 있어서, 의도하지 않은 에러 또한 처리*되고 있어요. *의도하지 않은 에러라면 다시 실행되기 보다, 에러를 처리하도록 전달해 줘야 하지 않을까요*?" 
+
+### 9. *Controller가 Lotto 결과로 WinStatistics 조립* — Tell-Don't-Ask
+
+```kotlin
+val statistics = WinStatistics(lottos.value, winNumber)  // ⚠
+```
+
+리뷰어: "*lottos의 value를 받아와서, determine을 통해 WinStatistics 객체를 생성해 주는 동작을 하고 있*네요! *객체에게 메시지를 보내고, 책임을 주어, 서로 협력하는 구조를 만들어 보면* 어떨까요?" + "*lottos의 결과값을 받아와서, WinStatistics을 생성해 주기보단, WinStatistics를 리턴해 주면* 어떨까요? *객체끼리 협력할 수 있도록 작업해 보아요*!"
+
+### 10. *Interface 분리 기준* — YAGNI 원칙
+
+```kotlin
+interface RankDeterminer {. }
+interface ProfitRateCalculator {. }
+```
+
+리뷰어: "RankDeterminer와 *ProfitRateCalculator 인터페이스를 분리하셨네요! 어떤 기준으로 인터페이스를 분리하셨는지 의견이 궁금*합니다!" + "*YAGNI라고, '실제로 필요할 때 무조건 구현하되, 그저 필요할 것이라고 예상할 때에는 절대 구현하지 말라'라는 소프트웨어 원칙을 말하는 의견도* 있어요 :), *예상했던 부분과 다르게 요구사항이 변경될 때, 오히려 예상하여 구현된 부분은 독이 될 수도 있기 때문*인데요, 그렇기 때문에 *예상을 통해 구현하기보다, 객체의 역할과 책임을 분리하여 관리*하도록 하면 좋을 거 같아요! 위 부분의 구현이 잘못되었다고 생각하진 않지만, *인터페이스를 통해 추상화를 하였지만, 구현체만 사용하고 인터페이스는 사용하지 않는 구조*라서 *스타일에 따라서, 인터페이스가 필요한가?라는 의견도 있을 것* 같다는 생각이 들어요!" — *추상화의 정당화*.
+
+### 11. *Set 사용 + 원시값 포장*
+
+리뷰어: "*로또번호인 Int의 원시값을 포장*해 보면 어떨까요?" + "*Bonus로 분리하셨네요! Bonus 또한 하나의 로또 번호라고 볼 수 있지 않을까요*?" + "*로또 번호를 set으로 관리하는 방법도 있는 것* 같아요 :)"
+
+### 12. `Lottos`의 *복합 책임* — *관리 + 생성 + 가격*
+
+리뷰어: "*Lottos에는 로또들을 관리하는 것뿐만 아니라, 로또를 생성해 주는 책임 또한 있는 것 같*아요! *로또 가격을 관리하고, 돈을 받아, 로또를 생성해 주는 책임은 다른 클래스로 나누는 것*도 고민해 보면 좋을 거 같아요!"
+
+### 13. `LottoPrice`의 *음수 가능성*
+
+```kotlin
+class LottoPrice(val value: Int)  // ⚠ 검증 부재
+```
+
+리뷰어: "*원시값 포장의 장점을 고민해 보시면 좋을 것* 같아요! *LottoPrice에 음수가 들어갈 수 있을까요*?"
+
+### 14. *방어적 코드 vs 미래 팀원*
+
+리뷰어: "*생성을 막았더라도, 이후 팀원들 등으로의 인해 의도치 않은 코드가 들어올 수 있다고* 생각해요! *당장의 구조에는 검증의 필요성이 없을지라도, 방어적 코드가 있으면 좋을 거 같*아요!"
+
+### 15. `RankTest`이지만 *LottoRankDeterminer 테스트*
+
+리뷰어: "*RankTest이지만, 실제로는 LottoRankDeterminer의 테스트로 보여지네요*!"
+
+### 16. *테스트 중복 초기화*
+
+리뷰어: "*중복된 초기화 작업이 보이*네요! *@before을 통해 테스트 초기화 작업을 할 수 있*습니다!"
+
+### 17. *given/when/then 테스트 구조*
+
+```kotlin
+@Test
+fun `로또 번호와 당첨 번호의 일치 개수를 반환한다`() {
+    val lotto =.
+    val winLotto = WinLotto(.)
+    val result = lotto.determineCountOfMatch(winLotto.winNumber)
+    assertThat(result).isEqualTo(6)
+}
+```
+
+리뷰어:
+```kotlin
+// given 
+val lotto = Lotto.from(.)
+val winLotto = WinLotto(.)
+// when
+val result = lotto.determineCountOfMatch(winLotto.winNumber)
+// then
+assertThat(result).isEqualTo(6)
+```
+"*테스트 코드의 가독성과 관리를 위해 준비/실행/검증부를 나눠 보면* 어떨까요? *무엇을 테스트하는지, 무엇을 검증하는지 명확*해질 수 있을 것 같아요!" — PR #123 (Gyuil-Hwnag).
+
+### 18. `List(lottoCount) Builder`
+
+리뷰어: "*List(lottoCount) Builder를 사용해 보셔도* 좋을 것 같아요!".
+
+### 19. *팩토리 함수에 `List<Int>` 받기*
+
+리뷰어: "팩토리 메소드 👍 *생성자와 같은 역할*을 하고 있네요. *List<Int>를 받아서 변환*해 보면 어떨까요?"
+
+### 20. 학생 *반복 입력 자가 의문* + 잭슨 답
+
+학생: "InputView에 관해 *질문드리고 싶은 게 있*습니다! 사실 *요구사항에는 '입력에 대한 예외 발생 시 다시 입력을 받아야 한다'라는 말이 없*어 항상 해당 로직을 구성할 때 의문점이 생기곤 합니다! 크루들 사이에도 이와 관련해서 *말이 많이 오가고*, 대게는 '*나중에 이러한 요구사항이 생길 때를 대비하자*'라는 말이 오간 것을 들었는데, *요구사항에는 없는 반복 입력을 계속 냅두는 게 맞는 것일까요.?* 아니면 *예외 처리를 해 프로그램 동작이 멈추게 하는 것이 맞을까요*."
+
+잭슨 답: "사실이 *요구사항에 존재 없기 때문에, 구현하지 않아도 되지만, 사용성을 고려하는 부분은 좋은 거 같*아요! 현업에서도 *요구사항에 없는 부분도 고려하여, 다른 관계자들과 적극적으로 커뮤니케이션*하기도 합니다. 하지만, *예측하지 못한 에러의 경우에는 의도치 못한 동작을 하게 되는데요, input에 대한 에러뿐 아니라, 다양한 에러에서도 tryRerun이 동작하기 때문에 의도하지 않은 동작의 가능성도 있지 않을까요*?" — PR #49 (잭슨, 써니 2단계)와 *직접 연결*.
+
+### 21. 학생 *InputView 책임 자가 의문* + 잭슨 답
+
+학생: "또, *InputView에서 입력 받은 원시값을 넘겨주는 것이 아닌 포장된 PurchaseMoney나 Lotto, LottoNumber를 넘겨주는 것과 입력에 대한 검증을 수행하는 것이 올바른 InputView의 책임인지 의문*이 듭니다!"
+
+잭슨 답: "*입력값 검증에 대한 부분은 View에도 있어도 되지만, 입력 시 검증하더라도 도메인에서 처리될 부분*이라고 생각이 들어요! *원시값을 포장 또한 도메인 영역에서 진행되어야 책임이 있지 않을까* 생각합니다!"
+
+### 22. *책임 분리 전반 평가*
+
+리뷰어 (전반 코멘트): "*구현에는 정답이 없기 때문에, 다양한 구조가 될 수 있*어요! 다양한 구조 들 중 *각각의 구현 방법 중 장단점을 비교해서, 써니님 만의 우선순위나 규칙, 코딩 철학을 고민*해 보시면 좋을 거 같아요! 저의 개인적인 생각으로는, *makeWinStatistics에 당첨에 대한 로직이 모두 있었지만, makeWinStatistics는 컨트롤러 내에 구현되어 있기 때문에, 테스트로 검증하기 힘들뿐더러, 컨트롤러에서 View 관련 코드와 도메인 로직들이 다양하게 실행되고 있었던 거 같*아요! 각 *모델들에게 책임을 나누었기 때문에, 테스트할 수 있는 구조가 된 것 같아서 개선되었다고 생각이 들어요*!"
+
+## 리뷰어 의견 요지
+
+- ***"World" god-naming***. 책임 모호.
+- **함수 순서 = *호출 흐름*** (Kotlin 컨벤션).
+- **`Lotto` *범위/중복/개수* 검증 셋 다**.
+- **장수 결정 = *도메인 책임***.
+- **`WinNumber` vs `Lotto` *책임 중복*** 정리.
+- **`Rank` *bonus 정보*** + *기본값으로 노출 최소화*.
+- **싱글턴 = *강한 커플링*** — *프로퍼티 주입*.
+- **`tryAndRerun` *Domain 적용 위험***.
+- **Tell, Don't Ask** — `lottos.determine(winningLotto)`.
+- **YAGNI** — *구현체만 쓰는 인터페이스*.
+- **원시값 포장 + Set**.
+- **`Lottos` *복합 책임* 분리**.
+- **`LottoPrice` 음수 검증**.
+- **방어적 코드 *미래 팀원*** 고려.
+- **테스트 이름 = *실제 테스트 대상*과 일치**.
+- **`@BeforeEach` 중복 제거**.
+- **given/when/then**.
+- **`List(n) { }` Builder**.
+
+- **대표 인용:**
+  > 개발자들은 보통 *코드를 작성하는 시간보다 작성을 위해 코드를 읽는 시간이 훨씬 많다고* 해요!
+  > — @namjackson on `src/main/kotlin/lotto/controller/World.kt`
+
+  > YAGNI라고, *"실제로 필요할 때 무조건 구현하되, 그저 필요할 것이라고 예상할 때에는 절대 구현하지 말라"*라는 소프트웨어 원칙을 말하는 의견도 있어요.
+  > — @namjackson on `src/main/kotlin/lotto/domain/RankDeterminer.kt`
+
+  > 싱글턴 인스턴스로 접근하게 되면, *강한 커플링이 생겨서 결합도가 높아져*요!
+  > — @namjackson on `src/main/kotlin/lotto/domain/LottoMachine.kt`
+
+  > 다양한 구조 들 중 각각의 구현 방법 중 장단점을 비교해서, *써니님 만의 우선순위나 규칙, 코딩 철학을 고민*해 보시면 좋을 거 같아요!
+  > — @namjackson (PR 전반 평가)
+
+## 얻은 교훈
+
+- **"World" god-naming = lotto 초창기 (#2, #3) 공통 안티** — *책임 무경계*. *Application/Controller* 같은 *기능 단어*가 자연.
+- **함수 *호출 순서대로 배치* (코틀린 컨벤션)** — *읽기 시간 >>> 쓰기 시간*. 위에서 아래로.
+- **`Lotto` 도메인 invariant = *3개* (개수/범위/중복)** — 모두 *init*에서. *원시값 포장 + Set*은 *invariant 일부를 타입으로 표현*.
+- **장수 결정 = *도메인 책임*** — `purchaseMoney.getLottoCount()`. Controller에 두면 *Tell-Don't-Ask 위반*.
+- **`Rank` 기본값 매개변수로 *노출 최소화*** — `matchBonus: Boolean = false`로 *MISS/FIRST/THIRD/FOURTH/FIFTH*에 noise 제거.
+- **싱글턴 = *강한 커플링*** — *프로퍼티 주입*이 *대체 구현체 가능*.
+- **`tryAndRerun` *적용 영역*** — *입력 경계*에만. *도메인 영역에 적용*하면 *의도 외 에러*까지 재실행.
+- **Tell, Don't Ask** — `lotto.determine(winLotto)`. `controller.organize(lotto.value,.)` 안티.
+- **YAGNI** — *예상으로 인터페이스* 도입 시 *구현체만 사용*하면 부담. *변경 가능성이 실제*일 때만.
+- **`Set` = *중복 방지 invariant***.
+- **`Lottos` *복합 책임* (관리 + 생성 + 가격)** = 분리.
+- **`LottoPrice` 음수 검증** — *원시값 포장의 본질*은 *invariant*. 검증 없으면 wrapper.
+- **방어적 코드 *미래 팀원* 고려** — *현재는 안 깨지더라도* *수정 시 깨질 가능성*.
+- **테스트명 = *실제 SUT*** — `RankTest`이지만 *LottoRankDeterminer 테스트*면 *오해 유발*.
+- **`@BeforeEach` 중복 제거**.
+- **`given/when/then`** — *3구역 분리*가 *유기적 객체 테스트* 가독성.
+- **`List(n) { gen() }`** — Kotlin idiom.