oh-my-oop 0.2.0

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

@@ -0,0 +1,143 @@
+# PR #46 — [반달] 2단계 로또
+
+- **Reviewee:** [@no1msh](https://github.com/no1msh)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/46
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @woowajames
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **기능 목록 README** — 칭찬: "*기능 목록 작성에 고민을 많이 하신 것* 같아요!".
+
+## 못한 점 (설계 관점)
+
+### 1. *수익률 소수점 둘째 자리 미적용*
+
+리뷰어: "*미션 실행 결과를 보면 당첨 통계는 소수점 둘째자리까지 보여주고* 있습니다. *동일하게 개선*해 보면 좋겠습니다."
+
+### 2. *기능 목록 단위 커밋* 권유
+
+리뷰어: "*추후에는 커밋 단위를 기능 목록 단위로 하시면 더 좋을 것* 같아요."
+
+### 3. `Lotto` *init과 부 생성자 호출 순서*
+
+```kotlin
+class Lotto(val numbers: List<LottoNumber>) {
+    constructor(input: String) : this(input.split(",").map { LottoNumber(it.toInt()) }) {
+        // ⚠ 검증?
+    }
+    init { require(numbers.size == 6) }
+}
+```
+
+리뷰어: "*이 부분이 실제로 동작하는 경우가 있을까요? 초기화 블록과 생성자의 호출 순서에 대해 알아*보세요! 🤔" — Kotlin: *부 생성자 → 주 생성자 → init*.
+
+### 4. `runCatching + onSuccess return + !!`
+
+```kotlin
+runCatching { payment = Payment(money) }
+.onSuccess { return payment!! }  // ⚠
+.onFailure { println(it.message) }
+```
+
+리뷰어: "*이렇게 표현할 수도 있어요*! 그리고 *while(true) {. }와 같은 구조는 자칫 무한 루프에 빠질 수 있는 위험 요소*가 있습니다. 특히 *컨트롤러에서는 while 문 내에서 또 while 문으로 들어가는 부분들이* 보입니다. *while 문을 제거하고 동일하게 동작할 수 있는 방법*을 고민해 보세요. 또한 *manualCount!!를 리턴해 주고 있는데요. !! 연산자 사용을 지양*해 보면 어떨까요?"
+
+### 5. *생성자 인자 vs 메서드 인자*
+
+리뷰어: "*메서드의 파라미터로 받아도 되는 부분을 생성자로 받아서 프로퍼티에 할당하는 것은 불필요*해 보입니다."
+
+### 6. *Controller에 여러 역할 혼재* — 수동 로또 생성 분리
+
+리뷰어: "*컨트롤러에 여러 가지 역할은 혼재해* 있습니다. *수동 로또 생성을 이렇게 컨트롤러 내부의 메서드로 존재하기 보다 별도의 클래스로 분리*하면 좋지 않을까요?"
+
+### 7. *LottoBundle*에서 수동/자동 분리 — 같은 곳?
+
+리뷰어: "*LottoBundle은 로또가 여러 장 모여 있는 클래스*입니다. *여기서 자동 생성을 한다면 수동 생성은 왜 이곳에서 이뤄지지 않을까요? 만약 역할이 많아진다고 생각되면 생성하는 부분은 별도로 분리*하면 좋겠죠? 😄"
+
+### 8. *오버로딩 = 외부 검증 중복 신호*
+
+리뷰어: "*이 함수가 이런 식으로 오버로딩되었다는 것은 숫자인지 아닌지 검증하는 로직이 외부에서 발생하고 있다는 의미*로 보입니다. *결국 같은 검증을 이곳저곳에서 하고 있다는 것인데 하나로 통일*해 보면 좋겠네요."
+
+### 9. `Payment` *수량 계산* + 별도 수량 함수 *분산*
+
+리뷰어: "*Payment에서 수량을 계산하는 함수가 있*습니다. 그리고 *여기에 또 수량 관련 함수가* 있네요. *비슷한 역할을 하는 게 흩어져* 있습니다. 또한 *ManualCount라는 클래스에서 AutoLottoCount를 계산하는 것도 이상*하게 보입니다."
+
+### 10. *생성자 2개 → 검증 중복*
+
+리뷰어: "*이런 식으로 생성자가 2개로 나뉠 이유가 없*습니다. *둘 중 하나를 선택해서 사용하시면 질문하셨던 검증 부분이 중복되는 것을 피할 수* 있습니다. *현재 각 생성자가 쓰이는 부분을 확인*해 보세요. *각각 한 곳에서 쓰이고 있기 때문에 통일하는 것은 크게 어렵지 않을 것*으로 보이네요."
+
+### 11. *수동 = 자동 + 입력 차이뿐* — 통합
+
+리뷰어: "*이 부분이 마음에 들지 않는다고 하셨습니다*. *LottoBundle 클래스에서 manualGenerate()와 autoGenerate()를 모두 해 주고 있*네요. *autoGenerate()는 쉽게 된다고 느끼는데 왜 manualGenerate()는 복잡하게 보일까요?* *자동이나 수동이나 실제 로또 도메인을 생각해 보면 6개의 숫자를 가지는 것으로 동일*합니다. 반달의 프로그램으로 대입하면 *'6개의 숫자를 가지는 것 = Lotto 클래스'*입니다. *단지 숫자를 자동으로 6개 만들어서 Lotto 클래스를 구성하느냐 입력 받은 값으로 구성하느냐의 차이 뿐*입니다. *거의 같다고 느껴지지 않나요? 그러면 '6개의 숫자를 가지는 것'에 대한 방식을 통일하면 좀 쉽게 접근이 가능*할 것이라 생각합니다. *현재 자동에 대한 6개의 숫자 모임(= Lotto 객체)은 RandomLottoGenerator 클래스에서 생성*하고 있습니다. *이러한 역할을 하는 수동 제너레이터를 만들어 볼 수 있지 않을까요*?"
+
+### 12. *매직 넘버 상수화*
+
+리뷰어: "*매직 넘버에 대한 상수화*를 하면 좋을 것 같습니다."
+
+### 13. `TotalPrize` *수익률 얻기 vs 생성*
+
+리뷰어: "*TotalPrize 입장에서 수익률을 얻는 게 아니라 생성하고* 있습니다. *네이밍이 조금 더 자연*스러워지면 어떨까요?"
+
+### 14. *별도 함수 분리* + *지역 변수 vs 직접*
+
+리뷰어: "*별도의 함수로 분리하면 더 깔끔할 것* 같네요." + "*굳이 지역 변수를 쓰지 않고 바로 넘겨줘도 좋을 거 같*습니다."
+
+### 15. *오버로딩 vs private constructor*
+
+리뷰어: "*취향의 영역인 거 같은데 private constructor 사용을 굳이 고집하지 않는다면 of() 함수 오버로딩을 쉽게 피할 수* 있을 것 같습니다. *오버로딩이 나쁘다는 게 아니라 중복된 로직이 나눠져 있는 게 약간 신경*이 쓰이네요. *이건 꼭 반영 안 하셔도 됩니다. 그냥 제 개인적인 생각*을 말씀드려 봤어요."
+
+### 16. *함수 길이 + 라인 분리*
+
+리뷰어: "*함수가 길기도 하지만 적당한 라인 분리가 안되어서 보기가 어려*워요. *관련 있는 부분으로 라인을 나눠* 보면 좋겠어요."
+
+### 17. *create 메서드 누락*
+
+리뷰어: "*숫자가 아닌 값이 들어올 때 → 어떻게 되어야 한다는 건지 불분명*합니다. 더불어 *피드백 반영이 안된 것이 위쪽에 있는데 'create를 사용하여 인자로 들어간 int값으로 LottoNumber를 만든다'라는 테스트에서 create의 메서드명이 변경되면 적절하지 않은 네이밍이라고 하였는데 현재 create라는 메서드가 없*네요. 함께 수정되면 좋겠습니다. *테스트 네이밍을 좀 더 신경*쓰시면 좋겠습니다."
+
+### 18. *정수형 vs 숫자*
+
+리뷰어: "*정확히는 정수형이 아닙니다. 현재 Int 값으로만 변환을 하고 있*습니다. *숫자라고 표현하는 게 차라리 적절*할 것 같습니다."
+
+## 리뷰어 의견 요지
+
+- **소수점 둘째 자리**.
+- **커밋 단위 = 기능 목록**.
+- ***init + 부 생성자 호출 순서***.
+- **`while + runCatching + !!` *무한 루프 위험***.
+- **Controller *수동 생성 분리***.
+- **`LottoBundle` *수동/자동 분리* 일관**.
+- **오버로딩 = *외부 검증 중복 신호***.
+- **`Payment` vs `ManualCount` *역할 분산***.
+- **생성자 *중복 통합***.
+- **수동 = 자동 + 입력 차이뿐 → 통합 (`Generator`)**.
+- **매직 넘버 *상수***.
+- **네이밍 *현실 동작*** (얻기 vs 생성).
+- **함수 *라인 분리***.
+
+- **대표 인용:**
+  > 자동이나 수동이나 실제 로또 도메인을 생각해 보면 *6개의 숫자를 가지는 것으로 동일*합니다. 반달의 프로그램으로 대입하면 *'6개의 숫자를 가지는 것 = Lotto 클래스'*입니다.
+  > — @woowajames on `src/main/kotlin/lotto/domain/LottoBundle.kt`
+
+  > 이런 식으로 *생성자가 2개로 나뉠 이유가 없*습니다. 둘 중 하나를 선택해서 사용하시면 질문하셨던 검증 부분이 중복되는 것을 피할 수 있습니다.
+  > — @woowajames on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+  > 추후에는 *커밋 단위를 기능 목록 단위로 하시면 더 좋을 것* 같아요.
+  > — @woowajames (커밋 관리 가르침)
+
+## 얻은 교훈
+
+- **소수점 *명세에 명시*** — 출력 형식도 *요구사항*.
+- **커밋 단위 = *기능 목록 단위*** — *PR 리뷰 가독성* + *되돌리기 단위*.
+- **`init` vs *부 생성자* 호출 순서** — Kotlin: *부 → 주 → init*. *부 생성자에 검증*만 두면 *주 생성자 호출 경로*에서 누락.
+- **`while + runCatching + !!`** = *세 가지 위험 합산*. 무한 루프 + null 단언 + 흐름 모호.
+- **Controller *역할 혼재 = 객체 분리 신호***.
+- **`LottoBundle` *자동만 분리 = 수동도 분리* 일관성**.
+- **오버로딩 = *외부 검증 중복 신호*** — *입력 형태 다양*하면 *팩토리 함수*에서 통합.
+- **`Payment` 수량 + `ManualCount` 수량** = 책임 분산. *Order/Quantity 통합*.
+- **생성자 2개 = *검증 중복***. *하나로 통일*.
+- **수동 = 자동 + 입력 차이뿐** = *통합 추상화*. *6개 숫자 모음*이 *공통*. 가르침.
+- **매직 넘버 *상수화*** — 모든 PR 공통.
+- **`TotalPrize.calculate` *얻기 vs 생성* 네이밍**.
+- **함수 *라인 분리*** = 가독성. PR #131 *분리 vs 분해* 균형.
+- ***create 메서드 사라짐* 같은 *변경 일관성*** — 테스트가 *사라진 메서드*를 가리키면 *PR 셀프 리뷰 부재*.

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

@@ -0,0 +1,178 @@
+# PR #13 — [수달] 1단계 로또
+
+- **Reviewee:** [@otter66](https://github.com/otter66)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/13
+- **단계:** 1단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 35
+
+## 잘한 점 (설계 관점)
+
+- **`Rank` enum에 `(countOfMatch, winningMoney, description)`** — 등수+상금+설명 한 곳.
+- **`Rank.valueOf(countOfMatch, matchBonus)`** — 보너스 매치 조건을 enum factory에 흡수 시도.
+- **`PurchaseAmount` 도입** — 금액 원시값 포장.
+- **`WinningLottery`로 당첨 번호 + 보너스를 묶음** — 1차 책임 분리.
+- **`LotteryNumber` 도메인 객체화** — 1~45 범위 검증을 객체 init으로.
+
+## 못한 점 (설계 관점)
+
+### 1. 매직넘버 `6`이 generator에 박힘
+
+```kotlin
+class LotteryGenerator {
+    fun generateLottery(): Lottery {
+        val lotteryNumbers: MutableList<LotteryNumber> = mutableListOf()
+        repeat(6) {  // ⚠ 6의 의미가 코드 안에 없음
+            lotteryNumbers.add(generateUniqueLotteryNumber(lotteryNumbers))
+        }
+        return Lottery(lotteryNumbers)
+    }
+}
+```
+
+리뷰어: "6이라는 숫자는 무엇을 의미하는 걸까요? 다른 컬렉션 API를 활용해 보면 어떨까요?" 학생 답: "Lottery가 가지는 번호의 개수이므로 Lottery에서 해당 상수를 가지도록 하고, 외부에서 가져다 쓸 수 있도록 하였습니다." — *6은 Lottery의 정체성*에 속함.
+
+### 2. `LotteryGenerator`/`LotteryNumberGenerator` 강결합 + 테스트 불가
+
+```kotlin
+private fun generateUniqueLotteryNumber(lotteryNumbers: List<LotteryNumber>): LotteryNumber {
+    val lotteryNumberGenerator = LotteryNumberGenerator()  // ⚠ 내장 인스턴스화
+    while (true) {
+        val randomLotteryNumber = lotteryNumberGenerator.generateLotteryNumber()
+        if (lotteryNumbers.contains(randomLotteryNumber)) continue
+        return randomLotteryNumber
+    }
+}
+```
+
+리뷰어: "LotteryNumberGenerator는 LotteryGenerator와 강한 결합 구조네요! LotteryGenerator.generateLottery()를 테스트 가능한 구조로 만들어 보아요! (자동차경주 미션을 떠올려보아요!)" — 이전 미션의 *NumberGenerator 인터페이스 주입* 패턴 재적용 필요.
+
+### 3. 무한 루프 위험 — 중복 시 재시도
+
+```kotlin
+while (true) {
+    val randomLotteryNumber = lotteryNumberGenerator.generateLotteryNumber()
+    if (lotteryNumbers.contains(randomLotteryNumber)) continue
+    return randomLotteryNumber
+}
+```
+
+리뷰어: "lotteryNumberGenerator.generateLotteryNumber()가 항상 같은 값이 호출된다면, 종료되지 않을 거 같아요! 중복되지 않는 숫자들을 생성하는 방법을 고민해 보면 어떨까요?" — 학생 수정: "로또 번호로 사용이 가능한 숫자들만을 사용해 중복이 없는 로또 번호들을 만들도록 하였습니다!" → `(1..45).shuffled().take(6)`.
+
+### 4. `Rank.SECOND`/`THIRD` 구분이 `valueOf`에서만
+
+```kotlin
+enum class Rank(val countOfMatch: Int, val winningMoney: Int, val description: String) {
+    SECOND(5, 30_000_000, "5개 일치, 보너스 볼 일치"),
+    THIRD(5, 1_500_000, "5개 일치"),.
+
+    companion object {
+        fun valueOf(countOfMatch: Int, matchBonus: Boolean): Rank {
+            if (countOfMatch == 5) return decideSecondOrThird(matchBonus)
+            return values().find { it.countOfMatch == countOfMatch } ?: MISS
+        }
+    }
+}
+```
+
+리뷰어: "2등과 3등은 countOfMatch가 동일하네요, 어떻게 2등과 3등을 구분할 수 있을까요? bonus 여부 또한 Rank가 가져야 하는 책임이 아닐까요?" — Rank에 *bonus 필요 여부* 필드를 추가하거나, 판별 로직을 더 일반화.
+
+### 5. Controller에 로직 집중
+
+```kotlin
+private fun calculateResult(lotteries: List<Lottery>, winningLottery: WinningLottery): WinningResult {
+    val winningResult = WinningResult()
+    repeat(lotteries.size) {
+        val countOfMatch = lotteries[it].countMatches(winningLottery)
+        val matchBonus = lotteries[it].containBonusNumber(winningLottery.bonusNumber)
+        winningResult.countRank(Rank.valueOf(countOfMatch, matchBonus))
+    }
+    return winningResult
+}
+```
+
+리뷰어: "lotteries의 데이터를 사용해서, Rank를 만들고, winningResult에 set하는 구조네요. **객체에게 메세지를 던져서 책임을 위임**해보도록 해요!" — `winningLottery.calculateResult(lotteries)` 한 줄로.
+
+### 6. `WinningResult`의 가변 `countMatchRanks`
+
+```kotlin
+class WinningResult(val countMatchRanks: MutableList<Int> = MutableList(6) { 0 }) {
+    fun countRank(rank: Rank) { countMatchRanks[rank.ordinal]++ }
+}
+```
+
+리뷰어 1: "countMatchRanks는 외부에서 수정이 가능한 구조네요!" 리뷰어 2: "countRank와 같은 set 함수는 언제, 얼마나 실행되었는지 관리하기가 까다로워지는데요, set를 외부에서 여러 번 실행되기보다, `List<Rank>`를 생성자로 받아서 처리해 보면 어떨까요?" — *생성 시 완성*된 객체로 만들면 시간차 무결성 보장.
+
+### 7. `println()`이 Controller에
+
+```kotlin
+fun run() {
+    val winningResult = calculateResult(lotteries, winningLottery)
+    println()  // ⚠ Controller가 출력 결정
+    outputView.printWinningStats(purchaseAmount, winningResult)
+}
+```
+
+리뷰어: "View는 언제든 변경될 수 있어요, println()은 View에서 처리하도록 해요!" — 출력 형식은 View 책임.
+
+### 8. `OutputView`에 5개 등수 print 코드 중복
+
+```kotlin
+println("${Rank.FIFTH.description} (${Rank.FIFTH.winningMoney})- ${result.countMatchRanks[Rank.FIFTH.ordinal]}")
+println("${Rank.FOURTH.description} (${Rank.FOURTH.winningMoney})- ${result.countMatchRanks[Rank.FOURTH.ordinal]}")
+//. 5번 반복
+```
+
+리뷰어: "중복된 코드를 분리해 보면 어떨까요?" — `Rank.values().filterNot { it == MISS }.forEach {. }`. 학생 수정: "associateWith를 이용해 해결."
+
+### 9. 테스트명/검증 모호
+
+```kotlin
+@ValueSource(ints = [1, 45])
+fun `번호를 하나 가진다`(number: Int) {. }
+```
+
+리뷰어: "테스트 케이스를 좀 더 구체적으로 사용해 보면 어떨까요? 하나의 요구사항 명세서라고 생각하면 좋아요! `1~45의 숫자로 로또 번호를 생성할 수 있다.`" + "에러 메시지까지 검증해 보면 어떨까요? 다른 의도하지 않은 에러가 같은 타입으로 에러가 발생할 경우, 테스트의 신뢰성이 떨어질 수도 있을 것 같아요!"
+
+### 10. `List<Lottery>` 일급 컬렉션 부재 — 학생 자가 의문
+
+학생: "Lotteries라는 일급 객체를 만들더라도 아무런 역할이 없는 단순히 리스트만 가지고 있는 객체가 될 것 같습니다. 이러한 경우에도 일급 객체를 만드는 것이 좋을까요?" — 리뷰어 후속: `lotteries`의 *집계 책임*이 있다면 일급 객체로. 단순 `List<Lottery>`로 외부에서 다 처리하면 절차적.
+
+## 리뷰어 의견 요지
+
+1. **매직넘버는 *위치 = 소유*** — 6은 Lottery의 정체성 → Lottery 안에 상수.
+2. **랜덤 의존은 *주입***  — 이전 미션(racingcar)의 패턴 재적용.
+3. **무한 루프 가능성 = 도메인 위반 신호** — 중복 회피를 *재시도*로 풀지 말고 *자료구조*로 풀어라(shuffle).
+4. **enum의 한 분기는 *enum이 책임지게*** — `SECOND.requiresBonus`/`isBonusMatched()` 필드 도입.
+5. **Controller = 조립**, 메시지 위임은 도메인에 — `winningLottery.calculateResult(lotteries)`.
+6. **객체는 *생성 시 완성*되어야 함** — 외부에서 setter를 여러 번 호출하는 누적 패턴 회피.
+7. **View 분리** — `println()`은 OutputView로.
+8. **테스트명 = 요구사항 명세서** — 요구사항 단어로 표현.
+
+- **대표 인용:**
+  > 6이라는 숫자는 무엇을 의미하는 걸까요?
+  > — @namjackson on `src/main/kotlin/lotto/domain/LotteryGenerator.kt`
+
+  > LotteryNumberGenerator는 LotteryGenerator와 강한 결합 구조네요! LotteryGenerator.generateLottery()를 테스트 가능한 구조로 만들어 보아요! (자동차경주 미션을 떠올려 보아요!)
+  > — @namjackson on `src/main/kotlin/lotto/domain/LotteryGenerator.kt`
+
+  > 2등과 3등은 countOfMatch가 동일하네요, 어떻게 2등과 3등을 구분할 수 있을까요? bonus 여부 또한 Rank가 가져야 하는 책임이 아닐까요?
+  > — @namjackson on `src/main/kotlin/lotto/domain/Rank.kt`
+
+  > 객체에게 메세지를 던져서 책임을 위임해 보도록 해요!
+  > — @namjackson on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > countRank와 같은 set 함수는 언제, 얼마나 실행되었는지 관리하기가 까다로워지는데요, set를 외부에서 여러 번 실행되기보다, `List<Rank>`를 생성자로 받아서 처리해 보면 어떨까요?
+  > — @namjackson on `src/main/kotlin/lotto/domain/WinningResult.kt`
+
+## 얻은 교훈
+
+- **이전 미션 학습을 *명시적으로 재적용***. racingcar의 NumberGenerator 주입은 lotto에도 동일하게 — 패턴은 *과제를 넘어 일반화*.
+- **매직넘버의 *소유*는 도메인 정체성**. `6`은 LottoSize 도메인 상수 — Lottery 안에서 정의.
+- **중복 회피 = 자료구조 선택** — `shuffled().take(N)` (전수 셔플) vs 무한 루프 재시도. 도메인이 *유한 집합*이면 셔플이 항상 종료.
+- **enum의 분기 조건은 enum 안에**. `Rank.valueOf` 안의 `if (countOfMatch == 5)` 매직넘버는 `Rank.SECOND.countOfMatch`로.
+- **객체는 *생성 시 완성*** — `setter`를 외부에서 여러 번 호출하는 객체는 *시간 의존성*을 외부에 노출.
+- **Controller = 조립**. 도메인 로직(`forEach + countRank`)은 도메인 객체(`winningLottery.calculateResult(lotteries)`)로 위임.
+- **`println()` = View 책임**. Controller가 `println()`을 호출하면 *흐름 조립자*가 *출력 형식*까지 결정.
+- **테스트명은 요구사항 문장**. `번호를 하나 가진다` → `1 이상 45 이하의 로또 번호를 생성할 수 있다`.
+- **일급 컬렉션은 *집계 행위가 있을 때***. Lotteries에 별다른 메서드가 없다면 굳이 만들지 말고 List로 유지 — *책임이 생기면* 일급 객체로 승격.

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

@@ -0,0 +1,160 @@
+# PR #53 — [수달] 2단계 로또
+
+- **Reviewee:** [@otter66](https://github.com/otter66)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/53
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **`LotteryMachine` 도입** — *발행 기계*로 책임 응집 시도.
+- **`Lotteries` 일급 컬렉션 + `plus(other)`** — 자동/수동 합치기 행위.
+- **`LotteryNumber` `data class` + value 명명 적용** — `lotteryNumber.number` → `.value`.
+- **`runCatching.getOrNull()` 패턴** — InputView에서 *null 반환*으로 Controller에 분기 위임.
+- **자가 의문 PR에 풍부히 명시** — *View 책임 경계*, *data vs value class*, *LottoTicket 도입 여부* 등.
+- **학습 로그 작성** — `data class vs value class`를 prolog에 정리.
+
+## 못한 점 (설계 관점)
+
+### 1. 수동/자동 흐름이 뒤바뀜
+
+```kotlin
+fun run() {
+    val amount: PurchaseAmount = getPurchaseAmount()
+    val autoLotteries: Lotteries = getLotteries(amount.autoNumber)     // ⚠ 자동을 먼저
+    val manualLotteries: Lotteries = getLotteries(amount.manualNumber) // ⚠ 수동을 나중에
+    val lotteries: Lotteries = autoLotteries.plus(manualLotteries)
+}
+```
+
+리뷰어: "리팩토링 과정에서 *로직이 꼬인 것* 같아요! *기존 자동 로또 기능에, 수동 기능이 추가*된 부분이에요! *수동 로또 발행 이후, 남는 금액에 맞는 자동 로또가 발행*되도록 작업해 주세요!" — 요구사항: *수동 N장 + (남은 금액)/1000 장 자동*.
+
+### 2. `LotteryMachine.createWinningResult` — 책임 위치
+
+```kotlin
+class LotteryMachine {
+    fun createWinningResult(winningLottery: WinningLottery, lotteries: Lotteries, amount: PurchaseAmount): WinningResult {. }
+}
+```
+
+리뷰어: "LotteryMachine에서 winningLottery, lotteries, amount의 파라미터를 받아서, *당첨 결과를 리턴해 줄 필요*가 있을까요? LotteryMachine은 *어떤 책임*을 가지고 있을까요? *winning에 대한 당첨에 대한 부분은 winningLottery에 위임*해 보면 어떨까요?" — *발행 기계*가 *당첨 판정*까지 흡수.
+
+### 3. `winningResult[rank]!!.plus(1)` — `!!` 강제 언패킹
+
+```kotlin
+val winningResult: MutableMap<Rank, Int> = Rank.values().associateWith { 0 }.toMutableMap()
+repeat(lotteries.size) {
+.
+    winningResult[rank] = winningResult[rank]!!.plus(1)  // ⚠
+}
+```
+
+리뷰어: "`!!`은 nullable한 변수를 notNull로 *강제로 변경*해 주는 동작을 해요, 변수에 null이 있는 경우, *에러가 발생*하곤 합니다. null을 처리할 수 있는 여러 방법을 고민해 보아요." + 후속: "당첨 리스트를, WinningResult의 *생성자로 전달*하여, Winning *집계하는 부분은 WinningResult에서* 하도록 해 보면 어떨까요?" — 누적 책임도 *결과 객체*에.
+
+### 4. `LotteryNumber(private val number)` getter + 변수명 중복
+
+```kotlin
+data class LotteryNumber(private val number: Int) {
+    fun toInt(): Int = number
+    fun toString(): String = number.toString()
+}
+```
+
+리뷰어: "코틀린에서는 getter를 따로 만들어 줄 필요가 없기도 해요, *number가 불변이라면, number를 노출해도 무방*. number라는 변수는 `lotteryNumber.number`라는 *중복 코드*가 발생되기도 하는데요, *value*와 같은 네이밍으로 `lotteryNumber.value`으로 *중복을 제거*할 수도 있을 거 같아요!" 학생: "외부에서 매개변수를 호출할 때 일관성을 위해 `.toInt()`, `.toString()`과 같이 작성하였는데, *내부에서 외부 로직과 관련 지어 변수명을 짓지 않도록* 하는 관점에서도 더 좋은 방법인 것 같습니다!"
+
+### 5. `value class` vs `data class` — 학생 자가 학습
+
+학생 학습 로그: "로또 번호를 원시값 포장하는 것에 대해 *data class*를 추천해 주셨는데, 현재 코드에서는 *value class*가 더 좋지 않을까? 라는 고민이 있습니다!" 리뷰어: "*value class와 data class는 서로 다른 역할*. 제가 data class를 언급한 부분은 직접 override한 *equals, hashCode 등을 자동으로 생성*해 주는 data class에 대한 *소개를 위함*이었고, *data class를 써야 한다는 코멘트는 아니긴* 했어요. 무엇을 사용하여 어떻게 구현하는지에 대한 *정답은 없다*고 생각이 들어요. 로또 번호가 *숫자로만 동일하면 되는 부분*일지, 아니면, 로또 번호를 *숫자를 가진 하나의 데이터 객체*라고 정의를 하는지에 따라 달라질 것 같아요." 학생 결론: "value class를 적용시켜 보았습니다! 객체 생성의 비용이 절감되고, 중복된 객체를 만들지 않기 위해 pool을 생성하는 과정을 줄일 수 있기 때문."
+
+### 6. InputView가 *수동 로또 N장*까지 직접 read + Lotteries 생성
+
+```kotlin
+fun readLotteries(count: Int): Lotteries? {
+    val lotteries: MutableList<Lottery> = mutableListOf()
+    repeat(count) {
+        val lottery: Lottery = Lottery(readln().split(", ").map { LotteryNumber(it.toInt()) })
+        lotteries.add(lottery)
+    }
+    return runCatching { Lotteries(lotteries) }.getOrNull()
+}
+```
+
+리뷰어: "로또 생성에 대한 부분은 *LottoMachine에 위임*해 보아도 좋을 거 같아요!" + "수동 로또를 *몇 장 살 것인가에 대한 Amount*에 대한 부분과 *구매하는 수동 로또 리스트와 분리*될 필요가 있을까요? 수동 로또 번호를 받게 되면, 구매하는 수동 로또의 갯수도 *당연히 알 수 있을 것* 같아요!" — *입력*과 *생성*의 분리. 학생 자가 답변: "View의 역할은 어디까지인지에 대해서는 *저만의 기준이 확정되지 않았습니다*. 추천해 주신 방법의 장점이 *view에서의 로직을 최소화*하고, 역할을 각 클래스에 맞게 분리할 수 있다는 장점 때문이 맞을까요?"
+
+### 7. View 책임 경계 — 학생 vs 페어 의견 차이
+
+학생 자가 의견 정리: "저는 *뷰에서 가공된 값을 보내고, controller의 기능을 최소화*한다는 것에 집중. 베르는 *뷰의 역할을 최소화 하고, controller를 통해 전달*해 도메인에서 값을 가공. 저의 방법에서는 controller의 기능이 최소화되는 장점이 있지만, *도메인의 역할을 뷰에게 빼앗긴 것* 같기도 하다는 단점. 베르의 방법에서는 controller의 기능이 조금은 늘어나는 단점이 있지만, *역할 분배가 좀 더 적절한* 것 같다는 장점." 학생: "아직 어떠한 방법이 더 좋은 방법인지 결정을 하지 못했기 때문에 다음 미션에서 *두 방법을 비교*해 보고자 합니다!"
+
+### 8. `LotteryGenerator`가 `LotteryMachine` 내부에서 직접 생성
+
+```kotlin
+fun generateLotteries(count: Int): Lotteries {
+    val generator: LotteryGenerator = LotteryGenerator()
+.
+}
+```
+
+리뷰어: "LotteryGenerator는 *LotteryMachine 생성 시점에 주입*받아 보면 어떨까요? LotteryMachine에서 *로또를 생성하는 부분에서 상세한 생성 테스트*를 할 수 있을 것 같아요! *인터페이스를 분리*한다면, 원하는 로또 번호를 생성하는 LottoMachine을 *테스트*할 수 있을 것 같아요!" — 의존성 주입 + Fake 주입 가능.
+
+### 9. `PurchaseAmount`에 `autoNumber` 상태값 보유
+
+```kotlin
+class PurchaseAmount(private val amount: Int, val manualNumber: Int) {
+    val autoNumber: Int = getPurchaseQuantity() - manualNumber  // ⚠ 상태값
+    fun toInt(): Int = amount
+}
+```
+
+리뷰어: "상태값을 가지는 변수보단 *Backing field*를 활용해 보면 어떨까요?" + "*불필요한 getter 함수*로 보여지네요! amount가 *불변 변수라면 외부에 공개해 주어도* 좋을 거 같아요!"
+
+### 10. `while (true)` 무한 루프 — `?: getPurchaseAmount()` 권장
+
+```kotlin
+private fun getPurchaseAmount(): PurchaseAmount {
+    while (true) {
+        val amount: PurchaseAmount? = inputView.readPurchaseAmount()
+        if (amount != null) return amount
+    }
+}
+```
+
+리뷰어: "이런 식으로도 사용할 수 있을 거 같아요! `return inputView.readPurchaseAmount() ?: getPurchaseAmount()`." — 재귀가 *while 무한 루프*보다 Kotlin idiomatic.
+
+## 리뷰어 의견 요지
+
+- **요구사항 순서** — 자동 *남는 금액*은 *수동 발행 후*.
+- **`LotteryMachine`의 책임** — *발행*에 집중, *당첨 판정*은 `WinningLottery`.
+- **`!!` 회피** — null 처리 방법 다양화.
+- **`value class` vs `data class`** — 정답 없음, *도메인 의미*에 따라 선택.
+- **InputView 책임 경계** = 학생 vs 페어 의견 차이의 *명시적 트레이드오프*.
+- **`LotteryMachine`이 `Generator` 주입받기** — 테스트 가능 구조.
+- **Backing field + 외부 노출** — `private val` + getter 함수보다 `val` 직접.
+- **`?: retry()`** > `while (true)`.
+
+- **대표 인용:**
+  > 리팩토링 과정에서 로직이 꼬인 것 같아요! … 수동 로또 발행 이후, *남는 금액에 맞는 자동 로또가 발행*되도록 작업해 주세요!
+  > — @namjackson on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > LotteryMachine에서 winningLottery, lotteries, amount의 파라미터를 받아서, *당첨 결과를 리턴해 줄 필요*가 있을까요? *winning에 대한 당첨에 대한 부분은 winningLottery에 위임*해 보면 어떨까요?
+  > — @namjackson on `src/main/kotlin/lotto/domain/LotteryMachine.kt`
+
+  > value class와 data class는 *서로 다른 역할*을 한다고 보면 좋을 거 같아요! … *무엇을 사용하여 어떻게 구현하는지에 대한 정답은 없다*고 생각이 들어요.
+  > — @namjackson on `src/main/kotlin/lotto/domain/LotteryNumber.kt`
+
+  > LotteryGenerator는 *LotteryMachine 생성 시점에 주입*받아 보면 어떨까요? *인터페이스를 분리*한다면, 원하는 로또 번호를 생성하는 LottoMachine을 *테스트*할 수 있을 것 같아요!
+  > — @namjackson on `src/main/kotlin/lotto/domain/LotteryMachine.kt`
+
+## 얻은 교훈
+
+- **요구사항 *순서*에 충실** — *자동 N장*이 *남는 금액*이라면 *수동 발행 후* 잔액 기준.
+- **`LotteryMachine`은 *발행*에 집중** — 당첨 판정은 `WinningLottery`로. 한 객체에 *발행 + 판정 + 통계*가 모이면 응집도↓.
+- **`!!` 회피** — *명시적 null 처리* 또는 *애초 null이 안 되는 구조*.
+- **`value class` vs `data class`** — 정답 없음. *로또 번호가 숫자로만 동일하면 되는가*(value class) vs *데이터 객체로 보는가*(data class).
+- **getter 함수 vs `val` 직접 노출** — Kotlin은 `val` 자체가 getter. 추가 함수는 *의도가 있을 때*만.
+- **변수명에 *내부 타입*을 두지 말 것** — `lotteryNumber.number` 같은 *타입 반복*은 *호출자 부담*. `.value`/`.toInt()`로.
+- **InputView vs Controller 책임 경계** — *정답 없는 트레이드오프*. *역할 분배의 적절성* vs *Controller 단순성*.
+- **`Generator` 주입** — `LotteryMachine`이 *Generator를 생성자에서 받으면* Fake로 테스트 가능.
+- **`?: retry()`** — Kotlin idiomatic 재시도. `while(true)`보다 *간결 + 의도 명시*.
+- **Backing field 활용** — `private var _x` + `val x get() = _x` 패턴은 *외부 불변 + 내부 가변* 표현.
+- **학습 로그로 *기준 정립*** — *value class vs data class* 같은 토픽은 *결론*보다 *비교 정리*가 학습.

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

@@ -0,0 +1,71 @@
+# PR #126 — [로또 1단계] 밀러 미션
+
+- **Reviewee:** [@oungsi2000](https://github.com/oungsi2000)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/126
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 45
+
+## 못한 점 + 핵심 지적
+
+### 1. Lotto에서 Int 노출 + 파싱
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    fun fromInput(input: String): Lotto = Lotto(input.split(",").map { it.toInt() })
+}
+```
+
+> Int로는 로또 번호가 아닌 것을 걸러내기는 어려워보여요. 로또 번호에 대한 값 객체를 만들어보는 건 어떨까요?
+
+> 입력 문자열을 파싱하는 것은, 콘솔 뷰에 굉장히 의존적이란 생각이 드네요. 안드로이드로 옮겼을 때도, 숫자 버튼을 눌렀을 때 항상 "," 로 구분되어있는 문자열이 입력으로 들어오는 것이 기대될까요?
+
+→ 도메인이 *파싱 형식*을 알면 *콘솔* 종속. View에서 파싱 후 도메인은 *완성된 값*.
+
+### 2. `RankMap` — 이름과 역할 모호
+
+```kotlin
+class RankMap(val data: Map<Rank, Int>) {. }
+```
+
+> RankMap이란 단어만 보고 다른 아무나 붙잡고 어떤 역할을 수행하는지 한 번에 유추해낼 수 있을까요?
+
+→ `WinningStatistic`/`RankCount` 같은 *역할*을 표현하는 이름.
+
+### 3. `global/Config` 패키지
+
+```
+lotto/
+  global/
+    Config.kt
+```
+
+> 상수를 한 파일에 몰아서 사용한 큰 이유가 있으신가요?
+
+→ `global/` god-folder.
+
+### 4. `LottoValidator` — 우회 가능
+
+```kotlin
+object LottoValidator {
+    fun validate(numbers: List<Int>) {. }
+}
+val lotto = Lotto(numbers)  // ⚠ Validator 안 거치고 직접 생성 가능
+```
+
+> 어딘가에서 이 검증기를 통과했더라도, Lotto객체 등은 검증기의 도움 없이 바로 생성할 수 있겠지요. Lotto 객체 생성을 하고자 하는 다른 개발자는 이런 검증기가 있는지 조차 모를 수 있겠어요. 그럴 때 그렇게 만들어진 객체는 과연 신뢰도 높은 객체일까요?
+
+→ Validator는 *도메인 외부*에 둘 수 없음. Lotto.init이 invariant 강제.
+
+### 5. `@DisplayName` vs 메서드명
+
+> 메서드 명 대신 DisplayName을 활용한 특별한 이유가 있으신가요?
+
+→ Kotlin은 백틱으로 함수명 자유. DisplayName은 자바 관습.
+
+## 얻은 교훈
+
+- **외부 Validator의 함정** — 우회 가능하면 도메인이 *불완전한 상태*로 생성 가능. invariant는 init이 강제.
+- **`global/Config` 패키지 = god-folder의 다른 이름**.
+- **Kotlin 백틱 함수명 > DisplayName**. 코틀린식.
+- **Int 노출 + 파싱이 도메인에 = 매체 종속**. 콘솔 idiom이 안드로이드/웹에서 어색.

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

@@ -0,0 +1,56 @@
+# PR #149 — [로또 2단계] 밀러 미션
+
+- **Reviewee:** [@oungsi2000](https://github.com/oungsi2000)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/149
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 41
+
+## 못한 점 + 핵심 지적
+
+### 1. 1단계 피드백 미반영 (racingcar 랜덤 테스트 패턴)
+
+> 이전 피드백을 먼저 반영해주세요 로또에서 랜덤 테스트를 구성하지 못한다는 의미는, 자동차 경주에서의 랜덤 테스트를 가능하게 하는 방법에 대해.
+
+→ racingcar에서 배운 NumberGenerator 추상화 패턴 미적용.
+
+### 2. object → class 변경 이유?
+
+```kotlin
+class LottoGenerator {. }  // 이전엔 object
+```
+
+> 갑자기 object -> class 로 변경된 이유는 무엇인가요?
+
+### 3. for + mutableList 패턴
+
+→ `List(count) { generate() }` 또는 `(1..count).map { generate() }`.
+
+### 4. `associate/group` 컬렉션 함수 활용
+
+```kotlin
+val map = mutableMapOf<Rank, Int>()
+lottos.forEach {. map[rank] = (map[rank] ?: 0) + 1. }
+```
+
+→ `lottos.groupingBy { it.match(winning) }.eachCount()`.
+
+### 5. 수동 로또가 LottoGenerator를 안 쓰는 분기
+
+```kotlin
+val manual = Lotto(.)  // ⚠ Generator 우회
+```
+
+> LottoGenerator 라는 객체가 있는데, 수동 로또는 생성기를 통하지 않네요. 수동 로또를 어디서 만드는 지 과연 다른 개발자들을 짐작할 수 있을까요?
+
+→ 자동/수동 모두 Generator 인터페이스 구현체.
+
+### 6. `UserInput`의 메서드 — View 전용?
+
+> 이 메서드들이 꼭 View에서 사용해야하는 메서드인가요?
+
+## 얻은 교훈
+
+- **이전 피드백 흡수 = 다음 단계의 기반**. 1단계 안 받았으면 2단계도 무너짐.
+- **`groupingBy { }.eachCount()`** = Map 집계의 표준. lotto 통계에 자연.
+- **자동/수동 통합 = Strategy/Generator 인터페이스 둘 다 거치게**. 일관성.