oh-my-oop 0.2.0

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

@@ -0,0 +1,296 @@
+# PR #107 — [블랙잭 1단계] 공백 미션
+
+- **Reviewee:** [@junseo511](https://github.com/junseo511)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/107
+- **단계:** 1단계
+- **리뷰어:** @lee-ji-hoon (지훈/코니)
+- **라인 코멘트:** 25 스레드 — *학생 자가 PR 본문 의문 2개 + 모든 thread 응답 + 양방향 매우 긴 핑퐁 토론 + 학생 자가 GameManager / UserCommand enum / 람다식 리팩토링 자가 도입*
+- **신규 reviewee** (2024 코호트). PR #137 (HamBeomJoon) 와 동일 reviewer. 학습 가시화 최강 사례.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 2개 + 셀프 체크리스트 + 스크린샷** — *"Hand의 외부에서 카드에 접근하지 않고, Hand라는 플레이어가 가진 객체 내에서 본인이 가진 점수와 버스트 여부를 반환하고 있습니다. 저는 오히려 외부에서 의존을 다시 하는 것보다 카드를 받아 저장하고 이러한 상태를 계산하는 역할이 손의 역할이다 라는 생각으로 제작하였는데, 코니의 의견이 궁금합니다!"* + *"결과를 출력하는 함수를 재사용하기 위해서는 플레이어는 이름이 있고, 딜러는 이름이 없는데 컨트롤러나 모델에서 '딜러'라는 텍스트를 가지기 싫어서 View에서 이름이 비어 있으면 '딜러'라는 기본값을 두었습니다. 혹시 코니는 어떤 쪽이 취향이신지 궁금합니다."* + **PR 본문에 게임 진행 스크린샷 첨부**. **PR 본문 학습 가시화 모범**. PR #128·#135·#108·#136·#137·#148·#151·#98·#95·#99·#46·#77·#91 결.
+- **모든 thread 에 학생 자가 답변** — 25 thread 중 22 thread 학생 응답. **학생 자가 학습 가시화 최강 사례**. PR #46 (krrong *반영커밋 URL 첨부*) / PR #43 (chws0508 *4 후보 명시*) / PR #91 (murjune *3 단계 자가 토론*) 결의 *모든 thread 응답 변형*.
+- **양방향 매우 긴 핑퐁 토론 (Hand 책임 + 딜러 이름)** — 핵심 2 thread 각 3-5 회 핑퐁 + 학생 자가 결정 변경 + reviewer 사과 (이름 잘못 부름 *"동전"* 사과). **양방향 토론 모범**.
+- **`UserCommand` enum 자가 도입** — 학생: *"사실 둘 중 하나로 구현해도 괜찮아서 그랬는데요, HIT이나 STAY라는 상태를 명시해주는게 코드를 읽는 입장에서 더 편할 것 같네요!! `enum class UserCommand` 로 반영하겠습니다 🫡"*. **도메인 어휘 (Hit/Stay) enum 도입**. PR #88·#90·#147·#31·#43 의 *Action enum* 결.
+- **`GameManager` 자가 도입** — 학생: *"참가자가 `isDrawable` 하다면 계속해서 드로우 의사를 묻는 `GameManager` 를 두었구요 :)"*. **책임 분배 자가 학습 + 새 협력자 도입**.
+- **`ResultManager` 자가 제안 + reviewer 인정** — 학생: *"딜러가 모든 것을 담당하게 되면 딜러의 역할이 늘어나고, 딜러가 무조건 모든 플레이어를 알아야 하지 않아도 된다는 생각이 들었습니다! ... ResultManager를 객체로 두고 결과를 반환하는 역할을 분리하는 것은 어떻게 생각하시나요?"* + reviewer: *"네 좋습니다. (...) 게임 총 매니저가 있는 것은 또 어떤 구조로 구현이 될까 궁금한데 공백이 한 번 보여주시겠어요 👀"*. **학생 자가 책임 분배 제안 + reviewer 인정** — PR #74 (송핑크 *Referee 자가 토론*) / PR #98 (chaehyuns *Judge 분리*) 결.
+- **`Hit/Stay 능동 어휘` 자가 학습** — 지훈: *"꽤나 능동적으로 행동을 하는 부분인데 이 부분을 이번에 녹여낸다면 어떻게 녹여낼 수 있을까요?"* + 학생 자가 적용. **도메인 능동 어휘 인식**.
+- **`apply` Kotlin scope function 자가 학습** — 학생: *"`수신 객체 람다 내부에서 수신 객체의 함수를 사용하지 않고 수신 객체 자신을 다시 반환 하려는 경우` 에 주로 apply 를 사용한다고 하네요! 평소에 apply랑 also에 크게 신경을 쓰지 않고 사용을 했던 것 같은데 다시 생각해보게 되네요 👍"*. **Kotlin scope function 자가 정의 학습**. PR #93 (junjange *let-run-elvis-pitfall*) / PR #137·#148·#90·#146·#91 의 *Kotlin 어휘 학습* 결.
+- **카지노 4-8 덱 도메인 학생 자가 인용** — 학생: *"단, 블랙잭이라는 도메인에서 이러한 상황을 방지하기 위해 4-8개의 덱을 사용한다고 해요 🤔 따라서 8개의 덱을 캐싱해서 우선 사용하고, 만약 해당 에러가 발생했을 때 던지는 방식이 도메인 측면에서 바라봤을 때 더 좋은 것 같습니다"*. **도메인 학습 + 자가 룰 인용**. PR #58 (otter66 *카지노 6덱*) / PR #26 (chws0508 *여러 덱*) 결.
+- **`확장 함수 `.toText()` 자가 정당화`** — 학생: *"제가 원하는 동작은 날아온 클래스의 정보를 출력해주는 것입니다. `그 클래스가 어떤 것인지 꼭 알아야 하는가?` 보다 `클래스를 출력할 텍스트로 변환한다` 가 더 중요한 부분이라고 생각해서 `.toText()` 만 붙여도 직관적으로 사용할 수 있다고 생각했습니다 👍"*. **확장 함수 의도 자가 명시**. PR #9 (Choisehyeon *확장 함수 4 분면*) 결.
+
+## 못한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 1: `Hand 책임 = score 계산 + bust 판단` 과한가?
+
+PR 본문 학생 자가 의문 + 본인 자가 결정 + reviewer 양방향 토론:
+
+지훈 1차: *"`assertThat(hand.isBust()).isTrue()` 이 지금 Bust를 반환하고 있을까요? 21점이 넘었을 때를 기준으로 생각을 해봤을 때 `isBust` 자체가 `Hand` 의 역할일까요?"*
+
+학생: *"현재 이 로직을 계산기로 옮겨보았습니다!"*
+
+지훈 2차: *"`손`이라는 역할을 생각했을 때 해당 객체가 직접 score를 계산하고 bust인지 까지 판단하는 것은 너무 과하지 않을까요? 지금 Player라는 객체가 하는 일이 아예 없는데 왜 그렇게 됐는지도 고민해 보면 좋을 것 같네요."*
+
+학생 자가 후회: *"저도 작업하면서 조금 과해보여서 이와 같은 질문을 남겼는데, Participant 자체에서 카드 모음을 가지고 있고 Participant가 생성될 때 미리 점수를 계산할 수 있는 계산기를 쥐어줘도 괜찮다는 생각이 들어요"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *Hand vs Participant + Calculator 책임 위치*
+
+- *Hand* = *카드 모음 + 점수 + Bust 판단* (학생 1차 코드) = *과한 책임*.
+- *Participant + Hand + Calculator* (학생 자가 최종 도달) = *카드 모음은 Participant, Hand 제거, 점수 계산은 Calculator*.
+
+PR #77 (murjune *Hand vs Participant 양방향 토론 — 학생 주장 유지*) 와 *반대 결* — *junseo511 학생은 *권고 후 자가 후회 + 책임 재분배***.
+
+#### 1.2. *Player 빈약 = 책임 누수 시그널*
+
+지훈: *"Player 클래스 자체가 너무 빈약해진 느낌이 안 드실까요?"* — *Player 가 *이름만 있는 빈 껍데기* = Hand 가 책임 다 가져감*.
+
+#### 1.3. *책임 재분배 = Participant 가 *카드 모음 + Calculator 협력**
+
+학생 자가 최종 = *Participant 가 카드 + Calculator 협력 / Hand 제거 / Player 가 Participant 상속 + 이름 추가*.
+
+PR #43·#74·#98·#46·#77 의 *Hand vs Participant 책임 토론* 결.
+
+### 2. PR 본문 자가 의문 2: `딜러 이름 = 컨트롤러 vs View 기본값` — 매우 긴 양방향 토론
+
+PR 본문 학생 자가 의문 + 4 단계 핑퐁:
+
+#### 2.1. 학생 의도: *컨트롤러/모델에서 "딜러" 텍스트 가지기 싫어서 View 기본값*
+
+#### 2.2. 지훈 1차: *함수 다중 책임 + 딜러 이름 가능성 + View 수동성 의문*
+
+> *"지금 이 하나의 함수가 여러 가지 일을 하고 있기 때문이 아닐까? 고민을 해보시면 좋습니다. 혹은 딜러는 꼭 이름이 없어야 할까요? 딜러만의 이름이 있을 수도 있고, 아니면 밖에서 현재 상태에 따른 name을 정해줄 수도 있을 것 같네요."*
+
+> *"그런데 이렇게 생각이 흐르게 된 이유는 View가 너무 수동적이라서 그렇게 된 것 같은데요. 아마 Domain Model의 의존을 아예 끊고 싶어서? 아니면 View는 멍청해야 해서? 일 것 같은데요. 근데 이미 `blackjack.model.CardRank` 등 많이 의존을 하고 있는 상태인데, 'View에게 어떠한 상태를 던져주고 그 상태에 따라 UI를 표시해!' 라고 해보는 것도 방법일 것 같은데 시간이 좀 있으니 고민해봅시다"*
+
+#### 2.3. 학생 자가 정당화 (몇 가지 경우의 수 검토 후 자가 결정)
+
+> *"그래서 돌고 돌아 현재는 기본값으로 '딜러'를 가지고 있어도 괜찮지 않을까...!?라는 생각을 했습니다. 플레이어는 기본 생성자로 이름을 가지고 있고, 플레이어와 딜러밖에 없는 상황이라 이름이 없다면 무조건 딜러라는 생각으로 돌아왔어요...! 🤔"*
+
+#### 2.4. 지훈 2차 (유지보수 관점 권유):
+
+> *"현실 세계에서는 딜러도 명찰표로 이름이 존재하는 경우가 충분히 있을 것 같아요. 동전의 의견도 틀린 부분은 없다고는 생각을 하는데 `기본값이 딜러`라는 부분이 살짝 어색하네요.*
+>
+> *동전이 사용할 때는 크게 상관이 없지만 이 프로젝트를 누군가 유지보수 한다고 생각을 해볼까요? '플레이어는 기본 생성자로 이름을 가지고 있고, 플레이어와 딜러밖에 없는 상황이라 이름이 없다면 무조건 딜러라는 생각' 을 자연스럽게 나올까 고민을 해보면 전 아닐 것 같아요. 위 로직을 알기 위해서는 UI Model을 처음부터 뜯어봐야 할 거예요"*
+
+#### 2.5. 학생 자가 결정 변경:
+
+> *"이런 관점에서 바라보면 유지보수를 위해 참가자는 일단 이름을 갖게 하는게 괜찮을 수도 있겠어요!! 일단 컨트롤러에서 딜러를 생성할 때 '딜러'를 명시해주고 추후에 딜러 이름을 별도로 구현하거나 다국어를 지원하는 방향도 괜찮아 보이네요"*
+
+#### 2.6. 지훈 마무리 + 학생 이름 실수 사과:
+
+> *"네 딜러의 이름을 어떻게 보면 UI에 표시하기 위해서 추가를 하는 것인가?라고 생각을 할 수가 있는데요! `참가자`라는 관점에서 봤을 때 각자 이름을 갖고 있는 것은 그리 어색하지는 않은 상황이라서 계속 핑퐁으로 리뷰를 해보았는데요! 잘 판단하신 것 같습니다."*
+>
+> *"죄송합니다,,, 다음 리뷰어 재밌는 리뷰 있길래 구경하다가 제가 정신이 나갔었나 보네요. 다음번에 제가 테크살롱 가게 되면 밥이나 커피라도 사드릴게요!"* (학생 이름 *"동전"* 으로 잘못 부른 것 사과)
+
+→ **6 가지 메타 학습**:
+
+#### 2.1. *유지보수 관점 메타 어휘 (지훈)*
+
+*"누군가 유지보수 한다고 생각을 해볼까요?"* — **MCP 룰 후보 `maintenance-perspective-evaluation`** = *현재 코드 가독성 + 미래 유지보수자 시점*.
+
+#### 2.2. *학생 자가 정당화 → 자가 결정 변경 (5 단계 진화)*
+
+*View 기본값 (1차) → 자가 정당화 (2차) → reviewer 유지보수 관점 (3차) → 자가 후퇴 + Controller 명시 (4차)*. **양방향 토론 모범 + 학생 자가 결정 변경**. PR #46·#43·#91·#77 결.
+
+#### 2.3. *기본값 = 매직 동작 안티패턴*
+
+- *View 가 *"이름 비어있으면 '딜러'"* 매직 변환* = *유지보수자 모르는 동작*.
+- *Controller 가 명시* = *코드 가독성 + 의도 명시*.
+
+**MCP 룰 후보 `magic-default-conversion`** = *기본값으로 도메인 어휘 주입 = 매직 동작*.
+
+#### 2.4. *함수 다중 책임 시그널*
+
+지훈: *"지금 이 하나의 함수가 여러 가지 일을 하고 있기 때문이 아닐까?"* — *과한 책임 → 분리 신호*.
+
+#### 2.5. *View 수동 vs 능동 메타 어휘*
+
+지훈: *"View가 너무 수동적이라서 그렇게 된 것 같은데요. (...) 'View에게 어떠한 상태를 던져주고 그 상태에 따라 UI를 표시해!'"* — **MVP/MVVM 어휘** = *View 가 상태 받고 표시 결정 능동*.
+
+#### 2.6. *reviewer 가 학생 이름 잘못 부름 + 자가 사과*
+
+*"동전"* 으로 잘못 부른 후 자가 사과. **reviewer 자가 사과 + 친밀한 어조**. PR #91·#77·#46·#16·#95·#137 의 *reviewer 자가 사과* 결.
+
+### 3. `abstract class + 기본 구현` = override 불가 학생 자가 정당화
+
+지훈: *"오늘 강의 시간 때 이야기 했던 내용이 기억이 나실까요? `abstract class에 구현을 하면 해당 함수 혹은 변수를 override 할 수 없다.`라는 것을 들으셨을 텐데요. 지금 구현 상태에서 만약 딜러는 `카드를 3장 받고 시작한다.` 라는 룰이 생기게 된다면 어떻게 될 것 같으신가요?"*
+
+학생 자가 정당화: *"카드의 장 수를 선택할 수 있는게 오히려 불필요한 구현이라고 생각했습니다! 블랙잭이라는 도메인에서는 2장을 기본값으로 계산하니까요 :) 추후 바뀌게 된다면 abstract fun으로 두고 draw를 사용할 것 같네요!! 하지만 잘 생기지 않을 것 같은 희박한 상황이라고 생각해서 유지해도 괜찮다고 생각합니다 🧐"*
+
+→ **YAGNI + 도메인 룰 자가 인용**:
+- *학생*: *"잘 생기지 않을 것 같은 희박한 상황"* = **YAGNI** 자가 적용. PR #146 (yrsel YAGNI 자가 인정) / PR #77 (murjune *PointCalculator 분리*) / PR #31 (no1msh *Builder 패턴*) 결.
+- *지훈 권유는 *확장 가능성** — 학생은 *현재 도메인 단순성 우선*.
+
+**`abstract class + 기본 구현 + override 불가`** — **MCP 룰 후보 `concrete-abstract-method-override-impossible`**.
+
+### 4. `private constructor` 망각 + 학생 자가 인정
+
+지훈: *"지금은 아래처럼 호출이 가능할 텐데요. `from`이라는 함수로 `Players` 가 만들어지길 원한 것 같은데요 지금은 아래처럼도 만들 수 있는 상황 같네요🤔"*
+
+```kotlin
+val players1 = Players(listOf(Player("tester")))  // private 우회
+val players2 = Players.from(listOf("tester"))
+```
+
+학생: *"앗 이런! `private constructor` 가 중간에 컴파일 에러를 내버려서 from을 만든건데, 다시 private으로 두는 것을 까먹었네요 😅"*
+
+→ **Factory 패턴 + private constructor + Kotlin 어휘**. PR #46 (krrong *data class private constructor copy 우회*) / PR #58 (otter66) 결.
+
+### 5. `WinningResult` 블랙잭 도메인 룰 미반영
+
+지훈: *"이번엔 블랙잭이라는 도메인을 생각했을 때 이 결과 Class가 가장 의문을 가질 것 같은데요. 블랙잭이라는 도메인이 단순히 `점수의 높고 낮음` 으로 승패가 결정이 되는 게임이 아니라는 것은 이미 아실텐데요! 해당 클래스만 봤을 때 '플레이어1 : 23점 / 딜러 : 19점' 이 상태일때 플레이어1이 승리자인가? 라는 의문이 들 것 같아요."*
+
+→ **블랙잭 룰 = Bust 양측 + BlackJack 2장 1.5배**. PR #26·#46·#16·#23·#66 결. **MCP 룰 후보 `blackjack-rule-fidelity` 강화**.
+
+### 6. `Bust 양측 테스트 위치`
+
+지훈: *"1. 유저1이 버스트가 됐다. 2. 딜러도 버스타가 됐다. 이 상황의 테스트는 어디에 있어야 하고 테스트가 필요하지 않을까요?"*
+
+→ **블랙잭 룰 정확성 테스트 = 도메인 객체 (Player) 책임**. PR #26·#66·#23 결.
+
+### 7. `Controller 메시지 vs 직접 행동`
+
+지훈: *"전반적으로 Controller가 객체에게 메세지를 던지는지 본인이 직접 행동하고 있는지 생각해봅시다."*
+
+학생: *"확실히 지금 controller를 보았을 때 너무 많은 일을 하고 있는 것 같아요! 단순히 딜러에게 첫번째 카드를 내놔! 정도는 도메인에서 필요한 내용이므로 모델 안에 있어도 괜찮을 것 같네요 :) 반영하겠습니다 👍"*
+
+지훈 후속: *"네 좋습니다. `delear는 처음에 2장 중 첫 번째 카드만 보여준다.` 이것은 명백한 비즈니스 로직이고, 그렇다는 것은 테스트에도 유의미한 로직이라는 것을 의미하기도 하겠죠 😀"*
+
+→ **비즈니스 로직 = 테스트 필요 + 도메인 위치**. PR #99·#95·#46·#43·#77·#66 의 *Controller god-object* 결.
+
+### 8. `CardDeck 전체 vs 한 장 받기` 람다식 자가 리팩토링
+
+지훈: *"아마 현실의 블랙잭을 생각하면 1번이 더 자연스러울 거예요 그런데 지금은 CardDeck을 전부 넘겨주고 있는데요. 공백이 생각했을 때 이 부분은 객체지향 관점에서 충분히 넘어갈 수 있는 부분이라고 생각하시나요? 아니면 부자연스럽다고 생각할까요?"*
+
+학생: *"저는 살짝 부자연스럽다고 생각해서 리팩토링 계획에 포함되어 있었는데, 이번에 람다식으로 리팩토링을 진행해서 반영하고자 합니다!! 모든 카드 덱을 플레이어 마음대로 주무를 수 있다? 가 조금 어색하게 느껴져서요!"*
+
+→ **`(Int) -> List<Card>` 람다 의존 vs `CardDeck` 객체 의존** — *Dependency Inversion*. PR #77 (KwonDae *`() -> Card` 람다*) / PR #137·#132·#99·#23 의 *onXX 콜백* 결.
+
+### 9. `isBust` vs `isDrawable` (현실 메타포)
+
+지훈: *"`isBust` 는 너 Bust야? 라고 질문을 하는 것 같은데요. 현실 세계를 기준으로 보면 `'나 더 뽑을 수 있는 상태야'`라고 표현이 되게끔 아직 더 뽑을 수 있다는 것을 표현하는 함수명도 좋아 보이네요!"*
+
+학생: *"hand를 제거하고 계산기를 주입하면서 해당 로직이 조금 바뀌었네요! 현재는 isBust()를 참가자가 직접 반환하고 있습니다! (...) 대신에 드로우를 지속할 수 있는지 확인하는 함수로 `isDrawable` 를 abstract로 두어서 다르게 구현했습니다 ‼️"*
+
+→ **부울 명명 = 긍정 방향 vs 부정 방향**:
+- *`isBust()`* = 부정 (실패 상태).
+- *`isDrawable()`* = 긍정 (가능 상태).
+- *PR #151 (jerry8282 *canHit/isBust 의미 통일 — True 방향*) 결*.
+
+### 10. `firstVisibleCard` List<Card> 유지 vs Card
+
+지훈 suggestion:
+
+```kotlin
+fun firstVisibleCard(): Card = cards.first()
+```
+
+지훈: *"이렇게 하는 게 조금 더 가독성에 좋지 않을까 하고 보니까 `List<Card>` 로 한 이유가 `View에서 표시하기 좋게 하기 위함` 으로 보이는데요 Model 관점에서 봤을 때 View에서 어떻게 표시가 되기 편한지를 고려를 해야 할지 아니면 현재 함수에 맞게끔 하는 게 좋을까요?"*
+
+학생: *"showInitialCards를 abstract로 두면서 List<Card>는 유지되어야 할 것 같아요! 이를 위해 플레이어와 딜러 모두 다른 함수를 가지는 것이 더 부자연스럽다고 생각되어서요. ... 처음 카드를 받고 딜러는 1장을 공개하고 플레이어는 2장을 공개한다."*
+
+→ **Model 의 View 형식 의존 vs 자기 형식**:
+- 학생: *공통 시그니처 = `List<Card>` 유지 (딜러 1장, 플레이어 2장 모두 List)*.
+- 지훈: *Model 이 View 형식 인식 = 결합도*.
+
+**양가성 + 학생 자가 결정**.
+
+### 11. `TEMP` → `DEFAULT_DEALER_NAME` 자가 제안
+
+지훈: *"`TEMP` 보다는 유의미한 의미를 주면 좋을 것 같네요"*
+
+학생: *"가볍게 `DEFAULT_DEALER_NAME` 는 어떠신가요?!"*
+
+→ **상수 명명 의미 명시**. PR #99·#26·#39·#46 vagueName 결.
+
+### 12. `Int / String 원시값 포장`
+
+지훈: *"여기서 Int / String 둘 다 어떠한 값인지 바로 알 수 있을까요? 저희는 원시값을 어떻게 하기로 했었을까요 🤔"*
+
+학생: *"불필요하다고 생각했는데 이렇게 몇줄만 덩그러니 보니까 눈에 안띄네요 🤣 포장해서 반영하겠습니다 👍"*
+
+→ **원시값 포장 요구사항**. PR #16 (SeongHoonC *원시값 포장 자가 의문*) / PR #74·#137·#148·#131·#46 결.
+
+### 13. `테스트 비즈니스 관점 (오류 반환 vs 중복 불가)`
+
+지훈: *"테스트를 하고자 했던 비즈니스적인 관점은 `플레이어 이름은 중복이 될 수 없다.` 였을 것 같은데요. 그런 관점에서 봤을 때 오류를 반환하는 게 주 관심사일까요?"*
+
+학생: *"보다 비즈니스 로직을 명시하는 네이밍이 좋을까요? TDD의 배경이 개발의 문서화인 점을 생각하면 그러한 방향성이 옳을 수 있겠어요 👏"*
+
+→ **테스트 = 명세서 어휘**. PR #26·#46·#99 결.
+
+### 14. `Builder name 필수` 처리
+
+지훈: *"name은 지금 Builder에서 필수로 받아야 하는 값인데요! 만약 이 값이 안 들어온 상태로 build가 행해지면 어떻게 될까요? 이 부분에 대해서 고민해 보면 좋을 것 같네요!"*
+
+→ **Builder 패턴 invariant**. PR #9·#31 결.
+
+### 15. `recieve` 명명 오타
+
+지훈: *"별거 아니지만 `receive` 으로 수정이 되어야 할 것 같네요 😀"*
+
+학생: *"함수명을 고민하다가 통일이 안되었나보네요 😅 반영하겠습니다 ‼️"*
+
+→ **명명 일관성**.
+
+## 리뷰어 의견 요지 (지훈/코니 / lee-ji-hoon)
+
+25 코멘트 특징 (PR #137 와 동일 reviewer):
+
+- **메타 질문 어휘** — *"Hand 의 역할일까요?"*, *"abstract class에 구현을 하면 override 할 수 없다는 것 기억나실까요?"*, *"누가 하고 결과는 어떻게 관리될까요?"* — 학생 자가 답변 유도.
+- **강의 인용** — *"오늘 강의 시간 때 이야기 했던 내용이 기억이 나실까요?"* — **실시간 학습 + 코드 연결**.
+- **현실 메타포 + 객체지향 대비** — *"현실에서는 다 알아야겠지만요 :) 프로그래밍의 세계는 조금 다를 수 있지 않을까요?!"* — *현실 vs 코드 트레이드오프*.
+- **유지보수 관점** — *"누군가 유지보수 한다고 생각을 해볼까요?"* — *시간 두고 관점*. **MCP 룰 후보 `maintenance-perspective-evaluation`**.
+- **장단점 토론** — *"각자 다른 비즈니스 로직을 draw에 묻혀도 되지 않을까?"* — *N 안 + 검토 권유*.
+- **칭찬 분포 균형** — *abstract fun, deck 재사용, 잘 반영* 등 칭찬 5회 + 권고 20회.
+- **reviewer 자가 사과 + 친밀한 어조** — *"동전"* 이름 실수 사과 + 밥 약속.
+- **suggestion 블록 활용** — `firstVisibleCard` 코드 + 명명 제안.
+
+## 대표 인용
+
+> *"`현재 카드를 더 받을지 말지 판단` 하는 것은 `참가자` 가 직접 스스로 판단할 수도 있을 것 같은데요. (...) `isBust` 는 너 Bust야? 라고 질문을 하는 것 같은데요. 현실 세계를 기준으로 보면 `'나 더 뽑을 수 있는 상태야'`라고 표현이 되게끔 아직 더 뽑을 수 있다는 것을 표현하는 함수명도 좋아 보이네요!"* — lee-ji-hoon (Tell-Don't-Ask + 부울 명명 긍정 방향)
+
+> *"동전이 사용할 때는 크게 상관이 없지만 이 프로젝트를 누군가 유지보수 한다고 생각을 해볼까요?"* — lee-ji-hoon (유지보수 관점 메타 어휘)
+
+> *"단순히 딜러에게 첫번째 카드를 내놔! 정도는 도메인에서 필요한 내용이므로 모델 안에 있어도 괜찮을 것 같네요 :) 반영하겠습니다 👍"* — junseo511 (Controller god-object 자가 인정 + 자가 결정)
+
+> *"카드의 장 수를 선택할 수 있는게 오히려 불필요한 구현이라고 생각했습니다! ... 잘 생기지 않을 것 같은 희박한 상황이라고 생각해서 유지해도 괜찮다고 생각합니다 🧐"* — junseo511 (YAGNI 자가 적용 + 자가 결정)
+
+> *"단, 블랙잭이라는 도메인에서 이러한 상황을 방지하기 위해 4-8개의 덱을 사용한다고 해요 🤔 따라서 8개의 덱을 캐싱해서 우선 사용하고, 만약 해당 에러가 발생했을 때 던지는 방식이 도메인 측면에서 바라봤을 때 더 좋은 것 같습니다"* — junseo511 (카지노 도메인 자가 인용 + 자가 결정)
+
+> *"죄송합니다,,, 다음 리뷰어 재밌는 리뷰 있길래 구경하다가 제가 정신이 나갔었나 보네요. 다음번에 제가 테크살롱 가게 되면 밥이나 커피라도 사드릴게요!"* — lee-ji-hoon (학생 이름 실수 사과 + 친밀한 어조)
+
+## 얻은 교훈
+
+1. **`PR 본문 자가 의문 2개 + 셀프 체크리스트 + 스크린샷` = 학습 가시화 최강 사례** — *학생이 *PR 본문에서 모든 학습 의도 + 자가 의문 + 검증 결과* 명시*. PR #128·#135·#108·#136·#137·#148·#151·#98·#95·#99·#46·#77·#91 결의 *PR 본문 자가 의문 풍부 시리즈*.
+
+2. **`모든 thread 응답 패턴`** — 25 thread 중 22 thread 학생 응답 = *학생 자가 학습 가시화 최강 사례*. PR #46 (krrong *반영커밋 URL*) 결의 *thread 단위 응답 변형*.
+
+3. **`5 단계 양방향 핑퐁 토론 + 학생 자가 결정 변경`** — *학생 의도 (1차) → reviewer 질문 → 학생 정당화 → reviewer 유지보수 관점 → 학생 자가 후퇴 + 결정 변경*. PR #46·#43·#91·#77 결의 *양방향 토론 진화*.
+
+4. **`유지보수 관점 메타 어휘 (lee-ji-hoon)`** — *"누군가 유지보수 한다고 생각을 해볼까요?"* — *시간 두고 관점 + 미래 유지보수자*. **MCP 룰 후보 `maintenance-perspective-evaluation`**. PR #95·#98 의 *재구현 권유* 결의 *유지보수 시점*.
+
+5. **`기본값 = 매직 동작 안티패턴`** — *View 가 *"이름 비어있으면 '딜러'"* 매직 변환 = 유지보수자 모르는 동작*. **MCP 룰 후보 `magic-default-conversion`**.
+
+6. **`abstract class + 기본 구현 + override 불가`** — *YAGNI vs 확장 가능성 트레이드오프*. **MCP 룰 후보 `concrete-abstract-method-override-impossible`**. PR #146·#77·#31 의 *YAGNI 자가 인정* 결.
+
+7. **`UserCommand enum + GameManager + ResultManager` 자가 도입 3종 세트** — *Hit/Stay 능동 어휘 enum + 게임 진행 매니저 + 결과 관리 매니저*. **책임 분배 자가 학습 + 새 협력자 도입**. PR #88·#90·#147·#43 의 *Action enum* + PR #74·#98 의 *Judge/Referee 분리* 결.
+
+8. **`apply / also / let / run Kotlin scope function` 자가 정의 학습** — *수신 객체 람다 + 반환값 + 차이*. PR #93·#137·#148·#90·#146·#91 의 *Kotlin 어휘* 결.
+
+9. **`카지노 4-8 덱 도메인 자가 인용 + throw 정당화`** — *학생이 *현실 카지노 룰* 인용 + *자가 throw 정당화*. PR #58·#26·#46 의 *카지노 6덱 메타포* 결의 *학생측 인용*.
+
+10. **`reviewer 자가 사과 + 친밀한 어조`** — *학생 이름 실수 → 사과 + 밥 약속*. PR #91·#77·#46·#16·#95·#137 결의 *친밀한 양방향 어조*.
+
+11. **`함수 다중 책임 시그널 (reviewer 진단 어휘)`** — *"하나의 함수가 여러 가지 일을 하고 있기 때문이 아닐까?"* — *함수 분리 시그널 메타 어휘*.
+
+12. **`View 수동 vs 능동` MVP/MVVM 어휘** — *View 가 상태 받고 표시 결정 능동 = 'View에게 상태 던져주고 UI 표시해!'*. **MCP 룰 후보 `view-passive-vs-active`**.
+
+13. **`isBust vs isDrawable 부울 긍정/부정 방향`** — *PR #151 (jerry8282 *canHit/isBust True 방향 통일*) 결*. *현실 메타포 = `더 뽑을 수 있는 상태`*.
+
+14. **`테스트 = 비즈니스 관점 명세서`** — *"오류 반환이 주 관심사일까요?"* — *테스트 명 = 비즈니스 의도*. **MCP 룰 후보 `test-name-business-perspective`**. PR #26·#46·#99 결.
+
+15. **`강의 인용 reviewer 패턴`** — *"오늘 강의 시간 때 이야기 했던 내용"* — *실시간 학습 + 코드 연결*. **시간 두고 학습 + 코드 연결** 어휘.

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

@@ -0,0 +1,316 @@
+# PR #145 — [블랙잭 2단계] 공백 미션
+
+- **Reviewee:** [@junseo511](https://github.com/junseo511)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/145
+- **단계:** 2단계
+- **리뷰어:** @lee-ji-hoon (코니)
+- **라인 코멘트:** 17 스레드 — *학생 자가 모든 응답 풍부 + 1단계 PR URL 자가 참조 + Manager 객체 도입 자가 반성 + 코드 포맷 자가 토론*
+- **양 단계 분석 reviewee** (1단계 #107 별도). 1단계의 *학습 가시화 최강 사례* 진화.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 1단계 URL 참조 + 변경 요약 + 게임 진행 스크린샷** — *"[이전 PR](https://github.com/woowacourse/kotlin-blackjack/pull/107)에서의 코멘트에 답변 및 반영을 완료했습니다."* + *"기존의 `게임 총괄 관리자` 가 하던 업무를 각 태스크별 관리자로 분리했습니다."* + *"기존에 제거한 Hand 객체를 다시 만들어"* + 베팅 게임 스크린샷. **1단계 자가 참조 + 2단계 변경 요약 명시 모범** — PR #99·#46·#95·#39 결의 *1단계 URL 자가 참조 시리즈* + PR #107 의 *스크린샷 첨부* 진화.
+- **`Map<Name,Money>` → `BettingResult` 변경 자가 정당화** — 코니 메타 질문: *"`Map<Name, Money>` -> `BettingResult` 로 변경이 되었는데요! 이 부분에 대해서는 어떤 의도로 변경이 된 걸까요? 틀렸다는 의미가 아닙니다. 커밋을 둘러보다가 변경이 되었길래 어떤 점을 보고 객체로 변경을 하셨을까 궁금해서 남기는 리뷰입니다."* + 학생: *"- Map이 아닌 다른 변수형으로 바뀌었을 경우에 수정하는 양을 줄이기 위해 / - 좀 더 명시적으로 이것은 무엇이다! 라는 것을 명시하기 위해"*. **2 가지 이유 자가 명시 모범** — *변경 비용 + 명시성*. PR #39 (rhthrhrl0 *PlayersNameAndBet 일급 컬렉션*) 결의 *역방향* (학생측 적극 도입).
+- **`unaryMinus` Kotlin operator 자가 발견** — 코니 *"unaryMinus 이런 게 있는 줄도 몰랐네요 👀"* + 학생: *"저도 몰랐는데 operator fun을 쓸 기회는 이때다 하고 써보려고 찾다보니까 나왔습니다 ㅋ.ㅋㅋㅋ.ㅋㅋ"*. **학생 자가 Kotlin 어휘 탐색 + reviewer 도 인정**. PR #46 (krrong *operator times*) / PR #137·#148·#90·#146·#91 의 *Kotlin 어휘* 결.
+- **`DrawManager` 자가 제거 결정** — 코니 진단: *"`DrawManager` 가 있으면서 어떤 이점이 생겼다고 생겼을까요? 지금 전반적으로 꼭 필요한 Manager인가? 싶은 것들이 있습니다."* + 학생: *"DrawManager를 없애고 Participants 내에서 참가자들이 create되자마자 카드를 받도록 구현하면 어떨까요?? 드로우가 필요하다면 각 참가자에게 드로우를 하도록 위임하구요!"*. **YAGNI 자가 인정 + 책임 위임 자가 도입**. PR #146 (yrsel *YAGNI 자가 인정*) / PR #31 (no1msh *Builder 패턴 불필요*) / PR #146 결.
+- **`이전에 배웠던 내용`** — 코니 *"이전에 배웠던 내용을 잊지 않고 잘 사용해주셨네요 👍"* (ResultCount) — **PR #107 1단계 권고 자가 반영 + 칭찬**.
+- **모든 thread 학생 응답** — 17 thread 모두 학생 답변 = *학습 가시화 최강 사례 (PR #107 와 동일)*. PR #46·#43·#91·#77·#107 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `Hand initialCards` 책임 위치 — 7 단계 핑퐁 토론
+
+코니 1차: *"hand에 `initialCards` 가 있음으로써 어떤 이점이 있다고 생각하실까요? 지금 당장에는 사용되는 곳이 다 테스트 부분 같아 보이는데, 그렇다면 지금 당장에 필요가 없는 구현인데 어떤 의도로 만들었는지를 알고 싶네요. 만약 초기카드를 정해주고 싶은 것이였다면 Hand를 주입해주는 곳에서 넣어줘야 했지 않을까 싶네요."*
+
+학생: *"패(Hand)라는 개념 자체가 카드를 보유한 상태를 의미하므로, 초기 카드를 가질 수 있도록 설계하는 것이 자연스럽다고 생각했습니다! 또한, 매번 넣어주는 것보다 테스트의 용이를 위해 패 안에 미리 카드를 쥐어줄 수 있는 것을 코니는 어떻게 생각하시나요?"*
+
+코니: *"네 초기 카드를 가질 수 있도록 설계를 했으면 첫턴에 바로 Hand에 Card를 넣어 주는 행위가 있으면 납득이 될 것 같았는데요. 지금은 없기에 어떤 의도로 이 객체를 만들었었는지가 궁금했어요 🤔"*
+
+학생: *"아! 이런 방법으로 처음 설계했어도 괜찮았을 것 같아요 :) 저는 카드를 뽑는 행위는 플레이어가 생성되고 나서 한다는 생각을 했어서요...! 현재는 테스트를 목적으로 둔 생성자라고 생각했습니다 🤔 플레이어에서 초기 카드를 생성할 때 받고 넘겨주는게 더 나은 방향일까요??"*
+
+코니 (트레이드오프 명시):
+
+> *"`테스트를 목적으로 둔 생성자가 과연 올바른 걸까?` 라는 것을 고민해 보면 어색하다고 생각이 드네요.*
+>
+> *플레이어가 생성이 될 때 1. Hand는 필수 값이다. 2. 게임에 참여할 때 필수적으로 카드를 2장을 갖는다. 이런 관점으로 봤을 때 그리 어색하지는 않다고 생각합니다. 단 그렇게 됐을 때 카드를 안 받고 시작하는 게임이 추가가 된다고 하면 수정이 생각보다 커질 수도 있게 될 것 같네요. 그래도 미리 받고 한다면 꽤나 코드가 단축이 되는 부분도 있을 것 같으며, 필수적인 요소를 받는 것이 어색하지는 않다고 생각하기에 어느 정도 트레이드오프로 감수할 수 있는 부분..."*
+
+학생: (자가 답변 — 잘림)
+
+코니 (자가 부연 + 자가 의도 명확화):
+
+> *"명확히는 Hand를 생성할 때 카드를 2장을 쥐어주는 것이었습니다 👀*
+>
+> *현실세계로 따지면 참여자들이 `Hand` 를 이미 갖고 있는 상태로 시작을 했겠지만 객체지향의 세계에서는 다르게 구현이 되어있기에 `Hand` 자체가 생성이 될 때 그냥 2장을 갖고 `Particiapnt` 들 에게 가는 건 어떨까요?라는 의미로 남겼던 리뷰입니다.*
+>
+> *객체 설계 자체가 잘못됐다는 느낌은 아니었으며, 제가 의견을 너무 어필해 버리면 그대로 따라갈까 봐 추상적으로 말해서 헷갈렸던 것 같습니다 🤔"*
+
+→ **5 가지 메타 학습**:
+
+#### 1.1. *테스트 목적 생성자 = 안티패턴 시그널*
+
+코니: *"테스트를 목적으로 둔 생성자가 과연 올바른 걸까?"* — **테스트 위해 도입된 생성자/메서드 = 코드 구조 잘못 시그널**. PR #99 (s6m1n *Controller + View 없이?*) / PR #91 (murjune *Test Fixture 진화*) 결.
+
+#### 2.1. *Hand 생성 시 2장 강제 vs 외부 주입*
+
+- (A) **`Hand(initialCards: List<Card>)`** — 학생 코드. *초기 카드 외부 주입 + 빈 Hand 가능*.
+- (B) **`Hand(twoCards: List<Card>)` + 필수 2장 invariant** — 코니 권유. *블랙잭 룰 강제*.
+- (C) **`Hand` 빈 생성 + Participant 생성 시 draw 2장** — 외부 주입.
+
+#### 1.3. *코니의 *"제가 의견을 너무 어필해 버리면 그대로 따라갈까 봐 추상적으로 말해서"** 메타 어휘
+
+**reviewer 가 *학생이 권고를 *맹목적으로 따르지 않도록* 추상화* 의도 명시**. PR #95 (말리빈 *옳고 그름 없고 장단점만*) / PR #43·#46·#91·#23·#26 의 *학생 결정 존중* 결의 *reviewer 의도 메타*.
+
+#### 1.4. *reviewer 자가 의도 명확화*
+
+코니가 *7 단계 토론 후* *"명확히는 Hand를 생성할 때 카드를 2장을 쥐어주는 것"* 자가 명시. **메타 토론의 마지막 명확화**. PR #91·#77·#46·#16·#95·#137 결.
+
+#### 1.5. *학생 자가 *"이런 방법으로 처음 설계했어도 괜찮았을 것 같아요"* — 자가 결정 변경 가능성*
+
+**학생이 권고를 *수용하지 않더라도 *다른 대안 인정* 메타 학습*. PR #107·#46·#43·#91 결.
+
+PR #46·#77·#98·#99·#43·#74 의 *Hand 책임 위치 토론* 결.
+
+### 2. `recieve → drawCards` 명명 + Int 원시값 (1단계 후속)
+
+코니: *"아앗.. 제가 말한 건 `recieve`라는 오타였는데!... `receive` 이 맞지 않나요?!.. 그리고 함수명과 lambda를 통일할 필요는 없습니다. 주로 lambda에는 어떠한 행위가 들어가는지를 자주 표현을 하는 편인데요. 그렇다면 지금 파라미터명을 다시 고민해 보면 좋을 것 같네요 🤔 그리고 `recieveCards: (Int) -> List<Card>` 에서 Int도 원시값이니 바꿔볼까요?"*
+
+학생: *"아니 헐 `receive` 가 맞다네요 😅"* + *"행위 자체는 카드를 뽑는 것이니 `drawCards` 가 적당해 보이는데 어떠신가요?!"* + *"사실 이친구도 눈에 밟히긴 했는데...! Winning을 세는 Count와 겹쳐서 리팩토링 게으름,,, 코니에게 딱 걸려버렸네요 🥲"*
+
+→ **3 가지 학습**:
+
+#### 2.1. *함수명 vs 람다명 분리*
+
+- *함수 (`receive`)* = *수신 측 동작 (받는다)*.
+- *람다 (`drawCards`)* = *공급 측 동작 (뽑는다)*.
+- *동일 람다지만 *호출자 시점* 과 *제공자 시점* 명명 다름*.
+
+#### 2.2. *오타 (recieve) 두 PR 연속 발견*
+
+PR #107 1단계의 *`recieve` 오타 → 명명 일관성 권고* 가 PR #145 에서도 잔존 = *학생 자가 학습 누락*. **MCP 룰 후보 `spelling-consistency`**.
+
+#### 2.3. *Int 원시값 학생 자가 *리팩토링 게으름* 인정*
+
+*"리팩토링 게으름,,, 코니에게 딱 걸려버렸네요"* — **학생 자가 게으름 인정 + 학습 가시화**. PR #46·#107·#91 결.
+
+### 3. `View 가 Domain 객체 직접 생성` 일관성 — MVC 메타 토론
+
+코니: *"`getIsRecieveMore` 은 `UserCommand` 를 직접 만들어서 넣어주고 있는데 `getPlayers` 는 반대로 String으로 회귀를 했네요!.. 공백은 MVC에서 View가 Model을 직접 만드는 것에 대해서 어떻게 생각할까요? 이미 View가 Model을 알고 있기에 만들어줘도 상관 없지 않을까요? 🤔"*
+
+학생: *"Controller에서 해도 괜찮고 View에서 해도 괜찮다는 것이 저의 의견입니다 ‼️ 하지만 일관성은 지켜야겠죠 😅 저는 객체 내의 메서드를 직접 부르는게 아니라면 뷰에서 생성정도는 하는게 개인적으로 더 명시적이고 깔끔해 보이네요 🤔"*
+
+코니: *"네 좋습니다. 둘 다 틀린 말은 아니라고 생각을 해요. 그런데 입력에 의해서 단순 생성만을 위한 것이라면 View에서 해도 되지 않을까?라는 게 제 의견입니다. 추가로 Android를 기준으로 하면 MVC가 정말 애매한 패턴이기에 지금 Android는 잊고 MVC에 대해서만 고민을 해보면 좋을 것 같네요 🤔"*
+
+학생: *"저도 MVC를 한번 더 하게되면 `생성` 이라는 행위를 뷰에 두는 방향으로 해봐야겠어요! 하지만 팩토리 메서드를 할 때에는 컨트롤러나 다른 모델에서 생성하도록 두고요 🤔"*
+
+→ **3 가지 학습**:
+
+#### 3.1. *View 가 Domain 객체 생성 양가성*
+
+- *View 가 입력 → Domain 객체 생성 → Controller 전달* = *입력 변환 응집*.
+- *View 가 String 반환 → Controller 가 Domain 객체 생성* = *View 가 도메인 무관*.
+- **`MCP 룰 후보 `view-domain-object-creation-locus`**.
+
+#### 3.2. *Android vs MVC 분리 어휘*
+
+코니: *"Android를 기준으로 하면 MVC가 정말 애매한 패턴이기에 지금 Android는 잊고 MVC에 대해서만 고민"* — **MVC vs MVP vs MVVM Android 패턴 분리**. PR #91 (murjune *Activity onCreate 경험*) / PR #137·#148 의 *Android 어휘* 결.
+
+#### 3.3. *일관성 자가 명시 + reviewer 인정*
+
+학생의 *"일관성은 지켜야겠죠 😅"* + 학생 자가 결정 변경 (팩토리 메서드는 Controller). **일관성 자가 학습**.
+
+### 4. `Manager` 객체 다중 = 빈약 Model 시그널
+
+코니: *"`WinningManager` 도 동일한 맥락의 리뷰입니다. `Participants`라는 Model이 이미 있으니 참가자들끼리 마지막에 서로의 점수를 알아서 결과를 controller한테 통보하는 형태는 별로였을까요? Controller의 모든 로직을 Manager라는 것으로 빼버리니 너무 빈약한 Model들이 많이 있습니다 🫠"*
+
+학생 자가 책임 재분배 제안: *"1. 그럼 참가자 각각에게 점수에 따라 승패의 상태를 반환하는 메서드를 구현해두고 2. 참가자들 객체에서는 각 참가자들의 정보를 수합해서 3. 컨트롤러에 수합된 정보를 반환하는건 어떨까요?"*
+
+→ **5 가지 학습**:
+
+#### 4.1. *Manager 객체 다중 = 빈약 Model 시그널*
+
+- *DrawManager, WinningManager, ParticipantManager, BettingManager...* — *N 개의 Manager 객체*.
+- *각 Manager 의 책임 = *기존 Model 의 책임* 누수*.
+- *Model 이 *빈약* = 도메인 객체가 *데이터 컨테이너* 로 격하*.
+
+**MCP 룰 후보 `manager-class-proliferation`** = *N 개 Manager 객체 = 책임 분산 부족 시그널*.
+
+#### 4.2. *PR #107 (`UserCommand/GameManager/ResultManager 자가 도입`) 의 *역효과**
+
+PR #107 (1단계) 에서 *학생 자가 도입* 한 *3 Manager + 게임 흐름 응집* 이 *PR #145 (2단계) 에서 *Manager 폭증 안티패턴 으로 전환*. **MCP 룰 후보 `responsibility-extraction-overcorrection`** = *과한 책임 분배 = Model 빈약*.
+
+#### 4.3. *학생 자가 책임 재분배 제안*
+
+3 단계 명시: *참가자 각각 → 참가자들 → 컨트롤러*. **자가 책임 분배 학습 모범**.
+
+#### 4.4. *코니의 *"빈약한 Model들이 많이 있습니다 🫠"* — 비유 어휘*
+
+이모지 *🫠* (얼굴 녹는 이모지) = *학생 자가 후회 + reviewer 친밀한 반응*. PR #46 (말리빈 *🥲*) / PR #107 (코니 *😅*) 결.
+
+#### 4.5. *Controller god-object 의 반대 방향 안티패턴*
+
+PR #99·#95·#28·#78·#112·#125·#147·#43·#77·#46 의 *Controller god-object* = *Controller 가 모든 책임* 안티패턴 + *Manager 폭증* = *책임을 *Manager 객체로 분산* 안티패턴* — **양 극단**.
+
+### 5. `WinningState ↔ Dealer 의존도 단방향` 자가 학습
+
+코니: *"WinningState 객체가 간접적으로 Dealer에 의존을 하고 있는 상태인데요. Dealer를 의식해서 만들어진 함수인데, 이 함수가 여기 있는 것이 맞을지 아니면 어딘가 로직이 꼬여서 만들어진 것으로 보이는데, 다시 생각해봐 주셨으면 좋겠어요."*
+
+학생: *"이건 확실히 안되겠네요...! 의존도를 최대한 단방향으로 하고자 했는데 안된 부분이 있었군요 🥲"*
+
+→ **간접 의존 = 도메인 객체 의식한 함수 시그널**. *WinningState (결과 객체) 가 Dealer (참가자) 의식 = 책임 분리 X*. PR #93 (junjange *bidirectional-dependency*) / PR #74 (송핑크 *양방향 의존*) 결.
+
+### 6. `payMoney` 명명 + 반환값 모호
+
+코니: *"`payMoney` 라는 이름을 생각해보면 단순히 `pay` 만 할 것이라고 보여서 반환을 안 할 것처럼 보이는데 함수 내부에서는 반환도 하고 있네요. 그리고 사용하는 곳에서 기존 money를 다시 반환하고 있네요."*
+
+→ **함수명 = 동작 + 반환값 일관성**. PR #99·#9·#39 결의 *명명 정확성* 결.
+
+### 7. `정상적으로` 추상 단어 — 테스트명 명세서 어휘
+
+코니 1차: *"`정상적으로 생성이 되면`이라는 뜻은 무엇이고 어떠한 것을 테스트하려고 했던 것인지 함수명만 보면 expect가 예상이 갈까요? 🤔"*
+
+코니 2차: *"저는 그냥 `정상적` 단어 자체가 빠지고 명확히 어떠한 상태가 될 것이다. 를 명시하기를 바랐습니다. 누군가한테는 name이 빈 상태도 정상적인 상태 라고 볼 수도 있지 않을까요?"*
+
+코니 3차 (BettingManagerTest): *"`정상적인 배팅금액 정상적으로 진행` 여기서 `정상적인`이 무엇을 의미할까요 🤔 테스트 코드에는 최대한 추상적인 의미를 지양해봅시다"*
+
+→ **테스트명 추상 단어 회피** = *"정상적", "옳은", "일반적인"*. PR #26·#46·#99·#107·#9 결의 *테스트 = 명세서* 어휘 강화.
+
+### 8. `unaryMinus` 테스트 무의미 자가 인정
+
+코니: *"이건 `unaryMinus` 가 구현이 되어있는지 안되어있는지를 보는 테스트의 느낌이네요. 유의미한 테스트인가? 그리그 비즈니스적인 로직인가? 하면 저는 잘 모르겠네요. `Money 객체에 - 기호를 붙이면 음수가 된다.` 이것은 `unaryMinus` 에서 이미 검증이 되어있는 API를 단순히 사용을 했기 때문인데요. `unaryMinus` 가 없었다면 이미 run 자체가 터졌을 것이기도 하고요."*
+
+학생: *"비즈니스 로직이 아닌 코틀린의 operator fun을 테스트하는 것은 확실히 무의미하다고 생각되네요! study test라면 모를까요 :) 이 테스트는 지우겠습니다!!"*
+
+→ **테스트 = 비즈니스 로직 + 도메인 룰 검증**. *Kotlin 표준 API 테스트 = 무의미 (이미 컴파일러 검증)*. **MCP 룰 후보 `meaningless-stdlib-test`**.
+
+### 9. `WinningResult.dealerResult` 미사용 + value class
+
+코니: *"변경이 된 부분은 확인을 했습니다. 단 value class를 써야 했던 이유와 `dealerResult` 는 아예 사용이 안 되고 있는데 `WinningResult`가 필요했던 이유가 있었을까? 싶긴 하네요. 그리고 지금의 출력은 `이름 : 수익` 이기에 PlayerResult랑 DelaerResult랑 달라야 할 이유도 없을 것 같아요."*
+
+학생: *"2단계 구현사항을 생각해보면 전반적으로 불필요한 객체들 같네요!! 계산에 필요한 PlayersWinningResult만 제외하고 삭제하도록 하겠습니다 :)"*
+
+→ **불필요 객체 자가 인정 + 제거 결정**. **YAGNI 강화**. PR #146·#31·#146 결.
+
+### 10. `BLACKJACK` 우선 vs `BUST` 우선 — 학생 자가 트레이드오프 인정
+
+코니: *"`플레이어 vs 딜러` 의 결과를 만들고 있는데요! 이때 `BLACKJACK` 인지 먼저 체크하는 것보다는 본인이 `BUST` 인지 판단하는게 논리적으로나 코드적으로 좀 더 좋지 않았을까 싶어요! 예를 들어서 플레이어가 BUST인 상황에서도 계속 DEALER의 handState가 어떤지 확인하고 있으니까요!"*
+
+학생: *"앗 저도 초기에 로직을 구성할 때 이 부분에서 똑같은 고민이 들었는데요...! 블랙잭이 2장 기준 21점이라 좀 더 명확하게 걸러질 것 같다는 생각이 들고, 그렇게 두었을 때 코드 모양이 계단식으로 내려가서 조금 더 예쁘다는(?) 생각이 들었어요!! 근데 코니의 방향도 논리적으로 합당하고 좋은 것 같아서 빠른 반영 진행하겠습니다 👍"*
+
+→ **3 가지 학습**:
+
+#### 10.1. *분기 순서 = 단락 평가 효율 + 도메인 의미*
+
+- *BLACKJACK 우선* = *2장 21점 빠른 필터 (학생 의도)*.
+- *BUST 우선* = *플레이어 자기 패배 우선 (코니 의도)*.
+
+#### 10.2. *코드 모양 (계단식) vs 논리 우선순위*
+
+학생의 *"계단식으로 내려가서 조금 더 예쁘다"* — *미적 vs 논리*. **양가성**.
+
+#### 10.3. *학생 자가 양가성 인정 + 빠른 반영*
+
+*"코니의 방향도 논리적으로 합당하고 좋은 것 같아서 빠른 반영 진행하겠습니다"* — **양가성 인정 + 자가 결정 변경**.
+
+### 11. `코드 포맷 (abstract val / val / abstract fun / fun)` 자가 토론
+
+코니: *"코드 포맷도 조금 더 신경을 쓰면 좋을 것 같네요. 1. abstract val 2. val 3. abstract fun 4. fun 이 형태로 정리가 된다면 더 깔끔할 것 같네요 👀"*
+
+학생: *"앗 추상 변수가 아래쪽으로 와버렸네요! override, operator, abstract, 일반 순으로 두면 괜찮을까요?!"*
+
+코니: *"네 좋습니다. 사실 저 구조가 공식문서에 있는 포맷팅이 아니긴 한데요. 단지 공백이 코드를 정리한 구조를 봤을 때 저렇게 되는 게 조금 더 가독성이 좋아 보인다고 느껴져서 제안을 드렸습니다 👀"*
+
+학생 자가 의문 + top-down 정리: (백킹 프로퍼티 위치 + cards/hand 의존 순서 자가 토론)
+
+코니 top-down 정리:
+
+```kotlin
+fun main() { foo1() }
+fun foo1() { foo2(); foo3() }
+fun foo2() { ... }
+fun foo3() { ... }
+```
+
+> *"`top-down` 형식으로 봤을 때 `foo1` 이 먼저 다음 `foo2` `foo3` 이런 순서로 위에서부터 읽히기에 순서대로 읽히게끔 하는 것을 좋아하기에 공백이 말한 `cards가 hand를 사용하니까 hand 위에 들어와...`"*
+
+→ **3 가지 메타 학습**:
+
+#### 11.1. *공식 문서 vs 개인 선호*
+
+코니: *"공식문서에 있는 포맷팅이 아니긴 한데요"* — *공식 컨벤션 + 개인 가독성 선호 양립*.
+
+#### 11.2. *top-down vs bottom-up 코드 읽기 순서*
+
+- *top-down*: 진입점 → 호출되는 함수 순서.
+- *bottom-up*: 의존 객체 → 사용 객체 순서.
+- *학생 자가 의문*: *백킹 프로퍼티 위치 (money 아래 _money?) / cards (hand 사용) 위치*.
+
+#### 11.3. *코드 포맷 = 가독성 자가 토론*
+
+**MCP 룰 후보 `code-format-readability-convention`** = *개인 선호 + 컨벤션 + top-down*. PR #46·#107 결.
+
+### 12. `winningState 테스트 부재 + 논리 우선순위 (놓친 부분)`
+
+코니: *"winningState에 대한 테스트도 추가를 해보면 좋을 것 같습니다. 지금 놓친 케이스가 존재하고 있습니다."*
+
+학생: *"테스트를 추가했는데 찾지 못했습니다 🥲 혹시 어떤건지 알 수 있을까요...?"*
+
+코니 자가 부연: *"명확히는 놓친 부분이라기 보단 논리적으로 아쉬운 부분이 좀 더 맞았겠네요!"*
+
+→ **reviewer 자가 부연 + 의도 명확화**. PR #16 (BeokBeok *"제가 설명이 조금 부족한 것 같네요"*) / PR #91·#77·#46·#95·#137 결.
+
+## 리뷰어 의견 요지 (코니 / lee-ji-hoon)
+
+17 코멘트 특징 (PR #107 와 동일 reviewer):
+
+- **메타 질문 어휘** — *"어떤 이점이 있다고 생각하실까요?"*, *"어떤 의도로 변경이 된 걸까요?"*, *"누가 한 번 천천히 고민을 해봐줬으면 좋겠어요"* — 학생 자가 답변 유도.
+- **`reviewer 의도 메타 (추상화 의도)`** — *"제가 의견을 너무 어필해 버리면 그대로 따라갈까 봐 추상적으로 말해서 헷갈렸던 것 같습니다"* — **MCP 핵심 가치 (학생 자가 결정 + reviewer 영향 차단) 와 일치**. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) / PR #43·#46·#23·#26 결.
+- **공식 문서 + 개인 선호 분리** — *"공식문서에 있는 포맷팅이 아니긴 한데요"* — *컨벤션 vs 개인 의견 메타 어휘*.
+- **자가 부연 + 의도 명확화** — *"명확히는 ~ 보단 ~ 가 좀 더 맞았겠네요!"* 다수. PR #91·#77·#46·#95·#137·#16 결.
+- **친밀한 이모지** — *🫠* (얼굴 녹는), *🤔*, *👀*, *😅* — **친밀한 어조**.
+- **`이전에 배웠던 내용`** 등 *1단계 PR 자가 참조*. PR #137·#46·#99 결.
+
+## 대표 인용
+
+> *"객체 설계 자체가 잘못됐다는 느낌은 아니었으며, 제가 의견을 너무 어필해 버리면 그대로 따라갈까 봐 추상적으로 말해서 헷갈렸던 것 같습니다 🤔"* — lee-ji-hoon (reviewer 의도 메타 어휘)
+
+> *"Controller의 모든 로직을 Manager라는 것으로 빼버리니 너무 빈약한 Model들이 많이 있습니다 🫠"* — lee-ji-hoon (Manager 폭증 = 빈약 Model)
+
+> *"테스트를 목적으로 둔 생성자가 과연 올바른 걸까?"* — lee-ji-hoon (테스트 위해 도입된 코드 = 안티패턴 시그널)
+
+> *"비즈니스 로직이 아닌 코틀린의 operator fun을 테스트하는 것은 확실히 무의미하다고 생각되네요! study test라면 모를까요 :)"* — junseo511 (테스트 = 비즈니스 로직 자가 인정)
+
+> *"리팩토링 게으름,,, 코니에게 딱 걸려버렸네요 🥲"* — junseo511 (학생 자가 게으름 인정 + 친밀한 어조)
+
+> *"의존도를 최대한 단방향으로 하고자 했는데 안된 부분이 있었군요 🥲"* — junseo511 (간접 의존 자가 인정)
+
+> *"DrawManager를 없애고 Participants 내에서 참가자들이 create되자마자 카드를 받도록 구현하면 어떨까요?? 드로우가 필요하다면 각 참가자에게 드로우를 하도록 위임하구요!"* — junseo511 (YAGNI 자가 인정 + 책임 위임 자가 도입)
+
+## 얻은 교훈
+
+1. **`Manager 객체 다중 = 빈약 Model 시그널`** — *DrawManager, WinningManager, ParticipantManager, BettingManager 4 개 폭증 = 책임 분산 과한 + Model 빈약*. **MCP 룰 후보 `manager-class-proliferation`**. PR #107 (1단계 자가 도입) → PR #145 (2단계 안티패턴 전환) **`responsibility-extraction-overcorrection`**.
+
+2. **`테스트 목적 생성자 = 안티패턴 시그널`** — *"테스트를 위해 도입된 생성자/메서드 = 코드 구조 잘못 시그널"*. PR #99·#91 결.
+
+3. **`reviewer 의도 메타 (추상화 의도)`** — *"의견을 너무 어필해 버리면 그대로 따라갈까 봐 추상적으로 말해서"* — **MCP `oh-my-oop` 핵심 가치 (학생 자가 결정 + reviewer 영향 차단) 와 일치**. PR #95·#43·#46·#23·#26 결.
+
+4. **`함수명 vs 람다명 분리`** — *함수 = 수신 측 동작 / 람다 = 공급 측 동작*. **MCP 룰 후보 `function-vs-lambda-naming-perspective`**.
+
+5. **`unaryMinus` Kotlin operator 자가 발견** — *학생 자가 Kotlin 어휘 탐색 + reviewer 도 인정*. PR #46·#137·#148·#90·#146·#91 결.
+
+6. **`Map → Domain 객체 변환` 2 이유** — *(1) 변경 비용 (Map 형변경 시 N곳 수정) + (2) 명시성 (이것은 무엇이다)*. **MCP 룰 후보 `map-to-domain-object-migration`**. PR #39 (rhthrhrl0 *일급 컬렉션 과적용*) 결의 *역방향*.
+
+7. **`View 가 Domain 객체 생성 양가성`** — *View 가 입력 → Domain 변환 응집* vs *View 가 String → Controller Domain 변환*. **MCP 룰 후보 `view-domain-object-creation-locus`**.
+
+8. **`Kotlin operator fun 테스트 = 무의미`** — *컴파일러 검증 + 비즈니스 로직 X*. **MCP 룰 후보 `meaningless-stdlib-test`**.
+
+9. **`테스트명 추상 단어 회피` (정상적/옳은/일반적인)** — *"누군가한테는 name이 빈 상태도 정상적인 상태 라고 볼 수도"*. PR #26·#46·#99·#107·#9 결.
+
+10. **`분기 순서 = 단락 평가 + 도메인 의미` 양가성** — *BLACKJACK 우선 (학생 미적/필터 효율) vs BUST 우선 (코니 논리)* — **MCP 룰 후보 `branch-order-readability-vs-logic`**.
+
+11. **`코드 포맷 (abstract val / val / abstract fun / fun)` 가독성 토론** — *공식 문서 vs 개인 선호 + top-down 읽기 순서*. **MCP 룰 후보 `code-format-readability-convention`**.
+
+12. **`PR 본문 1단계 URL 자가 참조 + 변경 요약 + 스크린샷` = 학습 가시화 최강 모범** — *PR #107 의 학습 가시화 진화*. PR #99·#46·#95·#39 결.
+
+13. **`친밀한 이모지 어조`** — *🫠, 🥲, 🤔, 👀, 😅* — *학생/reviewer 양측 친밀한 어조 + 자가 인정 양립*. PR #46·#107·#91 결.
+
+14. **`학생 자가 게으름 인정`** — *"리팩토링 게으름,,, 딱 걸려버렸네요"* — **학생 자가 학습 가시화 + 친밀한 어조**.