oh-my-oop 0.2.0

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

@@ -0,0 +1,265 @@
+# PR #47 — [하티] 2단계 블랙잭
+
+- **Reviewee:** [@sujin9](https://github.com/sujin9) (하티)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/47
+- **단계:** 2단계
+- **리뷰어:** [@BeokBeok](https://github.com/BeokBeok) (커트/벅벅) — 2023 코호트 reviewer
+- **라인 코멘트:** 13 스레드 — *학생 자가 답변 풍부 (5 thread) / 메서드 참조 = 함수형 프로그래밍 어휘 정점 + 테스트 커버리지 100 강박 vs 의미 메타 + 컨트롤러 *브릿지* 메타포 PR 본문 + 테스트 명명 부정형 → 긍정형 변환 + 람다 `it` 명시 + argument name 가독성 + 1.5/1.0 매직넘버 + 방어적 복사*
+- **sujin9 양 단계 완성** (1단계 #15). sujin9 양 단계 완성.
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 컨트롤러 *브릿지* 메타포
+
+PR 본문:
+
+> *"컨트롤러가 그저 `view`와 `domain`을 연결하는, 마치 `브릿지`와 같은 역할만 할 수 있도록 리팩토링을 해보았습니다."*
+
+→ **MCP 룰 `controller-as-bridge-metaphor`** ⭐⭐ 신규 — *컨트롤러 = view↔domain 브릿지 메타포*. PR #154 (laco-dev *"컨트롤러 없이 진행 가능?"*)·PR #72 (`controller-classification-criteria`)·PR #100 (`pseudo-domain-controller-layer`) 결의 *컨트롤러 책임 분리* 다른 축 — *학생 자가 브릿지 어휘*.
+
+### 2. 학생 자가 답변 + 깊은 의문 (5 thread)
+
+- Thread 1 (메서드 참조): 학생 자가 깊은 답변 + reviewer 확인 요청 *"제가 말한 부분이 맞는지, 혹은 놓친 부분이 있을지 궁금해요!"*.
+- Thread 7 (덱 모두 뽑기): 학생 자가 *카드 다시 채움* 의도 설명.
+- Thread 8 (게임 흐름 테스트): 학생 자가 깊은 토론 + reviewer 의견 요청 *"커트라면 어떻게 테스트를 작성하실지 궁금해요"*.
+
+### 3. `operator fun` 활용 칭찬 (Thread 2)
+
+reviewer: *"operator fun 활용 👍"*. BettingMoney 연산자 오버로딩.
+
+## 못한 점 (설계 관점)
+
+### 1. 메서드 참조 = 함수형 프로그래밍 어휘 (Thread 1) — 정점
+
+reviewer:
+
+> *"메서드 참조를 잘 활용해주셨네요. 👍 일반 함수에 비해 메서드 참조가 갖는 장점은 무엇인지 학습해보시면 어떨까요?"*
+
+학생 자가 답변 정점:
+
+> *"공부해보면서 아직 확실하게 아는 건 아니지만 제 생각을 적어보면요..!*
+>
+> *- 코드가 간결해지고 가독성이 좋아집니다.*
+> *- 만약 `game.startGame(participant) { ResultView.printSetUp() }` 과 같은 형태로 쓰게 된다고 했을 때, 만약 함수에 매개변수가 있는 경우라면 매개변수를 함께 담아서 함수를 전달해야 합니다. 하지만 메소드 참조를 사용하면 이를 나중에 지정해줄 수 있다는 장점이 있는 것 같아요!*
+>
+> ***제가 말한 부분이 맞는지, 혹은 놓친 부분이 있을지 궁금해요!*** 😄"*
+
+reviewer 첨언 정점:
+
+> *"잘 정리해주셨습니다. 👍 첨언드리자면, **메서드 참조는 input을 가공없이 그대로 함수 파라미터로 전달하기 때문에, 데이터가 전달되는 과정에서 훼손되지 않았음을 확신할 수 있습니다.** 즉, 동일한 input이면 동일한 output이 나올 것이라 기대할 수 있습니다.*
+>
+> ***\"동일한 input이면 동일한 output이 나온다\"라는 매커니즘은 \"함수형 프로그래밍\"의 매커니즘입니다.*** 😅"*
+
+→ **MCP 룰 `method-reference-as-functional-vocabulary`** ⭐⭐⭐ **신규 정점** — *메서드 참조 = 데이터 훼손 X + 함수형 프로그래밍 동일 input → 동일 output 매커니즘*.
+
+→ **`student-self-correction-request-vocabulary`** ⭐⭐ — *"제가 말한 부분이 맞는지, 놓친 부분이 있을지 궁금해요"* 학생 자가 확인 요청 어휘. PR #82·#149 등 학생 자가 질문 결.
+
+### 2. 테스트 커버리지 100 강박 vs 의미 (Thread 8) — 정점
+
+```kotlin
+// BlackjackGameTest
+@Test
+fun `게임을 오류없이 실행한다`() {
+    BlackjackGame().apply {
+        startGame(participant, ::output)
+        runPlayer(participant.players, ::isHit, ::output)
+        runDealer(participant.dealer, ::output)
+    }
+}
+```
+
+reviewer: *"게임을 오류없이 실행한다는 것은 어떤 의미일까요? 여기서 말하는 \"오류가 없다\" 라는 것은 어떤 오류를 말하는 걸까요?"*
+
+학생 자가 답변:
+
+> *"게임이 전체적으로 중간에 종료되거나 다른 오류 없이 잘 끝나는, 전체적인 로직의 `흐름`에 대한 테스트를 하고 싶어서 이렇게 작성하였었습니다. 다른 구체적인, 디테일한 오류들에 대해서는 다른 단위 테스트들이 있기 때문에 모든 경우의 수를 테스트하는 것은 굳이 필요하진 않다고 생각했어요!*
+>
+> ***혹시 이런 상황에서는 테스트가 굳이 필요한지, 필요하다면 어떻게 테스트를 하면 좋을까요?*** 다른 더 나은 테스트 방법이 있는지, 혹은 커트라면 어떻게 테스트를 작성하실지 궁금해요 😊"*
+
+reviewer 정점:
+
+> *"적어도 테스트는 명확한 요구사항이 기재되어야 합니다. 그렇지 않은 테스트는 의미가 없으며, **반드시 성공하는 테스트 코드를 작성하기 쉽게 됩니다.** 또한, 테스트 코드에는 가급적이면 로직을 넣지 않는 것이 좋습니다.*
+>
+> *모든 로직에 단위 테스트를 작성하는 것은 좋으나, **그렇다고 반드시 성공하는 테스트를 작성하는 것은 의미가 없습니다. 저라면, 이런 경우라면 차라리 테스트 코드를 작성하지 않습니다.** 그럼에도 불구하고 테스트 코드를 작성해야한다면, \"BlackJackGame 객체를 생성합니다.\" 와 같은 테스트 코드를 작성할 수 있을 것 같아요."*
+
+학생 자가 답변:
+
+> *"모든 로직에 테스트를 작성해야 한다는 생각과, 굳이 이게 작성할 필요가 있는 테스트인가에 대한 고민이 계속 있었는데 의견 감사해요! :)*
+>
+> ***앞으로 다음 미션에서는 테스트 커버리지를 100 만드는 것만 생각하기 보다는, 테스트의 의미에 더 집중해야겠어요*** 😄"*
+
+→ **MCP 룰 `coverage-100-vs-test-meaning`** ⭐⭐⭐ **신규 정점** — *테스트 커버리지 100 강박 vs 테스트 의미 — 학생 자가 자각*.
+
+→ **MCP 룰 `always-passing-test-anti-pattern`** ⭐⭐⭐ **신규** — *"반드시 성공하는 테스트 = 의미 없음 + 차라리 안 쓰는 게 낫다"* reviewer 명시 어휘.
+
+→ **MCP 룰 `test-with-logic-anti-pattern`** ⭐⭐ — *테스트 코드에 로직 포함 X*. PR #14·#48·#86 (테스트 어휘) 결 합류.
+
+→ **MCP `oh-my-oop` 핵심 가치 학생 측 메타 어휘** — *커버리지 100 강박 자가 자각*. PR #18 (`student-honest-no-deep-thought`) 결의 학생 솔직 인정 다른 축.
+
+### 3. 테스트 명명 부정형 → 긍정형 변환 (Thread 7)
+
+```kotlin
+// 변경 전
+@Test
+fun `덱에 있는 카드를 모두 뽑아도 오류가 나지 않는다`() { ... }
+```
+
+reviewer: *"덱에 있는 카드를 모두 뽑게 되면 오류가 발생해야 하지 않을까요?"*
+
+학생 자가 답변:
+
+> *"덱에 있는 카드를 모두 뽑으면 카드를 다시 채워줌으로써 게임이 끝나지 않고 계속 진행되도록 구현하고 싶어서 이렇게 작성하였습니다!"*
+
+reviewer: *"그렇다면, 말씀하신대로 \"오류가 나지 않는다\" 라는 문구 대신, \"다시 채워진다\" 의 내용이 들어가면 어떨까요?"*
+
+학생: *"오,,! 그게 더 의미에 맞는 이름인 것 같아요!"*
+
+→ **MCP 룰 `test-name-positive-vs-negative-vocabulary`** ⭐⭐ 신규 — *부정형 (오류 X) → 긍정형 (다시 채워진다) — 도메인 의도 명시*. PR #38 (테스트 명명 도메인 어휘) 결 합류.
+
+### 4. argument name 가독성 (Thread 0)
+
+reviewer:
+
+> *"코틀린에는 argument name이라는 것이 있습니다. argument name을 활용하면, 파라미터에 무엇을 넣어야할지 알 수 있어서 가독성이 좋아집니다. **파라미터가 3개 이상이거나, 함수명만 보고서 파라미터를 무엇을 넣어야할지 짐작하기 어려울 경우에는 argument name을 활용하는 것을 권장**합니다."*
+
+```kotlin
+// 권장
+val participant = BlackjackParticipant.of(
+    dealer = Dealer(),
+    names = names,
+    input = InputView::getBettingMoney
+)
+```
+
+→ **MCP 룰 `kotlin-named-parameter-readability`** ⭐⭐ — PR #144 (m6z1) `kotlin-named-parameter-readability` 결 합류 누적 2 PR → ***Kotlin named parameter 어휘*** ⭐⭐⭐ 강화.
+
+### 5. `1.5`와 `1.0` 매직넘버 (Thread 4)
+
+reviewer: *"1.5와 1.0은 각각 어떤 것을 의미할까요?"*
+
+→ **매직넘버 = 도메인 어휘 분리** = 누적 다수.
+
+### 6. 팩토리 + private constructor (Thread 3)
+
+reviewer:
+
+> *"팩토리 메서드를 활용한다면 생성자를 통한 객체 생성을 막도록 개선해보면 어떨까요?"*
+
+→ **팩토리 + private constructor** = 누적 다수.
+
+### 7. 언더바 `_` backing property 컨벤션 (Thread 5)
+
+reviewer:
+
+> *"대체로 backing property 패턴을 사용할 때 언더바(_)를 붙입니다. backing property 패턴을 사용하는 것이 아니라면, 언더바(_)는 제거해주시는 것이 좋습니다.*
+> *ref. https://kotlinlang.org/docs/coding-conventions.html#names-for-backing-properties"*
+
+→ **MCP 룰 `underscore-prefix-backing-property-only`** ⭐⭐⭐ — PR #12 (EmilyCh0 1단계) 결 합류 누적 2 PR + Kotlin 공식 컨벤션 ref 첨부 강화.
+
+### 8. 방어적 복사 (Thread 6)
+
+reviewer:
+
+> *"players를 BlackJackParticipant의 파라미터로 전달하게 되고, 이 값을 BlackJackParticipant 내부에서 데이터를 조작(추가 및 삭제)를 하게 되면, 원본(players)을 훼손하게 됩니다. 지금 구조에서는 문제가 없지만, 원본이 훼손되면 원본을 사용하게 되는 모든 곳에서 문제가 발생하게 됩니다."*
+
+→ **방어적 복사** = PR #137·#148 결 합류 누적 3 PR.
+
+### 9. 클래스 + 생성자 같은 줄 컨벤션 (Thread 9)
+
+```kotlin
+// 변경 전
+class BettingResult
+    private constructor(...) { ... }
+
+// 권장
+class BettingResult private constructor(...) { ... }
+```
+
+reviewer: *"클래스와 생성자는 한 줄에 같이 작성하는 것이 컨벤션이에요. 지금처럼 작성하시면, **private 함수로 오해하기 쉬워요.** 😅"*
+
+→ **MCP 룰 `class-constructor-same-line-convention`** ⭐ — 가독성 컨벤션 + 오해 시그널.
+
+### 10. 람다 `it` → 명시적 변수 (Thread 10)
+
+reviewer:
+
+> *"람다에서 기본적으로 제공하는 `it`을 활용해도 좋지만, **가급적이면 변수가 어떤 역할을 하는지 정의하여 사용하는 것을 권장**해요."*
+
+```kotlin
+// 변경 전
+players.forEach { it.draw(...) }
+
+// 권장
+players.forEach { player -> player.draw(...) }
+```
+
+→ **MCP 룰 `lambda-it-vs-named-param`** ⭐⭐ 신규 — *`it` 활용 가능 / 명시적 변수 = 역할 정의 권장*. PR #144 (`kotlin-named-parameter-readability`)·Thread 0 (`argument-name-readability`) 결 합류 — *명명 명시 어휘*.
+
+### 11. 파라미터 긴 경우 개행 (Thread 11)
+
+```kotlin
+fun of(
+    dealer: Dealer,
+    names: List<String>,
+    money: (String) -> (BettingMoney)
+): BlackjackParticipant { ... }
+```
+
+→ 가독성 컨벤션.
+
+### 12. main 함수도 한 가지 일만 (Thread 9 main)
+
+reviewer: *"main함수도 일종의 함수이므로, 함수가 한 가지 일만 잘 하도록 함수를 분리해보면 좋을 것 같아요."*
+
+→ **함수 한 가지 일** = 누적 다수.
+
+## 대표 인용
+
+> [sujin9 PR 본문]
+> *"컨트롤러가 그저 `view`와 `domain`을 연결하는, 마치 `브릿지`와 같은 역할만 할 수 있도록 리팩토링"*
+
+→ **컨트롤러 = 브릿지 메타포 학생 자가 어휘**.
+
+> [BeokBeok Thread 1]
+> *"메서드 참조는 input을 가공없이 그대로 함수 파라미터로 전달하기 때문에, 데이터가 전달되는 과정에서 훼손되지 않았음을 확신할 수 있습니다. 즉, 동일한 input이면 동일한 output이 나올 것이라 기대할 수 있습니다."*
+
+→ **메서드 참조 = 함수형 매커니즘 어휘 정점**.
+
+> [sujin9 Thread 1]
+> *"제가 말한 부분이 맞는지, 혹은 놓친 부분이 있을지 궁금해요!"*
+
+→ **학생 자가 확인 요청 어휘**.
+
+> [BeokBeok Thread 8]
+> *"반드시 성공하는 테스트를 작성하는 것은 의미가 없습니다. 저라면, 이런 경우라면 차라리 테스트 코드를 작성하지 않습니다."*
+
+→ **항상 성공 테스트 거부 어휘 정점**.
+
+> [sujin9 Thread 8]
+> *"앞으로 다음 미션에서는 테스트 커버리지를 100 만드는 것만 생각하기 보다는, 테스트의 의미에 더 집중해야겠어요"*
+
+→ **학생 자가 커버리지 100 강박 자각 어휘**.
+
+> [BeokBeok Thread 9 (생성자 줄바꿈)]
+> *"클래스와 생성자는 한 줄에 같이 작성하는 것이 컨벤션이에요. 지금처럼 작성하시면, private 함수로 오해하기 쉬워요."*
+
+→ **생성자 줄바꿈 = private 함수 오해 시그널 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **메서드 참조 = 함수형 프로그래밍 매커니즘 (input → output 훼손 X)** — **MCP 룰 `method-reference-as-functional-vocabulary` 후보** ⭐⭐⭐ 정점.
+2. **테스트 커버리지 100 강박 vs 의미** — **MCP 룰 `coverage-100-vs-test-meaning` 후보** ⭐⭐⭐ 정점.
+3. **항상 성공 테스트 안티패턴** — **MCP 룰 `always-passing-test-anti-pattern` 후보** ⭐⭐⭐.
+4. **컨트롤러 = 브릿지 메타포** — **MCP 룰 `controller-as-bridge-metaphor` 후보** ⭐⭐.
+5. **테스트 명명 부정형 → 긍정형 변환** — **MCP 룰 `test-name-positive-vs-negative-vocabulary` 후보** ⭐⭐.
+6. **Kotlin argument name + 람다 `it` vs 명시적 변수** — **MCP 룰 `kotlin-named-parameter-readability` + `lambda-it-vs-named-param` 후보** ⭐⭐⭐.
+7. **언더바 `_` backing property 컨벤션 누적 2 PR** — **MCP 룰 `underscore-prefix-backing-property-only` 후보** ⭐⭐⭐.
+8. **클래스 + 생성자 같은 줄 컨벤션 (private 함수 오해)** — **MCP 룰 `class-constructor-same-line-convention` 후보** ⭐.
+9. **방어적 복사 누적 3 PR** = 누적.
+
+## 메타 노트
+
+- **sujin9 양 단계 완성 (1단계 #15 → 2단계 #47)** — 1단계 단방향 가이드 → 2단계 학생 자가 답변 5 thread + 학생 자가 *확인 요청 + 의견 요청* 어휘 진화. **BeokBeok 양 단계 reviewer**.
+- **BeokBeok 양 PR 어휘 진화** (#15 가이드 → #47 함수형 매커니즘 + 테스트 의미 어휘 정점) — *2025-05 시점 누적 reviewer 다년 활동*.
+- **메타 케이스 8번째 = 학생 자가 *커버리지 100 강박 자각* + *컨트롤러 브릿지 메타포* + reviewer 함수형 매커니즘 어휘** — *학습 정체감 자각 + 어휘 진화 메타*.
+- **MCP `oh-my-oop` 핵심 가치 어휘** (학생 측 자가 자각 + reviewer 단일 답 거부 *"차라리 안 쓰는 게 낫다"*) 정점.

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

@@ -0,0 +1,305 @@
+# PR #29 — [블랙잭 1단계] 부나 미션
+
+- **Reviewee:** [@tmdgh1592](https://github.com/tmdgh1592)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/29
+- **단계:** 1단계 (Builder + DSL 시도)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 20 / 리뷰이 10)
+
+## 잘한 점 (설계 관점)
+
+- **`@JvmInline value class CardNumber(private val number: Int)`** — 끗수 원시값 포장 (후속에 enum 전환 검토).
+- **`Card private constructor + Card.of(id: Int)` Flyweight (`CARDS = flatten`)** — 52장 캐싱.
+- **`open class Player` + `Dealer : Player` 상속 구조** — 후속에 `abstract class Participant`로 개선 권고.
+- **`PlayerHand` 일급 컬렉션 + 방어적 복사** — 점수 계산 + Ace 보정.
+- **`DTO 패턴` 도입 시도 + 학생 자가 토론** (못한 점 §6).
+- **후속 반영 — `Cards.isBlackjack()` 캡슐화 + DTO 분리 위치 토론 + DSL+Builder 폐기 결정**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Shape` enum *한글 식별자*
+
+```kotlin
+enum class Shape {
+    스페이드, 다이아몬드, 하트, 클로버;
+}
+```
+
+리뷰어: "*한글로 코드를 작성하지 않도록 해주세요. 왜 한글로 작성하면 안되는지, 답변을 남겨주세요.*"
+
+학생 답변: "*Encoding 설정에 따라서 한글이 깨지는 경우가 발생할 수 있기 때문에, 영어로 작성*하는 것이 일반적일 것 같습니다."
+
+→ 한글 식별자는 *인코딩 호환* + *국제화* + *키보드 입력 비용* + *오픈소스 협업* 측면 모두 비표준. *enum 값 = 도메인 어휘*가 영어로. *출력만 한글*은 `OutputView`가 매핑.
+
+### 2. `BlackJackBuilder` *잘못된 빌더 패턴* (object + lateinit)
+
+```kotlin
+object BlackJackBuilder {
+    private lateinit var participants: Participants
+    private lateinit var cardDeck: CardDeck
+
+    fun cardDeck(generator: CardGenerator) { cardDeck = CardDeck(generator) }
+    fun participants(block: ParticipantsBuilder.() -> Unit) { participants = ParticipantsBuilder(block) }
+
+    operator fun invoke(block: BlackJackBuilder.() -> Unit): BlackJack = BlackJackBuilder.apply(block).build()
+    private fun build(): BlackJack = BlackJack(cardDeck, participants)
+}
+```
+
+리뷰어: "*빌더 패턴에 대한 잘못된 사용 방법*입니다. 1. *빌더는 어떠한 공유 자원을 사용하지 않습니다.* 2. *빌더가 생성하는 인스턴스를 만들기 위해 반드시 필요한 값*이라면, *선택적으로 받지 않습니다*. 즉, 이 경우 *생성자를 이용해서 받는것이 맞습니다*. 3. 지금 구조에서 *빌더 + DSL을 사용하는 것에 특별한 장점이 드러나지 않는 것 같습니다*."
+
+학생 자가 인정: "다시 살펴보니, *말씀해주신 것처럼 단순히 `val blackJack = BlackJackBuilder { }` 라는 코드를 작성했을 때 문제가 발생하게 됩니다*..😅 *Builder 패턴을 사용할 때에는 반드시 필요한 값이 아닌, 선택적으로 초기화가 필요한 경우에 사용하는 것이 올바른 사용법*이라는 생각이 들었습니다. [...] *이번에 우테코 강의에서 DSL을 배워서 적용해보고 싶은 마음에 해봤는데*, 3번 피드백을 받고 찾아보니, *빌더와 DSL을 함께 사용하는 경우는 어떠한 인스턴스를 생성하는 것이 복잡한 구조일 때 적합*하다고 합니다."
+
+→ **세 가지 빌더 위반 동시 발생:**
+1. `object` Builder = 전역 변경 가능 상태 (공유 자원).
+2. `cardDeck`/`participants` 둘 다 필수인데 *선택적 람다*로 받음 → 생성자가 자연.
+3. *Builder + DSL*은 *복잡한 인스턴스* 시나리오에 적합 — 블랙잭 2 필드는 *과잉*.
+
+수업에서 배운 기능을 *적용하고 싶은 마음*이 잘못된 적용을 만든 신호. PR #65 (kmkim2689) DSL과 같은 결.
+
+### 3. `Card.toString()` UI 결합
+
+```kotlin
+class Card private constructor(private val shape: Shape, val number: CardNumber) {
+    override fun toString(): String = "${number.toLetter()}${shape.name}"
+}
+```
+
+리뷰어: "*Card를 어떻게 그릴지는 UI의 관심사*입니다."
+
+학생 자가 인정: "*도메인은 비즈니스 로직만을 수행*하고, 로직에 의해서 *반환된 값을 어떻게 화면에 보여주는지는 View에 따라 다를 수* 있다고 다시금 생각이 들었습니다. *어떤 View에서는 Shape.Heart를 "하트" 라고 그리고 싶어하고, 또 다른 View에서는 하트를 "❤️"로 그리고 싶어한다면, 그 때마다 domain을 수정해주는건 재사용성이 매우 떨어지기 때문*입니다." — 일관 패턴 자가 인정.
+
+### 4. `Card.of(id: Int): Card = CARDS[id - 1]` — id 의미 모호
+
+```kotlin
+class Card private constructor(private val shape: Shape, val number: CardNumber) {
+    companion object {
+        private val CARDS = Shape.values().map { shape ->
+            (CardNumber.min()..CardNumber.max()).map { Card(shape, CardNumber(it)) }
+        }.flatten()
+        fun of(id: Int): Card = CARDS[id - 1]
+    }
+}
+```
+
+리뷰어: "*of 함수가 무엇을 의미하는지, 왜 필요한지 모르겠습니다.* 🙏🏻" — `id`는 *0~51 인덱스*. *외부에서 1~52 정수로 카드 참조*하는 호출자는 누구? PR #128 (ijh1298) `Card(cardIndex: Int)` 보조 생성자와 같은 결. *인덱스 ↔ Card 분해*는 *Card의 책임 X*. `Card.of(shape, number)` 같은 *식별자 기반*이 자연.
+
+또: `(CardNumber.min()..CardNumber.max()).map { Card(shape, CardNumber(it)) }` — `CardNumber.min()`/`max()` companion 메서드. 학생 후속에 `flatMap` 사용 권고: "*컬렉션 함수의 flatMap { } 을 사용해보세요*".
+
+### 5. `Command(value: String)` UI 형식이 도메인에
+
+```kotlin
+class Command(val value: String) {
+    private val validCommands = listOf("y", "n", "Y", "N")
+    init { require(value in validCommands) { ... } }
+}
+```
+
+리뷰어: "*"y", "n" 과같은 문자는 UI에서 결정하는 관심사*입니다. [...] 도메인에서 필요한 개념은, *받는다 or 받지 않는다 라는 두가지 개념*으로 볼 수 있지 않을까요?"
+
+학생 자가 인정: "*입력 값이 달라지는 상황에서도 domain을 재사용할 수 있게끔 만드는 것이 중요*하다는 생각이 들었습니다. 일례로, *한국을 타겟으로 하다가 앱을 글로벌화 했을 때, 각국 다른 언어로 이루어진 입력값에 따라 domain을 수정하거나 새롭게 만드는 것은 유지보수에 좋지 않을 수도 있기 때문*입니다." — PR #63/#125/#128와 같은 결 — UI 형식 도메인 보유.
+
+### 6. `HandDTO` Domain에서 생성 — 학생 자가 의문
+
+```kotlin
+data class HandDTO(val name: String, val hand: List<String>)
+```
+
+학생 PR 본문 자가 의문: "*DTO로 감싸는 것이 Controller의 역할인가 vs Domain의 역할인가* 우선, 이번 프로젝트를 진행하면서 *Domain에서 DTO로 감싸서 전달*하도록 하였습니다. 하지만 *테스트 코드를 작성하는 것이 너무 힘들어진다는 문제*가 발생하였는데, 이런 구조여도 괜찮은지 궁금합니다!"
+
+리뷰어: "*작성하는 방법을 묻기 전에, DTO가 왜 필요한가요?* DTO가 어떤 목적으로 사용되는지, 왜 필요한지, 그렇다면 누가 생성을 해야 하는 것인지 답변을 남겨주세요."
+
+학생 자가 답변: "*DTO는 각 계층간 데이터를 전달하기 위한 목적*을 가지고 있습니다. 따라서 *어떠한 로직을 포함하고 있어서도 안됩니다*. [...] *MVC패턴에서 Controller는 View와 Domain의 중개 역할*을 수행하며, View와 Domain을 의존합니다. 따라서 *Controller에서 DTO를 사용하여 Domain 로직을 통해 얻은 결과를 View에게 전달*해주는 것이 좋지 않을까 라는 생각을 하였습니다. 또한, *이번 미션을 하면서 Domain에서 DTO를 반환하게 되면 테스트 코드 작성이 매우 복잡해진다는 것을 깨달았습니다*."
+
+→ **테스트 어려움 = 책임 잘못 배치 신호** (PR #92 결). *DTO 변환*은 *Controller 책임*. Domain은 *비즈니스 로직만*. 학생이 *자가 진단 + 정답 도달*. (다만 콘솔 게임에 DTO는 *과잉*일 수도 있음.)
+
+### 7. `CardDeck`이 `CardGenerator` 의존 — 카드를 새로 만들기?
+
+```kotlin
+class CardDeck(private val generator: CardGenerator) {
+    private val deck = Card.all().toMutableList()
+    fun draw(): Card {
+        val card = generator.generate()
+        if (deck.contains(card)) { deck.remove(card); return card }
+        return draw()
+    }
+}
+```
+
+리뷰어: "*카드덱이 카드 제너레이터와 어떤 협력관계를 가지는 것일까요?* 가지고있는 *카드뭉치에서 카드를 뽑는데 카드를 새로 만든다는 의미가 맞을까요?* 카드 뭉치가 생성될때 *필요한 카드들을 생성자로 받아서 준비*할 수도 있지 않을까요?"
+
+학생 자가 인정: "*단순히 카드를 하나 뽑는데 그 때마다 계속 generate() 해주는 것이 자연스러운 구현은 아닌 것 같습니다.* CardDeck의 생성자 파라미터로 *generator 대신에 이미 생성된 카드들을 넘겨주는 방식으로 변경*해보겠습니다!" — *generate() + 중복 시 재귀*는 PR #65 (kmkim2689) 패턴 재출현. *덱이 미리 셔플 + pop*이 자연.
+
+### 8. `PlayerHand`에 점수 계산 + `JQK_SCORE` 상수
+
+```kotlin
+class PlayerHand {
+    fun calculateTotalScore(): Int = cards.map { it.number.toInt() }.fold(0) { total, number -> total + calculateEachScore(total, number) }
+    private fun calculateEachScore(score: Int, number: Int): Int = when (number) {
+        CardNumber.ace() -> calculateAceScore(score)
+        CardNumber.jack(), CardNumber.queen(), CardNumber.king() -> JQK_SCORE
+        else -> number
+    }
+    companion object { private const val ACE_MIN_SCORE = 1; private const val ACE_MAX_SCORE = 11; private const val JQK_SCORE = 10 }
+}
+```
+
+리뷰어: "*플레이어 핸드나 게임 결과 객체가 카드의 점수를 가지고 있는것이 맞을까요?* *기본 점수는 어떤 객체가 결정할 책임을 가지고 있을까요?*" — *Card.score()* 또는 *Rank.score*가 *카드 한 장의 책임*. `PlayerHand`는 *합산 + Ace 보정*만. `J`/`Q`/`K`가 *모두 10점*인 룰을 `PlayerHand`에 박으면 *카드의 점수 룰이 Hand 안*에 있어 *Card 도메인 어휘*가 누수.
+
+### 9. `GameResult.judgePlayer(dealerScore, playerScore)` — 정적 + Int 비교
+
+```kotlin
+enum class GameResult {
+    승, 무, 패;
+    companion object {
+        fun judgePlayer(dealerScore: Int, playerScore: Int): GameResult = when {
+            playerScore > BLACKJACK_SCORE -> 패
+            dealerScore > BLACKJACK_SCORE || playerScore > dealerScore -> 승
+            dealerScore == playerScore -> 무
+            else -> 패
+        }
+    }
+}
+```
+
+리뷰어: "*승부를 결정짓는 것은 딜러와 상관없이 참가자가 다른 참가자가 판단할 요소이지 않을까요?* [...] `class Player { fun judge(otherPlayer: Player): GameResult { ... } }`"
+
+학생 변호: "*블랙잭 게임은 Dealer와 Player가 싸우는 상황이기 때문에 승부를 결정짓는 것이 딜러와 상관있지 않을까요..?*"
+
+리뷰어: "*현실 게임 입장에서 본다면, 딜러와 플레이어간의 점수를 비교하는 것으로 볼 수 있겠네요. 하지만, 객체지향 관점에서 볼 때 점수를 비교하는 구현체가 딜러인지 플레이어인지 관심을 가질 필요가 있을까요?* *만약 딜러 vs 플레이어가 아닌 플레이어 vs 플레이어면 동일한 코드를 중복해서 만들어야 할까요?* 또한 지금 구조에서 본다면, *플레이어는 승패를 스스로 판단하는 것이 아닌, 딜러에 의해 수동적으로 계산이 되고 있습니다.* (플레이어 객체가 *자율적으로 역할을 수행하지 않다*고 볼 수 있습니다)"
+
+→ PR #63·#125·#128과 동일한 *상대 무관 비교 = 참가자 자율성* 토론.
+
+또: `enum 한글 값 (승/무/패)` — Shape의 한글 식별자와 같은 결.
+
+### 10. `Player`가 `open class` + `Dealer : Player` 상속
+
+```kotlin
+open class Player(val name: String) {
+    val hand = PlayerHand()
+    fun addCard(card: Card) { hand.add(card) }
+    fun isBust(): Boolean = hand.calculateTotalScore() > GameResult.blackjackScore()
+}
+class Dealer : Player(DEALER_NAME) { ... }
+```
+
+리뷰어: "*open class를 이용한 상속 구조가 아닌, 다형성을 이용한 추상 클래스를 고려*해보면 어떨까요? `abstract class Player { abstract fun canDraw(): Boolean }` [...] `dealer.isStay() // (X)` / `player.isBust() // (X)` / `player.canDraw() // (O) 딜러인지 참가자인지 관심없음, 더 뽑을 수 있니?`" — *Dealer is-a Player*는 *현실 비유*에 맞지만 *Liskov 위반*(Dealer는 입력 없이 자동 진행). *공통 추상 = `Participant`* + *서로 다른 역할*. PR #114와 같은 결.
+
+### 11. `BlackJackController.blackJack: BlackJack lateinit` — 매번 새로 생성
+
+```kotlin
+class BlackJackController {
+    private lateinit var blackJack: BlackJack
+    fun start() {
+        blackJack = BlackJackBuilder { ... }
+        ...
+    }
+}
+```
+
+리뷰어: "*start() 함수에서 매번 블랙잭을 새로 만든다면, blackjack 을 프로퍼티로 작성할 필요가 있을까요?*"
+
+학생 자가 인정: "*BlackJackController의 start() 메서드를 호출할 때마다 새로운 인스턴스로 초기화되므로 따로 뺴놓을 필요가 없을 것 같습니다!*" — PR #92·#114와 같은 *lateinit var의 호출 순서 invariant 위반*. *local val*이 자연.
+
+### 12. `Cards.getFirstCard(): List<Card>` — 첫 *카드 한 장*인데 *List 반환*
+
+```kotlin
+class Cards {
+    fun getFirstCard(): List<Card> = listOf(_items.first())
+}
+```
+
+리뷰어: "*getFirstCard() 라면 Card를 반환해야 하지 않을까요?*" — *이름과 반환 타입 불일치*. `getFirstCards()` 또는 `Card` 반환. *Dealer가 1장만 공개*하는 *룰을 위해 List로 감쌌으나* `Card` 자체 반환 + *호출자가 List 만들기*가 자연.
+
+### 13. `Cards`가 *외부 `BlackJack.blackjackScore()` 의존*
+
+```kotlin
+class Cards {
+    fun calculateTotalScore(): Int { ... }
+    private fun calculateAceScore(score: Int): Int =
+        if (hasAce() && (score + BONUS_SCORE) <= blackjackScore()) score + BONUS_SCORE else score
+}
+```
+
+리뷰어: "*블랙잭 스코어(21점)은 Cards에서 스스로 판단을 해야 좋지 않을까요?* 21점이라는 값은 *Cards의 점수 합계에서 도출되는 하나의 상태*이기 때문에, *`Blackjack.blackjackScore()` 형태로 사용하는 것이 아닌 `cards.isBlackjack()` 처럼 사용해야 맞을 것 같습니다.*" — *상수 위치*가 *Cards 외부 의존*을 만듦. `Cards.isBlackjack()`이 Tell-Don't-Ask.
+
+### 14. `Participants(dealer: Dealer, players: Players)` — *Participant 추상화 미활용*
+
+```kotlin
+class Participants(private val dealer: Dealer, private val players: Players)
+```
+
+리뷰어: "*Participants라는 객체 이름과 역할로 본다면, 딜러와 플레이어들을 알고있는 것이 아닌*, 아래와 같은 시그니처를 가지고 있을 것이라고 기대했습니다. `class Participants(participants: List<Participant>) { ... }` 딜러와 플레이어들을 이용해서 *`List<Participant>`를 만드는 것이 우선*되어야 하지는 않을까요? 또한, *모든 코드가 딜러 플레이어들을 직접적으로 호출해서 하고 있는데 Participant 타입을 활용하지 못하고 있는 것처럼 느껴집니다.*" — `Participants(dealer, players)`는 *프로퍼티 묶음*. PR #63과 같은 *Participants 첫 0번 = Dealer invariant* 변형. *공통 행위*는 `List<Participant>` 처리로.
+
+### 15. `BlackJack.drawAll()` — 두 단계 흐름이 한 메서드에
+
+```kotlin
+class BlackJack(private val deck: CardDeck, private val participants: Participants) {
+    fun drawAll() { participants.drawAll(deck) }
+}
+```
+
+리뷰어: "*처음 카드를 받는 동작과 게임을 시작하는 과정으로 크게 두가지로 나눠서 생각해볼 수 있지 않을까요?* `class BlackJack(...) { fun readyToStart() { participants.drawFirst(deck) } fun start(onDrawn: (Participant) -> Unit): BlackJackResult { while (isRunning()) { participants.draw(deck); ... } }`" — *초기 분배 vs 진행*이 *시점 분리*. `readyToStart()` + `start()`로 *호출자가 단계 명시*. PR #135와 같은 결.
+
+### 16. `Participant.cards` 공개 + `getCards()`도 공개
+
+```kotlin
+abstract class Participant(val name: String) {
+    val cards = Cards()
+    fun getCards(): List<Card> = cards.items
+}
+```
+
+리뷰어: "*getCards() 함수가 이미 공개되어 있는데 위 프로퍼티도 같이 공개할 필요가 있을까요?*" — *두 가지 접근 경로*가 *동일 정보*를 노출. *한 가지 공개*만 (Kotlin에서 `val cards: Cards`로 충분).
+
+## 리뷰어 의견 요지
+
+- ***한글 식별자 금지*** — 인코딩 + 국제화 + 협업.
+- ***Builder 패턴 잘못 사용*** — 공유 자원 X, 필수값은 생성자, DSL은 복잡 인스턴스에만.
+- ***`Card.of(id: Int)` 인덱스 분해 = Card 책임 X*** (PR #128와 같은 결).
+- ***`Command "y"/"n"`은 UI 형식*** — 도메인은 *받는다/받지 않는다*.
+- ***DTO 변환 = Controller 책임, Domain은 비즈니스 로직만*** — 학생 자가 도달.
+- ***`CardDeck + CardGenerator`는 부자연*** — 덱이 카드를 미리 보유.
+- ***카드 한 장 점수 = Card 책임*** — Hand는 합산 + 보정.
+- ***승부 = 참가자 자율성 (상대 무관 비교)*** — *Dealer.judge(player)* X.
+- ***open class 상속 < abstract Participant 다형성***.
+- ***lateinit var은 호출 순서 invariant 위반*** — local val.
+- ***`getFirstCard(): List<Card>` 반환 타입 ≠ 이름***.
+- ***`blackjackScore()` 상수 위치 = Cards 내부*** — `cards.isBlackjack()`.
+- ***Participants = `List<Participant>` 단일 추상*** — dealer/players 분리는 invariant 누수.
+- ***`drawAll()` = 초기 + 진행 두 단계 압축*** — `readyToStart()` + `start()` 분리.
+
+## 대표 인용
+
+> "y", "n" 과같은 문자는 *UI에서 결정하는 관심사*입니다. [...] 도메인에서 필요한 개념은, *받는다 or 받지 않는다 라는 두가지 개념*으로 볼 수 있지 않을까요?
+> — @laco-dev on `Command.kt`
+
+> 빌더 패턴에 대한 *잘못된 사용 방법*입니다. 1. *빌더는 어떠한 공유 자원을 사용하지 않습니다.* 2. *빌더가 생성하는 인스턴스를 만들기 위해 반드시 필요한 값*이라면, *선택적으로 받지 않습니다*.
+> — @laco-dev on `BlackJackBuilder.kt`
+
+> 카드덱이 카드 제너레이터와 어떤 협력관계를 가지는 것일까요? 가지고있는 *카드뭉치에서 카드를 뽑는데 카드를 새로 만든다는 의미가 맞을까요?*
+> — @laco-dev on `CardDeck.kt`
+
+> 현실 게임 입장에서 본다면, 딜러와 플레이어간의 점수를 비교하는 것으로 볼 수 있겠네요. 하지만, *객체지향 관점에서 볼 때 점수를 비교하는 구현체가 딜러인지 플레이어인지 관심을 가질 필요가 있을까요?* *만약 딜러 vs 플레이어가 아닌 플레이어 vs 플레이어면 동일한 코드를 중복해서 만들어야 할까요?*
+> — @laco-dev on `Dealer.kt`
+
+> 처음 카드를 받는 동작과 게임을 시작하는 과정으로 크게 *두가지로 나눠서 생각해볼 수 있지 않을까요?*
+> — @laco-dev on `BlackJack.kt`
+
+## 얻은 교훈
+
+- ***한글 식별자 = 인코딩/국제화/협업 비용*** — *도메인 어휘는 영어*, *출력만 한글*은 OutputView 매핑.
+- ***Builder + DSL = 복잡한 선택적 필드 인스턴스 시나리오*** — *2 필드 필수*면 생성자가 자연. *수업에서 배운 기능 적용 욕구*가 *과잉 적용* 만듦 (PR #65·#135와 같은 결).
+- ***`Card.of(id: Int)` 인덱스 분해 = Card 책임 X*** — *인덱스 ↔ Card 매핑*은 *호출자 책임*.
+- ***UI 입력 형식(`"y"`/`"n"`)은 도메인 X*** — *받는다 / 받지 않는다*가 도메인 어휘. PR #63·#125·#128와 같은 결.
+- ***DTO 변환 = Controller 책임*** — Domain에서 DTO 반환하면 *테스트 어려움*이 신호. 학생이 *자가 진단 + 정답 도달*.
+- ***`CardDeck + CardGenerator` 결합 = 덱이 카드를 새로 만듦*** — *덱이 미리 셔플 + pop*이 자연. PR #65 재출현 패턴.
+- ***카드 한 장 점수 = Card 또는 Rank/CardNumber 책임*** — Hand는 합산 + 보정. `JQK_SCORE = 10` 같은 룰이 Hand에 있으면 *Card 도메인 어휘 누수*.
+- ***승부 = 참가자 자율성 (`participant.judge(other)`)*** — *Dealer.judge(player)*는 *Dealer가 비교자 역할*. 상대 무관 비교가 자연.
+- ***open class < abstract Participant*** — *Dealer is-a Player*는 현실 비유에 맞지만 *Liskov 위반*. 공통 추상 + 서로 다른 역할.
+- ***`lateinit var blackJack` = 호출 순서 invariant 위반*** — *매번 새로 생성*이면 *local val*. PR #114·#92와 일관.
+- ***`getFirstCard(): List<Card>` = 이름 ≠ 반환 타입*** — `Card` 반환 + 호출자가 List.
+- ***`blackjackScore()` 상수 위치 = Cards 내부*** — `cards.isBlackjack()` 메시지. 외부 상수 참조는 *도메인 응집 깨짐*.
+- ***Participants = `List<Participant>` 단일 추상이 자연*** — `(dealer, players)` 분리는 *공통 행위*를 *직접 호출*로 분해.
+- ***`drawAll()` 한 메서드 = 초기 + 진행 압축*** — `readyToStart()` + `start()`로 *단계 분리*. PR #135와 같은 결.
+- ***학생이 자가 진단으로 정답 도달하는 PR 패턴*** — *PR 본문에 자가 의문 + 리뷰어 메타 질문 + 학생 자가 답변*. PR #135와 같은 결.