oh-my-oop 0.2.0

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

@@ -0,0 +1,230 @@
+# PR #62 — [블랙잭] 해음 1단계 미션
+
+- **Reviewee:** [@haeum808](https://github.com/haeum808) (해음) — 안드로이드 6기 코호트
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/62
+- **단계:** 1단계
+- **리뷰어:** [@ghojeong](https://github.com/ghojeong) (파이로)
+- **라인 코멘트:** 10 스레드 — *학생 자가 답변 9 thread + PR 본문 자가 질문 (calculated property vs 메서드) / 함수형 프로그래밍 어휘 정점 (index loop = LISP 절차지향 / map·filter·reduce 3종 / Lazy Evaluation / Higher Order Function) + reviewer *강한 피드백 자가 수정* 메타 + 학생 Slack DM 자가 학습 메타 + Mutable 팀 정책 단일 답 X*
+- **신규 reviewee** (안드로이드 6기 코호트).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 질문 — calculated property vs 메서드
+
+PR 본문:
+
+```kotlin
+// 현재 사용
+val total: Int
+    get() = cards.sumOf { it.value }
+
+// 후보
+fun calculateTotal(): Int {
+    return cards.sumOf { it.value }
+}
+```
+
+> *"위와 같이 GameInfo 클래스 안에서 calculated 프로퍼티인 total를 사용할 수도 있고 calculateTotal처럼 메서드로 만들 수도 있다고 생각합니다. **그런데 가독성이 더 좋고 복잡한 로직이 아니라 total을 사용했습니다. 이렇게 코드를 작성해도 괜찮을까요?**"*
+
+→ **MCP 룰 `pr-body-property-vs-method-question`** ⭐⭐ 신규 — *계산 프로퍼티 vs 메서드 학생 자가 의문 명시*. PR #30·#144 결의 *PR 본문 자가 질문* 다른 축.
+
+### 2. Higher Order Function 추상화 칭찬 (Thread 6)
+
+reviewer:
+
+> *"특히 마음에 들었떤 부분은 Dealer 와 Player 를 Participant 라는 인터페이스로 추상화 하고, generateCard 와 printCards 를 **Higher Order Function** 으로 추상화를 해주셨다는 부분입니다. 👍 💯*
+>
+> *옛날에 interface 나 class 상속 문법이 지원되지 않는 언어로 개발을 하다가, 사수분이 추상화를 해주세요 라고 피드백을 해주셔서 멘붕을 했던 과거가 제게 있습니다. **그런 상황에서는 HIgher Order Function 만으로도 굉장히 많은 추상화를 할 수 있었다**고, 제 개인 에피소드를 공유해봅니다."*
+
+→ **MCP 룰 `higher-order-function-as-abstraction-alternative`** ⭐⭐⭐ 신규 — *상속 X / interface X 환경에서 HOF로 추상화*.
+
+→ **`reviewer-personal-episode-vocabulary`** ⭐⭐ — *reviewer 본인 사수 멘붕 에피소드 공유 — 어휘 정당화*.
+
+### 3. `LOW_ACE` / `HIGH_ACE` data class 분리 — "천재적 아이디어" (Thread 7)
+
+```kotlin
+data class Card(val number: CardNumber, val value: Int)
+data class CardValue(val value: Int)
+```
+
+reviewer:
+
+> *"static 팩토리 외에 아무런 로직이 없는 class 를 data class 로 선언해 주신 점 마음에 듭니다. 👍 특히 Card 와 CardValue 2개로 data class 를 분리해주셔서, **LOW_ACE 인 경우와 HIGH_ACE 인 경우를 동일한 Card data class 로 표현할 수 있도록 한 점이 정말 천재적인 아이디어 같습니다.** 👍 💯"*
+
+→ **MCP 룰 `ace-as-low-high-data-class-pattern`** ⭐⭐ 신규 도메인 특수 — *Ace 1↔11 양가성을 LOW_ACE/HIGH_ACE 데이터 분리로 표현*. 블랙잭 도메인 룰 정확성.
+
+### 4. `playRound` 깔끔 칭찬 (Thread 5)
+
+reviewer:
+
+> *"제가 forEach 가 절차지향적이라고 말은 했지만, 제가 forEach 문법을 금지하려 한 것은 아닙니다. Haskell 과 같은 순수함수형 언어에서도 결국 순수해지지 못하는 순간이 있는데, 바로 **interrupt 가 필요한 순간**입니다. read 와 print 는 대표적인 시스템 IO 인터럽트이고, 인터럽트의 반복에는 이처럼 forEach 를 활용할 수 밖에 없습니다. playRound 매우 깔끔하게 잘 구현해주신 것 같아서 그에 대한 칭찬을 해봅니다. 👍"*
+
+→ **MCP 룰 `interrupt-as-functional-impurity-justification`** ⭐⭐ 신규 — *시스템 IO 인터럽트 = 함수형 한계 + forEach 정당*.
+
+## 못한 점 (설계 관점)
+
+### 1. index loop = 절차지향 + LISP / Lazy Evaluation 어휘 (Thread 1) — 정점
+
+```kotlin
+for (i in 0 until players.size) { players[i]... }
+```
+
+reviewer:
+
+> *"size 크기를 통한 index 가 사용된 반복문이 있다면, **굉장히 절차지향적인 코드를 짜고 있지는 않나 의심해 볼 필요가 있습니다.***
+>
+> *절차지향이 나쁘다는 의미는 아닙니다. 하지만 **index 를 통한 Element 의 접근은 가상메모리와 1대1 대응이 되는 \"Array\" 를 위한 문법이지, \"List\" 를 위한 문법은 아닙니다.***
+>
+> ***[List 는 LISP](https://www.tutorialspoint.com/lisp/lisp_lists.htm) 라는 프로그래밍 언어에서 중요하게 도입되었던 개념인데, 전통적으로 List 는 single linked list 를 뜻합니다. 즉 index 가 5라면 List 에서 5개의 node 를 루프를 돌아서 건너뛰어야 한다는 것을 의미합니다.***
+>
+> *요즘은 메모리가 부족한일이 없어서 HashMap 형태로 최적화가 되어있지만, 만약 함수형 프로그래밍을 연습하고자 한다면, **index 를 사용하지 않도록 연습하시는게 좋습니다. 왜냐하면 이러한 연습이 Lazy Evaluation 이라는 함수형 프로그래밍의 특성을 익히는데 큰 도움이 되기 때문**입니다."*
+
+학생 자가 답변:
+
+> *"HashMap으로 최적화되어 있는지 처음 알았습니다. 감사합니다. Lazy Evalutation을 사용하기 위해 Sequence를 활용하겠습니다."*
+
+reviewer 정정:
+
+> *"엄밀히 이야기 하면 JVM 은 ArrayList 로 최적화가 됩니다. 하지만 코틀린은 자바스크립트로 컴파일도 가능하므로, 넓은 의미에서 해시맵이라고 표현하였습니다."*
+
+학생: *"List로 초기화하면 MutableList가 불리고 MutableList에서 ArrayList에 값을 넣는 방식이라는 것을 배우게 됐습니다. 감사합니다!"*
+
+→ **MCP 룰 `index-loop-as-procedural-signal`** ⭐⭐⭐ **신규 정점** — *index loop = 절차지향 시그널 + LISP single linked list + JVM ArrayList vs HashMap 어휘 + Lazy Evaluation 함수형 특성*.
+
+→ **MCP 룰 `kotlin-sequence-as-lazy-evaluation`** ⭐⭐ — *Sequence = Lazy Evaluation 어휘*.
+
+### 2. forEach = 절차지향 시그널 + reviewer 강한 피드백 자가 수정 (Thread 2) — 정점
+
+reviewer 초기:
+
+> *"마찬가지로 forEach 문법이 사용되고 있다면, 내가 절차지향적으로 사고하고 있지는 않나 의심해볼 필요가 있습니다. **함수형으로 코딩한다면 대부분의 상황은 map, filter, reduce 3가지로 전부 해결할 수 있다고 생각하셔도 좋습니다.** 가령 저는 위의 코드만 보고서, 실제 내부 model 의 코드를 보지 않았음에도, 저는 함수형에서 제일 중요한 특성 중 하나인 \"불변\" 이 깨졌다는 것을 바로 알 수 있었습니다."*
+
+학생 자가 답변:
+
+> *"이 부분도 Players로 위치를 변경하여 Contrlloer에서 비즈니스로직을 없애주었습니다. **궁금한점이 forEach를 도메인 로직에서 쓰면 절차지향적이 아니게 될 수 있는지 궁금합니다!**"*
+
+reviewer:
+
+> *"그건 아닙니다. 절차지향은 절차지향입니다. **만약 루프를 돌면서 상태(멤버)값을 변경한다면 그것은 매우 전통적인 튜링머신에서의 절차지향적 프로그래밍 방법입니다.** 다만 로직을 도메인 영역으로 옮겨주었으므로, 테스트나 유지보수 관점에서 매우 좋은 리팩토링을 해주셨다고 생각합니다."*
+
+학생: *"감사합니다! 절차지향적인 것과 절차지향적이지 않은 것을 구별할 능력을 키워보겠습니다. for문을 제거하고 함수지향적으로 작성하겠습니다."*
+
+reviewer **자가 수정 정점**:
+
+> *"@haeum808 *
+>
+> ***헉! for 문을 제거하라는 피드백이 절대 아니었습니다. 절차지향이 나쁜 게 아니라고 고정관념을 깨고 싶어서 말씀드렸습니다.** 저는 지금 모양도 충분히 예쁘다고 생각합니다. **함수형으로도 할 수 있다 이지, 함수형으로 꼭 해달라는 피드백이 아니었습니다.***
+>
+> *다시 강조하지만 저는 객체설계 예쁘게 무척 잘해주셨다고 생각합니다."*
+
+reviewer 추가:
+
+> *"오히려 저는 지금 리팩토링이 해음이 생각하기에 만족스럽다면, step2 로 넘어갈 수 있도록 머지시켜드리고 싶습니다."*
+
+→ **MCP 룰 `reviewer-self-correction-on-strong-feedback`** ⭐⭐⭐ **신규 정점** — *reviewer 강한 피드백 → 학생 자가 잘못 이해 → reviewer *자가 수정 + 강요 X 명시***. PR #115 (laco-dev *쎄게 양해*)·PR #73 (`reviewer-don't-be-swayed`)·PR #106 (말리빈 *권력 자제*) 결의 *reviewer 권력 자제* 어휘 누적 4 PR → ***reviewer 자가 강요 회피 어휘 정점*** ⭐⭐⭐.
+
+→ **MCP 룰 `foreach-as-procedural-signal-but-not-forbidden`** ⭐⭐⭐ — *forEach = 절차지향 시그널 / 금지 X*. PR #73 (`is-operator-polymorphism-avoidance`) 결 합류.
+
+→ **MCP 룰 `map-filter-reduce-as-functional-toolkit`** ⭐⭐⭐ — *함수형 3 도구 어휘 정점*.
+
+→ **MCP 룰 `state-mutation-in-loop-as-procedural-signal`** ⭐⭐⭐ — *루프 + 상태 변경 = 튜링머신 절차지향*.
+
+### 3. Mutable 팀 정책 단일 답 X + 변경 메서드 전체 테스트 (Thread 3·4·9)
+
+reviewer:
+
+> *"어디까지 불변을 강제하고, Mutable 을 허용해줄까는 **개발팀마다 다릅니다.** 정말 철저하게 함수형 프로그래밍을 추구하는 곳에서는, 데이터단방향 구조를 위해 model 혹은 domain 에서 모든 종류의 Mutable 을 허용하지 않습니다.*
+>
+> *하지만 저는 그보다는 좀더 느슨한 기준을 가져가려합니다. 왜냐하면 **코틀린은 철저한 함수형 프로그래밍 언어로 설계된 언어가 아니기 때문입니다.** 만약 Mutable 한 멤버가 있다면, **해당 멤버를 변경할 수 있는 모든 메서드에 대해서 테스트 코드를 작성해주시면 됩니다.**"*
+
+reviewer (Thread 4·9):
+
+> *"gameInfo 에서 addCard 를 할 때, 단순히 카드의 개수만 테스트하는게 아니라, **실제로 카드 추가후 cards 의 값이 어떻게 바뀌었는지 전부 테스트해주시기 바랍니다.**"*
+
+> *"불변을 깨트리는 모든 종류의 함수에 대해서, 함수 호출 후 값이 어떻게 바뀌었는지 더 자세하게 테스트 작성 부탁드립니다. 가령 여기서도 **단순히 size 값이 아니라 실제 내부 Card 가 무엇무엇을 갖게 되었는지 테스트를 통해 알 수 있으면 좋겠습니다.**"*
+
+→ **MCP 룰 `mutable-team-policy-no-single-answer`** ⭐⭐⭐ **신규** — *불변/Mutable 허용 = 팀마다 다름 (단일 답 X)*. PR #38 (`exception-handling-location-no-right-answer`) 결 합류 → ***단일 답 거부 어휘 누적 2 PR***.
+
+→ **MCP 룰 `mutable-member-comprehensive-state-test`** ⭐⭐⭐ — *Mutable 멤버 변경 메서드 = 모든 메서드 + 내부 값 전체 테스트 (size X)*.
+
+### 4. CardValue 원시값 포장 (Thread 8)
+
+```kotlin
+// 변경 전
+cardValue.value == LOW_ACE_VALUE && total <= MAXIMUM_HIGH_ACE_THRESHOLD
+```
+
+reviewer: *"다만 Card 에서 `val value: Int` 라고 int 원시값을 가지고, 상수값과 ONE 을 긴 로직으로 직접 비교하는 것은 좀더 포장될 필요가 있지 않을까 하는 생각을 했습니다."*
+
+학생 자가 답변:
+
+> *"좋은 것 같습니다. 그런데 LOW_ACE와 HIGH_ACE를 추가하면 CardDeck에 두 개가 들어가서 GameInfo에서 합을 계산하는 로직으로 변경했습니다."*
+
+→ **원시값 포장 + 학생 자가 도메인 룰 발견** = 누적 다수.
+
+### 5. JVM jvmTarget 설정 (Thread 0)
+
+reviewer: *"이미 KotlinComplie 에서 jvmTarget 을 17로 명시하고 있음에도, JavaCompile 을 한번 더 명시한 이유가 있나요?"*
+
+학생 자가 답변:
+
+> *"자바 타겟 버전이 21로 설정되어 있어서 clean test 명령어를 실행시 오류가 발생했습니다. 자바 타겟을 17로 변경하여 위 코드를 삭제했습니다."*
+
+→ **JVM 설정 = 환경 의존 오류** ⭐ — Gradle 어휘.
+
+## 대표 인용
+
+> [ghojeong Thread 1]
+> *"index 를 통한 Element 의 접근은 가상메모리와 1대1 대응이 되는 \"Array\" 를 위한 문법이지, \"List\" 를 위한 문법은 아닙니다."*
+
+→ **index loop = Array 문법 / List 부적합 어휘**.
+
+> [ghojeong Thread 1]
+> *"List 는 LISP 라는 프로그래밍 언어에서 중요하게 도입되었던 개념인데, 전통적으로 List 는 single linked list 를 뜻합니다."*
+
+→ **LISP single linked list 어휘**.
+
+> [ghojeong Thread 2]
+> *"함수형으로 코딩한다면 대부분의 상황은 map, filter, reduce 3가지로 전부 해결할 수 있다고 생각하셔도 좋습니다."*
+
+→ **함수형 3 도구 어휘 정점**.
+
+> [ghojeong Thread 2 자가 수정]
+> *"헉! for 문을 제거하라는 피드백이 절대 아니었습니다. 절차지향이 나쁜 게 아니라고 고정관념을 깨고 싶어서 말씀드렸습니다. 함수형으로도 할 수 있다 이지, 함수형으로 꼭 해달라는 피드백이 아니었습니다."*
+
+→ **reviewer 강한 피드백 자가 수정 어휘 정점**.
+
+> [ghojeong Thread 3]
+> *"어디까지 불변을 강제하고, Mutable 을 허용해줄까는 개발팀마다 다릅니다."*
+
+→ **단일 답 거부 어휘**.
+
+> [ghojeong Thread 6]
+> *"옛날에 interface 나 class 상속 문법이 지원되지 않는 언어로 개발을 하다가, 사수분이 추상화를 해주세요 라고 피드백을 해주셔서 멘붕을 했던 과거가 제게 있습니다. 그런 상황에서는 HIgher Order Function 만으로도 굉장히 많은 추상화를 할 수 있었다고, 제 개인 에피소드를 공유해봅니다."*
+
+→ **reviewer 개인 에피소드 어휘**.
+
+> [ghojeong 최종 review]
+> *"불변성 관련해서 Slack DM 으로 핵심적인 포인트를 짚어주셔서 굉장히 놀랐습니다. reduce, map, filter를 잘 활용하고 불변성을 생각하면서 step2 에서 함수형프로그래밍에 다시 도전하겠습니다고 Slack DM 으로 말씀주셨는데, 기대하겠습니다!"*
+
+→ **학생 Slack DM 자가 학습 메타 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **index loop = 절차지향 시그널 + LISP/Lazy Evaluation** — **MCP 룰 `index-loop-as-procedural-signal` 후보** ⭐⭐⭐ 정점.
+2. **forEach = 절차지향 시그널 + 금지 X (reviewer 자가 수정)** — **MCP 룰 `foreach-as-procedural-signal-but-not-forbidden` + `reviewer-self-correction-on-strong-feedback` 후보** ⭐⭐⭐ 정점.
+3. **map·filter·reduce 함수형 3 도구** — **MCP 룰 `map-filter-reduce-as-functional-toolkit` 후보** ⭐⭐⭐.
+4. **Mutable 팀 정책 단일 답 X** — **MCP 룰 `mutable-team-policy-no-single-answer` 후보** ⭐⭐⭐. PR #38 결 누적 2 PR.
+5. **Mutable 멤버 변경 메서드 전체 + 내부 값 테스트** — **MCP 룰 `mutable-member-comprehensive-state-test` 후보** ⭐⭐⭐.
+6. **Higher Order Function = 추상화 대안** — **MCP 룰 `higher-order-function-as-abstraction-alternative` 후보** ⭐⭐⭐.
+7. **interrupt (read/print) = 함수형 한계 + forEach 정당** — **MCP 룰 `interrupt-as-functional-impurity-justification` 후보** ⭐⭐.
+8. **Ace LOW/HIGH data class 분리 (블랙잭 도메인)** — **MCP 룰 `ace-as-low-high-data-class-pattern` 후보** ⭐⭐.
+9. **루프 + 상태 변경 = 튜링머신 절차지향** — **MCP 룰 `state-mutation-in-loop-as-procedural-signal` 후보** ⭐⭐⭐.
+10. **PR 본문 계산 프로퍼티 vs 메서드 자가 질문** — **MCP 룰 `pr-body-property-vs-method-question` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **haeum808 안드로이드 6기 코호트 새 reviewee** — *PR 본문 자가 질문 + 학생 자가 답변 9 thread 풍부 + Slack DM 자가 학습 메타*.
+- **ghojeong reviewer 어휘 정점** — *함수형 프로그래밍 어휘 정점 (LISP/Lazy Evaluation/HOF/IO 인터럽트) + 단일 답 거부 + 강한 피드백 자가 수정 + 개인 에피소드 공유* 다축 어휘.
+- **학생 자가 Slack DM 학습 메타** — *PR 외 reviewer 1:1 DM 통한 자가 학습 깊이 → 다음 단계 도전 약속* — **MCP 룰 `student-slack-dm-learning-meta` 후보** ⭐⭐ 신규. PR #144 (m6z1 셀프 코드 리뷰) 결의 *PR 외 학습 채널* 다른 축.
+- **`oh-my-oop` 핵심 가치 어휘 누적**: 단일 답 거부 어휘 누적 2 PR (#38 + #62) + reviewer 자가 강요 회피 어휘 누적 4 PR (#115 + #73 + #106 + #62).

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

@@ -0,0 +1,169 @@
+# PR #89 — [블랙잭] 해음 2단계 미션
+
+- **Reviewee:** [@haeum808](https://github.com/haeum808) (해음) — 안드로이드 6기 코호트
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/89
+- **단계:** 2단계
+- **리뷰어:** [@ghojeong](https://github.com/ghojeong) (파이로)
+- **라인 코멘트:** 9 스레드 — *PR 본문 flux 상태 아키텍쳐 자가 학습 적용 + reviewer 자가 반성 *미션 본 목표 복귀 + 2단계 갈아엎기 요청* 메타 정점 + State 패턴 2 기준 (다형성 + Context 책임) + 매직 넘버 제거 + map 함수형 어휘 진화 + 콜백 String → Boolean 리턴*
+- **haeum808 양 단계 완성** (1단계 #62).
+- **메타 케이스 정점**: PR 본문 학생 자가 *reviewer 추천 flux 상태 아키텍쳐 자가 학습* → reviewer 자가 반성 *"순수 코틀린 객체 설계 본 목표를 벗어남"* → 2단계 *싹 갈아엎기* 요청 → 학생 자가 도전 → reviewer 감사. PR #62 reviewer 자가 수정 + PR #89 reviewer 미션 목표 복귀 = ghojeong 양 PR reviewer 자가 반성 어휘 연속.
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — flux 상태 아키텍쳐 자가 학습
+
+PR 본문:
+
+> *"파이로가 말씀해주신대로 flux 상태 아키텍쳐을 공부하고 적용했습니다! step2를 진행하기 전 step1에 flux 상태 아키텍쳐를 적용하고 시작했습니다. 확실히 단방향으로 상태가 흐르니 새로운 상태를 추가할 때도 편하게 추가할 수 있었습니다. 새로운 상태를 추가해도 다른 곳에서 에러가 나오지 않아서 손쉽게 추가할 수 있었습니다."*
+
+→ **MCP 룰 `pr-body-student-self-study-on-reviewer-recommendation`** ⭐⭐⭐ **신규** — *reviewer 추천 어휘를 학생 자가 학습 + 적용 + PR 본문 명시*. PR #154 (tobae-time 조영호 도서 자가 학습) 결 합류 누적 2 PR → ***학생 자가 학습 도서/어휘 인용 메타*** ⭐⭐⭐ 정점.
+
+### 2. State 패턴 + Participant interface 칭찬 (Thread 1·2)
+
+reviewer:
+
+> *"State 디자인 패턴을 활용해주셨군요 👍. 저는 State 디자인 패턴은 다음 두가지를 확인합니다.*
+> *1. **다형성(Polymorphism) 을 어떻게 활용했는가?***
+> *2. **Context 의 책임을 어느 객체에게 부여했는가?***
+>
+> *draw 와 profit 이 State 가 바뀔 때마다 다른 로직이 실행될 수 있도록, State 를 interface 로 먼저 추상화 해주신 점 무척 멋집니다. 👍 💯"*
+
+reviewer (Thread 2):
+
+> *"현재 State 의 Context 는 Dealer 와 Player 라고 이해했습니다. Dealer 와 Player 를 다시 Participant 라는 interface 로 추상화 해주신 점 멋집니다. 👍 interface 를 정말 잘 활용해 주신 것 같습니다."*
+
+→ **MCP 룰 `state-pattern-2-criteria`** ⭐⭐⭐ **신규 정점** — *State 패턴 점검 기준 2: (1) 다형성 활용 + (2) Context 책임 부여*. PR #154 (`state-pattern-no-if-type-check` 다형성)·PR #42 (불변 + 상태 패턴) 결 합류 누적 3 PR → ***State 패턴 어휘 정점*** ⭐⭐⭐.
+
+### 3. TestFixtures 칭찬 (Thread 5)
+
+reviewer: *"테스트를 위한 Fixture 를 선언해 주신 점 무척 좋습니다. 👍 💯"*
+
+### 4. map + 방어적 복사 함수형 어휘 진화 (Thread 8) — 정점
+
+reviewer:
+
+> *"크으! map 의 활용이 매우 능숙해 지셨다는 느낌을 받았습니다. 👍 게다가 방어적 복사까지 신경써 주셔서 더욱 멋집니다. 👍*
+>
+> *다만, **map 안의 while 문은 indentation depth 를 깊게하는 요인인 것 같은데, 이 로직을 State, Player 등등의 객체에 배분하거나, 함수 분리를 해주시면 좋을 것 같습니다.**"*
+
+→ **학생 함수형 어휘 진화** = 1단계 PR #62 *학생 자가 Slack DM 학습* → 2단계 *map 능숙 + 방어적 복사*. **메타 학습 시간성**.
+
+→ **MCP 룰 `map-with-while-as-indentation-depth-signal`** ⭐⭐ 신규 — *map 안 while = depth 깊어짐 → 책임 배분*.
+
+## 못한 점 (설계 관점)
+
+### 1. reviewer 자가 반성 + 미션 본 목표 복귀 + 2단계 갈아엎기 요청 (review #1) — 정점
+
+reviewer:
+
+> *"해음! 제가 반응형 프로그래밍 덕후이다 보니, 순수 코틀린 언어에서의 객체 설계라는 주제를 벗어나는 방향으로, 해음과 대화를 많이하게 된 것 같습니다.*
+>
+> ***저도 반성을 하면서, 블랙잭 미션의 본래 목표인 객체 설계로 되돌아가고자 합니다.***
+>
+> ***죄송하지만, 2단계 미션의 구조를 버리고 다시 작성해주시면 감사하겠습니다.***"*
+
+→ **MCP 룰 `reviewer-self-reflection-mission-goal-return`** ⭐⭐⭐ **신규 정점** — *reviewer 본인 취향 (반응형/flux) → 미션 본래 목표 자가 반성 + 갈아엎기 요청*. PR #62 (`reviewer-self-correction-on-strong-feedback`)·PR #115 (laco-dev *쎄게 양해*)·PR #73 (*휘둘리지 마세요*)·PR #106 (말리빈 *권력 자제*) 결 합류 누적 **5 PR** → ***reviewer 자가 강요 회피 어휘 정점*** ⭐⭐⭐ MCP `oh-my-oop` 핵심 가치 어휘 정점.
+
+→ **ghojeong reviewer 양 PR 자가 반성 어휘 연속** (#62 *강한 피드백 자가 수정* → #89 *미션 본 목표 복귀*) = **MCP `oh-my-oop` 핵심 가치 어휘 양 PR 일관 정점**.
+
+### 2. 학생 갈아엎기 도전 + reviewer 감사 (review #2·#3)
+
+reviewer review #2:
+
+> *"해음! **어찌보면 싹 갈아엎는 요청을 했음에도, 훌륭하게 새로 구현해주셔서 무척 감사합니다.** 🙇 매직 넘버만 조금 더 보완하면 좋을 듯 하여 피드백 남겨보았습니다!"*
+
+reviewer review #3:
+
+> *"해음! **처음부터 구조를 싹 갈아엎기 쉽지 않았을 텐데, 도전해주셔서 감사합니다!** 블랙잭 미션은 이렇게 마무리 하고, 다음 오목 미션도 화이팅입니다. 💪"*
+
+→ **MCP 룰 `student-restart-on-reviewer-request`** ⭐⭐⭐ **신규** — *reviewer *갈아엎기* 요청 → 학생 자가 도전 → reviewer 감사*. PR #154 (`pr-body-restart-from-scratch` rebase 손실 → 학습 기회 자가 재해석) 결의 *갈아엎기* 다른 축 — *학생 자발 vs reviewer 요청 갈아엎기*.
+
+### 3. 매직 넘버 일관 제거 (Thread 3·4·6) — 반복 시그널
+
+reviewer Thread 3: *"다만 곳곳에 매직 넘버가 있는 것은 아쉽습니다. Blackjack, Bust, Hit 을 포함하여 모든 매직 넘버를 유의미한 상수값으로 네이밍해서 선언해주세요."*
+
+reviewer Thread 4: *"state 뿐만 아니라 다른 model 에서 매직 넘버와 문자열은 유의미한 상수로 선언해주시기 바랍니다."*
+
+reviewer Thread 6: *"마찬가지로 매직 넘버와 문자열을 제거할 필요성을 느낍니다."*
+
+→ **매직 넘버 제거 일관 시그널** = 누적 다수.
+
+### 4. `onInputDecision` String → Boolean 리턴 (Thread 6)
+
+```kotlin
+val onInputDecision: (String) -> String
+```
+
+reviewer:
+
+> *"`val onInputDecision: (String) -> String` 의 경우에는 **String 을 리턴하지 않고 Boolean 을 리턴하도록 하는 것에 대해서는 어떻게 생각하시나요?**"*
+
+→ **MCP 룰 `callback-string-vs-boolean-return-type`** ⭐⭐ 신규 — *콜백 리턴 타입 = 도메인 의미 명시 (Boolean 선택)*. PR #14 (`cli-vs-gui-assumption-test` Boolean) 결 합류.
+
+### 5. `drawUntilSatisfaction` interface 메서드 + 디미터 법칙 (Thread 7)
+
+```kotlin
+// 현재 - 디미터 깨짐
+state == Hit(state.hand) && state.hand.calculateTotal() <= 16
+```
+
+reviewer:
+
+> *"`state == Hit(state.hand) && state.hand.calculateTotal() <= 16` 에 관련된 부분을 `fun drawUntilSatisfaction(): Boolean` 의 형태로 interface 에 선언하는 것은 어떨까 제안해봅니다. State interface 에 선언할지, Participant interface 에 선언할 지는 고민해주세요.*
+>
+> *고민해주시면서 `state.hand.calculateTotal()` 의 경우 처럼 **디미터 법칙이 깨지는 경우가 없도록** 해주시면 좋겠습니다."*
+
+→ **`dot-2-or-fewer-rule` 디미터** = PR #38 결 누적 2 PR.
+
+→ **MCP 룰 `behavior-locus-state-vs-participant-question`** ⭐⭐ — *행동 책임 위치 = State interface vs Participant interface 학생 자가 고민 유도*.
+
+### 6. README 체크 미완료 (Thread 0)
+
+reviewer: *"README 에 체크를 하지 않고 남겨 두신 이유가 있으시나요?"*
+
+→ **PR 본문 체크리스트 완성도** = PR #115·#154 (tobae-time 셀프 체크리스트) 결.
+
+## 대표 인용
+
+> [ghojeong review #1]
+> *"제가 반응형 프로그래밍 덕후이다 보니, 순수 코틀린 언어에서의 객체 설계라는 주제를 벗어나는 방향으로, 해음과 대화를 많이하게 된 것 같습니다. 저도 반성을 하면서, 블랙잭 미션의 본래 목표인 객체 설계로 되돌아가고자 합니다."*
+
+→ **reviewer 자가 반성 + 미션 본 목표 복귀 어휘 정점**.
+
+> [ghojeong review #1]
+> *"죄송하지만, 2단계 미션의 구조를 버리고 다시 작성해주시면 감사하겠습니다."*
+
+→ **reviewer 갈아엎기 사과 + 요청 어휘**.
+
+> [ghojeong review #2]
+> *"싹 갈아엎는 요청을 했음에도, 훌륭하게 새로 구현해주셔서 무척 감사합니다."*
+
+→ **학생 갈아엎기 도전 감사 어휘**.
+
+> [ghojeong Thread 1]
+> *"저는 State 디자인 패턴은 다음 두가지를 확인합니다. 1. 다형성(Polymorphism) 을 어떻게 활용했는가? 2. Context 의 책임을 어느 객체에게 부여했는가?"*
+
+→ **State 패턴 2 기준 어휘 정점**.
+
+> [haeum808 PR 본문]
+> *"파이로가 말씀해주신대로 flux 상태 아키텍쳐을 공부하고 적용했습니다! step2를 진행하기 전 step1에 flux 상태 아키텍쳐를 적용하고 시작했습니다."*
+
+→ **학생 자가 reviewer 추천 어휘 자가 학습 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **reviewer 자가 반성 + 미션 본 목표 복귀** — **MCP 룰 `reviewer-self-reflection-mission-goal-return` 후보** ⭐⭐⭐ 정점. PR #62·#115·#73·#106 결 누적 5 PR — *reviewer 자가 강요 회피 어휘 정점*.
+2. **State 패턴 2 기준 (다형성 + Context 책임)** — **MCP 룰 `state-pattern-2-criteria` 후보** ⭐⭐⭐. PR #154·#42 결 누적 3 PR.
+3. **학생 자가 reviewer 추천 어휘 자가 학습** — **MCP 룰 `pr-body-student-self-study-on-reviewer-recommendation` 후보** ⭐⭐⭐. PR #154 결 누적 2 PR.
+4. **reviewer 요청 갈아엎기 → 학생 자가 도전** — **MCP 룰 `student-restart-on-reviewer-request` 후보** ⭐⭐⭐.
+5. **콜백 리턴 타입 도메인 의미 (String → Boolean)** — **MCP 룰 `callback-string-vs-boolean-return-type` 후보** ⭐⭐.
+6. **map 안 while = depth 시그널** — **MCP 룰 `map-with-while-as-indentation-depth-signal` 후보** ⭐⭐.
+7. **행동 책임 위치 학생 자가 고민 유도** — **MCP 룰 `behavior-locus-state-vs-participant-question` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **haeum808 양 단계 완성 (1단계 #62 → 2단계 #89)** — 1단계 학생 자가 Slack DM 학습 → 2단계 PR 본문 *flux 상태 아키텍쳐 자가 학습 적용* → reviewer 본 목표 복귀 + 갈아엎기 요청 → 학생 자가 도전 + 함수형 어휘 진화 (map 능숙).
+- **ghojeong reviewer 어휘 정점 (양 PR 자가 반성 연속)** — #62 *강한 피드백 자가 수정* (forEach 강요 X 정정) → #89 *미션 본 목표 복귀 + 갈아엎기 사과* — **MCP `oh-my-oop` 핵심 가치 reviewer 양 PR 일관 정점**.
+- **메타 케이스 9번째** — *reviewer 본인 취향 → 미션 본 목표 자가 반성 + 갈아엎기 요청 → 학생 자가 도전* 정점.
+- **누적 메타 케이스 (batch 26 신규)**:
+  - 9. **haeum808 (PR #62 → #89)**: ghojeong reviewer 자가 반성 어휘 양 PR 연속 + 학생 자가 reviewer 추천 어휘 자가 학습 + 갈아엎기 도전.

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

@@ -0,0 +1,221 @@
+# PR #110 — [블랙잭 1단계] 환노 미션
+
+- **Reviewee:** [@hwannow](https://github.com/hwannow)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/110
+- **단계:** 1단계 (페어, *학생 자가 답변 매우 풍부*)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 17 / 리뷰이 13)
+
+## 잘한 점 (설계 관점)
+
+- **`Blackjack` 진행자 객체 분리 — *딜러 = 게임 참여자 + 진행자* 트레이드오프 자가 토론** (PR #125와 유사).
+- **`Hand` 일급 컬렉션 (후속 반영)** — 카드 + 점수 계산 + Bust.
+- **`Participant` 추상 클래스 + `canHit` 추상 메서드** (후속 반영).
+- **`ActionType` enum (HIT/STAY)** — 도메인 어휘.
+- **`GameResult` enum (Win/Lose/Draw) + Bust 분리 (후속)**.
+- **학생이 *모든 권고에 자가 답변 + 커밋 링크* 정성스럽게 명시** — 학습 가시화.
+
+## 못한 점 (설계 관점)
+
+### 1. PR 본문 — *딜러 = 참여자 vs 진행자* 학생 자가 토론
+
+학생 PR 본문: "*딜러를 게임 참여자로 볼 것인가? 게임 진행자로 볼 것인가? 딜러가 전체 카드 뭉치를 알아도 되는가?* 현실 세계를 반영한다면 *딜러는 능동적으로 플레이어들에게 카드*..." — *PR #125 (jerry8282)와 같은 자가 의문*. 학생이 *진행자 객체*(`Blackjack`) 분리 결론. 
+
+리뷰어: "*객체의 추상화에 대한 기본적인 접근을 잘 캐치해주셨어요* 👍🏻 *객체가 수동적이라고 생각하는 것은 자율성을 부여해주지 않아서 라고 생각*합니다. 예제로 보여주신 *`딜러가 16이 넘지 않으면 카드를 받는다`는 행위로 표*..."
+
+→ **객체 수동성의 원인 = 자율성 미부여**. 객체가 *외부 명령 받기*만 한다면 *행위로 표현*. 학생의 진행자 분리는 자율성 한 단계 더 부여.
+
+### 2. `Shape.value: String` UI 표현 — 학생 자가 토론
+
+```kotlin
+enum class Shape(val value: String) { ... }
+```
+
+학생 자가 토론 (PR #125와 동일): "*출력 정보를 enum에서 관리할지, view에서 확장함수로 관리할지도 많이 고민*했는데요! 🤔 *enum을 사용할 시, `리팩터링 시 변경 범위가 최소화된다` 라는 장점*이 있습니다. *만약에 영문 출력이 생길 경우, enum 의 프로퍼티에만*..."
+
+리뷰어: "*우선 모양이라는 enum 모델의 역할은 충분히 의미가 있어보여요.* 하지만, *만약 하트를 ❤️ 이렇게 출력해주세요. 라는 요구사항이 들어오면 우리는 도메인 모델을 수정해야 할까요? 또한 하트가 문자열이 아닌 시각적인 "이*..."
+
+학생 후속 답변 (URL 첨부): "*출력문을 관리하는 건 뷰의 역할인 것 같습니다! 🙃 따라서 뷰에서 확장함수로 출력문을 관리하도록 변경*해 주었..."
+
+리뷰어 후속: "*왜 URL이 먼저 나오는지는 둘째 치고...* *뷰에서 렌더링 해주면 도메인을 수정할 필요가 없잖아요?* *동일한 문제를 되새기고자 드린 질문*입니다." — **enum UI value 17개+ PR 연속**. 학생이 *PR #125와 동일한 토론을 자가 진행 → 자가 결론*.
+
+### 3. `YesOrNo` 도메인 클래스 — enum vs class
+
+```kotlin
+class YesOrNo(val value: String) { ... }
+```
+
+리뷰어: "*오히려 YesOrNo라는 개념이라면 이것도 enum이 되어야 하지 않았나요?* `enum class YesOrNo { Yes, No }` *도메인 입장이라면 Y, n, y 이런 문자열을 판단하기 위한 input 자체가 필요한 것인가 의문이 듭니다.* *키오스크라면 "y"라*..."
+
+학생 자가 답변: "우선 위 객체는 *`모든 원시값을 포장한다`라는 요구사항을 충족하기 위해 만든 객체였습니다!* 🙃 1. *`enum이 되어야*..." — **YesOrNo는 ActionType과 중복 개념**. *enum class + Yes/No*가 자연. *키오스크 = 버튼*이면 *Boolean*. PR #29·#119·#125·#128과 같은 결.
+
+### 4. `CardNumber.OtherAce` 어색한 이름
+
+```kotlin
+enum class CardNumber(...) {
+    ACE(1, "A"),
+    OTHER_ACE(11, "A");   // ⚠ 이름 어색
+}
+```
+
+리뷰어: "*OtherAce라는 이름이 어떤 역할을 하는 건지 어색하게 느껴져요. 점수를 계산하는게 다소 복잡하기는 한데 10점이라는 것을 보너스 점수라는 관점으로 해석*해보면 어때요?" — **`OtherAce` 만능 명사 + 룰 누수**. *Ace는 1점*만 enum 값. *11로 계산*은 *Cards.score()의 보너스 룰*. PR #29·#119와 같은 결.
+
+### 5. `ParticipantStatus` enum — *결과 + 상태 혼재* (PR #125와 동일)
+
+```kotlin
+enum class ParticipantStatus { None, Win, Lose, Bust, Draw }
+```
+
+리뷰어: "*이 상태 객체가 어떤 역할을 하는 것인지 의도를 잘 모르겠어요.* *Draw라는 것은 상태가 아닌 뽑는다는 행위*로 보이는 반면 *Win, Lose는 승부의 결과, Bust는 상태*가 되겠네요. *무엇을 위한 상태 객체*인지 저를 설득해주실 수 있..."
+
+학생 답변: "*Win (승), Lose (패), Draw (무) 는 승부의 결과, Bust는 상태가 맞습니다!* 🙃 *참여자들의 승패 결과를 나타내기 위한 enum class*인데, *게임의 룰을 적용시켜 Bust 상태까지 추가한 형태가 되었습니다.* 현재 요구 사항에서 Bust..."
+
+학생 후속: 후속 커밋에서 *Bust를 GameResult로 옮김*. **결과 enum과 상태 enum 분리 = 18개+ PR 연속**.
+
+### 6. `ParticipantStatus.compare(playerScore, dealerScore)` — 정적 비교자
+
+```kotlin
+companion object {
+    fun compare(playerScore: Int, dealerScore: Int): ParticipantStatus { ... }
+}
+```
+
+리뷰어: "*승부를 벌이는 것은 Status가 할 일이라고 봐야 하나요? 아니면 참가자가 할 일이라고 봐야 하나요?*"
+
+학생 답변: "*승부를 벌이는 것은 참가자가 할 일이라고 생각합니다!* 🤔 다만 *위 메소드는 `승부를 벌인다` 라는 관점이 아닌, `두 숫자를 비교해서 상태를 반환해라` 관점에서 바라보고 작성*하였습니다. 또한 *도메인의 프로퍼티가 아닌, 원시값인 Int로 판단*하고 상태를 반환하기 때문에 *ParticipantStatus 객체가 할 일이라고 생각*하였습니다!" — **학생의 *책임 분리 해석*: 비교 메서드는 *Int 비교 = enum 책임*, 승부 벌이기는 *참가자 책임***. 합리적 분기. 그러나 *함수명 `compare`*는 *enum과 어색*. *enum에 *result of compare 두 점수* 메서드*는 *trade-off*.
+
+### 7. `Participants`가 *카드 관리까지* — 책임 비대
+
+리뷰어: "*앞선 내용들이 이 문제를 해결하면서 도움이 될거에요.* *참가자가 카드들을 관리하기에는 너무 역할이 많은 것 같아요.* 덱은 카드뭉치에서 하나씩 빼는 역할이라면, *카드들이라는 객체가 있다면 어떤 역할*을 할 수 있을까요..."
+
+학생 후속: "*위 커밋에서 플레이어가 가지는 카드 뭉치를 일급 컬렉션으로 래핑해 주었습니다!* 🃏 `Hand.kt` 해당 객체는 카드를..." — **Hand 일급 컬렉션 = 카드 관리 + 점수 계산 + Bust 판정**. PR #79·#65·#10·#33과 같은 결.
+
+### 8. `Player.compareScores`가 *자기 상태 변경*
+
+```kotlin
+class Player {
+    var status: ParticipantStatus
+    fun compareScores(other: Player) {
+        status = ParticipantStatus.compare(this.score, other.score)   // ⚠ 자기 상태 변경
+    }
+}
+```
+
+리뷰어: "*점수를 비교하는 것은, 결국 상대적인 입장인데 그때마다 자신의 상태가 바뀐다는 것이 재사용성을 매우 떨어트리는 것으로 보입니다!*" — **`compareScores`가 *side effect*로 *자기 상태 변경***. *Tell-Don't-Ask 변형 위반*. *`match(other): Result` 반환*이 자연. PR #25·#33과 같은 결.
+
+### 9. `Deck` 생성자에 *셔플 전략* 매개변수
+
+```kotlin
+class Deck(shuffleStrategy: (List<Card>) -> List<Card>) { ... }
+```
+
+리뷰어: "*섞여져있는 카드를 주는 것과, 임의의 카드를 주는 것으로 이미 충분한 듯 한데 셔플하는 규칙까지 생성자로 보기에는 오버엔지니어링으로 보이지 않나요?* 지금 *구조만의 특별한 이점이 있을까요?* 오히려 *이런 기능들이 고*..."
+
+학생 답변: "이 부분은 *페어의 리뷰도 참고하여 수정*하였습니다! *처음에 전략 패턴을 도입했었던 건 테스트 코드에서 섞이*..." — **테스트 위한 Strategy 도입 → 오버 엔지니어링**. *명시적 카드 주입*이 *동등한 이점 + 단순*. PR #125 (jerry8282) Strategy 폐기와 같은 결.
+
+### 10. `domain.model` vs `model.domain` 패키지 — 학생 자가 토론
+
+```
+src/main/kotlin/blackjack/domain/model/...
+src/main/kotlin/blackjack/model/domain/...
+```
+
+리뷰어: "*아 맞다 아래 두개는 뭔차이인가요?* > domain.model > model.domain"
+
+학생 자가 답변: "*두 개에서 model의 의미가 다른 것 같습니다* 🤔 *domain.model 의 모델은 도메인 중심 설계에서 도메인 모델을 의미*할 것 같네요. > 도메인 로직을 포현하는 객체와 개념의 집합. *model.domain 에서 모델은 MVC 패턴에서의 모델*..."
+
+리뷰어 후속: "*레이어 기반이라는 점이 잘 이해가 안되는데요. 아래 1번처럼 작성해도 문제 없다는 것으로 봐야할까요?* `#1 model.domain model.ui model.data` vs `#2 data.model ui.model domain.model`" — **패키지 명명 컨벤션 토론**. *어떤 분류 축*이 *우선*인지에 따라. *Kotlin 컨벤션 + 회사 컨벤션*은 *각각*. PR #128과 같은 결.
+
+### 11. `Hand`에 *방어적 복사 미적용*
+
+```kotlin
+class Hand(val cards: MutableList<Card>) { ... }
+```
+
+리뷰어: "*수업 때 배운 방어적 복사 개념을 적용 해보세요* :)" — PR #79·#65·#24·#33과 같은 결.
+
+### 12. `Hand`가 *Bust 판정도*
+
+리뷰어: "*카드의 점수를 계산하는 역할을 한다면, 버스트 상태를 판단하는 것도 Hand가 적절하지 않을까요?*" — **`Hand.isBust()` = 점수 계산 + Bust 판정**. PR #135·#119·#81과 같은 결.
+
+### 13. `GameResult`가 *Bust 판단* 유지
+
+```kotlin
+enum class GameResult { Win, Lose, Draw, Bust }   // 후속에 Bust 남음
+```
+
+리뷰어: "*게임 결과로 바뀌었는데 왜 버스트를 이 객체가 판단하도록 유지되어있을까요?*" — **변경 반쪽**. 학생 자가 답변 후 후속 *완전한 분리 미반영*.
+
+### 14. `Player`의 *플레이어 vs 딜러 1:1 구도* — 1대다 미고려
+
+```kotlin
+class Player {
+    var status: ParticipantStatus
+    fun compareScores(dealerScore: Int) { ... }
+}
+```
+
+학생 답변: "*블랙잭이라는 게임 자체가 `플레이어 vs 딜러 1:1` 구도이고, 미션의 요구 사항도 게임을 여러번 하는 것이 아닌, `한번만 진행`하므로 플레이어들이 각각의 승패 결과를 들고 있는 게 합당하다고 생각*합니다! 만약 *플레이어*..." — **현재 요구사항 충실 = 1:1**. 확장성은 *미래 요구사항 발생 시 리팩토링* 입장. **YAGNI**. PR #24의 *1대다 권고*와 *반대 방향*.
+
+### 15. `ActionType` enum vs `YesOrNo` 분리 — 학생 자가 토론
+
+학생 답변: "*처음에 ActionType으로 만들지 않은 이유는 입력값에 대한 논리적인 오류 유효성 검증을 할 도메인이 필요한데, enum 클래스에서 사용자 입력값에 대한 유효성 검증을 하는 것이 맞는가? 에 대한 확신이 들지 않아 분리해 주었습*..." — **enum + 입력 검증의 위치**. *enum value 매핑 + 검증*은 *companion object*에. *별도 클래스 만드는 것은 과잉*. PR #128과 같은 결.
+
+### 16. `Blackjack` 진행자가 *플레이어/딜러 모두 진행* (이미 잘함)
+
+리뷰어 칭찬: "*객체의 추상화에 대한 기본적인 접근을 잘 캐치해주셨어요* 👍🏻 *객체가 수동적이라고 생각하는 것은 자율성을 부여해주지 않아서 라고 생각*합니다." — 학생의 *Blackjack 진행자 분리 시도가 잘됨*. 학생 *자가 답변*: "*따라서 추상 클래스의 canHit 메소드를 각각의 구현체에서 구현*하도록 바꿔 보았는데, *페로로의 피드백 의도가 이게 맞았을까요?* 🥲" → 리뷰어: "*네 맞습니다* :)"
+
+→ **학생의 *자가 의문 + 자가 답변*이 *반복적으로 정답에 도달***. 학습 가시화의 모범 사례.
+
+## 리뷰어 의견 요지
+
+- ***딜러 = 참여자 vs 진행자 = 학생 자가 토론 + 진행자 분리 진행***.
+- ***Shape.value UI = 17개+ PR 연속 (학생 자가 결론으로 View 이전)***.
+- ***`YesOrNo` 도메인 클래스 < enum + `ActionType`***.
+- ***`CardNumber.OtherAce` 만능 명사 + 보너스 점수 관점***.
+- ***`ParticipantStatus`에 결과 + 상태 혼재 = Bust 분리***.
+- ***Status가 비교자 책임 = 참가자 책임이 자연*** — 학생 *Int 비교는 enum* 분기 입장.
+- ***Participants 카드 관리 = Hand 일급 컬렉션 분리***.
+- ***`Player.compareScores`가 자기 상태 변경 = 재사용성 ↓*** — `match(other): Result` 반환.
+- ***Deck 셔플 전략 매개변수 = 오버 엔지니어링*** — 명시 카드 주입.
+- ***패키지 명명 (`domain.model` vs `model.domain`) = 분류 축 선택***.
+- ***Hand 방어적 복사***.
+- ***Hand가 Bust 판정 = 점수 계산 + Bust 응집***.
+- ***GameResult에 Bust 잔존 = 변경 반쪽***.
+- ***1:1 구도 = YAGNI vs 1대다 확장*** — 트레이드오프.
+- ***ActionType enum + companion에 매핑/검증***.
+
+## 대표 인용
+
+> 객체의 추상화에 대한 기본적인 접근을 잘 캐치해주셨어요 👍🏻 *객체가 수동적이라고 생각하는 것은 자율성을 부여해주지 않아서 라고 생각*합니다.
+> — @laco-dev on `Blackjack.kt`
+
+> 점수를 비교하는 것은, 결국 *상대적인 입장인데 그때마다 자신의 상태가 바뀐다는 것이 재사용성을 매우 떨어트*리는 것으로 보입니다!
+> — @laco-dev on `Player.kt`
+
+> 만약 하트를 ❤️ 이렇게 출력해주세요. 라는 요구사항이 들어오면 *우리는 도메인 모델을 수정해야 할까요?* 또한 *하트가 문자열이 아닌 시각적인 "이*...
+> — @laco-dev on `Shape.kt`
+
+> 위 메소드는 `승부를 벌인다` 라는 관점이 아닌, *`두 숫자를 비교해서 상태를 반환해라` 관점에서 바라보고 작성*하였습니다. 또한 *도메인의 프로퍼티가 아닌, 원시값인 Int로 판단하고 상태를 반환*하기 때문에 *ParticipantStatus 객체가 할 일이라고 생각*하였습니다!
+> — @hwannow (학생 책임 분리 해석) on `ParticipantStatus.kt`
+
+> 블랙잭이라는 게임 자체가 `플레이어 vs 딜러 1:1` 구도이고, 미션의 요구 사항도 *게임을 여러번 하는 것이 아닌, `한번만 진행`*하므로 *플레이어들이 각각의 승패 결과를 들고 있는 게 합당*하다고 생각합니다!
+> — @hwannow (학생 YAGNI) on `Player.kt`
+
+## 얻은 교훈
+
+- ***딜러 = 참여자 + 진행자 자가 토론 = PR #125와 동일한 학생 의문 패턴*** — 진행자 객체 분리.
+- ***객체 수동성 = 자율성 미부여 신호*** — *행위로 표현*하면 *외부 명령*이 메시지로 변환.
+- ***enum UI value 17개+ PR 연속 (MCP 룰 후보 최강)*** — 학생이 *PR #125 토론을 자가 진행*.
+- ***`YesOrNo` 도메인 클래스 = enum + ActionType 중복 개념*** — 원시값 포장의 *과잉 적용*.
+- ***`CardNumber.OtherAce` 만능 명사 = 룰 누수*** — *보너스 점수* 관점으로 분리.
+- ***ParticipantStatus에 결과 + 상태 혼재 = 18개+ PR 연속*** — Bust 별도 enum.
+- ***Status.compare가 enum 책임 vs 참가자 책임 = 학생 책임 분리 해석*** — *Int 비교 = enum*, *승부 = 참가자*. **트레이드오프 + 학생 근거 명시**.
+- ***Participants 카드 관리 = Hand 일급 컬렉션 분리*** — *Hand = 카드 + 점수 + Bust 응집*.
+- ***`Player.compareScores`가 자기 status 변경 = 재사용성 ↓*** — `match(other): Result` 반환.
+- ***Deck 셔플 전략 매개변수 = 오버 엔지니어링*** — *명시 카드 주입*이 동등한 이점 + 단순. PR #125·#65와 같은 결.
+- ***패키지 명명 = 분류 축 선택*** — *어떤 축이 우선*인지에 따라 컨벤션 결정.
+- ***GameResult에 Bust 잔존 = 변경 반쪽*** — *완전한 분리*까지 도달.
+- ***1:1 구도 (현재 요구사항) vs 1대다 확장 = YAGNI 트레이드오프*** — *현재 요구사항 충실* vs *미래 확장성*. **학생 근거 명시**.
+- ***ActionType enum + companion object에 매핑/검증*** — *별도 클래스* 만들지 않고 *enum 자체에 보유*.
+- ***학생 자가 의문 + 자가 답변 + 자가 결론 = 학습 가시화의 모범*** — PR #128·#135·#111·#120과 같은 결.