oh-my-oop 0.2.0

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

@@ -0,0 +1,167 @@
+# PR #50 — [스캇] 2단계 로또
+
+- **Reviewee:** [@chws0508](https://github.com/chws0508)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/50
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 23 (리뷰어 19 + 학생 4)
+
+## 잘한 점 (설계 관점)
+
+- **원시값 포장** — 리뷰어 칭찬: "*원시값을 잘 포장해 주셨네요* 👍".
+- **인터페이스 + 테스트** — 칭찬: "*모든 로직에 테스트 코드를 작성하기 위해 인터페이스를 구현해 주신 점 좋습니다* 👍".
+- **`IllegalStateException`** — 칭찬: "*IllegalArgumentException보다는 IllegalStateException이 더 적합해 보이네요* 👍".
+- **`Result` 타입 활용** — 칭찬 + 의미 검토 요구.
+
+## 못한 점 (설계 관점)
+
+### 1. `validate*` *검증 + 변환* — 두 책임
+
+```kotlin
+fun validateBonus(input: String): Int {  // ⚠
+    require(.)
+    return input.toInt()
+}
+```
+
+리뷰어: "*함수명만 봤을 때에는 '보너스볼 유효성을 체크한다'라는 의미로 보여요*. 하지만 함수 구현부를 보면, *유효성을 체크할 뿐만 아니라 다른 값으로 변환해서 리턴*을 해 주고 있네요. *하나의 함수에서는 한 가지 일만 하도록* 코드를 개선해 보면 어떨까요?"
+
+### 2. *예외 처리 두 분류* — Elizarov 인용
+
+리뷰어: "*코틀린에서 예외를 처리하는 방법은 크게 두 종류*가 있습니다.
+- *오류가 예상되는 경우*
+- *오류가 예상되지 않는 경우*
+
+오류가 예상되는 경우에는 주로 *null 또는 기본값을 리턴*합니다. 반면, 오류가 예상되지 않는 경우에는 *Exception을 던지고 이 Exception을 개발자에게 알려서 문제를 빠르게 파악*하도록 합니다. *Exception은 반드시 예외적인 상황에서만 사용*하는 것이 좋습니다. ref. *https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07*".
+
+### 3. `Result` 타입 *남용*
+
+리뷰어: "*Result 타입을 잘 활용*해 주셨네요. 👍 *Result 타입은 성공(success)과 실패(failure) 두 가지 경우를 나눠서 처리할 수 있는 장점*이 있습니다. 특히, *어떤 경우에 실패가 발생하는지 모르는 경우에 활용하기 좋*습니다. 하지만, *여기에서는 Result 타입을 사용함으로써 얻는 장점이 없어 보입니다. Result 타입을 사용하지 않고 코드를 개선*해 보면 어떨까요?" — *Result는 실패 종류 추상화*. *단순 시점*에선 *null/기본값*.
+
+### 4. *runCatching = try-catch*
+
+리뷰어: "*runCatching은 내부적으로 try-catch 문으로 구현*되어 있어요. 프로그래밍 요구사항 중 아래와 같은 항목이 있습니다. *'일반적인 코틀린 코드에서 try-catch를 사용하지 않는다.'* 이 요구사항을 반영해 보면 어떨까요?". (`runCatching`도 *catch 표현*).
+
+### 5. *상수 `private` 접근자*
+
+리뷰어:
+```kotlin
+private const val UNKNOWN_ERROR = "알 수 없는 오류입니다"
+```
+"*클래스 내부에서만 사용하는 값이라면 private 접근자를 붙여 보면 어떨까요*?" + "*private 접근자가 없으면 외부에서 접근이 가능하게 되고, 그렇게 되면 해당 변수 값의 변경으로 인하여 의도치 않게 다른 클래스에 영향*을 미치게 됩니다. *가급적이면 private를 붙여서 작성하고, 외부에서 접근하는 경우에 private를 지우는 습관*을 들이는 것을 권장합니다.".
+
+### 6. *Controller가 RankStatistics 구하는 로직 너무 잘 앎*
+
+리뷰어: "*Controller가 RankStatistics를 구하는 로직을 너무 잘 알고 있어요. RankStatistics를 구하는 로직은 RankStatistics에서 구하도록* 코드를 개선해 보면 어떨까요?"
+
+### 7. *Validation 클래스 분리* — 추가 객체 의무
+
+```kotlin
+class LottoValidation {. }  // ⚠ 도메인마다 별도
+```
+
+리뷰어: "코드를 보니 *XXXValidation이라는 클래스들을 구현*해 주셨네요. 이런 구조라면, *도메인 클래스가 생성될 때마다 매번 Validation 클래스가 생성되어야 할 것* 같아요. 또한 *Lotto에 요구사항이 변경된다면, Lotto 클래스와 LottoValidation 클래스 둘 다 변경*해야 하는 상황이 발생하게 됩니다. *Validation 클래스의 존재 여부에 대해서 다시 한번 고민해 보시고, LottoValidation 클래스가 하는 일을 Lotto 클래스에서 하도록* 코드를 개선해 보면 어떨까요?" 
+
+### 8. *NOT_INTEGER_ERROR 상수 여기저기*
+
+리뷰어: "*NOT_INTEGER_ERROR라는 상수값이 여기저기 정의가 되어 있어요. 지금 구조에서는 만약 정수가 아닌 소수를 입력하라는 요구사항이 생긴다면, 관련 문구를 일일이 찾아서 변경해 줘야 해요*. *출력과 관련된 문구는 OutputView에서 관리하도록* 코드를 개선해 보면 어떨까요?"
+
+### 9. `.toList()` *불필요 호출*
+
+```kotlin
+(MIN..MAX).toList().shuffled()  // ⚠
+```
+
+리뷰어:
+```kotlin
+val possibleLottoNumbers = MINIMUM_LOTTO_NUMBER..MAXIMUM_LOTTO_NUMBER
+return Lotto(possibleLottoNumbers.map { LottoNumber(it) }.shuffled().take(LOTTO_NUMBER_COUNT))
+```
+"*모든 컬렉션과 관련된 함수들(map, shuffled, take 등)은 매번 복사본을 만들게* 됩니다. 따라서, *toList 함수를 호출하지 않으셔도 됩니다*.".
+
+### 10. *로또 시작/끝 값 여기저기*
+
+리뷰어: "*로또의 시작값과 끝값이 여기저기 정의*가 되어 있습니다. *로또의 시작값과 끝값이 변경되게 되면, 관련 값을 일일이 찾아서 수정*해 줘야 합니다." — 단일 진입점.
+
+### 11. *InputView/Output 인터페이스 이유*
+
+리뷰어: "*InputView와 Output의 Interface를 만들어 주셨네요. 이와 같은 구조로 작성하게 되면 어떤 이점이 있을까요*?" — 학생 자가 정리 권유.
+
+### 12. `var` vs `val` *컬렉션*
+
+```kotlin
+var lottos: List<Lotto> = listOf()
+```
+
+리뷰어: "*List, Map과 같은 컬렉션은 내부적으로 데이터를 추가하거나 삭제하는 함수를 제공*해요. 그렇기 때문에 *var 대신 val을 사용*하는 것을 권장해요." — *List += newItem* 같은 *재할당 회피*.
+
+### 13. *간접 호출 = 너무 많은 함수 분리*
+
+리뷰어: "*함수명만 봤을 때에는 'RankInformation을 초기화한다'라는 의미로 보이는데요*. *실제 구현부에서는 RankCount를 업데이트*하고 있네요. *함수를 최대한 작은 단위로 나누는 것도 좋지만, 너무 나누게 되면 '간접 호출'이 되어 오히려 코드를 알기 더 어렵게* 만듭니다." — PR #131 (krrong) *함수 분리 vs 분해*와 같은 결.
+
+### 14. *Interface 명에 'Interface' 붙임*
+
+리뷰어: "*인터페이스명에 굳이 Interface라고 명시하지 않으셔도* 됩니다." — Kotlin 컨벤션.
+
+### 15. *클래스 헤더 가독성*
+
+```kotlin
+class WinningNumber(private val lottoNumbers: List<LottoNumber>, private val bonusNumber: LottoNumber) : Lotto(lottoNumbers) {
+```
+
+리뷰어:
+```kotlin
+class WinningNumber(
+    private val lottoNumbers: List<LottoNumber>, 
+    private val bonusNumber: LottoNumber
+) : Lotto(lottoNumbers) {
+```
+"*가로로 너무 길어질 경우에는 개행을 하는 것을 권장*해요. ref. https://kotlinlang.org/docs/coding-conventions.html#class-headers"
+
+## 리뷰어 의견 요지
+
+- **`validate + 변환` *한 함수에 두 일* X**.
+- **예외 처리 *두 분류*** — Elizarov.
+- **`Result` *남용*** — *실패 종류 추상화 시*만.
+- **`runCatching` = *try-catch 변형*** — 요구사항 위배.
+- **상수 *private* 기본**.
+- **Controller가 *도메인 로직 너무 앎***.
+- **`Validation` 별도 클래스 = *책임 분산***.
+- **상수 *단일 진입점*** (위치 + 변경).
+- **`.toList()` *Kotlin 컬렉션 함수 자동 복사*** 무지.
+- **인터페이스 *이점 자가 정리***.
+- **컬렉션 `val`** (var X).
+- **너무 잘게 나눈 함수 = *간접 호출 비용***.
+- **Interface 명에 'Interface' 붙이지 않기**.
+- **클래스 헤더 *개행 가독성***.
+
+- **대표 인용:**
+  > 코틀린에서 예외를 처리하는 방법은 크게 두 종류가 있습니다.
+  > - 오류가 예상되는 경우
+  > - 오류가 예상되지 않는 경우
+  > — @BeokBeok on `src/main/kotlin/lotto/util/Validation.kt`
+
+  > 함수를 최대한 작은 단위로 나누는 것도 좋지만, *너무 나누게 되면 '간접 호출'이 되어 오히려 코드를 알기 더 어렵게* 만듭니다.
+  > — @BeokBeok on `src/main/kotlin/lotto/domain/RankInformation.kt`
+
+  > LottoValidation 클래스가 하는 일을 *Lotto 클래스에서 하도록* 코드를 개선해 보면 어떨까요?
+  > — @BeokBeok on `src/main/kotlin/lotto/util/LottoValidation.kt`
+
+  > runCatching은 *내부적으로 try-catch 문으로 구현*되어 있어요. 프로그래밍 요구사항 중 '일반적인 코틀린 코드에서 try-catch를 사용하지 않는다.'.
+  > — @BeokBeok on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **`validate + 변환` 분리** — *함수 한 가지 일*. `validateAndConvert` 또는 *두 함수*.
+- **예외 처리 = *예상 vs 예상 외*** — Elizarov 글. *PR #5, #36, #90, #50 공통 인용*.
+- **`Result` *남용 회피*** — *실패 종류 추상화*가 가치. *단순 시점*은 *null + while*.
+- **`runCatching` = *try-catch 표현*** — 요구사항이 *try-catch 금지*면 *runCatching도 회피*.
+- **상수 *private 기본*** — *외부 접근*이 필요할 때만 풀기.
+- **Controller *도메인 로직 무지*** = *Tell-Don't-Ask*.
+- **`Validation` 별도 클래스 = *변경 다중 지점*** — 도메인 객체 *init*이 *책임 응집*.
+- **상수 *단일 진입점***.
+- **`.toList()` *Kotlin 컬렉션 함수가 자동 복사*** — 불필요 호출 알아채기.
+- **컬렉션 `val`** — `List`/`Map` 자체가 *불변*. 변경 메서드는 `MutableList` 사용.
+- **너무 잘게 나눈 함수 = *간접 호출 비용*** — *읽기 부담* > *재사용 가치*.
+- **Interface명에 *Interface* 붙이지 않기** — Kotlin 컨벤션.
+- **클래스 헤더 *개행*** — *가로 길이*는 *가독성*에 직접.

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

@@ -0,0 +1,155 @@
+# PR #116 — [로또 1단계] 오이 미션
+
+- **Reviewee:** [@cucumber99](https://github.com/cucumber99)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/116
+- **단계:** 1단계
+- **리뷰어:** @lee-ji-hoon (코니)
+- **라인 코멘트:** 32
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` `value class`** — 원시값 포장 + 인라인 최적화.
+- **TDD 흐름 첫 시도** — 학생 PR: "테스트 코드 작성 → 도메인 로직 작성 → 테스트 성공 시 리팩토링을 반복."
+- **`Lotto.countMatchingNumber`/`checkBonusNumber`** — Tell, Don't Ask 적용.
+- **`enumValues<Rank>().associateWith { 0 }` 초기 Map** — 함수형 어휘.
+- **`groupingBy {. }.eachCount()`** — 누적 패턴 압축.
+- **자가 의문 PR에 풍부히 명시** — *value class*, *test의 가독성*, *MVC 역할 경계*, *드라이버/네비게이터* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. `Amount`라는 이름 — 도메인 어휘 모호
+
+```kotlin
+class Amount(val money: Int) {
+    init { require(money >= LOTTO_PRICE) }
+}
+```
+
+리뷰어: "`Amount`라는 네이밍만 봤을 때는 그냥 단순 `가격`을 의미하는데 로또의 가격을 관리하는 게 맞는가? 라는 생각이 드는데요. 제가 왜 이런 느낌이 들었는지 생각해 보시면 좋을 거 같습니다." — `Amount`는 *수량/금액 일반*. `PurchaseAmount`/`LottoPurchasePrice` 같이 *무엇의*가 붙어야 도메인 어휘.
+
+### 2. `Amount`는 `class`, `LottoNumber`는 `value class` — 일관성
+
+리뷰어: "`Lotto`에는 value class인데 여기는 value class가 아니더라고요. 어떤 이유일까요?" 학생 답: "LottoNumber는 사용되는 곳이 많아서 성능 고려. `Amount`는 단 한 번만 사용된다고 생각해서." — *사용 빈도*에 따른 선택. 그러나 *원시값 포장 의도*는 동일.
+
+### 3. `LottoMatcher.calculateRank` — `public` 테스트 노출
+
+```kotlin
+class LottoMatcher(.) {
+    fun matchLotto(publishedLotto: List<Lotto>): Map<Rank, Int> {. }
+    fun calculateRank(lotto: Lotto): Rank {. }  // ⚠ matchLotto에서만 사용
+}
+```
+
+리뷰어: "이 함수는 `matchLotto`에서만 사용하기에 private이어야 할 거 같은데 테스트를 위해서 열려 있는 모습입니다. 만약 기존에 private였는데 테스트를 위해서 public으로 변경을 하게 된 것이라면 `private 함수를 왜 테스트해야 하나?`라는 질문을 먼저 해 보면 좋을 거 같은데요. 이 함수는 애초에 별도의 책임의 일부로서 원래는 다른 클래스에 들어 있어야 했던 것이거나 테스트가 불필요한 것일 겁니다." — *테스트 가능성 = 책임 분리 신호*.
+
+### 4. `LottoMatcher`에 `MutableMap` rankMap 보유
+
+```kotlin
+private val rankMap: MutableMap<Rank, Int> = enumValues<Rank>().associateWith { 0 }.toMutableMap()
+
+fun matchLotto(publishedLotto: List<Lotto>): Map<Rank, Int> {
+    publishedLotto.groupingBy { calculateRank(it) }.eachCount()
+.forEach { (rank, count) -> rankMap[rank] = count }
+    return rankMap
+}
+```
+
+`rankMap`이 *함수 호출마다 누적*되는 시간 결합. 학생도 후속 라운드에서 `Map<Rank, Int>` 반환으로 수정.
+
+### 5. `LottoMachine`이 랜덤 내장 — 테스트 불가 (TDD 부정합)
+
+```kotlin
+class LottoMachine {
+    private val numbers: List<LottoNumber> = (MIN..MAX).map(::LottoNumber)
+    private fun publishLotto(): Lotto = Lotto(numbers.shuffled().take(6).sortedBy { it.value })
+}
+```
+
+리뷰어: "로또의 도메인을 생각해 봤을 때 `랜덤으로 만들어지는 로또 번호`도 하나의 도메인적인 내용이라고 생각을 하는데요. 이것에 대한 테스트는 지금 없고 불가능한 상황으로 보여요. 그러면 어떻게 하면 테스트가 가능할까 고민해 보면 좋을 거 같습니다." 후속: "TDD 관점에서 다시 생각을 해 볼까요? 처음에 만들어질 때 `LottoMachine`은 랜덤된 숫자를 가진 `Lotto`를 반환할 것이다라고 생각을 하고 시작을 했을 거 같아요. 그러면 `랜덤된 숫자`가 이 `LottoMachine`의 핵심일 수도 있겠네요. 그래서 이 Machine이 진짜로 TDD로 작성이 된 게 맞을까? 라는 의구심에 드렸던 질문입니다." — TDD = *테스트가 먼저*인데 핵심이 테스트 불가면 *TDD 부정합*.
+
+### 6. `OutputView`가 도메인 모델 직접 받음
+
+```kotlin
+fun printPublishedLotto(quantity: Int, publishedLotto: List<Lotto>) {
+    println("${quantity}개를 구매했습니다.")
+    publishedLotto.forEach { lotto -> println(lotto.numbers.map { it.value }) }
+}
+```
+
+리뷰어: "모델이 가지고 있는 정보를 전달받게 한다면 어떨까요? 단순 표시해야 될 `List<String>`을 받는다면 어떨지 고민해 보면 좋을 거 같습니다!" 후속: "View가 Model을 모르게 하기 위해서 노력을 해 주신 거 같아요. 그런데 이렇게 됐을 때 View의 관심사가 어느 정도 Controller로 가는 것은 아닐까? 라는 것을 생각해 보면 좋을 거 같네요. 가령 `LottoController`의 `publishLotto` 함수가 `printPublishedLotto`에 데이터를 넣어 주기 위해서 Model을 가공해 주고 있는데 이게 Controller의 역할이 맞을까?" — Model → View 직접 vs Controller 변환은 *트레이드오프*.
+
+### 7. `Lotto.from(input: List<Int>)` 외에도 생성자 노출
+
+```kotlin
+class Lotto(val numbers: List<LottoNumber>) {
+    companion object { fun from(input: List<Int>): Lotto = Lotto(input.map(::LottoNumber)) }
+}
+```
+
+리뷰어: "`companion object`의 from으로 누군가 `Lotto`라는 것을 생성할 때 이 함수를 통해서 생성하라! 라고 만들어 주신 거 같아요. 근데 지금 상황에서는 `Lotto`에 그냥 접근이 가능하다 보니 일반적인 생성도 가능할 거 같아요. … 오이의 생각과 다르게 model을 쓰는 경우가 생길 수도 있을 거 같은데요!" 학생: "생성자를 `private`으로 선언하면 `Lotto("tester")`와 같은 일반적인 생성은 방지." — 의도 강제는 *private constructor + factory*.
+
+### 8. `PrizeCalculator` — 책임 흩어짐
+
+```kotlin
+class PrizeCalculator {
+    fun calculateEarningRate(money: Int, result: Map<Rank, Int>): Double {. }
+}
+```
+
+리뷰어: "전체적인 Model을 봤을 때 너무 과하게 흩어져 있는 것 같다는 느낌을 받았는데요. `PrizeCalculator`은 수익률을 결정하고 있는 `Model`인데요. 수익률은 로또 결과를 만드는 역할을 하는 곳 내부에 있어야 하는 비즈니스적인 로직이 아닐까? 라는 생각이 들어요." + "혹은 Util의 느낌이 강하긴 하네요." 학생: "`LottoMatcher`에 수익률 계산까지 부여하면 `LottoMatcher` 자체가 너무 커질 것 같아서 우선은 분리. 특히 다루는 상태가 없고 단순 계산만 수행하기 때문에 Util의 느낌." — *Util*은 *행위*만, *Model*은 *상태 + 행위*.
+
+### 9. `LOTTO_NUMBER_COUNT` 중복 선언 — `Lotto`와 `LottoMachine`
+
+```kotlin
+class Lotto { companion object { private const val LOTTO_NUMBER_COUNT = 6 } }
+class LottoMachine { companion object { private const val LOTTO_NUMBER_COUNT = 6 } }
+```
+
+리뷰어: "`LottoMachine`의 `LOTTO_NUMBER_COUNT`를 7로 변경을 해 봤을 때 `입력된 금액에 맞게 로또를 발행한다`만 실패하고 있는데요. 1. `LOTTO_NUMBER_COUNT`를 바라보는 곳이 2곳이기에 Machine의 Count를 변경해도 Lotto에는 문제가 없는 점. 2. … 제가 생각했을 때 `LOTTO_NUMBER_COUNT`는 Lotto가 가질 수 있는 LottoNumber의 수량이므로 Lotto의 비즈니스적인 정보라고 생각을 해서 한 곳에서 관리했을 것 같은데 오이는 어떻게 생각하실까요?" 학생: "리뷰가 아니었다면 아마 끝까지 몰랐을 수도 있었습니다."
+
+### 10. 테스트 검증 메시지 하드코딩
+
+```kotlin
+val exception = assertThrows<IllegalArgumentException> { LottoMatcher(.) }
+assertThat(exception.message).isEqualTo("[ERROR] 당첨 번호와 보너스 볼은 중복될 수 없습니다.")
+```
+
+리뷰어: "전반적으로 검증을 하드코딩으로 하셨는데요 이유를 알 수 있을까요?" 학생: "예외 메시지를 테스트할 경우 하드 코딩으로 검증을 하는 것이 TDD라는 방식과 더 잘 어울린다고 생각했습니다." — TDD에서 *상수 참조*보다 *하드코딩*이 더 *명세서 같다*는 의도.
+
+## 리뷰어 의견 요지
+
+1. **이름은 *무엇의 무엇*인가** — `Amount`보다 `PurchaseAmount`/`LottoPrice`가 도메인 어휘.
+2. **테스트 위해 public화 = 책임 분리 신호** — *private 함수를 테스트하지 말 것*. 테스트가 필요하면 *다른 객체*의 책임으로.
+3. **랜덤 의존을 외부 주입** — TDD 정합성 확보.
+4. **View에 Model 직접 vs Controller 변환** — *어느 쪽도 정답 아님*, 트레이드오프 인지.
+5. **`from`만 있고 주생성자가 public** — 의도 *강제*하려면 `private constructor`.
+6. **수익률은 *로또 결과의 행위*** — 별도 Calculator로 빼면 *Util*화.
+7. **상수의 *소유*는 한 곳** — `LOTTO_NUMBER_COUNT`는 Lotto의 정체성.
+8. **테스트명 = given-when-then** — 함수명도 *상황-입력-기대결과*.
+9. **드라이버/네비게이터 페어** — *설계도*를 먼저 그려야 *같은 방향*.
+
+- **대표 인용:**
+  > 이 함수는 `matchLotto`에서만 사용하기에 private이어야 할 거 같은데 테스트를 위해서 열려 있는 모습입니다. … private 함수를 왜 테스트해야 하나?
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/model/LottoMatcher.kt`
+
+  > TDD 관점에서 다시 생각을 해 볼까요? … 랜덤된 숫자가 이 `LottoMachine`의 핵심일 수도 있겠네요.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+  > `companion object`의 from으로 누군가 `Lotto`라는 것을 생성할 때 이 함수를 통해서 생성하라! 라고 만들어 주신 거 같아요. 근데 지금 상황에서는 `Lotto`에 그냥 접근이 가능하다 보니 일반적인 생성도 가능할 거 같아요.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/model/Lotto.kt`
+
+  > `LOTTO_NUMBER_COUNT`는 Lotto가 가질 수 있는 LottoNumber의 수량이므로 Lotto의 비즈니스적인 정보라고 생각을 해서 한 곳에서 관리했을 것 같은데 오이는 어떻게 생각하실까요?
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+## 얻은 교훈
+
+- **이름은 *무엇의 무엇*** — `Amount`/`Result`/`Calculator` 같은 *총칭 명사*는 도메인 어휘 부재 신호. `PurchaseAmount`/`LottoMatchResult`/`PrizeRule` 같이 *수식어 + 명사*.
+- **private 함수를 테스트할 충동 = 책임 분리 신호**. *테스트 needed → public → 새 책임 객체*로 이동.
+- **랜덤 의존 외부 주입 = TDD 정합성**. *핵심이 테스트 불가능*하면 TDD를 *진짜로 한 것* 아님.
+- **View가 Model을 직접 vs Controller 변환** — *어느 쪽도 정답 아님*. *Controller에 가공이 가도* / *View가 Model을 봐도* 트레이드오프 인지.
+- **`private constructor` + factory = 의도 강제**. factory만 만들고 주생성자가 public이면 호출자는 *어느 길로 가도 됨* — 의도 흩어짐.
+- **수익률은 *로또 결과의 행위*** — 따로 Calculator로 빼면 *상태 없는 Util*. *Model로 살리려면* 결과 객체의 메서드로.
+- **상수의 *소유*는 한 곳** — 중복 선언은 *변경 시 한쪽만 잊을* 함정. 테스트가 *한쪽 변경만으로 다 깨지지 않는 것*이 위험 신호.
+- **테스트명 = given-when-then 압축**. *함수명*도 *상황·입력·기대*가 보이도록.
+- **TDD에서 *상수 참조* vs *하드코딩*** — *명세서로서의 테스트*는 *변경에 둔감*해야 함. 하드코딩이 그 의도에 더 맞을 수 있음.
+- **페어 프로그래밍의 *설계도***  — 드라이버/네비게이터 역할의 모호함은 *설계도 부재* 신호. *큰 그림*을 먼저 합의.

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

@@ -0,0 +1,223 @@
+# PR #147 — [오이] 2단계 로또
+
+- **Reviewee:** [@cucumber99](https://github.com/cucumber99)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/147
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @lee-ji-hoon (코니)
+- **라인 코멘트:** 40 (리뷰어 26 + 학생 14)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoMachine` 인터페이스 + `publish` 추상화** — Strategy 시도.
+- **`model → domain` 패키지 변경** — 의도 메타-질문.
+- **`Rank` enum + `entries.find`** — 후속 라운드에서 enum 안전성 인식.
+- **`일급 컬렉션 List<List<Int>>` 회피** — 후속 *LottoTicket* 도입.
+
+## 못한 점 (설계 관점)
+
+### 1. *수동 로또 수 입력 후 천원 단위 검증* — 입력 순서 의존
+
+```
+1. 금액 입력 1400원
+2. 수동으로 구매할 로또 수 입력 1
+3. ERROR: 구입 금액은 천원 단위여야 합니다.  ⚠ 늦은 검증
+```
+
+리뷰어: "*이렇게 했을 때 '[ERROR] 구입 금액은 천원 단위여야 합니다.'이 뜨는 게 맞을까요*? *금액에 대한 것을 검증을 로또 수 입력 이후에 하는 게 맞을지* 고민해 봅시다! 혹은 *꼭 천원 단위일 필요가 있을까요. 거스름돈을 줄 수도 있을 거 같네요*! *요구사항에 천원 단위는 없었으니까요*~!" — *거스름돈 vs 천원 단위*.
+
+### 2. *Interface vs enum 정책* — 학생 선택 정당화
+
+```kotlin
+interface LottoMachine { fun publish(.): List<Lotto> }
+class AutoLottoMachine : LottoMachine {. }
+class ManualLottoMachine : LottoMachine {. }
+```
+
+리뷰어 (대안 제시):
+```kotlin
+enum class LottoMachinePolicy { AUTO, MANUAL }
+class LottoMachine(private val lottoMachinePolicy: LottoMachinePolicy) {
+    fun publishLottoTickets(info: LottoPurchaseInfo): List<Lotto> {
+        when (lottoMachinePolicy) {
+            AUTO -> {. }
+            MANUAL -> {. }
+        }
+    } 
+}
+```
+"이런 형태로 LottoMachine이 *만들어질 때! 혹은 publishLottoTickets에 이 publish는 어떤 정책으로 할꺼야!라고도 할 수 있을 텐데요. interface로 추상화를 하신 오이의 관점이 궁금*하네요~!" — *Strategy vs enum 정책 인자* 트레이드오프.
+
+### 3. `manualNumbers: List<List<Int>>` *내부 검증 부재*
+
+리뷰어: "*manualNumbers가 List<List<Int>>로 되어 있는데 저 List 안에 List<Int>가 검증이 필요 없을까요? 음수일 수도 있지 않을까요*!. *실제로 확인해 보면 좋을 거 같네요*!" — *원시 컬렉션 중첩*은 *검증 미완 상태*.
+
+### 4. `toString` 도메인 침투
+
+```kotlin
+class LottoNumber(.) {
+    override fun toString(): String = value.toString()
+}
+```
+
+리뷰어: "*toString을 단지 value를 숨기기 위한 용도로 사용을 한 거라면 toString의 의도와는 다르게 느껴지지 않*나요? *LottoNumber를 toString() 했다고 value의 값이 나오겠구나!라는 것을 유추할 수 있을까요*?" + "여기 *toString override된 것은 어떤 이유*일까요?" — *toString의 관습*: 객체 *디버그 표현*. *Value 노출 우회*로 쓰면 *어휘 충돌*.
+
+### 5. *`number` → `it` 가독성 후퇴*
+
+```kotlin
+numbers.map { it.toLottoNumber() }  // 이전: numbers.map { number -> number.toLottoNumber() }
+```
+
+리뷰어: "기존엔 `number ->`로 잘 표현해 주셨는데! *it으로 수정을 하셨더라고요!*. 지금은 *numbers라고 되어 있으니 number겠구나 할 수 있지만 보는 사람 입장에서는 1번 더 생각을 거쳐서 number겠구나라는 것이 나오는 것*이기 때문에 *보는 사람을 위해서 다시 표현하는 형태로 수정*하는 건 어떨까요?" — *암묵 it*은 *1단계 추론*.
+
+### 6. `Lotto.NUMBER_COUNT` *모호*
+
+리뷰어: "기왕 수정하는 김에 *Lotto.NUMBER_COUNT면 이게 어떤 COUNT인지 처음 보는 사람이 바로 알 수 있을까요*? 제가 썻다면 *지금 Lotto의 수량인가? 했을 거 같*아요!" — *컨텍스트가 클래스명에 들어 있어도 모호*. `NUMBERS_PER_LOTTO` 같이.
+
+### 7. `Rank.valueOf` *추가 분기 누락 위험*
+
+```kotlin
+fun valueOf(countOfMatch: Int, matchBonus: Boolean): Rank = when {
+    countOfMatch == 6 -> FIRST
+    countOfMatch == 5 && matchBonus -> SECOND
+.
+    else -> MISS
+}
+```
+
+리뷰어: "이건 제가 *리뷰하다가 놓친 부분 중에 하나인데 지금이라도 하나 추가해 둘게요*! *valueOf 함수를 보면 나중에 Rank 하나가 추가가 된다고 했을 때 valueOf when에서 놓치기 쉽지 않을까요*?
+```kotlin
+enum class Rank(.) {
+    FIRST(6, 2_000_000_000),
+.
+    FIFTH(2, 1_000), // 새롭게 추가
+    MISS(0, 0),
+}
+```
+이렇게 됐을 때 *valueOf에서는 에러가 안 나고 사용하는 입장에서는 그냥 썼다가 MISS가 나오는 것을 볼 수도 있을 거 같*아요! *enum의 장점을 살리기 위한 방법으로는 entries와 find를 적절히 사용하는 것도 방법*입니다!" — PR #131 *else 회피*와 정확히 같은 본질.
+
+### 8. *View가 너무 똑똑* — 멍청한 View
+
+리뷰어: "이 부분은 *1단계 때 해 보려다가 2단계 때 어차피 변경 포인트로 있을 거 같았는데 맞았*네요!.. *UI에 표시하기 위해서 어느 정도 UI에서 Model을 아는 것은 어쩔 수 없다고도 생각*을 하는데요. *그런데 UI가 어떠한 비즈니스적인 행동을 해서는 안 된다.라고 생각*을 하는데요. 그래서 제가 가장 좋아하는 말은 ***'View는 멍청해야 한다.'***라는 말인데요. *지금 View는 너무 똑똑해 보이는데* 오이가 한 번 고민해 보면 좋을 거 같네요.". 강사 동일 어록.
+
+### 9. `LottoMachine` 테스트가 *사용자 입력에 의존*
+
+리뷰어: "*LottoMachine 입장에서는 테스트 코드를 작성할 때 '사용자의 입력'과 관련이 있을까요? LottoMachine의 given에는 사용자의 입력과는 상관이 없을 겁니다*."
+
+### 10. *테스트 함수명에 '예외가 발생한다'* — 관심사 아님
+
+리뷰어: "테스트 입장에서 *어떠한 예외가 발생하는지는 큰 관심사가 아니지 않을까요*? 테스트를 작성할 때 검증을 하고자 했던 것은 *'구입 금액이 천원 이상이여야 한다.'로 보이는데요 그럼 예외가 발생한다는 것은 단지 상황일 뿐 테스트 코드 함수명에 들어갈 필요가 있었을까요*?" — *명세 어휘 = 결과 상태*, 구현 메커니즘 아님.
+
+### 11. *상수 직접 import*해 테스트?
+
+```kotlin
+LottoPurchaseInfo.LOTTO_PRICE
+```
+
+리뷰어: "*LottoPurchaseInfo.LOTTO_PRICE를 그대로 import해서 테스트를 해 주셨는데요*! https://jojoldu.tistory.com/615 *이런 의견도 있는데 오이의 의견은 어떨지* 궁금하네요~!" — *테스트가 자기 자신을 참조*하는 안티 (PR #113 `var price`와 같은 패턴).
+
+### 12. *emptyList 반환* — null 또는 sealed가 명확
+
+```kotlin
+fun publishManual(count: Int): List<Lotto> {
+    if (count == 0) return emptyList()  // ⚠ 빈 의도 모호
+.
+}
+```
+
+리뷰어: "지금 로또 머신은 아래와 같은 상태인데요! 1. *수동 로또 번호를 0개로 입력* 2. *0개로 입력했으니 emptyList() 반환* 그럼 여기서 *emptyList()라는 것을 만들지 말지를 역할을 수행해야 할 객체가 controller가 해야 할 역할이었는지 model의 역할이었는지* 고민해 봅시다!" + "*어떠한 상황에 어떤 Model을 만들지는 충분히 Controller가 할 수 있죠. 하지만 emptyList를 반환할 필요가 있었을까* 했습니다. *null로 반환을 한다면 조금 더 명확하게 이것은 잘못된 상황이다.라고 return 값으로 알려줄 수* 있죠. 혹은 *sealed를 사용해서 '어떠한 상태'인지도 알려줄 수* 있었을 것 같네요!"
+
+### 13. `LottoPurchaseInfo` *네이밍 뭉개기*
+
+리뷰어: "*LottoPurchaseInfo 로또 구매 정보인데, manualLottoCount는 실제로 지금 구매한 정보인가요? 아직 구매에 대한 검증이 거쳐지지 않은 정보 값인데 Info라는 네이밍을 통해서 뭉뚱그려서 정의가 된 감*이 없지 않아 있네요. *ManualLottoCount를 따로 나누는 것도 하나의 방법*일 거 같은데 한 번 고민해 봅시다~!"
+
+### 14. *`model` → `domain` 패키지 변경 의도*
+
+리뷰어: "기존엔 model이라는 패키지도 나쁘지는 않았다고 생각을 했는데 *domain으로 옮기신 의도가 어떤 것일까요*!"
+
+### 15. *try-catch vs null vs sealed class* — 학생 자가 의문
+
+학생: "*코틀린만의 예외 처리 방식 중 실패하는 경우가 복잡해서 null로 처리할 수 없으면 sealed class를 반환한다.라는 부분이 있는데 로또 미션에 적용하기가 어렵다고 느꼈*습니다." + "*논리적 오류인 경우 (로또 숫자의 범위를 벗어난 경우 등)나 논리적 오류가 아닌 경우 (잘못된 값이 입력된 경우)는 어떤 경우인지 이해가 되었지만, sealed class를 써야 하는 경우를 찾지 못했을 뿐더러 sealed class를 반환했을 때 외부에서 어떤 방식으로 처리해야 하는지 궁금*합니다."
+
+리뷰어: "네 *충분히 그럴 수 있습니다. 로또가 그리 큰 프로그램이 아니기 때문*이죠. 그런데 *null로 반환을 하느냐 아니면 sealed로 명시해서 어떠한 '상태'인지를 반환하는 것은 잘 아셨으면 좋겠*어서 아래 내용에 의견 남겨 둡니다. 예를 들어서 이런 경우를 가정할 수 있을 거 같아요
+```kotlin
+fun main() {
+    val result: Int? = getInputNumber()
+    // 왜 null인 거지?? 무엇을 해줘야 하는 거지??
+}
+
+private fun getInputNumber(): Int? {
+    return readlnOrNull()?.toIntOrNull()
+}
+```
+*getInputNumber 입장에서는 Number를 입력받기 위한 함수이니 Int가 아니면 null이다.라고 할 수 있는데 main() 함수 입장에서는 null이 들어오면 이거는 뭘 하라는 거지?라는 생각을 하게 되는 거*죠. 그런 상황에서 *sealed로 묶어서 어떠한 '상태'인지를 알려주면 그 상태에 따른 후속 동작을 main에서 할 수 있게 될 거 같은데요*!"
+
+→ *null의 손실*: *호출자가 어떤 행동을 해야 할지 모호*. *sealed*는 *어떤 상태인지 + 대응*까지 표현.
+
+### 16. *runCatching이 try-catch보다 낫나?* — Result 객체
+
+리뷰어: "*try-catch를 사용하는 경우는 try에서 어떠한 에러가 발생할 수도 있는데 그것을 단순 catch해서 처리하기 위함인데요. 이때 이 에러를 다른 곳으로 위임하는 게 좀 까다로운 편*입니다. 그 반면 *runCatching도 똑같이 catch를 하긴 하지만 Result라는 객체로 묶이다 보니 본인 레이어에서 error를 다른 레이어 혹은 객체에게 어떠한 상태임을 알리는 것이 간편하다는 장점*이 있습니다. 위 내용에 대해서는 https://toss.tech/article/21010 *이 글을 읽어 보면* 좋을 거 같네요." — *Toss 기술 블로그*도 우테코 공통 자료.
+
+### 17. *Amount 일반화 vs LottoPrice 도메인 명시*
+
+리뷰어: "단순 *Amount보다는 LOTTO_PRICE 같은 Lotto 도메인에 얽혀져 있으니 조금 더 명확한 이름*이면 좋겠다라는 생각은 있네요"
+
+### 18. *추상화 이유: '도메인 로직 노출' 어색*
+
+리뷰어 (학생 변호에 반박): "네 좋습니다. 하지만 *'도메인 로직이 노출되는 것을 피할 수 없어서 추상화를 했다.' 이 부분에서 도메인 로직이 노출이 되는 것 때문에 추상화를 했다는 말이 어색*하네요 🤔 1. *하나의 LottoMachine을 사용해서 어떠한 로또를 만들겠다. 통보 (enum)* 2. *여러 개의 LottoMachine을 만들어서 각 상황에 맞는 LottoMachine을 쓴다. (현재 방식)* 둘 다 결국 *controller에서 결정을 하게 되며 크게 다르지는 않을 것 같*은데요. *Controller에서 현재 View의 입력값에 따라서 어떠한 Model을 만들지와 어떠한 함수를 실행할지 등등의 판단 정도는 저는 할 수 있다고* 생각을 하는데요." — *추상화 정당화*가 *부정확*하면 *잘못된 추상화*.
+
+### 19. *MISS는 출력 필요 없음* — matchLotto에서 걸러야
+
+리뷰어: "*Rank.MISS인 경우 어떠한 출력도 필요가 없던 것이라면 matchLotto라는 함수에서 걸러줄 수도 있을 것* 같은데 이 부분은 그리 큰 사항은 아니기에 *나중에 고려만 해 보시면* 좋을 것 같습니다."
+
+### 20. `LottoMachine` *기본값 emptyList* 어색
+
+리뷰어: "*LottoMachine에서 생성자로 기본값이 emptyList인 것은 뭔가 어색*하네요. *LottoMachine 관점에서는 생성이 되었을 때 어떠한 값이 1개라도 존재를 해야 할 것 같*은데요 🤔" — *생성자 기본값 = 의미 있는 기본*이어야.
+
+## 리뷰어 의견 요지
+
+- **입력 *순서가 검증 순서*와 일치 (UX)**.
+- **`Strategy interface` vs `enum policy`** = 트레이드오프.
+- **`List<List<Int>>` 내부 검증 부재**.
+- **`toString` *의도 충돌*** — 값 숨기기 X.
+- **`it` vs *명시 파라미터*** — 가독성.
+- **`Rank.valueOf` *추가 분기 누락* → entries+find**.
+- **View는 멍청해야**.
+- **테스트 *given이 사용자 입력에 의존* X**.
+- **`emptyList` 반환 → *null 또는 sealed***.
+- **null의 *호출자 정보 손실*** — sealed로 상태 표현.
+- **`runCatching` *Result 객체로 위임 용이*** (Toss 글).
+- **`LottoPurchaseInfo` *Info 뭉개기* 회피**.
+- **`MISS` 출력 필터링**.
+- **`emptyList()` 기본값 → *의미 있는 기본***.
+
+- **대표 인용:**
+  > valueOf 함수를 보면 *나중에 Rank 하나가 추가가 된다고 했을 때 valueOf when에서 놓치기 쉽지 않을까요*? enum의 장점을 살리기 위한 방법으로는 *entries와 find를 적절히 사용*하는 것도 방법입니다!
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/Rank.kt`
+
+  > 그래서 제가 가장 좋아하는 말은 **'View는 멍청해야 한다.'**
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/view/OutputView.kt`
+
+  > getInputNumber 입장에서는 Number를 입력받기 위한 함수이니 Int가 아니면 null이다.라고 할 수 있는데 *main() 함수 입장에서는 null이 들어오면 이거는 뭘 하라는 거지?라는 생각*을 하게 되는 거죠.
+  > — @lee-ji-hoon on `README.md` (sealed class 설명)
+
+  > '도메인 로직이 노출되는 것을 피할 수 없어서 추상화를 했다.'이 부분에서 *도메인 로직이 노출이 되는 것 때문에 추상화를 했다는 말이 어색*하네요.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/LottoMachine.kt`
+
+## 얻은 교훈
+
+- ***검증 순서 = 입력 순서***. *금액 → 수동 수 입력 후*에 금액 오류 알리면 *UX 최악*.
+- **`Strategy interface` vs `enum policy` *현재 변경 가능성*에 따라** — *외부 추가 구현체 가능*하면 interface, *고정된 종류*면 enum.
+- **`Rank.valueOf when` *추가 분기 누락*** — *enum의 장점은 entries + find로 활용*. PR #131 (krrong)의 *else 회피*와 본질 같음.
+- **`toString` 의도** = *디버그 표현*. *value 숨기기*로 *오용*하면 호출자 헷갈림.
+- **암묵 `it` vs 명시 파라미터** — *1단계 추론*도 비용. *변수명*이 *문서*.
+- **View는 멍청해야** — *비즈니스 행동 X, UI 표시만*.
+- **테스트 *given*은 *해당 객체 입력*** — `LottoMachine` 테스트가 `사용자 입력`에 의존하면 *Mock 깊이* 부담.
+- **테스트 함수명 = *명세 결과*** — *'예외 발생'*은 *구현 메커니즘*. *'천원 이상이어야 한다'*가 명세.
+- **테스트가 *자기 자신 참조*** — `LottoPrice.PRICE`로 테스트하면 *상수 변경 시도 같이 변경*.
+- **`emptyList()` 반환 vs *null 또는 sealed*** — *빈 의도 모호*. *명확한 상태*가 *호출자 후속 행동*에 도움.
+- **null vs sealed** — null = *호출자가 행동 모름*. sealed = *상태 + 대응 가능*.
+- **`runCatching` *Result 위임 용이*** — *catch 위치 비결정* 문제를 *객체로 전달*. Toss 글.
+- **`LottoPurchaseInfo` *Info* 뭉개기** — *검증된 정보*와 *미검증 정보*를 *한 클래스*에 두면 *상태 모호*.
+- **`MISS` 출력 필터링 = *도메인의 표현 책임 인식***.
+- **`emptyList()` 기본값** = *생성자 의도 모호*. *의미 있는 기본*이 *Optional 표현*보다 자연.
+- **추상화 정당화 = *변경 가능성*** — *도메인 노출*은 *추상화 이유*가 아님 (interface도 시그니처 노출). *진짜 이유*는 *다른 구현체 가능성*.

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

@@ -0,0 +1,68 @@
+# PR #125 — [로또 1단계] 이든 미션
+
+- **Reviewee:** [@devfeijoa](https://github.com/devfeijoa)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/125
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 48
+
+## 못한 점 + 핵심 지적
+
+### 1. OutputView가 결과 *생성*까지
+
+```kotlin
+class OutputView {
+    fun printResult(lottos: List<Lotto>, winning: WinningLotto) {
+        val results = lottos.map {. }  // ⚠ View가 결과 계산
+.
+    }
+}
+```
+
+> 티켓 결과를 만들어내는 일은 뷰의 역할일까요?
+
+→ View는 *받은 결과 출력*만.
+
+### 2. `LottoResult` — 이름과 책임 불일치
+
+```kotlin
+class LottoResult(.) {
+    fun calculate(.): Map<Rank, Int> =.
+    fun profitRate(.): Double =.
+    // 계산만 수행, 결과 자체는 보유 X
+}
+```
+
+> LottoResult 라는 이름이라 어떠한 결과 값들을 가지고 있을 거라 기대했는데, 결과를 계산하는 객체였네요! 이 객체는 너무 많은 역할을 하고 있다는 느낌이 들어요.
+
+→ 이름 `LottoResult` = 보유, 실제는 계산. 두 책임 (계산 + 표현) 분리.
+
+### 3. `LottoStore`와 `LottoGenerator` 차이?
+
+```kotlin
+val tickets = lottoStore.getTickets(.)
+// vs
+val tickets = lottoGenerator.generate(.)
+```
+
+> 아래 두 코드에서 많은 차이점이 있었나요?
+
+→ "Store" (보유) vs "Generator" (생성) — 도메인 의미 다름. 학생이 *Store*를 *Generator*처럼 쓴 경우.
+
+### 4. `LottoTicketCounter` — 함수로 충분
+
+```kotlin
+class LottoTicketCounter {
+    fun count(price: Int): Int =.
+}
+```
+
+> 이 값은 꼭 함수로 반환하지 않아도 괜찮아 보이네요!
+
+→ `Money` property로 충분.
+
+## 얻은 교훈
+
+- **이름은 *반환 결과*가 아니라 *책임*을 표현**. `LottoResult`가 계산만 = god-object. *Result*는 보유, *Calculator*는 계산, *Formatter*는 표현.
+- **현실 어휘 차이** — Store vs Generator. 비유로 도메인 의미 검증.
+- **함수 하나만 가진 클래스** = top-level fun 또는 도메인 객체의 메서드.