oh-my-oop 0.2.0

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

@@ -0,0 +1,126 @@
+# PR #140 — [비비] 2단계 로또
+
+- **Reviewee:** [@rosemin928](https://github.com/rosemin928)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/140
+- **단계:** 2단계 (수동 로또)
+- **리뷰어:** @Gyuil-Hwnag (규일)
+- **라인 코멘트:** 30 (리뷰어 19 + 학생 11)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoGenerator` 활용** — 칭찬: "*Generator를 통한 생성 정말 좋습니다*ㅎㅎ👍".
+- **`Profit` 테스트 정밀** — 칭찬: "*Profit에 대한 테스트 정말 좋습니다*ㅎㅎ👍 *어떤 것이 주어졌고, 어떤 것을 테스트하며, 결과는 어떤 것인지 한눈에 들어오는군요*~".
+- **`LottoStore` 도입 → 테스트 가능** — 칭찬: "*LottoStore가 생겨남으로써, LottoStore를 통해서 로또 생성에 대한 테스트가 가능*해졌군요~💯".
+- **2단계 README 분리 작성** — 칭찬: "2단계 요구사항에 대한 *README 작성 좋습니다*~👍".
+- **당첨 로직 테스트 작성** — 칭찬: "*당첨 로직에 대한 테스트 코드 작성 정말 좋습니다*~👍".
+
+## 못한 점 (설계 관점)
+
+### 1. *자동/수동 변수명 모호*
+
+```kotlin
+val lottos =.  // ⚠ 자동인가 수동인가
+```
+
+리뷰어: "*자동 로또와 수동 로또를 구분해 주셨군요*~ *자동 로또라는 네이밍이 드러나게 변수명을 지어봐도 좋을 것 같*다는 생각이 듭니다!" — `autoLottos`, `manualLottos`.
+
+### 2. *순서가 바뀜*
+
+리뷰어: "*순서가 바뀐 것* 같아요~"
+
+### 3. `LottoTicketCounter.count(): List<Int>` — 두 값 합치기
+
+```kotlin
+class LottoTicketCounter {
+    fun count(): List<Int> = listOf(manualCount, autoCount)  // ⚠ 두 의미 합침
+}
+```
+
+리뷰어: "*해당값을 리스트로 만들어야 할 이유가 있을까? 라는 생각이 듭니다*! *fun manualCount(), fun autoCount() 이렇게 두 개로 나눠보는 것은 어떨까* 라는 생각이 듭니다~" — *List에 두 다른 의미*가 들어가면 *index access*가 *의미 모호*.
+
+### 4. *`numbers[0], numbers[1]` 위치 의존*
+
+리뷰어: "*numbers[0], numbers[1]라고 받은 부분이 살짝 고민이* 되긴 합니다! *현재의 구조를 모르는 사람이 본다면 해당 구현을 보고 어떤 건지 단번에 파악이 가능할까? 라는 생각*이 듭니다~ *autoCount, manualCount로 확실하게 구분을 지어서 파라미터로 받는 방법도 좋을 것 같다*는 생각이 듭니다💪"
+
+### 5. `LottoTicketCounter` *존재 정당화* — 학생 자가 의문
+
+학생: "*LottoTicketCounter는 로또 개수를 세는 역할, LottoStore는 로또를 발행하는 역할이라고 생각해서 따로 두었는데 이를 합치면 더 좋을까요*.?"
+
+리뷰어: "말씀해 주신 대로, *LottoStore에서 Count 하나로 묶는 방법도 있을 것 같긴 한데, 구조상 그렇게 변경하기가 쉽지 않아 보이긴 하네요*! *LottoTicketCounter라는 객체가 굳이 필요할까? 라는 의문이 듭니다*! *현재 역할은 Auto, Manual 갯수를 계산하는 역할에 지나지 않는다*는 생각이 듭니다🤔"
+
+후속: "*LottoTicketCount가 있어도 괜찮다고 생각을 하신 건 현재 로직을 담고 있기 때문인가 보군요*!👍 아주 좋습니다ㅎㅎ 그렇다면 *담당하는 역할은 아래와 같은데 LottoTicketCounter이라는 네이밍이 비비가 보시기에는 어떠신가요*??🤔 *로또의 구매할 수 있는 최저 금액 & 내가 구매한 로또 갯수 & 내가 구매한 자동 로또의 갯수*" — *책임 = 네이밍*이 *일치*해야.
+
+### 6. *수동 로또 입력 실패 시 전체 재입력?* — UX
+
+학생: *로또 10장 입력 도중 1번째 잘못되면 모두 다시 입력?*
+
+리뷰어: "*오호~ 아주 좋은 고민을 하셨군요*!👍 *로또를 열심히 10장을 적었는데, 사실 1번째 줄이 잘못되었다고 입력한 모든 것을 다시 입력해야 한다*? 억지스럽긴 한데, *회원가입이라고 한다면 힘들게 10단계를 넘었는데 사실 1단계에서 틀렸으니 다시 힘들게 10단계를 입력해야 한다?* *실제 사용자 입장에서는 무척 화가 나는 상황이겠군요*" — *현실 UX 시나리오*로 *입력 단위 검증*의 가치.
+
+### 7. *LottoStore 제거 이유*
+
+리뷰어: "*LottoStore를 제거하게 된 이유가 궁급*합니다!🤔" — *책임 객체 폐기*의 정당화 필요.
+
+### 8. 수동 로또 *발행 테스트 부재*
+
+리뷰어: "수동 로또라는 것이 생겼으니, *수동 로또도 제대로 발행을 하는지 한번 테스트해 봐도 좋을 것* 같다는 생각이 듭니다!💪"
+
+### 9. *45 이상 입력 → 앱 죽음*
+
+리뷰어: "*45 이상의 숫자를 입력하면 앱이 죽도록 되어 있군요*~ 이 부분은 *요구사항에 없긴 한데, 한 번 고민해 보면 좋을 것 같*은 내용인 것 같아서 코멘트 남겨 두었습니다! *재입력을 받도록 해 볼 수도 있겠다는 생각도 드는군요*!💪 (수정이 이루어져야 하는 것은 아니고 *어떻게 하면 해당 기능을 구현할 수 있을지 비비의 의견을 남겨* 주셔도 좋을 것 같습니다)"
+
+### 10. 테스트 *공통 부분 상수화*
+
+리뷰어: "*테스트 코드 작성 너무 잘해 주셨네요*~👍 *공통으로 테스트에서 이용할 수 있는 부분들에 대해서는 상수화를 해서 관리한다면, 테스트 코드에서 재사용을 하면서 중복된 부분들을 줄여볼 수* 있겠군요!"
+
+### 11. 테스트 *컨벤션 일관성*
+
+리뷰어: "*테스트 코드 컨벤션이 이러한 방식으로 정해졌다면 일관성 있게 다른 테스트에도 반영을 해 보는 것이 추후 다른 사람이 보더라도 일관되게 보여 한눈에 잘 들어올 수 있겠다*는 생각이 듭니다!" — *Profit 테스트 컨벤션*을 *다른 테스트에 일관 적용*.
+
+### 12. *수동 로또 갯수 테스트 다양한 케이스*
+
+리뷰어: "*수동 로또를 생성하는 것을 테스트하므로, 여러 가지 실패 등 케이스를 테스트해 봐도 좋겠다*는 생각이 듭니다💪 https://developer.android.com/studio/test/test-in-android-studio#view_test_coverage *테스트 커버리지*라는 개념.". 자료.
+
+### 13. *LottoStore 내 로직 vs Profit 분리* — 메타-질문
+
+리뷰어: "*해당 로직이 LottoStore 내에 있도록 한다면, 어떤 장점과 단점이 있게 될까요? 수정이 필요한 것은 아니고 비비의 의견을 알려* 주세요~💪"
+
+## 리뷰어 의견 요지
+
+- **자동/수동 *변수명 명시***.
+- **`List<Int>`에 *두 다른 의미* X**.
+- **`numbers[0], numbers[1]` *index access*는 *모호***.
+- **`LottoTicketCounter` *역할 + 네이밍 일치* 또는 통합**.
+- ***입력 단위 검증* vs 전체 재입력 UX**.
+- **`LottoStore` 제거 *정당화*** 필요.
+- **수동 로또 *발행 테스트***.
+- **45 이상 *앱 죽음* — 재입력 가능성**.
+- **테스트 *공통 상수* + *컨벤션 일관성***.
+- **`Store 내 로직` *책임 분리* 의견**.
+
+- **대표 인용:**
+  > 로또를 열심히 10장을 적었는데, 사실 1번째 줄이 잘못되었다고 *입력한 모든 것을 다시 입력해야 한다*? 억지스럽긴 한데, 회원가입이라고 한다면 *힘들게 10단계를 넘었는데 사실 1단계에서 틀렸으니 다시 힘들게 10단계를 입력해야 한다*?
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > LottoTicketCounter라는 *객체가 굳이 필요할까? 라는 의문*이 듭니다!
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/LottoTicketCounter.kt`
+
+  > 해당값을 *리스트로 만들어야 할 이유*가 있을까? fun manualCount(), fun autoCount() 이렇게 *두 개로 나눠 보는 것*은 어떨까.
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/LottoTicketCounter.kt`
+
+  > 45 이상의 숫자를 입력하면 *앱이 죽도록 되어 있군요*~
+  > — @Gyuil-Hwnag on `src/main/kotlin/lotto/domain/LottoNumber.kt`
+
+## 얻은 교훈
+
+- **자동/수동 *변수명 = 명시 어휘*** — `autoLottos`, `manualLottos`. *컨텍스트 의존*은 *모호*.
+- **`List<Int>`에 *두 다른 의미*가 들어가면 *index access*가 *의미 모호*** — `fun manualCount()`, `fun autoCount()` 분리.
+- **`numbers[0], numbers[1]` *위치 의존*** — 새 멤버는 *의미 자동 파악 불가*. *명시 파라미터*가 안전.
+- **`LottoTicketCounter` *역할 + 네이밍 일치*** — *Auto/Manual 개수 + 최저 금액 + 자동 갯수*가 *책임이라면*, *Counter*는 *책임 일부만* 반영. *네이밍 재검토 또는 통합*.
+- ***입력 단위 검증 = UX*** — *10장 중 1번째 오류 시 전체 재입력*은 *최악 UX*. *회원가입 10단계* 비유 강력. *각 줄 단위 재입력*이 자연.
+- **`LottoStore` 제거 *정당화 필요*** — *책임 객체 폐기*는 *왜 폐기인지* 설명. *역할이 흩어졌는지 통합되었는지*.
+- **수동 발행 테스트** = *새 기능에 새 테스트*. *기존 테스트만으로 부족*.
+- **45 이상 *앱 죽음* = 요구사항 외 UX 고려** — *재입력*이 *현실*.
+- **테스트 *공통 상수***. *fixture object*와 같은 *중복 제거 + 의미 명시*.
+- **테스트 *컨벤션 일관성*** — 한 테스트가 *given/when/result* 양호하면, *다른 테스트도 동일 형식*. PR #61 (Junyoung-WON) Rank 부분 테스트와 같은 결.
+- **`LottoStore 내 로직`** — *책임 응집 vs 분리* 트레이드오프. *현실 도메인 (가게)*가 *얼마나 많은 일*을 하는가.
+- **회원가입 *10단계 1단계 오류 비유*** — *UX 시나리오*는 *코드 결정*의 강력한 근거.

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

@@ -0,0 +1,119 @@
+# PR #103 — [로또] 빙티 2단계 미션
+
+- **Reviewee:** [@s6m1n](https://github.com/s6m1n)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/103
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 23
+
+## 잘한 점 (설계 관점)
+
+- **`LottoTickets` 일급 컬렉션** — `concat` 행위.
+- **`Money.calculateQuantity(LOTTO_PRICE)`** — 도메인 객체에 책임 위임.
+- **`Cashier` 객체 제거 + Money로 책임 통합** — 1단계 리뷰 반영.
+- **자가 의문 PR에 풍부히 명시** — *수동 Generator의 존재 의미*, *Generator 추상화 수준 통일* 등.
+
+## 못한 점 (설계 관점)
+
+### 1. 수동 발행 위치 — 학생 자가 의문
+
+학생 분석: "자동의 경우 LottoGenerator를 상속하는 RandomLottoGenerator에서 만들어지고 있습니다. 그러나 수동의 경우 별도의 Generator를 거치지 않고 컨트롤러에서 사용자로부터 값을 입력받아 바로 Lotto 객체로 만들어 줍니다. *같은 지위를 가지는 객체들인 만큼 생성 과정에 있어서 추상화 수준을 동일시*해야 하지 않을까?라는 의문." 학생 시도 후 결론: "수동 로또 generator을 추가하는 시도 끝에 [수정 전 구조]가 더 낫다는 결론." 리뷰어: "단순히 협력하는 구조가 되는 방식이 아쉬웠다면, 확장성을 위해 한 번 더 협력을 하도록 만들 수도 있습니다. *참고만*: `ManualLottoMachine { InputView.getLottoNumbers().toLottoNumbers() }`."
+
+### 2. `getTotalLottoTicket`이 *조회 + 출력*
+
+```kotlin
+private fun getTotalLottoTicket(manualLottoTickets, autoLottoTickets): LottoTickets {
+    OutputView.printLottoQuantity(.)
+    val totalLottoTickets = manualLottoTickets.concat(autoLottoTickets)
+    OutputView.printLottoNumbers(totalLottoTickets.tickets)
+    return totalLottoTickets
+}
+```
+
+리뷰어: "TotalLottoTicket을 가져온다는 행위가, *출력을 같이 하고 있다면* 두 가지 역할을 하고 있다고 볼 수 있지 않을까요? 가령 정말로 로또 티켓을 가져오려고 호출했는데, *그때마다 콘솔에 찍히게 됩니다*." — `get*` 메서드는 *순수 반환*만.
+
+### 3. 상수 중복 — `LottoController`와 `LottoNumber`
+
+```kotlin
+companion object {
+    const val LOTTO_PRICE = 1000
+    const val MINIMUM_LOTTO_NUMBER = 1  // ⚠ LottoNumber도 보유
+    const val MAXIMUM_LOTTO_NUMBER = 45
+}
+```
+
+리뷰어: "LottoNumber와 이곳 중복으로 상수를 사용한다면, *두 개 모두 바꾸어야 한다는 사실*을 개발자가 놓치기 쉽지 않을까요?"
+
+### 4. 수익률 책임 위치 — `Money.calculateRate` vs `LottoDrawingResult`
+
+```kotlin
+val marginRate = purchaseMoney.calculateRate(result.calculateTotalPrize())
+```
+
+리뷰어: "수익률이라는 것은 Money가 만들어 내는 것과 LottoDrawingResult가 만들어 내는 것 무엇이 더 적절하다고 생각하시나요? 만약 로또 게임에서 만들어야 하는 결과에 *다른 값*이 생긴다면 어떻게 될까요?" 학생: "수익률이 Money를 기반으로 계산되어서 calculateRate를 Money 클래스 내부에 두었는데, *다른 값이라는 확장*을 염두에 두면 *새로운 값과 수익률 모두 LottoDrawingResult에서 관리*하는 것이 통일성 있다고 생각합니다."
+
+### 5. `LottoDrawingResult.resultStatistics` 직접 노출
+
+```kotlin
+val resultStatistics: Map<Rank, Int> =.
+```
+
+리뷰어: "`resultStatistics`가 그대로 외부로 노출되어 있다면, 값에 해당하는 Int 타입이 무엇을 의미하는 것인지 알 수 있을까요? 갯수일 수도 있고, 가격의 총 합일지도 모릅니다. 이러한 경우 명확하게 메시지를 만들어 의도를 전달할 수 있습니다. `fun getWinningCountByRank(rank: Rank): Int {. }`." 학생: "예시로 들어 주신 getWinningCountByRank에서 힌트를 얻어 코드를 수정해 봤습니다! resultStatistics도 삭제되고, getWinningCountByRank라는 네이밍 덕분에 count라는 걸 개발자가 직관적으로 알 수 있겠네요."
+
+### 6. `coerceAtMost`/`coerceIn` 학습 시드
+
+```kotlin
+fun readPurchaseQuantity(maxQuantity: Int): Int {
+    val input = readln().toInt()
+    return if (input !in 0..maxQuantity) maxQuantity else input
+}
+```
+
+리뷰어: "`Int.coerceAtXXX(.)`라는 함수가 있어요 한번 찾아보세요." — Kotlin 표준 라이브러리의 *범위 클램프*.
+
+### 7. 테스트 함수명에 *구현 메서드명* 노출
+
+```kotlin
+fun `concat으로 두 LottoTickets을 하나의 LottoTickets로 합칠 수 있다`() {. }
+```
+
+리뷰어: "함수 이름을 테스트 코드에 그대로 드러내는 건 좋지 않아요. 만약 함수 이름이 변경된다면 테스트 코드도 같이 변경해야 한다는 사실을 *쉽게 놓칠* 수 있으니까요."
+
+### 8. README에 변수 잔존
+
+```
+"수동 로또 개수는 ${MINIMUM_PURCHASE_AMOUNT}개 이상."
+```
+
+리뷰어: "리드미에 변수가 😱" — 카피 시 *템플릿 변수 미해소*는 흔한 실수.
+
+## 리뷰어 의견 요지
+
+- **`get*` = *반환만***, 출력 등 사이드이펙트 X.
+- **상수 중복 = 변경 함정** — *한 곳* 소유 + import.
+- **수익률은 *결과 객체*의 책임** — 다른 값 확장 시 *통일성*.
+- **외부 노출 Map = *의미 모호*** — `getCount*` 같이 *의미 부여 메서드*.
+- **`coerceIn`/`coerceAtMost` 표준** — 범위 클램프.
+- **테스트 함수명 = 의도, 구현 메서드명 X**.
+- **수동 vs 자동 = *추상화 수준 통일*** 또는 *현실 비유 따라가기* — 정답 없음, 트레이드오프.
+
+- **대표 인용:**
+  > TotalLottoTicket을 가져온다는 행위가, 출력을 같이 하고 있다면 두 가지 역할을 하고 있다고 볼 수 있지 않을까요?
+  > — @laco-dev on `src/main/kotlin/lotto/controller/LottoController.kt`
+
+  > `resultStatistics`가 그대로 외부로 노출되어 있다면, 값에 해당하는 Int 타입이 무엇을 의미하는 것인지 알 수 있을까요? 갯수일 수도 있고, 가격의 총 합일지도 모릅니다.
+  > — @laco-dev on `src/main/kotlin/lotto/domain/model/LottoDrawingResult.kt`
+
+  > 함수 이름을 테스트 코드에 그대로 드러내는 건 좋지 않아요. 만약 함수 이름이 변경된다면 테스트 코드도 같이 변경해야 한다는 사실을 쉽게 놓칠 수 있으니까요.
+  > — @laco-dev on `src/test/kotlin/lotto/domain/model/LottoTicketsTest.kt`
+
+## 얻은 교훈
+
+- **`get*` 시그니처 = *순수 반환***. 출력/저장 같은 사이드이펙트는 별도 메서드.
+- **상수의 *한 곳* 소유** — 중복 선언은 *한쪽만 바뀌어도 안 깨짐*이라는 *위험한 invariant*.
+- **결과 객체에 *통일된 책임***  — 수익률을 Money에 두면 *다른 결과*가 생길 때 *어디로 가는가* 매번 결정.
+- **`Map<X, Y>` 외부 노출 회피** — 호출자에게 *Y의 의미*가 모호. `getCountByRank` 같이 *의미 부여 메서드*.
+- **Kotlin 표준 *범위 클램프***  — `coerceIn(0, max)`, `coerceAtMost(max)`. 직접 `if-else`보다 의도 명시.
+- **테스트 함수명 = *의도 명세***, 구현 메서드명을 함수명에 두면 *리네임이 테스트 깨짐*.
+- **수동 generator의 *추상화 가치*는 *옵션***. 정답이 아니라 *확장 옵션*. 현재 비용이 가치를 넘으면 *직접 변환*도 OK.
+- **README도 *코드*** — 템플릿 변수 잔존 등은 *리뷰 책임*.

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

@@ -0,0 +1,118 @@
+# PR #66 — [로또] 빙티 1단계 미션
+
+- **Reviewee:** [@s6m1n](https://github.com/s6m1n) (페어 진행)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/66
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 60
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber`, `Money`, `Rank`, `WinningLotto`, `LottoController` 분리**.
+- **`Money.ZERO` 같은 도메인 상수 시도**.
+- **`MethodSource` 테스트**.
+
+## 못한 점 (설계 관점)
+
+### 1. 커밋 단위 — 테스트만 (구현 없음)
+
+```
+test(LottoNumberTest): LottoNumber 생성 테스트 추가
+```
+
+> TDD로 구현하는 것은, 테스트를 먼저 작성해서 커밋을 올리는 것이 아닌 테스트를 선행하여 더 좋은 구조의 설계를 지향하는 과정입니다. 그렇기 때문에 하나의 기능 단위(커밋)에서는 구현 코드와 테스트 코드가 동시에 존재해야만 합니다.
+
+→ TDD = *사고 흐름*이지 *커밋 분리*가 아님.
+
+### 2. 패키지 구조 — lotto 안에 모이지 않음
+
+```
+controller/
+domain/model/
+```
+
+→ `lotto` 패키지 아래로 모아 다른 미션과 분리.
+
+### 3. `Money.ZERO`가 Int 반환
+
+```kotlin
+class Money(val value: Int) {
+    companion object {
+        const val ZERO = 0  // ⚠ Int 반환
+    }
+}
+```
+
+> `Money.ZERO`가 Int 타입을 반환하는게 맞을까요? `Money(0) == Money.ZERO` 를 비교하는게 더 일반적이지 않을까요?
+
+→ `Money.ZERO`는 Money 타입이어야 동등성/사칙연산 자연스러움.
+
+### 4. `receiveMoney()` 반환 타입 `Pair<Money, Int>`
+
+```kotlin
+fun receiveMoney(): Pair<Money, Int> {. }
+```
+
+> receiveMoney() 함수가 반환하는 `Pair<Money, Int>` 타입이 무엇인지 의미가 충분히 드러나고 있을까요?
+
+→ Money + 무엇? data class로 의미 부여.
+
+### 5. 에러 메시지 상수의 위치 자가 의문
+
+학생 의문:
+
+> 테스트를 위해 에러 메시지 상수를 Constants에 둘 지, 테스트 할 클래스 내부의 companion object에 public const val로 둘 지 고민했습니다. 후자는 테스트에서 클래스를 의존해서 안 좋다고 생각하는데.
+
+리뷰어 답:
+
+> 기능을 테스트 할 때에.
+
+→ 테스트가 클래스의 *공개 상수*에 의존하는 건 OK. 동작이 *그 메시지를 던지는지* 검증.
+
+### 6. `MethodSource` 의도 불명
+
+```kotlin
+@MethodSource("rankProvider")
+@ParameterizedTest
+fun `Rank 매칭`(matchCount: Int, bonus: Boolean, expected: Rank) {. }
+```
+
+> 하지만 이 테스트가 어떤 의도를 가지고 어떤 결과를 기대하는지 전달하기에는 충분하지 못할 때가 많습니다. MethodSource에서의 파라미터가 무엇인지 확인하기 위해 일일히 찾아가서 확인해야 하고
+
+→ MethodSource는 *케이스 수가 많을 때*만. 적으면 inline + 명시적 이름.
+
+### 7. `assertThrows` 파라미터 미확인
+
+```kotlin
+assertThrows<IllegalArgumentException> {. }
+```
+
+> assertThrows() 함수의 파라미터로 무엇을 전달하는지 확인해보세요.
+
+→ 메시지/원인까지 확인하면 검증 강도 ↑.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 가르침:
+
+1. **TDD 커밋 단위 = 완결된 기능 (테스트 + 구현)**.
+
+2. **값 객체의 동등성 = 같은 타입 비교**. `Money.ZERO`는 Money 타입.
+
+3. **Pair는 일회용**. 영구한 자료는 data class.
+
+4. **테스트가 *공개 상수*에 의존하는 건 OK** — 동작의 일부.
+
+5. **`MethodSource` 가독성 trade-off** — 케이스 수에 따라.
+
+- **대표 인용:**
+  > `Money.ZERO`가 Int 타입을 반환하는게 맞을까요? `Money(0) == Money.ZERO` 를 비교하는게 더 일반적이지 않을까요?
+  >
+  > — @laco-dev on `src/main/kotlin/domain/model/Money.kt`
+
+## 얻은 교훈
+
+- **값 객체의 상수 = 같은 값 객체 타입**. `Money.ZERO: Money`. `Money.ZERO: Int`면 wrapping 의미 약화.
+- **`Pair<T, U>` 반환 = 의미 잃은 자리**. data class로 두 필드에 이름 부여.
+- **TDD 커밋 = 사고 흐름의 결과지 *커밋 단위*가 아니다**. test/feat 분리는 *과정 기록*.
+- **`MethodSource` 사용 기준** = 케이스 수 ≥ 10개 정도. 적으면 `@CsvSource` 또는 inline.

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

@@ -0,0 +1,112 @@
+# PR #18 — [산군] 1단계 로또
+
+- **Reviewee:** [@s9hn](https://github.com/s9hn)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/18
+- **단계:** 1단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 63
+
+## 잘한 점 (설계 관점)
+
+- **`BonusNumber`, `Lotto`, `Count`, `ShuffledNumberGenerator` 분리**.
+- **`Rank` enum + countOfMatch**.
+
+## 못한 점 (설계 관점)
+
+### 1. `LottoController.printLottoResult` — 함수명과 책임 불일치
+
+```kotlin
+private fun printLottoResult(lottos: List<Lotto>, winning:.) {
+    val rank =.calculate.
+    val profit =.calculate.
+    println(rank)
+    println(profit)
+}
+```
+
+> printLottoResult라는 함수이름이지만, 내부적으로는 많은 일을 하는 것 같아요!
+
+→ 계산 + 출력 둘 다. *print*은 출력만, *계산은 도메인*.
+
+### 2. 컬렉션 API 미활용 (forEach 대신 for문)
+
+→ map/filter/forEach가 의도 명시적.
+
+### 3. `Count` 값 객체를 만들었지만 Int로 반환
+
+```kotlin
+fun numberOfLottos(): Int =.  // ⚠ Count 만들었는데 Int 반환
+```
+
+> int가 아닌, Count 그대로 반환하면 어떨까요?
+
+→ 값 객체 만든 의미 = 호출처도 그 객체로 다루기.
+
+### 4. Rank 2등/3등 같은 countOfMatch (5개)
+
+```kotlin
+enum class Rank(val countOfMatch: Int, val money: Int) {
+    SECOND(5, 30_000_000),
+    THIRD(5, 1_500_000),  // ⚠ 같은 countOfMatch
+}
+```
+
+> 2등과 3등의 countOfMatch가 일치하네요, Rank에서 2등과 3등을 어떻게 분리를 할수 있을까요? Bonus볼의 여부도 Rank의 책임이 아닐까요?
+
+→ Rank가 matchBonus를 *판별 데이터*로 가지면 명확.
+
+### 5. `BonusNumber`에 getter/setter
+
+```kotlin
+class BonusNumber {
+    private var number: Int = 0
+    fun getNumber(): Int = number
+    fun setNumber(v: Int) { number = v }
+}
+```
+
+> 코틀린에서는 getter, setter 함수를 잘 쓰지 않습니다! 공식 문서를 가볍게 읽어보시면 좋을거 같아요!
+
+→ Kotlin property가 자동 생성. 자바식 메서드 작성 = 코틀린 idiom 위반.
+
+### 6. `LottoAdministrator` feature-envy
+
+```kotlin
+class LottoAdministrator(.) {
+    fun matchCount(lottoNumber: Lotto, winningNumber: Lotto): Int {
+        return lottoNumber.numbers.filter { it in winningNumber.numbers }.size
+    }
+}
+```
+
+> lottoNumber와 winningNumber 객체의 numbers를 가져와서 확인하는 함수네요, 객체의 데이터를 쓰기보다, 메세지를 전달하여 책임을 위임해보면 어떨까요?
+
+→ `winningLotto.match(lotto): Rank`.
+
+## 리뷰어 의견 요지
+
+리뷰어 @namjackson의 가르침:
+
+1. **함수명과 책임의 일치**.
+
+2. **값 객체 만들었으면 그 객체로 다루기** — `Count` 반환.
+
+3. **Kotlin property 활용** — getter/setter 메서드 회피.
+
+4. **Tell-Don't-Ask** — feature-envy 회피.
+
+- **대표 인용:**
+  > 2등과 3등의 countOfMatch가 일치하네요, Rank에서 2등과 3등을 어떻게 분리를 할수 있을까요? Bonus볼의 여부도 Rank의 책임이 아닐까요?
+  >
+  > — @namjackson on `src/main/kotlin/domain/Rank.kt`
+
+  > 객체의 데이터를 쓰기보다, 메세지를 전달하여 책임을 위임해보면 어떨까요?
+  >
+  > — @namjackson on `src/main/kotlin/domain/LottoAdministrator.kt`
+
+## 얻은 교훈
+
+- **값 객체 만든 후 *그 타입으로 다루기***. Count 만들고 Int 반환 = wrapping 의미 없음.
+- **Kotlin property = 자동 getter/setter**. `var number: Int`만 쓰면 자바의 `getNumber/setNumber` 자동 생성. 직접 작성 ≠ Kotlin idiom.
+- **5개 일치 두 케이스 = Rank가 matchBonus 데이터 보유**. enum의 판별 데이터.
+- **`LottoAdministrator` 같은 외부 비교자 = feature-envy 신호**. `winningLotto.match(lotto)` 메시지로.

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

@@ -0,0 +1,104 @@
+# PR #75 — [심지] 1단계 로또
+
+- **Reviewee:** [@sh1mj1](https://github.com/sh1mj1)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/75
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 15
+
+## 잘한 점 (설계 관점)
+
+- **`evaluator.evaluate()` 같은 *동어반복* 학생이 자발적 지적**.
+- **`Money` data class vs equals/hashCode 직접 override 학생 자가 비교**.
+- **`WinningRank.NONE`의 `matchNumbers(0)`이 *사실상 실제 값이 아님*을 학생이 지적**.
+- **TDD로 인한 *public 강제*에 대한 자가 분석** (블로그 링크 포함 — 정리한 학생).
+- **책임 주도 설계 5단계를 *자가 인용*** (조영호 *오브젝트* 책 정리).
+- **자가 결론에 *기준과 근거*** — "*정답을 찾는 것도 좋지만, 자신만의 기준과 근거를 세우는 것이 중요*하다는 이야기를 들었습니다."
+
+## 못한 점 (설계 관점)
+
+### 1. `Evaluator.evaluate()` *동어반복* 네이밍
+
+학생: "이 코드의 클라이언트에서 *evaluate 메서드를 호출할 때, lotteryRankEvaluator.evaluate()의 모습처럼 객체 이름과 메서드의 이름이 중복*되고, *저는 이 중복이 불필요*하다고 느꼈기 때문입니다. 하지만 *다른 네이밍을 고민해 봐도 생각나는 것이 없었*습니다. 리뷰어님께서는 *이러한 불편함을 어떻게 해결*하시나요? 고민에 대해서도 말씀해 주신 *객체 간의 협력을 중심으로 생각하고 설계하다 보면, 네이밍의 문제가 자연스럽게 해결*될까요?"
+
+→ *Ranker.of(lotto, winningLotto)* 같은 *정적 팩토리*가 자연.
+
+### 2. `Money` *data class vs 직접 override*
+
+학생: "*data class 를 사용한다면 private constructor 를 사용하기를 권고하지 않기 때문*입니다.(컴파일러 warning) 경고가 생기는 이유는 *data class로 선언 시 copy라는 메서드를 사용할 수 있게 되는데, 이 때문에 진정한 private constructor가 아니게 되기 때문*입니다. 1. data class를 사용한다. →. 다른 클라이언트 코드에서 Money를 잘못 사용하는 경우를 감안하고 넘어간다. 2. data class를 사용하지 않고 직접 equals와 hashCode, toString 메서드를 오버라이드한다. → 코드가 매우 더러워진다. *리뷰어님은 1번과 2번 중 어떠한 것이 더 좋은 생각이라고 생각하시나요?*"
+
+리뷰어: "심지는 어떤 것이 더 좋은 생각이라고 생각하시나요? *반드시 다른 하나는 '나쁜 것' 이었나요*?" 
+
+학생 (재성찰): "저는 *2번의 방법이 더 적합*하다고 생각을 했습니다. 왜냐하면 직접 equals와 hashCode, toString 메서드를 오버라이드해서 생기는 문제보다는 *Money의 인스턴스를 생성하는 방법을 하나로만 지정해서, 추후에 다른 개발자가 Money 클래스를 사용할 때 생기는 실수나 코드의 반복을 줄이는 것이 더 도움*이 된다고 생각했기 때문입니다.. [P.S] *정답을 찾는 것도 좋지만, 자신만의 기준과 근거를 세우는 것이 중요*하다는 이야기를 들었습니다. 저도 리뷰어님의 의견을 절대적인 정답이라고 생각하지는 않고 제 기준을 세우겠습니다!"
+
+리뷰어: "*원론으로 돌아가서, private constructor를 사용할 필요가 있었는지? 그 이유는 무엇이었는지? 를 더 캐묻겠습니다* 😈" — *전제 자체를 의심*.
+
+### 3. `WinningRank.NONE` *값 아님*
+
+```kotlin
+enum class WinningRank(val matchNumbers: Int,.) {
+.
+    NONE(0,.)  // ⚠ '0'은 실제 등수 정보가 아님
+}
+```
+
+학생: "*NONE이라는 entry에서의 matchNumbers(0)은 사실상 실제 값이 아니게 되었습니다*. enum class를 사용하면서 이 문제를 해결할 수 있는 방법이 있을까요?"
+
+리뷰어: "*0, 1, 2를 갖게 하는 열거형을 가지게 된다면 어떤 장단점이 있었나요*? 원하는 문제를 해결해 볼 수 있었나요? *또 다른 문제가 생겼다면, 그것은 어떻게 해결*해 볼 수 있을까요? *완벽한 정답은 존재하지 않는다는 것을 유념*해 주세요 :)"
+
+→ *Range-based matching* (`matchNumbers <= 2 → NONE`)이나 *sealed class*로 *0-2 미만*을 명시 가능.
+
+### 4. `WinningResult`의 `Map<Rank, Int>` — *Int 포장 여부*
+
+학생: "요구사항: *모든 원시 값과 문자열을 포장한다*. WinningResult의 프로퍼티인 맵의 *Int 값은 당첨의 개수*를 의미합니다. *물론 이 클래스만 봐서는 Int 값이 당첨의 개수를 의미한다는 것을 알기 힘듭니다. 하지만 그 이유로 이 Int 값도 포장할 이유가 있을까요*? 저는 *과도한 포장*이라고 생각하였습니다. 하지만 리뷰어님은 어떻게 생각하시는지 궁금합니다. 또 *원시값 포장을 사용하지 않으면서, 이 클래스만 보고 Int 값이 어떤 값을 나타내는지 알려줄 수 있는 또 다른 방법*이 있나요? (주석을 작성하지 않고)"
+
+리뷰어: "*개발의 세계에 맞고 틀림을 논하는 건 생각보다 진흙탕 싸움일 수 있어요. 누구도 이길 수 없는 게임을 하는 것일지도 몰라요. 포장했을 때는 어떤 장단점이 있었나요? 포장을 해야 하는 이유에 대해서도 많은 생각을 해 보는 건 어떨까요?*" + "*극단적으로 연습을 해보는 것도 좋은 방법*이에요! 나중에 *포장된 값을 풀어내는 것은 언제든지 가능*하지만, *포장하는 연습을 해본 적이 없는 사람은, 애초에 포장 자체를 못할 가능성*이 있어요 :)"
+
+학생: "*제가 원시값 포장을 하지 않은 이유는 설계/구현 단계에서는 원시값으로 포장을 하여 객체를 만들더라도, 그 클래스 안에 유효성 검증이나, equals 등의 어떠한 로직도 필요없기 때문*이었습니다. 하지만 *제가 아직 원시값을 사용했을 때의 이점을 설명할 정도로 알고 있지 않은 것 같네요*! 이 부분은 제가 더 공부해 보겠습니다!!"
+
+### 5. *TDD가 public 강요*? 학생 자가 분석
+
+학생 (블로그 링크 첨부): "엄밀히 말하면 *TDD 때문에 메서드가 public이 된 건 아닌 것 같*습니다. 저는 우테코 프리코스 과정 중에 *TDD에 대해 알아보고, 장/단점을 [공부한 경험](https://sh1mj1-log.tistory.com/184)*이 있습니다. 또 제가 *[오브젝트 책을 공부하면서](https://sh1mj1-log.tistory.com/141) 책임 주도 설계의 흐름*을 아래처럼 정리했었습니다.
+> * 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악함.
+> * 시스템을 더 작은 책임으로 분할
+> * 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임 할당
+> * 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요하면 이를 책임질 적절한 객체 또는 역할을 찾음.
+> * 해당 객체 또는 역할에게 책임을 할당하여 두 객체가 협력하게 함.
+
+제가 처음 코드를 작성하기 전 기능 목록을 아래처럼 정리했었습니다. *'로또 번호와 당첨 번호, 보너스 번호를 비교하여 당첨 결과를 알려준다'*. 그런데 *이 기능 명세에서 객체의 책임을 더 분리하지 않았던 것 같*습니다. 위 책임에서 책임을 더 분리한다면, 아래처럼 분리할 수 있을 것 같아요.
+> * 로또와 당첨번호가 일치하는 숫자의 갯수를 구한다.
+> * 로또에 보너스번호가 있는지 여부를 구한다.
+
+위처럼 책임을 분리할 수 있다는 사실은 LotteryRankEvaluator 객체의 책임인 evaluate의 책임에 대해서 *테스트를 먼저 작성하다가 알아냈*습니다. 이 때 *기능 목록을 수정하면서 객체를 분리할 수 있었지만, 그렇지 못한 것* 같습니다. *제가 공부하고 정리했던 TDD 도입에서의 단점*에서 이런 것이 있더라구요. *'초기 설계에 얽매이게 된다. 이 경우는 도메인에 대한 지식과 이해가 부족할수록 자주 일어난다.'* TDD 방법론 자체의 문제라기 보다는 *제가 책임을 분리하는 능력이 부족했던 탓*이네요.. *공부했던 내용인데 실제로 적용하기는 역시 훨씬 어렵군요.*"
+
+리뷰어  "*'TDD 때문에 메서드가 public이 되었다'는 정말 사실일까요*? TDD로 개발하는 것은 매우 어려운 길이에요. 왜일까요? 정말로 *없는 코드에 대해 테스트를 먼저 작성하는 게 익숙하지 않아서일까요*? *없는 코드를 테스트한다는 말이 납득이 되실까요*? 코드를 치기 전, *먼저 기능 명세를 작성하듯이, 그 작성한 명세를 기반으로 객체 간의 협력을 설계*해 보세요 :) *그러면 그 객체가 다른 객체와 협력하기 위해 만들어야 하는 메서드들이 나오게 될 거에요. 그럼 그 메서드를 먼저 TDD로 옮기면 되겠지요. match와 bonusMatch는 다른 객체들과 협력하기 위해 설계된 메서드였나요*?"
+
+→ *match*, *bonusMatch*가 *클라이언트와의 협력*이 아니라 *evaluate 내부의 헬퍼*였다면 *처음부터 private*. *테스트가 우선 도달*했다고 *public이 되는 것은 결과론*.
+
+## 리뷰어 의견 요지
+
+- **메타-질문으로 학생을 *재성찰 유도*** — "심지는 어떻게 생각하세요?", "반드시 나쁜 것이었나요?", "전제 자체를 캐묻겠습니다 😈".
+- **객체 협력 설계가 우선, *TDD가 책임 결정자가 아님***.
+- **포장은 *연습 단계에서 과하게*** — *풀어내기는 쉬움*.
+- **완벽한 정답 없음** — *기준과 근거를 자기 것으로*.
+
+- **대표 인용:**
+  > 심지는 어떤 것이 더 좋은 생각이라고 생각하시나요? *반드시 다른 하나는 '나쁜 것' 이었나요*?
+  > — @malibinYun on `src/main/kotlin/model/Money.kt`
+
+  > 개발의 세계에 *맞고 틀림을 논하는 건 생각보다 진흙탕 싸움일 수 있*어요. *누구도 이길 수 없는 게임*을 하는 것일지도 몰라요.
+  > — @malibinYun on `src/main/kotlin/model/WinningResult.kt`
+
+  > 코드를 치기 전, *먼저 기능 명세를 작성하듯이, 그 작성한 명세를 기반으로 객체 간의 협력을 설계*해 보세요. 그러면 *그 객체가 다른 객체와 협력하기 위해 만들어야 하는 메서드들이 나오게 될 거에요*. 그럼 그 메서드를 먼저 TDD로 옮기면 되겠지요.
+  > — @malibinYun on `src/main/kotlin/model/lottery/LotteryRankEvaluator.kt`
+
+  > 나중에 *포장된 값을 풀어내는 것은 언제든지 가능*하지만, *포장하는 연습을 해 본 적이 없는 사람은, 애초에 포장 자체를 못할 가능성*이 있어요 :)
+  > — @malibinYun on `src/main/kotlin/model/WinningResult.kt`
+
+## 얻은 교훈
+
+- **`Evaluator.evaluate()` 동어반복 회피** — *Ranker.of(lotto, winning)* 같이 *정적 팩토리*로 *주어 + 동작*을 *한 단어*에. 객체 협력 어휘는 *짧고 자연*.
+- **`data class` vs `private constructor` 충돌** — *value class*가 표준 해법. 학생이 *직접 override*를 *코드 더러움*이라 자각.
+- **`enum.NONE`의 *가짜 값* 문제** — *Sentinel 객체*가 *0/null* 보유는 *의미 없는 값*. *sealed class*로 *MissCase* 분리 가능.
+- ***과도한 포장*에 대한 기준** — *유효성/equals 로직이 필요 없으면* 포장 가치 약함. 단 *연습 단계에선 과하게* 권장.
+- **TDD가 *책임 결정*하지 않음** — *기능 명세 → 객체 협력 → 메서드*. *Test-first*가 *Design-first*를 대체하지 않음.