oh-my-oop 0.2.0

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

@@ -0,0 +1,819 @@
+# PR #117 — [블랙잭 1단계] 제이 미션
+
+- **Reviewee:** [@parkjiminnnn](https://github.com/parkjiminnnn)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/117
+- **단계:** 1단계
+- **리뷰어:** [@woowahan-dino](https://github.com/woowahan-dino) (디노) — **신규 reviewer — 13번째**
+- **라인 코멘트:** 25 스레드 — *현실 메타포 정합 (카드뭉치에서 카드 꺼내 플레이어 받는다) + 함수 vs 필드 vs computed property (`get()=`) 학생 자가 의문 + Ace 합산 수학적 풀이 + 외부글 (수학 공식) + Kotlin `by` delegation + Iterable 구현 + 함수형 프로그래밍 학습 미션 어휘 + 테스트 하드코드 검증 + `isHit` → `canHit` 이름 vs 의미 + ViewMapper 분리 + drawCount 2역할 분리 + 자식 한정 `protected`*
+- **신규 reviewee** (2025년 코호트 — 3번째 코호트 합류 — 2023, 2024, 2025).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 + 셀프 체크리스트 + 집중 리뷰 영역 명시
+
+PR 본문 구조:
+- **셀프 체크리스트 7항목** (정상 동작 / 테스트 / 피드백 반영 / 코딩 스타일 / 린트 / 프로그래밍 요구사항 / README).
+- **집중 리뷰 영역 명시** *"객체의 역할에 맞게 잘 분리했는지 봐주세요!"* + *"변수명이나 함수명이 적절한가요?"*.
+- **코드 리뷰 커뮤니케이션 자가 의문** — `Get 함수 vs val 필드` 학생 자가 의문 (디노 답변 → Thread 5·14·18 등 multi-thread 후속 토론).
+
+→ **체계화된 PR 본문 모범 (2025 코호트 신규 스타일)** — *셀프 체크리스트 = CI 자가 점검 + 학생 자가 의문 명시*. PR #14·#106·#80·#82·#107·#46·#91·#11·#13·#18·#73 의 *자가 의문 PR 본문* 패턴 강화.
+
+학생 자가 의문 인용:
+
+> *"아래 코드의 Get 함수들을 필드로 선언하는게 나을지 함수로 선언하는게 더 나을지 궁금해요 디노! 저는 함수로 하는게 맞는 것 같아용..*
+> ```kotlin
+> fun getInitialCards(): Cards { ... }
+> fun getCardsCount() = allCards.size
+> ```"
+
+reviewer 후속 (Thread 3·5·14·18):
+
+- *property val vs computed property 양가성*.
+- *`val cardScore: Int = cardRank.score` (즉시 초기화) vs `get() = cardRank.score` (매 호출 계산) 트레이드오프*.
+
+→ **MCP 룰 `property-val-vs-computed-property` 후보** — *Kotlin val 즉시 초기화 vs get() 매 호출 트레이드오프*.
+
+### 2. `data class Card(private val cardRank, private val shape)` + 3 속성 — value object
+
+```kotlin
+data class Card(private val cardRank: CardRank, private val shape: Shape) {
+    val cardScore: Int = cardRank.score
+    val cardName: Pair<String, String> = cardRank.name to shape.name
+    val isAceCard: Boolean = cardRank == CardRank.ACE
+}
+```
+
+→ **`isAceCard: Boolean = cardRank == CardRank.ACE`** = reviewer 권유 (Thread 2) *자가 적용 완료*.
+
+다만 **`cardName: Pair<String, String>` 누수** = *Pair 튜플 = 도메인 어휘 누수* (PR #36 (boogi-woogi *`List<Pair<String, Int>>` 뷰가 도메인을 너무 잘 알고 있다*) 결).
+
+### 3. `enum class CardRank(val score: Int)` + Ace 11 기본
+
+```kotlin
+enum class CardRank(val score: Int) {
+    ACE(11),
+    KING(10), QUEEN(10), JACK(10),
+    TWO(2), THREE(3), ..., TEN(10),
+}
+```
+
+→ **Ace 11 기본 + while 차감 보정** (`ScoreCalculator.calculateTotalCardScore`) — PR #20·#64·#110·#28·#125·#147·#82 의 *Ace 11 기본 + while 차감 안티패턴* 결.
+
+다만 *수학적 풀이 (reviewer Thread 23 후속 권유)* 로 *while 제거 완료* — `totalCardScore - ACE_MINUS_VALUE * aceCount.coerceAtMost((totalCardScore - BLACKJACK_SCORE) / ACE_MINUS_VALUE + 1)`. **MCP 룰 `ace-bonus-mathematical-vs-iterative` 후보**.
+
+### 4. `Players` Kotlin `by` delegation 자가 적용
+
+```kotlin
+class Players(private val players: List<Player>) : List<Player> by players {
+    val names: List<String> = players.map { player -> player.name }
+    val cardNames: List<List<Pair<String, String>>>
+        get() = players.map { player -> player.cardNames }
+    ...
+}
+```
+
+→ **Kotlin `by` delegation 활용** — reviewer (Thread 8) *Kotlin delegation 권유 외부글* (kotlinlang.org/docs/delegation.html) → 학생 자가 적용.
+
+다만 **delegation = §PR #21 의 *일급 컬렉션 위임 = 나쁜 습관* 반대 시점**:
+
+PR #21 (galcyurio) 의 *위임 = 컬렉션처럼 쓰는 나쁜 습관* vs PR #117 (woowahan-dino) 의 *delegation 어휘 권유*. **2 reviewer 의 *반대 시점***.
+
+#### 4.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `by` delegation (현재) | *Kotlin 어휘 + List 메서드 자동 제공 (forEach/map/filter)* | *Tell-Don't-Ask 위반 위험 (List 처럼 사용) + 도메인 메시지 가시성 ↓* |
+| 일급 컬렉션 + 도메인 메시지만 | *Tell-Don't-Ask 정공 + 도메인 의도 명확* | *List 메서드 X (외부 호출 시 불편)* |
+
+→ **2 reviewer 메타 어휘 = MCP `oop_propose_alternatives` 핵심 가치 합류 (개인 의견 분리)**.
+
+PR #21 (galcyurio) + PR #117 (woowahan-dino) — *delegation 정공 토론*.
+
+### 5. `protected fun addCard(card: Card)` 자식 한정 가시성 자가 적용
+
+```kotlin
+abstract class Participant(private val cards: Cards) {
+    ...
+    protected fun addCard(card: Card) {
+        handCards.add(card)
+    }
+}
+```
+
+→ reviewer (Thread 16) *"지금은 addCard() 함수가 자식 클래스에서만 사용하도록 되어있는데 자식 클래스에서만 접근가능하도록 접근제어자를 추가해보면 어떨까요?"* → 학생 자가 적용. **`protected` 가시성 = 자식 한정 + 외부 호출 차단**. PR #87 결.
+
+### 6. `ScoreCalculator.adjustAceScore` 수학적 풀이 — while 제거
+
+```kotlin
+private fun adjustAceScore(totalCardScore: Int, aceCount: Int) = 
+    totalCardScore - ACE_MINUS_VALUE * aceCount.coerceAtMost((totalCardScore - BLACKJACK_SCORE) / ACE_MINUS_VALUE + 1)
+```
+
+→ **`while` 반복 → 수학적 단일 식 변환** (reviewer Thread 23 권유 → 학생 자가 적용). 
+
+#### 6.1. *수학 공식 도출*
+
+- Ace 11→1 = -10 점.
+- 초과 점수 = `totalCardScore - BLACKJACK_SCORE` (양수).
+- 필요한 -10 회수 = `초과 / 10 + 1` (1 부터 시작 = +1).
+- 다만 최대 -10 회수 = `aceCount` (Ace 개수 한정) → `coerceAtMost(aceCount)`.
+
+→ **MCP 룰 `iterative-loop-vs-math-formula` 강화** — *반복문 의존 vs 수학적 단일 식*. 외부글 동반.
+
+PR #87 (mutableMap → fold) 결의 *명령형 vs 함수형/수학적* 어휘 합류.
+
+### 7. 모든 25 스레드 학생 자가 답변 + 커밋 SHA 첨부
+
+25 스레드 전부 학생이 *반영 커밋 링크 (`https://github.com/woowacourse/kotlin-blackjack/pull/117/commits/<sha>`)* 첨부.
+
+→ **학생 자가 학습 가시화 모범 = 학습 가시화 정점**. PR #124·#128·#135·#108·#133·#136·#137·#148·#151·#146·#147·#88·#36·#87 결.
+
+### 추가 칭찬
+
+- *Thread 5*: *"너무 좋습니다 👍 저는 여기서 get함수보다 val로 선언해서 가져와도 좋다고 봐요"* — *학생 자가 의문 + reviewer confederate*.
+
+## 못한 점 (설계 관점)
+
+### 1. `createCardRank` 함수명 vs 실제 반환 — 이름·반환 불일치
+
+reviewer (Thread 1):
+
+> *"createCardRank 라는 함수명을 봤을 때는 CardRank를 만들어서 반환하는 느낌인데 함수 구현부는 그렇지 않네요. 적절한 함수명으로 변경하거나, cards를 전달하지 않고 `List<Card>`를 반환하는 형태로 변경해보면 어떨까요?"*
+
+학생: *"함수명을 변경했습니당 🫠"*
+
+→ **함수 이름·반환 의미 불일치** — PR #36 (boogi-woogi `decideAceValue` 1 or 11 예상 vs 실제 추가 점수) 결 강화.
+
+**MCP 룰 `function-name-vs-return-semantic-mismatch` 강화** 누적 3+ PR (#36·#117·#21).
+
+### 2. `cardName.contains("A")` vs `cardRank == CardRank.ACE` — Stringly-typed 회피
+
+reviewer (Thread 2):
+
+> *"cardName에 'A'가 포함되어 있는 것 보다 cardRank가 ACE인지 확인하면 어떨까요??*
+> ```
+> fun isAceCard(): Boolean = cardRank == CardRank.ACE
+> ```"
+
+학생: *"굳이 문자열 값을 비교하지 않고 cardRank에 담겨 있는 값을 통해 비교하는게 더 좋을 것 같네용"*
+
+→ **Stringly-typed vs enum 비교** — *문자열 검색 = 오타 위험 + 의미 누수* vs *enum 비교 = 컴파일러 강제*.
+
+**MCP 룰 `stringly-typed-vs-enum-comparison` 후보** — *문자열 contains vs enum equality*.
+
+PR #20·#28·#125·#147·#65·#92 결의 *enum의 UI value* 안티패턴 변형 (UI 값 검색).
+
+### 3. `val cardScore: Int = cardRank.score` vs `get() = cardRank.score` — property val vs computed property
+
+reviewer (Thread 3):
+
+> *"`val cardScore: Int = cardRank.score`*
+> *로 하는 것과*
+> *`val cardScore: Int`*
+> *`    get() = cardRank.score`*
+> *로 하는 것은 어떤차이가 있을까요?*
+>
+> *이 코드에서는 어떤게 더 적합할지 한번 고민해보면 좋을 것 같아요"*
+
+학생: *"score값을 매번 초기화해줄 필요없이 한번만 해도 된다고 생각하기 때문에 이렇게 하는게 맞는 것 같아요!"*
+
+reviewer 후속 (Thread 14): *"함수보다 field로 사용하면 더 좋을 것 같네요"*  
+reviewer 후속 (Thread 18): *"카드를 추가할 때 마다 새로운 값을 가져와야 한다면 `get() =` 을 사용하면 됩니다."*
+
+→ **Kotlin property 3 가지 형태**:
+
+| 안 | 의미 | 적합 시점 |
+|---|---|---|
+| `val cardScore: Int = cardRank.score` | *인스턴스 생성 시 한 번 초기화 + 불변* | *값이 인스턴스 생애 동안 변하지 않을 때* (현재 Card 의 cardScore) |
+| `val cardScore: Int get() = cardRank.score` | *매 호출 시 계산 + 항상 최신* | *값이 변할 수 있을 때 / 의존성이 mutable* |
+| `fun getCardScore(): Int = cardRank.score` | *매 호출 시 계산 + 함수 의도 명시* | *부작용 가능 / 인자 필요 / 명령형 동작* |
+
+#### 3.1. *Kotlin 어휘 정공*
+
+PR 본문 자가 의문 (Get 함수 vs val) → reviewer 다회 답변 (Thread 3·5·14·18) → 학생 multi-step 자가 학습.
+
+**MCP 룰 `property-val-vs-computed-property` 후보** — *Kotlin property 3 형태 트레이드오프*.
+
+### 4. `distinct()` vs `toSet()` — 함수 의도 양가
+
+reviewer (Thread 4):
+
+> *"distinct() 함수가 어떻게 구현되어 있는지 한번 보시고 distinct()대신 다른 함수를 쓰도록 변경해보면 좋을 것 같습니다. 아니면 제이는 여기서 distinct()를 사용하신 이유가 중복제거 외에 다른 의미도 있었을까요?"*
+
+학생: *"중복제거 말고는 다른 의미는 없었어요..😅"*
+
+→ **`distinct()` vs `toSet()` 의미 비교**:
+
+| 함수 | 의도 | 비용 |
+|---|---|---|
+| `distinct()` | *순서 보존 + 중복 제거 (List 유지)* | *O(n) + HashSet 보조 자료구조 내부* |
+| `toSet()` | *순서 X + 중복 자가 X* | *O(n) + HashSet* |
+
+학생의 *카드 중복 invariant 검증* 용도 = *순서 보존 불필요* → `toSet()` 적합.
+
+```kotlin
+// AS-IS
+require(allCards.distinct().size == getCardsCount())
+// TO-BE
+require(allCards.toSet().size == totalCount)
+```
+
+**MCP 룰 `distinct-vs-toSet-intent` 후보** — *함수 의도 = 순서 보존 여부*.
+
+### 5. `getCardsCount` → `cardsCount` — Cards 클래스 내 *count* 어휘
+
+reviewer (Thread 5):
+
+> *"저는 여기서 get함수보다 val로 선언해서 가져와도 좋다고 봐요. getCardsCount보다 cardsCount가 더 좋아보이고 이미 class 이름이 Cards니까 count만 해도 되지 않을까 싶습니다. 제이가 제 피드백이 괜찮다고 생각하시면 다른 것들도 같이 반영해봐도 좋을 것 같습니다~"*
+
+학생: *"카드를 추가할 때마다 초기화 해줘야 해서 val로 선언하면 안될 것 같네용..🥲 함수명만 수정하겠습니당"*
+
+reviewer 후속 (Thread 18): *"카드를 추가할 때 마다 새로운 값을 가져와야 한다면 `get() =` 을 사용하면 됩니다."*
+
+→ **클래스 명 = 의도 일부 → 멤버 명 중복 회피** (`Cards.cardsCount` vs `Cards.count` vs `Cards.totalCount`). 학생 최종 `totalCount` 자가 적용.
+
+**MCP 룰 `member-name-includes-class-name` 후보** — *Cards.cardsCount = 클래스 이름 중복*.
+
+### 6. `isHit` → `canHit` — 이름 의미 정확성
+
+reviewer (Thread 6):
+
+> *"함수를 사용하는 곳을 보니 **hit이 가능할 때 카드를 받는다** 인 것 같아요. isHit이라는 것 Hit이냐? 라는 의미라 적절한 이름은 아니라고 생각합니다. Hit이 가능한지? 라는 의미로 canHit 정도로 하면 어떨까요?"*
+
+학생: *"좋은데요? 가시죠!!"*
+
+→ **이름 의미 정확성** — *isHit (지금 Hit이다) vs canHit (Hit 가능하다)* 의 도메인 의미 차이. 
+
+**MCP 룰 `is-vs-can-prefix-semantics` 후보** — *is-prefix (현재 상태) vs can-prefix (가능 여부) 의미 구분*. PR #21 (Player.isHit() = !isBust()) 결의 *Hit 자동 시점 vs 사용자 선택* 변형.
+
+### 7. `16` 매직 넘버 → 상수
+
+reviewer (Thread 7):
+
+> *"여기서 16이 어떤 의미인지 상수로 빼서 관리하면 어떨까요??"*
+
+학생 자가 적용: `private const val DEALER_HIT_LIMIT = 16`.
+
+→ **매직 넘버 회피 + 도메인 의미 어휘** (Dealer hit 한계 = 16). PR #20·#28·#125·#125·#147·#65·#92·#36 결.
+
+### 8. `score = calculateCardScore() - cards.aceCount() + cards.aceCount()` inline 정리 — 동치 표현 회피
+
+reviewer (Thread 10):
+
+> *"score를 만들기 위해 호출하는 함수들을 전부 inline처리하면 이렇게 되네요*
+> *`var score = calculateCardScore() - cards.aceCount() + cards.aceCount()`*
+> *cards.aceCount를 빼고 더해서 사실상 calculateCardScore()만 해도 되겠네요"*
+
+→ **함수 합성 후 동치 식 = 추상화 의도 누수** — *Score = score - aceCount + aceCount = score*. **추상화가 동작 의도를 가리는 안티패턴**.
+
+#### 8.1. *함수 합성 시 동치 검증*
+
+학생 초기 코드:
+```kotlin
+fun calculate(cards: Cards): Int {
+    var score = calculateCardScore(cards)
+    score = subtractAceCount(score, cards)
+    score = addAceCount(score, cards)
+    return score
+}
+```
+
+→ *함수 3 단계 분리 → inline 시 `score - aceCount + aceCount = score` 자명*. **함수 분리가 *추상화 의도 X*** = *함수 분리 비용만 발생*.
+
+**MCP 룰 `function-decomposition-creates-identity` 후보** — *함수 분리가 inline 후 동치 = 추상화 의도 X*. PR #36·#46·#39 (function-decomposition-excess) 결 강화.
+
+### 9. 반복문 의존 vs 수학적 풀이 — Ace 합산 + 외부글
+
+reviewer (Thread 11):
+
+> *"개발을 하다보면 가끔 반복문에 너무 의존하게 될 때가 있습니다. 우리가 만약에 1부터 10까지 합을 구한다고 하면 1부터 10까지 반복문을 돌리는 것을 먼저 떠올리게 됩니다. 하지만 그것보다 더 좋은 수학적인 방법이 존재합니다. 이 로직도 꼭 반복문을 돌려야하는지? 수학적으로 풀 수 없는지? 를 생각해보면 좋을 것 같습니다.*
+> *https://leebaro.tistory.com/entry/1%EB%B6%80%ED%84%B0-10%EA%B9%8C%EC%A7%80-%EC%88%AB%EC%9E%90%EB%A5%BC-%ED%95%A9%ED%95%98%EB%8A%94-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98"*
+
+학생 자가 한계 인정:
+
+> *"가지고 있는 ace카드의 개수만큼 반복문으로 카드를 힛하는 턴마다의 카드의 총합을 계산해서 ace카드의 점수를 유동적으로 바꿀 수 있다고 생각을 합니다.. 근데 반복문을 사용하지 않고 수학적인 방법으로만 턴마다 카드 점수의 총합을 유동적으로 계산하는건 어떻게 해야 할지 도저히 감이 안 잡히는데 힌트를 조금만 더 주실 수 있을까요?🥺"*
+
+reviewer 후속 (Thread 23 — 힌트):
+
+> *"이렇게 하면 while 없이 계산해서 넣을 수 있겠네요*
+> ```kotlin
+> val totalCardScore = cards.scores().sum()
+> val aceCount = cards.aceCount()
+> return if (totalCardScore > BLACKJACK_SCORE && aceCount > 0) {
+>     totalCardScore - 10 * aceCount.coerceAtMost((totalCardScore - BLACKJACK_SCORE) / 10 + 1)
+> } else {
+>     totalCardScore
+> }
+> ```"
+
+학생: *"감사합니당. if문으로 조건을 나눌 생각을 못했네요😅"*
+
+→ **반복문 의존 vs 수학적 풀이 + 외부글 + 학생 자가 힌트 요청 + reviewer 후속 답변**:
+
+#### 9.1. *3 가지 학습 시점*
+
+1. **반복문 의존 안티패턴 인식** — *Ace = 1↔11 분기 = while 도는 반사적 반응*.
+2. **수학적 풀이 = `초과 / 10 + 1` (단일 식)** — `coerceAtMost(aceCount)` 활용.
+3. **외부글 + 학생 자가 힌트 요청 = 학생 학습 적극성** — *reviewer 답변 제공*.
+
+**MCP 룰 `iterative-loop-vs-math-formula` 강화** ⭐⭐. PR #87 (mutableMap → fold) 결과 같은 *명령형 vs 함수형/수학적* 어휘 합류.
+
+### 10. `model = domain vs view` — ViewMapper 분리 + Cards.isDisplayName 확장함수
+
+reviewer (Thread 12):
+
+> *"미션을 하고 있는 프로젝트에서 model이라는게 domain관점인지 view관점인지가 중요할 것 같아요. domain 관점에서는 title이라는 view 관점의 값들이 들어있는게 맞을까? 라는 의문을 가져보면 어떨까요?*
+>
+> ***ViewMapper나 Cards.isDisplayName()과 같은 확장함수를 사용하는 방식*** *도 괜찮은 방법 입니다."*
+
+학생 자가 적용 (4 commit):
+- *ViewMapper 클래스 생성*.
+- *카드이름의 출력방식 변경 함수 생성*.
+- *title 프로퍼티 제거*.
+- *반환 타입 변경*.
+
+→ **Model → View 의존성 분리 = MVC 절대 원칙** + **ViewMapper / 확장함수 2 가지 안**:
+
+#### 10.1. *3 가지 대안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Model 안 UI 메서드 (학생 초안 *title* 프로퍼티) | *카드 자가 표현 보유 + 호출 간결* | *Model → View 결합 + MVC 위반* |
+| `ViewMapper` 별도 클래스 (학생 자가 적용) | *변환 책임 명확 + Model 순수* | *클래스 ↑ + 매핑 보일러플레이트* |
+| `Cards.isDisplayName()` 확장함수 (reviewer 권유) | *Kotlin 어휘 + Model 순수 + 호출 간결* | *확장함수 검색성 ↓ + import 누수* |
+
+**MCP 룰 `view-mapper-vs-extension-function` 후보** — *Model→View 분리 방법 트레이드오프*. PR #21·#87·#88·#80·#76 결 강화.
+
+### 11. 현실 메타포 정합 — *카드뭉치에서 카드 꺼내 플레이어 받는다*
+
+reviewer (Thread 13):
+
+> *"이 동작에 대해서 생각해볼 필요가 있을 것 같아요. 현실에서는 카드뭉치에서 카드 한장을 꺼내서 플레이어가 받는다 라는 동작인데 이 코드를 보면 플레이어가 카드뭉치를 받고 거기서 카드를 받는 동작으로 보여요. 이 부분을 개선해보면 어떨까요?"*
+
+학생 자가 적용: *"뽑은 카드를 받는 기능으로 변경"*.
+
+→ **현실 메타포 정합 = 책임 분배 단계의 핵심**:
+
+#### 11.1. *3 가지 책임 분배 안*
+
+| 안 | 메타포 | 책임 |
+|---|---|---|
+| `player.receiveCards(deck)` (학생 초안) | *플레이어가 카드덱을 받음 → 거기서 카드 받음* | *플레이어 ↔ 카드덱 양방향 + 메타포 X* |
+| `deck.dealTo(player)` | *카드덱이 분배자 = 플레이어에게 카드 줌* | *카드덱이 분배 책임 (카지노 메타포)* |
+| `player.receive(drawnCard: Card)` (학생 자가 적용) | *플레이어가 *이미 뽑힌 카드 1장* 받음* | *현실 정공 (딜러가 뽑아서 줌)* |
+
+→ **현실 메타포 = 객체 책임 분배 핵심 어휘** = **MCP `oh-my-oop` 핵심 가치**. PR #31 (no1msh *발급기 그 자체에게는 돈이 필요하지 않다*) 결 + PR #21 (CardPicker = 가상 객체) 결.
+
+**MCP 룰 `metaphor-fidelity-locator` 강화** ⭐⭐⭐ — *현실에서 누가 이 일을 하는가*. 누적 8+ PR.
+
+### 12. MutableList 회피 — 함수형 프로그래밍 학습 미션 어휘
+
+reviewer (Thread 15):
+
+> *"이번에 함수형 프로그래밍에 대해 학습하는 미션이니까 MutableList를 만들지 않고 기존에 있는 List나 Array를 사용해서 만들어 보도록 해볼까요? Iterable 확장함수로 여러 함수들이 제공되고 있으니 적절한 함수들을 찾아서 변경해보면 좋을 것 같아요. addCardsByRank()함수도 제거할 수 있을 것 같습니다."*
+
+→ **함수형 프로그래밍 학습 미션 어휘 = 의도 명시**:
+
+#### 12.1. *학습 의도 = 미션의 본질*
+
+reviewer 가 *"이번에 함수형 프로그래밍에 대해 학습하는 미션이니까"* 명시 = *학습 목표 의식*. **학생 자가 학습 가시화 어휘**. PR #91·#107·#147·#22·#73·#76·#80·#82·#11·#13 결.
+
+#### 12.2. *Iterable 확장함수 (flatMap, map, fold) 권유*
+
+학생 초안:
+```kotlin
+fun createCards(): MutableList<Card> {
+    val cards = mutableListOf<Card>()
+    CardRank.values().forEach { rank -> addCardsByRank(cards, rank) }
+    return cards
+}
+```
+
+수정 후:
+```kotlin
+fun createCards(): List<Card> =
+    CardRank.values().flatMap { rank -> Shape.values().map { shape -> Card(rank, shape) } }
+```
+
+PR #21 (CardPackGenerator buildList 4 단계 중첩) 결 + PR #87 (mutableMap → fold) 결 동일 *명령형 vs 함수형* 어휘.
+
+**MCP 룰 `mutable-list-vs-functional-pipeline` 후보** — *MutableList 회피 + Iterable 확장함수*.
+
+### 13. `drawCount()` 함수 = 2 역할 — count 가져옴 + 카드 뽑음
+
+reviewer (Thread 19):
+
+> *"drawCount라는 함수가 한가지의 역할만 하지는 않는 것 같아요.*
+>
+> *drawCount만 보면 카드를 뽑은 개수를 가져오는 것으로 느껴지는데 내부에서는 실제로 카드를 뽑을 수 있으면 카드를 뽑는 역할도 하고 있어요. 함수를 분리해볼 수 있지 않을까요?"*
+
+학생 자가 적용: *drawCount() 로직 분리*.
+
+→ **함수 단일 책임 위반 (SRP)** — *조회 (count 가져옴) + 부작용 (카드 뽑음) 양가*. **CQS (Command-Query Separation) 위반**.
+
+#### 13.1. *2 가지 학습*
+
+#### 13.1.1. *CQS 원칙*
+
+*Command (부작용) vs Query (조회) 분리* = 메서드 1 = 1 역할.
+
+학생 코드:
+```kotlin
+fun drawCount(drawnCard: Card): Int {
+    var drawCount = DEFAULT_DRAW_COUNT
+    drawCount += addDraws(drawnCard)  // ← 카드 뽑음 (Command)
+    return drawCount                  // ← count 반환 (Query)
+}
+```
+
+→ **Command + Query 양가**. **MCP 룰 `command-query-separation` 후보**.
+
+#### 13.1.2. *이름 의미 누수*
+
+`drawCount` 이름 = *Query (count 가져옴)* 시사 → *실제는 Command + Query*. PR #36 (decideAceValue 명명·반환 불일치) 결 + Thread 1 (createCardRank) 결.
+
+### 14. `enum` 으로 처리 가능 — GameResultDecider
+
+reviewer (Thread 20):
+
+> *"이것들은 enum으로 처리 할 수 있지 않을까요?"*
+
+학생 자가 적용: *VictoryStatus enum 생성 + mapToVictoryStatus 변환*.
+
+→ **상수/문자열 → enum 변환** — *컴파일러 강제 + 의미 명시*. PR #20·#28·#125·#147·#65·#92 결.
+
+### 15. 테스트 = 하드코드 검증 (CardRank/Shape 변경 안전)
+
+reviewer (Thread 22):
+
+> *"만약 CardRank나 Shape가 어떤 값이 빠지거나 새로운 값이 추가되면 검증하기 어려울 것 같습니다. 보통 테스트 코드에서는 이렇게 코드를 만드는 것보단 하드코드 된 것으로 검증하는게 좋습니다."*
+
+학생 자가 적용.
+
+→ **테스트 = 하드코드 검증 정공**:
+
+#### 15.1. *Production 코드 의존 X*
+
+학생 초기 테스트:
+```kotlin
+@Test fun `카드 생성 테스트`() {
+    val cards = CardsGenerator().createCardPack()
+    assertEquals(CardRank.values().size * Shape.values().size, cards.totalCount)
+}
+```
+
+→ *`CardRank.values().size * Shape.values().size = 13 * 4 = 52`* — *production 코드 의존*. CardRank 추가 시 *테스트 같이 변경됨* → 회귀 감지 X.
+
+수정 후:
+```kotlin
+@Test fun `카드 생성 테스트`() {
+    val cards = CardsGenerator().createCardPack()
+    assertEquals(52, cards.totalCount)  // ← 하드코드
+}
+```
+
+→ *CardRank 가 13 미만이 되면 테스트 실패 = 회귀 감지*.
+
+**MCP 룰 `test-hardcoded-vs-production-derived` 강화** — *테스트 = 하드코드 검증 정공*. 누적 3+ PR (#99·#26·#117).
+
+PR #87 (테스트 = 객체 설계 명세서) 결 + PR #21 (테스트 본문 = 필요한 정보) 결 + PR #26 (테스트 = 명세서) 결 합류.
+
+### 16. `Players.kt` `val` 자가 적용 권유 — Iterable 구현 시
+
+reviewer (Thread 9 + 21):
+
+> *"Players 클리스가 Iterable<Player> 이기 때문에 players를 val로 선언하지 않아도 되는 것으로 보입니다."*  
+> *"여기도 val로 해볼 수 있겠네요"*
+
+→ **Iterable 구현 시 backing list val 불필요** — *delegation 의 의도 명확 → 별도 list 보관 X*.
+
+다만 학생 최종 코드 (`class Players(private val players: List<Player>) : List<Player> by players`) = *delegation source 는 여전히 보관* → reviewer 의 권유 ≠ list 제거 = *names/cardNames/scores 같은 *Players 추가 속성*만 val 화*.
+
+**MCP 룰 `delegation-source-val-redundancy` 후보** — *delegation source list 보관 의도 점검*.
+
+### 17. `showPlayerResult` 파라미터 비대칭 — playersNames 만 외부 전달
+
+reviewer (Thread 17):
+
+> *"updatedPlayerCardsNames, playersTotalScore 는 players에서 가져오는데 showPlayerResult로 전달되는 playersNames만 함수 외부에서 파라미터로 전달하는 이유가 있나요?"*
+
+학생 자가 적용: *showPlayerResult 인자 제거*.
+
+→ **함수 인자 일관성 = 객체 가져오는 자리 통일** — *3 인자 중 1 만 외부 전달 = 일관성 X*. **MCP 룰 `function-parameter-asymmetry` 후보**.
+
+### 18. `addDraws()` `Dealer.turn()` 의 `canHit()` 중복 호출
+
+reviewer (Thread 25):
+
+> *"turn()함수에서 canHit()을 호출하고 있기 때문에 addDraws()함수에 있는 while에서는 canHIt()를 호출하지 않아도 될 것 같네요"*
+
+학생 코드:
+```kotlin
+override fun turn(drawnCard: Card): Boolean {
+    if (canHit()) { addCard(drawnCard); return true }
+    return false
+}
+
+private fun addDraws(drawnCard: Card): Int {
+    var count = DEFAULT_DRAW_COUNT
+    while (canHit() && turn(drawnCard)) count++   // ← canHit 중복 호출
+    return count
+}
+```
+
+→ **canHit 중복 호출** — *while 조건과 turn 내부 모두 canHit 호출* = *2 회 평가*. **MCP 룰 `redundant-guard-condition` 후보**.
+
+### 19. `Players` Cards 와 함수 내부 처리 — Controller god-object 예방
+
+reviewer (Thread 24):
+
+> *"여기도 Players와 Cards를 넘겨서 함수 내부에서 처리 해볼 수 있겠네요"*
+
+→ **Controller 가 Players/Cards 외부에서 처리 → Tell-Don't-Ask 위반**. *Players/Cards 가 자가 처리 + 결과만 반환*. PR #87·#36·#28·#92·#48 결.
+
+### 20. `Players.toList()` (학생 자가 적용한 일급 컬렉션) — delegation 합류 vs Tell-Don't-Ask
+
+§4 참조. PR #21 (galcyurio *delegation = 컬렉션처럼 쓰는 나쁜 습관*) 와 PR #117 (woowahan-dino *delegation 정공*) 의 *반대 시점*. 
+
+→ **MCP `oop_propose_alternatives` 핵심 가치 합류 정점** — *reviewer 별 의견 차이 인정*.
+
+### 21. `Cards.kt` `allCards.toMutableList()` + `allCards.removeAll()` — mutable 누수
+
+```kotlin
+class Cards(allCards: List<Card>) {
+    val allCards: MutableList<Card> = allCards.toMutableList()
+    ...
+    fun initialCards(): Cards {
+        val initialCards = allCards.take(INITIAL_CARD_COUNT)
+        allCards.removeAll(initialCards)
+        return Cards(initialCards)
+    }
+}
+```
+
+→ **`val allCards: MutableList<Card>` public 노출** = *외부에서 변경 가능* + *`removeAll` 자가 변경*. **canonical mutable leak**.
+
+대안: `private val _cards: MutableList<Card>` + `val cards: List<Card> get() = _cards.toList()` (backing property). PR #18·#36·#21 결.
+
+**MCP 룰 `mutable-list-public-exposure` 강화** — 누적 5+ PR.
+
+### 22. `GameResultDecider` Tell-Don't-Ask — Dealer/Player score 직접 비교
+
+```kotlin
+class GameResultDecider(private val dealer: Dealer, private val players: Players) {
+    fun compareWinOrLose(): GameOutput {
+        ...
+    }
+
+    private fun comparePlayerResult(playerScore: Int): VictoryStatus =
+        when {
+            dealer.currentScore > BLACKJACK_SCORE -> VictoryStatus.WIN
+            playerScore > BLACKJACK_SCORE -> VictoryStatus.LOSE
+            else -> compareScores(playerScore)
+        }
+}
+```
+
+→ **Decider 객체 + Dealer/Player score 외부 꺼내서 비교** = *Tell-Don't-Ask 위반*. PR #87·#36·#28·#92·#48 결.
+
+대안: **`Player.compareWith(dealer): VictoryStatus`** 또는 **State 다형성** (PR #93·#136·#152·#98·#87 결).
+
+다만 학생의 *GameResultDecider 분리* = *비교 책임 단일 위치* (vs Player.compareWith 가 *Player ↔ Dealer 양방향 결합*). 
+
+**MCP 룰 `decider-vs-tell-dont-ask` 후보**.
+
+### 23. `currentScore` 매 호출 시 `ScoreCalculator(cards).calculateTotalCardScore()` 신규 인스턴스
+
+```kotlin
+abstract class Participant(private val cards: Cards) {
+    ...
+    val currentScore: Int
+        get() = ScoreCalculator(cards).calculateTotalCardScore()
+}
+```
+
+→ **매 호출 시 `ScoreCalculator` 신규 인스턴스 + 계산** = *비용 ↑*. *ScoreCalculator 가 stateless (cards 만 멤버)* → *companion object 정적 메서드* 대안.
+
+대안:
+```kotlin
+object ScoreCalculator {
+    fun calculateTotalCardScore(cards: Cards): Int = ...
+}
+
+// 호출
+val currentScore: Int get() = ScoreCalculator.calculateTotalCardScore(cards)
+```
+
+**MCP 룰 `stateless-class-vs-companion-object` 후보** — *stateless 클래스 인스턴스화 vs companion object 정적*. PR #20·#28·#125 결.
+
+### 24. `Dealer.turn` 반환 boolean 의미 + `Player.turn` 반환 boolean 의미 — 역방향
+
+```kotlin
+// Dealer
+override fun turn(drawnCard: Card): Boolean {
+    if (canHit()) { addCard(drawnCard); return true }
+    return false
+}
+
+// Player
+override fun turn(drawnCard: Card): Boolean {
+    if (canHit()) { addCard(drawnCard); return false }  // ← Dealer 와 반대
+    return true
+}
+```
+
+→ **`turn()` 반환 의미 Dealer/Player 역방향** — *Dealer.turn = true (hit 함) / Player.turn = false (hit 함)*. 
+
+도메인 의미:
+- Dealer: *turn() = true → 계속 hit (16 이하 동안)*.
+- Player: *turn() = true → 종료 (carry, hit 안 함)*.
+
+→ **이름·의미 양가** → 사용자 (Controller) 가 *Dealer.turn 인지 Player.turn 인지에 따라 분기 의미 반대*.
+
+**MCP 룰 `method-return-semantic-asymmetry-between-subclasses` 후보** — *부모 추상 메서드 반환 의미 자식 별 역방향*.
+
+### 25. `Card.cardName: Pair<String, String>` — Tuple 누수
+
+```kotlin
+val cardName: Pair<String, String> = cardRank.name to shape.name
+```
+
+→ **Tuple `Pair<String, String>` 도메인 어휘 누수** — *(rank, shape) 짝 = 도메인 객체로 표현 권유*. PR #36 (boogi-woogi *`List<Pair<String, Int>>` 뷰가 도메인을 너무 잘 알고 있다*) 결.
+
+대안:
+- `data class CardName(val rank: String, val shape: String)`.
+- `fun displayName(): String` (UI 변환 책임 명확).
+- View 가 `Card` 받아서 *card.cardRank.name + card.shape.name* 자가 처리.
+
+reviewer 명시 X — 다만 *Thread 12 (Model = domain vs view)* 와 결합.
+
+**MCP 룰 `tuple-leak-vs-domain-dto` 강화** — 누적 3+ PR (#36·#87·#117).
+
+## 리뷰어 의견 요지
+
+- **현실 메타포 정합** — *카드뭉치에서 카드 꺼내 플레이어 받는다* (Thread 13). *책임 분배 메타포 핵심*.
+- **이름·의미 정확성** — *createCardRank* (CardRank 반환 X), *isHit* → *canHit*, *drawCount* 2 역할.
+- **property val vs computed property** — *학생 자가 의문 + reviewer 다회 답변 (Thread 3·5·14·18)*.
+- **Kotlin delegation 권유** — *외부글 (kotlinlang.org) 동반*. PR #21 (galcyurio *위임 = 나쁜 습관*) 와 **반대 시점**.
+- **함수형 프로그래밍 학습 미션 어휘** — *MutableList 회피 + Iterable 확장함수*. *학습 의도 의식*.
+- **반복문 의존 vs 수학적 풀이** — *외부글 (leebaro 1부터 10까지 합) + 학생 자가 힌트 요청 + reviewer 후속 답변*.
+- **Stringly-typed → enum 비교** — *cardName.contains("A") → cardRank == ACE*.
+- **함수 합성 동치 = 추상화 의도 X** — *score - aceCount + aceCount = score*.
+- **테스트 = 하드코드 검증** — *production 코드 의존 X = 회귀 감지*.
+- **함수 인자 일관성** — *playersNames 만 외부 전달 = 비대칭*.
+- **canHit 중복 호출** — *while 조건과 turn 내부 모두 호출*.
+- **`protected` 자식 한정 가시성** — *addCard 외부 호출 차단*.
+- **Model = domain vs view 의문 + ViewMapper / 확장함수 2 안** — *MVC 절대 원칙*.
+- **enum 변환 권유** — *상수/문자열 → 컴파일러 강제*.
+- **distinct() vs toSet() 의도** — *순서 보존 여부*.
+- **클래스 이름과 멤버 이름 중복** — *Cards.cardsCount → Cards.count*.
+- **수정 후 칭찬** — *반영 후 commit 링크 첨부 모범*.
+
+## 대표 인용
+
+> [woowahan-dino]
+> *"이 동작에 대해서 생각해볼 필요가 있을 것 같아요. 현실에서는 카드뭉치에서 카드 한장을 꺼내서 플레이어가 받는다 라는 동작인데 이 코드를 보면 플레이어가 카드뭉치를 받고 거기서 카드를 받는 동작으로 보여요. 이 부분을 개선해보면 어떨까요?"*
+
+→ **현실 메타포 정합 어휘** — *MCP `oh-my-oop` 핵심 가치 (책임 분배 단계)*. PR #31·#21 결.
+
+> [woowahan-dino]
+> *"개발을 하다보면 가끔 반복문에 너무 의존하게 될 때가 있습니다. 우리가 만약에 1부터 10까지 합을 구한다고 하면 1부터 10까지 반복문을 돌리는 것을 먼저 떠올리게 됩니다. 하지만 그것보다 더 좋은 수학적인 방법이 존재합니다."*
+
+→ **반복문 의존 vs 수학적 풀이** 어휘. 외부글 동반.
+
+> [parkjiminnnn 자가 답변]
+> *"가지고 있는 ace카드의 개수만큼 반복문으로 카드를 힛하는 턴마다의 카드의 총합을 계산해서 ace카드의 점수를 유동적으로 바꿀 수 있다고 생각을 합니다.. 근데 반복문을 사용하지 않고 수학적인 방법으로만 턴마다 카드 점수의 총합을 유동적으로 계산하는건 어떻게 해야 할지 도저히 감이 안 잡히는데 힌트를 조금만 더 주실 수 있을까요?🥺"*
+
+→ **학생 자가 한계 인정 + 자가 힌트 요청** — *학습 적극성*. PR #95·#98·#46·#73·#36·#87 결.
+
+> [woowahan-dino]
+> *"미션을 하고 있는 프로젝트에서 model이라는게 domain관점인지 view관점인지가 중요할 것 같아요. domain 관점에서는 title이라는 view 관점의 값들이 들어있는게 맞을까? 라는 의문을 가져보면 어떨까요?"*
+
+→ **Model = domain vs view 의문 어휘** — *MVC 절대 원칙*.
+
+> [woowahan-dino]
+> *"이번에 함수형 프로그래밍에 대해 학습하는 미션이니까 MutableList를 만들지 않고 기존에 있는 List나 Array를 사용해서 만들어 보도록 해볼까요?"*
+
+→ **학습 의도 의식 어휘** — *미션의 학습 목표 의식*.
+
+> [woowahan-dino]
+> *"drawCount만 보면 카드를 뽑은 개수를 가져오는 것으로 느껴지는데 내부에서는 실제로 카드를 뽑을 수 있으면 카드를 뽑는 역할도 하고 있어요. 함수를 분리해볼 수 있지 않을까요?"*
+
+→ **CQS (Command-Query Separation) 어휘**.
+
+> [parkjiminnnn 자가 답변]
+> *"카드를 추가할 때마다 초기화 해줘야 해서 val로 선언하면 안될 것 같네용..🥲 함수명만 수정하겠습니당"*
+
+→ **학생 자가 부분 적용 + 부분 거절** — *val 으로 변환 거절 + 함수명만 적용*. **MCP `oop_propose_alternatives` 핵심 가치 (학생 자가 선택)** 합류.
+
+reviewer 후속 (Thread 18):
+
+> *"카드를 추가할 때 마다 새로운 값을 가져와야 한다면 `get() =` 을 사용하면 됩니다."*
+
+→ **reviewer 후속 답변 = 학생 자가 거절 이유 인정 + 대안 제시** — *3 가지 property 형태 안내*. **양방향 reviewer/학생 토론 정공**.
+
+## 얻은 교훈 (보편)
+
+1. **현실 메타포 정합 = 책임 분배 핵심** — *카드뭉치에서 카드 꺼내 플레이어 받는다* 같은 현실 동작 매핑. **MCP 룰 `metaphor-fidelity-locator` 강화** ⭐⭐⭐ (누적 8+ PR).
+
+2. **이름·의미 정확성 (함수 명명)** — *createCardRank/isHit/drawCount = 이름 vs 실제 동작 불일치*. **MCP 룰 `function-name-vs-return-semantic-mismatch` 강화** 누적 3+ PR.
+
+3. **property val vs computed property (`get()=`)** — *Kotlin 3 형태 (val 즉시 / get() 매 호출 / fun 명령형) 트레이드오프*. **MCP 룰 `property-val-vs-computed-property` 후보**.
+
+4. **Kotlin `by` delegation 권유 (PR #21 반대 시점)** — *delegation = Kotlin 어휘 정공* vs *PR #21 reviewer = 컬렉션처럼 쓰는 나쁜 습관*. **2 reviewer 의 반대 시점 = MCP `oop_propose_alternatives` 핵심 가치 합류 정점**.
+
+5. **반복문 의존 vs 수학적 풀이** — *Ace 1↔11 = while vs 단일 식*. 외부글 동반. **MCP 룰 `iterative-loop-vs-math-formula` 강화** ⭐⭐.
+
+6. **함수 합성 동치 = 추상화 의도 X** — *score - aceCount + aceCount = score = 함수 분리 비용만*. **MCP 룰 `function-decomposition-creates-identity` 후보**.
+
+7. **CQS (Command-Query Separation)** — *drawCount = count 가져옴 + 카드 뽑음 = 2 역할*. **MCP 룰 `command-query-separation` 후보**.
+
+8. **Stringly-typed → enum 비교** — *cardName.contains("A") → cardRank == ACE*. **MCP 룰 `stringly-typed-vs-enum-comparison` 후보**.
+
+9. **테스트 = 하드코드 검증 (production 코드 의존 X)** — *CardRank.values().size 의존 → 52 하드코드*. **MCP 룰 `test-hardcoded-vs-production-derived` 강화** 누적 3+ PR.
+
+10. **함수형 프로그래밍 학습 미션 어휘 (학습 목표 의식)** — *MutableList 회피 + Iterable 확장함수*. *학습 의도 의식*. **MCP 룰 `mutable-list-vs-functional-pipeline` 후보**.
+
+11. **Model = domain vs view (MVC 절대 원칙)** + **ViewMapper / 확장함수 2 안** — PR #21·#87 결 강화. **MCP 룰 `model-view-dependency-direction` 강화** ⭐⭐⭐.
+
+12. **`distinct()` vs `toSet()` 의도 = 순서 보존 여부** — **MCP 룰 `distinct-vs-toSet-intent` 후보**.
+
+13. **학생 자가 한계 인정 + 자가 힌트 요청** — *학습 적극성 모범*. *학습 = 시간 두고 반복* 어휘. PR #36·#87·#95·#98·#46·#73 결.
+
+14. **모든 25 스레드 학생 자가 답변 + 커밋 SHA 첨부** — *학생 자가 학습 가시화 정점*.
+
+15. **셀프 체크리스트 PR 본문 (2025 코호트 스타일)** — *체계화된 PR 본문 + 집중 리뷰 영역 명시*.
+
+16. **`protected` 자식 한정 가시성** — *Kotlin 어휘*. PR #87 결.
+
+17. **함수 인자 일관성** — *3 인자 중 1 만 외부 전달 = 비대칭*. **MCP 룰 `function-parameter-asymmetry` 후보**.
+
+18. **canHit 중복 호출 (Guard 중복)** — **MCP 룰 `redundant-guard-condition` 후보**.
+
+19. **클래스 이름과 멤버 이름 중복** — *Cards.cardsCount → Cards.count*. **MCP 룰 `member-name-includes-class-name` 후보**.
+
+20. **stateless 클래스 인스턴스화 vs companion object 정적** — *ScoreCalculator(cards) vs ScoreCalculator.calculate(cards)*. **MCP 룰 `stateless-class-vs-companion-object` 후보**.
+
+21. **부모 추상 메서드 반환 의미 자식 별 역방향** — *Dealer.turn = true (hit) vs Player.turn = true (종료)*. **MCP 룰 `method-return-semantic-asymmetry-between-subclasses` 후보**.
+
+22. **mutable 컬렉션 public 노출 (val MutableList)** — *backing property + 방어적 복사 정공*. **MCP 룰 `mutable-list-public-exposure` 강화** 누적 5+ PR.
+
+23. **양방향 reviewer/학생 토론 + 부분 거절 + reviewer 후속 답변** — *학생 자가 거절 이유 인정 + reviewer 대안 제시*. 누적 8+ PR.
+
+## 얻은 교훈 (도메인)
+
+1. **Ace 11 기본 + 수학적 단일 식** — `totalCardScore - 10 * aceCount.coerceAtMost((totalCardScore - BLACKJACK_SCORE) / 10 + 1)`. **MCP 룰 `ace-bonus-mathematical-vs-iterative` 후보**.
+
+2. **현실 메타포 = 카드뭉치에서 카드 꺼내서 플레이어 받는다** — *Player.receive(drawnCard: Card)* 정공.
+
+3. **Dealer 16 이하 자동 hit** — `DEALER_HIT_LIMIT = 16`. 블랙잭 표준 룰.
+
+4. **카드 중복 invariant + `toSet()` 검증** — *distinct() vs toSet() 의도 점검*.
+
+5. **VictoryStatus enum (WIN/LOSE/DRAW)** — *상수/문자열 → enum 변환*. PR #20·#28·#125 결.
+
+6. **`compareScores` `abs(BLACKJACK_SCORE - score)`** — *21에 가장 가까운 자가 승리 (블랙잭 룰 정확성)*. 다만 *블랙잭 표준 = bust 즉시 lose + 동점은 dealer 승*.
+
+→ **블랙잭 룰 와전 시점** — *abs 기반 비교* ≠ *21 정확 vs 21 미만 비교*. 학생 자가 점검 필요. **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 9+ PR.
+
+## MCP 룰 후보 신규 + 강화 (PR #117)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `metaphor-fidelity-locator` | 강화 | 8+ ⭐⭐⭐ |
+| `function-name-vs-return-semantic-mismatch` | 강화 | 3+ (#36·#117·#21) |
+| `property-val-vs-computed-property` | 신규 | 1 (#117) — Kotlin 어휘 |
+| `iterative-loop-vs-math-formula` | 강화 | 2+ (#117·#87) ⭐⭐ |
+| `function-decomposition-creates-identity` | 신규 | 1 (#117) |
+| `command-query-separation` | 신규 | 1 (#117) |
+| `stringly-typed-vs-enum-comparison` | 신규 | 1 (#117) |
+| `test-hardcoded-vs-production-derived` | 강화 | 3+ (#99·#26·#117) |
+| `mutable-list-vs-functional-pipeline` | 신규 | 1 (#117) |
+| `model-view-dependency-direction` | 강화 | 9+ ⭐⭐⭐ |
+| `distinct-vs-toSet-intent` | 신규 | 1 (#117) |
+| `function-parameter-asymmetry` | 신규 | 1 (#117) |
+| `redundant-guard-condition` | 신규 | 1 (#117) |
+| `member-name-includes-class-name` | 신규 | 1 (#117) |
+| `stateless-class-vs-companion-object` | 신규 | 1 (#117) |
+| `method-return-semantic-asymmetry-between-subclasses` | 신규 | 1 (#117) |
+| `mutable-list-public-exposure` | 강화 | 5+ |
+| `tuple-leak-vs-domain-dto` | 강화 | 3+ (#36·#87·#117) |
+| `is-vs-can-prefix-semantics` | 신규 | 2+ (#117·#21) |
+| `delegation-source-val-redundancy` | 신규 | 1 (#117) |
+| `view-mapper-vs-extension-function` | 신규 | 1 (#117) |
+| `decider-vs-tell-dont-ask` | 신규 | 1 (#117) |
+| `ace-bonus-mathematical-vs-iterative` | 신규 | 1 (#117) — 도메인 특수 |
+| `blackjack-rule-fidelity-comparison` | 강화 | 9+ ⭐⭐⭐ |
+
+## 메타 어휘 (13 reviewer + MCP 핵심 가치 합류 정점)
+
+- ***woowahan-dino (디노) = 13번째 reviewer*** — *MCP 핵심 가치 어휘 합류*.
+- ***현실 메타포 정합 어휘*** — woowahan-dino PR #117 — *"카드뭉치에서 카드 꺼내 플레이어 받는다"* — **MCP `oh-my-oop` 핵심 가치 (책임 분배 단계)**. PR #31·#21 결.
+- ***학습 의도 의식 어휘*** — woowahan-dino PR #117 — *"이번에 함수형 프로그래밍에 대해 학습하는 미션이니까"* — *미션의 학습 목표 의식*.
+- ***반복문 의존 vs 수학적 풀이*** — woowahan-dino PR #117 — *외부글 + 학생 자가 힌트 요청 + reviewer 후속 답변* 3 단계 학습 시점.
+- ***Model = domain vs view 의문 어휘*** — woowahan-dino PR #117 — *MVC 절대 원칙*.
+- ***학생 자가 부분 거절 + reviewer 후속 답변*** — parkjiminnnn / woowahan-dino — *학생 자가 거절 + reviewer 대안 제시* = **양방향 토론 정공**. PR #137·#151·#133·#146·#147·#87 결.
+- ***모든 25 스레드 학생 자가 답변 + 커밋 SHA 첨부*** — parkjiminnnn — *학습 가시화 정점*.
+- ***2025 코호트 스타일 (셀프 체크리스트 + 집중 리뷰 영역 명시)*** — *체계화된 PR 본문 + CI 자가 점검*. **2023·2024·2025 코호트 3 시기 합류**.
+
+→ **13 reviewer 누적 (말리빈/잭슨/페로로/지훈/krrong/vagabond95/BeokBeok/KwonDae/galcyurio/ghojeong/woowahan-leah/두루/woowahan-dino)** — *MCP `oh-my-oop` 핵심 가치 어휘 완전 합류 정점*.