oh-my-oop 0.2.0

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

@@ -0,0 +1,360 @@
+# PR #49 — [블랙잭 2단계] 써니 미션
+
+- **Reviewee:** [@inseonyun](https://github.com/inseonyun)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/49
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 28 스레드 / 32 코멘트 — *Result 객체 분리 + 추상 메서드 다형성 + 베팅/수익 분리* 깊은 토론
+
+## 잘한 점 (설계 관점)
+
+- **`Participant` 추상 클래스 + 진짜 다형성 (5개 abstract method)** — `getFirstOpenCards()`, `isHit()`, `getProfitMoney(other)`, `getResult(participants)`, `isDealer()` 모두 *Player/Dealer 다른 구현*. 1단계 *open class* 진단 후속 완전 반영. **`isDealer()` 추상 메서드 = 페로로 진단 *"Participant라는 추상 클래스가 딜러라는 구현 클래스를 직접적으로 아는 것은 지양해야 합니다"* 후속 반영**. PR #132·#136·#108 와 같은 결의 *Participant 다형성*.
+- **`Money` + `Profit` value class 분리** — *베팅금액 (1000원 이상 검증) vs 수익금 (음수 허용)* 두 도메인 객체. `Profit` 에 `operator fun unaryMinus`. **`Profit.of(money, earningRate)` factory** + *Money * earningRate.multiple = Profit*. PR #90 (케이엠 2단계) 의 *Money 두 용도 분리* 와 같은 결 + *별도 클래스 분리* 트레이드오프.
+- **`EarningRate` enum + `BLACKJACK(1.5f) / WIN(1.0f) / DRAW(0.0f) / LOSE(-1.0f)`** — 페로로의 *"수익금에 대한 배율은 단순히 결과로 계산되지 않고, 비교하는 상대방의 카드 상태를 이용해 같이 계산이 됩니다. 즉 두명 모두 블랙잭이라면 1.5배가 아닌 1배로 계산이 됩니다. 게임의 결과라고 표현하는 대신 EarningRate라는 표현을 사용해보면 어떨까요?"* 후속 반영. **결과 vs 배율 분리**.
+- **`Dealer.getProfitMoney(other) = -other.getProfitMoney(this)` Tell-Don't-Ask 정공** — *Dealer 수익 = 플레이어 수익의 음수* 한 줄. *연산자 오버로딩 (`-Profit`)* 활용. PR #131·#132·#133 와 같은 결의 *Dealer 수익 = 플레이어 합 × -1*. **inseonyun 표현이 가장 간결**.
+- **`Result` + `ParticipantsProfitResult` 결과 객체 분리** — 페로로 권고 *"`class Result(val participant: Participant, val profit: Float); class GameResult(val results: List<Result>)`"* 후속 반영. PR #132·#136 의 *BlackjackResult* 와 같은 결.
+- **베팅금 ≠ 수익금 자가 학습** — 학생 자가 인용 (CardGameTest.kt:?): *"세상에,,,제가 딜러, 플레이어 수익 계산 룰을 잘못 이해하고 있었군요... '베팅금과 수익은 따로 봐야 합니다.'가 수익 계산에 가장 큰 핵심이네요!"*. 자가 인용 + 도메인 룰 자가 학습 모범.
+- **`Player private constructor + Player.of(...)` 정적 팩토리** — 페로로 권고 *"정적 팩토리 메소드로 객체 생성 방식을 정의한다면 기본 생성자로 생성이 불가능 하도록 접근자를 만들어 보면 어떨까요?"* 후속 반영. PR #133·#136·#93 와 같은 결.
+- **`Profit operator fun unaryMinus`** — 페로로 자가 칭찬: *"연산자 오버로딩 👍🏻"*. Kotlin 어휘 활용.
+- **3 변수 제약 자가 결정 + 페로로 동의** — 학생 자가 답변: *"3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다 를 충족하기 위해 ... Participant에 cards 프로퍼티를 둬서 생성, 관리 하는 것이 가능하다는 것을 알 게 되어 해당 방법을 택하게 되었습니다."*. 페로로: *"프로그램을 구현하면서, 설계에 따라 3개 이상의 변수가 만들어 질 수도 있습니다. 반드시 모든 조건을 지켜나가야만 좋은 설계인 것은 아닙니다. 3가지 이상을 썼을 때 오히려 더욱 좋은 구조가 된다면, 물론 사용하는 것이 좋습니다."*. PR #133·#88·#132·#136·#41 와 같은 결의 *연습 도구 인식*.
+- **`drawCard` 재귀 호출** — `CardGame.drawToStart` 가 *participant.isHit() 면 draw + 재귀*. *while loop 대체 함수형*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Player.getProfitMoney(other)` 의 *5 단계 if 분기 + 수익 룰 직접 구현*
+
+```kotlin
+override fun getProfitMoney(other: Participant): Profit {
+    val playerCardsSum = cards.sum()
+    val otherCardsSum = other.cards.sum()
+    if (isBlackJack() && other.isBlackJack()) return Profit.of(money, EarningRate.DRAW)
+    if (isBlackJack()) return Profit.of(money, EarningRate.BLACKJACK)
+    if (isBust()) return Profit.of(money, EarningRate.LOSE)
+    if (other.isBust()) return Profit.of(money, EarningRate.WIN)
+    if (playerCardsSum > otherCardsSum) return Profit.of(money, EarningRate.WIN)
+    if (playerCardsSum == otherCardsSum) return Profit.of(money, EarningRate.DRAW)
+    return Profit.of(money, EarningRate.LOSE)
+}
+```
+
+→ **Player 수익 계산 = 5 단계 if + 점수 비교 직접**. *Tell-Don't-Ask 의 메시지 분리 미달*. *Cards.compare(other.cards): EarningRate* 같은 *Cards 메시지*가 정공. *현재 Player.getProfitMoney 가 cards.sum 직접 추출 + 비교*. PR #132·#136 의 *Participants.compareScores(other)* + *Hand 자기 비교 메서드* 와 *반대 트레이드오프* — *Player 안에 분기 응집*.
+
+### 2. `Cards.isBust(): Boolean = sum() >= 22` — *22 매직 + Bust 기준 오류 신호*
+
+```kotlin
+fun isBust(): Boolean = sum() >= PARTICIPANT_STANDARD_BUST_POINT
+
+companion object {
+    private const val PARTICIPANT_STANDARD_BUST_POINT = 22
+    ...
+}
+```
+
+→ **`>= 22` = *22 이상 Bust*** — *수학적으로 `> 21`* 과 동등. *상수 이름 `PARTICIPANT_STANDARD_BUST_POINT = 22`* 도 *Bust 기준 22* vs *블랙잭 룰 = 21 초과* 의 *어휘 불일치*. *BLACKJACK_MAX_SCORE = 21 + isBust = sum > 21* 이 *룰 정합*. 현재 *22 사용*은 *> 변환 + ≥*로 *동등 표현* 이지만 *이름 misleading*. PR #132 (환노 2단계) 의 *BUST_STANDARD = 21* 와 *반대 트레이드오프* (이름 모호함).
+
+### 3. `Cards.sum()` Ace 처리 — *`sum + 10 < 22` 조건의 비대칭*
+
+```kotlin
+fun sum(): Int {
+    var sum = _cards.sumOf { it.rank.score }
+    if (_cards.find { it.rank == Rank.ACE } != null && sum + ACE_BONUS_TEN < PARTICIPANT_STANDARD_BUST_POINT) {
+        sum += ACE_BONUS_TEN
+    }
+    return sum
+}
+```
+
+→ **`sum + 10 < 22` = sum + 10 ≤ 21**. *Ace 1 기본 + sum + 10 ≤ 21 시 +10* 패턴. **표준 Ace 보정 (PR #128·#135·#114·#125·#108·#131 와 같은 결)**. 다만 *`< 22` 표기*가 *`<= 21`* 보다 *직관 ↓*. *Bust 기준 22 정의 활용*이라 *내부 일관성* 정합. 미세 가독성.
+
+또한 *find { rank == ACE } != null* = *any { rank == ACE }* 단순화 가능. *Kotlin 어휘 미숙*. PR #132 (환노 2단계) 의 *contains 활용* 와 비교.
+
+### 4. `Cards(cards: Set<Card>)` 생성자 인자 + *카드 직접 초기화 (덱 우회)*
+
+학생 자가 답변: *"요구사항 중 하나인 `3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.`를 충족하기 위해 ... Dealer와 Player 모두 Participant의 Cards를 사용할뿐 각각의 참가자(dealer, player)가 지닌 cards 프로퍼티는 Participant에 접근을 해 사용하다보니 필요성이 없다 생각했고, Participant에 생성자가아닌 cards 프로퍼티를 둬서 생성, 관리 하는 것이 가능하다는 것을 알 게 되어 해당 방법을 택하게 되었습니다."*
+
+페로로: *"카드를 준비하기 위해 다소 불편한 방법(덱)을 사용하는 것처럼 느껴집니다."*
+
+→ **카드 생성 시점 = 덱 우회**. *현재 Cards 생성자 인자 Set<Card>* + *participant.drawFirst(deck)* 분리. *Cards(emptyList()) + drawFirst* = *Cards 빈 상태로 시작 + 외부에서 채움* (lotto empty-object-external-fill 변형). PR #124·#108·#132 와 같은 결.
+
+페로로 후속: *"가령 아래와 같은 기능이 추가된다면 지금의 구조는 귀찮은 상황이 오게 될 것 같습니다. ... `플레이어가 52장의 카드를 가지고 있다면, 추가로 카드를 뽑을 수 없다`"* 예시 — *테스트 시점에 52장 분배 필요* + *Player.drawCard(cardDeck) repeat(52)* 같은 *번거로움*. *생성자 직접 카드 인자*가 *테스트 용이성*.
+
+### 5. `Cards.firstCard(): Card = cards.first()` — *Set 의 first 순서 의존*
+
+```kotlin
+fun firstCard(): Card = cards.first()
+```
+
+→ **`Set.first()` = LinkedHashSet 이면 추가 순서, HashSet 이면 임의**. PR #90 (케이엠) 의 *Set<Card> 사용* 과 같은 결. *Cards 의 `_cards = cards.toMutableSet()` → MutableSet 구현 LinkedHashSet 보장* — *추가 순서대로*. 정합. 다만 *Set 의미는 순서 없음* — *호출자가 함정 가능성*. *List<Card>* + *firstCard = list.first()* 가 *순서 의미 명시*.
+
+### 6. `Dealer.getProfitMoney(other) = -other.getProfitMoney(this)` 의 *순환 호출 가능성*
+
+```kotlin
+override fun getProfitMoney(other: Participant): Profit = -other.getProfitMoney(this)
+```
+
+→ **Player.getProfitMoney(Dealer) 호출 → Dealer.getProfitMoney(Player) 호출 → -Player.getProfitMoney(Dealer)** *무한 재귀 가능성*. *현재 호출 흐름 = Dealer 가 player 에 대해서만 호출* 라면 OK. *플레이어 vs 플레이어 비교* 시 *Player.getProfitMoney(Player)* 가 *Player 자기 메서드 호출* → 정상.
+
+다만 *Dealer.getResult(participants)* 안에서 `participants.players.forEach { profit += getProfitMoney(it).value }` — *Dealer.getProfitMoney(player)* → *-player.getProfitMoney(dealer)* → *player.getProfitMoney(dealer)* 가 Player 메서드 → 무한 재귀 아님. **호출 흐름 정확**.
+
+그러나 *코드만 보면 무한 재귀 의심* 가능성 — *명시적 docstring* 또는 *Player/Dealer compareTo 명시*가 *호출자 안전성*. *Kotlin 어휘로 `operator fun unaryMinus`* + *상위 함수 위임* 패턴.
+
+### 7. `Dealer.getResult` 의 *INITIALIZE_PROFIT = 0L + forEach += value* — *var 가변 누적*
+
+```kotlin
+override fun getResult(participants: Participants): Result {
+    var profit = INITIALIZE_PROFIT  // var
+    participants.players.forEach { profit += getProfitMoney(it).value }
+    return Result(this, Profit(profit))
+}
+```
+
+→ **var profit + forEach 누적**. *Kotlin 함수형 어휘 = `participants.players.sumOf { getProfitMoney(it).value }`* 한 줄. *imperative + var* 가 *함수형 어휘 미숙*. PR #131·#132·#133 의 *sumOf* 활용 와 같은 결.
+
+### 8. `EarningRate.DRAW(0.0f)` — *블랙잭 vs 블랙잭 = DRAW 가 PUSH 의미*
+
+```kotlin
+enum class EarningRate(val multiple: Float) {
+    BLACKJACK(1.5f), WIN(1.0f), DRAW(0.0f), LOSE(-1.0f);
+}
+```
+
+페로로 답변 (베팅 vs 수익 분리 토론): *"둘다 블랙잭이면 돈을 그대로 돌려받으니 수익은 0원이 맞습니다"*
+
+→ **DRAW = 0.0f = 베팅금 그대로 돌려받음**. *카지노 룰 = PUSH (블랙잭 vs 블랙잭) 시 베팅금 반환*. *수익 = 0*. *룰 정합*.
+
+다만 *카지노 PUSH = 일반 무승부와 다른 의미일 수 있음* — *블랙잭 PUSH (둘 다 블랙잭) vs Stay PUSH (점수 같음)* = *수익 모두 0* 이라 *현재 enum DRAW 통합* 정합. PR #131·#132·#136·#108·#133 와 같은 결.
+
+### 9. `CardGame.drawToStart` 재귀 + *Stack overflow 가능성*
+
+```kotlin
+fun start(status: (Participant) -> Unit): ParticipantsProfitResult {
+    participants.players.forEach { drawToStart(it, status) }
+    drawToStart(participants.dealer, status)
+    return participants.getParticipantsProfitResult()
+}
+
+private fun drawToStart(participant: Participant, status: (Participant) -> Unit) {
+    if (participant.isHit()) {
+        participant.drawCard(cardDeck)
+        status(participant)
+        drawToStart(participant, status)  // ⚠ 재귀
+    }
+}
+```
+
+→ **JVM tail call 최적화 미보장 (Kotlin tailrec 키워드 부재)**. *블랙잭 = 최대 5-10 카드* 라 *stack overflow 가능성 0*. 다만 *Kotlin `tailrec` 키워드*로 *명시적 최적화*가 정공. PR #133 (시아 2단계) 의 *tailrec drawUntilFinished* 와 같은 결.
+
+### 10. `getResult(participants: Participants)` 시그니처 — *Dealer 만 participants 필요, Player 는 무시*
+
+```kotlin
+// Player
+override fun getResult(participants: Participants): Result {
+    return Result(this, getProfitMoney(participants.dealer))  // ⚠ dealer 만 사용
+}
+
+// Dealer
+override fun getResult(participants: Participants): Result {
+    var profit = INITIALIZE_PROFIT
+    participants.players.forEach { ... }  // ⚠ players 만 사용
+    ...
+}
+```
+
+→ **`getResult(participants)` 시그니처 통일 + 내부 사용 비대칭**. *Player 는 dealer 만, Dealer 는 players 만*. *시그니처 통일 = 다형성 호출 편의* vs *사용 비대칭 = misleading*. *Player.getResult(dealer)* / *Dealer.getResult(players)* 같은 *명시적 시그니처*가 *내부 사용 명료*. 다만 *다형성 호출 시 불편*.
+
+또한 `getResult(participants).profit` 가 *Result 객체 거쳐 profit 추출* — *Result 객체 인자 vs Profit 직접 반환* 의 *책임 분리* 트레이드오프.
+
+### 11. `Participant.isHit()` 의 *Player 와 Dealer 비대칭*
+
+```kotlin
+// Player
+override fun isHit(): Boolean {
+    return !isBust() && needToDraw(name.value)  // 외부 람다
+}
+
+// Dealer
+override fun isHit(): Boolean = cards.sum() <= DEALER_STANDARD_HIT_POINT
+```
+
+→ **Player.isHit = 외부 람다 호출 (사용자 입력) + Bust 회피** + **Dealer.isHit = 자기 점수 ≤ 16**. *다형성 정공*. *Player needToDraw 람다 = View 의존*. PR #132 (환노) 의 *ActionType 토론* 과 같은 결 — *Player 가 raw String 가까운 람다 의존*.
+
+### 12. `needToDraw: (String) -> Boolean` 시그니처 — *람다 String 인자 = name*
+
+```kotlin
+private val needToDraw: (String) -> Boolean
+...
+override fun isHit(): Boolean {
+    return !isBust() && needToDraw(name.value)
+}
+```
+
+→ **`needToDraw(name.value)` = 외부 람다에 자기 이름 인자**. *Player.name → 람다*는 *Player가 자기 이름 람다에 노출*. *람다 자체가 name → Boolean 변환* 책임 보유. *람다 안에서 InputView.getDecision(name)* 패턴 추정.
+
+다만 *Player 가 자기 name 람다에 노출* = *람다 책임 = name 별 의사 결정*. *View 가 사용자 의도 표현 (PR #132 페로로 진단)* 과 같은 결.
+
+### 13. `참가자 객체가 *value 외부 노출***
+
+페로로 (Participants.kt — 미해결): *"딜러와 플레이어들을 사용하기 때문에 value는 외부에 노출하지 않아도 될 것 같아요"*
+
+→ **`Participants.value: List<Participant>` 외부 노출** — *호출자가 직접 접근*. *Participants.dealer / Participants.players* 같은 *명시적 메시지*가 *Demeter*. PR #132·#133·#108 와 같은 결.
+
+### 14. `필터링 + 캐스팅` Participants.players — 페로로 진단
+
+페로로 (Participants.kt — 미해결): *"캐스팅이 꼭 필요한 작업일까요? 참가자 타입에 역할을 만들어 보는건 어려울까요? 추가로, 코드에 체이닝이 너무 길게 되어 있어 명시적으로 변수를 분리해서 가독성을 올려주세요"*
+
+→ **타입 캐스팅 + 체이닝 = 다형성 부재 신호**. *Participant 추상 메서드*가 *분기 회피*. *Participants 가 dealer + players 분리 보유* 같은 *생성자 분리*. PR #132 (환노 2단계) 의 *PlayerGroup(participants).filterIsInstance<Dealer>().first()* 와 같은 결.
+
+### 15. `Dealer.isPossibleDrawCard()` 별도 함수 — 페로로 진단
+
+페로로 (Dealer.kt — 미해결): *"`isPossibleDrawCard()` 함수가 별도로 사용성이 없어 보입니다. `isHit()` 함수에서 사용하기 위한 private 함수로 봐야 하지는 않을까요?"*
+
+→ **외부 사용처 없으면 private**. *Public 메서드 = 외부 인터페이스 약속*. *외부 사용 0 + Public = 의도 없는 노출*. PR #103 (해나 2단계) 의 *_cardDeck + cardDeck 이중 표현* 과 같은 결.
+
+### 16. `Player.sum()` 다중 호출 — 페로로 진단
+
+페로로 (Player.kt — 미해결): *"가장 마지막에 있는 Profit.of() 함수에 오기까지 sum() 함수는 몇번이 호출되는 걸까요?"*
+
+→ **`getProfitMoney` 내부에 `cards.sum()` 다중 호출**:
+```kotlin
+val playerCardsSum = cards.sum()
+val otherCardsSum = other.cards.sum()
+if (isBlackJack() && ...) ...  // isBlackJack → sum 호출
+if (isBust()) ...               // isBust → sum 호출
+```
+
+→ *isBlackJack, isBust 가 내부에서 sum() 호출* → *Profit.of 까지 sum 다중 호출*. *변수 캐싱*은 있지만 *isBlackJack/isBust 메서드 내부* 별도 호출. *성능 + 일관성 문제* (cards 변경 가능성).
+
+*Score / Cards 의 sum 캐싱* (val sum = ... 또는 by lazy) 이 *반복 호출 안전*. PR #136 (밀러 2단계) 의 *Score.value get() = calculateTotalSum()* 와 *같은 결의 캐싱 부재*.
+
+### 17. `Participants` 의 *value 노출 + 파라미터 이름*
+
+페로로 (Players.kt — 미해결): *"파라미터로 참가자 타입을 받기 때문에 파라미터 이름도 동일하게 맞춰주어서 구현이 무엇인지 모르게 하는 것이 좋겠습니다"*
+
+→ **파라미터 명시적 타입 일관성** = *추상 클래스 의존 + 구현 모름*. PR #88·#132 와 같은 결.
+
+### 18. `Cards` 가 *Set<Card>* 인자 → *내부 MutableSet 변환* 패턴
+
+```kotlin
+class Cards(cards: Set<Card>) {
+    private val _cards = cards.toMutableSet()
+    val cards: Set<Card>
+        get() = _cards.toSet()
+    ...
+}
+```
+
+→ **`Set` 인자 + `MutableSet 사본` + `getter Set 사본`** = *Set 사용 안전 + 캡슐화*. PR #90 (케이엠 2단계) 의 *Set<Card>* 와 같은 결. *getter 매 호출 toSet 사본* = *불필요한 사본 비용*. *toSet() (immutable view)* 이 *상수 시간*. 미세 비효율.
+
+## 리뷰어 의견 요지
+
+- **`Result(participant, profit)` 결과 객체 분리** — *플레이어 이름 + 나이 추가 시 도메인 모델 수정 X*. *데이터 클래스로 표현*.
+- **추상 클래스가 구현 클래스 (Dealer) 직접 알면 안 됨 — `isDealer()` 추상 메서드** — *DIP*. *구현체가 결정*.
+- **수익금 = 추상 함수로 다형성** — *Player vs Dealer 의 수익 계산 방식 다름*. *합치는 vs 각각 비교* 트레이드오프.
+- **베팅금 ≠ 수익금** — *블랙잭 vs 블랙잭 = 베팅금 그대로 돌려받음 (수익 0)*.
+- **EarningRate enum + 결과 vs 배율 분리** — *결과는 비교 상대방 상태 의존*.
+- **연산자 오버로딩 정공 (`-Profit`)** — Kotlin 어휘.
+- **3 변수 제약 = 좋은 설계 조건 아님** — *설계상 3개 이상 필요 시 사용 OK*.
+- **카드 직접 초기화 (덱 우회) vs 생성자 카드 인자** — *테스트 용이성* 트레이드오프.
+- **Participants.value 외부 노출 X + dealer/players 메시지** — Demeter.
+- **타입 캐스팅 = 다형성 부재 + 체이닝 가독성 ↓** — *명시적 변수 분리*.
+- **외부 미사용 메서드 = private** — *Public 의도 노출 의미*.
+- **sum 다중 호출 = 캐싱 권고** — *성능 + 일관성*.
+
+## 대표 인용
+
+**페로로 (Result 객체 분리, GameResult.kt):**
+> 게임의 결과에서 플레이어의 이름과 나이를 같이 출력해야 한다면 도메인 모델이 같이 수정이 되어야 합니다.
+> 게임의 결과를 그대로 데이터로 만들어본다면 이렇게 작성할 수 있을 것 같습니다.
+> ```kotlin
+> class Result(val participant: Participant, val profit: Float)
+> class GameResult(val results: List<Result>)
+> ```
+
+**페로로 (추상 클래스 = 구현 모름 + isDealer 추상, Participant.kt):**
+> Participant라는 추상 클래스가 딜러라는 구현 클래스를 직접적으로 아는 것은 지양해야 합니다.
+> 추상 클래스로 만들었기 때문에, 구현체가 누구인지는 내부에서 몰라야 합니다.
+> 딜러, 플레이어 객체에서 `isDealer()` 함수를 구현 해보세요
+
+**페로로 (추상 수익금 메서드, Participant.kt):**
+> 참가자에게 요구하는 것은 게임의 결과라기 보다는 수익금이 목표라고 생각합니다.
+> 그 과정에서 게임의 결과는 수익금을 계산하기 위한 절차로 볼 수 있는데요.
+>
+> 아래와 같은 시그니처로 구현이 가능할 것 같아요.
+> ```kotlin
+> abstract class Participant {
+>    // 딜러의 수익금 계산 방식
+>    // 플레이어의 수익금 계산 방식
+>    abstract fun getProfit(other: Participant): Profit
+> }
+> ```
+>
+> 딜러의 경우 모든 플레이어와 합친 것을 수익금이라고 생각했기 때문에 하나로 합치지 못한 것으로 보이는데요.
+>
+> 전부 합치는건 모든 참가자와 승부하는 개념이고, 각각의 참가자와 승부하는 것에 있어서랑은 다르게 해석해 볼 수 있겠습니다.
+>
+> 다시 말하면 모든 참가자들과 승부한 수익금들의 합계가 곧 전체 수익금이 되겠죠?
+
+**페로로 (베팅 vs 수익, CardGameTest.kt):**
+> 베팅한 금액과 당첨금을 합쳐서 수익을 계산하는 것이 아닌
+> 베팅금과 수익은 따로 봐야 합니다.
+> 즉 만원을 베팅해서 위 경우에 해당된다면 수익은 만원입니다.
+
+**페로로 (배율 표현, CardGameResult.kt):**
+> 수익금에 대한 배율은 단순히 결과로 계산되지 않고,
+> 비교하는 상대방의 카드 상태를 이용해 같이 계산이 됩니다.
+> 즉 두명 모두 블랙잭이라면 1.5배가 아닌 1배로 계산이 됩니다.
+>
+> 게임의 결과라고 표현하는 대신 EarningRate라는 표현을 사용해보면 어떨까요?
+
+**페로로 (3 변수 제약 적정 적용, DealerTest.kt:20):**
+> 프로그램을 구현하면서, 설계에 따라 3개 이상의 변수가 만들어 질 수도 있습니다.
+> 반드시 모든 조건을 지켜나가야만 좋은 설계인 것은 아닙니다.
+> 3가지 이상을 썼을 때 오히려 더욱 좋은 구조가 된다면, 물론 사용하는 것이 좋습니다.
+>
+> 저는 앞서 사용하신 내용이 잘못되었다고 하지 않고, 하나의 "불편한 방법"이라고 알려 드렸는데요.
+> 말씀하신대로 딜러와 플레이어가 생성될 때 함께 카드를 주지 않는것도 방법 중 하나입니다.
+>
+> 그리고 설계를 하면서 여러가지 방법중 하나를 선택하는 순간이 자주 옵니다.
+> 트레이드 오프라고 하는 영역에서, 각각의 방법이 어떠한 장단점을 가지는지를 비교하고, 결과적으로 선택을 하게 됩니다.
+
+**학생 자가 학습 (수익 룰 자가 깨달음, CardGameTest.kt):**
+> 세상에,,,제가 딜러, 플레이어 수익 계산 룰을 잘못 이해하고 있었군요...
+> '베팅금과 수익은 따로 봐야 합니다.'가 수익 계산에 가장 큰 핵심이네요!
+
+## 얻은 교훈
+
+1. ***`isDealer()` 추상 메서드 = DIP 정공***. *추상 클래스가 구현 (Dealer/Player) 직접 알면 X*. *구현체가 자기 정체성 알림*. *Participant.isDealer() abstract → Player override false, Dealer override true*. PR #132·#136·#93·#108 와 같은 결의 *Participant 다형성*.
+
+2. ***베팅금 ≠ 수익금 = 블랙잭 도메인 룰 정확성***. *블랙잭 vs 블랙잭 = 베팅금 그대로 돌려받음 (수익 = 0)*. *학생 자가 깨달음 + 페로로 정리*. PR #131·#132·#133·#136 와 같은 결의 *수익률 룰 정확성*.
+
+3. ***`EarningRate enum + 배율 = 결과 (WIN/LOSE/DRAW/BLACKJACK) 와 분리 표현***. *결과 = 비교 후*, *배율 = 결과 + 자기 상태 결합*. *별도 객체 분리*가 *책임 명료*. PR #132 (환노) 의 *GameResult enum + earningRate* 와 *같은 결*.
+
+4. ***`Profit operator fun unaryMinus()` = Kotlin 어휘 활용***. *Dealer.getProfitMoney(other) = -other.getProfitMoney(this)* 한 줄. *PR #131·#132·#133·#136·#90 의 Money 연산자 오버로딩* 와 같은 결.
+
+5. ***카드 직접 초기화 (덱 우회) = 테스트 용이성 vs 도메인 invariant 트레이드오프***. 페로로 의 *52장 카드 테스트* 예시. *Cards 생성자 카드 인자 = 테스트 용이*. *Cards 빈 시작 + drawFirst = 도메인 흐름 정합*. *둘 다 합리* — 트레이드오프.
+
+6. ***`Set<Card>.first()` 순서 = LinkedHashSet 보장만, HashSet 임의***. PR #90 와 같은 결. *MutableSet 구현 = LinkedHashSet (Kotlin 표준)* — *추가 순서대로*. *Set 의미 vs 순서 의존* 함정.
+
+7. ***Player.getProfitMoney 5 단계 if + cards.sum 다중 호출 = Tell-Don't-Ask 미달 + 캐싱 부재***. *Cards.compare(other.cards): EarningRate* 같은 *Cards 메시지* 가 정공. *현재 Player 안에 분기 응집* = *다형성 미활용*. PR #132·#136 의 *Hand.compareScores* 와 *반대 트레이드오프*.
+
+8. ***외부 미사용 메서드 = private***. *Public = 외부 인터페이스 약속*. *외부 사용 0 + Public = 의도 없는 노출*. PR #103·#88 와 같은 결.
+
+9. ***`Cards.isBust = sum >= 22` vs `sum > 21` 의 이름 misleading***. *상수 = `MAX_SCORE = 21` + `isBust = sum > 21`* 이 *룰 정합 어휘*. *`PARTICIPANT_STANDARD_BUST_POINT = 22`* 가 *Bust 기준 22* 의미 — *블랙잭 룰 (21 초과 Bust)* 과 *어휘 불일치*. PR #132 와 *반대 트레이드오프*.
+
+10. ***Kotlin 함수형 어휘 = sumOf 활용***. *var profit + forEach += value* 는 *imperative*. *participants.players.sumOf { getProfitMoney(it).value }* 한 줄 = *Kotlin 어휘*. PR #131·#132·#133 와 같은 결.
+
+11. ***재귀 호출 = Kotlin `tailrec` 키워드로 명시적 최적화***. *현재 `drawToStart` 재귀가 tailrec 미명시*. *블랙잭 = 5-10 카드 stack 안전*이지만 *Kotlin 어휘 정공 = tailrec*. PR #133 (시아 2단계) 의 *tailrec drawUntilFinished* 와 같은 결.
+
+12. ***3 변수 제약 = 설계 조건 아님***. *설계상 3개 이상 필요 시 사용 OK*. *학생 자가 회의 + 페로로 동의 + 트레이드오프 인식 모범*. PR #133·#88·#132·#136·#41 와 같은 결.
+
+13. ***Result 객체 분리 = 도메인 모델 + 결과 표현 분리***. *플레이어 이름·나이 추가 시 도메인 수정 X*. *Result(participant, profit) data class* + *ParticipantsProfitResult(List<Result>)* 컬렉션. PR #132·#136 의 *BlackjackResult* 와 같은 결.
+
+14. ***학생 자가 학습 인용 ("세상에,,,제가 ... 잘못 이해하고 있었군요") = 학습 가시화 모범***. *도메인 룰 자가 깨달음 + 후속 반영* 흐름. PR #128·#135·#108·#133·#136 와 같은 결.
+
+15. ***`Participants.value 외부 노출 = Demeter 위반***. *dealer / players 메시지* 가 *Demeter 안전*. *호출자가 알아야 하는 객체 수 최소화*. PR #132·#133·#108 와 같은 결.
+
+16. ***타입 캐스팅 + 체이닝 = 다형성 부재 + 가독성 ↓***. *Participants 내부 캐스팅 → Participant 추상 메서드*로 *다형성 활용 정공*. *체이닝 길이 = 변수 분리*가 *가독성 정공*. PR #93·#108 와 같은 결.
+
+17. ***Dealer 수익 = -Σ플레이어 수익 = 가장 간결한 표현***. *Dealer.getProfitMoney(other) = -other.getProfitMoney(this)* 한 줄. *PR #131·#132·#133 의 `playerProfits.sumOf * -1`* 보다 *간결*. *Kotlin operator unaryMinus 활용 모범*.
+
+18. ***Player.isHit = !isBust && needToDraw(name) — Bust 회피 + 외부 람다***. *Player 가 자기 Bust 검증 + 외부 의지 람다 호출* — *Tell-Don't-Ask 응용*. *람다 String 인자 = name* 으로 *Player 자기 이름 노출* — *View가 사용자 의도 표현 (PR #132 페로로 진단)* 과 같은 결.

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

@@ -0,0 +1,152 @@
+# PR #30 — [글로] 1단계 블랙잭
+
+- **Reviewee:** [@ippnsj](https://github.com/ippnsj) (글로)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/30
+- **단계:** 1단계
+- **리뷰어:** [@galcyurio](https://github.com/galcyurio) — 누적 14명 reviewer
+- **라인 코멘트:** 11 스레드 — *PR 본문 자가 질문 2개 (DTO 책임 + const val vs inline) + 학생 자가 답변 3 thread / 에러 메시지 inline String template + DTO도 domain 로직 + CLI y/n = 플랫폼 종속 UI + Map 외부 전달 의미 모호 + interface로 무작위성 테스트 분리 칭찬*
+- **신규 reviewee** (2023 코호트).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 질문 2개 (학습 모범)
+
+PR 본문:
+
+> *"1. DTO로 감싸는 것이 Controller의 역할인가 vs Domain의 역할인가*
+> *2. 에러 메시지와 같은 String도 const val 키워드를 통해 상수화를 해주는 것이 가독성이 높은지, 아니면 문자 그대로 작성하는 것이 높은지 궁금합니다!"*
+
+→ **MCP 룰 `pr-body-question-list`** ⭐⭐ 신규 — *PR 본문 자가 질문 번호 매김 + 구체 의문*. PR #144 (m6z1 셀프 코드 리뷰) 결 합류.
+
+### 2. DSL 활용 칭찬 (Thread 5)
+
+`BlackJackBuilder` DSL 패턴 활용. reviewer: *"DSL 활용 :+1:"*
+
+### 3. Interface로 무작위성 테스트 분리 칭찬 (Thread 7)
+
+reviewer: *"interface를 통해 무작위성을 테스트에서 분리 :+1:"*
+
+→ **`interface-for-randomness-test-injection`** = 누적 다수.
+
+### 4. CsvSource + 명확한 테스트 케이스 이름 (Thread 8·9)
+
+reviewer: *"CsvSource 활용 :+1:"* + *"명확한 테스트 케이스 이름 :+1:"*.
+
+## 못한 점 (설계 관점)
+
+### 1. 에러 메시지 inline String template vs 상수 (Thread 0) — 핵심
+
+reviewer:
+
+> *"개인적인 컨벤션으로는 항상 inline으로 작성합니다. 그 이유는 예외가 발생했을 때의 변수들을 에러 메시지에 담아놓아야 다음에 에러가 발생했을 때, 디버깅이 쉬워지기 때문입니다. **inline으로 작성하면 String template을 통해 가독성있게 작성할 수 있는데 이를 상수로 분리하면 `%s`와 같이 작성하고 `String.format()`을 써야하기 때문이에요.***
+>
+> *현재 코드를 예시로 들자면, 추후 여기서 예외가 던져져서 로그 툴에 쌓이더라도 예외 메시지가 `number`를 담지 않았으므로 `number` 값이 무엇인지는 알 수가 없습니다."*
+
+학생 자가 답변: *"format 함수를 사용하는게 오히려 가독성을 해칠 수 있겠네요! 감사합니다!ㅎㅎ😆"*
+
+→ **MCP 룰 `error-message-as-inline-string-with-template`** ⭐⭐⭐ **신규 정점** — *상수화 = `%s` + `String.format()` 필요 = 가독성 X + 변수 누락 / inline String template = 디버깅 변수 포함 가능*. **단일 답 아님** (개인 컨벤션) + reviewer 어휘 *"개인적인 컨벤션"* — MCP `oh-my-oop` 핵심 가치 어휘.
+
+### 2. CardNumber UI 로직 (Thread 1)
+
+`CardNumber`에서 출력 로직 포함.
+
+reviewer: *"UI 로직입니다. UI layer에서 데이터를 받아서 그리도록 만들어보세요."*
+
+→ **출력 표현 = UI 책임** = PR #115·#15·#130 등 누적 다수.
+
+### 3. 숫자 + 문자 (A, J, Q, K) 별도 = enum (Thread 2)
+
+```kotlin
+// 변경 전 - 숫자와 문자 별도
+class CardNumber(val number: Int, val display: String) { ... }
+```
+
+reviewer: *"숫자와 A, J, Q, K가 별도로 나뉘어져 있으니 가독성이 좋지 않습니다. enum class로 변경해보세요."*
+
+→ **`enum-for-fixed-set-of-values`** = 누적 다수.
+
+### 4. CLI y/n = 플랫폼 종속 UI 로직 (Thread 3)
+
+```kotlin
+// Command.kt - domain
+enum class Command(val input: String) { YES("y"), NO("n") }
+```
+
+reviewer: *"CLI에서 y, n을 받는 것은 domain 로직이 아니라 플랫폼에 종속된 ui로직입니다."*
+
+→ **MCP 룰 `cli-y-n-as-ui-not-domain`** ⭐⭐⭐ — PR #14 (`cli-vs-gui-assumption-test` Boolean 한정) 결 합류 누적 2 PR → *플랫폼 종속 UI 어휘 강화*.
+
+### 5. DTO도 domain 로직 + 네이밍 제거 (Thread 4) — 핵심
+
+reviewer (학생 PR 본문 질문 인용):
+
+> *"이 DTO들 또한 domain 로직입니다. 또한 domain에 있는 클래스들과 역할이 조금 중복된 부분이 보입니다.*
+>
+> ***먼저 각 클래스 이름에서 DTO라는 네이밍을 모두 떼어보세요.** 이름이 겹치는데 역할이 다르다면 다른 이름으로 변경해보거나 역할이 같다면 합쳐보면 어떨까요?"*
+
+학생 자가 답변:
+
+> *"DTO라는 네이밍을 모두 제거했을 때, 특별히 새로운 로직을 수행하는 클래스가 없다고 판단하여 기존 도메인 객체에서 가공된 값을 받아 뷰에 넘겨주도록 수정하였습니다!😄"*
+
+→ **MCP 룰 `dto-as-domain-logic-naming-test`** ⭐⭐⭐ **신규** — *DTO 네이밍 제거 = 역할 중복 진단 도구*. PR #72 (`dto-vs-model-classification`) 결 합류 — DTO 분류 어휘 누적 2 PR.
+
+→ **MCP 룰 `naming-removal-as-design-test`** ⭐⭐⭐ — *접미사 제거 → 역할 중복 발견* 어휘 도구. PR #154 (`getter-setter-naming-as-missed-object`) 결의 *어색 명명 시그널* 다른 축.
+
+### 6. Map 외부 전달 의미 모호 (Thread 10) — 핵심
+
+```kotlin
+// Participants
+val participants: Map<String, List<Card>>
+```
+
+reviewer:
+
+> *"DTO라는 네이밍만 제거하고 객체 선언은 그대로 사용해도 된다는 피드백이었습니다. **Map으로 외부에 전달하는 경우 외부에서는 String이 무슨 역할인지 List<Card>가 무슨 역할인지를 알 수가 없습니다.**"*
+
+→ **MCP 룰 `map-external-loss-of-meaning`** ⭐⭐⭐ **신규** — *Map<K, V> 외부 전달 = K/V 역할 모호*. PR #38 (`pair-vs-data-class-naming-clarity`) 결 합류 누적 2 PR → ***익명 타입 = 어휘 손실 어휘*** ⭐⭐⭐ 강화.
+
+### 7. CardDeck Generator 책임 (Thread 6)
+
+reviewer: *"Generator에서 `List<Card>`를 반환하도록 만들어보면 어떨까요? 그러면 draw() 함수의 구현도 더 깔끔해질 것 같아요."*
+
+학생 자가 답변:
+
+> *"게임 특성상 카드를 뽑을 때마다 카드를 섞어줄 필요가 없다고 판단하여, CardDeck 생성시에만 카드를 섞어주도록 하였습니다! 그리고 Generator를 빼고 CardDeck에서 자신의 deck에 있는 카드를 뽑아서 반환하도록 수정하였습니다~!😊"*
+
+→ **학생 자가 도메인 룰 명시 + 책임 재배치** ⭐⭐ — *카드 섞기 = CardDeck 생성 시점만*.
+
+## 대표 인용
+
+> [galcyurio Thread 0]
+> *"개인적인 컨벤션으로는 항상 inline으로 작성합니다. (...) inline으로 작성하면 String template을 통해 가독성있게 작성할 수 있는데 이를 상수로 분리하면 `%s`와 같이 작성하고 `String.format()`을 써야하기 때문이에요."*
+
+→ **에러 메시지 inline String template 어휘**.
+
+> [galcyurio Thread 4]
+> *"먼저 각 클래스 이름에서 DTO라는 네이밍을 모두 떼어보세요. 이름이 겹치는데 역할이 다르다면 다른 이름으로 변경해보거나 역할이 같다면 합쳐보면 어떨까요?"*
+
+→ **DTO 네이밍 제거 = 역할 중복 진단 어휘**.
+
+> [galcyurio Thread 10]
+> *"Map으로 외부에 전달하는 경우 외부에서는 String이 무슨 역할인지 List<Card>가 무슨 역할인지를 알 수가 없습니다."*
+
+→ **Map 외부 전달 = 어휘 손실 어휘**.
+
+> [galcyurio Thread 3]
+> *"CLI에서 y, n을 받는 것은 domain 로직이 아니라 플랫폼에 종속된 ui로직입니다."*
+
+→ **CLI y/n = 플랫폼 종속 UI 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **에러 메시지 inline String template** — **MCP 룰 `error-message-as-inline-string-with-template` 후보** ⭐⭐⭐ 정점.
+2. **DTO 네이밍 제거 = 역할 중복 진단** — **MCP 룰 `dto-as-domain-logic-naming-test` + `naming-removal-as-design-test` 후보** ⭐⭐⭐ 신규.
+3. **Map 외부 전달 = 어휘 손실** — **MCP 룰 `map-external-loss-of-meaning` 후보** ⭐⭐⭐ 신규. PR #38 결 누적 2 PR.
+4. **CLI y/n = 플랫폼 종속 UI** — **MCP 룰 `cli-y-n-as-ui-not-domain` 후보** ⭐⭐⭐. PR #14 결 누적 2 PR.
+5. **PR 본문 자가 질문 번호** — **MCP 룰 `pr-body-question-list` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **ippnsj 2023 코호트 새 reviewee** — 1단계 시작.
+- **galcyurio reviewer 어휘 — *"개인적인 컨벤션으로는"*** = MCP `oh-my-oop` 핵심 가치 (단일 답 X) 어휘.
+- **PR 본문 자가 질문 패턴 누적** (#30 ippnsj + #144 m6z1 셀프 코드 리뷰) — *학생 측 학습 가시화 메타*.