oh-my-oop 0.2.0

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

@@ -0,0 +1,516 @@
+# PR #108 — [블랙잭 1단계] 시아 미션
+
+- **Reviewee:** [@Leeyerin0210](https://github.com/Leeyerin0210)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/108
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 30 스레드 / 62 코멘트 (리뷰어·리뷰이 다회 핑퐁 다수)
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 토론 — 딜러 이름 + Hand 책임 분리** — 학생이 *딜러 이름*에 대해 4가지 옵션(없음 → 출력시 "딜러" / 기본값 "딜러" / 타입 enum / 속성 비교)을 *자가 정리한 후* 4번을 *"모델과 뷰 결합"* 우려로 자가 제외. *Hand가 카드 보관 + 점수 계산 두 책임을 가지는가*도 학생이 *자가 의문*. PR 전체에 *학생 자가 의문 → 말리빈 메타 질문 → 자가 답변* 패턴 일관.
+- **`ShuffleStrategy` 인터페이스로 셔플 분리 → 테스트 가능 `CardDeck`** — 말리빈의 *"CardDeck 객체는 테스트가 불가능한 구조이네요!"* 한 줄 지적에 대해 *전략 패턴*으로 분리. `class CardDeck(val shuffleStrategy: ShuffleStrategy = RandomShuffle())` — 기본값 + 테스트 시 *순서 고정 셔플* 주입 가능. 말리빈 자가 칭찬: *"랜덤의 요소를 인터페이스-구현체 구조로 잘 쪼개주셨네요 👍"*.
+- **블랙잭 룰 정확성 자가 학습 — *"2장만으로 21이 나오면 블랙잭"*** — 처음에는 *점수 비교만*으로 승부 판정. 말리빈의 *"단순히 점수의 크고 작음 만을 비교해서는 승패를 판별할 수 없답니다. 블랙잭 도메인에 대해 더 잘 알아보세요"* 한 줄로 학생이 *블랙잭 룰 자가 학습* → *2장 + 21*만 진짜 블랙잭으로 자가 반영. 학생 자가 인용: *"블랙잭 게임이 왜 블랙잭인가 했는데, 2장만으로 21점이 나오면 블랙잭이라 하는 걸 알게 되었습니다."* PR #128·#135·#114·#124 와 같은 결.
+- **6덱 + 자동 재셔플 — 카드 부족 → 게임 강제 종료 회피 후속 반영** — 말리빈의 *"한창 게임이 진행되는 도중에 카드가 부족해 게임이 종료되는 것은, 정상적인 게임 프로그램일까요?"* + *"카지노에서 덱 6벌이 사라졌으니, 카지노 문 닫고 손님들을 모두 쫓아내지 않는 것 처럼, 게임이 강제 종료되는 것은 문제라고 생각해요"* 진단에 대해 *6덱*으로 늘렸다가 *그래도 무한 게임 보장 못 함* 지적 후 *"카드 없을 경우, 새 기본 덱을 가져와서 무한 뽑을 수 있도록"* 자가 반영. *현실 카지노 = 6시간 게임* 멘탈 모델로 학생 사고 전환.
+- **Effective Kotlin 자가 학습 — Item 4/14 정리 후 자가 답변** — 말리빈의 *"멤버변수와 메서드의 리턴타입은 모두 명시해주는 것은 어떨까요? ... Effective Kotlin Item 4·14 참고"* 권고에 학생이 *책 본인 정리* → *자가 답변* → *Unit 예외 의문* → *말리빈 보강*. *외부 참조 학습 → 자가 정리 → 자가 의문* 흐름이 모범.
+- **`invoke` 팩토리 함수로 카드 캐싱 노출** — 말리빈의 *"덱에서 미리 생성해둔 것을 아는 사람은 작성한 사람 뿐이겠지요. 다른 개발자가 카드를 생성하는 로직을 활용해야할 때, 카드의 생성자를 바로 불러버리는 것이 가장 간편한 방법은 아닐지요"* 메타 질문에 대해 `operator fun invoke(rank, suit)` 로 *`Card(...)` 호출 자체가 캐시 lookup* 으로 자가 반영. *"다른 개발자가 생성자를 바로 불러도 기존 캐시된 카드들을 부를 수 있도록"* 자가 답변.
+- **`BlackjackEngine` 도메인 객체로 게임 진행 책임 이전** — *"딜러와 플레이어가 카드를 뽑는 로직은 컨트롤러의 역할일까요?"* + *"게임의 진행 일련의 과정도 컨트롤러의 역할일지 고민해보세요"* 두 단계 의문에 대해 *`BlackjackEngine` 도메인 객체 신설* + *드로우 책임 이전*. **PR #124 (모찌) 의 `BlackjackController god-object` 와 정확히 같은 진단에 대한 *반대편 모범 답안*** — 시아는 *Engine 객체 신설*로 1단계 안에서 일부 해소.
+
+## 못한 점 (설계 관점)
+
+### 1. `Card.invoke` 와 *생성자 호출 가능성* 의 모호함
+
+```kotlin
+class Card(val rank: CardRank, val suit: CardSuit) {
+    companion object {
+        val SINGLE_DECK = CardRank.entries.flatMap { rank ->
+            CardSuit.entries.map { suit -> Card(rank, suit) }
+        }
+
+        operator fun invoke(rank: CardRank, suit: CardSuit): Card {
+            return SINGLE_DECK.findLast { it.rank == rank && it.suit == suit }
+                ?: throw IllegalArgumentException("[ERROR] 잘못된 카드 번호나 문양입니다.")
+        }
+    }
+}
+```
+
+말리빈 (Card.kt:18 — 미해결): *"카드를 가져오려면 아래 형태로 작성해야겠네요. `Card(CardRank.ACE, CardSuit.SPADE)`. 이것은 생성자로 호출한 것인지 invoke 함수를 호출한 것인지 저도 모르겠는데요? Java의 바이트코드를 뜯어보지 않는 이상 어떤 것을 호출했는지 알기가 매우 어려워요. **생성자를 호출하는 케이스가 된다면, 중복된 값을 가지는 인스턴스를 생성할 수 있는 단점이 여전히 있겠어요.** invoke함수를 선택한 이유가 있을까요? 이팩티브 코틀린의 팩토리 함수에 대해 알아보셔도 좋겠어요."*
+
+→ **`operator fun invoke` + `public class Card` 가 두 길**. *Card(rank, suit) 호출*이 *생성자*에 가는지 *invoke*에 가는지 *Kotlin 컴파일러 우선순위*에 묻혀 있음. *생성자가 우선*이라 *invoke가 잡히지 않을 가능성*. *private constructor + companion fun of(...)* 패턴이 *팩토리 함수의 정공*. `class Card private constructor(...) { companion object { fun of(rank, suit): Card = SINGLE_DECK.first { it.rank == rank && it.suit == suit } } }`.
+
+또한 `SINGLE_DECK.findLast` 의 `findLast` 는 *동일 카드가 여러 개*일 때 *마지막*을 찾는 의미인데 *SINGLE_DECK 자체가 unique* 이므로 `first` 가 자연. *naming 부조화*.
+
+### 2. `Hand` 의 `BUST_SCORE = -1` 센티넬 + `maxOf` 트릭
+
+```kotlin
+class Hand(firstCard: List<Card>) {
+    private val _cards: MutableList<Card> = firstCard.toMutableList()
+    val cards: List<Card> get() = _cards.toList()
+
+    fun isBust(): Boolean = score() == BUST_SCORE
+
+    fun score(): Int {
+        val baseScore = cards.sumOf { card -> card.rank.score }
+        return maxOf(baseScore.formatIfBust(), maxScoreWithAce(baseScore).formatIfBust())
+    }
+
+    private fun maxScoreWithAce(hardScore: Int): Int {
+        val containsAce = cards.any { card -> card.rank == CardRank.ACE }
+        return if (containsAce) hardScore + SOFT_OFFSET_SCORE else hardScore
+    }
+
+    private fun Int.formatIfBust(): Int = if (this > BUST_CRITERIA) BUST_SCORE else this
+
+    companion object {
+        private const val BUST_SCORE = -1
+        private const val BUST_CRITERIA = 21
+        private const val SOFT_OFFSET_SCORE = 10
+    }
+}
+```
+
+→ **Bust 점수를 *-1* 센티넬로 표현 + `maxOf` 로 둘 중 큰 값**. 사고 흐름:
+
+- baseScore = 카드 점수 합 (Ace는 1)
+- maxScoreWithAce = Ace 있으면 baseScore + 10
+- 둘 다 21 초과면 → -1 (BUST_SCORE)
+- maxOf 로 둘 중 큰 값
+
+이 트릭이 *작동은 함* (`maxOf(-1, 20) = 20`, `maxOf(-1, -1) = -1`). 다만:
+
+1. **`score() == BUST_SCORE` 로 Bust 판정** — *점수 -1이 Bust*라는 매핑이 *Hand 외부에 새지 않아야* 하는데 `isBust` 가 *내부 의미를 외부 의미와 연결*. *`score() < 0` = Bust*가 *암묵적 invariant*.
+2. **`score()` 가 *Bust일 때 -1 반환*** — 호출자가 *점수로 비교*하려고 `score()`를 부르면 *-1을 받고 잘못된 분기*. *Bust 분리* 가 *isBust 메시지로 먼저 묻기* 가 강제됨.
+3. **이름 — `BUST_CRITERIA=21` 은 *Bust 기준이 아니라 블랙잭 상한***. `MAX_SCORE = 21` / `BUST_SENTINEL = -1` 같은 이름이 자연.
+4. **두 점수 후보 비교** — *`maxOf(baseScore, baseScore + 10)`* 는 *baseScore + 10 > baseScore 항상*. *Ace 있으면 +10 후 21 이하인지만 보면 됨*. *현재 트릭*은 *둘 다 Bust면 -1, 한쪽만 Bust면 다른 쪽*. 결과는 맞으나 *Ace 1 기본 + 단일 +10 if (sum + 10 ≤ 21)* 패턴이 *모두 한 줄*. 학생이 *Bust 양가성*을 *센티넬 + maxOf*로 풀어 *복잡도가 늘었다*.
+
+말리빈은 *softScore/hardScore 이름*만 지적 (못한 점 §3 참고). *센티넬 -1 트릭* 자체는 미해결로 남음 — *2단계에서 다시 손볼 신호*.
+
+### 3. `softScore` / `hardScore` 모호 명명 → 후속 자가 반영
+
+```kotlin
+// 초기 (예상)
+private fun softScore(): Int { ... }
+private fun hardScore(): Int { ... }
+```
+
+말리빈: *"다른 개발자들도 softScore와 hardScore가 무슨 뜻인지 한 번에 유추할 수 있을까요?"*
+
+학생 자가 답변 (커밋 `f62c66c`): *"처음 함수 이름을 작성했을 때는 단순계산 이란 뜻으로 hard, 그의 반대인 soft라고 작성했으나, 다시 보니 확실히 확인하기 어려울 것 같아, 이름에 확실히 뜻이 들어가도록 수정했습니다."*
+
+→ **블랙잭 도메인 어휘는 *카지노 표준*** — 카지노에서는 *soft 17 / hard 17*이 표준 용어 (Ace를 11로 셌을 때 / Ace를 1로 셌을 때). 학생은 *"단순계산 = hard / 반대 = soft"* 라고 *임의 매핑*. *카지노 표준 어휘*라도 *블랙잭 미숙자*에겐 모호. *`baseScore`/`maxScoreWithAce`* 같은 *구현 의미가 보이는 이름*이 자연. *도메인 어휘 차용 vs 구현 의미 명시* 의 트레이드오프 — *내부 함수는 구현 의미*가 안전, *외부 API는 도메인 어휘*가 자연.
+
+### 4. `Hand(firstCard: List<Card>)` 생성자 파라미터 이름 — *list가 firstCard?*
+
+```kotlin
+class Hand(firstCard: List<Card>) {
+    private val _cards: MutableList<Card> = firstCard.toMutableList()
+    ...
+}
+```
+
+→ **`firstCard: List<Card>` 라는 모순**. *first* + *복수형 List<Card>* 가 *카드 1장 vs 카드 여러 장* 의 혼란. *`initialCards: List<Card>` / `cards: List<Card>`* 가 자연. *Player/Dealer 의 `firstCard: List<Card>` 멤버*도 같은 모순.
+
+### 5. `Player.firstCard` 멤버 + `Dealer.firstCard` 멤버 — *초기값을 멤버로 보유*
+
+```kotlin
+class Player(val name: String, val firstCard: List<Card>) : Participant(firstCard)
+
+class Dealer(val firstCard: List<Card>, val name: String = DEALER_NAME) : Participant(firstCard) {
+    fun getAdditionalDrawCount(): Int {
+        return hand.getHandCount() - firstCard.size  // ⚠ 초기 카드 수 vs 현재 손패 수
+    }
+    ...
+}
+```
+
+말리빈 (Player.kt:6 — 미해결): *"firstCard가 멤버로 선언될 필요가 있을지 고민해보세요. 또, 처음부터 Hand를 갖게하는 것도 자연스럽다는 생각이 드네요"*
+
+→ **`firstCard`를 멤버로 보유 = 초기 상태를 영구 보관**. *초기 카드 = 생성자 인자*면 *Hand 만들고 끝* — Player/Dealer 가 *기억할 필요 없음*. *`Dealer.getAdditionalDrawCount`* 가 *현재 손패 수 - 초기 카드 수*로 *추가 뽑은 수*를 계산하는데, 이건 *Dealer 가 자기 초기 상태와 현재 상태를 비교*하는 *시간 비교*. *추가 뽑은 수 자체가 도메인 메시지가 아니라 출력용 카운터*.
+
+말리빈 (Dealer.kt — 미해결): *"반환 값인 Int가 어떤 값을 의미하는지 유추하기는 어려워보여요. 나아가서, 어떠한 플랫폼의 (콘솔)의 영향으로 이렇게 구성했다는 느낌이 강하게 드네요. 도메인에서 이러한 것을 알아야할지 고민해보세요"*
+
+학생 자가 답변 (커밋 `a94d03f`): *"함수에서 뽑는 것과 몇개 뽑았는지 반환하기 두가지의 기능을 모두 제공하려고 해서 이런 문제가 생긴 것 같습니다. 뽑는 건 뽑기만 할 수 있도록 하고, 몇개 뽑았는지 반환하는 것은 메세지를 던져서 반환할 수 있도록 하였습니다."*
+
+→ *뽑기 + 카운트 두 책임 분리* 자가 답변. *firstCard 멤버 보유* 자체는 여전히 미해결.
+
+### 6. `Participant` 추상 클래스 — *추상이 하나도 없는데 abstract 사용*
+
+```kotlin
+abstract class Participant(firstCard: List<Card>) {
+    val hand: Hand = Hand(firstCard)
+
+    fun draw(cardDeck: CardDeck) {
+        hand.add(cardDeck.draw())
+    }
+
+    fun getHandSize(): Int = hand.getHandCount()
+    fun getScore(): Int = hand.score()
+}
+```
+
+학생 자가 답변 (Participant.kt 첫 코멘트): *"플레이어와 딜러 모두 참가자에 속하고, 참가자가 모두 공통으로 가져야 할 기능들이 있기 때문에 사용하는 것이 좋다고 생각했습니다."*
+
+말리빈 (후속): *"그렇다면, open class와 interface를 활용하는 것과 현재의 차이점은 무엇인가요? 그리고 나서 다시 한 번 생각해주세요. 그 둘을 사용하지 않고, 여기에서 abstract 키워드를 사용한 이유는 무엇인가요?"*
+
+학생: *"Open 클래스: 인스턴스화가 가능하므로 추상적인 개념(참가자)을 표현하는 데 적합하지 않습니다. ... Interface: 공통적인 메서드를 정의하는 데는 유용하지만, 상태나 생성자 로직을 포함할 수 없어서 ... 참가자는 모두 자신의 핸드를 가지고 있기 때문에, 한계가 명확하다고 생각했습니다."*
+
+말리빈 (재반박, Participant.kt:5 — 미해결): *"생성자 로직을 포함할 수 없는 것은 공감이돼요. 그런데 참가자가 모두 자신의 핸드를 가지고 있기 때문에 한계가 명확한 것은 공감이 되지 않아요. 인터페이스에서 hand를 반드시 구현해야한다는 것을 명시하면 모두 Hand를 가지게 만들 수 있으니까요. 현 코드를 interface로 전환하는 건 완벽하게 불가능한가요? **abstract class는 고장 난 부분은 당신이 채워 넣으라 라는 의미에 가깝다고 생각해요. 그런데 여기에는 abstract할 게 하나도 없으니, abstract를 사용할 이유가 없다고 생각해요 :)**"*
+
+→ **`abstract` 키워드의 의미 = "고장 난 부분(abstract method)을 자식이 채운다"**. *abstract method 0 + open property 0* 인 *Participant* 는 *생성자 로직을 공유하는 부모 클래스*일 뿐. *`open class` 면 동일 효과 + 인스턴스화 막으려면 `sealed class`*. *Kotlin sealed class* 가 *Player/Dealer 두 자식만 허용*하면서 *인스턴스화 불가*도 만족. PR #28·#135·#114·#125 와 같은 결 (`open class` vs `abstract class` vs `sealed class` 차이).
+
+학생의 *"Interface는 상태/생성자 로직 포함 불가"* 도 *Kotlin interface property* 로 우회 가능 (`interface Participant { val hand: Hand }`). *"한계가 명확"* 이라는 표현이 *Kotlin 기능 미숙*에서 옴.
+
+### 7. `CalculateResult` object — *정적 계산기 = 책임 누수*
+
+```kotlin
+object CalculateResult {
+    private fun getResult(oneSelf: Participant, other: Participant): WinningResult {
+        val oneSelfBlackjack = oneSelf.getHandSize() == 2 && oneSelf.getScore() == 21
+        val otherBlackjack = other.getHandSize() == 2 && other.getScore() == 21
+
+        return when {
+            oneSelfBlackjack && otherBlackjack -> PUSH
+            oneSelfBlackjack -> WIN
+            otherBlackjack -> LOSE
+            oneSelf.getScore() > other.getScore() -> WIN
+            oneSelf.getScore() < other.getScore() -> LOSE
+            else -> PUSH
+        }
+    }
+
+    fun getUserResult(dealer: Dealer, player: Player): WinningResult = getResult(player, dealer)
+    fun getDealerResult(dealer: Dealer, player: Player): WinningResult = getResult(dealer, player)
+}
+```
+
+말리빈 (CalculateResult.kt — 미해결): *"어떤 계산기가 딜러와 플레이어를 앞에 두고 카드를 비교해주면서 결과를 내어줄 수도 있겠어요. 현실세계를 반영해보는 건 어떨까요? **이겼는지 졌는지 알려주는 건 누가 하면 적절할 역할일지 고민해보세요** :)"*
+
+→ **`object CalculateResult` = 정적 헬퍼로 비교 책임 격리**. *Tell-Don't-Ask* 위반 — *`oneSelf.getHandSize()` / `oneSelf.getScore()`* 로 *자기 정보를 빼서* *계산기가 비교*. *Participant.compete(other: Participant): WinningResult* 메시지면 *participant가 자기 결과를 알려줌*. PR #124 (모찌) 의 `GameResult.of(score, score)` 와 *정확히 같은 안티패턴*.
+
+또한 *`getUserResult` / `getDealerResult` 가 같은 함수의 인자 순서만 바꾼 래퍼* — *둘 다 필요한가?* `compete` 가 *대칭적 메시지*면 *하나로 충분*.
+
+말리빈(WinningResult.kt 미해결): *"객체의 값을 직접 꺼내 비교하기보다, 객체에게 메시지를 던져보는 건 어떨까요? 그러다보면 이 점수 계산 로직이 어떠한 객체로 응집시킬 수 있어보이네요"* — *점수 비교 ≠ 점수 메시지*.
+
+학생 자가 답변 (커밋 `2fac65c`): *"로직을 분리하여 object로 만들었습니다! 메세지를 던지니 훨씬 더 객체끼리의 결합이 사는 듯 한 느낌이 드네요."* → **객체 → object 분리는 *Tell-Don't-Ask 해소*가 아님**. *`object`는 싱글톤 = 정적 헬퍼 = Ask 패턴*. 학생이 *"메시지 던지기"*를 *"호출자가 그 호출을 하는 행위 자체"* 로 오해. *진짜 메시지 던지기*는 *`participant.compete(other)`*.
+
+### 8. `Dealer.getWinDrawLossResult(players)` + `Players.results(dealer)` — *결과 집계 두 곳*
+
+```kotlin
+// Dealer.kt
+fun getWinDrawLossResult(players: Players): Map<WinningResult, Int> {
+    val result = WinningResult.entries.associateWith { INITIAL_SCORE }.toMutableMap()
+    players.value.forEach { player ->
+        val winningResult = CalculateResult.getDealerResult(this, player)
+        result[winningResult] = result.getOrDefault(winningResult, INITIAL_SCORE) + ADDITIONAL_RESULT_COUNT
+    }
+    return result.toMap()
+}
+
+// Players.kt
+fun results(dealer: Dealer): Map<String, WinningResult> =
+    value.associate { player ->
+        player.name to CalculateResult.getUserResult(dealer, player)
+    }
+```
+
+→ **`Dealer` 가 *딜러의 W/D/L 카운트 집계* + `Players` 가 *플레이어별 결과 매핑***. *결과 집계 책임이 두 곳에 분산*. *`GameResults` 일급 컬렉션* 이 *전체 매치 결과를 한 번에 보유* 하고 *각 입장에서 필요한 view 제공* 이 자연.
+
+또한 `Dealer.getWinDrawLossResult(players)` 는 *Dealer가 모든 플레이어를 받아서 자기 결과 집계* — *Dealer가 자기 결과를 직접 계산*하기 위해 *전체 플레이어 의존*. *비대칭*. *Player는 자기 결과만 알면 되는데 Dealer는 전체*. *Match/Game 객체*가 *모든 비교를 끝내고 각자에게 결과 분배* 가 자연.
+
+### 9. `BlackjackEngine` — *god-object 분리 시도 미완성*
+
+```kotlin
+class BlackjackEngine {
+    val cardDeck: CardDeck = CardDeck()
+
+    fun preparePlayers(names: List<String>): Players = Players(names.map { name -> Player(name, makeFirstCards()) })
+    fun prepareDealer(): Dealer = Dealer(makeFirstCards())
+    fun playerDraw(player: Player): Unit = player.draw(cardDeck)
+    fun dealerDraw(dealer: Dealer): Unit = dealer.drawUntilFinished(cardDeck)
+    fun makeFirstCards(): List<Card> = List(2) { cardDeck.draw() }
+}
+```
+
+말리빈 (BlackjackEngine.kt:1 — 미해결): *"컨트롤러에 여전히 남아있는 게임 진행에 대한 역할들을 이 객체에 잘 옮겨내시길 기대할게요 :)"*
+
+말리빈 (BlackjackEngine.kt:13 — 미해결): *"메서드명은 동사로 시작하도록 작성해보세요 :)"*  (`playerDraw` / `dealerDraw` 가 *명사+동사*)
+
+말리빈 (BlackjackEngine.kt:4 — 미해결): *"카드 덱도 주입 받게끔 만들어야 테스트 코드를 작성하기 원활해지겠어요 :)"*
+
+→ **`BlackjackEngine` 신설은 좋은 방향이지만 절반의 분리**:
+
+1. **`cardDeck = CardDeck()` 멤버 직접 생성** — 테스트 시 주입 불가. *생성자 인자*로 받아야 *순서 고정 셔플 테스트* 가능. 이미 `CardDeck`은 *전략 패턴*으로 주입 가능한데 *Engine* 단에서 다시 *new* 로 잠금.
+2. **`playerDraw(player)` / `dealerDraw(dealer)` 가 *Engine이 카드를 뽑아 Participant에 추가하는 절차*** — *진짜 메시지 던지기*면 *`player.draw(cardDeck)`* 만 호출자가 부르면 됨. *Engine 거치는 wrapper* 가 *간접 호출의 이중 단계*.
+3. **`makeFirstCards` 가 *2장 하드코딩*** — *블랙잭 초기 2장 룰*이 *Engine 메서드 내부에 상수*. *Dealer는 1장 공개 / 플레이어는 2장 공개* 라는 *공개 규칙*과 *분배 규칙*이 분리 안 됨.
+4. **`preparePlayers(names) / prepareDealer()` 의 *준비 책임이 Engine?*** — *Engine = 진행* 인지 *Engine = 준비 + 진행* 인지 경계 모호. *블랙잭 게임 = 한 번의 매치* 면 *생성자에서 다 받음*이 자연.
+
+말리빈의 *"컨트롤러에 여전히 남아있는 게임 진행 역할"* 은 *Engine 도입했지만 Controller 여전히 게임 진행 결정* 이라는 신호. 즉 *분리 시도 + 진짜 분리 실패*. PR #124 (모찌) 의 god-object 와 다른 양상이지만 *완전한 모범 답안은 아님*.
+
+### 10. `Hand(firstCard: List<Card>)` 생성 시 검증 부재
+
+```kotlin
+class Hand(firstCard: List<Card>) {
+    private val _cards: MutableList<Card> = firstCard.toMutableList()
+    ...
+}
+```
+
+→ **`Hand` 생성 시 *카드 0장도 허용***. *블랙잭 초기 2장 룰* 이 *Hand 자체에 강제되지 않음*. *Hand 가 자기 invariant 모름*. *0장 Hand 의 `score()` = 0* 인데 *블랙잭에서 0장 상태는 존재하지 않음*. *Engine.makeFirstCards()* 가 *항상 2장*을 만들어 *우회*하지만 *Hand 단독으로는 invariant 없음*.
+
+이건 PR #108 의 `Hand` 가 `Cards` 도메인 컬렉션 책임을 가진다는 점에서 *공통 점수 계산 + 카드 추가* 만 가지고 *블랙잭 초기 룰* 은 분리한 결과 — *Hand 가 블랙잭 hand가 아니라 generic card collection* 의 의도일 수도. 다만 *프로젝트 이름이 blackjack* 이고 *score() 가 21 기반* 이므로 *블랙잭에 결합* — *invariant 강제* 가 자연.
+
+### 11. `CardDeck.draw` 의 *자동 재셔플*  — *현실은 좋으나 invariant 깨짐*
+
+```kotlin
+class CardDeck(val shuffleStrategy: ShuffleStrategy = RandomShuffle()) {
+    private var cards = shuffleStrategy.shuffle(SINGLE_DECK)
+
+    fun draw(): Card {
+        return cards.removeFirstOrNull() ?: run {
+            cards = shuffleStrategy.shuffle(SINGLE_DECK)
+            return cards.removeFirst()
+        }
+    }
+}
+```
+
+→ **카드 없으면 자동 새 덱 + 셔플 + draw**. *말리빈의 "카지노 = 무한 게임"* 모델에는 정합. 다만:
+
+1. **`cards = ... shuffle(SINGLE_DECK)`** — *`var cards`* 가 *멤버 재할당*. *멤버 immutability* 가 깨짐 (`var` + 재할당). *덱이 비면 새 덱*이 *같은 덱 객체가 채워지는가 / 새 덱 객체로 교체되는가*가 *동일성 의미*에 영향. 카지노에선 *카드를 다 쓰면 새 덱을 카지노 직원이 꺼냄* — *덱 객체 자체가 바뀜*이 자연. *코드 동작*과 *현실 metaphor* 정합.
+2. **`SINGLE_DECK` 재참조** — `SINGLE_DECK` 은 *companion val 52장 list*. *매 재셔플마다 같은 52장*. *6덱(312장) 의도*가 PR 본문에 있었으나 *코드는 1덱 반복 셔플*. *이전 라운드 사용 카드와 새 라운드 카드가 겹칠 가능성*. *현실 카지노는 6덱 6벌 진행 후 새 6덱* — *코드는 1덱 반복*.
+
+### 12. `RandomShuffle` 클래스 + `ShuffleStrategy` 인터페이스 — *외부 라이브러리 자제 권고*
+
+```kotlin
+class RandomShuffle : ShuffleStrategy {
+    override fun shuffle(cardList: List<Card>) = cardList.shuffled().toMutableList()
+}
+```
+
+말리빈 (CardDeck.kt — 미해결): *"코틀린에서는 최대한 코틀린 라이브러리를 활용해서 구현해보세요 :)"*
+
+학생 자가 답변 (커밋 `011cfff`) + 의문: *"구현해보았습니다! 혹시 외부 라이브러리를 자제해야하는 이유를 알 수 있을까요?"*
+
+말리빈: *"코틀린에서 기본 제공되는 것들이 있으니 최대한 그것을 활용해보시길 바라요 :). 굉장히 많은 것들을 제공해주니 이것들을 익숙하게 다루는 것도 중요하다 생각해서요. 더 많이 나아간다면, 코틀린은 JVM에서만 돌아가는 언어가 아니기 떄문이기도 해요. 어떠한 핵심 로직을 멀티플랫폼 어딘가에 이식해야할 때, JVM의 코드인 java 코드가 들어간다면, 이식할 때 번거로운 문제가 많이 생겨나겠지요"*
+
+→ **Kotlin Multiplatform 관점**. *Java import (e.g., `java.util.Random`, `Collections.shuffle`)* 가 들어가면 *Kotlin/JS, Kotlin/Native 이식 시 충돌*. *`List.shuffled()` 는 Kotlin stdlib* 이므로 안전. 학생이 *현재 stdlib `shuffled()` 사용 중* — 좋은 면. 말리빈의 권고는 *향후 외부 라이브러리 도입 시 신중*.
+
+### 13. `BlackjackEngine.cardDeck` 직접 생성 — *테스트 가능성 손상*
+
+```kotlin
+class BlackjackEngine {
+    val cardDeck: CardDeck = CardDeck()  // ⚠ 멤버 직접 생성
+    ...
+}
+```
+
+말리빈 (BlackjackEngine.kt:4 — 미해결): *"카드 덱도 주입 받게끔 만들어야 테스트 코드를 작성하기 원활해지겠어요 :)"*
+
+→ **CardDeck은 ShuffleStrategy를 주입 가능**한데, `BlackjackEngine` 단계에서 다시 `CardDeck()` 으로 lock. *Engine 테스트 시 순서 고정 카드 시퀀스 주입 불가*. *생성자 인자*로 받는 *DI 패턴*이 자연. PR #112·#28·#125·#10 (Singleton Deck) 와 *부분적으로 같은 결* — *Engine이 Deck을 *직접 만든다*는 면이 *Singleton 의 변형*.
+
+### 14. `Player`/`Dealer` *firstCard val 멤버* + *Participant 의 hand*  — *초기/현재 분리의 잔재*
+
+```kotlin
+abstract class Participant(firstCard: List<Card>) {
+    val hand: Hand = Hand(firstCard)
+    ...
+}
+
+class Player(val name: String, val firstCard: List<Card>) : Participant(firstCard)
+class Dealer(val firstCard: List<Card>, val name: String = DEALER_NAME) : Participant(firstCard) {
+    fun getAdditionalDrawCount(): Int = hand.getHandCount() - firstCard.size
+    ...
+}
+```
+
+→ **`firstCard` 멤버 보유 + 생성자 인자 양쪽**. *Participant 생성자가 `firstCard` 받음 → Hand 생성 → 끝* 이어야 하는데 *Player/Dealer 도 `val firstCard`* 로 *영구 보유*. *Hand 안에 들어간 카드*와 *firstCard 멤버*가 *같은 List 참조* 인지 *별도 사본* 인지 명시 안 됨. `Hand(firstCard).toMutableList()` 가 *복사본*을 만드니 두 곳이 분리되어 있어 *하나만 변하면 분기*. *시간에 따라 다른 정보를 두 변수로 보유*하는 *시간 일관성 문제*.
+
+*Dealer.getAdditionalDrawCount* 가 이 *시간 비교*의 사용처. *추가 뽑은 수* 자체가 *블랙잭 도메인 메시지가 아니라 출력용 카운터* (말리빈 *"콘솔 영향"* 진단과 정합). PR #124 (모찌) 의 `Dealer._results` 와 같은 결.
+
+### 15. `Players` *MAX_PLAYER_COUNT = 7*  — *현실 카지노 기준?*
+
+```kotlin
+class Players(val value: List<Player>) {
+    init {
+        require(value.size in MIN_PLAYER_COUNT..MAX_PLAYER_COUNT) { ... }
+        require(value.distinct().size == value.size) { ... }
+    }
+    companion object {
+        private const val MIN_PLAYER_COUNT = 1
+        private const val MAX_PLAYER_COUNT = 7
+    }
+}
+```
+
+학생 PR 코멘트: *"플레이어가 8명까지 가능하고, 6덱을 넣었는데도 불구하고 카드가 모자라는 상황은 논리 오류라고 판단"*
+
+→ **현재 코드는 7명 제한 (8명 가정과 불일치 — PR 작성 후 다른 곳 수정한 흔적)**. *카지노 기준 = 6~7명*이 표준. *학생이 8명 가정* 했는데 *코드는 7* — *주석/PR 본문과 코드 어휘 불일치* 의 흔적. 안티패턴은 아니나 *도메인 가정 명시 부재*.
+
+### 16. `Card.SINGLE_DECK` companion val — *덱이 카드의 정적 데이터?*
+
+```kotlin
+class Card(val rank: CardRank, val suit: CardSuit) {
+    companion object {
+        val SINGLE_DECK = CardRank.entries.flatMap { rank ->
+            CardSuit.entries.map { suit -> Card(rank, suit) }
+        }
+        ...
+    }
+}
+```
+
+→ **`Card.SINGLE_DECK` 의 위치 모순** — *덱 = 52장 카드 모음*은 *`CardDeck` 도메인 책임*. *`Card.SINGLE_DECK`* 은 *Card 클래스가 덱을 알고 있음*. 의도는 *invoke 팩토리 캐시*. 다만 *Card 가 자기 종류만 알고 / Deck 이 52장 구성 책임*이 자연. *`Card` companion 의 캐시*는 `Map<(rank,suit), Card>` 가 더 적합. *`CardDeck.SINGLE_DECK`* 으로 이동 + *`Card` 팩토리는 캐시 lookup*. 현재는 *순환 의존 신호* — `CardDeck` 이 `Card.SINGLE_DECK` 을 import 하고 `Card` 가 자기 자신의 모든 인스턴스를 안다.
+
+### 17. `Dealer.drawUntilFinished` — *while + score + isBust 이중 조건*
+
+```kotlin
+fun drawUntilFinished(cardDeck: CardDeck) {
+    while (hand.score() <= DEALER_DRAW_CRITERIA && !hand.isBust()) {
+        draw(cardDeck)
+    }
+}
+```
+
+→ **`hand.score() <= 16 && !hand.isBust()`**. *`isBust` 면 score == -1* 이므로 *-1 <= 16 = true*. *isBust 명시*로 *센티넬 -1 트릭이 새는 것* 방지. *Hand 가 isBust 시 score = -1* 트릭이 *호출자에 새지 않도록* *호출자가 isBust 먼저* 확인하는 *방어 코드*. *센티넬 트릭의 비용*. *Hand.canDraw(): Boolean = score < 17 && !isBust()* 면 한 줄. PR #112 의 *상태 메시지 응집* 결과와 같은 결.
+
+또한 *`DEALER_DRAW_CRITERIA = 16`* 매직 넘버를 *Dealer companion* 에 두는 게 *카지노 룰 명세 위치* 로 적절한지는 의문. *블랙잭 룰 전체*가 *Dealer companion* 에 묻혀 있으면 *룰 조회*가 *Dealer 안 봐야 함*. *Rule/BlackjackRule* 같은 *룰 객체* 로 분리도 후보.
+
+### 18. `assertAll` — *그룹 어설션 학습 질문*
+
+```kotlin
+// DealerTest.kt:60 — 추정
+@Test
+fun ...() {
+    assertEquals(...)
+    assertEquals(...)
+    assertEquals(...)
+}
+```
+
+말리빈 (DealerTest.kt:60 — 미해결): *"assertAll 로 묶는 것과 그렇지 않은 것은 어떤 차이가 있을까요?"*
+
+→ **JUnit `assertAll` = 여러 어설션 묶어 모두 실행**. *하나 실패해도 나머지 어설션도 실행*하여 *전체 실패 정보 보고*. *기본 `assertEquals` 연속*은 *첫 실패에서 멈춤* → *다른 어설션의 통과/실패 정보 손실*. *테스트 진단 가시성* 학습.
+
+### 19. *`Hand` 의 `getHandCount` / `getScore` — getXXX 명사형*
+
+```kotlin
+fun getHandCount(): Int = cards.size
+fun score(): Int { ... }
+
+// Participant
+fun getHandSize(): Int = hand.getHandCount()
+fun getScore(): Int = hand.score()
+```
+
+말리빈 (BlackjackEngine.kt:13 — 동사 시작 권고): *"메서드명은 동사로 시작하도록 작성해보세요 :)"*
+
+→ **`getXXX` 메서드명 = Java Bean 어휘**. *Kotlin은 `val handCount: Int get() = cards.size`* 같은 *property 문법*이 자연. `getXXX()` 함수형 호출은 *property로 노출* 하거나 *동사형 (`count()`, `scoreHand()`)*. *Kotlin 어휘 정착*. PR #28·#10·#119 와 같은 결 (`getXXX` 명사형 → Kotlin property 권고).
+
+또한 *`getScore()` 가 Hand 의 `score()` 를 그대로 위임*하고 *`Hand.score`는 함수 / Hand.cards 는 property* 로 *어휘 불일치*. *통일* 필요.
+
+## 리뷰어 의견 요지
+
+- **invoke 팩토리 + class 생성자 = 호출 모호** — `Card(rank, suit)`가 어느 쪽인지 *바이트코드 안 보면 모름*. *private constructor + companion factory* 가 정공.
+- **딜러는 왜 이름을 안 가지는가? = 변경 취약성 + 코드 탐색 위치** — 학생의 4 옵션 자가 토론에 대해 말리빈이 *"딜러 이름이 김딜러씨로 바뀌면 어떤게 가장 변경점에 취약? 이름은 어디에 있어야 자연? 다른 개발자가 딜러 이름을 어디서 찾을까?"* 메타 질문으로 *학생 자가 결론*  유도. *객체의 이름은 객체 안에* — *코드 탐색 위치 = 의미 위치*.
+- **카드 부족 = 게임 종료는 비현실** — *카지노 = 무한 게임 가능*. *6덱이 다 떨어져도 새 카드 가져옴*. 학생의 *"6덱 + 8명이면 카드 모자라는 게 논리 오류"* 멘탈을 *"카지노 = 6시간 게임"* 으로 전환.
+- **abstract = "고장 난 부분 채우라"** — *abstract method 0* 인 *Participant* 는 *abstract 키워드 의미 모호*. *open class + sealed class + interface property* 중 의도에 맞는 것 선택. *`abstract class` ≠ "추상 개념 표현"*.
+- **싱글톤 Deck = 테스트 불가** — `object` 또는 *멤버 직접 생성*이 *순서 고정 카드 시퀀스 주입 불가*. *전략 패턴 + 생성자 주입* 으로 *셔플 추상화* (시아가 1단계 안에 자가 반영).
+- **점수 직접 비교 = 블랙잭 룰 무지** — *21 초과 패배*, *2장 21 = 블랙잭*, *Bust 양측 무조건 패배* 모두 *점수 크기 비교*로 안 잡힘. *도메인 룰 학습 → 코드 반영*.
+- **메시지 던지기 ≠ object 분리** — 학생이 *함수를 object로 옮긴 것*을 *"메시지 던지기"*라 자가 칭찬했지만 *진짜 메시지*는 *`participant.compete(other)`*. *`CalculateResult.getResult(a, b)` = 정적 헬퍼 = Ask*.
+- **Inferred Type 리턴 = API 안전성 손상** — *외부 API*에서 *반환 타입 추론*은 *호출자가 타입 추론 어려움*. *Effective Kotlin Item 4·14*.
+- **Kotlin stdlib 우선 = 멀티플랫폼 이식성** — *Java import*는 *JVM 결합*. *Kotlin은 JVM 외 플랫폼*도 타겟.
+- **getXXX 명사형 → Kotlin property** — *Java Bean 어휘*를 *Kotlin property*로 정착.
+- **반환 Int 의미 부재 = 콘솔 영향 흔적** — *몇 장 뽑았는지 Int 반환*은 *콘솔 출력용 카운터*. *도메인 메시지가 아닌 출력 카운터*는 *도메인에 누수*.
+- **메서드명 길어도 의미 = 짧은 모호함 > 긴 명확함** — 말리빈 자가 예시: *`ObserveMyPermissionChangesOnSocketReconnectionUseCase`*.
+
+## 대표 인용
+
+**말리빈 (abstract = "고장 난 부분", Participant.kt:5):**
+> 생성자 로직을 포함할 수 없는 것은 공감이돼요.
+> 그런데 참가자가 모두 자신의 핸드를 가지고 있기 때문에 한계가 명확한 것은 공감이 되지 않아요.
+> 인터페이스에서 hand를 반드시 구현해야한다는 것을 명시하면 모두 Hand를 가지게 만들 수 있으니까요.
+>
+> abstract class는 고장 난 부분은 당신이 채워 넣으라 라는 의미에 가깝다고 생각해요.
+> 그런데 여기에는 abstract할 게 하나도 없으니, abstract를 사용할 이유가 없다고 생각해요.
+
+**말리빈 (메시지 던지기, WinningResult.kt):**
+> 객체의 값을 직접 꺼내 비교하기보다, 객체에게 메시지를 던져보는 건 어떨까요?
+> 그러다보면 이 점수 계산 로직이 어떠한 객체로 응집시킬 수 있어보이네요.
+
+**말리빈 (이름은 어디에, Dealer.kt):**
+> 딜러의 이름이 "김딜러씨"로 바뀌게 된다면 어떤게 가장 변경점에 취약할까요?
+> 또 이름은 어디에 가지고 있어야 가장 자연스러울까요?
+> 다른 개발자들이 딜러의 이름을 찾을 때 어떤 파일에 가서 찾아볼 것 같으신가요?
+
+**말리빈 (카지노 = 무한 게임, CardDeck.kt):**
+> 글쎄요.. 현실 세계에서도, 실제로 게임을 온라인으로 즐길 플레이어도,
+> 몇 시간을 앉아서 게임하는 것은 흔히 볼 수 있는 광경이라 생각해요.
+> 한 라운드가 돌았다 해서 항상 새 카드를 뜯어 쓰는 것도 아니구요.
+>
+> 카지노에서 덱 6벌이 사라졌으니, 카지노 문 닫고 손님들을 모두 쫓아내지 않는 것 처럼,
+> 게임이 강제 종료되는 것은 문제라고 생각해요.
+
+**말리빈 (invoke vs constructor 모호, Card.kt:18):**
+> 이것은 생성자로 호출한 것인지 invoke 함수를 호출한 것인지 저도 모르겠는데요?
+> Java의 바이트코드를 뜯어보지 않는 이상 어떤 것을 호출했는지 알기가 매우 어려워요.
+> 생성자를 호출하는 케이스가 된다면, 중복된 값을 가지는 인스턴스를 생성할 수 있는 단점이 여전히 있겠어요.
+
+**말리빈 (느슨한 결합, Controller):**
+> 뷰와 모델을 결합하라는 의미가 아니에요.
+> 느슨한 결합이라는 단어에 무언가 관점을 돌리기 어려워진 것 같네요.
+> 결국 값을 전달한다는 것은 어떤 연결로 결합되어있기에 가능한것이겠지요.
+> 이 결합은 완전히 서로를 아는 강한 결합일 수도 있고, 서로를 모른채 어떤 값을 주고 받을 수는 있는 약한 결합이 있을 수도 있겠지요.
+> 도메인에서 필요한 값을 interface 혹은 람다 등으로 가져올 수 있도록 만들어보세요.
+> **컨트롤러라는 이름 때문에 게임을 컨트롤 하는 기능을 컨트롤러에서 해야한다고 생각하는 건 아닐까 하는 생각도 문득 드네요.**
+
+**말리빈 (긴 이름이 모호한 이름보다 낫다):**
+> 이름이 길어지는 건 그게 무엇인지 알 길이 없어지는 것 보다 훨씬 낫다고 생각해요.
+> 대충 회사에서 쓰고 있는 긴 변수명을 찾아보니 `ObserveMyPermissionChangesOnSocketReconnectionUseCase` 이런 것도 있네요.
+
+**학생 자가 답변 (블랙잭 룰 자가 학습, WinningResult.kt):**
+> 블랙잭 게임이 왜 블랙잭인가 했는데, 2장만으로 21점이 나오면 블랙잭이라 하는 걸 알게 되었습니다. 해당 사항에 맞게 수정하였습니다.
+
+**학생 자가 답변 (딜러 이름 위치, Dealer.kt):**
+> 이름이 없는 경우 딜러라고 출력하는 것이 더 여러 곳을 손보게 되겠네요.
+> 거기에 개발자들도 객체의 이름을 객체 안에서 찾으려 할테니, 딜러의 이름은 딜러가 가지고 있는게 맞을 것 같습니다!
+
+**학생 자가 답변 (object 분리를 메시지로 오해, CalculateResult.kt):**
+> 로직을 분리하여 object로 만들었습니다! 메세지를 던지니 훨씬 더 객체끼리의 결합이 사는 듯 한 느낌이 드네요.
+
+**학생 자가 답변 (Effective Kotlin 정리 후 자가 의문, BlackjackEngine.kt):**
+> 먼저 생각한 것 -> 리턴타입을 명시하면 확실하게 리턴 타입이 보장되고, = 를 사용해서 리턴하면 코드 길이가 짧아지고 유연하게 작성할 수 있다.
+> 책을 읽고 정리한 것 -> 외부 API에서 Inferred Type로 리턴하게 되면, API의 안전이 보장되지 않고, 개발자가 타입을 쉽게 추론할 수 없게 된다. 또한 명확하지 않은 변수 타입은 코드 가독성을 떨어트려 효율을 저하시킨다.
+> 생각보다 리턴 타입이 보장되는 것이 정말 중요하네요, 코드를 짜면서 다른 개발자가 사용하는 경우를 거의 생각하지 않고 짜다 보니, 내가 알고 있으면 상관 없다고 생각했는데, API의 안전에도 영향을 끼칠 수 있다는 것을 알게 되었습니다.
+
+## 얻은 교훈
+
+1. ***`abstract class` 는 "추상 개념 표현 도구"가 아니라 "abstract method 채우기 강제 도구"***. *abstract method 0 + open property 0* 인 클래스에 *`abstract` 키워드*는 *의미 부재*. *인스턴스화 막기 = `sealed class` 또는 protected constructor*, *공통 상태/메서드 공유 = open class*, *공통 메서드 시그니처 강제 = interface*. *학생의 "abstract = 추상 개념 표현"* 사고가 *`abstract` 의 의미를 키워드 이름의 일상어 의미*로 해석한 결과. PR #28·#135·#114·#125 와 같은 결.
+
+2. ***메시지 던지기 = `participant.compete(other)`, 정적 헬퍼 분리가 아님***. 학생의 *"로직을 object로 분리 = 메시지 던지기"* 오해는 *`object` 가 싱글톤 = 정적 헬퍼 = Ask 패턴* 이라는 점을 놓침. *진짜 메시지* 는 *행위 주체에게 묻고 그 결과를 받음*. *Tell-Don't-Ask 의 핵심 = 호출자가 분기 안 만듦*.
+
+3. ***Java Bean 어휘 (`getXXX`/`setXXX`) → Kotlin property***. *`getHandCount()`* / *`getScore()`* 같은 *Java getter 형태*는 *Kotlin property* 로 정착. `val handSize: Int get() = hand.cards.size` 같은 *property 문법*이 *Kotlin 어휘*. *함수 vs property* 의 분기 기준: *부수효과 / 계산 비용 / 매번 다른 값* 이면 함수, *아니면 property*. PR #28·#10·#119 와 같은 결.
+
+4. ***카지노 = 무한 게임 메타포***. *카드 부족 → 게임 종료* 는 *현실 카지노 metaphor* 와 충돌. *6덱 다 떨어지면 새 6덱* 이 *현실*. 학생이 *"논리 오류"* 라 한 판단을 *말리빈이 "현실 = 6시간 게임"* 메타포로 전환. *현실 metaphor 자체*가 *코드 invariant 결정 기준*. PR #29·#34·#51 와 같은 결 (*현실 메타포 정합* 후속 학습).
+
+5. ***`invoke` 팩토리 + `public class` = 호출 모호. 팩토리 정공은 `private constructor` + `companion object fun of(...)`***. *Kotlin operator fun invoke 의 함정* — *같은 시그니처의 생성자가 우선*. *팩토리 메서드 패턴* 의 안전한 표현은 *생성자 private + 명명된 팩토리 함수*. PR #28·#125 와 같은 결.
+
+6. ***`firstCard` 멤버 보유 = 초기 상태와 현재 상태를 두 변수로 보관 = 시간 일관성 깨짐***. *생성자 인자만 받고 잊어버림*이 자연. *Dealer.getAdditionalDrawCount = hand.size - firstCard.size* 같은 *시간 비교*는 *출력용 카운터*이지 *도메인 메시지 아님*. 말리빈의 *"콘솔의 영향으로 이렇게 구성했다는 느낌이 강하게 드네요"* 진단이 *출력 위주 사고*의 도메인 누수 진단.
+
+7. ***메서드명은 동사로 시작 + Kotlin 어휘***. `playerDraw(player)` / `dealerDraw(dealer)` 는 *명사+동사 합성*. `drawForPlayer(player)` / *Player 자신이 draw* 가 자연. *어휘 일관성*.
+
+8. ***긴 이름이 모호한 이름보다 낫다***. 말리빈의 *`ObserveMyPermissionChangesOnSocketReconnectionUseCase`* 예시가 *극단적이지만 원칙*. *짧고 모호한 메서드명*보다 *길고 명확한 메서드명*. *IDE 자동완성 시대*에 *입력 비용은 0*. *읽는 비용은 매번*.
+
+9. ***Bust 점수를 센티넬(-1) + maxOf 트릭 < Ace 1 기본 + 단일 +10***. *학생의 트릭 (`baseScore.formatIfBust()` + `maxScoreWithAce(...).formatIfBust()` + `maxOf`)* 는 *작동은 함* 이지만 *복잡도 ↑ + isBust invariant 가 score==-1 에 묶임 + 호출자가 isBust 먼저 확인 강제*. *Ace 1 기본 + sum 계산 + Ace 있고 sum+10≤21 이면 +10* 패턴이 *한 줄*. PR #128·#135·#114·#125·#124 와 같은 결 (Ace 안티패턴 변형).
+
+10. ***Kotlin Multiplatform 관점 = Java import 자제***. *`java.util.Random` / `Collections.shuffle`* 같은 *Java 의존성*은 *Kotlin/JS, Kotlin/Native 이식 시 충돌*. *Kotlin stdlib (`shuffled()`, `random()`)* 이 *멀티플랫폼 안전*. *프로젝트가 JVM 한정*이라도 *습관*이 *향후 멀티플랫폼 도입 시 비용 절감*.
+
+11. ***학생의 *자가 의문 → 자가 답변 → 후속 자가 의문* 패턴이 학습 모범***. 시아의 *Effective Kotlin Item 4/14 → 본인 정리 → 자가 답변 → "Unit 타입은 어떻게?" 자가 의문 → 말리빈 보강* 흐름은 *수동적 적용*이 아니라 *능동적 학습*. *책 정리 시점에 자가 의문*이 *외부 학습 자료 활용의 정공*. PR #128·#135·#111·#120·#124 와 같은 결.
+
+12. ***결과 집계는 한 곳 — `Match/Game` 객체나 `GameResults` 일급 컬렉션***. *Dealer.getWinDrawLossResult(players)* + *Players.results(dealer)* 처럼 *결과 집계가 두 곳에 분산*하면 *두 결과의 일관성*을 *암묵적 invariant*로 보장해야 함. *한 객체가 매치를 진행하고 결과를 분배*가 자연.
+
+13. ***Engine 도입 자체는 좋으나 god-object 완전 해소가 아닐 수 있다***. *시아의 `BlackjackEngine`* 은 *Controller god-object* 의 일부 해소. 다만 *`cardDeck = CardDeck()` 멤버 직접 생성 + `playerDraw(player)`/`dealerDraw(dealer)` wrapper + Engine이 모든 진행을 흡수*. *Engine 자체가 god-object 의 이전된 형태*가 될 위험. *각 객체가 자기 책임* 흐름이 *Engine 거치는 wrapper*보다 메시지 패턴에 맞음. PR #112·#28 (BlackjackGame god-object) 와 같은 결.
+
+14. ***`Boolean` 반환 메시지 (`isBust`) 는 자기 점수 의미를 노출하지 않아야***. *`Hand.score()` 가 Bust 시 -1 반환* + *`isBust()` 가 score==-1 비교* 는 *Hand 내부 의미 (-1 센티넬) 가 호출자에 새는 함정*. *호출자가 `score()` 만 부르면 잘못된 정수*. *함수 분리* 면 *호출자가 안전*: `Hand.canCalculate(): Boolean` / `Hand.scoreOrNull(): Int?` / *throw + isBust* 등 다양.
+
+15. ***학생 자가 답변에 커밋 SHA 첨부 = 학습 가시화 모범 (Reviewer 친화)***. Leeyerin0210 이 *모든 후속 반영에 커밋 SHA*를 명시 (`141938f`, `a821755`, `29e4a32`, `0a2ae58`, `f62c66c`, `85b84de`, `558a794`, `fdc34e7`, `396235f`, `a94d03f`, `2fac65c`, `dfced9a`, `011cfff`, `13e5774` 등) → *말리빈이 "어디서 반영됐는지"* 즉시 확인 가능. PR #124 (모찌) 와 같은 결 (학생 자가 답변 + 커밋 SHA 첨부 패턴).