oh-my-oop 0.2.0

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

@@ -0,0 +1,107 @@
+# PR #153 — [이든] 2단계 로또 (최신 PR)
+
+- **Reviewee:** [@devfeijoa](https://github.com/devfeijoa)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/153
+- **단계:** 2단계 (lotto 미션 가장 최신 PR)
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 22 (리뷰어 15 + 학생 7)
+
+## 잘한 점 (설계 관점)
+
+- **인터페이스 활용 시도**.
+
+## 못한 점 (설계 관점)
+
+### 1. `ManualLottoGenerator`의 *count 묵시적 invariant*
+
+```kotlin
+class ManualLottoGenerator(val manualNumbersList: List<List<Int>>) {
+    fun generate(count: Int): List<Lotto> =.  // ⚠ count == manualNumbersList.size?
+}
+```
+
+리뷰어: "*ManualLottoGenerator 객체를 활용하는 개발자는 manualNumbersList의 count와 generate의 count가 같아야 한다는 사실을 알 수 있을까요? LottoGenerator 인터페이스의 역할을 제대로 하는 것일지 고민*해 보세요. 힌트를 조금 더 드리자면, *로또를 발급하는 객체가 랜덤 로또를 생성하는 객체를 활용하는 형태로 구성해 볼 수* 있겠어요." — *묵시적 약속 = 동료 혼란*.
+
+### 2. `Lotto`가 *당첨 티켓 관심*?
+
+리뷰어: "*로또 티켓 자체는 당첨 티켓에 대한 관심을 가져야 할지 고민*해 보세요!" — *책임 경계 검토*.
+
+### 3. *부 생성자 vs 팩토리* — 메타-질문
+
+리뷰어: "*이 부분을 생성자로 만들지 않은 이유가 궁금*하네요" — *팩토리 함수* 정당화.
+
+### 4. *에러 메시지에 입력값 없음*
+
+리뷰어: "*어떤 값이 들어왔는지 에러 메시지에 담아 보는 건* 어떨까요? *어떤 장점이 생길 수 있을까요*?" + "*어떤 입력 값이었는지도 메시지에 남겨보는 건* 어떨까요?".
+
+### 5. *`value class` → `class` 변경 이유*
+
+리뷰어: "*value class에서 class가 된 이유가 궁금*하네요!"
+
+### 6. *`assertAll` 사용 안 함*
+
+리뷰어: "*assertAll로 묶는 것과 그렇지 않은 것은 어떤 차이가 있을까요*?".
+
+### 7. *일급 컬렉션 부재* (Lottos, LottoResults)
+
+리뷰어: "*로또들을 담는 일급 컬렉션을 만들어 보는 건* 어떨까요?" + "*로또 결과들을 담는 일급 컬렉션을 만들어 보는 건* 어떨까요?" + 추가: "*여전히 유효한 피드백*이에요. *이번 미션의 요구사항이기도 한 일급 컬렉션을 만들어 보세요*." — *명세 요구사항*.
+
+### 8. `Lotto` *테스트 누락 요소*
+
+리뷰어: "*Lotto에 테스트 코드가 없는 어떠한 요소들이 있*네요. *잘 찾아서 추가해 보세요* :)"
+
+### 9. *LottoGenerator 인터페이스 구현체 강제 회피*
+
+리뷰어: "이렇게 되면 *수동 티켓을 만들 때마다 LottoFactory 객체와 ManualLottoGenerator 객체를 새로 생성*해야겠어요. *여기에서 자동, 수동 티켓을 만드는 역할을 수행하고, 랜덤의 요소를 국소적으로 분리해 보는 건 어떨까요? LottoGenerator 인터페이스가 반드시 수동 자동 구현체를 만들어야 한다는 것에 매몰되지 않아도 좋겠*어요." — *추상화의 자유*. *수동/자동 = LottoGenerator 구현체*에 강박 X.
+
+### 10. *테스트 불가 클래스* — LottoGenerator 가지는 객체로 테스트
+
+리뷰어: "*이 클래스는 테스트 불가능하니, LottoGenerator를 가지는 machine 객체를 테스트*해 보세요." — *간접 테스트*.
+
+### 11. *테스트 데이터 로직 vs 하드코딩*
+
+리뷰어: "*테스트에 필요한 정보를 로직을 통해 만들어 내지 않고, 직접 하드코딩으로 생성*해 보는 건 어떨까요?".
+
+### 12. *오해 여지 이름 vs 본인 기준*
+
+리뷰어: "*이름에 오해의 여지가 있으면 피하는 게 좋겠지요. 그렇다고 무조건 피하는 것은 좋은 방법일지도 생각*해 보세요 :) *본인만의 기준을 만들어 낼 수 있는 좋은 고민거리*네요!" — *기준과 근거*.
+
+## 리뷰어 의견 요지
+
+- **묵시적 invariant *시그니처로 명시*** (List/count 일치 문제).
+- **`Lotto` *당첨 무관***.
+- **부 생성자 vs 팩토리 *의도 정리***.
+- **에러 메시지에 *입력값***.
+- **`value class → class` *근거 정리***.
+- **`assertAll` *Soft Assertion 의도***.
+- **일급 컬렉션 (Lottos, LottoResults)**.
+- **`LottoGenerator` *수동/자동 구현체 강박 X***.
+- **테스트 불가 클래스 *간접 테스트***.
+- **테스트 데이터 *하드코딩 선호***.
+
+- **대표 인용:**
+  > ManualLottoGenerator 객체를 활용하는 개발자는 *manualNumbersList의 count와 generate의 count가 같아야 한다는 사실을 알 수 있을까요*?
+  > — @malibinYun on `src/main/kotlin/lotto/domain/ManualLottoGenerator.kt`
+
+  > LottoGenerator 인터페이스가 *반드시 수동 자동 구현체를 만들어야 한다는 것에 매몰되지 않아도 좋겠*어요.
+  > — @malibinYun on `src/main/kotlin/lotto/domain/LottoFactory.kt`
+
+  > 이름에 오해의 여지가 있으면 피하는 게 좋겠지요. *그렇다고 무조건 피하는 것은 좋은 방법일지도 생각*해 보세요. *본인만의 기준을 만들어 낼 수 있는 좋은 고민거리*네요!
+  > — @malibinYun 
+
+  > 로또 티켓 자체는 *당첨 티켓에 대한 관심을 가져야 할지* 고민해 보세요!
+  > — @malibinYun on `src/main/kotlin/lotto/domain/Lotto.kt`
+
+## 얻은 교훈
+
+- **묵시적 invariant *시그니처 명시*** — `ManualLottoGenerator(list).generate(count)`에서 *list.size == count*는 *암묵 약속*. *동료가 알 수 없음*.
+- **`Lotto` *당첨 무관*** — 당첨은 *WinningLotto* 책임.
+- **부 생성자 vs 팩토리 *의도 정리*** — *생성자 = 단순 생성*, *팩토리 = 분기/변환*.
+- **에러 메시지에 *입력값*** = *디버깅 비용 절감*. *로그 수집 시대*에 *유일한 데이터 보존*.
+- **`assertAll` *Soft Assertion*** = 한 검증 실패해도 나머지 실행.
+- **일급 컬렉션 *요구사항*** — *역할/책임 부여*가 진짜 가치.
+- **`LottoGenerator` *추상화의 자유*** — *수동/자동 구현체 강박 X*. *랜덤 요소 국소 분리*가 더 자연.
+- **테스트 불가 클래스 = *간접 테스트*** — 협력자 (`Machine`) 테스트.
+- **테스트 데이터 *하드코딩 선호*** — *로직으로 생성*은 *읽기 비용*.
+- **`value class → class` *근거 정리*** — *왜 변경했는지 자가 설명*.
+- **이름 *오해 여지 vs 자기 기준*** — *완전 회피 X*. *왜 그 이름인지 근거*가 더 중요.

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

@@ -0,0 +1,157 @@
+# PR #119 — [디랙] 1단계 로또
+
+- **Reviewee:** [@doabletuple](https://github.com/doabletuple)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/119
+- **단계:** 1단계
+- **리뷰어:** @woowahan-dino (디노)
+- **라인 코멘트:** 29 (리뷰어 15 + 학생 14)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` 원시값 포장**.
+- **`profitRate` Double 반환** — 후속 디스커션.
+
+## 못한 점 (설계 관점)
+
+### 1. 테스트 *함수명과 검증 코드 불일치*
+
+```kotlin
+@Test fun `1~45 사이의 숫자인지 검증`() {
+    assertThrows<.> { LottoNumber(0) }
+    assertThrows<.> { LottoNumber(46) }
+}
+```
+
+리뷰어: "*테스트 항목은 로또 번호가 1~45의 숫자인데 실제 코드는 1~45의 숫자가 아닌, 0과 46의 경계에 대한 테스트*네요! 두 가지로 나눠볼 수 있을 것 같은데, *1~45를 검사하는 테스트 코드와, 그 외에 값인 0과 46일 때 테스트 코드로 만들어볼 수 있을 것* 같아요~"
+
+### 2. *secondary constructor* — Fake Constructor
+
+```kotlin
+Lotto(setOf(1,2,3,4,5,6).map{LottoNumber(it)}.toSet())  // ⚠ 반복
+```
+
+리뷰어: "*Lotto 객체를 만들 때 setOf().map{}.toSet()하는 게 반복*되는데 *secondary constructor를 만들어서 조금 더 간편하게 Lotto 객체를 만들 수* 있게 하면 어떨까요? `Lotto(1, 2, 3, 4, 5, 6)`" — 패턴.
+
+### 3. *`@ParameterizedTest`* 활용
+
+리뷰어: "이런 유형의 테스트는 *@ParameterizedTest를 사용*해서 만들어 볼 수 있을 것 같아요~"
+
+### 4. `readLine()` vs `readlnOrNull()` — IDE 워닝
+
+리뷰어: "아마도 IntelliJ에서 *'Replace readLine with readlnOrNull'와 같은 워닝*을 보실 수 있을 것 같아요. *readlnOrNull()도 결국 내부적으로 readLine()을 호출하고 있어서 같은 효과를 내는 함수임에도 불구하고 IntelliJ가 readlnOrNull()을 사용하게 권장하는 이유가 어떤 건지 한 번 생각*해 보시면 좋을 것 같아요" — *null 안전성*은 *명시적*.
+
+### 5. *View에 `floor` 계산 로직* — 도메인 침투
+
+```kotlin
+// OutputView
+floor(profitRate * 100) / 100
+```
+
+리뷰어: "*floor(profitRate * 100) / 100와 같은 로직이 View에 있는 것보단 Domain에 있는 게 더 적절*해 보이는데 어떻게 생각하시나요?"
+
+### 6. *View에서 profitRate 비교 → enum 변환*
+
+```kotlin
+if (profitRate < 1) "손해."
+else if (profitRate > 1) "이익."
+else "현상유지."
+```
+
+리뷰어: "*View에서 profitRate가 1보다 작은지, 큰지, 같은지와 같은 로직이 있는 것 좋지 않아 보여요*! *View가 아닌 다른 곳에서 profitRate를 가지고 enum으로 변환하고 View에서는 enum에 따라 message만 출력*해 주면 어떨까요?".
+
+### 7. `!in` 연산자 가독성
+
+```kotlin
+!lotto.numbers.contains(bonusNumber)
+```
+
+리뷰어: "*bonusNumber !in lotto.numbers와 같이 사용할 수도 있*습니다~ *'bonusNumber가 lotto.numbers에 있지 않다'와 같이 읽혀서 저는 이렇게 작성하는 것을 선호*하는데 어떠신가요?" — *Kotlin idiom*으로 *자연어 읽기*.
+
+### 8. 상수 *위치* — `Lotto` 안에 *LottoNumber 상수*
+
+리뷰어: "*이것은 Lotto보다 LottoNumber의 상수로 있는 게 좋아 보여요*" — *책임 단위*에 상수 부착.
+
+### 9. `Lottos = Set<Lotto>` — 중복 의미
+
+리뷰어: "*Lottos에 Lotto가 중복으로 존재할 수 있다고 생각하는데 Set으로 하신 이유가 있을까요*?" — *Lottos*는 *List<Lotto>*. *같은 번호 조합 다중 구매* 가능.
+
+### 10. *검증 전 출력* 순서
+
+```kotlin
+fun convertLottos() {
+    showLottoCount(amount / 1000)  // ⚠ 출력 먼저
+    return Lottos.buy(amount)  // 검증
+}
+```
+
+리뷰어: "*price에 대한 검증을 convertLottos() 안에 Lottos.buy() 내부에서 하고 있는데 검증하기 전에 showLottoCount로 로또의 개수를 출력하는 게 조금 어색*하네요. *금액을 받고 바로 Lottos를 만든 다음 이 객체를 사용해서 출력을 하는 것*으로 변경해 보면 어떨까요?" — *검증 → 객체 → 출력* 흐름.
+
+### 11. *Controller가 result 직접 계산* — `Lottos` 활용
+
+리뷰어: "Controller에서 *직접 result를 구하는 것보단 Lottos 클래스에서 함수로 제공*하면 어떨까요?"
+
+### 12. *View가 문구 가공* — 도메인 결과만 받기
+
+리뷰어: "이런 *문구를 만들어서 출력하는 것도 OutputView의 역할*이라고 생각이 되서 실제로 *View.showResult에는 List<LottoResult>만 전달*해도 될 것 같아 보이네요"
+
+### 13. `makeRandomNumbers` — 매번 Range 생성
+
+```kotlin
+fun makeRandomNumbers(): List<LottoNumber> {
+    return (1..45).shuffled().take(6).map { LottoNumber(it) }  // ⚠ 매번 (1..45)
+}
+```
+
+리뷰어: "*LottoNumber를 만들기 위해 makeRandomNumbers를 사용하는데 매번 Range를 만들 필요는 없을 것* 같아요. 결국 List<Int>를 가지고 List<LottoNumber>를 만들게 될 탠데, *1~45의 LottoNumber 객체를 만들고 거기서 shuffle한 다음 take하면 될 것 같*은데 어떻게 생각하시나요? *만약 로또를 10억 치 사면 1,000,000번의 makeRandomNumbers가 호출될 탠데 그때 매번 Range 객체가 생긴다면 성능면에서 좋지는 않을 것* 같아요" — *Flyweight + 상수 컬렉션 재사용*.
+
+### 14. *일급 컬렉션 누락* — `LottoResults`
+
+리뷰어: "추가된 요구사항에 보면 *'일급 컬렉션을 쓴다.'라는 게 있*는데 *List<LottoResult>를 가지는 LottoResults를 만들고 내부에서 getProfitRate()를 만들어서 사용*하면 더 좋을 것 같아요"
+
+### 15. *수익률 표시*
+
+리뷰어: "이거는 *제가 잘못 이해하고 남겼던 것 같*네요 ㅠㅠ profitRate가 이미 수익률을 나타내는 것이었네요! 소수점 2자리까지만 표시를 해야 한다면 저렇게 하기보다 *%.2f 이런식으로 String format을 이용*해 보시는 것도 좋을 것 같아요" — *리뷰어 자기 정정*도 자연.
+
+## 리뷰어 의견 요지
+
+- **테스트 *함수명 = 검증 결과***.
+- **`Lotto(1,2,3,4,5,6)` *fake constructor*** — 테스트 가독성.
+- **`@ParameterizedTest` 활용**.
+- **`readlnOrNull()` *null 안전 명시***.
+- **View의 *계산/분기* → 도메인**.
+- **`!in` *자연어 가독성***.
+- **상수 *책임 단위*에**.
+- **`Lottos` = `List` (중복 허용)**.
+- **검증 → 객체 → 출력** 순서.
+- **Controller가 *result 직접 계산 X***.
+- **View *문구 가공* 책임**.
+- **상수 컬렉션 재사용** (Range 매번 X).
+- **`LottoResults` 일급 컬렉션**.
+- **`%.2f` String format**.
+
+- **대표 인용:**
+  > 테스트 항목은 로또 번호가 1~45의 숫자인데 실제 코드는 *1~45의 숫자가 아닌, 0과 46의 경계에 대한 테스트*네요!
+  > — @woowahan-dino on `src/test/kotlin/lotto/LottoNumberTest.kt`
+
+  > readlnOrNull()도 결국 내부적으로 readLine()을 호출 하고 있어서 같은 효과를 내는 함수임에도 불구하고 *IntelliJ가 readlnOrNull()을 사용하게 권장하는 이유가 어떤 건지 한 번 생각*해 보시면 좋을 것 같아요.
+  > — @woowahan-dino on `src/main/kotlin/lotto/InputView.kt`
+
+  > 만약 로또를 10억 치 사면 1,000,000번의 makeRandomNumbers가 호출될 탠데 그때 매번 *Range 객체가 생긴다면 성능면에서 좋지는 않을 것* 같아요.
+  > — @woowahan-dino on `src/main/kotlin/lotto/Lottos.kt`
+
+  > 이거는 제가 *잘못 이해하고 남겼던 것 같*네요 ㅠㅠ
+  > — @woowahan-dino 
+
+## 얻은 교훈
+
+- **테스트 *함수명과 검증 일치*** — *1~45 검증*이 *경계 외 (0, 46) 테스트*면 *제목/내용 불일치*. *정상 + 경계 외* 두 테스트.
+- **`Lotto(1,2,3,4,5,6)` *fake constructor*** — PR #60, #14, #119 모두 *공통 패턴*.
+- **`readlnOrNull()` = *null 안전 명시*** — `readLine()`도 같은 동작이지만 *암묵 null 가능성*이 *명시적*이지 않음.
+- **`!in` 연산자 = *자연어 가독성*** — `bonusNumber !in lotto`는 *영어 not in*과 일치.
+- **상수 *책임 단위*** — *LottoNumber 범위 (1, 45)*는 *LottoNumber*에. *Lotto*에 두면 *간접 참조*.
+- **`Lottos` = `List`** — *Set*은 *중복 불가*. *같은 번호 다중 구매* 가능하므로 List가 자연.
+- **검증 → 객체 → 출력 순서** — *검증 전 출력*은 *오류 시 잘못된 안내*.
+- **`!in` 연산자 + `in` 연산자** — Kotlin idiom.
+- **상수 컬렉션 재사용** — `(1..45)`를 *매번 생성*하면 *N번 객체 생성*. *Flyweight*나 *companion val*에.
+- **`LottoResults` 일급 컬렉션** — *행위 있으면 자격*. PR #80 (dpcks0509) *역할 없으면 일급 컬렉션 자격 미달*과 같은 결.
+- **`%.2f` String format** — *소수점 자르기 + 표시* 한 번에.

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

@@ -0,0 +1,77 @@
+# PR #138 — [디랙] 2단계 로또
+
+- **Reviewee:** [@doabletuple](https://github.com/doabletuple)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/138
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @woowahan-dino (디노)
+- **라인 코멘트:** 15 (리뷰어 8 + 학생 7)
+
+## 잘한 점 (설계 관점)
+
+- **후속 라운드 적극 반영** — 리뷰어 칭찬: "*제가 생각했던 방식보다 더 좋은 방식이 나왔네요* ㅎㅎ 👍".
+
+## 못한 점 (설계 관점)
+
+### 1. `Set → List` *변경 이유 모호*
+
+리뷰어: "*저는 Set으로 해야 LottoNumber가 중복되지 않아서 init에서 size를 검사하지 않아도 생각*하는데 *List로 변경하신 이유*가 있나요?" + (학생 후속): "*디랙 혹시 Set<LottoNumber>였을 때 같은 LottoNumber가 들어가서 그럴까요*? *List와 Set은 각각 자료구조인지 한 번 찾아 보시는 것도 좋을 것* 같아요!" — *자료구조 invariant* 활용.
+
+### 2. `Result.entries.find` *두 번 사용*
+
+```kotlin
+Result.entries.find { it.matchCount == matchCount && it.bonus } 
+    ?: Result.entries.find { it.matchCount == matchCount } 
+    ?: MISS
+```
+
+리뷰어: "*이 부분을 조금 더 최적화*해 볼 수 있을 것 같아요. *Result.entries.find를 두 번 쓰지 않고 한 번만 사용*해도 될 것 같아요"
+
+### 3. *Map 일괄 생성* — groupingBy
+
+```kotlin
+val result = mutableMapOf<Result, Int>()
+rankList.forEach { rank -> result[rank] = (result[rank] ?: 0) + 1 }
+```
+
+리뷰어: "*코드를 좀 더 나이스하게 바꿔 볼 수 있을 것* 같아요! *Result를 Key로 가지는 Map을 만들고 하나씩 찾아서 넣지 않고, 한 번에 만들어 볼 수는 없을까요? List<Result> => Map<Result, List<Result>> => Map<Result, Int> 형태로 바꿔* 볼 수 있을 것 같아요" — *`groupingBy { it }.eachCount()`* idiom.
+
+### 4. *Result.entries 순서 의존* — sort/reverse vs 선언 순서
+
+리뷰어: "*제가 생각했던 방법도 결국 Result.entries의 순서를 의존하는 방식*이었습니다. *저는 로직에서 어느 정도 순서를 의존해도 된다고* 생각합니다. 예를 들면 *잔돈 계산하는 로직이 있다고 하면 이것은 큰 단위 숫자부터 계산해야 하니 순서에 의존*해야 하지 않을까? 라는 생각입니다. *Result.entries를 sort하고 reverse할 필요 없이 선언 순서를 변경해도 되지 않을까요*? 그리고 *hasBonus >= result.requireBonus 이것도 조금 어색*합니다. *Boolean을 >=로 계산한 어떤 것을 기대할 수 있을까요*?" — *enum 선언 순서가 의도된 비즈니스 순서*면 *활용 정당*.
+
+### 5. *상수 위치* — 위에 선언
+
+리뷰어: "*보통은 상수를 위에 선언하고 함수를 아래에 선언*해요!"
+
+### 6. *입력 중복 vs 부족 분리* — 학생 의도 인정
+
+리뷰어: "*입력이 중복된 경우와, 입력이 부족한 경우를 나누고 싶어서 그러셨군요*! 이해했습니다 ㅎㅎ" — *학생 의도 이해*.
+
+## 리뷰어 의견 요지
+
+- **`Set` *invariant 활용*** — 변경 이유 명시.
+- **`Result.entries.find` *2회 → 1회 최적화***.
+- **`groupingBy { }.eachCount()` *Map 집계 idiom***.
+- **`enum 선언 순서` *비즈니스 의도*** — sort/reverse 불필요.
+- **`Boolean >=` *어색한 비교***.
+- **상수 *위에 선언***.
+
+- **대표 인용:**
+  > 저는 로직에서 *어느 정도 순서를 의존해도 된다고* 생각합니다. 예를 들면 *잔돈 계산하는 로직*이 있다고 하면 이것은 큰 단위 숫자부터 계산해야 하니 순서에 의존해야 하지 않을까? 라는 생각입니다.
+  > — @woowahan-dino on `src/main/kotlin/lotto/domain/Result.kt`
+
+  > Result를 Key로 가지는 Map을 만들고 *하나씩 찾아서 넣지 않고, 한 번에 만들어 볼 수는 없을까요*?
+  > — @woowahan-dino on `src/main/kotlin/lotto/domain/LottoResults.kt`
+
+  > Boolean을 >=로 계산한 *어떤 것을 기대할 수* 있을까요?
+  > — @woowahan-dino on `src/main/kotlin/lotto/domain/Result.kt`
+
+## 얻은 교훈
+
+- **자료구조 선택 *invariant 표현*** — *Set*은 *중복 방지*. *List*는 *순서/중복 허용*.
+- **`Result.entries.find` *1회 사용*** — *찾는 조건을 한 번에 결합*.
+- **`groupingBy { }.eachCount()`** = *Map 집계 표준 idiom*. *MutableMap + forEach*보다 *불변 + 함수형*.
+- **`enum` *선언 순서 = 비즈니스 순서*** — *큰 단위 잔돈 계산*처럼 *순서 의존 정당*. *sort/reverse 불필요*.
+- **`Boolean >=` *어색*** — *비교 연산자*는 *순서 있는 타입*에. *Boolean*은 *and/or*이 자연.
+- **상수 *위치*** — 함수 위에 *Kotlin 컨벤션*.
+- **`>=`로 Boolean 비교 → *Boolean 산술 오용 신호*** — *true=1, false=0* 가정.

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

@@ -0,0 +1,67 @@
+# PR #111 — [로또 1단계] 동전 미션
+
+- **Reviewee:** [@donghyun81](https://github.com/donghyun81)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/111
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 49
+
+## 못한 점 + 핵심 지적
+
+### 1. `Constants.kt` global — 응집도 0
+
+```kotlin
+object Constants {
+    // 모든 상수
+}
+```
+
+> 이 상수들을 글로벌하게 관리하는 이유가 궁금하네요! 어떠한 객체에 응집도 있게 묶어보는 건 어떨까요?
+
+### 2. Controller가 결과 비교 순회
+
+```kotlin
+class LottoController {
+    fun run() {
+        lottos.forEach { lotto ->
+            val rank = compare(lotto, winning)  // ⚠ Controller가 비교
+.
+        }
+    }
+}
+```
+
+> 로또 티켓의 순회를 돌면서 하나하나 결과를 비교하고 있네요. 이 로직은 도메인로직일까요, 컨트롤러의 로직일까요?
+
+→ `winningLotto.matchAll(lottos)` 메시지.
+
+### 3. `WinningNumbers` vs `Lotto` 차이 의문
+
+> 당첨 번호를 구성하는 요소는 무엇이 있을까요? 당첨 번호와 로또를 비교하면 어떠한 결과가 나올텐데, "당첨 번호"와 "비교할 로또", 이 둘의 차이점은 무엇일까요?
+
+→ 둘 다 6개 번호 = 데이터 같음. 차이는 *역할* (winning은 비교 기준).
+
+### 4. `LottoRank.matchBonus` 디폴트값 — 어디는 명시, 어디는 디폴트
+
+```kotlin
+enum class LottoRank(val matchBonus: Boolean = false) {
+    SECOND(matchBonus = true),
+.
+}
+```
+
+> matchBonus란 값을 어디는 명시되어있고 어디는 디폴트네요. 한 곳만 표현해야하는 정보인데 필드로 두는 것은 불필요해보여요. 보너스 볼이 맞아야한다는 것은 로직으로 표현해보는 건 어떨까요?
+
+→ matchBonus는 *판별 입력*이지 *enum의 영구 속성*이 아님.
+
+### 5. `LottoRankCalculator` — 아무 일도 안 함
+
+> 이 객체가 하는 일은 어딘가 아무 일도 하지 않는 객체에 응집도 있게 뭉쳐볼 수 있겠어요!
+
+→ Calculator가 *외부 비교*로만 채워지면 Tell-Don't-Ask 위반. WinningLotto가 자기 비교 책임.
+
+## 얻은 교훈
+
+- **`Constants.kt` global = god-folder 시작점**.
+- **Calculator/Analyzer가 외부 비교 = feature-envy**. 도메인이 자기 비교 책임.
+- **enum의 *판별 입력*과 *영구 속성* 분리** — matchBonus는 전자.

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

@@ -0,0 +1,124 @@
+# PR #152 — [로또 2단계] 동전 미션
+
+- **Reviewee:** [@donghyun81](https://github.com/donghyun81)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/152
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 20
+
+## 잘한 점 (설계 관점)
+
+- **`sealed class LottoResult` 대규모 도입** — Result 타입화 학습.
+- **`LottoMachine` 인터페이스 + `RandomLottoMachine` 구현체**.
+- **`Lottos` 일급 컬렉션** — 수동/자동 분리 보유.
+- **자가 의문 PR에 풍부히 명시** — *sealed 정당화*, *수동/자동 인터페이스 통합 어려움* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. sealed class 대규모 도입 — *과적용* 신호
+
+```kotlin
+sealed class LottoResult {
+    data class Success(val lotto: Lotto) : LottoResult()
+    data object InvalidNumbersNull : LottoResult()
+    data object InvalidNumberNull : LottoResult()
+    data class InvalidNumberRange(val lottoNumber: Int) : LottoResult()
+    data class InvalidNumbersSize(val lottoNumbers: Set<LottoNumber>) : LottoResult()
+}
+```
+
+리뷰어: "sealed로 대부분이 바뀐 것을 보니 생각이 많아지네요. *sealed를 쓰게 된 이유는 무엇인가요?* sealed로 구성되어 있는 부분도 있고, 아닌 부분들도 보여요. *나눈 기준*은 무엇인가요?" 학생: "사용자와 상호작용을 통해 생기는 처리를 *여러 방법으로* 처리하기 위해. 사용자에게 상황에 맞는 안내를 통해 사용자 경험 향상." 리뷰어 답: "사용자와 상호 작용을 통해 생기는 처리를 위해 sealed를 쓴 것은 공감이 잘 되지 않네요. *그런 처리는 View에서 해도 충분*하지 않았나. 처음부터 *null을 받지 못하도록 구성*하는 건 어떨까요? 논리적으로 맞지 않는 *객체 인스턴스를 생성하지 못하도록 막는 것*이 중요하다 생각해요. sealed도 그것을 해결할 수 있는 방법 중 하나이지요. 그런데 sealed로 *해결할 수도 있지만, 지난 단계의 미션을 진행했을 때 구성*했던 것처럼 해도 똑같이 해결이 됩니다." + "이 미션에서 sealed로 해결하고자 했던 것이, *sealed를 활용하지 않았을 때는 해결할 수 없었는지* 돌아보시면 좋겠어요."
+
+### 2. `LottoResult.getSuccessOrThrow()` — sealed인데 throw
+
+```kotlin
+fun getSuccessOrThrow(): Lotto {
+    require(this is Success)
+    return lotto
+}
+```
+
+리뷰어: "sealed로 묶었는데 *throw를 던진다*라.. 굉장히 특이한데요? sealed를 왜 묶었는지를 먼저 알아본 다음, … sealed로 해결할 수 있는 *문제를 정확하게 짚어내지 못했다*는 느낌이 강하게 드네요." 후속: "*논리적인 오류를 막을 때, throw를 하지 않기 위해* 고안할 수 있는 방법 중 하나가 sealed로 구성하는 것이지요. *왜 throw를 하지 않기 위해* 그런 구성이 나왔는지와, 어떻게 sealed는 그것을 해결해 줄 수 있었는지 고민해 보시면 좋겠어요."
+
+### 3. `Lottos`가 setter 패턴
+
+```kotlin
+class Lottos {
+    private val randomLottos: MutableList<Lotto> = mutableListOf()
+    private val manualLottos: MutableList<Lotto> = mutableListOf()
+    fun addRandomLotto(lotto: Lotto) { randomLottos.add(lotto) }
+    fun addManualLotto(lotto: Lotto) { manualLottos.add(lotto) }
+}
+```
+
+리뷰어: "이 객체는 값을 갖고 있는 것 말고는 하는 일이 없네요. 어떤 역할을 부여해 볼 수 있어 보여요. 또, *add를 일일이 불러 주기 보다, 생성할 때 값을 받게끔* 만들어 볼 수 있겠어요."
+
+### 4. `LottoStore` 명명 혼동
+
+```kotlin
+class LottoStore(val lottoRanks: Map<LottoRank, Int>) {. }
+```
+
+리뷰어: "이 객체 이름은 뭔가 *로또를 판매할 것만 같은* 느낌이 드네요!" 학생: "로또들을 통해 돈을 지급하는 객체를 생각해서 Store라고 생각했는데, *판매할 것 같은 느낌이 더* 드네요." — 명명이 *현실 세계의 다른 기능*을 연상시키면 혼동.
+
+### 5. `Lotto.getMatchCount(winningLotto)` — *Lotto가 winningLotto를 안다*
+
+리뷰어: "로또가 맡을 수 있는 역할을 잘 가져다 놓아주셨네요. getMatchCount()의 파라미터인 Lotto는 꼭 *당첨 티켓*일 필요는 없어 보여요. 그저 *로또와 로또를 비교*해서 맞는 개수를 비교해 준다는 의미만을 넣어 보는 건 어떨까요? *로또 자체가 굳이 당첨 티켓에 대한 관심을 가지지 않는 것*이죠." → `Lotto.getSameNumberCount(other: Lotto)`.
+
+### 6. `RandomLottoMachine` vs `ManualLottoMachine` 인터페이스 통합 어려움
+
+학생: "수동 로또 요구사항을 보고 random이랑 manual 머신 구현체를 만들어서 LottoMachine 인터페이스를 통해서 추상화하고 싶어서 여러 방법을 찾아봤지만, *generate의 매개변수가 달라서 오버로딩*을 하거나 *ManualLottoMachine의 생성자에 프로퍼티*를 받는 방법 말고는 찾지를 못했습니다." 리뷰어: "LottoMachine이 1단계에서 랜덤 로또를 생성하는 것만 생각해서 만들어진 *추상체*라 더욱 어려워지는 게 아닐지 고민해 보세요. *랜덤의 요소를 최대한 국소적으로* 만들어 내고, *추상의 단계를 수정*해 보세요." + "꼭 LottoMachine의 하위 구현체로 자동과 수동을 만들 필요는 없다. 저라면 *난수 발생기*만을 랜덤의 요소로 객체 분리했을 거라 생각해요."
+
+### 7. `WinningNumbers`가 `Lottos`의 값을 꺼내 사용
+
+```kotlin
+private fun getPurchaseLottoRanks(purchaseLotto: Lottos): List<LottoRank> = purchaseLotto.lottos.map {. }
+```
+
+리뷰어: "결국 Lottos의 값을 꺼내 쓰고 있으니 *메시지를 던진다는 느낌을 받기는 어려워* 보여요. *Lottos에게 WinningNumbers를 역으로 던져 보는 형태*로 구성해 보셔도 좋겠네요."
+
+### 8. Inferred Type — 멤버/리턴 타입 명시 부재
+
+```kotlin
+fun getSameNumberCount(other: Lotto) = _numbers.count { number -> other._numbers.contains(number) }
+```
+
+리뷰어: "*멤버 변수와 메서드의 리턴 타입*은 모두 명시해 주는 것은 어떨까요? 명시해 주는 것과 그렇지 않은 것은 어떤 차이점이 생길까요? Effective Kotlin 서적의 챕터를 참고해서… Item 4: *Inferred Type으로 리턴하지 말라*. Item 14: *변수 타입이 명확하지 않은 경우 확실하게 지정하라*."
+
+### 9. 1단계 코멘트 미반영
+
+리뷰어: "https://github.com/woowacourse/kotlin-lotto/pull/111#discussion_r1968857015 이 피드백이 반영되지 않은 것은 많이 아쉬운 마음이에요." — 이전 라운드 미반영은 *학습 흐름 단절*.
+
+## 리뷰어 의견 요지
+
+- **sealed의 *진짜 정당화*는 *throw 회피*** — 사용자 상호작용 처리는 View에서.
+- **sealed에 throw 섞기 X** — *sealed의 의미*가 *닫힌 분기*인데 throw는 *열린 실패*.
+- **Lottos에 *행위*** — setter 누적 패턴 회피, 생성자에 값 받기.
+- **명명은 *현실 세계 다른 기능*과 충돌 회피** — Store는 판매를 연상.
+- **Lotto.matchCount의 파라미터는 *임의의 Lotto*** — 당첨/일반 구분 X.
+- **추상체 *단계 수정*** — LottoMachine을 *Auto/Manual*로 나누기보다 *난수 발생기*만 분리.
+- **`Lottos`에 메시지 던지기** — getter로 꺼내 쓰지 말 것.
+- **Inferred Type 회피** — 멤버/리턴 타입 명시.
+- **이전 라운드 코멘트 반영**은 학습 흐름.
+
+- **대표 인용:**
+  > sealed로 묶었는데 throw를 던진다라.. 굉장히 특이한데요? sealed를 왜 묶었는지를 먼저 알아본 다음… *sealed로 해결할 수 있는 문제를 정확하게 짚어내지 못했다*는 느낌이 강하게 드네요.
+  > — @malibinYun on `src/main/kotlin/lotto/domain/service/RandomLottoMachine.kt`
+
+  > LottoMachine이 1단계에서 랜덤 로또를 생성하는 것만 생각해서 만들어진 추상체라 더욱 어려워지는 게 아닐지 고민해 보세요. 저라면 *난수 발생기*만을 랜덤의 요소로 객체 분리.
+  > — @malibinYun on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > Lotto의 파라미터인 Lotto는 꼭 *당첨 티켓*일 필요는 없어 보여요. 그저 로또와 로또를 비교해서 맞는 개수를 비교해 준다는 의미만을.
+  > — @malibinYun on `src/main/kotlin/lotto/domain/model/Lotto.kt`
+
+## 얻은 교훈
+
+- **sealed의 *진짜 정당화* = *throw 회피*** — 사용자 안내 메시지를 *도메인까지 끌어옴*은 책임 위반.
+- **sealed + throw = 의미 충돌** — sealed는 *모든 경우를 닫음*, throw는 *열린 실패*.
+- **Lottos에 행위** — `add` 누적 setter는 *외부 강제*. 생성자에 값 받기.
+- **명명 충돌 회피** — *Store*는 *판매*를 연상. 도메인 의미 명확화.
+- **`Lotto.matchCount(other)`** — 파라미터는 *임의의 Lotto*. *당첨*은 호출자의 맥락.
+- **추상체 *단계 수정*** — Manual/Auto Machine 통합이 어려우면 *추상이 잘못된 단계*일 수 있음. *난수 발생기*만 분리가 더 적합할 때도 있음.
+- **`Lottos`에 메시지 던지기**, getter로 꺼내 쓰지 말 것 — `Tell, Don't Ask`.
+- **Inferred Type 회피** (Effective Kotlin Item 4, 14) — 멤버/리턴 타입 명시는 *미래 변경의 견고성*.
+- **이전 라운드 미반영은 *학습 흐름 단절*** — *왜 미반영*했는지 PR에 명시.