oh-my-oop 0.2.0

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

@@ -0,0 +1,279 @@
+# PR #17 — [블랙잭 1단계] 코비 미션
+
+- **Reviewee:** [@rhkrwngud445](https://github.com/rhkrwngud445)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/17
+- **단계:** 1단계
+- **리뷰어:** @malibinYun (말리빈)
+- **라인 코멘트:** 30 (리뷰어 22 / 리뷰이 8)
+
+## 잘한 점 (설계 관점)
+
+- **`abstract class Participant` + `Dealer`/`Player`** + `Cards` 일급 컬렉션 + `ParticipantState` 도입 시도.
+- **`Deck` + `CardMaker` 분리** — 카드 생성과 덱 분리.
+- **`Referee` 객체 분리 + `Result` enum**.
+- **`@ParameterizedTest + @MethodSource` 활용** (못한 점 §14 참고).
+- **후속 반영 — `BlackjackGame.startGame` + Deck 새 초기화 + 게임 참여자가 카드 받기**.
+
+## 못한 점 (설계 관점)
+
+### 1. `BlackjackGame`이 *생성자에서 게임 시작* — 한 게임 한 인스턴스
+
+```kotlin
+class BlackjackGame(private val names: List<String>) {
+    private val deck: Deck = Deck(CardMaker().makeCards())
+    lateinit var dealerState: DealerState
+    val playersStates = mutableMapOf<String, PlayerState>()
+    init { makeParticipants() }
+}
+```
+
+리뷰어: "*하나의 블랙잭 게임 객체는, 한 번의 게임만 실행할 수 있겠네요* :) *객체는 한 개만 만들고, 게임은 여러 번 진행할 수 있게 만들어보는 것은 어떨까요?*" — *생성자가 게임 setup*하면 *재시작 = 새 객체*. `BlackjackGame()` + `startGame(names)` 분리. 학생 후속 반영.
+
+### 2. `BlackjackGame.makeStartDeck()` — 2장 분배가 BlackjackGame 책임?
+
+```kotlin
+private fun makeStartDeck(): MutableList<Card> {
+    val startDeck = mutableListOf<Card>()
+    repeat(2) { startDeck.add(deck.giveCard()) }
+    return startDeck
+}
+```
+
+리뷰어: "*2장의 카드를 뽑는 일은 정말 BlackjackGame의 역할일지 다시 고민*해보아요 :)" — *2장 = 게임 시작 룰*이지만 *카드를 뽑는 행위*는 *Participant 자율성*. `participant.drawInitial(deck)` 형태로 *참가자가 받기*. PR #28·#114·#92 권고와 같은 결.
+
+학생 자가 인정: "*게임 참여자의 역할로 이임했습니다!*"
+
+### 3. `Card data class` Flyweight 미적용
+
+```kotlin
+data class Card(val shape: Shape, val cardValue: CardValue)
+```
+
+리뷰어: "*카드들이 생성 되는 경우는 얼마나될까요? 한 번만 만들어두고 재활용할 수 있을까요?* 🙂" / 후속: "*여전히 동일한 카드이지만 다른 인스턴스를 만들 수 있는 구조*예요 :) *로또 번호를 생각해보고 구현해보시면 좋겠어요* 🙂"
+
+→ *data class*는 *equals/hashCode 자동*이라 *동치 비교*는 됨. 그러나 *생성 시마다 인스턴스*. *Lotto 미션의 LottoNumber Flyweight* 패턴: `private constructor` + `Card.of(shape, value)` 팩토리 + 52장 *static cache*. PR #112·#128·#135 패턴.
+
+### 4. `Shape.shape: String` UI 표현 보유
+
+```kotlin
+enum class Shape(val shape: String) { HEART("하트"), DIAMOND("다이아몬드"), SPADE("스페이드"), CLOVER("클로버") }
+```
+
+리뷰어: "*"하트" 는 도메인의 영역이 맞을까요? 출력 결과가 ♥로 변경된다면, 도메인을 변경해야할까요?*" — **enum UI value 11개 PR 연속**.
+
+### 5. `CardValue.ACE_ELEVEN_VALUE = 11` — Ace 11 기본값
+
+```kotlin
+enum class CardValue(val value: Int) {
+    ACE(1), ...
+    companion object { const val ACE_ELEVEN_VALUE = 11 }
+}
+```
+
+리뷰어: "*ACE 카드의 기본 점수는 1입니다.* ACE 하나만을 위해서 *필드를 늘리기 보다, 로직을 통해 특수 점수를 표현*해보는 것은 어떨까요?" — *ACE_ELEVEN_VALUE* 정적 상수로 따로 보유 = *Ace가 두 가지 점수*. *기본 1 + 보너스 10이 21 이하면 적용*이 단일 룰. PR #112·#29·#119와 같은 결.
+
+### 6. `CardMaker.makeCards()` — `for + mutableList` 사용
+
+리뷰어: "*kotlin 확장함수인 map을 활용해서 for문과 mutableList 생성을 지워보세요* :)" — `Shape.entries.flatMap { shape -> CardValue.entries.map { Card(shape, it) } }` 같은 *컬렉션 함수*. *Java 어휘 습관*.
+
+### 7. `Deck(cards: List<Card>)` 생성자 인자를 *바로 멤버에 저장 안 함*
+
+```kotlin
+class Deck(cards: List<Card>) { ... }
+```
+
+리뷰어: "*생성자로 들어오는 값은 반드시 멤버 변수로 선언해야 할까요?*" — `val cards: List<Card>` 처럼 *모든 생성자 인자를 멤버화*는 *과잉*. *내부 가공만 필요*하면 *멤버로 안 두기*. 그러나 `Deck`이 *카드를 보유*하면 *멤버로 선언* 필요. **답은 *책임 따라*** — *Deck = 카드 보유자*면 멤버, *Deck = 가공자*면 X.
+
+### 8. `Deck object` Singleton — 결정적 테스트 불가
+
+```kotlin
+object Deck {
+    private var cards: List<Card> = CardMaker().makeCards()
+    fun giveCard(): Card { ... }
+}
+```
+
+리뷰어: "*Deck은 랜덤에 대해 제어할 수 없는 객체*입니다. 이전 미션들에서 *랜덤에 대해 로직을 제어했고, 테스트 코드를 작성해 보았듯이* 카드에 대한 것도 *개발자가 제어할 수 있는 영역으로 변경*하길 시도해보세요! 😊" — PR #65·#79·#125·#92·#33과 같은 *Singleton Deck* 안티패턴. 
+
+### 9. `ParticipantState(cards: MutableList<Card>)` 외부 참조 누수
+
+```kotlin
+class ParticipantState(private val cards: MutableList<Card>) { ... }
+```
+
+리뷰어: "*방어적 복사의 의미가 없을 수도 있겠어요* :) 아래 코드 같이 실행한다면 어떤 일이 벌어질 수 있을까요? `val mutableList = mutableListOf(1, 2, 3); ParticipantState(mutableList); mutableList.clear()`" — PR #79·#65·#24·#28·#10·#33과 같은 *외부 참조 누수*. **9개 PR 연속 등장하는 안티패턴**.
+
+리뷰어: "*또, 참여자들이 가지고 있는 Card들을 일급 컬렉션으로 만들어보는 것은 어떨까요?*" — `Cards` 일급 컬렉션.
+
+### 10. `PlayerState.isBurst()` — *Burst가 Player만의 기능?*
+
+리뷰어: "*Burst인지 아닌지 확인하는 기능은, Player만이 필요한 기능일까요?*" — *Dealer도 Bust 가능*. *Burst*는 *Participant 공통 행위*. *State 분기 추상*이 모호.
+
+### 11. `Referee` 정적 비교자 — 블랙잭 룰 미반영
+
+```kotlin
+class Referee { ... }
+```
+
+리뷰어: "*블랙잭에 대한 도메인이 반영되지 않아 보여요. 딜러가 블랙잭이지만, 플레이어가 일반 21점인 경우는 딜러의 승리*입니다 :) *블랙잭에 대한 도메인을 좀 더 파악*해보세요!" / "*블랙잭은 딜러와 플레이어 간의 게임이라, 반드시 둘의 점수만을 비교하는 게임*이에요. *플레이어끼리도 승부를 겨루지 않지요.* 그래서 저는 *제 3자인 심판이란 객체가 필요하지 않다*고 생각해요. 코비는 어떻게 생각하시나..."
+
+→ **두 가지 결합 — *Referee 객체 필요성* + *블랙잭 룰 정밀도***. PR #28·#63·#125 *match는 참가자* 권고. PR #128·#119 *21 ≠ 블랙잭* 룰. **블랙잭 룰의 *Ace + 10 두 장만 진짜 블랙잭*** 11개 PR 연속 *블랙잭 룰 오해* 등장.
+
+### 12. `Dealer.constructor(vararg card: Card)` — *vararg + 단수형*
+
+```kotlin
+class Dealer(override val cards: Cards) : Participant(cards) {
+    constructor(vararg card: Card) : this(Cards(card.toList()))
+}
+```
+
+리뷰어: "*vararg 는 여러 개의 데이터 들어오는데, card 단수형은 어색해보입니다* :) 특히, *card.toList()는 1장 만을 담은 리스트를 만드는 것 처럼 보이네요* 🤔" — `vararg cards: Card`가 자연. *영문 단/복수* 식별. (사소하지만 가독성 영향.)
+
+### 13. `Participant.cards: open val` 외부 공개 + override
+
+```kotlin
+abstract class Participant(open val cards: Cards) { ... }
+class Dealer(override val cards: Cards) : Participant(cards) { ... }
+class Player(override val cards: Cards, val name: String) : Participant(cards) { ... }
+```
+
+리뷰어: "*cards를 open한 이유가 있을까요?* *이미 부모에서 멤버변수로서 갖고 있기에, 자식에서 부모에게 필요한 cards를 전달만 하면, override 하지 않고도 자식에서 cards를 접근할 수 있*습니다 🙂" — **불필요한 `open` + `override`**. 부모 생성자가 cards를 받고 `val cards: Cards`로 저장하면 *자식이 override 안 해도 접근 가능*. *open으로 외부 override 허용 + 자식에서 redundant override*. PR #119·#33과 같은 *외부 공개 + open* 안티패턴.
+
+### 14. `Participant.calculateCardSum()` — 표현식이 한 줄에 *복잡한 조건*
+
+```kotlin
+fun calculateCardSum(): Int = cards.getCards()
+    .sumOf { it.cardValue.value } +
+    if (isAceValueToEleven()) CardValue.ACE_ELEVEN_VALUE - CardValue.ACE.value else 0
+```
+
+리뷰어: "*로직이 단순하지 않으니 1줄 보단 중괄호를 열어주는 것은 어떨까요?*" — *expression body* 남용. *여러 단계 표현식*은 *block body*가 가독성. 
+
+### 15. `Participant.countAce()` *세는 메서드* vs *있는지 확인*
+
+```kotlin
+private fun isAceValueToEleven() = countAce() >= 1 && cards.getCards().sumOf { it.cardValue.value } <= ACE_ELEVEN_VALUE
+```
+
+리뷰어: "*결국 ACE가 존재하는 지를 알기 위해 만들어진 메서드*로 보여요. 그렇다면, *ACE를 세는 메서드가 아닌, ACE가 카드 목록에 있는 지 알아보는 기능*을 만드는 것은 어떨까요?" — `countAce() >= 1`은 *hasAce(): Boolean*과 동치. *의도 명시*. PR #10·#79와 같은 결.
+
+### 16. `Players(playerStates: List<PlayerState>)` 초기화 외부 책임
+
+```kotlin
+class Players { ... }
+```
+
+리뷰어: "*처음부터 초기화된 player를 생성자로만 받아보는 건 어떨까요?* 🙂" — *Players를 빈 상태로 만든 후 add 하는 패턴*보다 *초기 상태로 받기*가 자연. lotto 패턴.
+
+### 17. `Cards` 일급 컬렉션이 *값 보유만 + 책임 부재*
+
+```kotlin
+class Cards(...) { /* getCards / addCard 등만 */ }
+```
+
+리뷰어: "*Card에 대한 일급컬렉션이 값을 가지고 있는 것 말고 아무런 역할을 지니지 않네요. 이 객체에는 어떤 책임을 가지는 게 좋을 지 고민*해보세요 😊" — **일급 컬렉션의 핵심 가치 = *비즈니스 동작 보유***. *합산 / Bust 판정 / 보너스* 같은 *카드 관련 룰*을 `Cards` 안으로. 그렇지 않으면 *list wrapper*에 불과.
+
+### 18. `BlackjackController.dealerPickCard`가 *한 장만 뽑음*
+
+```kotlin
+private fun dealerPickCard(blackjackGame: BlackjackGame) {
+    if (blackjackGame.checkDealerAvailableForPick()) {
+        OutputView.printDealerUnder16()
+        blackjackGame.pickDealerCard()
+    }
+}
+```
+
+리뷰어: "*딜러는 16점 이하이면 반드시 카드를 뽑아야합니다. 한 장 더 뽑아서 16점 이하여도 더 뽑아야 함을 의미합니다* 🙂" — **`if` 단발 호출 ≠ `while`**. *Bust 또는 17 이상까지 반복*이 룰. 학생 코드는 *한 번만 검사 후 한 장*. **블랙잭 룰 오해**. PR #10·#92·#116과 같은 결.
+
+### 19. `DeckTest`에 *주석 처리된 테스트*
+
+```kotlin
+class DeckTest {
+    // @Test
+    // fun `...`() { ... }   // 주석 처리
+}
+```
+
+리뷰어: "*이 테스트는 어떤 이유로 주석 처리 된 걸까요 ?_?*" 학생: "*기능 구현을 계획했지만, 시간이 부족하여 구현하지 못했습니다*😥" — **주석 처리된 코드 = 의도 불명**. *해야 할 일은 TODO 코멘트 + commit*. *주석 코드*는 *읽는 사람이 의도 추측 불가*.
+
+### 20. `DealerStateTest`에 *Card 생성 boilerplate*
+
+```kotlin
+val card1 = Card(Shape.HEART, CardValue.ACE)
+val card2 = Card(Shape.DIAMOND, CardValue.KING)
+// ...
+```
+
+리뷰어: "*Card를 만들기 불편해보이고, 테스트 가독성도 나빠져 보여요. 테스트에서 사용할 Card의 가짜 생성자를 만들어보는 것은 어떨까요?* 가짜 생성자는 아래의 글을 참고해보세요 :) https://kotlinlang.org/docs/constructing-collections.html#concise-syntax-for-collections" — *Test fixture 함수* `cardOf(shape, value)` 또는 *vararg*. PR #28·#65 권고와 같은 결.
+
+### 21. `PlayerStateTest`에 *반복문 + ParameterizedTest*
+
+리뷰어: "*테스트 내에서 반복문을 실행시키는 것은 테스트 가독성을 떨어뜨립니다.* 한 눈에 보지 못하고, *코드가 어떻게 실행되는 지 머릿속에서 실행을 해봐야 하기 때문*이에요. 또, *해당 테스트는 반드시 Parameterized Test일 필요가 있*..."
+
+→ **반복문 + ParameterizedTest 이중 = 시나리오가 머릿속 시뮬레이션 필요**. *시나리오별 분리 테스트*가 *각 케이스 독립*. ParameterizedTest는 *입력만 다르고 동작은 같은 경우*에만.
+
+## 리뷰어 의견 요지
+
+- ***BlackjackGame 생성자에서 setup = 한 게임 한 인스턴스***.
+- ***2장 분배 = 참가자 자율성***.
+- ***Card Flyweight 미적용*** — 로또 패턴 권고.
+- ***enum UI value (11개 PR 연속)***.
+- ***Ace 11 기본 = 알고리즘 편의가 도메인 어휘 왜곡***.
+- ***`for + mutableList`보다 `flatMap`***.
+- ***`Deck` Singleton = 테스터빌리티 ↓***.
+- ***ParticipantState 외부 참조 누수 (9개 PR 연속)***.
+- ***Burst는 Participant 공통***.
+- ***Referee 객체 필요성 + 블랙잭 룰 정밀도***.
+- ***`vararg card` 단수형 어색***.
+- ***`open val cards` + override 불필요***.
+- ***expression body 남용 = block body 가독성***.
+- ***countAce() vs hasAce()*** — 의도 명시.
+- ***Players 생성자에 초기 상태***.
+- ***Cards 일급 컬렉션 = 비즈니스 동작 보유***.
+- ***딜러 16 이하 반복 = while***.
+- ***주석 처리 코드 = TODO 코멘트***.
+- ***테스트 fixture 함수 (가짜 생성자)***.
+- ***반복문 + ParameterizedTest 이중 = 시나리오 분리***.
+
+## 대표 인용
+
+> 하나의 블랙잭 게임 객체는, *한 번의 게임만 실행할 수 있겠네요* :) *객체는 한 개만 만들고, 게임은 여러 번 진행할 수 있게 만들어보는 것은 어떨까요?*
+> — @malibinYun on `BlackjackGame.kt`
+
+> *Deck은 랜덤에 대해 제어할 수 없는 객체*입니다. 이전 미션들에서 *랜덤에 대해 로직을 제어했고, 테스트 코드를 작성해 보았듯이* 카드에 대한 것도 *개발자가 제어할 수 있는 영역으로 변경*하길 시도해보세요! 😊
+> — @malibinYun on `Deck.kt`
+
+> 결국 *ACE가 존재하는 지를 알기 위해 만들어진 메서드*로 보여요. 그렇다면, *ACE를 세는 메서드가 아닌, ACE가 카드 목록에 있는 지 알아보는 기능*을 만드는 것은 어떨까요?
+> — @malibinYun on `Participant.kt`
+
+> 딜러는 *16점 이하이면 반드시 카드를 뽑아야합니다. 한 장 더 뽑아서 16점 이하여도 더 뽑아야 함을 의미*합니다 🙂
+> — @malibinYun on `BlackjackController.kt`
+
+> 블랙잭은 *딜러와 플레이어 간의 게임이라, 반드시 둘의 점수만을 비교하는 게임*이에요. *플레이어끼리도 승부를 겨루지 않지요.* 그래서 저는 *제 3자인 심판이란 객체가 필요하지 않다*고 생각해요.
+> — @malibinYun on `Referee.kt`
+
+> Card에 대한 일급컬렉션이 *값을 가지고 있는 것 말고 아무런 역할을 지니지 않*네요. *이 객체에는 어떤 책임을 가지는 게 좋을 지 고민*해보세요 😊
+> — @malibinYun on `Cards.kt`
+
+## 얻은 교훈
+
+- ***BlackjackGame 생성자에서 setup = 한 게임 한 인스턴스 강제*** — `startGame(names)` 분리로 *재시작 가능*. PR #114·#92·#29와 같은 결.
+- ***2장 분배는 참가자 자율성*** — `participant.drawInitial(deck)`. *진행자가 직접 분배*는 *자율성 부재* + *분배 책임 누수*.
+- ***Card Flyweight 미적용 = 로또 패턴 권고*** — `private constructor` + `Card.of(shape, value)` + 52장 static cache. PR #112·#128·#135와 같은 결.
+- ***enum UI value = 11개 PR 연속 (MCP 룰 후보 최강)***.
+- ***Ace 11 기본 + 추가 상수(`ACE_ELEVEN_VALUE`) = 도메인 어휘 왜곡*** — *기본 1 + 보너스 10*이 단일 룰. PR #29·#112·#119 권고와 같은 결.
+- ***`for + mutableList` < `flatMap`*** — Kotlin 컬렉션 함수 활용. *Java 어휘 습관*.
+- ***Singleton Deck = 결정적 테스트 불가*** — 9개+ PR 연속.
+- ***ParticipantState 외부 참조 누수 = 10개+ PR 연속 안티패턴 (MCP 룰 후보)***.
+- ***Burst는 Participant 공통*** — Dealer도 Bust 가능. *State가 Player 전용*이면 추상화 누수.
+- ***Referee 객체 vs 참가자 자율성 + 블랙잭 룰 정밀도*** — *match는 참가자 메시지*가 12개+ PR 연속 권고.
+- ***`vararg card` 단수형 어색*** — `vararg cards: Card` 복수형이 자연.
+- ***`open val cards` + override 불필요*** — 부모가 받고 저장하면 자식 자동 접근. *open + redundant override*는 불필요한 노이즈.
+- ***expression body 남용 < block body*** — *여러 단계 표현식*에서.
+- ***`countAce()` 셀 필요 없음 → `hasAce(): Boolean`*** — *Ace 한 번만 +10 보정*이면 카운트 무의미. PR #10·#79와 같은 결.
+- ***Cards 일급 컬렉션 = 비즈니스 동작 보유*** — *list wrapper*는 일급 컬렉션 X.
+- ***딜러 16 이하 = while 반복*** — `if` 단발은 *블랙잭 룰 오해*. PR #10·#92·#116과 같은 결.
+- ***주석 처리 코드 = 의도 불명*** — *TODO 코멘트* + *commit으로 미완성 표시*.
+- ***테스트 fixture (가짜 생성자) = 테스트 가독성 ↑*** — *Card 생성 boilerplate*를 *test 헬퍼*로.
+- ***반복문 + ParameterizedTest 이중 = 시나리오 머릿속 시뮬레이션 필요*** — *시나리오별 분리 테스트*가 *독립*.

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

@@ -0,0 +1,145 @@
+# PR #50 — [코비] 2단계 블랙잭
+
+- **Reviewee:** [@rhkrwngud445](https://github.com/rhkrwngud445) (코비)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/50
+- **단계:** 2단계
+- **리뷰어:** [@malibinYun](https://github.com/malibinYun) (말리빈)
+- **라인 코멘트:** 8 스레드 — *학생 자가 답변 3 thread + Effective Kotlin Item 4·14 외부 서적 인용 + 1단계 리뷰 연장선 + Deck 전략 생성자 주입 + BlackJack 승리 vs 일반 승리 책임 분리 + assertAll 효율*
+- **rhkrwngud445 양 단계 완성** (1단계 #17).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 1단계 피드백 미이해 자가 질문
+
+PR 본문:
+
+> *"이전 피드백 반영하였습니다! 다만 해당 피드백에서 \"다른 인스턴스를 만들 수 있는 구조\"를 잘 이해 못하였습니다😥 **어떻게 접근해야 할지 참고할 예시나 키워드 부탁드려도 괜찮으실까요..?!**"*
+
+→ **`student-self-vocabulary-keyword-request`** ⭐ — 학생 자가 *이해 못한 부분 키워드 요청* 어휘.
+
+### 2. assertAll 효율 자가 답변 (Thread 7)
+
+reviewer: *"assert 구문을 나열하는 것과, assertAll로 감싸는 것은 어떤 차이점이 있을까요?"*
+
+학생 자가 답변: *"assertAll은 이전 테스트가 틀렸어도 어디서 값이 또 다른지 알 수 있습니다! 테스트 수가 많아지면 효율적일 것 같습니다!"*
+
+→ **MCP 룰 `assertall-vs-sequential-assert-tradeoff`** ⭐⭐ 신규 — *assertAll = 다른 검증 계속 + 어디서 또 틀렸는지 동시 확인*. PR #42 (`assertj-soft-assertion-for-long-tests`) 결 합류 누적 2 PR.
+
+## 못한 점 (설계 관점)
+
+### 1. Effective Kotlin Item 4·14 외부 서적 인용 (Thread 1) — 정점
+
+reviewer:
+
+> *"멤버변수와 메서드의 리턴타입은 모두 명시해주는 것은 어떨까요? 명시해주는 것과 그렇지 않은 것은 어떤 차이점이 생길까요?*
+>
+> *먼저 고민해보시고, 아래 Effective Kotlin 서적의 챕터를 참고해서 스스로 생각해본 것과 비교해보아요 😀*
+>
+> *- **Item 4 : `Inferred Type으로 리턴하지 말라`***
+> *- **Item 14 : `변수 타입이 명확하지 않은 경우 확실하게 지정하라`***"*
+
+학생 자가 답변:
+
+> *"Inferred Type일 때 super 혹은 interface 형태로 리턴되지 않기 때문에, 제 코드를 직접 조작하지 않는 이상 외부에서 코드를 조작하기 어렵습니다. 또한 코드 내부로 들어가서 타입을 확인을 해주어야 하는 비용이 발생하기 때문에, 코드를 짧게 작성하는 것보다 이점이 많다고 생각됩니다!!"*
+
+→ **MCP 룰 `effective-kotlin-inferred-type-reference`** ⭐⭐⭐ **신규** — *Effective Kotlin Item 번호 명시 + 학생 자가 학습 비교 어휘*. PR #154 (조영호)·PR #150 (로버트 마틴)·PR #62 (LISP)·PR #136 (엘레강트 오브젝트) 결 합류 → ***외부 서적 인용 누적 5 PR*** ⭐⭐⭐ 정점 강화.
+
+→ **`reviewer-book-chapter-citation`** ⭐⭐⭐ — *reviewer 서적 챕터 명시 + 학생 자가 스스로 생각 후 비교* 어휘.
+
+### 2. Deck 전략 패턴 생성자 주입 (Thread 2)
+
+reviewer:
+
+> *"deck을 변수로 두어 계속 새 List를 할당하는 것 보다, 한 MutableList에 카드를 추가/삭제하게 구현해보세요. **makeRandomDeck()은, 모든 덱은 랜덤하다는 전제가 깔려있어 보여요.** Deck 객체를 생성할 때, **카드를 채우는 전략을 생성자로부터 받아보게** 만들어보세요 :)"*
+
+→ **MCP 룰 `deck-fill-strategy-via-constructor`** ⭐⭐⭐ 신규 — *랜덤 가정 X + 카드 채우기 전략 = 생성자 주입*. PR #30 (Generator interface)·PR #154 (`factory-with-test-only-variant`) 결 합류 누적 3 PR.
+
+### 3. 딜러 = 생성자 / 플레이어 = 실행 시 주입 (Thread 0)
+
+reviewer:
+
+> *"사이드 이팩트를 발생시키기 보다, 게임을 실행할 때 딜러와 플레이어를 받는 것은 어떨까요? **딜러는 변하지 않으니, 여전히 생성자에 놔둬도 괜찮아 보이네요** :)"*
+
+→ **MCP 룰 `dealer-constructor-vs-player-runtime-injection`** ⭐⭐⭐ 신규 — *불변 의존 = 생성자 / 변경 가능 = 실행 시 주입*. PR #38 (`mutable-member-var-state-dependent-result`)·PR #154 (`construction-time-vs-mutation-time-invariant`) 결 합류 누적 3 PR.
+
+### 4. 일급 컬렉션 + Mutable 내부 + toList 반환 (Thread 5) — 1단계 연장선
+
+reviewer (PR #17 리뷰 연장):
+
+> *"현재 리스트를 반환할 수 있습니다. **mutableList.toList()로 복사해서 반환이 가능합니다.** 컬렉션에 담기는 객체가 불변이라면 반환하는 객체는 안전하겠지요 🙂*
+>
+> *일급 컬렉션 내부에서 관리하는 컬렉션을 Mutable로 해도, 외부에서의 수정 등을 막을 수 있습니다. 어떤 이유로 불가능하다고 생각하셨을까요?_?"*
+
+학생 자가 답변:
+
+> *"프로퍼티로 둘 생각을 못했었네요.. **위의 덱 리뷰와 같이 프로퍼티로 두어 외부적으로 불변한 객체를 생성할 수 있다는 것을 간과했었습니다..**😭"*
+
+→ **MCP 룰 `firstclass-collection-mutable-inner-with-tolist-return`** ⭐⭐ 신규 — *일급 컬렉션 = Mutable 내부 + `toList()` 외부 = 캡슐화 + 성능*. PR #42·#47 결 합류.
+
+→ **MCP 룰 `student-cross-pr-feedback-continuity`** ⭐⭐ — *1단계 PR 리뷰 링크 + 2단계 연장선* — PR #97·#154·#101 결 합류.
+
+### 5. BlackJack 승리 vs 일반 승리 책임 분리 (Thread 6)
+
+reviewer:
+
+> *"BlackJack으로 승리한 것과, 일반적으로 승리한 것은 정말 다른 종류의 승리일까요? **요구사항으로 규칙이 여러 추가된다면, 여러 종류의 DRAW, WIN 등이 더 생겨날 수 있어보여요.** 그렇다면 이들은 정말로 Result 하나만을 나타내는 걸까요? 다른 책임을 가지고 있는 것은 아닐지 고민해보아요 🙂"*
+
+→ **MCP 룰 `bjackjack-vs-normal-win-different-responsibility`** ⭐⭐⭐ 신규 — *Result enum = 미래 규칙 추가 시 책임 분리 시그널*. PR #134 (`score-vs-blackjack-score-locus`)·PR #97 (`branch-multiplication-as-test-burden-signal`) 결 합류 — *enum 책임 분리 어휘*.
+
+### 6. public vs val 가시성 (Thread 3)
+
+reviewer: *"현재 players의 가시성을 public으로 공개하는 것과 크게 다르지 않아보이네요 :)"*
+
+→ **가시성 = 의도 명시** = 누적.
+
+### 7. 총합 중복 계산 (Thread 4)
+
+reviewer: *"총합을 중복으로 계산하네요 :) 한 번 만 계산하게 변경해보세요."*
+
+→ **중복 계산 = 캐싱/지역변수** = 누적.
+
+### 8. reviewer 마무리 — 기한 초과 머지
+
+reviewer:
+
+> *"미션 기한이 지나 아쉽게도 바로 머지해야해요 ㅠ_ㅠ. 다음 미션에는 기한을 꼭 지켜서 리뷰 받으시길 바라요 😥. 그래도 저와 함께 미션을 진행하면서 고민했던 것들이 미래에 도움이 되셨으면 좋겠어요!!"*
+
+→ **`reviewer-deadline-miss-merge-vocabulary`** ⭐⭐ — *기한 초과 = 머지 + 미래 도움 어휘*. PR #134·#97 결 합류 누적 3 PR — *reviewer 시간 한계 어휘 정점*.
+
+## 대표 인용
+
+> [malibinYun Thread 1]
+> *"아래 Effective Kotlin 서적의 챕터를 참고해서 스스로 생각해본 것과 비교해보아요 😀. Item 4 : `Inferred Type으로 리턴하지 말라`. Item 14 : `변수 타입이 명확하지 않은 경우 확실하게 지정하라`"*
+
+→ **Effective Kotlin 챕터 명시 + 스스로 생각 후 비교 어휘**.
+
+> [malibinYun Thread 0]
+> *"딜러는 변하지 않으니, 여전히 생성자에 놔둬도 괜찮아 보이네요"*
+
+→ **불변 = 생성자 / 가변 = 실행 시 주입 어휘**.
+
+> [malibinYun Thread 6]
+> *"BlackJack으로 승리한 것과, 일반적으로 승리한 것은 정말 다른 종류의 승리일까요?"*
+
+→ **enum 책임 분리 시그널 어휘**.
+
+> [rhkrwngud445 Thread 5]
+> *"프로퍼티로 둘 생각을 못했었네요.. 위의 덱 리뷰와 같이 프로퍼티로 두어 외부적으로 불변한 객체를 생성할 수 있다는 것을 간과했었습니다.."*
+
+→ **학생 자가 *간과* 자가 자각 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **Effective Kotlin Item 챕터 인용 (외부 서적 누적 5 PR)** — **MCP 룰 `effective-kotlin-inferred-type-reference` + `reviewer-book-chapter-citation` 후보** ⭐⭐⭐ 정점.
+2. **불변 = 생성자 / 가변 = 실행 시 주입** — **MCP 룰 `dealer-constructor-vs-player-runtime-injection` 후보** ⭐⭐⭐.
+3. **Deck 전략 생성자 주입** — **MCP 룰 `deck-fill-strategy-via-constructor` 후보** ⭐⭐⭐.
+4. **enum 책임 분리 시그널** — **MCP 룰 `bjackjack-vs-normal-win-different-responsibility` 후보** ⭐⭐⭐.
+5. **일급 컬렉션 + Mutable 내부 + `toList()` 반환** — **MCP 룰 `firstclass-collection-mutable-inner-with-tolist-return` 후보** ⭐⭐.
+6. **assertAll vs sequential assert** — **MCP 룰 `assertall-vs-sequential-assert-tradeoff` 후보** ⭐⭐.
+7. **reviewer 기한 초과 머지 어휘 (누적 3 PR)** — **MCP 룰 `reviewer-deadline-miss-merge-vocabulary` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **rhkrwngud445 양 단계 완성 (1단계 #17 → 2단계 #50)**.
+- **외부 서적 인용 누적 5 PR** (PR #154 조영호 + PR #150 로버트 마틴 + PR #62 LISP + PR #136 엘레강트 오브젝트 + PR #50 Effective Kotlin) — *외부 권위 인용 정점*.
+- **reviewer 시간 한계 어휘 누적 3 PR** (PR #134 + #97 + #50) — *reviewer 자가 한계 인정* 어휘 정점.