oh-my-oop 0.2.0

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

@@ -0,0 +1,253 @@
+# PR #23 — [블랙잭 1단계] 멘델 미션
+
+- **Reviewee:** [@rhthrhrl0](https://github.com/rhthrhrl0)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/23
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 28 스레드 — *학생 자가 답변 + 학습 풍부* + 말리빈 매우 긴 메타 답변 (점수 계산 책임 위치 그림 첨부) + 외부 글 추천
+- **신규 reviewee** (2023년 3월 PR — 시기적으로 다른 코호트)
+
+## 잘한 점 (설계 관점)
+
+- **View 람다 콜백 분리 칭찬 2회** — 말리빈 *"View에 대한 요소를 람다를 통해 전달해주셨네요 👍"* + *"View에 대한 내용을 람다로 잘 전달해주신 게 정말 인상 깊네요! 👍👍"*. **`onXX` 콜백 어휘 = Inversion of Control 정공** — PR #99 (s6m1n 자가 학습) / PR #137·#132 의 *외부 자료 + 콜백* 결.
+- **다형성 활용** — 말리빈 *"다형성을 활용해주셨네요 👍"* — Player/Dealer 추상화.
+- **방어적 복사 자가 학습** — 말리빈 *"방어적 복사가 잘 이뤄졌네요 👍"*. PR #108·#132·#133·#85·#58·#137·#148·#74 와 같은 결.
+- **`Card` 가짜 생성자 (Factory) 외부 글 추천 + 학생 자가 학습** — 말리빈: *"Card를 만들기 불편해보이고, 테스트 가독성도 나빠져 보여요. 테스트에서 사용할 Card의 가짜 생성자를 만들어보는 것은 어떨까요? 가짜 생성자는 아래의 글을 참고해보세요"* + [Kotlin 공식 문서 - concrete-type-constructors](https://kotlinlang.org/docs/constructing-collections.html#concrete-type-constructors) + [Item 30 - Consider Factory Functions](https://blog.kotlin-academy.com/item-30-consider-factory-functions-instead-of-constructors-e1c747fc475) — *외부 학습 자료 첨부*. 학생: *"재밌게 읽었습니다. 좋은 글 추천해주셔서 감사합니다!"*. **MCP `oh-my-oop` 룰에 외부 자료 인용 패턴**.
+- **`assertAll` 자가 학습 + 병행 처리 어휘** — 말리빈 메타 질문: *"검증문을 나열하는 것과 assertAll로 감싸는 것은 어떤 차이가 있을까요?"* + 학생 자가 답변: *"이걸 사용하면 순차처리가 아닌 병행 처리가 가능해진다고 확인했습니다. 덕분에 에러가 발생하면 멈추고 뒤에 것이 테스트 안되는게 아니라 이 하나의 전체 그룹에서 발생한 모든 오류를 체크 가능하다는 글을 읽었습니다. 알려주셔서 감사합니다!!"*. **테스트 어휘 자가 학습 + 자가 의미 정리 모범**. PR #99·#88·#85 의 *테스트 어휘* 결.
+- **새 게임 객체 재사용 자가 반영 (페이즈 객체 도입)** — 말리빈 진단 *"하나의 블랙잭 게임 객체는, 한 번의 게임만 실행할 수 있겠네요 :) 객체는 한 개만 만들고, 게임은 여러 번 진행할 수 있게 만들어보는 것은 어떨까요?"* + 후속: *"game은 한 번만 생성하고, 내부에서는 사이드 이팩트를 발생 시키지 않으면서, 플레이어와 딜러에 대한 상태를 가지지 않게 만들어보는 것을 시도해보세요 :)"* + 학생 자가 반영: *"게임의 각 진행 단계를 페이즈라는 개념의 객체들로 만들고 게임을 실행하면 페이즈 객체들을 연속실행 시키는 방법으로 수정했습니다!"*. **싱글톤 vs 1회용 자가 학습 + 페이즈 객체 도입 자가 진화** — PR #98 의 *State 패턴* / PR #99 의 *람다 콜백* 결.
+- **`RandomCardDrawer` 카드 목록 캐싱 자가 반영** — 말리빈 진단 *"카드 목록은 RandomCardDrawer를 생성할 때마다 새로 생성되겠네요 :) 카드 목록을 한 번만 생성해서 재활용해보는 것은 어떨까요?"* + 학생 자가 반영 (companion object + private val CARD_DECK). PR #74·#108·#133 의 *카드 캐싱* 결.
+- **`else` 자가 학습 (극단 회피 인정)** — 말리빈: *"아래 두 줄은 첫 줄의 if문의 else 로도 표현이 가능하겠네요 :)"* + 학생: *"else를 지양하라는 말에 너무 집중하다보니 극단적으로 else를 안쓰게 된 것 같습니다. 지적해주셔서 감사합니다."*. **원칙 극단 적용 자가 인정 + 균형 학습**. PR #146 의 *YAGNI* / PR #151 의 *반란군 비유* 결.
+- **머지 후 후속 코멘트 + 학생 자가 후속 학습** — 머지 시점 이후에도 *3월 8·9·12일* 코멘트 활발 = *피드백 후 학습 지속*. 말리빈/멘델 양측 모두 후속 토론 — *PR 머지가 학습 종료 X* 모범.
+
+## 못한 점 (설계 관점)
+
+### 1. `점수 계산 Dealer 책임` + `Player vs Player 비교 어려움` — 말리빈 매우 긴 답변 + 그림 첨부
+
+말리빈 진단:
+
+> *"점수를 계산하는 부분은 Dealer만 가지고 있으면 좋겠어요. 플레이어와 플레이어는 사실 경쟁 상대가 아니기 때문이에요. 플레이어끼리 결과를 비교하면, 어떤 플레이어가 이겼는 지 알기도 어려울 것으로 예상돼요. (Player.getGameResult()) 또, 승패를 결정하는 룰은 딜러와 플레이어 간 연관이 있기도 해서요. 그러면 자연스럽게 Players 에게 메시지를 던지는 형태도 사라질 수도 있겠어요 :) 멘델의 생각은 어떠신가요?"*
+
+학생 자가 답변 (자가 정당화):
+
+> *"저는 플레이어의 승패가 딜러보다 먼저 결정나고('플레이어가 버스트 된다면 플레이어는 딜러가 버스트 되더라도 진다'라는 규칙) 또한, 딜러의 승패 종합 결과는 플레이어들에 의해 정해진다고 생각했습니다. 그래서 플레이어 기준의 승패 결과가 중요하다고 생각을 해서 플레이어쪽에 게임 결과 반환 메소드가 있는것이 적절할것 같다고 생각했습니다. 그래서 이번에 수정하면서 딜러쪽에서 게임의 승패를 반환하는 메소드는 제거 시켰습니다. 혹시 수정 이후에도 아직 부자연스러워 보이시면 해당 로직을 딜러쪽으로 이동시켜보겠습니다!"*
+
+말리빈 매우 긴 답변 (3 메타 시점 + 그림 첨부):
+
+> *"저는 딜러쪽이 좀 더 특수하다고 생각해요 :) 일반적이라면 카드 점수와 개수 만으로 결과가 나오지만, 블랙잭의 경우는 딜러가 블랙잭일 때 특수 룰이 적용된다 생각해요. 그리고 현실 세계에서는 딜러가 결과를 알려주기 때문이에요.*
+
+> *위 같은 의견도 있지만, 아래는 제 개인적인 의견입니다 ㅎ_ㅎ 저는 딜러도, 플레이어도 아닌, 그 부모 객체인 Participant에 위치해도 좋다는 생각이에요. 사실 결과 자체는 누가 가지고 있는 지 보다, 카드더미만 있으면 알 수 있으니까요.*
+
+> *좀 더 의존 관계에 대해 짚어보면, 현재는 플레이어는 Dealer를 알고 있습니다. (의존 관계 그림 첨부)"*
+
+학생 후속 답변: *"열정적으로 피드백과 의견을 달아주셔서 감사합니다! 말리빈님의 글을 읽어보니 왜 그렇게 하기를 원하셨는지 알겠습니다. 더 수정해보겠습니다!"*
+
+→ **4 가지 메타 학습**:
+
+#### 1.1. *점수 계산 책임 위치 = 3 후보*
+
+- (A) **`Dealer.compareResult(player)`** — 말리빈 *공식 의견*. *블랙잭 특수 룰 (딜러 블랙잭) + 현실 메타포 (딜러가 결과 알려줌)*.
+- (B) **`Player.getGameResult(dealer)`** — 학생 자가 선택. *플레이어 승패가 딜러보다 먼저 결정 + 플레이어 기준 결과 중요*.
+- (C) **`Participant.compareWith(other)`** — 말리빈 *개인 의견*. *카드더미만으로 결과 알 수 있음 + 의존 관계 단순*.
+
+#### 1.2. *플레이어 vs 플레이어 비교 어려움*
+
+말리빈의 핵심 진단 = *"플레이어와 플레이어는 사실 경쟁 상대가 아니기 때문이에요. 플레이어끼리 결과를 비교하면, 어떤 플레이어가 이겼는 지 알기도 어려울 것으로 예상돼요."*
+
+→ **블랙잭 도메인 룰 = *플레이어 vs 플레이어 비교 X***. *각 플레이어 vs 딜러 1:1 비교*. *학생의 `Player.getGameResult()` = "이 플레이어가 이겼는가" 의 *상대* 가 불명확*.
+
+대안:
+- **`Player.getGameResultAgainst(dealer)`** — 명시적 상대.
+- **`Dealer.compareResult(player)`** — 딜러 기준 (위 A).
+
+#### 1.3. *현실 메타포 + 도메인 룰 = 같은 결*
+
+*"현실 세계에서는 딜러가 결과를 알려주기 때문이에요"* — *현실 메타포 = 딜러가 결과 발표* + *도메인 룰 = 딜러 vs 각 플레이어 비교* = **같은 결**. PR #70 (chaehyuns 1단계) 의 *현실 메타포 (Dealer 판단) vs 확장성 (Participant vs Participant)* 트레이드오프 결.
+
+#### 1.4. *공식 의견 + 개인 의견 분리 메타 어휘*
+
+말리빈의 *"제 개인적인 의견입니다 ㅎ_ㅎ"* — *공식 권고 (Dealer 책임)* + *개인 의견 (Participant 부모 책임)* 명시 분리. **MCP `oh-my-oop` 의 *단일 답 X + N개 대안 + 트레이드오프* 어휘와 일치**. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) 결.
+
+PR #74 (송핑크 *Referee*) / PR #148·#151 (krrong *역할 vs 상태*) / PR #49·#132 (참가자 vs 참가자 일반화) 결.
+
+### 2. `State.Burst, State.NoBurst` 외부 분기 → Tell-Don't-Ask 자가 학습
+
+말리빈 진단: *"이 함수들은 결국 Burst 인지 아닌지 구별하는 것으로 주로 쓰이고 있네요 :) 외부에서 State.Burst, State.NoBurst를 구분하기보다, Cards에게 물어보는 것은 어떨까요? 또, Cards에게 점수를 물어보면, 내부에서 계산을 마치고 합산 점수만 반환하게 만들어보세요 :)"*
+
+→ **Tell-Don't-Ask = *상태를 외부에서 분기 X, 객체에 메시지 명령***. 
+
+대안:
+- *`if (cards.state == Burst)`* < *`if (cards.isBurst())`* (외부 분기 X).
+- *`cards.calculateScore()`* 반환 < *외부에서 합산 로직* (책임 응집).
+
+PR #74 (송핑크 *Tell-Don't-Ask 자가 인정*) / PR #98 (chaehyuns *Hand 메시지*) / PR #99 (s6m1n *Hand 클래스 도입*) 결.
+
+### 3. `Dealer 가 players 의 값을 꺼내 호출` → 메시지 권고
+
+말리빈: *"players에서 값을 꺼내서 호출하기 보다, players에게 메시지를 던져보는 것은 어떨까요?"*
+
+→ **`getter 호출 + 외부 로직` < `객체에 메시지 + 내부 로직`** = *Tell-Don't-Ask + 디미터 법칙*. PR #99 (s6m1n *Players 일급 컬렉션*) / PR #133·#136·#137 의 *Tell-Don't-Ask* 결.
+
+### 4. `CardDrawer` 명명 — Drawer = 서랍 안티패턴
+
+말리빈: *"Drawer의 일반적인 뜻은 '서랍'이에요 :) ~~~er 접두사를 많이 사용하다 보면 나오는 흔한 오류라고 생각해요. 더 구체적인 다른 이름을 찾아볼까요? 🙂"*
+
+→ **`~~~er` 접두사 함정**:
+- *`Drawer`* = *카드를 뽑는 자* 의도, 그러나 *Drawer = 서랍* 의 일반 의미가 강함.
+- *`Drawer`* 같은 동사+er 명명 = *영어 사전상 다른 의미와 충돌* 시 *의도 전달 실패*.
+
+대안:
+- **`CardDealer`** — 도메인 어휘 (카드 분배자).
+- **`CardSupplier`** — 추상화 (공급자).
+- **`Deck`** — 직접적 도메인 명사.
+- **`Shoe`** — 카지노 블랙잭 어휘 (카드를 담는 통).
+
+**MCP 기존 룰 `vagueName`** 변형 — *`~~~er` 접두사 검사*. PR #67 (s6m1n *DealingShoe*) / PR #74 (송핑크 *Deck*) 결.
+
+### 5. `Cards(Set<Card>)` — 여러 벌 카드 요구사항 시 한계
+
+말리빈: *"Cards를 생성할 때 Set을 받으셨네요! 중복된 카드를 받지 않을 수 있는 장점이 생길 수 있지만, 블랙잭 게임에서 여러 벌의 카드를 사용하는 요구사항이 추가되면 어떤 일이 생길 수 있을까요?"*
+
+→ **자료구조 선택 트레이드오프**:
+- **`Set<Card>`** = *중복 차단 + 카드 1벌 한정*. *여러 벌 사용 시 동일 카드 중복 = Set이 차단 → 동작 깨짐*.
+- **`List<Card>`** = *순서 + 중복 허용 + 여러 벌 가능*.
+- **`MutableList<Card>` + draw 시 remove** = *덱 자료구조 + 카드 소진 모델링*.
+- **`ArrayDeque<Card>`** = *FIFO 덱 + draw 효율*.
+
+**MCP 룰 후보 — `set-vs-list-multiset`** = *중복 허용 시나리오 검토*. PR #58 (otter66 *카지노 6덱 메타포*) 결.
+
+### 6. `pattern 안 "스페이드" View 영역 누수` — 학생 자가 의문 + 말리빈 메타 답변
+
+말리빈: *"pattern 안의 값은 뷰의 영역이에요 :) '스페이드' 는 '♠' 로도 충분히 변경이 가능해보입니다 🙂"*
+
+학생: *"이모지를 써야하는 이유를 잘 모르겠습니다!! 혹시 특별한 이유가 있을까요??"*
+
+말리빈 부연 (메타 어휘):
+
+> *"이모지를 써야만 한다는 의미가 아니었어요. 카드 심볼에 대한 View의 출력 형태는 언제든지 변경 가능하다는 의미였습니다 :) 이모지 뿐만 아니라, 영어 등의 다른 언어로도 출력이 가능하겠지요 🙂*
+
+> *그렇다면, 이 모든 변경 가능할 요소들을 domain이 가지고 있는 게 맞을 지에 대한 질문이었어요!"*
+
+→ **3 가지 메타 학습**:
+
+#### 6.1. *학생 자가 의문 = 학습 모범*
+
+*"이모지를 써야하는 이유를 잘 모르겠습니다!!"* = *reviewer 의 *의도* 가 학생에게 닿지 않음 + 자가 명시*. **학습 갭 명시 모범**. PR #95 (송핑크 *"이해를 못했습니다"*) 결.
+
+#### 6.2. *reviewer 부연 = 의도 명시*
+
+말리빈의 *"이모지를 써야만 한다는 의미가 아니었어요"* — *학생의 표면적 해석 (이모지 강제) 을 부정 + 본 의도 (View 표현 가변성) 명시*. PR #95·#99 의 *두 번 부연* 결.
+
+#### 6.3. *Domain vs View 어휘*
+
+*도메인 = 게임 룰 (스페이드/하트/다이아/클럽)* + *View = 표현 (♠ vs "스페이드" vs "Spade" vs 그림)*. **MCP 기존 룰 `enum-with-ui-value`** (lotto 어휘) 의 *블랙잭 변형*. PR #28·#78·#112·#125·#147 의 *enum koreanText/description* 결.
+
+### 7. `BlackJackCardDeck` 카드 캐싱 (LottoNumber 참조)
+
+말리빈: *"이전 로또 미션에서 LottoNumber를 캐싱했던 것 처럼, 동일한 Card 객체가 중복으로 생성되지 않게 만들어보는 것은 어떨까요?"*
+
+→ **이전 미션 학습 자가 연결 권고**. *LottoNumber 1-45 캐싱* → *Card 52장 캐싱* = *동일 패턴 자가 적용*. PR #74·#108·#133·#136 의 *Card private constructor + Factory + 캐싱* 결.
+
+### 8. `재귀 호출 의도 자가 정당화` — *마지막 if 중복 자가 인정 X*
+
+말리빈 진단: *"마지막 줄의 if 문은 중복 코드로 보입니다. 어떤 의도인지 알기 어려워서, 한 번만 검사하는 것과 어떤 점이 다른가요?_?"*
+
+학생 자가 정당화:
+
+> *"카드를 추가하지 않겠다고 n을 입력하더라도 플레이어의 카드 목록을 출력해야합니다. 떄문에 카드를 더한다고 y를 입력하면 카드를 더하고 카드목록을 출력하고, 만약 n을 입력하면 카드를 더하지 않고 출력하도록 되어있습니다. 또한, 만약 카드를 더하겠다고 y를 입력하면 버스트 되지 않는한 계속 물어봐야 하기 때문에 마지막 if문에서 재귀 호출을 했습니다."*
+
+→ **학생 자가 정당화 = *재귀 호출 의도 명시***. *말리빈은 *코드만 보고 중복 인식* 했으나 학생의 의도 (카드 출력 양분기 + 재귀 종료 조건) 가 명확*. **재귀 호출의 의도 = 주석 또는 함수 분리로 가독성 향상** 가 정공:
+
+- (A) **`hitOrStay()` 함수 분리** — *재귀 의미 명시 + 매개변수로 종료 조건*.
+- (B) **반복문 + 명시적 break 조건** — *재귀 회피*.
+- (C) **State 패턴** = *Hit 상태 → 다음 상태 전이* (PR #98 의 상태 패턴 토론).
+
+학생 머지 시점 미반영 (자가 정당화로 종결).
+
+### 9. `BlackJackCardDeckTest` 갯수만 검증 = 무의미
+
+말리빈: *"갯수만을 검증하는 것은 테스트에 큰 의미를 부여하기 어렵습니다. 랜덤에 대해 제어할 수 있게 만들어보시고, 정확히 예측 가능한 카드로 검증문을 구성해보세요 :)"*
+
+→ **갯수 검증 < 결정적 검증**:
+- *`assertEquals(2, deck.draw().size)`* = *갯수만* — *어떤 카드든 통과*. *버그 잡기 어려움*.
+- *`assertEquals(Card.SPADE_ACE, deck.draw())`* = *결정적* — *덱이 정확히 어떤 카드를 반환하는지 검증*.
+
+해결 = *interface CardDeck + 결정적 구현체 주입* (PR #74·#95·#99 의 *Random 테스트* 결).
+
+### 10. `input/output/choice` 변수명 모호
+
+말리빈: *"input, output, choice는 다른 개발자들이 이름만 보고 어떤 의미인지 한 번에 파악할 수 있을까요?"*
+
+→ **MCP 기존 룰 `vagueName`** (lotto/racingcar `vagabond95` 인용) 결. *추상 명사 (`input`/`output`) 가 *컨텍스트 모호* + *위치별로 다른 의미* 위험*. 대안 = `playerNameInput` / `gameResultOutput` / `hitOrStayChoice`.
+
+### 11. `Answer.kt` 도메인에 "y","n" View 요소 누수
+
+말리빈: *"Answer를 domain으로 분류해주셨네요 :) 'y', 'n'는 뷰의 요소이니 분리해주세요 :)"*
+
+→ **도메인-뷰 경계 명확화**. *Answer enum 자체는 도메인 (`Hit`/`Stay`)* + *"y","n" 입력 표현은 View*. *View → Answer 변환은 ViewModel/Mapper 영역*. PR #28·#78·#112·#125·#147 의 *enum koreanText/description* 결.
+
+### 12. `프로덕션 코드 + 테스트용 로직` — 분리 권고
+
+말리빈: *"테스트 코드에서만 사용되는 로직을 프로덕션 코드에 넣는 것은 지양해주세요 :)"*
+
+→ **테스트 전용 코드 = 테스트 모듈에**. *프로덕션 코드 + 테스트 헬퍼* = *프로덕션 API 오염 + 의도 모호*. PR #99 (s6m1n *Test Fixture 함수 분리*) 결.
+
+### 13. 딜러 16/17 룰 미준수 — 블랙잭 룰 정확성
+
+말리빈: *"딜러의 점수가 16이하이면 17이상이 될 때까지 카드를 계속 받아야합니다 :) 블랙잭 규칙을 로직에 잘 반영해주세요!"*
+
+→ **MCP 룰 후보 — `blackjack-rule-fidelity`** (도메인 특수). *딜러 자동 hit ≤16 / Ace+10 두 장 블랙잭 / Bust 개별 판정* 등 *블랙잭 룰 정확성*. PR #20·#64·#110·#120·#29·#63 의 *블랙잭 룰 오해* 결.
+
+## 리뷰어 의견 요지 (말리빈 / malibinYun)
+
+28 코멘트 특징 (PR #74 와 동일한 reviewer):
+
+- **메타 질문 어휘** — *"~ 어떨까요?"*, *"~ 어떤 점이 다른가요?_?"*, *"~ 어떤 일이 생길 수 있을까요?"* — 학생 자가 답변 유도. PR #74·#95 와 동일.
+- **외부 자료 첨부** — *Kotlin 공식 문서 + Kotlin Academy 블로그 (Item 30)*. **MCP `oh-my-oop` 의 *외부 자료 인용* 어휘**. PR #95·#67·#74 결.
+- **공식 의견 + 개인 의견 분리** — *"위 같은 의견도 있지만, 아래는 제 개인적인 의견입니다 ㅎ_ㅎ"* — **MCP `oop_propose_alternatives` 의 *N 안 + 트레이드오프* 어휘와 일치**. PR #95 (*"옳고 그름 없고 장단점만"*) 결.
+- **그림 첨부 의존 관계** — *플레이어 → Dealer 의존 그림* (이미지 URL 첨부) — 텍스트 < 시각화. PR #98·#99·#146·#148 의 *다이어그램* 결.
+- **이전 미션 학습 자가 연결 권고** — *"이전 로또 미션에서 LottoNumber를 캐싱했던 것 처럼"* — *racingcar/lotto 학습 자가 자가 적용 권유*. PR #95·#67 결.
+- **머지 후 후속 코멘트 활발** — *3월 8·9·12일* 양측 코멘트. *PR 머지 = 학습 종료 X*.
+
+## 대표 인용
+
+> *"플레이어와 플레이어는 사실 경쟁 상대가 아니기 때문이에요. 플레이어끼리 결과를 비교하면, 어떤 플레이어가 이겼는 지 알기도 어려울 것으로 예상돼요."* — malibinYun (도메인 룰 + 점수 책임 위치)
+
+> *"위 같은 의견도 있지만, 아래는 제 개인적인 의견입니다 ㅎ_ㅎ 저는 딜러도, 플레이어도 아닌, 그 부모 객체인 Participant에 위치해도 좋다는 생각이에요. 사실 결과 자체는 누가 가지고 있는 지 보다, 카드더미만 있으면 알 수 있으니까요."* — malibinYun (공식 의견 + 개인 의견 메타 분리)
+
+> *"이모지를 써야만 한다는 의미가 아니었어요. 카드 심볼에 대한 View의 출력 형태는 언제든지 변경 가능하다는 의미였습니다. (...) 그렇다면, 이 모든 변경 가능할 요소들을 domain이 가지고 있는 게 맞을 지에 대한 질문이었어요!"* — malibinYun (학생 표면 해석 → 본 의도 부연)
+
+> *"저는 플레이어의 승패가 딜러보다 먼저 결정나고('플레이어가 버스트 된다면 플레이어는 딜러가 버스트 되더라도 진다'라는 규칙) 또한, 딜러의 승패 종합 결과는 플레이어들에 의해 정해진다고 생각했습니다."* — rhthrhrl0 (학생 자가 도메인 룰 정당화)
+
+> *"else를 지양하라는 말에 너무 집중하다보니 극단적으로 else를 안쓰게 된 것 같습니다. 지적해주셔서 감사합니다."* — rhthrhrl0 (원칙 극단 적용 자가 인정)
+
+> *"이걸 사용하면 순차처리가 아닌 병행 처리가 가능해진다고 확인했습니다. 덕분에 에러가 발생하면 멈추고 뒤에 것이 테스트 안되는게 아니라 이 하나의 전체 그룹에서 발생한 모든 오류를 체크 가능하다는 글을 읽었습니다. 알려주셔서 감사합니다!!"* — rhthrhrl0 (assertAll 자가 학습 + 의미 정리)
+
+## 얻은 교훈
+
+1. **점수 계산 책임 위치 = *Dealer / Player / Participant* 3 후보 + 도메인 룰 + 현실 메타포** — *블랙잭 = Dealer vs 각 Player 1:1 비교* + *Player vs Player 비교 X* + *Dealer 가 결과 알려주는 현실 메타포*. **MCP 룰 후보 — `dealer-vs-player-result-locus`** (도메인 특수). PR #70·#74·#148·#151·#49·#132 결.
+
+2. ***공식 의견 + 개인 의견 메타 분리*** = **MCP `oh-my-oop` 의 *N 안 + 트레이드오프* 어휘와 일치**. *reviewer 가 *권위적 단일 답* 이 아니라 *주된 권고 + 개인 의견 + 학생 선택지* 명시*. PR #95 (*"옳고 그름 없고 장단점만"*) 결.
+
+3. ***학생 표면 해석 → reviewer 본 의도 부연*** — *학생이 *"이모지를 써야 하나요?"* 표면 의문 → reviewer *"카드 심볼 표현이 가변임을 의미"* 본 의도 부연*. **학생이 모르는 채로 두지 않으려는 자가 명시 + reviewer 의 명확화 어휘**. PR #95·#99 결.
+
+4. **`~~~er` 접두사 명명 함정** — *`Drawer = 서랍` 의 영어 사전 의미* 와 *`카드 뽑는 자` 의도* 충돌. **MCP 룰 후보 — `er-suffix-collision`** = *영어 사전 다중 의미 충돌 검사*.
+
+5. **`Set<Card>` vs `List<Card>` 자료구조 선택** = *중복 차단 vs 여러 벌 카드 요구사항*. **자료구조 선택 = 요구사항 확장 가능성 고려**. PR #58 의 *카지노 6덱 메타포* 결.
+
+6. **갯수만 검증 = 무의미 테스트** — *결정적 카드 검증 + 랜덤 제어 (interface + 구현체) 정공*. PR #74·#95·#99 의 *Random 테스트* 결.
+
+7. **이전 미션 학습 자가 연결 권고** — *"로또 미션의 LottoNumber 캐싱"* → *블랙잭 Card 캐싱* — *racingcar/lotto/blackjack 미션 간 학습 연쇄*. **양 단계 + 양 미션 본 reviewer 만 가능한 권유**.
+
+8. **외부 자료 첨부** = *공식 문서 + 블로그 + Kotlin Academy Item 시리즈* — *학생 자가 학습 채널 확장*. *PR 코멘트 = 짧은 텍스트* + *외부 자료 = 깊은 학습*. PR #95·#67·#74 결.
+
+9. **그림 첨부 의존 관계** = *텍스트 < 시각화*. *Player → Dealer 의존 그림* = *학생이 *의존 방향*을 시각적으로 파악*. PR #98·#99·#146·#148 의 *다이어그램* 결.
+
+10. **`else` 자가 학습 (원칙 극단 적용 자가 인정)** — *"else를 지양하라는 말에 너무 집중하다보니 극단적으로 else를 안쓰게 된 것 같습니다"*. **원칙 = 일률 적용 X + 컨텍스트 균형**. PR #146 (*YAGNI*) / PR #151 (*반란군 비유*) / PR #98 (*상태 패턴 효과 의문*) 결.
+
+11. ***머지 후 후속 코멘트 = 학습 지속*** — *3일 후, 6일 후 양측 코멘트* — *PR 머지 = 학습 종료 X*. PR #128·#135·#108·#136 의 *학생 자가 토론 지속* 결.
+
+12. **블랙잭 룰 정확성 = 도메인 특수 진단** — *딜러 ≤16 자동 hit* = *블랙잭 도메인 룰 미준수 가능성* — **MCP 룰 후보 `blackjack-rule-fidelity`**. PR #20·#64·#110·#120·#29·#63 결.
+
+13. **`Answer enum + "y"/"n" View 누수`** = *도메인-뷰 경계 명확화*. PR #28·#78·#112·#125·#147 의 *enum koreanText/description* 결의 *블랙잭 변형*.
+
+14. **`재귀 호출 의도 자가 정당화`** — *학생이 *코드 표면 (중복)* 이 아닌 *의도 (양분기 + 종료 조건)* 명시*. **자가 정당화 ≠ 권고 거부**. *학생이 *왜 이렇게 작성했는지* 명시 + reviewer 가 *그 의도가 잘 전달되는지* 평가* — 양방향 토론 모범.

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

@@ -0,0 +1,238 @@
+# PR #39 — [블랙잭 2단계] 멘델 미션
+
+- **Reviewee:** [@rhthrhrl0](https://github.com/rhthrhrl0)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/39
+- **단계:** 2단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 23 스레드 — *1단계 권고 적극 자가 반영 + State/Phase 패턴 도입 + 그러나 과도한 일급화·deepCopy 새 안티패턴*
+- **양 단계 분석 reviewee** (1단계 #23 별도). 학생 자가 마감 당일 사과 + 상태 패턴 처음 시도 자가 명시.
+
+## 잘한 점 (설계 관점)
+
+- **`Phase` 추상화 = View 분리 정공 — 말리빈 놀람 칭찬** — *"view에 대한 요소들을 Phase로 추상화한 것은 정말 신선한 발상이네요!! 👍"* / *"View를 Phase로 추상화한 형태가 매우 흥미롭네요 👍"*. **학생 자가 *진행 단계 (Phase) 객체화* 발상** — *명령형 절차 < 단계 객체 시퀀스*. PR #98·#99·#137 의 *진행 흐름 추상화* 결.
+- **상태 패턴 자가 학습 (1단계 후 새로 학습)** — PR 본문: *"이번에 새로 배운 상태 패턴 개념을 추가해서 적용하는데 시간이 좀 걸려서 리뷰 요청이 늦어졌습니다."* + *"상태 패턴 적용이 처음이라서 잘못된 부분들을 지적해주시면 감사하겠습니다!!"*. 말리빈 머지 시점 칭찬: *"상태 패턴을 열심히 구현해주셨네요 👍👍 처음 구현해보기에는 어려우셨을텐데 잘 구현해주셨네요!"*. **자가 학습 + 자가 명시 모범** — PR #98 (chaehyuns *상태 패턴 처음*) 결.
+- **1단계 PR URL 본문 자가 참조** — *"저번 step1때 달렸던 나머지 피드백들도 최대한 반영해봤고 달렸던 코멘트들에 대해서도 제 생각과 궁금점들을 코멘트로 달아놨습니다. https://github.com/woowacourse/kotlin-blackjack/pull/23"*. **양 단계 본 reviewer 만 가능한 1단계 코멘트 답변 + 2단계 PR 본문 URL 자가 참조** — PR #99·#95 의 *1단계 코멘트 URL 자가 참조* 결.
+- **카드 캐싱 + elvis 활용 권고 (1단계 권고 자가 반영)** — 말리빈: *"카드를 잘 캐싱해주셨네요! 👍👍 of 메서드는 ?: (elvis operator)의 활용을 도전해보세요 :)"*. PR #23 1단계의 *LottoNumber 캐싱* 권고 자가 반영. PR #74·#108·#133·#136·#23·#26 와 같은 결.
+- **Score `compareTo` 오버로딩 권고** — 말리빈: *"compareTo 연산자를 오버로딩 해볼 수도 있어요 :)"*. **Kotlin 연산자 오버로딩 어휘** — PR #93·#136·#152 의 *State.compareTo* 다형성 결.
+- **suggestion 블록 활용** — `if (cardsState is BustState) return true else return false` → `return cardsState is BustState`. **Kotlin 표현식 함수** — PR #26 (잭슨 `isPossibleDrawCard` suggestion) 결.
+- **머지 시점 학생 자가 회고** — *"그동안 감사했습니다!! 아래 달아주신 코멘트들에 대해서 좀 더 고민해보고 다음 미션 때 적용시켜보겠습니다 :)"*. PR #95·#98·#99 의 *학생 자가 회고* 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `NameAndBet` 명명 + `PlayersNameAndBet` 일급 컬렉션 과적용
+
+말리빈 진단 1: *"플레이어의 정보를 나타내고 싶은 class 같은데, 이름에 큰 의미를 부여하긴 어려워 보이네요. 더 나은 이름을 고민해볼까요? 🤔"*
+
+말리빈 진단 2: *"이 객체는 값을 갖고만 있고, 특별한 역할을 하지 않아 쓸모를 느끼기 어려워요. 모든 컬렉션을 반드시 일급 컬렉션으로 래핑할 필요는 없다고 생각해요 🙂"*
+
+→ **2 가지 학습**:
+
+#### 1.1. *`NameAndBet` = and 접속어 명명 안티패턴*
+
+- *`NameAndBet`* = *Name + Bet 두 속성 이어붙임* = *도메인 어휘 X + 책임 모호*.
+- 대안:
+  - **`PlayerInfo`** — 추상 명사, 여전히 모호.
+  - **`PlayerProfile`** — *기본 정보 + 베팅 = "프로필"* 어휘.
+  - **`Bettor` / `PlayerRegistration`** — *책임 (베팅하는 자 / 게임 참가 등록 정보) 중심*.
+- **MCP 룰 후보 — `and-conjunction-name`** = *Name + Bet, Hand + Wallet 같은 *접속어 명명* 검사*. PR #133·#88·#132·#136·#93 의 *3 변수 제약 부산물 인공 객체* 결.
+
+#### 1.2. *모든 컬렉션 일급 X — 일급 컬렉션 과적용 안티패턴*
+
+- *`PlayersNameAndBet`* = `List<NameAndBet>` 일급 화 + *행동 없음*.
+- *일급 컬렉션 = *컬렉션 + 도메인 행동* 의 조합*. *행동 없는 일급 화 = 의미 없는 래퍼*.
+
+**MCP 룰 후보 — `first-class-collection-without-behavior`** = *lotto 의 `collection-wrapper-without-behavior` 변형*. PR #133·#74·#108·#99 의 *일급 컬렉션 자가 학습* 결의 *역효과*.
+
+### 2. `BlackJackCardDeck` 카드 개수 별도 상태
+
+말리빈: *"카드 개수의 상태를 따로 갖고 있는 것 보단, 카드 목록을 컬렉션에 넣어서 뽑아 쓰는 방식은 어떠신가요? 🙂"*
+
+→ **컬렉션 자체 = 개수 정보 포함**. *`cards.size` 가 *상태* 그 자체*. *`var remainingCount: Int` 별도 = *컬렉션 + 카운터 = 동기화 책임 + 버그 위험*.
+
+PR #23 1단계의 *Set vs List* / PR #26 1단계의 *카드 뽑기 + 제외* 결. **`redundant-state` 안티패턴**.
+
+### 3. `Cards.deepCopy` — *정말 deepCopy 인가?*
+
+말리빈: *"deepCopy가 정말 필요할까요? 정말로 'deepCopy'가 이루어지고 있을까요?"*
+
+→ **2 가지 메타 의문**:
+
+#### 3.1. *deepCopy 필요성*
+
+- *Cards 가 불변이라면 deepCopy 불필요* — *동일 인스턴스 공유 무해*.
+- *Cards 가 가변이라면* deepCopy 정공.
+- *학생 코드 = *불변 의도* 인데 deepCopy 잔재* = **불필요한 방어**. 
+
+#### 3.2. *정말 deepCopy 인가?* — 명명 vs 실제
+
+- *`deepCopy()`* 명명 = *재귀적 깊은 복사 의미*.
+- *학생 코드*가 *얕은 복사 (shallow copy, e.g., `cards.toList()`)* 라면 *명명 거짓*.
+- **MCP 기존 룰 `defensive-copy-on-immutable`** (batch 10·11) + *명명 정확성*.
+
+PR #137·#148 의 *방어적 복사 강박 자가 학습* 결.
+
+### 4. `Cards 불변 의도 + 가변 내부` + 매번 계산
+
+말리빈: *"Cards를 불변 객체로 만들어주신 것 같아요. 불변 객체를 의도하셨지만 내부는 가변 객체를 가지고 있네요 :) 반드시 가져야할 가변 객체일까요? 컬렉션에도 + operator가 오버로딩 되어있답니다 😊 또, 불변 객체이면, 위 프로퍼티들을 호출할 때마다 계산하는 함수들을 매번 호출해주어야할까요?"*
+
+→ **3 가지 학습**:
+
+#### 4.1. *불변 의도 + 가변 내부 = 의도 누수*
+
+- *`Cards(val cards: List<Card>)`* — *List 자체는 불변 인터페이스* 이지만 *백킹 객체가 `MutableList`* 라면 *외부 캐스팅으로 변경 가능*. PR #74 (송핑크 *불변 객체 자가 학습*) 결.
+
+#### 4.2. *컬렉션 `+ operator` 오버로딩*
+
+- *`cards + newCard`* = *불변 List + 새 Card → 새 List 생성*. Kotlin 표준 라이브러리.
+- *학생 코드의 `add(card: Card): Cards = Cards(this.cards + card)` 같은 형태* 가 정공.
+
+#### 4.3. *불변 + 매번 계산 함수 호출 = 비효율*
+
+- *`fun sum() = cards.sumOf { it.value }`* — *매 호출마다 N 회 합산*.
+- *불변 객체 + 생성 시점 계산* = *`val score: Int = cards.sumOf { it.value }`* 한 번 + 캐시.
+
+**MCP 룰 후보 — `immutable-recompute-on-call`** = *불변 객체의 비싼 계산이 매 호출마다 반복 = 캐싱 정공*.
+
+### 5. `Cards.sum + ACE_ADDITIONAL_VALUE` 중복 연산
+
+말리빈: *"sum + ACE_ADDITIONAL_VALUE 연산을 중복으로 수행하네요 :) 한 번만 수행하도록 지역 변수에 할당해볼까요? 😊"*
+
+→ **중복 연산 = 지역 변수 추출**. PR #95 (송핑크 *when 6번 합산 → 변수 저장*) 결.
+
+### 6. `BlackJackGame.run()` 결과 반환
+
+말리빈: *"phases.run()을 하면, Result를 반환하게 만들어보는 것은 어떨까요?"*
+
+→ **사이드 이펙트 < 결과 객체 반환** — PR #95·#99·#23 의 *결과 객체 반환* 결.
+
+### 7. `State 생성자 주입` 권유
+
+말리빈: *"State도 생성자로 받는다면, 어떤 장점이 생길 수 있을까요? 😊"*
+
+→ **State 객체 외부 주입 가능성**:
+- *`Participant(name: Name, state: State = InitialState)`* — *State 외부 주입 = 테스트 시 임의 상태 시작 + 다양한 시나리오*.
+- *내부 고정 (`InitialState` 만)* = *테스트 시 N 번 카드 추가 후 특정 상태 도달 시뮬레이션 필요*.
+
+테스터빌리티 + 유연성. PR #98 (chaehyuns *State 객체 데이터 = 행동에 필요 최소*) 결.
+
+### 8. `BetProfitResultTest` 에 `Participants` 불필요
+
+말리빈: *"이 테스트에 정말로 Participants 객체가 필요할까요?"*
+
+→ **테스트 최소 의존**. *`BetProfitResult` 테스트인데 *Participants* 까지 생성 = *과한 객체 그래프*. PR #99·#26 의 *Test Fixture 품질* 결.
+
+### 9. `BlackJackCardDeckTest` 51장 동일 카드 — 무의미
+
+말리빈: *"테스트에 동일 카드를 51장 넣어야할까요? 실제로 2번째의 카드를 뽑았는지, 50번째 카드를 뽑았는지 판단하기는 어려워보여요. 필요한 만큼만 카드를 세팅해주는 것은 어떨까요?"*
+
+→ **테스트 입력 = 검증 가능한 최소**. *51장 동일 카드 = 어떤 카드를 뽑았는지 무관 = 검증 자체 무의미*. PR #23 1단계 *갯수만 검증 무의미* 결.
+
+### 10. `BlackJackGame` 테스트 가능성 — 랜덤 끌어올림
+
+말리빈: *"카드 덱에 대한 랜덤 요소를 더 끌어 올리면, BlackJackGame도 테스트할 수 있게 만들어볼 수 있겠네요 🙂"*
+
+→ **랜덤 = 가장 바깥 계층으로 끌어올림 (Functional Core, Imperative Shell)**:
+- *내부 (BlackJackGame, Deck) = 결정적 + 주입된 카드 시퀀스 의존*.
+- *외부 (Controller, main) = 랜덤 생성 + 주입*.
+
+PR #23 1단계·#26·#95·#99·#74 의 *랜덤 테스트* 결.
+
+### 11. `ProfitMoney` 팩터리 + `Score` 생성자 — 기준 의문
+
+말리빈: *"생성자로 만들지 않고 팩터리 메서드로 만든 이유와 기준이 궁금하네요 :)"* (ProfitMoney)
+
+말리빈: *"value를 갖고있는 Primary 생성자가 더 자연스러워보이는데, 이렇게 생성자를 구성한 이유와 기준이 궁금하네요 :)"* (Score)
+
+→ **객체 생성 방식 = *명확한 의도***:
+- *Primary constructor* = *기본 + 가장 단순*.
+- *Secondary constructor* = *primary 의 변형 + 다른 인자 조합*.
+- *Factory method (`companion object.of()`)* = *복잡한 유효성 검증 + 캐싱 + 명확한 명명* (e.g., `Card.of(SPADE, ACE)`).
+- *학생 코드의 `ProfitMoney` 팩터리 + `Score` 비정상 생성자* = *기준 일관성 부재*.
+
+**MCP 룰 후보 — `factory-vs-constructor-inconsistency`** = *동일 코드베이스 내 생성 방식 기준 통일 권고*.
+
+### 12. `i` 변수 모호 + `vagueName` 결
+
+말리빈: *"i가 어떤 의미인지 다른 개발자들은 한 번에 파악할 수 있을까요?"*
+
+→ **MCP 기존 룰 `vagueName`** + *짧은 변수명 (`i`, `j`, `n`)*. *반복문 인덱스 관용 `i`* 외에는 *명확한 의미 명명*. PR #95 (송핑크 *ind 축약어*) / PR #23 1단계 *input/output 모호* 결.
+
+### 13. `한 메서드 = 하나의 일`
+
+말리빈: *"한 메서드에서는 하나의 일만 하게 만들어주세요 :)"*
+
+→ **Single Responsibility Principle (메서드 수준)**. *PlayersResultInfo.엮인 책임 (계산 + 출력 + 변환)* 가능성. PR #98·#99·#137 의 *책임 분리* 결.
+
+### 14. `에러 메시지에 입력값 포함`
+
+말리빈: *"에러 메시지에 어떤 입력이 들어왔는지도 알려주는 것은 어떨까요?"*
+
+→ **`throw IllegalArgumentException("값이 잘못되었습니다")` < `throw IllegalArgumentException("값이 잘못되었습니다: input=$input")`**. *디버깅 친화도 + 사용자 친화도*. PR #146 (yrsel) 결.
+
+### 15. `덱 소진 후 테스트` — 모든 케이스 검증
+
+말리빈: *"덱을 모두 소진 한 뒤, 원하는 카드를 뽑는 테스트 코드를 작성할 수 있을까요?"*
+
+→ **경계 조건 테스트**. *덱이 비었을 때 = 도메인 경계*. *예외 발생 / 빈 옵셔널 반환 / 덱 리필* 등 *명확한 도메인 룰* 검증.
+
+PR #74·#26 의 *카드 부족 시 게임 종료 UX* 결.
+
+### 16. `확장 함수 체이닝 도전`
+
+말리빈: *"확장 함수 체이닝으로의 변경을 도전해보아요 🙂"*
+
+→ **Kotlin 함수형 어휘**:
+- *`for (player in players) { ... }`* (명령형) < *`players.map { ... }.filter { ... }.sumOf { ... }`* (선언형 체이닝).
+- PR #26 (스캇 *forEach → map/groupingBy*) 결.
+
+## 리뷰어 의견 요지 (말리빈 / malibinYun)
+
+23 코멘트 특징 (PR #23 와 동일 reviewer):
+
+- **메타 질문 어휘** — *"~ 어떨까요?"*, *"~ 어떤 장점이 생길 수 있을까요?"*, *"~ 정말 필요할까요?"*, *"~ 이유와 기준이 궁금하네요"* — 학생 자가 답변 유도. PR #23·#74·#95 와 동일.
+- **명명 의문 어휘 다중** — *"이름에 큰 의미를 부여하긴 어려워 보이네요"* / *"이 객체는 값을 갖고만 있고, 특별한 역할을 하지 않아 쓸모를 느끼기 어려워요"* — *명명 ≠ 책임* 진단.
+- **모든 컬렉션 일급 X 메타 어휘** — *"모든 컬렉션을 반드시 일급 컬렉션으로 래핑할 필요는 없다고 생각해요 🙂"* — **일급 컬렉션 *과적용 경고*** 어휘. *학생이 1단계 학습 후 *과도 적용* 한 안티패턴 자가 진단*.
+- **신선한 발상 칭찬** — *"View를 Phase로 추상화한 형태가 매우 흥미롭네요 👍"*, *"정말 신선한 발상이네요!! 👍"* — **학생의 *창의적 추상화* 명시 인정**. PR #146 (yrsel typealias) / PR #148 (etama 추상화 확장) 결.
+- **머지 시점 종합 코멘트** — *"상태 패턴을 열심히 구현해주셨네요 👍👍 처음 구현해보기에는 어려우셨을텐데 잘 구현해주셨네요!"* — *학생 자가 *상태 패턴 처음* 자가 사과* + *reviewer 인정* = *학습 진화 모범*. PR #98·#99 결.
+
+## 대표 인용
+
+> *"이번에 새로 배운 상태 패턴 개념을 추가해서 적용하는데 시간이 좀 걸려서 리뷰 요청이 늦어졌습니다. 공식적 마감 당일날에 너무 많은 커밋을 한번에 올려서 죄송합니다.... 저번에 피드백 주신 것들은 최대한 반영해봤고 추가적으로 다른 부분들도 수정해봤습니다. 상태 패턴 적용이 처음이라서 잘못된 부분들을 지적해주시면 감사하겠습니다!!"* — rhthrhrl0 (학생 자가 학습 + 자가 사과 + 자가 명시 모범)
+
+> *"모든 컬렉션을 반드시 일급 컬렉션으로 래핑할 필요는 없다고 생각해요 🙂"* — malibinYun (일급 컬렉션 과적용 경고)
+
+> *"View를 Phase로 추상화한 형태가 매우 흥미롭네요 👍"* — malibinYun (학생의 창의적 추상화 인정)
+
+> *"deepCopy가 정말 필요할까요? 정말로 'deepCopy'가 이루어지고 있을까요?"* — malibinYun (방어적 복사 강박 + 명명 정확성 메타 의문)
+
+> *"불변 객체이면, 위 프로퍼티들을 호출할 때마다 계산하는 함수들을 매번 호출해주어야할까요?"* — malibinYun (불변 + 매번 계산 = 비효율 자가 학습 권유)
+
+> *"상태 패턴을 열심히 구현해주셨네요 👍👍 처음 구현해보기에는 어려우셨을텐데 잘 구현해주셨네요!"* — malibinYun (머지 시점 학습 진화 인정)
+
+> *"그동안 감사했습니다!! 아래 달아주신 코멘트들에 대해서 좀 더 고민해보고 다음 미션 때 적용시켜보겠습니다 :)"* — rhthrhrl0 (학생 머지 시점 자가 회고 + 후속 학습 의지)
+
+## 얻은 교훈
+
+1. ***모든 컬렉션 일급 X — 일급 컬렉션 과적용 안티패턴*** — *행동 없는 일급화 = 의미 없는 래퍼*. **MCP 룰 후보 `first-class-collection-without-behavior`** (lotto `collection-wrapper-without-behavior` 변형). PR #133·#74·#108·#99 의 *일급 컬렉션 자가 학습* 결의 *역효과*.
+
+2. **`and 접속어 명명`** = *`NameAndBet`, `HandAndWallet` 같은 *두 속성 이어붙임* = *도메인 어휘 X + 책임 모호***. **MCP 룰 후보 `and-conjunction-name`**. PR #133·#88·#132·#136·#93 의 *3 변수 제약 부산물 인공 객체* 결.
+
+3. **불변 의도 + 가변 내부 = 의도 누수** — *`Cards(val cards: List<Card>)` + 백킹 `MutableList` 가능*. *kotlin 의 List 인터페이스 자체는 불변 보장 X*. PR #74 (송핑크 *불변 객체 자가 학습*) 결.
+
+4. **불변 객체 + 매번 계산 함수 호출 = 비효율** — *`val score: Int = ...`* 1회 계산 vs *`fun score() = ...`* N회 계산. **MCP 룰 후보 `immutable-recompute-on-call`**.
+
+5. ***deepCopy 명명 vs 실제* 의문** — *명명 = 깊은 복사 의미 + 실제 = 얕은 복사 가능성*. **명명 정확성 + 방어적 복사 강박** — PR #137·#148 의 *defensive-copy-on-immutable* 결.
+
+6. **State 객체 외부 주입 = 테스터빌리티** — *Participant(state: State = InitialState)* = *임의 상태 시작 시뮬레이션 가능*. PR #98 (chaehyuns *State 객체 데이터 최소화*) 결.
+
+7. **랜덤 = 가장 바깥 계층으로 끌어올림 (Functional Core, Imperative Shell)** — *내부 = 결정적 + 외부 = 랜덤 주입*. PR #74·#23·#95·#99·#26 의 *Random 테스트* 결.
+
+8. **객체 생성 방식 = 명확한 의도 (factory vs constructor)** — *기본 = primary, 변형 = secondary, 복잡 = factory*. *동일 코드베이스 내 일관성*. **MCP 룰 후보 `factory-vs-constructor-inconsistency`**.
+
+9. **`Phase` 추상화 = 학생의 창의적 발상** — *진행 단계 객체화 → View 분리 + 흐름 명시*. PR #98 (chaehyuns State 패턴) / PR #99 (s6m1n 람다 콜백) 와 다른 *제3의 추상화*. **`phase-pattern`** = *블랙잭 진행 단계를 객체 시퀀스로 표현* — 도메인 특수 패턴.
+
+10. **학생 *상태 패턴 처음* 자가 사과 + reviewer 인정 = 학습 진화 모범** — *PR 본문 자가 사과 + 머지 시점 reviewer 인정 + 학생 자가 회고 (다음 미션 적용)* 3 단계. PR #98 (chaehyuns *추후 시간 될 때 다시*) / PR #95 (송핑크 *처음부터 다시 만들어보기*) 결.
+
+11. **PR 본문 + 1단계 PR URL 자가 참조** — *2단계 학생이 *1단계 코멘트 답변 + PR URL 첨부*. *양 단계 본 reviewer 만 가능한 학생 자가 학습 가시화*. PR #99·#95 결.
+
+12. **suggestion 블록 활용 (Kotlin 표현식 함수)** — `if return true else return false` → `return ...`. PR #26 (잭슨 `isPossibleDrawCard`) 결.