oh-my-oop 0.2.0

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

@@ -0,0 +1,269 @@
+# PR #135 — [블랙잭 2단계] 화이팅 미션
+
+- **Reviewee:** [@ijh1298](https://github.com/ijh1298)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/135
+- **단계:** 2단계 (베팅 추가 — 수익률 계산, 블랙잭 1.5배 규칙)
+- **리뷰어:** @krrong (크롱)
+- **라인 코멘트:** 30 (리뷰어 13 / 리뷰이 17)
+
+## 잘한 점 (설계 관점)
+
+- **`Card.standardCards: Map<Pair<CardNumber, Suit>, Card>` Flyweight** — *(13×4 = 52)* 인스턴스만 공유. `Card.of(cn, suit)` 팩토리.
+- **`BetAmount` 원시값 포장** — 베팅 금액의 invariant 분리.
+- **`PlayerBetInfo(player, betAmount)` 묶음 객체** — *세 변수 이상 클래스 회피* 요구사항 대응.
+- **`drawSafely + Deck.refill()` 빈 덱 복구 패턴 (후속)** — null 반환 → refill → 재시도. (못한 점 §1 참고.)
+- **`Hand.isBlackJack()` *2장 + 21점*으로 명시 분리** — *점수 동률 = 무승부 오판* (PR #128) 수정.
+- **`Casino` Controller 명명** — *블랙잭 게임을 진행하는 장소* 도메인 비유.
+- **후속 반영 — `Scoreboard`에서 *수익 계산*만 `BetRecords`로 이전 + `Dealer.profit = -sum(players.profit)` 단순화 + Elvis 연산자**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Deck.refill()` 자동 채움 vs 명시 신호
+
+```kotlin
+// Before
+fun pop() = if (cards.isEmpty()) { refill(); cards.removeFirst() } else cards.removeFirst()
+
+// After (학생 후속)
+private fun drawSafely(number: Int, deck: Deck): List<Card> {
+    val drawnDeck = deck.pop(number)
+    if (drawnDeck == null) {
+        deck.refill()
+        return drawSafely(number, deck)
+    }
+    return drawnDeck
+}
+```
+
+리뷰어 (PR #128 시점): "*덱이 비어있으면 덱을 스스로 채우고 있는데요. 이를 사용하는 동료 개발자가 이를 예상할 수 있을까요?* 🤔"
+학생 후속: "컨트롤러에서 카드를 꺼내오고, *null이 반환되었다면 카드에게 refill을 해달라는 메시지*를 던진 후에 다시 카드를 꺼내올 수 있도록 메서드를 추가" 
+리뷰어 평가: "*처음 의견은 덱을 채우지 않아도 괜찮다였는데, 이런 방식도 새롭고 좋네요* 😊" — *컨트롤러가 refill 시점을 명시*. 다만 *재귀 호출*은 *덱이 항상 채워질 수 있다*는 가정에 의존.
+
+### 2. `Casino` Controller의 모든 변수에 *명시 타입 선언* — 과잉 명시
+
+```kotlin
+fun run() {
+    val deck: Deck = Deck(cardsGenerator)
+    val participants: Participants = Participants(Dealer(), setPlayers())
+    val playerBetInfos: List<PlayerBetInfo> = setPlayerBetInfos(participants.players)
+    ...
+}
+```
+
+리뷰어: "*nit: 자료형을 명시해주는 이유가 있나요?* (https://github.com/woowacourse/kotlin-blackjack/pull/128#discussion_r1989251469 *2트째*)"
+
+학생 자가 변호: "원래는 해당 습관이 없었지만 *레벨1 제이슨의 수업을 계속해서 들으면서 자료형을 명시하는 게 더 이해가 쉽다고 생각*했습니다. 제가 작성한 코드더라도 *시간이 지난 후 읽으면 이 변수의 자료형이 무엇인지 쉽게 짐작하기 어려울 때*가 있고 [...] 제 기준은 *모든 자료형을 다 남기는 것*입니다!"
+
+→ *모든 변수 타입 명시*는 Kotlin 관례와 어긋남. `val deck = Deck(cardsGenerator)`는 *우변이 타입 자명*. *명시가 도움 되는 경우*(예: 인터페이스 반환의 *상위 추상*으로 다루고 싶을 때)가 아니면 *과잉*. *읽기 수월함*은 *변수명 + 우변*으로도 충분.
+
+### 3. `Player.play()` / `Dealer.play()` Controller로 회수 — 학생 자가 토론
+
+```kotlin
+// PR #128 (1단계)
+fun play(deck: Deck, onResponse: (String) -> Boolean, displayCards: (Player) -> Unit) {
+    while (isDrawable()) {
+        if (!onResponse(name)) { displayCards(this); break }
+        drawCard(deck)
+        displayCards(this)
+    }
+}
+// PR #135 — 제거 후 Controller로 이동
+```
+
+학생 자가 인정: "play 메서드를 컨트롤러로부터 이전했던 이유는 *Player가 게임을 자기 턴을 진행하는 게 능동적*이라는 생각했기 때문이었습니다. 이전하고 나니 제가 생각하는 play 메서드는 다음과 같은 단점이 생겼습니다. 😅 - *테스트하기 어렵다*. - *모델에게 view를 호출하는 메서드를 고차함수로 넘기는 찝찝함*. - *메서드가 단일 책임을 가지고 있지 않음*. 따라서, 차라리 *모델의 흐름을 제어할 수 있는 컨트롤러에서 적절한 순서로 메서드를 호출*하는 게 적합하다는 판단을 했습니다."
+
+리뷰어: "*플레이어 혹은 딜러가 자기 턴을 진행하는 것은 능동적인 것이 맞습니다. 현실 세계에서는요. 하지만 객체지향의 세계에서도 능동적인 것이 맞을지 혹은 다른 객체들과의 협력을 통해 할 수는 없는지 와 같은 부분들을 앞으로도 고민*해보면 좋을 것 같습니다." — *현실 비유로 자율성*은 *반쪽*. *객체지향 자율성*은 *결정 책임이 자기에게 있느냐*. `play()`에 *입력 callback*과 *출력 callback*이 들어오면 *결정은 외부*. → 자율성 흉내만. *Controller로 회수*가 옳은 선택. 학생도 자가 정리.
+
+### 4. `Hand.cards: deepCopy()` 방어적 복사 변경 — 백킹 프로퍼티 사용 미숙
+
+```kotlin
+// Before
+class Hand {
+    private var _cards = mutableListOf<Card>()
+    private val cards get() = _cards.toList()
+}
+// After (학생 후속 시도)
+class Hand {
+    private var _cards = listOf<Card>()       // ⚠ List는 이미 불변
+    private val cards get() = _cards.deepCopy()
+}
+```
+
+리뷰어: "*backing property를 어떻게 사용하는지 한번 더 확인해보면 좋겠습니다.* 또한, *방어적 복사를 위해 이렇게 수정한 이유가 무엇일까요?* 이전 방법과는 어떻게 다른지 알려주세요"
+
+학생 자가 인정: "*backing property를 적용한 이유는 외부에서 cards 리스트를 수정하지 않게 하고 싶어서였습니다!* 그런데 *이미 둘 다 private으로 선언해두고 있는 실수* 때문에 *제대로 그 효과를 얻지 못한* 것 같습니다😓 [...] *deepCopy를 통해서 외부에 보여주는 hand의 cards는 새로운 카드 객체가 생성되고 있어서 캐싱해놓은 이점이 사라지지 않는 것 아닐까* 하는 생각이 듭니다.."
+
+→ 백킹 프로퍼티의 정석은 `private val _cards: MutableList<Card>` + `val cards: List<Card> get() = _cards`. *외부에 List 인터페이스만 노출* → 불변 view. `deepCopy()`는 *Card 자체가 불변*이면 *불필요한 비용*. `Card`가 Flyweight (52장 캐싱)인데 *deepCopy*로 새 인스턴스 생성하면 *Flyweight 이점 무효화*. 학생도 자가 의문.
+
+### 5. `Hand.isBlackJack()` + `isNotBlackJack()` 둘 다 — 부정형 함수의 *역설*
+
+```kotlin
+fun isBlackJack(): Boolean = cards.size == 2 && getScore() == BLACK_JACK_NUMBER
+fun isNotBlackJack(): Boolean = !isBlackJack()
+```
+
+리뷰어: "*블랙잭인가 블랙잭이 아닌가를 나눌 이유가 있나요?* 🤔"
+
+학생 자가 변호: "코틀린 역시 `isBlank()`, `isNotBlank()` 메서드를 따로 지원하기도 하고, `!opponent.hand.isBlackJack()`처럼 *긴 코드는 not 연산자를 보지 못하고 지나칠 수 있다*고 생각했습니다."
+
+→ Kotlin stdlib `isBlank`/`isNotBlank`는 *고빈도 + 사용 측이 명확히 읽기 위한* 예외. *도메인 객체*에 *둘 다 노출*하면 *호출 측 선택*이 증가하고 *부정 의미 함수 명*가 *컬렉션처럼* 늘어남. 한 가지로 통일하고 호출 측 `!isBlackJack()`이 더 적은 책임.
+
+### 6. `Participant.drawCard(cards: List<Card>)` + `cards.forEach(hand::add)` — 메서드 참조 사용
+
+```kotlin
+fun drawCard(cards: List<Card>) {
+    cards.forEach(hand::add)
+}
+```
+
+리뷰어: "*일반 함수에 비해 메서드 참조가 갖는 장점은 무엇인지 찾아보시고 위 코드에서 메서드 참조를 통해 넘겨야 하는 이유를 설명해주세요.*"
+
+학생 자가 변호: "메서드 참조를 사용한 이유는 *수업에서 함수형 프로그래밍에 대해 배웠고 적용해볼겸 사용*했습니다. drawCard 메서드에 적용하는 메서드 참조는 비교적 간단해서 *굳이 적용할 필요가 없어 보이기도 하지만*, 람다 식이 복잡해지면 *참조를 이용해서 간결하게 적을 수 있다*는 장점이 있을 듯 합니다!" — *기능 사용 욕구*가 *적용 정당화*. `cards.forEach { hand.add(it) }`도 동일. *메서드 참조의 가치*는 *재사용성 + 람다 본문 노이즈 제거*이지 *수업 적용*이 아님. (PR #65 callback 폭증과 같은 결.)
+
+### 7. `Participants(dealer, players)` vs `List<Participant>` — 학생 자가 토론
+
+```kotlin
+class Participants(val dealer: Dealer, val players: List<Player>)
+```
+
+리뷰어: "`Dealer`와 `Player`모두 `Participant`를 상속받고 있기 때문에 `List<Participant>`로 묶어줄 수 있고, *이 점을 알고 있던 것처럼 보입니다. 코드가 변경된 이유가 무엇인가요?*"
+
+학생 자가 변호: "*메서드에 넘기는 인자의 수를 줄이기 위해 딜러와 플레이어의 조합인 Participants 객체를 만들었습니다.* 또한 `List<Participants>`를 사용하면 *Dealer, List<Player>를 분리하는 로직이 (가능은 하겠지만) 직관적이지 못할 듯해서* Participants 클래스를 만들어 사용했습니다. [...] 다만 *역할과 책임이 없고 단순히 프로퍼티를 감싸기 위한 객체*를 생성하고 있다는 생각이 들었습니다. 😅 *이 방식은 객체를 적절하게 사용하고 있지 않은 걸까요..?*"
+
+→ PR #63 (jinuemong)의 *Participants 첫 0번 = Dealer invariant* 문제를 *타입 분리*로 해결. 그러나 *프로퍼티 묶음만*이라 *역할*이 없음. *initialCardsDistribute / runPlayersDrawPhase* 같은 *공통 작업*을 `Participants` 메서드로 끌어오면 *Tell-Don't-Ask*. 학생이 자가 의문 인식.
+
+### 8. `PlayerBetInfo(player, betAmount)` — *세 변수 회피* 요구사항이 만든 분리
+
+```kotlin
+class PlayerBetInfo(private val player: Player, private val betAmount: BetAmount) { ... }
+```
+
+학생 자가 인정: "*인스턴스 변수가 세 개 이상인 클래스를 사용하지 마라는 요구사항에 의해* 이 객체를 생성하게 되었습니다. BetAmount 객체를 만들 때, *플레이어가 베팅 금액을 들고 있는게 제일 적절*하다고 생각했습니다! 다만 *Player가 name, hand를 이미 지니고 있어 betAmount의 프로퍼티를 추가하게 되면 요구사항을 어기게 되었습니다*.😓 따라서 *플레이어와 그 사람의 베팅 정보를 지니고 있는 객체*를 만들어서 이 객체가 *수익금을 구하는 역할*을 지니게 했습니다."
+
+리뷰어: "*커밋 기록을 보니 베팅금액의 위치가 바뀌었던데 이유가 무엇인가요?* *플레이어 개인의 베팅금액은 스스로가 가지고 있는게 좋지 않을까요?*"
+
+→ **형식 규칙(*변수 3개 이하*)이 도메인 모델을 왜곡한 신호**. *PlayerBetInfo*는 *요구사항 회피용 인공물*. *Player가 betAmount를 갖는 자연 표현*이 *형식 규칙*에 의해 *분리*. 형식 규칙은 *코드를 단순화하는 도구*인데 *목적이 도구 자체*가 되면 안 됨. PR #63의 `BlackJack` 객체 / PR #128의 `Rule` 객체와 같은 결.
+
+### 9. `Scoreboard`가 *결과 + 수익* 둘 다 — 책임 비대
+
+```kotlin
+class Scoreboard(private val participants: Participants) {
+    fun getDealerProfit(playerBetInfos: List<PlayerBetInfo>): Double {
+        val playersProfit: Collection<Double> = getPlayersProfit(playerBetInfos).values
+        return -playersProfit.filter { it < 0.0 }.sum() - playersProfit.filter { it > 0.0 }.sum()
+    }
+    fun getPlayersProfit(...): Map<Player, Double> { ... }
+    fun getResults(): Map<Player, GameResult> { ... }
+    ...
+}
+```
+
+리뷰어: "*현재 구현한 `Scoreboard`는 게임 결과를 가져오는 것 외에도 많은 일을 하고 있습니다.* 그렇다면 *우리는 이제 뭔가 해야겠죠?*" / "*현재 구현에서는 플레이어의 수익을 통해 딜러의 수익을 쉽게 구할 수 있는 것처럼 보이네요.*" — *결과 조회*(승/패/무) + *수익 계산*(원금 × 배수) 두 책임. 학생 후속: *수익 계산*만 `BetRecords`로 이전 + `dealerProfit = -sum(playersProfit)` 단순화 (PR #112와 같은 *역집계* 패턴).
+
+### 10. `Dealer.showFirstCard()` + `Player.showCards(): List<Card>` — *공개 카드 수*가 도메인 룰
+
+```kotlin
+class Dealer : Participant {
+    fun showFirstCard(): Card = hand.toList().first()
+}
+class Player : Participant {
+    // showCards는 모든 카드 공개
+}
+```
+
+리뷰어: "*카드를 처음으로 공개할 때 딜러는 1장을, 플레이어는 2장을 공개하는데, 이는 비즈니스 로직으로 볼 수 있지 않을까요?* 즉, *우리가 만든 참가자 아래에서 딜러와 플레이어가 각각 어떻게 다른 구현을 갖도록 만들어 볼* 수 있을 것 같아요." — `Participant.showInitialCards()` 추상 메서드 + Dealer는 1장, Player는 2장 *Liskov 호환 구현*. 도메인 룰을 *Participant 추상화 아래*로. 학생 후속 시도: "*다음과 같이 수정해봤는데 크롱의 피드백의 의도에 맞는지 정확히 모르겠습니다..*"
+
+### 11. `Player.compareTo`에 *블랙잭 우선 + Bust 우선* 순서 분기
+
+```kotlin
+override fun compareTo(opponent: Participant): GameResult {
+    return when {
+        hand.isBlackJack() && opponent.hand.isNotBlackJack() -> GameResult.BLACKJACK_WIN
+        hand.isBlackJack() && opponent.hand.isBlackJack() -> GameResult.DRAW
+        hand.isBust() -> GameResult.LOSE
+        opponent.hand.isBust() -> GameResult.WIN
+        myScore > opponentScore -> GameResult.WIN
+        myScore == opponentScore -> GameResult.DRAW
+        else -> GameResult.LOSE
+    }
+}
+```
+
+학생 자가 토론: "*같은 21점으로 무승부인 경우에도 블랙잭인 사람이 이기는 조건을 고려*했습니다!" — *블랙잭 룰* 충실. PR #128에서 *점수 동률 = 무승부* 오판한 결을 수정. *순서 의존 when* 분기 — *블랙잭 ↗ Bust ↗ 점수 비교*. 가독성은 그럭저럭이나 *룰 = 코드 분기 순서*가 *암묵 invariant*. 별도 *룰 객체*로 표현 가능하지만 *과잉*. 현 상태도 합리적.
+
+### 12. `setBetAmount` 재시도 — *재귀로 invariant 보호*
+
+```kotlin
+private fun setBetAmount(playerName: String): BetAmount {
+    val input: Double = inputView.readBetAmount(playerName)
+    return runCatching { BetAmount(input) }.getOrElse { setBetAmount(playerName) }
+}
+```
+
+`runCatching + getOrElse + 재귀`. *예외 → 재시도*가 모범 패턴이지만 *재귀 깊이*가 *사용자 오타 횟수*에 의존. *while 루프*가 *Stack overflow 보호 + 의도 명시*. PR #65 (kmkim2689)의 `runCatching` 폭증과 같은 결.
+
+### 13. `Card.standardCards` Map 키 — `String 연결` → `Pair<CardNumber, Suit>` 변경
+
+```kotlin
+// Before
+val standardCards: Map<String, Card> = ... .associateBy { it.cardNumber.name + it.suit.name }
+fun of(cn, suit) = standardCards[cn.name + suit.name] ?: throw ...
+
+// After (학생 후속)
+val standardCards: Map<Pair<CardNumber, Suit>, Card> = ... .associateBy { it.cardNumber to it.suit }
+fun of(cn, suit) = standardCards[cn to suit] ?: throw ...
+```
+
+학생 자가 토론: "*Pair<CardNumber, Suit>를 선택하지 않았던 이유*는 of 메서드를 호출하는 개발자 입장에서 *안의 key값이 어떻게 구성되어 있는지 큰 관심사가 아니라 생각*했고, *객체지향에서 의미가 불분명한 Pair 사용을 지양해야 한다는 생각*이 무의식적으로 있었기 때문입니다! [...] *수정하면서도 크게 좋은 개선인지는 의아한 심정*입니다.."
+
+→ *String 연결 key*는 *충돌 가능*(예: `name = "TEN"` + `suit = ""` vs `name = "TE"` + `suit = "N"`) + *enum.name 의존*. `Pair<CardNumber, Suit>`는 *타입 안전*. 학생의 *의미 불분명 Pair 회피* 직관은 *공개 API에 노출되는 Pair*에는 맞지만 *internal Map key*는 다른 맥락. 모든 *원칙*을 *맥락 무관 적용*하면 부적합.
+
+## 리뷰어 의견 요지
+
+- ***Deck.refill() 자동은 호출자 모름 → 명시 신호 (Elvis + 재시도) 좋음***.
+- ***모든 변수 타입 명시는 과잉*** — Kotlin 추론 활용.
+- ***play() callback 폭증 = 자율성 흉내*** — Controller로 회수가 자연.
+- ***backing property 정석*** — `private val _cards: MutableList` + `val cards: List`.
+- ***`Card` Flyweight 캐싱 vs `deepCopy()` 충돌*** — 카드가 불변이면 deepCopy 불필요.
+- ***`isBlackJack` + `isNotBlackJack` 둘 다 노출 = 호출 측 선택 증가***.
+- ***메서드 참조는 재사용성/노이즈 제거 가치 있을 때*** — *수업 적용*이 정당화 X.
+- ***`Participants(dealer, players)`는 프로퍼티 묶음 X, 공통 작업 메서드 보유*** — Tell-Don't-Ask.
+- ***형식 규칙(변수 3개 이하)이 도메인 모델 왜곡*** — `PlayerBetInfo`는 인공물 신호.
+- ***Scoreboard 책임 분리*** — 결과 조회 / 수익 계산.
+- ***Dealer 1장 vs Player 2장 공개 = 비즈니스 룰 = Participant 추상 메서드***.
+- ***`runCatching + 재귀`보다 `while` 루프*** — Stack overflow 보호.
+- ***Map key는 Pair가 타입 안전*** — *Pair 회피*는 *공개 API* 맥락 한정.
+
+## 대표 인용
+
+> 플레이어 혹은 딜러가 자기 턴을 진행하는 것은 능동적인 것이 맞습니다. 현실 세계에서는요. *하지만 객체지향의 세계에서도 능동적인 것이 맞을지* 혹은 *다른 객체들과의 협력을 통해 할 수는 없는지* 와 같은 부분들을 앞으로도 고민해보면 좋을 것 같습니다.
+> — @krrong on `Player.kt`
+
+> 카드를 처음으로 공개할 때 *딜러는 1장을, 플레이어는 2장을 공개*하는데, 이는 비즈니스 로직으로 볼 수 있지 않을까요?
+> — @krrong on `Dealer.kt`
+
+> 커밋 기록을 보니 *베팅금액의 위치가 바뀌었던데* 이유가 무엇인가요? *플레이어 개인의 베팅금액은 스스로가 가지고 있는게 좋지 않을까요?*
+> — @krrong on `PlayerBetInfo.kt`
+
+> 일반 함수에 비해 *메서드 참조가 갖는 장점은 무엇인지 찾아보시고 위 코드에서 메서드 참조를 통해 넘겨야 하는 이유*를 설명해주세요.
+> — @krrong on `Participant.kt`
+
+> 현재 구현에서는 *플레이어의 수익을 통해 딜러의 수익을 쉽게 구할 수 있는 것*처럼 보이네요.
+> — @krrong on `Scoreboard.kt`
+
+## 얻은 교훈
+
+- ***Deck 자동 refill은 호출자 모름 = 의외 동작*** — Elvis/null 반환 + 호출자 재시도가 *명시 신호*.
+- ***모든 변수 타입 명시 = 과잉*** — Kotlin은 *추론*이 기본. *명시*는 *상위 추상 강제*나 *컴파일 오류 회피* 같은 *목적이 있을 때만*.
+- ***`play()`에 입력/출력 callback이 들어오면 *자율성 흉내*가 됨*** — 결정 주체가 외부면 자율성은 *현실 비유*에만 머무름. *Controller로 회수*가 객체지향 자율성 정의에 충실.
+- ***Backing property 정석*** — `private val _cards: MutableList<Card>` + `val cards: List<Card> get() = _cards`. *둘 다 private*은 *백킹 의미 무효*.
+- ***`Card` Flyweight + deepCopy 충돌*** — *Flyweight = 카드 불변*. *deepCopy로 새 인스턴스*는 *캐싱 이점 무효화*. 객체가 *불변*이면 *그냥 노출*해도 안전.
+- ***`isBlackJack` + `isNotBlackJack` 둘 다 = 호출 측 선택 증가*** — `isBlank`/`isNotBlank` 같은 stdlib 예외는 *고빈도 + 가독성 ↑*. 도메인 객체에는 한 가지로.
+- ***메서드 참조의 가치 = 재사용성 + 람다 본문 노이즈 제거*** — *수업 적용*은 정당화가 못 됨.
+- ***`Participants(dealer, players)`가 프로퍼티 묶음만이면 단순 record*** — `initialCardsDistribute` 같은 공통 작업을 메서드로 끌어오면 Tell-Don't-Ask. 학생 자가 의문 인식 신호.
+- ***형식 규칙(변수 3개 이하)이 도메인 모델을 왜곡한 신호 = 인공 객체 등장*** — `PlayerBetInfo`는 `Player.betAmount`의 *형식 회피용*. *형식은 코드 단순화 도구*. *목적이 도구 자체*가 되면 안 됨. PR #63 `BlackJack` 객체와 같은 결.
+- ***책임 분리 = 새 객체 + 역집계*** — Scoreboard에서 *수익 계산*만 `BetRecords`로 + `dealerProfit = -sum(playersProfit)` 역집계. PR #112와 같은 패턴.
+- ***Dealer 1장 vs Player 2장 공개 = 비즈니스 룰*** — `Participant.showInitialCards()` 추상 메서드 Liskov 호환.
+- ***`runCatching + 재귀` < `while + try-catch`*** — Stack overflow 보호 + 의도 명시.
+- ***Pair 회피 직관은 공개 API 맥락에서*** — *internal Map key*에는 Pair가 *타입 안전*. *모든 원칙을 맥락 무관 적용* 위험.
+- ***학생이 자가 의문을 명시*하는 PR은 리뷰가 깊어짐** — PR #135처럼 학생이 *내가 한 결정의 단점*을 먼저 쓰면 *리뷰어 코칭이 인정 + 다음 단계 질문*으로 연결.

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

@@ -0,0 +1,346 @@
+# PR #28 — [블랙잭 1단계] 인선 미션
+
+- **Reviewee:** [@inseonyun](https://github.com/inseonyun)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/28
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 30 / 리뷰이 0 — *학생 답변이 별도 thread 또는 코멘트로 회신*)
+
+## 잘한 점 (설계 관점)
+
+- **`Name` `@JvmInline value class` + 정규식 invariant** — 원시값 포장 + 생성 시 검증.
+- **`Cards` 일급 컬렉션 + 방어적 복사 (`_cards.toList()`)** — 리뷰어 칭찬 명시.
+- **`Card private constructor` + Factory 사용** (학생 후속 반영).
+- **`CardPickerGenerator` → `CardDeck.drawCard()` 통합 (후속)** — 셔플 책임 Deck 내부로.
+- **`Cards(Set<Card>)`로 변경 (후속)** — 중복 검증 자체를 자료구조가 보장.
+- **`Cards.sum()` Ace 보정을 *합 + 10 ≤ 21*로 단순화 (후속)** — 리뷰어 권고 반영.
+
+## 못한 점 (설계 관점)
+
+### 1. `Suit`/`Rank` enum에 `description: String` UI 표현 보유
+
+```kotlin
+enum class Suit(val description: String) {
+    DIAMOND("다이아몬드"), CLOVER("클로버"), SPADE("스페이드"), HEART("하트")
+}
+enum class Rank(private val score: Int, val description: String? = null) {
+    ACE(1, "A"), KING(10, "K"), QUEEN(10, "Q"), JACK(10, "J"),
+    DEUCE(2), THREE(3), ...
+}
+```
+
+리뷰어: "description은 UI의 관심사이지 않을까요? 가령 스페이드를 "spade" "♤" 이렇게 출력할 수도 있습니다." — *UI 표현 다국어/심볼* 변경이 *도메인 enum 수정*을 강요. PR #78·#112·#125와 같은 결.
+
+### 2. `Card.toString()`이 UI 표현
+
+```kotlin
+data class Card(val rank: Rank, val suit: Suit) {
+    override fun toString(): String {
+        if (rank.description != null) return rank.description + suit.description
+        return rank.getScore().toString() + suit.description
+    }
+}
+```
+
+리뷰어: "카드가 어떻게 UI에 그려져야 할지는 *UI 영역의 관심사*입니다. 비슷하게 다른 도메인 모델에서 toString() 사용하고 있는 곳은 모두 동일합니다." — 일관 패턴 (PR #78·#112와 동일).
+
+### 3. `GameResult`가 `Map<String, Boolean>` — Win/Lose 단편
+
+```kotlin
+class GameResult private constructor(val playersResult: Map<String, Boolean>) {
+    fun getDealerWinResult(): Int = playersResult.count { !it.value }
+    fun getDealerLoseResult(): Int = playersResult.count { it.value }
+    companion object {
+        private fun match(dealer: Dealer, player: Player): Boolean {
+            if (player.isBust()) return false
+            if (dealer.isBust()) return true
+            return (BLACKJACK_POINT - dealer.cards.sum()) > (BLACKJACK_POINT - player.cards.sum())
+        }
+        fun of(dealer: Dealer, players: List<Player>): GameResult =
+            GameResult(buildMap { players.forEach { put(it.name.value, match(dealer, it)) } })
+    }
+}
+```
+
+리뷰어: "승부를 결정짓는 것은 *딜러, 플레이어와 상관없이 참가자가 다른 참가자와 판단할 요소*이지 않을까요? [...] abstract class Player { fun match(otherPlayer: Player): Result } [...] 그리고 GameResult를 만들때 *누구의 입장에서 승리인지* 알기가 어렵게 느껴집니다." — `Boolean`은 *정보 부족*(True가 누구 입장인지?) + *match가 GameResult.Companion*에 있으면 *참가자의 자율성* 손상. PR #63·#125와 같은 *Tell-Don't-Ask* 결.
+
+### 4. `CardPicker` — `Deck`과 별도 + 인덱스 비교 후 throw
+
+```kotlin
+class CardPicker(private val cards: Cards) {
+    private var cursor = 0
+    fun pick(): Card {
+        require(cursor < cards.size) { OUT_OF_INDEX_CARDS_CURSOR }
+        return cards.cards[cursor++]
+    }
+}
+```
+
+리뷰어: "카드를 뽑는 개념이 아닌 *선택한다는 Pick 개념은 새롭네요* 👍🏻 그런데 *크기 비교를 먼저할 필요가 있을까?* 라는 생각이 들어요 cards에게서 *특정 위치의 카드를 가져오도록 하고, 없다면 null을 반환*하도록 해서 로직을 판단할 수 있지 않을까요?" / "*CardPicker가 단순히 "보기" 기능만 제공*하다보니 카드뭉치가 해야할 역할을 이곳저곳으로 코드가 분리되어있는 느낌이 들어요. *카드뭉치라는 개념을 만들어 보면 어떨까요?*" — *Picker*는 *덱이 해야 할 일*의 *부분*만 함. *Deck*에 *셔플 + 뽑기 + 빈 덱 처리*를 모두 응집.
+
+### 5. `CardPackGenerator` 별도 객체 — Deck이 스스로
+
+```kotlin
+class CardPackGenerator {
+    fun createCards(): Cards =
+        Cards(buildList {
+            Rank.values().forEach { rank -> addAll(Suit.values().map { suit -> Card(rank, suit) }) }
+        })
+}
+```
+
+리뷰어: "*컬렉션의 flatMap { ... } 을 활용 해보세요*" / "*카드덱이 스스로 할 수 있을 것 같은데 카드팩 제너레이터 개념이 유지될 필요가 있을까요?*" — Generator/Picker/Cards 셋이 *덱의 책임을 셋으로 쪼갬*. `CardDeck`이 *생성 + 셔플 + 뽑기* 한 객체로 응집이 자연.
+
+### 6. `Names`가 *최대 8명* invariant 보유 + `InputView`도 8명 검증
+
+```kotlin
+data class Names(val names: List<Name>) : List<Name> by names {
+    init {
+        require(names.size < PLAYER_MAX) { PLAYER_COUNT_ERROR }
+        require(names.distinct().size == names.size) { PLAYER_NAME_DUPLICATE }
+    }
+    companion object { private const val PLAYER_MAX = 8 }
+}
+
+class InputView {
+    fun readName(): List<String> {
+        ...
+        require(players.size <= PLAYER_MAX) { PLAYER_COUNT_ERROR }     // 도메인 룰이 UI에도
+        return players
+    }
+}
+```
+
+리뷰어: "*Names 객체가 플레이어가 최대 8명이라는 것을 알 필요가 있을까요?*" → 학생이 *도메인 위치*로 옮긴 후 다시: "*8명까지 참여 가능한 것은 도메인 로직이 아닐까요?*" — *도메인 invariant는 도메인 한 곳*에. UI에서 *예방 차원*으로 또 검사하면 *변경 시 두 곳 수정*.
+
+또: `Names: List<Name> by names` 위임 — 리뷰어: "*저는 개인적으로 `by List<T>` 형태의 위임은 위와 같은 이유 때문에 지양*하는 편입니다. [...] *해당 객체가 해야할 비즈니스 로직을 모두 이곳에서 처리하는 실수로 이어지고 있어요*. 플레이어들만 반환하는 기능은 Participants 객체가 해야할 역할이 아닐까요?" — *위임으로 외부에 List 인터페이스를 그대로 노출*하면 *호출자가 .filter/.map을 직접 사용*하게 되어 *비즈니스 로직이 호출자로 누수*.
+
+### 7. `Participant.isHit(): Boolean` — Hit가 *상태 머신*인데 Boolean으로 환원
+
+```kotlin
+abstract class Participant(val cards: Cards, val name: Name) {
+    abstract fun isHit(): Boolean
+    fun isBust(): Boolean = cards.sum() > BUST_POINT
+}
+```
+
+리뷰어: "*블랙잭 게임에서 Hit라는 상태 는 단순한 Boolean 형태로 판단하기가 어렵습니다.* 단순히 21점보다 낮다 혹은 16점보다 낮다라는 조건은 "스테이" 상태 가 될 수도 있습니다. [...] 21점보다 낮은데 *더 안뽑겠다고 하면 -> 스테이* / 21점보다 낮은데 *더 뽑겠다고 하면 -> 히트* / 21점보다 높으면 -> 버스트 [...] *"카드를 더 뽑을 수 있니" 를 묻고싶은 것은 아닐까요?*" — `isHit`은 *Hit이라는 상태*를 묻는 것처럼 보이지만 실제로는 *카드를 더 받을 수 있는지*. **이름이 상태 머신을 흉내내지만 의미는 능력 질의**. PR #78의 `State` sealed interface가 이 혼동을 해결하는 모델.
+
+### 8. `Cards.add(card: Card)`가 *중복 검사 + 추가*
+
+```kotlin
+fun add(card: Card) {
+    require(!_cards.contains(card)) { CARD_DUPLICATE_ERROR }
+    _cards.add(card)
+}
+```
+
+리뷰어: "카드를 추가할 때 마다 항상 가지고 있는지 검사하고 *오류를 발생시키고 있는데요*. *오류를 발생시키지 않도록 자료구조를 이용*해보면 어떨까요?" — *Set*을 쓰면 *중복 자체가 자료구조 invariant*. *룰을 자료구조에 위임*. 학생 후속: `Cards(Set<Card>)`.
+
+### 9. `Rank.getScore(score: Int = 0)` — 파라미터 의미 모호
+
+```kotlin
+enum class Rank(private val score: Int, val description: String? = null) {
+    ACE(1, "A"), ...
+    ;
+    fun getScore(score: Int = 0): Int {
+        when (this) {
+            ACE -> {
+                if (score + ACE_SCORE_ELEVEN > WIN_SCORE) return ACE_SCORE_ONE
+                return ACE_SCORE_ELEVEN
+            }
+            else -> return this.score
+        }
+    }
+}
+```
+
+리뷰어: "`getScore()` 함수의 파라미터가 *무엇을 하기 위한 역할인지 잘 와닿지 않는 것 같아요*. 이 내용은 앞서 *카드의 합계를 계산하는 방법을 개선*하면 달라질 수 있겠네요" — *Ace 점수를 카드 한 장이 결정*하려면 *현재까지의 합*을 인자로 받아야 함. 그러나 *합산은 컬렉션의 책임*이지 *카드 한 장*의 책임이 아님. `Cards.sum()`에서 *Ace 보정 단일 룰*로 통일하면 *Rank.score는 인자 없는 단순 값*.
+
+또: `getScore`의 `score` 파라미터 동명 — *함수명 = 변수명*은 PR #78 (`drawOrNot`)과 같은 결.
+
+### 10. `Participants(List<Participant>)` + `Participants.of(dealer, players)` — 명시 분리의 가치 의문
+
+```kotlin
+data class Participants(val participants: List<Participant>) : List<Participant> by participants {
+    companion object {
+        fun of(dealer: Dealer, players: Players) =
+            Participants(listOf(dealer as Participant) + players as List<Participant>)
+    }
+}
+```
+
+리뷰어: "딜러도 플레이어도 모두 Participant 타입으로 동일하기 때문에 *단순하게 생성할 수 있지는 않을까요?* *딜러와 플레이어를 명시적으로 받는 것에 대한 장점이 없어 보여요.*" — *Participants.of(dealer, players)* 같은 *역할별 명시 인자*가 *추상화*와 *모순*. 도메인 비유로는 *딜러는 0번째*가 자연스럽지만 *Participant.match(other)*를 보면 *균등 추상*이 자연.
+
+### 11. `CardGame`이 *초기화만* — 진행 부재
+
+```kotlin
+class CardGame(private val cardPicker: CardPicker) {
+    fun initPlayers(names: List<Name>): Players = Players(names.map { Player(pickTwice(), it) })
+    fun initDealer(): Dealer = Dealer(pickTwice())
+    fun pickTwice(): Cards = Cards(buildList { add(cardPicker.pick()); add(cardPicker.pick()) })
+}
+```
+
+리뷰어: "*카드 게임에 대한 기본적인 진행 방식*을, 위 객체에서 담당할 것이라고 기대했는데 *초기화만 하고 아무런 역할을 하지 않네요*. 게임을 진행할 수 있도록 기능을 추가 해보면 어떨까요?" — 이름이 *Game*인데 *Game을 안 함*. `Controller`가 진행 로직을 모두 가짐. *이름 = 책임 기대치*의 불일치.
+
+### 12. `CardGame.drawPlayersCard(players, input: (String) -> Boolean, output: (Participant) -> Unit)` — UI callback이 도메인에
+
+```kotlin
+fun drawPlayersCard(players: Players, input: (String) -> Boolean, output: (Participant) -> Unit) {
+    players.filter { it.isHit() }.forEach { drawPlayerCard(it, input, output) }
+}
+```
+
+리뷰어: "1. 카드게임의 함수에서 *UI를 연상시키는 이름을 사용하면 안됩니다*. (input, output)과 같은 이름 대신 *도메인 기능에 맞는 이름*을 사용해야 합니다. 2. *파라미터는 Participant를 사용하는 반면, 함수 이름에서 구현체가 드러나면 안됩니다.* 3. 더 뽑을지 여부를 UI로부터 받도록 *Player에서 협력 관계*를 만들어 줄 수 있을 것 같습니다. ``` class Player(val needToDraw: () -> Boolean) { fun isHit(): Boolean = "더 뽑을 수 있고" && needToDraw() } ```" — *callback이 도메인 함수 인자*면 *UI 어휘가 도메인 메서드명에 누수*. *Player의 의도* 자체에 *Hit 의사*를 callback으로 주입.
+
+### 13. `CardGame.pickTwice()` public — *외부 미사용, 테스트만 사용*
+
+리뷰어: "위 함수는 외부에서 *사용이 되지 않고 있어요* 테스트 코드에서만 사용하는 것은 *사용된다고 하지 않습니다*. 위 기능은 *다른 메소드를 통해 테스트가 가능하도록 만들어 져야* 하겠습니다." — PR #63 (jinuemong)의 `changeState() public`과 동일 결. *테스트 위해 public화*는 *캡슐화 위반*. *입력 → 출력*으로 검증.
+
+### 14. `Dealer.getGameResult(players)` + `Player.getGameResult(dealer)` — 같은 메시지 두 구현
+
+```kotlin
+class Dealer(...) : Participant(...) {
+    fun getGameResult(players: Players): Map<Result, Int> {
+        val playersResult = players.getGameResult(this)
+        return mapOf(
+            Result.WIN to (playersResult.count { it.value == Result.LOSE }),
+            Result.LOSE to (playersResult.count { it.value == Result.WIN }),
+        )
+    }
+}
+```
+
+리뷰어: "이 함수가 *플레이어, 딜러가 각각 따로 새롭게 정의될 필요가 있을까요?* 외부에서는 `Participant.getGameResult(...)` *메시지를 요청하는 것*으로 볼 수 있지 않을까요?" — *동일 메시지*를 *역할 다른 두 클래스*에 *별도 구현*하면 *추상화 부재*. `Participant.getGameResult(other: Participant)`로 *Liskov 호환*.
+
+### 15. `OutputView`가 `participant.cards.cards.elementAt(0)`로 직접 접근
+
+```kotlin
+fun printPlayerStatus(participant: Participant) {
+    if (participant.name.value == DEALER) {
+        println(MESSAGE_DEALER_STATUS.format(participant.cards.cards.elementAt(0).getCardFormat()))
+    } ...
+}
+```
+
+리뷰어: "*참가자에게 -> 처음 뽑은 카드 목록을 요청한다 라는 기능*으로 만들어 볼 수 있지 않을까요? `abstract fun getFirstOpenCards(): Cards` [...] *지금 Player, Dealer, Participant등의 cards에 직접 접근해서 비즈니스 로직을 처리하는 것이 아닌 해당 객체가 스스로 처리할 수 있도록 만들어 주셔야 합니다.* 극단적으로는 *cards를 private으로 만들고 구현을 유지*시킨다?" — *View가 도메인 내부 구조 분해 접근*. `.cards.cards.elementAt(0)`는 *세 단계 의존*. `participant.firstOpenCard()` 메시지.
+
+### 16. `Controller`의 *재진입 시 Bust 가드 누락*
+
+```kotlin
+private fun askGetMorePlayerCard(player: Player) {
+    while (player.isHit() && inputView.readYesOrNo()) {
+        player.cards.add(picker.pick())
+        outputView.printPlayerStatus(player)
+        if (player.isHit()) outputView.printGetCardMore(player.name)
+    }
+}
+```
+
+리뷰어: "*카드를 받고나면 버스트 상태가 되어버릴 수도 있지 않을까요?* 그러면 의도와 달리 출력이 되지 않을 것 같아요" — `isHit()`이 *Hit 가능 == 21 미만*이라면 *카드 받은 후 22가 되어 isHit=false*. *if 분기*가 *Bust 발생 시 잘못된 메시지*. 상태 머신이 있으면 *Bust 메시지가 자동*.
+
+### 17. `Cards.sum()` Ace 계산 — *합 + 10 ≤ 21*인지 *2번 검토*는 무의미
+
+```kotlin
+fun sum(): Int {
+    var sum = _cards.sumOf { it.rank.score }
+    repeat(_cards.filter { it.rank == Rank.ACE }.size) {
+        if (sum + ACE_BONUS_TEN <= PARTICIPANT_STANDARD_BUST_POINT) sum += ACE_BONUS_TEN
+    }
+    return sum
+}
+```
+
+리뷰어: "*에이스 카드가 2장인 경우에 과연 20점의 보너스를 받는 경우가 있을까?* 를 생각해보세요. 조금 더 간단하게 만들어 질 수 있습니다." — *Ace 두 장 모두 11로 계산 = 22*는 *항상 Bust*. → *Ace는 최대 한 장만 11* (다른 한 장은 1). 룰 단순화 = *한 번만 검토*.
+
+### 18. `ParticipantsTest` setup 장황 — Factory 함수 권고
+
+```kotlin
+val dealer = Dealer(Cards(listOf(Card(Rank.KING, Suit.HEART))))
+val players = Players(listOf(
+    Player(Cards(listOf(Card(Rank.ACE, Suit.HEART))), Name("jason")),
+    Player(Cards(listOf(Card(Rank.DEUCE, Suit.HEART))), Name("pobi"))
+))
+```
+
+리뷰어: "*테스트 코드를 만들기 위해 준비하는 재료가 가독성을 떨어트리고 있어요.* [...] `val players = Players(Player("jason", Card(ACE, HEART)), Player("pobi", Card(DEUCE, HEART)))`" — *테스트는 시나리오*. *생성 boilerplate*가 *의도*를 가림. *vararg 생성자 + 간결한 Card factory*.
+
+### 19. `PlayerTest`가 *CardPicker + CardPackGenerator*로 테스트
+
+```kotlin
+@Test
+fun `플레이어는 카드 두 장을 받을 수 있다`() {
+    val cards = CardPackGenerator().createCards()
+    val cardPicker = CardPicker(cards)
+    ...
+}
+```
+
+리뷰어: "플레이어가 카드를 두장 받는 기능을 테스트 하는 것이기 때문에 *카드 피커와 카드 제너레이터는 이곳에서 고려하거나 사용하는 것은 적절하지 않습니다*." — *Player의 책임*은 *카드 보유*. *카드 출처*는 무관. *테스트 격리 = 테스트 대상의 책임만*.
+
+### 20. `CardTest`가 *Rank 테스트*
+
+```kotlin
+@Test
+fun `ACE가 플레이어에게 11이 더 유리한 경우, 유리한 숫자로 반환된다`() {
+    val card = Card(Rank.ACE, Suit.CLOVER)
+    assertThat(card.rank.getScore(1)).isEqualTo(11)
+}
+```
+
+리뷰어: "위 테스트는 *Card를 테스트하는 것이 아니고, Rank를 테스트 한 것이지 않을까요?*" — `card.rank.getScore(1)`은 *Rank의 메서드*. *Card 클래스 = Rank + Suit 묶음*인데 *묶음의 동작*이 아닌 *Rank 동작*을 검증.
+
+## 리뷰어 의견 요지
+
+- ***enum description (UI 표현)은 도메인 X*** — PR #78·#112·#125와 일관.
+- ***toString 도메인 메서드 X***.
+- ***match는 참가자의 메시지*** — `Participant.match(other)` Tell-Don't-Ask.
+- **`CardPicker`/`CardPackGenerator` 셋이 *덱의 책임을 흩뜨림*** — `Deck` 단일 응집.
+- ***도메인 invariant는 도메인 한 곳*** — UI/Domain 양쪽 검증은 변경 비용.
+- ***`by List<T>` 위임은 비즈니스 로직 누수 위험***.
+- ***`isHit(): Boolean`은 상태 머신을 흉내내지만 의미는 능력 질의*** — 상태와 능력 분리.
+- ***Set은 중복 검사를 자료구조에 위임***.
+- ***`getScore(score: Int)` 파라미터 모호*** — 합산 위치 개선.
+- ***`Dealer.getGameResult` vs `Player.getGameResult` = 추상화 부재*** — `Participant.getGameResult(other)`.
+- ***`participant.cards.cards.elementAt(0)`는 캡슐화 분해*** — `firstOpenCard()` 메시지.
+- ***UI callback `input`/`output`이 도메인 함수명에 노출*** — 도메인 어휘만.
+- ***테스트 위해 public화 금지***.
+- ***Ace 2장 = +20은 항상 Bust*** — 룰 단순화.
+
+## 대표 인용
+
+> 승부를 결정짓는 것은 딜러, 플레이어와 상관없이 *참가자가 다른 참가자와 판단할 요소*이지 않을까요?
+> — @laco-dev on `src/main/kotlin/model/GameResult.kt`
+
+> 블랙잭 게임에서 Hit라는 *상태* 는 단순한 Boolean 형태로 판단하기가 어렵습니다. [...] "카드를 더 뽑을 수 있니"를 묻고싶은 것은 아닐까요?
+> — @laco-dev on `src/main/kotlin/model/Participant.kt`
+
+> CardPicker가 단순히 *"보기" 기능만 제공*하다보니 카드뭉치가 해야할 역할을 *이곳저곳으로 코드가 분리*되어있는 느낌이 들어요. *"카드뭉치" 라는 개념을 만들어 보면 어떨까요?*
+> — @laco-dev on `src/main/kotlin/controller/Controller.kt`
+
+> Names 객체가 *플레이어가 최대 8명이라는 것을 알 필요가 있을까요?*  / 8명까지 참여 가능한 것은 도메인 로직이 아닐까요?
+> — @laco-dev (Names → InputView 양쪽)
+
+> 카드를 뽑는건 *Participant 객체가 자율적으로* 할 수 있도록 해주세요
+> — @laco-dev on `src/main/kotlin/domain/CardGame.kt`
+
+> 참가자에게 -> *처음 뽑은 카드 목록을 요청한다* 라는 기능으로 만들어 볼 수 있지 않을까요?
+> — @laco-dev on `src/main/kotlin/view/OutputView.kt`
+
+## 얻은 교훈
+
+- ***enum description (UI 표현) 도메인 보유는 일관 안티패턴*** — PR #78/#112/#125와 합쳐 *4개 PR 연속 등장*. MCP 룰 후보로 강력.
+- ***`Map<String, Boolean>` 같은 자료구조는 의미 부족*** — *True가 누구 입장 승리?* 같은 *의미 손실*. enum/sealed로 명시.
+- ***Generator + Picker + Cards 셋은 Deck의 책임을 셋으로 쪼갬*** — *덱 한 객체*가 *생성 + 셔플 + 뽑기*를 응집.
+- ***Names가 "8명 제한"을 알면 도메인, UI가 알면 누수*** — *도메인 invariant는 도메인 한 곳*. UI에서 *예방*은 변경 비용.
+- ***`by List<T>` 위임은 비즈니스 로직을 호출자로 누수*** — 컨트롤러가 `.filter`/`.map` 쓰기 시작. 일급 컬렉션의 *메서드만 노출*.
+- ***`isHit(): Boolean`은 상태와 능력의 혼동*** — Hit은 *상태*(Hit/Stay/Bust)인데 Boolean은 *능력*(더 받을 수 있나). *상태 머신* + *능력 질의*는 별도.
+- ***Set으로 중복 검사를 자료구조에 위임*** — `_cards.contains(card)` + throw 대신.
+- ***`Rank.getScore(score: Int)` 파라미터는 책임 위치 신호*** — 카드 한 장이 *문맥 합*을 받으면 *합산 책임이 카드에*. *합산은 컬렉션*이 자연.
+- ***UI callback (`input`/`output`)을 도메인 함수 인자로 받으면 도메인 어휘 침범*** — *Player의 의도* 자체를 `needToDraw: () -> Boolean`으로 협력.
+- ***`Dealer.getGameResult` vs `Player.getGameResult` = 동일 메시지 두 구현 → 추상화 부재*** — `Participant.getGameResult(other)` 한 메서드.
+- ***View가 `participant.cards.cards.elementAt(0)`로 분해 접근 = 캡슐화 깨짐*** — `firstOpenCard()` 메시지.
+- ***`pickTwice()` 외부 미사용 + 테스트만 사용은 *사용된다고 하지 않음*** — 입력→출력 경로로 테스트.
+- ***Ace 두 장 = +20은 항상 Bust*** — *Ace는 최대 한 장만 11*. 한 번 검토로 충분.
+- ***CardTest가 `card.rank.getScore()`를 검증하면 Rank 테스트*** — *대상 클래스의 책임*에 한정된 시나리오.