oh-my-oop 0.2.0

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

@@ -0,0 +1,220 @@
+# PR #67 — [블랙잭 1단계] 빙티 미션
+
+- **Reviewee:** [@s6m1n](https://github.com/s6m1n)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/67
+- **단계:** 1단계
+- **리뷰어:** @KwonDae — **신규 reviewer**
+- **라인 코멘트:** 24 스레드 — *DealingShoe 자가 학습 + initFrom/hitFrom 자가 토론 + 참가자 vs 참가자 추상화*
+
+## 잘한 점 (설계 관점)
+
+- **`DealingShoe` 책임 분리 자가 학습** — KwonDae 진단: *"내용을 보면 player와 dealer가 각자 카드를 뽑는 행위들인데, 카드를 뽑으라고 명령을 하는곳이 DealingShoe 도메인 로직에서 Participant의 확장함수를 만들며 이곳에서 이루어져야 하는지에 대해 조금 의문이 들어요🧐. DealingShoe 는 카드덱으로서 카드를 관리하고, 덱의 카드에서 참가자들에게 카드를 주는것까지가 카드덱으로서의 역할이 아닌가 하는 생각이 들었습니다. `참가자들에게 본인의 상태가 어찌됐든 관심없고! 일단 게임은 시작했으니 알아서 뽑아라` 라는 메세지를 던져보도록 하는건 어떨까요? 현실세계 블랙잭 게임에서도 딜러가 카드덱에서 카드를 뽑고, 플레이어들도 카드를 가져옵니다(물론 규칙상 딜러가 DealingShoe에서 카드를 가져오지만 참가자(딜러)가 버튼을 눌렀기에 DealingShoe가 카드를 내보내겠죠?)"* + 학생 자가 답변: *"DealingShoe가 게임 흐름을 알고 있을 필요는 없으며, 마찬가지로 뽑은 카드를 어떻게 할 건지 몰라도 된다는 의견에 동의합니다! ... initGame, giveCardTo 메서드를 각각 Participant의 내부 메서드 initFrom, hitFrom로 수정해봤습니다."*. **현실 메타포 (DealingShoe = 카드 내보내기, Participant = 가져가기) 자가 학습 모범**. PR #146·#74·#41 와 같은 결.
+- **`Default Arguments` Kotlin 어휘 자가 학습** — 학생 자가 의문: *"여기서 의문점이, initFrom메서드는 hitFrom와 같은 addCard를 수행하며 단지 2장을 뽑기 위해 한 번 더 반복할 뿐입니다. 이렇게 횟수만 다른 코드를 별도의 함수로 구현해주는 게 괜찮은지 궁금합니다!"* + KwonDae: *"중복되는 코드가 반복이 되는 부분에 대해서는 기본적으로 `dealingShoe.pickCard()` 시 한장의 카드를 가져오지만, [Default-arguments](https://kotlinlang.org/docs/functions.html#default-arguments) 를 통해서 몇장 가져올 지 optional로 열어준다면 중복코드를 방지할 수 있을까요?"* + 학생: *"default arguments를 알고 있었는데도 미처 떠올리지 못했네요😅 중복 코드 해결에 대한 좋은 아이디어 주셔서 감사합니다!!"*. **Kotlin 어휘 + 중복 제거 학습 모범**.
+- **`Participant 추상클래스 + 공통 로직` 자가 적용** — KwonDae 칭찬: *"공통으로 활용될 추상클래스 활용을 잘 해주셨네요!💯"* + *"플레이어인지, 딜러인지 관심없이 더 뽑을 수 있는지에 대해 추상클래스를 활용하여 잘 구현해주셨네요💯"*. PR #49·#108·#133·#132·#136·#74 와 같은 결.
+- **`participant vs participant` 자가 토론** — KwonDae 진단: *"승부를 판단하는 로직을 참가자 객체가 스스로하게끔 할 수 있을까요? 즉, 플레이어와 딜러 구분 없이 Participant 자체가 다른 Participant와 비교하여 판단할 수 있지 않을까요? `abstract class Participant { fun judge(otherParticipant: Participant): Result { ... } }`"* + 학생 자가 답변: *"코멘트를 읽고 현 구조와 제시해주신 구조를 비교해보고자 승패를 판정하는 로직을 Participant 내부로 옮기는 시도를 했습니다. 그러나 Participant에서 승부를 판단해준다면 버스트 된 게 플레이어인지 딜러인지 구별할 수 없어 case2를 깔끔하게 처리할 수 없다는 생각이 들어, 결국 Participant 대신 Dealer의 책임으로 옮겨보았습니다."* + 후속 KwonDae: *"한번 더 나아가서, 추상클래스인 Participant 에서 공통 로직을 함수화하여 해당 함수를 [super](https://kotlinlang.org/docs/inheritance.html#calling-the-superclass-implementation) 키워드를 활용하여 딜러와 플레이어간 차이나는 로직 Participant를 상속하는 각 클래스에서 처리할 수 있습니다."* + 학생 자가 답변: *"수정 전에는 dealer만 judge 메서드를 갖고 있고, 플레이어를 기준으로 이겼는지 졌는지 판단하고 있었습니다. 그래서 dealerStatistics를 구하려면 GameStatistics객체에서 playerStatistics 결과를 반전시켜야 했는데, 제시해주신 방법을 사용하니 딜러와 플레이어가 자신의 판단 로직을 이용해 각자의 결과를 스스로 구할 수 있게 되었습니다!"*. **`super` 키워드 + abstract 다형성 + 참가자 vs 참가자 정공 자가 학습 모범**. PR #148·#151·#49·#132·#136·#70 와 같은 결.
+- **방어적 복사 자가 적용** — KwonDae 칭찬: *"일급컬렉션을 불변객체를 활용해 잘 구현해주셨네요!👍 혹시 프로퍼티를 또다른 멤버변수에게 값을 복사해서 선언해준 이유가 있을까요?"* + 학생 자가 답변: *"DealingShoe에 들어온 프로퍼티를 그대로 사용하면 같은 주소를 참조하기 때문에, 밖에서 변경이 일어났을 때 내부의 값도 영향을 받을 수 있다고 생각했습니다. 따라서 toList로 방어적 복사를 진행해보았습니다!"* + KwonDae: *"현재 Card는 불변객체입니다. 또한, DealingShoe를 초기화할 때 주입하는 컬렉션도 [Read-Only](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-list/#list)로 변경이 불가합니다."*. **Kotlin `List` Read-Only + Card 불변 = 방어적 복사 비용 없음 자가 학습**. PR #137·#148·#85·#124 와 같은 결.
+- **`InputView` raw 의도 표현 자가 토론** — KwonDae 진단: *"InputView는 입력을 받거나 모델로 가공하여 Controller에게 넘기는 것이 주 역할인데요, 이러한 문자열에 대해 판단하는 로직은 어디의 역할에 가깝다고 생각하시나요?"* + 학생 자가 답변: *"문자열 판단은 InputView(뷰)의 역할이라고 생각합니다! 가령, 콘솔이 아닌 안드로이드에서라면 \"카드를 더 뽑으시겠습니까?\"라는 메시지와 터치 가능한 예/아니오 버튼이 존재할 것입니다. 게임 컨트롤러를 사용한다면 조이콘을 움직이거나 물리키를 눌러 선택할 수도 있습니다. 이처럼 다양한 방식으로 hit 여부에 대한 입력이 들어올 수 있는데, 이는 각각의 외부 라이브러리에 종속되고 Controller에서 이 모든 방법을 처리해줄 순 없기에 뷰에서 Boolean으로 가공해 넘겨주어야 한다는 생각입니다. 뿐만 아니라 추후 y/n가 아닌 YES/NO로 UI로직이 변경된다면 이것 또한 뷰에서 수정하는 것이 자연스럽다고 생각합니다!"*. **View 가 사용자 의도 표현 (PR #132 페로로 진단) 와 같은 결의 학생 자가 정확 인식 모범**.
+- **테스트 Fixture 자가 학습 + 한글 명명 결정** — KwonDae 추천 + 글 공유 + 학생 자가 결정: *"`BeforeEach`를 이용해 중복 되는 코드를 제거하고 상수를 추가해 테스트의 가독성을 향상시킬 수 있었습니다! 공유해주신 글을 비롯해 BeforeEach 어노테이션이 붙은 test fixture 메소드 명을 setUp이라고 지은 코드가 많던데, 일반 테스트 메서드처럼 구체적인 한글로 적는 게 더 이해하기 쉬울 것 같아 `모든 테스트에 딜러와 플레이어 한 명이 참가하며, 딜러는 3하트 카드를 갖도록 세팅한다` 라고 써보았습니다. 괜찮은 방법인지 궁금합니다..!"*. **테스트 Fixture + 한글 명명 자가 학습**.
+- **카드 부족 시 try-catch 처리 자가 반영** — KwonDae 진단: *"예를 들어 한 테이블에 30명의 참가자가 있는 상태에서 게임을 하다보면 카드가 부족해 게임을 진행할 수 없는 상황이 생길 수 있겠네요..!"* + 학생: *"컨트롤러에서 내부적으로 pickCard가 사용되는 메서드들을 try-catch로 감싸, 예외가 던져지면 게임을 종료하도록 수정했습니다!"*. PR #108·#133·#136·#41·#53 와 같은 결.
+- **`runCatching` Kotlin 어휘 권고** — KwonDae 진단: *"kotlin 에서 제공하는 runCatching을 활용해볼까요? 또한, 로또미션에서 배웠던 오류에 대한 처리방법들을 적용해볼 수 있겠네요!"*. PR #148 와 같은 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `ktlint 깨짐` — *PR 위생*
+
+KwonDae: *"ktlint 확인해주세요👍"*
+
+→ **린트 = PR 위생**. PR #148·#147 와 같은 결의 *PR 위생 부족*.
+
+### 2. `deck = init 블록 초기화` 불필요
+
+KwonDae: *"deck을 init에서 초기화 해주는 이유가 있을까요?"* + 학생: *"deck을 굳이 init 블럭 안에서 초기화 해 준 특별한 이유는 없습니다! 초기화 로직이 복잡하지 않고 한 줄로 끝나기 때문에 프로퍼티 선언시 진행해주어도 무방할 것 같다는 생각이 드네요..ㅎㅎ"*
+
+→ **프로퍼티 선언 vs init 블록 초기화 트레이드오프**. *간단한 초기화 = 프로퍼티 선언*. *복잡한 로직 = init 블록*. Kotlin 어휘 정공.
+
+### 3. `CardNumber` 한글 멤버 = 도메인 누수
+
+KwonDae: *"일관성있게 영단어로 통일해주면 어떨까요?"* + 학생 자가 답변: *"출력 형식을 쉽게 맞추기 위해 요구사항에 명시된 텍스트를 Enum class의 name에 넣어버렸는데, 도메인 모델은 UI 로직을 몰라야 한다는 것을 간과했네요..😂 이 부분은 OutputView에 확장함수 format을 구현하는 방향으로 수정하였습니다!"*
+
+→ **enum 멤버 = 한글 직접 (도메인 누수)**. *enum 멤버 = 영문 식별자 + View 매핑 분리*. PR #75·#124·#28·#78 와 같은 결.
+
+### 4. `GameResult.승/무/패` UI 로직 = OutputView 확장함수 분리
+
+KwonDae: *"'승', '무', '패' 는 출력될 때 사용되는 UI 로직입니다. 도메인에서는 어떻게 다루어야 할까요?"* + 학생: *"해당 부분도 마찬가지로 OutputView에서 확장함수 format을 구현하는 방향으로 수정해보았습니다!"*
+
+→ **`Extension function .format()` Kotlin 어휘 활용 정공**. *View 분리 + 도메인 청결성*. PR #146·#137 와 같은 결.
+
+### 5. `Deck.count` 파라미터 + Default value = 카드 부족 회피 시도
+
+KwonDae 진단: *"여기서 count는 어떤 역할을 하는 파라미터일까요? card를 내부적으로 생성하는 대신, 생성자로 받으면 테스트가 가능한 구조가 될 것 같네요"*
+
+학생 자가 답변: *"count는 게임 플레이에 사용되는 카드 덱의 갯수입니다. default값을 1로 설정해 기본적으로 한 개의 덱으로 플레이하도록 했습니다! 다만 요구사항에서 인원수를 제한하지 않은 만큼, 극단적으로 많은 참가자(ex. 22명)가 있다면 1개의 덱으론 정상적인 플레이가 부족할 것 같다고 생각했습니다. 아래는 게임에 참여하는 플레이어 수가 늘어났을 때 중간에 카드가 다 떨어지는 것을 방지하고자 저와 페어가 생각해낸 방법입니다. - 추후, 사용자 수에 따라 적절한 덱의 갯수를 계산하여 덱 생성 시 전달해주는 기능의 확장성을 열어놓자! (Deck 클래스 생성자). - 52개의 카드를 모두 뽑으면 인덱스를 0으로 되돌리고 카드를 다시 섞자! (pick 메서드). 어떤 게 더 좋은 방법인지에 대한 판단이 서지 않아 우선 두가지 모두를 구현해두었습니다."*
+
+→ **카드 부족 시나리오 = 두 가지 시도 (multi-deck + 무한 셔플) 양립 = YAGNI 위반**. *한 가지 결정 + 후속 확장*이 정공. PR #146 의 *INITIAL_HAND_OUT_CARD_COUNT* 와 같은 결의 *학생 자가 인식*.
+
+### 6. `Deck.shuffle()` 테스트 불가능 → 외부 주입 자가 반영
+
+KwonDae: *"shuffle()이라는 내부에서 갖는 랜덤요소로 인해 해당 로직 테스트가 불가합니다."* + 학생: *"shuffle된 카드 리스트를 밖에서 생성해 파라미터에 전달해주도록 수정했습니다!"*
+
+→ **랜덤 = 외부 주입 + 테스트 가능**. PR #108·#133·#136 (ShuffleStrategy) / PR #146 와 같은 결.
+
+### 7. `productNumberAndSuit` 메서드 + 반환 타입 명시
+
+KwonDae 진단: *"보통 변수와 함수가 어떤 값을 가져오는지 알려면 type을 확인하는게 가장 보편적입니다. 지금은 type 명시가 되어 있지 않아 내부 코드를 봐야 어떤 type을 반환하는지 알 수 있습니다. 명시적으로 type을 선언해주는게 어떨까요?"*
+
+학생 자가 답변: *"리뷰어님 의견에 동의합니다! 제가 짠 코드인데도 productNumberAndSuit의 반환값이 한 눈에 들어오지 않네요.. 해당 메서드에서 반환값을 명시하도록 수정했습니다ㅎㅎ 더불어, productNumberAndSuit라는 메서드명 또한 명확하지 않다고 느껴져 combineCardSymbol로 바꿔보았습니다!"*
+
+→ **메서드 반환 타입 명시 + 명확한 메서드명 자가 학습**. PR #108·#137·#75·#70 와 같은 결.
+
+### 8. `GameStatistics 객체 역할 모호` — 자가 학습 진행
+
+KwonDae: *"이제 GameStatistics의 역할이 굉장히 가벼워졌습니다. 현재 이 객체의 역할은 무엇일까요? 단순 Controller로 부터 명단을 받아와 객체에게 명령을 전달하는? 그런 역할을 하는것으로 보이는데요. 이 객체 없이도 player, dealer 스스로 판단결과를 받아와 Controller <-> Participant(player, dealer) 간 주고받을 수 있게 개선을 해볼 수 있을까요?"*
+
+→ **객체 역할 = 단순 명령 전달 = 의미 부재**. *Participant 자체 메시지로 충분*. PR #75·#146·#147 와 같은 결의 *불필요한 중간 객체 자가 인식*.
+
+### 9. `DealingShoe.initGame` 책임 모호 → Participant.initFrom 자가 이전
+
+KwonDae 진단 (위 잘한 점 §1 참고).
+
+### 10. `initFrom` + `hitFrom` 중복 메서드 = default arguments 권고
+
+(잘한 점 §2 참고).
+
+### 11. `GameStatistics judge dealerStatistics 결과 반전` → super + abstract 다형성
+
+(잘한 점 §4 참고).
+
+### 12. `pickCard` 반환 카드 = `getCard` 의도 명확화 권고
+
+KwonDae 진단: *"'덱에 특정 카드가 남아있을 때, draw시 해당 카드가 나와야 한다' 테스트도 진행해주세요👏"*
+
+→ **테스트 명세 정확성**. PR #137·#90·#136 와 같은 결.
+
+### 13. `pickCard 의 카드 부족 → IllegalStateException` 처리 vs try-catch wrapper
+
+학생 자가 반영: *"컨트롤러에서 내부적으로 pickCard가 사용되는 메서드들을 try-catch로 감싸, 예외가 던져지면 게임을 종료하도록 수정했습니다!"*
+
+→ **`runCatching` Kotlin 어휘 권고 (KwonDae 후속)**. *try-catch 명령형 vs runCatching 함수형*. PR #148·#147 와 같은 결.
+
+### 14. `BeforeEach setUp` 한글 명명 = 일반적 vs 명시적 트레이드오프
+
+학생 자가 의문 + KwonDae 답변: *"가독성을 해치지 않는다면 저는 괜찮다고 생각합니다! 다만 아래와 같이도 가능하겠네요 ```kotlin @BeforeEach fun setUp() { player = Player(\"빙티\"); dealer = createDealer(ThreeWithHeart) } ```"*
+
+→ **테스트 fixture 명명 = 학생 자가 결정 + reviewer 양방향 인정 모범**. *한글 = 의도 명시 / setUp = 관행 어휘*. *둘 다 합리*. PR #70·#90 와 같은 결.
+
+### 15. `Card 캐싱 + 외부 인스턴스 차단 권고 부재` — *Card private constructor 권고*
+
+(코드 미공개 — 추정). PR #32·#74·#75·#137·#146 와 같은 결의 *Card 캐싱 + private constructor*.
+
+### 16. `DealingShoe` 테스트가 *DealingShoe 가 아닌 Participant 책임* 자가 학습
+
+KwonDae 진단: *"dealingShoe가 게임을 초기화하는게 맞을까요?_? 이 테스트는 ParticipantTest 에 해당하는 테스트가 아닐까 생각이 드네요"* + 학생: *"게임 초기화에 관한 흐름은 컨트롤러의 initParticipantsCard 메서드에서 진행해주고, pickCard 메서드를 통해 각 참가자들이 스스로 dealingShoe에서 카드를 뽑아오도록 수정했습니다! 이에 따라 위 테스트도 각각 Dealer, Player 클래스의 `딜러가 초기 카드를 2장 가져온다`, `플레이어가 초기 카드를 2장 가져온다`로 변경했습니다."*
+
+→ **테스트 위치 = 책임 위치 일치**. *DealingShoe 테스트 = 카드 관리 + Participant 테스트 = 카드 받기*. PR #137·#90 와 같은 결.
+
+## 리뷰어 의견 요지
+
+- **DealingShoe = 카드 관리 + 참가자 = 카드 받기** (현실 메타포 명료).
+- **Default arguments = 중복 제거 + Kotlin 어휘**.
+- **참가자 vs 참가자 추상화 + `super` 키워드 + abstract 다형성** = 정공.
+- **방어적 복사 = Card 불변 + List Read-Only 시 비용 없음**.
+- **InputView = 사용자 의도 표현 (Multi-platform UI 고려)** — *학생 자가 정확 인식 모범*.
+- **enum 한글 = 도메인 누수 + Extension function 분리**.
+- **카드 부족 = try-catch / runCatching**.
+- **테스트 fixture 한글 명명 vs setUp 관행** 양방향 인정.
+- **테스트 위치 = 책임 위치 일치**.
+- **shuffle = 외부 주입 + 테스트 가능**.
+
+## 대표 인용
+
+**KwonDae (DealingShoe 현실 메타포, DealingShoe.kt):**
+> 내용을 보면 player와 dealer가 각자 카드를 뽑는 행위들인데, 카드를 뽑으라고 명령을 하는곳이 DealingShoe 도메인 로직에서 Participant의 확장함수를 만들며 이곳에서 이루어져야 하는지에 대해 조금 의문이 들어요 🧐
+>
+> DealingShoe 는 카드덱으로서 카드를 관리하고, 덱의 카드에서 참가자들에게 카드를 주는것까지가 카드덱으로서의 역할이 아닌가 하는 생각이 들었습니다.
+> `참가자들에게 본인의 상태가 어찌됐든 관심없고! 일단 게임은 시작했으니 알아서 뽑아라` 라는 메세지를 던져보도록 하는건 어떨까요?
+> 현실세계 블랙잭 게임에서도 딜러가 카드덱에서 카드를 뽑고, 플레이어들도 카드를 가져옵니다(물론 규칙상 딜러가 DealingShoe에서 카드를 가져오지만 참가자(딜러)가 버튼을 눌렀기에 DealingShoe가 카드를 내보내겠죠?)
+
+**KwonDae (Default Arguments, DealingShoe.kt):**
+> 중복되는 코드가 반복이 되는 부분에 대해서는 기본적으로 `dealingShoe.pickCard()` 시 한장의 카드를 가져오지만, [Default-arguments](https://kotlinlang.org/docs/functions.html#default-arguments) 를 통해서 몇장 가져올 지 optional로 열어준다면 중복코드를 방지할 수 있을까요?
+
+**KwonDae (참가자 vs 참가자 + super 키워드, Dealer.kt):**
+> 한번 더 나아가서, 추상클래스인 Participant 에서 공통 로직을 함수화하여 해당 함수를 [super](https://kotlinlang.org/docs/inheritance.html#calling-the-superclass-implementation) 키워드를 활용하여 딜러와 플레이어간 차이나는 로직 Participant를 상속하는 각 클래스에서 처리할 수 있습니다.
+>
+> 그렇다면 참가자 객체 자체가 스스로 다른 참가자와의 승패를 결정할 수 있게되어 `GameStatistics` 객체에 의존하지 않아도 되도록 한번 고민해볼까요?
+
+**KwonDae (Card 불변 + List Read-Only, DealingShoe.kt:4):**
+> 현재 Card는 불변객체입니다.
+> ```kotlin
+> data class Card(val cardNumber: CardNumber, val suit: Suit)
+>
+> class Controller(cards: List<Card>) {
+>     private val dealingShoe = DealingShoe(cards)
+> ```
+>
+> 또한, DealingShoe를 초기화할 때 주입하는 컬렉션도 [Read-Only](...)로 변경이 불가합니다.
+
+**학생 자가 학습 (View 사용자 의도 표현 자가 정확 인식, InputView.kt:17):**
+> 문자열 판단은 InputView(뷰)의 역할이라고 생각합니다!
+> 가령, 콘솔이 아닌 안드로이드에서라면 "카드를 더 뽑으시겠습니까?"라는 메시지와 터치 가능한 예/아니오 버튼이 존재할 것입니다.
+> 게임 컨트롤러를 사용한다면 조이콘을 움직이거나 물리키를 눌러 선택할 수도 있습니다.
+> 이처럼 다양한 방식으로 hit 여부에 대한 입력이 들어올 수 있는데, 이는 각각의 외부 라이브러리에 종속되고 Controller에서 이 모든 방법을 처리해줄 순 없기에 뷰에서 Boolean으로 가공해 넘겨주어야 한다는 생각입니다.
+> 뿐만 아니라 추후 y/n가 아닌 YES/NO로 UI로직이 변경된다면 이것 또한 뷰에서 수정하는 것이 자연스럽다고 생각합니다!
+
+**학생 자가 학습 (DealingShoe 자가 결정 + 의문, DealingShoe.kt):**
+> DealingShoe가 게임 흐름을 알고 있을 필요는 없으며, 마찬가지로 뽑은 카드를 어떻게 할 건지 몰라도 된다는 의견에 동의합니다!
+> 말씀하신대로 DealingShoe는 플레이에 사용되는 카드덱을 상태로 갖고 카드를 건네 주기만 하는 것이 훨씬 자연스럽다고 느껴지네요👍
+>
+> `initGame(카드를 2장씩 나눠줘 게임을 초기화한다)`, `giveCardTo(플레이어에게 카드를 1장씩 나눠준다)` 메서드를 각각 Participant의 내부 메서드 `initFrom`, `hitFrom`로 수정해봤습니다.
+>
+> 여기서 의문점이, initFrom메서드는 hitFrom와 같은 addCard를 수행하며 단지 2장을 뽑기 위해 한 번 더 반복할 뿐입니다.
+> 이렇게 횟수만 다른 코드를 별도의 함수로 구현해주는 게 괜찮은지 궁금합니다!
+
+**학생 자가 학습 (참가자 vs 참가자 시도 후 case2 함정 인식, GameStatistics.kt):**
+> 저와 페어는 과제 요구사항에 블랙잭 규칙이 자세히 명시되어있지 않아 실제 블랙잭 게임의 규칙을 참고해 코드를 작성했습니다!
+> `case1` : 플레이어 **생존**, 딜러 **버스트** -> 플레이어 승
+> `case2` : 플레이어 **버스트**, 딜러 **버스트** -> 딜러 승
+> `case3` : 플레이어 **버스트**, 딜러 **생존** -> 딜러 승
+> 그 중에는 위 처럼 플레이어가 버스트됐을 경우에 **딜러의 버스트 여부에 상관 없이 플레이어가 무조건 패배**하게 된다는 규칙이 있었습니다.
+> 이를 반영하려면 승부를 판단할 때 플레이어와 딜러를 구별할 필요가 있다고 생각해 GameStatistics라는 객체를 만들었습니다.
+>
+> 코멘트를 읽고 현 구조와 제시해주신 구조를 비교해보고자 승패를 판정하는 로직을 Participant 내부로 옮기는 시도를 했습니다.
+> 그러나 Participant에서 승부를 판단해준다면 버스트 된 게 플레이어인지 딜러인지 구별할 수 없어 case2를 깔끔하게 처리할 수 없다는 생각이 들어, 결국 Participant 대신 Dealer의 책임으로 옮겨보았습니다.
+
+**학생 자가 학습 (super 키워드 활용, GameStatistics.kt):**
+> 수정 전에는 dealer만 judge 메서드를 갖고 있고, 플레이어를 기준으로 이겼는지 졌는지 판단하고 있었습니다.
+> 그래서 dealerStatistics를 구하려면 GameStatistics객체에서 playerStatistics 결과를 반전시켜야 했는데,
+> 제시해주신 방법을 사용하니 딜러와 플레이어가 자신의 판단 로직을 이용해 각자의 결과를 스스로 구할 수 있게 되었습니다!
+
+## 얻은 교훈
+
+1. ***DealingShoe = 카드 관리 (현실 메타포) + Participant = 카드 받기 (스스로 뽑아라)***. *책임 분리 = 도메인 정합*. **MCP 룰 후보 — `dealer-as-card-supplier-only`**. PR #146·#74·#41·#75 와 같은 결.
+
+2. ***Default Arguments = Kotlin 중복 제거 어휘***. *`pickCard(count: Int = 1)`* 한 메서드 + *2장 / 1장 호출 시 인자 전달*. PR #146·#148 와 같은 결.
+
+3. ***참가자 vs 참가자 + `super` 키워드 + abstract 다형성 = 정공***. *Dealer-only judge → Participant.judge(other) + super 활용 + 자식 차이 처리*. PR #148·#151·#49·#132·#136·#70 와 같은 결.
+
+4. ***`super` 키워드 = 부모 공통 로직 호출 + 자식 차이만 추가*** = Kotlin 어휘. PR #137·#136 와 같은 결.
+
+5. ***Card 불변 + List Read-Only = 방어적 복사 비용 없음*** = *Kotlin 컬렉션 어휘 (Read-Only 표준)*. PR #137·#148·#85·#124 와 같은 결의 *학생 자가 학습*.
+
+6. ***View = 사용자 의도 표현 (Multi-platform UI 고려)*** = *학생 자가 정확 인식 모범*. *PR #132 페로로 진단 (GraphicsInputView 예시)* 와 같은 결의 학생 자가 도출.
+
+7. ***enum 한글 멤버 = 도메인 누수 + Extension function 분리***. *`.format()` Kotlin 어휘 활용*. PR #75·#124·#28·#78·#146 와 같은 결.
+
+8. ***카드 부족 시나리오 = multi-deck / 무한 셔플 / try-catch / runCatching*** 다양한 트레이드오프. *YAGNI 위반 = 두 가지 동시 구현*. PR #146 와 같은 결.
+
+9. ***Deck.shuffle 외부 주입 = 테스트 가능***. *PR #108·#133·#136 의 ShuffleStrategy* 와 같은 결.
+
+10. ***반환 타입 명시 + 명확한 메서드명 (productNumberAndSuit → combineCardSymbol) 자가 학습***. PR #108·#137·#75·#70 와 같은 결의 *Effective Kotlin Item 4/14*.
+
+11. ***`runCatching` Kotlin 어휘 = 함수형 에러 처리***. *try-catch 명령형 대안*. PR #148·#147 와 같은 결.
+
+12. ***GameStatistics 단순 명령 전달 = 의미 부재 → 객체 제거 + Participant 자기 메시지***. *불필요한 중간 객체 자가 인식*. PR #75·#146·#147 와 같은 결.
+
+13. ***`BeforeEach` fixture 한글 명명 vs setUp 관행 트레이드오프*** — *학생 결정 + reviewer 양방향 인정 모범*. PR #70·#90 와 같은 결.
+
+14. ***테스트 위치 = 책임 위치 일치***. *DealingShoe 테스트 → Participant 테스트* 자가 이전. *책임 분리 = 테스트 분리*. PR #137·#90 와 같은 결.
+
+15. ***신규 reviewer KwonDae = Kotlin 어휘 (super, Default Arguments, runCatching) + Read-Only 컬렉션 강조***. *외부 자료 (Kotlin 공식 문서) 링크 풍부 + 학습 가이드 명료*. *말리빈·페로로·두루·잭슨·지훈·크롱 외 신규 reviewer 스타일 추가*.
+
+16. ***학생 자가 학습 + 자가 토론 + reviewer 양방향 인정 = 학습 가시화***. *DealingShoe 책임 + Default Arguments + super 키워드 + View 의도 표현 + 카드 부족 시나리오 모두 자가 학습 + 후속 반영*. PR #146·#148·#151·#137·#41·#74 와 같은 결.

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

@@ -0,0 +1,229 @@
+# PR #99 — [블랙잭 2단계] 빙티 미션
+
+- **Reviewee:** [@s6m1n](https://github.com/s6m1n)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/99
+- **단계:** 2단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 12 스레드 + **PR 본문 자가 의문 2개** + **1단계 코멘트 URL 자가 참조** + **의존 다이어그램 첨부**
+- **양 단계 분석 reviewee** (1단계 #67 별도)
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 의존 다이어그램 + 4개 변경사항 + 2개 자가 의문 명시** — *Hand 클래스 도입 + GameStatistics 삭제 + Return 클래스 + calculateBetAmount 위치* 4 영역 자가 정리 + *Return 의 enum 분기 트레이드오프 자가 의문* + *Dealer/Player 각각 calculateBetAmount 중복 자가 의문*. **학생 자가 학습 모범 — PR #128·#135·#108·#133·#136·#137·#148·#151·#98·#95 와 같은 결**.
+- **1단계 코멘트 URL 자가 참조 + 자가 반영 명시** — *"[지난 코멘트](https://github.com/woowacourse/kotlin-blackjack/pull/67#discussion_r1524410778)의 내용을 반영해보았습니다!"* — *1단계 GameStatistics 객체 관련 reviewer 권고 위치를 URL 로 정확히 첨부* + *2단계에서 어떻게 반영했는지 명시*. **양 단계 본 reviewee 만 가능한 자가 학습 모범**. PR #95 의 *PR #74 URL 인용* / PR #136·#133 의 *PR 자가 참조* 결.
+- **Hand 클래스 도입 자가 정당화** — *"이전 코드에서는 Participant 객체들이 일급 컬렉션 없이 List<Card>를 직접 갖고 있어 카드를 처리하는 내부 로직을 모두 알고 있었습니다. 그러나 step2에서 배팅 금액 요소가 추가되었고, 이 또한 Participant에서 처리하자니 객체가 너무 많은 책임을 갖고 있다는 생각이 들었습니다. 따라서 카드와 관련된 책임을 분리하고자 Hand 클래스를 만들어주었습니다."* — *2단계 신규 책임 (베팅) 추가 → 기존 책임 재분배 자가 진단*. PR #74·#133·#88·#137·#148 와 같은 결의 *Hand 일급 컬렉션 도입*. KwonDae 칭찬: *"현재 Hand와 Participant 간 책임이 잘 분리되어서 어느 한곳에 비대해지지 않고 잘 분배되어 있도록 설계되어 있는게 인상깊었습니다."*
+- **Controller → 람다 콜백 자가 학습 (KwonDae 메타 질문 후)** — KwonDae 메타 질문: *"이 코멘트의 궁극적 의도는 'Controller와 View 없이도 블랙잭 게임을 할 수 있는가?' 에 대해서 도메인 로직이 충분히 Controller로 부터 분리되었나? 를 고민해보시면 좋겠습니다 👍"* + 학생 자가 답변: *"기존 로직에서는 반복문을 돌 때마다 'y/n에 대해 입력받기', '현재 카드 리스트를 출력하기'를 수행하는 뷰의 메서드가 필요했는데 해당 기능을 수행하는 함수들을 hitOrStay에서 람다로 받도록 분리해보았습니다!"*. **`onXX` 콜백 어휘 자가 학습** — PR #137·#132 와 같은 결.
+- **Players 일급 컬렉션 자가 도입 (KwonDae 권고 후)** — KwonDae: *"현재 딜러가 플레이어들(Players) 라는 컬렉션에 대해 의존성이 커보이네요. 그렇다면 플레이어들의 정보를 갖고있는 일급컬렉션을 활용해보는건 어떨까요?"* + 학생: *"플레이어의 정보를 갖는 일급컬렉션 Players를 만들고 컨트롤러에 있던 반복문 로직을 옮겨주었습니다!"*. PR #133·#74·#108·#137 와 같은 결.
+- **`protected` 키워드 자가 학습** — KwonDae: *"Participant 를 상속하는 클래스에서만 사용중인데요 이를 상속하는 클래스 외에서는 접근하지 못하게 제약을 걸어볼까요?"* + 학생: *"protected 키워드로 제약을 걸어주었습니다!"*. **상속 가시성 자가 학습** (private/protected/internal/public Kotlin 어휘).
+- **Dealer.hitOrStay 람다 콜백 + Card 의존** — KwonDae: *"Dealer 객체가 DealingShoe 객체 자체에 의존하기 보다는 card에 의존할 수 있도록 해볼 수 있겠네요!"* + 코드 예시 첨부 + 메타 질문: *"해당 함수에서 'DealingShoe 객체가 정말 필요한가?' 에 대해서 고민해볼까요?"*. **객체 의존 vs 메시지 의존 자가 학습 (`Card` 만 받으면 충분)**.
+- **머지 시점 회고 권유** — *"Controller는 이제 도메인 로직으로부터 자유로워졌네요 🎉 이 수정사항을 반영하시면서 어떤 장점을 느낄 수 있었는지 한번 스스로 정리해보셔도 좋은 회고가 될 것 같습니다."*. **학생 자가 회고 권유 모범** — PR #95 (말리빈 *"처음부터 다시 만들어보는 시간을 가져보셔도 좋겠어요"*) 결.
+- **zip 활용 칭찬** — *"zip 활용 💯"* — *Kotlin 컬렉션 어휘 활용*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Return` enum 클래스 명명 + 분기 트레이드오프 (학생 자가 의문)
+
+PR 본문 학생 자가 의문:
+
+> *"승패에 따른 rate의 부호를 구분해주기 위해 +와 - 각각을 모두 enum으로 생성했는데, 아래 두 케이스 중 어떤 쪽이 더 적절한지 궁금합니다..!*
+> *Return을 반환할 때 : WIN, LOSE, BLACKJACK, LOSE_BLACKJACK 등 직접적으로 명시하므로 어떤 상태인지 한 눈에 확인하기 쉬움*
+> *rate을 꺼내어 반환할 때 : 1.5배를 얻거나 잃을 때를 동일한 enum으로 처리, rate를 꺼내 부호를 별도로 붙여 구별해주어야 함"*
+
+KwonDae 답변 (자가 의문 → 함수 책임 어휘):
+
+> *"이 고민에 대한 부분은 Return을 활용하는 함수 Judge() 메서드의 용도, 네이밍에 따라 달라질 것 같습니다. Judge() 라는 메서드가 1. 단순히 결과를 판단만 하는 용도로 활용, 2. 무언가 연산도 함께 이루어져 '판단' 이라는 외 부수로직 포함, 이런 케이스가 존재할 수 있겠는데요, 그에 따라 Return이라는 enum의 활용도가 달라지겠죠? 그리고 Return enum 클래스 네이밍도 보다 직관적으로 수정해볼까요?"*
+
+학생: *"Return 대신 기존 게임 결과를 뜻하던 GameResult로 다시 변경했습니다!"*
+
+→ **3 가지 메타 학습**:
+
+#### 1.1. *enum 분기 다중 = 클래스 명명 어색의 시그널*
+
+학생의 *WIN / LOSE / BLACKJACK / LOSE_BLACKJACK* 4 분기 = *(승/패) × (블랙잭/일반)* 곱집합. *2-axis = enum 단일 표현 어색*. 대안:
+- (A) **`WinLose × IsBlackjack` 두 enum 곱** — *2 enum 으로 분리*.
+- (B) **`GameResult` enum + `multiplier: Double` 속성** — *부호 + 배율 직접 표현*.
+- (C) **`sealed class Outcome` + 멤버별 데이터** — *블랙잭은 별도 멤버 + 배율 1.5 / 일반 승리 멤버 + 배율 1 / 패 멤버 + 배율 -1*. 트레이드오프: *멤버 간 데이터 차이 X 시 `sealed without differentiation` 안티패턴* (PR #93). 데이터 차이가 있다면 `sealed` 정공.
+
+#### 1.2. **명명 = 사용자(`Judge()`) 책임에 따라 결정**
+
+KwonDae 의 *"Return을 활용하는 함수 Judge() 메서드의 용도, 네이밍에 따라 달라질 것"* — **반환 객체의 명명은 *반환 객체 자체* 가 아니라 *사용 컨텍스트*에 의해 결정**. *함수가 *결과 판단만* 한다면 `GameResult` 정공*. *함수가 *연산까지* 한다면 `RewardCalculation` 같은 어휘*.
+
+학생 결정 = `Return → GameResult` — *과한 어휘 (`Return`)* 가 *오히려 도메인 의미 손실* → *`GameResult` 같은 도메인 어휘 정공*. **MCP 기존 룰 `vagueName`** (`Return` 같은 추상 명사) 결.
+
+#### 1.3. *학생 자가 의문 = 학습 가시화*
+
+*WIN/LOSE/BLACKJACK 4분기 vs rate 단일 + 부호 분리* — *학생이 자가 2 안 + 각각 트레이드오프 명시* = *MCP `oop_propose_alternatives` 의 어휘와 일치*.
+
+PR #95·#98·#137·#148·#151 의 *학생 자가 의문* 결.
+
+### 2. Controller god-object — KwonDae 메타 질문: *"Controller와 View 없이 블랙잭 게임을 할 수 있는가?"*
+
+KwonDae 진단 (`proceedPlayerTurn()` 위치): *"컨트롤러 내에서 상태를 가져와 판단하여 로직을 수행하고 있어요. 만일 게임이 의도한대로 동작하지 않아 오류가 발생한다면 컨트롤러를 잘못 작성한 탓일까요? 도메인 로직에 오류가 있었기 때문일까요? 어떻게 개선해볼 수 있을까요?.?"*
+
+후속 메타 질문: *"이 코멘트의 궁극적 의도는 'Controller와 View 없이도 블랙잭 게임을 할 수 있는가?' 에 대해서 도메인 로직이 충분히 Controller로 부터 분리되었나? 를 고민해보시면 좋겠습니다 👍"*
+
+→ **3 가지 메타 진단**:
+
+#### 2.1. *오류 위치 = 책임 위치*
+
+*"오류가 발생한다면 컨트롤러를 잘못 작성한 탓? 도메인 로직?"* — **버그 위치 = 책임 위치**. *Controller 가 도메인 분기 (상태 판단, 카드 추가 결정) 를 한다면 → 도메인 버그 발생 시 *Controller* 와 *도메인 객체* 양쪽 모두 의심* → *책임 분산 = 디버깅 분산*.
+
+#### 2.2. *Controller + View 없이 게임 가능?* = **테스터빌리티 의문**
+
+도메인 로직만으로 *게임 시작 → 카드 분배 → hit/stay → 결과 판정* 흐름이 *Controller 없이 도메인 메서드 호출만으로 가능한가* = **테스트 가능성 의문**.
+
+해결:
+- (A) **`BlackjackGame.start(inputCallback, outputCallback)` 람다 콜백** (학생 자가 반영).
+- (B) **`BlackjackGame.next()` 단계별 진행 메서드 + 호출자가 시점 결정** — *람다 X + 상태 머신*. PR #93·#136·#152 의 *State.compareTo* 다형성 결.
+- (C) **`BlackjackGame.replay(commands: List<Command>)`** — *명령 패턴 + 결정적 테스트*.
+
+학생 자가 답변 = (A) — *람다 콜백으로 IO 분리*. PR #137·#132 의 *onXX 콜백* 결.
+
+#### 2.3. *Controller 가 자유로워졌네요* = 머지 시점 회고 권유
+
+KwonDae 머지 시점: *"Controller는 이제 도메인 로직으로부터 자유로워졌네요 🎉 이 수정사항을 반영하시면서 어떤 장점을 느낄 수 있었는지 한번 스스로 정리해보셔도 좋은 회고가 될 것 같습니다."* — **회고 = 자가 학습 가시화 권유**.
+
+PR #95 (말리빈 *"처음부터 다시 만들어보는 시간"*) / PR #98 (두루 종합 머지 코멘트) 결.
+
+### 3. `calculateBetAmount` Dealer/Player 각각 계산 — 학생 자가 의문
+
+PR 본문 학생 자가 의문:
+
+> *"플레이어만 calculateBetAmount를 수행하여 수익 총 합을 구하고 부호를 반전시켜 딜러의 수익을 구하는 것의 비용이 더 적다고 판단되지만, 게임 흐름 상 딜러의 수익을 먼저 출력하고 플레이어의 수익을 출력하기 때문에 딜러와 플레이어 각각에서 calculateBetAmount 메서드를 수행하고 있습니다. 현재는 가독성을 위해 불필요한 연산을 하고 있는 것 같아 딜러에서 구현한 calculateBetAmount 메서드 로직이 적절한지에 대해 의문이 듭니다."*
+
+KwonDae 답변 (일급 컬렉션 권고):
+
+> *"현재 딜러가 플레이어들(Players) 라는 컬렉션에 대해 의존성이 커보이네요. 그렇다면 플레이어들의 정보를 갖고있는 일급컬렉션을 활용해보는건 어떨까요?"*
+
+학생: *"플레이어의 정보를 갖는 일급컬렉션 Players를 만들고 컨트롤러에 있던 반복문 로직을 옮겨주었습니다!"*
+
+→ **자가 의문 = 가독성 vs 중복 연산 트레이드오프**. *학생은 *출력 순서 (딜러 먼저 → 플레이어)* 가 *연산 흐름 (플레이어 합산 → 딜러 부호 반전)* 과 *불일치* 를 자가 진단*. *해결 = Players 일급 컬렉션 + 합산 로직 위치* — *Players 가 `totalProfit()` 책임 + Dealer 는 `-players.totalProfit()` 단일 명령*.
+
+대안:
+- (A) **`Players.totalBetAmount()` 합산 + Dealer 는 부호 반전 단순 명령** = 학생 자가 반영.
+- (B) **`Dealer.calculateBetAmount(players: Players)` 메서드** = *Dealer 가 Players 인자 받음*. 트레이드오프: *Dealer 가 Players 의존 = 결합도*.
+- (C) **별도 `GameResult` 객체 + Dealer/Players 양쪽 결과 보유** = *결과 객체 응축*.
+
+학생 결정 (A) — *책임 단순화 + 출력 순서 무관*. PR #133·#136·#90 의 *책임 분배* 결.
+
+### 4. `protected` 키워드 누락 (1단계 학습 누락)
+
+KwonDae: *"Participant 를 상속하는 클래스에서만 사용중인데요 이를 상속하는 클래스 외에서는 접근하지 못하게 제약을 걸어볼까요?"*
+
+학생: *"protected 키워드로 제약을 걸어주었습니다!"*
+
+→ **Kotlin 가시성 어휘 자가 학습**:
+- *`private`* = 클래스 내부.
+- *`protected`* = 상속 자식 + 동일 클래스.
+- *`internal`* = 동일 모듈.
+- *`public` (default)* = 어디서나.
+
+*상속에서만 사용하는 멤버 = `protected` 정공*. *`public` 방치 = 불필요한 API 노출*. PR #85·#137 의 *가시성 자가 학습* 결.
+
+### 5. `Dealer.hitOrStay` — `DealingShoe` 객체 의존 vs `Card` 의존
+
+KwonDae 코드 예시 첨부:
+
+```kotlin
+fun hitOrStay(
+    pickCard: () -> Card,
+    printDealerHitMessage: () -> Unit,
+) {
+    while (isHittable()) {
+        super.pickCard(pickCard, 1)
+        printDealerHitMessage()
+    }
+}
+```
+
+후속 메타: *"해당 함수에서 'DealingShoe 객체가 정말 필요한가?' 에 대해서 고민해볼까요?"*
+
+→ **메시지 의존 vs 객체 의존**:
+- *Dealer 가 `DealingShoe` 전체 객체* 의존 → *DealingShoe 의 모든 책임 (남은 카드 수, 셔플, 리필) 까지 알아야 함*.
+- *Dealer 가 `() -> Card` 람다* 의존 → *카드 한 장 받는 책임만*. *DealingShoe 인지 모름*.
+
+**Dependency Inversion + Tell-Don't-Ask**:
+- *추상화 (람다) 의존* < *구체 (DealingShoe 객체) 의존*.
+- *카드 공급자가 누구인지 Dealer 는 모름* → *테스트 시 결정적 카드 공급자 주입 가능*.
+
+PR #41·#137·#132 의 *외부 자료 + 콜백* / PR #74 의 *interface CardDealer + 구현체 분리 권고* 결. 학생 머지 시점에 이 부분 미반영.
+
+### 6. Test Fixture 품질 — KwonDae 매우 긴 어휘 토론
+
+KwonDae: *"Test Fixture를 잘 활용해주셨는데요, 단순 객체를 변수로 치환하는 방법에서 더 나아가 테스트 코드 품질을 높여볼 수 있습니다. `val dealingShoe = createDealingShoe(EIGHT_CARD, EIGHT_CARD, TWO_CARD)`*
+
+> *"한가지 도움이 됐으면 하는게, 단순 객체를 상수처럼 사용하는 것만이 가독성과 테스트 코드 작성함에 있어 편리해질까요?*
+
+> *Test Fixture는 프로덕션 코드와 동일하게 높은 품질을 유지해야 합니다. 만약 테스트 코드 품질이 낮다면 - 유지보수가 어렵다 - 가독성이 오히려 떨어질 수 있다 - 테스트 코드에 오히려 더 많은 리소스가 들어간다*
+
+> *이를 위해 `createPlayers(), createCards()` 같은 실제로 우리가 도메인 로직에 사용하던 방식들과 별개로 생각하지 않고 비슷한 품질을 유지하도록 해야하는 이유입니다. 단순 객체를 의미있는 변수로 치환하는 방법에서 한발 더 나아가서 '어떻게 하면 중복 호출되는 함수를 줄여 가독성을 높일 수 있을까?' 에 고민을 해보셨음 하는 마음에 코멘트들을 남겼습니다."*
+
+→ **테스트 코드 품질 = 프로덕션 코드 품질**:
+
+1. *상수 (`EIGHT_CARD`) = 1 변수 치환* < *생성 함수 (`createDealingShoe(...)`) = N개 인자 + 가독성 + 재사용*.
+2. *유지보수* = *Card 생성 방식 변경 시 *생성 함수 1곳 변경* vs *상수 N개 모두 변경***.
+3. *재사용* = *동일 카드 조합이 여러 테스트에 등장 시 *함수 추출* 정공*.
+
+대안:
+- (A) **`createDealingShoe(vararg cards: Card)` 함수** = 가변 인자 + 명시적 카드 시퀀스.
+- (B) **`Cards.of(EIGHT, EIGHT, TWO)` Builder DSL** = Kotlin DSL 어휘.
+- (C) **`Fixture.dealingShoeWith(EIGHT, EIGHT, TWO)` Test Fixture 모듈** = 별도 객체로 분리.
+
+학생 머지 시점 미반영 (KwonDae 가 *DM 권유*: *"혹시 이후에도 논의하고 싶은 부분이 있다면 언제든 편하게 DM주세요 :)"*).
+
+PR #95·#88·#85·#137 의 *테스트 코드* 결.
+
+### 7. given-when-then 패턴 권고
+
+KwonDae: *"지금도 섹션별로 나누어져 있긴 하지만 명시적으로 given-when-then 패턴을 적용해서 구간을 나누어 보는건 어떨까요?"* + 외부 글 첨부.
+
+→ **AAA (Arrange-Act-Assert) 또는 GWT (Given-When-Then) 패턴**:
+- *Given*: 테스트 컨텍스트 (객체 생성, 데이터 준비).
+- *When*: 행동 (테스트 대상 메서드 호출).
+- *Then*: 검증 (assert).
+
+*Kotlin 의 `@Test` 함수에 *주석 또는 명시적 섹션 (//given //when //then)** 으로 구분*. 학생 머지 시점 미반영.
+
+## 리뷰어 의견 요지 (KwonDae)
+
+12 코멘트 특징:
+- **메타 질문 어휘** — *"오류가 발생한다면 컨트롤러를 잘못 작성한 탓일까요? 도메인 로직에 오류가 있었기 때문일까요? 어떻게 개선해볼 수 있을까요?.?"* / *"DealingShoe 객체가 정말 필요한가?"* / *"단순 객체를 상수처럼 사용하는 것만이 가독성과 테스트 코드 작성함에 있어 편리해질까요?"* — *학생 자가 답변 유도*.
+- **궁극적 의도 명시** — *"이 코멘트의 궁극적 의도는 'Controller와 View 없이도 블랙잭 게임을 할 수 있는가?' 에 대해서..."* — *첫 코멘트가 학생에게 닿지 않으면 후속 코멘트로 *의도* 명시*. PR #95 의 *두 번 부연* 결.
+- **코드 예시 첨부** — *`hitOrStay(pickCard, printDealerHitMessage)` 람다 콜백 코드* — 학생이 *바로 비교 가능*. PR #98·#75·#74·#133·#137·#146·#148·#151 의 *reviewer 코드 예시 첨부* 결.
+- **머지 시점 회고 권유** — *"Controller는 이제 도메인 로직으로부터 자유로워졌네요 🎉 이 수정사항을 반영하시면서 어떤 장점을 느낄 수 있었는지 한번 스스로 정리해보셔도 좋은 회고가 될 것 같습니다."* — *학생 자가 회고 명시 권유*.
+- **외부 글 + DM 채널 권유** — 테스트 코드 글 링크 + *"혹시 이후에도 논의하고 싶은 부분이 있다면 언제든 편하게 DM주세요"* — *PR 외부 채널 권유 = 깊은 토론 가능성 인정*.
+- **종합 머지 코멘트 = 단계 진화 인정** — *"1단계에서 구조 설계와 피드백 반영을 잘 해주셔서 큰 변경점 없이 미션을 마무리 할 수 있었습니다."* — *1단계 + 2단계 본 reviewer 만 가능한 평가*. PR #98 (두루 종합) 결.
+
+## 대표 인용
+
+> *"이 코멘트의 궁극적 의도는 'Controller와 View 없이도 블랙잭 게임을 할 수 있는가?' 에 대해서 도메인 로직이 충분히 Controller로 부터 분리되었나? 를 고민해보시면 좋겠습니다 👍"* — KwonDae (테스터빌리티 메타 질문)
+
+> *"Controller는 이제 도메인 로직으로부터 자유로워졌네요 🎉 이 수정사항을 반영하시면서 어떤 장점을 느낄 수 있었는지 한번 스스로 정리해보셔도 좋은 회고가 될 것 같습니다."* — KwonDae (머지 시점 회고 권유)
+
+> *"Test Fixture는 프로덕션 코드와 동일하게 높은 품질을 유지해야 합니다. 만약 테스트 코드 품질이 낮다면 유지보수가 어렵다, 가독성이 오히려 떨어질 수 있다, 테스트 코드에 오히려 더 많은 리소스가 들어간다."* — KwonDae (테스트 = 프로덕션 동등 품질)
+
+> *"승패에 따른 rate의 부호를 구분해주기 위해 +와 - 각각을 모두 enum으로 생성했는데, 아래 두 케이스 중 어떤 쪽이 더 적절한지 궁금합니다..!"* — s6m1n (학생 자가 의문 + 2 안 트레이드오프 명시)
+
+> *"기존 로직에서는 반복문을 돌 때마다 'y/n에 대해 입력받기', '현재 카드 리스트를 출력하기'를 수행하는 뷰의 메서드가 필요했는데 해당 기능을 수행하는 함수들을 hitOrStay에서 람다로 받도록 분리해보았습니다!"* — s6m1n (학생 자가 람다 콜백 적용 + 자가 학습 명시)
+
+## 얻은 교훈
+
+1. **PR 본문 = *학습 가시화 모범 채널***. *의존 다이어그램 + N개 주요 변경사항 + 자가 의문 + 1단계 코멘트 URL 자가 참조* — *학생이 PR 본문을 *학습 정리 공간* 으로 사용*. PR #128·#135·#108·#133·#136·#137·#148·#151·#98·#95 와 같은 결.
+
+2. **1단계 코멘트 URL 자가 참조** — *2단계 PR 본문에서 1단계의 *어느 코멘트* 를 *어떻게 반영했는지* 명시* = *양 단계 본 reviewer 가 1단계 학습 가시화 + 2단계 자가 평가 가능*. **양 단계 분석된 reviewees 모두에게 권장할 만한 패턴**.
+
+3. **enum 명명 = 사용 컨텍스트 (호출자 책임) 따라 결정** — *`Return` (추상) < `GameResult` (도메인) < `BettingMultiplier` (특수 책임)*. **MCP 기존 룰 `vagueName`** + *호출자 책임 어휘 일치 권고*.
+
+4. **enum 분기 다중 = 곱집합 = 명명 어색 시그널** — *WIN/LOSE × 일반/블랙잭 4 분기* = *2 axis 인 곳에 1 enum 강제* → *대안 = 2 enum 곱 / sealed + 데이터 멤버 / enum + 속성*.
+
+5. **테스터빌리티 메타 질문 = *"Controller + View 없이 가능한가?"*** = *도메인 로직 분리 정도 자가 진단*. *오류 발생 시 *Controller 탓?* *도메인 탓?* 분기 모호 = 책임 분산 시그널*.
+
+6. **머지 시점 회고 권유 = *자가 학습 가시화***. *"수정사항을 반영하시면서 어떤 장점을 느낄 수 있었는지"* — *학생 자가 학습 *말로 표현* 권유*. PR #95 (말리빈 *"처음부터 다시 만들어보는 시간"*) / PR #98 (두루 종합) 결.
+
+7. **`() -> Card` 람다 의존 vs `DealingShoe` 객체 의존** — *Dependency Inversion + 추상화 의존*. *카드 공급자 정체 모르는 Dealer = 테스트 친화 + 결합도 한정*. PR #74 의 *interface CardDealer* / PR #137·#132·#41 의 *onXX 콜백* 결.
+
+8. **Test Fixture 품질 = 프로덕션 동등** — *상수 치환 < 생성 함수 추출 < DSL/Builder*. *Test Fixture 가 *재사용성 + 가독성 + 변경 비용* 모두 책임*. **MCP 룰 후보 — `test-fixture-quality-parity`** (도메인 코드 어휘를 테스트에도 동일하게).
+
+9. **`protected` 가시성 = 상속 자식만 접근** = *Kotlin 어휘 + 캡슐화 정공*. *public default 방치 = 불필요 API 노출*.
+
+10. **자가 의문 2 안 + 트레이드오프 명시** — *학생이 *2 안 + 각각 장단점* 자가 정리* = *MCP `oop_propose_alternatives` 어휘와 일치*. **학생 자가 학습이 MCP 가 권하는 어휘로 자가 진화**. PR #95·#98·#137·#148·#151 와 같은 결.