oh-my-oop 0.2.0

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

@@ -0,0 +1,613 @@
+# PR #21 — [블랙잭 1단계] 둘리 미션
+
+- **Reviewee:** [@hyemdooly](https://github.com/hyemdooly)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/21
+- **단계:** 1단계
+- **리뷰어:** [@galcyurio](https://github.com/galcyurio) — 기존 reviewer (batch 17 신규 합류, PR #22·#86 등 동일 reviewer)
+- **라인 코멘트:** 15 스레드 — *Model → UI 로직 분리 (3회 반복: Card/Cards/Suit) + 테스트 가독성 외부글 (testing.googleblog) + 일급 컬렉션 위임 X + toList/toSet 방어적 복사 + Regex Pattern 비용 + CardPicker 책임 위치 (Player vs 가상 객체)*
+- **신규 reviewee** (2023년 3월 코호트).
+
+## 잘한 점 (설계 관점)
+
+### 1. `data class Card(val rank: Rank, val suit: Suit)` — value object 간결
+
+```kotlin
+package model
+data class Card(val rank: Rank, val suit: Suit)
+```
+
+→ **`Card` data class 간결**. *equality 자동 + 불변*. PR #74·#108·#133·#46·#39·#82·#107·#18·#36 결.
+
+### 2. `Cards` 중복 카드 invariant — init + add 양쪽 검증
+
+```kotlin
+class Cards(cards: List<Card>) {
+    private val _cards = cards.toMutableList()
+    val cards: List<Card>
+        get() = _cards.toList()
+    ...
+    init {
+        require(cards.distinct().size == cards.size) { CARD_DUPLICATE_ERROR }
+    }
+
+    fun add(card: Card) {
+        require(!_cards.contains(card)) { CARD_DUPLICATE_ERROR }
+        _cards.add(card)
+    }
+    ...
+}
+```
+
+→ **카드 중복 invariant 강제** — *init 시점 distinct 체크 + add 시점 contains 체크* 양쪽 모두. **backing property + 방어적 복사 패턴** (PR #18 결 + PR #46·#36 결).
+
+다만 **doubly-enforced invariant 중복 비용**:
+- init 시점 distinct = O(n)
+- 매 add 시점 contains = O(n)
+
+→ *MutableSet 자료구조 대안* (PR #23·#26 결).
+
+### 3. `abstract class Participant` + Dealer/Player 상속 — 다형성 hit 판정
+
+```kotlin
+abstract class Participant(val cards: Cards, val name: Name) {
+    abstract fun isHit(): Boolean
+    fun isBust(): Boolean { if (cards.sum() > BUST_POINT) return true; return false }
+    fun pick(cardPack: Cards) { cards.add(cardPack.pop()) }
+}
+
+class Dealer(...) : Participant(cards, name) {
+    override fun isHit(): Boolean = cards.sum() < HIT_STANDARD_POINT
+}
+
+class Player(...) : Participant(cards, name) {
+    override fun isHit(): Boolean = !isBust()
+}
+```
+
+→ **`isHit()` 다형성 자가 적용** — *Dealer = 16 이하 hit, Player = bust 아니면 hit*. **Tell-Don't-Ask 적용**. PR #16·#98·#91·#43·#73·#80·#87 결.
+
+reviewer 후속 칭찬 (Thread 14): *"더욱 코드가 객체지향적이 되었네요 👍"*.
+
+### 4. `Rank.getScore(score: Int = 0)` Ace 1↔11 양가성
+
+```kotlin
+enum class Rank(private val score: Int) {
+    ACE(1), DEUCE(2), ..., JACK(10);
+
+    fun getScore(score: Int = 0): Int {
+        when (this) {
+            ACE -> {
+                if (score + ACE_SCORE_ELEVEN > WIN_SCORE) return ACE_SCORE_ONE
+                return ACE_SCORE_ELEVEN
+            }
+            else -> return this.score
+        }
+    }
+}
+```
+
+→ **Ace 1 기본 + 11 변환 boundary** + **현재 합계 인자로 Ace 조정** = *Cards.sum 호출자가 sum 누적 + Ace 분리 계산*. PR #36 결의 *Ace 1 기본 + 단일 +10 룰* 변형. *합산이 호출자 책임* = *Ace 분리 자가 처리*.
+
+### 5. `data class Players` + `data class Participants` — 일급 컬렉션 (다만 위임 ↓)
+
+```kotlin
+data class Players(private val players: List<Player>) {
+    fun toList(): List<Player> = players.toList()
+}
+```
+
+→ **일급 컬렉션 + 방어적 복사 toList()** — *list 직접 노출 X*. PR #18·#36·#74·#107 결.
+
+다만 **현재는 toList 만 노출** → reviewer 후속 코멘트 (Thread 10): *"외부에 데이터를 전달하기보다 메시지를 받아 내부에서 처리한 후 결과 반환"*.
+
+### 6. PR 본문 = 간단 (자가 의문 없음)
+
+PR 본문: *"안녕하세요, 리뷰어님!! 많이 배우겠습니다. 피드백 부탁드립니다! :)"*
+
+→ **자가 의문 없는 PR 본문** — *학생이 점검 요청만*. PR #11·#13·#22·#33 결의 *간단 PR 본문* 패턴.
+
+## 못한 점 (설계 관점)
+
+### 1. 한 줄에서 너무 많은 처리 — CardPackGenerator
+
+reviewer (Thread 1):
+
+> *"한 줄에서 너무 많은 처리를 하고 있습니다. 함수 또는 변수로 분리해보세요."*
+
+학생 코드:
+
+```kotlin
+private fun createCards() = buildList {
+    Rank.values().forEach { rank -> addAll(createCardsBySuit(rank)) }
+}
+private fun createCardsBySuit(rank: Rank) = Suit.values().map { suit -> Card(rank, suit) }
+```
+
+→ **`buildList { forEach { addAll(map { ... }) } }` 중첩 4 단계** = *읽기 어려움*. 
+
+#### 1.1. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 4 단계 중첩 (현재) | *간결 + buildList 활용* | *읽기 어려움 + 디버깅 어려움* |
+| Top-level 분리 (rank.forEach { suit.forEach { add }}) | *2 단계 + 명시적 forEach* | *함수 추출 필요* |
+| flatMap 활용 (rank.flatMap { suit.map { Card(rank, suit) } }) | *함수형 + 1 단계* | *flatMap 어휘 익숙도 필요* |
+
+대안 (flatMap):
+
+```kotlin
+private fun createCards(): List<Card> = 
+    Rank.values().flatMap { rank -> Suit.values().map { suit -> Card(rank, suit) } }
+```
+
+**MCP 룰 `nested-builder-readability` 후보** — *buildList/forEach/map 중첩 4단계 = 읽기 어려움*.
+
+### 2. `CardPicker` 별도 클래스 vs `Cards`/`Card`/`Player` 책임
+
+reviewer (Thread 2):
+
+> *"이 기능은 별도 클래스로 분리되기보다는 Cards, Card, Player와 같은 클래스에 구현되어야 하는 로직으로 보입니다. 별도의 CardPicker라는게 가상의 무언가가 존재하기보다는 카드를 pick하는 책임은 플레이어에게 있는게 조금 더 자연스럽게 느껴져요."*
+
+→ **CardPicker = 가상 객체 안티패턴** — *pick 책임은 *실재 도메인 객체 (Player/Cards) 에 있음***.
+
+#### 2.1. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `CardPicker` 별도 클래스 (학생 초안) | *책임 명시 + 단일 책임* | *가상 객체 + 도메인 메타포 X* |
+| `Player.pick(cardPack: Cards)` (현재) | *Tell-Don't-Ask + 도메인 메타포 자연* | *Player 가 cardPack 직접 호출 = 매개체 누수* |
+| `Cards.deal(player: Player)` | *카드덱이 분배 책임* | *Cards ↔ Player 양방향 결합* |
+
+학생은 **`Participant.pick(cardPack: Cards)` 채택** (반영 완료).
+
+**MCP 룰 `virtual-object-vs-real-domain` 강화** — *Picker/Manager 같은 가상 객체 = 도메인 메타포 X*. 누적 6+ PR (#80·#145·#100·#76·#39·#31·#21). ⭐⭐⭐.
+
+PR #31 (no1msh *발급기 그 자체에게는 돈이 필요하지 않다*) 결의 *현실 메타포 정합* 어휘 일치.
+
+### 3. Model 안에 UI 로직 — `Card`/`Cards`/`Suit` 3회 반복
+
+reviewer (Thread 3, 4, 5 — 동일 메시지 3회):
+
+> *"UI 로직입니다. UI layer에서 데이터를 받아서 그리도록 만들어보세요."*
+
+→ **Model → View 결합 안티패턴** — *Card/Cards/Suit 클래스에 *UI 텍스트 표현 메서드 (예: toKoreanString)** 가 있었음 → reviewer 가 *3 자리 모두 동일 권유*.
+
+학생 자가 적용 후속 (Thread 12):
+
+> *"View에서 UI를 그리도록 잘 변경해주셨네요 👍"*
+
+#### 3.1. *Model → View 의존 방향 = 절대 원칙*
+
+PR #87·#88·#80·#76·#93·#107·#137·#90 결.
+
+#### 3.2. *2 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Model 안 UI 메서드 (학생 초안) | *카드 자가 표현 메서드 보유 (`card.toKoreanString()`)* | *Model → View 결합 + UI 변경 시 Model 변경* |
+| View 가 Model 받아서 UI 처리 (현재) | *Model 순수 + UI 격리* | *View 가 Model 어휘 알아야 함 (Rank/Suit enum)* |
+| `SuitModel` UI layer 한정 객체 (reviewer 미래 권유) | *UI ↔ Domain 명시 분리* | *클래스 ↑ + 변환 로직 필요* |
+
+reviewer 미래 권유 (Thread 12 후속):
+
+> *"조금 더 고도화해본다면 ui layer에서만 사용하는 SuitModel을 만들고 해당 클래스에서 UI를 제공하도록 만드는 방법도 있습니다. 이 방식은 이번 미션에서는 적용하지 않아도 좋지만 추후 안드로이드에서 자주 쓰이는 방식이니 미리 인지해두시면 좋겠어요."*
+
+→ **안드로이드 어휘 (SuitModel) 미래 학습 권유** + **이번 미션 적용 X 명시** = *학생 부담 최소화*.
+
+**MCP 룰 `model-view-dependency-direction` 강화** — 누적 8+ PR ⭐⭐⭐.
+
+### 4. Regex Pattern 비용 — 재사용 권유
+
+reviewer (Thread 6):
+
+> *"Regex에서 내부적으로 사용하는 Pattern 인스턴스는 생성 비용이 높습니다. 재사용하는 방식으로 수정해보세요."*
+
+→ **Regex 인스턴스 매번 생성 vs 재사용** — *companion object 에 Regex 1개 보관 + 매 호출 시 재사용*.
+
+```kotlin
+// AS-IS (학생 초안)
+fun parse(input: String) = Regex("[a-zA-Z]+").matches(input)
+
+// TO-BE (재사용)
+companion object { private val NAME_PATTERN = Regex("[a-zA-Z]+") }
+fun parse(input: String) = NAME_PATTERN.matches(input)
+```
+
+**MCP 룰 `regex-pattern-reuse` 후보** — *Regex 인스턴스 매번 생성 = 비용*. *Kotlin 어휘 한정*.
+
+### 5. `@BeforeEach` 충분 vs 매 테스트 새 인스턴스
+
+reviewer (Thread 7):
+
+> *"`@BeforeEach`로도 충분해보여요."*
+
+reviewer 후속 (Thread 13):
+
+> *"참고로 junit4, junit5에서는 각 테스트 케이스를 수행하기 전에 테스트 클래스를 새로 만드는게 기본 설정이라 실제로는 `@BeforeEach`도 필요없습니다. 하지만 가독성과 추후에 필요해지는 경우도 생기므로 지금처럼 초기화 코드를 분리해주시는게 좋습니다. 만약 필요하다면 `@TestInstance(Lifecycle.PER_CLASS)`를 통해 한 번만 인스턴스가 만들어지도록 할 수도 있습니다."*
+
+→ **junit 기본 = 각 테스트 새 인스턴스 + @BeforeEach 가독성**:
+
+#### 5.1. *3 가지 라이프사이클*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| junit 기본 (PER_METHOD) | *완전 격리 + 안정* | *비용 ↑* |
+| @BeforeEach (현재) | *명시적 초기화 + 가독성* | *추가 어노테이션* |
+| @TestInstance(PER_CLASS) | *비용 ↓* | *공유 상태 위험* |
+
+**MCP 룰 `junit-test-lifecycle-tradeoff` 후보** — *junit 라이프사이클 선택 트레이드오프*.
+
+### 6. 테스트 본문 = 필요한 정보 + 외부글 (testing.googleblog)
+
+reviewer (Thread 8):
+
+> *"테스트 본문에는 테스트하고자 하는 것을 이해할 수 있는 정보를 모두 가지고 있어야 하고, 반대로 불필요한 내용을 전부 감추어야 합니다.*
+>
+> *- 참고: https://testing.googleblog.com/2014/03/testing-on-toilet-what-makes-good-test.html*
+>
+> *여기서 불필요한 정보는 무엇인지 필요한 정보는 무엇인지 찾아보고 불필요한 정보들을 테스트 본문 바깥으로 분리해보세요."*
+
+→ **테스트 본문 가독성 = 필요한 정보 + 불필요한 정보 분리** + **외부글 (Google Testing on the Toilet)**:
+
+#### 6.1. *외부글 활용*
+
+`testing.googleblog.com/2014/03/testing-on-toilet-what-makes-good-test.html` — **외부 자료 + 자가 학습** 어휘. PR #87·#36·#23·#26·#108·#136·#151·#146·#148·#93·#133 결.
+
+#### 6.2. *불필요한 정보 분리 = factory 함수*
+
+reviewer 후속 (Thread 11):
+
+> *"이 테스트 케이스에서 중요한 정보는 Rank입니다. 테스트 케이스를 처음 보는 사람이 테스트 본문만 보아도 합이 16이 넘거나 넘지 않았을 때, hit or stay 한다는 것을 알 수 있어야 합니다. 하지만 이미 함수 이름에서부터 hitDealer(), stayDealer()라고 확정되어있고 어떤 때에 hit 되는지는 테스트 본문을 떠나서 해당 함수를 들여다 보아야합니다. `dealer(rank1, rank2, ...)` 형태로 만들어보는건 어떨까요?"*
+
+→ **테스트 fixture factory 함수** — *`dealer(rank1, rank2)` 가 *테스트 본문 안에서 핵심 정보 (Rank) 노출***.
+
+대안:
+
+```kotlin
+// AS-IS
+@Test fun hitDealer() {
+    val dealer = Dealer(Cards(listOf(Card(Rank.TEN, Suit.HEART), Card(Rank.FIVE, Suit.HEART))))
+    assertTrue(dealer.isHit())
+}
+
+// TO-BE (factory)
+private fun dealer(vararg ranks: Rank): Dealer = 
+    Dealer(Cards(ranks.map { Card(it, Suit.HEART) }))
+
+@Test fun `합이 16 이하면 hit`() {
+    val dealer = dealer(Rank.TEN, Rank.FIVE)  // 핵심: 10 + 5 = 15
+    assertTrue(dealer.isHit())
+}
+```
+
+**MCP 룰 `test-fixture-essential-info` 강화** — *테스트 본문 = 필요한 정보만 + 외부 factory*. 누적 5+ PR (#99·#26·#21·#87·#93). ⭐⭐.
+
+### 7. 테스트 indent 깊이 — Participants 의 *이름 만들기*
+
+reviewer (Thread 9):
+
+> *"indent가 굉장히 깊습니다. 여기서는 해당 이름으로 제대로 만들어지는지가 중요한 테스트 케이스같은데 불필요한 정보들을 분리해보세요."*
+
+→ **테스트 indent 깊이 = §6 의 *불필요한 정보 누수* 표면**. 
+
+§6 의 *factory 함수* 권유와 같은 결.
+
+### 8. 일급 컬렉션 위임 X + toList/toSet 방어적 복사
+
+reviewer (Thread 10):
+
+> *"일급 컬렉션을 구현할 때는 외부에 데이터를 전달하기보다는 메시지를 받아서 내부에서 처리한 후 외부에 결과를 반환하는게 좋습니다. 하지만 컬렉션을 구현하고 위임하도록 처리해버리면 습관적으로 컬렉션을 쓰듯이 사용하게되어서 나쁜 습관이 만들어집니다. 이번 미션에서는 위임을 쓰지 않고 만들어보세요.*
+>
+> *하지만 외부에서 해당 데이터가 반드시 필요한 경우도 있는데 이런 경우에는 아래와 같은 함수를 통해 방어적 복사를 한 이후 드러내주세요.*
+>
+> ```kotlin
+> fun toList(): List<Foo> = values.toList()
+> fun toSet(): Set<Foo> = values.toSet()
+> ```"
+
+→ **일급 컬렉션 = Tell-Don't-Ask 정공**:
+
+#### 8.1. *3 가지 학습*
+
+#### 8.1.1. *위임 (delegation) 회피*
+
+학생 코드:
+
+```kotlin
+data class Players(private val players: List<Player>) {
+    fun toList(): List<Player> = players.toList()
+}
+```
+
+→ `Players(list).map { ... }` 처럼 *Players 가 List 메서드 위임* 시 *컬렉션처럼 쓰는 습관*. **나쁜 습관 형성**.
+
+#### 8.1.2. *메시지 받기 정공*
+
+`Players.findWinners(): List<Player>`, `Players.getDealerProfit(): Int` 처럼 *내부 로직 처리 메서드*.
+
+#### 8.1.3. *toList/toSet 방어적 복사*
+
+외부 노출 필요 시 *방어적 복사*. PR #36 (backing property + data class 융합) 결.
+
+**MCP 룰 `first-class-collection-delegation-pitfall` 강화** — *일급 컬렉션 + 위임 = 나쁜 습관*. 누적 4+ PR (#21·#74·#108·#46).
+
+### 9. `LinkedList` 자료구조 활용
+
+reviewer (Thread 15):
+
+> *"LinkedList와 같이 이미 잘 만들어져있는 자료구조를 활용해봐도 좋겠네요."*
+
+학생 코드 (`Cards.pop`):
+
+```kotlin
+fun pop(): Card {
+    require(_cards.isNotEmpty()) { OUT_OF_INDEX_CARDS_CURSOR }
+    val card = _cards[0]
+    _cards.removeAt(0)
+    return card
+}
+```
+
+→ **`MutableList.removeAt(0) = O(n)`** (ArrayList 의 경우). `LinkedList.removeFirst() = O(1)`. *카드덱 pop = LinkedList 자연*.
+
+대안:
+- `ArrayDeque<Card>.removeFirst()` — Kotlin 어휘.
+- `LinkedList<Card>().pollFirst()` — Java 어휘.
+- `MutableList<Card>().removeAt(_cards.size - 1)` — *카드덱 뒤에서 뽑기 = O(1)*.
+
+**MCP 룰 `data-structure-choice-deck` 후보** — *카드덱 자료구조 = LinkedList vs ArrayDeque vs MutableList rear-pop*. PR #58·#23·#26 결.
+
+### 10. Singleton Deck X — CardPackGenerator 인스턴스 + Cards 객체
+
+```kotlin
+class CardPackGenerator {
+    fun createCardPack(): Cards = Cards(createCards())
+    ...
+}
+```
+
+→ **CardPackGenerator 인스턴스 메서드 + Cards 객체 반환** = *Singleton Deck 안티패턴 회피* (PR #20·#28·#125·#65·#92·#108·#137·#106·#48·#9·#22·#13·#11·#39·#16·#46·#36 누적 결의 *반대 시점*).
+
+다만 **`CardPackGenerator` 가 별도 클래스 (책임 명확)** vs **`Cards.createPack()` companion 정적 팩토리 (단일 책임)** 트레이드오프.
+
+#### 10.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| CardPackGenerator 별도 클래스 (현재) | *생성 책임 명확 + Cards 객체와 분리* | *Generator = 가상 객체 (§2 결)* |
+| Cards.createPack() companion | *Cards 자가 생성 + 단일 책임* | *Cards companion object 비대* |
+
+reviewer 의 §2 (CardPicker = 가상 객체) 와 *같은 결*:
+
+- *CardPicker = Player.pick 으로 흡수*.
+- *CardPackGenerator 도 가상 객체 위험* — *다만 reviewer 명시 X = OK 시점*.
+
+**MCP 룰 `generator-vs-static-factory` 후보**.
+
+### 11. `Cards.add(card)` mutable 누수 vs immutable
+
+```kotlin
+fun add(card: Card) {
+    require(!_cards.contains(card)) { CARD_DUPLICATE_ERROR }
+    _cards.add(card)
+}
+```
+
+→ **`Cards.add` = mutable 메서드** → *Player.pick(cardPack: Cards) 가 *cardPack.pop() + this.cards.add()* 양쪽 모두 변경*.
+
+#### 11.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| mutable add (현재) | *카드 1장 추가 자연 + GC 비용 ↓* | *Cards 외부에서 변경 가능 = invariant 누수* |
+| immutable + (Card) -> Cards | *완전 immutable + 함수형* | *카드 1장마다 새 Cards 인스턴스 + List 복사* |
+
+PR #87 결의 *partial immutability* 변형. **MCP 룰 `mutable-collection-method-on-domain-class` 후보**.
+
+### 12. `Participant.pick(cardPack: Cards)` — 양방향 결합
+
+```kotlin
+abstract class Participant(val cards: Cards, val name: Name) {
+    fun pick(cardPack: Cards) {
+        cards.add(cardPack.pop())
+    }
+}
+```
+
+→ **`Participant.pick` 이 *cardPack.pop() + this.cards.add()* 양쪽 호출** = *Participant ↔ cardPack 양방향 결합 (cardPack 변경 + this 변경)*.
+
+대안: **`cardPack.dealTo(participant: Participant)`** — *cardPack 책임 명확*. 다만 *Participant ↔ Cards 결합 동일*.
+
+reviewer 명시 X — *책임 위치 토론 영역*.
+
+**MCP 룰 `bidirectional-mutation-via-method` 후보** — *메서드가 두 객체 모두 변경*.
+
+### 13. `Cards.sum()` 함수 — 합산 로직 일부 외부에 (Rank.getScore)
+
+```kotlin
+fun sum(): Int {
+    var sum = _cards.filter { it.rank != Rank.ACE }.sumOf { it.rank.getScore() }
+    sum += _cards.filter { it.rank == Rank.ACE }.sumOf { it.rank.getScore(sum) }
+    return sum
+}
+```
+
+→ **합산 로직이 Cards + Rank 양쪽에 분산** — *Cards 가 Ace 분리 + Rank.getScore(sum) 호출 → Rank 가 sum 받아 11/1 결정*.
+
+#### 13.1. *Tell-Don't-Ask 부분 위반*
+
+`Cards.sum()` 이 *합계 누적 + Ace 분기* 모두 처리. **Rank 가 sum 받음 = 외부 데이터 의존**.
+
+대안: **`Cards.sum()` 이 Ace 1↔11 전체 결정** vs **`Rank.calculateScore(currentSum)` 가 self 결정** — 양쪽 모두 *부분 위반*.
+
+PR #36 결 (`CardNumber.decideAdditionalAceScore`) 결.
+
+#### 13.2. *Rank.getScore(score: Int = 0)` 함수 시그니처 양가성*
+
+`getScore()` (인자 없음) = *기본 score 반환*.  
+`getScore(score)` (인자 있음) = *Ace 11 변환 결정*.
+
+→ **하나의 메서드 = 2 가지 역할** → *의미 누수*. 
+
+대안:
+- `Rank.baseScore: Int` (property) + `Rank.adjustForAce(currentSum: Int): Int` (Ace 한정).
+- `Rank.calculateScore(currentSum: Int = 0): Int` — 명명 정확.
+
+**MCP 룰 `function-multiple-roles-via-default-param` 후보** — *기본 인자 = 메서드 2 역할 양가*. PR #36 (decideAceValue 명명·반환 불일치) 결.
+
+### 14. `Cards.pop()` `Cards.removeAt(0)` — 자료구조 부적합
+
+§9 참조.
+
+### 15. `Players` 의 `toList()` 명명 = 일급 컬렉션 위임 의도 누수
+
+```kotlin
+data class Players(private val players: List<Player>) {
+    fun toList(): List<Player> = players.toList()
+}
+```
+
+→ **`toList()` 메서드만 노출 = 외부에서 컬렉션처럼 활용 의도** → **§8 의 *일급 컬렉션 위임 X* 권유 정공**.
+
+대안: *Players 가 도메인 메시지 추가* — `findWinnerNames(): List<Name>`, `getTotalProfit(dealer: Dealer): Int` 등.
+
+### 16. `Participants.of(dealer, players)` `listOf(dealer as Participant) + players.toList() as List<Participant>` — 캐스팅 누수
+
+```kotlin
+companion object {
+    fun of(dealer: Dealer, players: Players) = 
+        Participants(listOf(dealer as Participant) + players.toList() as List<Participant>)
+}
+```
+
+→ **`as Participant` 캐스팅 2회** = *Kotlin smart cast 의도 누수* + *List<Player> → List<Participant> 캐스팅 위험*.
+
+대안:
+```kotlin
+fun of(dealer: Dealer, players: Players): Participants = 
+    Participants(listOf<Participant>(dealer) + players.toList())
+```
+
+→ **타입 인자 명시 (`listOf<Participant>(dealer)`) + 자동 공변성**. *Kotlin List 가 *공변* → players.toList(): List<Player> 자동 List<out Participant> OK*.
+
+**MCP 룰 `unnecessary-cast-via-typed-listOf` 후보** — *불필요한 캐스팅 → 타입 인자 명시*.
+
+## 리뷰어 의견 요지
+
+- **Model → UI 로직 분리 (3 자리 동일 권유)** — Card/Cards/Suit. *MVC 절대 원칙*.
+- **CardPicker = 가상 객체 + Player 책임** — *책임 위치 *실재 도메인 객체에***.
+- **테스트 본문 = 필요한 정보 + 외부글 (testing.googleblog)** — *factory 함수 + 불필요한 정보 분리*.
+- **일급 컬렉션 + 위임 X + toList/toSet 방어적 복사** — *외부 데이터 X + 메시지 받기*.
+- **Regex Pattern 비용 + 재사용** — *Kotlin 어휘*.
+- **junit 라이프사이클 + @BeforeEach + PER_CLASS** — *추가 학습 안내*.
+- **LinkedList 자료구조 활용** — *카드덱 pop = O(1)*.
+- **SuitModel = UI layer 한정 객체 (미래 학습 안내)** — *안드로이드 어휘 + 이번 미션 적용 X*.
+- **한 줄에서 너무 많은 처리 (CardPackGenerator)** — *함수 또는 변수 분리*.
+- **`@BeforeEach` 충분** — *runIf 람다 활용 권유*.
+- **수정 후 칭찬** — *View 에서 UI 그리도록* + *객체지향적으로 개선*.
+
+## 대표 인용
+
+> [galcyurio]
+> *"별도의 CardPicker라는게 가상의 무언가가 존재하기보다는 카드를 pick하는 책임은 플레이어에게 있는게 조금 더 자연스럽게 느껴져요."*
+
+→ **가상 객체 vs 실재 도메인 객체 어휘**. PR #31 (no1msh *발급기 그 자체에게는 돈이 필요하지 않다*) 결의 *현실 메타포 정합* 어휘.
+
+> [galcyurio]
+> *"일급 컬렉션을 구현할 때는 외부에 데이터를 전달하기보다는 메시지를 받아서 내부에서 처리한 후 외부에 결과를 반환하는게 좋습니다. 하지만 컬렉션을 구현하고 위임하도록 처리해버리면 습관적으로 컬렉션을 쓰듯이 사용하게되어서 나쁜 습관이 만들어집니다."*
+
+→ **일급 컬렉션 + 위임 = 나쁜 습관** 어휘. *Tell-Don't-Ask 정공*.
+
+> [galcyurio]
+> *"테스트 본문에는 테스트하고자 하는 것을 이해할 수 있는 정보를 모두 가지고 있어야 하고, 반대로 불필요한 내용을 전부 감추어야 합니다."*
+
+→ **테스트 본문 가독성 = 필요/불필요 정보 분리** 어휘. 외부글 (testing.googleblog) 동반.
+
+> [galcyurio]
+> *"조금 더 고도화해본다면 ui layer에서만 사용하는 SuitModel을 만들고 해당 클래스에서 UI를 제공하도록 만드는 방법도 있습니다. 이 방식은 이번 미션에서는 적용하지 않아도 좋지만 추후 안드로이드에서 자주 쓰이는 방식이니 미리 인지해두시면 좋겠어요."*
+
+→ **미래 학습 안내 + 이번 미션 적용 X** = *학생 부담 최소화*. PR #87·#36·#95·#23·#26 결.
+
+> [galcyurio]
+> *"참고로 junit4, junit5에서는 각 테스트 케이스를 수행하기 전에 테스트 클래스를 새로 만드는게 기본 설정이라 실제로는 `@BeforeEach`도 필요없습니다. 하지만 가독성과 추후에 필요해지는 경우도 생기므로 지금처럼 초기화 코드를 분리해주시는게 좋습니다."*
+
+→ **junit 도구 어휘 + 가독성 우선** 권유. *학생의 현재 코드 OK + 추가 어휘 학습 안내*.
+
+## 얻은 교훈 (보편)
+
+1. **가상 객체 vs 실재 도메인 객체** — *CardPicker/Manager = 가상 객체 안티패턴 vs Player.pick 정공*. PR #31 (no1msh) 결의 *현실 메타포 정합*. **MCP 룰 `virtual-object-vs-real-domain` 강화** ⭐⭐⭐ (누적 6+ PR).
+
+2. **Model → View 의존성 금지 (MVC 절대 원칙)** — *Card/Cards/Suit UI 메서드 3 자리 동일 권유*. **MCP 룰 `model-view-dependency-direction` 강화** ⭐⭐⭐ (누적 8+ PR).
+
+3. **일급 컬렉션 + 위임 = 나쁜 습관** — *컬렉션처럼 쓰는 습관 형성 + Tell-Don't-Ask 위반*. **MCP 룰 `first-class-collection-delegation-pitfall` 강화** (누적 4+ PR).
+
+4. **테스트 본문 = 필요한 정보 + 외부 factory + 외부글 (testing.googleblog)** — *불필요한 정보 분리 + dealer(rank1, rank2) 형태*. **MCP 룰 `test-fixture-essential-info` 강화** ⭐⭐ (누적 5+ PR).
+
+5. **SuitModel = UI layer 한정 객체 (미래 학습)** — *Model ↔ UI Model 분리 + 안드로이드 어휘*. **MCP 룰 `ui-layer-model-separation` 후보** (미래 학습).
+
+6. **junit 라이프사이클 트레이드오프** — *PER_METHOD vs @BeforeEach vs PER_CLASS*. **MCP 룰 `junit-test-lifecycle-tradeoff` 후보**.
+
+7. **Regex Pattern 비용 + 재사용** — *Kotlin 어휘*. **MCP 룰 `regex-pattern-reuse` 후보**.
+
+8. **LinkedList vs ArrayDeque vs MutableList 자료구조** — *카드덱 pop = O(1) 필요*. **MCP 룰 `data-structure-choice-deck` 후보**.
+
+9. **한 줄에서 너무 많은 처리** — *buildList/forEach/map 4 단계 중첩 = 읽기 어려움*. *함수 또는 변수 분리 / flatMap 대안*. **MCP 룰 `nested-builder-readability` 후보**.
+
+10. **함수 시그니처 = 2 역할 (기본 인자 분기)** — *Rank.getScore() vs Rank.getScore(sum)*. **MCP 룰 `function-multiple-roles-via-default-param` 후보**.
+
+11. **불필요한 캐스팅 (`as`) → 타입 인자 명시** — *Kotlin smart cast + 공변성 활용*. **MCP 룰 `unnecessary-cast-via-typed-listOf` 후보**.
+
+12. **mutable 메서드 (Cards.add) = 양방향 결합 + invariant 누수** — *immutable vs mutable 트레이드오프*. PR #87 *partial immutability* 결.
+
+13. **간단 PR 본문 (자가 의문 없음)** vs **자가 의문 PR 본문** — PR #11·#13·#22·#33 결의 *간단 PR 본문* 패턴.
+
+## 얻은 교훈 (도메인)
+
+1. **Ace 1 기본 + sum 인자로 11 변환** — *Cards.sum 호출자가 Ace 분기*. PR #36 (CardNumber.decideAdditionalAceScore) 결.
+
+2. **Dealer hit ≤16** + **Player !isBust 일 때 hit** — 블랙잭 표준 룰.
+
+3. **카드 중복 invariant 양쪽 검증** — init distinct + add contains.
+
+4. **CardPackGenerator (별도 클래스) vs Cards.createPack() companion** — *Generator 별도 vs 정적 팩토리 트레이드오프*.
+
+5. **`Suit` enum DIAMOND/CLOVER/SPADE/HEART** — *UI 표현은 View*. *Model 안 enum 자체는 도메인 어휘*.
+
+6. **`Rank` enum ACE/DEUCE/.../JACK** + **score 인자 양가성 (기본 0 / Ace 분기)** — 도메인 어휘.
+
+7. **`Cards.pop()` `removeAt(0)`** — *카드덱 자료구조 부적합 (O(n))*. *LinkedList / ArrayDeque / 뒤에서 pop 대안*.
+
+8. **`Player.isHit() = !isBust()`** — *Player 의 hit 결정이 외부 (사용자 의지)* 가 아닌 *bust 여부 자가 결정* = *블랙잭 룰 와전*. *실제 블랙잭 = 사용자가 hit/stay 선택* → *isHit() = !isBust() 는 *자동 hit* 시점만 OK*.
+
+→ **MCP 룰 `auto-hit-vs-user-choice` 후보** — *Player.isHit() 의미 양가*. PR #80·#82·#73·#76 결.
+
+## MCP 룰 후보 신규 + 강화 (PR #21)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `virtual-object-vs-real-domain` | 강화 | 6+ (#80·#145·#100·#76·#39·#31·#21) ⭐⭐⭐ |
+| `model-view-dependency-direction` | 강화 | 8+ ⭐⭐⭐ |
+| `first-class-collection-delegation-pitfall` | 강화 | 4+ (#21·#74·#108·#46) |
+| `test-fixture-essential-info` | 강화 | 5+ (#99·#26·#21·#87·#93) ⭐⭐ |
+| `ui-layer-model-separation` | 신규 | 1 (#21) — SuitModel UI layer 한정 |
+| `junit-test-lifecycle-tradeoff` | 신규 | 1 (#21) |
+| `regex-pattern-reuse` | 신규 | 1 (#21) — Kotlin 한정 |
+| `data-structure-choice-deck` | 신규 | 4+ (#21·#58·#23·#26) |
+| `nested-builder-readability` | 신규 | 1 (#21) |
+| `function-multiple-roles-via-default-param` | 신규 | 2+ (#21·#36) |
+| `unnecessary-cast-via-typed-listOf` | 신규 | 1 (#21) |
+| `mutable-collection-method-on-domain-class` | 신규 | 1 (#21) |
+| `bidirectional-mutation-via-method` | 신규 | 1 (#21) |
+| `generator-vs-static-factory` | 신규 | 2+ (#21·#46) |
+| `auto-hit-vs-user-choice` | 신규 | 5+ (#80·#82·#73·#76·#21) |
+
+## 메타 어휘 (12 reviewer + MCP 핵심 가치)
+
+- ***가상 객체 vs 실재 도메인 객체*** — galcyurio PR #21 — *"별도의 CardPicker라는게 가상의 무언가가 존재하기보다는 카드를 pick하는 책임은 플레이어에게 있는게 조금 더 자연스럽게"* — *현실 메타포 정합 + 책임 위치 자연*.
+- ***일급 컬렉션 + 위임 = 나쁜 습관 형성*** — galcyurio PR #21 — *"컬렉션을 구현하고 위임하도록 처리해버리면 습관적으로 컬렉션을 쓰듯이 사용하게되어서 나쁜 습관이 만들어집니다"* — *Tell-Don't-Ask 정공*.
+- ***테스트 본문 = 필요한 정보만*** — galcyurio PR #21 — *외부글 (testing.googleblog)* + *factory 함수* + *dealer(rank1, rank2) 형태*.
+- ***SuitModel 미래 학습 안내 + 이번 미션 적용 X*** — galcyurio PR #21 — *학생 부담 최소화 + 안드로이드 어휘*. PR #87·#36·#95·#23·#26 결.
+- ***UI 로직 model 분리 = 절대 원칙*** — galcyurio PR #21 — *3 자리 동일 권유 (Card/Cards/Suit)* + *MVC 핵심*.
+- ***`@BeforeEach` 가독성 우선 + 학생 현재 코드 OK*** — galcyurio PR #21 — *학생 부담 최소화 + 도구 어휘 학습 안내*.
+
+→ *galcyurio = 5+ reviewer (말리빈/잭슨/페로로/지훈/krrong/galcyurio) 와 같은 메타 어휘* — **MCP `oh-my-oop` 핵심 가치 합류 정점 유지**.