oh-my-oop 0.2.0

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

@@ -0,0 +1,188 @@
+# PR #103 — [블랙잭 2단계] 해나 미션
+
+- **Reviewee:** [@hxeyexn](https://github.com/hxeyexn)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/103
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @laco-dev (페로로)
+- **라인 코멘트:** 10 스레드 / 20 코멘트 — 짧은 PR + 핵심 안티패턴 진단 다수
+
+## 잘한 점 (설계 관점)
+
+- **플레이어 + 베팅 금액 동시 입력 자가 반영** — 페로로의 *"플레이어를 준비하면서 배팅 금액을 입력받을 수 있지 않을까요?"* 진단 자가 반영 (커밋 `14775ee`). PR #85·#88·#90 와 같은 결.
+- **딜러 16점 룰 명시 자가 반영** — 페로로의 *"딜러도 16점 이하라면, 16점을 넘을 때 까지 계속해서 뽑아야 합니다."* 진단 자가 반영 (커밋 `55d2dcf`). 1단계 룰 보강.
+- **딜러 베팅 금액 제거 자가 반영** — 페로로의 *"배팅 금액은 플레이어에게만 있는 개념이 아닐까요? 딜러의 입장에서는, 배팅을 하지 않으니까요"* 진단 자가 반영 (커밋 `a69ea03`). *Dealer ≠ Player 도메인 구분 명시*. PR #103 (해나) 의 *Player(name, betAmount) vs Dealer(name)* 비대칭 정공. PR #133·#85·#136 와 같은 결.
+- **수익률 계산 책임 = `FinalWinning`** 자가 결정 — 페로로 메타 질문 *"수익률은, 게임 결과인 FinalWinning이 계산하는 것과 Participants가 계산하는 것 중 누가 하는 것이 적절하다고 생각하시나요?"* 에 학생 자가 답변: *"FinalWinning이 좀 더 적절한 것 같습니다! Participants와 FinalWinning 중 고민 했었는 데 FinalWinning으로 수익률을 계산하는 것을 옮겨보니 코드가 간결해졌다는 걸 느꼈습니다."* (커밋 `2253b73`). **자가 결정 + 근거 명시 모범**.
+- **상태 패턴 도입 자가 학습 (CardHand 분리)** — 페로로의 *"플레이어는 스테이 상태를 선언하면, 카드를 더 이상 뽑을 수 없어요. 이 개념을 구현 해보시면 좋을 것 같습니다."* + 1단계 코멘트 인용 *"플레이어와 딜러가 카드 상태랑 강하게 결합되어 있다 ... 플레이어가 스테이가 될 수 있다는 상태가 고려한다면 도움이 좀 될 것 같습니다."* 후속 반영 (커밋 `e0f3ef7`). *학생 자가 인용으로 1단계 진단 의식 명시*.
+- **Bust 양측 처리 + 딜러 Bust 룰 자가 반영** — 페로로의 *"내가 버스트라면 상대의 패와 상관없이 무조건 패배합니다."* 진단 학생 자가 정리: *"- 플레이어가 Bust라면 딜러의 패와 상관없이 무조건 패. - 딜러가 Bust이고, 플레이어가 Bust가 아니라면 딜러 패"* 룰 추가 (커밋 `68dd994`). **블랙잭 룰 정확성 자가 학습 모범**. PR #128·#135·#114·#136 와 같은 결.
+- **`calculatePlayerProfit` MutableMap 인자 제거 자가 반영** — 페로로 진단 *"메서드를 분리하는 과정에서 놓친 것 같습니다. profit 파라미터 삭제하였습니다!"* (커밋 `4503d84`). *불필요한 가변 인자 제거*.
+- **`CardFixture` 활용 + 꼼꼼한 테스트** — 페로로 자가 칭찬 다수 (Fixture 좋습니다 + 꼼꼼한 테스트 좋았습니다).
+
+## 못한 점 (설계 관점)
+
+### 1. `RandomDeck` 의 `_cardDeck` + `cardDeck` 이중 표현 — *불필요한 중복*
+
+학생 코드 (추정):
+```kotlin
+class RandomDeck {
+    private val _cardDeck: List<Card> = ...
+    private val cardDeck: List<Card> = ...
+}
+```
+
+페로로 (RandomDeck.kt:6 — 미해결): *"이 두개의 카드덱은 어떤 차이가 있나요?"*
+
+학생: *"_cardDeck에는 실제 카드 덱을 저장하고, cardDeck을 이용해 클래스 외부에서는 카드 덱 데이터를 읽을 수는 있지만, 직접 수정할 수는 없게 하려고 했었습니다. 리팩터링 하다보니 cardDeck을 외부에서 사용할 때가 없어졌는 데 추후에 사용할 일이 있을까봐 일단은 private으로 설정해뒀습니다! 혹시 제가 잘못 이해하고 있는 부분이 있을까요..?"*
+
+페로로 후속: *"둘 다 모두 `List<Card>` 타입이고, 따로 두개가 나뉘어진 이유가 모르겠네요!?"*
+
+→ **`_cardDeck` (private) + `cardDeck` (private) 이중 표현 = *불필요한 중복***. *Kotlin backing field 패턴 = `private val _x + val x: get() = _x.toList()`*. *둘 다 `List<Card>`* 면 *backing field 아닌 단순 중복*. *YAGNI 위반*. PR #88 (채드) 의 *부 생성자 미사용 자가 삭제* 와 같은 결.
+
+학생 자가 답변에서 *"추후에 사용할 일이 있을까봐 일단은 private으로 설정해뒀습니다"* = **추측 코딩 신호** — *현재 사용처에서 시작 + 필요 시 추가* 정공.
+
+### 2. `CardHand` *카드 + 상태 결합 강도* — 1단계 진단의 일부 후속 반영
+
+페로로 (CardHand.kt:31 — 미해결): *"플레이어는 스테이 상태를 선언하면, 카드를 더 이상 뽑을 수 없어요. 이 개념을 구현 해보시면 좋을 것 같습니다."*
+
+학생 자가 답변: *"> 지난번 플레이어와 딜러가 카드 상태랑 강하게 결합되어 있다는 말을 드렸는데, > 플레이어가 스테이가 될 수 있다는 상태가 고려한다면 도움이 좀 될 것 같습니다. 이와 관련해 step1에서 남겨 주신 조언 참고해서 피드백 반영해보았습니다!"* (커밋 `e0f3ef7`).
+
+→ **1단계 진단 인용 = 학습 모범**. *학생이 1단계 페로로 코멘트 직접 인용 + 의식적 반영*. PR #128·#135·#108·#133·#136 와 같은 결의 *진단 인식 + 후속 반영*.
+
+다만 *상태 분리 결과 코드는 미공개* — *Hand 자체에 stay boolean / sealed state / enum* 등 표현 방식이 *PR #85·#136·#152·#133·#131* 의 다양한 트레이드오프 중 어느 것인지 확인 불가.
+
+### 3. `Participants.calculatePlayerProfit(MutableMap)` 인자 — *부수효과 메서드 시그니처*
+
+페로로 (Participants.kt — 미해결): *"calculatePlayerProfit() 라는 함수 이름으로만 보면, 수익률을 반환하는 역할을 잘 수행하고 있어요. 그런데 MutableMap을 굳이 파라미터로 넣어줄 필요가 있는 것일까요?"*
+
+학생 자가 답변 (커밋 `4503d84`): *"메서드를 분리하는 과정에서 놓친 것 같습니다. profit 파라미터 삭제하였습니다!"*
+
+→ **MutableMap 인자 = 부수효과 메서드 시그니처**. *calculateXXX 가 반환 + 외부 가변 Map 변경* 동시 책임. *PR #85 (하디 2단계) 의 페로로 calculateFinalProfits Unit 반환 진단* 과 같은 결. *학생 자가 후퇴 모범*.
+
+### 4. *`is Bust` 의 *상대 패와 무관하게 패배* 룰 누락 (자가 수정 전)*
+
+페로로 (Role.kt — 미해결, 자가 반영 후): *"내가 버스트라면 상대의 패와 상관없이 무조건 패배합니다."*
+
+학생 자가 정리:
+```
+- 플레이어가 Bust라면 딜러의 패와 상관없이 무조건 패
+- 딜러가 Bust이고, 플레이어가 Bust가 아니라면 딜러 패
+```
+
+(커밋 `68dd994`).
+
+→ **블랙잭 룰 정확성 = Bust 우선순위 + 비대칭**. *플레이어 Bust → 무조건 Lose*, *딜러 Bust + 플레이어 비Bust → 플레이어 Win*. *양측 Bust → 플레이어 Lose (카지노 룰)*. PR #128·#135·#114·#125·#108·#133·#132·#136 와 같은 결.
+
+### 5. `Fixture` 직접 활용 미숙 — 학생 자가 질문
+
+페로로 (RoleTest.kt:159 — 미해결): *"꼼꼼한 테스트 좋았습니다. Fixture를 조금 더 활용한다면, 이렇게도 생성해 볼 수 있어요. `val dealer = Dealer(HEART_TEN, HERART_SEVEN); val player = Player(HEART_TEN, HEART_FIVE)`"*
+
+학생 답변: *"감사합니다! 위 예시가 아직 잘 이해가 되지 않는 데 혹시 조언이나 자료를 좀 더 얻을 수 있을까요..? 🥲"*
+
+→ **Fixture = 생성자 인자 가변 + 매 테스트 다른 카드 조합**. *Dealer(card1, card2)* 같은 *생성자 카드 인자*가 *vararg 또는 List 인자*로 *유연한 테스트 데이터*. *현재 학생은 fixture 의미 학습 진행 중*. PR #90·#133·#136 의 *Fixture 활용 패턴* 과 비교: PR #103 은 *학습 진행 중*.
+
+### 6. `BlackJack` controller 가 *플레이어 준비 + 게임 진행* 책임 — *분리 부재 신호*
+
+페로로 (BlackJack.kt — 첫 두 코멘트): *플레이어 준비 + 배팅 금액 입력 + 16점 룰* 모두 *Controller 의 직접 책임*. *Game 도메인 객체 분리 부재*. PR #131·#132·#136·#152 와 같은 결의 *Controller god-object* 변형.
+
+학생 후속 반영으로 *플레이어 + 베팅 동시 입력*은 *생성 시점 응집*. 다만 *게임 진행 (딜러 16점 룰) 가 Controller 안*인지 *Dealer/Game 객체 안*인지 *코드 미공개*.
+
+### 7. `RandomDeck` *naming* — *deck = 셔플 결과 vs 셔플 방식*
+
+→ **`RandomDeck` = *셔플된 덱 = 랜덤 카드 시퀀스***. *덱 = 카드 모음 + 셔플 = 랜덤 순서* 라면 *Deck 만으로 충분*. *RandomDeck* 이 *고정 순서 Deck* 와 *대비 표현* 의도라면 *전략 패턴 (ShuffleStrategy)* 이 정공. PR #108·#133·#136·#93 의 *ShuffleStrategy / DeckManager interface* 와 같은 결.
+
+### 8. *수익률 계산 책임의 두 후보 (Participants vs FinalWinning) 자가 결정 — 근거 명시*
+
+페로로 메타 질문 → 학생 자가 결정 + 근거: *"FinalWinning으로 수익률을 계산하는 것을 옮겨보니 코드가 간결해졌다는 걸 느꼈습니다."*
+
+→ **결정 근거 = "코드 간결성"**. *PR #131·#132·#108·#133·#85 의 *수익률 책임 위치 토론* 과 같은 결*. 다양한 선택지 (Participant 자기 책임 vs Result 객체 응집)*. *해나 = FinalWinning 응집* 선택. PR #85 (하디) 의 *PlayerResult.profit by lazy* 와 같은 결.
+
+### 9. `BlackJack.kt:112` — Controller 직접 딜러 룰 보유
+
+페로로 (BlackJack.kt:112 — 미해결): *"딜러도 16점 이하라면, 16점을 넘을 때 까지 계속해서 뽑아야 합니다."*
+
+학생 후속 반영: *16점 룰 추가*.
+
+→ **딜러 룰 = Dealer 자기 책임 vs Controller 명령** — *Dealer.shouldDrawCard() = score <= 16* 메시지가 자연. PR #131·#132·#136 와 같은 결. *현재 코드 미공개* — *룰 위치 정확 확인 불가*.
+
+## 리뷰어 의견 요지
+
+- **플레이어 준비 + 베팅 금액 동시 입력** — *생성 시점에 모든 정보 응집*.
+- **딜러 = 베팅 안 함, 도메인 구분** — *Player ≠ Dealer 의 멤버 차이*.
+- **딜러 16점 이상까지 hit** — *블랙잭 룰 정확성*.
+- **상태 패턴 = 카드와 상태 결합 해소** — *플레이어 stay 상태 + 카드 차단*.
+- **수익률 계산 위치 = 메타 질문으로 학생 자가 결정 유도** — *Participants vs FinalWinning*.
+- **Bust 무조건 패배 = 상대 패 무관** — *블랙잭 룰 정확성*.
+- **MutableMap 인자 = 부수효과 시그니처** — *calculate 메서드 반환 + 외부 변경* 분리.
+- **`_cardDeck` + `cardDeck` 이중 표현 = 불필요한 중복 + 추측 코딩** — *YAGNI 위반*.
+- **Fixture 활용 + 생성자 가변 인자** — *유연한 테스트 데이터*.
+
+## 대표 인용
+
+**페로로 (Bust 무조건 패배, Role.kt):**
+> 내가 버스트라면 상대의 패와 상관없이 무조건 패배합니다.
+
+**페로로 (수익률 책임 위치 메타 질문, Participants.kt):**
+> 수익률은, 게임 결과인 FinalWinning이 계산하는 것과 Participants가 계산하는 것 중 누가 하는 것이 적절하다고 생각하시나요?
+
+**페로로 (딜러 베팅 도메인 구분, Dealer.kt):**
+> 배팅 금액은 플레이어에게만 있는 개념이 아닐까요?
+> 딜러의 입장에서는, 배팅을 하지 않으니까요
+
+**페로로 (1단계 진단 연장, CardHand.kt:31):**
+> 플레이어는 스테이 상태를 선언하면, 카드를 더 이상 뽑을 수 없어요.
+> 이 개념을 구현 해보시면 좋을 것 같습니다.
+
+**페로로 (이중 표현 무의미, RandomDeck.kt:6):**
+> 둘 다 모두 `List<Card>` 타입이고, 따로 두개가 나뉘어진 이유가 모르겠네요!?
+
+**페로로 (Fixture 활용 권고, RoleTest.kt:159):**
+> 꼼꼼한 테스트 좋았습니다.
+> Fixture를 조금 더 활용한다면, 이렇게도 생성해 볼 수 있어요.
+> ```kotlin
+> val dealer = Dealer(HEART_TEN, HERART_SEVEN)
+> val player = Player(HEART_TEN, HEART_FIVE)
+> ```
+
+**학생 자가 답변 (수익률 책임 자가 결정, Participants.kt):**
+> FinalWinning이 좀 더 적절한 것 같습니다! Participants와 FinalWinning 중 고민 했었는 데 FinalWinning으로 수익률을 계산하는 것을 옮겨보니 코드가 간결해졌다는 걸 느꼈습니다. 감사합니다!
+
+**학생 자가 답변 (1단계 진단 인용 + 후속 반영, CardHand.kt:31):**
+> > 지난번 플레이어와 딜러가 카드 상태랑 강하게 결합되어 있다는 말을 드렸는데,
+> > 플레이어가 스테이가 될 수 있다는 상태가 고려한다면 도움이 좀 될 것 같습니다.
+>
+> 이와 관련해 step1에서 남겨 주신 조언 참고해서 피드백 반영해보았습니다!
+
+**학생 자가 답변 (Bust 룰 정확성 자가 정리, Role.kt):**
+> ```
+> - 플레이어가 Bust라면 딜러의 패와 상관없이 무조건 패
+> - 딜러가 Bust이고, 플레이어가 Bust가 아니라면 딜러 패
+> ```
+> 피드백 주신 내용 참고해 위의 두가지 조건 추가하였습니다!
+
+**학생 자가 답변 (추측 코딩 자가 인식, RandomDeck.kt:6):**
+> _cardDeck에는 실제 카드 덱을 저장하고, cardDeck을 이용해 클래스 외부에서는 카드 덱 데이터를 읽을 수는 있지만, 직접 수정할 수는 없게 하려고 했었습니다. 리팩터링 하다보니 cardDeck을 외부에서 사용할 때가 없어졌는 데 추후에 사용할 일이 있을까봐 일단은 private으로 설정해뒀습니다!
+
+## 얻은 교훈
+
+1. ***플레이어 준비 + 베팅 금액 동시 입력 = 생성 시점에 모든 정보 응집***. PR #85·#88·#90·#108·#133 와 같은 결. *Player(name, betAmount) 생성 시점에 한 번에 받음*.
+
+2. ***딜러 ≠ 플레이어 = 도메인 멤버 차이***. *Dealer 는 베팅 안 함 → betAmount 미보유*. *Player 와 Dealer 의 비대칭이 도메인 룰 표현*. PR #133·#85·#136 와 같은 결.
+
+3. ***블랙잭 Bust 룰 = "무조건 패배 (상대 패 무관)"*** = *카지노 룰 정확성*. *플레이어 Bust → Lose 즉시*, *양측 Bust → 플레이어 Lose*, *딜러 Bust + 플레이어 비Bust → 플레이어 Win*. PR #128·#135·#114·#125·#108·#133·#132·#136·#90·#88·#85 와 같은 결.
+
+4. ***메타 질문으로 자가 결정 유도 = 학습 모범***. *페로로의 "Participants vs FinalWinning 중 누가 적절한가?"* 메타 질문 → *학생 자가 답변 + 근거 명시*. *맞고 틀림 X, 트레이드오프*. PR #131·#136·#88 와 같은 결의 reviewer 스타일.
+
+5. ***1단계 진단 인용 + 후속 반영 = 진단 인식 학습 모범***. *학생이 1단계 페로로 코멘트 직접 인용*. *진단 누적 + 후속 회기 회피*. PR #128·#135·#108·#133·#136 와 같은 결.
+
+6. ***`_cardDeck` + `cardDeck` 이중 표현 = 추측 코딩 + YAGNI 위반***. *Kotlin backing field 패턴 = `private val _x` + `val x: get() = _x.toList()`*. *둘 다 private + 동일 타입* 이면 *불필요한 중복*. *현재 사용처 시작 + 필요 시 추가* 정공.
+
+7. ***`calculatePlayerProfit(MutableMap)` 인자 = 부수효과 메서드 시그니처***. *PR #85 (하디 2단계) 의 calculateFinalProfits 진단* 와 같은 결. *calculate = 반환*, *부수효과 ≠ calculate 어휘*. *학생 자가 후퇴*.
+
+8. ***Fixture 활용 + 생성자 가변 인자 = 유연한 테스트 데이터***. *PR #90 (케이엠) 의 fixture + CsvSource* 와 같은 결. *현재 학생은 학습 진행 중* — *fixture 의미 자가 질문*.
+
+9. ***`RandomDeck` naming = ShuffleStrategy interface vs 클래스 직접*** = *전략 패턴 정공 vs 단일 구현*. PR #108·#133·#136·#93 의 *ShuffleStrategy / DeckManager interface* 와 *반대 트레이드오프*. *테스트 시 결정적 카드 시퀀스 필요* 시 *전략 패턴*이 정공.
+
+10. ***학생 자가 답변에 커밋 SHA 첨부 = 진단 → 후속 반영 흐름 명시***. *14775ee, 55d2dcf, e0f3ef7, a69ea03, 2253b73, 4503d84, 68dd994* 등 다수. *학습 가시화 패턴 일관성*. PR #128·#135·#108·#133·#88·#136 와 같은 결.
+
+11. ***리뷰어 메타 질문 + 학생 자가 결정 + 근거 명시 + 코드 간결성 trade-off 명시 = 학습 모범***. *PR #103 은 짧지만 깊은 토론* — *짧은 PR 이라도 학습 가시화 가능*. PR #131·#136 와 같은 결의 *짧은 PR + 풍부한 자가 학습*.
+
+12. ***수익률 계산 책임 후보 (Participants vs FinalWinning) = 트레이드오프 명시***. *Participants 자기 책임 (Tell-Don't-Ask) vs Result 객체 응집*. *둘 다 합리*. *학생 자가 결정 근거 = 코드 간결성*. *결정의 근거 명시 자체*가 *학습 가치*. PR #85·#108·#131·#132·#133·#136·#152 와 같은 결의 *책임 위치 토론*.

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

@@ -0,0 +1,301 @@
+# PR #81 — [블랙잭 1단계] 해나 미션
+
+- **Reviewee:** [@hxeyexn](https://github.com/hxeyexn)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/81
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 19 / 리뷰이 11)
+
+## 잘한 점 (설계 관점)
+
+- **`CardHandState` enum + `precondition` 속성** — 상태별 임계점 상수화 (후속 반영).
+- **`PlayerName` 원시값 포장**.
+- **`abstract class Role` + `Player`/`Dealer`** + 후속에 `addInitialCards` 추상 공통화.
+- **`CardGenerator` 인터페이스 + `RandomCardGenerator`/`ExplicitCardGenerator`** — 테스트 fake 분리.
+- **`PlayerWinning.judgeDealerWinningResult` (groupingBy + eachCount + reverse) — 역집계** (후속 반영).
+- **후속 반영 — Ace 1점 기본 + 11 검토 룰 변경 / Singleton Deck → CardIndex reset / Shape/Number UI → OutputView / canDraw() 상태 반환 / Referee 제거 + Dealer로 책임 이전**.
+
+## 못한 점 (설계 관점)
+
+### 1. `CardShape.shape: String` UI 표현
+
+```kotlin
+enum class CardShape(val shape: String) { HEART("하트"), CLOVER("클로버"), ... }
+```
+
+리뷰어: "*"하트", "클로버" 는 UI 로직이 아닐까요? 가령 `♤ ♠` 처럼 출력해야 한다면 도메인 모델의 수정이 불가피*합니다." — **12개 PR 연속 enum UI value**.
+
+### 2. `CardNumber.JUMP` — JACK 오타
+
+```kotlin
+enum class CardNumber(val number: Int, val output: String = number.toString()) {
+    ACE(11, "A"), TEN(10), KING(10), QUEEN(10),
+    JUMP(10),       // ⚠ JACK 오타
+}
+```
+
+리뷰어: "*플레잉 카드에서 J는 JACK 입니다!*" — *도메인 어휘 정확성*. `JUMP`는 *도메인 부재*. **JACK 명사 모름 = 도메인 조사 부족 신호**.
+
+### 3. `CardNumber.ACE.number = 11` 기본값
+
+→ PR #119·#29·#112·#17과 동일. *Ace 1 기본*이 도메인 룰. 학생 후속 인정: "*제가 규칙을 잘못 이해하고 있었네요* 🥲".
+
+### 4. `CardDeck` Singleton + 게임 단발
+
+```kotlin
+object CardDeck {
+    private val cardDeck = CardShape.entries.flatMap { ... }.shuffled()
+    private var cardIndex = 0
+    fun getRandomCard(): Card = cardDeck[cardIndex++]
+}
+```
+
+리뷰어: "*단 하나만 존재하는 덱이네요* 😱 *게임이 여러 번 진행 되면 어떤 일이 발생할까요?*"
+
+학생 자가 인정: "*플레이어 수를 6명으로 제한해 52장의 카드를 모두 소진할 일이 없다고만 생각했습니다. 게임이 여러 번 진행되었을 때는 고려하지 못했던 것 같습니다..!* CardIndex 를 reset 하는 방식으로 수정해보았습니다." — **Singleton + reset** = *상태 가변 + Singleton 결합 = 더 복잡*. *class Deck + 매 게임 새 인스턴스*가 정답. 학생의 reset 패치는 *Singleton 유지의 미봉책*.
+
+### 5. `CardHand.sum()`의 `while + 차감 + count Ace`
+
+```kotlin
+fun sum(): Int {
+    var aceCount = hand.count { it.number == CardNumber.ACE }
+    var tempSum = hand.sumOf { it.number.number }
+    while (aceCount >= MIN_ACE_COUNT && tempSum > BLACK_JACK) {
+        aceCount--
+        tempSum -= SUBTRACTION_BETWEEN_MAX_AND_MIN
+    }
+    return tempSum
+}
+```
+
+리뷰어: "*블랙잭에서 A 카드의 기본 점수는 1점입니다.* 아래 점수 계산 규칙을 참고해보시고, *어떻게 수정할 수 있을지 고민 해보세요* :) > *에이스 카드가 포함되어 있을 때, 카드들의 점수 합계가 11점보다 낮다면 보너스 점수 10점을 획득한다.*"
+
+→ PR #112·#29·#33·#10·#17·#119와 동일한 *while + 차감* 패턴. *단일 룰*로 단순화. 학생 후속 반영.
+
+### 6. `CardHand.addNewCard()`이 `CardDeck.getRandomCard()` 직접 호출
+
+```kotlin
+fun addNewCard() {
+    _hand.add(CardDeck.getRandomCard())   // ⚠ Singleton 직접 호출
+}
+```
+
+리뷰어: "*무엇이 들어올지 모르는 카드를 뽑게 되는 행위는 테스트가 가능한 구조*일까요?" — *Singleton 의존 = 테스트 격리 불가*. `addNewCard(card: Card)` 또는 `addNewCard(generator: CardGenerator)`. 학생 후속: `ExplicitCardGenerator` 도입.
+
+### 7. `Player.getState()` *Bust + BlackJack + 카드 합* — *Hit/Stay 누락*
+
+```kotlin
+override fun getState(): CardHandState {
+    val sum = cardHand.sum()
+    return when {
+        sum > BLACK_JACK -> CardHandState.BURST
+        sum == BLACK_JACK -> CardHandState.BLACKJACK
+        else -> CardHandState.STAY        // ⚠ 21 미만이면 무조건 STAY?
+    }
+}
+```
+
+리뷰어: "*플레이어의 상태는 단순히 카드 점수로만 판단할 수 없습니다.* 가령 *21점이 넘지 않더라도 플레이어가 더 뽑겠다고 한다면 HIT 상태가 되고, 그만 뽑겠다고 하면 STAY 상태*가 됩니다. *상태를 반환하는 방식과 상태를 내부적으로 변경 가능하도록 가지고 있도록 하는 차이*가 있을 것 같습니다. `var state: State; private set`"
+
+→ **상태가 *점수만으로 결정*되지 않음**. *21 미만 + HIT 의사 = HIT*, *21 미만 + STAY 의사 = STAY*. *유저 선택*이 상태 전이의 트리거. 학생 후속: `CardHandState.DRAW_POSSIBILITY`로 *카드 더 받을 수 있음*만 표현, *Hit/Stay 결정*은 외부에서.
+
+### 8. `BLACK_JACK = 21` 상수가 *여러 곳 중복*
+
+리뷰어: "*`블랙잭 = 21` 이라는 값이 여러군데서 재사용이 되고 있어요.* 만약 *블랙잭 점수가 22점으로 바뀐다면 악몽이 벌어지지 않을까요?*" — *도메인 상수의 단일 정의*. 학생 후속: `CardHandState.BLACKJACK.precondition`으로 *enum 속성*에 통합.
+
+### 9. `Referee` 정적 비교자 → 학생 Dealer로 이전
+
+리뷰어: "*승부를 판단하는 로직은 참가자가 스스로 할 수 있지 않을까요?* *Referee 라는 객체는 단순히 함수를 분리한 것으로밖에 보이지 않아, 클래스로서의 목적이 명확하지 않습니다.* WinningResult를 만들어 내기에 적절한 위치는 없을까요?"
+
+학생 자가 인정: "*클래스의 역할과 책임에 대해 다시 한 번 생각해 볼 수 있게 질문 주셔서 감사합니다.* 🙇 *승부를 판단하는 로직은 Dealer의 책임이라는 판단*이 서서 *Dealer로 해당 로직을 이동*시켰습니다."
+
+→ **Referee → Dealer 이전은 *PR #28·#63 권고와 부분 일치 + 참가자 자율성과 부분 어긋남***. *Dealer가 비교자*는 *현실 비유 충실*, *Tell-Don't-Ask는 player.match(other)*. 학생은 *중간 단계* 도달.
+
+### 10. `PlayerWinning(result: Map<...>)` data class — *역할 모호*
+
+```kotlin
+data class PlayerWinning(val result: Map<PlayerName, WinningResultStatus>)
+data class DealerWinning(val result: Map<WinningResultStatus, Int>)
+```
+
+리뷰어: "*객체 이름만 본다면, 플레이어 하나의 승부 결과를 가지고 있을 것처럼 느껴지는데, 실제로는 무엇을 하는지 잘 모르겠어요.* *이 클래스가 정말 필요한 것일까요?*"
+
+학생 자가 변호: "*data class 내 딜러의 승부를 판단하는 책임은 불필요하지만, PlayerWinning이라는 class 자체는 플레이어들의 결과를 담고 있어야 하기 때문에 필요하다고 생각*합니다..!"
+
+→ **명사 PlayerWinning vs 실제 보유 (Map<Player, Status>) 의미 불일치**. *PlayerWinning = 플레이어 하나의 결과* 직관 vs *실제 = 다수 플레이어의 결과 묶음*. `PlayersResult` 또는 *Map 노출* 자체가 자연. 단수/복수 명명 정확성.
+
+### 11. `DealerWinning.result: Map<WinningResultStatus, Int>` value 의미 모호
+
+```kotlin
+data class DealerWinning(val result: Map<WinningResultStatus, Int>)
+```
+
+리뷰어: "*result 에 담겨있는 value 값이 무엇인지 알기 어려워 보입니다.* 적절한 메소드를 통해 메시지를 전달 해보면 어떨까요? `fun getWinningCount(): Int { ... } fun getDrawCount(): Int { ... }`" — *Map 자료구조 그대로 노출* < *메서드로 의미 명시*. *호출자가 Map["WIN"] 같은 키 추측* 회피.
+
+후속 댓글: "*이 의문이 해결되지 않았어요. 아직 `getFinalResult()` 의 반환 타입이 무엇인지 모르지 않을까요?*" — 학생이 *getFinalResult(): Map<WinningResultStatus, Int>* 형태로 *그대로 반환*. 리뷰어는 *반환 타입 자체가 의미*임을 재강조.
+
+### 12. `BlackJack.runPlayerPhase`의 *상태 판단 + 입력 + 분기 한 줄*
+
+```kotlin
+private fun runPlayerPhase(it: Player) {
+    while (it.getState() == CardHandState.STAY && inputView.readIsHit(it)) {
+        it.runPhase()
+        outputView.printPlayerCardHand(it)
+    }
+}
+```
+
+학생 자가 인정: "*하지만 초반 설계처럼 runPhase의 파라미터 값에 HIT 여부를 넣고, while(runPhase(inputView.readIsHit))의 형태로 컨트롤러에서 사용하면 Player의 카드 패가 Black Jack 이거나 BUST 라도 플레이어에게 카드를 더 받겠냐는 질문을 한번 더 출력*하게 됩니다."
+
+리뷰어: "*블랙잭 게임에서 STAY는 카드를 더이상 뽑지 않겠다를 선언한다는 의미*입니다. *블랙잭 도메인이 어려워 이 부분은 잘못 알고 계신 것 같네요.* [...] *카드를 더 뽑을 수 있는지 여부를 묻는 로직*이 보이지 않는데요. *Input 이전에 플레이어 혹은 딜러가 카드를 더 뽑을 수 있는지를 물어봐야 하지 않을까요?* `player.canDraw() && askDraw(player)`"
+
+→ **블랙잭 STAY 의미 오해**: 학생의 `CardHandState.STAY`는 *21 미만 일반 상태*로 사용. 룰: *STAY = 사용자가 그만 뽑겠다 선언*. 학생 자가 인정 후 `canDraw()` 메서드 도입. PR #28·#114·#10과 같은 결.
+
+### 13. `runPhase()` 명명 — *카드 뽑는 행위가 phase?*
+
+리뷰어: "*또한 `runPhase` 라는 이름이 무엇을 의도하는지 잘 모르겠습니다. 단순하게 카드를 뽑는다는 행위로 나타내고 싶은게 아닌가요?* `drawTo(...)`" — *추상 명사*(`runPhase`/`processTurn`/`step`)보다 *구체 행위*(`drawCard`/`receiveCard`). PR #29·#92와 같은 결.
+
+### 14. `BlackJack.cardDeck = CardDeck.cardDeck` — 클래스 레벨 + Singleton 참조
+
+```kotlin
+class BlackJack(...) {
+    private val cardDeck = CardDeck.cardDeck    // ⚠ 멤버 + Singleton 참조
+}
+```
+
+리뷰어: "*딜러와 플레이어는 지역변수로 준비가 되는데 덱은 클래스 레벨에서 생성을 하는 이유는 무엇일까요?*" — **일관성 누락**. *한 게임 = 한 인스턴스*면 *덱도 지역 변수*. *Singleton 잔재*가 *클래스 레벨* 보유로 드러남.
+
+### 15. `Role`이 `CardGenerator` 의존 — Deck이 아닌 Generator
+
+```kotlin
+abstract class Role(open val name: PlayerName, open val cardHand: CardHand) {
+    fun addInitialCards(cardGenerator: CardGenerator) {
+        repeat(INITIAL_CARDS_COUNT) { cardHand.addNewCard(cardGenerator) }
+    }
+    fun runPhase(cardGenerator: CardGenerator) { ... }
+}
+```
+
+리뷰어: "*참가자가 CardGenerator와 협력하는게 자연스러운 흐름인가요? 아니면 CardGenerator와 협력하는게 자연스러운 흐름인가요?* *덱을 통해 받지 않은 이유가 있나요?* *CardDeck이 고도화가 되고 역할이 만들어지지 않고, 엉뚱한 다른 객체가 만들어진 것 같아서요.*" — **`Deck`이 *카드 보유자 + 뽑기*면, `Generator`는 *Deck의 내부 구현* 또는 *Deck 생성용*. Role이 직접 Generator 의존 = *Deck 추상화 누수***. PR #24·#10·#29와 같은 결.
+
+### 16. `Player.getState`가 *cardHand.sum()* 외부 계산
+
+```kotlin
+data class Player(...) : Role(...) {
+    override fun getState(): CardHandState {
+        val sum = cardHand.sum()
+        return when { ... }
+    }
+}
+```
+
+리뷰어: "*CardHand가 CardHandState를 가지고 있어야 자연스럽지 않을까요??* 이미 *CardHand가 블랙잭 도메인에 강하게 결합*되어 있다면, *스스로 상태를 가지고 판단*하도록 하는게 어떨까요?" — *Player가 cardHand.sum()* + 분기 = *Tell-Don't-Ask 변형 위반*. `cardHand.getState()`가 자연.
+
+### 17. `Dealer.canDraw()` — Player와 다른 메서드명
+
+```kotlin
+data class Dealer(...) : Role(...) {
+    fun canDraw(): Boolean = this.getState() == CardHandState.HIT
+}
+```
+
+리뷰어: "*이 함수는 플레이어와 딜러가 모두 동일하게 가지고 있다면, 추상 함수로 만들어 볼 수 있지 않을까요?*" — `canDraw()`가 *공통 행위*면 `Role.canDraw(): Boolean` 추상. *Dealer 단독*은 *추상화 누락*.
+
+### 18. `Participants.getPlayerResult` + 별도 `getDealerResult` — 결과 객체 분산
+
+```kotlin
+data class Participants(val dealer: Dealer, val players: Players) {
+    fun getPlayerResult(): Map<PlayerName, Int> = ...
+    // getDealerResult가 별도
+}
+```
+
+리뷰어: "*결과를 만들어내는 동작이 왜 따로따로 존재하는지 의아*합니다. *플레이어 결과와 딜러 결과를 모두 가지는 게임 결과를 생성하도록 만들 수 있지 않을까요?* *그 역할은 누가 해야 적절할까요?*" — *GameResult* 단일 객체에 *Player + Dealer 결과*. PR #112·#135·#92와 같은 결.
+
+### 19. `CardHandTest`에 *명시 deck + 합산 + Ace 보정* 다중 검증
+
+```kotlin
+class CardHandTest {
+    // 딜러나 플레이어 카드 패의 합을 구하는 동작은 완전히 같다.
+    private val explicitCardDeck = listOf(... 7장 ...)
+    @Test fun `...`() { ... }
+}
+```
+
+리뷰어: "*무엇을 테스트 하고 싶은 걸까요??* 🤔" / "*이 규칙으로 시나리오를 다시 고려 해보셨을까요? 테스트가 너무 복잡하게 판단이 되는 것 같습니다.* *TDD로 구현한다*..."
+
+→ **테스트 의도 불명** + **시나리오 복잡 = TDD 사이클 위반**. *한 테스트 = 한 시나리오*가 *Red 단계의 명확성*. *7장 fixture*는 *여러 시나리오가 한 데이터에 섞임*.
+
+### 20. `DealerTest`에 *테스트 로직 보유*
+
+```kotlin
+@Test fun `...`() {
+    if (dealer.getState() == CardHandState.HIT) {     // ⚠ 테스트에 if 분기
+        // 한 장 더 뽑기 검증
+    }
+}
+```
+
+리뷰어: "*테스트 코드에 로직을 포함하면 안됩니다.* 한 장을 더 뽑는다는 메시지는 *`canDraw()` 를 통해 판단해야 하지 않을까요?*" — *테스트 = 명세*. *if 분기는 두 가지 시나리오를 한 테스트에 담음*. *시나리오 분리*가 정답.
+
+## 리뷰어 의견 요지
+
+- ***enum UI value (12개 PR 연속)***.
+- ***JACK 오타 = 도메인 어휘 부정확***.
+- ***Ace 1 기본 (학생 자가 인정)***.
+- ***Singleton Deck + reset = 미봉책*** — class + 매 게임 새 인스턴스.
+- ***while + 차감 Ace 보정 < 단일 룰***.
+- ***CardHand가 Singleton Deck 직접 호출 = 테스트 불가***.
+- ***Player 상태 = 점수 외 유저 선택 결합*** — HIT/STAY는 의지의 결과.
+- ***`BLACK_JACK = 21` 상수 중복*** — enum 속성으로 단일 정의.
+- ***Referee → Dealer 이전은 중간 단계*** — 참가자 자율성이 정답.
+- ***`PlayerWinning(Map<Player, Status>)` 단수/복수 명명 불일치***.
+- ***Map 그대로 노출 < 메서드로 의미 명시***.
+- ***블랙잭 STAY = 그만 뽑겠다 선언*** — 학생 도메인 오해.
+- ***`runPhase` 추상 명사 < `drawCard` 구체 행위***.
+- ***Deck 클래스 레벨 + 참가자 지역 변수 = 일관성 누락***.
+- ***Role이 Generator 직접 의존 = Deck 추상화 누수***.
+- ***`player.getState`가 cardHand.sum() = CardHand가 state 보유 자연***.
+- ***Dealer.canDraw 단독 = 추상화 누락*** — Role.canDraw 추상.
+- ***Player + Dealer 결과 분산 = GameResult 단일 객체***.
+- ***테스트 7장 fixture = 시나리오 다중*** — 한 테스트 한 시나리오.
+- ***테스트 로직 (if 분기) = 시나리오 분리 필요***.
+
+## 대표 인용
+
+> 단 하나만 존재하는 덱이네요 😱 *게임이 여러 번 진행 되면 어떤 일이 발생할까요?*
+> — @laco-dev on `CardDeck.kt`
+
+> 플레이어의 상태는 *단순히 카드 점수로만 판단할 수 없습니다*. 가령 *21점이 넘지 않더라도 플레이어가 더 뽑겠다고 한다면 HIT 상태가 되고, 그만 뽑겠다고 하면 STAY 상태*가 됩니다.
+> — @laco-dev on `Player.kt`
+
+> 승부를 판단하는 로직은 *참가자가 스스로 할 수 있지 않을까요? Referee 라는 객체는 단순히 함수를 분리한 것으로밖에 보이지 않아, 클래스로서의 목적이 명확하지 않습니다.*
+> — @laco-dev on `Referee.kt`
+
+> 참가자가 CardGenerator와 협력하는게 자연스러운 흐름인가요? 아니면 CardGenerator와 협력하는게 자연스러운 흐름인가요? *덱을 통해 받지 않은 이유가 있나요?* CardDeck이 고도화가 되고 역할이 만들어지지 않고, *엉뚱한 다른 객체가 만들어진 것 같*아서요.
+> — @laco-dev on `Role.kt`
+
+> `CardHand가 CardHandState를 가지고 있어야 자연스럽지 않을까요?? 이미 CardHand가 블랙잭 도메인에 강하게 결합되어 있다면, 스스로 상태를 가지고 판단하도록* 하는게 어떨까요?
+> — @laco-dev on `Player.kt`
+
+## 얻은 교훈
+
+- ***enum UI value = 12개 PR 연속 (MCP 룰 후보 최강)***.
+- ***JACK 오타 = 도메인 어휘 정확성 부족 신호*** — *플레잉 카드 룰*을 *코드 작성 전 조사*.
+- ***Singleton Deck + reset = 미봉책*** — *class + 매 게임 새 인스턴스*가 정답. PR #65·#79·#125·#92·#33·#10·#17와 같은 결.
+- ***while + 차감 Ace 보정 = 알고리즘으로 룰 흩뜨림*** — *Ace 1 기본 + 11 검토 단일 룰*. 8개+ PR 연속.
+- ***Singleton Deck을 도메인 메서드가 직접 호출 = 테스트 격리 불가*** — Generator 인터페이스 주입.
+- ***Player 상태 = 점수 + 유저 의지 결합*** — *21 미만 + HIT 의사 = HIT*. *점수만으로 STAY 결정*은 도메인 오해.
+- ***`BLACK_JACK = 21` 상수 중복 = 변경 시 여러 곳 수정*** — enum 속성 또는 단일 정의.
+- ***Referee → Dealer 이전은 중간 단계*** — *Dealer 비교자*는 *현실 비유*, *Tell-Don't-Ask*는 *player.match(other)*. 학생이 *중간 단계 도달*.
+- ***`PlayerWinning(Map<Player, Status>)` 단수/복수 명명 불일치*** — *PlayerWinning = 1인분*인지 *다수의 결과 묶음*인지. *PlayersResult* 같은 *복수형*이 자연.
+- ***Map 자료구조 그대로 노출 < 메서드로 의미 명시*** — `getWinningCount()` / `getDrawCount()`.
+- ***블랙잭 STAY = 그만 뽑겠다 선언, 일반 상태 X*** — *학생 도메인 오해*. **블랙잭 룰 정확 이해가 13개+ PR 반복 권고 (MCP 룰 후보)**.
+- ***`runPhase` 추상 명사 < `drawCard` 구체 행위*** — *동작 = 동사*가 가독성. PR #29·#92와 같은 결.
+- ***Deck 클래스 레벨 + 참가자 지역 변수 = 일관성 누락*** — *Singleton 잔재*가 멤버 보유로 드러남.
+- ***Role이 Generator 직접 의존 = Deck 추상화 누수*** — *Generator는 Deck의 내부 구현*. *Role은 Deck과만 협력*.
+- ***`player.getState`가 cardHand.sum() = CardHand가 state 보유 자연*** — *CardHand가 블랙잭 도메인 결합*되어 있으면 *스스로 상태 판단*.
+- ***Dealer.canDraw 단독 = 추상화 누락*** — `Role.canDraw` 추상.
+- ***Player + Dealer 결과 분산 = GameResult 단일 객체*** — *결과 생성 책임자*는 *진행자(Game)*가 자연.
+- ***테스트 7장 fixture = 시나리오 다중 = TDD Red 단계 명확성 위반*** — *한 테스트 한 시나리오*.
+- ***테스트 로직 (if 분기) = 두 시나리오 한 테스트*** — 분리.