oh-my-oop 0.2.0

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

@@ -0,0 +1,318 @@
+# PR #85 — [블랙잭 2단계] 하디 미션
+
+- **Reviewee:** [@ii2001](https://github.com/ii2001)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/85
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 17 스레드 / 31 코멘트 — *Hand 불변/가변 토론* + *사이드 이펙트 vs 명시적 반환 토론*
+
+## 잘한 점 (설계 관점)
+
+- **`Hand` 가 *불변 객체로 진화* — `draw(card): Hand` / `decideStay(): Hand` 메시지 반환** — 페로로의 *"Hand가 Hand를 반환하도록 해서, 객체가 더 안전하도록 잘 만들어 주셨습니다. 👍🏻 짧은 시간내에 이정도로 적용해보시는게 쉽지 않았을텐데요."* 자가 칭찬. *불변 객체 + 메서드 체인* 패턴. *Tell-Don't-Ask* + *Functional style*.
+
+  ```kotlin
+  fun draw(card: Card): Hand {
+      if (stay) return this  // ⚠ stay 시 same instance
+      return Hand(_cards.apply { add(card) }, stay)
+  }
+
+  fun decideStay(): Hand {
+      return Hand(_cards, true)
+  }
+  ```
+
+- **`Hand.stay: Boolean` 상태 반영 — 스테이/버스트 시 추가 카드 차단** — 페로로의 *"블랙잭 게임에서 스테이 상태, 버스트 상태는 더이상 카드를 뽑을 수 없는 상태죠? 그렇다면, Hand에서도 이 상태라면 카드를 더 뽑을 수 없도록 기능을 만들어 보면 어떨까요?"* 진단 반영. *학생 자가 답변: "불변객체로 만듦과 동시에 해결이 되었습니다!"*. *Hand 가 자기 invariant 알리는 책임*.
+- **`Player.state` enum (`State.Running.Hit` / `State.Finished.Blackjack/Bust/Stay`) 도출** — *Hand 의 isBlackjack/isBust/isStay 메시지로 derived 상태*. 1단계 *Cards.getStatus enum* 진단의 후속 반영.
+
+  ```kotlin
+  val state: State
+      get() = when {
+          hand.isBlackjack() -> State.Finished.BlackJack
+          hand.isBust() -> State.Finished.Bust
+          hand.isStay() -> State.Finished.Stay
+          else -> State.Running.Hit
+      }
+  ```
+
+- **`Deck` 의 `generateStandardDeck` + 자동 셔플 + 카드 부족시 새 덱 채움** — *카지노 무한 게임 룰 정합*. *companion object* 에 *기본 덱 생성 함수*. PR #108·#133·#136 와 같은 결.
+
+  ```kotlin
+  fun dealCard(): Card {
+      if (_cards.isEmpty()) {
+          _cards.addAll(generateStandardDeck())
+          _cards.shuffle()
+      }
+      return _cards.removeAt(0)
+  }
+  ```
+
+- **`PlayerResult.profit: Int by lazy { calculateProfits() }` Kotlin 지연 초기화** — 페로로의 *"코틀린의 지연 초기화를 이용하면, 프로퍼티를 호출할 때 마다 매번 계산하지 않고 한번만 초기화 하도록 할 수 있습니다."* 권고 후속 반영. *Kotlin `by lazy`* 어휘 활용. *순수 계산 + 캐싱* 자연.
+- **`GameResult.dealerProfit = -playerResults.sumOf { it.profit }` — 총합 0 게임 룰 정합** — *딜러 수익 = 플레이어 수익 합 × -1*. PR #131·#132·#133 와 같은 결.
+- **`Player(name, hand, bettingMoney = BettingMoney())` 생성자 인자 통일** — 페로로의 *"플레이어 이름에 맞춰 배팅금액을 입력 받고, 바로 플레이어를 생성하도록 만들면, 배팅 금액을 Map 형태로 넣어줄 필요가 없지 않을까요?"* 진단 후속 반영. *Map<Player, BettingMoney>* 우회 제거.
+- **테스트 추가 자가 반영** — *기능 추가 시 테스트도 같이*. 페로로 다중 권고 후속.
+- **사이드 이펙트 → 별도 반환 자가 학습 (논쟁 후 후퇴)** — 학생이 처음에 *"calculateFinalProfits() 가 player 속 bettingMoney 변경 → 따로 반환 불필요"* 주장 → 페로로의 *"불변 상태로 만든다면 → 수익률을 별도 함수로 계산하는게 아닌 게임의 결과로 같이 포함하도록 한다면"* 진단 → 학생 자가 후퇴: *"따로 빼는게 더 안전성은 있을 것 같아서 그렇게 수정해보았습니다"*. **자가 학습 + 후속 반영 모범**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Hand.draw` 가 *_cards 재사용* — *불변 흉내 + 깊은 가변*
+
+```kotlin
+class Hand(
+    private val _cards: MutableList<Card>,
+    val stay: Boolean = false,
+) {
+    val cards: List<Card> get() = _cards.toList()
+    ...
+    fun draw(card: Card): Hand {
+        if (stay) return this
+        return Hand(_cards.apply { add(card) }, stay)  // ⚠ _cards 변경 + 새 Hand 반환
+    }
+    ...
+}
+```
+
+페로로 (Hand.kt:6 — 미해결): *"불변을 목표로 하였지만, 실제로는 가변 객체처럼 동작을 하고 있어요. 완전히 불변을 지향하는 것이라면, List 타입 하나로만 동작하도록 만들어 보시면 됩니다. `fun draw(card: Card): Hand { val nextHand = Hand(cards + card) }`"*
+
+학생 자가 답변 (미반영): *"완전한 불변보단 가변객체가 좋지 않을까 싶습니다 ㅜㅜ. 아직 굳이 불변으로 바꿔야 하는 큰 이유를 못찾겠습니다. 방어적 복사가 과연 정말 옳은것인가에 대해서 더 심도있는 고민이 필요한 것 같습니다."*
+
+→ **`Hand.draw(card): Hand` 반환 = *불변 스타일*** + **`_cards.apply { add(card) }` 으로 *기존 list 변경 + 같은 list 참조 새 Hand 반환***. *두 Hand 객체가 같은 _cards 참조*. *이전 Hand 조회 시 *이미 변경된 list***. **불변 표면 + 깊은 가변 함정**. *진짜 불변* = *`Hand(cards + card)` 새 list 생성*.
+
+페로로 진단의 의미 = *Hand 반환 = 불변 의도* / *_cards 재사용 = 가변 함정*. 학생이 *불변 vs 가변 트레이드오프*를 *방어적 복사 비용*으로 의식. 다만 *불변 표면 + 깊은 가변* 은 *최악의 표현* — *호출자가 불변 가정으로 코드 작성 시 버그 가능성*.
+
+### 2. `Deck(cards: List<Card>)` 생성자 = *기존 코드 회귀 신호*
+
+```kotlin
+class Deck(cards: List<Card> = generateStandardDeck()) {
+    private val _cards = cards.toMutableList()
+    val cards: List<Card> get() = _cards.toList()
+    ...
+}
+```
+
+페로로 (Deck.kt — 미해결): *"생성자로 받던 방식이 다시 없어졌어요. 왜일까요?? 테스트코드도 모두 깨졌을 것 같네요. 생성자와 방어적 복사를 활용한 방법은 아래를 참고 해주세요. `class Dedk(cards: List<Card>) { private val _cards = mutableListOf(cards); val cards: List<Card> get() = _cards.toList() }`"*
+
+→ **방어적 복사 + 불변 외부 노출 패턴이 정공**. *현재 코드 `cards.toMutableList()` + `_cards.toList()` 가 그 패턴*. 페로로 코멘트는 *이전 리뷰 자가 후퇴 경고*. 학생이 *Mutable 인자 → List 인자 → Mutable 인자 → List 인자* 흐름에서 *왔다갔다* 한 흔적. *최종 코드 정합*.
+
+페로로 추가 (Deck.kt:8 — 미해결): *"비어있을 때 셔플하는 규칙도 generateStandardDeck() 에 넣으면, 고민하던 비어있으면 셔플한다 라는 논리적인 문제도 해결되지 않을까요?"*
+
+→ **`dealCard` 에 *if (_cards.isEmpty()) addAll + shuffle*** 분기 vs *`generateStandardDeck()` 자체가 셔플된 덱 반환*. *책임 분리* 트레이드오프. *현재 dealCard 분기*는 *카지노 룰 분기*. *generateStandardDeck 셔플 포함*은 *생성자에서 init { _cards.shuffle() } 와 일관*.
+
+### 3. `Hand` 추상 클래스 + `DrawableHand` / `ReadOnlyHand` 인터페이스 패턴 미적용 (참고만 제시)
+
+페로로 (Hand.kt:12 — 미해결 참고): *"Hand가 Hand를 반환하도록 해서, 객체가 더 안전하도록 잘 만들어 주셨습니다. 👍🏻 ... 아래는 적용하지 않으셔도 됩니다. 참고만 해주세요. 사실 블랙잭 미션에서는 여러가지 추상화 전략을 이용한 기법을 경험하도록 되어 있는데요. 인터페이스 개념을 이용한다면 if, else 를 사용하지 않고 Hand의 상태를 수월하게 관리할 수도 있습니다."*
+
+```kotlin
+abstract class Hand {
+    abstract fun draw(card): Hand
+    abstract fun decideStay(): Hand
+}
+
+class DrawableHand: Hand {
+    override fun draw(card: Card): Hand { ... }
+    override fun decideStay(): Hand { return ReadOnlyHand(...) }
+}
+
+class ReadOnlyHand: Hand {
+    override fun draw(card: Card): Hand { return this }
+}
+```
+
+→ **상태 패턴 = if-else 제거**. *PR #152 (모찌 2단계) 의 State interface / PR #136 (밀러 2단계) 의 sealed class BlackJackRule* 와 같은 결. *현재 `Hand.stay: Boolean` + if-return* 은 *상태 분기 if 잔존*. *추상화로 다형성 활용* 미반영. 페로로 참고만 제시.
+
+### 4. `PlayerResult.calculateProfits` — *Result enum 분기 + 블랙잭 추가 분기*
+
+```kotlin
+private fun calculateProfits(): Int {
+    val playerBlackjack = player.hand.isBlackjack()
+    val bettingAmount = player.bettingMoney.bettingMoney
+
+    return when {
+        result == Result.PLAYER_WIN && playerBlackjack -> (bettingAmount * 1.5).toInt()
+        result == Result.PLAYER_WIN -> bettingAmount
+        result == Result.DEALER_WIN -> -bettingAmount
+        result == Result.DRAW -> 0
+        else -> 0  // ⚠ 도달 불가 (Result enum 3개)
+    }
+}
+```
+
+페로로 (GameResult.kt — 미해결): *"플레이어의 수익률이니까 PlayerResult에 가지고 있어야 하지 않을까요? 추가로 플레이어 자신의 결과를 가지고 있을테니 그 결과만으로 수익률을 계산할 수 있어 보이는데요. 수익률을 위해 딜러와 다시 승부를 벌이는 이유가 있을까요?"*
+
+→ **수익률 = PlayerResult 책임 (좋은 면)** + **블랙잭 분기 (`isBlackjack && PLAYER_WIN`) = Player.hand 직접 의존**. *PR #131·#132 의 GameResult enum + BlackjackWin 별도 멤버 패턴* 과 비교: *Result enum 3개 (WIN/DEALER_WIN/DRAW) + BLACKJACK 별도 분기*. *블랙잭은 결과의 한 종류*인지 *수익률의 한 변형*인지 *모호*. *Result.BLACKJACK_WIN* 멤버 추가가 *명시*.
+
+또한 `else -> 0` = *도달 불가 분기* — *Result enum 3개 + `result == PLAYER_WIN && !blackjack` else* 까지면 모든 경우 처리. *enum exhaustive when 활용 미달*.
+
+### 5. `Player(name, hand, bettingMoney)` 가 *Hand + BettingMoney + name = 3 변수*
+
+→ **3 변수 제약**. *Player = 이름 + 손패 + 베팅금*. *블랙잭 도메인에서 자연한 묶음*. *3 변수 제약 = 연습 도구* (PR #133 말리빈 진단) 의 *정당한 도메인 객체* 케이스.
+
+다만 `BettingMoney = BettingMoney()` default = *베팅 안 한 Player* 표현. *Player 가 반드시 베팅* 인지 *default 베팅 0* 인지 *도메인 의미 명시 부재*. PR #131 (다이스 2단계) 의 *기본 생성자 지양* 권고와 같은 결.
+
+### 6. `Hand.draw` 의 `if (stay) return this` — *예외 vs silent ignore*
+
+```kotlin
+fun draw(card: Card): Hand {
+    if (stay) return this   // ⚠ stay 시 silent return
+    return Hand(_cards.apply { add(card) }, stay)
+}
+```
+
+→ **stay 상태에서 `draw(card)` 호출 시 *카드 무시 + 자기 반환***. *예외 throw* 대안: *stay 시 IllegalStateException*. *silent ignore vs explicit failure* 트레이드오프. *호출자가 stay 상태 모르고 draw 호출 시 *카드 분실 신호 없음**. *PR #152 (모찌 2단계) 의 Finish.draw throw IllegalStateException* 와 *반대 트레이드오프*.
+
+*안전한 표현* = *Hand.draw 가 *stay 검증 후 호출자가 보장**. *현재 silent return* = *Hand 가 자기 invariant 강제 + 호출자 부담 없음*. *둘 다 합리* — 트레이드오프.
+
+### 7. `Hand(_cards.apply { add(card) }, stay)` — *같은 _cards 참조 새 Hand*
+
+```kotlin
+return Hand(_cards.apply { add(card) }, stay)
+```
+
+→ **두 Hand 객체가 *같은 _cards MutableList 참조***. *호출 흐름*:
+- *Hand1 = 초기 손패*
+- *Hand2 = Hand1.draw(card)* → Hand1._cards 에 카드 추가 + Hand2 새 객체이지만 same _cards
+
+*Hand1._cards.size == Hand2._cards.size* (둘이 같은 list).
+
+이건 *불변 객체의 본질 위반* — *Hand1 의 상태가 Hand1.draw 호출로 변경*. *함수형 스타일 정공* = *cards + card* (새 list 생성). 페로로 권고:
+
+```kotlin
+fun draw(card: Card): Hand {
+    val nextHand = Hand(cards + card)  // 새 List
+}
+```
+
+학생 자가 답변 = *가변 유지 결정*. *Kotlin 의 cards + card immutable expression* 활용 미달.
+
+### 8. `Hand.stay: Boolean` 부생성자 default = `false` — 모호한 시작 상태
+
+```kotlin
+class Hand(
+    private val _cards: MutableList<Card>,
+    val stay: Boolean = false,
+)
+```
+
+→ **`stay = false` default** = *모든 Hand 가 초기 *진행 중**. *블랙잭 도메인 = Hand 생성 시점 = 초기 2장 분배 후* 라면 *진행 중 default* 정합. 다만 *Hand 자체*가 *카드 0장 또는 카드 1장* 상태도 가능 — *블랙잭 룰 invariant 부재*. PR #136 (밀러 2단계) 의 *Hand.size 검증 부재* 와 같은 결.
+
+### 9. `calculateFinalProfits()` *반환 없음 + 사이드 이펙트* (자가 후퇴) — `calculate` naming 패턴 위반
+
+학생 초기 코드 (후속 수정 전): `calculateFinalProfits()` 가 *Unit 반환 + Player.bettingMoney 변경*.
+
+페로로: *"`calculateFinalProfits()` 무언가를 계산하라 라는 메시지가 아무것도 반환을 하지 않는게 맞을까요? ... calculateXXX는 일반적인 프로그래밍 패턴으로 무언가를 반환하도록 사용됩니다."*
+
+학생: *"제 생각엔 calculateFinalProfits()함수내에서 계산을 한 후에 player속에 bettingMoney가 변경되게 만들어서 따로 반환이 필요하지 않다고 생각하는데 어떻게 생각하시나요???"*
+
+페로로: *"calculateXXX는 일반적인 프로그래밍 패턴으로 무언가를 반환하도록 사용됩니다. 대다수의 개발자들이 이렇게 사용될거라고 생각을 하는데 실제로는 다르다면 불필요한 비용이 들 수 있습니다. 클래스와 함수 모두, 가급적 사이드 이펙트를 최소화 하라는 의미는 무엇인지 알고 계실거라 생각합니다. 그런 차원에서 본다면 calculateFinalProfits()을 호출할 때 마다 값이 달라질 수 있다는 것은 좋은 방법일까요? > 게임 결과를 만들었는데, 수익률이 매번 바뀔 수 있다 > 게임 결과에 있는 딜러의 배팅 금액을 임의로 바꾸면 수익률이 바뀌어야 한다. 위 문제를 근본적으로 접근해서, 불변 상태로 만든다면 -> 수익률을 별도 함수로 계산하는게 아닌 게임의 결과로 같이 포함하도록 한다면 어떨까요?"*
+
+→ **`calculateXXX = 반환 패턴 표준 + 사이드 이펙트 최소화 + 불변 게임 결과 권고**. 학생 자가 후퇴 + 후속 반영. *호출 시점마다 값 달라질 위험 + 게임 결과 invariant 깨짐* 진단.
+
+### 10. *불변에 대한 학생 자가 회의 — "방어적 복사가 정말 옳은가"*
+
+학생 인용: *"완전한 불변보단 가변객체가 좋지 않을까 싶습니다 ㅜㅜ. 아직 굳이 불변으로 바꿔야 하는 큰 이유를 못찾겠습니다. 방어적 복사가 과연 정말 옳은것인가에 대해서 더 심도있는 고민이 필요한 것 같습니다."*
+
+→ **불변 vs 가변 트레이드오프 자가 의문 — 학습 가시화 모범**. *PR #133 (시아 2단계) 의 "val 가변 vs var 불변"* 자가 의문과 같은 결. *불변 = multi-thread 안전 + 부수효과 0 + 추론 쉬움*. *가변 = 성능 + 코드 짧음 + 익숙*. *결정은 도메인 + 컨텍스트 의존*.
+
+페로로 답변 (calculateFinalProfits 토론): *"기존 사이드 이펙트를 사용한 코드가 안정성이 떨어진다는 것을 충분히 알고 계셧다면 왜 사용했을까요.."* — *학생의 자가 판단이 옳은 지 토론 유도*.
+
+## 리뷰어 의견 요지
+
+- **`calculateXXX` 가 사이드 이펙트 + Unit = naming 패턴 위반** — *반환 표준*. *호출 시점마다 값 변경 가능성 = 게임 결과 invariant 부재*.
+- **불변 게임 결과 = 수익률을 결과 객체에 포함** — *계산 시점 ≠ 결과 시점* 분리. *PlayerResult.profit by lazy* 가 그 표현.
+- **`Hand.draw(card): Hand` 메시지 반환 = 불변 표면, 다만 _cards 재사용은 깊은 가변** — *완전한 불변* = *List 타입 하나 + cards + card*.
+- **상태 패턴 (`DrawableHand` / `ReadOnlyHand`) = if-else 제거** — *블랙잭 미션의 추상화 전략 경험*. 페로로 참고만 제시.
+- **`Deck` 빈 상태 셔플 = generateStandardDeck 책임** — *논리적 문제 (비어 있으면 셔플) 해결*.
+- **방어적 복사 = 캡슐화 + 의도치 않은 버그 방지** — *외부에서 cards.add(...) 같은 변경* 차단. PR #108 (시아 1단계) 의 *MutableList 외부 인자* 진단의 연장.
+- **수익률 = PlayerResult 책임** — *플레이어 자신의 결과만으로 계산 가능*. *딜러와 다시 승부 X*.
+- **Kotlin `by lazy` 활용** — *프로퍼티 호출마다 매번 계산 X*. *한 번 초기화 + 캐싱*.
+- **사이드 이펙트 = 가급적 최소화 + 의도 명시 필요** — *사용 시 명시 안 하면 호출자 추측*. *학생이 의도 = 명시*.
+- **`MutableList` vs `List` = 기본은 불변** — *생성자 인자 Mutable 이면 외부 변경 가능성*.
+- **테스트도 기능과 함께 추가** — *기능 추가 시 테스트 필수 (TDD 일관성)*.
+
+## 대표 인용
+
+**페로로 (calculate 패턴 + 사이드 이펙트, BlackJackController.kt):**
+> calculateXXX는 일반적인 프로그래밍 패턴으로 무언가를 반환하도록 사용됩니다.
+> 대다수의 개발자들이 이렇게 사용될거라고 생각을 하는데 실제로는 다르다면 불필요한 비용이 들 수 있습니다.
+>
+> 클래스와 함수 모두, 가급적 사이드 이펙트를 최소화 하라는 의미는 무엇인지 알고 계실거라 생각합니다.
+> 그런 차원에서 본다면 calculateFinalProfits()을 호출할 때 마다 값이 달라질 수 있다는 것은 좋은 방법일까요?
+>
+> > 게임 결과를 만들었는데, 수익률이 매번 바뀔 수 있다
+> > 게임 결과에 있는 딜러의 배팅 금액을 임의로 바꾸면 수익률이 바뀌어야 한다.
+>
+> 위 문제를 근본적으로 접근해서, 불변 상태로 만든다면 --> 수익률을 별도 함수로 계산하는게 아닌 게임의 결과로 같이 포함하도록 한다면 어떨까요?
+
+**페로로 (불변 vs 가변 + Hand, Hand.kt:6):**
+> 불변을 목표로 하였지만, 실제로는 가변 객체처럼 동작을 하고 있어요.
+> ```kotlin
+> val cards = mutableListOf<Card>()
+> val hand = Hand()
+> cards.add(Card())
+> cards.add(Card())
+> val result = hand.cards // [?, ?]
+> ```
+>
+> 완전히 불변을 지향하는 것이라면, List 타입 하나로만 동작하도록 만들어 보시면 됩니다.
+> ```kotlin
+> fun draw(card: Card): Hand {
+>    val nextHand = Hand(cards + card)
+> }
+> ```
+
+**페로로 (상태 패턴 추상화 참고, Hand.kt:12):**
+> Hand가 Hand를 반환하도록 해서, 객체가 더 안전하도록 잘 만들어 주셨습니다. 👍🏻
+> ...
+> 아래는 적용하지 않으셔도 됩니다. 참고만 해주세요*
+> 사실 블랙잭 미션에서는 여러가지 추상화 전략을 이용한 기법을 경험하도록 되어 있는데요.
+> 인터페이스 개념을 이용한다면 if, else 를 사용하지 않고 Hand의 상태를 수월하게 관리할 수도 있습니다.
+
+**페로로 (캡슐화 = 의도치 않은 버그 방지, Deck.kt):**
+> 작성하신 구조에서는 논리적으로 카드가 비어있다면 셔플을 하거나, "Deck is empty" 출력합니다.
+> 지우는 것 외에도 외부에서 상태를 임의로 바꾸지 못하게 하는 것은 객체지향 캡슐화와, 은닉성을 지키면서 의도치 않은 버그를 만들지 않기 위함입니다.
+>
+> 지우는 것 말고 반대로 넣는 예시로 볼게요.
+> 아래와 같은 코드 호출이, 내가 의도한 프로그램으로서 동작하는데 문제가 없을까요?
+> 사용하는 측이 건들였으니 아무런 책임이 없는 걸까요?
+
+**페로로 (사이드 이펙트 의도 명시 + 학생 자가 의도, BlackJackController.kt):**
+> 사이드 이펙트를 이용해서 풀려 했다는 사실을, 왜 먼저 명시해주지 않으셨을까 궁금하네요.
+> 정답은 없기 때문에 가변 상태를 이용한 방법도 하나의 해결법이 될 수 있습니다.
+>
+> 상태를 불변으로 만들면서, 점차 개선하는 과정을 연습하는 과정으로 생각해주시면 될 것 같습니다.
+> 다만 기존 사이드 이펙트를 사용한 코드가 안정성이 떨어진다는 것을 충분히 알고 계셧다면 왜 사용했을까요..
+
+**학생 자가 답변 (불변 vs 가변 자가 의문, Hand.kt:6):**
+> 완전한 불변보단 가변객체가 좋지 않을까 싶습니다 ㅜㅜ
+> 아직 굳이 불변으로 바꿔야 하는 큰 이유를 못찾겠습니다.
+> 방어적 복사가 과연 정말 옳은것인가에 대해서 더 심도있는 고민이 필요한 것 같습니다.
+
+**학생 자가 답변 (사이드 이펙트 시도 의도, BlackJackController.kt):**
+> 사이드 이펙트를 사용해서 풀면 좋은 경우가 있다고 들어서 저는 이경우가 굳이 불변으로 바꾸지 않고 사이드 이펙트를 사용하는게 더 좋다고 판단했었습니다.
+
+## 얻은 교훈
+
+1. ***`calculateXXX` 가 사이드 이펙트 + Unit = naming 패턴 위반***. *Kotlin 의 calculate 메서드 표준 = 반환*. *대다수 개발자 추측과 다른 동작 = 불필요한 인지 비용*. 사이드 이펙트 의도면 *명시적 이름 (`updateProfits()`, `applyResultsToPlayers()`)* 이 자연.
+
+2. ***불변 게임 결과 = 수익률을 결과 객체에 포함***. *계산 시점마다 값 달라지면 *게임 결과 invariant* 깨짐*. *결과 객체의 수익률 = 계산 시점에 고정 (`by lazy`)* 가 정공. PR #131·#132·#133 의 *GameResult/BlackjackResult* 와 같은 결.
+
+3. ***Hand.draw(card): Hand 반환 = 불변 표면, _cards 재사용 = 깊은 가변***. *불변 표현 + 가변 함정* 최악. *Kotlin `cards + card` immutable expression* 활용 가능. 학생 자가 회의 + 후속 반영 미달 = *trade-off 의식이 의도적 선택*.
+
+4. ***방어적 복사 = 캡슐화 + 의도치 않은 버그 방지***. *Mutable 인자 노출 → 외부 변경 가능 → 의도 안 했는데 상태 변경*. *생성자에서 toMutableList() 사본 + getter toList()* 가 정공. PR #108·#132·#133 와 같은 결.
+
+5. ***상태 패턴 (`DrawableHand` / `ReadOnlyHand`) = if-else 제거***. *블랙잭 미션의 추상화 전략 경험 = 인터페이스 다형성*. *Hand.stay: Boolean + if (stay) return this* 는 *상태 분기 잔존*. PR #152·#136·#133·#131 와 같은 결의 sealed/abstract 상태 객체.
+
+6. ***Kotlin `by lazy` = 프로퍼티 호출마다 매번 계산 X***. *순수 계산 + 캐싱* 자연. *`val profit: Int by lazy { calculateProfits() }`* 한 줄. *Kotlin 어휘 활용 모범*.
+
+7. ***딜러 수익 = 플레이어 수익 합 × -1*** = *총합 0 게임 룰 정합*. PR #131·#132·#133·#136 와 같은 결. 학생의 *`GameResult.dealerProfit = -playerResults.sumOf { it.profit }`* 한 줄 표현.
+
+8. ***`else -> 0` 도달 불가 분기 = enum exhaustive when 미활용***. *Result enum 3개 (PLAYER_WIN/DEALER_WIN/DRAW)* 면 *모든 경우 처리*. *else 도달 불가*. *Kotlin enum + when exhaustive* 컴파일러 보장 활용 미달.
+
+9. ***`Hand.stay` Boolean 시작값 = false default = 모호한 시작 상태***. *Hand 생성 시점*이 *초기 2장 분배 후* 라면 *default false 정합*. *Hand 0장/1장* 상태도 가능 — *블랙잭 invariant 부재*. PR #136·#133·#132 와 같은 결.
+
+10. ***학생 자가 학습 + 자가 후퇴 + 자가 회의 = 학습 가시화 모범***. *사이드 이펙트 → 별도 반환 후퇴*, *불변 vs 가변 자가 회의*, *방어적 복사 의문*. *trade-off 의식 = 의도적 선택* 흐름. 페로로의 *"사이드 이펙트를 사용해서 풀려 했다는 사실을, 왜 먼저 명시해주지 않으셨을까 궁금하네요"* 가 *자가 의도 명시의 중요성*. PR #131·#132·#133·#136 와 같은 결.
+
+11. ***`Hand.draw(card)` silent return vs throw IllegalStateException 트레이드오프***. *PR #152 (모찌 2단계) 의 Finish.draw throw* 와 *반대 선택*. *silent ignore = Hand 자기 invariant 강제 + 호출자 부담 없음*. *throw = 명시적 실패 + 호출자가 stay 검증 강제*. *둘 다 합리* — 도메인 의존.
+
+12. ***`generateStandardDeck()` 자체가 셔플 포함 vs `dealCard` 분기*** = *책임 분리 트레이드오프*. *셔플 = 덱 생성 시 한 번* vs *카지노 룰 = 빈 시 셔플 + 새 카드* 양쪽 표현. PR #108·#133·#136·#136 와 같은 결.
+
+13. ***`MutableList<Card>` 생성자 인자 회귀 → List<Card> 자가 후퇴 → 다시 MutableList → ...*** = *자가 학습 흐름의 왔다갔다*. 페로로 진단 = *학생이 왜 회귀했는지 자가 인식 + 명시* 권고. *학습 가시화 = 자가 결정의 근거 노출*.

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

@@ -0,0 +1,250 @@
+# PR #128 — [블랙잭 1단계] 화이팅 미션
+
+- **Reviewee:** [@ijh1298](https://github.com/ijh1298)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/128
+- **단계:** 1단계 (페어, TDD 진행)
+- **리뷰어:** @krrong (크롱)
+- **라인 코멘트:** 30 (리뷰어 13 / 리뷰이 17)
+
+## 잘한 점 (설계 관점)
+
+- **`@JvmInline value class` 적극 사용 (`CardNumber`, `Suit`) + 범위 invariant** — 원시값 포장.
+- **TDD 진행 — 테스트 / 구현 / README 체크 분리 커밋** — 리뷰어가 *한 번에 진행 권고*했지만 *TDD 사이클 가시화* 의도 명시.
+- **`Card.constructor(cardIndex: Int)` 인덱스 → CardNumber/Suit 분해 — 카드 ID 변환 유틸** (후속에 제거됨).
+- **후속 반영 폭 큼:**
+  - `value class Suit/CardNumber` → `enum class` 전환 (학생 자가 이점 설명: *유효성 검증 불필요* + *else 구문 회피*).
+  - `outputView` 확장 함수로 *UI 문자열 이관*.
+  - `Rule` 클래스 제거 + `HandCards` 일급 컬렉션 도입 (점수 계산 + Bust + 비교 책임 이전).
+  - `Player`/`Dealer` 추상화 → `Participant`로 재정의 + `compareTo` 메서드.
+  - `Deck`에 `CardsGenerator` 인터페이스 주입 (테스터빌리티).
+
+## 못한 점 (설계 관점)
+
+### 1. enum 대신 `@JvmInline value class`로 *13개 / 4개 닫힌 집합* 표현
+
+```kotlin
+@JvmInline
+value class Suit(private val index: Int) {
+    init { require(index in SUIT_INDEX_RANGE) { ... } }
+    companion object { const val MAX_SUIT_NUMBER = 4 }
+}
+
+@JvmInline
+value class CardNumber(val cardNumber: Int) {
+    init { require(cardNumber in CARD_NUMBER_RANGE) { ERROR_OUT_OF_CARD_NUMBER_RANGE } }
+    fun getValue(): Int = if (cardNumber > 10) 10 else cardNumber
+    fun getCardNumberName(): String = when (cardNumber) {
+        1 -> "A"; 11 -> "J"; 12 -> "Q"; 13 -> "K"; else -> cardNumber.toString()
+    }
+}
+```
+
+리뷰어: "enum class로 변경해볼까요? *value 클래스로 설계한 이유와 변경하면서 어떤 이점이 있었는지 설명해주세요* 🤠"
+
+학생 자가 인정: "단지 1~13의 정수만을 담으니 *원시값의 최적화에 도움이 되는 value class*로 결정하고 빠르게 넘어갔었는데, enum class로 수정하니 *애초에 13가지의 수만 선언해놓아서 이외 지정될 수 없는 정수의 유효성 검증을 하지 않아도 된다는 점*, *열거형의 장점인 한눈에 보기 쉽다는 점*의 이점을 챙길 수 있었습니다!"
+
+→ **`value class` vs `enum class` 선택 휴리스틱**: *연속 정수 + invariant*는 `value class`, *닫힌 유한 집합*은 `enum class`. 학생은 *원시값 최적화* 한 가지만 보고 선택. *유한 집합 → enum*이 더 큰 이점(컴파일러 검증 + when else 회피).
+
+### 2. `CardNumber.getCardNumberName()` UI 표현 ("A", "J", "Q", "K")
+
+리뷰어: "*어떻게 출력이 될지는 UI의 관심사이지 않을까요?* 🤔" — 일관 패턴. 후속 `outputView` 확장함수로 이동.
+
+### 3. `WinLoss.koreanText` — 도메인 enum이 한국어 문자열 보유
+
+```kotlin
+enum class WinLoss(val koreanText: String) {
+    WIN("승"), DRAW("무"), LOSE("패"),
+}
+```
+
+리뷰어: "`koreanText` 역시 *UI 영역처럼 보이네요*!" — 일관 패턴 (PR #28·#112·#125와 동일). 후속 반영.
+
+### 4. `Card(cardIndex: Int)` 보조 생성자 — 0~51 인덱스로 분해
+
+```kotlin
+data class Card(val cardNumber: CardNumber, private val suit: Suit) {
+    constructor(cardIndex: Int) : this(
+        cardNumber = CardNumber((cardIndex) % MAX_CARD_NUMBER + 1),
+        suit = Suit((cardIndex) / MAX_CARD_NUMBER),
+    ) { require(cardIndex in CARD_INDEX_RANGE) { ERROR_OUT_OF_CARD_INDEX } }
+}
+```
+
+리뷰어: "*딱 봐도 복잡하게 생겼군요...*😅 `CardNumber`와 `Suit`를 리팩터링하면서 함께 리팩터링해보면 좋겠어요." — *인덱스 ↔ (Number, Suit) 변환*은 *Card의 책임이 아님*. enum 전환 시 자연히 제거됨 (학생 인정).
+
+### 5. `Deck`이 *Singleton + 모든 카드 자동 생성 + ArrayDeque*
+
+```kotlin
+class Deck {
+    companion object {
+        private val cards = ArrayDeque(Card.CARD_INDEX_RANGE.shuffled().map { Card(it) })
+        fun giveCard() = cards.removeFirst()
+    }
+}
+```
+
+리뷰어: "덱을 생성할 때 *모든 카드가 들어있을 것이라고 예상할 수 있을까요?* 🤔 카드를 명시적으로 넣어주는 것은 어떤가요? --- *특별히 `ArrayDeque`를 사용한 이유가 있나요?*"
+
+학생: "*Deck의 네이밍에서 카드를 가지고 있을 거라 충분히 추측이 가능하다고 생각*하여 프로퍼티나 인자로 받을 필요가 없다고 생각했습니다! [...] 시작부터 셔플된 카드로 덱이 생성되면 테스트하기 어려울 듯하여 [...] *셔플된 카드를 넣는 Generator, 원하는 카드를 넣을 수 있는 Generator를 주입할 수 있도록 CardsGenerator 인터페이스*를 만들어 리팩터링을 진행했습니다!" — *이름 추론*과 *명시적 invariant 표현*은 다름. *생성자 인자*가 *invariant 가시화*. 자료구조 선택(`ArrayDeque`): "*시간복잡도 면에서 나은 ArrayDeque을 무의식적으로 사용*" — *무의식*이라는 정직한 인정.
+
+또: `companion object`로 *static cards*. *전역 변경 가능 상태* (PR #78/#65와 같은 결).
+
+### 6. `GameParticipant` abstract class의 `play()` / `isDrawFinish()` 미구현 + 미사용
+
+```kotlin
+abstract class GameParticipant(val name: String) {
+    private val cards = mutableListOf<Card>()
+    init { repeat(2) { drawCard() } }       // ⚠ init에서 추상 메서드 호출 위험 없는지?
+    fun showCards(): List<Card> = cards.toList()
+    fun drawCard() { cards += Deck.giveCard() }
+    abstract fun play()
+    abstract fun isDrawFinish(): Boolean
+}
+```
+
+리뷰어: "*`Player`, `Dealer` 모두 구현하고 있지 않은데 무엇을 위한 것인가요?* 🤔" / "*`play` 함수와 비슷하게 어떤 곳에서도 사용하고 있지 않네요* 😅" — *추상 메서드 정의*해놓고 *구현체에서 빈 함수*. *설계 의도만 적어놓고 실제 흐름이 호출 안 함*. 학생 자가 인정: "급하게 미션을 진행해서 *제가 보기에도 이상한 부분을 많이 작성*한 것 같습니다 😭" — 후속 `Participant` + `compareTo` 재정의.
+
+또: `init`에서 `drawCard()`가 *static Deck*에 의존 → *전역 상태에 의존하는 생성자*. *Participant 생성 시점에 Deck이 준비*되어야 한다는 *암묵 invariant*.
+
+### 7. `Rule` 클래스가 *모든 룰을 companion object에* — *상태 없는 정적 유틸*
+
+```kotlin
+class Rule {
+    companion object {
+        fun calculateResultByCards(cards: Collection<Card>): Int { ... }
+        fun isBurst(cards: Collection<Card>): Boolean { ... }
+        fun isDealerMustDraw(cards: Collection<Card>): Boolean { ... }
+        ...
+    }
+}
+```
+
+리뷰어: "*모든 함수가 `Collection<Card>` 를 받고 있는데 이렇게 구현한 이유는 무엇인가요?* 🤔" / "*모든 로직을 companion object에 작성*해주었는데 이러한 이유가 있을까요? 🤔"
+
+학생 자가 인정: "*상태가 필요없지만 규칙에 물어보는 용도로 Rule을 처음에 정의*했습니다. 따라서 *object처럼 사용*하게 되었습니다. 다만 [...] *명확한 역할이 정의되지 않고, 규칙이라는 광범위한 역할*을 맡다보니 *무슨 상태를 지녀야 할지, 무슨 책임을 지녀야 할지가 명확해지지 않아졌습니다*."
+
+리뷰어: "*`Rule`이 가지고 있는 모든 기능들은 알맞는 객체로 이동할 수 있는 것처럼 보여요*. 열심히 분리해보면 *`Rule` 자체를 떠나보내줄 수도* 있어보입니다. 🤠" — `Rule`이라는 *광범위 명사*가 *책임 흡인기*. 정적 유틸 + Collection 인자는 *데이터를 빼앗긴 객체*(feature-envy). 학생 후속: `Rule` 제거 + `HandCards`에 *점수 계산 + Bust 판정 + 비교* 이전. **`Rule` 같은 *범용 명사*는 책임을 흩뜨림** — 이름이 의미를 만들지 않는다 (PR #63 `BlackJack`과 같은 결).
+
+### 8. `Rule.calculateResultByCards(cards: Collection<Card>)` — Collection 추상화의 부작용
+
+학생 자가 인정: "*페어의 의견에 List, Set 등 타입을 전부 받을 수 있다는 장점*을 수긍해 그렇게 적용하였습니다! 다만 생각해보니 *저번 미션과 다르게 Set을 사용할 필요가 없다*고 생각이 듭니다. 또한 *명확한 자료형을 명시하지 않는 셈이니 혹시 모를 어떤 문제점이 발생할 수도 있을 듯합니다.*" — *유연성*은 *명확성을 비용으로*. *호출자가 어떤 타입을 줄지 모름* + *함수 내부에서 가정*. 가장 *구체적인 타입*이 보통 정답.
+
+### 9. 매직넘버 곳곳 — `21`, `16`, `10`
+
+```kotlin
+fun calculatePlayerWinLoss(...): WinLoss {
+    ...
+    if (playerScore > 21) { ... }       // ⚠ 매직 21
+}
+
+class Rule { companion object {
+    fun calculateResultByCards(cards: Collection<Card>): Int {
+        ...
+        if (1 in cardValues && (minimumSum + 10) <= BLACK_JACK_NUMBER) {   // ⚠ 매직 10
+            return minimumSum + 10
+        }
+    }
+}}
+```
+
+리뷰어: "*곳곳에 매직넘버가 자주 출몰하고 있네요. 다른 파일들도 모두 확인해주세요* 🤠" — `BUST_THRESHOLD = 21`, `ACE_BONUS = 10`, `DEALER_MUST_HIT_THRESHOLD = 16` 같은 *도메인 룰 상수* 명명.
+
+### 10. `HandCards.compareTo(opponentHandCards): GameResult` — *점수 동률 = 무승부* 오판
+
+```kotlin
+fun compareTo(opponentHandCards: HandCards): GameResult {
+    if (isBurst()) return GameResult.LOSE
+    if (getScore() > opponentHandCards.getScore()) return GameResult.WIN
+    if (getScore() == opponentHandCards.getScore()) return GameResult.DRAW
+    return GameResult.LOSE
+}
+```
+
+리뷰어: "*점수가 똑같다고 항상 비기는 것은 아니에요!* 블랙잭 룰을 다시 한 번 확인해보면 좋겠어요 🤠" — 블랙잭에서 *21 = BlackJack(2장)*과 *21 = 일반 합산*은 다름. 또 *Bust 동률*은 *무승부 아님*. *점수 동률 != 무승부*. 단순 *점수 비교*는 블랙잭 룰을 환원시킴.
+
+### 11. `HandCards.compareTo` — `if` 3개 분기
+
+리뷰어: "*조건이 3가지 이상인 경우에는 if문 보다도 when 절을 사용하는 것을 권장*합니다 🤠 ref. https://kotlinlang.org/docs/coding-conventions.html#if-versus-when" — Kotlin 코딩 컨벤션. *3개 이상 분기는 when*.
+
+### 12. `HandCards`가 *사용 안 됨* (후속에 도입했으나 다른 곳 미수정)
+
+리뷰어: "*사용하지 않는 것처럼 보이네요* 😅" — *새 객체 도입만 하고 기존 코드 갱신 누락*. 리팩토링 *반쪽*.
+
+### 13. TDD *분리 커밋* — 컴파일 안 되는 중간 커밋
+
+학생 PR 본문: "테스트 코드 작성, 구현, README 체크가 *따로 커밋*을 진행"
+
+리뷰어: "*TDD를 진행하는 것처럼 보이는데요*. [...] *한 번에 이루어지면 좋을 것 같아요* 🤠"
+
+학생 자가 토론: "이번 페어가 저번 미션에서 *TDD로 진행했음에도 불구하고 TDD로 진행한 티가 안났다*고 피드백을 받아서 이번에 *티가 나도록(?) 진행해보자*고 판단해서 이런 방식으로 커밋을 했었습니다. 다만 *컴파일 되지 않는 코드를 커밋*하면서 *이 방식으로 진행해도 되는가에 대한 찜찜함*과 의문이 남긴 했었습니다.." — *TDD 가시화*가 *컴파일 깨진 중간 커밋*을 낳음. *Red-Green-Refactor*의 *Red 상태도 함께 커밋*해야 *TDD 흔적*이 보인다는 *의도*는 이해되나, *git history는 bisect 가능*해야 의미. 학생도 *찜찜함*을 자가 인정.
+
+### 14. `HandCards.show()` + `HandCards.cards` 둘 다 노출
+
+```kotlin
+class HandCards {
+    private val _cards = mutableListOf<Card>()
+    private val cards get() = _cards.toList()    // private getter
+    fun add(card: Card) { _cards += card }
+    fun show(): List<Card> = cards               // public show()
+}
+```
+
+`show()`가 *방어적 복사된 cards*를 *그대로 반환*. *공개 API*에 `show()`/`cards` 둘 다 존재할 필요 없음. *외부에 노출할 거면 `cards: List<Card>`*가 직관, *컬렉션 전체 노출이 싫으면 `forEach`/`map` 위임만*.
+
+### 15. `CardsGenerator: interface`에 `fun interface` 폐기 토론
+
+```kotlin
+interface CardsGenerator {
+    fun createCards(): List<Card>
+}
+```
+
+리뷰어: "*fun interface로 선언했던 이유와 변경한 이유가 무엇인가요?* 🤔" — Kotlin `fun interface`는 *단일 추상 메서드*에 *람다 변환*을 허용. 학생이 *왜 `fun interface`에서 일반 `interface`로* 바꿨는지 설명 요구. *기능 선택의 근거*가 *글로 남아야* 학습 가시화.
+
+## 리뷰어 의견 요지
+
+- ***`value class` vs `enum class` 선택*** — *연속 정수 + invariant*는 value, *닫힌 유한 집합*은 enum.
+- ***UI 표현(`koreanText`, `getCardNumberName`)은 도메인 X***.
+- ***`Card.constructor(cardIndex)` 인덱스 분해는 Card의 책임 X***.
+- ***Deck Singleton + 자동 생성 = 명시 invariant 부재 + 테스터빌리티 ↓***.
+- ***abstract class의 미구현/미사용 추상 메서드 = 설계 의도만 적어놓은 잔해***.
+- ***`Rule` 광범위 명사 = 책임 흡인기*** — 책임을 적절 객체로 이전 후 `Rule` 제거 가능.
+- ***`Collection<Card>` 인자 = 명확성과 맞바꾼 유연성***.
+- ***매직넘버(21/16/10) 상수화***.
+- ***`compareTo`가 점수 동률 = 무승부 = 블랙잭 룰 환원***.
+- ***`if` 3개 이상 = `when`*** (Kotlin convention).
+- ***새 객체 도입만 + 기존 갱신 누락 = 리팩토링 반쪽***.
+- ***TDD 가시화가 컴파일 깨진 중간 커밋을 낳음 = bisect 불가***.
+
+## 대표 인용
+
+> 어떻게 출력이 될지는 *UI의 관심사*이지 않을까요? / `koreanText` 역시 *UI 영역처럼 보이네요!*
+> — @krrong on `CardNumber.kt` / `WinLoss.kt`
+
+> enum class로 변경해볼까요? *value 클래스로 설계한 이유와 변경하면서 어떤 이점이 있었는지 설명*해주세요 🤠
+> — @krrong on `Suit.kt`
+
+> `Player`, `Dealer` 모두 구현하고 있지 않은데 *무엇을 위한 것인가요?* 🤔
+> — @krrong on `GameParticipant.kt`
+
+> `Rule`이 가지고 있는 모든 기능들은 *알맞는 객체로 이동할 수 있는 것처럼* 보여요. 열심히 분리해보면 *`Rule` 자체를 떠나보내줄 수도 있어보입니다.* 🤠
+> — @krrong on `Rule.kt`
+
+> *점수가 똑같다고 항상 비기는 것은 아니에요!* 블랙잭 룰을 다시 한 번 확인해보면 좋겠어요 🤠
+> — @krrong on `HandCards.kt`
+
+## 얻은 교훈
+
+- ***`value class` vs `enum class`*** — *연속 정수 + 범위 invariant*는 `value class`, *닫힌 유한 집합*은 `enum class`. *원시값 최적화*만 보면 잘못된 선택 (학생 자가 인정).
+- ***Card 인덱스 → (Number, Suit) 분해는 Card 책임 X*** — *enum 전환 = 변환 코드 자동 제거* (학생 자가 깨달음).
+- ***Deck Singleton + 자동 생성은 invariant 명시 부재*** — 생성자에 카드 인자 + Generator 인터페이스 주입이 *invariant 가시화 + 테스터빌리티*.
+- ***abstract 메서드 정의 + 미구현 = 설계 잔해*** — *의도만 적어놓고 흐름이 호출 안 함*. 사용처가 생긴 후 정의.
+- ***`Rule` 같은 광범위 명사는 책임 흡인기*** — `HandCards`, `Participant.isDrawable`, `WinLossStatistics` 등 *적절 객체로 이전 후 `Rule` 제거*. PR #63의 `BlackJack` 객체 의미 모호와 같은 결.
+- ***`Collection<Card>` 인자 = 명확성을 비용으로 한 유연성*** — *호출 가정이 함수 내부*에 박힘. 가장 구체적 타입이 보통 정답.
+- ***매직넘버(21/16/10/2)는 도메인 룰 상수***. `BUST_THRESHOLD`, `DEALER_MUST_HIT_THRESHOLD`, `ACE_BONUS`, `INITIAL_HAND_SIZE`.
+- ***점수 동률 = 무승부는 블랙잭 룰 환원*** — *Bust 동률*은 *무승부 아님*. *21(BlackJack 2장) vs 21(일반 합산)*도 다름. *블랙잭 룰* 충실히 읽기.
+- ***`if` 3개 이상 = `when`*** (Kotlin convention).
+- ***새 객체(`HandCards`) 도입만 + 호출처 갱신 누락 = 리팩토링 반쪽*** — 전체 흐름 검증 필요.
+- ***TDD 가시화 ≠ 컴파일 깨진 중간 커밋*** — *Red 상태 커밋*은 *git history bisect 불가*. *TDD 흔적*은 *작은 단위 + 빠른 사이클*로 가시화하되 *컴파일은 항상 통과*.
+- ***`fun interface` vs 일반 `interface`*** — 단일 추상 메서드 + 람다 변환 가치가 있을 때만 `fun interface`. 선택 근거를 *글로 남기는 습관*.
+- ***`HandCards.show()` + 방어적 복사 + cards 둘 다 노출은 과잉*** — 외부 API 단순화.