oh-my-oop 0.2.0

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

@@ -0,0 +1,541 @@
+# PR #133 — [블랙잭 2단계] 시아 미션
+
+- **Reviewee:** [@Leeyerin0210](https://github.com/Leeyerin0210)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/133
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 23 스레드 / 46 코멘트
+
+## 잘한 점 (설계 관점)
+
+- **`Card` private constructor + `getCashed` 팩토리** — 1단계 *`operator fun invoke` + public class* 의 모호함 (말리빈: *"바이트코드 안 보면 호출 모름"*) 을 *private constructor + 명명된 팩토리*로 자가 해소. 학생 자가 인용: *"첫 의도는 52장의 카드 의외의 카드를 만들게 할 수 있게 하려고 하였으나, 정의되지 않은 카드가 추가되면 게임에 문제가 생길 수 있을 것 같아 기본 생성장를 프라이빗으로 변경하였습니다."*
+- **`Participant` interface (1단계 abstract class → 2단계 interface)** — 말리빈의 1단계 *"abstract할 게 하나도 없으니, abstract를 사용할 이유가 없다고 생각해요"* 진단을 *완전 반영*. `interface Participant` + `val items: Items` 추상 프로퍼티 + *default 메서드*로 *공통 동작 공유*. *abstract 의미 부재*를 *interface 의 추상 property + default method*로 자가 해결. *PR 본문 자가 인용 부재이나 코드 자체가 답변*.
+- **`Player.compareHand(other: Participant): WinningResult` 메시지** — 1단계 `object CalculateResult.getResult(...)` 정적 헬퍼 (말리빈 진단: *"객체에게 메시지를 던져보는 건"*) 를 *플레이어 메시지*로 자가 이전. 말리빈 코멘트: *"딜러도 결국 하나의 플레이어라고 생각할 수도 있지요. 그러면 승패의 결과는 플레이어와 플레이어를 비교해도 나올 수 있는 것은 아닐지."* 학생 답변 (커밋 `258e602`): *"참가자에게 비교하는 함수를 만들고, 플레이어와 딜러에게 구현을 약간 다르게 하였습니다."*
+- **`WinningResult` enum 의 `BLACKJACK` 분리** — 1단계 *WIN/PUSH/LOSE* 에 *블랙잭 (1.5배)* 추가. *2장 + 21* 정확 판정 (`getHandSize() == 2 && getScore() == 21`) + *별도 enum 멤버*로 *수익률 1.5배 분리 표현*. PR #128·#135·#114·#124 와 같은 결의 블랙잭 룰 정확성.
+- **`WinningResult.getPrize(WinningResult): Double` 외부 룰 표** — 1.5 / 1.0 / 0.0 / -1.0. *수익률 = WinningResult enum의 부가 정보*로 분리. *enum 멤버 안에 `val prize: Double`* 로 *프로퍼티 통합*도 가능했으나 *함수 분리*가 *룰 변경 시 enum 멤버 안전*.
+- **`EventListener` / `EventProvider` 인터페이스 = 모델-뷰 느슨한 결합** — 1단계 말리빈 *"도메인이 뷰만 모른다는 사실에 집중 → 인터페이스 혹은 람다 등으로 가져올 수 있도록"* 의 *완전한 후속 반영*. `EventListener.displayParticipantCards(name, cards)` 같은 *콜백 인터페이스*로 *도메인 → View 통보*. 학생 PR 본문: *"인터페이스를 활용해서 모델은 입력받는 구조를 모르고, 뷰에서 구현할 수 있도록 하였는데"*. 말리빈 답변: *"네 :) 의도한 방향이 맞아요."*
+- **`tailrec fun drawUntilFinished` — 말리빈 권고 자가 학습** — 말리빈의 *"재귀 함수로 게임 진행 + tailrec 키워드 알아보세요"* 권고 (반영 안 해도 좋다는 단서) 를 *Dealer.drawUntilFinished* 에 적용. 학생 자가 인용: *"재귀함수로 게임을 원하는 만큼 계속 진행하도록 변경하였습니다. tailrec 엄청나네요 오버플로우를 신경 쓸 필요가 없다니..!"*
+- **`Items(hand, money)` 일급 컬렉션 시도** — 말리빈의 *3 인스턴스 변수 제약 = 연습 도구* + *"2개를 묶어 하나의 클래스로 만들어보세요"* 힌트 반영. `Player(name, items)` / `Dealer(name, items)` 로 *Items 안에 hand + money 묶음*. *클래스 분리 연습*. 다만 *깊은 함정* (못한 점 §4) 도 동반.
+- **`Money` 연산자 오버로딩 후속 반영** — 말리빈의 *"연산자 오버로딩을 활용해볼 수도 있겠어요"* 권고에 *`operator fun plus`* 자가 도입. 학생 자가 인용: *"코드가 훨씬 더 깔끔해졌네요!"* 다만 *가변 객체 + 연산자 오버로딩 상성 문제* (못한 점 §1) 가 자가 학습 후속 토론으로 남음.
+- **테스트 픽스처 (`SPADE_ACE`) 도입** — 말리빈 *"테스트에 필요한 카드를 매번 만들어내는 건 매우 귀찮은 일이지요. 미리 카드 스텁을 테스트 패키지에 만들어 두고 재활용해보는건 어떨까요?"* 권고 후속 반영. 학생: *"매번 만들지 않아도 되니 너무 간편해졌습니다."*
+- **카드 한 장 전달 — `Participant.draw(card)`** — 1단계 *Participant.draw(cardDeck: CardDeck)* 가 *Participant이 deck 의존* (말리빈: *"카드를 뽑을 때 덱을 주는 것 보다 카드 한 장을 주는 건 어떤지에 대한 의견"*) → 2단계 *`draw(card: Card)`* 로 *카드 1장만 전달* + *engine 이 deck 보유*. 학생 자가 답변: *"카드 한장을 주도록 수정했습니다. 플레이어의 경우는 효과적으로 수정되었다고 생각하지만, 딜러의 경우에는 여러번 계속 뽑기를 해야 해서 덱을 가져와야 할 수 밖에 없었습니다."* — *Player.draw(card)* 단일 + *Dealer.drawUntilFinished(deck)* 는 deck 의존 (트레이드오프 인식 + 정당화).
+
+## 못한 점 (설계 관점)
+
+### 1. `Money` 가변 + `plus` 가 `Unit` 반환 — *연산자 오버로딩 안티패턴 정공*
+
+```kotlin
+class Money(
+    var value: Double,  // ⚠ var
+) {
+    operator fun plus(money: Money) {
+        value = value + money.value  // ⚠ 자기 변경 + Unit 반환
+    }
+
+    fun multiplyMoney(factor: Double): Money = Money(value * factor)
+}
+```
+
+말리빈 (Money.kt:11 — 미해결): *"Money가 가변 객체였네요. 연산자 오버로딩이 되어있는 다른 것들을 참고해보세요. 가변객체와 연산자 오버로딩은 상성이 그리 좋지 않음을 이번 경험으로 알게되시면 좋겠어요 :)"*
+
+→ **`Money` 가변 + `operator fun plus` Unit 반환 = 두 가지 안티패턴 동시**:
+
+1. **Kotlin operator plus 는 *새 객체 반환*이 표준** — `val total = a + b` 가 *자연*. *a + b 가 Unit 반환*하면 *`a + b` 자체가 표현식으로 사용 불가*. `BetResult.getDealerResult`의 `dealerResult + money` 가 *결과 무시 + 자기 변경* — *호출자가 "왜 이 줄이 있는지" 추측해야 함*.
+2. **`Int`/`Long`/`Double` 표준 산술과 의미 충돌** — *Kotlin 표준에선 `a + b` 가 immutable + 새 값*. *Money 가변 plus* 는 *Kotlin 어휘에 안 맞음*. *문서 안 보면 함정*.
+
+`multiplyMoney(factor)` 가 *Money 새 객체 반환* (불변 스타일) 인 반면 `plus`는 *가변 self 변경* — *동일 클래스 내 두 스타일 혼재*. *연산자 오버로딩의 원칙 = 직관적 의미 + 표준 표현*.
+
+또한 *Money 가변 + multi-thread 안전성 < Money 불변* (학생이 1단계에서 자가 학습한 결론) 과 모순.
+
+### 2. `BetResult.getDealerResult` — *Money 가변에 묶인 버그 패턴*
+
+```kotlin
+private fun getDealerResult(
+    playerResults: Map<Participant, Money>,
+    dealer: Dealer,
+): Map<Participant, Money> {
+    var dealerResult = Money(0.0)
+    playerResults.forEach { (_, money) ->
+        dealerResult + money       // ⚠ 결과 무시. Money.plus(Unit) 가변 self 변경에 의존
+    }
+    dealerResult = dealerResult.multiplyMoney(-1.0)
+    return mapOf(Pair(dealer, dealerResult))
+}
+```
+
+→ **`dealerResult + money` 의 *결과 무시 + 가변 변경 의도***. *Money.plus 가 Unit 반환 + value 변경*이므로 *동작은 함*. 다만 *코드만 보면 *`dealerResult + money` 한 줄이 NoOp* 으로 읽힘* — *Money.plus 의 가변 구현 알아야* 의미 파악. *코드 가독성 0*.
+
+또한 *딜러 결과 = 플레이어 결과 합 × -1* 룰. *플레이어들이 +5000원 벌면 딜러는 -5000원 잃음* 의 총합 0 게임. 표현은 정합. 다만 *Money 가변 의존*은 *수정 시 사고 유발*.
+
+`var dealerResult = Money(0.0)` 후 *dealerResult.multiplyMoney(-1.0)* 으로 *재할당* — *불변 스타일* 표현. *plus도 불변이면 모두 일관 — `dealerResult + money` 가 *새 Money* 반환 + *fold/sum* 패턴*.
+
+```kotlin
+val dealerLoss = playerResults.values.sumOf { it.value }
+return mapOf(dealer to Money(-dealerLoss))
+```
+
+이 한 줄이면 *Money 가변 의존 0*.
+
+### 3. `BlackjackEngine.bets: MutableMap<Player, Money>` + `Items.money` 이중 보유 — *SSOT 위반*
+
+```kotlin
+class BlackjackEngine(...) {
+    var bets: MutableMap<Player, Money> = mutableMapOf()
+
+    fun getPlayersBet(players: Players) {
+        players.value.forEach { player ->
+            bets[player] = Money(eventProvider.getBetAmount(player.name).toDouble())
+        }
+    }
+    ...
+}
+
+// Items
+class Items(val hand: Hand, val money: Money)
+```
+
+말리빈 (BlackjackEngine.kt:8 — 미해결): *"플레이어가 돈을 갖고있는데, 여기에서 베팅 금액을 한 번 더 관리하고 있는 것이 혼란스럽네요. 어디가 SSOT인지 알기가 어려워요. 이 부분은 없애보는 건 어떨까요?"*
+
+→ **`Player.items.money` (플레이어 자기 돈) + `BlackjackEngine.bets[player]` (베팅 금액 별도 보관) 이중 보유**. *베팅 금액 = 플레이어 책임* 인지 *게임 책임* 인지 모호. *Player.items.money* 가 *현재 보유금* 이면 *bet은 라운드 시작 시 자기 보유금에서 빼서 게임에 거는 흐름*. *둘 다 보유*는 *상태 일관성*을 *암묵적 invariant*로 유지해야 함.
+
+학생 PR 본문 자가 인용: *"플레이어에 3개 이상의 인스턴스 변수가 생기는걸 방지하기 위해 플레이어의 소지금을 없애고, 판돈을 엔진에 저장한 다음, 판돈을 기준으로 결과를 출력하도록 하였는데, 이렇게 하면 차후에 게임을 몇번 이어서 하는 기능을 확장하기 힘들게 될 것 같다는 생각이 듭니다."*
+
+말리빈 자가 답변: *"인스턴스 변수 3개 유지는 확실히 극단적인 방법이에요. 그러나 지금은 연습을 위해 일부러 극단적인 방법을 택했다고 생각해주세요. 분리를 연습하려면 이런 극단적임이 가장 적합하더라구요."*
+
+→ ***3 변수 제약 = 연습 도구, 절대 룰 X***. *프로그래밍 요구사항* 의 제약을 *학생이 "왜 이렇게 까지 해야 하나"* 자가 회의 → 말리빈 *"분리 연습"* 정당화. *제약의 의도 = 결합 분해 능력 키우기*. *결과적인 SSOT 위반* 은 *연습 과정의 부산물*. **MCP 룰 후보 — 형식 규칙(3변수)이 만든 인공 객체**. PR #128·#135 의 `Wallet`/`PlayerBetInfo`/`UserInformation` 와 같은 결.
+
+### 4. `Items` + `setNewHand(newHand)` — *val items + hand 가변 변경의 우회*
+
+```kotlin
+class Items(
+    val hand: Hand,
+    val money: Money,
+) {
+    fun setNewHand(newHand: Hand) {
+        hand.clear()
+        newHand.cards.forEach { card ->
+            hand.add(card)
+        }
+    }
+}
+
+// Hand
+fun clear() { _cards.clear() }
+fun add(card: Card) { _cards.add(card) }
+```
+
+말리빈 (Dealer.kt 미해결): *"아래 코드를 실행시키면 어떤 문제가 발생할까요? `val dealer = Dealer(...); dealer.items = Items(...)`"*
+
+학생 자가 답변 (커밋 `241741c`): *"딜러의 손패와 아이템을 마음대로 변경할 수 있겠네요. 관련 val로 수정했습니다. 그러나 결과적으로 핸드는 무조건 수정되어야 하다 보니 var로 수정하였는데, 책에서 읽기로는 val 가변객채 보다는 var 불변객체 가 더 멀티 쓰레드에서 안전하다고 들었습니다. 그러면 items 에서 hand를 가변으로 수정하려고 하다보니, 그럼 이전과 같은 문제가 발생 할 것 같더라고요. 그래서 일단은 val 가변객채로 선언한 _cards 의 카드를 전부 빼고 새 핸드의 카드를 전부 넣는 식으로 구상하였습니다."*
+
+→ **`val items` 외부 (좋은 면) + `Items.hand: val Hand` + `Hand.clear() + add(card)` 가변 변경 (얕은 불변 함정)**. *`val items`* 외부 보호 → *Items 객체 자체는 교체 불가*. 그러나 *Items.hand 도 val* 인데 *Hand가 가변 (clear/add)* 이므로 *Items 객체의 hand 내용은 바뀜*. 깊은 불변 X.
+
+학생이 *"val 가변 vs var 불변"* 트레이드오프 의식. *Kotlin 스타일 = "var 불변" (var prop + immutable Hand)*. 라운드 종료 시 *`items = items.copy(hand = newHand)` (Items도 data class면 자연)* 패턴. *현재 *val items + setNewHand 가변 변경* 은 *불변 스타일 흉내 + 깊은 가변* 절충.
+
+또한 `Hand.clear()` 가 *블랙잭 도메인 메시지로 의미 있는가* — *블랙잭에서 손패를 비우는 행위가 *라운드 종료 시 새 라운드 시작* 외에 있는가*. *도메인 메시지가 아니라 *Hand 가변 변경 우회 메서드**. *진짜 도메인은 `Items.startNewRound(hand)` 같은 명시적 메시지*.
+
+### 5. `Hand.BUST_SCORE = -1` 센티넬 트릭 — *1단계 미해결 그대로*
+
+```kotlin
+class Hand(...) {
+    fun isBust(): Boolean = score() == BUST_SCORE
+    fun score(): Int {
+        val baseScore = cards.sumOf { it.rank.score }
+        return maxOf(baseScore.formatIfBust(), maxScoreWithAce(baseScore).formatIfBust())
+    }
+    private fun maxScoreWithAce(hardScore: Int): Int = if (containsAce) hardScore + 10 else hardScore
+    private fun Int.formatIfBust(): Int = if (this > 21) BUST_SCORE else this
+
+    companion object {
+        private const val BUST_SCORE = -1
+        ...
+    }
+}
+```
+
+→ **`score()` 가 Bust 시 *-1* 반환 + `isBust()` 가 *score == -1* 비교**. 1단계 미해결의 *센티넬 트릭이 호출자에 새는 함정* 그대로 유지. *호출자가 `score()` 만 부르면 *Bust일 때 -1 정수* → 잘못된 비교*. *`WinningResult.getResult`* 의 *`one.getScore() > other.getScore()` 비교* 가 *둘 중 한쪽 Bust*면 *`isBusted()` 분기로 먼저 분리*하는 *방어 코드*에 의존.
+
+```kotlin
+// WinningResult.getResult
+other.isBusted() -> WIN
+one.isBusted() -> LOSE
+other.getScore() > one.getScore() -> LOSE  // ⚠ 두 isBusted 분기 후에야 안전
+```
+
+*호출자가 *Bust 분기 먼저 검증* 이 강제됨* — *센티넬 트릭의 비용*. *진짜 분리* 는 *`Hand.scoreOrNull()` / `sealed class Score { Valid(Int), Bust }`* 같은 *타입 표현*.
+
+### 6. `WinningResult.getResult` 의 *플레이어 양측 Bust* 안티 분기
+
+```kotlin
+fun getResult(one: Participant, other: Participant): WinningResult {
+    val otherBlackjack = other.getHandSize() == 2 && other.getScore() == 21
+    val oneBlackjack = one.getHandSize() == 2 && one.getScore() == 21
+    return when {
+        otherBlackjack && oneBlackjack -> PUSH
+        oneBlackjack -> BLACKJACK
+        otherBlackjack -> LOSE
+        (one.isBusted() && other.isBusted() && one is Player) -> LOSE  // ⚠ Player 타입 검사
+        other.isBusted() -> WIN
+        one.isBusted() -> LOSE
+        other.getScore() > one.getScore() -> LOSE
+        other.getScore() < one.getScore() -> WIN
+        else -> PUSH
+    }
+}
+```
+
+→ **`(one.isBusted() && other.isBusted() && one is Player) -> LOSE` 분기 — *Player/Dealer 비대칭***. *블랙잭 룰 = Bust 양측이면 둘 다 패배*. *플레이어 LOSE*만 명시되어 *딜러 입장에서 두 명 다 Bust면?* *fallback 으로 흘러가서 *other.getScore() == one.getScore() = -1 == -1 = PUSH*** 가 됨. *카지노 룰은 *플레이어 Bust 즉시 LOSE, 딜러 Bust면 모든 플레이어 WIN**. *양측 Bust* 도 *플레이어 LOSE*가 룰. *현재 분기*는 *`one is Player`* 일 때 *플레이어 LOSE* 만 표현 — *딜러 입장 비대칭 + Player 타입 검사 = 안티 다형성*.
+
+*`Player.compareHand(dealer)` 의 *Player → 자기 입장에서 결과*는 자연. 그렇다면 `one is Player` 라는 분기 자체가 *Player.compareHand* 호출 시점에 이미 *one = this(Player)* 로 고정됨 — *타입 검사 불필요*. *Dealer.compareHand 가 호출되지 않는다면 *분기 자체 죽은 코드*. PR #133에서 *Player.compareHand 만 호출* (`makeBetResultByPlayers`) 이므로 *Dealer 입장 호출 = 죽은 코드*. *복잡도 부담 + 의미 부재*.
+
+### 7. `WinningResult.getResult` 가 *정적 헬퍼* — Tell-Don't-Ask 미완성
+
+```kotlin
+class Player(...) : Participant {
+    fun compareHand(other: Participant): WinningResult = WinningResult.getResult(this, other)
+}
+
+// WinningResult
+fun getResult(one: Participant, other: Participant): WinningResult { ... }
+```
+
+→ **`Player.compareHand` 메시지는 *겉만 메시지*, *내부는 정적 호출***. *Player.compareHand → WinningResult.getResult(this, other)* 는 *`this`/`other.getHandSize()`/`getScore()`/`isBusted()`* 정보를 *Static 함수가 추출 + 비교*. *Tell-Don't-Ask 의 본질 = `this` 가 자기 정보로 결과 결정*. 현재는 *one/other 모두 ask + static logic*. PR #108 (시아 1단계) 의 *`object CalculateResult`* 정적 헬퍼와 *형태만 바뀜*.
+
+말리빈의 *"객체에게 메시지를 던져보는 건"* 의도는 *Player 자기 정보로 결과 결정* — *외부 enum 정적 함수 의존 X*. *Player 내부에서 자기 손패/Bust 상태 + 상대 메시지로 결과 계산* 이 진짜 메시지. *enum WinningResult* 는 *결과 표현*만, *결정 로직*은 *Participant 안*.
+
+다만 *Dealer/Player 다형성 차이 발생 시 분리*가 의도라면 *abstract method `compareHand(other)` 의 각 구현체에서 다른 로직*도 가능. *현재는 Player에만 compareHand* — *Dealer는 호출 안 됨*.
+
+### 8. `BlackjackEngine.progressXXX` 명사형 / `progress + 동사` 합성
+
+```kotlin
+fun progressPlayersDraw(players: Players) { ... }
+fun progressDealerDraw(dealer: Dealer) { ... }
+fun progressCalculateResult(dealer: Dealer, players: Players): Map<Participant, Money> { ... }
+fun progressCalculateFullResult(currentResult: Map<Participant, Money>) { ... }
+fun progressPlayerDrawUntilFinished(player: Player) { ... }
+```
+
+→ **`progress + XX` = *Engine이 진행 단계*를 명사적 prefix로 묶음**. *Kotlin 동사형 메서드명* 권고와 충돌. `playerDraw` / `dealerDraw` / `calculateResult` 같은 *동사*가 자연. *`progress` prefix*는 *Engine이 게임 진행자임을 메서드명에 새김* — *Engine god-object 자기 인식의 신호*.
+
+또한 `progressCalculateResult` + `progressCalculateFullResult` 두 단계가 *결과 계산 (단순)* + *결과 합산 (Player money 변경)* 분리. *왜 두 단계?* *전자는 단순 read-only, 후자는 Player.items.money 가변 변경* — *Side-effect 분리 의도*면 합리. 다만 *명명에서 안 드러남*.
+
+### 9. `Items.hand.cards` / `player.items.hand.cards` — *Demeter 위반 + 학생 자가 의문*
+
+```kotlin
+// 사용처
+eventListener.displayParticipantCards(player.name, player.items.hand.cards)
+eventListener.displayParticipantInfo(
+    dealer.name,
+    dealer.items.hand.cards,
+    dealer.items.hand.score(),
+    dealer.items.hand.isBust(),
+)
+```
+
+학생 PR 본문 자가 인용: *"items을 활용해서 적용시켜보았습니다. 확실히 확장성은 좋아진 것 같은데, 아이템에 접근 할 때 마다 player.items.hand.value 이렇게 접근하는게 너무 번거롭다는 생각이 드네요. player 안에 함수를 만들어서 핸드를 달라는 메세지를 전달하는게 맞을까요? 하니면 벨류를 사용해서 적용하는게 맞을까요?"*
+
+말리빈 답변 (Items.kt:1): *"맞고 틀림에 집중하기 보다, 그 불편함을 해결하기 위해 어떤 방법을 사용하면 좋을지에 대해 더 초점을 맞춰보세요. 디미터의 법칙에 대해서도 알아보시면서 마주한 불편함을 어떻게 해결하면 좋을지 고민해보세요!"*
+
+학생 답변: *"단순히 getter로 데이터를 가져오는 것이 아닌 메세지를 주고받기! 제 코드도 무조건 자료를 가져와서 비교하는 방식이었는데, 객체지향에 위배되는줄 몰랐네요. 이건 범위가 너무 넓어서 시간이 날 때 천천히 리펙토링 해보겠습니다."*
+
+→ **Items 일급 컬렉션 도입의 부작용 = Demeter 깊이 증가**. *Player → Items → Hand → cards/score/isBust* 가 *3 단계 점 접근*. *Items 도입 = 변수 묶음* 의도였으나 *접근 경로 길어짐 + Demeter 위반*. *Player.cards()*, *Player.score()* 등 *위임 메서드*로 *접근 한 단계*가 자연. *호출자는 Items 존재 모름* — *Items 은 Player 내부 구현*.
+
+*EventListener.displayParticipantInfo(name, cards, score, isBusted)* 가 *4 개 정보를 한 번에 받음* — *participant 한 객체*를 받으면 더 자연. 다만 *EventListener interface = 도메인 → View 통보* 이므로 *Participant 도메인 객체를 View에 노출*은 *View가 도메인 알아야* 함. *DTO* 변환이 *완전한 분리*. 트레이드오프.
+
+### 10. `BlackjackEngine` god-object — *bets + cardDeck + eventListener + eventProvider 4 인스턴스 변수*
+
+```kotlin
+class BlackjackEngine(
+    val cardDeck: CardDeck = CardDeck(),
+    val eventListener: EventListener,
+    val eventProvider: EventProvider,
+) {
+    var bets: MutableMap<Player, Money> = mutableMapOf()
+    ...
+}
+```
+
+→ **4 인스턴스 변수 + 11 메서드 (`getPlayersBet`, `preparePlayers`, `prepareDealer`, `drawPlayer`, `drawDealer`, `makeFirstHand`, `progressPlayersDraw`, `progressPlayerDrawUntilFinished`, `progressDealerDraw`, `progressCalculateResult`, `progressCalculateFullResult`, `setParticipantCard`)** — *Engine 이 모든 진행 흡수*. 1단계 *Controller god-object → 2단계 Engine god-object* 의 *책임 이전 + 분리 미완*.
+
+말리빈 (BlackjackEngine.kt:1 — 미해결): *"네 :) 의도한 방향이 맞아요. ... 어떤 차이가 있을까요?"* + *"어떤 의존성이 심해지나요? 또, 어떤 확장에 문제가 생길 수 있었나요?"* (두 단계 메타 질문).
+
+학생: *"음..그래도 지금처럼 게임 진행에 대한 로직과 출력만 담당하는 로직을 나눠서 진행은 엔진에서, 출력은 컨트롤러에서 진행하는 것이 맞다고 생각했습니다."*
+
+→ **Engine + Controller 의 책임 경계 = 학생 자가 결정**. *Engine = 진행*, *Controller = 출력* 분리. 그러나 *EventListener interface 가 도메인-뷰 콜백*이므로 *Controller = 의존성 주입 + EventListener 구현* 인지 *Controller = 메인 흐름 (run 함수)* 인지 *추가 분리*가 모호. *Engine.progressXX 11개 메서드*는 *Engine = 모든 흐름의 진입점* — *Controller 가 그저 Engine.progressXX 순차 호출자*면 *Engine 안에 `run()`* 도 가능 (PR #131 (다이스) 와 같은 결).
+
+### 11. `EventListener.displayDealerDrawInfo(name, count)` — *카운트 = 출력용 카운터*
+
+```kotlin
+fun displayDealerDrawInfo(name: String, count: Int)
+
+// 사용처
+eventListener.displayDealerDrawInfo(dealer.name, dealer.getHandSize() - START_CARD_COUNT)
+```
+
+→ **`dealer.getHandSize() - START_CARD_COUNT` = *현재 핸드 - 초기 카드 수* = *추가 뽑은 수***. 1단계 *Dealer.getAdditionalDrawCount* (말리빈 진단: *"콘솔의 영향으로 이렇게 구성했다는 느낌이 강하게 드네요"*) 와 같은 결. *2단계에서도 동일한 *출력용 카운터*가 Engine에 살아 있음*. *Dealer는 자기 추가 뽑은 카드 수*를 *메시지로 알리지 않음* + *Engine이 외부에서 계산*. 도메인 책임 누수.
+
+### 12. `Player` 가 `compareHand(other: Participant)` 만 가짐 — *Dealer.compareHand 없음 = 비대칭*
+
+```kotlin
+class Player(...) : Participant {
+    fun compareHand(other: Participant): WinningResult = WinningResult.getResult(this, other)
+}
+
+class Dealer(...) : Participant {
+    tailrec fun drawUntilFinished(cardDeck: CardDeck) { ... }
+    // compareHand 없음
+}
+```
+
+→ **`Player.compareHand` 만 존재 = *플레이어 vs 다른 참가자* 메시지로 *플레이어 입장* 결과**. *Dealer.compareHand* 가 없으므로 *Dealer 입장 결과*는 *BetResult.getDealerResult* 에서 *플레이어 합 × -1* 로 *우회*. *Tell-Don't-Ask 의 *Dealer 입장* 부재*.
+
+*Participant interface에 `compareHand`* 가 *abstract method* 면 *Player/Dealer 각각 구현 다형성* — *카지노 룰 (딜러는 모든 플레이어와 동시 비교)* 도 *Dealer.compareHand(players: Players)* 같은 *다른 시그니처* 로 표현. 현재는 *Player에만 method 존재 + 정적 헬퍼* 가 그 한계.
+
+### 13. `Card.getCashed` — *cashed* 오타 + *findLast* naming 모순
+
+```kotlin
+class Card private constructor(
+    val rank: CardRank,
+    val suit: CardSuit,
+) {
+    companion object {
+        val SINGLE_DECK = ...
+
+        fun getCashed(
+            rank: CardRank,
+            suit: CardSuit,
+        ): Card =
+            SINGLE_DECK.findLast { it.rank == rank && it.suit == suit }
+                ?: throw IllegalArgumentException("[ERROR] 잘못된 카드 번호나 문양입니다.")
+    }
+}
+```
+
+→ **`getCashed` = `cached`의 오타 (현금화 cash와 혼동)**. *Card 캐시 lookup* 의미 — *getCached* 가 표준. *팩토리 함수 이름 = `Card.of(rank, suit)` / `Card.from(rank, suit)`* 가 Kotlin 표준 어휘. *명명 오타*는 *향후 사용자 혼란*.
+
+또한 `findLast` — *SINGLE_DECK이 unique*인데 *마지막 매칭*은 *의미 부재*. *`first { ... }` 또는 `single { ... }`* 가 자연. PR #108 (시아 1단계) 와 같은 결의 *naming 부조화* 잔존.
+
+### 14. `Items.hand: Hand` + `Items.money: Money` 둘 다 val — *깊은 불변 부족 + Items 정당화 모호*
+
+```kotlin
+class Items(
+    val hand: Hand,    // val + Hand 가변 (clear/add)
+    val money: Money,  // val + Money 가변 (var value: Double)
+) {
+    fun setNewHand(newHand: Hand) { ... }
+}
+```
+
+→ **Items 두 멤버 모두 *val + 내부 가변***. *val 보호는 객체 교체 차단*만, *내부 변경은 그대로*. *Items 도입의 의미 = 데이터 묶음 + 메시지 발신처*. 다만 *Items.setNewHand* 같은 *상태 변경 메서드* 가 *Items 안에 있는 것*은 *Items = 일급 컬렉션이 자기 정보 관리* 패턴. *현재는 setNewHand 외에 다른 메서드 0개* — *데이터 클래스에 가까움*.
+
+*Kotlin data class 로 재선언* 하면 *equals/hashCode/copy* 자동. *`items.copy(hand = newHand)` 같은 *불변 사본*이 자연 — *현재 *clear + add* 가변 변경*과 정공.
+
+말리빈 메타 답변 (BlackjackEngine.kt 첫 두 단계 질문): *"인스턴스 변수 3개 유지는 확실히 극단적인 방법이에요. 그러나 지금은 연습을 위해 일부러 극단적인 방법을 택했다고 생각해주세요."*
+
+→ **Items = 3 변수 제약 우회로 만들어진 인공 객체** 의 측면. *블랙잭 도메인에서 "참가자의 아이템" = hand + money* 가 *자연한 묶음*인가 *아니면 변수 갯수 제약 인공물*인가. *답은 트레이드오프* — 학생/말리빈 둘 다 의식.
+
+### 15. `Participant.addPrize(prize)` — *Money 가변에 묶인 부수효과 메서드*
+
+```kotlin
+interface Participant {
+    val items: Items
+    ...
+    fun addPrize(prize: Money) = items.money + prize  // ⚠ items.money + prize = Unit, 가변 변경
+}
+```
+
+→ **`items.money + prize` 결과 무시 + Money.plus 가변 변경 의존**. *Participant.addPrize(prize)* 가 *부수효과 메서드 (Unit)* 인데 *내부 `items.money + prize`* 도 *Unit + 가변 변경* — *두 단계 가변에 의존*. *Money 불변 + plus 새 객체*면 *`items = items.copy(money = items.money + prize)`* 같은 *명시적 재할당*. 그러나 *items val* 이므로 *Items 도 copy 의존*.
+
+*Kotlin 가변 vs 불변 정공* — *모두 불변 + copy* 패턴. 현재는 *가변 plus 호출 + val 우회* 가 *복잡도 증가*.
+
+### 16. `BlackjackEngine.setParticipantCard` — *라운드 재시작 시 새 핸드 분배*
+
+```kotlin
+fun setParticipantCard(dealer: Dealer, players: Players) {
+    dealer.changeHand(makeFirstHand())
+    players.value.forEach { player ->
+        player.changeHand(makeFirstHand())
+    }
+}
+```
+
+→ **`changeHand` = Items.setNewHand 호출 = Hand.clear() + add()**. 라운드 종료 후 *같은 Dealer/Player 객체* 의 *Hand 만 비우고 새 카드 추가*. *학생 자가 학습 (`tailrec` + 재귀로 게임 N회) 의 확장 기능*. *Player/Dealer 동일성 유지 + 라운드 간 손패 교체*.
+
+말리빈 (BlackjackEngine.kt 미해결): *"여러운 도전 과제일 수도 있지만 한 번 남겨둘게요 이건 반영하지 않으셔도 좋아요 :) 재귀 함수로 게임 진행을 구현해볼 수도 있겠어요. 코틀린의 tailrec 키워드도 함께 알아보세요!"*
+
+→ **`tailrec` 자가 학습은 좋은 면** + **`setParticipantCard` 가 *in-place 핸드 교체*로 *Player 동일성 유지*** 는 *말리빈의 도전 과제* 의 답. 다만 *Player 가 라운드 마다 다른 손패* = *Player 동일성 의미가 "참가자 신원"으로 좁아짐* + *Hand 가변 변경 의존* 의 부산물.
+
+*불변 스타일 정공* = *라운드마다 새 Player(이름, newItems)* 객체 생성. 다만 *Player 객체 identity 가 라운드별로 달라짐* — *총 결과 집계* 등에서 *같은 이름 = 같은 사람* 판정 필요. *현재 in-place 교체*는 *identity 유지*를 위한 트레이드오프.
+
+### 17. `Players` 가 `value: List<Player>` 만 가짐 — *행위 미부여*
+
+```kotlin
+class Players(val value: List<Player>) {
+    init { require(...) }
+    // 일급 컬렉션이지만 메서드 0개
+}
+```
+
+말리빈 (Players.kt — 미해결): *"value 프로퍼티가 있는데 getPlayers() 함수를 따로 만든 이유가 궁금하네요!"*
+
+학생 자가 답변 (커밋 `04edcd9`): *"지난 리뷰에서 메세지를 줘야한다 이런 생각이 들어서 get을 붙였는데 지금 생각해보니 쓸대 없는 함수였네요.."*
+
+→ **`Players` 일급 컬렉션이지만 *행위 메서드 0개***. *`results(dealer: Dealer): Map<...>` 메서드 (1단계)* 가 *2단계에서 BetResult로 이전됨*. *지금 Players는 *컬렉션 wrapper + 검증*만*. *일급 컬렉션의 가치 = 자기 정보 + 자기 행위*. *현재는 자기 정보만*. *`Players.eachDraw(deck)`* 같은 *분배 메시지* 추가 후보.
+
+### 18. `getCashed` factory naming + *생성자 vs 팩토리 표준 어휘*
+
+```kotlin
+fun getCashed(rank: CardRank, suit: CardSuit): Card =
+    SINGLE_DECK.findLast { it.rank == rank && it.suit == suit }
+        ?: throw IllegalArgumentException(...)
+```
+
+→ **Kotlin 팩토리 함수 표준 어휘 미준수**:
+- `from(rank, suit)`: 다른 형태에서 객체 생성
+- `of(rank, suit)`: 여러 인자로 객체 생성
+- `valueOf(rank, suit)`: 더 명시적
+- `getInstance()`: 싱글톤
+- `getCached()`: 캐시 명시
+
+*`getCashed`* 는 *명명 오타 + 표준 어휘 부재*. *Effective Java/Kotlin 팩토리 함수 어휘* 권고.
+
+### 19. `assertThat` vs `assertEquals` 학생 자가 학습 영역
+
+```kotlin
+// 학생: 빨간 줄이 떠서 assertEquals 사용
+```
+
+말리빈 (BlackjackEngineTest.kt:40): *"빨간 줄이 나타났다는 건, 컴파일이 안됐다는 의미인가요? 그렇다면 그냥 문법을 잘못 활용한 경우예요. assertAll과 assertThat은 서로 사용할 수 있어요. ... 왜 assertThat 으로 시작하는 테스트 라이브러리가 등장했는지 알아보셔도 좋겠어요."*
+
+→ **AssertJ `assertThat` = fluent API + 풍부한 매처**. *JUnit `assertEquals` = 단순 동등*. *복잡한 어설션 (`assertThat(list).containsExactly(...)` 등)* 은 *assertThat 만의 영역*. *학생이 컴파일 오류를 이유로 회피한 것은 학습 회피 신호* — 말리빈 진단.
+
+### 20. `Hand.score()` 의 `maxOf(baseScore.formatIfBust(), maxScoreWithAce(baseScore).formatIfBust())` — *과잉 트릭 잔존*
+
+```kotlin
+fun score(): Int {
+    val baseScore = cards.sumOf { card -> card.rank.score }
+    return maxOf(baseScore.formatIfBust(), maxScoreWithAce(baseScore).formatIfBust())
+}
+
+private fun maxScoreWithAce(hardScore: Int): Int =
+    if (containsAce) hardScore + 10 else hardScore
+
+private fun Int.formatIfBust(): Int = if (this > 21) BUST_SCORE else this
+```
+
+→ **1단계 트릭 그대로**. *baseScore (Ace=1)* + *maxScoreWithAce (Ace 있으면 +10)* 두 후보 + *각각 Bust면 -1* + *maxOf*. *Ace 단일 +10 if (sum + 10 ≤ 21)* 한 줄 패턴 (PR #128·#135·#114) 으로 충분.
+
+*containsAce && baseScore + 10 ≤ 21 → baseScore + 10 else baseScore* 이 *부정확한 경우* — *Ace 2장* (예: A♠ A♥). *baseScore = 2, maxScoreWithAce = 12 (한 Ace만 +10)*. *현재 `containsAce` boolean → +10 1번* 이 *Ace 2장 처리 정확* (둘 다 11이면 22 > 21이므로 한 Ace만 11 + 나머지는 1). OK.
+
+다만 *세 Ace* 경우: *baseScore = 3, maxScoreWithAce = 13*. *현실 시나리오*는 *극히 드물지만 룰 = 한 Ace만 11* 이 정확. 현재 구현 OK.
+
+### 21. `Items` 도입의 *Demeter 비용 vs 변수 묶음 이득* — 학생 자가 의문이 미해결
+
+학생 PR 본문 (items): *"player.items.hand.value 이렇게 접근하는게 너무 번거롭다는 생각이 드네요. player 안에 함수를 만들어서 핸드를 달라는 메세지를 전달하는게 맞을까요? 하니면 벨류를 사용해서 적용하는게 맞을까요?"*
+
+학생 후속 답변: *"이건 범위가 너무 넓어서 시간이 날 때 천천히 리펙토링 해보겠습니다."*
+
+→ **Items 도입의 *Demeter 비용*을 학생이 자가 인식 + 미해결**. *Player.cards()*, *Player.score()*, *Player.isBust()* 같은 *위임 메서드* 가 *Player가 자기 정보 노출 + 호출자 한 단계 접근* 의 정공. *Participant interface 의 default 메서드* `getHandSize()`, `getScore()`, `isBusted()` 가 *그 방향*인데 *EventListener 호출 시 *cards 자체*가 필요해 *items.hand.cards 직접 접근*. 도메인 메시지 (Participant) + View 호환 (cards 노출) 의 트레이드오프.
+
+## 리뷰어 의견 요지
+
+- **Money 가변 + 연산자 오버로딩 = 상성 안 좋음** — *operator plus = 새 객체 반환* 표준 + *불변* 안전. *가변 + plus = 표현식 의미 무너짐*.
+- **SSOT — 같은 정보 두 곳 보유 X** — *Player.items.money* + *Engine.bets[player]* 이중 = *상태 일관성 암묵 invariant*.
+- **3 변수 제약 = 연습 도구, 절대 룰 X** — *분리 능력 키우기 위한 극단적 방법*. *Items 같은 인공 객체*는 *연습 부산물*. *완전히 정당한 도메인 객체*가 되려면 *블랙잭 도메인에서 "참가자의 아이템"이 자연한 묶음인가* 검증.
+- **재귀 + tailrec = 게임 N회 진행** — *while loop 의존 X*. *tailrec 키워드 = 스택 안전 재귀*. *Kotlin 다중 패러다임 학습*.
+- **Demeter — `player.items.hand.value` 같은 점 체인 = 객체 협력 부재 신호** — *Player.cards()* 위임이 *호출자가 알아야 하는 객체 수 최소화*.
+- **참가자 vs 참가자 메시지 = 딜러도 플레이어로 일반화** — *Player.compareHand(participant)* 도입은 좋은 면. 다만 *내부가 정적 헬퍼*면 *Tell-Don't-Ask 의 절반*.
+- **연습 의도 = 다각도 시점 갖기, 맞고 틀림 X** — 말리빈의 *"맞고 틀림을 가르는 것으로 초점을 맞추기보다, 다각도의 시점으로 본다는 것에 더 집중해보세요. 이런 고민들이 앞으로 기준을 나누는데 자신만의 힘을 기를 수 있게 해줄거라 의심치 않아요."*
+- **assertThat 도입 이유 = 매처 풍부함** — *JUnit assertEquals 한계*. *복잡한 어설션 표현력*.
+- **테스트 픽스처 = 재사용 + 가독성** — *매번 카드 만들기 X*. *상수 fixture* 가 *테스트 의도 명료*.
+- **`dealer.items = ...` 외부 변경 가능성 = val 보호 필요** — *property val*은 *교체 차단*. *내부 가변* 은 별개.
+
+## 대표 인용
+
+**말리빈 (3 변수 제약의 의도, BlackjackEngine.kt):**
+> 인스턴스 변수 3개 유지는 확실히 극단적인 방법이에요.
+> 그러나 지금은 연습을 위해 일부러 극단적인 방법을 택했다고 생각해주세요. 분리를 연습하려면 이런 극단적임이 가장 적합하더라구요.
+> 처음부터 분리에 익숙해지면, 합치는 것은 매우 쉬워져요.
+> 그러나 분리를 할 줄 모르면 합쳐져있는 것에서 분리할 수 있다는 사실 자체를 깨닫지 못하지요.
+>
+> 객체가 어떤 값을 가지는 게 너무 자연스럽다면 그 객체에 위치하는 것이 당연하지요.
+> 야매라고 생각하실 수도 있겠지만, 3개가 필요한 곳에서, 2개를 묶어 하나의 클래스로 만들어보세요.
+> 이 클래스의 이름을 짓는 것 조차도 굉장히 어려운 일이 될 수도 있으니 좋은 연습이 될거예요.
+
+**말리빈 (가변 객체 + 연산자 오버로딩, Money.kt:11):**
+> Money가 가변 객체였네요. 연산자 오버로딩이 되어있는 다른 것들을 참고해보세요.
+> 가변객체와 연산자 오버로딩은 상성이 그리 좋지 않음을 이번 경험으로 알게되시면 좋겠어요.
+
+**말리빈 (SSOT, BlackjackEngine.kt:8):**
+> 플레이어가 돈을 갖고있는데, 여기에서 베팅 금액을 한 번 더 관리하고 있는 것이 혼란스럽네요.
+> 어디가 SSOT인지 알기가 어려워요.
+> 이 부분은 없애보는 건 어떨까요?
+
+**말리빈 (Demeter, Items.kt:1):**
+> 맞고 틀림에 집중하기 보다, 그 불편함을 해결하기 위해 어떤 방법을 사용하면 좋을지에 대해 더 초점을 맞춰보세요.
+> 디미터의 법칙에 대해서도 알아보시면서 마주한 불편함을 어떻게 해결하면 좋을지 고민해보세요!
+
+**말리빈 (재귀 + tailrec, BlackjackEngine.kt):**
+> 어려운 도전 과제일 수도 있지만 한 번 남겨둘게요 이건 반영하지 않으셔도 좋아요.
+> 재귀 함수로 게임 진행을 구현해볼 수도 있겠어요.
+> 코틀린의 tailrec 키워드도 함께 알아보세요!
+
+**말리빈 (참가자 일반화, Dealer.kt):**
+> 그렇다면 WinningResult 자체를 만들어내는 로직은 WinningResult에 옮겨보는 건 어떨까요?
+> 로또의 등수를 계산했듯이요.
+>
+> 또 하나 생각할 점을 던져드릴게요.
+> 딜러도 결국 하나의 플레이어라고 생각할 수도 있지요.
+> 그러면 승패의 결과는 플레이어와 플레이어를 비교해도 나올 수 있는 것은 아닐지.
+> 그것을 코드로 충분히 표현해볼 수는 있지 않을지 고민해보세요.
+
+**말리빈 (다각도 시점, BlackjackEngine.kt:1):**
+> 맞고 틀림을 가르는 것으로 초점을 맞추기보다, 다각도의 시점으로 본다는 것에 더 집중해보세요. 이런 고민들이 앞으로 기준을 나누는데 자신만의 힘을 기를 수 있게 해줄거라 의심치 않아요.
+
+**학생 자가 학습 (tailrec, BlackjackEngine.kt):**
+> 재귀함수로 게임을 원하는 만큼 계속 진행하도록 변경하였습니다. tailrec 엄청나네요 오버플로우를 신경 쓸 필요가 없다니..!
+
+**학생 자가 학습 (Demeter 깨달음, Items.kt):**
+> 단순히 getter로 데이터를 가져오는 것이 아닌 메세지를 주고받기! 제 코드도 무조건 자료를 가져와서 비교하는 방식이었는데, 객체지향에 위배되는줄 몰랐네요. 이건 범위가 너무 넓어서 시간이 날 때 천천히 리펙토링 해보겠습니다.
+
+**학생 자가 답변 (val 가변 vs var 불변 트레이드오프, Dealer.kt):**
+> 딜러의 손패와 아이템을 마음대로 변경할 수 있겠네요. 관련 val로 수정했습니다. 그러나 결과적으로 핸드는 무조건 수정되어야 하다 보니 var로 수정하였는데, 책에서 읽기로는 val 가변객채 보다는 var 불변객체 가 더 멀티 쓰레드에서 안전하다고 들었습니다. 그러면 items 에서 hand를 가변으로 수정하려고 하다보니, 그럼 이전과 같은 문제가 발생 할 것 같더라고요. 그래서 일단은 val 가변객채로 선언한 _cards 의 카드를 전부 빼고 새 핸드의 카드를 전부 넣는 식으로 구상하였습니다.
+
+**학생 자가 학습 (블랙잭 룰 정확성, Dealer.kt — 1단계 연장):**
+> 현실 세계에서는 딜러가 플레이어 카드를 보고 계산한다고 생각해서 그렇게 구현하였으나, 딜러가 너무 많은 기능을 가지고 있는게 아닌가 싶습니다. 어디까지 현실 세계를 반영해야 하는지 궁금합니다.
+
+## 얻은 교훈
+
+1. ***가변 객체 + 연산자 오버로딩 = 상성 안 좋음***. *`operator fun plus(other) = Unit + 자기 변경`* 은 *Kotlin 표준 어휘 위반*. *`a + b`* 가 *표현식*으로 사용 불가 + *결과 무시 + 부수효과* 가독성 0. *불변 객체 + 새 객체 반환* 패턴이 *operator overloading 의 정공*. PR #131 (다이스 2단계) 의 *BetAmount value class* 와 *반대 패턴*.
+
+2. ***SSOT — 같은 정보 두 곳 보유는 invariant 비용***. *`Player.items.money` + `Engine.bets[player]` 이중*은 *베팅금 갱신 시 두 곳 동기화*. *상태 변경의 모든 경로*가 *두 곳 함께 변경* 보장해야 함 — *암묵적 invariant*. *SSOT (Single Source Of Truth)* = *상태 1곳*. *베팅금 = Player 책임* 이면 *Engine은 read-only*.
+
+3. ***3 변수 제약 = 연습 도구, 절대 룰 X*** — 학생/말리빈 둘 다 의식. *형식 규칙 (3변수)* 이 *Wallet/Items/PlayerBetInfo 같은 인공 객체*를 만들 위험. *연습의 의도 = 분리 능력 키우기*. *완전한 도메인 정당화*가 *진짜 객체와 인공 객체* 의 경계. PR #128·#135 의 *Wallet*/*UserInformation* 과 같은 결.
+
+4. ***Demeter — `a.b.c.d` 점 체인 = 협력 부재 신호***. *Player.items.hand.cards* 가 *3단계 접근*. *Player.cards()* 위임이 *호출자가 알아야 하는 객체 수 최소화*. *Items 일급 컬렉션 도입의 부작용 = 접근 경로 길어짐* — *위임 메서드*로 *외부에는 한 단계 접근*만 보이게.
+
+5. ***`Player.compareHand(other)` 메시지는 *겉만 메시지*, *내부 정적 헬퍼*면 Tell-Don't-Ask 절반***. *`Player.compareHand → WinningResult.getResult(this, other)`* 는 *Static 함수가 self/other 정보 추출 + 비교*. *진짜 메시지*는 *Player 자기 정보로 결과 결정* — *외부 enum 정적 함수 의존 X*. PR #108 (시아 1단계) 의 *object CalculateResult* 변형.
+
+6. ***Bust 양측 + Player 타입 검사 = 안티 다형성***. *`(one.isBusted() && other.isBusted() && one is Player) -> LOSE`* 분기는 *Participant 다형성 부재 신호*. *Player.compareHand 만 호출* 이라면 *one is Player* 검사 = *죽은 코드*. 그렇다면 *코드 자체 삭제* 가능. *블랙잭 룰 (Bust 양측 = 양측 패배)* 명시도 부재.
+
+7. ***`Card private constructor + named factory` 가 정공 — 1단계 invoke 함정 자가 해소***. 학생이 1단계 *operator fun invoke + public class* 의 모호함을 *private constructor + getCashed*로 자가 후속. 다만 *`getCashed` 명명 오타 (cached)* + *Kotlin 팩토리 표준 어휘 (`of`/`from`)* 미준수.
+
+8. ***`tailrec` = 스택 안전 재귀***. *Kotlin tailrec 키워드*는 *꼬리 재귀 최적화 강제*. *`drawUntilFinished` 같은 *조건 만족 시 종료 + 자기 재귀** 가 *while 루프와 동등한 성능 + 함수형 어휘*. *학생 자가 학습 + 도전 과제 반영 모범*.
+
+9. ***val + 가변 내부 = 얕은 불변***. *`val items: Items` + `Items.hand: Hand` 가변 (clear/add)* 은 *외부 교체 차단 + 내부 변경 허용*. *깊은 불변*은 *모든 멤버 불변 + copy 패턴*. *학생이 "val 가변 vs var 불변" 트레이드오프 의식* + *현재는 *val + clear/add 우회**.
+
+10. ***EventListener/EventProvider interface = 도메인-뷰 느슨한 결합 정공***. 1단계 말리빈의 *"도메인이 뷰만 모른다는 사실에 집중 → 인터페이스 혹은 람다 등으로 가져올 수 있도록"* 의 완전한 후속 반영. *EventListener.displayParticipantCards(name, cards)* 콜백으로 *도메인 → View 통보*. *Controller 가 EventListener 구현체* 주입. PR #131 (다이스 2단계) 의 *BlackJackView interface* 와 같은 결.
+
+11. ***Engine god-object 가능성 — Controller 분리 + 진행 흡수의 후속***. *1단계 Controller god-object → 2단계 Engine god-object* 의 책임 이전 + 분리 미완. *Engine 11 메서드 + 4 인스턴스 변수* 가 *god-object 변형 신호*. *각 객체 자기 책임* 흐름이 *Engine 거치는 wrapper* 보다 메시지 패턴에 맞음.
+
+12. ***Hand BUST_SCORE = -1 센티넬 트릭 잔존 (1단계 미해결 그대로)***. *score() = Bust 시 -1* 트릭이 *호출자가 isBust 먼저 분리*를 *암묵적 invariant*로 강제. *WinningResult.getResult* 의 *isBusted 분기 후 score 비교* 가 그 우회. *진짜 분리*는 *sealed class Score { Valid(Int), Bust }* 또는 *Hand.scoreOrNull(): Int?*.
+
+13. ***`getXXX` 명사형 → Kotlin property 또는 동사형***. `getHandSize()`, `getScore()`, `isBusted()` 가 *Java Bean 어휘*. *Kotlin val handSize get(), val score get(), val busted get()* 이 *Kotlin 어휘*. *Participant interface default property* 활용.
+
+14. ***`progress + XX` prefix = Engine god-object 자기 인식 신호***. *`progressPlayersDraw` / `progressDealerDraw` / `progressCalculateResult`* 는 *Engine 이 게임 진행자임을 메서드명에 새김*. *분리된 객체*들 각자 *자기 책임 메시지* 면 *progress prefix 불필요*. *명명이 책임의 분배 상태를 노출*.
+
+15. ***학생 자가 답변에 커밋 SHA 첨부 + 자가 학습 모범 패턴 지속***. Leeyerin0210 이 1단계와 동일하게 *모든 자가 답변에 커밋 SHA* (`258e602`, `46cb1ab`, `a854fe5`, `7bdab32`, `04edcd9`, `f51bab8`, `241741c`, `09a3758`, `bedbaf0`, `41651a0`, `ac6a151` 등) + *책 정리 + 자가 의문 + 후속 학습* 흐름. *Kotlin Multiplatform·Effective Kotlin·Demeter·tailrec* 자가 학습. *외부 자료 → 본인 코드 적용* 학습 모범.
+
+16. ***라운드 N회 게임의 *Player identity 유지* vs *불변 사본*의 트레이드오프***. *현재 in-place 핸드 교체 (Items.setNewHand → Hand.clear + add)* 는 *Player 동일성 유지 + 가변 변경*. *불변 사본 (Player.copy(items = newItems))* 은 *Player 객체 매 라운드 새로 생성*. *총 결과 집계 시 같은 사람 매핑*은 *이름 키* 사용. *동일성 의미*가 *identity (참조) vs equality (이름)* 의 트레이드오프.
+
+17. ***일급 컬렉션의 가치 = 자기 정보 + 자기 행위***. *Players 클래스가 *value: List<Player>* 만 + *행위 메서드 0* 이면 *컬렉션 wrapper*에 그침. *Players.eachDraw(deck)*, *Players.results(dealer)* 같은 *컬렉션 메시지* 가 *일급 컬렉션 정당화*. *현재는 init 검증만 + 메서드 0개* — *행위 부재* 가 *일급 컬렉션의 가치 미실현*.