oh-my-oop 0.2.0

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

@@ -0,0 +1,248 @@
+# PR #125 — [블랙잭 1단계] 제리 미션
+
+- **Reviewee:** [@jerry8282](https://github.com/jerry8282)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/125
+- **단계:** 1단계 (페어, *딜러의 두 역할* 토론 출발점)
+- **리뷰어:** @krrong (크롱)
+- **라인 코멘트:** 30 (리뷰어 17 / 리뷰이 13)
+
+## 잘한 점 (설계 관점)
+
+- **`Blackjack` 진행자 객체 분리 — 딜러의 *카드 배부 역할*을 떼냄** (PR 본문 학생 자가 결정).
+- **`Participants` 추상 클래스 + `Dealer`/`Player` 상속** — interface가 아닌 `abstract class`로 상태 공유 (PR #123 학생의 후속 결론과 같은 결).
+- **`CardShuffler` 인터페이스 + `FalseShuffle` fake** — Deck 셔플을 *주입형 전략*으로 (lotto의 `non-newable` 패턴 재현).
+- **`ActionType` enum (Hit/Stay)** — 행동을 도메인 어휘로.
+- **`BeforeEach` test fixture 적극 활용** — 후속 반영.
+- **`Deck`에 `ArrayDeque`** — *위에서 한 장씩* 자료구조 일치.
+- **후속 반영 — `protected`/`protected set`으로 *외부 변경 차단*** — `dealer.cards.clear()` / `dealer.status = Win` 같은 외부 변경 위험을 봉인.
+- **후속 반영 — `Shape`의 영문 출력 제거 + OutputView 이관** + **`CardShuffler` 폐기 → Deck이 카드 인수로 받음** (Strategy 과잉 폐기).
+
+## 못한 점 (설계 관점)
+
+### 1. PR 본문에서 학생 자가 의문 — *카드 배부 진행자가 누구인가*
+
+학생 PR 본문: "실제 블랙잭에서는 카드를 나누어주는 역할이 딜러의 역할입니다. 하지만, 이번 블랙잭 미션에서는 딜러에게 *카드를 나누어주는 진행자의 역할*과 *게임 참여자의 역할, 두 가지를 하게 될 거 같아* Blackjack 객체를 따로 생성하여 카드를 배부해주는 역할을 주었습니다."
+
+리뷰어: "딜러의 역할이 게임 참여자와 진행자의 역할, 두 가지를 하게 될 거 같다는 점에 동의해요 👍 [...] 하지만 지금은 카드를 배부하는 역할 외에도 다른 역할을 하고 있는 것처럼 보여요. 역할을 잘 정했으니 그 역할에 맞는 일만 하도록 구성해볼까요? 🤠" — *역할 분리*는 옳았으나 *Blackjack*이라는 진행자가 *점수 비교*, *Hit/Stay 판정*, *결과 계산* 등 *진행 외 역할*까지 떠안음. *Blackjack = 카드 배부*만으로 좁히기.
+
+### 2. `Shape`/`ParticipantStatus` enum에 *UI 출력 문자열* 보유
+
+```kotlin
+enum class Shape(val symbol: String) {
+    Spade("♠"), Heart("♥"), ...
+}
+enum class ParticipantStatus {
+    None, Win, Lose, Bust, Draw,
+}
+// + Player.toString() 오버라이드 검토 중
+```
+
+학생 자가 토론: "출력 정보를 enum에서 관리할지, view에서 확장함수로 관리할지도 많이 고민했는데요 🤔 enum을 적용할 시, `리팩터링 시 변경 범위가 최소화된다` 라는 장점이 있습니다. 만약에 영문 출력이 생길 경우, enum 의 프로퍼티에만 추가하면 되므로, 출력문을 enum에서 관리하는 것이 유지보수 측면에서 합당하다고 판단하였습니다."
+
+리뷰어: "출력 정보가 도메인일까? 에 대해 고민해보면 좋을 것 같은데요 🤔 언급하신대로 enum에 영문을 추가하는 것으로 변경사항이 적어질거에요. 같은 이유로 `ParticipantStatus` 역시도 승, 패, 무 String을 가질 수 있고, 플레이어의 이름과 카드를 출력하기 위해 `Player`의 `toString`을 오버라이드 할 수 있습니다. 점점 도메인과 뷰의 경계가 무너지게 되고 구분할 수 없는 형태가 되어버릴거에요." — *변경 최소화*라는 단기 이익이 *도메인-뷰 경계 붕괴*라는 장기 비용. lotto `side-effect-in-holder` 룰과 동일 결.
+
+### 3. `Participants.cards: MutableList<Card>`가 abstract public — 외부 변경 위험
+
+```kotlin
+abstract class Participants() {
+    abstract val name: String
+    abstract val cards: MutableList<Card>           // 외부에서 .clear() 가능
+    abstract var status: ParticipantStatus          // 외부에서 .status = Win 가능
+}
+```
+
+리뷰어: "```kotlin val dealer = Dealer(); dealer.cards.clear() ``` 어떤 일이 발생할까요? 🤔" / "```kotlin val dealer = Dealer(); dealer.status = ParticipantStatus.Win ``` 어떤 일이 발생할까요? 🤔🤔" — *공개 mutable 컬렉션 + var setter*는 *invariant 무방비*. 학생 후속 반영: `protected set` + `protected val _cards`로 캡슐화. (그러나 *왜 처음부터 protected가 자연*인지가 학습 포인트.)
+
+### 4. `Deck(cardShuffler: CardShuffler)` + `Deck.deck: ArrayDeque<Card>` — 자기 이름 보유
+
+```kotlin
+class Deck(cardShuffler: CardShuffler) {
+    private val deck: ArrayDeque<Card> = initCard(cardShuffler)   // Deck 안에 deck
+}
+```
+
+리뷰어: "`Deck`이 `deck`을 가지고 있네요. 함께 일하는 동료 개발자가 헷갈리지 않을까요?" — *클래스 == 속성*이면 *의미*가 동어반복. `cards` / `remaining`이 자연.
+
+리뷰어: "덱을 생성할 때 52장의 카드가 들어있을 것이라고 예상할 수 있을까요? 카드를 명시적으로 넣어주는 것은 어떤가요? 🤔" — *Deck 생성자가 52장 자동 생성 + 셔플*은 *외부에서 보이지 않는 부작용*. `Deck(cards: List<Card>)`로 *명시적 주입*하면 *Strategy 패턴* 자체가 불필요. 학생 후속: Strategy 폐기 + `Deck(cards)` 채택.
+
+### 5. `FalseShuffle`이 *프로덕션 패키지*에 위치
+
+```kotlin
+// src/main/kotlin/blackjack/model/strategy/FalseShuffle.kt
+class FalseShuffle : CardShuffler { ... }
+```
+
+리뷰어: "테스트 코드를 위한 클래스는 테스트 패키지에 있는 것이 좋아요 🤠" — *fake 구현*은 `src/test/kotlin/`에. 프로덕션 패키지에 두면 *프로덕션 빌드에 fake가 노출* + *Strategy 인터페이스가 fake 때문에 존재*하는 구조가 됨.
+
+### 6. `Dealer.overThreshold()` 함수명 모호
+
+```kotlin
+class Dealer(override val name: String = DEALER_NAME) : Participants() {
+    fun overThreshold(): Boolean = sumCardNumber > THRESHOLD
+}
+```
+
+리뷰어: "딜러가 Hit이 가능한 상태인지를 확인하는 일을 하는 것처럼 보이는데, 메서드명만보고 이를 쉽게 알 수 있을까요? 🤔" — `overThreshold`는 *비교 동작*이고 *결과의 의미*(Hit 가능 / 종료 가능)가 함수명에 없음. `mustHit()`, `canDraw()`, `shouldStop()` 같이 *결과 동사*.
+
+### 7. `Player.compareScores(number: Int)` — Tell-Don't-Ask 부분 위반
+
+```kotlin
+class Player(override val name: String) : Participants() {
+    fun compareScores(number: Int) {
+        if (status != ParticipantStatus.Bust) {
+            status = ParticipantStatus.compare(sumCardNumber, number)
+        }
+    }
+}
+```
+
+리뷰어: "현실 세계에서는 딜러와 플레이어 간의 점수를 비교하지만, 객체 관점에서는 모두 동일한 참가자 역할을 가지는데요, 이는 참가자가 다른 참가자와 점수를 비교할 수 있다는 의미입니다. 예를 들면, `플레이어 vs 플레이어` 또는 `딜러 vs 플레이어` 도 가능하겠죠 🤠"
+
+학생 응답: "해당 프로젝트에서는 플레이어와 딜러를 비교하여 플레이어의 상태 변경을 하기 때문에 딜러는 플레이어의 상태에 따라 승패를 판단하게 하였습니다. 따라서, 딜러의 입장에서의 비교 로직은 필요없다고 판단하였고 플레이어에만 비교로직을 사용하였습니다." — `compareScores(number: Int)`는 *상대를 Int로 받음* = *상대 객체에 메시지 못 보냄*. `compete(other: Participant)`로 *동일 추상*에 메시지 보내는 것이 자연. PR #63의 *상대가 누구라도 상관없는 비교*와 같은 결.
+
+### 8. `ParticipantStatus`에 *게임 결과 상태*와 *플레이어 상태* 혼재
+
+```kotlin
+enum class ParticipantStatus() {
+    None,      // 초기
+    Win,       // 게임 결과
+    Lose,      // 게임 결과
+    Draw,      // 게임 결과
+    Bust,      // 플레이어 상태 (카드 합 > 21)
+}
+```
+
+리뷰어: "게임 결과에 대한 상태(`Win, Lose, Draw`)와 플레이어의 상태(`Bust`)가 혼재되어 있는 것처럼 느껴져요. 둘은 성격이 다른 것처럼 느껴지는데 제리는 어떻게 생각하나요? 🤔" — *게임 진행 상태*(Ready/Hit/Stay/Bust/BlackJack)와 *결과 판정*(Win/Lose/Draw)은 *다른 축*. 한 enum에 합치면 *생애주기 혼란* + *불가능한 전이*(예: `Bust → Win`인지 `Bust → Lose`인지). PR #78 (dpcks0509)의 `State` sealed interface가 이 문제를 해결하는 모델.
+
+### 9. `service/Blackjack` vs `domain/` 구분 — Spring 어휘 차용
+
+리뷰어: "service와 domain은 무엇이 다른지 설명해주세요 🤔"
+학생: "**domain**은 객체의 정보를 저장하고 해당 객체가 스스로 데이터를 가공하고 처리한다고 생각하고, **service**는 여러 domain에 있는 객체에게 메시지를 주고 받게 하고 각 객체들 간의 협력을 조정해주는 역할을 한다고 생각합니다."
+
+학생 설명은 *교과서적 정의*지만 *콘솔 게임*에서 *Service 레이어*는 *Controller와 중복 가능성 ↑*. *Service*가 *프레임워크 어휘*(Spring)인지 *도메인 어휘*인지 판단 필요. 콘솔에선 `model/` 안에 `Game` 단일 진행자로 충분.
+
+### 10. `Blackjack.shouldStopDrawing(action, player)`가 *두 일* 수행
+
+```kotlin
+fun shouldStopDrawing(playerAction: ActionType, player: Player): Boolean {
+    when (playerAction) {
+        ActionType.Hit -> hitAction(player)      // 부작용: 카드 추가
+        ActionType.Stay -> return true
+    }
+    return false
+}
+```
+
+리뷰어: "`shouldStopDrawing`은 Hit일 경우 `hitAction`을 호출하고, Stay일 경우 true를 반환하고 있는데요, 하나의 함수안에서 두 가지 일을 하고 있습니다. 하나의 일만 하도록 변경해볼까요? 🤔" — *Boolean 질문*과 *상태 변경*이 같은 메서드. *Command-Query Separation* 위반. 학생 후속 반영: `shouldStopDrawing`을 *순수 질의*로, `hitAction`은 별도 호출.
+
+### 11. `Participants.sumCardNumber`에 *Ace 보정 로직 직접 박힘*
+
+```kotlin
+abstract class Participants() {
+    val sumCardNumber: Int get() = getSumNumber()
+    private fun getSumNumber(): Int {
+        var sum = cards.sumOf { it.cardNumber.number }
+        val aCount: Int = cards.count { it.cardNumber == CardNumber.Ace }
+        repeat(aCount) {
+            if (sum + CardNumber.OTHER_ACE > BUST_STANDARD) return@repeat
+            sum += CardNumber.OTHER_ACE
+        }
+        return sum
+    }
+}
+```
+
+리뷰어: "ACE가 포함된 카드의 총합을 구하는 방법을 다시 한 번 고민해볼까요? 🤔" — *Ace 1↔11*은 *Card 자체의 동작*인데 `Participants`에서 *합산하면서 결정*하는 패턴. `Card.value(currentSum: Int)`나 `Hand.score()`에 *룰 캡슐화*가 자연. PR #63의 `changeAceScore` 복잡도와 유사. + `OTHER_ACE` 같은 모호명(`ACE_BONUS = 10`이 명확).
+
+### 12. `BlackjackTest`에 *클래스 필드 직접 초기화* — 테스트 격리 깨짐
+
+```kotlin
+class BlackjackTest {
+    private val player1 = Player("제리")
+    private val player2 = Player("환노")
+    private val dealer = Dealer()
+    private val deck = Deck(FalseShuffle())
+    private val game = Blackjack(deck)
+    // @Test 들이 같은 인스턴스 공유 — 한 테스트가 carded면 다른 테스트에도 영향
+}
+```
+
+리뷰어: "이처럼 만들어두면 어떤 문제가 발생할 수 있을까요? 🤔"
+학생: "위처럼 만들게 되면 각 테스트가 서로에게 영향을 줄 수 있을 것 같습니다. 따라서 각 테스트 실행마다 객체를 초기화할 수 있도록 BeforeEach를 사용할 것 같습니다!" — JUnit5는 *기본 PER_METHOD* 격리지만, *mutable 멤버*가 *생성자에서 초기화*되면 *각 테스트 fresh 인스턴스*임에도 *생성자가 동일 부작용*을 만들어 *Deck.spreadCard() 순서가 누적되는 효과*. `@BeforeEach`로 *명시적 초기화*가 안전.
+
+### 13. `DeckTest`에서 *enum 순서 의존 테스트*
+
+```kotlin
+class DeckTest {
+    private val deck: Deck = Deck(FalseShuffle())
+    @Test
+    fun `카드를 셔플해서 첫번째 장에 있는 카드를 나누어준다`() {
+        val card = deck.spreadCard()
+        assertThat(card).isEqualTo(Card(Shape.Diamond, CardNumber.Ace))  // Shape/CardNumber 순서 의존
+    }
+}
+```
+
+리뷰어: "`Shape` 혹은 `CardNumber`의 순서가 변경되면 어떻게 될까요? 🤔" — `FalseShuffle`이 *원본 순서 유지* → 첫 카드는 *Shape.entries[0] × CardNumber.entries[0]*. enum 순서가 *테스트 결과의 진실*이 됨. *순서 변경 = 테스트 깨짐*. Named argument로 *어떤 카드인지 명시*하거나 fake가 *명시적 카드 목록*을 받도록.
+
+### 14. `Player`가 `compareScores`로 *자기 status를 mutate*
+
+```kotlin
+fun compareScores(number: Int) {
+    if (status != ParticipantStatus.Bust) {
+        status = ParticipantStatus.compare(sumCardNumber, number)
+    }
+}
+```
+
+`Player.status`가 `var`이고 `compareScores`가 *비교 + setter*. *결과를 반환*하는 것이 자연한데 *부작용*으로 처리. + `if (status != Bust)` 가드가 *상위에서 누가 책임*인지 모호 (이미 Bust면 *비교하지 않는다*는 룰).
+
+## 리뷰어 의견 요지
+
+- ***딜러 = 진행자 + 참여자* 분리는 옳다 — 그러나 `Blackjack`이 또 비대해지지 않게.**
+- ***enum이 UI 문자열 보유*는 도메인-뷰 경계 붕괴.**
+- ***public mutable 컬렉션 + var setter*는 외부 변경 위험** — protected/private 캡슐화.
+- **`Deck`이 `deck`을 갖는 동어반복 명명.**
+- **`Deck` 생성자에 *카드 명시 주입*하면 Strategy 자체 불필요.**
+- ***Test fake는 test 패키지***.
+- ***결과 동사 함수명*** — `overThreshold` vs `mustHit`/`canDraw`.
+- ***Tell-Don't-Ask*** — `compareScores(number)`보다 `compete(other)`로 *동일 추상* 메시지.
+- ***게임 진행 상태*와 *결과 상태* 분리** — 한 enum에 합치면 생애주기 혼란.
+- ***Service vs Domain*** — Spring 어휘 차용의 *콘솔 게임 적합성* 점검.
+- ***CQS 위반*** — `shouldStop`이 부작용도 일으키면 안 됨.
+- ***Ace 보정*은 `Card`/`Hand`** — `Participants`에 두면 책임 누수.
+- ***테스트 격리*** — 멤버 직접 초기화는 *생성자 부작용* 누적.
+
+## 대표 인용
+
+> 출력 정보가 도메인일까? 에 대해 고민해보면 좋을 것 같은데요 🤔 [...] 점점 도메인과 뷰의 경계가 무너지게 되고 구분할 수 없는 형태가 되어버릴거에요.
+> — @krrong on `src/main/kotlin/blackjack/model/domain/Shape.kt`
+
+> ```val dealer = Dealer(); dealer.cards.clear()``` 어떤 일이 발생할까요? 🤔
+> — @krrong on `src/main/kotlin/blackjack/model/domain/Participants.kt`
+
+> 객체 관점에서는 모두 동일한 참가자 역할을 가지는데요, 이는 참가자가 다른 참가자와 점수를 비교할 수 있다는 의미입니다. 예를 들면, `플레이어 vs 플레이어` 또는 `딜러 vs 플레이어` 도 가능하겠죠 🤠
+> — @krrong on `src/main/kotlin/blackjack/model/domain/Player.kt`
+
+> 게임 결과에 대한 상태(`Win, Lose, Draw`)와 플레이어의 상태(`Bust`)가 혼재되어 있는 것처럼 느껴져요. 둘은 성격이 다른 것처럼 느껴지는데 제리는 어떻게 생각하나요? 🤔
+> — @krrong on `src/main/kotlin/blackjack/model/domain/ParticipantStatus.kt`
+
+> 역할을 잘 정했으니 그 역할에 맞는 일만 하도록 구성해볼까요? 🤠
+> — @krrong on `src/main/kotlin/blackjack/model/service/Blackjack.kt`
+
+## 얻은 교훈
+
+- **"딜러 = 참가자 + 진행자" 분리는 옳음 — 그러나 *진행자*에게 *또 다른 비대화*가 들어오기 쉬움** — 진행자의 책임을 *카드 배부* / *입력 처리* / *점수 비교* / *결과 누적*으로 *더 잘게 쪼개기* 검토 필요.
+- **enum에 UI 출력 문자열 두기 = *변경 범위 최소화*는 단기, *도메인-뷰 경계 붕괴*는 장기** — *변경 비용 절감*이 *역할 혼합*의 핑계가 되지 않게.
+- **`abstract val cards: MutableList<Card>` + `abstract var status` = invariant 무방비** — *기본을 protected*로. 처음부터 *외부에서 mutate 가능한가*를 자문.
+- **`Deck`에 `deck` 속성 = 동어반복** — *클래스 == 속성*이면 *의미가 없음*. `cards`/`remaining`.
+- **`Deck(cards: List<Card>)` 명시 주입으로 Strategy 폐기** — *생성자 부작용*(셔플)을 *외부에서 주입*하면 Strategy 인터페이스 자체가 *fake 위해서만 존재*하던 코드를 제거 가능.
+- **test fake는 *test 패키지에*** — `src/main/.../FalseShuffle`은 *프로덕션 빌드에 fake 포함*.
+- ***결과 동사 함수명*** — `overThreshold()` vs `mustHit()`. *비교 동작*이 아니라 *반환값의 의미*가 함수명에.
+- ***Tell-Don't-Ask*: `compareScores(other.score)`보다 `compete(other)`** — *상대를 Int로 받기* 시작하면 *동일 추상*에 메시지를 못 보내고 *알고리즘 노출*.
+- ***게임 진행 상태*(Ready/Hit/Stay/Bust)와 *결과 상태*(Win/Lose/Draw) 분리** — 한 enum에 합치면 *불가능한 전이*(Bust → Win?) + *생애주기 혼란*. sealed interface 두 개로 표현.
+- ***Service vs Domain*** — Spring 어휘를 *콘솔 게임*에 그대로 가져오면 *Controller와 중복*. *콘솔 진행자*는 보통 `Game` 하나로 충분.
+- ***CQS*** — `shouldStopDrawing(action, player): Boolean`이 *부작용*도 일으키면 *함수명-동작 불일치* + *호출자 의도 불명*.
+- ***Ace 보정 = Card/Hand의 책임*** — `Participants.sumCardNumber`에 *룰을 박으면* 책임 누수. *Card.value(currentSum)* 또는 *Hand.score()*에.
+- ***테스트 멤버 직접 초기화는 위험*** — *생성자 부작용 누적*. `@BeforeEach`로 *명시 초기화*.
+- ***enum 순서 의존 테스트*** — `entries[0]`이 *테스트의 진실*이 되면 *enum 재배열 = 테스트 깨짐*.

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

@@ -0,0 +1,243 @@
+# PR #151 — [블랙잭 2단계] 제리 미션
+
+- **Reviewee:** [@jerry8282](https://github.com/jerry8282)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/151
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @krrong (크롱)
+- **라인 코멘트:** 15 스레드 / 33 코멘트 — *Controller 재사용 + View 검증 범위 + Hand 상태 객체 메시지* 깊은 토론
+
+## 잘한 점 (설계 관점)
+
+- **`BlackjackController` 재사용 가능 구조 자가 반영** — 크롱 진단 *"블랙잭 게임을 여러번 진행하기 위해 `BlackjackController`를 재사용할 수 있을텐데요. 현재 구조는 재사용하기에는 어려운 구조라고 생각이 듭니다. 새로운 플레이어와 블랙잭 게임을 진행하기 위해 `BlackjackController`를 재사용할 수 있도록 만들어보면 어떨까요?"* + 학생 자가 반영: *"controller의 인스턴스 변수를 삭제하여 재사용을 할 수 있도록 수정하였습니다."* (커밋 `e5c4043`). **Controller stateless 자가 학습**. PR #133 (시아 2단계) 의 *BlackjackEngine.setParticipantCard (in-place 핸드 교체)* 와 *반대 트레이드오프* — *시아 = 같은 Engine 객체 재사용, 제리 = stateless Controller 재사용*.
+- **`init → Start` naming 자가 반영** — 크롱 진단 *"`init`은 값을 세팅하거나 초기화하는 느낌을 줄 수 있기 때문에 네이밍을 변경해보면 더욱 가독성이 좋아질 것 같아요."* + 학생 자가 반영 (커밋 `81e6298`): *"초기화 하거나 세팅하는 느낌을 주는 init대신에 Start를 사용하여 게임 시작 시 보여주는 카드로 네이밍을 변경하였습니다."*. **naming = 의미 표현 자가 학습**.
+- **`BUST_STANDARD` private 가시성 자가 반영** — 크롱 진단 *"위치만 옮기는 것이 아니라 가시성도 함께 변경해주세요."* + 학생: *"BUST_STANDARD 뿐만 아니라 다른 객체들의 상수값들을 private으로 변경하였습니다.🥲"* (커밋 `7f6a714`). **캡슐화 일관성 자가 학습**.
+- **블랙잭 = 2장 + 21 자가 학습** — 크롱 진단 *"합계가 21이라고 무조건 블랙잭인것은 아닙니다. 도메인을 다시 한 번 공부해보세요."* + 학생 자가 답변: *"그 전에는 합계가 21이면 블랙잭 상태로 바꾸는 것이였습니다. 따라서, Blackjack 객체에서 카드를 처음 나누어주는 메소드에서만 판단하기만 하면 되었기 때문에 합계가 21이면 무조건 블랙잭으로 되도록 하였습니다.😅 하지만, Hand객체의 status변수가 없어진 지금은 카드의 size가 두장임을 판단하여 블랙잭이 되도록 수정하였습니다!💪"* (커밋 `279a8f3`). PR #148·#128·#108·#125·#114·#131·#136·#137 와 같은 결.
+- **`Hand` 가 자기 Bust/Blackjack 판단 자가 학습** — 크롱 진단 *"카드가 들어올 때 버스트인가, 블랙잭인가를 판단해서 상태를 변경하는 것을 외부에서 예측할 수 있을까요? 카드가 손에 들어올 때마다 **정말 상태를 변경해야만 하는가?** **다른 방법은 없을까?** 에 대해 고민해보면 좋겠습니다. 조금 힌트를 드리자면, `Hand`는 자신이 버스트인지, 블랙잭인지를 판단하는 일을 할 수 있었습니다. `Participants` 역시 자신이 카드를 받을 수 있는지를 판단할 수 있었구요. 객체들의 협력을 잘 이끌어내면 상태를 갖지 않아도 될 것처럼 보입니다."* + 학생 자가 반영 (커밋 `279a8f3`): *"Hand에게 버스트 인지 블랙잭인지 판단을 하는 메소드만 주고 Participants가 Hand에게 메시지를 던져 블랙잭인지 판단을 하여 블랙잭 승리로 끝나도록 수정하였습니다!😊"*. **상태 변경 X + 메시지 패턴 자가 학습 모범**.
+- **`canHit` 의미 명확화 자가 학습** — 크롱 진단 *"nit: 뭔가 이상하지 않나요? canHit -> True: Hit을 할 수 있는 상태 / 버스트인가? -> True: Hit을 하지 못하는 상태"* + 학생 자가 인용: *"이 로직에서 계속 위화감이 들었는데 크롱이 말씀해주시니 확 와닿았습니다! 바로 로직을 수정하였습니다!😂"* (커밋 `f713f4c`). **부울 메시지 의미 일관성 자가 학습**.
+- **배수별 메서드 폭증 자가 해소** — 크롱 진단 *"1배 ~ 1000배까지 모든 배수가 생긴다면 1000개의 메서드가 필요한 것처럼 보입니다."* + 학생 자가 반영: *"PlayerBetAmount 객체에서 배수를 파라미터로 받아 계산을 하도록 수정하였습니다."* PR #148·#147 와 같은 결의 *배수별 메서드 → 파라미터 인자*.
+- **`Hand.cards` Backing Property + 가독성 자가 학습** — 크롱 진단 *"1. 어디는 `_cards`를 어디는 `card`를 사용하고 있네요. 이러한 모습이 꽤 자주 보이는 것 같습니다. 2. `sum`을 var로 선언하는 것이 아닌 val로 선언하는 것이 더 좋지 않을까요? 3. `return if ~` 처럼 작성할 수도 있습니다."* + 학생 자가 답변: *"빽킹 프로퍼티로 전부 수정을 하고 getter인 cards는 반환만 하도록 수정하였습니다. ... sum을 val로 선언을 하고 반환값을 sum + 10으로 반환하도록 수정하였습니다. ... 객체 지향 생활 체조 원칙에 더 올바른 방법이라고 생각을 하였습니다.."* (커밋 `dc83ab1`). **Kotlin 어휘 + 객체 지향 생활 체조 원칙 자가 학습**.
+- **참가자 점수 비교 추상화 자가 학습** — 크롱 진단 *"점수를 비교하는 것은 플레이어만 가능한 것일까요? 저는 블랙잭이 추상화 기법을 공부해볼 수 있는 미션이라고 생각합니다. 참가자는 상대방과의 점수를 비교하여 결과를 내올 수 있는데요, 이는 다음과 같은 경우도 모두 판단이 가능해야 한다는 것입니다. 플레이어 vs 플레이어 / 플레이어 vs 딜러 / 딜러 vs 딜러"* + 학생 자가 답변: *"현재 프로젝트에서는 플레이어만 판단하면 된다고 생각하여 저는 Player객체에만 사용을 하였습니다. 하지만, 확장성을 생각한다고 하면 Participants객체에 위치하는 것이 더 올바른 방법인 것 같습니다.😊"* + 크롱 자가 인정: *"제리 의견도 맞아요. 확장성을 고민하면 어디까지 생각해봐야 하는가 고민하다 중요한 것들을 놓치기 쉽습니다. 또한 고민한다고 모든 경우의 수를 예상하고 대비할 수는 없으니까요."*. **확장성 vs 현재 책임 트레이드오프 양방향 인식 모범**.
+- **테스트 추가 자가 반영** — 크롱 진단 *"딜러는 다양한 일을 하고 있는데요. 테스트를 꼼꼼하게 작성했는지 확인해주세요. 2단계에서 새로 추가된 클래스와 기존에 있던 다른 모든 클래스들도 동일합니다."* 후속 반영.
+- **`MethodSource` 사용 자가 회의** — 크롱 진단 *"`@MethodSource`를 활용한 장점이 보이질 않는 것 같네요😅"* + 학생 자가 답변: *"MethodSource를 사용하지 않아도 단순히 Jack, King, Queen을 카드로 넣으면 되었군요..😅"*. **테스트 어휘 자가 학습**.
+- **View vs 도메인 검증 자가 토론 (반란군 비유)** — 학생 자가 답변: *"저번 로또 미션과 블랙잭 미션에서 제일 고민되는 문제는 View에서 어디까지 validate인가 였습니다. 결국 내린 결론은 **null값과 타입과 마지막으로 해당 View반환값을 쓰는 도메인의 형식은 View에서 처리하자**였습니다.🥹 만약, 사용자가 `www.a.com`을 입력했을 때 해당 사이트가 실제로 존재하는지는 도메인에서 검증해야 한다고 생각합니다. 반면, `ww.a.com`처럼 www의 형식을 어긴 입력은 View에서 처리하는 것이 맞다고 생각합니다. 따라서, 이번 구현도 `베팅 금액의 형식은 당연히 양수이다`는 형식이라고 생각이 되어 View로직에 넣었습니다. 제가 생각하는 도메인 로직은 `최소 베팅금액을 1000원으로 제한한다.` 라는 것이 도메인 로직이고 모든 사람들이 당연하게 생각하는 `베팅금액은 0보다 크다`를 View에서 판단하는 것이 맞다고 생각합니다."* — *학생 깊은 자가 토론*. 크롱 반박: *"베팅금액이 0보다 커야한다는 것은 사용자 입력 형식이 아니라, 게임 진행을 위한 기본적인 전제 조건이며 이는 비즈니스 규칙에 해당한다고 볼 수 있습니다. 현재 블랙잭 게임을 콘솔이 아닌 다른 UI로 가져간다면 어떻게 될까요? 콘솔 뷰에서 처리하고 있는 검증 로직은 새로운 UI에는 존재하지 않을겁니다. 따라서 0보다 큰 값이 들어왔는지는 검증할 수 없어지겠죠."*. **View vs 도메인 검증 경계 양방향 토론 모범**. PR #41 (핑구 2단계 잭슨 답변) 와 같은 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `PlayerBetAmount(amounts: Map<Player, BettingMoney>)` — *Map 자료구조 + 인스턴스 변수 제약*
+
+학생 자가 답변: *"그런데 인스턴스 변수를 2개 이하로 유지해야 한다는 조건을 맞추려다 보니, 결국 Map을 써야 하는 상황이 생겼습니다."*
+
+크롱 답변: *"플레이어가 베팅 금액을 들고 있는 것이 적절하다고 판단이 되면 그렇게 구현해도 괜찮습니다. 요구사항을 지켜야 하지만 좋은 설계라고 생각하면 가끔은 부숴도... ~~제리는 포비가 키우는 반란군이니까요ㅋㅋ~~ 제리가 원래 그리던 꿈을 펼쳐주세요."* + *"이번 미션에서는 가능한 한 Map 사용을 지양하는 것을 목표로 삼았습니다. 적절한 자료구조의 사용은 설계와 더불어 자료구조가 제공하는 이점들을 활용할 수 있겠습니다. 가령 아래처럼 클래스를 설계할 수도 있을겁니다. `class PlayerBetAmount(val amounts: Map<Player, BettingMoney>)`"*
+
+학생 자가 답변: *"저도 포비가 키우는 반란군이 되고 싶지만, 객체 지향을 향한 한 걸음은 결국 요구사항을 제대로 이해하고 따르는 것이라고 생각했습니다. 따라서, 이번에는 요구사항에 맞춰 코드를 구현하였습니다..🥲 하지만, 코틀린과 객체 지향에 대해 공부를 좀 더 하고 저만의 가치관이 확립되면 그때는 제대로 된 반란군이 되어 볼 생각입니다!!💪"*
+
+→ **`Map<Player, BettingMoney>` = 3 변수 제약 우회 자료구조**. *`PlayerBetAmount(player, bettingMoney)` 단일 객체 + List 보유* 가 *PR #137·#90·#49 의 정공*. *`Map<X, X>` 자료구조 = *Pair 우회 (PR #132 페로로 진단 와 같은 결)***. *학생 자가 회의 + 크롱 메시지 (반란군 비유) = 양방향 트레이드오프 인식 모범*. PR #133·#88·#132·#136·#41·#49·#146 와 같은 결의 *3 변수 제약 = 연습 도구*.
+
+### 2. `BlackjackController` 재사용 → *Controller stateless* — *상태 vs 무상태 트레이드오프*
+
+```kotlin
+// 학생 자가 반영 (e5c4043) 후
+class BlackjackController(...) {
+    // 인스턴스 변수 삭제 → stateless 재사용 가능
+    fun run() { ... }
+}
+```
+
+→ **stateless Controller = 재사용 가능 + 의존성 주입만**. *상태 보유 = 한 게임 = 재사용 불가*. *PR #133 (시아 2단계) 의 BlackjackEngine.setParticipantCard (in-place 핸드 교체)* 는 *같은 객체 재사용*. *둘 다 합리 — *stateless Controller + new 도메인 객체 매 라운드** vs *재사용 Engine + in-place 변경**. 트레이드오프.
+
+### 3. `Player.compareScores` 만 — *Participants 다형성 부재 → 자가 학습*
+
+크롱 진단 (Player.kt — 미해결): *"점수를 비교하는 것은 플레이어만 가능한 것일까요?"*
+
+학생 자가 답변: *"현재 프로젝트에서는 플레이어만 판단하면 된다고 생각하여 저는 Player객체에만 사용을 하였습니다. 하지만, 확장성을 생각한다고 하면 Participants객체에 위치하는 것이 더 올바른 방법인 것 같습니다.😊"*
+
+크롱 자가 인정: *"제리 의견도 맞아요. 확장성을 고민하면 어디까지 생각해봐야 하는가 고민하다 중요한 것들을 놓치기 쉽습니다. 또한 고민한다고 모든 경우의 수를 예상하고 대비할 수는 없으니까요."*
+
+→ **확장성 vs 현재 책임 트레이드오프**. *Participants 다형성 (모든 vs 모든) = 미래 가능성*. *Player only = 현재 충분*. *YAGNI vs 추상화*. *양방향 인식 모범*. PR #146 (채넛 = YAGNI 인용) / PR #148 (타마 = Participant 다형성) 와 *비슷한 결*. *제리는 현재 책임 우선* 선택.
+
+### 4. `BettingMoney 1배 ~ 1000배 메서드` 폭증 (자가 해소 전)
+
+크롱 진단 (BettingMoney.kt — 미해결): *"1배 ~ 1000배까지 모든 배수가 생긴다면 1000개의 메서드가 필요한 것처럼 보입니다."*
+
+학생: *"PlayerBetAmount 객체에서 배수를 파라미터로 받아 계산을 하도록 수정하였습니다."*
+
+→ **배수별 메서드 폭증 안티패턴**. *`bettingMoney.times1() / times1_5() / times2()` 같은 *메서드 폭증***. *파라미터로 배수 받기* 정공. PR #148·#147 와 같은 결.
+
+### 5. `View vs 도메인 검증 경계` — *학생 자가 토론 깊이*
+
+학생 자가 인용: *"저번 로또 미션과 블랙잭 미션에서 제일 고민되는 문제는 View에서 어디까지 validate인가 였습니다. 결국 내린 결론은 **null값과 타입과 마지막으로 해당 View반환값을 쓰는 도메인의 형식은 View에서 처리하자**였습니다."*
+
+학생 추가 인용: *"제가 생각하는 도메인 로직은 `최소 베팅금액을 1000원으로 제한한다.` 라는 것이 도메인 로직이고 모든 사람들이 당연하게 생각하는 `베팅금액은 0보다 크다`를 View에서 판단하는 것이 맞다고 생각합니다. 크롱은 이 접근 방식에 대해 어떻게 생각하시나요? 🤔"*
+
+크롱 답변: *"베팅금액이 0보다 커야한다는 것은 사용자 입력 형식이 아니라, 게임 진행을 위한 기본적인 전제 조건이며 이는 비즈니스 규칙에 해당한다고 볼 수 있습니다. 현재 블랙잭 게임을 콘솔이 아닌 다른 UI로 가져간다면 어떻게 될까요? 콘솔 뷰에서 처리하고 있는 검증 로직은 새로운 UI에는 존재하지 않을겁니다. 따라서 0보다 큰 값이 들어왔는지는 검증할 수 없어지겠죠."*
+
+→ **View vs 도메인 검증 경계 양방향 토론**. *학생 = "당연한 형식은 View"* / *크롱 = "비즈니스 규칙 = 도메인"*. *Multi-platform UI 시 도메인 검증 필수*. *PR #41 (핑구 + 잭슨) 의 동일 트레이드오프* / *PR #148 (타마 + 크롱) 의 베팅금 도메인 이전* 와 같은 결. **MCP 룰 후보 — `view-only-validation-cross-ui-fragility`**.
+
+### 6. `Hand` 가 *상태 변경 (status var)* → 메시지 패턴 자가 학습
+
+학생 자가 답변 인용: *"그 전에는 합계가 21이면 블랙잭 상태로 바꾸는 것이였습니다. 따라서, Blackjack 객체에서 카드를 처음 나누어주는 메소드에서만 판단하기만 하면 되었기 때문에 합계가 21이면 무조건 블랙잭으로 되도록 하였습니다.😅 하지만, Hand객체의 status변수가 없어진 지금은 카드의 size가 두장임을 판단하여 블랙잭이 되도록 수정하였습니다!💪"*
+
+→ **`Hand.status var` → 메시지 패턴 (`Hand.isBlackjack()`)**. *상태 변경 vs 메시지 (derived)* 트레이드오프. *상태 = 캐시 + 변경 가능성*. *메시지 = 매 호출 derived + 시점 무관*. *PR #146·#131·#137·#136 의 derived 상태 (`get() = ...`)* 와 같은 결.
+
+### 7. `canHit` vs `isBust` 의미 일관성
+
+크롱 진단 (Player.kt — 미해결): *"nit: 뭔가 이상하지 않나요? canHit -> True: Hit을 할 수 있는 상태 / 버스트인가? -> True: Hit을 하지 못하는 상태"*
+
+학생 자가 답변: *"이 로직에서 계속 위화감이 들었는데 크롱이 말씀해주시니 확 와닿았습니다!"*
+
+→ **부울 메시지 의미 = True 방향 일관**. *canHit = Hit 가능* vs *isBust = Hit 불가능*. *호출자가 분기 시 헷갈림*. *둘 다 *긍정 방향* 또는 *부정 방향* 통일*. *Kotlin 어휘 = `!isBust && canHit`* 보다 *`canDraw()` 한 메서드*가 *의미 일관*.
+
+### 8. `Hand` 의 *`return if ~` Kotlin 어휘* + `객체 지향 생활 체조 원칙` 토론
+
+크롱 진단: *"`return if ~` 처럼 작성할 수도 있습니다."*
+
+학생 자가 답변: *"이 부분이 고민이였는데 크롱이 말씀하신대로 return if로 사용을 한다고 하면 else가 사용되는데 ... 이렇게 사용을 하여 else를 없애는 것이 객체 지향 생활 체조 원칙에 더 올바른 방법이라고 생각을 하였습니다.. 이에 대해 크롱의 생각이 궁금합니다.🤔"*
+
+크롱 답변: *"이상적으로 생각하면 제리의 의견이 타당하다고 생각하지만, 사실 이 부분에 정답은 없다고 생각합니다. 가독성의 영역이고 가독성은 개인의 취향이 반영되니까요."*
+
+→ **`return if-else` vs `if-return; return` 트레이드오프**. *객체 지향 생활 체조 원칙 = else 회피* (학생 인용). *Kotlin 어휘 = if-else 양쪽 합리*. *가독성 = 개인 취향* (크롱 자가 인정). **양방향 트레이드오프 인식 모범**.
+
+### 9. `init` naming → `Start` — 함수명 의미 표현
+
+크롱 진단 (Participants.kt — 미해결): *"`init`은 값을 세팅하거나 초기화하는 느낌을 줄 수 있기 때문에 네이밍을 변경해보면 더욱 가독성이 좋아질 것 같아요."*
+
+→ **`init` = 초기화 어휘**. *Kotlin `init` 블록과 의미 충돌*. *`start` / `show` 등 명시적 어휘*가 *의미 명료*. PR #136·#137·#88·#146 와 같은 결의 *naming = 책임 표현*.
+
+### 10. `Dealer` 다양한 일 = 테스트 부족 신호
+
+크롱 (Dealer.kt:6 — 미해결): *"딜러는 다양한 일을 하고 있는데요. 테스트를 꼼꼼하게 작성했는지 확인해주세요🙏. 2단계에서 새로 추가된 클래스와 기존에 있던 다른 모든 클래스들도 동일합니다."*
+
+학생: *"딜러의 메소드 별 테스트와 따로 테스트가 없었던 객체들의 테스트를 추가하였습니다.🥲"* (커밋 `2c9f136`).
+
+→ **클래스 = 여러 일 시 테스트 필수**. *Dealer 의 다중 책임 신호 + 테스트 커버리지*. *PR #137·#103·#147·#148 와 같은 결의 *테스트 자가 추가 모범**.
+
+### 11. `친절한 프로그램` UX 권고
+
+크롱 (BlackjackController.kt:1 — 미해결): *"nit: 게임을 진행할 때 버스트가 되면 카드를 뽑을 수 없는데요. 사용자에게 이를 알려주는 것이 더 친절한 프로그램이지 않을까요😅"*
+
+→ **UX = 도메인 룰 + 사용자 친화 메시지**. *Bust 후 카드 못 뽑음 → 명시적 안내*. *PR #103·#137 와 같은 결의 *사용자 피드백*.
+
+### 12. `BettingMoney 0보다 큰 검증` → View vs 도메인 학생 자가 토론
+
+학생 자가 답변 (View 검증 후) → 크롱 권고 후 도메인 이전. *학생 자가 표현 시점 어휘 = "당연한 형식"* — 학생 사고의 한계 명시 (View 검증 = 콘솔 가정).
+
+→ **`당연한 형식` 인식 = 현재 UI 가정 함정**. *Multi-platform 고려*에선 *도메인이 자기 invariant 강제*. PR #41·#148 와 같은 결.
+
+### 13. `Hand` 상태 var 제거 = 자가 학습 핵심
+
+크롱 진단 (Hand.kt — 미해결): *"카드가 손에 들어올 때마다 **정말 상태를 변경해야만 하는가?** **다른 방법은 없을까?**"*
+
+→ **상태 var → derived 메시지 패턴 전환**. *학생 자가 학습 핵심*. *`Hand.status` 보유 + 변경* 대신 *`Hand.isBlackjack()`, `Hand.isBust()` 메서드*. *시점 무관 + 외부 예측 가능성*. PR #146·#131·#137·#136·#148 와 같은 결.
+
+## 리뷰어 의견 요지
+
+- **Controller 재사용 = stateless** — *인스턴스 변수 제거*. *PR #133 의 in-place vs 제리 = stateless* 트레이드오프.
+- **Map 자료구조 우회 = 인스턴스 변수 제약 부산물** — *PlayerBetAmount 클래스 응집*이 정공.
+- **반란군 비유 = 요구사항 vs 좋은 설계 자유** — *학생의 요구사항 준수 결정 인정*.
+- **Hand = 상태 변경 X + 자기 판단 메시지** — *Tell-Don't-Ask*.
+- **`canHit` vs `isBust` 부울 의미 일관** — *True 방향 통일*.
+- **참가자 vs 참가자 추상화 + YAGNI vs 추상화 트레이드오프** — 양방향 인식.
+- **View vs 도메인 검증 = 비즈니스 규칙은 도메인** — *Multi-platform 고려*.
+- **`init` naming = Kotlin 의미 충돌** — *Start 어휘*.
+- **블랙잭 = 2장 + 21** — *학생 자가 학습*.
+- **배수별 메서드 폭증 = 파라미터 인자**.
+- **테스트 꼼꼼함 = 다중 책임 클래스 필수**.
+
+## 대표 인용
+
+**크롱 (반란군 비유 + 요구사항 vs 설계, PlayerBetAmount.kt):**
+> 플레이어가 베팅 금액을 들고 있는 것이 적절하다고 판단이 되면 그렇게 구현해도 괜찮습니다.
+> 요구사항을 지켜야 하지만 좋은 설계라고 생각하면 가끔은 부숴도... ~~제리는 포비가 키우는 반란군이니까요ㅋㅋ~~
+>
+> 제리가 원래 그리던 꿈을 펼쳐주세요.
+>
+> > 이번 미션에서는 가능한 한 Map 사용을 지양하는 것을 목표로 삼았습니다.
+>
+> 적절한 자료구조의 사용은 설계와 더불어 자료구조가 제공하는 이점들을 활용할 수 있겠습니다.
+
+**크롱 (Hand 상태 변경 X 메시지 패턴, Hand.kt):**
+> 카드가 들어올 때 버스트인가, 블랙잭인가를 판단해서 상태를 변경하는 것을 외부에서 예측할 수 있을까요?
+> 카드가 손에 들어올 때마다 **정말 상태를 변경해야만 하는가?** **다른 방법은 없을까?** 에 대해 고민해보면 좋겠습니다.
+>
+> 조금 힌트를 드리자면,
+> `Hand`는 자신이 버스트인지, 블랙잭인지를 판단하는 일을 할 수 있었습니다.
+> `Participants` 역시 자신이 카드를 받을 수 있는지를 판단할 수 있었구요.
+> 객체들의 협력을 잘 이끌어내면 상태를 갖지 않아도 될 것처럼 보입니다.
+
+**크롱 (View vs 도메인 검증, InputView.kt):**
+> 베팅금액이 0보다 커야한다는 것은 사용자 입력 형식이 아니라, 게임 진행을 위한 기본적인 전제 조건이며 이는 비즈니스 규칙에 해당한다고 볼 수 있습니다.
+> 현재 블랙잭 게임을 콘솔이 아닌 다른 UI로 가져간다면 어떻게 될까요? 콘솔 뷰에서 처리하고 있는 검증 로직은 새로운 UI에는 존재하지 않을겁니다. 따라서 0보다 큰 값이 들어왔는지는 검증할 수 없어지겠죠.
+
+**크롱 (canHit vs isBust 의미 일관, Player.kt):**
+> nit: 뭔가 이상하지 않나요?
+> canHit -> True: Hit을 할 수 있는 상태
+> 버스트인가? -> True: Hit을 하지 못하는 상태
+
+**크롱 (확장성 vs 현재 책임 양방향, Player.kt):**
+> 제리 의견도 맞아요.
+> 확장성을 고민하면 어디까지 생각해봐야 하는가 고민하다 중요한 것들을 놓치기 쉽습니다.
+> 또한 고민한다고 모든 경우의 수를 예상하고 대비할 수는 없으니까요.
+
+**학생 자가 학습 (요구사항 우선 결정, PlayerBetAmount.kt):**
+> 저도 포비가 키우는 반란군이 되고 싶지만, 객체 지향을 향한 한 걸음은
+> 결국 요구사항을 제대로 이해하고 따르는 것이라고 생각했습니다.
+> 따라서, 이번에는 요구사항에 맞춰 코드를 구현하였습니다..🥲
+>
+> 하지만, 코틀린과 객체 지향에 대해 공부를 좀 더 하고 저만의 가치관이 확립되면
+> 그때는 제대로 된 반란군이 되어 볼 생각입니다!!💪
+
+**학생 자가 학습 (View vs 도메인 검증 자가 토론, InputView.kt):**
+> 저번 로또 미션과 블랙잭 미션에서 제일 고민되는 문제는 View에서 어디까지 validate인가 였습니다.
+> 결국 내린 결론은 **null값과 타입과 마지막으로 해당 View반환값을 쓰는 도메인의 형식은 View에서 처리하자**였습니다. 🥹
+>
+> 만약, 사용자가 `www.a.com`을 입력했을 때 해당 사이트가 실제로 존재하는지는 도메인에서 검증해야 한다고 생각합니다.
+> 반면, `ww.a.com`처럼 www의 형식을 어긴 입력은 View에서 처리하는 것이 맞다고 생각합니다.
+>
+> 따라서, 이번 구현도 `베팅 금액의 형식은 당연히 양수이다`는 형식이라고 생각이 되어 View로직에 넣었습니다.
+>
+> 제가 생각하는 도메인 로직은 `최소 베팅금액을 1000원으로 제한한다.` 라는 것이 도메인 로직이고
+> 모든 사람들이 당연하게 생각하는 `베팅금액은 0보다 크다`를 View에서 판단하는 것이 맞다고 생각합니다.
+
+**학생 자가 학습 (canHit 위화감 자가 인식, Player.kt):**
+> 이 로직에서 계속 위화감이 들었는데 크롱이 말씀해주시니 확 와닿았습니다!
+> 바로 로직을 수정하였습니다!😂
+
+**학생 자가 학습 (객체 지향 생활 체조 원칙 인용, Hand.kt:8):**
+> 이 부분이 고민이였는데 크롱이 말씀하신대로 return if로 사용을 한다고 하면 else가 사용되는데
+> ...
+> 이렇게 사용을 하여 else를 없애는 것이 객체 지향 생활 체조 원칙에 더 올바른 방법이라고 생각을 하였습니다..
+> 이에 대해 크롱의 생각이 궁금합니다.🤔
+
+## 얻은 교훈
+
+1. ***Controller 재사용 = stateless = 인스턴스 변수 제거***. *PR #133 (시아) in-place 변경 vs PR #151 (제리) stateless 재사용* 트레이드오프. *둘 다 합리 — 도메인 메타포 의존*.
+
+2. ***`Map<X, X>` 자료구조 = 3 변수 제약 부산물 (반란군 비유 = 요구사항 vs 설계 자유)***. *크롱 인용: "좋은 설계라고 생각하면 가끔은 부숴도..."* + *학생 결정 = 요구사항 우선*. *학습 + 자유 + 트레이드오프 명시 모범*. PR #133·#88·#132·#136·#146·#41·#49 와 같은 결.
+
+3. ***`Hand` 상태 변경 X + derived 메시지 패턴 = Tell-Don't-Ask 정공***. *`Hand.status var` 변경 → `Hand.isBlackjack()` 메서드*. *시점 무관 + 외부 예측 가능성*. PR #146·#131·#137·#136·#148 와 같은 결의 *derived 상태*.
+
+4. ***View vs 도메인 검증 = 비즈니스 규칙 = 도메인***. *Multi-platform UI 시 View 검증만 = 새 UI 에서 누락*. *학생 의 "당연한 형식" 어휘 = 콘솔 UI 가정 함정*. *크롱 = 비즈니스 규칙 = 도메인 강제*. PR #41·#148 와 같은 결. **MCP 룰 후보 — `view-only-validation-cross-ui-fragility`**.
+
+5. ***`canHit` vs `isBust` 부울 의미 일관 = True 방향 통일***. *canHit True = Hit 가능* / *isBust True = Hit 불가능* 의 *방향 충돌*. *둘 다 긍정 방향 또는 부정 방향 통일*. *`canDraw()` 한 메서드*가 *의미 일관*. PR #41·#148 와 같은 결.
+
+6. ***`init` naming = Kotlin 의미 충돌***. *Kotlin `init` 블록 = 객체 초기화*. *`init` 메서드명 = 의미 충돌*. *`start` / `show` 등 명시적 어휘*. PR #136·#137·#88·#146 와 같은 결.
+
+7. ***확장성 vs 현재 책임 양방향 트레이드오프 = 어디까지 추상화***. *Participants 다형성 (플레이어 vs 플레이어, ...) = 미래 가능성*. *Player only = 현재 충분*. *크롱 자가 인정 ("확장성 고민하면 ... 중요한 것들 놓치기 쉽습니다")*. PR #146·#148 와 같은 결.
+
+8. ***`MethodSource` 활용 X = 단순 카드 인자 충분***. *Jack/King/Queen 카드 인자만으로 테스트 가능*. *@MethodSource 오버엔지니어링*. *학생 자가 학습 모범*. PR #146·#136·#90 와 같은 결.
+
+9. ***`객체 지향 생활 체조 원칙` 인용 = else 회피 vs Kotlin if-else 어휘***. *원칙 = else 회피*. *Kotlin = if-else 양쪽 합리*. *크롱 = 가독성 = 개인 취향*. **양방향 트레이드오프 인식 모범**.
+
+10. ***친절한 프로그램 UX = 도메인 룰 + 사용자 피드백***. *Bust 후 카드 못 뽑음 → 명시적 안내*. *도메인 정확성 + UX 완성도*. PR #103·#137 와 같은 결.
+
+11. ***Dealer 다양한 일 = 다중 책임 신호 + 테스트 부족***. *클래스 책임 분배 + 테스트 커버리지*. *PR #137·#103·#147·#148 와 같은 결*.
+
+12. ***배수별 메서드 폭증 = 파라미터 인자***. *1배 ~ 1000배 메서드 X*. *`calculate(multiplier: Double)` 한 메서드*. PR #148·#147 와 같은 결.
+
+13. ***`반란군 비유` (크롱) + 학생 결정 (요구사항 우선) = reviewer/학생 양방향 자유 + 가치관 명시 모범***. *Reviewer 가 *학생 자유* 명시 인정* + *학생이 *현재 우선 + 미래 가치관 확립 의지** = *학습 + 가치관 발달 + 양방향 존중* 모범. PR #137·#148 와 같은 결의 *학생/리뷰어 양방향 학습*.
+
+14. ***Backing Property + val 활용 자가 학습***. *`_cards` private + `cards` getter`* + *`var sum` → `val sum` + `sum + 10` 반환*. *Kotlin 어휘 + 불변 정공*. PR #146·#137·#133 와 같은 결.
+
+15. ***`Hand.size == 2 + 21 = 블랙잭` 자가 학습***. *학생 자가 의식 + 후속 반영*. *블랙잭 룰 정확성*. PR #148·#128·#108·#125·#114·#131·#136·#137 와 같은 결.
+
+16. ***학생 자가 학습 + 자가 토론 깊이 + reviewer 양방향 인정 = 학습 가시화 최고 수준***. *View 검증 자가 토론 + 객체 지향 생활 체조 원칙 인용 + 확장성 vs 현재 책임 트레이드오프*. PR #146·#148·#137·#41 와 같은 결.