oh-my-oop 0.2.0

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

@@ -0,0 +1,216 @@
+# PR #32 — [블랙잭 1단계] 크롱 미션
+
+- **Reviewee:** [@krrong](https://github.com/krrong) — **이 학생이 PR #148·#151 의 reviewer** (크롱). 학생/리뷰어 메타 흥미 케이스.
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/32
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 29 스레드 — *Card 인스턴스 캐싱 + Referee → Dealer 통합 + 사이드 이펙트* 학습 풍부
+
+## 잘한 점 (설계 관점)
+
+- **`Card` 52개 인스턴스 미리 캐싱 + Card.all() 재활용 자가 학습** — 학생 자가 답변: *"이번 리뷰를 받고 `Card`클래스에 미리 52개의 카드 인스턴스를 만들어두고 재사용 할 수 있도록 수정했습니다. 이렇게 되면 기존에 있던 모양과 숫자를 랜덤으로 생성하는 클래스들은 필요 없어진다고 생각이 들어 삭제하였고, `CardDeck` 클래스에서 카드를 뽑을 때 랜덤으로 동작하도록 수정했습니다."* — *카드 = 52개 고정 + 뽑는 순서가 랜덤* 메타포 자가 인식. **PR #148 의 *크롱 리뷰어 본인이 학생 시절 같은 자가 학습 진행* — 메타 흥미 케이스!**
+- **`Referee` → `Dealer` 통합 자가 학습** — 학생 자가 답변: *"딜러와 플레이어의 승패를 계산하고 저장하는 `Referee`클래스를 만들어 해당 로직들을 이동했습니다!"* + 추가 후속: *"사이드 이펙트를 발생시키지 않기 위해 Referee 클래스를 삭제하고 승자를 판단하는 로직을 다시 딜러에게 주었습니다! 딜러는 플레이어들의 리스트를 받아서 점수를 비교하고 최종 결과를 `Map<String, Consequence>`형태로 돌려주도록 하였습니다!"*. **Referee 도입 후 부수효과 진단 → 딜러 통합 후퇴 자가 학습 모범**. PR #74 (알송, 말리빈) 의 *Referee 자가 토론* / PR #58 (수달, 페로로) 의 *학생 Referee 추구* 와 같은 결.
+- **사이드 이펙트 = Player 가변 vs 결과 반환 자가 학습** — 학생 자가 인용: *"이 메서드에서 발생시키는 사이드 이펙트는 Player 가 갖고 있는 승패에 대한 정보를 바꾸는 것을 의미하는 것으로 이해했는데 맞을까요?"* + 말리빈 인정 + 위키 링크. **사이드 이펙트 정의 자가 학습**. PR #85·#137·#148 와 같은 결.
+- **`CardNumber.ACE.value = null` → ACE 1 기본 자가 학습** — 학생 자가 답변: *"이 부분에 대해서 페어와 많은 의견을 나누었습니다. 다른 카드와는 다르게 ACE카드는 1과 11로 사용이 가능하기 때문에 특정 값으로 고정 시키기보다 null로 만든 뒤에 점수를 계산하는 부분에서 상황에 맞게 처리하자는 결론이 나와 위와 같이 작성했습니다! ACE카드는 일반적으로 1로 사용하기 때문에 그에 맞게 수정했습니다!"* + 말리빈: *"`점수를 계산하는 부분에서 상황에 맞게 처리하자`는 의견은 동의해요 :) 하지만, CardNumber 내부 값이 null인지 아닌지 비교하기보다는, CardNumber 자체가 ACE인지 비교를 하면 된다고 생각해요"*. **`null` 우회 vs `is ACE` 명시 비교 자가 학습**.
+- **`isSuccessAddCardToPlayer` 함수명 자가 학습** — 말리빈 진단 *"addCard를 했는데 반환은 Boolean이네요 :) C 스타일의 코드처럼 느껴졌습니다."* + 학생 자가 반영. *Boolean 반환 시 명시적 이름*. PR #124·#125·#114·#41 와 같은 결.
+- **`Set<Card>` → `List<Card>` 자가 학습** — 말리빈 진단 *"이후에 카드 여러 벌을 가지고 게임을 할 수 있는 요구사항이 추가된다면, Set으로 구현했을 때 어떤 일이 발생할 수 있을까요?"* + 학생: *"블랙잭 도메인에 대한 지식이 부족해서 단순히 52장의 카드로만 진행하는 게임이라고 생각했습니다."* + List 변경. PR #58·#108 와 같은 결.
+- **`CardBunch` 2장 검증 자가 후퇴** — 학생 자가 인용: *"굳이 필요한 생성 조건인가?라는 생각을 했습니다. `CardBunch`는 단순히 유저가 들고 있는 카드를 의미하는데 생성 당시 2장임을 검사할 필요가 있는가, 컨트롤러에서 2장에 맞게 나누어주면 되는 것이 아닌가 하는 생각에 생성 조건을 삭제하였습니다!"*. *YAGNI + 책임 분배 자가 인식*.
+- **블랙잭 룰 정확성 자가 학습** — 말리빈 진단 *"딜러가 블랙잭일 때, 플레이어가 블랙잭이 아니면 모든 플레이어는 패배합니다. 블랙잭의 도메인에 대해 더 공부해서 반영해보세요"* + 학생 자가 반영 + *"총점이 21점을 넘으면 어떤 상태인지, 등등의 게임 용어들이 있었지요"* 후속 반영. PR #148·#108·#125·#114·#131·#136·#137·#151 와 같은 결.
+- **Card private constructor + 캐싱 + all() 활용 자가 반영** — 학생 자가 답변: *"코멘트 해주신 부분을 생각해보니 외부에서 올바른 값만 넣어주면 인스턴스를 생성할 수 있었고, 생성자를 private으로 바꿔서 Card 객체 이외에서는 인스턴스를 생성하지 못하게 막았고 `all()`을 통해 캐싱된 카드들을 가져다 쓸 수 있도록 변경하였습니다!"*. PR #108·#133·#136·#137·#146·#74 와 같은 결.
+- **`Effective Kotlin Item 4/14` 학생 자가 학습** — 말리빈 권고 *"Effective Kotlin 서적의 챕터를 참고해서 스스로 생각해본 것과 비교해보아요. Item 4 : Inferred Type으로 리턴하지 말라. Item 14 : 변수 타입이 명확하지 않은 경우 확실하게 지정하라"* — PR #108 (시아) 와 같은 결.
+- **`.sum { }` + `.any { }` Kotlin 확장 함수 자가 학습** — 학생 자가 인용: *"확장함수를 사용하니까 가독성도 좋고 코드도 짧아지네요 :) 더 공부해보도록 하겠습니당🙃"*.
+- **Test Fixture 자가 학습 + 한글 명명 결정** — *PR #67 (s6m1n) 의 `BeforeEach` setUp 한글 명명* 과 같은 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `CardBunch.size` 로 중복 카드 비교 — `contains` Kotlin 어휘 누락
+
+말리빈: *"중복 카드를 사이즈로 비교하는 게 매우 어색합니다. contains를 활용해보세요."*
+
+→ **`set.size != list.size` 우회 vs `list.contains(card)` 명시**. *Kotlin 어휘 = contains*. PR #67·#88 와 같은 결.
+
+### 2. `addCard` 가 Boolean 반환 = C 스타일
+
+말리빈: *"addCard를 했는데 반환은 Boolean이네요 :) C 스타일의 코드처럼 느껴졌습니다. 다른 개발자들은 해당 Boolean 값이 어떤 의미를 가지고 있을 지 한 번에 알아볼 수 있을까요?"*
+
+학생: *"Boolean값이 어떤 의미를 가지고 있을지 한 번에 알아볼 수 있도록 함수명을 `isSuccessAddCardToPlayer`으로 변경하였습니다!"*
+
+→ **Boolean 반환 = is/has 접두사 + 의미 명시**. PR #124·#125·#114·#41 와 같은 결.
+
+### 3. `CardNumber 출력 메서드` View 의존
+
+말리빈: *"해당 메서드는 View에서만 사용하네요 :) 도메인과 뷰의 로직을 분리해주세요."*
+
+→ **enum 출력 메서드 = View 책임 누수**. PR #124·#28·#78·#112·#125·#128·#135·#137·#75 와 같은 결.
+
+### 4. `overCondition` 함수명 모호
+
+말리빈: *"overCondition이란 말은 어떤 의미를 가지고있을까요? 다른 개발자들도 한 번에 알아볼 수 있을까요?"*
+
+학생: *"조금 더 직관적으로 알아볼 수 있게 `canGetCard`로 바꾸었는데 괜찮은 것인지 잘 모르겠네요,, 함수의 네이밍이 정말 어려운 것 같습니다..😢"*
+
+→ **`overCondition` = 모호 vs `canGetCard` = 직관**. *`canDraw()` / `canHit()` Kotlin 어휘*. PR #75·#151·#41 와 같은 결.
+
+### 5. `Player.calculateWinning` 사이드 이펙트 = Player 가변 변경
+
+말리빈: *"이 역할은 정말 이 객체의 역할일 지 고민해보세요 :) 또, 사이드이팩트를 발생시키는 메서드의 작성은 최대한 지양해보세요."*
+
+학생: *"딜러와 플레이어의 승패를 계산하고 저장하는 `Referee`클래스를 만들어 해당 로직들을 이동했습니다! 그리고 이 메서드에서 발생시키는 사이드 이펙트는 Player 가 갖고 있는 승패에 대한 정보를 바꾸는 것을 의미하는 것으로 이해했는데 맞을까요?"*
+
+말리빈: *"네 :) 사이드 이팩트에 대한 정의는 [이 링크](https://en.wikipedia.org/wiki/Side_effect_(computer_science))를 참고해보세요!"*
+
+→ **사이드 이펙트 = 함수가 외부 상태 변경 + 반환값 외 효과**. *순수 함수 (입력 → 출력)* 가 *예측 가능성*. *학생 자가 학습 모범*. PR #85·#137·#148 와 같은 결.
+
+### 6. `CardDeck` 랜덤 위치 학생 자가 토론
+
+말리빈 진단: *"shape와 card를 랜덤으로 생성할 필요가 있을까요? 해당 객체를 랜덤으로 생성했기에 필요하지 않은 로직들이 생겨나진 않았을까요? 정말로 랜덤이 필요한 곳은 어디일까요?"*
+
+학생 자가 답변 깊음 (700+자): *"이 부분은 열심히 고민해봤는데 마땅한 방법이 떠오르지 않습니다..😢 ... 나름의 고민의 결과로 CardDeck 자체가 아래 프로퍼티를 갖게 하는 방법을 생각했습니다. ... 하지만 이렇게 구현하게 되면 랜덤을 사용하기 때문에 단위 테스트가 불가능하다고 생각됩니다. 접근 방법이 잘못된 것일까요?"*
+
+말리빈 답변: *"지금은 카드를 뽑을 때 새로운 카드를 생성하는 형태이지요! 여러 벌의 카드를 사용할 때에 대해 생각해보면 좋겠어요 :) 또, 덱의 52장의 카드가 모두 떨어지면 이후 어떻게 해야할 지도 생각해보면 좋겠어요 🙂. 위 모두, 모양과 숫자가 동일한 카드를 재사용할 수 있다는 특징이 있지요. 한 번만 만들어두고 여러 번 재사용할 수 있게 만들어보셨으면 좋겠어요 :). 로또 번호도 45개를 만들어두고 재사용했었지요! **현실 세계에서 카드를 뽑으면, 카드의 요소가 랜덤 처럼 보이지만, 사실은 뽑는 카드의 순서가 랜덤이지요** 이런 생각으로 정말로 랜덤이 필요한 곳은 어디인지에 대해 질문을 드렸어요"*
+
+→ **랜덤 = 카드 자체 X, 뽑는 순서가 랜덤**. *카드 52장 고정 + 뽑는 순서가 랜덤* 메타포. *학생 자가 학습 + 자가 적용 (Card.all() 캐싱 + CardDeck.drawCard 랜덤) 모범*. **현실 메타포 핵심 인용**. PR #146·#108·#133·#136 와 같은 결.
+
+### 7. `CardDeck.drawCard 52장 모두 사용 후` 처리 부재
+
+학생 자가 인용: *"또 말씀해주신 여러 벌의 카드를 사용할 때는 `Card`클래스에 있는 값을 여러번 가져오도록 확장할 수 있고, 52장의 카드가 모두 떨어진 경우 역시 다시 카드를 가져올 수 있도록 확장할 수 있을 것 같다고 생각이 들었습니다. (현재는 `IllegalArgumentException`를 반환하도록 만들어둔 상태입니다)"*
+
+→ **카드 부족 시나리오 = `IllegalArgumentException` vs 무한 게임 메타포 트레이드오프**. PR #108·#133·#136·#41·#53·#74 와 같은 결.
+
+### 8. `Referee` 사이드 이펙트 → 삭제 + 딜러 통합
+
+말리빈: *"사이드 이팩트를 발생시키는 것 보다, 게임 결과를 반환하게 만들어보는 것은 어떨까요?"* + 후속: *"디미터의 법칙을 참고해서, 딜러와 플레이어의 점수를 가져오는 것을 변경해보는 것은 어떨까요?"*
+
+학생 자가 반영: *"딜러와 플레이어의 점수를 가져오기 위해 객체에 메시지를 넘기는 방법으로 수정했습니다. 또, 사이드 이펙트를 발생시키지 않기 위해 Referee 클래스를 삭제하고 승자를 판단하는 로직을 다시 딜러에게 주었습니다!"*
+
+→ **Referee 사이드 이펙트 + Demeter 위반 → Dealer 통합**. *현실 메타포 (Referee 분리) 시도 후 트레이드오프 후퇴 자가 학습*. PR #74·#58·#147 와 같은 결.
+
+### 9. `Card 의 init require` = 의미 없는 검증 (자가 인식)
+
+말리빈: *"이 로직은 정말로 의미 있는 검증일까요?"*
+
+학생: *"캐싱된 카드를 가져오기 때문에 필요 없을 것이라고 생각했었는데 혹시라도 다른 값을 넣어 Card 객체를 만들지 못하도록 작성했었는데 의미 없는 코드인 것 같아 삭제했습니다!"*
+
+→ **불필요한 방어 = 데드 코드**. *외부 호출 흐름 검증* 후 *불필요 시 삭제*. PR #88·#103·#147 와 같은 결.
+
+### 10. `ACE 보너스 체크 1번만` 자가 학습
+
+말리빈: *"ACE가 4장 있더라도, ACE의 점수 체크는 1번만 하면 됩니다. (카드 목록에 ACE의 유무 검사) 애초에 ACE가 2장이면, 22점이 아닌, 12점이기 때문이에요. 물론 2점으로도 사용할 수 있겠지요. 그 점을 고려해서 로직을 작성해볼까요? 😀"*
+
+학생: *"ACE의 값은 1로 고정하여 계산하도록 수정했습니다! 그리고 ACE를 가지고 있다면 10을 더해줘도 21을 넘지 않는지 확인하고 넘지 않으면 10을 더해주도록 수정했습니다!"*
+
+→ **Ace 보너스 +10 단일 적용 (PR #128·#114·#125·#108·#131·#132·#41·#49 와 같은 결의 정공 패턴)**.
+
+### 11. `Dealer.canGetCard <= 15` vs `>= 17` 불일치 (콘솔 출력 vs 코드)
+
+말리빈: *"딜러의 점수가 15이하 일 때만 카드를 받을 수 있네요 :) 콘솔엔 17이상 이라는 출력을 하고 있는데, 코드에서 사용하는 상수가 다르면 이후 디버깅할 때 어려울 것이 예상됩니다"*
+
+학생: *"17로 수정했습니다 :)"*
+
+→ **상수 vs 출력 메시지 일치성**. *디버깅 비용*. PR #131·#137 와 같은 결.
+
+### 12. `Consequence (승/패/무) 문자열` = View 의존
+
+말리빈: *"승 패 무 라는 문자열들은 도메인 영역 일지 고민해볼까요? 다른 비슷한 enum class가 또 있는 지 찾아볼까요?"*
+
+학생 자가 답변: *"CardNumber는 \"총 합계계산\" 이라는 도메인 로직에서 사용하기 때문에 필요하지만 Consequence, Shape 은 단순히 출력만을 위해 값을 가지고 있던 것 같습니다. 생각하지 못한 부분을 짚어주셔서 감사합니다🙃"*
+
+→ **enum UI value 안티패턴 (PR #75·#124·#28·#78·#112·#125·#128·#135·#137 와 같은 결)**.
+
+### 13. `Dealer 의 if-else 다중 분기` → when + 게임 용어
+
+말리빈: *"총점이 21점을 넘으면 어떤 상태인지, 등등의 게임 용어들이 있었지요 :) 해당 용어를 도메인 로직에 녹여내보는 것은 어떨까요? 세 번째 줄의 조건은 정말로 `블랙잭` 의 조건이 맞을까요? 또, if문이 많을 때는 when절을 활용해보세요"*
+
+→ **`Bust` / `Blackjack` 도메인 어휘 활용 + when 패턴 매칭**. PR #137·#148·#136 와 같은 결.
+
+### 14. `askGetCard + isSuccessAddCardToPlayer` 메서드 분리 — 학생 자가 학습
+
+학생 자가 인용: *"이 부분에 대해서 많이 고민해봤는데,, 카드를 추가할 수 있는지 여부는 위의 함수인 `askGetCard`에서 while문 내부에서 확인을 하고, `isSuccessAddCardToPlayer` 함수는 플레이어에게 카드를 받을지 물어보고 받는다면 카드를 주가하는, 그리고 카드를 추가하는데 성공하면 true를, 실패했다면 false를 반환하도록 하는 일을 하는데요, 이 전체 과정이 하나의 일이라고 볼 수는 없는 것인지 궁금합니다..🙃"*
+
+말리빈 답변: *"음! 말씀 대로 추가할 수 있는 지에 대한 여부는 player.canGetCard()로 묻고 있네요. 이 부분은 제가 잘못 말씀드렸어요 😥. 저는 플레이어가 카드를 받았는데, 그것에 대한 성공을 꼭 Boolean으로써 반환 해야 하는 지 의문이 들어요. 사실 InputView.getDecision(player)의 결과를 반환하는 것과 크게 다르지 않은 로직이라 생각합니다. 또, askGetCard 메서드를 봤을 때 수행하는 로직을 예측하기가 어렵다는 느낌을 많이 받았어요. **플레이어가 카드를 받을 수 있을 때 까지 반복문을 돌리고, 플레이어가 카드를 추가하는 데 성공했는데!... 갑자기 연재 종료된 웹툰이 된 느낌이랄까요?** 🤔"*
+
+→ **메서드 의도 모호 = 연재 종료된 웹툰 비유**. *호출자가 다음 동작 예측 불가 = 책임 분배 실패 신호*. 학생 + 말리빈 양방향 토론 모범.
+
+### 15. `RefereeTest` 명세 추상화 부족 — 자가 학습
+
+말리빈: *"합계 수치만 가지고는 게임의 룰을 정확하게 알기는 어려워보여요. `플레이어보다 딜러가 점수가 높으면 딜러가 승리한다` 같은 이름은 어떨까요?"*
+
+→ **테스트 함수명 = 룰 표현**. PR #137·#90·#136·#88 와 같은 결.
+
+## 리뷰어 의견 요지
+
+- **Boolean 반환 함수명 = is/has + 의미 명시** ("C 스타일 코드 느낌").
+- **카드 = 52개 고정 + 뽑는 순서가 랜덤** (현실 메타포 핵심).
+- **사이드 이펙트 = 외부 상태 변경 = 예측 불가 = 지양**.
+- **Set vs List = 도메인 변경 (여러 벌) 대비**.
+- **`Card.init require` = 외부 호출 검증 후 불필요 시 삭제**.
+- **`overCondition` 모호 → `canGetCard` 직관**.
+- **`Consequence` UI value = 도메인 누수**.
+- **블랙잭 도메인 어휘 + when 활용**.
+- **메서드 의도 명시 = "연재 종료된 웹툰 X" 비유**.
+- **테스트 = 룰 표현 + 추상화**.
+- **Card private constructor + 캐싱 + all() 활용 정공**.
+- **ACE 보너스 = 카드 목록 ACE 유무 검사 + 단일 +10**.
+- **상수 vs 출력 메시지 일치성 (디버깅 비용)**.
+
+## 대표 인용
+
+**말리빈 (현실 메타포 = 카드 자체 X, 뽑는 순서가 랜덤, CardDeck.kt):**
+> 현실 세계에서 카드를 뽑으면, 카드의 요소가 랜덤 처럼 보이지만, 사실은 뽑는 카드의 순서가 랜덤이지요
+> 이런 생각으로 정말로 랜덤이 필요한 곳은 어디인지에 대해 질문을 드렸어요 🙂
+> 크롱은 어떻게 생각하시나요?
+
+**말리빈 (메서드 의도 = 연재 종료된 웹툰 비유, Controller.kt:52):**
+> 또, askGetCard 메서드를 봤을 때 수행하는 로직을 예측하기가 어렵다는 느낌을 많이 받았어요.
+> 플레이어가 카드를 받을 수 있을 때 까지 반복문을 돌리고, 플레이어가 카드를 추가하는 데 성공했는데!... 갑자기 연재 종료된 웹툰이 된 느낌이랄까요? 🤔
+
+**말리빈 (사이드 이펙트 정의 + 위키 링크, Player.kt):**
+> 사이드 이팩트에 대한 정의는 [이 링크](https://en.wikipedia.org/wiki/Side_effect_(computer_science))를 참고해보세요!
+
+**말리빈 (CardNumber ACE 비교 = is ACE, CardNumber.kt):**
+> `점수를 계산하는 부분에서 상황에 맞게 처리하자`는 의견은 동의해요 :)
+> 하지만, CardNumber 내부 값이 null인지 아닌지 비교하기보다는, CardNumber 자체가 ACE인지 비교를 하면 된다고 생각해요 🙂
+
+**학생 자가 학습 (Card 52개 캐싱 + 뽑는 순서 랜덤, CardDeck.kt):**
+> 이번 리뷰를 받고 `Card`클래스에 미리 52개의 카드 인스턴스를 만들어두고 재사용 할 수 있도록 수정했습니다. 이렇게 되면 기존에 있던 모양과 숫자를 랜덤으로 생성하는 클래스들은 필요 없어진다고 생각이 들어 삭제하였고, `CardDeck` 클래스에서 카드를 뽑을 때 랜덤으로 동작하도록 수정했습니다.
+
+**학생 자가 학습 (사이드 이펙트 자가 정의, Player.kt):**
+> 이 메서드에서 발생시키는 사이드 이펙트는 Player 가 갖고 있는 승패에 대한 정보를 바꾸는 것을 의미하는 것으로 이해했는데 맞을까요?
+
+**학생 자가 학습 (Referee 자가 삭제 + Dealer 통합, Referee.kt):**
+> 사이드 이펙트를 발생시키지 않기 위해 Referee 클래스를 삭제하고 승자를 판단하는 로직을 다시 딜러에게 주었습니다! 딜러는 플레이어들의 리스트를 받아서 점수를 비교하고 최종 결과를 `Map<String, Consequence>`형태로 돌려주도록 하였습니다!
+
+**학생 자가 학습 (Consequence/Shape UI value 인식, Consequence.kt):**
+> CardNumber는 "총 합계계산" 이라는 도메인 로직에서 사용하기 때문에 필요하지만 Consequence, Shape 은 단순히 출력만을 위해 값을 가지고 있던 것 같습니다. 생각하지 못한 부분을 짚어주셔서 감사합니다🙃
+
+## 얻은 교훈
+
+1. ***카드 = 52개 고정 + 뽑는 순서가 랜덤*** = *현실 메타포 핵심*. *Card.all() 캐싱 + CardDeck 랜덤 추출*. **MCP 룰 후보 — `random-on-card-vs-order`** (현실 메타포). PR #146·#108·#133·#136·#74 와 같은 결.
+
+2. ***사이드 이펙트 = 외부 상태 변경 + 반환값 외 효과 = 예측 불가 = 지양***. *Player 가변 변경 → 결과 반환 패턴*. PR #85·#137·#148 와 같은 결.
+
+3. ***Referee 도입 → 사이드 이펙트 + Demeter 위반 → Dealer 통합 후퇴***. *현실 메타포 vs 도메인 정합 자가 학습 모범*. PR #74·#58·#147 와 같은 결.
+
+4. ***메서드 의도 = "연재 종료된 웹툰 X" 비유*** — 말리빈 명료 비유. *메서드 이름과 다른 책임 흡수 = 호출자 예측 실패*.
+
+5. ***`addCard` Boolean 반환 = C 스타일 = 의미 모호*** → *is/has 접두사 + 명시적 이름*. PR #124·#125·#114·#41 와 같은 결.
+
+6. ***`CardNumber.ACE` 비교 = `is ACE` 명시 > `value == null` 우회***. *enum 멤버 자체 비교*가 *Kotlin 어휘 정공*.
+
+7. ***Set vs List = 도메인 변경 (여러 벌) 대비***. *Set = 중복 차단 + 1벌 가정*. *List = 중복 가능 + N벌 가능성*. PR #67·#88·#90 와 같은 결.
+
+8. ***Card private constructor + all() 활용 = 외부 인스턴스 생성 차단***. PR #108·#133·#136·#137·#146·#74 와 같은 결.
+
+9. ***Ace 보너스 = ACE 유무 검사 + 단일 +10 (Ace 4장도 +10 한 번만)***. PR #128·#114·#125·#108·#131·#132·#41·#49 와 같은 결.
+
+10. ***상수 vs 출력 메시지 일치성 = 디버깅 비용***. *Dealer.16 코드 vs 17이상 메시지* 불일치 자가 반영. PR #131·#137 와 같은 결.
+
+11. ***Consequence (승/패/무) UI value = 도메인 누수***. *학생 자가 인식 모범*. PR #75·#124·#28·#78 와 같은 결.
+
+12. ***학생 krrong (이 PR 작성자) = PR #148·#151 의 reviewer 본인 = 메타 학습 케이스***. *학생 시절의 자가 학습이 reviewer 메타 질문 (역할 vs 상태 자가 학습, 반란군 비유) 으로 후속 누적*. *학습 곡선 메타 분석 가치*.
+
+13. ***`overCondition` 모호 → `canGetCard` 직관***. *Kotlin Boolean 어휘 = `canDraw()` / `canHit()`*. PR #75·#151·#41 와 같은 결.
+
+14. ***Effective Kotlin Item 4/14 자가 학습 (Inferred Type 반환 + 명확한 변수 타입)*** — PR #108·#137 와 같은 결.
+
+15. ***학생 자가 답변 깊이 + 자가 토론 풍부 + reviewer 답변 흡수 = 학습 가시화***. *Referee 자가 토론 + 사이드 이펙트 자가 정의 + CardDeck 랜덤 위치 자가 학습 + ACE null 자가 토론*. PR #146·#148·#151·#137·#41·#74 와 같은 결.

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

@@ -0,0 +1,285 @@
+# PR #46 — [블랙잭 2단계] 크롱 미션
+
+- **Reviewee:** [@krrong](https://github.com/krrong)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/46
+- **단계:** 2단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 29 스레드 — *학생 자가 학습 + 양방향 메타 토론 풍부 + *반영커밋* URL 첨부 패턴 모범*
+- **양 단계 분석 reviewee** (1단계 #32 별도). **메타 학습 케이스: krrong = 학생 (#32, #46) + reviewer (#148, #151)** 동시 등장.
+
+## 잘한 점 (설계 관점)
+
+- **모든 학생 답변에 *반영커밋 URL 첨부* 패턴** — 학생이 14회 코멘트 답변 중 11회에 *`[반영커밋](커밋URL)`* 명시 = *reviewer 가 *어떤 커밋이 어떤 권고를 반영*한 것인지 즉시 확인 가능*. **학습 가시화 매개체 모범** — PR #99 (s6m1n *PR URL 자가 참조*) / PR #128·#135·#108·#136 와 같은 결의 *학생 자가 학습 가시화 강화*.
+- **양방향 메타 토론 (Dealer → Player vs Dealer → Participant)** — 학생 자가 반박: *"리뷰를 보고 리팩토링 하기 전에 딜러가 player보다 Participant를 알게 해서 얻을 수 있는 이점이 무엇이 있을까 고민해봤습니다. (...) 하지만 그렇게 해서 얻는 이점도 있지만 잃게 되는 것들도 있다고 생각이 듭니다. (...) 때문에 플레이어를 알고 있을 때의 이점이 더 크다고 생각됩니다. 하지만 리뷰어님이 코멘트를 달아주신 이유가 있을 것이라고 생각되는데 혹시 여쭤봐도 괜찮을까요? 🙃"* + 말리빈 매우 긴 답변. **양방향 토론 모범** — PR #137·#151·#133·#146·#147 와 같은 결.
+- **Kotlin 어휘 자가 학습 풍부** — *`operator times` 오버로딩 자가 적용* / *`equals` & `hashCode` Alt+Insert 자가 단축키 학습* / *`return if ~` 표현식* / *`infix` 함수 자가 적용* / *`1_000` underscore 어휘* / *`object` (상태 없는 calculator)* / *backing property 자가 적용*. **Kotlin 어휘 자가 학습 모범** — PR #137·#148·#90·#146 의 *Kotlin 어휘 학습* 결.
+- **Card 캐싱 + `equals` 오버라이드 자가 학습** — 학생 자가 답변: *"저도 그 부분을 고민하고 있어서 일반 class로 변경하고 equals를 오버라이드 하는 방식으로 수정하였습니다!"*. *data class private constructor + Factory 함정 자가 진단 + class + equals 자가 정공* — PR #133·#136·#74 의 *Card private constructor + Factory* 결.
+- **Parameterized Test 자가 토론 + 콘솔 가독성 자가 의문** — 학생 자가 적용 + 자가 의문: *"이렇게 작성하고 테스트 코드를 실행했을 때 실행결과가 아래와 같이 나오기 때문에 가독성과 직관성이 떨어진다고 느껴지는데 리뷰어님은 어떻게 생각하시는지 여쭤보고 싶습니다! 🙃"* + 스크린샷 첨부 + 말리빈 답변: *"저는 사실 콘솔에 테스트 통과에 대해서는 잘 신경쓰지 않아요. 가끔은 성공한 것은 보이지도 않게 필터를 걸기도 합니다. 중요한 건 실패한 테스트라고 생각해요. (...) 어차피 콘솔에 어떻게 찍히든, 테스트 코드를 봐야 이해가 쉽기도 해요. 설명서의 역할이니까요 :)"*. **양방향 토론 + 스크린샷 증거 + reviewer 의 *테스트 명세서 어휘***. PR #99·#26 의 *테스트 명세서* 결.
+- **backing property + 외부 참조 누수 자가 학습** — 말리빈 도전: *"`mutableList.clear()` 어떤 일이 발생할 수 있을까요?"* + 학생: *"해당 코드를 실행시키면 카드덱이 가지고 있는 카드들도 삭제가 되는 것을 확인했습니다! backing property를 활용해서 CardDeck이 생성될 때 인자로 받은 리스트를 기반으로 다시 생성하여 가지도록 수정했습니다! 추가로 같은 일이 CardBunch에서도 발생하는 것으로 보여서 해당 코드도 수정하였습니다!"*. **외부 참조 누수 자가 진단 + 동일 패턴 다른 위치 자가 검사**. PR #74·#108·#132·#133·#85·#58·#137·#148 의 *방어적 복사* 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `BettingMoney * Int` 메서드 폭증 → `operator times` 오버로딩
+
+말리빈 진단: *"1~10000개의 곱셈이 생긴다면 1만 개의 메서드가 생겨야할까요? BettingMoney를 불변 객체로 만들어주셨으니, BettingMoney자체를 곱셈할 수 있게, multiply operator를 오버로딩 해보는 것을 도전해보세요 :)"*
+
+학생: *"`operator fun times(d: Double)` 을 사용해서 multiply operator를 오버로딩 해보았습니다!"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *극단 사례 메타 어휘 — "1만 개"*
+
+말리빈의 *"1~10000개의 곱셈이 생긴다면 1만 개의 메서드가 생겨야할까요?"* — **극단 사례 (reductio ad absurdum) 메타 어휘** = *현재 코드의 *한 사례 (× 2, × 3)* 가 *변경 요청 시 N 회 반복* 됨을 학생에게 자가 명시*. **MCP `oh-my-oop` 의 *변경 시 비용* 어휘**.
+
+#### 1.2. *Kotlin operator overloading 어휘*
+
+- *`operator fun times(d: Double): BettingMoney`* → *`BettingMoney(1000) * 4`* 표기.
+- *Java/일반 OO 어휘*: `multiply(int)` 메서드.
+- *Kotlin 의 *연산자 오버로딩* 어휘 = 도메인 객체에 *수학 연산* 명시*.
+
+#### 1.3. *불변 객체 + 새 객체 반환 정공*
+
+- *`times` 가 *새 BettingMoney 반환* = 불변성 유지.
+- *호출 측: `val newMoney = oldMoney * 2`*.
+
+### 2. `data class private primary constructor` 함정
+
+말리빈 진단: *"data class의 private primary constructor는 컴파일러가 경고하듯, 의미가 없습니다. class로 변경해보는 것은 어떨까요?"*
+
+학생: *"저도 그 부분을 고민하고 있어서 일반 class로 변경하고 equals를 오버라이드 하는 방식으로 수정하였습니다!"*
+
+→ **2 가지 함정 진단**:
+
+#### 2.1. *data class private constructor 함정*
+
+- *data class*: `equals`/`hashCode`/`toString`/`copy` 자동 생성.
+- *그러나 `copy()` = primary constructor 호출* — *primary 가 private 라도 `data.copy()` 는 외부에서 호출 가능 = private 우회*.
+- *컴파일러 경고*: *"Non-private primary constructor is exposed via the generated 'copy()' method of a 'data' class. The 'copy' will be made non-public in the future releases."*
+- **PR #58 (otter66) 의 *data class + private constructor copy 우회 함정* 결**. **MCP 룰 후보 — `dataclass-private-constructor-copy-leak`**.
+
+#### 2.2. *학생 자가 사전 진단 + 자가 정공 채택*
+
+학생의 *"저도 그 부분을 고민하고 있어서"* — **학생이 reviewer 권고 이전에 자가 인식**. *그러나 자가 결정 못해 일단 코드 작성 → reviewer 권고로 확정* 패턴. **학습 가시화 + 자가 결정 모범**.
+
+### 3. `Dealer 가 Player vs Participant` — 양방향 매우 긴 토론
+
+말리빈: *"딜러가 Player를 알기 보다, Participant를 알게 해보는 것은 어떨까요?"*
+
+학생 자가 반박 (3 단계 토론):
+
+> *"리뷰를 보고 리팩토링 하기 전에 딜러가 player보다 Participant를 알게 해서 얻을 수 있는 이점이 무엇이 있을까 고민해봤습니다. 제 생각은 나중에 어떤 클래스가 될지 모르지만 Participant를 구현한 다른 클래스가 오더라도(확장) 문제 없이 동작하기 위함이라고 생각됩니다."*
+>
+> *"하지만 그렇게 해서 얻는 이점도 있지만 잃게 되는 것들도 있다고 생각이 듭니다. 예를 들면 Calculator에서는 플레이어가 가지고 있는 베팅 금액과 승/패 여부를 가지고 받는 배당금을 계산하는 로직이 있는데요, 딜러가 Participant를 알도록 하면 플레이어만이 가지면 되는 배팅금액을 인터페이스까지 끌어올려야 하고, 자연스럽게 배팅금액을 가지고 있지 않아도 되는 딜러까지 배팅금액을 가지게 된다고 생각합니다."*
+>
+> *"때문에 플레이어를 알고 있을 때의 이점이 더 크다고 생각됩니다. 하지만 리뷰어님이 코멘트를 달아주신 이유가 있을 것이라고 생각되는데 혹시 여쭤봐도 괜찮을까요? 🙃"*
+
+말리빈 매우 긴 답변:
+
+> *"크롱이 말씀해주신 것 처럼, 확장의 이점도 있고, 의존 관계에 대한 이점도 가져올 수 있다고 생각했어요 :) 플레이어나 딜러는 Participant 의 하위 클래스인데, 딜러가 Player 대신 Participant를 알게 되면 하위 구현체끼리의 의존 관계를 잘라낼 수 있어 이점이 있다고 생각했어요 🙂*
+>
+> *제가 조금 이해가 어려운 것은, [학생 반박 인용] 이 부분인데요, 위 내용은 Calculator가 Participant를 알게 되면 갖게 되는 문제로 보입니다.*
+>
+> *Calculator는 이미 Dealer와는 영향이 전혀 없이, Player와 Consequence만을 가지고 금액을 결정하게 되는데요, getPlayerConsequence 이 메서드에서는 Participant에서 갖고 있는 메서들로만 Consequence를 계산해내고 있어 보여요. 이곳에서 Player의 베팅금액을 참조하고 있었다면 이야기가 달라지겠지요 🙂 그렇기에 배팅 금액을 Participant interface까지 끌어올려야 하지 않아도 된다고 생각이 듭니다.*
+>
+> *제가 크롱의 의도를 잘못 파악했을까요 ?_? 제가 이해하지 못한 내용이 있을 수 있으니, 곰곰이 생각해보시고 다시 이야기 나누어요 😊 슬랙 DM도 좋고, 코멘트도 좋습니다~"*
+
+→ **5 가지 메타 학습**:
+
+#### 3.1. *학생 자가 *3 단계 토론*: 자가 분석 + 자가 반박 + reviewer 의도 질문*
+
+1. *자가 분석*: *"이점이 무엇일까 고민"*.
+2. *자가 반박*: *"잃게 되는 것들도 있다"*.
+3. *reviewer 의도 질문*: *"리뷰어님이 코멘트를 달아주신 이유가 있을 것이라고 생각되는데 혹시 여쭤봐도 괜찮을까요?"*.
+
+**3 단계 학생 자가 토론 모범** — PR #137·#151·#133·#146 결.
+
+#### 3.2. *Dealer → Player 의존 vs Dealer → Participant 의존*
+
+- *Dealer → Player* (학생 코드) = *형제 구현체 간 직접 의존*. *Dealer 와 Player 가 같은 부모 (Participant) 를 가짐에도 형제끼리 의존*.
+- *Dealer → Participant* (말리빈) = *Dealer 는 *추상 부모만 알면 충분***. *Player 는 Dealer 와 무관 + Dealer 는 *Participant 메시지만 사용*. **DIP (Dependency Inversion Principle)**.
+
+PR #95 (송핑크 *Dealer extends Player?*) / PR #23 (멘델 *점수 책임 위치 3 후보*) / PR #148·#151·#49·#132 의 *참가자 vs 참가자 일반화* 결.
+
+#### 3.3. *Calculator 가 Player 의존 vs Participant 의존*
+
+말리빈의 *"위 내용은 Calculator가 Participant를 알게 되면 갖게 되는 문제로 보입니다"* — *학생의 반박이 *다른 의존* (Calculator → Participant) 의 문제 였음 자가 진단*. **reviewer 가 *학생 의도를 다시 명확화* 모범**.
+
+#### 3.4. *reviewer 자가 의도 의문 — "제가 크롱의 의도를 잘못 파악했을까요 ?_?"*
+
+말리빈의 *"제가 크롱의 의도를 잘못 파악했을까요 ?_? 제가 이해하지 못한 내용이 있을 수 있으니, 곰곰이 생각해보시고 다시 이야기 나누어요"* — **reviewer 자가 한계 인정 + 양방향 토론 권유**. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) / PR #137 (지훈 *어휘 혼란 자가 인정*) 결.
+
+#### 3.5. *PR 코멘트 외부 채널 권유 (Slack DM)*
+
+말리빈의 *"슬랙 DM도 좋고, 코멘트도 좋습니다~"* — **PR 외부 채널 권유 = 깊은 토론 가능성 인정**. PR #99 (KwonDae *DM 권유*) 결.
+
+### 4. `BettingMoney 곱셈 → BettingMoney 반환 vs Int` 자가 토론
+
+말리빈: *"곱셈을 수행하면, BettingMoney가 반환되도록 도전해보세요 :)"*
+
+학생 자가 반박: *"저도 해당 부분을 BettingMoney가 반환되도록 하려고 했었습니다! 하지만 BettingMoney에는 0이하의 값이 들어갈 수 없도록 만들어두었기 때문에 이익을 계산할 수 없다고 판단해서 위와 같이 작성했었습니다. 최종 수익을 계산해서 반환하던, 게임의 결과로 받는 배당금을 반환하던 0 혹은 음수의 값이 들어갈 수 밖에 없다고 생각이 됩니다. 리뷰어님은 어떻게 생각하시나요?!"*
+
+말리빈: *"BettingMoney에는 음수가 들어가서는 안되니, 수익률은 BettingMoney로 취급하지 않겠다는 의미겠지요! 그렇담, minusFrom은 없어도 괜찮겠다고 생각해요. 수익률을 계산하는 곳에서 BettingMoney의 value를 꺼내는 것도 괜찮다고 생각해요 :)"*
+
+→ **2 가지 학습**:
+
+#### 4.1. *불변 객체 invariant + 산술 연산 결과 타입*
+
+- *`BettingMoney` invariant: ≥ 1* (베팅은 양수).
+- *수익률 = *음수 가능* (손실)*.
+- *동일 타입 (BettingMoney) 으로 표현 시* = *invariant 위반 위험 + 의미 누수*.
+- **수익률 ≠ 베팅 머니** — *별도 타입 (예: `Profit`) 또는 *원시 Int 사용*.
+
+#### 4.2. *학생 자가 의문 + reviewer 답변 후 *trade-off 인정***
+
+말리빈의 *"수익률을 계산하는 곳에서 BettingMoney의 value를 꺼내는 것도 괜찮다고 생각해요"* — *value 노출 (Tell-Don't-Ask 위반) 도 *맥락에 따라 OK***. PR #95 (말리빈 *"옳고 그름 없고 장단점만"*) 결.
+
+PR #133·#88·#132·#136·#93 의 *3 변수 제약 부산물 인공 객체* / PR #131 (moondev03 *`-0.0` Double IEEE 754 함정 우회*) 결의 *값 객체 invariant + 산술*.
+
+### 5. `52장 vs 53번 뽑기 = 도메인 룰 (덱 리필)`
+
+말리빈: *"블랙잭 게임을 하다보면 덱을 다시 채워야할 수도 있고, 한 게임은 여러 벌의 카드로 진행을 하는 요구사항이 생길 수도 있어요. 정말 53번 뽑으면 오류가 발생해야할까요?"*
+
+학생: *"하나의 덱으로 게임을 한다는 것은 52장의 카드로 게임을 진행한다고 것이고 카드가 52장만 있을 때 53번을 뽑았을 때 오류가 발생하는지(== 덱에 카드가 하나도 없을 때 뽑으면 오류가 발생) 확인하려고 했었습니다!"*
+
+말리빈 후속: *"52장을 다 사용햇더라도 게임을 진행할 수 있게 프로그램을 만들어보길 도전해보시면 좋겠네요! 😊"*
+
+→ **카지노 6덱 메타포 + 덱 리필**. PR #58 (otter66 *카지노 6덱 메타포*) / PR #74·#108·#133·#136·#41 의 *카드 부족 시 게임 종료 UX* / PR #23·#26 의 *카드덱 자료구조* 결.
+
+### 6. `cardDeck.drawCard()` 두 번 호출 → 한 메서드 2장 반환
+
+말리빈: *"cardDeck.drawCard()를 두 번 호출하고 있네요 :) 한 메서드가 2장을 반환하게 만들어보는 것은 어떨까요?"*
+
+말리빈 별도 권고: *"이후 3, 4, ... 100장을 가져오는 기능이 생긴다면 100개의 메서드를 작성해야합니다. `drawCards(...) : List<Card>` 재활용가능하게 만들어보는 것은 어떨까요?"*
+
+→ **N 회 호출 < 가변 인자 메서드**:
+- *`drawCard()` × 2* (호출자 책임) < *`drawCards(2)`* (도메인 책임).
+- *학생 자가 답변*: *"컨트롤러에 필요 하지 않은 코드였던 것 같아요!"* = *Controller god-object 자가 인정*.
+
+PR #99 (s6m1n *Controller god-object*) / PR #43 (chws0508 *BlackJack.runGame*) 결.
+
+### 7. `Calculator` 상태 없음 → `object`
+
+말리빈: *"calculator가 내부에 상태를 지니지 않으니, object로 만들어도 좋겠어요 :)"*
+
+→ **Kotlin `object` 어휘 = 싱글톤** + *상태 없는 헬퍼*.
+
+- *`class Calculator`* + *상태 없음* = *매번 인스턴스 생성 비용 + 의미 없음*.
+- *`object Calculator`* = *단일 인스턴스 + 함수형 호출 (`Calculator.calculate(...)`)*.
+
+PR #70 (chaehyuns 1단계 *ShuffleCardMachine + CardMachineManager = object 자가 학습*) 결.
+
+### 8. `initialCards` 멤버 필요?
+
+말리빈: *"initialCards는 멤버일 필요가 있을까요?"*
+
+→ **메서드 지역 변수 vs 클래스 멤버 변수**:
+- *멤버 변수 = 객체 생애 동안 유지 + 외부 노출 가능성*.
+- *지역 변수 = 메서드 호출 동안만 + 캡슐화*.
+- *`initialCards` 가 생성자에서만 사용 + 이후 미사용* = *지역 변수 / `init { ... }` 블록 정공*.
+
+**MCP 룰 후보 — `unnecessary-member-variable`** = *멤버 변수 = 필요한 경우만*.
+
+### 9. `카드들의총합가져오기` 메서드명 — 라면 비유
+
+말리빈: *"`카드들의총합가져오기` 보다는, `총점가져오기` 같은 이름 짓기는 어떨까요? 아래 이름을 비교해보아요 :) `냄비에물을500미리붓고100도씨까지온도를올린뒤스프를뿌리고면을넣고3분을기다리기` vs `라면끓이기`"*
+
+→ **추상화 수준 일치 + 의도 명시**:
+- *긴 절차 명 = 구현 상세 노출 + 변경 시 명명도 변경*.
+- *짧은 의도 명 = 행동 추상화 + 호출자 친화*.
+- **MCP 룰 후보 — `procedural-method-name`** = *구현 상세 명명 vs 의도 명명*.
+
+PR #146 (yrsel) / PR #99·#26 의 *명명 의문* 결.
+
+### 10. `에러 메시지에 입력값 포함` (PR #39 결)
+
+말리빈: *"Exception에 어떤 문제였는 지 에러 메시지를 담아보는 것은 어떨까요?"*
+
+말리빈 별도: *"어떤 에러 메시지가 나왔는지도 검증해볼까요? 🙂"*
+
+말리빈 또 별도: *"어떤 에러 메시지가 나타났는지도 검증해보세요 :)"*
+
+→ **에러 메시지 = *입력값 + 사용자 친화도 + 디버깅 친화도***. PR #39 (rhthrhrl0) 결.
+
+### 11. `숫자 1_000 underscore` Kotlin 어휘
+
+말리빈: *"숫자를 나타낼 때에는 `1_000` 이렇게도 나타낼 수 있답니다! 숫자가 `100000`만 되어도 읽기가 어려워서, `100_000` 라고 나타내주면 쉽게 읽을 수 있어요 :)"*
+
+→ **Kotlin literal underscore**. 가독성 명시 + 도메인 단위 (천/만) 시각화.
+
+### 12. `테스트 = 2장 들어있음 < 예상 카드 들어있음`
+
+말리빈: *"2장이 들어있음만을 검증하기 보다는, 실제로 예상한 카드가 들어있는 지 검증해보세요 :)"*
+
+→ **테스트 품질 = 결정적 + 검증 가능한 최소**. PR #23·#26·#39 의 *갯수만 검증 무의미* 결.
+
+### 13. `21점` ≠ `블랙잭` — 블랙잭 룰 정확성
+
+말리빈: *"21점이어야만 이 테스트 상황이 만들어지는 것은 아닙니다. `블랙잭`과 `총합21점`은 서로 다르다는 점을 유의해주세요 :)"*
+
+→ **블랙잭 룰 정확성** = *2장 21점 (BlackJack) ≠ 3장 이상 21점 (Twenty-One)*. PR #26 (잭슨 *BlackJack 21점 > 3장 이상 21점*) 결. **MCP 룰 후보 `blackjack-rule-fidelity`**.
+
+### 14. `52장 다 사용 후 게임 진행` — 도전 권유
+
+말리빈 머지 시점: *"52장을 다 사용햇더라도 게임을 진행할 수 있게 프로그램을 만들어보길 도전해보시면 좋겠네요! 😊"*
+
+→ **도전 권유 = 학습 시드**. PR #98·#99·#95 의 *재구현 권유* 결.
+
+## 리뷰어 의견 요지 (말리빈 / malibinYun)
+
+29 코멘트 특징 (PR #23·#39·#74·#95 와 동일 reviewer):
+
+- **메타 질문 + 극단 사례** — *"1만 개의 메서드가 생겨야할까요?"* (BettingMoney), *"100개의 메서드를 작성해야합니다"* (drawCards) — **극단 사례 (reductio ad absurdum) 메타 어휘**. PR #23·#39 결.
+- **양방향 토론 + 자가 한계 인정** — *"제가 크롱의 의도를 잘못 파악했을까요 ?_?"* — **reviewer 자가 한계 인정**. PR #95·#137·#147·#151 결.
+- **외부 채널 권유 (Slack DM)** — *"슬랙 DM도 좋고, 코멘트도 좋습니다~"*. PR #99 (KwonDae) 결.
+- **라면 비유** — *"`냄비에물을500미리붓고...` vs `라면끓이기`"* — **추상화 수준 시각화 메타 어휘**. PR #151 (크롱 *반란군 비유*) / PR #146 (두루 *YAGNI 비유*) 결.
+- **suggestion 블록 없음** — PR #26·#39·#43 의 *suggestion 첨부* 와 차이.
+- **머지 시점 도전 권유** — *"52장을 다 사용햇더라도 게임을 진행할 수 있게 프로그램을 만들어보길 도전해보시면 좋겠네요!"*. PR #98·#99·#95 결.
+
+## 학생/Reviewer 메타 학습 케이스 — krrong
+
+**krrong = 학생 (#32 1단계, #46 2단계) + reviewer (#148 etama 2단계, #151 jerry 2단계)** 동시 등장.
+
+PR #46 학생 시기 (2023년 3월): *학생 자가 학습 + 양방향 토론 + 반영커밋 URL 첨부 + 3 단계 자가 토론*.
+
+PR #148·#151 reviewer 시기 (2024년 3월, 약 1년 후): *역할 vs 상태 자가 학습 + 참가자 vs 참가자 일반화 + 반란군 비유 + 학생 자가 토론 권유 + 머지 시점 학습 진화 인정*.
+
+→ **1 년 학생 → reviewer 진화 케이스**. *학생 시기의 학습 패턴 (자가 토론 + 양방향 + 반영커밋 URL)* 이 *reviewer 시기에 *학생에게 같은 패턴 권유* 로 진화*. **MCP `oh-my-oop` 의 *학습 = 시간 두고 반복* 어휘와 일치**. PR #95·#98·#99 의 *재구현 권유* 결.
+
+## 대표 인용
+
+> *"하지만 그렇게 해서 얻는 이점도 있지만 잃게 되는 것들도 있다고 생각이 듭니다. (...) 때문에 플레이어를 알고 있을 때의 이점이 더 크다고 생각됩니다. 하지만 리뷰어님이 코멘트를 달아주신 이유가 있을 것이라고 생각되는데 혹시 여쭤봐도 괜찮을까요? 🙃"* — krrong (3 단계 학생 자가 토론 모범)
+
+> *"제가 크롱의 의도를 잘못 파악했을까요 ?_? 제가 이해하지 못한 내용이 있을 수 있으니, 곰곰이 생각해보시고 다시 이야기 나누어요 😊 슬랙 DM도 좋고, 코멘트도 좋습니다~"* — malibinYun (reviewer 자가 한계 인정 + 양방향 토론 권유)
+
+> *"`냄비에물을500미리붓고100도씨까지온도를올린뒤스프를뿌리고면을넣고3분을기다리기` vs `라면끓이기`"* — malibinYun (추상화 수준 라면 비유)
+
+> *"이렇게 작성하고 테스트 코드를 실행했을 때 실행결과가 아래와 같이 나오기 때문에 가독성과 직관성이 떨어진다고 느껴지는데 리뷰어님은 어떻게 생각하시는지 여쭤보고 싶습니다! 🙃"* — krrong (Parameterized Test 자가 의문 + 스크린샷 첨부)
+
+> *"저는 사실 콘솔에 테스트 통과에 대해서는 잘 신경쓰지 않아요. 가끔은 성공한 것은 보이지도 않게 필터를 걸기도 합니다. 중요한 건 실패한 테스트라고 생각해요."* — malibinYun (테스트 명세서 어휘)
+
+> *"저도 해당 부분을 BettingMoney가 반환되도록 하려고 했었습니다! 하지만 BettingMoney에는 0이하의 값이 들어갈 수 없도록 만들어두었기 때문에 이익을 계산할 수 없다고 판단해서 위와 같이 작성했었습니다. (...) 리뷰어님은 어떻게 생각하시나요?!"* — krrong (불변 객체 invariant + 산술 연산 자가 의문)
+
+## 얻은 교훈
+
+1. **`extends 자식 → Player` vs `extends 자식 → Participant` 의존 방향** — *형제 구현체 의존 < 추상 부모 의존 (DIP)*. *Dealer → Player = 형제 직접 의존* / *Dealer → Participant = 추상 의존 + 형제 의존 차단*. PR #95·#23·#148·#151·#49·#132 결.
+
+2. **`data class private constructor + copy() 우회 함정`** — *컴파일러 경고 명시 + `copy()` 가 primary constructor 우회*. PR #58 (otter66 *data class + private constructor copy 우회*) / PR #74·#108·#133·#136 의 *Card private constructor + Factory* 결. **MCP 룰 후보 `dataclass-private-constructor-copy-leak`**.
+
+3. **`operator overloading` Kotlin 어휘 = *수학 연산 도메인 명시*** — *`BettingMoney * 4`* / *`Score > 21`* / *`State.compareTo`* — *도메인 객체에 수학/비교 연산 = Kotlin 어휘*. PR #93·#136·#152·#39 결.
+
+4. **`불변 객체 invariant + 산술 연산 결과 타입`** — *`BettingMoney ≥ 1` invariant + 수익률 (음수 가능) → 별도 타입 (Profit) 또는 원시 Int*. **MCP 룰 후보 `value-object-arithmetic-invariant-leak`**.
+
+5. **3 단계 학생 자가 토론** — *자가 분석 + 자가 반박 + reviewer 의도 질문*. **학생 자가 학습 가시화 모범**. PR #137·#151·#133·#146·#23 결.
+
+6. **reviewer 자가 한계 인정 + 양방향 토론** — *"제가 의도를 잘못 파악했을까요?"* — *reviewer 가 *학생 의도* 를 *잘못 해석 가능성* 명시*. PR #95·#147·#137·#151 결.
+
+7. **반영커밋 URL 첨부 패턴** — *학생이 *어떤 권고를 어떤 커밋에서 반영* 명시*. **학습 가시화 매개체 + reviewer 친화도**. PR #99 (PR URL) / PR #128·#135·#108·#136 결.
+
+8. **라면 비유 (추상화 수준)** — *긴 절차 명 vs 짧은 의도 명*. **MCP 룰 후보 `procedural-method-name`**. PR #151·#146 의 *비유 어휘* 결.
+
+9. **극단 사례 메타 어휘 (reductio ad absurdum)** — *"1만 개의 메서드가 생겨야할까요?"* / *"100개의 메서드"* — *현재 코드의 *한 사례* 가 *변경 시 N 회 반복* 자가 명시*. **MCP `oh-my-oop` 의 *변경 시 비용* 어휘**.
+
+10. **`testing = 명세서` 어휘 (Parameterized Test 학생 자가 의문 후)** — *"콘솔 통과 X, 테스트 코드는 설명서"* — PR #99·#26 (테스트 명세서) 결.
+
+11. **외부 참조 누수 + backing property 자가 학습** — *`mutableList` 외부 보유 + `clear()` → 내부 누수*. *backing property + 재생성 정공*. PR #74·#108·#132·#133·#85·#58·#137·#148 결.
+
+12. **krrong 1 년 학생 → reviewer 진화 케이스** — *2023년 3월 학생 시기의 학습 패턴 (자가 토론 + 양방향 + 반영커밋 URL) → 2024년 3월 reviewer 시기의 학생 권유*. **MCP `oh-my-oop` 의 *학습 = 시간 두고 반복* 어휘와 일치**. 학생/reviewer 동시 등장 메타 케이스. PR #98·#95·#99 의 *재구현 권유* 결.