oh-my-oop 0.2.0

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

@@ -0,0 +1,21 @@
+# PR #101 — [로또] 벼리 2단계 미션
+
+- **Reviewee:** [@gaeun5744](https://github.com/gaeun5744)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/101
+- **단계:** 2단계
+- **리뷰어:** *(self-discussion)*
+- **라인 코멘트:** 14
+
+## 학생 자가 변경 이유
+
+> 이전에서는 제가 문자열은 따로 companion object에서 const val로 선언함으로써 한곳에 모아두었지만, 이번 pr에서는 문자열을 그대로 넣었습니다.
+
+> 기존에는 `InputView`에 모든 로직을 두었지만, 이번 pr에서는 연관된 함수들을 묶어서 `domain` 객체를 생성한 후에 Controller에 전달하는 방식으로 로직을 세.
+
+> `Ticket`이 `lottos`를 발행한다는 상황이 어색해보여서, `lottoMachine`으로 수정했습니다!!
+
+## 얻은 교훈
+
+- **상수 분리 vs 인라인 = 컨텍스트에 따라**. 1단계에서 모은 상수를 2단계에서 인라인으로 되돌리는 결정도 *왜*가 명확하면 OK.
+- **InputView 분리** — 연관 함수를 도메인 객체로 묶기.
+- **이름이 어색하면 변경** — `Ticket`보다 `LottoMachine`이 *발행* 행위 어울림.

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

@@ -0,0 +1,158 @@
+# PR #78 — [로또] 벼리 1단계 미션
+
+- **Reviewee:** [@gaeun5744](https://github.com/gaeun5744)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/78
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 38
+
+## 잘한 점 (설계 관점)
+
+- **`LottoPrize` enum에 `(matchingCount, amount)` 결합** — 등수와 상금이 한 곳.
+- **`LottoNumberGenerator` 인터페이스 + `RandomLottoNumberGenerator` 구현** — 랜덤 격리 시도.
+- **`Lotto`의 `numbers`를 `private`로 캡슐화** — 외부에서 `List<LottoNumber>` 접근 차단.
+- **`PurchaseInfo`로 구매 정보 1차 포장** — `price`/`amount`를 객체에.
+- **자가 질문 PR에 풍부히 명시** — 책임 위치, object 사용 여부 등 학생이 먼저 논점 제기.
+
+## 못한 점 (설계 관점)
+
+### 1. `ModelTest.kt` 단일 파일에 모든 모델 테스트
+
+```kotlin
+class ModelTest { /* Lotto, LottoNumber, PurchaseInfo, WinningLotto 모두 */ }
+```
+
+리뷰어: "한 테스트 파일에서 모델에 대한 테스트를 전부 진행하고 있네요. 모델이 굉장히 많아진다면 이 테스트 파일도 비대해질 것 같은데요, Model 별로 분리해주세요." — Test 클래스는 SUT당 1:1. `LottoTest`, `LottoNumberTest`, …
+
+### 2. `LottoConstants`/`StringConstants` god-folder
+
+```kotlin
+object LottoConstants {
+    const val LOTTO_SIZE = 6
+    const val LOTTO_MIN_NUMBER = 1
+    const val LOTTO_MAX_NUMBER = 45
+    const val LOTTO_PRICE = 1000
+}
+
+object StringConstants {
+    const val ERROR_MESSAGE = "[ERROR]"
+    const val INVALID_PURCHASE_PRICE = "."
+    const val INVALID_LOTTO_NUMBER = "."
+.
+}
+```
+
+리뷰어: "object로 분리되는 상수의 기준은 무엇일까요? 지금이야 규모가 작아 상수 관리가 되겠지만 규모가 큰 프로젝트라면 어느 순간 파편화가 될 가능성이 높아보여요. 위 상수들을 대체할 다른 객체 혹은 한정자를 통해 해당 파일에서 관리하도록 수정해볼까요?" — *어떤 상수든 다 들어가는* god-object는 응집도 0. 도메인별 객체의 `companion object`로 배치.
+
+### 3. `Lotto.compare(otherLotto, bonusNumber): LottoPrize` — 책임 과부하
+
+```kotlin
+fun compare(otherLotto: Lotto, bonusNumber: LottoNumber): LottoPrize {
+    val matchingCount = otherLotto.numbers.intersect(numbers).size
+    val isMatchingBonus = contains(bonusNumber)
+    return LottoPrize.getLottoPrize(matchingCount, isMatchingBonus)
+}
+```
+
+문제 1: 함수명 `compare`는 정렬 비교 시그니처. 문제 2: `Lotto`가 `LottoPrize` 결정 책임을 가짐 — 등수 판정은 *당첨 정보(당첨 번호+보너스+규칙)* 의 책임. Lotto는 *매칭 개수만* 반환해야 함.
+
+### 4. `WinningLotto`가 검증만 — 책임 부재
+
+```kotlin
+class WinningLotto(val lotto: Lotto, val bonusNumber: LottoNumber) {
+    init { require(!lotto.contains(bonusNumber)) {. } }
+}
+```
+
+리뷰어: "WinningLotto라는 일급컬렉션을 사용해주셨네요. 지금은 값을 wrapping 하는 것 외에는 다른 역할이 없어서 클래스의 존재가 잘 드러나지 않고 있어요. 예를 들어, 당첨 번호 비교, 검증 같은 로직을 여기서 수행해보는 건 어떨까요?" — 후속 리뷰에서 더 강하게: "WinningLotto에서 해당 티켓, 당첨 로또, 보너스번호 위 3개 정보만 알아도 총 당첨 갯수와 수익률 모두 하나의 도메인에서 해결이 가능할 것 같습니다."
+
+### 5. `PurchaseInfo`가 `LOTTO_PRICE`를 상수 의존
+
+```kotlin
+class PurchaseInfo(purchasePrice: String) {
+    val price: Int
+    val amount: Int
+    init {
+        require(. && purchasePrice.isMoreThanMin() && purchasePrice.divideByLottoPrice()) {. }
+        amount = price / LOTTO_PRICE
+    }
+}
+```
+
+리뷰어: "로또 가격이 인상되었다면, `isMoreThanMin`과 같은 비즈니스 로직 내부 코드도 변경되어야 하고 테스트 코드도 변경되어야 합니다." — 학생 의문: "companion object의 `LOTTO_PRICE`를 변경하지 않고 외부에서 변경해야 하는 이유가 궁금합니다!" 리뷰어 답: "추후 기획자의 요구사항에 따라 여러 종류의 복권을 판매하도록 요구사항이 주어진다면, 각 복권마다의 `PurchaseInfo`를 따로 구현해야 할까요?" — 가격은 *외부 주입*해야 다중 복권 대응.
+
+### 6. `LottoPrize.getLottoPrize`의 매직넘버 `5`
+
+```kotlin
+companion object {
+    fun getLottoPrize(matchingCount: Int, isMatchingBonus: Boolean): LottoPrize {
+        if (matchingCount == 5) {. }  // ⚠ enum 값으로 대체 가능
+    }
+}
+```
+
+학생 의문: "2등과 3등의 matchingCount가 서로 같아서 SECOND.amount 혹은 THIRD.amount 둘다 사용 가능하기에 그냥 그대로 5를 넣었습니다." 리뷰어: "이 케이스에만 들어맞기 때문에 이 값이 갖는 특별한 의미를 인지하지 못하고, 경계하지 않으면 수정사항에 정상적으로 대응하지 못할 가능성이 크겠죠. 또한, 단위 테스트가 이 문제를 발견하지 못할 수 있다는 것입니다."
+
+### 7. `retryWhileNoException`의 위치 — Controller 안
+
+```kotlin
+class LottoController {
+    private fun <T> retryWhileNoException(action: () -> T): T {
+        return try { action() } catch (e: IllegalArgumentException) {
+            println("${ERROR_MESSAGE} ${e.localizedMessage}")
+            action()
+        }
+    }
+}
+```
+
+리뷰어: "이 함수는 예외 발생시 출력을 하고 있고, 이 함수를 사용하는 함수들의 공통점은 View와 관련이 있다는 겁니다. 그러면 어디에서 관리하는게 보다 가독성이 좋을까요?" — 출력+재시도는 View 인접 책임. *함수가 어디서 *호출되는가*가 아니라 *무엇과 협력하는가*가 위치 기준.
+
+### 8. `object InputView`/`OutputView` — 메모리 vs 책임
+
+학생 결정: "InputView는 지속적으로 사용하는 클래스가 아닌, 뷰 로직에서만 사용하기 때문에 프로그램 런타임 내내 메모리를 차지하는 것은 낭비라는 생각이 들었습니다!" 리뷰어 반박: "Controller 뿐 아니라 많은 곳에서도 InputView, OutputView를 사용해야 하는 상황이라면 어떻게 생각하시나요?" — `object` 결정 기준은 *메모리*가 아니라 *상태/인스턴스화 필요성*.
+
+### 9. `WinningStatics`가 별도 클래스로 분리
+
+```kotlin
+class WinningStatics {
+    fun calculateProfitRatio(purchaseInfo: PurchaseInfo, prizeCount: Map<LottoPrize, Int>): Double {. }
+}
+```
+
+학생 변명: "calculateProfitRatio를 WinningLotto에 넣을 경우 파라미터 3개가 필요해 복잡해짐. 두 객체가 서로 의존하지 않도록 따로 만들었습니다." 리뷰어: "purchaseInfo는 어떤 역할을 하는 클래스일까요? val lottoPrice: Int 프로퍼티의 쓰임새를 한번 생각해볼까요. … 결국 *티켓 = 사용자가 구매한 로또의 정보 집합 & 총 구매 가격*. 그리고 그 티켓의 가격이 있는 Domain이 존재한다면, WinningLotto에서 해당 티켓, 당첨 로또, 보너스번호 위 3개 정보만 알아도 총 당첨 갯수와 수익률 모두 하나의 도메인에서 해결이 가능할 것 같습니다." — 책임이 흩어진 원인은 *Ticket이라는 자연스러운 객체의 부재*.
+
+## 리뷰어 의견 요지
+
+1. **상수 god-folder = 응집도 0** — 도메인별 객체 안의 `companion object`로.
+2. **`WinningLotto`는 당첨 발표의 *주체*** — 검증만 하는 wrapper는 *객체로서 존재 이유 부재*.
+3. **`Ticket` 같은 *자연스러운 객체*가 빠지면 책임이 흘러넘침** — `WinningStatics`가 *별도로* 생긴 이유는 Ticket이 없어서.
+4. **함수 위치 = *협력 대상*과의 거리** — `retryWhileNoException`이 View 출력 + View 입력과 협력하면 View 옆.
+5. **`object` 결정은 *상태/인스턴스화 필요성*** — 메모리 절약은 부차적, 의미적 기준이 우선.
+6. **매직넘버는 *케이스 안에서 우연히 같은 값*** — `SECOND.matchingCount`처럼 의미가 함께 옮겨가야 변경에 안전.
+7. **PurchaseInfo의 *로또 가격 의존성*은 외부 주입** — 확장(다중 복권) 시 핵심.
+
+- **대표 인용:**
+  > object로 분리되는 상수의 기준은 무엇일까요? … 위 상수들을 대체할 다른 객체 혹은 한정자를 통해 해당 파일에서 관리하도록 수정해볼까요?
+  > — @KwonDae on `src/main/kotlin/lotto/constants/LottoConstants.kt`
+
+  > WinningLotto라는 일급컬렉션을 사용해주셨네요. 지금은 값을 wrapping 하는 것 외에는 다른 역할이 없어서 클래스의 존재가 잘 드러나지 않고 있어요.
+  > — @KwonDae on `src/main/kotlin/lotto/model/WinningLotto.kt`
+
+  > 결국 *티켓 = 사용자가 구매한 로또의 정보 집합 & 총 구매 가격*. 그리고 그 티켓의 가격이 있는 Domain이 존재한다면, WinningLotto에서 해당 티켓, 당첨 로또, 보너스번호 위 3개 정보만 알아도 총 당첨 갯수와 수익률 모두 하나의 도메인에서 해결이 가능할 것 같습니다.
+  > — @KwonDae on `src/main/kotlin/lotto/service/WinningStatics.kt`
+
+  > 이 함수는 예외 발생시 출력을 하고 있고, 이 함수를 사용하는 함수들의 공통점은 View와 관련이 있다는 겁니다. 그러면 어디에서 관리하는 게 보다 가독성이 좋을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **상수 god-folder는 응집도 0**. `LottoConstants`, `StringConstants` 같이 *어떤 상수든 다*가 기준이면 변경 시 영향 범위가 흩어진다. 도메인별 `companion object`로 가두면 변경 영향이 한 곳에.
+- **Test 클래스는 SUT 1:1**. `ModelTest`는 god-test — 책임 분리의 *테스트* 거울. 모델별 테스트로 쪼개야 실패 메시지가 가리키는 곳이 명확.
+- **검증만 하는 wrapper는 객체가 아니다**. `WinningLotto`가 init 검증만 한다면 `data class`로 충분 — 그러나 *당첨 발표의 주체*로서 `calculatePrizeCount`, `calculateProfitRatio`를 가지면 비로소 객체.
+- **빠진 *자연스러운 도메인 객체*가 책임 분산의 원인**. `WinningStatics`가 *별도* 클래스로 떨어진 까닭은 `Ticket`이라는 *자연어 객체*가 없어서. 자연어로 이름이 떠오르는 객체부터 찾아라.
+- **함수 위치 = 협력 대상과의 거리**. `retryWhileNoException`이 *View 출력 + View 입력*과 협력하면 View 옆. *어디서 호출되는가*가 아니라 *무엇을 알아야 하는가*.
+- **`object` 결정 기준은 *상태/인스턴스화 의도*** — 메모리는 부차적. 상태가 없고 단 하나의 의미라면 `object`로 의미 단언.
+- **매직넘버는 *지금 안 들킴*이 가장 위험**. `5`가 `SECOND.matchingCount`와 같은 의미라면 그렇게 부르고, 다르면 다른 상수로. *우연한 같음*이 변경 시 폭탄.
+- **상수 의존을 외부 주입으로 끌어올리면 다중 사례 대응 가능**. `PurchaseInfo(price: Int, lottoPrice: Int)` — 복권 종류가 늘어도 같은 객체로 처리.
+- **`Tell, Don't Ask`는 비교 책임에도 적용**. `Lotto.compare(other, bonus)`로 LottoPrize까지 결정하면 Lotto가 *판정 규칙*까지 흡수. Lotto는 *매칭 개수*만, 판정은 `WinningLotto`/`LottoPrize`.

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

@@ -0,0 +1,83 @@
+# PR #107 — [로또 1단계] 조이 미션
+
+- **Reviewee:** [@gahyunkim](https://github.com/gahyunkim)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/107
+- **단계:** 1단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 53
+
+## 잘한 점 (설계 관점)
+
+- **`LottoFactory`로 생성 책임 분리**.
+- **메시지 전달 시도 — Lotto에게 메시지** 칭찬 받음.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto`가 자체 LottoNumber 범위 검증
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    init { require(numbers.all { it in 1..45 }) }  // ⚠ 로또 숫자 범위가 Lotto의 책임?
+}
+```
+
+> 로또 숫자 범위에 대한 책임은 로또일까요, 로또 숫자일까요?
+
+→ `LottoNumber` 객체로 분리하면 그 책임이 자연스럽게 옮겨감.
+
+### 2. `bonusNumber: String` — 타입 불일치
+
+```kotlin
+class WinningLotto(val lotto: Lotto, val bonusNumber: String) {. }
+```
+
+> `bonusNumber`는 왜 `String`이 됐을까요?!
+
+→ 입력 파싱이 도메인까지 흘러옴. 도메인은 *파싱된 값*.
+
+### 3. `Purchase`도 String
+
+```kotlin
+class Purchase(val amount: String) {. }
+```
+
+> 구입 금액을 `String`으로 하신 이유가 있으신가요?
+
+→ 같은 패턴. 도메인은 Int.
+
+### 4. 테스트 코드 반복 — Fake Constructor 미사용
+
+```kotlin
+val lotto1 = Lotto(listOf(1, 2, 3, 4, 5, 6))
+val lotto2 = Lotto(listOf(7, 8, 9, 10, 11, 12))
+//. 반복
+```
+
+> `Lotto(listOf(1, 2, 3, 4, 5, 6)`로 비슷한 코드가 반복되네요!ㅎㅎ 테스트 코드의 가독성을 좋게 하기 위해, 가짜 생성자를 고려해볼 수 있답니다.
+
+### 5. 두 컬렉션 교집합 함수 미활용
+
+```kotlin
+val matched = lotto.numbers.filter { it in winning.numbers }
+```
+
+> 두 컬렉션 간의 교집합을 구할 수 있는 함수가 있어요. 한번 찾아볼까요?
+
+→ `lotto.numbers intersect winning.numbers`.
+
+### 6. Factory에 private 미적용
+
+```kotlin
+class LottoFactory {
+    fun createOne(): Lotto =.  // ⚠ 내부에서만 쓰는데 public
+    val MIN = 1                    // ⚠ public 상수
+}
+```
+
+> 이 함수는 내부에서만 사용하고 있어요. `private`으로 닫는 것은 어떨까요?
+
+## 얻은 교훈
+
+- **String → Int 타입 변환은 *입력 경계*에서 끝**. 도메인이 String 받기 시작하면 *전체 도메인이 파싱 부담*.
+- **`intersect` 컬렉션 함수** — 두 컬렉션 공통 원소. lotto 매칭에 자연스러움.
+- **Factory의 내부 함수는 private** — 노출 면적 최소화.

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

@@ -0,0 +1,51 @@
+# PR #136 — [로또 2단계] 조이 미션
+
+- **Reviewee:** [@gahyunkim](https://github.com/gahyunkim)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/136
+- **단계:** 2단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 45
+
+## 잘한 점
+
+- **LottoNumber 캐싱 전략** — 칭찬.
+
+## 못한 점 + 핵심 지적
+
+### 1. 두 `amount` 검증을 Validator가 직접
+
+```kotlin
+class Validator {
+    fun validate(amount1: Int, amount2: Int) {. }  // ⚠ 원시값 검증
+}
+```
+
+> amount는 원시값 포장하지 않아도 될까요?
+
+→ `PurchaseAmount`, `ManualCount` 같은 값 객체. 외부 Validator 대신 각자 init 검증.
+
+### 2. `amount` 네이밍 — 가격 vs 장수 혼동
+
+```kotlin
+class Purchase(val amount: Int) {. }  // amount가 장수? 금액?
+```
+
+> 로또 장수를 `amount`로 네이밍하게 되면서, 이 변수는 가격이라는 의미가 담긴 이름이 더 적절하지 않을까? 생각이 듭니다!
+
+### 3. `LottoFactory`가 단순 통과
+
+```kotlin
+class LottoFactory(.) {
+    fun create(lottos: List<Lotto>): List<Lotto> = lottos  // ⚠ 그대로 반환
+}
+```
+
+> 로또들을 받아서 그대로 리턴하고 있네요
+
+→ Factory가 *생성*도 *변환*도 안 함 = 죽은 추상.
+
+## 얻은 교훈
+
+- **원시 amount 두 개 = 두 도메인 값 객체로** — Validator 외부화 회피.
+- **`amount` 모호** — 가격이면 `price`, 장수면 `count`. 도메인 어휘.
+- **죽은 추상 회피** — Factory가 통과만 하면 제거.

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

@@ -0,0 +1,171 @@
+# PR #106 — [로또 1단계] 지오 미션 제출합니다
+
+- **Reviewee:** [@giovannijunseokim](https://github.com/giovannijunseokim)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/106
+- **단계:** 1단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 75
+
+## 잘한 점 (설계 관점)
+
+- **`LottoResult` enum + `BonusMatched` 별도 enum** — boolean 대신 enum으로 3 상태 (`YES/NO/IRRELEVANT`) 명시.
+- **`LottoNumber` 값 객체 도입**.
+- **PR 본문에 자가 의문 명시** — "접근할 수 없는 부분 테스트?", "when 가독성?".
+- **에러 메시지 케이스별 상수**.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller가 mutable `lateinit var` 보유
+
+```kotlin
+class LottoController {
+    lateinit var winningLotto: WinningLotto
+    lateinit var boughtLottos: Lottos
+    
+    fun buyLottos() {. }
+    fun readWinningLotto() {. }
+    fun showResult() {. }
+}
+```
+
+> 외부에 열려있어 수정될 위험이 있겠어요. `private`로 막아주면 어떨까요?
+
+→ `lateinit var` + public = 상태가 외부에서 변경 가능 + 사용 순서 강제 어려움.
+
+### 2. Application과 Controller 분리 의미?
+
+```kotlin
+fun main() {
+    val lottoApplication = LottoApplication()
+    lottoApplication.run()
+}
+
+class LottoApplication {
+    val controller = LottoController()
+    fun run() {
+        controller.buyLottos()
+        controller.readWinningLotto()
+        controller.showResult()
+    }
+}
+```
+
+> `Application`과 `Controller`의 역할이 나눠진 이유가 있을까요?
+
+→ 둘 다 흐름 제어. 분리의 정당화가 약하면 하나로.
+
+### 3. `LottoResult` 순서에 의존
+
+```kotlin
+companion object {
+    fun of(matchCount: Int, bonusMatched: Boolean): LottoResult {
+        return values()[matchCount]  // ⚠ enum 선언 순서에 의존
+    }
+}
+```
+
+> 만약 `LottoResult` 상수들이 순서가 바뀐다면 이 코드는 어떻게 될까요?
+
+→ enum 선언 순서가 *암묵적 계약*이 되어 버림. 매칭 조건으로 명시적 검색.
+
+### 4. 최소 구입 금액 검증이 `Lottos`에
+
+```kotlin
+class Lottos(val lottos: List<Lotto>) {
+    init {
+        require(.) { "최소 구입 금액." }  // ⚠ 컬렉션이 금액 정책 검증
+    }
+}
+```
+
+> 최소 구입 금액에 대한 검증은 `Lottos`의 책임일까요?
+
+→ `PurchaseAmount`/`Money` 같은 금액 도메인의 책임.
+
+### 5. `Lottos`가 구매 장수 계산까지
+
+```kotlin
+class Lottos {
+    fun calculate(price: Int): Int =.  // ⚠ 가격으로 장수 계산
+}
+```
+
+> 가격을 받아서 계산하다보니, 이 함수에서 로또의 장수를 계산하는 역할까지 하고 있어요.
+
+→ 구매 장수 계산은 금액 도메인 (`PurchaseAmount.numberOfLottos`).
+
+### 6. `LottoNumber`를 매번 새 인스턴스로
+
+```kotlin
+val numbers = (1..45).map { LottoNumber(it) }  // ⚠ 100개 로또면 100*6 = 600개 인스턴스
+```
+
+> 만약 100개, 1000개 이상의 로또 숫자를 생성한다면 어떨까요? 인스턴스 100개, 1000개가 필요할까요?
+
+→ 1-45 범위의 LottoNumber는 *고정된 45개*. 캐싱/팩토리 메서드로 재사용.
+
+```kotlin
+class LottoNumber private constructor(val value: Int) {
+    companion object {
+        private val cache = (1..45).associateWith { LottoNumber(it) }
+        fun of(value: Int): LottoNumber = cache[value] ?: throw IllegalArgumentException(.)
+    }
+}
+```
+
+### 7. `get()` 커스텀 프로퍼티 vs 함수의 기준 모호
+
+```kotlin
+val numberOfLottos: Int get() =.  // 또는 fun numberOfLottos(): Int
+```
+
+> `get()` 커스텀 프로퍼티를 사용하는 것과, 함수를 사용하는 것, 이 두 가지는 어떨 때 각각 사용할까요?
+
+→ Kotlin 컨벤션: 상태 조회/단순 계산은 property, 부수효과/연산 비용 있는 건 함수.
+
+### 8. 학생의 자가 의문 — 도달 불가 코드 테스트
+
+```kotlin
+companion object {
+    fun of(matchCount: Int, bonusMatched: Boolean): LottoResult {
+        if (matchCount < FIFTH.matchCount) return FAIL
+        //. 매칭.
+        throw IllegalArgumentException(.)  // ⚠ 도달 불가지만 컴파일러가 모름
+    }
+}
+```
+
+PR 본문: *"throw에 대한 검증(assertThrow)이 진행되지 않았다고 나오는 것을 확인했습니다."*
+
+→ **답:** 도달 불가 코드의 테스트 커버리지는 무의미. 그 코드 자체를 제거하거나, sealed로 컴파일러가 알게 하기.
+
+## 리뷰어 의견 요지
+
+리뷰어 @hyemdooly의 가르침:
+
+1. **lateinit var + public 회피** — private 적용 + 가능하면 생성자 주입.
+
+2. **enum의 *순서 의존* 회피** — `values()[index]`는 silent bug 위험. 명시적 매칭으로.
+
+3. **금액 도메인의 책임** — Lottos가 금액 검증/계산까지 가지면 god-object 시작.
+
+4. **인스턴스 재사용 압박 시뮬레이션** — 1000개로 늘면 부담? 캐싱 검토.
+
+5. **이름 설계 시 *함수 vs property* 의식**.
+
+- **대표 인용:**
+  > 만약 `LottoResult` 상수들이 순서가 바뀐다면 이 코드는 어떻게 될까요?
+  >
+  > — @hyemdooly on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 만약 100개, 1000개 이상의 로또 숫자를 생성한다면 어떨까요? 인스턴스 100개, 1000개가 필요할까요?
+  >
+  > — @hyemdooly on `src/main/kotlin/lotto/domain/LottoNumber.kt`
+
+## 얻은 교훈
+
+- **enum의 *순서 의존*은 silent bug**. `values()[N]`은 enum 재배치 시 다른 값을 반환 — 컴파일러 경고도 없음. 명시적 `find {. }`로.
+- **고정 범위의 값 객체는 캐싱 후보**. LottoNumber(1-45)는 시스템 전체에서 45개만 존재 = `flyweight` 패턴 후보.
+- **`Lottos`(일급 컬렉션)는 컬렉션 관리만**. 금액, 등수, 통계 같은 부수 도메인은 별도 객체.
+- **도달 불가 코드의 테스트 커버리지 ≠ 신뢰**. 도달 불가하면 *코드 자체를 제거*. sealed class로 컴파일러가 보장하게.
+- **lateinit var = invariant 시간차 파괴**. 객체가 생성 시점부터 *완성된 상태*를 갖도록.

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

@@ -0,0 +1,111 @@
+# PR #137 — [지오] 2단계 로또
+
+- **Reviewee:** [@giovannijunseokim](https://github.com/giovannijunseokim)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/137
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @hyemdooly (구두)
+- **라인 코멘트:** 24 (리뷰어 17 + 학생 7)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoShop`이 Generator에게 생성 위임** — Tell-Don't-Ask 칭찬.
+- **`null`을 활용한 예외 처리** — 칭찬: "*null을 활용해서 예외 처리* 👍".
+- **`kdoc` 활용** — 칭찬: "kdoc 활용 👍".
+- **`LottoMachine` 외부 받기** — 후속 리팩토링에서 *방법 주입*.
+
+## 못한 점 (설계 관점)
+
+### 1. *Controller에서 직접 생성*
+
+리뷰어: "*Controller에서 생성하지 않고 밖에서 생성된 것을 받아서 사용할 수* 있을까요?" — DI 권유.
+
+### 2. *테스트용 가짜 생성자 프로덕션 코드에*
+
+```kotlin
+class Lotto {
+    constructor(vararg numbers: Int) : this(numbers.map { LottoNumber(it) }.toSet())  // ⚠ 테스트용
+}
+```
+
+리뷰어: "*테스트를 위한 가짜 생성자라면 테스트 코드에 있는 것이 좋을 것 같*아요!" — *프로덕션 코드 오염* 회피.
+
+### 3. `RandomLottoGenerator` *생성된 로또 내용 테스트 불가*
+
+리뷰어: "로또 머신에게 로또를 생성하는 방법을 알려주고, 그 방법대로 생산하게 하는 것이 좋네요 👍 *테스트하기 쉬워지려면 어떻게 수정해야 할까요? 지금으로서는 RandomLottoGenerator 때문에 생성된 로또의 내용까지는 테스트하기가 어렵겠*군요 🤔" +  "*로또 내용 테스트는 LottoShop이 아닌 LottoMachine이나 LottoGenerator가 되어야 겠*군요. *제가 놓쳤어요*!! 감사합니다.ㅎㅎ" — *책임 단위 테스트*.
+
+### 4. *테스트 검증부 하드코딩 vs 계산*
+
+리뷰어: "제가 *[테스트 검증부 하드코딩](https://jojoldu.tistory.com/615)에 관한 글을 공유*해 드렸던가요? *저는 계산 로직이 직접적으로 들어가는 것보다는 하드코딩을 선호*해요. *지오 생각은 어떠신가요*?" + 후속: "저는 *expect에는 되도록 하드코딩하는 편*입니다! 원래는 지오와 같은 의견으로, *이렇게 작성해야 로또 가격이 변해도 테스트 코드는 잘 돌아간다고 생각*했는데요. *테스트 코드는 일종의 문서이기도 하니, 한 눈에 볼 수 있도록 하드코딩하는 것을 더 선호*하게 되었습니다! 만약 *로또 가격이 변한다면 테스트 코드도 같이 변경*해 줘야 한다고 생각해요. *지금 같은 경우에는 999 이런 식으로요*!" — *테스트 = 문서*: PR #147 (lee-ji-hoon) `var price` 동어 반복과 같은 결.
+
+### 5. `winLotto` 변수명
+
+리뷰어: "*winLotto에서 win이 된 이유*가 있을까요? 앞에 *boughtLottos*가 있어서 *기존처럼 winLotto가 더 구분하기 좋아 보여서요*!"
+
+### 6. *논리적 오류 vs null 반환* — 학생 README 적었음
+
+리뷰어: "이번 로또에서 *예외 처리보다는 객체 간의 책임과 역할에 대해 좀 더 리뷰를 드리려고 하고 있긴 한데요*! *README에 '논리적인 오류가 아니면 예외를 던지지 말고 null을 반환한다.' 내용을 적어 주셔서요*.ㅎㅎ *지금은 모든 오류에 대해 예외를 던지고* 있는 것 같아요. *논리적인 오류는 무엇일까요? null을 반환받으면 어떻게 예외 처리를 할 수 있을까요*?" 후속: "*모든 오류가 예외를 던지고 있어서 드린 리뷰였는데, 적절히 수정해 주셨군요* ㅎㅎ 👍".
+
+### 7. `LottoShop`이 *처음부터* 손님의 돈+수동 양 보유?
+
+리뷰어: "*LottoShop에서 손님의 돈과, 수동으로 구입할 양을 처음부터 들고 있기 보다는 로또를 살 때 받는 게 더 자연*스럽지 않을까 싶은데, *지오 생각은 어떠신가요*?" 학생 후속: *Count 원시값 포장 + 살 때 계산* 두 의견 제시. 리뷰어: "*하지만 지금 요구사항에서는 지오의 의견을 읽어보니 이해가* 되네요! 💭" — *대화로 결정*.
+
+### 8. *에러 메시지 sealed class*
+
+리뷰어: "이런 에러 메시지를 *sealed class를 활용해서, InputView에서 전달해 줄 수 있을 것* 같아요!" — *상태별 메시지 매핑*.
+
+### 9. `interface` vs `fun interface`
+
+리뷰어: "*인터페이스에 함수가 하나밖에 없군요! interface vs fun interface에 대해 학습*해 보세요.ㅎㅎ" + "추가로 *LottoGenerator인데, 실제 코드는 LottosGenerator인 것* 같아요. 아마 수동 경우 때문에 이렇게 된 것 같은데, 다른 리뷰에서 같이 코멘트 드리겠습니다!" — *SAM = fun interface*. *Lotto vs Lottos* 시그니처 일관성.
+
+### 10. `LottoMachine` *함수형 인터페이스 + View 람다*
+
+리뷰어: "*LottoMachine도 외부로부터 받아서 사용하면 어떨까요*? 지금은 하나의 로또 머신이 방법을 주입받아서 사용하고 있는데, *자동 로또 머신과 수동 로또 머신으로 나눠볼 수도 있을 것 같*아요. 즉, *LottoMachine을 만들 때 generator를 주입받는 방법도 있을 것 같*아요!
+
+그럼, *사용자한테 입력받는 경우에는 어떻게 처리하나요? 라는 질문*이 있을 것 같은데요.
+```kotlin
+val manualLottoGenerator = LottoGenerator { view.readManualLotto() } // Manual Lotto 하나를 읽어오는 뷰 로직
+```
+이런 식으로 *Controller에서 Generator한테 뷰의 로직을 넘겨줄 수* 있습니다.
+
+> 그럼 이건 Domain 입장에서 View를 알고 있는 것은 아닌가요?
+
+이 의문에 대해서는 *크루들과 함께 토론*해 보시면 좋을 것 같아요!" — *함수형 인터페이스 람다*로 *책임 전달*. *추상화 깊이* 학생 사고 유도.
+
+## 리뷰어 의견 요지
+
+- **Controller *직접 생성 X*** — 외부 주입.
+- **테스트 *fake = 테스트 코드*에**.
+- **테스트하기 어려운 곳 = *책임 분리* 신호**.
+- **테스트 *expect 하드코딩***.
+- **변수명 *대조*** — `winLotto` vs `winnings`.
+- **논리적 오류 vs *null 반환***.
+- **`Shop` *살 때 받기*** = 자연 흐름.
+- **에러 메시지 *sealed class* InputView에 매핑**.
+- **`fun interface` *SAM 학습***.
+- **`LottoGenerator { view.readManualLotto() }` *람다로 View 책임 주입*** — *추상화 토론 거리*.
+
+- **대표 인용:**
+  > 테스트하기 쉬워지려면 *어떻게 수정해야 할까요? 지금으로서는 RandomLottoGenerator 때문에 생성된 로또의 내용까지는 테스트하기가 어렵겠*군요.
+  > — @hyemdooly on `src/main/kotlin/lotto/domain/LottoShop.kt`
+
+  > 테스트 코드는 일종의 문서이기도 하니, *한 눈에 볼 수 있도록 하드코딩하는 것을 더 선호*하게 되었습니다.
+  > — @hyemdooly on `src/test/kotlin/lotto/domain/LottoShopTest.kt`
+
+  > 이런 식으로 *Controller에서 Generator한테 뷰의 로직을 넘겨줄 수* 있습니다. > 그럼 이건 Domain 입장에서 View를 알고 있는 것은 아닌가요? 이 의문에 대해서는 *크루들과 함께 토론*해 보시면 좋을 것 같아요!
+  > — @hyemdooly on `src/main/kotlin/lotto/domain/LottoMachine.kt`
+
+  > 지오의 의견을 읽어보니 이해가 되네요! 
+  > — @hyemdooly on `src/main/kotlin/lotto/domain/LottoShop.kt`
+
+## 얻은 교훈
+
+- **Controller *직접 생성 X*** — DI (생성자/세터/인터페이스). *생성 책임 외부*.
+- **테스트 *fake = 테스트 코드*에** — *프로덕션 오염* 회피.
+- **테스트 어려움 = *책임 분리 신호*** — *RandomGenerator 의존*이 *LottoShop 테스트*를 막으면 *책임 위치 의심*.
+- **테스트 *expect 하드코딩 = 문서*** — *동어 반복 회피* + *명세 가시성*.
+- **변수명 *대조*** — `winLotto` vs `boughtLottos`. *대구 (對句)*가 가독성.
+- **논리적 오류 vs null 반환** — *논리 오류 = 예외*, *형식 오류 = null*. *PR #148 (etama123) 4단계 정리*와 같은 결.
+- **`Shop` *살 때 받기*** — *손님 정보를 처음부터 보유*보다 *주문 시 받기*가 자연 흐름.
+- **에러 메시지 *sealed class*** — *InputView*에서 *상태별 매핑*.
+- **`fun interface` *SAM 학습*** — *함수 하나만*인 interface는 *fun interface*로.
+- **`LottoGenerator { view.readManualLotto() }` *람다 위임*** — *함수형 인터페이스*가 *View 책임*을 *Domain에 위임*. *추상화 vs 의존 방향* 토론 거리.

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

@@ -0,0 +1,52 @@
+# PR #67 — [로또] 해음 1단계 미션
+
+- **Reviewee:** [@haeum808](https://github.com/haeum808)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/67
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 49
+
+## 못한 점 + 핵심 지적
+
+### 1. Lotto가 값 + 검증만 (행위 없음)
+
+```kotlin
+class Lotto(val numbers: List<LottoNumber>) {
+    init { require(numbers.size == 6) }
+}
+```
+
+> 로또 객체가 값을 가지고, 검증하는 것 이외에 별다른 역할을 맡고 있지 않고있네요. 이 객체가 할 수 있는 일들을 다른 곳으로부터 가져와 모아두는 건 어떨까요?
+
+→ Lotto가 *외부에 의해* 비교/매칭되는 *수동적 객체*. `lotto.match(winningLotto)` 같은 행위 부여.
+
+### 2. LottoNumber 매번 생성 — flyweight 미적용
+
+→ 캐시 후 재활용.
+
+### 3. 에러 메시지에 입력값 미포함
+
+```kotlin
+require(value > 0) { "잘못된 금액입니다" }
+```
+
+> 어떤 값이 들어와서 Exception이 발생했는지 메시지를 담아주는 건 어떨까요?
+
+### 4. Rank 매칭 — 모든 값 순회
+
+```kotlin
+fun findRank(count: Int, bonus: Boolean): Rank {
+    return values().first { it.count == count && it.bonus == bonus }
+}
+```
+
+> 모든 값을 순회할 필요가 있을까요? 특정 경우에만 조건문을 처리하고, 나머지를 처리하게 구성해보는 건 어떨까요?
+
+→ when으로 *특수 케이스* (5개 + 보너스 = SECOND) 분기.
+
+## 얻은 교훈
+
+- **값 객체에 행위 부여 필수** — 값만 있으면 *수동적 객체*.
+- **flyweight 패턴** = 고정 범위 값 객체 재활용.
+- **에러 메시지에 *입력값*** 포함 → 운영 디버깅 비용 ↓.
+- **when 분기 vs 전체 순회** — 특수 케이스가 적으면 when이 명시적.