oh-my-oop 0.2.0

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

@@ -0,0 +1,106 @@
+# PR #52 — [로피] 2단계 블랙잭
+
+- **Reviewee:** [@Choisehyeon](https://github.com/Choisehyeon) (로피)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/52
+- **단계:** 2단계
+- **리뷰어:** [@BeokBeok](https://github.com/BeokBeok) (커트/벅벅)
+- **라인 코멘트:** 6 스레드 — *PR 본문 3 인스턴스 변수 원칙 학생 자가 어려움 어휘 + 학생 자가 답변 2 thread / 와일드카드 import + null 보장 + 함수명 = 도메인 의도 + enum profitRate 칭찬 + 테스트 자세*
+- **Choisehyeon 양 단계 완성** (1단계 #9).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 3 인스턴스 변수 원칙 학생 자가 어려움
+
+PR 본문:
+
+> *"안녕하세요! 리뷰어님. **User 클래스에 베팅금액을 넣어버리면 프로퍼티가 3개가 되어서 그거에 대해 고민하느라 2단계 제출이 늦어졌습니다ㅠㅠ**"*
+
+→ **MCP 룰 `pr-body-three-instance-var-difficulty-vocabulary`** ⭐⭐ 신규 — *3 인스턴스 변수 원칙 학생 자가 어려움 명시*. PR #37 (`principle-as-guide-not-absolute` reviewer가 *원칙 = 가이드 / 절대 X* 권유) 결의 *학생 측 시간 손실* 다른 축.
+
+### 2. enum profitRate 칭찬 (Thread 4)
+
+reviewer: *"승패 관련해서 수익률까지 enum에 잘 적용해주셨네요. 👍"*
+
+→ PR #97 (`enum-with-domain-value-as-elegant`) 결 합류 누적 2 PR.
+
+### 3. 딜러 최종 수익 테스트 칭찬 (Thread 5)
+
+reviewer: *"딜러의 최종 수익을 반환하는 테스트 코드를 잘 작성해주셨네요. 👍"*
+
+## 못한 점 (설계 관점)
+
+### 1. 와일드카드 import 지양 + ktlint ref (Thread 1)
+
+```kotlin
+import blackjack.domain.*  // 와일드카드
+```
+
+reviewer:
+
+> *"코틀린에서는 와일드카드(*)를 사용하는 것을 지양합니다.*
+> *ref. https://pinterest.github.io/ktlint/rules/standard/#no-wildcard-imports"*
+
+→ **MCP 룰 `kotlin-wildcard-import-avoid`** ⭐ 신규 — *Kotlin 와일드카드 import 지양 + ktlint 공식 컨벤션 ref*. PR #47 (`underscore-prefix-backing-property-only` Kotlin 공식 컨벤션 ref) 결 합류 누적 2 PR.
+
+### 2. null 보장 (Thread 2)
+
+reviewer:
+
+> *"input이 null이 전달될 경우에는 어떻게 동작하게 될까요? **input이 반드시 null이 아님을 보장할 수 있을까요?**"*
+
+학생 자가 답변: *"InputView에서 getOrElse를 사용하여 null을 반환하지 않도록 수정했습니다!"*
+
+→ **`null-guarantee-via-getorelse`** ⭐⭐ — *`getOrElse` = null 회피 어휘*. PR #154 (`toIntOrNull-vs-type-check`) 결 합류.
+
+### 3. 함수명 = 도메인 의도 일치 (Thread 3)
+
+```kotlin
+// 변경 전 - 모호
+fun isBlackJackSize(): Boolean = cards.size == 2
+```
+
+reviewer:
+
+> *"함수명만 봐서는, 카드의 크기가 2인 경우에는 블랙잭 사이즈라고 이해가 되는데요. **카드 크기가 2인데 블랙잭이 아닌 경우도 있지 않을까요?** 물론, 카드가 2장이고 그 합이 21일 경우를 의도하셨겠지만, 다른 개발자가 보았을 때 이 로직만 보면 오해를 할 수 있지 않을까요?"*
+
+학생 자가 답변: *"isSizeTwo()로 네이밍 수정했습니다!"*
+
+→ **함수명 의도 일치 누적 16+ PR** — *카드 2 ≠ 블랙잭 도메인 정확성*. PR #12·#15·#101 등 결.
+
+### 4. 프로그램 실행 단위 개행 (Thread 0)
+
+reviewer: *"프로그램 실행 단위로 개행을 해주게 되면, 좀 더 코드를 읽기가 편해집니다."*
+
+→ PR #38·#54 (`blank-line-as-flow-boundary`) 결 누적 3 PR.
+
+### 5. 테스트 자세 — 딜러 패배 도메인 룰 (Thread 5)
+
+reviewer:
+
+> *"딜러인 경우에도 좀 더 자세하게 작성해보면 어떨까요? \"딜러가 패배하면 딜러는 모든 유저의 배팅금액만큼 잃는다\""*
+
+→ **테스트 명명 도메인 어휘** = 누적 다수.
+
+## 대표 인용
+
+> [Choisehyeon PR 본문]
+> *"User 클래스에 베팅금액을 넣어버리면 프로퍼티가 3개가 되어서 그거에 대해 고민하느라 2단계 제출이 늦어졌습니다ㅠㅠ"*
+
+→ **학생 자가 3 인스턴스 변수 원칙 어려움 어휘**.
+
+> [BeokBeok Thread 3]
+> *"카드의 크기가 2인 경우에는 블랙잭 사이즈라고 이해가 되는데요. 카드 크기가 2인데 블랙잭이 아닌 경우도 있지 않을까요?"*
+
+→ **함수명 = 도메인 정확성 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **3 인스턴스 변수 원칙 학생 자가 시간 손실** — **MCP 룰 `pr-body-three-instance-var-difficulty-vocabulary` 후보** ⭐⭐.
+2. **Kotlin 와일드카드 import 지양 + ktlint** — **MCP 룰 `kotlin-wildcard-import-avoid` 후보** ⭐.
+3. **`getOrElse` null 회피** — **MCP 룰 `null-guarantee-via-getorelse` 후보** ⭐⭐.
+4. **함수명 = 도메인 정확성 누적 16+ PR** = 강화.
+
+## 메타 노트
+
+- **Choisehyeon 양 단계 완성 (1단계 #9 → 2단계 #52)**.
+- **3 인스턴스 변수 원칙 어휘 누적** — PR #37·#52 — *학생 측 어려움 + reviewer *원칙 = 가이드 / 절대 X*. 단일 답 거부 어휘 누적 강화.

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

@@ -0,0 +1,282 @@
+# PR #9 — [블랙잭 1단계] 로피 미션
+
+- **Reviewee:** [@Choisehyeon](https://github.com/Choisehyeon)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/9
+- **단계:** 1단계 (페어)
+- **리뷰어:** @BeokBeok (벅벅)
+- **라인 코멘트:** 23 스레드 — *학생 자가 확장 함수 vs 멤버 함수 장단점 자가 정리 + Builder 패턴 호출 순서 + 외부 글 첨부*
+- **신규 reviewee** (2023년 3월 코호트). PR #16 (SeongHoonC) 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **확장 함수 vs 멤버 함수 장단점 학생 자가 매우 긴 답변** — 벅벅 메타 질문: *"winTo 함수를 확장함수 또는 멤버함수로 구현했을 때 각각 어떤 장단점이 있을지 고민해보면 어떨까요?"* + 학생 자가 답변:
+
+> **확장함수 장점:** *"코드가 간결해져서 가독성이 높다. 기존 클래스를 수정하지 않고도 새로운 기능 추가 할 수 있다, 수신 객체를 지정하지 않고도 User 클래스에 멤버 프로퍼티나 메서드에 접근할 수 있다."*
+>
+> **확장함수 단점:** *"네임스페이스 오염이 발생할 수 있다. 확장 함수는 클래스 외부에서 정의되므로, 클래스 내부의 함수와 이름이 충돌할 수 있다. 클래스의 캡슐화가 위반될 수 있다."*
+>
+> **멤버함수 장점:** *"클래스의 캡슐화를 보호할 수 있다. 클래스 내부에서 수행되므로 코드를 읽는 사람이 이를 의도적으로 이해하기 쉽다."*
+>
+> **멤버함수 단점:** *"클래스의 구조와 밀접하게 연관된 작업만 수행할 수 있기 때문에, 클래스의 구조를 변경하지 않고 새로운 기능을 추가하기 어려울 수 있다."*
+
+**Kotlin 어휘 학생 자가 4 분면 정리 모범** (장점 × 2 + 단점 × 2). PR #16 (SeongHoonC *abstract vs open*) / PR #91 (murjune *sealed vs abstract*) / PR #43 (chws0508 *interface 프로퍼티*) 결.
+
+- **`map` + `getter` 활용 칭찬** — 벅벅: *"getter와 map을 활용해서 participants를 Outcome 객체로 잘 변환해주셨네요. 👍"* — Kotlin 함수형 어휘.
+- **확장 함수 정공 칭찬** — 벅벅: *"winTo라는 확장함수를 잘 구현해주셨네요. 👍"* — *위 §장단점 토론 + 칭찬 양립*.
+- **`ACE 포함 여부` 함수 칭찬** — 벅벅: *"ACE가 포함 여부를 조회하는 함수를 잘 구현해주셨네요."*
+
+## 못한 점 (설계 관점)
+
+### 1. `setBlackJack()` 함수명 — set 계열 함수 컨벤션 위반
+
+벅벅: *"함수명만 봤을 때에는 '블랙잭을 설정한다' 라는 의미로 이해가 되는데요. 하지만 흔히 set 계열의 함수는 무언가를 리턴하는 것으로 예상되기 보다는, 단순히 값을 설정할 것으로 예상이 됩니다. 함수명이 구현체가 하는 일을 잘 표현하도록 함수명을 개선해보면 어떨까요?"*
+
+→ **JavaBean 컨벤션 + Kotlin**:
+- *`setX(value)`* = *값 설정 + Unit 반환* (관용).
+- *`set 동사 + 명사`* + *리턴값 보유* = *컨벤션 위반*.
+- 대안: *`createBlackJack()`*, *`buildBlackJack()`*, *`initializeBlackJack()`*.
+
+**MCP 기존 룰 `vagueName` 변형** + *set 접두사 컨벤션 위반 검사*. PR #99·#26·#39·#46 결.
+
+### 2. `winTo` 함수 = 프로퍼티 X (상태 vs 행동)
+
+벅벅: *"프로퍼티는 상태를 나타내며, 함수는 행동을 나타냅니다. winTo 함수는 상태라기보다는 행동을 의미합니다. 프로퍼티는 상태만을 갖도록 코드를 개선해보면 어떨까요?"*
+
+→ **Kotlin 어휘 (프로퍼티 vs 함수)**:
+- *프로퍼티* = *상태 (값) 표현*. 정적 의미.
+- *함수* = *행동 (계산/변환) 표현*. 동적 의미.
+- *`val winTo: ...` (프로퍼티)* < *`fun winTo(): ...` (함수)* — *행동은 함수 정공*.
+
+PR #91 (murjune *프로퍼티 vs 함수 자가 인정*) 결.
+
+### 3. `BlackJack 확장 함수` 위치 — 외부 발견 가능성
+
+벅벅: *"BlackJack 클래스와 관련된 확장 함수를 작성해주셨네요. 👍 BlackJack 클래스 내의 멤버 함수로 구현하는 것과, 다른 클래스에서 BlackJack의 확장함수를 만드는 것은 각각 어떤 장점이 있을까요? 만약 다른 개발자가 guestsTurn 함수와 dealerTurn 함수가 BlackJackGame에 정의가 되어있을 것이라 예상할 수 있을까요?"*
+
+→ **확장 함수 vs 멤버 함수 발견 가능성**:
+- *멤버 함수* = *클래스 내 즉시 가시 + 자동 완성*.
+- *확장 함수* = *외부 클래스에 정의 + import 필요 + 발견 어려움*.
+- *블랙잭 도메인 핵심 메서드 (guestsTurn, dealerTurn)* = *멤버 함수 정공*.
+
+PR #11 (위 학생 자가 4 분면) 의 *확장 함수 단점 (네임스페이스 오염)* 와 동일 결.
+
+### 4. `CardDeck` 외부 shuffle → 생성 시 shuffle
+
+벅벅: *"외부에서 shuffle 함수를 호출해줘야할까요? CardDeck 객체를 생성할 때 shuffle 해서 전달해줘도 되지 않을까요?"*
+
+→ **객체 invariant + 생성 시 보장**. PR #16 (SeongHoonC *init 블록 자가 적용*) / PR #77 (murjune *Deck shuffle 생성 시 1회*) 결.
+
+### 5. `Cards.toList()` 외부 호출 — 학생 자가 정당화
+
+벅벅: *"toList라는 함수를 외부에서 호출해줘야할까요? 외부에서 cards 변수에 접근해서 값을 조회하도록 개선해보면 어떨까요?"*
+
+학생 자가 정당화: *"캡슐화를 위해 toList 함수를 사용해서 호출해줬는데 직접 접근하게 된다면 Card.card.toList()과 같이 될 것 같아서 캡슐화를 하기 위해 위 방식으로 진행했습니다!"*
+
+벅벅 별도 (suggestion):
+
+```kotlin
+class Cards(val cards: Set<Card> = setOf()) {
+```
+
+*"대체로 Immutable한 컬렉션 타입이라면, 외부에 오픈이 되더라도 변경할 수 없습니다. private 접근자를 제거한다면, 불필요한 toList 함수를 만들지 않아도 됩니다."*
+
+→ **2 가지 학습**:
+
+#### 5.1. *Immutable 컬렉션 vs Mutable 컬렉션 외부 노출*
+
+- *`MutableList<Card>` 외부 노출* = *외부 변경 위험* → *방어적 복사 / `toList()` 필요*.
+- *`List<Card>` (Immutable interface)* = *외부에서 변경 불가* → *`toList()` 불필요*.
+- **단, `MutableList` 가 백킹 객체인 경우 `List` 인터페이스로 캐스팅해도 외부에서 `as MutableList` 가능** — PR #16 (SeongHoonC *LSP 자가 학습*) 결.
+
+#### 5.2. *학생 자가 정당화 (캡슐화 의도)*
+
+학생이 *`toList()` 가 캡슐화를 위한 것* 자가 명시. *그러나 Set<Card> immutable 이라면 노출해도 무해* — *학생 자가 학습 갭*.
+
+PR #74 (송핑크 *불변 객체 자가 학습*) / PR #46 (krrong *backing property*) 결.
+
+### 6. `OutputView` enum 출력 — 학생 자가 정당화 (View 영역)
+
+벅벅: *"지금과 같은 구조에서는 enum이 변경될 때마다 이 코드들도 변경을 해줘야합니다. enum만 변경해도 이 코드들이 영향을 미치지 않도록 코드를 개선해보면 어떨까요?"*
+
+학생 자가 정당화: *"저는 이부분이 출력에 관한 부분이라고 생각해서 enum에서 값을 넣어주는 것이 뷰의 역할을 가지고 있다는 생각이 들어서 위와 같이 진행했습니다!"*
+
+→ **enum 출력 위치 양가성**:
+- *학생 시점*: *View 가 enum → 문자열 변환 = View 영역*.
+- *벅벅 시점*: *enum 추가 시 View 코드 변경 강제 = 변경 파급*.
+
+대안:
+- (A) **enum.label / enum.displayName** — *enum 이 출력 문자열 보유*. **MCP 기존 룰 `enum-with-ui-value`** — *벅벅이 *enum 영역 누수* 진단하는 학생 자가 결정*.
+- (B) **View 가 enum-to-string Map** — *enum 추가 시 Map 추가 = 한 곳 변경*.
+- (C) **별도 mapper 객체** — *View ↔ enum 사이 변환 응집*.
+
+PR #28·#78·#112·#125·#147·#23·#26·#16·#77 의 *enum-with-ui-value* 결의 *반대 시점* — *View 가 enum 변환 책임 보유 학생 자가 결정*.
+
+### 7. `User` 3 변수 제약 (요구사항)
+
+벅벅: *"프로그램 요구사항에는 아래와 같은 항목이 있습니다. - 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다. 위 요구사항을 적용해보면 어떨까요?"*
+
+→ **요구사항 인용 (벅벅 패턴)**. PR #16 (SeongHoonC) 결.
+
+### 8. `Builder 패턴 호출 순서 + 지연 초기화`
+
+벅벅: *"Builder 패턴은 호출 순서와 상관 없이, build 함수를 호출하는 순간 객체가 정상적으로 만들어져야 합니다. 하지만, 아래와 같은 코드를 작성하게 되면 어떻게 될까요?"*
+
+```kotlin
+val blackjack = BlackJackBuilder().build()
+blackjack.participants
+```
+
+*"이를 해결하기 위해서는 어떻게 하면 좋을지 고민해보면 어떨까요? Builder 패턴의 장단점 및 지연초기화의 장단점에 대해서 학습해보면 좋을 것 같아요."*
+
+→ **3 가지 학습**:
+
+#### 8.1. *Builder 패턴 = 호출 순서 무관 + build() 시점 완성*
+
+- *학생 코드*: *`cardDeck()` 호출 후 `draw()` 호출* 필요 — *호출 순서 의존*.
+- *Builder 정공*: *내부 default 값 / required 인자 강제* + *build() 시점 invariant 검증*.
+
+#### 8.2. *지연 초기화 (`by lazy` / `lateinit var`)*
+
+- *`by lazy`* = *최초 접근 시 초기화 + 이후 캐싱*.
+- *`lateinit var`* = *향후 초기화 강제 + 접근 전 초기화 필수*.
+
+#### 8.3. *cardDeck 미호출 + draw 호출 시 NullPointerException*
+
+벅벅 별도: *"cardDeck 함수가 호출되지 않은 상태에서 draw 함수가 호출되면 어떤 일이 발생할까요? 이를 예방하려면 어떻게 개선하면 좋을지 고민해보면 어떨까요?"*
+
+PR #16 (SeongHoonC *init 블록 invariant*) 결.
+
+### 9. `introduce` + `companion init` 중복
+
+벅벅: *"introduce 함수와 BlackJackBuilder 클래스의 companion object의 init 함수의 구현체가 동일하네요. 그렇다면 중복되는 코드를 줄여보면 어떨까요?"*
+
+→ **DRY (Don't Repeat Yourself)** + *중복 코드 = 변경 시 N 곳 모두 수정*.
+
+### 10. `when exhaustive` (Kotlin 1.6+) — 외부 글
+
+벅벅: *"만약 CardValue의 값이 추가가 된다면, 별도로 신경을 쓰지 않는 이상 else 문으로 동작하게 되면서 예상치 못한 오류가 발생할 수 있습니다. when을 exhaustive하게 작성해보면 어떨까요?"* + [Kotlin 공식 문서 - exhaustive when](https://kotlinlang.org/docs/whatsnew16.html#stable-exhaustive-when-statements-for-enum-sealed-and-boolean-subjects).
+
+→ **Kotlin 1.6+ exhaustive when** — *enum 추가 시 컴파일 에러 강제*. PR #91 (murjune *sealed + when exhaustive 자가 학습*) / PR #137·#148·#90·#146 결.
+
+### 11. `when (binary)` vs `if` — 외부 글
+
+벅벅: *"binary condition인 경우에는 when 보다는 if문 사용을 권장해요. ref. https://kotlinlang.org/docs/coding-conventions.html#if-versus-when"*
+
+→ **Kotlin 코딩 컨벤션**:
+- *2 분기 = if 정공 (단순)*.
+- *3 분기 이상 = when 정공 (가독성)*.
+
+PR #26 (잭슨) / PR #16 (벅벅) / PR #43 (chws0508 자가 학습) 의 *동일 외부 글*.
+
+### 12. `forEach` vs `map` (변환 X)
+
+벅벅 suggestion: `participants.all().forEach { ... }` *"무언가를 변환하는 것이 아니라면 forEach를 활용해보면 어떨까요?"*
+
+→ **Kotlin 컬렉션 함수형 어휘**:
+- *`map`* = *값 변환* (`List<A>` → `List<B>`).
+- *`forEach`* = *부수 효과* (Unit 반환).
+
+PR #26 (잭슨 *forEach → map/groupingBy* — 반대 권고 — *map 활용*) 결의 *반대 시점*.
+
+### 13. `경계값 테스트 (20 vs 21)`
+
+벅벅: *"20자가 넘을 경우에 예외처리가 발생하는 것으로 이해하고 있습니다. 테스트 코드에서는 가급적이면 경계값을 위주로 테스트를 하는 것이 좋습니다. 여기에서는 이름을 21자에 대해서 테스트를 하는 것으로 개선하는 것을 권장합니다."*
+
+→ **경계값 테스트 (Boundary Value Analysis)** — *N + 1 검증*. 가장 흔한 버그 위치.
+
+### 14. `Cards.ACE 책임 = CardValue 메시지`
+
+벅벅: *"ACE가 포함 여부를 조회하는 함수를 잘 구현해주셨네요. 다만, Cards 클래스가 CardValue 객체에 대해서 너무 잘 알고 있어요. ACE를 관리하는 주체가 어디인지 고민해보시고, ACE를 관리하는 곳에 메시지를 보내서 ACE가 포함되어있는지 확인하도록 코드를 개선해보면 어떨까요?"*
+
+→ **Tell-Don't-Ask + 책임 위치**:
+- *`Cards.contains(CardValue.ACE)` = Cards 가 CardValue 분기 알기*.
+- *`Card.isAce()` = Card 가 자기 책임* → *`Cards.any { it.isAce() }`* 정공.
+
+PR #43·#74·#98·#137·#148 의 *Tell-Don't-Ask* 결.
+
+### 15. `= 표현식 함수` vs `{} 블록` Kotlin 어휘
+
+벅벅 suggestion: `fun initDraw() { ... }` *"`=` 을 사용하게 되면, 흔히 코드만 봤을 때 마치 리턴값이 있는 것처럼 보여요. 리턴타입이 없는 경우에는 `=` 보다는 중괄호를 사용해보면 어떨까요?"*
+
+→ **Kotlin 어휘**:
+- *`fun f(): Int = expr`* = *단일 표현식 + 리턴값*.
+- *`fun f() { stmt }`* = *블록 + Unit (보통 리턴 X)*.
+- *학생 코드 `fun f() = forEach { ... }`* = *Unit 반환 + `=` 사용 = 가독성 ↓*.
+
+### 16. `세팅이 된다` 테스트 함수명 모호
+
+벅벅: *"'세팅이 된다' 라는 것은 어떤 것을 의미할까요? 다른 개발자가 보았을 때에도 어떤 것을 의미하는지 알 수 있도록 함수명을 작성해보면 어떨까요?"*
+
+→ **테스트 명세서 어휘** — PR #26·#46·#99 결.
+
+### 17. `결과` 함수명 vs `Outcome` 리턴 타입 불일치
+
+벅벅: *"함수명만 봤을 때에는 '게임 결과'라는 의미로 해석돼요. 하지만 리턴타입은 Outcome이네요. 함수명만 봤을 때 리턴타입이 Outcome임을 알 수 있도록 개선해보면 어떨까요?"*
+
+→ **함수명 = 리턴 타입 추론 가능 권유**. *`fun getResult(): Outcome` < `fun toOutcome(): Outcome`*. PR #99·#39 (vagueName) 결.
+
+### 18. `->` 같은 라인 (Kotlin 컨벤션)
+
+벅벅 suggestion: `CardValue.TEN -> this.value.toString()` *"사소하지만, `->` 는 같은 라인에 작성하는 것을 권장합니다."*
+
+→ **Kotlin 코딩 컨벤션 (ktlint)**. PR #77 (KwonDae *ktlint 확인*) 결.
+
+### 19. `인덴트 depth ≤ 2` (요구사항)
+
+벅벅: *"아래 프로그래밍 요구사항을 적용해보면 어떨까요? - indent(인덴트, 들여쓰기) depth를 2를 넘지 않도록 구현한다. 1까지만 허용한다."*
+
+→ **요구사항 인용 (벅벅 패턴)** + **객체지향 생활 체조 원칙**.
+
+## 리뷰어 의견 요지 (벅벅 / BeokBeok)
+
+23 코멘트 특징 (PR #16 와 동일 reviewer):
+
+- **요구사항 인용** — *"프로그래밍 요구사항에는 아래와 같은 항목이 있습니다"* (3 회). PR #16 결.
+- **외부 글 첨부** — *Kotlin 공식 문서 (exhaustive when + if vs when)* — PR #16·#26·#23·#95·#67·#46·#77 결.
+- **suggestion 블록 활용** — `Cards(val cards: Set<Card>)`, `participants.all().forEach`, `fun initDraw() {}`, `-> ...` 4회. PR #26·#39·#43·#77 결.
+- **메타 질문 + 학생 자가 답변 유도** — *"확장함수 또는 멤버함수로 구현했을 때 각각 어떤 장단점이 있을지"* (학생 4 분면 답변 유도) / *"shuffle 함수를 호출해줘야할까요?"* / *"toList라는 함수를 외부에서 호출해줘야할까요?"*.
+- **학생 자가 정당화 인정 + 권고 유지** — `toList` 캡슐화 자가 정당화 + `enum` 출력 위치 자가 정당화. *학생 결정 존중 + 추가 권고*. PR #91·#43·#46 결.
+
+## 대표 인용
+
+> **확장함수 장점:** *"코드가 간결해져서 가독성이 높다. 기존 클래스를 수정하지 않고도 새로운 기능 추가 할 수 있다."* / **확장함수 단점:** *"네임스페이스 오염이 발생할 수 있다. 클래스의 캡슐화가 위반될 수 있다."* / **멤버함수 장점:** *"클래스의 캡슐화를 보호할 수 있다."* / **멤버함수 단점:** *"클래스의 구조와 밀접하게 연관된 작업만 수행할 수 있기 때문에, 클래스의 구조를 변경하지 않고 새로운 기능을 추가하기 어려울 수 있다."* — Choisehyeon (Kotlin 어휘 4 분면 자가 정리)
+
+> *"BlackJack 클래스 내의 멤버 함수로 구현하는 것과, 다른 클래스에서 BlackJack의 확장함수를 만드는 것은 각각 어떤 장점이 있을까요? 만약 다른 개발자가 guestsTurn 함수와 dealerTurn 함수가 BlackJackGame에 정의가 되어있을 것이라 예상할 수 있을까요?"* — BeokBeok (확장 함수 발견 가능성 메타 질문)
+
+> *"Builder 패턴은 호출 순서와 상관 없이, build 함수를 호출하는 순간 객체가 정상적으로 만들어져야 합니다."* — BeokBeok (Builder 패턴 정의 어휘)
+
+> *"캡슐화를 위해 toList 함수를 사용해서 호출해줬는데 직접 접근하게 된다면 Card.card.toList()과 같이 될 것 같아서 캡슐화를 하기 위해 위 방식으로 진행했습니다!"* — Choisehyeon (학생 자가 캡슐화 정당화)
+
+> *"저는 이부분이 출력에 관한 부분이라고 생각해서 enum에서 값을 넣어주는 것이 뷰의 역할을 가지고 있다는 생각이 들어서 위와 같이 진행했습니다!"* — Choisehyeon (enum 출력 위치 학생 자가 정당화)
+
+## 얻은 교훈
+
+1. **`확장 함수 vs 멤버 함수` 학생 자가 4 분면 정리** — *장단점 × 2 명시*. **Kotlin 어휘 자가 학습 모범**. PR #16·#43·#91·#74 결의 *학생 자가 학습 풍부 시리즈*.
+
+2. **`확장 함수 발견 가능성` = 외부 위치 + import 필요 = 도메인 핵심 메서드 부적합** — *멤버 함수 = 즉시 가시* / *확장 함수 = 외부 유틸*. **MCP 룰 후보 `extension-function-domain-misuse`**.
+
+3. **`Builder 패턴 호출 순서 + 지연 초기화`** — *호출 순서 의존 = Builder 정공 X*. *build() 시점 invariant 검증 + 지연 초기화 (`by lazy`)*. **MCP 룰 후보 `builder-call-order-dependency`**.
+
+4. **`set 접두사 함수명 + 리턴값 보유` 컨벤션 위반** — *`set 동사` = JavaBean = Unit 반환 관용*. PR #99·#26·#39·#46 의 *vagueName* 결.
+
+5. **`프로퍼티 vs 함수` = 상태 vs 행동** — *`val 이름`* = *상태* / *`fun 이름()` = *행동**. PR #91 (murjune *프로퍼티 vs 함수*) 결.
+
+6. **`Immutable 컬렉션 vs Mutable` 외부 노출** — *`Set<Card>` immutable = 외부 노출 OK + `toList()` 불필요*. PR #16 (SeongHoonC *LSP*) / PR #46 (krrong *backing property*) 결.
+
+7. **`enum 출력 위치 양가성`** — *학생: View 가 enum→string 변환 = View 영역* vs *reviewer: enum 추가 시 View 변경 강제 = enum 영역 누수*. **MCP 기존 룰 `enum-with-ui-value` 반대 시점**.
+
+8. **`when exhaustive` Kotlin 1.6+** — *enum/sealed/Boolean exhaustive 보장 + else 불필요*. PR #91 (murjune *sealed + when exhaustive*) 결.
+
+9. **`when (binary) vs if` Kotlin 컨벤션** — *2 분기 = if / 3 분기 = when*. PR #26·#16·#43 의 *동일 외부 글*.
+
+10. **`경계값 테스트` (Boundary Value Analysis)** — *N + 1 검증* = *예외 처리 가장 흔한 버그 위치*.
+
+11. **`= 표현식 함수` vs `{} 블록` Kotlin 어휘** — *Unit 반환 = 블록 / 리턴값 = 표현식*. PR #43·#39 의 *Kotlin 어휘 학습* 결.
+
+12. **`함수명 = 리턴 타입 추론 가능 권유`** — *`fun result()` < `fun toOutcome()`* — *명명 일관성*. PR #99·#39 결.
+
+13. **`인덴트 depth ≤ 2` 요구사항** — *객체지향 생활 체조 원칙*. PR #16·#23·#26 결의 *2023년 3월 코호트 요구사항 인용 패턴*.
+
+14. **`Tell-Don't-Ask + Card.isAce()` 책임 위치** — *Cards 가 CardValue 분기 알기 < Card 가 자기 책임*. PR #43·#74·#98·#137·#148 결.
+
+15. **`벅벅 reviewer 패턴`** — *요구사항 인용 + Kotlin 공식 문서 + suggestion 블록 + 메타 질문* — PR #16 와 *동일한 패턴*. **2023년 3월 코호트 reviewer 3인 중 가장 *외부 자료 + 컨벤션* 어휘 강도 높음**.

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

@@ -0,0 +1,182 @@
+# PR #14 — [블랙잭 1단계] 코건 미션
+
+- **Reviewee:** [@DYGames](https://github.com/DYGames)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/14
+- **단계:** 1단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 16 스레드 — *PR 본문 자가 의문 (뷰-모델 상호작용 + 람다 깊이) + ManualCardFactory Map suggestion + ordinal 지양*
+- **신규 reviewee** (2023년 3월 코호트). PR #22·#48 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 (뷰-모델 람다 깊이)** — *"질문드릴 점이 있는데, 게임에서 모든 플레이어들에게 한장의 카드를 더 받는지 결정하는 로직이 있습니다. 이때 뷰와 모델의 로직이 복잡하게 상호작용하는데, 이를 저는 람다를 이용해서 해결하였는데 여전히 복잡하고 코드 깊이가 깊어집니다. 어떻게 생각하고 구현하면 좀 더 깔끔하고 분리된 코드를 작성할 수 있을지 궁금합니다."* — **PR 본문 자가 의문 모범**. PR #76·#82·#107·#46·#91·#11·#13·#80·#106 결.
+- **방어적 복사 칭찬** — galcyurio: *"방어적 복사 :+1:"*. PR #74·#108·#133·#46·#23 결.
+- **UI layer 도메인 의존 칭찬** — galcyurio: *"ui layer에서 domain layer를 의존하여 데이터를 받아서 렌더링하도록 잘 구현해주셨네요 :+1:"*. PR #22 (galcyurio *UI→Domain OK*) 결.
+- **불필요 정보 분리 자가 적용** — galcyurio: *"불필요한 정보를 잘 분리해주셨습니다 👍"* + 학생 자가 함수 분리. PR #22 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `y/n CLI 환경 의존 → Boolean (GUI 가정)`
+
+galcyurio: *"`y`, `n`은 CLI 환경에서만 실행될 것이라는 전제가 깔려있으며, 또한 외부에서는 Boolean으로 사용되고 있습니다. Boolean으로 사용하는게 오히려 가독성도 좋고 더 유연해집니다. 이 프로그램을 그대로 GUI 환경에서도 쓴다고 생각하고 만들어보세요."*
+
+학생: *"View 단에서 Boolean으로 검증, 변환해주었습니다."*
+
+→ **CLI vs GUI 가정 메타 어휘**:
+- *`y`/`n` 도메인 = CLI 한정*.
+- *Boolean = 도메인 추상화 + GUI 전환 가능*.
+
+**MCP 룰 후보 `cli-vs-gui-assumption-test`**. PR #137 (HamBeomJoon *Multi-platform 함정*) / PR #41·#151·#80·#82·#100 결.
+
+### 2. `if/when 중괄호` 공식 컨벤션
+
+galcyurio: *"[공식 컨벤션](https://kotlinlang.org/docs/coding-conventions.html#control-flow-statements)에 따르면 if문과 when문은 2줄 이상이면 중괄호를 사용합니다."*
+
+→ **Kotlin 공식 컨벤션**. PR #82·#9·#16·#26 결.
+
+### 3. `ManualCardFactory` 테스트 전용 + Map 받기
+
+galcyurio: *"ManualCardFactory는 테스트를 위한 Fake 구현체이기 때문에 이를 위한 테스트 케이스는 작성되어선 안됩니다. 추가로 ManualCardFactory는 현재 테스트 케이스를 제외하고는 그 어떤 테스트 케이스에서도 쓰이지 않고 있네요. CardFactory를 의존하고 있는 BlackjackStage에 대한 테스트 케이스를 작성하다보면 필요해질 겁니다."*
+
+galcyurio (Map suggestion):
+
+```kotlin
+// AS-IS
+val cardFactory = ManualCardFactory(
+    listOf(CardType.CLUB, CardType.SPADE), listOf(CardNumber.THREE, CardNumber.QUEEN)
+)
+
+// TO-BE  
+val cardFactory = ManualCardFactory(mapOf(
+    CardType.CLUB to CardNumber.THREE,
+    ...
+))
+```
+
+galcyurio 자가 *착각 사과*: *"제가 착각하고 잘못 말씀드렸네요 🙏🙇 이 구현체는 테스트를 위한 구현체니까 단순히 원하는대로 반환을 시키면 됩니다. 테스트 가독성을 위해 List로 받는 대신 Map을 받도록 처리해보면 어떨까요?"*
+
+→ **3 가지 학습**:
+
+#### 3.1. *Test Fake 구현체 = 자체 테스트 X*
+
+- *Fake = 테스트용 도구 = 의존하는 코드 테스트할 때 사용*.
+- *Fake 자체 테스트 = 무의미*.
+
+**MCP 룰 후보 `test-fake-self-test-anti-pattern`**. PR #145 (junseo511 *unaryMinus 무의미 테스트*) / PR #99·#91 결.
+
+#### 3.2. *List<A> + List<B> vs Map<A,B>* — 데이터 구조 변경
+
+*두 리스트의 i 번째 페어* < *Map 의 명시적 페어*.
+
+#### 3.3. *reviewer 자가 *착각* 사과*
+
+PR #91·#77·#46·#16·#95·#137·#107·#145·#48 결.
+
+### 4. `it/it2` 변수명 — 명시적 명명
+
+galcyurio: *"`it`, `it2` 대신 알맞은 이름을 명시해보세요."*
+
+학생: *"각각 cardType, cardNumber로 변경하였습니다."*
+
+→ **중첩 람다 명시 명명**. PR #13·#107·#145 결.
+
+### 5. `when expression vs if expression`
+
+galcyurio: *"when expression을 활용하여 `''`와 같은 불필요한 반환을 없애보세요. 변환 후에 CardType이나 CardNumber를 추가해보고 if expression과 when expression 2개 방식에 어떤 차이점이 있는지도 정리해보면 좋겠어요."*
+
+학생: *"enum 클래스에서 when expression을 사용할 때는, else 브랜치를 사용하지 않을때 enum의 모든 항목에 대해 브랜치를 관리하도록 강제하는 차이가 있다고 정리했습니다."*
+
+→ **MCP 기존 룰 `sealed-class-when-exhaustive`** (enum 변형) — *when exhaustive + else 강제*. PR #91·#9·#26·#43·#16·#76 결.
+
+### 6. `테스트 static import 컨벤션`
+
+galcyurio: *"프로덕션 코드에서는 static import를 하지 않는게 컨벤션이지만 테스트 코드에서는 static import를 하는게 컨벤션입니다."*
+
+```kotlin
+assertThat(isDistributable).isTrue
+```
+
+→ **테스트 코드 컨벤션 = 프로덕션과 다름**. **MCP 룰 후보 `test-static-import-convention`**.
+
+### 7. `테스트 가독성 = 불필요 정보 분리`
+
+galcyurio: *"테스트 본문에는 테스트하고자 하는 것을 이해할 수 있는 정보를 모두 가지고 있어야 하고, 반대로 불필요한 내용을 전부 감추어야 합니다."* + [Google Testing Blog](https://testing.googleblog.com/2014/03/testing-on-toilet-what-makes-good-test.html) + *"이 테스트 케이스에서 중요한 건 숫자의 합입니다. 그 이외에 `CardType.HEART`와 같은 코드는 보이지 않도록 만들어보세요."*
+
+학생: *"Int를 입력받아 같은 수를 가지는 Cards를 생성하는 함수를 분리하여 테스트 코드의 가독성을 높였습니다."*
+
+galcyurio 별도: *"테스트 코드에서는 가독성이 중요합니다. 적절한 개행을 통해 CardNumber.TEN, CardNumber.TEN, CardNumber.TWO가 잘 보이도록 하거나 불필요한 코드를 테스트 본문 밖으로 분리해보세요."*
+
+→ **PR #22 (galcyurio *Google Testing Blog*) 와 같은 결**. *동일 reviewer 동일 어휘 강화*. PR #22 결.
+
+### 8. `when actual vs then expected` 위치
+
+galcyurio: *"when절에 실제값(actual)이 위치해야하고 then절에 기댓값(expected)가 위치해야 합니다."*
+
+→ **GWT 패턴 표준**. PR #99·#46·#107·#145·#9 결.
+
+### 9. `뷰-모델 람다 깊이` PR 본문 자가 의문
+
+galcyurio: *"특정 시점에 View의 함수를 호출해야 한다는 점 때문에 이런 코드가 생긴 것으로 보이네요. domain layer로 ui layer의 고차 함수를 넘겨서 처리하겠다는 방법은 좋습니다 :+1: 여러 가지를 한꺼번에 처리하다보니 복잡해진 것 같은데 작은 문제 여러개로 나누어서 처리해보세요. - 고차함수 하나에서 너무 많은 작..."*
+
+학생: *"도메인 로직은 최대한 도메인 안으로 이동하고, 고차 함수 전달과 반환을 적절히 활용하여 수정하였습니다."*
+
+→ **고차 함수 + 작은 문제 분해**. PR #145·#107·#82·#100·#80·#48 결.
+
+### 10. `BlackjackStageTest` 테스트 케이스명 명확화
+
+galcyurio: *"BlackjackStageTest의 테스트 케이스 이름들도 조금 더 명확하게 작성해보면 좋겠어요!"*
+
+→ **테스트 = 명세서 어휘**. PR #22·#26·#46·#99·#107·#145·#9 결.
+
+### 11. `ordinal 사용 지양`
+
+galcyurio: *"ordinal 사용은 지양해주세요. 사용하더라도 enum 간의 순서가 바뀌었을 때 문제없어야 합니다."*
+
+→ **ordinal 의존 = 순서 변경 시 깨짐**. **MCP 룰 후보 `enum-ordinal-dependency`** (기존 룰 후보 강화). PR #137 (HamBeomJoon *enum-ordinal-dependency*) 결.
+
+### 12. `테스트 함수 위치`
+
+galcyurio: *"별개로 테스트 클래스에서 중요한 부분은 테스트 본문이므로 해당 함수들은 테스트 함수들 아래쪽에 작성해주시는게 좋습니다. :)"*
+
+→ **테스트 파일 구조**. PR #22·#145 결.
+
+## 리뷰어 의견 요지 (galcyurio)
+
+16 코멘트 특징 (PR #22·#48 와 동일 reviewer):
+
+- **공식 컨벤션 외부 자료** — *Kotlin coding-conventions, Google Testing Blog* — PR #22·#48 결.
+- **suggestion 블록 활용** — Map 자료구조 + `assertThat ... isTrue` 코드.
+- **`:+1:`, `🙏`, `🙇` 친밀한 어조** — PR #22·#48 일관.
+- **자가 *착각* 사과** — PR #91·#77·#46·#16·#95·#137·#107·#145·#48 결.
+
+## 대표 인용
+
+> *"`y`, `n`은 CLI 환경에서만 실행될 것이라는 전제가 깔려있으며 (...) 이 프로그램을 그대로 GUI 환경에서도 쓴다고 생각하고 만들어보세요."* — galcyurio (CLI vs GUI 가정 메타)
+
+> *"ManualCardFactory는 테스트를 위한 Fake 구현체이기 때문에 이를 위한 테스트 케이스는 작성되어선 안됩니다."* — galcyurio (Test Fake 자체 테스트 안티패턴)
+
+> *"enum 클래스에서 when expression을 사용할 때는, else 브랜치를 사용하지 않을때 enum의 모든 항목에 대해 브랜치를 관리하도록 강제하는 차이가 있다고 정리했습니다."* — DYGames (Kotlin when exhaustive 자가 학습)
+
+> *"제가 착각하고 잘못 말씀드렸네요 🙏🙇"* — galcyurio (reviewer 자가 *착각* 사과)
+
+## 얻은 교훈
+
+1. **`CLI vs GUI 가정 메타`** — *`y`/`n` 도메인 = CLI 한정 / Boolean 추상화 = GUI 전환 가능*. **MCP 룰 후보 `cli-vs-gui-assumption-test`**. PR #137·#41·#151·#80·#82·#100 결.
+
+2. **`Test Fake 구현체 자체 테스트 X`** — *Fake = 의존 코드 테스트 도구 / Fake 자체 테스트 = 무의미*. **MCP 룰 후보 `test-fake-self-test-anti-pattern`**. PR #145·#99·#91 결.
+
+3. **`테스트 static import 컨벤션`** — *프로덕션과 다름*. **MCP 룰 후보 `test-static-import-convention`**.
+
+4. **`ordinal 의존 = 순서 변경 시 깨짐`** = 기존 룰 후보 강화. PR #137 결.
+
+5. **`when expression exhaustive`** Kotlin 어휘. PR #91·#9·#26·#43·#16·#76 결.
+
+6. **`when actual / then expected` GWT 위치 규칙**. PR #99·#46·#107·#145·#9 결.
+
+7. **`테스트 가독성 = 불필요 정보 분리`** (Google Testing Blog). PR #22 결의 *동일 reviewer 동일 어휘*.
+
+8. **`고차 함수 + 작은 문제 분해`** — *복잡 람다 = 분해*. PR #145·#107·#82·#100·#80·#48 결.
+
+9. **`if/when 중괄호` 공식 컨벤션**. PR #82·#9·#16·#26 결.
+
+10. **`Map<A,B> vs List<A> + List<B>`** = 데이터 구조 = 가독성.