oh-my-oop 0.2.0

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

@@ -0,0 +1,141 @@
+# PR #80 — [채드] 1단계 로또
+
+- **Reviewee:** [@dpcks0509](https://github.com/dpcks0509)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/80
+- **단계:** 1단계
+- **리뷰어:** @ghojeong (파이로)
+- **라인 코멘트:** 15
+
+## 잘한 점 (설계 관점)
+
+- **`enum Rank(countOfMatch, winningAmount)`** — 등수+상금 응집.
+- **`Lottos(List<Lotto>)`, `Lotto(List<Int>)` 일급 컬렉션 시도** — 비록 책임 없어 폐기 권고 받음.
+- **`InputValidator` 예외 *세세한 테스트*** — 리뷰어 칭찬: "*예외 처리에 대해 세세한 테스트를 남겨 주신 점 좋습니다.* 👍 보통 *성공 시나리오에 대해서만 테스트하지, 실패했을 예외에 대한 테스트는 귀찮아할 수 있는데 꼼꼼*하시네요. 👍".
+
+## 못한 점 (설계 관점)
+
+### 1. 일급 컬렉션 = *역할 + 책임* 있을 때만
+
+```kotlin
+class Lottos(val publishedLottos: List<Lotto>) {
+    override fun toString(): String {
+        return publishedLottos.joinToString("\n")
+    }
+}
+
+open class Lotto(val numbers: List<Int>) {
+    override fun toString(): String {
+        return numbers.sorted().joinToString(", ", "[", "]")
+    }
+}
+```
+
+학생 의문: "*일급 컬렉션을 어떨 때 사용해야 하는지 기준*과 *어디까지 일급 컬렉션을 사용해야 하는지* 이해가 잘 가지 않습니다. 예를 들어서, *List<Int> numbers를 의미하는 Lotto를 만들고 List<Lotto>를 의미하는 Lottos를 또 다시 일급 컬렉션으로 만드는 게 맞는지* 궁금합니다." 
+
+리뷰어: "필요하다면 *끊임없이 일급 컬렉션을 만들어 나가야* 합니다. 그리고 *만약 새로 만든 일급 컬렉션이 불편하다면 일급 컬렉션으로 만들지 않으면 됩니다*. 가령 저는 안드로이드 개발을 처음 할 때 *테트리스 게임*을 만들었었는데, *중첩된 일급 컬렉션을 만들기 싫어서, 1차원 리스트(배열)만을 활용*하여, 2차원으로 렌더링 되는 테트리스를 그렸습니다. 그리고 제 맹세컨대 *1차원으로 테트리스를 개발하니 중첩된 2차원의 일급 컬렉션보다 훨씬 어려워서 고생*을 했습니다. 만약 3차원의 물체를 다루는 안드로이드 앱을 만들게 된다면, 저는 *일급 컬렉션의 일급 컬렉션의 일급 컬렉션*을 만들겁니다. ㅋㅋㅋㅋ"
+
+리뷰어 (별도 위치, 핵심): "*반면 저는 중첩된 일급 컬렉션이 문제가 아니라, 채드의 일급 컬렉션의 역할과 책임이 없어서 문제*가 되는 것 같습니다. *일급 컬렉션을 만드는 이유는 객체가 하나일 때와, 그 객체가 여러 개일 때, 할 수 있는 역할과 책임이 달라지고, 그에 따라 테스트가 필요한 개성 있는 메서드를, 일급 컬렉션이 가지게 되기 때문*입니다. 하지만 제가 느끼기에 *Lotto와 Lottos 모두, toString만 override가 되어 있을 뿐 테스트가 필요한 비즈니스 로직이 존재하지 않*습니다. 그렇기에 제 입장에서 *Lotto와 Lottos 둘 다 일급 컬렉션으로 분류하지 않*습니다."
+
+→ **테스트할 비즈니스 로직 = 일급 컬렉션 자격 기준.**
+
+### 2. `Lotto` `open class` + 상속 — 의도 불명
+
+```kotlin
+open class Lotto(val numbers: List<Int>) {. }
+
+open class WinningLotto(private val winningNumbers: List<Int>, private val bonusNumber: Int) : Lotto(winningNumbers) {
+.
+}
+```
+
+리뷰어: "Lotto와 WinningLotto를 *open class로 하신 의도*가 궁금합니다. *kotlin이 class를 상속하려면 open이라는 키워드를 필요하게끔 한 이유*는, *abstract class와 interface가 아닌 일반 클래스는 되도록 상속을 하지 않도록 프로그래밍 언어적으로 제약을 걸으려 하였기 때문*입니다. *어떤 유용함 때문에 제약을 해제하였는지 채드의 의도*가 궁금합니다." 학생: "Lotto에서 numbers를 가지고 있고 WinningLotto에서도 lotto의 numbers를 사용하니 *Lotto를 상속받아서 이용하면 좋을 것이라고 생각*했는데 피드백을 보고 다시 보니 *상속을 할 이유가 없어 보여서 해제*하였습니다." — *데이터 재사용을 위한 상속*은 안티. *합성*이 자연.
+
+### 3. `Buyer.lateinit var lottos` — *세터 메서드*가 본질
+
+```kotlin
+class Buyer(private val purchaseAmount: Int) {
+    val numberOfLotto: Int = calculateNumberOfLotto()
+    lateinit var lottos: Lottos  // ⚠
+
+    fun buyLottos(lottos: Lottos) {
+        this.lottos = lottos
+    }
+}
+```
+
+리뷰어: "lottos를 굳이 *lateinit var로 선언한 이유*가 궁금합니다. 저에게 *buyLottos는 단순한 세터 메서드처럼 느껴지기 때문*입니다." 학생: "Buyer 클래스 안에서 lottos를 생성하기 보다는 *바깥에서 생성된 lottos를 받아와서 선언해 주는 게 좋겠다*고 생각해서 *lateinit var을 사용해서 나중에 초기화*하려고 생각했습니다. 코드를 리팩토링하다 보니 *Buyer 클래스는 필요가 없다고 판단되어 제거*하고 calculateNumberOfLotto 메소드를 외부에 선언하였습니다." — *역할 없는 객체* 폐기.
+
+### 4. `Rank.countOfMatch`만 *매직넘버* — 일관성 부재
+
+```kotlin
+enum class Rank(val countOfMatch: Int, val winningAmount: Int) {
+    FIRST(6, Constant.FIRST_RANK_WINNING_MONEY),  // ⚠ 6은 매직, FIRST_RANK는 상수
+    SECOND(5, Constant.SECOND_RANK_WINNING_MONEY),
+.
+}
+```
+
+리뷰어: "winningAmount는 Constant에 상수로 정의했지만, *countOfMatch는 Rank enum 안에 매직넘버로 사용하신 이유*가 있나요? *countOfMatch와 winningAmount가 어떻게 다른지, 왜 다르게 구현*하셨는지 채드의 기준이 궁금해서 여쭈어봅니다." 학생: "*countOfMatch는 Rank 클래스 안에서만 사용*되고, *winningAmount가 다른 클래스에서도 사용*될 줄 알고 상수 선언을 했었습니다. 그런데 Rank 파일에서만 winningAmount가 사용이 되어서 *Rank 파일 내에서 상수 선언을 하려 했는데 enum class 안에서는 상수 선언이 안 된다고 하여 상수 선언하는 것을 해제*하였습니다." — *enum 자체가 상수*. companion object에 const 가능.
+
+### 5. `WinningStatistic.toString` — 다국어 + 모델 변경 위험
+
+```kotlin
+class WinningStatistic(val result: Pair<Rank, Int>) {
+    override fun toString(): String {
+.
+        return "${rank.countOfMatch}개 일치${", 보너스 볼 일치".takeIf { result.first.ordinal == 1 } ?: " "}(${rank.winningAmount}원)- ${count}개"
+    }
+}
+```
+
+리뷰어 (1차): "*toString만을 override하는 클래스가 모델에서 굉장히 많이* 보입니다. 안드로이드 앱을 개발하다가 *앱이 잘 나가면 다국어 지원을 해야 하는 경우*가 종종 생깁니다. 만약 *한국어로 만든 앱이 잘 되어서, 영미권에 동일한 앱으로 진출*을 하려 한다면 *어떻게 언어 확장*을 하려 하시나요?"
+
+학생 자가 질문: "*toString을 override해서 출력 형식을 커스텀하는 것과 get메소드를 새로 추가하여 String을 반환하는 것으로 하는 것의 차이*가 있는지 궁금합니다. *다국어 지원을 할 때 언어 확장을 할 수 없는 단점 때문에 toString을 지양*하는 것이 좋은 건가요?"
+
+리뷰어: "*저는 별로 차이가 없다고 생각*합니다. 아뇨. *근본적으로는 문구 수정을 할 때 model의 소스코드를 까서 수정해야 한다는 점이 단점*입니다. 가령 채드가 *유일한 안드로이드 개발자*인 상황에서, 기획자가 문구를 더 자극적으로 바꾸었다고 가정해 봅시다. (안드로이드는 팀이 굉장히 작은 경우가 종종 있습니다.) *'XXX개를 맞추었고, 보너스 볼! 까지 맞추었습니다!!'* 그 상황에 *채드가 휴가*를 갔다고 가정해 봅시다. *model은 비즈니스 로직을 담고 있기에, 출근한 동료 개발자는 굉장히 신중하게 수정*하려 할 겁니다. *만약 잘못 수정하면 화면에 표시가 잘못되는 것을 넘어, 중대한 버그나 크래시를 일으킬 수 있기 때문*입니다. 동료는 *간단한 문구 수정임에도 불구하고 채드에게 WinningStatistic 모델만 수정하면 될지, 혹시 더 추가로 살펴봐야 하는 모델은 없는지 코드 리뷰 요청*을 보낼 수 있습니다. *휴가 중에 동료의 요청을 채드가 즐겁게 대응할 수 있다면, 문제가 없*습니다. 하지만 저는 *개인적으로 별로 즐겁지 않았기에 제 개인 경험을 공유*해 보았습니다." — *경험 기반 가르침*.
+
+### 6. Controller의 `makeRandomNumbers` + `drawSixNumbers` *불필요한 분리*
+
+```kotlin
+private fun generateLottoNumbers(): List<Int> {
+    val numberGenerator = NumberGenerator()
+    val randomNumbers = numberGenerator.makeRandomNumbers()
+    return numberGenerator.drawSixNumbers(randomNumbers)  // ⚠ 항상 연달아
+}
+```
+
+리뷰어: "어차피 *makeRandomNumbers와 drawSixNumbers는 반드시 같이 쓰일 수밖에 없는데, 굳이 메서드를 분리한 이유*가 있나요? *분리함으로 인해 어떤 유연함 혹은 장점이 생겼는지* 궁금합니다." 학생: "한 메소드에서 *한 가지 행동만 하게 하려고 두 가지 메소드로 분리* 하였는데 *굳이 불필요한 행동이었던 것* 같습니다. 따로 *LottoGenerator object를 생성하여 하나의 메소드로 통일*시켜 보았습니다!" — *SRP 오해*: *함수 한 줄 = 한 책임*이 아니라 *변경 이유 한 가지*.
+
+## 리뷰어 의견 요지
+
+- **일급 컬렉션의 정당화 = *비즈니스 로직 + 테스트 메서드*** (역할/책임).
+- **중첩 일급 컬렉션은 OK** — *각자 책임 있으면*.
+- **상속 사용에 *유용함 근거* 필요** — 데이터 재사용은 상속 X.
+- **`lateinit var` = *세터 메서드 신호*** — *역할 검토*.
+- **`enum`의 `countOfMatch` vs `winningAmount` *일관성*** — 상수 처리 통일.
+- **`toString()` 다국어 문제 + *휴가 시 동료가 model 수정 위험*** = View로.
+- **함수 *항상 같이 쓰임* = SRP 오해**.
+
+- **대표 인용:**
+  > 반면 저는 중첩된 일급 컬렉션이 문제가 아니라, *채드의 일급 컬렉션의 역할과 책임이 없어서 문제*가 되는 것 같습니다.
+  > — @ghojeong on `src/main/kotlin/model/Lotto.kt`
+
+  > kotlin이 class를 상속하려면 open이라는 키워드를 필요하게끔 한 이유는, *abstract class와 interface가 아닌 일반 클래스는 되도록 상속을 하지 않도록 프로그래밍 언어적으로 제약을 걸으려 하였기 때문*입니다.
+  > — @ghojeong on `src/main/kotlin/model/WinningLotto.kt`
+
+  > model은 비즈니스 로직을 담고 있기에, *출근한 동료 개발자는 굉장히 신중하게 수정*하려 할 겁니다. 만약 잘못 수정하면 *화면에 표시가 잘못되는 것을 넘어, 중대한 버그나 크래시를 일으킬 수 있기 때문*입니다.
+  > — @ghojeong on `src/main/kotlin/model/WinningStatistic.kt`
+
+  > 어차피 makeRandomNumbers와 drawSixNumbers는 *반드시 같이 쓰일 수밖에 없는데, 굳이 메서드를 분리한 이유*가 있나요?
+  > — @ghojeong on `src/main/kotlin/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **일급 컬렉션 = *행동/책임 있을 때***. 단순 `List` 감싸기 + `toString`은 자격 미달. *테스트할 메서드*가 신호.
+- **중첩 일급 컬렉션 OK** — *테트리스 1차원 vs 2차원* 비유. 자연스러운 차원만큼 감싸기.
+- **상속은 *재사용 도구 아님*** — Kotlin이 `open` 키워드 강제하는 건 *상속 회피*가 기본 방침이라는 언어적 신호.
+- **`lateinit var = 세터 메서드*** — *나중에 초기화*는 *순서 의존*. 책임이 *외부 입력 수용*이라면 *생성자 인자*로.
+- **`enum` 자체가 상수** — 별도 상수로 다시 뽑을 필요 X. *일관성*은 *내부 표현 결정*에 따라.
+- **`toString()` 문구 = *모델 변경 위험*** — *휴가 중 동료가 model 수정*하려면 *부담*. View 매핑이 *안전*.
+- **함수 *항상 같이 쓰임* = 한 함수일 수 있음** — SRP는 *변경 이유 한 가지*이지 *함수 한 줄*이 아님.
+- **예외 테스트도 *경계값 다수*** — `"-1000"`, `"0"`, `"999"`, `" 1000 "`, `" "`, `""`, `"oneThousand"` 같은 *다양한 실패 경로*가 *명세*.

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

@@ -0,0 +1,134 @@
+# PR #87 — [채드] 2단계 로또
+
+- **Reviewee:** [@dpcks0509](https://github.com/dpcks0509)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/87
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @ghojeong (파이로)
+- **라인 코멘트:** 28 (리뷰어 23 + 학생 5)
+
+## 잘한 점 (설계 관점)
+
+- **매직 넘버 *모두 상수화*** — 칭찬: "*매직 넘버들을 모두 상수로 훌륭하게 선언*해 주셨군요. 👍".
+- **`Strategy 패턴` 자발 도입** — 리뷰어 칭찬: "*전략 패턴이라는 키워드를 알려드리지 않았음에도, 스스로 적용해 주시다니 대단*하시네요. *다른 크루분들께 정보를 공유받으셨을까요? 아니면 직접 생각해 내셨나요*?"
+- **수동 로또 *테스트 작성*** — 칭찬: "*수동 로또 발행에 대해서도 꼼꼼히 테스트를 작성해 주신 점 좋습니다*. 👍".
+
+## 못한 점 (설계 관점)
+
+### 1. *도메인 init vs 입력 검증* — 이중일?
+
+학생: "*입력을 받을 때 입력값 검증을 통해 잘못된 값이 들어오면 오류를 발생하도록 구현을 해 놓아도 model 안에서도 init, require를 통해서 값을 검증하는 것이 좋은 방법인 건지, 이중일을 하는 불필요한 행동인지* 궁금합니다."
+
+리뷰어: "*저는 값의 검증에 관해서는 중복되어 보이더라도 무조건 여러 번 하는 것을 좋아*합니다. *view와 model은 지금은 패키지만 분리되어 있지만, 최종적으로는 별개의 모듈로 분리될 수 있다고 생각*하시면 좋습니다. 만약 *채드님이 취업하신 조직의 부서 구조가 셀 단위가 아니라, 모듈 단위로 부서가 분리되어 있을 경우, model을 담당하는 부서와 view를 담당하는 부서가 아예 다를 수* 있습니다. 그리고 저는 *팀원에게는 강한 신뢰를 갖지만, 외부 조직 및 부서는 같은 팀이 아니기에 실체를 알 수 없는 블랙박스*라 생각합니다. 즉 *view를 담당하는 부서에서 입력값 검증을 했다고는 하지만, 실제로는 제대로 검증을 안 하는 경우*가 생깁니다. 설사 채드님이 view와 model을 둘 다 구현하셨다고 하더라도, *model보다 더 빈번히 수정되는 view는 언제든지 다른 누군가에 의해 검증 로직이 잘못되거나 삭제될 수* 있습니다. 그러므로 저는 *차라리 배포 전에 테스트를 실패하거나 동작이 실패하게끔, model과 view 상관없이 검증 로직을 최대한 많이 넣는 편*입니다." — *부서 단위 분리* + *외부 조직 블랙박스* 시나리오.
+
+### 2. `toString` 남용? — MVC 분리
+
+학생: "*model에 대한 출력을 할 때 저는 toString을 통해서 출력에 대해 컨트롤하였는데 다른 크루들은 toString을 많이 안 써서 구현을 했던데 toString을 남용하는 것이 안 좋은 습관인지, get 함수를 통해서 그냥 model에서 값만 받아오고 outputView에서 값을 가공해서 출력하는 것이 더 좋은 방법인지* 궁금합니다."
+
+리뷰어: "*이전과 달리, 문구를 const로 선언해 주신 점 좋*습니다. 👍 *toString을 남용하는 것은 안 좋은 습관이 아닙니다. toString이 view와 연관이 깊다는 게 문제*입니다. *MVC의 핵심은 Model과 View가 얼마나 잘 분리되어 있는지*이고, *이 분리는 model에서 제공하는 함수 및 값이 view의 요구사항 변경에 영향을 받으면 안 된다는 것을 뜻*합니다. *문구의 수정은 개발팀의 리팩토링이 아닌, 기획팀의 문구 첨삭을 통해서 이루어*집니다. 그렇기에 저는 *모델에서 한국어 문구를 렌더링하는 모든 문구를 view의 영역이라고* 보고 있습니다." 추가: "*개발에 더 좋은 방법은 없습니다. 상황에 필요한 방법만이 있을 뿐*입니다. *돈을 받고 일하는 입장에서, 만약 돈을 주는 조직이 model에서 toString을 통해 문구를 렌더링하라는 요구를 한다면 저는 채드가 구현하신 것처럼 할 것*입니다." — *조직 요구사항 우선*.
+
+### 3. `object` vs `class` — 블로그 인용
+
+학생: "*view에 대한 파일들을 object로 선언한 크루도 있고 class로 선언한 크루도 있던데, object와 class를 선언하는 기준을 어떻게 잡아야 하는지* 궁금합니다."
+
+리뷰어: "관련해서 *[안드로이드 6기 동기분이 좋은 블로그 글](https://velog.io/@kmkim2689/Kotlin-%EC%83%9D%EC%84%B1%EC%9E%90-%EB%B3%80%EC%88%98%EA%B0%80-%EC%97%86%EB%8A%94-%EA%B2%BD%EC%9A%B0-class%EC%99%80-object-%EC%A4%91-%EC%96%B4%EB%96%A4-%EA%B2%83%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%A0%EA%B9%8C)을 쓰셨던데*, 참고를 하시면 좋을 것 같습니다. 제가 위 블로그 글에서 제일 마음에 들었던 부분은 *'No Silver Bullet'*입니다. 제 정말 솔직한 심정은 *'어느 쪽으로 해도 크게 상관없다, 성능 상 크게 차이도 없으며, 설사 있더라도 그 장단점을 느끼기에는 프로젝트의 요구사항이 많지 않다.'*입니다. *view에 대해서 너무 시간을 쏟기 보다는 model에 대해서 시간을 더 쏟으면 좋을 텐데*입니다. *view는 보통 직접 구현하는 경우가 없고, 전적으로 프레임워크에 의존하게 되는 경우가 많*습니다."
+
+### 4. 테스트 패키지 = main 미러링
+
+리뷰어: "*test/kotlin 내부의 패키지 구조를 main/kotlin의 패키지 구조와 동일하게* 해 주세요. 가령 *model과 관련 테스트들은 test/kotlin/model 안에 배치하면, 테스트에 필요한 model 클래스를 import할 필요가 없게* 됩니다."
+
+### 5. *테스트 클래스 1:1 매핑*
+
+리뷰어: "*테스트 클래스 명은, 테스트하려는 클래스와 1대 1 매핑이 되도록* 해 주시면 좋습니다. 가령 *InputTest는 실제로는 InputValidator에 대한 테스트를 해 주고 있으므로, InputValidatorTest라고 이름을 바꿔* 주시면 좋습니다.".
+
+### 6. *모델 책임 = 테스트 가능성*
+
+리뷰어: "*모델의 역할과 책임이 잘 나누어져 있는가? 를 판단할 때, 저는 '각 모델 클래스 별로 유의미한 테스트를 편하게 작성할 수 있는가?'로 판단*합니다. *모델 클래스에서 테스트하는 내용이, 곧 그 모델의 역할과 책임이기 때문*입니다. *테스트 주도 개발*을 하면 *테스트를 실제 구현보다 앞서 우선시*해야 합니다. *모델의 역할과 책임 또한 그 모델의 실제 구현 로직이 아니라, 테스트를 통해 판단할 수 있어야* 합니다. 왜냐하면 *테스트를 실패했을 시, 요구사항이 바뀐 게 아니라면 수정해야 할 것은 테스트가 아니라 실제 구현체이기 때문*입니다." + "*특히 model 안에 있는 LottoGenerator로 인하여 테스트가 어려우리라 생각*되는데, *자동차 미션 때와 마찬가지로, 로또 미션에서 학습해 내야 하는 모델 설계의 핵심*이라고 강조해 봅니다."
+
+### 7. `Pair` *값 의미 모호*
+
+```kotlin
+val result: Pair<Int, Int> =.  // ⚠ first가 뭐고 second가 뭐?
+```
+
+리뷰어: "*제가 채드님의 동료라고 생각했을 때, pair의 값이 무슨 값인지 예상하기 어렵다는 생각*이 듭니다.. *다른 동료가 이 코드를 유지보수할 때는 pair의 값(pair.first와 pair.second)을 로직을 확인해야 알 수* 있지 않을까요? 관련 글을 하나 추천해 봅니다. *[Prefer Data Classes Over Pairs](https://proandroiddev.com/prefer-data-classes-over-pairs-42b8a39e5e37)*" — *Pair*는 *호출자 컨벤션 의존*. *data class*는 *필드 이름*.
+
+### 8. *매직넘버 -1, 0*
+
+리뷰어: "*-1은 매직넘버이군요. model, view, util 상관없이 매직넘버는 피해* 주세요. *null의 경우에는 차라리 exception을 던져서 예외 처리를 하는 것은 어떨까요*?" + "*0도 마찬가지로 매직넘버라 생각하고 상수화* 부탁드립니다!"
+
+### 9. `drawWinningLotto` *네이밍* — UI인 줄
+
+리뷰어: "*컨트롤러에서 drawWinningLotto라는 이름을 보았을 때, displayPurchaseResult나, analyzeWinningStatics와 마찬가지로, 리턴값 없이 view와 상호작용하는 메서드라고 생각*했습니다. *drawWinningLotto보다 좀 더 좋은 네이밍을 고민*해 주시면 좋을 것 같습니다." — `draw`는 *그리다*로 오해.
+
+### 10. `LottoPrize.ordinal` 의존 — enum 추가 시 위험
+
+```kotlin
+result[lottoPrize.ordinal] =.  // ⚠ ordinal에 의존
+```
+
+리뷰어: "*로또 규칙에 따라 LottoPrize enum 숫자가 정해져 있기 때문에, 지금은 ordinal을 result list에 넣어도 상관이 없어 보입니다*. 하지만 이렇게 규칙이 명확하고 정해져 있으면 상관없지만, *개발을 하다 보면 기획 변경에 따라 enum은 바뀔 여지가 있고, 위와 같은 코드는 enum 추가, 수정, 삭제될 때마다 유지보수 중 실수를 발생시킬 수* 있어 보입니다. *enum을 추가하거나 삭제하더라도 수정할 코드가 없도록 개선*해 주시면 좋을 것 같습니다." — *ordinal 의존성*은 *순서 깨짐 위험*.
+
+### 11. `repeat + index` 활용 vs `forEach`
+
+리뷰어: "*index를 직접 사용해야 하는 상황이라면, repeat 문이나 전통적인 for 문이나 별 차이가 없어 보입니다*. *repeat 대신 차라리 forEach를 활용*하면 어떨지 제안해 봅니다."
+
+### 12. *exception 던지기 vs 예외 처리* — 리뷰어 *자기 정정*
+
+리뷰어: "exception을 던져 보면 어떨까? 라는 피드백을 드렸는데, *잘못된 입력을 했을 때, 앱을 강제 종료하는 것을 원하는 상황이 아니므로, exception은 던지지 않도록 하는 게 맞는 것* 같습니다. *과제를 다시 자세히 읽어 보다가, 힌트 중에 '예외 처리를 통해 에러가 발생하지 않도록 한다.' 조건이 있어서 피드백 수정*하려고 연락드렸습니다." + "*혹시 제가 드린 피드백 중에서 궁금하거나 납득이 어려운 부분이 있다면, 언제든 질문주세요! 제가 실수를 했을 수도 있으니까요*!" — *리뷰어의 솔직한 자기 정정*. 패턴.
+
+### 13. *수동/자동 발행 통합* — 인터페이스 추상화
+
+리뷰어: "*수동 로또 발행은 publishHandpickedLottos를 통해서, 자동 로또 발행은 lottos.publishLottos로 하고 있는 듯이* 보입니다. *깊게 생각해 보면 '수동 로또 발행'과 '자동 로또 발행'은 수동으로 사용자가 입력해서 숫자를 생성하느냐, 자동으로 랜덤 라이브러리가 숫자를 생성하느냐에 대한 차이만이 있을 뿐 둘 다 똑같은 '로또 발행'이라는 것*을 알 수 있습니다. *'수동 로또 발행'과 '자동 로또 발행'이 최대한 동일한 로직, 동일한 함수, 동일한 객체, 동일한 인터페이스를 활용할 수 있도록 리팩토링에 도전*해 보시기 바랍니다. *힌트는 '로또 발행'에 관련한 인터페이스를 선언해서 implements해 보기*를 바랍니다."
+
+후속 (재사용 범위 명확화): "동일하다는 말이 잘못 전달될까봐 한 번 더 말씀드리면, *제가 동일한 함수와 동일한 객체를 사용해 달라는 말은, 재사용 가능한 함수와 객체의 영역을 넓혀 달라는 말*이었습니다. *재사용성이 핵심이지 동일해야 한다가 핵심은 아닙니다*. 의도를 다시 한 번 말씀드려봅니다."
+
+### 14. *get/toString 테스트* — 빡세게 vs 실용
+
+리뷰어: "*get이나 toString이 테스트할 로직이 없을만큼 간단하다면 괜찮*습니다. *연습해 보시라는 의미에서 빡세게 피드백 드렸지만 꼭 전부 지킬 필요는 없*습니다."
+
+### 15. `package lotto` 최상위 추가 이유
+
+리뷰어: "*리팩토링을 하시면서 최상위에 package lotto를 새로 만드신 이유가 있*나요?"
+
+## 리뷰어 의견 요지
+
+- **이중 검증 *환영*** — *부서 분리 시나리오*.
+- **`toString` *MVC 분리 문제* — model 변경 ≠ 기획 문구 변경**.
+- **`object` vs `class` *No Silver Bullet*** — view는 *프레임워크 의존*이라 *고민 가치 낮음*.
+- **테스트 패키지 = main 미러링**.
+- **테스트 클래스 = *1:1 매핑***.
+- **모델 *책임 = 테스트 가능성***.
+- **`Pair` → *data class***.
+- **매직 넘버 *전부 상수화***.
+- **`drawWinningLotto` *네이밍 오해***.
+- **`enum.ordinal` 의존 위험**.
+- **`repeat + index` → `forEach`**.
+- **수동/자동 발행 *재사용성 확장***.
+
+- **대표 인용:**
+  > 저는 *값의 검증에 관해서는 중복되어 보이더라도 무조건 여러 번 하는 것을 좋아*합니다.. *외부 조직 및 부서는 같은 팀이 아니기에 실체를 알 수 없는 블랙박스*라 생각합니다.
+  > — @ghojeong on `src/main/kotlin/util/InputValidator.kt`
+
+  > MVC의 핵심은 Model과 View가 얼마나 잘 분리되어 있는지이고, *이 분리는 model에서 제공하는 함수 및 값이 view의 요구사항 변경에 영향을 받으면 안 된다는 것을 뜻*합니다.
+  > — @ghojeong on `src/main/kotlin/model/WinningStatistic.kt`
+
+  > 모델의 역할과 책임이 잘 나누어져 있는가?를 판단할 때, 저는 *'각 모델 클래스 별로 유의미한 테스트를 편하게 작성할 수 있는가?'로 판단*합니다.
+  > — @ghojeong on `src/test/kotlin/model/LottoTest.kt`
+
+  > 재사용성이 핵심이지 *동일해야 한다가 핵심은 아닙니다*.
+  > — @ghojeong on `src/main/kotlin/model/LottoGenerator.kt`
+
+## 얻은 교훈
+
+- ***이중 검증 환영*** — *모듈 분리 시나리오*. *외부 부서 = 블랙박스*. *View 변경 잦음* → *Model 자체 invariant*가 *최후 안전망*.
+- **`toString` *MVC 분리 위반* 여부 = 조직 요구사항 + Model 영향도**.
+- **`object` vs `class` *No Silver Bullet*** — *view는 프레임워크 의존*이므로 *큰 차이 없음*. *시간은 Model에*.
+- **테스트 패키지 = *main 미러링*** — *import 없이 같은 패키지 내에서 접근*. *위치 발견* 비용.
+- **테스트 *클래스 1:1*** — `InputTest` X, `InputValidatorTest` O.
+- **모델 *책임 = 테스트 가능성*** — *테스트할 수 있는 게 책임*. *TDD*의 본질.
+- **`Pair` *호출자 컨벤션* → *data class*** — `pair.first`/`pair.second`는 *위치 의존*. *data class*는 *이름 의존*.
+- **매직 넘버 *모든 곳에서* 상수화** — `-1`, `0`도. *시그널이 있는 숫자*는 *상수*.
+- **`drawWinningLotto` 네이밍** — *draw = 그리다*로 오해. *getWinningLotto*나 *receiveWinningLotto*.
+- **`enum.ordinal` 의존 = *순서 깨짐 위험*** — *enum 추가/삭제* 시 *모든 ordinal 의존 코드 깨짐*. PR #131 (krrong) *else 회피*와 본질 같음.
+- **`repeat + index` 어색하면 `forEach`** — Kotlin idiom. *index가 진짜 필요한지* 의심.
+- **수동/자동 *재사용성 확장*** — *동일 인터페이스 활용 영역 넓히기*. *완전 동일 강제 X*.

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

@@ -0,0 +1,170 @@
+# PR #112 — [로또 1단계] 타마
+
+- **Reviewee:** [@etama123](https://github.com/etama123)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/112
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 31
+
+## 잘한 점 (설계 관점)
+
+- **`Lotto` invariant 강제** — `require`로 크기/범위/중복 검증.
+- **`LottoNumber` `data class`** — 학생 자가 학습 후 `equals`/`hashCode` 필요성 인지.
+- **README에 기능 목록 상세** — 작업 추적 가시화.
+- **`fun interface LottoNumberGenerator`** 도입 (이후 라운드) — 랜덤 외부 주입.
+- **`runCatching` 기반 `retryWhenException` 유틸** 도입.
+- **자가 의문 PR에 풍부히 명시** — *입력 검증의 위치*, *runCatching 적용*, *함수형 인터페이스 첫 도입* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. `Lotto(val lottoNums: List<Int>)` — `LottoNumber` 객체 부재
+
+```kotlin
+class Lotto(val lottoNums: List<Int>) {
+    init {
+        require(lottoNums.size == DEFAULT_LOTTO_SIZE)
+        require(lottoNums.all { it in MIN_RANGE..MAX_RANGE })
+        require(lottoNums.size == lottoNums.toSet().size)
+    }
+}
+```
+
+리뷰어: "lottoNums의 각 원소들이 1~45 사이에 들어간다는 걸 확신할 수 있을까요? 아마 Lotto의 초기화 부분을 보지 않는다면 해당 원소가 1..45에 해당함을 쉽게 알지 못할 겁니다." 학생: "Lotto 객체를 만들고 보니 내부에 들어가는 수도 LottoNumber 객체를 만드는 것이 낫겠다 !!" — 후속 라운드에서 `LottoNumber` 분리.
+
+### 2. `Lotto` 자료구조로 중복 표현
+
+리뷰어: "명시적으로 중복이 불가능함을 알려주기도 하면서, 자료구조를 사용하여 방지할 수 있습니다. 자동차를 예로 들어서, 2인승 자동차에 인원을 태우면서 더 이상 타지 못함을 알리는 것보다 2인승 자동차라는 것을 알려준다면 보다 효과적으로 외부에도 알리기도 쉽고 추가 검증도 필요 없겠죠?" — `Set<LottoNumber>`로 *중복 불가가 타입에 표현*.
+
+### 3. `Purchase` 명명 — 객체의 *역할*
+
+```kotlin
+class Purchase(val amountOfPurchase: String) {. }
+```
+
+리뷰어: "구매금액을 관리하는 객체로 PurchaseAmount..? 같은 명시적인 이름이 더 좋아 보이네요." 학생: "사용자의 입장에서 클래스 이름을 명시했던 것 같습니다. 앞으로는 **객체 그 자체의 역할**에 맞게 네이밍해 보겠습니다."
+
+### 4. `Purchase`가 `String`을 받음 — 도메인이 입력 형식 인식
+
+```kotlin
+class Purchase(val amountOfPurchase: String) {
+    init {
+        require(amountOfPurchase.all { it.isDigit() })
+.
+    }
+}
+```
+
+리뷰어: "예외 발생 시 에러 노출로 프로그램을 종료하는 것보다, 사용자로 하여금 재시도를 하게 유도하는 건 어떨까요? 코틀린에는 runCatching이라는 게 존재하는데요 참고해 보셔도 좋습니다." — *재시도 흐름*은 *예외 던지기*가 아니라 *null/Result*.
+
+### 5. `WinningLotto` 보너스 검증이 String 처리까지
+
+```kotlin
+class WinningLotto(val winningLotto: Lotto, val bounusNumber: String) {  // ⚠ typo: bounus
+    init {
+        require(bounusNumber.all { it.isDigit() })
+        require(bounusNumber.isNotBlank())
+        require(!winningLotto.lottoNums.contains(bounusNumber.toInt()))
+    }
+}
+```
+
+리뷰어: "보너스 번호도 어떻게 보면 하나의 로또번호입니다. 로또번호라는 일급 컬렉션이 존재한다면 중복되는 검증은 없어질 수 있겠네요!" — `LottoNumber` 분리 후 `bonusNumber: LottoNumber`.
+
+### 6. `LottoFactory` — 테스트 불가 (랜덤 내장)
+
+```kotlin
+class LottoFactory {
+    fun generateLottoNumbers(): List<Int> = (MIN..MAX).shuffled().take(LOTTO_SIZE).sorted()
+}
+```
+
+리뷰어: "현재 LottoFactory는 테스트가 가능한 구조일까요? 테스트가 불가하다면 어떤 이유이고, 어떻게 개선할 수 있을까요?" 후속: "현재 `generateLottoNumbers()` 함수는 shuffled() 함수에 의존적이어서, 우리는 결과를 예측할 수 없습니다. 만약 로또 번호를 생성하는 알고리즘을 외부로부터 주입받는다면 어떻게 변할까요? … Functional interface를 참고해 보시어 구현해 보셨으면 좋겠습니다." — 학생 후속 라운드에서 `fun interface LottoNumberGenerator` 도입.
+
+### 7. `InputView`/`Validator`/`Controller` — *변환과 검증 책임* 흩어짐
+
+```kotlin
+class InputValidator { fun validateNumber(value: String) {. } }
+// Controller
+val price = inputView.inputPurchasePrice()
+val amount = Purchase(price).calculateAmountOfLottos()
+```
+
+리뷰어: "객체는 입력값에 대해 스스로 검증하여 정상값을 반환하거나 그렇지 않으면 null을 반환한다(null을 반환한다는 건 어떤 의미일까?). 구입금액, 로또번호를 어디서 판단해야 할까? InputView는 split된 문자열만 파싱하여 도메인으로 던져도 되지 않을까?" — *`도메인에 맞는 타입`은 도메인의 책임*.
+
+### 8. `runCatching` 패턴 — *두 함수 반복*
+
+```kotlin
+fun inputPurchasePrice(): String? {
+    return runCatching {
+        val input = readln().also { InputValidator.ValidateNumber(it) }
+        input
+    }.getOrNull()
+}
+
+fun retryInputPurchasePrice(): String {
+    var input: String? = null
+    while (input == null) { input = inputPurchasePrice() }
+    return input
+}
+```
+
+학생: "runCatching을 활용해 잘못된 값 입력 시 재입력을 받을 수 있도록 코드를 작성. 하지만 하나의 입력값을 검증할 때마다 두 개의 함수 형식이 반복되는 것이 어색." → 학생이 *유틸리티 함수*로 추상화. 리뷰어: "프로그램 내에서 반드시 필요한 값이라면 `fun inputWinningNumbers(): Set<Lotto> { val input = inputView.inputWinningNumber() ?: inputWinningNumbers() }`."
+
+### 9. 학생 리뷰 반영 누락 다수
+
+리뷰어: "어려우셨던 걸까요? 반영이 안 된 부분이 많은데 어려우셨다면 공유 부탁드려요! 어느 부분을 어려워하시는지 알아야 타마가 완주하기까지 도움을 드릴 수 있습니다." 학생: "수정 커밋 후 push를 잊었습니다." — *반영 사실 확인*은 push 후 리뷰어 재확인까지.
+
+### 10. `data class` vs `class` 학생 자가 학습
+
+리뷰어 질문: "`User`/`User2` 동등성 비교 결과는?" 학생 답: "`==`는 내부적으로 `equals()`를 호출. data class는 `equals()`를 자동 생성하며 모든 프로퍼티 값이 같으면 true. 일반 클래스는 참조 비교(=== 동일). `===`는 동일 객체(참조 비교)." — *data class의 의미*를 학생이 정확히 정리.
+
+### 11. `getWinningNumber` Controller에서 String 변환
+
+```kotlin
+private fun getWinningNumber(): Lotto {
+    val winningLotto: String = inputView.inputWinningNumber()
+    return Lotto(winningLotto.split(",").map {. LottoNumber(it.toInt()) })
+}
+```
+
+리뷰어: "inputView로부터 넘어오는 타입이 `List<Int>`로 받으면 어떨까요? `val winningLotto = WinningLotto(inputView.inputWinningNumber())` WinningLotto 스스로 Int 리스트를 받아 당첨번호를 만들 수 있지 않을까요?" — Controller에서 변환 대신 *도메인에서 자기 형식*.
+
+## 리뷰어 의견 요지
+
+1. **`LottoNumber` 분리 = 범위 검증을 타입에 위임** — Lotto는 *크기*만 검증.
+2. **자료구조 = invariant 표현** — Set이 *중복 불가*를 *타입에 새겨줌*.
+3. **객체명 = *객체 자체의 역할*** — *사용자 관점 명사*는 도메인 어휘 부재 신호.
+4. **`Purchase`가 String을 받으면 도메인이 *입력 형식*을 알게 됨** — 변환은 어딘가 *외부*.
+5. **랜덤 의존은 *함수형 인터페이스*로 상위 주입** — TDD 정합성.
+6. **`runCatching`은 *재시도+null* 양쪽 가능** — 두 함수 반복 시 *유틸리티*로 추상.
+7. **null의 의미** — "이 값을 만들 수 없다." 호출자가 *다음 행동*을 결정.
+8. **리뷰 반영 = 명시적 확인** — push 누락도 흔한 실수.
+9. **Tell, Don't Ask** — `WinningLotto(inputView.inputWinningNumber())` 한 줄로.
+10. **2인승 자동차 비유** — *자료구조 선택*이 *제약을 외부에 친절하게 알림*.
+
+- **대표 인용:**
+  > 2인승 자동차에 인원을 태우면서 더 이상 타지 못함을 알리는 것보다 2인승 자동차라는 것을 알려준다면 보다 효과적으로 외부에도 알리기도 쉽고 추가 검증도 필요 없겠죠?
+  > — @KwonDae on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+  > 현재 `generateLottoNumbers()` 함수는 shuffled() 함수에 의존적이어서, 우리는 결과를 예측할 수 없습니다.
+  > — @KwonDae on `src/main/kotlin/lotto/domain/LottoFactory.kt`
+
+  > `도메인에 맞는 타입`이라는 건 누구의 책임인지 생각해 볼 만한데요 1. 객체는 입력값에 대해 스스로 검증하여 정상값을 반환하거나 그렇지 않으면 null을 반환한다 2. 구입금액, 로또번호를 어디서 판단해야 할까? InputView는 split된 문자열만 파싱하여 도메인으로 던져도 되지 않을까?
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > inputView로부터 넘어오는 타입이 `List<Int>`로 받으면 어떨까요? WinningLotto 스스로 Int 리스트를 받아 당첨번호를 만들 수 있지 않을까요?
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+## 얻은 교훈
+
+- **`LottoNumber` 분리**는 *범위*를 타입에 위임 — Lotto는 *크기* 검증만, *각 번호의 유효성*은 LottoNumber.
+- **자료구조 선택 = invariant의 *외부 알림*** — `Set<LottoNumber>`이면 호출자가 *중복 불가*를 즉시 인지.
+- **객체명은 *역할*** — `Purchase`(행위)보다 `PurchaseAmount`(값) — *명사형*이 객체의 정체성에 더 가까움.
+- **도메인이 *입력 형식*을 알면 결합** — `Purchase(amount: String)`이면 *입력 형식 변경*이 도메인 변경.
+- **`runCatching`의 *두 표정***  — `.getOrNull()`로 null화, `.getOrElse { retry() }`로 재시도. *어느 표정*이 적절한지 호출 위치에서 결정.
+- **null의 의미는 *값 부재*** — *재시도/기본값/실패*는 호출자가 결정.
+- **`fun interface`** = SAM 람다 주입의 표준 — *생성 알고리즘*을 외부에서.
+- **2인승 자동차 비유** — *제약을 사후 검증*이 아니라 *타입으로 외부에 친절히* 알림.
+- **`data class` = `equals`/`hashCode`/`toString` 자동** — *참조 비교*가 아니라 *값 비교* 의도면 data class. 단, *Flyweight*와 결합하면 정합성 점검 필요.
+- **TDD 정합성 = 핵심 로직이 테스트 가능** — 랜덤이 *핵심*인 객체가 *테스트 불가*면 그건 TDD가 *아닌* 것.
+- **리뷰 반영 = *push 후 재확인*** — 커밋만 하고 push 안 하면 리뷰어가 *반영되지 않음*으로 봄.

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

@@ -0,0 +1,183 @@
+# PR #148 — [타마] 2단계 로또
+
+- **Reviewee:** [@etama123](https://github.com/etama123)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/148
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 17
+
+## 잘한 점 (설계 관점)
+
+- **`LottoCalculator` 별도 객체** — *구매 금액 ↔ 로또 수 계산* 책임 분리.
+- **`LottoNumberGenerator` 인터페이스 + `AutoLottoNumberGenerator`/`ManualLottoNumberGenerator`** — Strategy. 리뷰어 칭찬: "👍".
+- **후속 라운드 적극 반영** — *sealed class*로 Profit 메시지 분리, *거스름돈 반환* 기능 추가, *논리 오류 vs null* 정리.
+- **PR 본문에 *변경 커밋 링크* 첨부** — 리뷰어가 *후속 변경*을 즉시 확인 가능.
+
+## 못한 점 (설계 관점)
+
+### 1. *1000원 단위 미만* — *오류* vs *거스름돈* 선택
+
+```kotlin
+class LottoCalculator(
+    val amountOfPurchase: Int,
+    private val lottoPrice: Int = LOTTO_PRICE,
+) {
+    private fun validatePurchaseAmount() {
+        require(amountOfPurchase % lottoPrice == 0) { "로또는 ${lottoPrice}원 단위로 구입해 주세요" }
+    }
+}
+```
+
+리뷰어: "*1000원 단위가 아니라면 오류를 발생시키는 건 미션의 요구사항 이었을까요*? 혹은 단위로 입력하지 않고 *나머지가 발생했을 때 오류 대신 거스름을 반환하거나 추가 금액을 요구*할 수 있지 않을까요? *실제 현실세계에 대입*해 보면 쉽게 답이 나올 거에요." 학생: "*Price 도메인 내부에서 금액 입력 시에, 거스름돈을 반환한다는 메시지를 추가*했습니다! 나중에 *추가 금액을 요구하는 기능*도 추가할 수 있을 것 같습니다." — *현실 메타포*로 도메인 행동 재해석.
+
+### 2. *Domain에 View 로직* — `println("거스름돈")`
+
+```kotlin
+class Price(val price: Int) {
+    init {
+        validatePurchaseAmount()
+    }
+
+    private fun validatePurchaseAmount() {
+        if (price % LOTTO_PRICE != 0) {
+            val change = price % LOTTO_PRICE
+            println("구입 금액이 1000원 단위가 아닙니다. 거스름돈 ${change}원을 반환합니다.")  // ⚠ View
+        }
+    }
+}
+```
+
+리뷰어: "도메인에 *view 로직이 들어가* 있네요..! 이런 부분은 *sealed class를 활용*하면 좋을까요?" — *도메인은 상태만, 표현은 View*. 학생: "도메인에 message가 있다는 것은 *view의 책임을 domain이 대신*하게 되어, 수익 계산하는 역할을 넘어 *UI의 역할까지* 하게 됩니다. 그래서 *value만 가지는 것이 아니라 메시지 속성을 별도의 데이터로 추가할 수 있는 sealed class*로 분리해 보았습니다!"
+
+### 3. `Profit` enum이 *message* 보유
+
+```kotlin
+enum class Profit(val message: String) {  // ⚠ View 문구
+.
+}
+```
+
+리뷰어: "현재 *domain에 있는 Profit enum class에 view에서 사용되는 프로퍼티*가 있습니다. *도메인 모델에 message가 존재하는 거에 대해 어떻게 생각*하시나요? 만약 *출력 메시지가 변경되어야 한다면 도메인이 변경*되어야 할 거에요." + 후속 위치: "toString 부분은 *View의 로직*이 아닐까요? 도메인에서는 *sealed class로만 상태를 정의*하고, 해당 상태에 대한 *출력 문구는 View에서 정의*해 줘도 괜찮을 것 같습니다." 학생 후속:
+
+```kotlin
+sealed class ProfitMessage {
+    object LossMessage : ProfitMessage() {
+        override fun toString(): String = "기준이 1이기 때문에 결과적으로 손해라는 의미임"
+    }
+.
+}
+```
+— 여전히 *도메인 폴더에 메시지*가 남음. *Profit 상태 → View 매핑*은 *View 측*에 둬야 완전 분리.
+
+### 4. `getManualLottoNumbers(): List<List<Int>>` — *원시 컬렉션 중첩*
+
+```kotlin
+private fun getManualLottoNumbers(amount: Int): List<List<Int>> {
+    val manualLottoNumbers = mutableListOf<List<Int>>()
+    outputView.printManualLottoMessage()
+
+    repeat(amount) {
+        val numbers = inputView.inputManualLottoNumber()
+        manualLottoNumbers.add(numbers)
+    }
+    return manualLottoNumbers
+}
+```
+
+리뷰어: "*List<List<Int>> 조금 어색해 보이지 않나요*? 함수 이름이 ManualLottoNumber라면 *반환값도 List<Lotto>이어야 자연스러울 것* 같아요." 학생: "Controller 내부에서 *List<Int>를 받을 때마다, 수동 로또를 발행*하는 방식으로 변경해 보았습니다. 이렇게 변경함에 따라 *입력한 수동 로또 번호 하나마다, 유효성을 검증*할 수 있게 되었습니다." — *지연된 도메인 변환*은 검증 시점도 지연.
+
+### 5. `LottoSeller`가 `LottoFactory` 의존 — *검증 미완 입력*
+
+```kotlin
+class LottoSeller(
+    val price: Int,
+    val manualLottoAmount: Int,
+    val manualLottos: List<List<Int>>,  // ⚠ 검증 미완
+) {. }
+```
+
+리뷰어: "*들어오는 값이 검증이 되어 있지 않으니 LottoSeller가 LottoFactory까지 의존*하게 되고 있네요. *프로퍼티 자체를 List<Lotto>로 받아* 보는 건 어떨까요?" — *불변/검증된 도메인 타입*을 인자로 받아야 *재검증/팩토리 호출*이 불필요.
+
+### 6. *논리 오류 vs null* — `toInt` vs `toIntOrNull`
+
+```kotlin
+fun inputPurchasePrice(): Int {
+    println("구입금액을 입력해 주세요.")
+    val input = readln().also { InputValidator.ValidateNumber(it) }  // 검증 후 toInt
+    return input.toInt()
+}
+```
+
+리뷰어: "> *논리적인 오류가 아니면 예외를 던지지 말고 null을 반환*한다. *InputValidator에서 검증하는 항목은 논리 오류에 해당*할까요? 기존 kotlin에서 *toInt와 toIntOrNull 둘 다 개발한 건 어떤 의도*였을까요?" 학생 정리:
+```
+**구입 금액에 문자가 입력된 경우** 
+1. InputValidator로 숫자인지 확인 
+2. 문자로 오입력 확인 -> null을 반환 
+3. 구입 금액 도메인에서 논리 오류 검사 (require() 사용)
+4. 사용자에게 재 입력 요구
+```
+"이렇게 로직을 짜면, *View에서 입출력 오류를 막을 수 있을 뿐만 아니라, 논리 오류에도 대처가 가능*하다고 생각합니다!" + 후속: "1. 입력 오류인 경우, *InputValidator에서 null을 반환해 재입력*. 2. 논리 오류인 경우, *controller에서 runCatching을 활용*해, *domain에서 던져진 예외*가 있는 경우 *재입력*."
+
+### 7. `runCatching` 권장
+
+리뷰어 (calculator 위에): "아래 코멘트와 마찬가지입니다. 코틀린에는 *runCatching*이라는 게 존재하는데요 참고해 보셔도 좋습니다."
+
+### 8. InputView가 *Lotto 객체*까지 만들 수도
+
+```kotlin
+private fun getWinningNumbers(): Lotto {
+    while (true) {
+        val input = inputView.inputWinningNumber()
+        runCatching {
+            return Lotto(input.map { number -> LottoNumber(number) })
+        }.onFailure { e ->
+            outputView.printErrorMessage(e.message)
+        }
+    }
+}
+```
+
+리뷰어: "**_Lotto 객체 생성 시 스스로 검증에 대한 로직이 잘 정리되어 있다면_** *InputView로부터 정상 입력 시 Lotto 객체를 전달받는다면* 어떨까요? 현재 *OutputView에서는 Model을 빌려 출력*을 하는데, *InputView에서도 입력받은 값을 통해 객체를 만들어 컨트롤러로 던져* 줄 수 있을 거에요."
+```kotlin
+//inputView
+fun inputWinningNumber(): Lotto {
+    val winningLotto = readln(). ?: inputWinningNumber()
+    return winningLotto
+}
+```
+— *대칭 원칙*: View는 *입/출력 모두 도메인 객체와의 변환*.
+
+## 리뷰어 의견 요지
+
+- **요구사항 외 *현실 메타포*** — 1000원 미만은 *오류*가 아닌 *거스름돈*도 가능.
+- **도메인 ≠ View** — `println`, `message`, `toString` 모두 View로.
+- **`sealed class`로 *상태와 메시지 분리***.
+- **원시 컬렉션 중첩 (`List<List<Int>>`) → 도메인 타입**.
+- **검증 미완 인자 = *팩토리 의존* 신호**.
+- **`InputValidator` = *입력 형식*, *도메인 = 논리 오류***.
+- **`InputView`도 *도메인 객체* 반환 가능** — 대칭.
+
+- **대표 인용:**
+  > 1000원 단위가 아니라면 오류를 발생시키는 건 미션의 요구사항 이었을까요? *실제 현실세계에 대입*해 보면 쉽게 답이 나올 거에요.
+  > — @KwonDae on `src/main/kotlin/lotto/domain/LottoCalculator.kt`
+
+  > 만약 *출력 메시지가 변경되어야 한다면 도메인이 변경*되어야 할 거에요.
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > List<List<Int>> 조금 어색해 보이지 않나요? *반환값도 List<Lotto>이어야 자연스러울 것* 같아요.
+  > — @KwonDae on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 들어오는 값이 검증이 되어 있지 않으니 *LottoSeller가 LottoFactory까지 의존*하게 되고 있네요. *프로퍼티 자체를 List<Lotto>로 받아* 보는 건 어떨까요?
+  > — @KwonDae on `src/main/kotlin/lotto/domain/LottoSeller.kt`
+
+## 얻은 교훈
+
+- **요구사항 외 *현실 메타포*** — *1000원 미만*은 *오류*가 아닌 *거스름돈*. *물리적 키오스크*가 가르치는 도메인 행동.
+- **도메인 ≠ View** — `println`, `message: String`, `toString`는 모두 *View 책임*. 도메인 변경 = View 변경이 되어선 안 됨.
+- **`sealed class`로 *상태와 메시지 분리*** — 도메인은 *상태 ID*만, *문구*는 View에서 매핑.
+- **원시 컬렉션 중첩은 *지연된 도메인***. `List<List<Int>>` → `List<Lotto>`로 *생성 시점*을 앞당기면 *검증도 앞당김*.
+- **검증 미완 인자 = *팩토리 의존* 신호** — `LottoSeller(manualLottos: List<List<Int>>)`처럼 *원시값 입력*은 *내부에서 도메인 변환*을 강요.
+- **입력 형식 오류 = null + 재입력, 논리 오류 = require + runCatching 재입력** — *두 경로*를 명시적으로 분리한 학생의 4단계 정리는 *경계 패턴*의 모범.
+- **`runCatching`은 입력 경계의 일관 패턴** — `try-catch`보다 *Result*가 *재시도 위치*를 명확.
+- **`InputView`도 *도메인 객체 반환* 가능** — *OutputView가 도메인 사용*과 *대칭*. `fun inputWinningNumber(): Lotto`처럼.
+- **변경 커밋 링크를 PR 댓글에 첨부** — 후속 라운드 응답을 *URL로*. 리뷰 효율 + 변경 추적.