oh-my-oop 0.2.0

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

@@ -0,0 +1,282 @@
+# PR #100 — [블랙잭 2단계] 팡태 미션
+
+- **Reviewee:** [@Hevton](https://github.com/Hevton)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/100
+- **단계:** 2단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 16 스레드 — *Wallet 클래스 (지갑이 이름 보유) 자가 인정 + Game 도메인 위치 자가 의문 + 디미터 법칙 어휘 + participantState var 외부 변경 자가 학습*
+- **양 단계 분석 reviewee** (1단계 #82 별도).
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 정리** — *"이번 미션에서는, 저번 미션에서 마지막으로 남겨주신 피드백도 반영했습니다! 그리고 Answer 도메인 로직 관련하여 남겨주신 코멘트는 #82 에 함께 남겼습니다."* — **1단계 PR URL 자가 참조 + 머지 후 후속 토론 명시**. PR #99·#46·#95·#39·#145·#23 결.
+- **다형성 정리 칭찬** — KwonDae: *"공통로직 중복이 없어지면서 다형성 관점에서 어떤 차이점이 있는지 명확해졌네요 👍"* — *PR #82 1단계의 Human 추상화 진화*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Wallet 클래스 = 이름이 지갑에` — 학생 자가 *지갑 안 신분증* 비유 정당화 후 자가 변경
+
+KwonDae: *"Wallet이라는 새로운 클래스가 생성되었네요. `참가자는 지갑을 갖고있고, 지갑은 'John'이라는 이름을 갖는다`. 참가자가 이름을 갖는게 아닌 지갑이 참가자 이름을 갖게되었는데 조금 어울리지 않다는 느낌이 들었습니다. 이렇게 구현하신 이유가 있을까요?"*
+
+학생: *"객체가 갖고 있는 인스턴스 변수의 개수를 두 개로 줄이기 위해 계층 구조를 만들게 되었습니다. 제가 생각했을 때엔 지갑 안에 신분증 같은 것으로 생각했는데, 너무 제 기준에서만 생각한 것 같습니다. 알려주셔서 감사합니다. 해당 부분은 네이밍을 변경했습니다!"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *3 변수 제약 부산물 인공 객체*
+
+- *Player(name, money, hand)* — 3 변수 + 제약 위반.
+- *Player(wallet, hand)* — wallet 에 name + money — *부산물 객체*.
+
+**MCP 기존 룰 `3-variable-constraint-artifact`** (PR #98·#133·#88·#132·#136·#93·#39 결) 강화.
+
+#### 1.2. *학생 자가 *지갑 안 신분증* 비유 정당화*
+
+*비유 = 정당화 시도* 였으나 *공유 가능성 검증 X* → 자가 인정 + 자가 변경.
+
+#### 1.3. *현실 메타포 검증 = 공유 가능성*
+
+*"지갑 안 신분증"* = 학생 개인 비유 → *공유 가능한 도메인 어휘 X* → 명명 변경.
+
+PR #74 (송핑크 *Referee 자가 토론*) / PR #46 (krrong *라면 비유*) 결의 *비유 검증* 변형.
+
+### 2. `participantState var 외부 변경 가능` — 동시성 vs 개방폐쇄 자가 학습
+
+KwonDae 1차: *"`open var wallet: Wallet` 지갑을 변경가능한 구조로 만드신 이유가 궁금합니다. 새로운 지갑으로 대체될 수 있는건가요?"*
+
+KwonDae 2차: *"`open var participantState: ParticipantState` 현재 participantState는 Participant를 상속하는 Dealer, Player 를 사용하는 모든곳에서 접근이 가능하며 변경이 가능합니다. 이에 따른 사이드 이펙트는 어떤게 있을까요?"*
+
+학생 1: *"Player의 이름을 먼저 List<String>으로 받아서 List<Player>를 생성하고, 그 이후에 금액들을 세팅해주는 과정이 필요했다는 이유로 지갑을 변경가능한 구조로 만들게 되었습니다. 하지만 굳이 지갑을 변경 가능하게까지 만들지 않더라도, Player 생성 과정에서 플레이어 이름과 돈을 함께 받아서 생성하면 더 낫겠다고 생각하여 그렇게 바꿨습니다!"*
+
+학생 2 (자가 의문): *"현재 ParticipantState를 var로 선언하여 외부에서 변경이 가능한 문제를 인지했습니다. 이로 인해 동시성 문제가 발생할 수도 있겠다고 생각이 들었습니다. 하지만 동시에 궁금한 점은, 결국 ParticipantState를 외부에서 접근할 수 없더라도 Pariticpant는 ParticipantState를 변경하는 로직을 갖고 있으므로 (e.g hit 함수) 이 함수를 결국 여러 곳에서 호출하면 동시성 문제가 똑같이 발생하지 않을까 라는 생각이 드는데, 제가 잘못 바라보고 있는 부분이 있을까요??"*
+
+KwonDae 메타 답변:
+
+> *"이 부분에 대한 중요한 관점은 participantState 를 개방해야 하는 프로퍼티인가? 입니다. 이 코드를 구현한 사람은 `participantState는 외부에서 접근하여 수정하지 않아야 하는 값` 을 알고 있다 하더라도, 동료개발자가 Player, Dealer 외 새로운 Player 타입이 생겨 Participant를 상속하는 새로운 Player를 생성한다고 가정해볼게요. state가 바뀌어야 하는 상황(ex. hit) 외에 수정하면 안되는 값이라는걸 알 수 있을까요? 개방폐쇄의 원칙에 대해 한번 살펴보면 좋겠습니다. 동시성문제와는 다른 상황입니다."*
+
+학생 자가 결정:
+
+> *"제이든 감사합니다. 해당 부분에 대한 문제를 인지했어요. (...) 다시 돌아보니 블랙잭 미션에서 아쉬운 설계가 보이기 시작하는 것 같습니다. 말씀해주신 participantState를 아예 외부에서 참조 조차 못하게 수정해보려 했으나, 이미 시작에서부터 너무 많은 설계가 연쇄되어 있네요.. 대신 private set으로 외부에서는 설정하지 못하게는 불변으로 변경해보았는데, 이에 대해서는 어떻게 생각하시나요?? 또한 이번 오목 미션을 진행하면서는 state 프로퍼티를 외부에 노출시키지 않고 고차함수를 활용하는 연습을 더 진행해 볼 수 있었습니다!"*
+
+→ **5 가지 학습**:
+
+#### 2.1. *동시성 문제 vs 개방폐쇄 원칙 (OCP)*
+
+- *학생: 동시성 우려*.
+- *KwonDae: 개방폐쇄 원칙 (동료 개발자가 새 Player 추가 시 수정하면 안 되는 값 알기)*.
+- **MCP 룰 후보 `mutable-state-open-violation`** = *var open + 외부 변경 가능 = OCP 위반*.
+
+#### 2.2. *유지보수자 시점 (동료 개발자가 새 Player 추가)*
+
+PR #82·#107·#145·#46·#91 의 *유지보수자 시점* 결의 *KwonDae 어휘 강화*.
+
+#### 2.3. *학생 자가 *블랙잭 미션 설계 연쇄* 후회*
+
+*"이미 시작에서부터 너무 많은 설계가 연쇄되어 있네요.."* — **학생 자가 *코드 누적 부채* 자가 인정**. PR #145 (junseo511 *Manager 폭증*) / PR #76 (Yunseok-Nam *팩토리 메서드 그저 좋다*) 결.
+
+#### 2.4. *`private set` 자가 적용 (외부 read + 내부 write)*
+
+```kotlin
+open var participantState: ParticipantState
+    private set
+```
+
+— **Kotlin 어휘 자가 학습**.
+
+#### 2.5. *오목 미션 학습 자가 적용 명시*
+
+*"이번 오목 미션을 진행하면서는 state 프로퍼티를 외부에 노출시키지 않고 고차함수를 활용하는 연습을 더 진행해 볼 수 있었습니다!"* — **이전 미션 학습 자가 연결 + 다음 미션 학습 자가 적용**. PR #91·#95·#23·#46 결의 *학습 연쇄*.
+
+### 3. `Players → wallet 노출 X` — 디미터 법칙
+
+KwonDae: *"Wallet 클래스에서 드린 코멘트와 같이 배팅금액을 입력해서 wallet이라는 가변 프로퍼티를 사용해야만 처리가 가능했을까요? 또한, Players - player - wallet 구조에서 Players까지 노출되어야만 할까요?"* + KwonDae 별도: *"디미터의 법칙에 대해 찾아보시면 좋을 것 같습니다 🙂"*
+
+학생: *"감사합니다. Players - player - wallet 구조에서 Players까지 노출되어야 할 필요를 느끼지 못했습니다. 그리고 이를 개선하는 과정에서 Player의 Name과 Player의 Money를 먼저 받은 뒤에 Player 객체로 생성하는 과정을 진행하게끔 수정했습니다."*
+
+KwonDae 자가 메타: *"아시겠지만 프로그래밍에 정답은 없습니다 ㅎㅎ 단순 위 코멘트의 의도는 `Players에서 wallet 에 대해 알아야 하는가?` 였습니다. 이부분에 대해서는 디미터의 법칙에 대해 살펴보셔도 도움이 될 것 같습니다."*
+
+→ **디미터 법칙 (Law of Demeter) 강화**. PR #66 (vagabond95 *디미터 법칙*) / PR #72 (ghojeong) / PR #93·#133·#146·#137 결.
+
+### 4. `Participant 스스로 결과 판단`
+
+KwonDae: *"현재 Participant는 다른 참가자의 정보를 받아 스스로 승패 결정을 할 수 있습니다. 그렇다면 본인의 결과도 스스로 판단하여 외부에 결과만 알려줄 수 있지 않을까요?"*
+
+→ **참가자 vs 참가자 일반화 + 자기 판단**. PR #77·#46·#95·#23·#148·#151·#49·#132·#82·#86 결.
+
+### 5. `isYes` 변수명 모호
+
+KwonDae: *"isYes 라는 변수명만 보고도 어떤 역할을 하는 변수인지 알 수 있을까요? 🧐"*
+
+학생: *"불분명했던 것 같습니다. 해당 변수명은 grep.app 을 통해 continueToPlay로 수정했습니다. 감사합니다."*
+
+→ **부울 명명 = 의미 명시**. *`grep.app` 활용 자가 학습* — *외부 검색 + 명명 표준화*. PR #66·#107·#151·#98 결.
+
+### 6. `Players 일급컬렉션 활용 X`
+
+KwonDae: *"Players 라는 일급컬렉션을 생성했는데 현재 클래스에서 **일급컬렉션**을 활용하지 않고있습니다. Players에 대한 수정을 하려면 Game, Players 두군데 모두 비즈니스 로직을 다시 검토해봐야 할까요? 일급컬렉션을 사용해 Game에서 수행하는 로직들을 Players가 수행할 수 있는것들을 가져가볼까요?"*
+
+→ **일급 컬렉션 = 행동 응집**. PR #39 (rhthrhrl0 *first-class-collection-without-behavior*) / PR #145·#99·#74·#108·#133·#137·#46 결.
+
+### 7. `associate` Kotlin 어휘
+
+KwonDae: *"내부적으로 MutableMap 을 생성하지 않고도 [associate](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/associate.html) 를 활용해볼 수 있습니다. 또한 이 로직은 Game에서 수행되어야만 할까요?"*
+
+학생 자가 의문: *"associate 함수를 잊고 있었네요ㅜㅜ 정말 감사합니다! 마찬가지로 Game의 존재에 대해 스스로 고뇌하게 되네요. (...) 제이든이 말씀해주신 GameManager 느낌을 내볼까 했어요. 제가 잘못 바라보고 있는 방향이 무엇인지 알려주시면 감사드리겠습니다."*
+
+→ **Kotlin 어휘 + 1단계 GameManager 비유 연쇄**. PR #82 결.
+
+### 8. `GameTest` 위치 (Dealer 테스트)
+
+KwonDae: *"이 테스트는 딜러 테스트에 더 어울리지 않을까요?"*
+
+학생: *"딜러가 다수의 플레이어(Players) 들과 대결한 결과 (e.g A승 B무 C패) 를 리턴해야 해서, 게임을 진행하는 자인 Game에서 진행했는데 이 부분에 대해 어떻게 생각하시나요...!?? 딜러의 개인 대결은 judge 함수가 정의되어 있습니다."*
+
+→ **테스트 책임 = 도메인 객체와 일치 권유**. PR #46·#76·#9 결.
+
+### 9. `ktlint` 확인 (이미지 첨부)
+
+KwonDae: *"ktlint 확인해주세요 :)"* — 이미지.
+
+→ **컨벤션 자동화**. PR #77·#86·#9 결.
+
+### 10. `Game 도메인 vs Controller 통신 매개체` — 학생 자가 매우 긴 토론
+
+KwonDae: *"Game 이라는 클래스는 도메인 모델인가요? 어떤 배경에서 생성되었는지 궁금합니다. 제가 이해하기에는 Controller로 부터 명령을 받아 Player, Dealer 에 직접 접근하여 판단하는 로직들이 굉장히 많은데요.."* + 3 가지 초점:
+
+1. 일급컬렉션 활용
+2. Controller에 비슷한 성격을 띄는 Game에서 객체들에게 직접 접근하여 비즈니스 로직 수행하는 부분
+3. Participant(player, dealer) 스스로 수행할 수 있음에도 불구하고 자료에 직접 접근하여 연산 수행
+
+학생: *"Game 이라는 클래스를 도입한건 제 욕심이 과했나 싶네요. 컨트롤러에서 Players, Dealer 등의 다양한 인자를 사용해 함수들을 호출하는 대신에, 게임의 모든 참여자들을 한번에 담고 있고, 게임을 진행해주는 클래스가 있으면 좋곘다고 생각했습니다."*
+
+KwonDae: *"그렇다면 Game은 도메인이 아닌, Controller <-> 도메인 로직들(Player, Dealer, Deck...) 간 통신 매개체 역할이겠네요."*
+
+학생 자가 후회: *"지금 보니 잘못 얽히고 설킨 설계가 스스로도 많이 보이네요. 추상화를 제대로 활용하지 못했던 것 같습니다. 많이 되돌아보게 해 주셔서 감사합니다.."*
+
+→ **3 가지 학습**:
+
+#### 10.1. *Game 도메인 vs Controller 통신 매개체 분류*
+
+- *Game 이 도메인 = 자기 책임 + 일급 컬렉션 활용*.
+- *Game 이 통신 매개체 = Controller 와 도메인 사이 = 사실상 Controller 추가 계층*.
+
+**MCP 룰 후보 `pseudo-domain-controller-layer`** = *도메인 객체 명명 + 실제 Controller 책임 = 통신 매개체 = 추가 계층*.
+
+#### 10.2. *학생 자가 *욕심* 자가 인정*
+
+*"Game 이라는 클래스를 도입한건 제 욕심이 과했나 싶네요"* — **학생 자가 추상화 욕심 자가 인정**. PR #145·#76·#39·#31·#77 의 *pattern-applied-without-need* 결.
+
+#### 10.3. *PR #82 의 GameManager 비유 연쇄 + PR #100 의 자가 자기 의문*
+
+PR #82 의 *KwonDae GameManager 비유 (이해 돕기 위한 예시)* → 학생이 PR #100 에서 *Game 클래스 도입* → reviewer 가 *통신 매개체* 분류. **`비유 → 적용 → 재해석` 메타 학습 순환**.
+
+### 11. `Player.state` 직접 접근 X — 람다/interface 추상화
+
+KwonDae: *"Player의 state를 직접 접근하여 판단하기 보다 state의 context인 Player에서만 갖고 있도록해 객체가 스스로 상태에 따라 행동하게끔 해보면 어떨까요? 구조가 약간 복잡하여 한번에 모든것을 하기 보단, `각 객체의 자료들마다 이 데이터가 외부로 노출되어야만 하는가?` `내부에서 수행할 수 있지만, 외부에 의존하고 있지 않은가?` 충분한 고민을 해보셨으면 좋겠습니다."*
+
+학생 자가 의문: *"이 부분에 대해 더 좋은 방법이 있지 않을까 step1에서부터 고민했지만, 방법을 알 수 없었습니다 ㅜㅜ 'Playing 상태가 지속되는 동안에만 사용자로부터 입력을 받아야 한다'는 전제조건이 있으니, 결국 사용자의 상태를 체크해야만 하지 않을까 라고 밖에 생각이 들지 않습니다.. 혹시 이 부분에 대해 추상적으로나마 도움을 받을 수 있을까요..?"*
+
+KwonDae 코드 예시:
+
+```kotlin
+// in Participant.kt
+fun play(
+    playByDecision: () -> Boolean,
+    onDraw: () -> Card,
+    카드뽑은다음(): (Participant) -> Unit,
+)
+```
+
+KwonDae 메타: *"결국 책임을 분리하기 위해서는 추상화가 핵심입니다. 추상화에는 다양한 방법들이 있죠, interface, 람다 등등"*
+
+학생 자가 학습: *"Player는 자신의 상태를 알고 있기 때문에 Player 내부에서 스스로 판단하여 행동하게끔 위임할 수 있었습니다. 고차함수를 사용해놓고도 잘 이해하고 있지 못했던건지 생각해내지 못한게 아쉽습니다. 대신 이번 오목 미션을 진행하면서 고차함수를 너무 잘 활용하고 있는 느낌이 들어서 뿌듯합니다."*
+
+→ **3 가지 학습**:
+
+#### 11.1. *상태 직접 접근 → 람다/interface 추상화*
+
+- *외부에서 `if (player.state.isPlaying)` 분기* → *`player.play(playByDecision, onDraw, ...)` 메시지*.
+- *Player 가 자기 상태 판단 + 외부는 명령만*.
+
+#### 11.2. *책임 분리 = 추상화 (interface, 람다)*
+
+PR #82·#107·#77·#137 결.
+
+#### 11.3. *오목 미션 학습 자가 연결*
+
+*"이번 오목 미션을 진행하면서 고차함수를 너무 잘 활용하고 있는 느낌이 들어서 뿌듯합니다"* — **이전 미션 학습 자가 적용 + 자가 평가**. PR #91·#95·#23·#46·#100 (위 §2.5) 결.
+
+### 12. `getDealerResult` Players 일급컬렉션으로 가져올 수 있음
+
+KwonDae: *"이런 부분도 Players 일급컬렉션에서의 getPlayersResult()를 통해 getDealerResult() 라는 별도의 함수 없이도 가져올 수 있습니다. 플레이어의 '패'는 딜러의 '승' 이니까요 🙂 회고하시면서 도전해보시길 바랄게요 💪"*
+
+→ **양면 결과 = 반대 부호 변환**. PR #99 (s6m1n *calculateBetAmount 양측 계산*) / PR #95 (송핑크 *수익률 부호 반전*) 결.
+
+### 13. `private set` 자가 해결 후 확인
+
+KwonDae 마무리: *"현재 외부에서 직접 participantState를 참조하고 있기에 접근 제한자를 적용하기가 어려우셨을겁니다. 직접 참조하면 어떤 단점들이 있었는지를 기억하며 회고해보시고, 다음 미션에서도 이부분을 유의하여 진행하시면 도움이 될겁니다."*
+
+→ **다음 미션 회고 권유**. PR #95·#98·#99 결.
+
+### 14. `DeckExplicitGenerationStrategy` 가변 컬렉션 자가 실수
+
+KwonDae: *"DeckExplicitGenerationStrategy 의 프로퍼티는 `List<Card>`인데 가변컬렉션으로 바꿔주는 이유가 있을까요?"*
+
+학생: *"제가 실수했네요 ㅜㅜ 감사합니다"*
+
+→ **불변 컬렉션 + 의도 명시**. PR #74·#46·#23 결.
+
+### 15. `Game.kt:60` 객체가 할 일 — 칭찬
+
+KwonDae: *"좋습니다 👍 객체가 할 일이 생겼네요. 추후, 위 Players 또는 Player, Dealer를 통해 가져와 로직을 수행하는 부분도 각자의 객체에 맞게 위임해보는 작업도 도전해보세요!"*
+
+→ **점진적 책임 위임 도전 권유**.
+
+## 리뷰어 의견 요지 (KwonDae / 제이든)
+
+16 코멘트 특징 (PR #82 와 동일 reviewer):
+
+- **메타 질문 + 유지보수자 시점** — *"동료 개발자가 새로운 Player 타입을 만든다면 알 수 있을까요?"* — PR #82·#107·#145 결.
+- **외부 글 + 코드 예시 + 이미지** — *associate Kotlin 공식 문서* + *Participant.play 람다 예시* + *ktlint 이미지*.
+- **회고 권유** — *"회고하시면서 도전해보시길 바랄게요"*. PR #82·#95·#98·#99 결.
+- **다음 미션 학습 권유** — *"다음 미션에서도 이부분을 유의하여 진행하시면 도움이 될겁니다"*.
+- **친밀한 이모지** — *🧐, 🙂, ㅎㅎ, 💪* — PR #82 일관.
+
+## 대표 인용
+
+> *"제가 생각했을 때엔 지갑 안에 신분증 같은 것으로 생각했는데, 너무 제 기준에서만 생각한 것 같습니다."* — Hevton (현실 메타포 자가 검증 실패 인정)
+
+> *"이미 시작에서부터 너무 많은 설계가 연쇄되어 있네요.."* — Hevton (학생 자가 코드 누적 부채 자가 인정)
+
+> *"동료개발자가 Player, Dealer 외 새로운 Player 타입이 생겨 Participant를 상속하는 새로운 Player를 생성한다고 가정해볼게요. state가 바뀌어야 하는 상황(ex. hit) 외에 수정하면 안되는 값이라는걸 알 수 있을까요? 개방폐쇄의 원칙에 대해 한번 살펴보면 좋겠습니다. 동시성문제와는 다른 상황입니다."* — KwonDae (개방폐쇄 원칙 + 유지보수자 시점 메타)
+
+> *"Game 이라는 클래스를 도입한건 제 욕심이 과했나 싶네요."* — Hevton (학생 자가 추상화 욕심 자가 인정)
+
+> *"이번 오목 미션을 진행하면서는 state 프로퍼티를 외부에 노출시키지 않고 고차함수를 활용하는 연습을 더 진행해 볼 수 있었습니다!"* — Hevton (다음 미션 학습 자가 적용)
+
+> *"아시겠지만 프로그래밍에 정답은 없습니다 ㅎㅎ"* — KwonDae (개인 의견 메타 어휘)
+
+## 얻은 교훈
+
+1. **`현실 메타포 자가 검증 실패`** — *"지갑 안 신분증"* 같은 *개인 비유* = *공유 가능성 X*. **MCP 룰 후보 `personal-metaphor-without-shared-vocabulary`**. PR #74·#46 결.
+
+2. **`mutable-state-open-violation`** — *var open + 외부 변경 가능 = OCP 위반*. **유지보수자 시점 + 새 하위 클래스 추가 가능성**.
+
+3. **`pseudo-domain-controller-layer`** — *Game 같은 *도메인 명명 + Controller 책임* = 통신 매개체 = 추가 계층*. PR #145 (Manager 폭증) 결.
+
+4. **`코드 누적 부채 자가 인정`** — *"이미 시작에서부터 너무 많은 설계가 연쇄"* — **학생 자가 자가 인정 모범**. PR #145·#76·#39 결.
+
+5. **`다음 미션 학습 자가 적용`** — *오목 미션에서 고차함수 자가 활용 자가 평가*. PR #91·#95·#23·#46 결의 *KwonDae 어휘*.
+
+6. **`grep.app` 활용 변수명 탐색** — *외부 검색 + 명명 표준화*. **MCP 룰 후보 `external-naming-search-tool`**.
+
+7. **`Game 도메인 vs Controller 통신 매개체`** 분류 메타 — *도메인 객체 명명 + 실제 책임 = 통신 매개체*. **MCP 룰 후보 `pseudo-domain-controller-layer`**.
+
+8. **`상태 직접 접근 → 람다/interface 추상화`** — PR #82·#107·#77·#137 결.
+
+9. **`이전 미션 학습 연쇄 + 다음 미션 학습 자가 적용`** = *학습 = 시간 두고 반복* + *자가 평가*. PR #91·#95·#23·#46 결.
+
+10. **`개방폐쇄 원칙 (OCP)` + `유지보수자 시점`** = *동료 개발자가 새 하위 클래스 추가 시 *수정 X 값* 알기 어려움*. PR #16·#137 (조영호 원칙 어휘) 결.
+
+11. **`Participant 스스로 결과 판단`** — *디미터 법칙 + 참가자 vs 참가자 일반화*. PR #77·#46·#95 결.
+
+12. **`Wallet 부산물 객체 = 3 변수 제약 안티패턴 강화`** — PR #98·#133·#88·#132·#136·#93·#39 결.

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

@@ -0,0 +1,303 @@
+# PR #82 — [블랙잭 1단계] 팡태 미션
+
+- **Reviewee:** [@Hevton](https://github.com/Hevton)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/82
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 19 스레드 — *PR 본문 자가 의문 2개 + 의존성 그래프 첨부 + Answer 도메인 vs View 매우 긴 양방향 토론 + TestDeck 자가 정당화*
+- **신규 reviewee** (2024 코호트). PR #99·#67·#77·#91 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 2개 + 의존성 그래프 첨부**:
+  1. *"최대한 한 방향으로 도메인 간 관계를 작성해보고자 시도했습니다. 의존 관계를 이해하고 있는지, 의존성 그래프를 작성해 보았는데 잘못 이해하고 있는 점이 있는지 피드백을 받고 싶습니다."* + 의존성 그래프 이미지 첨부.
+  2. *"이전까지 미션을 진행하면서, 컨트롤러의 역할은 '응답 받고, 이를 처리해줄 도메인 함수 호출' 정도의 짧은 느낌으로만 작성했습니다. (...) 하지만 이번에는 컨트롤러의 역할을 조금 더 두었습니다. 결과적으로 '게임을 진행하는 자'가 현재 도메인이 아니라 컨트롤러가 되었습니다. 현재 구성에 대해, 더 세분화 되는게 좋을지, 구성에 대한 피드백을 솔직하게 받아보고 싶습니다."*
+  
+  **의존성 그래프 첨부 = 학습 가시화 모범**. PR #98·#99·#77·#107·#46 결의 *시각 자료 첨부* 진화.
+- **`abstract Human` 다형성 활용 칭찬** — KwonDae: *"추상클래스를 활용하여 딜러와 플레이어의 공통 로직을 한곳에 구현하고, 다형성을 구현하는 방향 좋습니다 👍"*. PR #74·#108·#133·#132·#136·#46·#77 결.
+- **`runCatching + getOrElse` Kotlin 어휘** — KwonDae: *"runCatching + getOrElse 활용 👍 👍"*. PR #93 (junjange *let-run-elvis-pitfall*) / PR #91 (murjune *Result*) 결.
+- **`flatMap` Kotlin 어휘 권유 + 학생 자가 의문 + reviewer 코드 예시** — 학생: *"MarkType과 ValueType의 모든 조합을 만들기 위해서 flatMap 활용을 기대할 수가 없지 않나요?"* + KwonDae 코드 예시:
+
+```kotlin
+private val cards: MutableList<Card> =
+    MarkType.entries.flatMap { mark ->
+        associateMark(mark)
+    }
+    .shuffled()
+    .toMutableList()
+
+private fun associateMark(markType: MarkType): List<Card> {
+    return ValueType.entries.map { amount -> 
+        Card.from(markType, amount) 
+    }
+}
+```
+
+**학생 자가 의문 → reviewer 코드 예시 모범**. PR #77·#91·#99·#46·#107 결.
+
+- **`TestDeck` 자가 정당화 + reviewer 인정** — KwonDae: *"테스트를 위해 Deck을 인터페이스화 하신걸까요? 로또 미션에서 테스트를 위해 어떤 과정들이 있었는지 생각해보면, 해당 모델 자체를 인터페이스로 만들지 않고, 랜덤요소가 들어간 대상을 내부적으로 책임을 갖지 않고 주입받도록 했던 방식도 있습니다."* + 학생: *"테스트 더블을 구현해보고자 전략 패턴 느낌을 활용했습니다. 프로덕션에서는 랜덤한 카드들을 pop 해주는 TrumpDeck, 테스트에서는 지정한 카드들을 순서대로 pop 해주는 TestDeck을 이용하게 했습니다."* + reviewer 메타 질문: *"지금은 Deck 자체를 인터페이스화 한 경우이고 전략패턴이라면, 카드덱을 생성하는 곳에서 전략패턴 사용하는게 자연스럽다는 생각을 했습니다. 1. interface Deck 2. deck.create() 중에서 어느 곳에 전략패턴을 적용하는게 좋을까요?"*. **학생 자가 전략 패턴 의도 + reviewer 적용 위치 메타 질문 모범**.
+
+## 못한 점 (설계 관점)
+
+### 1. `MarkType.mark` View 누수 — 메타 질문 + 학생 자가 학습
+
+KwonDae 1차: *"`val mark: String` 은 도메인 로직일까요? View에 표시되는 문구가 수정된다면 도메인에서 수정되어야 하는걸까요?"*
+
+학생: *"기본적으로 문구를 가지고 있어도 되겠지만, 이를 View에서 when 으로 지정해주는 방법도 있겠다고 생각이 드네요..! 후자의 경우가 제가 더 나아가고자 하는 방향과 일치하는 것이죠?"*
+
+KwonDae 메타 질문: *"기본적으로 문구를 가지고 있어도 되겠지만, UI에 표시되어야 하는 로직이 도메인에 있어도 괜찮다는 걸까요? 🧐 출력에 표시되는 문구를 수정해달라는 기획자의 요구사항이 왔을 때 동료개발자가 어디를 가장 먼저 살펴보게 될까요?"*
+
+학생: *"질문을 굉장히 잘해주시네요.. 단번에 이해되었습니다. 해당 부분 곧바로 수정했습니다. 감사합니다."*
+
+→ **3 가지 학습**:
+
+#### 1.1. *"기획자 요구사항 + 동료 개발자 위치"* — reviewer 메타 어휘
+
+**MCP `oh-my-oop` 의 *유지보수자 시점* 어휘 강화**. PR #107·#145 (lee-ji-hoon *유지보수 관점*) 결.
+
+#### 1.2. *enum 부가 속성 (`mark`) 도메인 X / View O*
+
+**MCP 기존 룰 `enum-with-ui-value`**. PR #137 (HamBeomJoon *Rank.label*) / PR #77 (murjune *Suit 스페이드*) / PR #28·#78·#112·#125·#147·#23·#26·#16·#9·#11·#13 결.
+
+#### 1.3. *학생 자가 *질문 잘해주셨다* 인정*
+
+*"질문을 굉장히 잘해주시네요.. 단번에 이해되었습니다."* — **메타 질문 효과 학생 자가 인정**.
+
+### 2. `TrumpDeck object 싱글톤` 동시 게임 어려움
+
+KwonDae: *"카드덱을 object 로 관리하는 이유가 궁금해요! 게임을 다수, 또는 동시에 여러 게임을 진행한다면 어떤 문제가 발생할 수 있을까요?"*
+
+학생: *"하나의 덱을 여러 Hand가 주입 받아 사용한다는 의미를 두고 싶었습니다. 실제로 게임을 할 때 하나의 덱에서 여러 사람이 카드를 소모하게 되는 것 처럼 구현하고자 했습니다. 하지만 이에 대해 동시 게임 진행이 어려운 문제가 존재할 수도 있겠네요.."*
+
+KwonDae: *"하나의 Deck 인스턴스를 여러 Hand가 주입 받아 사용하면 팡태의 구현하고자 하는 사항이 만족되겠네요 👍"*
+
+→ **싱글톤 (object) vs 단일 인스턴스 (class + DI)**:
+- *object* = *프로그램 전체 단일 + 동시 게임 X*.
+- *class + DI* = *게임마다 새 인스턴스 + 여러 Hand 공유*.
+
+PR #11 (ki960213 *Deck object 자가 인정*) / PR #46 (krrong *Calculator object*) / PR #16 (BeokBeok) 결.
+
+### 3. `Judge object 책임 vs Participant 자기 판단`
+
+KwonDae: *"Judge라는 승패 판단하는 object 역할에 대해 생각해보면 좋을 것 같아요. 사실 승패를 계산하는 로직은 딜러와 플레이어간 차이점이 있을까요? 팡태가 만들어놓은 `abstract class Human` 에서 아래와 같이 다른 사람과의 비교를 자체적으로 판단할 수 있도록 한다면 Judge object는 역할이 어떻게 될까요?"*
+
+```kotlin
+abstract class Human {
+   fun judge(otherHumane: Human): Result { ... }
+}
+```
+
+학생: *"'전체 결과' 에 대한 책임을 갖는 객체를 따로 두어서 역할을 주면, 책임 분리가 조금 더 직관적이지 않을까? 생각했습니다. 하지만 '전체 결과'로 꼭 생각하지 않더라도 승패 로직을 확실히 휴먼에서 다뤄주면 좋을 것 같다는 생각이 드네요.. 감사합니다"*
+
+→ **참가자 vs 참가자 일반화 + Judge object 책임**:
+
+- *Judge object 분리*: *책임 응집 직관* (학생 의도) vs *Participant 가 충분히 자기 판단 가능* (reviewer).
+- *Tell-Don't-Ask + 자기 판단* 정공.
+
+PR #77 (murjune *participant.judge*) / PR #46 (krrong *Dealer → Participant*) / PR #95·#23·#148·#151·#49·#132·#74·#98·#43 결의 *참가자 vs 참가자 일반화* 결.
+
+### 4. `Hand` 가 `TrumpDeck` 의존 — 의미 모호
+
+KwonDae 1차: *"Hand 클래스가 전체카드덱(TrumpDeck)을 프로퍼티로 갖고있어야 할까요?"*
+
+학생: *"생성자에서 의존성 주입하는 경우에 대해서만 너무 익숙하게 생각했던 것 같습니다. 설계할 땐 이게 가장 의존성 주입 관점에서 의미있지 않을까 싶었는데, 생각해보니 draw 시에 주입해줘도 되겠다는 생각이 듭니다."*
+
+KwonDae 2차: *"제가 이해한 Hand는 현재 사용자가 들고있는 카드 정보라고 이해했었는데, 프로퍼티 타입은 Deck 이어서 `List<Card>`가 더 어울리지 않을까한 코멘트였습니다 🙂"*
+
+학생: *"제가 동료 개발자가 봤을 때 충분히 헷갈릴만한 코드를 작성하였네요. 이에 대해 코드를 개선해보겠습니다."*
+
+→ **`Hand` 의미 = 현재 손에 든 카드** vs *전체 덱 X*. **MCP 룰 후보 `hand-deck-conflation`** = *Hand 가 Deck 보유 = 의미 혼동*. PR #77 (murjune *Hand 책임*) / PR #99·#46·#43 결.
+
+### 5. `TrumpDeck` 내부 랜덤 = 테스트 불가
+
+KwonDae 1차: *"카드덱 생성시 내부적으로 랜덤요소를 반영하여 카드덱을 생성하고 있습니다. 만약 특정 카드덱을 셋팅해두어 pop() 하는 로직을 테스트 해야 한다면 어떻게 수정해야 할까요? 🧐"*
+
+학생: *"그것을 위한 목적으로 TestDeck을 만들어보게 되었습니다"*
+
+→ *TestDeck 자가 정당화* (위 §잘한점). 다만 *전략 패턴 적용 위치* 가 학생 자가 검토할 만한 영역. PR #74·#23·#95·#99·#26·#39·#46·#77 결.
+
+### 6. `Deck` 카드 부족 시 예외 처리
+
+KwonDae: *"만약 덱에 더이상 카드가 없다면 어떤 일이 발생할까요? 지난 미션에서 논리 오류가 아니라면 어떻게 했었는지 생각해볼 수 있겠네요!"*
+
+학생: *"감사합니다. 해당 예외에 대해서는 고려하지 못했네요..!"*
+
+KwonDae 별도 (이후): *"사실 현실세계에서는 참가인원이 2~8명으로 제한되어 있습니다 ㅎㅎ 그렇기에 덱이 모두 소진되는 일 & 중복되는 카드는 발생할 수 없죠. 다만, 프로그래밍 관점에서 removeAt() 이라는 함수가 exception..."*
+
+→ **이전 미션 학습 자가 연결**. PR #91 (murjune *논리 오류*) / PR #46·#26·#74·#108·#133·#136·#41·#107 결.
+
+### 7. `ValueType.rank` View vs 도메인
+
+KwonDae: *"rank는 도메인 로직일까요~? UI 로직이 수정된다면 여기서 수정이 일어나야 됩니다 🧐 amount를 활용할 수 있겠네요!"*
+
+학생: *"감사합니다. amount와 달리 rank는 도메인 로직이 아니겠네요..!"*
+
+→ **enum 부가 속성 도메인 vs View**. PR #137·#77·#23·#26·#16·#9 결.
+
+### 8. `Card` 상수 (INVALID_RANGE, MAX_NUMBER, DIVIDER) 의미 모호
+
+KwonDae: *"처음에 INVALID_RANGE, MAX_NUMBER, DIVIDER 가 무얼 의미하는지 이해하기 힘들었네요 🥲 만약 숫자 혹은 모양이 추가된다면 다시 계산하여 상수를 바꿔주어야 할까요?"*
+
+학생: *"이 부분이 저도 설계에 어려움을 느꼈습니다 ㅜ..ㅜ 처음에는 '문양' x '숫자' 를 조합하여 카드를 생성하는 과정을 넣으려고 했으나, 그렇게 되면 과제 요구사항에 적혀진 'depth 2 미만' 에 위배되기 때문에 해당 방법을 생각하게 되었습니다.. 이 부분은 더 고민해보겠습니다."*
+
+→ **`depth 2 미만` 요구사항 vs 자연스러운 모델링**:
+- *요구사항 (인덴트 depth ≤ 2)* + *문양 × 숫자 조합 (2 중 for 또는 flatMap)* 충돌.
+- *MarkType.flatMap { ValueType.map }* — `flatMap` 이 depth 회피 (위 §잘한점).
+
+**MCP 룰 후보 `requirement-vs-natural-modeling-conflict`** = *요구사항 강제 = 부자연스러운 모델링 시그널*. PR #98 (chaehyuns *3 변수 제약*) / PR #146 (yrsel *YAGNI*) 결.
+
+### 9. `Hand vs Cards` 명명 혼동 (위 §4 와 같음)
+
+### 10. `Answer 도메인 vs View` 매우 긴 양방향 토론
+
+KwonDae: *"이 로직들은 도메인 로직과 UI 로직 중 어디에 더 어울릴까요? 🧐"*
+
+학생: *"Answer의 역할로 묶으면 테스트가 용이하지 않을까 싶었습니다..!! '사용자의 응답'에 대해 '정해진 응답의 객체'로 변환해야 하는 과정에서 UI에서도 일부 로직을 갖고, 도메인에서도 일부 로직을 가져서 분리되어있는 방법 대신에 도메인에서 이 로직을 한번에 담당해주면 조금 더 유지보수가 간편하지 않을까 싶었는데, 이에 대해 어떻게 생각하시는지 궁금합니다..!"*
+
+KwonDae 메타 질문 + 유지보수자 시점:
+
+> *"UI에서 도메인에 따라 출력 양식을 결정하는 로직을 갖는게 어울리지 않는다는 걸까요?*
+>
+> *'정해진 응답의 객체'로 변환 — View에서 하는 역할이 이런 역할이지 않을까요?*
+>
+> *예를 들어, 출력 양식이 또는 입력 조건이 수정되었을 때 동료 개발자가 어디를 가장 먼저 찾아볼까요?*
+>
+> *1. Answer 도메인 로직이 어떻게 구현되어 있는지 들어온다.*
+> *2. OutputView /InputView 와 Controller 호출부를 찾아본다"*
+
+학생: *"질문을 정말 잘해주시네요.. 되돌아보게 되었습니다. 해당 부분 적용해보겠습니다."*
+
+학생 자가 후속 의문: *"Answer 로직은 도메인이 아닌 View로 빼면서 테스트가 불가능해졌는데, 이러한 것의 이점이 어떤 것이 있을까요??"*
+
+KwonDae: *"이번 수정에서 Answer 모델이 삭제되었네요? 오히려 Answer 로직에서 View에 의존하는 로직이 있었다면 단위테스트가 불가했을텐데 이부분에 대해서는 부연설명을 부탁드려도 될까요?"*
+
+학생: *"Answer 객체는 fromInput(input: String) 이라는 팩토리 메서드로 생성되게 구현하여, View에서의 입력값으로 받을 String의 값에 따른 단위테스트를 진행할 수 있었습니다! 즉 사용자의 모든 입력에 따른 단위테스트가 도메인 로직에서 가능했던 느낌입니다. 제 생각에는 사용자의 응답이 YES 또는 NO 또는 기타 입력으로 왔을 때의 단위테스트를 진행해야 한다고 생각했는데, 지금처럼 InputView에서 진행하는 부분이 있다면 사용자 입력에 대한 단위테스트가 어렵다고 생각했는데, 잘못 이해하고 사용한 부분이 있을까요??"*
+
+KwonDae 마무리: *"이 테스트는 도메인 테스트일까요 View 테스트에 해당할까요? 입력에 따른 단위테스트라면 도메인 로직이 사용자의 입력에 의존하고 있었다는 이야기가 되겠네요..! 그럼 사용자 입력을 Answer 도메인으로 부터 분리하고 Answer 객체가 다른 역할이 없다면 해당 객체의 존재 가치에 대해서 생각해볼 필요가 있을 것 같습니다."*
+
+→ **5 가지 학습**:
+
+#### 10.1. *사용자 입력 의존 = 도메인 객체 X*
+
+- *Answer.fromInput(String)* = *사용자 입력 의존* = *도메인 의도 아닌 View 변환 책임*.
+- *Answer 가 다른 역할 없음* = *존재 가치 의문*.
+
+#### 10.2. *테스트 도메인 vs View*
+
+학생이 *Answer 도메인 테스트* 라고 생각한 것이 *실은 View 입력 테스트*. **MCP 룰 후보 `test-classification-domain-vs-view`**.
+
+#### 10.3. *동료 개발자 찾아보는 위치 = 유지보수자 시점*
+
+KwonDae 어휘. PR #107·#145 (lee-ji-hoon) / PR #46·#91 결.
+
+#### 10.4. *학생 자가 *"잘못 이해하고 사용한 부분이 있을까요?"* 자가 의문*
+
+PR #91·#46·#107·#43 결.
+
+#### 10.5. *Answer 객체 자가 삭제 결정*
+
+학생 자가 *불필요 객체 자가 결정 + 삭제*. PR #145·#13·#146·#31 결.
+
+### 11. `GameManager` vs `Controller` 게임 진행자
+
+KwonDae: *"팡태가 말씀하신 것 처럼 `결과적으로 '게임을 진행하는 자'게 현재 도메인이 아니라 컨트롤러` 가 되었는데, 그렇다면 컨트롤러 내에서 BlackJackGame..."*
+
+학생 자가 의문: *"말씀하신 GameManager는 View와 상호간 값, 명령을 진행한다면 MVC에서 도메인의 역할은 아닌 것인가요?? 도메인에서는 뷰를 참조하지 않는다고 생각하고 있기에 제가 KwonDae의 말씀을 잘못 이해한 것 같아서 질문드립니다!"*
+
+KwonDae: *"제가 말씀드리는 GameManager는 도메인 역할이 아닌, Controller - 블랙잭 게임장 / GameManager - 매 게임을 관리감독 하는 관리자 (매 게임이 끝나면 초기화(새로운 인스턴스)가 된다) 에 비유할 수 있겠네요. GameManager가 있어야 한다가 아닙니다. 단순 이해를 돕기위해 예시를 들고와봤습니다. MVC에서 Controller는 현재 블랙잭에서 게임관리자가 맞습니다. 도메인은 해당 '게임에 참여하는 자'가 되겠네요"*
+
+→ **MVC Controller = 게임 관리자 + 도메인 = 게임 참가자**. *학생 자가 *MVC 정의 의문* + reviewer 명확화*. PR #145·#107·#46·#91 결.
+
+### 12. `사용자 응답 모든 입력` Player 비유
+
+KwonDae 별도 *"사용자의 응답이 YES 또는 NO 또는 기타 입력 단위테스트"* 의 마무리: *(jumbled 코드)*. PR #91·#107·#46 결.
+
+### 13. `participant.initGame(cardDeck)` 메시지 던지기
+
+KwonDae: *"딜러와 플레이어를 게임 시작 셋팅을 해주는 부분이군요..! `게임 시작 시 참가자들은 두장의 카드를 갖게된다.` 이부분은 비즈니스 로직에 해당할까요? `participant.initGame(cardDeck)` 식으로 객체가 알아서 하게끔 메세지를 던져보는건 어떨까요?"*
+
+→ **Tell-Don't-Ask + initGame 메시지**. PR #99·#107·#43·#46·#77·#9·#76 결.
+
+### 14. `Test Fixture` 외부 글 추천
+
+KwonDae: *"참고로 테스트에 Test Fixture 라는 개념이 있습니다. 이는 여러 테스트에서 같은 Data를 사용할 때, 코드 중복을 피하면서 가독성을 높이는 방법인데요"* + [tjdtls690 Test Fixture 글](https://tjdtls690.github.io/studycontents/java/2022-10-10-test_fixture/) 추천.
+
+→ **외부 자료 첨부**. PR #91 (KwonDae *팩토리 메서드 글*) / PR #95·#67·#23·#26·#16·#46·#77·#107 결.
+
+### 15. `Player.judge` Dealer 의 코드 vs Player 의 코드 (suggestion)
+
+KwonDae suggestion (코드만 첨부, 본문 잘림):
+
+```kotlin
+// in Dealer.kt
+override fun judge(other: Participant): ResultType {
+    return when {
+        other.participantState is ParticipantState.Bust -> ResultType.WIN
+        participantState is ParticipantState.Bust -> ResultType.LOSE
+        this.getPointWithAce() > other.getPointWithAce() -> ResultType.WIN
+        this.getPointWithAce() == other.getPointWithAce() -> ResultType.DRAW
+        ...
+```
+
+→ **참가자 vs 참가자 일반화 + 자기 Bust 우선**. PR #77 (murjune *블랙잭 룰 비대칭*) / PR #95·#23·#148·#151 결.
+
+### 16. `의존성 그래프` 자가 검토 (위 PR 본문 §1)
+
+KwonDae: *"의존성 그래프를 잘 작성해주셔서 덕분에 프로젝트 이해하는데 아주 큰 도움이 되었습니다 👍 💯 지금 human 이라는 추상클래스를 활용하여 플레이어, 딜러간 공통 로직을 잘 설계해주셨는데요, 조금 더 나아가서 어떤 부분이 공통 로직이 될 수 있고, 어떤 부분이 다른 구현을 가질 수 있어 다형성을 고려할 (수 있는지 ...)"* + 학생 자가 의문: *"의존성 그래프를 그린 뒤에, 의존성이 가장 적은 것부터 구현하는 방향이 구현이 쉽지 않나요??!"* + reviewer 자가 명확화: *"맞습니다. 그래서 의존성 그래프를 그려 구조를 파악하기 쉽게 만들도록 하는 역할과 함께 가장 의존성이 적은 것 부터 구현하는게 맞습니다. 제가 헷갈리게 말씀드린거 같네요 🥲 하고싶었던 의미는 '객체 스스로가 할 수 있는 기능임에도 불구하고 다른 객체에 의존하는 상황에 대해 생각해보자' 였습니다!"*
+
+→ **의존성 그래프 자가 작성 + reviewer 자가 사과 + 의도 명확화**. PR #91·#77·#46·#16·#95·#137·#107 결.
+
+## 리뷰어 의견 요지 (KwonDae / 제이든)
+
+19 코멘트 특징 (PR #99·#67·#77·#91 와 동일 reviewer):
+
+- **메타 질문 + 유지보수자 시점** — *"기획자 요구사항이 왔을 때 동료 개발자가 어디를 가장 먼저 살펴보게 될까요?"* — **유지보수자 시점 강화**. PR #107·#145 결.
+- **외부 글 + 코드 예시 첨부** — *Test Fixture 외부 글* + *flatMap 코드 예시*. PR #91·#77·#46 결.
+- **`?_?`, `🧐`, `🥲` 친밀한 이모지** — PR #99·#77·#91 일관.
+- **reviewer 자가 사과 + 의도 명확화** — *"헷갈리게 말씀드린거 같네요 🥲"* / *"단순 이해를 돕기위해 예시를 들고와봤습니다"*. PR #91·#77·#46·#16·#95·#137·#107 결.
+- **이전 미션 학습 자가 연결** — *"지난 미션에서 논리 오류가 아니라면 어떻게 했었는지"* — PR #91 결.
+- **칭찬 분포** — *추상클래스 다형성, runCatching, flatMap 권유, 의존성 그래프* 등 칭찬.
+
+## 대표 인용
+
+> *"질문을 굉장히 잘해주시네요.. 단번에 이해되었습니다. 해당 부분 곧바로 수정했습니다."* — Hevton (메타 질문 효과 학생 자가 인정)
+
+> *"기획자의 요구사항이 왔을 때 동료개발자가 어디를 가장 먼저 살펴보게 될까요?"* — KwonDae (유지보수자 시점 메타 질문)
+
+> *"출력 양식이 또는 입력 조건이 수정되었을 때 동료 개발자가 어디를 가장 먼저 찾아볼까요? 1. Answer 도메인 로직이 어떻게 구현되어 있는지 들어온다. 2. OutputView /InputView 와 Controller 호출부를 찾아본다"* — KwonDae (유지보수자 위치 시뮬레이션)
+
+> *"Answer 객체가 다른 역할이 없다면 해당 객체의 존재 가치에 대해서 생각해볼 필요가 있을 것 같습니다."* — KwonDae (불필요 객체 시그널)
+
+> *"제 생각에는 사용자의 응답이 YES 또는 NO 또는 기타 입력으로 왔을 때의 단위테스트를 진행해야 한다고 생각했는데, 지금처럼 InputView에서 진행하는 부분이 있다면 사용자 입력에 대한 단위테스트가 어렵다고 생각했는데, 잘못 이해하고 사용한 부분이 있을까요??"* — Hevton (학생 자가 *잘못 이해* 자가 의문)
+
+> *"제가 헷갈리게 말씀드린거 같네요 🥲 하고싶었던 의미는 '객체 스스로가 할 수 있는 기능임에도 불구하고 다른 객체에 의존하는 상황에 대해 생각해보자' 였습니다!"* — KwonDae (reviewer 자가 사과 + 의도 명확화)
+
+## 얻은 교훈
+
+1. **`유지보수자 시점 (기획자 요구사항 + 동료 개발자 위치)` 메타 어휘** — *"기획자 요구사항이 왔을 때 동료 개발자가 어디를 가장 먼저 살펴보게 될까요?"*. **MCP 룰 후보 `maintainer-perspective-locator`**. PR #107·#145·#46·#91 결.
+
+2. **`Answer 도메인 vs View` 양가성** — *학생이 *Answer 객체* 로 *사용자 입력 변환* 응집 시도* + *reviewer 가 *Answer 가 다른 역할 없음 = 존재 가치 의문* 메타 + 학생 자가 삭제*. **MCP 룰 후보 `intermediate-object-without-role`** = *단순 변환만 담당하는 객체 = 존재 가치 의문*.
+
+3. **`테스트 분류 (도메인 vs View)`** — *입력 변환 테스트 = View 테스트 / 비즈니스 로직 = 도메인 테스트*. **MCP 룰 후보 `test-classification-domain-vs-view`**.
+
+4. **`Hand 가 Deck 보유 = 의미 혼동`** — *Hand = 현재 손에 든 카드 / Deck = 전체 카드*. **MCP 룰 후보 `hand-deck-conflation`**.
+
+5. **`참가자 vs 참가자 일반화 + Judge object 책임`** — *Judge 분리 vs Participant 자기 판단*. PR #77·#46·#95·#23·#148·#151·#49·#132·#74·#98·#43 결.
+
+6. **`요구사항 (인덴트 depth ≤ 2) vs 자연스러운 모델링 충돌`** — *학생 자가 *요구사항 강제 = 부자연스러운 상수 도입* 자가 인정*. **MCP 룰 후보 `requirement-vs-natural-modeling-conflict`**. PR #98 (chaehyuns *3 변수 제약*) / PR #146 (yrsel *YAGNI*) 결.
+
+7. **`의존성 그래프 PR 본문 첨부`** — *학습 가시화 + 의존성 자가 검토*. **MCP 룰 후보 `dependency-graph-self-review`**. PR #98·#99·#77·#107·#46 결의 *시각 자료 강화*.
+
+8. **`flatMap` Kotlin 어휘 = depth 회피 + 자연스러운 모델링** — *2 중 for / nested map → flatMap*. **MCP 룰 후보 `nested-loop-to-flatmap`**.
+
+9. **`reviewer 자가 사과 + 의도 명확화`** — 다수. PR #91·#77·#46·#16·#95·#137·#107·#145 결.
+
+10. **`TestDeck = 전략 패턴 적용 위치` 학생 자가 의문** — *Deck 자체 interface (학생) vs Deck.create() 위치 (reviewer)*. PR #74·#77·#23 결.
+
+11. **`이전 미션 학습 자가 연결`** — *"지난 미션에서 논리 오류가 아니라면"* — PR #91·#95·#23·#46 결의 *KwonDae 어휘*.
+
+12. **`MVC Controller vs GameManager` 비유** — *Controller = 게임장 / GameManager = 매 게임 관리자 (인스턴스화)*. **MCP 룰 후보 `controller-vs-game-manager-distinction`**.
+
+13. **`object 싱글톤 vs class + DI` 동시 게임 시나리오** — PR #11·#46·#16 결.
+
+14. **`PR 본문 자가 의문 2개 + 의존성 그래프 + 시각 자료` = 학습 가시화 풍부** — PR #98·#99·#77·#107·#46·#91 결.