oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-blackjack/doabletuple/126-1/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,680 @@
+# PR #126 — [블랙잭 1단계] 디랙 미션
+
+- **Reviewee:** [@doabletuple](https://github.com/doabletuple)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/126
+- **단계:** 1단계
+- **리뷰어:** [@KwonDae](https://github.com/KwonDae) (제이든) — 기존 reviewer (PR #129·#138·#67·#75·#99 동일)
+- **라인 코멘트:** 18 스레드 — *PR 본문 자가 의문 1개 (Verdict 문자열 = View 책임?) + reviewer Thread 9 답변 + 모든 18 스레드 학생 자가 답변 + commit SHA + 학생 자가 후속 의문 4+ 회 + 현실 메타포 (참가자가 자가 판단 + 외부 장치 X) + Tell-Don't-Ask + 추상화 활용 점검 (canHit / showHand / processHits) + Kotlin 어휘 자가 학습 (open vs abstract vs interface, filterIsInstance) + 입력 검증 (공백/중복/딜러 이름 같음) + Choice/Verdict 도메인 → View 이동*
+- **신규 reviewee** (2025년 코호트 — 모바일 안드로이드 7기, PR #117·#129 와 동일 코호트, batch 19·20 합쳐 4 PR 표본 = 2025 코호트 코퍼스 형성).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 1개 + 자가 의견 명시 (2025 코호트 스타일)
+
+PR 본문:
+
+> *"승/패/무 상태를 관리하기 위해 `enum class Verdict`를 만들고, 각 엔트리가 `'승'`, `'패'` 또는 `'무'` 문자열을 갖도록 했습니다.*
+>
+> *생각해보니 해당 문자열들은 출력을 위해서만 사용되고 있는만큼, 엔트리를 문자열로 표현하는 것은 `View`의 책임에 더 가까운 것이 아닐지 헷갈리는 부분이 생겼습니다.*
+>
+> *반면 이 책임을 `View`로 옮긴다면 `View`가 `Verdict`별로 어떤 문자열을 사용할지 판단해야 할 것 같은데, `View`가 이러한 로직을 가져도 되는지에 대해서도 확신이 서지 않았습니다.*
+>
+> *두 방법 중 어느 쪽이 MVC 패턴에 더 가깝다고 생각하시는지 궁금합니다."*
+
+→ **MVC 패턴 자가 의문 + 2 안 분석 + reviewer 자가 답변 (Thread 9)**:
+
+reviewer Thread 9 답변:
+
+> *"승, 패, 무 는 View에서 사용되는 로직으로 보여요! 혹시 디자인 요구사항이 기호로 바뀌었다면 도메인 로직이 수정되어야 할겁니다"*
+
+→ **변경 가능성 = View 책임 지표** = *디자인 변경 시 도메인 변경 X 시점 = View 책임 정공*.
+
+PR #35 (hyemdooly *PR 본문 자가 의문 3개 + reviewer 라인 답변*) 결의 *PR 본문 자가 의문 답변 가시성 정공* 어휘 합류. **MCP 룰 `pr-body-question-explicit-reviewer-quote` 강화** 누적 2+ PR (#35·#126).
+
+### 2. 모든 18 스레드 학생 자가 답변 + commit SHA + 자가 후속 의문 4+ 회 (2025 코호트 정점)
+
+- Thread 4: *open class vs abstract class 자가 답변 + Participant 추상 추가 자가 적용*.
+- Thread 7: *Participants 단일 인스턴스 의도 자가 답변 + 부생성자 제거 자가 적용*.
+- Thread 12: *변수명 `list` 자가 의문 + 4 안 (`participants`/`all`/`allParticipants`/`list`) 검토 + 자가 선택 (`all`)*.
+- Thread 13: *추상화 의도 자가 의문 + reviewer 의도 자가 확인*.
+- Thread 15: *processHits 시그니처 차이 자가 인지 + reviewer 답변 확인*.
+
+→ **모든 스레드 commit SHA 첨부 + 자가 후속 의문 풍부** = *PR #117·#129·#138 결의 *학생 자가 학습 가시화 정점* 유지*. 2025 코호트 4 PR (#117·#129·#138·#126) **합류**.
+
+### 3. `abstract class Participant` + Dealer/Player 자가 학습 정공
+
+```kotlin
+abstract class Participant(val name: String) {
+    protected val hand = Hand()
+
+    abstract fun canHit(): Boolean
+    abstract fun showHand(): List<Card>
+
+    fun accept(cards: List<Card>) { hand.add(cards) }
+    fun computePoint(): Int = hand.computePoint()
+    fun isBusted(): Boolean = hand.isBusted()
+    ...
+}
+```
+
+→ **`abstract class` + 2 추상 메서드 + 공통 로직 분리** = *PR #129·#138·#129 결의 *추상화 정공 자가 학습***.
+
+reviewer (Thread 4): *"open class를 활용하신 배경에는 어떤게 있었을까요? - open class - abstract class - interface 세가지는 어떤 차이점이 있을까요?"*
+
+학생 자가 답변:
+
+> *"`Dealer`는 `Player` 플러스 알파 정도의 역할일 것이라고 생각해서 `Dealer`가 `Player`를 상속하도록 `open class`를 사용했습니다. 하지만 리팩터링을 하다보니 히트하는 기준 등 서로 다르게 처리해야 하는 부분이 발생해서, `Participant` 추상 클래스를 만들고 `Dealer`과 `Player`가 `Participant`를 구현하도록 변경했습니다."*
+
+→ **학생 자가 *open class Player + Dealer : Player* 안티패턴 인지 + 자가 정정** = *PR #80·#82·#22·#11·#13·#73·#76 결의 *open class Player + Dealer : Player* 안티패턴 자가 인지 정공*.
+
+**MCP 룰 `open-class-vs-abstract-class-locator` 강화** 누적 8+ PR.
+
+### 4. `Hand` 객체 분리 — Participant god-object 회피
+
+```kotlin
+class Hand() {
+    private val cards: MutableList<Card> = mutableListOf()
+
+    fun show(count: Int = cards.size): List<Card> = cards.take(count).map { card -> card.copy() }
+    fun add(cards: List<Card>) { this.cards.addAll(cards) }
+    fun computePoint(): Int = ...
+    fun isBusted(): Boolean = computePoint() > BUST_THRESHOLD
+    ...
+}
+```
+
+→ reviewer (Thread 5): *"현재 Player가 다소 많은 역할을 갖고 있는거 같습니다. 게임 참가자, 딜러 모두 카드를 들고있는데 또 다른 객체로 분리해볼 수 있을까요?"*
+
+학생 자가 적용: *"딜러와 플레이어의 패를 `Hand` 클래스로 분리해보았습니다!"*
+
+→ **god-object 회피 + Hand 책임 분리** = PR #117·#129·#138 결의 *ParticipantCards 분리* 어휘 일치.
+
+#### 4.1. *`Hand.show(count: Int = cards.size)` 기본 인자 + 방어적 복사*
+
+```kotlin
+fun show(count: Int = cards.size): List<Card> = cards.take(count).map { card -> card.copy() }
+```
+
+→ **방어적 복사 `card.copy()`** + **기본 인자 `count = cards.size` (전체) / count 명시 (일부)** = *Kotlin 어휘 정공*.
+
+다만 *기본 인자 분기 + count 명시 분기* = PR #117 결의 *function-multiple-roles-via-default-param* 변형 — *show() 전체 vs show(1) 일부 의도 양가*.
+
+### 5. `Player.compareAgainst(dealer): Result` 자가 판단 + 현실 메타포
+
+```kotlin
+fun compareAgainst(dealer: Dealer): Result {
+    if (isBusted()) return Result.LOSE
+    if (dealer.isBusted()) return Result.WIN
+
+    val point: Int = computePoint()
+    val dealerPoint: Int = dealer.computePoint()
+    return when {
+        point > dealerPoint -> Result.WIN
+        point < dealerPoint -> Result.LOSE
+        else -> Result.DRAW
+    }
+}
+```
+
+→ reviewer (Thread 10) — **현실 메타포 정공**:
+
+> *"이부분에 대해 같이 이야기 해보고 싶어요. 현재 Verdict라는 별도의 객체를 두어 승/패를 계산하고 있습니다. 현실세계에서 생각해본다면, 참가자와 딜러 스스로가 본인의 카드뭉치와 상대방의 카드 뭉치를 비교해서 각자의 승패 여부를 알거에요. 별도의 장치를 두어 계산하지 않습니다. 그렇다면 참가자 스스로가 판단할 수 있도록 해볼 수 있을까요?"*
+
+학생 자가 답변:
+
+> *"말씀하신대로 참가자가 스스로 승패 여부를 판단하는 것이 현실에 더 가까울 것 같네요. `Verdict`가 '기준 플레이어'와 '비교 플레이어'를 받아서 승패 여부를 반환하는 코드가 직관성이 떨어지는 것 같아 고민하고 있었는데, 참가자가 스스로 판단하도록 바꾸니 조금 더 직관적인 것 같습니다!"*
+
+→ **현실 메타포 + Tell-Don't-Ask + 학생 자가 깨달음**. **MCP 룰 `metaphor-fidelity-locator` 강화** 누적 10+ PR ⭐⭐⭐. PR #117·#129 (현실 메타포) 결 강화.
+
+### 6. `Dealer.getDealerResults` + `Result.reverse()` — 부호 반전 어휘
+
+```kotlin
+fun getDealerResults(playerResults: Map<Player, Result>): Map<Result, Int> {
+    return Result.entries.associateWith { result ->
+        playerResults.values.count { playerResult -> result == playerResult.reverse() }
+    }
+}
+
+enum class Result {
+    WIN, LOSE, DRAW;
+
+    fun reverse(): Result = when (this) {
+        WIN -> LOSE
+        LOSE -> WIN
+        else -> DRAW
+    }
+}
+```
+
+→ **`Result.reverse()` = 결과 반전 어휘** = PR #36 (`operator fun not()` GameResult 반전) 결의 *반대 시점 (`reverse` 명명)*. **MCP 룰 `enum-reverse-method-vs-operator-not`** — 누적 2+ PR (#36·#126).
+
+PR #35 (`getDealerProfitResult * -1` 부호 반전) 결의 *deal 결과 반전* 어휘 변형.
+
+### 7. `enum Action` 자가 적용 — String → Action
+
+reviewer (Thread 3): *"단순 String 대신 Hit or Stand를 명시적으로 반환하는 방법에는 무엇이 있을까요?"*
+
+학생 자가 적용: *enum class Action 생성 + HIT/STAND 반환*.
+
+→ **Stringly-typed → enum 변환** = PR #117·#20·#28·#125·#147·#65·#92 결의 *enum 변환* 정공.
+
+### 8. `Participants(dealer, players)` 생성자 타입 분리 — 컴파일 시 invariant 강제
+
+```kotlin
+class Participants(val dealer: Dealer, val players: List<Player>) {
+    val all: List<Participant> = listOf(dealer) + players
+
+    init {
+        val playerNames: List<String> = players.map { player -> player.name }
+        require(playerNames == playerNames.distinct()) { MESSAGE_ERROR_PLAYER_NAMES_NOT_UNIQUE }
+        require(playerNames.none { playerName -> playerName == dealer.name }) {
+            MESSAGE_ERROR_PLAYER_NAME_SAME_AS_DEALER.format(dealer.name)
+        }
+    }
+    ...
+}
+```
+
+→ **PR #129 결의 *생성자 타입 분리 정공* 자가 학습 정공** + **추가 invariant (이름 중복 X + 딜러 이름 X)**.
+
+reviewer (Thread 7):
+
+> *"현재 Controller에서는 두가지 생성자를 혼용하고 있는데, Participants는 '참가자의 집합' 이라는 객체로 하나의 게임에 하나의 인스턴스가 존재하는게 아닌걸까요?"*
+
+학생 자가 답변:
+
+> *"말씀하신대로 하나의 게임에 하나의 인스턴스가 존재하는 것이 의도였습니다! 딜러와 플레이어를 따로 관리할 필요가 있어서 부생성자를 추가했었는데, 결국에는 부생성자만 쓰게 된 것 같습니다 😅"*
+
+→ **단일 인스턴스 의도 = 생성자 타입 분리 + 부생성자 제거 자가 적용**. **MCP 룰 `compile-time-singleton-vs-runtime-filter` 강화** 누적 5+ PR (#129·#79·#92·#48·#126).
+
+### 9. `processHits` 다형성 + 시그니처 차이 자가 인지
+
+```kotlin
+// Player.processHits — readAction (입력) + printStatus (출력)
+fun processHits(
+    deck: Deck,
+    readAction: (Player) -> Action,
+    printStatus: (Player) -> Unit,
+) {
+    if (!canHit()) return
+    if (readAction(this) == Action.STAND) {
+        if (showHand().size == INITIAL_DRAW_COUNT) printStatus(this)
+        return
+    }
+    accept(deck.draw())
+    printStatus(this)
+    processHits(deck, readAction, printStatus)  // ← 재귀
+}
+
+// Dealer.processHits — printStatus (출력) 만
+fun processHits(
+    deck: Deck,
+    printStatus: (Dealer) -> Unit,
+) {
+    while (canHit()) {
+        printStatus(this)
+        accept(deck.draw())
+    }
+}
+```
+
+→ **`processHits` 시그니처 차이 자가 인지** + **추상화 X (시그니처 다름)**:
+
+학생 자가 의문 (Thread 15):
+
+> *"플레이어는 `processHits()` 시 `덱, 입력 함수, 출력 함수`가 필요한 반면 딜러는 `processHits()` 시 `덱, 출력 함수`만 필요해서 시그니처가 달라 추상 함수로 빼내지 못했는데, 제가 놓치고 있는 것이 있을까요? 😓"*
+
+reviewer 자가 인정 (Thread 16):
+
+> *"저도 공통로직에만 집중하다보니 외부 입력을 받아야 한다는 것을 놓쳤네요 🫠 맞습니다. 플레이어는 딜러와 달리 외부의 입력을 받아야 하기에 추상화가 어려울거에요. 지금 해주신 것 처럼 Participants 에서 행동하도록 잘 구현해주셨습니다 👍"*
+
+→ **학생 자가 한계 인지 + reviewer 자가 인정** = **양방향 토론 + reviewer 자가 후퇴 어휘**. PR #87 (reviewer 자가 후퇴), PR #129 (학생 자가 부분 거절) 결 합류.
+
+**MCP 룰 `abstract-method-blocked-by-signature-divergence` 후보** — *시그니처 차이 = 추상화 불가 = Tell-Don't-Ask 정공 (각 자식 메서드)*.
+
+다만 **Player.processHits 재귀 (PR #138 결) + Dealer.processHits while** — *동일 reviewer 가 PR #138 에 권유한 재귀가 PR #126 에 X*. 
+
+#### 9.1. *Player 재귀 + Dealer while 양가성*
+
+- *Player.processHits 재귀* = PR #138 결의 *함수형 정공* 자가 적용.
+- *Dealer.processHits while* = PR #138 의 *반대 시점 (명령형)*. 
+
+**학생 자가 일관성 X** — *Player 와 Dealer 양가성* = *추상화 의도 약함* 시사.
+
+### 10. 입력 검증 (공백/중복/딜러 이름 같음)
+
+reviewer (Thread 1, 이미지): *"입력에 대해 검증이 필요해 보여요!"*
+
+학생 자가 적용:
+- 참가자 이름 공백 X 검증.
+- 플레이어 이름 중복 X 검증.
+- 플레이어 ↔ 딜러 이름 같음 X 검증.
+
+→ **3 가지 invariant 자가 적용**. PR #129·#138 결 강화.
+
+### 11. 추가 칭찬 (수정 후 reviewer 칭찬)
+
+- Thread 6: *"`filterIsInstance` 를 활용할 수 있습니다."* + 학생 자가 적용. *Kotlin 어휘 자가 학습*.
+- Thread 11: *Participant.canHit 추상 메서드 자가 적용*.
+- Thread 14·15·16: *Participants 자가 행동 + 고차함수 자가 적용*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Verdict` 문자열 → View 책임 — PR 본문 자가 의문 답변
+
+학생 PR 본문 자가 의문 + reviewer (Thread 9) 답변 — §1 §5 참조.
+
+→ **MVC 책임 분리 = 변경 가능성 지표**. **MCP 룰 `model-view-dependency-direction` 강화** 누적 11+ PR ⭐⭐⭐.
+
+### 2. `InputView` 가 `OutputView` 호출 — 직접 print 권유
+
+reviewer (Thread 2):
+
+> *"InputView에서 OutputView로만 출력이 가능할까요? 바로 print로 출력하면 안되는걸까요? 🧐"*
+
+학생 자가 답변:
+
+> *"입력은 `InputView`가, 출력은 `OutputView`가 책임져야 한다는 생각에 `InputView`가 직접 출력을 하거나 출력할 때 쓰이는 상수를 가지고 있는 것이 조금 껄끄럽게 느껴졌던 것 같습니다.*
+>
+> *조금 더 고민해보니 `InputView`가 입력, `OutputView`가 출력만을 책임져야 한다기보다는 각자 입력을 위한 기능, 출력을 위한 기능을 책임져야 한다고 접근하는 것이 더 낫다고 생각됩니다."*
+
+→ **InputView 의 *입력 안내 메시지 출력* = InputView 책임**:
+
+#### 2.1. *2 가지 시점*
+
+| 안 | 의미 | 시점 |
+|---|---|---|
+| InputView 입력만 + OutputView 출력만 (학생 초안) | *완전 분리* | *너무 엄격* |
+| InputView 입력 + 입력 안내 출력 / OutputView 출력만 | *각자 기능 책임* | *Kotlin/실무 정공* |
+
+**MCP 룰 `input-view-output-strict-separation` 후보** — *입출력 분리 엄격성 트레이드오프*.
+
+### 3. `Choice` 도메인 패키지 X (View 로직)
+
+reviewer (Thread 8):
+
+> *"Hit or Stand의 역할을 하는 객체로 이해했습니다. 도메인으로 관리되어야 할 주체일까요? 도메인 패키지에 존재하지만 내부는 View에 관련된 로직으로 보이네요 🥲"*
+
+학생 자가 적용: *Choice → Action 변환 + 도메인 위치 적절성 자가 학습*.
+
+→ **객체 위치 = 책임 = 변경 영향 범위** = *Choice (View 입력 결과) ≠ Domain*.
+
+**MCP 룰 `object-locus-by-change-impact` 후보** — *변경 영향 범위 기준 객체 위치 결정*.
+
+### 4. 변수명 `list` → `all` — 타입 이름 사용 회피
+
+reviewer (Thread 12): *"변수명 `list`는 어떤 의미일까요?"*
+
+학생 자가 답변:
+
+> *"`participants`라는 이름도 고려했지만, 객체도 `participants`라는 이름으로 생성한다면 접근할 때 `participants.participants`가 되는 것이 어색하다고 생각해 `list`를 사용하게 됐습니다. 반면 `list`처럼 변수의 타입을 이름으로 사용하는 것도 권장되지 않는 것으로 이해하고 있어 다른 이름을 써야 할 필요성을 느끼고 있습니다 😅 `participants`, `all`, `allParticipants` 등 중에서 고민하다가 `all`로 변경해보았는데, 어떻게 생각하시나요?"*
+
+→ **변수명 트레이드오프 4 안 자가 분석**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `list` (학생 초안) | *간결 + Participants.list 명확* | *타입 이름 = 의미 약함* |
+| `participants` | *도메인 의미 명확* | *Participants.participants 중복* |
+| `all` (학생 자가 선택) | *Participants.all = 전체 명확* | *all 의 *전체* 의미 추상* |
+| `allParticipants` | *모든 참가자 명확* | *Participants.allParticipants 중복 유사* |
+
+학생 자가 학습 = *변수명 타입 이름 회피 + 도메인 어휘 + 중복 회피*. **MCP 룰 `variable-name-by-type-vs-meaning` 후보** — *List/Map 같은 타입 이름 회피*.
+
+PR #117 (Cards.cardsCount → Cards.count) 결 합류.
+
+### 5. 카드 N장 공개 = 비즈니스 로직 + Participants 자가 행동 (PR #129 결 강화)
+
+reviewer (Thread 13·14):
+
+> *"이부분을 깊게 고민해볼 필요가 있어요 🧐 카드를 n장 공개한다는 분명한 게임의 비즈니스 로직 중 하나입니다. 지금까지 구현한 것 처럼 참가자와 딜러의 행동을 추상화가 가능할겁니다"*
+
+> *"Participants 객체를 만들었다면 내부 프로퍼티를 꺼내 Controller에서 행동하는게 아닌, Participants 객체 스스로가 행동하게끔 해보는건 어떤가요?"*
+
+학생 자가 적용: *Participants.makeInitialDeals / Participants.processPlayersHits / Participants.processDealerHits* 자가 추가.
+
+→ **비즈니스 로직 = Participants 자가 행동 + 고차함수** = PR #129 결 강화. **MCP 룰 `business-logic-vs-controller-logic` 강화** 누적 3+ PR (#129·#138·#126).
+
+### 6. `Dealer.initialHandShown: Boolean` 지역 변수 + 상태 plus 가시화
+
+```kotlin
+class Dealer(...) : Participant(name) {
+    private var initialHandShown: Boolean = false
+    ...
+    override fun showHand(): List<Card> {
+        if (initialHandShown) return hand.show()
+        initialHandShown = true
+        return hand.show(INITIAL_VISIBLE_CARD_COUNT)
+    }
+}
+```
+
+→ **`var initialHandShown` 가변 상태 + 호출 자가 변경** = *호출 횟수 invariant 부재 + 부작용*.
+
+reviewer (Thread 18):
+
+> *"초기 덱을 보여줄 때 1장만 보여주기 위해 사용되는 변수로 이해했습니다. 지역변수 사용 대신, 현재 딜러의 상태를 보고 판단할 수 있지 않을까 생각했는데요"*
+
+→ **상태 변수 vs 도메인 상태 판단** — *`hand.size == 2` 면 초기 시점 추론 가능* (다만 *카드 추가 후 다시 2장 = 모호*).
+
+#### 6.1. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `var initialHandShown` (현재) | *명시적 + 1회 보장* | *가변 상태 + 호출 외부 의존* |
+| `hand.size == INITIAL_DRAW_COUNT` 판단 | *상태 기반 + 가변 X* | *카드 추가 후 다시 2장 = 모호* |
+| Controller 가 단계 관리 + showInitial / showFinal 분리 | *명시적 단계 + 가변 X* | *Controller 가 단계 어휘 알아야 함* |
+
+**MCP 룰 `state-flag-vs-domain-state-judgement` 후보** — *상태 플래그 vs 도메인 상태 판단*.
+
+### 7. `Hand.computePoint` Ace 단일 +10 룰
+
+```kotlin
+fun computePoint(): Int {
+    val point = cards.sumOf { it.rank.point }
+    return point + computeBonusPoint(point)
+}
+
+private fun computeBonusPoint(point: Int): Int {
+    if (point + BONUS_POINT <= BUST_THRESHOLD && hasAce()) return BONUS_POINT
+    return 0
+}
+```
+
+→ **Ace 1 기본 + 단일 +10 룰** = PR #36·#129·#138 결의 *단일 +10 룰 정공*. *Multi-Ace 처리 X* — PR #117 수학적 풀이와 *반대 시점*.
+
+**MCP 룰 `ace-bonus-single-vs-multi` 강화** 누적 4+ PR.
+
+### 8. `Player.canHit() = !isBusted()` — 21 시 hit 가능 (PR #129·#138 결과 같은 룰 와전 가능)
+
+```kotlin
+override fun canHit(): Boolean {
+    return !isBusted()  // !(point > 21) → point ≤ 21 → 21 시 hit 가능
+}
+```
+
+→ **Player 21 시 hit 가능** = *PR #129·#138·#139 결과 같은 시점*. *PR #35 (hyemdooly *21 시 stop 자가 결정*) 반대 시점*.
+
+**MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 14+ PR ⭐⭐⭐.
+
+### 9. `Dealer.canHit() = computePoint() <= HIT_THRESHOLD` (`<= 16`) — 정공
+
+```kotlin
+override fun canHit(): Boolean = (computePoint() <= HIT_THRESHOLD)
+
+companion object {
+    const val HIT_THRESHOLD = 16
+    ...
+}
+```
+
+→ **`<= 16` = 16 시 hit, 17 시 stop = 블랙잭 표준 룰 정공**. PR #138 결과 같은 의미.
+
+다만 **`HIT_THRESHOLD = 16`** 명명 양가 — *PR #35 `HIT_STANDARD_POINT = 17` (`< 17` 비교)* 와 *명명 + 비교* 양립.
+
+| 명명 / 비교 | 의미 |
+|---|---|
+| `HIT_THRESHOLD = 16` + `<= 16` (PR #126) | *16 이하 hit* |
+| `HIT_STANDARD_POINT = 17` + `< 17` (PR #35) | *17 미만 hit* |
+| `DEALER_MAX_SCORE = 16` + `<= 16` (PR #138) | *16 이하 hit* |
+| `DEALER_MAX_SCORE = 16` + `<` 16 (PR #129) | *16 미만 hit = 룰 와전* |
+
+→ **명명 + 비교 양립성 = 룰 정확성 지표**. PR #129 만 *룰 와전 (16 시 stay)*.
+
+### 10. `Card.copy()` 방어적 복사 — Hand.show 에서
+
+```kotlin
+fun show(count: Int = cards.size): List<Card> = cards.take(count).map { card -> card.copy() }
+```
+
+→ **`card.copy()` 방어적 복사** — *data class Card 의 copy() 활용*. *외부 변경 방지*. 
+
+다만 *Card 가 data class 면 *immutable* → *copy 불필요* (참조만 공유 OK).
+
+**MCP 룰 `defensive-copy-on-immutable` 강화** — PR #137·#148 결의 *방어적 복사 강박 (불변 객체)* 결 합류. 누적 3+ PR.
+
+### 11. `Player(name, vararg cards: Card)` 부생성자 — 테스트 fixture 의도
+
+```kotlin
+class Player(name: String) : Participant(name) {
+    constructor(name: String, vararg cards: Card) : this(name) {
+        accept(cards.toList())
+    }
+    ...
+}
+```
+
+→ **부생성자 = 테스트 fixture 의도 (vararg cards)** — *Player(name, card1, card2) 호출 = 카드 초기 보유 객체*. PR #35 결의 *DSL 테스트 fixture* 변형.
+
+**MCP 룰 `test-fixture-secondary-constructor` 후보** — *부생성자 = 테스트 편의*.
+
+### 12. `Player.processHits` 재귀 vs `Dealer.processHits` while — 양가성
+
+§9 참조.
+
+### 13. `Result.reverse()` enum 메서드 — `operator fun not()` 와 양가
+
+§6 참조. PR #36 의 *operator fun not()* 반대 시점 (명명 `reverse`).
+
+### 14. `Hand.cards: MutableList<Card>` private + 직접 변경 메서드 (add)
+
+```kotlin
+class Hand() {
+    private val cards: MutableList<Card> = mutableListOf()
+    fun add(cards: List<Card>) { this.cards.addAll(cards) }
+    ...
+}
+```
+
+→ **mutable List private + add 메서드 노출** = *PR #138·#117 결의 *mutable list public 노출* 반대 시점 정공*.
+
+### 15. `Participants.makeInitialDeals(deck: Deck)` — Deck 인자 받음
+
+```kotlin
+fun makeInitialDeals(deck: Deck) {
+    all.forEach { participant ->
+        participant.accept(deck.draw(Participant.INITIAL_DRAW_COUNT))
+    }
+}
+```
+
+→ **Deck 인자 = 외부 의존 명시** + **`participant.accept(deck.draw(N))` Tell-Don't-Ask 정공**. PR #138 결의 *객체 소유 vs 매개변수 전달 자가 학습* 일치.
+
+### 16. `Dealer.getPlayerResults` + `getDealerResults` — Tell-Don't-Ask + Dealer 결과 계산 책임
+
+```kotlin
+fun getPlayerResults(players: List<Player>): Map<Player, Result> {
+    return players.associateWith { player -> player.compareAgainst(this) }
+}
+
+fun getDealerResults(playerResults: Map<Player, Result>): Map<Result, Int> {
+    return Result.entries.associateWith { result ->
+        playerResults.values.count { playerResult -> result == playerResult.reverse() }
+    }
+}
+```
+
+→ **Dealer 가 *Players 결과 모음* + *Dealer 결과 모음* 책임** — *Player.compareAgainst(dealer) 호출 위임 + Dealer 가 결과 통계*. **Tell-Don't-Ask + Dealer 자가 통계**.
+
+다만 *Dealer.getDealerResults 가 Map<Player, Result> 받음* = *외부 객체가 결과 보유* → *Tell-Don't-Ask 부분 위반*. 
+
+대안: **`Players.getResults(dealer): Map<Result, Int>`** = *Players 일급 컬렉션이 자가 통계*.
+
+**MCP 룰 `result-aggregation-locator` 후보** — *결과 통계 위치 = Dealer vs Players vs 외부 객체*.
+
+### 17. `Participants.processPlayersHits` + `processDealerHits` 단순 위임 (PR #129 결)
+
+```kotlin
+fun processPlayersHits(deck: Deck, input: (Player) -> Action, output: (Player) -> Unit) {
+    players.forEach { player -> player.processHits(deck, input, output) }
+}
+
+fun processDealerHits(deck: Deck, output: (Dealer) -> Unit) {
+    dealer.processHits(deck, output)
+}
+```
+
+→ **PR #129·#87 결의 *단순 위임 메서드 = 추가 책임 X 인공* 강화** 누적 4+ PR.
+
+다만 **forEach + 인자 위임 = *Participants 가 *전체 처리* 의도* 측면 OK**. **트레이드오프**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 위임만 (현재) | *Tell-Don't-Ask + Controller 가벼움* | *Participants 추가 책임 X = 인공* |
+| 일급 컬렉션 추가 책임 | *Participants 가 *전체 통계 + 자가 처리* 가짐* | *책임 ↑* |
+| 위임 X + Controller 직접 호출 | *Participants 인공 X* | *Controller 가 forEach 처리* |
+
+### 18. 칭찬 (filterIsInstance Kotlin 어휘 자가 학습)
+
+reviewer (Thread 6): *"filterIsInstance 를 활용할 수 있습니다."* — 외부글 (kotlinlang.org).
+
+학생 자가 적용. **Kotlin 어휘 자가 학습** = PR #117·#138·#139 결.
+
+**MCP 룰 `kotlin-stdlib-extension-application` 후보** — *Kotlin stdlib 확장 함수 활용*.
+
+## 리뷰어 의견 요지
+
+- **PR 본문 자가 의문 (Verdict 문자열 = View 책임?) 에 라인 코멘트 답변 (Thread 9)** — *MVC 변경 가능성 = View 책임 지표*.
+- **InputView 가 입력 안내 메시지 출력 직접 = OK** — *각자 기능 책임 트레이드오프*.
+- **String → enum Action** — *Stringly-typed 회피*.
+- **open vs abstract vs interface Kotlin 어휘 자가 학습**.
+- **Hand 객체 분리 (god-object 회피)**.
+- **filterIsInstance Kotlin 어휘 권유 + 외부글**.
+- **Participants 단일 인스턴스 의도 + 부생성자 제거**.
+- **Choice 도메인 vs View 책임**.
+- **Verdict 문자열 = View 책임 (변경 가능성 지표)**.
+- **현실 메타포 (참가자가 자가 판단 + 외부 장치 X)** — PR #129·#138 결 강화.
+- **Participant.canHit 추상 메서드 자가 학습**.
+- **변수명 `list` → 도메인 어휘 (학생 자가 4 안 분석 + `all` 선택)**.
+- **카드 N장 공개 = 비즈니스 로직 + Participants 자가 행동**.
+- **Participants 자가 행동 (Controller 에서 내부 프로퍼티 꺼내기 X) + 고차함수**.
+- **processHits 시그니처 차이 = 추상화 어려움 (학생 자가 인지 + reviewer 자가 인정)**.
+- **외부에서 데이터 꺼내 작업 vs 내부 행동 (Tell-Don't-Ask)**.
+- **`initialHandShown` 지역변수 vs 도메인 상태 판단**.
+
+## 대표 인용
+
+> [doabletuple PR 본문]
+> *"생각해보니 해당 문자열들은 출력을 위해서만 사용되고 있는만큼, 엔트리를 문자열로 표현하는 것은 `View`의 책임에 더 가까운 것이 아닐지 헷갈리는 부분이 생겼습니다. (...) 두 방법 중 어느 쪽이 MVC 패턴에 더 가깝다고 생각하시는지 궁금합니다."*
+
+→ **MVC 자가 의문 + 2 안 분석**.
+
+> [KwonDae Thread 9]
+> *"승, 패, 무 는 View에서 사용되는 로직으로 보여요! 혹시 디자인 요구사항이 기호로 바뀌었다면 도메인 로직이 수정되어야 할겁니다"*
+
+→ **변경 가능성 = View 책임 지표** 어휘.
+
+> [KwonDae Thread 10]
+> *"이부분에 대해 같이 이야기 해보고 싶어요. 현실세계에서 생각해본다면, 참가자와 딜러 스스로가 본인의 카드뭉치와 상대방의 카드 뭉치를 비교해서 각자의 승패 여부를 알거에요. 별도의 장치를 두어 계산하지 않습니다."*
+
+→ **현실 메타포 + Tell-Don't-Ask 어휘** — PR #129·#138 결 강화.
+
+> [doabletuple Thread 10]
+> *"참가자가 스스로 판단하도록 바꾸니 조금 더 직관적인 것 같습니다!"*
+
+→ **학생 자가 깨달음**.
+
+> [doabletuple Thread 12]
+> *"`participants`라는 이름도 고려했지만, 객체도 `participants`라는 이름으로 생성한다면 접근할 때 `participants.participants`가 되는 것이 어색하다고 생각해 `list`를 사용하게 됐습니다. 반면 `list`처럼 변수의 타입을 이름으로 사용하는 것도 권장되지 않는 것으로 이해하고 있어 다른 이름을 써야 할 필요성을 느끼고 있습니다 😅 `participants`, `all`, `allParticipants` 등 중에서 고민하다가 `all`로 변경해보았는데, 어떻게 생각하시나요?"*
+
+→ **학생 자가 4 안 분석 + 자가 선택 + reviewer 의견 요청** — *학생 자가 학습 모범*.
+
+> [KwonDae Thread 16]
+> *"저도 공통로직에만 집중하다보니 외부 입력을 받아야 한다는 것을 놓쳤네요 🫠 맞습니다. 플레이어는 딜러와 달리 외부의 입력을 받아야 하기에 추상화가 어려울거에요. 지금 해주신 것 처럼 Participants 에서 행동하도록 잘 구현해주셨습니다 👍"*
+
+→ **reviewer 자가 한계 인정 + 학생 자가 인지 인정** — **양방향 토론 + reviewer 자가 후퇴 어휘**.
+
+> [KwonDae Thread 17]
+> *"외부에서 객체의 데이터를 꺼내 행동을 하기 보다, 객체가 이미 상태를 갖고 있기 때문에 내부에서 행동을 하는 것에 대해 이야기를 하고 싶었어요!"*
+
+→ **Tell-Don't-Ask 어휘 + 객체 상태 vs 외부 행동**.
+
+## 얻은 교훈 (보편)
+
+1. **PR 본문 자가 의문 + reviewer 라인 인용 + 답변** — PR #35 결 강화. **MCP 룰 `pr-body-question-explicit-reviewer-quote` 강화** 누적 2+ PR (#35·#126).
+
+2. **변경 가능성 = View 책임 지표** — *디자인 변경 시 도메인 변경 X = View 책임*. **MCP 룰 `change-impact-as-locus-criteria` 후보**.
+
+3. **InputView 의 입력 안내 출력 = OK (각자 기능 책임)** — *분리 엄격성 트레이드오프*. **MCP 룰 `input-view-output-strict-separation` 후보**.
+
+4. **open class vs abstract class vs interface 자가 학습 + open class Player + Dealer 안티패턴 자가 인지** — *Kotlin 어휘 정공*. **MCP 룰 `open-class-vs-abstract-class-locator` 강화** 누적 8+ PR.
+
+5. **Hand 객체 분리 (god-object 회피)** — PR #117·#129·#138 결.
+
+6. **현실 메타포 + Tell-Don't-Ask (참가자 자가 판단)** — **MCP 룰 `metaphor-fidelity-locator` 강화** 누적 10+ PR ⭐⭐⭐.
+
+7. **시그니처 차이 = 추상화 불가 + 학생 자가 인지 + reviewer 자가 인정** — *양방향 토론*. **MCP 룰 `abstract-method-blocked-by-signature-divergence` 후보**.
+
+8. **변수명 = 타입 이름 (list) 회피 + 도메인 어휘 (all)** — *학생 자가 4 안 분석*. **MCP 룰 `variable-name-by-type-vs-meaning` 후보**.
+
+9. **카드 N장 공개 = 비즈니스 로직 + Participants 자가 행동** — PR #129 결 강화. **MCP 룰 `business-logic-vs-controller-logic` 강화** 누적 3+ PR.
+
+10. **객체 위치 = 변경 영향 범위** — *Choice 도메인 vs View*. **MCP 룰 `object-locus-by-change-impact` 후보**.
+
+11. **`var initialHandShown` 가변 상태 vs 도메인 상태 판단** — *상태 플래그 vs hand.size 판단*. **MCP 룰 `state-flag-vs-domain-state-judgement` 후보**.
+
+12. **부생성자 (vararg cards) = 테스트 fixture 의도** — **MCP 룰 `test-fixture-secondary-constructor` 후보**.
+
+13. **enum reverse() vs operator fun not()** — *명명 + 의미*. **MCP 룰 `enum-reverse-method-vs-operator-not` 후보** 누적 2+ PR (#36·#126).
+
+14. **filterIsInstance Kotlin stdlib 어휘 자가 학습** — **MCP 룰 `kotlin-stdlib-extension-application` 후보**.
+
+15. **단일 인스턴스 의도 = 부생성자 제거 + 컴파일 시 invariant 강제** — PR #129 결 강화. **MCP 룰 `compile-time-singleton-vs-runtime-filter` 강화** 누적 5+ PR.
+
+16. **외부 데이터 꺼내 작업 vs 객체 자가 행동 (Tell-Don't-Ask)** — *고차함수로 메시지 전달*. PR #87·#129·#138 결.
+
+17. **모든 18 스레드 학생 자가 답변 + commit SHA + 자가 후속 의문 4+ 회** — *2025 코호트 4 PR 합류 (#117·#129·#138·#126)*.
+
+18. **Player 21 시 hit 가능 (`!isBusted`)** — *블랙잭 룰 PR #129·#138·#139·#126 결과 동일*. **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 14+ PR.
+
+19. **결과 통계 위치 (Dealer vs Players vs 외부)** — **MCP 룰 `result-aggregation-locator` 후보**.
+
+20. **단순 위임 메서드 = 추가 책임 X 인공 (PR #129·#87·#138 결 강화)** — 누적 4+ PR.
+
+## 얻은 교훈 (도메인)
+
+1. **Dealer 16 시 hit / 17 시 stop (`<= 16` 정공)** — PR #138 결과 같은 의미. PR #129 (`< 16` 와전) 반대 시점.
+
+2. **카드 N장 공개 = 비즈니스 로직 (Player 2장 / Dealer 1장)** — PR #129·#138 결.
+
+3. **블랙잭 1.5배 미적용** — *PR #126 1단계는 1.5배 분기 X (단순 WIN/LOSE/DRAW)*. PR #138 (2단계) 자가 적용 가능.
+
+4. **Ace 1 기본 + 단일 +10 룰** — PR #36·#129·#138 결.
+
+5. **참가자 자가 승패 판단 (외부 장치 X)** — *현실 메타포*.
+
+6. **이름 invariant (공백 X / 중복 X / 딜러 이름 X)** — *Participants invariant 3 종 정공*.
+
+## MCP 룰 후보 신규 + 강화 (PR #126)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `pr-body-question-explicit-reviewer-quote` | 강화 | 2+ (#35·#126) |
+| `change-impact-as-locus-criteria` | 신규 | 1 (#126) |
+| `input-view-output-strict-separation` | 신규 | 1 (#126) |
+| `open-class-vs-abstract-class-locator` | 강화 | 8+ |
+| `metaphor-fidelity-locator` | 강화 | 10+ ⭐⭐⭐ |
+| `abstract-method-blocked-by-signature-divergence` | 신규 | 1 (#126) |
+| `variable-name-by-type-vs-meaning` | 신규 | 2+ (#117·#126) |
+| `business-logic-vs-controller-logic` | 강화 | 3+ (#129·#138·#126) |
+| `object-locus-by-change-impact` | 신규 | 1 (#126) |
+| `state-flag-vs-domain-state-judgement` | 신규 | 1 (#126) |
+| `test-fixture-secondary-constructor` | 신규 | 1 (#126) |
+| `enum-reverse-method-vs-operator-not` | 신규 | 2+ (#36·#126) |
+| `kotlin-stdlib-extension-application` | 신규 | 4+ (#117·#138·#126·#139) |
+| `compile-time-singleton-vs-runtime-filter` | 강화 | 5+ |
+| `defensive-copy-on-immutable` | 강화 | 3+ (#137·#148·#126) |
+| `model-view-dependency-direction` | 강화 | 11+ ⭐⭐⭐ |
+| `result-aggregation-locator` | 신규 | 1 (#126) |
+| `simple-delegation-method-unnecessary` | 강화 | 4+ |
+| `blackjack-rule-fidelity-comparison` | 강화 | 14+ ⭐⭐⭐ |
+| `ace-bonus-single-vs-multi` | 강화 | 4+ |
+
+## 메타 어휘 (13 reviewer + MCP 핵심 가치 합류 정점 유지)
+
+- ***reviewer 자가 한계 인정 + 학생 자가 인지 인정*** — KwonDae PR #126 — *"저도 공통로직에만 집중하다보니 외부 입력을 받아야 한다는 것을 놓쳤네요 🫠"* — **양방향 토론 + reviewer 자가 후퇴 어휘**.
+- ***변경 가능성 = View 책임 지표*** — KwonDae PR #126 — *"디자인 요구사항이 기호로 바뀌었다면 도메인 로직이 수정되어야 할겁니다"*.
+- ***현실 메타포 = 참가자 자가 판단 (외부 장치 X)*** — KwonDae PR #126 — PR #129·#138 결 강화. 누적 10+ PR.
+- ***학생 자가 4 안 분석 + reviewer 의견 요청*** — doabletuple PR #126 — *"`participants`, `all`, `allParticipants` 등 중에서 고민하다가 `all`로 변경해보았는데, 어떻게 생각하시나요?"* — *학생 자가 학습 모범*.
+- ***Tell-Don't-Ask 어휘 (외부 데이터 꺼내 작업 vs 객체 자가 행동)*** — KwonDae PR #126.
+
+→ **13 reviewer + MCP 핵심 가치 어휘 합류 정점 유지**. **2025 코호트 코퍼스 형성 (4 PR: #117·#129·#138·#126)** = *셀프 체크리스트 + 모든 스레드 commit SHA + 학생 자가 의문 풍부 + reviewer 깊은 메타 어휘* 일관 패턴 확인.