oh-my-oop 0.2.0

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

@@ -0,0 +1,900 @@
+# PR #87 — [블랙잭 2단계] 레오 미션
+
+- **Reviewee:** [@jaeyeongjo](https://github.com/jaeyeongjo)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/87
+- **단계:** 2단계
+- **리뷰어:** [@ghojeong](https://github.com/ghojeong) (파이로) — 1단계 #73 동일 reviewer (학생-reviewer 페어 안정)
+- **라인 코멘트:** 22 스레드 — *State Context 책임 명시 (State ↔ Context 양방향 참조 회피) + `is` 연산자 회피 (SOLID 위반 + 외부글) + 디미터 법칙 (외부글) + 테스트 = 객체 설계 명세서 어휘 (역할·책임·협력) + ParticipantInfo sealed class 의도 자가 답변 (3변수 제약) + WinningState 매직 넘버 → State 분리*
+- **양 단계 완성 reviewee** (1단계 #73 batch 18 분석 완료 + 2단계 #87 = batch 19 추가).
+
+## 잘한 점 (설계 관점)
+
+### 1. `sealed class ParticipantState` + 3개 자식 (Blackjack/Bust/Normal) — 진정한 State 패턴
+
+```kotlin
+sealed class ParticipantState(private val hand: Hand, private val info: ParticipantInfo) {
+    abstract val isBlackjack: Boolean
+    abstract val isBust: Boolean
+    abstract val isFinished: Boolean
+    
+    abstract fun calculateGameOutcome(opponent: ParticipantState): GameOutcome
+    abstract fun drawCard(card: Card): ParticipantState
+    ...
+}
+
+class Blackjack(hand: Hand, info: ParticipantInfo) : ParticipantState(hand, info) {
+    override val isBlackjack = true
+    override val isFinished = true
+    override fun calculateGameOutcome(opponent: ParticipantState): GameOutcome {
+        if (opponent.isBlackjack) return GameOutcome.Tie
+        return GameOutcome.WinWhenBlackjack
+    }
+    override fun drawCard(card: Card): ParticipantState = this
+}
+```
+
+→ **State 자식들이 *abstract 함수 2개* 구현** (`calculateGameOutcome` + `drawCard`) — *Tell-Don't-Ask + 다형성*. PR #93·#136·#152·#98 결의 *State 자식 책임 부여* 정공.
+
+reviewer 칭찬: *"State 에 다형성을 활용할 수 있게 abstract 문법을 더 적극적으로 활용해주셨군요 👍"* + *"Participant 가 ParticipantState 의 명시적인 Context 가 되었군요 👍 덕분에 State 를 관리하는 책임이 누구인지가 더 명확해진 것 같습니다."*
+
+reviewer 메타 어휘:
+
+> *"객체 설계의 핵심은 '역할', '책임', '협력' 입니다."*
+
+→ **조영호 「객체지향의 사실과 오해」 + Wirfs-Brock RDD 핵심 어휘**. *MCP `oh-my-oop` 의 책임 주도 설계 어휘 정점*.
+
+### 2. State Context 책임 명시 — Participant 가 ParticipantState 의 Context
+
+학생 자가 답변 (Thread 12):
+
+> *"상태는 ParticipantState하나이고 context는 participant입니다. GameState은 상태가 아닙니다! 혼란이 없게끔 코드를 다시 정리해서 푸시해보겠습니다!"*
+
+→ **State Context 어휘 자가 학습** — *1단계 #73 reviewer 권고 (Context = Participant) → 2단계 자가 적용*. **MCP `oh-my-oop` 의 *역할·책임·협력* 어휘 학생 합류**.
+
+reviewer 메타 어휘:
+
+> *"저는 상태를 분석할 때는 상태를 저장하고 관리하는 책임을 가진 Context 객체가 무엇인지 꼭 살펴봅니다. (...) ParticipantState 와 GameState 를 멤버로서 가지고 있는 객체는 없어보이고 매번 Lazy 하게 계산하는 듯이 보이는데, 레오가 생각하기에 ParticipantState 와 GameState 를 관리하는 책임을 가지는 객체는 누구일지 궁금해서 여쭈어봅니다."*
+
+→ **Context 책임 명시 = State 패턴 정공의 핵심**. PR #73 *Context 어휘 도입* → 2단계 *자가 적용*.
+
+### 3. State ↔ Context 양방향 참조 회피 — 순환 참조 의식
+
+reviewer (Thread 13):
+
+> *"만약 ParticipantState 의 Context 가 Participant 라면, ParticipantState 가 다시 Participant 를 파라미터로 받는 것은 서로를 쌍방향으로 참조하게 하여, 객체의 관계를 혼란스럽게 하지 않을까 하는 생각을 했습니다. opponent 대신에 같은 레벨의 opponentParticipantState 를 파라미터로 받는 것은 어떻게 생각하세요?"*
+
+학생: *"서로 쌍방향으로 참조하는 경우를 없애서 다시 푸시해보겠습니다!"*
+
+reviewer 후속 칭찬:
+
+> *"Participant 와 ParticipantState 가 서로를 쌍방향으로 참조하지 않도록 수정해주셨군요. 👍 객체설계를 할 때 순환참조가 일어날 수 있는 여지는 항상 조심하는 편이 좋다고 저는 생각합니다."*
+
+→ **양방향 참조 회피 + 같은 레벨 참조 권유**:
+
+```kotlin
+fun calculateGameOutcomeAgainst(opponent: Participant): GameOutcome = 
+    state.calculateGameOutcome(opponent.getState())
+```
+
+→ *Participant 끼리 외부 호출* → *내부에서 state.calculateGameOutcome(opponent.getState())* → *State ↔ State 같은 레벨 협력*.
+
+PR #93 (junjange 2단계 *State.compareTo 다형성*) 결 + PR #136 (whk06061 *State 자식 책임 부여*) 결.
+
+**MCP 룰 `state-context-bidirectional-reference` 후보** — *State 가 Context 를 파라미터로 받기 = 양방향 참조 안티패턴*.
+
+### 4. `data object` + `enum class GameOutcome` 칭찬
+
+```kotlin
+enum class GameOutcome(val scoreRecord: ScoreRecord, val payoutMultiplier: Double) {
+    WinWhenBlackjack(ScoreRecord(1, 0), 1.5),
+    Win(ScoreRecord(1, 0), 1.0),
+    Tie(ScoreRecord(0, 0), 0.0),
+    Lose(ScoreRecord(0, 1), -1.0),
+}
+```
+
+reviewer 칭찬 (Thread 11):
+
+> *"그렇지 않아도 언급을 하려고 했었는데, data object 를 enum 선언해주신 점은 저도 참 좋은 아이디어 같습니다! 👍"*
+
+→ **`enum class` 멤버에 `scoreRecord` + `payoutMultiplier` 2 속성 묶음**:
+
+- **블랙잭 1.5배 별도 멤버 `WinWhenBlackjack(ScoreRecord(1, 0), 1.5)`** — PR #36·#26·#147·#88·#93·#136·#152·#133 결. 누적 9+ PR ⭐⭐⭐.
+- **`ScoreRecord(wins: Int, losses: Int)` + `payoutMultiplier` 동시 담음** — *enum 값 = 합산 가능 데이터*.
+
+**MCP 룰 `enum-with-composite-state` 후보** — *enum 멤버에 여러 속성 묶음 + 합산 가능*.
+
+### 5. PR 본문 (간결) + 학생 자가 답변 6+ 회 풍부
+
+PR 본문은 1단계 #73 (자가 의문 2개) 와 달리 *"잘 부탁드립니다 !"* 1줄. 다만 **라인 코멘트에서 자가 답변 풍부**:
+
+- Thread 4: *3 파라미터 제약 자가 학습 답변* (ParticipantInfo 추상화).
+- Thread 12: *상태 vs Context 자가 정정*.
+- Thread 14: *ParticipantState 의 GameState Context 부적절* 자가 인정.
+- Thread 17: *테스트 커버리지 자가 의문*.
+- Thread 19: *디미터 법칙 자가 깨달음* (*"state에 필요한 함수를 생성해주고, Pariticipant는 state에게 요청을 하는듯하게 리팩토링하면 되겠군요!"*).
+- Thread 22: *테스트 커버리지 자가 의문 → 자가 깨달음*.
+
+→ **학생 자가 토론 풍부 = 1100~1400 줄 분량 휴리스틱** + *학생 자가 답변 = 학습 가시화 모범*. PR #128·#135·#111·#120·#29·#63·#137·#148·#151·#146·#147·#88·#36 결.
+
+### 6. `ParticipantInfo` sealed class 부모 — 3 파라미터 제약 자가 학습
+
+학생 자가 답변 (Thread 4):
+
+> ```kotlin
+> class Player(name: ParticipantName, hand: Hand) : Participant(name, hand)
+> ```
+>
+> *"기존 Player에 betAmount을 추가하는게 가장 간단하지만, 그럴 경우 클래스의 파라미터가 3개가 되어버려서, 파라미터 갯수를 2개이하로 유지하기 위해서 ParticipantInfo를 상속받는 PlayerInfo,DealerInfo을 구현했습니다..!"*
+
+reviewer 인정:
+
+> *"파라미터 갯수를 2개 이하로 유지해야한다는데 동의합니다! `ParticipantInfo` 와 관련된 리뷰는 수정 요청이 아니라, 코드를 읽는 동료가 이런 부분을 궁금해할 수도 있구나! 라는 경험으로 생각하고 넘어가셔도 좋을 것 같습니다."*
+
+→ **3 변수 제약 부산물 인공 객체 (ParticipantInfo / PlayerInfo / DealerInfo)** — *형식 규칙이 만든 인공 객체*. PR #133·#88·#132·#136·#93 누적 결.
+
+**다만 reviewer 인정 = *동료 개발자 시점 메타 어휘***:
+
+> *"코드를 읽는 동료가 이런 부분을 궁금해할 수도 있구나!"*
+
+→ **동료 개발자 시점 어휘 (maintainer perspective locator)** 합류. PR #91·#107·#147·#22·#73·#76·#80·#82·#11·#13 결의 *동료 개발자 시점*.
+
+### 7. 추가 칭찬
+
+- **Player 추가 테스트 꼼꼼하게 작성 👍 어플리케이션 돌려보기 전에 미션 요구사항 만족 확인** (Thread 8).
+- **Participants 의 playRound/playRoundForPlayers/playRoundForDealer → BlackjackController 로 이동** (Thread 10) — model → view 의존성 분리 자가 적용.
+
+## 못한 점 (설계 관점)
+
+### 1. `is` 연산자 회피 — SOLID 위반 + 외부글
+
+reviewer (Thread 15):
+
+> *"이건 정말 도전해 볼만한 내용이라서 말씀 드리는데, 클래스 타입에 대한 is 연산자를 사용하지 않도록 리팩토링해주세요. `OutputView.printGameResult` 를 포함하여 클래스 타입을 통한 조건 분기가 필요할 것 같으면, 차라리 Boolean 맴버 혹은 enum 맴버를 하나 더 추가하는 형식으로 리팩토링 부탁드립니다. 추가할 경우에는 파라미터 혹은 맴버의 갯수가 2개 이하가 되도록 객체 설계를 다시 고민해주시고요.*
+>
+> *코틀린의 is 처럼 자바에는 instanceof 연산자가 있는데, [왜 직접적인 클래스 타입 체크가 SOLID 원칙에 좋지 않은지](https://tecoble.techcourse.co.kr/post/2021-04-26-instanceof/)에 관한 글을 공유해봅니다."*
+
+학생: *"is 연산자를 사용하지 않고, 구현해보겠습니다!"*
+
+→ **`is` 클래스 타입 분기 = SOLID 위반 (OCP) + 외부글**:
+
+#### 1.1. *`is` 연산자 회피 = 다형성 권유*
+
+현재 코드 (위 `Bust.calculateGameOutcome`):
+
+```kotlin
+override fun calculateGameOutcome(opponent: ParticipantState): GameOutcome {
+    if (this.getInfo().isDealer() && opponent.isBust) return GameOutcome.Win
+    return GameOutcome.Lose
+}
+```
+
+→ *`this.getInfo().isDealer()` Boolean 분기* = *State 패턴 안에서 다시 *Participant 타입* 분기*. **State 패턴 의도 누수**.
+
+#### 1.2. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `is` (현재) | *간결 + Kotlin smart cast* | *SOLID OCP 위반 + 자식 추가 시 분기 누락 위험* |
+| Boolean 멤버 (`isDealer`) | *접근 일정 + Kotlin when 활용* | *플래그 폭증 + 의도 의미 약함* |
+| 다형성 (자식 추상 메서드) | *진정한 State 패턴 + 자식 추가 시 컴파일러 강제* | *추상 메서드 시그니처 설계 필요* |
+
+reviewer 권유 = *Boolean 멤버 + enum 멤버 2 안* — *다만 다형성 안으로 가는 게 가장 정공*.
+
+#### 1.3. *외부글 = tecoble instanceof + SOLID 원칙*
+
+reviewer 외부 자료 `tecoble.techcourse.co.kr/post/2021-04-26-instanceof/` — **외부 자료 활용 메타 어휘**. PR #36·#23·#26·#108·#136·#151·#146·#148·#93·#133 결의 *외부 자료* + *학생 자가 학습*.
+
+**MCP 룰 `is-operator-polymorphism-avoidance` 강화** — 누적 6+ PR (#147·#87·#136·#152·#93·#98). ⭐⭐⭐.
+
+### 2. 디미터 법칙 적용 — Participant → state → ... 깊게 타고 내려감
+
+reviewer (Thread 19):
+
+> *"Participant 가 ParticipantState 의 명시적인 Context 가 되었군요 👍 덕분에 State 를 관리하는 책임이 누구인지가 더 명확해진 것 같습니다. 다만 필요한 기능을 state 에서 함수로 제공하고 있지 않아, 깊게 타고 내려가는 것 같습니다. [디미터 법칙](https://tecoble.techcourse.co.kr/post/2020-06-02-law-of-demeter/) 을 고려해서 State 가 제공해야할 기능을 기반으로 함수들을 리팩토링 해주셨으면 합니다."*
+
+학생 자가 깨달음:
+
+> *"그렇네요..! 개선하겠습니다 / state에 필요한 함수를 생성해주고, Pariticipant는 state에게 요청을 하는듯하게 리팩토링하면 되겠군요!"*
+
+→ **디미터 법칙 + 외부글 + 학생 자가 깨달음** — *Tell-Don't-Ask 변형* 어휘:
+
+#### 2.1. *깊게 타고 내려가는 = 의존 깊이 ↑*
+
+현재 코드 (`Participant.getName()` → `state.getName()` → `info.getName()` → `name`):
+
+```kotlin
+sealed class Participant(private var state: ParticipantState) {
+    fun getName() = state.getName()
+    fun getCards() = state.getCards()
+    fun getCardsSum() = state.getCardsSum()
+    ...
+}
+```
+
+→ *Participant → state → info → name* = *3 단계 위임*. **디미터 법칙 위반 (a.b.c.d 호출)**.
+
+#### 2.2. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Participant 가 state 위임 (현재) | *State 가 Context 역할 명확* | *위임 메서드 N개 + 깊게 타고 내려감* |
+| Participant 가 직접 멤버 (name, hand) | *호출 1 단계* | *State 분리 의도 약화* |
+| State 가 메시지 던지기 (`state.printSelf()`) | *Tell-Don't-Ask + 다형성* | *View 호출 메서드를 State 가 가짐 → View 결합* |
+
+reviewer 권유 = **State 가 제공해야 할 기능 = 메시지 던지기** — *Tell-Don't-Ask 정공*.
+
+#### 2.3. *외부글 = tecoble 디미터 법칙*
+
+reviewer 외부 자료 `tecoble.techcourse.co.kr/post/2020-06-02-law-of-demeter/` — 누적 4+ PR (#93·#133·#146·#87).
+
+**MCP 룰 `law-of-demeter-violation-depth` 강화** — 누적 6+ PR ⭐⭐.
+
+### 3. 테스트 = 객체 설계 명세서 어휘 — 역할·책임·협력 메타 어휘
+
+학생 자가 의문 (Thread 17 + 22):
+
+> *"Participant의 calculateGameOutcomeAgainst을 테스트 함으로서, ParticipantState의 calculateGameOutcome을 테스트했다고 생각했는데, 혹시 제 생각이 잘못됐을까요 ?"*
+
+reviewer 메타 어휘:
+
+> *"ParticipantState 를 포함해서 테스트를 추가로 작성해달라는 요청은, 테스트 커버리지에 관련된 피드백이 아니라, 객체 설계에 관련된 피드백이라고 생각해주시면 좋을 것 같습니다.*
+>
+> *객체 설계의 핵심은 '역할', '책임', '협력' 입니다. 만약 Participant 의 테스트 만으로 ParticipantState 와 Participants 를 테스트할 게 없다면, 결국 ParticipantState 와 Participants는 Participant 에 굉장히 의존적인 역할을 가지고 있거나, 심지어 Participant 외에 Participants 혹은 ParticipantState 은 역할이 존재하지 않는 객체 설계라고 말할 수 있습니다.*
+>
+> *기능적인 면에서는 분영 Participant 에 테스트를 굉장히 잘 작성해주셨지만, 그렇다면 ParticipantState 와 Participants 의 역할은 무엇이고, Participant 와 어떻게 협력하고 있는지 표현해달라는 의미에서 테스트 코드의 작성을 부탁드렸습니다.*
+>
+> *테스트 코드는 커버리지를 통과하는 것보다, 이 객체를 앞으로 어떻게 유지보수할 것인지 동료 개발자에게 안내하는, 역할 및 책임에 관한 명세서로서 매우 유용하다는 점을 말씀 드리고 싶었습니다."*
+
+reviewer 후속:
+
+> *"모든 함수에 대한 테스트를 작성할 필요는 없지만, 최소한 이 객체는 어떠한 역할을 기대하고 만들었다는 의도를 표현할 수 있는 테스트가 객체 별로 존재했으면 해서 요청을 드렸습니다."*
+
+학생 자가 깨달음:
+
+> *"생각해보니 calculateResult와 calculateFinalProfits만의 로직이 있기때문에, 따로 테스트가 필요해보입니다..! 반영해서 푸시하겠습니다"*
+
+→ **테스트 = 객체 설계 명세서 + 역할·책임·협력 어휘** — *Wirfs-Brock RDD 핵심 어휘* + **MCP `oh-my-oop` 핵심 가치 정점**.
+
+#### 3.1. *테스트 = 객체 설계 명세서*
+
+PR #26 (chws0508 1단계 *테스트 = 명세서*) 결 강화. *테스트가 객체 의도 + 역할 표현*.
+
+#### 3.2. *역할·책임·협력 = 객체 설계의 핵심*
+
+**조영호 「객체지향의 사실과 오해」 핵심 어휘** — *역할 (객체의 추상), 책임 (객체의 기능), 협력 (객체간 관계)*.
+
+#### 3.3. *Participant 만 테스트 시 ParticipantState/Participants 의 역할이 의존적/없음 시사*
+
+reviewer 의 진단: *테스트 작성 가능 여부 = 객체 역할 존재 여부 지표*. **MCP `oop_design_validate` 룰 후보 `no-role-no-test-no-design`**.
+
+→ **MCP 룰 `test-as-design-spec` 강화** — *테스트 가 객체 역할 표현* 어휘. 누적 3+ PR (#26·#87·#93). ⭐⭐⭐.
+
+### 4. `WinningState(1, 0)` 매직 넘버 → State 정의
+
+reviewer (Thread 7):
+
+> *"`WinningState(1, 0)` 와 `WinningState(0, 1)` 에 쓰인 1 과 0 모두 매직 넘버로 보입니다. 기왕 State 라는 네이밍을 할거고, WinningState 기반으로 분기처리 로직을 사용할 거라면, `WinningState(1, 0)` 인 경우와 `WinningState(0, 1)` 경우에 대한 State 를 Bust, Normal 의 경우처럼 따로 정의해주시는게 좋지 않을까 생각했습니다. 기왕 State 디자인패턴을 활용해주시고 계신데, WinningState 라는 data class 로 조건문 분기처리를 하고 있으니, 전부 State 로 합칠 수 있지 않을까 해서 제안해보았습니다."*
+
+학생: *"GameState를 따로 만들어서, 한번 개선해봤습니다!"*
+
+→ **매직 넘버 = State 정의 (Win / Lose / Tie)** — `data class WinningState(wins: Int, losses: Int)` → `enum GameState { WIN; LOSE; TIE }` 또는 *sealed class*.
+
+학생은 *GameState 따로 만듦* → 다만 reviewer 의 (Thread 12 + 14) 의 후속: *ParticipantState 는 상태, GameState 는 *상태 아님* (Lazy 계산)*.
+
+#### 4.1. *Lazy 계산 = Context 멤버 X*
+
+reviewer:
+
+> *"현재 ParticipantState 와 GameState 를 멤버로서 가지고 있는 객체는 없어보이고 매번 Lazy 하게 계산하는 듯이 보이는데, 레오가 생각하기에 ParticipantState 와 GameState 를 관리하는 책임을 가지는 객체는 누구일지 궁금해서 여쭈어봅니다. Participant 혹은 Participants 인가요?"*
+
+→ *Context 가 State 멤버로 보관 vs Lazy 계산* 의 차이. *블랙잭 도메인에서 GameState 는 결과 (한 번 계산) → Context 멤버 보관 의미 X = State 아님*. 학생 자가 인정.
+
+#### 4.2. *State 와 Value Object 구분*
+
+reviewer (Thread 12):
+
+> *"현재 제가 느끼기에 WinningState 는 Value Object 로서 활용되고 있고, '상태' 라고 부를 수 있는 것은 `sealed class ParticipantState` 와 `enum class GameState` 이 두가지라고 판단했습니다."*
+
+→ **State (상태) vs Value Object 명시적 구분** — *State 는 시간에 따라 변하는 것 + Context 에서 관리, Value Object 는 불변값*.
+
+**MCP 룰 `state-vs-value-object` 후보** — *State 디자인 패턴 적용 vs Value Object 적용 차이*. 누적 2+ PR (#87·#136).
+
+### 5. model → view 의존성 — MVC 핵심 원칙
+
+reviewer (Thread 6):
+
+> *"model 은 **절대로** view 에 대해서 의존성을 가져서는 안됩니다. MVC 의 핵심은 model 을 view 로부터 의존성을 분리시키는데 있습니다. 앞으로 MVP, MVVM 등의 디자인패턴을 도입하게 되더라도, model 이 view 에 의존성을 가지면 안된다는 원칙은 꼭 지켜주시기 바랍니다."*
+
+학생: *"넵 ! 모델과 뷰를 분리하겠습니다"*
+
+→ **MVC 원칙 절대성 어휘**. **MCP 룰 `model-view-dependency-direction` 강화** — *Domain → UI X / UI → Domain OK*. 누적 7+ PR.
+
+PR #88·#80·#76·#93·#107·#137·#90 결.
+
+### 6. `mutableMap` → `fold` 권유 — 함수형
+
+reviewer (Thread 21):
+
+> *"현재 최종 결과를 계산하기 위해 mutableMap 을 사용하고 있는데, 저는 이런 종류의 계산에는 fold 를 사용하면 mutable 한 요소를 없앨 수 있다고 생각합니다. 만약 어렵다면 욕심내지 않으셔도 된다고 생각합니다! 지금도 충분하니 mutable 을 없앨 수도 있다! 정도로 생각하고 넘어가시면 충분할 것 같습니다."*
+
+학생: *"아...그렇군요! fold를 사용해본적이없어서, 몰랐습니다! 찾아서 공부해보겠습니다"*
+
+```kotlin
+fun calculateResult(): Map<Participant, ScoreRecord> {
+    val result = mutableMapOf<Participant, ScoreRecord>()
+    players.forEach { player ->
+        calculateDealerResult(result, player)
+        calculatePlayerResult(result, player)
+    }
+    return result.toMap()
+}
+```
+
+→ **현재 mutableMap + forEach + 외부 함수에 result 전달** = *명령형*. **`fold` 대안**:
+
+```kotlin
+fun calculateResult(): Map<Participant, ScoreRecord> =
+    players.fold(mapOf<Participant, ScoreRecord>()) { acc, player ->
+        acc + dealerRecordFor(acc, player) + (player to player.calculateGameOutcomeAgainst(dealer).scoreRecord)
+    }
+```
+
+#### 6.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| mutableMap + forEach (현재) | *읽기 자연* + *디버깅 쉬움* | *mutable 누수 + 함수 분리 시 result 전달* |
+| `fold` | *immutable + Kotlin 함수형* | *acc + 새 항목 추가 어휘 익숙도 필요* |
+
+reviewer 의 *"욕심내지 않으셔도 된다"* = *학생 학습 시간 인정* + *현재 안 OK*. PR #95·#23·#26·#36 결의 *학생 선택지 분리* 어휘.
+
+**MCP 룰 `mutable-collection-vs-fold` 후보** — *명령형 mutableMap vs 함수형 fold*.
+
+### 7. Higher Order Function 추상화 — setup* 3개 모델로 이동
+
+reviewer (Thread 5):
+
+> *"readBetAmount 를 인터페이스 혹은 람다로 추상화해서, Higher Order Function 형태의 파라미터로 넘겨받으면, setupParticipants, setupDealer, setupPlayers 3개를 모두 model 의 영역으로 옮길 수 있지 않을까 해서 제안을 해봅니다."*
+
+reviewer 후퇴:
+
+> *"다시 생각해보니 이 피드백은 과한 감이 있다는 생각이 들어서 반영해주시지 않아도 괜찮습니다!"*
+
+→ **reviewer 자가 후퇴 어휘** — *학생 부담 최소화*. PR #95·#23·#26 결의 *개인 의견 + 학생 선택지 분리*.
+
+#### 7.1. *Higher Order Function 추상화 시점 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Controller 에서 setup (현재) | *Controller 책임 명확* | *Controller god-object 위험 + 모델 로직 누수* |
+| Higher Order Function 으로 model 이동 | *모델 책임 강화 + Controller 가벼움* | *model 이 람다 의존 + 추상화 깊이 ↑* |
+
+reviewer 후퇴 = *현재 안 OK + 미래 학습 시점 명시*.
+
+**MCP 룰 `setup-locus-controller-vs-model` 후보** — *setup 로직 위치 트레이드오프*.
+
+### 8. `Aginst` 오타 — 명명 정확성
+
+reviewer (Thread 1):
+
+> *"Aginst 가 아무리 보아도 오타같아서 언급을 해봅니다."*
+
+학생: *"오타네요.. 수정하겠습니다!"*
+
+→ **명명 정확성**. *영어 사전 어휘 정확*. PR #23 (rhthrhrl0 *Drawer = 서랍 영어 사전 의미 충돌*) 결.
+
+**MCP 룰 `english-spelling-naming` 후보** — *영문 명명 오타 점검*.
+
+### 9. `ParticipantInfo` sealed class — reviewer 자가 의문 + 학생 자가 답변
+
+reviewer (Thread 2):
+
+> *"data class 에 대하여 굳이 부모 sealed class 인 `ParticipantInfo` 가 필요한지 저는 잘 이해가 가지 않아서 설명이 필요합니다. ParticipantInfo 에 재사용가능한 로직 혹은 인터페이스가 전혀 보이지 않기 때문입니다. 아마 `val name: ParticipantName` 을 재사용하고 싶어서 선언해주셨다고 이해했는데, 그로 인해서 어떤 부분이 간단해졌는지 레오가 생각하신 개선점이 궁금합니다. 가령 지금과 같은 상황에서 PlayerInfo 는 betAmount 에 접근하기 위하여, ParticipantInfo 로 추상화하지 못하고, 항상 PlayerInfo 로만 쓰게 될 것 같습니다."*
+
+reviewer (Thread 3):
+
+> *"`sealed class Participant` 에서 상속에 대비하여, ParticipantInfo 가 필요했다고 이해하면 될까요?"*
+
+학생: *"넵 맞습니다!"*
+
+reviewer:
+
+> *"그렇다면 저는 지금 구조 납득이 가는 것 같습니다! 설명 감사합니다!"*
+
+→ **reviewer 자가 의문 → 학생 자가 답변 → reviewer 자가 인정**. **양방향 reviewer/학생 토론** 모범. PR #137·#151·#133·#146·#147 결.
+
+#### 9.1. *sealed class 의도 = 다형성 + 상속 대비*
+
+학생의 *Participant sealed class 자식 = Dealer/Player* 와 *ParticipantInfo sealed class 자식 = DealerInfo/PlayerInfo* = *대칭 구조* 의도.
+
+다만 **`ParticipantInfo` 의 *재사용 인터페이스 X (오직 name + isDealer + getBetAmount)*** = *상속이 추가 책임 부여 X* → **상속 인공 객체 위험**.
+
+#### 9.2. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| ParticipantInfo sealed (현재) | *Participant 와 대칭 + 3변수 제약 회피* | *추상화 인공 + getBetAmount 0 (DealerInfo) 의미 약함* |
+| Player(name, hand, betAmount) 3변수 | *간결 + Info 객체 불필요* | *3변수 제약 위반 + Player vs Dealer 비대칭 (betAmount 만 Player)* |
+| `data class Player(info: PlayerInfo, hand: Hand)` (Info 합성) | *2변수 + Info 분리 자연* | *Info 추상화 무용 (sealed 의미 약함)* |
+
+reviewer 후퇴 = *현재 안 OK + 동료 시점 코멘트*.
+
+**MCP 룰 `inheritance-without-shared-interface` 후보** — *재사용 인터페이스 X 인 sealed class = 인공 추상화*. 누적 3+ PR.
+
+### 10. `ParticipantInfo` `getBetAmount() = 0` (DealerInfo) — Dummy 값
+
+```kotlin
+class DealerInfo(...) : ParticipantInfo(...) {
+    override fun getBetAmount() = 0
+    ...
+}
+```
+
+→ **DealerInfo 의 getBetAmount = 0 = Dummy 값**. *Dealer 는 베팅하지 않음 도메인 의미를 *숫자 0 으로 표현* = *의미 누수***.
+
+대안: 
+- `getBetAmount(): Int?` (nullable) — *베팅 없음 명시*.
+- `sealed class ParticipantInfo { abstract val name; ... }` + Bet 관련 메서드는 PlayerInfo 한정 — *Dealer 호출 시 컴파일러 에러*.
+- *Dealer 에 baseAmount 멤버 X* — *호출 자리에서 Player/Dealer 분기*.
+
+**MCP 룰 `dummy-zero-for-domain-absent` 후보** — *도메인 부재를 0 으로 표현* (PR #131 (`-0.0` Double IEEE 754 함정) 결의 *Dummy zero* 변형).
+
+### 11. `ktlinCheck` 통과 X — 린트 안내
+
+reviewer (Thread 9):
+
+> *"`./gradlew clean ktlinCheck` 를 했을 경우 린트를 현재 통과하지 못하고 있는 것 같은데, 확인 부탁드립니다."*
+
+학생: *"앗 다시 학인해보겠습니다!"*
+
+→ **린트 도구 안내**. *CI 단계 자가 점검* 어휘. PR #80·#76·#107·#82·#147 결.
+
+**MCP 룰 X (도구 활용 메타 어휘)**.
+
+### 12. Participants 의 `calculateResult` / `calculateFinalProfits` 단위 테스트 X
+
+reviewer (Thread 22):
+
+> *"다만 Participants 에 관해서 단위테스트가 전혀 작성되어 있지 않은데, 테스트를 작성해주시면 좋을 것 같습니다."*
+
+→ §3 (테스트 = 객체 설계 명세서) 의 *Participants 테스트 부재 사례*. 학생 자가 깨달음.
+
+### 13. `Hand` `addCard` 가변 — Hand 멤버 mutable
+
+```kotlin
+class Normal(...) : ParticipantState(...) {
+    override fun drawCard(card: Card): ParticipantState {
+        getHand().addCard(card)  // ← Hand.addCard = mutable
+        return when {
+            getHand().calculateCardsSum() > THRESHOLD_BUST -> Bust(getHand(), getInfo())
+            else -> Normal(getHand(), getInfo())
+        }
+    }
+}
+```
+
+→ **State 자식이 mutable Hand 변경 + 새 State 반환** = *부분 immutable*:
+
+- *State 객체 자체는 immutable (Bust/Normal 새 인스턴스)*.
+- *Hand 내부는 mutable (addCard)*.
+
+reviewer 명시 X — 다만 *fold 권유 (§6) 와 같은 결의 함수형 어휘*. PR #93·#136·#152·#147·#137 결의 *immutable State + Hand mutable* 일치.
+
+#### 13.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Hand mutable + 새 State (현재) | *카드 추가 자연* | *State 자식이 Hand 변경 = 부작용* |
+| Hand immutable + Hand 새 인스턴스 | *완전 immutable* | *카드 1장 추가마다 새 List 복사 + GC 비용* |
+
+**MCP 룰 `partial-immutability` 후보** — *State 객체 immutable + 내부 자료구조 mutable* 트레이드오프.
+
+### 14. State `getHand()` `getCardsSum()` `getCards()` getter 4종 — 위임 깊이
+
+```kotlin
+sealed class ParticipantState(...) {
+    fun getHand() = hand
+    fun getInfo() = info
+    fun getCardsSum() = hand.calculateCardsSum()
+    fun getCards() = hand.getCards()
+    fun getName() = info.getName()
+    fun getBetAmount() = info.getBetAmount()
+}
+```
+
+→ **위임 메서드 6 개** = *§2 (디미터 법칙) 의 깊이 원인*. *State 가 Hand/Info 호출 위임*.
+
+대안: **State 가 일하는 메시지** (위 §2 권유):
+
+```kotlin
+sealed class ParticipantState {
+    abstract fun displayInitialCards(): List<Card>
+    abstract fun displayFinalScore(): String
+    abstract fun calculateProfit(opponent: ParticipantState, betAmount: Int): Double
+}
+```
+
+→ *getter 위임 X + 메시지 던지기*. **Tell-Don't-Ask 정공**.
+
+PR #93·#136·#137·#148·#152 결.
+
+### 15. `setupParticipants/setupDealer/setupPlayers` 분리 — Controller 책임 분산
+
+reviewer 메모 (Thread 5, §7 참조):
+
+> *"setupParticipants, setupDealer, setupPlayers 3개를 모두 model 의 영역으로 옮길 수 있지 않을까 해서 제안을 해봅니다."*
+
+→ **Controller 의 setup 3개 분산 = 책임 분할 의도** + *Model 이동 권유 (reviewer 자가 후퇴)*.
+
+#### 15.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Controller 3 분할 (현재) | *책임 명확 + 단위 함수 작음* | *Controller god-object 위험 + 모델 로직 외부 누수* |
+| Model 1 통합 + HoF | *모델 책임 강화* | *Model 람다 의존 + 추상화 ↑* |
+
+**MCP 룰 `controller-setup-split-vs-model-locus` 후보** — *setup 위치 트레이드오프*.
+
+### 16. State `companion object calculateInitialParticipantState` — 정적 헬퍼 vs State 다형성
+
+```kotlin
+companion object {
+    fun calculateInitialParticipantState(hand: Hand, info: ParticipantInfo): ParticipantState {
+        return when {
+            hand.calculateCardsSum() == THRESHOLD_BLACKJACK && hand.getCards().size == BLACKJACK_CARD_SIZE ->
+                Blackjack(hand, info)
+            hand.calculateCardsSum() > THRESHOLD_BUST -> Bust(hand, info)
+            else -> Normal(hand, info)
+        }
+    }
+}
+```
+
+→ **State 정적 팩토리** = *Bust/Normal/Blackjack 분기 외부 (companion)* + *초기 State 결정*. 
+
+#### 16.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 정적 팩토리 (현재) | *State 자식 단순 + Hand 점수 기반 결정 한 자리* | *분기 외부 = State 자식 의도 일부 누수* |
+| Normal 시작 + drawCard 자가 변환 | *State 자식이 자가 변환* | *초기 Blackjack 판정 (2장 21점) 처리 X* |
+
+reviewer 명시 X — *현재 안 OK + 의도 명확*.
+
+PR #36 (boogi-woogi *CardsState.valueOf(score, isInitialDraw)* 정적 팩토리) 결 동일.
+
+### 17. `Participant` `getBetAmount()` 위임 — Player/Dealer 분기 누락
+
+```kotlin
+sealed class Participant(...) {
+    fun getBetAmount() = state.getBetAmount()
+}
+
+class Dealer(state) : Participant(state) {
+    // getBetAmount() = 0 (state.info.getBetAmount() = 0)
+}
+```
+
+→ **Dealer.getBetAmount() = 0** = *DealerInfo.getBetAmount = 0 위임* (위 §10 참조).
+
+`calculateProfitAgainst` (Dealer):
+```kotlin
+override fun calculateProfitAgainst(opponent: Participant) =
+    -(opponent.getBetAmount() * (opponent.calculateGameOutcomeAgainst(this).payoutMultiplier))
+```
+
+→ *Dealer 의 수익 = -(상대 베팅 × 결과 배수)* = *상대 베팅을 가져옴*. **Dealer 가 *자기 베팅 0* 을 호출하지 않음** = *코드는 OK*.
+
+다만 *getBetAmount() 메서드 가 Participant 에 있음* = *Dealer 호출 시 0 반환 = 의미 누수* (위 §10).
+
+### 18. `Participant.getState()` getter — 디미터 위반 직접 노출
+
+```kotlin
+sealed class Participant(...) {
+    fun getState() = state
+}
+```
+
+→ **State 직접 노출 getter** — *Participant 외부에서 state 직접 접근* = *디미터 법칙 위반 + Encapsulation 부분 누수*.
+
+`calculateGameOutcomeAgainst`:
+```kotlin
+fun calculateGameOutcomeAgainst(opponent: Participant): GameOutcome = 
+    state.calculateGameOutcome(opponent.getState())
+```
+
+→ *Participant 가 opponent.getState() 직접 호출* = *§3 디미터 법칙 위반*.
+
+대안: **`Participant.calculateOutcomeWith(opponent: Participant)`** = *opponent 가 메시지 받아서 self.state 와 비교*:
+
+```kotlin
+fun calculateGameOutcomeAgainst(opponent: Participant): GameOutcome = 
+    opponent.compareStateWith(state)  // ← opponent 가 메시지 받음
+    
+fun compareStateWith(otherState: ParticipantState): GameOutcome =
+    state.calculateGameOutcome(otherState)
+```
+
+→ *getState() getter 불필요*. **Tell-Don't-Ask 정공**.
+
+PR #93·#136·#137·#148 결.
+
+### 19. `ParticipantState.isFinished` `isBlackjack` `isBust` — 부울 멤버 3개
+
+```kotlin
+abstract val isBlackjack: Boolean
+abstract val isBust: Boolean
+abstract val isFinished: Boolean
+```
+
+→ **Boolean 멤버 3 개 = *State 식별 변형***. *§1 (is 연산자 회피) reviewer 권유 = Boolean 멤버 추가* 와 일치.
+
+#### 19.1. *Boolean 멤버 vs 다형성 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Boolean 멤버 (현재) | *State 식별 간결 + 클래스 타입 분기 회피* | *플래그 폭증 (State 추가 시 N+1 flag) + 의도 약함* |
+| 다형성 추상 메서드 | *진정한 State 패턴* | *추상 시그니처 설계 필요* |
+
+reviewer 권유 = Boolean 멤버 + enum 멤버 (§1).
+
+**MCP 룰 `state-flag-vs-polymorphism` 후보** — *State Boolean 식별 vs 다형성*. 누적 4+ PR.
+
+### 20. `Participant.calculateProfitAgainst` 추상 + Player/Dealer 구현 차이
+
+```kotlin
+abstract fun calculateProfitAgainst(opponent: Participant): Double
+
+class Dealer(...) : Participant(...) {
+    override fun calculateProfitAgainst(opponent: Participant) =
+        -(opponent.getBetAmount() * (opponent.calculateGameOutcomeAgainst(this).payoutMultiplier))
+}
+
+class Player(...) : Participant(...) {
+    override fun calculateProfitAgainst(opponent: Participant) = 
+        getBetAmount() * (calculateGameOutcomeAgainst(opponent).payoutMultiplier)
+}
+```
+
+→ **Dealer.calculateProfitAgainst = -(상대 베팅 × 상대 결과)** vs **Player.calculateProfitAgainst = 자기 베팅 × 자기 결과**.
+
+#### 20.1. *대칭 깨짐*:
+
+- Player: *self.betAmount × self.outcome*.
+- Dealer: *-(opponent.betAmount × opponent.outcome)*.
+
+→ *Dealer 의 수익 = 모든 Player 의 수익 합의 부호 반전* (PR #36 *operator fun not() 부호 반전* 결).
+
+#### 20.2. *Tell-Don't-Ask 위반*
+
+`Dealer.calculateProfitAgainst` 가 *opponent.getBetAmount() × opponent.calculateGameOutcomeAgainst(this).payoutMultiplier* 호출 = *opponent 의 데이터 가져와서 계산*.
+
+대안: **`Player.calculateProfitAgainst` 의 부호 반전 활용** — `Participants.calculateFinalProfits` 에서 *Player 합 부호 반전*:
+
+```kotlin
+profits[dealer] = -players.sumOf { player -> player.calculateProfitAgainst(dealer) }
+```
+
+→ *Dealer.calculateProfitAgainst 불필요 → abstract 제거*.
+
+**MCP 룰 `tell-dont-ask-asymmetric-method` 후보** — *대칭 깨진 메서드 = 한쪽이 다른쪽 데이터 가져옴*.
+
+### 21. `Participant.drawCard` `Participant.isGameFinished` — `protected` 멤버
+
+```kotlin
+protected fun drawCard(card: Card) {
+    state = state.drawCard(card)
+}
+
+protected fun isGameFinished() = state.isFinished
+```
+
+→ **`protected` 멤버 = 자식 (Player/Dealer) 한정 접근**. *Player.playRound + Dealer.playRound 가 호출*.
+
+#### 21.1. *protected 활용 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| protected (현재) | *외부 호출 차단 + 자식 호출 OK* | *Kotlin 의 sealed class 한정 자식 = 사실상 internal* |
+| private + 자식이 메서드 재선언 | *완전 캡슐화* | *코드 중복* |
+| public + 외부 호출 가능 | *유연성* | *캡슐화 누수* |
+
+→ *현재 안은 sealed class + protected = 적절*. Kotlin 어휘 활용.
+
+### 22. `Participants` 의 `calculateDealerResult` 의 `MutableMap` 외부 전달
+
+```kotlin
+private fun calculateDealerResult(
+    result: MutableMap<Participant, ScoreRecord>,
+    player: Player,
+) {
+    val originalDealerGameOutcome = result.getOrDefault(dealer, DEFAULT_WINNING_STATE)
+    val addDealerGameOutcome = dealer.calculateGameOutcomeAgainst(player).scoreRecord
+    result[dealer] = ScoreRecord(...)
+}
+```
+
+→ **`MutableMap` 인자로 전달 + 함수 안에서 변경** = *부작용 함수 시그니처에 노출*.
+
+§6 (fold) 의 변형. PR #98·#43·#107·#137·#148·#76·#86·#73 결의 *명령형 mutable* 안티패턴.
+
+**MCP 룰 `mutable-collection-as-parameter` 후보** — *MutableMap/MutableList 외부 전달*.
+
+## 리뷰어 의견 요지
+
+- **State Context 책임 명시** — *State 를 저장/관리하는 책임 객체 = Context*. 학생 자가 답변: *상태 = ParticipantState 하나, Context = Participant, GameState 는 상태 아님*.
+- **State ↔ Context 양방향 참조 회피** — *State 가 Context 파라미터 받음 = 순환*. *opponentParticipantState* 또는 *isSelfDealer: Boolean* 권유.
+- **`is` 연산자 회피 = SOLID OCP** — 외부글 (tecoble instanceof).
+- **디미터 법칙 = State 가 메시지 던지기** — 외부글 (tecoble 디미터).
+- **테스트 = 객체 설계 명세서 + 역할·책임·협력** — *Wirfs-Brock RDD 어휘 정점*.
+- **WinningState 매직 넘버 → State 정의** — *State 디자인 패턴 도입 시 모든 분기 State 로*.
+- **`ParticipantInfo` 의도 자가 의문 → 학생 자가 답변** — *3 파라미터 제약 부산물 인공 객체 + reviewer 인정*.
+- **model → view 의존성 금지 = MVC 절대 원칙**.
+- **mutableMap → fold 권유** — *학생 부담 최소화 어휘 동반*.
+- **Higher Order Function 으로 setup 3개 모델 이동** — *reviewer 자가 후퇴*.
+- **`Aginst` 오타** — 명명 정확성.
+- **`ktlinCheck` 통과 X** — CI 도구.
+- **State abstract 적극 활용 칭찬 (수정 후)**.
+- **순환참조 회피 칭찬 (수정 후)**.
+- **Player 추가 테스트 꼼꼼 칭찬**.
+- **data object 를 enum 선언 칭찬**.
+
+## 대표 인용
+
+> [ghojeong]
+> *"객체 설계의 핵심은 '역할', '책임', '협력' 입니다. (...) 테스트 코드는 커버리지를 통과하는 것보다, 이 객체를 앞으로 어떻게 유지보수할 것인지 동료 개발자에게 안내하는, 역할 및 책임에 관한 명세서로서 매우 유용하다는 점을 말씀 드리고 싶었습니다."*
+
+→ **MCP `oh-my-oop` 핵심 가치 정점 어휘** — *조영호 「객체지향의 사실과 오해」 + Wirfs-Brock RDD 핵심 어휘*. **테스트 = 객체 설계 명세서** 어휘.
+
+> [ghojeong]
+> *"저는 상태를 분석할 때는 상태를 저장하고 관리하는 책임을 가진 Context 객체가 무엇인지 꼭 살펴봅니다. (...) 레오가 생각하기에 ParticipantState 와 GameState 를 관리하는 책임을 가지는 객체는 누구일지 궁금해서 여쭈어봅니다."*
+
+→ **State Context 책임 분석 메타 어휘**.
+
+> [jaeyeongjo 자가 답변]
+> *"상태는 ParticipantState하나이고 context는 participant입니다. GameState은 상태가 아닙니다! 혼란이 없게끔 코드를 다시 정리해서 푸시해보겠습니다!"*
+
+→ **학생 자가 State 정정 어휘**. *State vs 결과 (Lazy 계산) 구분 자가 깨달음*.
+
+> [ghojeong]
+> *"만약 ParticipantState 의 Context 가 Participant 라면, ParticipantState 가 다시 Participant 를 파라미터로 받는 것은 서로를 쌍방향으로 참조하게 하여, 객체의 관계를 혼란스럽게 하지 않을까 하는 생각을 했습니다. opponent 대신에 같은 레벨의 opponentParticipantState 를 파라미터로 받는 것은 어떻게 생각하세요?"*
+
+→ **양방향 참조 회피 어휘**.
+
+> [ghojeong]
+> *"다만 필요한 기능을 state 에서 함수로 제공하고 있지 않아, 깊게 타고 내려가는 것 같습니다. 디미터 법칙 을 고려해서 State 가 제공해야할 기능을 기반으로 함수들을 리팩토링 해주셨으면 합니다."*
+
+→ **디미터 법칙 + 메시지 던지기** 어휘.
+
+> [jaeyeongjo 자가 깨달음]
+> *"state에 필요한 함수를 생성해주고, Pariticipant는 state에게 요청을 하는듯하게 리팩토링하면 되겠군요!"*
+
+→ **학생 자가 Tell-Don't-Ask 깨달음** 어휘. *디미터 법칙 → Tell-Don't-Ask 자가 변환*.
+
+> [ghojeong]
+> *"`ParticipantInfo` 와 관련된 리뷰는 수정 요청이 아니라, 코드를 읽는 동료가 이런 부분을 궁금해할 수도 있구나! 라는 경험으로 생각하고 넘어가셔도 좋을 것 같습니다."*
+
+→ **동료 개발자 시점 어휘** (maintainer perspective locator). PR #91·#107·#147·#22·#73·#76·#80·#82·#11·#13 결.
+
+> [ghojeong]
+> *"이건 정말 도전해 볼만한 내용이라서 말씀 드리는데, 클래스 타입에 대한 is 연산자를 사용하지 않도록 리팩토링해주세요."*
+
+→ **`is` 연산자 SOLID 위반 + 도전 어휘**.
+
+> [ghojeong]
+> *"만약 어렵다면 욕심내지 않으셔도 된다고 생각합니다! 지금도 충분하니 mutable 을 없앨 수도 있다! 정도로 생각하고 넘어가시면 충분할 것 같습니다."*
+
+→ **reviewer 학생 부담 최소화 + 선택지 분리** 어휘. PR #95·#23·#26·#36 결.
+
+> [ghojeong]
+> *"다시 생각해보니 이 피드백은 과한 감이 있다는 생각이 들어서 반영해주시지 않아도 괜찮습니다!"*
+
+→ **reviewer 자가 후퇴** 어휘. *학생 부담 최소화 + 자가 의견 비판적 점검*.
+
+## 얻은 교훈 (보편)
+
+1. **State Context 책임 분석 = State 디자인 패턴 정공** — *Context = State 를 저장/관리하는 객체*. 학생 자가 합류. **MCP 룰 `state-context-locator` 후보**. 누적 4+ PR (#73·#87·#93·#136).
+
+2. **State ↔ Context 양방향 참조 회피** — *State 가 Context 파라미터 받음 = 순환 참조 + 객체 관계 혼란*. 같은 레벨 참조 (opponentState) 또는 단순 데이터 (Boolean) 권유. **MCP 룰 `state-context-bidirectional-reference` 후보**.
+
+3. **`is` 연산자 회피 = SOLID OCP 위반** — *Boolean 멤버 + enum 멤버 + 다형성 3 안*. 외부글 (tecoble instanceof). 누적 6+ PR. **MCP 룰 `is-operator-polymorphism-avoidance` 강화** ⭐⭐⭐.
+
+4. **디미터 법칙 = State 가 메시지 던지기 + Tell-Don't-Ask** — *a.b.c.d 깊이 = 위반*. 외부글 (tecoble 디미터). 학생 자가 Tell-Don't-Ask 자가 깨달음. 누적 6+ PR.
+
+5. **테스트 = 객체 설계 명세서 + 역할·책임·협력** — *Wirfs-Brock RDD 어휘 정점*. *테스트 작성 가능 여부 = 객체 역할 존재 여부 지표*. **MCP 룰 `test-as-design-spec` 강화** 누적 3+ PR ⭐⭐⭐.
+
+6. **`ParticipantInfo` 3변수 제약 부산물 인공 객체** — *형식 규칙이 만든 인공 추상화*. PR #133·#88·#132·#136·#93·#87 누적 결.
+
+7. **model → view 의존성 금지 = MVC 절대 원칙** — *MVC/MVP/MVVM 공통*. 누적 7+ PR.
+
+8. **mutableMap → fold = 명령형 vs 함수형** — *학생 부담 최소화 어휘 동반*. **MCP 룰 `mutable-collection-vs-fold` 후보**.
+
+9. **reviewer 자가 후퇴 + 학생 부담 최소화 + 선택지 분리** — *reviewer 가 자가 의견 비판적 점검*. **MCP `oop_propose_alternatives` 핵심 가치 합류**. 누적 12+ reviewer 어휘.
+
+10. **State vs Value Object 명시적 구분** — *State = 시간에 따라 변하는 것 (Context 멤버), Value Object = 불변값*. **MCP 룰 `state-vs-value-object` 후보**. 누적 2+ PR.
+
+11. **WinningState 매직 넘버 → State 정의** — *State 디자인 패턴 도입 시 모든 분기 State 로 + 단, Lazy 계산 = 상태 아님 구분*.
+
+12. **양방향 reviewer/학생 토론** — *reviewer 자가 의문 → 학생 자가 답변 → reviewer 자가 인정*. 누적 7+ PR.
+
+13. **동료 개발자 시점 어휘 (maintainer perspective locator)** — *코드를 읽는 동료가 이런 부분을 궁금해할 수도 있구나*. 누적 11+ PR ⭐⭐⭐.
+
+14. **State 자식이 abstract 함수 적극 활용 + 다형성 = 조건문 ↓** — *State 가 다양한 abstract 가지면 다형성으로 조건문 줄임*. 누적 6+ PR.
+
+15. **`Aginst` 오타 / 영문 명명 정확성** — *영어 사전 어휘 정확*. PR #23 결.
+
+16. **Higher Order Function 으로 setup 3개 모델 이동** — *Controller god-object 위험 vs 모델 책임 강화*. reviewer 자가 후퇴.
+
+17. **`protected` 멤버 = sealed class 자식 한정 접근** — Kotlin 어휘 활용.
+
+18. **순환 참조 회피 = 객체 관계 명확** — *수정 후 reviewer 칭찬*. 학생 자가 적용.
+
+19. **함수 명명 자가 답변 + 외부글 자가 학습** — *학생 자가 학습 가시화*. *학습 = 시간 두고 반복* 어휘.
+
+20. **Tell-Don't-Ask 의 부분 적용 = 부분 위반** — *State 가 getter 위임 6개 + 외부 가져옴*. *진정한 Tell-Don't-Ask = 메시지 던지기*.
+
+## 얻은 교훈 (도메인)
+
+1. **블랙잭 1.5배 별도 enum 멤버 `WinWhenBlackjack(ScoreRecord(1, 0), 1.5)`** — *enum 에 ScoreRecord + payoutMultiplier 묶음*. 누적 9+ PR ⭐⭐⭐.
+
+2. **블랙잭 룰 정확성**:
+- *Bust 양측 시 Dealer Win* (Dealer 21 초과는 *룰 위반이 아닌 자가 처리* → Player.Bust + Dealer.Bust = Dealer Win? *블랙잭 표준 룰은 Player Bust 즉시 Lose, Dealer Bust → Player Win*).
+- *현재 코드 `Bust.calculateGameOutcome` = `if (this.getInfo().isDealer() && opponent.isBust) return GameOutcome.Win` = *Dealer 가 Bust + Player 가 Bust → Dealer Win** = *룰 와전*?
+- *실제 블랙잭 룰*: Player Bust = 즉시 Player Lose (Dealer 의 결과와 무관). Dealer Bust = 모든 살아있는 Player Win.
+- 학생 자가 점검 필요 (reviewer 명시 X). **블랙잭 룰 정확성 점검 룰 후보**.
+
+3. **`ParticipantState.calculateInitialParticipantState`** — *2장 21점 = Blackjack, 21초과 = Bust (초기에 발생 X), else = Normal*. *isInitialDraw 플래그 없이 카드 size 체크* (PR #36 `isInitialDraw` 플래그 vs PR #87 `cards.size == 2` 체크 비교).
+
+4. **`Dealer.shouldDrawCardForDealer = getCardsSum() <= 16`** — *Dealer 자동 hit ≤16*. 블랙잭 표준 룰.
+
+5. **State 자식이 mutable Hand 변경 + 새 State 반환 = 부분 immutable** — *State 객체 immutable + 내부 Hand mutable*. **MCP 룰 `partial-immutability` 후보**.
+
+6. **`ParticipantBetAmount.MIN_BET_AMOUNTS = 1`** — *베팅 최소 1원*. 도메인 invariant. PR #36 (BattingMoney value > 0) 결.
+
+7. **`MAX_PLAYER_SIZE = 5`** — Participants invariant. 도메인 룰.
+
+## MCP 룰 후보 신규 + 강화 (PR #87)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `state-context-locator` | 신규 | 4 (#73·#87·#93·#136) — Context = State 관리 책임 |
+| `state-context-bidirectional-reference` | 신규 | 1 (#87) — State ↔ Context 양방향 참조 회피 |
+| `is-operator-polymorphism-avoidance` | 강화 | 6+ (#147·#87·#136·#152·#93·#98) |
+| `law-of-demeter-violation-depth` | 강화 | 6+ (#93·#133·#146·#87·#137·#148) |
+| `test-as-design-spec` | 강화 | 3+ (#26·#87·#93) ⭐⭐⭐ |
+| `inheritance-without-shared-interface` | 신규 | 3+ (#87·#147·#88) |
+| `dummy-zero-for-domain-absent` | 신규 | 2+ (#131·#87) |
+| `model-view-dependency-direction` | 강화 | 7+ |
+| `mutable-collection-vs-fold` | 신규 | 1 (#87) |
+| `mutable-collection-as-parameter` | 신규 | 1 (#87) |
+| `state-flag-vs-polymorphism` | 신규 | 4+ (#147·#87·#136·#152) |
+| `partial-immutability` | 신규 | 2+ (#87·#136) |
+| `state-vs-value-object` | 신규 | 2+ (#87·#136) |
+| `english-spelling-naming` | 신규 | 2+ (#23·#87) |
+| `setup-locus-controller-vs-model` | 신규 | 1 (#87) |
+| `tell-dont-ask-asymmetric-method` | 신규 | 1 (#87) |
+| `state-children-method-vs-external-when` | 강화 | 7+ (#93·#136·#152·#98·#36·#87) |
+| `blackjack-rule-fidelity` | 강화 | 9+ |
+| `enum-with-composite-state` | 신규 | 1 (#87) — enum 멤버에 여러 속성 묶음 |
+
+## 메타 어휘 (12 reviewer + MCP 핵심 가치 합류)
+
+- ***역할·책임·협력 = 객체 설계의 핵심*** — ghojeong PR #87 — *조영호 「객체지향의 사실과 오해」 + Wirfs-Brock RDD 핵심 어휘 합류*. **MCP `oh-my-oop` 핵심 가치 정점**.
+- ***테스트 = 객체 설계 명세서*** — ghojeong PR #87 — *테스트가 객체 의도 + 역할 표현*. PR #26 결 강화.
+- ***State Context 책임 분석 메타 어휘*** — ghojeong PR #87 — *State 를 저장/관리하는 책임 객체 = Context*.
+- ***reviewer 자가 후퇴 + 학생 부담 최소화*** — ghojeong PR #87 — *"다시 생각해보니 이 피드백은 과한 감이 있다는 생각이 들어서 반영해주시지 않아도 괜찮습니다!"* — **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+- ***동료 개발자 시점 어휘 (maintainer perspective locator)*** — ghojeong PR #87 — *"코드를 읽는 동료가 이런 부분을 궁금해할 수도 있구나!"*. 누적 11+ PR ⭐⭐⭐.
+- ***외부 자료 + 자가 학습*** — ghojeong PR #87 — tecoble instanceof + tecoble 디미터 법칙 2 외부글.
+- ***학생 자가 Tell-Don't-Ask 깨달음*** — jaeyeongjo PR #87 — *"state에 필요한 함수를 생성해주고, Pariticipant는 state에게 요청을 하는듯하게 리팩토링하면 되겠군요!"* — *디미터 법칙 → Tell-Don't-Ask 자가 변환*.
+- ***학생 자가 State 정정*** — jaeyeongjo PR #87 — *"상태는 ParticipantState하나이고 context는 participant입니다. GameState은 상태가 아닙니다!"* — *State vs 결과 (Lazy 계산) 구분 자가 깨달음*.
+
+## 비교 (PR #73 → #87 진화 — 사족 X, 안티패턴 명시만)
+
+- **1단계 #73 신규 reviewer ghojeong → 2단계 #87 동일 reviewer = 학생-reviewer 페어 안정** (2 PR 누적).
+- **1단계 State 디자인 패턴 사용 확인 → 2단계 State Context 책임 명시 + 자식 abstract 적극 활용 자가 적용** — *학습 시간성 + 자가 적용*.
+- **1단계 `Set vs List` (removeLast) → 2단계 `mutableMap vs fold`** — *명령형 vs 함수형 어휘 진화*.
+- **1단계 Hand 객체 분리 칭찬 → 2단계 State ↔ Hand 위임 깊이 (디미터 법칙)** — *Hand 분리 자가 적용 후속 학습 시점*.
+- **1단계 PR 본문 자가 의문 2개 → 2단계 라인 자가 답변 6+ 회 풍부** — *자가 학습 형식 변화*.
+
+→ *진화 비교 = 사족 아님 (안티패턴 코드 위치 명시)* + *State 패턴 학습 시간성 일관*.