oh-my-oop 0.2.0

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

@@ -0,0 +1,137 @@
+# PR #72 — [서기] 1단계 로또
+
+- **Reviewee:** [@Yunseok-Nam](https://github.com/Yunseok-Nam)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/72
+- **단계:** 1단계
+- **리뷰어:** @vagabond95 (스카이)
+- **라인 코멘트:** 24 (리뷰어 16 + 학생 8)
+
+## 잘한 점 (설계 관점)
+
+- **인터페이스 활용** — 리뷰어 칭찬: "인터페이스 활용 👍".
+- **`Rank` 보너스 번호 체크 분기 통합** — 리뷰어 칭찬: "*보너스 번호 체크 여부를 넣어서, 2등에 대한 별도 분기 처리를 하지 않아도 되겠*네요! *보통 놓치기 쉬운 부분인데 잘 구현해 주셨습니다* 👍 💯".
+
+## 못한 점 (설계 관점)
+
+### 1. `PurchaseAmount` 만들었지만 *Int 반환*
+
+```kotlin
+class PurchaseAmount(val value: Int) {. }
+fun calculateCount(amount: PurchaseAmount): Int = amount.value / PURCHASE_UNIT  // ⚠
+```
+
+리뷰어: "*PurchaseAmount 클래스를 만들어 주셨는데, Int 타입을 리턴해 주게 된다면 해당 클래스를 사용하는 의미가 반감*될 것 같아요." — *값 객체 만들었으면 그 객체로 다루기*.
+
+### 2. *PURCHASE_UNIT을 Controller가 앎*
+
+```kotlin
+val count = amount.value / PURCHASE_UNIT  // ⚠
+```
+
+리뷰어: "*PURCHASE_UNIT는 PurchaseAmount 내부에서 알고 있으니, PurchaseAmount에서 직접 이 값을 리턴*해 주는 것은 어떨까요? *controller에서 모델에 대한 세부 사항에 되도록 의존하지 않도록* 구현해 보면 좋을 것 같아요 :)" + "*PURCHASE_UNIT이라는 상수 중복도 제거*할 수 있게 되구요." — Tell, Don't Ask.
+
+### 3. *값 재사용 없으면 바로 return*
+
+리뷰어: "*값을 재사용하지 않는다면 바로 리턴해도 좋겠*네요!" — 불필요한 중간 변수.
+
+### 4. `generateLotto` *LottoStore 반환* — 시그니처 모순
+
+```kotlin
+fun generateLotto(): LottoStore =.  // ⚠
+```
+
+리뷰어: "*generateLotto 함수인데 리턴은 LottoStore인 게 조금 어색*한 것 같아요." — *함수명-반환 타입* 일치.
+
+### 5. *split이 도메인에* — View 책임
+
+```kotlin
+fun parse(input: String): List<Int> = input.split(SPLIT_DELIMITER).map { it.toInt() }  // ⚠
+```
+
+리뷰어: "*SPLIT_DELIMITER는 view 레벨에서 알 수 있는 값이므로, split 과정은 view에서 수행하는 것이 적절*하지 않을까요?".
+
+### 6. *중복 방지 자료구조 (Set)*
+
+```kotlin
+class Lotto(val numbers: List<Int>) {
+    init { require(numbers.distinct().size == 6) }  // ⚠ List + 검증
+}
+```
+
+리뷰어: "검증을 꼼꼼하게 잘 해 주셨네요 👍 그런데, *로또 번호의 경우 특성상 값이 겹치면 안 되기 때문에 아예 중복을 막을 수 있는 자료구조를 사용*해 보는 것도 좋을 것 같아요. *내부에서는 검증이 완료되었지만, 외부에서는 자료구조만 봤을 때 중복이 됐는지 되지 않았는지 알 수 없으니 또다시 중복 처리를 이어나갈 가능성도 있구요*!" — *invariant를 타입으로 표현*.
+
+### 7. *외부에서 컬렉션 수정 가능* — 일급 컬렉션 의미 반감
+
+리뷰어: "*외부에서 컬렉션 수정이 가능한 타입*이네요. *이럴 경우 일급 컬렉션은 단순한 wrapping class 밖에 안 되기 때문에 활용하는 이유가 반감*될 것 같아요." — *MutableList* 노출 X.
+
+### 8. *Controller가 lottos를 상태로* — Lottos와 역할 중복
+
+```kotlin
+class LottoController {
+    private val lottos: MutableList<Lotto> = mutableListOf()  // ⚠
+}
+```
+
+리뷰어: "*lottos를 상태로 가지고 있을 필요가 있을까요*~? *이로 인해 lottos와 역할이 상당히 겹쳐* 보여요." — *Controller에 상태* = *Lottos와 책임 중복*.
+
+### 9. *Lottos가 스스로 수행*
+
+리뷰어: "*이 로직도 Lottos가 '스스로' 수행하는 것이 더 자연*스럽지 않을까요~?" — Tell, Don't Ask.
+
+### 10. *`Lotto` vs `Lotto 개수`* — 메서드 위치
+
+리뷰어: "*Lotto보다는 Lotto의 개수와 관련된 함수에 가깝지 않을까요*~?" — *함수 위치 = 책임 일치*.
+
+### 11. *Set이면 `distinctBy` 불필요*
+
+리뷰어: "*set 자료구조로 변경되었으므로, distinctBy 처리가 제거되어도 동일한 결과*가 나올 것 같아요!" — *자료구조 invariant*가 *검증 코드 대체*.
+
+### 12. `object` *vs class* — 학생 자가 질문
+
+리뷰어: "*해당 클래스를 object로 선언해 주었을 때, 장/단점은 무엇이 있을까요*? 추가로 *object 클래스를 활용하는 기준이 따로 있으실지* 궁금합니다 :)" — 패턴.
+
+### 13. *purchaseAmount = 0* 예외
+
+리뷰어: "*purchaseAmount가 0인 경우에 대한 예외 처리가 필요*해 보여요!"
+
+## 리뷰어 의견 요지
+
+- **값 객체 만들었으면 *그 객체로 다루기*** — Int 반환 = 의미 반감.
+- **Controller가 모델 세부에 의존 X**.
+- **함수명 = *반환 타입 일치***.
+- **`split` *View 책임***.
+- **중복 방지 = *Set 자료구조***.
+- **컬렉션 외부 수정 *MutableList 노출 X***.
+- **Controller 상태 vs Lottos = 책임 중복**.
+- **Tell, Don't Ask** — Lottos 스스로.
+- **함수 위치 = *책임 일치***.
+- **자료구조 invariant** → 검증 코드 단순화.
+- **0 예외 처리**.
+
+- **대표 인용:**
+  > PurchaseAmount 클래스를 만들어 주셨는데, *Int 타입을 리턴해 주게 된다면 해당 클래스를 사용하는 의미가 반감*될 것 같아요.
+  > — @vagabond95 on `src/main/kotlin/lotto/domain/PurchaseAmount.kt`
+
+  > 외부에서는 자료구조만 봤을 때 *중복이 됐는지 되지 않았는지 알 수 없으니 또다시 중복 처리를 이어나갈 가능성도 있*구요!
+  > — @vagabond95 on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+  > 외부에서 컬렉션 수정이 가능한 타입이네요. 이럴 경우 *일급 컬렉션은 단순한 wrapping class 밖에 안 되기 때문에 활용하는 이유가 반감*될 것 같아요.
+  > — @vagabond95 on `src/main/kotlin/lotto/domain/Lottos.kt`
+
+  > 보통 놓치기 쉬운 부분인데 잘 구현해 주셨습니다 👍 💯
+  > — @vagabond95 on `src/main/kotlin/lotto/domain/Rank.kt`
+
+## 얻은 교훈
+
+- **값 객체 *유지*** — `PurchaseAmount.numberOfLottos(): LottoCount`. *Int 반환*은 *값 객체 의미 반감*.
+- **Controller *모델 세부 의존 X*** — `PURCHASE_UNIT` 같은 *도메인 상수*는 *도메인 객체 내부*에.
+- **함수명 = *반환 타입 일치*** — `generateLotto(): LottoStore`는 *의도 불일치*.
+- **`split`은 *View 책임*** — *delimiter*는 *입력 형식*에 속함.
+- **중복 방지 *자료구조*** = *Set*. *invariant를 타입으로*.
+- **`MutableList` 외부 노출 X** — *일급 컬렉션 의미*는 *불변 + 행위 부여*. *Mutable 노출*은 *wrapper 수준*.
+- **Controller 상태 = *Lottos와 책임 중복*** — *상태 + 행위*가 *한 객체*에 응집해야.
+- **Tell, Don't Ask** — `lottos.calculate()`, `lottos.match()`.
+- **함수 위치 = *책임 일치*** — *Lotto 개수*는 *Lottos*. *Lotto 자체*는 *6개 번호*.
+- **자료구조 invariant** = 검증 코드 단순. `Set.distinctBy` 불필요.
+- **0 예외** — *경계값 처리*.
+- **`object` 기준 *자가 정리*** — *상태 없음 + 단일 인스턴스 + 변경 가능성 낮음*. 패턴.

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

@@ -0,0 +1,17 @@
+# PR #86 — [로또] 서기 2단계 미션
+
+- **Reviewee:** [@Yunseok-Nam](https://github.com/Yunseok-Nam)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/86
+- **단계:** 2단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 12
+
+## 핵심 지적
+
+> 중첩된 컬렉션은 코드를 이해하기 어렵게 만드는 것 같아요. 중첩되지 않은 형태로 개선해볼 수 있을까요~?
+
+→ `List<List<Int>>` 같은 형태 대신 도메인 객체 (`List<Lotto>`)로.
+
+## 얻은 교훈
+
+- **중첩 컬렉션 회피** — `List<List<T>>`는 의미 모호. 도메인 객체로 wrapping.

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

@@ -0,0 +1,62 @@
+# PR #102 — [로또] 차람 2단계 미션
+
+- **Reviewee:** [@aprilgom](https://github.com/aprilgom)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/102
+- **단계:** 2단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 46
+
+## 못한 점 + 핵심 지적
+
+### 1. `run()`이 너무 많은 일
+
+```kotlin
+fun run() {
+    // 입력 + 검증 + 발급 + 매칭 + 출력
+}
+```
+
+→ 함수 분리.
+
+### 2. `Money.divide` nullable 반환
+
+```kotlin
+class Money {
+    operator fun div(other: Money): Money? =.  // ⚠ nullable
+}
+```
+
+> 나눌경우 nullable하도록 설정하신 이유가 있을까요?? 이로 인하여 Money를 계산하는 부분에서 불필요한 nullcheck 하는 로직이 들어가고 있는 것 같습니다.
+
+→ 0 나눗셈은 예외 또는 *Optional 표현 명시*. 임의의 nullable 회피.
+
+### 3. 수동 로또 생성 객체 부재
+
+```kotlin
+class RandomLottoTicketGenerator {. }
+// ⚠ 수동 생성 객체 없음
+```
+
+> 현재 RandomLottoTicket을 생성해주는 객체는 존재하지만 수동으로 로또 티켓을 만들어주는 내용은 존재하지 않는 것 같네요
+
+→ Strategy 인터페이스로 자동/수동 통합.
+
+### 4. `Rank.decideRank()` when 사용
+
+```kotlin
+fun decideRank(.): Rank = when (.) {. }
+```
+
+> decideRank 함수에서 Enum의 API를 활용하여 when식은 가능하면 쓰지 않고 구현해 보는 방식을 고민해보면 좋을 것 같다는 생각이 듭니다
+
+→ `entries.find {. } ?: MISS` 패턴.
+
+### 5. `initList` 메서드명 — 의미 불명
+
+> 코드양이 많아질 경우 initList라는 네이밍에 대해서 고민해보는 것도 좋을 것 같습니다!
+
+## 얻은 교훈
+
+- **nullable의 의미는 *부재***. 0 나눗셈 같은 *오류* 표현 X.
+- **자동/수동 통합** = Strategy 인터페이스 + 두 구현체.
+- **enum API > when 분기** — `entries.find {. }`로 fallback.

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

@@ -0,0 +1,146 @@
+# PR #64 — [차람] 1단계 로또
+
+- **Reviewee:** [@aprilgom](https://github.com/aprilgom)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/64
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag (규일)
+- **라인 코멘트:** 50
+
+## 잘한 점 (설계 관점)
+
+- **`LottoPurchase`, `LottoResult`, `LottoTicket` 분리 + 원시값 포장 + init 검증** — 리뷰어 칭찬: "*LottoTicket 원시값 포장과 init으로 초기 Validation Check 좋네요*~👍".
+- **`enum class` 활용** — 리뷰어 칭찬: "enum class에 대한 활용 좋네요~".
+- **`companion object` String.Format** — 칭찬: "*Format을 활용하니까 코드를 한눈에 보기 좋네요*!".
+- **`InputView` interface화** — 리뷰어 칭찬: "*inputView를 이전과 다르게 interface화*시켜 주셨네요~👍".
+- **`by 키워드`** — 칭찬: "by 키워드의 사용 좋네요👍".
+- **`intersect` 활용** — 칭찬: "*intersect 너무 잘 사용*해 주셨네요!!💯💯💯".
+- **`value class LottoNumber`** — 칭찬: "*value class를 사용*해 주셨군요👍".
+- **`junit @ParameterizedTest` 활용** — 칭찬: "*junit의 기능들 활용 좋습니다*👍".
+
+## 못한 점 (설계 관점) — 메타-질문 + 학생 깊은 답변
+
+### 1. *View 인스턴스 = Controller 지역 변수*
+
+```kotlin
+class LottoController {
+    fun run() {
+        val inputView = InputView()  // ⚠ 지역
+        val outputView = OutputView()
+.
+    }
+}
+```
+
+리뷰어: "*반드시 수정이 필요한 내용은 아니며, inputView와 outputView을 지역 변수로 선언하신 이유*가 궁금합니다! 1. *구현할 수 있는 다른 방법은 어떤 것이* 있을까요?? 2. *현재 방법대로 구현을 했을 때는 어떤 단점이 존재*할까요??"
+
+학생: "1. *InputView와 OutputView를 Controller 밖에서 만들어서 가져오는 방법*이 있습니다. (main에서 LottoController(InputView, OutputView)) 아니면 *object 키워드를 써서 싱글턴*으로 만들어 버리는 방법도 있습니다. (object InputView) 2. 이 프로젝트에서는 *View가 만들어지는 시점을 어디에 둬도 크게 상관 없겠다 싶어 Controller에서 만들어 쓰고* 있었습니다.. *눈 앞의 명세만 구현한 셈*이네요.. 당장의 동작에는 별 문제가 없어 보이니, 그렇다면 *구조를 개선하기 위해 다른 요구사항이 찾아왔을 때 이 구조가 얼마나 대처할 수 있는지* 생각해 봤습니다. 만약에 *콘솔 어플리케이션이 아닌 키오스크로 로또를 뽑고 싶다*고 해 봤을 때, 대처가 가능할까요? 아마 안될 것 같습니다. 그래서, 먼저 *키오스크가 됐던 콘솔이 됐던 View에서 기대되는 동작들을 뽑아 인터페이스로* 만들어 봤습니다. 이후에 *Controller 내부에서 View의 구현체(ConsoleView 등..) 인스턴스를 만들어 쓸 경우 컨트롤러의 재사용이 힘드니 컨트롤러 내부에서 만들지 않고 외부에서 인터페이스로 받아* 줬습니다. *Controller에서는 이제 interface만 사용할 뿐 구현이 어떻게 된 지는 상관하지 않으니 이제 키오스크 View도 넣어 줄 수 있습니다*."
+
+→ *현실 변경 시나리오(키오스크)로 추상화 정당화*. *이상적 학습 답변*.
+
+### 2. `InputView` *Class vs object* — 같은 질문, 같은 답변
+
+리뷰어: "*InputView를 Class로 지정하신 이유*가 궁금합니다! 🤔" 학생: "지금 이 프로젝트에서는 *굳이 Class일 필요는 없어 보이고 object로 만들어도 상관없*어 보입니다. 하지만, *항상 요구사항은 변경이 있을 수 있으니 좋은 구조를 만들어 변경 사항에 최소한의 비용으로 대처*할 수 있다면 좋을 것 같네요. 위의 지적해 주신 부분(*컨트롤러 내부에서 View 인스턴스를 만들어서 쓰고 있는 코드*)와 같은 답변을 드릴 수 있을 것 같습니다."
+
+### 3. `LottoTicketMakeMethod` *동사 빠진 네이밍*
+
+```kotlin
+interface LottoTicketMakeMethod {
+    fun makeTicket(): LottoTicket
+}
+```
+
+리뷰어: "interface에 대한 활용 좋습니다!👍 수정이 반드시 필요한 것은 아니나 *LottoTicketMakeMethod라는 네이밍은 살짝 의미가 모호*해질 수도 있겠다는 생각도 드네요🤔 *LottoTicket을 만드는 것이니 LottoTicketGenerator 등등 여러 가지 이름을 적용*해 볼 수 있을 것 같습니다!" 학생: "*확실히 지금 네이밍은 행위를 하는 주체로 보이지는 않네요. LottoTicketGenerator 쪽이 더 나은 것 같습니다*!" — *Method*는 OOP 어휘에서 *내장 의미가 다름* (메서드). *Generator/Strategy*가 명확.
+
+### 4. `value class` vs `data class` — 학생 깊은 분석
+
+리뷰어: "*value class와 data class는 어떤 차이점이 존재*할까요?? 해당 내용을 *value class로 작성하신 이유*가 궁금합니다!🤔"
+
+학생 (놀라운 깊이): "*value class는 원시 타입도 모두 래핑하는 것이 제약조건*이라 사용했습니다. value class는 *하나의 값을 래핑해서 타입을 만들어 주고 싶지만 인스턴스를 만들어서 힙에 올려 두고 싶지 않을 때, 이것을 클래스의 사용처에 inline화*시키는.. *최적화를 위한 그런 키워드*라 알고 있습니다. 예를 들어 *fun foo(a: LottoNumber): Int의 경우는 자바로 변환될 때 int foo-맹글링해시코드(int a)*가 됩니다. 공식 문서를 보니 *웬만한 경우에는 inline화 되나 제네릭, 인터페이스나 Nullable처럼 원래 타입으로 쓰이지 않을 때에는 inline화 되지 않는다*고 하는데.. *rule of thumb이라고 적어 놓으니 정확한 기준인지를 모르겠*습니다 😞 페어의 피드백도 봤는데, *같은 번호의 LottoNumber 인스턴스가 중복이 될 가능성*이 있을 것 같습니다. *data class는 hashcode, isEqual 등을 컴파일러가 대신 작성해 주는 키워드*입니다. 이 쪽은 *value class와 달리 항상 힙에 올라가는 것으로 보이니.. 이 경우는 굳이 오버헤드를 감수해 가며 data class를 사용할 필요는 없을 것* 같습니다."
+
+→ *내부 컴파일러 동작 + 트레이드오프*까지 정리.
+
+### 5. `LottoNumber` *단독 의미 부재* — 자가 의문
+
+학생: "개인적으로는 *LottoNumber가 LottoTicket에서 떨어져 있을 때, 그것이 로또 번호로서의 의미를 가질까*? *로또 숫자는 여럿이 같이 존재해야 의미를 가지지 않을까*? *세상에는 숫자 하나만 가지고 하는 로또는 없지 않은가*? 그렇다면 *LottoNumber를 래핑하는 것은 의미가 있나? 적어도 LottoTicket 단위여야 의미를 갖지 않을까*?" — *원시값 포장의 *경계 가치* 의심.
+
+### 6. `set` 네이밍 — *기능 늘면 모호*
+
+리뷰어: "*set으로 네이밍 지어주시는 것도 좋긴 하지만, 추후 LottoTicket에 대한 기능이 늘어날 경우 네이밍으로 인하여 어떤 기능을 담당하는지 헷갈릴 수도* 있겠다는 생각이 들긴 합니다!" — *Kotlin setter* 컨벤션 충돌.
+
+### 7. `toIntList()` *반환 의도 불명*
+
+```kotlin
+fun toIntList(): List<Int>
+```
+
+리뷰어: "*toIntList()로 네이밍 지어 주시는 것도 좋긴 하지만, 자칫 잘못 해석할 여지*가 있어서 네이밍 고민해 보시는 것도 좋을 것 같다는 생각이 듭니다!! *toIntList()라는 메서드 명만 보면 어떤 것을 반환해 주는 거지*?? 라는 생각이 들 수도 있겠다는 생각이 들기도 합니다🤔" — *어떤 도메인 의미*인지 이름에서 사라짐.
+
+### 8. *테스트 네이밍 명세성* — 자동차 경주 예시
+
+```kotlin
+@Test
+fun `자동차가 1칸 이동하면 거리는 1이다`() {
+    val myCar = Car("Duru")
+    myCar.move(1)
+    assertThat(myCar.distance).isEqualTo(1)
+}
+```
+
+리뷰어: "*테스트 코드 깔끔하게 잘 작성*해 주셨네요!! 너무 잘해 주셨지만 참고할 만한 내용이 있어서 코멘트 남겼습니다~ *테스트 코드의 경우 어떤 테스트인지 확실하게 알 수 있게 네이밍을 정해 주는 것도 좋은 것* 같습니다!" 학생: "확실히 *테스트 코드의 네이밍에 많이 소홀*했던 것 같습니다. *머릿속에 떠오르지 않으면 적당히 짓고 넘겨 버리는 경향*이 있는데, *안 좋은 버릇인 것* 같습니다."
+
+### 9. *주석으로 남긴 죽은 코드*
+
+리뷰어: "*해당 내용은 주석으로 남겨 두신 이유*가 궁금합니다!🤔" 학생: "*구매한 로또의 등수 통계 기능을 테스트 가능하게 만들다 남은 흔적*입니다.. *커밋하기 전에 지워야 했는데 꼼꼼하지 못했*습니다."
+
+### 10. `CsvSource` *하드코딩 대체*
+
+리뷰어: "위에서 사용되는 *하드 코딩 되어 있는 내용들에 대해서는 @CsvSource 및 테스트 코드의 여러 기능들을 통해서 제공*해 보는 방법도 고민해 볼 만할 것 같습니다!!"
+
+### 11. *Set과 List 통합* — 같은 도메인, 다른 컬렉션
+
+리뷰어: "*해당 내용에 대해서도 set과 list를 따로 구분하지 않고 통합할 수 있는 방법은 있을지 고민*해 보는 것도 좋을 것 같습니다💪" — 두 타입 사이 변환이 *호출 코드에 흩어짐*.
+
+### 12. `ktlint`, EOF, 코드 정렬
+
+리뷰어: "*gradlew clean ktlintCheck*", "*File > Preferences > Editor > General > Ensure every saved file ends with a line break*", "*맥 사용 시에는 control + cmd + L로 코드 정렬*". 학생: "lint.. 노력하겠습니다 😭".
+
+## 리뷰어 의견 요지
+
+- ***View 인스턴스 위치*** = 미래 변경(키오스크 등) 대응 기준.
+- **`InputView` *class vs object*** — 단순하면 object, 변경 가능성 있으면 class.
+- **인터페이스 *동사 네이밍*** — `MakeMethod`보다 `Generator`.
+- **`value class` vs `data class` *근거 자가 정리*** 권장.
+- ***LottoNumber 단독 의미*** — 도메인 의미 경계 검토.
+- **`set`, `toIntList` *모호 네이밍 회피***.
+- **테스트 네이밍 = *어떤 상황 → 어떤 동작 → 어떤 결과***.
+- **주석 코드 = *커밋 전 삭제***.
+- **`CsvSource` *하드코딩 대체***.
+- **`Set`/`List` *변환 책임 일원화***.
+- **ktlint + EOF + 정렬**.
+
+- **대표 인용:**
+  > 콘솔 어플리케이션이 아닌 *키오스크로 로또를 뽑고 싶다고 해 봤을 때, 대처가 가능할까요? 아마 안될 것 같습니다*.
+  > — @aprilgom on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > 우리는 함수를 분리하는 것이지 분해하는 것이 아닙니다 (PR #131과 비교) — 여기 강사는 *적극 칭찬 + 메타 질문*으로 학생 사유 유도.
+
+  > LottoNumber가 LottoTicket에서 떨어져 있을 때, *그것이 로또 번호로서의 의미를 가질까*?
+  > — @aprilgom on `src/main/kotlin/lotto/domain/LottoNumber.kt`
+
+  > value class는 *하나의 값을 래핑해서 타입을 만들어 주고 싶지만 인스턴스를 만들어서 힙에 올려 두고 싶지 않을 때, 이것을 클래스의 사용처에 inline화*시키는.. 최적화를 위한 그런 키워드.
+  > — @aprilgom on `src/main/kotlin/lotto/domain/LottoNumber.kt`
+
+## 얻은 교훈
+
+- **View 인스턴스 = *현실 변경 시나리오*가 판단 기준** — *키오스크/콘솔 둘 다 지원*이 *interface 주입*의 정당화. *눈 앞의 명세만 구현*은 학생 자가 진단의 *반성 어휘*.
+- **인터페이스 *동사 네이밍*** — `Method`는 *OOP 메서드 의미*와 충돌. `Generator`, `Strategy`, `Factory`처럼 *행위 주체* 어휘.
+- **`value class` 정당화 = *inline 최적화 + 타입 안전 + 힙 회피*** — *data class는 힙*이라 *작은 래퍼*에 부적합.
+- **`LottoNumber` 단독 의미 의심** — *6개가 모여야 로또*라는 *도메인 의미*. *단독 객체*가 *진짜 도메인 객체*인지 의심해도 좋음.
+- **테스트 네이밍 = *상황 → 동작 → 결과***. `자동차가 1칸 이동하면 거리는 1이다`처럼 *명세 한 줄*.
+- **주석 코드 *커밋 금지*** — *학습 흔적*은 *별도 브랜치*에. PR은 *최종 상태*만.
+- **`CsvSource` *데이터-driven 테스트*** — *하드코딩 다수 케이스*는 *시그널 약함*.
+- **`Set`/`List` *변환 책임 일원화*** — 두 타입을 *호출 코드*에서 변환하면 *Liskov 위반*.
+- **ktlint *자동화*** — *코드 스타일 검토*는 *기계 작업*. 리뷰는 *설계*에 집중.
+- **이 PR의 *교육적 가치* = 학생의 답변** — *키오스크 시나리오*, *value class inline 메커니즘*, *LottoNumber 단독 의미 자가 의문*. *리뷰어 칭찬 + 메타 질문 + 학생 깊은 답변*의 3박자.
+- **`InputView class vs object`** — *변경 가능성*이 *class 선택* 정당화. 정적 *object*는 *Mock 불가*.
+- **`makeXxx` vs `setXxx` *Kotlin getter/setter 충돌*** — `set` prefix는 *Kotlin property setter* 컨벤션과 부딪힘.

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

@@ -0,0 +1,26 @@
+# PR #11 — [우기] 1단계 로또
+
+- **Reviewee:** [@boogi-woogi](https://github.com/boogi-woogi)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/11
+- **단계:** 1단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 9
+
+## 학생 자가 의문
+
+> 사실 이 함수가 이 클래스 내부에서 사용되는 것은 아니지만 LottoResult와 관련되어 있다고 생각하여 해당 클래스의 companion object로 선언하였습니다.
+
+> 이렇게 enum 클래스 내부에 있는 숫자들도 상수로 분리하는 것이 좋을까요?
+
+## 핵심 지적
+
+```kotlin
+private fun PurchaseMoney.validateMoneyUnit() = require(this.money % LOTTO_PRICE == 0)
+```
+
+→ 확장 함수 활용.
+
+## 얻은 교훈
+
+- **함수 위치 = 호출처 + 책임 일관성**.
+- **enum의 데이터 숫자도 *enum 자체의 영역*** — 외부 상수 분리는 *재사용 범위*에 따라.

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

@@ -0,0 +1,26 @@
+# PR #29 — [우기] 2단계 로또
+
+- **Reviewee:** [@boogi-woogi](https://github.com/boogi-woogi)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/29
+- **단계:** 2단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 13
+
+## 학생 자가 의문 + 리뷰어 답변
+
+학생:
+
+> Controller의 인자의 개수를 줄이기 위해서 여러 방법을 생각해보다가 한가지 궁금한 점이 생겼습니다! 여기서 의존성을 주입해줄때 이것을 그냥 클래스 내부에서 생성해주는 것과.
+
+리뷰어:
+
+> 가능하면 생성자로 주입받는 것을 권장합니다. 멤버 변수는 클래스 내부에 정의한 함수에서 쉽게 데이터를 접근할 수 있다는 장점을 갖지만, 멤버 변수의 값에 따라 함수의 호출 결과의.
+
+### Lotto가 WinningLotto 너무 잘 앎
+
+> Lotto 클래스가 WinningLotto 클래스를 너무 잘 알고 있어요. Lotto 클래스에서 메시지를 보내도록 코드를 개선해보면 어떨까요?
+
+## 얻은 교훈
+
+- **DI = 생성자 주입 표준**. 멤버 변수 직접 생성 회피.
+- **하위 객체가 상위를 알면 결합도 ↑**. Lotto → WinningLotto 의존은 *역방향*.

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

@@ -0,0 +1,52 @@
+# PR #26 — [빅스] 1단계 로또
+
+- **Reviewee:** [@briandr97](https://github.com/briandr97)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/26
+- **단계:** 1단계
+- **리뷰어:** @woowahan-leah
+- **라인 코멘트:** 42
+
+## 못한 점 + 핵심 지적
+
+### 1. `Bank` object god-helper
+
+```kotlin
+object Bank {
+    fun calculate(.): Int =.
+    fun statistics(.): Map<Rank, Int> =.
+}
+```
+
+> Bank object가 하는 역할이 WinStatistics나 WinningResult에 없는 이유가 뭘까요? 애초에 저희가 일급 컬렉션을 만들거나 원시값을 포장하는 이유가 뭘까요?
+
+→ Bank가 외부 비교/통계 책임 = god-object. WinStatistics 같은 도메인 객체로 위임.
+
+### 2. enum 추가 시 코드 수정 필요
+
+```kotlin
+when (rank) {
+    Rank.FIRST ->.
+    Rank.SECOND ->.
+    // Rank 추가 시 매번 추가
+}
+```
+
+> Rank값이 추가될때마다 매번 이 코드를 수정해줘야 할까요? 힌트: enum 클래스에서 제공하는 함수를 이용해보세요.
+
+→ `Rank.entries.forEach {. }`로 자동 순회.
+
+### 3. `Judgement` object도 god-helper
+
+```kotlin
+object Judgement {
+    fun rank(lotto: Lotto, winning: WinningLotto): Rank =.
+}
+```
+
+> Judgement object가 하는 역할이 WinningNumbers, 혹은 WinningResult나 ComparingResult에 없는 이유가 뭘까요? 객체에 메시지를 전달하는 것이 아니라 값을 직접 꺼내어(get) 조작한다면 애초에 저희가 일급 컬렉션을 만들거나 원시값을 포장하는 이유가.
+
+## 얻은 교훈
+
+- **god-object 패턴의 다른 이름들** — `Bank`, `Judgement`, `Analyzer`, `Calculator`, `Manager` 모두 외부에서 데이터 꺼내 처리. 도메인 객체 메시지로.
+- **enum 자동 순회 = OCP** — `entries.forEach`로 enum 추가 시 코드 무수정.
+- **원시값 포장의 *목적***은 *행위 부여*. 데이터만 wrapping 후 외부에서 꺼내 처리 = 포장의 의미 잃음.

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

@@ -0,0 +1,123 @@
+# PR #51 — [빅스] 2단계 로또
+
+- **Reviewee:** [@briandr97](https://github.com/briandr97)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/51
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @woowahan-leah
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`InputResponseView`로 입력 요청 + 입력 수용 통합** — 도메인별 분리 시도.
+- **`assertThrows` + `kotest`의 `shouldHaveMessage`** — 테스트 가독성↑.
+- **`MethodSource` ParameterizedTest** — 테스트 케이스 외부화.
+- **자가 의문 PR에 풍부히 명시** — *checkError 위치*, *Purchaser의 지저분함* 인지.
+- **리뷰어 제안 사후 `LottoCount`로 책임 분리 시도**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Purchaser` — 3단계 외부 초기화
+
+```kotlin
+val purchaser = checkError { Purchaser(getMoney()) }
+checkError { purchaser.decideManualLottoCount(getManualLottoCount()) }
+checkError { purchaser.purchaseManualLottoBundle(getManualLottoBundle(purchaser.manualLottoCount)) }
+```
+
+리뷰어: "Purchaser의 상태가 세 번에 나뉘어 초기화되고 있습니다. 1. 여러 번 나뉘어져 초기화될 필요가 있을까? 2. 외부의 조작 없이 *스스로 일할 수 있도록* 만들어 보면 어떨까? 3. 꼭 Purchaser가 이 모든 일을 해야 할까?" — *생성 시점 = 완성 시점*이 객체의 원칙.
+
+### 2. `checkError {. }`로 모든 호출 감싸기
+
+리뷰어: "에러가 발생할 가능성이 있는 모든 구문을 감싸도록 구현하시는 과정에서 이러한 코드가 나온 것 같아요. 현재 구현에서는 *에러가 발생할 가능성*이 있는 영역을 하나의 분기점이라고 여겼다면, Input에서 받는 입력을 분기점이라고 가정하여 블록을 나누는 방법도 있을 것 같네요." 후속: "매번 생성할 때 체크하는 것이 아니라요. *Input 단위로 끊기*도 옵션." → 학생: "에러 발생에 따른 다음 동작이 다를 때 이런 부분을 적용하면 좋다는 말씀이신가요?" 리뷰어: "맞습니다."
+
+### 3. `WinStatistics`에 `LOTTO_PRICE = 1000` 중복
+
+```kotlin
+class WinStatistics(.) {
+    companion object { private const val LOTTO_PRICE = 1000 }
+}
+class Purchaser(spentMoney: Money) {
+    val purchasedLottoCount: Int = (spentMoney / LOTTO_PRICE).toInt()
+}
+```
+
+리뷰어: "요구사항이 바뀌어 로또 한 장이 2000원으로 올랐다면 이곳과 Purchaser 모두 수정되어야 할까요?" 학생: "LOTTO_PRICE를 util의 common으로 빼 전역으로 사용하도록 수정. 이제 한 군데에서 수정하면 모든 곳에 적용." — *상수의 *한 곳* 소유*.
+
+### 4. `catch (e: Exception)` 수준의 `checkError`
+
+리뷰어: "`catch (e: Exception)`이 지양되는 이유는 뭘까요? 이러한 코드는 프로그램이 커질수록 예상치 못한 버그를 발견하기 어렵게 만들 수 있어요. 모든 에러를 catch문이 먹어서 프로그래머가 인지하지 못하는 일이 생길 수 있습니다." — *모든 예외 흡수*는 *디버깅 지옥*. CustomError 또는 sealed 분기.
+
+### 5. `LottoCount`가 수동/자동 모두 알아야
+
+```kotlin
+class LottoCount(spentMoney: Money, val manualCount: Int) {
+    val totalCount = (spentMoney / Money(LOTTO_PRICE)).toInt()
+    val autoCount = totalCount - manualCount
+    init {
+        require(totalCount > 0)
+        require(manualCount >= 0)
+        require(manualCount <= totalCount)
+    }
+}
+```
+
+리뷰어: "한 발자국 더 나아가 보자면. 로또를 구매하는 곳에서 수동 로또인지, 자동 로또인지 알 필요가 있을까요? Purchaser에게 로또를 구매하는 책임만 갖게 하고 구체적으로 어떤 방법으로 구매하는지는 *다른 클래스에서 알아서* 하도록 해도 괜찮았을 것 같네요. 이 과정에서 *상속이나 인터페이스의 구현*이 사용될 수 있겠지만 구체적인 방법은 직접 고민." — 결국 *Strategy / Generator 인터페이스* 권장.
+
+### 6. 테스트 픽스처 의미 모호
+
+```kotlin
+private val otherLottoBundle = LottoBundle(listOf(
+    Lotto(1, 2, 3, 4, 5, 6),
+    Lotto(2, 3, 4, 5, 6, 7),
+))
+// 사용처
+purchaser.purchaseManualLottoBundle(otherLottoBundle)
+```
+
+리뷰어: "이러한 값을 테스트를 위한 Fixture라고 합니다. 이러한 픽스처는 어떻게 사용하는 것이 직관적일까요? 다음 구문을 보고 다른 개발자가 한눈에 otherLottoBundle 값을 예상할 수 있을까요?" 학생: "변수명을 `manualLottoBundle`로, 전역으로 따로 빼지 않고 각 함수 내부에서 사용." — 픽스처의 *전역 vs 함수 내 선언* 트레이드오프.
+
+### 7. 주석 처리된 코드 잔존
+
+```kotlin
+fun inputMoney(): Long? {
+    return readLine()?.toLongOrNull() // ?: throw IllegalArgumentException("$PREFIX.")
+}
+```
+
+리뷰어: "이 주석은 꼭 필요한 주석일까요? 간단한 주석을 남길 때에도 주석이 꼭 필요한 상황인지 고려하시는 게 좋습니다. … 클린 코드 책에서 설명하는 주석에 대한 장을 읽어보시면 좋을 것 같아요!"
+
+### 8. PR에 이전 페어 커밋 잔존
+
+리뷰어: "이전 페어의 커밋 기록이 보이는 이유가 뭘까요~? 테코톡 시간에도 다뤄진 주제인 *rebase*를 한번 활용해 보세요." — Git history 관리도 협업 책임.
+
+## 리뷰어 의견 요지
+
+- **생성 = 완성** — 객체가 3단계로 초기화되면 *지저분함 신호*.
+- **`catch (e: Exception)` 수준 흡수 회피** — *예외 종류*별 구체적 핸들링.
+- **재시도 단위 = *Input 단위*** — *생성 호출마다* 감싸기보다 *입력 분기*에서 한 번에.
+- **상수의 *한 곳* 소유** — 중복 선언은 *변경 영향* 흩어짐.
+- **Strategy/Generator 분리** = 수동/자동의 자연스러운 답.
+- **픽스처 *의미 명시*** — 변수명 또는 *함수 내 선언*으로.
+- **주석은 *왜*에만**, *코드 폐기*는 삭제.
+- **PR history도 협업 책임** — rebase로 정리.
+
+- **대표 인용:**
+  > Purchaser의 상태가 세 번에 나뉘어 초기화되고 있습니다. 1. 여러 번 나뉘어져 초기화될 필요가 있을까? 2. 외부의 조작 없이 스스로 일할 수 있도록 만들어 보면 어떨까? 3. 꼭 Purchaser가 이 모든 일을 해야 할까?
+  > — @woowahan-leah on `src/main/kotlin/domain/Purchaser.kt`
+
+  > `catch (e: Exception)`이 지양되는 이유는 뭘까요? 이러한 코드는 프로그램이 커질수록 예상치 못한 버그를 발견하기 어렵게 만들 수 있어요.
+  > — @woowahan-leah on `src/main/kotlin/LottoController.kt`
+
+  > 로또를 구매하는 곳에서 수동 로또인지, 자동 로또인지 알 필요가 있을까요?
+  > — @woowahan-leah on `src/main/kotlin/domain/Purchaser.kt`
+
+## 얻은 교훈
+
+- **객체는 *생성 시점에 완성***. 외부에서 단계별로 `decide*`/`purchase*`를 호출하는 구조는 *지저분함*. *생성자에 모든 정보* 또는 *별도 객체로 분해*.
+- **재시도 단위는 *Input 분기***. 매 호출을 `checkError`로 감싸면 *catch (Exception)* 수준. *입력 받기-검증-처리* 한 블록을 *Input 단위*로.
+- **예외 종류 구체화** — `CustomError extends IllegalArgumentException` 같이 *분류*로 만들면 호출자가 *어떻게 반응*을 명시.
+- **상수의 *한 곳* 소유** — 가격/사이즈 같은 도메인 상수는 *한 객체*가 관리, 다른 곳은 *import*.
+- **수동/자동 = Strategy 분리** — 한 객체에 두 책임을 모두 부여하면 *생성자/메서드 파라미터*가 커지고 *외부에서 어느 길*인지 매번 분기.
+- **테스트 픽스처는 *의미 명시*** — 변수명에 *상황*을 담거나, *전역 픽스처*보다 *함수 내 선언*으로 자명하게.
+- **주석은 *왜*에만**, *폐기 코드*는 git history가 보존하니 *삭제*.
+- **PR history도 협업**. rebase/squash로 *의미 단위 커밋*.