oh-my-oop 0.2.0

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

@@ -0,0 +1,240 @@
+# PR #148 — [블랙잭 2단계] 타마 미션
+
+- **Reviewee:** [@etama123](https://github.com/etama123)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/148
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @krrong (크롱) — *신규 reviewer*. 깊은 메타 진단 + 학생 자가 학습 모범.
+- **라인 코멘트:** 27 스레드 / 38 코멘트 — *역할 vs 상태 자가 학습 + 추상화 확장 + 콜백 vs Listener*
+
+## 잘한 점 (설계 관점)
+
+- **역할 vs 상태 자가 학습 모범** — 학생 자가 인용: *"[크롱의 저번 피드백](...)을 받고 나서 제가 **역할**과 **상태**를 명확하게 구별하지 못했던 부분을 다시 한 번 깨달았습니다 😓. 1. `Player`는 승패를 판단하는 **역할**을 담당하고 있어야 합니다. 2. `GameResult`는 승패 결과(**상태**)를 나타내는 객체여야 합니다. ... 그렇기 때문에 플레이어가 직접 경기 결과를 가지는 것은 올바르지 않다는 생각이 들었습니다. 게임 결과는 Player가 아니라 GameResult가 책임져야 한다는 점을 다시 한 번 인식하게 되었습니다. 또한, `setPlayerStatus`라는 함수명이 실제로는 승패 결과를 반환하는 함수였기 때문에, 그 함수명이 직관적이지 않다는 점도 깨달았습니다. 따라서 `getPlayerStatus`와 같이 승패를 반환하는 의미가 명확한 함수명으로 변경했습니다"*. **자가 메타 인식 + 후속 반영 + 함수명 정확성 학습 모범**.
+- **`Card.isAce()` 자기 정보 메시지 자가 학습** — 학생 자가 답변: *"`객체에 메시지를 던진다`라는 말의 의미를 잘 이해하지 못했던 것 같아요😥 그래서 이번 피드백에서는 `Card`객체가 직접 Ace 인 지 아닌지 말하도록 만들었는데, 크롱의 의도가 맞는 지 궁금합니다!"*. **Tell-Don't-Ask 자가 학습 명시 모범**.
+- **`HandStatus` enum + `from(hand)` 정적 팩토리** — 학생 자가 인용: *"`Hand` 객체에서 카드의 상태를 관리하는 조건문이 많아지면서 복잡함을 느꼈습니다. 그래서 `HandStatus` 클래스를 추가하여 카드 상태를 관리하기로 했습니다. 상태를 나타내기 위해 Enum class를 사용했고, `from` 메서드를 통해 현재 카드의 상태를 반환할 수 있도록 구현했습니다."*. PR #131·#146 와 같은 결.
+- **`Listener` 패턴 도입 자가 학습** — 학생 자가 답변: *"MVC에서 도메인과 뷰를 분리하는 방법에는 2가지가 있다고 생각합니다. 1. 고차함수로 콜백. 2. Listener 사용. 이중, 콜백은 함수 파라미터로 중복이 많이 되어, **`Listener`** 클래스를 활용해 inputView를 직접 주입받지 않도록 했습니다."*. **MVC 분리 방법 자가 비교 + 결정 모범**. PR #133·#137·#132 와 같은 결의 *EventListener/EventProvider / 고차함수 트레이드오프*.
+- **추상화 확장 의도 (플레이어 vs 플레이어, 플레이어 vs 딜러, 딜러 vs 딜러) 학습 진행** — 크롱 진단: *"플레이어와 플레이어, 딜러와 플레이어, 심지어는 딜러와 딜러 간에도 경기 결과를 계산해볼 수 있죠. 타마가 만든 참가자-딜러-플레이어를 어떻게 해야 위와 같은 상황에 대해 추상화를 잘 적용해볼 수 있을까요?"* + 학생 후속 반영. PR #49·#132·#136 와 같은 결의 *Participant 다형성 = 참가자 vs 참가자 일반화*.
+- **플레이어 + 베팅 동시 입력 자가 반영** — 크롱 진단 *"플레이어 이름을 이용해 베팅금액을 입력받고, 바로 플레이어를 생성하면 베팅금액을 Map에 저장할 필요가 없지 않을까요?"* 후속 반영 (커밋 `2107ce4`). 학생: *"코드가 더 직관적이고 단순화된 것 같습니다 😇"*. PR #103·#85·#88·#137 와 같은 결.
+- **공개 룰 도메인 이전 자가 학습** — 크롱 진단 *"최초 공개 시 딜러는 1장, 플레이어는 2장을 공개한다. 는 게임에서 정한 비즈니스 로직으로 보는 것이 적절하지 않을까요? 비즈니스 로직을 UI에서 결정하는 것이 맞는가를 고민해볼 필요가 있습니다."* + 학생 자가 학습: *"처음에는 \"카드를 보여준다\" 라는 것이 view의 역할이라고 생각했었는데, \"어떻게\" 보여줄 지는 게임의 규칙이고, 몇 장 보여줄 지는 참가자의 역할이되겠다고 생각해 도메인 로직에 적극적으로 반영했습니다"* (커밋 `184f225`). **도메인-뷰 책임 경계 자가 학습 모범**. PR #132·#137·#88 와 같은 결.
+- **베팅금 0원 검증 도메인 이전** — 크롱 진단 *"현재 베팅금액은 0원 이하를 입력받을 수 있는 것처럼 보입니다. 베팅금액이 0원보다 커야한다는 어디서 검증하는 것이 맞을지 고민해보면 좋겠네요."* + 학생 자가 학습: *"해당 예외처리는 도메인의 역할이라 생각해, 도메인 내부 init 블럭에서 예외 처리를 구현했어요"* (커밋 `b7db99d`). PR #137·#103·#136·#90·#49 와 같은 결.
+- **`runCatching` 자가 학습** — 크롱 진단 *"하나라도 입력을 잘못하면 게임이 터져버립니다. 로또에서 배운 오류 처리에 대해 고민해보고 다시 입력을 받을 수 있도록 만들어주세요."* + 학생 자가 반영 (커밋 `b6450bf`): *"`runCatching`을 사용해서 오류 처리가 가능하도록 개선했습니다"*. **Kotlin runCatching 어휘 학습**.
+- **베팅금 vs 수익 자가 인식 + GameResult 응집** — 크롱 진단 *"플레이어의 경기 결과를 가져오는데 베팅금액이 변하고 있습니다. 이는 외부에서 예측할 수 없는 점이죠. 베팅금액은 말 그대로 베팅금액입니다. 곰곰히 생각해보면 플레이어가 베팅한 금액은 변하지 않습니다. 경기 결과에 따라서 얻는 금액이 달라지는 것이고 여기서 얻는 금액이 베팅한 금액에 기반될겁니다."* + 학생 자가 답변: *"Player가 직접 본인의 배팅 결과를 반환하는 것이 어색함은 저도 동의합니다 😥. 딜러의 결과 + 수익이 \"참가자의 승패 상태\"에 따라 결정되기 때문에, 그래서 수익 계산과 딜러의 결과를 정하는 로직을 `GameResult` 내부로 변경하였습니다."* (커밋 `e88a208`). PR #85·#49 와 같은 결의 *베팅금 ≠ 수익*.
+- **테스트 자가 추가** — 크롱 진단 *"게임의 결과를 판단하는 것은 블랙잭 게임에서 가장 중요한 도메인 로직 중 하나인데, 테스트가 존재하지 않습니다."* 후속 반영.
+
+## 못한 점 (설계 관점)
+
+### 1. `Hand(cards: List<Card>)` 외부 가변 참조 — *방어적 복사 자가 인식*
+
+```kotlin
+val cards = mutableListOf(card1, card2, card3)
+val hand = Hand(cards)
+cards.clear()
+```
+
+크롱 진단 (Hand.kt — 미해결): *"어떤 일이 발생할 수 있을까요?"*
+
+학생 자가 답변: *"cards의 리스트가 비워지게 됩니다. `Hand`가 `cards`를 직접 참조하고 있기 때문에, 외부에서 `cards`에 변경이 일어나면 `hand`가 들고 있는 카드에도 변경이 일어나게 됩니다. 그래서 Hand 내부에서도 `fun getCards(): List<Card> = cards.toList()` `toList()` 연산자를 사용해서 얕은 복사가 가능하도록 구현했었습니다. 혹시 해당 방법이 틀렸던 것일까요? 😰"*
+
+→ **`toList()` getter = *읽기 방어*** + **생성자 인자 직접 참조 = *쓰기 방어 0***. *비대칭 방어*. *생성자에서 `cards.toMutableList()` 사본*이 *읽기 + 쓰기 양쪽 방어*. PR #108·#132·#133·#85·#58 와 같은 결의 *MutableList 인자 함정*.
+
+### 2. `BetAmount` enum + when else — 크롱 메타 질문
+
+크롱 진단 (BetAmount.kt — 미해결): *"enum과 when을 함께 사용하면 else문을 작성하지 않을 수 있는데요. 이를 통해 어떤 이점을 발휘할 수 있을까요?"*
+
+학생 자가 답변: *"`PlayerResultStatus` Enum class에서 빠진 값이 Draw을 추가해서 명시적으로 코드를 수정했습니다 🫡"*
+
+→ **enum + when exhaustive = else 불필요 = 컴파일러 보장**. *새 enum 멤버 추가 시 when 안 채우면 컴파일 오류*. *Kotlin 패턴 매칭 정공*. PR #137·#136·#93·#90 와 같은 결.
+
+### 3. `DealerResult` 가 *GameResult 와 중복*
+
+크롱 진단 (DealerResult.kt — 미해결): *"`DealerResult`가 하는 일은 아래와 같은 이유로 `GameResult`로 대체할 수 있는 것처럼 보입니다. 1. 플레이어의 경기 결과를 기반으로 딜러의 경기 결과를 계산할 수 있다. 2. 플레이어의 수익을 기반으로 딜러의 수익을 계산할 수 있다."*
+
+→ **`DealerResult` 별도 클래스 = 중복 가능성**. *Player 결과 기반 → Dealer 결과 도출* 라면 *GameResult 한 클래스 안*에서 *Dealer/Player 모두 표현*. PR #131·#132·#136·#49 의 *통합 GameResult* 와 같은 결.
+
+### 4. `Hand` 의 *블랙잭 = 21 무조건* 룰 부정확 — 자가 학습
+
+크롱 진단 (Hand.kt — 미해결): *"합계가 21이라고 무조건 블랙잭인것은 아닙니다. 도메인을 다시 한 번 공부해보세요."*
+
+학생 자가 후속 반영 (인용 PR #151 jerry 케이스 유사): *"그 전에는 합계가 21이면 블랙잭 상태로 바꾸는 것이였습니다. 따라서, Blackjack 객체에서 카드를 처음 나누어주는 메소드에서만 판단하기만 하면 되었기 때문에 합계가 21이면 무조건 블랙잭으로 되도록 하였습니다.😅 하지만, Hand객체의 status변수가 없어진 지금은 카드의 size가 두장임을 판단하여 블랙잭이 되도록 수정하였습니다!💪"*
+
+→ **블랙잭 룰 = 2장 + 21**. *3장 21 ≠ 블랙잭*. *학생 자가 학습 + 후속 반영 모범*. PR #128·#108·#125·#114·#131·#136·#137 와 같은 결.
+
+### 5. `GameController` 가 *Dealer 와 Player 따로 받음* — *Participant 추상 미활용*
+
+크롱 진단 (GameController.kt — 미해결): *"`Dealer`와 `Player`는 모두 `Participant`를 상속받고 있습니다. 즉, 딜러와 플레이어를 따로 받을 필요가 없다는 것이죠. 이와 비슷한 다른 부분들도 어떻게 개선할 수 있을지 고민해보면 좋겠습니다."*
+
+→ **`Participant` 추상 클래스 활용 부족**. *Dealer, Player 따로 받음 = 다형성 미활용*. *List<Participant>* 또는 *Participant 인자*로 통일. PR #132 (환노) 의 *PlayerGroup(participants).filterIsInstance* 와 *반대 트레이드오프* — *Participant 인자 통일 정공*.
+
+### 6. `addCard repeat` Controller 책임 — 크롱 진단
+
+크롱 (Participant.kt:18 — 미해결): *"컨트롤러를 보면 카드 N장을 추가하는 것을 `repeat`을 통해 진행하고 있는데요. 이 함수를 재활용할 수 있도록 만들어보면 어떨까요?"*
+
+후속 코멘트: *"는 함수 분리를 뜻하는 것이 아닌 addCard 함수 자체를 재활용 할 수 있도록 고민해보는 의도였습니다 😅"*
+
+→ **`addCard(card: Card)` vs `addCards(cards: List<Card>)` 트레이드오프**. *Controller 가 repeat 호출 = 함수 재사용 부족*. *Participant.addCards(deck.draw(2))* 같은 *vararg 또는 list 인자*가 정공. PR #132·#88 와 같은 결.
+
+### 7. `Player` 점수 비교만 = *확장성 부족*
+
+크롱 진단 (Player.kt — 미해결): *"점수를 비교하는 것은 플레이어만 가능한 것일까요? 저는 블랙잭이 추상화 기법을 공부해볼 수 있는 미션이라고 생각합니다. 참가자는 상대방과의 점수를 비교하여 결과를 내올 수 있는데요, 이는 다음과 같은 경우도 모두 판단이 가능해야 한다는 것입니다. 플레이어 vs 플레이어 / 플레이어 vs 딜러 / 딜러 vs 딜러"*
+
+→ **점수 비교 = Participant 일반 메서드**. *Player.compareScores(other: Participant)* 가 *플레이어 vs 플레이어 / 플레이어 vs 딜러 모두 표현*. *학생 자가 학습 모범 (Player only → Participant 일반화)*. PR #49·#132·#136 와 같은 결.
+
+### 8. `BetAmount` 린트 깨짐 — *PR 위생*
+
+크롱 (BetAmount.kt — 미해결): *"린트가 깨지고있습니다. 시간이 부족했던거겠죠? 😅"*
+
+→ **PR 위생 = 린트 통과**. *시간 부족 = 학생 자가 인정*. PR #147 의 *미완성 주석 잔존* 와 같은 결.
+
+### 9. `GameResult` 가 *DealerResult 코드만 이전*
+
+크롱 진단 (GameResult.kt — 미해결): *"단순히 `DealerResult`에 있던 코드를 `GameResult`로 옮겨온 것처럼 보입니다. 딜러의 게임 결과, 수익은 플레이어의 게임 결과, 수익과 관련이 있어보입니다. 그리고 이러한 정보들은 이미 `GameResult`가 가지고 있어요. 이를 적극 활용하는 방법을 고민해보면 좋겠습니다."*
+
+→ **이전만 + 적극 활용 부재**. *GameResult 가 이미 보유한 정보 (플레이어 결과) → 딜러 결과 도출* 가능. *코드 단순 이전 = 책임 분리 효과 부재*. *Player 결과 합계 → Dealer 수익 도출* 패턴.
+
+### 10. `GameController` 함수 호출 순서 — 가독성
+
+크롱 (GameController.kt:1 — 미해결): *"nit: 함수의 호출 순서대로 코드를 작성하면 가독성이 좋아질 수 있습니다."*
+
+→ **함수 정의 순서 = 호출 순서**. *호출 흐름대로 위→아래 정의*가 *호출자가 위에서 읽으며 흐름 추적*. *Kotlin 어휘 권고*. PR #131·#88 와 같은 결.
+
+### 11. `setPlayerStatus → getPlayerStatus` 함수명 자가 학습
+
+학생 자가 인용: *"또한, `setPlayerStatus`라는 함수명이 실제로는 승패 결과를 반환하는 함수였기 때문에, 그 함수명이 직관적이지 않다는 점도 깨달았습니다. 따라서 `getPlayerStatus`와 같이 승패를 반환하는 의미가 명확한 함수명으로 변경했습니다"*
+
+→ **`setXX` = 값 설정 어휘 vs `getXX` = 값 반환 어휘**. *반환 함수 = get/check/calculate 등*. *set = void/mutation*. *학생 자가 인식 + 후속 반영 모범*. PR #58·#85·#88 와 같은 결.
+
+### 12. `OutputView` 수익 출력 오류 — 자가 수정
+
+크롱 (OutputView.kt — 미해결): *"수익이 잘못출력되고 있는 것처럼 보입니다. ```##최종 승패 / 딜러: 1승 2패 0무| 수익: -3000 / a: 블랙잭 ! | 수익: 1500 / b: 승 | 수익: 2000 / c: 패 | 수익: -3000``` "*
+
+학생: *수정했습니다😰*
+
+→ **수익 계산 + 출력 형식 오류**. *플레이어 수익 합 (1500+2000-3000=500) vs 딜러 -3000* 불일치. *총합 0 게임 룰 위반*. *블랙잭 = 1.5배 vs 1배 룰 적용 오류 가능성*. *학생 자가 후속 반영*.
+
+### 13. `BetAmount` 1배~1000배 메서드 폭증
+
+크롱 (BettingMoney.kt — 미해결, PR #151 케이스 유사): *"1배 ~ 1000배까지 모든 배수가 생긴다면 1000개의 메서드가 필요한 것처럼 보입니다."*
+
+→ **배수별 메서드 폭증 안티패턴**. *PR #151 jerry 케이스 유사*. *파라미터로 배수 받기*가 정공. *PlayerBetAmount.calculate(multiplier: Double)* 한 메서드.
+
+## 리뷰어 의견 요지
+
+- **역할 vs 상태 명확 구별** — *역할 = 행위 주체*, *상태 = 변하는 값*. *Player = 역할*, *GameResult = 상태*.
+- **플레이어 vs 플레이어 / 플레이어 vs 딜러 / 딜러 vs 딜러 추상화** — *Participant 다형성 정공*.
+- **공개 룰 = 도메인 = 참가자 자기 책임** — *몇 장 공개할지 = 도메인 + 어떻게 = 게임 규칙*.
+- **베팅금 vs 수익 분리** — *베팅금 = 불변*, *수익 = 결과 + 베팅금*.
+- **enum + when exhaustive = else 불필요 = 컴파일러 보장**.
+- **MutableList 인자 직접 참조 = 외부 변경 함정** — *cards.toMutableList() 사본*.
+- **`Dealer`/`Player` 따로 받음 = Participant 다형성 미활용** — *List<Participant>*.
+- **`addCard` 재활용 = vararg/list 인자**.
+- **`Listener` vs 고차함수 콜백 트레이드오프** — *학생 자가 결정 = Listener*.
+- **`setXX` vs `getXX` 어휘** — *반환 = get, 설정 = set*.
+- **함수 호출 순서 = 정의 순서** — 가독성.
+- **린트 = PR 위생** — *시간 부족 ≠ 무시*.
+
+## 대표 인용
+
+**크롱 (Participant 다형성 = 참가자 vs 참가자, Player.kt):**
+> 점수를 비교하는 것은 플레이어만 가능한 것일까요?
+> 저는 블랙잭이 추상화 기법을 공부해볼 수 있는 미션이라고 생각합니다.
+>
+> 참가자는 상대방과의 점수를 비교하여 결과를 내올 수 있는데요,
+> 이는 다음과 같은 경우도 모두 판단이 가능해야 한다는 것입니다.
+> ```
+> 플레이어 vs 플레이어
+> 플레이어 vs 딜러
+> 딜러 vs 딜러
+> ```
+
+**크롱 (베팅금 ≠ 수익, Player.kt:15):**
+> 한발 더 나아가보면, 게임의 결과에 따라서 **플레이어의 베팅금액을 변경하는 것이 괜찮을까?** 에 대해서도 고민해볼 수 있겠어요.
+> 이전에 드린 리뷰와 비슷하게 플레이어의 경기 결과를 가져오는데 베팅금액이 변하고 있습니다. 이는 외부에서 예측할 수 없는 점이죠.
+>
+> 베팅금액은 말 그대로 베팅금액입니다. 곰곰히 생각해보면 플레이어가 베팅한 금액은 변하지 않습니다.
+> 경기 결과에 따라서 얻는 금액이 달라지는 것이고 여기서 얻는 금액이 베팅한 금액에 기반될겁니다.
+>
+> 이 역시 객체간의 협력으로 이끌어낼 수 있는 것처럼 보이네요 🤔
+
+**크롱 (공개 룰 = 도메인, OutputView.kt:1):**
+> 사실 블랙잭은 추상화 전략을 이해하고 공부해볼 수 있도록 구성되어 있는데요.
+>
+> 최초 공개 시 딜러는 1장, 플레이어는 2장을 공개한다. 는 게임에서 정한 비즈니스 로직으로 보는 것이 적절하지 않을까요?
+> 비즈니스 로직을 UI에서 결정하는 것이 맞는가를 고민해볼 필요가 있습니다.
+
+**크롱 (방어적 복사 함정, Hand.kt):**
+> ```kotlin
+> val cards = mutableListOf(card1, card2, card3)
+> val hand = Hand(cards)
+> cards.clear()
+> ```
+> 어떤 일이 발생할 수 있을까요?
+
+**크롱 (Participant 다형성 미활용, GameController.kt):**
+> `Dealer`와 `Player`는 모두 `Participant`를 상속받고 있습니다. 즉, 딜러와 플레이어를 따로 받을 필요가 없다는 것이죠.
+> 이와 비슷한 다른 부분들도 어떻게 개선할 수 있을지 고민해보면 좋겠습니다.
+
+**학생 자가 학습 (역할 vs 상태, Player.kt:15):**
+> [크롱의 저번 피드백](...)을 받고 나서 제가 **역할**과 **상태**를 명확하게 구별하지 못했던 부분을 다시 한 번 깨달았습니다 😓
+> 	1.	`Player`는 승패를 판단하는 **역할**을 담당하고 있어야 합니다.
+> 	2.	`GameResult`는 승패 결과(**상태**)를 나타내는 객체여야 합니다.
+>
+> 그렇기 때문에 플레이어가 직접 경기 결과를 가지는 것은 올바르지 않다는 생각이 들었습니다. 게임 결과는 Player가 아니라 GameResult가 책임져야 한다는 점을 다시 한 번 인식하게 되었습니다.
+> 또한, `setPlayerStatus`라는 함수명이 실제로는 승패 결과를 반환하는 함수였기 때문에, 그 함수명이 직관적이지 않다는 점도 깨달았습니다. 따라서`getPlayerStatus`와 같이 승패를 반환하는 의미가 명확한 함수명으로 변경했습니다
+>
+> 이번 리뷰는 **"객체에게 메시지를 던져라"** 는 저번 리뷰와도 이어지는 내용이라 느꼈습니다.
+
+**학생 자가 학습 (Listener vs 콜백 트레이드오프, InputView.kt:1):**
+> MVC에서 도메인과 뷰를 분리하는 방법에는 2가지가 있다고 생각합니다.
+> 1. 고차함수로 콜백
+> 2. Listener 사용
+>
+> 이중, 콜백은 함수 파라미터로 중복이 많이 되어, **`Listener`** 클래스를 활용해 inputView를 직접 주입받지 않도록 했습니다.
+
+**학생 자가 학습 (Tell-Don't-Ask 자가 인식, Card.kt:11):**
+> `객체에 메시지를 던진다`라는 말의 의미를 잘 이해하지 못했던 것 같아요 😥
+> 그래서 이번 피드백에서는 `Card`객체가 직접 Ace 인 지 아닌지 말하도록 만들었는데, 크롱의 의도가 맞는 지 궁금합니다!
+
+**학생 자가 학습 (공개 룰 도메인 이전, OutputView.kt):**
+> Dealer와 Player의 추상 클래스 `Participant`에서 추상 메서드를 추가했어요!
+>
+> 처음에는 "카드를 보여준다" 라는 것이 view의 역할이라고 생각했었는데, "어떻게" 보여줄 지는 게임의 규칙이고, 몇 장 보여줄 지는 참가자의 역할이되겠다고 생각해 도메인 로직에 적극적으로 반영했습니다 ☺️
+
+**학생 자가 학습 (Racing Car 피드백 인용, Deck.kt):**
+> 코드를 작성한 입장에서, 내가 아는 정보를 바탕으로 한 변수명을 작성했던 것 같습니다 ㅜ.ㅜ
+> **Racing Car 미션**에서부터 이야기가 되던, _객체 안에서는 외부의 상황을 알 필요가 없다_ 피드백이 지켜지고 있지 않았었네요.
+> 이번 피드백을 초석으로, 앞으로는 이런 실수가 없도록 해보겠습니다 💪
+
+## 얻은 교훈
+
+1. ***역할 vs 상태 명확 구별 = OOP 핵심 개념***. *Player = 승패 판단 역할 (행위 주체)*, *GameResult = 승패 결과 상태 (변하는 값)*. *학생 자가 인식 + 메타 학습 모범*. **MCP 룰 후보 — `role-state-conflation`**.
+
+2. ***참가자 vs 참가자 = Participant 다형성 = 추상화 정공***. *플레이어 vs 플레이어 / 플레이어 vs 딜러 / 딜러 vs 딜러 모두 표현 가능*. *Participant.compareScores(other: Participant)* 메시지. PR #49·#132·#136 와 같은 결.
+
+3. ***공개 룰 = 도메인 + 몇 장 = 참가자 자기 책임 + 어떻게 = 게임 규칙***. *학생 자가 학습 모범*. *UI 책임 vs 도메인 책임 경계 명료성*. PR #132·#137·#88 와 같은 결.
+
+4. ***베팅금 vs 수익 분리 = 베팅금 불변 + 수익 = 결과 + 베팅금 도출***. *Player.bettingAmount val 불변*. *GameResult 가 수익 계산*. PR #85·#49·#137·#88 와 같은 결.
+
+5. ***Listener vs 고차함수 콜백 트레이드오프***. *Listener = 명시적 인터페이스 + 다양한 구현*. *콜백 = 함수 파라미터 중복 가능성*. *학생 결정 = Listener (콜백 중복 회피)*. PR #133·#137·#132 와 같은 결의 *EventListener/EventProvider*.
+
+6. ***`MutableList` 인자 직접 참조 = 외부 변경 함정***. *getter `toList()` 만 = 읽기 방어 + 쓰기 방어 0*. *생성자에서 `cards.toMutableList()` 사본*이 *양쪽 방어*. PR #108·#132·#133·#85·#58·#146 와 같은 결.
+
+7. ***`Participant` 다형성 미활용 = Dealer/Player 따로 받기 = 코드 중복***. *List<Participant>* 또는 *Participant 인자*로 통일. PR #132·#88 와 같은 결.
+
+8. ***enum + when exhaustive = else 불필요 = 컴파일러 보장***. *새 enum 멤버 추가 시 when 안 채우면 컴파일 오류*. *Kotlin 패턴 매칭 정공*. PR #137·#136·#93·#90·#137 와 같은 결.
+
+9. ***`setXX` vs `getXX` 함수명 = 반환 vs 설정 어휘***. *setPlayerStatus 가 반환 함수 = 이름 misleading*. *학생 자가 인식 + 후속 반영 모범*. PR #58·#85·#88 와 같은 결.
+
+10. ***Tell-Don't-Ask 자가 학습 = "객체에 메시지를 던진다" 의미 자가 학습***. *Card.isAce() = 자기 정보 자기 메시지*. *학생 자가 인용 + reviewer 인정 ("정확히 이해하신 것 같습니다 👍")*.
+
+11. ***블랙잭 = 21 무조건 X = 2장 + 21 정확***. *학생 자가 학습 + 후속 반영*. PR #128·#108·#125·#114·#131·#136·#137 와 같은 결.
+
+12. ***`addCard` 재활용 = vararg/list 인자***. *Controller repeat 호출 회피*. *Participant.addCards(cards: List<Card>)* 단일 메서드. PR #132·#88 와 같은 결.
+
+13. ***`runCatching` Kotlin 어휘 = 에러 처리***. *try-catch 대신 함수형 어휘*. PR #136 (밀러) 의 *NullableRetry/ThrowableRetry* 와 같은 결의 *에러 처리 추상화*.
+
+14. ***Racing Car 피드백 인용 (이전 미션 학습 누적) = 학습 가시화 모범***. *_객체 안에서는 외부의 상황을 알 필요가 없다_ 피드백 인용 + 후속 반영*. PR #103 (해나) 의 *1단계 피드백 인용* 와 같은 결.
+
+15. ***`DealerResult` + `GameResult` 중복 = 통합 정공***. *Player 결과 기반 → Dealer 결과 도출*. *GameResult 한 클래스 안에서 표현*. PR #131·#132·#136·#49 와 같은 결.
+
+16. ***학생 자가 학습 + 자가 답변 + 커밋 SHA 첨부 풍부 = 학습 가시화 최고 수준***. *역할 vs 상태 / Tell-Don't-Ask / Listener vs 콜백 / 공개 룰 도메인 이전 / 방어적 복사 모두 자가 학습 메타 인식 + 후속 반영*. PR #128·#135·#108·#133·#137·#146·#41·#88·#136 와 같은 결.
+
+17. ***신규 reviewer 크롱 (krrong) = 깊은 메타 진단 + 추상화 확장 (플레이어 vs 플레이어 vs 딜러)***. *PR #131·#136·#88 (두루) / PR #41·#53 (잭슨) / PR #93·#108·#133 (말리빈) / PR #124·#85·#103·#58·#49·#152 (페로로) / PR #137 (지훈) / PR #146 (두루)* 외 *신규 reviewer 스타일 추가*. **프로젝트 reviewer 다양성 명시**.

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

@@ -0,0 +1,146 @@
+# PR #102 — [블랙잭 2단계] 벼리 미션
+
+- **Reviewee:** [@gaeun5744](https://github.com/gaeun5744)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/102
+- **단계:** 2단계
+- **리뷰어:** [@vagabond95](https://github.com/vagabond95) — 1단계 #69 동일 reviewer
+- **라인 코멘트:** 13 스레드 — *PR 본문 자가 의문 (공통 로직 묶는 방법 + Dealer/Player playTurn 시그니처 차이) + 학생 자가 의문 (factory deck 의존성, abstract vs interface) + reviewer *추상함수 기준보다 추상 클래스와 인터페이스 사용 기준* 메타 어휘 + 람다 named parameter 권유 + API 일관성 어휘 + 람다 네이밍 = 외부 상황 X 어휘*
+- **양 단계 완성 reviewee** (1단계 #69 batch 23 완료 + 2단계 #102 = batch 24).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 + 시그니처 차이 학습
+
+PR 본문:
+
+> *"`Dealer`와 `Player`를 보면 공통적으로 `playTurn` 로직이 있습니다. 둘의 로직은 비슷하지만, 반환값과 파라미터가 약간 다릅니다. (...) 그래서 부득이하게 `Finish`를 반환하기 어려워서 둘의 로직을 공통으로 묶지 못했는데, 이러한 상황에서는 어떻게 대처해야할지 몰라 질문 드립니다."*
+
+→ **시그니처 차이 추상화 한계 학생 자가 의문** = PR #126·#140·#69 결 합류 누적 4+ PR.
+
+### 2. 학생 자가 abstract vs interface 의문 (Thread 2)
+
+학생:
+
+> *"혹시 해당 구현을 `abstract`가 아닌 `interface`로도 바꿔도 무방한 코드일까요? 저는 추상함수를 사용하는 기준이 다음과 같이 두가지 라고 생각합니다.*
+> *- 클래스간 공통된 로직을 묶을 때*
+> *- 클래스 간 연간관계가 강할 때 (...) 현재의 로직은 구현부가 없고 시그니처만 존재하고 있기 때문에, 인터페이스를 사용하는 것과 큰 차이점을 못 느끼고 있습니다."*
+
+reviewer:
+
+> *"인터페이스를 사용하는 것과 큰 차이가 없다면, 반대로 다중 상속이 가능하여 비교적 제약이 적은 인터페이스를 사용하지 않을 이유가 있을까요? :)*
+>
+> *추상함수는 말씀하신 것처럼 인터페이스의 함수 시그니쳐와 동일하므로, 추상함수를 사용하는 기준보다는 추상 클래스와 인터페이스를 사용하는 기준을 잡아보는게 좋을 것 같은데요."*
+
+→ **학생 자가 Kotlin 어휘 깊은 학습 + reviewer 메타 어휘 (기준 재정의)** = PR #129·#126·#138·#142·#143·#113·#19·#69 결 합류 누적 9+ PR.
+
+### 3. 학생 자가 *deck 의존성 vs card 전달* 의문 (Thread 1)
+
+학생:
+
+> *"`Players`와 `Dealer`가 `Deck`을 가지고 있는 상황이 어색하여, 팩토리 함수를 이용해 `gamePlayers`를 초기화 하였습니다. 다만, 이렇게 하는 방식이 과연 옳은지에 관해 의문이 들었습니다."*
+
+reviewer:
+
+> *"deck 을 꼭 주입받아야하는지 고민해보면 좋겠어요. card 만 전달받아도 충분하지 않을까요?"*
+
+학생 자가 적용: *고차함수로 받기*.
+
+→ **deck 의존성 제거 학생 자가 학습** = PR #69 1단계 결의 *2단계 학생 자가 정공*. **MCP 룰 `object-ownership-vs-parameter-passing` 강화** 누적 4+ PR.
+
+### 4. 추가 칭찬
+
+- Thread 8: *"enum 활용 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. 람다 named parameter 권유 (Thread 6)
+
+reviewer:
+
+> *"람다를 넘길 때는 named parameter 를 습관해주시면 좋습니다~! 현재와 같은 코드는 어떤 람다인지 구분이 불가능해서 가독성이 많이 떨어질 것 같아요."*
+
+→ **Kotlin named parameter 가독성** = **MCP 룰 `kotlin-named-parameter-readability` 후보**.
+
+### 2. API 일관성 어휘 (Thread 7)
+
+reviewer:
+
+> *"times 함수는 하나만 제공해도 되지 않을까요? 혹은 Float 형도 지원해야하지 않을까요? API 는 일관된 규칙을 가지고 있어, 코드를 쉽게 예측할 수 있으면 좋다고 생각합니다 ㅎㅎ"*
+
+→ **API 일관성 어휘** = **MCP 룰 `api-consistency-criteria` 후보** — *함수 1 개 vs 모든 타입 지원 양쪽 일관성*.
+
+### 3. 람다 네이밍 = 외부 상황 X (Thread 13)
+
+reviewer:
+
+> *"앞으로도 람다의 네이밍을 지을 때 항상 명심하면 좋을 부분입니다. 람다는 외부의 상황을 알지 못하고, 철저히 람다를 사용하는 입장에서 네이밍이 지어져야합니다!"*
+
+→ **람다 네이밍 = 사용 입장 어휘** = *PR #36 (Domain/View 비용 메타포) 결 합류*. **MCP 룰 `lambda-naming-from-user-perspective` 후보**.
+
+### 4. show 알기 model = view 책임 (Thread 9)
+
+reviewer: *"\"show\" 할 것이라는 것을 model 이 알고 있는 것이 어색하지 않을까요?"*
+
+→ **Model→View 분리** = 누적 15+ PR ⭐⭐⭐.
+
+### 5. setResult vs getResult 명명 (Thread 10)
+
+reviewer: *"해당 함수는 gameResult 를 반환하는 것인지 Result 를 Set 하는 것인지 코드를 직접 보기 전까지는 알기가 어려울 것 같아요."*
+
+→ **이름 의미 정확성** = 누적 13+ PR.
+
+### 6. Result 일급 컬렉션 (Thread 11)
+
+reviewer: *"Result 도 별도 클래스로 묶어봐도 좋겠습니다~!"*
+
+→ **일급 컬렉션** = 누적 다수.
+
+### 7. require init 검증 중복 (Thread 12)
+
+reviewer: *"require 문이 중복되는데, 클래스의 init 블록에서 한번에 검증해도 좋겠습니다~!"*
+
+→ **검증 중복 자가 정리** = PR #69·#109 결 합류.
+
+### 8. players turn + dealer turn 함수 명명 (Thread 4)
+
+reviewer: *"players trun 인데 dealer turn 도 진행되는게 어색한 것 같아요. 함수를 분리하거나 네이밍을 수정해야하지 않을까요~?"*
+
+→ **함수 명명 의미 정확성**.
+
+### 9. 매직넘버 BLACKJACK_NUMBER 재활용 (Thread 3)
+
+학생 자가 *매직넘버 제거 까먹음* 인정.
+
+→ **매직넘버 상수화** = 누적 다수.
+
+### 10. 상태 = 파라미터 받지 말고 멤버 (Thread 5)
+
+reviewer: *"상태로 가지고 있으므로, 파라미터로 받을 필요가 없지 않을까요?"*
+
+→ **parameter vs self state access** = PR #140·#143 결 합류.
+
+## 대표 인용
+
+> [vagabond95 Thread 2]
+> *"추상함수를 사용하는 기준보다는 추상 클래스와 인터페이스를 사용하는 기준을 잡아보는게 좋을 것 같은데요."*
+
+→ **reviewer 메타 어휘 (기준 재정의)**.
+
+> [vagabond95 Thread 13]
+> *"람다는 외부의 상황을 알지 못하고, 철저히 람다를 사용하는 입장에서 네이밍이 지어져야합니다!"*
+
+→ **람다 네이밍 사용 입장 어휘**.
+
+> [vagabond95 Thread 7]
+> *"API 는 일관된 규칙을 가지고 있어, 코드를 쉽게 예측할 수 있으면 좋다고 생각합니다"*
+
+→ **API 일관성 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **시그니처 차이 추상화 한계** = 누적 4+ PR.
+2. **추상 클래스 vs 인터페이스 기준** = 누적 9+ PR.
+3. **람다 named parameter 가독성** — **MCP 룰 `kotlin-named-parameter-readability` 후보**.
+4. **API 일관성 어휘** — **MCP 룰 `api-consistency-criteria` 후보**.
+5. **람다 네이밍 = 사용 입장** — **MCP 룰 `lambda-naming-from-user-perspective` 후보**.
+6. **deck 의존성 제거 학생 자가 학습 시간성 (PR #69 → #102)** = *학습 시간성 정공*.

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

@@ -0,0 +1,224 @@
+# PR #69 — [블랙잭 1단계] 벼리 미션
+
+- **Reviewee:** [@gaeun5744](https://github.com/gaeun5744)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/69
+- **단계:** 1단계
+- **리뷰어:** [@vagabond95](https://github.com/vagabond95) — 2023 코호트 (racingcar 인용 reviewer) + 2024 reviewer
+- **라인 코멘트:** 20 스레드 — *Domain ↔ View 분리 5+ 자리 + 학생 자가 *type-safe enum class* 의문 + CardMachineManager 인터페이스 학생 자가 *확장성* 명시 + handle 이름 정확성 + Judge 객체 vs Dealer 책임 4 라운드 깊은 양방향 토론 + reviewer *현실 세계 투영 = 필수 X, 필요할 때 사용 도구* 메타 어휘 + 상태 패턴 자가 적용*
+- **신규 reviewee** (2024 코호트, 새 1단계 분석).
+
+## 잘한 점 (설계 관점)
+
+### 1. 학생 자가 *type-safe enum class* 의문 (Thread 1)
+
+학생:
+
+> *"그렇다면 문자열이 포함된 `enum class`들은 따로 util 패키지에 두는게 맞을까요...? 문자열을 없앨까 라는 생각도 들었지만, 이는 상수를 `type-safe`하게 다루는 enum class의 장점을 활용하지 못한다는 생각이 들어서 패키지를 옮기는 쪽으로 생각했습니다!!"*
+
+→ **학생 자가 *type-safe* + *enum class 장점 활용* 어휘** = *Kotlin 어휘 깊은 자가 학습*. **MCP 룰 `student-self-type-safe-vocabulary` 후보**.
+
+reviewer 자가 정정:
+
+> *"CompetitionResult 를 enum 으로 구현하고, 이것이 model 패키지에 있는 것은 자연스럽다고 생각해요. 제가 코멘트를 남겼던 것은 enum 자체가 문제가 된다기보다 model 에서 view 에서 사용될 값을 알고 있는 것이 어색해보였어요."*
+
+→ **reviewer 자가 의도 명료화** = PR #142 결 합류.
+
+### 2. CardMachineManager 인터페이스 + 학생 자가 *확장성* 명시 (Thread 2)
+
+학생 자가 답변:
+
+> *"`ShuffleCardMachine` 및 `BlackjackCardMachine` 등의 상태를 싱글톤으로 만드는게 문맥상 옳다고 생각해서 해당 `CardMachineManager object`를 만들었습니다. 만약 예시의 클래스들을 그냥 object로 만들 경우, 해당 클래스에 직접 접근해서 다른 Deck 클래스를 만든 후, 수정해야 하기 때문에 Deck 객체의 확장성이 저해된다고 생각했습니다."*
+
+학생 자가 후속: `shuffle` → `handle` 이름 자가 변경.
+
+reviewer 칭찬: *"handle 로 수정되니, 구현의도가 명확해진 것 같아요. 카드를 분배하는 방식을 인터페이스로 유연하게 다루는 것은 좋은 시도 같습니다 👍"*
+
+→ **학생 자가 *유연성* 의식 + 자가 명명 정정** + **인터페이스 = 카드 분배 방식 유연** = PR #138·#142·#143 결 합류.
+
+### 3. Judge 객체 vs Dealer 책임 — 4 라운드 깊은 양방향 토론 (Thread 12)
+
+학생 자가 답변:
+
+> *"따로 `Judge`라는 객체를 둘까라는 생각도 했지만, 현실 세계에 빗대어 봤을때 문맥이 어색해 보여서 `Dealer` 객체에 두었습니다! 왜냐하면 실제로 승패를 판단하는건 딜러이며, 딜러가 승패 결과에 따라 칩을 직접 놔눠주기 때문에 추후 리팩토링을 위해서 `Dealer` 객체에 두었습니다.*
+>
+> *또한, 원래부터 딜러라는 역할 자체가 책임이 많은 역할이라는 생각에 무의식중에 괜찮지 않을까? 라는 생각이 들었습니다.*
+>
+> *제리는 책임이 많은 역할에 대해 어떻게 생각하시나요? 현실 세계에서는 책임이 많은 역할이더라도, 프로그래밍 세계에서는 역할을 책임을 쪼개서 새로운 객체를 탄생시키는게 옳다고 생각하시나요?"*
+
+reviewer (메타 어휘):
+
+> *"벼리의 말도 일리가 있다고 생각해요. 도메인을 어떻게 해석하느냐에 따라 관점을 다르게 볼 수 있겠네요!*
+>
+> *좋은 질문이고, 굉장히 어려운 내용이라고 생각해요. 저도 잘 지키고 있는지 모르겠네요 ㅎㅎ;*
+> *저 같은 경우 현실세계의 도메인을 잘 투영하려고 노력하지만, 읽고 유지보수하기 쉬운 코드인가? 를 더 중요하게 생각하고 구현하는 것 같아요.*
+>
+> *읽고 유지보수하기 쉬운 코드는 기본적으로 수행하는 역할이 명확하고, 잘 분리되어야 한다고 생각해서 위와 같은 코멘트를 남기게 되었네요 ㅎㅎ*
+>
+> *벼리의 명확한 기준이 있다면, 우선 그 방향으로 진행해보고 추후에 구현이 막힐"*
+
+학생 자가 후속 의문:
+
+> *"그렇다면 제리는 역할과 책임이 명확하고 읽기 쉬운 코드를 작성하는데 있어서, 현실 세계의 도메인을 투영하는 것은 필수가 아니라 필요할때 사용하는 도구라 생각하시나요?*
+>
+> *사실 현실 세계를 투영한다고 해도, 다양한 정렬 방식을 제공하는 `CardMachine`이 실제로는 존재 하지 않지만 유지보수성을 위해 추가한 것처럼, 어디까지 현실 세계를 의인화할지 아직도 고민입니다."*
+
+→ **현실 메타포 vs 유지보수성 트레이드오프 깊은 메타 어휘** = *PR #117·#129·#130·#143·#109·#113·#118·#71·#96 (현실 메타포 정합) 결의 *반대 시점 (학생 자가 메타 의문)***. **MCP 룰 `metaphor-fidelity-vs-maintenance-tradeoff` 후보** — *현실 메타포 = 도구 vs 필수* 학생 자가 메타 의식.
+
+PR #118 (현실 메타포 vs SRP 트레이드오프) 결의 *학생 자가 깊은 의문* 어휘 합류.
+
+### 4. 상태 패턴 자가 적용 (Thread 17)
+
+reviewer: *"결과를 판단하는 조건식이 복잡한데요, 조건식의 순서도 중요하고 조금만 요구사항이 추가되어도 이해하기가 쉽지 않을 것 같아요 😢 객체지향의 다형성을 이용하여 코드를 좀 더 간결하게 만들어보는 방법은 없을까요?"*
+
+학생: *"상태 패턴을 이용해서 코드를 좀 더 간결하게 해봤습니다...!!"*
+
+→ **State 패턴 자가 적용** = PR #93·#136·#152·#98·#36·#87·#142·#143·#138·#153 결 합류 누적 11+ PR.
+
+### 5. 추가 칭찬
+
+- Thread 18: *"확장함수 활용 👍 패키지도 view 에 잘 선언해주셨네요!"*.
+- Thread 19: *"이전보다 훨씬 코드가 간결해졌네요 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. Domain ↔ View 분리 5+ 자리 (Thread 1·3·6·7·8)
+
+reviewer 가 5+ 자리에서 *view 값 (result/value/shape/이름 출력 함수)* 도메인 외부 권유.
+
+→ **MVC 원칙 정공** = PR #126·#143·#149·#19·#35·#68 결 합류 누적 15+ PR ⭐⭐⭐.
+
+### 2. Pattern 명명 = 정규식 충돌 (Thread 6)
+
+reviewer: *"Pattern 은 정규식에 사용되는 클래스의 이름이기도 해서 좀 더 구체적인 네이밍이 들어가면 좋겠습니다 :)"*
+
+→ **Kotlin/Java 표준 라이브러리 명명 충돌** = PR #130 (Number vs kotlin.Number), PR #142 (Result vs kotlin.Result) 결 강화 누적 3+ PR.
+
+### 3. HandCards 가 Deck 가짐 자연성 X (Thread 5·16)
+
+reviewer: *"HandCards 는 플레이어가 소지하고있는 카드를 표현하는 도메인으로 보이는데요, 전체 카드 덱을 같이 소지하고 있는 부분이 어색한 것 같아요. 필요할 때만 카드를 전달받는것이 도메인의 흐름상 좀 더 자연스럽지 않을까요?"*
+
+→ **카드 전달 vs Deck 소유** = PR #96·#138 결의 *손이 덱과 카드를 동시에 아는가* 어휘 합류.
+
+### 4. Player.deck 멤버 → 카드 전달 (Thread 13)
+
+reviewer:
+
+> *"Player, Dealer 가 deck 을 가지고 있는 이유는 card 를 추가해주기 위함인데요. deck 을 멤버로 가지고 있기보다, 필요시 card 만 전달받는 것은 어떨까요?*
+>
+> *현 구조에서는 테스트시에도 deck 을 매번 주입해줘야하는데, deck 에 대한 의존성을 줄여봐도 좋을 것 같습니다."*
+
+학생 자가 적용: *팩토리 함수 통해 deck 전달*.
+
+→ **객체 소유 vs 매개변수 전달** = PR #138 (rosemin928 *deck 매개변수 전달 = 소유 X*) 결 합류.
+
+### 5. isWantAddCard 외부 의존 (Thread 14)
+
+reviewer:
+
+> *"isWantAddCard 여부를 Player 가 꼭 알 필요가 있을까요? 해당 구현은 외부에 의한 조건인데, `카드가 주어지면 더한다.` 의 역할이 더 간결하고 명확할 것 같아요."*
+
+학생 자가 답변:
+
+> *"메시지는 최대한 추상적이고 명료해야 하는데, 그 법칙을 제대로 지키지 못한것 같네요ㅠㅠ 지적해주셔서 감사합니다!!"*
+
+→ **메시지 추상화 어휘 + Tell-Don't-Ask** = PR #129·#142·#143 결 합류.
+
+### 6. GameParticipant.addCard 추상화 미적용 (Thread 15)
+
+reviewer: *"addCard 도 필수적인 함수로 보이는데 상위 클래스에서는 선언되지 않은 이유가 무엇일까요?"*
+
+학생: *"`Dealer` 객체와 `Player` 객체의 시그니처가 달라서 넣지 않았습니다ㅠ"*
+
+→ **시그니처 차이 추상화 한계** = PR #126·#140 결 합류. 학생 자가 수정.
+
+### 7. Players init 검증 중복 (Thread 10)
+
+reviewer: *"해당 검증은 내부의 init 블록이 아니라 별도함수로 분리해서 검증하는 이유가 있을까요?"*
+
+학생: *"`validateDuplicateNames`을 제거하면, `names.toSet()`에서 저절로 중복이 제거된 채 객체가 생성되기 때문에 추가했습니다! 지금 다시 보니 init 블록 내 검증과 겹치는거 같아서 이쪽 검증을 제거하겠습니다!"*
+
+→ **검증 중복 자가 인지** = PR #109 (validation-function-vs-require-inline) 결 합류.
+
+### 8. Deck.draw 리턴 List<Card> 확장성 (Thread 4)
+
+reviewer: `removeFirst()` 활용 권유.
+
+학생 자가 답변:
+
+> *"해당 `draw`메서드의 반환 타입이 `List<Card>`라서 어쩔 수 없이 여러 줄로 작성했습니다ㅠ 처음 블랙잭 게임을 시작할 때 카드를 두장 뽑는데, 이때 같은 메서드를 두번 사용하기 보다는 파라미터로 뽑고자 하는 카드의 개수를 전달하는 것이 확장성에 좋을것 같아서 이렇게 구현했습니다!!"*
+
+→ **학생 자가 *확장성* 의식** = *PR #138·#142 결의 *유연성 vs 현재 룰* 어휘 합류*.
+
+### 9. InputView 분리 기준 (Thread 11)
+
+학생 자가 답변:
+
+> *"다음과 같이 두가지 기준으로 뷰를 분리했습니다.*
+> *1. 객체를 생성해서 던질 수 있는가 (도메인 객체를 단위로 해서 뷰를 분리했습니다.)*
+> *2. 비슷한 함수끼리 엮을 수 있는가"*
+
+→ **학생 자가 분리 기준 명시** = *PR #126·#130·#117 결의 *학생 자가 분류* 합류*.
+
+### 10. `playerInput` 모호 명명 (Thread 9)
+
+reviewer: *"playerInput 은 너무 이름이 모호한 것 같아요. 좀 더 구체적인 네이밍으로 지어볼 수 있을까요?"*
+
+→ **이름 의미 정확성** = 누적 13+ PR.
+
+### 11. Player 의 상태 자가 결정 (Thread 20)
+
+reviewer: *"상태가 스스로 다음 상태를 결정하도록 리펙토링 해봐도 좋을 것 같습니다!"*
+
+→ **State 패턴 자식 자가 결정** = PR #93·#136·#152·#98 결 합류.
+
+## 대표 인용
+
+> [vagabond95 Thread 12]
+> *"저 같은 경우 현실세계의 도메인을 잘 투영하려고 노력하지만, 읽고 유지보수하기 쉬운 코드인가? 를 더 중요하게 생각하고 구현하는 것 같아요."*
+
+→ **현실 메타포 vs 유지보수성 메타 어휘**.
+
+> [gaeun5744 Thread 12]
+> *"그렇다면 제리는 역할과 책임이 명확하고 읽기 쉬운 코드를 작성하는데 있어서, 현실 세계의 도메인을 투영하는 것은 필수가 아니라 필요할때 사용하는 도구라 생각하시나요?"*
+
+→ **학생 자가 *현실 메타포 = 도구* 메타 의문**.
+
+> [gaeun5744 Thread 1]
+> *"이는 상수를 `type-safe`하게 다루는 enum class의 장점을 활용하지 못한다는 생각이 들어서"*
+
+→ **학생 자가 *type-safe* Kotlin 어휘**.
+
+> [gaeun5744 Thread 14]
+> *"메시지는 최대한 추상적이고 명료해야 하는데, 그 법칙을 제대로 지키지 못한것 같네요ㅠㅠ"*
+
+→ **학생 자가 *메시지 추상화* 메타 학습**.
+
+## 얻은 교훈 (보편)
+
+1. **현실 메타포 vs 유지보수성 트레이드오프** — **MCP 룰 `metaphor-fidelity-vs-maintenance-tradeoff` 후보**.
+
+2. **학생 자가 *type-safe* / *확장성* / *메시지 추상화* Kotlin/OOP 어휘** — **MCP 룰 `student-self-type-safe-vocabulary` 후보**.
+
+3. **Kotlin/Java 표준 라이브러리 명명 충돌 (Pattern)** — 누적 3+ PR.
+
+4. **카드 전달 vs Deck 소유** — PR #96·#138 결 누적 3+ PR.
+
+5. **시그니처 차이 추상화 한계 → 학생 자가 수정** = 누적.
+
+6. **검증 중복 자가 인지** = PR #109 결.
+
+7. **상태 패턴 자가 적용 (조건식 복잡 → 다형성)** = 누적 11+ PR.
+
+8. **InputView 분리 기준 학생 자가 명시** = 누적.
+
+## MCP 룰 후보 신규 + 강화 (PR #69)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `metaphor-fidelity-vs-maintenance-tradeoff` | 신규 | 1 (#69) |
+| `student-self-type-safe-vocabulary` | 신규 | 1 (#69) |
+| `class-name-vs-stdlib-collision` | 강화 | 3+ (#130·#142·#69) |
+| `model-view-dependency-direction` | 강화 | 15+ ⭐⭐⭐ |
+| `state-children-method-vs-external-when` | 강화 | 11+ |
+| `object-ownership-vs-parameter-passing` | 강화 | 3+ |
+| `function-name-vs-return-semantic-mismatch` | 강화 | 13+ |