oh-my-oop 0.2.0

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

@@ -0,0 +1,391 @@
+# PR #58 — [블랙잭 2단계] 수달 미션
+
+- **Reviewee:** [@otter66](https://github.com/otter66)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/58
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 18 스레드 / 22 코멘트 — *6덱 카지노 메타포 + MatchResult getResult naming + Participant 가변 betting 노출* 토론
+
+## 잘한 점 (설계 관점)
+
+- **`MultiDeck` 6덱 도입 — 카지노 룰 메타포** — `private const val DECK_COUNT = 6` + `List(6) { createCardPack() }.flatten().shuffled()`. 학생 자가 인용: *"앗... 이 부분은 카지노에서의 블랙잭 게임 규칙을 반영시켰습니다! 블랙잭 게임을 할 때에는 카드 카운팅을 어렵게 하기 위해 여러개의 덱을 사용하는 멀티덱 방식을 사용하는데, 그 중에서도 6개의 덱을 사용하는 것이 일반적이라고 하여 그 부분을 적용시켜보았습니다..!"*. **현실 메타포 자가 학습 모범**. 다만 *요구사항과 동떨어짐* 진단도 동반 (못한 점 §1).
+- **State 학습 테스트 자가 작성** — 페로로 자가 칭찬: *"여러가지 도전을 위한 학습 테스트 좋습니다. 👍🏻"*. `src/test/kotlin/study/blackjack/state/State.kt` 위치 — *production code 외 학습 테스트* 분리. **학습 가시화 모범**.
+- **`Card data class private constructor + Card.from(rank, shape)` factory** — *호출 모호함 회피*. PR #133·#93·#136 와 같은 결.
+- **`Cards.sum()` Ace 보정 — *`sum + 10 <= 21` 정확 조건*** — *PR #128·#114·#125·#108·#131·#132·#41·#49 와 같은 결의 표준 패턴*.
+- **`Player abstract class + Participant / Dealer 다형성 (`canHit`)`** — 1단계 *open class* 진단 후속. *Player abstract = 공통, Participant = 베팅 보유 플레이어, Dealer = 16점 이하 hit*. PR #132·#136·#108·#133 와 같은 결의 *Participant 다형성*.
+- **`GameResult enum + ratio: Float (WIN 1.0, BLACKJACK 0.5, DRAW 0.0, LOSE -1.0)`** — *BLACKJACK ratio = 0.5* = *보너스 비율* (1.5배 = WIN ratio 1.0 + BLACKJACK ratio 0.5). 다만 *룰 정확성 문제* 동반 (못한 점 §5).
+- **`Dealer.getPayout(participants, results) = sum * -1`** — *딜러 수익 = 플레이어 합 × -1*. PR #131·#132·#133·#136·#49 와 같은 결.
+- **카드 부족 룰 자가 학습 — 6덱 사용으로 카지노 표준 반영** — *학생 자가 학습 + 메타포 명시*.
+- **BettingAmount 외부 변경 가능성 자가 해소 (커밋 진행)** — 페로로 진단 *"배팅금액이 위처럼 노출된 이유는 무엇일까요?"* + 학생 자가 답변: *"이전에 코틀린 프로퍼티에 대해 알아보았고, 코틀린에서는 기본 접근자를 메서드로 만들면 안된다는 것을 알았습니다. ... 또한, 이렇게 바꾸고 생각해보니 외부에서 자유자재로 변경이 가능한 상태이기에 값에 문제가 생길 수 있을 것이라 생각했습니다. 따라서 언제든지 외부에서 변경이 가능한 값이 아니라, 생성시 생성자로 받아 읽기전용 값으로 만들어 가지고있도록 변경하였습니다!"*. **Kotlin property 어휘 + 캡슐화 자가 학습 모범**.
+
+## 못한 점 (설계 관점)
+
+### 1. `MultiDeck(6덱)` 적용 — *요구사항과 동떨어짐 진단*
+
+```kotlin
+class MultiDeck private constructor(
+    cards: List<Card> = listOf()
+) {
+    ...
+    private val _cards: MutableList<Card> =
+        if (cards.isEmpty()) List(DECK_COUNT) { createCardPack() }.flatten().shuffled().toMutableList()
+        else cards.toMutableList()
+
+    fun draw(): Card = _cards.removeAt(0)
+    ...
+    companion object {
+        private const val DECK_COUNT = 6
+    }
+}
+```
+
+페로로 (MultiDeck.kt:22 — 미해결): *"6개의 덱을 준비시키는 이유는 무엇인가요? 요구사항과 많이 동떨어진 느낌이라 이유가 궁금합니다"*
+
+학생 자가 답변: *"앗... 이 부분은 카지노에서의 블랙잭 게임 규칙을 반영시켰습니다!"*
+
+→ **현실 메타포 vs 요구사항 트레이드오프**. *카지노 표준 = 6덱* 학습 가치 ↑. 다만 *우아한테크코스 블랙잭 룰* 가정 (PR #85 페로로 진단: *"커스텀 룰에서 뽑을 수 있으니까 라는 답 대신, 연습을 위해 해보시면 좋겠습니다. 지금은 우아한테크코스 블랙잭 룰을 구현하고 있으니까요"*) 와 *부분 충돌*. *현실 메타포 = 학습 가치 ↑ + 요구사항 일치 ↓*. PR #108·#133 (시아) 의 *6덱 + 카지노 무한 게임 메타포* 와 같은 결.
+
+### 2. `MatchResult.getUniqueCountResult()` — *count == 1 인 결과 첫 번째 = naming 모호 + 부정확*
+
+```kotlin
+class MatchResult {
+    private val countBy: MutableMap<GameResult, Int> = ...
+
+    fun getUniqueCountResult(): GameResult =
+        this.countBy.filter { it.value == 1 }.keys.first()
+    ...
+}
+```
+
+페로로 (MatchResult.kt — 미해결): *"`getResult()`가 무엇을 반환하는 것인지 사용하는 측이 알 수 있을까요?"*
+
+페로로 추가 (MatchResultTest.kt:13 — 미해결): *"MatchResult에 승리, 패배, 무승부 횟수를 가지고 있기 때문에 MatchResult에게 각 결과에 따른 갯수를 얻도록 하는 방법이 좋겠습니다. > 게임의 결과를 스스로 판단해서 반환하도록 만들어야 한다 `matchResult.count(GameResult.WIN); val actual = matchResult.getCountBy(GameResult.WIN)`"*
+
+→ **`getUniqueCountResult` = *count == 1 인 결과의 첫 번째***. *플레이어 매치 1회 가정* — *count 1 인 결과 = 그 플레이어 결과*. *논리는 정합* 이지만 *naming 모호 + 사용 의도 미명료*. *`getCountBy(GameResult)` 같은 *명시적 메시지*가 정공. *MatchResult 가 자기 정보 알리는 방식*.
+
+또한 `getUniqueCountResult` 가 *match 가 여러 번 일어났을 때 잘못 동작* — *count == 1 결과 여러 개일 수 있음 (예: WIN 1번 + LOSE 1번)*. *현재 사용처 = match 1회 가정* — *우회*. *멀티 매치 도메인 확장 시 깨짐*.
+
+### 3. `MatchResult.reversGameResult()` — *오타 + 가변 변경 + 사용 의도 부재*
+
+```kotlin
+fun reversGameResult() {
+    val winTmp = this.countBy[GameResult.WIN]
+    this.countBy[GameResult.WIN] = this.countBy[GameResult.LOSE] ?: throw IllegalArgumentException()
+    this.countBy[GameResult.LOSE] = winTmp ?: throw IllegalArgumentException()
+}
+```
+
+페로로 (MatchResult.kt — 미해결): *"키값이 없는 경우는 논리적인 오류로 보이지 않습니다. 예외를 발생시키지 않도록 만들어주세요"*
+
+→ **`reversGameResult()` 오타 (`Revers` → `Reverse`) + Win/Lose 키 swap + ?: throw**. *Map 키 존재 보장 (countBy 초기화 시 모든 enum 포함)* 이지만 *?: throw* 우회. *논리 오류 아님* — *예외 던질 필요 없음*. 페로로 진단.
+
+또한 *Win/Lose swap = 딜러 입장 결과*. *Dealer.matchResult.reverse() → Player 결과 도출* 의도. *명시적 메서드 명 = `asDealerResult()` / `mirrorAsDealer()`* 가 자연. *현재 reverse 는 모호*.
+
+### 4. `Player.matchGameResult(otherPlayer)` — *분기 순서 오류 (Blackjack 분기 누락 신호)*
+
+```kotlin
+fun matchGameResult(otherPlayer: Player): GameResult {
+    val otherPlayerCardsSum: Int = otherPlayer.cards.sum()
+    val cardsSum = cards.sum()
+
+    return when {
+        cardsSum > MAX_SUM_NUMBER -> GameResult.LOSE
+        otherPlayerCardsSum > MAX_SUM_NUMBER -> GameResult.WIN
+        otherPlayerCardsSum > cardsSum -> GameResult.LOSE
+        otherPlayerCardsSum == cardsSum -> GameResult.DRAW
+        cards.isBlackjack() -> GameResult.BLACKJACK   // ⚠ 점수 비교 후에 도달
+        else -> GameResult.WIN
+    }
+}
+```
+
+→ **분기 순서 = Bust → 점수 비교 → 동점 → Blackjack → else Win**. *내 점수 > 상대 점수 분기가 *Blackjack 분기 위*에 있어 *블랙잭 우선순위 사라짐**. *예: 내 카드 2장 21 (블랙잭) + 상대 카드 3장 20 → matchGameResult = WIN (Blackjack 분기 도달 X)*. *블랙잭 룰 = 1.5배 보너스 사라짐*. **룰 정확성 오류**.
+
+페로로 (GameResult.kt:7 — 미해결): *"수익금에 관한 배율은, 단순히 자신의 결과로 결정이 되지 않습니다. 가령, 플레이어가 블랙잭일때 상대의 상태에 따라 이길수도있고 비길수도있고 블랙잭일수도있습니다. 즉, 게임의 결과 != 배율이라고 정의할 수 없다는 의미라고 생각됩니다."*
+
+학생 자가 답변: *"자신이 블랙잭임에도 상대 또한 블랙잭일 경우는 결국 무승부라고 생각하여 이 경우에는 무승부라는 GameResult를 가지도록 하였습니다!"*
+
+→ **학생 자가 답변 = *블랙잭 vs 블랙잭 → DRAW* 정확**. 다만 *블랙잭 분기 자체가 점수 비교 후*에 있어 *대부분의 블랙잭 케이스가 WIN 흡수*. **분기 순서 + GameResult 가 배율 == 결과 = 룰 부정확**.
+
+페로로 후속 (GameResult.kt:7 추가 진단): *"수익금에 대한 배율은 단순히 결과로 계산되지 않고, 비교하는 상대방의 카드 상태를 이용해 같이 계산이 됩니다."* PR #49 (써니 2단계) 와 같은 결 — *수익률 = 결과 + 상대 상태 결합*.
+
+### 5. `GameResult.BLACKJACK(0.5f)` — *룰 misleading + 배율 표현 부정확*
+
+```kotlin
+enum class GameResult(val ratio: Float) {
+    WIN(1.0f),
+    BLACKJACK(0.5f),
+    DRAW(0.0f),
+    LOSE(-1.0f),
+}
+```
+
+→ **`BLACKJACK.ratio = 0.5f` = *보너스 비율*** (전체 = WIN 1.0 + BLACKJACK 0.5 = 1.5). 다만 *호출자가 BLACKJACK 만 받으면 *0.5 배율* 이해 어려움*. *PR #132·#108·#136·#90 의 BLACKJACK_PROFIT = 1.5f* (전체 배율) 와 *반대 트레이드오프*.
+
+**BLACKJACK 결과는 *WIN 의 변형* — 단독 적용 시 의미 부정확**. *호출자가 BLACKJACK → WIN ratio + BLACKJACK ratio 두 단계 합산* 강제. *PR #132·#108·#136 의 1.5 직접 표현* 이 *호출자 친화*.
+
+### 6. `Participant.bettingAmount` 외부 노출 — *@JvmField 사용 흔적 + 자가 학습*
+
+학생 자가 답변 (Participant.kt — 미해결): *"해당 어노테이션이 없을 때 아래의 오류가 발생하여 추가하였습니다. `fun <set-bettingAmount>(<set-?>: BettingAmount): Unit defined in blackjack.domain.player.Participant; fun setBettingAmount(newBettingAmount: BettingAmount): Unit defined in blackjack.domain.player.Participant`. 하지만 이전에 코틀린 프로퍼티에 대해 알아보았고, 코틀린에서는 기본 접근자를 메서드로 만들면 안된다는 것을 알았습니다. 따라서 다시 코드를 봤을때 기본 접근자를 사용하는 것이 문제라는 것을 알았고, 기본 접근자를 만들지 않고 변수의 값을 수정하도록 하였습니다!"*
+
+→ **`@JvmField` 어노테이션 사용 흔적 = Kotlin property accessor 우회**. *Java interop 의도* 가능성 + *Kotlin 어휘 미숙 신호*. 학생 자가 학습 + 후속 반영 = *생성자 val + 읽기 전용*. **Kotlin property accessor 어휘 학습 모범**.
+
+### 7. `Card.from(number, shape).find` 매번 순회 — *52장 lookup 비용*
+
+```kotlin
+data class Card private constructor(...) {
+    companion object {
+        private val CARDS: List<Card> = createCards()
+
+        fun from(cardNumber: CardNumber, cardShape: CardShape): Card {
+            return CARDS.find { cardNumber == it.number && cardShape == it.shape } ?: throw IllegalArgumentException()
+        }
+        ...
+    }
+}
+```
+
+페로로 (Card.kt:12 — 미해결): *"재사용의 이점을 가져갔지만, 생성을 할때마다 불필요한 순회가 많이 발생합니다. 만약 카드 52번째의 카드를 계속해서 요청한다면 매번 52번의 코드가 반복됩니다. 적절한 자료구조를 이용해서 해결해보세요"*
+
+→ **`List.find` = O(N)**. *Map<(rank, shape), Card>* = *O(1)*. *Kotlin Pair 키 또는 nested map*. 미세 성능. *학습 가치*. PR #108·#133 의 *findLast naming 부조화* 와 같은 결.
+
+### 8. `data class private constructor` — *data class 의 copy + private 충돌*
+
+```kotlin
+data class Card private constructor(...)
+```
+
+페로로 (Card.kt:3 — 미해결): *"data class를 사용하면 private 생성자를 이용하는 장점이 가려집니다. 관련해서 검색을 해보시면 재미있는 내용이 많이 있습니다"*
+
+→ **data class 의 `copy()` 가 자동 생성 + private constructor 우회**. *`card.copy(number = ACE)` 호출 시 private constructor 호출* — *외부에서 임의 Card 생성 가능성*. **data class + private constructor = 모순**. *Kotlin 어휘 함정*.
+
+해결: *`copy` 명시적 override + private* 또는 *non-data class*. PR #136·#133 의 *non-data class + factory* 와 같은 결.
+
+### 9. `Cards.MAX_SUM_NUMBER` 위치 모순 — *플레이어 점수 상수가 Player.companion*
+
+페로로 (Cards.kt:26 — 미해결): *"21점이라는 상수값이 플레이어에 정의되어 MAX_SUM_NUMBER라는 의미를 가지는게 맞을까요?"*
+
+```kotlin
+// Player
+companion object {
+    const val CARD_SETTING_COUNT = 2
+    const val MAX_SUM_NUMBER = 21
+}
+
+// Cards
+fun isBlackjack() =
+    (_cards.size == Player.CARD_SETTING_COUNT) && (sum() == MAX_SUM_NUMBER)
+```
+
+→ **`MAX_SUM_NUMBER = 21` 이 Player companion**. *Cards 가 자기 점수 룰 (21 초과 = Bust)* 알아야 함 → *Cards.MAX_SUM_NUMBER* 가 자연. *현재 Cards 가 Player.MAX_SUM_NUMBER 의존* = *Player → Cards 단방향이어야 하는데 Cards → Player 역의존*. PR #131·#136 와 같은 결의 *Score 룰 위치*.
+
+### 10. `Cards.containsCardNumber(CardNumber.ONE)` — *Ace = ONE 표현*
+
+```kotlin
+if (containsCardNumber(CardNumber.ONE) && sum + ACE_BONUS <= MAX_SUM_NUMBER) return sum + ACE_BONUS
+```
+
+→ **`CardNumber.ONE` = *Ace 표현***. *블랙잭 도메인에서 Ace 의 가치 = 1 또는 11*. *CardNumber.ONE = Ace ratio 1* 의미라면 *naming = ACE / CardNumber.ACE* 가 정공. *현재 ONE = 1 점수 + Ace 의미* 가 *어휘 부정확*. PR #128·#131·#136·#90 의 *Rank.ACE / CardNumber.ACE* 와 *반대 트레이드오프*.
+
+### 11. `Player.setFirstTurnCards(multiDeck)` — *플레이어가 deck 의존*
+
+```kotlin
+fun setFirstTurnCards(multiDeck: MultiDeck) =
+    repeat(CARD_SETTING_COUNT) { cards.add(multiDeck.draw()) }
+```
+
+페로로 (Dealer.kt — 미해결): *"`participants.getPayout(this)` 기능을 만들어도 되지 않을까요?"* (관련 토론)
+
+페로로 (Player.kt 직접 진단 — 미해결): *"이 기능은 Cards가 하도록 만들어주세요"*
+
+→ **`setFirstTurnCards` 가 Player 메서드 + deck 의존**. *Cards 가 자기 카드 채움*이 *Cards 자기 책임*. *Player → Cards 메시지* 위임. PR #133·#108 (시아) 의 *Participant.draw(card)* 와 *반대 트레이드오프* (시아는 카드 한 장 인자).
+
+### 12. `Dealer.getPayout(participants, results)` — *복잡한 인자 + Tell-Don't-Ask 미달*
+
+```kotlin
+fun getPayout(participants: Participants, participantsResults: List<MatchResult>): Int {
+    var sum = 0
+    participants.values.forEachIndexed { index, it ->
+        sum += it.bettingAmount.getPayout(participantsResults[index].getUniqueCountResult())
+    }
+    return sum * (-1)
+}
+```
+
+페로로 (BlackjackGame.kt — 미해결): *"마찬가지로 participants.values를 꺼내서 사용하지 않고 participants가 스스로 하도록 만들어주세요. 다른 코드도 모두 동일한 의견입니다"*
+
+→ **`participants.values.forEachIndexed` = *participants 정보 빼서 외부 순회***. *Participants.getDealerPayout(): Int* 메시지가 *Participants 자기 책임*. *현재 Dealer 가 participants + results 두 인자 + 인덱스 매칭* = *복잡도 ↑ + Demeter 위반*.
+
+또한 *`participantsResults[index]`* 가 *List + index 의존* — *Map<Participant, MatchResult>* 가 *id 안전*.
+
+### 13. `Player` 가 *MatchResult 보유* — *카드 변경 시 데이터 오염 가능성*
+
+페로로 (Player.kt — 미해결): *"같은 의견을 반복해서 드리는 것 같습니다. 위 함수에서 MatchResult를 반환하지 않고, 참가자가 계속해서 가지고 있는 상태로 만든 이유는 무엇인가요? 카드를 3장 가지고있는상태로 결과를 만들고 또다시 카드를 받으면 이전 결과는 데이터가 현재와 일치하지 않는 데이터 오염이 되지는 않을까요?"*
+
+→ **Participant 가 *결과 + 카드 둘 다 보유* = 데이터 일관성 위반**. *결과 = 시점 의존*. *Participant 가 결과 보유 → 카드 변경 → 결과 outdated*. *결과 반환 + Result 객체*가 *불변 시점 표현*. PR #49 (써니) 의 *Result(participant, profit)* 와 같은 결. *PR #85 (하디) 의 `by lazy`* 도 같은 결의 *시점 고정*.
+
+### 14. `Cards.toMutableList()` 생성자 인자 → *MutableList 변환*
+
+```kotlin
+class Cards(cards: List<Card> = listOf()) {
+    constructor(vararg cards: Pair<CardNumber, CardShape>) : this(cards.map { Card.from(it.first, it.second) }.toList())
+
+    private val _cards = cards.toMutableList()
+    ...
+}
+```
+
+→ **`List` 인자 + 내부 MutableList 사본**. 정공. PR #90·#132·#108 와 같은 결.
+
+페로로 진단 (Cards.kt — 미해결, 미사용 함수): *"이 코드는 외부에서 사용되지 않습니다. 테스트 코드에서만 사용되는 코드는 사용한다고 말하지 않습니다. 🙏🏻 이 기능을 테스트하기 위해서 다른 방법을 사용하는 순서로 이어져야 합니다."*
+
+→ **테스트 전용 코드 지양**. PR #53·#41·#88 와 같은 결.
+
+### 15. `BlackjackGame` 가 *Controller 이름만 변경* — 페로로 진단
+
+페로로 (BlackjackController.kt — 미해결): *"아래 내용은 참고만 해주세요. 변경은 하지 않으셔도 됩니다. 블랙잭 게임 도메인 모델을 만들어 게임의 로직을 만들어 보신 시도가 좋았습니다. 다만, 지금 구조로 보면 단순히 컨트롤러의 이름이 BlackGame으로 바뀐 것 정도로만 느껴집니다. 예를 들어 블랙잭 게임을 한다면 \"게임 시작\", \"게임 결과\" 라는 두가지 관점의 개념이 있습니다. 하지만 구현한 블랙잭 게임에서는 아래 모든 코드를 호출해야 한다는 것을 외부에서 반드시 알아야만 합니다. `blackjackGame.bettingParticipants(); blackjackGame.setFirstTurnPlayersCards(); blackjackGame.hitPlayersCards();` 블랙잭 게임을 제어하는 하나의 도메인이라면 이런 구조를 생각해볼 수 있겠습니다 `class BlackjackGame(...) { fun start(): BlackjackGameResult { ... } }`"*
+
+→ **`BlackjackGame.start(): BlackjackGameResult` 한 메서드** — *외부 진입점 단일화*. *호출자가 모든 진행 단계 알 필요 X*. PR #131·#132·#136·#152 와 같은 결의 *Game 단일 진입점*.
+
+### 16. `BlackjackGame.read/print UI 이름 포함` — 도메인-뷰 결합
+
+페로로 (BlackjackGame.kt — 미해결): *"도메인 모델에서는 read, print와 같은 UI와 관련된 이름이 포함되면 안됩니다. 파라미터, 함수이름 모두 동일합니다"*
+
+→ **도메인 메서드명 = UI 어휘 X**. *`readXX` / `printXX`* 는 *View 책임*. *도메인 = 비즈니스 로직 메시지*. PR #132·#90·#88·#41 와 같은 결.
+
+### 17. `MatchResult.countBy: MutableMap` 외부 노출 (`getResults()`) — *외부 가변 변경 가능성*
+
+```kotlin
+fun getResults(): Map<GameResult, Int> = this.countBy.toMap()
+```
+
+→ **`toMap()` 사본 반환** — *외부 변경 차단*. 정공. *방어적 복사*.
+
+다만 `countBy: MutableMap` 내부 보유 + *count 메서드가 putIfAbsent + plus 패턴* 이 *Kotlin 어휘 = `countBy.merge(result, 1, Int::plus)`* 한 줄 가능. *imperative + var* 가 *Kotlin 어휘 미숙*. PR #49 (써니) 의 *var profit + forEach* 와 같은 결.
+
+### 18. `MatchResult` 의 *주석 처리된 동일 클래스 정의* — *Dead code*
+
+```kotlin
+class MatchResult { ... }
+
+// class MatchResult {
+//    private val countBy: MutableMap<GameResult, Int> = ...
+//    fun count(gameResult: GameResult) { ... }
+//    ...
+// }
+```
+
+→ **동일 클래스 주석 처리** — *Dead code*. *git history 가 변경 추적*. *주석으로 코드 보존*은 *코드베이스 오염*. *Kotlin 어휘 = 즉시 삭제*. PR #88 (채드) 의 *부 생성자 미사용 자가 삭제* 와 같은 결의 *YAGNI*.
+
+## 리뷰어 의견 요지
+
+- **블랙잭 도메인 룰 정확성 = 결과 + 상대 상태** — *블랙잭 vs 블랙잭 = DRAW*, *블랙잭 vs Bust = WIN*. *분기 순서 + 우선순위*.
+- **Participant 가 *결과 보유 = 데이터 오염 가능성*** — *결과 = 시점 의존*. *카드 변경 시 outdated*. *불변 Result 객체*.
+- **`getResult()` naming 모호 = 호출자가 의미 모름** — *`getCountBy(GameResult)` 같은 명시적 메시지*.
+- **`reverseGameResult` 오타 + 사용 의도 모호** — *예외 던질 필요 없음*.
+- **data class + private constructor = copy 우회** — *Kotlin 어휘 함정*.
+- **6덱 = 카지노 메타포 + 요구사항 동떨어짐** — *학습 가치 vs 룰 일치 트레이드오프*.
+- **`Card.find` 매번 순회 = O(N), Map = O(1)** — *적절한 자료구조*.
+- **`MAX_SUM_NUMBER = 21` Player 위치 모순** — *Cards 자기 룰*.
+- **`BlackjackGame` 이 Controller 이름만 변경 = 외부 단계 노출 자기 책임 부재** — *`start(): BlackjackGameResult` 단일 진입점*.
+- **도메인 메서드명 UI 어휘 (`readXX`/`printXX`) X** — *비즈니스 로직 어휘*.
+- **테스트 전용 코드 지양** — *생산 코드 오염 회피*.
+
+## 대표 인용
+
+**페로로 (배율 = 결과 + 상대 상태 결합, GameResult.kt:7):**
+> 수익금에 관한 배율은, 단순히 자신의 결과로 결정이 되지 않습니다.
+> 가령, 플레이어가 블랙잭일때
+> 상대의 상태에 따라 이길수도있고 비길수도있고 블랙잭일수도있습니다.
+>
+> 즉, 게임의 결과 != 배율이라고 정의할 수 없다는 의미라고 생각됩니다.
+
+**페로로 (Participant 결과 보유 = 데이터 오염, Player.kt):**
+> 같은 의견을 반복해서 드리는 것 같습니다.
+> 위 함수에서 MatchResult를 반환하지 않고, 참가자가 계속해서 가지고 있는 상태로 만든 이유는 무엇인가요?
+>
+> 카드를 3장 가지고있는상태로 결과를 만들고
+> 또다시 카드를 받으면 이전 결과는 데이터가 현재와 일치하지 않는 데이터 오염이 되지는 않을까요?
+
+**페로로 (BlackjackGame = Controller 이름만 변경, BlackjackController.kt):**
+> 다만, 지금 구조로 보면 단순히 컨트롤러의 이름이 BlackGame으로 바뀐 것 정도로만 느껴집니다.
+>
+> 예를 들어 블랙잭 게임을 한다면 "게임 시작", "게임 결과" 라는 두가지 관점의 개념이 있습니다.
+> 하지만 구현한 블랙잭 게임에서는 아래 모든 코드를 호출해야 한다는 것을 외부에서 반드시 알아야만 합니다.
+> ```kotlin
+> blackjackGame.bettingParticipants()
+> blackjackGame.setFirstTurnPlayersCards()
+> blackjackGame.hitPlayersCards()
+> ...
+> ```
+>
+> 블랙잭 게임을 제어하는 하나의 도메인이라면 이런 구조를 생각해볼 수 있겠습니다
+> ```kotlin
+> class BlackjackGame(...) {
+>    fun start(): BlackjackGameResult { ... }
+> }
+> ```
+
+**페로로 (6덱 요구사항 동떨어짐, MultiDeck.kt:22):**
+> 6개의 덱을 준비시키는 이유는 무엇인가요?
+> 요구사항과 많이 동떨어진 느낌이라 이유가 궁금합니다
+
+**페로로 (data class + private constructor, Card.kt:3):**
+> data class를 사용하면 private 생성자를 이용하는 장점이 가려집니다.
+> 관련해서 검색을 해보시면 재미있는 내용이 많이 있습니다
+
+**페로로 (도메인 = UI 어휘 X, BlackjackGame.kt):**
+> 도메인 모델에서는 read, print와 같은 UI와 관련된 이름이 포함되면 안됩니다.
+> 파라미터, 함수이름 모두 동일합니다
+
+**페로로 (자료구조, Card.kt:12):**
+> 재사용의 이점을 가져갔지만, 생성을 할때마다 불필요한 순회가 많이 발생합니다.
+> 만약 카드 52번째의 카드를 계속해서 요청한다면 매번 52번의 코드가 반복됩니다.
+>
+> 적절한 자료구조를 이용해서 해결해보세요
+
+**학생 자가 답변 (카지노 6덱 메타포, MultiDeck.kt:22):**
+> 앗... 이 부분은 카지노에서의 블랙잭 게임 규칙을 반영시켰습니다!
+> 블랙잭 게임을 할 때에는 카드 카운팅을 어렵게 하기 위해 여러개의 덱을 사용하는 멀티덱 방식을 사용하는데,
+> 그 중에서도 6개의 덱을 사용하는 것이 일반적이라고 하여 그 부분을 적용시켜보았습니다..!
+
+**학생 자가 학습 (Kotlin property 어휘 + 캡슐화, Participant.kt):**
+> 이전에 코틀린 프로퍼티에 대해 알아보았고, 코틀린에서는 기본 접근자를 메서드로 만들면 안된다는 것을 알았습니다.
+> 따라서 다시 코드를 봤을때 기본 접근자를 사용하는 것이 문제라는 것을 알았고, 기본 접근자를 만들지 않고 변수의 값을 수정하도록 하였습니다!
+>
+> 또한, 이렇게 바꾸고 생각해보니 외부에서 자유자재로 변경이 가능한 상태이기에 값에 문제가 생길 수 있을 것이라 생각했습니다.
+> 따라서 언제든지 외부에서 변경이 가능한 값이 아니라, 생성시 생성자로 받아 읽기전용 값으로 만들어 가지고있도록 변경하였습니다!
+
+## 얻은 교훈
+
+1. ***Participant 가 결과 보유 = 데이터 일관성 위반***. *결과 = 시점 의존*. *카드 변경 시 outdated*. *불변 Result 객체* 가 *시점 고정*. PR #49 (써니) 의 *Result(participant, profit)* / PR #85 (하디) 의 *PlayerResult.profit by lazy* 와 같은 결.
+
+2. ***`BlackjackGame.start(): BlackjackGameResult` 단일 진입점***. *외부 호출자가 모든 단계 알 필요 X*. *Game 자기 진행 + 결과 반환*. PR #131·#132·#136·#152·#41·#53 와 같은 결의 *god-object 해결 정공*.
+
+3. ***도메인 메서드명 UI 어휘 X***. *`readXX` / `printXX` = View 책임*. *도메인 = 비즈니스 로직 어휘*. PR #132·#90·#88·#41 와 같은 결.
+
+4. ***data class + private constructor = copy 우회 = Kotlin 어휘 함정***. *외부에서 `card.copy(...)` 호출 시 private 생성자 우회*. *non-data class + factory* 또는 *copy override + private* 정공. PR #136·#133 와 같은 결의 *Card private constructor + named factory*.
+
+5. ***6덱 = 카지노 메타포 + 요구사항 동떨어짐 트레이드오프***. *현실 메타포 = 학습 가치 ↑*. *우아한테크코스 룰 = 1덱 가정*. *학습 vs 일치* 트레이드오프. PR #108·#133 (시아) 와 같은 결.
+
+6. ***`Card.find` O(N) → `Map<(rank, shape), Card>` O(1)***. *52장 lookup 반복 시 N^2 비용*. *적절한 자료구조 = Hash Map*. PR #108·#133 와 같은 결의 *findLast naming + 자료구조*.
+
+7. ***`MAX_SUM_NUMBER = 21` Player 위치 모순 = 룰 위치 분산***. *Cards 가 자기 점수 룰 알아야 함*. *Cards → Player 역의존* 함정. PR #131·#136 와 같은 결.
+
+8. ***분기 순서 = 룰 우선순위***. *Bust → 블랙잭 → 점수 비교* 순서. *현재 점수 비교 후 블랙잭 분기 = 우선순위 사라짐*. *블랙잭 룰 = 1.5배 보너스 미적용*. PR #128·#125·#114·#108·#133·#132·#136 와 같은 결.
+
+9. ***`MatchResult.reverseGameResult()` 오타 + Win/Lose swap + 사용 의도 모호***. *Dealer 입장 결과 = Player 결과 mirror* 의도. *명시적 메서드명 = `asDealerResult()` / `mirrorAsDealer()`* 가 정공. *현재 reverse 는 모호 + 오타*.
+
+10. ***`@JvmField` = Kotlin property accessor 우회 = Java interop 신호***. *순수 Kotlin 프로젝트에선 불필요*. *학생 자가 학습 + 후속 반영 = Kotlin 어휘 정공*. *Kotlin 기본 접근자 = property*. PR #133·#108·#132 와 같은 결의 *Kotlin property 어휘*.
+
+11. ***`CardNumber.ONE = Ace 표현` = 어휘 부정확***. *Ace = 점수 1 또는 11 도메인 의미*. *CardNumber.ACE* 가 *블랙잭 도메인 어휘 정공*. PR #128·#131·#136·#90 의 *Rank.ACE / CardNumber.ACE* 와 *반대 트레이드오프*.
+
+12. ***주석 처리된 코드 = Dead code***. *git history 가 변경 추적*. *주석 보존 = 코드베이스 오염*. *YAGNI*. PR #88·#41 와 같은 결.
+
+13. ***학습 테스트 (`src/test/kotlin/study/...`) = 학습 가시화 모범***. *production code 외 학습 코드 분리*. *State 패턴 학습 + 도전 시도*. *학습 테스트 분리 + 페로로 칭찬 모범*.
+
+14. ***`BLACKJACK ratio = 0.5f` (보너스 비율) vs `1.5f` (전체 배율) 트레이드오프***. *otter66 = 보너스 비율 (WIN 1.0 + BLACKJACK 0.5 = 1.5)*. *PR #132·#108·#136·#90 = 전체 배율 1.5*. *호출자 친화 = 전체 배율 직접 표현*.
+
+15. ***`Players.values.forEachIndexed + 인덱스 매칭` = Demeter + 복잡도***. *Participants.getDealerPayout(): Int* 메시지가 *Participants 자기 책임*. *Map<Participant, MatchResult>* 가 *id 안전*. PR #132·#108·#133 와 같은 결.
+
+16. ***학생 자가 학습 + 자가 답변 풍부 = 학습 가시화 모범***. *Kotlin property 어휘 + 캡슐화 자가 학습 + 카지노 메타포 명시 + 후속 반영 흐름*. *학생이 자기 의도 명시 + 페로로 진단 흡수* 패턴. PR #128·#135·#108·#133·#136·#41 와 같은 결.