oh-my-oop 0.2.0

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

@@ -0,0 +1,250 @@
+# PR #31 — [블랙잭 1단계] 반달 미션
+
+- **Reviewee:** [@no1msh](https://github.com/no1msh) (**반달 = 본 MCP `oh-my-oop` 프로젝트 저자**)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/31
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 19 스레드 — *학생 자가 PR 본문 의문 2개 (DTO 위치 + 상수화) + Dealer is-a Player 자가 의문 + Builder 패턴 자가 인정 + 일급 컬렉션 칭찬*
+- **신규 reviewee** + **메타 케이스: reviewee 가 본 MCP `oh-my-oop` 저자** — *학생 시절 코드 + reviewer 메타 어휘 양가 활용 사례*.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 2개 + 자가 후회 + 자가 어려움 명시** — *"미션 시간이 얼마남지 않아 바쁘게 하다보니 완벽하게 하진 못했던 것 같습니다ㅜㅜ"* + *(1) DTO 위치 (Controller vs Domain)* + *(2) 에러 메시지 상수화 vs 직접 작성*. **PR 본문 자가 의문 모범**. PR #128·#135·#108·#136·#137·#148·#151·#98·#95·#99·#46·#77·#91 결.
+- **`Command` 도메인 분리 칭찬** — vagabond95: *"코멘드를 따로 도메인으로 분리해주신 시도 좋습니다 👍"*. **Command 패턴 자가 도입** — *Hit/Stay 명령을 별도 도메인 객체로*. PR #88·#90·#147 의 *Action enum* 결.
+- **`View` 비즈니스 로직 X 칭찬** — vagabond95: *"View 의 역할에 맞게, 비즈니스 로직이 포함되지 않고 간결하게 잘 구현해주신 것 같습니다 👍"*. **View 책임 명확 분리** — PR #28·#79·#16·#26·#9 의 *View 로직 누수* 와 반대 결.
+- **일급 컬렉션 활용 칭찬** — vagabond95: *"일급 컬렉션 활용 👍"* (Cards 클래스).
+- **Controller 단순 중계 칭찬** — vagabond95: *"컨트롤러의 구현이 단순히 중계해주는 형태로 단순해졌네요 👍"* — *피드백 반영 후 칭찬*. PR #99·#95·#28·#78·#112·#125·#147·#43·#77·#46 의 *Controller god-object* 와 반대 결.
+
+## 못한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 1: `DTO 위치 = Controller vs Domain`
+
+PR 본문: *"우선, 이번 프로젝트를 진행하면서 Domain에서 DTO로 감싸서 전달하도록 하였습니다. 하지만 테스트 코드를 작성하는 것이 너무 힘들어진다는 문제가 발생하였는데, 이런 구조여도 괜찮은지 궁금합니다!"*
+
+→ **DTO 위치 양가성**:
+
+- **Domain 이 DTO 반환** (학생 선택):
+  - 장점: Domain 이 외부 표현 정확히 통제.
+  - **단점 (학생 자가 명시): 테스트 어려움** — *Domain 메서드가 DTO 반환 = 테스트 시 도메인 객체 직접 검증 X + DTO 변환 결과만 검증*.
+  
+- **Controller 가 Domain → DTO 변환** (정공):
+  - Domain 은 자기 객체만 반환 → Controller 가 DTO 변환.
+  - 장점: *Domain 테스트는 도메인 객체로 결정적 검증*. *Controller 가 변환 책임*.
+  - 단점: Controller 의 변환 책임 추가 (작은 비용).
+
+- **별도 Mapper / Assembler 객체**:
+  - 변환 책임을 별도 객체로 응집.
+
+**MCP 룰 후보 — `dto-conversion-locus`** = *Domain 이 DTO 반환 = 테스트 어려움 시그널*. PR #99 (s6m1n *Hand 클래스*) / PR #91 (murjune *UiModel*) / PR #88·#131 (view-by-stage-split) 결.
+
+학생 자가 명시 *"테스트 코드를 작성하는 것이 너무 힘들어진다는 문제"* — **테스트 어려움 = 책임 잘못 배치 시그널 자가 학습**. PR #99 (s6m1n *Controller + View 없이 가능?*) 와 같은 결의 *역방향* (학생측 자가 진단).
+
+### 2. PR 본문 자가 의문 2: `에러 메시지 상수화 vs 직접 작성`
+
+학생 자가 의문: *"에러 메시지와 같은 String도 const val 키워드를 통해 상수화를 해주는 것이 가독성이 높은지, 아니면 문자 그대로 작성하는 것이 높은지 궁금합니다!"*
+
+→ **에러 메시지 상수화 양가성**:
+
+- **상수화 (`const val ERROR_MESSAGE = "..."`)**:
+  - 장점: 메시지 변경 시 한 곳 수정.
+  - 장점: 다국어 / i18n 시 분리 용이.
+  - 단점: 호출 위치에서 메시지 내용 즉시 알기 어려움 (가독성 ↓).
+
+- **직접 작성 (`throw IllegalArgumentException("...")`)**:
+  - 장점: 호출 위치에서 메시지 즉시 가독.
+  - 단점: 동일 메시지 N 곳 = 변경 시 N 곳 수정.
+
+- **하이브리드** — *컴파일 시점 보간 (Kotlin string templates)* + *상수 prefix + 동적 인자*.
+
+**학생 자가 의문 모범**. *vagabond95 미답변* — *PR 본문 의문 답변 누락 가능성*. PR #46 (말리빈 *minusFrom 권고*) 의 *에러 메시지에 입력값 포함* 결.
+
+### 3. `Dealer is-a Player` 상속 의문
+
+vagabond95: *"딜러가 플레이어를 상속하는 구조로 구현해주셨는데, 블랙잭 도메인에서 `Dealer is a Player` 의 논리가 성립할까요?"*
+
+→ **3 가지 학습**:
+
+#### 3.1. *LSP (Liskov Substitution Principle) + is-a 논리*
+
+- *Dealer extends Player* = *모든 Dealer 는 Player* (LSP).
+- *블랙잭 룰*: *Dealer 는 베팅 X, 자동 hit ≤16, 1.5배 배당 분기* — *Player 와 행동 다름*.
+- *`Dealer is a Player` 가 의미적으로 성립 X* — *LSP 위반 위험*.
+
+#### 3.2. *Dealer extends Player vs 공통 부모 추상화*
+
+- **(A) `Dealer extends Player`** = 학생 선택. *PR #95 (말리빈 *Dealer 는 Player 의 변종?*) / PR #16 (BeokBeok *Dealer.name override?*) 의 *학생 자가 결정* 결*.
+- **(B) `abstract Participant` + `Player` / `Dealer extends Participant`** = *공통 부모 추상화*. PR #74·#108·#133·#132·#136·#49·#46 의 *추상 클래스 + Participant 통합* 결.
+- **(C) `interface Participant` + 다중 구현** = *상속 X + 인터페이스*.
+- **(D) `Dealer` / `Player` 무관계 + 협력자 위임** = *컴포지션*.
+
+**MCP 룰 후보 — `dealer-extends-player-lsp-violation`**. PR #95·#23·#46·#148·#151·#49·#132·#77 결.
+
+#### 3.3. *vagabond95 의 *"논리가 성립할까요?"* 메타 질문*
+
+학생 자가 답변 권유. PR #95 (말리빈 *Dealer 는 Player 의 변종?*) 와 *동일 메타 질문* — *2023년 3월 코호트 reviewer 공통 패턴*.
+
+### 4. `ParticipantsBuilder` + `BlackJackBuilder` — Builder 패턴 의문
+
+vagabond95 1차: *"빌더를 따로 두신 이유가 있으실까요? 현재 구현상, 빌더를 별도로 두었을때의 이점이 잘 보이지 않는 것 같습니다."*
+
+vagabond95 2차: *"빌더 패턴을 염두하여 만드신 것이라면, 현재구조는 빌더 패턴과는 거리가 멀어보입니다. 빌더 패턴의 구조에 대해 학습해보셔도 좋을 것 같아요."*
+
+vagabond95 3차 (BlackJackBuilder): *"Participants 빌더와 같은 맥락으로 꼭 필요한 클래스일지 검토 부탁드릴게요!"*
+
+→ **2 가지 학습**:
+
+#### 4.1. *Builder 패턴 = 복잡 객체 단계별 생성*
+
+- *Builder = 호출 순서 무관 + build() 시점 invariant 검증* (PR #9 BeokBeok 결).
+- *Participants 가 단순 List<Participant> = 빌더 불필요* — *생성자 + 팩토리 함수 충분*.
+
+#### 4.2. *YAGNI (You Aren't Gonna Need It)*
+
+- *현재 요구사항이 *복잡 생성 단계 X* + 학생이 *Builder 도입* = *과한 추상화*.
+- **PR #146 (yrsel YAGNI 자가 인정)** 결.
+
+**MCP 룰 후보 — `unnecessary-builder-pattern`** = *YAGNI 위반 + 책임 모호*. PR #9 (BeokBeok *Builder 호출 순서*) 결의 *Builder 도입 자체 불필요* 시점.
+
+### 5. `한글 변수명` — 코딩 컨벤션 위반
+
+vagabond95: *"변수명을 한글로 지으면 안되는 이유가 있다면 무엇일까요?"* + *"전반적으로 한글 변수가 사용된 케이스가 보이는데, 코멘트 참고하여 같이 검토 부탁드려요!"*
+
+→ **PR #26 (chws0508 *한글 컨벤션 외부 글 자가 학습*) 와 같은 결**. *비 ASCII 문자 = 다른 개발자 혼란 + 컨벤션 위반*.
+
+### 6. `enum 명명 구체화` + `CardNumber` enum 도입 권유
+
+vagabond95 1차: *"enum 클래스 네이밍이 좀 더 구체적으로 지어지면 좋을 것 같아요."* (Shape)
+
+vagabond95 2차: *"enum 으로 선언할 경우 좀 더 구현이 단순해질 것 같은데, 장/단점 비교 후 검토 부탁드려요." (CardNumber)*
+
+→ **enum 어휘 + 명명 구체성**:
+- *`Shape`* (추상) < *`CardShape`* / *`CardSuit`* (구체).
+- *CardNumber* = *class 보다 enum 정공* (1~10, J, Q, K, A = 닫힌 집합).
+
+**MCP 기존 룰 `vagueName` + enum 도입 권유**. PR #99·#26·#23·#39·#46·#16·#9 결.
+
+### 7. `동일 도메인 상태 분산` — `CardGenerator` vs `CardDeck` 양쪽 cards
+
+vagabond95 1차: *"generator 도 cards 를 가지고 있고, CardDeck 도 cards 를 가지고 있는데 각각 따로 관리되어야할 이유가 있을까요?"*
+
+vagabond95 2차 (메타 질문): *"동일한 도메인 상태가 여러곳에 분산되면 어떠한 문제점이 생길 수 있을까요?"*
+
+→ **도메인 상태 분산 = 동기화 문제**:
+- *동일 cards 가 generator + CardDeck 양쪽 보유* → *변경 시 양쪽 동기화 필요*.
+- *원본 단일 위치 (Single Source of Truth)* 정공.
+
+**MCP 룰 후보 — `domain-state-duplication`** = *동일 상태 다중 객체 보유*. PR #39 (rhthrhrl0 *redundant-state*) 결.
+
+### 8. `2번 draw 호출` — Controller vs Domain
+
+vagabond95: *"꼭 2번 draw 를 해주는게 도메인의 비즈니스 로직이라면, 2번 호출해주는 부분은 domain 이 담당해보는 것은 어떨까요? 현재 drawAll 호출에 대한 제약사항이 없는 상태애서, 횟수에 대한 context 가 부족한 개발자의 경우 여러번 호출하게될 가능성이 있을 것 같아요. (+ 여러번 호출했을 떄의 안전장치도 없는 것 같구요!)"*
+
+vagabond95 별도 (메타 질문): *"BlackJack 내부에서 수행 가능하지 않을까요? 컨트롤러가 도메인의 세부사항을 어디까지 알아야할지, 많이 알수록 or 적게알수록 장/단점은 무엇일지 고민해보면 좋겠어요!"*
+
+→ **Controller 도메인 세부 침투 양가성**:
+
+- *Controller 많이 알기*: *세부 제어 가능 + 도메인 변경 시 Controller 도 영향*.
+- *Controller 적게 알기*: *도메인 응집 + Controller 단순 + 도메인 변경 영향 차단*.
+
+**MCP 룰 후보 — `controller-domain-coupling-depth`**. PR #99·#95·#28·#78·#112·#125·#147·#43·#77·#46 결.
+
+PR #46 (krrong *drawCard() 두 번 호출 → 한 메서드 2장 반환*) 와 동일 결.
+
+### 9. `extension function` 활용 권유
+
+vagabond95: *"`승, 무, 패` 도 extension function 으로 변환하도록 구현해볼수도 있겠네요!"*
+
+→ **PR #9 (BeokBeok *winTo 확장 함수 vs 멤버 함수 학생 자가 4 분면*) 결**. *확장 함수 = 외부 변환 응집*.
+
+### 10. `상수 vs 함수` 제공 의문
+
+vagabond95: *"상수가 아닌 함수로 제공하시는 이유가 있을까요~?"*
+
+→ **상수 (val) vs 함수 (fun) 양가성**:
+- *상수* = *불변 + 계산 비용 X*.
+- *함수* = *호출 시점 계산 + 외부 의존 가능*.
+- *`fun blackJackNumber() = 21`* (상수임에도 함수) = *불필요한 함수 호출 비용 + 의도 모호*.
+
+PR #91·#43 (프로퍼티 vs 함수) 결.
+
+### 11. `getPlayerMatchResults()` 중복 통합
+
+vagabond95: *"getPlayerMatchResults() 와 구현이 거의 비슷해보이는데, 재사용하거나 통합해보는 것이 가능할까요?"*
+
+→ **DRY (Don't Repeat Yourself)**. PR #9 (BeokBeok *introduce vs companion init 중복*) 결.
+
+### 12. `draw() 계속 호출 시 예외 처리`
+
+vagabond95: *"draw() 를 계속 호출 했을때, 예외처리가 필요하지 않을까요?"*
+
+→ **카드 부족 시 도메인 룰**:
+- *예외 발생* (1 벌 한정 모델) vs *덱 리필* (카지노 6덱 메타포) vs *Optional 반환*.
+
+PR #46 (krrong *53번 뽑으면 오류?*) / PR #26 (chws0508 *6덱 메타포*) / PR #58·#74·#108·#133·#136·#41 결.
+
+### 13. `테스트 코드 비어있음`
+
+vagabond95: *"테스트 코드가 채워지지 않은 것 같아요!"*
+
+→ **TDD 요구사항 미준수**. PR #16·#33·#9 결.
+
+## 리뷰어 의견 요지 (vagabond95)
+
+19 코멘트 특징:
+
+- **간결 + 메타 질문 위주** — *"이유가 있을까요?"*, *"논리가 성립할까요?"*, *"어떠한 문제점이 생길 수 있을까요?"* — 학생 자가 답변 유도.
+- **장단점 비교 권유** — *"장/단점 비교 후 검토 부탁드려요"*, *"많이 알수록 or 적게알수록 장/단점은 무엇일지 고민해보면 좋겠어요"* — **MCP `oh-my-oop` 의 *N 안 + 트레이드오프* 어휘 합류**.
+- **빌더 패턴 학습 권유** — *"빌더 패턴의 구조에 대해 학습해보셔도 좋을 것 같아요"* — *학생 자가 학습 채널 권유*.
+- **`👍` 칭찬 분포** — *View 분리, Command 분리, 일급 컬렉션, Controller 단순화* 4회 칭찬. **균형 잡힌 분포**.
+
+## 학생/Reviewee 메타 케이스: no1msh = MCP `oh-my-oop` 저자
+
+본 PR의 학생 *no1msh = 반달* 은 이 분석 코퍼스가 사용되는 **MCP `oh-my-oop` 서버의 저자**.
+
+→ **메타 학습 케이스**:
+
+1. **2023년 3월 학생 시기 코드** = *Dealer extends Player + Builder 패턴 도입 + 한글 변수* 등 *현재 MCP 룰이 진단할만한 안티패턴 다수*.
+2. **현재 MCP `oh-my-oop`** = *학생 시기 자가 학습이 *룰화* + *N 안 + 트레이드오프* 어휘로 진화*.
+3. **vagabond95 의 reviewer 어휘** (장단점 비교, 메타 질문) = **MCP `oh-my-oop` 핵심 어휘와 일치**.
+
+PR #46 (krrong 학생 + reviewer 메타 케이스) 와 *같은 결의 *1 년 학생 → 도구 저자* 진화 케이스*. **학생 시기 자가 의문 → 도구화** 패턴.
+
+## 대표 인용
+
+> *"미션 시간이 얼마남지 않아 바쁘게 하다보니 완벽하게 하진 못했던 것 같습니다ㅜㅜ"* — no1msh (학생 자가 완성도 인정)
+
+> *"우선, 이번 프로젝트를 진행하면서 Domain에서 DTO로 감싸서 전달하도록 하였습니다. 하지만 테스트 코드를 작성하는 것이 너무 힘들어진다는 문제가 발생하였는데, 이런 구조여도 괜찮은지 궁금합니다!"* — no1msh (DTO 위치 + 테스트 어려움 자가 시그널)
+
+> *"에러 메시지와 같은 String도 const val 키워드를 통해 상수화를 해주는 것이 가독성이 높은지, 아니면 문자 그대로 작성하는 것이 높은지 궁금합니다!"* — no1msh (상수화 양가성 자가 의문)
+
+> *"블랙잭 도메인에서 `Dealer is a Player` 의 논리가 성립할까요?"* — vagabond95 (LSP + is-a 논리 메타 질문)
+
+> *"동일한 도메인 상태가 여러곳에 분산되면 어떠한 문제점이 생길 수 있을까요?"* — vagabond95 (도메인 상태 분산 메타 질문)
+
+> *"컨트롤러가 도메인의 세부사항을 어디까지 알아야할지, 많이 알수록 or 적게알수록 장/단점은 무엇일지 고민해보면 좋겠어요!"* — vagabond95 (Controller-Domain 결합 깊이 양가성)
+
+## 얻은 교훈
+
+1. **`DTO 위치 = Controller vs Domain` 양가성** — *Domain 이 DTO 반환 = 테스트 어려움 시그널*. *Controller 변환 정공 + Domain 은 자기 객체*. **MCP 룰 후보 `dto-conversion-locus`**. *학생 자가 테스트 어려움 명시 = 책임 잘못 배치 자가 진단 모범*.
+
+2. **`Dealer is-a Player` LSP 위반** — *블랙잭 룰의 Dealer ≠ Player 차이 (베팅 X, 자동 hit, 1.5배)* = *상속 시 LSP 위반*. **MCP 룰 후보 `dealer-extends-player-lsp-violation`**. PR #95·#23·#46·#148·#151·#49·#132·#77 결.
+
+3. **`불필요한 Builder 패턴`** — *YAGNI 위반 + Builder 정의 (호출 순서 무관 + build() invariant) 미준수*. **MCP 룰 후보 `unnecessary-builder-pattern`**. PR #9 (BeokBeok *Builder 호출 순서*) / PR #146 (yrsel *YAGNI 자가 인정*) 결.
+
+4. **`동일 도메인 상태 분산` = Single Source of Truth 위반** — *동일 cards 가 generator + CardDeck 양쪽 보유 = 동기화 문제*. **MCP 룰 후보 `domain-state-duplication`**. PR #39 (rhthrhrl0 *redundant-state*) 결.
+
+5. **`Controller-Domain 결합 깊이`** — *Controller 많이 알기 = 세부 제어 + 변경 영향* vs *적게 알기 = 도메인 응집 + 변경 차단*. **MCP 룰 후보 `controller-domain-coupling-depth`**. PR #99·#95·#46·#77 결.
+
+6. **`상수화 vs 직접 작성` 학생 자가 의문** — *상수 (한 곳 수정) vs 직접 (즉시 가독)* — **MCP 룰 후보 `string-constant-locus`**. *학생 자가 의문 가시화 모범*.
+
+7. **`reviewer 메타 어휘 = MCP `oh-my-oop` 핵심과 일치`** — *vagabond95 의 *"많이 알수록 or 적게알수록 장/단점"*, *"장/단점 비교 후 검토"*. **MCP `oh-my-oop` 의 *N 안 + 트레이드오프* 어휘 합류**. PR #23·#26·#43·#46·#91·#95 의 *9 reviewer 모두 공통 어휘* 결.
+
+8. **`no1msh = MCP `oh-my-oop` 저자` 메타 학습 케이스** — *2023년 3월 학생 시기 자가 의문 → 1 년 후 도구 저자*. *학생 시기 자가 학습이 *룰화 + 어휘 진화*. PR #46 (krrong 학생 + reviewer) 결의 *학생 → 도구* 변형.
+
+9. **`테스트 어려움 = 책임 잘못 배치 시그널`** — *학생이 *DTO 변환을 Domain 에 둔 후 테스트 어려움 자가 발견*. **테스트 어려움 = 설계 시그널** 자가 학습 모범. PR #99·#91·#46·#23·#74 결.
+
+10. **`Command 도메인 분리`** — *Hit/Stay 명령을 별도 도메인 객체로*. PR #88·#90·#147 의 *Action enum* 결의 *Command 패턴*.
+
+11. **`한글 변수명` 컨벤션 위반** — *비 ASCII = 다른 개발자 혼란*. PR #26 (chws0508 *한글 컨벤션 외부 글 자가 학습*) 결의 *학생측 미인식 케이스*.
+
+12. **`vagabond95 reviewer 패턴`** — *간결 + 메타 질문 위주 + 장단점 비교 권유*. *batch 12 신규 reviewer 로 등장한 reviewer 의 *2023년 3월 코호트* 활동 진단*.

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

@@ -0,0 +1,302 @@
+# PR #24 — [블랙잭 1단계] 수달 미션
+
+- **Reviewee:** [@otter66](https://github.com/otter66)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/24
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 21 / 리뷰이 9)
+
+## 잘한 점 (설계 관점)
+
+- **`Cards` 일급 컬렉션 + `sumCardsNumber()` + Ace 보정 분리** — 점수 계산을 Cards에.
+- **`CardGenerator(randomGenerator: Generator)` Strategy** — 테스터빌리티 (후속에 `Deck` 클래스로 단순화).
+- **`Result` enum (WIN/LOSE/DRAW) + `Result.valueOf(dealerSum, participantSum)` 분리**.
+- **`Participants` 일급 컬렉션 + `values: List<Participant>` 접근자**.
+- **후속 반영 — `Cards` 방어적 복사 + Deck 도입 + 함수 순서(stepdown) + Participant 추상화 + match 메시지 분리**.
+
+## 못한 점 (설계 관점)
+
+### 1. `CardShape.word` / `Result.word` — UI 문자열 도메인 보유
+
+```kotlin
+enum class CardShape(val word: String) { SPADE("스페이드"), DIAMOND("다이아몬드"), HEART("하트"), CLOVER("클로버") }
+enum class Result(val word: String) { WIN("승"), LOSE("패"), DRAW("무"); }
+```
+
+리뷰어: "*word는 UI의 관심사*이지 않을까요? 가령 스페이드를 *"spade" "♤"* 이렇게 출력할 수도 있습니다." / "마찬가지로 *"승", "패", "무"는 UI의 관심사로 보입니다*." — PR #28·#78·#112·#125·#128·#135와 동일한 *enum의 UI 표현 보유* 패턴. **6개 PR 연속 등장하는 안티패턴**.
+
+### 2. `Cards.isBlackjack()` — *2장 + ACE + JQK*인지 *직접 비교*
+
+```kotlin
+private fun isBlackjack(): Boolean {
+    if (_cards.size != 2) return false
+    val condition1 = _cards.filter { it.number == CardNumber.ONE }.size
+    val condition2 = _cards.filter {
+        it.number == CardNumber.KING || it.number == CardNumber.QUEEN || it.number == CardNumber.JACK
+    }.size
+    if (condition1 == 1 && condition2 == 1) return true
+    return false
+}
+```
+
+리뷰어: "*점수를 계산할 때에는 간단하게 아래처럼 생각해볼 수 있습니다.* ``` 1. 카드 점수를 합산한다 2. 에이스 카드가 있다면, 보너스 점수 10점을 더한 결과가 21 이하라면, 그 값을 반환한다. ```" — *블랙잭 = ACE + JQK 2장*이라는 *특별 케이스*가 *별도 메서드*. *합산 후 21 이하면 +10 보너스*가 *단일 룰*로 더 단순. + `condition1` / `condition2` 같은 *변수명*은 *의미 부재*.
+
+### 3. `open class Player` + `Dealer : Player` 상속
+
+```kotlin
+open class Player(val name: String, ...) {
+    fun checkMustGenerateCard(): Boolean = ...
+    fun isGenerateCardPossible(): Boolean = ...
+}
+class Dealer(name: String = "딜러") : Player(name) {
+    fun checkMustGenerateCard(): Boolean = cards.sumCardsNumber() <= MIN_SUM_NUMBER
+}
+```
+
+리뷰어: "*플레이어와 딜러 에게는 각자 카드를 더 뽑을 수 있는지 방법이 다릅니다.* 즉 *딜러인지 플레이어인지 상관 없이 카드를 더 뽑을 수 있는지? 에 대해서만 요청을 할 수 있다고 볼 수 있겠습니다.* open class를 이용한 상속 구조가 아닌, *다형성을 이용한 추상 클래스*를 고려해보면 어떨까요? ```kotlin abstract class Player { abstract fun canDraw(): Boolean }``` `dealer.checkMustGenerateCard() // (X)` / `participant.isGenerateCardPossible() // (X)` / `player.canDraw() // (O) 딜러인지 참가자인지 관심없음, 더 뽑을 수 있니?`" — PR #29와 같은 결. *`canDraw()` 단일 메서드*가 *Liskov 호환*.
+
+또: 함수명 `checkMustGenerateCard` / `isGenerateCardPossible` 둘 다 *동작 동사*가 아닌 *상태 질의의 우회 표현*. `canDraw()` 한 줄.
+
+### 4. `Player.generateCard()` — 카드를 *생성*?
+
+```kotlin
+open class Player(
+    val name: String,
+    private val generator: CardGenerator = CardGenerator(RandomGenerator())
+) {
+    fun generateCard() { cards.addCard(generator.generateCard()) }
+}
+```
+
+리뷰어: "*카드를 뽑는다 라는 개념은 addCard(card)를 이용해서 전달되는것에 반해 카드를 생성한다라는 개념은 플레이어에게 어떤 의미를 가지는 것일까요?* *카드 뭉치(Deck)에서 카드를 한장 뽑는다 라는 기능*을 구현할 수도 있지 않을까요? ```kotlin class Player { fun draw(deck: Deck) { ... } }```"
+
+학생 자가 인정: "*말씀해주신 것처럼 카드를 발행하는 것(뽑는 것)은 플레이어가 아닌 덱에서 진행한 후 플레이어의 카드에 더하는 것이 더 좋은 방법인 것 같아 그렇게 수정*하였습니다!" — *Player가 generator를 보유 + 카드 생성 책임*은 *카드 출처 책임이 Player에*. *덱에서 한 장 뽑기*가 자연.
+
+### 5. `Player(name, generator = CardGenerator(RandomGenerator()))` — 깊은 기본값 의존
+
+```kotlin
+open class Player(
+    val name: String,
+    private val generator: CardGenerator = CardGenerator(RandomGenerator())
+) {...}
+```
+
+*Player가 생성자 기본값에 RandomGenerator 의존*. *기본 생성 비용*에 *Random 인스턴스 매번* + *테스터빌리티 ↓*. *생성자 주입은 호출자가 명시*가 자연.
+
+### 6. `Player.name`의 `require(name.length in 2..10)` — 이름 검증이 Player에 박힘
+
+```kotlin
+init { require(name.length in 2..10) { ERROR_NAME_LENGTH } }
+```
+
+리뷰어: "*플레이어 이름에 대해 도메인 로직을 분리*해보세요"
+
+학생 변호: "*플레이어의 이름에 대해 "Name"등과 같이 분리를 할까 생각하였지만 이름의 길이를 검사하는 것 외에는 로직이 없고, 요구사항 외의 불필요한 로직이라 생각하여 해당 로직을 제거하는 방향으로 결정*하였습니다!!" — *Name 도메인 분리* 대신 *검증 제거*. **Trade-off**: *분리하면 객체 1개 더 + 검증 보유*, *제거하면 invariant 손실*. 학생은 *요구사항 외*라며 *후자 선택*. 리뷰어 의도는 *분리* 권고였으나 학생 *YAGNI 적용*. 합리적 결정 가능.
+
+### 7. `OutputView`에 *String + 연산자 누적*
+
+```kotlin
+fun printFinalResult(dealer: Dealer, participants: Participants) {
+    var dealerResultMessage = FINAL_DEALER_RESULT_MENT
+    if (dealer.results[Result.WIN] != 0) dealerResultMessage += "${dealer.results[Result.WIN]}${Result.WIN.word} "
+    if (dealer.results[Result.LOSE] != 0) dealerResultMessage += "${dealer.results[Result.LOSE]}${Result.LOSE.word} "
+    if (dealer.results[Result.DRAW] != 0) dealerResultMessage += "${dealer.results[Result.DRAW]}${Result.DRAW.word} "
+    println(dealerResultMessage)
+}
+```
+
+리뷰어: "*코틀린에서는 String 을 + 연산으로 이어나가는 방식은 지양*합니다. *buildString과 같은 문자열 Builder 함수를 사용* 해보세요" — `+=`로 *불변 String을 매번 새 인스턴스*. `buildString { ... }` 또는 `joinToString` 등 *전용 빌더*.
+
+### 8. `CardGenerator + RandomGenerator + Generator` — 명사 중복
+
+```kotlin
+class CardGenerator(private val randomGenerator: Generator) {
+    fun generateCard(): Card = Card(generateCardNumber(), generateCardShape())
+    fun generateCardNumber(): CardNumber = randomGenerator.generateCardNumber()
+    fun generateCardShape(): CardShape = randomGenerator.generateCardShape()
+}
+```
+
+리뷰어: "*제너레이터, 카드 제너레이터, 랜덤 제너레이터 등 여러가지 비슷한 개념이 뒤섞여 있는 느낌*이 듭니다. 로또 미션에서 *45개 라는 변하지 않는 숫자라는 개념*을 사용한 것과 같이 *카드 뭉치에는 최대 52개의 카드가 존재할 수 있습니다.* `끗수(13개) * 모양(4개) = 52` 이러한 개념을 모델로 풀어내보면 어떨까요? `class Deck(private val cards: Cards) { ... }` 마찬가지로 *하나의 블랙잭 게임에서는 무한대로 카드를 뽑을 수 있는 개념이 아니겠죠?*"
+
+학생 자가 인정: "*테스트를 위해 제품코드에 인터페이스를 두고 구현하는 방법을 선택*하였는데 이 과정에서 *불필요한 코드가 여럿 생긴 것 같습니다*. 말씀해주신 것처럼 *덱 클래스를 두고 덱에서 카드를 뽑아줄 수 있도록 변경*하였습니다!!" — **테스터빌리티 위해 추상화 폭증 → 도메인 어휘 흐려짐**. *덱 = 52장 한정 자료구조*가 더 자연. PR #29와 같은 결.
+
+### 9. `Result.valueOf(dealerSum, participantSum): Result` — 정적 + Int 비교
+
+```kotlin
+enum class Result {
+    companion object {
+        fun valueOf(dealerSum: Int, participantSum: Int): Result {
+            when {
+                ((dealerSum > Cards.MAX_SUM_NUMBER) and (participantSum > Cards.MAX_SUM_NUMBER)) -> return DRAW
+                ...
+            }
+            return WIN
+        }
+    }
+}
+```
+
+리뷰어: "*승부를 결정짓는 것은 딜러와 상관없이 참가자가 다른 참가자와 판단할 요소이지 않을까요?* ```kotlin abstract class Player { fun decideResult(otherPlayer: Player): Result { ... } } ```" / 후속 댓글: "*승부를 판단하는 것은 참가자가 스스로 해야 하지 않을까요?* [...] 마찬가지로 *참가자는 다른 참가자와 점수를 비교할 수 있다는 의미*입니다. *가령 딜러 vs 플레이어가 아닌 플레이어 vs 플레이어의 승부가 되도 전혀 문제가 없어야* 합니다. ```kotlin abstract class Player { fun match(other: Player): Result { ... } } ```" / 또: "*한사람이 여러 사람과 승부를 벌이는 입장*에서도 마찬가지로 참가자의 역할로 만들어 볼 수 있겠습니다. ```kotlin abstract class Player { fun match(others: List<Player>): GameResult } class GameResult(val participant: Participant, val winCount: Int, val loseCount: Int, val drawCount: Int) ```"
+
+→ **세 번의 리뷰**로 *상대 무관 비교 + 1대다 확장*까지 모델 제시. PR #28·#63·#125·#128·#29와 동일 주제 — *match는 참가자 메시지*가 핵심.
+
+### 10. `Cards(_cards: MutableList<Card> = mutableListOf())` — 방어적 복사 누락
+
+```kotlin
+class Cards(private val _cards: MutableList<Card> = mutableListOf())
+```
+
+리뷰어: "*방어적 복사가 이루어질 수 있도록 해주세요* ```val cards = mutableListOf<Card>(); Cards(cards); cards.add(Card()); cards.add(Card()); cards.add(Card())```" — *외부 참조 보유*하면 *외부에서 추가 가능*. 학생 자가 인정: "*방어적 복사...!!! 수업시간에 배웠던 내용인데 무심코 지나쳐버렸네요...ㅠㅠ 방어적 복사를 적용하여 외부에서 전달한 리스트와 다른 주소의 리스트를 사용하도록 변경*하였습니다!! 감사합니다!!" — PR #79 (ii2001)·#65 (kmkim2689)와 같은 *Hand 외부 참조 누수*.
+
+### 11. `BlackjackController`가 *카드 발급 직접 호출* — Participants 메시지 없음
+
+```kotlin
+private fun settingPlayersCards(dealer: Dealer, participants: Participants) {
+    repeat(CARD_SETTING_COUNT) { dealer.addCard(cardGenerator.generateCard()) }
+    participants.values.forEach { participant ->
+        repeat(CARD_SETTING_COUNT) { participant.addCard(cardGenerator.generateCard()) }
+    }
+}
+```
+
+리뷰어: "*카드를 뽑는 동작을 참가자들(Participants) 객체에게 메시지를 전달해서 동작하도록* 해주세요. 다른 비슷한 곳도 같이 개선이 되면 좋겠습니다" — Controller가 *Dealer + Participants 각각 직접 호출*. `participants.drawInitial(deck)` 한 줄이 자연. *일급 컬렉션이 비즈니스 동작 제공*하는 패턴.
+
+### 12. `readParticipantMoreCard` 깊은 중첩 + 불필요 분기
+
+```kotlin
+private fun readParticipantMoreCard(participant: Participant) {
+    while (true) {
+        val check = participant.isGenerateCardPossible()
+        if (check) {
+            val answer = inputView.readMoreCard(participant.name)
+            if (answer == ANSWER_MORE_CARD) { participant.addCard(cardGenerator.generateCard()) }
+            outputView.printParticipantCards(participant)
+            if (answer == ANSWER_NOT_MORE_CARD) break
+        }
+        if (!check) break       // ⚠ check 변수를 if 두 번 검사
+    }
+}
+```
+
+리뷰어: "*불필요한 괄호와 조건식이 같이 사용*되었습니다. 위 코드의 *가독성을 개선* 해 볼 수 있지 않을까요?" — `check`를 *if 두 번 + while true* 조합으로 *복잡*. `while (participant.isGenerateCardPossible())`로 *Boolean 결과를 while 조건에*.
+
+### 13. `Cards.MAX_SUM_NUMBER = 21` — *Result enum이 외부 Cards 상수 참조*
+
+```kotlin
+enum class Result {
+    companion object {
+        fun valueOf(dealerSum: Int, participantSum: Int): Result {
+            when {
+                (dealerSum > Cards.MAX_SUM_NUMBER) ... -> return DRAW
+            }
+        }
+    }
+}
+```
+
+`Result.valueOf` → `Cards.MAX_SUM_NUMBER` 의존. *Result가 Cards의 상수* 참조 = *역방향 의존*. PR #29의 `Cards`가 `BlackJack.blackjackScore()` 참조와 같은 결.
+
+### 14. `Dealer.results: MutableMap<Result, Int>` public + Controller가 변경
+
+```kotlin
+class Dealer(...) : Player(...) {
+    val results: MutableMap<Result, Int> = Result.values().associateWith { 0 }.toMutableMap()
+}
+
+// Controller에서
+dealer.decideParticipantsResult(participants)
+dealer.decideDealerResult(participants)
+```
+
+*공개 mutable Map*. *invariant 무방비*. PR #125 (jerry8282) `Participants.cards/status` 와 같은 결.
+
+### 15. `Participants(values: List<Participant>)` — values 명명 모호
+
+```kotlin
+class Participants(val values: List<Participant>)
+```
+
+리뷰어: "*참가자들을 생성하기 위한 values가 무엇인지 사용하는 측에서 알기 어렵지 않을까요?*"
+
+학생 변호: "*참가자 리스트라는 것을 직관적으로 나타낼 수 있는 participants라는 변수명을 사용*하려고 하였으나 외부에서 사용시 ``Participants.participants``로 사용하게 되어 *가독성이 좋지 않다고 판단*하였습니다. 따라서 *`mapOf<Int, String>().valu...`*" (cut) — *클래스 == 속성 동어반복* 회피 의도는 좋으나 `values`는 *Map.values* 연상. `items` 또는 *공개 자체를 안 함*(메서드로 노출).
+
+### 16. `Cards.getFirstCard()` 류 누락 + Dealer 1장 vs Player 2장 공개 비대칭 (다른 PR 패턴 — 이 PR엔 명시 안 됨)
+
+생략.
+
+### 17. `Deck.??` 무슨 동작 함수인지 불명
+
+리뷰어: "*무슨 동작을 하는 함수인지 이해가 잘 되지 않아요. 덱이 가지고 있는 카드들을 생성자 혹은 정적 팩토리 메소드로 만들어 볼 수 있지는 않을까요?*"
+
+→ Deck의 메서드명이 *동작 모호*. *카드 미리 보유 + 생성자/팩토리*가 자연.
+
+### 18. `DealerTest` 함수명 — *상태 질의*
+
+```kotlin
+@Test fun `카드를 더 받아야 하는 상태인지 확인한다`() { ... }
+```
+
+리뷰어: "*카드를 더 받아야 하는 상태가 무엇일까요?* *테스트 코드는 프로그램의 사양서*라고 부르기도 합니다. 즉 *테스트 코드만 봐도 어떻게 동작하는지 예측이 될 수 있도록 구체적으로 작성*하는 것이 중요합니다. 위 테스트로 예를 들어 보면, 아래처럼 작성이 가능합니다. *"카드의 합계가 16점보다 높다면 더 뽑을 수 없다"* / *"카드의 합계가 16점보다 낮다면 더 뽑을 수 있다"*" — *상태 라벨* 대신 *시나리오 + 결과*.
+
+### 19. `DeckTest`가 *모든 요구사항을 한 테스트에*
+
+```kotlin
+@Test fun `덱은 52장 카드를 가지며 무작위로 1장씩 카드를 뽑을 수 있다`() {
+    // 52장 검증 + 셔플 검증 + 1장 뽑기 검증
+}
+```
+
+리뷰어: "*한번에 모든 요구사항을 가지는 테스트를 하려고 하지 않아도* 됩니다. *덱이 가지는 특징을 테스트 할 수 있는 정도로 환경을 준비하는 것으로 충분*합니다. ```kotlin fun `카드 덱에 'A 하트' '3 스페이드'가 있을 때, 1장을 뽑으면 ...````" — *한 시나리오 한 테스트*. *모든 요구사항 검증* 의도는 *통합 테스트*에 가까움 + *실패 원인 추적 어려움*.
+
+## 리뷰어 의견 요지
+
+- ***enum의 UI 문자열 보유는 6개 PR 연속 안티패턴***.
+- ***블랙잭 = ACE+JQK 2장* 특별 처리보다 *합산 + 보너스 10*** 단일 룰.
+- ***open class < abstract Participant + canDraw()*** — PR #29와 같은 결.
+- ***Player.generateCard() = 카드 출처 책임이 Player*** — `draw(deck: Deck)` 권고. 학생 자가 반영.
+- ***String += < buildString***.
+- ***Generator/CardGenerator/RandomGenerator 명사 중복 = 도메인 어휘 흐려짐*** — *Deck 52장 한정* 모델.
+- ***match는 참가자 메시지 (Tell-Don't-Ask)*** — 세 번의 리뷰로 1대1, 1대다 확장 제시.
+- ***Cards 외부 참조 = 방어적 복사 필요*** (학생 자가 반영).
+- ***Controller가 직접 호출 < Participants 메시지***.
+- ***Dealer.results MutableMap public = invariant 무방비***.
+- ***Participants.values 명명 모호***.
+- ***Deck 메서드 동작 모호***.
+- ***DealerTest 함수명 = 상태 라벨 < 시나리오 + 결과***.
+- ***DeckTest 한 테스트에 모든 요구사항 X*** — 한 시나리오 한 테스트.
+
+## 대표 인용
+
+> word는 *UI의 관심사*이지 않을까요? / "승", "패", "무"는 *UI의 관심사로 보입니다*.
+> — @laco-dev on `CardShape.kt` / `Result.kt`
+
+> 카드를 뽑는다 라는 개념은 addCard(card)를 이용해서 전달되는것에 반해 *카드를 생성한다라는 개념은 플레이어에게 어떤 의미를 가지는 것일까요?* 카드 뭉치(Deck)에서 *카드를 한장 뽑는다 라는 기능*을 구현할 수도 있지 않을까요?
+> — @laco-dev on `Player.kt`
+
+> 제너레이터, 카드 제너레이터, 랜덤 제너레이터 등 *여러가지 비슷한 개념이 뒤섞여 있는 느낌*이 듭니다. [...] *카드 뭉치에는 최대 52개의 카드가 존재할 수 있습니다.* 끗수(13개) * 모양(4개) = 52
+> — @laco-dev on `CardGenerator.kt`
+
+> 한사람이 여러 사람과 승부를 벌이는 입장에서도 마찬가지로 참가자의 역할로 만들어 볼 수 있겠습니다. `abstract class Player { fun match(others: List<Player>): GameResult }`
+> — @laco-dev on `Score.kt`
+
+> 한번에 모든 요구사항을 가지는 테스트를 하려고 하지 않아도 됩니다. *덱이 가지는 특징을 테스트 할 수 있는 정도로 환경을 준비*하는 것으로 충분합니다.
+> — @laco-dev on `DeckTest.kt`
+
+## 얻은 교훈
+
+- ***enum의 UI 문자열(`word`, `koreanText` 등)은 7개+ PR 연속 안티패턴 = MCP 룰 후보로 매우 강력*** — *변경 비용이 도메인-뷰 경계 붕괴*.
+- ***블랙잭 = ACE+JQK 2장* 같은 *특별 케이스 분기*보다 *합산 + 보너스 10* 단일 룰*** — *룰을 자료구조에 위임*하면 분기 폭증 회피.
+- ***open class 상속 < abstract Participant + canDraw()*** — PR #29와 같은 결. *현실 비유 자율성*보다 *Liskov 호환*.
+- ***Player가 generator를 보유 = 카드 출처 책임이 Player*** — *덱에서 뽑기*가 자연. 학생 자가 반영.
+- ***Player.name의 invariant = 도메인 객체 분리 vs 검증 제거 트레이드오프*** — 학생이 *YAGNI 선택*도 합리적. 다만 *invariant 손실*은 *기록*해두기.
+- ***String += < buildString/joinToString*** — Kotlin 컨벤션.
+- ***`Generator + CardGenerator + RandomGenerator` 명사 중복 = 추상화 폭증*** — *테스터빌리티 위해 인터페이스* 시도가 *도메인 어휘 흐림*. *Deck 52장 한정 자료구조* 모델이 더 자연.
+- ***match는 참가자 메시지 (1대1 → 1대다 확장 가능)*** — `GameResult(participant, winCount, loseCount, drawCount)` 형태로 *참가자 단위 집계*.
+- ***`Cards(_cards: MutableList<Card>)` 외부 참조 = 방어적 복사 필요*** — `_cards.toMutableList()` 또는 `cards.toList()`.
+- ***Controller가 직접 호출 < Participants 메시지*** — `participants.drawInitial(deck)` 한 줄.
+- ***`MutableMap<Result, Int>` public = invariant 무방비*** — *count by result*는 *외부에서 변경 불가*하게.
+- ***`Participants.values` 명명 모호 = Map.values 연상*** — `items` 또는 *공개 자체 안 함*(메서드만).
+- ***Deck 메서드명이 동작 모호 = 카드 미리 보유 + 생성자/팩토리가 자연***.
+- ***DealerTest 함수명 = "상태 라벨"보다 "시나리오 + 결과"*** — *테스트 = 사양서*.
+- ***DeckTest 한 테스트에 모든 요구사항 X*** — *덱이 가지는 특징을 테스트할 수 있는 정도 환경 준비*. 통합 테스트 ≠ 단위 테스트.