oh-my-oop 0.2.0

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

@@ -0,0 +1,460 @@
+# PR #90 — [블랙잭 2단계] 케이엠 미션
+
+- **Reviewee:** [@kmkim2689](https://github.com/kmkim2689)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/90
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @Gyuil-Hwnag (두루)
+- **라인 코멘트:** 22 스레드 / 30 코멘트 — *학생 자가 답변 매우 풍부* (특히 *value class vs data class vs class* 1000자 답변)
+
+## 잘한 점 (설계 관점)
+
+- **`Money @JvmInline value class` + 4가지 연산자 오버로딩 (`plus`/`minus`/`times`/`unaryMinus`)** — *Kotlin value class 의 완전 활용*. *원시 박싱 없음 + 타입 안전 + 모든 산술*. PR #131·#132·#136 의 *value class* 와 *기능 풍부도 최고 수준*.
+
+  ```kotlin
+  @JvmInline
+  value class Money(val amount: Int = 0) {
+      operator fun plus(other: Money): Money = Money(this.amount + other.amount)
+      operator fun minus(other: Money): Money = Money(this.amount - other.amount)
+      operator fun times(times: Double): Money = Money((this.amount * times).toInt())
+      operator fun unaryMinus(): Money = Money(-amount)
+
+      companion object {
+          fun from(bettingAmount: Int): Money {
+              require(bettingAmount >= MINIMUM_MONEY_AMOUNT) { ... }
+              return Money(bettingAmount)
+          }
+      }
+  }
+  ```
+
+  *베팅 금액 (factory `from` + invariant 검증) + 수익 금액 (default 0 + 자유 산술)* 두 용도 자가 분리. *학생의 1000+자 자가 답변 = value class vs data class vs class 자가 학습 모범*.
+- **`EarningRate` enum + `BLACKJACK(1.5) / WIN(1.0) / LOSE(-1.0) / BURST(-1.0) / DRAW(0.0)`** — *수익률 룰 enum 응집*. *BLACKJACK / BURST 별도 멤버* — *현재 LOSE = BURST = -1.0 같지만 의미 분리*. PR #132 (환노 2단계) 의 *GameResult enum + earningRate* 와 같은 결.
+- **`Players.of(...)` 정적 팩토리 + `zip` 함수 활용** — 두루 자가 칭찬: *"`zip`함수의 활용 좋습니다~👍"*. *Kotlin stdlib 함수 활용 모범*. *팩토리 메서드 + 람다 인자*로 *Players 생성 시점에 의존성 주입*:
+
+  ```kotlin
+  fun of(
+      playerNames: List<String>,
+      playerMoneyAmount: List<Int>,
+      onInputDecision: (String) -> String,
+      generateCard: () -> Card?,
+  ): Players {
+      return playerNames.zip(playerMoneyAmount) { name, amount ->
+          Player.of(
+              gameInfo = GameInfo(name, Money.from(amount)),
+              onInputDecision = { onInputDecision(name) },
+              generateCard = generateCard,
+          )
+      }.run { Players(this) }
+  }
+  ```
+
+- **`Card.toString` override = View 책임 분리 자가 학습** — 두루 권고 *"Cards의 toString()을 오버라이딩을 한다면 Output에 좀 더 유연하게 대응을 할 수 있을것 같다"* 후속 반영. 학생 자가 인용: *"toString() 메소드를 오버라이드 해본 경험이 없어서 적용할 생각을 하지 못하였던 것 같습니다! 말씀하신 대로 수정을 진행해보니 뷰 측에서 형식을 일일이 지정해주지 않고 toString() 메소드 호출만으로 원하는 형식으로 정보를 출력할 수 있게 되었습니다!"*
+- **테스트 픽스처 + Fixtures.kt 활용** — 두루 권고 + 학생 자가 반영. *공통 테스트 데이터 추출*. *fixture = 테스트 가독성 + 재사용*.
+- **`@CsvSource` 활용** — 두루 자가 칭찬: *"CsvSource기능의 활용 정말 좋습니다~👍"*. *Parameterized 테스트 + 데이터 주도 테스트* 어휘.
+- **빈 입력 재시도 자가 구현** — 두루 자가 칭찬: *"빈칸 입력시 재 입력을 받도록 해주셨군요~👍"*. *입력 retry 패턴*.
+- **`Money.from(bettingAmount)` 정적 팩토리 + invariant 검증** — *베팅 금액 ≥ 1* 검증. *Player.of / Players.of* 와 함께 *팩토리 패턴 일관성*.
+- **`Money(0)` default = 수익 시작값** — 두루 권고 후속 *"0으로 하드코딩 하는 방법도 있지만, Money 객체에 Default Value를 넣어주는 방식"* 반영. *베팅 금액 (1 이상)* vs *수익 금액 (0 default + 음수 허용)* 두 의미 *생성 방식 분리* (factory vs primary constructor + default).
+- **함수 단일 책임 분리 자가 반영** — 두루 권고 후속. *Judge 의 winning 판정 함수* `isPlayerBurst` / `isPlayerBlackjack` / `isPlayerWin` / `isPlayerLose` 각각 분리.
+- **`Player.of(...)` 정적 팩토리 + 초기 카드 분배 응집** — *생성 시점에 2장 분배*:
+
+  ```kotlin
+  fun of(gameInfo, onInputDecision, generateCard): Player {
+      repeat(INITIAL_DRAW_COUNT) {
+          gameInfo.addCard(generateCard() ?: throw ...)
+      }
+      return Player(gameInfo, onInputDecision)
+  }
+  ```
+
+  *초기 카드 분배 + Player 생성 응집*. PR #132 (환노) 의 *Player(name, Hand)* 어색함 회피 + *팩토리 함수 표준 어휘*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Judge.isPlayerWin` / `isPlayerLose` — *복잡한 분기 + 룰 부정확 신호*
+
+```kotlin
+private fun isPlayerWin(
+    playerDifference: Int,
+    dealerDifference: Int,
+): Boolean =
+    dealerDifference != BLACKJACK_DIFFERENCE && playerDifference == BLACKJACK_DIFFERENCE ||
+        dealerDifference < BLACKJACK_DIFFERENCE && playerDifference >= BLACKJACK_DIFFERENCE ||
+        playerDifference < dealerDifference
+
+private fun isPlayerLose(
+    playerDifference: Int,
+    dealerDifference: Int,
+): Boolean =
+    playerDifference < BLACKJACK_DIFFERENCE && dealerDifference >= BLACKJACK_DIFFERENCE ||
+        dealerDifference < playerDifference
+```
+
+두루 (Judge.kt — 미해결, 두 번 코멘트): *"해당 내용의 조건들은 새로운 요구사항이 생길때마다 로직이 복잡하게 꼬일 수도 있을것 같은데, 결과를 좀더 복잡하지 않도록 해보는 방법을 고민해봐도 좋을 것 같다는 생각이 듭니다!🤔"*
+
+→ **승패 판정 로직이 *21 - sumOfCards = difference* 변환 후 *부호 + 크기 비교* 다중 분기**. *`difference < 0`* = Bust, *`difference == 0`* = 21 도달, *`difference > 0`* = 21 미만. *직관적이지 않음* — *호출자가 difference 의 *의미* 추측 필요*.
+
+직접 점수 비교 표현:
+- *`isBust(score)` = score > 21*
+- *`isPlayerBlackjack(player)` = score == 21 && cards.size == 2*
+- *`compareScores(player, dealer)`* = *Bust → Lose, Dealer Bust → Win, 점수 비교*
+
+*PR #132·#136·#108·#133·#152 의 *상태별 메시지 + Tell-Don't-Ask** 와 비교: PR #90 은 *Judge 정적 분기 + difference 변환* — *Tell-Don't-Ask 미달*. *Judge = 정적 헬퍼* — *Participant.compare(other) 메시지가 정공*.
+
+### 2. `Judge.getEarningRate` — *4 단계 if-when 분기 + Judge가 도메인 룰 전부 알고 있음*
+
+```kotlin
+class Judge(val dealer: GameInfo, val players: List<GameInfo>) {
+    fun getDealerIncome(): Money { ... }
+    fun getPlayersIncome(): List<Money> { ... }
+    private fun getSinglePlayerIncome(playerGameInfo: GameInfo): Money { ... }
+    private fun getEarningRate(dealerDifference: Int, playerDifference: Int, playerGameInfo: GameInfo): EarningRate {
+        return when {
+            isPlayerBurst(playerDifference, dealerDifference) -> EarningRate.BURST
+            isPlayerBlackjack(playerGameInfo, dealerDifference) -> EarningRate.BLACKJACK
+            isPlayerWin(playerDifference, dealerDifference) -> EarningRate.WIN
+            isPlayerLose(playerDifference, dealerDifference) -> EarningRate.LOSE
+            else -> EarningRate.DRAW
+        }
+    }
+    ...
+}
+```
+
+→ **Judge = 정적 헬퍼 + 모든 블랙잭 룰 판정 책임**. *Tell-Don't-Ask 위반*:
+- *Judge 가 player.gameInfo.cards.take(2).sumOf* 같은 *플레이어 카드 직접 접근*
+- *Judge 가 difference 계산 + 모든 분기 판정*
+- *Player/Dealer/GameInfo 는 자기 결과 알리는 메시지 부재*
+
+*PR #132 (환노) 의 *Participants.compareScores(other)** / *PR #136 (밀러) 의 *BlackJackRule.compare(other)** 와 *반대 트레이드오프*. PR #90 은 *Judge god-object* 변형.
+
+다만 *Judge 자체*가 *블랙잭 룰의 응집 객체*면 *Judge.judge(player, dealer): EarningRate* 메시지가 *내부 분기 응집*. *Participant.compare(other)* 다형성보다 *Judge = 룰 전담*이 *책임 분리 다른 표현*. 트레이드오프.
+
+### 3. `isPlayerBlackjack(playerGameInfo, dealerDifference)` — *블랙잭 + 딜러 비블랙잭 결합*
+
+```kotlin
+private fun isPlayerBlackjack(playerGameInfo: GameInfo, dealerDifference: Int): Boolean =
+    playerGameInfo.cards.take(INITIAL_CARD_SIZE).sumOf { it.value } == CRITERIA_NUMBER &&
+        dealerDifference != BLACKJACK_DIFFERENCE
+```
+
+→ **`isPlayerBlackjack` 조건 = *플레이어 첫 2장 21 + 딜러 비블랙잭***. *플레이어 블랙잭 자체* 가 아니라 *블랙잭 + 딜러 비블랙잭 시 EarningRate.BLACKJACK 적용*. *이름 = 의미 모순* — *isBlackjack* 아니라 *`shouldApplyBlackjackBonus`*.
+
+또한 *`playerGameInfo.cards.take(INITIAL_CARD_SIZE).sumOf { it.value }`* — *첫 2장 점수*. 현재 *Set<Card>* 라 *first 2가 *입력 순서대로 보장 안 됨* (Set 의 iteration order = LinkedHashSet 이면 보장). *2단계 게임에서 카드 추가 순서 = 초기 2장 → Hit 추가* 라면 *take(2) = 초기 2장*. 다만 *Set의 의미상 순서 보장 X* — *함정*. PR #136 (밀러) 의 *Hand.size 검증 부재* 와 같은 결.
+
+### 4. `Player.checkBurst` — *MAXIMUM_CARD_TOTAL = 21 == Bust 기준 vs 도달 기준 혼동*
+
+```kotlin
+private fun checkBurst(): PickingState {
+    if (gameInfo.sumOfCards >= MAXIMUM_CARD_TOTAL) {
+        return PickingState.STAND
+    }
+    return PickingState.HIT
+}
+
+companion object {
+    private const val MAXIMUM_CARD_TOTAL = 21
+    ...
+}
+```
+
+→ **`>= 21` 이면 STAND** — *21 == 도달 + 21 초과 = Bust* 둘 다 STAND 로 동작. *MAXIMUM_CARD_TOTAL = 21* 이름이 *Bust 기준 (> 21)* 인지 *도달 기준 (== 21)* 인지 모호. *이름 = `BLACKJACK_SCORE` / `MAX_VIABLE_SCORE`*가 *의미 명료*.
+
+또한 *checkBurst 가 STAND 반환* = *Burst 도 STAND 로 같은 상태로 흡수*. *블랙잭 도메인에서 Bust 와 Stand 는 다른 상태*. *PickingState* enum 에 *BURST 별도 멤버* 필요 (못한 점 §5).
+
+### 5. `PickingState` enum 의 *HIT / STAND* 2 멤버 — *BURST 상태 부재*
+
+```kotlin
+// PickingState.kt (추정, 코드 미공개)
+enum class PickingState { HIT, STAND }
+```
+
+→ **`PickingState` 가 *입력 의도* (HIT/STAND) + *Player 자기 상태* (Bust 도달) 의 두 의미 혼재**. *`Player.checkBurst()` 가 STAND 반환* = *Bust 도 STAND 으로 흡수*. *Bust 와 Stand 의 의미 차이 (Bust = 무조건 패배, Stand = 점수 비교)* 가 *enum 에서 표현 안 됨*. *추가 BURST 멤버* 또는 *별도 State enum*.
+
+PR #132·#136·#152 의 *상태 객체 분리 (Bust / Stay / Blackjack)* 와 *반대 트레이드오프*. PR #90 은 *액션 + 상태 enum 통합 시도 + 룰 표현 부족*.
+
+### 6. `GameInfo.cards: Set<Card>` — *순서 보장 부재 + 중복 차단*
+
+```kotlin
+class GameInfo(
+    val name: String,
+    val moneyAmount: Money = Money(),
+    cards: Set<Card> = emptySet(),
+) {
+    private val _cards: MutableSet<Card> = cards.toMutableSet()
+    ...
+}
+```
+
+→ **`Set<Card>` 사용 의의 = *카드 중복 방지***. *블랙잭 도메인 = 한 덱에서 같은 카드 2장 안 나옴* — *Set 정합*. 다만:
+
+1. **`Set.iteration order` = LinkedHashSet 보장만 (default), HashSet 은 보장 X** — `toMutableSet()` 가 *LinkedHashSet* 반환 (Kotlin 표준). 정합.
+2. **`cards.take(2)` = 초기 2장** — Set 도 iteration order 보장 (LinkedHashSet)이면 *추가 순서대로*. PR 의 *isBlackjack* 분기 의존.
+3. **`Set` 이 *Card 중복 안 됨* 보장** — *카드 동등성 = data class equals (rank + suit)*. *같은 카드 두 번 들어가면 Set 차단* — 도메인 invariant.
+
+다만 *손패 = 카드 순서가 의미 있을 수 있음* (블랙잭 룰 자체는 무관). *List vs Set* 트레이드오프 — *Set 선택 합리*. 다만 *take(2)* 같은 *순서 의존 코드*가 *함정*.
+
+### 7. `Player(gameInfo, onInputDecision: () -> String)` — *람다 인자가 Player 멤버*
+
+```kotlin
+class Player(
+    val gameInfo: GameInfo,
+    val onInputDecision: () -> String,
+) : Participant() { ... }
+```
+
+→ **Player 가 *입력 콜백을 멤버로 보유***. *Tell-Don't-Ask*: *Player 가 자기 의사 결정 = 콜백 호출*. *Player 가 자기 손패를 보고 더 뽑을지 결정* 의도 표현. PR #132 (환노 2단계) 의 *고차함수 시도* 와 같은 결.
+
+다만 *콜백 = View 의존*. *Player 가 View 콜백 보유 = 도메인 → View 결합*. *Player 가 자기 상태 + 외부 입력 분리* 는 *EventProvider interface* (PR #133) 처럼 *interface 의존성 주입*. *람다 인자 vs 인터페이스* 트레이드오프.
+
+또한 *`onInputDecision: () -> String`* 이 *String 반환* — *PR #132 의 *raw String vs ActionType 토론** 과 같은 결. *View가 사용자 의도 표현* (ActionType) 이면 *`onInputDecision: () -> PickingState`* 가 *도메인 어휘*. *현재 String 반환*은 *Player 가 String → PickingState 변환* 책임 보유.
+
+### 8. `Players` 의 *MIN = 2 / MAX = 8* — *최소 2명 강제 의문*
+
+```kotlin
+companion object {
+    private const val MINIMUM_NUMBER_OF_PLAYERS = 2
+    private const val MAXIMUM_NUMBER_OF_PLAYERS = 8
+    private val PLAYER_NUM_RANGE = MINIMUM_NUMBER_OF_PLAYERS..MAXIMUM_NUMBER_OF_PLAYERS
+    ...
+}
+```
+
+→ **`MIN = 2` = 최소 2명 강제** — *블랙잭 = 1 인 게임 가능 (혼자 vs 딜러)*. *카지노 도메인 = 1 인 이상*. *학생 결정 근거 부재*. PR #131·#132·#133 의 *MIN = 1* 와 다른 트레이드오프.
+
+또한 *MAX = 8* — *카지노 표준 = 6~7명*. *프로그래밍 요구사항* 의 *최대 인원* 가정. *도메인 룰 vs 학생 가정* 모호.
+
+### 9. `Player.drawCardsUntilStand` — *재귀 vs 반복* 미명시
+
+```kotlin
+override fun drawCardsUntilStand(
+    generateCard: () -> Card?,
+    printCards: (GameInfo) -> Unit,
+) {
+    val pickingState = drawSingleCard(generateCard)
+    printCards(gameInfo)
+    determineContinuation(pickingState, generateCard, printCards)
+}
+```
+
+→ **`determineContinuation` 가 재귀 호출 추정**. *PR #133 (시아) 의 tailrec* 같은 *명시적 재귀*인지 *while loop* 인지 *코드 미공개*. *재귀 시 stack overflow 가능성* 또는 *tailrec 보장*.
+
+### 10. `Judge` 내부 `BLACKJACK_DIFFERENCE = 0` — *추상화 우회 신호*
+
+```kotlin
+companion object {
+    private const val BLACKJACK_DIFFERENCE = 0
+    private const val INITIAL_CARD_SIZE = 2
+    private const val CRITERIA_NUMBER = 21
+}
+```
+
+→ **`difference = 21 - score`** 변환 + *`difference == 0` = 21 도달, difference < 0 = Bust, difference > 0 = 21 미만*. *직관적 점수 비교 (>=, ==, > 21)* 대신 *difference 변환*. *추가 변환 단계* = *코드 가독성 ↓*. *score 직접 비교*가 자연.
+
+학생의 *difference* 변환 의도 = *동일 비교 표현 (`difference == 0` 둘 다)* 일 가능성. 다만 *Bust 분기*가 *difference < 0* — *0 미만 == Bust* 가 *직관 위반*.
+
+### 11. `Players` 부 생성자 vs 팩토리 메서드 혼재 — 학생 자가 답변
+
+```kotlin
+class Players(val value: List<Player>) {
+    init { ... }
+    companion object {
+        fun of(...): Players { ... }
+    }
+}
+```
+
+두루 (Players.kt:29 — 미해결): *"추가적으로 Players 함수로 팩토리 함수로 인스턴스를 생성하도록 설정해두셨는데, 일부 테스트코드에서 부 생성자로 인스턴스를 생성하도록 하는 코드들이 있어서 그렇게 작성하신 이유가 있을까요??🤔"*
+
+학생 답변: *"객체에 대한 동작의 테스트를 진행하고자 할 때, 복잡한 로직들을 집어넣어야 하는 정적 팩토리 메소드보다는 이미 데이터가 만들어진 상태에서 테스트를 진행하는 것이 더욱 손쉬운 테스트 진행에 도움이 될 것이라고 생각하였습니다!"*
+
+→ **테스트 vs 프로덕션 호출 방식 분리**. *프로덕션 = factory* / *테스트 = primary constructor 직접*. *Player.of 같은 복잡한 분배 로직 우회 + 사전 상태 주입*. *테스트 가독성 + Player 동작 격리* 의도. *접근성 트레이드오프*.
+
+### 12. `Money.from` factory vs primary constructor `Money(0)` — 학생 자가 답변 풍부
+
+학생 1000+자 자가 답변 (요약): *"베팅 금액 (검증 필요) = factory `from`, 수익 금액 (음수 허용 + 검증 불필요) = primary constructor + default"*. 두루 권고 *"Default Value"* 반영. *value class 한계 = abstract class 상속 불가* 자가 인식 + *Bet/Profit 분리 시도 후 통합 결정*. **학생 자가 학습 + 결정 근거 명시 모범**.
+
+다만 **`Money(0)` primary constructor 노출** = *호출자가 검증 우회 가능* (`Money(-1000)` 같은 호출). *value class 의 invariant 강제 부재*. *factory only 정공* — `Money.from(bettingAmount: Int)` + `Money.zero()` 두 factory.
+
+### 13. `EarningRate.BURST(-1.0)` vs `LOSE(-1.0)` — *같은 값 두 멤버*
+
+```kotlin
+enum class EarningRate(val rate: Double) {
+    BLACKJACK(1.5),
+    WIN(1.0),
+    LOSE(-1.0),
+    BURST(-1.0),
+    DRAW(0.0),
+}
+```
+
+→ **`LOSE` 와 `BURST` 가 *같은 rate (-1.0)***. *의미 분리 (Bust = 무조건 패배, Lose = 점수 비교 패배)*는 합리. *현재 코드 = 둘 다 -1.0* 이므로 *수익률 계산 차이 0*. *향후 BURST 차별 (예: 2단 패널티)* 가능성 대비.
+
+다만 *`Judge.getEarningRate` 분기에서 BURST 우선 → LOSE fallthrough*: *플레이어 Bust → BURST 반환*, *Bust 아닌 패배 → LOSE 반환*. *분기 명시* 정공. *EarningRate.BURST 노출 자체는 도메인 의미 분리* — *수익률 계산은 동일*.
+
+### 14. `Judge(dealer: GameInfo, players: List<GameInfo>)` — *Player 대신 GameInfo 인자*
+
+```kotlin
+class Judge(
+    val dealer: GameInfo,
+    val players: List<GameInfo>,
+) { ... }
+```
+
+→ **Judge 가 *Player/Dealer 인스턴스가 아닌 GameInfo 인자***. *GameInfo = 공통 인터페이스*. *Player.gameInfo* 와 *Dealer.gameInfo* 분리 후 *Judge 가 GameInfo 만 받음* — *Player/Dealer 의 행동 메서드 미접근*. *Tell-Don't-Ask 의 *행동 메시지* 호출 불가*.
+
+*Judge.dealer.sumOfCards* 같은 *데이터 추출* 만 가능 — *Player vs Dealer 다형성 활용 X*. *Participant 추상화 후 Player/Dealer 인자*가 정공.
+
+### 15. `Player.onInputDecision()` 호출 — *PickingState.entries.find* 의 String 매핑
+
+```kotlin
+override fun drawSingleCard(generateCard: () -> Card?): PickingState {
+    val inputDecision = onInputDecision()
+    val pickingState =
+        PickingState.entries.find { it.value == inputDecision }
+            ?: throw IllegalStateException(EXCEPTION_PLAYER_INPUT)
+    ...
+}
+```
+
+→ **String → PickingState 매핑 = Player 책임**. *PR #132 (환노) 의 View가 사용자 의도 표현 (ActionType 반환)* 진단과 같은 결의 *반대 트레이드오프* — *현재 Player가 raw String 받아 변환*. *PickingState.entries.find { it.value == inputDecision }* 는 *Y/N 같은 String → enum 변환*. *PR #132 의 페로로 진단* (*컨트롤러에 중복 만들어지면 한쪽 변경 시 한쪽 고장*) 와 같은 함정 가능성.
+
+또한 *`it.value` = enum 멤버의 String 부가 속성*. PR #124·#28·#78·#112 의 *enum 의 UI value* 안티패턴 변형. *PickingState 가 도메인 인지 입력 인지* 경계 모호.
+
+### 16. `GameInfo.toString()` override — 도메인 객체가 View 형식 보유
+
+```kotlin
+override fun toString(): String {
+    return MESSAGE_PARTICIPANT_CARD_RESULT.format(
+        name,
+        cards.joinToString { MESSAGE_CARD_INFO.format(it.title, it.shape.title) },
+        sumOfCards,
+    )
+}
+
+companion object {
+    private const val MESSAGE_PARTICIPANT_CARD_RESULT = "%s카드: %s - 결과: %d"
+    private const val MESSAGE_CARD_INFO = "%s%s"
+}
+```
+
+→ **`GameInfo.toString` 이 *한글 메시지 형식 보유***. *View 책임 흡수*. *toString = 디버깅용*이 *Kotlin 표준 어휘*. *프로덕션 출력에 toString 사용* = *형식 변경 시 도메인 객체 수정*. PR #131·#88 의 *toString 도메인 객체 자가 표현* 와 같은 결.
+
+*형식 일관성* vs *도메인-뷰 분리* 트레이드오프. *현재 GameInfo.toString 한글 메시지*는 *완전 도메인 어휘 부재*. *OutputView 에서 매핑*이 정공.
+
+### 17. `Players` 의 `init` *2 검증 (중복 + 인원수)*
+
+```kotlin
+init {
+    require(value.map { it.gameInfo.name }.distinct().size == value.size) { EXCEPTION_DUPLICATED_PLAYERS }
+    require(value.size in PLAYER_NUM_RANGE) { EXCEPTION_NUMBER_OF_PLAYERS.format(value.size) }
+}
+```
+
+→ **이름 중복 검증 + 인원수 검증** 정합. *value.map { it.gameInfo.name }* = *Player → name 추출*. *Player.gameInfo.name* 점 체인 — *Demeter 위반 표면*. *`value.map { it.name }`* (Player.name getter) 가 *위임 메서드 추가*면 *Demeter 안전*. *Player 가 name 직접 노출*하면 *gameInfo 노출 회피 가능*.
+
+### 18. `Player.checkBurst` 가 *`sumOfCards >= 21`* — *21 도달도 STAND*
+
+```kotlin
+private fun checkBurst(): PickingState {
+    if (gameInfo.sumOfCards >= MAXIMUM_CARD_TOTAL) {
+        return PickingState.STAND
+    }
+    return PickingState.HIT
+}
+```
+
+→ **21 도달 + 21 초과 모두 STAND** — *블랙잭 도달 (2장 21 = 블랙잭)* + *21 도달 후 더 안 받음* 표현. *블랙잭 자체 = STAND 흡수* — *EarningRate.BLACKJACK 분기*가 *Judge.isPlayerBlackjack* 에서 *별도 판정*. *상태 분리 부재*.
+
+*PR #132·#136·#152 의 *State 객체 분리 (Blackjack/Bust/Stay)* * 와 *반대 트레이드오프*. PR #90 은 *enum 통합 + Judge 분기 분담*.
+
+## 리뷰어 의견 요지
+
+- **`value class` 정공 활용 — `@JvmInline` + 연산자 오버로딩** — 두루의 *"value class를 너무 잘 작성해주셨네요~💯"* 칭찬. *학생 자가 답변 1000+자 = value class vs data class vs class 자가 학습 모범*.
+- **승패 판정 로직 = 복잡 분기 + 새 요구 시 꼬임 위험** — *difference 변환 + 다중 if-or 분기*. *직접 점수 비교 + Tell-Don't-Ask 메시지* 권고.
+- **`toString` override = View 형식 분리** — *학생 자가 학습 모범 (오버라이드 첫 경험)*.
+- **`@CsvSource` + 테스트 픽스처 + 함수명 명확성** — *테스트 어휘 정공 활용*.
+- **단일 책임 함수 분리** — *Judge winning 판정* 분리.
+- **`Money` Default Value (0)** — *수익 시작값 표현*. *primary constructor + default* 활용.
+- **`zip` 함수 활용 = Kotlin stdlib 어휘** — *Players.of 의 List 결합* 패턴.
+- **테스트 동작 격리 = primary constructor 활용** — *팩토리 우회 + 사전 상태 주입*. *접근성 트레이드오프 학생 자가 결정*.
+- **`data class` vs `value class` vs `class` 차이 학습** — 두루 메타 질문 + 학생 1000+자 자가 답변.
+- **`InputView` 단계별 분리 (`initializeView`)** — *기능별 네이밍* 권고. *PR #88·#131 와 같은 결*.
+- **패키지 분리 (`card` / `gameInfo` / `participants`)** — *도메인 그룹별 패키지*.
+
+## 대표 인용
+
+**두루 (Judge 복잡 분기 + 요구사항 변화 시 꼬임, Judge.kt):**
+> 해당 내용의 조건들은 새로운 요구사항이 생길때마다 로직이 복잡하게 꼬일 수도 있을것 같은데, 결과를 좀더 복잡하지 않도록 해보는 방법을 고민해봐도 좋을 것 같다는 생각이 듭니다!🤔
+
+**두루 (value class 학습 메타 질문, Money.kt):**
+> 고민해보면 좋을 내용인 것 같아서 코멘트 남겨두었습니다!
+> `data class`, `value class`, `class`는 각각의 어떤 차이점을 가지고 있을까요??
+> 추가적으로 `@JvmInline` 해당 어노테이션을 추가하면 어떠한 기능을 하는걸까요??
+
+**학생 자가 답변 (value class vs data class vs class 자가 학습, Money.kt — 발췌):**
+> data class는 toString(), hashCode(), equals(), copy(), componentN()메소드를 자동으로 만들어주는 클래스입니다.
+> class와는 달리 이름부터 데이터를 담는 클래스라는 뉘앙스를 강하게 풍기는 만큼, 사용 시 클래스와 비교하였을 때 아래와 같은 이점을 얻을 수 있습니다.
+> ...
+> 우선 하나의 원시값만을 담아야 한다는 것이 value class의 특성임은 공식 문서에서도 잘 나와있음을 확인할 수 있었습니다.
+> ...
+> 또한, 수많은 멤버 변수 및 메소드를 필요하지 않을 때 value class를 사용하면 좋을 것 같다는 생각이 들었습니다. value class 자체가 과거에는 inline class라는 이름을 가졌다고 하는데, inline의 정의인 "함수나 코드 블록을 호출하는 위치에 해당 함수 또는 코드 블록의 본문이 복사되어 실행되는 것"이라는 특성을 생각해 보았습니다.
+> ...
+> 결론적으로 아래 상황들이 모두 맞아떨어지게 된다면 성능 상 이점을 볼 수 있도록 value class를 활용하게 될 것 같습니다.
+> * '하나'의 원시값만을 생성자에 담아야 하는 상황.
+> * data class나 class에서만 제공해주는 기능들을 필요로 하지 않는 상황
+> * typealias를 활용하기에는 아쉬운, 내부 로직이 필요할 것 같은 상황
+> * 수많은 멤버 변수/메소드를 필요로 하지 않으면서 value class로 만든 Wrapper 클래스가 광범위하게 사용되지는 않는 상황
+
+**학생 자가 답변 (Money factory vs primary constructor 자가 결정, GameInfo.kt — 발췌):**
+> 제가 설계를 진행할 때, Money 클래스가 두 가지 용도로 사용이 되도록 하였다는 것이 근본적 이유였습니다. 저는 베팅 금액과 수익 금액 두 가지를 동시에 Money 클래스를 활용하여 표현을 하고자 하였습니다.
+>
+> 문제는 베팅 금액의 경우 0 이하가 될 수 없는 반면에 수익 금액은 0 이하의 정수가 될 수 있다는 차이가 존재했다는 것이었습니다.
+>
+> 그 이유로, Money 클래스를 제약이 존재하는 베팅 금액 용도로 생성할 때는 정적 팩토리 메소드를 활용하여 메소드 내부에서 음수인지의 여부를 검증하고자 하였고, 수익으로서 Money는 주생성자로 바로 생성하고자 하는 목적으로 위와 같은 방식을 적용하게 되었습니다.
+
+**학생 자가 답변 (Bet/Profit 추상화 시도 후 통합, GameInfo.kt — 발췌):**
+> 사실 다른 후보로, Money라는 개념을 value class 대신 abstract class 혹은 interface로 추상화하고 Bet(베팅 금액)과 Profit(수익 금액)을 각각 value class로 구현하고자 생각하기도 하였습니다. 하지만 value class는 abstract class를 상속받을 수 없었기에 abstract class로 추상화 후 value class로 상속하는 조합으로는 목적을 달성할 수 없었습니다. 또한 Bet과 Profit이 공통으로 수행하는 책임이 거의 없었기에, 추상화 자체의 실익이 적다는 생각을 하게 되었습니다.
+
+**학생 자가 답변 (테스트 primary constructor 활용 이유, Players.kt:29):**
+> 객체에 대한 동작의 테스트를 진행하고자 할 때, 복잡한 로직들을 집어넣어야 하는 정적 팩토리 메소드보다는 이미 데이터가 만들어진 상태에서 테스트를 진행하는 것이 더욱 손쉬운 테스트 진행에 도움이 될 것이라고 생각하였습니다!
+
+**학생 자가 답변 (toString 오버라이드 첫 경험, GameRoundView.kt):**
+> toString() 메소드를 오버라이드 해본 경험이 없어서 적용할 생각을 하지 못하였던 것 같습니다!
+> 말씀하신 대로 수정을 진행해보니 뷰 측에서 형식을 일일이 지정해주지 않고 toString() 메소드 호출만으로 원하는 형식으로 정보를 출력할 수 있게 되었습니다!
+
+**두루 (학생 자가 답변 평가):**
+> 해당 내용에 대해서 정말 많은 객체의 책임과 추상화에 대해서 고민을 하셨을 것 같군요~👍
+> 타당한 근거 정말 좋습니다.
+> 사실 구현에 대해서 정답은 없어서 케이엠이 해당 내용을 구현하실 때 타당한 이유가 있었고, 그에 대한 설명을 해주시는 모습 정말 좋습니다ㅎㅎ😆
+
+## 얻은 교훈
+
+1. ***`@JvmInline value class` + 4가지 연산자 오버로딩 = Kotlin value class 완전 활용***. *원시 박싱 없음 + 타입 안전 + 모든 산술*. PR #131·#132·#136 와 같은 결의 *value class* 트레이드오프 — *기능 풍부도 최고 수준*.
+
+2. ***`Money` 두 용도 (베팅 + 수익) 자가 분리 = factory + primary constructor***. *베팅 (검증 필요) = factory*. *수익 (음수 허용) = primary constructor + default*. *학생 자가 학습 + 결정 근거 명시 모범*. *abstract class + value class 조합 시도 후 통합 후퇴 = 추상화 트레이드오프 학습*.
+
+3. ***Judge 정적 헬퍼 + difference 변환 = Tell-Don't-Ask 절반***. *Judge 가 모든 룰 판정 + Participant/GameInfo 는 데이터 추출만*. *PR #132·#136 의 Participant.compare(other) 메시지 다형성* 과 *반대 트레이드오프*. *Judge god-object 변형* 가능성. 두루 *"새 요구사항 시 꼬임 위험"* 진단.
+
+4. ***`difference = 21 - score` 변환 = 추상화 우회 신호***. *직접 점수 비교 (`score > 21`, `score == 21`)* 가 *직관*. *difference 변환 + 다중 분기*는 *코드 가독성 ↓*. *추가 변환 단계 = 인지 비용*.
+
+5. ***`PickingState` enum 의 HIT/STAND 통합 = 입력 의도 + 상태 표현 혼재***. *Bust 도 STAND 로 흡수* = *상태 차이 (Bust 무조건 패배 vs Stand 점수 비교) 표현 부족*. *PR #132·#136·#152 의 State 객체 분리* 와 *반대 트레이드오프* — *enum 통합 + Judge 분기*. **MCP 룰 후보 — `action-and-state-enum-conflation`**.
+
+6. ***`Card.toString` override = 도메인 객체가 자기 표현 알림***. 학생 자가 첫 경험 + *View 측 형식 지정 X*. *toString = 디버깅 vs 프로덕션 출력* 트레이드오프 의식 필요. *프로덕션 사용 시 형식 변경 = 도메인 객체 수정* 함정.
+
+7. ***`Set<Card>` 사용 = 카드 중복 차단 + iteration order LinkedHashSet 보장***. *블랙잭 도메인 = 같은 카드 2장 안 나옴* 정합. *Set.take(2) = 추가 순서대로 (LinkedHashSet)*. *List vs Set* 트레이드오프 — *Set 선택 합리*. 다만 *순서 의존 코드*는 *함정 가능성*.
+
+8. ***`Player(gameInfo, onInputDecision: () -> String)` 람다 인자 = 입력 콜백 멤버***. *Player 가 자기 의사 결정 = 콜백 호출*. *PR #132 (환노) 의 고차함수 시도* 와 같은 결. *Player → View 결합 vs interface 의존성 주입* 트레이드오프.
+
+9. ***`onInputDecision: () -> String` raw String 반환 = View가 raw vs 의도 표현 트레이드오프***. PR #132 (환노) 의 *페로로 진단 "View가 사용자 의도 표현 (ActionType)"* 과 같은 결. *Player 가 String → PickingState 변환 책임* = *변환 로직 중복 가능성*.
+
+10. ***`Judge(dealer: GameInfo, players: List<GameInfo>)` = Player/Dealer 인자 아닌 GameInfo***. *Participant 다형성 활용 X*. *Judge.dealer.sumOfCards* 같은 *데이터 추출* 만. *Player vs Dealer 행동 메서드 미접근*.
+
+11. ***`Money(0)` primary constructor 노출 = invariant 강제 부재***. *value class 의 factory only 정공* 위반 — *호출자가 `Money(-1000)` 같은 호출 가능*. *Money.zero() / Money.from()* 두 factory 가 *invariant 강제*.
+
+12. ***리뷰어 메타 질문 + 학생 1000+자 자가 답변 = 학습 가시화 최고 수준***. *두루의 "data class vs value class vs class 차이?"* 메타 질문 → *학생 자가 학습 1000+자 답변*. *외부 자료 + 본인 사고 + 코드 적용* 흐름이 *모범 학습 패턴*. PR #128·#135·#108·#133·#136 와 같은 결.
+
+13. ***패키지 분리 (`card` / `gameInfo` / `participants`) = 도메인 그룹별*** — *프로젝트 구조 명료성*. PR #88 의 *card/game/user* 와 같은 결. *각 패키지가 자기 책임 영역* 명시.
+
+14. ***`zip` 함수 + `run { Players(this) }` = Kotlin stdlib 어휘 활용***. *List 결합 + scope function*. *factory 함수 안에서 변환 + wrap* 패턴. *Kotlin 어휘 정공*.
+
+15. ***학생 자가 답변에 추상화 시도 후 통합 후퇴 명시 = 학습 가시화 모범***. *Bet / Profit value class 추상화 시도 → 공통 책임 거의 없음 → 통합 결정* 흐름이 *추상화의 정당화 기준*. *추상화 = 도메인 차이 있을 때만*. PR #88·#131 와 같은 결.