oh-my-oop 0.2.0

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

@@ -0,0 +1,129 @@
+# PR #117 — [로또 1단계] 제이 미션
+
+- **Reviewee:** [@parkjiminnnn](https://github.com/parkjiminnnn)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/117
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto`가 자기 invariant(크기/범위/중복) 검증** — `init` 블록으로 *진입 즉시* 보장.
+- **`Lottos` 일급 컬렉션** — 컬렉션에 행위.
+- **`Rank.fromMatchResult(countOfMatch, matchBonus)`** — 분기 캡슐화.
+- **TDD 처음 시도** — 학생 PR에 명시.
+
+## 못한 점 (설계 관점)
+
+### 1. 콘솔 `1,2,3,4,5,6` 입력 시 에러
+
+리뷰어: "실제로 콘솔에 1,2,3,4,5,6을 입력하면 에러가 발생하고 있어요!" — 공백 미처리 또는 `trim()` 누락. 사용자 입력 *허용 폭*에 대한 도메인 정의 누락.
+
+### 2. `Lotto(val numbers: List<Int>)` — `LottoNumber` 미추출 + 범위 불확신
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    init {
+        validateLottoNumbersCount(numbers)
+        validateLottoNumbersRange(numbers)
+        validateLottoNumbersDuplicate(numbers)
+    }
+}
+```
+
+리뷰어: "현재 구조에서는 numbers의 각 원소들이 1~45 사이에 들어간다는 걸 확신할 수 있을까요? 아마 Lotto의 초기화 부분을 보지 않는다면 해당 원소가 1..45에 해당함을 쉽게 알지 못할 겁니다. *로또 번호*라는 객체로 분리하면서 해당 객체가 *스스로 할 수 있는 역할*에 대해 고민." + "1~45를 갖는 *로또번호*라는 객체를 갖게 된다면 조금 더 감이 올 것 같은데요, *당첨 로또*를 계산하는 건 *당첨 로또*라는 객체를 생성하여 책임을 분리할 수 있을 것 같아요. 현재 Lotto 객체가 너무 많은 일을 하고 있습니다."
+
+### 3. `Lotto.getRank(winningNumbers, bonus)` — Lotto가 등수까지 결정
+
+```kotlin
+fun getRank(winningNumbers: List<Int>, bonusNumber: Int): Rank {
+    val countOfMatch = countMatchWinningNumbers(winningNumbers)
+    val matchBonus = isHaveBonusNumber(bonusNumber)
+    validateLottoNumbersDuplicate(winningNumbers + listOf(bonusNumber))
+    return Rank.fromMatchResult(countOfMatch, matchBonus)
+}
+```
+
+리뷰어: "당첨 로또를 계산하는 건 *당첨 로또*라는 객체를 생성하여 책임을 분리할 수 있을 것 같아요." — *등수 결정*은 *당첨 정보*의 책임, Lotto는 *매칭 개수*만.
+
+### 4. 중복 검증을 자료구조로 표현
+
+```kotlin
+private fun validateLottoNumbersDuplicate(numbers: List<Int>) {
+    require(numbers.size == numbers.toSet().size)
+}
+```
+
+리뷰어: "명시적으로 중복이 불가능함을 알려주기도 하면서, 자료구조를 사용하여 방지할 수 있습니다. 2인승 자동차에 인원을 태우면서 더 이상 타지 못함을 알리는 것보다 *2인승 자동차*라는 것을 알려준다면 보다 효과적으로 외부에도 알리기도 쉽고 추가 검증도 필요 없겠죠?"
+
+### 5. `LottoMachine`이 발행 + 수익률까지
+
+```kotlin
+class LottoMachine(private val amount: Int) {
+    fun getLottos(.): Lottos {. }
+    fun getProfitRate(countLottoByRank: Map<Rank, Int>): Float {. }
+}
+```
+
+리뷰어: "로또를 생성하는 기계가 당첨금을 계산해 주는 역할도 하는 걸까요? 세세하게 들어가 비즈니스 로직을 나눠 보면 어떨까요? `class WinningResult { fun getProfitRate(.) }`" — *기계*가 *결과 계산*까지 흡수하면 응집도↓.
+
+### 6. 랜덤 내장 — 테스트 불가
+
+```kotlin
+private fun getLottoNumbers(): List<Int> {
+    val shuffledLottoNumbers = (LOTTO_MIN..LOTTO_MAX).shuffled()
+    return shuffledLottoNumbers.take(LOTTO_SIZE).sorted()
+}
+```
+
+리뷰어: "랜덤으로 생성되는 로또는 어떻게 테스트할 수 있을까요? 실제로 현재 테스트는 진행하지 못했었던 거 같아요" + "테스트가 어려운 코드의 의존관계를 *객체 그래프 상위로* 이동시키는 내용이 있습니다."
+
+### 7. `LOTTO_EACH_AMOUNT = 1000` 내부 상수
+
+리뷰어: "만약 요구사항 변경에 의해 로또 가격이 인상되었다고 하면 상수를 변경해 줘야 할까요? 조금 더 변경에 유연하게 한다면 어떻게 할 수 있을까요?" — *외부 주입*.
+
+### 8. `OutputView`에 *입력 안내 문구*
+
+```kotlin
+class OutputView {
+    fun printPurchaseAmountGuide() { println("구입금액을 입력해 주세요.") }
+    fun printLastWeekWinningNumbersGuide() { println(.) }
+    fun printBonusNumberGuide() { println(.) }
+}
+```
+
+리뷰어: "입력받기 위해 출력할 문구는 Input과 Output 중 어느 역할에 해당할까요? 입력받기 위해 출력하는 문구(구입금액, 당첨번호 입력..)는 *입력받는 객체의 역할*이라고 생각할 수 있지 않을까요? 콘솔에 출력되는 모든 문구 = OutputView라는 개념에서 벗어나도 좋을 것 같아요" — *입력 안내*는 InputView의 자연스러운 부분.
+
+### 9. require + 예외 = 종료. runCatching 미적용
+
+리뷰어: "require로 검증을 하는 것 잘해주셨습니다. 다만, 예외 발생 시 에러 노출로 프로그램을 종료하는 것보다, 사용자로 하여금 재시도를 하게 유도하는 건 어떨까요? 코틀린에는 runCatching이라는 게 존재."
+
+## 리뷰어 의견 요지
+
+- **타입으로 invariant 표현** — `LottoNumber` 추출하면 *Lotto 내부 범위 검증*이 필요 없어짐.
+- **자료구조가 invariant** — `Set`이면 중복 불가가 *외부에 알려짐*.
+- **객체 1개에 *발행 + 결과 계산* 흡수 회피** — 책임 분리.
+- **랜덤은 *상위로 주입*** — 테스트 가능 구조.
+- **상수 외부 주입** — 다중 가격 대응.
+- ***입력 안내*는 InputView 책임도 OK** — *콘솔 출력 = OutputView*라는 *기계적 분리*에서 자유.
+
+- **대표 인용:**
+  > 1~45를 갖는 *로또번호*라는 객체를 갖게 된다면 조금 더 감이 올 것 같은데요, 당첨 로또를 계산하는 건 *당첨 로또*라는 객체를 생성하여 책임을 분리할 수 있을 것 같아요. 현재 Lotto 객체가 너무 많은 일을 하고 있습니다.
+  > — @KwonDae on `src/main/kotlin/lotto/model/Lotto.kt`
+
+  > 로또를 생성하는 기계가 당첨금을 계산해 주는 역할도 하는 걸까요?
+  > — @KwonDae on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+  > 입력받기 위해 출력하는 문구(구입금액, 당첨번호 입력..)는 입력받는 객체의 역할이라고 생각할 수 있지 않을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/view/OutputView.kt`
+
+## 얻은 교훈
+
+- **타입으로 invariant** — `LottoNumber` 추출 시 *Lotto*가 *범위 검증*에서 자유로워짐. *Lotto의 책임*은 *크기·중복*에 집중.
+- **`Set<LottoNumber>`으로 중복 표현** — *2인승 자동차* 비유: *외부에 자료구조로 알리는 것*이 *나중에 거절*보다 친절.
+- **`Tell, Don't Ask` 적용 = 책임 분리** — `Lotto.getRank()`보다 `WinningLotto.match(lotto)`.
+- **객체 1개에 *2개 역할* 흡수 회피** — `LottoMachine`이 *발행 + 수익률*이면 응집도 0. `WinningResult`로 분리.
+- **랜덤 *상위 주입*** — 테스트 격리 + 자동/수동 Strategy 도입에 필수.
+- **상수 외부 주입** — 가격/사이즈 같은 도메인 정책은 *생성자에 주입*해 변경 유연.
+- ***입력 안내 문구*는 InputView 책임도 OK** — *콘솔 출력 = OutputView*는 *기계적 분리*. 의미상 *입력의 일부*.
+- ***종료 vs 재시도*** — UX. `runCatching` + `?:` 재귀.

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

@@ -0,0 +1,173 @@
+# PR #146 — [로또 2단계] 제이 미션
+
+- **Reviewee:** [@parkjiminnnn](https://github.com/parkjiminnnn)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/146
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 18
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` 도메인 객체화** — `Lotto.numbers`가 `Set<LottoNumber>`로.
+- **`WinningResult` 클래스 도입** — 수익률 계산을 *결과 객체*로.
+- **`ManualLottoGenerator` + `LottoGenerator` 인터페이스** — Strategy.
+
+## 못한 점 (설계 관점)
+
+### 1. 테스트만을 위한 `companion object`
+
+```kotlin
+class LottoTest {
+    @Test
+    fun `로또가 6개가 아닌 번호를 가질 때 오류를 반환한다`() {
+        val numbers = makeTestLotto(setOf(1, 2, 3, 4, 5))
+        assertThrows<IllegalArgumentException> { Lotto(numbers) }
+    }
+    companion object {
+        fun makeTestLotto(lottoNumbers: Set<Int>): Set<LottoNumber> = lottoNumbers.map { LottoNumber(it) }.toSet()
+    }
+}
+```
+
+리뷰어: "companion object가 *필요한 상황*일까요?" 학생: "테스트만을 위한 함수를 저렇게 만들어 봤는데 LottoTest 클래스에서만 사용하는 게 아닌 *다른 테스트 클래스들에서도 이 함수가 필요*해서 companion object로 만들어서 *다른 클래스에서 사용*할 수 있게 했습니다. 저 방법 말고는 다른 방법이 생각이 나지 않네요." — *공통 테스트 픽스처*를 어디에 둘지는 *별도 `TestFixture` object 또는 top-level function*.
+
+### 2. 1000원 단위 검증 *삭제* — 요구사항 후퇴
+
+```diff
+-    private fun validateAmountUnit() {
+-        require(amount % LOTTO_EACH_AMOUNT == 0) {
+-            "[ERROR] ${LOTTO_EACH_AMOUNT}원 단위의 금액으로 입력해 주세요. 입력값: $amount"
+-        }
+-    }
+```
+
+리뷰어: "요구사항에는 없었지만 구현해 주셨던 *1000원 단위의 검증 로직이 삭제*되었네요. 그렇다면 1000원 이외의 *나머지 금액에 대해 어떻게 처리*를 하면 좋을까요?" 학생: "좋은 방법이 떠오르지 않아서 일단 1000원 미만으로 입력하는 것만 못하게 했습니다." — *잔돈 처리* 또는 *재입력*.
+
+### 3. 논리적 오류 vs null 학생 자가 의문
+
+학생: "논리적 오류가 아닐 때는 *예외를 던지지 말고 null을 반환*하라고 하셨는데 *논리적 오류가 발생한 경우는 어떤 경우*인가요? 혹시 로또로 예를 들어서 설명해 주실 수 있나요?" 리뷰어: "현재 프로그램은 금액을 *숫자가 아닌 이외의 문자를 받으면 종료*되게끔 구현되어 있어요. 기존 kotlin에서 *toInt와 toIntOrNull 둘 다 개발한 건 어떤 의도*였을까요? 입력을 받는다 → 입력값을 프로그램의 구입 금액으로 *변환하는 과정 중 논리 오류가 아니라면 null을 반환*한다." — *문자 입력*은 *재시도*, *범위 위반*은 *예외*.
+
+### 4. `WinningLotto.getRank`가 Lotto의 프로퍼티에 직접 접근
+
+```kotlin
+private fun countMatchWinningNumbers(winningNumbers: Set<LottoNumber>): Int {
+    lotto.validateLottoNumbersCount(winningNumbers)
+    return lotto.numbers.count { existNumber -> winningNumbers.contains(existNumber) }
+}
+
+private fun isHaveBonusNumber(bonusNumber: LottoNumber): Boolean = lotto.numbers.contains(bonusNumber)
+```
+
+리뷰어: "Lotto의 프로퍼티에 *직접 접근*하고 있네요. *Lotto 객체가 스스로 판단*하게 bonusNumber만 던져 볼 수 있을까요?" 학생: "lotto 객체에서 로또 번호들 중에 *bonusNumber의 존재 여부를 확인 하는 로직을 추가*했습니다!" — `lotto.contains(bonusNumber)`.
+
+### 5. `LottoMachine`이 *수동/자동 수* 모두 관리
+
+```kotlin
+class LottoMachine(
+    private val amount: Int,
+    val passiveLottoQuantity: Int,
+    private val passiveLottoNumbers: List<Lotto>,
+) {
+    fun getActiveLottoQuantity(): Int = amount / LOTTO_EACH_AMOUNT - passiveLottoQuantity
+    fun getTotalLottos(lottoQuantity: Int): Lottos = Lottos(passiveLottoNumbers).plus(getActiveLottos(lottoQuantity))
+    fun getProfitRate(countLottoByRank: Map<Rank, Int>): Float {. }
+}
+```
+
+리뷰어: "LottoMachine에서의 이 함수들에 대해 이야기를 나눠 보고 싶어요. *LottoMachine이 몇 개의 로또가 자동이고 몇 개의 로또가 수동인지 관심*이 있을까? 생각이 들었습니다. LottoMachine은 *로또 생성(getLottoNumbers())만 존재해도 그 역할*을 한다고 생각이 들었는데요 `getProfitRate()` 함수도 *결과를 계산하는 책임을 갖는 클래스를 분리*해도 좋고 때에 따라서는 *로또 스스로가 판단*도 할 수 있을 거라고 생각이 드네요. *LottoMachine의 역할을 분리*해 볼까요?" — 후속 리팩토링: 학생이 `LottoMachine`을 *Generator 위임자*로 축소.
+
+### 6. 보너스 중복 시 *프로그램 종료* — runCatching 권장
+
+리뷰어: "당연히 중복될 수 없죠. 하지만, 중복이 됐다는 이유로 *시스템을 종료해 버린다면 유저는 다시 맨 처음부터 시작*해야 할 거에요. 이런 경우에 [runCatching]을 사용할 수 있습니다." 예시 코드:
+```kotlin
+private fun getWinningLotto(): WinningLotto {
+   return runCatching {. }.getOrElse {
+       println(..)
+       getWinningLotto()
+    }
+}
+```
+
+### 7. View가 `\n`을 *입력 안내 메시지 앞*에 출력
+
+```kotlin
+fun readWinningNumbers(): Set<Int> {
+    println("\n지난 주 당첨 번호를 입력해 주세요.")
+.
+}
+```
+
+리뷰어 (이미지 농담만): "😂" — 학생: "trim()을 사용해 공백을 제거시켜서 해결했습니다."
+
+### 8. `ManualLottoGenerator(numbers: Set<Int>)` — Controller가 Set 만들고 넘김
+
+```kotlin
+class ManualLottoGenerator(private val numbers: Set<Int>) : LottoGenerator {
+    override fun getLottoNumbers(): Lotto = Lotto(numbers.map { LottoNumber(it) }.toSet())
+}
+```
+
+학생 의문: "여기에 set 타입도 *controller에서 LottoNumber 객체로 감싸서* 가져오는 게 맞는 건가요?" 리뷰어: "네 잘 구현해 주셨습니다. 더 나아가서 `ManualLottoGenerator` 클래스가 *List<Lotto>를 반환*해도 좋을 것 같아요." — *Generator가 한 번에 발행물 묶음*.
+
+### 9. `LottoMachine`이 사실상 *위임만*
+
+```kotlin
+class LottoMachine(private val lottoGenerator: LottoGenerator) {
+    fun generateLotto(): Lotto = lottoGenerator.getLottoNumbers()
+}
+```
+
+리뷰어: "이제 LottoMachine은 *사실상 하는 일이 없어서* 컨트롤러에서 *바로 lottoGenerator를 활용*할 수 있겠어요!" — *단순 위임*은 추상화 비용만.
+
+### 10. property vs parameter — 학생 자가 의문
+
+학생: "프로퍼티는 *줄일 수 있다면 줄이는 편이 좋은가요*? amount를 수익률 계산을 위해서만 사용이 되는데 *굳이 프로퍼티에 넣어서 써야 하나* 싶기도 하고 *lottoQuantity 객체를 만든 이유가 불투명*해지지 않을까 해서 지워 봤는데 어떻게 생각하시나요?" 리뷰어: "kotlin에서 *property와 parameter의 차이점*은 무엇일까요? 이 둘의 차이점을 생각해 보시면 *질문 속에 답*이 있습니다. 두 키워드의 *접근 가능한 범위*가 포인트가 될 수 있겠네요." — *property*는 *생명주기 + 외부 접근*, *parameter*는 *호출 시점*만.
+
+### 11. `LottoQuantityTest` 빈 테스트
+
+```kotlin
+class LottoQuantityTest {
+    @Test
+    fun `getAutoLottoQuantity`() { }  // ⚠ 비어 있음
+}
+```
+
+리뷰어: "👀"
+
+## 리뷰어 의견 요지
+
+- **테스트 공통 픽스처는 *별도 TestFixture object 또는 top-level function*** — `companion object`보다 자연.
+- **이전 라운드 요구사항 *유지* 점검** — 1000원 단위 검증 누락은 *기능 후퇴*.
+- ***논리 오류 vs null*** — *변환 실패*는 null, *범위 위반*은 예외.
+- **`Tell, Don't Ask`** — `lotto.contains(bonus)`.
+- **`LottoMachine`의 역할 분리** — 발행/통계 분리.
+- **`runCatching` 재시도** — 종료 회피.
+- **Generator가 *List<Lotto>* 반환** — 호출자 변환 책임 제거.
+- **`property` vs `parameter`** = 생명주기/접근 범위.
+- **빈 테스트 함수 X**.
+
+- **대표 인용:**
+  > LottoMachine이 *몇 개의 로또가 자동이고 몇 개의 로또가 수동인지 관심*이 있을까? 생각이 들었습니다. LottoMachine은 *로또 생성만 존재해도 그 역할*을 한다고 생각이 들었는데요.
+  > — @KwonDae on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+  > 당연히 중복될 수 없죠. 하지만, 중복이 됐다는 이유로 *시스템을 종료해 버린다면 유저는 다시 맨 처음부터 시작*해야 할 거에요.
+  > — @KwonDae on `src/main/kotlin/lotto/model/WinningLotto.kt`
+
+  > 입력값을 프로그램의 구입 금액으로 *변환하는 과정 중 논리 오류가 아니라면 null을 반환*한다.
+  > — @KwonDae on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > 이제 LottoMachine은 *사실상 하는 일이 없어서* 컨트롤러에서 바로 lottoGenerator를 활용할 수 있겠어요!
+  > — @KwonDae on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+## 얻은 교훈
+
+- **테스트 공통 픽스처 = *top-level function* 또는 *별도 object***. companion은 *한 클래스* 한정 의도.
+- **이전 라운드 요구사항 유지 점검** — *새 기능 추가 시 기존 검증 누락*은 흔한 함정.
+- **논리 오류 vs null** — *변환 실패*(문자 입력)는 null + 재시도. *범위 위반*(0원 이하)은 예외.
+- **`Tell, Don't Ask`** — `lotto.numbers.contains(bonus)` → `lotto.contains(bonus)`.
+- **`LottoMachine`의 책임 = 발행만** — 자동/수동 수 관리 + 수익률 계산은 *별도 객체*.
+- **`runCatching`으로 재시도** — *입력 오류 → 처음부터*는 사용자 경험 최악.
+- **Generator가 *List<Lotto>* 반환** — `Set<Int>` 받고 *Lotto 1개* 반환은 *호출자가 반복문* 책임.
+- **`property` vs `parameter`** — property는 *객체 생명주기 + 외부 접근*, parameter는 *함수 호출 시점*만.
+- **위임만 하는 객체는 제거 대상** — `LottoMachine.generateLotto() = lottoGenerator.getLottoNumbers()`는 *추상화 비용*만.
+- **빈 테스트 함수 = *나중에 작성*에서 *영원히 안 작성*** — 작성 안 할 거면 제거, 작성 예정이면 *Tag*.

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

@@ -0,0 +1,21 @@
+# PR #33 — [핑구] 2단계 로또
+
+- **Reviewee:** [@pingu244](https://github.com/pingu244)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/33
+- **단계:** 2단계 (재제출)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 8
+
+## 잘한 점
+
+- **특정 등수에 대한 조건문 삭제** (`if (rank == SECOND).` 같은 분기 제거).
+- **로또 번호 캐싱**.
+
+## 핵심 지적
+
+- **println을 별도 함수로 감싸기**.
+
+## 얻은 교훈
+
+- **특정 등수 조건문 제거 = 유연성 ↑**. enum 자체가 *판별 데이터* (matchBonus)를 가지면 외부 분기 사라짐.
+- **flyweight 적용** = 도메인 일관성.

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

@@ -0,0 +1,30 @@
+# PR #54 — [핑구] 2단계 로또
+
+- **Reviewee:** [@pingu244](https://github.com/pingu244)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/54
+- **단계:** 2단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 10
+
+## 핵심 지적
+
+### 1. 함수명과 반환 불일치
+
+### 2. `ManualLotto` — 복수형 표현 부족
+
+```kotlin
+class ManualLotto(val lottos: List<Lotto>) {. }  // ⚠ 컬렉션인데 단수형
+```
+
+> 해당 클래스는 로또 컬렉션을 가지고 있으므로 복수 표현형을 좀 더 드러내면 어떨까요? 외부에서 네이밍만 본다면, 단일한 ManualLotto 라고도 오해할 수 있어보여요.
+
+→ `ManualLottos` 또는 `ManualLottoBunch`.
+
+### 3. MutableList 반환
+
+> MutableList 타입으로 리턴할 경우 외부에서 컬렉션의 수정이 가능할 것 같은데요. 의도된 구현이실까요?
+
+## 얻은 교훈
+
+- **컬렉션 = 복수형 이름** (`Lottos`, `Cars`, `Numbers`).
+- **MutableList 반환 = 외부 수정 가능 위험**. List/toList()로.

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

@@ -0,0 +1,19 @@
+# PR #7 — [핑구] 1단계 로또
+
+- **Reviewee:** [@pingu244](https://github.com/pingu244)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/7
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 8
+
+## 핵심 지적
+
+- **함수 이름 구체화**.
+- **반복 코드 함수 묶기**.
+- **`any {. }` 활용**.
+- **숫자 언더스코어 가독성** — 칭찬.
+
+## 얻은 교훈
+
+- **`any/all/none`** = 컬렉션 술어 함수 표준.
+- **숫자 언더스코어** (`1_000_000`) = 가독성 ↑.

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

@@ -0,0 +1,143 @@
+# PR #31 — [아크] 2단계 로또
+
+- **Reviewee:** [@re4rk](https://github.com/re4rk)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/31
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 28 (리뷰어 17 + 학생 11)
+
+## 잘한 점 (설계 관점)
+
+- **`value class` 활용** — 칭찬: "value class를 활용해 주셨네요 👍".
+- **`plus` 연산자 오버로딩** — 칭찬: "*plus 연산자 오버로딩을 잘 해 주셨네요*! 👍".
+- **일급 컬렉션 분리** — 칭찬: "*일급 컬렉션으로 잘 분리해 주셨네요* 👍".
+- **`groupingBy + eachCount` 패턴** — 리뷰어 칭찬 + 추가 sequence 제안.
+
+## 못한 점 (설계 관점)
+
+### 1. 남은 돈 계산에 *수동 티켓 전체* 불필요
+
+```kotlin
+fun remainingMoney(manual: Lottos): Money = money - manual.size * LOTTO_PRICE  // ⚠
+```
+
+리뷰어: "*남은 돈을 구하기 위해서 수동 티켓 전체가 필요할까요*? :)" — *최소 필요 정보*: `size: Int`만.
+
+### 2. `LottoStore` *변환 책임 분리*
+
+리뷰어: "*이미 Lotto가 파라미터로 들어오고 있어 큰 의미를 부여하기 어려워* 보입니다. *Lotto로 변환하는 역할을 이 객체에 위임*해 보는 것은 어떨까요?"
+
+### 3. `LottoFactory` + `LottoStore` *역할 중복*
+
+리뷰어: "*LottoFactory와 LottoStore는 하는 역할이 겹쳐* 보이네요. 또, *자동 티켓을 만들 때마다 LottoFactory 객체를 생성하는 것은 불필요해* 보입니다 :) *객체 간 역할을 다시 생각해 보시고, 어느 한 쪽을 통폐합*하면 좋겠네요 🙂"
+
+### 4. `Rank.values()` *전부 채우고 필터* — 불필요 연산
+
+```kotlin
+val result = Rank.values().associateWith { 0 }.toMutableMap()
+lottos.forEach {. result[matchRank] = (result[matchRank] ?: 0) + 1 }
+return result.filter { it.value > 0 }
+```
+
+리뷰어: "*Rank.values()로 먼저 값을 채우지 않고 시도*해 보세요 :) *갯수를 0이 아닌 것을 필터링하더라도, 결국 불필요한 연산을 하고 있*습니다. 먼저, *1장의 티켓을 비교하는 메서드를 분리*해 보세요 :)"
+
+### 5. *`LottoStore` 테스트 size만 검증*
+
+리뷰어: "*LottoStore는 Lotto를 생성하는 객체이기에, size 뿐만 아니라 원하는 티켓을 생성했는지도 검증*해 보는 것은 어떨까요?"
+
+### 6. *멤버변수 vs 직접 상수 접근*
+
+리뷰어: "*멤버변수에 할당하기보다, 직접 LOTTO_PRICE를 접근*해 보는 것은 어떨까요?" — *불필요한 중간 변수*.
+
+### 7. `List<Lotto>` *일급 컬렉션화*
+
+리뷰어: "*List<Lotto>를 일급 컬렉션으로 만들어* 보세요 🙂"
+
+### 8. *내부 전용 메서드 private 처리*
+
+리뷰어: "*이 메서드는 이 객체에서만 쓰이니 private으로 가리거나, 통폐합*해 보는 것은 어떨까요?"
+
+### 9. `LottoStore` 책임 *현실 메타포 정리*
+
+리뷰어: "*LottoStore에서는 딱 로또의 발급 기능만 분리*해 보는 것은 어떨지 제안해 봐요 :) *발급받는 데 반드시 Money가 필요하다는 현실 세계의 반영이지만, 사실 발급기 그 자체에게는 돈이 필요하지 않지요* 😊" — *현실 비유의 깊이*: *돈 필요한 건 고객 입장, 발급기는 명령 받음*.
+
+### 10. *함수형 체이닝* 제안
+
+리뷰어:
+```kotlin
+return lottos.asSequence()
+.map { Rank.valueOf(it.countMatch(lotto), it.contains(bonusNumber)) }
+.groupingBy { it }
+.eachCount()
+.let { LottoResult(it) }
+```
+
+### 11. `assertAll` vs *여러 검증문*
+
+```kotlin
+assertThat(lottoTickets.size).isEqualTo(2)
+assertThat(lottoTickets[0].).isEqualTo(.)
+assertThat(lottoTickets[1].).isEqualTo(.)
+```
+
+리뷰어: "*검증문을 여러 개 쓰는 것과 assertAll로 감싸는 것은 어떤 차이점이 있을까요*?" 후속:
+```kotlin
+assertAll(
+    { assertThat(lottoTickets.size).isEqualTo(2) },
+    { assertThat(lottoTickets[0].toList().).isEqualTo(listOf(1, 2, 3, 4, 5, 6)) },
+    { assertThat(lottoTickets[1].toList().).isEqualTo(listOf(1, 11, 22, 33, 44, 45)) },
+)
+```
+— *Soft Assertion*: *한 검증 실패해도 나머지 실행*.
+
+### 12. 테스트 반복문 *가독성 해침*
+
+리뷰어: "*반복문으로 검증문을 실행하는 것은 가독성을 해칩니다. 어떤 시점에 어떤 값을 비교하는지 어렵기 때문*이에요. *사이즈와 숫자의 범위를 검증하는 것은 큰 의미를 갖기 어렵습니다. 실제로 생성한 lotto가 정확하게 예측된 값을 가지는지 비교*해 보는 것은 어떨까요?"
+
+### 13. *피드백 미반영* 후속 질문
+
+리뷰어: "*이 피드백은 조금 어려우셨을까요? 혹은 더 자세한 설명이 필요하신가요*?" — *대화 지속* 권유.
+
+## 리뷰어 의견 요지
+
+- **메서드 시그니처 = *최소 필요 정보***.
+- **`LottoStore` *변환 책임 위임***.
+- **`Factory` + `Store` *역할 중복 통폐합***.
+- **`Rank.values()` *불필요 사전 채우기***.
+- **테스트 *예측 값 비교*** (size만 X).
+- **상수 *직접 접근*** (중간 변수 X).
+- **`List<Lotto>` *일급 컬렉션***.
+- **내부 메서드 *private***.
+- **`LottoStore` = *발급 기능*** (Money는 호출자 책임).
+- **함수형 체이닝** — sequence + groupingBy + eachCount.
+- **`assertAll` *Soft Assertion***.
+- **테스트 반복문 *가독성 해침***.
+
+- **대표 인용:**
+  > 남은 돈을 구하기 위해서 *수동 티켓 전체가 필요할까요*? :)
+  > — @malibinYun on `src/main/kotlin/lotto/domain/Money.kt`
+
+  > 발급받는 데 *반드시 Money가 필요하다는 현실 세계의 반영이지만, 사실 발급기 그 자체에게는 돈이 필요하지 않지요* 😊
+  > — @malibinYun on `src/main/kotlin/lotto/domain/LottoStore.kt`
+
+  > 사이즈와 숫자의 범위를 검증하는 것은 큰 의미를 갖기 어렵습니다. *실제로 생성한 lotto가 정확하게 예측된 값을 가지는지 비교*해 보는 것은 어떨까요?
+  > — @malibinYun on `src/test/kotlin/lotto/domain/LottoStoreTest.kt`
+
+  > 이 피드백은 *조금 어려우셨을까요? 혹은 더 자세한 설명이 필요하신가요*?
+  > — @malibinYun (대화 지속 권유)
+
+## 얻은 교훈
+
+- **메서드 시그니처 = *최소 필요 정보*** — `manual: Lottos`보다 `manualCount: Int`. *과한 인자*는 *결합도*.
+- **`LottoStore` *변환 책임 위임*** — *이미 Lotto가 들어오는데 다시 변환*은 의미 약함.
+- **`Factory` + `Store` *역할 중복*** = *통폐합 또는 책임 분명화*.
+- **`Rank.values()` *사전 채우기 + 필터*** = 불필요. *직접 grouping + eachCount*가 자연.
+- **테스트 *예측 값 비교*** — *size만 비교*는 *어떤 값이 생성되었는지 명세 부재*. *Fake Generator*로 *결정적 결과*.
+- **상수 *직접 접근*** — *중간 멤버변수*는 *간접화 비용*.
+- **`List<Lotto>` *일급 컬렉션*** = 도메인 행위 부여.
+- **내부 메서드 *private*** — *외부 의도가 없다*는 신호.
+- **`LottoStore = 발급 기능*** — *Money는 호출자 책임* (현실: *고객이 돈 보유*, *발급기는 명령*). PR #131 (krrong) *Cashier 책임 흐름*과 같은 결.
+- **함수형 체이닝** — `sequence → map → groupingBy → eachCount → let { Result(it) }`.
+- **`assertAll` *Soft Assertion*** — *한 검증 실패해도 나머지 실행*. *모든 실패 한눈에 확인*.
+- **테스트 *반복문* 가독성 해침** — *어떤 시점*에 *어떤 값*인지 *추적 비용*. *명시적 케이스 분리*.
+- **`현실 비유의 깊이*** — `발급기에게는 돈이 필요하지 않다`는 *책임 흐름 분리*의 강력한 비유. PR #131 *Wallet 비대칭*과 같은 결.

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

@@ -0,0 +1,66 @@
+# PR #4 — [아크] 1단계 로또 (초창기 PR)
+
+- **Reviewee:** [@re4rk](https://github.com/re4rk)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/4
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 51
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` 값 객체**, 일급 컬렉션 delegation 시도.
+- **`RandomNumberGenerator` 인터페이스 (전략 패턴)**.
+- **`LottoFactory`로 생성 책임 분리**.
+
+## 못한 점 (설계 관점)
+
+### 1. 일급 컬렉션 delegation으로 — 불필요 메서드 노출
+
+```kotlin
+class Lotto(private val numbers: List<LottoNumber>) : List<LottoNumber> by numbers
+```
+
+> 일급 컬렉션을 delegation을 활용해서 구현해주셨네요! delegation을 활용하면, Lotto에서 필요한 메서드 뿐만 아니라 불필요한 메서드 까지도 갖게 됩니다. 일급 컬렉션에서는 필요한 메서드만 구현해보는 것은 어떨까요?
+
+→ delegation은 *전체 인터페이스 노출*. 일급 컬렉션의 본질 (선택적 메서드 노출)에 어긋남.
+
+### 2. `LottoNumber` 매번 새 인스턴스
+
+```kotlin
+val lottoNumbers = (1..45).map { LottoNumber(it) }  // ⚠ 매번 45개 생성
+```
+
+> 로또의 각 숫자를 객체로 표현해주셨네요! 로또 숫자를 만드는 경우는 얼마나 될까요? 동일한 숫자는 한 번만 만들고 재활용해 볼 수 있을까요?
+
+→ `flyweight` 패턴. LottoNumber.of(value) → 캐시에서 반환.
+
+### 3. `LottoResult`가 결과를 직접 만듦
+
+```kotlin
+class LottoResult(.) {
+    fun make(): Map<Rank, Int> =.  // ⚠ 외부 객체에서 결과 조립
+}
+```
+
+> 로또 당첨 결과를 만들어내는 것은 정말 LottoResult의 역할일까요? 필요한 기능을 가진 객체에게 메시지를 던져보는 것은 어떨까요?
+
+→ `WinningLotto` 또는 `Lottos`가 결과를 *생성*하고, `LottoResult`는 *결과를 표현*만.
+
+### 4. `List(count) {. }` 미활용
+
+```kotlin
+fun createLottos(count: Int): List<Lotto> {
+    val lottos = mutableListOf<Lotto>()
+    repeat(count) { lottos.add(createLotto()) }
+    return lottos
+}
+```
+
+→ `List(count) { createLotto() }` 한 줄.
+
+## 얻은 교훈
+
+- **일급 컬렉션 ≠ delegation**. delegation은 *전체 인터페이스 자동 위임* → "필요한 것만 노출"의 일급 컬렉션 원칙과 충돌.
+- **flyweight 패턴 = 고정 범위 값 객체의 재사용**. LottoNumber(1-45), Money 같은 동치성 객체.
+- **결과 *생성*과 *표현* 분리**. `WinningLotto`가 결과 *생성*, `LottoResult`는 *표현 단위*.
+- **`List(count) {. }` Kotlin builder** — `mutableListOf + add` 패턴의 idiomatic 대체.

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

@@ -0,0 +1,26 @@
+# PR #23 — [코비] 1단계 로또
+
+- **Reviewee:** [@rhkrwngud445](https://github.com/rhkrwngud445)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/23
+- **단계:** 1단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 11
+
+## 핵심 지적
+
+### 1. 멤버 변수 vs 생성자 주입
+
+> 멤버 변수는 모든 함수가 공통으로 접근해서 사용할 수 있는 장점이 있지만, 멤버 변수의 값에 따라 함수의 호출 결괏값이 달라.
+
+### 2. 함수 시그니처 단순화
+
+```kotlin
+fun initWinningLottoNumbers(lottoNumbers: List<Int>, bonusNumber: Int) {. }
+```
+
+→ 도메인 객체로 묶어 시그니처 단순화.
+
+## 얻은 교훈
+
+- **멤버 변수 → 생성자 주입** = 함수 결과 예측 가능성 ↑.
+- **여러 파라미터 = 도메인 객체로 묶기** (`WinningLottoInput`).