oh-my-oop 0.2.0

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

@@ -0,0 +1,97 @@
+# PR #95 — [로또] 해음 2단계 미션
+
+- **Reviewee:** [@haeum808](https://github.com/haeum808)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/95
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 26
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` Flyweight + `from(value)`** — `(1..45).associateWith` 캐싱.
+- **`Lotto` 부생성자 두 종류** — `vararg` + `List<Int>` 두 호출 지점 지원.
+- **`require(numbers.size == LOTTO_SIZE)`** — 도메인 invariant.
+- **자가 인정 흐름** — 학생이 "잘못된 협력이라고 생각합니다. 변경하는 게 맞다고 생각합니다!"라고 *책임 위치*를 스스로 정정.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto.findRank(lotto, bonus): Rank` — 등수 계산이 Lotto의 책임?
+
+```kotlin
+class Lotto(val numbers: Set<LottoNumber>) {
+    fun findRank(lotto: Lotto, bonusNumber: LottoNumber): Rank {
+        val countOfMatch = (lotto.numbers intersect numbers).size
+        val matchBonus = lotto.contains(bonusNumber)
+        return Rank.valueOf(countOfMatch, matchBonus)
+    }
+}
+```
+
+리뷰어: "거의 다 왔네요! 로또가 자기 자신과 보너스 번호까지 받아서 등수를 반환하고 있네요! 등수를 계산하는 게 로또 티켓이 해야 하는 일이 적절할까요? 스스로가 자기 자신을 비교했을 때, *맞은 번호의 개수* 정도만 반환하게 만들어 보는 건 어떨까요?" 학생: "lotto와 bonus는 WinningNumber가 가지고 있는데 이걸 굳이 'Lotto에게 메시지를 보내서 거기서 처리해!' 처럼 이상하게 코드를 작성. 객체 스스로 상태를 가지고 충분히 처리할 수 있는 책임인데 의미 없이 넘긴 책임이라고 생각합니다. 즉 *잘못된 협력*이라고 생각합니다."
+
+### 2. `LottoMachine`이 일회용 — 재사용 불가
+
+```kotlin
+class LottoMachine(private val money: Money, val manual: Int) {
+    private val _lottoes: MutableList<Lotto> = mutableListOf()
+    fun makeManualLotto(lotto: Lotto) { _lottoes.add(lotto) }
+    fun makeRandomLotto() { repeat(auto.toInt()) { _lottoes.add(Lotto(.)) } }
+}
+```
+
+리뷰어: "이 객체는 한 번 사용한 뒤, 재활용하지 못하는 형태네요! 객체를 한 개만 만들고, 새로 만들지 않고 로또 생성을 여러 번 할 수 있도록 변경해 보는 건 어떨까요?" 학생: "재활용하지 못하고 적절하지 못한 추가적인 객체라고 생각해서 Money 객체와 합쳐 주었습니다." — *생성자가 상태를 누적*하면 *일회용*. *상태 없는 메서드*면 재사용 가능.
+
+### 3. 랜덤 내장 — 테스트 불가
+
+```kotlin
+fun makeRandomLotto() {
+    repeat(auto.toInt()) {
+        val randomNumbers = (1..45).shuffled().take(6).sorted()  // ⚠ 내장
+        _lottoes.add(Lotto(randomNumbers))
+    }
+}
+```
+
+리뷰어: "랜덤에 대한 요소가 다시 테스트할 수 없는 형태로 변경되었네요. 외부로부터 주입받는 형태로 변경해서 테스트 가능하도록 변경해 주세요! 개수만을 비교하는 것은 테스트에 큰 의미를 갖지 못한다고 생각해요. 개발자가 제어 가능한 환경에서 *원하는 로또 티켓 자체*를 검사해야 테스트도 의미가 있어요." 학생: "제어 가능 및 테스트 용이하게 람다를 넘기는 방식으로 변경했습니다." — 람다 주입 OK, `fun interface`도 옵션.
+
+### 4. `contains`에 `any` 사용 — Set의 `contains` 직접 호출 못 함
+
+```kotlin
+operator fun contains(number: LottoNumber): Boolean = numbers.any { it == number }
+```
+
+리뷰어: "contains 내부 로직을 any를 활용하기보다, set의 기능인 contains를 활용해 보는 건 어떨까요? 시간 복잡도에서 어떤 차이점을 보일까요?" 학생: "선형 탐색이 아닌 해시로 찾게 됩니다. any를 사용하게 되면 O(n)이 나오지만 contains를 사용하면 O(1). 이미 있는 라이브러리 함수를 사용하는 게 맞다고 생각합니다." 리뷰어 후속: "반드시 모든 Set이 시간 복잡도가 O(1)인 것은 아니랍니다! Set은 interface이기에, 다양한 구현체들이 존재해요!" — 학생 답이 *대체로* 맞지만, *구현체 의존*임을 짚어줌.
+
+### 5. `LottoNumber` 캐싱 효과 검증 부재
+
+리뷰어: "캐싱을 활용해 주셨네요! 테스트를 통해 *실제로 같은 인스턴스를 반환하고 있는지* 검증해 보는 건 어떨까요?" 학생: "꼼꼼히 보지 못했습니다! 누군가 코드를 바꿀 수도 있는데 같은 인스턴스를 반환하는지 테스트 코드가 있다면 휴먼 에러를 없앨 수 있을 것 같습니다!" — *캐싱은 미래 변경으로 깨질 수 있는 invariant*. 테스트로 보호.
+
+### 6. `WinningLotto` 책임 위치 명확화
+
+리뷰어: "당첨 티켓이 여러 로또 티켓을 받아 등수를 계산해 주네요! 그렇다면 *1개의 로또 티켓을 받아 비교하는 역할*도 이 객체에 위치하는 게 자연스럽다는 생각이 드네요." 학생: "LottoDrawingResult의 책임으로 변경하고 보너스 번호가 있는지 체크하는 책임을 WinningLotto에 위임했습니다."
+
+## 리뷰어 의견 요지
+
+- **메시지 방향 = 책임 소유** — `lotto.findRank(.)`는 *로또가 등수까지 알아야*. `winningLotto.match(lotto)`가 자연.
+- ***일회용 객체* vs *재사용 객체*** — 누적 상태를 보유하면 일회용. 상태 없는 메서드는 재사용.
+- **컬렉션 API의 *시간 복잡도*** — `Set.contains`가 보통 O(1), `any`는 O(n). 단 *구현체 의존*.
+- **캐싱은 *테스트로 보호*해야 미래에 안 깨짐**.
+
+- **대표 인용:**
+  > 거의 다 왔네요! 로또가 자기 자신과 보너스 번호까지 받아서 등수를 반환하고 있네요! 등수를 계산하는 게 로또 티켓이 해야 하는 일이 적절할까요?
+  > — @malibinYun on `src/main/kotlin/lotto/model/Lotto.kt`
+
+  > 이 객체는 한 번 사용한 뒤, 재활용하지 못하는 형태네요!
+  > — @malibinYun on `src/main/kotlin/lotto/model/LottoMachine.kt`
+
+  > 반드시 모든 Set이 시간 복잡도가 O(1)인 것은 아니랍니다! Set은 interface이기에, 다양한 구현체들이 존재해요!
+  > — @malibinYun on `src/main/kotlin/lotto/model/Lotto.kt`
+
+## 얻은 교훈
+
+- **메시지 방향 = 도메인 의미** — "당첨 로또가 *내 번호와 비교한다*" (`winningLotto.match(lotto)`) vs "로또가 *당첨인지 확인*" — 전자가 자연. 등수 결정은 *당첨 로또의 행위*.
+- **누적 상태 보유 = 일회용 객체**. `_lottoes.add()`가 누적되면 재사용 불가. *상태 없는 메서드*로 발행물만 반환.
+- **랜덤 외부 주입**은 *테스트 가능성*의 1차 조건. 람다 또는 `fun interface`.
+- **컬렉션 API 선택은 *시간 복잡도*와 *구현체*** — `any` vs `contains`는 의미는 같아도 비용이 다름. *Set의 구현체*까지 확인.
+- **Flyweight 캐싱은 *테스트로 보호*** — 누군가 캐시 로직을 우회하면 *동일 인스턴스 반환*이라는 invariant가 깨짐. 명시 테스트로 안전망.
+- **"잘못된 협력"이라는 학생 자가 표현**이 정확 — *책임 위임이 아니라 책임 전가*는 협력 X.

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

@@ -0,0 +1,235 @@
+# PR #113 — [환노] 1단계 로또
+
+- **Reviewee:** [@hwannow](https://github.com/hwannow)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/113
+- **단계:** 1단계
+- **리뷰어:** @lee-ji-hoon (코니)
+- **라인 코멘트:** 49 (학생 13 + 리뷰어 36)
+
+## 잘한 점 (설계 관점)
+
+- **현실 비유로 모델 설계 시도** — *LottoResult = 결과 확인 사이트*, *Controller = 구입자*. (이후 비판되지만 *시도 자체*는 가치 있음).
+- **`PurchaseAmountValidator`, `WinningNumberValidator`, `BonusNumberValidator` 분리** — *각 입력 책임* 의식.
+- **`require` 사용** — 도메인 invariant 표명.
+
+## 못한 점 (설계 관점)
+
+### 1. *Controller가 모든 값 보유* — 현실 비유 오용
+
+```kotlin
+fun run() {
+    val purchaseAmount = getPurchaseAmount()  // Controller 보관
+    val lottos = LottoMachine().buyLottos(purchaseAmount)
+    val winningNumber = getWinningNumber()
+    val bonusNumber = getBonusNumber(winningNumber)
+    val lottoResult = LottoResult(winningNumber, bonusNumber)
+    val winningStats = lottoResult.matchLotto(lottos)
+    val prize = lottoResult.calculatePrize(winningStats)
+    outputView.printProfit(lottoResult.calculateProfit(prize, purchaseAmount))  // 직접 호출
+}
+```
+
+학생 자가 변호: "LottoResult가 *로또 결과 확인 사이트*, Controller가 *로또를 구입하는 사람*이라고 생각했을 때, *현실에서는 구입 금액, 등수 별 당첨 결과, 상금, 수익률 같은 데이터는 로또 결과 확인 사이트에서 값을 저장하지 않고, 로또를 구입한 당사자가 갖고 있게* 됩니다. 따라서 코드도 위와 같이 *컨트롤러가 대부분의 리턴값을 갖게* 됐습니다. 특히 *등수 별 당첨 결과의 경우, LottoResult 내에서 계산하고 저장하려면 MutableMap 또는 lateinit 또는 var를 사용해야 하기 때문에* `결과를 저장할 객체를 따로 만들어야 할지`에 대해 많은 고민을 했습니다."
+
+리뷰어: "모든 것들을 *현실 세계로 반영하려고 했던 것과 그리고 제 생각에는 현실 세계랑도 안 맞는 부분이 존재해서 Model들이 해야 할 역할들을 제대로 못하고 있다*고 생각을 합니다. 이 부분은 *객체지향에 대해서 많이들 오해를 하고 있는 것이 객체를 현실 세계의 사물과 완전히 같은 것으로 오해를 하고 구현*을 하기 때문인데요. *실제로 모든 객체들이 그럴 수는 없습니다. 예를 들어 'A가 음료를 마신다.'라는 동작을 할 때 음료는 A로 인해서 양이 줄어들어야 하지만 객체지향에서 코드를 작성을 하게 되면 'A가 음료에게 메세지를' 던져서 양이 줄어들게* 되겠죠. 이런 것처럼 *모든 객체들이 현실세계와 완벽하게 동일하게 될 수는 없*습니다. *객체지향 패러다임의 목적은 현실세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이 메인*이라고 생각을 하는 게 더 좋을 것입니다. 책의 내용을 갖고 와 보자면 「객체지향의 사실과 오해」에서는 이런 말도 있는데요. > *소프트웨어 객체는 현실 속의 객체를 모방하거나 추상화한 것이 아닌 은유할 뿐이다. (쉽게 유추할 수 있도록)* 이처럼 *객체지향에서 객체는 현실 속의 객체를 추상화하고 은유를 할 뿐*이라고 생각해 주시면 더 좋을 같습니다." + "*현실 세계를 기준으로 등수 별 당첨 결과, 상금은 적어도 로또 확인 사이트에서 확인이 가능한 데이터* 같은데요. *어떤 기준으로 그렇게 생각하셨는지* 궁금하네요."
+
+### 2. `run()` *너무 가혹한 함수*
+
+```kotlin
+fun run() {
+    val purchaseAmount = getPurchaseAmount()  // 10줄
+    val lottos = LottoMachine().buyLottos(purchaseAmount)
+    outputView.printPurchasedLottos(lottos)
+    val winningNumber = getWinningNumber()
+    val bonusNumber = getBonusNumber(winningNumber)
+    val lottoResult = LottoResult(winningNumber, bonusNumber)
+.
+}
+```
+
+리뷰어: "*run이라는 함수의 역할이 너무 가혹*하다고 생각이 드네요. 지금 당장은 10줄이지만 *너무 많은 모델들이 포함되어 있는 함수라서 10줄이 20줄 30줄 같은 가독성*이 되어 버립니다. 그리고 *누군가 어떠한 코드를 추가할 때 실수하기도 더 쉬워*지겠죠."
+```kotlin
+fun run() {
+    val lottoRound = createLottoRound()
+    val result = playLottoRound(lottoRound)
+    displayResult(result)
+}
+```
+"가령 이런 형태로도 나눠 볼 수 있을 거 같습니다."
+
+### 3. `Validator` *능동 vs 수동* — 책임 위치
+
+```kotlin
+class PurchaseAmountValidator(input: String) {  // 외부가 사용
+    init {. }
+}
+```
+
+리뷰어: "`Validator`라는 *역할만 생각했을 때 어떠한 input에 대한 검증*일 것입니다. 그런데 *지금 검증을 하고 있는 것은 input이 메인처럼 보이지만 실제로는 본인의 생성에 대한 검증*인데 이것을 input으로 검증을 하고 있을 뿐이며, *외부에서 validator를 사용하는 게 아니라 validator가 능동적으로 검증을 하는데 수동적이어야 하지 않을까요*?"
+
+후속 (학생 우려): "*사용자로부터 받을 입력이 늘어나게 된다면 각 입력마다 Validator를 만들어야 되는 문제*가 생길 것 같은데."
+
+리뷰어 (도메인 모델링 본질): "*입력에 따른 Validator가 생기는 것은 당연한 일*이라고 생각합니다. *공통된 것들은 추상화를 하거나 비슷한 도메인은 하나의 Validator에서 처리*를 한다든지 하는 방법들이 있죠. 그런데 *지금 이것을 '문제'라고 인식한 이유는 모든 것들이 Controller의 역할이 되어 버려서 그렇게 인식*을 하게 된 것이라고 생각을 하는데 *제가 위에 적어둔 객체지향과 MVC에 대해서 다시 고민*해 보시기 바랍니다." 학생 후속: Validator 전부 제거, *PurchaseAmount.init*으로 이동. 리뷰어: "*모든 입력에 대한 검증을 Validator에서 하는 순간 Validator는 무궁무진하게 늘어나게 될 거에요*! 🫠".
+
+### 4. 테스트만을 위한 `public` 메서드
+
+```kotlin
+class LottoMachine {
+    fun generateInternal(): Lotto =.  // ⚠ Controller 안 부름
+}
+```
+
+학생: "controller에서 *직접적인 호출 없이 테스트 코드를 위해 public으로 선언*된 메소드입니다." 리뷰어: "*'private 함수를 왜 테스트해야 하나?'라는 질문을 먼저 해 보면 좋을 거 같*은데요. 현재 *이 함수를 public으로 바꿔서 마음이 걸린다면, 이 함수는 애초에 별도의 책임의 일부로서 원래는 다른 클래스에 들어 있어야 했던 것이거나 테스트가 불필요한 것*일 겁니다."
+
+### 5. `parseToInt` *한 줄 함수 = 추출 가치?*
+
+```kotlin
+private fun parseToInt(input: String): Int { return input.toInt() }
+```
+
+리뷰어: "*이게 정말 필요했던 함수일까요*? 그렇다면 *winningNumber.map { parseToInt(it) } 여기서 map도 함수화*를 해야 했지 않았을까요?" — *추출 일관성*: 한 곳만 추출하면 *기준 모호*.
+
+### 6. `RandomGenerator`의 *MIN/MAX 결합*
+
+```kotlin
+class RandomGenerator {
+    fun getRandomNumberList(): List<Int> {
+        return (MIN_NUMBER..MAX_NUMBER).shuffled().take(6)  // ⚠ Lotto 도메인 결합
+    }
+}
+```
+
+리뷰어: "*이 클래스와 이 함수는 정말 Random인 Number를 뱉고 있나요? 제가 보기엔 어떤 도메인의 의존적으로 구현이 되어 있어서 특정 MIN과 MAX만 반환*하는 거 같네요" + "RandomGenerator는 *객체지향적 관점에서 봤을 때 어떤 역할을 하고 있을까요? 단순 랜덤으로 이루어진 것들은 모두 Generate해 주는 역할을 해야 하는 걸까요? 그러기엔 너무 가혹*하지 않을까요 🫠" + "로또를 구매하려고 할 때 *그제서야 RandomGenerator를 만드는 것은 뭔가 어색*하지 않나요? *LottoMachine에 내장되어 있어야 할 거 같은 기능*이네요" — *역할 부여*는 *공통 추상*이 아니라 *책임 일치*가 기준.
+
+### 7. *상수 위치 일관성* — 1, 45 다른 곳에 있는데 Lotto 안엔 없음
+
+```kotlin
+class Lotto(.) {
+    init {
+        require(numbers.all { it in 1..45 })  // ⚠ 하드코딩
+    }
+}
+```
+
+리뷰어: "*1과 45가 이미 다른 곳에 상수화되어 있는데요 여기에는 상수화가 안 되어 있*네요 🫠 즉 *Lotto가 1부터 45라는 개념이 지금 다른 곳에 조금 더 치중이 되어 있는 거 같은데 수정*해 보면 어떨까요!"
+
+### 8. `MutableList` 누적 → `List(n) {. }`
+
+```kotlin
+val lottos: MutableList<Lotto> = mutableListOf()
+repeat(lottoCount) {
+    lottos.add(Lotto(randomGenerator.getRandomNumberList()))
+}
+return lottos.toList()
+```
+
+리뷰어: "전반적으로 *Mutable한 값들은 최소화 해 보려고 했다*. 라는 내용이 있었는데요. *여기도 결국 이렇게 선언을 해 두면 계속 유지보수를 하다 보면 누군가가 이 값에 잘못 변경한다*든지 하는 일이 생길 거 같아요."
+```kotlin
+fun buyLottos(purchaseAmount: Int): List<Lotto> {
+    val randomGenerator = RandomGenerator()
+    val lottoCount = getLottoCount(purchaseAmount)
+    return List(lottoCount) { Lotto(randomGenerator.getRandomNumberList()) }
+}
+```
+
+### 9. `InputView` *중복 print + readln* — MVC 의도와 결합도
+
+```kotlin
+fun getPurchaseAmount(): String { println(MESSAGE_INPUT_PURCHASE_AMOUNT); return readln() }
+fun getWinningNumber(): String { println(MESSAGE_INPUT_WINNING_NUMBER); return readln() }
+fun getBonusNumber(): String { println(MESSAGE_INPUT_BONUS_NUMBER); return readln() }
+```
+
+학생: "세 메소드가 *출력 → 입력값 반환 로직이 동일*해서 `fun getData(message: String): String {. }` 위처럼 *하나의 메소드로 통일*시킬지 고민했는데, 이렇게 될 경우 *호출부에서 출력 메시지를 넘겨주게* 됩니다. 따라서 *출력 부분에 수정이 일어나면 controller를 수정하게 될 텐데, 이는 MVC 패턴의 의도와 맞지 않는 것 같*아서 중복 로직 메소드 세 개를 각각 구현했습니다. 코니는 이에 대해 어떻게 생각하시나요?"
+
+리뷰어: "*제 개인적인 생각으로는 합리적*이라고 생각을 합니다. MVC 패턴의 의도는 *각 계층의 책임을 분리하는 데* 있습니다. *View는 사용자와의 인터랙션, 즉 입력과 출력을 담당하고, Controller는 비즈니스 로직의 흐름을 관리*하는 역할을 합니다. *입력 메시지를 View 내부에 하드코딩해 두면, View가 변경될 때 Controller에 영향을 주지 않는 장점*이 있는데요. *반면에, 하나의 범용 메소드를 만들어 메시지를 호출부에서 넘겨주게 되면, View의 메시지 로직이 Controller로 흘러들어가는 구조*가 됩니다. 이렇게 되면 *출력 메시지에 수정이 필요할 때 Controller까지 수정해야 하는 상황*이 발생할 수 있습니다." — 학생 사유 *지지*. + 추가: "*개인적으로 저 정도의 복잡성이면 딱히 비즈니스적인 것도 없으니 나중에 수정이 일어나도 저기에 수정은 없을 것 같아서 getData()처럼 하나의 함수 정도는 파 두고 다른 예외 함수들을 추가할 거 같*네요."
+
+### 10. *재입력 (`while+catch`)* vs *프로그램 종료*
+
+리뷰어: "전반적으로 *require을 사용해서 error를 만들어 주셨는데 이번엔 Catch해서 유저가 다시 입력을 하게끔 해 보는 건 어떨까요*?
+```kotlin
+while(true) {
+   1. 유저의 입력
+   2. validate 
+      2-1. true -> 입력 그대로 반환
+      2-2. catch -> 유저에게 알려주고 그대로 다시 입력 시작
+}
+```
+*이 부분은 시간이 남으면 구현해 보는 것으로 하겠습니다! 지금은 다른 부분에 집중*해 주세요!" — *학생 우선순위 보호*.
+
+### 11. *`var price` 변수 의도 모호* — 테스트 시그널 약함
+
+```kotlin
+class LottoMachine {
+    val price: Int = LOTTO_PRICE  // ⚠ 단순 테스트용 노출
+}
+```
+
+리뷰어: "이 변수는 *단순 테스트만을 위해서 public*인 것으로 보이는데요. *테스트에서 1_000이라는 값을 확인하기 위함*인데, *꼭 price를 참조해서 확인을 했어야 했을까요*? 이 변수를 사용하는 *테스트 코드의 함수명은 '로또 1장의 가격은 1000원이다'*입니다. 그런데 *LOTTO_PRICE가 2,000원으로 변경이 되었을 때도 price라는 변수를 참조 중이니 테스트가 성공*할 거 같네요. *테스트 함수명에는 1000원인데도요* 🤔" — *테스트가 자기 자신을 참조*하는 *동어 반복* 안티.
+
+### 12. `PurchaseAmount` 네이밍 — *최소 단위* 명시
+
+```kotlin
+class PurchaseAmount(val value: Int) {. }
+```
+
+리뷰어: "*PurchaseAmount만 봤을 때 이게 최소 단위가 있을 것이라고 예측이 가능*할까요? *객체는 클래스명만 봤을 때 어떤 역할을 할 것인지 어느 정도 납득이 가야 하는데 지금은 좀 아쉽다*는 생각이 있네요 🤔" + "*value라는 네이밍도 조금 더 가다듬*으면 어떨까요" — *클래스명 = 즉시 이해되는 도메인 책임*.
+
+### 13. *View는 멍청해야* — 메시지 선택권
+
+리뷰어: "*제가 가장 좋아하는 말은 'View는 멍청해야 한다.' / 'View는 수동적이어야 한다'*인데요! *View가 어떠한 메시지를 보여줄지 직접 선택하는 것도 가능은 하지만 멍청하게 해 보는 연습*을 해 보면 어떨까요?"
+
+### 14. *양수 체크 2곳* — 검증 위치 일원화
+
+리뷰어: "양수/음수를 확인하는 동작이 *Input에서도 하고 LottoPurchaseAmount init에서도 하는 것*으로 보이는데요. *LottoPurchaseAmount의 특성상 양수만 가능하긴 하지만 Input에서 이미 걸러졌을 것을 또 확인하게 되는 상황*이기도 한데요. 2곳에서 체크하니까 *한 곳은 없애야 한다!라는 것은 아니고, 양수만 가능한 것을 둘 다 체크하는 게 좋을지 한 곳에서만 하는 게 좋을지 한 번 고민*해 보면 좋을 거 같네요!"
+
+### 15. 학생 *필드 vs 생성자* 자가 의문
+
+학생: "이번 리팩토링 진행하면서 피드백 받았던 부분들 적용하려고 노력했습니다. 😭 다만 *아직 어떤 객체에 무엇을 저장해야 할지 감이 잡히지 않습니다*. winningStats, prize, profit을 *LottoCalculator의 필드에 저장하기엔 (선언 → 계산 메소드 → 저장) 로직으로 인해 var로 선언해야 하는 부분도 마음에 걸립니다*."
+
+리뷰어  "음 *근본적으로 왜 필드로 선언을 하려고 했던 것인지 한 번 이야기*를 해 보면 좋을 거 같네요. *생성자와 필드로 선언해야 할 것들이 각각 어떠한 상황에서 선택을 해야 하는지를 고민*해 봤으면 좋겠습니다. 가령 *winningStats를 필드 변수로 선언할 필요가 있을까요? Lotto들이 들어왔을 때 지금처럼 단순히 어떠한 결과값만 나와도 충분*하지 않을까요?" + "*추가로 저런 구조가 고민이 되면 그냥 짜고 리뷰를 받아 보는 것도 답*입니다. *리뷰어 입장에서는 글로만 설명이 되면 어떻게 구조를 잡고 이야기를 하시는 걸까?라는 의문이 계속 들기 때문*이죠! 코드를 리뷰 받기 위함이라면 그 *코드를 구현해 보고 우선 리뷰 요청을 해 보는 것도 팁*입니다."
+
+## 리뷰어 의견 요지
+
+- ***객체지향 = 현실 모방 X, 현실 은유***. 「객체지향의 사실과 오해」 인용.
+- **`run` *작은 함수 단위 (Round/Result/Display)***.
+- **`Validator` *능동 vs 수동*** — *생성 시 자기 검증*이 자연.
+- **테스트 위한 `public` 변경 X** — *책임 재배치*가 답.
+- **`MutableList` 누적 → *불변 `List(n) {. }`***.
+- **`InputView`의 *각 메시지 분리* MVC 결합도 낮춤** (학생 사유 지지).
+- **재입력 catch 패턴** — *우선순위 보호*.
+- **`var price` *테스트 위한 노출* = 동어 반복 테스트**.
+- **`PurchaseAmount` *네이밍*에 *최소 단위* 단서**.
+- **`View는 멍청해야*** — 메시지 선택권 최소화.
+- **검증 위치 *일원화*** — 양수 체크 2곳 의식.
+
+- **대표 인용:**
+  > 객체지향 패러다임의 목적은 *현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이 메인*이라고 생각을 하는 게 더 좋을 것입니다.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 소프트웨어 객체는 *현실 속의 객체를 모방하거나 추상화한 것이 아닌 은유할 뿐*이다.
+  > — @lee-ji-hoon (조영호 「객체지향의 사실과 오해」 인용)
+
+  > 모든 것들이 Controller의 역할이 되어 버려서 *그렇게 인식*을 하게 된 것이라고 생각을 하는데 제가 위에 적어둔 *객체지향과 MVC에 대해서 다시 고민*해 보시기 바랍니다.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 코드를 리뷰 받기 위함이라면 그 *코드를 구현해 보고 우선 리뷰 요청을 해 보는 것도 팁*입니다.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/LottoResult.kt`
+
+## 얻은 교훈
+
+- **객체지향 = *현실의 은유, 모방 X*** — 「객체지향의 사실과 오해」 인용. *현실 비유*는 *유추 도구*이지 *설계 원리*가 아님.
+- ***A가 음료를 마신다* → *A가 음료에게 메시지를 던진다*** — *능동/수동 뒤집힘*이 OO의 핵심.
+- **`run` *작은 함수 단위*** — *createLottoRound → playLottoRound → displayResult* 같은 *논리 흐름*. 10줄이지만 *지속 가능*.
+- **`Validator` *능동*** — *외부가 검증*은 *수동*. *객체 스스로 검증 (init)*이 *능동*.
+- **테스트 위한 `public` 변경 = *책임 위치 재검토 신호*** — `internal` 회피하지 말고 *진짜 책임 분리*.
+- **`MutableList` 누적 패턴 → *불변 `List(n) { generator() }`*** — Kotlin 컬렉션 생성 idiom + 불변 보장.
+- **MVC 결합도 = *View 메시지의 위치***. 학생의 *각 메서드 분리*가 *Controller 영향 차단*. 둘 다 정당.
+- **재입력 catch 패턴은 *선택* — *시간/우선순위*에 맡길 수 있음** — 리뷰어가 *학습 부하 조절*.
+- **`var price` *테스트 노출* = 동어 반복** — *2,000원 변경 시에도 테스트 통과*하는 *부정 신호*. 테스트 함수명에 *명시 값*만 있어야.
+- **`PurchaseAmount` 클래스명에 *최소 단위 단서*** — *클래스명만 보고 책임 즉시 파악*이 OO 어휘 기준.
+- **`View는 멍청해야*** — *수동적*. *메시지 선택권* 최소.
+- **검증 위치 일원화** — *Input + 도메인 init* 양쪽이면 *의도적 중복*인지 *실수 중복*인지 명시.
+- **학생 필드 vs 생성자 자가 고민** — *임시 계산값*은 *필드 X, 반환값으로*. *var 회피*가 자연스럽게 *순수 함수*로.
+- **`코드 짜고 리뷰 요청*** — *글로만 설명*하면 리뷰어가 *추측에 의존*. *실제 코드 + 리뷰 요청*이 효율.
+- **「객체지향의 사실과 오해」 = 우테코 리뷰어들의 *공통 교과서*** — 학생들이 *책 인용 학습*하는 신호.

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

@@ -0,0 +1,149 @@
+# PR #132 — [로또 2단계] 환노 미션
+
+- **Reviewee:** [@hwannow](https://github.com/hwannow)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/132
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @lee-ji-hoon
+- **라인 코멘트:** 58
+
+## 잘한 점 (설계 관점)
+
+- **`LottoGenerator` 인터페이스로 자동 로또 추출 분리** — `LottoMachine`이 generator 구현체에 의존하지 않음.
+- **`LottoNumber` Flyweight 적용** — `(1..45).associateWith(::LottoNumber)`로 미리 생성한 인스턴스를 `from(value)`로 조회. `private constructor`까지 막아 외부 생성 차단.
+- **`var purchasableCount` 외부 변경 가능성을 본인이 의심** — public 가변 필드의 위험을 코멘트에서 명시.
+- **MVC 책임 경계에 대한 자가 의문** — View 분기 처리의 자리에 대해 학생이 먼저 논점 제기.
+- **`OrderSheet`로 입력 정보 묶기 시도** — 흩어진 입력값을 한 객체로 묶으려는 의도는 좋음.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto`가 테스트를 위해 `equals`/`hashCode` override
+
+```kotlin
+class Lotto(randomNumbers: List<LottoNumber>) {
+    override fun equals(other: Any?): Boolean {
+        if (this === other) return true
+        if (other !is Lotto) return false
+        return numbers.toSet() == other.numbers.toSet()
+    }
+    override fun hashCode(): Int = numbers.toSet().hashCode()
+}
+```
+
+리뷰어 지적: "지금 실제 도메인에서 사용이 되지 않는 equals hashCode로 확인이 됐는데요! 단순 테스트 관점에서 편의를 위해서 이렇게 변경을 하는 게 맞을까요?" — *테스트를 위해 도메인 내부 구조를 바꾸는 것*은 본말전도. 정렬 책임을 OutputView로 이동시키니 data class로 단순화 가능했음.
+
+### 2. `LottoPurchaseAmount`가 `lottoPrice`를 생성자 인자로 받음
+
+```kotlin
+class LottoPurchaseAmount(val money: Int, lottoPrice: Int) {
+    var purchasableCount: Int  // ⚠ public var
+    init { purchasableCount = money / lottoPrice }
+}
+```
+
+- **로또 가격을 누가 갖는가**의 책임 모호: `LottoMachine`도 알고 `LottoPurchaseAmount`도 받음. 리뷰어 비유 — "가격을 정해 주는 건 과자 가게이지만 가격이 매겨져 있는 건 과자 자체 아닐까요?"
+- **`var purchasableCount` public** — `lottoPurchaseAmount.purchasableCount = 10` 식으로 검증 후에도 외부에서 덮어쓸 수 있음.
+- **구매 금액 객체에서 구매 가능 수량이 나오는 것 자체가 어색** — 결국 `TotalPurchasableLottoCount`로 분리.
+
+### 3. `stringToLottoNumber(string: String)` — 시그니처에 타입 중복
+
+```kotlin
+private fun stringToLottoNumber(string: String): List<LottoNumber> {
+    val splitString = string.split(DELIMITERS).map { it.trim() }
+    return splitString.map { LottoNumber(it.toInt()) }
+}
+```
+
+리뷰어: "여기서 String이라는 정보가 들어갈 필요가 있을까요? string으로 받을 것이다! 라는 것을 이미 표현을 하고 있는 상태니까요!" — 함수명이 *입력 타입*을 기술하면 도메인 어휘가 사라짐.
+
+### 4. `LottoMachine`이 자동/수동/(가능한 하이브리드) 모두 한 클래스에서
+
+```kotlin
+class LottoMachine(.) {
+    fun buyLottos(orderSheet: OrderSheet): List<Lotto> {. }
+    private fun buyAutoLottos(lottoCount: Int): List<Lotto> {. }
+    fun buyManualLottos(lottos: List<String>): List<Lotto> {. }
+}
+```
+
+리뷰어 시나리오: "나중에 반자동 로또를 발급해 주는 것이 추가가 된다면 함수를 하나 더 추가를 하게 될까요? 이런 형태로 함수가 계속 늘어나다보면 하나의 Machine에 너무 많은 로직들이 들어가게 될 수 있고…" — 결국 `LottoGenerator` 인터페이스에 자동/수동/하이브리드 구현을 두는 **Strategy** 또는 generator 리스트 주입 방식을 권유.
+
+### 5. `OrderSheet`가 책임을 너무 많이 보유
+
+```kotlin
+class OrderSheet(
+    val purchaseAmount: LottoPurchaseAmount,
+    val manualLottoCount: ManualLottoCount,
+    val manualLottoNumber: List<Lotto>
+)
+```
+
+리뷰어 비교: "주문서의 역할이면 `수동 2장 / 자동 5장 / 총 얼마` 같은 정보만 갖고 있어야 하지 않을까요? 지금 보면 Lotto 자체도 들고 있고 ManualLottoCount도 들고 있다 보니 어색하네요." — 주문서는 *주문 의도*만, 완성된 `Lotto` 인스턴스는 머신의 출력물.
+
+### 6. View가 입력 재시도까지 통째로 처리
+
+```kotlin
+fun getManualLottoCount(): Int {
+    while (true) {
+        println(MESSAGE_INPUT_MANUAL_LOTTO_COUNT)
+        val input = intOrNull(readln())
+        if (input != null) return input
+    }
+}
+```
+
+`null` 반환만으로는 "왜 실패했는지" 정보가 사라짐. 리뷰어 제안 — `sealed interface InputResult { EmptyInput; NotNumber; Success(Int) }`로 *실패 유형*까지 타입에 담아야 View가 적절한 메시지를 띄울 수 있음.
+
+### 7. `ManualLottoCount`가 `purchasableCount`를 알아야 함
+
+```kotlin
+class ManualLottoCount(val lottoCount: Int, purchasableCount: Int) {
+    init { require(lottoCount <= purchasableCount) }
+}
+```
+
+리뷰어: "수동 로또 수가 총 구매 로또 수를 알아야 할 필요가 있을까요? 전체 구매 수량 → (수동, 자동)으로 묶여서 관리되는 게 맞지 않을까요?" — *수동 수가 가능 수를 안다*는 것은 책임의 역류.
+
+### 8. 테스트 이름이 "어떻게 실패하는지"를 기술
+
+```kotlin
+@ValueSource(ints = [-1, -2, -1000])
+fun `수동으로 구매할 로또 수로 0 미만의 숫자가 들어오면 IllegalArgumentException이 발생한다`(input: Int) {. }
+```
+
+리뷰어: "주요 관심사는 `0 미만의 숫자가 들어오면 안 된다`인데 이게 어떻게 0이 안 들어오게 하는지는 큰 관심사가 아닐 거예요. exception으로 방지를 하거나 null로 반환을 하거나 등등의 방법은 구현부에서 알아서 할 일이라고 생각" — 테스트명이 **구현 수단(Exception)** 을 가리키면 구현 바꿀 때 테스트도 갈아엎어야 함.
+
+### 9. `Lotto`가 정렬 시점을 저장 시점에 잡음
+
+저장 시점에 sort → data class 못 씀 → equals/hashCode 강제. 학생이 토론 후 "값을 정렬해서 보여 주는 건 UI 로직이다"로 결론. 핵심 — *정렬은 표현*이고, 표현은 OutputView. 도메인이 표현 형식을 가지고 있으면 출력 변경이 도메인 변경.
+
+## 리뷰어 의견 요지
+
+1. **"View는 멍청해야 한다"** — 단, 어디까지 멍청해야 하는지는 팀 합의. 데이터 분기/필터링/정렬이 *비즈니스적이면* 도메인, *표현적이면* View.
+2. **테스트를 위해 도메인 내부를 바꾸지 말 것** — equals override가 단지 테스트 비교를 위한 것이라면 잘못된 신호. 정렬 책임 자체를 옮기면 data class로 자연스럽게 비교 가능.
+3. **`null`보다 sealed로 실패 타입화** — `EmptyInput`/`NotNumber`/`Success` 같이 *실패 유형*을 타입에 담아야 호출자가 강제로 분기.
+4. **책임 비대 시 추상화** — `LottoMachine`에 메서드 늘리기 vs `LottoGenerator` 구현체 늘리기. 후자가 단일 책임 + 테스트 격리.
+5. **모든 원시 값/문자열 포장 원칙은 *가격*도 예외 아님** — `lottoPrice: Int`로 떠다니면 `LottoMoney`/`LottoPrice` 같은 타입이 어디에 속해야 하는지 자연스럽게 드러남.
+
+- **대표 인용:**
+  > 단순 테스트 관점에서 편의를 위해서 이렇게 변경을 하는 게 맞을까요? 단순 테스트만을 위한 방법이라면 다른 방법들이 더 있을 거 같은데 한 번 고민해보시면 좋을 거 같습니다.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+  > `var + public`이면 어떤 문제를 초래할 수 있을까요? Amount를 아는 곳에서 이 값을 의도적으로 변경할 수 있지 않을까요?
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/LottoPurchaseAmount.kt`
+
+  > 로또를 과자, 로또 머신을 과자 가게라고 생각했을 때, 가격을 정해 주는 건 과자 가게이지만 가격이 매겨져 있는 건 과자 자체 아닐까요?
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/domain/LottoPurchaseAmount.kt`
+
+  > `null`로만 반환하면 main 입장에서 "나는 무엇을 해야 하는 거지?"라는 것을 고민하게 될 거예요. sealed로 처리한다면 UI는 상태에 따라 표시할 Text를 정할 수도 있죠.
+  > — @lee-ji-hoon on `src/main/kotlin/lotto/view/InputView.kt`
+
+## 얻은 교훈
+
+- **테스트를 위해 도메인 내부 구조 바꾸지 말 것.** `equals`/`hashCode`/`toString` override의 동기가 "테스트 통과"라면 책임 위치 재고 신호. 정렬을 OutputView로 옮기니 data class로 자연스럽게 풀림.
+- **`var + public` 필드는 검증을 무효화.** `init { require(.) }`로 막아도 외부에서 setter로 덮어쓸 수 있으면 도메인 무결성 0. 모든 도메인 필드는 `val` 또는 캡슐화된 setter.
+- **`null`은 실패 *유형*을 못 담는다.** 실패 사유가 여러 가지(빈 입력 / 형식 / 범위)면 sealed로 타입화해야 호출자가 의미 있는 분기를 강제받음.
+- **함수 이름에 입력 타입이 들어가면 도메인 어휘 소실.** `stringToLottoNumber(string)` 대신 `parseLotto(input)` 또는 단순히 호출 위치에서 변환.
+- **"본인이 본인의 가격을 안다."** — 로또 가격을 `LottoMachine`/`PurchaseAmount`에 끼워 넣는 대신 `Lotto.price` 또는 `LottoPrice` 값 객체로. 두 곳이 같은 정보를 알면 둘 중 하나는 책임 침범.
+- **메서드 추가 vs 구현체 추가.** 동일 행위의 *전략*이 늘 때 메서드를 추가하면 클래스 비대 + 테스트 폭증. Strategy/구현체 분리가 테스트 격리·유지보수에 유리.
+- **테스트명은 *의도*, 구현 수단 아님.** `"X가 발생한다"` 보다 `"X는 허용되지 않는다"` — 검증 방식(예외/null/Result)이 바뀌어도 테스트명은 유지됨.
+- **`LottoNumber` Flyweight + `private constructor`** = 도메인 객체 수가 유한할 때의 표준 패턴. 추가로 `value class`(Kotlin)나 `record`(Java)로 한 단계 더 최적화 가능.

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

@@ -0,0 +1,141 @@
+# PR #77 — [해나] 1단계 로또
+
+- **Reviewee:** [@hxeyexn](https://github.com/hxeyexn)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/77
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 15
+
+## 잘한 점 (설계 관점)
+
+- **한정자 + 원시값 포장 (`LotteryNumber`)** — 리뷰어 칭찬: "한정자를 통해 외부에 공개하지 않고 *원시값 포장을 잘 해 주셨어요* 👍".
+- **`TicketGenerationStrategy` 인터페이스** — Strategy. 리뷰어 칭찬: "인터페이스 💯".
+- **PR 본문에 *4가지 자가 질문***: 캡슐화 복잡도, run vs apply, 중복 상수, 유효성 검증 위치.
+- **후속 라운드 *Set으로 중복 방지*, *전략 생성자 주입*, *가격 default param*** 모두 반영.
+
+## 못한 점 (설계 관점)
+
+### 1. `List` vs `Set` — 중복 방지 *자료구조*로 표현
+
+```kotlin
+class Lottery(private val lotteryNumbers: List<LotteryNumber>) {
+    init {
+        require(validateDuplicate(lotteryNumbers)) { EXCEPTION_DUPLICATED_NUMBER }
+    }
+    private fun validateDuplicate(lotteryNumbers: List<LotteryNumber>) = 
+        lotteryNumbers.size == lotteryNumbers.toSet().size
+}
+```
+
+리뷰어: "*중복된 번호에 대한 검증이 필요하다면 중복을 방지할 수 있도록 자료구조를 사용*해 보는 건 어떨까요?" — *제약을 타입으로 표현*. 학생: "*List 대신 Set을 사용해 중복을 방지*하도록 수정했습니다!"
+
+### 2. `toString()` 의존 — 문구 변경 시 도메인 변경
+
+```kotlin
+override fun toString() = "[${lotteryNumbers.map { it.number }.joinToString(", ")}]\n"
+```
+
+리뷰어: "지금은 *단순 출력문이기에 문제가 되지 않*지만 *view에 보여지는 문구를 수정해 달라는 요청이 왔을 때 도메인 모델의 toString() 함수를 수정*해야겠네요. *어떠한 문구에 의존하지 않고 여러 구분자에 대응이 가능*하도록 할 수 있을까요?"
+
+### 3. `LottoNumber.fromInput`의 `split` — View 책임
+
+```kotlin
+fun fromInput(input: String): Lottery {
+    return input.split(LOTTERY_DELIMITER).map { LotteryNumber.fromInput(it) }
+.run { Lottery(this) }
+}
+```
+
+리뷰어: "위와 동일합니다. 또한, *split하는 로직은 view와 관련이 있어 보이*네요." — *문자열 파싱* = View 책임. 도메인은 *List<Int>* 받기.
+
+### 4. `LOTTO_TICKET_PRICE` *내부 상수 의존* — 가격 인상 시 변경 범위 큼
+
+```kotlin
+class RandomTicketGenerationStrategy(private val amount: Amount) {
+    override fun issueTicket(): Ticket {
+        repeat(amount.money / LOTTO_TICKET_PRICE) {. }  // ⚠ 내부 상수
+    }
+}
+```
+
+리뷰어: "현재는 로또 가격이 1000으로 고정되어 있어서 문제가 없지만 *로또 가격이 인상되었다면, 검증하는 비즈니스 로직 내부 코드도 변경되어야 하고 테스트 코드도 변경*되어야 합니다. *내부 상수에 의존하지 않고 유연하게 대처*해 볼까요?" 학생: "주 생성자에 *로또 가격을 추가하고, 기본 값을 두어 가격이 인상되면 주 생성자의 디폴트 값만 변경*할 수 있도록 하여 비즈니스 로직 내부 코드와 테스트 코드는 변경되지 않도록 수정했습니다!" 후속 리뷰어: "기본 값이 있는 *파라미터 활용으로, 비즈니스 로직을 보다 유연*하게 활용할 수 있게 되었네요".
+
+### 5. *랜덤 요소 외부 주입*
+
+리뷰어: "*랜덤의 요소가 변경되면 비즈니스 로직도 변경되어야 할까요*? 로또 뿐 아니라 *랜덤 요소가 변경되어도 랜덤 요소를 외부로부터 주입받아 LottoNumberGenerator 로직을 재사용 가능*하게끔 해볼까요?" — *함수형 인터페이스 또는 LottoNumberGenerator 분리*.
+
+### 6. `LotteryStore.setStrategy()` *Builder 패턴 가짜*
+
+```kotlin
+class LotteryStore {
+    private var ticketGenerationStrategy: TicketGenerationStrategy = DefaultTicketGenerationStrategy()
+
+    fun setStrategy(ticketGenerationStrategy: TicketGenerationStrategy): LotteryStore {
+        this.ticketGenerationStrategy = ticketGenerationStrategy
+        return this
+    }
+}
+```
+
+리뷰어: "Controller에서 *실수로 strategy를 설정해 주지 않으면 DefaultTicketGenerationStrategy으로 테스트 코드가 출력*이 될 수 있겠네요.! *어떻게 하면 LotteryStore를 사용할 때 테스트 코드에서는 TestStrategy, 로또에서는 LottoStrategy를 사용하도록 유도*할 수 있을까요?" 학생: "주 생성자로 *TicketGenerationStrategy을 의존성 주입*하여 테스트 코드에서는 ExplictStrategy, 로또 스토어에서는 RandomStrategy를 사용하도록 유도하게 수정했습니다!" 후속 리뷰어: "*어떠한 전략을 따르는 로또가게*인지를 나타내게 되었네요 👍". — *생성자 주입 = 의무 명시*, *setter 주입 = 실수 허용*.
+
+### 7. `.run`/`.apply` 남용 — 학생 질문
+
+학생 질문 (PR 본문): "run은 람다 식의 결과를 반환해 주고, apply는 수신 객체 자체를 반환해 준다고 알고 있습니다. *이를 적용할 때마다 어떤 걸 사용해야 하는지 아직 기준이 모호*할 게 느껴질 때가 많은데." 리뷰어: "*저는 개인적으로 run 대신 의미 있는 변수를 사용하여 표현*하려고 하며, apply는 *하나의 변수에 반복되는 패턴(ex. builder) 같은 경우 통일성*을 주기 위해 apply 블럭 안에서 설정해 주곤 합니다." 학생 후속:
+```diff
+-return numbers.map { LotteryNumber(it) }.run { Lottery(this) }
++val lotteryNumbers = numbers.map { LotteryNumber(it) }
++return Lottery(lotteryNumbers)
+```
+리뷰어 칭찬: "*변수 활용으로 가독성이 한층 높아졌네요* 👍 이제 *어떤 값을 반환하려는 함수인지 보다 명확*해졌어요."
+
+### 8. *중복 상수 위치* — 학생 자가 질문
+
+학생: "1. 각각의 파일에서만 사용되는 부분은 각각의 파일에서 관리하고, *공통적으로 쓰이는 상수들은 별도의 상수 파일을 만들어서 관리*. 2. 지금처럼 각각의 파일에서 필요한 상수는 각각의 파일에서 관리. 이건 해나의 의견도 궁금하네요." 리뷰어: "*단지 2번의 경우에는 수정이 필요할 때 모든 곳에서 수정을 요구*하겠죠? *실수로라도 바꾸지 않았다면 상이한 결과*를 나타낼 겁니다." — *유지보수 단위*는 *단일 진입점*.
+
+### 9. *init vs 팩토리 메서드* — 학생 자가 질문
+
+학생: "유효성 검증을 *init 블록에서 처리하는 방법과 팩토리 메서드에서 처리하는 방법, 이 두 가지를 같이 사용*했는데." 리뷰어: "*복잡하다는 건 어느 정도가 복잡한 걸까요*?🧐 *팩토리 메서드를 통해 로또 상점 객체를 만들 때 검증을 하는 과정을 담당*할 수 있겠고 *로또 상점 객체가 만들어지고, 로또를 생성할 때 로또의 init 블럭에서 검증*을 진행할 수 있겠네요. 말그대로 *팩토리 메서드는 객체를 만들어 내는 공장(Factory)을 만드는 패턴*이라고 생각해 주시면 될 것 같습니다." — *init = 자기 invariant*, *factory = 입력 변환 + 객체 생성 결정*.
+
+### 10. ktlint
+
+리뷰어: "*ktlint를 확인*해 주세요!" (이미지 첨부).
+
+## 리뷰어 의견 요지
+
+- **제약을 *타입/자료구조*로 표현** — 중복 방지 = Set.
+- **`toString` View 책임** — *문구 변경 시 도메인 안전*.
+- **문자열 *split*은 View** — 도메인은 *변환된 입력*.
+- ***Default* 파라미터로 *생성자 가격 주입***.
+- **랜덤 *외부 주입***.
+- **`setStrategy` 가짜 Builder X** — *생성자 주입 강제*.
+- **`.run`/`.apply` *남용 회피*** — 의미 있는 변수.
+- **상수 *단일 진입점*** — 분산 시 변경 누락 위험.
+- **`init` = 자기 invariant, `factory` = 입력 변환 + 생성 결정**.
+
+- **대표 인용:**
+  > 중복된 번호에 대한 검증이 필요하다면 *중복을 방지할 수 있도록 자료구조를 사용*해 보는 건 어떨까요?
+  > — @KwonDae on `src/main/kotlin/model/Lottery.kt`
+
+  > view에 보여지는 문구를 수정해 달라는 요청이 왔을 때 *도메인 모델의 toString() 함수를 수정해야겠*네요. *어떠한 문구에 의존하지 않고 여러 구분자에 대응이 가능*하도록 할 수 있을까요?
+  > — @KwonDae on `src/main/kotlin/model/Lottery.kt`
+
+  > Controller에서 *실수로 strategy를 설정해 주지 않으면* DefaultTicketGenerationStrategy으로 테스트 코드가 출력이 될 수 있겠네요.!
+  > — @KwonDae on `src/main/kotlin/model/LotteryStore.kt`
+
+  > 단지 2번의 경우에는 수정이 필요할 때 *모든 곳에서 수정을 요구*하겠죠? *실수로라도 바꾸지 않았다면 상이한 결과*를 나타낼 겁니다.
+  > — @KwonDae on README.md 
+
+## 얻은 교훈
+
+- **제약을 *자료구조*로 표현** — *중복 방지*는 검증이 아니라 *타입* (`Set`). *불가능한 상태*를 *불가능한 타입*으로.
+- **`toString` 도메인 침투 = 미래 비용** — *문구 변경 요청* 시 *도메인 변경*.
+- **문자열 `split`은 View** — 도메인은 *변환된 입력* (`List<Int>`).
+- **`Default` 파라미터로 *변경 단일 지점*** — `lottoTicketPrice: Int = 1_000`는 *가격 인상 시 한 줄 변경*.
+- **랜덤 *외부 주입*** — *함수형 인터페이스* (`() -> Int`)로 *테스트 가능성* + *재사용*.
+- **`setStrategy` 가짜 Builder X** — *Controller가 까먹으면 Default*인 *암묵 의존*. 생성자 주입 = *의무*.
+- **`.run`/`.apply` 회피** — *지역 변수 + 명시적 호출*이 *어떤 값을 반환하는지* 드러냄. 리뷰어 칭찬: "변수 활용으로 가독성 높아졌네요".
+- **상수 *공통 상수 파일*** — 분산 관리 시 *수정 누락*. *단일 진입점*.
+- **`init` = *자기 invariant*** (개수, 범위), **`factory` = *입력 변환 + 생성 결정*** (String → List<Int>). 둘 다 사용 정당.
+- **자가 4가지 질문을 PR 본문에 정리** — 리뷰어가 *체계적 응답* 가능. 좋은 *PR 설명 패턴*.
+- **ktlint** — *형식 자동화*는 *코드 리뷰의 첫 게이트키퍼*.