oh-my-oop 0.2.0

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

@@ -0,0 +1,287 @@
+# PR #77 — [블랙잭 1단계] 오둥이 미션
+
+- **Reviewee:** [@murjune](https://github.com/murjune)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/77
+- **단계:** 1단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 24 스레드 — *학생 자가 PR 본문 의문 + 외부 블로그 인용 + Higher Order Function 자가 학습 + 일급컬렉션 정의 자가 주장*
+- **신규 reviewee** (2024년 코호트). PR #99·#67 (KwonDae) 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 + 이미지 첨부** — *"Card 들의 합을 계산하는 방식을 동적으로 바꾸고 싶어 위와 같이 생성자에 calculator 객체를 만들었습니다. 그러나, calculator를 domain model(일급 컬렉션)에 넣는 것이 맞는것일까.. 라는 고민을 하고 있습니다. 이에 대해 제이든의 피드백을 받고 싶습니다🙋‍♂️"* + 코드 이미지 첨부. **학생 자가 학습 모범 + 시각 자료**. PR #128·#135·#108·#133·#136·#137·#148·#151·#98·#95·#99 결.
+- **`value class` Kotlin 어휘 자가 활용** — KwonDae 칭찬: *"value class 활용 👍"*. **Kotlin 1.5+ value class = inline 성능 + 타입 안전성** — PR #137·#148·#90·#146 의 *Kotlin 어휘 학습* 결.
+- **`Read-Only 컬렉션 + plus operator` 자가 활용** — KwonDae 칭찬: *"Read-Only 컬렉션을 사용하기 때문에 plus 연산자로 처리해주는 부분 인상깊었네요 👍"*. **불변 객체 + 새 컬렉션 반환** — PR #46 (krrong *operator times*) / PR #39 (rhthrhrl0 *컬렉션 + operator*) 결.
+- **`TestFixture` 활용 풍부** — KwonDae 칭찬 2회 (`CardFixtures.kt`, `DeckFixtures.kt`): *"TestFixture를 잘 활용해주셨네요 💯"* / *"TestFixture 사용으로 가독성이 좋아졌네요 👍"*. **PR #99 (s6m1n *Test Fixture 품질*) 권고 자가 적용 모범** — *KwonDae 가 양 PR 모두 리뷰* 했기에 *PR #99 학생 자가 학습이 PR #77 학생에게 권고로 이어진 패턴* 가능성.
+- **`Deck.removeLast()` 빈 컬렉션 사전 방어** — KwonDae 칭찬: *"룰 마다 다르겠지만? cards가 비어있을 때 removeLast()가 예외가 발생할 수 있는데 사전에 막아주는 코드 좋습니다 👍"*. **방어 코드 + Kotlin 어휘**.
+- **`UiModel` View 캡슐화 자가 학습** — KwonDae 칭찬: *"UiModel로 View에서 나타낼 데이터들을 캡슐화 해주셨군요..! 👍"*. **MVVM / Presentation Model 어휘** — PR #88·#131 의 *view-by-stage-split* 결의 진화.
+- **추상화 활용** — KwonDae 칭찬: *"추상화를 잘 이용해주셨네요 👍 공통 로직을 중복으로 구현하기 보다 super 키워드를 활용해 한곳에서 관리할 수 있도록 개선해볼 수 있겠네요!"* + 외부 글 ([Kotlin 공식 문서 - inheritance](https://kotlinlang.org/docs/inheritance.html#calling-the-superclass-implementation)). **외부 자료 첨부**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Hand 책임 위치` — 학생 자가 깊은 토론 (Hand vs Participant)
+
+KwonDae 1차: *"현재 참가자(플레이어, 딜러)의 상태(들고있는 카드 정보, bust 여부 등)을 알고있다면 계산이 간소화 될거라 생각합니다. 참가자가 Hit를 수행할 때 마다 현재 Ace를 들고있다면 현재 스코어에 따라 1과 11중 어떤 값을 취해야 할 지 판단할 수 있기 때문에 참가자(Participant)가 스스로 판단하여 점수를 계산하게끔 할 수 있을거에요"*
+
+학생 자가 반박: *"나의 상태(score) 도 결국 Hand의 상태(cards)를 가져와 계산하는 것이라 생각합니다. Hand 가 스스로 점수가 몇 점인지, 버스트인지, 블랙잭인지 판단하는 것이 좋다고 생각합니다!"*
+
+KwonDae 2차: *"카드를 가져오거나 내 상태에 대한 판단은 Hand가 하는걸까요? 이러한 현재 내 카드에 대한 판단은 참가자가 할 수 있을겁니다. 또한, 이 로직은 딜러와 플레이어의 공통 로직이 되겠네요!"*
+
+학생 후속: *"참여자(Participant)가 Hand 의 상태를 가져와 판단하기 보다는 Hand 가 자신의 상태(cards)를 기반으로 스스로 점수가 몇 점인지, 버스트인지, 블랙잭인지 판단하는 것이 좋다고 생각합니다!"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *책임 위치 = Hand vs Participant (양방향 토론)*
+
+- **Hand 책임** (학생 주장):
+  - *카드 모음의 상태 (점수, Bust, BlackJack) 는 *카드 모음 자체* 가 알 수 있음*.
+  - *Participant 가 Hand 위임 = 응집*.
+- **Participant 책임** (KwonDae 주장):
+  - *Ace 1↔11 결정은 *현재 스코어* 에 따라 변동 → 참가자 상태와 결합*.
+  - *Hit 명령 → Participant 가 자기 상태 판단 + Hand 업데이트*.
+
+**둘 다 유효 + 다른 트레이드오프** — *Hand = 데이터 응집 / Participant = 상태 변경 응집*. PR #99 (s6m1n *Hand 클래스 도입*) / PR #98 (chaehyuns *State + HandCards*) / PR #46 (krrong *CardBunch*) 결.
+
+#### 1.2. *학생 자가 주장 유지 + reviewer 인정*
+
+학생이 *자가 주장 유지* + *KwonDae 가 *학생 주장 수용* (`이 로직은 딜러와 플레이어의 공통 로직` 권고 후 그 이상 밀지 않음)*. **학생/reviewer 양방향 토론 + 학생 결정 존중**. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) / PR #46 (말리빈 *Dealer→Player vs Participant 토론*) 결.
+
+#### 1.3. *학생 의문에 대한 reviewer 자가 부연 + 사과*
+
+KwonDae: *"앗, 제가 오히려 헷갈리게 질문을 드린거 같아 죄송하네요 🥲 정리하면, 처음에 일급 컬렉션이라고 생각하지 못하고 캡슐화한 클래스라고 생각했었습니다."* — **reviewer 자가 사과 + 자가 부연**. PR #95·#137·#147·#151 의 *reviewer 자가 한계 인정* 결.
+
+### 2. `Hand 일급 컬렉션 정의` — 학생 자가 매우 긴 외부 글 인용 답변
+
+KwonDae 의문: *"이 경우에 Hand는 일급컬렉션 일까요?"*
+
+학생 자가 매우 긴 답변:
+
+```kotlin
+class Hand(
+    val cards: List<Card>,
+    private val pointCalculator: PointCalculator = DefaultPointCalculator(BLACKJACK_NUMBER),
+) : List<Card> by cards {
+```
+
+> *"저는 일급컬렉션이라고 생각합니다. 이유: 저는 일급컬렉션이 기본 collection 에 `비지니스 로직을 입힌 domain model` 이라고 스스로 정의했습니다. 해당 `Hand` 는 `List<Card> + 비지니스 로직` 형태 입니다. 저는 일급컬렉션이 기본 collection 에 `비지니스 로직을 입힌 domain model`라고 생각하기 때문에 by 키워드를 써도 일급컬렉션이라 생각합니다."*
+
+> *(이후 학생의 외부 블로그 인용)* *"일급컬렉션의 규칙 중 하나는 [컬렉션을 제외한 다른 멤버변수는 존재하지 않아야](https://developerfarm.wordpress.com/2012/02/01/object) ..."*
+
+→ **3 가지 메타 학습**:
+
+#### 2.1. *학생 자가 일급 컬렉션 정의 명시*
+
+학생의 *"스스로 정의했습니다"* — **자가 학습 + 자가 정의** 모범. PR #74·#108·#133·#99·#46 의 *일급 컬렉션 자가 학습* 결.
+
+#### 2.2. *외부 블로그 인용 + 정의 검증*
+
+학생이 *외부 블로그의 일급 컬렉션 규칙 (1 변수만) 인용* + *자가 코드가 규칙 위반인지 자가 검증*. **외부 자료 + 자가 검증 모범** — PR #95·#67·#23·#26·#16·#46 의 *외부 자료 첨부* 결의 *학생측 외부 자료 인용*.
+
+#### 2.3. *`by` 키워드 (Kotlin 위임)*
+
+- *`class Hand(val cards: List<Card>) : List<Card> by cards`* = *Hand 가 `List<Card>` 인터페이스를 *cards 에 위임*.
+- **Kotlin Delegation 어휘** — *상속 X + 인터페이스 위임*. PR #74 (송핑크 *Delegate vs 일급 컬렉션 자가 학습 + 트레이드오프*) 결의 *Hand 적용*.
+
+**MCP 룰 후보 — `delegate-vs-firstclass-collection`** = *PR #74 (말리빈 *Delegate 활용 일급 컬렉션 권고 X*) 와 본 PR (학생 *Delegate 사용*) 의 *동일 토론 패턴*. 양가성 인정*.
+
+### 3. `Participant 추상화 + judge` — 참가자 vs 참가자 일반화
+
+KwonDae: *"승부를 판단하는 로직을 참가자 객체가 스스로하게끔 할 수 있을까요? 즉, 플레이어와 딜러 구분 없이 Participant 자체가 다른 Participant와 비교하여 판단할 수 있지 않을까요?"*
+
+```kotlin
+abstract class Participant {
+   fun judge(otherParticipant: Participant): Result { ... }
+}
+```
+
+학생 자가 답변 + 코드 + 도메인 룰:
+
+> *"실제 블랙잭 게임에서 딜러와 플레이어가 둘다 Bust 상태 일 때, 플레이어가 지는 것으로 알고 있습니다! 따라서, 딜러와 플레이어의 계산 방식이 약간 다릅니다!! 사실 이 부분이 마음에 들지 않아 개선하기 위해 머리를 싸매고 있네요..😅"*
+
+```kotlin
+// Dealer
+override fun judge(other: Participant): GameResult =
+    when {
+        other.isBust() -> GameResult.WIN
+        isBust() -> GameResult.LOSE
+        ... 나머지는 동일
+
+// Player
+override fun judge(other: Participant): GameResult =
+    when {
+        isBust() -> GameResult.LOSE  // 자기 Bust 우선 (둘 다 Bust 시 플레이어 패배)
+        ...
+```
+
+KwonDae 후속: *"오둥이의 블랙잭 게임장은 둘 다 bust 일 때 플레이어가 패배하는 룰을 적용하고 있었군요..! 오둥이도 이부분이 마음에 들지 않는다면 같이 고민해봐도 좋을 것 같습니다 :)"*
+
+→ **5 가지 학습**:
+
+#### 3.1. *참가자 vs 참가자 일반화 (`judge(other: Participant)`) 시도*
+
+- *`Dealer.compareResult(player)`* (한 방향) < *`Participant.judge(other)`* (양방향 일반화).
+- *형제 구현체 간 강한 의존 차단 + DIP 적용*.
+
+PR #46 (krrong 2단계 *Dealer → Participant 양방향 토론*) / PR #95·#23·#148·#151·#49·#132 결.
+
+#### 3.2. *블랙잭 룰 정확성 (둘 다 Bust 시 플레이어 패배)*
+
+학생 자가 도메인 룰 인용 — *"실제 블랙잭 게임에서 딜러와 플레이어가 둘다 Bust 상태 일 때, 플레이어가 지는 것으로 알고 있습니다!"*. **MCP 룰 후보 `blackjack-rule-fidelity`** + PR #26 (잭슨 *Bust 양측 명시*) / PR #46 (말리빈 *BlackJack ≠ 21*) 결.
+
+#### 3.3. *judge 다형성 vs 비대칭 도메인 룰*
+
+- *판정 룰이 *대칭* (점수 비교) 인 경우 = `Participant.judge` 일반화 정공.
+- *판정 룰이 *비대칭* (Player Bust 우선) 인 경우 = *각자 다른 judge 구현* 필요 → *Participant 일반화의 한계*.
+
+#### 3.4. *학생 자가 *마음에 들지 않음* 자가 명시*
+
+*"사실 이 부분이 마음에 들지 않아 개선하기 위해 머리를 싸매고 있네요..😅"* — **학생 자가 *현 코드 만족도 명시*** = *MCP `oh-my-oop` 의 *학생 결정 + reviewer 협력* 어휘와 일치*. PR #128·#135·#108·#133·#98·#95·#99·#46 결.
+
+#### 3.5. *reviewer 가 *학생 결정 존중* + *공동 고민 권유**
+
+KwonDae: *"오둥이도 이부분이 마음에 들지 않는다면 같이 고민해봐도 좋을 것 같습니다"* — **공동 학습 어휘**. PR #46 (말리빈 *"슬랙 DM도 좋고"*) / PR #99 (KwonDae *DM 권유*) 결.
+
+### 4. `play 함수 + onHit 람다 → 생성자 주입` 권유 — Higher Order Function 자가 학습
+
+KwonDae: *"지금 공통 로직을 잘 분리해주셨는데요, play 함수도 `onHit: (String) -> Boolean,` 외에는 동작이 같아서 사용자가 HIt를 할지 말지에 대한 람다는 Player의 생성자에서 받아보는건 어떨까요? Dealer와 같은 [HIgher Order Function](https://kotlinlang.org/docs/lambdas.html#higher-order-functions)이 될 수 있어보여 이 함수도 추상화가 가능할 것 같습니다."*
+
+→ **2 가지 학습**:
+
+#### 4.1. *람다 인자 주입 vs 생성자 주입*
+
+- *매 호출마다 람다 인자 주입* = *호출자가 매번 람다 전달*.
+- *생성자에서 람다 보유* = *객체 생성 시 1회 + 매 호출에서 재사용*.
+- *호출 횟수 N 회 시* = *생성자 주입 정공*.
+
+#### 4.2. *Higher Order Function 외부 글*
+
+KwonDae 가 *Kotlin 공식 문서 인용* — **외부 자료 첨부**. PR #95·#67·#23·#26·#16·#46 의 *외부 자료 첨부* 결.
+
+### 5. `PointCalculator` 도메인 모델 vs 분리 — PR 본문 자가 의문
+
+PR 본문 학생 자가 의문: *"calculator를 domain model(일급 컬렉션)에 넣는 것이 맞는것일까.."*
+
+KwonDae 답변: *"딜러와 플레이어의 카드 계산 방식이 다른걸까요?.? 이 고민은 Participant 클래스를 abstract class로 추상화 시킴으로써 해결이 가능할거라 생각합니다. (...) 지금 고민중이신 카드계산은 공통로직에 해당하여 추상클래스에서 공통로직으로 소화할 수 있습니다."*
+
+학생 후속: *"게임의 기획이 바뀌어 카드 score 계산 알고리즘이 바뀔 수도 있을 것 같아, 계산 알고리즘을 따로 빼두려 했습니다!"*
+
+→ **2 가지 학습**:
+
+#### 5.1. *전략 패턴 의도 (`PointCalculator` 분리)*
+
+- *카드 점수 계산 알고리즘 변동 가능성* = *전략 객체 (PointCalculator) 분리* 의도.
+- *YAGNI 위반 가능성*: *현재 요구사항에는 단일 알고리즘 (블랙잭 점수)*.
+
+PR #146 (yrsel *YAGNI 자가 인정*) / PR #67 (s6m1n 1단계 *PointCalculator 등장 가능*) 결.
+
+#### 5.2. *Participant abstract class 공통 로직 vs 별도 객체*
+
+- *Participant abstract class* = *상속 + 메서드 공통 위치*.
+- *별도 PointCalculator* = *컴포지션 + 책임 분리*.
+
+**상속 vs 컴포지션 트레이드오프**. PR #95·#74·#46 결.
+
+### 6. `Rank.label`, `Suit.스페이드` View 누수 자가 학습
+
+KwonDae 1차: *"label 은 출력용으로 존재하는 걸까요? 출력되는 문구를 모양으로 바꾼다던가 수정 사항이 생긴다면 도메인 로직을 수정해야 하겠네요 🧐"*
+
+학생: *"완전 아차싶네요.. 수정하겠습니다!!💪"*
+
+KwonDae 2차: *"`스페이드` 는 도메인로직일까요? 위에 Rank 의 label 처럼 문구가 아닌 모양으로 수정되어야 한다면 도메인 로직이 수정되어야 합니다."*
+
+학생: *"오...! 놏치고 있었네요 반영하겠습니다~!"*
+
+→ **MCP 기존 룰 `enum-with-ui-value`** (lotto/blackjack 다수 PR 결). PR #28·#78·#112·#125·#147·#23·#26 결.
+
+### 7. `Deck.shuffle()` 매번 vs 생성 시 1회
+
+KwonDae: *"카드를 뽑는 로직인 pull() 메서드 내부의 shuffle 이라는 랜덤요소로 테스트가 불가능한 상황입니다. Deck이 생성되는 때 받는 카드들이 이미 랜덤요소가 들어간 상태로 받는다면 매번 pull() 할 때 마다 shuffle 행동이 필요할까요? 실제로 블랙잭 게임에서도 hit 할 때 마다 섞지 않습니다 🧐"*
+
+→ **현실 메타포 + 테스터빌리티**:
+- *현실 블랙잭* = *덱 셔플 1회 + 매 카드 뽑기*.
+- *학생 코드* = *매 뽑기마다 셔플 (무한 셔플)* = *현실 룰 X + 테스트 불가*.
+- *해결* = *Deck 생성 시 셔플 1회 + 매 뽑기는 결정적*.
+
+PR #74·#23·#95·#99·#26·#39·#46 의 *랜덤 테스트* 결.
+
+### 8. `Controller god-object → 참가자 스스로 행동`
+
+KwonDae: *"ParticipantHands를 통해서 플레이어를 생성해야 할까요? `player.firstDraw(deck)` `dealer.firstDraw(deck)` 객체 스스로 행동하게끔 매세지만 던져볼까요?"*
+
+KwonDae 별도: *"이 클래스 대신 참가자(딜러, 플레이어)가 스스로 행동하게끔 할 수 있을까요? Controller에서 이부분에 대한 코멘트 드린 부분과 연결되는 내용입니다."*
+
+→ **Tell-Don't-Ask + Controller god-object**. PR #99·#95·#28·#78·#112·#125·#147·#43 결.
+
+### 9. `GameResult` 승/패/무 도메인 vs UI
+
+KwonDae: *"승,패,무는 도메인 로직일까요~? UI 로직이 수정된다면 여기서 수정이 일어나야 됩니다 🧐"*
+
+→ **enum-with-ui-value 결**.
+
+### 10. `Deck 테스트` 추가 권고
+
+KwonDae: *"이 도메인에 대한 테스트는 진행되지 않았네요. card를 생성자로 주입받음으로써 테스트가 가능하게끔은 잘해주셨습니다 👍 예로, 아래 테스트도 진행해볼까요? > A하트 카드 한장이 남았을 때, Hit시 A하트 카드가 나와야 한다."*
+
+→ **결정적 테스트 케이스 권고**. PR #16·#39·#46·#23·#26 결.
+
+### 11. `ktlint` 확인 권고
+
+KwonDae: *"ktlint 확인해주세요! 👍"* (이미지 첨부).
+
+→ **린터 = 코드 컨벤션 자동화**. PR #41·#137·#148 의 *Kotlin 어휘* 결의 *컨벤션 도구*.
+
+## 리뷰어 의견 요지 (KwonDae / 제이든)
+
+24 코멘트 특징 (PR #99 와 동일 reviewer):
+
+- **이미지 첨부** — ktlint 결과 화면. **시각 자료** — PR #46 (krrong *Parameterized Test 스크린샷*) 결.
+- **외부 글 첨부** — *Kotlin 공식 문서 (lambdas + inheritance)*. PR #95·#67·#23·#26·#16·#46 결.
+- **메타 질문 + 학생 자가 답변 유도** — *"Hand는 일급컬렉션 일까요?"*, *"label 은 출력용으로 존재하는 걸까요?"*, *"승,패,무는 도메인 로직일까요~?"*.
+- **`?.?`, `🧐` 등 가벼운 이모티콘** — *학생 친화적 어조*. PR #99 (KwonDae *`?.?`*) / PR #95 (말리빈 *`?_?`*) 와 동일 어휘.
+- **reviewer 자가 사과** — *"앗, 제가 오히려 헷갈리게 질문을 드린거 같아 죄송하네요 🥲"* — PR #95·#46·#137 결.
+- **공동 학습 권유** — *"같이 고민해봐도 좋을 것 같습니다"* — PR #46 (말리빈 *DM 권유*) / PR #99 (KwonDae *DM 권유*) 결.
+- **학생 결정 존중** — Hand vs Participant 토론에서 *학생 주장 수용 후 추가 권고 X*. **MCP `oh-my-oop` 의 *학생 선택지 인정* 어휘**.
+
+## 대표 인용
+
+> *"calculator를 domain model(일급 컬렉션)에 넣는 것이 맞는것일까.. 라는 고민을 하고 있습니다. 이에 대해 제이든의 피드백을 받고 싶습니다🙋‍♂️"* — murjune (PR 본문 학생 자가 의문 + 이미지)
+
+> *"저는 일급컬렉션이 기본 collection 에 `비지니스 로직을 입힌 domain model` 이라고 스스로 정의했습니다."* — murjune (학생 자가 일급 컬렉션 정의)
+
+> *"실제 블랙잭 게임에서 딜러와 플레이어가 둘다 Bust 상태 일 때, 플레이어가 지는 것으로 알고 있습니다! 따라서, 딜러와 플레이어의 계산 방식이 약간 다릅니다!! 사실 이 부분이 마음에 들지 않아 개선하기 위해 머리를 싸매고 있네요..😅"* — murjune (학생 자가 도메인 룰 인용 + 자가 만족도 명시)
+
+> *"오둥이의 블랙잭 게임장은 둘 다 bust 일 때 플레이어가 패배하는 룰을 적용하고 있었군요..! 오둥이도 이부분이 마음에 들지 않는다면 같이 고민해봐도 좋을 것 같습니다 :)"* — KwonDae (학생 결정 존중 + 공동 학습 권유)
+
+> *"앗, 제가 오히려 헷갈리게 질문을 드린거 같아 죄송하네요 🥲"* — KwonDae (reviewer 자가 사과)
+
+> *"이 경우에 Hand는 일급컬렉션 일까요?"* — KwonDae (정의 자가 의문 + 학생 자가 답변 유도)
+
+## 얻은 교훈
+
+1. **`by` 키워드 (Kotlin Delegation) + 일급 컬렉션 양가성** — *`class Hand(...) : List<Card> by cards`* = *위임 + 일급 컬렉션 양가성*. **MCP 룰 후보 `delegate-vs-firstclass-collection`**. PR #74 (송핑크 *Delegate vs 일급 컬렉션 토론*) 결.
+
+2. **`value class` Kotlin 어휘** — *Kotlin 1.5+ inline 성능 + 타입 안전성*. PR #137·#148·#90·#146·#39 의 *Kotlin 어휘 학습* 결.
+
+3. **`Higher Order Function` + 생성자 주입** — *람다 인자 주입 (매 호출) vs 생성자 주입 (1 회 + 재사용)*. **MCP 룰 후보 `lambda-injection-locus`**. PR #46 (krrong *Kotlin 어휘*) / PR #137·#132·#99·#23 의 *onXX 콜백* 결.
+
+4. **`Hand vs Participant` 책임 위치 양방향 토론** — *Hand = 데이터 응집 / Participant = 상태 변경 응집*. **둘 다 유효 + 다른 트레이드오프 + 학생 결정 존중**. PR #99·#98·#46·#74·#43 의 *Hand 클래스 도입* 결.
+
+5. **`참가자 vs 참가자 일반화 (`judge(other: Participant)`)`** + **블랙잭 룰 비대칭 (둘 다 Bust 시 플레이어 패배)** — *판정 룰이 *대칭* 이면 일반화 정공 / *비대칭* 이면 각자 다른 구현 필요*. **MCP 룰 후보 `judge-symmetry-violation`**. PR #46·#95·#23·#148·#151·#49·#132 결.
+
+6. **`외부 블로그 인용 + 자가 정의 검증`** — *학생이 *외부 일급 컬렉션 정의 (1 변수만)* 인용 + *자가 코드가 규칙 위반인지 자가 검증*. **외부 자료 + 자가 검증 학생 모범**. PR #95·#67·#23·#26·#16·#46 의 *외부 자료 첨부* 결의 *학생측*.
+
+7. **`Deck.shuffle()` 매번 vs 생성 시 1회** — *현실 메타포 + 테스터빌리티*. *현실 룰 = 셔플 1회 + 매 카드 결정적*. PR #74·#23·#95·#99·#26·#39·#46 결.
+
+8. **`reviewer 자가 사과 + 자가 부연`** — *"제가 오히려 헷갈리게 질문을 드린거 같아 죄송하네요 🥲"* — **양방향 토론 + reviewer 자가 한계 인정**. PR #95·#46·#137·#147·#151 결.
+
+9. **`공동 학습 권유`** — *"같이 고민해봐도 좋을 것 같습니다"* — **학생/reviewer 협력 어휘**. PR #46 (말리빈 *DM 권유*) / PR #99 (KwonDae *DM 권유*) 결.
+
+10. **`enum-with-ui-value` 결 (Rank.label, Suit.스페이드)** — **MCP 기존 룰** + lotto/blackjack 다수 PR. PR #28·#78·#112·#125·#147·#23·#26·#16 결.
+
+11. **`Test Fixture 활용`** — *PR #99 (KwonDae *Test Fixture 품질*) 권고가 PR #77 학생에게 *적용된 후 칭찬* 받는 패턴* — **reviewer 의 학습 시드가 다른 학생에게 이어지는 *학습 전파 케이스***.
+
+12. **`PR 본문 자가 의문 + 이미지`** — *코드 이미지 첨부* + *외부 자료 인용* + *자가 학습* — **학생 자가 학습 가시화 모범**. PR #98·#99·#136·#137·#148·#46 결.
+
+13. **`PointCalculator` 분리 = YAGNI 위반 vs 전략 패턴 의도** — *현재 단일 알고리즘 + 미래 변동 가능성*. *PR #146 (YAGNI 자가 인정)* 결. **MCP 룰 후보 `premature-strategy-extraction`**.
+
+14. **`ktlint` 자동 컨벤션 도구** — *Kotlin 어휘 + 컨벤션 자동화*. *리뷰어가 *코드 스타일 = 자동화 도구* 권유*.

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

@@ -0,0 +1,280 @@
+# PR #91 — [블랙잭 2단계] 오둥이 미션
+
+- **Reviewee:** [@murjune](https://github.com/murjune)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/91
+- **단계:** 2단계
+- **리뷰어:** @KwonDae (제이든)
+- **라인 코멘트:** 13 스레드 — *학생 자가 깊은 메타 토론 + PR 본문 자가 의문 2개 + 외부 책 인용 (엘레강트 오브젝트 + 헤드퍼스트 디자인 패턴)*
+- **양 단계 분석 reviewee** (1단계 #77 별도). PR #99·#67·#77 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 2개 + 외부 책 인용 + 코드 첨부** — *UiModel postfix 자가 의문 (엘레강트 오브젝트 인용)* + *상태 패턴 의문 (Heads First Design Patterns 인용)* + *외부 블로그 링크 첨부*. **학생 자가 학습 매우 깊은 모범** — PR #128·#135·#108·#136·#137·#148·#151·#98·#95·#99·#46·#77 결.
+- **`sealed class` 학생 자가 매우 긴 답변 (Kotlin 어휘 자가 정리)** — KwonDae 메타 질문: *"abstract class 로 선언했을 때와 어떤 차이점이 있을까요?"* + 학생: *"sealed class 는 컴파일 시점에 sub class 들이 결정되는 special 한 abstract class 입니다! sealed class 는 abstract class 와 달리 구현체가 같은 패키지 안에만 있어야 합니다. 따라서, 다른 패키지에서 super class를 상속하지 못합니다. 이에 따라, 컴파일러가 해당 super class 의 자손들을 모두 알고 있기 때문에 when 문에서 `else 문`을 사용하지 않아도 됩니다. 이에 따른 장점) else 문이 없기 때문에, sub class 를 추가했을 때 when 절에서 컴파일 에러가 발생하여 추가적인 로직 처리를 강제 시킵니다. 이를 통해, else 문이 발생시킬 수 있는 논리 에러를 방지할 수 있다는 장점이 있습니다! (따라서, else 문을 사용하면 sealed class 를 사용할 이유가 없다고 생각합니다)"*. **Kotlin 어휘 학생 자가 정리 모범 (sealed vs abstract + when exhaustive 효과)** — PR #98 (chaehyuns *sealed class 자가 학습*) / PR #137·#148·#90·#146 결.
+- **`super` 키워드 자가 학습 + 자가 위험 인식** — 학생: *"super 키워드를 사용하여 Bust 와 같이 예외적인 상황은 sub class 가 처리하도록 하고, 기본 로직은 super class 의 judge 를 통해 처리하도록 했습니다. (...) 다만, super class 의 judge 기능이 바뀔 때 sub class 들도 이에 대한 변경이 강제되었습니다. 따라서, 부모의 규칙을 반드시 자식도 지켜야할 때만 open 키워드로 확장을 열어야 겠다는 생각을 했습니다. 또 한가지 든 생각이 해당 judge 함수를 잘 모르는 사람이 이를 override 하여 재정의한다면 저의 의도와 다르게 사용할 수도 있어 위험할 수 있겠다는 염려도 있었습니다.(제가 처음 Activity의 onCreate, onStart 함수들을 사용할 때 이상하게 사용했거든요 🥲)"*. **상속 양가성 자가 학습 + 안드로이드 경험 인용 모범**. PR #46·#77·#23 의 *상속 학습* 결.
+- **상태 패턴 양방향 토론 + Heads First Design Patterns 코드 인용** — 학생이 *책 코드 직접 첨부 + 자가 의문 명시*. **외부 자료 + 자가 검증 모범** — PR #95·#67·#23·#26·#16·#46·#77 의 *외부 자료* 결.
+- **`ParameterizedTest` 활용** — KwonDae 칭찬 *"ParameterizedTest 활용 👍 👍"*. PR #46 (krrong *Parameterized Test 자가 토론*) 결.
+- **`abstract fun` 활용 칭찬** — KwonDae *"abstract fun 활용 👍"*. PR #16 (SeongHoonC *abstract vs open 자가 학습*) 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `UiModel postfix` 자가 의문 — 엘레강트 오브젝트 인용
+
+PR 본문 학생 자가 의문 (엘레강트 오브젝트 인용):
+
+> *"객체를 '정보를 수정하거나 스스로 어떤 일을 수행할 만큼 똑똑하지 못하기 때문에 단순히 정보를 전달하는 용도' 로 사용하지말고, '스스로 결정을 내리고 행동할 수 있는 자립적인 엔티티'로 사용하라"*
+>
+> *"현재 제가 만든 UiModel 은 단순히 데이터를 View 에 편하게 전달하기 위한 용도로만 사용하고 있습니다. 따라서 책에서 말하는 '스스로 결정을 내리고 행동할 수 있는 자립적인 엔티티' 라고는 보기 힘듭니다..🥲 이러한, UiModel 에게 다른 책임을 좀 더 부여하여 `UiModel` 이라는 postfix 를 떼어버릴 수 있도록 하는 것이 좋을까요??"*
+
+KwonDae 답변 (UiModel 미래 책임 명시):
+
+> *"UiModel을 잘 작성해주셨어요 👍 지금은 콘솔 출력이기에 크게 쓰임새가 있진 않지만, 안드로이드 개발을 진행하다 보면 Domain model 데이터 그대로 보여주기보다 1. 가공을 하거나 2. 새로운 필드가 필요할 경우 3. UiModel 에서 책임이 있는 함수(ex.특정 글자 하이라이팅) 지금도 만약 조건별로 출력조건이 다르다면 UiModel 에 로직이 추가되어야 할 것입니다. 그렇다면 스스로 결정하고 판단할 수 있는 객체가 되겠지요. 현재 요구사항에서는 유지..."*
+
+→ **3 가지 메타 학습**:
+
+#### 1.1. *DTO/UiModel = 자립적 객체 vs 데이터 운반자 양가성*
+
+- *엘레강트 오브젝트 (Yegor Bugayenko)* = *모든 객체는 자립적 + 행동 보유*. *DTO = 안티패턴* 시점.
+- *MVVM / Android* = *UiModel = ViewModel ↔ View 사이 변환 데이터 + 가공 로직 보유 가능*.
+- *현재 콘솔 미션 = 가공 로직 미미 → 단순 운반자*. *향후 안드로이드 = 책임 추가 시 자립적*.
+
+**MCP 룰 후보 — `uimodel-passive-vs-active-tension`** = *현재 책임 부족 vs 미래 책임 가능성 트레이드오프*.
+
+#### 1.2. *외부 책 (엘레강트 오브젝트) 자가 인용 + 자가 의문*
+
+학생이 *책 내용 발췌 + 자가 코드와 비교 + 자가 후회* — *외부 학습 + 자가 검증 모범*. **PR #136 (oungsi2000 *엘레강트 오브젝트 4.2/2.2 인용*) 와 같은 결**.
+
+#### 1.3. *reviewer 가 *미래 책임 명시* + *현재 OK 인정**
+
+KwonDae 의 *"현재 요구사항에서는 유지..."* (미완성 텍스트, 추정 "유지하시되 미래에 책임 추가 시 재고려" 의미) — *현재 코드 OK 인정 + 미래 시나리오 명시*. **MCP `oh-my-oop` 의 *N 안 + 트레이드오프* 어휘**.
+
+PR #74 (송핑크 *Delegate 자가 학습 + 트레이드오프*) / PR #46 (krrong *BettingMoney 곱셈 자가 의문*) 결.
+
+### 2. `상태 패턴 Context↔State 양방향` vs `Context→State 단방향` — PR 본문 자가 의문
+
+PR 본문 학생 자가 의문:
+
+> *"전통적인 상태 패턴은 state 가 context 를 들고 있고, 여러 state 가 상황에 맞게 context의 state를 update 하는 방식으로 알고 있습니다!! 그러나, 저는 state 와 context 가 서로 양방향 의존관계를 가지고 있다는 점이 추후 문제가 될 수 있다 판단하여 participant(context) ---> state 단방향 형태로 구현하였습니다. 이유) context 혹은 state를 변경하면 다른 클래스도 변경해야 하기 때문에 확장성 및 유지보수가 어려워질 것을 염려했습니다."*
+
+KwonDae 1차 답변 (정의 재설명):
+
+> *"정의를 다시 할 필요가 있습니다. 상태 패턴에서의 context 란 State 를 저장하고 관리하는 역할을 갖고 있는 호스트 객체를 뜻합니다. Context는 내부적으로 상황에 따라 State를 변경할 수 있고, 그 외에 상태에 영향을 줄 수 있는 변수들은 갖고 있습니다. 그렇다면 위 의문점이 깔끔하게 해소가 될까요? 🧐"*
+
+학생 자가 명확화 + 책 코드 인용:
+
+> *"제 의도와 맞지 않게 잘못 질문한것 같습니다.. 죄송합니다. 😥 저는 [헤드퍼스트 디자인 패턴] 을 기반으로 상태 패턴을 학습하였습니다. 책에서는, 아래 코드와 같이 state 도 context 를 들고 있고, state의 액션이 끝나면 context의 setState를 호출하여 상태를 업데이트를 합니다. state와 context가 서로를 가지고 있는 아래와 같은 상태 패턴을 실제로 사용하는지 의문이 들어 질문한 것이였습니다!"*
+
+KwonDae 2차 답변 (양방향 트레이드오프):
+
+> *"좋은 질문을 주셨네요 👍 제 개인적인 생각으로는 두가지 방법은 장단점이 뚜렷합니다.*
+>
+> *1. Context -> State: 이 경우는 State가 Context를 알 필요가 없습니다. 단지 State에 따라 내부적으로 상태에 따라 필요한 로직을 수행하며, 상태가 변경될 때 새로운 상태를 생성할 수 있습니다.*
+>
+> *2. Context <-> State: 양방향 의존성이 있다면, 1:1로 코드의 복잡성이 증가할 수 있고 재사용이 어려워질 수 있습니다. 다만, State가 Context를 알고 있기에 상태 전환시 Context 로직에 대한 제어를 갖게될 수 있기에 Context는 단순히 상태를 전환하는 업무를 수행하고, 비즈니스 로직을 위임받은 State가 상태에 따른 로직을 수행할 수 있겠죠. 그만큼 상태에 따라 유기적으로 수행하는 장점이 있다고 생각합니다."*
+
+학생: *"2가지 방식을 알기 쉽게 설명해주셔서 감사합니다~!! 1 : N 관계가 아니라면 Context <-> State 방식도 한 번 시도해봐야겠습니다~!!💪"*
+
+→ **5 가지 학습**:
+
+#### 2.1. *학생 자가 의문 + 책 코드 인용 + 자가 의도 명확화 (3 단계)*
+
+1. *자가 의문* (PR 본문) = 양방향 의존 *문제 시*.
+2. *reviewer 정의 재설명* (Context = 호스트 객체).
+3. *자가 의문 명확화* (책 코드 첨부 + 자가 의도 명시: *"실제로 사용하는지 의문"*).
+
+**3 단계 학생 자가 토론 + 의도 명확화 모범**. PR #95 (송핑크 *"이해를 못했습니다"*) / PR #46 (krrong *3 단계 토론*) / PR #43 (chws0508 *4 후보 명시*) 결.
+
+#### 2.2. *Context↔State (양방향) vs Context→State (단방향)*
+
+- **Context→State** (학생 선택):
+  - State 는 Context 무관 = 재사용 친화 + 결합도 한정.
+  - 단점: Context 가 모든 분기 책임 = 분기 많을 시 복잡.
+- **Context↔State** (책 표준):
+  - State 가 Context 의 setState 호출 = 상태 전환 책임이 State 에.
+  - 단점: 양방향 의존 = 재사용 어려움 + 복잡성 증가.
+  - 장점: Context 는 단순 + State 자기 도메인 로직 응집.
+
+PR #98 (chaehyuns *State 자가 학습 + Player 들고 있음*) / PR #39 (rhthrhrl0 *State 생성자 주입*) / PR #43·#152·#93·#136 의 *State 정공* 결.
+
+#### 2.3. *KwonDae 의 *"좋은 질문을 주셨네요"* — reviewer 가 학생 의문 인정*
+
+학생의 *책 코드 첨부 후 명확화* 가 *reviewer 의 새로운 답변 (트레이드오프 양방향)* 유도. **양방향 토론 모범**. PR #95·#46·#137 결.
+
+#### 2.4. *"개인적인 생각으로는"* — reviewer 메타 어휘*
+
+KwonDae 의 *"제 개인적인 생각으로는"* — **개인 의견 메타 분리**. PR #23 (말리빈 *"제 개인적인 의견입니다 ㅎ_ㅎ"*) / PR #26 (잭슨 *"개인적인 의견이니 참고만"*) / PR #43 (잭슨 *"정답은 없는거니"*) / PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) 결의 *KwonDae 어휘 합류*. **MCP `oh-my-oop` 핵심 가치와 일치**.
+
+#### 2.5. *책 (헤드퍼스트 디자인 패턴) 인용 + 코드 직접 첨부*
+
+학생이 *책 코드 그대로 첨부* + *자가 의문 명시* — *외부 자료 + 자가 검증 학생 모범*. PR #136 (oungsi2000 *엘레강트 오브젝트*) / PR #98 (chaehyuns *Heads First Design Patterns*) 결.
+
+### 3. `Result vs runCatching` 위치 — Controller vs View 양방향 토론
+
+KwonDae 1차: *"InputView.fetchBetting() 으로부터 `Result<List<Betting>>` 값을 받거나, `List<Betting>?` 을 받도록 한다면 Controller에서의 로직이 단순해질 수 있을까요?"*
+
+학생 자가 반박: *"Betting 에서 논리적 오류가 발생하였기 때문에 재시작을 위하여 runCatching 을 사용하였습니다! 그리고, 해당 error 는 Domain 으로부터 던져진 Error 이기 때문에 Controller에서 처리하도록했습니다. 혹시, View 에서 해당 에러를 핸들링하라고 하신 이유가 있을까요?!"*
+
+KwonDae 2차 (의도 명확화 + 코드 첨부):
+
+> *"저의 코멘트 의도는 에러가 발생할 가능성이 있는 InputView 클래스 내 `inputView.fetchBetting(name)` 에서 runCatching으로 감싸 이에 대한 결과값으로 `Result` or `List<Betting>?` 를 통한 성공/실패 시에 대한 로직 처리가 Controller에서 하는게 어울리지 않을까하는 코드의 위치 관점에서 였습니다."*
+
+```kotlin
+private tailrec fun createBetting(name: String): Betting {
+    return inputView.fetchBetting(name)
+        .onFailure { ... }
+        .getOrT...
+```
+
+→ **3 가지 학습**:
+
+#### 3.1. *Domain 에러 vs View 에러 위치*
+
+- *학생 해석*: *Betting 검증 = 도메인 = Controller 가 처리*.
+- *KwonDae 의도*: *runCatching 위치 = InputView 에서 + Result 반환 → Controller 가 onSuccess/onFailure 처리*.
+
+#### 3.2. *runCatching 위치 = 에러 발생 근접*
+
+- *View 가 입력 받음 → 도메인 객체 생성 시점 = View 가 *에러 발생 가능 코드 영역**.
+- *try/catch 또는 runCatching 위치* = *호출자 (Controller) 가 *결과만* 받도록* — *View 의 책임이 *입력 + 결과 반환*.
+
+#### 3.3. *학생 자가 의문 ("혹시 ~ 이유가 있을까요?")*
+
+학생이 *자가 정당화 + reviewer 의도 의문* — **3 단계 토론 모범**. PR #46 (krrong *3 단계 토론*) / PR #95·#43 결.
+
+### 4. `finishState 미할당 시 예외 vs null` — 학생 자가 *논리적 오류* 자가 결정
+
+KwonDae: *"현재 finishState 가 값이 할당이 되지 않으면 예외가 발생하여 프로그램이 종료될텐데요, 지난 로또 미션에서의 오류에 대해 어떻게 처리했었는지 배웠던 것 처럼 `논리적인 오류가 아니면 예외를 던지지 말고 null을 반환한다.` 를 활용해보는건 어떨까요?"*
+
+학생 자가 반박: *"저는 참가자의 state가 finishState 가 아닌데, judge() 함수를 호출하는 것이 논리적 오류라 판단했습니다. 그 이유는, Participant 가 아직 블랙잭 게임을 Play하지도 않았는데, judge를 호출하는 것이 의도대로 동작하지 않는 논리 에러 라 생각했기 때문입니다. 따라서, 다른 개발자가 Play하지도 않았는데, judge를 호출한다면 예외를 발생시켜 개발자에게 알리고자 했습니다!"*
+
+→ **2 가지 학습**:
+
+#### 4.1. *논리적 오류 vs 입력 오류*
+
+- **논리적 오류 (학생 자가 분류)** = *코드 호출 순서 잘못* (예: `judge()` 가 finished 전 호출). *Exception 정공* = *개발자에게 즉시 알림*.
+- **입력 오류** = *사용자 입력 X 또는 형식 잘못*. *null/Result 반환* = *재시도 가능*.
+
+#### 4.2. *학생 자가 *분류 기준* 명시 + reviewer 권고 반박*
+
+학생이 *자기 코드의 *오류 종류* 를 *논리적 오류* 로 분류 + 권고 거부 + 이유 명시*. **자가 분류 + 권고 반박 모범**. PR #46·#43·#95 결의 *학생 자가 결정 + 이유 명시*.
+
+PR #143·#147 (sealed without differentiation) / PR #98 (chaehyuns *상태 패턴 효과 의문*) 결.
+
+### 5. `프로퍼티 vs 함수` 자가 인정
+
+KwonDae: *"프로퍼티로 선언하지 않은 이유가 있을까요?"*
+
+학생: *"실수한 것 같습니다.. 반영하겠습니다!"*
+
+→ **Kotlin 어휘 (interface property)**. PR #43 (chws0508 *interface 프로퍼티 자가 학습*) 결.
+
+### 6. `Test Fixture 팩토리 패턴 + `List<Player>` 반환` 권유
+
+KwonDae 1차: *"given 에 중복되는 코드가 많이 들어가는데요, 차이점은 인자로 들어가는 값이군요.. 🧐 팩토리 메서드 패턴을 통해서 의미있는 객체를 보기 쉽게 생성해보는건 어떨까요? 테스트 코드는 가독성을 높이기 위해 여러 장치들을 사용하곤 합니다."*
+
+KwonDae 2차 (`createBustPlayers` 함수 코드 예시):
+
+```kotlin
+fun createBustPlayers(betting: Betting, count: Int): List<Player> {
+    return List(count) {
+        Player(NAME, betting, createBustState()) { true }
+    }
+}
+```
+
+KwonDae 3차 (`createCards vararg` 코드 예시):
+
+```kotlin
+fun createCards(vararg ranks: Rank): List<Card> {
+    return List(ranks.size) {
+        createCard(rank = ranks[it])
+    }
+}
+
+// AS-IS
+val cards = listOf(SEVEN_CARD, FIVE_CARD)
+// TO-BE
+val cards = createCards(Rank.ACE, Rank.SIX)
+```
+
+→ **PR #99 (KwonDae *Test Fixture 품질*) 의 *Test Fixture 학습 시드* 가 PR #77 (#77 학생 자가 적용 후 칭찬) → PR #91 (학습 진화 + 한 단계 더) 으로 이어지는 패턴**. **MCP 룰 후보 `test-fixture-quality-parity` 강화** = *vararg 함수 + 의미 명명 + 재사용*.
+
+### 7. `given-when-then` `given` 위치 의문 + reviewer 자가 부연
+
+KwonDae: *"제가 이전 코멘트의 내용은 사실 위 코멘트들에 더 어울리는 내용이었네요 혼란을 드린거 같아 죄송합니다 🥲 이 부분에서는 given-when-then 패턴에서 given 에 과연 어떤 값을 셋팅해두는게 효율적인가? 에 대해 고민을 해보셨으면 했습니다. 처음 봤을 땐 otherPoint, betting, expect 모두 when 에서의 어떠한 행동을 하기 전 필요한 값이라고 생각이 들 것 같다는 생각이 들었습니다."*
+
+```kotlin
+// given
+val state = createBlackjackState()
+// when
+val actual = state.calculateProfit(BETTING_10000, BLACKJ...
+```
+
+→ **2 가지 학습**:
+
+#### 7.1. *given 정의 = 상태 셋업 vs 인자 값*
+
+- *`given` = *테스트 컨텍스트 (생성 객체)***.
+- *`when` = *행동 (메서드 호출) + 필요한 인자**.
+- *학생 코드*: *otherPoint, betting, expect 모두 given* — *KwonDae 권고*: *otherPoint/betting 은 when 의 인자 / expect 는 then 의 검증값*.
+
+#### 7.2. *reviewer 자가 사과 + URL 자가 참조 + 자가 부연*
+
+KwonDae 의 *"혼란을 드린거 같아 죄송합니다 🥲"* + URL 참조 — **reviewer 자가 한계 인정 + 자가 부연 + 이전 코멘트 정정**. PR #77·#46·#16·#95·#137 결.
+
+PR #99·#26·#46 의 *given-when-then 패턴* 결.
+
+## 리뷰어 의견 요지 (KwonDae / 제이든)
+
+13 코멘트 특징:
+
+- **코드 예시 첨부 다수** — Test Fixture `createBustPlayers`, `createCards vararg`, given-when-then 분리. **코드 예시 = 학생이 바로 비교 가능**. PR #77·#99·#46 결.
+- **PR 자가 참조 + 자가 사과** — *"제가 이전 코멘트의 내용은 사실 위 코멘트들에 더 어울리는 내용이었네요 혼란을 드린거 같아 죄송합니다"*. PR #77·#46·#16·#95 결.
+- **메타 질문 + 학생 자가 답변 유도** — *"abstract class 로 선언했을 때와 어떤 차이점이 있을까요?"*, *"super 키워드를 사용하면서 어떤 장점이 있다고 생각하시나요?"*, *"프로퍼티로 선언하지 않은 이유가 있을까요?"*.
+- **개인 의견 메타 어휘** — *"제 개인적인 생각으로는"*. **MCP `oh-my-oop` 핵심 가치**. PR #23·#26·#43·#95·#46 결의 *KwonDae 어휘 합류*.
+- **이전 미션 학습 자가 연결** — *"지난 로또 미션에서의 오류에 대해 어떻게 처리했었는지 배웠던 것 처럼"* — *racingcar/lotto/blackjack 미션 간 학습 연쇄*. PR #95·#23·#46 결.
+- **양방향 토론 + 학생 의도 명확화 후 트레이드오프 답변** — 상태 패턴 / Result 위치 등에서 *학생 의도 재확인 후 양방향 답변*. PR #95·#46·#77·#137 결.
+
+## 대표 인용
+
+> *"객체를 '정보를 수정하거나 스스로 어떤 일을 수행할 만큼 똑똑하지 못하기 때문에 단순히 정보를 전달하는 용도' 로 사용하지말고, '스스로 결정을 내리고 행동할 수 있는 자립적인 엔티티'로 사용하라"* — 엘레강트 오브젝트 (murjune PR 본문 인용)
+
+> *"sealed class 는 컴파일 시점에 sub class 들이 결정되는 special 한 abstract class 입니다! (...) 컴파일러가 해당 super class 의 자손들을 모두 알고 있기 때문에 when 문에서 `else 문`을 사용하지 않아도 됩니다."* — murjune (Kotlin 어휘 학생 자가 정리)
+
+> *"또 한가지 든 생각이 해당 judge 함수를 잘 모르는 사람이 이를 override 하여 재정의한다면 저의 의도와 다르게 사용할 수도 있어 위험할 수 있겠다는 염려도 있었습니다.(제가 처음 Activity의 onCreate, onStart 함수들을 사용할 때 이상하게 사용했거든요 🥲)"* — murjune (상속 위험 자가 학습 + 안드로이드 경험 인용)
+
+> *"제 의도와 맞지 않게 잘못 질문한것 같습니다.. 죄송합니다. 😥 저는 헤드퍼스트 디자인 패턴을 기반으로 상태 패턴을 학습하였습니다."* — murjune (자가 질문 명확화 + 책 인용)
+
+> *"제 개인적인 생각으로는 두가지 방법은 장단점이 뚜렷합니다. 1. Context -> State (...) 2. Context <-> State"* — KwonDae (양방향 트레이드오프 + 개인 의견 메타)
+
+> *"저는 참가자의 state가 finishState 가 아닌데, judge() 함수를 호출하는 것이 논리적 오류라 판단했습니다."* — murjune (자가 오류 분류 + 권고 반박 + 이유 명시)
+
+## 얻은 교훈
+
+1. **`DTO/UiModel = 자립적 객체 vs 데이터 운반자 양가성`** — *엘레강트 오브젝트 (모든 객체 자립) vs MVVM (UiModel 미래 책임)*. *현재 미션 = 단순 운반자 OK + 미래 시나리오 (안드로이드 가공) = 자립적*. **MCP 룰 후보 `uimodel-passive-vs-active-tension`**. PR #136 (oungsi2000 *엘레강트 오브젝트 인용*) 결.
+
+2. **`상태 패턴 Context↔State vs Context→State` 양가성** — *책 (Heads First) 표준 = 양방향* vs *학생 단방향 의도 (결합도 한정)*. **양방향 = State 의 setState 위임 + 비즈니스 로직 응집** / **단방향 = State 재사용 + Context 분기 책임**. PR #98·#39·#43·#152·#93·#136 결.
+
+3. **`sealed class vs abstract class` Kotlin 어휘 학생 자가 정리** — *컴파일 시점 sub class 결정 + when else 불필요 + 컴파일러 강제*. **MCP 룰 후보 `sealed-class-when-exhaustive`**. PR #98·#137·#148·#90·#146 결.
+
+4. **`super 키워드 = 상속 양가성 자가 학습`** — *공통 로직 위임 장점 + super 변경 시 sub 강제 변경 + override 위험성 (Activity 경험 인용)*. PR #46·#77·#23 결.
+
+5. **`runCatching / Result 위치 = 에러 발생 근접`** — *View 입력 → 도메인 객체 생성 시점에서 runCatching + Result 반환* / *Controller 는 onSuccess/onFailure 처리*. **MCP 룰 후보 `runcatching-locus`**. PR #93 (junjange *runCatching on non-input*) 결.
+
+6. **`논리적 오류 vs 입력 오류` 분류** — *논리적 오류 = 코드 호출 순서 잘못 = Exception* / *입력 오류 = 사용자 입력 X = null/Result*. **MCP 룰 후보 `error-classification-locus`**.
+
+7. **`학생 자가 분류 + 권고 반박 + 이유 명시`** — *학생이 *자기 코드의 오류 종류* 자가 분류 + reviewer 권고 거부 + 이유 명시*. **자가 결정 + 논리 모범**. PR #46·#43·#95·#23 결.
+
+8. **`Test Fixture 진화 = vararg 함수 + 재사용`** — *PR #99 (Test Fixture 품질) → PR #77 (학습 적용) → PR #91 (vararg + 재사용 한 단계 더)*. **MCP 룰 후보 `test-fixture-quality-parity` 강화**. **reviewer 매개 학습 전파 케이스**.
+
+9. **`given-when-then` `given` 정의 — 상태 셋업 vs 인자** — *`given` = 객체 생성 / `when` = 행동 + 인자 / `then` = 검증값*. *otherPoint, betting, expect 모두 given X → 인자/검증값 위치 분리*.
+
+10. **`개인 의견 메타 어휘 (KwonDae 합류)`** — *"제 개인적인 생각으로는"* — **MCP `oh-my-oop` 핵심 가치**. PR #23·#26·#43·#95·#46 결의 *9 reviewer 모두 사용하는 공통 어휘*.
+
+11. **`reviewer 자가 사과 + URL 자가 참조 + 자가 부연`** — *학생 의문 → reviewer 자가 한계 인정 + 정정*. **양방향 토론 모범**. PR #77·#46·#16·#95·#137 결.
+
+12. **`이전 미션 학습 자가 연결 (lotto → blackjack)`** — *"지난 로또 미션에서의 오류에 대해 어떻게 처리했었는지"* — *미션 간 학습 연쇄*. PR #95·#23·#46 결.
+
+13. **`외부 책 인용 + 자가 검증` (학생측 풍부)** — *엘레강트 오브젝트 + 헤드퍼스트 디자인 패턴* — *학생이 *책 코드 직접 첨부* + *자가 의문 명시* + *자가 검증*. **MCP `oh-my-oop` 의 *학습 자료 확장* 어휘**. PR #136·#108·#46·#77 결.
+
+14. **`Activity onCreate/onStart` 안드로이드 경험 인용** — *학생이 *과거 경험* 을 *현재 코드 위험성 진단*에 활용. **메타 학습 = 도메인 간 연결**.