oh-my-oop 0.2.0

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

@@ -0,0 +1,683 @@
+# PR #139 — [블랙잭 2단계] 제이 미션
+
+- **Reviewee:** [@parkjiminnnn](https://github.com/parkjiminnnn)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/139
+- **단계:** 2단계
+- **리뷰어:** [@woowahan-dino](https://github.com/woowahan-dino) (디노) — 1단계 #117 동일 reviewer
+- **라인 코멘트:** 12 스레드 — *PR 본문 자가 의문 2개 (object vs class + object 사용 시점) + 학생 진흙탕 코드 자가 인정 + 한판 vs 여러판 가정 (Player 변경) + Short-circuit evaluation 학습 + List<Player> → Players 일급 컬렉션 + currentScore → score 이름 단순화 + isBust 필드화 + dealerProfit 두 형태 통일 + abs 비교 불필요 자가 정정 + Dealer/Player cardNames 통일 + 플레이어마다 forEach 시 input 받기*
+- **양 단계 완성 reviewee** (1단계 #117 batch 19 분석 완료 + 2단계 #139 = batch 20 추가).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 인정 — *진흙탕 코드* 어휘 + 자가 의문 2개
+
+PR 본문:
+
+> *"안녕하세요 디노 🦖 머리가 생각보다 잘 안돌아가서 피드백을 먼저 받고 반영하여 리팩토링을 해볼까해서 pr을 먼저 올릴게요.. 비록 진흙탕 코드이지만 잘부탁드립니다..🥲"*
+
+→ **학생 자가 *피드백 → 리팩토링* 전략 + 자가 한계 인정**:
+- *"머리가 안돌아가서"* = *학습 부담 인정*.
+- *"피드백을 먼저 받고 반영하여 리팩토링"* = *제출 → 피드백 → 리팩토링 사이클 의식*.
+- *"진흙탕 코드"* = *자가 코드 한계 명시*.
+
+**MCP `oh-my-oop` *학습 = 시간 두고 반복* 어휘 합류** — *제출 시점이 완성 X*. PR #36·#87·#129·#138 결의 *학생 자가 한계 인정* 어휘 합류.
+
+**PR 본문 자가 의문 2개**:
+- ViewMapper.kt object vs class 블럭 어느 게 나을지?
+- object 는 주로 어떤 경우에 사용하나?
+
+→ **Kotlin 어휘 자가 학습** (PR #117 결의 *property val vs computed property* + PR #138 결의 *value class + @JvmInline + getOrNull + tailrec*) 합류.
+
+### 2. `Players` 일급 컬렉션 자가 적용 (PR #117 결 + by delegation)
+
+```kotlin
+class Players(private val players: List<Player>) : List<Player> by players {
+    val names: List<String> = players.map { player -> player.name }
+    val cardNames: List<List<CardName>>
+        get() = players.map { player -> player.cardNames }
+    val scores: List<Int>
+        get() = players.map { player -> player.score }
+    ...
+}
+```
+
+→ **`by` delegation + 일급 컬렉션** (PR #117 1단계 결 유지) + **반환 타입 도메인화** (`List<Player>` → `Players`).
+
+reviewer (Thread 1): *"여기 return type이 List<Player>말고 Players로 변경해볼 수 있겠네요"* → 학생 자가 적용.
+
+PR #21·#74·#108·#46·#117·#129·#138 결 합류.
+
+### 3. `Player.score` 이름 단순화 + 학생 자가 답변
+
+```kotlin
+val score: Int
+    get() = handCards.score
+```
+
+→ reviewer (Thread 4): *"currentScore가 어떤 의미 일까요?? 과거 스코어나 미래 스코어도 있을까요?? 이름이 길어지거나 부연설명이 붙으면 직관적이지 않게 됩니다. score로 하더라도 이해할 수 있을 것 같아보여요"*
+
+학생: *"카드가 추가될때마다 점수가 바뀌기 때문에 현재의 점수를 의미하는 currentScore로 했던건데 생각해보니 그냥 score로 해도 될 것같네용."*
+
+→ **이름 의미 정확성 = 부연설명 회피**. *current/total 같은 부연설명은 도메인 의미가 *과거/미래 분기* 일 때만 의미*. 블랙잭 = *현재 점수만 의미 있음* → *score 만으로 충분*.
+
+**MCP 룰 `name-redundant-qualifier` 후보** — *현재/총합 같은 부연설명 회피*. PR #117 (isHit → canHit) 결의 *이름 의미 정확성* 변형.
+
+### 4. `isBust` 필드화 + `isBlackJack` 필드 동일 패턴
+
+```kotlin
+abstract class Participant(...) {
+    val isBust: Boolean
+        get() = handCards.isBust
+    val isBlackJack: Boolean = handCards.isBlackJack
+    ...
+}
+```
+
+→ reviewer (Thread 5): *"이것들은 dealer나 player가 bust인 케이스니까 isBlackJack인 것처럼 필드로 만들면 어떨까요?"* → 학생 자가 적용.
+
+**상태 필드화** — *함수 호출 X + 필드 직접 접근 = 일관성*. 
+
+다만 **`isBlackJack: Boolean = handCards.isBlackJack` (즉시 초기화) vs `isBust: Boolean get() = handCards.isBust` (computed property) 양립**:
+
+- `isBlackJack`: *초기 2장 + 21점 = 인스턴스 생성 시 결정 + 불변* → *즉시 초기화 OK*.
+- `isBust`: *카드 추가 시마다 변경* → *computed property 필요*.
+
+PR #117 1단계 결의 *property val vs computed property* 학생 자가 적용. **MCP 룰 `property-val-vs-computed-property` 강화** 누적 2+ PR (#117·#139).
+
+### 5. Short-circuit evaluation 학생 자가 학습
+
+reviewer (Thread 3):
+
+> *"1번: `ScoreCalculator(cards).initialTotalCardScore == BLACKJACK_SCORE && handCards.size == INITIAL_CARDS_COUNT`*
+> *2번: `handCards.size == INITIAL_CARDS_COUNT && ScoreCalculator(cards).initialTotalCardScore == BLACKJACK_SCORE`*
+>
+> *의 차이가 뭘까요? 어떤 차이가 있는지 알아보시겠어요? hint: Short-circuit evaluation"*
+
+학생: *"먼저 연산자의 결과에 따라 뒤의 연산자의 실행여부를 결정한다는 내용이군용. 알려주셔서 감사합니당.🫠"*
+
+→ **Kotlin 어휘 자가 학습** — `&&` 평가 순서 = *왼쪽 false → 오른쪽 평가 X*:
+- 1번: ScoreCalculator 인스턴스 생성 비용 (initialTotalCardScore 계산) → 항상 발생.
+- 2번: handCards.size 체크 (cheap) → false 면 ScoreCalculator 생성 X.
+
+→ **비용 큰 평가는 뒤로** = *short-circuit 활용*.
+
+**MCP 룰 `short-circuit-evaluation-order` 후보** — *Boolean 연산자 평가 순서 최적화*.
+
+### 6. `abs` 비교 자가 정정 — when 분기로 필터링
+
+reviewer (Thread 10):
+
+> *"여기서 abs로 판단하는 이유가 어떤건지 궁금하네요. 저는 이렇게만 해도 된다고 생각하는데 제가 놓친 부분이 있을까요?"*
+
+학생 자가 정정:
+
+> *"step1때는 필요했었는데 지금 로직에는 위에서 블랙잭점수보다 참가자의 점수가 큰 경우가 when문에서 필터링 되서 필요없게 되었네용."*
+
+```kotlin
+private fun compareScores(player: Player): Float {
+    val dealerScore = dealer.score
+    val playerScore = player.score
+    return when {
+        playerScore < dealerScore -> -player.betAmount
+        playerScore > dealerScore -> player.betAmount
+        else -> ZERO
+    }
+}
+```
+
+→ **`abs` 제거 자가 정정** — *1단계 #117 의 abs 비교 (블랙잭 점수와 가장 가까운) 가 2단계에서 *isBust/isBlackJack 필터링* 이후 불필요*. **이전 미션 코드의 *불필요한 잔재* 자가 정리**.
+
+**MCP 룰 `dead-logic-from-previous-stage` 후보** — *이전 단계 로직 잔재 정리*. PR #117 (블랙잭 룰 abs 비교 와전) 결의 *2단계 자가 정정*.
+
+#### 6.1. *PR #117 → PR #139 진화*
+
+PR #117 (1단계) `abs(BLACKJACK_SCORE - score)` 비교 = *블랙잭 점수에 가장 가까운 자가 승리* 와전. 
+PR #139 (2단계) *isBust/isBlackJack 필터링 + 단순 score 비교* = 정공.
+
+→ **블랙잭 룰 자가 정정** = *학습 시간성*. **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 12+ PR ⭐⭐⭐.
+
+### 7. `enum VictoryStatus` 학생 자가 유지 + DealerProfit/PlayerProfit data class
+
+```kotlin
+data class DealerProfit(val money: Float)
+data class PlayerProfit(val name: String, val money: Float)
+```
+
+→ **수익 도메인 객체 분리** — `DealerProfit` + `PlayerProfit` data class. *Player.profit vs Dealer.profit 의 도메인 분리*.
+
+다만 *Float vs Double 타입* (reviewer Thread 9 권유 → 학생 자가 거절 + 대안 제시).
+
+### 8. 추가 칭찬 + 학생 자가 답변 풍부
+
+- 모든 12 스레드 학생 자가 답변 + commit SHA 첨부 (PR #117 결 강화).
+- 학생 자가 *"좋은데요~ 가시죠!"* 어휘 (Thread 5·12) — *reviewer 제안에 *학생 자가 적극 수용* 어휘*.
+
+## 못한 점 (설계 관점)
+
+### 1. `betAmount` Player 생성 시점 — 한 판 vs 여러 판 가정
+
+reviewer (Thread 2):
+
+> *"betAmount는 Player가 생성될 때 만드는게 맞을까요? 지금은 게임을 한판만 하지만 여러판을 한다고 가정하면 Player는 어떻게 변경되어야할까요?"*
+
+학생 자가 적용: *베팅금액을 생성자로 받지 않도록 변경*.
+
+학생 코드 (수정 후):
+```kotlin
+class Player(val name: String, playerCards: Cards) : Participant(playerCards) {
+    var betAmount: Float = ZERO
+        private set(value) {
+            require(value > ZERO) { PLAYER_AMOUNT_ERROR_MESSAGE }
+            field = value
+        }
+
+    fun betting(betAmount: Float) {
+        this.betAmount = betAmount
+    }
+}
+```
+
+→ **여러 판 가정 = betAmount 가 *판마다 변경***. *Player 인스턴스 = 여러 판 공유 + betAmount = 매 판 변경*. **`var betAmount` + `betting()` 메서드** 자가 적용.
+
+#### 1.1. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `Player(name, cards, betAmount)` (학생 초안) | *생성 시 invariant 강제* | *Player = 매 판 신규 인스턴스 X 가정* |
+| `var betAmount + betting()` (학생 자가 적용) | *Player 공유 + betAmount 변경 가능* | *var = 외부 변경 가능* |
+| `Player.startRound(betAmount): Round` | *Round 객체 = 판 별 인스턴스* | *Round 객체 추가 + 복잡도 ↑* |
+
+reviewer 의 *"여러 판 가정"* = *학생이 *미래 확장* 의식 권유*. **MCP 룰 `feature-evolution-driven-design` 후보** — *현재 요구사항 vs 미래 확장 의식*.
+
+다만 *현재 미션은 1 판만 * → *여러 판은 가정만*. *YAGNI 위반? vs 변경 비용 인식?* 트레이드오프.
+
+### 2. `var betAmount` + `private set` — Tell-Don't-Ask 부분 위반
+
+```kotlin
+var betAmount: Float = ZERO
+    private set(value) {
+        require(value > ZERO) { PLAYER_AMOUNT_ERROR_MESSAGE }
+        field = value
+    }
+```
+
+→ **`var betAmount` public get** = *외부에서 player.betAmount 접근 가능* + **`private set`** = *외부 직접 수정 X (betting() 만 가능)*.
+
+다만 **`var betAmount` public get + ProfitCalculator 가 외부 호출**:
+
+```kotlin
+private fun calculatePlayerProfit(player: Player): Float =
+    when {
+        player.isBlackJack && !dealer.isBlackJack -> player.betAmount * ONE_AND_HALF  // ← 외부 호출
+        player.isBust -> -player.betAmount
+        ...
+    }
+```
+
+→ **Player.betAmount 외부 호출 = Tell-Don't-Ask 위반**. PR #87·#129·#138 결.
+
+대안: **`Player.calculateProfit(other: Participant): Float`** — *Player 가 자가 계산*.
+
+### 3. `ProfitCalculator` 외부 객체 — Tell-Don't-Ask 위반 (PR #129·#138 결의 *반대 시점*)
+
+```kotlin
+class ProfitCalculator(private val dealer: Dealer, players: Players) {
+    val playerProfits: List<PlayerProfit> = ...
+    val dealerProfit: DealerProfit = DealerProfit(playerProfits.map { -it.money }.sum())
+
+    private fun calculatePlayerProfit(player: Player): Float = when { ... }
+}
+```
+
+→ **`ProfitCalculator` = 외부 장치 (PR #129 reviewer KwonDae *"게임의 승패를 결정해주는건 외부 장치가 해주는걸까요?"* 결)**.
+
+다만 **PR #117 reviewer (woowahan-dino) 의 결**:
+- PR #117: *비즈니스 로직은 Model* 위치 권유.
+- PR #139: *ProfitCalculator 자가 권유 X* (학생 자가 유지).
+
+→ **2 reviewer 의 *반대 시점*** = **MCP `oop_propose_alternatives` 핵심 가치 (개인 의견 차이) 합류**. PR #129 (KwonDae *외부 장치 X*) vs PR #139 (woowahan-dino *ProfitCalculator 유지 OK*).
+
+학생 PR 본문 자가 의문:
+
+> *"- ProfitCalculator 클래스의 역할을 더 분리하는게 좋을지 봐주세용."*
+
+→ **학생 자가 의문 + reviewer 답변 보류 (자가 분리 권유 X)** = *현재 안 OK*.
+
+**MCP 룰 `result-decider-external-object-vs-participant-method` 강화** — 누적 3+ PR (#129·#138·#139). *2 reviewer 반대 시점 = trade-off*.
+
+### 4. `dealerProfit` 두 형태 통일 — val + 리턴 타입
+
+reviewer (Thread 7):
+
+> *"두가지의 형태를 통일하면 좋을 것 같네요. 둘다 val로 만들고, 둘다 리턴타입이 비슷한 형태면 좋겠네요"*
+
+학생 자가 적용:
+
+```kotlin
+val playerProfits: List<PlayerProfit> = ...
+val dealerProfit: DealerProfit = DealerProfit(playerProfits.map { -it.money }.sum())
+```
+
+→ **두 멤버 형태 통일** (val + 도메인 타입). PR #117 *property val vs computed property* 결.
+
+### 5. Float vs Double 타입 — 학생 자가 거절 + 대안 제시
+
+reviewer (Thread 9):
+
+> *"이렇게 해도 테스트 코드는 통과하게 되네요. Float -> Double로는 바꿔줘야할게 있습니다."*
+
+학생 자가 답변 + 대안:
+
+> *"`val dealerProfit: DealerProfit = DealerProfit(playerProfits.map { -it.money }.sum())` 이렇게 하면 double 타입으로 안받아도 되는데 어떻게 생각하시나요 디노!"*
+
+→ **학생 자가 거절 + 대안 제시** = *학생 자가 학습 가시화 모범*. PR #117 (`val cardScore` 학생 자가 부분 거절) 결 강화. **양방향 reviewer/학생 토론 정공**.
+
+#### 5.1. *Float vs Double 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Float (학생 자가 적용) | *메모리 ↓ (4 byte)* | *정확도 ↓ (7 자리) + Kotlin 어휘 어색 (Java float)* |
+| Double (reviewer 권유) | *정확도 ↑ (15 자리) + Kotlin 기본 타입* | *메모리 ↑ (8 byte)* |
+| BigDecimal | *완벽한 정확도* | *비용 ↑ + 복잡도 ↑* |
+
+블랙잭 수익 = *최대 1.5배 정확 + 정수 베팅 금액* → *Float 으로 충분* (다만 *Kotlin 어휘 자연성* 으로 Double 권유).
+
+**MCP 룰 `float-vs-double-domain-precision` 후보**.
+
+### 6. `playerProfits` forEach 람다 인자 이름 — `playerResult` vs `playerProfit`
+
+reviewer (Thread 8):
+
+> *"playerProfits의 forEach인데 람다 인자는 playerResult네요. 이름을 맞추면 좋을 것 같아요"*
+
+→ **컬렉션 이름 vs 람다 인자 이름 일관성** — *playerProfits.forEach { playerProfit -> ... }* = *컬렉션 단수형 사용 정공*.
+
+**MCP 룰 `collection-name-vs-lambda-element-naming` 후보** — *컬렉션 복수형 + 람다 단수형 일관성*.
+
+### 7. Dealer/Player 의 `cardNames` 통일 — Participant 로 추출
+
+reviewer (Thread 11):
+
+> *"Dealer도 initialDealerCards 대신 Dealer.cardNames로 처리하면 좋을 것 같네요. Player는 cardName로 처리하고 있는데 Dealer는 외부에 있는 initialDealerCards를 사용하고 있어서 통일되지 않는 형태라고 생각합니다."*
+
+학생 *오해*:
+
+> *"음 dealer객체를 생성할 때 Cards타입의 initialDealerCards가 필요해서 cardName으로 처리하긴 힘들 것 같아용..🥲"*
+
+reviewer 의도 재명시:
+
+> *"제 의견이 제대로 전달되지 않은 것 같네요. Player가 가지고 있는 cardNames를 Participant로 올려보시고, showInitialGameState(), showTotalResult() 에서 전달하는 initialDealerCards를 dealer로 변경해보세요"*
+
+→ **양방향 reviewer/학생 토론 + 학생 오해 + reviewer 재명시**:
+
+#### 7.1. *학생 오해 = 의도 재읽기 모범*
+
+학생이 *"dealer 객체 생성 시점 cards 필요"* 로 오해 (Cards 타입 vs cardNames 출력 의도 혼동).
+
+reviewer 의 *cardNames 추출 + Participant 공통 메서드* 권유 = *Player.cardNames + Dealer.cardNames 공통 = 추출 정공*.
+
+학생 코드 최종 (수정):
+```kotlin
+abstract class Participant(...) {
+    val cardNames: List<CardName>
+        get() = handCards.cardNames
+    ...
+}
+```
+
+→ **Player + Dealer 공통 (cardNames) Participant 추상화 추출** = PR #87·#129 결의 *추상화 활용 점검* 어휘.
+
+**MCP 룰 `abstraction-as-shared-behavior-discovery` 강화** 누적 2+ PR (#129·#139).
+
+#### 7.2. *학생 오해 + reviewer 재명시 = 학습 시간성*
+
+PR #117 (parkjiminnnn) 결의 *학생 자가 부분 거절* 변형 — *오해 + 재명시*. **MCP 룰 `student-misunderstanding-reviewer-restatement` 후보**.
+
+### 8. 베팅금액 입력 시점 — Player 생성 후 일괄 vs forEach 시
+
+reviewer (Thread 12):
+
+> *"미리 받은 것을 player.betting에 넣는게 아니라 players.forEach할 때 마다 input을 받게 하면 어떨까요?"*
+
+학생 자가 적용: *플레이어마다 배팅금액을 입력 받게 변경*.
+
+→ **입력 시점 = 도메인 흐름 정합**:
+
+#### 8.1. *2 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 일괄 입력 후 betting 호출 (학생 초안) | *입력 단계 분리 + Player 객체 완성 후 betting* | *입력 단계 + betting 단계 분산* |
+| players.forEach 시 input (학생 자가 적용) | *도메인 흐름 자연 (Player 마다 베팅)* | *입력 단계와 게임 단계 혼합* |
+
+reviewer 권유 = *도메인 흐름 (한 명씩 베팅 후 게임) 정합*.
+
+### 9. `Dealer.drawCount` 함수 = 2 역할 — PR #117 결 재발
+
+```kotlin
+fun drawCount(drawCard: () -> Card): Int {
+    var drawCount = DEFAULT_DRAW_COUNT
+    drawCount += addDraws(drawCard)
+    return drawCount
+}
+
+private fun addDraws(drawCard: () -> Card): Int {
+    var count = DEFAULT_DRAW_COUNT
+    while (turn(drawCard())) {
+        count++
+    }
+    return count
+}
+```
+
+→ **`drawCount` = Query (count 반환) + Command (카드 뽑음)** = **CQS 위반 재발** (PR #117 1단계 결).
+
+reviewer 명시 X (2단계에서 다시 제기 X) — *학생이 자가 분리 안 됨* + *reviewer 가 1단계 권유 후 후속 안 함*.
+
+**MCP 룰 `command-query-separation` 강화** 누적 2+ PR (#117·#139). *학생 자가 1단계 학습 → 2단계 재발* = *학습 시간성 한계*.
+
+### 10. `currentScore` → `score` 이름 단순화 (장점 §3)
+
+§3 참조.
+
+### 11. `var betAmount` 가변 + setter 검증
+
+§2 참조.
+
+### 12. `Dealer.canHit() = handCards.score <= DEALER_HIT_LIMIT` — Ace Soft 미고려
+
+```kotlin
+override fun canHit(): Boolean = handCards.score <= DEALER_HIT_LIMIT
+```
+
+→ **Dealer canHit 단순 비교 (Soft Ace 미고려)**. PR #138 (Dealer.isDrawable Soft Ace 분기) 결 의 *반대 시점*.
+
+다만 *`handCards.score` 가 이미 Soft Ace 적용한 finalScore 반환*? — *ScoreCalculator.calculateTotalCardScore* 가 *Ace soft 처리 수학적 풀이*. 
+
+학생 코드 (`Participant.score = handCards.score`) → `HandCards.score = ScoreCalculator(cards).calculateTotalCardScore()`. → *Soft Ace 자가 처리 + Dealer.canHit 단순 비교*.
+
+**현재 안 정합** — *score 가 이미 Soft Ace 처리 후 값*. PR #117 결의 *수학적 풀이* 일관.
+
+### 13. `Player.canHit() = score <= BLACKJACK_SCORE` — 21 시 hit 가능 (PR #129 결과 동일)
+
+```kotlin
+override fun canHit(): Boolean = score <= BLACKJACK_SCORE
+```
+
+→ **Player 21 시 hit 가능** = PR #138 결과 동일. **블랙잭 룰 = 21 시 hit X 명시 X** = *호출자가 멈춤 책임*. 
+
+대안: `< BLACKJACK_SCORE` (21 미만만 hit).
+
+**MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 12+ PR.
+
+### 14. `Player.turn` `Dealer.turn` 반환 의미 역방향 (PR #117 결 재발)
+
+```kotlin
+// Player
+override fun turn(drawnCard: Card): Boolean {
+    if (canHit()) { addCard(drawnCard); return false }  // hit 함 → false
+    return true
+}
+
+// Dealer
+override fun turn(drawnCard: Card): Boolean {
+    if (canHit()) { addCard(drawnCard); return true }  // hit 함 → true
+    return false
+}
+```
+
+→ **PR #117 결의 *부모 추상 메서드 반환 의미 자식 별 역방향* 재발** (학생 자가 1단계 → 2단계 유지). 
+
+**MCP 룰 `method-return-semantic-asymmetry-between-subclasses` 강화** 누적 2+ PR (#117·#139).
+
+### 15. `var betAmount: Float = ZERO` 초기값 + `betting()` 호출 강제 X
+
+```kotlin
+var betAmount: Float = ZERO
+    private set(value) {
+        require(value > ZERO) { PLAYER_AMOUNT_ERROR_MESSAGE }
+        field = value
+    }
+```
+
+→ **초기값 ZERO + betting() 호출 강제 X** = *betting 호출 전 Player 사용 시 0원 베팅 상태*. *호출 순서 invariant 부재*.
+
+대안: 
+- `betAmount: Float?` (nullable) + *betting 호출 시 set*.
+- `Player.startRound(betAmount): RoundPlayer` (Round 객체).
+
+**MCP 룰 `lateinit-var-call-order-invariant` 강화** 누적 9+ PR (PR #28·#92·#48·#16·#22·#11·#13·#36·#139).
+
+### 16. `Participant.handCards` `get() = HandCards(cards)` — 매 호출 시 신규 인스턴스
+
+```kotlin
+abstract class Participant(private val cards: Cards) {
+    val handCards
+        get() = HandCards(cards)
+    ...
+}
+```
+
+→ **매 호출 시 `HandCards` 인스턴스 신규 생성** = *비용 ↑*. PR #117 (ScoreCalculator stateless 신규 인스턴스) 결.
+
+대안: 
+- `private val _handCards: HandCards = HandCards(cards)` (즉시 초기화).
+- *HandCards 가 stateless* 시 `object HandCards` (companion).
+
+**MCP 룰 `stateless-class-vs-companion-object` 강화** 누적 2+ PR (#117·#139).
+
+### 17. `isBlackJack` 즉시 초기화 vs `isBust` computed — Participant 일관성
+
+```kotlin
+val isBust: Boolean
+    get() = handCards.isBust  // computed property
+val isBlackJack: Boolean = handCards.isBlackJack  // 즉시 초기화
+```
+
+→ **2 형태 양립** = *PR #117 (val vs get()) 학생 자가 학습 활용*. 다만 *handCards 가 매 호출 시 신규 인스턴스* → *isBlackJack 즉시 초기화 = 첫 호출 시 한 번 = OK* + *isBust computed property = 매 호출 시 신규 HandCards* = *비용 ↑*.
+
+§16 참조.
+
+### 18. `ProfitCalculator(dealer, players)` 외부 객체 + 의존 양방향
+
+```kotlin
+class ProfitCalculator(private val dealer: Dealer, players: Players) {
+    val playerProfits: List<PlayerProfit> =
+        players.map { player -> PlayerProfit(player.name, calculatePlayerProfit(player)) }
+    ...
+}
+```
+
+→ **ProfitCalculator 가 Dealer + Players 외부 호출** = *PR #129 KwonDae 결의 *외부 장치 X***. 다만 *PR #139 woowahan-dino reviewer = 유지 OK*.
+
+**reviewer 별 의견 차이** = **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+
+§3 참조.
+
+### 19. PR 본문 자가 의문 — object vs class + object 사용 시점
+
+reviewer 답변 X (2단계에서 다시 제기 X 또는 PR 본문 답변 미제공).
+
+→ **학생 자가 의문이 답변 받지 못함** = *PR 본문 자가 의문 가시성 낮음*. PR 본문 자가 의문은 *라인 코멘트보다 약함*. **MCP 룰 `pr-body-question-visibility-low` 후보** — *PR 본문 vs 라인 코멘트 답변 가능성 차이*.
+
+PR #18 (boogi-woogi *companion object enum 매직 넘버 자가 의문*) 결의 *PR 본문 자가 의문 후속 답변* 와 *반대 시점* (답변 X).
+
+### 20. Dealer/Player canHit 분기 — 도메인 룰 차이 자가 구분
+
+```kotlin
+// Player
+override fun canHit(): Boolean = score <= BLACKJACK_SCORE  // ≤ 21
+
+// Dealer
+override fun canHit(): Boolean = handCards.score <= DEALER_HIT_LIMIT  // ≤ 16
+```
+
+→ **Player 21 / Dealer 16 자가 도메인 룰 분기 정공** + **abstract canHit 다형성** = PR #129·#138 결.
+
+### 21. `ScoreCalculator.initialTotalCardScore` 즉시 + `calculateTotalCardScore()` 함수 — 양립
+
+```kotlin
+class ScoreCalculator(private val cards: Cards) {
+    val initialTotalCardScore = cards.scores.sum()
+
+    fun calculateTotalCardScore(): Int { ... }
+}
+```
+
+→ **즉시 초기화 멤버 + 메서드 양립** — PR #117 결의 *val vs computed property* + *함수* 3 형태 자가 적용. **MCP 룰 `property-val-vs-computed-property` 강화** 누적 3+ PR.
+
+## 리뷰어 의견 요지
+
+- **PR 본문 자가 의문 답변 안 함 (object vs class)** — *라인 코멘트로 옮겨야 답변 받음*.
+- **`List<Player>` → `Players` 반환 타입 도메인화** — 일급 컬렉션 정공.
+- **`betAmount` Player 생성 시점 vs 여러 판 가정** — *현재 요구사항 vs 미래 확장*.
+- **Short-circuit evaluation 학습** — *Boolean 평가 순서 최적화*.
+- **`currentScore` → `score` 이름 단순화** — *부연설명 회피*.
+- **`isBust` 필드화** — *isBlackJack 처럼 일관성*.
+- **`isBackJack` 오타** — PR #87 (Aginst 오타) 결.
+- **두 형태 통일 (val + 리턴 타입)** — 일관성.
+- **`playerProfits.forEach { playerResult ... }` 람다 인자 이름 일치** — *컬렉션 복수형 + 람다 단수형*.
+- **Float → Double 학생 자가 거절 + 대안 제시** — *양방향 토론*.
+- **abs 비교 불필요 자가 정정** — *이전 단계 코드 잔재 정리*.
+- **Dealer/Player cardNames 통일 Participant 추출** — *학생 오해 + reviewer 재명시*.
+- **베팅금액 forEach 시 입력** — *도메인 흐름 정합*.
+
+## 대표 인용
+
+> [parkjiminnnn PR 본문]
+> *"머리가 생각보다 잘 안돌아가서 피드백을 먼저 받고 반영하여 리팩토링을 해볼까해서 pr을 먼저 올릴게요.. 비록 진흙탕 코드이지만 잘부탁드립니다..🥲"*
+
+→ **학생 자가 학습 한계 인정 + 피드백 → 리팩토링 사이클 의식**.
+
+> [woowahan-dino Thread 2]
+> *"betAmount는 Player가 생성될 때 만드는게 맞을까요? 지금은 게임을 한판만 하지만 여러판을 한다고 가정하면 Player는 어떻게 변경되어야할까요?"*
+
+→ **미래 확장 가정 의문** = *YAGNI vs 변경 비용 인식*.
+
+> [woowahan-dino Thread 3]
+> *"의 차이가 뭘까요? 어떤 차이가 있는지 알아보시겠어요? hint: Short-circuit evaluation"*
+
+→ **Kotlin 어휘 자가 학습 권유 + hint 제공**.
+
+> [parkjiminnnn Thread 4]
+> *"카드가 추가될때마다 점수가 바뀌기 때문에 현재의 점수를 의미하는 currentScore로 했던건데 생각해보니 그냥 score로 해도 될 것같네용."*
+
+→ **학생 자가 이름 의도 자가 정정** — *부연설명 의도 vs 단순 명명 트레이드오프*.
+
+> [parkjiminnnn Thread 9]
+> *"`val dealerProfit: DealerProfit = DealerProfit(playerProfits.map { -it.money }.sum())` 이렇게 하면 double 타입으로 안받아도 되는데 어떻게 생각하시나요 디노!"*
+
+→ **학생 자가 거절 + 대안 제시** — *양방향 토론 정공*.
+
+> [parkjiminnnn Thread 10]
+> *"step1때는 필요했었는데 지금 로직에는 위에서 블랙잭점수보다 참가자의 점수가 큰 경우가 when문에서 필터링 되서 필요없게 되었네용."*
+
+→ **학생 자가 *이전 단계 코드 잔재* 정리** — *2단계 자가 정정 + 블랙잭 룰 자가 학습*.
+
+> [woowahan-dino Thread 11]
+> *"제 의견이 제대로 전달되지 않은 것 같네요. Player가 가지고 있는 cardNames를 Participant로 올려보시고, showInitialGameState(), showTotalResult() 에서 전달하는 initialDealerCards를 dealer로 변경해보세요"*
+
+→ **학생 오해 + reviewer 재명시** = *양방향 토론 깊이*. PR #117·#129·#138 결 합류.
+
+## 얻은 교훈 (보편)
+
+1. **PR 본문 자가 인정 (진흙탕 코드) + 피드백 → 리팩토링 사이클 의식** — *학생 학습 한계 + 피드백 활용 전략*. **MCP `oh-my-oop` *학습 = 시간 두고 반복* 어휘 합류**.
+
+2. **`List<X>` → `X일급컬렉션` 반환 타입 도메인화** — *PR #21·#74·#108·#46·#117·#129·#138·#139 결*. **MCP 룰 `return-type-domain-object` 후보**.
+
+3. **미래 확장 가정 (한 판 vs 여러 판)** — *YAGNI vs 변경 비용 인식* 트레이드오프. **MCP 룰 `feature-evolution-driven-design` 후보**.
+
+4. **Short-circuit evaluation 평가 순서 최적화** — *비용 큰 평가는 뒤로*. **MCP 룰 `short-circuit-evaluation-order` 후보**.
+
+5. **이름 부연설명 회피 (current/total 같은 단어)** — *과거/미래 분기 없으면 단순 명명*. **MCP 룰 `name-redundant-qualifier` 후보**.
+
+6. **상태 필드화 일관성 (isBust + isBlackJack 둘 다 필드)** — *함수 호출 X + 필드 직접 접근*.
+
+7. **컬렉션 이름 vs 람다 인자 이름 일관성** — *컬렉션 복수형 + 람다 단수형*. **MCP 룰 `collection-name-vs-lambda-element-naming` 후보**.
+
+8. **이전 단계 코드 잔재 정리** — *abs 비교 = 1단계 잔재 vs 2단계 필터링 후 불필요*. **MCP 룰 `dead-logic-from-previous-stage` 후보**.
+
+9. **추상화 활용 = 공통 사항 → 추상 메서드 (Dealer/Player cardNames)** — *학생 오해 + reviewer 재명시*. **MCP 룰 `abstraction-as-shared-behavior-discovery` 강화** 누적 2+ PR.
+
+10. **학생 오해 + reviewer 재명시** — *양방향 토론 깊이*. **MCP 룰 `student-misunderstanding-reviewer-restatement` 후보**.
+
+11. **학생 자가 거절 + 대안 제시 (Float vs Double)** — *양방향 토론 정공*. PR #117 결 강화.
+
+12. **2 reviewer 의 반대 시점 (ProfitCalculator 외부 객체 OK vs 외부 장치 X)** — *KwonDae vs woowahan-dino*. **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+
+13. **CQS 위반 재발 (drawCount 1단계 → 2단계)** — *학습 시간성 한계*. **MCP 룰 `command-query-separation` 강화** 누적 2+ PR.
+
+14. **부모 추상 메서드 반환 의미 역방향 재발** — *학생 자가 1단계 → 2단계 유지*. **MCP 룰 `method-return-semantic-asymmetry-between-subclasses` 강화** 누적 2+ PR.
+
+15. **`var betAmount` + `betting()` 호출 강제 X** — *호출 순서 invariant 부재*. **MCP 룰 `lateinit-var-call-order-invariant` 강화** 누적 9+ PR.
+
+16. **PR 본문 자가 의문 답변 가능성 낮음** — *PR 본문 vs 라인 코멘트*. **MCP 룰 `pr-body-question-visibility-low` 후보**.
+
+17. **abs 자가 정정 = 블랙잭 룰 자가 학습** — *1단계 → 2단계 학습 시간성*. **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 12+ PR ⭐⭐⭐.
+
+18. **학생 자가 *좋은데요~ 가시죠!* 적극 수용 어휘** — *학생 학습 적극성 어휘*.
+
+19. **모든 12 스레드 학생 자가 답변 + commit SHA** — *학생 자가 학습 가시화 정점* (PR #117 결 유지).
+
+20. **stateless 클래스 매 호출 시 신규 인스턴스 (HandCards)** — PR #117 결 강화. **MCP 룰 `stateless-class-vs-companion-object` 강화** 누적 2+ PR.
+
+## 얻은 교훈 (도메인)
+
+1. **`Dealer.DEALER_HIT_LIMIT = 16` + `<=` 비교** — *블랙잭 표준 룰 정공*. PR #138 결 일치.
+
+2. **`Player.canHit() = score <= 21`** — *21 시 hit 가능 (사용자 선택)*. PR #129·#138 결.
+
+3. **`isBlackJack = handCards.size == INITIAL_CARDS_COUNT && score == BLACKJACK_SCORE`** — *초기 2장 + 21점 정공*. PR #138 결.
+
+4. **Ace soft 1↔11 수학적 풀이 (PR #117 결 유지)** — *while → 수학적 단일 식*. 
+
+5. **베팅금액 forEach 시 입력 = 도메인 흐름 정합** — *Player 마다 베팅 후 게임*.
+
+6. **`BLACKJACK_SCORE = 21` + `ONE_AND_HALF = 1.5f`** — *블랙잭 1.5배 정공*.
+
+7. **DealerProfit / PlayerProfit data class 분리** — *도메인 어휘 + 객체 분리*. PR #87·#138 결.
+
+## MCP 룰 후보 신규 + 강화 (PR #139)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `feature-evolution-driven-design` | 신규 | 1 (#139) — 현재 vs 미래 확장 |
+| `short-circuit-evaluation-order` | 신규 | 1 (#139) |
+| `name-redundant-qualifier` | 신규 | 2+ (#139·#117) — current/total 부연설명 |
+| `collection-name-vs-lambda-element-naming` | 신규 | 1 (#139) |
+| `dead-logic-from-previous-stage` | 신규 | 1 (#139) |
+| `abstraction-as-shared-behavior-discovery` | 강화 | 2+ (#129·#139) |
+| `student-misunderstanding-reviewer-restatement` | 신규 | 2+ (#139·#117) |
+| `return-type-domain-object` | 신규 | 8+ (#21·#74·#108·#46·#117·#129·#138·#139) |
+| `float-vs-double-domain-precision` | 신규 | 1 (#139) |
+| `result-decider-external-object-vs-participant-method` | 강화 | 3+ (#129·#138·#139) |
+| `command-query-separation` | 강화 | 2+ (#117·#139) |
+| `method-return-semantic-asymmetry-between-subclasses` | 강화 | 2+ (#117·#139) |
+| `lateinit-var-call-order-invariant` | 강화 | 9+ |
+| `pr-body-question-visibility-low` | 신규 | 1 (#139) |
+| `blackjack-rule-fidelity-comparison` | 강화 | 12+ ⭐⭐⭐ |
+| `stateless-class-vs-companion-object` | 강화 | 2+ (#117·#139) |
+| `property-val-vs-computed-property` | 강화 | 3+ (#117·#139·#138) |
+
+## 메타 어휘 (13 reviewer + MCP 핵심 가치 합류 정점 유지)
+
+- ***학생 자가 *진흙탕 코드* 인정 + 피드백 → 리팩토링 사이클*** — parkjiminnnn PR #139 — *"머리가 생각보다 잘 안돌아가서 피드백을 먼저 받고 반영하여 리팩토링을 해볼까해서 pr을 먼저 올릴게요"* — **학생 학습 적극성 + 자가 한계 인정** 어휘.
+- ***Kotlin 어휘 자가 학습 권유 + hint 제공*** — woowahan-dino PR #139 — *short-circuit evaluation hint, Float vs Double 변경 권유* — **MCP `oop_propose_alternatives` 핵심 가치 (학생 자가 학습 권유)**.
+- ***학생 자가 거절 + 대안 제시 (Float vs Double)*** — parkjiminnnn PR #139 — *"이렇게 하면 double 타입으로 안받아도 되는데 어떻게 생각하시나요 디노!"* — **양방향 토론 정공**. PR #117 결 강화.
+- ***학생 자가 *이전 단계 코드 잔재* 정리 (abs)*** — parkjiminnnn PR #139 — *블랙잭 룰 자가 학습 시간성*.
+- ***학생 오해 + reviewer 재명시*** — woowahan-dino PR #139 — *"제 의견이 제대로 전달되지 않은 것 같네요"* — *양방향 토론 깊이*. PR #117·#129·#138 결.
+- ***2 reviewer 의 반대 시점 (ProfitCalculator 외부 객체 OK vs 외부 장치 X)*** — KwonDae #129 vs woowahan-dino #139 — **MCP `oop_propose_alternatives` 핵심 가치 (개인 의견 차이)**.
+
+→ **13 reviewer + MCP 핵심 가치 어휘 합류 정점 유지**. **batch 20 신규 발견 = *2 reviewer 의 *반대 시점* 패턴*** (ProfitCalculator 외부 객체 OK vs 외부 장치 X) = **MCP `oop_propose_alternatives` 핵심 가치 실증**.
+
+## 비교 (PR #117 → #139 진화 — 사족 X, 안티패턴 명시만)
+
+- **1단계 #117 셀프 체크리스트 + 자가 의문 1개 (depth) → 2단계 #139 셀프 체크리스트 + 자가 의문 2개 (object vs class + object 사용 시점)** — *학생 자가 의문 풍부 유지*.
+- **1단계 25 thread → 2단계 12 thread** — *2단계 코드 줄어듦 (이전 학습 활용)*.
+- **1단계 currentScore → 2단계 score** — *이름 부연설명 회피*.
+- **1단계 `<` 비교 → 2단계 `<=` 비교 + abs 자가 정정** — *블랙잭 룰 자가 학습*.
+- **1단계 CQS 위반 (drawCount) → 2단계 CQS 위반 재발** — *학습 시간성 한계*.
+- **1단계 method 반환 의미 역방향 (turn) → 2단계 유지** — *학습 시간성 한계*.
+- **1단계 모든 스레드 commit SHA → 2단계 모든 스레드 commit SHA** — *학습 가시화 정점 유지*.
+
+→ *진화 비교 = 사족 아님 (안티패턴 코드 위치 명시)* + *학생 자가 학습 정점 유지 + 일부 학습 한계 (CQS / method 반환 역방향 재발)*.