oh-my-oop 0.2.0

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

@@ -0,0 +1,129 @@
+# PR #38 — [코비] 2단계 로또
+
+- **Reviewee:** [@rhkrwngud445](https://github.com/rhkrwngud445)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/38
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 20
+
+## 잘한 점 (설계 관점)
+
+- **`purchaseManualLottos`/`purchaseAutoLottos` 분리**.
+- **`toIntOrNull() ?: return retry()` 재시도 흐름**.
+- **`PurchasedLotto` 도메인 객체** — Lotto와 *발행된 Lotto* 구분.
+
+## 못한 점 (설계 관점)
+
+### 1. `mutableListOf().apply` — `as`로 가변 변환 위험
+
+```kotlin
+fun purchaseAutoLottos(money: Money): List<PurchasedLotto> = mutableListOf<PurchasedLotto>().apply {
+.
+}
+```
+
+리뷰어: "mutableList를 함수의 리턴 타입을 활용하여, List 타입으로 전달하도록 구현해 주셨네요. 하지만, `as`를 통해 *Mutable로 변환이 가능*하며, 이로 인하여 원본을 훼손시킬 수 있습니다. *방어적 복사*를 활용하여, 원본을 훼손하지 않도록 코드를 개선해 보면 어떨까요?" 후속: "컬렉션과 관련된 함수들은(filter, map 등) 연산을 한 후에 *원본이 아닌 복사본*을 리턴." — `toList()` 또는 `.map`.
+
+### 2. 함수명 *너무 김*
+
+```kotlin
+fun getRemainingMoneyAfterManualLottoPurchase(manualLottoCount: Int): Money {. }
+```
+
+리뷰어: "함수명이 너무 길어서 잘 읽히지가 않네요. 함수명의 단어의 수를 조금 줄여 보면 어떨까요?"
+
+### 3. `validateNumeric` — 커스텀 < 시스템 함수
+
+```kotlin
+fun validateNumeric(value: String): Int = value.toInt()
+```
+
+리뷰어: "String 타입을 Int로 변환하는 로직을 구현해 주셨네요. 다만, *대체로 커스텀한 함수보다는 시스템 함수가 더 가독성*이 좋습니다." — `toIntOrNull()` 직접 호출.
+
+### 4. `runCatching + lateinit + result =` 패턴
+
+```kotlin
+fun inputPurchasingMoney(): Money {
+    lateinit var result: Money
+    runCatching {. }.onSuccess { result = Money(it) }.onFailure { return inputPurchasingMoney() }
+    return result
+}
+```
+
+리뷰어: "코틀린에서 예외를 처리하는 방법은 크게 두 종류가 있습니다. *오류가 예상되는 경우*, *오류가 예상되지 않는 경우*. 위 경우는 어떤 경우일까요? 일반적인 코틀린 코드에서 *try-catch를 사용하지 않는다*." → `toIntOrNull() ?: return retry()`.
+
+### 5. `nullable List` vs *빈 컬렉션*
+
+```kotlin
+private fun inputLottoNumbers(): List<Int>? {. }
+```
+
+리뷰어: "List와 같은 컬렉션은 내부적으로 데이터를 추가하거나 삭제할 수 있습니다. 또한 *데이터가 없다면, null이 아닌 빈 컬렉션*을 활용할 수 있습니다." 학생 의문: "리스트가 비어 있는지 체크하는 것보다 받아온 list가 null인지 체크하는 것이 효율적이라고 생각이 되어서." 리뷰어: "null이라는 의미는 *객체를 신뢰할 수 없다*. 그렇기 때문에 null을 참조하게 되면 exception이 발생. 하지만 *빈 컬렉션은 nullable하지 않기 때문에 신뢰할 수 있으며*…"
+
+### 6. `inputManualLottos`가 *입력 + 변환 + 검증*
+
+```kotlin
+fun inputManualLottos(manualLottoCount: Int): List<Lotto> {
+    repeat(manualLottoCount) {
+        val manualLotto = inputLottoNumbers() ?: return inputManualLottos(manualLottoCount)
+        manualLottos.add(Lotto(manualLotto.map { LottoNumber(it) }))
+    }
+    return manualLottos
+}
+```
+
+리뷰어: "이 함수는 *두 가지 일*을 하고 있어요. (입력값 받기, 수동 로또 생성하기) *하나의 함수는 한 가지 일만* 하도록." 학생: "모델에 사용되는 객체를 inputview에서 받는 것보다 *controller에서 매핑*하는 게 적절하다고 판단되어 수정." → 학생이 List<List<Int>> 반환으로 변경.
+
+### 7. 재귀 호출 = *영문 모를 무한 루프*
+
+리뷰어: "함수의 재귀 호출은 신중하게 하는 것을 권장합니다. 이와 같이 *재귀 호출*을 하게 되면, 사용자의 입장에서는 *영문도 모른 채 프로그램이 종료되지 않는 부정적인 경험*을 하게 됩니다. 사용자가 유효한 값을 입력할 때까지 반복을 하고 싶으시다면, *사용자에게 어떤 것이 잘못 되었는지 알려*주어야 합니다." + "참고로, *프로그래밍 요구사항에는 입력값이 유효할 때까지 계속해서 입력을 받는다*와 같은 요구사항은 없습니다."
+
+### 8. 테스트명에 *내부 정보* 노출
+
+```kotlin
+fun `manualLottoList와 금액이 주어졌을 때, purchasedLottos() 호출시, 구매금액 만큼의 PurchasedLotto를 반환한다`() {. }
+```
+
+리뷰어: "테스트 코드에는 가급적이면 *내부 정보를 드러내지 않고*, *어떤 것을 테스트하고자 하는지*를 나타내는 것이 좋습니다. 만약 몇 개월이 지난 후 purchasedLottos 함수명을 변경하게 된다면, 이 함수명도 변경할 수 있을까요?"
+
+### 9. Kotlin 중괄호 컨벤션
+
+```kotlin
+if (checkRankIsThird(.)) return THIRD  // ⚠ 컨벤션
+```
+
+리뷰어: "코틀린에서는 중괄호를 넣어 주는 것이 컨벤션입니다."
+
+## 리뷰어 의견 요지
+
+- **방어적 복사** — `toList()`/`.map` 등 *복사본 반환*.
+- **함수명 *짧고 의도 명확***.
+- **커스텀 함수 < 시스템 함수**.
+- **`try-catch`/`runCatching` 회피** — Kotlin idiomatic 코드는 *조건 분기*로.
+- **null vs 빈 컬렉션** — 컬렉션은 *빈 컬렉션*이 신뢰 가능.
+- **함수 한 가지 일** — 입력 + 변환 + 검증 분리.
+- **재귀 호출 = *무한 루프 위험*** — 사용자 안내 + 종료 조건.
+- **테스트명 = 의도, 구현 메서드명 X**.
+- **Kotlin 컨벤션 = 중괄호**.
+
+- **대표 인용:**
+  > `as`를 통해 Mutable로 변환이 가능하며, 이로 인하여 원본을 훼손시킬 수 있습니다. *방어적 복사*를 활용하여, 원본을 훼손하지 않도록.
+  > — @BeokBeok on `src/main/kotlin/domain/game/LottoMachine.kt`
+
+  > null이라는 의미는 객체를 신뢰할 수 없다라는 의미입니다. 그렇기 때문에 null을 참조하게 되면 exception이 발생. 하지만, *빈 컬렉션은 nullable하지 않기 때문에 신뢰할 수 있으며*…
+  > — @BeokBeok on `src/main/kotlin/view/InputView.kt`
+
+  > 함수의 재귀 호출은 신중하게 하는 것을 권장합니다. … 영문도 모른 채 프로그램이 종료되지 않는 부정적인 경험. 참고로, *프로그래밍 요구사항에는 입력값이 유효할 때까지 계속해서 입력을 받는다와 같은 요구사항은 없습니다*.
+  > — @BeokBeok on `src/main/kotlin/view/InputView.kt`
+
+## 얻은 교훈
+
+- **방어적 복사** = 외부 mutable 변환 차단. `toList()`/`.map`이 *복사본 반환*.
+- **null vs 빈 컬렉션** — *컬렉션은 빈 컬렉션*이 표준 — null 참조 위험 회피.
+- **함수 한 가지 일** — InputView는 *입력만*, 변환은 *Controller/Mapper*.
+- **재귀 호출 = *무한 루프 가능성*** — 사용자 안내 + 종료 조건. *요구사항에 없으면 도입 신중*.
+- **테스트명 = 의도** — 함수명/객체명 노출은 *리네임 시 테스트 깨짐*.
+- **Kotlin 컨벤션 = 중괄호** — 단일 라인이라도 `if` 본문에 중괄호.
+- **시스템 함수 > 커스텀** — 추가 정보가 없는 wrapping은 제거.
+- **`try-catch`보다 *조건 분기*** — `toIntOrNull() ?:.`.
+- ***요구사항에 없으면 도입 신중*** — *안정성*과 *요구사항 충실*은 별개.

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

@@ -0,0 +1,146 @@
+# PR #21 — [멘델] 1단계 로또
+
+- **Reviewee:** [@rhthrhrl0](https://github.com/rhthrhrl0)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/21
+- **단계:** 1단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 15
+
+## 잘한 점 (설계 관점)
+
+- **`LottoController(inputView: InputViewInterface, resultView: ResultViewInterface)` 인터페이스 주입** — 리뷰어 칭찬: "*생성자로 interface를 주입해서 LottoController도 테스트 가능*하군요 :+1:".
+- **`Set<Int>` 사용** — 리뷰어 칭찬: "Set 활용 :+1:".
+- **`PurchaseLottoMoney`, `LottoNumber` 원시값 포장** — 리뷰어 칭찬: "금액을 나타내는 *래퍼 클래스* :+1:".
+- **`LottoNumber` Flyweight** — `lottoNumbers: Map<Int, LottoNumber>`.
+
+## 못한 점 (설계 관점)
+
+### 1. *View 검증* vs *도메인 require* — 학생 자가 의문
+
+학생: "저번 과제에서는 *일급 컬렉션을 이용하는 조건이 없어서 모든 데이터에 대한 검증을 인풋뷰 영역에서 수행*했습니다. 이렇게 *최소한의 타입 변환에 대한 유효성 검증은 뷰 영역에서 수행하고, 그 받은 데이터들을 활용해서 데이터 유효성(데이터의 range 등)에 대한 검증은 그 클래스에서 담당*해야 한다면, 보시는 것처럼 *컨트롤러에서 재입력 받기 위해서 코드를 구성하면 가독성도 떨어지고 너무 많은 보일러플레이트 코드가 발생*한다고 생각합니다(반복문을 돌면서 runCatching을 사용하는 메소드가 너무 많이 생기는 것 같습니다). 아니면 *컨트롤러 쪽 말고 인풋뷰 쪽에서 일급 컬렉션을 지닌 객체를 생성까지 하고 반환하는 것*이 나을까요?"
+
+리뷰어: "*View에서 처리하는 경우와 객체 안에서 require 처리하는 경우는 다릅니다*. 보통 요구사항으로 *입력이 잘못된 경우에 다시 유저에게 입력을 받아야 하므로 View에서 다시 입력받도록* 만들어야 합니다. 그런데 여기를 지나쳐서 *만약 로또 번호가 45보다 큰 48이 만들어지는 경우 논리 오류가 발생*하게 됩니다. *논리 오류는 컴파일 오류도 없고 런타임에 예외도 발생하지 않아서 디버깅하기가 어려우므로 빠르게 실패하도록 만들어 줘야 합니다*. 저는 오히려 지금과 같이 *InputView에서 바로 재입력을 받는 게 더 안전*하다고 생각해요." + "객체에서 *require()를 호출하는 건 논리 오류를 만들지 않기 위한 목적*이 큽니다. InputView에서 한 번 검증이 끝났다면 그대로 사용해 주시면 되고 그래도 거슬린다면 *바로 LottoNumber를 만들어 주셔도 상관없*습니다. *의존성 측면에서 보았을 때, presentation layer가 domain layer에 의존하는 것은 문제 없*습니다."
+
+→ View 검증 = *재입력 가능*, Domain `require` = *논리 오류 방지 안전망*. *두 위치 모두 정당*.
+
+### 2. *일급 컬렉션 활용* 학생 자가 의문
+
+학생: "*일급 컬렉션에서 다른 곳에서 자신이 가진 컬렉션을 활용하는 공통적인 비즈니스 로직을 담은 메소드를 만들어서 최대한 해당 컬렉션들을 활용하는 중복 코드를 다른 영역에서 줄이고 통일성 있는 메소드를 제공하는 것이 목적* 같은데, 이번 과제에서는 마땅히 *그런 메소드(일급 컬렉션을 활용해서 특별한 연산을 수행해서 결과를 반환하는 메소드)가 생각이 나지 않아서 일급 컬렉션을 어떻게 잘 활용할 수 있을지 고민*입니다." + "*LottoStatistics 클래스의 역할을 Lotto에게 위임해도 되는 걸까요*?"
+
+리뷰어: "*중복 코드를 줄이는 것보다도 더 중요한 목적이 바로 객체 지향적인 코드*가 되기 때문입니다. *List<Int>를 로또로 처리하는 것보다는 Lotto를 로또로 처리하는 게 훨씬 더 좋은 가독성*을 가지게 됩니다." + "큰 문제는 없어 보입니다. 저는 오히려 *수익률을 계산하는 책임을 WinningLotto로부터 분리하여 하나의 책임만 맡도록 처리되어 더 좋은 코드*라고 생각해요." — *일급 컬렉션의 목적*은 *중복 제거*가 아니라 *도메인 어휘*.
+
+### 3. TDD에서 *private이 안 됨* — 학생 자가 의문
+
+학생: "TDD를 하다 보니 *작은 메소드들이 private으로 감싸지지 않습니다*. 그 *작은 메소드들까지 모두 미리 생각해서 테스트 코드를 설계하고 큰 역할의 메소드들만 테스트하도록 테스트 코드를 잘 설계하고 클래스 작성에 들어가야 하는 것이 맞는 건가요*? TDD를 하다 보니 살짝 *분할 정복의 느낌*이 강했습니다."
+
+리뷰어: "*테스트를 위해 private 함수를 public으로 만들어 주는 것은 지양*해 주세요. *가능한 한 공개되어 있는 함수를 통해 간접적으로 테스트*해 주셔야 합니다. 그 이유는 *private 함수의 경우에는 해당 클래스의 내부 구현체라고 볼 수 있고 public 함수는 해당 클래스의 API*라고도 볼 수 있는데, *private 함수를 테스트한다는 것은 내부 구현을 건드린다는 것과 마찬가지*입니다. 따라서 *현재는 문제가 없을 수 있더라도 추후에 요구사항이 변경되면 테스트 케이스가 깨지게 되는 가장 큰 원인*이 됩니다." 
+
+### 4. *MethodSource로 테스트 의도 분산*
+
+```kotlin
+@ParameterizedTest(name = "{1}개가 일치하는 경우")
+@MethodSource("provideLottoAndMatchCount")
+```
+
+리뷰어: "*좋은 테스트 코드는 테스트 본문만 보아도 테스트하는 의도를 모두 알 수 있어야* 합니다. *MethodSource는 테스트 본문에서 분리되므로 두 곳을 모두 확인*해야 합니다. *테스트 본문만 보아도 어떻게 했을 때, 어떻게 되어야 하는지를 명확하게 알 수 있도록* 만들어 보세요." — *지역성*이 *테스트 가독성*의 핵심.
+
+### 5. 상수 `MINIMUM_LOTTO_RANGE` *common 패키지*
+
+```kotlin
+// common/const.kt
+const val MINIMUM_LOTTO_RANGE = 1
+const val MAXIMUM_LOTTO_RANGE = 45
+```
+
+리뷰어: "*Lotto의 범위이므로 Lotto에 위치*시키는 게 어떨까요?" — *상수 위치 = 도메인 책임*. *common god-folder* 회피.
+
+### 6. *상수 위치 후 다시 하드코딩* — 메시지 본문에
+
+```kotlin
+private const val ERROR_LOTTO_RANGE = "로또 번호는 1이상 45이하여야 합니다."  // ⚠ 다시 1, 45
+```
+
+리뷰어: "*1, 45가 변경되는 경우 이 부분의 하드코딩된 부분도 변경*해야 합니다. *기존 상수가 있다면 해당 상수를 참조하는 방식*으로 만들어 주세요.".
+
+### 7. `LottoNumber.from` *Range 재검사* 후 Flyweight 조회
+
+```kotlin
+fun from(number: Int): LottoNumber {
+    require(number in MINIMUM_LOTTO_RANGE..MAXIMUM_LOTTO_RANGE) { ERROR_LOTTO_RANGE }
+    return lottoNumbers[number]!!  // ⚠ Range 재검사 후 !!
+}
+```
+
+리뷰어: "*유효성 검사할 때, Range를 한 번 더 만들 필요 없이 null인지를 체크*하시면 됩니다. *만약 lottoNumber를 만드는 로직이 변경되었는데 유효성 검사하는 로직은 변경하지 않으면 그대로 오류가 발생*하기 때문이에요."
+```kotlin
+return requireNotNull(lottoNumbers[number]) { ERROR_LOTTO_RANGE }
+```
+→ *검증 일원화*: *맵에 없으면 잘못된 값*. 두 곳에 두면 *동기화 오류* 위험.
+
+### 8. 에러 메시지에 *변수 값 포함 안 함*
+
+```kotlin
+private const val ERROR_LOTTO_RANGE = "로또의 숫자는 ${MINIMUM_LOTTO_RANGE}에서 ${MAXIMUM_LOTTO_RANGE}사이의 숫자여야 합니다."
+// ⚠ 실제 입력값 number는 메시지에 없음
+```
+
+리뷰어: "*number를 에러 메시지에 포함*시켜 주세요. 로그를 보았을 때 *stacktrace가 남아있으니 어느 코드에서 발생했는지는 알 수 있*습니다. *하지만 변수는 메시지에 담지 않는 한 데이터가 사라지게* 됩니다. *실제로 배포가 되는 경우에는 로그만 따로 수집해 주는 툴을 사용하시게 될* 겁니다. 그런 경우에 *로그를 보았는데 메시지에 필요한 정보가 담겨 있지 않으면 디버깅이 너무 힘들어*집니다." — *Production 로그 수집* 시나리오.
+
+### 9. 테스트 전용 함수 *main에*
+
+```kotlin
+// common/open_func.kt
+fun Set<Int>.convertToLottoNumberSet(): Set<LottoNumber> = this.map { LottoNumber.from(it) }.toSet()
+```
+
+리뷰어: "*이 함수는 테스트 코드에서만 쓰이므로 test SourceSet으로 옮겨* 주세요." — *프로덕션 코드 오염* 방지.
+
+### 10. `companion object`의 `const val` *불필요한 public*
+
+```kotlin
+companion object {
+    const val ONE_LOTTO_MONEY = 1000  // ⚠ 외부 미사용
+    const val ERROR_LOTTO_PURCHASE_MONEY = "."  // ⚠ 외부 미사용
+}
+```
+
+리뷰어: "이 상수는 *이 클래스 외에서는 쓰이지 않*습니다. *기본적으로 private으로 선언하고 꼭 필요한 경우에만 풀어주도록 습관*을 가져 보세요." — *가시성 최소화* 원칙.
+
+## 리뷰어 의견 요지
+
+- ***View 검증* + *도메인 require* 둘 다 정당** — View = 재입력, require = 논리 오류 안전망.
+- **일급 컬렉션 = *도메인 어휘* (객체지향)** — 중복 제거는 부수효과.
+- **테스트를 위한 *public 노출 X*** — 내부 구현이 아닌 *API*만 테스트.
+- **테스트 본문 *지역성*** — MethodSource 분리는 *두 곳 보기* 강요.
+- **상수 위치 = 도메인 책임**.
+- ***Range 검증과 Flyweight 조회 일원화*** — `requireNotNull(map[x])`.
+- **에러 메시지에 *변수 값 포함*** — 로그 수집 시 *데이터 사라짐* 방지.
+- **테스트 전용 함수 *test SourceSet*에**.
+- **상수 *private 기본***.
+
+- **대표 인용:**
+  > 논리 오류는 *컴파일 오류도 없고 런타임에 예외도 발생하지 않아서 디버깅하기가 어려우므로 빠르게 실패하도록* 만들어 줘야 합니다.
+  > — @galcyurio on `src/main/kotlin/view/InputView.kt`
+
+  > 중복 코드를 줄이는 것보다도 더 중요한 목적이 바로 *객체 지향적인 코드*가 되기 때문입니다. *List<Int>를 로또로 처리하는 것보다는 Lotto를 로또로 처리하는 게 훨씬 더 좋은 가독성*을 가지게 됩니다.
+  > — @galcyurio on `src/main/kotlin/domain/LottoStatistics.kt`
+
+  > private 함수를 테스트한다는 것은 *내부 구현을 건드린다는 것과 마찬가지*입니다. *현재는 문제가 없을 수 있더라도 추후에 요구사항이 변경되면 테스트 케이스가 깨지게 되는 가장 큰 원인*이 됩니다.
+  > — @galcyurio on `src/test/kotlin/domain/LottoSellerTest.kt`
+
+  > 변수는 *메시지에 담지 않는 한 데이터가 사라지게* 됩니다. *실제로 배포가 되는 경우에는 로그만 따로 수집해 주는 툴을 사용*하시게 될 겁니다.
+  > — @galcyurio on `src/main/kotlin/domain/LottoNumber.kt`
+
+## 얻은 교훈
+
+- **View 검증 ≠ Domain `require`** — *View 검증*은 *사용자 재입력*, *Domain require*는 *논리 오류 안전망*. *두 위치 모두 정당*하며 *목적이 다름*.
+- ***인터페이스 주입 = Controller 단위 테스트***. `InputViewInterface`, `ResultViewInterface`로 *Fake View* 주입 가능.
+- **일급 컬렉션 = *도메인 어휘*** — 중복 제거는 부수효과. *Lotto*가 *List<Int>*보다 *가독성/객체지향* 우위.
+- **TDD에서 *private이 안 됨* = 책임 설계 부족**. *기능 명세 → 객체 협력 → 테스트* 순서.
+- **테스트는 *공개 API*만** — *private을 public화*는 *내부 구현 결합*. 요구사항 변경 시 테스트 깨짐.
+- **테스트 본문 *지역성*** — `MethodSource`는 *데이터-of-tests*만 추출하되 *의도*는 본문에.
+- **상수 위치 = *도메인***. `common`은 *진짜 공통*만. *Lotto 범위*는 *Lotto*.
+- **에러 메시지에 *입력값 동봉*** — *로그 수집 툴* 시대에 *변수 데이터*는 *메시지 안*이 유일한 보존 위치.
+- **테스트 전용 함수 = *test SourceSet*** — main 오염 회피.
+- **`const val` *private 기본*** — 가시성 최소화. *꼭 필요할 때만 노출*.
+- **`requireNotNull(map[x])` 패턴** — *Flyweight + 검증 일원화*. *Range 재검사 + !!*는 *동기화 오류 위험*.

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

@@ -0,0 +1,150 @@
+# PR #36 — [멘델] 2단계 로또
+
+- **Reviewee:** [@rhthrhrl0](https://github.com/rhthrhrl0)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/36
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 16
+
+## 잘한 점 (설계 관점)
+
+- **`@JvmInline value class LottoNumber`** — 리뷰어 칭찬: "value class 활용 👍".
+- **`Validator` object 후속 도입** — `validateMakeXxx` 패턴으로 *null 반환 + 객체 생성* 책임 합침.
+- **`OutputView`가 *도메인 데이터 받아 렌더링*** — 리뷰어 칭찬: "UI에서 domain의 데이터를 받아서 *렌더링 👍*".
+- **학생의 *추가 질문 라운드*** — `runCatching` 제거 의도를 *두 가지 해석*으로 캡처 + 이미지 첨부 ("이런 식으로 분리하는 것을 말씀하신 건가요?").
+
+## 못한 점 (설계 관점)
+
+### 1. *상수 private 해제* — *책임 위치* 잘못
+
+```diff
+ companion object {
+-    private const val ONE_LOTTO_MONEY = 1000
++    const val ONE_LOTTO_MONEY = 1000
+ }
+```
+
+학생 자가 코멘트: "LottoSeller 클래스의 *sellManualLottos 메소드에서 1000이라는 숫자가 필요해서 private 해제*해 줬습니다 ㅜ" — *다른 클래스가 상수 필요*하면 *private 해제*가 아니라 *그 책임을 어디 둘지* 재검토. 결국 `sellAutoLottos`가 `PurchaseLottoMoney(count * ONE_LOTTO_MONEY)`를 만드는 것 자체가 *위치 의심*. 학생도 후속에서 알아챔.
+
+### 2. *정상 Flow에 `runCatching`* — try-catch 남용
+
+```kotlin
+override fun getMoney(): PurchaseLottoMoney {
+    while (true) {
+        println(INPUT_MESSAGE_FOR_PURCHASE_MONEY)
+        val money = validateMoney(readln().toIntOrNull()) ?: continue
+        runCatching { PurchaseLottoMoney(money) }
+.onSuccess {. return it }
+.onFailure { println(it.message) }
+    }
+}
+```
+
+리뷰어: "전체적으로 *runCatching()을 사용*해 주셨는데 *프로그램의 정상 Flow에 해당되는 경우들은 모두 제거*해 주세요." + "프로그램의 *정상적인 Flow에서 예외를 던지고 try-catch를 통해 처리하는 방법은 지양*해야 합니다. *논리 오류일 때 예외를 던지라는 것은 런타임에 예외도 발생하지 않아서 로그로도 안 남는 최악의 상황을 그나마 예외라도 던지게 만들어서 로그에 수집되게 만들라는 의미*입니다."
+
+학생 질문 (좋은 메타-질문): "생성자 호출 부분에서 *runCatching을 모두 사용*해 주었는데 *이렇게 하면 안 되는 걸까요*? 아니면 *runCatching 로직을 함수 매개변수를 가진 메소드로 분리해서 생성자를 호출할 때 재활용*해서 코드의 중복을 줄이라는 말씀이신가요??" 리뷰어: "*잘못된 입력이 들어왔을 때, 재입력을 받는 것은 충분히 예상 가능한 정상적인 Flow*입니다. 그렇기 때문에 *예외를 던져서 그것을 try-catch하는 식으로 코드를 작성하는 것은 예외 처리 기능을 잘못 사용*하는 것입니다. *유효성 검사를 한 뒤에 제대로 된 응답인 경우에만 생성자를 호출*하도록 만들어 보세요." + "*논리 오류인 경우에 예외를 던지는 것들은 프로그램 전역적으로 설정된 예외 처리기를 통해 로그가 남도록* 만들면 좋습니다. 코틀린에서는 *Thread.setUncaughtExceptionHandler()를 이용*해서 catch 되지 않은 Exception들을 잡아서 추가 처리를 해 줄 수 있습니다." + [Roman Elizarov - Kotlin and Exceptions](https://medium.com/@elizarov/kotlin-and-exceptions-8062f589d07) 링크.
+
+### 3. `LottoSeller.sellManualAndAuto` — *예외 던지는 검증*
+
+```kotlin
+fun sellManualAndAuto(purchaseInfo: LottoPurchaseInfo, requestManualNumbers: List<Lotto>): Ticket {
+    require(purchaseInfo.manualCount == requestManualNumbers.size) {
+        ERROR_MANUAL_COUNT_NOT_EQUAL.format(.)
+    }
+.
+}
+```
+
+학생: "LottoPurchaseInfo 객체랑 *수동 발급 로또인 List<Lotto>를 다시 래핑해서 생성자 쪽에서 검증해 주는 클래스를 만들어야 할까요*? 지금은 *[구매하려 하는 수동 로또의 개수]와 [발급을 요청한 List<Lotto>] 둘의 크기가 같다는 검증을 LottoSeller가 가진 메소드 쪽에서 수행*하고 있습니다." 리뷰어: "이 부분도 마찬가지로 *예측할 수 없는 비정상적인 case가 아니라 충분히 발생할 수 있는 정상 Flow*입니다. *잘못된 입력을 했을 때, 다시 재입력을 받을 수 있는 구조*로 변경해 보세요." — *경계 검증을 View*에서.
+
+### 4. `if`/`when` *중괄호 생략* — 공식 컨벤션
+
+```kotlin
+private fun sellAutoLottos(count: Int): Ticket =
+    if (count == 0) Ticket(emptyList())
+    else sellLottos(PurchaseLottoMoney(count * ONE_LOTTO_MONEY))
+```
+
+리뷰어: "[공식 컨벤션](https://kotlinlang.org/docs/coding-conventions.html#control-flow-statements)에 따르면 *if문과 when문은 2줄 이상이면 중괄호를 사용*합니다."
+
+### 5. `Lotto.toString()` — *View 로직 도메인 침투*
+
+```kotlin
+override fun toString(): String {
+    val sb = StringBuilder("[")
+    numbers.forEach { lottoNumber -> sb.append("${lottoNumber.number}, ") }
+    sb.delete(sb.length - 2, sb.length)
+    sb.append("]")
+    return sb.toString()
+}
+```
+
+리뷰어: "*UI 로직*에 해당됩니다. *View에서 Lotto의 정보를 받아서 UI를 그리도록* 만들어 보세요." 학생 후속: `OutputView.printLottoNumbers(lotto: Lotto)`로 이동 — *대괄호 포맷*은 View 책임.
+
+### 6. `LottoStatistics`가 *Map* 반환 — Tell, Don't Ask
+
+```kotlin
+fun matchTicket(ticket: Ticket): Map<Rank, Int> {. }  // ⚠ 컬렉션 반환
+fun yield(result: Map<Rank, Int>, purchaseLottoMoney: PurchaseLottoMoney): String {. }
+```
+
+리뷰어: "*UI 단에 데이터를 넘겨주는 것과 같이 꼭 필요한 경우가 아니라면 외부로 데이터에 넘겨서 처리하는 방식은 지양*해 주세요. *객체에 메시지를 전달하여 객체 내부에서 처리한 뒤 값을 반환*하도록 만들어 보세요." 학생: `LottoResult` 도입 — *결과 객체*로 캡슐화.
+
+### 7. `Ticket` *역할 없음* — 단순 래퍼
+
+```kotlin
+class Ticket(val lottos: List<Lotto>)
+```
+
+리뷰어: "*Ticket이 사실상 아무 역할도 하지 않고 있*습니다. *외부에서 Ticket의 값을 꺼내서 쓰는 대신에 Ticket 내부에서 lottos를 이용하여 처리한 뒤 값을 반환*하도록 만들어 보세요." 학생: `Ticket.matchTicketCount(winningLotto)`, `Ticket.forEach` 등 *컬렉션 방법론을 객체 내부에서*.
+
+### 8. `deepCopy` vs `copy` — 명시적 네이밍
+
+```kotlin
+class Ticket(lottos: List<Lotto>) {
+    private val _lottos = lottos.toList()
+    val lottos: List<Lotto> get() = _lottos.toList()
+}
+```
+
+리뷰어: "코틀린에서는 *data class로 선언하면 자동으로 얕은 복사가 되는 copy() 함수가 만들어집니다*. *깊은 복사를 제공해 주고 싶을 때는 명시적으로 deepCopy()와 같이 함수명으로 드러내* 주면 좋습니다." — *복사 의미*를 *이름*에.
+
+### 9. `validateXxx()` *Boolean 관행*
+
+리뷰어: "별개로 *validateXxx()와 같은 네이밍의 함수들을 보통 Boolean을 반환*하도록 만듭니다. 현재 구현도 나쁘지 않지만 *validateXxx()를 호출하고 true이면 객체를 생성하고 아니면 다시 재입력을 받는 구조*로 만들어도 좋습니다." — *검증과 생성을 한 함수*로 합치는 것보다 *책임 분리*가 관행.
+
+## 리뷰어 의견 요지
+
+- **`runCatching` = *정상 Flow가 아닌 경우*만**. 입력 재시도는 *명시적 null 반환 + while*.
+- **논리 오류의 예외 = *로그 + UncaughtExceptionHandler***.
+- **`if/when` 2줄 = *중괄호 필수***.
+- **`toString()` View 침투 금지** — *대괄호 포맷*도 View.
+- **컬렉션 반환 vs *객체 메시지*** — `Ticket.matchTicketCount(winningLotto)`.
+- **단순 래퍼 클래스는 *행동 추가*가 정상**.
+- **`deepCopy` 명시적 네이밍**.
+- **`validateXxx` = Boolean 관행**.
+
+- **대표 인용:**
+  > 프로그램의 정상적인 Flow에서 예외를 던지고 try-catch를 통해 처리하는 방법은 *지양*해야 합니다.
+  > — @galcyurio on `src/main/kotlin/view/InputView.kt`
+
+  > 논리 오류일 때 예외를 던지라는 것은 *런타임에 예외도 발생하지 않아서 로그로도 안 남는 최악의 상황을 그나마 예외라도 던지게 만들어서 로그에 수집*되게 만들라는 의미입니다.
+  > — @galcyurio on `src/main/kotlin/view/InputView.kt`
+
+  > UI 단에 데이터를 넘겨주는 것과 같이 꼭 필요한 경우가 아니라면 *외부로 데이터에 넘겨서 처리하는 방식은 지양*해 주세요.
+  > — @galcyurio on `src/main/kotlin/domain/LottoStatistics.kt`
+
+  > Ticket이 *사실상 아무 역할도 하지 않고* 있습니다. *외부에서 Ticket의 값을 꺼내서 쓰는 대신에 Ticket 내부에서 lottos를 이용하여 처리한 뒤 값을 반환*하도록 만들어 보세요.
+  > — @galcyurio on `src/main/kotlin/domain/Ticket.kt`
+
+## 얻은 교훈
+
+- **다른 클래스가 상수 필요 → *책임 위치 재검토*** — *private 해제*는 결합도 신호. `1000원`이 *판매소* 책임인가 *금액 도메인* 책임인가.
+- **`runCatching`은 *예측 불가 오류*에만** — *재입력*은 *정상 Flow*이므로 *null 반환 + while*.
+- **논리 오류 = *예외 + 전역 핸들러*** — 로깅을 위한 *최후 안전망*.
+- **`if/when` 2줄 이상 = 중괄호** — Kotlin 공식 컨벤션. PR #49 잭슨도 같은 지적.
+- **`toString()`은 View 책임** — *대괄호 포맷*도 도메인이 알면 *다국어/A-B 테스트* 시 도메인 변경.
+- **컬렉션 반환 vs *결과 객체*** — `Map<Rank, Int>` 노출보다 `LottoResult.profitRate()`가 *Tell, Don't Ask*.
+- **단순 래퍼 = *행동 추가 가능 신호*** — `Ticket`이 *값만 보유*하면 `lottos.count { winning.match(it) }`이 외부에 흩어짐.
+- **`deepCopy` 명시** — `copy()`는 *얕은*. *깊은*은 이름으로 드러내야.
+- **`validateXxx` = Boolean** — *검증 + 생성*을 한 함수에 두는 것은 *책임 결합*. 분리가 관행.

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

@@ -0,0 +1,179 @@
+# PR #123 — [비비] 1단계 로또
+
+- **Reviewee:** [@rosemin928](https://github.com/rosemin928)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/123
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag (규일)
+- **라인 코멘트:** 45 (리뷰어 27 + 학생 18)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoGenerator` interface** — Strategy.
+- **README 작성** — 칭찬: "README 작성 정말 좋네요~👍".
+- **테스트 fixture 도입** — 후속 라운드에서 학생이 적용. 리뷰어: "*test fixture를 적용해 주신 내용을 보니, 해당 코멘트는 넘어가도 될 것* 같습니다ㅎㅎ".
+- **후속 라운드 칭찬 빈출** — "Profit 객체가 정말 *이익률을 계산하는 객체로 변경*되었군요~👍" / "*non-nullable하던 것에 대한 처리 좋네요*~👍" / "LottoApplication이라고 *네이밍을 변경해 주셨군요*~👍".
+
+## 못한 점 (설계 관점)
+
+### 1. `main()` 이름 모호 — *다게임 확장 시*
+
+리뷰어: "추후 *게임 종류가 많아진다면, main()이라는 네이밍이 다소 애매하게 느껴질* 수 있겠네요~ *이를 로또에 맞게 바꾸려면 어떻게 바꿔 보는 것이 좋을까요*?🤔" 학생 후속: `LottoApplication`. 칭찬 받음.
+
+### 2. *하드 코딩 문구* 다수
+
+리뷰어: "*하드 코딩된 문구들에 대해서, 상수화를 해 보는 것은 어떨까* 라는 생각이 듭니다~💪" + 전체 코멘트: "전반적인 코멘트입니다! 위에서 남겨 둔 코멘트처럼 *하드코딩된 내용들에 대해서 상수화를 진행해 보는 것*은 어떨까 라는 생각이 듭니다~"
+
+### 3. *결과를 Map으로 반환* — `WinningStatistics` 객체화
+
+```kotlin
+fun calculateResult(.): Map<Rank, Int> =.  // ⚠ 원시 컬렉션 반환
+```
+
+리뷰어: "*Map으로 리턴되는 값들을 WinningXXX or Lottos 등으로 묶어 보는 것은 어떨까* 라는 생각이 듭니다~🤔 그렇다면 *OutputView.printResult() 내의 로직 등 여러 가지 책임을 가질 수 있겠다*는 생각이 드네요!"
+
+### 4. `Profit` *원시값 노출* — 객체 책임화
+
+```kotlin
+val profit: Double =.
+```
+
+리뷰어: "*원시값 포장을 한다면, Profit이라는 객체도 책임을 가지게 해 볼 수도 있겠군요*!" 학생 후속: `Profit` 클래스에 *이익률 계산 책임* 부여. 리뷰어 칭찬: "*Profit 객체가 정말 이익률을 계산하는 객체로 변경*되었군요~👍".
+
+### 5. *Interface 사용 의도* 메타-질문
+
+리뷰어: "*Interface를 사용해 주셨군요!!👍 interface를 사용하신 이유*가 궁금합니다~🤔"
+
+### 6. *문자 입력 → 폭파* (주석으로 표시)
+
+```kotlin
+// 문자가 들어오면.
+```
+
+리뷰어: "주석에 *남겨주셨네요😅 문자가 들어오면. 서비스는 폭파되겠군요..!*" — *알면서도 안 한 것*은 *기술 부채 명시화*인 점은 좋으나 *해결*이 더 좋음.
+
+### 7. *함수가 너무 많은 기능*
+
+리뷰어: "*하나의 함수가 많은 기능을 담당하고 있는 것* 같은데, *이를 어떻게 분리를 해 볼 수 있을까요*~🤔"
+
+### 8. *다국어 시나리오* — Controller 적용?
+
+리뷰어: "*만약 한국 로또 / 미국 로또 / 일본 로또된다면 언어마다의 Input/Output이 있을 텐데, 이는 어떻게 LottoController에 적용을 해 볼 수 있을까요*??🤔 한 번 고민해 보면 좋을 내용인 것 같아서 코멘트 남겨 두었습니다! *수정이 필요한 것은 아닙니다*"
+
+### 9. *1000원 단위 강제 vs 거스름돈*
+
+리뷰어: "*로또 구매 금액을 무조건 1000원 단위로 받아야 할까요*..? 비비의 의견을 알려 주세요! 요구사항에는 없기는 하지만, *물가 인상률이 반영되어 로또가 1100원이 된다면 동전이 없다면 10장 단위를 꼭 맞춰야 할까요*?" — *현실 메타포*. *물가 인상*은 *우테코 리뷰어 공통 가르침*.
+
+### 10. *분리 책임 다국어/지역화* — LottoNumber에 응집
+
+리뷰어: "*해당 내용은 만약 LottoNumber라는 객체가 있다면, 해당 객체의 책임으로 볼 수도 있겠*군요!" — *책임을 도메인 객체에 부착*.
+
+### 11. *`Profit` 생성자에 lottoBundle, winningLotto* — 의존 깊이
+
+```kotlin
+class Profit(
+    private val lottoBundle: LottoBundle,
+    private val winningLotto: WinningLotto,
+    val profit: Double
+)
+```
+
+리뷰어: "*profit이 생성자로 있는 이유*가 궁금합니다!" + "해당 객체에서도 *lottoBundle, winningLotto가 반드시 있어야 할까요*?🤔 현재의 *댑스를 보면 Controller → Profit → WinningStatistics으로 객체 간의 의존성이 생기고 있는 것* 같아서, *Controller → Profit & WinningStatistics 형태*로도 변경을 해 보는 것은 어떤가 라는 생각이 듭니다! *현재 구조를 보면 객체 간의 결합이 강하게 되어 있다*는 생각이 드네요" — *직렬 의존* → *병렬 의존*으로 결합도 낮춤.
+
+### 12. *non-nullable 강제* → 오류 위험
+
+```kotlin
+result[rank] = result[rank] + 1  // ⚠ null 가능
+```
+
+리뷰어: "*non-nullable하다고 강제하는 것은 오류를 발생시킬 수 있*습니다!"
+```kotlin
+result[rank] = result[rank] ?: (0 + 1)
+```
+— `Map<K, V>` getter는 *nullable*. *!!*이나 *non-null 단언*은 *Map 초기화 가정* 의존.
+
+### 13. *InputView 네이밍*
+
+리뷰어: "Application 때와 동일하게, *InputView한테 좀 더 유의미한 네이밍을 어떤 방식으로 지어 줄 수 있을까요*?"
+
+### 14. *테스트 네이밍 + given/when/result*
+
+리뷰어: "*테스트 코드의 경우 어떤 테스트인지 확실하게 알 수 있게 네이밍*을 정해 주는 것도 좋은 것 같습니다!"
+```kotlin
+@Test
+fun `자동차가 1칸 이동하면 거리는 1이다`() {
+    // given
+    val myCar = Car("Duru")
+    // when
+    myCar.move(1)
+    // result
+    assertThat(myCar.distance).isEqualTo(1)
+}
+```
++ "*주어진 것 / 어떤 액션 / 액션의 결과 구분*으로입니다. 여러 객체들 간에 유기적으로 연결이 되어 있는 테스트를 할 경우에는 *코드 라인 수도 늘어나고, 어떤 것을 테스트하는지 명확히 알아보기 힘든 경우가 있었어서 주어진 것 / 어떤 액션 / 액션의 결과로 테스트 함수 내에서 분리*해 보는 것도 좋을 것 같습니다." — *Arrange-Act-Assert* 또는 *Given-When-Then* 패턴.
+
+### 15. *테스트 커버리지 IDE 지원*
+
+리뷰어: "테스트 코드 잘 작성해 주셨네요~👍 참고해 보면 좋을 내용인 것 같아서 남겨 두었습니다! https://developer.android.com/studio/test/test-in-android-studio#view_test_coverage *테스트 코드를 어느 정도로 작성했는지 확인하는 방법으로 테스트 커버리지라는 개념*이 있습니다. 물론 *IDEA에서 기능을 지원*해 주고 있습니다~"
+
+### 16. *일급 컬렉션* 학생 자가 의문
+
+학생: "*일급 컬렉션을 사용해 보려고 했습니다.! 이렇게 사용하는 것이 맞는지 확신이 서지 않아서 더 공부*해 보고 싶습니다!"
+
+리뷰어: "*저랑 이번 미션을 진행하면서 같이 얘기해 보면 좋을 것 같습니다*! 우선 *비비가 생각하시는 '원시값 포장 & 일급 컬렉션'은 무엇인가요*? (정답을 원하는 게 아니라 비비가 *문득 생각해 봤을 때 드는 생각을 남겨* 주세요. *아무말 대잔치여도 좋습니다*~) 일급 컬렉션에 대해서 참고해 보면 좋을 내용들이 있어서 남겨 두었습니다 - https://jojoldu.tistory.com/412".
+
+### 17. `LottoTicketCounter` vs `LottoStore` *동일 목표*
+
+리뷰어: "*LottoTicketCounter와 LottoStore는 돈을 받고 로또를 발행한다는 동일한 목표를 바라보고 있는 것 같은데, 하나로 합쳐 보는 것도* 좋을 것 같습니다~💪" — *유사 책임 객체 통합*.
+
+### 18. *문자열 검증 후 Double로* — InputView가 형 변환 책임
+
+리뷰어: "*input에 대한 검증은 inputView에서 하였으니, String 말고 Double 형으로 받아 볼 수 있겠*군요!" — *View가 검증 + 변환*, *Controller/Domain은 검증된 타입* 수용.
+
+### 19. *winningStatics 자체 받기* — 플로우 명확화
+
+리뷰어: "현재는 *winningStatics 자체를 받고 있어서, 헷갈릴 수도 있겠*다는 생각이 드네요! 아래와 같은 *흐름*으로 해 보면 좀 더 구현이 깔끔해질 수도 있겠다는 생각이 드네요~ *WinningLotto를 구한다 → WinningLottoStatics의 함수를 통해서 몇 개가 당첨 Or 결과를 리턴한다 → 결과를 Profit에 넣어준다.* 이렇게 한다면, *WinningLotto → 당첨 로또 → WinningLottoStatics → 나의 당첨 내역 → Profit → 내 이익률* 이런 순서로 *구현의 플로우가 잘 드러날 수 있겠*다는 생각이 듭니다!"
+
+## 리뷰어 의견 요지
+
+- **`main()` 이름 → *애플리케이션 도메인***.
+- **하드코딩 문구 → *상수화***.
+- **`Map<Rank, Int>` → *WinningStatistics 객체***.
+- **`Profit` *원시값 → 책임 객체***.
+- **다국어 시나리오로 *interface 정당화***.
+- **1000원 단위 강제 → *거스름돈 / 자율***.
+- **`!!` 회피** — Map nullable 인식.
+- **`Profit` *직렬 의존* → *Controller가 병렬 의존***.
+- **`LottoTicketCounter` + `LottoStore` *통합* 가능**.
+- **`InputView`가 *Double 형*까지 변환**.
+- **`given/when/result` 테스트 구조**.
+- **테스트 커버리지 IDE 지원**.
+- **일급 컬렉션 *책 참고*** — jojoldu 블로그.
+
+- **대표 인용:**
+  > 만약 한국 로또 / 미국 로또 / 일본 로또된다면 *언어마다의 Input/Output이 있을 텐데, 이는 어떻게 LottoController에 적용을 해 볼 수 있을까요*?
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/LottoController.kt`
+
+  > 물가 인상률이 반영되어 *로또가 1100원이 된다면 동전이 없다면 10장 단위를 꼭 맞춰야 할까요*?
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/PurchaseAmount.kt`
+
+  > 현재 구조를 보면 *객체 간의 결합이 강하게 되어 있다*는 생각이 드네요.
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/Profit.kt`
+
+  > 우선 비비가 생각하시는 *'원시값 포장 & 일급 컬렉션'은 무엇인가요*? (정답을 원하는 게 아니라 비비가 문득 생각해 봤을 때 드는 생각을 남겨 주세요 *아무말 대잔치여도 좋습니다*~)
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/Lottos.kt`
+
+## 얻은 교훈
+
+- **`main()` 이름 = *애플리케이션 진입점*** — *다게임 확장* 시 `LottoApplication`처럼 *도메인 명시*.
+- **`Map<Rank, Int>` → *WinningStatistics 객체*** — *원시 컬렉션 반환*은 *호출자가 자료구조 직접 다룸*. 객체 캡슐화 = *책임 위임 + 출력 책임* 단순화.
+- **`Profit` *원시값 → 책임 객체*** — *Double 노출*은 *계산식이 호출자*에. *수익률 계산까지 객체* 책임화.
+- **다국어 시나리오 = interface 정당화** — PR #64 *키오스크*, PR #80 *Quest/Task/ToDo A-B*와 같은 패턴. *국제화*는 *우테코 리뷰어 공통 가르침*.
+- **1000원 단위 = *거스름돈 시나리오*** 
+- **`!!` 회피** — `Map` getter *nullable* 인식. *non-null 단언*은 *초기화 가정* 의존.
+- **`Profit` 직렬 의존 → 병렬 의존** — *Controller → Profit → WinningStatistics*는 *결합도 강*. *Controller → Profit & WinningStatistics* 동등하게.
+- **`LottoTicketCounter` + `LottoStore` *동일 책임* 통합** — *클래스 분리 ≠ 책임 분리*.
+- **`InputView` *Double 변환까지*** — *검증 + 형 변환*은 *View 책임 한계*에.
+- **`given/when/result`** — 테스트 *3구역 분리*. *유기적 객체 테스트*는 *시각적 구분*이 가독성.
+- **테스트 커버리지 *IDE 지원*** — IDEA *기능 활용*. *기계 측정*에 의존, *수치*는 *추적*만.
+- **일급 컬렉션 = *책 + 블로그 참고*** — jojoldu 블로그는 *우테코 공통 자료*.
+- **객체 흐름 = *도메인 어휘 시퀀스*** — `WinningLotto → 당첨 → WinningLottoStatics → 내역 → Profit → 이익률` 식의 *시퀀스 다이어그램*.