oh-my-oop 0.2.0

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

@@ -0,0 +1,166 @@
+# PR #49 — [써니] 2단계 로또
+
+- **Reviewee:** [@inseonyun](https://github.com/inseonyun)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/49
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @namjackson (잭슨)
+- **라인 코멘트:** 17
+
+## 잘한 점 (설계 관점)
+
+- **`Lottos.operator fun plus`** — 컬렉션 결합을 *연산자*로. 리뷰어 칭찬: "operator 👍 👍".
+- **`PurchaseMoney`, `LottoCount`, `LottoPrice`, `LottoTicket`** — 원시값 포장 4개.
+- **`tryAndRerun` 유틸** — *입력 실패 시 재시도*를 한 곳에서.
+- **Controller 슬림화** — 후속 라운드에서 잭슨이 "Controller 내의 코드가 많이 줄었네요 👍 👍" 인정.
+
+## 못한 점 (설계 관점)
+
+### 1. 자동 로또 수 계산 = *Controller*에서 수행
+
+```kotlin
+// World.kt
+private fun initLottos(purchaseLottoCount: LottoCount, manualLottoCount: LottoCount): Lottos {
+    val store = LottoStore()
+    val autoLottoCount = purchaseLottoCount.calculateAutoLottoCount(manualLottoCount)
+    val manualLottos = store.buyManualLotto(manualLottoCount.value, *initManualLotto(manualLottoCount))
+    val autoLottos = store.buyAutoLotto(autoLottoCount.value)
+    val totalLottos = store.mergeLottos(manualLottos, autoLottos)
+.
+}
+```
+
+리뷰어: "자동 로또를 *몇 장 사는지에 대한 부분은 money와 manualLottoCount를 입력받은 LottoStore에서 계산*되어야 하는 작업이 아닐까요?" + "store에서 값을 받아와서, Controller에서 처리하기보단, *Store에게 책임을 주어, 내부적으로 동작이 처리되게 메시지를 전달*해 보아도 좋을 거 같아요! Store에 PurchaseMoney, Array<Lotto>의 정보만 있다면, *수동 로또와 자동 로또를 반환할 수 있지 않을까요*?" — *Tell, Don't Ask*.
+
+### 2. InputView vs OutputView vs 화면 단위 — 학생 자가 의문
+
+학생: "입력을 위한 문구 출력의 경우 현재 *컨트롤러에서 inputView의 함수를 호출할 때 같이 호출*하며 사용하고 있는데, *InputView 클래스 내의 함수에서 OutputView를 호출*해줘도 문제 되지 않는지 궁금합니다." 리뷰어: "View라는 것은 *입출력을 모두 포함*하기 때문에, InputView, OutputView로 나뉘어서, InputView에선 입력만 받고, OutputView에선 출력만 받는 역할을 분리하게 되어, *View에 대한 정의가 모호*해진 것 같아요. *입/출력이라는 기능으로 분리하는 것이 아니라, 화면 단위나 행위 단위로 나눠* 보는 건 어떨까요? InputView에서는 *유저의 로또 정보를 입력을 받는 단계의 UI*를, OutputView에서는 *로또 결과 출력을 하는 단계의 UI*로 분리." — *입력/출력의 기능 분리*가 *행위 단위 분리*에 비해 응집도 낮음.
+
+### 3. View에서 *반복 입력* vs 도메인 검증 — 학생 자가 의문
+
+학생: "입력에 대한 예외와 반복 입력을 View에서 진행하고, *원시값 포장과 이에 따른 검증을 도메인에서 진행*하게 됐을 때, *그 검증 예외의 경우도 반복 입력*을 수행해 정상적인 값을 받도록 해야 할지, 아니면 프로그램이 종료되도록 할지 고민입니다." 리뷰어: "요구사항이 명확하지 않기 때문에 *선택의 문제*라고 생각합니다! 반복 입력을 수행하게 된다면, ux적으로는 좋지만, *입력값이 아닌 다른 에러들까지 반복이 실행될 가능성*도 있고, *입력으로 인한 에러가 아닌 다른 에러가 발생했을 때의 통일성*에 대한 부분도 고려해야 할 부분이라고 생각이 들어요. 사실 입력 값에 대한 부분인 만큼, *입력받는 View에서도 검증을 하는 게 깔끔*하기도 해요. 현업에서는 *명확한 요구사항과 명세서가 작성되어야 하기도 하고, 관련된 담당자들과의 의사소통으로 결정*되는 부분도 있지만, 로또 프로그램은 미션이니 만큼 *자유롭게 구현*하셔도 좋을 거 같습니다!" — *시스템 경계*는 *명세서*에 의존.
+
+### 4. `Array<Lotto>`는 무엇? — *발행 전 티켓* 모델링
+
+```kotlin
+private fun initManualLotto(manualLottoCount: LottoCount): Array<Lotto> {. }
+```
+
+리뷰어: "Array<Lotto>는 무엇을 의미하는 것일까요? 얼핏 보았을 때 *Lottos와 무엇이 다를까 고민이 생길 것* 같아요. *발행하기 전 로또라면, LottoTicket 같은 클래스*를 만들어보면 어떨까요?" + (InputView 내): "Lotto 생성에 대한 *책임은 LottoStore의 ManualLottoGenerator에게 위임*해 보면 어떨까요? 아직 *발행 전 티켓은 LottoTicket과 같은 클래스로 전달*되어도 좋을 거 같단 생각이 들어요!" — *상태가 다른 객체*는 *다른 타입*.
+
+### 5. View가 *구매 가능 매수* 계산
+
+```kotlin
+private fun readManualLottoCount(purchaseMoney: Int): Int {
+    val input = readln()
+    require(input.toIntOrNull() != null) { ERROR_MESSAGE_ONLY_NUMBER }
+    if (input.toInt() != 0)
+        require((purchaseMoney / (input.toInt() * LottoPrice.DEFAULT_LOTTO_PRICE) > 0)) { ERROR_MESSAGE_AVAILABLE_COUNT }
+    return input.toInt()
+}
+```
+
+리뷰어: "계산되는 로직은 *도메인 로직으로 이동*해 보면 어떨까요? *구매 가능한 로또는 purchaseMoney에서 관리*되어도 좋을 거 같아요!" — *View의 검증*은 *형식*만, *비즈니스 규칙*은 도메인.
+
+### 6. `data class` vs 일반 class — 학생 자가 의문
+
+```kotlin
+class Lotto private constructor(private val numbers: Set<LottoNumber>) {
+    override fun hashCode(): Int = numbers.hashCode()
+    override fun equals(other: Any?): Boolean {. }
+}
+```
+
+리뷰어: "data 클래스와 일반 클래스는 *어떤 차이*가 있을까요?" 학생: "기존 동등성 비교를 위해 data class로 선언을 해 주었으나, *주 생성자를 private constructor로 선언하는 과정에서 copy 메소드를 통해 주 생성자가 노출 된다는 IDE 상에서의 문구*를 확인하여, 이를 막고자 data class가 아닌 *일반 클래스로 선언 후 equals와 hashCode 함수를 오버라이드* 했습니다! 혹시 이 경우 어떤 방법으로 코드 작성을 해야 하나요?" 리뷰어: "private constructor를 놓쳤었네요. *트레이드오프에 대한 선택의 문제*인 것 같아요! 현재 Lotto의 *팩토리 함수에 중요한 로직이 없기 때문에 private constructor를 강제하지 않아도 좋을 거 같긴* 한데, *통일성이나, 이후 팩토리 함수의 로직이 추가될 수 있으니, 선택의 문제*인 것 같아요." — *생성자 통제* vs *data class 편의* 트레이드오프.
+
+### 7. `LottoStore`의 `buyManualLotto`/`buyAutoLotto` 외부 노출 — 캡슐화
+
+```kotlin
+class LottoStore { 
+    fun buyManualLotto(): Lottos {. }
+    fun buyAutoLotto(): Lottos {. }
+    fun makeLottos(): Lottos = mergeLottos(buyManualLotto(), buyAutoLotto())
+}
+```
+
+리뷰어: "buyManualLotto, buyAutoLotto는 *테스트 코드 외에선 사용되지 않아요. 외부로 노출될 필요가 없을 것 같아요*! 테스트도 변경해 보아요!" — *테스트를 위한 가시성 확장* 안티패턴.
+
+### 8. `var lottoCount` *상태값* — Backing field 권장
+
+```kotlin
+class LottoStore(.) {
+    var lottoCount = purchaseMoney.getPurchaseLottoCount()
+        private set
+
+    fun buyManualLotto(): Lottos {
+        lottoCount -= manualLottoTickets.size  // ⚠ 상태 변경
+.
+    }
+}
+```
+
+리뷰어: "변수에 대한 *책임이 모호*한 거 같아요. *lottoCount는 어떤 것을 의미할까요*? *상태값을 가질 필요는 없을 거 같아요*, 또한 외부에 노출되지 않아도 될 거 같아요!" 제안:
+```kotlin
+private val autoLottoCount get() = purchaseMoney.getPurchaseLottoCount() - manualLottoTickets.size
+```
+*파생값은 계산식*. 학생: "Controller에서 *수동, 자동 로또 구매 결과 출력*을 호출할 때, *각각의 로또 개수를 출력해야 해서 public으로 변수를 선언*했었는데, *private으로 숨기고, 이를 따로 getAutoLottoCount라는 함수를 구현*해서 반환해 주는 방식으로 해도 상관이 없을까요!? *직접적인 변수 접근을 할 수 없어 이와 같은 방법이 좋아 보이지만 필요 없는 함수를 결과 출력을 위해 굳이 생성*하는 게 아닌가 싶어 의문이 듭니다!" 리뷰어: "써니님 말씀대로 *불필요해 보이는 함수가 되었네요. 제가 커뮤니케이션 미스가 있었네요* 🙏 *상태값을 가지는 변수보단 Backing field를 활용*을 추천하는 코멘트였습니다! *autoLottoCount는 getter만 있기 때문에 외부에 노출되어도 상관없을 것* 같아요!" — *별도 함수 vs property getter*는 Kotlin에서 *property*가 자연.
+
+### 9. `if`문 *중괄호 생략*
+
+```kotlin
+fun checkManualLottoCount(manualLottoCount: Int): Int {
+    if (manualLottoCount != 0)
+        require(value / (manualLottoCount * LottoPrice.DEFAULT_LOTTO_PRICE) > 0) { ERROR_MESSAGE_AVAILABLE_COUNT }
+.
+}
+```
+
+리뷰어: "if문이 2줄 이상 되면, `{}` 중괄호 *생략하지 않는 게 좋을 거 같아요*!" — *암묵 블록 경계*는 버그 유발(Apple goto fail).
+
+### 10. 테스트에 *범위로 LottoNumber 생성*
+
+```kotlin
+fun generateLotto(startLottoNumber: Int, endLottoNumber: Int): List<LottoNumber> = 
+    (startLottoNumber..endLottoNumber).map { LottoNumber(it) }
+```
+
+리뷰어: "*range로 만들어서 generate해 주기 보다 List<Int>로 받아* 보면 어떨까요? *좀 더 명확*할 거 같아요!" — *추상화*보다 *명시적 케이스*.
+
+## 리뷰어 의견 요지
+
+- **Tell, Don't Ask** — `LottoStore`가 *수동/자동 수 + 발행*까지 직접.
+- **InputView/OutputView 기능 분리는 *응집도 낮음*** — *화면/행위 단위*로 분리.
+- **반복 입력 = *명세에 따른 선택***. View 형식 vs 도메인 정책 일관성 필요.
+- **발행 전 티켓은 *별도 타입* (`LottoTicket`)** — 상태가 다른 객체는 타입도 다름.
+- **View의 비즈니스 계산 X** — *구매 가능 매수*는 `PurchaseMoney`.
+- **`data class` vs `private constructor`** = *트레이드오프*.
+- **테스트만을 위한 가시성 확장 X**.
+- **`var` 상태값 → *property getter (backing field)***.
+- **if 2줄 이상 = 중괄호 필수**.
+- **테스트 픽스처는 *명시적 List*가 *range*보다 명확**.
+
+- **대표 인용:**
+  > 자동 로또를 *몇 장 사는지에 대한 부분은 money와 manualLottoCount를 입력받은 LottoStore에서 계산*되어야 하는 작업이 아닐까요?
+  > — @namjackson on `src/main/kotlin/lotto/controller/World.kt`
+
+  > 입/출력이라는 기능으로 분리하는 것이 아니라, *화면 단위나 행위 단위로 나눠* 보는 건 어떨까요?
+  > — @namjackson on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > 아직 *발행 전 티켓은 LottoTicket과 같은 클래스로 전달*되어도 좋을 거 같단 생각이 들어요!
+  > — @namjackson on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > 상태값을 가지는 변수보단 *Backing field를 활용*을 추천하는 코멘트였습니다!
+  > — @namjackson on `src/main/kotlin/lotto/model/LottoStore.kt`
+
+## 얻은 교훈
+
+- **Tell, Don't Ask** — `purchaseMoney.calc - manualCount` 같은 *Controller 계산*은 *Store에 메시지*로.
+- **View 분리는 *기능*이 아니라 *화면/행위***. InputView/OutputView는 *기능 분리*로 *응집도 낮은* 안티패턴이 됨.
+- **반복 입력의 *경계*** — *형식 오류*는 View에서 재시도, *도메인 규칙 위반*은 일관 정책 필요.
+- **상태가 다른 객체는 *다른 타입*** — *발행 전 LottoTicket* vs *발행 후 Lotto*.
+- **View의 비즈니스 계산 금지** — *구매 가능 매수*는 `PurchaseMoney.getPurchaseLottoCount()`.
+- **`data class` vs `private constructor` 충돌** — *copy 노출*이 부담이면 일반 class + equals/hashCode. 단 *팩토리 로직이 없으면 트레이드오프*.
+- **테스트를 위한 *public 노출*은 안티패턴** — *내부 메서드 테스트* 필요하면 *통합 시나리오*로.
+- **`var` 상태값 → *property getter*** — *파생값*은 *계산식*. Kotlin은 `val x get() =.`이 *함수*보다 자연.
+- **`if` 2줄 이상 = `{}` 필수** — Apple goto fail 사례처럼 *암묵 블록*은 버그 유발.
+- **테스트 픽스처는 *명시적*** — `(1..5)` 범위보다 `listOf(1,2,3,4,5)`가 *의도*를 드러냄.
+- **리뷰어도 *커뮤니케이션 미스*를 인정** — "써니님 말씀대로 불필요해 보이는 함수가 되었네요. *제가 커뮤니케이션 미스가 있었네요* 🙏". 후배가 의문을 제기하는 *대화의 가치*.

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

@@ -0,0 +1,154 @@
+# PR #16 — [글로] 1단계 로또
+
+- **Reviewee:** [@ippnsj](https://github.com/ippnsj)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/16
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 75
+
+## 잘한 점 (설계 관점)
+
+- **`LotteryNumber` 값 객체 도입**, `Lottery` 일급 컬렉션.
+- **`LotteriesGenerator` 인터페이스 + 람다 주입 시도** (SAM).
+- **`PurchaseAmount` 값 객체** — 금액 도메인 분리.
+- **`Revenue` 별도 객체** — 수익률 분리.
+
+## 못한 점 (설계 관점)
+
+### 1. `NumberOfRank` 이름과 데이터 불일치
+
+```kotlin
+class NumberOfRank(val numbers: Map<String, Int>) {. }
+```
+
+> 이름은 NumberOfRank인데, 키값인 String은 무엇을 의미하는지? 값인 Int는 Number라는 것인데 이 Number는 무엇을 의미하는지?
+
+→ `Map<Rank, Int>`로 키 타입을 도메인 어휘로. `numbers`라는 필드명도 모호 (`countByRank` 등).
+
+### 2. `Rank`가 String 파라미터 받음 (상금 정보 외부에서)
+
+```kotlin
+enum class Rank(val description: String, val price: Int) {
+    FIRST("6개 일치", 2_000_000_000),
+.
+    fun calculatePrize(count: Int): Int =.
+}
+```
+
+> Rank 스스로 상금을 계산할 방법이 있는데 String을 파라미터로 받는 이유는 무엇일까요?
+
+→ Rank가 자기 상금 정보를 갖고 있으면 외부에서 받을 필요 없음.
+
+### 3. `description`이 도메인에 들어옴 (UI 누수)
+
+```kotlin
+enum class Rank(val description: String, val price: Int) {
+    FIRST("6개 일치",.),  // ⚠ UI 표현이 enum 데이터
+}
+```
+
+> description은 UI영역의 관심사이지 않을까요?
+
+`Revenue`에도 description 누수 — 같은 패턴.
+
+### 4. `WinningResultCalculator` — 이름과 책임 불일치
+
+```kotlin
+class WinningResultCalculator {
+    fun calculate(.): Double =.  // ⚠ 수익률 계산만 함
+}
+```
+
+> 로또 게임에 대한 승부 결과가 하는 역할은 무엇일까요? 현재는 당첨금을 계산해주는 역할만 수행하고 있기 때문에 객체 이름과는 다소 맞지 않아 보입니다. 승부 결과를 만들어내는 역할로 본다면 NumberOfRank를 만드는 역할도 같이 할 수 있을 것 같습니다.
+
+→ 두 선택지:
+- 이름에 맞게 책임 확장 (`WinningResult`가 NumberOfRank + 수익률 둘 다)
+- 책임에 맞게 이름 좁히기 (`ProfitCalculator`)
+
+### 5. `Lottery`가 `Bonus`인지 알아야 하는 책임
+
+```kotlin
+class Lottery(.) {
+    fun match(other: Lottery, bonusNumber: LotteryNumber): Rank {
+        val count = numbers.count { it in other.numbers }
+        val hasBonus = numbers.contains(bonusNumber)  // ⚠ Lottery가 보너스를 알아야 함
+        return Rank.of(count, hasBonus)
+    }
+}
+```
+
+> 파라미터로 받은 로또 번호가 일치하는지 확인하기 때문에 이 숫자가 Bonus인지 아닌지는 알 필요가 없지 않을까요?
+
+→ `WinningLottery` (Lottery + Bonus를 모두 가진 별도 객체)가 `match(lottery): Rank`를 책임.
+
+### 6. View에서 try-catch + 중복
+
+```kotlin
+fun readPurchaseAmount(): Int {
+    while (true) {
+        try {
+            return readLine()!!.toInt()
+        } catch (e: NumberFormatException) {
+            println(".")
+        }
+    }
+}
+```
+
+→ 재귀로 더 깔끔:
+
+```kotlin
+fun readPurchaseAmount(): Int {
+   val result = readLine().toIntOrNull()
+   if (result != null) return result
+   println(.)
+   return readPurchaseAmount()
+}
+```
+
+### 7. 테스트 생성 반복 → Fake Constructor 미적용
+
+```kotlin
+val lottery = Lottery(listOf(
+    LotteryNumber(1), LotteryNumber(10), LotteryNumber(20),.
+))
+```
+
+> Fake Constructor 같은 개념을 사용할 수 있습니다.
+> ```kotlin
+> val lottery = Lottery(1, 10, 20, 30, 40, 45)
+> private fun Lottery(vararg numbers: Int): Lottery {. }
+> ```
+
+테스트 가독성 + 작성 비용 ↓.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 가르침:
+
+1. **enum의 `description` = UI 누수**. lotto에서 가장 흔한 안티패턴 중 하나. UI 표현이 도메인 데이터에 박히면 UI 변경이 도메인 변경.
+
+2. **이름과 책임의 일치**. `WinningResultCalculator`가 수익률만 계산 = 이름 너무 큼. 두 선택 중 일관성.
+
+3. **Fake Constructor** 패턴 — 테스트 가독성 + 재사용. lotto는 다수 LotteryNumber를 만들어야 해서 특히 효과적.
+
+4. **재귀 입력** = while + try-catch보다 depth 낮음.
+
+5. **Tell-Don't-Ask** — Lottery가 Bonus를 알지 않게, WinningLottery가 match 책임.
+
+- **대표 인용:**
+  > 이름은 NumberOfRank인데, 키값인 String은 무엇을 의미하는지? 값인 Int는 Number라는 것인데 이 Number는 무엇을 의미하는지?
+  >
+  > — @laco-dev on `src/main/kotlin/lotto/domain/NumberOfRank.kt`
+
+  > 로또 게임에 대한 승부 결과가 하는 역할은 무엇일까요? 현재는 당첨금을 계산해주는 역할만 수행하고 있기 때문에 객체 이름과는 다소 맞지 않아 보입니다.
+  >
+  > — @laco-dev on `src/main/kotlin/lotto/domain/WinningResultCalculator.kt`
+
+## 얻은 교훈
+
+- **`Map<String, Int>`는 god-map**. Key가 String이면 호출처에서 매번 정확한 키를 알아야 함. `Map<Rank, Int>`로 타입 안전성.
+- **enum 데이터에 UI 표현 (`description`) 박지 말 것** — lotto의 특히 빈번한 안티패턴.
+- **클래스명 = 책임의 한 문장 요약**. `WinningResultCalculator`가 수익률만 = 이름과 어긋남. 책임을 *확장*하거나 *이름을 좁히기*.
+- **Fake Constructor** = 테스트 부생성자. `Lottery(1, 10, 20, 30, 40, 45)` 같은 짧은 생성. lotto처럼 다수의 값 객체를 조립해야 하는 도메인에 효과적.
+- **재귀 입력 패턴**. while+try-catch보다 깔끔. *단, 입력 재시도 횟수가 제한적*인 콘솔 환경에서 안전.

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

@@ -0,0 +1,145 @@
+# PR #55 — [글로] 2단계 로또
+
+- **Reviewee:** [@ippnsj](https://github.com/ippnsj)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/55
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @laco-dev (라코)
+- **라인 코멘트:** 20 (리뷰어 12 + 학생 8)
+
+## 잘한 점 (설계 관점)
+
+## 못한 점 (설계 관점)
+
+### 1. `PurchaseAmount` *불필요한 관심사 다수*
+
+```kotlin
+class PurchaseAmount(.) {
+    fun numberOfLottos(): Int
+    fun manualLottos(): Int  // ⚠ Amount가 수동을 앎?
+    fun autoLottos(): Int
+}
+```
+
+리뷰어: "*PurchaseAmount가 불필요한 관심사를 많이 가지게 된 것* 같습니다. *구매 금액 입장에서 로또 갯수나 수동 로또 등의 정보는 알 필요가 없지 않을까요? 자동과 수동은 하나의 상위 개념으로 구조화가 되어야 맞는 방법*이지 않을까 생각해요
+```
+주문서 {
+   주문 금액
+   수동 갯수
+   자동 갯수
+}
+```" — *Order* 도메인.
+
+### 2. *`Quantity` 별도 객체* — 양수 보장
+
+리뷰어: "*항상 양수만 가지는 개념의 Quantity를 별도의 객체로 만들어* 보세요" — *원시값 포장 + invariant*.
+
+### 3. *자동/수동 의미 함수명에 숨김*
+
+```kotlin
+fun getQuantity(): Int  // ⚠ 자동인지 수동인지 모름
+```
+
+리뷰어: "*자동, 수동 의미가 여기저기 숨겨져 있어서 이 함수가 무슨 Quantity를 반환하는지 파악이 어렵게 느껴*집니다. *함수 이름만 보면, 단순히 양의 정수를 반환하는데, 실제로는 수동 로또 갯수를 반환*하고 있습니다. *자동, 수동처럼 의미를 여러 개 가지는 경우라면 함수의 이름에 포함을 시켜 주는 게 좋겠*습니다".
+
+### 4. *`mutableList()` → `List(size) {. }`*
+
+리뷰어: "*mutableList() 대신 List를 생성하기 위한 빌더 함수를 활용*해 보세요." — 모든 PR 공통.
+
+### 5. *오류 책임 위치* — InputView/Controller/OutputView?
+
+리뷰어: "*오류가 발생했을 때 InputView에게 책임을 전달하는 게 맞는 순서일까요? 생성하는 과정에서 실패를 했을 수도 있고, InputView에서 실패를 했을 수도 있지는 않을까요? 입력을 받는 중에 실패한 것이라면, InputView에서 스스로 출력을 하고 컨트롤러에서 오류를 확인하는 목적이라면, 컨트롤러에서 콘솔에 출력을 할 수 있고 사용자에게 오류를 전달하고 싶다면, OutputView로 오류를 출력*할 수 있겠습니다." — *오류 출처 = 처리 책임*.
+
+### 6. `LottoResult.totalPrize(ranks)` — 외부 조립
+
+```kotlin
+val ranks =.
+val prize = lottoResult.totalPrize(ranks)  // ⚠
+```
+
+리뷰어: "*총 상금을 계산하기 위해서 파라미터로 받는 ranks는 이미 LottoResult가 스스로 계산할 능력이 있지 않을까요? 외부에서 만들고 다시 함수로 넣어줄 필요가* 있을까요? 만약, LotteryResult가 아래와 같은 형태가 된다면 어떤 차이가 있을까요?
+```kotlin
+class LotteryResult(val winningLottery: WinningLottery, tickets: List<Lottery>) {. }
+```"
+
+### 7. *`val` 사용* — init에서 결정 가능
+
+리뷰어: "*init 블록에서 결정되는 값이라면 val로 만들어도* 됩니다."
+
+### 8. *코드 일관성* — `manualTickets`/`autoTickets`
+
+리뷰어:
+```kotlin
+val manualTickets = publishManualTickets(.)
+val autoTickets = publishAutoTickets(.)
+```
+"autoTickets()와 *일관성 있는 코드 작성을 생각한다면, 이렇게 작성하면 더욱 좋을 것* 같아요"
+
+### 9. *학생 자가 의문* — 싱글톤 vs 클래스 + 프로퍼티 vs 함수
+
+학생: "ranks라는 값을 *이후 결과값 출력에도 사용해야 해서 외부에서 만들고 다시 함수로 넣어 주게 했던 것 같*아요!. *함수로 두지 않은 이유는 함수로 두면 호출 시마다 같은 값을 가진 다른 객체가 생성되기 때문*입니다!. *LotteryResult가 원래 ResultCalculator였어서 싱글톤 객체가 맞다고 생각*했는데 LotteryResult라고 놓고 보면 *각 게임마다 새로이 생성해도 괜찮을 것 같다는 생각이* 듭니다! 아직까지는 *싱글톤 같아 보이는 경우(calculator 등)에는 싱글톤 객체를 생성하고, 그렇지 않은 경우(PurchaseAmount, Receipt처럼 각 시행마다 새로운 객체가 필요할 것 같은 경우)에는 클래스를 생성*하는데 *어떤 경우에 싱글톤을 만들고 어떤 경우에 클래스를 만들어야 할지 스스로 기준이 잘 잡히지 않습니다*ㅠㅠ"
+
+리뷰어 답변: "*어떤 부분에 의존성을 부여하거나 하는 것은 결국 하다보면 트레이드 오프의 순간이 옵니다. 이 점은 많은 코드 작성을 하시면서 직접 깨달으셔야 하는 부분*이라, *지금 기준에서 무엇이 정답이다라고 말씀을 드리기 어려울 것* 같습니다. *재사용이 중요할 수도 있고, 생성자로 받을지 함수로 받을지 등 여러 가지 선택의 순간*이 옵니다. *이 방법과 저 방법 사이에 어떤 장단점이 있는지, 왜 그렇게 생각했는지를 주관을 가지고 가셨으면 좋겠*습니다. *당장 어디서는 무엇이 좋더라, 무엇을 써야만 한다에 쫒기다 보면 끝이 없*습니다."
+
+리뷰어 *개인 의견 예시* (협력 구조):
+```kotlin
+class WinningLottey {
+    // 우승 로또에게 -> 승부 결과를 알려줘 (티켓을 건네주며)
+    //    로또 결과에게 -> 결과를 알려줘 (티켓과 우승 번호를 건네주며)
+    fun matchBy(tickets: List<Lottery>): LotteryResult {. }
+}
+
+val winningLottery: WinningLottery
+val result = winningLottery.matchBy(tickets)
+val profit = result.getProfit(purchase)
+val ranks = result.getRanks()
+```
+"*위 구조는 LotteryResult를 만드는 데 필요한 것을 하나하나 꺼내와서 합치는 방식이 아닌, 필요에 따라 협력하는 구조로 만든 과정*이 됩니다." + *100회 로또 당첨 번호 시나리오* 비교:
+```kotlin
+# 1: 매번 LotteryResult(Ticket, winningLotto) 새로 만듦
+# 2: val results = winningLotto.matchBy(Tickets); results.get(1)
+```
+"*결론은, 설계와 구현은 자유롭다*.."
+
+### 10. *`run` 사용 불필요*
+
+리뷰어: "*run을 사용한 이점이 없*습니다."
+
+## 리뷰어 의견 요지
+
+- **`PurchaseAmount` *책임 = 금액*** — 수량은 *Order*.
+- **`Quantity` 양수 invariant 별도**.
+- **자동/수동 *함수명 명시***.
+- **`List(size) { gen() }`**.
+- **오류 *출처 = 처리 책임***.
+- **`LottoResult` *스스로 계산*** — 외부 조립 X.
+- **`val` 우선** (init 결정 시).
+- **일관성 *변수명***.
+- **싱글톤 vs 클래스 *트레이드오프*** — *직접 깨달아야*.
+- **`run` *이점 없으면 X***.
+
+- **대표 인용:**
+  > 입력을 받는 중에 실패한 것이라면, InputView에서 스스로 출력을 하고 *컨트롤러에서 오류를 확인하는 목적이라면, 컨트롤러에서 콘솔에 출력을 할 수 있고 사용자에게 오류를 전달하고 싶다면, OutputView로 오류를 출력*할 수 있겠습니다.
+  > — @laco-dev on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 어떤 부분에 의존성을 부여하거나 하는 것은 *결국 하다 보면 트레이드 오프의 순간*이 옵니다. 이 점은 *많은 코드 작성을 하시면서 직접 깨달으셔야 하는 부분*이라, 지금 기준에서 무엇이 정답이다라고 말씀을 드리기 어려울 것 같습니다.
+  > — @laco-dev (싱글톤 vs 클래스 학생 질문에)
+
+  > 위 구조는 LotteryResult를 만드는 데 필요한 것을 하나하나 꺼내와서 합치는 방식이 아닌, *필요에 따라 협력하는 구조*로 만든 과정이 됩니다.
+  > — @laco-dev on `src/main/kotlin/lotto/domain/WinningLottery.kt`
+
+  > 결론은, 설계와 구현은 자유롭다.
+  > — @laco-dev
+
+## 얻은 교훈
+
+- **`PurchaseAmount` *금액 책임만*** — *수량/수동/자동*은 *Order* 도메인.
+- **`Quantity` *양수 invariant*** = 원시값 포장 + 검증. *PurchaseAmount.numberOfLottos: Quantity*.
+- **자동/수동 *함수명에 명시*** — `getManualQuantity()`. *암묵 컨텍스트* 의존 회피.
+- **`List(size) { gen() }`** = Kotlin idiom. *모든 PR 공통*.
+- **오류 *출처 = 처리 책임*** — InputView 입력 오류 → InputView, 도메인 생성 → Controller/OutputView. *책임 흐름*.
+- **`LottoResult` *스스로 계산*** — *외부에서 ranks 만들어 다시 넣기*는 *Tell-Don't-Ask 위반*. *생성 시점에 협력자 다 받아*서 *내부 계산*.
+- **`val` 우선** — *init에서 결정*되면 *val*. *재할당 가능성*만 *var*.
+- **일관성 *변수명*** — *대구 (對句)* 가독성.
+- **싱글톤 vs 클래스 = *트레이드오프*** — *재사용 vs 시행별 생성*. *기준은 자기 경험*. 리뷰어가 *정답 제시 거부*는 *PR #75 말리빈*, *PR #137 hyemdooly*와 같은 패턴.
+- **`run`은 *이점 명확할 때*** — *지역 변수 + 명시 호출*이 자연.
+- **`WinningLottery.matchBy(tickets): LottoResult` *협력 구조*** — *값 조립 → 메시지 협력*. *100회 로또 시나리오*가 *재사용성* 강조.

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

@@ -0,0 +1,68 @@
+# PR #59 — [레오] 1단계 로또
+
+- **Reviewee:** [@jaeyeongjo](https://github.com/jaeyeongjo)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/59
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 58
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto`, `LottoNumber`, `Rank`, `LottoAnalyzer` 분리**.
+
+## 못한 점 (설계 관점)
+
+### 1. 테스트만 있는 커밋
+
+```
+test: LottoTest 생성
+```
+
+> 하나의 기능을 작성할 때에는 테스트 코드와 구현 코드가 항상 같이 존재해야 합니다.
+
+### 2. `LottoNumber` 주 생성자가 String
+
+```kotlin
+class LottoNumber(val value: String) {
+    init { require(value.toIntOrNull() in 1..45) }
+}
+```
+
+> 로또 번호는 숫자로 이루어져 있으니, 주 생성자로 가지는 값은 Int 타입이어야 하지 않을까요?
+
+→ 도메인 객체는 *도메인 타입*. String 파싱은 호출자 (InputView).
+
+### 3. Rank 등수 수동 비교에 매직넘버 `5`
+
+```kotlin
+if (matchCount == 5 && hasBonus).
+```
+
+> `5` 값을 하드코딩 하는 대신에 enum 에 정의된 값을 활용해보세요
+
+→ `Rank.SECOND.matchCount`로 간접 참조.
+
+### 4. `LottoAnalyzer` god-object
+
+```kotlin
+class LottoAnalyzer(lottos: Lottos, winning: WinningLotto) {
+    fun rankOf(lotto: Lotto): Rank =.
+    fun statistics(): Map<Rank, Int> =.
+    fun profitRate(): Double =.
+}
+```
+
+> LottoAnalyzer 객체가 협력을 하지 않고 모든 결과를 처리하려고 하기 때문에 상당히 복잡하게 구현되었습니다. 객체가 외부 (LottoAnalyzer)를 통하지 않고 스스로 결과를 만들어 내려면 어떻게 해야 할까요?
+
+→ Analyzer가 모든 책임을 가져가면 god-object. 각 도메인이 *자기 책임*.
+
+### 5. Rank 테스트 일부만
+
+→ 모든 등수 (1~5, MISS) 테스트.
+
+## 얻은 교훈
+
+- **도메인 객체의 주 생성자 = 도메인 타입**. String 파싱은 *입력 경계*에서 끝.
+- **매직넘버 대신 enum 참조** — enum이 데이터 소유자.
+- **"Analyzer/Calculator/Manager" god-object 패턴** — 모든 결과를 외부 객체가 만들지 말고 각 도메인이 책임.
+- **enum 케이스 전부 테스트** = 비즈니스 분기 전체 검증.

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

@@ -0,0 +1,53 @@
+# PR #83 — [로또] 레오 2단계 미션
+
+- **Reviewee:** [@jaeyeongjo](https://github.com/jaeyeongjo)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/83
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 47
+
+## 잘한 점
+
+- **`LottoBudget` 도입 — 지갑 비유** (칭찬).
+
+## 못한 점 + 핵심 지적
+
+### 1. 캡슐화 기능 사라짐
+
+```kotlin
+class LottoResult {. }  // 일부 메서드가 다시 외부로 노출됨
+```
+
+> 이 기능은 캡슐화를 위한 역할을 잘 수행하고 있는데, 왜 다시 사라졌을까요?
+
+→ 리팩토링 중 캡슐화 약화 발생. *변경 의도*가 명확해야.
+
+### 2. 수동 + 자동 패턴 불일치
+
+```kotlin
+val autoLottos = AutoLottoMachine.create(budget, generator)
+val manualLottos = ManualLottoMachine(numbers).get()  // ⚠ 다른 사용 패턴
+```
+
+> 수동 로또와 자동 로또의 발급 패턴이 유사한 것 같은데, 사용하는 방법이 다르게 사용되고 있네요. 번호들을 발급한다는 협력에 집중해서 본다면 단순하게 만들어 볼 수 있지 않을까요?
+> ```kotlin
+> AutoLotoMachine.createLottos(budget, RandomLottoNumbersGenerator())
+> ```
+
+### 3. 지갑 차감 — 발급 실패 시 일관성?
+
+```kotlin
+class LottoBudget(.) {
+    fun deduct(amount: Int) {. }  // ⚠ 차감 후 발급 실패하면?
+}
+```
+
+> LottoBudget을 만들어주셔서 지갑처럼 사용되는 설계 방법 좋았습니다. 다만 지갑을 먼저 차감하기 때문에 실제 로또를 발급하는 과정에서 문제가 생긴다면 어떻게 될까요? 상태를 만들어서 관리를 하는 방법도 좋지만, 단순히 생성할 갯수만 입력받는 방법이라면 위 문제는 사라집니다.
+
+→ 트랜잭션 무결성 의식. 또는 *수량 계산만* 받고 *지갑 보유*는 외부.
+
+## 얻은 교훈
+
+- **리팩토링 중 캡슐화 약화** = 변경 의도 검토 필요.
+- **수동/자동 패턴 통일** — 같은 *발급 협력*이면 같은 시그니처.
+- **상태 보유의 트랜잭션 부담** — 차감 후 실패 시 롤백 어려움. *수량만 받는* 무상태 함수가 더 안전.