oh-my-oop 0.2.0

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

@@ -0,0 +1,279 @@
+# PR #76 — [블랙잭 1단계] 서기 미션
+
+- **Reviewee:** [@Yunseok-Nam](https://github.com/Yunseok-Nam)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/76
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 18 스레드 — *PR 본문 자가 의문 3개 + 학생 매우 깊은 양방향 토론 + 팩토리 메서드 vs 부생성자 매우 긴 토론 + 학생 자가 결정 변경*
+- **신규 reviewee** (2024 코호트).
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 3개 + 자가 학습 모범**:
+  1. *"Card클래스에서 테스트의 편의를 위해 팩토리 메서드인 of를 작성하였습니다. 말리빈은 테스트를 위한 팩토리 메서드에 대해서 어떻게 생각하시는지 궁금합니다!!"*
+  2. *"ScoreBoard에서 cardSum을 상태로 가지고 있는데 이때 updateCardSum()을 할때마다 해당 값을 다시 0으로 초기화 해주는 로직이 실행됩니다. cardSum을 따로 저장하지 않고 매번 다시 계산하는 것보다는 낫다고 생각해서 이와같이 구현을 하였습니다. 혹시 더 좋은 방법이 있을 지 궁금합니다!"*
+  3. *"BlackjackGame에서 initCard메서드가 게임 시작 시 딜러와 플레이어에게 2장의 카드를 나누어 주는 기능을 수행합니다. 해당 기능이 controller와 model의 경계에 있는데 model에 조금 더 근접하다 생각되어 이와같이 작성하였습니다. 이것이 맞는 것인지 그렇지 않다면 다른 접근 법이 있는지 궁금합니다"*
+  
+  **PR 본문 자가 의문 3개 모범**. PR #128·#135·#108·#136·#137·#148·#151·#98·#95·#99·#46·#77·#91·#107 결.
+- **`model 이 view 참조 X 근본 이유 자가 학습 (4 단계 메타 질문)`** — 학생 자가 답변:
+
+> *"### 1. model이 view를 참조하지 말아야하는 근본적인 이유는 무엇일까요?*
+> *근본적인 이유는 구성 요소간 결합도를 최소화 함으로써 유지보수성을 높이기 위함이라 생각합니다.*
+>
+> *### 고차함수 방식을 사용하면 어떤 부분이 해결되었나요?*
+> *해당 도메인에서 view를 선언하거나 상태를 가지지 않게 함으로써 직접적으로 view를 참조하지 않을 수 있었습니다.*
+>
+> *### '주입'은 무엇을 해결하기 위한 방법일까요?*
+> *구성요소 간의 직접적인 참조를 피하면서 해당 구성요소의 기능을 사용할 수 있게 하는 방법이라고 생각합니다."*
+
+말리빈 칭찬: *"좋은 답변이네요!!! 👍 고민해보시면서 질문하신 부분들에 대해 조금은 자신만의 생각이 생겨나셨을까요 ?_?"*
+
+학생 자가 학습 명시: *"네넵 🙂 질문에 답을 하기위해 고민을 하다보니 제가 생각한 부분에 대해서 확신이 들었습니다. 예를 들어 위 질문에 대해서는 처음에 그저 model과 view가 참조되어있다는 것이 불편했다면 지금 저의 생각은 BlackjackGame내부에 직접적으로 view인스턴스가 생성된 것이 아닌 주입을 통한 참조가 이루어진 것이므로 이것을 강한 참조라 보기 어렵다입니다. 그러면서 코드의 질과 관계없이 말리빈이 해주신 말씀처럼 저의 코드에 대한 주관이 생긴 것 같습니다!"*
+
+**자가 의문 → 자가 답변 → 자가 학습 가시화 모범** — PR #46·#107·#91·#43 결.
+
+- **`에러 메시지 검증 자가 학습 + reviewer 추가 가치 공유`** — 학생: *"의도대로 에러 메세지가 출력되는지 + 에러메세지가 직접 드러나면서 어떤 것을 테스트 하고 어떤 결과를 원하는 지 파악하기 쉬워진 것 같습니다!"* + 학생 자가 의문: *"혹시 이 밖에 말리빈이 생각하는 에러 메시지 검증을 함으로써 얻을 수 있는 이점이 있는지 궁금합니다!"* + 말리빈: *"하나 더 좋은 점을 공유해드리자면, 같은 종류의 Exception Instance가 throw 되더라도, 에러메시지로 특정 예외를 구분할 수 있겠지요!"*. **학생 자가 의문 → reviewer 추가 가치 공유 모범** — PR #91·#46·#107·#137 결.
+
+## 못한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 — Card 카드 생성 + View 의존 + 팩토리 메서드 양가성
+
+말리빈: *"기호와 숫자를 다른 문자열로도 나타낼 수 있는 요구사항이 추가되면 이 메서드는 어떻게 될까요? 예를 들어, 앞으로 스페이드는 ♤,♠,spade, Spade, 스페이드 등으로도 입력받을 수 있다면 모든 경우를 도메인 로직에서 처리해주어야할까요?"*
+
+학생 자가 의문: *"감이 잘 오지 않네요😢😢😢 하루 정도 고민해보았는데 위에서 하신 질문에 대해서 감이 안잡히네요ㅜ"*
+
+말리빈 자가 부연: *"이런 수많은 문자열에 대해 카드를 찾을 수 있는 모든 경우의 수를 도메인에서 처리하면, 메서드의 길이가 매우 길어질 수 있겠지요. 그런 역할은 Card 도메인 객체가 맡을 역할이 적절할지 고민해보시라는 의미었어요 :) 생성자에서 이미 우리가 원하는 값을 넣어야만 하는 제약을 두었음에도 불구하고, 입력 문자열에 의존해 카드를 찾는다는 것은, 결국 View의 요소에 의존하는 것과 크게 다르지 않아보이네요!"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *학생 자가 *감이 안 잡힘* 명시*
+
+*"감이 잘 오지 않네요😢😢😢 하루 정도 고민해보았는데"* — **학생 자가 학습 갭 명시 + 시간 투자 명시 모범**. PR #95·#107·#16 결.
+
+#### 1.2. *Card.of(String) = View 입력 문자열 의존*
+
+- *학생 코드*: *`Card.of("♠", "10")`* — *View 입력 문자열을 도메인이 받아 변환*.
+- *반박*: *생성자 제약 (CardSuit enum) 으로 충분한데 *문자열 변환* 까지 도메인에 = 책임 누수*.
+
+#### 1.3. *reviewer 자가 부연*
+
+*"질문 의도가 아니었어요"* 류 자가 부연. PR #91·#16·#46·#95·#137·#77 결.
+
+### 2. `팩토리 메서드 vs 부생성자` 매우 긴 토론 — 학생 자가 결정 변경
+
+말리빈: *"부생성자를 활용해보는 건 어떨까요?"*
+
+학생 1차: *"팩토리 메서드를 알기 전에는 위 같은 것들을 부생성자로 처리하곤 했었습니다. 팩토리 메서드를 알게되고 부생성자에 비해 많은 이점을 가지고 있는 팩토리 메서드(의미있는 함수명 가능, 여러 생성자 로직을 깔끔하게 구현..etc)를 사용하는 것이 좋다고 생각되었습니다! 혹시 말리빈이 위 코드에서 어떠한 부분때문에 부생성자 활용을 추천하신건지 궁금합니다! 😄"*
+
+말리빈 메타 질문:
+
+> *"현 코드에서 부 생성자와 팩터리메서드를 동시에 놓고 비교했을때, 1. 생성자를 활용하는 것은 팩터리 메서드의 from을 사용 만큼 이해하기 어려운 생성 방법이었나요? 2. 어떤 부분에서 깔끔한 차이를 보였나요?*
+>
+> *제가 코드를 작성할 때 중요하게 생각하는 것 중에 하나는, '필요에 의해서 추가 및 수정함' 이에요. 이 경우에서 팩터리 메서드가 정말로 필요했었는지 저는 동의하기 어려웠어요.*
+>
+> *다른 개발자들이, 객체를 생성할 때 어떤 제약 조건들이 있는지 보기 위해 가장 먼저 떠올릴 위치는 어디일까요?"*
+
+학생 답변: *"1. 각 메서드 별 객체를 생성하는 특징을 함수명으로 보여줌으로써 부생성자보다는 가독성 면에서 좋다. 2. 부생성자에서 보다는 팩토리 메서드가 어떤 로직이 실행되는지 잘 보여준다는 점에서 깔끔하게 구현할 수 있다."* + *"### 다른 개발자들이, 객체를 생성할 때 어떤 제약 조건들이 있는지 보기 위해 가장 먼저 떠올릴 위치는 어디일까요? 가장 상단에 위치할 init블럭일 것 같습니다!"*
+
+추가: *"앗 그리고 아래와 같이 부생성자로 할 경우 `JVM signature error` 가 발생합니다. dummy implicit을 사용하여 해결할 수 있지만 그것 보다는 팩토리메서드를 사용하는것이 좋다 생각됩니다!"*
+
+말리빈 자가 인정 + 메타 답변:
+
+> *"Template을 활용할 때의 Type erase 떄문에 활용한다는 것에 저도 100% 동의해요!*
+>
+> *> 각 메서드 별 객체를 생성하는 특징을 함수명으로 보여줌으로써 부생성자보다는 가독성 면에서 좋다.*
+>
+> *위 의견이 저에게 와닿지 않았던 생각을 말씀드릴게요 :)*
+>
+> *객체 생성은 생성자를 통해 한다 라는 것이 기본 문법이기에, 팩터리 메서드가 존재함을 알기 위해서는 생성자로의 생성이 막혀있음을 알게 된 다음에나 인식할 수 있다고 생각해요. 생성자가 막혀있지 않다면, 구현을 직접 들어가보지 않는 이상 팩터리 메서드의 존재를 바로 인식하기란 쉽지 않겠지요.*
+>
+> *그리고 `Players.from(List<String>)` 이나, `Players(List<String>)` 이나 , List\<String>으로부터 Players 객체를 생성한다는 의미는 모두 동일하게 의도..."*
+
+학생 자가 결정 변경:
+
+> *"질문에 대해서 고민하고 답을 작성하고 마지막에 해주신 말씀을 보면서 제가 코드를 작성할 때를 생각해보았을 때 팩토리메서드가 그저 좋다라는 것만 생각하고 일단 생성한 다음 의미를 부여한것 같다는 생각이 들었습니다. (...) 특히 위 질문을 보고 고민하면서 다른 사람들의 편의성을 생각하지 않고 저의 편의성을 우선했라는 생각이 많이 들었네요🥲🥲"*
+
+→ **6 가지 학습**:
+
+#### 2.1. *팩토리 메서드 vs 부생성자 양가성*
+
+- **팩토리 메서드 장점** (학생 의견): 의미있는 함수명, 여러 생성자 로직 깔끔.
+- **부생성자 장점** (말리빈 의견): 기본 문법 + 생성자 위치에서 가장 먼저 발견.
+- **JVM Type erase** (학생 자가 인용): `List<T>` 시그니처 충돌 = 팩토리 정공.
+
+#### 2.2. *"필요에 의해서 추가 및 수정함"* — reviewer 메타 어휘
+
+**YAGNI 어휘**. PR #146 (yrsel YAGNI) / PR #107 (junseo511 *abstract class*) / PR #145 (학생 자가 *Manager 폭증*) / PR #31·#77 결.
+
+#### 2.3. *학생 자가 *팩토리 메서드 그저 좋다 생각만* 자가 인정*
+
+*"팩토리메서드가 그저 좋다라는 것만 생각하고 일단 생성한 다음 의미를 부여한것 같다"* — **학생 자가 *과한 추상화 자가 인정* 모범**. PR #146·#107·#145·#31·#77 결.
+
+#### 2.4. *"다른 사람들의 편의성 vs 자기 편의성"* — 메타 어휘
+
+**MCP `oh-my-oop` 의 *유지보수자 시점 메타 어휘* 와 일치**. PR #107 (lee-ji-hoon *유지보수 관점 평가*) 결.
+
+#### 2.5. *부생성자 / 팩터리 메서드 / 생성자 발견 순서*
+
+- *기본 = 생성자 (가장 먼저 보임)*.
+- *부생성자 = 생성자 옆 (자동 발견)*.
+- *팩토리 메서드 = companion object 또는 외부 (생성자 막혀야 인식)*.
+
+**MCP 룰 후보 — `factory-method-discoverability`** = *생성자 미차단 + 팩토리 메서드 = 발견 어려움*.
+
+#### 2.6. *JVM Type erase 회피 시 팩토리 메서드 정공*
+
+- *`Players(playerNames: List<String>)` + `Players(players: List<Player>)`* = JVM 시그니처 충돌.
+- *팩토리 메서드* = *함수명 차이*로 회피.
+
+### 3. `BlackjackGame 대리자 vs 현실 게임 객체` 자가 학습
+
+말리빈: *"이 객체에게 계속 플레이어와 딜러를 넘기면서 게임을 진행해야하네요. 블랙잭 게임을 수행하는 객체라기 보다는, 귀찮은 일들을 대신 수행해주는 대리자의 느낌을 강하게 받았어요. 블랙잭 게임 객체가 현실세계를 모방한 역할을 가지게 만들어보는건 어떨까요?"*
+
+학생: *"BlackjackGame 객체를 실제 게임이 진행되는 공간이라 생각하고 게임 진행이 해당 객체에서 진행되도록 해보겠습니다 😸"*
+
+→ **`대리자` vs `자율 객체`** = *외부에서 *데이터 넘기며* 작업 시키는 객체 = 대리자 (수동) / 자기 데이터 + 자기 책임 수행 객체 = 자율*. **MCP 룰 후보 `proxy-object-anti-pattern`** = *데이터 외부 주입 + 행동 위탁 = 대리자 시그널*. PR #99·#107·#46·#43·#77 결.
+
+### 4. `Controller god-object → 게임 객체 자율성`
+
+말리빈: *"게임 객체에게 무언가를 하라고 일일이 지시하고 있네요! 게임 객체가 자율성을 가지도록 만들어 볼 수 있을까요? 게임 객체에게 게임 시작하라고 하면, 반환 값으로는 게임 결과를 받고, 그것을 출력만 할 수 있도록 구성해보는 건 어떨까요?"*
+
+학생: *"아하 BlackJackGame의 역할을 잘 살렸다고 생각했었는데 말씀하신 것을 보고 생각해보았을 때 결국 controller에서는 게임의 시작과 결과만이 중요하다고 생각되고 나머지 로직은 도메인에서 내부적으로 처리하도록 하는것이 좋다고 생각이 드네요."*
+
+→ **Controller god-object + Tell-Don't-Ask**. PR #99·#107·#43·#46·#77·#9 결.
+
+### 5. `applyReceivedCard` 함수명 = 동작 추론 어려움
+
+말리빈: *"applyReceivedCard메서드 명을 보고, 카드가 들어올 때 점수 계산을 수행하고 있다는 사실을 다른 개발자들도 한 번에 알 수 있을까요?"*
+
+→ **함수명 = 부수 효과 명시**. PR #99·#39·#9 결.
+
+### 6. `DealerResult` 외부 mutableMap 초기화 안티패턴
+
+말리빈: *"객체를 만들고 외부에서 상태를 변화시키는 것 보다, 필요한 컬렉션을 생성자에서 받게끔 구성해보는 건 어떨까요? 현 형태는 DealerResult 객체 자체가 큰 의미를 가지지 못해보여요. 이 객체를 사용하는 쪽에서 mutableMapOf<GameResultType, Int>() 를 직접 생성해서 사용하는 것과 크게 다르지 않아 보이네요. 카운트를 세기 위함이라면, groupingBy, eachcount 등의 확장함수를 적극 활용해보시길 바라요 :)"*
+
+→ **MCP 기존 룰 `empty-object-external-fill`** (lotto 변형). PR #145·#39 결.
+
+### 7. `Card 인스턴스 재활용`
+
+말리빈: *"카드를 생성하는 경우는 얼마나 될까요? 인스턴스를 재활용해볼 수 있을까요?"*
+
+→ **불변 객체 + 재활용**. PR #74·#108·#133·#23·#26·#46·#77·#66 결.
+
+### 8. `Denomination 10 상수 위치`
+
+말리빈: *"이 값의 위치에 대해 더 고민해보는 건 어떨까요? 이 값이 정말로 필요한 객체는 어디였나요?"*
+
+학생: *"처음 설계 시 Ace의 값이 1또는 11이 될 수 있어서 기본 값을 1로 두고 해당 상수를 암묵적으로 11이라 생각하여 Denomination에 위치시켰습니다. 말씀해주신 것을 보고 해당 값이 정말 Denomination에 어울리는가를 고민을 해보았을 때 해당 값(10)이 사실은 카드의 score를 의미한다기 보다는 카드 합계 계산 시 필요한 값의 의미가 더 강하다고 생각이 들었습니다. 그렇다면 해당 값이 있어야 할 곳은 cardSum을 계산하는 곳이라 생각이 드네요."*
+
+→ **상수 위치 = 의미 응집**. **MCP 룰 후보 `constant-locus-meaning-cohesion`**. PR #16·#9·#11·#43·#137·#148 결.
+
+### 9. `4장 21점 = 블랙잭?` 룰 정확성
+
+말리빈: *"카드 4장의 점수의 합이 21이면 이것은 블랙잭인가요?"*
+
+학생: *"카드 2장의 합이 21일때만 블랙잭이라고 하는군요,, 수정하겠습니다!"*
+
+→ **블랙잭 룰 정확성 (2장 21점만 블랙잭)**. PR #26·#46·#16·#23·#66·#107 결.
+
+### 10. `RandomCardProvider 파라미터` 인터페이스 활용 후 불필요
+
+말리빈: *"이미 인터페이스로 랜덤 테스트를 구현할 수 있게끔 구성되어있으니, 파라미터로 카드 목록을 받지 않아도 좋아보이네요!"*
+
+→ **DI 정공 + 추가 파라미터 불필요**. PR #74·#23·#95·#99·#26·#39·#46 결.
+
+### 11. `HandCards` 테스트 부재 + 생성자 초기값
+
+말리빈: *"HandCards에 대한 테스트가 없네요! 모든 도메인 로직에 대해 테스트 코드를 작성해주세요 :) 테스트를 진행할 때, 초기 카드를 addCard를 부르지 않고 생성자로 초기 값을 세팅할 수 있도록 구성해보는 건 어떨까요?"*
+
+→ **TDD 요구사항 + 생성자 초기값**. PR #16·#33·#9·#145 결.
+
+### 12. `Score 직접 꺼내기 vs 메시지`
+
+말리빈: *"점수 계산을 수행할 때, 값을 직접 꺼내지 않고 객체에게 메시지를 던져보는 건 어떨까요?"*
+
+→ **Tell-Don't-Ask**. PR #66·#43·#107·#46·#137·#148 결.
+
+### 13. `에러 메시지 입력값 포함`
+
+말리빈: *"에러메시지에 입력 값이 무엇이었는지도 표시해주는 건 어떨까요? 어떤 장점이 생길 수 있을까요?"*
+
+→ **에러 메시지 입력값 명시**. PR #39·#46 결.
+
+### 14. `companion object 함수 위치` 자가 인정
+
+말리빈: *"이 함수는 생성자에서만 사용하는데, companion object 에 위치시킨 이유가 무엇이었나요 ?_?"*
+
+학생: *"이전에 팩토리 메소드에서도 사용되었어서 동반객체에 위치시켰었는데 리팩토링 후에 신경을 쓰지 못했네요,,🥲🥲"*
+
+→ **리팩토링 후 잔재 자가 인정**. PR #98·#145 결.
+
+### 15. `BlackjackGameTest 하드코딩` 가독성
+
+말리빈: *"테스트 코드를 보는 사람은 이곳에서 잠깐 멈출 것 같아요. 어떤 로직이 실행돼서 어떤 값이 할당이 되는지 머릿속으로 생각하기 위해서요. 읽다가 멈추는 것은 테스트 가독성을 낮추는 점이라 생각해요. 값을 하드코딩해서 넣어주는 건 어떨까요? 또, 생성자를 통해 필요한 초기 값을 넣어주는 방법에 대해서도 고민해보시면 좋겠어요 :)"*
+
+→ **테스트 가독성 = 멈추지 않고 읽기**. **MCP 룰 후보 `test-readability-pause-anti-pattern`**.
+
+### 16. `DenominationTest` 불필요 값 잔재
+
+말리빈: *"이 값은 언제 사용하는 값인가요?"*
+
+학생: *"앗,, Denomination을 리팩토링 하는 과정에서 테스트도 수정하였는데 해당 값도 없애야 했는데 신경쓰지 못했네요,,ㅜ 좀 더 집중해서 리팩토링 진행하겠습니다!!!"*
+
+→ **리팩토링 후 잔재**. 위 §14 결.
+
+## 리뷰어 의견 요지 (말리빈 / malibinYun)
+
+18 코멘트 특징 (PR #23·#39·#46·#74·#95 와 동일 reviewer):
+
+- **메타 질문 다중 (4 단계)** — model-view 참조 X 근본 이유 4 질문 시리즈 → 학생 자가 답변 모범 유도.
+- **`"필요에 의해서 추가 및 수정함"` YAGNI 어휘** — 팩토리 메서드 양가성 토론에서 사용.
+- **`팩토리 메서드 vs 부생성자` 매우 긴 토론** — 학생 자가 결정 변경 모범.
+- **`?_?`, `:)`, `🥲` 친밀한 어조** — PR #95·#23·#46·#74·#39 와 일관.
+- **메타 어휘 (`대리자`, `자율 객체`)** — *"귀찮은 일들을 대신 수행해주는 대리자의 느낌을 강하게 받았어요"* — **대리자 안티패턴 어휘**.
+
+## 대표 인용
+
+> *"감이 잘 오지 않네요😢😢😢 하루 정도 고민해보았는데 위에서 하신 질문에 대해서 감이 안잡히네요ㅜ"* — Yunseok-Nam (학생 자가 *학습 갭 + 시간 투자* 명시)
+
+> *"근본적인 이유는 구성 요소간 결합도를 최소화 함으로써 유지보수성을 높이기 위함이라 생각합니다."* — Yunseok-Nam (model-view 참조 X 근본 이유 자가 학습)
+
+> *"좋은 답변이네요!!! 👍 고민해보시면서 질문하신 부분들에 대해 조금은 자신만의 생각이 생겨나셨을까요 ?_?"* — malibinYun (학생 자가 학습 가시화 인정)
+
+> *"질문에 대해서 고민하고 답을 작성하고 마지막에 해주신 말씀을 보면서 제가 코드를 작성할 때를 생각해보았을 때 팩토리메서드가 그저 좋다라는 것만 생각하고 일단 생성한 다음 의미를 부여한것 같다는 생각이 들었습니다. (...) 특히 위 질문을 보고 고민하면서 다른 사람들의 편의성을 생각하지 않고 저의 편의성을 우선했라는 생각이 많이 들었네요🥲🥲"* — Yunseok-Nam (학생 자가 *과한 추상화 인정* + *유지보수자 시점 메타*)
+
+> *"제가 코드를 작성할 때 중요하게 생각하는 것 중에 하나는, '필요에 의해서 추가 및 수정함' 이에요."* — malibinYun (YAGNI 어휘)
+
+> *"객체를 만들고 외부에서 상태를 변화시키는 것 보다, 필요한 컬렉션을 생성자에서 받게끔 구성해보는 건 어떨까요? 현 형태는 DealerResult 객체 자체가 큰 의미를 가지지 못해보여요."* — malibinYun (empty-object-external-fill 결)
+
+## 얻은 교훈
+
+1. **`팩토리 메서드 vs 부생성자` 양가성** — *팩토리 (의미 명명 + 여러 로직)* vs *부생성자 (기본 문법 + 발견 가능성)*. **MCP 룰 후보 `factory-method-discoverability`** = *생성자 미차단 + 팩토리 = 발견 어려움*.
+
+2. **`"필요에 의해서 추가 및 수정"` (YAGNI 어휘)** — PR #146·#107·#145·#31·#77 결의 *말리빈 어휘 강화*.
+
+3. **`학생 자가 과한 추상화 자가 인정`** — *"팩토리메서드가 그저 좋다라는 것만 생각하고 일단 생성한 다음 의미를 부여한것 같다"* = **MCP 룰 후보 `pattern-applied-without-need`**. PR #146·#39 (rhthrhrl0 *일급 컬렉션 과적용*) / PR #77 (*PointCalculator 분리*) / PR #145 (*Manager 폭증*) / PR #31 (*Builder 패턴 불필요*) 결.
+
+4. **`대리자 (Proxy) vs 자율 객체` 메타 어휘** — *데이터 외부 주입 + 행동 위탁 = 대리자 시그널 / 자기 데이터 + 자기 책임 = 자율 객체*. **MCP 룰 후보 `proxy-object-anti-pattern`**. PR #99·#107·#46 결.
+
+5. **`다른 사람들의 편의성 vs 자기 편의성` 유지보수자 시점** — PR #107 (lee-ji-hoon *유지보수 관점 평가*) 결.
+
+6. **`model-view 참조 X 근본 이유 4 단계 메타 질문`** — *결합도 최소화 + 유지보수성 + 강한 참조 vs 주입 = 자가 학습*. PR #99·#107·#137 결.
+
+7. **`Card.of(String)` View 입력 의존 안티패턴** — *생성자 enum 제약 + 문자열 변환 별도 책임 분리*. **MCP 룰 후보 `domain-object-string-input-leak`**. PR #66·#23·#26 결.
+
+8. **`상수 위치 = 의미 응집`** — *Denomination 10 = 카드 score X / 카드 합계 계산 영역*. **MCP 룰 후보 `constant-locus-meaning-cohesion`**.
+
+9. **`JVM Type erase = 팩토리 메서드 정공 시나리오`** — *`List<T>` 시그니처 충돌*. **MCP 룰 후보 `jvm-type-erase-factory-justification`**.
+
+10. **`외부 mutableMap 초기화 + 외부 채우기 = empty-object-external-fill`** — *MCP 기존 룰 lotto 변형*. PR #145·#39 결.
+
+11. **`테스트 가독성 = 멈추지 않고 읽기`** — *복잡 로직 = 머릿속 계산 강제 = 가독성 ↓*. **MCP 룰 후보 `test-readability-pause-anti-pattern`**.
+
+12. **`학생 자가 *감 안 잡힘* 명시 + 시간 투자`** — *PR 본문 + 코멘트 응답에서 학습 갭 명시 모범*. PR #95·#107·#16 결.
+
+13. **`reviewer 추가 가치 공유` 어휘** — *학생 자가 의문 → reviewer 추가 가치 공유*. *에러 메시지 = 같은 Exception 종류 구별 가능*. PR #91·#46·#107·#137 결.
+
+14. **`PR 본문 자가 의문 3개` = 학습 가시화 모범** — PR #128·#135·#108·#136·#137·#148·#151·#98·#95·#99·#46·#77·#91·#107 결.
+
+15. **`리팩토링 후 잔재` 자가 인정** — *companion object 함수 / Denomination 테스트 값* — *리팩토링 시 *놓친 잔재* 자가 인정*. PR #98 (chaehyuns *_cards.clear()*) / PR #145 결.

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

@@ -0,0 +1,203 @@
+# PR #86 — [블랙잭 2단계] 서기 미션
+
+- **Reviewee:** [@Yunseok-Nam](https://github.com/Yunseok-Nam)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/86
+- **단계:** 2단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 16 스레드 — *data class private constructor + copy() 우회 자가 인정 + 검증 로직 불필요 자가 학습 + HandCards 생성자 초기값 양가성*
+- **양 단계 분석 reviewee** (1단계 #76 별도).
+
+## 잘한 점 (설계 관점)
+
+- **`data class private constructor` 함정 자가 인정** — 말리빈: *"data class의 생성자에 private 를 붙여주셨네요. IDE에서 어떤 경고문이 나오고 있나요? 무엇을 경고하고 있나요?"* + 학생 자가 답변: *"주생성자를 막았더라도 data클래스를 선언하게 되면 자동으로 생긴 `copy()`메서드로 인해 주생성자를 막는게 의미가 없어지네요,, 심지어 굳이 data를 붙일 필요도없었고요,,😮‍💨😮‍💨 만약 생성자를 private으로 한 상황에서 data class의 기능이 필요한 경우 필요한 메서드만(hashCode,equals..etc) 명시적으로 오버라이딩하는 방법을 사용해야겠네요"*. **PR #46·#58 결의 `dataclass-private-constructor-copy-leak` 강화** + 학생 자가 *명시적 오버라이딩* 대안 자가 학습.
+- **`검증 로직 불필요` 자가 학습** — 말리빈: *"이 검증 로직은 실제로 exception이 발생할 수 있는 로직일까요?"* + 학생: *"생각해보니 이미 파라미터로 Denomination, Suite를 넘겨주는 것 자체가 실제 있는 값을 넘겨 준다는 것이네요.. 만약 사용자가 카드를 직접 입력할 수 있도록 기능이 확장 될 경우 View단에서 유효성 검증을 하고 Denomination(혹은 Suite)를 반환해주는 것이 더 자연스러운 것 같네요,, 정리해보면 말리빈이 질문주신 것에 대한 답은 예외가 발생할 수 없는 로직이네요 위 검증 코드는.. 😢"*. **type system 신뢰 = 검증 불필요 자가 학습**. PR #66·#107·#23·#9·#16 의 *경계 입력 검증* 결의 *type 신뢰* 변형.
+- **카드 캐싱 칭찬** — 말리빈: *"카드 인스턴스를 캐싱해주셨네요 👍"*. PR #74·#108·#133·#46·#77·#23·#26 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `blackjackGame.start` 결과 반환
+
+말리빈: *"blackjackGame.start의 결과물로 게임 결과가 반환되도록 구성해보는 건 어떨까요?"*
+
+학생: *"딜러와 플레이어의 결과(2단계에서는 수익률)를 딜러와 플레이어가 가지고 있지 않고 결과 객체가 가지게 하고 게임 결과로 결과객체를 반환하도록 수정해봐야겠네요 💪"*
+
+→ **Controller god-object → 결과 반환**. PR #95·#99·#43·#46·#77·#107·#145 결.
+
+### 2. `Card.from(cardProvider)` vs `cardProvider.provide()` 양가성
+
+말리빈: *"아래코드에서 카드를 한 장 가져오는데, cardProvider만 있어도 충분해보이는데 이렇게 구성하게 된 이유가 궁금해요 :)"*
+
+```kotlin
+val cardProvider: CardProvider = ~~
+val card1 = cardProvider.provide()
+val card2 = Card.from(cardProvider)
+```
+
+학생 자가 정당화: *"만약 Card가 현재 프로덕션에서 사용하고 있는 RandomCardProvider가 아니라 다른 종류의 CardProvider를 사용하고 싶을 경우 `val cardProvider: CardProvider = RandomCardProvider`코드를 수정하기 보다 `from()`메서드의 파라미터를 통해 전략을 수정해주고 싶어서 위와 같이 작성하였습니다!"*
+
+말리빈 반박:
+
+```kotlin
+var cardProvider: CardProvider = RandcomCardProvider()
+val card1 = cardProvider.provide()
+
+cardProvider = OtherCardProvider()
+val card2 = cardProvider.provide()
+```
+
+*"아래 코드 처럼 cardProvider만을 가지고도 충분히, 원하는 'RandomCardProvider가 아니라 다른 종류의 CardProvider를 사용하고 싶을 경우' 를 지킬 수 있어보이네요!"*
+
+→ **3 가지 학습**:
+
+#### 2.1. *Card.from(provider) = 책임 누수*
+
+- *Card 가 *provider 알기* = *Card 가 *생성 전략* 인지*.
+- *학생 의도 = 전략 선택 가능성*. *현실 = `var cardProvider` 변경* 으로 충분.
+
+#### 2.2. *Card 가 provider 의존 = 양방향 의존 위험*
+
+- *학생: Card → CardProvider 의존*.
+- *추가 의존성 = 결합도 증가*.
+
+#### 2.3. *학생 자가 의도 명시 + reviewer 단순 대안 제시*
+
+**MCP 룰 후보 `redundant-factory-with-strategy-parameter`** = *전략 객체 + 정적 팩토리 + 전략 인자 = 중복*.
+
+### 3. `Dealer` 빈 객체 + add → 값 모음 + 한 번 + 불변
+
+말리빈: *"빈 객체를 생성해서 값을 계속 add 하는 형태보다, 값을 모두 모았다가 객체를 생성할 때 한 번에 넣어주고, 해당 객체는 불변하게 변경해보는 건 어떨까요?"*
+
+→ **MCP 기존 룰 `empty-object-external-fill`** 강화. PR #145·#39·#76 결.
+
+### 4. `들여쓰기 규칙`
+
+말리빈: *"들여쓰기 규칙은 꼭 지켜주세요!"*
+
+→ **Kotlin 코딩 컨벤션 (ktlint)**. PR #77·#9·#82 결.
+
+### 5. `companion object` 모든 메서드 위치 자가 학습
+
+말리빈: *"companion object 내의 모든 메서드들은 모두 이곳에 위치해야하나요 ?_?"*
+
+학생: *"`players()`는 부생성자에 쓰기 위해서 companion object내에 위치 시켜 주었고(코드를 작성할 때 해당 메서드를 동반객체 밖에 선언할 경우 컴파일에러가 발생했었습니당) `validatePlayers()`와 `findDuplicatedNames()`메서드 역시 `players()`에 사용되기 위해 companion object내에 위치 시켜주었습니다🔆🔆"*
+
+→ **companion object 사용 기준** = *팩토리 메서드 + 내부 도우미 함수만*. *모든 메서드 위치 강제 X*. **MCP 룰 후보 `companion-object-method-locus`**.
+
+### 6. `테스트용 카드 상수 활용`
+
+말리빈: *"자주 사용하는 테스트용 카드는 상수로 만들어보는 건 어떨까요? 누가 봐도 이것은 하트2 카드구나! 라고 인식할 수 있을 정도로 이름을 지어서요!"*
+
+→ **테스트 픽스처 상수 명명**. PR #99 (s6m1n *Test Fixture 품질*) / PR #91 (murjune *vararg*) / PR #46·#76 결.
+
+### 7. `HandCards` 생성자 초기값 양가성 — 학생 자가 의문
+
+말리빈: *"HandCards 의 생성자로 초기 값을 넣을 수 있게 재구성해보는 건 어떨까요?"*
+
+학생 자가 정당화:
+
+```kotlin
+class HandCards {
+    private val _cards = mutableListOf<Card>()
+    val cards: List<Card>
+        get() = _cards.toList()
+    fun addCard(card: Card) {
+        _cards.add(card)
+    }
+}
+```
+
+*"현재 HandCards에서 생성자로 초기 값을 넣어주려면 주생성자에 cards가 들어가야 하고 그러기 위해서는 카드를 한장씩 add하는 것이 아니라 한번에 넘겨주야 하는데 게임 로직 상 한장씩 넘겨줄 수 밖에 없는 상황이 있는 것 같습니다,,ㅜ"*
+
+말리빈 메타 질문: *"주생성자에 cards가 들어갈때, 이 cards는 반드시 멤버 변수로 동시에 선언되어야할까요?"*
+
+→ **3 가지 학습**:
+
+#### 7.1. *생성자 인자 ≠ 멤버 변수*
+
+- *`class HandCards(cards: List<Card>)` (멤버 X)* — *생성 시 받지만 내부 mutable list 로 변환*.
+- *`class HandCards(val cards: List<Card>)` (멤버 O)* — *외부 노출*.
+
+#### 7.2. *학생 자가 잘못된 가정*
+
+*"주생성자에 cards가 들어가면 자동으로 멤버"* 가정 = *Kotlin 어휘 미숙*.
+
+#### 7.3. *PR #145 와 같은 결*
+
+PR #145 (junseo511 *Hand initialCards 7 단계 토론*) / PR #76 (Yunseok-Nam 1단계 *HandCards 테스트*) 결.
+
+### 8. `equal로 인스턴스 비교` 테스트
+
+말리빈: *"equal로 실제 인스턴스가 같은지도 비교할 수 있을까요? of를 사용하지 않고, 생성자를 public으로 변경한 뒤에, 아래 코드를 실행시키면 테스트는 성공할까요?"*
+
+학생: *"캐싱된 값을 비교하려했는데 그저 값만 비교했네요,, 참조 값이 같은지 테스트하도록 수정하겠습니다^_^"*
+
+→ **참조 vs 값 비교 자가 학습**. *캐싱 검증 = `===` (참조 동일) vs `==` (값 동일)*. **Kotlin 어휘**. PR #46 (krrong *equals & hashcode*) 결.
+
+### 9. `Dealer` Kotlin 컬렉션 체이닝 도전
+
+말리빈: *"이 부분은 다양한 코틀린 컬렉션 확장함수들을 활용해서 메서드 체이닝을 이용해 구성해볼 수 있겠어요 :) 어렵겠지만 꼭 도전해보시면 좋겠어요!"*
+
+→ **함수형 체이닝 어휘**. PR #39·#26·#13 결.
+
+### 10. `Profit 인스턴스 2번 생성`
+
+말리빈: *"dealerProfit, playerProfit을 만들 때 Profit의 인스턴스를 불필요하게 2번씩 생성하고있네요. 1번만 생성하도록 변경해보는 건 어떨까요?"*
+
+→ **불필요 객체 생성**. PR #46·#95 결.
+
+### 11. `GAME_MAX_SCORE` vs *구체적 21 의미*
+
+말리빈: *"GAME_MAX_SCORE 보다는 저 구체적인 21 점수에 대한 의미를 변수명에 녹여보는 건 어떨까요? 21점수만은 특정 룰이라고 할 수 없지만, 그 특정 룰을 만들어내는 한가지의 중요한 요소이니까요!"*
+
+→ **상수 명명 = 도메인 의미 응축**. PR #46·#76 결.
+
+### 12. `GameResultType.BLACKJACK = Win 변형` 로직 표현
+
+말리빈: *"블랙잭은 결국 Win과 다르지 않아보이네요. Blackjack은 로직으로써 표현해봐도 좋겠다는 생각이 드네요 :)"*
+
+→ **enum 분기 = 로직 표현 vs 멤버 추가** 양가성. PR #99·#107 결.
+
+### 13. `assertAll` 활용
+
+말리빈: *"assertAll로 감싸는 것과 아닌 것은 어떤 점이 다를까요?"*
+
+→ **assertAll = 모든 검증 실행 + 실패 시 모두 보고**. PR #23 (멘델 *assertAll 자가 학습*) 결.
+
+### 14. `CsvSource` 활용
+
+말리빈: *"CsvSource를 활용해보는 건 어떨까요?"*
+
+→ **Parameterized Test 어휘**. PR #46·#91 결.
+
+## 리뷰어 의견 요지 (말리빈 / malibinYun)
+
+16 코멘트 특징 (PR #76 와 동일 reviewer):
+
+- **메타 질문 어휘** — *"어떤 경고문이 나오고 있나요?"*, *"이렇게 구성하게 된 이유가 궁금해요"*, *"실제로 exception이 발생할 수 있는 로직일까요?"* — 학생 자가 답변 유도.
+- **`?_?`, `😮‍💨`, `🔆`, `^_^` 친밀한 이모지** — PR #76 일관.
+- **양방향 대안 코드 제시** — *Card.from(provider) vs var cardProvider 변경* 코드 직접 첨부.
+- **PR #76 와 동일 분량/스타일**.
+
+## 대표 인용
+
+> *"주생성자를 막았더라도 data클래스를 선언하게 되면 자동으로 생긴 copy()메서드로 인해 주생성자를 막는게 의미가 없어지네요,, 심지어 굳이 data를 붙일 필요도없었고요,,😮‍💨😮‍💨"* — Yunseok-Nam (data class private constructor + copy() 우회 자가 인정)
+
+> *"생각해보니 이미 파라미터로 Denomination, Suite를 넘겨주는 것 자체가 실제 있는 값을 넘겨 준다는 것이네요.. (...) 정리해보면 말리빈이 질문주신 것에 대한 답은 예외가 발생할 수 없는 로직이네요 위 검증 코드는.. 😢"* — Yunseok-Nam (type system 신뢰 자가 학습)
+
+## 얻은 교훈
+
+1. **`data class private constructor + copy() 우회`** 강화 — PR #46·#58·#76 결.
+
+2. **`type system 신뢰 = 검증 불필요`** — *enum/sealed 등 type 으로 제약 + 추가 검증 = 중복*. **MCP 룰 후보 `redundant-validation-on-type-constraint`**.
+
+3. **`redundant-factory-with-strategy-parameter`** — *Card.from(provider) = 정적 팩토리 + 전략 인자 = 중복*.
+
+4. **`companion-object-method-locus`** — *팩토리 + 내부 도우미만 / 모든 메서드 강제 X*.
+
+5. **`생성자 인자 ≠ 멤버 변수`** Kotlin 어휘 학생 자가 학습 갭. PR #145 결.
+
+6. **`참조 vs 값 비교`** 테스트 (`===` vs `==`). PR #46 결.
+
+7. **`상수 명명 = 도메인 의미 응축`** (GAME_MAX_SCORE → BLACKJACK_TARGET). PR #46·#76 결.
+
+8. **`empty-object-external-fill`** Dealer 변형. PR #145·#39·#76 결.