oh-my-oop 0.2.0

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

@@ -0,0 +1,395 @@
+# PR #106 — [블랙잭 1단계] 지오 미션
+
+- **Reviewee:** [@giovannijunseokim](https://github.com/giovannijunseokim)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/106
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 19 스레드 — *Rank.possibleValues 곱집합 매우 긴 토론 (8 단계) + Dealer.players 의존 매우 긴 토론 (7 단계) + reviewer "동료분은 프로 99% 반영" 메타 + 학생 자가 *현 관점 vs 새 관점* 자가 의문*
+- **신규 reviewee** (2024 코호트).
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 셀프 체크리스트 + 자가 의문** — *"최대한 TDD를 지키면서 프로그래밍을 해나갔는데, 시간에 급급해 구현이 부족한 부분이 많아요... 따라서 리뷰요청 및 첫 리뷰 후 전반적인 설계를 다시 처음부터 해볼 생각입니다."* — **PR 본문 자가 인정 + 재설계 의지**.
+- **`Shuffler` SAM functional interface 자가 적용** — 학생: *"덱을 섞는 로직을 Shuffler가 수행하도록 추상화한 후, 임의로 섞는 RandomShuffler를 구현했습니다! 또한 functional interface (SAM)으로 만들어 테스트 코드에서 손쉽게 Shuffler를 임의로 구현하여 사용할 수 있도록 해보았습니다!"*. **Kotlin SAM + DI 정공**. PR #77·#23·#74·#26 결.
+- **카드 카운팅 도메인 지식 자가 인용** — 학생: *"블랙잭이라는 게임이 카드 카운팅을 방지하기 위해 1개부터 최대 8개의 카드 덱을 사용한다는 도메인 지식을 확인했기 때문입니다!"* + 자가 정정: *"제가 덱과 팩에 대해 혼동하여 적은 것 같습니다. 덱: 게임에서 사용하는 모든 카드의 개수, 여러 팩이 될 수 있음. 팩: 트럼프 카드에 존재하는 52장의 묶음."* **도메인 지식 자가 인용 + 자가 정정 모범**. PR #82·#46·#107 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `ACE 기본 1 + 10 로직` vs `possibleValues Set 곱집합` — 매우 긴 8 단계 토론
+
+말리빈 1차: *"ACE의 기본 점수는 1이에요. 10점은 특수 케이스이니, 그 점은 로직으로 표현해보는 건 어떨까요?"*
+
+학생 자가 매우 긴 답변 (Rank PR 본문 위치):
+
+> *"처음 설계 단계에서 저는 Ace를 보고, 하나의 카드가 2개 이상의 값을 가질 수 있다고 생각했습니다. 때문에 Ace를 포함해서 다른 값들 모두 possibleValues라는 value의 Set을 가지도록 했고, 결과 점수를 구할 때는 모든 경우의 수를 구하기 위해 곱집합을 활용했습니다.*
+>
+> *개발을 다 하고 나니 확장성을 고려했단 생각도 들지만, 오버엔지니어링이 아닌가 하는 생각도 드네요. 😭"*
+
+말리빈 후속: *"매번 여러개의 점수를 검사하는 것은 생산성에 도움이 될까요? 오히려 끝수가 여러개의 점수를 가질 수 있다고 구성하고 싶으신 이유가 가장 궁금하네요 :)"*
+
+학생: *"저는 해당 코드가 처음 본 사람에게 더욱 직관적으로 다가올 수 있다고 생각했어요. 블랙잭을 처음 마주친 개발자라면, 가장 고민스러운 부분이 `Ace가 1도, 11도 될 수 있다.`일 것 같아요. 따라서 그 개념을 `possibleValue`라는 직관적인 형태로 옮겨놓은 것입니다!"*
+
+말리빈: *"직관적으로 보면, 카드에 적혀있는 A는 1로 보는 것이 직관적이지요. 아무나 붙잡고 ACE 카드를 보고 '이 카드는 1 또는 11점인 카드로군' 이라고 바로 생각하진 않지요. 원카드를 할때도 카드 자체는 직관적으로 1이지만 하우스 룰에 따라 3장을 먹게 하는 카드가 될 수도, 1장을 먹게하는 카드가 될 수도 있겠지요. 트럼프 카드를 활용하는 게임을 만들게 될때, 게임마다 전용 트럼프 카드를 만들어야하는 상황을 마주할수도 있겠네요."*
+
+학생: *"만약 한 프로젝트에서 트럼프 게임을 활용하는 여러 게임이 있다고 한다면, 게임마다의 추가적인 룰이 있어야 한다고 생각해요. 게임마다 카드를 활용하는 방향이 달라지니까요. 예를 들어 포커에서는 Jack, Queen, King이 11, 12, 13의 개념으로 크기 비교에 사용됩니다. (...) 따라서 저는 게임마다 트럼프 카드의 역할을 재정의해주어야 한다고 생각해요."*
+
+말리빈 최종 (양가성 인정):
+
+> *"조커는 게임 마다 카드더미를 관리하는 곳에서 어떻게 처리할지 맡기면 되겠고, 오히려 카드의 점수는 게임마다 다르니, Rank에 점수를 갖지 않고 다른 곳에서 관리해야겠다는 결론으로 도달했다면 굉장히 논리적이고 확장 가능한 설계의 이야기로 맺을 수 있었겠어요. 게임마다 점수가 다르더라도 카드의 모양새는 어느 게임에서든 똑같으니까요."*
+
+학생 자가 깨달음: *"그렇네요. RANK 자체는 점수와 무관하니까, 외부에서 BlackjackCard같은 객체가 점수에 대한 책임을 갖는 것이 좋아보입니다. 끝까지 제 의견에 대해 논의해주시고 관심가져주셔서 감사합니다!"*
+
+→ **5 가지 학습**:
+
+#### 1.1. *Rank = 점수 무관 (다른 게임에서도 동일) / 점수 책임 외부 (BlackjackCard)*
+
+- *Rank.ACE.value = 1* (블랙잭 한정) → *Rank.ACE* (점수 X) + *BlackjackScore(Rank.ACE) = 1 or 11*.
+- *PR #67·#137·#148·#46 의 점수 책임 위치* 결.
+
+#### 1.2. *직관성 자가 정당화 양가성*
+
+- *학생: possibleValue Set = 처음 본 개발자 직관*.
+- *말리빈: A 카드 = 1 직관 / 1 또는 11 = 블랙잭 룰*.
+
+#### 1.3. *학생 자가 *게임마다 트럼프 재정의* 자가 답변*
+
+학생이 *포커 J/Q/K = 11/12/13 + 조커 사용* 인용 — **다른 게임 비교 + 도메인 인용**.
+
+#### 1.4. *말리빈 *확장 가능한 설계 결론* 권유 + 학생 자가 깨달음*
+
+*"끝까지 제 의견에 대해 논의해주시고 관심가져주셔서 감사합니다!"* — **양방향 토론 + 학생 자가 깨달음 모범**.
+
+#### 1.5. *PR #82 (Hevton *4 카드 21점 = 블랙잭?*) / PR #76·#137·#148·#90·#67 의 *Ace 1↔11* 결*
+
+### 2. `Dealer.players` 의존 — 매우 긴 7 단계 토론
+
+말리빈 1차: *"딜러가 플레이어를 갖고있는 것은 굉장히 특이하네요. 현실 세계와 개발의 세계는 다르지만, 딜러가 플레이어를 갖고 있다는 것은 저에겐 좀 어색하게 다가오네요. 딜러와 플레이어가 협력할 수 있도록 다르게 구성해보는 건 어떨까요?"*
+
+학생 자가 정당화: *"딜러와 플레이어가 협력할 수 있으려면, 최소한 둘 중 하나는 다른 하나를 알고 있어야 한다고 생각하여 위와 같이 작성했습니다. 새로운 클래스를 추가하여 딜러가 플레이어를 갖고 있지 않도록 할 수 있지만, 그렇게 하면 둘 사이를 매개하는 역할의 클래스가 하나 더 생기는 건데, 그만한 가치가 있는지 아직 잘 판단하지 못하겠습니다 😭 위 코드가 어색하여 가독성이 떨어지는 점 외에도 다른 단점이 존재할까요?"*
+
+말리빈: *"`갖고 있는 것`과 `알고 있는 것`은 별개의 이야기라는 점을 유념해보세요!"*
+
+학생 자가 의문: *"딜러와 플레이어가 존재하는 클래스 `Table` 등이 생겨날 것 같은데요. 그렇게 될 경우 기존에는 하나의 클래스가 하나의 클래스에 의존했다면(Dealer -> Player) 하나의 클래스가 두 개의 클래스에 의존하여(Table -> Dealer, Player) 의존성이 하나로 몰리게 되지 않을까요? 하나의 클래스가 여러번 수정되는 것과, 여러 클래스가 한 번씩 수정되는 것은 다르다고 생각해요. 만약 여러 명이서 동시 작업을 할 때를 고려해보면, 후자가 더 좋은 것 아닐까요?"*
+
+말리빈: *"`갖고 있는 것`과 `알고 있는 것`은 둘 다 같은 의존성이 존재해요. 저는 의존성의 변화를 짚어드린 게 아니에요. 멤버로 가질 필요가 있는지를 물어본 거였어요."*
+
+학생: *"`갖고 있는 것 == 생성하는 것`으로 착각하고 있던 것 같습니다. 멤버로 갖지 않는다면, 필요한 함수에서 파라미터로 받아 사용할 수도 있을 것 같아요."*
+
+학생 자가 자가 결정: *"하지만 Dealer가 수행하는 작업 중 대부분이 List<Player>에 의존하고 있기 때문에 List<Player> 없이는 Dealer가 제대로 된 역할 수행을 하지 못한다고 생각합니다. 만약 파라미터로만 받는다면 Dealer의 중요한 의존성인 List<Player>가 명시적으로 드러나지 않는다고 생각해요. 한 두개의 함수에서만 필요로 한다면 메서드 주입을 고려해 보겠지만, 현재 상황에서는 생성자 주입이 더 좋은 방법이라고 생각합니다!"*
+
+→ **6 가지 학습**:
+
+#### 2.1. *`갖고 있는 것` vs `알고 있는 것`*
+
+- 학생: *`갖고 있는 것 == 생성하는 것`* 자가 *착각* 인정.
+- 말리빈: *갖고 있는 것 (멤버) = 알고 있는 것 (의존)* — 같은 의존성.
+
+**MCP 룰 후보 `having-vs-knowing-conflation`** = *멤버 보유 ≠ 의존 X / 둘 다 의존*.
+
+#### 2.2. *멤버 vs 파라미터 주입 양가성*
+
+- *멤버 (학생)* = *명시적 의존 + 생성자 주입*.
+- *파라미터 (말리빈 권유)* = *함수별 의존 + 호출자 책임*.
+- *학생 자가 결정 = 멤버 유지 (대부분 함수가 의존)*.
+
+PR #46 (krrong *Dealer→Player vs Participant*) / PR #95·#23 결.
+
+#### 2.3. *학생 자가 *동시 작업 시* 의존성 분산 메타 어휘*
+
+*"여러 명이서 동시 작업을 할 때를 고려해보면, 후자가 더 좋은 것 아닐까요?"* — **MCP `oh-my-oop` 의 *유지보수자 시점* 어휘 학생 자가 적용**. PR #107·#145·#82·#100 결.
+
+#### 2.4. *Dealer-Player 매개 클래스 (Table)* 학생 자가 제안
+
+PR #46 (krrong *Dealer → Participant*) / PR #82·#100·#23 결.
+
+#### 2.5. *학생 자가 결정 + 자가 정당화 (멤버 유지)*
+
+학생이 *권고 검토 후 자가 결정 유지* = *권고 맹목 추종 X*.
+
+#### 2.6. *PR #72 (ghojeong *kimhm0728 HandCards 유지 결정 존중*) 와 같은 결*
+
+### 3. `Character` 명명 → Kotlin Number 와 충돌
+
+말리빈: *"Number... Character.... 코틀린의 Number 인터페이스와 헷갈릴 위험이 크다 생각해요. Character는 Char의 무언가라는 생각이 드네요. 더 적절한 이름을 찾아보시면 좋겠어요 :)"*
+
+학생: *"안 그래도 임포트할 때 문제가 생기더라구요 😂"*
+
+→ **명명 = 표준 라이브러리 충돌 회피**. **MCP 룰 후보 `stdlib-name-conflict`**. PR #99·#39·#9 결.
+
+### 4. `Hand` 방어적 복사 + 외부 mutableList 영향
+
+말리빈: *"아래 코드를 실행시키면 어떤 문제가 발생할 수 있을까요?"*
+
+```kotlin
+val cards = mutableListOf(.....)
+val hand = Hand(cards)
+cards.clear()
+```
+
+학생: *"외부의 코드 조작이 객체 내부에 영향을 미쳐 예기치 못한 상태로 돌입할 수 있을 것 같습니다. 방어적 복사를 통해 구현할 수 있을 것 같습니다!"*
+
+학생 자가 후속 의문: *"만약 추후 사용자가 중간에 게임을 그만두고 이탈하는 기능이 생길 경우, players: List<Player>에 대한 조작이 Dealer가 들고 있는 List<Player>에도 영향을 미쳐야 할 것이라고 생각됩니다. 이런 경우에도 방어적 복사를 적용해야 할까요?"*
+
+말리빈: *"컨트롤러에 멤버들이 필요할지 고민해보세요. 연관성이 어딘가에 묶여있는 듯한 느낌이 드셨다면, 도메인이 제대로 분리되어 있는지도 고민해보시면 좋겠네요!"*
+
+→ **PR #46·#74·#108·#132·#133·#85·#58·#137·#148·#23·#26 결**. *방어적 복사 + 도메인 분리*.
+
+### 5. `Hand` 점수 계산 + Ace 1개만 11점 힌트
+
+말리빈: *"점수 로직이 조금만이라도 바뀐다면 유지보수에 용이할지 고민해보시면 좋겠어요. 점수 계산에 힌트를 하나 드리자면, ACE는 여러장을 갖고 있어도, 반드시 1개만 11점이 되어야 게임에서 패배하지 않을 수 있다는 사실에서 로직을 고안해보세요!"*
+
+→ **블랙잭 도메인 룰 핵심 힌트**. PR #76·#67·#137·#148·#46 의 *Ace 1↔11* 결.
+
+### 6. `Player + Dealer 공통 → Participant` 추상화 자가 적용
+
+말리빈: *"플레이어와 딜러는 비슷한 역할을 수행할 수 있어요. 그러한 공통 로직이 무엇일지 고민해보시고, 어떻게 중복적으로 작성하지 않고 통합할 수 있을지도 고민해보세요!"*
+
+학생 자가 적용: *"플레이어와 딜러의 공통 로직을 Participant라는 이름의 추상 클래스를 통해 통합해보았습니다!"*
+
+→ **공통 추상화 + Participant 도입**. PR #74·#108·#133·#132·#136·#49·#46·#80·#100 결.
+
+### 7. `Controller god-object → 객체 분리`
+
+말리빈: *"컨트롤러에 게임 진행의 핵심 로직들이 간간히 보이네요 :) 핵심로직을 객체로 분리해볼까요?"*
+
+→ **PR 다수 결**. 학생 자가 적용 (커밋 명시).
+
+### 8. `"21 미만"` 규칙 위치 매우 긴 토론
+
+말리빈: *"이 규칙은 '카드들'이 가져야하는 규칙일까요?"*
+
+학생: *"카드를 추가할 수 있는 곳은 card의 리스트가 존재하는 Cards라고 생각했는데, 의미론적으로는 Hand에서 가져야 할 규칙인 것 같습니다."*
+
+말리빈: *"카드를 추가하는 것을 짚은 게 아니라, 점수의 합이 21이어야만 한다는 '규칙'을 말한거였어요!"*
+
+학생: *"`'모든 카드의 합이 21 미만이 될 수 있을 경우에만 카드를 얻을 수 있습니다.'` 라는 규칙을 말씀하신 것으로 이해했습니다. 카드를 얻는 곳은 Hand이니, Hand에서 그 조건을 알아야 한다고 생각했고, 현재는 그렇게 옮겨두었습니다!"*
+
+말리빈: *"플레이어가 카드를 많이 뽑아 Busted인 경우에 점수가 21점을 넘는 경우는 '오류' 상황일까요?"*
+
+→ **3 가지 학습**:
+
+#### 8.1. *21 미만 vs Bust 룰 양가성*
+
+- *학생 코드 = `21 미만일 때만 카드 얻기` 제약*.
+- *블랙잭 룰 = Bust (21 초과) = 자동 패배 = *오류 X*.
+- *학생 코드가 *Bust 상황 자체를 차단* = 룰 정확성 X*.
+
+**MCP 룰 후보 `bust-as-error-not-state`** = *Bust = 게임 상태 / 오류 X*.
+
+#### 8.2. *학생 자가 의문 + reviewer 의도 명확화*
+
+학생이 *카드 추가 vs 점수 규칙* 혼동 → reviewer 가 *21 점수 규칙* 명확화.
+
+#### 8.3. *PR #26·#46·#16·#23·#66·#107·#22 의 블랙잭 룰 정확성* 결.
+
+### 9. `onBusted` 콜백 명명 양가성 + 학생 자가 안드로이드 onClick 비유
+
+말리빈: *"이 시그니처만 보았을 떄, onBusted가 어떤 뜻인지 바로 알 수 있을까요? 다른 개발자들은 이 메서드를 어떻게 구현해야할지 바로 감을 잡을 수 있을지도 고민해보세요."*
+
+학생 자가 답변: *"안드로이드 개발에서 클릭 이벤트에 반응해 특정 로직을 수행해야 할 때, `onClick()`을 주로 사용하는 것으로 알고 있습니다. 그 관점에서 `onBusted`는 버스트가 되었을 때 수행해야 하는 로직이라는 의미를 잘 전달하고 있다고 생각하는데, 말리빈은 왜 `onBusted`가 어떤 뜻인지 바로 알 수 없을 것이라고 생각했는지 궁금합니다."*
+
+말리빈: *"아하 버스트가 되었을 때 호출해주는 콜백이었군요! 설명을 들으니 이해가 되네요. click Listener는 외부에서 구현이 주입받는 형태가 많아서요, 여기는 클래스가 직접 콜백을 구현해야하는 것으로 보여요. 우선 이런 형태가 저에게 매우 어색하단 느낌을 많이 받았어요. Busted인 상태만 특별히 콜백을 받아야하나? 블랙잭인것도 콜백을 해줘야하나? 그렇다면 모든 것들은 다 콜백을 만들어줘야하나? 이런 생각이 드네요. 콜백의 형태가 아니더라도 Busted일 때 무언가를 수행하게끔 만드는 것은 충분히 구성해볼 수 있어 보여요 :)"*
+
+→ **3 가지 학습**:
+
+#### 9.1. *안드로이드 `onX` 콜백 vs 도메인 객체 콜백 차이*
+
+- *Android `onClick`* = *외부 주입 (View → 사용자 클릭 리스너)*.
+- *도메인 `onBusted`* = *클래스 내부 구현 + 외부 주입 X*.
+- **상황 차이 + 패턴 충돌**.
+
+**MCP 룰 후보 `android-onx-vs-domain-callback-confusion`**. PR #80 (Junyoung-WON *콜백 명명*) 결.
+
+#### 9.2. *Busted 콜백만 특별 = 다른 상태 (BlackJack, ...) 도 콜백? 메타 의문*
+
+- *colback 한 상태에만 = 일관성 X*.
+
+#### 9.3. *학생 자가 결정 변경 (Hand 생성자 파라미터)*
+
+학생: *"현재는 onBusted를 구현할 필요가 없게 만들고, Hand의 생성자 파라미터로 만들었어요. Hand를 가진 주체가 누구냐에 따라 버스트되었을 때의 동작이 다르기 때문입니다."*
+
+말리빈: *"옵저버 패턴으로 구현하라는 의미는 아니었어요."*
+
+PR #80·#82·#107·#137 결.
+
+### 10. `Score` 응집 (Cards + Hand 병합)
+
+말리빈: *"점수에 대한 역할이 여기저기 흩어져있다는 느낌이 강하게 들어요. 다른 개발자가 점수가 계산로직을 보기 위해 굉장히 많은 이동이 필요하겠어요. 이 역할들을 어떠한 객체에 응집시켜볼 수 있겠어요 :)"*
+
+학생: *"`Cards`, `Hand`의 응집도가 떨어진다는 느낌이 들어 둘을 하나로 병합해 보았습니다."*
+
+→ **점수 책임 응집**. PR #76·#16·#43·#137·#148 결.
+
+### 11. `클래스 멤버 순서 컨벤션`
+
+말리빈 + Kotlin 공식 문서: *"클래스 멤버를 정의할 때 순서를 컨벤션에 따라 작성해주세요. https://kotlinlang.org/docs/coding-conventions.html#class-layout"*
+
+→ **코드 포맷 컨벤션**. PR #145 (lee-ji-hoon *코드 포맷*) 결.
+
+### 12. `덱 리필 게임장 비유` (firstOrNull + elvis)
+
+말리빈: *"더 이상 카드를 뽑지 못하게 된다면, 게임장 문 닫고 모든 손님을 내쫓아야할까요?"*
+
+학생: *"firstOrNull과 엘비스 연산자를 활용해 덱 리필을 수행해야 할 것 같습니다."*
+
+→ **현실 비유 + Kotlin 어휘**. PR #46·#107·#22·#23·#26·#48 결.
+
+### 13. `abstract class vs interface vs open class` Kotlin 어휘
+
+말리빈: *"abstract class를 활용하신 이유가 무엇인가요? interface, open class와는 어떻게 다를까요? 이 친구들을 활용하지 않은 이유도 궁금해요 :)"*
+
+학생: *"중복 코드를 제거하기 위해 abstract class를 활용했습니다. 1. interface를 활용하지 않은 이유: protected 가시성 변경자를 사용하기 위해서입니다! 2. open class를 활용하지 않은 이유: onBusted의 구현을 강제시키기 위해서입니다!"*
+
+학생 자가 후속 결정 변경: *"다만 추상 클래스를 활용하니 상속 계층이 생겨 부모의 코드를 계속해서 확인하게 되는 문제가 발생했습니다. 따라서 interface를 활용하고 hand를 내부에서 직접 생성한 후 private 키워드를 붙여주었습니다."*
+
+→ **Kotlin 어휘 자가 정리 + 자가 결정 변경 (abstract → interface)**. PR #16·#91·#74·#95·#108·#133·#137·#147 결.
+
+### 14. `Score = 점수 vs 게임 상태` — 매우 긴 토론 (10 단계) + reviewer 메타
+
+말리빈: *"히트를 할 수 있다는 것은 점수의 상태인가요?"*
+
+학생: *"히트 가능 여부는 점수에 달려 있습니다. 따라서 점수가 `히트를 할 수 있는지`라는 상태를 들고 있어도 된다고 생각합니다."*
+
+말리빈: *"저는 역전의 관계는 아닐지 생각이 드네요. 지금의 인터페이스를 보면, 이름만 Score이지, 게임의 상태를 나타내는 것과 다르지 않아보이기도 하네요. 점수의 상태일지, 게임의 상태일지 고민해보세요!"*
+
+학생 자가 매우 긴 답변: *"게임의 상태: 특정 플레이어가 게임 내에서 어떤 상태를 들고 있는가 → 승, 패, 무, 게임 중. 점수의 상태: 현재 갖고 있는 점수가 어떤 점수인가 → 힛을 더 할 수 있는 점수, 블랙잭 점수, 블랙잭은 아니지만 최대 점수, 버스트된 점수. 물론 이렇게 하면 점수가 그냥 점수가 아니라, 블랙잭의 점수라는 조금 더 구체적인 형태로 변하죠. 다만 현재 개발중인 프로그램은 블랙잭이기 때문에, 그렇게 둬도 된다고 생각해요!"*
+
+말리빈 (정답 명시 X 어휘):
+
+> *"게임의 상태는 `시작` `진행중` `종료` 가 있다고 생각해요. 그 하위에 여러 상태들이 더 있겠어요. 종료에는 블랙잭, 버스트, 그만받기 등이 있겠지요.*
+>
+> *점점 제가 생각하는 지점을 알려드리는 것으로 수렴하는 느낌이 드네요. 이것은 정답으로 받아들일 수 있기에 여기에서 이런 형태의 피드백을 하는 것을 그리 좋아하지 않아요.*
+>
+> *이 지점이 아니더라도 질문에 방향에 맞게 다른 지점으로 가기를 희망해요. 지금의 관점을 깨고 다른 관점들을 다각도로 보는 연습을 많이 하시면 좋겠어요. 특히 관심사의 분리에 대해서요."*
+
+학생 자가 매우 긴 메타 의문 (3 가지):
+
+> *"저 또한 정답이 제공되는 피드백보다는, 스스로 생각할 여지가 주어지는 피드백을 선호합니다. (...)*
+>
+> *다만 현재 혼란스러운 지점은 **언제 현 관점을 깨고 새로운 관점으로 바라보아야 하는가?** 입니다.*
+>
+> *제가 제 코드에 대해 주장하는 부분은 코드 작성 전 고민하고, 배우고, 리뷰 후에도 고민해본 후 나온 결론입니다. 따라서 말리빈의 리뷰 덕분에 다시 생각해보고 고치게 된 코드도 많아요. 제게 있어서 그 기준은 개인적인 **납득**입니다.*
+>
+> *다만 가끔은 제가 **고집을 부리고 있지는 않은가?** 하는 생각도 들어요.*
+>
+> *- 말리빈은 어떤 기준으로 피드백에 대해 수용하나요?*
+> *- 의견을 나눌 때 있어서 제가 어떤 점을 수정하면 더욱 좋은 의견 나눔을 할 수 있을까요?"*
+
+말리빈 매우 긴 메타 답변:
+
+> *"언제든지 논리로 찍어 누를 수 있으나, 그렇게 하지 않는 이유는 그것이 정답으로 받아들여질 것이 필연적이기 때문이에요. 그러니 '개인적인 납득' 을 충족하는 답변은 저에게 얻기 어려울거예요.*
+>
+> *언제 현 관점을 깨느냐라.. 언제든지 깨면 좋겠어요. 순수 코틀린으로만 만드는 이 작은 미션에서 얼마든지 다른 구현의 갈래를 만들어 경험해볼 수 있지요. 그런 최대한 많은 경험을 하고, 장단점을 스스로 찾아 기준을 만들 수 있는 재료를 많이 가져가보시면 좋겠어요.*
+>
+> *질문이 있으셨으니 대답을 남겨둘게요. 도움이 될 것 같진 않지만요.*
+>
+> *> 말리빈은 어떤 기준으로 피드백에 대해 수용하나요?*
+> *제 동료분들은 프로라고 생각해요. 그렇기에 그들이 하는 말을 99% 반영해요."*
+
+학생 자가 최종 결정: *"앞으로는 제안된 방식에 논리적 결함이 없다면 반영해보는 것도 좋은 학습이 될 것 같네요. 감사합니다!"*
+
+→ **10 가지 메타 학습**:
+
+#### 14.1. *reviewer 자가 *정답 강요 회피* 어휘*
+
+*"제가 생각하는 지점을 알려드리는 것으로 수렴하는 느낌이 드네요. 이것은 정답으로 받아들일 수 있기에 여기에서 이런 형태의 피드백을 하는 것을 그리 좋아하지 않아요."*
+
+**MCP 핵심 가치 + reviewer 자가 명시**. PR #145 (lee-ji-hoon *"의견을 너무 어필 시"*) / PR #72·#43·#22·#26·#46·#95·#107 결.
+
+#### 14.2. *학생 자가 *현 관점 vs 새 관점 + 언제 깨는가?* 메타 의문*
+
+**MCP 룰 후보 `student-perspective-shift-self-question`** = *학생 자가 *관점 변환 시점* 자가 의문*.
+
+#### 14.3. *학생 자가 *개인적인 납득* 기준 명시*
+
+- *코드 작성 전 + 학습 + 리뷰 후 고민 → 결론*.
+- *납득 = 자가 결정 기준*.
+
+#### 14.4. *학생 자가 *고집인가?* 자가 의문*
+
+**MCP 룰 후보 `student-stubbornness-self-question`** = *학생 자가 *권고 거부 시 고집인가?* 자가 의문*.
+
+#### 14.5. *reviewer 메타: "동료분은 프로 99% 반영"*
+
+- *실무 동료 신뢰 + 99% 수용*.
+- *학습 미션 = 학생 자가 결정 존중*.
+
+#### 14.6. *reviewer 메타: "언제든지 관점 깨면 좋겠어요"*
+
+- *학습 미션 = *다양한 구현 갈래 경험* + *장단점 자가 발견*.
+- **MCP `oh-my-oop` *학습 = 시간 두고 반복* 어휘 강화**.
+
+#### 14.7. *reviewer 메타: "논리로 찍어 누를 수 있으나 정답 강요 X"*
+
+- *권력 차이 인지 (reviewer > 학생)*.
+- *권력 자제 = 학생 자가 학습 보장*.
+
+#### 14.8. *학생 자가 최종 결정 변경*
+
+*"앞으로는 제안된 방식에 논리적 결함이 없다면 반영해보는 것도 좋은 학습이 될 것 같네요"* — **학생 자가 *수용 기준* 변경**.
+
+#### 14.9. *PR #72 (ghojeong *팀별 컨벤션*) / PR #145 결의 *학습 자가 결정* 메타 강화*
+
+#### 14.10. *Score = 점수 vs 게임 상태 본 토론은 *부수적*, 메타 토론이 핵심*
+
+### 15. `firstOrNull + elvis` 덱 리필
+
+(위 §12 와 같음)
+
+### 16. `abstract → interface` 학생 자가 결정 변경
+
+(위 §13 과 같음)
+
+## 리뷰어 의견 요지 (말리빈 / malibinYun)
+
+19 코멘트 특징:
+
+- **매우 긴 메타 어휘** — *"정답으로 받아들일 수 있기에 (...) 그리 좋아하지 않아요"*, *"동료분은 프로 99% 반영"*, *"논리로 찍어 누를 수 있으나"* — **MCP 핵심 가치 강화**.
+- **8-10 단계 핑퐁 토론** (Rank possibleValues, Dealer.players, Score = 점수 vs 게임 상태) — 매우 깊은 양방향.
+- **현실 비유** (게임장 문 닫고 손님 내쫓기, A 카드 1 vs 1 또는 11 직관, 트럼프 게임마다 점수 다름) — PR #72 (서포터 비유) / PR #74·#23·#46·#26·#48 결.
+- **양가성 인정 + 학생 자가 결정 존중** — 다수 thread.
+- **외부 자료 (Kotlin coding conventions)** — PR #14·#80·#82·#22·#13 결.
+
+## 대표 인용
+
+> *"점점 제가 생각하는 지점을 알려드리는 것으로 수렴하는 느낌이 드네요. 이것은 정답으로 받아들일 수 있기에 여기에서 이런 형태의 피드백을 하는 것을 그리 좋아하지 않아요. 이 지점이 아니더라도 질문에 방향에 맞게 다른 지점으로 가기를 희망해요. 지금의 관점을 깨고 다른 관점들을 다각도로 보는 연습을 많이 하시면 좋겠어요."* — malibinYun (정답 강요 회피 + 다각도 관점 권유)
+
+> *"언제든지 논리로 찍어 누를 수 있으나, 그렇게 하지 않는 이유는 그것이 정답으로 받아들여질 것이 필연적이기 때문이에요. 그러니 '개인적인 납득' 을 충족하는 답변은 저에게 얻기 어려울거예요."* — malibinYun (reviewer 권력 자제 메타)
+
+> *"제 동료분들은 프로라고 생각해요. 그렇기에 그들이 하는 말을 99% 반영해요."* — malibinYun (실무 동료 vs 학습 미션 수용 기준 차이)
+
+> *"다만 현재 혼란스러운 지점은 **언제 현 관점을 깨고 새로운 관점으로 바라보아야 하는가?** 입니다."* — giovannijunseokim (학생 자가 관점 변환 시점 메타 의문)
+
+> *"앞으로는 제안된 방식에 논리적 결함이 없다면 반영해보는 것도 좋은 학습이 될 것 같네요."* — giovannijunseokim (학생 자가 수용 기준 결정 변경)
+
+> *"`갖고 있는 것`과 `알고 있는 것`은 둘 다 같은 의존성이 존재해요. 저는 의존성의 변화를 짚어드린 게 아니에요. 멤버로 가질 필요가 있는지를 물어본 거였어요."* — malibinYun (having vs knowing 양가성)
+
+## 얻은 교훈
+
+1. **`reviewer 정답 강요 회피 메타 어휘`** — *"정답으로 받아들일 수 있기에 (...) 좋아하지 않아요"*. **MCP 핵심 가치 강화**. PR #145·#72·#43·#22·#26·#46·#95·#107 결.
+
+2. **`reviewer 권력 자제 메타`** — *"논리로 찍어 누를 수 있으나"* — **권력 차이 인지 + 자제**. **MCP 룰 후보 `reviewer-power-restraint-meta`**.
+
+3. **`실무 vs 학습 미션 수용 기준 차이`** — *동료 = 99% 수용 / 학습 = 학생 자가 결정 존중*. **MCP 룰 후보 `professional-vs-learning-acceptance-criteria`**.
+
+4. **`학생 자가 *현 관점 vs 새 관점 + 언제 깨는가?* 메타 의문`** — **MCP 룰 후보 `student-perspective-shift-self-question`**.
+
+5. **`학생 자가 *고집인가?* 자가 의문`** — **MCP 룰 후보 `student-stubbornness-self-question`**.
+
+6. **`having vs knowing 의존성 양가성`** — *멤버 보유 = 의존 / 멤버 X = 의존 X 아님*. **MCP 룰 후보 `having-vs-knowing-conflation`**.
+
+7. **`Rank = 점수 무관 (다른 게임 동일) / 점수 책임 외부 (BlackjackCard)`** — *카드 모양 vs 점수 별도*. **MCP 룰 후보 `rank-vs-score-separation`**. PR #67·#137·#148·#46·#76 결.
+
+8. **`Bust = 게임 상태 / 오류 X`** — **MCP 룰 후보 `bust-as-error-not-state`**. PR #26·#46·#16·#23·#66·#107·#22 결.
+
+9. **`onX 콜백 안드로이드 vs 도메인 차이`** — *외부 주입 vs 내부 구현 = 패턴 충돌*. **MCP 룰 후보 `android-onx-vs-domain-callback-confusion`**. PR #80 결.
+
+10. **`stdlib name conflict`** — *Character vs Kotlin Number/Char 충돌*. **MCP 룰 후보 `stdlib-name-conflict`**. PR #99·#39·#9 결.
+
+11. **`SAM functional interface` Kotlin 어휘** — PR #77 결.
+
+12. **`abstract class vs interface vs open class` 학생 자가 결정 변경** — PR #16·#91·#74·#95 결.
+
+13. **`Set vs List` 자료구조 한계** — PR #23·#26·#11·#73 결.
+
+14. **`reviewer 8-10 단계 핑퐁 토론` 매우 깊은 양방향** — PR #145·#107·#43·#46·#76·#82 결의 *최대 깊이*.

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

@@ -0,0 +1,219 @@
+# PR #134 — [블랙잭 2단계] 지오 미션
+
+- **Reviewee:** [@giovannijunseokim](https://github.com/giovannijunseokim) (지오)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/134
+- **단계:** 2단계
+- **리뷰어:** [@malibinYun](https://github.com/malibinYun) (말리빈)
+- **라인 코멘트:** 9 스레드 — *학생 자가 답변 7 thread 매우 풍부 (val mutableList vs var listOf 장단점 도표화 + 클라이언트 입장 어휘 + abstract vs interface 자가 분류 + 책임 위치 자가 자각) + PR 본문 1단계 영감 3개 명시 + reviewer 학습 시간 부족 미션 마무리 어휘 + 상태 패턴 = 타입 캐스팅 X 숨겨진 요구사항*
+- **giovannijunseokim 양 단계 완성** (1단계 #106 = PR #106 학생 *언제 관점 깨는가* 메타 어휘).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 1단계 영감 자가 학습 진화 명시 (3개)
+
+PR 본문:
+
+> *"### 수정한 부분은 다음과 같습니다!*
+>
+> *- 딜러와 플레이어가 협력할 수 있도록 다르게 구성해보는 건 어떨까요? **딜러가 플레이어를 갖지 않고, 둘 모두 덱을 알고 있게 하여 스스로 `hit`할 수 있도록** 만들었습니다.*
+>
+> *- 게임의 상태는 시작 진행중 종료 가 있다고 생각해요. **영감을 받아 `ParticipantState`를 새롭게 구성해보았습니다!***
+>
+> *- 그 외에도 프로그래밍 요구 사항 *3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.* 를 따르다 보니 전반적으로 많은 클래스가 수정되었습니다."*
+
+→ **MCP 룰 `pr-body-prior-feedback-applied-list`** ⭐⭐ 신규 — *1단계 피드백 영감 자가 적용 리스트 + 인용 + 변경 사항*. PR #154 (`pr-body-restart-from-scratch` 처음부터 다시) 결의 *1→2단계 학습 진화* 다른 축.
+
+→ **`participant-self-hit-via-deck`** ⭐⭐ — *딜러가 플레이어를 갖지 않고 = 협력 모델 자가 학습*. PR #148·#151 (참가자 vs 참가자 일반화) 결 합류.
+
+### 2. 학생 자가 답변 매우 풍부 (7 thread, 가장 길고 깊은)
+
+7 thread 모두 학생 자가 답변 + *클라이언트 입장*·*책임은 만든 사람에게*·*결론 도표화* 등 깊은 답변.
+
+## 못한 점 (설계 관점)
+
+### 1. `val mutableList` vs `var list` 학생 자가 도표화 (Thread 2)
+
+reviewer:
+
+> *"여기는 변수로 활용한 이유가 궁금하네요. mutableList를 하나 활용해서 매번 List 객체를 만들지 않게 구성하는 것과 어떤 차이와 장단점이 있었나요?"*
+
+학생 자가 답변 정점:
+
+> *"`val`은 재할당 불가 프로퍼티, `var`은 재할당이 가능한 프로퍼티라고 알고 있습니다. 하지만 내부 요소가 변할 수 있기에 `val`로 선언해도 주소값이 변하지 않을 뿐 객체의 내부 요소는 변할 수 있다고 생각합니다.*
+>
+> *저는 이 내부 요소의 변경을 최소화하고 싶었습니다. 가변 객체보다 불변 객체가 더욱 직관적이고 이해하기 쉬울거라고 생각했습니다.*
+>
+> ***결론***
+> *`val mutableList = mutableListOf()`*
+> *장점: 변경 시 객체 생성이 일어나지 않음*
+> *단점: 가변 객체이기 때문에 상태 예측이 어려움, `val`로 선언되었으나 변경 가능한 것이 직관적이지는 않음(개인 의견)*
+>
+> *`var list = listOf()`*
+> *장점: 불변 객체이기 땜문에 상태 예측이 쉬움*
+> *단점: `var` 프로퍼티이기 때문에 재할당이 가능하므로 상태 예측이 큰 의미가 없을 수 있음, 변경 시 객체 생성이 일어나 성능이 좋지 못함"*
+
+→ **MCP 룰 `student-self-pros-cons-tabulation`** ⭐⭐⭐ **신규 정점** — *학생 자가 트레이드오프 도표화 + 결론 명시 어휘*. PR #106·#62 (학생 자가 의문) 결의 *학생 자가 깊은 분석* 다른 축 — *도표 형식 정점*.
+
+→ **`val-mutable-vs-var-immutable-tradeoff`** ⭐⭐⭐ — *내부 mutation 직관성 vs 성능 트레이드오프*. PR #62 (`mutable-team-policy-no-single-answer`) 결 합류.
+
+### 2. 생성자 vs `invoke` 캐싱 — 클라이언트 입장 어휘 (Thread 4) — 정점
+
+reviewer:
+
+> *"`Card(...)` 라고 씌여있는 코드는 생성자를 부르고 있는 것인지 invoke함수를 부르고 있는 것인지 다른 개발자들이 볼 때, 한 눈에 알아볼 수 있을까요? 저마저도 생성자를 부르고 있다는 착각을해서, 캐싱이 제대로 되고 있는지 의심을 하게 되는 생각까지 닿게 되네요."*
+
+학생 자가 답변 정점:
+
+> *"이 부분에 대해서는 최근 가장 많이 생각해본 **클라이언트의 입장**이라는 것을 녹여봤어요.*
+>
+> *`Card`를 사용하는 클라이언트 입장에서는 생성자를 부르고 있는 것인지, `invoke` 함수를 부르고 있는 것인지 알아볼 필요가 없다고 생각해요.*
+>
+> *`List()` 함수를 사용할 때 해당 리스트를 **어떻게** 만드는지 관심이 없는 것처럼요.*
+>
+> ***캐싱을 제대로 하고 있는 지에 대한 책임은 `Card` 클래스를 만든 사람에게 있다고 생각합니다. 캐싱을 하고 있다는 것이 굳이 함수명에 드러날 필요는 없다고 생각했어요.*** 불필요한 정보라는 생각도 했고, 만약 캐싱 방식이 바뀌거나 사라진다면 의존하는 곳에 영향을 미칠 수 있으니까요."*
+
+→ **MCP 룰 `client-perspective-vocabulary`** ⭐⭐⭐ **신규 정점** — *클라이언트 입장 vs 구현자 입장 어휘 학생 자가 자각*. PR #106 (`student-perspective-shift-self-question`) 결의 *관점 깨기 자각* 진화 어휘.
+
+→ **MCP 룰 `constructor-vs-invoke-encapsulation`** ⭐⭐ 신규 — *생성자 vs `invoke` = 클라이언트 무관심 + 만든 사람 책임 어휘*.
+
+→ ***학습 시간성 진화*** — 1단계 PR #106 *언제 관점 깨는가* 자가 의문 → 2단계 PR #134 *클라이언트 입장* 어휘 정착. **giovannijunseokim 학습 메타 케이스 정점**.
+
+### 3. abstract vs interface — 학생 자가 분류 (Thread 5)
+
+reviewer: *"여기는 다시 abstract가 된 이유가 궁금하네요. abstract 키워드를 적절하게 사용하고 있는지 고민해보세요. interface와 abstract class는 무엇이 다른지에 대해 더 자세한 공부를 해보세요."*
+
+학생 자가 답변:
+
+> *"`interface`는 다중 구현이 가능하고, 객체지향에서의 역할을 의미한다고 생각합니다.*
+>
+> *반면 `abstract class`는 다중 상속이 불가하며, 객체지향에서의 역할을 하나로 제한한다고 생각합니다. 다만 `interface`보다 **더욱 강력한 도구**(`field`를 갖는 프로퍼티 구현, `protected`, `private` 등의 가시성 변경자 사용 가능)이라고 생각합니다.*
+>
+> *때문에 `interface`는 다형성 및 추상화를 위해 사용하고, `Participant`는 다형성보다는 **코드 중복의 개선을 위해 사용**된다고 생각했습니다.*
+>
+> *이 경우 `Player`와 `Dealer`가 `Participant`에 속하는데, 둘은 중복되는 코드가 많습니다. 이를 조합을 통해 개선할 수도 있습니다. 하지만 객체 지향 생활 체조 원칙 7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다. 규칙을 지키기 위해 `abstract class`를 활용해 보았습니다.*
+>
+> ***interface, abstract class에 대해 제가 정확히 이해하고 있는지는 개념을 정리하고 크루들에게 공유하며 검증해보도록 하겠습니다.*** 감사합니다!"*
+
+→ **MCP 룰 `abstract-vs-interface-criteria`** ⭐⭐⭐ **신규** — *interface = 다형성/역할 / abstract = 코드 중복 개선 + 강력 도구 (field, 가시성 변경자) 학생 자가 분류*.
+
+→ **`student-knowledge-validation-via-peer-sharing`** ⭐⭐ — *학생 자가 *크루들 공유로 검증* 어휘 — PR #62 (Slack DM 학습) 결의 *PR 외 학습 채널* 다른 축.
+
+### 4. 상태 패턴 = 타입 캐스팅 X 숨겨진 요구사항 (Thread 6)
+
+reviewer:
+
+> *"상태 패턴을 사용하셨으니, 타입 캐스팅을 사용하지 않고 프로젝트를 구성해보세요. 그것을 상태 패턴으로 해결할 수 있으니까요 :)* ***블랙잭 미션은 타입 캐스팅을 가능한 사용하지 않는 것이 숨겨진 요구사항이랍니다.***"*
+
+→ **MCP 룰 `state-pattern-no-type-casting-hidden-requirement`** ⭐⭐⭐ — PR #154·#42 (`state-pattern-no-if-type-check`)·PR #73 (`is-operator-polymorphism-avoidance`) 결 합류 누적 **4 PR 정점** ⭐⭐⭐ — *블랙잭 미션 숨겨진 요구사항 어휘*.
+
+### 5. `Score` 도메인 룰 책임 위치 (Thread 3)
+
+reviewer:
+
+> *"점수가 단순히 21점이라해서 블랙잭이라고 부를 수 없어요. **점수 객체가 블랙잭 점수 규칙에 대한 관심을 가지는 것이 정말 적절할지 고민**해보세요."*
+
+학생 자가 답변:
+
+> *"`SCORE_BLACKJACK`는 `isBlackjackScore` 내부에서 쓰이고 있기 때문에 여기서 필요하다고 생각할 수 있지만, **실제로는 말리빈이 얘기한 것처럼 `ParticipantState`에서 쓰이는 값입니다.***
+>
+> *때문에 `ParticipantState`에서 계산하거나, `Score`를 활용한 도메인의 특화 모델 `BlackjackScore`에서 계산하는 것이 좋다고 생각됩니다."*
+
+→ **MCP 룰 `score-vs-blackjack-score-locus`** ⭐⭐⭐ 신규 — *Score = 일반 점수 / 블랙잭 룰 = ParticipantState 또는 BlackjackScore 특화*. PR #106 (`rank-vs-score-separation` Rank 게임 무관) 결 합류 → ***도메인 책임 위치 어휘 누적 2 PR***.
+
+### 6. 딜러가 플레이어와 계산 — Player public 노출 자가 발견 (Thread 7)
+
+reviewer:
+
+> *"파라미터 명을 보면 dealer의 것만 계산할 수 있을 것만 같지만, Player와 Player를 계산하는 것도 가능하겠어요. Player와 Player를 비교해 계산하는 것 보다는 딜러가 플레이어와 점수를 계산하는 것이 더 자연스럽다는 생각이 드네요."*
+
+학생 자가 답변:
+
+> *"`betting`에 대해 `player`가 들고 있어서 저런 로직이 나온 것 같아요. 말리빈의 말대로 딜러가 플레이어와 점수를 계산하게 하는 것이 더욱 직관적인 것 같습니다.*
+>
+> ***다만 `dealer`에게 계산의 책임을 넘겨보니 `player`의 베팅 금액을 `public`하게 열어야 하더라구요. 처음부터 `betting`을 플레이어가 갖고 있는 것이 맞는지에 대한 생각도 드네요.***"*
+
+→ **MCP 룰 `responsibility-shift-side-effect-discovery`** ⭐⭐⭐ 신규 — *책임 이전 시 다른 클래스 캡슐화 부작용 자가 발견*. PR #38·#106 결의 *책임 위치 학생 자가 자각* 정점.
+
+### 7. Playing vs Hittable 관계 역전 (Thread 8)
+
+reviewer: *"Playing과 Hittable의 관계가 뒤집혀있단 생각을 지울 수 없네요."*
+
+학생 자가 답변: *"동의합니다. 이제 보니 관계가 역전된 코드 같네요. 😂"*
+
+→ **MCP 룰 `state-hierarchy-inverted-relationship`** ⭐⭐ 신규 — *상태 계층 관계 역전 시그널*.
+
+### 8. 컨트롤러 도메인 로직 분리 (Thread 0)
+
+reviewer:
+
+> *"이 객체는 도메인 객체보다 컨트롤러에 가깝네요. 게임의 룰에 맞춰 게임을 진행하는 로직을 도메인 객체로 분리해보세요. **블랙잭 미션에서 게임의 로직을 분리해내는 것이 가장 핵심이기도 한 미션이니까요!**"*
+
+→ **Controller 어휘 누적 8 PR 정점** = #37·#42·#48·#47·#72·#43·#54·#134.
+
+### 9. 에러 메시지 입력 값 포함 (Thread 1)
+
+reviewer: *"어떤 값이 들어와서 예외가 발생했는지 메세지에 담아보는 건 어떨까요? 어떤 장점이 생길 수 있을까요?"*
+
+학생 자가 답변: *"에러 체크 시 어떤 값이 들어왔는지 확인할 수 있고, 왜 그런 값이 나왔는지 추적하기 훨씬 좋을 것 같아요. 앞으로는 문자열 템플릿을 사용해 에러 메시지에 에러 원인이 된 값을 출력하도록 수정하겠습니다!"*
+
+→ **`error-message-as-inline-string-with-template`** = PR #30 결 합류 누적 2 PR.
+
+### 10. reviewer 학습 시간 부족 미션 마무리 어휘 (Thread review)
+
+reviewer:
+
+> *"2단계 미션 고생 많으셨어요. 다음 원활한 미션 진행을 위해 이번 미션을 이만 마무리 짓도록 할게요. 피드백은 나중에 시간이 남을 때 반영해보세요. **방학 때 처음 부터 다시 만들어보는 것도 큰 도움이 될거예요.**"*
+
+→ **MCP 룰 `reviewer-mission-time-bound-conclusion-vocabulary`** ⭐⭐⭐ 신규 — *학습 시간 한계 → 미션 마무리 + 방학 재구현 권유*. PR #115 (laco-dev *시간 지체 마무리 + 2단계 재시작*) 결 합류 누적 2 PR → ***reviewer 시간 한계 어휘***.
+
+## 대표 인용
+
+> [giovannijunseokim Thread 4]
+> *"클라이언트의 입장이라는 것을 녹여봤어요. `Card`를 사용하는 클라이언트 입장에서는 생성자를 부르고 있는 것인지, `invoke` 함수를 부르고 있는 것인지 알아볼 필요가 없다고 생각해요."*
+
+→ **클라이언트 입장 어휘 학생 자가 정착**.
+
+> [giovannijunseokim Thread 4]
+> *"캐싱을 제대로 하고 있는 지에 대한 책임은 `Card` 클래스를 만든 사람에게 있다고 생각합니다."*
+
+→ **만든 사람 책임 어휘**.
+
+> [giovannijunseokim Thread 5]
+> *"interface, abstract class에 대해 제가 정확히 이해하고 있는지는 개념을 정리하고 크루들에게 공유하며 검증해보도록 하겠습니다."*
+
+→ **학생 자가 peer 검증 어휘**.
+
+> [giovannijunseokim Thread 7]
+> *"다만 `dealer`에게 계산의 책임을 넘겨보니 `player`의 베팅 금액을 `public`하게 열어야 하더라구요. 처음부터 `betting`을 플레이어가 갖고 있는 것이 맞는지에 대한 생각도 드네요."*
+
+→ **책임 이전 시 부작용 자가 발견 어휘**.
+
+> [malibinYun Thread 6]
+> *"블랙잭 미션은 타입 캐스팅을 가능한 사용하지 않는 것이 숨겨진 요구사항이랍니다."*
+
+→ **미션 숨겨진 요구사항 어휘**.
+
+> [malibinYun review]
+> *"방학 때 처음 부터 다시 만들어보는 것도 큰 도움이 될거예요."*
+
+→ **reviewer 학습 시간 한계 + 재구현 권유 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **학생 자가 트레이드오프 도표화 + 결론 명시** — **MCP 룰 `student-self-pros-cons-tabulation` 후보** ⭐⭐⭐ 정점.
+2. **클라이언트 입장 vs 구현자 입장 어휘 학생 자가 자각** — **MCP 룰 `client-perspective-vocabulary` 후보** ⭐⭐⭐ 정점.
+3. **abstract vs interface 학생 자가 분류** — **MCP 룰 `abstract-vs-interface-criteria` 후보** ⭐⭐⭐.
+4. **상태 패턴 = 타입 캐스팅 X 숨겨진 요구사항 누적 4 PR 정점** — **MCP 룰 `state-pattern-no-type-casting-hidden-requirement` 후보** ⭐⭐⭐.
+5. **Score 도메인 룰 책임 위치 (ParticipantState / BlackjackScore 특화)** — **MCP 룰 `score-vs-blackjack-score-locus` 후보** ⭐⭐⭐.
+6. **책임 이전 시 부작용 자가 발견 (Player betting public 노출)** — **MCP 룰 `responsibility-shift-side-effect-discovery` 후보** ⭐⭐⭐.
+7. **reviewer 학습 시간 한계 + 재구현 권유** — **MCP 룰 `reviewer-mission-time-bound-conclusion-vocabulary` 후보** ⭐⭐⭐.
+8. **상태 계층 관계 역전** — **MCP 룰 `state-hierarchy-inverted-relationship` 후보** ⭐⭐.
+9. **PR 본문 1단계 영감 자가 적용 리스트** — **MCP 룰 `pr-body-prior-feedback-applied-list` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **giovannijunseokim 양 단계 완성 (1단계 #106 → 2단계 #134)** — 1단계 *언제 관점 깨는가 자가 의문* (PR #106) → 2단계 *클라이언트 입장* 어휘 정착 + *학생 자가 도표화* + *책임 이전 부작용 자가 발견*. **학습 메타 케이스 — 학생 측 메타 어휘 학습 정점**.
+- **malibinYun reviewer 다년 활동** — 2024 PR #95 + 2025 PR #118·#141·#134 등 다년 reviewer.
+- **메타 케이스 10번째** — *giovannijunseokim 1년 학습 시간성 + 메타 어휘 학생 측 학습 정착*.
+- **Controller 어휘 누적 8 PR** (PR #37·#42·#48·#47·#72·#43·#54·#134) — 누적 정점 강화.
+- **상태 패턴 어휘 누적 4 PR + 타입 캐스팅 X 숨겨진 요구사항 명시** — 정점.