oh-my-oop 0.2.0

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

@@ -0,0 +1,232 @@
+# PR #78 — [블랙잭 1단계] 채드 미션
+
+- **Reviewee:** [@dpcks0509](https://github.com/dpcks0509)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/78
+- **단계:** 1단계 (블랙잭 기본 게임 — 카드 분배 / Hit·Stay 진행 / 승패 판정)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 30 (리뷰어 19 / 리뷰이 11)
+
+## 잘한 점 (설계 관점)
+
+- **`State`를 `sealed interface`로 모델링** — `Running.Hit` / `Finished.Stay`/`Bust`/`BlackJack`. 상태 전이를 `when` 분기 없이 타입으로 표현. 블랙잭의 핵심 도메인 패턴.
+- **`Denomination`(13종) × `Suit`(4종)으로 `Card` 구성** — 두 축 직교 분해. 52장을 곱집합으로.
+- **`Referee` 객체로 승패 판정 책임 분리** — Controller에서 빼냄.
+- **`PlayerEntry` 일급 컬렉션** — `List<Player>` 노출 대신 묶음.
+- **`@BeforeEach`로 test fixture 도입** (리뷰 후 반영) — 매 테스트 setup 중복 제거.
+
+## 못한 점 (설계 관점)
+
+### 1. `BlackJackController`가 god-object — UI/도메인/진행 책임 혼재
+
+```kotlin
+object BlackJackController {
+    fun run() {
+        val playersName = readPlayersName()
+        val (dealer, playerEntry) = showInitialSettingCard(playersName)
+        playGame(playerEntry, dealer)
+        showGameResult(dealer, playerEntry)
+    }
+
+    private fun readPlayersName(): List<String> {
+        showPlayersNameReadMessage()
+        return try {
+            val playersName = readln().split(',').map { it.trim() }
+            require(playersName.all { it.isNotBlank() }) { INVALID_PLAYER_NAME }
+            playersName
+        } catch (e: IllegalArgumentException) { ... }
+    }
+
+    private fun determinestate(player: Player) {
+        if (isBust(player)) player.state = State.Finished.Bust
+        else if (isBlackjack(player)) player.state = State.Finished.BlackJack
+    }
+}
+```
+
+리뷰어: "과연 해당내용은 Controller 에서 관리를 하는 것이 맞을지 고민해보면 좋을 것 같습니다!! 요구사항에 `UI 로직을 InputView, ResultView와 같은 클래스를 추가해 분리한다.` 와 같은 내용이 있습니다!!" / "딜러의 상태를 체크하는 것이 과연 Controller 에서 가지고 있어야 하는 책임인지에 대해서 고민해보면 좋을 것 같습니다!!🤔" — *입력 파싱*은 InputView, *상태 결정*은 Player 자신.
+
+### 2. `Card.toString()`이 UI 표현(한국어 + JQKA)을 도메인에 보유
+
+```kotlin
+class Card(val denomination: Denomination, val suit: Suit) {
+    override fun toString(): String {
+        val number = when (denomination) {
+            Denomination.JACK -> "J"
+            Denomination.QUEEN -> "Q"
+            Denomination.KING -> "K"
+            Denomination.ACE -> "A"
+            else -> denomination.score
+        }
+        val shape = when (suit) {
+            Suit.CLUBS -> "클로버"
+            Suit.DIAMONDS -> "다이아몬드"
+            Suit.HEARTS -> "하트"
+            Suit.SPADES -> "스페이드"
+        }
+        return "$number$shape"
+    }
+}
+```
+
+리뷰어: "number & shape에 대한 분기 내용이 Card에서 책임을 지고 있어야 하는지는 고민해보면 좋을 것 같습니다!🤔" — `OutputView`가 카드 → 문자열 매핑을 가져야 함. *UI 언어 변경 = 도메인 수정*은 의존 역전.
+
+### 3. `Deck`을 `object` (Singleton) — 테스트마다 `initialize()` 필요
+
+```kotlin
+object Deck {
+    // 전역 단일 상태. 매 테스트 BeforeEach에서 Deck.initialize() 호출.
+    fun dealCard(): Card { ... }
+}
+
+// 테스트
+class DealerTest {
+    @BeforeEach
+    fun deckInitialize() { Deck.initialize() }
+}
+```
+
+리뷰어: "Deck을 object 키워드로 정의하신 이유가 있을까요??" — *전역 변경 가능 상태*는 테스트 격리를 깬다. `class Deck`로 매 게임 새 덱.
+
+### 4. `ScoreCalculation` 정적 유틸 객체 — `Hand`의 책임 누수
+
+```kotlin
+object ScoreCalculation {
+    fun calculate(hand: Hand): Int {
+        val totalScore = calculateTotalScore(hand)
+        return convertAceToOne(totalScore, hand)
+    }
+    private fun calculateTotalScore(hand: Hand) =
+        hand.cards.sumOf { card -> card.denomination.score }
+    private fun convertAceToOne(totalScore: Int, hand: Hand): Int {
+        var score = totalScore
+        val aceCount = hand.cards.count { it.denomination == Denomination.ACE }
+        repeat(aceCount) { if (score > BLACKJACK_SCORE) score -= CONVERT_ACE }
+        return score
+    }
+}
+```
+
+리뷰어: "해당 객체의 경우 hand 에 대한 계산만을 담당하고 있는 객체 같은데, 해당 책임을 hand 에서 가지고 기능을 하도록 해도 될 것 같다는 생각이 듭니다!!" — `hand.score()` 가 Tell-Don't-Ask. 정적 유틸은 *데이터를 빼앗긴 객체* 신호 (feature-envy).
+
+### 5. `Dealer.judgeDraw()` 매직넘버 16
+
+```kotlin
+class Dealer(val hand: Hand) {
+    var state: State = State.Running.Hit
+    fun judgeDraw(): Boolean = ScoreCalculation.calculate(hand) <= 16
+}
+```
+
+리뷰어: "조건의 경우 하드 코딩되어 있는 내용을 상수로 관리를 해봐도 좋을 것 같다는 생각이 듭니다🤔" — `DEALER_HIT_THRESHOLD = 16`. 더 본질적으로는 *딜러 정책*을 `Dealer`만의 룰로 표현.
+
+### 6. `State`에 `READY` 누락 — 게임 시작 직후 상태 없음
+
+```kotlin
+sealed interface State {
+    sealed interface Running : State {
+        data object Hit : Running
+    }
+    sealed interface Finished : State {
+        data object Stay : Finished
+        data object Bust : Finished
+        data object BlackJack : Finished
+    }
+}
+```
+
+리뷰어: "유저가 카드를 뽑지 않는 경우도 존재를 하는데, 이에 대해서도 추가를 하면 추후에 조건이 바뀌었을 때 좀더 유연하게 적용을 할 수 있을것 같다는 생각이 듭니다🤔" — 모든 Player가 `Hit`로 시작하면 *2장 받은 직후 = Hit* 상태인지 *Ready* 상태인지 모호. 학생은 후속에 `READY` 추가.
+
+### 7. `Hand`가 외부에서 `Deck.dealCard()`를 받아 넣음
+
+```kotlin
+// Controller가 Hand에 카드 주입
+dealer.hand.draw(Deck.dealCard())
+
+// askPlayerDraw 내부
+player.hand.draw(Deck.dealCard())
+```
+
+`Hand`는 *어떤 카드인지*만 알고 *어디서 왔는지* 무관해야 함. *진행자 객체*(Dealer 또는 GameInformation)가 Deck과 Hand 사이 *중개* 책임을 가져야 자연. (이는 PR #125 jerry8282의 학생 자가 의문과 연결 — *카드를 나누어주는 진행자의 역할*은 누구인가.)
+
+### 8. 함수명과 변수명 동명 — `drawOrNot`
+
+```kotlin
+private fun askPlayerDraw(player: Player) {
+    while (player.state is State.Running.Hit) {
+        val drawOrNot = askPlayersDraw(player)         // 변수
+        if (drawOrNot == DRAW_DECISION) {
+            player.hand.draw(Deck.dealCard())
+            drawOrNot(drawOrNot, player)               // 함수 (변수와 동명)
+            ...
+        }
+    }
+}
+```
+
+리뷰어: "drawOrNot 함수와 drawOrNot 변수는 물론 다르지만 네이밍이 같음으로서 자칫 혼란을 야기할 수 있겠다는 생각이 듭니다🥲" — 더 큰 문제는 *동일 메서드 호출 흐름이 두 번 발생* (`drawOrNot()` 안에서 `determinestate()` 호출되는데 바로 다음 줄에서도 `determinestate()`를 또 호출 — 코드 자체의 *의도 불명*).
+
+### 9. `Hand(mutableListOf<Card>())`를 Controller가 직접 구성
+
+```kotlin
+private fun dealingCards(playersName: List<String>): List<Hand> {
+    val hands = List(playersName.size + 1) { Hand(mutableListOf()) }
+    repeat(2) { hands.forEach { hand -> hand.draw(Deck.dealCard()) } }
+    return hands
+}
+```
+
+`Hand(mutableListOf())`로 외부에서 *빈 컬렉션*을 만들어 주입. `Hand()`의 기본 생성자가 빈 상태로 시작해야 자연. *컬렉션 mutable 노출* + *외부 채우기*는 lotto의 `empty-object-external-fill` 안티패턴과 동일.
+
+### 10. `ProgressView.showPlayerHand` vs `showDealerHand` — 중복
+
+```kotlin
+fun showPlayerHand(player: Player) { ... }      // top-level
+private fun showDealerHand(dealer: Dealer) { ... } // top-level private
+```
+
+리뷰어: "같은 기능을 하는 것으로 보이는데, 하나의 함수로 통합할 수 있다면 통합해보는 것도 좋을 것 같다는 생각이 듭니다!💪" — `Player`와 `Dealer`가 *카드 가진 자*라는 공통 상위 추상이 없어 view에서 중복. 도메인의 *역할 부재*가 view 중복으로 드러남.
+
+### 11. 테스트 함수명이 *결과만* 표현
+
+```kotlin
+@Test
+fun `Denomination, Suit 조합으로 된 객체 생성`() { ... }
+```
+
+리뷰어 권고: ``자동차가 1칸 이동하면 거리는 1이다`` 같은 *시나리오 + 결과* 형식. 학생은 후속에 반영.
+
+## 리뷰어 의견 요지
+
+- **Controller는 진행 흐름만** — UI 입출력은 View, 상태 판단은 도메인.
+- **`Card.toString` UI 표현 분리** — `OutputView`가 카드→문자열 책임.
+- **`Deck` Singleton 회피** — 매 게임 새 덱 (테스트 격리).
+- **점수 계산은 `Hand`의 책임** — 정적 유틸 객체 제거.
+- **매직넘버 16 상수화** + 딜러 정책으로 캡슐화.
+- **`State`에 READY 추가** — 초기 상태 명시.
+- **테스트 fixture (`@BeforeEach`)** + 시나리오 + 결과 네이밍.
+
+## 대표 인용
+
+> 해당 객체의 경우 hand 에 대한 계산만을 담당하고 있는 객체 같은데, 해당 책임을 hand 에서 가지고 기능을 하도록 해도 될 것 같다는 생각이 듭니다!!
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/model/game/ScoreCalculation.kt`
+
+> number & shape에 대한 분기 내용이 Card에서 책임을 지고 있어야 하는지는 고민해보면 좋을 것 같습니다!🤔
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/model/card/Card.kt`
+
+> 딜러의 상태를 체크하는 것이 과연 Controller 에서 가지고 있어야 하는 책임인지에 대해서 고민해보면 좋을 것 같습니다!!🤔
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/controller/BlackJackController.kt`
+
+> 유저가 카드를 뽑지 않는 경우도 존재를 하는데, 이에 대해서도 추가를 하면 추후에 조건이 바뀌었을 때 좀더 유연하게 적용을 할 수 있을것 같다는 생각이 듭니다🤔
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/model/game/State.kt`
+
+## 얻은 교훈
+
+- **`State` = `sealed interface`** — 블랙잭의 핵심 도메인. `Running`(Hit) / `Finished`(Stay/Bust/BlackJack) + 초기 `Ready`. `when` 분기 대신 *타입으로 분리*하면 상태별 메서드를 각 데이터 객체에 둘 수 있음.
+- **점수 계산은 `Hand`의 책임** — `ScoreCalculation.calculate(hand)`는 *데이터를 빼앗긴 객체* (feature-envy). `hand.score()`가 Tell-Don't-Ask.
+- **`Card.toString`에 UI 표현 박지 말 것** — JACK→"J" / CLUBS→"클로버" 같은 *언어/UI 결합*은 `OutputView`로. (lotto의 `side-effect-in-holder` 룰 적용 가능.)
+- **`Deck` Singleton(`object`) 금지** — 전역 변경 가능 상태. 매 게임 새 `Deck` 인스턴스가 자연. *셔플도 새 덱마다 한 번*.
+- **딜러 정책(`<=16 then Hit`)은 `Dealer` 안에** — 매직넘버 16은 *블랙잭 규칙*. Controller가 *조건 비교*를 하면 정책이 누수.
+- **`Hand(mutableListOf())` + 외부 채우기 = `empty-object-external-fill`** — `Hand()` 기본 생성자가 빈 상태로 시작. Deck에서 받는 책임은 *Dealer/Game* 같은 *진행자*.
+- **테스트 함수명 = 시나리오 + 결과** — *"객체 생성"* 같은 기능 라벨 X. *"딜러 합이 16 이하면 카드를 더 받는다"* 같은 *행동 기술*.
+- **`State.READY` 누락은 *시작 = 진행 중*과 *시작 직후 = 미결정*의 혼동 신호** — sealed로 모델링하면서 *모든 가능 상태*를 빠뜨리지 않는 것이 핵심.
+- **`drawOrNot` 함수와 변수 동명** — 가장 작은 안티패턴이지만 *읽기 비용*은 큼. 변수는 `decision` 등 *결과*를 표현하는 이름으로.

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

@@ -0,0 +1,137 @@
+# PR #88 — [블랙잭 2단계] 채드 미션
+
+- **Reviewee:** [@dpcks0509](https://github.com/dpcks0509)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/88
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @Gyuil-Hwnag (두루)
+- **라인 코멘트:** 28 스레드 / 48 코멘트 — *reviewer 칭찬 위주 + 학생이 모든 코멘트 후속 반영*
+
+## 잘한 점 (설계 관점)
+
+- **`BettingAmount` 원시값 포장** — 두루 자가 칭찬: *"BettingAmount 에 대한 원시값 포장 좋습니다~👍"*. *Int → 도메인 객체 wrap* 정공.
+- **`Calculator → Revenue → GameRevenue` 책임 분리 흐름 자가 반영** — 두루의 *"Player의 이윤을 계산하는 것인데, 해당 내용이 과연 Calculator 에 있어야 하는지"* 진단 → 학생 *"Revenue 클래스를 따로 만들어 분리"* → 추가 진단 *"게임 Player에 대한 결과를 구하는 것인데, 과연 Revenue에 있는 것이 맞을까"* → 학생 *"Result 클래스에서 승무패 결과를 구하도록 분리"* → *PlayerRevenue/DealerRevenue sealed class → GameRevenue 통합* (지나친 추상화 회피).
+- **`Card data class + toString() override` 자가 학습** — 두루 자가 인용: *"toString의 활용과 Card를 data class로 만들어주셨네요~ 이번 리뷰때 여쭤보려고 남겨두었는데ㅎㅎ 정말 좋습니다!!"*. *Kotlin data class + toString 어휘 활용*.
+- **`Revenue.toString()` 오버라이딩 — View 책임 분리** — 두루의 *"해당 내용을 Revenue라는 객체를 만들고 toString을 오버라이딩 하는 방법으로 해봐도 좋을 것 같다"* 권고 → 학생 자가 반영: *"Revenue클래스에서 toString으로 처리하였습니다!"*.
+- **InputView / OutputView 분리 자가 반영 — `SettingInputView` / `ProgressInputView` + `ProgressOutputView` / `ResultOutputView`** — 두루의 *"InputView도 InitializeInputView, GameInputView 등으로 분리"* 권고 → 학생 자가 반영. *View 책임을 단계별로 분리* — *입력 받기 단계 vs 게임 진행 단계*. *MCP 룰 후보 — `view-by-stage-split`*. PR #131 (다이스 2단계) 의 *BlackJackInputView/BlackJackOutputView interface* 와 비교: *interface vs 단계별 분리* 트레이드오프.
+- **`model` 패키지 분리 — `card` / `game` / `user`** — 두루 권고 *"model 내에서도 금액, 참가자, 결과를 담당하는 객체들의 패키지를 나눠두는 것"* 자가 반영. *도메인 그룹별 패키지* 가 *프로젝트 구조 명료성*.
+- **`PlayerRevenue` / `DealerRevenue` sealed class → `GameRevenue` 통합 자가 후퇴** — 두루: *"현재 구현하신 내용을 보면 너무 지나치게 Sealed Class로 Player와 Delear를 나눈 것으로 보입니다🥲 ... `명확하게 기능을 담당하지 않은 상태에서의 지나친 추상화 가독성과 해당 객체에 대한 명확한 책임 판별을 와해 시킨다는 생각이 듭니다`"*. 학생 자가 반영: *"PlayerRevenue와 DealerRevenue를 Revenue라는 객체를 가지는 GameRevenue라는 하나의 클래스로 통합"*. **지나친 추상화 회피 자가 학습 모범**.
+- **`GameInformation` 삭제 → Hand + State 분리 자가 반영** — 두루의 *"Participant 객체에서 Score를 가지고 있는다. Hand 내부에서 State에 대해서 상태를 들고 있으며, State에 결정은 Hand 에서 draw()함수를 호출할 때 내부적으로 판단을 한다. ... player.gameInformation.hand.cards 이렇게 계속 깊게 들어가는 구현이 사라질수 있을 것 같다"* 진단 → 학생 자가 반영: *"Hand 내부에서 cards를 가지고 있기 때문에 Participant보다는 Hand가 score를 가지고 있는게 더 어울린다고 생각하여 수정하였고, Participant가 state를 가지고 있게 하여 GameInformation을 삭제"*. **Demeter 위반 해소**. PR #133 (시아 2단계) 의 *Items + Demeter 깊이* 와 같은 결.
+- **테스트 함수명 *행위→결과* 자가 학습** — 두루의 *"테스트 함수명을 좀 더 명확하게 `행위 -> 결과`로 작성"* + *"`Ace가 2장 있을 때 카드 점수의 합은 12이다` 라는 테스트 함수명"* 권고 자가 반영. *테스트 = 명세*.
+- **테스트 매직넘버 상수화 자가 반영** — 두루 권고 자가 후속.
+- **Kotlin `named arguments` 자가 학습** — 두루의 *실제 이슈 예시 (`val foo = Foo(100)` → 의도와 다른 결과)* + named arguments 권고 → 학생 자가 반영: *"judgeDrawOrNot함수의 readDecision과 output에 대하여 named arguments을 적용"*.
+- **`readDecision() = false` 같은 *불필요한 헬퍼* 자가 삭제** — 두루의 *"아래의 해당 코드가 있어야 하는 이유가 궁금합니다"* 진단 → 학생 *"함수를 삭제하고 true, false를 직접 넣어주는 방식으로 변경"*.
+- **Players 객체 생성 위치 자가 결정 (`SettingInputView`)** — 두루 권고 *"Players 객체에서 담당을 해보도록"* 에 대해 학생 자가 답변: *"Players 객체를 따로 만드는 것 보다는 이름과 베팅금액을 입력받을때 바로 Players를 만들어서 반환하는 것이 더 좋은 방법이 될 것 같다는 생각에 SettingInputView에서 처리"*. **권고 vs 자가 판단의 합리적 분리**.
+- **함수 분리 자가 반영** — 두루의 *"`딜러의 이윤을 출력`, `플레이어의 이윤을 출력` 과 같이 하나의 함수에서는 하나의 기능을 담당"* 권고 후속.
+
+## 못한 점 (설계 관점)
+
+### 1. `GameInformation` 통합 객체 — *3 변수 제약 회피용 인공 객체 (자가 인식)*
+
+학생 자가 답변: *"GameInformation이 없고 Hand와 State를 각각 나눠서 가지고 있게 되면 Participant에서 ParticipantInformation, Hand, State를 생성자에서 가지고 있기 때문에 \"3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.\"라는 요구조건을 지키지 못한다고 생각하여, GameInformation을 Hand와 State를 가지도록 묶었습니다..!"*
+
+→ **`GameInformation = Hand + State` 묶음 = *3 변수 제약 회피용 인공 객체***. *학생이 자가 인식*. *후속 반영* 시 GameInformation 삭제 → Hand + State 직접 보유로 후퇴. 깊이 ↓ + 인공 객체 ↓.
+
+PR #133 (시아 2단계) 의 *Items* / PR #132 (환노 2단계) 의 *BetStatus/ProceedStatus* / PR #136 (밀러 2단계) 의 *BlackJackPair* 와 같은 결의 *3 변수 제약 부산물* 패턴.
+
+### 2. `Information` / `Manager` / `Calculator` 만능 명사 — 자가 후퇴 흐름
+
+학생 흐름:
+1. `Calculator` (이윤 계산) — 두루 진단 *"Calculator 에 있어야 하는지"*
+2. `Revenue` 클래스 분리
+3. `GameRevenue` 게임 결과 분리
+4. `PlayerRevenue` / `DealerRevenue` sealed class (지나친 추상화)
+5. `GameRevenue` 통합 (자가 후퇴)
+
+→ **`Calculator` 같은 *만능 명사*가 *초기 책임 분배의 함정***. *MCP 룰 후보 — `vague-class-name` 룰의 *Calculator/Information/Manager* 변형*. 학생 자가 후퇴로 *완전한 도메인 어휘 (Revenue/GameRevenue)*로 정착.
+
+### 3. `Participant.gameInformation.hand.cards` Demeter 깊이 (수정 전) — 자가 해소
+
+두루 진단: *"`player.gameInformation.hand.cards` 이렇게 계속 깊게 들어가는 구현이 사라질수 있을 것 같다"*. 학생 자가 반영 후 *`player.cards` (Participant 위임)* 로 짧아짐.
+
+### 4. *지나친 추상화 (`Sealed Class`로 Player/Dealer Revenue 분리)*
+
+두루 진단: *"명확하게 기능을 담당하지 않은 상태에서의 지나친 추상화 가독성과 해당 객체에 대한 명확한 책임 판별을 와해 시킨다는 생각이 듭니다"*
+
+→ **추상화 = 도메인 차이가 있을 때만**. *PlayerRevenue vs DealerRevenue 의 책임 차이가 크지 않으면 통합*. *학생 자가 후퇴 = 추상화의 트레이드오프 학습 모범*. PR #131 (다이스 2단계) 의 *Hand → PersonCards 수직 분리 후 다시 합침* 과 같은 결.
+
+### 5. 메서드명 *judgeXXX* / *readXXX* — 명확성 개선 여지
+
+```kotlin
+fun readDecision(): Boolean = false  // ⚠ 호출자가 어떤 의미인지 모름
+fun judgeDrawOrNot(...) { ... }
+```
+
+→ *judgeXX = 판단 + 결과*. *Kotlin 어휘로는 `shouldDraw(): Boolean`* 같은 *부울 메시지*가 자연. 학생 자가 일부 반영.
+
+### 6. *`Hand` 부 생성자 미사용* 자가 발견
+
+```kotlin
+class Hand(cards: List<Card>) { ... }
+```
+
+두루 진단 → 학생 *"다른데서 사용한다고 생각하고 생성자로 만들어놓았는데 다른데서 사용이 되지않아 삭제 처리"*.
+
+→ **불필요한 생성자 미리 추가 = 추측 코딩**. *YAGNI 위반*. *현재 사용처에서 시작 + 필요 시 추가*가 정공.
+
+## 리뷰어 의견 요지
+
+- **칭찬 위주 + 메타 질문** — *🤔 / 👍 / 💪* 다수. *깊은 진단 < 자가 학습 기회 제공*. PR #131 (다이스 2단계) 와 같은 결.
+- **지나친 추상화 = 가독성 + 책임 판별 와해** — *추상화는 도메인 차이가 있을 때만*. *Sealed class 무분별 사용 경계*.
+- **테스트 함수명 = 행위 → 결과** — *`Ace가 2장 있을 때 카드 점수의 합은 12이다`* 같은 *기능 명세*.
+- **named arguments — 실제 이슈 예시** — *`Foo(100)` 호출이 의도와 다른 결과* 의 실제 사례. *Kotlin named arguments 가 그 방지*.
+- **`toString` override = View 책임 분리** — *도메인 객체의 문자열 표현* 을 *도메인 자체가 알리고 View는 받기만*.
+- **단일 책임 함수 분리** — *딜러 + 플레이어 출력 한 함수 → 별도 함수*.
+- **만능 명사 → 도메인 어휘** — *Calculator → Revenue → GameRevenue* 흐름.
+- **3 변수 제약 = 연습 도구, 너무 얽매이지 말 것** — *GameInformation 같은 인공 객체 회피*.
+
+## 대표 인용
+
+**두루 (지나친 추상화 경계, Revenue.kt):**
+> 현재 구현하신 내용을 보면 너무 지나치게 Sealed Class로 Player와 Delear를 나눈 것으로 보입니다🥲
+> 해당 내용은 Revenue라는 객체를 가지고 함수로 PlayerRevenue와 DelearRevenue를 분리하는 것은 어떤가 하는 생각이 듭니다🤔
+>
+> `명확하게 기능을 담당하지 않은 상태에서의 지나친 추상화 가독성과 해당 객체에 대한 명확한 책임 판별을 와해 시킨다는 생각이 듭니다`
+
+**두루 (Demeter 위반 자가 해소 권고, GameInformation.kt):**
+> 추후에 시간이 된다면 아래와 같은 방법으로 바꿔보는 것도 해보시면 좋을 것 같다는 생각이 듭니다!!
+> 1. Participant 객체에서 Score를 가지고 있는다.
+> 2. Hand 내부에서 State에 대해서 상태를 들고 있으며, State에 결정은 Hand 에서 draw()함수를 호출할 때 내부적으로 판단을 한다.
+>
+> 위의 2가지가 충족이 된다면, GameInformation 이라는 객체는 사라질 수 있겠다는 생각이 듭니다💪
+> 또한, 위처럼 수정을 하게된다면, player.gameInformation.hand.cards 이렇게 계속 깊게 들어가는 구현이 사라질수 있을 것 같다는 생각이 듭니다~
+
+**두루 (named arguments 실제 이슈 예시, BlackJackController.kt):**
+> 실제로 있었던 이슈를 예시로 공유를 드리고자 합니다.
+> 아래와 같은 `Foo()`라는 함수가 존재를 하며, 각각의 a, b, c 에 들어가는 값에 따라서 로직에서 호출을 하는 함수가 다르다고 할때, Foo()에 대해서 파악을 하지 않은 상태에서 아래와 같이 `val foo = Foo(100)` 으로 선언을 하여, c라는 결과를 생각했지만, a라는 결과가 나와서 중요기능이 동작을 하지 않았던 이슈가 있었습니다.
+
+**학생 자가 답변 (GameInformation 통합 이유 자가 인식, GameInformation.kt):**
+> GameInformation이 없고 Hand와 State를 각각 나눠서 가지고 있게 되면 Participant에서 ParticipantInformation, Hand, State를 생성자에서 가지고 있기 때문에 "3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다."라는 요구조건을 지키지 못한다고 생각하여, GameInformation을 Hand와 State를 가지도록 묶었습니다..!
+> State를 판별하는 로직을 GameState 안에서 판별하도록 로직의 위치를 변경하였습니다!
+
+**학생 자가 후속 (Demeter 해소 + 인공 객체 삭제, GameInformation.kt):**
+> Hand 내부에서 cards를 가지고 있기 때문에 Participant보다는 Hand가 score를 가지고 있는게 더 어울린다고 생각하여 수정하였고, Participant가 state를 가지고 있게 하여 GameInformation을 삭제해 보았습니다!
+
+**학생 자가 답변 (권고 vs 자가 판단 합리적 분리, BlackJackController.kt):**
+> Players 객체를 따로 만드는 것 보다는 이름과 베팅금액을 입력받을때 바로 Players를 만들어서 반환하는 것이 더 좋은 방법이 될 것 같다는 생각에 SettingInputView에서 처리하게 수정해 보았습니다!
+
+## 얻은 교훈
+
+1. ***지나친 추상화 = 가독성 + 책임 판별 와해***. *PlayerRevenue / DealerRevenue sealed class* 처럼 *책임 차이가 작은데 추상화*는 *코드 복잡도 ↑ + 의의 부재*. *통합 = 추상화의 트레이드오프 학습*. PR #131 (다이스 2단계) 의 *Hand → PersonCards 분리 후 다시 합침* 과 같은 결.
+
+2. ***`Calculator`/`Information`/`Manager` 같은 만능 명사 = 책임 분배의 함정***. *책임이 안 잡힌 곳에 *Calculator* 가 등장*. *Revenue / GameRevenue / Result* 같은 *도메인 어휘*로 후퇴가 정공. *MCP `vague-class-name` 룰 확장*: *Calculator/Information/Manager* 추가 후보. PR #128·#125·#114·#10 와 같은 결의 *vagueName 안티패턴 변형*.
+
+3. ***`GameInformation = Hand + State` 묶음 = 3 변수 제약 회피용 인공 객체*** — 학생 자가 인식 + 후속 삭제. PR #133·#132·#136 와 같은 결의 *제약 부산물 vs 정당한 도메인 객체* 트레이드오프. *제약은 연습 도구* (말리빈/두루 공통 진단).
+
+4. ***Demeter 위반 = `a.b.c.d` 점 체인 = 협력 부재 신호***. *`player.gameInformation.hand.cards`* 가 *4 단계*. *위임 메서드 (Participant.cards)* 가 *호출자가 알아야 하는 객체 수 최소화*. PR #133·#131·#152·#136·#128·#135 와 같은 결.
+
+5. ***Kotlin `named arguments` = 인자 순서 함정 방지***. *실제 이슈 사례 = Foo(100) 호출이 의도와 다른 결과*. *`Foo(a = 0, b = 0, c = 100)` named* 가 *호출 의도 명시 + 컴파일러 안전성*. *Kotlin 어휘 활용 모범*.
+
+6. ***`toString` override = 도메인 객체가 자기 문자열 표현 알림***. *View 의 형식 지정 책임 vs 도메인 객체의 표현 책임* 트레이드오프. *현재는 도메인 객체가 자기 표현* — *Tell-Don't-Ask 변형*. *주의: 도메인 객체가 view 의 모든 형식을 흡수하면 도메인-뷰 결합*. *toString = 디버깅 + 단순 표현*에 한정 권고.
+
+7. ***테스트 함수명 = 행위 → 결과 (기능 명세)***. *"Ace가 2장 있을 때 카드 점수의 합은 12이다"* 같은 *도메인 명세*. *함수명 종속 X*. PR #128·#135·#152·#124·#125 와 같은 결.
+
+8. ***View 단계별 분리 (`SettingInputView` / `ProgressInputView`)*** = *View 책임이 단계별로 다름을 노출*. *입력 받기 단계 (베팅, 이름) vs 게임 진행 단계 (Hit/Stay)* 가 *다른 책임*. **MCP 룰 후보 — `view-by-stage-split`** (PR #131 의 *interface 분리* vs PR #88 의 *단계별 분리* 두 표현). PR #131·#132 와 같은 결.
+
+9. ***불필요한 생성자 미리 추가 = YAGNI 위반***. *Hand 부 생성자 미사용 자가 발견 + 삭제*. *현재 사용처에서 시작 + 필요 시 추가* 가 *Kotlin 어휘 활용 정공*.
+
+10. ***리뷰어 칭찬 위주 + 학생 100% 후속 반영 = PR #131·#136 와 같은 결의 모범 학습***. *두루의 *🤔/👍/💪* 메타 질문 위주 + 학생이 모든 코멘트 후속 반영*. *깊은 안티패턴 진단 < 자가 학습 기회 제공* 의 reviewer 스타일 변형.

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

@@ -0,0 +1,269 @@
+# PR #112 — [블랙잭 1단계] 에타마 미션
+
+- **Reviewee:** [@etama123](https://github.com/etama123)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/112
+- **단계:** 1단계
+- **리뷰어:** @krrong (크롱)
+- **라인 코멘트:** 30 (리뷰어 14 / 리뷰이 16)
+
+## 잘한 점 (설계 관점)
+
+- **`Card private constructor + Card.of()` + `Card.getAllCard()` 캐시 — Flyweight 패턴** — 52장 인스턴스를 *유한 집합*으로 제어. lotto의 `LottoNumber` Flyweight와 동일 결.
+- **`Participant` 추상 클래스 + `Dealer`/`Player`** — `hitThreshold`만 추상화하고 *Hit 가능 판단*은 공통.
+- **`Deck(shuffledDeck: List<Card>)` 명시 주입** — 외부에서 카드 순서 제어 → 결정적 테스트.
+- **`Suit`/`Rank` enum + `getScore()`** — Ace=11 기본, 보정은 별도.
+- **학생 자가 토론 — *현실 세계 딜러 vs 객체 딜러* 차이를 미리 PR 본문에 제기** (못한 점 §1).
+- **후속 반영 — `@BeforeEach`로 Deck 격리 + `Card.toString` UI 이관 + `FakeParticipant`를 test 클래스 내부로 이동**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Dealer.getCard(deck: Deck)`가 *초기화 시점에 모든 카드 뽑기* — 현실 게임과 어긋남
+
+```kotlin
+class Dealer : Participant() {
+    override val hitThreshold: Int get() = DEALER_HIT_THRESHOLD
+    fun getCard(deck: Deck) {
+        while (canHit()) {
+            addCard(deck.draw())
+        }
+    }
+    fun hasAdditionalCard(): Boolean = cards.size > INITIAL_CARD_COUNT
+}
+```
+
+학생 자가 토론(PR 본문): "딜러는 첫 번째 카드만 오픈하기 때문에 / hit / stay 여부를 외부에서 입력받지 않기 때문에 / 로직 자체에서 hit의 여부가 결정되기 때문에 딜러 내부에서 카드를 뽑는 로직을 설정했습니다. 하지만 이처럼 *카드를 미리 뽑아두는게, 현실 세계에서의 게임 진행과 다르기 때문에 괜찮을까* 의문이 들었어요."
+
+리뷰어: "현실에서는 딜러가 가지고 있는 카드를 나눠주지만, 객체지향에서는 *참가자와 마찬가지로 카드를 받는 존재*로 볼 수 있습니다!"
+
+학생 해명: "딜러가 2장의 카드를 받은 후, 합이 16 이하일 경우 추가 카드를 뽑고, 17 이상이면 멈추는 규칙을 반영하기 위해 2장 이상의 카드를 미리 뽑아두는 것을 의미했습니다."
+
+→ 패턴: *흐름 단순화*를 위해 *시점을 압축*. 그러나 *Player는 turn 단위 진행 / Dealer는 한 번에 끝남* 의 *비대칭*이 생김. *진행자(Game)*가 Dealer에게 *한 장씩* 메시지 보내는 것이 *대칭적 추상*. 이후 `hasAdditionalCard()` 같은 *상태 조회 메서드*가 *압축된 시점 복구*용으로 필요해진 점이 신호 (못한 점 §2).
+
+### 2. `Dealer.hasAdditionalCard()` — 압축된 시점을 풀기 위한 추적 메서드
+
+```kotlin
+fun hasAdditionalCard(): Boolean = cards.size > INITIAL_CARD_COUNT
+```
+
+리뷰어: "이 메서드가 필요한 이유는 무엇인가요? 🤔" — *Dealer가 미리 다 뽑은* 결과를 *나중에 "추가로 뽑았는지" 묻는* 메서드. *시점 압축 → 복구 메서드*의 안티패턴. *한 장씩 진행*하면 *추가 뽑기 발생 = 그 자체로 사건*이라 별도 추적 불필요.
+
+### 3. `Card.toString()` UI 표현 박힘
+
+```kotlin
+class Card private constructor(val rank: Rank, val suit: Suit) {
+    fun getScore() = this.rank.score
+    override fun toString(): String = rank.toDisplayName() + suit.toDisplayName()
+}
+
+fun Rank.toDisplayName(): String = when (this) { Rank.ACE -> "A"; ... }
+fun Suit.toDisplayName(): String = when (this) { Suit.SPADE -> "♠"; ... }
+```
+
+리뷰어: "`toString`을 오버라이드 한 이유에 대해 생각해보고 도메인에서 필요로 하는 것인가 고민해보면 좋겠어요 🤔"
+학생 자가 인정: "주소값이 출력되었기 때문에 toString을 오버라이드하면 문제가 해결되기에 가벼운 마음으로 사용했습니다. 하지만 결국 이 부분도 UI 로직에 더 가깝다고 생각이 되네요 🥶" — *디버깅 편의*로 시작한 *도메인 메서드*가 *UI 표현 의존*을 도메인에 끌어들임. PR #78·#125와 같은 결.
+
+### 4. `Rank.toDisplayName()` 확장 함수 — 도메인 파일에 *View 함수*
+
+```kotlin
+// blackjack/domain/Rank.kt
+enum class Rank(val score: Int) {
+    ACE(11), ... ;
+}
+fun Rank.toDisplayName(): String = when (this) { ... "A" ... }   // 같은 파일
+
+// blackjack/domain/GameResultStatus.kt
+enum class GameResultStatus { PLAYER_WIN, PLAYER_LOSE, DRAW }
+fun GameResultStatus.toDisplayName(): String = when (this) { PLAYER_WIN -> "승"; ... }
+```
+
+학생 자가 변호: "각 Enum 클래스와 밀접한 관련이 있기 때문에 해당 클래스 아래에 위치하는 것이 가독성과 직관성 측면에서 더 적절하다고 생각합니다."
+
+리뷰어: "관련이 있는 enum클래스에 함께 작성하는 것과 OutputView에 작성하기 모두 장단점이 있어서 트레이드 오프의 영역이라고 볼 수 있어요. 현재의 구현 방식은 출력의 형태를 Win, Lose, Draw 로 변경하려 할 때 *Domain역시 변경이 필요*한데요. 이에 대해서도 고민해보면 좋을 것 같습니다. 그런데 이와는 별개로 *꼭 확장 함수를 사용해야할까요?* 🤔"
+
+학생 후속 인정: "view 관련 로직들은 모두 outputview로 이동시켰습니다." — *Kotlin DSL 수업에서 배운 확장 함수*를 *어디든 적용해보기*는 *기능 사용 욕구*가 *역할 결정*을 압도한 신호.
+
+### 5. `Deck`이 `LinkedList<Card>` — 자료구조 선택의 정당화 부재
+
+```kotlin
+class Deck(shuffledDeck: List<Card>) {
+    private val deck = LinkedList(shuffledDeck)
+}
+```
+
+리뷰어: "`LinkedList`...요? 🤔" — *왜 `ArrayDeque`나 `MutableList`가 아니고 `LinkedList`인가?* 자료구조 선택은 *접근 패턴에 따른 결정*(랜덤 액세스 빈도, 양 끝 추가/제거 등). 블랙잭의 *맨 위 카드 꺼내기*는 `ArrayDeque.removeFirst()` 또는 `MutableList.removeFirst()`로 충분. `LinkedList`는 *Java 컬렉션 어휘*를 *습관적 선택*한 신호.
+
+### 6. `Participant.addCard()`가 *카드 추가 + 합산* 두 일
+
+```kotlin
+fun addCard(card: Card) {
+    cards.add(card)
+    totalSum = calculateTotalSum()       // 추가하면서 totalSum도 갱신
+}
+```
+
+리뷰어: "addCard라는 메서드명을 보고 카드를 뽑겠구나라고 기대했지만 내부에서는 *총합을 함께 계산*하고 있어요. 하나의 함수가 하나의 일만 할 수 있도록 변경해볼까요 🤠" — *Command-Query 혼합* 변형. `addCard()`는 *카드 추가*만, `totalSum`은 *접근 시점 계산*(custom get())이 자연. *상태 캐시 갱신*을 *액션과 묶으면* 호출자가 `totalSum`의 *최신성*을 *항상* 신경 써야 함.
+
+### 7. `Participant.cards: MutableList<Card>` public — 일급 컬렉션 부재
+
+```kotlin
+abstract class Participant {
+    var totalSum: Int = 0
+        private set
+    val cards: MutableList<Card> = mutableListOf()       // public mutable
+    ...
+}
+```
+
+리뷰어: "*카드들을 갖는 일급 컬렉션을 만들어볼까요?* 어떤 장점을 얻을 수 있을까요? 🤔" — `Hand`/`Cards` 일급 컬렉션이 *cards 보관 + 점수 계산 + Ace 보정*을 담당하면 `Participant`는 *결정 + 정체성*만. (PR #123 후반의 자가 인정과 같은 결.)
+
+### 8. `BLACKJACK_LIMIT = 21` 이름 — 상수 의미와 사용처 불일치
+
+```kotlin
+companion object {
+    const val BLACKJACK_LIMIT = 21
+    const val ACE_SCORE_DIFFERENCE = 10
+}
+
+fun isBust(): Boolean = totalSum > BLACKJACK_LIMIT
+```
+
+리뷰어: "21은 *BUST의 기준!* 으로 네이밍하는게 더 적절해 보이네요 🤠" — 21을 *블랙잭 한계*로 표현했으나 *사용처는 모두 Bust 판정*. `BUST_THRESHOLD = 21` 또는 `BLACKJACK_SCORE = 21`이 도메인 어휘와 *사용 의도* 둘 다 일치.
+
+### 9. `Rank.ACE.score = 11` — 일반 통념과 어긋남
+
+```kotlin
+enum class Rank(val score: Int) {
+    ACE(11),   // ⚠ 일반적으로 1
+    TWO(2), THREE(3), ...
+}
+```
+
+리뷰어: "일반적으로 ACE는 몇이라고 생각할까요? 🤔" — *Ace를 11로 시작 + 합이 21 초과면 보정*은 *블랙잭의 한 가지 알고리즘*이지만, *Ace의 기본값*은 보통 *1*. *알고리즘 편의*가 *도메인 어휘를 왜곡*한 신호. (대안: *Ace를 1로 시작 + 11점 추가 검토 시점에 +10*. — PR #63 리뷰어 권고와 동일.)
+
+### 10. `calculateTotalSum`이 *while + 차감* Ace 보정 — 복잡
+
+```kotlin
+private fun calculateTotalSum(): Int {
+    var score = cards.sumOf { it.getScore() }
+    var aceCount = cards.count { it.rank == Rank.ACE }
+    while (score > BLACKJACK_LIMIT && aceCount > 0) {
+        score -= ACE_SCORE_DIFFERENCE
+        aceCount--
+    }
+    return score
+}
+```
+
+리뷰어: "ACE가 포함된 카드의 총합을 구하는 방법을 다시 한 번 고민해볼까요? 🤔" — PR #63와 동일한 *while + 차감* 패턴. *Ace = 1로 시작 + 합 ≤ 11이면 +10* 한 줄 룰로 단순화 가능.
+
+### 11. `DealerResult` / `GameResult` / `PlayerResult` — 결과 객체 셋
+
+```kotlin
+class GameResult(private val dealer: Dealer, val players: List<Player>) {
+    val dealerResult = DealerResult()
+    private val playerResult: MutableList<PlayerResult> = mutableListOf()
+}
+class DealerResult { /* WIN count, LOSE count, ... */ }
+class PlayerResult { /* Player + GameResultStatus */ }
+```
+
+리뷰어: "`DealerResult`, `GameResult`, `PlayerResult` 게임의 결과를 위한 길이 많이 험난해보여요 😵‍💫 블랙잭은 *딜러와 플레이어간의 게임*입니다. 이 말을 잘 곱씹어보면 *플레이어의 승패는 딜러의 승패와 관련*이 있는 것 같아요." — *Dealer 결과 = Player 결과의 역집계*. `Map<Player, GameResultStatus>` 한 자료구조로 *딜러 통계 = entries.groupBy { it.value }* 도출 가능. 객체 3개로 흩뜨리면 *동기화 책임*만 늘어남.
+
+학생 자가 토론: "Dealer와 Player 모두 같은 **Participant**이므로, 결과도 비슷한 형태로 저장할 수 있지 않을까 고민했습니다. 현재 `PlayerResult가` `Player`와 `GameResultStatus`를 가지는 것처럼, `Result`도 `Participant`와 `GameResult`를 가지는 방식으로 구조를 개선하는 것을 고민 중입니다." — *공통 추상*까지 도달했으나 *역집계로 단순화*는 미발견.
+
+### 12. `CardTest`가 *Deck 기능 테스트*
+
+```kotlin
+class CardTest {
+    @Test
+    fun `Card는 52개의 인스턴스만 가질 수 있다`() {
+        // Card.getAllCard().size == 52 검증
+    }
+}
+```
+
+리뷰어: "CardTest이지만 Deck의 기능을 테스트하는 것처럼 보이네요 🤔" — `Card.getAllCard()`는 *Card의 정적 메서드*지만 *전체 카드 집합 = Deck의 책임*. *Flyweight 캐시 보유자*와 *덱의 책임*이 같은 메서드에 모임. `Card.getAllCard()` → `Deck.createShuffledDeck()` 같은 이름이 자연.
+
+### 13. `ParticipantTest`에서 *Deck 호출 = 한 장 가져오기*로 오해 가능 함수명
+
+```kotlin
+@Test
+fun `덱에서 한 장의 카드를 가져올 수 있다`() {
+    val fake = FakeParticipant()
+    fake.addCard(Card.of(Rank.ACE, Suit.SPADE))   // Deck 안 거치고 직접
+    ...
+}
+```
+
+리뷰어: "작성한 테스트는 *덱에서 한 장의 카드를 가져오는 것처럼 보이지 않*네요 😅" — 테스트가 *FakeParticipant.addCard()*를 호출하지만 함수명은 *덱에서 가져오기*. *시나리오 + 결과*가 *코드와 일치*해야.
+
+### 14. `DeckTest`에서 *enum 순서 의존 + 클래스 멤버 직접 초기화*
+
+```kotlin
+class DeckTest {
+    private val testDeck = Deck(Card.getAllCard())       // 클래스 필드 초기화
+    @Test
+    fun `뽑은 카드는 덱에 존재하지 않는다`() {
+        val card1 = testDeck.draw()
+        assertThat(card1).isEqualTo(Card.of(Rank.ACE, Suit.SPADE))    // enum 순서 의존
+        ...
+    }
+}
+```
+
+리뷰어: "`testDeck`을 위처럼 선언하면 어떤 문제가 생길 수 있을까요? 🤔" / "`Suit` 혹은 `Rank`의 순서가 변경되면 어떻게 될까요? 🤔" — *순서 의존* + *공유 인스턴스*. 학생 후속 반영: `@BeforeEach` + *반환값이 덱에 포함되어 있는지*로 *명시적 검증*.
+
+### 15. `FakeParticipant` 위치 — 프로덕션 소스 X, 테스트 fixture로
+
+```kotlin
+// src/test/kotlin/blackjack/FakeParticipant.kt
+class FakeParticipant : Participant() { ... }
+```
+
+리뷰어: "테스트용 객체를 만들었네요 👏 한 곳에서만 사용하고 있는 것 같으니 *위치를 옮겨볼 수도* 있을 것 같아요!" — 1회만 쓰이면 *fixture* 파일에 둘 필요 없이 *테스트 클래스 내부 private*. 학생 후속 반영.
+
+## 리뷰어 의견 요지
+
+- **현실 딜러 ≠ 객체 딜러** — 객체 딜러도 *카드를 받는 존재*. *미리 다 뽑기*는 *시점 압축 + 복구 메서드 필요*의 신호.
+- ***DealerResult/GameResult/PlayerResult* 셋은 과잉** — *Player 결과 → Dealer 통계 역집계*.
+- **`toString` 도메인 X, `OutputView` ○.**
+- **enum 옆 *toDisplayName 확장함수*는 *도메인-뷰 결합*** — 가까이 두고 싶은 욕구 vs 변경 전파.
+- ***`addCard`가 합산까지*** — CQS 혼합.
+- ***일급 컬렉션 부재*** — `MutableList<Card>` public.
+- **`LinkedList` 선택의 정당화** — `ArrayDeque`/`MutableList`가 자연.
+- **`BLACKJACK_LIMIT` 명명** — 사용처가 Bust 판정.
+- **`ACE = 11` 일반 통념과 어긋남.**
+- ***while + 차감 Ace 보정* 복잡** — *Ace 1 시작 + 11점 단일 검토*.
+- ***테스트 멤버 직접 초기화 + enum 순서 의존*** — `@BeforeEach` + 명시 검증.
+
+## 대표 인용
+
+> 현실에서는 딜러가 가지고 있는 카드를 나눠주지만, 객체지향에서는 *참가자와 마찬가지로 카드를 받는 존재*로 볼 수 있습니다!
+> — @krrong on `src/main/kotlin/blackjack/domain/Dealer.kt`
+
+> `DealerResult`, `GameResult`, `PlayerResult` 게임의 결과를 위한 길이 많이 험난해보여요 😵‍💫 블랙잭은 *딜러와 플레이어간의 게임*입니다. 이 말을 잘 곱씹어보면 *플레이어의 승패는 딜러의 승패와 관련*이 있는 것 같아요.
+> — @krrong on `src/main/kotlin/blackjack/domain/DealerResult.kt`
+
+> addCard라는 메서드명을 보고 카드를 뽑겠구나라고 기대했지만 내부에서는 *총합을 함께 계산*하고 있어요. 하나의 함수가 하나의 일만 할 수 있도록 변경해볼까요 🤠
+> — @krrong on `src/main/kotlin/blackjack/domain/Participant.kt`
+
+> 일반적으로 ACE는 몇이라고 생각할까요? 🤔
+> — @krrong on `src/main/kotlin/blackjack/domain/Rank.kt`
+
+> 출력의 형태를 Win, Lose, Draw 로 변경하려 할 때 *Domain역시 변경이 필요*한데요. [...] 그런데 이와는 별개로 *꼭 확장 함수를 사용해야할까요?* 🤔
+> — @krrong on `src/main/kotlin/blackjack/domain/GameResultStatus.kt`
+
+## 얻은 교훈
+
+- **객체 딜러는 *카드를 받는 존재*. *현실 비유*가 *시점 압축*을 정당화하면 *복구용 상태 조회 메서드*(`hasAdditionalCard()`)가 필요해짐 — 시점 압축 신호.**
+- **`toString()`은 *도메인 메서드*가 아님** — 디버깅 편의로 시작해도 결국 *UI 결합*. `OutputView.format(card)` 자연.
+- **enum 옆 `toDisplayName()` 확장 함수 = *근거리 변경 편의*가 *역할 결정*을 압도** — *수업에서 배운 기능 적용 욕구*가 *역할 분리*를 흐림.
+- ***`addCard()`가 합산까지* = CQS 혼합** — `addCard` 액션 + `totalSum` 접근 시 계산이 자연.
+- ***결과 객체 셋(`DealerResult`/`GameResult`/`PlayerResult`)은 과잉*** — `Map<Player, GameResultStatus>` 단일 자료구조 + 역집계가 더 단순. *공통 추상*까지 갔는데 *단순화*는 미발견.
+- **`LinkedList`는 *Java 어휘 습관* 선택** — Kotlin은 `ArrayDeque`/`MutableList`로 *맨 위 카드 꺼내기*가 더 자연.
+- **`BLACKJACK_LIMIT = 21` 명명은 *사용처와 의도*로** — 모든 사용처가 Bust 판정이면 `BUST_THRESHOLD`가 정직.
+- **`Rank.ACE.score = 11` = 일반 통념 위배** — *알고리즘 편의*가 *도메인 어휘*를 왜곡. *Ace = 1 기본 + 11 검토*가 통념 일치.
+- ***while + 차감 Ace 보정*은 PR #63·#78과 동일한 안티패턴 — *합 ≤ 11이면 +10* 한 줄 룰.**
+- **`CardTest`가 *Deck 책임* 검증** — `Card.getAllCard()`라는 *Flyweight 캐시 메서드* 위치가 모호하면 *덱의 책임*도 *Card에 누수*.
+- ***테스트 fake가 한 곳만 쓰이면 내부 private*** — 별도 파일은 *재사용 의도가 있을 때만*.
+- **enum `entries` 순서를 *테스트 진실*로 삼지 말 것** — 순서 변경 = 테스트 깨짐.