oh-my-oop 0.2.0

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

@@ -0,0 +1,189 @@
+# PR #43 — [블랙잭 2단계] 스캇 미션
+
+- **Reviewee:** [@chws0508](https://github.com/chws0508)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/43
+- **단계:** 2단계
+- **리뷰어:** @namjackson (잭슨)
+- **라인 코멘트:** 10 스레드 — *학생 자가 책임 위치 매우 깊은 의문* + *1단계 권고 적극 반영 (Score, 상태 패턴, sealed class)*
+- **양 단계 분석 reviewee** (1단계 #26 별도). 학생 자가 진화 모범.
+
+## 잘한 점 (설계 관점)
+
+- **1단계 권고 적극 반영 + 상태 패턴 자가 도입** — 학생 자가 답변: *"이 부분을 해결하기 위하여 상태패턴을 이용해 보았습니다!"* (1단계의 Player 스코어 분기 깊이 → 2단계 상태 패턴 자가 적용). 잭슨 칭찬: *"상태 패턴을 활용해주셨네요 👍 👍"* / *"sealed class 👍"*. **PR #39 (rhthrhrl0 상태 패턴 처음 자가 학습) / PR #98 (chaehyuns 상태 패턴 시도) 결**.
+- **학생 자가 책임 위치 매우 깊은 의문** — *"게임의 승패를 결정하는 것이 플레이어의 역할인지, 블랙잭 게임의 역할인지, 아니면 승패를 가지고 있는 GameResultType의 역할인지... 아니면 따로 또 객체를 만들어줘야 하는지... 이번에는 상태패턴을 써서 상태가 승패를 결정하도록 하였지만, 이런식으로 책임을 정하기 애매하거나 어려울 때, 리뷰어님은 어떤 기준으로 부여하시는지 궁금합니다."* — **학생이 *4 후보 명시 + reviewer 의 책임 기준 자가 의문* 모범**. PR #128·#135·#108·#133·#136·#137·#148·#151·#98·#95·#99·#23 와 같은 결.
+- **잭슨 자가 한계 인정 + 책임 위치 트레이드오프 명시** — *"GameResultType에게 승패를 결정하는 책임을 주었는데, GameResultType에는 결국 playerScoreState와 dealerScoreState를 모두 알아야한다는 단점또한 생기는것 같아요. 승패를 정하는 책임이 어디에 있어야할지 한번 더 생각해보아도 좋을거같아요! 정답은 없는거니, 고민만해주셔도 좋아요!"* — **MCP `oop_propose_alternatives` 어휘와 일치**. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) / PR #23 (말리빈 *"제 개인적인 의견입니다"*) / PR #26 (잭슨 *"개인적인 의견이니 참고만"*) 결.
+- **suggestion 블록 활용 2회** — `cardDeck.shuffled()[0]` → `cardDeck.shuffled().first()` / when 분기 직접 비교 코드 suggestion. PR #26 (잭슨 *given-when-then + expression body*) 결.
+- **학생 자가 잘못된 가정 자가 인정** — *"when 을 쓸때 무조건 소괄호안에 값이 있어야 한다고 착각했네요 ㅠㅠ 수정하였습니다!"* — **학생 자가 잘못된 가정 자가 인정 + Kotlin 어휘 자가 학습**. PR #23 1단계의 *else 지양 극단 적용* / PR #146 *YAGNI 자가 인정* 결.
+- **interface 프로퍼티 자가 학습 권고** — 잭슨: *"코틀린에서 인터페이스에서는 프로퍼티도 선언할수 있어요 😄 필요에 따라서, 함수대신 프로퍼티도 사용할수 있습니당!"*. **Kotlin 어휘 (interface property) 자가 학습** — PR #98·#99·#146·#137 의 *Kotlin 어휘 학습* 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `compareScoreValue` 점수 차이 계산 → 직접 비교 권고
+
+잭슨 suggestion:
+
+```kotlin
+fun compareScoreValue(dealerScoreValue: Int, playerScoreValue: Int): GameResultType {
+    return when {
+        playerScoreValue > dealerScoreValue -> WIN
+        dealerScoreValue < playerScoreValue -> LOSE
+        else -> DRAW
+    }
+}
+```
+
+잭슨 진단: *"점수차이를 계산하신 이유가 있나욤? 그냥 크기를 비교해주는게 좀더 직관력이 있지않을까욤?"*
+
+학생: *"when 을 쓸때 무조건 소괄호안에 값이 있어야 한다고 착각했네요 ㅠㅠ 수정하였습니다!"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *`when (값)` vs `when { 조건 }` 두 형태*
+
+- *`when (x) { 1 -> ..., 2 -> ... }`* — *값 매칭*. 학생 *잘못된 가정 (소괄호 필수)*.
+- *`when { x > y -> ..., x < y -> ... }`* — *조건 매칭 (if-else-if chain 대체)*. **Kotlin 의 강력한 어휘**.
+
+#### 1.2. *점수 차이 vs 직접 비교*
+
+- *점수 차이 (`dealer - player`) → 부호 검사* = *우회 + 직관성 ↓*.
+- *직접 비교 (`>`, `<`, `==`) → enum 결과* = *직관 + 단순*.
+
+#### 1.3. *학생 자가 잘못된 가정 자가 인정 모범*
+
+**Kotlin 어휘 학습 갭 자가 노출 = 학습 가시화 모범**. PR #23 (멘델 *else 지양 극단*) / PR #146 (yrsel *YAGNI 자가 인정*) 결.
+
+### 2. `GameResultType` 책임 위치 — 학생 자가 매우 깊은 의문
+
+잭슨 메타 진단:
+
+> *"GameResultType에게 승패를 결정하는 책임을 주었는데, GameResultType에는 결국 playerScoreState와 dealerScoreState를 모두 알아야한다는 단점또한 생기는것 같아요. 승패를 정하는 책임이 어디에 있어야할지 한번 더 생각해보아도 좋을거같아요! 정답은 없는거니, 고민만해주셔도 좋아요!"*
+
+학생 자가 매우 깊은 의문:
+
+> *"이 부분이 상당히 어려운 것 같습니다 ㅠㅠ 게임의 승패를 결정하는 것이 플레이어의 역할인지, 블랙잭 게임의 역할인지, 아니면 승패를 가지고 있는 GameResultType의 역할인지... 아니면 따로 또 객체를 만들어줘야 하는지... 이번에는 상태패턴을 써서 상태가 승패를 결정하도록 하였지만, 이런식으로 책임을 정하기 애매하거나 어려울 때, 리뷰어님은 어떤 기준으로 부여하시는지 궁금합니다."*
+
+→ **5 가지 학습**:
+
+#### 2.1. *책임 위치 = 4 후보*
+
+학생 자가 명시:
+- (A) **Player** — 플레이어가 자기 승패 판단.
+- (B) **BlackJackGame** — 게임이 승패 판단 (god-object 위험).
+- (C) **GameResultType (enum)** — *enum 이 행동 가짐 = OOP 함정 (enum 만능)*.
+- (D) **별도 객체 (예: Judge / Referee)** — *심판 객체 분리*.
+- (E, 학생 선택) **State** — *상태가 자기 승패 결정 (다형성)*.
+
+PR #74 (송핑크 *Referee 자가 토론*) / PR #23 1단계 (멘델 *3 후보 + 그림*) / PR #70·#98 (chaehyuns *Judge 분리*) 결.
+
+#### 2.2. *enum에 행동 부여 = 양가성*
+
+- *enum + 행동* = *Kotlin 어휘 풍부 + 멤버별 분기 캡슐화*. PR #137·#148·#90·#146 의 *enum + when exhaustive* 결.
+- *그러나 enum 이 *다른 객체 (Player, Dealer) 의 내부 상태* 까지 알아야 한다면* = *책임 누수*.
+
+#### 2.3. *State 패턴 = 다형성 디스패치*
+
+- *각 State (BlackJack, Bust, Hit, Stay) 가 자기 승패 결정 메서드*.
+- *외부는 `state.compareTo(other)` 만 호출* → *enum 분기 제거*.
+
+PR #93·#136·#152 의 *State.compareTo: GameResult 다형성* 결.
+
+#### 2.4. *책임 기준 자가 의문 모범*
+
+학생의 *"리뷰어님은 어떤 기준으로 부여하시는지 궁금합니다"* — **reviewer 의 *책임 기준* 자가 의문**. *학생이 *경험/규칙* 을 묻는 것이 아니라 *판단 기준* 을 묻는 것* = **메타 학습 자가 명시**.
+
+#### 2.5. *"정답은 없는거니, 고민만해주셔도 좋아요"* — reviewer 메타 어휘
+
+잭슨의 *"정답은 없는거니"* — **MCP `oh-my-oop` 의 핵심 가치**. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) / PR #23·#26 결.
+
+### 3. `Player 스코어 분기 깊이` → 상태 패턴 자가 적용
+
+잭슨 진단: *"Player의 스코어 별로 분기처리를 해주어서, 각 스코어별 케이스가 나누어졌지만, 반면에, 결국 뎁스가 깊어져서, 한번에 승패로직을 파악하기는 힘들수도 있다고 생각이 들어요!"*
+
+학생: *"이 부분을 해결하기 위하여 상태패턴을 이용해 보았습니다!"*
+
+→ **`if-else 분기 깊이 < State 다형성`**:
+- *if-else N 단 분기* = *읽기 힘듦 + 변경 시 N 곳 모두 수정*.
+- *State 객체 N 개* = *각 객체에 분기 책임 분산 + 새 상태 추가 시 새 State 클래스 1개*.
+
+PR #98 (chaehyuns 상태 패턴 시도) / PR #39 (rhthrhrl0 상태 패턴 처음) / PR #93·#136·#152·#90 의 *State 정공* 결.
+
+### 4. `shuffled()[0]` → `shuffled().first()`
+
+잭슨 suggestion: `return cardDeck.shuffled().first()`
+
+→ **Kotlin 어휘 (.first())** — *`[0]`* (배열 인덱스) < *`.first()`* (의도 명시). *비어있을 때 `NoSuchElementException` 명시 + 의도 가독성*.
+
+### 5. `Controller god-object` — `BlackJack.runGame()` 결과 반환
+
+잭슨: *"게임시작시 , 플레이어 턴 -> 딜러턴 의 게임을 통해서 결과를 리턴하는 부분은 BlackJack 클래스내에서 관리하는 책임이 아닐까요? 컨트롤러에서는 blackJackGame 게임을 실행시키고, 결과만 받아오면 어떨까요? `val gameResult = blackJackGame.runGame(`"*
+
+→ **Controller 절차 분기 < BlackJack 도메인 응집**:
+- *Controller 가 *플레이어 턴 → 딜러 턴 → 결과* 분기* = *도메인 절차 누수*.
+- *`blackJackGame.runGame()` 단일 진입점* = *도메인 절차 캡슐화 + Controller 는 결과만 출력*.
+
+PR #99 (s6m1n *Controller god-object 메타 질문*) / PR #95 (송핑크 *game.start() 결과 반환*) / PR #28·#78·#112·#125·#147 의 *Controller god-object* 결.
+
+### 6. `private` 가시성 — 외부 노출 함수만 public
+
+잭슨: *"외부에 노출되지않는 함수들은 private으로 관리해주세요!"*
+
+→ **Kotlin 가시성 어휘** = *public default 방치 = 불필요 API 노출*. PR #99 (s6m1n *protected 자가 학습*) 결.
+
+### 7. `interface 프로퍼티` 자가 학습
+
+잭슨: *"코틀린에서 인터페이스에서는 프로퍼티도 선언할수 있어요 😄 필요에 따라서, 함수대신 프로퍼티도 사용할수 있습니당!"*
+
+→ **Kotlin interface vs Java interface**:
+- *Java*: 메서드만 (default impl 가능, but no fields).
+- *Kotlin*: *추상 프로퍼티 선언 가능* (`val score: Int`) + *구현체가 백킹 필드 또는 getter 제공*.
+- *학생 코드의 `fun getValue(): Int`* < *`val value: Int`* — *getter 함수 < 프로퍼티 어휘*.
+
+PR #98 (chaehyuns *fun interface vs interface*) 결.
+
+### 8. `주석 코드 수정`
+
+잭슨: *"주석 코드를 수정해주세요!"*
+
+→ **주석 정리 = 일상 책임**. PR #28·#79 의 *주석 정리* 결.
+
+## 리뷰어 의견 요지 (잭슨 / namjackson)
+
+10 코멘트 특징 (PR #26 와 동일 reviewer):
+
+- **suggestion 블록 활용 2회** — *when 분기 + `shuffled().first()`*. PR #26 (잭슨 *given-when-then + expression body*) / PR #39 (말리빈 *if return*) 결.
+- **메타 질문 + 책임 기준 자가 토론** — *"승패를 정하는 책임이 어디에 있어야할지 한번 더 생각해보아도 좋을거같아요!"* — **책임 기준 메타 어휘**.
+- **MCP `oop_propose_alternatives` 어휘 일치** — *"정답은 없는거니, 고민만해주셔도 좋아요!"* / *"이부분도 정답이 없는부분이니 고민만해주셔도 좋을거같아요!"*. PR #26 (잭슨 *"개인적인 의견이니 참고만"*) 결.
+- **칭찬 분포** — *sealed class 👍*, *상태 패턴 👍👍*, *Kotlin 어휘 (interface 프로퍼티) 추가 학습* — *학생 자가 진화 인정*.
+- **머지 시점 학생 자가 회고 권유 없음** — *10 thread = 가벼운 분량 + 1단계 권고 적극 반영* 으로 빠른 머지.
+
+## 대표 인용
+
+> *"게임의 승패를 결정하는 것이 플레이어의 역할인지, 블랙잭 게임의 역할인지, 아니면 승패를 가지고 있는 GameResultType의 역할인지... 아니면 따로 또 객체를 만들어줘야 하는지... 이번에는 상태패턴을 써서 상태가 승패를 결정하도록 하였지만, 이런식으로 책임을 정하기 애매하거나 어려울 때, 리뷰어님은 어떤 기준으로 부여하시는지 궁금합니다."* — chws0508 (학생 자가 4 후보 + reviewer 책임 기준 자가 의문 모범)
+
+> *"승패를 정하는 책임이 어디에 있어야할지 한번 더 생각해보아도 좋을거같아요! 정답은 없는거니, 고민만해주셔도 좋아요!"* — namjackson (책임 기준 + MCP 핵심 어휘)
+
+> *"이 부분을 해결하기 위하여 상태패턴을 이용해 보았습니다!"* — chws0508 (1단계 권고 자가 반영 + 상태 패턴 자가 적용)
+
+> *"when 을 쓸때 무조건 소괄호안에 값이 있어야 한다고 착각했네요 ㅠㅠ 수정하였습니다!"* — chws0508 (학생 자가 잘못된 가정 자가 인정 + Kotlin 어휘 자가 학습)
+
+## 얻은 교훈
+
+1. **책임 위치 = *기준 자가 의문 모범*** — *학생이 *4 후보 명시 + reviewer 의 판단 기준 자가 의문*. **메타 학습 자가 명시**. PR #95 (송핑크 *abstract vs open 자가 의문*) / PR #99 (s6m1n *Return enum 자가 의문*) 결.
+
+2. **`enum 에 행동 부여` 양가성** — *Kotlin 어휘 풍부 + 멤버별 분기 캡슐화* vs *다른 객체 내부 상태 까지 알아야 함 = 책임 누수*. PR #137·#148·#90·#146 의 *enum + when exhaustive* / PR #93 *sealed without differentiation* 결.
+
+3. **`State 다형성` = if-else 분기 깊이 해결** — *각 State 가 자기 승패 결정 메서드 → 외부 분기 제거*. PR #93·#136·#152 의 *State.compareTo* / PR #98·#39·#43 학생 자가 적용 결.
+
+4. **잭슨의 *"정답은 없는거니, 고민만해주셔도 좋아요"*** — **MCP `oh-my-oop` 핵심 어휘**. PR #95·#23·#26 와 같은 결. *reviewer 가 *판단 기준 강요 X + 학생 선택지 인정* 메타 어휘*.
+
+5. **`when (값)` vs `when { 조건 }` Kotlin 어휘 갭 자가 인정** — *학생이 *잘못된 가정 (소괄호 필수) 자가 명시 + 자가 학습*. **MCP 룰 후보 `when-pattern-vs-condition`** = *Kotlin 어휘 학습 갭 진단*.
+
+6. **`interface 프로퍼티` Kotlin 어휘** — *Java interface (메서드만) vs Kotlin interface (추상 프로퍼티 + 메서드)*. *getter 함수 (`fun getValue()`) < 프로퍼티 (`val value`)*.
+
+7. **`Controller god-object → BlackJack.runGame()` 결과 반환** — *Controller 절차 분기 < 도메인 응집*. PR #99·#95·#28·#78·#112·#125·#147 결.
+
+8. **suggestion 블록 활용 (Kotlin 어휘 + 코드 단순화)** — *when 분기 직접 비교 + `shuffled().first()`*. PR #26·#39 결.
+
+9. **1단계 권고 적극 반영 + 상태 패턴 자가 적용** = *학생 자가 진화 모범*. *PR #26 1단계 권고 (Player 스코어 분기) → PR #43 2단계 자가 적용 (State 패턴)* — **양 단계 본 reviewer 만 가능한 진화 가시화**. PR #98·#39·#74·#67 결.
+
+10. **수직 책임 분포 (4 후보) + 학생 자가 명시** — *Player / BlackJackGame / GameResultType / 별도 객체* — *학생이 *책임 후보를 명시적으로 나열* + reviewer 가 *기준 자가 토론*. **MCP `oop_propose_responsibilities` 어휘와 일치**.

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

@@ -0,0 +1,351 @@
+# PR #109 — [블랙잭 1단계] 오이 미션
+
+- **Reviewee:** [@cucumber99](https://github.com/cucumber99)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/109
+- **단계:** 1단계
+- **리뷰어:** [@hyemdooly](https://github.com/hyemdooly) (둘리) — 2025 코호트 신규 reviewer (PR #130·#143·#109 분석 reviewer)
+- **라인 코멘트:** 25 스레드 — *PR 본문 자가 의문 3개 (생성자 vs Deck interface + UI 모델 도메인 분리 + Person 추상 클래스) + 학생/reviewer 5 라운드 양방향 토론 (Game 책임 + Deck 외부 주입 vs 딜러 보유) + reviewer 자가 정정 + 학생 자가 의문 + 테스트 = 도메인 설계 개선 어휘 + State 별 카드 장수 책임 + State 가 객체 vs 값 받기 + 상수 도메인 위치 + assertAll vs 여러 assertThat + Deck 생성 자연스러운가?*
+- **신규 reviewee** (2025년 코호트 — 모바일 안드로이드 7기, PR #117·#129·#130·#126·#138·#142·#143·#109 = **2025 코호트 8 PR 코퍼스 성장**).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 3개 + 페어 학습 + 자가 입장 명시
+
+PR 본문 (Thread 1·3 인용):
+- *Hand 일급 컬렉션 + Person 추상 → Hand 생성자 받음 vs Deck interface 추상화 학생 자가 의문*.
+- *UI 모델 분리 (PersonUiModel) + 도메인 vs View 책임 학생 자가 의문*.
+- *Person 추상 클래스로 Dealer/Player 구현 자가 적용*.
+
+→ **학생 자가 의문 3개 + 자가 입장 + 페어 학습** = PR #21·#35·#126 결의 *PR 본문 자가 의문 3개* 어휘 합류. 2025 코호트 정점 유지.
+
+### 2. `Deck` 생성 책임 학생 ↔ reviewer 5 라운드 양방향 토론
+
+reviewer (Thread 13): *"`Deck`에서 카드를 생성하는 것은 자연스러운 액션일까요?"*
+
+학생:
+
+> *"저는 `Deck`이 게임에서 사용될 카드들을 관리하므로, 생성에 대한 책임 또한 가지고 있어도 된다고 생각했습니다! (...) 둘리의 생각은 어떠신가요?🤔"*
+
+reviewer:
+
+> *"저는 카드들을 외부에서 주입받는 형태를 사용할 것 같아요. 🤔 덱은 누군가가 카드를 뽑을 수 있도록 관리하는 역할은 맞지만, 생성을 한다고 생각하지는 않아요. 카드가 비었다고 해서 새로운 덱을 생성해주는 것도 어색해요. (...) 처음부터 빈 값을 세팅할 수 있다면 더 자연스럽지 않을까요?"*
+
+→ **5 라운드 양방향 + DI vs 자가 생성 트레이드오프** = PR #143 (medAndro 결의 *Deck 외부 주입 vs 내부 생성*) 합류. **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+
+### 3. State 별 카드 장수 책임 + State 객체 vs 값 받기
+
+reviewer (Thread 5·6): *"`State`들이 객체를 받기 보다는 실제 값들(카드 개수, 스코어)을 받아서 판단하면 어떨까요? 여기서 관심사는 사람보다는 사람이 가지고 있는 것들이라고 생각해요!"* + *"`State`에 따른 뽑을 수 있는 카드 장수를 선언하면 어떨까요?"*
+
+→ **State 책임 분리 + 관심사 = 카드 (사람 X)** = PR #87·#142·#138 (state pattern + abstract method) 결의 *State 자식 책임* 어휘 강화.
+
+**MCP 룰 `state-receives-value-vs-object` 후보** — *State 가 객체 받기 vs 값 받기 (관심사)*.
+
+### 4. Game 책임 5 라운드 양방향 토론 + reviewer 자가 정정 + 학생 자가 결정
+
+reviewer (Thread 19): *"사실 저는 지금 구조에서 Game 존재의 이유를 잘 모르겠어요. (...) 오히려 분리해서 더 가독성이 떨어지는 것 같아요. 🤔"*
+
+학생 자가 의문 + 자가 결정:
+
+> *"`Game` 객체를 사용하지 않고, 컨트롤러에 도메인 로직이 노출되어도 괜찮을까요? 혹은 컨트롤러에 도메인 로직이 노출될 수 밖에 없는 상황이라면, 설계가 잘못된 것인가요?"*
+
+학생 자가 결정: *"지금 당장은 Game의 문제를 해결할 방법이 떠오르지 않아서, 우선은 Game 객체를 사용하지 않게끔 하겠습니다."*
+
+reviewer 자가 정정:
+
+> *"오 제 의견이 잘못 전달이 된 것 같은데요! 제가 모호하게 말씀을 드린 것 같네요 🙏 **람다 함수로 전달하는 것은 도메인이 뷰에 의존하지 않는 것이 맞습니다. 뷰의 함수를 참조하는 것이 아니라서요!** 저도 이 이후로 조금 더 생각을 해봤는데, 오이 의견대로 우선 Game을 사용하되 함수를 너무 타고 들어가지 않게끔 단순하게 만들면 좋아지지 않을까 싶어요!!"*
+
+→ **5 라운드 양방향 + 학생 자가 결정 → reviewer 자가 정정 + 변경 인정** = PR #126·#130·#142 (reviewer 자가 한계 인정) 결 정점 강화. **MCP 룰 `reviewer-self-position-revision` 후보** — *reviewer 가 자가 의견 변경 + 학생 의견 인정*.
+
+### 5. 학생 자가 *현실 메타포 (딜러가 카드 분배)*
+
+학생 자가 답변 (Thread 17):
+
+> *"현실에서의 블랙잭 게임을 생각해보면, 딜러가 정확히 하나의 덱을 가지고 있으면서 각 플레이어와 자신에게 카드를 분배하는 것이 적절하다고 생각했습니다."*
+
+→ **학생 자가 현실 메타포 어휘** = PR #117·#129·#130 결의 *현실 메타포 정합* 학생 자가 합류. **MCP 룰 `metaphor-fidelity-locator` 강화** 누적 11+ PR ⭐⭐⭐.
+
+다만 *PR #117 reviewer 의 *카드뭉치에서 꺼내서 플레이어 받는다* 메타포* vs *PR #109 학생 자가 *딜러가 분배* 메타포* = **현실 메타포 양가성 (분배자 = 딜러 vs 카드뭉치)**.
+
+### 6. 학생 자가 *factory 함수 vs 생성자 동일 역할* 인지
+
+reviewer (Thread 2): *"팩토리 함수가 생성자랑 동일한 역할을 하는 것으로 보여요!"*
+
+→ **팩토리 함수 무의미 = 생성자 활용** = PR #21·#142 결의 *불필요한 추상화* 변형. **MCP 룰 `factory-function-vs-constructor-redundancy` 후보**.
+
+### 7. UI 모델 분리 (PersonUiModel) + 안드로이드 어휘
+
+reviewer (Thread 3):
+
+> *"사실 UiModel을 사용하는 경우는 실제 안드로이드 개발에서 자주 사용되긴 합니다. Data - Domain - Presentation 계층으로 나누게 되면서 각 계층의 모델들을 만들 수 있어요. (지금 당장 몰라도 되는 내용이니 그렇구나 하고 넘어가주세요.ㅎㅎ) 우선 저는 Ui Model이 도메인이 아니라고 생각해요. 지금 구조에서는 View의 역할에 가깝다고 생각합니다."*
+
+→ **3 계층 (Data/Domain/Presentation) 분리 + 학생 부담 최소화 어휘** = PR #21·#35 (galcyurio SuitModel 미래 학습) 결 + PR #130 (hyemdooly RankModel 자가 적용) 결의 **학생 → reviewer 진화 어휘 일관**.
+
+### 8. 추가 칭찬
+
+- Thread 7: *"확장 함수 사용 👍"*.
+- Thread 9: *"테스트 코드에 kotest의 DSL을 활용해주셨군요 👍"*.
+- 학생 자가 답변 풍부 + 학생 자가 코드 예시 (PR 본문) + 학생/reviewer 5 라운드 양방향 토론 4 자리 (Thread 13·15·17·19).
+
+## 못한 점 (설계 관점)
+
+### 1. 부생성자 vs Default value (Kotlin 어휘)
+
+reviewer (Thread 4): *"여기서 부생성자가 필요할까요?"* + *"아하 Default value를 사용할 수 있을 것 같아서 드린 리뷰였어요!"* + 외부글 (kotlinlang.org/docs/classes.html#constructors).
+
+학생 자가 답변:
+
+> *"특정 카드들을 플레이어나 딜러가 가지고 있을 때의 상황을 테스트하기 위해서 `Hand`를 생성자로 전달하거나, 전달하지 않을 경우 내부에서 기본으로 생성하게 됩니다. 때문에 외부에서 부 생성자로 `Hand`를 받아올 경우 외부와의 참조를 끊기 위해 `Hand`에 `copy`를 선언하고 그대로 사용했습니다."*
+
+→ **부생성자 vs Kotlin default value 트레이드오프** = PR #126·#130 결의 *test-fixture-secondary-constructor* 어휘 + Kotlin default value 어휘 비교.
+
+### 2. `setName` 이름 vs 출력 동작 — 이름 의미 불일치
+
+reviewer (Thread 12): *"이름은 `setName`이지만 하는 일은 출력이군요 🤔"*
+
+→ **이름 의미 정확성** = PR #36·#117·#129·#130·#139 (`function-name-vs-return-semantic-mismatch`) 결 누적 5+ PR.
+
+### 3. flag → 명시적 이름
+
+reviewer (Thread 14): *"flag말고 더 명시적인 이름이 있을까요?"* — *Boolean 변수 명명 정확성*.
+
+**MCP 룰 `boolean-variable-naming` 후보**.
+
+### 4. `dealer.draw()` = `deck.draw()` 위임만 — 책임 모호
+
+reviewer (Thread 15·17): *"이게 무슨 로직일까 생각했는데 딜러가 뽑아서 플레이어에게 주고있는 것이군요. 결국 플레이어가 카드를 뽑고 있는 것이니, 각자 덱에서 카드를 뽑는다 생각하면 더 단순해지지 않을까요?"*
+
+학생: *"`dealer.draw()`는 결국 `deck.draw()`를 반환할 뿐, 추가적인 동작은 하지 않는데요. 이렇게 되면 카드를 드로우하는 책임은 최종적으로 `Deck`에게 있는건가요?"*
+
+reviewer 자가 답변:
+
+> *"카드를 뽑아서 리턴하고 있는건 deck이고 뽑은 카드를 리턴하고 있는 것도 dealer인데, deck에서 뽑은 카드를 그대로 dealer가 던져준다고 해서 dealer에게는 책임이 없다고 할 수 있을까요? 크루들과 함께 대화해보면 좋을 것 같네요!"*
+
+→ **단순 위임 메서드 = 책임 모호** = PR #129·#87·#138 (`simple-delegation-method-unnecessary`) 결 강화 누적 5+ PR.
+
+### 5. Player 의 람다 인자 (decideHit, onHit) - View 의존
+
+reviewer (Thread 11): *"출력 때문에 String에 이름을 넣기 위해 이렇게 된 람다식으로 보입니다. 뷰를 제외하고 봤을 때, 이런 구조는 자연스러운 구조일까요? 🤔"*
+
+학생: *"근데 둘리가 말한 몇 가지 버그 중 하나가 해당 구조때문에 발생한다는걸 알아버렸어요..🥲 또한 플레이어 객체가 `View`의 메소드에 의존하고 있기 때문에 문제가 될 수 있을 것 같아요. 해당 부분은 개선하겠습니다!"*
+
+→ **람다 = View 결합 + 버그 발생 자가 학습** = PR #36·#129·#138·#142 결 합류.
+
+### 6. 상수 도메인 위치 (`GameRule` → 관련 모델 분산)
+
+reviewer (Thread 20): *"이 상수들을 관련된 도메인 모델로 옮겨볼 수 있지 않을까요?"*
+
+학생: *"하나의 상수가 여러 곳에서 사용되는 경우가 있어서 우선 `GameRule`에 모아놨습니다."*
+
+→ **`GameRule` 상수 모음 vs 각 도메인 모델 분산** = PR #130 (domain-constant-locator) 결의 *반대 시점*. 
+
+#### 6.1. *2 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| GameRule 상수 모음 (학생) | *상수 한 자리 + 여러 곳 공유 간결* | *도메인 의미 분산 + 한 클래스 비대* |
+| 각 도메인 모델 분산 (reviewer) | *각 모델 자가 상수 + 도메인 의미 명확* | *상수 ↑ + 공유 시 모델 ↔ 모델 의존* |
+
+**MCP 룰 `constant-aggregation-vs-domain-distribution` 후보**.
+
+### 7. `assertAll` vs 여러 assertThat
+
+reviewer (Thread 10): *"`assert`를 한 함수에 여러번 쓰면 어떤 불편함이 생길 수 있을까요?"*
+
+학생: *"`assertThat`중 하나라도 검증에 실패하면 이후 `assertThat`이 실행되지 않는 문제가 있었네요. `kotest`나, `assertAll`을 활용해보겠습니다!"*
+
+→ **테스트 fail-fast vs fail-all** = *학생 자가 학습*. **MCP 룰 `assert-all-vs-multiple-assertions` 후보**.
+
+### 8. 테스트 = 도메인 설계 개선 어휘 (학생 자가 의문 + reviewer 답변)
+
+학생 자가 의문 (Thread 25):
+
+> *"테스트 코드에서 카드를 직접 추가하지 않고 생성자로 주입하기 위해서는 도메인의 코드가 바뀌어야 하는데요. 테스트를 위해 도메인을 변경하는 것은 바람직한가요?"*
+
+reviewer:
+
+> *"테스트가 용이하도록 설계를 개선하는 것은 도메인을 변경하는 것일까요?"*
+
+→ **테스트 = 도메인 설계 개선 어휘** = PR #87 (jaeyeongjo *테스트 = 객체 설계 명세서*) + PR #129·#142 (테스트 가능성 = 객체 설계 지표) 결 강화 정점. 누적 4+ PR.
+
+**MCP 룰 `test-driven-domain-improvement` 강화** — *테스트 용이 = 설계 개선 어휘*.
+
+### 9. `given/when/then` 표준 vs 학생 코드 양가
+
+reviewer (Thread 18):
+
+> *"given/when/then에 어떤 행위를 하는지 다시 한번 살펴보면 좋겠어요. 제가 보기에 여기서 when은, given에 가까워보여요. 빈 덱을 만들기 위함이니까요!"*
+
+→ **테스트 BDD 어휘 (given/when/then) 정확성** — *학생 자가 학습*. **MCP 룰 `bdd-given-when-then-fidelity` 후보**.
+
+### 10. Participant 0 리턴 vs 예외
+
+reviewer (Thread 22): *"더 뽑을 수 없다면 0을 리턴하는 것이 자연스럽지 않을까요?"*
+
+학생: *"예외를 발생시키는 것보다 둘리가 말한 방식이 더 자연스러울 것 같아요😊"*
+
+→ **예외 vs 0 리턴** = PR #35 (galcyurio Kotlin 예외 처리 4 원칙) 결 합류. 
+
+### 11. 테스트 함수 이름 vs 결과 불일치
+
+reviewer (Thread 23): *"테스트함수 이름과 결과가 일치하지 않는 것 같아요. 🤔"* — *PR #36·#117 (`function-name-vs-return-semantic-mismatch`) 결 합류*.
+
+### 12. `Game(dealer, players)` init 블록에서 카드 분배 — 생성 시 부작용
+
+```kotlin
+class Game(val dealer: Dealer, val players: List<Player>) {
+    init {
+        players.forEach { player -> handOutCard(player) }
+        handOutCard(dealer)
+    }
+    ...
+}
+```
+
+→ **생성자 init 블록 부작용** = *Game 생성 시 자동 카드 분배* = *학생 자가 의문 (Thread 24) reviewer 답변*. **MCP 룰 `init-block-side-effect` 후보**.
+
+### 13. 학생 자가 *Game 사용 X 결정* → reviewer 자가 정정 (Game 유지)
+
+§4 참조. **학생 자가 결정의 한계 + reviewer 자가 정정** = *학생/reviewer 양방향 토론 정점*.
+
+### 14. `processTurn` `processDealerHit` `askHit` Game 메서드 4개 + 람다 인자
+
+```kotlin
+fun askHit(decideHit: (String) -> Boolean, onHit: (Player) -> Unit) { ... }
+fun processDealerHit(): Boolean { ... }
+private fun askHitForEachPlayer(player: Player, decideHit: ..., onHit: ...) { ... }
+private fun processTurn(player: Player, decideHit: ..., onHit: ...) { ... }
+```
+
+→ **Game 의 람다 인자 4개 메서드** = *PR #36 (callback-lambda-explosion) 결 합류*. *PR #142 결의 *Game 분리 + 책임 응집* 어휘 합류*.
+
+### 15. `dealer.canHit()` Tell-Don't-Ask + Dealer 자가 판단
+
+```kotlin
+fun processDealerHit(): Boolean {
+    if (dealer.canHit()) { handOutCard(dealer); return true }
+    return false
+}
+```
+
+→ **Dealer.canHit() 호출 = Tell-Don't-Ask 부분 정공**. 다만 *Game 이 분기 처리* = *완전 Tell-Don't-Ask X*. 
+
+대안: `dealer.processHit(): Boolean` (Dealer 자가 처리). **MCP 룰 `external-flow-control-vs-internal` 후보**.
+
+## 리뷰어 의견 요지
+
+- **PR 본문 자가 의문 3개에 답변 (Thread 1·3 + 인용)**.
+- **부생성자 vs Kotlin default value + 외부글**.
+- **State 가 객체 vs 값 받기 (관심사)** + **State 별 카드 장수 책임**.
+- **UI Model = View 역할 + 3 계층 (Data/Domain/Presentation) + 학생 부담 최소화**.
+- **`setName` 이름 vs 출력 동작 = 이름 의미 불일치**.
+- **`flag` 명시적 이름**.
+- **dealer.draw() = deck.draw() 위임 = 책임 모호**.
+- **Player 의 람다 인자 = View 의존 + 버그 발생**.
+- **Deck 생성 책임 5 라운드 양방향 + 외부 주입 권유**.
+- **상수 도메인 분산 vs `GameRule` 모음**.
+- **assertAll vs 여러 assertThat**.
+- **테스트 = 도메인 설계 개선 어휘 (학생 자가 의문 + reviewer 답변)**.
+- **given/when/then BDD 어휘 정확성**.
+- **Participant 0 리턴 vs 예외**.
+- **테스트 함수 이름 vs 결과 불일치**.
+- **Game 책임 5 라운드 양방향 + reviewer 자가 정정 (Game 유지 권유)**.
+- **딜러 Deck 보유 vs 외부 주입 (학생 자가 현실 메타포 + reviewer 람다 외부 주입)**.
+- **kotest DSL 칭찬 + 확장 함수 사용 칭찬**.
+
+## 대표 인용
+
+> [hyemdooly Thread 13]
+> *"저는 카드들을 외부에서 주입받는 형태를 사용할 것 같아요. 🤔 덱은 누군가가 카드를 뽑을 수 있도록 관리하는 역할은 맞지만, 생성을 한다고 생각하지는 않아요. 카드가 비었다고 해서 새로운 덱을 생성해주는 것도 어색해요."*
+
+→ **Deck 생성 = 자연스럽지 않음 어휘**.
+
+> [cucumber99 Thread 17]
+> *"현실에서의 블랙잭 게임을 생각해보면, 딜러가 정확히 하나의 덱을 가지고 있으면서 각 플레이어와 자신에게 카드를 분배하는 것이 적절하다고 생각했습니다."*
+
+→ **학생 자가 현실 메타포** — *PR #117·#129·#130 결의 *현실 메타포 정합* 학생 자가 합류*.
+
+> [hyemdooly Thread 19]
+> *"오 제 의견이 잘못 전달이 된 것 같은데요! 제가 모호하게 말씀을 드린 것 같네요 🙏 **람다 함수로 전달하는 것은 도메인이 뷰에 의존하지 않는 것이 맞습니다.** (...) 오이 의견대로 우선 Game을 사용하되 함수를 너무 타고 들어가지 않게끔 단순하게 만들면 좋아지지 않을까 싶어요!!"*
+
+→ **reviewer 자가 의견 변경 + 학생 의견 인정** — *PR #126·#130·#142 결의 *reviewer 자가 한계 인정* 어휘 정점 강화*.
+
+> [cucumber99 Thread 25]
+> *"테스트 코드에서 카드를 직접 추가하지 않고 생성자로 주입하기 위해서는 도메인의 코드가 바뀌어야 하는데요. 테스트를 위해 도메인을 변경하는 것은 바람직한가요?"*
+
+→ **학생 자가 *테스트 vs 도메인 변경* 자가 의문**.
+
+> [hyemdooly Thread 25]
+> *"테스트가 용이하도록 설계를 개선하는 것은 도메인을 변경하는 것일까요?"*
+
+→ **테스트 = 도메인 설계 개선 어휘** — *PR #87·#129·#142 결 강화 정점*.
+
+## 얻은 교훈 (보편)
+
+1. **PR 본문 자가 의문 3개 + reviewer 인용 답변** — *2025 코호트 정점 유지*.
+
+2. **Deck 외부 주입 vs 내부 생성 (5 라운드 양방향)** — **MCP 룰 `dependency-injection-vs-internal-creation` 강화** 누적 2+ PR (#143·#109).
+
+3. **State 가 객체 vs 값 받기 (관심사)** — **MCP 룰 `state-receives-value-vs-object` 후보**.
+
+4. **Game 책임 5 라운드 + reviewer 자가 정정** — **MCP 룰 `reviewer-self-position-revision` 후보**. PR #126·#130·#142 결 강화.
+
+5. **현실 메타포 학생 자가 사용** — **MCP 룰 `metaphor-fidelity-locator` 강화** 누적 11+ PR ⭐⭐⭐.
+
+6. **테스트 = 도메인 설계 개선 어휘** — **MCP 룰 `test-driven-domain-improvement` 후보** + PR #87·#129·#142 강화. 누적 4+ PR.
+
+7. **factory 함수 vs 생성자 동일 역할 = 무의미 추상화** — **MCP 룰 `factory-function-vs-constructor-redundancy` 후보**.
+
+8. **UI Model = View 역할 + 3 계층 + 학생 부담 최소화** — *PR #21·#35·#130 결 합류*.
+
+9. **상수 도메인 분산 vs 모음 트레이드오프** — **MCP 룰 `constant-aggregation-vs-domain-distribution` 후보**.
+
+10. **assertAll vs 여러 assertThat (테스트 fail-fast vs fail-all)** — **MCP 룰 `assert-all-vs-multiple-assertions` 후보**.
+
+11. **BDD given/when/then 어휘 정확성** — **MCP 룰 `bdd-given-when-then-fidelity` 후보**.
+
+12. **init 블록 부작용 (Game 생성 시 자동 카드 분배)** — **MCP 룰 `init-block-side-effect` 후보**.
+
+13. **외부 흐름 제어 vs 객체 내부 (`dealer.canHit()` 외부 분기 vs `dealer.processHit()` 자가)** — **MCP 룰 `external-flow-control-vs-internal` 후보**.
+
+14. **Boolean 변수 명명 (flag → 명시적)** — **MCP 룰 `boolean-variable-naming` 후보**.
+
+15. **부생성자 vs Kotlin default value + 외부글** — **MCP 룰 `secondary-constructor-vs-default-value` 후보**.
+
+16. **모든 25 스레드 학생 자가 답변 + 학생/reviewer 5 라운드 양방향 토론 4 자리** — *2025 코호트 정점 유지*.
+
+## 얻은 교훈 (도메인)
+
+1. **딜러 = 카드 분배자 (학생 자가 현실 메타포)** — *PR #117 (카드뭉치에서 꺼내서 플레이어 받는다) 와 반대 시점 양가*.
+
+2. **State 별 카드 장수 (Dealer 1장 / Player 2장)** — *State 책임 분리*.
+
+3. **블랙잭 룰 정확성 = 학생 자가 적용** (코드에 명시 없으니 추가 검증 필요).
+
+## MCP 룰 후보 신규 + 강화 (PR #109)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `state-receives-value-vs-object` | 신규 | 1 (#109) |
+| `reviewer-self-position-revision` | 신규 | 1 (#109) |
+| `metaphor-fidelity-locator` | 강화 | 11+ ⭐⭐⭐ |
+| `test-driven-domain-improvement` | 강화 | 4+ (#87·#129·#142·#109) |
+| `factory-function-vs-constructor-redundancy` | 신규 | 1 (#109) |
+| `dependency-injection-vs-internal-creation` | 강화 | 2+ (#143·#109) |
+| `constant-aggregation-vs-domain-distribution` | 신규 | 1 (#109) |
+| `assert-all-vs-multiple-assertions` | 신규 | 1 (#109) |
+| `bdd-given-when-then-fidelity` | 신규 | 1 (#109) |
+| `init-block-side-effect` | 신규 | 1 (#109) |
+| `external-flow-control-vs-internal` | 신규 | 1 (#109) |
+| `boolean-variable-naming` | 신규 | 1 (#109) |
+| `secondary-constructor-vs-default-value` | 신규 | 1 (#109) |
+| `simple-delegation-method-unnecessary` | 강화 | 5+ |
+| `function-name-vs-return-semantic-mismatch` | 강화 | 5+ |
+
+## 메타 어휘 (14 reviewer + MCP 핵심 가치 합류 정점 유지)
+
+- ***5 라운드 양방향 토론 + reviewer 자가 정정 4 자리 (Thread 13·15·17·19)*** — hyemdooly PR #109 — *학생 자가 결정 → reviewer 자가 정정 (학생 의견 인정)*.
+- ***테스트 = 도메인 설계 개선 어휘*** — hyemdooly PR #109 — *PR #87·#129·#142 결 정점 강화*.
+- ***학생 자가 현실 메타포*** — cucumber99 PR #109 — *학생이 reviewer 전에 자가 사용*.
+- ***reviewer 자가 모호 어휘 인정 + 학생 의견 인정 (Thread 19)*** — hyemdooly PR #109 — *"오 제 의견이 잘못 전달이 된 것 같은데요! 제가 모호하게 말씀을 드린 것 같네요 🙏"*. **MCP 핵심 가치 합류 정점**.
+
+→ **14 reviewer + MCP 핵심 가치 어휘 합류 정점 유지**. **2025 코호트 8 PR 코퍼스 성장**.