oh-my-oop 0.2.0

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

@@ -0,0 +1,219 @@
+# PR #150 — [블랙잭 2단계] 페토 미션
+
+- **Reviewee:** [@chanho0908](https://github.com/chanho0908) (페토) — 2025 모바일 안드로이드 7기 코호트
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/150
+- **단계:** 2단계
+- **리뷰어:** [@lee-ji-hoon](https://github.com/lee-ji-hoon) (지훈)
+- **라인 코멘트:** 8 스레드 — *PR 본문 응집도/확장성 학생 자가 학습 명시 + 학생 자가 SOLID (DIP/OCP/SRP) 위반 자가 자각 정점 + 우발적 중복 vs 진짜 중복 로버트 마틴 인용 학생 자가 + DM 활발 학습 + reviewer 학생 열정 인정 어휘 + 기능 명세서 우선 습관*
+- **chanho0908 양 단계 완성** (1단계 #123).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 응집도/확장성 학생 자가 학습 명시
+
+PR 본문:
+
+> *"2단계에서 저는 **응집도와 확장성**에 초점을 두었습니다. 기존 클래스에 파라미터를 수정한다던가 같은 과정에 있어서 얼마나 **기존 코드를 수정하지 않고 확장할 수 있을가**에 대해 고민해봤어요!"*
+
+→ **MCP 룰 `pr-body-student-design-focus-explicit`** ⭐⭐ 신규 — *학생 자가 설계 초점 (응집도/확장성) PR 본문 명시*. PR #134·#154 결 합류.
+
+### 2. sealed class 자가 선택 (Thread 0)
+
+학생: *"When절에서 Class Type 분기를 위해 sealed class로 수정했습니다!"*
+
+→ **sealed class** = 누적 다수.
+
+### 3. 우발적 중복 vs 진짜 중복 — 로버트 마틴 인용 학생 자가 자각 (Thread 7) — 정점
+
+학생 자가 답변 정점:
+
+> *"앞선 리뷰를 고민하면서 각 참여자의 계산 로직은 스스로 가지도록 수정했습니다. 하지만 when 절의 `isBust() && other.isBust() -> WIN` 을 제외하곤 딜러와 플레이어의 계산 로직이 동일한 로직을 타고 있습니다.*
+>
+> *때문에, 공통된 부분만 추출해 추상 클래스에 위치 시킬지 중복을 허용할지 고민했습니다.*
+>
+> ***저는 이 코드가 과연 정말 중복일까? 에 대해서 고민했어요!***
+>
+> *새로운 플레이어가 생길 가능성이 존재할 때 단순히 같은 코드라고 해서 무조건 추상 클래스에 위치시키는게 맞을까??*
+>
+> *이런 고민을 하게 되었는데요, 다음 두 가지 이유로 추상 클래스에 분리하지 않기로 결정했습니다.*
+>
+> *+ 코드가 중복된다는 이유로 계산 로직이 분리되면 추후 유지보수와 복잡성이 늘어날 것이라고 생각했습니다.*
+> *+ 여기서 제가 생각하는 중복은 **로버트 마틴이 주장한 \"우발적 중복\"** 에 해당한다고 생각합니다. 지금은 코드가 중복된 것 처럼 보이지만 추후 새로운 타입의 플레이어가 생겨난다면 분명 현재 로직에서 서로 다른 방향으로의 수정되는 부분들이 일어날 것이라고 생각해요!"*
+
+reviewer 인정:
+
+> *"네 좋습니다.*
+>
+> ***무조건적으로 중복이 된다는 이유로 억지로 합쳐졌던 느낌이 없지 않아 있었긴 합니다.** 말씀대로 이전의 방법대로 한다면 추가적인 참여자가 생기게 되었을 때 `Participant` 의 compare 부분에 로직이 점점 불어나게 되어버리죠.*
+>
+> *그러면서 인터페이스가 실제 구현체를 알게 되는 기이한 코드가 되어버리기에 **페토의 의견대로 진행하는 것이 좋아 보이네요** 👍*
+>
+> *> 아니면 진짜 중복인 로직만 몰아서 구현을 해두고 각 구현체에서 `super.compare(other)` 를 호출하는 것도 하나의 방법으로 보이네요!"*
+
+→ **MCP 룰 `accidental-vs-essential-duplication-distinction`** ⭐⭐⭐ **신규 정점** — *우발적 중복 vs 진짜 중복 학생 자가 자각*. PR #134 (`student-self-pros-cons-tabulation`)·PR #54 (`unnecessary-indirect-call` vs PR #72 `forward-compatible-delegation`) 결의 *트레이드오프 판단* 다른 축 — *학생 자가 깊은 판단 정점*.
+
+→ **MCP 룰 `student-cites-robert-martin`** ⭐⭐⭐ **신규** — *학생 자가 로버트 마틴 우발적 중복 인용*. PR #154 (조영호 도서)·PR #151 (객체 지향 생활 체조 원칙)·PR #136 (엘레강트 오브젝트) 결 합류 누적 4 PR → ***학생 자가 외부 권위 인용 학습 어휘 정점***.
+
+## 못한 점 (설계 관점)
+
+### 1. 학생 자가 SOLID (DIP/OCP/SRP) 위반 자가 자각 (Thread 1) — 정점
+
+학생 자가 정점 (1단계 결정 + 2단계 reviewer 대화로 자가 자각):
+
+> *"1단계에서 승패 계산 함수의 위치에 대해 고민한 결과 저는 추상 클래스에 위치시키기로 결정했어요!*
+>
+> *플레이어나 딜러에 위치시지 않은 가장 결정적인 이유는 **추상 클래스를 구현하고 있는 구현체들이 서로의 존재를 모르게 하고 싶었습니다.***
+>
+> *크루들과 해당 내용에 대해서 많이 논의를 하면서 현실 세계를 떠올렸을 때 게임 결과를 딜러가 계산하는 것 처럼 딜러가 플레이어를 알아도 된다는 의견이 있었습니다. 물론 맞는 의견이지만 **객체지향 관점에선 조금 다르게 표현해도 된다고 생각**했어요!*
+>
+> *또한 같은 추상 클래스를 구현하는 구현체들이 직접적으로 의존하도록 허용한다면 **이런 것들이 하나 하나 쌓여 추후 의존성 그래프를 그려봤을 때 복잡도가 굉장히 높아질 것**이라고 생각했습니다."*
+
+reviewer:
+
+> *"네 그러면 반대로 `Participant` 가 실제 구현체들을 알게 되는 상황인데요. 지금 이 구조에서 만약 **모듈화를 해서 실제 구현체는 다른 모듈에 있게 될 수도** 있습니다.*
+>
+> *그리고 `VIPPlayer`라는 새로운 Player가 추가가 되었을 때 compare 자체도 수정이 되어야 하는 상황이 올 수도 있죠.*
+>
+> *이런 상황에서는 아래와 같은 방법이 있을 것 같네요*
+> *1. compare에서 Player인지 Dealer인지 모르게 한다.*
+> *2. 각 실제 구현체에서 compare를 한다."*
+
+학생 자가 답변 정점 (SOLID 자가 자각):
+
+> *"> Participant 가 실제 구현체들을 알게 되는 상황*
+>
+> *이 부분은 제가 놓치고 있었네요! 🙁 when절에서 분기하기 때문에 알게 된 것 같아요. 그럼 말씀해주신 것 처럼 새로운 Player가 추가 되었을 때 계속해서 when절에 코드가 늘어나고 점점 비대해질 것 같습니다.*
+>
+> ***이 경우 저는 추상화에 의존하는줄 알았지만 사실은 구현체에 의존하고 있었고 DIP를 위배하는 것 같습니다***
+>
+> *또한 말씀해주신 모듈화 관점에서도 생각해봤을 때 추상 클래스가 domain 모듈에 위치하고 구현체들이 피쳐별로 나뉘어진다면 추상 클래스들이 구현체를 알지 못하기 때문에 동작할 수 없는 코드가 될 것 같습니다.*
+>
+> ***그리고 이런 행위는 OCP도 위반하는 행위라고 생각합니다!***
+>
+> ***플레이어가 각자의 계산 로직을 독립적으로 가져야 새로운 Player가 추가되도 Participant에는 영향을 주지 않고 새로운 Player에 기능들을 구현함으로써 SRP를 준수**할 수 있다고 생각해요!*
+>
+> ***나열하고 보니 아주 아주 못난이 코드였네요*** 😅"*
+
+→ **MCP 룰 `student-SOLID-violation-self-realization`** ⭐⭐⭐ **신규 정점** — *학생 자가 DIP/OCP/SRP 위반 동시 자가 자각 + 자조 어휘 (못난이 코드)*. PR #62·#106 (학생 자가 *마음에 걸린다*·*깊은 생각 없었음*) 결의 *학생 자가 자각* 다른 축 — ***학생 SOLID 인용 자가 자각 어휘 정점*** ⭐⭐⭐.
+
+→ **MCP 룰 `abstract-class-knowing-concretes-anti-pattern`** ⭐⭐⭐ **신규** — *추상 클래스가 구현체 안다 = DIP 위반 + 모듈화 시 컴파일 불가*. PR #154 (`rule-as-god-object-anti-pattern`) 결 합류 — *god-object 변형 어휘*.
+
+→ **MCP 룰 `polymorphism-vs-when-branch-on-concrete`** ⭐⭐⭐ — *when 분기 = 구현체 의존 / 다형성으로 해결*. PR #154·#97·#42 (`state-pattern-no-if-type-check`) 결 합류 누적 6 PR.
+
+### 2. UiModel 인터페이스 의미 퇴색 자가 자각 (Thread 5)
+
+reviewer:
+
+> *"UiModel이 만들어졌군요. 어떤 이유로 만들어졌는지가 궁금한데. UiModel의 이름만 봤을 때는 왜 profit만 존재하는지 그리고 이것을 왜 interfac로 만들었는지는 이유를 모르겠네요. 어떤 의도일까요?"*
+
+학생 자가 답변:
+
+> *"UI에 출력될 플레이어의 이름과 수익률을 묶기 위해 만들었습니다.*
+>
+> *인터페이스는 수익률에 관한 상태를 오버라이드 하려고 사용했는데 다소 불필요했던 것 같습니다 ㅎ_ㅎ,,,,*
+>
+> ***OutPutView에서 인터페이스 타입으로 받는 것도 아닌지라 인터페이스를 분리한 의미가 퇴색된 것 같습니다***
+>
+> *요부분 다시 정신차리고 수정하겠습니다!"*
+
+→ **MCP 룰 `interface-without-polymorphism-purpose-loss`** ⭐⭐⭐ **신규** — *인터페이스 분리 = 다형성 X + 타입 수신 X = 의미 퇴색 학생 자가 자각*. PR #80 (`unnecessary-abstraction-without-polymorphism`)·PR #134 (`abstract-vs-interface-criteria`) 결 합류 누적 3 PR.
+
+### 3. 컨트롤러 vs 게임 vs 플레이어 책임 (Thread 4)
+
+reviewer:
+
+> *"이 로직은 Controller가 어울렸을까요? 아니면 블랙잭 게임? 아니면 플레이어가 직접 profit을 들고 있었을 수도 있을 것 같아요. **적절하게 메세지를 던지거나 역할을 부여를 해봅시다.**"*
+
+학생 자가 답변: *"저도 이 부분이 컨트롤러의 역할로써 적합한지 고민했었는데 (...) 컨트롤러의 역할로써 적합하지 않다고 생각이 들어 수정하겠슴니다!"*
+
+→ **Controller 어휘 누적 9 PR** = PR #37·#42·#48·#47·#72·#43·#54·#134·#150.
+
+### 4. `operator fun times` BettingAmount (Thread 3)
+
+reviewer: *"`operator fun times` 를 잘 활용해 보면 더 좋을 것 같네요 👀"*
+
+→ **`operator-overload-times-domain`** = PR #37·#47 결 합류 누적 3 PR.
+
+### 5. 딜러 손해 0원 버그 + 스크린샷 (Thread 6)
+
+학생 자가:
+
+> *"딜러의 손해 금액이 0원으로 고정되는 문제가 발생해 기존 로직을 수정했습니다!"* (스크린샷 첨부)
+
+→ **`student-bug-discovery-with-screenshot`** ⭐⭐ — *학생 자가 버그 발견 + 스크린샷 첨부*. PR #38 (reviewer 스크린샷)·PR #144 결의 *스크린샷 어휘* 다른 축 — *학생 자가 첨부 어휘*.
+
+### 6. 이름 변경 자가 의견 묻기 (Thread 2)
+
+학생: *"이름을 조금 바꿔봤는데 어떨가요 ㅎㅎ..?"*
+
+→ **`student-self-proposal-naming-inquiry`** ⭐ — 학생 자가 명명 의견 묻기 어휘.
+
+### 7. reviewer 기능 명세서 우선 습관 권장 (review 첫번째)
+
+reviewer:
+
+> *"단! 앞으로는 꼭 기능 명세서를 작성을 하고, 어떻게 변경을 할지 미리 꼭 적어두고 하는 습관을 해보시길 바랍니다."*
+
+→ **MCP 룰 `feature-spec-before-impl-habit-vocabulary`** ⭐⭐ **신규** — *기능 명세서 작성 우선 습관 어휘*. PR #115·#154 (셀프 체크리스트) 결 합류.
+
+### 8. reviewer 마무리 — 학생 열정 인정
+
+reviewer:
+
+> *"페토가 정말 열정적이어서 저도 어떻게 하면 조금이라도 더 만족스러운 블랙잭 미션을 할 수 있을까 고민이 되어서 이것저것 많이 질문을 하고 리뷰를 남겼던 것 같네요.*
+>
+> *앞으로의 미션이나 일들을 하면서 지금 해왔던 것들이 분명 도움이 될 것이라고 생각하니 마지막까지 파이팅입니다!"*
+
+→ **MCP 룰 `reviewer-student-passion-acknowledgment`** ⭐⭐ 신규 — *학생 열정 → reviewer 자가 깊은 질문 어휘*. PR #134 (말리빈 미션 마무리)·PR #97 (ghojeong 자가 방향 안내 부족 아쉬움) 결의 *reviewer 자가 반성* 다른 축 — *reviewer 자가 학습 어휘*.
+
+## 대표 인용
+
+> [chanho0908 Thread 1]
+> *"이 경우 저는 추상화에 의존하는줄 알았지만 사실은 구현체에 의존하고 있었고 DIP를 위배하는 것 같습니다 (...) 그리고 이런 행위는 OCP도 위반하는 행위라고 생각합니다! (...) SRP를 준수할 수 있다고 생각해요!"*
+
+→ **학생 자가 SOLID 3종 위반 자가 자각 어휘 정점**.
+
+> [chanho0908 Thread 1]
+> *"나열하고 보니 아주 아주 못난이 코드였네요 😅"*
+
+→ **학생 자가 자조 어휘**.
+
+> [chanho0908 Thread 7]
+> *"저는 이 코드가 과연 정말 중복일까? 에 대해서 고민했어요! (...) 여기서 제가 생각하는 중복은 로버트 마틴이 주장한 \"우발적 중복\"에 해당한다고 생각합니다."*
+
+→ **학생 자가 로버트 마틴 인용 + 우발적 중복 자가 자각 어휘 정점**.
+
+> [lee-ji-hoon Thread 7]
+> *"무조건적으로 중복이 된다는 이유로 억지로 합쳐졌던 느낌이 없지 않아 있었긴 합니다. (...) 페토의 의견대로 진행하는 것이 좋아 보이네요"*
+
+→ **reviewer 학생 의견 인정 어휘**.
+
+> [chanho0908 Thread 5]
+> *"OutPutView에서 인터페이스 타입으로 받는 것도 아닌지라 인터페이스를 분리한 의미가 퇴색된 것 같습니다"*
+
+→ **인터페이스 의미 퇴색 자가 자각 어휘**.
+
+> [lee-ji-hoon 마지막 review]
+> *"페토가 정말 열정적이어서 저도 어떻게 하면 조금이라도 더 만족스러운 블랙잭 미션을 할 수 있을까 고민이 되어서 이것저것 많이 질문을 하고 리뷰를 남겼던 것 같네요."*
+
+→ **reviewer 학생 열정 인정 + 자가 깊은 질문 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **학생 자가 SOLID (DIP/OCP/SRP) 위반 자가 자각** — **MCP 룰 `student-SOLID-violation-self-realization` 후보** ⭐⭐⭐ 정점.
+2. **추상 클래스가 구현체 안다 = DIP 위반 + 모듈화 불가** — **MCP 룰 `abstract-class-knowing-concretes-anti-pattern` 후보** ⭐⭐⭐.
+3. **우발적 중복 vs 진짜 중복 학생 자가 자각** — **MCP 룰 `accidental-vs-essential-duplication-distinction` 후보** ⭐⭐⭐ 정점.
+4. **학생 자가 로버트 마틴 인용 (외부 권위 누적 4 PR)** — **MCP 룰 `student-cites-robert-martin` 후보** ⭐⭐⭐.
+5. **인터페이스 = 다형성 X = 의미 퇴색 (누적 3 PR)** — **MCP 룰 `interface-without-polymorphism-purpose-loss` 후보** ⭐⭐⭐.
+6. **when 분기 = 구현체 의존 / 다형성 (누적 6 PR)** — **MCP 룰 `polymorphism-vs-when-branch-on-concrete` 후보** ⭐⭐⭐ 정점.
+7. **기능 명세서 우선 습관** — **MCP 룰 `feature-spec-before-impl-habit-vocabulary` 후보** ⭐⭐.
+8. **reviewer 학생 열정 인정 + 자가 깊은 질문** — **MCP 룰 `reviewer-student-passion-acknowledgment` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **chanho0908 페토 2025 모바일 안드로이드 7기 코호트** — *2025 코호트 누적 PR 16개 정점*.
+- **학생 자가 외부 권위 인용 누적 4 PR** (PR #154 조영호 + PR #151 객체 지향 생활 체조 + PR #136 엘레강트 오브젝트 + PR #150 로버트 마틴) — *학생 자가 학습 외부 권위 누적*.
+- **학생 자가 SOLID 위반 자가 자각 정점** — DIP/OCP/SRP 동시 인용 + 못난이 코드 자조 — *학생 측 메타 어휘 정점*.
+- **다형성 vs when 분기 어휘 누적 6 PR 정점** = State 패턴 결 합류.
+- **Controller 어휘 누적 9 PR** — Controller 책임 + 테스트 + 분류 + 메시지 어휘 최정점.
+- **메타 케이스 13번째** — *chanho0908 학생 자가 SOLID 동시 자가 자각 + 로버트 마틴 인용 + 자조 어휘 (못난이 코드)*.

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

@@ -0,0 +1,259 @@
+# PR #26 — [블랙잭 1단계] 스캇 미션
+
+- **Reviewee:** [@chws0508](https://github.com/chws0508)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/26
+- **단계:** 1단계
+- **리뷰어:** @namjackson (잭슨)
+- **라인 코멘트:** 27 스레드 — *학생 자가 답변 + 책임 재고민 풍부* + *외부 글 2개 추천* + *블랙잭 룰 정확성 토론*
+- **신규 reviewee** (2023년 3월 PR — PR #23 와 같은 코호트). PR #41 (핑구 1단계) / #53 (베리 1단계) 의 reviewer 동일.
+
+## 잘한 점 (설계 관점)
+
+- **테스트 케이스 = 프로그램 명세서 어휘** — 잭슨: *"구체적인 케이스별로 테스트 코드작성 👍 👍 테스트 케이스만 보아도, 블랙잭 승리규칙을 알수 있을거 같네요 😄 이처럼 테스트 케이스를 하나의 프로그램 명세서라고도 할 수 있어요!"*. **테스트 = 명세서 = 학습 가시화 매개체 모범**. PR #99·#88·#85 의 *테스트 어휘* 결.
+- **`when` vs `if-else` 외부 글 추천** — 잭슨: *"if else 문외에 when을 활용해보면 어떨까요? when, if-else는 어느경우에 쓰는게 좋을까요? 가볍게 읽어보면 좋을거같아요!"* + [Kotlin 공식 문서 - if vs when](https://kotlinlang.org/docs/coding-conventions.html#if-versus-when). **외부 학습 자료 첨부** — PR #23·#74·#95·#67 결.
+- **한글 코딩 컨벤션 자가 답변 (학생 자가 학습)** — 잭슨: *"한글로 구현하셨네요, 한글로 코드를 짜게되면 어떤 단점들이 있을까요? 코딩 컨벤션을 따르면 무엇이 좋을까요?"* + [Kotlin 공식 문서 - property-names](https://kotlinlang.org/docs/coding-conventions.html#property-names) + *"(CamelCase, SnakeCase, UpperCase등 여러 네이밍의 케이스가 사용되는 이유는 무엇일까요?)"* + 학생 자가 답변: *"한글과 같은 비 ASCII 문자가 다른 개발자들에게 혼란을 줄 수 있고, 가독성에 좋지 못합니다... 코딩 컨벤션을 따르는 이유는 코드의 가독성을 높일 수 있고, 잠재적 오류를 줄일 수 있고, 유지보수에 용이하다는 장점이 있습니다."*. **학생 자가 학습 + 자가 의미 정리 모범**.
+- **블랙잭 룰 추가 학습 권고** — 잭슨: *"몇가지 추가적인 승리규칙이 있는데요, 카드를 단 두장으로만 21이되면, BlackJack이라고 합니다 같은 21점이라도, BlackJack상태는 세장 이상의 21점도 승리할수 있는 규칙이예요! BlackJack 21점 > 3장 이상 21 점 다음 미션시, 관련내용이 있으니 추가해주시면 좋을거 같아요!"*. **블랙잭 룰 정확성 권고 + 2단계 학습 시드**. PR #20·#64·#110·#120·#29·#63 의 *블랙잭 룰 오해* 결.
+- **`given-when-then` 패턴 suggestion 첨부** — 잭슨이 *suggestion 블록*으로 코드 예시 첨부: `// given val givenCards = ... // when, then assertThrows<...>`. **PR suggestion 기능 활용 = 학생이 바로 적용 가능**. PR #99 (KwonDae *given-when-then 패턴 권고*) 결.
+- **카드 캐싱 자가 학습 (Card.companion object)** — 잭슨: *"미리 CardDeck 1세트를 생성해놓고 쓰신부분 👍 👍 category와 number를 랜덤으로 생성하여 find 방법도 좋지만, 생성된 cardDeck을 섞어서( .shuffled() ) 뽑는 방식이 좀더 간단하게 접근할수 있는 방법 같아요!"* + 학생 후속: *"Card의 companion object 에서 카드덱을 미리 만들어두고 뽑아쓰는 형식으로 수정하였습니다."*. PR #74·#108·#133·#136·#23 와 같은 결.
+- **테스트 케이스 명명 어휘** — 잭슨: *"무엇을 검증 하는지를 중점으로 고민하시면 좋을거같아요! 만약 getGameResult의 무승부를 검증한다면, 'Burst되지 않은 동일한 점수일때, 승패를 확인하면, 무승부이다'"* — *주어 + 조건 + 검증 결과* 명명 모범.
+- **추상화 → 테스트** — 잭슨: *"CardDrawer를 추상화하셧으니, BlackJackGame Test도 작성해보면 어떨까요?"* — *interface 분리 = 테스트 친화 + 자가 테스트 권고*. PR #23·#74·#95·#99 의 *Random 테스트* 결.
+- **Score 클래스 자가 도입 (책임 분리 자가 반영)** — 잭슨: *"Cards객체의 책임이 조금 커진거 같아요! 점수 계산하는 부분의 책임을 분리해보면 어떨까요?"* + 학생: *"Score 클래스를 생성하여 분리하였습니다"*. **점수 책임 = Cards 가 아닌 Score 분리** — PR #131·#136·#146·#147·#70 의 *점수 책임 위치 트레이드오프* 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `Answer.YES` 입력값 → BlackJackGame 모름 권고
+
+잭슨: *"BlackJackGame에서 Answer.YES라는 입력값을 알아야 할까요? BlackJackGame에서는 카드를 추가로 받는지에 대한 부분만 관심사이지, 어떤 input을 받을지에 대한 부분 몰라도 좋을거같아요! input이란 네이밍도 함께 변경해보아요!"*
+
+학생: *"Boolean을 받도록 수정하였습니다"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *View 어휘 (`y`/`n` → `Answer.YES/NO`) 누수 방지*
+
+*BlackJackGame 도메인* 이 *`Answer.YES`* 같은 *입력 표현* 을 알면 = *입력 표현 변경 (예: "예"/"아니오") 시 도메인 변경*.
+
+#### 1.2. *Boolean vs sealed Action*
+
+- *Boolean* = 단순. *학생 자가 반영*.
+- *sealed class Action { Hit, Stay }* = *블랙잭 도메인 어휘 명시 + Bust 등 확장 가능*. PR #88·#90·#147 의 *Action enum* 결.
+
+#### 1.3. *`input` 변수명 — 모호*
+
+PR #23 (멘델) 의 *`input/output/choice` 모호 명명* 결. **MCP 기존 룰 `vagueName`**.
+
+### 2. `players.players` 중복 변수명
+
+잭슨: *"players.players 와같이 중복된 코드는 가독성을 저하시키기도합니다 players라는 변수명보다는 value, list 같은 변수명을 활용해도 좋을거같아요!"*
+
+→ **일급 컬렉션 변수명 컨벤션**:
+- *`Players(val players: List<Player>)`* → *외부 접근 `players.players`* 중복.
+- *`Players(val value: List<Player>)`* → *`players.value`* 단순.
+- *`Players(private val list: List<Player>)`* → *외부 접근 X, 메시지만*. **Tell-Don't-Ask 정공** — 잭슨의 *값 노출 자체* 가 가독성보다 큰 문제.
+
+PR #74·#99·#133·#137 의 *일급 컬렉션 자가 학습* 결.
+
+### 3. `RandomCardPicker` 테스트 전용 코드 + cards 생성시점 주입
+
+잭슨 1차: *"테스트 코드에서만 사용되고 있네요! 테스트를 위한 코드는 지양해주는것이 좋아요! 다른 방법의 테스트를 고민해보면 어떨까요?"*
+
+학생: *"더이상 사용되지 않는 코드여서 삭제하였습니다"*
+
+잭슨 2차 (메타 질문): *"cards를 생성시점에 주입하면 장점이 있을까요?"*
+
+학생 자가 답변: *"cards를 생성시점에 주입하면 cards가 한번만 생성될 것 같아서 데이터 관리에 효율적일 것 같습니다"*
+
+잭슨 3차 (도메인 룰 확장):
+
+> *"보통 CardDeck에서 카드를 뽑으면 해당 카드가 CardDeck에서 제외되곤합니다. 이 처럼 구현해보면 어떨까요? CardPicker 생성시점에, CardDeck를 주입받아서, 해당 CardDeck 또한 관리해보면 어떨까요? CardDeck에 카드가 모두 떨어졌을때에도 예외처리할 수 있을거 같아요!"*
+
+학생 자가 의문 (도메인 룰 인용):
+
+> *"제가 알기로는 블랙젝 게임에서는 여러카드덱을 사용하는것으로 알고있는데 카드를 뽑고나서 카드덱에서 지우게되면 중복된 카드를 뽑을 수 없게 되지 않나요? 그리고 카드가 다 떨어지게 되는 경우는 카드덱을 여러개 사용하지 않는다는 뜻 아닐까요?"*
+
+→ **3 가지 학습**:
+
+#### 3.1. *카드 뽑기 + 제외 vs 캐싱*
+
+- *뽑은 카드 = 덱에서 제외* (잭슨 권고) = *카드 1벌 한정 모델*.
+- *카드 캐싱 + 매번 random pick* (학생) = *여러 벌 가능 + 중복 카드 가능*.
+
+#### 3.2. *학생 자가 도메인 룰 인용*
+
+*"블랙젝 게임에서는 여러카드덱을 사용하는것으로 알고있는데"* — *카지노 6덱 메타포* (PR #58 otter66) 결. *카드 1벌 한정 = 6덱 룰과 충돌*.
+
+#### 3.3. *카드 부족 시 예외 vs 자연 종료*
+
+잭슨 권고 *"카드가 모두 떨어졌을때에도 예외처리"* = *1벌 한정 + 예외*. 학생 *"카드가 다 떨어지게 되는 경우는 카드덱을 여러개 사용하지 않는다는 뜻"* = *6덱 사용 시 비예외*. **둘 다 유효 — 도메인 룰 결정에 따라 다름**. PR #74·#108·#133·#136·#41 의 *카드 부족 시 게임 종료 UX* 결.
+
+### 4. `Participant Result 책임 위치 + 블랙잭 룰 정확성`
+
+잭슨: *"Participant에는 플레이어와 딜러가 있습니다, Result는 누구의 기준으로 승/패가 정해지는 걸까요? 해당 책임이 누구에게 있어야하는지 한번 고민해보셔도 좋을거같아요!"*
+
+블랙잭 룰 추가 명시:
+
+> *"블랙잭의 룰 상 플레이어와 딜러가 모두 Burst이더라도, 1. 플레이어 Burst -> 딜러의 점수와는 상관없이 플레이어 패배 2. 딜러 Burst -> Burst가 아닌 플레이어의 승리 가 정해집니다."*
+
+→ **2 가지 학습**:
+
+#### 4.1. *책임 위치 = Participant 부모 X*
+
+*Participant 부모에 Result 메서드* = *Player/Dealer 둘 다 동일 시그니처* → *그러나 Player 기준 vs Dealer 기준* 의 명확화 X. PR #23 (멘델 1단계) / #70 (chaehyuns 1단계) / #74 (송핑크 1단계) 의 *점수 책임 위치 토론* 결.
+
+#### 4.2. *블랙잭 룰 = 양측 Bust 분기*
+
+- *Player Bust → 자동 패배* (Dealer 의 Bust 무관).
+- *Dealer Bust → Bust 아닌 Player 승리*.
+
+**MCP 룰 후보 — `blackjack-rule-fidelity`** = *Player Bust 자동 패배* + *Dealer Bust 시 Bust 아닌 Player 승리*. PR #20·#64·#110·#120·#29·#63·#23 결.
+
+### 5. `ResultView` 비즈니스 로직 누수 → GameResult 클래스 자가 도입
+
+잭슨: *"게임의 결과값은 View의 역할은 아닌거 같아요 View에서 비즈니스 로직을 제거해보면 어떨까요?"*
+
+학생: *"GameResult 클래스를 생성해서 처리하였습니다"*
+
+→ **View ≠ 도메인**. *View 가 점수 비교, 승패 판정 = 도메인 로직 누수*. *GameResult 도메인 객체 분리 + View 는 표현만* 정공. PR #99·#108·#88 의 *view-by-stage-split* 결.
+
+### 6. `Cards(Set<Card>)` → List 자가 반영 (여러 카드덱)
+
+잭슨: *"카드는 여러카드덱을 한번에 사용하기때문에, 중복된 카드가 존재하기도합니다! Set으로 관리되어야할 필요는 없을거 같아요!"*
+
+학생: *"List로 바꾸어 주었습니다!"*
+
+→ PR #23 (멘델) 의 *Set vs List 여러 벌 카드* 와 *동일 진단 + 동일 학생 자가 반영*. *2023년 3월 동일 코호트 = 동일 안티패턴 + 동일 reviewer 진단* 패턴.
+
+**MCP 룰 후보 — `set-vs-list-multiset`** = *중복 허용 시나리오 검토*.
+
+### 7. `Cards.maxSumState / minSumState` 외부 분기 → Score 클래스 자가 도입
+
+잭슨: *"어떤 의도로 minSumState, maxSumState 를 나누셨을까요? State를 외부에서 다르게 사용될 이유는 없을거같아요!"*
+
+학생: *"생각해보니 불필요한 것 같아서 삭제하고, Score 클래스를 만들어서 처리하도록 하였습니다"*
+
+→ **외부 분기 함수 다중 제공 = 책임 누수**:
+- *`maxSumState` / `minSumState` 외부에 제공* = *호출자가 둘 중 선택* = *Ace 처리 룰을 호출자가 알아야 함*.
+- *`Score` 객체가 내부에서 결정* = *Ace 룰 캡슐화 + 단일 진입점*.
+
+**Ace 1↔11 양가성 + 단일 결정** — PR #137·#148·#90 의 *Ace 처리* 결.
+
+### 8. `Cards 초기 2장 검증` — 책임 위치 자가 학습
+
+잭슨: *"개인적인 의견이니 참고만해주셔도 좋아요. 카드 초기값이 2장인 부분의 검증이 필요할까요? 카드 2장을 초기값을 받는건 BlackJack게임의 관심사라고 생각이 들어요. Cards 생성에 이러한 조건이 있는 것은 외부에서 알기 힘들지 않을까 하는 생각이드네요!"*
+
+학생 자가 답변: *"블랙잭 게임에서 혹시 실수로 카드를 하나만 주입했을때를 방지하기 위해 제약을 걸어둔건데 생각해보니 Cards가 이것까지 알아야 하나 라고 생각되고 초기 카드 2장을 갖는건 Cards의 책임이 아니라 blackjackgame의 책임이라고 볼수도 있겠군요.. 객체의 역할과 책임에 대해 좀 더 고민해보겠습니다"*
+
+→ **3 가지 학습**:
+
+#### 8.1. *학생 자가 정당화 + 자가 후회*
+
+*"실수 방지를 위해 제약"* → *"Cards 가 이것까지 알아야 하나"* — *학생이 *자가 정당화 + 자가 후회* 두 단계 거침*. **자가 학습 풍부 모범**. PR #128·#135 의 *학생 자가 답변 모범* 결.
+
+#### 8.2. *책임 = Cards (일반 카드 묶음) vs BlackJackGame (블랙잭 도메인 규칙)*
+
+- *Cards* = *카드 묶음 일반 = 1장도 N장도 가능*.
+- *BlackJack 룰* = *초기 2장 분배*.
+- *Cards 에 *최소 2장* 제약* = *Cards 가 블랙잭 도메인 룰까지 알게 됨* → *Cards 재사용 불가 (다른 카드 게임에서 1장만 가질 수 없음)*.
+
+#### 8.3. *"외부에서 알기 힘들지 않을까"* — *암묵 제약 어휘*
+
+잭슨의 *"Cards 생성에 이러한 조건이 있는 것은 외부에서 알기 힘들지 않을까"* = **암묵 제약 (implicit invariant)** 어휘. *Cards(emptyList()) 가 통과될 것 같으나 init 에서 Exception* = *호출자 놀람*. PR #20·#64·#110 의 *implicit-invariant-on-known-rule* 결.
+
+### 9. `result` 람다명 — Show 동작 vagueName
+
+잭슨: *"result라는 람다는 무엇을 의미할까요? 뭔가 결과가 나올것 같은 이름인거 같아요! 반면에 이름과 달리 실제로는 플레이어의 카드를 Show해주는 동작을 하는것 같아요. 적당한 네이밍을 사용해보면 코드 가독성이 좋아질것 같아요!"*
+
+→ **MCP 기존 룰 `vagueName`**. *`result`* 명사가 *동작 (Show)* 을 의미함이 *기대와 다름*. 대안 = `showPlayerCards` / `onPlayerCardsRendered`. PR #23 의 *vagueName* 결.
+
+### 10. `초기 두 장 뽑기 = BlackJack 관심사 vs CardDrawer 관심사`
+
+잭슨: *"초기에 카드 두장을 뽑는건 BlackJack 객체의 관심사 아닐까요? CardDrawer에서는 불필요한 관심사는 아닐까요?"*
+
+→ **§8 와 동일 책임 위치**. *카드 한 장 뽑기 = CardDrawer* + *블랙잭 룰 (초기 2장 분배) = BlackJackGame* 분리.
+
+### 11. `Dealer.승패 바꿔주기 → 함수 분리`
+
+잭슨: *"승패를 바꿔주고있는데, 함수로 분리해보면 어떨까요?"*
+
+→ *조건 표현식 → 명명된 함수* = 가독성. PR #98 (chaehyuns *Judge 함수 분리*) 결.
+
+### 12. `Dealer.isPossibleDrawCard` if 문 → 조건식 리턴
+
+잭슨 suggestion 제공:
+
+```kotlin
+override fun isPossibleDrawCard(): Boolean = cards.maxSumState().sum <= DEALER_ADD_CARD_CONDITION
+```
+
+→ **Kotlin 표현식 함수** = *if문 + 단일 리턴 < 조건식 직접 리턴*. **Kotlin 어휘 (expression body)**.
+
+### 13. `forEach → map/groupingBy`
+
+잭슨: *"forEach를 사용하기보다 map, groupingBy 등을 활용해보아도 좋을거같아요!"*
+
+→ **Kotlin 컬렉션 어휘 (function-style)** = *forEach (Unit 반환) < map (값 반환) / groupingBy (그룹화)*. *학생: 승패는 Participant 공통 처리 + GameResult 에서 전체 정보 처리로 자가 반영*.
+
+### 14. `ParticipantsTest` 가독성 — 확장함수/팩토리
+
+잭슨: *"Participants 생성으로 코드가 길어지고, 가독성이 저하되네요! 테스트코드내 확장함수, 팩토리 등 여러 방법으로 간소화해보면 어떨까요?"*
+
+→ **PR #99 (KwonDae *Test Fixture 함수 분리*) 결**. **MCP 룰 후보 `test-fixture-quality-parity`** = *테스트 코드 = 프로덕션 동등 품질*.
+
+## 리뷰어 의견 요지 (잭슨 / namjackson)
+
+27 코멘트 특징 (PR #41/#53 와 동일 reviewer):
+
+- **메타 질문 어휘** — *"~ 어떨까요?"*, *"~ 어떤 단점들이 있을까요?"*, *"~ 누구의 기준으로 정해지는 걸까요?"* — 학생 자가 답변 유도. PR #41 (핑구) / #53 (베리) 와 동일.
+- **외부 자료 첨부 2회** — *Kotlin 공식 문서 (if vs when, property-names)*. **PR #23 (멘델, 말리빈) 외부 자료 2개 / PR #95 (송핑크, 말리빈) 외부 자료** 결. *공식 문서 인용이 이 코호트 reviewer 들의 공통 패턴*.
+- **suggestion 블록 활용 2회** — *given-when-then 패턴 코드 + `isPossibleDrawCard()` 표현식 코드*. **PR suggestion 기능 활용 = 학생이 한 클릭으로 적용 가능**.
+- **도메인 룰 정확성 명시** — *"플레이어 Burst → 자동 패배"* + *"BlackJack 21점 > 3장 이상 21점"*. **MCP 룰 후보 `blackjack-rule-fidelity`** 의 명확한 reviewer 인용.
+- **개인 의견 분리** — *"개인적인 의견이니 참고만해주셔도 좋아요"*. **MCP `oop_propose_alternatives` 어휘와 일치** + PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) / PR #23 (말리빈 *"제 개인적인 의견입니다"*) 결.
+- **머지 시점 학습 시드** — *"다음 미션시, 관련내용이 있으니 추가해주시면 좋을거 같아요!"* — *2단계 학습 시드 명시*. PR #98·#99·#95 의 *2단계 권유* 결.
+- **테스트 케이스 = 명세서 어휘** — *"테스트 케이스를 하나의 프로그램 명세서라고도 할 수 있어요!"* — **테스트 = 학습 가시화 매개체 메타 어휘**. PR #99 (KwonDae *Test Fixture 품질*) 결.
+
+## 대표 인용
+
+> *"한글과 같은 비 ASCII 문자가 다른 개발자들에게 혼란을 줄 수 있고, 가독성에 좋지 못합니다... 코딩 컨벤션을 따르는 이유는 코드의 가독성을 높일 수 있고, 잠재적 오류를 줄일 수 있고, 유지보수에 용이하다는 장점이 있습니다."* — chws0508 (학생 자가 학습 + 자가 의미 정리)
+
+> *"블랙젝 게임에서는 여러카드덱을 사용하는것으로 알고있는데 카드를 뽑고나서 카드덱에서 지우게되면 중복된 카드를 뽑을 수 없게 되지 않나요? 그리고 카드가 다 떨어지게 되는 경우는 카드덱을 여러개 사용하지 않는다는 뜻 아닐까요?"* — chws0508 (학생 자가 도메인 룰 인용 + 자가 의문)
+
+> *"블랙잭 게임에서 혹시 실수로 카드를 하나만 주입했을때를 방지하기 위해 제약을 걸어둔건데 생각해보니 Cards가 이것까지 알아야 하나 라고 생각되고 초기 카드 2장을 갖는건 Cards의 책임이 아니라 blackjackgame의 책임이라고 볼수도 있겠군요.. 객체의 역할과 책임에 대해 좀 더 고민해보겠습니다"* — chws0508 (학생 자가 정당화 + 자가 후회 + 자가 학습)
+
+> *"BlackJackGame에서 Answer.YES라는 입력값을 알아야 할까요? BlackJackGame에서는 카드를 추가로 받는지에 대한 부분만 관심사이지, 어떤 input을 받을지에 대한 부분 몰라도 좋을거같아요!"* — namjackson (View 어휘 누수 진단)
+
+> *"테스트 케이스만 보아도, 블랙잭 승리규칙을 알수 있을거 같네요 😄 이처럼 테스트 케이스를 하나의 프로그램 명세서라고도 할 수 있어요!"* — namjackson (테스트 = 명세서 메타 어휘)
+
+> *"블랙잭의 룰 상 플레이어와 딜러가 모두 Burst이더라도, 1. 플레이어 Burst -> 딜러의 점수와는 상관없이 플레이어 패배 2. 딜러 Burst -> Burst가 아닌 플레이어의 승리 가 정해집니다."* — namjackson (블랙잭 룰 정확성 명시)
+
+## 얻은 교훈
+
+1. **테스트 케이스 = 프로그램 명세서 어휘** — *테스트가 *동작 명세*를 표현* = *코드보다 가독성 높은 명세*. *케이스명 = "주어 + 조건 + 검증 결과"* 명명 모범. PR #99 (KwonDae *Test Fixture 품질*) 결.
+
+2. **블랙잭 룰 정확성 = 도메인 진단**:
+   - *Player Bust → 자동 패배* (Dealer Bust 무관).
+   - *BlackJack 21점 (2장) > 3장 이상 21점* — 1.5배 배당 적용 (2단계 학습 시드).
+   - **MCP 룰 후보 `blackjack-rule-fidelity`** — PR #20·#64·#110·#120·#29·#63·#23 결의 *명확한 reviewer 인용*.
+
+3. ***학생 자가 정당화 + 자가 후회 + 자가 학습*** 3 단계 모범 — *"실수 방지를 위해 제약" → "Cards가 이것까지 알아야 하나" → "객체의 역할과 책임에 대해 좀 더 고민"*. PR #128·#135·#108·#136 의 *학생 자가 답변 모범* 결.
+
+4. **암묵 제약 (implicit invariant) = *외부에서 알기 힘든 조건***. *`Cards(emptyList())` 가 init에서 Exception* = *호출자 놀람*. *암묵 제약 = 명시적 도메인 객체 (BlackJackGame) 로 이동* 정공. PR #20·#64·#110 의 *implicit-invariant-on-known-rule* 결.
+
+5. ***카드 1벌 vs 여러 벌 도메인 룰*** = *카드 캐싱 + 매번 random pick* vs *카드 뽑기 + 제외*. **둘 다 유효 — 도메인 룰 (카지노 6덱) 결정에 따라 다름**. *학생 자가 도메인 룰 인용 = 자가 학습 가시화*. PR #58 (otter66 *카지노 6덱 메타포*) / PR #23 (멘델 *Set vs List*) 결.
+
+6. **`View 어휘 (Answer.YES) → 도메인 누수`** = *입력 표현 변경 시 도메인 변경 위험*. *Boolean / sealed Action* 으로 대체. PR #88·#90·#147 의 *Action enum* 결.
+
+7. **점수 책임 위치 = Cards 가 아닌 Score 분리** — *Ace 1↔11 양가성 + 단일 결정 = Score 캡슐화*. *외부 분기 함수 (`maxSumState`/`minSumState`) 다중 제공 = 책임 누수*. PR #137·#148·#90·#131·#136·#146 결.
+
+8. **테스트 코드 가독성 = 확장함수 / 팩토리 / Test Fixture** — *Participants 생성 길어짐 = 확장함수 또는 팩토리 추출*. PR #99 (KwonDae *Test Fixture 품질*) 결. **MCP 룰 후보 `test-fixture-quality-parity`**.
+
+9. **`open class` 같은 `Dealer.isPossibleDrawCard` if 문 → expression body** — *Kotlin 표현식 함수 어휘* = *if + return 단일 < 조건식 직접 리턴*. PR #137·#148·#90·#146 의 *Kotlin 어휘 학습* 결.
+
+10. **suggestion 블록 활용** — *PR suggestion 기능 = 학생이 한 클릭 적용*. *given-when-then suggestion + 표현식 함수 suggestion* 두 번 사용. **PR 기능 활용 = reviewer 효율성 도구**.
+
+11. **외부 자료 첨부 = 학생 자가 학습 채널 확장** — *Kotlin 공식 문서 (if vs when, property-names)* + *Kotlin Academy / Kotlin 공식 문서 (PR #23 멘델)*. **PR 코멘트 = 짧은 텍스트 + 외부 자료 = 깊은 학습** — 2023년 3월 코호트 reviewer 공통 패턴. PR #23·#74·#95·#67·#41·#53 결.
+
+12. **머지 시점 학습 시드 = 2단계 권유** — *"다음 미션시, 관련내용이 있으니 추가해주시면 좋을거 같아요!"* — *블랙잭 룰 정확성 (1.5배 배당) 2단계 학습 시드*. PR #98·#99·#95 의 *2단계 권유* 결.
+
+13. **2023년 3월 코호트 패턴** = *Set vs List 카드덱 / Cards 책임 분리 / View 어휘 누수 / 한글 변수명 / 외부 글 추천* — PR #23 (멘델) 와 *동일 안티패턴 + 동일 reviewer 진단 패턴* (다만 reviewer 다름: 멘델=말리빈, 스캇=잭슨). **동일 코호트 = 동일 학습 시드**.
+
+14. **개인 의견 분리** — *"개인적인 의견이니 참고만해주셔도 좋아요"* — **MCP `oop_propose_alternatives` 어휘와 일치**. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) / PR #23 (말리빈 *"제 개인적인 의견입니다"*) 결.