oh-my-oop 0.2.0

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

@@ -0,0 +1,482 @@
+# PR #152 — [블랙잭 2단계] 모찌 미션
+
+- **Reviewee:** [@wondroid-world](https://github.com/wondroid-world)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/152
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 23 스레드 / 45 코멘트 — 학생 자가 답변 + 커밋 SHA 첨부 패턴 유지
+
+## 잘한 점 (설계 관점)
+
+- **State 패턴 도입 — `interface State` + `StartGame`/`Hit`/`Finish(Bust/Blackjack/Stay)`** — 1단계의 `Cards.getStatus(): CardsStatus` enum 분기 구조를 *상태 객체로 일급화*. `state.draw(card): State` 가 *다음 상태로 전이* 메시지. `Hit.draw` 가 *블랙잭/Bust/Stay/Hit 분기*를 자기 안에서 결정. *Tell-Don't-Ask* 진척.
+- **`Money value class` + 연산자 오버로딩 (`operator fun times`)** — `Money * Float = Money` / `Money * Int = Money` 표현. *`@JvmInline value class`* 로 *런타임 박싱 없음*. 도메인 어휘를 *값 객체*로.
+- **블랙잭 룰 정확성 — `Hit.draw` 에서 *카드 2장 + 21 = 블랙잭, 21 초과 = Bust, 그 외 21 = Stay***
+  ```kotlin
+  newHand.size == FIRST_CARD_COUNT && score == BLACKJACK_SCORE -> Blackjack(newHand)
+  score > BLACKJACK_SCORE -> Bust(newHand)
+  else -> Stay(newHand)  // score == 21 but size > 2 → Stay (블랙잭 X)
+  ```
+  → *1단계 페로로 진단* (`첫 턴 21 ≠ 카드 2장 21`) 완전 반영. *3장 21*은 *Stay*로 분기.
+- **전역 상수 `BlackjackRule.kt` 자가 제거** — 학생이 1단계 종료 후 *공통 상수 객체*에 룰 모았다가, 페로로의 *"특정 비즈니스 로직이 공통 상수에 결합되는건 좋지 않다. 모든 객체가 Rule에 의존하게 되어 하나의 Rule을 쉽게 수정하지 못하게 되지 않나요?"* 진단으로 *각 객체 companion 상수화*로 자가 후퇴. 학생 자가 인용: *"객체는 스스로 자율성을 가져야한다는 생각에서 보면 객체 내에서 상수화를 진행하는 것이 맞다고 바뀌었습니다. 그리고 전역 상수와 객체간에 결합도 올라가서, 유지 보수가 어려워진다고도 생각이 듭니다."*
+- **`Participant.state` 가 `var` + `private set` 후속 반영** — 페로로의 *"private setter를 사용하면 되지 않을까요?"* 한 줄에 *backingField (`var _state` + `val state: get`) → `var state private set`* 으로 자가 반영. *Kotlin property 어휘* 정착.
+- **`Hit.stop()` / `StartGame.stop()` → `Stay`** — *플레이어가 언제든 게임을 끝낼 수 있어야 한다*는 학생 해석. 결과적으로 *카드 한 장 받기 전*에도 `stop` 가능 (StartGame.stop) — 도메인 룰과 정합 여부는 미해결.
+- **`Hit.draw` 의 *다음 상태 결정* 1단계 진단 반영** — *"논리적으로 카드를 뽑는 즉시 버스트가 결정될텐데 stop()이라는 행동이 다시 버스트로 바꿀 일이 있나요?"* 페로로 의문에 *"점수로 파악하는 로직은 draw에서 다 판단을 해주고 넘겨주고 있습니다"* 자가 답변 + 후속 커밋. *상태 전이의 진입점 통일*.
+- **`Dealer.canDraw()` 메시지 도입** — 1단계 `Dealer.isHit()` (페로로 진단: *Hit은 액션이지 상태가 아님*) 에서 `canDraw()`로 자가 변경. *플레이어와 일관된 메시지* 시도 (다만 Player는 canDraw 미구현 — 못한 점 §1).
+- **테스트 픽스처 — `Hand(...)` 직접 생성으로 시작 카드 주입** — `BlackjackGameTest` 의 시드 카드 주입으로 *순서 고정 테스트*. *전략 셔플*과 정합.
+
+## 못한 점 (설계 관점)
+
+### 1. `dealerTurn()` 의 *while 안에 즉시 return* — *논리 오류*
+
+```kotlin
+fun dealerTurn(): Boolean {
+    while (dealer.canDraw()) {
+        dealer.receiveCard(cardDeck.pickCard())
+        return true     // ⚠ while 첫 번째 iteration 끝나면 즉시 반환
+    }
+    dealer.stop()
+    return false
+}
+```
+
+→ **`while`이 *루프*가 아니라 *if + return* 으로 동작**. *한 번 호출에 카드 1장*만 받고 끝남. *딜러 룰 = "16 이하면 17 이상까지 hit"* 가 *호출자가 반복해서 `dealerTurn()` 부르기*로 외부에 떠넘김. *Tell-Don't-Ask* + *딜러 자율성* 모두 위반.
+
+페로로의 직접 코멘트는 없지만 *`canDraw(participant)` 일관성* 의 결처럼, *딜러 차례 = 자기가 알아서 17까지 hit* 면 함수 내부에서 `while (dealer.canDraw()) { dealer.receiveCard(...) }` 가 자연. `return true/false` 가 *카드 한 장이라도 받았는지* 알리는 시그널이라면 *함수명이 `tryDealerDraw()`* 같은 *시도 메시지*가 자연.
+
+### 2. `Player.canDraw()` 미구현 — *Player/Dealer 메시지 비대칭*
+
+```kotlin
+// Dealer
+fun canDraw(): Boolean = state.hand.score() <= DEALER_HIT_SCORE
+
+// Player — canDraw 메서드 없음. Controller가 state.hand.score 직접 검사하거나 외부 입력
+```
+
+페로로 (BlackjackGame.kt 미해결): *"딜러입장에서 더 뽑을 수 있는지는 게임에서, 플레이어입장에서 더 뽑을 수 있는지 여부를 컨트롤러에서 판단하는데 일관성이 떨어져 보입니다. > 카드를 더 뽑을 수 있는지 확인하고 카드를 뽑는다 라는 기능 아래에서는 딜러인지 플레이어인지 상태가 어떤지는 함수 스스로 판단하면 되지 않을까요?"*
+
+페로로 힌트:
+```kotlin
+fun canDraw(participant: Participant): Boolean {
+    // 플레이어 → ???
+    // 딜러 → ???
+}
+fun drawTo(participant: Participant) { ... }
+```
+
+→ **`Participant.canDraw()` 메시지로 통일하면 호출자 분기 사라짐**. *Player는 *입력 의지 + 21 이하**, *Dealer는 *17 이하**. *Strategy 차이*는 *Participant 다형성*. 현재는 *Dealer만 canDraw* + *Player는 외부 입력으로만 결정* → *대칭 메시지 부재*.
+
+### 3. `Finish.expectedProfit(money)` + `Finish.profit()` + `Finish.profitRate` — *세 책임 중첩*
+
+```kotlin
+abstract class Finish(override val hand: Hand) : State {
+    abstract val profitRate: Float
+
+    override fun expectedProfit(money: Money): Money = money * profitRate
+    override fun profit(): Float = profitRate
+    override fun draw(card: Card) = throw IllegalStateException("...")
+    override fun stop() = throw IllegalStateException("...")
+}
+
+class Blackjack(override val hand: Hand) : Finish(hand) {
+    override val profitRate: Float get() = BLACKJACK_PROFIT  // 1.5f
+    override fun profit(): Float = profitRate  // ⚠ Finish의 profit과 중복 override
+    companion object { const val BLACKJACK_PROFIT = 1.5f }
+}
+```
+
+페로로 (Finish.kt — 미해결): *"profit() 함수가 무엇을 하고싶은지 전달이 잘 안되는 것 같아요. 입력받는 돈이 없는데 배율만 반환하면 어떤 뜻인가요?"*
+
+학생 자가 답변: *"아 이 부분은 저의 실수라고 생각합니다. 처음에 profitRate 필드를 private으로 두고 이를 읽는 메서드를 만들어야겠다! 라고 생각했습니다. 하지만, public으로 필드를 만드면서, 결국 필요없는 부분이였는 데, 아직까지 쓰고 있군요...."*
+
+페로로 (PlayerGameResult.kt — 미해결): *"저는 Result가 무엇을 의미하는지 잘 모르겠어요. 다른 개발자가 보더라도 아! 이게 수익금이구나! 라고 바로 이해할 수 있을까요?"*
+
+→ **`profitRate` (val) + `profit()` (배율 반환) + `expectedProfit(money)` (금액 반환)** 의 *3중 표현*. *수익률 vs 수익금*이 *이름에 안 보임*. *`Money.expectedProfit(state)`* 처럼 *Money가 자기 곱하기 메시지*면 *State는 배율만 노출* + *Money가 곱셈 담당*. PR #133 (시아 2단계) 의 *Money.times 오버로딩* 과 같은 결.
+
+또한 `profitRate` 가 *Blackjack/Stay/Bust 별 const* — *enum* 으로 묶는 게 자연 (1.5/1.0/-1.0). 현재 *클래스 3개에 const 분산*.
+
+### 4. `PlayerGameResult.playerProfitRate()` — *State 분기를 호출자가 다시 함*
+
+```kotlin
+class PlayerGameResult(
+    private val dealer: Dealer,
+    private val player: Player,
+) {
+    fun playerProfitRate(): Float {
+        val dealerState = dealer.state
+        val playerState = player.state
+
+        if (dealerState is Blackjack && playerState is Blackjack) return GameResult.PUSH.profit
+        if (dealerState is Blackjack && playerState is Stay) return GameResult.LOSE.profit
+        if (dealerState is Bust && playerState is Stay) return GameResult.WIN.profit
+        if (dealerState is Stay && playerState is Stay) return getStayResult(dealerState, playerState)
+        return playerState.profit()
+    }
+    ...
+}
+```
+
+페로로 (Finish.kt 첫 코멘트): *"참가자가 수익률을 계산하는 관점과 State가 수익률을 계산하는 관점은 서로 다릅니다. 상태 입장에서는 단순히 현재 상태에 따른 수익률만 계산하는 반면 플레이어의 수익률은 상대의 패를 같이 확인하게 됩니다. **그렇다면 참가자 -> 상태 -> 형태로 협력하는 관계로 만들 수 있지 않았을까요?** 하나의 예로, 딜러와 플레이어가 모두 블랙잭이면 무승부입니다."*
+
+학생 자가 답변 (커밋 `9c6ed42`): *"페로로, 페로로가 준 힌트를 통해서, gameReult라는 클래스를 만들어서 결과를 처리하게 되었습니다. 하지만, 시간이 너무 부족해져서 좀 더 말끔하게 적지 못했습니다."*
+
+→ **State 패턴의 이점 = 분기 제거. 그런데 PlayerGameResult가 *`is Blackjack && is Stay`* 같은 *상태 타입 분기 4개*를 다시 함**. *State 패턴 도입 = 분기 제거*가 아니라 *분기 이동*에 그침. *Participant.compete(other: Participant): GameResult* 메시지로 *state 안에서 상대 상태와 비교*면 *외부 if문 사라짐*. 페로로의 *"참가자 → 상태 → 협력"* 이 그 의미.
+
+또한 *Bust 양측 처리 누락* — `is Bust && is Bust` 분기 없음. *마지막 fallback `playerState.profit()`* 으로 *Bust profit = -1f* 가 적용되지만 *Bust dealer & Bust player*는 *명시 안 됨*. 룰 정확성 신호.
+
+### 5. `BlackjackGame.firstTurn()` — *Players + Dealer 카드 1:1 분배 + 첫 카드 공개 규칙 누락*
+
+```kotlin
+fun firstTurn() {
+    repeat(FIRST_CARD_COUNT) {
+        giveCard(cardDeck)
+    }
+}
+
+private fun giveCard(cardDeck: CardDeck) {
+    dealer.receiveCard(cardDeck.pickCard())
+    players.giveCardForPlayer(cardDeck)
+}
+```
+
+→ **딜러는 1장 공개 / 플레이어는 2장 공개**라는 *블랙잭 룰* 이 *firstTurn 의 분배 규칙*에 새겨 있지 않음. *`repeat(2) { dealer + players }`* 는 *분배 규칙*. *공개 규칙*은 *View 에서 분기*로 표현되고 있을 가능성.
+
+페로로 (1단계 OutputView.kt:30 미해결 — 본 PR에서 *직접 코멘트는 없으나 1단계의 미해결 사항*): *"최초에 딜러는 1장의 카드를, 플레이어는 2장의 카드를 공개한다 라는 규칙이 있을거에요. 이 규칙은 명확한 비즈니스 로직인데 어떻게 구현할지 추상화 관점에서 접근해보면 도움이 될거에요."*
+
+→ *Participant.openCards(): Hand* 메시지면 *Dealer는 1장 / Player는 2장*을 자기가 결정. *View는 받은 카드만 출력*. 현재는 미반영.
+
+### 6. `Players.giveCardForPlayer(cardDeck)` — *deck 매개변수 노출*
+
+```kotlin
+// BlackjackGame
+private fun giveCard(cardDeck: CardDeck) {
+    dealer.receiveCard(cardDeck.pickCard())
+    players.giveCardForPlayer(cardDeck)  // ⚠ deck을 Players에 넘김
+}
+```
+
+페로로 (BlackjackGame.kt 미해결): *"일급 컬렉션으로 묶었으면 Players에게 메시지를 보내도록 해주세요~"*
+
+학생 자가 답변: *"페로로, 일급 컬렉션이 Players에서 일을 시키기위해서, 공통된 카드 덱을 쓰게 해주기 위해서, 매개변수로 cardDeck자체를 넘겨주고 있는 데, 이게 괜찮은 건지 모르겠어요..... 😭"*
+
+페로로 후속: *"왜 괜찮지 않다고 생각하나요?"*
+
+→ **`deck`을 매개변수로 노출 vs 카드 한 장만 전달**. *Players.giveCardForPlayer(cardDeck)* 는 *Players가 deck.pickCard()를 호출* — *Players가 deck을 안다*는 결합. *Players.receiveCard(cards: List<Card>)* 면 *deck 의존 없음*. PR #133 (시아 2단계) 의 *말리빈 "Deck을 손에 쥐여줘야할지"* 동일 결.
+
+다만 *카드 한 장씩 vs 한 번에 N장* 의 트레이드오프 — *분배 룰이 외부 (Game) 결정*이면 *Players는 받은 카드 그대로 추가*가 자연. *공유 deck = Game이 보유 + 카드만 분배*.
+
+### 7. `BettingTable.getProfit()` + `getProfit(profitRate)` 오버로딩 — *어느 것이 호출되는지*
+
+```kotlin
+class BettingTable(
+    val participant: Participant,
+    private val bettingAmount: Money,
+) {
+    fun getProfit(): Money {
+        val participantState = participant.state
+        return participantState.expectedProfit(bettingAmount)
+    }
+
+    fun getProfit(profitRate: Float): Money = bettingAmount * profitRate
+}
+```
+
+페로로 (BettingTable.kt 미해결): *"그런데 논리적으로 실행할 수 없는 동작이라면 상태 내부에서 스스로 판단하는게 맞지 않을까요? 상태를 분리하는 것 대비 여기저기 if문으로 타입 검사를 하는게 오히려 분리한 이점을 낮추고 있습니다. 아래 두개는 어떤 차이가 있을지? State.profit() / Finished.profit()"*
+
+→ **`getProfit()` 두 시그니처 — *State 위임 vs 외부 profitRate 주입***. *호출자가 둘 중 어느 것을 부르는지* 가 *상황에 따라 달라짐* — *PlayerGameResult.playerProfitRate()* 로 계산한 profitRate를 다시 *BettingTable.getProfit(profitRate)* 에 넘기는 흐름이라면 *State 책임이 깨짐*. *BettingTable* 이 *Participant + Money* 만 보유 = *Participant 책임의 보조 클래스* — *별도 객체 필요한가* 도 의문.
+
+학생 자가 답변 (커밋 `aa4b8a5`): *"현재 저의 관점에서 보기에 범위 차이로 보입니다. state는 아주 넓은 범위이기 때문에 만약 hit이나 startGame에서 profit을 구할려면 에러가 날것입니다. 하지만, finish에서 구하면, 에러없이 제 값을 구할 수 있는 상태가 될 것입니다. ... state에서 구현을 하고 finish가 아닌 구역에서는 스스로 에러를 뱉어낼 수 있도록 해야할 거 같습니다."*
+
+→ *State 인터페이스에 expectedProfit 선언 → Hit/StartGame은 throw* 결정. *if문 회피 = 좋은 면* 이지만 *런타임 throw* 가 *호출자가 분기 안에서 안전한가*를 의심하게 함. *진짜 분기 제거*는 *컴파일 타임 sealed 다형성* (못한 점 §8).
+
+### 8. `interface State` 가 *sealed 가 아님* — *외부 구현 가능 + when exhaustive 불가*
+
+```kotlin
+interface State {
+    val hand: Hand
+    fun expectedProfit(money: Money): Money
+    fun profit(): Float
+    fun draw(card: Card): State
+    fun stop(): State
+}
+```
+
+→ **State 상태 종류 = 5개 (StartGame/Hit/Bust/Blackjack/Stay) 라는 *닫힌 집합***. *Kotlin `sealed interface State`* 면 *컴파일러가 when exhaustive 검사* + *외부 패키지 구현 차단*. `is Blackjack && is Stay` 같은 *타입 분기*가 *when (state)* 패턴 매칭으로 표현 가능. *호출자 분기 안전성 ↑*.
+
+`PlayerGameResult.playerProfitRate()` 의 *4 단계 if + fallback* 이 *sealed when* 이면 *모든 조합* 처리 강제. *Bust 양측 처리 누락* 도 컴파일러가 잡음. PR #133 (시아 2단계) 의 *sealed 키워드 토론* 과 *부분적으로 같은 결*.
+
+### 9. `Hit.draw` 의 *블랙잭 룰* 이 *상태 전이 분기*에 내장 — *Ace 11 보정 미반영 신호*
+
+```kotlin
+override fun draw(card: Card): State {
+    val newHand = hand + card
+    val score = newHand.score()
+    return when {
+        score < BLACKJACK_SCORE -> Hit(newHand)
+        newHand.size == FIRST_CARD_COUNT && score == BLACKJACK_SCORE -> Blackjack(newHand)
+        score > BLACKJACK_SCORE -> Bust(newHand)
+        else -> Stay(newHand)
+    }
+}
+```
+
+→ **score 계산이 `newHand.score()` 한 줄에 들어 있어 Ace 1↔11 양가성 처리는 Hand 내부**. 1단계의 *Cards.calculateScore* 의 *Ace 단일 +10* 패턴이 *Hand.score* 로 이전되었을 것. 본 PR에서는 Hand 코드를 직접 보기 어려우나 *score == 21* 조건이 *Ace 11 보정 후*인지 *Ace 1 기본*인지가 *블랙잭 판정 정확성* 결정.
+
+`size == FIRST_CARD_COUNT && score == BLACKJACK_SCORE`이 *Blackjack(2장 21)* 룰 정확. *Stay(score == 21 but size > 2)* 와 *Bust (score > 21)* 분리 정합. 다만 *score == 21 도달*은 *Ace 11 인식*에 의존 — *Ace 1 기본일 때 score == 11 → +10 → score == 21*. *Hand.score* 가 *최대 21 이하 점수 반환* 룰을 따른다면 OK.
+
+### 10. `Money` 가변/불변 — `value class` 사용은 좋으나 *`Float` 산술 정밀도 손실*
+
+```kotlin
+@JvmInline
+value class Money(val value: Int) {
+    operator fun times(floatNumber: Float): Money = Money((this.value * floatNumber).toInt())
+    operator fun times(intNumber: Int): Money = Money(this.value * intNumber)
+}
+```
+
+→ **`Float` 산술 + `Int` 변환 = 정밀도 손실**. *1000 * 1.5f = 1500.0f → 1500* OK. *1000 * 1.5f = 999.99996f* 같은 케이스 발생 가능 (Float 표현 한계). *수익률 = BigDecimal 권고* 가 *금융 도메인 표준*. PR #133 의 *Money 가변/연산자 오버로딩* 토론과 같은 결.
+
+또한 `times(Float)` 와 `times(Int)` 만 있고 *`plus`/`minus`* 없음 — *베팅 금액 더하기/빼기*는 *호출자가 `Money(a.value + b.value)`* 로 우회. *완전한 산술 추상화 미달*.
+
+### 11. `BlackjackGame.playerTurn(player)` — *한 장만 받음 + 호출자가 루프*
+
+```kotlin
+fun playerTurn(player: Player) {
+    player.receiveCard(cardDeck.pickCard())
+}
+```
+
+페로로 (BlackjackController.kt:61 미해결): *"디테일한 요소지만, 필요하다면 게임이 컨텍스트를 더 가지고 있도록 만들어도 괜찮을 것 같습니다. 어찌되었든 컨트롤러에서 로직을 최소화 하는 과정이 되니까요. `while (blackjackGame.canDraw(player) && askDraw(player)) { ... }`"*
+
+→ **`playerTurn(player)` 가 *한 장만 받음* + *Controller가 askDraw → canDraw → playerTurn 루프 책임***. *Controller god-object* 진단은 1단계에서 *BlackjackGame 도입*으로 일부 해소. 다만 *플레이어 차례 = 카드 받는 입력 루프*가 *Game 책임*인지 *Controller 책임*인지 *경계 모호*. 페로로의 `while (blackjackGame.canDraw(player) && askDraw(player))` 가 *입력 인터페이스를 콜백 인자*로 받는 *고차함수* 패턴 — *Game 내부 루프 + 콜백으로 UI 분리*. PR #131 (다이스 2단계 콜백) / #132 (환노 2단계 고차함수) 와 같은 결.
+
+### 12. `Hit.stop()` → `Stay(hand)` + `StartGame.stop()` → `Stay(hand)` — *카드 0장 Stay 허용*
+
+```kotlin
+// StartGame.stop
+override fun stop(): State = Stay(hand)
+```
+
+→ **StartGame.stop = 카드 받기 전 stop 가능**. *카드 0장으로 게임 종료 → Stay 상태*. *블랙잭 룰* 상 *최소 2장 받고 게임 시작* 이 표준. *Stay(emptyList())* 는 *도메인 invariant 위반*.
+
+학생 자가 답변: *"먼저, stop()했을 때는 카드를 더 이상 받지 않는다는 의미로 finish인 상태로 넘기기 위해서, 메서드를 생성했습니다. 그럼 왜 Hit가 아닌 interface에서 선언을 하였는가? 라고 생각할 수도 있습니다. 이때 생각한 관점은 언제든 플레이어가 게임을 끝낼 수 있어야하지 않을까? 라는 관점이였습니다. 카드를 한장만 받고 게임을 끝낼 수도 있어야 한다고 생각을 해서, interface 함수로 선언했습니다."*
+
+→ **학생 의도 = "언제든 게임 끝낼 수 있어야"**. *블랙잭 도메인 룰* 과 *Kotlin 인터페이스 메서드 일관성*의 트레이드오프. *진짜 도메인은 첫 2장 분배 후 stop 가능*. *StartGame.stop 자체가 도메인에서 호출 안 됨*이 *현실*이라면 *StartGame은 Finish(stop) 메서드 throw*가 자연.
+
+### 13. `Money` 입장에서 `profit` 관심사 — *Money 책임 누수*
+
+```kotlin
+@JvmInline
+value class Money(val value: Int) {
+    operator fun times(floatNumber: Float): Money = Money(...)
+    operator fun times(intNumber: Int): Money = Money(...)
+}
+```
+
+페로로 (Money.kt 첫 코멘트): *"Money 입장에서 단순히 곱하기만 하고 싶은데 profit이라는 관심사가 필요한가요?"*
+
+학생 자가 답변 (커밋 `4351003`): *"페로로 말처럼 money 입장에서는 profit이라는 관심사가 필요없을 것같아요! 다만 파라미터로 float가 들어오거나, int 타입이 들어왔을 때, 모두다 계산할 수 있도록 오버로딩해서, 메서드를 만들었습니다."*
+
+페로로 후속: *"커밋에 또 이상한게 섞였군요.. 😓"*
+
+→ **`Money.profit()` 같은 메서드가 초기 코드에 있었던 흔적**. 후속 반영으로 *`Money.times` 만 남김* — *Money 가 자기 곱셈 메시지*만. *수익률 결정 = State 책임*, *수익금 계산 = Money 책임*으로 *책임 분리* 시도. 다만 PlayerGameResult 가 *State 분기를 다시 함* (못한 점 §4) 이라 *완전한 분리 미달*.
+
+### 14. `CardDeck` private constructor — *테스트 가능성 의문 + 학생 자가 토론*
+
+```kotlin
+// CardDeck.kt — private constructor
+// 학생: 항상 랜덤 셔플된 상태로 시작
+```
+
+페로로 (CardDeck.kt:16 미해결): *"private constructor로 만들었는데 항상 랜덤에 의존하면 CardDeck 테스트는 어떻게 해야 하나요?"*
+
+학생: *"페로로 저는 카드덱에 들어가는 카드들은 항상 랜덤인 상태로 있어야한다고 생각을 했습니다. 현실 세계의 카드 덱들은 항상 카드가 섞어진 체로 게임 준비가 되어있기 때문입니다."*
+
+페로로: *"카드들이 랜덤으로 있는 건 현실세계에서 고려한 스펙 아닌가요? 만약 랜덤으로 있는 카드가 아닌 순서대로 있는 카드덱을 준비해야 하면 어떻게 해야하나요?"*
+
+학생: *"만약 순서대로 있는 카드덱이 필요하다고 하면, 생성자를 public으로 열어두겠습니다! 페로로 게임이 시작할려면, 저는 카드가 섞어있어야 한다고 생각을 하는 데, 이 생각이 너무 현실 기반일까요...?! 혹시 페로로가 순서대로 있는 카드덱을 고려하게 된 이유가 궁금합니다!!"*
+
+→ **현실 룰 vs 테스트 가능성**. *현실 카지노 = 항상 셔플된 덱* 이지만 *테스트 = 결정적 순서 필요*. *전략 패턴 (ShuffleStrategy)* 으로 *RandomShuffle (현실) / IdentityShuffle (테스트)* 주입이 정공 — PR #108 (시아 1단계) 의 *ShuffleStrategy* 후속 결정. 학생이 *"private constructor + 항상 랜덤"* 으로 *현실 룰을 strict로 강제*. *테스트 = 셔플된 덱 안에서 어떤 순서가 나올지 검증* 으로 *간접 테스트* 가능하나 *결정적 시나리오 테스트* 불가능.
+
+### 15. `state.hand.cards` 반복 표현 — *Demeter 위반 표면*
+
+페로로 (BlackjackView.kt 미해결): *"`participant.state.hand.cards` 저는 이 반복되는 코드 자체를 줄일 방법을 고민하기를 의도했습니다."*
+
+학생 자가 답변 (커밋 `7627937`): View 안 `showCards(participant: Participant): List<String>` 헬퍼 추출 — *participant만 받아 안에서 카드 추출*. 학생: *"하지만, 드는 생각은 view만을 위한 메서드를 도메인 안에 만드는 것이 맞나? 라는 생각에 view에서 함수로 구현했습니다."*
+
+페로로 후속: *"너무 어렵게 생각하지 말고 우선은 현재 파일에서 코드중복이 발생하는것을 줄여보자. 라는 관점으로 접근해주시면 좋겠어요"*
+
+→ **`participant.state.hand.cards` = *Demeter 위반의 표면 신호***. *participant.cards()* 메시지면 *내부 구조 노출 0*. *View가 도메인 메서드 의존하는가* 의 트레이드오프 — *Demeter 준수 + Participant.cards()* 가 자연. *View 헬퍼* 는 *코드 중복 해소 의도*만 충족, *Demeter 위반 해소 X*.
+
+### 16. `Participant.state.update` 의 의미 모호 — *행위 vs 결과 네이밍*
+
+```kotlin
+// 초기 코드 — Participant
+fun updateState(card: Card) { state = state.draw(card) }  // → 후속에서 receiveCard 로 변경
+```
+
+페로로 (Participant.kt 미해결): *"카드 한장을 건네준다는 행위가 상태를 바꾼다는게 어떤 의미인가요? 카드를 더하는건지 빼는건지 복사하는건지 의미가 전달이 되고 있나요?"*
+
+학생 자가 답변 (커밋 `2706164`): *"페로로 메서드명을 지을 때, 행위의 결과로 네이밍을 하는 것이 아니라, 행위 그 자체를 네이밍하는 것이 좋다고 하는 걸까요...?"*
+
+페로로: *"말 그대로입니다. 아무 개발자가 와서 봤을 때 유저.업데이트스테이트 라는 행위가 어떤 동작을 할지 예측할 수 있나요?"*
+
+→ **`updateState(card)` = 결과 네이밍 / `receiveCard(card)` = 행위 네이밍**. *Tell-Don't-Ask* 의 메시지는 *행위*. *상태 변경*은 *행위의 결과*. *호출자에게 "내가 카드 받았어"* 가 *"내 상태 바꿔"*보다 자연.
+
+### 17. `BettingTable.bettingAmount: Money` — *Bust일 때 0원 테스트 오류*
+
+페로로 (BustTest.kt 미해결): *"버스트인데 왜 배팅금이 0원이되나요?"*
+
+학생 자가 답변 (커밋 `55df417`): *"이 부분은 제가 실수했습니다! 알려주셔서 감사합니다."*
+
+→ **테스트 시나리오 오류 = 도메인 룰 이해 신호**. *Bust → 베팅금 -1배 (-bettingAmount)*. *0원이 아님*. *학생 단순 실수*로 자가 반영. *Money * (-1f) = -Money* 으로 *베팅금 잃음* 표현. *부호가 잘림*하는지 Money value class 의 *Int 음수 표현* 호환성도 검증 필요.
+
+### 18. 테스트 이름이 *함수명 그대로* — *기능 관점 부재*
+
+```kotlin
+// BlackjackGameTest.kt — 함수명 그대로 테스트 이름
+@Test
+fun `playerTurn() 함수 테스트`() { ... }
+```
+
+페로로 (BlackjackGameTest.kt 미해결): *"특정 함수 이름을 테스트에 그대로 작성하는 것은 좋지 않습니다. 만약 함수 이름이 변경되더라도 테스트 코드를 같이 수정해야 한다는 것을 실수하기 쉽고 기능 관점이 아닌 함수 이름에 종속됩니다."*
+
+페로로 (DealerTest.kt:46 미해결): *"이 테스트 이름은 적절한가요???"*
+
+페로로 (DealerTest.kt 미해결): *"마찬가지로 특정 상태로 업데이트 한다는게 뭘 테스트 하고 싶은건지 드러나고 있지 않습니다."*
+
+→ **테스트 이름 = 기능 명세**. *함수명 그대로* = *함수명 바뀌면 테스트 이름 부정합 + 의도 노출 0*. *"플레이어가 카드를 받으면 hand 점수가 증가한다"* 같은 *기능 관점* 이름이 자연. PR #128·#135·#114·#125·#124 와 같은 결.
+
+### 19. `run()` 함수 복잡도 — *Controller 절차적 명령*
+
+페로로 (BlackjackController.kt 미해결): *"어쩌다보니 run() 함수가 너무 복잡해졌는데 수정중이라고 보았습니다. 이런 부분도 마저 다듬어 주시면 좋을 것 같네요"*
+
+학생 자가 답변 (커밋 `123eb71`): *"함수를 추출해서 조금 더 간결하게 만들어 보았습니다!"*
+
+→ **`run()` 의 절차 호출** = *Controller 가 게임 흐름을 명령형으로 기술*. *함수 추출*은 *세분화* 이지만 *Controller god-object 책임* 자체는 미해결. 페로로의 1단계 *"컨트롤러 없이 게임을 진행할 수 있을까요?"* 진단의 연장.
+
+### 20. `PlayerBehavior` enum 잔존 + 미사용 가능성
+
+```kotlin
+// PlayerBehavior.kt (1단계 그대로)
+enum class PlayerBehavior { HIT, STAY }
+```
+
+→ State 패턴 도입 후 *`PlayerBehavior` enum 이 입력 변환 단계에만 살아 있을 가능성*. State 안에 *Hit/Stay* 가 *클래스로* 존재하므로 *PlayerBehavior enum* 은 *입력 의도 표현*만 담당. *State 와의 매핑* 위치가 *Controller인가 InputView인가* 의 토론은 PR #132 (환노 2단계) 와 같은 결.
+
+### 21. *룰 상수의 분산* — `Hit.BLACKJACK_SCORE` / `Hit.FIRST_CARD_COUNT` / `Blackjack.BLACKJACK_PROFIT` / `Stay.STAY_PROFIT` / `Bust.BUST_PROFIT` / `Dealer.DEALER_HIT_SCORE` / `BlackjackGame.FIRST_CARD_COUNT`
+
+→ **전역 상수 분리는 잘된 면 (자가 답변 §1)** 이지만 *동일 의미 상수가 두 클래스*에 등장:
+
+- `Hit.FIRST_CARD_COUNT = 2`
+- `BlackjackGame.FIRST_CARD_COUNT = 2`
+
+*같은 상수의 두 곳 정의* = *변경 시 동기화 누락 위험*. *Hit가 자기 룰 알고 / BlackjackGame이 자기 분배 룰 알고* 의 *우연한 같은 값*인지 *공유해야 할 룰*인지 *근거 명시 부재*. *PlayerGameResult* 도 *블랙잭 1.5배 + Stay 1.0배 + Bust -1.0배* 의 *Finish 서브클래스 const* 를 *enum (`GameResult.WIN/LOSE/PUSH`)* 와 *별개 표현*. **두 표현 (`Finish.profitRate` const vs `GameResult.profit` enum) 이 같은 의미를 다른 형태**.
+
+### 22. *블랙잭(Finish) → Stay(Finish) 전이 미구현* — 학생이 알아챈 부분
+
+학생 PR 본문 인용: *"딜러(블랙잭) vs 플레이어(블랙잭) → 플레이어 수익률은 stay의 1.0을 바라봐야함. 이렇게 플레이어의 상태를 블랙잭에서 스테이로 업데이트 해야되더라구요. 이 과정이 개인적으로 느끼기에 매끄럽지 않아 구현이 제대로 되지 않았습니다."*
+
+페로로 답변 (Finish.kt 첫 코멘트): *"참가자가 수익률을 계산하는 관점과 State가 수익률을 계산하는 관점은 서로 다릅니다."*
+
+→ **블랙잭 vs 블랙잭 → PUSH 처리를 위해 *블랙잭 → Stay 전이* 가 필요하다는 학생 해석은 *State 의미 오해***. *상태 자체* 는 *블랙잭 그대로 유지*. *결과 (PUSH)* 는 *비교 시점*에 결정. *Participant.compete(other)* 메시지가 *블랙잭 vs 블랙잭 = PUSH* 를 *별도 상태 전이 없이* 표현. 페로로의 *"상태 입장에서는 단순히 현재 상태에 따른 수익률만 계산하는 반면 플레이어의 수익률은 상대의 패를 같이 확인"* 진단이 정확.
+
+## 리뷰어 의견 요지
+
+- **상태 분리의 이점 = if문 제거** — `if (state is X)` 가 *상태 분리 도입한 의미를 다시 까먹는 신호*. *다형성*으로 *호출자 if 0개*.
+- **참가자 → 상태 → 협력** — *PlayerGameResult가 dealer.state·player.state 분기*는 *상태 정보를 빼서 외부에서 비교*. *Participant 메시지*로 *상태 협력*.
+- **상태 분리 + 논리적 실행 불가 = 상태가 스스로 throw** — `Hit.profit()` throw는 *상태 자체 가드*. *호출자 if 회피*. 다만 *런타임 예외* < *컴파일 타임 sealed*.
+- **메서드명 = 행위 + 결과 → 행위만** — `updateState(card)` 는 *결과 (state 업데이트)*. `receiveCard(card)` 는 *행위*. *호출자 친화 = 행위 메시지*.
+- **공통 상수 객체 = 비즈니스 로직과 결합** — 모든 객체가 *전역 Rule 의존*하면 *Rule 수정의 파급 범위* 가 클래스 전체. *각 객체 자기 상수*가 자율성.
+- **테스트 이름 = 함수명 X / 기능 관점 O** — *함수명 종속 = 함수명 변경 시 테스트 부정합*. *기능 관점 = 도메인 명세*.
+- **`participant.state.hand.cards` = Demeter 위반 표면**. *Participant 메시지*로 *카드 노출*.
+- **현실 룰 (`항상 셔플된 덱`) vs 테스트 가능성 (`결정적 순서`)** — *전략 패턴*으로 둘 다 만족 (1단계 학생이 자가 발견 → 2단계에서 다시 *private constructor + 랜덤* 으로 회귀하는 듯한 신호).
+- **확장성 = 도메인 요구가 부를 때** — `Money.times(Float)` + `Money.times(Int)` 오버로딩이 *현재 사용처가 *Float 만 있는데도 Int 추가*. *YAGNI*.
+
+## 대표 인용
+
+**페로로 (참가자 → 상태 협력, Finish.kt):**
+> 참가자가 수익률을 계산하는 관점과 State가 수익률을 계산하는 관점은 서로 다릅니다.
+> 상태 입장에서는 단순히 현재 상태에 따른 수익률만 계산하는 반면 플레이어의 수익률은 상대의 패를 같이 확인하게 됩니다.
+> 그렇다면 참가자 -> 상태 -> 형태로 협력하는 관계로 만들 수 있지 않았을까요?
+> 하나의 예로, 딜러와 플레이어가 모두 블랙잭이면 무승부입니다.
+
+**페로로 (메시지 일관성, BlackjackGame.kt):**
+> 딜러입장에서 더 뽑을 수 있는지는 게임에서, 플레이어입장에서 더 뽑을 수 있는지 여부를 컨트롤러에서 판단하는데 일관성이 떨어져 보입니다.
+> > 카드를 더 뽑을 수 있는지 확인하고 카드를 뽑는다
+> 라는 기능 아래에서는 딜러인지 플레이어인지 상태가 어떤지는 함수 스스로 판단하면 되지 않을까요?
+
+**페로로 (상태 분리 이점 = if문 제거, BettingTable.kt):**
+> 그런데 논리적으로 실행할 수 없는 동작이라면 상태 내부에서 스스로 판단하는게 맞지 않을까요?
+> 상태를 분리하는 것 대비 여기저기 if문으로 타입 검사를 하는게 오히려 분리한 이점을 낮추고 있습니다.
+
+**페로로 (행위 vs 결과 네이밍, Participant.kt):**
+> 카드 한장을 건네준다는 행위가 상태를 바꾼다는게 어떤 의미인가요?
+> 카드를 더하는건지 빼는건지 복사하는건지 의미가 전달이 되고 있나요?
+> ...
+> 아무 개발자가 와서 봤을 때 유저.업데이트스테이트 라는 행위가 어떤 동작을 할지 예측할 수 있나요?
+
+**페로로 (전역 상수 결합도, BlackjackRule.kt):**
+> 특정 비즈니스 로직이 공통 상수에 결합되는건 좋지 않다고 생각합니다.
+> 반대로 모든 객체들이 Rule에 의존하게 되어서 하나의 Rule을 쉽게 수정하지 못하게 되지 않나요?
+> Rule이라면 상황에 따라 다른 룰을 적용할수도 있다는 뜻일텐데 게임마다 다른 규칙을 적용하는게 가능할까요?
+> 단 1번만 사용되는데도 불구하고 우선 공통 상수로 빼는 건 좋지 않은 습관입니다.
+> 각 객체가 스스로 판단할 수 있도록 시작하는게 좋습니다.
+
+**페로로 (확장성 = 1.5배 신호, BetAmount.kt 결):**
+> 승패여부, 블랙잭 상관 없이 배율(earningRate)이라는 개념을 넘겨주는 방식은 어떨까요?
+> > 블랙잭은 1.5배, 버스트는 -1배
+
+**페로로 (Money의 관심사 분리):**
+> Money 입장에서 단순히 곱하기만 하고 싶은데 profit이라는 관심사가 필요한가요?
+
+**학생 자가 답변 (블랙잭 → Stay 전이 미해결 신호):**
+> 딜러(블랙잭) vs 플레이어(블랙잭) -> 플레이어 수익률은 stay의 1.0을 바라봐야함.
+> 이렇게 플레이어의 상태를 블랙잭에서 스테이로 업데이트 해야되더라구요. 이 과정이 개인적으로 느끼기에 매끄럽지 않아 구현이 제대로 되지 않았습니다.
+
+**학생 자가 답변 (StartGame과 Hit(emptyList()) 차이, StartGame.kt):**
+> 아, 기능 목록에서 작은 기능으로 나누고 시작했습니다.
+> 기능을 나누다보니, 참가자들은 카드를 한장을 받는다부터 시작을 했습니다.
+> 카드를 한장을 받을 때는 카드를 받는 메서드만 필요하지 다른 판단하는 메서들은 필요가 없다고 생각했습니다. 객체를 좀 더 작게 나누고 싶어서, StartGame()으로 인스턴스를 먼저 생성했습니다.
+
+**학생 자가 답변 (Hit.stop과 StartGame.stop을 interface에 둔 이유):**
+> 먼저, stop()했을 때는 카드를 더 이상 받지 않는다는 의미로 finish인 상태로 넘기기 위해서, 메서드를 생성했습니다.
+> 그럼 왜 Hit가 아닌 interface에서 선언을 하였는가? 라고 생각할 수도 있습니다. 이때 생각한 관점은 언제든 플레이어가 게임을 끝낼 수 있어야하지 않을까? 라는 관점이였습니다.
+
+**학생 자가 답변 (엘레강트 오브젝트 - 빌더 함수 네이밍, PlayerGameResult.kt 결):**
+> 페로로! 엘레강트 오브젝트를 읽으면서, 빌더 함수의 네이밍에 대해서 배우게 되었습니다. 반환값이 있는 함수는 그 함수에게 바라는 것을 물어본다는 것을 배웠습니다. 그래서, 여기서는 수익률을 반환하니 playerProfitRate라고 네이밍을 바꿔보았습니다.
+
+## 얻은 교훈
+
+1. ***State 패턴 도입 = if문 제거를 위함. `is XX` 분기가 다시 나오면 다형성 미활용 신호***. wondroid-world 가 *State interface + StartGame/Hit/Bust/Blackjack/Stay* 로 *상태 일급화* 후에도 *PlayerGameResult.playerProfitRate* 가 *`is Blackjack && is Stay`* 4단 분기. *Participant.compete(other): GameResult* 메시지가 *상대 패와 비교까지 협력*하면 *외부 if 0개*. 페로로의 *"참가자 → 상태 → 협력"* 가 그 핵심.
+
+2. ***`sealed interface State` 가 정공 — 외부 구현 차단 + when exhaustive 검사***. *interface State* 는 *외부 패키지 구현 가능*. *Kotlin sealed*은 *닫힌 계층 = 컴파일러 보장*. *PlayerGameResult* 의 *4단 if + fallback* 이 *sealed when* 이면 *모든 조합 강제*. PR #133 (시아 2단계) 의 *sealed 키워드 토론*과 같은 결.
+
+3. ***메서드명 = 행위 메시지 (`receiveCard`), 결과 (`updateState`) 가 아님***. `updateState(card)` 는 *결과 알림*. `receiveCard(card)` 는 *행위 요청*. *Tell-Don't-Ask* 의 메시지는 *행위 동사*. 학생 자가 답변 *"행위의 결과로 네이밍 하는 것이 아니라, 행위 그 자체를 네이밍"* 이 정확.
+
+4. ***전역 Rule 상수 객체는 결합도 증가 + 자율성 손상***. *모든 객체가 BlackjackRule 의존*하면 *Rule 변경의 파급 범위* 가 *전체 클래스 = 변경 비용 ↑*. *게임마다 다른 룰* 가능성도 차단. *각 객체 companion 상수*가 *자기 책임의 일부*. PR #128·#135·#114·#125 와 같은 결.
+
+5. ***딜러 자율성 = `dealerTurn()` 안에서 17 이상까지 hit***. `while (dealer.canDraw()) { dealer.receiveCard(...) } / return false` 한 줄 안에 *호출 한 번에 끝나는 의미*. 현재 `while ... return true` 가 *while 첫 iteration 후 return* 으로 *루프 미작동* — 논리 오류. *호출자가 다시 반복 부르기*가 *딜러 룰을 외부에 떠넘김*.
+
+6. ***`canDraw()` 메시지를 Player와 Dealer 둘 다에 노출 = Participant 다형성***. *Player.canDraw()* 는 *21 이하 + 입력 의지*, *Dealer.canDraw()* 는 *17 이하*. *전략 차이 = 다형성*. *외부 if (`if (participant is Dealer)`) 0개*. PR #131·#132·#133 와 같은 결.
+
+7. ***`Money * profitRate` 가 정공 — `BettingTable.getProfit(profitRate)` 같은 우회 X***. *Money 가 자기 곱셈 메시지*. *State 가 profitRate 알림*. *Participant 가 결과 결정*. *세 책임 분리* 가 *Tell-Don't-Ask*. *오버로딩으로 두 getProfit* 은 *한 번에 둘 다 만족* 시도 = *책임 분리 미달*.
+
+8. ***`value class` + 연산자 오버로딩 = Kotlin 어휘***. *`@JvmInline value class Money`* 는 *런타임 박싱 없음 + 타입 안전*. *`operator fun times`* 가 *`money * 1.5f`* 자연 표현. 단 *`Float` 산술 정밀도 한계*는 *금융 도메인 시 BigDecimal 권고*.
+
+9. ***`Hit.stop()`이 의미 있는가? - 도메인 invariant 와 인터페이스 메서드의 트레이드오프***. *StartGame.stop = Stay(emptyList())* 는 *블랙잭 룰 위반 (최소 2장)*. *학생 의도 = "언제든 게임 끝낼 수 있어야"* 는 *모든 상태에 stop 메서드 강제*. *진짜 도메인 = 첫 2장 후 stop 가능*. *interface 메서드 일관성* < *도메인 invariant*. *sealed when 으로 `StartGame.stop` 가드*가 자연.
+
+10. ***`getXXX` 명사형 → 행위 동사***. `dealerTurn` (명사) / `playerTurn` (명사) 는 *차례를 가져옴*. *`takeDealerTurn()` / `runDealerTurn()`* 동사가 자연. *Kotlin 어휘 정착*.
+
+11. ***테스트 이름 = 기능 명세, 함수명 종속 X***. *함수명 그대로 테스트 이름*은 *함수명 변경 시 동기화 누락 + 의도 노출 0*. *"플레이어가 카드를 받으면 점수가 증가한다"* 같은 *기능 관점*이 자연. 도메인 변경 시 테스트도 *어휘 갱신*.
+
+12. ***`participant.state.hand.cards` = Demeter 표면 신호***. *Participant.cards()* 메시지가 *내부 구조 노출 0*. *View가 도메인 메서드 의존*은 *View가 Participant 인터페이스만 알면 됨* — *State / Hand 알 필요 없음*. *Demeter 준수의 핵심 = 호출자가 알아야 하는 객체의 수 최소화*.
+
+13. ***`StartGame` 과 `Hit(emptyList())` 차이 — 기능 단위 사고가 클래스 분리로 이어진 사례***. 학생 자가 답변 *"기능 목록에서 작은 기능으로 나누고 시작 → StartGame() 인스턴스 먼저"* 가 *기능 분해 → 클래스 분리* 패턴. *YAGNI vs 의도 명시* 트레이드오프 — *StartGame이 의미 있는 도메인 상태*면 OK, *Hit(emptyList())* 와 똑같은 행동이면 *중복*. *Hit.draw(첫 카드)* 와 *StartGame.draw(첫 카드)* 의 결과가 같다면 *StartGame 책임 정당화 부재*.
+
+14. ***1단계 진단 (`첫 턴 21 ≠ 카드 2장 21`)이 2단계 `Hit.draw`에서 완전 반영 — 학습 가시화 모범***. `newHand.size == FIRST_CARD_COUNT && score == BLACKJACK_SCORE -> Blackjack(newHand)` 로 *2장 21 = 블랙잭, 3장 21 = Stay* 분기 정확. PR #128·#135·#114·#125·#124 와 같은 결의 도메인 룰 정확성.
+
+15. ***Bust 양측 처리 누락 = 블랙잭 룰 정확성 신호***. PlayerGameResult 에 *`is Bust && is Bust`* 분기 없음. *마지막 `playerState.profit()` fallback* 이 *Bust -> -1f* 로 흡수하지만 *명시 부재*. *블랙잭 룰 = 양측 Bust = 양측 패배*. *sealed when* 이면 *컴파일러가 누락 신고*. PR #128·#135·#108·#124 와 같은 결.
+
+16. ***학생 자가 답변에 커밋 SHA 첨부 = 학습 가시화 모범 (지속)***. wondroid-world 가 1단계와 동일하게 *모든 자가 답변에 커밋 SHA* 첨부 (`4351003`, `4a3256f`, `51f6c0a`, `2706164`, `1c41c43`, `7627937`, `9c6ed42`, `2ee93c2`, `aa4b8a5`, `55df417`, `123eb71`, `a5d718d` 등). *학습 가시화 패턴 일관성*.
+
+17. ***엘레강트 오브젝트 자가 학습 — "반환값이 있는 함수는 그 함수에게 바라는 것을 물어본다"***. 학생이 *`PlayerGameResult` 의 `getResult` → `playerProfitRate`* 로 *반환값 의미 노출* 자가 반영. *외부 자료 학습 → 본인 코드 적용* 학습 모범. PR #108 (시아 1단계) 의 *Effective Kotlin Item 4/14* 와 같은 결.