oh-my-oop 0.2.0

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

@@ -0,0 +1,140 @@
+# PR #91 — [로또] 심지 2단계
+
+- **Reviewee:** [@sh1mj1](https://github.com/sh1mj1)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/91
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 42
+
+## 잘한 점 (설계 관점)
+
+- **`LotterySeller`로 게이트키퍼 도입** — Controller가 `LotteryMachine`에 직접 접근하지 않고 `LotterySeller`를 거치도록. Façade/게이트키퍼.
+- **`Money`는 `private constructor` + `wons(.)` 팩토리** — 단위(원화)를 코드에 명시.
+- **`LotteryNumber` Flyweight** — `(1..45).associateWith(::LotteryNumber)` 캐싱.
+- **원시값 포장의 *동기*를 명확히 문서화** — `Quantity` 도입 이유로 "1년 후의 나는 다른 개발자"를 제시.
+- **요구사항 변경 시나리오까지 README에 기록** — 미래 변경에 대한 사고 흔적.
+- **Strategy 패턴 도입에 *감정적 거리*를 둠** — 학생이 "디자인 패턴에 너무 집착하는 모습"을 스스로 경계.
+
+## 못한 점 (설계 관점)
+
+### 1. `Money`가 이율 계산까지 — 책임 비대
+
+```kotlin
+class Money private constructor(val amount: BigDecimal) : Comparable<Money> {
+    fun calculateProfitRate(totalWinningPrize: Money): ProfitRate =
+        ProfitRate(totalWinningPrize / this)
+}
+```
+
+학생도 호출이 `지불금액.calculateProfitRate(총당첨금)` 형태가 어색하다고 인지. 리뷰어 지적: "이율이란 어떤 계산 기준이냐에 따라 달라질 수 있어 보여요. Money 자체가 이런 기준들을 갖고 있는 건 조금 어색… 이율을 계산하는 수식들이 늘어난다면, Money에 해당 수식을 계산하는 메서드들이 그만큼 증가해야 할까요?" — *수익률은 Money의 본질이 아니라 두 Money 간 관계*.
+
+### 2. `Money.from(input: String)` — Money가 파싱 책임까지
+
+```kotlin
+companion object {
+    fun from(input: String): Money {. }  // 문자열 → Money
+}
+```
+
+리뷰어: "돈으로 입력받는 문자열이 매우 많아진다면, 이 메서드에서 그 모든 돈을 표현하는 문자열에 대해 인식하는 로직을 이 객체에서 처리해야 할까요?" — 파싱은 *입력 어댑터*의 책임, Money는 *값*만.
+
+### 3. `Lotteries.evaluateWinning(winningLottery)` — INFORMATION EXPERT 오용
+
+```kotlin
+data class Lotteries(val lotteries: List<Lottery>) {
+    fun evaluateWinning(winningLottery: WinningLottery): WinningResult {
+        lotteries.forEach {. winningLottery.evaluateWinningRank(it). }
+    }
+}
+```
+
+학생: "Lotteries가 정보가 가장 많다고 생각해서 책임을 줬다." 리뷰어: "당첨 티켓이 한 장의 로또 티켓을 비교하는 역할이 있으니, n 장을 비교하는 역할도 자연스럽다." — INFORMATION EXPERT는 *절대 정보량*이 아니라 *개념적 책임 소유*. "당첨 발표"의 주체는 `WinningLottery`. 단, 옮기면 *단일 비교 메서드*가 외부에서 호출되지 않아 테스트하기 어려워지는 새로운 트레이드오프 발생.
+
+### 4. `compareLottery(other): Quantity` — 명명 혼동
+
+```kotlin
+fun compareLottery(other: Lottery): Quantity =
+    Quantity(lotteryNumbers.count { it in other.lotteryNumbers })
+```
+
+리뷰어: "`compare`라는 단어는 `compareTo()` 메서드가 먼저 떠오르네요. 저는 Boolean을 반환할 거란 느낌이 들었어요." — Kotlin/Java 관용상 `compare*`는 정렬용 정수/불리언. 매칭 개수면 `matchCount`, `countMatches`.
+
+### 5. `Lottery` / `LotteryNumber`가 `equals`/`hashCode`/`toString` 수동 override
+
+```kotlin
+override fun equals(other: Any?): Boolean {. }
+override fun hashCode(): Int = lotteryNumbers.hashCode()
+override fun toString(): String = "Lottery(lotteryNumbers=$lotteryNumbers)"
+```
+
+원래 `data class`였던 것을 `private constructor`로 바꾸면서 보일러플레이트 부활. 캐시(Flyweight)와 data class 자동 생성 사이의 트레이드오프를 학생이 의식하지 못함.
+
+### 6. `LotteryMachine.generateRandomLottery()` — 테스트 불가능
+
+```kotlin
+class LotteryMachine {
+    fun generateRandomLottery(): Lottery =
+        Lottery.of(*(MIN..MAX).shuffled().take(6).sorted().toIntArray())
+}
+```
+
+리뷰어: "랜덤에 대한 요소를 외부로부터 받게끔 만들어보는 건 어떨까요?" — 랜덤이 메서드 내부에 박혀 있으면 출력 검증 불가. *랜덤 요소를 인터페이스로 빼면 영향 범위가 최소화*.
+
+### 7. `Lottery.of(numbersStrategy: NumbersStrategy)` 단일 진입점 강제
+
+```kotlin
+fun of(numbersStrategy: NumbersStrategy): Lottery =
+    Lottery(numbersStrategy.generate().map { LotteryNumber.of(it) })
+```
+
+리뷰어: "이 로또 객체는 NumbersStrategy가 없으면 생성하기가 매우 까다롭겠어요. Lottery 객체는 정말로 NumbersStrategy로만 생성하게끔 제한해야 할까요?" — 게다가 `ExplicitNumbersStrategy`는 *로또 1장당 1개씩* 생성. 수동 N장이면 N개의 전략 인스턴스 — 비용 증폭.
+
+### 8. `WinningRank`의 보너스 필드 — enum이 2등만의 정보 보유
+
+```kotlin
+enum class WinningRank(
+    val numbersMatchQuantity: Quantity,
+    val bonusNumberMatch: Boolean,  // ⚠ 사실상 2등 전용
+.
+)
+```
+
+리뷰어 의도: "2등이 될 수 있는 조건을 enum의 필드 값으로 알리지 않고, 등수를 찾는 로직에서 어떨 때 2등을 반환하는지를 코드로 녹여보라." — 도메인 *분기 조건*을 enum 필드로 인코딩하면 다른 등수의 boolean이 무의미 + "왜 이 필드가 있는지"를 사용처 보지 않으면 모름.
+
+### 9. `Quantity.init` — 사실상 도달 불가능한 검증
+
+학생 분석: "현 시스템에서 `from` 메서드 제외하면 논리적으로 count가 0 미만이 되지 않을 것이지만, 코드가 예측 가능하게 동작하려면 객체가 생성될 때 검증을 해 주는 것이 적절." — 트레이드오프(불필요 검증 비용 vs 미래 변경 안전망)에 *정량적 기준이 없다*고 토로. 리뷰어 답: 정량적 기준보다 "이 코드를 아무도 해석할 수 없는 여지가 있는가"를 기준으로 한다.
+
+## 리뷰어 의견 요지
+
+1. **책임의 자리 = "이 행위의 *개념적 주체*"** — 정보량이 많다고 책임을 가지지 않음. "당첨 발표"의 주체는 `WinningLottery`.
+2. **확장 함수 어휘로 의도를 압축** — `groupingBy {. }.eachCount()`로 `forEach + Map[k]!! + Quantity(1)` 같은 절차적 누산을 제거.
+3. **`operator`로 자연어 흐름 만들기** — `contains` operator로 `number in lottery` 가능. 도메인 어휘를 키워드 수준으로 끌어올림.
+4. **랜덤은 *없앨 수 없고 가두기*만 가능** — 테스트 불가능 영역을 최소화하는 것이 목표. 디자인 패턴은 그 *수단*일 뿐.
+5. **enum의 필드는 *항상 모든 케이스에 의미*가 있어야 함** — 한 케이스만의 조건이 enum 필드로 들어가면 응집도 깨짐.
+6. **예외 메시지에 입력값 포함** — 사용자도 자신이 잘못 입력한 값을 알 수 있음.
+7. **디자인 패턴은 룰이 아니라 패턴** — 의도를 담는 것이 우선, 패턴 적용은 *결과*.
+
+- **대표 인용:**
+  > Money 자체가 이율을 반환하는게 저는 조금 어색하게 느껴지네요. 이율이란 어떤 계산 기준이냐에 따라 달라질 수 있어 보여요.
+  > — @malibinYun on `src/main/kotlin/model/Money.kt`
+
+  > 당첨 티켓이 한 장의 로또 티켓을 비교하면서 결과를 내주는 역할이 있으니, 당첨 티켓이 n장의 로또 티켓을 비교하는 역할을 갖는 것도 자연스럽다는 생각이 드네요.
+  > — @malibinYun on `src/main/kotlin/model/lottery/Lotteries.kt`
+
+  > 우리가 하고자 하는 것은 불가능한 랜덤 테스트를 가능으로 변경하는 게 아니에요. 테스트가 불가능한 곳을 최대한 줄여내는 것이 목표예요.
+  > — @malibinYun on `src/main/kotlin/model/lottery/strategy/RandomNumbersStrategy.kt`
+
+  > compare라는 단어는 compareTo() 메서드가 먼저 떠오르네요. 저는 Boolean을 반환할 거란 느낌이 들었어요.
+  > — @malibinYun on `src/main/kotlin/model/lottery/Lottery.kt`
+
+## 얻은 교훈
+
+- **INFORMATION EXPERT는 정보 *소유권*에 관한 것, 정보 *양*이 아님**. "당첨 발표"는 당첨 티켓의 행위로 읽혀야 자연스럽다. 컬렉션이 검색·필터·집계를 다 흡수하면 컬렉션이 비대해짐.
+- **`Money`/`Quantity` 같은 값 객체에 *계산 결과 타입*을 만들지 말 것**. `calculateProfitRate(Money) -> ProfitRate`처럼 외부 타입을 생산하는 메서드는 그 외부 타입의 책임. 두 값의 관계는 *제3의 객체* 또는 호출자 책임.
+- **파싱은 *입력 어댑터*의 책임**. `Money.from(String)`이 String 형식을 안다는 것은 도메인이 입력 형식에 결합. 입력 변환은 View/Mapper에서.
+- **`compare*` 명명은 *비교/정렬*에만**. 매칭 개수면 `matchCount`/`countMatches`. Kotlin/Java 관용을 거스르면 호출자가 시그니처를 두 번 본다.
+- **랜덤은 *최외곽으로 가두기*가 패턴 적용보다 우선**. Strategy를 도입했어도 `RandomNumbersStrategy` 자체가 테스트 불가하면, 패턴은 *영향 범위 축소*에만 기여. 디자인 패턴은 *목적*이 아니라 *결과*.
+- **enum 필드는 모든 케이스에 의미가 있어야 응집**. 한 케이스 전용 필드(예: 2등 전용 `bonusNumberMatch`)는 *분류*가 아니라 *분기 입력*이며, 그건 로직으로 표현해야 한다.
+- **`init` 검증의 *동기*는 도달 가능성이 아니라 *시간*이다**. 지금 도달 불가능해도 미래 변경으로 도달 가능해질 수 있음. "1년 후의 다른 개발자가 이 객체에 대해 무엇을 가정할 수 있는가"가 기준.
+- **단일 진입점 강제는 비용**. 정적 팩토리 하나로 통합하면 사용처 어휘는 깔끔해지지만 *인스턴스 생성 비용*과 *경직성*이 따라옴. 수동 로또 N장에 전략 인스턴스 N개는 과한 비용.

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

@@ -0,0 +1,96 @@
+# PR #65 — [로또] 알송 1단계 미션
+
+- **Reviewee:** [@songpink](https://github.com/songpink)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/65
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 75
+
+## 잘한 점 (설계 관점)
+
+- **`Rank` enum + countOfMatch 필드** — 등수와 일치 개수를 묶음.
+- **출력 문구 상수화**.
+- **`LottoPurchase`, `LottoResult` 등 도메인 분리 시도**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Rank.countOfMatch` 정의했지만 활용 안 함
+
+```kotlin
+enum class Rank(val countOfMatch: Int, val winningMoney: Int) {
+    FIRST(6, 2_000_000_000),
+    SECOND(5, 30_000_000),
+.
+}
+// ⚠ countOfMatch가 enum에 박혀 있지만, 호출처에서는 별도 매칭 로직 사용
+```
+
+> Rank에 정의한 countOfMatch가 활용되지 못하고 있지 않을까요?
+
+→ enum의 데이터가 *호출처가 사용해야 의미*. Rank가 스스로 매칭 책임을 가지면 호출처 코드 줄어듦.
+
+### 2. 보너스 일치 로직이 OutputView에
+
+```kotlin
+// OutputView 안
+if (rank == Rank.SECOND) {
+    println("${rank.countOfMatch}개 일치, 보너스 볼 일치")
+} else {
+    println("${rank.countOfMatch}개 일치")
+}
+```
+
+리뷰어 핵심 지적:
+
+> 2등이 보너스 번호가 있다는 것은, 비즈니스 로직에서 결정되는 내용입니다. 만약 2등이 아닌 3등이 보너스 번호가 있었다면, 출력하는 곳에서는 이를 알기 어렵게 됩니다. 보너스 번호가 일치하는지에 대해서도 Rank가 가지도록 만들어 보면 어떨까요?
+
+→ Rank에 `matchBonus: Boolean` 필드 추가, View는 단순히 `if (rank.matchBonus) ", 보너스 볼 일치"` 형태로 줄이기.
+
+### 3. 테스트가 매직 상수 1000에 직접 의존
+
+```kotlin
+@Test
+fun `10000원으로 10개를 구매할 수 있다`() {
+    val purchase = LottoPurchase(10000)
+    assertThat(purchase.numberOfLottos).isEqualTo(10)  // ⚠ 1000원/개라는 내부 상수에 의존
+}
+```
+
+> 로또 가격이 현재는 1000원이기 때문에 테스트가 통과합니다. 하지만 로또 가격이 변경된 순간 이 테스트는 실패하게 됩니다. 내부적인 상수에 직접 의존하지 않고 조금 더 확장성 있는 구조로 만드려면 어떻게 할 수 있을까요?
+
+### 4. 함수명 `getNum()` — 무엇을 반환?
+
+```kotlin
+fun getNum(result: Map<Rank, Int>, rank: Rank): Int {
+    return result[rank] ?: 0
+}
+```
+
+> `getNum(.)` 이라는 함수 이름만 두고 봤을때 결과로부터 무엇을 반환하고 있는지 예측이 되지 않습니다.
+
+→ `countOf(rank)` 같은 도메인 어휘.
+
+### 5. 출력 메시지 반복 — for문 + println
+
+→ StringBuilder/buildString으로 한 번에 합쳐 한 번만 print.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 핵심 메시지:
+
+1. **enum의 데이터를 *enum이 직접 활용*하게** — `countOfMatch`/`matchBonus`를 enum이 들고 *매칭 책임*까지 가지면 호출처 코드가 줄어듦.
+
+2. **boolean을 View가 결정하지 말 것** — "2등은 보너스 일치"는 도메인 규칙. View가 알면 도메인 규칙 변경이 View 변경.
+
+3. **테스트의 내부 상수 의존 회피** — 로또 가격 1000원이 변하면 테스트도 깨진다 = 테스트가 *프로덕션의 구현 디테일*에 묶임.
+
+- **대표 인용:**
+  > 2등이 보너스 번호가 있다는 것은, 비즈니스 로직에서 결정되는 내용입니다. 보너스 번호가 일치하는지에 대해서도 Rank가 가지도록 만들어 보면 어떨까요?
+  >
+  > — @laco-dev on `src/main/kotlin/view/OutputView.kt`
+
+## 얻은 교훈
+
+- **enum의 데이터 = enum 자신이 활용해야 의미.** 호출처가 enum 데이터를 꺼내 비교/매칭하면 enum의 가치 줄어듦. enum이 행위까지 가지면 *closed enum의 OOP 본연*.
+- **View의 분기 조건이 도메인 규칙이면 → 도메인으로**. `if (rank == SECOND) bonusMsg` = 도메인 규칙. Rank가 `matchBonus` 필드를 직접 가지면 View는 무지.
+- **테스트의 내부 상수 의존 = brittle test**. 로또 가격이 1000 → 5000으로 바뀌면 같은 테스트가 깨짐. 테스트는 *명세*를 검증해야지 *구현*을 검증하면 안 됨.

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

@@ -0,0 +1,64 @@
+# PR #99 — [로또] 알송 2단계 미션
+
+- **Reviewee:** [@songpink](https://github.com/songpink)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/99
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 55
+
+## 잘한 점 (설계 관점)
+
+- **`ManualLottoMachine` 분리 시도**.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller에서 랜덤 생성 — 1단계 피드백 미반영
+
+```kotlin
+class LottoController {
+    fun run() {
+        val numbers = (1..45).shuffled().take(6)  // ⚠ Controller에서 직접 랜덤
+    }
+}
+```
+
+학생 의문:
+
+> 만약 도메인로직이 아니라면 controller에서 랜덤넘버를 생성하는 것이 좋을 것 같습니다
+
+리뷰어:
+
+> 이 내용이 아직 반영이 안된 것 같은데요 무엇이 궁금하신 것일까요?
+
+### 2. `Map<Rank, Int>` 그대로 노출
+
+```kotlin
+fun calculateRanks(): Map<Rank, Int> =.
+```
+
+> `Map<Rank, Int>` 라는 타입으로만 본다면, 값이 무엇인지 예측이 어려울 수 있는데요 모든 원시값을 포장하는 연습을 한다고 했을 때, `Map<Rank, Int>` 라는 타입도 포장하도록 만들어 보면 어떨까요?
+
+→ `LottoWinningRank` 같은 *집계 객체*로 wrapping.
+
+### 3. `ManualLottoMachine` — 전달자 역할만
+
+```kotlin
+class ManualLottoMachine(private val numbers: List<List<Int>>) {
+    fun generate(): List<Lotto> = numbers.map { Lotto(it) }
+}
+```
+
+> 지금의 로또 머신은 단순히 생성자로 받은 값을 그대로 전달하는 역할만 하고 있습니다. 협력이라는 관계로 접근한다면, 번호를 전달하는 메시지로 만들어 보면 어떨까요?
+> ```kotlin
+> class LottoMachine(private val lottoNumbersGenerator: LottoNumbersGenerator) {
+>    fun make(count): List<Lotto>
+> }
+> ```
+
+→ Strategy 패턴 — 수동/자동을 인터페이스 구현체 교체로.
+
+## 얻은 교훈
+
+- **`Map<X, Int>` 도 wrapping 대상**. 의미가 약한 자료구조 노출 회피. `WinningRankCount(map)` 같은 객체.
+- **단순 전달자 객체 = 의미 없는 추상화**. 생성자가 받은 값을 그대로 노출만 하면 객체일 필요 없음. *행위*가 있어야.
+- **Strategy 패턴 = 수동/자동/반자동 확장의 표준 답**. 인터페이스 + 구현체 교체.

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

@@ -0,0 +1,20 @@
+# PR #10 — [하티] 1단계 로또
+
+- **Reviewee:** [@sujin9](https://github.com/sujin9)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/10
+- **단계:** 1단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 14
+
+## 학생 자가 의문
+
+> 유효성 검사나 규칙 위반 (ex. 금액에 음수가 입력된 경우 등)에 대한 검사가 어디서 이루어져야 하는지 고민이 되었습니다. 우선 빈칸이나 공백만 입력되는 경우.
+
+> 1급 컬렉션을 만들어 생성할 때, 예를 들어 List<LottoNumber> 의 경우 생성 시에 이 형태를 그대로 받는 것이 너무 불필요한 작업이 많이 필요하다고 느껴져서.
+
+→ Fake Constructor로 해소.
+
+## 얻은 교훈
+
+- **검증의 위치 = 형식 (View) + invariant (Domain init)** 두 분류.
+- **`List<LottoNumber>` 생성 = Fake Constructor 패턴**. `Lotto(1, 2, 3, 4, 5, 6)` 같은 짧은 진입점.

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

@@ -0,0 +1,124 @@
+# PR #35 — [하티] 2단계 로또
+
+- **Reviewee:** [@sujin9](https://github.com/sujin9)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/35
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` `value class` + `private constructor`** — 원시값 포장 + 인라인.
+- **`InputInterface`/`OutputInterface` 추상화 + Fake 구현체** — Controller 단위 테스트 시도.
+- **`LottosGenerator` 인터페이스** — Strategy 패턴.
+- **자가 의문 PR에 풍부히 명시** — *원시값 포장 필요성*, *Controller 테스트 범위*, *Fake 분리* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. 원시값 포장의 *과잉 자가 의문*
+
+학생: "`money`와 같은 값도 객체로 감싸 줄 필요가 있을까? 객체가 결국 money라는 int 값만 가지고 있는 상태라면, 굳이 감싸 줄 필요가 없지 않을까?" 리뷰어: "크게 필요성을 느끼지 못한다면 따로 분리하지 않으셔도 좋습니다. … 미션에서와는 다르게 *모든 원시 타입을 포장*하기보다는 *도메인에 중요한 경우*에만 포장해서 활용하는 편입니다." 리뷰어 가치 제시:
+- 타입이 다르면 *컴파일 오류로 잘못 넘김 방지*
+- 여러 layer에서 원시 타입 사용 시 *어디서 잘못된 데이터*가 들어갔는지 추적 어려움
+- 중복 유효성 검사 → wrapper class면 *생성 시점*에 빠르게 실패
+
+### 2. `Rank` ParameterizedTest 파라미터 타입
+
+```kotlin
+@CsvSource("1 2 3 4 5 6, FIRST",.)
+fun `일치하는 번호 개수에 따라 Rank를 구한다`(numbers: String, result: String) {
+.
+    assertThat(.).isEqualTo(Rank.valueOf(result))
+}
+```
+
+리뷰어: "junit에서 내부적으로 `valueOf()`를 사용하기 때문에 `result: Rank`로 곧바로 선언하셔도 됩니다." — 변환 *외부 호출*은 불필요.
+
+### 3. private 함수를 테스트하려고 public화
+
+```kotlin
+class LottoController(.) {
+    fun getNumberOfLotto(money: Int): Int = money / LOTTO_PRICE  // ⚠ 테스트 위해 public
+}
+```
+
+리뷰어: "테스트를 위해 private 함수를 public으로 만들어 주는 것은 지양해 주세요. 가능한 한 공개되어 있는 함수를 통해 *간접적으로* 테스트해 주셔야 합니다. 그 이유는 private 함수의 경우에는 *해당 클래스의 내부 구현체*라고 볼 수 있고 public 함수는 *해당 클래스의 API*. private 함수를 테스트한다는 것은 내부 구현을 건드린다는 것 → 추후에 요구사항이 변경되면 테스트 케이스가 깨지게 되는 가장 큰 원인."
+
+### 4. `LottoNumber.number` 노출 vs `toInt()` — 차이는?
+
+리뷰어: "내부 필드는 감추고 `toInt()`와 같은 함수를 제공해 주는 건 어떨까요? 2가지 방식의 차이점은 무엇일까요?" 학생 시도: "기능적으로 차이점이 있는지 아직 잘 모르겠습니다." 리뷰어: "기능적으로는 차이가 없지만 추후 유지보수할 때를 위해 조금 더 클린한 코드. 내부 구현인 `number`를 숨길 수 있습니다. 이를 통해 *이름을 변경하거나 Int 타입을 Long, Float 타입으로 변경*하는 것이 자유로워집니다."
+
+### 5. `RandomLottosGenerator` — 복수 명사 어색
+
+```kotlin
+class RandomLottosGenerator : LottosGenerator {. }
+```
+
+리뷰어: "우리가 '자동차들 공장'이라고 부르지 않고 '자동차 공장'이라고 부르듯이 기존 LottoGenerator 네이밍이 더 자연스럽게 느껴져요." — *발행물의 단수형*이 자연.
+
+### 6. 테스트 본문에 *계산 로직*
+
+```kotlin
+assertThat(actual).containsExactlyInAnyOrder(
+    "수동 1장 자동 3장",
+    "수익률 ${round((5_000 + 30_000_000 + 50_000) / 4000.toDouble() * 100) / 100}"
+)
+```
+
+리뷰어: "테스트 코드에는 로직이 있어선 안 됩니다. 예상되는 값을 하드코딩해 주세요!" + "테스트 본문에는 테스트하고자 하는 것을 이해할 수 있는 정보를 모두 가지고 있어야 하고, 반대로 *불필요한 내용을 전부 감추어야* 합니다."
+
+### 7. `inner class` Fake 구현체 vs 별도 클래스
+
+```kotlin
+class LottoControllerTest {
+    inner class TestInputView() : InputInterface {. }
+    inner class TestOutputView(.) : OutputInterface {. }
+    inner class TestGenerator : LottosGenerator {. }
+}
+```
+
+리뷰어: "Fake 구현체는 재사용 가능한 형태로 분리해 주시면 좋습니다. … 외부로 상태를 전달해 주세요. `FakeOutputInterface(onPrintPurchaseCounts:., onPrintUserLottos:., onPrintResult:.)` 같이 *생성자에 콜백*으로." — *고차 함수 주입*으로 *호출 검증*까지 가능.
+
+### 8. 학생 자가 의문 — Controller 테스트 범위
+
+학생: "컨트롤러를 테스트할 때 중점적으로 보아야 하는 부분은 무엇일까요? 세세한 로직들에 대한 단위 테스트들이 있는 상태에서 컨트롤러를 테스트한다는 건 전체적인 흐름을 보기 위한 역할로 보아야 하는 걸까요?" 리뷰어: "도메인 객체를 mocking 하지 않고 테스트를 작성하면 통합 테스트. 도메인 객체를 mocking해서 테스트하면 사실상 Controller에 대한 단위 테스트. 실제 업무에서는 Controller에 해당되는 클래스들이 비즈니스 로직을 가지게 되는 경우도 많이 생기게 되어서 테스트가 필요."
+
+### 9. 자동/수동 통합 — 주석 흐름 시도
+
+학생 시도: 테스트 픽스처에 *어느 줄이 무슨 등수*인지 주석. 리뷰어: "주석은 코드가 *어떤 일을 하는지*가 아니라 *왜 존재하는지*를 담고 있어야 합니다. 코드만 봐서는 어떤 일을 하는지 이해가 잘 안 된다면 *코드를 더 간단하게* 고쳐야 합니다." + 후속: "지금 코드에서도 `ManualLottoGenerator`를 만들어서 Controller를 통해 호출하도록 만들면 일관되게 프로그램을 구현."
+
+## 리뷰어 의견 요지
+
+- **원시값 포장은 *도메인에 중요한 경우*만** — 무조건 모두 포장 X.
+- **`enum` 타입은 junit이 *valueOf* 자동 변환** — 직접 enum 인자 가능.
+- **private 함수를 테스트하려고 public화 금지** — 책임 분리로 해결.
+- **value class의 *필드 숨김*은 미래 타입 변경에 유연**.
+- **명명은 *단수형*** — *발행물 N개*를 만드는 *공장*은 `LottoGenerator`.
+- **테스트 본문에 *로직* X** — 하드코딩.
+- **Fake는 *재사용 가능*하게 분리 + 고차 함수 콜백**.
+- **Controller 테스트의 *범위*는 mocking 여부에 따라 달라짐**.
+
+- **대표 인용:**
+  > 미션에서와는 다르게 모든 원시 타입을 포장하기보다는 도메인에 중요한 경우에만 포장해서 활용하는 편입니다.
+  > — @galcyurio on `README.md`
+
+  > 테스트를 위해 private 함수를 public으로 만들어 주는 것은 지양해 주세요. … 추후에 요구사항이 변경되면 테스트 케이스가 깨지게 되는 가장 큰 원인이 됩니다.
+  > — @galcyurio on `src/main/kotlin/lotto/domain/LottoController.kt`
+
+  > 우리가 '자동차들 공장'이라고 부르지 않고 '자동차 공장'이라고 부르듯이 기존 LottoGenerator 네이밍이 더 자연스럽게 느껴져요.
+  > — @galcyurio on `src/main/kotlin/lotto/model/generator/RandomLottosGenerator.kt`
+
+  > 테스트 코드에는 로직이 있어선 안 됩니다. 예상되는 값을 하드코딩해 주세요!
+  > — @galcyurio on `src/test/kotlin/lotto/domain/LottoControllerTest.kt`
+
+## 얻은 교훈
+
+- **원시값 포장은 *선택적***. *타입 잘못 넘김 방지*, *논리 오류 추적*, *중복 검사 제거*가 가치 — 그 가치를 얻을 곳만 포장.
+- **junit의 *enum 자동 변환*** — `result: Rank`로 직접 선언, `valueOf()`는 내부에서 자동.
+- **private 함수 테스트 충동 = 책임 분리 신호**. public API로 *간접 테스트*, 또는 *책임을 다른 객체*로.
+- **value class의 *필드 숨김*** — 미래의 *타입 변경*(Int → Long)에 호출자가 영향 받지 않음.
+- **명명은 *단수형*** — *공장의 본질*은 *발행물*이 아니라 *공장 자체*. `LottosGenerator` → `LottoGenerator`.
+- **테스트 본문 = *입력과 기대 결과*만**. *계산식*은 *어떤 식이 옳은지*를 *테스트가 가정*하게 됨 — *명세서*가 아닌 *실행*.
+- **Fake는 *고차 함수 콜백*으로** — `onPrint*: (X) -> Unit` 형태면 *호출 횟수/순서/인자*까지 검증 가능.
+- **주석은 *왜*에만**. *코드가 복잡해서 주석으로 보충*하면 *복잡함이 해결책*이 아니라 *복잡함의 노출*.
+- **Controller 테스트는 *mocking 여부*에 따라 *단위 vs 통합***. 실무에서 Controller가 *비즈니스 로직*을 가지면 테스트 필수.

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

@@ -0,0 +1,30 @@
+# PR #22 — [부나] 1단계 로또
+
+- **Reviewee:** [@tmdgh1592](https://github.com/tmdgh1592)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/22
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 13
+
+## 핵심 지적
+
+### 1. `.editorconfig` 같은 IDE 파일 — `.gitignore` 권장
+
+### 2. `divideByThousand` 확장 함수
+
+```kotlin
+fun Int.divideByThousand(): Int = this / 1000
+```
+
+> 이 부분은 money 에 대한 원시값을 포장하고, 해당 클래스 내부에서 처리되는 것이 더 적절하지 않을까요?
+
+→ 확장 함수가 *공용 유틸*인데 *Money 도메인 지식*을 가짐. Money 객체로.
+
+### 3. `divideByThousand` 이름 일반적인데 메시지는 도메인 특화
+
+> 오류 메세지는 '입력값' 이라는 내용을 내포하고 있는 부분 자체가 common 한 케이스를 다루지 않는.
+
+## 얻은 교훈
+
+- **`util/common` 확장 함수에 도메인 지식 누수 회피**. 도메인 객체로 흡수.
+- **함수 이름과 에러 메시지 일관성** — `divideByThousand`가 일반 유틸이면 도메인 메시지 X.

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

@@ -0,0 +1,20 @@
+# PR #30 — [부나] 2단계 로또
+
+- **Reviewee:** [@tmdgh1592](https://github.com/tmdgh1592)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/30
+- **단계:** 2단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 14
+
+## 핵심 지적
+
+- **LottoNumber의 Int 변환 검증 — 어디서?**
+
+> number 가 int 로 변환할 수 있는 숫자 형태인지는 입력 레벨에서도 검증이 가능할 것 같은데요. 타입에 대한 검증을 view 에서 하는게 적절할지, domain 에서.
+
+- **Money에 operator 활용 권장**.
+
+## 얻은 교훈
+
+- **Int 변환 검증 = View (형식)**. 도메인은 Int 받고 *범위*만 검증.
+- **`operator` (`+`, `-`)** — Money 같은 산술 도메인에 자연.