oh-my-oop 0.2.0

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

@@ -0,0 +1,187 @@
+# PR #52 — [멧돼지] 2단계 로또
+
+- **Reviewee:** [@2chang5](https://github.com/2chang5)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/52
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` `value class`** — 인라인 클래스 활용.
+- **`ManualPurchaseCount` value class + private constructor + factory** — 검증 강제.
+- **`LottoFactory` 인터페이스 + `RandomLottoFactory`/`ManualLottoFactory`** — Strategy.
+- **자가 의문 PR에 풍부히 명시** — *Manual Factory가 InputView를 의존*하는 딜레마를 학생이 직접 정리.
+
+## 못한 점 (설계 관점)
+
+### 1. `purchaseLottoCount` + `purchaseLotto` 분할 입력 — 학생 의도 의문
+
+```kotlin
+private fun getManualPurchaseCount(purchaseCount: Int): ManualPurchaseCount {. }
+private fun getManualPurchaseLotto(manualPurchaseCount: ManualPurchaseCount): List<Lotto> {. }
+```
+
+리뷰어: "InputView로부터 purchaseLottoCount(), purchaseLotto()를 *나눠서 호출하는 이유*는 무엇인가요?" 학생: "*입력을 각각 따로 받기*도 하고 한 함수에서 *한 가지 일만* 하려고 노력하는 방향에서 쪼개 보았습니다! 로또를 *구입 금액을 입력*하는 것과 *로또 발행을 구분*한 것처럼 수동 로또 *구입 갯수와 수동 로또 입력을 구분*하였습니다!"
+
+### 2. bonus 확인에 `map` 불필요
+
+```kotlin
+fun matchLottoNumber(bonusNumber: LottoNumber): Boolean =
+    bonusNumber.value in lottoNumbers.map { lottoNumber -> lottoNumber.value }  // ⚠ map
+```
+
+리뷰어: "bonusNumber가 있는지 확인하기 위해, *map으로 변환할 필요는 없습니다*. 앞서 사용한 `count {. }` 함수를 잘 활용해 보세요" 학생: "count를 활용하여 리팩토링해 보았지만 뭔가 `in`을 사용하면 *안에 있나 없나가 직관적*으로 받아들여지는 반면 count를 사용하면 *뭔가 한참 생각해야 아 이게 안에 존재하는지 판별*하는구나를 느낄 수 있는 거 같아 저는 뭔가 아쉬운데…" 리뷰어 답: "map과 in이 따로 있어서 헷갈렸군요. 이 경우에는 *`any { }` 함수*를 사용할 수 있을 것 같아요." — `any { it == bonusNumber }`.
+
+### 3. 같은 클래스 파라미터는 private 함수 접근 가능
+
+```kotlin
+fun countContainLottoNumber(lotto: Lotto): Int =
+    lottoNumbers.count { lottoNumber -> lottoNumber.value in lotto.lottoNumbers.map { it.value } }
+```
+
+리뷰어: "위 함수에서 `lotto.lottoNumbers.map` 함수는 *몇 번이 호출*이 될까요? 메소드의 *파라미터로 같은 클래스가 들어온다면, private 함수를 호출*할 수 있습니다." — `lottoNumbers.count { it in other.lottoNumbers }`로, *내부 직접 접근*.
+
+### 4. `ManualPurchaseCount`가 `purchaseCount`까지 검증
+
+```kotlin
+value class ManualPurchaseCount private constructor(val value: Int) {
+    init { require(value > 0) }
+    companion object {
+        fun ManualPurchaseCount(manualPurchaseCount: Int, purchaseCount: Int): ManualPurchaseCount {
+            require(manualPurchaseCount < purchaseCount) { BIGGER_MANUAL_PURCHASE_MONEY_ERROR }
+            return ManualPurchaseCount(manualPurchaseCount)
+        }
+    }
+}
+```
+
+리뷰어: "'수동 로또 수'가 '구입 로또 수'에 *관심을 가지는 게 맞는 설계*일까요? 구조적으로 고려한다면 아래 형태로, *하나의 묶음으로서 관리*가 되어야 하지는 않을까요?
+```
+전체 구매 갯수 {
+    수동 구매 갯수
+    자동 구매 갯수
+}
+```
+즉, 현재 구조에서 *아래 함수는 논리적으로 문제가 되지 않는 코드*가 됩니다.
+```kotlin
+val totalCount = 20
+val autoCount = 5
+val manualCount = ManualPurchaseCount(15, totalCount)
+doNext(manualCount, autoCount) // 잘못 넣음 그런데 전혀 문제가 없음
+```" — *팩토리에서 전체 수를 받아도 인스턴스에는 안 남으므로* 외부에서 *서로 모순된 값*을 넘길 수 있음.
+
+### 5. `Fake Constructor` 이름 패턴
+
+```kotlin
+companion object {
+    fun ManualPurchaseCount(manualPurchaseCount: Int, purchaseCount: Int): ManualPurchaseCount {. }
+}
+```
+
+리뷰어: "프로덕션 코드에서 사용할 목적으로는 *Fake Constructor와 같이 대문자로 시작하는 함수*를 사용하는 경우는 특이한 경우를 제외하고는 없습니다. *명시적으로 함수에 이름을 부여*하도록 해야 합니다." — `of(.)` 또는 `from(.)`.
+
+### 6. Controller가 *자동/수동 발행 정책*을 다 알고 있음
+
+```kotlin
+private fun getLottoBunch(
+    purchaseCount: Int,
+    manualPurchaseCount: ManualPurchaseCount,
+    manualPurchaseLotto: List<Lotto>,
+): LottoBunch {
+    val autoPurchaseCount = getAutoPurchaseCount(purchaseCount, manualPurchaseCount)
+    val lottoBunch = LottoBunch(manualPurchaseLotto + List(autoPurchaseCount) { lottoFactory.createLotto() })
+}
+```
+
+리뷰어: "무언가 *어색함*이 느껴지지는 않으셨나요? 자동 로또는 *로또 팩토리를 이용*해서 만들고 있습니다. 수동 로또는 *직접 만들고* 있습니다. 즉, 현재는 LottoFactory라는 타입이 *랜덤으로 줄 것이다라는 것을 컨트롤러가 이미 전부 다 알고 있다*는 의미가 됩니다. *자동으로 만들지, 수동으로 만들지 구체적인 방법은 구현체에서 결정*해야 하지 않을까요? 의존성을 주입하는 방법은 크게 3가지: 1. 생성자 2. ??? 3. ???"
+
+### 7. `ManualLottoFactory`의 *View 의존* 딜레마
+
+```kotlin
+class ManualLottoFactory : LottoFactory {
+    override fun createLotto(): Lotto =
+        Lotto(InputView.getManualPurchaseLotto().map { LottoNumber(it) }.toSet())  // ⚠ View 의존
+}
+```
+
+리뷰어: "ManualLotto에서 InputView에 의존해서 직접 가져오도록 한 방법은 좋습니다. 하지만 *도메인에서 view를 의존하게 되면 안* 됩니다. 도메인에서 구현해야 하는 대상이 맞다면, *뷰에 의존하지 않는 다른 형태*로 만들거나, *컨트롤러가 있는 곳에서 구현*을 해야 맞겠습니다." 학생 자가 의문 길게: "*createLotto에 인자를 추가*하는 방법, *인터페이스에 별도 메서드 추가*, *setter/생성자로 상태 보유* — 셋 다 마음에 안 들어요." 리뷰어: "1번, 2번, 3번 *모두 좋지 않은 방법*입니다. 이 내용은 지금 단계에서는 *고민하는 것으로 충분한 도움*이 되셨을 것 같습니다. 저는 지금 *제 의견이나 답을 알려드리지 않을 건데요*. 이렇게도 구현해 보고, 저렇게도 구현해 보고 *스스로 답을 찾아*가셨으면 좋겠습니다." — *명확한 정답이 없는* 영역에서 학생이 직접 시도.
+
+### 8. `LottoBunch.from(totalPurchaseCount)`이 *슈퍼 함수*가 됨
+
+```kotlin
+class LottoBunch(val value: List<Lotto>) {
+    companion object {
+        fun from(totalPurchaseCount: TotalPurchaseCount): LottoBunch {
+            val lottoBunch = LottoBunch(getManualPurchaseLotto(.) + getAutoPurchaseLotto(.))
+            OutputView.printPurchaseResult(.)  // ⚠ View 호출
+            return lottoBunch
+        }
+    }
+}
+```
+
+리뷰어: "LottoBunch가 *직접적으로 로또 구현 방식을 알게 되면서*, 지금까지 쌓아온 방식이 *모두 깨진 것* 같습니다.
+1. *도메인에서 UI 구현*을 하고 있습니다.
+2. 도메인에서 *자동 팩토리, 수동 팩토리와 모두 의존*하게 되었습니다.
+3. *LottoBunch.from 함수가 슈퍼 함수*가 되었습니다. 모든 게임의 로직을 담고 있게 되었네요." 학생: "아아아아아아아아 컨트롤러가 어떤 조건인지 *모르게 하려고 옮겼는데 더 중요한 규칙을 어겨버렸*네요. 다 알고 숙지한 내용인데 왜 이런 바보짓을 했는지 부끄럽습니다. 그래도 오히려 바보짓을 많이 해서 좀 더 *각인되게 룰을 배우는 것* 같습니다!!"
+
+### 9. `AutoPurchaseCount` — 단순 복붙
+
+```kotlin
+value class AutoPurchaseCount(val value: Int) {
+    init { require(value > 0) { NEGATIVE_AUTO_PURCHASE_MONEY_ERROR } }
+    companion object { private const val NEGATIVE_AUTO_PURCHASE_MONEY_ERROR = "수동 구입 로또수는 음수일 수 없습니다" }  // ⚠ 메시지가 수동
+}
+```
+
+리뷰어: "PurchaseCount가 *두 개로 만들어질 이유*가 있을지는 모르겠네요. 그럼에도 만들었으니 의견을 드려보면. *수동 로또에서 복사 붙여넣기 한 것* 같습니다." — 메시지에 *수동 로또*라는 문구가 남아 있음.
+
+### 10. `TotalPurchaseCount`의 주생성자가 Int
+
+```kotlin
+class TotalPurchaseCount(totalPurchaseCount: Int, manualPurchaseCount: Int) {
+    val autoPurchaseCount: AutoPurchaseCount
+    val manualPurchaseCount: ManualPurchaseCount
+}
+```
+
+리뷰어: "Int 타입으로 만든다고 하면, *PurchaseCount를 받는 게 주 생성자*가 되어야 하지 않을까요? 부 생성자를 이용해서 만들어 볼 수도 있겠습니다. 검증은 생성 이후의 *init 블록*에서 해도 괜찮지 않을까 싶어요" — *주 생성자*에 *value class* 받는 것이 자연.
+
+## 리뷰어 의견 요지
+
+- **단계별 입력 분리** — *한 함수 한 역할* 원칙. 입력의 *의미 단위*로 분리.
+- **`map().contains()` → `any {}`** — Kotlin idiomatic.
+- **같은 클래스 파라미터는 *내부 접근* 가능** — `private` 멤버를 직접 사용.
+- **상위 객체에서 두 개수를 함께 관리** — `ManualCount + AutoCount`보다 `TotalPurchaseCount`로 묶기.
+- **`Fake Constructor` 회피** — `of`/`from` 같은 *명시적 이름*.
+- **Controller가 자동/수동 정책 X** — 구현체에서 결정.
+- **도메인 → View 의존 금지** — Manual 입력 → Controller에서 데이터 받고 → Factory에 인자로 넘기는 방법은 *학생이 직접 답 찾을 영역*.
+- **`LottoBunch`가 발행+출력+팩토리 의존 모두 흡수** = *슈퍼 함수* 안티패턴.
+
+- **대표 인용:**
+  > '수동 로또 수'가 '구입 로또 수'에 *관심을 가지는 게 맞는 설계*일까요? 구조적으로 고려한다면 *하나의 묶음으로서 관리*가 되어야 하지는 않을까요?
+  > — @laco-dev on `src/main/kotlin/lotto/domain/ManualPurchaseCount.kt`
+
+  > 자동 로또는 *로또 팩토리를 이용*해서 만들고 있습니다. 수동 로또는 *직접 만들고* 있습니다. … *컨트롤러가 이미 전부 다 알고 있다*는 의미가 됩니다.
+  > — @laco-dev on `src/main/kotlin/lotto/LottoController.kt`
+
+  > LottoBunch가 직접적으로 로또 구현 방식을 알게 되면서, 지금까지 쌓아온 방식이 *모두 깨진 것* 같습니다. … *LottoBunch.from 함수가 슈퍼 함수*가 되었습니다.
+  > — @laco-dev on `src/main/kotlin/lotto/domain/LottoBunch.kt`
+
+  > 1번, 2번, 3번 *모두 좋지 않은 방법*입니다. … 저는 지금 *제 의견이나 답을 알려드리지 않을* 건데요. 이렇게도 구현해 보고, 저렇게도 구현해 보고 *스스로 답을 찾아*가셨으면 좋겠습니다.
+  > — @laco-dev on `src/main/kotlin/lotto/domain/factory/ManualLottoFactory.kt`
+
+## 얻은 교훈
+
+- **한 함수 한 역할** — 입력의 *의미 단위*로 분리.
+- **Kotlin idiomatic**: `map().contains()`보다 `any {}`/`count {}`로 한 번 순회.
+- **같은 클래스 파라미터** = *private 멤버 직접 접근* 가능 — `Lotto.match(other: Lotto)` 안에서 `other.numbers`.
+- **상위 객체로 묶기** — `ManualCount(value, total)`은 *total을 안 가지므로* 모순 가능. `TotalPurchaseCount`에 `manual + auto` 묶으면 invariant 강제.
+- **`Fake Constructor`(대문자 함수) 회피** — `of`/`from`/`create` 같은 *명시적 이름*.
+- **Controller는 *발행 정책*을 모르게**. 자동/수동 분기를 Controller가 알면 *구현체의 의미 소실*.
+- **도메인 → View 의존 금지** — 학생의 *3가지 시도 모두 거절*되는 영역. *해결책은 스스로 찾기*가 학습.
+- **`LottoBunch.from`이 *슈퍼 함수*가 되는 신호** — *발행 + 출력 + 팩토리 의존*이 한 함수에 모이면 도메인의 의미가 깨짐. *돌이켜 보면 다 알던 규칙*인데 *과정에서 실수*함을 학생이 자가 인정.
+- **PurchaseCount 응집 클래스** — Total/Manual/Auto를 *한 곳*에서 관리.
+- **value class의 주생성자에 *value class*** — 부생성자가 *Int 변환*을 수행하고 *init에서 검증*.
+- **메시지 복붙 검토** — *AutoPurchaseCount*에 *수동 로또* 메시지가 남으면 *복사 흔적*.

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

@@ -0,0 +1,206 @@
+# PR #14 — [로피] 1단계 로또
+
+- **Reviewee:** [@Choisehyeon](https://github.com/Choisehyeon)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/14
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 36 (리뷰어 33 + 학생 3)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` 캐싱 (Flyweight)** — 칭찬: "*숫자 캐싱을 잘 해 주셨네요* 👍👍".
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoNumber` *객체화 부재*
+
+리뷰어: "*로또 번호를 하나의 객체로 표현*해 보는 것은 어떨까요?" — 원시 Int 사용.
+
+### 2. `matchLottos`가 *Lotto + Lottos 양쪽* — 중복 책임
+
+```kotlin
+class Lotto { fun matchLottos(.) =. }
+class Lottos { fun matchLottos(.) =. }  // ⚠ 중복
+```
+
+리뷰어: "matchLottos는 *Lotto에도 있고, Lottos에도 있*네요! *winningLotto와 bonusNumber를 묶어서 당첨 티켓이란 객체를 만들어 보는 것*은 어떨까요?"
+
+### 3. `WinningResult` *빈 껍데기 + 외부 채우기* — invariant 시간차
+
+```kotlin
+val result = WinningResult()
+lottos.forEach {. result.add(rank). }  // ⚠ 외부 조립
+```
+
+리뷰어: "*빈 껍데기의 WinningResult를 만들어서 값을 채우기보다, WinningResult를 직접 만들어서 반환*하는 것은 어떨까요?" — *invariant 시간차*: 생성 시점엔 *불완전 객체*. 사용 시점엔 *완전 객체*. *Tell-Don't-Ask* 위반.
+
+### 4. *갯수 세는 확장 함수* — `count { }` 활용
+
+리뷰어: "*갯수를 세어 주는 확장 함수를 찾아 보는 것은* 어떨까요?" → `Iterable.count { predicate }`.
+
+### 5. *Rank에 View 로직*
+
+리뷰어: "도메인에 *View에 대한 로직이 들어 있*네요. *View에 대한 로직은 View에서만 사용*해 주세요!" — 모든 PR 공통 패턴.
+
+### 6. `Rank` *2등을 먼저 검사* — 순서 의존
+
+리뷰어: "*rank를 찾기 전에 2등을 먼저 검사해 보는 것은 어떨까요*?" — *bonus = 5등급 동률 시 2등 분기*. *find 순서*에 *비즈니스 의도*.
+
+### 7. *로또 생성을 View가 함*
+
+리뷰어: "*로또를 만들어 내는 것은 View의 역할일까요*? 😀"
+
+### 8. *테스트 공유 변수*
+
+리뷰어: "*여러 테스트가 하나의 변수를 공유하면 어떤 장단점*이 있을까요?" — *테스트 격리* vs *공통 fixture*.
+
+### 9. *랜덤 테스트 제어* — 자동차 경주 학습
+
+리뷰어: "*자동차 경주 미션을 잘 상기해서, 랜덤에 대한 테스트를 다시 구현*해 보세요! *랜덤 요소를 개발자가 제어 가능하게 만들어 보는 것을 고민*해 주세요 🙂" — *Random 외부 주입* 일관 가르침.
+
+### 10. *어떤 메시지가 나왔는지* — 출력 검증
+
+리뷰어: "*어떤 메시지가 나왔는지도 검증*해 보는 건 어떨까요? 🙂" — *경로만 테스트 X, 출력 내용도*.
+
+### 11. *생성자 위치* — Kotlin 컨벤션
+
+리뷰어: "*생성자의 위치는 멤버 함수들 가장 상위에 위치하는 것이 [코틀린 컨벤션](https://kotlinlang.org/docs/coding-conventions.html#class-layout)*입니다 :)"
+
+### 12. *`(1..count).map`* / *`List() { }` 가짜 생성자* — `forEach` 누적 대안
+
+리뷰어: "*(1..count).map { ~ } 이런 확장 함수를 활용*해 보시길 의도했어요. 🙂 *List() { ~ } 같은 전역 함수를 활용*해 보셔도 좋습니다. *다른 반복문을 통해 Collection을 만들어 내는 부분들도 확장 함수로 바꿔 보는 것을 도전*해 보세요 💪"
+
+### 13. *생성자에서 프로퍼티*
+
+리뷰어: "*바로 생성자에서 프로퍼티를 생성*해 보는 것은 어떨까요?" — 본문 init보다 *주 생성자 val* 명시.
+
+### 14. `String` `+` 결합
+
+리뷰어: "*String을 +로 만드는 것은 지양*해야 합니다. 지금은 *컴파일러가 똑똑해져서 알아서 효율적으로 바꿔 주지만, 어떤 단점이 있었을까요*?" — *불변 문자열 매번 생성*. `StringBuilder`/template.
+
+### 15. *메서드 체이닝 줄 분리*
+
+리뷰어: "*메서드 체이닝할 때는 한 줄에 하나만 사용해 보는 것은 어떨까요*? *붙여 썼을 때 어떤 문제가 생길 수* 있을까요?" + "*체이닝된 메서드 중 한 곳에서 Exception이 발생하면, 콘솔에서는 해당 라인을 가리킵니다. 한 줄로 되어 있다면, 어떤 체이닝된 곳에서 Exception이 발생했는지 찾기 어려워*지겠지요 🙂" — *디버깅 가독성*.
+
+### 16. `entries` vs `values()`
+
+리뷰어: "*이전처럼 values()를 활용*해 보세요!" — Kotlin 1.9+ `entries`.
+
+### 17. `WinningLotto` 빈 객체 — 역할 위임
+
+리뷰어: "List<LottoNumber> 대신 *Lotto를 재활용*해 보는 건 어떨까요? 또, *Winning Lotto 객체는 값을 갖고 있기만 할 뿐, 아무 역할도 하고 있지 않고 있*어요. *다른 곳에 흩어져 있는 적절한 역할을 이 객체에 위임*해 보아요 😊"
+
+### 18. *`String?.nullOrBlank()`* 활용
+
+리뷰어: "*String?.nullOrBlank() 확장 함수를 활용*해 보세요" — Kotlin stdlib.
+
+### 19. *주석으로 테스트 횟수 표시* — 거짓말 위험
+
+리뷰어: "*주석을 활용하는 것은 완전히 나쁜 방법은 아니라고* 생각해요. 다만, *주석은 코드가 변경 돼도 에러를 뱉어 내지 않기 때문에 수정하지 않게 되고, 거짓말을 할 가능성이 매우 높아져 주의*해야겠지요. 🙂 *반복 테스트를 할 때 정말로 횟수가 의미가 있는 지 먼저 생각*해 보시면 좋겠어요. *단순히 값만 바꾼 같은 경우의 반복 테스트는, 정말 의미가 있을까요? 어떤 경우가 반복했을 때 의미 있는 테스트가 될까요*?"
+
+### 20. *너무 긴 검증문*
+
+리뷰어: "*검증문이 너무 길어 읽기 어렵습니다. 메시지는 변수에 할당해 보는 것은* 어떨까요?"
+
+### 21. *변하지 않는 검증 재료* 파라미터?
+
+리뷰어: "*변하지 않는 검증 재료를 파라미터로 받을 필요가 있을까요*?"
+
+### 22. *ParameterizedTest인데 1번만 테스트*
+
+리뷰어: "*ParameterizedTest인데 테스트는 실제로 1번만 하고 있*네요. *ParameterizedTest일 필요가 있을지 고민*해 보아요 :)" — *애너테이션 오용*.
+
+### 23. *`Set` 활용 — 중복 방지*
+
+리뷰어: "*Set을 활용*해 보는 것은 어떨까요?".
+
+### 24. *양방향 의존* — `Lotto` ↔ `WinningLotto`
+
+```kotlin
+class Lotto { fun matchWith(winning: WinningLotto) =. }
+class WinningLotto { fun matchWith(lotto: Lotto) =. }  // ⚠
+```
+
+리뷰어: "*Lotto와 WinningLotto가 서로 알고 있는 양방향 의존성을 지니*네요. *양방향 의존 관계는 어떤 단점이 있을까요*? matchLotto 역할의 위치를 다시 한 번 생각해 볼까요? 🙂" — *순환 의존*은 *변경 전파*.
+
+### 25. `LottoGame.matchGame` — 어색한 이름
+
+리뷰어: "*LottoGame의 이름과 실제 하는 역할에 대해 충분히 고민*해 보셨으면 좋겠어요. *matchGame은 다른 개발자가 봤을 때에도 한 번에 이해되는 이름일까요*?"
+
+### 26. *generate마다 1..45 리스트 매번 생성*
+
+```kotlin
+fun generate(): List<Int> = (1..45).shuffled().take(6)  // ⚠ 매번 새 리스트
+```
+
+리뷰어: "*generate를 할 때마다 1~45 숫자 list가 매번 생성*되겠네요. *한 번만 만들어 보는 것은 어떨까요*?" — *상수 컬렉션*으로 *재사용*.
+
+### 27. *피드백 롤백 오해* — 학생의 오해
+
+리뷰어: "*[이전처럼 변경]해 보라는 의미는 [이전에 드렸던 피드백]까지도 이전으로 롤백하라는 의미가 아닙니다*. 😥" — *부분 변경 의도*가 *전체 롤백*으로 오해된 경우.
+
+### 28. `WinningLotto.hasBonusNumber()` — *어색*
+
+리뷰어: "이 메서드들은 *당첨 로또가 가져야 할 일이 맞을까요*? *당첨 티켓은 반드시 보너스 볼을 지니는데*, 특히, *WinningLotto.hasBonusNumber()는 굉장히 어색한 사용*으로 느껴집니다." — *항상 true*인 메서드는 *불필요*.
+
+### 29. *테스트 준비 = `Lotto(1, 2, 3, 4, 5, 6)`*
+
+리뷰어: "테스트의 *준비 재료를 map 등의 로직으로 만들어 내는 것은 가독성을 해칩니다*. 아래 코드 스니펫을 참고해서, *생성자 혹은 가짜 생성자(팩토리 함수)로 만들어 보는 것*은 어떨까요?
+```kotlin
+val lotto = Lotto(1, 2, 3, 4, 5, 6)
+```".
+
+### 30. *ParameterizedTest 도전* — CsvSource
+
+리뷰어: "이 테스트는 *PrameterizedTest로 만들어 보는 것을 도전*해 보세요! 💪 힌트로, *CsvSource를 활용*해 보세요 :)"
+
+## 리뷰어 의견 요지
+
+- **`LottoNumber` 객체화 + Set**.
+- **`matchLottos` 양쪽 중복 → 당첨 티켓**.
+- **빈 객체 + 외부 채우기 → *완성 객체 반환***.
+- **`Rank.from` 2등 우선 분기**.
+- **View vs 도메인 = 모든 PR 공통**.
+- **랜덤 외부 주입** (자동차 경주 학습).
+- **출력 메시지도 검증**.
+- **Kotlin 컨벤션 *생성자 위치, 체이닝 줄 분리***.
+- **`String +` → 템플릿**.
+- **양방향 의존 = 순환 위험**.
+- **`hasBonusNumber()` 항상 true** = 불필요.
+- **`ParameterizedTest` *1번만*** = 오용.
+- **테스트 준비 = *생성자/팩토리***. `map` 로직 가독성 해침.
+- **주석 = *거짓말 가능성*** — 코드 변경에 따라가지 않음.
+- **`(1..45).shuffled()` *매번 생성*** → 상수 컬렉션 재사용.
+
+- **대표 인용:**
+  > 빈 껍데기의 WinningResult를 만들어서 값을 채우기보다, *WinningResult를 직접 만들어서 반환*하는 것은 어떨까요?
+  > — @malibinYun on `src/main/kotlin/lotto/domain/WinningResult.kt`
+
+  > 주석은 *코드가 변경 돼도 에러를 뱉어 내지 않기 때문에 수정하지 않게 되고, 거짓말을 할 가능성이 매우 높아*져 주의해야겠지요.
+  > — @malibinYun on `src/test/kotlin/lotto/domain/LottoTest.kt`
+
+  > 당첨 티켓은 반드시 보너스 볼을 지니는데, 특히, *WinningLotto.hasBonusNumber()는 굉장히 어색한 사용*으로 느껴집니다.
+  > — @malibinYun on `src/main/kotlin/lotto/domain/WinningLotto.kt`
+
+  > 양방향 의존 관계는 *어떤 단점*이 있을까요?
+  > — @malibinYun on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+## 얻은 교훈
+
+- **빈 객체 + 외부 채우기 = *invariant 시간차*** — 생성 시점에 *불완전*. *완성된 객체 반환*이 *invariant 즉시 보장*.
+- **`matchLottos` *양쪽 중복*** = 책임 위치 모호. *WinningLotto*가 *매칭 진입점*.
+- **`Rank.from` 분기 순서 = *비즈니스 의도*** — *2등 먼저 검사*가 *bonus 동률 처리* 명세.
+- **양방향 의존 = *순환 위험 + 변경 전파*** — `Lotto.match(winning)` 또는 `winning.match(lotto)` 한쪽만.
+- **`hasBonusNumber()` *항상 true* = 불필요** — *invariant인 속성*은 *질문할 필요 없음*.
+- **`ParameterizedTest` *1번만*** = 잘못된 도구. *vanilla `@Test`* 충분.
+- **테스트 준비 = *생성자/팩토리*** — `numbers.map {. }`보다 *Lotto(1,2,3,4,5,6)*가 *의도 즉시*.
+- **주석의 *거짓말 위험*** — *컴파일러가 검증 안 함*. 코드 변경에 따라가지 않음.
+- **반복 테스트 *의미 있는 횟수*** — *값만 바꾸는 반복*은 *시그널 없음*. *경계값/엣지 케이스*가 의미 있는 반복.
+- **`(1..45).shuffled()` *매번 생성*** → *상수 컬렉션 재사용*. *Flyweight*의 변형.
+- **생성자 위치 = *멤버 함수 가장 상위*** — Kotlin 컨벤션.
+- **체이닝 *줄 분리*** = *디버깅 가독성*. *Exception 라인 추적*.
+- **`String +` → *템플릿/StringBuilder*** — *불변 문자열* 매번 생성.
+- **랜덤 외부 주입** — *자동차 경주 학습*. 일관된 가르침.
+- **출력 메시지 검증** — *경로 통과만으로 부족*. *어떤 내용이 출력되었는지*도.
+- **`(1..count).map { gen() }` / `List(n) { gen() }`** — Kotlin idiom.
+- **`String?.isNullOrBlank()` *Kotlin stdlib*** 활용.

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

@@ -0,0 +1,119 @@
+# PR #47 — [로피] 2단계 로또
+
+- **Reviewee:** [@Choisehyeon](https://github.com/Choisehyeon)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/47
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 21 (리뷰어 18 + 학생 3)
+
+## 잘한 점 (설계 관점)
+
+- **`take` 확장 함수** — 칭찬: "take 확장 함수를 활용해 주셨네요 👍".
+- **Kotlin delegation** — 1단계와 다른 시도.
+- **확장함수 활용** — 칭찬: "*코틀린 확장함수를 잘 활용*해 주셨네요!".
+- **`Parameterized Test`** — 칭찬: "*Parameterized Test를 잘 작성*해 주셨네요!".
+
+## 못한 점 (설계 관점)
+
+### 1. `!!` 사용
+
+리뷰어: "*null과 non-null을 엄격히 구분하는 언어이니, !!의 사용은 지양*해 주세요.".
+
+### 2. *LottoMachine 매번 new*
+
+리뷰어: "*로또를 생성할 때마다 LottoMachine을 새로 생성하지 않고 재활용*할 수 있는 방법을 생각해 보아요 :)"
+
+### 3. *결과 생성 책임 위치*
+
+리뷰어: "*로또 결과를 생성하는 것은 어느 객체의 일일지* 다시 고민해 보아요 :)"
+
+### 4. `Lotto delegation` *전체 인터페이스 노출*
+
+```kotlin
+class Lotto(numbers: List<LottoNumber>) : List<LottoNumber> by numbers
+```
+
+리뷰어: "*Kotlin Delegation을 활용해서 일급 컬렉션을 구현*해 주셨네요 :) delegation을 활용하면, *Lotto에서 필요한 메서드 뿐만 아니라 불필요한 메서드까지도 갖게* 됩니다. *일급 컬렉션에서는 필요한 메서드만 구현*해 보는 것은 어떨까요?".
+
+### 5. *`List(n) {. }` 가짜 생성자*
+
+리뷰어: "*List() {. }를 활용*해 볼 수 있어요 🙂" — 모든 PR 공통.
+
+### 6. `Count` *많은 의존 + 책임 모호*
+
+리뷰어: "이 *Count는 이름에 비해서 많은 의존 관계가 엮여 있어 보여요. Count라 하면 갯수만을 가지고 있을 것이 기대*되는데, *Money를 알고, Lotto를 간접적으로 알고 있는 형태*예요. 이 객체의 *역할과 책임에 대해서는 충분히 고민*을 해 보셨으면 좋겠어요. 너무 어려운 내용일 수도 있으니, *많은 변형을 하지 않으셔도 좋습니다* 🙂" — PR #140 (rosemin928) *LottoTicketCounter 책임 모호*와 같은 결.
+
+### 7. *에러 메시지 정확성* — 보너스 번호 ≠ 로또 숫자
+
+리뷰어: "*로또 숫자는 반드시 당첨 번호는 아니라고* 생각해요. *메시지를 더 다듬어 보는 건* 어떨까요?"
+
+### 8. *`ParameterizedTest` + `MethodSource` 활용*
+
+리뷰어: "이 테스트는 *Parameterized Test를 활용*해 볼 수 있겠네요 :)" + "*list처럼 복잡한 객체가 필요한 경우엔 Method Source가 더 적합*할 수 있어요 :)" + (한편) "*검증문에 필요한 비교군이 너무 길어 읽기 어렵습니다 :) 게다가 로직이 포함되어서 어떤 값이 반환될 지 한 번에 예측하기가 쉽지 않*아요. *검증의 비교군으로 들어가는 재료를 given 단계에서 미리 준비*해 두는 것은 어떨까요?"
+
+### 9. *불필요한 코드*
+
+리뷰어: "*필요하지 않는 코드는 지워* 주세요!"
+
+### 10. `object` vs *한 번만 생성*
+
+리뷰어: "*LottoMachine을 object를 활용해 만들어 주셨네요 :) 기존처럼 class로 두고, 필요한 곳에서 한 번만 생성해서 활용하는 방법도* 있답니다! *RandomLottoGenerator은 여전히 매번 만들어 줘야겠네요 :) 이 객체도 한 번만 만들고 재활용*해 보면 좋겠네요!"
+
+### 11. *`asSequence` 활용*
+
+리뷰어: "추가로, *.asSequence()에 대해 알아 보셔도 좋겠*어요 😊"
+
+### 12. *`fun interface` + 람다*
+
+리뷰어: "*fun interface에 대해 알아 보시고, 바로 람다로 넘기는 방법에 대해 알아*보시면 좋겠어요! 😊".
+
+### 13. *when/then 혼재* — given/when/then 분리
+
+리뷰어: "*when/then이 섞여 있어서 검증문이 길어*지네요 :) *저는 짧은 테스트라도 given when then을 모두 나눠 주는 게, 읽는 사람에게 더 잘 읽을 수 있게 도움을 준다*고 생각해요 🙂"
+
+### 14. *`assertThat(Collection).hasSize()`*
+
+리뷰어: "*assertThat(Collection).hasSize()를 활용*해 보세요 :)"
+
+## 리뷰어 의견 요지
+
+- **`!!` *마지막 수단***.
+- **재활용 가능 객체 = *매번 new X***.
+- **결과 생성 *책임 위치***.
+- **`delegation` *전체 노출* → 일급 컬렉션 *선택 노출***.
+- **`List(n) {. }`**.
+- **`Count` *책임 응집*** — Money/Lotto 의존 X.
+- **에러 메시지 *정확성***.
+- **ParameterizedTest + MethodSource + given 단계 분리**.
+- **`asSequence`** — 지연 평가.
+- **`fun interface` 람다**.
+- **given/when/then 분리**.
+- **`hasSize()`** assertj idiom.
+
+- **대표 인용:**
+  > delegation을 활용하면, Lotto에서 *필요한 메서드 뿐만 아니라 불필요한 메서드까지도 갖게* 됩니다. 일급 컬렉션에서는 *필요한 메서드만 구현*해 보는 것은 어떨까요?
+  > — @malibinYun on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+  > 이 Count는 *이름에 비해서 많은 의존 관계가 엮여 있어 보여*요. Count라 하면 *갯수만을 가지고 있을 것이 기대*되는데, *Money를 알고, Lotto를 간접적으로 알고 있는 형태*예요.
+  > — @malibinYun on `src/main/kotlin/lotto/domain/Count.kt`
+
+  > 짧은 테스트라도 *given when then을 모두 나눠 주는 게, 읽는 사람에게 더 잘 읽을 수 있게 도움*을 준다고 생각해요.
+  > — @malibinYun on `src/test/kotlin/lotto/domain/LottoTest.kt`
+
+  > 너무 어려운 내용일 수도 있으니, *많은 변형을 하지 않으셔도 좋습니다* 🙂
+  > — @malibinYun
+
+## 얻은 교훈
+
+- **`!!`은 *Kotlin null safety 무시*** — *마지막 수단*.
+- **재활용 가능 객체 *매번 new X*** — *상태 없는 협력자*는 *한 번 만 생성 + 재사용*.
+- **결과 생성 *책임 위치*** = *결과 객체*에.
+- **`delegation` *전체 인터페이스 노출* vs *일급 컬렉션 선택 노출***.
+- **`List(n) { gen() }`** — 모든 PR 공통.
+- **`Count` *이름에 비해 많은 의존*** = 책임 모호.
+- **에러 메시지 *정확*** — *로또 숫자 ≠ 당첨 번호*. 어휘 정합.
+- **`ParameterizedTest` *경계값/시나리오 분리* + `MethodSource` *복잡 객체*** + **given 단계 분리** — 테스트 가독성 3박자.
+- **`asSequence`** — *지연 평가*. *대량 컬렉션 변환 체이닝* 시 메모리 효율.
+- **`fun interface` 람다** — *SAM*.
+- **`given/when/then` *짧은 테스트도*** — *읽기 가독성*.
+- **`assertThat(Collection).hasSize()`** = assertj idiom.

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

@@ -0,0 +1,83 @@
+# PR #2 — [코건] 1단계 로또
+
+- **Reviewee:** [@DYGames](https://github.com/DYGames)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/2
+- **단계:** 1단계 (초창기 PR)
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 57
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto`, `Lottos`, `Bonus`, `WinNumber`, `LottoRankDeterminer` 분리**.
+- **`require` 활용**.
+
+## 못한 점 (설계 관점)
+
+### 1. `World` Controller — god-controller
+
+```kotlin
+class World {
+    fun run() {
+        // 입력, 통계 계산, 출력 모두 World 안에
+    }
+}
+```
+
+> 로또들을 가지고 당첨 티켓과 비교해 통계를 만드는 이 행위는 도메인 로직 입니다 :) Controller의 역할을 하는 World 객체의 책임이 정말 맞을까요?
+
+→ `World`는 너무 광범위한 이름 + 도메인 로직까지 떠안음.
+
+### 2. `WinNumber` vs `Lotto` 불필요한 분리
+
+```kotlin
+class WinNumber(val numbers: List<Int>) {. }
+class Lotto(val numbers: List<Int>) {. }
+```
+
+> WinNumber와 Lotto의 역할에는 객체로 분리할 만큼의 큰 차이점이 있을까요?
+
+→ 같은 데이터 + 같은 검증이면 분리 정당화 어려움. `WinningLotto(lotto, bonus)` 같은 *조합*이 자연스러움.
+
+### 3. `LottoRankDeterminer` — feature-envy
+
+```kotlin
+class LottoRankDeterminer(.) {
+    fun determine(lotto: Lotto, winning: WinNumber): Rank {
+        val count = lotto.numbers.filter { it in winning.numbers }.size  // ⚠ 데이터 꺼내 비교
+        return Rank.of(count)
+    }
+}
+```
+
+> 로또 끼리 비교해서 몇 개가 맞았는지 알아보는 역할은 이 객체의 책임이 맞을까요? 로또에게 메시지를 던지는 방법을 생각해보아요
+> 
+> Rank를 찾는 행위는 Rank에게 위임해보는 것은 어떨까요?
+
+### 4. `RandomLottoGenerator` 매번 새 List 생성
+
+```kotlin
+fun generate(): Lotto {
+    val pool = (1..45).toList().shuffled()  // ⚠ 매번 45개 List 새로 생성
+    return Lotto(pool.take(6))
+}
+```
+
+> generate()를 호출할 때마다 45개 숫자를 담은 List 객체가 새로 생성되겠네요. 한 번 만 생성하고 재활용하는 방법에 대해 고민해보아요
+
+### 5. 랜덤 테스트가 size만 검증
+
+```kotlin
+@Test fun `로또 6개 생성`() {
+    assertThat(generator.generate().size).isEqualTo(6)  // ⚠ 1-45 범위, 중복 미확인
+}
+```
+
+> 랜덤 요소에 대한 테스트에서 size만을 비교하는 것은 제어된 테스트를 했다는 의미를 가지기엔 어렵습니다.
+
+## 얻은 교훈
+
+- **Controller 이름 = 도메인 어휘**. `World`는 god-naming 패턴 — 무엇이든 들어갈 수 있음.
+- **두 객체의 분리 정당화 = 책임/데이터의 다름**. 같으면 합치거나 *조합 객체*로.
+- **Tell-Don't-Ask** — Determiner가 외부 객체 정보로 비교 = feature-envy.
+- **불변 컬렉션 재활용** — `(1..45).toList()`를 *상수*로 한 번만 생성. flyweight 패턴.
+- **랜덤 테스트 = 결정적 fake 주입** — size만 검증 ≠ 제어된 테스트.