oh-my-oop 0.2.0

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

@@ -0,0 +1,162 @@
+# PR #105 — [블랙잭] 차람 2단계 미션
+
+- **Reviewee:** [@aprilgom](https://github.com/aprilgom) (차람)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/105
+- **단계:** 2단계
+- **리뷰어:** [@laco-dev](https://github.com/laco-dev) (페로로)
+- **라인 코멘트:** 8 스레드 — *PR 본문 strength 도메인 어휘 상세 설명 + 이미지 첨부 + 학생 자가 *물음표 나게 하는 코드* 자조 / 컨트롤러 없이 게임 가능? 상상 테스트 누적 2 PR + StrengthPolicy Int → 객체 역할 + Statistics 단순 값 vs 수익률 계산 책임 + Stay 후 카드 변경 차단*
+- **aprilgom 양 단계 완성** (1단계 #64).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — strength 도메인 어휘 상세 설명 + 이미지 첨부 정점
+
+PR 본문:
+
+> *"이전 단계에서 StrengthPolicy에 대한 설명이 필요하다는 피드백 남겨주셨는데요,*
+>
+> *(스크린샷 첨부)*
+>
+> ***strength는 족보의 순위라 생각하시면 될 것 같습니다.** (위 쪽으로 갈 수록 강한 패이고, 아래쪽으로 갈수록 약한 패입니다.)*
+>
+> *그러면 출력할 때 블랙잭은 22, bust일때는 -1이나 0이 나오지 않는가? 라는 피드백을 주셨는데요, **참가자끼리 승패를 비교할 때는 이 strength를 이용해 비교를 하고, 점수 출력을 할 때에는 손에 있는 카드 점수의 총합을 이용해 출력합니다.***
+>
+> *예를 들어, 손에 10,10,7 카드가 있다고 할 때 bust가 되었으니 strength가 0 or -1이나 출력할때는 손 패의 카드 점수 총 합인 27을 출력합니다. (...) **이 두 패의 승부를 낼 때는 손 패의 카드 점수 총 합인 27, 21로 비교하는 것이 아니라 strength인 0, 22로 비교하여 승부를 냅니다.***
+>
+> *딜러의 bust가 플레이어의 bust를 이기기에 StrengthPolicy 인터페이스를 만들고 딜러와 플레이어가 각기 다른 구현체를 받게 해 차이를 두고자 했습니다. (굳이 인터페이스를 쓴 이유는, Participant 안에 when문을 길게 넣고싶지 않아 인터페이스로 따로 뺀 것입니다.)"*
+
+→ **MCP 룰 `pr-body-domain-vocabulary-with-screenshot`** ⭐⭐⭐ **신규** — *학생 자가 도메인 어휘 상세 설명 + 이미지 첨부 + 분리 의도 명시*. PR #150 (`student-bug-discovery-with-screenshot`)·PR #144 (m6z1 셀프 코드 리뷰) 결 합류 누적 3 PR — *학생 자가 스크린샷 어휘 정점*.
+
+→ **MCP 룰 `score-display-vs-score-compare-separation`** ⭐⭐⭐ **신규** — *점수 출력 = cards.scoreSum / 점수 비교 = strength* 분리 어휘. PR #134 (`score-vs-blackjack-score-locus`)·PR #50 (`bjackjack-vs-normal-win-different-responsibility`) 결 합류 누적 3 PR → ***도메인 책임 분리 어휘 정점*** ⭐⭐⭐.
+
+### 2. Money 연산자 오버로딩 칭찬 (Thread 3)
+
+reviewer: *"Money에 대한 연산자 오버로딩 좋습니다. 👍🏻"*
+
+→ **`operator-overload-times-domain`** 누적 4 PR (PR #37·#47·#150·#105).
+
+### 3. 테스트 꼼꼼 칭찬 (Thread 7)
+
+reviewer: *"테스트 꼼꼼하게 작성 잘 해주셨네요. 좋습니다. 👍🏻"*
+
+## 못한 점 (설계 관점)
+
+### 1. `stake` 어휘 — 학생 자가 *물음표 자조* (Thread 0)
+
+```kotlin
+val stake: Int  // 판돈
+```
+
+reviewer: *"정말 궁금해서 남깁니다. 🤔 `stake` 라는 뜻이 무엇인가요???"*
+
+학생 자가 답변:
+
+> *"판돈입니다! **뭔가 계속 물음표를 나게하는 코드라 죄송합니다..**"*
+
+→ **MCP 룰 `student-self-question-mark-self-deprecation`** ⭐⭐ 신규 — *학생 자가 *물음표 나게 하는 코드 죄송* 자조*. PR #150 (`못난이 코드`)·PR #144 (셀프 코드 리뷰) 결 합류 누적 3 PR — *학생 자조 어휘*.
+
+→ **`domain-vocabulary-uncommon-english`** ⭐⭐ — *`stake` = 판돈 도메인 영어 어휘 + reviewer 자가 의문*.
+
+### 2. 컨트롤러 없이 게임 가능? 상상 테스트 (Thread 1) — 정점
+
+reviewer:
+
+> *"한편으로는 이런 생각을 해 볼 수도 있는데요. **\"지금 블랙잭 프로그램은, 컨트롤러 없이 게임이 가능할까?\"** 컨트롤러에서 도메인 로직을 얼만큼 사용하고 있는가에 따라 다를 수 있는데 한번 고민해보시면 좋겠습니다. 따로 수정은 하지 않아도 됩니다"*
+
+→ **MCP 룰 `controller-imagination-test`** ⭐⭐⭐ **누적 2 PR** = PR #154 (laco-dev *"컨트롤러가 없더라도 블랙잭 게임을 진행할 수 있을까?"*) + PR #105. **동일 reviewer 양 PR 동일 어휘** → ***laco-dev reviewer 시그니처 어휘*** ⭐⭐⭐.
+
+### 3. StrengthPolicy Int → 객체 역할 (Thread 2)
+
+reviewer:
+
+> *"이미지 남겨주셔서 조금 이해할 수 있었습니다. **그런데 이 정책을 Int 타입으로 관리할 필요가 있나요?***
+>
+> ***Strength라는 객체를 만들었다면 무언가 역할을 쥐어 줄 수 있지 않을까요?***"*
+
+→ **MCP 룰 `policy-as-int-to-object-with-role`** ⭐⭐⭐ 신규 — *Policy = Int 원시값 / 객체 = 역할 부여*. PR #38 (`primitive-return-on-wrapped-value`)·PR #150 (`interface-without-polymorphism-purpose-loss`) 결 합류 — *원시값 vs 객체 역할 어휘 정점*.
+
+### 4. 1원 초기화 = 테스트용 생성자 자가 자가 자각 (Thread 4)
+
+```kotlin
+constructor(name: String) : this(name, Money(1))
+```
+
+reviewer: *"1원으로 초기화 하는 것은 무엇을 위한 생성자일까요?"*
+
+학생 자가 답변:
+
+> *"테스트가 깨져서 임시로 썼던 생성자입니다. 부 생성자를 없애고 Fixture에 가생성자를 만들어주었습니다. **제 코드가 계속 물음표를 드리네요..**"*
+
+→ **MCP 룰 `test-only-secondary-constructor-anti-pattern`** ⭐⭐ — *테스트용 부 생성자 = Fixture로 분리*. PR #154 (`factory-with-test-only-variant`) 결 합류 누적 2 PR.
+
+### 5. Stay 후 카드 변경 차단 (Thread 5)
+
+reviewer:
+
+> *"플레이어는 스테이 상태를 선언하면, 더 이상 카드를 뽑을 수 없게 됩니다. 이 개념을 구현 해보시면 좋겠어요!"*
+
+학생 자가 답변 (이해 확인):
+
+> *"stay 이후 cards의 변경을 막으라는 말씀으로 이해했는데 맞을까요?"*
+
+→ **`state-pattern-external-mutation-risk`** = PR #154 결 누적 강화.
+
+### 6. Statistics 단순 값 vs 수익률 계산 책임 (Thread 6)
+
+reviewer:
+
+> *"수익률을 계산하는 역할을 별도의 객체로 만드는 대신, 다른 객체가 일을 하도록 해보면 어떨까요? **지금의 Statistics 관련 객체들은 단순히 값만 가지는 용도로만 사용이 되고 있는데요.** 수익률을 계산하는데 가장 많은 정보를 알고 있을지도 모릅니다."*
+
+→ **MCP 룰 `statistics-as-pure-value-vs-responsibility`** ⭐⭐⭐ 신규 — *Statistics = 단순 값 보유 / 정보가 가장 많은 객체에 책임 부여*. PR #134 (`score-vs-blackjack-score-locus`)·PR #38 (`value-holder-vs-value-calculator-conflation`) 결 합류 누적 3 PR — *책임 위치 = 정보 보유자 어휘 정점*.
+
+### 7. reviewer 마무리 — 학생 따라옴 격려
+
+reviewer:
+
+> *"제가 여러모로 괴롭힌 것 같은데,, 싫은 티 안내고 잘 따라와주셔서 좋았습니다. 이후에도 스스로 생각한 규칙이나 기준이 따로 있다면, PR이나 코드를 통해 잘 드러나도록 작성해주시면 더욱 좋겠습니다."*
+
+→ **`reviewer-student-following-acknowledgment`** ⭐⭐ — *학생 따라옴 + PR/코드로 규칙 드러내기 권유*. PR #150 (`reviewer-student-passion-acknowledgment`) 결 합류.
+
+## 대표 인용
+
+> [aprilgom PR 본문]
+> *"참가자끼리 승패를 비교할 때는 이 strength를 이용해 비교를 하고, 점수 출력을 할 때에는 손에 있는 카드 점수의 총합을 이용해 출력합니다."*
+
+→ **점수 출력 vs 점수 비교 분리 어휘**.
+
+> [aprilgom Thread 4]
+> *"제 코드가 계속 물음표를 드리네요.."*
+
+→ **학생 자가 자조 어휘**.
+
+> [laco-dev Thread 1]
+> *"지금 블랙잭 프로그램은, 컨트롤러 없이 게임이 가능할까?"*
+
+→ **laco-dev 시그니처 어휘 (#154 + #105)**.
+
+> [laco-dev Thread 2]
+> *"Strength라는 객체를 만들었다면 무언가 역할을 쥐어 줄 수 있지 않을까요?"*
+
+→ **객체 역할 부여 어휘**.
+
+> [laco-dev Thread 6]
+> *"수익률을 계산하는데 가장 많은 정보를 알고 있을지도 모릅니다."*
+
+→ **정보 보유자 = 책임 부여 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **PR 본문 도메인 어휘 상세 설명 + 이미지** — **MCP 룰 `pr-body-domain-vocabulary-with-screenshot` 후보** ⭐⭐⭐.
+2. **점수 출력 vs 점수 비교 분리** — **MCP 룰 `score-display-vs-score-compare-separation` 후보** ⭐⭐⭐.
+3. **컨트롤러 없이 게임 가능? 상상 테스트 (laco-dev 시그니처)** — **MCP 룰 `controller-imagination-test` 후보** ⭐⭐⭐ 누적 2 PR.
+4. **Policy = Int / 객체 = 역할** — **MCP 룰 `policy-as-int-to-object-with-role` 후보** ⭐⭐⭐.
+5. **Statistics 단순 값 / 정보 보유자 = 책임** — **MCP 룰 `statistics-as-pure-value-vs-responsibility` 후보** ⭐⭐⭐.
+6. **학생 자가 *물음표 자조* 어휘 (누적 3 PR 자조 어휘)** — **MCP 룰 `student-self-question-mark-self-deprecation` 후보** ⭐⭐.
+7. **테스트용 부 생성자 = Fixture** — **MCP 룰 `test-only-secondary-constructor-anti-pattern` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **aprilgom 양 단계 완성 (1단계 #64 → 2단계 #105)** — *PR 본문 도메인 어휘 상세 설명 + 이미지 첨부 + 학생 자가 자조 어휘*.
+- **laco-dev reviewer 시그니처 어휘 — `controller-imagination-test`** 양 PR (#154 + #105) 동일 어휘.
+- **학생 자가 자조 어휘 누적 3 PR** (PR #144 + #150 + #105) — *학생 측 자가 자조 어휘 정점*.
+- **도메인 책임 분리 어휘 누적 3 PR** (PR #134·#50·#105) — *점수/승부/Statistics 책임 분리 정점*.

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

@@ -0,0 +1,279 @@
+# PR #64 — [블랙잭 1단계] 차람 미션
+
+- **Reviewee:** [@aprilgom](https://github.com/aprilgom)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/64
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 23 / 리뷰이 7)
+
+## 잘한 점 (설계 관점)
+
+- **`Participant` 추상 + `Player`/`Dealer`** + 후속에 `isBusted()`/`isBlackJack()` 공통화.
+- **`GameStatistics`로 게임 결과 집계 분리** (후속에 *PlayerStatistics + DealerStatistics 분리*).
+- **`reverseGameResult` 함수로 *Player → Dealer 역집계*** — PR #112·#135와 같은 패턴.
+- **후속 반영 — `DeckManager` 제거 (Controller로 이동) + `Cards` 일급 컬렉션 + Deck 명시 주입 + 통계 객체 분리**.
+
+## 못한 점 (설계 관점)
+
+### 1. `DeckManager` 명사 모호 + 책임 비대
+
+```kotlin
+class DeckManager {
+    private val deck: Deck = Deck()
+    fun initGame(dealer: Dealer, players: List<Player>) { ... }
+}
+```
+
+리뷰어: "*이 객체가 현재는 게임 진행을 위한 로직을 담당하고 있다면, DeckManager라는 이름은 적절할까요?*" / "*덱은 멤버 프로퍼티로 입력을 받지만, 딜러와 플레이어는 파라미터로 받고 있습니다. 왜일까요?* 혹시 *아래와 같이 초기화*를 한다면 어떻게 달라지나요? `class DeckManager(val players, val dealer, val deck)`"
+
+학생: "*DeckManager는 Deck을 관리하는 것이 의도였으니, 게임 진행을 위한 로직을 DeckManager가 맡는 것은 맞지 않은 것 같습니다.* *DeckManager에서 참가자들에게 초기 카드를 나눠주는 로직을 컨트롤러로 옮겼습니다.* 이후에 *DeckManager에 있던*..."
+
+→ **`Manager` 만능 명사**. *Deck 관리 + 게임 진행*이 한 객체에 = *책임 비대*. PR #92·#65·#128·#29와 같은 결.
+
+### 2. `GameStatistics.playerStatistics: Map<String, GameResult>` — String 키
+
+```kotlin
+val playerStatistics: Map<String, GameResult> by lazy {
+    players.associate { player -> player.name to judge(dealer, player) }
+}
+```
+
+리뷰어: "*`playerStatistics` 의 키값으로 가지고 있는 타입이 플레이어의 이름이라는 사실을 사용하는 측에서 알 수 있을까요??* *플레이어가 키값이 아닌 이유가 있을까요?*"
+
+학생: "*String으로 결과를 내놓아서 출력을 조금 편하게 해보려는 생각이었지만, PlayerName등으로 포장한다면 모를까 String만으로는 명확하지 않은 것 같습니다.* *거기에 더해 이런 의도면 도메인 로직에 뷰 로직도 섞이고 있다*..."
+
+→ **`String 키 = 출력 편의를 위한 도메인 침범**. `Map<Player, GameResult>` 또는 `Map<PlayerName, GameResult>` (PlayerName value class)가 자연.
+
+### 3. `dealerStatistics.get(GameResult.LOSE) ?: 0` — Map 노출
+
+```kotlin
+val dealerStatistics: Map<GameResult, Int> by lazy {
+    playerStatistics.values.map { reverseGameResult(it) }.groupingBy { it }.eachCount()
+}
+```
+
+리뷰어: "*마찬가지로 딜러의 통계가 의미하는 값이 무엇인지 불분명*합니다. 또한 *외부로 Map 타입이 그대로 드러나면서, 사용을 위해 불필요한 로직을 사용해야만 합니다*. `dealerStatistics.get(GameResult.LOSE) ?: 0` *의미를 다시 한번 클래스로 나타낸다면 사용하는 측에서도 명확하게 판단할 수 있지 않을까요?* `class DealerStatistics(...) { fun getWinningCount(): Int; fun getLoseCount(): Int; fun getDrawCount(): Int }`"
+
+→ **Map 그대로 노출 = 호출자가 키 추측 + `?:` 분기 필요**. `DealerStatistics` 객체로 *메서드 명시*. PR #25·#81·#125와 같은 결.
+
+### 4. `GameStatistics`가 *승부 비교 직접 수행*
+
+```kotlin
+class GameStatistics {
+    private fun judge(dealer: Dealer, player: Player): GameResult { ... }
+}
+```
+
+리뷰어: "*참가자와 참가자가 승부를 하는 동작은, 통계가 판단을 하는 것이 맞을까요? 아니면 참가자가 스스로 결정하는 것이 맞을까요?*"
+
+학생: "*참가자가 스스로 결정하는 것이 맞다 생각합니다. (CompareTo 처럼..) 하지만 승패판정 구현 당시에는 좋은 방법을 찾지 못해 이렇게 구현*했는데요, *플레이어가 먼저 버스트될 경우 패배이니 순차적으로 검사해야하겠다 인식*했..."
+
+→ **승부 비교는 참가자 자기 책임 — 17개+ PR 연속 권고**. 학생 자가 인식 + *구현 어려움*으로 *현재 형태 유지*. *Tell-Don't-Ask*의 *현실적 어려움*.
+
+### 5. `Participant.cardList: MutableList<Card>` — 일급 컬렉션 부재
+
+```kotlin
+abstract class Participant(val name: String) {
+    private val cardList: MutableList<Card> = mutableListOf()
+    fun addCard(card: Card) { cardList.add(card) }
+}
+```
+
+리뷰어: "*카드뭉치에 대한 동작과 상태를 책임지는 객체를 만들어 보면 어떨까요?* `Cards`" — *Hand 또는 Cards 일급 컬렉션* 권고. PR #79·#65·#10과 같은 결.
+
+### 6. `Player.threshold = 21` 지역 변수 + 상수 중복
+
+```kotlin
+class Player(name: String) : Participant(name) {
+    override fun isHitable(): Boolean {
+        val score = getCardSum()
+        val threshold = 21    // ⚠ 지역 변수 + 여러 곳 21 중복
+        ...
+    }
+}
+```
+
+리뷰어: "*`val threshold = 21` 반복되는 이 값은 어디에서 표현을 해야 좋을까요?* *지금의 구조에서는 만약 21점이 22점으로 변경된 순간 악몽이 시작*될 것 같습니다" — **매직넘버 + 지역 변수**. `BUST_THRESHOLD = 21` 도메인 상수. PR #128·#119·#81·#8와 같은 결.
+
+### 7. `Dealer.judge(participant)` — GameStatistics.judge와 중복
+
+```kotlin
+class Dealer(name: String = "딜러") : Participant(name) {
+    fun judge(participant: Participant): GameResult { ... }
+}
+```
+
+리뷰어: "*GameResult에서 판단하는 judge와는 어떤 차이가 있나요?*"
+
+학생 자가 인정: "*판정을 어디서 하면 좋을까 여기저기 시도하다 남은 흔적인데요, 삭제를 깜빡했습니다*... *딜러와 플레이어는 참가자로서 동격이라는 생각이라 둘 중 하나에 판정을 맡기는 것은 맞지 않다 생각합니다.*"
+
+→ **시도 중 남은 잔재**. *책임 위치 토론 → 임시 코드*가 *지워지지 않음*. PR #8와 같은 *주석 잔재*와 같은 결.
+
+### 8. `Deck`이 *카드 소진 시 셔플 재반환*
+
+```kotlin
+class Deck {
+    fun pick(): Card { if (cards.isEmpty()) cards = makeShuffledDeck(); ... }
+}
+```
+
+리뷰어: "*더이상 카드가 남아있지 않다면 카드를 섞어서 다시 반환하는게 맞을까요? 일반적으로 생각한다면 덱의 카드가 다 떨어진다면, 그것으로 끝일 것이라고 생각하지 않을까* 합니다. `fun pick(): Card?`" — *덱 소진 시 *재공급*은 의외 동작*. *null 반환*이 *Kotlin 자연*. PR #135·#116·#81과 같은 결.
+
+### 9. `Deck` 생성 시 즉시 셔플 — 결정적 테스트 불가
+
+```kotlin
+class Deck { private var cards: List<Card> = makeShuffledDeck() }
+```
+
+리뷰어: "*지금의 구조에서는 생성과 동시에 랜덤으로 카드가 준비되기 때문에 아래와 같은 테스트를 할 수가 없습니다.* 어떻게 개선할 수 있을까요? > *카드 뭉치에 A 스페이드 카드가 있을 때 카드를 한 장 뽑는다면 A 스페이드이다.*"
+
+학생: "*외부에서 카드 리스트를 받을 수 있도록 생성자를 만들었습니다.*" — PR #135·#111·#65와 같은 *카드 명시 주입* 권고.
+
+### 10. `Deck` 클래스 레벨 vs 지역 변수 일관성
+
+```kotlin
+class Controller {
+    private val deck = Deck()    // ⚠ 클래스 레벨
+    fun run() {
+        val dealer = Dealer()    // 지역 변수
+        val players: List<Player> = ...   // 지역 변수
+    }
+}
+```
+
+리뷰어: "*플레이어와 딜러는 run() 함수에서 만들어지는데 덱은 클래스에서 생성하는 장점이 있을까요?*" — PR #81와 같은 *Deck만 클래스 레벨 = Singleton 잔재*.
+
+### 11. `Cards.showCard()` 함수명 — *보여주다 vs List 변환*
+
+```kotlin
+class Cards { fun showCard(): List<Card> = ... }
+```
+
+리뷰어: "*`showCard()` 카드라는 이름은 무언가를 보여줘라 라는 행동으로 보이는데요. 컬렉션 함수에서 사용하기에는 의미가 맞지 않아 보입니다.* *컬렉션 함수의 사용방법과 유사하게 만들어봐도 좋을 것 같습니다.* `fun toList() = ...`" — *show*는 *UI 출력 동작* 연상. *컬렉션 변환*은 `toList()`. **함수명 = 동작 의미** 일치.
+
+### 12. `DealerStatistics.dealerStatistics.get(GameResult.LOSE) ?: 0`
+
+리뷰어: "*Map 함수의 getOrDefault(...)를 사용할 수 있습니다.*" — Kotlin stdlib *`getOrDefault`*.
+
+### 13. `Deck`이 *참가자 의존* — *참가자 → 덱 vs 덱 → 참가자*
+
+리뷰어: "*덱이 참가자에게 의존하는 것과 참가자가 덱에 의존하는 것에는 논리적인 차이가 있습니다.* 이전에 남겨드린 이 의문은 *아직 근본적으로 해결이 되지 않은 것 같아요*. - https://github.com/woowacourse/kotlin-blackjack/pull/64#discussion_r..." — **의존 방향 = 책임 위치**. *참가자가 카드를 받는 존재*면 *Participant → Deck 의존*. *Deck이 참가자에게 카드를 전달*하면 *Deck → Participant 의존*. *현실 비유 vs OOP 자율성*의 트레이드오프.
+
+### 14. `Player`의 *21점 = Bust 비교*
+
+리뷰어: "*이 문제는 어떻게 해결하는 건가요?*" — *Bust 판정의 위치* 토론. PR #135·#92·#114와 같은 결.
+
+### 15. `PlayerScorePolicy` — 버스트 시 -1 반환?
+
+```kotlin
+class PlayerScorePolicy { fun getScore(): Int = if (busted) -1 else score }
+```
+
+리뷰어: "*버스트가 되더라도 결과 점수를 출력해야 하는데요. 21점 초과라면 -1로 나오지 않을까요?*" — **Bust 시 *점수 = 실제 합산*이 자연**. *-1은 비교 트릭*인데 *출력*에 사용되면 *의미 왜곡*. PR #119와 같은 *0점 트릭*과 같은 결.
+
+### 16. `ScorePolicy.@JvmStatic` 어노테이션
+
+```kotlin
+class ScorePolicy {
+    companion object {
+        @JvmStatic fun ... { ... }
+    }
+}
+```
+
+리뷰어: "*`@JvmStatic` 어노테이션이 왜 추가되었을까요?*" — `@JvmStatic`은 *Java 상호 운용*에서 *static 호출*용. *Kotlin 전용 프로젝트*에서는 *불필요*. **Java 어휘/관례 잔재**.
+
+### 17. `ScorePolicy.BLACKJACK` 상수 의미 모호
+
+```kotlin
+class ScorePolicy { companion object { const val BLACKJACK = 21 } }
+```
+
+리뷰어: "*`ScorePolicy.BLACKJACK` 이라는 상수는 무엇을 의미하는것일까요?*" — *상수명 `BLACKJACK = 21`*은 *블랙잭 점수 = 21*이라는 *블랙잭 룰 부정확*. *21점 == 일반 21*과 *블랙잭(Ace+10 두 장)*의 *룰 차이*가 *상수에 반영 안 됨*. PR #128·#119와 같은 결.
+
+### 18. `OutputView`의 *플레이어 2장 / 딜러 1장 공개* — 비즈니스 룰
+
+리뷰어: "*> 플레이어는 처음 2장의 카드를 공개하고, 딜러는 처음 1장의 카드를 공개한다.* 이 규칙은 *비즈니스 로직으로 봐야 하지 않을까요?* *플레이어와 딜러가 같은 함수 아래서 다른 동작을 하도록 만드려면 어떻게 해야 할까요?*" — `Participant.openInitialCards()` 추상 메서드. PR #135·#92·#116과 같은 결.
+
+### 19. `DeckTest`가 *52장 검증*
+
+```kotlin
+@Test fun `덱은 52장이다`() { ... }
+```
+
+리뷰어: "*이 기능은 덱을 테스트 한 것이 아닌 것 같습니다. 덱의 경우 생성자를 통해 카드를 받을 수 있는데, 52장이 들어있다는 사실은 생성자로 무엇을 넣었는가에 따라 다를 것 같은데, 52장을 모두 넣는 것은 불필요한 작업으로 보입*..." — *생성자 주입 후*에는 *덱의 책임이 52장 보장*이 아님. *호출자가 넣은 카드 수*가 *덱의 size*.
+
+### 20. `PlayerTest`가 *플레이어 책임이 아닌 것 검증*
+
+리뷰어: "*이 테스트는 플레이어를 테스트 하는 것이 맞을까요?*" — *대상 책임만 검증*. PR #116·#33·#28과 같은 결.
+
+### 21. `Controller`가 *게임 결과 출력 시 여러 파라미터*
+
+리뷰어: "*게임 결과를 출력하기 위해 매번 파라미터를 모두 넘겨야 한다면, 해당 값을 객체로 만들어 볼 수도 있지 않을까요?* `class BlackjackGameResult(...) { ... }`" — *여러 파라미터 전달 = 객체로 묶음* 신호. PR #112·#135와 같은 결.
+
+### 22. `DealerTest` 함수명 — *true 반환 의미 모호*
+
+```kotlin
+@Test fun `더 받을 수 있는지 확인하면 true 반환`() { ... }
+```
+
+리뷰어: "*이 테스트로 봤을때 왜 true를 반환하는지가 나타나고 있을까요?* 기능적인 관점에서 접근한다면 이렇게 표현할 수 있지 않을까요? > *딜러는 카드의 총합이 16점보다 낮다면, 더 뽑아야 한다.*"
+
+학생: "*테스트의 이름이 코드의 동작을 표현할 뿐 무엇을 하고자 하는지 의도를 나타내지 못하고 있는 것 같습니다. 수정했습니다!*" — **테스트 함수명 = 시나리오 + 결과** (PR #28·#24·#114와 같은 결).
+
+## 리뷰어 의견 요지
+
+- ***`DeckManager` 만능 명사 + 책임 비대***.
+- ***`Map<String, GameResult>` String 키 = 도메인 침범***.
+- ***Map 그대로 노출 < `DealerStatistics` 객체 메서드***.
+- ***승부 비교 = 참가자 자기 책임*** (17개+ PR 연속).
+- ***`MutableList<Card>` < `Cards` 일급 컬렉션***.
+- ***`val threshold = 21` 지역 변수 + 매직넘버 중복***.
+- ***`Dealer.judge` + `GameStatistics.judge` 중복 = 시도 잔재***.
+- ***Deck 소진 시 재셔플 = 의외 동작***.
+- ***Deck 생성 시 즉시 셔플 = 결정적 테스트 불가***.
+- ***Deck 클래스 레벨 vs 지역 변수 일관성***.
+- ***`showCard` 명사 (보여주다) < `toList` 컬렉션 어휘***.
+- ***`getOrDefault` Kotlin stdlib***.
+- ***Deck ↔ Participant 의존 방향***.
+- ***`PlayerScorePolicy` Bust 시 -1 = 출력 의미 왜곡***.
+- ***`@JvmStatic` Java 상호 운용 = Kotlin 전용에 불필요***.
+- ***`ScorePolicy.BLACKJACK` 상수 = 블랙잭 룰 정확 의미***.
+- ***`DeckTest` 52장 검증 = 생성자 책임***.
+- ***Controller 결과 파라미터 = 객체로 묶음***.
+- ***테스트 함수명 = 의도 + 결과***.
+
+## 대표 인용
+
+> 마찬가지로 *딜러의 통계가 의미하는 값이 무엇인지 불분명*합니다. 또한 *외부로 Map 타입이 그대로 드러나면서, 사용을 위해 불필요한 로직을 사용해야만 합니다*.
+> — @laco-dev on `GameStatistics.kt`
+
+> 참가자와 참가자가 승부를 하는 동작은, *통계가 판단을 하는 것이 맞을까요? 아니면 참가자가 스스로 결정하는 것이 맞을까요?*
+> — @laco-dev on `GameStatistics.kt`
+
+> `val threshold = 21` 반복되는 이 값은 *어디에서 표현을 해야 좋을까요?* 지금의 구조에서는 만약 *21점이 22점으로 변경된 순간 악몽이 시작*될 것 같습니다.
+> — @laco-dev on `Player.kt`
+
+> 덱이 *참가자에게 의존하는 것과 참가자가 덱에 의존하는 것에는 논리적인 차이*가 있습니다.
+> — @laco-dev on `Deck.kt`
+
+> 플레이어는 처음 2장의 카드를 공개하고, 딜러는 처음 1장의 카드를 공개한다. *이 규칙은 비즈니스 로직으로 봐야 하지 않을까요?*
+> — @laco-dev on `OutputView.kt`
+
+## 얻은 교훈
+
+- ***`DeckManager` 만능 명사 = Deck 관리 + 게임 진행 흡수*** — *Manager/Information/Rule* 만능 명사 안티패턴. PR #92·#65·#128·#29와 같은 결.
+- ***`Map<String, GameResult>` String 키 = 출력 편의가 도메인 침범*** — `Map<Player, ...>` 또는 `Map<PlayerName, ...>` (value class).
+- ***Map 그대로 노출 < 객체 메서드*** — `getWinningCount()` / `getLoseCount()`. 17개+ PR 연속.
+- ***GameStatistics가 승부 판단 vs 참가자 자율*** — 학생 자가 인식 (`CompareTo 처럼`). *구현 어려움*으로 미완성. **18개+ PR 연속 권고**.
+- ***`val threshold = 21` 지역 변수 + 매직넘버 = 변경 악몽*** — 도메인 상수 단일 정의.
+- ***시도 중 남은 잔재 (`Dealer.judge` + `GameStatistics.judge`) = 책임 위치 토론의 흔적*** — *임시 코드 정리* 누락.
+- ***Deck 소진 시 재셔플 = 의외 동작*** — null 반환이 Kotlin 자연. PR #135·#116·#81과 같은 결.
+- ***Deck 생성 시 즉시 셔플 = 결정적 테스트 불가*** — 외부 카드 주입.
+- ***`@JvmStatic` Java 상호 운용 어노테이션 = Kotlin 전용에 불필요*** — *Java 어휘 잔재 신호*.
+- ***`ScorePolicy.BLACKJACK = 21` 상수명 = 블랙잭 룰 부정확 신호*** — *21 == 블랙잭*이 아님. *Ace+10 두 장만 진짜 블랙잭*.
+- ***플레이어 2장 / 딜러 1장 공개 = 비즈니스 룰 = Participant 추상 메서드*** — PR #135·#92·#116과 같은 결.
+- ***`showCard()` (보여주다) vs `toList()` (컬렉션 어휘)*** — 함수명 동작 의미 일치.
+- ***Bust 시 -1 트릭 = 출력 의미 왜곡*** — *Bust = 실제 합산*. *비교 알고리즘*에 *Bust 분기*가 자연.
+- ***DeckTest 52장 검증 = 생성자 책임*** — 호출자가 넣은 카드 수가 덱의 size.
+- ***Controller 결과 파라미터 4개+ = 객체로 묶음 신호*** — `BlackjackGameResult` 객체.

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

@@ -0,0 +1,188 @@
+# PR #18 — [블랙잭 1단계] 우기 미션
+
+- **Reviewee:** [@boogi-woogi](https://github.com/boogi-woogi)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/18
+- **단계:** 1단계
+- **리뷰어:** [@woowahan-leah](https://github.com/woowahan-leah) (**신규 reviewer — 12번째**)
+- **라인 코멘트:** 16 스레드 — *PR 본문 자가 의문 2개 (개행 컨벤션 + enum 매직 넘버) + Tell-Don't-Ask 강화 + 상속 vs 조합 외부 글*
+- **신규 reviewee** (2023년 3월 코호트).
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 2개**:
+  1. *"코드를 작성하면서 엔터를 치는 저만의 규칙이 있습니다. (ex. 함수 안에서 변수 선언이 모두 끝난뒤, 리턴하기 전, 클래스 바디가 시작할때) 그런데 이러한 엔터를 치는 규칙도 개발자들이 주로 따르는 컨벤션이 있는지 궁금합니다!"*
+  2. *"companion object로 선언할 수 없는 enum class 내부에서 쓰이는 매직 넘버들은 어떠한 형식으로 처리해야하는지 궁금합니다!"*
+  
+  **PR 본문 자가 의문 2개 모범**. PR #76·#82·#107·#46·#91·#11·#13·#80·#106·#14 결.
+- **enum class 내 `companion object` 가능 자가 학습** — woowahan-leah: *"enum class에도 다음과 같이 companion object를 선언할 수 있습니다!"* + 학생: *"넵 맞습니다!! 처음에 companion object의 상수를 enum class안에서 이용하려고 했었습니다. 그런데 enum class의 인스턴스들이 생성되는 시점에 companion object가 생성되지 않아서 사용할 수 없다는 것을 알게되었습니다! 이런 경우에 해당 파일의 상위에 private const val로 정의를 해도 괜찮을까요?"*. **PR #22 (RightHennessy *"enum 내 companion object 불가"* 자가 잘못된 가정)** 결의 *반대 시점 (실제 가능)* + *enum 인스턴스 생성 시점 vs companion object 생성 시점 자가 학습*.
+- **일급 컬렉션 구현 칭찬** — woowahan-leah: *"일급 컬렉션 구현 👍"*. PR #74·#108·#133·#46·#39·#82·#107 결.
+- **backing property 칭찬** — woowahan-leah: *"수업 시간에 배운 backing property 활용 👍 _cards 는 이미 MutableList로 선언되어 있는데 variable로 만들 필요가 있을까요?"*. PR #46·#16 결.
+- **딜러/플레이어 상속 vs 조합 칭찬 + 외부 글** — woowahan-leah: *"딜러와 플레이어의 중복 코드를 상속이 아닌 조합으로 해결한 방향 좋습니다 👍 어떤 과정으로 결론을 내리게 되셨나요?"* + 학생 자가 *솔직 답변*: *"솔직히 말씀드리면 구현하면서 그렇게 깊은 생각이 있었던 것은 아니었습니다😂 제가 왜 상속이 아닌 조합으로 코드를 구현했는지에 대한 근거를 곰곰히 생각해보겠습니다!"* + woowahan-leah 외부 글: *"[prolog techcourse 상속 vs 조합 글](https://prolog.techcourse.co.kr/studylogs/2773) 이 글을 참고해보시면 도움이 될 거예요."*. **학생 자가 *깊은 생각 없었음* 자가 솔직 인정 + 외부 글 자가 학습 모범** — PR #80 (Junyoung-WON *BaseHuman 추상화 자가 인정*) / PR #14·#106 결.
+- **학습 테스트 칭찬** — woowahan-leah: *"학습 테스트 👍"* (study/NumberTest).
+- **불필요 variable 제거 칭찬** — woowahan-leah: *"불필요한 variable 제거👍"*.
+- **UI 로직 제거 칭찬** — woowahan-leah: *"UI로직 제거 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. `enum class` 내 매직 넘버 — 학생 자가 의문 + woowahan-leah 답변
+
+학생 자가 의문 (PR #1, 본문): *"companion object로 선언할 수 없는 enum class 내부에서 쓰이는 매직 넘버들은 어떠한 형식으로 처리해야하는지 궁금합니다!"*
+
+woowahan-leah 답변 (위 §잘한점):
+
+```kotlin
+enum class GameResultCondition(
+    val gameResult: GameResult,
+    val condition: (playerScore: Int, dealerScore: Int) -> Boolean
+) {
+    ...
+
+    companion object {
+        private const val ...
+    }
+}
+```
+
+학생 후속 자가 의문: *"처음에 companion object의 상수를 enum class안에서 이용하려고 했었습니다. 그런데 enum class의 인스턴스들이 생성되는 시점에 companion object가 생성되지 않아서 사용할 수 없다는 것을 알게되었습니다! 이런 경우에 해당 파일의 상위에 private const val로 정의를 해도 괜찮을까요?"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *enum class + companion object 생성 시점 양가성*
+
+- *enum 인스턴스 생성 시점 (정적 초기화)* vs *companion object 생성 시점 (정적 초기화 이후)*.
+- *enum 인스턴스 *생성자 인자에서 companion 상수 참조* 시 = ClassNotInitialized*.
+- *enum 인스턴스 *메서드에서* companion 상수 참조 = OK*.
+
+**MCP 룰 후보 `enum-companion-init-order`**.
+
+#### 1.2. *enum 외부 top-level private const val 양가성*
+
+- *enum 외부 파일 상수 = 다른 곳에서 참조 가능 (의도 누수)*.
+- *enum 내부 companion = 응집 (단, 위 §1.1 시점 주의)*.
+
+PR #22·#11 (vagebond95/galcyurio *상수 위치*) 결.
+
+#### 1.3. *PR #22 (RightHennessy) 의 *enum 내 companion object 불가* 잘못된 가정* 반대 시점
+
+학생 자가 *enum 인스턴스 생성 시점* 인식 = *Kotlin 어휘 깊은 자가 학습*.
+
+### 2. `DrawState.POSSIBLE 외부 판단` → 메시지 던지기
+
+woowahan-leah: *"DrawState.POSSIBLE을 외부에서 판단하여 계산하지 말고 메세지만 던지는 구조로 바꿔보면 어떨까요?"*
+
+→ **Tell-Don't-Ask + enum 외부 분기 X**. PR #98·#43·#107·#137·#148 결.
+
+### 3. `getter 조작` vs 메시지 + 외부 글
+
+woowahan-leah: *"외부에서 값을 꺼내어(get) 조작하기보다 메세지를 던져 객체가 일하도록 해볼까요? 🙂 이 말이 잘 이해되지 않는다면 다음 글이 도움이 되면 좋겠어요. - https://homoefficio.github.io/2019/07/04/객체-지향-프로그래밍과-메시징/"*
+
+학생: *"전체적으로 아직 객체에 메시지를 던지면 객체가 일하도록 하는 구조를 제대로 구현하지 못하는것 같습니다! 리팩토링하면서 개선할 수 있도록 노력해보겠습니다!"*
+
+→ **외부 글 (homoefficio 블로그) 메시징 + Tell-Don't-Ask**. PR #91·#67·#23·#26·#16·#46·#77·#107·#82·#22 결.
+
+### 4. `Controller god-object → 도메인` (객체가 일하도록)
+
+woowahan-leah: *"이 로직은 컨트롤러에 어려울까요?? 도메인에 어울릴까요? 컨트롤러가 없어도 블랙젝 게임을 할 수 있도록, 객체가 일하도록 해보세요. 🙂"*
+
+→ **PR #72 (ghojeong *Controller + View 없이?*) 결의 강화**. PR #99·#107·#43·#46·#77·#48 결.
+
+### 5. `Card UI 의존성`
+
+woowahan-leah: *"만약 UI 요구사항이 바뀌어 뷰를 표기하는 방식이 바뀐다면 어떻게 될까요? UI 로직의 변경사항으로 인해 도메인 로직이 수정되는 상황이 발생하게 됩니다. 도메인 로직이 UI 로직에 의존하지 않도록 의존성을 끊어보면 어떨까요? :slightly_smiling_face:"*
+
+→ **enum-with-ui-value 강화**. PR #137·#77·#23·#26·#16·#9·#11·#13·#82·#22·#86·#100·#80 결.
+
+### 6. `Shape.values() + map`
+
+woowahan-leah: *"Shape값이 변경되면 이 코드도 변화해야 할까요? enum 클래스에서 제공하는 API중 모든 enum 값을 가져올 수 있는 API, map 연산자를 활용하여 변경해보면 어떨까요?"*
+
+→ **enum.values() + map = 확장 친화**. PR #82·#137·#39 결.
+
+### 7. `Cards.SMALL_ACE_VALUE / BIG_ACE_VALUE` 위치
+
+woowahan-leah: *"CardNumber에서 카드 숫자 값을 가지고 있는데 Cards 클래스에서 SMALL_ACE_VALUE, BIG_ACE_VALUE 값을 따로 갖는 것이 어색하다고 느껴질 수 있을 것 같아요. 어떻게 개선해볼 수 있을까요?"*
+
+→ **상수 위치 = 의미 응집**. PR #76·#11·#16·#9·#43·#137·#148 결.
+
+### 8. `GameResult.description` UI 로직
+
+woowahan-leah: *"description도 UI로직이라고 생각됩니다."*
+
+→ **MCP 기존 룰 `enum-with-ui-value`**. PR 다수 결.
+
+### 9. `chained call` 컨벤션
+
+woowahan-leah: *"코틀린 컨벤션에서 예시로 주신 사례에 대해서 별도로 강제하지는 않습니다! 보통 실무에서는 팀에서 일하는 개발자의 스타일에 따라 달라지곤 합니다. 참고로 chained call에 대해서는 다음과 같은 규칙이 있습니다."* + [Kotlin chained calls](https://kotlinlang.org/docs/coding-conventions.html#wrap-chained-calls)
+
+→ **PR #80 (Junyoung-WON *PR 본문 개행 규칙 자가 의문*) 와 같은 결의 응답**. *팀 스타일 + Kotlin chained call 공식 컨벤션*. PR #14·#82·#9 결.
+
+### 10. `CardNumber` 외부 분기 vs 객체 자체 — 매우 긴 토론
+
+woowahan-leah: *"CardNumber 외부에서 어떤 값인지 판단하기보다 객체 자체가 일할 수 있도록 하면 어떨까요? 이 말이 잘 이해되지 않는다면 오프라인 코드 리뷰를 진행해도 좋습니다😊"*
+
+학생: *"한번 충분히 고민해보고 개선하겠습니다!!"* + *"객체의 데이터를 외부에서 요구하는 것이 아니라 메시지를 통해서 객체 자체가 일할 수 있도록 만드는게 참 어려운거 같아요😂"*
+
+woowahan-leah: *"오프라인 코드리뷰를 요청하셔도 됩니다 ㅎㅎ"*
+
+학생: *"오늘까지만 한번 더 고민해보겠습니다!"*
+
+→ **3 가지 학습**:
+
+#### 10.1. *오프라인 코드 리뷰 권유*
+
+PR #99·#82·#46 (DM 권유) 결의 *오프라인 코드 리뷰 변형*.
+
+#### 10.2. *Tell-Don't-Ask 어려움 자가 인정*
+
+*"객체의 데이터를 외부에서 요구하는 것이 아니라 메시지를 통해서 객체 자체가 일할 수 있도록 만드는게 참 어려운거 같아요😂"* — **MCP `oh-my-oop` 의 *Tell-Don't-Ask* 어휘 학생 자가 인정**.
+
+#### 10.3. *학생 자가 *오늘까지만 한번 더* 시간 한정*
+
+**MCP 룰 후보 `time-boxed-self-learning`** = *학생 자가 시간 한정 학습*.
+
+## 리뷰어 의견 요지 (woowahan-leah) — **신규 reviewer (12번째)**
+
+16 코멘트 특징:
+
+- **외부 글 첨부** — *homoefficio 메시징 블로그 + prolog techcourse 상속 vs 조합 + Kotlin chained calls 공식 문서* — PR #22·#13·#16·#82·#46·#107 결.
+- **`👍`, `🙂`, `😊` 친밀한 어조** — *학생 친화 어조*.
+- **오프라인 코드 리뷰 권유** — **MCP 룰 후보 `offline-code-review-suggestion`**. PR #99·#82·#46 (DM 권유) 결의 *오프라인 변형*.
+- **수업 시간 인용** — *"수업 시간에 배운 backing property 활용 👍"* — **PR #107 (lee-ji-hoon *오늘 강의*) / PR #80 (Junyoung-WON *수업에서 배운 내용*) 결의 *강의 인용 reviewer 합류***.
+- **`enum class + companion object` 정확한 답변** — Kotlin 어휘 깊은 이해.
+- **여러번 *객체가 일하도록* 어휘 반복** — Tell-Don't-Ask 강조.
+
+## 대표 인용
+
+> *"솔직히 말씀드리면 구현하면서 그렇게 깊은 생각이 있었던 것은 아니었습니다😂 제가 왜 상속이 아닌 조합으로 코드를 구현했는지에 대한 근거를 곰곰히 생각해보겠습니다!"* — boogi-woogi (학생 자가 *깊은 생각 없었음* 자가 솔직 인정)
+
+> *"객체의 데이터를 외부에서 요구하는 것이 아니라 메시지를 통해서 객체 자체가 일할 수 있도록 만드는게 참 어려운거 같아요😂"* — boogi-woogi (Tell-Don't-Ask 어려움 자가 인정)
+
+> *"enum class의 인스턴스들이 생성되는 시점에 companion object가 생성되지 않아서 사용할 수 없다는 것을 알게되었습니다!"* — boogi-woogi (enum + companion 생성 시점 자가 학습)
+
+> *"외부에서 값을 꺼내어(get) 조작하기보다 메세지를 던져 객체가 일하도록 해볼까요?"* — woowahan-leah (Tell-Don't-Ask 메타 어휘)
+
+## 얻은 교훈
+
+1. **`enum class + companion object` 가능 (Kotlin 어휘)** — PR #22 (RightHennessy 잘못된 가정) 결의 *반대 시점*.
+
+2. **`enum 인스턴스 생성 시점 vs companion object 생성 시점`** — *생성자 인자 참조 시 NotInitialized*. **MCP 룰 후보 `enum-companion-init-order`**.
+
+3. **`상속 vs 조합` 외부 글 (prolog techcourse)** + **`학생 자가 *깊은 생각 없었음* 자가 솔직 인정`** — **MCP 룰 후보 `student-honest-no-deep-thought`**. PR #80·#14·#106 결.
+
+4. **`객체가 일하도록 (Tell-Don't-Ask)` 매우 어려운 자가 인정** — *학생측 어려움 명시*. PR 다수 결.
+
+5. **`오프라인 코드 리뷰 권유`** — **MCP 룰 후보 `offline-code-review-suggestion`**. PR #99·#82·#46 (DM 권유) 결의 *오프라인 변형*.
+
+6. **`수업 시간 인용 reviewer 합류` (woowahan-leah)** — PR #107·#80 결의 *강의 인용 패턴 강화*.
+
+7. **`chained call 컨벤션`** Kotlin 공식 문서. PR #14·#82·#9 결.
+
+8. **`enum.values() + map = 확장 친화`** Kotlin 어휘. PR #82·#137·#39 결.
+
+9. **`PR 본문 자가 의문 2개 + 솔직 답변` = 학습 가시화 모범** — PR #76·#82·#107·#46·#91·#11·#13·#80·#106·#14 결.
+
+10. **`시간 한정 자가 학습` (학생 *"오늘까지만 한번 더"*)** — **MCP 룰 후보 `time-boxed-self-learning`**.
+
+11. **`외부 글 다양성`** — homoefficio (메시징) + prolog techcourse (상속 vs 조합) + Kotlin chained calls + 학습 테스트.
+
+12. **`Shape.values() + map` 확장 친화** Kotlin enum 어휘.