oh-my-oop 0.2.0

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

@@ -0,0 +1,465 @@
+# PR #93 — [블랙잭 2단계] 에디 미션
+
+- **Reviewee:** [@junjange](https://github.com/junjange)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/93
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 21 스레드 / 51 코멘트 — *State 패턴 + Demeter + sealed vs enum* 깊은 토론 + 학생 자가 학습 모범
+
+## 잘한 점 (설계 관점)
+
+- **State 패턴 정공 — `interface State` + `abstract Started(Hand)` + `Running (Hit) / Finished (Blackjack/Bust/Stay)` 계층** — *Tell-Don't-Ask 정공*. `Hit.draw(card)` 가 *21 초과 → Bust, 2장 21 → Blackjack, 21 도달 → Stay, else → Hit* 분기로 *다음 상태 결정*. **`Blackjack.calculate(opponent: State) = if (opponent is Blackjack) Draw else BlackjackWin` 같은 다형성 메시지**. PR #136 (밀러 2단계) 의 *sealed class BlackJackRule + Stay.compare* 와 같은 결.
+- **`Finished.profit(betAmount, gameResult)` 다형성 + 메시지 응집** — *상태별 earningRate (Blackjack=1.5, Stay=1.0, Bust=-1.0) + 공통 profit 계산*. 호출자가 *isBust 분기* 없이 *state.profit(betAmount, result)* 한 줄.
+- **`Started` 부모 클래스에 `calculateHand()` 응집 — Ace 점진적 보정** — *Ace 11 기본 + repeat(aceCount) { total += 10; if > 21 → -10 + return@repeat }* 패턴:
+
+  ```kotlin
+  override fun calculateHand(): Int {
+      var total = hand.cards.sumOf { it.number.value }  // Ace=1 기본
+      val aceCount = hand.cards.count { it.number == CardNumber.ACE }
+      repeat(aceCount) {
+          total += Hand.DIFF_ACE_TO_ONE  // +10
+          if (total > Hand.BLACKJACK_NUMBER) {
+              total -= Hand.DIFF_ACE_TO_ONE
+              return@repeat  // ⚠ break
+          }
+      }
+      return total
+  }
+  ```
+
+  *Ace 각각에 11 시도 + Bust면 -10 + 종료* — *Ace 다수 정확*. PR #128·#114·#108·#131 와 같은 결.
+- **`sealed class CardHolder` + `Player` / `Dealer` 다형성** — 1단계 *open class* 자가 학습 후 *sealed* 정공. *외부 구현 차단 + 컴파일러 보장*. PR #136 (밀러 2단계) 의 *sealed class BlackJackRule* 와 같은 결.
+- **`sealed interface GameResult` + `data object BlackjackWin / Win / Lose / Draw`** — *Kotlin `data object` 활용*. *닫힌 결과 계층 + 컴파일러 when exhaustive*. PR #132 (환노) 의 *GameResult enum + earningRate* 와 *반대 트레이드오프* — *enum 부가 속성* vs *sealed object*.
+
+  ```kotlin
+  sealed interface GameResult {
+      data object BlackjackWin : GameResult
+      data object Win : GameResult
+      data object Lose : GameResult
+      data object Draw : GameResult
+  }
+  ```
+
+- **`DeckManager` interface + `GameDeck` 구현체 — DIP** — *카드 한 장 가져오는 메서드 추상화*. 말리빈 권고 *"카드 한 장을 가져오는 메서드를 인터페이스로 만들어볼 수 있겠어요"* 후속 반영. *position 인자 추가로 결정적 카드 뽑기 가능* — 테스트 용이성.
+- **`CardHolder.drawCard(card: () -> Card, shouldDrawCard: () -> Boolean, showPlayerCards: (CardHolder) -> Unit)` 고차함수** — *외부 입력 + 출력 콜백을 람다 인자로*. *Player/Dealer 가 자기 진행 자율성*. *Tell-Don't-Ask 정공*. PR #132 (환노 2단계) 의 *고차함수 시도 + 깊이 문제* 와 *비슷한 트레이드오프* — junjange 는 *적정 깊이로 안착*.
+- **`Card.from(cards: List<Card>)` 팩토리 명명 자가 학습** — 말리빈의 *"from과 of는 어떤 의미 차이가 있나요? 어떤 것은 Card를, 다른 하나는 List\<Card>를 반환하는데, 다른 개발자들도 of 와 from 의 경계를 명확히 알아차릴 수 있을까요?"* 진단 후속 반영 (커밋 `b2f1b80`).
+- **양방향 의존 자가 해소** — 말리빈 진단 *"부모가 자식을 알고 있는 형태이네요! 양방향 의존 관계가 생겨나기도 했구요"* + 학생 자가 답변 *"부모와 자식간에 결합도가 증가하여 유지보수가 힘들어질 것 같습니다! 단일 책임 원칙도 위반 될 것으로 보입니다! 의존성을 제거하고 코드를 간소화했습니다!"* (커밋 `efa1571`). **MCP 룰 후보 — `bidirectional-dependency` 변형**.
+- **Demeter 학습 + 리팩토링** — 말리빈 *"디미터의 법칙에 대해 알아보셔도 좋겠어요"* 진단 → 학생 *"네네!! 디미터의 법칙을 준수하면서 리팩터링을 진행했습니다!"* (커밋 `98299dd`). PR #133·#88 와 같은 결.
+- **타입 캐스팅 제거 자가 반영** — 말리빈 *"상태 패턴을 활용해주셨으니, 타입 캐스팅을 사용하지 않고 구현해주세요"* + 학생 자가 반영 (커밋 `15e1e77`). *다형성 활용 정공*.
+- **let/run 함수 활용 함정 자가 학습** — 말리빈의 *"이런 형태를 잘못 사용하게 된다면 let 블럭과 run 블럭 모두가 실행되는 말도 안되는 상황이 발생할 수도 있어요. let 스코프 함수 내부에 잘못된 코드를 작성했을 때 발생하게 되겠는데요, 어떤 경우에 두 스코프가 다 실행 될 수 있을지 고민해보시면 좋겠어요!"* + 학생 자가 실험 (let에서 null 반환 시 두 블록 실행) + 자가 반영. **Kotlin scope function 함정 학습 모범**.
+- **`UserInfo` 도입 — name + betAmount 묶음** — *3 변수 제약* 회피 + *Player/Dealer 공통 정보* 응집. PR #133 (시아 2단계) 의 *Items* 와 같은 결의 *제약 부산물 + 정당한 도메인 객체* 경계.
+
+## 못한 점 (설계 관점)
+
+### 1. `Hit.draw(card)` 에서 `hand.add(card)` 가변 변경 + 새 상태 반환 — *불변 표면 + 깊은 가변*
+
+```kotlin
+class Hit(private val hand: Hand = Hand()) : Running(hand) {
+    override fun draw(card: Card): State {
+        hand.add(card)  // ⚠ 기존 hand 가변 변경
+        val sumOfCard = hand.calculate()
+        return when {
+            sumOfCard > THRESHOLD_BUST -> Bust(hand)        // 새 상태 + 같은 hand 참조
+            sumOfCard == THRESHOLD_BUST && hand.cards.size == 2 -> Blackjack(hand)
+            sumOfCard == THRESHOLD_BUST -> Stay(hand)
+            else -> Hit(hand)
+        }
+    }
+    ...
+}
+```
+
+→ **`hand.add(card)` = 기존 Hand 가변 변경 + 새 State 객체 반환 + 같은 hand 참조** — PR #85 (하디 2단계) 와 같은 결의 *불변 표면 + 깊은 가변* 함정. *Hit 상태 → Bust 상태 전이* 시 *같은 Hand 참조* 라서 *이전 Hit 객체 조회 시 이미 add 된 hand*.
+
+*완전한 불변* = *`Hand(cards + card)`* 새 Hand 생성 + 새 State. *현재 `hand.add(card)`* 가변 호출.
+
+### 2. `Running.calculate(opponent): GameResult = Lose` — *진행 중 상태가 결과 반환?*
+
+```kotlin
+abstract class Running(hand: Hand) : Started(hand) {
+    override fun isFinished(): Boolean = false
+
+    override fun calculate(opponent: State): GameResult {
+        return GameResult.Lose  // ⚠ 진행 중이면 Lose?
+    }
+    ...
+}
+```
+
+→ **`Running.calculate(opponent) = Lose` = 진행 중 상태에서 결과 메서드 호출 시 무조건 Lose**. *State interface 의 `calculate` 가 모든 상태에 강제* → *Running 상태도 응답 필요*. *논리적으로는 calculate 가 호출 안 되어야 함*. *Lose 반환은 우회*. *PR #152 (모찌 2단계) 의 Hit.expectedProfit throw IllegalStateException* 와 *반대 트레이드오프*.
+
+*throw 가 정공* — *진행 중 상태에서 calculate 호출은 도메인 invariant 위반*. *Lose 반환은 silent failure* — *호출자가 결과 잘못 사용 시 디버깅 어려움*.
+
+### 3. `Running.profit(betAmount, gameResult) = 0.0` + `Finished.profit` 분기 — *책임 양분*
+
+```kotlin
+// Running
+override fun profit(betAmount: BetAmount, gameResult: GameResult): Double = 0.0
+
+// Finished
+override fun profit(betAmount: BetAmount, gameResult: GameResult): Double {
+    val rate = earningRate()
+    return when (gameResult) {
+        is GameResult.Draw -> 0.0
+        is GameResult.Lose -> -betAmount.amount.toDouble()
+        else -> betAmount.amount * rate
+    }
+}
+```
+
+→ **`Running.profit = 0.0` + Finished.profit 가 *gameResult 분기 + earningRate 곱*** — *Running 은 결과 부재 → 0*, *Finished 는 결과 + 배율*. 다만 *Bust.earningRate = -1.0* 인데 *Finished.profit 에서 `is Lose → -betAmount`* 별도 분기 — *Bust 의 earningRate(-1.0) 이 적용 안 됨*. *룰 정합* 인지 *중복* 인지 모호.
+
+실제 사용 흐름:
+- *Bust 상태 → calculate(opponent) = Lose 반환* → *Finished.profit 에 GameResult.Lose 인자 → `is Lose → -betAmount`*. *earningRate(-1.0) 미적용*.
+- *Blackjack 상태 → calculate(opponent) = BlackjackWin 반환* → *Finished.profit 에 BlackjackWin 인자 → `else → betAmount * 1.5`*. *earningRate 적용*.
+- *Stay 상태 → calculate(opponent) = Win/Lose/Draw* → *Finished.profit 분기*.
+
+→ **Bust 의 earningRate(-1.0) 이 *실제로는 미사용***. *earningRate 추상 메서드*가 *Finished 의 일관 계약*이지만 *Bust는 항상 Lose 분기로 흡수*. *Dead code* 가능성. *earningRate 의 사용처 = `else → betAmount * rate`* — *Bust 의 earningRate 호출 시점 없음*.
+
+### 4. `sealed interface GameResult` vs `enum class GameResult` 토론 — 학생 자가 학습
+
+학생 초기 선택: *sealed interface*. 말리빈 진단: *"enum class와 어떤 점이 차이가 있었나요?"*. 학생 답변: *"profit 함수에서 sealed interface를 통해 패턴 매칭을 할 때, 컴파일러가 타입 안정성을 유지하면서 코드를 검증하여 개발 과정에서 실수를 안 할 수 있는 장점이 있었습니다!"*
+
+말리빈 후속: *"enum은 말씀해주신 위 장점이 존재하지 않았나요?"*
+
+학생: *"맞습니다ㅠㅠ 제가 잘못알고있었습니다 위에 sealed interface는 특별하게 장점을 살리고 있지는 않은 것 같습니다. 그러나 추후에 BlackjackWin 상태일 때만 특정 데이터를 전달해야하는 경우에는 유요할 것 같습니다!"*
+
+말리빈: *"특별하게 장점을 살리고 있지 않다면, 저는 필요한 부분만 가져가는 것이 코드를 이해하는 데 불필요한 생각이 들지 않게 해준다 생각해요. 이렇게 할거면 왜 enum을 쓰지 않았지? 라는 의문을 들게하는 것 부터, 코드를 이해하는 데 벌써 한 번의 멈춤이 생겼다고 생각해요. 저는 최대한 필요에 의해 코드를 구성하는 것을 선호해요."*
+
+학생: *"저도 말리빈처럼 왜라고 말했을 때 답하는 것을 중요시하는데 위 부분에서 sealed class의 장점을 살리지 못한다면 enum으로 수정해야할 것 같습니다!"*
+
+→ **sealed vs enum = 도메인 차이가 있을 때만 sealed**. *현재 GameResult 4 멤버 모두 *데이터 없는 object* → enum 으로 충분*. *sealed = 멤버 별 다른 데이터 보유 가능*이 장점. *현재 도메인이 그 가능성 없음*. **MCP 룰 후보 — `sealed-without-differentiation`** *= sealed 의 멤버 별 데이터 차이 없으면 enum 권고*.
+
+학생 자가 답변에서 *"BlackjackWin 상태일 때만 특정 데이터를 전달해야하는 경우에는 유요"* 도 *미래 가능성* 이지만 *YAGNI 위반*. 말리빈의 *"필요에 의해 코드를 구성"* 가르침.
+
+### 5. `Hand.add(card)` 가변 변경 후 `cards.size` 검사
+
+```kotlin
+// Hit.draw
+hand.add(card)
+val sumOfCard = hand.calculate()
+return when {
+    sumOfCard > THRESHOLD_BUST -> Bust(hand)
+    sumOfCard == THRESHOLD_BUST && hand.cards.size == 2 -> Blackjack(hand)
+    ...
+}
+```
+
+→ **`hand.cards.size == 2`** — *Hand 의 외부에서 size 직접 접근*. *Hand.isBlackjackEligible() = cards.size == 2 && score == 21* 같은 메서드 위임이 자연. Demeter 표면.
+
+### 6. `Dealer.shouldDrawCard(): Boolean = calculateHand() <= 16` — *Dealer 자기 룰 메시지 (잘함) + Hand 알 필요 없음*
+
+```kotlin
+class Dealer(...) : CardHolder(...) {
+    fun shouldDrawCard(): Boolean = calculateHand() <= DEALER_CARD_DRAW_THRESHOLD
+    ...
+}
+```
+
+말리빈 (Dealer.kt — 미해결): *"shouldDrawCard() 이 친구는 CardHolder, Dealer, Player 모두가 갖고있는 듯한 느낌이 드네요! 공통으로 갖고있는 멤버지만, 실행했을 때 동작은 다르게 만드는 방법이 있을까요?"*
+
+학생 자가 답변: *"흠 공통으로 갖고 있어서 interface를 통해 추상화하려고 했지만.. Dealer의 shouldDrawCard는 본인의 카드 점수 합에 따라서 값이 달라지고 Player의 shouldDrawCard는 사용자의 입력에 따라서 달라지기 때문에 추상화가 쉽지 않은 것 같습니다!"*
+
+말리빈 후속: *"입력을 받아오기 위한 람다 등은 최대한 깊이를 깊게 가져가지 않았으면 했어요. 게임을 관제하는 객체를 하나 만들어둔다면 이런 람다를 도메인 깊이 알지 않을 수 있으니까요. ... 그렇다면 플레이어나 딜러나 그저 카드를 받기만 할 수 있는 객체가 되고, 줄 지 말 지는 게임 객체가 판단해줄 수도 있었겠지요!"*
+
+→ **Player/Dealer shouldDrawCard 다형성 vs Game 객체 판단**. *현재 Dealer 만 shouldDrawCard 메서드 (Player 는 외부 람다)*. *완전 다형성* = *Player.shouldDrawCard(input) / Dealer.shouldDrawCard()* 같은 *인자 통일 + 다형성*. 또는 *Game 객체 = 모든 판단 + Player/Dealer 는 받기만*.
+
+*트레이드오프*. PR #132·#136 와 같은 결의 *Participant 다형성* 가 정공.
+
+### 7. `CardHolder.calculateProfit(opponent: State)` — *state 직접 인자*
+
+```kotlin
+fun calculateProfit(opponent: State): Double {
+    val gameResult = state.calculate(opponent)
+    return state.profit(betAmount = userInfo.betAmount, gameResult = gameResult)
+}
+```
+
+→ **`opponent: State` 인자** = *Player가 다른 Player의 State 직접 받음*. *호출자 (BlackjackController)* 가 *`player.calculateProfit(dealer.state)`* 호출. *Tell-Don't-Ask*: *`player.calculateProfit(dealer)`* 가 더 자연 — *Player가 Dealer로부터 State 추출*. *State 인자 직접 노출*은 *내부 표현 의존*.
+
+### 8. `BetAmount` 의 *문자열 파싱이 도메인 책임?* 자가 학습
+
+학생 초기: *문자열 파싱이 도메인 책임*. 말리빈 진단: *"문자열을 파싱해서 BetAmount를 만든다는 것은 도메인의 역할일까요?"*. 학생 자가 답변: *"배팅 금액에 대한 유효성 검증 이후, 문자열을 파싱하는 것은 도메인의 역할이라고 생각했습니다! 그런데, 다시 생각해보니 view의 역할에 더 적합한 것 같습니다!"* (커밋 `7ada402`).
+
+→ **도메인 vs View 책임 자가 학습**. *문자열 파싱 = View*, *유효성 검증 = 도메인*. *PR #132 (환노 2단계) 의 View가 사용자 의도 표현* 진단과 같은 결.
+
+### 9. `BlackjackState` vs `Blackjack` naming 모호 → State 로 변경 시도 → 말리빈 reminder
+
+학생 초기: `BlackjackState` 와 `Blackjack` 두 객체. 말리빈: *"BlackjackState 와 Blackjack은 처음 보는 개발자들이 서로 어떻게 다른 객체인지 내부 구현을 자세히 보지 않고 파악할 수 있을까요?"*. 학생: *"잘 모를 것 같습니다 BlackjackState를 State로 수정하겠습니다!"* (커밋 `5a66d0a`).
+
+말리빈 후속: *"앗 ㅋㅋㅋ 아래 피드백을 다시 곱씹어볼까요 ?_?"* + 1단계 피드백 링크.
+
+→ **이름 모호함 자가 해소 + 1단계 피드백 회귀 신호**. *학생이 이름 모호함 진단 받고 다시 변경했지만 이전 피드백 (`State` vs `Blackjack`) 와 같은 결*. *학습 가시화 + 재발견*.
+
+### 10. `Card.create` 와 `companion object card` 중복 — 자가 발견
+
+말리빈: *"create라는 이름으로 무언가 새로운 인스턴스를 생성할 것 처럼 느껴지네요. companion object 의 card를 직접 접근하는 것과 어떤 차이점이 있는지 모르겠어요. 전체적으로 필요하지 않은 코드들을 다듬어 덜어내는 연습을 해보세요"*
+
+학생: *"헉 지금 다시보니 중복되는 내용이네요ㅠㅠ 감사합니다!"* (커밋 `0d2b950`).
+
+→ **중복 코드 자가 발견 + 삭제**. *create / companion val card 둘 다 *기존 캐시 lookup**. *호출자가 둘 중 어느 것 호출하는지 모호*. *Kotlin 어휘 정공 = factory function 한 가지*.
+
+### 11. `DeckManager.drawCard(position: Int)` — *position 의미*
+
+```kotlin
+interface DeckManager {
+    fun resetDeck(cards: List<Card>? = null)
+    fun drawCard(position: Int): Card
+}
+
+class GameDeck : DeckManager {
+    private val deck: MutableList<Card> = Card.cards.shuffled().toMutableList()
+
+    override fun drawCard(position: Int): Card {
+        if (position < deck.size) {
+            return deck.removeAt(position)
+        }
+        resetDeck()
+        return deck.removeAt(position)
+    }
+    ...
+}
+```
+
+말리빈 (DeckManager.kt:7 — 미해결): *"이전 피드백에 이어서, 기대한 인터페이스는 카드 단 한장만을 가져오는 메서드만 가진 인터페이스였어요. `interface ~ { fun getCard(): Card }`. 랜덤의 요소를 최소화해본다 라는 것에 가장 많이 고민해보세요. reset은 랜덤의 요소였을지, position은 랜덤의 요소였을지 연관지어서요! 1, 2 단계 미션에서 배운 것들을 완전히 자신의 것으로 만들어보세요"*
+
+→ **`position: Int` 인자 = 랜덤 요소 외부 노출**. *덱이 랜덤이면 *어떤 position 카드든 랜덤** — *position 명시 의의 부재*. *카드 한 장만 받는 메서드*가 *최소 인터페이스*. *학생 의도*는 *테스트 시 결정적 카드* 였으나 *전략 패턴 (ShuffleStrategy)* 이 정공. *position 인자*는 *외부에서 덱 내부 구조 의존*.
+
+학생 자가 답변: *"랜덤의 요소를 최소화하는 것에 대해서 좀 더 고민해보겠습니다!.."*
+
+→ **인터페이스 추상화의 적정 수준 학습 진행 중**. *DeckManager 의 `resetDeck(cards: List<Card>? = null)` + `drawCard(position: Int)`* 가 *외부 제어 표면*. *진짜 인터페이스 = `fun draw(): Card` 한 메서드*. *resetDeck 도 외부 호출 불필요* — *덱이 비면 자동 셔플 + 새 덱*. PR #108·#133 (시아) 와 같은 결.
+
+### 12. `Card.cards` 같은 *전역 카드 풀* — *Card 객체가 자기 풀 알고 있음*
+
+```kotlin
+private val deck: MutableList<Card> = Card.cards.shuffled().toMutableList()
+```
+
+→ **`Card.cards` companion val** = *52장 카드 list 전역*. PR #108·#133 (시아) 의 *`Card.SINGLE_DECK` 위치 모순* 과 같은 결. *Card = 1장* vs *Card.cards = 52장 모음* 의미 충돌. *DeckManager.STANDARD_DECK* 또는 *Deck.companion val* 이 자연.
+
+### 13. `userInfo` naming — 만능 명사
+
+```kotlin
+sealed class CardHolder(val userInfo: UserInfo)
+
+data class UserInfo(val nickname: Nickname, val betAmount: BetAmount = BetAmount())
+```
+
+→ **`UserInfo` = 만능 명사 (Information)** — PR #88·#114·#125 의 *vagueName 안티패턴* 변형. *블랙잭 도메인에서 `UserInfo` 가 자연한 어휘*인지 *3 변수 제약 부산물*인지 모호. *Player(nickname, betAmount)* 직접 인자 + *CardHolder 는 두 멤버 공통 보유*가 *명시적*.
+
+다만 *Player + Dealer 가 공통 정보 (nickname, betAmount) 보유* + *Dealer 도 nickname/betAmount 필요* 라면 *UserInfo 응집* 정합. *Dealer 의 betAmount = 0 default* — *Dealer 가 베팅 안 하는 도메인 룰 vs UserInfo 일관성* 트레이드오프.
+
+### 14. `Started.calculateHand` 의 *Ace 보정 후 return@repeat*
+
+```kotlin
+override fun calculateHand(): Int {
+    var total = hand.cards.sumOf { it.number.value }
+    val aceCount = hand.cards.count { it.number == CardNumber.ACE }
+    repeat(aceCount) {
+        total += Hand.DIFF_ACE_TO_ONE
+        if (total > Hand.BLACKJACK_NUMBER) {
+            total -= Hand.DIFF_ACE_TO_ONE
+            return@repeat  // ⚠ break (Kotlin repeat의 continue)
+        }
+    }
+    return total
+}
+```
+
+→ **`return@repeat` = 단일 iteration 종료 (continue 의미)**. *Kotlin `repeat` 에 break 없음* — *continue 만 가능*. *while loop 변환*이 *break 의도 명시*. 현재 코드는:
+- *iter 1: total += 10*. *if > 21 → total -= 10 + continue → iter 2*
+- *iter 2: total += 10*. ...
+
+*Ace 다수 정확 처리*. 다만 *return@repeat 의미가 *continue* 라 *Kotlin 어휘 미숙자에겐 함정**. *while loop* 이 *break 의도 명시*:
+
+```kotlin
+var aceCount = ...
+while (aceCount > 0 && total > 21) {
+    total -= 10
+    aceCount--
+}
+```
+
+PR #136·#108·#131 의 *while 패턴* 과 같은 결.
+
+### 15. `Card.cards` 전역 + `GameDeck.drawCard` 가 *resetDeck* 호출 — *position 의미*
+
+```kotlin
+override fun drawCard(position: Int): Card {
+    if (position < deck.size) {
+        return deck.removeAt(position)
+    }
+    resetDeck()
+    return deck.removeAt(position)
+}
+```
+
+→ **`position >= deck.size` 면 resetDeck + removeAt(position)** — *resetDeck 후 새 덱이 적어도 position+1 장*. *Card.cards.shuffled().toMutableList()* = *52장*. *position < 52* 면 정합. *position == 52* 같은 경계 케이스에서 *IndexOutOfBoundsException* 가능성. *position 인자 자체*가 *외부 책임 노출*. PR #108·#133 (시아) 의 *카드 부족 시 자동 셔플* 패턴과 다름.
+
+### 16. `Bust.earningRate(): Double = -1.0` Dead code 가능성 — 못한 점 §3 보강
+
+```kotlin
+class Bust(hand: Hand) : Finished(hand) {
+    override fun earningRate(): Double = -1.0
+
+    override fun calculate(opponent: State): GameResult {
+        return Lose
+    }
+}
+```
+
+→ **`Bust.earningRate(-1.0)` 추상 메서드 구현이지만 *호출 흐름에서 미사용***. *Bust.calculate → Lose → Finished.profit → `is Lose → -betAmount`* 분기 — *earningRate 호출 없음*. *추상 메서드 계약* + *실 사용 0* = *dead code*. *Finished.profit 의 `else -> betAmount * rate`* 가 *earningRate 사용처* 인데 *Bust 는 항상 Lose 분기*.
+
+*해결*: *Finished.profit 의 `is Lose → betAmount * rate` (Bust 는 rate=-1 이므로 -betAmount)* 가 *통일*. 현재는 *분기 분리 + earningRate 일부 dead*.
+
+### 17. `let / run` 함수 함정 학생 자가 검증
+
+학생 자가 실험 코드:
+```kotlin
+fun main() {
+    var test: Int? = 1
+    test?.let {
+        println("let 실행됨")
+        test = null
+        null
+    } ?: run {
+        test = 1
+        println("run 실행됨")
+    }
+    println(test)
+}
+```
+
+말리빈 답변: *"네! 맞아요. 생각보다 null을 반환하는 메서드들이 꽤나 많답니다. 특히 java의 메서드가 non-null 이라고 착각했을 때 자주 발생하게 되지요. 지금은 예시 코드를 작성하시면서 \"무슨 이런 말도안되는 일이 발생할까? 너무 방어적인것 아닐까?\" 하는 생각이 드실 수 있겠지만, 생각보다 자연스러운 코드인데도 이런 현상이 발생해버린다면, 디버깅할때 굉장히 골치아파진답니다. 코드는 자연스러운데, 실행은 비정상적이니, 원인을 찾아내는 데 굉장히 어려워지게돼요."*
+
+→ **let / run 함수 함정 = null 반환 시 두 블록 실행**. *학생이 자가 검증 코드 작성 → 함정 확인 → 후속 반영*. *Kotlin scope function 학습 모범*. **MCP 룰 후보 — `let-run-elvis-pitfall`**.
+
+## 리뷰어 의견 요지
+
+- **State 패턴 정공 (Running/Finished + Blackjack/Bust/Stay)** + **타입 캐스팅 제거 = 다형성 활용**.
+- **sealed vs enum = 필요한 만큼만**. *멤버 별 데이터 차이 없으면 enum*. *코드 이해 시 *왜 sealed 인가* 의문 = 인지 비용*.
+- **bidirectional dependency = 부모-자식 결합도 증가 + SRP 위반** — 학생 자가 학습 + 해소.
+- **Demeter + 위임 메서드** — *a.b.c.d 점 체인 회피*.
+- **scope function 함정 — let의 null 반환 시 run 도 실행** — *디버깅 어려움*.
+- **랜덤 요소 최소화 = 카드 한 장 가져오는 인터페이스** — *position 인자는 외부 책임 노출*. *현재 DeckManager.resetDeck + drawCard(position)* 는 *외부 제어 표면*. *진짜 인터페이스 = `fun draw(): Card`*.
+- **명명 = 의미 표현** — *`newCardHolder` (print용 람다인지 알기 어려움)*, *`from / of` 경계 명료*, *BlackjackState vs Blackjack 모호*.
+- **추상화 = 공통의 요소 뽑기** — *Player/Dealer 의 shouldDrawCard 공통 메서드 다형성 시도* + *Game 객체 분리 권고*.
+- **`라면 끓이기` 비유 = 함수 이름이 *과정 설명* X, *결과/의도* O** — *카드의 합산 가져오기 / 손계산하기 한 단어*.
+- **단일 책임 (`Card.create` vs `companion val card` 중복)** — *불필요한 코드 다듬기*.
+
+## 대표 인용
+
+**말리빈 (sealed vs enum, GameResult.kt:10):**
+> enum은 말씀해주신 위 장점이 존재하지 않았나요?
+> ...
+> 특별하게 장점을 살리고 있지 않다면, 저는 필요한 부분만 가져가는 것이 코드를 이해하는 데 불필요한 생각이 들지 않게 해준다 생각해요.
+> 이렇게 할거면 왜 enum을 쓰지 않았지? 라는 의문을 들게하는 것 부터, 코드를 이해하는 데 벌써 한 번의 멈춤이 생겼다고 생각해요.
+> 저는 최대한 필요에 의해 코드를 구성하는 것을 선호해요 :)
+
+**말리빈 (랜덤 요소 최소화 + 인터페이스 추상화, DeckManager.kt:7):**
+> 이전 피드백에 이어서,
+> 기대한 인터페이스는 카드 단 한장만을 가져오는 메서드만 가진 인터페이스였어요.
+> ```kotlin
+> interface ~ {
+>     fun getCard(): Card
+> }
+> ```
+>
+> 랜덤의 요소를 최소화해본다 라는 것에 가장 많이 고민해보세요.
+> reset은 랜덤의 요소였을지, position은 랜덤의 요소였을지 연관지어서요!
+>
+> 1, 2 단계 미션에서 배운 것들을 완전히 자신의 것으로 만들어보세요 :)
+> 미션을 모두다 다시 한 번 구현해보는 것도 좋은 방법이 될 거예요 🙂
+
+**말리빈 (scope function 함정, GameDeck.kt):**
+> if - else 를 활용하는 것이 가독성에 더욱 도움이 되는 경우가 많아요.
+>
+> 또, 이런 형태를 잘못 사용하게 된다면 let 블럭과 run 블럭 모두가 실행되는 말도 안되는 상황이 발생할 수도 있어요.
+> let 스코프 함수 내부에 잘못된 코드를 작성했을 때 발생하게 되겠는데요,
+> 어떤 경우에 두 스코프가 다 실행 될 수 있을지 고민해보시면 좋겠어요!
+
+**말리빈 (라면 끓이기 비유, CardHolder.kt):**
+> `카드의 합산 가져오기` `손계산하기` 이 둘에 대한 이름은 한 단어를 가리키기도 하네요.
+>
+> `냄비에물550ml를넣고빨간가루가들어있는손바닥만한봉투를뜯어물에뿌린다음100도씨까지올려서건조된밀가루무언가를넣고3분간기다린다`
+> 라는 이름보다,
+> `라면 끓이기`
+> 라는 이름을 지어보는 연습을 해보세요 :)
+
+**말리빈 (Player/Dealer 공통 추상화 + Game 객체 권고, Dealer.kt):**
+> 입력을 받아오기 위한 람다 등은 최대한 깊이를 깊게 가져가지 않았으면 했어요.
+> 게임을 관제하는 객체를 하나 만들어둔다면 이런 람다를 도메인 깊이 알지 않을 수 있으니까요.
+> 그래서 처음에 달아둔, ... 이 피드백을 남겨두기도 했었지요!
+> 그렇다면 플레이어나 딜러나 그저 카드를 받기만 할 수 있는 객체가 되고, 줄 지 말 지는 게임 객체가 판단해줄 수도 있었겠지요!
+> 추상화를 활용한다면 최대한 공통의 요소를 뽑아내려 고민을 많이 해보세요.
+
+**말리빈 (bidirectional dependency, CardHolder.kt):**
+> 부모가 자식을 알고 있는 형태이네요!
+> 양방향 의존 관계가 생겨나기도 했구요.
+> 둘은 어떤 문제점이 생길 수 있을까요?
+
+**학생 자가 학습 (let / run 함정 자가 실험, GameDeck.kt):**
+> ```kotlin
+> fun main() {
+>     var test: Int? = 1
+>     test?.let {
+>         println("let 실행됨")
+>         test = null
+>         null
+>     } ?: run {
+>         test = 1
+>         println("run 실행됨")
+>     }
+>     println(test)
+> }
+> ```
+> let과 run 블럭 모두 실행되는 경우가 위 상황처럼 let에서 null을 반환하는 경우일까요?!
+> 위 같은 오류가 발생할 수 있다고 판단하여 수정했습니다!
+
+**학생 자가 답변 (sealed → enum 자가 후퇴, GameResult.kt:10):**
+> 맞습니다ㅠㅠ 제가 잘못알고있었습니다 위에 sealed interface는 특별하게 장점을 살리고 있지는 않은 것 같습니다.
+> 그러나 추후에 BlackjackWin 상태일 때만 특정 데이터를 전달해야하는 경우에는 유요할 것 같습니다!
+> ...
+> 저도 말리빈처럼 왜라고 말했을 때 답하는 것을 중요시하는데 위 부분에서 sealed class의 장점을 살리지 못한다면 enum으로 수정해야할 것 같습니다!
+
+**학생 자가 답변 (bidirectional dependency 해소, CardHolder.kt):**
+> 부모와 자식간에 결합도가 증가하여 유지보수가 힘들어질 것 같습니다! 단일 책임 원칙도 위반 될 것으로 보입니다! 의존성을 제거하고 코드를 간소화했습니다!
+
+**학생 자가 답변 (Player/Dealer 추상화 한계 + 추가 학습 의지, Dealer.kt):**
+> 흠 공통으로 갖고 있어서 interface를 통해 추상화하려고 했지만.. Dealer의 shouldDrawCard는 본인의 카드 점수 합에 따라서 값이 달라지고 Player의 shouldDrawCard는 사용자의 입력에 따라서 달라지기 때문에 추상화가 쉽지 않은 것 같습니다!
+> ...
+> 저도 그것에 대해서 고민이 많았고 해결하고 싶었지만 해결하지 못했네여ㅠㅠ 좀 더 고민해보겠습니다! 감사합니다!!
+
+## 얻은 교훈
+
+1. ***State 패턴 정공 = sealed + 다형성 + 외부 if 0개***. *Running (Hit) → Finished (Blackjack/Bust/Stay)* 계층 + *calculate/profit 메시지 다형성*. *호출자가 if (state is X) 분기 0개* 가 *State 패턴 핵심*. PR #136·#152·#133·#131 와 같은 결.
+
+2. ***sealed vs enum = 필요한 만큼만***. *멤버 별 데이터 차이 없으면 enum 충분*. *sealed = 멤버 별 다른 데이터/메서드 가능*이 진짜 장점. *"왜 sealed?"* 의문 자체가 *코드 이해 비용*. **MCP 룰 후보 — `sealed-without-differentiation`**. PR #136 (밀러 2단계) 의 *sealed class 선택 근거 명시* 와 *반대 트레이드오프*.
+
+3. ***bidirectional dependency = 부모-자식 결합도 증가 + SRP 위반***. *부모가 자식 알고 있는 형태* = *수정의 파급 범위 ↑*. *DIP* 위반 가능성. 학생 자가 학습 + 해소 모범. **MCP 룰 후보 — `bidirectional-dependency`**.
+
+4. ***Kotlin scope function 함정 — `let의 null 반환 시 elvis run 도 실행`*** — *Java non-null 가정 오류 + 디버깅 어려움*. *학생 자가 실험 + 검증 모범*. **MCP 룰 후보 — `let-run-elvis-pitfall`** (Kotlin 한정).
+
+5. ***랜덤 요소 최소화 = 카드 한 장 받는 인터페이스***. *`fun draw(): Card`* 단일 메서드. *position 인자, reset 메서드* 는 *외부 책임 노출 + 랜덤 요소 X*. *DeckManager 의 진짜 책임 = 카드 한 장 제공*. *진짜 추상화 = 가장 단순한 메시지*. PR #108·#133·#136 와 같은 결.
+
+6. ***도메인 vs View 책임 = 문자열 파싱은 View, 검증은 도메인***. *PR #93 학생 자가 학습 + 후속 반영*. PR #132·#133·#88 와 같은 결의 *View 의도 표현*.
+
+7. ***`라면 끓이기` 비유 = 함수 이름은 결과/의도, 과정 설명 X***. *`카드의 합산 가져오기` vs `손계산하기`* 한 단어 가리키면 *합치기*. *Kotlin 어휘에서 *짧고 의미 있는 이름** 정공. PR #128·#114 의 *vagueName 안티패턴* 과 *반대 방향*.
+
+8. ***명명 모호함 (`BlackjackState` vs `Blackjack`)*** — *개발자가 내부 구현 봐야 차이 알면 명명 실패*. *State 로 변경* 자가 반영 → *1단계 피드백 회귀*. PR #128·#136·#88 와 같은 결의 *naming = 책임 표현*.
+
+9. ***`UserInfo` 만능 명사 = vagueName 변형***. *Information* 어휘는 *책임이 안 잡힌 곳에 등장*. *Player(nickname, betAmount)* 직접 인자가 *명시*. 다만 *Player + Dealer 공통 정보 응집* 시 정당화 가능. PR #88·#125·#114 의 *vagueName 안티패턴 확장*.
+
+10. ***`Running.calculate = Lose` silent failure***. *진행 중 상태에서 결과 메서드 호출 시 무조건 Lose 반환*. *throw IllegalStateException 가 정공*. *PR #152 (모찌 2단계) 의 Hit.profit throw* 와 *반대 트레이드오프*. *silent = 디버깅 어려움*.
+
+11. ***`Bust.earningRate` Dead code 가능성 = State 추상 메서드 통일 부작용***. *Bust.calculate = Lose → Finished.profit 의 `is Lose → -betAmount` 분기 → earningRate 미사용*. *추상 메서드 계약 일관성 vs 실 사용 일치성* 트레이드오프.
+
+12. ***고차함수 + 명시적 인터페이스 = 입력 콜백 추상화***. *`drawCard(card: () -> Card, shouldDrawCard: () -> Boolean, showPlayerCards: (CardHolder) -> Unit)`* 3 콜백 인자. *PR #132 (환노) 의 고차함수 시도 + 깊이 문제* 와 *비슷한 트레이드오프* — junjange 는 *적정 깊이로 안착*.
+
+13. ***`Hit.draw(card)` 가변 변경 + 새 State 반환 = 불변 표면 + 깊은 가변***. PR #85 (하디 2단계) 와 같은 결. *완전 불변 = Hand(cards + card) 새 Hand 생성*. *현재 hand.add(card) 가변 호출 → 같은 hand 참조 새 State* = *호출자 혼란 가능성*.
+
+14. ***`return@repeat` = continue 의미, Kotlin repeat 에는 break 없음***. *Ace 보정 패턴 정확*하지만 *break 의도 모호*. *while loop* 이 *break 의도 명시*. *Kotlin 어휘 미숙자 함정*.
+
+15. ***Card.cards companion val = 전역 카드 풀 위치 모순***. *Card = 1장* 인데 *Card.cards = 52장 풀*. *DeckManager.STANDARD_DECK* 또는 *Deck companion val* 이 자연. PR #108·#133 와 같은 결.
+
+16. ***학생 자가 학습 + 자가 실험 (let/run 검증 코드) + 자가 후퇴 (sealed → enum) = 학습 가시화 최고 수준***. *말리빈 깊은 진단 → 학생 자가 검증/실험 → 자가 결론 + 후속 반영* 흐름이 *모범 학습*. PR #128·#135·#108·#133·#136 와 같은 결의 학생 자가 토론 풍부 패턴.