oh-my-oop 0.2.0

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

@@ -0,0 +1,162 @@
+# PR #98 — [로또 2단계] 해나
+
+- **Reviewee:** [@hxeyexn](https://github.com/hxeyexn)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/98
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **`PurchaseInformation` data class로 응집** — Amount + ManualLotteryCount 묶기.
+- **`LotteryMachine`이 수동/자동 발급 + Ticket 반환** — 객체에 *주체적 역할* 부여.
+- **`retryUntilSuccess` 재시도 흐름**.
+- **1단계 리뷰 적극 반영**.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller가 `List<List<String>>` 정제
+
+```kotlin
+private fun splitManualLotteries(input: List<String>): List<List<String>> {
+    val splitManualLotteries = InputView.splitManualLotteries(input)
+    val manualLotteries = mutableListOf<List<String>>()
+    splitManualLotteries.forEach { manualLotteries.add(it) }
+    return manualLotteries
+}
+```
+
+리뷰어: "InputView로부터 `List<Lottery>`를 전달받는 건 어떨까요? Controller에서 *데이터를 정제하는 책임*이 있어야 할까요?" 학생 답: "현재 `List<Lottery>`를 직접 전달받지 않은 이유는 *콘솔 이외의 다른 환경*에서 동일한 데이터를 다양한 형태로 활용." 리뷰어 답: "동료 개발자가 유지보수를 맡았을 때, `List<List<String>>`을 보고 *어떤 의미를 갖는 데이터*인지 쉽게 알 수 있을까요? 또한, 이중 List로 되어 있기에 *보일러 플레이트 코드*도 발생. *원시값을 포장하여 모델로서의 역할을 부여*해준 후 Controller에게 넘긴다면 그것으로 역할은 충분."
+
+### 2. `ManualLotteryCount` 단독 객체 vs *구매 정보*로 응집
+
+```kotlin
+class ManualLotteryCount(val count: Int) {. }
+```
+
+리뷰어: "ManualLotteryCount 역할을 좀 더 의미 있게 활용해 볼까요? 현재 프로젝트 내에서 ManualLotteryCount 클래스는 *구매 정보에 가까운 성격*을 띄우고 있네요. 그렇다면 *구매 정보에 관련된 값들을 하나의 클래스*에 모아 책임을 갖도록." 학생 수정: `PurchaseInformation` data class 도입하여 Amount + ManualLotteryCount 응집.
+
+### 3. Controller가 *수동/자동 발급 + 티켓 조립* 분담
+
+```kotlin
+val manualLotteries = issueManualLotteries(splitManualLotteries)
+val autoLotteries = issueAutoLotteries(amount, manualLotteryCount)
+val ticket = issueTicket(manualLotteries, autoLotteries, amount)
+```
+
+학생 자가 의문: "TicketGenerationStrategy가 Ticket을 반환하는 것이 아니라 Lottery를 반환해 *티켓의 역할이 모호*해졌고, *티켓 전략과 티켓의 역할*에 대한 의문이 들었습니다. 굳이 전략이 필요한가? 라는 생각도 들어서…" 리뷰어: "Controller에서 개별 로또마다 수동, 자동을 뽑아내서 티켓을 발급받도록 하는 과정이 *필요할까요*? Controller -> LottoMachine에게 *필요한 정보(수동 로또, 구매금액.)를 전달*해서 LottoMachine이 *알아서 수동, 자동 로또를 발급*하고 Ticket을 반환받도록. *LottoMachine에게 좀 더 주체적인 역할을 부여*." 학생 수정 완료.
+
+### 4. `start()` 메서드의 가독성
+
+```kotlin
+fun start() {
+    val amount = retryUntilSuccess { readAmount() }
+    val manualLotteryCount = retryUntilSuccess { readManualLotteryCount(amount) }
+    val manualLotteriesInput = readManualLotteries(manualLotteryCount)
+    val splitManualLotteries = splitManualLotteries(manualLotteriesInput)
+    val manualLotteries = issueManualLotteries(splitManualLotteries)
+    val autoLotteries = issueAutoLotteries(amount, manualLotteryCount)
+    val ticket = issueTicket(manualLotteries, autoLotteries, amount)
+    printTicketInfo(ticket)
+.
+}
+```
+
+리뷰어: "동료 개발자가 보게 되었을 경우 빠른 시간 내 이해하기 어떨까요? *파편화 되어 있는 함수들을 순서대로 보았을 때 이해하기 쉽도록* 해볼 수 있을 것 같아요. 1. 사용자로부터 입력 받는 함수 2. 로또 생성 함수 3. 당첨 로또 입력 받는 함수 4. 당첨금 계산. 식으로 Controller 내부에서도 함수들을 정리해 볼 수 있겠네요." 학생 정리.
+
+### 5. 1000원 미만 = 종료, 잔돈 안내 부재 — 키오스크 비유
+
+리뷰어: "현재는 구입금액이 1000원 미만이면 *바로 Exception을 발생시켜 종료*시키고 있습니다. 식당의 키오스크를 생각해 보면, 기본금액 5000원 이상인 식당에서 우리가 *현금을 1000원을 넣는다고 프로그램이 종료*될까요? *5000원 이상 투입* 안내문구를 띄운다든가, 무엇이 잘못됐는지 알려줘 가이드를 할 수 있겠죠. 미션에서 요구하는 *논리적인 오류*는 사용자가 경험하는 *모든 과정*에 있어서 Exception을 던져야 하는 상황인지, 혹은 어떠한 오류가 발생했을 때 적절하게 *문제를 해결하도록* 할 것인지 기대." — 키오스크 비유로 *재시도 vs 종료* 명확화.
+
+### 6. Controller에서 Amount null 처리 vs InputView에서 null 반환
+
+```kotlin
+// Controller 내에서 처리
+private fun readAmount(): Amount {
+    return runCatching {
+        Amount.fromInput(inputView.readAmount()) ?: readAmount()
+    }.getOrElse { throwable ->
+        outputView.printError(throwable.message ?: "잘못된 입력")
+        readAmount()
+    }
+}
+```
+
+리뷰어: "Controller에서 try-catch or runCatching 같은 코드들이 필요 없게 할 수 있을까요? *InputView로부터 검증된 Amount를 Controller가 전달받는다면 어떨까요*? `fun readAmount(): Amount? { runCatching { Amount(readln().toInt()) }.getOrNull() }`. 이렇게 *Amount?*를 nullable하게 활용할 수 있겠네요." — null 반환으로 *Controller가 분기*.
+
+### 7. `ManualLotteriesGenerationStrategy` — *단순 매핑*에 Strategy?
+
+```kotlin
+class ManualLotteriesGenerationStrategy(.) : LotteriesGenerationStrategy {
+    override fun generate(): List<Lottery> = manualLotteries.map { Lottery.fromInput(it) }
+}
+```
+
+리뷰어: "`ManualLotteriesGenerationStrategy`의 역할에 대해서 살펴보면 현재 *단순 Lottery로 mapping*해 주는 것 외에는 비즈니스 로직이 존재하지 않습니다. `RandomLotteriesGenerationStrategy`의 경우엔 *랜덤이라는 비즈니스 로직*이 존재하지만, List<List<Int>> -> List<Lottery> 과정에서 과연 *ManualLotteriesGenerationStrategy가 정말 필요한가*에 대해 생각해 보아도 좋을 것 같아요. 어차피 검증 로직은 Lottery에 존재." 학생: "전략 패턴을 사용했으니 *꼭 이걸 수동 로또에도 이용해야겠다는 생각에 갇혀있었던 것* 같습니다. 개발도 *상황에 따라 유연하게 사고*하는 게 중요하다."
+
+### 8. *재귀 InputView*가 *Controller 제어권* 박탈
+
+```kotlin
+private fun readManualLottery(): List<Int> {
+    val lottery = splitManualLottery(readln()).mapNotNull { it.toIntOrNull() }
+    if (lottery.size == LOTTERY_COUNT) return lottery
+    println(EXCEPTION_IS_NOT_NUMBER)
+    return readManualLottery()
+}
+```
+
+리뷰어: "이것은 *예외가 발생했을 때의 처리 제어권*을 어디로 위임할 거냐로 볼 수 있습니다. 예외 상황이 발생했을 때 이곳처럼 *다시 해당 함수를 호출하는 상황*에서는 *Controller가 개입을 할 수 없습니다*. 1차적으로 InputView에서 숫자로 이루어졌는지 확인을 한 후, LotteryNumber로 wrapping 하는 과정에서 *Controller에게 null을 반환*하여 Controller에서 *null에 대한 처리를 하게끔 제어권을 넘겨주는* 건 어떨까요?" + "만약 요구사항이 변경되어 예외 상황에 대한 추가 로직이 필요할 때 현재로서는 InputView에 코드를 추가하여 *view에서 비즈니스 로직을 처리*하게 될 겁니다. 결국 *MVC 패턴 구조의 장점이 사라지게* 되겠죠."
+
+### 9. `ManualLotteryCount.validatePurchaseBound`의 require가 종료 유발
+
+```kotlin
+private fun readManualLotteryCount(amount: Amount): ManualLotteryCount {
+    while (true) {
+        val manualLotteryCount = ManualLotteryCount.fromInput(.)
+        if (manualLotteryCount != null) return manualLotteryCount
+        OutputView.printError(EXCEPTION_IS_NOT_NUMBER)
+    }
+}
+```
+
+리뷰어: "ManualLotteryCount 내부 validatePurchaseBound의 require로 인해 Exception이 발생하면 어떻게 될까요? 위의 readAmount()와 같이 *빈번한 Exception 발생*은 프로그램 실행에 *좋은 영향을 주지 않습니다*."
+
+### 10. 테스트 Fixture 인라인
+
+리뷰어: "참고로 테스트에 *Test Fixture*라는 개념이 있습니다. 이는 여러 테스트에서 같은 Data를 사용할 때, *코드 중복을 피하면서 가독성을 높이는* 방법."
+
+## 리뷰어 의견 요지
+
+- **이중 컬렉션 `List<List<X>>` 회피** — *도메인 객체*로 감싸기.
+- **관련 값 *응집 클래스*** — `Amount` + `ManualLotteryCount`처럼 *함께 쓰이는 값*은 *PurchaseInformation*.
+- **Machine에 *주체적 책임*** — Controller는 *조립*, Machine이 *발행+티켓 반환*.
+- **키오스크 비유** — *논리 오류*는 *바로 종료*가 아니라 *재시도 안내*.
+- **InputView가 null 반환 → Controller가 분기** — *제어권*을 Controller로.
+- **Strategy는 *비즈니스 로직이 있을 때*만** — 단순 매핑은 *추상화 비용*만.
+- **재귀 InputView = MVC 장점 소실** — *view에서 비즈니스 분기*가 누적.
+- **Test Fixture** — 중복 데이터 *명시적 변수*로.
+
+- **대표 인용:**
+  > 동료 개발자가 유지보수를 맡았을 때, `List<List<String>>`을 보고 어떤 의미를 갖는 데이터인지 쉽게 알 수 있을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > 식당의 키오스크를 생각해 보면, 기본금액 5000원 이상인 식당에서 우리가 현금을 1000원을 넣는다고 *프로그램이 종료*될까요? 5000원 이상 투입 안내문구를 띄운다든가, 무엇이 잘못됐는지 알려줘 가이드.
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LotteryController.kt`
+
+  > 다시 해당 함수를 호출하는 상황에서는 Controller가 개입을 할 수 없습니다. *Controller에게 null을 반환*하여 Controller에서 null에 대한 처리를 하게끔 *제어권을 넘겨주는* 건 어떨까요?
+  > — @KwonDae on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > `ManualLotteriesGenerationStrategy`의 역할은 *단순 Lottery로 mapping*해 주는 것 외에는 비즈니스 로직이 존재하지 않습니다. 과연 *정말 필요한가*에 대해 생각해 보아도.
+  > — @KwonDae on `src/main/kotlin/lotto/view/InputView.kt`
+
+## 얻은 교훈
+
+- **이중 컬렉션은 의도 모호** — `List<List<X>>`보다 *도메인 객체*로 감싸기.
+- **관련 값 *응집 클래스*** — `Amount` + `ManualLotteryCount`처럼 *함께 쓰이는 값*은 *PurchaseInformation*.
+- **Machine에 *주체적 책임*** — Controller는 *조립*, Machine이 *발행+티켓 반환*까지.
+- **키오스크 비유** — *논리 오류*는 *바로 종료*가 아니라 *재시도 안내*.
+- **InputView가 null 반환** — Controller에 *분기 제어권*. 재귀 호출은 *Controller 제어권 박탈* + *MVC 장점 소실*.
+- **Strategy는 *비즈니스 로직이 있을 때*** — *단순 매핑*에 Strategy 도입은 *추상화 비용*만. 패턴에 *갇히지 말 것*.
+- **Test Fixture** — 중복 데이터를 *명시적 변수*로 분리 + *재사용*.
+- **`runCatching.getOrNull()`** — *예외를 null로 흡수*하는 표준 패턴.
+- **Kotlin이 *Checked Exception*을 제공하지 않는 이유** — 예외 처리에 *정답은 없음*, *Result/null/예외*를 *상황에 맞게*.

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

@@ -0,0 +1,19 @@
+# PR #17 — [둘리] 1단계 로또
+
+- **Reviewee:** [@hyemdooly](https://github.com/hyemdooly)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/17
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 10
+
+## 핵심 지적
+
+- **Rank `values()` 활용 간결화**.
+- **LottoResult 함수 분리 + 변수 단계 가독성**.
+- **LottoNumber 재사용 (flyweight)**.
+- **`Amount` 원시값 포장 + 검증 위임**.
+
+## 얻은 교훈
+
+- **`values().find/forEach`** — enum 전체 순회 표준.
+- **LottoNumber flyweight** — 1억 티켓도 45개 인스턴스만.

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

@@ -0,0 +1,23 @@
+# PR #28 — [둘리] 2단계 로또
+
+- **Reviewee:** [@hyemdooly](https://github.com/hyemdooly)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/28
+- **단계:** 2단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 10
+
+## 잘한 점
+
+- **`Count` 값 포장 + operator overloading** — 칭찬.
+
+## 핵심 지적
+
+- **operator overloading의 반환 타입 = 감싸는 원시값 X**. 같은 wrapper 타입으로.
+- **LottoStore를 수동에도 활용** — 자동/수동 통합.
+
+> Lotto 를 생성하는 방식이 구매 방식에 따라 파편화되기 시작하면, 점점 구조를 파악하는데 어려움이 생길 수 있.
+
+## 얻은 교훈
+
+- **operator overload 반환 = 같은 wrapper 타입**. `Money + Money = Money`.
+- **자동/수동 통합 = LottoStore 인터페이스**. 파편화 회피.

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

@@ -0,0 +1,171 @@
+# PR #15 — [뽀또] 1단계 로또 제출합니다
+
+- **Reviewee:** [@hyunji1203](https://github.com/hyunji1203)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/15
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 85
+
+## 잘한 점 (설계 관점)
+
+- **`Money`, `Lotto`, `Lottos`, `Rank`, `WinningResult`, `LottoGenerator` 도메인 분리** — 책임 단위로 클래스.
+- **`LottoGenerator` 인터페이스** — `RandomLottoGenerator` 구현체 분리.
+- **`Rank` enum + 등수별 출력 override** (개선 필요).
+- **`require()` 활용**.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller의 lateinit + Coordinator 책임 모호
+
+```kotlin
+class LottoGame {
+    private val input by lazy { InputView() }
+    private val output by lazy { OutputView() }
+    lateinit var money: Money
+    lateinit var lottos: Lottos
+    lateinit var winningResult: WinningResult
+
+    fun run() {
+        initGame()
+        startGame()
+        endGame()
+    }
+}
+```
+
+`money`, `lottos`, `winningResult`가 Controller 멤버 변수로 보유 → 함수 결과 예측 어려움.  
+`initGame/startGame/endGame`이 public → 외부에서 잘못된 순서로 호출 가능.
+
+### 2. `BonusNumber`가 Lotto와 별개 클래스 (도메인 중복)
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    init {
+        require(numbers.size == 6) { INPUT_LOTTO_SIZE_ERROR_MESSAGE }
+        require(numbers.toSet().size == 6) { INPUT_LOTTO_DUPLICATE_ERROR_MESSAGE }
+        require(numbers.filter { number -> number in 1..45 }.size == 6) { INPUT_LOTTO_RANGE_ERROR_MESSAGE }
+    }
+    fun countMatchNumber(lotto: Lotto): Int {. }
+    fun hasBonusNumber(bonusNumber: BonusNumber): Boolean {. }
+}
+```
+
+`1..45` 범위 검증이 `Lotto` 내부 + `BonusNumber` 내부 양쪽에. → **`LottoNumber` 값 객체로 추출하면 중복 제거 + 도메인 개념 1급화**.
+
+### 3. `Lotto`가 내부 `numbers`를 외부에 그대로 노출
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    fun countMatchNumber(lotto: Lotto): Int {
+        return numbers.filter { lotto.numbers.contains(it) }.size  // ⚠ 외부에서도 numbers 직접 접근
+    }
+}
+```
+
+호출처에서 `lotto.numbers.contains(.)` 같은 로직이 가능 → 캡슐화 약함.
+
+### 4. OutputView가 도메인 계산까지
+
+```kotlin
+class OutputView {
+    fun outputLottoSizeMessage(money: Money) {
+        println((money.price / LOTTO_PRICE).toString() + OUTPUT_LOTTO_SIZE_MESSAGE)
+    }
+}
+```
+
+> "구매 가능한 로또의 갯수를 OutputView가 너무 똑똑하게 알고 있지는 않을까요? 만약, 로또 구매 갯수를 계산하는 비즈니스 로직이 수정된다면, UI 코드가 바뀌어야 하겠죠?"
+
+→ 계산은 도메인(`Money.numberOfLottos()` 같은), 출력은 UI.
+
+### 5. `Rank` enum에 UI 표현 override
+
+```kotlin
+enum class Rank(val countOfMatch: Int, val winningMoney: Int) {
+    FIRST(6, 2_000_000_000),
+    SECOND(5, 30_000_000) {
+        override fun toString(): String = RANK_BONUS_MESSAGE.format(countOfMatch, winningMoney)
+    },
+.
+    override fun toString(): String = RANK_MESSAGE.format(countOfMatch, winningMoney)
+}
+```
+
+> "Rank에 대한 출력 값은 UI의 관심사입니다. 도메인 모델에서 UI 로직을 제거하고."
+
+### 6. `null` 대신 `MISS` enum 활용 미흡
+
+```kotlin
+fun findRank(.): Rank? {. }  // ⚠ MISS가 있는데 null 반환
+```
+
+> "MISS 라는 타입이 있으니 논리적으로 null을 반환하는 것 보다 MISS를 반환하는게 좋지 않을까요?"
+
+### 7. 테스트가 다른 도메인을 끌어들임
+
+```kotlin
+class LottoTest {
+    @Test
+    fun `랜덤.`() {
+        val lottos = RandomLottoGenerator().generateLottos(.)  // ⚠ LottoTest인데 Generator 등장
+    }
+}
+```
+
+> "이 테스트는 LottoTest이기 때문에 LottoGenerator를 사용하지 않고 작성되어야 합니다."
+
+### 8. 테스트 함수명 모호
+
+```kotlin
+fun `입력된 금액이 null 일 때`() {. }
+```
+
+→ null일 때 *무엇을* 검증? 예외 발생? 기본값 반환? 본문을 봐야 앎.
+
+### 9. 커밋 단위 — 구현 없이 테스트만 추가
+
+```
+test(MoneyTest): 입력된 금액 확인하는 테스트 추가
+```
+
+> "하나의 기능 (커밋)은 반드시 테스트 코드와 구현 코드가 같이 존재해야 합니다. 지금 커밋에서는 Money라는 객체가 없기 때문에 오류가 발생합니다."
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 핵심 가르침 (racingcar에서도 동일 학생을 본 리뷰어):
+
+1. **"로또 번호" 도메인 추출** — `Lotto`와 `BonusNumber`가 같은 범위(1-45) 검증을 중복하면 그건 *공통 개념*이 누락된 신호. `LottoNumber` 값 객체로.
+
+2. **컬렉션 추상화 = 일급 컬렉션** — Lotto가 `List<LottoNumber>`를 그대로 노출하지 말고, "로또 번호들" 객체를 만들어 (1) 6개 보장, (2) 일치 개수 계산, (3) 포함 여부 등 메서드만 노출.
+
+3. **UI는 똑똑하지 않게** — 도메인 계산이 OutputView에 들어가면 UI 수정 시 도메인 영향. 도메인이 계산해서 결과만 UI로.
+
+4. **`null` 대신 enum 케이스** — `MISS`가 있으면 그걸 반환. `null` 처리 강제는 호출자의 부담.
+
+5. **테스트는 한 클래스에 집중** — `LottoTest`에서 `LottoGenerator`를 쓰면 테스트 범위 흐림. SUT(Subject Under Test) 명확히.
+
+- **대표 인용:**
+  > 로또에서 사용하는 번호가 BonusNumber와 중복해서 로직을 사용하고 있습니다. "로또 번호" 라는 역할을 만들어서 개선 해보세요.
+  >
+  > — @laco-dev on `src/main/kotlin/domain/Lotto.kt`
+
+  > Lotto를 사용하는 곳에서는 numbers 라는 타입이 몇개인지 알지 못하고, 위 작성된 코드처럼 로직이 외부로 노출되는 문제로 이어질 수 있습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/domain/Lotto.kt`
+
+  > 구매 가능한 로또의 갯수를 OutputView가 너무 똑똑하게 알고 있지는 않을까요? 만약, 로또 구매 갯수를 계산하는 비즈니스 로직이 수정된다면, UI 코드가 바뀌어야 하겠죠? UI에서는 최대한 똑똑하지 않게 만드는 것도 좋습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/view/OutputView.kt`
+
+  > MISS 라는 타입이 있으니 논리적으로 null을 반환하는 것 보다 MISS를 반환하는게 좋지 않을까요?
+  >
+  > — @laco-dev on `src/main/kotlin/domain/Rank.kt`
+
+## 얻은 교훈
+
+- **중복된 검증 = 누락된 도메인 개념의 신호**. Lotto의 number(1-45) + BonusNumber(1-45) → 공통 개념 `LottoNumber`로 추출. 검증이 한 곳에.
+- **일급 컬렉션의 가치 = "어떻게 다루는지를 캡슐화"**. `List<Int>` 그대로 노출하면 호출처가 `.contains()`, `.filter()` 직접 사용. 일급 컬렉션 (`Numbers`)이 메서드만 노출하면 외부는 도메인 어휘로만 대화.
+- **UI는 똑똑하지 않게** = OutputView가 도메인 계산하면 도메인 변경이 UI까지 번짐.
+- **enum의 모든 상태를 활용 = `null` 회피**. `MISS`/`NONE` 케이스가 있으면 그걸 반환. `Rank?` 같은 nullable로 호출자 부담 늘리지 말 것.
+- **테스트의 SUT 명확히**. `LottoTest`는 `Lotto`만 검증. 다른 클래스 사용 = 테스트 범위 흐려짐.
+- **커밋 단위 = "테스트 + 구현 함께"**. 컴파일 안 되는 커밋은 그 시점의 상태를 다시 가져갈 수 없음.

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

@@ -0,0 +1,150 @@
+# PR #48 — [뽀또] 2단계 로또
+
+- **Reviewee:** [@hyunji1203](https://github.com/hyunji1203)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/48
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @laco-dev (라코)
+- **라인 코멘트:** 34 (리뷰어 19 + 학생 15)
+
+## 잘한 점 (설계 관점)
+
+- **`Lottos` 위임 활용** — 리뷰어 칭찬: "*위임을 이용해 Lottos가 리스트 타입이 되도록 한 점은 잘 해 주셨*습니다. 👍🏻".
+- **`Rank` 테스트 명세성** — 칭찬: "*Rank가 어떤 기능을 하는지, 어떤 등수가 있는지 테스트 코드만 보고 바로 이해할 수 있게 되었어요*. 👍🏻".
+- **`LottoGenerator` 인터페이스** — 시도.
+- **`LottoMaker` 도입** — 후속 *간소화*.
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoMaker` *협력 없는 단독 생성* + RandomLottoGenerator 직접 의존
+
+```kotlin
+class LottoMaker {
+    fun make(): Lotto {
+        val generator = RandomLottoGenerator()  // ⚠ 직접 생성
+        return.
+    }
+}
+```
+
+리뷰어: "1. *LottoMaker는 아무런 협력이 없이, 단순히 로또를 만들고만 있*어요. 2. *도메인 로직이 다시 RandomLottoGenerator()라는 불확실성과 의존성을 가지게 되었*어요. *로또를 만든다 → 로또 제너레이터에게 로또를 요청한다 → 로또를 반환한다* 순서의 흐름이 되려면 어떻게 할 수 있을까요? *의존성을 주입하는 방법은 생성자 뿐만 아니라 대표적으로 3가지 방법*을 사용할 수 있습니다."
+
+### 2. *수동/자동 generator 인터페이스 분리* — 추상화 목적 상실
+
+학생 후속: "*수동 로또 제너레이터 인터페이스와 자동 로또 제너레이터 인터페이스를 따로*"
+
+리뷰어: "*방향을 잘못 접근*하셨습니다. *수동인지 자동인지를 모르게 하기 위한 목적인데, 따로 만든다는 것 자체가 근본적으로 인터페이스로 만들 이유가 없게 되지 않을까요*?"
+
+추가 (인터페이스 의도): "로또 제너레이터가 인터페이스로 만들어지게 되면서 *기대할 수 있는 것은 구현에 관심없이 로또 번호를 반환하는 것*을 생각할 수 있습니다. 하지만 지금은 *RandomLottoGenerator만 사용되고, 수동 로또는 InputView에서 바로 만들고 있*습니다. 이 경우, *인터페이스 활용을 못하고 있다*고 볼 수 있습니다. 로또 메이커에게 → 로또를 만들어 주세요 → *로또를 어떻게 만들어요* → 로또 번호 제너레이터에게 요청해요 → 로또를 만들어서 돌려줘요. 이러한 요구사항을 구현하면서, *랜덤 로또 번호를 만들어 줄지, 수동 로또 번호를 만들어 줄지 모르게 만드는 것이 목표*이겠습니다." — 안티.
+
+리뷰어 후속 (정답 제시):
+```kotlin
+class LottoMaker {
+   // 더이상 수동으로 만들지, 자동으로 만들지 관심이 없어짐
+   fun makeLottos(count: Int, lottoGenerator: LottoGenerator): Lottos {
+      return Lottos(lottoGenerator.generate(count))
+   }
+}
+// 호출부
+val manualLottos = lottoMaker.makeLottos(ManualLottoGenerator)
+val autoLottos = lottoMaker.makeLottos(RandomLottoGenerator)
+```
+
+### 3. `RandomLottoGenerator` *도메인 모델 위치* 의문
+
+리뷰어: "저는 *랜덤 로또 제너레이터 구현체가 도메인 모델에 위치할 필요가 있을까? 생각이 들기도* 해요. 로또 게임이라는 도메인 안에서 *랜덤으로 만들어서 돌려준다가 비즈니스 로직이라고 볼 수도 있지만, 다르게 생각하면 어떻게 입력받는지 상관없이 LottoGenerator만 알면 되지 않을까*? 라고 생각을 해서요. 그렇게 본다면 예를 들어 *로또 번호를 키오스크에서 입력받을 수도 있고, 종이로도 입력받을 수도 있고 등등 다양한 방법*이 존재합니다. 즉, *도메인 외에 여러 가지 다양한 의존성을 가질 수 있다는 의미*인데요. 하지만 필요한 것은 *LottoGenerator라는 인터페이스 타입만 필요하지 구현체에는 관심이 없어야* 합니다. 그런 의미로 저는 *게임을 어떻게 풀어낼지 결정하는 위 구현체는 컨트롤러 쪽에서 결정이 되어야 하지 않을까* 합니다."
+
+### 4. Controller 검증 *중복*
+
+리뷰어: "*이 검증 로직은 도메인 모델에서 수행하고 있기 때문에 중복이라고 볼 수 있지 않을까요*?"
+
+### 5. *Rank fallback null* — `MISS` 활용
+
+```kotlin
+fun from(.): Rank? = entries.find {. }  // ⚠ null
+```
+
+리뷰어: "*일치하지 않는 Rank가 있는 경우, MISS 타입을 반환해야 하지 않을까요*??" + "*Rank의 miss 타입을 사용하기 때문에 null 타입으로 반환하지 않아도 되지 않을까요*!?" — *NullObject 패턴*: `MISS`가 *null 대체*.
+
+### 6. *파라미터는 불변 List*
+
+리뷰어: "*파라미터를 받을 때에는 가급적 불변 객체인 List 타입을 받도록* 합니다." — `MutableList` 외부 노출 X.
+
+### 7. `Lottos.count` 위임 vs *명시 메서드*
+
+리뷰어: "위임을 이용해 Lottos가 리스트 타입이 되도록 한 점은 잘 해 주셨습니다. 👍🏻 다만, *객체가 해야 할 책임과 비즈니스 로직을 외부에서 뺏어서 작성할 수 있다는 의중성은 잘 염두해 두시면* 좋겠습니다. 가령 아래와 같이 *Lottos에게 요청을 해야 할 로직도 밖에서 작성할 위험*을 가집니다.
+```kotlin
+val lottos: Lottos
+val lottoMatchCount = lottos.count {. } // 이게 호출이 되니 자연스럽게 이렇게 하게 됨
+
+val lottos: Lottos
+val lottoMatchCount = lottos.getMatchCount() // 이게 맞음!
+```" — *위임의 양면성*: *컬렉션 인터페이스 노출*은 *외부 조립 유혹*.
+
+### 8. `matchLottos` *중복 함수*
+
+리뷰어: "이미 WinningResult를 반환하는 위 matchLottos 함수가 있는데, *이 함수가 새로 만들어진 이유가 무엇*인가요??"
+
+### 9. *INPUT_XX 네이밍 — UI 결합*
+
+리뷰어: "*도메인 로직이기 때문에 INPUT_XX 형태로 UI 입력과 관련성이 있는 네이밍은 피하는 게 좋겠*습니다." — *도메인 어휘*는 *UI 무관*.
+
+### 10. `getOrDefault` vs `getOrElse`
+
+리뷰어: "*getOrDefault() 함수는 실제 값을 가져오기 먼저 호출이* 됩니다. *getOrElse {. }와 getOrDefault() 함수가 어떤 차이를 가지는지* 한번 고민해 보세요." — *eager evaluation* vs *lazy evaluation*. `getOrDefault(key, expensiveCall())`은 *항상 expensiveCall 실행*.
+
+### 11. *라인 줄이려고 가독성 희생*
+
+리뷰어: "*라인 수를 줄이기 위해 가독성이 많이 떨어졌*습니다. *변수를 이용해 가독성을 개선*해 보세요."
+
+### 12. *프로퍼티 이름 대문자* — Kotlin 컨벤션
+
+리뷰어: "*프로퍼티의 이름은 소문자로 시작*해야 합니다. https://kotlinlang.org/docs/coding-conventions.html#naming-rules"
+
+### 13. *파라미터 이름 `a`* — 모호
+
+리뷰어: "*'a'가 무엇일까요*..? *파라미터를 단순한 이름으로 사용하지 말아야* 합니다. *코틀린 컬렉션의 plus 함수에는 무엇으로 사용하는지 찾아*보세요." — Kotlin `plus(other:.)`.
+
+### 14. `println()` *디버깅 잔여물*
+
+리뷰어: "*println()은 어떤. 과정으로 추가가 되었을까요*?" — *PR 셀프 리뷰 부재*.
+
+## 리뷰어 의견 요지
+
+- **`LottoMaker` *협력자 주입***.
+- **`LottoGenerator` 인터페이스의 *목적 = 구현체 무지***. *수동/자동 분리*는 본질 위반.
+- **`RandomLottoGenerator` *도메인 위치* 의문** — *키오스크/종이* 시나리오.
+- **검증 중복 제거**.
+- **`Rank.MISS` *NullObject*** = null 회피.
+- **파라미터 = *불변 List***.
+- **위임 시 *명시 메서드 우선*** — 위임 메서드가 *외부 조립 유혹*.
+- **`getOrDefault` vs `getOrElse`** — *eager vs lazy*.
+- **`INPUT_XX` 네이밍 *UI 결합 회피***.
+- **변수 이름 *의미 부여***.
+- **`println` 디버깅 잔여물**.
+
+- **대표 인용:**
+  > 인터페이스로 만들어지게 되면서 기대할 수 있는 것은 *구현에 관심없이 로또 번호를 반환하는 것*을 생각할 수 있습니다.
+  > — @laco-dev on `src/main/kotlin/domain/LottoMaker.kt`
+
+  > 따로 만든다는 것 자체가 *근본적으로 인터페이스로 만들 이유가 없게 되지 않을까요*?
+  > — @laco-dev on `src/main/kotlin/domain/LottoGenerator.kt`
+
+  > 객체가 해야 할 책임과 비즈니스 로직을 *외부에서 뺏어서 작성할 수 있다는 의중성은 잘 염두*해 두시면 좋겠습니다.
+  > — @laco-dev on `src/main/kotlin/domain/Lottos.kt`
+
+  > getOrDefault() 함수는 *실제 값을 가져오기 먼저 호출*이 됩니다.
+  > — @laco-dev on `src/main/kotlin/domain/WinningResult.kt`
+
+## 얻은 교훈
+
+- **`LottoMaker` *협력자 주입*** — *new RandomGenerator()*는 *결합 강제*. *생성자/세터/인터페이스 주입* 3방법.
+- **인터페이스 *목적 = 사용자가 구현체 모름*** — *수동/자동 인터페이스 분리*는 *목적 위배*. **공통 시그니처**만이 본질.
+- **`RandomLottoGenerator` *도메인 위치* 의문** — *키오스크/종이* 시나리오 시 *Generator 구현체는 Controller가 선택*.
+- **`Rank.MISS` = *NullObject 패턴*** — `Rank.from(): Rank?`보다 `Rank.from(): Rank = MISS`가 *호출자 null 처리 불요*.
+- **파라미터 = *불변 List<T>*** — `MutableList` 외부 노출은 *침습적 수정 허용*.
+- **위임 메서드 = *명시 메서드 우선*** — `: List<T> by numbers`로 `lottos.count { winningContains(it) }`이 *외부 조립*. `lottos.getMatchCount(winning)`이 *Tell-Don't-Ask*.
+- **`getOrDefault` vs `getOrElse`** — *eager vs lazy*. *비용 있는 fallback*은 `getOrElse {. }`.
+- **`INPUT_XX` *UI 결합 어휘***. 도메인은 *순수 도메인 단어*.
+- **`println` 잔여물 = *PR 셀프 리뷰 부재***.
+- ***Kotlin 컨벤션 프로퍼티 소문자***.
+- **파라미터 이름 = *의미 있는 단어*** — `a`, `b`, `i`는 *컨벤셔널 인덱스*에만.

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

@@ -0,0 +1,104 @@
+# PR #62 — [로또] 하디 미션
+
+- **Reviewee:** [@ii2001](https://github.com/ii2001)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/62
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 59
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto`, `WinningNumber`, `LottoGenerator`, `LottoPrize` 분리**.
+- **`Constant` 사용**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Veilfier` — 오타 + 의미 불명
+
+```kotlin
+class Veilfier {. }
+```
+
+> Veilfier 는 어떤 뜻인가요? 검색해도 어떤 뜻인지 잘 모르겠네요
+
+→ `Verifier`의 오타 + 의미 모호. 클래스명은 *검색해서 의미를 알 수 있어야*.
+
+### 2. `Lotto.numbers: List<Int>` — LottoNumber 미추출
+
+```kotlin
+class Lotto(val numbers: List<Int>) {. }
+```
+
+> Int로 단일 로또 번호에 대한 제약 사항을 충분히 표현해낼 수 있을까요? 로또 번호 하나를 객체로써 의미를 담아보는건 어떨까요?
+
+→ lotto의 핵심 안티패턴 (PR마다 반복).
+
+### 3. `WinningNumber` — 값만 보유, 행위 없음
+
+```kotlin
+class WinningNumber(val number: Int) {
+    // 행위 없음
+}
+```
+
+> 이 객체는 단순히 값을 가지고있는 것 외에 별다른 역할을 가지고 있지 않고 있네요 이 객체가 맡을만한 일이 무엇인지 찾아 이 객체에게 부여해보는 건 어떨까요?
+
+→ 값 객체 만들었으면 *행위*도 부여. 매칭 판정, 보너스 일치 여부 등.
+
+### 4. `Constant` god-class — 자가 의문 유도
+
+```kotlin
+object Constant {
+    const val LOTTO_PRICE = 1000
+    const val MIN = 1
+.
+}
+```
+
+> 이 값들을 하나의 상수 클래스로 묶은 이유가 궁금해요! 필요한 객체가 갖고 있는 것과 어떤 차이점과 장단점이 있었나요?
+
+### 5. `LottoGenerator` 테스트 없음
+
+```kotlin
+class LottoGenerator { fun generate(): Lotto =. }
+// ⚠ 테스트 없음 (랜덤 의존)
+```
+
+> LottoGenerator에 대한 테스트 코드가 존재하지 않네요 이 객체는 어떻게 테스트 가능하게 만들어볼 수 있을까요? 자동차 경주에서의 랜덤 테스트를 어떻게 만들었는지 다시 되새겨보아요
+
+→ NumberGenerator 인터페이스로 추상화. racingcar에서 학습한 패턴.
+
+### 6. `LottoPrize`에 뷰 요소
+
+```kotlin
+enum class LottoPrize(val countOfMatch: Int, val prize: Int, val message: String) {. }
+```
+
+> 도메인 로직에 뷰 요소가 들어있네요!
+
+→ lotto의 또 다른 반복 안티패턴 — Rank/Prize enum에 표시 문자열.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun의 가르침:
+
+1. **클래스명 = 검색해서 의미 추적 가능해야** — `Veilfier` 오타.
+
+2. **`LottoNumber` 추출** — lotto 마스터 키.
+
+3. **값 객체에 행위 부여** — 값만 있으면 그저 wrapper.
+
+4. **god-class `Constant` vs 필요한 객체가 자체 보유**.
+
+5. **테스트 가능성 = racingcar 학습 적용** — NumberGenerator 추상화.
+
+- **대표 인용:**
+  > 이 객체는 단순히 값을 가지고있는 것 외에 별다른 역할을 가지고 있지 않고 있네요 이 객체가 맡을만한 일이 무엇인지 찾아 이 객체에게 부여해보는 건 어떨까요?
+  >
+  > — @malibinYun on `src/main/kotlin/lotto/model/WinningNumber.kt`
+
+## 얻은 교훈
+
+- **클래스명 = 검색 가능한 단어** — 오타/조어는 동료가 의미 추정 어려움.
+- **값 객체에 행위 부여 필수**. 값만 있는 wrapper는 *얇은 위장*. 행위가 있어야 객체.
+- **이전 미션 (racingcar) 학습 적용** — NumberGenerator 추상화는 racingcar에서 받은 가르침. 동일 패턴.

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

@@ -0,0 +1,20 @@
+# PR #88 — [로또] 하디 2단계 미션
+
+- **Reviewee:** [@ii2001](https://github.com/ii2001)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/88
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 6
+
+## 핵심 지적
+
+- **수동 티켓 생성을 적절한 객체로 이동**.
+- **테스트 픽스처 적용**.
+- **1단계 피드백 (PR #62) 유지** — `LottoPrize`에 뷰 요소.
+
+> https://github.com/woowacourse/kotlin-lotto/pull/62#discussion_r1502612429 여전히 유효한 피드백입니다.
+
+## 얻은 교훈
+
+- **이전 라운드 피드백 *지속적 검증***. 2단계에서 1단계 피드백 미반영은 *학습 후퇴*.
+- **테스트 픽스처 = `@BeforeEach`** — 반복 setup 제거.