oh-my-oop 0.2.0

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

@@ -0,0 +1,225 @@
+# PR #97 — [블랙잭] 올리브 2단계 미션
+
+- **Reviewee:** [@kimhm0728](https://github.com/kimhm0728) (올리브)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/97
+- **단계:** 2단계
+- **리뷰어:** [@ghojeong](https://github.com/ghojeong) (파이로)
+- **라인 코멘트:** 8 스레드 — *PR 본문 6개 자가 학습 진화 명시 + DM 학습 + 학생 자가 *처음부터 다시 구현 고려* 의문 / 유지보수 > 성능 우선순위 어휘 정점 + static 함수 = 유틸 / 협력 관계 어휘 + public = 메시지 통로 + 분기 N×M = 테스트 부담 = 다형성 도입 시그널 + reviewer 피드백 우선순위 메타 + reviewer 자가 *방향 잡아주지 못한 아쉬움* 어휘*
+- **kimhm0728 양 단계 완성** (1단계 #72 = `controller-classification-criteria` + Jeans 메타 어휘 풍부 PR).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 6개 자가 학습 진화 명시 정점
+
+PR 본문:
+
+> *"## 질문 or 기능 구현 외의 주요한 리팩터링*
+>
+> *1. step1에서 `Lazy Calculation`이라는 키워드를 알려주셨는데요, step2의 수익 계산하는 로직에 적용해보았습니다.*
+>
+> *2. step1 코멘트 중 해당 코멘트는 아직 반영하지 못했습니다 🥲 (...) **초기 설계 자체가 잘못된 것 같아서 미션 끝나면 처음부터 다시 구현할 생각도 하고 있는데요(ㅠㅠ) 이 부분 조언 부탁드릴 수 있을까요?***
+>
+> *3. step1에서 패키지에 대한 얘기를 해주셔서, step2를 진행하면서 적절한 패키지 구조에 대해 고민해보았습니다.*
+>
+> *4. Ace가 11으로 계산되는 경우는 최대 한 번밖에 없더라구요. → `fold` 람다 내에 if 여러개 작성하지 않고 단순화*
+>
+> *5. 테스트 픽스처*
+>
+> *6. step1에 달아둔 질문 링크"*
+
+→ **MCP 룰 `pr-body-restart-from-scratch-consideration`** ⭐⭐⭐ **신규** — *학생 자가 *처음부터 다시 구현 고려* 의문 + reviewer 조언 요청*. PR #154 (`pr-body-restart-from-scratch`)·PR #89 (`student-restart-on-reviewer-request`) 결 합류 누적 3 PR → ***갈아엎기 어휘 누적 3 PR 정점*** (자발 vs 요청 vs 고민).
+
+### 2. 연속 if 없이 가독성 칭찬 (Thread 0·4)
+
+reviewer (Thread 0):
+
+> *"블랙잭 미션에서는 가독성을 헤치는 연속된 조건분기를 없애기 위해, 디자인패턴이나 객체 설계를 조언드리게 되는데, **특별한 디자인패턴 키워드 없이도 연속된 if 문들을 무척 잘 없애주신 것 같습니다.** 👍"*
+
+reviewer (Thread 4):
+
+> *"기존의 연속된 If 문보다 지금이 훨씬 보기편한 것 같습니다. **람다에 집착하지 않고 함수 분리해주셔서 멋집니다.** 👍"*
+
+### 3. Role super 칭찬 (Thread 6)
+
+reviewer: *"게임의 결과를 분기처리하는 핵심 로직에 대한 책임은 Role 이 가져가게 되었군요! **Role 의 로직을 super 의 형태로 재사용할 수 있도록 해주신 점 기발한 것 같습니다.** 👍"*
+
+→ PR #154 (`reviewer-kotlin-tip-vocabulary` final keyword) 결 합류 — Kotlin 어휘.
+
+## 못한 점 (설계 관점)
+
+### 1. 유지보수 > 성능 우선순위 어휘 (Thread 1) — 정점
+
+학생 자가 질문:
+
+> *"`Dealer`의 수익을 구할 때는 기존 코드처럼 `Player`의 수익을 구해서 마이너스 연산만 해주면 되는데, **오히려 코드량이나 연산이 더 많아졌다는 느낌이 들었습니다.** 이에 대해 리뷰어님은 어떻게 생각하시나요?"*
+
+reviewer 정점:
+
+> *"profit, profitByPlayer, gameResult 으로 함수가 쪼개져서, **오히려 각 함수의 역할과 책임이 매우 명확해졌다고 생각합니다.** 각 함수가 무엇을 하고, 무엇을 리턴하고 있는지 올리브도 명확해졌다고 생각하지 않나요? (...) **저는 바뀐 코드가 아름답다는 생각마저 드네요.***
+>
+> *연산이 많아졌다는 의견에 대해서는 저도 동의합니다. **하지만 연산이 많아진 대신 함수의 역할과 책임이 명확해졌고, 이는 더 쉬운 유지보수를 의미합니다. 만약 정 늘어난 연산 때문에 성능 이슈가 생긴다면 캐싱을 하는 객체를 추가하면 됩니다.***
+>
+> *이건 개발팀마다 스타일이 다를 것 같은데, **저는 쉬운 유지보수를 최우선 가치로 개발하고, 성능은 문제가 되었을 경우에만 최적화를 합니다.** 이건 안드로이드 개발자로서의 제 개인 경험인데, **성능이 느려서 문제가 되는 경우보다 유지보수가 어려워서 추가 기능 개발이 느려지는 게 문제가 되는 경우가 훨씬 많았기 때문입니다.**"*
+
+reviewer 추가:
+
+> *"참고로 무엇이 정답이다! 보다는 **내 코드가 더 테스트하기 쉬워졌는가? 이 함수가 무엇을 하는지 더 명확해졌는가? 에 집중해주세요!** 성능도 물론 고려해야할 요소이지만 지금 성능 말고도 할게 많습니다!"*
+
+→ **MCP 룰 `maintainability-over-performance-priority`** ⭐⭐⭐ **신규 정점** — *유지보수 > 성능 우선순위 어휘 + 안드로이드 개발자 경험*. PR #62·#89 (ghojeong reviewer 자가 어휘) 결 합류 누적 3 PR — ***ghojeong reviewer 어휘 정점***.
+
+→ **MCP 룰 `code-judgment-criteria-test-fn-clarity`** ⭐⭐⭐ — *판단 기준 = 테스트하기 쉬워졌는가 + 함수가 무엇을 하는지 명확해졌는가*. PR #47 (`coverage-100-vs-test-meaning`)·PR #89 (`state-pattern-2-criteria`) 결 합류 — *판단 기준 어휘 정점*.
+
+→ **`reviewer-personal-experience-vocabulary`** ⭐⭐ — *안드로이드 개발자 경험* — PR #62 (`reviewer-personal-episode-vocabulary` 사수 멘붕) 결 합류 누적 2 PR — *ghojeong reviewer 어휘*.
+
+### 2. static 함수 = 유틸 / 협력 관계 어휘 (Thread 2) — 정점
+
+학생 자가 질문:
+
+> *"`CardProvider`를 `Hand`의 생성자 파라미터로 전달하기 위해서는, \"Controller -> Players -> Player -> Role -> Hand\"의 흐름으로 전달해주어야 합니다. (...) 초기 설계 자체가 잘못된 것 같아서 미션 끝나면 처음부터 다시 구현할 생각도 하고 있는데요"*
+
+reviewer 정점:
+
+> *"지금은 `Player -> Role -> Hand` 대신에, `Player -> Card` 로 CardProvider 를 넘기고 있군요. CardProvider 가 Card 의 리스트를 제공함에도, **다시 또 Card 가 CardProvider 를 호출하는 static 함수를 가지는 것은 쌍방향으로 의존성이 생기는 것 같아서 요상해보입니다.***
+>
+> *처음부터 다시 구현해보시겠다고 하셨는데, 저는 무척 환영합니다. 저도 그럴 필요성을 동의합니다.*
+>
+> *그에 대한 저의 조언은 현재 companion object 안에 있는 static 함수 중, of 나 from 같은 기본적인 팩토리 함수 외에, **모든 static 함수들을 static 이 아니게 될 수 있도록 적절한 객체에게 할당을 해보시라고 조언드리고 싶습니다. static 으로 선언된 함수는 사실 어느 객체에 있어도 상관없는 유틸 함수라고 생각을 해주셔야 합니다.**"*
+
+학생 자가 답변:
+
+> *"`Card`의 모든 경우의 수를 미리 캐싱해두더라도, `Card`의 생성자는 public으로 열어두어도 괜찮나요? 저는 외부에서 \"캐싱된 Card\"가 아닌 \"별도의 Card 인스턴스\"를 계속 생성하는 것을 막기 위해 private으로 제한해두었는데"*
+
+reviewer 정점:
+
+> *"Card 의 생성자를 public 으로 열어두어야 하는지에 대한 고민보다도. **Card 와 연관을 맺는 객체들의 \"협력\" 관계가 말이 되는지에 대해 고민해주세요.***
+>
+> ***public 하게 공개된 함수는 생성자를 포함하여, 다른 객체에게 소통의 통로가 되는 메시지 입니다. public 하게 공개된 요소가 어떤 객체와 협력하기 위해 필요한 것인지, 그 객체와 협력이 말이 되는지, 그리고 public 하게 공개된 로직을 테스트 할 수 있는지에 대해 집중해주세요.***
+>
+> *올리브가 굉장히 열심히 해주고 계심에도, 지금 너무 많은 요소를 신경 쓰기 때문에 고민이 점점 많아지게 되는 것 같습니다. 언젠가는 해야할 고민이 맞지만, **한정된 시간내에서 학습해내야할 경험이 있다는 점을 고려해서 우선순위를 말씀드려봅니다.**"*
+
+→ **MCP 룰 `static-fn-as-misplaced-utility`** ⭐⭐⭐ **신규 정점** — *static 함수 = 어느 객체에도 무관 유틸 → 객체 할당 권유*. PR #80 (`util-package-definition`) 결 합류 누적 2 PR.
+
+→ **MCP 룰 `public-fn-as-message-collaboration-vocabulary`** ⭐⭐⭐ **신규 정점** — *public 함수 (생성자 포함) = 소통 통로 메시지 + 협력 관계 정합 + 테스트 가능성*. PR #42 (`tell-dont-ask-message-vocabulary`)·PR #101 (`message-vocabulary-student-self-narration`) 결 합류 누적 3 PR → ***메시지 어휘 정점*** ⭐⭐⭐.
+
+→ **`learning-priority-time-bound`** ⭐⭐⭐ — *한정된 시간 학습 우선순위*. PR #134 (`reviewer-mission-time-bound-conclusion-vocabulary`) 결 합류.
+
+### 3. `gameResult` 분기 N×M = 테스트 부담 → 상태 패턴 (Thread 7) — 정점
+
+reviewer:
+
+> *"현재 Dealer와 Player, Role에서 모두 gameResult() 함수를 구현하고 있습니다. 함수의 중복이 문제가 아니라 **gameResult 로 인해서 분기처리가 점점 많아지는 것이 문제**입니다.*
+>
+> *위의 Dealer 만 보면, DRAW, BLACKJACK_LOSE, WIN, LOSE 4 가지 경우에 대한 분기처리 같지만, super 까지 고려하면 3가지 경우에 대한 분기처리가 추가됩니다. Player 에도 Dealer 와 마찬가지로 4가지에 대한 분기처리가 있으므로, **gameResult 함수를 제대로 검증하려면 (3+4) + (3+4) = 14 개의 테스트를 작성해야합니다.**그리고 이 분기는 혹여나 예외가 추가될 때마다 계속 늘어날 것입니다.*
+>
+> *이를 해결하기 위해서 다형성(Polymorphism) 을 도입해보자고 제안을 해봅니다. **GameResult 를 최종 마지막 결과가 아니라 현재 진행중인 GameState 라 생각**하고, 게임이 진행하면서 GameState 가 수시로 바뀌도록 해주세요. (`var GameState`)*
+>
+> *if 혹은 when 을 통해 분기되어야 하는 로직은 `abstract fun` 에 따라, **State 가 달라지면 알아서 다른 로직이 실행되도록 다형성을 활용**해주시기 바랍니다."*
+
+→ **MCP 룰 `branch-multiplication-as-test-burden-signal`** ⭐⭐⭐ **신규 정점** — *분기 N×M = 테스트 N×M 부담 시그널 → 상태 패턴 도입*. PR #154·#42·#89·#134 (`state-pattern-no-if-type-check`/`state-pattern-no-type-casting-hidden-requirement`) 결 합류 누적 **5 PR 정점** ⭐⭐⭐.
+
+→ **MCP 룰 `result-as-state-not-final-vocabulary`** ⭐⭐⭐ 신규 — *GameResult = 최종 결과 / GameState = 진행 중 변화 어휘*. PR #89 (`state-pattern-2-criteria`) 결 합류 — *State 패턴 어휘 정점*.
+
+### 4. reviewer 피드백 우선순위 메타 (Thread 6)
+
+학생 자가:
+
+> *"`Dealer`와 `Player`, `Role`에서 모두 `gameResult()` 함수를 구현하고 있다는 점이 마음에 걸렸습니다."*
+
+reviewer:
+
+> *"크흡... **예리하시군요.** 사실 이 부분 지적할까 하다가, **이 부분에 대한 리팩토링보다는 테스트 코드에 대한 보완이 시급하다고 생각해서 언급하지 않았습니다.***
+>
+> *다만 분기조건을 알기쉽게 함수명을 지어주신 것은 정말 보기좋다고 생각한 칭찬입니다!*
+>
+> *테스트 코드 보완 후에, 이 부분을 갈아엎는데 욕심이 있으시다면 연락주세요. 도와드리겠습니다."*
+
+→ **MCP 룰 `reviewer-feedback-prioritization-meta`** ⭐⭐⭐ **신규** — *reviewer 피드백 우선순위 메타 (지적 vs 시급 우선)*. PR #62·#89 (ghojeong 자가 반성) 결 합류 → ***reviewer 자가 결정 어휘***.
+
+→ **`student-self-detection-precise`** ⭐⭐ — *학생 자가 *마음에 걸린다* 사전 자각 어휘*.
+
+### 5. 패키지 = `common` vs 통합 (Thread 3)
+
+reviewer:
+
+> *"여러 패키지에서 공통적으로 쓰이는 객체들은 `model.common` 이라고 해서, common 패키지를 만들고는 합니다. 하지만 미션은 요구사항이 많지 않으므로 가능한 common 이 필요없게끔 객체 설계를 해주셨으면 합니다. 저는 혼란이 생길거라면 굳이 card 와 participant 패키지를 나누지 말고, Amount 와 Hand 가 있는 model 패키지로 다같이 묶어버리는게 낫지 않을까 생각이 들었습니다. **블랙잭 미션 완료까지 시간이 얼마 안 남았고 굳이 분류해야할만큼 model 객체가 많지 않으므로, 다 같은 model 패키지로 묶어버리고 차라리 패키지보다는 객체설계 개선에 시간을 더 쓰는게 좋지 않을까 제안해봅니다.**"*
+
+→ **`time-bound-priority-package-vs-design`** ⭐⭐ — *시간 한계 + 우선순위 어휘*. PR #115 (laco-dev 시간 지체)·PR #134 (말리빈 미션 마무리) 결 합류 누적 3 PR.
+
+### 6. GameResult enum profitRate 우아함 칭찬 (Thread 8)
+
+reviewer:
+
+> *"GameResult 을 enum 으로 만들어주신 것은 무척 좋습니다! profitRate 를 상수화하는 무척 우아한 방법이라 생각이 됩니다. 👍 💯"*
+
+→ **`enum-with-domain-value-as-elegant`** ⭐⭐ — enum + 속성 어휘.
+
+### 7. reviewer 마무리 — *방향 잡아주지 못한 아쉬움* (review 마지막)
+
+reviewer:
+
+> *"DM 을 포함해서 굉장히 많은 이야기를 나누어주셨는데, **제가 더 일찍 방향을 잡아주지 못해서 살짝 아쉬움이 남네요.** 모든 내용을 학습하지 못한 것에 크게 마음 두지 마시고, **다음 미션에 가셔서 다음 미션에서 배울 수 있는 경험에 집중해 주시기 바랍니다!**"*
+
+→ **MCP 룰 `reviewer-mid-mission-direction-regret`** ⭐⭐⭐ 신규 — *reviewer 자가 방향 안내 부족 아쉬움 + 학습 분량 안 무거움 격려*. PR #115·#89·#62·#134 결 합류 누적 **7 PR reviewer 자가 반성 어휘** ⭐⭐⭐ 정점.
+
+## 대표 인용
+
+> [ghojeong Thread 1]
+> *"저는 쉬운 유지보수를 최우선 가치로 개발하고, 성능은 문제가 되었을 경우에만 최적화를 합니다. (...) 성능이 느려서 문제가 되는 경우보다 유지보수가 어려워서 추가 기능 개발이 느려지는 게 문제가 되는 경우가 훨씬 많았기 때문입니다."*
+
+→ **유지보수 > 성능 우선순위 + 개인 경험 어휘 정점**.
+
+> [ghojeong Thread 1]
+> *"무엇이 정답이다! 보다는 내 코드가 더 테스트하기 쉬워졌는가? 이 함수가 무엇을 하는지 더 명확해졌는가? 에 집중해주세요!"*
+
+→ **판단 기준 어휘 정점**.
+
+> [ghojeong Thread 2]
+> *"public 하게 공개된 함수는 생성자를 포함하여, 다른 객체에게 소통의 통로가 되는 메시지 입니다. public 하게 공개된 요소가 어떤 객체와 협력하기 위해 필요한 것인지, 그 객체와 협력이 말이 되는지"*
+
+→ **public = 메시지 통로 + 협력 관계 어휘 정점**.
+
+> [ghojeong Thread 2]
+> *"static 으로 선언된 함수는 사실 어느 객체에 있어도 상관없는 유틸 함수라고 생각을 해주셔야 합니다."*
+
+→ **static = 유틸 어휘**.
+
+> [ghojeong Thread 7]
+> *"gameResult 함수를 제대로 검증하려면 (3+4) + (3+4) = 14 개의 테스트를 작성해야합니다."*
+
+→ **분기 N×M = 테스트 부담 어휘**.
+
+> [ghojeong 마지막 review]
+> *"제가 더 일찍 방향을 잡아주지 못해서 살짝 아쉬움이 남네요. 모든 내용을 학습하지 못한 것에 크게 마음 두지 마시고, 다음 미션에 가셔서 다음 미션에서 배울 수 있는 경험에 집중해 주시기 바랍니다!"*
+
+→ **reviewer 자가 방향 안내 부족 아쉬움 어휘**.
+
+> [kimhm0728 PR 본문]
+> *"초기 설계 자체가 잘못된 것 같아서 미션 끝나면 처음부터 다시 구현할 생각도 하고 있는데요(ㅠㅠ)"*
+
+→ **학생 자가 처음부터 다시 구현 고려 어휘**.
+
+> [kimhm0728 Thread 6]
+> *"`Dealer`와 `Player`, `Role`에서 모두 `gameResult()` 함수를 구현하고 있다는 점이 마음에 걸렸습니다."*
+
+→ **학생 자가 *마음에 걸린다* 사전 자각 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **유지보수 > 성능 우선순위 + 개인 경험** — **MCP 룰 `maintainability-over-performance-priority` 후보** ⭐⭐⭐ 정점.
+2. **판단 기준 = 테스트 가능 + 함수 명확** — **MCP 룰 `code-judgment-criteria-test-fn-clarity` 후보** ⭐⭐⭐ 정점.
+3. **public = 메시지 통로 + 협력 관계 어휘** — **MCP 룰 `public-fn-as-message-collaboration-vocabulary` 후보** ⭐⭐⭐ 정점. PR #42·#101 결 누적 3 PR.
+4. **static 함수 = 어느 객체에도 무관 유틸** — **MCP 룰 `static-fn-as-misplaced-utility` 후보** ⭐⭐⭐ 정점.
+5. **분기 N×M = 테스트 부담 시그널 → 상태 패턴** — **MCP 룰 `branch-multiplication-as-test-burden-signal` 후보** ⭐⭐⭐ 정점. 상태 패턴 누적 5 PR.
+6. **GameResult = 진행 중 GameState 어휘** — **MCP 룰 `result-as-state-not-final-vocabulary` 후보** ⭐⭐⭐.
+7. **reviewer 피드백 우선순위 메타** — **MCP 룰 `reviewer-feedback-prioritization-meta` 후보** ⭐⭐⭐.
+8. **reviewer 자가 방향 안내 부족 아쉬움 (누적 7 PR)** — **MCP 룰 `reviewer-mid-mission-direction-regret` 후보** ⭐⭐⭐ 정점.
+9. **학생 자가 처음부터 다시 구현 고려 (누적 3 PR)** — **MCP 룰 `pr-body-restart-from-scratch-consideration` 후보** ⭐⭐⭐.
+10. **시간 한계 우선순위 (패키지 vs 객체 설계)** — **MCP 룰 `time-bound-priority-package-vs-design` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **kimhm0728 양 단계 완성 (1단계 #72 → 2단계 #97)** — 1단계 *controller-classification-criteria* + 풍부 메타 어휘 → 2단계 *처음부터 다시 구현 고려 학생 자가 의문* + ghojeong reviewer 유지보수/성능/협력/메시지 어휘 정점 + Slack DM 활발 학습 + 6개 자가 학습 진화 명시. **학습 메타 케이스 — 학생 자가 *처음부터 다시* + DM 학습 깊이 정점**.
+- **ghojeong reviewer 어휘 누적 정점** (PR #62 함수형 어휘 → #89 미션 본 목표 복귀 → #97 유지보수/성능/협력/메시지/판단 기준 정점) — *ghojeong 3 PR reviewer 어휘 최정점* ⭐⭐⭐.
+- **메타 케이스 12번째** — *kimhm0728 PR 본문 *처음부터 다시 구현 고려* 학생 자가 의문 + DM 학습 + 학생 자가 *마음에 걸린다* 사전 자각*.
+- **reviewer 자가 반성 어휘 누적 7 PR 정점** (PR #62 + #89 + #115 + #73 + #106 + #54 + #97) — **MCP `oh-my-oop` 핵심 가치 최정점 강화**.
+- **상태 패턴 어휘 누적 5 PR 정점** (PR #154 + #42 + #89 + #134 + #97) — 분기 N×M → 다형성 도입 시그널.

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

@@ -0,0 +1,221 @@
+# PR #68 — [블랙잭 1단계] 꼬상 미션
+
+- **Reviewee:** [@kkosang](https://github.com/kkosang)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/68
+- **단계:** 1단계
+- **리뷰어:** [@KwonDae](https://github.com/KwonDae) (제이든) — 2024 코호트 reviewer
+- **라인 코멘트:** 22 스레드 — *PR 본문 *클래스 다이어그램 그림 첨부* (페어 학습) + Participant 추상화 + BlackJack 클래스 = 다형성 제기능 X (소프트17 룰 4 라운드 깊은 양방향 토론) + 학생 자가 *개방-폐쇄 원칙 OCP* 어휘 + GameManager 없이 가능 권유 + 고차함수 + 학생 자가 인자 3개 줄이고 싶음 의문*
+- **신규 reviewee** (2024 코호트, 새 1단계 분석).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 클래스 다이어그램 그림 첨부 + 페어 학습
+
+PR 본문:
+
+> *"블랙잭 미션에 대한 클래스다이어그램을 페어와 함께 간략하게 그려봤습니다 ! 참고해서 봐주시면 감사하겠습니다 🙇🏻‍♂️"*
+
+→ **클래스 다이어그램 그림 첨부 + 페어 학습** = PR #96 (Hogu59 의존성 그래프 시각화) 결 합류. **MCP 룰 `student-self-class-diagram-visualization` 후보** — *학생 자가 클래스 다이어그램 그림*.
+
+### 2. Participant 추상화 + reviewer 추가 책임 권유
+
+reviewer (Thread 1):
+
+> *"딜러와 플레이어들의 공통점을 추상화를 통해 잘 구현해주셨네요 👍*
+> *조금 더 참가자 라는 객체 스스로가 판단하고 행동하게끔 해볼 수 있을까요? draw, checkState 같은 부분들에 이어서 `다른 참가자와의 승패비교`, `게임 참가 시 두장의 카드 뽑는 행동` 등 외부로부터 결정되는 것이 아닌 객체 자체로서 행동하게 할 수 있는 로직들을 추가해도 좋겠네요 👍"*
+
+→ **Participant 추상화 + Tell-Don't-Ask 추가 책임** = PR #87·#129·#142·#143·#140 결 합류.
+
+### 3. 학생 자가 *개방-폐쇄 원칙 OCP* 어휘 (Thread 11)
+
+학생:
+
+> *"하지만 소프트17뿐만 아니라 다른 룰이 계속해서 추가되어 게임 본질을 잃어버린다면 기존의 블랙잭게임이 아닌 새로운 게임을 만드는 것이라고 볼수도 있을 것 같은데 혹시 질문하신 부분이 객체지향 설계의 원칙 중 하나인 개방-폐쇄 원칙(Open/Closed Principle)인가요..?!"*
+
+→ **학생 자가 *OCP* 어휘** = *SOLID 원칙 자가 학습*. **MCP 룰 `student-self-solid-principle-vocabulary` 후보**.
+
+### 4. 소프트17 룰 학생/reviewer 4 라운드 깊은 양방향 토론 (Thread 11)
+
+reviewer:
+
+> *"만약 블랙잭 내부 룰 중 [소프트17] 이라는 룰 적용이라는 추가 요구사항이 생겼다면 어떻게 해야할까요? 이 규칙은 딜러에게만 적용되는 규칙이기에 Dealer 에서 다르게 처리를 해주어야 할겁니다.*
+>
+> *그렇다면 이 BlackJack 클래스 내부에서 처리를 할 수 있을까요? BlackJack이라는 클래스를 만들면서 Partic[ipant 추상화 제기능 못 함]"*
+
+학생 자가 답변 + reviewer 답변 + 학생 자가 답변 + reviewer 답변 = **4 라운드 양방향 토론** + *카지노마다 소프트17 적용 다름 = 본질 다른 게임?* 학생 자가 의문.
+
+reviewer:
+
+> *"소프트17이 블랙잭 게임의 본질을 잃어버리게 하는 룰일까요? 그렇다면 카지노마다 소프트17이 적용되는 곳이 있고 아닌 곳이 있는데 이들은 본질적으로 다른 블랙잭 게임인걸까요?_?*
+>
+> *Participant 추상화를 통해 딜러와 플레이어간 공통 로직을 모으고, 다형성(확장)에 대해서는 제공을 하지만, BlackJack이라는 객체를 통해 다시 다형성에 대해 제기능을 하지 못하고 있습니다."*
+
+→ **외부 룰 추가 요구사항 가정 + 다형성 활용 의식 + 학생 자가 *블랙잭 본질* 의문 + reviewer *카지노마다 다른 룰* 답변** = **MCP 룰 `polymorphism-as-rule-extension-tolerance` 후보**.
+
+PR #142 (polymorphism-as-change-tolerance) 결의 *변경 가능성 = 다형성* 어휘 강화.
+
+### 5. 고차함수 + 학생 자가 *모듈성 / 객체 일* 학습 (Thread 19)
+
+학생:
+
+> *"고차함수를 사용하면 모듈성을 높일 수 있는 것 같고, 객체에게 할일을 부여해줄 수 있다는 점이 좋았던 것 같습니다 ! 고차함수를 처음 적용해봐서 익숙하지 않아서 어려웠던 것 같고, drawAdditionalCard메서드에서 현재 인자를 3개 받고 있는데 줄이고 싶었지만 방법이 떠오르지 않았습니다..😅"*
+
+reviewer:
+
+> *"맞습니다. 고차함수를 통해 가독성 향상 외에도 외부 상태의 변경이나 가변 데이터를 피하고, 불변성을 지향하는 함수형 프로그래밍에 기반을 두고 있기에 순수 함수를 통한 부수효과를 억제하여 오류를 피할 수 있습니다."*
+
+→ **고차함수 = 모듈성 + 함수형 프로그래밍 학생 자가 학습 + 학생 자가 인자 폭증 의문** = PR #109·#140·#143·#142 결 합류.
+
+### 6. 추가 칭찬
+
+- Thread 3: *"도메인의 enum 과 View 역할을 잘 각각 부여해주셨네요 👍"*.
+- Thread 1: *"공통점을 추상화를 통해 잘 구현해주셨네요 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. InputValidator 도메인 vs UI + `println` model 위치 (Thread 2)
+
+reviewer: *"InputValidator는 도메인 로직일까요 UI로직일까요? 또한, model에서 view 역할을 하는 `println()` 존재에 대해서 어떻게 생각하시나요?"*
+
+→ **Domain ↔ View 분리 + Kotlin 예외 처리 (논리 오류 vs null)** = PR #126·#143·#149·#19·#35 결 합류 누적 14+ PR ⭐⭐⭐.
+
+reviewer 가 *로또 미션* 인용 (cross-mission learning).
+
+### 2. Ace 'A' 출력 vs 11 (Thread 4) — 블랙잭 룰 출력 정확성
+
+reviewer: *"에이스는 11이 아닌 'A'로 출력되어야 합니다"*
+
+→ **블랙잭 출력 룰 정확성** = PR #36·#130·#143 (블랙잭 룰 정확성) 결 합류.
+
+### 3. 메서드명 vs state update (Thread 5)
+
+reviewer: *"메소드명은 현재스코어를 확인하는 함수이지만, 행동은 state를 update 해주고 있습니다"*
+
+→ **CQS 위반 + 이름 의미 불일치** = PR #117·#139·#130·#141 결 합류.
+
+### 4. Bust 시 Ace 처리 불필요 (Thread 6)
+
+reviewer: *"Bust 일 때, 현재 에이스를 갖고 있지 않아도 이 행동을 해야할까요?"*
+
+→ **불필요한 조건 분기 = 학생 자가 학습**.
+
+### 5. CardDeck 테스트 가능성 + Default arguments (Thread 7·13)
+
+reviewer: *"CardDeck을 테스트 가능하게끔 외부에서 카드덱을 받도록 설정할 수 있을까요? 특정 카드덱을 받지 않는다면, [Default arguments] 로 설정해줄 수 있는 옵션도 있으니까요"*
+
+학생 자가 적용: `class CardDeck(cards: List<Card> = ...default...)`.
+
+→ **DI + Default argument Kotlin 어휘** = PR #138·#113·#118·#141·#149 결 합류 누적 8+ PR.
+
+### 6. Test Fixture 외부글 (Thread 8)
+
+reviewer: *"테스트 픽스처에 대한 좋은 글을 공유드릴게요 :) https://tjdtls690.github.io/studycontents/java/2022-10-10-test_fixture/"*
+
+→ **외부글 (tjdtls690)** = PR #36·#71·#129·#138·#118 결 합류.
+
+### 7. 승부 판단 = Participant.judge(other) (Thread 10) — Tell-Don't-Ask
+
+학생 자가 의문:
+
+> *"Participation에서 승부를 판단하도록 수정하였는데, 제가 생각했을 때는 참가자가 직접 승부를 판단하는 것보다 GameResult라는 객체가 승부를 판단하는게 좀 더 자연스럽다고 생각했는데 혹시 Participant에서 승부를 판단해야 하는 이유가 있을까요?"*
+
+→ **외부 객체 vs Participant.judge 학생 자가 의문** = PR #129·#142·#143·#140 결 합류.
+
+### 8. BlackJack 클래스 = 다형성 제기능 X (Thread 11) — §3·§4 참조
+
+### 9. GameManager 가 draw 수행 vs participant.draw(cardDeck) (Thread 12)
+
+reviewer:
+
+> *"참가자에게 draw()를 행동하게 위임했다면, cardDeck만 넘겨서 알아서 draw 하도록 하는건 어떨까요?*
+>
+> *그렇다면 GameManager 가 참여자 객체에게 카드를 몇장 뽑을지 매니저에서 결정 하는 것도 플레이어 객체가 몇장 뽑을지 스스로 행동하게끔 할 수 있겠네요!*
+> *`participant.initDrawCard(cardDeck)`*
+>
+> *객체 스스로 행동하게끔 고쳐본다면 GameManager 클래스 없이도 가능할까요? 🧐"*
+
+→ **GameManager god-object 회피 + 객체 자가 행동 정공** = PR #142·#129 결 합류.
+
+### 10. 사용자 입력 판단 = 도메인 vs UI (Thread 18) — 학생 자가 잘못된 답변 → reviewer 정정
+
+학생: *"사용자 입력에 대해 판단하는 로직은 도메인 로직에 해당한다고 생각합니다 ! 입력은 똑같이 들어왔지만, 입력값에 대한 판단만 바뀌는 경우 도메인 로직을 수정해주어야 할 것 같습니다 !"*
+
+reviewer:
+
+> *"View 는 입력 또는 출력 값에 대해 책임을 갖고 Controller에게 도메인 로직에 활용 될 데이터를 전달하는 것에 역할이 있습니다. 입력값에 대한 요구사항이 변경되었을 때 도메인 로직을 수정하는것이 자연스러운가? 에 대해 고민해보셨으면 좋겠습니다."*
+
+→ **학생 자가 잘못된 답변 + reviewer 정정** = *학생 자가 학습 시간성*. 누적 다수 PR.
+
+### 11. `getOrElse` 반복 코드 제거 (Thread 15·16)
+
+reviewer: *"위와 마찬가지로 getOrElse 로 반복되는 코드를 제거해볼까요?"* + suggestion 블록 활용.
+
+→ **Kotlin scope function 활용**.
+
+### 12. Controller 가 player 상태 확인 + 비즈니스 로직 (Thread 17)
+
+reviewer: *"Controller에서 player의 상태를 확인하고 비즈니스 로직에 관여하는 것에 대해 어떻게 생각하시나요? 위와 비슷한 맥락의 코멘트인거 같습니다. 객체에게 할일을 하라고 메세지를 던지기만 해보는건 어떨까요?"*
+
+→ **고차함수 + Tell-Don't-Ask** = 누적 다수 PR.
+
+### 13. CardDeck mutable 외부 노출 (Thread 20)
+
+reviewer: 코멘트 (Thread 20 - 자동 분류). *CardDeck mutable 관련*.
+
+→ **mutable-list-public-exposure** = 누적 6+ PR.
+
+### 14. HumanName 생성자 / 팩토리 (Thread 14)
+
+reviewer: *"이 함수는 테스트시에만 사용하는 함수인가요?.?"*
+
+학생: *"사용을 안하고 있었네요..! 수정해서 사용하도록 변경했습니다"*
+
+→ **Dead code** = PR #153 결 합류.
+
+### 15. 학생 자가 클래스 다이어그램 (PR 본문) — §1 참조
+
+## 대표 인용
+
+> [kkosang Thread 11]
+> *"하지만 소프트17뿐만 아니라 다른 룰이 계속해서 추가되어 게임 본질을 잃어버린다면 기존의 블랙잭게임이 아닌 새로운 게임을 만드는 것이라고 볼수도 있을 것 같은데 혹시 질문하신 부분이 객체지향 설계의 원칙 중 하나인 개방-폐쇄 원칙(Open/Closed Principle)인가요..?!"*
+
+→ **학생 자가 OCP 어휘** + *블랙잭 본질 의문*.
+
+> [KwonDae Thread 11]
+> *"소프트17이 블랙잭 게임의 본질을 잃어버리게 하는 룰일까요? 그렇다면 카지노마다 소프트17이 적용되는 곳이 있고 아닌 곳이 있는데 이들은 본질적으로 다른 블랙잭 게임인걸까요?_?"*
+
+→ **카지노마다 다른 룰 어휘** — *도메인 본질 vs 변형 트레이드오프*.
+
+> [KwonDae Thread 12]
+> *"객체 스스로 행동하게끔 고쳐본다면 GameManager 클래스 없이도 가능할까요? 🧐"*
+
+→ **GameManager god-object 회피 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **학생 자가 클래스 다이어그램 시각화** — **MCP 룰 `student-self-class-diagram-visualization` 후보**.
+
+2. **학생 자가 *OCP* 어휘** — **MCP 룰 `student-self-solid-principle-vocabulary` 후보**.
+
+3. **소프트17 룰 4 라운드 양방향 + 카지노마다 다른 룰** — **MCP 룰 `polymorphism-as-rule-extension-tolerance` 후보**.
+
+4. **GameManager god-object 회피 + 객체 자가 행동** = 누적 다수.
+
+5. **학생 자가 잘못된 답변 + reviewer 정정 (Thread 18)** — *학습 시간성*.
+
+6. **외부글 (tjdtls690 Test Fixture)** = 누적 8+ PR.
+
+7. **로또 미션 cross-reference** — *cross-mission learning*.
+
+## MCP 룰 후보 신규 + 강화 (PR #68)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `student-self-class-diagram-visualization` | 신규 | 1 (#68) |
+| `student-self-solid-principle-vocabulary` | 신규 | 1 (#68) |
+| `polymorphism-as-rule-extension-tolerance` | 신규 | 1 (#68) |
+| `model-view-dependency-direction` | 강화 | 14+ ⭐⭐⭐ |
+| `function-name-vs-return-semantic-mismatch` | 강화 | 12+ |
+| `external-resource-reference` | 강화 | 8+ |
+| `mutable-list-public-exposure` | 강화 | 6+ |
+| `dead-code-removal` | 강화 | 2+ |

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

@@ -0,0 +1,158 @@
+# PR #94 — [블랙잭 2단계] 꼬상 미션
+
+- **Reviewee:** [@kkosang](https://github.com/kkosang)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/94
+- **단계:** 2단계
+- **리뷰어:** [@KwonDae](https://github.com/KwonDae) (제이든) — 1단계 #68 동일 reviewer
+- **라인 코멘트:** 15 스레드 — *PR 본문 자가 의문 (BlackJack 클래스 삭제 가능?) + reviewer *시야 환기 위해 요구사항 없는 룰 가정 의도* 자가 답변 + data class vs class 학생 자가 답변 + State 패턴 abstract fun 미적용 + Controller-View 없이 도메인 + calculateResult + displayResult = 함수 2 역할 (CQS) + 일급 컬렉션 위임 권유 + given-when-then 학생 자가 학습*
+- **양 단계 완성 reviewee** (1단계 #68 batch 23 완료 + 2단계 #94 = batch 24).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 + 인사 (몸 상태)
+
+PR 본문:
+
+> *"몸 상태가 좋지 않아서 오래걸렸습니다 😥 제이든도 환절기에 감기 조심하세요 ㅠㅠ! 1단계 리뷰 반영 하는 부분에서 아직 BlackJack 클래스에 대해서는 해결하지 못하였는데 BlackJack클래스를 삭제하고 HandCard에서 상태를 관리하면서 Participant에서 HandCard를 사용하면 되는걸까요?"*
+
+→ **학생 자가 한계 인정 + reviewer 안부 인사 + 자가 의문** = PR #130·#139·#143·#121·#153 결 합류. 인간적 어휘.
+
+### 2. reviewer 의도 명료화 (Thread 9 - PR 본문 자가 의문 답변)
+
+reviewer:
+
+> *"조금은 시야를 환기시키기 위해 요구사항에는 없었던 룰에 대해서 생각을 해보고 적용을 하게 된다면 현재 구조에서 어떤 문제가 생길 수 있을지에 대해 고민을 유도하는 코멘트였습니다 ㅎㅎ*
+>
+> *지금 BlackJack이라는 클래스를 통해 블랙잭 로직들을 응집함으로써 잘 분리가 되었습니다. BlackJack 클래스가 없다면 Participant 가 지금 보다는 비대해질 가능성이 있겠죠. 다만,..."*
+
+→ **reviewer 의도 자가 명료화 + 1단계 #68 소프트17 룰 어휘 명시** = *PR #142 (reviewer-self-clarification-explicit) 결 합류 누적 5+ PR*.
+
+### 3. data class vs class 학생 자가 답변
+
+학생: *"Card를 data class로 만든 이유는 값에 대한 정보만 들어있고 get메서드를 통해 읽기전용으로만 사용하고 있어서 사용했습니다. 또한CardDeck에서 Card객체의 값 비교를 테스트할 때, equals()와 hashCode() 같은 메서드를 자동으로 생성해주기 때문에 data class로 수정하였습니다 !"*
+
+→ **Kotlin 어휘 자가 학습** = PR #117·#138·#143 결 합류.
+
+### 4. given-when-then 학생 자가 학습 (Thread 10)
+
+reviewer: *"그리고 given-when-then 패턴을 활용해서 보다 가독성이 높은 테스트 코드를 작성해볼까요?"*
+
+학생: *"테스트 코드에서도 given-when-then이라는 패턴이 존재했군요 ! 수정하였습니다"*
+
+→ **BDD given-when-then 학생 자가 학습** = PR #109·#19 결 합류.
+
+### 5. 추가 칭찬
+
+- Thread 1: *"runCatching 활용을 잘 해주셨네요 👍"*.
+- Thread 4: *"랜덤 요소가 있는 부분을 추상화를 잘 해주셨네요 👍"*.
+- Thread 11: *"fold 활용 👍 👍"*.
+- Thread 12: *"추상화를 통해 각 상태에 따라 로직을 수행하게 잘 구현해주셨네요 💯"*.
+
+## 못한 점 (설계 관점)
+
+### 1. UserDecision 패키지 이동 vs 의존성 (Thread 3)
+
+reviewer: *"단순 패키지 이동으로 해결될 수 있는 부분일까요? 현재 도메인 모델인 Player 에서 UserDecision을 의존하고 있습니다. 단순 코멘트를 반영하는 목적이 아닌 깊게 고민해보고 이해가 가지 않는 부분은 편하게 DM으로 말씀해주셔도 됩니다."*
+
+→ **DM 활용** = PR #129·#138·#142·#121·#153 결 합류.
+
+### 2. ShuffleCardDeck interface 테스트 활용 X (Thread 4)
+
+reviewer: *"테스트시에는 이 인터페이스가 활용이 안되고 있습니다."*
+
+→ **interface-for-test-substitution** = PR #138·#143·#113·#118·#149 결 합류.
+
+### 3. 테스트 보장 X (Thread 5) — *예상 하지 못하게* 모호
+
+reviewer: *"이 테스트는 과연 결과를 보장할 수 있는 테스트일까요? 🧐 `예상 하지 못하게` 라는 테스트 제목이 이해가 잘 가지 않았어요."*
+
+학생: *"만약 생성된 카드에서 모두 expectedCard와 모두 같은 경우가 있을 수 있을 수 있기 때문에, 테스트 결과를 보장할 수 없습니다 ! 해당 테스트를 삭제하도록 하겠습니다 !"*
+
+→ **테스트 결과 보장 = 플레이키 테스트 회피** = **MCP 룰 `flaky-test-avoidance` 후보**.
+
+### 4. State 패턴 abstract fun 미적용 (Thread 7)
+
+reviewer: *"State 패턴의 핵심 중에 abstract fun 추상화 메서드를 활용하여 상태가 변할 때 마다 어떤 상태인지에 따라 다른 로직을 수행하는 것이 기능중에 하나인데요."*
+
+→ **State 자식 책임 부여** = PR #93·#136·#152·#98·#36·#87·#142·#143·#138 결 합류 누적 12+ PR.
+
+### 5. 수익 = Participant 위임 (Thread 8) — Tell-Don't-Ask
+
+reviewer: *"수익을 계산하는 로직도 Participant 에게 위임 해보는건 어떨까요?"*
+
+→ **Tell-Don't-Ask** = 누적 다수 PR.
+
+### 6. Controller-View 없이 게임 가능 (Thread 13) — 테스터빌리티
+
+reviewer:
+
+> *"Controller에서 player에 직접 접근해서 무언가를 직접 꺼내고 넣는 작업들을 해주어야 할까요? (...) 이 코멘트의 궁극적 의도는 \"Controller와 View 없이도 블랙잭 게임을 할 수 있는가?\" 에 대해서 도메인 로직이 충분히 Controller로 부터 분리되었나? 를 고민해보시면 좋겠습니다."*
+
+→ **Controller/View 없이 도메인 = 테스터빌리티** = PR #99 (chaehyuns) 결 + PR #87 (jaeyeongjo 테스트 = 객체 설계 명세서) 결 합류. **MCP 룰 `controller-view-domain-coupling` 강화** 누적 3+ PR.
+
+### 7. `calculateResult` + displayResult = 함수 2 역할 (Thread 13) — CQS
+
+reviewer:
+
+> *"함수의 이름은 calculateResult() 이기에 함수를 진입하는 의도는 결과를 도출하기 위해서입니다.*
+> *1. 플레이어들의 게임 결과를 가져온다*
+> *2. 가져온 결과를 통해 수익률을 계산하여 출력한다"*
+
+→ **CQS 위반 + 함수 분리** = PR #117·#139·#130·#141·#118 결 합류 누적 5+ PR.
+
+### 8. 일급 컬렉션 위임 + suggestion 블록 (Thread 15)
+
+reviewer:
+
+> *"```suggestion*
+> *    fun getParticipantProfitResult(): List<Double> {*
+> *        val result = players.getProfitResult()*
+> *        return result*
+> *    }*
+> *```*
+>
+> *와 같이 일급컬렉션을 사용하여 객체에게 도메인 로직을 집중시킬 수 있습니다. 이후 오목 미션 진행하시면서도 객체가 할 수 있는 일을 최대한 위임하는 연습을 하시면 좋을 것 같습니다 👍"*
+
+→ **일급 컬렉션 위임 + 다음 미션 (오목) 권유** = **MCP 룰 `cross-mission-learning-bridge` 후보** — *현재 미션 → 다음 미션 학습 권유*.
+
+### 9. blackJack.state 의존성 = 테스트 불가 (Thread 14)
+
+reviewer:
+
+> *"현재 blackJack.state 라는 내부적으로 의존성이 있어 테스트가 불가한 구조네요. 테스트가 불가할때는 지난 로또미션, 블랙잭 미션을 진행하며 경험했던 방법들을 이용할 수 있습니다.*
+> *1. 테스트 불가 요소를 분리한다*
+> *2. 의존성을 갖지 않도록 주입 받는다."*
+
+→ **테스트 불가 = 의존성 분리** = PR #87·#129·#142·#109·#140 결 합류.
+
+### 10. CardDeckTest fixture (Thread 10) — Test Fixture
+
+reviewer: *"이부분은 Test Fixture를 이용해 개선해볼 수 있곘네요!"*
+
+→ **Test Fixture** = 누적 다수.
+
+## 대표 인용
+
+> [kkosang PR 본문]
+> *"제이든도 환절기에 감기 조심하세요 ㅠㅠ!"*
+
+→ **학생 인간적 어휘** + 자가 한계 인정.
+
+> [KwonDae Thread 9]
+> *"조금은 시야를 환기시키기 위해 요구사항에는 없었던 룰에 대해서 생각을 해보고 적용을 하게 된다면 현재 구조에서 어떤 문제가 생길 수 있을지에 대해 고민을 유도하는 코멘트였습니다 ㅎㅎ"*
+
+→ **reviewer 의도 자가 명료화** + *시야 환기 어휘*.
+
+> [KwonDae Thread 15]
+> *"이후 오목 미션 진행하시면서도 객체가 할 수 있는 일을 최대한 위임하는 연습을 하시면 좋을 것 같습니다 👍"*
+
+→ **cross-mission 학습 권유 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **reviewer 의도 자가 명료화** = PR #142·#126·#130·#109 결 강화 누적 5+ PR.
+2. **플레이키 테스트 회피** — **MCP 룰 `flaky-test-avoidance` 후보**.
+3. **Controller/View 없이 도메인 = 테스터빌리티** — **MCP 룰 `controller-view-domain-coupling` 강화** 누적 3+ PR.
+4. **CQS 위반 (calculateResult + displayResult)** = 누적 5+ PR.
+5. **cross-mission 학습 권유 어휘** — **MCP 룰 `cross-mission-learning-bridge` 후보**.
+6. **State 자식 책임 부여** = 누적 12+ PR.