oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-blackjack/chaehyuns/98-2/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,206 @@
+# PR #98 — [블랙잭 2단계] 채채 미션
+
+- **Reviewee:** [@chaehyuns](https://github.com/chaehyuns)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/98
+- **단계:** 2단계
+- **리뷰어:** @Gyuil-Hwnag (두루)
+- **라인 코멘트:** 21 스레드 (반 정도는 칭찬 — 실제 토론은 7~8개) + **PR 본문 자가 의문 3개** + **학생 자가 답변 깊이** (data object / sealed class / fun interface)
+- **양 단계 분석 reviewee** (1단계 #70 별도)
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문에 학생 자가 의문 3개 명시** — *"내가 한 것이 진짜 상태 패턴이 맞는가?"* (Heads First Design Patterns 책 인용, 조건문 제거 효과 의문) / *3개 변수 제약 우회 의문* / *fun interface vs interface 자가 토론* + 자가 결론. PR #128·#135·#108·#133·#136·#137·#148·#151 와 같은 결.
+- **두루 sealed class 코드 예시 제안 → 학생 자가 반영 + when + sealed 학습** — 학생 답변: *"sealed class를 사용해서 유지보수성, 확장성, 타입안정성 을 높일 수 있었습니다! 특히 when 문을 사용할때 sealed class를 활용한다면 더 좋겠다는 지식도 얻어갑니다 🤓"*. **Kotlin 어휘 (sealed + when exhaustive) 자가 학습 모범**. PR #137·#148·#90 와 같은 결.
+- **`data object` 자가 학습 (`Running` 상태)** — 두루 권고에 학생이 *toString/equals/hashCode 구현 차이* + *sealed 와 조합 시 패키지명/주소값 무의미* 자가 분석 후 답변. **PR #146 두루 typealias 자가 학습 / PR #148 크롱 역할-상태 자가 학습 / PR #151 자가 학습** 결.
+- **HandCards 의존성 자가 반영** — 두루 진단 *"Hand 에서 Deck을 부 생성자로 안가지고 함수의 파라미터로 받아서 처리하는 방법으로 객체 생성시에 대한 의존성을 줄여볼 수 도 있겠다는 생각이 듭니다~💪"* + 학생: *"객체보다는 함수에 파라미터로 받아서 처리하는 게 더 객체지향적이라는 생각이 드네요!"*. **생성자 의존 vs 파라미터 주입 자가 학습**. PR #133·#136·#85·#58 와 같은 결.
+- **Judge 책임 객체화** — 두루 칭찬: *"게임 결과와 이윤을 담당하는 객체를 새롭게 만들어 주셨네요~👍"*. *1단계 Dealer 책임 비대* → *2단계 Judge 분리* 자가 진화 (PR #70 §5 토론의 자가 답변).
+- **OutputView → ProgressView + ResultView 분리 자가 반영** — 두루 권고 + 학생: *"OutputView를 분리해볼 생각은 하지 못했는데 코드 가독성과 유지보수하기 좀 더 수월해졌다고 생각이 드네요!! ㅎㅎ 감사합니다!"*. *view-by-stage-split* — PR #88·#131 와 같은 결.
+- **BettingAmount + BettingAmountInputView 분리** — 두루 칭찬: *"BettingAmount에 대한 Input도 분리를 해주셨네요~💯"*. *원시값 포장 + 입력 객체 단위 view 분리* — PR #137·#148 와 같은 결.
+- **테스트 코드 + ValueSource 활용** — 두루 칭찬: *"ValueSource를 활용해서 테스트 코드 너무 깔끔하게 작성해주셨네요~👍"* / *"테스트 함수명만 보고도 어떠한 기능을 테스트하는 함수인지 명확하게 판별이 가능하네요~💯"* (1단계의 함수명 미흡 자가 학습 후 반영).
+- **PR 본문 다이어그램 첨부** — Figma 손그림 상태 다이어그램. 두루 칭찬: *"첨부해주신 다이어그램을 보니까 어떤 내용인지 더 한눈에 들어오네요~💯"*. **시각화 = 리뷰어 컨텍스트 부담 감소 + 학생 자가 정리** — PR #146·#148·#92 와 같은 결.
+
+## 못한 점 (설계 관점)
+
+### 1. State sealed class 미적용 (학생 자가 자가 사유 후 자가 반영)
+
+두루 코드 제안:
+
+```kotlin
+sealed class State {
+    abstract fun decisionState(): State
+
+    class Start(private val player: Player): State() {
+        override fun decisionState(): State {
+            player.initializeCards()
+            return if (player.isBlackjack()) Blackjack(player) else Running(player)
+        }
+    }
+
+    class Hit(private val player: Player) : State() {
+        override fun decisionState(): State {
+            player.addCard()
+            return if (player.isBust()) Bust(player) else Running(player)
+        }
+    }
+
+    data object Running : State() {
+        override fun decisionState(): State = Running
+    }
+}
+```
+
+학생 자가 인정: *"sealed class를 사용해서 유지보수성, 확장성, 타입안정성 을 높일 수 있었습니다!"*
+
+→ **`interface State` + 파일 분리 < `sealed class State` + 하나의 파일**. 
+
+이유:
+- *`sealed`*는 *컴파일러가 상태 닫힘 (closed type hierarchy) 보장* → `when` 문 *`else` 없이도 exhaustive*.
+- *`interface`*는 *추가 구현체가 외부 모듈에서 생길 수 있음* → `when` 에 `else` 강제 + 미처리 누락 위험.
+- 블랙잭의 상태는 *기획상 명확히 한정 (Start/Hit/Bust/BlackJack/Stay)* → *닫힘이 정공*.
+
+PR #93·#136·#152·#90 가 *sealed 정공* + PR #146·#148·#151 가 *fun interface vs interface 자가 학습* 결.
+
+### 2. Running data object 미적용 (`player` 생성자 잔재 자가 토론)
+
+두루: *"player 생성자의 경우 따로 사용을 하는 곳이 보이지 않는데, 혹시 추가를 해주신 이유가 있을까요??🤔 추가적으로 Running 에서 player를 제거 하고 나면 IDEA 내에서 data object로 수정을 하도록 권유 할텐데, data object 는 어떤 것일까요??"*
+
+학생 자가 답변 (학습 모범):
+
+> *"Running 에서 player 생성자가 쓰이지 않는 걸 확인하고 data object로 변환 하려는 시도를 했으나, Hit으로 상태를 돌릴때 카드를 추가해야하다보니 player을 가지고 있어야 Hit에 player을 줄 수 있었습니다. 다만 너무 아쉬운 점은 상태가 Player보다는 HandCards를 들고 있었다면 코드가 조금 더 가독성이나 사용성이 좋지 않았을까 하는 생각을 했습니다. 상태 패턴을 처음 쓰다보니 어떻게 상태 패턴을 관리해야 효과적인지에 대한 학습이 부족했다고 생각이 들어, 추후 시간이 될 때 다시한번 구현해보고 싶네요!*
+
+> *수정하며 IDEA 내에서 data object로 수정을 하도록 권유를 해서 data object에 대해 살펴보니 data class와 동일하게 data object는 일반 object와 동일하지만 내부적으로 toString(), euquals(), hasCode()를 구현하고 있다는 것을 알 수 있었습니다. 즉 data class 타입은 객체명과 데이터값을 간결하게 보여줄 수 있고 object 타입은 객체의 풀패키지명과 주소값을 가지고 있는데, sealed 타입으로 감싸서 각 상태값을 관리할때에는 object 객체의 패키지명과 주소값은 유의미한 값이 아닐 가능성이 많으니 data object로 수정을 권유한다는 점도 학습할 수 있었습니다! 🤓"*
+
+→ **학생 자가 두 가지 학습**:
+
+1. **상태 객체가 들고 있어야 하는 것: Player vs HandCards**. *상태 객체의 데이터 = 행동에 필요한 최소 정보*. *상태 전이 시 `player.addCard()`만 호출한다면 `HandCards` 만 들어도 충분*. *Player 전체를 들면 → 상태 객체가 Player 의 다른 책임 (베팅/이름) 까지 알게 됨 → 결합도 증가*.
+2. **`object` vs `data object` (Kotlin 1.9+ 어휘)**. 
+   - `object` → 싱글톤 + `toString` = `package.ClassName@hashcode` (디버그 비친화).
+   - `data object` → `toString` = `ClassName` / `equals` = `true` (같은 싱글톤끼리) / `hashCode` = 안정값.
+   - *sealed 의 멤버 상태는 데이터값 차이가 없는 경우* → `data object` 가 *디버깅·로깅·`when` 분기에 더 친화*.
+
+PR #133·#136·#90·#146 와 같은 결 (Kotlin 어휘 자가 학습).
+
+### 3. `HandCards.clear()` 잔재 (학생 자가 인정)
+
+두루: *"해당 함수를 통해서 카드를 비워주도록 하는 이유에 대해서 궁금합니다!🤔"*
+
+학생: *"상태 패턴을 적용하면서 코드를 이리저리 바꾸다 보니 _cards.clear()를 추가했다가 깜빡하고 삭제를 하지 못했네요 🥲 객체보다는 함수에 파라미터로 받아서 처리하는 게 더 객체지향적이라는 생각이 드네요! 수정했습니다:)"*
+
+→ **상태 패턴 적용 중 자가 jitter 코드 잔존**. *리팩토링 중 `clear()` 같은 mutable 메서드 잔재 = 객체 생애주기 모호 + 캡슐화 누수 위험*. *불변 객체 + 새 객체 생성* 으로 대체가 정공.
+
+추가 학생 자가 학습 — *"객체보다는 함수에 파라미터로 받아서 처리하는 게 더 객체지향적"*. 이건 *맥락 한정 명제*:
+- *전역 의존 (생성자)* < *지역 의존 (파라미터)* — *결합도 한정*.
+- 단 *동일 협력자를 매번 받아야 한다면 파라미터가 오히려 노이즈* — *경우에 따라 다름*.
+
+PR #58 의 `Deck` 생성자 vs 파라미터 토론 / PR #133 의 `HandCards` 자가 학습 결.
+
+### 4. `isWin` / `isLose` 명명 → `PlayerWin` / `DealerWin` 권고
+
+두루: *"조건도 상태에 맞게 정말 너무 잘 분리해주셨네요~👍 다만 추후에 시간이 나신다면, `isWin`, `isLose` or (예시) `PlayerWin`, `DelearWin`를 보고 누가 이기는 것인지에 대해서도 있으면 좋을 것 같다는 생각이 듭니다!💪"*
+
+학생: *"생각해보니 player의 기준에서 작성되었다는 것을 명시해줄 필요가 있었던거 같네요! 좋은 리뷰 감사합니다 😄"*
+
+→ **부울 명명에서 *기준점 (subject) 누락***. *`isWin` = "누가 이기나?"* 가 *코드 독자*에게 *Player 기준 명시 X* → *Dealer 코드에서도 호출되면 의미 반전 위험*.
+
+대안:
+- (A) **`PlayerWin` enum 값** = *부울 X, 결과 enum O*. 단 `enum class GameResult { PlayerWin, DealerWin, Push }` 자체가 *3-state 분기 = 부울 단일성보다 풍부*.
+- (B) **`Result.isWinFor(participant)`** = *기준점을 인자로*. *enum 변형 = 함수형*.
+- (C) **`isPlayerWin` 명명** = *기준점 명시 + 부울 유지*. 가장 단순.
+
+**`canHit` vs `isBust` 부울 의미 일관 (True 방향 통일)** — PR #151 의 *부울 명명 의미 통일* 결.
+
+### 5. PR 본문 자가 의문 3개
+
+#### 5.1. *"내가 한 것이 진짜 상태 패턴이 맞는가?"*
+
+학생 자가 의문: *"여기서 3번 조건문 코드를 전부 없애라고 되어 있는데, 생각보다 제 코드에서 드라마틱한 변화는 찾을 수 없었습니다...🥲"*
+
+→ *Heads First Design Patterns* (책) 의 *상태 패턴 = 조건문 제거 = 다형성 디스패치 위임* 정의를 *자가 적용 시 효과 의문*.
+
+원인 진단:
+1. *상태 객체가 `Player` 를 들고 있어 → 상태 객체에서 `player.addCard()` 등 호출 → 학생 코드의 조건문 자체는 사라졌으나 → "Player 가 무엇을 할지" 의 분기가 *상태 객체로 옮겨갔을 뿐*.
+2. *진정한 상태 패턴* = *State 객체가 `decideState()` 와 같이 다음 상태를 자기 책임 으로 결정* → *Context (Player) 는 `state.handle()` 만 호출*. *학생 코드는 이 흐름이 미완성* (Context vs State 책임 경계 모호).
+
+→ **상태 패턴 효과 = 조건문 *위치 이동* 이 아니라 *Context 의 분기 책임 자체 제거***. PR #93·#136·#152 가 *Player → State.compareTo(other): GameResult* 다형성 정공.
+
+#### 5.2. *"3개 이상의 인스턴스 변수를 쓰지 않을 수 있는 방법?"*
+
+학생: *"지금 현재 player에 대한 변수를 줄여야하는데, 도저히 방법이 생각나지 않습니다... 혹시 조언해주실만한 내용이 있으신지 궁금합니다! 객체가 '상태'를 가지고 있으려면 추가되는 게 어쩔 수 없는 것일까요?"*
+
+→ *3 변수 제약* = *블랙잭 미션 요구사항 (객체지향 생활 체조 원칙)*. *Player 가 `name`/`handCards`/`bettingAmount`/`state` 4 변수* → 제약 위반.
+
+해결 후보 (학생이 자가 답변 X — 1단계 후 머지 시점까지 미해결):
+
+- (A) **Player 분해** — `Participant` (name) + `Hand` (cards) + `Wallet` (bettingAmount). *책임별 분리*.
+- (B) **`PlayerBetInfo` 같은 인공 객체 도입** — *베팅 + 결과를 묶음*. PR #133·#88·#132·#136·#93 의 *3 변수 제약 부산물 인공 객체* 결. 트레이드오프: *책임은 모호하지만 변수 수 통과*.
+- (C) **State 가 Player 가 아닌 더 작은 단위 (HandCards) 들기** — *학생 자가 후회*.
+- (D) **제약 자체 회피** — *블랙잭 도메인의 자연 모델링이 어렵다면 제약 완화 정공*. PR #146 의 *YAGNI* / PR #151 의 *반란군 비유* 결.
+
+#### 5.3. *fun interface vs interface*
+
+학생 자가 답변 (자가 결정): *"하지만 추후 state에 대한 메소드들이 늘어날 가능성, 그리고 일반적으로 다른 사람들이 기대하는 state는 fun interface 보다는 interface라고 생각해서 코드를 수정하지 않았습니다."*
+
+→ **자가 결정 합리**:
+- *fun interface = SAM (Single Abstract Method) 한정* → *람다 단축 표기 가능*. 그러나 *2개째 메서드 추가 즉시 `fun` 키워드 컴파일 에러*.
+- *State 의 향후 메서드 확장 (canHit, decideState, score) 가능성 ≥ 1* → *interface 유지* 가 *변경 비용 회피*.
+- *"사람들이 기대하는 state는 interface"* → *관용적 어휘* (Wirfs-Brock 의 stereotype 어휘에 가까움).
+
+PR #146·#148·#151 의 *fun interface 자가 토론* 결.
+
+### 6. `Judge` 함수 분리 권고
+
+두루: *"이전에 비해서 상태에 대해서 좀 더 판별을 쉽게 하려는 노력이 보이는 것 같은데, 해당 내용을 함수로 분리를 해보시는것은 어떨까 라는 생각도 듭니다!!💪"*
+
+학생: *"함수로 분리하니 더 코드가 깔끔해보이네요! 감사합니다 :)"*
+
+→ **함수 분리 = *조건 표현식 → 명명된 함수*** = *읽는 사람이 의미를 한 번에 파악*. 단순 권고 + 학생 자가 반영.
+
+### 7. `HandCards.cards` vs `HandCards` 분리 (1단계 권고 반영 누락)
+
+1단계 두루 권고: *"Cards의 toString을 이용하도록 수정을 해보는 것도 좋을 것 같다는 생각이 듭니다~"*
+
+2단계에서 HandCards 자체에 `clear()` 잔재 (위 §3) + `_cards.clear()` 가 남았음 → *1단계 권고 일부만 반영*.
+
+→ **1단계 자가 반영 누락 = 학생도 인정 (위 §3)**. *상태 패턴 적용에 집중하다 다른 권고 누락*.
+
+## 리뷰어 의견 요지 (두루 / Gyuil-Hwnag)
+
+두루의 21 코멘트 패턴:
+- **칭찬 절반 + 핵심 진단 절반** — *너무 깔끔합니다!💯* (4회), *너무 잘 분리해주셨네요~👍* (5회), *깔끔하게 작성해주셨네요~👍* (3회). 칭찬이 코드 위치별로 명확 → *학생이 어떤 부분이 잘 되었는지 자가 학습 가능*.
+- **코드 예시 첨부 진단** = *sealed class 코드 예시* (State.kt §1). *문장 설명 < 코드 예시* → *학생이 직접 비교 가능 + 자가 적용 학습*. PR #75·#74·#133·#137·#146·#148·#151 의 두루/말리빈/지훈/크롱 코드 예시 결.
+- **머지 시점 종합 코멘트** = *"고민을 많이 하시고 점점 객체들의 각 역활들에 대해서 잘 분리가 되고, 복잡한 로직에 대한 처리와 가독성 측면에서도 좋아지는 모습이 아주 인상적이었습니다!!"* — *1→2단계 진화 인정 + 학생 자가 동기 부여*. PR #70 1단계 → #98 2단계 양 단계 본 reviewer 만 가능한 종합 평가.
+- **메타 학습 권유** = *`PlayerWin`/`DealerWin` 명명* / *`HandCards` 의존성 줄이기* — *수정 강제 X + "추후에 시간이 나신다면" 권유 형식*.
+
+## 대표 인용
+
+> *"수정하며 IDEA 내에서 data object로 수정을 하도록 권유를 해서 data object에 대해 살펴보니 data class와 동일하게 data object는 일반 object와 동일하지만 내부적으로 toString(), euquals(), hasCode()를 구현하고 있다는 것을 알 수 있었습니다. (...) sealed 타입으로 감싸서 각 상태값을 관리할때에는 object 객체의 패키지명과 주소값은 유의미한 값이 아닐 가능성이 많으니 data object로 수정을 권유한다는 점도 학습할 수 있었습니다! 🤓"* — chaehyuns
+
+> *"다만 너무 아쉬운 점은 상태가 Player보다는 HandCards를 들고 있었다면 코드가 조금 더 가독성이나 사용성이 좋지 않았을까 하는 생각을 했습니다. 상태 패턴을 처음 쓰다보니 어떻게 상태 패턴을 관리해야 효과적인지에 대한 학습이 부족했다고 생각이 들어, 추후 시간이 될 때 다시한번 구현해보고 싶네요!"* — chaehyuns (학생 자가 후회 + 향후 재구현 의지)
+
+> *"여기서 3번 조건문 코드를 전부 없애라고 되어 있는데, 생각보다 제 코드에서 드라마틱한 변화는 찾을 수 없었습니다...🥲 그 결과 '내가 한 것이 진짜 상태 패턴이 맞는가?' 에 대한 고민이 들어..."* — chaehyuns (학생 자가 패턴 적용 효과 의문)
+
+> *"sealed class를 사용해서 유지보수성, 확장성, 타입안정성 을 높일 수 있었습니다! 특히 when 문을 사용할때 sealed class를 활용한다면 더 좋겠다는 지식도 얻어갑니다 🤓"* — chaehyuns (학생 Kotlin 어휘 자가 학습)
+
+> *"step1, step2 두루의 리뷰를 통해서 코드가 더 깔끔해질 수 있었고 가독성 측면에서 더 신경을 쓸 수 있었습니다 😊 좋은 리뷰와 말씀 너무 감사드립니다!"* — chaehyuns (양 단계 종합 회고)
+
+## 얻은 교훈
+
+1. **상태 패턴 효과 = *Context 의 분기 책임 제거***, *조건문 위치 이동* 이 아님. 학생의 *"드라마틱한 변화 없다"* 자가 의문 = *상태 객체가 Context 를 들고 있어 분기 책임이 *위치만 이동* 함을 자가 진단*.
+
+2. **상태 객체의 데이터 = *행동에 필요한 최소 정보***. *Player 전체 < HandCards (가장 작은 단위)*. *상태 객체가 협력자의 다른 책임까지 알면 결합도 폭증*. 학생 자가 후회 모범.
+
+3. **`object` vs `data object` (Kotlin 1.9+) = *디버깅/로깅 친화도***. *sealed 의 상태 멤버에 `data object` 가 정공*. *toString = ClassName / equals 안정 / 패키지명 누수 X*.
+
+4. **`interface` vs `sealed class`** = *컴파일러 상태 닫힘 보장* vs *외부 모듈 확장 가능성*. *블랙잭 같은 *닫힌 상태 집합* = `sealed` 정공 + `when else` 불필요*.
+
+5. **`fun interface` vs `interface`** = *SAM 한정 람다 단축 vs 확장 여지*. *State 처럼 메서드 추가 가능성 ≥ 1* = `interface` 정공. *학생 자가 결정 합리*.
+
+6. **`isWin` / `isLose` 부울 명명 = *기준점 (subject) 명시 누락 시 의미 반전 위험***. *`isPlayerWin`* / *`Result.isWinFor(participant)`* / *enum GameResult* 가 대안.
+
+7. **3 변수 제약 = *블랙잭 도메인 자연 모델링 어려움***. *학생 자가 미해결* = *제약과 도메인 정합의 트레이드오프*. PR #133·#88·#132·#136·#93 의 *인공 객체 도입* 패턴 = *우회 + 책임 모호 비용*.
+
+8. **상태 패턴 적용 중 `clear()` 같은 mutable 잔재**. *리팩토링 중 객체 생애주기 변경 시 *지운 메서드 흔적이 남기 쉬움**. *불변 객체 + 새 객체 생성* 으로 대체가 정공.
+
+9. **PR 본문에 자가 의문 3개 + 자가 다이어그램 + 학생 자가 답변 모두 풍부 = *학습 가시화 모범***. PR #128·#135·#108·#133·#136·#137·#148·#151 와 같은 결.
+
+10. **양 단계 본 reviewer 만 가능한 종합 평가** = *진화 인정 + 동기 부여*. *PR #70 (1단계) → #98 (2단계) 자가 진화* = *Dealer 책임 비대 → Judge 분리* / *score 책임 모호 → State 도입 시도* / *함수명 미흡 → 테스트 함수명 명확화* 가 두루의 종합 코멘트로 *학생도 자가 진화 가시화*.

package/lessons/woowacourse-kotlin-blackjack/chanho0908/123-1/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,277 @@
+# PR #123 — [블랙잭 1단계] 페토 미션
+
+- **Reviewee:** [@chanho0908](https://github.com/chanho0908)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/123
+- **단계:** 1단계 (안드로이드 백그라운드 — 객체지향 토론 풍부)
+- **리뷰어:** @lee-ji-hoon (코니)
+- **라인 코멘트:** 30 (리뷰어 16 / 리뷰이 14)
+
+## 잘한 점 (설계 관점)
+
+- **`Deck`이 `Deque<TrumpCard>` 자료구조 보유** — `ArrayDeque`로 *카드를 위에서 한 장씩* 개념 표현 (PR #63·#65의 Set/재귀 문제 회피).
+- **`Participant` 인터페이스 + `Dealer`/`Player` 구현** — 중복 코드 추상화.
+- **`Participants` 일급 컬렉션 (`players + dealer` 구성)** — 컨트롤러가 *컬렉션* 단위로 전달.
+- **`UserChoice` enum (HIT/STAY)** — 도메인 어휘로 입력 정규화.
+- **`retryWhenException` 유틸 분리** — Controller에서 재시도 루프 추상화.
+- **`fixture/trumpCardFixture` test fixture 디렉토리 분리** — 공통 setup을 *별도 함수 묶음*으로.
+- **테스트 함수명 *시나리오 + 결과* 일관 적용** — 매우 긴 이름이지만 *상황을 정확히 기술*.
+- **학생이 *캡슐화 vs 테스터빌리티* 트레이드오프를 자가 토론 — PR 본문에 명시** (못한 점 §1과 연결).
+
+## 못한 점 (설계 관점)
+
+### 1. `Deck` *의도적으로 테스트 불가능* 설계 — 카드 소진 처리 누락
+
+```kotlin
+class Deck {
+    private val cards: Deque<TrumpCard> = ArrayDeque()
+    init { getAllCards() }
+    fun pop(): TrumpCard = cards.pop()       // 빈 덱에서 NoSuchElementException
+    private fun getAllCards() { cards.addAll(makeCards()) }
+}
+```
+
+학생 자가 설명: "`pop()` 메소드만이 public으로 구현되어 있는점, `shuffled()`을 사용하고 있다는 점 [...] 저는 의도적으로 이 클래스를 테스트 불가능하게끔 설계했습니다 ! [...] 테스트 불가능 코드가 나쁜 코드인가 ?"
+
+리뷰어: "캡슐화를 하다 보면 내부 구현 로직을 최대한 숨기게 되니 테스트가 불가능해집니다. 물론 그 캡슐화된 로직은 테스트가 필요가 없게끔 짜는 것이 중요합니다. [...] 그러면 지금의 상황은 모든 비즈니스 로직이 정말 잘 고려가 되어 있느냐를 고민해 보시죠. ``` 1. 참여자를 10명 정도 설정한다. 2. 다들 계속 카드를 받는다. 3. ??? ``` 3번에서 어떠한 상황이 발생하는지부터 생각해 봅시다. 이 클래스가 정말 테스트가 필요 없을까요?"
+
+학생 자가 인정: "카드가 모두 소진 되었을 경우 그 다음 과정에 대한 처리가 되어있지 않았더군요 ... 😱 [...] `Deck`은 명백히 테스트가 필요한 클래스가 맞는 것 같습니다 ! + 카드가 모두 소진 되었을 때 + 카드 뭉치의 구성이 게임 규칙에 맞게 만들어지는가? + 카드 뭉치에 중복된 카드가 없는가?" — *테스트 불가능 = 비즈니스 룰 미포함*이 동치였음을 자가 깨달음.
+
+### 2. `pop()` vs `draw()` — 자료구조 노출 vs 도메인 어휘
+
+학생 자가 토론: "`pop`은 `stack, queue, deque` 같은 특정 자료구조에만 있는 함수입니다. 그렇기 때문에 `Deck`이 어떤 자료구조를 사용하는지 외부에서 대략적인 유추가 가능합니다. [...] 외부로부터 숨은 의존성을 제거하고 완전히 은닉화하기 위해선 `draw()`같은 함수명을, 해당 함수의 동작을 유추할수 있도록 하고 싶다면 ? `pop()` 을 사용하면 된다고 생각"
+
+리뷰어: "`좋은 API는 사용자가 당신의 클래스 이름만 보고도 모든 메서드 이름을 맞출 수 있어야 합니다` 라는 측면에서 pop이 어울리신가요? draw가 어울릴까요? 아니면 draw는 사람이 해야 하는 것이고 다른 함수명을 선택해보는 것이 좋을까요?" — *클래스 이름 → 메서드 이름 추론 가능성*이 좋은 API 척도. `Deck.draw()`는 *카드를 뽑는다*는 도메인 행위에 일치. `pop()`은 구현 어휘.
+
+### 3. `Deck.getAllCards()` — getter인데 `add` 동작
+
+```kotlin
+init { getAllCards() }
+private fun getAllCards() {
+    cards.addAll(makeCards())            // get이 아닌 add
+}
+```
+
+리뷰어: "`getAllCards` 함수만 생각했을 때 이 함수가 호출이 될 때 뭔가 문제가 있어 보이지 않나요? ``` 1. 이 함수가 정말 get인가? 2. 누군가 유지보수 할 때 이 함수를 잘못 쓰면 어떻게 될까? ```"
+학생 자가 인정: "메소드 네이밍은 getter지만 동작은 add를 하고 있으니 명백히 잘못된 네이밍인 것 같습니다 😅" — `private` 함수에도 *동사가 동작과 일치*하는 원칙은 동일.
+
+### 4. `Participant` 인터페이스의 `sumOfCards` (property) vs `sum()` (function) 동거
+
+```kotlin
+interface Participant {
+    val cards: List<TrumpCard>
+    val sumOfCards: Int        // property — ACE 보정 전 원시 합
+    fun addCard(card: TrumpCard)
+    fun hasAce(): Boolean
+    fun isBust(): Boolean
+    fun sum(): Int             // function — ACE 보정 적용된 최종 점수
+}
+```
+
+리뷰어: "`sumOfCards` 가 사용이 되는 부분을 보면 이것이 public일 필요가 있을지를 고민해보면 좋을 것 같고, `sumOfCards` 와 `sum()` 이 두 개를 어느 상황에서 써야 하는지 이 인터페이스만 보고도 유추가 가능할까요? 저는 좀 어려웠네요 🫠" — *내부 계산 단계*가 *공개 API*에 노출. `sumOfCards`는 `sum()`의 내부 일부일 뿐. *공개 API에서 *호출자 선택*을 강요*하지 말 것.
+
+### 5. `Player`가 `data class` — equals/hashCode 의도 불명
+
+```kotlin
+data class Player(val name: String) : Participant {
+    private val _cards = mutableListOf<TrumpCard>()
+    override val cards: List<TrumpCard> get() = _cards.toList()
+    ...
+}
+```
+
+리뷰어: "`Player` 가 data class 여야만 했던 이유가 있을까요? 🤔" — `data class`는 *값 객체*. `Player`는 *_cards mutable state*를 가져 *식별자(name)는 같은데 손패가 다른 두 Player*가 가능. *동치성이 깨질 위험*. lotto/racingcar의 `data class + var = 위험` 패턴 (STYLE_GUIDE §9-2)과 동일.
+
+### 6. `Player.sumOfCards`를 `val` + custom `get()` — 호출 비용 매번 발생
+
+```kotlin
+override val sumOfCards get() = _cards.sumOf { card -> card.tier.values }
+```
+
+리뷰어: "해당 값이 변수로 선언하게 된 계기가 무엇인지 궁금하네요. 페토는 변수 선언을 할 때 custom get() 을 쓰는 경우와 함수를 쓰는 경우 어떻게 구분을 하나요?"
+
+학생 답변: "`custom getter`는 필드를 만들지 않고 `getter`만 생성되어 원본 필드의 값이 변경될 때 `getter`에 선언된 필드의 값에 따라 변경됩니다 ! [...] 메소드로 사용해도 되지만 이를 사용하는 다른 곳 에서 코드가 간결해진다는 장점 때문에 변수로 사용했습니다." — `val + get()`은 *매 접근마다 계산*. *상태가 아닌 함수*를 *property*로 노출하면 호출자는 *저장된 값*이라고 오해. *순수 계산은 `fun`*, *지속 상태는 `val`*이 원칙.
+
+### 7. `BlackJackGame.calculateDealerResult`가 결과를 *람다로 전달*
+
+```kotlin
+fun calculateDealerResult(action: (Map<GameResult, Int>) -> Unit) {
+    val dealerMap = GameResult.entries.associateWith { 0 }.toMutableMap()
+    participants.players.forEach { player ->
+        val result = GameResult.from(participants.dealer.sum(), player.sum())
+        dealerMap[result] = dealerMap.getOrDefault(result, 0) + 1
+    }
+    action(dealerMap)                // 반환 대신 콜백
+}
+```
+
+리뷰어: "`calculateDealerResult` 여기서 왜 Result를 lambda로 값을 넘기는지가 궁금하네요. 단순 return을 할 수는 없던 것인가요? 페토가 lambda를 선택한 이유가 무엇인가요?" — 람다 콜백은 *비동기/이벤트* 컨텍스트에 자연. *동기 계산*에서 callback을 쓰면 *반환값 추적이 어려워지고* *Controller가 람다 안에서 View 호출* 패턴이 나옴. PR #65와 같은 *기능 과시* 위험.
+
+### 8. `BlackJackController.readForGame(participants): BlackJackGame` — 함수명 모호
+
+```kotlin
+private fun readForGame(participants: Participants): BlackJackGame {
+    val deck = Deck()
+    return BlackJackGame(participants, deck)
+}
+```
+
+리뷰어: "이 함수를 보고 `BlackJackGame` 을 반환할 것이다. 라는 것을 알 수 있을까요?" — `readForGame`은 *준비 동작*에 가까우나 *반환값 = `BlackJackGame`*이라는 정보 없음. `createGame()` / `assembleGame()`가 자연.
+
+### 9. `UserChoice` enum이 *입력 문자열을 `MutableMap`으로 저장*
+
+```kotlin
+enum class UserChoice {
+    HIT, STAY,
+    ;
+    companion object {
+        private const val INPUT_HIT = "y"
+        private const val INPUT_STAY = "n"
+        private const val INVALID_VALUE = "잘못된 값을 입력하였습니다."
+        private val CHOICE = mutableMapOf<String, UserChoice>()        // 가변 + 정적
+        // ...
+    }
+}
+```
+
+리뷰어: "유저의 선택을 왜 map으로 저장하고 있는 것일까요?" — `enum.entries.find { ... }`로 충분. *가변 정적 맵*에 *상수*를 담는 패턴은 *재초기화 위험* + *불필요한 상태*. + UI 형식(`"y"`/`"n"`)이 도메인 enum 안에 있음 (PR #63·#65와 같은 결).
+
+### 10. `Dealer.companion object`에 `DEALER_MAX_SCORE = 16`, `ACE_EXTRACT_SCORE = 10`
+
+```kotlin
+class Dealer : Participant {
+    fun isOverMaxScore(): Boolean {
+        if (hasAce() && !isBust()) {
+            return sumOfCards + ACE_EXTRACT_SCORE > DEALER_MAX_SCORE
+        }
+        return sumOfCards > DEALER_MAX_SCORE
+    }
+    companion object {
+        const val DEALER_MAX_SCORE = 16
+        const val ACE_EXTRACT_SCORE = 10
+    }
+}
+
+// 다른 곳에서
+import blackjack.domain.participant.Dealer.Companion.ACE_EXTRACT_SCORE
+```
+
+리뷰어: "이 값이 `Dealer`의 동반 객체로 있는 게 맞을까요? `Dealer`만 판단해야 할 값이 아니니 어디가 적합했을지 고민을 해보면 바로 답이 나올 것 같네요!" — `ACE_EXTRACT_SCORE = 10`은 *블랙잭 룰*. `Dealer` 외 `Player`도 사용. *카드 룰 상수*는 `Card`/`Game` 수준에. `Dealer.Companion`에 두면 *Dealer가 룰의 소유자*라는 오해.
+
+### 11. `enums/` 패키지 — 구현 세부로 패키지 구성
+
+```
+blackjack/
+  domain/
+    enums/
+      CardTier.kt
+      Shape.kt
+      GameResult.kt
+      UserChoice.kt
+    participant/
+      Dealer.kt
+      Player.kt
+      Participant.kt
+```
+
+리뷰어: "model 안에 enums로 이렇게 분리가 되면 interface가 생기면 interfaces 로 분리를 하실 계획일까요? 패키지명은 대략적으로 집합체에 대한 성격을 나타내는 것을 노력해보시면 좋을 것 같습니다. 패키지에서 어떻게 구현이 되었던 그건 패키지의 관심사가 아닙니다." — 패키지명은 *Kotlin 키워드/구현 타입*이 아니라 *도메인 응집*으로. `card/`, `participant/`, `game/`처럼.
+
+### 12. `interface Participant`로 중복 제거 — `abstract`는 고려 안 함
+
+```kotlin
+interface Participant {
+    val cards: List<TrumpCard>
+    val sumOfCards: Int
+    fun addCard(card: TrumpCard)
+    // 모든 구현이 _cards mutableListOf + 같은 본문 — 중복 폭증
+}
+```
+
+리뷰어: "`딜러와 플레이어에서 발생하는 중복 코드를 제거해야 한다.` 을 지키기 위해서 interface를 선택한 것 같은데요. abstract도 있는데 페토가 생각했을 때 왜 interface를 선택했는지가 궁금하네요." — `interface`는 *공통 행위 계약*이고 *상태 공유*는 보장하지 않음. 그래서 `_cards`, `addCard`, `hasAce` 같은 *공통 구현*이 두 곳에 복제됨. `abstract class Participant`로 *상태 + 기본 구현* 공유가 자연. 학생도 자가 인정: "인터페이스의 모든 멤버는 가시성이 `public` [...] 추상 클래스는 `protect`를 사용해 가시성 변경이 가능 [...] 추상 클래스를 사용해 리팩토링하겠습니다 !"
+
+### 13. `Player.isBust` vs `Dealer.isBust` — 같은 이름, 다른 룰
+
+```kotlin
+class Player : Participant {
+    override fun isBust(): Boolean = sumOfCards > BUST_STANDARD               // 21 초과
+    private fun isBustByMaxAce(): Boolean = sumOfCards + ACE_EXTRACT_SCORE > BUST_STANDARD
+}
+
+class Dealer : Participant {
+    override fun isBust(): Boolean = sumOfCards + ACE_EXTRACT_SCORE > BUST_STANDARD  // ACE 보정 적용
+}
+```
+
+`Player.isBust`는 *raw sum > 21*, `Dealer.isBust`는 *ACE 보정 적용*. *같은 함수명에 다른 룰*은 *Liskov 위반*. 인터페이스 계약을 *명확히 정의*하거나 *둘 다 ACE 보정 후 비교*로 통일해야.
+
+### 14. `Player`가 점수 계산까지 — 카드 컬렉션 분리 안 함
+
+리뷰어: "플레이어가 직접 점수를 계산할 수도 있지만, 카드를 관리하면서 점수를 계산하는 역할을 분리할 수도 있을 것 같은데 페토는 어떻게 생각하나요?" — `Hand`/`Cards` 일급 컬렉션이 *카드 보유 + 점수 계산*을 갖고, `Player` 는 *결정 + 이름*만. 학생도 자가 인정: "다른 크루들 의견을 들어보니 카드 리스트를 관리하는 일급 컬랙션이 있더라구요 ! 저도 말씀해주신 역할들을 하는 카드 리스트 일급 컬랙션이 있으면 어떨까 고민했습니다."
+
+### 15. `playGame` 안의 `if (player.cards.size == 2) onPlayerStateUpdated(player); break` — 매직 조건
+
+```kotlin
+fun playGame(getPlayerChoice: (String) -> UserChoice, onPlayerStateUpdated: (Player) -> Unit) {
+    participants.players.forEach { player ->
+        while (!player.isBust()) {
+            val choice = getPlayerChoice(player.name)
+            when (choice) {
+                UserChoice.HIT -> player.addCard(deck.pop())
+                UserChoice.STAY -> {
+                    if (player.cards.size == 2) { onPlayerStateUpdated(player) }
+                    break
+                }
+            }
+            onPlayerStateUpdated(player)
+        }
+    }
+}
+```
+
+`player.cards.size == 2` 라는 *매직 조건*이 *무엇을 의미하는지* 불명. *초기 손패 = 2*라는 도메인 룰이 *루프 내부 조건*으로 누수. *상태 머신*(Ready/Hit/Stay/Bust)으로 표현하면 *size == 2*가 무의미해짐.
+
+## 리뷰어 의견 요지
+
+- **테스트 불가능 ≠ 좋은 캡슐화** — *비즈니스 룰 미포함*이 진짜 문제. *카드 소진 시 동작*은 비즈니스 룰.
+- **`Deck.pop()` vs `draw()`** — *클래스 이름으로 메서드 이름 추론 가능성*이 좋은 API.
+- **`getAllCards()` 같은 *get/실동작 불일치* 함수명** — private도 동사 정확성.
+- **인터페이스의 *공개 API 두 가지 점수 계산법*은 호출자 혼란** — `sumOfCards` private화 + `sum()`만 공개.
+- **`data class + mutable state`는 동치성 위험.**
+- **`val + get()` vs `fun`** — *상태 없는 계산*은 함수, *지속 상태*는 property.
+- **결과 *콜백 전달*보다 *return*** — 동기 계산은 단순 반환.
+- **`enum`에 *MutableMap 정적 저장*** — `entries.find` 한 줄로.
+- **상수의 *소속 클래스*** — *도메인 룰*인지 *역할별 룰*인지로 위치 결정.
+- **패키지명 = 도메인 응집, 구현 타입 X.**
+- **`interface` vs `abstract class`** — 상태 공유면 abstract.
+
+## 대표 인용
+
+> 캡슐화를 하다 보면 내부 구현 로직을 최대한 숨기게 되니 테스트가 불가능해집니다. 물론 그 캡슐화된 로직은 테스트가 필요가 없게끔 짜는 것이 중요합니다. [...] 1. 참여자를 10명 정도 설정한다. 2. 다들 계속 카드를 받는다. 3. ??? 3번에서 어떠한 상황이 발생하는지부터 생각해 봅시다. 이 클래스가 정말 테스트가 필요 없을까요?
+> — @lee-ji-hoon on `src/main/kotlin/blackjack/domain/Deck.kt`
+
+> 좋은 API는 사용자가 당신의 클래스 이름만 보고도 모든 메서드 이름을 맞출 수 있어야 합니다 라는 측면에서 pop이 어울리신가요? draw가 어울릴까요?
+> — @lee-ji-hoon on `src/main/kotlin/blackjack/domain/Deck.kt`
+
+> getAllCards 함수만 생각했을 때 이 함수가 호출이 될 때 뭔가 문제가 있어 보이지 않나요? 1. 이 함수가 정말 get인가? 2. 누군가 유지보수 할 때 이 함수를 잘못 쓰면 어떻게 될까?
+> — @lee-ji-hoon on `src/main/kotlin/blackjack/domain/Deck.kt`
+
+> 패키지명은 대략적으로 집합체에 대한 성격을 나타내는 것을 노력해보시면 좋을 것 같습니다. 패키지에서 어떻게 구현이 되었던 그건 패키지의 관심사가 아닙니다.
+> — @lee-ji-hoon on `src/main/kotlin/blackjack/domain/enums/CardTier.kt`
+
+> `Dealer`만 판단해야 할 값이 아니니 어디가 적합했을지 고민을 해보면 바로 답이 나올 것 같네요!
+> — @lee-ji-hoon on `src/main/kotlin/blackjack/domain/participant/Dealer.kt` (Dealer.Companion의 ACE_EXTRACT_SCORE)
+
+## 얻은 교훈
+
+- **테스트 불가능 코드가 *항상 잘 캡슐화된 것*은 아니다.** 학생의 *의도적 테스트 불가능* 설계는 *카드 소진 시 동작*이라는 비즈니스 룰을 *잊게* 만들었음. *캡슐화된 로직은 테스트가 필요 없게* 짜야 한다는 원칙은 *룰을 빠뜨리지 않았을 때*만 성립.
+- **함수명 = 클래스 이름에서 추론 가능해야** — `Deck.draw()`가 `Deck.pop()`보다 *도메인 어휘 일치*. `pop()`은 자료구조 노출.
+- **`getXxx`가 *add 동작*하면 명백한 안티패턴** — `private`이라도 *동사-동작 일치*는 동일.
+- **인터페이스에 *내부 계산 단계*를 공개하지 말 것** — `sumOfCards`(raw) + `sum()`(보정)이 둘 다 공개면 호출자가 혼란. *최종 결과*만 공개.
+- **`data class + mutable state` = 동치성 위험** — `data class`는 *값 객체*. 가변 손패를 가지면 *같은 이름인데 다른 손패*인 두 Player가 equals.
+- **`val + custom get()` vs `fun`** — *지속 상태*는 property, *순수 계산*은 function. *property로 보이는데 매 접근마다 계산*은 호출자 오해.
+- **결과는 *return*, callback은 *비동기/이벤트*에서만** — 동기 계산을 콜백으로 전달하면 *반환값 추적*이 어려워지고 *도메인 → View* 의존이 숨음.
+- **패키지명 = 도메인 응집, 구현 타입 회피** — `enums/`, `interfaces/`는 *Kotlin 어휘*. `card/`, `participant/`, `game/`처럼 *도메인 응집*.
+- **`enum`에 *MutableMap 정적 저장*은 과잉** — `entries.find { ... }` 한 줄.
+- **블랙잭 룰 상수(`ACE_EXTRACT_SCORE`, `BUST_STANDARD`)는 *역할 클래스*가 아닌 *Card/Game 수준*** — `Dealer.Companion`에 두면 *Dealer가 룰의 소유자*라는 오해.
+- **공통 행위 + 상태 공유는 `abstract class`** — `interface`는 *행위 계약*만. 모든 구현이 `_cards mutableListOf<>()`를 복제하면 *추상 클래스 신호*.
+- **`Player.isBust` vs `Dealer.isBust` 룰 차이 = Liskov 위반 신호** — 인터페이스에 *서로 다른 룰*을 같은 함수명으로 두지 말 것.
+- **`player.cards.size == 2` 매직 조건은 *상태 머신 부재 신호*** — Ready/Hit/Stay/Bust를 sealed로 두면 *size == 2* 같은 *기수 비교*가 사라짐.