oh-my-oop 0.2.0

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

@@ -0,0 +1,298 @@
+# PR #154 — [블랙잭 2단계] 토바에 미션
+
+- **Reviewee:** [@tobae-time](https://github.com/tobae-time) (토바에) — 2025 모바일 안드로이드 7기 코호트
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/154
+- **단계:** 2단계
+- **리뷰어:** [@laco-dev](https://github.com/laco-dev) (페로로)
+- **라인 코멘트:** 15 스레드 — *모든 thread 학생 자가 답변 + 커밋 SHA 첨부 (15/15) / 상태 패턴 외부 변경 위험 + 다형성 if 타입 검사 회피 + getter/setter 어휘 오해 → 객체 분리 신호 + 1단계 Rule god-object → 2단계 상태 패턴 학습 진화 + PR 본문 「객체지향의 사실과 오해」 도서 인용 정점*
+- **tobae-time 양 단계 완성** (1단계 #115).
+- **메타 케이스 7번째 정점**: PR 본문 학생 자가 *조영호 「객체지향의 사실과 오해」 도서 자가 학습* 명시 + reviewer 양 PR 어휘 진화 (#115 "쎄게 양해" → #154 "성장 과정 격려") + 상태 패턴 학생 자가 어려움 솔직 인정.
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 학생 자가 학습 도서 인용 정점
+
+PR 본문:
+
+> *"1단계 피드백 과정에서 제가 리뷰를 잘못 이해하여 다시 생각해보라는 의미로 오해하였습니다. participant에 대해 배제하고 생각하여 나온 결과물이었던 것 같습니다... 더불어 객체지향의 역할, 책임, 협력에 대한 이해도가 낮아서 **객체지향의 사실과 오해라는 도서를 읽고 코드를 다시 작성**해보았으나 아직도 잘 모르겠습니다. 😢*
+>
+> *그리고 로또 미션 당시, 컨트롤러에서 로직을 수행한다는 피드백을 받은 적 있는데, 그 부분도 아직 부족한 것 같습니다.*
+>
+> *rebase 과정에서 코드가 일부 날아갔는데, 저도 Rule을 다시 만질 자신이 없기도 했고 다시 해보는 것도 저한테는 연습이 될 수 있을 것 같아서 **처음부터 다시 코드를 작성**하였습니다... ~~(연습이 됐는지는 잘 모르겠습니다...)~~"*
+
+→ **MCP 룰 `pr-body-self-learning-book-citation`** ⭐⭐⭐ **신규 정점** — *학생 자가 조영호 「객체지향의 사실과 오해」 도서 인용*. **MCP `oh-my-oop` 핵심 가치 어휘 정점** (도구 영감 도서).
+
+→ **MCP 룰 `pr-body-prior-mission-feedback-recall`** ⭐⭐ 신규 — *로또 미션 때 받은 피드백 부족 자가 회상* (학습 시간성).
+
+→ **MCP 룰 `pr-body-restart-from-scratch`** ⭐⭐ 신규 — *rebase 코드 일부 손실 → *연습 의도*로 처음부터 다시 작성 — 학생 자가 *손실을 학습 기회로*재해석*.
+
+### 2. 모든 thread 학생 자가 답변 + 커밋 SHA (15/15)
+
+PR #115 (10/15) → PR #154 (15/15) **모든 thread 응답률 100%** + 커밋 SHA 첨부. *학습 가시화 정점*.
+
+### 3. 셀프 체크리스트 `[x?]` 자가 회의 표시
+
+PR 본문 셀프 체크리스트에서 *"이전에 받은 피드백을 모두 반영하였는가?"* / *"프로그래밍 요구 사항을 준수하였는가?"* 등 일부 항목에 `[x?]` 표시 — *완벽 체크 X, 회의 명시*.
+
+→ **MCP 룰 `pr-self-checklist-doubt-marker`** ⭐⭐ 신규 — *셀프 체크리스트에 `[x?]` 회의 마커로 학생 자가 *불확실성 명시**.
+
+## 못한 점 (설계 관점)
+
+### 1. 상태 패턴 외부 변경 위험 (Thread 2) — 핵심
+
+```kotlin
+val player = Player(...)
+player.state = Ready()
+player.state = Hit()
+player.state = Bust()
+player.state = Hit()
+```
+
+reviewer:
+
+> *"상태는 카드를 뽑으면서 그에 맞게 바뀌기를 기대합니다. 그렇다면 아래와 같은 코드는 어떤 문제가 발생할 수 있을까요?*
+> ***그렇다면 참가자가 카드를 뽑을 때 스스로 상태를 변경하려면 어떻게 해야 할까요?***
+> ```kotlin
+> // Participant
+> fun drawTo(card: Card) {
+>    state = ???
+> }
+> ```"*
+
+→ **MCP 룰 `state-pattern-external-mutation-risk`** ⭐⭐⭐ **신규 정점** — *외부에서 `state = Ready()`/`Bust()`/`Hit()` 임의 변경 = 상태 전이 룰 깨짐*. PR #100 (`mutable-state-open-violation`)·PR #38 (`mutable-member-var-state-dependent-result`) 결 합류 → *외부 mutation 위험 어휘 3 PR*.
+
+→ **Tell-Don't-Ask 메시지 어휘 — `drawTo(card)` 자가 변경** ⭐⭐⭐ — PR #38 *"내 카드 넘겨줄테니 알려줘"* 결 누적.
+
+### 2. 다형성 if 타입 검사 회피 (Thread 10) — 핵심
+
+reviewer 코드 예시:
+
+```kotlin
+while (player.canDraw() && askDraw(player)) {
+   player.drawTo(card)
+}
+player.stay() // 버스트면 어차피 안바뀐다.
+print(...)
+```
+
+reviewer:
+
+> *"결과에 따라 어떻게 출력할지는 출력에서 결정하면 될 것으로 보이는데요. 다형성을 이용해 구현체가 무엇인지 관심 없도록 했는데 **매번 if 문으로 타입을 볼 필요가 있을까요?** 동작이 이해가 되신다면 다형성에 대해 많은 성장을 할 수 있을 것 같습니다."*
+
+→ **MCP 룰 `state-pattern-no-if-type-check`** ⭐⭐⭐ **신규** — *상태 패턴 도입 후 if `is` 타입 검사 = 다형성 무효화*. PR #73 (`is-operator-polymorphism-avoidance`) 결 합류 누적 2 PR → ***`is` 절차지향 시그널 어휘*** ⭐⭐⭐ 강화.
+
+→ ***`player.stay()` 버스트면 안바뀐다* 패턴** ⭐⭐ — *상태가 자기 전이 무시 (Idempotent 호출)*.
+
+### 3. getter/setter 어휘 오해 → 객체 분리 신호 (Thread 13) — 핵심 학생 자가 자각
+
+reviewer:
+
+> *"흔히 getXXX, setXXX 형태는 getter()와 setter()의 역할을 할 것이라고 기대합니다. 이 함수들을 다른 사람이 봐도 잘 이해가 될까요?"*
+
+학생 자가 답변 정점:
+
+> *"작성하면서 get과 set은 아닌 것 같다고 생각했는데, 적절한 네이밍을 생각하지 못해서 두었습니다. **알아차리지 못한 객체로 분리하라는 신호였던 것 같습니다...** 앞으로 getter, setter는 해당 역할을 할 때 말고는 지양하도록 하겠습니다."*
+
+→ **MCP 룰 `getter-setter-naming-as-missed-object`** ⭐⭐⭐ **신규 정점** — ***`getXXX`/`setXXX` 어색함 = 분리해야 할 객체 신호*** 학생 자가 자각. PR #72 (`awkward-feeling-signal`) 결의 *어색함 시그널* 정점 — 학생 측 메타 어휘.
+
+→ **MCP `oh-my-oop` 핵심 가치 학생 측 메타 어휘** — *어색한 명명 = 모르는 객체 시그널*.
+
+### 4. 수익금 = 승패 X / O 두 응용 (Thread 3)
+
+reviewer 코드:
+
+```kotlin
+// Participant
+fun profit(other: Participant) {
+   val stateProfit = state.profit(other.state) // 승패를 고려하지 않은 수익
+   return calculateProfit(...) // 승패를 같이 고려한 수익
+}
+```
+
+reviewer:
+
+> *"플레이어 딜러 모두 블랙잭이라면, 무승부입니다. 라는 규칙이 잘 통과하고 있나요? 나아가서 **승패와 상관없이 수익금을 계산하는 것은 상태 객체가 해도 되지 않을까요? 승패를 이용한 수익금과 승패를 이용하지 않은 수익금 두개를 응용할 수 있을 것 같아요.**"*
+
+학생 자가 답변: *"상태 객체에서 하도록 변경하였습니다."*
+
+→ **MCP 룰 `state-as-domain-calculator`** ⭐⭐ 신규 — *수익금 = 상태 객체 책임*. PR #133 (Score 책임 분배) 결 합류.
+
+→ **블랙잭 룰 — 양쪽 블랙잭 = 무승부** ⭐⭐ — 도메인 룰 정확성.
+
+### 5. `Ready` vs `Hit` 상태 분기 — 학생 자가 어려움 솔직 인정 (Thread 5)
+
+reviewer: *"Ready랑 Hit이랑 어떤 차이가 있나요?"*
+
+학생 자가 답변:
+
+> *"Ready 상태일 때는 2장을 받은 상태로, 두 장의 최대 합이 21이기 때문에 블랙잭이 가능합니다. 하지만 버스트는 불가능합니다. Hit 상태는 3장의 카드를 받은 상태로, 블랙잭의 조건은 A 한 장과 10, J, Q, K입니다. 따라서 3장일 때 블랙잭이 불가능합니다. 각 상태에서 필요 없는 분기는 제거하였습니다.*
+>
+> *+ 추후 리뷰를 반영하다 보니, Hit에서 Blackjack으로 변경하는 분기가 필요하다고 생각하여 99c4873a31a2a711322a4ad7bc1cfec573dd96ea 해당 커밋에 분기를 다시 추가하였습니다. **제가 아직 상태 패턴에 대해 이해하고 사용하고 있다는 생각이 들지 않습니다... 코드가 작동하게 수정하였지만 나중에 다시 보도록 하겠습니다 ㅠㅠ**"*
+
+reviewer 최초 review:
+
+> *"강의 피드백에 나온 **상태 패턴은 아직 개념이 잘 안잡히셨을 부분이라 너무 어렵다면 모두 수정하지 않아도 됩니다.** 나중에라도 내 코드를 돌아봤을 때 이해가 되기만 하면 충분합니다."*
+
+→ **MCP 룰 `student-state-pattern-honest-doubt`** ⭐⭐⭐ 신규 — *상태 패턴 이해 어려움 솔직 인정 + 자가 추가-제거 분기 반복*. PR #18 (`student-honest-no-deep-thought`)·PR #106 (학생 *언제 관점 깨는가*) 결 합류 누적 3 PR.
+
+→ **MCP 룰 `reviewer-difficulty-acknowledgment-vocabulary`** ⭐⭐⭐ 신규 — *"어렵다면 모두 수정하지 않아도 됩니다", "나중에라도 돌아봤을 때 이해되면 충분"* — PR #115 *쎄게 양해* → PR #154 *어려움 인정 + 후일 학습 격려* 진화. **reviewer 양 PR 어휘 진화 메타** ⭐⭐⭐.
+
+### 6. 컨트롤러 + 비즈니스 로직 분리 — 상상 테스트 (Thread 14)
+
+reviewer:
+
+> *"한편으로는 작성해주신 블랙잭 게임은 컨트롤러와 비즈니스 로직을 모두 가지고 있습니다. 이러한 상상을 해보시면 어떤 느낌인지 알 수 있을 거에요.*
+> ***> 컨트롤러가 없더라도 블랙잭 게임을 진행할 수 있을까??***"*
+
+→ **MCP 룰 `controller-imagination-test`** ⭐⭐⭐ **신규 정점** — *컨트롤러 없이 게임 진행 가능? 상상 테스트*. PR #48·PR #72 (`controller-classification-criteria` *view 의존 + 테스트 가능*) 결의 *컨트롤러 분류* 다른 축 — *상상으로 결합도 진단*.
+
+→ **MCP `oh-my-oop` 핵심 가치 어휘** — *책임 분리 검증을 위한 상상 도구*.
+
+### 7. Deck 테스트용 팩토리 분리 (Thread 0)
+
+reviewer: *"카드가 항상 랜덤으로 섞이는데 특정 덱 상태로 테스트를 하려면 어떻게 해야 하나요?"*
+
+학생 자가 답변:
+
+> *"주 생생성자를 private으로 변경하고 동반 객체의 팩토리 메서드로 랜덤 덱을 생성하도록 변경하였습니다. **특정 덱 상태로 테스트가 어렵기 때문에 `createCustomDeck()`을 생성하였습니다. 주 생성자를 public으로 둘 것인지, 테스트를 위한 함수를 만들 것인지 고민하였으나, 카드 덱은 생성을 제어하는 편이 좋다고 생각하여 특정 덱 테스트를 따로 만들었습니다.**"*
+
+→ **MCP 룰 `factory-with-test-only-variant`** ⭐⭐ — *팩토리 + 테스트용 별도 팩토리 + 생성자 제어 어휘*. PR #15 *Deck DI*·PR #22 (`static-mutable-collection-unsafe`)·PR #115 *Deck DI 자가 답변* 결 합류.
+
+### 8. `_cards` var/val 어휘 (Thread 1)
+
+reviewer: *"`_cards`는 `var`와 `val`중 무엇이 어울릴까요?"*
+
+→ PR #12 (언더바 = backing property 컨벤션) 결 합류. 누적.
+
+### 9. `final` 키워드 활용 — Kotlin Tip (Thread 4)
+
+reviewer:
+
+> *"코틀린 Tip:*
+> *추상 함수에 구현체에 final 키워드를 붙이면 어떤 일이 생길까?*
+> *`override final fun`"*
+
+학생 자가 답변:
+
+> *"final 키워드를 붙이면 자식 클래스에서 override가 불가능해지므로, 자식 클래스에서 해당 함수를 수정하거나 변경할 수 없습니다. 필요하다면 부모 클래스의 해당 함수를 그대로 사용하게 됩니다."*
+
+→ **MCP 룰 `reviewer-kotlin-tip-vocabulary`** ⭐⭐ 신규 — *"코틀린 Tip:" 메타 어휘*. PR #82·#107·#80 (Kotlin 어휘 다수 학습) 결 누적 학습 어휘 패턴.
+
+→ **`override final` 어휘** ⭐ — 자식 override 차단.
+
+### 10. 결과 판단 — `Dealer` vs 상대 `State` (Thread 6)
+
+reviewer: *"결과를 판단하는데 있어 Dealer가 필요한건가요? 아니면 상대방의 State가 필요한건가요?"*
+
+학생 자가 답변: *"불필요한 객체 전달이었던 것 같습니다. state만 전달해도 충분해서 변경하였습니다."*
+
+→ **MCP 룰 `minimum-required-data-passing`** ⭐⭐ 신규 — *함수 인자에 필요한 최소 데이터만 전달 (객체 vs 상태)*. PR #38 (디미터 법칙) 결 합류.
+
+### 11. 추상 함수 구현체 = 파일별 테스트 (Thread 7)
+
+reviewer:
+
+> *"추상 함수의 구현체는 하나의 파일에서 모든 테스트를 작성하지 않습니다. 하나에서 모든 테스트를 하는 대신 개별적인 상태를 모두 파일로 나눠서 테스트 하도록 해주세요"*
+
+→ **MCP 룰 `subclass-tests-by-file`** ⭐⭐ 신규 — *상태 패턴 + 구현체 = 파일별 테스트 분리*. PR #12 *"하나의 파일 = 하나의 클래스"* 결 합류 — *테스트도 동일 원칙*.
+
+### 12. 입력 검증 — 타입 검사 vs null 체크 (Thread 8)
+
+reviewer: *"이 타입 검사가 필요한 행위인가요? 🤔"*
+
+학생 자가 답변: *"타입 검사보다는, 위에서 toIntOrNull()을 수행해주었기 때문에 null 체크 후 반환하는 것이 더 좋을 것 같습니다."*
+
+→ **`toIntOrNull-vs-type-check` 중복 검증** ⭐⭐ — *이미 nullable 표현된 데이터를 다시 타입 검사*. PR #86 (`redundant-validation-on-type-constraint`) 결 합류 누적 2 PR.
+
+### 13. `bettingAmount` 생성 시 vs `var` (Thread 9)
+
+reviewer: *"bettingAmount를 플레이어 생성할 때 받는 것과 var로 관리하는 것은 어떤 차이가 있나요?"*
+
+학생 자가 답변:
+
+> *"생성할 때 받으면 게임이 시작할 때부터 끝날 때까지 불변성을 보장할 수 있습니다. var은 중간에 배팅금이 변경될 때 사용하는 게 더 좋을 것 같습니다!"*
+
+→ **`construction-time-vs-mutation-time-invariant`** ⭐⭐ — *생성 시 받기 = 게임 전체 불변성 / `var` = 변경 가능*. PR #100·PR #154 누적.
+
+### 14. 함수 호출 순서 정렬 (Thread 11)
+
+reviewer: *"마이너하지만 사람이 코드를 읽을때 위에서 아래로 읽기 때문에 함수의 호출 순서에 따른 정렬을 맞춰주면 더욱 좋습니다."*
+
+→ **`function-order-by-call-flow`** ⭐ — 가독성 컨벤션. PR #38 *흐름 단위 개행* 결 합류.
+
+### 15. 딜러 카드 더 받기 = 딜러 비즈니스 로직 (Thread 12)
+
+reviewer: *"딜러가 카드를 더 뽑을 수 있는지는 딜러가 결정할 비즈니스 로직으로 보입니다."*
+
+→ **Tell-Don't-Ask + 딜러 자가 결정** = 누적 다수.
+
+## 대표 인용
+
+> [tobae-time PR 본문]
+> *"객체지향의 역할, 책임, 협력에 대한 이해도가 낮아서 객체지향의 사실과 오해라는 도서를 읽고 코드를 다시 작성"*
+
+→ **학생 자가 조영호 도서 인용 학습 어휘 정점**.
+
+> [tobae-time PR 본문]
+> *"rebase 과정에서 코드가 일부 날아갔는데 (...) 다시 해보는 것도 저한테는 연습이 될 수 있을 것 같아서 처음부터 다시 코드를 작성"*
+
+→ **학생 자가 손실 → 학습 기회 재해석 어휘**.
+
+> [laco-dev 최초 review]
+> *"강의 피드백에 나온 상태 패턴은 아직 개념이 잘 안잡히셨을 부분이라 너무 어렵다면 모두 수정하지 않아도 됩니다. 나중에라도 내 코드를 돌아봤을 때 이해가 되기만 하면 충분합니다."*
+
+→ **reviewer 어려움 인정 + 후일 학습 격려 어휘**.
+
+> [laco-dev 최종 review]
+> *"잘못이 많고 힘들다고 생각하시지 마시고 성장하는 과정이라고 봐주세요. 남은 우테코 기간도 응원하겠습니다."*
+
+→ **reviewer 성장 과정 격려 어휘 정점**.
+
+> [tobae-time Thread 13]
+> *"작성하면서 get과 set은 아닌 것 같다고 생각했는데, 적절한 네이밍을 생각하지 못해서 두었습니다. 알아차리지 못한 객체로 분리하라는 신호였던 것 같습니다..."*
+
+→ **학생 자가 어색함 → 객체 분리 신호 자각 어휘 정점**.
+
+> [tobae-time Thread 5]
+> *"제가 아직 상태 패턴에 대해 이해하고 사용하고 있다는 생각이 들지 않습니다... 코드가 작동하게 수정하였지만 나중에 다시 보도록 하겠습니다 ㅠㅠ"*
+
+→ **학생 자가 솔직 어려움 인정 어휘**.
+
+> [laco-dev Thread 14]
+> *"컨트롤러가 없더라도 블랙잭 게임을 진행할 수 있을까??"*
+
+→ **컨트롤러 상상 테스트 어휘 정점**.
+
+> [laco-dev Thread 13]
+> *"흔히 getXXX, setXXX 형태는 getter()와 setter()의 역할을 할 것이라고 기대합니다. 이 함수들을 다른 사람이 봐도 잘 이해가 될까요?"*
+
+→ **getter/setter 어휘 오해 시그널**.
+
+## 얻은 교훈 (보편)
+
+1. **PR 본문 학생 자가 조영호 「객체지향의 사실과 오해」 도서 인용** — **MCP 룰 `pr-body-self-learning-book-citation` 후보** ⭐⭐⭐ 정점.
+2. **상태 패턴 외부 변경 위험** — **MCP 룰 `state-pattern-external-mutation-risk` 후보** ⭐⭐⭐.
+3. **다형성 if 타입 검사 회피** — **MCP 룰 `state-pattern-no-if-type-check` 후보** ⭐⭐⭐. PR #73 결 누적 2 PR.
+4. **getter/setter 어휘 오해 → 객체 분리 신호** — **MCP 룰 `getter-setter-naming-as-missed-object` 후보** ⭐⭐⭐ 정점 (학생 자가 자각).
+5. **컨트롤러 상상 테스트 — *없어도 진행 가능?*** — **MCP 룰 `controller-imagination-test` 후보** ⭐⭐⭐.
+6. **학생 상태 패턴 솔직 어려움 인정 + reviewer 후일 격려** — **MCP 룰 `student-state-pattern-honest-doubt` + `reviewer-difficulty-acknowledgment-vocabulary` 후보** ⭐⭐⭐.
+7. **PR 본문 손실 → 학습 기회 재해석** — **MCP 룰 `pr-body-restart-from-scratch` 후보** ⭐⭐.
+8. **PR 본문 셀프 체크리스트 회의 마커 (`[x?]`)** — **MCP 룰 `pr-self-checklist-doubt-marker` 후보** ⭐⭐.
+9. **수익금 = 상태 객체 책임** — **MCP 룰 `state-as-domain-calculator` 후보** ⭐⭐.
+10. **추상 함수 구현체 = 파일별 테스트** — **MCP 룰 `subclass-tests-by-file` 후보** ⭐⭐.
+11. **최소 데이터 전달 (객체 vs 상태)** — **MCP 룰 `minimum-required-data-passing` 후보** ⭐⭐.
+12. **reviewer Kotlin Tip 어휘** — **MCP 룰 `reviewer-kotlin-tip-vocabulary` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **tobae-time 양 단계 완성 (1단계 #115 → 2단계 #154)** — *Rule god-object 학생 자가 시도 → 1단계 reviewer 강한 비판 → 학생 자가 도서 학습 → 2단계 상태 패턴 도입 (불완전 인정) → reviewer 격려 진화*. **학습 방향 전환 메타 케이스** ⭐⭐⭐ 정점.
+- **reviewer laco-dev 양 PR 어휘 진화** (#115 *"쎄게 피드백 양해"* → #154 *"성장 과정 격려 + 어려움 인정"*) — **MCP `oh-my-oop` reviewer 어휘 진화 메타** ⭐⭐⭐.
+- **메타 케이스 7번째 = 학생 학습 시간성 + 학습 방향성 + reviewer 어휘 진화 3중 메타** — 누적 메타 케이스:
+  1. krrong (1년 학생 → reviewer 진화)
+  2. hyemdooly (2년 학생 → reviewer 진화)
+  3. 말리빈 (2024→2025 reviewer 다년 활동)
+  4. 두루 (2024→2025 reviewer 다년 활동)
+  5. Hogu59 (1년 늦은 2단계 학습 시간성)
+  6. EmilyCh0 (1단계 단방향 → 2단계 자가 답변 9 thread 진화)
+  7. **tobae-time (Rule god-object → 상태 패턴 학습 방향 전환 + 도서 자가 학습 + reviewer 어휘 진화 3중)** ⭐⭐⭐.
+- **MCP `oh-my-oop` 도구 영감 도서 (조영호 「객체지향의 사실과 오해」) 학생 자가 인용** — 도구 가치 검증.

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

@@ -0,0 +1,235 @@
+# PR #25 — [블랙잭 1단계] 베리 미션
+
+- **Reviewee:** [@whk06061](https://github.com/whk06061)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/25
+- **단계:** 1단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 30 (리뷰어 19 / 리뷰이 11)
+- **참고:** PR #24 (otter66)와 *코드가 거의 동일* (페어 or fork). 다만 리뷰 토론이 별개.
+
+> ⚠ **PR #24와 공통 패턴은 그 문서 참고**. 본 문서는 *namjackson 리뷰어의 추가 발견*과 *학생 후속 반영*에 집중.
+
+## 잘한 점 (설계 관점)
+
+- **`BlackjackManager` 도입 (후속 반영)** — Controller god-object 회피 + 게임 진행자 분리 (PR #24보다 한 걸음 더).
+- **`CardsGenerator` 인터페이스 + `RandomCardsGenerator`** (후속) — Strategy.
+- **`Participants.values.forEach { participant.updateResult(dealer.cards.sumCardsNumber()) }`** — *참가자가 자기 결과 계산* (PR #28·#63 권고와 같은 결).
+- **테스트에 *given/when/then 주석*** — 학생 자가 인정.
+
+## 못한 점 (설계 관점 — PR #24와 공통)
+
+PR #24 (otter66)와 *공통 패턴*은 다음 (자세한 분석은 [PR #24](../otter66/24-1단계-블랙잭.md) 참고):
+
+- **`Result(val word: String)` enum의 UI 표현**.
+- **`Result.valueOf(dealerSum, participantSum)` 정적 비교자** — *참가자 메시지* 권고.
+- **`CardGenerator + RandomGenerator + Generator` 명사 중복**.
+- **`Player.generateCard()` = 카드 출처 책임이 Player**.
+- **`open class Player` + `Dealer : Player`** vs Participant 추상.
+- **`Cards.isBlackjack()` 복잡 (ACE+JQK 2장 특별 케이스)**.
+
+## 못한 점 (설계 관점 — PR #25 추가 패턴)
+
+### 1. `Participant.result: lateinit var` + `updateResult(dealerSum)` — *상태 캐싱 + 사이드 이펙트*
+
+```kotlin
+class Participant(name: String) : Player(name) {
+    lateinit var result: Result
+        private set
+    fun updateResult(dealerSum: Int) {
+        result = Result.valueOf(dealerSum, cards.sumCardsNumber())
+    }
+}
+```
+
+리뷰어: "*Result는 player들의 cards에 의존된 상태값으로 보여요, update를 통해 Result값을 내부에서 값을 변경하기보다, Result값을 생성하여 리턴*해주면 어떨까요?"
+
+학생 자가 인정: "*자신의 결과를 계산해주는 역할은 Result가 아닌 참여자가 하는게 맞는 것 같습니다!* 참여자가 자신의 승패 결과를 계산하도록 수정했습니다!"
+
+또 후속 댓글: "*updateResult를 사용하지 않고 result에 접근하거나, updateResult가 여러번 실행되거나, 게임이 종료되기전에 실행이 된다면, 여러 리스크*가 있을것 같아요. *dealerSum, Cards에 의존적인 Result를 상태로 가지고있으면 관리하기 힘들지 않을까요?* *Result를 반환하여 관리*하면 어떨까요?"
+
+→ **PR #33 (2chang5) `Player.consequence: lateinit + chooseWinner(score)`와 동일 결**. *lateinit + setter 캐싱*은 *호출 순서 invariant* + *stale 위험*. *fun match(other): Result* 반환이 정답.
+
+### 2. `Player.generateCard()`가 *외부 미사용 + 테스트만 사용*
+
+```kotlin
+open class Player(...) {
+    fun generateCard() { cards.addCard(generator.generateCard()) }
+}
+```
+
+리뷰어: "*generator와 해당 함수는 테스트 코드 외에선 사용되지않아요, 테스트를 위한 코드는 지양*해주세요!" — PR #63·#92와 같은 *테스트 위해 public화* 안티패턴. 학생 후속 인정: "*불필요한 함수를 삭제했습니다!*"
+
+### 3. `BlackjackManager.lateinit var participants` — `setup` 호출 순서 invariant
+
+```kotlin
+class BlackjackManager(cardsGenerator: CardsGenerator) {
+    val dealer = Dealer()
+    lateinit var participants: Participants
+        private set
+    fun setup(getNames: () -> List<String>) { ... }
+}
+```
+
+리뷰어: "*getNames을 람다로 받을 필요가 있을까요?* *lateinit var 는 지연된 초기화가 가능하지만 가변 변수인 var로 선언이 되곤합니다.* *setup통해 초기화 해주기보단, names를 생성자로 받고, 초기화하면 어떨까요?*" — PR #92·#29·#114·#34와 같은 *lateinit 패턴 + setup 호출 순서 의존*. `BlackjackManager(names: List<String>, generator: CardsGenerator)` 생성자 주입이 자연.
+
+또: *getNames를 callback으로 받음*도 *Controller → Manager → InputView 의존 역전*. *Controller가 names 만들어서 전달*이 자연.
+
+### 4. `BlackjackManager.provideParticipantMoreCard(participant, requestMoreCard, printResult)` — callback 폭증
+
+```kotlin
+fun provideParticipantMoreCard(
+    participant: Participant,
+    requestMoreCard: (String) -> Boolean,
+    printResult: (Participant) -> Unit,    // ⚠ View callback
+) {
+    while (true) {
+        val check = participant.checkProvideCardPossible()
+        if (check) {
+            val answer = requestMoreCard(participant.name)
+            if (answer) provideCard(participant)
+            printResult(participant)
+            if (!answer) break
+        }
+        if (!check) break
+    }
+}
+```
+
+리뷰어: "*printResult라는 람다명은 View의 역할을 담고 있는것 같아요!* *도메인 로직인 BlackJackManager는 View를 모르는데요*, *onProvideCard 같은 함수명을 사용*해보면 좋을거 같아요!" — *람다명에 View 어휘*(*printResult*)가 *도메인 → View 의존*을 *함수명에 가시화*. *람다 이름*은 *콜백 의미*(`onProvideCard` / `onCardDrawn`)로. PR #28·#33·#65와 같은 결.
+
+또: `Early return pattern 을 활용화면 로직이 단순화` — `if (!check) break; ...` 한 줄 단축.
+
+### 5. `BlackjackController`가 *BlackjackManager.data + 자체 반복문* — Tell-Don't-Ask 위반
+
+```kotlin
+fun run() {
+    blackjackManager.setup(inputView::readParticipantsName)
+    ...
+    provideParticipantsMoreCard()
+}
+private fun provideParticipantsMoreCard() {
+    blackjackManager.participants.values.forEach {
+        blackjackManager.provideParticipantMoreCard(it, ...)
+    }
+}
+```
+
+리뷰어: "*blackjackManager 에서 participants을 받아와서 반복문을 돌려 다시, provideParticipantMoreCard를 사용하고있네요, blackjackManager의 데이터를 받아와서 blackjackManager를 다시 사용하는것보다, blackjackManager에게 `blackjackManager.playParticipantTurns(...)`와 같은 함수를 통해 메세지를 전달*해서, 해당 역할 하도록 작업해보면 어떨까요?" — *manager.data → loop → manager.method* 패턴 = *Manager 객체의 데이터를 외부에서 다시 쓰는* 패턴. *playParticipantTurns(...)* 한 메서드로 *manager가 자기 데이터 처리*.
+
+### 6. `CardDeck.checkProvidePossible()` + `provide(): Card` — null 반환 회피
+
+```kotlin
+class CardDeck(cardsGenerator: CardsGenerator) {
+    fun checkProvidePossible(): Boolean {
+        if (_cards.isNotEmpty()) return true
+        return false
+    }
+    fun provide(): Card {
+        val card = _cards[0]
+        _cards.removeAt(0)
+        return card
+    }
+}
+```
+
+리뷰어: "*checkProvidePossible를 통해 사전에 값이 비어있는걸 체크하여도 되지만, 보통 코틀린의 경우, 해당 값이 없는경우 null을 리턴하곤* 합니다! *`provide(): Card?` provide시, 카드가 없다면 null을 리턴*해보도록하면 어떨까요?" — **Java pre-check + 호출 < Kotlin null 반환**. PR #135·#116과 같은 결. *호출자가 check → call*은 *경쟁 조건* 위험(single-thread에서는 안전하지만 *의도가 명확하지 않음*).
+
+또: `_cards[0]` + `_cards.removeAt(0)` 두 줄을 `_cards.removeFirstOrNull()` 한 줄로.
+
+### 7. `Cards.isBlackjack` 복잡 분기 — PR #24와 동일
+
+```kotlin
+private fun isBlackjack(): Boolean {
+    if (_cards.size != 2) return false
+    val condition1 = _cards.filter { it.number == CardNumber.ACE }.size
+    val condition2 = _cards.filter {
+        listOf(CardNumber.KING, CardNumber.QUEEN, CardNumber.JACK).contains(it.number)
+    }.size
+    if (condition1 == 1 && condition2 == 1) return true
+    return false
+}
+```
+
+리뷰어: "*블랙잭 판별로직이 복잡한것 같아요!* *`점수는 21점 && 카드는 2장`* *좀더 간단하게 판별할수 있을것 같아요!*" — `score == 21 && cards.size == 2` 한 줄. PR #128·#116·#119와 같은 결.
+
+또: "*여기서 BlackJack 분기처리할필요가 없지않을까요? calculateAceSum을 통해 같은 결과가 나올거 같아요!* --- *카드가 ace인지에 대한 부분은 Card에서 처리되어야할 책임 아닐까요?*" — `Card.isAce()`로 *카드 자신의 책임*. PR #10·#79와 같은 결.
+
+### 8. `Dealer.results: MutableMap<Result, Int>` 공개 — 일급 컬렉션 부재
+
+```kotlin
+class Dealer(name: String = "딜러") : Player(name) {
+    val results: MutableMap<Result, Int> = Result.values().associateWith { 0 }.toMutableMap()
+}
+```
+
+리뷰어: "*MutableMap<Result, Int>는 무엇을 의미할까요? 일급컬렉션을 만들어보면 어떨까요?*" — `DealerResults(winCount: Int, loseCount: Int, drawCount: Int)` 또는 *Map wrapper*. *Map 자료구조 노출*은 *호출자가 키 추측*. PR #81·#125와 같은 결.
+
+### 9. `CardsTest`에서 *addCard에 의존*
+
+```kotlin
+@Test fun `갖고 있는 카드 숫자의 합을 계산해 반환한다`() {
+    val cards = Cards()
+    cards.addCard(Card(CardNumber.ONE, CardShape.DIAMOND))   // ⚠ addCard에 의존
+    cards.addCard(Card(CardNumber.JACK, CardShape.CLOVER))
+    val actual = cards.sumCardsNumber()
+    assertThat(actual).isEqualTo(21)
+}
+```
+
+리뷰어: "*sumCardsNumber 함수로 카드 숫자의 합을 계산하는 테스트이지만, 이 테스트는 addCard라는 다른 함수에 테스트가 의존적인 테스트입니다.* *이러한 테스트는 신뢰성이 낮다고 볼수있습니다.* *addCard로 테스트 준비하기 보단, 생성자* ..." — *테스트 setup이 다른 메서드*에 의존하면 *해당 메서드 버그*가 *대상 테스트도 깨뜨림*. *생성자 주입* (`Cards(listOf(...))`)이 자연. 학생 후속: 생성자 주입 채택.
+
+### 10. `Dealer.decideParticipantsResult(participants)` — Dealer가 결과 결정
+
+```kotlin
+dealer.decideParticipantsResult(participants)
+dealer.decideDealerResult(participants)
+```
+
+리뷰어: "*해당 함수는, 누구의 기준의 승/패를 나타내는걸까요?* *결과를 계산해주는 역할을 각각의 참여자에게 부여*해보면 어떨까요? *참여자가 Result를 반환하는 구조라면 좀더 직관적*일것 같아요!" — PR #10·#28·#63 권고와 동일. 학생 후속: `participant.updateResult(dealerSum)`로 *반쯤 이동* — *Int 인자*로 받음으로써 *완전한 Tell-Don't-Ask는 아님*.
+
+## 리뷰어 의견 요지
+
+- ***`lateinit result + updateResult` 사이드 이펙트 setter < `match(other): Result` 반환***.
+- ***테스트 위해 public 메서드 = 코드 결함***.
+- ***`lateinit + setup` 호출 순서 invariant***.
+- ***View callback의 *람다 이름*에 View 어휘 = 의존 가시화***.
+- ***Early return으로 단순화***.
+- ***manager.data → loop → manager.method = manager에 메시지로 이동***.
+- ***Kotlin null 반환 < Java pre-check + call***.
+- ***블랙잭 판별 = `점수 21 && 카드 2장` 한 줄***.
+- ***Card.isAce가 Card의 책임***.
+- ***MutableMap 공개 < 일급 컬렉션***.
+- ***테스트 setup이 다른 메서드 의존 = 신뢰성 ↓***.
+- ***Dealer 비교자 < 참가자 자기 결과***.
+
+## 대표 인용
+
+> Result는 player들의 cards에 의존된 상태값으로 보여요, *update를 통해 Result값을 내부에서 값을 변경하기보다, Result값을 생성하여 리턴*해주면 어떨까요?
+> — @namjackson on `Participant.kt`
+
+> *blackjackManager의 데이터를 받아와서 blackjackManager를 다시 사용하는것보다*, blackjackManager에게 `blackjackManager.playParticipantTurns(...)`와 같은 함수를 통해 *메세지를 전달*해서, 해당 역할 하도록 작업해보면 어떨까요?
+> — @namjackson on `BlackjackController.kt`
+
+> 보통 코틀린의 경우, 해당 값이 없는경우 *null을 리턴*하곤 합니다! `provide(): Card?` provide시, 카드가 없다면 *null을 리턴*해보도록하면 어떨까요?
+> — @namjackson on `CardDeck.kt`
+
+> printResult라는 *람다명은 View의 역할*을 담고 있는것 같아요! *도메인 로직인 BlackJackManager는 View를 모르는데요*, *onProvideCard 같은 함수명*을 사용해보면 좋을거 같아요!
+> — @namjackson on `BlackjackManager.kt`
+
+> sumCardsNumber 함수로 카드 숫자의 합을 계산하는 테스트이지만, *이 테스트는 addCard라는 다른 함수에 테스트가 의존적인 테스트*입니다. *이러한 테스트는 신뢰성이 낮다고 볼수있습니다.*
+> — @namjackson on `CardsTest.kt`
+
+## 얻은 교훈
+
+- ***`lateinit result + updateResult(dealerSum)` 사이드 이펙트 setter = `match(other): Result` 반환의 변형*** — *Int 인자로 받음*은 *Tell-Don't-Ask 부분 위반*. *상대 객체*를 받아야 *동일 추상에 메시지*.
+- ***테스트 위해 public 메서드 = 코드 결함 신호*** — *입력 → 출력*으로 검증. PR #63·#92와 같은 결.
+- ***`BlackjackManager.setup(getNames: () -> List<String>)`은 callback이 자연스럽지 않음*** — *값을 받아 명시 주입*. *람다 변환*이 *호출자 의존 시점 분산*.
+- ***View callback의 *람다 이름*에 View 어휘 (`printResult`/`displayCards`) = 도메인 → View 의존 가시화*** — `onProvideCard` 같은 *사건 어휘*가 도메인 어휘.
+- ***Early return + null 반환은 Kotlin 컨벤션***.
+- ***manager.data → 외부 loop → manager.method = 응집도 부족*** — *manager.playTurns()*로 *manager가 자기 데이터 처리*.
+- ***`provide(): Card?` null 반환 < `checkProvidePossible()` + `provide()` 분리*** — *경쟁 조건 + 의도 명시 부족*.
+- ***블랙잭 판별 = `score == 21 && cards.size == 2` 한 줄*** — *condition1/condition2* 같은 *추상 변수*는 의도 흐림. PR #128·#116과 같은 결.
+- ***`Card.isAce()` = Card의 책임*** — *Cards가 it.number == ACE* 비교는 *Card 내부 표현 누수*.
+- ***`MutableMap<Result, Int>` 공개 = 일급 컬렉션 부재*** — `DealerResults` 객체로 *의미 명시*.
+- ***테스트 setup이 다른 메서드 의존 = 그 메서드 버그로 대상 테스트도 깨짐*** — 생성자 주입.
+- ***Dealer.decideResults() < participant.match(other)*** — *결과 책임이 참가자*.