oh-my-oop 0.2.0

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

@@ -0,0 +1,67 @@
+# PR #105 — [로또 1단계] 뭉치 미션
+
+- **Reviewee:** [@m6z1](https://github.com/m6z1)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/105
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 46
+
+## 못한 점 + 핵심 지적
+
+### 1. Lotto에 Set 미적용 (List + 중복 검증)
+
+```kotlin
+class Lotto(val numbers: List<LottoNumber>) {
+    init { require(numbers.toSet().size == numbers.size) }  // ⚠ 매번 변환
+}
+```
+
+> set을 활용해보는 건 어떨까요?
+
+→ 도메인 자체에 *중복 없음 invariant*가 있다면 Set으로 저장.
+
+### 2. LottoMachine — 테스트 어려운 구조
+
+```kotlin
+class LottoMachine {
+    fun generate(count: Int): List<Lotto> {
+        repeat(count) {. Random.nextInt(.). }  // ⚠ Random 직접
+    }
+}
+```
+
+> 이 클래스는 테스트하기 매우 어려운 구조네요. 랜덤 요소를 분리해내서 테스트할 수 있도록 구성해보는 건 어떨까요?
+
+### 3. `mutableListOf + add` 패턴
+
+```kotlin
+val lottos = mutableListOf<Lotto>()
+repeat(count) { lottos.add(generateOne()) }
+return lottos
+```
+
+> 코틀린 Collections 확장함수들을 활용한다면 지금처럼 mutableList를 만들어서 add 하는 형태의 코드를 작성하지 않아도 된답니다!
+
+→ `List(count) { generateOne() }`.
+
+### 4. `LottoNumber` 직접 equals/hashCode
+
+```kotlin
+class LottoNumber(val value: Int) {
+    override fun equals(.): Boolean =.
+    override fun hashCode(): Int =.
+}
+```
+
+> 직접 equals & hashCode를 구현하신 이유는 무엇인가요? data class 와 class의 차이점에 대해 알아보세요!
+
+→ data class 또는 value class가 자동 생성.
+
+### 5. LottoNumber 캐싱 미적용
+
+## 얻은 교훈
+
+- **도메인 invariant 표현 = 자료구조 선택**. *중복 없음*은 Set으로.
+- **`List(count) {. }` Kotlin builder** — mutableListOf + repeat 패턴 대체.
+- **data class / value class > 직접 equals/hashCode**.
+- **flyweight** — 1억 티켓도 LottoNumber 45개 재활용.

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

@@ -0,0 +1,104 @@
+# PR #151 — [로또 2단계] 뭉치 미션
+
+- **Reviewee:** [@m6z1](https://github.com/m6z1)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/151
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **1단계 코멘트를 PR에 명시적 링크 + 답변** — 학습 흐름이 PR에 *명시적으로 남음*.
+- **`LottoNumbersGenerator` 인터페이스 + `Auto*`/`Manual*` 구현체** — Strategy.
+- **`runCatching + getOrElse`로 재시도 흐름**.
+- **`size` 필드 vs `get()` 트레이드오프 인지** — *불변 객체*는 필드, 가변은 get().
+- **자가 의문 PR에 풍부히 명시** — *수동 generator의 존재 의미*, *LottoMachine 호출 = Lotto 호출과 무엇이 다른가* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoMachine`이 *하는 일 부재*
+
+```kotlin
+class LottoMachine {. }
+```
+
+리뷰어: "이 객체는 하는 일이 전혀 없어요. LottoMachine.createLotto()를 호출하는 것과 Lotto() 생성자를 호출하는 것은 무엇이 다른가요? Controller에 있는 *로또 생성에 대한 일련의 로직*을 분리해 보세요." + "이 객체가 LottoNumbersGenerator를 가지도록 만들어 보세요. 테스트 가능하도록 구조를 변경하면서요." 학생 수정: "로또 번호 생성기를 추상화하여, 자동 생성기와 수동 생성기를 구현. 로또 기계에서 로또를 발행할 때는 로또 번호 생성기와 발행할 로또의 개수를 매개변수로 받아 로또 생성 로직을 `LottoMachine` 객체로 분리."
+
+### 2. `WinningLotto.findLottoRank`을 `Lotto.getRank(winningLotto)`로 이동
+
+```kotlin
+// 변경
+fun getRank(winningLotto: WinningLotto): Rank {
+    val matchCount = getMatchCount(winningLotto.winningNumbers)
+    val isMatchedBonus = isMatchedBonusNumber(winningLotto.bonusNumber)
+    return Rank.findRank(matchCount, isMatchedBonus)
+}
+```
+
+리뷰어: "이 메서드의 위치는 어떤 이유로 옮겨진 걸까요?" 학생: "Lotto 내부로 옮긴 후의 로직을 보니 lotto에서 *winningLotto의 값을 직접 꺼내 사용*하게 되는 일이 생겼습니다. WinningLotto에게 직접 메시지(몇 개 맞는지/보너스 포함 여부)를 던지게 되어도 Lotto 내부의 메서드와 같은 로직 → 다시 *WinningLotto가 Lotto를 받아* '내 기준 너는 몇 등이다'로 반환." — *메시지 방향*을 다시 뒤집음.
+
+### 3. `LottoCount.validateLottoMaxCount(other)` — 자기 자신 타입을 받는 검증
+
+```kotlin
+class LottoCount(val count: Int) {
+    fun validateLottoMaxCount(totalCount: LottoCount) {
+        require(count <= totalCount.count) {. }
+    }
+}
+```
+
+리뷰어: "이 메서드는 어떤 역할을 수행하는 건지 알기가 너무 어렵네요. *왜 이 객체 안에 존재*해야 하는 것인지, *이름으로 어떤 일*을 하는 것인지, *왜 자기 자신과 같은 인스턴스*를 받아야 하는지 등등에서요. 정말 필요한 기능이었나요? 또, Exception을 던져서만 로직을 구성할 수 있는 것이었나요?" 학생: "오류가 생기면 무조건 Exception을 던진다고만 생각해서 구현. *isAvailablePurchase* 함수를 구현하여, 구매가 불가능할 경우 사용자에게 다시 입력받도록 수정."
+
+### 4. `data class Lotto`로 변경 — 그러나 변경 의도
+
+```kotlin
+- class Lotto(
++ data class Lotto(
+      val numbers: List<LottoNumber>,
+)
+```
+
+학생: "사용자가 중복된 값을 입력했을 때 *입력한 로또 번호 개수는 5개입니다*라는 메시지를 보고 중복된 값이 제거되어 입력한 로또 번호 개수가 5개라는 것을 사용자가 판단하기엔 *불친절*하다고 생각." 리뷰어: "여전히 *도메인을 개발하는 사람과 어플리케이션을 사용하는 사람*과의 관계가 공감이 가지 않네요. 뷰에서 중복된 값 자체를 받지 못하도록 막는 기능이 생긴다면 여기의 기능은 의미가 있을까요? *Exception 메시지가 정말 애플리케이션 사용자에게 노출되는 메시지인가요?*" — 도메인 검증 메시지는 *개발자용*. 학생 깨달음: "이전에 언급해주셨던 *Glide.with()의 여러 옵션* 라는 말씀과 연결 → 가변인자와 List를 통해 *여러 옵션*을 두도록."
+
+### 5. `isMatchedBonusNumber` — 너무 좁은 이름
+
+리뷰어: "이 메서드의 내용은 꼭 *보너스 번호를 포함*하는지 여부만을 알려주는 기능일까요?" 학생: "함수의 네이밍 및 매개변수의 네이밍을 number로 수정. 보너스 번호가 아닌 *다른 번호로도 포함*되어 있는지 재사용할 수 있도록 수정." — `containsNumber(LottoNumber)`로 일반화.
+
+### 6. `Lotto`가 `List`인가 `Set`인가
+
+리뷰어: "오 그럼에도 불구하고 *주 생성자는 여전히 Set이 아닌 List*로 둔 이유가 있으신가요?" — 학생이 List 유지 의도 미명시.
+
+### 7. *Generator 호출 vs Lotto 호출* 자가 의문
+
+학생: "`Lotto(numbers)`를 이용해 검증을 진행. 이 과정에서 *불필요한 Lotto 인스턴스가 여러 번 생성*. 입력할 때마다 `LottoMachine.createLotto(lottoNumbers)`를 호출하여 로또 하나씩 생성해야 할까? 하지만, 위 로직으로 구현하게 되면 결국 *LottoMachine이 필요할까*?" 리뷰어: "지금의 고민이 굉장히 유의미한 고민이라 생각해요. *어디든 장단점과 트레이드 오프*가 생길 수밖에 없다는 점을 이 고민으로 완전히 체험. 저는 로또 머신이라는 객체가 존재함으로써 *로또를 만들 때는 항상 로또의 생성자를 직접 불러야 하나? 아니면 다른 객체가 있나? 라는 고민을 아예 배제*시켜 줄 수 있다 생각해요."
+
+### 8. `LottoMachine` 생성자 vs 파라미터 — 학습 시드
+
+리뷰어: "파라미터로 구성한 것도 하나의 방법이지만, 생성자로도 변경해 보시면 좋겠어요! *어떤 차이점이 있을지, 장단점은 무엇일지* 고민해 보시면서요."
+
+## 리뷰어 의견 요지
+
+- **도메인 검증 메시지는 *개발자용***, 사용자 메시지는 View 책임.
+- **객체에 *메시지 던지기*로 책임 위임** — `lotto.containsNumber(bonus)` 같이 일반화된 메시지.
+- **자기 자신 타입을 받는 검증 메서드** = *이름과 책임 모호 신호*.
+- **`Lotto`/`LottoMachine` 둘 다 *생성 책임 위치*** — 머신이 있으면 *고민 배제*, 없으면 *추가 객체 없음*. trade-off.
+- **`LottoMachine`은 *LottoNumbersGenerator 보유*가 자연** — *생성자 주입*으로 *상태 + 행위*.
+
+- **대표 인용:**
+  > 이 객체는 하는 일이 전혀 없어요. LottoMachine.createLotto()를 호출하는 것과 Lotto() 생성자를 호출하는 것은 무엇이 다른가요?
+  > — @malibinYun on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+  > Exception 메시지가 정말 애플리케이션 사용자에게 노출되는 메시지인가요?
+  > — @malibinYun on `src/main/kotlin/lotto/model/Lotto.kt`
+
+  > 이 메서드의 내용은 꼭 "보너스 번호를 포함"하는지 여부만을 알려주는 기능일까요?
+  > — @malibinYun on `src/main/kotlin/lotto/model/Lotto.kt`
+
+## 얻은 교훈
+
+- **검증 메시지 = *개발자용***, 사용자 메시지는 View 책임. 둘을 혼동하면 *도메인이 사용자를 의식*.
+- **`isXxxBonusNumber` 같은 *좁은 이름*은 *기능 일반화 신호*** — `containsNumber(LottoNumber)`가 *재사용 가능*.
+- **자기 자신 타입을 받는 검증** — *왜 객체 안에 있나*, *이름이 의도를 표현하나* 의심.
+- **Generator vs 직접 생성자 = 트레이드오프** — Generator는 *고민 배제*, 직접은 *추가 객체 없음*. *어떤 환경*에 따라 선택.
+- **`LottoMachine`은 *LottoNumbersGenerator 보유*가 자연** — 생성자 주입으로 *변경 단일점*.
+- **PR에 *이전 라운드 코멘트 링크*** — 학습 흐름 가시화 + 리뷰어 추적 용이.

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

@@ -0,0 +1,186 @@
+# PR #127 — [로또 1단계] 메다 미션
+
+- **Reviewee:** [@medAndro](https://github.com/medAndro)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/127
+- **단계:** 1단계
+- **리뷰어:** @lee-ji-hoon
+- **라인 코멘트:** 36
+
+## 잘한 점 (설계 관점)
+
+- **원시값 포장(`LottoNumber`/`PurchaseAmount`/`PurchaseQuantity`/`EarningRate`)을 광범위하게 적용** — 각 도메인 어휘 분리.
+- **`LottoGenerator` 분리** — Lotto 생성 로직과 Lotto 검증 분리.
+- **`enum class Rank`로 등수+상금** — 한 enum이 등수 분류 + 상금 가짐.
+- **`PurchaseAmount` 검증을 `PurchaseQuantity`보다 먼저** — 일급 객체끼리 책임 위임 시도.
+- **`Rank.entries.associateWith { 0 }`로 초기 Map 형성** — 누락 등수도 0으로 시작.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto`가 `List<LottoNumber>` — 중복 검증 수동
+
+```kotlin
+class Lotto(val lottoNumbers: List<LottoNumber>) {
+    init {
+        require(lottoNumbers.size == 6) {. }
+        require(lottoNumbers.map { it.number }.distinct().size == 6) {
+            HAS_DUPLICATE_NUMBERS.format(
+                lottoNumbers.map { it.number }.groupBy { it }
+.filter { it.value.size > 1 }.keys.toList().joinToString(", ")
+            )
+        }
+    }
+}
+```
+
+리뷰어: "특정 자료구조를 사용하면 외부에 중복이 불가능한 것을 알려주기도 하면서 중복에 대한 것을 자연스럽게 방지할 수가 있는데요. 그렇게 되면 init에 체이닝도 조금 줄어들 수 있겠네요." — `Set<LottoNumber>` 시그니처면 *중복 불가가 타입에 표현*. init 체이닝 6단계가 줄어듦.
+
+### 2. 한 `init`에 두 책임 + 7단계 체이닝
+
+리뷰어: "지금 한 곳에 서로 다른 역할을 하는 체이닝이 있기 때문인데요. 이 체이닝이 각각 무슨 역할을 하는지를 직접 하나하나 분석을 해서 보는 것 보다 함수로 분리를 한다면 어떨까요?" — *"한 줄에 점 하나"* 원칙. 의도가 다른 체이닝은 메서드명으로 분리.
+
+### 3. `LottoConstants` — 비즈니스 정책과 도메인 규칙 혼재
+
+```kotlin
+object LottoConstants {
+    const val LOTTO_PRICE = 1000              // 비즈니스 정책 (변동)
+    const val NUMBER_OF_LOTTO_NUMBERS = 6     // 도메인 규칙 (불변)
+    private const val MINIMUM_LOTTO_NUMBER = 1
+    private const val MAXIMUM_LOTTO_NUMBER = 45
+    val LOTTO_RANGE = MINIMUM_LOTTO_NUMBER..MAXIMUM_LOTTO_NUMBER
+}
+```
+
+리뷰어: "로또의 가격은 1000원이라는 내용은 비즈니스적인 내용으로 생각할 수도 있지 않을까요?" — 학생 인정: "가격 인상 등 서비스 운영 과정에서 유동적으로 변경되는 *비즈니스 정책*과 운영 중 변경을 할 일이 거의 없는 *도메인 규칙*을 실수로 혼재해 버린 것 같습니다." → 변경 빈도가 다른 상수는 같은 객체에 두지 말 것.
+
+### 4. `LottoNumber`가 인스턴스 폭증 위험
+
+```kotlin
+class LottoNumber(val number: Int) {. }
+```
+
+리뷰어: "`LottoNumber`를 사용하는 `Lotto`가 수십만 개 생겼다고 했을 때 `LottoNumber`도 수십만 개가 생길 텐데요. 이런 상황에서 원시값을 래핑한 경우 특정 클래스를 사용한다면 조금 더 최적화가 가능한데요 한 번 찾아보면 어떨까요?" — *Flyweight* (`(1..45)` 사전 캐싱) 또는 `value class`.
+
+### 5. `PurchaseAmount`의 클래스명 vs 책임 불일치
+
+```kotlin
+class PurchaseAmount(val amount: Int) {
+    init {
+        require(amount > 0)
+        require(amount % LOTTO_PRICE == 0)  // 로또 가격을 이미 안다
+    }
+}
+```
+
+리뷰어: "`구매가격`만으로 보이지만 init을 보면 이 클래스는 로또라는 도메인에 많이 의존되어 있는 것 같은데요. 1) 로또에 대한 의존을 줄인다. 2) 로또에 대한 의존을 두고 클래스명을 수정한다. 어떤 것이 적합할지 한 번 고민해보시면 좋을거 같습니다." — 학생 수긍: "*로또구매가격*인 값을 포장하는 클래스는 필요하다고 생각되어 클래스 이름만 변경." → `LottoPayInfo`로 변경.
+
+### 6. `PurchaseQuantity`가 `runCatching`으로 자기 책임 중복 검증
+
+```kotlin
+class PurchaseQuantity(purchaseAmount: PurchaseAmount) {
+    val quantity = runCatching { purchaseAmount.amount / LOTTO_PRICE }.getOrElse {
+        throw IllegalArgumentException(INDIVISIBLE_VALUE_ERROR.format(purchaseAmount.amount))
+    }
+}
+```
+
+리뷰어: "이 도메인 모델에 대한 테스트 커밋이 안 보이네요. 이 runCatching이 정말 필요했던 것인지 한 번 테스트 코드를 구현해 보면 좋을 것 같습니다." 학생 자가 발견: "`PurchaseAmount`에서 이미 확인했던 걸 또 확인하고 있었네요." → 일급 객체로 받았으면 다시 검증할 필요 없음.
+
+### 7. `InputView`가 직접 `Lotto`/`WinningLotto`/`PurchaseAmount` 생성
+
+```kotlin
+class InputView {
+    fun readPurchaseAmount(): PurchaseAmount {. }
+}
+```
+
+리뷰어: "View가 직접 Model을 만들어 줘도 상관이 없을까요? View의 역할은 무엇일까요?" 학생 정리: "뷰: 단순 형식 변환(String → Int) + 도메인 객체를 전달받아 출력. 컨트롤러: 도메인 객체 생성 + 흐름 관리 + 예외 *처리*. 도메인: 비즈니스 로직 구현 + 자기 검증 및 예외 *발생*."
+
+### 8. `LottoCalculator.getWinningStats()` — Mutable Map 누적
+
+```kotlin
+private fun getWinningStats(): Map<Rank, Int> {
+    val winningStats: MutableMap<Rank, Int> = Rank.entries.associateWith { 0 }.toMutableMap()
+    lottos.forEach {
+        val rank = winningLotto.getRank(it)
+        winningStats[rank] = (winningStats[rank]?.plus(1)) ?: 1
+    }
+    return winningStats
+}
+```
+
+리뷰어: "Mutable한 Map이 없이 이 함수가 하는 동작을 충분히 수정이 가능한데요. `groupingBy` + `eachCount` 등을 잘 사용해보시면 좋을 거 같습니다." — `lottos.groupingBy { winningLotto.getRank(it) }.eachCount()` 한 줄.
+
+### 9. `LottoGenerator`를 별도 클래스로
+
+```kotlin
+class LottoGenerator {
+    fun generateLotto(): Lotto {. }
+}
+```
+
+리뷰어: "Lotto의 생성자나 invoke에서 처리할 수 있을 거 같은데 `LottoGenerator`로 분리를 했을 때 Lotto가 해야 할 일을 나눈 것이 되는데 이렇게 됐을 때 어떤 이점이 있다고 생각하시나요?" 후속: "누군가 `Lotto` Class만 봤을 때 `LottoGenerator`의 유무를 알 수 있을까요? 그냥 `Lotto` 클래스를 그냥 넣어서 만들어 버릴 수도 있을 거 같아요. 그런 상황에서는 `Lotto` 내부에 본인이 생성을 전담하는 방법도 있는데요!" — `Lotto.private constructor + companion object` 팩토리.
+
+### 10. 테스트명/검증 대상 불일치
+
+```kotlin
+@Test
+fun `6개의 로또 번호를 생성한다`() {
+    assertDoesNotThrow { LottoGenerator().generateLotto() }
+}
+
+@ValueSource(doubles = [0.051, 0.052, 0.053, 0.054])
+fun `소수점 아래 2자리로 반올림한다`(rate: Double) {
+    val earningRate = EarningRate(rate)
+    assertThat(earningRate.rate).isEqualTo(0.05)
+}
+```
+
+리뷰어: "이 테스트 코드는 함수명에 맞는 테스트 코드를 만들고 수행 중인 게 맞을까요?" + "소수점 아래 2자리로 반올림한다. 이것은 어떠한 것을 확인하기 위한 테스트인가요?" + "테스트 코드 함수명을 짤 때 `given` `when` `then` 형식으로 구현을 해 보면서…" — 테스트명은 *의도*, 본문은 *검증 대상*과 일치해야.
+
+### 11. `OutputView`가 손익 분기 직접 판단
+
+```kotlin
+fun printLottoEarningRate(earningRate: EarningRate) {
+    val gainLossText = if (earningRate.rate > 1) "이득이라는"
+        else (if (earningRate.rate == 1.0) "본전이라는" else "손해라는")
+    println("총 수익률은 ${earningRate.rate}입니다.. $gainLossText.")
+}
+```
+
+리뷰어: "View의 관점에서는 지금 1보다 큰지 작은지 같은지를 비교하기 보다는 rate에 따른 `상태`를 만들고 그 상태에 따라 Text가 변경이 되는 건 어떨까요?" — *손익 상태*는 도메인이 판별, View는 상태→텍스트만.
+
+## 리뷰어 의견 요지
+
+1. **자료구조가 invariant를 표현** — `Set<LottoNumber>`이면 중복 불가가 *타입에 새겨짐*.
+2. **비즈니스 정책 vs 도메인 규칙** — 변경 빈도가 다른 상수는 같은 객체에 두면 안 됨. 가격은 정책, 6개·1~45는 규칙.
+3. **검증을 *일급 객체 통과*로 압축** — 한 번 검증된 객체는 다시 검증하지 않음.
+4. **View는 *형식 변환 + 출력*만** — 도메인 객체 생성은 Controller.
+5. **함수형 어휘로 누적 패턴 압축** — `groupingBy {. }.eachCount()`.
+6. **Generator의 필요성 = *Lotto 외부에서 생성 정책을 갖는가*** — 그렇지 않으면 `Lotto.companion`이 충분.
+7. **테스트명/본문/검증 대상 일치** — given-when-then으로 명시.
+8. **View 분기는 *상태*로 표현** — 1보다 큰지 작은지 같은지는 *비즈니스 판정*.
+
+- **대표 인용:**
+  > 로또의 가격은 1000원이라는 내용은 비즈니스적인 내용으로 생각할 수도 있지 않을까요?
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/constants/LottoConstants.kt`
+
+  > `LottoNumber`를 사용하는 `Lotto`가 수십만 개 생겼다고 했을 때 `LottoNumber`도 수십만 개가 생길 텐데요. … 한 번 찾아보면 어떨까요?
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/value/LottoNumber.kt`
+
+  > 누군가 `Lotto` Class만 봤을 때 `LottoGenerator`의 유무를 알 수 있을까요? 그냥 `Lotto` 클래스를 그냥 넣어서 만들어 버릴 수도 있을 거 같아요.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/service/LottoGenerator.kt`
+
+  > View의 관점에서는 지금 1보다 큰지 작은지 같은지를 비교하기 보다는 rate에 따른 `상태`를 만들고 그 상태에 따라 Text가 변경이 되는 건 어떨까요?
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/view/OutputView.kt`
+
+## 얻은 교훈
+
+- **자료구조 선택 = invariant 표현**. `List<LottoNumber>`에서 중복 검증을 직접 하지 말고 `Set<LottoNumber>`이면 타입이 보장.
+- **상수의 *변경 빈도*가 다르면 같은 객체에 두지 말 것**. 정책(가격)과 규칙(개수·범위)을 분리하면 변경 영향 범위가 명확.
+- **일급 객체를 *받았다는 것* = 검증 완료**. 받은 쪽에서 다시 검증하면 일급 객체 도입 의미 소실.
+- **View는 *형식 변환 + 출력*만, 도메인 생성은 Controller**. View가 도메인을 만들면 *모델/뷰 책임 경계*가 모호.
+- **누적 패턴은 함수형 어휘로 압축 가능**. `MutableMap + forEach + ?:plus(1)`은 `groupingBy{}.eachCount()`로.
+- **Generator 분리의 *이점*은 *Lotto 외부에서 생성 전략이 필요할 때***. 단일 전략이면 `Lotto.companion`이 응집도 더 높음.
+- **테스트명 = 의도, 본문 = 그 의도의 직접 검증**. 함수명 `소수점 아래 2자리로 반올림한다`는 *주어가 누락*. `수익률은 소수점 3번째 자리에서 반올림된다`로.
+- **View 분기는 *상태*로 표현 가능할 때 그렇게 하라**. `if (rate > 1)`은 *비즈니스 판정*; `enum class ProfitState`로 도메인이 결정, View는 매핑만.
+- **객체 지향 생활 체조 원칙 *한 줄에 점 하나*** — 여러 의도가 한 체이닝에 섞이면 메서드명 부여로 의도 표현.

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

@@ -0,0 +1,132 @@
+# PR #130 — [로또 2단계] 메다 미션
+
+- **Reviewee:** [@medAndro](https://github.com/medAndro)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/130
+- **단계:** 2단계
+- **리뷰어:** @lee-ji-hoon
+- **라인 코멘트:** 66
+
+## 잘한 점 (설계 관점)
+
+- **`GainLoss`, `Rank` enum 분리** — 이득/손실 구분.
+- **`EarningInfo` 도메인** — 수익 정보 분리.
+- **`RandomLottoNumbersGenerator`** — 인터페이스 분리.
+
+## 못한 점 (설계 관점)
+
+### 1. enum의 `enums/` god-folder
+
+```
+lotto/
+  enums/
+    GainLoss.kt
+    Rank.kt
+```
+
+> 이번엔 패키지도 신경을 써볼까요? `enums` 안에 `GainLoss` `Rank` 두 가지가 존재하는데 enums라는 패키지 하나로 관리를 한다면 이 패키지는 Constants object 처럼 무진장 많아 질거 같아요. 그래서 제가 추천하는 방법은 이 enum의 역할에 대해서 신경을 써서 패키징을 해보면 좋을거 같아요. 만약 이 enum이 domain 영역이라면 도메인 패키지로.
+
+→ 패키지명 = *기술 분류* (enums, util) ≠ *도메인 분류* (lotto.domain).
+
+### 2. `value/` 패키지 — 무슨 의미?
+
+```
+lotto/
+  domain/
+    value/
+      EarningInfo.kt
+```
+
+> value라는 패키지는 무엇을 의미하는 패키지일까요?
+
+→ value object를 위한 패키지라면 *도메인 의미*가 약함. domain 평탄화 권장.
+
+### 3. `EarningInfo` 가 UI 텍스트 보유
+
+```kotlin
+class EarningInfo(.) {
+    val gainLossDescription: String = when (.) {
+        Gain -> "이득"
+        Loss -> "이라는"
+    }
+}
+```
+
+> EarningInfo는 domain model인데 "이득", "이라는" 같은 View에 표시될 Text를 알 필요가 있을까요?
+
+→ 도메인은 *판정*만, *표현 문자열*은 OutputView.
+
+### 4. `GainLoss` 생성 위치 — 호출자 의존
+
+```kotlin
+class EarningInfo(.) {
+    val gainLoss: GainLoss = GainLoss.from(rate)  // ⚠ EarningInfo가 만듦
+}
+```
+
+→ GainLoss의 역할 정의가 모호. enum이 *판정만 하는* 것인지, *표현까지 가진* 것인지 결정 필요.
+
+### 5. 테스트에 외부 API 사용
+
+```kotlin
+@Test
+fun `랜덤 로또 번호 생성`() {
+    val numbers = RandomLottoNumbersGenerator().generate()
+    assertThat(numbers.sortedBy { it.value }).isEqualTo(.)
+}
+```
+
+> 이 테스트에서 `sortedBy` 같은 Collection API를 사용을 해야했을까요? `sortedBy` 같은 외부 API를 써야만 하는 상황을 테스트를 해야 하는 것일까?에 대해서 고민을 해보면 좋습니다.
+
+→ sortedBy를 테스트 코드에 넣는 것은 *프로덕션 코드가 정렬하지 않음을 시사*. 정렬이 도메인 요구라면 도메인이 정렬된 상태로 반환.
+
+### 6. 테스트 함수명에 "예외가 발생한다"
+
+```kotlin
+@Test fun `잘못된 입력 시 예외가 발생을 한다`() {. }
+```
+
+> 테스트 함수명에 `예외가 발생을 한다.` 라는 것을 지금 꼭 표현을 해야 할까요? 예외를 발생하지 않고 상태를 반환한다던지 하게 되면 함수명 + 내부 구현까지 전부 바뀌게 될 것입니다.
+
+→ 함수명은 *시나리오*만, *구현 방식*(예외)은 본문에. 구현 변경 시 함수명도 안 바뀜.
+
+### 7. 반자동 로또 확장 시 대응?
+
+```kotlin
+class LottoMachine {
+    fun generate(manualCount: Int): Lottos =.
+}
+```
+
+> 나중에 만약 반자동 로또가 나오게 된다면 이 함수는 이제 반자동 로또 넘버까지 받게 될텐데요
+
+→ 확장성 압박 시뮬레이션. 수동/자동/반자동을 *Strategy*로 표현하면 함수 시그니처 안 바뀜.
+
+## 리뷰어 의견 요지
+
+리뷰어 @lee-ji-hoon의 가르침:
+
+1. **패키지명 = 도메인 분류** — `enums/`, `util/`, `value/`는 기술 분류. lotto 도메인을 표현하는 패키지로.
+
+2. **enum 데이터의 UI 누수** — `GainLoss`에 "이득"/"이라는" 같은 표시 문자.
+
+3. **테스트가 *프로덕션의 약점*을 드러냄** — sortedBy를 테스트에 쓴다 = 프로덕션이 정렬 안 함.
+
+4. **테스트 함수명 = 시나리오 + 결과 (구현 무관)**.
+
+5. **확장 시나리오 압박** — 반자동 로또 시 함수 시그니처 견디는가?
+
+- **대표 인용:**
+  > 이번엔 패키지도 신경을 써볼까요? `enums` 안에 `GainLoss` `Rank` 두 가지가 존재하는데 enums라는 패키지 하나로 관리를 한다면 이 패키지는 Constants object 처럼 무진장 많아 질거 같아요.
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/enums/GainLoss.kt`
+
+  > 이 테스트에서 `sortedBy` 같은 Collection API를 사용을 해야했을까요? `sortedBy` 같은 외부 API를 써야만 하는 상황을 테스트를 해야 하는 것일까?에 대해서 고민을 해보면 좋습니다.
+  >
+  > — @lee-ji-hoon on `src/test/kotlin/lotto/service/RandomLottoNumbersGeneratorTest.kt`
+
+## 얻은 교훈
+
+- **패키지명 = 도메인 어휘**. `enums/`, `util/`, `value/`는 *기술 분류*로 god-folder가 됨. 같은 enum도 *Rank*는 lotto.domain, *AnimalKind*는 zoo.domain.
+- **테스트가 프로덕션 약점 폭로**. 테스트에서 정렬/필터/조작이 필요하면 프로덕션이 *완성된 형태*로 안 주고 있는 신호.
+- **테스트 함수명에 구현 방식 (예외) 박지 말 것**. "잘못된 입력에 대한 처리"가 시나리오, 처리 방식 (예외 vs 빈 결과 반환)은 본문.
+- **확장 시나리오 압박 = 인터페이스 도입 시점**. 수동/자동/반자동을 함수 인자로 받으면 추가마다 시그니처 변경. Strategy로 *변경 없이 확장*.

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

@@ -0,0 +1,66 @@
+# PR #110 — [로또 1단계] 다이스 미션
+
+- **Reviewee:** [@moondev03](https://github.com/moondev03)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/110
+- **단계:** 1단계
+- **리뷰어:** @krrong
+- **라인 코멘트:** 50
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto`, `LottoNumber`, `LottoNumbers`, `WinningNumbers`, `LottoRank` 분리**.
+- **README 커밋 단위 일치** — 리뷰 편의성 ↑.
+
+## 못한 점 (설계 관점)
+
+### 1. 입력 형식 검증 미흡 — `1, 2, 3, 4, 5, 6` (공백) 처리
+
+```kotlin
+fun parseWinning(input: String): List<Int> {
+    return input.split(",").map { it.toInt() }  // ⚠ 공백 미처리
+}
+```
+
+리뷰어:
+
+> 게임을 실행해보면서 당첨 번호를 `1, 2, 3, 4, 5, 6` 처럼 입력했더니 예외가 발생하네요. 메시지로 `숫자만 입력해주세요` 라고 나와서 어떻게 입력해야 하는가를 고민하느라 애를 먹었네요. 이러한 경우도 처리해주면 좋겠어요!
+
+→ `.split(",").map { it.trim().toInt() }`. UX 친화.
+
+### 2. `LottoRank`에 `matchBonus` 필드 — racingcar/lotto 반복 패턴
+
+> 그런데 `LottoRank`가 matchBonus도 들고있어야 할까요?
+
+→ matchBonus = *판별 입력*이지 *Rank의 영구 속성*이 아님.
+
+### 3. `Lotto`와 `WinningNumbers` 거의 동일 (중복)
+
+```kotlin
+class Lotto(val numbers: LottoNumbers) {. }
+class WinningNumbers(val numbers: LottoNumbers) {. }
+```
+
+> `WinningNumbers`와 클래스명을 제외하고 완전히 일치하네요. `Lotto`의 역할과 `WinningNumbers`의 역할은 각각 무엇인가요?
+
+→ 둘 다 LottoNumbers wrapping이면 *역할 분리 의도가 무엇인지* 명확히. 같으면 합치거나 *조합*.
+
+### 4. `LottoNumbers` 상속 — 검증 중복 회피 시도
+
+학생:
+
+> 현재 Lotto와 WinningNumbers에서 중복된 LottoNumber 검증 로직을 각각 수행하도록 구현했습니다. 이를 위해 LottoNumbers 클래스를 생성하고, 해당 클래스를 상속받아 검증이 이루어지도록 했습니다.
+
+→ 상속보다 *조합*이 일반적. `Lotto(val numbers: LottoNumbers)`.
+
+### 5. `LottoNumber.Companion` private — 이유?
+
+> companion object를 private으로 만든 이유가 있나요?
+
+→ private companion = 외부에서 LottoNumber.of() 같은 팩토리 호출 불가. 의도였는지 실수였는지.
+
+## 얻은 교훈
+
+- **UX 친화 입력 처리** — `1,2,3,4,5,6` vs `1, 2, 3, 4, 5, 6` 둘 다 받기. trim()으로.
+- **상속 vs 조합** — 코드 중복 회피로 상속 도입은 위험. 보통 조합이 더 안전.
+- **두 클래스가 거의 같다 = 합칠 후보**. 역할이 다르면 *분명한 메서드 차이*가 있어야.
+- **`private companion object`** — 팩토리 메서드 노출 차단. 의도면 OK, 실수면 수정.