oh-my-oop 0.2.0

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

@@ -0,0 +1,726 @@
+# PR #129 — [블랙잭 1단계] 비비 미션
+
+- **Reviewee:** [@rosemin928](https://github.com/rosemin928)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/129
+- **단계:** 1단계
+- **리뷰어:** [@KwonDae](https://github.com/KwonDae) (제이든) — 기존 reviewer (batch 12 신규 합류)
+- **라인 코멘트:** 22 스레드 — *Tell-Don't-Ask + 현실 메타포 정공 (게임 승패 = 외부 장치 X, 참가자 자가 결정) + 추상화 활용 점검 (개별 객체에 책임 위임 시 공통 사항 자가 발견) + sealed interface vs abstract class vs open class 학생 자가 학습 + Deck 테스트 가능성 + interface 분리 + 모든 22 스레드 학생 자가 답변 + 커밋 SHA 첨부 + 커뮤니케이션 메타 (줄글 vs 핵심 내용)*
+- **신규 reviewee** (2025년 코호트 — 모바일 안드로이드 7기, PR #117 와 동일 코호트).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 + 셀프 체크리스트 + 집중 리뷰 영역 명시 (2025 코호트 스타일)
+
+PR 본문 구조:
+- **셀프 체크리스트 7항목** (PR #117 와 동일).
+- **집중 리뷰 영역 자가 명시** *"인덴트 depth를 신경 써보면서 작성을 했지만 여전히 여러 부분에서 depth가 2를 넘겼습니다... 특히 BlackJackGame 클래스에서 playGame 함수에서 depth가 깊어지게 됐는데 이를 어떻게 분리해야 할 지 모르겠어서 수정하지 못했습니다."*
+
+→ **체계화된 PR 본문 모범 + 학생 자가 한계 인정** — *학습 적극성*. PR #117 결의 *2025 코호트 스타일*. PR #95·#98·#46·#73·#36·#87·#117 결의 *학생 자가 한계 인정* 어휘 합류.
+
+### 2. 모든 22 스레드 학생 자가 답변 + 커밋 SHA 첨부 + 자가 후속 의문
+
+22 스레드 전부 학생이 *반영 커밋 링크 (commit SHA)* 첨부 + **자가 후속 의문 5+ 회**:
+
+- Thread 1: *deal 여러 명 = `first()` vs `single()` vs `List<Dealer>` 자가 의문*.
+- Thread 5: *Participants 객체 생성 자가 적용 + Player ↔ Participants 분리 자가 설명*.
+- Thread 7: *승패 로직 Player 이동 자가 의문 (Participant vs Player 위치 토론)*.
+- Thread 10: *검증 코드 함수 분리 vs require 자가 의문 + Reviewer 답변 받음*.
+- Thread 22: *결과 로직 ResultCalculator 분리 자가 의문* (PR 본문 외 추가 의문).
+
+→ **학생 자가 학습 가시화 정점** + **자가 후속 의문 풍부** = *PR #117 (parkjiminnnn) 결의 *모든 스레드 commit 첨부* + *PR #133·#137·#148·#151·#146·#147 결의 *학생 자가 의문*** 결합.
+
+### 3. `Participants(dealer: Dealer, players: List<Player>)` 생성자 타입 분리
+
+```kotlin
+class Participants(
+    val dealer: Dealer,
+    val players: List<Player>,
+) {
+    fun getChoice(deck: Deck, getPlayerChoice: ..., onPlayerStateUpdated: ...) {
+        players.forEach { player -> player.choice(deck, getPlayerChoice, onPlayerStateUpdated) }
+    }
+}
+```
+
+→ **딜러/플레이어 생성자 타입 분리 = 컴파일러 강제** — *List<Participant> + first() 분리 vs 생성자 타입 분리*. **MCP 룰 `compile-time-singleton-vs-runtime-filter` 후보**.
+
+학생 자가 적용 (Thread 11·12):
+- `Participants(participants: List<Participant>)` → `filter { it is Dealer }.first()` (학생 초안)
+- `Participants(dealer: Dealer, players: List<Player>)` (학생 자가 적용)
+
+reviewer 후속 (Thread 12): *"생성자 프로퍼티 선언이 현재 유의미하게 사용되고 있을까요?"* → 학생 자가 깨달음: *"불필요한 변수가 된다는 것을 깨달았습니다"*.
+
+### 4. `ParticipantCards` 객체 분리 — Participant god-object 회피
+
+```kotlin
+class ParticipantCards(private val _cards: MutableList<TrumpCard> = mutableListOf()) {
+    val allCards: List<TrumpCard> get() = _cards.toList()
+    val sumOfCards: Int get() = _cards.sumOf { it.tier.values }
+
+    fun add(card: TrumpCard) { _cards.add(card) }
+    fun hasAce(): Boolean = _cards.any { it.tier == CardTier.ACE }
+    fun size(): Int = _cards.size
+}
+```
+
+→ **카드 책임 객체 분리** — reviewer (Thread 6) *"Participant가 하는 일이 다소 많아 보이네요..! 딜러, 참가자 모두 자신들의 카드를 들고 있으니 이 또한 객체로 취급해볼 수 있을까요?"* → 학생 자가 적용.
+
+**god-object 회피 + 책임 분리** PR #145·#80·#76·#82·#107·#46·#16·#73·#36·#87 결.
+
+다만 **`val allCards: List<TrumpCard> get() = _cards.toList()` 외부 노출** + **`Participant.getAllCards(): List<TrumpCard> = cards.allCards`** = *2단계 위임 + 외부 노출* → §디미터 법칙 가능.
+
+### 5. `Participant abstract class` + Dealer/Player 추상 메서드 3개
+
+```kotlin
+abstract class Participant(val cards: ParticipantCards) {
+    abstract fun showInitialCards(): List<TrumpCard>
+    abstract fun isDrawable(): Boolean
+    abstract fun getResult(other: Participant): GameResult
+    
+    fun receiveCard(card: TrumpCard) { cards.add(card) }
+    fun isBust(extraScore: Int = ACE_HARD_SCORE): Boolean = cards.sumOfCards + extraScore > BUST_STANDARD
+    fun finalScore(): Int = ...
+}
+```
+
+→ **추상 메서드 3종 + 공통 로직 finalScore/isBust/receiveCard** — *진정한 추상화*:
+
+#### 5.1. *3 추상 메서드 = 다형성*
+
+- `showInitialCards()`: *Dealer 1장 / Player 2장 (도메인 룰)*.
+- `isDrawable()`: *Dealer 16 이하 / Player 21 이하 (도메인 룰)*.
+- `getResult(other)`: *Dealer 관점 / Player 관점 (대칭 역방향)*.
+
+학생 자가 학습 (Thread 8·15·16): *abstract class 선택 + Dealer/Player 공통 로직 추출*.
+
+#### 5.2. *공통 로직 finalScore/isBust/receiveCard = 부모 클래스*
+
+부모 클래스가 *공통 로직 보유 + 자식이 *추상 메서드* 만 차이*. **추상화 정공**.
+
+PR #87·#36·#16·#73·#80·#82·#107 결.
+
+### 6. 카드 공개 (`showInitialCards`) = 비즈니스 로직 자가 이동
+
+reviewer (Thread 13):
+
+> *"이부분을 깊게 고민해볼 필요가 있어요 🧐 `딜러는 첫번째 카드를 공개해야 한다` 는 비즈니스 로직일까요 Controller 로직일까요? 참가자와 딜러가 `카드를 공개한다` 라는 공통 로직에 대해 지금까지 구현한 것 처럼 참가자와 딜러의 행동을 추상화가 가능할겁니다"*
+
+학생 자가 적용: *"카드를 N장 공개한다는 로직은 비즈니스 로직이라고 생각하여 Participant 내로 옮겼습니다! 첫 카드를 공개할 때 플레이어는 2장을, 딜러는 1장을 공개하도록 수정했습니다!"*
+
+→ **비즈니스 로직 vs Controller 로직 구분 + 자가 추상화** — *Controller 가 *Dealer.cards.take(1) + Player.cards.take(2)* 외부 처리 → *Participant.showInitialCards() 다형성*.
+
+**MCP 룰 `business-logic-vs-controller-logic` 후보** — *비즈니스 vs 컨트롤러 위치 트레이드오프*.
+
+### 7. 추가 칭찬
+
+- *Thread 4*: *"View로직을 갖지 않게 enum 을 잘 구성해주셨네요"* (Shape).
+- *Thread 17*: *"고차함수 활용 👍"* (Player.choice).
+- *Thread 19*: *"명시적인 테스트명과 세세하게 테스트를 항목을 구성해주셨네요 👍"*.
+- *Thread 21*: *"추상화 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. 딜러 여러 명 논리오류 + `first()` vs `single()` vs 생성자 타입 분리
+
+reviewer (Thread 1·11):
+
+> *"이렇게 되면 딜러가 여러명일 때 논리오류 대응이 가능할까요?"*
+
+학생 자가 답변:
+
+> *"게임에서 딜러가 여러 명일 경우는 없을거라고 생각해서 다음과 같이 작성했었습니다…! 실제 게임에서는 딜러가 한 명이어도 만약의 경우를 생각해서 List<Dealer>로 코드를 작성하는게 좋을까요? 또, 이번에 이에 대해 고민해보면서 `first()` 대신 `single()`을 사용해서 딜러가 한 명인 것을 강제하고 그렇지 않을 때는 예외를 던지는 방법도 있다는 것을 알게 되었습니다."*
+
+reviewer (Thread 11):
+
+> *"지난 로또 미션에서도 로또 번호는 중복이 될 수 없기에 어떻게 처리를 해줘야 하는지 기억하시나요? 지금 구조에서는 그와 동일한 상황이라고 생각했어요!*
+>
+> *두가지 방법이 있을 것 같아요. - Paricipants 생성자에서 타입 분리(dealer, player) - 내부 프로퍼티에서 검증(예외던지기? singleOrNull?) 어느 방법이 좋을지 고민해보시고 알려주세요!"*
+
+학생 자가 적용: *생성자 타입 분리*.
+
+→ **invariant 강제 시점 3 가지**:
+
+| 안 | 시점 | 장점 | 단점 |
+|---|---|---|---|
+| `List<Participant>.first()` (학생 초안) | *호출 시* | *간결* | *invariant 위반 시 silent + 의미 누수* |
+| `List<Participant>.single()` | *호출 시 + 예외* | *invariant 명시 + 예외 던짐* | *런타임 검증 + 호출 매번 비용* |
+| 생성자 타입 분리 (`Participants(dealer, players)`) | *컴파일 시* | *invariant 강제 + 호출자가 의미 알기 쉬움* | *Participant 추상화 일부 약화* |
+
+→ **MCP 룰 `compile-time-singleton-vs-runtime-filter` 후보** — *invariant 강제 시점 트레이드오프*. PR #79·#92·#48·#39 결의 *invariant 강제 시점*.
+
+### 2. ktlint 통과 X — 도구 안내
+
+reviewer (Thread 2):
+
+> *"ktlint 확인해주세요!"* (이미지 첨부)
+
+학생: *"넵 감사합니다!!"*
+
+→ **CI 도구 자가 점검**. PR #87 결 강화.
+
+### 3. `String` → `UserChoice` enum 반환
+
+reviewer (Thread 3):
+
+> *"String대신 UserChoice 를 반환하는건 어떨까요?"*
+
+학생 자가 적용.
+
+→ **Stringly-typed → enum 변환** — *컴파일러 강제 + 의미 명시*. PR #117·#20·#28·#125 결.
+
+### 4. `Players` 일급 컬렉션 + 자가 행동 — depth 깊이 분리
+
+reviewer (Thread 5):
+
+> *"현재 객체들을 잘 생성해주시고 분리를 해주셨는데 만약 Players 라는 일급컬렉션이 존재한다면 해당 객체 내에서 스스로 행동할 수 있지 않을까요?"*
+
+학생 자가 적용: *Participants 객체 생성 + 로직 분리*.
+
+→ **일급 컬렉션 = depth 분리 + Tell-Don't-Ask** — *playGame 함수 depth = Players/Participants 가 자가 처리*. PR #21·#74·#108·#46·#36·#117 결.
+
+### 5. 게임 승패 = 외부 장치 vs 참가자 자가 결정 — Tell-Don't-Ask + 현실 메타포
+
+reviewer (Thread 7):
+
+> *"게임의 승패를 결정해주는건 외부 장치가 해주는걸까요?*
+> *실제 게임을 생각해보면, 외부 장치로 게임 승패를 결정하는게 아닌, 딜러와 참가자가 스스로 판단하게 됩니다.*
+> *`Participant 가 힌트가 되겠네요!`"*
+
+학생 자가 적용: *Player 로 승패 로직 이동* (다만 *Player 가 자가 결정 + Dealer 가 반대 받음* 자가 의문 발생).
+
+reviewer 후속 (Thread 14):
+
+> *"`내 점수와 상대 점수를 비교하여 결과를 판단한다`는 참가자와 딜러의 공통 로직입니다. 다만, 그 기준이 다를뿐일거에요. 지금까지 추상화를 진행한 이유에 대해 고민해보시죠!*
+>
+> *추상화를 진행하게 된다면 Controller입장에서는 `Participant` 가 참가자인지, 딜러인지 알 필요없이 `Participant` 에게 결과를 판단하라고 메세지만 던지면 됩니다"*
+
+학생 자가 적용: *각각 참가자가 승패를 계산* (Dealer.getResult / Player.getResult 추상 메서드).
+
+→ **Tell-Don't-Ask + 현실 메타포 + 추상화 활용 점검**:
+
+#### 5.1. *3 단계 학습*
+
+1. **외부 장치 (GameResultDecider) → Player 로 이동** (학생 1차 자가 적용).
+2. **Player 만 자가 결정 + Dealer 반대 받음 → 복잡 자가 의문**.
+3. **Player + Dealer 모두 자가 결정 (`Participant.getResult` 추상)** (학생 2차 자가 적용).
+
+#### 5.2. *현실 메타포 어휘*
+
+reviewer *"외부 장치로 게임 승패를 결정하는게 아닌, 딜러와 참가자가 스스로 판단하게 됩니다"* = **현실 메타포 정합**. PR #117·#31·#21 결.
+
+**MCP 룰 `metaphor-fidelity-locator` 강화** ⭐⭐⭐ — 누적 9+ PR.
+
+#### 5.3. *추상화 활용 점검 어휘*
+
+reviewer *"지금까지 추상화를 진행한 이유에 대해 고민해보시죠!"* = **학습 의도 회수 어휘**.
+
+**MCP 룰 `abstraction-purpose-revisit` 후보** — *추상화를 진행한 이유 회수*.
+
+### 6. `sealed interface vs abstract class vs open class` — Kotlin 어휘
+
+reviewer (Thread 8):
+
+> *"- sealed interface*
+> *- abstract class*
+> *- open class*
+> *이 세가지의 차이점과 용도는 어떻게 될까요? 고민해보시고 블랙잭 미션에서는 어떤 키워드가 어울릴지 고민해보시고 저에게도 공유해주세요!"*
+
+학생 자가 답변:
+
+> *"abstract class와 sealed interface 모두 추상화를 제공하지만, abstract class는 공통된 로직을 미리 구현하여 하위 클래스에서 재사용할 수 있도록 강제하는 반면, interface는 구현해야 할 틀만 제공하고, 모든 로직을 하위 클래스에서 직접 작성해야 한다는 차이가 있습니다. open class는 일반 클래스를 어디서든 상속 가능하도록 하지만 그렇기 때문에 의도를 잘못 이해했다면 잘못된 방식으로 기능이 변경될 위험이 있다고 알고 있습니다."*
+
+→ **Kotlin 어휘 3 가지 트레이드오프**:
+
+| 키워드 | 의도 | 적합 시점 |
+|---|---|---|
+| `sealed interface` | *알려진 자식 한정 + 다형성 분기 (when exhaustive)* | *자식이 한정 + 상태/이벤트 표현* (Bust/Normal/Blackjack 같은 State) |
+| `abstract class` | *공통 로직 + 추상 메서드* | *자식 공통 로직 + 차이는 추상 메서드 (Participant)* |
+| `open class` | *상속 허용 (의도 약함)* | *드물게 사용 + Java 호환* |
+
+학생 최종 선택: **`abstract class Participant`** — *공통 로직 (finalScore, isBust, receiveCard) + 추상 메서드 (showInitialCards, isDrawable, getResult)*. **정확한 의도 매핑**.
+
+**MCP 룰 `sealed-vs-abstract-vs-open-locator` 후보** — *Kotlin 키워드 선택 트레이드오프*. PR #98·#36·#147·#93·#136 결의 *sealed vs enum vs abstract* 변형.
+
+### 7. `Deck` 테스트 가능성 + `interface` 분리
+
+reviewer (Thread 9):
+
+> *"현재 Deck의 비즈니스 로직은 테스트가 가능할까요? 예를 들어, `특정 순서의 카드의 덱에서 순서대로 뽑으면 의도한 카드가 나와야한다` 를 테스트가 가능할까요?"*
+
+학생 자가 답변: *"전부 private으로 처리되어 있어서 테스트가 불가하네요... interface로 랜덤으로 섞인 카드와 테스트용으로 순서대로 카드 뭉치를 생성하도록 하여 테스트가 가능하도록 했습니다!"*
+
+→ **테스트 가능성 = 객체 설계 지표** (PR #87 *테스트 = 객체 설계 명세서* 결 강화):
+
+#### 7.1. *Deck = interface 분리*
+
+```kotlin
+interface Deck { fun pop(): TrumpCard }
+class RandomDeck : Deck { ... }     // production
+class FixedDeck : Deck { ... }       // test (순서대로)
+```
+
+→ **테스트 가능성을 위한 interface 분리** + **production vs test 의 별도 구현**. *의존성 역전 (DIP)*.
+
+**MCP 룰 `interface-for-test-substitution` 후보** — *테스트 가능성을 위한 interface 분리*. 누적 4+ PR.
+
+#### 7.2. *Singleton Deck 회피 vs interface 분리 양가*
+
+PR #20·#28·#125·#65·#92·#108 결의 *Singleton Deck (companion object MutableSet)* 안티패턴 회피 → *interface + DI 정공*.
+
+### 8. `if (names.contains(EMPTY))` true/false 의미 → 직관 로직
+
+reviewer (Thread 10):
+
+> *"비비의 의도는 함수를 사용해 가독성을 높이는걸로 이해했는데요, 해당 함수가 갖는 true/false의 의미를 찾기보다 직관적으로 이해할 수 있게 로직 구성도 가능합니다!"*
+
+학생 자가 적용 + 자가 후속 의문 (검증 코드 함수 분리 vs require + 줄글 vs 핵심).
+
+reviewer 후속 답변:
+
+> *"- 검증코드를 함수로 분리하는게 좋을지?*
+> *- 도메인에서 검증할 때 require 로 검증할지? or 함수로 분리할지?*
+> *로 정리가 될 것 같은데요 🥲*
+> *일단, 첫번째 질문은 함수를 읽을 때 내부 구현까지 알 필요가 없다면 직관성이 좋은 함수로 분리하는게 좋다고 생각해요. 사실 내부에서 어떤 규칙으로 검증하는지 까진 관심이 없어도 된다면, 함수로 ~~검증을 한다 정도만 알려줘도 무방하기 때문입니다.*
+>
+> *두번째는 require 에서 검증할 때는 로직의 복잡도에 따라 다를 것 같은데요, 굳이 함수로 분리해야 하나? 싶기도 합니다. 보통 require에서는 하나의 로직에 대해 검증하기에 여러 로직이 합쳐지지 않을거라고 생각되네요"*
+
+→ **검증 코드 분리 트레이드오프 + 도메인 require 어휘**:
+
+#### 8.1. *검증 함수 분리 시점*
+
+- 함수 분리: *내부 구현 알 필요 X + 의도 명시* (예: `validateNonEmpty(names)`).
+- inline: *간결 + 로직 1 가지만 + require 자가 적용*.
+
+#### 8.2. *Boolean 함수명 = true/false 의미*
+
+학생 초안 (예시):
+```kotlin
+if (validateNames(names)) {
+    return names
+}
+```
+
+→ *`validateNames` 가 true/false 어느 것을 의미? = 가독성 모호*. **MCP 룰 `boolean-function-name-ambiguity` 후보** — *Boolean 함수명 = true/false 의미 명시*.
+
+### 9. 커뮤니케이션 메타 (줄글 vs 핵심 내용) — reviewer 메타 어휘
+
+reviewer (Thread 10 후속):
+
+> *"조금 도움이 되었으면 하는 마음에 조심스럽게 말씀드려봅니다 🙃*
+> *우테코 미션을 진행하는 것을 넘어 이후 현업에서도 커뮤니케이션 비용 줄이기에 대해 많은 사람들이 고민을 하는데요.*
+> *예를 들어, 비비가 주신 질문을 줄글로 주셔도 좋지만, 핵심 내용을 간략하게 전달하는 것 또한 중요하다고 생각해요.*
+> *앞으로 리뷰어들과 많은 소통을 하실 때 이부분도 함께 고려하신다면 비비의 커뮤니케이션 능력 또한 향상될겁니다!"*
+
+학생: *"앞으로의 리뷰에서 피드백 주신 점 반영하여 핵심 내용을 보기 좋게 적어보도록 하겠습니다!"*
+
+→ **reviewer 가 커뮤니케이션 메타 어휘 명시** = *코드 외 학습 영역 + 학생 미래 커리어 의식*. **MCP `oh-my-oop` 핵심 가치 합류 (커뮤니케이션 비용)**.
+
+PR #87 *"동료 개발자가 이런 부분을 궁금해할 수도 있구나"* 결 + PR #76·#80·#107 결의 *동료 개발자 시점* 어휘 합류.
+
+### 10. `참가자는 본인 스스로 Hit 가능한지 알 수 있다` — 추상화 활용 점검
+
+reviewer (Thread 15):
+
+> *"`참가자는 본인 스스로 Hit 가능한지 알 수 있다` 는 Player, Dealer 의 공통 사항이 아닐까요? 단지 Hitable 한지 기준이 다를뿐입니다. 추상화 활용에 대해 고민해보시죠 🧐"*
+
+학생 자가 적용 (`isDrawable` 추상 메서드 추가):
+
+```kotlin
+abstract class Participant {
+    abstract fun isDrawable(): Boolean
+}
+
+class Dealer : Participant {
+    override fun isDrawable(): Boolean = ... // 16 이하
+}
+
+class Player : Participant {
+    override fun isDrawable(): Boolean = ... // 21 이하
+}
+```
+
+학생 자가 깨달음: *"플레이어의 hitable 여부는 `isBust`가 아니라 `!isBust`여서 사용되는 방식이 아예 반대라는 것을 알았습니다... 시간에 쫓겨 작업하느라 미처 확인하지 못한 부분이었던 것 같아요…"*
+
+→ **추상화 활용 = 공통 사항 → 추상 메서드** + **학생 자가 한계 인정** (시간 압박 인정).
+
+**MCP 룰 `abstraction-as-shared-behavior-discovery` 후보** — *공통 사항 → 추상 메서드 변환*.
+
+### 11. `open class` vs `abstract class` 의미 점검 (추상 메서드 없을 시)
+
+reviewer (Thread 16):
+
+> *"`Dealer, Player` 클래스 의 코멘트들과 이어지는 코멘트입니다.*
+> *현재 구조에서 open class 로 선언해도 달라지는게 없는 이유가 무엇일까요?"*
+
+학생 자가 답변:
+
+> *"현재 Participant는 추상 메서드를 포함하고 있지 않아 추상화는 이루어지지 않고, 단순히 공통된 로직을 플레이어와 딜러에서 재사용하도록 만든 구조이기 때문에 실질적으로는 open class로 선언한 것과 다른게 없는 것 같아요...!*
+>
+> *로직 중 추상화를 통해 가지고 있을 수 있는 부분이 충분히 많은데도 잘 활용하고 있지 못했던 것 같습니다. 이 부분을 abstract class를 좀 더 활용할 수 있도록 이번 리뷰들을 반영하여 수정했습니다!"*
+
+→ **`abstract class` vs `open class` = 추상 메서드 유무**. *추상 메서드 없는 abstract class = open class 와 사실상 동치*. 
+
+**Kotlin 어휘 깊은 학생 자가 깨달음**. PR #117 *property val vs computed property* 결의 *Kotlin 어휘 자가 학습* 변형.
+
+**MCP 룰 `abstract-without-abstract-method` 강화** — 누적 5+ PR (#95·#36·#117·#129·#147).
+
+### 12. `Deck.pop` 예외 처리 — 게임 종료 흐름
+
+reviewer (Thread 20):
+
+> *"그럴 확률은 적겠지만, 만약 더이상 카드를 뽑지 못한다면 Exception이 발생하여 프로그램이 그대로 종료될거에요. 현실에서 게임을 구현한다면 게임을 끝내 중간 결과를 출력하거나, 안내문구를 출력하고 프로그램을 로직상 종료하는 흐름은 어떨까요?"*
+
+reviewer 후속:
+
+> *"`deck.pop` 로직을 수정하라는게 아닌, 이 함수를 호출할 때 어떤점을 고려해야 하는지에 대해 고민해보셨으면 합니다 :)"*
+
+→ **예외 처리 vs 로직 종료 흐름** — *Exception 던지기 = 프로그램 종료* vs *Exception 잡아서 게임 끝내 + 안내문구*. **MCP 룰 `exception-vs-graceful-shutdown` 후보**.
+
+### 13. `Player.allCards 에 직접 접근` — Tell-Don't-Ask
+
+reviewer (Thread 18):
+
+> *"allCards 에 직접 접근하기보다 `참가자의 덱에서 몇장 꺼내올 수 있다` 로직을 수행해보는건 어떨까요?"*
+
+→ **Tell-Don't-Ask** — *Participant.cards.allCards.take(N) 외부 처리* → *Participant.takeFirstN(n: Int) 메시지*. **MCP 룰 `external-take-vs-domain-method` 후보**.
+
+다만 *`showInitialCards()` 자가 적용* (Player 2장 / Dealer 1장) = *이미 정공*. reviewer 의 *추가 시점*.
+
+### 14. `Dealer.isDrawable()` `Player.isDrawable()` 의미 반대 — 추상화 의도 약함
+
+```kotlin
+// Dealer.isDrawable() = sum < 16  (draw 가능 = 16 미만)
+// Player.isDrawable() = sum <= 21 (draw 가능 = 21 이하)
+```
+
+→ *조건 의미는 *공통: hit 가능 시 true* + *기준만 차이*. 다만 **`isDrawable` 와 `!isBust` 양가성**:
+
+- Dealer.isDrawable() ≠ !isBust() (16 < score ≤ 21 도 isBust X, isDrawable X).
+- Player.isDrawable() ≈ !isBust() (소프트 21 한정).
+
+학생 자가 깨달음 (Thread 15) = *Player.isDrawable = !isBust ≠ isBust*. **이름과 의미 일관성**.
+
+PR #117 (isHit → canHit) 결의 *이름 의미 정확성* 변형.
+
+### 15. `Dealer.getResult` vs `Player.getResult` — 대칭 코드 + 양방향 호출 위험
+
+```kotlin
+// Player.getResult(other: Participant): GameResult
+override fun getResult(other: Participant): GameResult = when {
+    this.isBust() -> GameResult.LOSE
+    other.isBust() && !this.isBust() -> GameResult.WIN
+    myScore > otherScore -> GameResult.WIN
+    ...
+}
+
+// Dealer.getResult(other: Participant): GameResult
+override fun getResult(other: Participant): GameResult = when {
+    other.isBust() -> GameResult.WIN
+    this.isBust() && !other.isBust() -> GameResult.LOSE
+    ...
+}
+```
+
+→ **대칭 코드 = Dealer 와 Player 각자 *자가 결정***. 다만 **`isBust` 양가성**:
+
+- Dealer.getResult(player): *other (Player) isBust → Dealer WIN*.
+- Player.getResult(dealer): *other (Dealer) isBust + !this.isBust → Player WIN*.
+
+→ *각자 자가 결정 = Tell-Don't-Ask 정공*. 다만 *`participant1.getResult(participant2)` 와 `participant2.getResult(participant1)` 양방향 호출 가능* → *항상 부호 반전 인지 필요*.
+
+대안: **`Participant.compareWith(other): GameResult`** 추상 + *부호 반전 1 자리* (PR #36 `operator fun not()` 결).
+
+**MCP 룰 `symmetric-getResult-vs-compareWith` 후보**.
+
+### 16. 결과 계산 책임 + 현실 메타포 (학생 자가 의문)
+
+학생 자가 의문 (Thread 22):
+
+> *"그래서 관련 로직을 또 다른 객체로 분리하여 (예를 들면 결과 로직을 모아서 resultCalculator) 가지게 하는게 좋을까? 하는 고민을 했었습니다. 이에 대해 제이든은 어떻게 생각하시는지 궁금합니다!"*
+
+reviewer:
+
+> *"결국에 결과를 계산하는건 누구의 역할일까? 를 고민해보시면 좋을 것 같아요. 또한, 현실세계에 도입해서 블랙잭 게임을 할 때 외부 장치로 결과를 계산하는가를 생각해보셔도 좋습니다. 충분히 고민해보시고 해결이 안되는 부분이 있다면 말씀주세요 :)"*
+
+→ **현실 메타포 + 학생 자가 학습 권유** — *§5 결의 *외부 장치 X = 참가자 자가 결정* 일관*. **MCP `oh-my-oop` 핵심 가치 합류 정점**.
+
+### 17. `BlackJackGame.calculateDealerResult` + `calculatePlayerResult` Controller-like 누수
+
+```kotlin
+fun calculateDealerResult(action: (Map<GameResult, Int>) -> Unit) {
+    val dealerMap = GameResult.entries.associateWith { 0 }.toMutableMap()
+    participants.players.forEach { player ->
+        val result = participants.dealer.getResult(player)
+        dealerMap[result] = dealerMap.getOrDefault(result, 0) + 1
+    }
+    action(dealerMap)
+}
+```
+
+→ **BlackJackGame 이 `Map<GameResult, Int>` 누적 + 외부 action 호출** = *callback 람다 = View 결합* (PR #36·#137 결).
+
+대안: **`Participants.calculateDealerResults(): Map<GameResult, Int>` 메서드 + Controller 가 결과 받아서 View 처리** — *callback 람다 X*.
+
+**MCP 룰 `callback-action-for-result-aggregation` 후보** — *결과 누적 callback vs return*. PR #36 (callback-lambda-view-cost) 결.
+
+### 18. `processDealerTurn(): Int` `count` 반환 — 의미 모호
+
+```kotlin
+fun processDealerTurn(): Int {
+    var count = 0
+    while (participants.dealer.isDrawable()) {
+        participants.dealer.receiveCard(deck.pop())
+        count++
+    }
+    return count
+}
+```
+
+→ **`Int` 반환 = 의미 모호**. *processDealerTurn 의 결과가 *카드 뽑은 횟수* 임을 인지 어려움*. 
+
+대안:
+- `data class DealerTurnResult(val drawCount: Int)`.
+- `fun processDealerTurn(onDrawn: () -> Unit)` (callback).
+
+**MCP 룰 `primitive-return-without-domain-meaning` 후보** — *원시 타입 반환 = 의미 누수*. PR #36·#21 결.
+
+### 19. `BlackJackGame.handOutInitializedCards(initializedCardCount: Int = INITIAL_CARD_COUNT)` 기본 인자 양가
+
+```kotlin
+fun handOutInitializedCards(initializedCardCount: Int = INITIAL_CARD_COUNT) {
+    (participants.players + participants.dealer).forEach { player ->
+        repeat(initializedCardCount) { player.receiveCard(deck.pop()) }
+    }
+}
+```
+
+→ **기본 인자 + 호출 시 외부 인자 (테스트 한정?)** = *production 호출 시 인자 생략 + 테스트 시 인자 전달*. **production vs test 의 양방향 인터페이스**.
+
+다만 *Dealer 도 2장 받음* = *Dealer 의 도메인 룰 = 첫 카드만 공개 (showInitialCards)* 의 *카드 수신 = 모두 2장* 와 *공개 = 1장* 분리. 
+
+학생의 분리 시점:
+- 카드 수신: 모두 2장 (`handOutInitializedCards`).
+- 공개: Dealer 1장 / Player 2장 (`showInitialCards`).
+
+→ **수신 vs 공개 분리 = 도메인 룰 정확**. PR #117 결의 *카드뭉치에서 꺼내서 플레이어 받는다* 결.
+
+### 20. `Dealer.DEALER_MAX_SCORE = 16` — 16 매직 넘버 회피
+
+```kotlin
+companion object {
+    private const val DEALER_MAX_SCORE = 16
+    private const val DEALER_INITIAL_CARD_COUNT = 1
+}
+```
+
+→ **매직 넘버 16 → 상수 명명**. PR #117 (DEALER_HIT_LIMIT) 결. 
+
+다만 *`DEALER_MAX_SCORE = 16` 명명 양가* = *Dealer 최대 점수 = 16? Dealer hit 한계 = 16?*. **이름 의미 정확성**:
+
+- `DEALER_HIT_THRESHOLD = 16` (16 이하 hit).
+- `DEALER_STAY_THRESHOLD = 17` (17 이상 stay).
+
+학생의 `<` 비교 (`cards.sumOfCards < DEALER_MAX_SCORE`) = *16 미만 hit* → *17 = stay* (블랙잭 룰).
+
+다만 `<` 시 *16 시 stay* → *블랙잭 룰 = 16 시 hit 인지 stay 인지 도메인 확인 필요*. 
+
+**블랙잭 표준 룰**: Dealer 16 이하 hit (16 시 hit). → 학생 코드 `cards.sumOfCards < 16` 시 *16 시 hit X = 룰 와전*.
+
+→ **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** — *< vs ≤ 점검*. 누적 10+ PR ⭐⭐⭐.
+
+### 21. `Participant.finalScore` Ace Soft 1↔11 — 단일 +10 룰 (PR #36 결)
+
+```kotlin
+fun finalScore(): Int =
+    if (cards.hasAce() && !isBust(ACE_SOFT_SCORE)) {
+        cards.sumOfCards + ACE_SOFT_SCORE
+    } else {
+        cards.sumOfCards
+    }
+```
+
+→ **Ace 1 기본 + 단일 +10 룰** (PR #36 결의 *단일 +10*).
+
+**Ace 2장 이상 처리 X** — *Ace 1장 = 1+10=11, Ace 2장 모두 11 시 22 > 21 = soft Ace 적용 X (단일 +10)*. 
+
+PR #117 (수학적 풀이) 결의 *Multi-Ace 정확 처리* vs 현재 안 *단일 +10*. **트레이드오프**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 단일 +10 (현재) | *간결 + Ace 1장 한정 정확* | *Ace 2장 이상 정확 X* |
+| Multi-Ace 수학적 (PR #117 후속) | *모든 Ace 정확* | *공식 복잡* |
+| while + 차감 (안티패턴) | *Multi-Ace OK* | *반복문 의존* |
+
+**MCP 룰 `ace-bonus-single-vs-multi` 강화** — 누적 2+ PR (#36·#129).
+
+### 22. `Participants` `getChoice(deck, getPlayerChoice, onPlayerStateUpdated)` 람다 2개
+
+```kotlin
+fun getChoice(
+    deck: Deck,
+    getPlayerChoice: (String) -> Boolean,
+    onPlayerStateUpdated: (Player) -> Unit,
+) {
+    players.forEach { player -> player.choice(deck, getPlayerChoice, onPlayerStateUpdated) }
+}
+```
+
+→ **콜백 람다 2개 = call site 인지 부담 ↑** (PR #36 결).
+
+다만 *Participants.getChoice = 단순 위임 (player.choice 호출)* = *추가 책임 없음*. **MCP 룰 `simple-delegation-method-unnecessary` 후보** — *단순 위임 메서드 = 추가 책임 X = 메서드 인공*.
+
+PR #87 (Participant.getName, getCards 위임 6 개) 결 동일.
+
+## 리뷰어 의견 요지
+
+- **현실 메타포 = 게임 승패 외부 장치 X, 참가자 자가 결정** — *Tell-Don't-Ask + 현실 정합*.
+- **추상화 활용 점검 = 공통 사항 + 기준 다름** — *지금까지 추상화를 진행한 이유 회수*.
+- **딜러 여러 명 논리오류 + invariant 강제 시점 3 안** — *first / single / 생성자 타입 분리*.
+- **sealed interface vs abstract class vs open class** — *Kotlin 어휘 자가 학습*.
+- **Deck 테스트 가능성 + interface 분리** — *DIP*.
+- **검증 코드 함수 분리 vs require 트레이드오프** — *내부 구현 알 필요 X 시 함수 분리*.
+- **커뮤니케이션 메타 (줄글 vs 핵심 내용)** — *코드 외 학습 영역 + 학생 미래 커리어 의식*.
+- **카드 공개 = 비즈니스 로직 vs Controller 로직** — *Participant 내로 이동 + 다형성*.
+- **deck.pop 예외 처리 = 게임 종료 흐름** — *프로그램 종료 vs 안내문구 후 종료*.
+- **`if (validateNames)` true/false 의미** → *직관 로직*.
+- **Participants 생성자 프로퍼티 유의미 사용 점검** — *불필요한 변수 자가 깨달음*.
+- **`open class` = abstract method 없는 abstract class 동치 점검** — *Kotlin 어휘 학생 자가 학습*.
+- **`Player.allCards` 직접 접근 → `takeFirstN` 메시지** — *Tell-Don't-Ask*.
+- **이미 칭찬한 부분** — View 로직 없는 enum / 고차함수 활용 / 명시적 테스트명 / 추상화.
+
+## 대표 인용
+
+> [KwonDae]
+> *"게임의 승패를 결정해주는건 외부 장치가 해주는걸까요? 실제 게임을 생각해보면, 외부 장치로 게임 승패를 결정하는게 아닌, 딜러와 참가자가 스스로 판단하게 됩니다."*
+
+→ **현실 메타포 + Tell-Don't-Ask 어휘**. PR #117·#31·#21 결.
+
+> [KwonDae]
+> *"`내 점수와 상대 점수를 비교하여 결과를 판단한다`는 참가자와 딜러의 공통 로직입니다. 다만, 그 기준이 다를뿐일거에요. 지금까지 추상화를 진행한 이유에 대해 고민해보시죠!*
+>
+> *추상화를 진행하게 된다면 Controller입장에서는 `Participant` 가 참가자인지, 딜러인지 알 필요없이 `Participant` 에게 결과를 판단하라고 메세지만 던지면 됩니다"*
+
+→ **추상화 활용 점검 + 학습 의도 회수** 어휘. **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+
+> [KwonDae]
+> *"우테코 미션을 진행하는 것을 넘어 이후 현업에서도 커뮤니케이션 비용 줄이기에 대해 많은 사람들이 고민을 하는데요. 예를 들어, 비비가 주신 질문을 줄글로 주셔도 좋지만, 핵심 내용을 간략하게 전달하는 것 또한 중요하다고 생각해요."*
+
+→ **커뮤니케이션 메타 어휘** — *코드 외 학습 영역 + 학생 미래 커리어 의식*.
+
+> [KwonDae]
+> *"두가지 방법이 있을 것 같아요. - Paricipants 생성자에서 타입 분리(dealer, player) - 내부 프로퍼티에서 검증(예외던지기? singleOrNull?) 어느 방법이 좋을지 고민해보시고 알려주세요!"*
+
+→ **N 안 + 학생 선택지** 어휘. **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+
+> [rosemin928 자가 답변]
+> *"플레이어의 hitable 여부는 `isBust`가 아니라 `!isBust`여서 사용되는 방식이 아예 반대라는 것을 알았습니다... 시간에 쫓겨 작업하느라 미처 확인하지 못한 부분이었던 것 같아요…"*
+
+→ **학생 자가 한계 인정 (시간 압박) + 자가 깨달음** — *학습 적극성*. PR #36·#87·#117 결.
+
+> [KwonDae]
+> *"`deck.pop` 로직을 수정하라는게 아닌, 이 함수를 호출할 때 어떤점을 고려해야 하는지에 대해 고민해보셨으면 합니다 :)"*
+
+→ **reviewer 의도 명시 + 학생 자가 학습 권유** 어휘.
+
+> [KwonDae]
+> *"아니요 절대 죄송하지 않으셔야 합니다 ㅎㅎ 잘 진행해주고 계셔서 조금이라도 도움이 되었으면 하는 마음이었다는것만 알아주세요!"*
+
+→ **reviewer 의 인간적 학생 격려** 어휘.
+
+## 얻은 교훈 (보편)
+
+1. **현실 메타포 = 게임 승패 외부 장치 X = 참가자 자가 결정** — *Tell-Don't-Ask + 현실 정합*. **MCP 룰 `metaphor-fidelity-locator` 강화** ⭐⭐⭐ 누적 9+ PR.
+
+2. **추상화 활용 점검 = 공통 사항 → 추상 메서드** — *공통 사항 + 기준 다름 = 추상화 패턴*. **MCP 룰 `abstraction-as-shared-behavior-discovery` 후보**.
+
+3. **추상화 진행 이유 회수** — *"지금까지 추상화를 진행한 이유에 대해 고민해보시죠!"* = *학습 의도 회수 어휘*. **MCP 룰 `abstraction-purpose-revisit` 후보**.
+
+4. **invariant 강제 시점 3 안 (compile vs runtime vs filter)** — *생성자 타입 분리 vs single() vs filter().first()*. **MCP 룰 `compile-time-singleton-vs-runtime-filter` 후보**.
+
+5. **sealed interface vs abstract class vs open class** — *Kotlin 어휘 트레이드오프*. **MCP 룰 `sealed-vs-abstract-vs-open-locator` 후보**.
+
+6. **`abstract class` vs `open class` = 추상 메서드 유무** — *추상 메서드 없는 abstract = open 동치*. **MCP 룰 `abstract-without-abstract-method` 강화** 누적 5+ PR.
+
+7. **테스트 가능성 = 객체 설계 지표 + interface 분리 (DIP)** — *production vs test 의 별도 구현*. **MCP 룰 `interface-for-test-substitution` 후보**.
+
+8. **검증 코드 함수 분리 vs require 트레이드오프** — *내부 구현 알 필요 X 시 함수 분리*. **MCP 룰 `validation-function-vs-require-inline` 후보**.
+
+9. **커뮤니케이션 메타 (줄글 vs 핵심 내용)** — *코드 외 학습 영역 + 학생 미래 커리어 의식*. **MCP 핵심 가치 합류**.
+
+10. **비즈니스 로직 vs Controller 로직 구분** — *카드 공개 = 비즈니스 (참가자 다형성)*. **MCP 룰 `business-logic-vs-controller-logic` 후보**.
+
+11. **예외 처리 vs 게임 종료 흐름** — *Exception 던지기 vs graceful shutdown*. **MCP 룰 `exception-vs-graceful-shutdown` 후보**.
+
+12. **Boolean 함수명 = true/false 의미 명시** — *validateNames true/false 모호*. **MCP 룰 `boolean-function-name-ambiguity` 후보**.
+
+13. **외부 take vs 도메인 메서드** — *cards.allCards.take(N) → takeFirstN(n) 메시지*. **MCP 룰 `external-take-vs-domain-method` 후보**.
+
+14. **대칭 getResult vs compareWith** — *각자 자가 결정 (대칭 코드) vs 한 자리에서 비교*. **MCP 룰 `symmetric-getResult-vs-compareWith` 후보**.
+
+15. **모든 22 스레드 학생 자가 답변 + 커밋 SHA + 자가 후속 의문 5+ 회** — *학생 자가 학습 가시화 정점*.
+
+16. **2025 코호트 스타일 (셀프 체크리스트 + 집중 리뷰 영역 자가 명시)** — PR #117·#129 합류.
+
+17. **학생 자가 한계 인정 (시간 압박)** — *시간에 쫓겨 미처 확인 못 함*. *학습 적극성*. 누적 10+ PR.
+
+18. **단순 위임 메서드 = 추가 책임 X = 메서드 인공** — *Participants.getChoice = player.choice 단순 호출*. **MCP 룰 `simple-delegation-method-unnecessary` 후보**.
+
+19. **결과 누적 callback vs return** — *callback action(map) vs return map*. **MCP 룰 `callback-action-for-result-aggregation` 후보**.
+
+20. **원시 타입 반환 (Int) = 의미 누수** — *processDealerTurn(): Int = drawCount 의미 모호*. **MCP 룰 `primitive-return-without-domain-meaning` 후보**.
+
+## 얻은 교훈 (도메인)
+
+1. **Dealer 1장 / Player 2장 카드 공개 도메인 룰** — *showInitialCards 다형성*.
+
+2. **Dealer 16 이하 hit / Player 21 이하 hit** — *Hit 가능 기준 차이 = 추상 메서드 isDrawable*.
+
+3. **카드 수신 vs 공개 분리** — *수신은 모두 2장, 공개는 Dealer 1장 / Player 2장*.
+
+4. **Ace 1 기본 + 단일 +10 룰** — PR #36 결. *Multi-Ace 정확 처리 X*.
+
+5. **`Dealer.isDrawable() = sum + 10 < 16` (Ace Soft 적용)** — *Soft Ace + 16 한계*. 다만 *블랙잭 표준은 17 이상 stay → < 17 또는 ≤ 16 hit*.
+
+→ **`DEALER_MAX_SCORE = 16` + `<` 비교 시 16 시 stay = 룰 와전 가능**. **블랙잭 룰 정확성 점검 필요**. **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 10+ PR ⭐⭐⭐.
+
+6. **게임 승패 = 참가자 자가 결정 (외부 GameResultDecider X)** — *Tell-Don't-Ask + 현실 메타포*.
+
+7. **GameResult enum (WIN/LOSE/DRAW)** — *블랙잭 1.5배 분기 X (이번 미션 1단계)*.
+
+## MCP 룰 후보 신규 + 강화 (PR #129)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `metaphor-fidelity-locator` | 강화 | 9+ ⭐⭐⭐ |
+| `abstraction-as-shared-behavior-discovery` | 신규 | 1 (#129) |
+| `abstraction-purpose-revisit` | 신규 | 1 (#129) |
+| `compile-time-singleton-vs-runtime-filter` | 신규 | 4+ (#129·#79·#92·#48) |
+| `sealed-vs-abstract-vs-open-locator` | 신규 | 5+ (#129·#98·#36·#147·#93·#136) |
+| `abstract-without-abstract-method` | 강화 | 5+ (#95·#36·#117·#129·#147) |
+| `interface-for-test-substitution` | 신규 | 4+ (#129·#48·#39·#46) |
+| `validation-function-vs-require-inline` | 신규 | 1 (#129) |
+| `business-logic-vs-controller-logic` | 신규 | 2+ (#129·#129) |
+| `exception-vs-graceful-shutdown` | 신규 | 1 (#129) |
+| `boolean-function-name-ambiguity` | 신규 | 1 (#129) |
+| `external-take-vs-domain-method` | 신규 | 1 (#129) |
+| `symmetric-getResult-vs-compareWith` | 신규 | 1 (#129) |
+| `simple-delegation-method-unnecessary` | 신규 | 2+ (#129·#87) |
+| `callback-action-for-result-aggregation` | 신규 | 1 (#129) |
+| `primitive-return-without-domain-meaning` | 신규 | 2+ (#129·#36) |
+| `blackjack-rule-fidelity-comparison` | 강화 | 10+ ⭐⭐⭐ |
+| `ace-bonus-single-vs-multi` | 강화 | 2+ (#36·#129) |
+
+## 메타 어휘 (13 reviewer + MCP 핵심 가치 합류 정점 유지)
+
+- ***KwonDae (제이든)*** — 기존 reviewer (batch 12 신규 합류) **메타 어휘 깊이 정점** (커뮤니케이션 메타 + 학생 인간적 격려 + 추상화 활용 점검 + 현실 메타포 정공).
+- ***현실 메타포 = 외부 장치 X*** — KwonDae PR #129 — *"게임의 승패를 결정해주는건 외부 장치가 해주는걸까요? 실제 게임을 생각해보면, 외부 장치로 게임 승패를 결정하는게 아닌, 딜러와 참가자가 스스로 판단하게 됩니다."* — **MCP `oh-my-oop` 핵심 가치 (현실 메타포 정합)**. PR #117·#31·#21 결.
+- ***추상화 활용 점검 + 학습 의도 회수*** — KwonDae PR #129 — *"지금까지 추상화를 진행한 이유에 대해 고민해보시죠!"* — *학습 의도 회수 어휘*.
+- ***N 안 + 학생 선택지*** — KwonDae PR #129 — *"두가지 방법이 있을 것 같아요. (...) 어느 방법이 좋을지 고민해보시고 알려주세요!"* — **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+- ***커뮤니케이션 메타 (줄글 vs 핵심 내용)*** — KwonDae PR #129 — *"우테코 미션을 진행하는 것을 넘어 이후 현업에서도 커뮤니케이션 비용 줄이기에 대해 많은 사람들이 고민을 하는데요."* — *코드 외 학습 영역 + 학생 미래 커리어 의식*. **MCP `oh-my-oop` 핵심 가치 합류**.
+- ***학생 인간적 격려*** — KwonDae PR #129 — *"아니요 절대 죄송하지 않으셔야 합니다 ㅎㅎ"* — *reviewer 의 인간적 학생 격려* 어휘.
+- ***reviewer 의도 명시 + 학생 자가 학습 권유*** — KwonDae PR #129 — *"`deck.pop` 로직을 수정하라는게 아닌, 이 함수를 호출할 때 어떤점을 고려해야 하는지에 대해 고민해보셨으면 합니다 :)"*.
+- ***학생 자가 한계 인정 (시간 압박)*** — rosemin928 PR #129 — *"시간에 쫓겨 작업하느라 미처 확인하지 못한 부분이었던 것 같아요…"* — *학습 적극성*.
+- ***모든 22 스레드 학생 자가 답변 + 커밋 SHA + 자가 후속 의문 5+ 회*** — rosemin928 PR #129 — *학생 자가 학습 가시화 정점* (PR #117 결).
+- ***2025 코호트 스타일 (셀프 체크리스트 + 집중 리뷰 영역 자가 명시)*** — *체계화된 PR 본문 + 학생 자가 한계 명시*. PR #117·#129 합류 = 2025 코호트 *2 PR 표본*.
+
+→ **13 reviewer + MCP `oh-my-oop` 핵심 가치 어휘 합류 정점 유지**. **2025 코호트 (모바일 안드로이드 7기) 신규 패턴**: 셀프 체크리스트 PR 본문 + 모든 스레드 commit SHA + 학생 자가 한계 인정.