oh-my-oop 0.2.0

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

@@ -0,0 +1,297 @@
+# PR #116 — [블랙잭 1단계] 동전 미션
+
+- **Reviewee:** [@donghyun81](https://github.com/donghyun81)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/116
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 24 / 리뷰이 6)
+
+## 잘한 점 (설계 관점)
+
+- **`Cards` 추상 클래스 + `Deck`/`Hands` 구체 구현** — *덱과 손패가 같은 기본 동작 (`accept`, `cards.count()`)*을 공유하면서 *서로 다른 역할*. 후속 분리.
+- **`Dealer(vararg card: Card) : this(Hands(*card))` 보조 생성자** — 테스트 친화.
+- **`Verdict.reverse()` — *상대 결과로 자기 결과 도출*** (Tell-Don't-Ask 1.5단계).
+- **`Verdict.determine(standardPlayer, comparePlayer)` 의 *bust 양측 처리*** + 학생 자가 인정 (못한 점 §10 참고).
+- **후속 반영 — *학생이 "현실 기반 사고가 잘못"이라고 자가 분석* → 점수 = 카드 책임으로 이전 + 자료구조 *Stack/Deque* 결정**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Suit.value` / `Verdict.value` UI 문자열 — **7개 PR 연속**
+
+```kotlin
+enum class Suit(val value: String) { HEART("하트"), SPADE("스페이드"), DIAMOND("다이아몬드"), CLUB("클로버") }
+enum class Verdict(val value: String) { WIN("승"), LOSE("패"), DRAW("무") }
+```
+
+리뷰어 (Suit): "*하트, 스페이드, 다이아몬드, 클로버가 위와 같이 출력 될 것이라는 것은 UI의 역할로 보입니다.* 만약 하트를 ❤️ 이렇게 출력한다면, *이는 도메인에서 수정할 책임일까요?*"
+리뷰어 (Verdict): "*요기도 동일한 것 같아요!* 만약 디자이너가 *WIN 처럼 출력해달라고 했는데 그때마다 도메인이 바뀌면 안되겠죠?*"
+
+→ **8개 PR 연속(#28·#78·#112·#125·#128·#135·#24·#116) 등장하는 안티패턴. MCP 룰 후보 최강.**
+
+### 2. `Choice("y"/"n")` 도메인 객체 — UI 형식 보유
+
+```kotlin
+class Choice(private val value: String) {
+    init { require(value == CHOICE_YES || value == CHOICE_NO) { ERROR_INVALID_CHOICE } }
+    fun isHit(): Boolean = value == CHOICE_YES
+    companion object {
+        private const val CHOICE_YES = "y"
+        private const val CHOICE_NO = "n"
+    }
+}
+```
+
+리뷰어: "*이어서 이 내용들도 모두 UI 관심사로 보입니다!* 도메인 입장에서 *굳이 value라는 것을 만들 필요가 있을까?* 라는 생각도 드네요." — `enum class Choice { YES, NO }`로 *도메인 어휘만*. `"y"/"n"` → `YES/NO` 매핑은 InputView.
+
+### 3. `InputView`가 `OutputView`를 가지고 *출력 호출*
+
+```kotlin
+class InputView {
+    private val outputView = OutputView()
+    fun readPlayerNames(): List<String> {
+        outputView.requestPlayerNames()       // ⚠ InputView → OutputView
+        val input: String = readln()
+        return input.split(...).map { ... }
+    }
+}
+```
+
+리뷰어: "*InputView가 직접 콘솔에 찍으면 안되는걸까요?* 굳이 OutputView를 다시 호출하는 이유가 궁금합니다."
+
+학생 자가 토론: "출력이라는 기능은 outputView이 관리하는 게 더 맞지 않나? 라는 의견에 *정확하게 반박하기 힘들*어서 *관점에 차이일 수 있다*고 생각이 되었습니다. 저는 *inputView랑 outputView가 화면이라고 생각*한다면 당연히 굳이 OutputView를 InputView가 전혀 의존할 필요가 없다고 생각하는데, *inputView와 outputView가 input과 output이라고 생각한다면 이렇게 받는 게 맞지 않나?*"
+
+리뷰어: "*콘솔에 입력받는것도 콘솔에 "출력"하면서 입력을 받지 않나요?* 입력과 출력을 어떤 기준으로 나누냐일 것 같은데요. *이름을 입력해주세요* '동전' <-- *이것도 출력이 아닌가?* 결국 *View라는 관점에서 본다면 입력과 출력으로 나누는게 아닌 입력을 위한 기능, 출력을 위한 기능 관점으로 접근하는게 맞지 않을까* 싶어요."
+
+→ **입력 vs 출력의 경계 = 기준 합의 필요**. *View 책임 자체*는 *입력을 위한 화면 + 출력을 위한 화면*. *InputView가 OutputView 호출*하는 구조는 *책임 분리가 아니라 책임 이전*.
+
+### 4. `InputView.readPlayerAction(player: Player): String` 반환
+
+```kotlin
+fun readPlayerAction(player: Player): String {
+    outputView.requestPlayerAction(player)
+    val input: String = readln()
+    return input
+}
+```
+
+리뷰어: "*InputView로부터 Choice를 반환 받으면 될 것 같은데 String을 반환한 이유가 있나요?* 도메인을 의존안한다고 하기에는 *이미 Player를 받기 때문에 앞뒤가 안맞습니다*. 또한 *만약 Y, N을 String으로 비교하는게 아닌 키오스크에서 버튼을 누를수도 있고 그림을 그릴수도 있다면 지금 구조는 불가능*하게 됩니다."
+
+→ **일관성 신호 — Player를 받으면서 String을 반환은 모순**. `Choice` enum 반환이 자연. + *Y/N String 비교*는 *콘솔 가정*이라 *UI 변형 불가능*.
+
+### 5. `Player.getScore()` — 점수 계산이 Player 책임
+
+```kotlin
+open class Player(val name: String, initCards: List<Card> = listOf()) {
+    fun getScore(): Int {
+        val score = this.cards.sumOf { it.rank.score }
+        return score + getBonusScore(totalScore = score)
+    }
+    private fun getBonusScore(totalScore: Int): Int { ... }
+    private fun hasAce(): Boolean = this.cards.any { it.rank == Rank.ACE }
+}
+```
+
+리뷰어: "*점수를 계산하는 것은 플레이어가 결정하는게 맞을까요?* *카드들을 관리하고 로직을 수행하는 역할의 객체가 필요하지는 않을까요?*"
+
+학생 자가 인정: "*제가 아직 현실을 기반으로 객체의 책임을 생각하는 부분이 많아서 잘못 생각 한 것 같습니다.* '플레이가 자기 점수를 계산하고 반환' 보다는 *'카드가 자기 점수를 반환'이 카드가 플레이어나 딜러가 아닌 다른 객체에 있더라도 자기 점수를 반환하는 것이 자율성이 더 높을 것 같습니다.*" — **PR #112·#114·#29·#24와 동일한 *점수 = 카드/Hand 책임* 결론**. 학생 자가 깨달음.
+
+### 6. `Player` open class 상속 — Participant 추상화 미시도
+
+```kotlin
+open class Player(val name: String, initCards: List<Card> = listOf()) { ... }
+```
+
+리뷰어: "*open class, abstract class, interface의 차이점을 알고 계신가요?* 플레이어 그리고 딜러는 *어떤 관계로 나타내야 적절할까요?* 가령 *딜러와 플레이어는 동일한 로직을 가지지만 일부는 서로 다른 로직을 수행*하고는 합니다. 이를 표현하기 위한 적절한 방법은 무엇일까요? 아래 힌트를 참고해보세요 :) ```#1 Participant ⨽Player ⨽Dealer #2 Player ⨽Dealer```"
+
+→ 두 가지 추상화 옵션 명시 (`Participant` 추상 + Player/Dealer / `Player` 기반 + Dealer 확장). PR #24·#29·#114와 동일 주제.
+
+### 7. `Cards` 추상 클래스 + `Cards` *덱 표현인지 모호*
+
+```kotlin
+class Cards(initCards: List<Card> = deckCards.shuffled()) {
+    private val cards: MutableList<Card> = initCards.toMutableList()
+    fun draw(count: Int = DRAW_DEFAULT_COUNT): List<Card> {
+        if (cards.count() < count) cards.addAll(deckCards.shuffled())   // ⚠ 무한 재공급
+        return List(count.coerceAtMost(count)) { cards.removeFirst() }
+    }
+}
+```
+
+리뷰어: "*카드들 생각하다가 흠칫했네요. 혹시 이 객체의 역할은 "덱"일까요?* 이 기능이 카드와 카드들의 관계로 *잘 어울리는지 앞서 피드백을 참고*해보시면 좋을 것 같아요. *`Card - Deck - Cards`*"
+
+→ `Cards`라는 *광범위 명사*가 *덱 + 손패* 둘 다 흡수. `Card - Deck - Hands` 두 가지 *역할*로 분리. *카드들* → *어떤 카드들?* 모호.
+
+또: "*덱을 표현하기에 또 다른 자료구조는 어떤게 있을까요?*"
+학생: "*자연스러운 자료구조는 선입후출인 Stack이 제일 자연스러운 자료구조*라고 생각 됩니다!" — Stack/Deque/LinkedList. 학생 후속: `Deck(LinkedList<Card>)`.
+
+### 8. `Deck.draw` *카드 모자라면 무한 재공급*
+
+```kotlin
+class Deck private constructor(override val cards: LinkedList<Card>) : Cards() {
+    fun draw(count: Int = DRAW_DEFAULT_COUNT): List<Card> {
+        if (cards.count() < count) accept(blackJackCards.shuffled())   // ⚠ 모자라면 52장 재공급
+        return List(count.coerceAtMost(blackJackCards.count())) { cards.pop() }
+    }
+}
+```
+
+리뷰어: "*카드가 모자라면 52장을 반환하는게 논리적으로 적절한 흐름인가요?* 다른 개발자도 바로 이해할 수 있는 것인지 *고민해볼 필요*가 있습니다. 한편으로는 *준비한 덱이 모두 소진되면 어떤 식으로 게임 진행이 되는지도* 같이 생각해보면 좋을 것 같아요. 지금 구조라면 *계속 뽑으면 무한정으로 뽑았던 카드를 또 뽑을 수 있겠*어요." — PR #135 (ijh1298) `refill`과 같은 결. *자동 재공급*은 *호출자 모름* + *덱 소진 invariant 무시*.
+
+### 9. `GameController`가 *Hand에 직접 끼워넣기* — accept 메서드의 어색함
+
+```kotlin
+private fun initialDeal(deck: Deck, participants: Participants) {
+    participants.players.forEach { player ->
+        player.hands.accept(deck.draw(START_CARD_COUNT))       // ⚠ player.hands에 직접 accept
+    }
+}
+```
+
+리뷰어: "*최초에 Hand를 준비할 때, 2장을 가진 상태로 생성을 하면 안되는건가? 라는 생각이 드는데요* *역할을 위해 accept라는 메소드가 만들어졋다기 보다는, accept를 쓰기 위해 구조를 억지로 바꾼듯한 느낌*이 들어서요" / "*참가자의 카드에 직접 끼워넣는 것 보다는 참가자에게 카드를 주는 것이 자연스럽지 않을까요?*"
+
+→ `player.hands.accept(cards)` 는 *Hand에 직접 접근*. `player.accept(cards)` 또는 *2장 보유 상태로 생성*이 자연. **메서드 등장 이유 = 호출자 편의면 안 됨**.
+
+### 10. `Dealer.determine` — *둘 다 Bust = 내가 승리* 룰 오해
+
+```kotlin
+private fun determine(otherHands: Hands): Verdict {
+    return when {
+        hands.isBust() && otherHands.isBust() -> WIN       // ⚠ 둘 다 Bust = 딜러 승
+        hands.isBust() -> LOSE
+        ...
+    }
+}
+```
+
+리뷰어: "*"둘다 버스트면 내가 항상 이긴다" 라는 규칙은 너무 불공평하지 않을까요?* 블랙잭 게임에서 *여러명이 버스트면 그 여러명은 그냥 패배*한겁니다." — *블랙잭 룰* 정확히 *각 플레이어 vs 딜러* 개별 판정. *딜러 Bust = 모든 안-Bust 플레이어 승*. *플레이어 Bust = 그 플레이어 패배*(딜러 상태 무관). **블랙잭 룰을 흐릿하게 이해**.
+
+또: `Verdict.reverse()`로 *상대 결과 → 자기 결과*는 좋으나, *Dealer가 비교 주체*인 구조 자체가 PR #28·#63·#125·#29·#24의 *match는 참가자 메시지* 권고에 어긋남.
+
+### 11. `Dealer.getPlayerVerdict` / `Dealer.getDealerVerdicts` — *플레이어 / 딜러 별도 호출*
+
+```kotlin
+fun getPlayerVerdict(players: List<Participant>): Map<Participant, Verdict> = ...
+fun getDealerVerdicts(players: List<Participant>): Map<Verdict, Int> = ...
+```
+
+리뷰어: "*Verdict이라는 것을 객체로 만들어 보면 어떤 차이점이 있을까요?* `class Verdict(...)` 플레이어와의 승부나 *딜러의 승부를 따로 호출하는 구조가 어색하게 느껴지기도* 합니다. *딜러도 플레이어도 결국 승리 수 패배 수 무승부 수라는 개념을 가지는게아닐까?*" — *Verdict 객체*로 *winCount/loseCount/drawCount*를 가지면 *Dealer/Player 모두 동일 추상 결과*. PR #24의 *1대다 GameResult*와 같은 결.
+
+### 12. `Hands`가 `Deck.START_CARD_COUNT`에 의존
+
+```kotlin
+class Hands private constructor(override val cards: MutableList<Card>) : Cards() {
+    fun isStartCardCount(): Boolean = cards.count() == START_CARD_COUNT      // Deck의 상수 참조
+}
+```
+
+리뷰어: "*시작할 때 뽑는 카드 수를 일부로 분리했는데 Hands에서 다시 의존하게 만든 이유가 있나요?*" — *Hands가 Deck의 룰을 안다*면 *공통 상수* 또는 *룰의 소유자*가 모호. PR #128 (ijh1298)의 *Dealer.Companion의 `ACE_EXTRACT_SCORE`*와 같은 결.
+
+### 13. `ChoiceTest` — *enum 동작 자체 테스트*
+
+```kotlin
+class ChoiceTest {
+    @Test fun `y가 입력될 시 true를 반환한다`() { assertThat(Choice.YES.isYes()).isEqualTo(true) }
+    @Test fun `n이 입력될 시 true를 반환한다`() { assertThat(Choice.NO.isYes()).isEqualTo(false) }    // ⚠ true? 함수명 오류
+}
+```
+
+리뷰어: "*이 테스트는 더이상 의미가 있는 테스트가 아닙니다 :) 🗑️*" — `Choice` 자체가 *enum 두 값*이면 *isYes() = (value == YES)* 항상 true. *자동 보장되는 동작을 테스트*는 *코드 → 테스트 동어반복*. (또: 두 번째 테스트 함수명에 `true를 반환` 오타.)
+
+### 14. `DeckTest` — *함수명 vs 실제 동작 불일치*
+
+```kotlin
+@Test fun `카드들에서 카드 2장을 반환한다`() {
+    val deck = Deck(listOf(Card(Suit.HEART, Rank.SIX), Card(Suit.HEART, Rank.SEVEN)))
+    assertThat(deck.draw(1)).isEqualTo(listOf(Card(Suit.HEART, Rank.SIX), Card(Suit.HEART, Rank.SEVEN)))  // ⚠ draw(1)이 2장?
+}
+```
+
+리뷰어: "*코드 라인은 줄이다보니 가독성이 현저히 떨어지게 된 것 같아요. 이 부분도 개선해주세요 그리고 2장을 반환한다는데 draw는 1입니다* 😓" — *테스트 함수명*과 *호출 인자 / assertion* 불일치 = 테스트가 *문서로서 거짓*.
+
+### 15. `HandsTest`에 `Player` 등장
+
+```kotlin
+class HandsTest {
+    @Test fun `플레이어는 카드를 받는다`() {
+        val actual = Player("동전", Card(Suit.HEART, Rank.ACE), Card(Suit.HEART, Rank.KING), Card(Suit.HEART, Rank.SIX))
+        hands.accept(listOf(Card(Suit.HEART, Rank.SIX)))
+        assertThat(hands.showCards()).isEqualTo(actual.hands.showCards())
+    }
+}
+```
+
+리뷰어: "*Hands를 테스트하는데 플레이어가 왜 나오는건가요?*" — *테스트 대상 ≠ 테스트 시나리오*. *Hands.accept*를 검증하려면 *Hands만 등장*.
+
+또: "*이 테스트를 읽는 사람이 보너스 점수가 어떤 원리로 동작하는지 이해할 수 있을까요?* 즉 성공하면 *왜 성공했는지 실패하면 왜 실패하는지를 알 수 있는 코드인지* 궁금합니다." — *테스트 = 사양서*. *왜 21점이 되는지*가 *카드 조합*에서 드러나야.
+
+### 16. `OutputView`가 *Dealer 1장 / Player 2장 공개* 결정 — 비즈니스 룰이 UI
+
+리뷰어: "*최초 공개시 딜러는 1장, 플레이어는 2장을 노출한다.* *비즈니스 로직이 아닐까요?* 이것을 *UI에서 결정하는 것이 게임의 규칙인지? UI의 규칙인지? 고민할 필요*가 있습니다. 우리가 만든 *참가자라는 역할 아래 딜러와 플레이어가 다른 구현을 가지도록 하는 것이 추상화를 적용해볼 기회*라고 봅니다." — PR #135·#92와 동일한 *공개 카드 수 = 비즈니스 룰*. `Participant.showInitialCards()` 추상 메서드.
+
+### 17. `GameController`가 *Dealer는 생성자 직접, Player는 이름만*
+
+```kotlin
+val participants = Participants(Dealer(), inputView.readPlayerNames())
+```
+
+리뷰어: "*참가자를 만드는데 딜러는 생성자로 직접 받고 플레이어는 이름만 받는게 일관성이 떨어지는 것 같습니다.*" — *Dealer 생성 (인스턴스)* vs *Player(이름)* 비대칭. `Participants.of(dealerName, playerNames)` 또는 *둘 다 이름 받기*.
+
+## 리뷰어 의견 요지
+
+- ***enum의 UI value = 8 PR 연속 안티패턴 (Suit.value, Verdict.value)***.
+- ***`Choice("y"/"n")` 도메인이 UI 형식 보유***.
+- ***InputView가 OutputView 호출 = 책임 이전*** — *입력을 위한 화면 / 출력을 위한 화면*.
+- ***InputView 반환 = Choice enum, String X***.
+- ***점수 계산 = 카드/Hand 책임*** (학생 자가 깨달음, *현실 기반 사고 자기 분석*).
+- ***Open class < Participant 추상*** (2가지 옵션 제시).
+- ***`Cards`는 광범위 명사, `Card - Deck - Hands`로 역할 분리***.
+- ***Deck 자동 재공급 = 호출자 모름, 덱 소진 invariant 무시***.
+- ***player.hands.accept(cards)는 메서드 등장 정당화가 호출자 편의*** — `player.accept(cards)` 또는 *2장 보유 상태 생성*.
+- ***둘 다 Bust = 내가 승리 = 블랙잭 룰 오해*** — *각 플레이어 vs 딜러 개별 판정*.
+- ***Verdict 객체로 winCount/loseCount/drawCount 통일*** — Dealer/Player 별도 호출 어색.
+- ***Hands가 Deck.START_CARD_COUNT 의존 = 룰 소유자 모호***.
+- ***`enum 동작 자체 테스트는 의미 없음***.
+- ***테스트 함수명 ≠ 동작이면 사양서로 거짓***.
+- ***테스트 대상 ≠ 테스트 시나리오*** (Hands 테스트에 Player 등장).
+- ***Dealer 1장 / Player 2장 공개 = 비즈니스 룰***.
+- ***참가자 생성에 Dealer 인스턴스 vs Player 이름은 비대칭***.
+
+## 대표 인용
+
+> 만약 하트를 ❤️ 이렇게 출력한다면, 이는 *도메인에서 수정할 책임일까요?*
+> — @laco-dev on `Suit.kt`
+
+> 객체지향 관점에서 *협력이라는 것과 자율성 측면에서 본다면, 승부를 벌이는 것은 누가 하는게 가장 적절*하다고 생각하시나요? 1. 플레이어와 플레이어 2. 플레이어와 딜러 3. 참가자와 참가자 4. 승패 / 한편으로는 *만약 승부를 결정하기 위해 플레이어의 정보를 계속해서 참견해야 한다면, 그것은 자율성이 깨진다*고 볼 수 있지 않을까요?
+> — @laco-dev on `Verdict.kt`
+
+> 결국 *View라는 관점에서 본다면 입력과 출력으로 나누는게 아닌 입력을 위한 기능, 출력을 위한 기능 관점으로 접근*하는게 맞지 않을까 싶어요.
+> — @laco-dev on `InputView.kt`
+
+> 카드가 모자라면 *52장을 반환하는게 논리적으로 적절한 흐름인가요?* [...] 지금 구조라면 *계속 뽑으면 무한정으로 뽑았던 카드를 또 뽑을 수 있겠*어요.
+> — @laco-dev on `Deck.kt`
+
+> "둘다 버스트면 내가 항상 이긴다" 라는 규칙은 *너무 불공평하지 않을까요?* 블랙잭 게임에서 *여러명이 버스트면 그 여러명은 그냥 패배*한겁니다.
+> — @laco-dev on `Dealer.kt`
+
+> 역할을 위해 accept라는 메소드가 만들어졋다기 보다는, *accept를 쓰기 위해 구조를 억지로 바꾼듯한 느낌*이 들어서요
+> — @laco-dev on `GameController.kt`
+
+## 얻은 교훈
+
+- ***enum의 UI 문자열 보유 = 8개 PR 연속 등장 (MCP 룰 후보 최강)*** — *디자이너가 표현 변경 요청 = 도메인 수정* 비효율.
+- ***Choice("y"/"n") = UI 형식이 도메인에*** — `enum Choice { YES, NO }`. 매핑은 InputView.
+- ***InputView → OutputView 호출은 책임 이전*** — *View = 입력을 위한 화면 + 출력을 위한 화면*. *Input/Output 분리*는 기능 분류이지 역할 분리 X.
+- ***InputView 반환 타입 = 도메인 어휘 (Choice)*** — String 반환은 *UI 형식이 호출자에 누수*. 키오스크/그림 같은 *대안 UI*에서 *재사용 불가*.
+- ***점수 계산 = 카드/Hand 책임, Player X*** — 학생 자가 깨달음 명시: *현실 기반 사고가 잘못*. *카드가 다른 객체에 있어도 자기 점수 반환이 자율성 ↑*.
+- ***open class < `abstract Participant`*** — 두 가지 추상화 옵션(`Participant`/`Player`) 모두 가능. *역할 차이가 일부면 추상 메서드*.
+- ***`Cards`는 광범위 명사 → 덱/손패 흡수*** — `Card - Deck - Hands` 두 역할로. PR #29 `Rule`과 같은 *광범위 명사 = 책임 흡인기* 패턴.
+- ***Deck 자동 재공급 = 호출자 모름 + invariant 무시*** — 덱 소진 시 *명시 신호*가 자연. (PR #135 ijh1298 refill + null + Elvis 결과 우수.)
+- ***`player.hands.accept(cards)` = 메서드 등장 정당화가 호출자 편의*** — *Hand에 직접 접근*. *2장 보유 상태로 생성* 또는 `player.accept(cards)`.
+- ***Bust 양측 = 무승부/딜러 승 모두 룰 오해*** — *플레이어 vs 딜러 개별 판정*이 정답. *블랙잭 룰 충실히 읽기* (PR #128 *점수 동률 = 무승부*와 같은 결).
+- ***Verdict 객체화 → winCount/loseCount/drawCount***로 Dealer/Player 통일 — *별도 호출* 어색.
+- ***Hands가 Deck.START_CARD_COUNT 의존 = 룰 소유자 모호*** — 도메인 룰 상수의 *소속 객체*는 *룰의 책임자*.
+- ***enum 동작 자체를 테스트는 동어반복*** — *호출 결과가 정의로 자명*하면 테스트 가치 ↓.
+- ***테스트 함수명 ≠ 동작이면 사양서로 거짓*** — `draw(1)이 2장 반환`은 사양 무력화.
+- ***테스트 대상 ≠ 테스트 시나리오*** — *Hands 테스트에 Player 등장*은 격리 위반.
+- ***Dealer 1장 / Player 2장 공개 = 비즈니스 룰*** — Participant 추상 메서드.
+- ***참가자 생성 비대칭 (Dealer 인스턴스 vs Player 이름) = 일관성 ↓*** — `Participants.of(dealerName, playerNames)` 또는 *둘 다 이름*.

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

@@ -0,0 +1,244 @@
+# PR #147 — [블랙잭 2단계] 동전 미션
+
+- **Reviewee:** [@donghyun81](https://github.com/donghyun81)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/147
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 15 스레드 / 26 코멘트 — *상태 클래스 분리 과잉 + 서비스 분리 의문 + 다형성 학습 진행 중*
+
+## 잘한 점 (설계 관점)
+
+- **상태를 클래스로 나누려는 시도** — 페로로 자가 칭찬: *"상태를 클래스로 나누려는 시도가 좋아 보입니다."* — *State 패턴 도입 의도*. 다만 *과잉 분리* 함정 동반 (못한 점 §1).
+- **`MatchResult.BLACKJACK_LOSE(-1.5)` 의도 명시 + 학생 자가 회고** — 학생 자가 답변: *"BLACKJACK_LOSE(-1.5)가 추가된 이유는 딜러도 각 플레이어와 수익을 계산할 수 있도록 MatchDealer가 matchResults를 가지고 구현하려고 추가했습니다. 하지만 구현하다 보니 matchPlayers에서 각 bettingPlayer들을 찾아서 다시 matchResults와 비교를 해야 하니 너무 복잡해져서 제거했는데, 이 부분을 제거를 안 했네요.. ㅎㅎ"*. **시도 → 복잡도 인식 → 후퇴 + 의도 명시 모범**.
+- **`Score` 객체 도입 시도** — 점수 계산 응집 시도. 다만 *블랙잭 / 딜러 룰 누수* 함정 동반 (못한 점 §6).
+- **`PlayingService` 고차함수 시도** — 학생 자가 답변: *"학습 내용에 고차함수에 관련된 내용이 있어서 반영 했는데, 기본적인 인터페이스를 통해서 사용 해보겠습니다!"*. **학습 진행 + reviewer 권고 흡수**. PR #132 (환노) / #137 (미플) 와 같은 결의 *고차함수 → interface*.
+- **수정 의지 + 다형성 학습 진행 중 자가 표현** — 학생 자가 답변: *"1단계 미션에서 다형성에서 느낀 장점은 ＂추상화된 타입에서 구현체들이 다른 일을 처리 할 수 있다＂ 를 제일 큰 장점으로 느꼈습니다. 하지만 수업에서 상태에 따라 처리하는 부분에서 조건을 줄이는 방법을 보면서 다형성에 장점에 관해서 다르게 느끼는 부분도 많고, 오히려 다형성이 뭔지 더 모호해진 느낌을 받았습니다. 이번에 클래스로 상태를 다 나누어 보고 페로로 피드백도 받아보면서, 왜 카드를 상태에 따라 처리했는지, 카드와 플레이어 중 상태에 따라 나누는 게 누구여야 하는지 등등 조금씩 감을 잡아가는 것 같아서 그에 따라 구현해보겠습니다."*. **학생 자가 학습 진행 + 메타 인식 모범**.
+
+## 못한 점 (설계 관점)
+
+### 1. `InitialParticipant / PlayingDealer / PlayingPlayer / ...` — *상태 × 참가자 = N × M 클래스 폭증*
+
+```kotlin
+// 추정 구조
+class InitialParticipant ...
+class InitialDealer ...
+class InitialPlayer ...
+class PlayingDealer ...
+class PlayingPlayer ...
+class MatchDealer ...
+class MatchPlayer ...
+```
+
+페로로 (InitialParticipant.kt — 미해결): *"상태를 클래스로 나누려는 시도가 좋아 보입니다. 다만, 상태마다 딜러 플레이어 참가자가 매번 쌍으로 만들어져 너무 많은 클래스가 필요합니다. 이외에 상태가 또 생길때마다 N개씩 반복해서 만들어지게 되는데 플레이어든 딜러가 매번 바뀌는게 맞는걸까요? 그렇지 않다면, 딜러와 플레이어가 가지고있는 \"카드패\"의 상태가 바뀌는 것으로 생각해보면 어떨까요? 딜러 - 카드패 : Initial -> Playing -> Finished. 플레이어 - 카드패 : Initial -> Playing -> Finished"*
+
+→ **상태 × 참가자 = N × M 클래스 폭증 안티패턴**. *블랙잭 = 3 상태 (Initial/Playing/Finished) × 2 참가자 (Dealer/Player) = 6 클래스 + Match 추가 시 9 클래스*. *상태 클래스 분리 의도는 좋으나 객체 단위 잘못 선택*.
+
+**진짜 분리 = "카드패" 의 상태 객체** — *Hand.Initial / Hand.Playing / Hand.Finished 3 클래스 + Dealer/Player 2 클래스 = 5*. *N + M*. 다만 *N × M = 6 → 9 → ...* 폭증. **MCP 룰 후보 — `state-times-actor-class-explosion`**. PR #131·#136·#152·#93 의 *State 객체 (5 클래스) + Participant 다형성 (2 클래스)* 와 *반대 트레이드오프*.
+
+학생 자가 학습 인용: *"다형성이 뭔지 더 모호해진 느낌"* — *과잉 분리 후 자가 인식*.
+
+### 2. `PlayingDealer.handState` — *Initial 상태도 HandState 만들 수 있음*
+
+페로로 (PlayingDealer.kt — 미해결): *"이러한 HandState는 플레잉중이 아니더라도 항상 만들어낼 수 있는 개념이라고 생각해요. Initial이어도 HandState를 계산할 수 있고 Match여도 계산할 수 있습니다."*
+
+→ **`HandState` 가 *Playing 상태에만 종속***. *Hand 의 점수/Bust/Blackjack 상태는 모든 시점 계산 가능*. *PlayingDealer 의존*은 *학생 의도와 실제 행동의 불일치*. PR #146·#131 의 *Score 도메인 객체* 와 같은 결의 *시점 무관 상태*.
+
+### 3. `InitService / PlayingService / ...` 서비스 분리 — *책임 분배 모호*
+
+페로로 (InitService.kt — 미해결): *"서비스를 두개로 쪼개면 어떤 이점이 있나요..? 게임의 준비 단계도 하나의 게임 시나리오중 하나인데 플레잉 참가자로 바꾸는건 또 개별적으로 하고 있고 Init 서비스가 무슨 일을 하기 위한 객체인지 잘 이해가 안되요"*
+
+학생 자가 답변: *"각 관심사를 가진 플레이어 끼리 서비스를 처리하면, 누가 게임시나리오 흐름에서 뭘 하는지 명확히 할 수 있고 수정 사항이 있어도 각 서비스에서만 수정 할 수 있지 않을까 싶어서 나눠 봤습니다. init이랑 play를 하는 플레이어가 같은 관심사를 가지고 있어서 의미는 없어보이지만 ㅎㅎ.."*
+
+→ **서비스 분리 = 단계별 책임 명시 의도** vs **실제로는 같은 관심사 분산**. *학생 자가 인식*: *"의미는 없어 보이지만"*. *YAGNI 위반*. PR #88·#136·#137 와 같은 결의 *추상화 과잉*.
+
+### 4. `MatchResult.BLACKJACK_LOSE(-1.5)` — *플레이어 -1.5배 손실 = 도메인 룰 위반*
+
+페로로 (MatchResult.kt:8 — 미해결): *"호앵... 딜러가 블랙잭이면 오히려 내가 돈을 더 뱉어야하나요?? 😱"*
+
+학생 자가 답변: *"... 하고 싶었던 구현은 when문을 제거해서 계산하고 각 플레이어의 대결을 뒤집어서 딜러가 보관하고 딜러의 대결 결과를 통해 딜러의 수익을 정하고 싶었는데 반대로만 남겨놔서 이상한 구현이 되었네요 ㅎㅎ..\"*
+
+→ **`BLACKJACK_LOSE(-1.5)` = 학생 의도 잔재**. *카지노 룰 = 플레이어 패배 시 -1배 (베팅금 손실)*. *-1.5 = 도메인 룰 위반*. *학생 자가 인식 + 제거 누락* — *구현 정리 부족 신호*. PR #128·#137 와 같은 결의 *수익률 룰 정확성*.
+
+### 5. `BettingPlayer` 에 *when 절 의미 부재 (자가 인식)*
+
+페로로 (BettingPlayer.kt — 미해결): *"이 로직에 when이 어떤 의미가 있나요?"*
+
+학생 자가 답변: *"승패 결과에 profitRate를 추가하고 나서 when으로 처리했던 부분을 없애야 하는데 생각없이 값만 처리했네요.. ㅎㅎ"*
+
+→ **`when` 절 잔재 = 리팩토링 누락**. *enum + profit: Double* 후속 반영 후 *when 절 dead*. *학생 자가 인식 + 후속 반영 모범*. PR #131·#132·#137 와 같은 결의 *enum 부가속성 응집*.
+
+### 6. `Score` 가 *블랙잭 + 딜러 룰 모두 알기*
+
+페로로 (Score.kt — 미해결): *"버스트나 최대 점수는 이해하겠는데 블랙잭이나 딜러 스테이가 점수랑 무슨 관련이 있나요? > 블랙잭을 판단하는 것, 딜러가 카드를 더 뽑을 수 있는지 판단하는 것. 위 비즈니스 로직을 Score가 책임지는게 적절한가요?"*
+
+학생 자가 답변: *"부적절하다고 생각됩니다! 수정하겠습니다."*
+
+→ **`Score` = *일반 점수 객체***. *블랙잭/딜러 룰 = Hand/Participant 책임*. *PR #146·#136·#131 와 같은 결의 *Score 룰 누수***. *학생 자가 인식 + 후속 반영 모범*.
+
+### 7. `ProfitPlayer` 클래스명 — *기능 + 클래스 이름 이어붙이기*
+
+페로로 (ProfitPlayer.kt — 미해결): *"게임 결과에 수익률 외에 다른 개념들도 필요하면 클래스 이름을 이어붙일건가요??? `class MatchResultProfitPlayerWithXXX()`"*
+
+학생 자가 답변: *"수익을 가지고 있는 클래스 보다는 수익과 관련된 행동을 하는 Player클래스라고 생각하고 명칭했지만, 공감 받기 너무 어려운 작명이였던 것 같습니다. 페로로는 명칭할때 행동에 따른 명칭은 어떤 부분을 신경쓰면서 작성해야 공감이 간다고 생각하시나요?"*
+
+페로로 후속: *"질문이 잘 이해가 안되네요. 근본적으로 `수익과 관련된 행동을 하는 Player`라는게 왜 있는지 모르겠어요. 플레이어에게 수익금을 계산하라는 요청을 하는게 먼저아닌가여?"*
+
+학생 자가 답변: *"음.. 그러네요 구현할때는 수익과 관련된 행동을 하는 Player라고 생각하고 만들었는데, 정리하다보니 상태만 남았던 Player여서 행동에 의미가 전혀 없는 클래스가 되었군요, 수정하겠습니다!"*
+
+→ **클래스명 = 기능 + 명사 이어붙이기 안티패턴**. *`ProfitPlayer / MatchResultProfitPlayerWithXXX`* 는 *기능 명사화 = 책임 분리 실패 신호*. *Player 자체에 수익 계산 메서드*가 정공. *Tell-Don't-Ask = `player.calculateProfit(dealer)`*. **MCP 룰 후보 — `feature-class-naming-explosion`**. PR #88·#125·#114·#146 의 *vagueName 변형*.
+
+### 8. `BettingPlayers.findXX` naming — *Kotlin find 의미 (nullable)*
+
+페로로 (BettingPlayers.kt — 미해결): *"흔히 find라는 의미는 코틀린에서 찾는다를 뜻해서 대부분 반환 타입이 nullable로만들어져요. `List.find { ... }`를 찾아보세요 비슷한 함수가 많습니다."*
+
+→ **`find` = nullable 반환 표준 (Kotlin stdlib)**. *non-null 반환 = `first` / `single`* 이 *Kotlin 어휘*. PR #108·#133·#58 와 같은 결의 *naming 부조화*.
+
+### 9. `DealerHit / PlayerHit / DoubleHit / ...` 분리 — *Hit 가 *주체별 다른 룰* 가정*
+
+페로로 (DealerHit.kt — 미해결): *"Hit에 딜러인지 플레이어인지를 엮는 이점이 있을까요? 만약 다른 Hit를 판단하는 My라는 룰이 생기면 MyHit YouHit DoubleHit 이런거를 계속 만들건가요?"*
+
+→ **`Hit` 에 *주체 엮기 = 폭증 안티패턴***. *`DealerHit`, `PlayerHit`* = *주체별 클래스*. *Hit = 행위*, *주체는 메서드 인자 또는 다형성*. PR #131·#136·#152·#93 와 같은 결의 *State 객체 분리* 와 *주체 분리* 의 차이.
+
+### 10. `Finished` 가 *Initial 상속* — *상속 모순*
+
+페로로 (Finished.kt — 미해결): *"Finished가 Initial을 상속하는게 엄청 모순적이지 않나요?"*
+
+→ **상속 = is-a 관계**. *Finished is-a Initial?* — *Finished 가 *초기 상태의 하위* 인가*. *논리적 모순*. *상태 객체 분리* 시 *공통 인터페이스 (State) + Initial/Playing/Finished 형제 클래스*가 정공. *상속 계층 부정확 = 학생 다형성 학습 진행 신호*. PR #93·#136·#152 와 같은 결의 *sealed/abstract State 형제 분리*.
+
+### 11. `Finished.draw` 가 *예외 던짐 = 자기 자신 반환 대안*
+
+페로로 (Finished.kt — 미해결): *"오류를 발생시키는것도 나쁘지 않은 방법인데 자기 자신을 반환하는 방법도 있습니다."*
+
+→ **`Finished.draw(card) = throw` vs `Finished.draw(card) = this`** 트레이드오프. *throw = 명시적 실패*. *self return = silent 무시*. *PR #152 (모찌) 의 Finish.draw throw IllegalStateException* 와 같은 결의 *throw 정공*. *PR #85 (하디) 의 Hand.draw stay → self return* 와 *반대 트레이드오프*.
+
+### 12. `Hands.bonus` 점수 처리 미이전 — *구현 일관성 부재*
+
+페로로 (Hands.kt — 미해결): *"점수로 다 옮겼는데 정작 보너스 점수는 안옮긴... 구현에 일관성이 떨어지는군요"*
+
+→ **점수 계산 → Score 이전 + 보너스 점수 (Ace 11 보정) Hands 잔존** = *책임 분산*. *Ace 보너스 = 점수 계산의 일부* — *Score 응집*이 일관. *학생 리팩토링 미완성 신호*.
+
+### 13. `PlayingService` 의 *초기 카드 시점 onPlayerState 호출* — *시점 모호*
+
+페로로 (PlayingService.kt — 미해결): *"카드가 2장이면 onPlayerState가 호출되는 상관관계가 있나요? 어색하지 않나요?"*
+
+학생 자가 답변: *"첫 초기화 상태일 경우에 호출 되도록 수정하겠습니다!"*
+
+→ **`카드 2장 → onPlayerState 호출` = 초기 상태 메시지 시점 모호**. *카드 수로 *초기 상태* 판단 = *Hand 의 isInitial 메시지*가 정공. *호출자 (Service) 가 카드 수 직접 검사 = Demeter 위반 + 시점 모호*.
+
+### 14. `BetTest` 미완성 주석 잔존 — *PR 위생*
+
+페로로 (BetTest.kt — 미해결): *"모두 완료되지 않았더라도 주석을 그대로 남기고 올리지는 말아주세요 :)"*
+
+학생 자가 답변: *"일이 있어서 피드백을 일요일 점심이후로 적용해볼려고 빨리 올리다보니 급하게 행동한 것 같습니다 ㅎㅎ... 주의하겠습니다"*
+
+→ **PR 위생 = 완성된 코드 + 주석 정리**. *미완성 주석은 reviewer 부담*. *Draft PR* 활용이 정공. *학생 자가 인정*.
+
+### 15. `PlayingService` 고차함수 vs 인터페이스 — 페로로 권고
+
+페로로 (PlayingService.kt — 미해결): *"TMI : 일단 무작정 고차함수로 만든 시도는 좋지만 우리는 협력을 위한 가장 기본적인 \"인터페이스\" 라는 것을 사용 할 수도 있었어요."*
+
+→ **고차함수 vs 인터페이스 트레이드오프**. *고차함수 = 함수 인자 = 간결 + 단일 동작*. *인터페이스 = 명시적 의존 + 다양한 구현 + 테스트 용이*. PR #132 (환노) 의 *고차함수 시도 → 인터페이스 권고* / PR #137 (미플) 의 *onXX 콜백 어휘* 와 같은 결.
+
+## 리뷰어 의견 요지
+
+- **상태 × 참가자 N×M 클래스 폭증 = "카드패" 의 상태 객체로 N+M 분리** — *Hand.Initial/Playing/Finished + Dealer/Player*.
+- **HandState 시점 무관 계산 가능** — *Playing 상태 종속 X*.
+- **서비스 분리 이점 모호 = 같은 관심사 분산** — 학생 자가 인식.
+- **`Hit` 주체별 분리 = 폭증 = Hit + 주체 인자 또는 다형성*** — *DealerHit / PlayerHit / DoubleHit* 회피.
+- **`Finished is-a Initial` 상속 모순** — 형제 클래스 + 공통 인터페이스.
+- **Finished.draw = throw vs self return 트레이드오프**.
+- **Score 가 블랙잭/딜러 룰 알기 = 누수** — 학생 자가 인식.
+- **`ProfitPlayer` 기능 + 명사 이어붙이기 = 책임 분리 실패 신호** — *Player 자체 메서드*.
+- **`find` = Kotlin nullable 반환 표준** — *non-null 은 first/single*.
+- **고차함수 vs 인터페이스 트레이드오프** — *인터페이스 협력 정공*.
+- **PR 위생 = 미완성 주석 X** — Draft PR 활용.
+
+## 대표 인용
+
+**페로로 (상태 × 참가자 폭증, InitialParticipant.kt):**
+> 상태를 클래스로 나누려는 시도가 좋아 보입니다.
+>
+> 다만, 상태마다 딜러 플레이어 참가자가 매번 쌍으로 만들어져 너무 많은 클래스가 필요합니다.
+> 이외에 상태가 또 생길때마다 N개씩 반복해서 만들어지게 되는데 플레이어든 딜러가 매번 바뀌는게 맞는걸까요?
+>
+> 그렇지 않다면,
+> 딜러와 플레이어가 가지고있는 "카드패"의 상태가 바뀌는 것으로 생각해보면 어떨까요?
+>
+> 딜러
+> - 카드패 : Initial -> Playing -> Finished
+>
+> 플레이어
+> - 카드패 : Initial -> Playing -> Finished
+
+**페로로 (Hit + 주체 폭증, DealerHit.kt):**
+> Hit에 딜러인지 플레이어인지를 엮는 이점이 있을까요?
+> 만약 다른 Hit를 판단하는 My라는 룰이 생기면 MyHit YouHit DoubleHit 이런거를 계속 만들건가요?
+
+**페로로 (상속 모순, Finished.kt):**
+> Finished가 Initial을 상속하는게 엄청 모순적이지 않나요?
+
+**페로로 (기능 + 명사 이어붙이기, ProfitPlayer.kt):**
+> 게임 결과에 수익률 외에 다른 개념들도 필요하면 클래스 이름을 이어붙일건가요???
+> ```
+> class MatchResultProfitPlayerWithXXX()
+> ```
+
+**페로로 (HandState 시점 무관, PlayingDealer.kt):**
+> 이러한 HandState는 플레잉중이 아니더라도 항상 만들어낼 수 있는 개념이라고 생각해요.
+> Initial이어도 HandState를 계산할 수 있고 Match여도 계산할 수 있습니다.
+
+**페로로 (find = nullable, BettingPlayers.kt):**
+> 흔히 find라는 의미는 코틀린에서 찾는다를 뜻해서 대부분 반환 타입이 nullable로만들어져요.
+> `List.find { ... }`를 찾아보세요 비슷한 함수가 많습니다.
+
+**학생 자가 학습 (다형성 학습 진행 중 메타 인식, InitialParticipant.kt):**
+> 1단계 미션에서 다형성에서 느낀 장점은 ＂추상화된 타입에서 구현체들이 다른 일을 처리 할 수 있다＂ 를 제일 큰 장점으로 느꼈습니다.
+> 하지만 수업에서 상태에 따라 처리하는 부분에서 조건을 줄이는 방법을 보면서 다형성에 장점에 관해서 다르게 느끼는 부분도 많고,
+> 오히려 다형성이 뭔지 더 모호해진 느낌을 받았습니다.
+> 이번에 클래스로 상태를 다 나누어 보고 페로로 피드백도 받아보면서, 왜 카드를 상태에 따라 처리했는지,
+> 카드와 플레이어 중 상태에 따라 나누는 게 누구여야 하는지 등등 조금씩 감을 잡아가는 것 같아서 그에 따라 구현해보겠습니다.
+
+**학생 자가 답변 (BLACKJACK_LOSE 의도 + 후퇴 누락, MatchResult.kt:8):**
+> BLACKJACK_LOSE(-1.5)가 추가된 이유는 딜러도 각 플레이어와 수익을 계산할 수 있도록 MatchDealer가 matchResults를 가지고 구현하려고 추가했습니다.
+> 하지만 구현하다 보니 matchPlayers에서 각 bettingPlayer들을 찾아서 다시 matchResults와 비교를 해야 하니 너무 복잡해져서 제거했는데, 이 부분을 제거를 안 했네요.. ㅎㅎ
+
+**학생 자가 답변 (서비스 분리 의문 자가 인식, InitService.kt):**
+> 각 관심사를 가진 플레이어 끼리 서비스를 처리하면, 누가 게임시나리오 흐름에서 뭘 하는지 명확히 할 수 있고 수정 사항이 있어도 각 서비스에서만 수정 할 수 있지 않을까 싶어서 나눠 봤습니다.
+> init이랑 play를 하는 플레이어가 같은 관심사를 가지고 있어서 의미는 없어보이지만 ㅎㅎ..
+> 역할 분리를 통한 재사용성에 관해서 솔직히 실질적으로 프로젝트를 만들고 확장하거나 수정해본적이 없어서 이론을 가지고 분리해야하는데 경험이 없으니 이론을 정립하거나 공감하기 어려워서 이것저것 해보는것이 좋다고 생각해서 해봤습니다!
+
+**학생 자가 답변 (ProfitPlayer naming 자가 인식, ProfitPlayer.kt):**
+> 음.. 그러네요 구현할때는 수익과 관련된 행동을 하는 Player라고 생각하고 만들었는데,
+> 정리하다보니 상태만 남았던 Player여서 행동에 의미가 전혀 없는 클래스가 되었군요, 수정하겠습니다!
+
+## 얻은 교훈
+
+1. ***상태 × 참가자 N×M 클래스 폭증 = "카드패" 상태 분리로 N+M***. *상태 클래스 분리 의도는 좋으나 객체 단위 잘못*. *Hand.Initial/Playing/Finished + Dealer/Player = 5*. *N×M (Initial×Dealer, Initial×Player, ...) = 6 → 9 → ...* 폭증. **MCP 룰 후보 — `state-times-actor-class-explosion`**.
+
+2. ***`Hit + 주체` 이름 폭증 = 행위 + 주체 인자 분리***. *DealerHit / PlayerHit / DoubleHit* 회피. *Hit = 행위* + *주체는 메서드 인자 (`compete(other)`) 또는 다형성*. PR #131·#136·#152·#93 와 같은 결.
+
+3. ***`Finished is-a Initial` 상속 모순 = is-a 관계 위반***. *상태 객체 = 형제 클래스 + 공통 인터페이스 (sealed/abstract State)*. PR #93·#136·#152 와 같은 결의 *State 형제 분리*.
+
+4. ***`ProfitPlayer / MatchResultProfitPlayerWithXXX` 기능 + 명사 이어붙이기 = 책임 분리 실패***. *Player 자체 메서드 (calculateProfit)* 가 정공. *기능 명사화 = naming 폭증*. **MCP 룰 후보 — `feature-class-naming-explosion`**. PR #88·#125·#114·#146 의 *vagueName 변형*.
+
+5. ***`HandState` 시점 무관 = 모든 시점 계산 가능***. *Playing 상태 종속 X*. *Hand 의 점수/Bust/Blackjack 은 시점 무관*. *PR #146·#131 의 Score 도메인 객체* 와 같은 결의 *불변 derived 값*.
+
+6. ***서비스 분리 = 같은 관심사 분산 시 의미 부재***. *학생 자가 인식 ("의미는 없어 보이지만")*. *YAGNI 위반*. *책임 분리 = 다른 책임 시*에만. PR #88·#136·#137 와 같은 결.
+
+7. ***`Score` 가 블랙잭/딜러 룰 알기 = 누수***. *Score = 일반 점수 객체*. *룰 = Hand/Participant 책임*. *학생 자가 인식 + 후속 반영*. PR #146·#136·#131·#108·#137 와 같은 결.
+
+8. ***`Finished.draw = throw` vs `self return` 트레이드오프***. *PR #152 throw (페로로) / PR #85 self return (페로로 같은 reviewer 다른 PR) 둘 다 합리*. *throw = 명시적 실패 vs self = silent*.
+
+9. ***`find` Kotlin nullable 반환 = non-null 은 first/single***. *Kotlin 어휘 표준*. PR #108·#133·#58 와 같은 결.
+
+10. ***고차함수 vs 인터페이스 트레이드오프 = 인터페이스 협력 정공***. *고차함수 = 함수 인자 간결 + 단일 동작*. *인터페이스 = 명시적 의존 + 다양한 구현*. PR #132·#137 와 같은 결.
+
+11. ***PR 위생 = 미완성 주석 X***. *Draft PR 활용*. *완성 PR 만 리뷰 요청*. *학생 자가 인정 + 후속 권고 흡수*.
+
+12. ***학생 다형성 학습 진행 중 메타 인식 = "다형성이 뭔지 더 모호해진 느낌"*** — *학생 자가 학습 진행 모범*. *상태 클래스 분리 → 폭증 → 페로로 진단 → 카드패 상태 객체 + Hand 다형성 학습 진행*. PR #128·#135·#108·#133·#137·#146·#41·#88 와 같은 결의 학생 자가 토론 풍부.
+
+13. ***`BLACKJACK_LOSE(-1.5)` 룰 위반 = 도메인 룰 정확성 실패***. *학생 의도 (딜러 입장 -1.5배 mirror) → 구현 복잡도 → 제거 결정 → 제거 누락*. *PR 정리 부족 신호*. PR #128·#137·#136 와 같은 결의 *수익률 룰 정확성*.
+
+14. ***`when` 절 리팩토링 후 잔재 dead code***. *enum + profit: Double 후속 반영 후 when 정리 누락*. *학생 자가 인식 모범*. PR #131·#132·#137·#88 와 같은 결.
+
+15. ***`PlayingDealer` HandState 종속 = State 객체 책임 모호***. *HandState = 시점 무관 derived*. *Playing 상태 종속*은 *학생 다형성 학습 진행 중 신호*. PR #146·#131 의 *Score 시점 무관* 와 같은 결.