oh-my-oop 0.2.0

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

@@ -0,0 +1,238 @@
+# PR #74 — [블랙잭 1단계] 알송 미션
+
+- **Reviewee:** [@songpink](https://github.com/songpink)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/74
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 29 스레드 / 학생 자가 학습 풍부 — *불변 vs 가변, Delegate vs 일급컬렉션, abstract vs open, 도메인 모르는 개발자 시나리오*
+
+## 잘한 점 (설계 관점)
+
+- **Delegate 일급 컬렉션 자가 학습 + 트레이드오프** — 학생 자가 답변: *"직접 구현하는 것에 비해 delegate를 사용할 경우 래핑되는 인터페이스의 메서드를 Deck의 인스턴스에서 바로 사용할 수 있다는 점이 편리하다고 생각했습니다. 사실 이번 블랙잭 미션에서 사용되지는 않는 기능인데, 수업에서 배운 기능이라 연습겸 써보았습니다."*. 말리빈 답변: *"연습으로 사용해본 것은 정말 잘 해주셨어요👍 ... 저는 일급 컬렉션에 delegate 활용을 선호하지 않아요. 이 이유에 대해 한 번 고민해보세요"*. 학생 자가 답변: *"위임하지 말아야 할 메서드들도 위임하기 때문일까요?"* + 말리빈 인정: *"Delegate를 활용한다면, 일급 컬렉션이 필요 이상으로 기능들을 노출시킨다고 생각해요"*. **Kotlin Delegate vs 일급 컬렉션 트레이드오프 자가 학습 모범**.
+- **불변 객체 자가 학습 + 자가 인식** — 학생 자가 답변 인용: *"먼저 제가 불변객체에 대해 잘못 알고 있었군요! 외부에서만 바꾸지 못하면 불변객체라고 생각했는데 내부에서도 변경이 불가능해야 불변객체이군요. 알려주셔서 감사합니다😄"*. **불변 객체 정의 자가 학습 모범**. PR #85·#137·#148 와 같은 결.
+- **GameResult → Referee → Dealer 책임 자가 토론** — 학생 자가 답변: *"최초 구상은 GameResult를 블랙잭 게임의 심판 역할을 하는 객체로 설계하는 것이었는데요, 굳이 심판을 둔 이유는 카드의 수를 비교하는 행동은 딜러와 플레이어 둘 사이에서 카드를 상호 확인하고 그에 따른 승패를 서로 동의하는 것이라고 생각했기 때문에, 딜러나 플레이어 둘 중 한쪽이 승패를 결정하는 것이 아니라 승패를 판정하는 심판이 저의 소프트웨어 세계에서는 필요하다고 생각했기 때문입니다."* — *현실 메타포 자가 정당화 + 코드 적용 후 변경*. 말리빈: *"둘 다 구현해보고 비교해보셔도 좋겠어요 :) 다만, 현실세계의 블랙잭 게임에서는 정말 \"심판\"이 따로 있는지 고민해보시면 좋겠네요!"*. 학생 자가 결정: *"둘다 구현해보고 비교해본 결과 굳이 심판이 필요하지는 않겠다는 생각이 듭니다! 판정 책임을 딜러에게 넘기니 코드량이 줄어들더라구요"*. **현실 메타포 vs 도메인 정합 자가 학습 모범**.
+- **카지노 무한 게임 메타포 자가 학습** — 말리빈 진단 *"한창 진행중이고 특정 플레이어는 블랙잭을 가져서 기뻐하고있었는데, 모든 카드 덱의 소모로 갑자기 게임이 결과 없이 끝나버린다면, 사용자에게 좋은 경험일지 고민해보시면 좋겠어요!"* + 학생: *"덱을 리필해서 참가자들에게 나눠주어야 겠습니다."*. PR #108·#133·#136·#41 와 같은 결.
+- **`Card` 캐싱 + Factory 자가 반영** — 말리빈: *"카드를 사용하는 경우는 얼마나 될까요? 동일한 값을 가지는 인스턴스를 재활용 해 볼 수 있을까요?"* + 학생: *"팩토리함수를 통해 카드들을 캐싱하고 재활용 할 수 있게 했습니다!"* + 후속: *"카드 인스턴스를 재활용할 수 있게 캐싱해주셨지만, 여전히 다른 개발자들은 같은 값을 지닌 다른 인스턴스를 생성할 수 있겠어요. 늘 똑같은 인스턴스만을 사용할 수 있도록 제한해보는 건 어떨까요?"*. PR #108·#133·#136 와 같은 결.
+- **Rank 의 보너스 점수 = 로직으로 표현 자가 반영** — 말리빈 진단 *"ACE 하나 때문에 보너스 점수라는 것을 enum 모두가 알고 있는 것이 적절할까요? 보너스 점수는 로직으로 표현해보는 건 어떨까요?"* + 학생: *"포인트 계산 로직이 보너스번호를 갖고 있도록 수정했습니다."*. **enum 부가속성 vs 로직 분리 자가 학습**.
+- **abstract vs open vs interface 자가 학습** — 말리빈 진단 *"이 클래스는 abstract로 선언되어있는데 abstract의 요소가 전혀 없네요. abstract class와 interface의 차이는 무엇일까요?"* + 학생 자가 답변 깊음 (abstract = 다중상속 X + 백킹필드 + 구현 메서드 vs interface = 다중구현 + 동일 동작 보장) + 결론: *"본 블랙잭 게임에서는 '참여자'라는 추상적인 개념을 '딜러'와 '플레이어'로 구체화해 사용하고 있기 때문에 abstract class를 쓰는 것이 더 적합하다고 생각합니다. Participant의 행위를 딜러와 플레이어가 더욱 구체화하도록 수정하겠습니다!"* + 말리빈 답변: *"abstract class는 가끔 고장난 클래스라는 별명이 있답니다. 빵꾸를 뚫어 고장내놓고, 사용자가 상속받아 사용할 때, 고장낸 부분을 사용자가 구현해야만 할 수 있게 만드는 것이지요. 그런 abstract 메서드들이 없어서 abstract 키워드를 사용한 게 어색했어요. open class 같은 \"open\" 키워드에 대해 알아보셔도 좋겠어요"*. **MCP 룰 후보 — `abstract-without-abstract-method`** (말리빈/페로로/두루 공통 진단). PR #108·#133·#137·#147 와 같은 결.
+- **양방향 의존 자가 해소** — 말리빈 진단 *"Deck과 Card가 양방향 의존성을 지니게 되었네요! 양방향 의존성은 무엇일까요? 어떤 문제점이 생길 수 있을까요?"* + 학생 자가 답변: *"두 객체가 서로 의존하고 서로 필요로 하고 있는 상황이군요.. 꼼꼼하지 못했습니다. 수정했습니다! 양방향 의존을 하게 될 경우 두 객체 사이의 결합도가 너무 높아져 한 객체의 변경이 다른 객체에 큰 영향을 미치게 됩니다."*. PR #93 와 같은 결의 *bidirectional-dependency*.
+- **방어적 복사 자가 반영** — 말리빈 진단 *"외부에서 Deck의 값을 변경해버릴 수 있는 문제가 있군요.. 방어적복사를 사용해 외부에서 값을 변경할 수 없도록 수정했습니다!"*. PR #108·#132·#133·#85·#58·#137·#148 와 같은 결.
+- **추상 클래스 + Participant 통합** — 말리빈: *"딜러와 플레이어는 공통의 역할을 가지고 있네요!"* + 학생: *"추상클래스 Participant를 이용해 공통 로직을 묶어주었습니다!"*. PR #49·#108·#133·#132·#136 와 같은 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `gradle 수정` vs *근본 원인 해결*
+
+말리빈 진단 (build.gradle.kts): *"어떤 이유에서 이 설정이 필요하셨나요 ?_?"* + 학생 자가 답변: *"사실 다른 크루가 넣었던 코드를 생각 없이 따라 작성한 코드였습니다.."* + 말리빈: *"PC의 타겟 버전을 고쳐보는 것도 좋은 경험이 될 수 있겠어요! gradle 수정 보다는 근본적인 원인을 먼저 고쳐보셔도 좋겠어요"*.
+
+→ **근본 원인 해결 vs 우회 = 학습 가치**. *복사 코드 + 이해 없음 = 함정*. **MCP 룰 후보 — `copy-paste-without-understanding`** (Kotlin 어휘 학습).
+
+### 2. `JvmStatic` 자가 학습 + 필요성 검증
+
+말리빈: *"`@JvmStatic` 을 작성하신 이유가 궁금해요 :)"* + 학생: *"사실은 페어의 의견이었는데요, 자바와의 상호운용성과 확장성을 위해 작성했습니다. 필요가 없다면 삭제하도록 하겠습니다."* + 말리빈: *"`@JvmStatic`에 대해 정확히 알고 계신 것 같네요 :) \"필요가 없음\"에 대해서는 알송이 판단해주시면 좋겠어요!"*
+
+→ **`@JvmStatic` = Java interop = 순수 Kotlin 시 불필요**. *PR #58 (수달) 의 @JvmField* 와 같은 결.
+
+### 3. `26명 플레이어 시 게임 종료?` — 카드 부족 시나리오
+
+말리빈: *"26명의 플레이어가 모두 카드를 2장씩 나눠가진 상태라면, 게임이 종료되어야할까요?"* + 학생: *"카드를 모두 소모하게 되면 게임이 그대로 종료되어야 할 것 같습니다."* + 말리빈 후속: *"한창 진행중이고 특정 플레이어는 블랙잭을 가져서 기뻐하고있었는데, 모든 카드 덱의 소모로 갑자기 게임이 결과 없이 끝나버린다면, 사용자에게 좋은 경험일지 고민해보시면 좋겠어요!"*
+
+→ **UX + 도메인 룰**. 학생 후속 반영. PR #108·#133·#136·#41 와 같은 결.
+
+### 4. `Deck.Companion @JvmStatic` 부생성자 권고
+
+말리빈: *"부생성자를 활용해보는 건 어떨까요?"*
+
+→ Kotlin 어휘 = secondary constructor. *factory function vs 부생성자 트레이드오프*.
+
+### 5. `ParticipantsHandCards.cards.size < 2 도 정상 작동` — *도메인 모르는 개발자 시나리오 (말리빈 명진단)*
+
+학생 자가 답변: *"최초 분배되는 카드의 개수가 2개이고 최소한 딜러 한명에게 카드 2장이 주어지기 때문에 cards가 2미만이 될 경우는 없다고 생각했습니다. 혹시 이 생각이 잘못된 것일까요?"*
+
+말리빈 답변 핵심: *"\"현 로직\" 상에서는 문제가 없겠지요! 다른 개발자가 리팩터링이나 기능 추가를 해야할 때, 블랙잭 게임에 대한 모든 룰과 제약조건에 대해 정확히 알고 있을까요? \"도메인을 모르는 데 어떻게 개발에 투입되냐?\" 라는 생각이 들 수도 있겠지만, 그렇게 된다면 현실적으로 주니어 개발자는 취업을 할 수 없겠지요.."*
+
+→ **도메인 모르는 개발자 시나리오 = 명시적 invariant 강제 정공**. *require + 상수화*가 *다른 개발자 안전망*. **MCP 룰 후보 — `implicit-invariant-on-known-rule`**. PR #137·#88 와 같은 결.
+
+### 6. `Player MutableList<Card>` 직접 보유 + 백킹 프로퍼티 + 안정성 트레이드오프 학생 자가 토론
+
+학생 자가 답변 (Player MutableList vs HandCards): *"플레이어의 손패는 Player객체의 프로퍼티로 가지고 있는 것이 자연스러운데, 손패는 계속 추가되는 것이기 때문에 MutableList타입을 가져야 했습니다. 그런데 MutableList는 외부에서 수정이 가능하기 때문에 이를 방지하기 위해 백킹 프로퍼티를 사용했습니다. HandCards의 cards를 MutableList로 바꾸고 플레이어가 HandCards를 직접 가지게 한다면 구조는 간단해 지겠지만 안정성이 떨어질 것 같습니다."*
+
+말리빈 답변: *"Player가 MutableList를 가지는 것과, HandCards가 MutableList를 가지는 게 얼마나 큰 차이가 있는 지 잘 모르겠네요. 위치만 조금 바뀌었을 뿐, Player가 MutableList를 가지는 것에 \"비해서\" HandCards가 MutableList를 가지는 것이 안정성이 떨어진다는 의견은 동의하기 어렵네요."*
+
+학생 후속: *"아..! 확실히 그렇네요!"*
+
+→ **위치만 변경 ≠ 안정성 차이**. *책임 응집 (HandCards 가 자기 카드 관리)* + *Player.handCards = val*. **자가 학습 모범**.
+
+### 7. `hit(card) = handCards.plus(card)` 함수형 plus 활용 자가 학습
+
+말리빈 권고: *"`handCards = handCards.plus(card)`"* + 학생: *"제안주신 plus함수를 사용하면 MutableList를 사용하지 않아도 손패를 추가할 수가 있겠군요! 그런데 대신 val이 아니라 var로 수정해야 하는데, 이 때문에 결국 가변객체의 상태가 아닌가 하는 생각이 듭니다.. private set으로 외부 변경이 불가능하게 만들기는 했지만 이 방법이 좋은 방법일까요?"* + 말리빈: *"프로젝트 전체적으로 불변성을 적용하지 않으면 어딘가에서는 반드시 가변적인 코드를 작성할 수 밖에 없겠지요. 불변 객체를 하나 적용한 곳에서, 가변인 곳이 발견된다면 그곳도 불변하게끔 변경하면서, 점진적으로 불변하는 객체가 존재할 수 있는 범위를 확장해나갈 수 있겠지요."*
+
+→ **함수형 plus + var private set vs 완전 불변 트레이드오프 점진적 적용**. PR #85·#148·#137 와 같은 결.
+
+### 8. `Hand.score 전략 분리` — *오버엔지니어링 가능성*
+
+말리빈: *"오호! 카드 점수를 구하는 전략을 분리해주셨네요!👍 블랙잭 게임에서 패의 총합을 구하는 방법이 여러개로 나뉠 가능성이 있는지는 고민해보시면 좋겠네요! 오버엔지니어링일 수도 있을지 스스로 판단해보면 좋겠어요"*
+
+→ **YAGNI vs 추상화 트레이드오프**. *전략 분리 = 미래 가능성*. *현재 1가지 계산 룰 = 단순 메서드*. PR #146·#147 와 같은 결.
+
+### 9. `Hand.totalScore` 호출 = `player.hand.score` Demeter 진단
+
+말리빈 진단: *"각 플레이어에게 score가 무엇인지 메세지를 던져 물어보는 것은 어떨까요? 디미터의 법칙에 대해 알아보셔도 좋겠어요"* + 예시: *"`val score1 = player.hand.score` `val score2 = player.score`. 아래 두 줄 중 디미터의 법칙을 지키고 있는 것은 어느것일까요?"*
+
+→ **`player.score` (위임 메서드) vs `player.hand.score` (Demeter 위반)**. PR #146·#88·#137·#93·#133 와 같은 결.
+
+### 10. `Dealer + Player Bust 룰 = 블랙잭 고려 부재`
+
+말리빈: *"딜러가 스페이드 A와 10을 가지고 있고, 플레이어가 4장의 카드와 합산 점수가 21이라면, 누구의 승리일까요?"* + 학생: *"블랙잭을 고려하지 않았군요.. 로직을 추가했습니다!"*
+
+→ **블랙잭 룰 정확성 = 2장 + 21 우선 = 3장 21 ≠ 블랙잭**. PR #148·#108·#125·#114·#131·#136·#137·#151 와 같은 결.
+
+### 11. `Dealer + Player canHit` 동일 메서드 강제 안티 다형성
+
+학생 자가 답변: *"이렇게 했던 이유는 Participant 추상클래스에서 구현된 메서드를 딜러와 플레이어가 똑같이 상속해서 사용하기 위해 억지로 메서드의 구현을 똑같이 맞추었기 때문에 컨트롤러가 딜러에게 canHit을 물어보는 상황이 되었습니다.. 딜러와 플레이어의 히트가능 조건이 다른 만큼 꼭 같은 메서드를 사용할 필요가 없었다고 생각합니다. ... 이렇게 수정하면 딜러의 hit 메서드에서 canHit을 부를 수 있게 되는데요, 이렇게 하면 딜러 객체의 자율성과 응집도가 더욱 높아질 것 같습니다!"*
+
+→ **다형성 강제 통일 vs 자율성 트레이드오프 자가 학습 모범**. *Player.canHit (입력) vs Dealer.canHit (16 이하)* 서로 다른 룰 = *abstract method 다형성* 또는 *Player/Dealer 자기 메서드*. PR #49·#108·#133·#132·#136 와 같은 결.
+
+### 12. `Rank.label` View 어휘
+
+말리빈: *"label은 사실 View의 요소는 아니었을지 고민해보셔도 좋겠어요 :)"*
+
+→ **enum 부가속성 = UI value 안티패턴**. PR #75·#124·#28·#78 와 같은 결.
+
+### 13. `WinningState.from(compared = -1)` — 의미 모호 인자
+
+말리빈 진단: *"compared가 뜻하는 숫자 범위에 대해서 다른 개발자들도 한 번에 알 수 있을까요? 옆에 있는 아무 사람이나 붙잡아서, 아래 코드만 보고, 승 패 무 중 무엇일 것 같냐고 물어본다면, 한 번에 맞출 수 있을까요? `WinningState.from(compared = -1)`"*
+
+→ **`Int` 인자 = 의미 모호**. *`compareTo` 결과 직접 노출 = 호출자가 -1/0/1 해석 필요*. PR #137·#90·#75 와 같은 결의 *원시값 포장*.
+
+### 14. `Participant abstract 의 요소 부재` — 메이저 진단
+
+말리빈: *"이 클래스는 abstract로 선언되어있는데 abstract의 요소가 전혀 없네요. abstract class와 interface의 차이는 무엇일까요?"* + 후속: *"abstract class는 가끔 고장난 클래스라는 별명이 있답니다. 빵꾸를 뚫어 고장내놓고, 사용자가 상속받아 사용할 때, 고장낸 부분을 사용자가 구현해야만 할 수 있게 만드는 것이지요. 그런 abstract 메서드들이 없어서 abstract 키워드를 사용한 게 어색했어요."*
+
+→ **`abstract` = 고장난 부분 강제 + 사용자가 채움**. *abstract method 0 + open property 0 = abstract 의미 부재*. **MCP 룰 후보 — `abstract-without-abstract-method`** (말리빈/페로로/두루 공통). PR #108·#133·#137·#147 와 같은 결.
+
+### 15. `CsvSource(delimiter = ":")` — 기본 어휘 위반
+
+말리빈: *"CsvSource에서 delimiter 정의를 \":\"로 명시한 특별한 이유가 있으셨나요 ?_?"* + 학생: *"특별한 이유는 없었고 보기 좋아서 \":\"로 사용했습니다!😅 혹시 좋지 않은 습관일까요?"* + 말리빈: *"아하! 좋지 않은 습관이라기 보다는, 저는 필요에 의해서 기능을 활용하는 것을 선호해서요! Comma Seperated Value, 즉 `,`로 나누어진 Value라는 의미이기에, `,`를 직접 문자열로 사용할 게 아니라면 구분자를 변경할 필요는 없다고 생각해요"*
+
+→ **CSV = Comma Seperated Value = 기본 구분자 의미**. *기능 의미 변경 = 명시 필요*. **MCP 룰 후보 — `csv-delimiter-deviation`** (테스트 어휘 미세).
+
+### 16. `참가자 같은 비즈니스 로직 묶기 부재` (Participant, ParticipantHand, Hand 결합도)
+
+말리빈: *"Participant, ParticipantHand, Hand 등등... 비슷한 역할을 가진 로직들이 응집도 있게 모여있지 않아보여요. 상호 클래스간 결합도가 매우 높은 느낌을 받았어요. 비슷한 역할들을 적절한 객체에게 응집도 있게 모아보는 것은 어떨까요?"*
+
+→ **유사 책임 분산 = 응집도 ↓**. *역할별 책임 응집* 정공. PR #147 (state × actor 폭증) 와 같은 결의 *책임 분산 안티패턴*.
+
+### 17. `Deck` 가 *플레이어 수에 관심* — 책임 누수
+
+말리빈: *"Deck이 player의 수에 대한 관심을 가지는 것은 적절할까요?"*
+
+→ **Deck = 카드 풀, Player 수 = Players 책임**. *책임 응집*. PR #108·#133 와 같은 결.
+
+### 18. `Card 보너스 점수 enum 전체에 강요` — 자가 반영
+
+말리빈: *"ACE 하나 때문에 보너스 점수라는 것을 enum 모두가 알고 있는 것이 적절할까요? 보너스 점수는 로직으로 표현해보는 건 어떨까요?"* + 학생 자가 반영.
+
+→ **enum 부가속성 vs 로직 분리**. *Ace 만 적용되는 룰 → 로직 표현*. PR #146·#137·#136 와 같은 결.
+
+## 리뷰어 의견 요지
+
+- **Delegate 일급 컬렉션 = 필요 이상 기능 노출 위험** — *말리빈 선호 X*.
+- **불변 객체 = 내부 + 외부 모두 변경 불가** — *학생 자가 정의 확립*.
+- **현실 메타포 vs 도메인 정합** — *Referee 자가 토론*.
+- **카지노 무한 게임 메타포 vs 카드 부족 종료**.
+- **`abstract` 키워드 = abstract method 강제** ("고장난 클래스 별명") — 메이저 진단.
+- **도메인 모르는 개발자 시나리오 = 명시적 invariant** — 메이저.
+- **함수형 plus + 점진적 불변성 적용**.
+- **양방향 의존성 = 결합도 ↑ + 변경 파급**.
+- **Demeter = `player.score` (위임) vs `player.hand.score` (위반)**.
+- **블랙잭 룰 정확성 = 2장 + 21 우선 (3장 21 ≠ 블랙잭)**.
+- **`Int` 인자 의미 모호 = compareTo 결과 노출 X**.
+- **CSV delimiter = 기본 의미 = 변경 X**.
+- **Card 캐싱 + 외부 다른 인스턴스 생성 차단 = private constructor**.
+- **gradle 우회 < 근본 원인 해결**.
+
+## 대표 인용
+
+**말리빈 (abstract = 고장난 클래스 별명, Participant.kt):**
+> abstract class는 가끔 고장난 클래스라는 별명이 있답니다. 빵꾸를 뚫어 고장내놓고, 사용자가 상속받아 사용할 때, 고장낸 부분을 사용자가 구현해야만 할 수 있게 만드는 것이지요.
+> 그런 abstract 메서드들이 없어서 abstract 키워드를 사용한 게 어색했어요.
+> open class 같은 "open" 키워드에 대해 알아보셔도 좋겠어요 :)
+
+**말리빈 (도메인 모르는 개발자 시나리오, ParticipantsHandCards.kt):**
+> "현 로직" 상에서는 문제가 없겠지요!
+> 다른 개발자가 리팩터링이나 기능 추가를 해야할 때, 블랙잭 게임에 대한 모든 룰과 제약조건에 대해 정확히 알고 있을까요?
+>
+> "도메인을 모르는 데 어떻게 개발에 투입되냐?" 라는 생각이 들 수도 있겠지만,
+> 그렇게 된다면 현실적으로 주니어 개발자는 취업을 할 수 없겠지요..
+
+**말리빈 (Delegate vs 일급 컬렉션 선호, Deck.kt):**
+> Delegate를 활용한다면, 일급 컬렉션이 필요 이상으로 기능들을 노출시킨다고 생각해요 :)
+
+**말리빈 (Demeter = `player.score` vs `player.hand.score`, Dealer.kt:25):**
+> 어떻게 양방향 의존성이 생겨나는걸까요 ?_?
+>
+> 아래 두 줄 중 디미터의 법칙을 지키고 있는 것은 어느것일까요?
+> ```kotlin
+> val score1 = player.hand.score
+> val score2 = player.score
+> ```
+
+**말리빈 (점진적 불변성, Player.kt):**
+> 프로젝트 전체적으로 불변성을 적용하지 않으면 어딘가에서는 반드시 가변적인 코드를 작성할 수 밖에 없겠지요.
+> 불변 객체를 하나 적용한 곳에서, 가변인 곳이 발견된다면 그곳도 불변하게끔 변경하면서, 점진적으로 불변하는 객체가 존재할 수 있는 범위를 확장해나갈 수 있겠지요.
+
+**말리빈 (CSV delimiter 기본 의미, HandTest.kt:16):**
+> Comma Seperated Value, 즉 `,`로 나누어진 Value라는 의미이기에, `,`를 직접 문자열로 사용할 게 아니라면 구분자를 변경할 필요는 없다고 생각해요
+
+**학생 자가 학습 (불변 객체 정의 자가 인식, Player.kt):**
+> 먼저 제가 불변객체에 대해 잘못 알고 있었군요! 외부에서만 바꾸지 못하면 불변객체라고 생각했는데 내부에서도 변경이 불가능해야 불변객체이군요. 알려주셔서 감사합니다 😄
+
+**학생 자가 학습 (Referee 자가 토론 + 결정, GameResult.kt):**
+> 최초 구상은 GameResult를 블랙잭 게임의 심판 역할을 하는 객체로 설계하는 것이었는데요, 굳이 심판을 둔 이유는 카드의 수를 비교하는 행동은 딜러와 플레이어 둘 사이에서 카드를 상호 확인하고 그에 따른 승패를 서로 동의하는 것이라고 생각했기 때문에, 딜러나 플레이어 둘 중 한쪽이 승패를 결정하는 것이 아니라 승패를 판정하는 심판이 저의 소프트웨어 세계에서는 필요하다고 생각했기 때문입니다.
+> ...
+> 둘다 구현해보고 비교해본 결과 굳이 심판이 필요하지는 않겠다는 생각이 듭니다! 판정 책임을 딜러에게 넘기니 코드량이 줄어들더라구요, 심판을 만들지 않는 것으로 수정했습니다.
+
+**학생 자가 학습 (다형성 강제 통일 vs 자율성, BlackJackController.kt:32):**
+> 이렇게 했던 이유는 Participant 추상클래스에서 구현된 메서드를 딜러와 플레이어가 똑같이 상속해서 사용하기 위해 억지로 메서드의 구현을 똑같이 맞추었기 때문에 컨트롤러가 딜러에게 canHit을 물어보는 상황이 되었습니다..
+> ...
+> 딜러와 플레이어의 히트가능 조건이 다른 만큼 꼭 같은 메서드를 사용할 필요가 없었다고 생각합니다.
+> 이렇게 수정하면 딜러의 hit 메서드에서 canHit을 부를 수 있게 되는데요, 이렇게 하면 딜러 객체의 자율성과 응집도가 더욱 높아질 것 같습니다!
+
+## 얻은 교훈
+
+1. ***`abstract` = abstract method 강제 = "고장난 클래스 별명"*** — 말리빈/페로로/두루 공통 진단. *abstract method 0 + open property 0 + abstract 키워드 = 의미 부재*. **MCP 룰 후보 — `abstract-without-abstract-method`** (메이저). PR #108·#133·#137·#147 와 같은 결.
+
+2. ***도메인 모르는 개발자 시나리오 = 명시적 invariant 강제***. *"현 로직 상에서는 문제가 없겠지만 도메인 모르는 개발자가 들어오면..."* = *주니어 안전망*. **MCP 룰 후보 — `implicit-invariant-on-known-rule`**.
+
+3. ***불변 객체 = 외부 + 내부 모두 변경 불가***. *학생 자가 정의 확립 모범*. PR #85·#148·#137 와 같은 결.
+
+4. ***현실 메타포 vs 도메인 정합 트레이드오프*** — *Referee 자가 토론 + 둘 다 구현 + 비교*. PR #58·#108·#137 와 같은 결.
+
+5. ***Delegate 일급 컬렉션 = 필요 이상 기능 노출***. *말리빈 선호 X*. *직접 구현 + 메서드 선택*이 정공. PR #146·#136 와 같은 결.
+
+6. ***점진적 불변성 적용***. *일부 불변 + 점차 확장*. *완전 불변은 어려움 + 부분 적용 가치*. PR #85 와 같은 결.
+
+7. ***Demeter = `player.score` (위임) vs `player.hand.score` (위반)*** — 말리빈 명료한 비교 예시. PR #146·#88·#137·#93·#133 와 같은 결.
+
+8. ***함수형 plus + var private set vs 완전 불변 트레이드오프***. *Kotlin `cards + card` immutable expression* 활용. PR #85·#148·#137 와 같은 결.
+
+9. ***양방향 의존성 = 결합도 ↑ + 변경 파급***. *Deck ↔ Card 양방향* 자가 해소. PR #93 와 같은 결.
+
+10. ***Hand.score 전략 분리 = 오버엔지니어링 가능성 (YAGNI)***. *블랙잭 1 룰 = 단순 메서드*. PR #146·#147 와 같은 결.
+
+11. ***다형성 강제 통일 vs 자율성 트레이드오프***. *Player.canHit (입력) vs Dealer.canHit (16) 다른 룰*. *abstract method 다형성* 또는 *각자 메서드 + 자율성*. PR #49·#108·#133·#132·#136 와 같은 결.
+
+12. ***`Int` 인자 = 의미 모호 (compareTo 결과 -1/0/1 노출 X)***. *value class 포장 + 의미 명시*. PR #137·#90·#75 와 같은 결.
+
+13. ***Card 캐싱 + private constructor = 외부 다른 인스턴스 차단***. *factory만 가능*. PR #108·#133·#136 와 같은 결.
+
+14. ***gradle 우회 vs 근본 원인 해결 = 학습 가치***. *복사 코드 + 이해 없음 안티패턴*. **MCP 룰 후보 — `copy-paste-without-understanding`**.
+
+15. ***`@JvmStatic` / `@JvmField` = Java interop = 순수 Kotlin 시 불필요***. PR #58 와 같은 결.
+
+16. ***CSV delimiter = 기본 의미 (Comma Seperated Value)***. *기능 의미 변경 = 명시 필요*. *기본 어휘 우선*. **MCP 룰 후보 — `csv-delimiter-deviation`**.
+
+17. ***`Hand.score` 전략 패턴 (`Hand.scoreStrategy`) = 오버엔지니어링 vs 미래 확장 트레이드오프***. *현재 1 룰 = 단순 메서드*. PR #146 와 같은 결.
+
+18. ***학생 자가 학습 + 자가 답변 + 트레이드오프 양방향 인식 풍부 = 학습 가시화 최고 수준***. *Delegate / 불변 객체 / Referee / abstract / 다형성 강제 통일 자가 토론*. PR #146·#148·#151·#137 와 같은 결.

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

@@ -0,0 +1,216 @@
+# PR #95 — [블랙잭 2단계] 알송 미션
+
+- **Reviewee:** [@songpink](https://github.com/songpink)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/95
+- **단계:** 2단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 13 스레드 + **학생 자가 의문 1개** (open vs abstract 다시 학습) + **말리빈 매우 긴 메타 답변** (자기 논리의 한계 자가 인정 + "옳고 그름 없음, 장단점만")
+- **양 단계 분석 reviewee** (1단계 #74 별도)
+
+## 잘한 점 (설계 관점)
+
+- **학생 자가 의문 후 reviewer 가 자기 진단의 한계 자가 인정 + 메타 학습 어휘 답변** — 학생 의문: *"하위 클래스에서 구현이 모두 같은데도 굳이 추상클래스로 만들고 override를 하는 것이 좋은지, 아니면 인스턴스가 없더라도 open클래스로 만드는 것이 좋은지 입니다."* + 말리빈 답변: *"꼭 Player와 Dealer가 같은 부모를 상속 받아야만 한다는 규칙은 없으니까요 :) Player가 최상위고, Dealer는 Player의 변종 정도로 생각하는 것은 부자연스러울까요?"* + *"개발에 옳고 그름은 없으니, 틀린방법은 없어요. 위에서 짚어드린 내용 조차도, '틀린' 내용이 아니예요. 그저 저는 공감하기 어려웠고, 지키고 싶은 여러 요소들을 지킬 수 있는 다른 방법들이 떠올랐기 때문에 다른 방법을 제시해볼 수 있을 거라 생각했어요 :)"*. **양방향 reviewer/학생 메타 토론 + reviewer 자기 한계 자가 인정 모범** — PR #133·#137·#146·#147·#148·#151 와 같은 결.
+- **PR 본문에 자가 의문 + 자가 정당화** — *"플레이어들이 예산(budget)을 프로퍼티로 갖게 한 것이 있는데요, 이번 미션에서 사용되지는 않는 프로퍼티이기는 한데, 수익(profit)을 플레이어들이 프로퍼티로 가지고 있으려면 예산도 가지고 있는 것이 자연스럽더라구요.. 일단 만들어 두었다가 사용되지 않아서 지웠는데, 지우니까 상당히 어색해져서 다시 만들었습니다."*. **학생이 *불필요해 보이는 프로퍼티의 자가 정당화 → reviewer 가 다른 의견 제시* 시드**. (말리빈은 *"손익은 PlayerResult 가 가져야"* 로 반박 — 아래 §6).
+- **Tell-Don't-Ask 자가 인정 + 자가 반영** — 말리빈 진단 *"카드들에게 현 상태가 블랙잭인지 메시지를 던져 물어보는 건 어떨까요?"* + 학생: *"Hand에게 해당 메서드가 있음에도 사용하지 않았군요.. 수정했습니다."*. *PR #74 1단계의 Tell-Don't-Ask 학습 누락 → 2단계 자가 인정 + 반영*.
+- **사이드 이펙트 vs 결과 객체 반환 자가 학습** — 말리빈: *"객체의 사이드 이펙트를 발생시키지 않고, 결과 객체를 만들어 반환하도록 구성해보는 건 어떨까요?"* + 학생: *"확실히 의존성을 주입하도록 수정하면 결합도를 낮출 수 있겠네요. 수정했습니다."*. *책임 분리 + 함수형 결과 반환 자가 학습* — PR #133·#136·#90 와 같은 결.
+- **when 6번 합산 → 변수 저장 자가 반영** — 말리빈: *"when절의 3번째 분기까지 간다면, 총합을 구하는 연산을 총 6번을 해야하네요. 비효율적인 연산을 줄일 수 있는 방법이 있을까요?"* + 학생: *"계산된 값을 담는 새로운 변수를 선언해 사용하도록 변경했습니다."*. *공통 연산 추출 + 가독성 향상*.
+- **1단계 Deck 안전성 PR #74 자가 참조** — 말리빈: *"이 코드는 아래 코드에 대해 여전히 안전할까요? https://github.com/woowacourse/kotlin-blackjack/pull/74#discussion_r1521166706"* + 학생: *"꼼꼼하지 못해 죄송합니다.. 😅 수정했습니다!!"*. **1단계 권고 자가 참조 + 2단계 반영 누락 자가 인정**. PR #74 의 *방어적 복사* / *카드 캐싱* / *Card private constructor + Factory* 결.
+- **Random 테스트 가능성 → interface + 구현체 분리 자가 학습 권고** — 말리빈: *"자동차 경주와 로또에서 배웠던 랜덤 테스트에 대해 꼭 복습해보세요. 랜덤의 요소를 최소한으로 만들어서 테스트 해볼 수 있게끔 구성하길 바랐어요. 파라미터로 값을 받아 랜덤에 대한 요소를 줄여내볼 수도 있었고, interface 와 구현체를 활용해서도 랜덤에 대한 요소를 줄여내볼 수 있었지요."*. **lotto/racingcar 학습 자가 연결 권고** — 학생 미반영 (양 단계 머지 시점까지).
+- **Participant 공통 추출 자가 반영** — 말리빈: *"플레이어와 딜러가 공통적으로 갖고 있는 것들도 Participant에 묶어보는 건 어떨까요?"* + 학생: *"묶어주었습니다! 그런데 그 과정에서 궁금한 점이 생겼네요.. 다음 요청때 질문드리겠습니다."* → *학생 자가 의문 → 본문 코멘트로 의문 명시 후속 토론* 시드. PR #49·#108·#133·#132·#136 와 같은 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `abstract Participant + Player/Dealer 동일 구현 override` — *학생 자가 의문 + 말리빈 매우 긴 메타 답변*
+
+학생 자가 의문 (PR 본문 코멘트):
+
+> *"Participant 추상클래스에 있는 hit과 setInitialHand는 Player와 Dealer에서 구현이 바뀌지 않고 동일하게 사용됩니다. 저는 처음에 구현이 똑같기 때문에 굳이 각각의 객체가 이 메서드들을 override하지 않고 추상클래스의 메서드를 그대로 사용하면 되겠다고 생각을 했습니다. 그런데 이렇게 했을 때 말리빈께서 'Participant가 abstract의 성격을 가지고 있지 않다'라고 피드백을 주셨습니다. 저는 그래서 이 때 Participant를 open클래스로 바꿀까도 생각을 했지만 이 경우 Participant의 인스턴스를 만들고 있지 않기 때문에 open클래스를 쓰면 안된다는 다른 크루의 말을 들었습니다. 그래서 abstract로 유지하되, hit과 setInitialHand의 구현을 플레이어와 딜러가 똑같이 override하는 방식으로 수정했습니다. 이 방법이 옳은걸까요?"*
+
+말리빈 매우 긴 답변 (메타 학습 어휘):
+
+> *"'Participant의 인스턴스를 만들고 있지 않기 때문에 open클래스를 쓰면 안된다는 다른 크루의 말을 들었습니다' 요건 왜 안되는지 그 크루는 논리적으로 알송을 설득한 것일까요? 저는 왜 안되는지 좀 더 물어봤을 것 같네요!"*
+>
+> *"꼭 Player와 Dealer가 같은 부모를 상속 받아야만 한다는 규칙은 없으니까요 :) Player가 최상위고, Dealer는 Player의 변종 정도로 생각하는 것은 부자연스러울까요?"*
+>
+> *"개발에 옳고 그름은 없으니, 틀린방법은 없어요. 위에서 짚어드린 내용 조차도, '틀린' 내용이 아니예요. 그저 저는 공감하기 어려웠고, 지키고 싶은 여러 요소들을 지킬 수 있는 다른 방법들이 떠올랐기 때문에 다른 방법을 제시해볼 수 있을 거라 생각했어요 :)"*
+>
+> *"제가 한 말에 대해서도 논리적인 반박을 할 수 있었을 거예요! '말리빈께서 Participant가 abstract의 성격을 가지고 있지 않다'라고 했으나, 여기에는 알송이 말씀하신 한 가지 요소가 결여되어있네요. 'Participant의 인스턴스를 만들고 있지 않기 때문에' 에서, abstract class 이기에 원하지 않는 객체의 인스턴스를 만들어내고 싶지 않았다, 라는 논리였다면 저는 이 논리에 대해 매우 공감하고, 납득했을 거예요."*
+>
+> *"개발의 세계에는 정답이 없으니, 정말 많은 고민을 하면서 미션을 수행해보세요. 옳고 그름은 없고, 장단점만이 있는 세계이니까요!"*
+
+→ **3 가지 메타 학습**:
+
+#### 1.1. 다른 크루의 말 *그대로 따라하지 말기*
+
+*"왜 안되는지 그 크루는 논리적으로 알송을 설득한 것일까요?"* — *권위 인용 (다른 크루) ≠ 논리적 설득*. *학생은 *논리를 묻고 자기가 납득해야* 자기 결정*.
+
+#### 1.2. 상속 구조 자체 의문 권유
+
+*"꼭 Player와 Dealer가 같은 부모를 상속 받아야만 한다는 규칙은 없으니까요"* — *블랙잭에서 Player와 Dealer 가 *같은 추상 부모를 가져야 한다* 는 가정 자체 의문 권유*. 
+
+대안:
+- (A) **`Dealer extends Player`** = *Dealer 는 Player 의 변종 (자동 hit ≤16 외엔 동일)*. *공통 코드 직접 상속 + abstract 키워드 불필요*.
+- (B) **`abstract Participant`** = *공통 추상 + 각각 구현*. *학생 현재 코드*.
+- (C) **`interface Participant`** + *각각 별도 구현* = *상속 회피 + 다중 인터페이스 가능*.
+- (D) **`Dealer`/`Player` 무관계 + 공통 코드는 협력자에게 위임** = *상속 회피 + 컴포지션*.
+
+학생 자가 결정 = (B) — *현실 메타포 (참가자 abstract) 우선*. 말리빈은 *(A) 도 가능* 제시 + *정답 강요 X*.
+
+#### 1.3. *"개발에 옳고 그름은 없고, 장단점만이 있는 세계"* — **조영호 메타 가르침과 일치**
+
+→ **MCP `oh-my-oop` 의 핵심 어휘 = *단일 답 X, N개 대안 + 트레이드오프***. 말리빈의 답변은 이 어휘를 자가 사용. *학생이 reviewer 의 한 가지 의견을 *절대 답*으로 오해하지 않도록 *메타 학습 어휘 명시***.
+
+→ **PR #75·#147·#151 의 reviewer 자가 한계 인정** 결.
+
+→ **MCP 룰 후보 — `abstract-without-abstract-method`** (1단계 #74 의 학습 누락이 2단계에 재발 → 학생 자가 자가 의문화 → reviewer 메타 답변).
+
+### 2. `Controller → BlackjackGame.start() 결과 반환` — 학생 *이해 못함* + 두번 부연
+
+말리빈 진단:
+
+```kotlin
+val game = BlackJackGame()
+val result = game.start()
+print(result)
+```
+
+학생 자가 의문: *"이해를 못했습니다.. 출력해야 할 사항이 여러개인데, 어떤 결과를 반환하도록 하라는 말씀이실까요..?"*
+
+말리빈 부연: *"마지막 게임이 종료되고 나서 출력해야할 게임의 결과물을 말씀드렸어요! 출력해야할 것들은 객체를 생성하거나, 메서드 파라미터 등으로 적절히 전달해주면 충분히 구성 가능하실거예요 :)"*
+
+→ **학생 자가 의문 = 이해 갭 명시 (자가 학습 모범)**. 
+
+이해 갭 진단:
+- *학생 코드*: Controller 가 *진행 중 단계별로 출력* (initial hand → hit 입력 → 결과 출력 → 수익 출력 4-5 단계).
+- *말리빈 의도*: *게임의 진행과 출력 시점을 결과 객체에 응축* → *Controller 는 출력 명령만*.
+- 그러나 *진행 중 출력*은 *블랙잭 도메인의 자연 흐름* — *초기 카드 후 → 각 플레이어 hit 입력* 단계 자체가 *결과 객체 반환 후 출력* 모델과 충돌.
+
+해결 대안:
+- (A) **`game.start()` 가 *상태 전이 기록*을 담은 `GameLog` 반환** = *Controller 가 로그 재생 (replay)*. 그러나 *hit 입력 같은 양방향 IO 가 어려움*.
+- (B) **`game.start(inputCallback, outputCallback)` 패턴** = *Inversion of Control + 콜백*. *학생 미적용*. PR #137 의 *onXX 콜백* 결.
+- (C) **현재 학생 구조 유지 + Controller 가 진행 중 출력 명령** = *현실 절차에 가까운 모델 + 양방향 IO 자연*.
+
+학생 미반영 + 머지. *말리빈 권고가 *학생 도메인 모델과 충돌* → 학생이 *명확히 이해 못한 채 머지* 케이스*. **두 번 부연했음에도 학생 미반영** — 권고의 한계.
+
+→ **PR #98 의 *상태 패턴 효과 자가 의문*** 와 같은 결 *(권고 ≠ 학생 도메인 정합 시 미반영)*.
+
+### 3. `Dealer.hit(condition)` vs `Dealer.hit()` 시그니처 불일치 → 디폴트 파라미터 우회
+
+말리빈 진단: *"이 둘은 어떻게 다른가요? 딜러는 둘 둥 어떤 메서드를 써야할지 다른 개발자는 바로 알아차릴 수 있을까요?"*
+
+학생: *"추상클래스의 메서드를 딜러와 플레이어가 공통으로 상속하도록 하고 싶었는데, 딜러는 hit조건을 객체 내부에서 불러올 수 있기 때문에 condition파라미터가 필요가 없더라구요.. 그런데 상속을 할 때 메서드의 시그니처를 바꾸는 방법이 없어서, 별 수 없이 오버로드를 했습니다. 다른 방법을 일단 찾아보겠습니다.."* + 후속: *"디폴트 파라미터를 사용해 수정했습니다!"*
+
+말리빈 후속: *"음~ 사실 condition을 외부에서 받도록 구성하지 않았으면 했어요. BlackjackGame을 관제하는 하나의 객체가 있어서, 해당 객체와 적절히 협력하는 형태로 구성해도 좋겠다는 생각이 들었어요 :) 말씀해주신대로 딜러와 플레이어가 동일한 메서드를 호출해서 플레이하지 않을 수도 있으니까요!"*
+
+→ **3 단계 자가 학습 + reviewer 후속 권고**:
+
+1. **상속 시그니처 불일치 자가 진단** = *Player.hit(condition)* vs *Dealer.hit()* → *추상 메서드 시그니처 강제*.
+2. **디폴트 파라미터 우회** = *`hit(condition: () -> Boolean = { true })`* 같은 형태. 학생 자가 시도.
+3. **reviewer 후속 = 우회 X, *근본 원인* (외부에서 condition 받는 구조) 자체가 잘못** = *Player.hit 자체가 외부 의존 = 단순 명령 X*.
+
+대안:
+- (A) **`Dealer` / `Player` 가 *같은 부모 X* + 각자 자기 책임의 hit()** (위 §1.2 (A)).
+- (B) **상속 유지 + Player/Dealer 동일 시그니처 + 내부에서 자기 조건 판단** = *condition 인자 제거 + 자기 메서드에서 자기 조건*.
+- (C) **`BlackjackGame` 관제 객체가 *언제 누구에게 hit 명령* 결정** + *Dealer/Player 는 단순 카드 수령*.
+
+**MCP 룰 후보 — `strategy-default-param-pollution`** (lotto 의 기존 룰 변형) 결. *디폴트 파라미터 = 메서드 오버로드 우회 시 *시그니처 통일* 효과 + 단점은 *호출 컨텍스트별 의미 차이*.
+
+### 4. `Deck.draw()` 53장 시 테스트 가능성 X
+
+말리빈: *"53번째 카드는 정확히 무엇이 나올지 테스트를 작성할 수 있는 코드일까요?"*
+
+학생: *"테스트를 못하겠군요.. 할 수 있도록 수정했습니다."*
+
+→ **테스터빌리티 자가 학습**. 53번째 카드 = *덱이 비어 카드를 모두 소진한 후 다음 동작* 시나리오. *내부 랜덤 의존 = 테스트 불가능*.
+
+해결:
+- *interface CardDealer + 구현체 분리* (말리빈 별도 권고 #11) = *테스트 시 결정적 구현체 주입*.
+
+PR #74 1단계의 *카드 부족 시 게임 종료 UX* 자가 토론 결.
+
+### 5. `Deck.cards` 양방향 안전성 (PR #74 자가 참조 누락 자가 인정)
+
+말리빈: *"이 코드는 아래 코드에 대해 여전히 안전할까요?"* + PR #74 코멘트 URL 인용.
+
+학생: *"꼼꼼하지 못해 죄송합니다.. 😅 수정했습니다!!"*
+
+→ **1단계 권고가 2단계 코드에서 다시 등장 = 학생 자가 인정**. *reviewer 의 PR 자가 참조* (URL 첨부) = *학생이 1단계 권고 위치를 즉시 확인 가능*. 
+
+PR #74 1단계 §방어적 복사 자가 학습 / *Deck 외부 변경 가능성* 토론 결.
+
+### 6. `Player.profit` 책임 위치 = *Player vs PlayerResult*
+
+말리빈 진단: *"손익에 대한 건 게임의 결과라고 생각해요. 플레이어가 갖지 않고, 게임 결과를 담은 객체가 담고 있게 구성해보셔도 좋겠어요."* + 별도: *"베팅 머니 자체는 Player 객체가 가지고 있어도 좋아보이네요! 그렇다면 PlayerResult 스스로가 플레이어의 승패에 따라 베팅머니를 계산하는 역할을 맡아볼 수도 있겠어요."*
+
+학생 미반영 (머지 시점까지).
+
+→ **PR 본문 자가 의문 (예산 프로퍼티 자가 정당화) 의 반박**:
+
+- 학생: *"수익을 플레이어들이 프로퍼티로 가지고 있으려면 예산도 가지고 있는 것이 자연스럽더라구요"*
+- 말리빈: *수익은 *게임 결과* 의 책임* — *Player 는 베팅 머니까지*, *수익 (승패에 따라 계산되는 결과값) 은 PlayerResult*.
+
+**역할 vs 상태 분리** — PR #148 의 *krrong (역할=Player, 상태=GameResult) 자가 학습* 결. **MCP 룰 후보 — `role-state-conflation`** 결.
+
+### 7. `Player` 손익 책임 누수 + `Dealer` 책임 비대
+
+말리빈: *"딜러 객체가 하는 일이 매우 많아졌네요. 하는 역할을 적절히 다른 객체에 분리해보는 연습을 시도해보셔도 좋겠어요."*
+
+→ **PR #74 1단계 §점수 계산이 Dealer 책임 위치 자가 토론 / Referee 자가 학습** 의 *2단계 재발*. *책임 분산 학습이 2단계에서 다시 누수*. 학생 미반영.
+
+PR #28·#78·#112·#125·#147 의 *Controller god-object* 결의 *Dealer god-object*.
+
+### 8. `ind` 축약어 명명 — vague-name 결
+
+말리빈: *"ind가 index인지 다른 개발자들이 한 번에 알아챌 수 있을까요? 축약어는 최대한 사용을 지양하도록 노력해보세요 :)"*
+
+→ **변수명 축약어 = *짧기 위해 명확성 희생***. `index` / `i` (관용 한정) / `position` / `cardIdx` 가 대안. **MCP 기존 룰 `vagueName`** (lotto/racingcar `vagabond95` 인용) 결.
+
+## 리뷰어 의견 요지 (말리빈 / malibinYun)
+
+13 코멘트 + 매우 긴 메타 답변. 특징:
+
+- **단순 진단보다 *학생 자가 의문 유발* 어휘** — *"~ 어떨까요?"*, *"~ 다른 개발자는 바로 알아차릴 수 있을까요?"*, *"~ 정말 '심판'이 따로 있는지"* — *학생이 자가 답변 작성하도록 유도*.
+- **PR 자가 참조** — 1단계 PR #74 의 코멘트 URL 첨부. *학생이 1단계 학습 위치를 즉시 확인 가능*. PR #133·#136 의 *PR 자가 참조* 결.
+- **자기 진단의 한계 자가 인정** — *"위에서 짚어드린 내용 조차도, '틀린' 내용이 아니예요. 그저 저는 공감하기 어려웠고..."*. PR #147 페로로 *"다형성 학습 진행 인정"* / PR #151 크롱 *"확장성 한계 자가 인정"* 결.
+- **메타 학습 어휘 명시** — *"개발에 옳고 그름은 없고, 장단점만이 있는 세계"*. **MCP `oh-my-oop` 핵심 어휘와 일치**.
+- **머지 시점 권유** — *"나중에 시간이 나게 된다면 미션을 처음부터 다시 만들어보는 시간을 가져보셔도 좋겠어요! 처음 만든 것과 완전히 다른 코드를 마주하게 될거예요 :)"*. **재구현 권유 = 학생 자가 진화 모범** — PR #98 chaehyuns 의 *"추후 시간이 될 때 다시한번 구현해보고 싶네요"* 결.
+
+## 대표 인용
+
+> *"꼭 Player와 Dealer가 같은 부모를 상속 받아야만 한다는 규칙은 없으니까요 :) Player가 최상위고, Dealer는 Player의 변종 정도로 생각하는 것은 부자연스러울까요?"* — malibinYun (상속 구조 자체 의문 권유)
+
+> *"개발에 옳고 그름은 없으니, 틀린방법은 없어요. 위에서 짚어드린 내용 조차도, '틀린' 내용이 아니예요. 그저 저는 공감하기 어려웠고, 지키고 싶은 여러 요소들을 지킬 수 있는 다른 방법들이 떠올랐기 때문에 다른 방법을 제시해볼 수 있을 거라 생각했어요 :)"* — malibinYun (자기 진단의 한계 자가 인정)
+
+> *"제가 생각하고 있는 무언가들도 누군가에게는, 그들이 지켜내고 싶은 특정 요소들을 만족시키지 못할 거예요. 리뷰어한테 미션을 시키고 다른 리뷰어가 리뷰하더라도 모두가 다른 의견을 제시할거예요."* — malibinYun (reviewer 다양성 = 절대 답 X)
+
+> *"개발의 세계에는 정답이 없으니, 정말 많은 고민을 하면서 미션을 수행해보세요. 옳고 그름은 없고, 장단점만이 있는 세계이니까요!"* — malibinYun (조영호 메타 가르침과 일치)
+
+> *"하위 클래스에서 구현이 모두 같은데도 굳이 추상클래스로 만들고 override를 하는 것이 좋은지, 아니면 인스턴스가 없더라도 open클래스로 만드는 것이 좋은지 입니다."* — songpink (학생 자가 의문 = 학습 갭 명시)
+
+> *"이해를 못했습니다.. 출력해야 할 사항이 여러개인데, 어떤 결과를 반환하도록 하라는 말씀이실까요..?"* — songpink (학생 자가 이해 갭 명시 = 학습 모범)
+
+## 얻은 교훈
+
+1. **reviewer 의 메타 답변 = *"옳고 그름 X, 장단점만"*** — *조영호 「객체지향의 사실과 오해」 와 MCP `oh-my-oop` 의 핵심 어휘*. *말리빈의 답변이 이 어휘를 직접 사용* = *학생이 *reviewer 의견을 절대 답으로 오해하지 않도록 메타 학습 어휘 명시***. **MCP 의 핵심 가치가 실제 리뷰 현장에서 동일하게 작동**.
+
+2. **다른 크루의 말 *그대로 따라하지 말기*** — *권위 인용 ≠ 논리적 설득*. 학생이 *논리를 묻고 자기가 납득해야* 자기 결정. *말리빈의 *"왜 안되는지 그 크루는 논리적으로 알송을 설득한 것일까요?"*. PR #147·#151·#137 의 *학생/reviewer 메타 토론* 결.
+
+3. **상속 구조 자체 의문 권유** — *Player extends Dealer? Dealer extends Player? 둘 다 같은 부모? 무관계?* — *기본 가정 자체 다시 보기*. PR #49·#108·#133·#132·#136 의 *추상 클래스 + Participant 통합* 결의 *반대 시점*.
+
+4. **`abstract class` vs `open class` vs `interface` 자가 학습**:
+   - *`abstract class`* = *인스턴스 생성 차단 + 추상 메서드 가능 + 단일 상속*.
+   - *`open class`* = *인스턴스 생성 가능 + 상속 가능*.
+   - *`interface`* = *다중 구현 + 구현 메서드 (default impl) 가능 + 백킹 필드 X*.
+   - *블랙잭 Participant 처럼 *인스턴스 X + 공통 코드 100%* = *abstract 이지만 abstract 메서드 X* → *어색함* → *open class (인스턴스 X 강제 X) 또는 interface (다중 구현) 정공*. **MCP 룰 후보 `abstract-without-abstract-method`** = PR #74·#108·#133·#137·#147 결.
+
+5. **PR 본문 자가 의문 + 자가 정당화 + 본문 코멘트로 자가 의문 명시** — *학생이 *불필요해 보이는 프로퍼티 / 어려운 구조 변경 / 학습 갭* 을 *PR 본문 + 본문 코멘트에 명시 = 학습 가시화 모범*. PR #128·#135·#108·#133·#136·#137·#148·#151·#98 와 같은 결.
+
+6. ***이해 못함* 자가 명시 = 학습 모범** — *"이해를 못했습니다.. 어떤 결과를 반환하도록 하라는 말씀이실까요?"* — *reviewer 권고를 *그대로 반영 X* + *자가 이해 갭 명시 후 부연 요청*. *학생이 *모르는 채로 머지하지 않으려는 자가 의식*.
+
+7. **권고가 학생 도메인 모델과 충돌 시 미반영** — *Controller → BlackjackGame.start() 결과 반환* 처럼 *학생의 진행 중 출력 흐름 (양방향 IO)* 과 *결과 객체 응축* 이 충돌 → *학생 미반영 + 머지*. **권고 ≠ 절대 답** 의 실증.
+
+8. **1단계 PR 자가 참조 + URL 인용** — *2단계에서 1단계 동일 안티패턴 재발 시 reviewer 가 1단계 코멘트 URL 첨부* → *학생이 즉시 1단계 학습 위치 확인 + 자가 인정*. **양 단계 본 reviewer 만 가능한 권유 형식**.
+
+9. **`Player.profit` 책임 위치 = *Player vs PlayerResult* (역할 vs 상태)** — *역할 (Player) 은 베팅 머니까지 / 상태 (수익 계산 결과) 는 PlayerResult*. **MCP 룰 후보 `role-state-conflation`** — PR #148 의 krrong (역할 vs 상태 자가 학습) 결.
+
+10. **재구현 권유 = 학생 자가 진화 모범** — *"나중에 시간이 나게 된다면 미션을 처음부터 다시 만들어보는 시간을 가져보셔도 좋겠어요! 처음 만든 것과 완전히 다른 코드를 마주하게 될거예요"*. *학습 = 한 번에 X + 시간 두고 반복*. PR #98 chaehyuns *"추후 시간이 될 때 다시한번 구현해보고 싶네요"* 결.

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

@@ -0,0 +1,132 @@
+# PR #15 — [블랙잭 1단계] 하티 미션
+
+- **Reviewee:** [@sujin9](https://github.com/sujin9)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/15
+- **단계:** 1단계
+- **리뷰어:** [@BeokBeok](https://github.com/BeokBeok) (벅벅) — 2023 코호트 reviewer
+- **라인 코멘트:** 13 스레드 — *PR 본문 자가 의문 (enum 출력 표기 위치 + mark vs view 변환 예시 코드) + abstract vs open 학생 자가 깊은 학습 (인스턴스화 여부) + 다국어 어휘 + on 전치사 = 콜백 어휘 + 함수명 vs 구현부 일치 + Ace 관리 위치 + private constructor + 팩토리 칭찬*
+- **신규 reviewee** (2023 코호트, 새 1단계).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 + 코드 예시
+
+PR 본문:
+
+> *"enum 클래스가 출력 시 표기되는 부분은 어느 부분에 정의하는 것이 책임에 옳은건가 하는 의문이 들었습니다."*
+
+→ **PR 본문 자가 의문 + 코드 예시** = PR #35·#126 결 합류.
+
+### 2. abstract vs open 학생 자가 깊은 학습 (Thread 5)
+
+reviewer: *"abstract와 open의 차이점은 무엇일까요?"*
+
+학생 자가 답변:
+
+> *"**open** : 상속을 **받을 수 있는** 클래스 또는 함수입니다. open class는 상속 받는 대상이 없어도 인스턴스화 할 수 있고, open fun은 상속 받는 대상이 그대로 사용할 수도, override하여 재정의할 수도 있습니다.*
+>
+> ***abstract** : 상속을 **받아야만 하는** 클래스 또는 함수입니다. abstract class는 상속 받는 대상이 없다면 인스턴스화할 수 없습니다. abstract fun은 반드시 재정의되어야 합니다.*"
+
+reviewer:
+
+> *"open과 abstract의 차이점에 대해서 잘 정리해주셨네요. 👍 볼드체하신 부분도 중요하지만, 가장 큰 차이점은 \"인스턴스화\" 여부도 중요합니다. 😄 Participant 자체가 인스턴스가 생성되면 안되기 때문에, open보다 abstract가 더 적합합니다."*
+
+→ **Kotlin 어휘 깊은 자가 학습 + reviewer 정정 (인스턴스화 여부 핵심)** = PR #19·#129·#126·#138·#142·#143·#113·#69·#102 결 누적 10+ PR.
+
+### 3. 다국어 어휘 (Thread 8)
+
+reviewer:
+
+> *"같은 enum 타입이여도 다른 화면에서는 다르게 보여줘야하는 경우가 있습니다. 또한, 추후 안드로이드 개발을 하시게 되면 \"다국어\" 기능을 염두에 두고 개발을 하시게 될텐데, \"다국어\" 지원을 하기 위해서는 View에서 보여주도록 하는 것이 대응하기가 용이합니다. 😄"*
+
+→ **다국어 어휘 + 안드로이드 미래 학습** = PR #130 (medAndro 안드로이드 리소스 파일) + PR #118 (Shape 안드로이드 이식) 결 합류.
+
+**MCP 룰 `i18n-multi-language-as-view-responsibility` 후보** — *다국어 = View 책임*.
+
+### 4. 추가 칭찬
+
+- Thread 12: *"대체로 팩터리 메서드를 활용하고, 생성자로 객체를 만들지 못하도록 private constructor를 잘 활용해주셨네요. 👍"*.
+- Thread 13: *"when을 exhaustive하게 잘 작성해주셔서 enum이 추가되거나 삭제되더라도 변경을 쉽게 인지할 수 있겠네요. 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. 승패 로직 테스트 가능 (Thread 1)
+
+reviewer: *"이 로직은 승패와 관련된 로직을 담고 있습니다. 블랙잭 미션에서 핵심 로직 중 하나라고 볼 수 있습니다. 그렇다면 테스트가 가능하도록 코드를 개선해보면 어떨까요?"*
+
+→ **테스트 가능성 = 객체 설계 지표** = 누적 다수.
+
+### 2. Ace 관리 위치 (Thread 2)
+
+reviewer: *"Ace라는 값을 어디에서 관리를 하고 있는지 고민해보시면 좋을 것 같아요. Ace 값을 관리하는 곳에서 메시지를 보내서 판단하도록 코드를 개선해보면 어떨까요?"*
+
+→ **Tell-Don't-Ask + Ace 책임 위치** = 누적 다수.
+
+### 3. CardNumber.value 프로퍼티 불필요 (Thread 3)
+
+reviewer: *"CardNumber의 value를 조회하는 프로퍼티를 구현해주셨네요. 👍 하지만, 이 프로퍼티가 없이 value를 조회할 수 있지 않을까요?"*
+
+→ **불필요한 프로퍼티** = PR #141·#149 (Money.toInt() 불필요) 결 합류.
+
+### 4. value class 포장 (Thread 6)
+
+reviewer: *"스코어(Int)도 위 요구사항을 반영해보면 어떨까요?"*
+
+→ **원시값 포장** = 누적 다수.
+
+### 5. companion object import 가독성 (Thread 7)
+
+reviewer:
+
+> *"companion object를 import하게되면 간편하게 사용할 수 있는 장점이 있습니다. 반면, 이 값이 어느 곳에서 정의가 되었는지 알기가 어렵습니다. 어떤 companion object에 정의가 되어있는지 알기 쉽도록 코드를 개선해보면 어떨까요?"*
+
+→ **import 가독성 트레이드오프** = **MCP 룰 `companion-object-import-readability` 후보**.
+
+### 6. on 전치사 = 콜백 어휘 (Thread 11) + 외부글
+
+reviewer:
+
+> *"함수명 앞에 \"on\"이라는 전치사를 사용해주셨네요. 👍 대체로 앞에 \"on\"이라는 전치사를 사용하여 함수를 작성하는 경우, 일반 함수가 아닌 \"콜백\" 함수를 의도합니다. 이 함수는 콜백함수가 아니므로, 전치사를 제거해보면 어떨까요?*
+>
+> *ref. https://android.googlesource.com/platform/developers/docs/+/975a589941f728f6c6ce6fbbd7517ca854bc61ba/api-guidelines/index.md#callback-method-nami"*
+
+→ **on 전치사 콜백 어휘 + 안드로이드 외부글** = PR #137 (HamBeomJoon `onXX` 콜백 어휘) + PR #35 (`onXxx` 도메인 어휘) 결 합류 누적 3+ PR.
+
+### 7. 함수명 vs 구현부 일치 (Thread 9)
+
+reviewer: *"테스트 코드에서는 \"모든 경우의 카드를 뽑을 수 있다\" 라고 언급이 되어있지만, 구현부는 52장인지 아닌지에 대한 여부를 판단하고 있네요."*
+
+→ **함수명 = 구현 의도 일치** = 누적 14+ PR.
+
+### 8. 테스트 명명 *일부의 가치* 모호 (Thread 10)
+
+reviewer: *"\"일부의 가치\"에서 \"일부\"는 어떤 것을 의미할까요? 어떤 것을 테스트를 하려고 하는지 좀 더 명확하게 작성해보면 어떨까요? 가령, \"ACE가 3장이면 한 장은 11이고 나머지는 1이다\"와 같이 작성할 수 있을 것 같아요."*
+
+→ **테스트 명명 구체성** = PR #109 (BDD given-when-then) 결 합류.
+
+### 9. 커스텀 Deck 테스트 (Thread 4)
+
+reviewer: *"내가 원하는 카드 리스트를 가지고 Deck을 만들 수 있도록 테스트 코드를 작성해보면 어떨까요?"*
+
+→ **Deck DI** = 누적 8+ PR.
+
+## 대표 인용
+
+> [BeokBeok Thread 5]
+> *"가장 큰 차이점은 \"인스턴스화\" 여부도 중요합니다."*
+
+→ **abstract vs open 인스턴스화 어휘**.
+
+> [BeokBeok Thread 8]
+> *"\"다국어\" 지원을 하기 위해서는 View에서 보여주도록 하는 것이 대응하기가 용이합니다."*
+
+→ **다국어 = View 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **abstract vs open 인스턴스화 여부 핵심** = 누적 10+ PR.
+2. **다국어 = View 책임** — **MCP 룰 `i18n-multi-language-as-view-responsibility` 후보**.
+3. **on 전치사 = 콜백 어휘 + 안드로이드 외부글** = 누적 3+ PR.
+4. **companion object import 가독성** — **MCP 룰 `companion-object-import-readability` 후보**.
+5. **함수명 = 구현 의도 일치** = 누적 14+ PR.
+6. **테스트 명명 구체성**.