oh-my-oop 0.2.0

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

@@ -0,0 +1,769 @@
+# PR #36 — [블랙잭 2단계] 우기 미션
+
+- **Reviewee:** [@boogi-woogi](https://github.com/boogi-woogi)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/36
+- **단계:** 2단계
+- **리뷰어:** [@woowahan-leah](https://github.com/woowahan-leah) (1단계 #18 동일 reviewer — *2 PR 누적 = 학생-reviewer 페어 안정*)
+- **라인 코멘트:** 24 스레드 — *Tell-Don't-Ask 2단계 재발 (PlayerGameResults `value` 외부 조작) + sealed class 학습 깊이 (학생 자가 답변 + reviewer 후속 confederate) + nullable enum 3안 트레이드오프 + backing property + data class 융합 대안 + decideAceValue 명명·실제 반환 불일치 + Domain/View 비용 메타포*
+- **양 단계 완성 reviewee** (1단계 #18 batch 18 분석 완료 + 2단계 #36 = batch 19 추가).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 인식 — 컨트롤러 도메인 로직 분리 의식
+
+PR 본문: *"2단계 미션을 진행하면서는 컨트롤러에 존재하는 도메인 로직들을 분리하는 것을 중점적으로 생각했습니다."*
+
+→ **학생 자가 *과제 인식*** + *1단계 #18 reviewer 권고 (Tell-Don't-Ask) → 2단계 자가 적용 의지*. PR #76·#82·#107·#46·#91·#11·#13·#80·#106·#14 결의 *PR 본문 자가 의문* 패턴 + *2단계 자가 적용 의지* 결합.
+
+### 2. `sealed class CardsState` Running(score) + object BlackJack/Bust — 학생 자가 학습 깊이
+
+```kotlin
+sealed class CardsState {
+    object BlackJack : CardsState()
+    data class Running(val score: Int) : CardsState()
+    object Bust : CardsState()
+    companion object {
+        private const val BLACKJACK_SCORE = 21
+        fun valueOf(score: Int, isInitialDraw: Boolean = false): CardsState = when {
+            score > BLACKJACK_SCORE -> Bust
+            score == BLACKJACK_SCORE && isInitialDraw -> BlackJack
+            else -> Running(score)
+        }
+    }
+}
+```
+
+학생 자가 답변 (PR #36, line 코멘트):
+
+> *"sealed 클래스를 사용해야하는 근거에 대해서 생각해보았습니다. enum class는 해당 class에 속하는 instance가 모두 같은 프로퍼티를 갖고 같은 형식으로 이루어져야 하기 때문에 Running 상태일때만 필요한 score를 처리하기가 어렵다고 생각했습니다. sealed 클래스를 사용하면서 굳이 다른 정보가 필요하지 않은 BlackJack과 Bust는 object를 선언하였고 Running과 같이 같은 Running 상태라도 score가 다를 수 있기 때문에 data class로 선언하였습니다. 그리고 이 score 값을 CardsState를 받는 쪽에서 이용할 수 있게 만들었습니다. sealed 클래스 사용 경험이 거의 없어서 이러한 상황에서의 사용이 적절했는지 잘 모르겠습니다! (미션 끝나고 sealed 클래스에 대해서 다시 꼭 정리하겠습니다)"*
+
+reviewer (woowahan-leah) 후속 confederate:
+
+> *"sealed class에 대해 잘 고민해보고 적절한 사용 시점을 잘 정리해주셨네요 👍 이외에도 함수나 프로퍼티를 가질 수 있다는 것이 sealed class의 강력한 속성이라고 생각해요. 추가로 CardsState가 직접 일할 수 있게 다음과 같이 확장도 가능해보입니다.*
+>
+> ```kotlin
+> sealed class CardsState {
+>     ...
+>     companion object {
+>          fun 내가 이제 무슨 state인지 판단해줘(score: Int) {
+>               if (score > BLACKJACK_SCORE) return Bust()
+>          }
+>     }
+> }
+> ```
+>
+> *이래야 진정으로 '직접 본인의 상태를 판단하는 객체'가 될 수 있지 않을까요? 고민해보고 이번 단계에 적용해보면 어떨까요? 어려움이 있다면 저와 페어 프로그래밍해봐도 좋습니다!"*
+
+→ **양방향 메타 학습**:
+- 학생: *sealed 자가 추론 (enum vs sealed 멤버 데이터 차이)* → object 무 데이터 / data class 데이터 → reviewer 일치 확인.
+- reviewer 후속: *자식들에게도 책임 부여 = 상태 패턴* (현재 valueOf companion object 만 일하고 자식은 데이터 컨테이너).
+- 페어 프로그래밍 권유 = *reviewer가 학습 가시화*.
+
+PR #98 (chaehyuns 2단계 *상태 패턴 자가 의문*) / PR #93 (junjange 2단계 *State.compareTo 다형성*) / PR #136 (whk06061 *State 자식 책임 부여*) 결의 *상태 패턴 도입 시점*.
+
+### 3. `enum class GameResult` + `BLACKJACK_WIN(1.5)` 멤버 — 블랙잭 룰 정확성
+
+```kotlin
+enum class GameResult(val profitRate: Double) {
+    BLACKJACK_WIN(1.5),
+    WIN(1.0),
+    LOSE(-1.0),
+    DRAW(0.0);
+
+    operator fun not(): GameResult = when (this) {
+        BLACKJACK_WIN -> LOSE
+        WIN -> LOSE
+        LOSE -> WIN
+        DRAW -> DRAW
+    }
+}
+```
+
+→ **블랙잭 1.5배 정확성** — `BlackjackWin` 별도 결과 멤버 (vs *Win + isBlackjack 분기*). PR #93·#136·#152·#133·#88·#147 결 *블랙잭 1.5배 분기*.
+
+**`operator fun not()` 활용** = *결과 반전 도메인 의미* — `!GameResult.WIN = LOSE`, `!ProfitMoney = -ProfitMoney`. **Kotlin 어휘 깊은 자가 활용** — *딜러 결과 = !플레이어 합계* (`return !playersTotalProfitMoney`). PR #137 (HamBeomJoon *operator overloading*) / PR #133 (Money operator plus) 결.
+
+reviewer 칭찬: *"profitRate를 GameResult 내부에 캡슐화 👍"* + *"PlayerGameResult 객체가 일하도록 👍"* + *"Case를 나누어 엔티티를 작게 유지한 점은 좋았습니다 👍"*.
+
+### 4. `@JvmInline value class` 3종 — PlayerName/BattingMoney/ProfitMoney
+
+```kotlin
+@JvmInline value class PlayerName(val value: String) {
+    init { require(value.isNotEmpty()) { NAME_LENGTH_ERROR } }
+}
+
+@JvmInline value class BattingMoney(val value: Int) {
+    init { require(value > 0) { BATTING_MONEY_EXCEPTION } }
+}
+
+@JvmInline value class ProfitMoney(val value: Int) {
+    operator fun not(): ProfitMoney = ProfitMoney(-value)
+}
+```
+
+→ **value class 3종 자가 적용** + *각각 invariant 명시* (이름 길이 ≥1, 베팅 ≥1, 수익 부호 반전). reviewer (1단계 외부 글) *"오프라인에서 질문해주신 것처럼 이러한 유효성 검사 로직 캡슐화도 원시값 래핑의 중요한 목적 중 하나입니다!"* — *오프라인 페어 학습* 이어진 자가 적용. PR #82·#76·#107·#106 결.
+
+### 5. `BlackJackCase` / `BustCase` / `RunningCase` — 케이스 분기 작은 enum
+
+```kotlin
+enum class BlackJackCase(val gameResult: GameResult) {
+    WIN(GameResult.BLACKJACK_WIN),
+    DRAW(GameResult.DRAW);
+    companion object {
+        fun valueOf(dealerCardsState: CardsState): BlackJackCase = when (dealerCardsState) {
+            is CardsState.BlackJack -> DRAW
+            else -> WIN
+        }
+    }
+}
+```
+
+→ **작은 enum 3개로 (`GameResult.valueOf` 책임 분할)** *플레이어 상태별 분기*. PR #99 (s6m1n 2단계 *WIN/LOSE × 블랙잭/일반 곱집합*) 결의 *반대 시점* — *상태별 enum 분리 = 곱집합 평탄화*.
+
+reviewer 칭찬: *"Case를 나누어 엔티티를 작게 유지한 점은 좋았습니다 👍"* + *"조건 활용하여 케이스 판별 👍"* (BustCase).
+
+### 6. 추가 칭찬 (단순)
+
+- **`CardNumber` 캡슐화 👍** — *value class 변환 아니지만 enum + companion 함수*.
+- **외부에서 state를 수정할 수 없도록 접근 제어자 설정 👍** (`Cards._cards: MutableList` + `cards: List` getter).
+- **Bust 로 잘 바꿔주셨습니다 😆** (1단계 → 2단계 명명 개선).
+- **숫자가 아닌 입력 불허 창의적 구현 👍** (`requestAdditionalDraw` `requestPlayersName` 등 입력 변환).
+- **PlayerGameResult 객체가 일하도록 👍** (`PlayerGameResult.of(player, otherCardsState)` 정적 팩토리).
+
+## 못한 점 (설계 관점)
+
+### 1. `BlackJackReferee` 의 `playerProfitResult` 값 외부 조작 — Tell-Don't-Ask 2단계 재발
+
+reviewer:
+
+> *"playerProfitResult값을 외부에서 꺼내서 조작하기보다 직접 메세지를 던져 요청하면 어떨까요? 다른 곳에서도 이렇게 메세지를 던져 구현해야 할 필요가 있는 곳이 없는지 점검해보세요! 상황에 따라 일급 컬렉션 사용이 필요할 수 있습니다. 참고: https://jojoldu.tistory.com/412"*
+
+→ **Tell-Don't-Ask 2단계 재발** — *1단계 #18 reviewer 권고 (DrawState.POSSIBLE 외부 판단 X)* → *2단계 자가 적용 의지에도 다른 자리 (BlackJackReferee.playerProfitResult) 에 재발*.
+
+**3 가지 학습**:
+
+#### 1.1. *일급 컬렉션 자가 적용*
+
+reviewer *"상황에 따라 일급 컬렉션 사용이 필요할 수 있습니다"* — *학생이 일급 컬렉션 어휘 자가 학습 시점*.
+
+→ *현재 `PlayerGameResults(private val _playerGameResults)` 는 일급 컬렉션* (잘 적용됨) + *총 수익 메서드 `getPlayersTotalProfit()` 도 일급 컬렉션* (잘 적용됨). 다만 *Referee 가 외부 꺼내서 조작* = *일급 컬렉션 의미 누수*.
+
+#### 1.2. *외부 글 = jojoldu 일급 컬렉션*
+
+reviewer 외부 자료 *jojoldu.tistory.com/412* — **외부 자료 활용 메타 어휘**. PR #23·#26·#108·#136·#151·#146·#148·#93·#133 결.
+
+#### 1.3. *BlackJackReferee 의 책임 = 메시지 던지기*
+
+현재 `Dealer.judgeDealerGameResults` 가 `!playersTotalProfitMoney` 로 메시지 처리. 다만 *Referee 의 다른 메서드*는 외부 조작 → *Tell-Don't-Ask 부분 적용*.
+
+**MCP 룰 `tell-dont-ask-partial-coverage` 후보** — *일부 자리만 Tell-Don't-Ask 적용 = 인지 부담 ↑*.
+
+### 2. Domain/View 비용 메타포 — *서버/클라이언트* 비유
+
+reviewer:
+
+> *"Domain을 서버, View를 클라이언트라고 가정해보고 View의 호출 최소화하여 비용을 줄여보면 어떨까요?"*
+
+→ **메타포 어휘 (서버/클라이언트)** = *Domain ↔ View 호출 비용 메타포*. 현재 `BlackJackGameController` 가 *Domain → View → Domain → View* 반복 (drawAdditionalCardsForPlayers 함수 인자 람다로 *내부에서 View 호출*).
+
+**3 가지 학습**:
+
+#### 2.1. *View 호출 비용 메타포*
+
+*Domain (서버) ↔ View (클라이언트) 라운드트립 = 네트워크 비용*. 라운드트립 횟수 ↓ = *비용 ↓*.
+
+#### 2.2. *람다 콜백 vs 일괄 응답 트레이드오프*
+
+현재 `BlackJackGame.drawAdditionalCardsForPlayers(isPlayerWantedAdditionalCards, checkCurrentCards)` = *콜백 람다 2개*. → *View 함수 매번 호출* (`OutputView::printPlayerCurrentCards`).
+
+대안: **`BlackJackGame.drawAdditionalCardsForPlayers(isPlayerWantedAdditionalCards): List<PlayerDrawResult>`** = *일괄 응답*. 두 대안 트레이드오프:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 콜백 람다 | 실시간 진행 표시 (블랙잭 한 장씩 보임) | View 라운드트립 ↑ |
+| 일괄 응답 | View 라운드트립 ↓ | 진행 표시 불가 (한 번에 다 보임) |
+
+→ *블랙잭 도메인은 한 장씩 보이는 것이 자연* (UX) → *콜백 람다가 적절* (다만 reviewer 의 *비용 메타포*는 *진행 표시 필요 없는 케이스* 에서 유효).
+
+#### 2.3. *PR #137 (HamBeomJoon) `println` 도메인 X (간접 lambda 도 결합)* 결
+
+PR #137 결: *콜백 람다 = View 결합도 ↓ 처럼 보이지만, 사실상 *View 함수 직접 호출과 동치**. 
+
+**MCP 룰 `callback-lambda-view-cost` 후보** — *콜백 람다 = View 호출 비용*.
+
+### 3. `GameResultCase` 의 `condition` 익명 함수 = enum 외부 분기
+
+학생 코드 (위 reviewer 코멘트에서 참조):
+
+```kotlin
+enum class GameResultCase(val condition: (playerScore: Int, dealerScore: Int) -> Boolean) {
+    WIN({ ... }), LOSE({ ... }), DRAW({ ... });
+    // ...
+}
+```
+
+reviewer:
+
+> *"enum class의 condition 익명 함수로 result를 판단하는 이 방법이 적절할까요? 매번 외부에서 GameResultCase의 values 전체를 호출해서 어떤 케이스인지 판단해야 할 텐데요."*
+
+reviewer 후속:
+
+> *"Case를 나누어 엔티티를 작게 유지한 점은 좋았습니다 👍 다만 이 코멘트의 의도는 `condition` 함수를 꼭 enum 객체가 들고 있어야 할까?에 초점이 맞춰져있습니다. condition은 어떤 enum을 반환할지 처음에 판단할 때에만 필요하고 실제 WIN, DRAW 값을 만질 때에는 사용되지 않는 값입니다. 이러한 조건이 사용되지 않는다면 빌더 함수에 캡슐화해도 되지 않을까 싶습니다 🤔 이를테면 다음처럼 구현해볼 수 있겠네요!*
+>
+> ```kotlin
+> fun valueOf(dealerCardsState: CardsState): BlackJackCase? {
+>     return if (dealerCardsState != CardsState.BlackJack) {
+>         WIN
+>     } else if (dealerCardsState == CardsState.BlackJack) {
+>         DRAW
+>     } else {
+>         null
+>     }
+> }
+> ```
+>
+> *저는 참고로 nullable한 enum보다 not nullable한 enum을 선호하긴 합니다 🤔*"
+
+→ **3 가지 학습**:
+
+#### 3.1. *enum 외부 분기 X — condition 익명 함수 의도 누수*
+
+reviewer 핵심: *condition = enum 선택 시점만 필요* → *enum 외부 (companion object valueOf) 가 적절*. **enum 내부 condition lambda 보관 = *데이터 메모리 낭비 + 의도 누수***.
+
+PR #98·#43·#107·#137·#148·#76·#86·#73 결의 *enum 외부 분기 X*.
+
+#### 3.2. *nullable enum vs not-nullable enum 3안 트레이드오프*
+
+reviewer 3 가지 안:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| nullable enum (`BlackJackCase?`) | *값이 없음 명시* | *call site `?.` 처리 + 추측 어려움* |
+| not-nullable enum (예: `WIN` 기본) | *call site 간결* | *기본값 의도 약함* |
+| NONE enum 추가 (`NONE`) | *명시적 부재 + 컴파일러 보장* | *enum 멤버 ↑ 폭증* |
+
+reviewer 선호: *not-nullable enum* (개인 의견). **MCP `oop_propose_alternatives` 핵심 가치 = N 안 + 트레이드오프 + 개인 의견 분리** 어휘 합류.
+
+PR #95·#23·#26 결 (*"옳고 그름 X, 장단점만"*) 동일.
+
+#### 3.3. *현재 BlackJackCase 는 not-nullable, GameResultCase 는 nullable*
+
+GameResultCase 의 *condition 익명함수* 는 *조건 false 면 매핑 없음* → nullable.
+
+reviewer *nullable enum 선호 X* + *NONE enum 멤버* → *학생 자가 선택* 권유.
+
+**MCP 룰 `enum-nullability-axis` 후보** — *enum nullable 여부 트레이드오프 3안*.
+
+### 4. `decideAceValue` / `decideAdditionalAceScore` — 명명과 실제 반환 불일치
+
+```kotlin
+companion object {
+    private const val ADDITION_SCORE_FOR_ACE = 10
+    private const val STANDARD_SCORE = 11
+    private const val ZERO = 0
+
+    fun decideAdditionalAceScore(score: Int): Int {
+        if (score <= STANDARD_SCORE) return ADDITION_SCORE_FOR_ACE
+        return ZERO
+    }
+}
+```
+
+reviewer:
+
+> *"A를 판단하는 여러 경우의 수를 고민해봤군요 👍 단, decideAceValue -> 함수의 네이밍은 Ace 값을 정해주는 함수, 즉 1 혹은 11을 리턴할 것 처럼 생겼는데 실제로는 추가로 더해야 하는 값을 리턴하고 있어요. 명시적인 네이밍을 활용하는 것도 좋아보입니다."*
+
+→ **이름 vs 실제 반환 불일치** — `decideAceValue` 또는 `decideAdditionalAceScore` 둘 다 어색:
+
+- `decideAceValue` → *Ace 값 (1 or 11) 반환 예상* → 실제는 *추가 더할 값 (0 or 10)*.
+- `decideAdditionalAceScore` → *추가 점수 반환 명시*. 다만 *AdditionalAceScore* = *Ace 점수 추가분* vs *Ace 외 추가 점수* 양가.
+
+**대안 명명**:
+- `getAceBonusIfApplicable(currentSum: Int): Int` — *현재 합계 기준 보너스 점수*.
+- `getExtraScoreForSoftAce(currentSum: Int): Int` — *Soft Ace = 11 vs Hard Ace = 1 도메인 어휘 + 추가분*.
+- `getAceUpscoreBonus(currentSum: Int): Int` — *Ace 점수 업그레이드 보너스*.
+
+**MCP 룰 `function-name-vs-return-semantic-mismatch` 후보** — *이름과 실제 반환값 의미 불일치*.
+
+PR #99·#147·#95·#76 결의 *vague rename* (Return → GameResult, etc.).
+
+### 5. `Ace` 11 기본 + 단일 +10 룰 자가 적용 — Ace 안티패턴 ↓
+
+```kotlin
+fun getMinimumCardsScore(): Int = cards.sumOf { card -> card.number.value }
+
+fun getTotalCardsScore(): Int {
+    val minimumScore = getMinimumCardsScore()
+    if (cards.any { card -> card.number == CardNumber.A }) {
+        return minimumScore + CardNumber.decideAdditionalAceScore(minimumScore)
+    }
+    return minimumScore
+}
+```
+
+→ **Ace 1 기본 + 단일 +10 룰** (Ace 1 sum + Ace 11 변환 가능 시 +10). PR #20·#64·#110·#28·#125·#147 의 *while + 차감 보정 안티패턴 반대 시점*.
+
+**Ace 룰 정확성** ⭐⭐:
+
+- *Ace 1 기본 + 11 변환 보너스*: *재계산 1회* (현재 안).
+- *Ace 11 기본 + while 차감 보정*: *재계산 N회 (Ace 개수 만큼)*.
+
+다만 *current 안 한계*:
+- **여러 Ace 가 모두 11 변환 시점 처리 X** — *Ace 2장 = 11+11 = 22 > 21 → 1+11 = 12, 1+1 = 2*. 현재 코드는 *Ace 존재 시 1회 +10* → *Ace 1장 변환은 OK, Ace 2장 모두 변환은 처리 X*.
+- → *현재 안은 Ace 1장 한정 정확* + *Ace 2장 이상은 잘못된 합산*.
+
+**MCP 룰 `ace-bonus-single-vs-multi` 후보** — *Ace +10 단일 룰 vs Multi-Ace 트레이드오프*.
+
+PR #82 (Hevton 1단계 *Ace +10 단일*) 결 + PR #11 (ki960213 *Ace 1+11 변환 모두 처리*) 결.
+
+### 6. `Card.draw()` companion object + `ALL_CARDS: MutableSet` — Singleton Deck 변형
+
+```kotlin
+class Card(val number: CardNumber, val shape: Shape) {
+    companion object {
+        private val ALL_CARDS: MutableSet<Card> = CardNumber.values()
+            .flatMap { cardNumber ->
+                Shape.values().map { shape -> Card(cardNumber, shape) }
+            }.toMutableSet()
+
+        fun draw(): Card {
+            val card = ALL_CARDS.random()
+            ALL_CARDS.remove(card)
+            return card
+        }
+    }
+}
+```
+
+→ **Singleton Deck (companion object MutableSet) 안티패턴** — 2판 이상 불가 / 테스트 격리 X / *static mutable state*. PR #20·#28·#125·#65·#92·#108·#137·#106·#48·#9·#22·#13·#11·#39·#16·#46 누적 결.
+
+**3 가지 학습**:
+
+#### 6.1. *Set vs List 자료구조 트레이드오프*
+
+PR #23·#26 결의 *Set vs List 다중 카드덱 (여러 벌)* 트레이드오프 → *현재 안은 1벌 한정*. *6벌 카지노 메타포 (PR #58 결)* 시 자료구조 변경 필요.
+
+#### 6.2. *Singleton 회피 = Cards constructor default*
+
+`Cards(cards: List<Card> = listOf(Card.draw(), Card.draw()))` → *Cards 생성 시 Card.draw 2회 자동 호출* + *static state 변경* = *Cards 생성 자체가 부작용*.
+
+대안: **`Deck` 객체 + `dealer.deck.draw()` 메시지**. PR #46 (rhthrhrl0 2단계 *Deck 도입*) / PR #91 (murjune 2단계 *Deck 자료구조*) 결.
+
+#### 6.3. *MutableSet 사용 vs 재귀 자료구조*
+
+PR #23·#26 결 *Set 자료구조 = 카드 중복 자연 방지*. 다만 *MutableSet 변경 = 함수형 사고 X*. **immutable Set + slice 함수** 대안.
+
+**MCP 룰 `singleton-deck-via-companion` 후보** — *companion object MutableSet/MutableList = Singleton Deck 변형*. 누적 17+ PR ⭐⭐⭐.
+
+### 7. `lateinit var blackJackPlayers` + `initPlayers` — 호출 순서 invariant 부재
+
+```kotlin
+class BlackJackGame(val dealer: Dealer = Dealer()) {
+    lateinit var blackJackPlayers: BlackJackPlayers
+        private set
+
+    fun initPlayers(names: List<String>, getBattingMoney: (String) -> Int) {
+        val players = names.map { name -> Player(name, getBattingMoney(name)) }
+        blackJackPlayers = BlackJackPlayers(players)
+    }
+}
+```
+
+→ **`lateinit var` + setter** (1단계 #18 의 *lateinit var callback* 결 재발). *initPlayers 호출 전 blackJackPlayers 접근 = UninitializedPropertyAccessException*. PR #28·#92·#48·#16·#22·#11·#13 누적 결.
+
+**MCP 룰 `lateinit-var-call-order-invariant` 후보** — *호출 순서 invariant 부재*. 누적 8+ PR.
+
+**대안**:
+- **Builder Pattern** — `BlackJackGame.Builder().withPlayers(names).build()` → *호출 시점 강제*.
+- **Generic 분리** — `BlackJackGameSetup` (players 없음) + `BlackJackGame(setup, players)` → *컴파일 시점 강제*.
+- **constructor + 필수 인자** — `BlackJackGame(players: BlackJackPlayers, dealer: Dealer)` → *생성 자체가 invariant*.
+
+reviewer 는 이 토픽 명시 X — 다만 *Tell-Don't-Ask 후속 코멘트* 에서 *외부 조작 의도* 가 *lateinit + setter 변형*임을 시사.
+
+### 8. `BlackJackPlayers.drawAdditionalCardsForPlayers` 함수 인자 = 람다 2개 — 콜백 지옥
+
+```kotlin
+fun drawAdditionalCardsForPlayers(
+    isPlayerWantedAdditionalCards: (player: Player) -> Boolean,
+    checkCurrentCards: (player: Player) -> Unit = { },
+) {
+    players.forEach { player ->
+        player.drawCardsRepeatedly(
+            isPlayerWantedAdditionalCards = { isPlayerWantedAdditionalCards(player) },
+            checkCurrentCards = { checkCurrentCards(player) }
+        )
+    }
+}
+```
+
+→ **콜백 람다 2개 = call site 인지 부담 ↑** + *내부에서 람다 재포장 (`{ isPlayerWantedAdditionalCards(player) }`)*. 
+
+대안: **Listener interface** (PR #148 (etama123 2단계 *Listener vs 고차함수*) 결):
+
+```kotlin
+interface PlayerActionListener {
+    fun isWantedAdditionalCards(player: Player): Boolean
+    fun onCardsChanged(player: Player)
+}
+```
+
+**3 가지 트레이드오프**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 람다 2개 (현재) | *호출자가 함수 참조로 간결 (`InputView::requestAdditionalDraw`)* | *람다 ↑ = 인지 부담 + 람다 시그니처 분산* |
+| Listener interface | *책임 그룹화 + 구현 명확* | *Adapter 클래스 필요 + 보일러플레이트* |
+| Sealed result + suspend | *진행 결과 + 다음 액션 일급화* | *복잡도 ↑ + Kotlin coroutines 의존* |
+
+reviewer 명시 X — 다만 *Tell-Don't-Ask + Domain/View 비용 메타포* 와 관련 자가 학습 영역.
+
+PR #148·#137·#132·#90·#147·#136·#152·#88·#131·#93·#133·#85 결.
+
+### 9. `PlayerGameResults` data class + 방어적 복사 양가성 — 학생 자가 의문
+
+학생:
+
+> *"test를 하기 위해서 아래와같이 equals와 hashCode를 override 했습니다. data 클래스를 사용하고 싶었지만 인자로 들어오는 List<PlayerGameResult>에 대한 방어적 복사를 수행해야된다고 생각해서 이 방법을 사용했는데 적절한 사용인지 잘 모르겠습니다!"*
+
+reviewer:
+
+> *"현재는 두 프로퍼티 모두 List<PlayerGameResult> 타입이기에 backing property로 선언했을 때의 큰 이점이 없어보입니다 🤔 오히려 다음과 같이 작성하면 backing property의 이점을 살리며 data 클래스로도 변환할 수 있을 것 같네요!*
+>
+> ```kotlin
+> data class PlayerGameResults(private val _playerGameResults: List<PlayerGameResult>) {
+>     val playerGameResults: List<PlayerGameResult>
+>         get() = _playerGameResults.toList()
+>     ...
+> }
+> ```"
+
+→ **2 가지 학습**:
+
+#### 9.1. *방어적 복사 vs data class 양가성*
+
+학생 자가 사고: *data class 사용 시 equals 자동 생성 → 방어적 복사 어려움 → 그래서 equals/hashCode override*.
+
+reviewer 자가 답변: *data class + private val 백킹 + getter toList() = 방어적 복사 자동 + equals 자동*. **양립 가능**.
+
+PR #137·#148 결의 *방어적 복사 강박 자가 학습 (불변 객체 deepCopy 비용)* 결.
+
+#### 9.2. *backing property = 두 프로퍼티 같은 타입 시 이점 ↓*
+
+reviewer *"두 프로퍼티 모두 List<PlayerGameResult> 타입이기에 backing property로 선언했을 때의 큰 이점이 없어보입니다"* → **backing property 사용 시점 트레이드오프**:
+
+| 케이스 | backing property 이점 |
+|---|---|
+| 내부 MutableList + 외부 List | *불변 노출* + *방어적 복사* |
+| 내부 List + 외부 List (같은 타입) | *방어적 복사만* (불변 노출은 그대로) |
+| Computed property + caching | *재계산 회피* |
+
+→ *현재 안*은 *방어적 복사만* 이점 → reviewer 의 대안 (*data class + private val + getter toList*) 가 *더 간결*.
+
+#### 9.3. *PR #46 (rhthrhrl0 2단계 backing property) 결*
+
+PR #46 (rhthrhrl0 2단계) 도 *backing property + 방어적 복사* 자가 학습.
+
+**MCP 룰 `backing-property-applicability` 후보** — *backing property 사용 시점 트레이드오프*.
+
+### 10. `enum class GameResultCase` `condition` 익명함수 — §3 참조 (Case 분리 + condition 빌더 함수)
+
+PR #36 의 핵심 학습 시점. reviewer *enum + condition lambda 분리 = builder 함수 (companion object valueOf)*.
+
+학생 자가 적용 결과 → *BlackJackCase / BustCase / RunningCase 3개 enum 분리 (위 §잘한점 5)*. **학습 후속 시점 완성**.
+
+### 11. `List<Pair<String, Int>>` 타입 vs 도메인 명명
+
+```kotlin
+fun initPlayers(names: List<String>, getBattingMoney: (String) -> Int) { ... }
+```
+
+reviewer (관련 코멘트, `BlackJackGame.kt`):
+
+> *"`List<Pair<String, Int>>` -> 타입만 보고도 어떤 데이터인지 판단할 수 있을까요? 사용하는 곳에서는 `.map { (playerName, battingMoney) ->`로 깔끔하게 묶어 처리하고 있지만 뷰가 도메인을 너무 잘 알고 있다는 생각도 듭니다. 어떻게 해결해볼 수 있을까요?"*
+
+→ **Tuple 타입 누수 (Pair<String, Int>) = 도메인 의미 부족**:
+
+#### 11.1. *뷰가 도메인을 잘 알고 있다*
+
+*View → Domain 호출 시 (name, money) 묶음 형태* = *Domain 의 PlayerInitInfo 객체 필요* 시사.
+
+#### 11.2. *대안 3 가지*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `Pair<String, Int>` (현재) | *간결 + Kotlin destructuring 활용* | *타입만으로 의미 모름 + View ↔ Domain 결합* |
+| `data class PlayerInitInfo(name: String, money: Int)` | *도메인 어휘 + View → Domain 명시 인터페이스* | *DTO 추가 + 클래스 ↑* |
+| `getBattingMoney: (String) -> Int` 람다 (현재 안의 일부) | *Pair 자료구조 회피* | *View 의존성 람다로 전이* |
+
+#### 11.3. *PR #137·#148·#90·#136 결*
+
+PR #137 (HamBeomJoon *Money 가변 + operator plus Unit 반환*) / PR #148 (etama123 *Listener vs 고차함수 콜백*) / PR #90 (kmkim2689 *view-as-raw-input-converter*) / PR #136 (whk06061 *State 자식 책임 부여*) 결의 *View ↔ Domain 결합 어휘*.
+
+**MCP 룰 `tuple-leak-vs-domain-dto` 후보** — *Pair/Triple 타입 누수 vs 도메인 DTO*.
+
+### 12. `BlackJackReferee` 함수 호출 순서 = 읽기 쉽도록 배치
+
+reviewer:
+
+> *"함수의 호출 순서를 정할 때에는 읽기 쉽도록 호출하는 곳을 먼저, 이어서 호출되는 순서대로 배치하는 것이 좋습니다.*
+>
+> ```kotlin
+> fun main() {
+>     A()
+>     B()
+> }
+> fun A() {}
+> fun B() {}
+> ```"
+
+→ **함수 정의 순서 = *호출 순서 따라 위에서 아래로***. *Stepdown 원칙* (Clean Code) 어휘. PR #93 (junjange 2단계 *Clean Code 인용*) 결.
+
+**MCP 룰 `function-order-stepdown` 후보** — *호출자 먼저, 호출 함수 뒤*. 코드 가독성 룰.
+
+다만 *Kotlin top-level 함수* 는 *순서 무관* (전방 참조 가능) → *읽기 편의 한정 룰*.
+
+### 13. `InputView::requestAdditionalDraw` `InputView::requestPlayersName` `InputView::requestBattingMoney` — 입력 함수 폭증
+
+```kotlin
+private fun initPlayers() {
+    val names = InputView.requestPlayersName()
+    blackJackGame.initPlayers(names, InputView::requestBattingMoney)
+    ...
+}
+```
+
+reviewer:
+
+> *"requestAdditionalDraw도 그렇고 이런 식으로 숫자가 아닌 입력을 허용하지 않도록 한 것은 창의적인 구현이라고 생각해요 👍 매번 입력타입이 늘어날 때마다 이러한 함수를 계속 만들어야 할까?라는 고민을 해볼 순 있겠네요."*
+
+→ **`request*` 함수 폭증** = *입력 타입마다 함수 1개* → *N 개 입력 = N 개 함수*.
+
+**3 가지 대안**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 함수별 분리 (현재) | *함수명 = 입력 의미 + 도메인 검증 통합* | *입력 ↑ = 함수 ↑ 폭증* |
+| Generic `inputView.read<T>(prompt: String, parser: (String) -> T): T` | *함수 1개로 모든 입력 처리* | *parser 람다 매번 작성 + 도메인 검증 분산* |
+| Sealed Input + ViewModel | *Input 일급화 + 검증 단일 위치* | *복잡도 ↑* |
+
+reviewer *고민해볼 순 있겠네요* = *현재 안 OK + 미래 확장 의식*.
+
+**MCP 룰 `input-function-proliferation-vs-generic` 후보** — *입력 함수 폭증 vs Generic read*.
+
+### 14. `enum class GameResult.not()` operator 활용 — Kotlin 어휘
+
+```kotlin
+operator fun not(): GameResult = when (this) {
+    BLACKJACK_WIN -> LOSE
+    WIN -> LOSE
+    LOSE -> WIN
+    DRAW -> DRAW
+}
+```
+
+→ **`operator fun not()` = enum 반전 어휘**. *딜러 결과 = !플레이어 합계*.
+
+다만 *논리 부정 (`!`) 의미와 enum 반전 의미 비교 어색*:
+- *`!Boolean` = true ↔ false* (논리 부정).
+- *`!GameResult` = WIN ↔ LOSE, DRAW → DRAW* (의미 반전).
+- *`!ProfitMoney` = -value* (부호 반전).
+
+**3 가지 트레이드오프**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `operator fun not()` (현재) | *간결 (`!result`) + Kotlin 어휘* | *`!` 가 *논리 부정* 의미와 혼동* |
+| `fun inverse()` / `fun reverse()` | *의미 명시 + `result.inverse()` 명확* | *Kotlin operator 어휘 손실* |
+| `operator fun unaryMinus()` (ProfitMoney) | *`-result` = 부호 반전 의미 자연* | *enum 에는 어색* |
+
+reviewer 명시 X — 다만 *Kotlin 어휘 깊은 활용* 칭찬 가치.
+
+PR #133·#137·#148·#90 (Money operator plus, ProfitMoney 정공) 결.
+
+**MCP 룰 `operator-not-semantic-misalign` 후보** — *`operator fun not()` 의미 일치 트레이드오프*.
+
+### 15. State 패턴 자식 책임 부여 미적용 — reviewer 후속 권유
+
+reviewer (위 §잘한점 2 인용):
+
+> *"CardState가 스스로 일할 수 있도록 👍 이를 더 구체화하여 자식들에게도 책임을 부여하면 지난 수업처럼 상태 패턴의 모습을 띄게 할 수 있습니다."*
+
+→ **State 패턴 미적용 (자식 책임 부여 X)** — 현재 CardsState 자식 (BlackJack/Bust/Running) 은 *데이터 컨테이너* + *분기는 외부 (GameResult.valueOf when)*.
+
+**State 패턴 정공**:
+
+```kotlin
+sealed class CardsState {
+    abstract fun compareWith(other: CardsState): GameResult
+
+    object BlackJack : CardsState() {
+        override fun compareWith(other: CardsState): GameResult = when (other) {
+            is BlackJack -> DRAW
+            else -> BLACKJACK_WIN
+        }
+    }
+    object Bust : CardsState() {
+        override fun compareWith(other: CardsState): GameResult = when (other) {
+            is Bust -> WIN
+            else -> LOSE
+        }
+    }
+    data class Running(val score: Int) : CardsState() {
+        override fun compareWith(other: CardsState): GameResult = when (other) {
+            is Bust -> WIN
+            is BlackJack -> LOSE
+            is Running -> compareByScore(score, other.score)
+        }
+    }
+}
+```
+
+PR #93·#136·#152·#98 결의 *State 자식 책임 부여*.
+
+**3 가지 트레이드오프**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 외부 when (현재) | *분기 한 자리 + sealed 자식 단순* | *State 자식 = 데이터 컨테이너 + Tell-Don't-Ask 위반* |
+| State 자식 추상 메서드 (정공) | *Tell-Don't-Ask + 다형성* | *self.compareWith(other) 와 other.compareWith(self) 대칭 깨기 시 어색* |
+| Visitor 패턴 | *State 추가 시 자식 수정 X* | *복잡도 ↑ + Kotlin 에 어색 (sealed when 이 더 자연)* |
+
+**MCP 룰 `state-children-method-vs-external-when` 후보** — *State 자식 추상 메서드 vs 외부 when*. 누적 6+ PR.
+
+### 16. 머지 후 후속 코멘트 (학습 종료 X)
+
+PR 머지일 = 2023-03-12. reviewer 의 마지막 라인 코멘트 2개 (`CardsState.kt` *상태 패턴 모습* + `BustCase.kt` *조건 활용 케이스 판별*) 가 머지 시점 동일.
+
+→ **머지 ≠ 학습 종료**. PR #23·#26 결의 *머지 후 후속 코멘트*. reviewer 가 *학생 추가 학습 권유* 의식.
+
+## 리뷰어 의견 요지
+
+- **Tell-Don't-Ask 2단계 재발** — *playerProfitResult 값 외부 조작 → 메시지 던지기 + 일급 컬렉션* + 외부 글 (jojoldu).
+- **Domain/View 비용 메타포** — *서버/클라이언트 라운드트립 비유*.
+- **`enum + condition lambda 분리` = builder 함수** — *condition 익명함수 의도 누수 + valueOf 빌더 함수 캡슐화*.
+- **sealed class 학습 깊이 + 자식 책임 부여 권유** — *학생 자가 답변 + reviewer 후속 confederate + 페어 프로그래밍 권유*.
+- **nullable enum vs not-nullable enum 3안** — *개인 의견 명시 + 학생 선택지 분리*.
+- **backing property + data class 융합 대안** — *방어적 복사 자가 의문 → reviewer 자가 답변*.
+- **`decideAceValue` 명명·실제 반환 불일치** — *이름 보고 1 or 11 반환 예상하는데 실제로는 추가 점수*.
+- **함수 호출 순서 = 호출자 먼저 + 읽기 편의** — Stepdown 원칙.
+- **`request*` 함수 폭증 미래 의식 권유** — *입력 타입마다 함수 폭증 vs Generic*.
+- **`List<Pair<String, Int>>` 도메인 명명 권유** — *뷰가 도메인을 너무 잘 알고 있다*.
+- **머지 후 후속 코멘트** — *학습 종료 X*.
+
+## 대표 인용
+
+> [woowahan-leah]
+> *"Domain을 서버, View를 클라이언트라고 가정해보고 View의 호출 최소화하여 비용을 줄여보면 어떨까요?"*
+
+→ **Domain/View 비용 메타포 어휘**. 새로운 reviewer 어휘. *Kent Beck 메타포* 어휘.
+
+> [boogi-woogi 자가 답변]
+> *"sealed 클래스를 사용해야하는 근거에 대해서 생각해보았습니다. enum class는 해당 class에 속하는 instance가 모두 같은 프로퍼티를 갖고 같은 형식으로 이루어져야 하기 때문에 Running 상태일때만 필요한 score를 처리하기가 어렵다고 생각했습니다. (...) sealed 클래스 사용 경험이 거의 없어서 이러한 상황에서의 사용이 적절했는지 잘 모르겠습니다! (미션 끝나고 sealed 클래스에 대해서 다시 꼭 정리하겠습니다)"*
+
+→ **학생 자가 학습 + 자가 한계 인정 + 미래 학습 의지 명시**. *학습 = 시간 두고 반복* 어휘 (PR #95·#98·#99·#23·#46 결).
+
+> [woowahan-leah]
+> *"이래야 진정으로 '직접 본인의 상태를 판단하는 객체'가 될 수 있지 않을까요? 고민해보고 이번 단계에 적용해보면 어떨까요? 어려움이 있다면 저와 페어 프로그래밍해봐도 좋습니다!"*
+
+→ **페어 프로그래밍 권유 + 학습 가시화** 어휘. *reviewer 가 학생 학습 적극 개입* 의식.
+
+> [woowahan-leah]
+> *"playerProfitResult값을 외부에서 꺼내서 조작하기보다 직접 메세지를 던져 요청하면 어떨까요? 다른 곳에서도 이렇게 메세지를 던져 구현해야 할 필요가 있는 곳이 없는지 점검해보세요! 상황에 따라 일급 컬렉션 사용이 필요할 수 있습니다."*
+
+→ **Tell-Don't-Ask + 다른 자리 점검 권유 + 일급 컬렉션 어휘**.
+
+> [woowahan-leah]
+> *"저는 참고로 nullable한 enum보다 not nullable한 enum을 선호하긴 합니다 🤔"* + *"아래 두 케이스는 참고만 해주세요!"*
+
+→ **개인 의견 + 학생 선택지 분리** 어휘. PR #23·#26·#95 결.
+
+> [boogi-woogi 자가 의문]
+> *"test를 하기 위해서 아래와같이 equals와 hashCode를 override 했습니다. data 클래스를 사용하고 싶었지만 인자로 들어오는 List<PlayerGameResult>에 대한 방어적 복사를 수행해야된다고 생각해서 이 방법을 사용했는데 적절한 사용인지 잘 모르겠습니다!"*
+
+→ **학생 자가 의문 + 자가 한계 인정** 모범. PR #91·#11·#13·#80·#106 결.
+
+## 얻은 교훈 (보편)
+
+1. **Tell-Don't-Ask 2단계 재발 = *부분 적용*** — *1단계 일부 자리 적용 → 2단계 다른 자리 재발*. *일관 적용 vs 부분 적용 트레이드오프*. **MCP 룰 `tell-dont-ask-partial-coverage` 후보**.
+
+2. **Domain/View 비용 메타포 = *서버/클라이언트 라운드트립***. *호출 비용 의식 = 메타포 어휘*. **MCP 룰 `domain-view-call-cost-metaphor` 후보** (메타포 = 학습 어휘).
+
+3. **enum + condition lambda = *데이터 메모리 낭비 + 의도 누수*** — *condition 함수 enum 멤버 보관 vs valueOf 빌더 함수 캡슐화*. 누적 8+ PR.
+
+4. **State 자식 책임 부여 = *진정한 State 패턴*** — *데이터 컨테이너 자식 + 외부 when vs 자식 추상 메서드 + 다형성*. 누적 6+ PR.
+
+5. **nullable enum vs not-nullable enum 3안 = *개인 의견 + 학생 선택지 분리*** — *MCP `oop_propose_alternatives` 핵심 가치*. 누적 9+ reviewer 어휘.
+
+6. **backing property + data class 융합** — *방어적 복사 자가 의문 + data class 양립 가능* (private val + getter toList()).
+
+7. **함수 명명 vs 실제 반환 불일치** — *`decideAceValue` 보고 1 or 11 예상 → 실제는 추가 점수*. **MCP 룰 `function-name-vs-return-semantic-mismatch` 후보**.
+
+8. **operator overloading 의미 일치** — *`operator fun not()` = 논리 부정 vs 의미 반전 양가*. **MCP 룰 `operator-not-semantic-misalign` 후보**.
+
+9. **Stepdown 원칙 = *호출자 먼저, 호출 함수 뒤*** — Clean Code 어휘.
+
+10. **Tuple 누수 (Pair<String, Int>) vs 도메인 DTO** — *뷰가 도메인을 너무 잘 알고 있다*. **MCP 룰 `tuple-leak-vs-domain-dto` 후보**.
+
+11. **request* 함수 폭증 vs Generic read** — *입력 타입마다 함수 1개 = 함수 ↑*.
+
+12. **머지 후 후속 코멘트 = *학습 종료 X*** — *reviewer 가 머지일에도 추가 코멘트*. PR #23·#26 결.
+
+13. **페어 프로그래밍 권유 = *reviewer 적극 개입*** — *학습 가시화 + 학생 의지 + reviewer 시간 투자*.
+
+## 얻은 교훈 (도메인)
+
+1. **블랙잭 1.5배 별도 enum 멤버 `BLACKJACK_WIN(1.5)`** — *Win + isBlackjack 분기* 반대 시점. 누적 8+ PR.
+
+2. **Ace 1 기본 + 단일 +10 룰** — *재계산 1회 + Ace 1장 한정 정확*. *Ace 2장 이상* 자가 처리 한계 + *while 차감 안티패턴 반대 시점*.
+
+3. **Singleton Deck (companion object MutableSet)** — *2판 이상 불가 + 테스트 격리 X*. 누적 17+ PR.
+
+4. **`operator fun not()` GameResult 반전 + ProfitMoney 부호 반전** — *딜러 결과 = !플레이어 합계* 도메인 의미. Kotlin operator 깊은 활용.
+
+5. **PlayerName + BattingMoney + ProfitMoney value class 3종** — *오프라인 페어 학습 이어진 자가 적용*.
+
+6. **`BlackJackCase / BustCase / RunningCase` 작은 enum 3개** — *플레이어 상태별 분기 평탄화*. PR #99 *WIN/LOSE × 블랙잭/일반 곱집합* 반대 시점.
+
+7. **CardsState `companion object valueOf(score, isInitialDraw)` + `isInitialDraw` 플래그** — *초기 2장 BlackJack 판정 + 추가 draw 후 BlackJack 판정 X 도메인 룰*.
+
+8. **`requestAdditionalDraw` `requestPlayersName` `requestBattingMoney`** — *함수 참조 (`InputView::requestAdditionalDraw`) 활용 깊음*. *콜백 람다 = 함수 참조 결합도 ↓*.
+
+## MCP 룰 후보 신규 (PR #36 신규 + 기존 강화)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `tell-dont-ask-partial-coverage` | 신규 | 1 (#36) — 1단계 적용 + 2단계 다른 자리 재발 |
+| `domain-view-call-cost-metaphor` | 신규 | 1 (#36) — *서버/클라이언트 비유* reviewer 어휘 |
+| `callback-lambda-view-cost` | 신규 | 1 (#36) — *콜백 람다 = View 호출 비용* |
+| `enum-nullability-axis` | 신규 | 1 (#36) — *nullable vs not-nullable vs NONE 멤버 3안* |
+| `function-name-vs-return-semantic-mismatch` | 신규 | 1 (#36) — *decideAceValue vs 실제 반환* |
+| `ace-bonus-single-vs-multi` | 신규 | 1 (#36) — *Ace +10 단일 룰 vs Multi-Ace* |
+| `operator-not-semantic-misalign` | 신규 | 1 (#36) — *operator fun not() 의미 일치* |
+| `function-order-stepdown` | 신규 | 1 (#36) — *Stepdown 원칙* |
+| `input-function-proliferation-vs-generic` | 신규 | 1 (#36) — *request* 함수 폭증 vs Generic* |
+| `tuple-leak-vs-domain-dto` | 신규 | 1 (#36) — *Pair<String, Int> 누수 vs 도메인 DTO* |
+| `backing-property-applicability` | 신규 | 2 (#36·#46) — *backing property 사용 시점 트레이드오프* |
+| `singleton-deck-via-companion` | 강화 | 17+ (누적) — companion object MutableSet/MutableList |
+| `lateinit-var-call-order-invariant` | 강화 | 8+ (누적) — 호출 순서 invariant |
+| `state-children-method-vs-external-when` | 강화 | 6+ (#93·#136·#152·#98·#36) — State 자식 책임 |
+| `enum-condition-lambda-misplacement` | 강화 | 8+ (#36·#98·#43·#107·#137·#148·#76·#86·#73) |
+| `blackjack-rule-fidelity` | 강화 | 8+ (#36·#26·#147·#88·#93·#136·#152·#133) — BLACKJACK_WIN 1.5배 |
+
+## 메타 어휘 (12 reviewer + MCP 핵심 가치 합류)
+
+- ***Domain/View 비용 메타포 (서버/클라이언트)*** — woowahan-leah PR #36 — *Domain ↔ View 호출 비용 의식*.
+- ***페어 프로그래밍 권유*** — woowahan-leah PR #36 — *학습 가시화 + reviewer 적극 개입*.
+- ***개인 의견 + 학생 선택지 분리*** — woowahan-leah PR #36 — *"저는 참고로 nullable한 enum보다 not nullable한 enum을 선호하긴 합니다 🤔"* + *"아래 두 케이스는 참고만 해주세요!"* — *MCP `oop_propose_alternatives` 핵심 가치 합류*.
+- ***외부 글 활용*** — woowahan-leah PR #36 — *jojoldu.tistory.com/412* (일급 컬렉션) — *외부 자료 + 자가 학습* 어휘.
+- ***머지 후 후속 코멘트*** — woowahan-leah PR #36 — *학습 종료 X + 추가 학습 권유*. PR #23·#26 결.
+- ***학생 자가 한계 인정 + 미래 학습 의지*** — boogi-woogi *"sealed 클래스 사용 경험이 거의 없어서 이러한 상황에서의 사용이 적절했는지 잘 모르겠습니다! (미션 끝나고 sealed 클래스에 대해서 다시 꼭 정리하겠습니다)"* — *학습 시간성 인정 + 미래 학습 시점 명시*. 누적 9+ PR.
+
+## 비교 (PR #18 → #36 진화 — 사족 X, 안티패턴 명시만)
+
+- **1단계 #18 신규 reviewer woowahan-leah → 2단계 #36 동일 reviewer = 학생-reviewer 페어 안정** (2 PR 누적).
+- **1단계 Tell-Don't-Ask (DrawState.POSSIBLE 외부 판단) → 2단계 playerProfitResult 외부 조작 재발** — *부분 적용*.
+- **1단계 enum 매직 넘버 자가 의문 → 2단계 enum + condition lambda 의도 누수 자가 의문** — *enum 학습 시간성*.
+- **1단계 일급 컬렉션 칭찬 → 2단계 일급 컬렉션 권유 + 외부 글** — *학습 시점 강화*.
+- **1단계 상속 vs 조합 자가 솔직 인정 → 2단계 sealed class 자가 한계 인정 + 미래 학습 의지** — *학생 자가 한계 인정 일관*.
+
+→ *진화 비교 = 사족 아님 (안티패턴 코드 위치 명시)* + *학생 자가 한계 인정 어휘 일관*.