oh-my-oop 0.2.0

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

@@ -0,0 +1,149 @@
+# PR #144 — [포르] 2단계 로또
+
+- **Reviewee:** [@jiyuneel](https://github.com/jiyuneel)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/144
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @krrong
+- **라인 코멘트:** 16
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber.getAll()` 메시지화** — 학생 직접: "*객체에게 메시지를 던지는 연습을 꾸준히 해야 할 것 같네요..!* 🙂".
+- **`WinningLotto.getLottoResult(lottos)`** — *Tell, Don't Ask*. 리뷰어 칭찬: "*WinningLotto가 스스로 일을 할 수 있도록 만들었네요* 👏".
+- **`LottoCount` value class** — 리뷰어 칭찬: "*로또 개수 포장* 👏".
+- **`Lotto.of` (수동) vs `Lotto.create` (자동) 팩토리 분리** — 후속 라운드에서 의도 명확화.
+- **`LottoMachine` 인터페이스 + `ManualLottoMachine`/`AutomaticLottoMachine`** — Strategy. 리뷰어 칭찬: "*공통 로직을 인터페이스로 추상화* 💯".
+- **학생이 *시도 후 폐기*도 PR에 명시** — 일급 컬렉션 만들어 봤다가 *역할 없어 폐기*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto.create()` — *자동 발매기 책임을 Lotto가 가져감*
+
+```kotlin
+companion object {
+    fun create(): Lotto {
+        val lottoNumbers =
+            LottoNumber.NUMBERS.values
+.shuffled()
+.take(NUMBER_OF_LOTTO_NUMBERS)
+        return Lotto(lottoNumbers)
+    }
+}
+```
+
+리뷰어 (1차): "로또가 *스스로를 반환*한다? 저는 *조금 어색하게 느껴*지기도 해요! Lotto가 직접 Lotto를 만들어 반환하도록 만든 *이유는 무엇*인가요? 🤔" 학생 (1차): "*create 함수가 팩토리 함수로써 Lotto 인스턴스를 생성하는 역할*을 하도록 했습니다! private constructor를 사용하여." 리뷰어 (2차): "아하! 제가 코드를 잘못 이해했었던 것 같군요 🙇‍♂️ — *랜덤으로 6개의 번호를 선택해서 로또를 반환하는 일은 로또의 책임일까요*? *AutomaticLottoMachine이 할 일을 로또가 가져가버린 것처럼* 보여요! 🤔" — *팩토리의 자기 책임 검증*: *어떤 생성 정책*인가에 따라 *책임 위치 다름*. *랜덤 선택*은 발매기 책임.
+
+### 2. `LottoMachine.generate(lottoNumbers: List<List<Int>>? = null)` — *nullable 분기*
+
+```kotlin
+interface LottoMachine {
+    fun generate(
+        lottoCount: LottoCount,
+        lottoNumbers: List<List<Int>>? = null,  // ⚠ nullable 인터페이스
+    ): List<Lotto>
+}
+```
+
+학생 자가 의문: "*자동 발매기는 로또 개수만 필요하고, 수동 발매기는 로또 번호도 필요로 한다는 점*에서 *설계가 복잡*해진 것 같습니다. 결국 *lottoNumbers를 nullable로 선언*하고, *자동 발매기의 경우에는 lottoNumbers가 null*로 오도록 했습니다." 리뷰어: "*과연 로또 번호를 함수로만 넘길 수 있는 것일까*?에 대해 고민해 보면 답을 찾을 수 있을 것 같아요 🤠 *혼자 고민하는데 너무 많은 시간을 쏟지 마시고 어려우면 dm 남겨* 주셔도 됩니다요 😊" 학생: "로또 번호를 *수동 발매기의 생성자를 통해 넘겨주는 방식*으로 리팩터링해 봤습니다! 🤩"
+```kotlin
+class ManualLottoMachine(private val lottoNumbers: List<List<Int>>) : LottoMachine {
+    override fun generate(lottoCount: LottoCount): List<Lotto> {. }
+}
+```
+— *공통 인터페이스 = 공통 시그니처*. *분기 인자*는 *생성자로*.
+
+### 3. 인터페이스 추가 *협력 끌어올림* — 함수 주입
+
+리뷰어 후속 제안:
+```kotlin
+interface LottoMachine {
+   fun generate(count: LottoCount): List<Lotto>
+}
+
+class ManualLottoMachine(
+   private val getLottoNumbers: (List<Int>) -> Unit  // ⚠ 함수 주입
+): LottoMachine {
+  override fun generate(count: Int): List<Lotto> {
+     return List(count) { Lotto(getLottoNumbers()) }
+  }
+}
+```
+
+"*나중에 협력 관계를 끌어올린다면 다음처럼 작성*할 수도 있어요." — *함수형 인터페이스*로 *지연 입력*. 매번 *번호 입력*을 함수로.
+
+### 4. `List<Lotto>` *일급 컬렉션* 없음
+
+학생 자가 답변: "로또 리스트를 감싸는 *일급 컬렉션을 만드는 방법을 생각하고, 실제로 그렇게 구현도 해 봤었*습니다. 하지만 구현을 하고 나니, 해당 클래스가 *List<Lotto>를 감싸는 것 외에는 아무런 역할이나 책임이 없어서 결국 List를 사용*하게 되었습니다! 제가 *고려하지 못한 부분*이 있을까요..?!" 리뷰어 (균형 잡힌 답변):
+> List<Lotto>를 감싸면 간단하게만 생각해 봐도 아래와 같은 장점을 얻을 수 있을 거에요.
+> 1. *도메인 의미를 명확하게 전달*할 수 있다. (클래스명을 잘 지어야 하겠지만요 😅)
+> 2. 컬렉션에 대한 *불변성을 보장*한다. (개발자가 실수로 `MutableList<Lotto>`의 형태로 넘겨도 불변성을 보장)
+> 3. *확장성을 가질 수 있다*. (로또 묶음이 하는 일이 생겼을 때 일급 컬렉션에 로직만 추가하면 되니 변경이 좀 더 자유로움)
+> 
+> *하지만 언급한 것처럼 역할과 책임이 없기에 만들지 않는 것도 좋은 근거와 방법*이라고 생각해요 👏
+
+— *언제 일급 컬렉션을 만들지*는 *현재 행동* + *예상 확장*의 트레이드오프.
+
+### 5. `Lotto.lottoNumbers` *public 노출*
+
+```kotlin
+class Lotto(val lottoNumbers: List<LottoNumber>) {. }
+```
+
+리뷰어: "`LottoNumber`가 가지고 있는 값을 사용 사용하도록 잘 변경해 주었네요 👏 *너가 가진 번호 다 내놔라고 LottoNumber에게 메시지를 던져* 볼까요?" 학생: "*LottoNumber가 가지고 있는 로또 번호를 반환하는 getAll 함수*를 통해 값을 사용할 수 있도록 수정했습니다! *객체에게 메시지를 던지는 연습을 꾸준히 해야 할 것 같네요..!*" — *getter 호출* → *메시지*.
+
+### 6. `LottoStore.publish` — 네이밍
+
+```kotlin
+class LottoStore {
+    fun publish(.)  // ⚠ 발행
+}
+```
+
+리뷰어: "nit: *상점에서 판매한다 → sell*은 어떤가요? 🤔" 학생: "*sell이 판매한다는 의미를 나타내는 더 명확한 네이밍*인 것 같아서 변경했습니다!" — *현실 메타포 일치* (kiosk).
+
+### 7. 테스트 *assertj static import* 권장
+
+```kotlin
+Assertions.assertThat(lottos.size).isEqualTo(5)
+```
+
+리뷰어:
+```kotlin
+import org.assertj.core.api.Assertions.assertThat
+assertThat(lottos.size).isEqualTo(5)
+```
+
+## 리뷰어 의견 요지
+
+- **`Lotto.create()` = *발매기 책임을 도메인이 가져간 안티***. *랜덤 선택*은 *AutomaticLottoMachine*.
+- **인터페이스 인자는 *공통*만** — *분기 인자*는 *생성자*.
+- **함수 주입으로 *협력 끌어올림*** — Functional Interface.
+- **일급 컬렉션 = *트레이드오프*** — *현재 행동 없음 ↔ 미래 확장*.
+- **`.lottoNumbers` 노출 → *메시지*** — `lotto.contains(.)`.
+- **네이밍 = *현실 메타포***. `publish` → `sell`.
+- **assertj static import**.
+
+- **대표 인용:**
+  > 랜덤으로 6개의 번호를 선택해서 로또를 반환하는 일은 *로또의 책임일까요*? *AutomaticLottoMachine이 할 일을 로또가 가져가버린 것처럼* 보여요!
+  > — @krrong on `src/main/kotlin/lotto/domain/model/Lotto.kt`
+
+  > 자동 발매기는 로또 개수만 필요하고, 수동 발매기는 로또 번호도 필요로 한다는 점에서 설계가 복잡해진 것 같습니다. 결국 lottoNumbers를 nullable로 선언하고.
+  > — @jiyuneel on `src/main/kotlin/lotto/domain/service/LottoMachine.kt`
+
+  > 과연 *로또 번호를 함수로만 넘길 수 있는 것일까*?에 대해 고민해 보면 답을 찾을 수 있을 것 같아요 🤠
+  > — @krrong on `src/main/kotlin/lotto/domain/service/LottoMachine.kt`
+
+  > 하지만 언급한 것처럼 *역할과 책임이 없기에 만들지 않는 것도 좋은 근거와 방법*이라고 생각해요 👏
+  > — @krrong on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **`Lotto.create()`는 *책임 침범*** — *랜덤 6개 선택*은 *발매기*. *수동 입력 검증*만 `Lotto` 책임.
+- **공통 인터페이스 = 공통 시그니처** — *수동만 필요한 번호*를 *nullable*로 인터페이스에 넣으면 *자동도 신경 써야*. *생성자 차이*로 해결.
+- **함수 주입으로 협력 끌어올림** — `(Int) -> List<Int>` 같은 *지연 입력*은 *순서 의존*을 *호출 컨텍스트*에서 해결.
+- **일급 컬렉션 = *트레이드오프*** — *역할 없으면 List 사용*도 합리. 단 *불변성/확장성*은 일급 컬렉션 장점.
+- **`.numbers` 노출 → 메시지** — `lotto.numbers.contains(x)` → `lotto.contains(x)`.
+- **네이밍은 *현실 메타포*** — `publish` vs `sell`. *키오스크*에서 *판매*하는 게 자연.
+- **assertj `import static`** — `assertThat(x).isEqualTo(y)`가 *코드 시그널*.
+- **리뷰어의 *DM 제안*은 좋은 신호** — *왕복 4회 이상* 되면 *비동기 한계*. *동기 채널*로 이동.
+- **이미지 첨부/커밋 링크 활용** — 학생이 *5e0de6b 커밋 링크*를 댓글에 첨부.

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

@@ -0,0 +1,148 @@
+# PR #58 — [에디] 1단계 로또
+
+- **Reviewee:** [@junjange](https://github.com/junjange)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/58
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 31
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto` 중복/크기 검증** — `require`로 도메인 invariant 강제.
+- **`enum class Rank(countOfMatch, winningMoney)`** — 등수+상금 한 곳.
+- **`Range` 재활용** — `LOTTO_NUMBER_RANGE: IntRange = 1..45`.
+- **`Rank.valueOf(countOfMatch, matchBonus)` factory** — 매칭 → Rank 변환 캡슐화.
+- **리뷰 반영을 커밋 해시로 명시** — 변경 추적 용이.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller가 `","`로 split — View 책임 침범
+
+```kotlin
+private fun lottoDraw(): DrawResult {
+    val winningNumber = InputView.readWinningNumbers()
+    val winningLotto = Lotto((winningNumber.split(",").map { LottoNumber(it.trim()) }))
+.
+}
+```
+
+리뷰어: "`,`로 split된다는 내용은 view의 요구사항인데요. view의 요구사항이 바뀔 때 controller에 변경이 발생하는 것을 지양해야 할 것 같습니다!" — 입력 형식은 View 내부에서 *완성된 데이터*로 변환되어야 함.
+
+### 2. `LottoMachine(private val price: String)` — 도메인이 String 받음
+
+```kotlin
+class LottoMachine(private val price: String) {
+    init { require(price.toIntOrNull()?.let { it >= MIN_PRICE } == true) }
+}
+```
+
+리뷰어: "LottoNumber, LottoMachine 모두 String으로 넘겨주고 내부적으로 숫자로 타입 변환 및 검증을 처리하고 있는데요. price가 숫자 타입으로 '입력' 되었는지는 View에서 검증하는 것이 좀 더 적절하지 않을까요?" 학생 반박: "View는 입력만, 유효성 검사는 LottoMachine." → 후속 논의에서 *형식 검증 = View*, *비즈니스 검증 = Domain*으로 합의.
+
+### 3. `LottoResult.static` — Kotlin 예약어와 혼동되는 명명
+
+```kotlin
+class LottoResult(val static: Map<Rank, Int>) {. }
+```
+
+리뷰어: "kotlin이긴 하지만 static은 기본적으로 '정적 상태'를 의미하는 예약어로 많이 쓰이기 때문에 조금 혼동이 올 수 있을 것 같아요. 좀 더 적절한 네이밍으로 바꿔봐도 좋겠습니다." — `statistic`/`countByRank`.
+
+### 4. `LottoTicket` vs `Lotto` — 명명 혼동
+
+```kotlin
+fun getLottoTicket(): Int = price.toInt() / MIN_PRICE  // ⚠ 수량 반환인데 Ticket
+```
+
+리뷰어: "LottoTicket과 Lotto가 네이밍으로 봤을 때, 큰 차이를 알지 못할 것 같아요. 좀 더 적절한 이름은 없을까요~?" — 함수가 *수량*을 반환하면 `getLottoCount`.
+
+### 5. `OutputView`가 Rank 순회로 출력
+
+```kotlin
+fun printResult(lottoResult: LottoResult) {
+    println("당첨 통계"); println("---------")
+    Rank.entries.reversed().forEach { rank ->. }  // ⚠ Model 구조 가정
+}
+```
+
+리뷰어: "Rank를 순회하면서 출력하기보다, lottoResult의 결과를 바로 출력하는 것은 어떨까요? 현재 요구사항에서는 rank를 순회하면서 출력을 해도 차이가 없습니다. 다만, 이것은 View가 'LottoResult에는 모든 등수의 결과가 들어있다.'라는 model의 내부 구현을 암묵적으로 알고 있기 때문에 가능한 것으로 보여요. 만약 LottoResult 내부에 변경사항이 발생하면, View에도 변경사항이 발생할 텐데 이러한 의존관계는 줄여 보면 어떨까요?" → 학생 해결: `LottoResult.toString()`을 커스텀해 View는 *출력만*.
+
+### 6. `Lotto`가 `List<LottoNumber>` — Set이 더 적합
+
+```kotlin
+class Lotto(val lottoNumbers: List<LottoNumber>) {
+    init { require(lottoNumbers.distinct().size == LOTTO_SIZE) }
+}
+```
+
+리뷰어: "이미 중복 검증을 잘해 주셨는데, 추가적으로 같이 생각해 보면 좋을 부분이라 코멘트 남깁니다. lottoNumbers의 자료구조는 List인데, Set으로 바꾼다면 기본적으로 '중복을 허용하지 않는 자료구조'이므로 도메인의 의미상 좀 더 적절한 자료구조가 될 수 있습니다." — 자료구조가 *invariant 표현*.
+
+### 7. `LottoAnalyzer` class vs object
+
+```kotlin
+class LottoAnalyzer(private val lottos: List<Lotto>, private val drawResult: DrawResult) {. }
+```
+
+리뷰어: "class와 object를 사용하시는 기준이 있으실까요? 해당 클래스를 object로 전환하는 것이 적절할까요? 적절하다면 (혹은 그렇지 않다면) 이유는 무엇일까요?" 학생: "class의 생성자를 메서드의 파라미터로만 사용하고 있어 상태를 가지지 않고, 해당 class는 랭크를 통계 내는 기능만 하므로 object로 바꾸는 것이 더 적절." → `object`로 변환 + `calculateResult` 사용처 객체로 이동.
+
+### 8. `LottoMachine` class — 학생도 동일 결론
+
+학생: "LottoMachine을 object로 선언했을 때, 하나의 인스턴스만 생성되므로 메모리 측면에서 장점이 있을 것 같습니다. … LottoMachine은 price를 의존하고 있지만, price는 getNumberOfLottoTickets() 메서드에서만 사용되고 있고 LottoMachine이 price의 상태를 가지고 있을 필요가 없기 때문에 object로 바꾸는 게 더 적합." — *상태 없음*이 명확하면 `object`.
+
+### 9. `Rank.valueOf` 매번 분기
+
+```kotlin
+fun valueOf(countOfMatch: Int, matchBonus: Boolean): Rank {
+    if (countOfMatch == THIRD.countOfMatch && !matchBonus) return THIRD
+    return entries.find { it.countOfMatch == countOfMatch } ?: MISS
+}
+```
+
+리뷰어: "현재는 보너스 번호 때문에 Rank, LottoResult 등의 클래스에서 매번 분기 처리가 필요한 상황인데요. 앞으로도 보너스 번호와 관련된 클래스는 모두 이러한 분기 처리가 들어가야 하고, 이는 추후에 변경사항이 발생할 경우 리소스가 많이 드는 작업이 될 수 있을 것 같아요. 분기 처리 없이 등수를 구하도록 리팩토링 해 볼 수 있을까요?" 학생: "RankState라는 enum class에서 일반 당첨, 보너스 당첨, 미당첨을 구분." 리뷰어 후속: "Rank와 RankState는 잘 보면 유사한 점이 많습니다. matchBonus를 Rank에서 다룬다면 두 클래스를 잘 병합해 볼 수도 있지 않을까요?" — *분기 → 별도 enum* → *두 enum 병합*의 의사결정 흐름.
+
+### 10. `Rank` 테스트 일부만
+
+```kotlin
+class RankTest {
+    @Test fun `5개 일치 + 보너스 → 2등`() {. }
+    @Test fun `5개 일치 → 3등`() {. }
+    // 1, 4, 5등, MISS 누락
+}
+```
+
+리뷰어: "나머지 등수는 테스트하지 않으신 이유가 있을까요?" 학생: "3등을 구하는 로직이 어려울 수 있다고 판단하여 3등과 그 외 다른 2개의 테스트 코드를 작성." → 학생 보강 (1등~MISS 모두).
+
+### 11. 일급 컬렉션 `Lottos` 부재
+
+리뷰어: "요구사항 중 하나인 일급 컬렉션을 Lotto 리스트에 적용해 볼 수 있을 것 같아요~!" — `List<Lotto>` 자체를 `Lottos`로 감싸면 *발행물의 집합*이 자기 행위를 가질 수 있음.
+
+## 리뷰어 의견 요지
+
+1. **View 요구사항(`,` split, 형식 변환)이 Controller로 누수되지 말 것** — 입력 형식 변경이 *Controller*까지 영향 가면 책임 경계 깨짐.
+2. **자료구조 = invariant 표현** — `Set`이 도메인 의미를 더 잘 담을 수 있다면 `List` 대신.
+3. **`object` vs `class`** — *상태 없음*이 확실하면 `object`. 메모리 절약은 부차적.
+4. **분기 처리 흩어짐 = 새 enum 등장 신호** — `Rank.SECOND`/`THIRD` 분기가 여러 곳에 나타나면 `RankState` 같은 *새 분류*가 필요.
+5. **결과 객체의 *자기 출력 표현*** — `LottoResult.toString()`을 정의해 View가 *순회 책임*에서 자유로워짐.
+6. **명명은 *도메인 예약어*와 겹치지 않게** — `static`은 Kotlin/Java 키워드 인식.
+
+- **대표 인용:**
+  > `,`로 split된다는 내용은 view의 요구사항인데요. view의 요구사항이 바뀔 때 controller에 변경이 발생하는 것을 지양해야 할 것 같습니다!
+  > — @vagabond95 on `src/main/kotlin/lotto/controller/LottoGameController.kt`
+
+  > 이것은 View가 'LottoResult에는 모든 등수의 결과가 들어있다.'라는 model의 내부 구현을 암묵적으로 알고 있기 때문에 가능한 것으로 보여요.
+  > — @vagabond95 on `src/main/kotlin/lotto/view/OutputView.kt`
+
+  > 분기 처리 없이 등수를 구하도록 리팩토링 해 볼 수 있을까요?
+  > — @vagabond95 on `src/main/kotlin/lotto/model/Rank.kt`
+
+  > Set으로 바꾼다면 기본적으로 '중복을 허용하지 않는 자료구조'이므로 도메인의 의미상 좀 더 적절한 자료구조가 될 수 있습니다.
+  > — @vagabond95 on `src/main/kotlin/lotto/model/Lotto.kt`
+
+## 얻은 교훈
+
+- **View 형식(`,` split, String→Int)은 Controller로 누수 X**. 입력 *형식 변경*이 도메인 변경으로 이어지면 책임 경계 미설계 신호.
+- **자료구조가 *invariant*를 표현** — `Set<LottoNumber>`이면 *중복 불가*가 타입에 명시. 외부에서 *불필요한 중복 검사*가 사라짐.
+- **`object` = *상태 없음 + 단일성* 단언**. 메모리 절약이 아니라 *의미*가 1차 동기.
+- ***분기가 여러 곳에 흩어지면 새 enum 등장 신호*** — `Rank`에 매번 `if (bonus)`가 붙으면 `RankState`/`BonusMatched` 같은 *새 분류*가 떠오름. 그 후 *원래 enum과 병합*도 검토.
+- **결과 객체의 *자기 표현*** — `toString()` 커스텀으로 View 책임 줄이기. 단, 출력 형식이 자주 바뀌면 *별도 Formatter*가 더 자유로움.
+- **자료구조 선택은 *컬렉션 무조건 List*가 아님** — Set/Map/List의 도메인 의미를 의식.
+- **이름이 Kotlin/Java *예약어와 닮음*** — 의도 전달에 마찰. `static`은 *정적*을 떠올리게 함.
+- **테스트는 *모든 분기*를 명세서로** — *어려운 경우만* 테스트 작성하면 *남은 분기*는 미보장.

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

@@ -0,0 +1,178 @@
+# PR #81 — [로또] 에디 2단계 미션
+
+- **Reviewee:** [@junjange](https://github.com/junjange)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/81
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 32
+
+## 잘한 점 (설계 관점)
+
+- **`sealed class GameState`** — 게임 흐름을 상태 패턴으로 표현.
+- **`ErrorCode` enum + `ExceptionsHandler`** — 검증 로직 공통화 시도.
+- **`LottoBundle.append(other)`** — 자동/수동 로또를 *컬렉션*이 직접 합치는 행위.
+- **`LottoMachine`을 `object`로 복귀** — 상태 없음에 맞는 선택.
+- **`Kiosk + Deposit + Record`로 리팩토링** — 사용자 흐름(잔액 + 거래 기록)을 한 객체로 통합.
+- **`MatchResult` = wrapping → 행위 보유 객체로 진화** — 리뷰어 칭찬.
+
+## 못한 점 (설계 관점)
+
+### 1. 함수명에 `And` — 두 책임 신호
+
+```kotlin
+private fun getLottoBundleAndDrawResult(): Result<LottoResponse> =.
+```
+
+리뷰어: "네이밍에 And가 들어간다는 것은 해당 함수가 2가지 이상의 역할을 수행한다는 신호인데요. 함수당 한 가지 역할만 수행하도록 개선 가능할까요?"
+
+### 2. `LottoManualPurchase` vs `LottoManualPurchaseCount`
+
+```kotlin
+data class LottoManualPurchase(val count: Int) {. }
+```
+
+리뷰어: "`LottoManualPurchaseCount(val count: Int)`에 더 가까울 것 같습니다!" — 클래스명에 *count*가 빠지면 *수동 구매 자체*인지 *수동 구매 수*인지 모름.
+
+### 3. 상수 중복 — `LottoMachine`/`Lotto`/`LottoNumber`
+
+```kotlin
+class LottoMachine(.) {
+    companion object {
+        private const val LOTTO_SIZE = 6                      // ⚠ Lotto가 이미 보유
+        private val LOTTO_NUMBER_RANGE: IntRange = 1..45      // ⚠ LottoNumber가 이미 보유
+    }
+}
+```
+
+리뷰어: "해당 상수들은 이미 다른 모델에서 선언되어 있는 상수로 보여요. 상수 선언의 중복을 제거해 볼 수 있을까요?" — *상수의 소유*는 한 곳, 다른 곳은 import.
+
+### 4. `createLottoBundle(lottoManualPurchaseNumbers: List<List<String>>,.)` — 이중 컬렉션
+
+```kotlin
+fun createLottoBundle(
+    lottoManualPurchaseNumbers: List<List<String>>,
+    lottoPurchaseCount: LottoManualPurchase,
+): LottoBundle {. }
+```
+
+리뷰어: "이중 컬렉션은 쉽게 타입을 유추하기 어렵게 만드는데요. 일급 컬렉션으로 한번 감싸주는 것은 어떨까요?" — `ManualPurchaseLottos` 같은 일급 컬렉션으로.
+
+### 5. 같은 의미 상태가 두 인자로 분리됨
+
+```kotlin
+fun createLottoBundle(manualPurchaseLottos: ManualPurchaseLottos, lottoManualPurchaseCount: LottoManualPurchaseCount): LottoBundle
+```
+
+리뷰어: "manualPurchaseLottos에서 lottoManualPurchaseCount 값을 추출해 낼 수 있지 않을까요? 같은 의미를 가지는 상태는 최대한 재사용해 보면 좋을 것 같아요!" — `manualPurchaseLottos.size`로 충분.
+
+### 6. `LottoMachine.getRandomLottoCount` 호출 무제한 + `price` 불변
+
+```kotlin
+class LottoMachine(private val price: Price) {
+    fun getRandomLottoCount(.): Int {
+        val randomLottoCount = price.getNumberOfLottoTickets() - lottoPurchaseCount.count
+.
+    }
+}
+```
+
+리뷰어: "getRandomLottoCount의 호출에는 제한이 없는데, price는 생성 시에만 주입을 받으므로 로또를 구매했을 때 price 값도 차감되어야 논리적으로 맞지 않을까요~? 추후에 수동으로 로또를 언제든지 구매할 수 있는 요구사항이 추가될 경우 버그가 발생할 수 있는 부분일 것 같아요." — Kiosk 패턴(잔액 추적)으로 발전.
+
+### 7. `LottoAnalyzer.calculateResult` — `MatchResultResponse`의 책임
+
+```kotlin
+object LottoAnalyzer {
+    fun calculateResult(matchResultResponse: MatchResultResponse): LottoResult {. }
+}
+```
+
+리뷰어: "calculateResult 내에서 진행되는 로직은 MatchResultResponse 클래스가 '스스로' 수행할 수 있는 동작 아닐까요~? MatchResultResponse 클래스의 역할이 파편화되었다고 볼 수도 있을 것 같아요!" — *Analyzer*는 *대상 객체에 행위*가 있을 때 잉여.
+
+### 8. `Price.plusPrice(strMoney: String)` — 시그니처 불일치
+
+```kotlin
+data class Price(val money: Int = DEFAULT_MONEY) {
+    fun plusPrice(strMoney: String): Price {. }  // ⚠ String
+    fun minusPrice(): Price {. }                  // ⚠ 인자 없음
+}
+```
+
+리뷰어 ①: "생성자에서는 Int를 전달받고 있는데, plus에서는 String 타입을 받는 구조가 일관성이 없어 보여요." ② "plusPrice가 실제로 더해지고자 하는 값을 받는다면, minusPrice도 동일한 규칙으로 빼고자 하는 값을 인자로 받는 것이 일관성이 있을 것 같아요." ③ "kotlin에서는 `operator` 라는 키워드를 이용하여 산술 연산자 오버라이딩이 가능하므로 이번 기회에 활용해 봐도 좋을 것 같아요." → `operator fun plus(other: Int)`.
+
+### 9. `Price`가 `Lotto`에 의존 (`getRandomLottoCount`/`getNumberOfLottoTickets`)
+
+```kotlin
+data class Price(val money: Int) {
+    fun minusPrice(): Price = copy(money = money - getNumberOfLottoTickets() * MIN_PRICE)
+}
+```
+
+리뷰어: "이러한 구조가 가능한 이유는 Price가 `getRandomLottoCount`, `getNumberOfLottoTickets`와 같이 Lotto에 대한 의존성을 가지고 있기 때문이에요. 그런데, 잘 생각해 보면 '가격'과 '로또' 중에 어느 것이 더 상위 개념일까요? 다르게 얘기하면 로또가 가격에 대한 정보를 알고 있는 것과 가격이 로또에 대한 정보를 알고 있는 것 중 어느 것이 더 자연스러울까요?" — *상위 개념(가격)*이 *하위 개념(로또)*을 알지 말 것.
+
+### 10. `Deposit.minus`가 음수 검증 누락
+
+```kotlin
+operator fun minus(other: Int): Deposit = copy(money = Money(money.value - other))
+```
+
+리뷰어: "예치금의 개념이라면 빼고자 하는 값이 현재 남은 금액보다 큰 경우 즉, 마이너스가 되는 상황이 발생할 때의 예외처리가 필요하지 않을까요~?" — 도메인 invariant 누락.
+
+### 11. `addDeposit + recordPurchase`가 *외부에서 강제됨*
+
+```kotlin
+kiosk.addDeposit(money)
+kiosk.recordPurchase(money)
+```
+
+리뷰어: "이 과정이 항상 같이 수행되어야 한다면, kiosk 내부에서 한번에 처리해 주는 것은 어떨까요? 개별 스탭을 외부에서 처리해야 할 경우 이러한 사항을 놓칠 수 있고 또 구현상으로도 강제하기 어려워 의도하지 않은 동작을 유발시키기 쉬울 것 같아요." — *호출 순서 강제*는 *외부 컨벤션*이 아니라 *내부 캡슐화*.
+
+### 12. 중앙 `ErrorCode` enum
+
+```kotlin
+enum class ErrorCode(val status: Int, val reason: String) {. }
+```
+
+리뷰어: "에러코드 정리 👍. 그런데, 서비스가 커질수록 모든 에러코드를 한 곳에서 관리했을 때 생길 수 있는 단점도 추후에는 같이 고려가 되면 좋을 것 같아요!" — 중앙 enum이 *god-folder*가 될 위험.
+
+### 13. `sealed class GameState` 선택 — Enum/Sealed Interface와의 비교
+
+리뷰어: "Enum, Sealed Interface를 활용해도 동일한 목적으로 활용이 가능한데요, 각각 선택하는 기준에 대해 생각해 보면 좋을 것 같습니다." — 학습 방향 제시.
+
+## 리뷰어 의견 요지
+
+1. **함수명에 `And` = 두 책임 신호** — 분리.
+2. **상수 중복 = 소유권 모호** — Lotto 정체성은 Lotto, LottoNumber 정체성은 LottoNumber.
+3. **이중 컬렉션은 일급 컬렉션으로 감싸기** — 의도 명시.
+4. **시간에 따라 변하는 상태 = 객체 생성자에 박아두지 말 것** — Kiosk/Deposit 패턴으로 잔액 추적.
+5. **연산 인터페이스 *일관성*** — `plus(Int)` + `minus(Int)` + `operator`.
+6. **상위 개념이 하위 개념을 모르게** — Price가 Lotto를 알면 의존 방향 역전.
+7. ***항상 같이 수행*되는 절차는 *외부에서 강제하지 말 것*** — 내부 캡슐화로 호출자 부담 제거.
+8. **중앙 enum = god-folder 위험** — 도메인별 분리 검토.
+9. **단순 wrapping → 행위 보유로 진화** — `MatchResult` 칭찬.
+
+- **대표 인용:**
+  > 네이밍에 And가 들어간다는 것은 해당 함수가 2가지 이상의 역할을 수행한다는 신호인데요.
+  > — @vagabond95 on `src/main/kotlin/lotto/controller/LottoGameController.kt`
+
+  > 잘 생각해 보면 '가격'과 '로또' 중에 어느 것이 더 상위 개념일까요? 다르게 얘기하면 로또가 가격에 대한 정보를 알고 있는 것과 가격이 로또에 대한 정보를 알고 있는 것 중 어느 것이 더 자연스러울까요?
+  > — @vagabond95 on `src/main/kotlin/lotto/model/Price.kt`
+
+  > 이 과정이 항상 같이 수행되어야 한다면, kiosk 내부에서 한번에 처리해 주는 것은 어떨까요? 개별 스탭을 외부에서 처리해야 할 경우 이러한 사항을 놓칠 수 있고…
+  > — @vagabond95 on `src/main/kotlin/lotto/controller/LottoGameController.kt`
+
+  > calculateResult 내에서 진행되는 로직은 MatchResultResponse 클래스가 '스스로' 수행할 수 있는 동작 아닐까요? MatchResultResponse 클래스의 역할이 파편화되었다고 볼 수도 있을 것 같아요!
+  > — @vagabond95 on `src/main/kotlin/lotto/model/LottoAnalyzer.kt`
+
+## 얻은 교훈
+
+- **함수명에 `And`/`Or`는 *2개 이상 책임* 신호**. 분리하거나 *목적*을 새 명사로.
+- **상수의 *소유권*은 한 곳**. 중복 선언은 *변경 시 양쪽 모두 잊을 위험*.
+- **이중 컬렉션 = 의도 모호** — 일급 컬렉션으로 *무엇의 모음인지* 명시.
+- ***같은 의미의 상태*는 *하나의 인자*** — `manualPurchaseLottos`가 이미 count를 안다면 따로 받지 말 것.
+- **시간에 따라 변하는 상태는 *객체 생성자*에 박지 말 것**. Price가 *최초 입력값*만 알고 있다면 잔액 추적 불가 → Kiosk/Deposit으로 *시간 흐름* 표현.
+- **연산자 시그니처 *일관성*** — `plus(Int)` + `minus(Int)` + `operator`. 한쪽만 인자 없으면 *외부에서 빼는 값을 알 수 없음*.
+- **상위 개념이 하위 개념을 알지 말 것**. *가격*이 *로또*를 알면 의존 방향 역전 — 로또가 가격을 알아야 자연.
+- **항상 같이 수행되는 절차는 *내부 캡슐화*** — 호출자가 *두 번 호출*해야 한다면 빠뜨릴 위험.
+- **중앙 enum은 god-folder 위험** — 도메인별 sealed/예외 분리도 옵션.
+- **단순 wrapping → 행위 보유 객체로 진화**. wrapping만 하던 객체가 행위를 갖기 시작하면 *진짜 객체*가 됨.
+- ***Enum vs Sealed class vs Sealed interface*** — 학습 시드. *상태가 데이터를 보유* 하면 sealed, *순수 분류*면 enum.

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

@@ -0,0 +1,153 @@
+# PR #120 — [로또 1단계] 공백 미션 제출합니다
+
+- **Reviewee:** [@junseo511](https://github.com/junseo511)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/120
+- **단계:** 1단계
+- **리뷰어:** @krrong
+- **라인 코멘트:** 71
+
+## 잘한 점 (설계 관점)
+
+- **`Rank` enum + `matchBonus: Boolean = false` 기본값** — 2등에만 보너스 필드 적용 시도.
+- **PR 본문에 명확한 자가 의문 다수** — TDD 커밋 단위, LottoNumber 필요성, `matchBonus` 기본값 처리 등.
+- **README 체크박스 활용** — 진행 상태 시각화.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto`가 너무 많은 일
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    init {
+        validateLottoNumbersCount(numbers)
+        validateLottoNumbersRange(numbers)
+        validateLottoNumbersDuplicate(numbers)
+    }
+
+    private fun validateLottoNumbersCount(numbers: List<Int>) {
+        require(numbers.size == LOTTO_NUMBER_SIZE) {. }
+    }
+
+    private fun validateLottoNumbersRange(numbers: List<Int>) {
+        require(numbers.all { it in 1..45 }) {. }
+    }
+    // + 중복 검증
+    // + 등수 계산
+    // + 보너스 비교
+}
+```
+
+학생 의견:
+
+> LottoNumber class를 따로 만들어서 번호에 대한 검증을 진행하더라구요?! 저는 근데 가지고 있는 로또 번호들을 Lotto에서 검증해도 괜찮다고 생각합니다. 오히려 너무 class를 보기 위해 가는 길이 가독성을 떨어지게 만드는 느낌이더라구요.
+
+리뷰어 답변:
+
+> 하지만 `Lotto`클래스가 하는 일이 많아지지 않을까요?
+>. 로또에서 사용하는 숫자는 Int 타입인데요. 외부에서 가져온 이 숫자들이 로또 번호라는 것을 어떻게 알 수 있을까요?
+> ```kotlin
+> val lotto = Lotto(.)
+> val number = lotto.numbers.first()
+> foo(number)
+> 
+> fun foo(number: Int) {
+>     // number가 로또 번호가 맞나? 검증을 해야할까?
+> }
+> ```
+
+→ 가독성과 타입 안전성의 trade-off — Lotto 외부로 *Int를 노출*하면 호출자가 매번 "이게 로또 번호인가?" 의심.
+
+### 2. `Rank`의 `matchBonus` 처리 — 5개 일치 SECOND에만 적용
+
+```kotlin
+enum class Rank(
+    val countOfMatch: Int,
+    val winningMoney: Int,
+    val matchBonus: Boolean = false,
+) {
+    MISS(0, 0),
+    FIFTH(3, 5_000),
+    FOURTH(4, 50_000),
+    THIRD(5, 1_500_000),
+    SECOND(5, 30_000_000, true),  // ⚠ 5개 일치 둘 중 보너스 일치만 SECOND
+    FIRST(6, 2_000_000_000),
+    ;
+
+    companion object {
+        fun fromMatchResult(countOfMatch: Int, matchBonus: Boolean): Rank {
+            // 복잡한 분기 로직.
+            throw IllegalArgumentException(.)
+        }
+    }
+}
+```
+
+학생 의문:
+
+> Rank를 반환하는 과정에서 SECOND일 때 boolean값을 기본으로 가지게 했습니다. 근데 6개 중에서 SECOND만 예외를 둬야 하는 로직 말고도 더 괜찮은 방법이 있을까요?
+
+리뷰어 답:
+
+> `Rank`는 정말 `matchBonus`가 필요할까요?
+
+→ **답:** 보너스 일치 정보는 Rank의 *속성*보다 Rank를 *찾는 데 쓰는 입력*. `Rank.matchBonus` 필드 자체가 어색.
+
+리뷰어가 준 힌트:
+
+```kotlin
+return entries.find { it.countOfMatch == countOfMatch && it.matchBonus == matchBonus } ?: MISS
+```
+
+→ `IllegalArgumentException` 없이 MISS로 fallback.
+
+### 3. 테스트 assertion 길게
+
+```kotlin
+import org.junit.jupiter.api.Assertions
+Assertions.assertEquals(5, lottoQuantity)  // ⚠ 길게
+```
+
+→ `import..assertEquals` 후 `assertEquals(5, lottoQuantity)`.
+
+### 4. PR 본문의 TDD 커밋 의문
+
+학생:
+
+> feat부터 커밋을 날려야 하는가? -> 진행한건 test부터 작성했는데 왜 feat부터 만들어야 하지?
+> test부터 커밋을 날려야 하는가? -> test부터 날린 상태로 빌드를 돌리면 컴파일 에러가 발생할 텐데 왜 test부터 날리는거지?
+
+리뷰어 답:
+
+> 저의 선호도는 **세 번째**(feat과 test를 함께 커밋한다)인데요.  
+> 100개의 기능을 TDD로 구현할 때 200개의 커밋 vs 100개의 커밋, 리뷰어가 어떤 PR이 리뷰하기 편할까요?
+
+→ TDD = *테스트 주도 사고*. 커밋은 *완결된 단위*.
+
+## 리뷰어 의견 요지
+
+리뷰어 @krrong (racingcar에서도 reviewee였던 사람이 lotto에서 reviewer로!):
+
+1. **`LottoNumber` 도메인 추출 — 가독성 vs 타입 안전성**. 가독성 떨어진다는 학생 의견에 *호출처 의심 비용*으로 반박.
+
+2. **`Rank.matchBonus` 필드의 어색함** — Rank의 *속성*인지 *찾기 입력*인지 구분.
+
+3. **TDD 커밋 단위 = 완결된 기능 단위** — test/feat 분리는 *과정 기록*이지 *리뷰 단위*가 아님.
+
+4. **`Rank` 검색에서 예외 던지지 말고 MISS fallback**.
+
+- **대표 인용:**
+  > 하지만 `Lotto`클래스가 하는 일이 많아지지 않을까요? 로또 번호인지 검증도 해야하고, 몇 등인지 계산도 해야하고.
+  >
+  > — @krrong on `src/main/kotlin/lotto/model/Lotto.kt`
+
+  > `Rank`는 정말 `matchBonus`가 필요할까요?
+  >
+  > — @krrong on `src/main/kotlin/lotto/model/Rank.kt`
+
+## 얻은 교훈
+
+- **LottoNumber 추출의 진짜 가치 = *호출처가 의심하지 않게***. 외부에 `Int` 노출 = 매번 "이게 로또 번호 맞나?" 의심. 타입이 정답.
+- **enum 필드의 분류 — *속성* vs *검색 키***. `matchBonus`는 Rank가 *되는 조건*이지 *Rank의 본질 속성*이 아님. enum 필드는 *영구한 속성*만.
+- **MISS/NONE fallback > Exception**. enum이 전 케이스를 표현하면 *예외 던질 일 없음*. `find {. } ?: MISS`.
+- **TDD 커밋 단위 = "다른 사람이 리뷰 가능한 단위"**. 테스트만 있는 커밋은 빌드 실패. 둘을 합치면 *완결된 기능*.
+- **이전 reviewee가 다음 라운드 reviewer로** — racingcar 학생 krrong이 lotto에서 어떻게 학습한 걸 리뷰로 돌려주는지 패턴을 보여주는 PR.