oh-my-oop 0.2.0

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

@@ -0,0 +1,115 @@
+# PR #71 — [로또 1단계] 채채
+
+- **Reviewee:** [@chaehyuns](https://github.com/chaehyuns)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/71
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **`fun interface NumberGenerator`** — 테스트 가능 구조.
+- **`PurchaseAmount`의 한정자 상수 분리** — 도메인 객체 응집.
+- **자가 의문 PR에 풍부히 명시** — *일급 컬렉션의 비용*, *class vs object*, *WinningNumber 분리* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoNumberGenerator`의 랜덤 내장
+
+```kotlin
+class LottoNumberGenerator : NumberGenerator {
+    override fun generate(): LottoNumbers = LottoNumbers.lottoNumbersOf(*(LOTTO_NUMBER_RANGE).shuffled().take(LOTTO_SIZE).sorted().toIntArray())
+}
+```
+
+리뷰어: "랜덤의 요소가 변경되면 비즈니스 로직도 변경되어야 할까요? 로또뿐 아니라 랜덤 요소가 변경되어도 *랜덤 요소를 외부로부터 주입받아* LottoNumberGenerator 로직을 재사용 가능하게끔 해볼까요?"
+
+### 2. `LottoNumbers` — 일급 컬렉션 wrapper만, 행위 부재
+
+```kotlin
+data class LottoNumbers(val numbers: List<LottoNumber>) {
+    init { require(numbers.size == LOTTO_SIZE) {. }; require(numbers.distinctBy { it.number }.size == LOTTO_SIZE) }
+}
+```
+
+리뷰어: "LottoNumbers 객체가 이미 원시값을 포장한 값을 갖고, *검증 외에는 하는 일이 없네요*. 이 객체에서 할 수 있는 일을 가져오거나 혹은 *Lotto 내에서 private 하게 관리*될 수 있도록 하는 건 어떨까요?" + "중복된 번호에 대한 검증이 필요하다면 *자료구조*를 사용해 보는 건 어떨까요? *2인승 자동차* 비유" — 검증만 + 자료구조도 List → Set 추천.
+
+### 3. `vararg numbers: Int` 팩토리
+
+```kotlin
+fun lottoNumbersOf(vararg numbers: Int): LottoNumbers = LottoNumbers(numbers.map { LottoNumber(it) }.toList())
+```
+
+리뷰어: "numbers를 매번 `vararg`를 이용한 이유가 있을까요? `List<Int>` 형태로 받으면 toList() 같은 converter가 없어도 될 것 같아요." 학생: "test 코드를 작성하면서 가변인자로 넣기 위해 하다 보니 List<Int> 형태로 넣을 생각을 못했던 거 같습니다!"
+
+### 4. Controller가 `SPLIT_DELIMITER` 처리
+
+```kotlin
+val winningNumbers = Lotto(LottoNumbers(inputView.readWinningNumbers().split(SPLIT_DELIMITER).map { LottoNumber(it.toInt()) }))
+```
+
+리뷰어: "`SPLIT_DELIMITER`에 대한 관심은 Controller에서 갖고 있어야 할까요?" + "inputView로부터 이미 split된 값을 받기는 어려울까요?" — View 책임.
+
+### 5. `OutputView`가 `lottos.lottos` 깊게 접근
+
+```kotlin
+fun printLottoNumbers(lottos: Lottos) {
+    lottos.lottos.forEach { lotto: Lotto ->
+        val resultLotto = lotto.lottoNumbers.numbers.joinToString(.)
+    }
+}
+```
+
+리뷰어: "lottos 내부의 MutableList라는 수정 가능한 타입의 정보에 접근하고 있는데요. 단순 원시값 포장만 하기보다 *일급 컬렉션 활용*하여 원하는 데이터를 요청하고 View에서 할 일을 진행해 보도록 수정해 볼까요?" — *Tell, Don't Ask*.
+
+### 6. `PurchaseAmount`의 상수 외부 주입 부재
+
+리뷰어: "현재는 로또 가격이 1000으로 고정되어 있어서 문제가 없지만 로또 가격이 인상되었다면, `validateNumberRange`를 검증하는 *비즈니스 로직 내부 코드도 변경*되어야 하고 테스트 코드도 변경되어야 합니다."
+
+### 7. `Pair<Lotto, LottoNumber>` 반환
+
+```kotlin
+private fun generateWinningNumbers(): Pair<Lotto, LottoNumber> {. }
+```
+
+리뷰어: "지금은 Pair이기에 코드를 작성한 개발자가 pair.first, pair.second가 어떤 값을 가져오는지 알 수 있을 겁니다. 하지만 다른 개발자가 유지보수를 해야 한다면, Pair 값을 가져다 쓸 때 *어떤 값인지 알려면 여기까지 들어와서 파악*을 해야겠죠?" — 영구 사용은 *data class*.
+
+### 8. `class LottoNumberGenerator` vs `object`
+
+리뷰어: "해당 `LottoNumberGenerator`는 object로 활용이 가능할까요? 채채님의 class, object를 나누는 기준이 궁금합니다." — *상태 없음*이면 `object`.
+
+### 9. 일급 컬렉션 *비용* — 학생 자가 의문
+
+학생: "'일급 컬렉션을 사용하고 원시값을 포장하라' 라는 요구 사항을 지키기 위해 LottoNumber, LottoNumbers, Lotto, Lottos 등 여러 class를 생성. joinToString 등 여러 함수들을 사용하기 위해 코드의 *복잡도가 굉장히 증가*. 어디까지 캡슐화를 해야 하는지, 이것이 진정으로 도움이 되는지 저는 느끼지 못한 거 같습니다." 리뷰어: "일급 컬렉션을 사용하는 것이 *무조건적으로 장점만 존재*하는 게 아닙니다. 그에 따라 값을 가져오거나, 개별 클래스로 나누면서 *추가적인 구현이 필요*해지니까요. 하지만, *각자의 비즈니스 로직을 분리*하면서 캡슐화를 할 수 있어…"
+
+## 리뷰어 의견 요지
+
+- **랜덤 외부 주입** = 테스트 가능 구조.
+- **일급 컬렉션은 *행위*가 있어야** — 검증만이면 *Lotto 내부 private*.
+- **`Set`/자료구조로 *중복 불가* 표현**.
+- **View 형식(`SPLIT_DELIMITER`)은 View 책임**.
+- **`Pair`보다 data class** — 영구 사용 시.
+- **상수 외부 주입** — 가격 변경 유연.
+- **일급 컬렉션은 *트레이드오프*** — 비용 vs 캡슐화 가치.
+
+- **대표 인용:**
+  > LottoNumbers 객체가 이미 원시값을 포장한 값을 갖고, *검증 외에는 하는 일이 없네요*.
+  > — @KwonDae on `src/main/kotlin/model/LottoNumbers.kt`
+
+  > `SPLIT_DELIMITER`에 대한 관심은 Controller에서 갖고 있어야 할까요?
+  > — @KwonDae on `src/main/kotlin/controller/LottoController.kt`
+
+  > 다른 개발자가 유지보수를 해야 한다면, Pair 값을 가져다 쓸 때 어떤 값인지 알려면 여기까지 들어와서 파악을 해야겠죠?
+  > — @KwonDae on `src/main/kotlin/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **랜덤 *외부 주입*** = 테스트 가능 구조.
+- **일급 컬렉션의 *정당화*는 행위** — 검증만이면 *Lotto 내부 private*.
+- ***자료구조 선택*이 invariant 표현** — `Set<LottoNumber>`로 중복 불가 명시.
+- **View 책임 = 입력 형식 변환** — `","` split은 View가, 도메인은 *완성된 데이터*.
+- **`Tell, Don't Ask` 적용 시 OutputView가 깊은 접근 회피**.
+- **상수 외부 주입** — 도메인 정책 변경에 유연.
+- **`Pair`는 일회용**, 영구는 *data class* + 의미 있는 필드명.
+- **class vs object = 상태 유무** — *상태 없음*이면 object.
+- **일급 컬렉션은 *비용*과 *가치*의 trade-off** — 무조건적인 적용 X.

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

@@ -0,0 +1,107 @@
+# PR #97 — [로또 2단계] 채채
+
+- **Reviewee:** [@chaehyuns](https://github.com/chaehyuns)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/97
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber.from()` Flyweight** — 1단계 리뷰 반영.
+- **`Lottos`/`LottoStore`/`WinningPrizeCalculator`** 분리 시도.
+- **`NumberGenerator` 인터페이스 + 테스트용 Fake** — 랜덤 격리.
+- **자가 의문 PR에 풍부히 명시** — *WinningLotto 책임 부재*, *List<List<String>> vs List<Lotto>*, *class vs object* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. `WinningLotto`가 *검증만* — 행위 부재
+
+```kotlin
+class WinningLotto(val winningNumbers: Lotto, val bonusNumber: LottoNumber) {
+    init { require(!winningNumbers.getMatchBonus(bonusNumber)) }
+}
+```
+
+학생: "WinningLotto를 생성하여서 winningNumbers와 bonusNumber를 저장. 하지만 객체를 만들고 나니 이 객체는 *검증만* 하는 역할만 존재하고 다른 역할은 존재하지 않음." 리뷰어: "Controller 입장에서 winningLotto에 대한 정보, profitAmount, profitRate에 대한 관심이 필요할까요? Controller는 단지 *명령만* 내릴 뿐입니다. WinningLotto가 스스로 판단하여 *당첨번호 갯수, 당첨금, 수익률* 같은 정보들을 갖고 있다면 return되는 WinningLotto만을 가지고 활용할 수 있겠네요." — *Tell, Don't Ask* 강조.
+
+### 2. `LottoStore.generateManualLottos(List<List<String>>)` — 이중 컬렉션
+
+```kotlin
+fun generateManualLottos(manualLottoNumbers: List<List<String>>) {
+    manualLottoNumbers.forEach { lottoNumbers ->
+        val lotto = Lotto.lottoNumbersOf(lottoNumbers)
+        lottos.add(lotto)
+    }
+}
+```
+
+학생 자가 의문: "step1 리뷰를 바탕으로 ',' split을 view에서 하는 게 맞다는 판단. 그렇기에 List<List<String>>을 사용해서 [1,2,3,4,5,6],[1,2,3,4,5,6] 이런 식으로 받아올 수밖에 없는데." 리뷰어: "List<List<String>>을 보면 동료 개발자가 처음 이 코드를 보았을 때 이해하기 쉬울까요? 또한, LottoStore에서 Collection을 정제하는 게 좋은 걸까요? InputView로부터 입력받을 때 지금 채채가 만들어 놓은 Lotto를 활용하여, *List<Lotto>*를 받도록 하는 건 어떨까요?"
+
+### 3. `Lottos`의 책임이 `WinningLotto`에 가깝지 않은가
+
+```kotlin
+class Lottos(val lottos: MutableList<Lotto> = mutableListOf()) {
+    fun winningResult(winningLotto: WinningLotto): Map<WinningRank, Int> {. }
+}
+```
+
+리뷰어: "`fun winningResult` 함수도 WinningLotto에서 수행할 수 있을까요? 그럼 Lottos의 클래스가 필요할까요? 사용자가 발행한 로또에 대한 정보(List<Lotto>), 구매 금액 같은 *여러 곳에서 사용할 공통 도메인 모델*을 의미 있게 만들어 보는 건 어떨까요? *hint. 현실에서도 로또 티켓 한 장 안에 어떤 정보들이 담겨 있을까요?*"
+
+### 4. `LottoStore.lottos` 외부 노출
+
+```kotlin
+class LottoStore(.) {
+    var lottos = Lottos()
+        private set
+}
+```
+
+`private set`이지만 *getter*가 외부 노출. Controller가 `lottoStore.lottos`를 직접 사용. → *Tell, Don't Ask* 위반.
+
+### 5. `WinningRank` 분기 + DEFAULT_COUNT
+
+```kotlin
+WinningRank.entries.forEach { rank ->
+    if (rank != WinningRank.NONE) {
+        outputView.printRankStatistics(rank, rankCounts[rank] ?: DEFAULT_COUNT)
+    }
+}
+```
+
+리뷰어 첫 코멘트의 후속: "WinningLotto가 *수익률·통계* 메서드를 가지면 Controller에서 *NONE 제외 + DEFAULT_COUNT 분기*가 사라짐."
+
+### 6. `class LottoNumberGenerator` vs `object` — 학생 자가 의문
+
+학생: "LottoNumberGenerator는 Test 코드에서 TestNumberGenerator을 만들어서 랜덤 값을 제어하기 위한 수단으로 주생성자로 선언해서 관리하고 싶어서 class로 구현." 리뷰어: "class와 object 차이는 *인스턴스화를 통해 객체를 생성, Singleton instance로 생성하는 관점*에 있습니다. 인스턴스화를 통한 객체를 생성하게 되면 *생성하는 객체마다 다른 state*. 현재는 LottoNumberGenerator는 인스턴스화를 통한 각 객체마다의 state가 다를까요? fun generate를 통해 제어." — *상태 유무*가 1차 기준.
+
+### 7. `.gitkeep` 잔존
+
+리뷰어: "이 파일은 이제 없어도 될 것 같네요!" — 폴더 구조 확정 후 정리.
+
+## 리뷰어 의견 요지
+
+- **Tell, Don't Ask** — Controller가 *winningLotto의 정보*에 관심 가지면 잘못된 위임.
+- **`Lottos` vs `WinningLotto`** — 매칭/통계는 *WinningLotto*가 자연.
+- **이중 컬렉션 회피** — View가 `List<Lotto>`로 변환 후 도메인에 전달.
+- **`Tell, Don't Ask` 적용 후 Controller가 분기 사라짐**.
+- **class vs object = *state 유무***.
+
+- **대표 인용:**
+  > Controller 입장에서 winningLotto에 대한 정보, profitAmount, profitRate에 대한 관심이 필요할까요? Controller는 단지 명령만 내릴 뿐입니다.
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 사실 지금은 검증만 하고 있기에 단순 wrapping class에 불과합니다. 하지만 WinningLotto에서 과연 할 수 있는 게 정말 없을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/model/WinningLotto.kt`
+
+  > InputView로부터 입력받을 때 지금 채채가 만들어 놓은 Lotto를 활용하여, *List<Lotto>*를 받도록 하는 건 어떨까요?
+  > — @KwonDae on `src/main/kotlin/lotto/model/LottoStore.kt`
+
+## 얻은 교훈
+
+- **검증만 하는 wrapper는 객체가 아님** — `WinningLotto`가 *발행, 매칭, 통계*까지 갖고 가면 진짜 객체.
+- **Tell, Don't Ask 적용 후 Controller는 *명령만***. 매번 *정보 조회 후 분기*는 책임이 잘못된 신호.
+- **이중 컬렉션은 의도 모호** — View에서 `List<Lotto>`까지 변환 후 도메인에 전달.
+- **공통 도메인 모델 ≠ 컬렉션 wrapping** — *Ticket*에 *발행 정보 + 구매 금액*까지 들고 가면 *여러 곳에서 사용할 공통*이 됨.
+- **class vs object = 상태 유무**. *상태 없음*이면 `object`. *각 인스턴스마다 state 다름*이면 `class`.
+- **`.gitkeep`은 *폴더 비어 있을 때*만 의미** — 채워졌으면 제거.

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

@@ -0,0 +1,51 @@
+# PR #124 — [로또 1단계] 페토 미션
+
+- **Reviewee:** [@chanho0908](https://github.com/chanho0908)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/124
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 45
+
+## 잘한 점
+
+- **PR 본문에 자가 의문** — View → Domain 의존 의문.
+
+## 못한 점 + 핵심 지적
+
+### 1. View → Domain 의존 의문
+
+학생:
+
+> 이럼에도 불구하고 View가 domain을 직접 의존해도 된다는 근거가 (정말! 순수한 궁금증!) 조심스래 궁금합니다
+
+리뷰어:
+
+> 단순하게 도메인을 출력하는 것이 UI의 역할이기 때문이에요. 도메인 없이 그냥 출력만 한다면 뭘 출력할건데? 라는 생각을 할 수 있겠죠.
+
+→ Domain 모름 → 출력할 게 없음. View → Domain 의존은 *자연*.
+
+### 2. `PurchasePrice`에 LOTTO_PRICE 1000원 박힘
+
+```kotlin
+class PurchasePrice(val amount: Int) {
+    fun ticketCount(): Int = amount / 1000  // ⚠ 1000원이 여기?
+}
+```
+
+> 로또 한장의 가격이 1,000원이라는 것을 이 곳에서 결정하는게 적절할까? 라는 생각이 드네요. A 상점에서는 1,000원 B 상점에서는 2,000원에 팔아야 한다면.? 그렇다면 로또 한장의 가격은 누구의 책임이라고 봐야 할지 애매하군요!
+
+→ Lotto 자체 또는 *상점*의 책임이 더 자연. 구매 가격은 *그 자체*만.
+
+### 3. `assertThrows { }` 미사용
+
+```kotlin
+try { PurchasePrice(-1) } catch (e:.) {. }
+```
+
+→ `assertThrows<IllegalArgumentException> { PurchasePrice(-1) }`.
+
+## 얻은 교훈
+
+- **View → Domain 의존은 OK** — Domain 없이 출력할 게 없음. *Domain → View*만 금지.
+- **로또 한장 가격의 책임자 의문** — 누가 가격 정책 소유? 미션에선 단일이지만 미래 가변성.
+- **`assertThrows<T> { }`** = 코틀린 idiom.

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

@@ -0,0 +1,149 @@
+# PR #129 — [2단계 - 로또] 라이언
+
+- **Reviewee:** [@chanho0908](https://github.com/chanho0908)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/129
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 39
+
+## 잘한 점 (설계 관점)
+
+- **`fun interface LottoMachine { fun generate(): Lotto }`** — 단일 추상 메서드를 SAM으로 표현, 람다 주입 가능.
+- **`PassivityLottoAmount`/`ManualLottoAmount` `value class` + `private constructor`** — 원시값 포장 + 검증 강제.
+- **`LottoOrderRequest`(주문서)로 입력을 한 객체에 묶음** — 리뷰어 제안 수용해서 *수동/자동 발급 흐름이 Controller에 섞인 문제*를 해소 시도.
+- **Rank의 `requiresBonusMatch` 분기 도입** — `Rank.SECOND`를 enum 사용처에서 하드코딩하지 않음.
+- **`Lotto.contains(bonusNumber)`로 의도 표현** — `value in list.map { it.value }` 같은 변환을 제거.
+
+## 못한 점 (설계 관점)
+
+### 1. `value class PassivityLottoAmount`가 `PurchasePrice`까지 알아야 함
+
+```kotlin
+value class PassivityLottoAmount private constructor(val value: Int) {
+    companion object {
+        fun create(value: Int, money: PurchasePrice): PassivityLottoAmount {
+            val purchasableAmount = money.getPurchasableLottoCount()
+            require(value <= purchasableAmount) { INVALID_PASSIVITY_LOTTO_SIZE }
+            return PassivityLottoAmount(value)
+        }
+    }
+}
+```
+
+리뷰어: "개수를 고려할 거면 수동, 자동 로또 개수를 모두 관리하는 객체를 만드는 게 맞지 않을까요? 수동은 클래스로 만들고 자동은 따로 관리하는 이유가 궁금합니다." 추가로: "수동 로또는 몇 장을 살 건지만 관심사고, 실제로 살 수 있는지 못 사는지는 Price 쪽에서 이미 판단하고 있으니 문제없지 않을까요?" — 검증을 *원시값 포장 객체*에 욱여넣으면서 `Money`에 다시 의존 → 관계 역전.
+
+### 2. `LottoGenerator.validateMoney(money)` — 인터페이스 분리 위반
+
+```kotlin
+interface LottoGenerator {
+    fun generate(quickPickLottoAmount: Int): List<Lotto>
+    fun validateMoney(money: PurchasePrice)  // ⚠ 테스트 fake가 안 쓰는 메서드 override
+}
+```
+
+학생도 자가 의문: "테스트 코드의 `FakeLottoNumberGenerator`에서 사용하지 않는 `validate` 함수를 오버라이드하는 현상이 발생했습니다. 이 경우 인터페이스 분리 원칙(ISP)을 위반하는 것이 아닌가?" — 리뷰어: "근본적으로 돈을 검증하기 위해서 PurchasePrice를 만든 건데 이걸 왜 다시 검증하고 있는 건가요?? 검증된 금액을 LottoGenerator로 넣으면 문제없지 않나요?"
+
+### 3. `LottoMatchResult.getWinningCount(rank)`가 미존재 키에 예외
+
+```kotlin
+class LottoMatchResult(private val winningCountByRank: Map<Rank, Int>) {
+    fun getWinningCount(rank: Rank): Int =
+        winningCountByRank[rank] ?: throw IllegalArgumentException(NOT_EXIST_RANK.format(rank))
+}
+```
+
+학생 의도: "당첨 순위가 없을 때 == 프로그램을 의도적으로 에러를 발생시킬 만큼 치명적인 상황." 리뷰어: "왜 0이 의미없는 값이라고 생각하시는지 궁금하네요. 당연히 갯수가 아무것도 없다면 0이 나올 것이 자연스럽게 느껴지지 않나요?" — 도메인 어휘에서 *0건*은 자연스러운 상태. 그것에 예외를 띄우면 호출자가 정상 흐름을 try/catch로 감싸게 됨.
+
+### 4. `LottoOrderRequest`가 생성된 `List<Lotto>`를 들고 있음
+
+```kotlin
+data class LottoOrderRequest(
+    val money: PurchasePrice,
+    val amount: PassivityLottoAmount,
+    val passiveLottoNumber: List<Lotto>,  // ⚠ 이미 만들어진 Lotto
+)
+```
+
+리뷰어: "아직 주문서라면 로또를 만들기 전일 텐데 Lotto가 생성자에 담겨 있는 게 어색하지 않을까요? 손님 입장이라면 로또 번호를 넘겨줄 텐데, 그렇지 않고 만들어진 로또를 넘겨준다?" — *주문서 vs 발행물* 구분이 흐려짐. 주문서는 *의도*만, Lotto는 *결과*.
+
+### 5. `WinningLotto.getRank(buyLotto.numbers)` — Lotto 내부 직접 접근
+
+```kotlin
+private fun getRank(buyLotto: List<LottoNumber>): Rank {
+    val lottoMatches = buyLotto.intersect(winningLottoNumbers).size
+    val isBonusMatched = buyLotto.contains(bonusNumber)
+.
+}
+```
+
+리뷰어: "Lotto가 스스로 가지고 있는 numbers에 직접 접근해서 비즈니스 로직을 처리하는 부분이 조금 아쉽습니다. 지금 Lotto 클래스가 아무런 역할이 없는 것 같아서, 메시지를 전달하는 연습을 조금만 더 해 봅시다. Lotto 객체에게 일치하는 개수는 몇 개인지 알려달라고 메시지를 전달해 보세요." — Tell, Don't Ask. `lotto.countMatches(winningNumbers)`.
+
+### 6. `sealed class LottoException` — 모든 도메인 오류를 커스텀 sealed로
+
+```kotlin
+sealed class LottoException(override val message: String?) : Throwable(message) {
+    class InvalidLottoSize : LottoException(INVALID_LOTTO_SIZE)
+    class DuplicatedLottoSize : LottoException(DUPLICATED_LOTTO_NUMBERS)
+}
+```
+
+리뷰어: "흔히 사용하는 IllegalArgumentException, IllegalStateException 같은 예외 대비 얼마나 이점이 있는지는 잘 모르겠군요. 오류마다 전부 개별적으로 핸들링을 해야 한다면 필요한 게 맞습니다. 그런데 else 케이스도 고려해야 한다는 점도 있습니다." — Custom Exception의 비용(switch의 else, 호출자 부담)을 학생도 결국 수긍.
+
+### 7. `PurchasePrice` — 생성자가 `init`만, 함수가 다 함
+
+```kotlin
+class PurchasePrice(val value: Int, standardPrice: Int = STANDARD_AMOUNT_UNIT) {
+    init { if (value <= 0 && value < standardPrice) throw OverStandardPriceException(standardPrice) }
+    fun getPurchasableLottoCount(standardPrice: Int = STANDARD_AMOUNT_UNIT): Int = value / standardPrice
+}
+```
+
+리뷰어: "지금은 생성자가 단순 검증만 하고 아무런 기능을 하지 않는데요. 함수로 받는다면 오히려 생성자도 불필요한 게 맞습니다. 반대로 생성자로 한다면, 생성자를 활용하는 게 좋을 것 같아요." 추가: 조건도 잘못 — `value <= 0 && value < standardPrice`는 잘못된 논리(`&&` → `||`).
+
+### 8. `check` vs `if-throw` 혼동
+
+```kotlin
+check(value >= standardPrice) {. }
+check(numbers.size == this.numbers.size) { throw LottoException.DuplicatedLottoSize() }
+```
+
+리뷰어: "check 함수가 받는 파라미터가 무엇인지 살펴보셨나요? check 함수가 내부에서 무슨 일을 하고 있는지 찾아보세요." — `check` 자체가 `IllegalStateException`을 던지는 함수인데 람다 안에서 또 throw → 이중 예외.
+
+### 9. `value class` + `equals`/`hashCode` 인지 부재
+
+학생 자가 학습: "테스트 과정에서 value class는 동일성 검사를 할 수 없다는 것을 확인" — value class 도입의 트레이드오프(인라인 + 동일성 의미 변화)를 사전에 검토하지 않음.
+
+## 리뷰어 의견 요지
+
+1. **검증 책임은 *값 객체*가 갖되, 다른 값 객체에 의존하지 말 것** — `PurchasePrice`가 가능 수량을 계산하면 `ManualLottoAmount`는 그 결과를 *비교* 하는 게 아니라, *Money - manualCount = autoCount* 같이 호출자가 조합.
+2. **value class의 `value`를 풀어내지 마라** — `getPurchasableLottoCount(): Int`처럼 *원시값 반환*은 포장 의미 소실. `Count` 같은 타입으로 유지.
+3. ***주문서*는 의도, *발행물*은 결과** — 두 개념을 한 객체에 섞으면 시간차 무결성이 깨짐.
+4. **`Tell, Don't Ask`** — Lotto 자체에 `matchCount(other)`, `contains(number)`를 두고 외부는 메시지만 전달.
+5. **Custom Exception은 *분기 처리가 필요할 때*만** — 그렇지 않으면 호출자에게 `else` 처리 부담만 안김.
+6. **`check`/`require`는 Kotlin 표준 어휘** — 람다 안에 다시 throw하면 의도 충돌.
+7. **`null`을 view 내부에서 *재시도*로 흡수** — 비논리적 오류는 *재입력 흐름*, 논리적 오류는 *예외*. 두 흐름을 try-catch 한 그릇에 담지 않음.
+
+- **대표 인용:**
+  > 근본적으로 돈을 검증하기 위해서 PurchasePrice를 만든 건데 이걸 왜 다시 검증하고 있는 건가요?? 검증된 금액을 LottoGenerator로 넣으면 문제없지 않나요?
+  > — @laco-dev on `src/main/kotlin/domain/service/LottoGenerator.kt`
+
+  > Lotto가 스스로 가지고 있는 numbers에 직접 접근해서 비즈니스 로직을 처리하는 부분이 조금 아쉽습니다. … Lotto 객체에게 일치하는 개수는 몇 개인지 알려달라고 메시지를 전달해 보세요.
+  > — @laco-dev on `src/main/kotlin/domain/model/winning/WinningLotto.kt`
+
+  > 아직 주문서라면 로또를 만들기 전일 텐데 Lotto가 생성자에 담겨 있는 게 어색하지 않을까요?
+  > — @laco-dev on `src/main/kotlin/domain/model/LottoOrderRequest.kt`
+
+  > 당연히 갯수가 아무것도 없다면 0이 나올 것이 자연스럽게 느껴지지 않나요?
+  > — @laco-dev on `src/main/kotlin/domain/model/LottoMatchResult.kt`
+
+## 얻은 교훈
+
+- **값 객체의 검증은 *자기 자신만의 invariant*에 한정**. 다른 값 객체의 가능 수량까지 자기가 알면 그 두 객체가 결합. `PurchasePrice → 가능 수량`만 알고, `manualCount`는 호출자에서 빼서 `autoCount` 만든다.
+- **인터페이스에 모든 도메인 검증을 얹지 말 것**. Fake/Stub에서 빈 override가 생기면 ISP 위반의 *직접 증거*.
+- **0건은 자연스러운 도메인 상태**. 정상 경로에서 도달 가능한 상태를 예외로 만들면 호출자가 try/catch로 정상 흐름을 둘러쌈.
+- ***주문서 vs 발행물* 분리**. 의도 단계의 객체에 결과 단계의 객체를 끼우면 시간차 무결성 + 책임 혼선.
+- **`Tell, Don't Ask`는 컬렉션도 동일**. `lotto.numbers.intersect(other.numbers).size` → `lotto.matchCount(other)`. 외부는 의도만, 계산은 본인이.
+- **Custom Exception 분기의 *비용*은 `else`**. sealed로 닫아도 호출자가 모든 분기 + else를 처리해야 하면 가독성 가치가 사라짐. `IllegalArgumentException` + 의미 있는 메시지가 더 나은 경우가 많음.
+- **`check`/`require` 자체가 예외를 던진다**. 람다 인자는 *메시지 빌더*지 *던지는 곳*이 아님. 두 번 던지면 한 번은 무의미.
+- **value class는 *동일성 의미가 변한다*는 트레이드오프 동반**. 도입 전에 `==`/`===` 의도와 동작 차이를 점검.
+- **`null` + 재시도 vs `try-catch` + 재시도** — 함수 호출 흐름이 5~10단계 이상이면 `try-catch`로 둘러싸는 비용이 폭증. *비논리적 오류*는 호출 위치에서 `null`로 표현하고 재입력. 정말 *치명적인 논리적 오류*만 예외.

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

@@ -0,0 +1,117 @@
+# PR #24 — [스캇] 1단계 로또
+
+- **Reviewee:** [@chws0508](https://github.com/chws0508)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/24
+- **단계:** 1단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 21
+
+## 잘한 점 (설계 관점)
+
+- **`Rank` enum + `(countOfMatch, winningMoney)`** — 등수/상금 한 곳.
+- **`BonusNumber`/`LottoNumber` 원시값 포장**.
+- **자가 의문 PR에 풍부히 명시** — *매칭 개수의 책임* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. `check(countOfMatch, matchBonus, rank)` — 함수명 모호
+
+```kotlin
+companion object {
+    fun valueOf(countOfMatch: Int, matchBonus: Boolean): Rank? {
+        return values().find { rank -> check(countOfMatch, matchBonus, rank) }
+    }
+    private fun check(countOfMatch: Int, matchBonus: Boolean, rank: Rank): Boolean {. }
+}
+```
+
+리뷰어: "함수명만 봤을 때에는 무엇을 '체크'하는지 알기가 어렵네요. 함수가 하는 일에 대해서 좀 더 명확하게 작성해 보면 어떨까요?" 학생: "checkRankCondition으로 변경." — `check*`는 *검증 행위* 시사, 의미가 *boolean 반환의 술어*면 `is*`/`matches*`.
+
+### 2. 매직리터럴 in `check`
+
+```kotlin
+private fun check(countOfMatch: Int, matchBonus: Boolean, rank: Rank): Boolean {
+    if (countOfMatch == 5 && !matchBonus) return rank.winningMoney == 1_500_000  // ⚠ 5, 1_500_000
+    if (countOfMatch < 3) return rank.countOfMatch < 3
+.
+}
+```
+
+리뷰어: "숫자 5와 1_500_000과 같은 것은 *매직리터럴*이라고 합니다. 이 숫자들은 자세히 보시면, Enum에 정의된 값과 동일합니다. 해당 값을 가지고 있는 Enum을 활용해 보면 어떨까요?" 학생: "Enum에 있는 값을 그대로 사용하는 식으로 변경." → `Rank.THIRD.countOfMatch`, `Rank.THIRD.winningMoney`.
+
+### 3. `LottoAdministrator.getMatchOfNumber` — 매칭이 Administrator의 책임?
+
+```kotlin
+class LottoAdministrator {
+    fun getMatchOfNumber(lottoNumber: Lotto, winningNumber: Lotto): Int {. }
+    fun isMatchBonus(lottoNumber: Lotto, bonusNumber: BonusNumber): Boolean {. }
+}
+```
+
+리뷰어: "보너스 볼을 일치 여부를 확인하는 이유는, 보너스 볼로 인하여 *랭킹이 변경*되기 때문입니다. 그렇다면, LottoAdministrator 클래스보다는 *Rank 클래스에서 구하는 것이 더 적합*하지 않을까요?" — 학생 자가 의문: "매칭 개수는 Rank? Lotto?" — 학생 결론: 일치 개수는 *Lotto의 정보*에 따라 변하므로 `Lotto.count` + Rank는 *그 결과 사용*.
+
+### 4. `OutputView`의 *Rank 별 줄 별 하드코딩*
+
+```kotlin
+println(
+    "3개 일치 (5,000원) - ${if (lottoResult[Rank.FIFTH] == null) 0 else lottoResult[Rank.FIFTH]}개\n" +
+    "4개 일치 (50,000원) - ${.}\n" +
+.
+)
+```
+
+리뷰어: "만약 요구사항이 변경되어 Rank 클래스의 값이 변경되면, 이 부분도 반드시 변경이 필요합니다. Rank 클래스가 변경되더라도, *출력하는 문구들을 변경하지 않아도 되도록* 코드를 개선해 보면 어떨까요?" 학생: "`fun printLottoRankCount(rank: Rank, lottoResult: HashMap<Rank, Int>) { if (rank != Rank.MISS) println("${rank.countOfMatch}개 일치 (${rank.winningMoney}원) - ${lottoResult[rank] ?: 0} 개") }` 로 수정." — *Rank 데이터*로 자동 포맷.
+
+### 5. 랜덤 테스트가 *반드시 성공*
+
+```kotlin
+@Test
+fun `1~45의 랜덤번호 6개를 추출한다`() {
+    val actual = ShuffledNumberGenerator().generate()
+    assertThat(actual.size).isEqualTo(6)
+}
+```
+
+리뷰어: "랜덤으로 추출하는 테스트는 *반드시 성공하는 테스트*입니다. 그래서 *랜덤값을 테스트하는 것은 의미가 없습니다*. *내가 원하는 숫자로 로또를 생성*했을 때, 잘 생성이 되는지 확인해 보는 코드를 작성해 보면 어떨까요?"
+
+### 6. 테스트명 모호
+
+```kotlin
+@Test fun `갯수는 1 이상이다`() {. }
+@Test fun `당첨번호와 보너스번호는 1~45이다`() {. }  // ⚠ 실제로는 46 테스트
+```
+
+리뷰어: "어떤 갯수가 1 이상일까요?" + "함수명만 봤을 때에는 1부터 45 사이의 숫자를 테스트하는 것으로 보이지만, *실제 구현부는 45보다 큰 46을 테스트*하고 있네요. 테스트하고자 하는 것과, 함수명을 일치시켜 보면 어떨까요?"
+
+### 7. Rank 테스트 일부만
+
+리뷰어: "현재 당첨번호로 인한 등수가 여러 개가 있습니다. 요구사항에 맞게 등수가 나타나는지 *모든 등수에 대한 테스트* 코드를 작성해 보면 어떨까요?"
+
+## 리뷰어 의견 요지
+
+- **함수명 = 의도** — `check*`보다 `is*`/`matches*`.
+- **매직리터럴 = enum/상수 활용**.
+- **매칭 책임 = 데이터 소유 객체** — Administrator 같은 *별도 객체*는 응집도 낮춤.
+- **View 출력은 *Rank 데이터*로 자동 포맷** — 변경 동기화.
+- **랜덤 테스트는 *의미 없음*** — *입력 제어*로 의미 있는 검증.
+- **테스트명 = 실제 검증 대상과 일치**.
+
+- **대표 인용:**
+  > 함수명만 봤을 때에는 무엇을 '체크'하는지 알기가 어렵네요.
+  > — @BeokBeok on `src/main/kotlin/domain/Rank.kt`
+
+  > 숫자 5와 1_500_000과 같은 것은 매직리터럴이라고 합니다. 이 숫자들은 자세히 보시면, Enum에 정의된 값과 동일합니다.
+  > — @BeokBeok on `src/main/kotlin/domain/Rank.kt`
+
+  > 랜덤으로 추출하는 테스트는 반드시 성공하는 테스트입니다. 그래서 랜덤값을 테스트하는 것은 의미가 없습니다.
+  > — @BeokBeok on `src/test/kotlin/domain/LottoMachineTest.kt`
+
+## 얻은 교훈
+
+- **`check*` = 검증/예외 행위 시사**. *반환이 있으면* `is*`/`has*`/`matches*`.
+- **매직리터럴 = enum/상수 활용** — *수치가 enum 값과 일치*하면 반드시 *enum 참조*.
+- **매칭 책임은 *데이터 소유 객체*** — `Administrator` 같은 *행위 객체*에 매칭을 두면 *Lotto가 단순 데이터*가 됨.
+- **View 출력은 *Rank 데이터*로 자동 포맷** — Rank 변경 시 View 변경 X.
+- **랜덤 테스트는 *반드시 성공* 무의미** — *입력 제어*로 *기대 출력* 검증.
+- **테스트명 = 실제 검증 대상과 일치** — 함수명에 *범위* 명시하되 *실제 케이스*와 일치.
+- ***모든 등수 테스트*** — 일부만 테스트하면 *나머지 분기*는 미보장.