oh-my-oop 0.2.0

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

@@ -0,0 +1,540 @@
+# PR #136 — [블랙잭 2단계] 밀러 미션
+
+- **Reviewee:** [@oungsi2000](https://github.com/oungsi2000)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/136
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @Gyuil-Hwnag (두루)
+- **라인 코멘트:** 20 스레드 / 48 코멘트 — 학생 자가 학습 (엘레강트 오브젝트) 풍부 + 두루의 메타 질문 다수
+
+## 잘한 점 (설계 관점)
+
+- **`sealed class BlackJackRule<T : Participant>` + `Bust` / `BlackJack` / `Stay` subtypes — State 패턴 정공 (sealed)** — *닫힌 계층 = 컴파일러 보장 + 외부 구현 차단*. 1단계 *함수형 분기*에서 *상태 객체 다형성*으로 자가 학습 후속. *제네릭 (`<T : Participant>`)* 으로 *Player/Dealer 타입 구분* — 진보된 Kotlin 어휘 활용. PR #152 (모찌 2단계) 의 *interface State* 와 비교: *sealed* 가 정공.
+- **`BlackJackRule(participant)` 팩토리 함수 (`@Suppress("FunctionName")`)** — *클래스와 동일 이름의 함수 = Kotlin pseudo-constructor 패턴*. `BlackJackRule(participant)` 호출 시 *isBust / isBlackJack / else (Stay)* 분기로 *적절한 subtype 반환*. *Caller 가 마치 생성자처럼 사용*. **`@Suppress("FunctionName")`** 으로 *PascalCase 함수* 의도 명시. PR #108 (시아 1단계) 의 *Card.invoke* 함정 회피 — *별도 함수명 + 명시적 자유함수* 가 *생성자 모호함 회피*.
+- **상태 메시지 다형성 — `compare(other: BlackJackRule<out Participant>): GameResult` 가 sub-type 별로 다른 구현**:
+  ```kotlin
+  // BlackJack
+  override fun compare(other) = if (other is BlackJack) DRAW else WIN
+  // Bust
+  override fun compare(other) = LOSE
+  // Stay
+  override fun compare(other) = when {
+      other is BlackJack -> LOSE
+      other is Bust -> WIN
+      else -> Score(participant).compare(Score(other.participant))
+  }
+  ```
+  *Tell-Don't-Ask 정공* — *상태 객체가 자기 입장 비교 결과* 직접 반환. *Bust 는 무조건 LOSE* (블랙잭 룰 정확). PR #152·#133·#131·#132 와 같은 결.
+- **`GameResult` enum + `sign: Int`** — WIN(1) / LOSE(-1) / DRAW(0) 부호 일급화. *수익률 = sign × multiplier* (BlackJack은 1.5, Stay는 1.0). *룰 표 = enum 부가 속성*. PR #132 (환노 2단계) 의 `earningRate: Double` 와 비슷한 결.
+- **`Score` data class + `operator fun compareTo(Score)` + `operator fun compareTo(Int)`** — *Score 비교 = Score 와 Int 둘 다 지원*. `score > 21` / `score < otherScore` 자연 표현. *value class 안 쓰고 data class* — *constructor 오버로딩 (`Score(List<Card>)` + `Score(Participant)`)*. *Kotlin 연산자 어휘 활용*.
+- **`Score.calculateTotalSum` Ace 처리 패턴 — `while (sum > 21 && aceCount > 0) sum -= (11 - 1)`** — *Ace 11 기본 + while 차감* 패턴. *Ace 다수 정확* (각 Ace 11 → 1 점진적). PR #128·#135·#114·#125·#108·#131 와 같은 결. *내부적으로 Ace 1↔11 양가성*.
+- **`Score(Participant)` 보조 생성자 — Score 가 Participant 의존 가능** — *Score 객체에 Participant 인자* = *`Score(participant.getCards())` 의 syntactic sugar*. *호출 편의 + 코드 길이 ↓*. 다만 *Participant 가 Score 알아야 호출 → Score 가 Participant 알아야 생성* = *순환 의존 신호* (못한 점 §3).
+- **`NullableRetry` / `ThrowableRetry` interface — 입력 재시도 추상화** — 1단계 lotto 의 *sealed class 예외 처리* 경험 반영 + *AOP-like retry 인터페이스* 도입. 학생 자가 인용: *"엘레강트 오브젝트의 4.2에서 재시도 로직은 aop로 처리하면 깔끔하다는 내용이 있어 비슷하게 구현하려고 시도해봤어요."* 두루 자가 답변: *"구현해주신 내용 아주 좋습니다👍"*.
+- **`BlackJackPair` data class (Player + Dealer)** — *카지노 매치 단위* 일급화. *Controller 가 입력받은 플레이어 + 딜러 묶음*. PR #131·#132 와 같은 결의 *PlayerGroup*.
+- **`Participant.isBlackJack` 룰 정확 — `countAce() == 1 && countScoredTen() == 1`** — *Ace 1장 + 10점 카드 1장 = 블랙잭 2장 21점*. *조합 정확* (Ace+10 / Ace+J / Ace+Q / Ace+K). 다만 *2장 size 검증 부재* (못한 점 §1).
+- **엘레강트 오브젝트 자가 학습 + 본인 코드 적용** — *4.2 체크 예외만 던지세요 → ThrowableRetry 적용*. *2.2 상태 없는 행동 클래스 지양 → BlackJackResult 객체 책임 재배치*. *책 → 코드 적용 + 두루와 토론* 학습 모범.
+- **`Cards → Hand` naming 자가 반영** — 두루 코멘트: *"`Cards 객체는 플레이어가 가지고 있는 카드`라는 담당하는 기능에 맞게 네이밍을 수정해보는 것도 좋을 것 같습니다!"*. 학생 자가 반영: *"Cards -> Hand로 이름을 변경하였습니다..!"* *도메인 어휘 정확성*.
+- **`State → BlackJackRule` naming 자가 반영** — 두루: *"State가 담당하고 있는 것은 블랙잭의 규칙이군요. 해당 객체가 담당하고 있는 기능에 맞게 네이밍을 수정해볼 수 있을 것 같군요💪"*. 학생 자가 반영: *"BlackJackRule 로 이름을 변경하였습니다"*. *naming = 책임 표현*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Participant.isBlackJack` — *2장 size 검증 부재 = 룰 invariant 누수*
+
+```kotlin
+fun isBlackJack(): Boolean {
+    return innerHand.countAce() == 1 && innerHand.countScoredTen() == 1
+}
+```
+
+→ **`countAce + countScoredTen == 2` 의 *카드 2장 강제 부재***. *Ace 1장 + 10점 카드 1장 + 다른 카드* 도 *조건 통과*. 예: *A♠ K♥ 2♣* — *countAce=1, countScoredTen=1, sum=13(A=11)→13(<=21 OK)*. *isBlackJack=true* 인데 *블랙잭 룰 = 2장 21*. *실제로 게임에서 *블랙잭은 초기 2장 후만 판정*이므로 *3장 도달 전에 분기*하면 누락 없음. 다만 *Hand 자체*가 *블랙잭 invariant 강제 안 함*.
+
+*명시적 검증*:
+
+```kotlin
+fun isBlackJack(): Boolean {
+    return innerHand.size() == 2 && countAce() == 1 && countScoredTen() == 1
+}
+```
+
+이 *컴파일 타임 + 런타임 invariant 보장*. 두루 코멘트는 없으나 *룰 정확성 신호*.
+
+### 2. `BlackJackRule.compare` 가 *`is BlackJack`/`is Bust` 타입 검사* — *sealed when exhaustive 미활용*
+
+```kotlin
+// Stay
+override fun compare(other: BlackJackRule<out Participant>): GameResult {
+    if (other is BlackJack) return GameResult.LOSE
+    if (other is Bust) return GameResult.WIN
+    return Score(participant).compare(Score(other.participant))
+}
+
+// BlackJack
+override fun compare(other) = if (other is BlackJack) DRAW else WIN
+
+// Bust
+override fun compare(other) = LOSE
+```
+
+→ **`if (other is BlackJack)` / `if (other is Bust)` 타입 검사 = *sealed when exhaustive 미활용***. *`sealed class BlackJackRule`* 인데 *when (other)* 패턴 매칭이면 *컴파일러가 모든 분기 강제*. 현재 *if-return* 은 *Stay 와의 비교* (else fallback) 누락 시 *런타임 발견*.
+
+```kotlin
+override fun compare(other) = when (other) {
+    is BlackJack -> GameResult.LOSE
+    is Bust -> GameResult.WIN
+    is Stay -> Score(participant).compare(Score(other.participant))
+}
+```
+
+이 *sealed 의 장점 = 새 상태 추가 시 모든 compare 함수 컴파일 오류*. *현재 if-return* 은 *새 subtype 추가 시 누락 가능*.
+
+### 3. `Score(Participant)` 보조 생성자 — *순환 의존 신호*
+
+```kotlin
+// Score
+data class Score(private val cards: List<Card>) {
+    constructor(participant: Participant) : this(participant.getCards())
+    ...
+}
+
+// Participant
+fun canHit(): Boolean = Score(this) < hitThreshold
+
+fun isBust(): Boolean = Score(innerHand.toList()) > BLACKJACK_BUST_LIMIT
+```
+
+→ **Score → Participant 의존 + Participant → Score 의존 = 순환**. *Score 는 카드 점수 계산* + *Participant 는 자기 점수 (Score) 알림*. *Participant.score(): Score* 메시지가 *Tell-Don't-Ask* 정공. *현재 Score 가 Participant 인자 받음 + Participant 도 Score 생성* 양방향.
+
+*해결*:
+- *Score 가 Participant 모름* (`Score(List<Card>)` 만) + *Participant.score() = Score(cards)* 위임
+- *Score 가 도메인 의식 X + 단순 점수 객체*. *Participant 가 자기 카드로 Score 생성*만.
+
+PR #131 (다이스 2단계) 의 *Score private constructor + Score.create(cards)* 와 같은 결 — *순환 회피*. 현재는 *순환 의존* — *학습 가시화 의도*인지 *우연*인지 모호.
+
+### 4. `Score.compare(other): GameResult` 의 `else throw IllegalStateException` — *도달 불가 명시*
+
+```kotlin
+fun compare(other: Score): GameResult {
+    return when {
+        this > other -> GameResult.WIN
+        this < other -> GameResult.LOSE
+        this.isEqualTo(other) -> GameResult.DRAW
+        else -> throw IllegalStateException("")
+    }
+}
+```
+
+→ **`>` / `<` / `==` 3 분기 + else throw** — *논리적으로 3 분기 모든 경우 처리*. *else 도달 불가*. *`when { ... }` exhaustive 보장이 Kotlin 컴파일러*에선 *Int 비교의 경우 자동 보장 X* — *명시적 else 또는 if/else if* 필요. 현재 *throw* 는 *도달 불가 명시* 패턴. 다만 *throw 의미가 모호 (`""` 빈 메시지)*. *`UnreachableException` / `error("...")`* 가 *의도 명시*.
+
+또한 *`this.isEqualTo(other) -> DRAW`* 가 *value 비교* — *`this > other == false && this < other == false`* 이면 *값 동등* 이므로 *isEqualTo 도 true*. *3 분기 자체가 중복*. *`compareTo(other).sign` 로 -1/0/1 → enum 매핑* 이 1줄.
+
+### 5. `Score(this)` Participant 인자 매 호출 — *불필요한 객체 생성*
+
+```kotlin
+// Participant
+fun canHit(): Boolean = Score(this) < hitThreshold  // 매 호출 새 Score 객체
+
+fun isBust(): Boolean = Score(innerHand.toList()) > BLACKJACK_BUST_LIMIT  // 매 호출 새 Score
+```
+
+→ **`Score(this)` / `Score(innerHand.toList())` 매 호출 새 객체** — *Score data class* 라 *equals/hashCode* 정합이지만 *불변 객체로서 매번 새 인스턴스*. *Hand 변경 안 되면 같은 Score* — *캐싱 가능*. 다만 *Score 가 cards.list 보유 + Hand 가 가변* 이므로 *Score(this) 가 매번 다른 카드 리스트*. *현재 Hand.add 시 Score 다음 생성 = 다른 점수*.
+
+*성능보다 의미 명료성* 측면 — *Participant.score(): Score* 가 *자기 점수 메시지* 가 더 자연. *Score(this)* 가 *Participant 외부에서 Score 생성*도 가능하지만 *호출자가 Score 직접 다룸* 패턴.
+
+### 6. `BlackJackRule.getEarnRate(gameResult: GameResult)` — *Bust 입장 비대칭*
+
+```kotlin
+// BlackJack
+override fun getEarnRate(gameResult: GameResult): Double = 1.5 * gameResult.sign
+
+// Stay
+override fun getEarnRate(gameResult: GameResult): Double = gameResult.sign * 1.0
+
+// Bust
+override fun getEarnRate(gameResult: GameResult): Double = -1.0  // ⚠ gameResult 무시
+```
+
+→ **Bust 는 `getEarnRate(gameResult)` 인자 무시 + 항상 -1.0**. *Bust 는 항상 LOSE* 룰 정합. 다만 *`getEarnRate(GameResult.WIN)`* 같은 *불가능 호출*도 *-1.0* 반환 — *함수 시그니처가 호출자에게 misleading*. *Bust.compare(other) = LOSE* 만 호출되므로 *getEarnRate(LOSE) 만 정합* — *런타임 보장*은 *현재 사용 흐름* 의존.
+
+*해결*: *Bust.getEarnRate() (인자 없음)* 시그니처. 다만 *오버라이드 호환성 깨짐*. *세 subtype 시그니처 통일 vs Bust 안전성* 트레이드오프. *현재 통일* 선택.
+
+또한 *`gameResult.sign * 1.0`* (Stay) = *`gameResult.sign.toDouble()`*. *× 1.0* 곱셈은 *명시적 Double 변환 의도* 인지 *불필요한 곱셈*인지 모호.
+
+### 7. `Player.bettingAmount: Int = 0` default + `require(bettingAmount > 0)` 모순
+
+```kotlin
+class Player(val name: String, val bettingAmount: Int = 0) : Participant() {
+    init {
+        require(name.isNotEmpty()) { INVALID_NAME }
+        require(bettingAmount > 0) { INVALID_BETTING_AMOUNT }
+    }
+    ...
+}
+```
+
+→ **default = 0 + require > 0 모순** — *`Player(name)` 호출 시 *bettingAmount = 0 → require 실패***. *default 값 자체가 invalid*. *Kotlin default value 는 유효한 값* 이어야 함. *default 제거* (`val bettingAmount: Int`) 가 *호출자 강제 명시*. *PR #131 (다이스) 의 기본 생성자 지양* 권고와 같은 결.
+
+### 8. `BlackJackGame.run()` 의 *if + outputView 분기* — *Tell-Don't-Ask 부분 위반*
+
+```kotlin
+fun run() {
+    eachPlayerHitOrNot()
+    if (pair.dealer.needsAdditionalCard()) {
+        outputView.printDealerHaveAdditionalCard()
+    }
+    addDealerCard()
+}
+```
+
+→ **`if (pair.dealer.needsAdditionalCard())` 가 *외부 분기 + 출력* + `addDealerCard()` 가 *내부 루프***. *Dealer 의 추가 카드 받는 흐름*이 *외부 if 분기 + 내부 while*로 *책임 분산*. *`Dealer.takeAdditionalCards(deck, onAdditionalNeeded: () -> Unit)`* 같은 *콜백 메시지*면 *if 분기 사라짐*. PR #131·#132·#152 와 같은 결.
+
+또한 `needsAdditionalCard()` 와 `canHit()` 의 차이 모호:
+
+```kotlin
+// Dealer
+fun needsAdditionalCard(): Boolean = Score(this) < DEALER_HIT_THRESHOLD  // < 17
+
+// Participant
+fun canHit(): Boolean = Score(this) < hitThreshold  // < 17 (Dealer)
+```
+
+→ *완전 동일 의미 + 다른 이름* = *naming 중복*. *둘 다 *Dealer 가 17 미만일 때 true**. *`canHit` 한 가지로 통일* 또는 *`needsAdditionalCard`* 만 노출이 자연.
+
+### 9. `handlePlayerHit` 의 *while + boolean 분기 + break*
+
+```kotlin
+private fun handlePlayerHit(player: Player) {
+    while (player.canHit()) {
+        val result = inputView.askPlayerHit(player.name)
+        if (result) {
+            player.addCard(deck.draw())
+            outputView.printPlayerCards(player)
+        } else {
+            break
+        }
+    }
+}
+```
+
+→ **`Boolean` 반환 input → if + break + while** — Kotlin 어휘 `do-while` + *`break` 위치 모호* (else 안). *Player.takeTurns(askHit: () -> Boolean, ...)* 같은 *콜백 패턴*이 더 응집. PR #132 (환노) 의 *고차함수 시도 + 인터페이스* 토론과 같은 결.
+
+또한 `inputView.askPlayerHit(player.name)` 가 *Boolean 반환* — *플레이어 행동 = "예/아니오"* 만 가정. PR #132 의 *ActionType enum + InputView 다형성* 권고 (페로로 진단) 와 같은 결.
+
+### 10. `Score.value: Int get() = calculateTotalSum()` — *매 호출 재계산*
+
+```kotlin
+data class Score(private val cards: List<Card>) {
+    val value: Int
+        get() = calculateTotalSum()
+    ...
+}
+```
+
+→ **`value` getter 가 *매 호출 calculateTotalSum 재계산***. *Score 가 불변 (data class + val cards)* 인데 *getter 계산*. *`val value: Int = calculateTotalSum()`* 초기화로 *한 번만 계산* 가능. *현재 `get() = ...`* 는 *function* 의미 — *순수 함수면 캐싱 안전*.
+
+*성능 미세* 비용. 다만 *`value` 사용처가 `compareTo` 등 다수*면 *반복 계산*. PR #131 (다이스) 의 *Score private constructor + factory* 와 *비교*: 다이스는 *생성 시 계산 + value 불변*, 밀러는 *getter 매 계산*. 둘 다 동작은 정확.
+
+### 11. `Score.isEqualTo` 노출 + *equals override 회피*
+
+```kotlin
+data class Score(private val cards: List<Card>) {
+    ...
+    fun isEqualTo(other: Score): Boolean = value == other.value
+    ...
+}
+```
+
+두루 (Score.kt:50 — 미해결): *"해당 함수에 대해서 외부에 드러나도록 작성을 하신 이유가 있을까요?"*
+
+학생 자가 답변: *"현재는 외부에서 오버로딩한 compareTo 연산자를 사용하고 있어요. 이 말은 즉 모양만 다를 뿐 사실 equals 연산자를 사용하는 isEqualTo 가 외부에서 사용될 여지가 있다고 생각했어요. 사실 equals를 재정의하려고도 생각했어요. 하지만 hashcode도 재정의 해야하며, 예제 코드로 대략 보았을 때 코드가 지저분하다고 생각하여 그냥 이름만 다른 isEqualTo 라는 메소드를 제작하는 것이 더 낫겠다고 생각이 들었네요. 두루의 생각은 어떤가요?"*
+
+두루 후속: *"그런 이유였군요~ 그렇다면 좋습니다!👍"*
+
+→ **`equals` 재정의 vs `isEqualTo` 별도 메서드** — *Kotlin data class 는 equals 자동* (val cards 기반). *Score.value 동등성 ≠ cards 동등성*. 예: *cards = [A♠, K♥]* 와 *cards = [K♠, A♥]* 가 *value 같지만 cards 리스트 다름* → *equals false, isEqualTo true*. *학생의 의도 명료* — *value 기반 비교를 별도 메서드로*.
+
+다만 *Score.value 가 Score 의 본질*이면 *equals 도 value 기반* 이 자연. *data class 의 equals 가 cards 기반* 은 *Score 가 카드 리스트 ID로 동등성 갖는다* 의미 — *블랙잭에서 카드 순서/조합과 무관한 점수 동등성*과 맞지 않음. *학생의 isEqualTo 분리 결정*은 *data class 의 equals 의도와 도메인 의미의 불일치*를 회피한 합리적 선택. 다만 *non-standard Kotlin 어휘*.
+
+### 12. `Score.compare(other)` 의 `else throw` + *3 분기 중복*
+
+```kotlin
+fun compare(other: Score): GameResult {
+    return when {
+        this > other -> GameResult.WIN
+        this < other -> GameResult.LOSE
+        this.isEqualTo(other) -> GameResult.DRAW
+        else -> throw IllegalStateException("")
+    }
+}
+```
+
+→ **분기 중복 + 도달 불가 throw**. *`this > other == false && this < other == false`* 이면 *값 동등* (Int compareTo 의 *trichotomy*). *isEqualTo 분기 자체 중복*. *throw 도 도달 불가* — *컴파일러 보장 부재*.
+
+*간결화*:
+
+```kotlin
+fun compare(other: Score): GameResult = when {
+    this > other -> GameResult.WIN
+    this < other -> GameResult.LOSE
+    else -> GameResult.DRAW
+}
+```
+
+이 정공. *학생 자가 의도*는 *isEqualTo 메서드의 사용 의도 노출* 일 가능성 — *코드 가독성에 isEqualTo 등장*. 다만 *논리 중복*.
+
+### 13. `BlackJackPair` 인스턴스 변수 3개 회피 시도 — 학생 자가 회의
+
+```kotlin
+data class BlackJackPair(val players: List<Player>, val dealer: Dealer = Dealer())
+```
+
+학생 PR 코멘트 (BlackJackPair.kt:3): *"컨트롤러에서 입력받은 플레이어와 딜러를 묶는 일급 컬렉션을 생성했어요! 여기에 사실 deck 도 넣고싶었지만 인스턴스 변수는 3개 미만이어야 해서.... 그런데 의문이 가는 점이 있어요. 다른 모든 부분은 인스턴스 변수를 3개 미만으로 줄였지만, 컨트롤러와 블랙잭 게임 객체는 view를 주입받아 어떻게 하더라도 3개 미만으로 못 줄이겠더라고요.. 굳이 3개 미만으로 줄인다면 view를 주입하는 것이 아닌 직접 blackjackView에 접근하도록 해야 할 것 같아요. 엘레강트 오브젝트의 해당 내용을 본다면 이는 잘못된 방법 같아요."*
+
+두루 답변: *"맞아요...😅 실제로 구현을 하면서 변수가 3개 미만으로만 규정을 하기는 정말 힘든 부분이 많습니다. 특히나, Controller 와 BlackJackGame 에서는 무지하게 힘듭니다. 맞추려다보면 어거지로 객체를 끼워넣는 방식이 될 수 있어요. 그래서 저도 왠만하면, Controller 와 BlackjackGame 부분에 대해서는 변수에 대한 제한에 대해서 별말을 하지 않았긴 합니다!"*
+
+두루 후속: *"해당 객체를 없앨 수 있는 방법은 한가지가 있긴 합니다. ... `BlackjackGame.run()`으로 블랙잭 게임을 실행시켜보도록 하는 것은 어떨까요? ㄴ 이말은 BlackJackGame 이라는 Controller 역활을 하는 객체를 만들어보길 원했어요. GameController 라는 것이 존재하고 해당 GameController 에서는 여러 게임들을 실행 시킬 수 있으며, 해당 Controller 에서는 `게임객체.run()`으로 실행이 가능하도록 한다!"*
+
+→ **3 변수 제약 자가 회의 + 두루 답변 = 제약 vs 현실의 트레이드오프 학습**. PR #133 (시아 2단계) 의 *말리빈 "연습 도구"* 진단과 같은 결. *Controller/Game 객체에서 변수 줄이기 어려움* 이 *제약의 한계*. *해결 = GameController + Game 분리* 패턴.
+
+### 14. `BlackJackGame` 4 인스턴스 변수 (`pair`, `deck`, `outputView`, `inputView`) — *Controller god-object*
+
+```kotlin
+class BlackJackGame(
+    private val pair: BlackJackPair,
+    private val deck: Deck,
+    private val outputView: BlackJackOutputView,
+    private val inputView: BlackJackInputView,
+) {
+    fun setUp() { ... }
+    fun run() { ... }
+    fun eachPlayerHitOrNot() { ... }
+    private fun addDealerCard() { ... }
+    private fun setInitialPlayerCards(players) { ... }
+    private fun handlePlayerHit(player) { ... }
+}
+```
+
+→ **4 변수 + 6 메서드** — *BlackJackGame 가 *게임 진행 + 입출력 인터페이스 직접 의존**. PR #131·#132·#133 와 같은 결의 *Engine/Game god-object*. *Controller 가 입출력 + Game 이 도메인* 의 *명시적 분리*는 *Game(inputCallback, outputCallback)* 같은 *콜백 주입* 패턴.
+
+두루의 *GameController + Game 분리* 권고가 그 정공 — *Controller = 진입점 + Game 객체 호출, Game = 도메인 자기 진행*. *현재 BlackJackGame = Controller + Game 합쳐짐* — *책임 흡수*.
+
+### 15. `Hand.size(): Int` 메서드 + *isBlackJack 에 size 검증 부재 (못한 점 §1과 정합)*
+
+```kotlin
+class Hand {
+    private val cards = mutableListOf<Card>()
+    ...
+    fun size(): Int { return cards.size }
+}
+```
+
+→ **`Hand.size()` 메서드 존재 + Participant.isBlackJack 에서 사용 안 함**. *2장 검증* 가능했음. *`innerHand.size() == 2 && countAce() == 1 && countScoredTen() == 1`* 한 줄 추가가 *룰 invariant 강제*.
+
+### 16. `Dealer.getOpenedCard(): Card` — *공개 룰을 Dealer 메서드로 명시*
+
+```kotlin
+class Dealer : Participant() {
+    ...
+    fun getOpenedCard(): Card {
+        return innerHand.toList().first()  // ⚠ 첫 카드만 공개
+    }
+}
+```
+
+→ **`getOpenedCard()` = *첫 카드만 공개* 룰 메서드 노출**. *블랙잭 공개 룰 정확*. *Dealer.openedCards: List<Card>* 메서드면 *Player.openedCards: List<Card> = cards* 일관성 가능 (PR #132 환노 의 `getInitCard()` 다형성과 같은 결). *현재 Dealer만 getOpenedCard* — *Player 측 동일 메시지 부재 비대칭*.
+
+### 17. `BlackJackRule(participant)` factory function — *@Suppress("FunctionName") + 클래스와 동일 이름*
+
+```kotlin
+@Suppress("FunctionName")
+fun <T : Participant> BlackJackRule(participant: T): BlackJackRule<T> {
+    return when {
+        participant.isBust() -> Bust(participant)
+        participant.isBlackJack() -> BlackJack(participant)
+        else -> Stay(participant)
+    }
+}
+
+sealed class BlackJackRule<T : Participant> { ... }
+```
+
+→ **함수 이름 = 클래스 이름 (PascalCase) + @Suppress("FunctionName") 으로 lint 우회**. *Kotlin pseudo-constructor pattern* — *호출자는 `BlackJackRule(player)` 가 마치 생성자처럼 보임*. *invoke operator 의 대안* — *invoke 와 달리 confusion 명시 회피* (@Suppress 가 *고의 패턴* 명시).
+
+다만 *팩토리 함수 표준 어휘 (`BlackJackRule.from(participant)`, `BlackJackRule.of(participant)`)* 와 *다른 표현*. *Kotlin pseudo-constructor* 는 *드물지만 인정된 패턴* — Kotlin stdlib 의 *`buildList`, `MutableList<T>(...)`* 등이 비슷한 패턴. *블랙잭 도메인에서 정당화 가능*. PR #108·#133 의 *Card.invoke* 함정 회피 의도.
+
+### 18. `Stay` subtype 의 `else -> Score(...).compare(...)` — *순환 호출 가능성*
+
+```kotlin
+// Stay
+override fun compare(other: BlackJackRule<out Participant>): GameResult {
+    if (other is BlackJack) return GameResult.LOSE
+    if (other is Bust) return GameResult.WIN
+    return Score(participant).compare(Score(other.participant))
+}
+```
+
+→ **`other is Stay` 일 때 `Score(participant).compare(Score(other.participant))`** — *Stay vs Stay 비교 = 점수 비교*. *Score.compare = WIN/LOSE/DRAW 반환*. *BlackJackRule.compare → Score.compare* 호출 순서 명료. 순환 없음.
+
+다만 *Score.compare 가 GameResult 반환*이라 *BlackJackRule.compare 가 Score 의존*. *책임 분리 명확* — *상태 비교 분기 (BlackJackRule)* + *점수 비교 (Score)*. PR #131 (다이스 2단계) 의 *Score 객체 분리* 와 같은 결.
+
+### 19. `Player.canHit() = Score(this) < hitThreshold` — *Bust 도달 시 자동 false*
+
+```kotlin
+// Participant
+fun canHit(): Boolean = Score(this) < hitThreshold
+```
+
+→ **Score 가 21 이상이면 canHit = false** — *21 == hitThreshold 이면 canHit = false* — *Player threshold = 21, Dealer threshold = 17*. *Player 가 정확히 21 도달*하면 canHit = false (자동 STAY). *Bust (>21) 도 canHit = false*. *블랙잭 룰 정합*.
+
+다만 *블랙잭 (2장 21)* 은 *카드 받은 후 자동 STAY* 가 자연. *handlePlayerHit while (player.canHit())* 가 *블랙잭 도달 시 자동 종료* — 정확. *블랙잭 vs Stay 의 BlackJackRule 분리*는 *결과 계산 시* 만 의미.
+
+### 20. `BlackJackInputView` / `BlackJackOutputView` interface 미공개 — *추정 인터페이스*
+
+본 PR 내용은 `BlackJackGame` 이 interface 의존하나 *구체 코드 미공개*. 1단계 lotto 학습 + 두루 권고 반영 추정.
+
+### 21. `setInitialPlayerCards(players: List<Player>)` 가 *Player 만* — *Dealer 별도 분배*
+
+```kotlin
+fun setUp() {
+    pair.dealer.setInitialCard(deck)
+    setInitialPlayerCards(pair.players)
+    outputView.showInitialCards(pair)
+}
+```
+
+→ **Dealer 와 Players 분리 분배**. *PR #132 (환노) 의 *모든 참여자 forEach + 다형성** 과 *다른 트레이드오프* — *Dealer 와 Player 의 분배 차이 명시*. *현재 둘 다 setInitialCard 같은 메시지* → *분리 의의 모호*. *통일 가능*.
+
+또한 `setInitialCard(deck)` 가 *Participant.setInitialCard(deck)* 라 *Dealer / Player 동일 메서드*. *분리 호출* 의의 = *명시적 순서 표현 (Dealer 먼저)*. *논리적으론 동시 분배 가능*. *카지노 룰 = 딜러 먼저 1장, 플레이어 각 1장, 딜러 1장, 플레이어 각 1장* 도 있음 — *현재 코드는 모두 2장씩 한꺼번에*.
+
+## 리뷰어 의견 요지
+
+- **3 변수 제약 = 연습 도구, Controller/Game 에서는 절대 룰 X** — 두루 자가 답변: *"Controller 와 BlackJackGame 에서는 무지하게 힘듭니다. 맞추려다보면 어거지로 객체를 끼워넣는 방식이 될 수 있어요. 그래서 저도 왠만하면, Controller 와 BlackjackGame 부분에 대해서는 변수에 대한 제한에 대해서 별말을 하지 않았긴 합니다!"*. PR #133 (시아) 와 같은 결.
+- **GameController + Game 분리 = god-object 해결** — *Controller = 게임 객체.run() 호출자, Game = 게임 진행*. *여러 Game 을 실행시킬 수 있는 GameController* 의 *확장 안전성*.
+- **State (BlackJackRule) sealed class = 닫힌 계층 보장** — *외부 구현 차단 + 컴파일러 when exhaustive*. *sealed class vs sealed interface 차이* 학생 자가 학습.
+- **점수 계산 = Score 객체 분리** — *Participant 의 점수 계산 책임 누수 해소*. *Hand = 카드 관리, Score = 점수 계산*. PR #131 와 같은 결.
+- **`getEarnRate` 가 Bust 입장 `gameResult.sign`을 무시 = 시그니처 misleading** — *Bust 는 항상 -1.0*. *호출 흐름 보장*이 *런타임 의존*.
+- **논리적 오류 vs 비논리적 오류 자가 정의** — 학생 인용: *"논리적 오류는 사실 예외가 아닌데 오류 라는 워딩 때문에 예외라는 인식이 있는 것 같아요. 저는 개인적으로 논리적 오류라는 단어 대신 논리적 모순 이란 단어를 사용하고 싶어요."* *예외 처리 자가 학습 모범*.
+- **엘레강트 오브젝트 4.2 (체크 예외) + 2.2 (상태 없는 행동)** — 학생 자가 학습 + 본인 코드 적용.
+- **`isEqualTo` 별도 메서드 vs equals 재정의** — *data class 의 equals 자동 vs 도메인 의미 동등성* 트레이드오프. 학생 결정 합리.
+- **`Cards` / `State` 네이밍 자가 반영 (`Hand` / `BlackJackRule`)** — *책임을 이름으로 표현*.
+- **긴 변수명 > 모호한 짧은 이름** — 두루 자가 표현 (PR #131 다이스 와 같은 결).
+
+## 대표 인용
+
+**두루 (3 변수 제약 의 한계, BlackJackPair.kt):**
+> 맞아요...😅
+> 실제로 구현을 하면서 변수가 3개 미만으로만 규정을 하기는 정말 힘든 부분이 많습니다
+> 특히나, Controller 와 BlackJackGame 에서는 무지하게 힘듭니다.
+> 맞추려다보면 어거지로 객체를 끼워넣는 방식이 될 수 있어요
+> 그래서 저도 왠만하면, Controller 와 BlackjackGame 부분에 대해서는 변수에 대한 제한에 대해서 별말을 하지 않았긴 합니다!
+
+**두루 (GameController + Game 분리, BlackJackPair.kt):**
+> 해당 객체를 없앨 수 있는 방법은 한가지가 있긴 합니다
+> 이건 제가 이전에 남겼던 코멘트에서 살짝의 힌트를 얻어볼 수 있을 것 같아요
+> > `BlackjackGame.run()`으로 블랙잭 게임을 실행시켜보도록 하는 것은 어떨까요?
+>
+> ㄴ 이말은 BlackJackGame 이라는 Controller 역활을 하는 객체를 만들어보길 원했어요.
+> GameController 라는 것이 존재하고 해당 GameController 에서는 여러 게임들을 실행 시킬 수 있으며, 해당 Controller 에서는 `게임객체.run()`으로 실행이 가능하도록 한다!
+>
+> 현재처럼 한가지 Controller가 있는 경우라면 그 효과는 미비하지만, 여러 Controller들이 있고 여러 Controller에서 BlackJackGame을 한다고 할때, 위와 같이 작성을 해보면 입출력이 조금씩 다르지만 언제나 동일한 블랙잭 게임을 제공할 수 있다는 장점이 있어요.
+
+**두루 (점수 계산 분리 + 상태 인터페이스 진단, Participant.kt):**
+> 저도 같은 의견이네요. 이렇게 된 이유가 무엇일까요?
+> 저는 밀러의 구현을 보면, 점수 계산을 플레이어가 하는 부분에서 걸리는군요.
+> 점수 계산기 or 규칙을 판별 (즉, 게임 매너저 <- 플레이어의 점수 or 결과를 계산해주는 역활)이 있다면 해결이 될 수도 있을 것 같군요💪
+
+**학생 자가 학습 (엘레강트 오브젝트 4.2 + 예외 처리 자가 정의, Application.kt:16):**
+> 엘레강트 오브젝트의 4.2 체크 예외만 던지세요 (https://jessyt.tistory.com/163)
+> 부분에서 딱 한 번만 복구하세요 라는 내용이 있습니다. 이 내용을 토대로 저도 이번 코드에 적용해 보았어요!
+>
+> 엘레강트 오브젝트의 내용 자체는 완전 동의하지만 막상 코드로 구현하게 되니 모양이 예쁘지 않게 나오고, 던져진 예외에 맞춰서 다른 동작을 수행하려 하게 된다면 더욱 코드가 길어질 것 같다는 생각이 들었어요.
+
+**학생 자가 학습 (논리적 오류 vs 비논리적 오류 자가 정의, GameController.kt:26):**
+> 논리적 오류의 정확한 정의는 **프로그램이 강제 종료되지도 않고 의도대로 동작하지도 않는 상황** 이라고 알고 있어요
+> 이를 토대로 간단하게 세울 수 있는 저만의 기준을 공유드릴게요.
+>
+> 논리적 오류 : 잘못된 사용자 입력 값, http요청 시 예상과 다른 페이지 반환 등 프로그래머의 의도대로 동작하지 않지만 예외는 던져지지 않는 상황
+> 비논리적 오류 : 이외의 모든 프로그래머의 잘못된 사용으로 인한 예외
+>
+> 즉 논리적 오류는 원래 예외가 던져졌어야 할 상황에 예외가 던져지지는 않은 것이라고 할 수 있겠네요.
+> 논리적 오류는 사실 예외가 아닌데 오류 라는 워딩 때문에 예외라는 인식이 있는 것 같아요.
+> 저는 개인적으로 논리적 오류라는 단어 대신 논리적 모순 이란 단어를 사용하고 싶어요.
+
+**학생 자가 답변 (sealed class vs sealed interface 자가 학습, Stay.kt):**
+> sealed class 또는 sealed interface를 사용하게 된다면 상속, 또는 구현을 막을 수 있다는 장점이 있습니다! (한 패키지에서만 구현 가능)
+> 두루가 말씀하신 *한 곳에서 규칙에 대해서 볼 수 있을 것 같다* 라는 부분은 저는 패키지가 그 역할을 충분히 다하고 있다고 생각해요.
+> 저는 오히려 한 파일에서 몰아 보면 더 헷갈리더라고요.
+>
+> 현재의 BlackJackRule (이전 State 인터페이스) 은 여러 클래스에 범용적으로 사용하게끔 만든 인터페이스가 아니에요. (반대의 예시로는 이전에 설명드린 NullableRetry, ThrowableRetry 등이 있겠네요). 그렇다면 클라이언트의 악의적 구현을 막기 위해 예방 차원에서 sealed 키워드를 붙이는게 맞다고 생각했어요.
+>
+> 그렇다면 여기서 고민인 것이 sealed class vs sealed interface 에요.
+> ...
+> 제가 곰곰이 생각해보았을 때, BlackJackRule은 인터페이스보다는 추상 클래스가 더 어울리다고 생각했어요.
+> 이유는 sealed 키워드로 상속을 관리한다는 것은 곧 *클래스 계층 구조를 명확히 한다* 와 동일하다고 생각했기 때문이에요
+>
+> 또한 sealed로 한 패키지 내에서 관리한다는 것은 인터페이스처럼 높은 자유도를 설정할 필요도 없기 때문에,
+> 디폴트 프로퍼티를 설정할 수 있는 추상 클래스를 선택하는 것이 적절하다고 생각했어요
+
+**학생 자가 답변 (isEqualTo 별도 메서드 이유, Score.kt:50):**
+> 현재는 외부에서 오버로딩한 compareTo 연산자를 사용하고 있어요.
+> 이 말은 즉 모양만 다를 뿐 사실 equals 연산자를 사용하는 isEqualTo 가 외부에서 사용될 여지가 있다고 생각했어요
+>
+> 사실 equals를 재정의하려고도 생각했어요.
+> 하지만 hashcode도 재정의 해야하며,
+> 예제 코드로 대략 보았을 때 코드가 지저분하다고 생각하여 그냥 이름만 다른 isEqualTo 라는 메소드를 제작하는 것이 더 낫겠다고 생각이 들었네요.
+
+**학생 자가 답변 (3 변수 제약 자가 회의, BlackJackPair.kt:3):**
+> 컨트롤러에서 입력받은 플레이어와 딜러를 묶는 일급 컬렉션을 생성했어요!
+> 여기에 사실 deck 도 넣고싶었지만 인스턴스 변수는 3개 미만이어야 해서....
+>
+> 그런데 의문이 가는 점이 있어요.
+> 다른 모든 부분은 인스턴스 변수를 3개 미만으로 줄였지만, 컨트롤러와 블랙잭 게임 객체는 view를 주입받아 어떻게 하더라도 3개 미만으로 못 줄이겠더라고요..
+>
+> 굳이 3개 미만으로 줄인다면 view를 주입하는 것이 아닌 직접 blackjackView에 접근하도록 해야 할 것 같아요.
+>
+> https://jessyt.tistory.com/159
+> 엘레강트 오브젝트의 해당 내용을 본다면 이는 잘못된 방법 같아요.
+
+**학생 자가 학습 (Score 객체 분리, Participant.kt):**
+> 이 부분에 대해 한참을 고민했어요.
+> 결국 Score 객체를 따로 만들어 점수 계산을 따로 처리하도록 만들었어요.
+> 이렇게 구현하니 State에서 점수계산을 하는 부분 또한 Score로 옮길 수 있게 되어 일석이조가 되었네요!
+
+## 얻은 교훈
+
+1. ***`sealed class BlackJackRule<T : Participant>` = State 패턴 정공***. *sealed 키워드 = 닫힌 계층 + 외부 구현 차단 + 컴파일러 when exhaustive 검사*. *제네릭 `<T : Participant>` 로 Player/Dealer 타입 구분*. PR #152 (모찌 2단계) 의 *interface State* 보다 *sealed* 가 정공. **MCP 룰 후보 — `state-machine-without-sealed`** 가 *interface 인 경우 sealed 권고*.
+
+2. ***`BlackJackRule(participant)` factory function (`@Suppress("FunctionName")`)*** — *Kotlin pseudo-constructor pattern*. *클래스와 동일 이름 함수* + *@Suppress 로 lint 의도 명시*. *호출자는 생성자처럼 사용*. PR #108·#133 의 *invoke 함정* 회피 + *팩토리 함수 표준 어휘 (`.of()`, `.from()`) 의 대안*.
+
+3. ***`if (other is X)` 분기 = sealed 의 when exhaustive 미활용***. *if-return* 은 *새 subtype 추가 시 누락 가능*. *`when (other) { is BlackJack → ..., is Bust → ..., is Stay → ... }` exhaustive 가 컴파일러 보장*. *sealed 의 진짜 장점 활용*.
+
+4. ***Score 객체 분리 = 점수 계산 응집***. *Participant.score() = Score(cards)* 메시지가 *Tell-Don't-Ask*. *Hand = 카드 관리, Score = 점수 계산* 책임 분리. *학생 자가 학습 + 두루 권고 반영 모범*. PR #131 (다이스) 와 같은 결.
+
+5. ***Ace 처리 = `while (sum > 21 && aceCount > 0) sum -= 10`*** — *Ace 11 기본 + 차감 패턴*. *Ace 다수 정확 (각 Ace 11→1 점진적)*. PR #128·#135·#108·#131·#132 와 같은 결의 Ace 정공.
+
+6. ***Bust 입장 `getEarnRate(gameResult)` = 인자 무시 = 시그니처 misleading***. *Bust 는 항상 -1.0* 정합이지만 *함수 시그니처가 호출자에게 misleading*. *세 subtype 시그니처 통일 vs Bust 안전성* 트레이드오프. *오버라이드 호환성*과 *호출 의미 명료성* 의 균형.
+
+7. ***`Player(name, bettingAmount: Int = 0)` default = 0 + require > 0 모순***. *default 값이 invalid* = *명시적 호출 강제 안 됨*. *default 제거*가 *컴파일 타임 강제*. PR #131 (다이스) 의 기본 생성자 지양 권고와 같은 결.
+
+8. ***3 변수 제약 = 연습 도구, Controller/Game 에서는 너무 얽매이지 말 것***. 두루 자가 답변: *"맞추려다보면 어거지로 객체를 끼워넣는 방식이 될 수 있어요"*. 학생 자가 회의: *"3개 미만으로 줄인다면 view를 주입하는 것이 아닌 직접 blackjackView에 접근하도록 해야 할 것 같아요. 엘레강트 오브젝트의 해당 내용을 본다면 이는 잘못된 방법 같아요."* PR #133·#132 와 같은 결.
+
+9. ***GameController + Game 분리 = god-object 해결 정공***. *Controller = 진입점 + Game.run() 호출, Game = 도메인 자기 진행*. *현재 BlackJackGame = Controller + Game 합쳐짐*. *분리 시 GameController 가 여러 Game 실행 가능 + 입출력 분리*.
+
+10. ***엘레강트 오브젝트 자가 학습 + 본인 코드 적용 = 학습 모범***. *4.2 체크 예외 → ThrowableRetry 적용*, *2.2 상태 없는 행동 → BlackJackResult 책임 재배치*. *외부 자료 → 본인 사고 변동 → 코드 후속 반영* 흐름. 학생이 *"엘레강트 오브젝트의 내용 자체는 완전 동의하지만 막상 코드로 구현하게 되니 모양이 예쁘지 않게 나오고"* 의 *책 원칙 vs 현실 코드 트레이드오프 인식*.
+
+11. ***논리적 오류 vs 비논리적 오류 자가 정의 = 예외 처리 사고 모범***. *학생이 "논리적 오류 = 예외 던져지지 않음 + 의도대로 동작 X" vs "비논리적 오류 = 예외 발생"* 자가 정의. *"논리적 오류" 워딩 자체에 의문 → "논리적 모순" 대체어 제시*. *예외 처리의 본질에 대한 자가 사고 모범*.
+
+12. ***sealed class vs sealed interface 학생 자가 학습***. *abstract class = "고장난 부분 채우라"* (말리빈 1단계 진단) + *sealed = "패키지 내에서만 상속 가능"*. *BlackJackRule = 범용 인터페이스 아니라 닫힌 계층 → sealed*. *abstract class 선택 이유 = 디폴트 프로퍼티*. **학생 자가 결정 + 두루 인정**.
+
+13. ***`isEqualTo` 별도 메서드 vs equals 재정의 = data class 의 자동 equals 와 도메인 의미 불일치 회피***. *Score data class 의 equals = cards 리스트 동등성* vs *블랙잭 도메인 의미 = value 동등성*. *학생의 별도 메서드 결정 = 합리적 회피*. *Kotlin 어휘 non-standard 비용 vs 도메인 의미 명료성* 트레이드오프.
+
+14. ***네이밍 = 책임 표현***. *`Cards → Hand` (플레이어 손패)*, *`State → BlackJackRule` (블랙잭 규칙)*. *이름이 책임을 표현* — *호출자가 의미 추측 X*. 두루 자가 표현: *"State가 담당하고 있는 것은 블랙잭의 규칙이군요. 해당 객체가 담당하고 있는 기능에 맞게 네이밍을 수정해볼 수 있을 것 같군요"*. PR #128·#135·#125 와 같은 결.
+
+15. ***`Score.compare(other)` 의 *3 분기 중복 + else throw* = 도달 불가 명시 = Kotlin 어휘 부재***. *`Score.compareTo`* 가 *trichotomy 보장* (Int 비교 본질) 이므로 *>, <, == 3 분기 후 else 도달 불가*. *throw 도 도달 불가 명시* 패턴이지만 *컴파일러 보장 부재*. *간결화 = `when { > → WIN, < → LOSE, else → DRAW }`*.
+
+16. ***`Hand.isBlackJack` 의 *size == 2 검증 부재* = 룰 invariant 누수***. *countAce + countScoredTen == 2* 가정 + *추가 카드 검증 X*. *실제 게임 흐름에선 정합* (블랙잭 판정은 첫 2장 후만). *Hand 자체 invariant 강제 X* — *호출 흐름 의존*. *명시적 size 검증* 이 *invariant 보장*.
+
+17. ***`Score(Participant)` 보조 생성자 = 순환 의존 신호***. *Score → Participant + Participant → Score* 양방향. *Score 단순 점수 객체 + Participant 가 자기 카드로 Score 생성* 단방향이 정공. *학생 의도 = 호출 편의*. *순환 비용 vs 호출 편의* 트레이드오프.
+
+18. ***`NullableRetry` / `ThrowableRetry` interface = AOP-like 추상화 정공***. *예외 발생 시 재시도 로직* 의 *공통 추상화*. *Kotlin interface + 람다 인자* 로 *재사용 가능 retry 패턴*. *학생 자가 학습 + 본인 도메인 적용 모범*. PR #133 (시아) 의 *EventListener/EventProvider* 와 같은 결의 인터페이스 추상화.
+
+19. ***칭찬 위주 리뷰 + 깊은 메타 질문 + 학생 자가 학습 풍부 = PR #131 다이스와 같은 결***. 두루의 *🥳/👍/💪* 다수 + *"여기서 질문"* 메타 질문 위주. *깊은 안티패턴 진단 < 자가 학습 기회 제공*. *학생 자가 답변 + 외부 자료 학습 + 코드 적용* 흐름이 그 보상.
+
+20. ***`@Suppress("FunctionName")` 의 명시적 lint 우회 = 의도 패턴 명시***. *PascalCase 함수* 는 *Kotlin lint warning*. *@Suppress 로 *고의 패턴* 명시* = *호출자에게 *이건 의도된 pseudo-constructor* 신호*. *lint 무시 vs 의도 명시* 의 정공.