oh-my-oop 0.2.0

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

@@ -0,0 +1,278 @@
+# PR #22 — [블랙잭 1단계] 링링 미션
+
+- **Reviewee:** [@RightHennessy](https://github.com/RightHennessy)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/22
+- **단계:** 1단계
+- **리뷰어:** [@galcyurio](https://github.com/galcyurio) (**신규 reviewer — 10번째**)
+- **라인 코멘트:** 16 스레드 — *학생 자가 PR 본문 질문 명시 + OCP 칭찬 + 테스트 가독성 (Google Testing Blog 인용) + LinkedList pop 자가 학습*
+- **신규 reviewee** (2023년 3월 코호트).
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 질문 명시** — *"아, 추가로 제 질문들은 아래 코드에 달아놓았습니다. 😊"* — **PR 본문에 *질문이 인라인 코멘트로* 분산 명시**. PR #76·#82·#107·#46·#91·#11·#13 결.
+- **`GameResultCondition` enum + OCP 칭찬** — galcyurio: *"말씀해주신 것처럼 장단점이 있습니다. 지금 방법은 추가적인 분기가 생길 경우 기존 코드를 건드리지 않고도 enum constant를 추가하여 기능을 추가할 수 있다는 장점이 있습니다. 그래서 저는 OOP 관점에서 보았을 때, 개방 폐쇄 원칙을 잘 지켰다고 생각해요 :+1:"*. **개방폐쇄 원칙 (OCP) 명시 + 칭찬**. PR #16·#137·#100 의 *원칙 명시 어휘* 결.
+- **`CardPack` 분리 칭찬** — galcyurio: *"네, 잘 구현해주셨습니다 :+1:"* (CardPack 분리).
+- **테스트 가독성 자가 학습 (Google Testing Blog 인용)** — galcyurio + 학생 인용:
+
+> *Google Testing Blog (Testing on the Toilet): "One property of a good test is `clarity`. Clarity means that a test should serve as readable documentation for humans, describing the code being tested in terms of its public APIs. Two more important properties are `completeness` and `conciseness`. A test is complete when its body contains all of the information you need to understand it, and concise when it doesn't contain..."*
+
+**외부 자료 + 학생 자가 인용 + 자가 적용**. PR #91·#95·#23·#26·#16·#46·#77 의 *외부 자료* 결의 *학생측 외부 자료 인용*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Cards size == INITIAL_CARDS_SIZE` 검증 — 학생 자가 의문
+
+학생 자가 의문: *"카드를 한장도 안받은 경우에 가진 카드를 보여주기위한 코드인데요, 이 하나를 위해 Controller에서 Cards를 import 하는 것이 적합할까요? 아니면 controller 안에서 상수처리를 해야할지, view에서 경우를 나누어 처리를 해줘야할지 궁금합니다!"*
+
+galcyurio 1: *"Cards는 항상 size가 INITIAL_CARDS_SIZE일 수밖에 없으니 체크를 할 필요가 없습니다."*
+
+```kotlin
+init {
+    require(cards.size == INITIAL_CARDS_SIZE)
+}
+```
+
+galcyurio 2: *"위와 별개로 domain에서 ui를 의존하는 반대의 경우는 문제가 되더라도 ui layer에서 domain layer의 클래스를 사용하는 것은 문제 없습니다."*
+
+galcyurio 3: PR #22 다른 위치 URL 인용.
+
+학생 자가 답변: *"아 이 로직은 한장도 더 받지 않고 'n'을 응답하고 끝난 경우 현재 들고 있는 카드를 보여주기 위해 있는 로직이어서 삭제하지 않았습니다..! (한장이라도 더 받은 사람은 마지막에 'n'을 입력해도 가진 카드를 출력하지 않습니다...!)"*
+
+→ **3 가지 학습**:
+
+#### 1.1. *`init { require }` Kotlin 어휘 = 객체 invariant*
+
+- *생성 시점 검증* + *Cards size 보장*.
+- PR #16·#9·#107 결.
+
+#### 1.2. *`UI → Domain` 의존 vs `Domain → UI` 의존 양방향성 명시*
+
+galcyurio: *"domain에서 ui를 의존하는 반대의 경우는 문제가 되더라도 ui layer에서 domain layer의 클래스를 사용하는 것은 문제 없습니다."* — **MCP 룰 후보 `dependency-direction-clarification`** = *UI → Domain 의존은 OK / Domain → UI 의존은 문제*. PR #145 (junseo511 *View 가 Domain 객체 생성*) 결.
+
+#### 1.3. *학생 자가 *기능 의도* 명시 후 자가 결정*
+
+*"한장도 더 받지 않고 'n'을 응답하고 끝난 경우 현재 들고 있는 카드를 보여주기 위해"* — **기능 의도 명시 후 자가 유지 결정**. PR #91·#11·#43 결.
+
+### 2. `enum 내 companion object` 불가 + 상수 공유
+
+학생: *"21을 상수처리하고 싶었는데, enum 클래스 내부에서는 companion object를 사용불가하다는 것을 알았습니다. 상수처리를 하지 않는 것이 맞을까요? 아니면 다른 클래스에서 이미 존재하는 상수값을 가져오는 것이 맞을까요?"*
+
+galcyurio: *"다른 곳에서 해당 상수를 쓰지 않는다면 top-level에 private으로 선언해두면 됩니다. 하지만 Player를 보니 이미 선언된 곳이 있으니 해당 상수를 public으로 풀어주신 후 참조하는게 어떨까요?"*
+
+학생: *"조언해주신대로 Player의 상수를 참조하였습니다! 🤗"*
+
+→ **3 가지 학습**:
+
+#### 2.1. *enum 내 companion object Kotlin 어휘 (실제로는 가능)*
+
+학생의 *"enum 내부에서는 companion object를 사용불가"* = *Kotlin 어휘 학생 자가 잘못된 가정* — *실제로는 가능* (Kotlin 1.x+).
+
+#### 2.2. *상수 위치 = 사용처 응집*
+
+- *한 곳만 사용* = *top-level private*.
+- *여러 곳 사용* = *기존 상수 위치 public*.
+
+**MCP 룰 후보 `constant-shared-vs-local`**. PR #11·#16 결.
+
+#### 2.3. *Player 의 상수를 GameResultCondition enum 이 참조 = 의존 방향*
+
+*도메인 객체 (Player) 의 상수* → *enum 이 참조* = *의존 OK*. 반대 (Player → enum 상수) 도 OK.
+
+### 3. `Card` View 로직 누수
+
+galcyurio: *"UI 로직입니다. UI layer의 View에서 데이터를 받아서 UI를 그리도록 개선해보세요."*
+
+학생: *"UI 로직에서 이뤄져야 하는 일에 대해 모두 UI에서 행할 수 있도록 코드를 변경하였습니다."*
+
+→ **MCP 기존 룰 `enum-with-ui-value`**. PR #137·#77·#23·#26·#16·#9·#11·#13·#82 결.
+
+### 4. `ALL_CARDS` mutable static — CardPack 객체 분리 권유
+
+galcyurio: *"변경 가능한 컬렉션을 static하게 선언해두는 것은 좋지 않습니다. `ALL_CARDS`가 모두 remove되는 경우에 이 프로그램은 더 이상 정상적으로 동작하지 않을거에요. 모든 카드를 불변으로 캐시해두는 것과 그 카드들을 하나씩 draw 하는 기능을 별도로 분리해보세요."*
+
+학생 자가 의문: *"제가 이해를 잘 못한 것 같아 추가적으로 질문을 드리자면.. > 모든 카드를 불변으로 캐시해두는 것과 그 카드들을 하나씩 draw 하는 기능을 별도로 분리해보세요. 이 말씀이 단순히 remove를 하지 말라는 뜻일까요? 아니면 캐싱을 따로 해두고 다른 카드 덱을 만들어서 그 안에서 draw 하라는 말씀이실까요? 😂"*
+
+galcyurio: *"remove 뿐만 아니라 add 또한 되어선 안됩니다. 현재 구현은 계속해서 같은 종류의 카드가 나올 수도 있기 때문에 잘못된 구현입니다. > 캐싱을 따로 해두고 다른 카드 덱을 만들어서 그 안에서 draw 하라는 말씀이실까요? 😂 맞습니다. 변경 가능한 컬렉션을 가진 CardPack과 같은 구현체를 만들어보세요."*
+
+→ **3 가지 학습**:
+
+#### 4.1. *Static mutable = 전역 상태 + 의도 변화 위험*
+
+- *`val ALL_CARDS: MutableList`* = *프로그램 전역 + remove/add 가능*.
+- *모두 remove = 동작 X / add = 중복 카드*.
+
+**MCP 룰 후보 `static-mutable-collection-unsafe`**. PR #11·#46·#16 결.
+
+#### 4.2. *불변 캐시 + 가변 Deck 분리*
+
+- *`val ALL_CARDS: List<Card>`* (불변 + static) + *`class CardPack(remainingCards: MutableList<Card>)`* (가변 인스턴스) — *원본 보호 + draw 시 인스턴스 카드 소진*.
+
+PR #74·#108·#133·#46·#77·#26 결.
+
+#### 4.3. *학생 자가 의문 + reviewer 명확화*
+
+*"이 말씀이 단순히 remove를 하지 말라는 뜻일까요?"* — **학생 자가 학습 갭 명시 모범**. PR #95·#107·#16·#76 결.
+
+### 5. `GameResult` 승/패/무 String = UI 로직
+
+galcyurio: *"승, 패, 무 String은 UI 로직입니다. UI layer에서 GameResult에 따라 승, 패, 무를 출력하도록 만들어보세요."*
+
+→ **enum-with-ui-value 강화**. PR #137·#77·#23·#26·#16·#9·#11·#13·#82·#100·#82·#80 결.
+
+### 6. `when` 활용
+
+galcyurio: *"when expression을 활용해보세요."*
+
+학생: *"when으로 분기처리를 하도록 코드를 변경하였습니다!"*
+
+→ **Kotlin when 어휘**. PR #91·#9·#26·#43·#16·#76 결.
+
+### 7. `Shape` UI 로직
+
+galcyurio: *"UI 로직입니다. UI layer에서 데이터를 받아서 그리도록 만들어보세요."*
+
+→ **enum-with-ui-value 결**.
+
+### 8. `BlackJackRefereeTest` 함수명 = 룰 설명 가능?
+
+galcyurio: *"테스트 케이스 이름에는 어떻게 동작하는지 또는 요구사항이 명시되어야 합니다. 누군가에게 블랙잭의 룰에 대해 설명할 때, `딜러를 상대로 링링은 패배하고 우기는 승리하고 써니는 무승부`하는 게임이라고 이야기할 수 있을까요? 링링은 왜 패배하는지, 우기는 왜 승리하는지, 써니는 왜 무승부하는지가 드러나야 합니다."*
+
+학생: *"카드합으로 승무패를 구별한다는 것을 반영하여 함수 이름을 변경하였습니다!"*
+
+→ **테스트명 = 룰 설명 가능 + 이유 명시**. PR #26·#46·#99·#107·#145·#9 의 *테스트 명세서* 결.
+
+### 9. `테스트 본문 = clarity + completeness + conciseness` Google Blog
+
+galcyurio: *"테스트 본문에는 테스트하고자 하는 것을 이해할 수 있는 정보를 모두 가지고 있어야 하고, 반대로 불필요한 내용을 전부 감추어야 합니다."* + [Google Testing Blog 글](https://testing.googleblog.com/2014/03/testing-on-toilet-what-makes-good-test.html)
+
+학생 자가 인용 + 매우 긴 답변 (위 §잘한점) + 자가 정리:
+
+> *"제가 생각했을때 이 테스트에서 불필요한 정보는 점수에 영향을 주지 않는 카드의 모양, 플레이어의 이름이고, 꼭 필요한 정보는 뽑은 카드 목록과 그 카드의 합이라고 생각했습니다."*
+
+galcyurio 추가 권유 + 코드 예시:
+
+```kotlin
+// given
+val player1 = createPlayer(CardNumber.SEVEN, CardNumber.K) // 9
+val player2 = createPlayer(CardNumber.EIGHT, CardNumber.ONE) // 17
+```
+
+학생: *"테스트 코드 밖에서 불필요한 요소들을 처리하여, 테스트 코드 안에서는 필요한 요소들만 입력 받아 객체를 반환하도록 하는 함수를 생성하였습니다."*
+
+→ **5 가지 학습**:
+
+#### 9.1. *학생 자가 외부 자료 인용*
+
+학생이 *Google Blog 영어 원문 자가 발췌* + *3 properties (clarity/completeness/conciseness) 명시* — **학생측 외부 자료 인용 모범**. PR #91·#77 의 *외부 책 인용* 결.
+
+#### 9.2. *불필요 정보 분리 = 테스트 픽스처 함수 추출*
+
+- *`createPlayer(cardNumber, cardNumber)` 헬퍼* = *카드 모양/플레이어 이름 등 불필요 정보 함수 내부에 숨김*.
+
+PR #99 (KwonDae *Test Fixture 품질*) / PR #91 (murjune *createBustPlayers vararg*) 결.
+
+#### 9.3. *학생 자가 의문 + reviewer 코드 예시*
+
+학생 자가 *불필요 정보 식별 (모양/이름)* + reviewer 가 *코드 예시 (createPlayer)* 첨부.
+
+#### 9.4. *side effect 없이 반환 = 유연한 구조*
+
+galcyurio: *"side effect 없이 반환을 해주는 현재 구조가 더 유연한 구조입..."* — **함수형 + 결과 반환**.
+
+#### 9.5. *불필요 정보 검토 vs 학생 인식 갭*
+
+galcyurio 추가 권유 *"여전히 테스트 코드에 불필요한 정보가 남아있습니다"* — *학생이 첫 시도 후에도 추가 불필요 정보 존재* — **테스트 정제 = 반복 학습**.
+
+### 10. `BlackJackRefereeTest 구조` 자가 의문
+
+학생: *"BlackJackRefree는 딜러와 플레이어들을 넘겨 각각의 사람들이 가지는 카드를 비교하는 구조라, 무엇을 테스트하고 있는지 한눈에 깔끔하게 보일 수 없는 구조라 생각했습다. (물론 제가 놓치고 있는 것일 확률이 높지만요..) 그렇다면 이 구조가 잘못된 것일까요? 지금처럼 `BlackJackRefree` 를 통해 결과를 새로운 `List<PlayerGameResult>`로 만들어서 반환하는 것이 아니라, 결과를 바로바로 출력해주는 것이 더 나을까요?"*
+
+galcyurio: *"side effect 없이 반환을 해주는 현재 구조가 더 유연한 구조입..."*
+
+→ **side effect X 결과 반환 = 함수형 정공**. PR #145·#46·#76 결.
+
+### 11. `DealerTest` 동일 불필요 정보
+
+galcyurio: *"BlackJackRefereeTest와 마찬가지로 나머지 테스트 케이스도 불필요한 정보를 분리해보세요!"*
+
+→ **반복 적용**.
+
+### 12. `LinkedList pop` 활용
+
+galcyurio: *"직접 0번째 카드를 가져오는 대신 `LinkedList`와 같이 이미 잘 만들어진 자료구조를 활용해보는건 어떨까요?"*
+
+학생: *"코틀린에는 왜 pop이 없지.? 라고 생성해서 자꾸 shuffle했던 것 같습니다. Linked List를 사용하면 해결 가능한 거였군요..! ㅎㅎ 수정하였습니다."*
+
+→ **Kotlin 자료구조 어휘 + Java LinkedList 활용**. **MCP 룰 후보 `data-structure-tool-knowledge`**. PR #46·#23 결.
+
+### 13. `CardPack` 최초 1회 셔플
+
+galcyurio: *"현실처럼 CardPack을 최초에 한 번만 셔플해주셔도 충분합니다 :)"*
+
+학생: *"앗.. 그렇군요 ㅎㅎ.. 계속해서 랜덤해서 뽑는다고 생각해서 자꾸 shuffle했던 것 같습니다. 최초 한번만 shuffle 하도록 변경하겠습니다!"*
+
+→ **PR #77·#66 (Deck shuffle 위치) 결**.
+
+### 14. `테스트 함수` 위치 (테스트 함수 아래)
+
+galcyurio: *"테스트 클래스에서는 테스트 함수가 더 중요하므로 테스트 함수 아래에 위치하도록 해주세요."*
+
+→ **테스트 파일 구조 컨벤션**. PR #145 (코드 포맷 가독성) 결.
+
+### 15. `BlackJackRefereeTest` 함수 외부 처리 자가 적용
+
+학생: *"불필요한 일을 테스트 함수 외부에서 처리하도록 코드를 수정하였습니다!"*
+
+→ **자가 적용 명시**.
+
+## 리뷰어 의견 요지 (galcyurio) — **신규 reviewer**
+
+16 코멘트 특징:
+
+- **`:+1:` 칭찬 + `OOP/OCP 원칙` 명시** — *"개방 폐쇄 원칙을 잘 지켰다고 생각해요 :+1:"* — **객체지향 원칙 약어 명시**. PR #16·#137·#100 (조영호 어휘 + KwonDae) 결의 *galcyurio 합류*.
+- **외부 자료 첨부** — *Google Testing Blog* — PR #91·#67·#23·#26·#16·#46·#77·#107·#82 결.
+- **`UI → Domain 의존 OK / Domain → UI 의존 문제` 명시 어휘** — **MVC 의존 방향 메타**.
+- **코드 예시 첨부** — `createPlayer(CardNumber, CardNumber)` 코드.
+- **반복 권유 (지속적 정제)** — *"여전히 불필요한 정보가 남아있습니다"* — *학생이 첫 시도 후 추가 정제 필요*.
+
+## 대표 인용
+
+> *"그래서 저는 OOP 관점에서 보았을 때, 개방 폐쇄 원칙을 잘 지켰다고 생각해요 :+1:"* — galcyurio (OCP 명시 칭찬)
+
+> *"domain에서 ui를 의존하는 반대의 경우는 문제가 되더라도 ui layer에서 domain layer의 클래스를 사용하는 것은 문제 없습니다."* — galcyurio (MVC 의존 방향 메타)
+
+> *"One property of a good test is `clarity`. Clarity means that a test should serve as readable documentation for humans, describing the code being tested in terms of its public APIs."* — RightHennessy (Google Testing Blog 자가 인용)
+
+> *"코틀린에는 왜 pop이 없지.? 라고 생각했었는데 Linked List를 사용하면 해결 가능한 거였군요..!"* — RightHennessy (Kotlin 자료구조 어휘 자가 학습)
+
+> *"이 말씀이 단순히 remove를 하지 말라는 뜻일까요? 아니면 캐싱을 따로 해두고 다른 카드 덱을 만들어서 그 안에서 draw 하라는 말씀이실까요? 😂"* — RightHennessy (학생 자가 학습 갭 명시)
+
+## 얻은 교훈
+
+1. **`MVC 의존 방향 메타`** — *UI → Domain OK / Domain → UI 문제*. **MCP 룰 후보 `dependency-direction-clarification`**.
+
+2. **`개방 폐쇄 원칙 (OCP)` 명시** — *enum 추가 = 기존 코드 변경 X = OCP 정공*. PR #16·#137·#100 결.
+
+3. **`Static mutable collection unsafe`** — *전역 + remove/add 가능 = 동작 X*. **MCP 룰 후보 `static-mutable-collection-unsafe`**.
+
+4. **`불변 캐시 + 가변 Deck 인스턴스 분리`** — PR #74·#108·#133·#46·#77·#26 결.
+
+5. **`테스트 본문 3 properties (clarity/completeness/conciseness)`** — *Google Testing Blog 외부 자료 + 학생 자가 인용*. **MCP 룰 후보 `test-3-properties-clarity-completeness-conciseness`**.
+
+6. **`LinkedList pop` 활용** — *Kotlin 자료구조 어휘 + Java 표준 라이브러리 활용*. **MCP 룰 후보 `data-structure-tool-knowledge`**.
+
+7. **`enum 내 companion object` 어휘 가능성** — *학생 자가 잘못된 가정 (불가) vs 실제 가능*. **MCP 룰 후보 `kotlin-vocabulary-misconception`**.
+
+8. **`상수 공유 vs local`** — *한 곳 = top-level private / 여러 곳 = public*. **MCP 룰 후보 `constant-shared-vs-local`**.
+
+9. **`테스트명 = 룰 설명 가능 + 이유 명시`** — *"왜 패배/승리/무승부?"* — PR #26·#46·#99·#107·#145·#9 결.
+
+10. **`테스트 정제 = 반복 학습`** — *첫 시도 후에도 추가 불필요 정보 검토*. PR #99 (Test Fixture 진화) 결.
+
+11. **`init { require }` Kotlin 어휘 = 객체 invariant** — PR #16·#9·#107 결.
+
+12. **`side effect X 결과 반환 = 함수형 정공`** — PR #145·#46·#76 결.
+
+13. **`외부 자료 학생측 인용` 모범** — PR #91·#77 결의 *학생측 강화*.
+
+14. **`galcyurio reviewer 패턴`** — *간결 + 원칙 명시 + 외부 자료 + 코드 예시 + 반복 권유* — **10번째 reviewer 합류**.

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

@@ -0,0 +1,188 @@
+# PR #48 — [블랙잭 2단계] 링링 미션
+
+- **Reviewee:** [@RightHennessy](https://github.com/RightHennessy)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/48
+- **단계:** 2단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 13 스레드 — *Controller 책임 BlackJackGame 이전 자가 학습 + CardPack draw() 테스트 + UI 의존 분리 매우 긴 토론*
+- **양 단계 분석 reviewee** (1단계 #22 별도). 학생 자가 PR 본문 *코드 더럽고 복잡* 인정.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 *코드 복잡* 인정** — *"베팅 금액 기능을 추가하면서 코드가 굉장히.. 더럽고 복잡해져서 마음이 불편하네요.. 🙇‍♀️"* — **학생 자가 코드 부채 자가 인정**. PR #100·#145 결.
+- **`CardPack` 1단계 권고 자가 반영** — 학생: *"저번에 리뷰해주신 대로, 처음에만 shuffle 한 후, linkedList를 이용하여 카드를 한장 뽑도록 코드를 변경했습니다."* — **PR #22 1단계 권고 자가 적용 + 보고**. PR #46·#107·#145·#76 결의 *1단계 권고 자가 반영 + 명시*.
+- **재입력 받기 칭찬** — galcyurio: *"재입력 받기 👍"*. PR #11 (ki960213 *ReadValueSureModifier*) 결.
+- **`BlackJackGame` 테스트 작성 칭찬** — galcyurio: *"BlackJackGame 테스트 작성 :+1: 가독성도 좋네요!"* — **1단계 권고 후속 테스트 가시화**. PR #99·#46·#91 결.
+- **`GameResultCondition` 제거 + BlackJackReferee 응집 자가 반영** — 학생: *"GameResultCondition을 개선하지 못한 점이 가장.. 아쉬운데요, 상태 판단을 위해 너무 많은 일을 하고 있다는 생각이 들었습니다. 어떤 식으로 개선해야 좋을까요,,? 😥"* + galcyurio: *"GameResultCondition을 제거한 다음 이 로직들을 BlackJackReferee에서 burst인지 draw인지를 판단하고 GameResult를 반환하도록 만들어보면 어떨까요?"* + 학생 자가 적용. **학생 자가 의문 + reviewer 구체 권고 + 자가 적용 모범**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Controller god-object → BlackJackGame` — 학생 자가 의문 + 매우 긴 토론
+
+학생 자가 의문: *"controller의 책임을 blackJackGame으로 넘겼는데, 코드의 개선은 전혀 없는 것 같아 생성 후 왜(?) 라는 질문을 가장 많이 남긴 부분 같습니다..."*
+
+galcyurio: *"현재 Controller는 현재 테스트하기 힘든 상태입니다. 하지만 BlackJackGame으로 이동하게되면서 테스트하기 쉬운 코드가 되었습니다. BlackJackGame에 대한 테스트 코드를 작성해보세요."*
+
+galcyurio 별도: *"Controller에서 UI에 의존하고 있으므로 Controller는 여전히 테스트하기 힘든 코드입니다. 이 피드백은 일단 기억만 해두고 이번 미션에서는 Controller 테스트보다 domain 객체인 BlackJackGame을 테스트하는 것에 집중해보세요."*
+
+→ **3 가지 학습**:
+
+#### 1.1. *Controller god-object 이전 = 테스트 가능성 시그널*
+
+- *Controller (UI 의존) = 테스트 불가능*.
+- *BlackJackGame (도메인) = 테스트 가능*.
+- *코드 이전 = *책임 위치 + 테스트 가능성* 양립*.
+
+**MCP 룰 후보 `controller-to-domain-test-enablement`**. PR #99·#107·#145·#46·#72 결.
+
+#### 1.2. *학생 자가 *왜?* 의문 = 학습 진행 시그널*
+
+*"왜(?) 라는 질문을 가장 많이 남긴 부분"* — **학생 자가 *왜* 의문 = 학습 활성 시그널**.
+
+#### 1.3. *PR #72 (ghojeong *Controller 판단 기준 2 가지*) 결*
+
+PR #72 의 *view 의존 + 테스트 가능 = Controller* 판단 기준 강화.
+
+### 2. `BlackJackGameTest` UI 의존 분리 + 람다 vs Controller 매우 긴 토론
+
+학생 자가 의문: *"제가 결과물을 테스트하려고 하다보니.. 이미 출력된 것에 대해 어떻게 테스트를 해야할지 감이 오질 않습니다.. string으로 만들어서 반환하여 다른 곳에서 print를 해야할까요? 아니면 이미 출력된 구문에 대해 테스트할 수 있는 방법이 따로 있을까요?"*
+
+galcyurio 3 단계 권유:
+
+> *"BlackJackGame은 domain 객체입니다. 어떻게 출력되는지에 대해서는 알지 못하므로 당연히 UI에 관한 테스트도 할 수 없는게 정상입니다.*
+>
+> *아래와 같은 순서로 리팩터링해보세요.*
+> *1. BlackJackGame에서 UI 관련 의존성을 분리한다.*
+> *2. BlackJackGame에서 외부로 노출될 필요가 없는 함수들을 모두 private으로 선언한다.*
+> *3. BlackJackGame의 public 함수에 대한 테스트 케이스를 작성한다."*
+
+학생 자가 적용: *"InputView는 game내로 전달하여 람다로 사용하고 있기 때문에 완벽한 분리가 되지 않았다고 생각합니다.. 그냥 controller 내에서 각 player에 대한 값을 받는 것이 완벽하게 분리하는 것일까요..?"*
+
+galcyurio: *"View에 대한 직접적인 의존성은 사라졌기 때문에 테스트하기 쉬운 코드가 되었습니다. 지금 구조도 나쁘지 않아 보입니다."*
+
+→ **3 가지 학습**:
+
+#### 2.1. *3 단계 도메인 분리 리팩토링 가이드*
+
+1. UI 의존 분리.
+2. private 노출 최소화.
+3. public 함수 테스트.
+
+**MCP 룰 후보 `domain-isolation-refactoring-steps`**.
+
+#### 2.2. *람다 전달 vs Controller 내 직접 처리 양가성*
+
+- *람다 전달 (학생 코드)* = *완벽한 분리 X 자가 우려*.
+- *Controller 내 직접* = *완벽한 분리 + 도메인 자유*.
+- *reviewer*: *"View에 대한 직접적인 의존성은 사라졌기 때문에 테스트하기 쉬운 코드가 되었습니다"* — *람다 전달 = 의존성 끊김 인정*.
+
+PR #145·#107·#82·#100·#80 의 *람다 콜백* 결.
+
+### 3. `CardPack` private + 카드 부족 시 외부 책임
+
+galcyurio: *"변경 가능한 상태의 필드를 외부로 그대로 노출해서는 안됩니다. 쓰는 곳이 없다면 private으로 감추고 쓴다면 방어적 복사를 하고 노출해야 합니다."*
+
+학생 자가 의문 (테스트 위해 함수 vs 방어적 복사):
+
+> *"현재 외부에서 사용하는 곳은 CardPackTest 하나임을 확인했습니다. 외부에서 사용하기 위해 방어적 복사를 쓰는 것이 나을까요? 아니면 `fun size(): Int = cards.size` 와 같이 그냥 size를 구하는 함수를 만들고 private로 감추는 것이 나을까요?*
+>
+> *테스트를 위해 함수를 만드는 것이 안좋다고 생각하여 일단은 방어적 복사를 하도록 했는데, get() 함수를 사용하는 것도 크게 다르지 않다는 생각이 들어서 고민이 됩니다..."*
+
+galcyurio (메타 답변):
+
+> *"테스트를 위해 함수를 추가하거나 public으로 노출해서는 안됩니다. 그러면 남는 건 draw() 함수이므로 이 함수를 통해 테스트해야 합니다.*
+>
+> *하지만 CardPack 자체에서 카드가 없으면 새롭게 리필이 되어버리고 있는데 이 동작을 외부에서 카드가 없는지 확인하고 없으면 카드를 채워주는 방식으로 변경해보세요. 그러면 draw() 함수를 56번과 57번 호출했을 때, 각각 카드와 null이 반환되는지를 체크할 수 있습니다."*
+
+학생: *"cards를 private으로 변경하고, 카드팩이 비었는지 확인하고 다시 채워주는 작업을 각각 dealer와 player의 draw에서 시행하도록 변경하였습니다."*
+
+→ **5 가지 학습**:
+
+#### 3.1. *테스트 위해 함수 X / public 노출 X = 단단한 원칙*
+
+- *public 노출 = 본 코드 책임 외 추가 책임*.
+- *테스트는 *기존 public 함수만* 사용*.
+
+**MCP 룰 후보 `test-only-public-exposure-anti-pattern`**. PR #145·#86·#99 결.
+
+#### 3.2. *카드 리필 책임 = 외부 (Dealer/Player) 가 확인 + 외부 채움*
+
+- *CardPack 내부 자동 리필* = *invariant 모호*.
+- *외부 (Dealer/Player)* = *명시적 카드 부족 확인 + 채움 결정*.
+
+#### 3.3. *56장 vs 57장 draw 테스트 시나리오*
+
+- *56번 = 정상 카드*.
+- *57번 = null 반환*.
+- **결정적 테스트 = 카드 소진 시나리오**.
+
+PR #46·#26·#23·#107·#22 의 *카드 부족 시* 결.
+
+#### 3.4. *PR #22 1단계의 ALL_CARDS mutable static 권고* 자가 적용
+
+PR #22 1단계의 *불변 캐시 + 가변 Deck 인스턴스 분리* 적용 자가 반영.
+
+#### 3.5. *학생 자가 *방어적 복사 vs get 함수* 자가 양가성 의문*
+
+학생이 *두 안 모두 자가 검토* + reviewer 의 *제 3 안 (draw 함수만 사용)* 채택.
+
+### 4. `주석 = 왜 vs 무엇`
+
+galcyurio: *"주석은 코드가 어떤 일을 하는지가 아니라 왜 존재하는지를 담고 있어야 합니다. 코드만 봐서는 어떤 일을 하는지 이해가 잘 안 된다면 코드를 더 간단하게 고쳐야합니다. 정규 표현식이나 복잡한 알고리즘에 대해서는 예외로 어떤 일을 하는지를 적어도 좋지만 일반적으로는 코드에 담을 수 없는 정보를 주석에 남기는 편이 좋습니다."*
+
+→ **주석 = WHY > WHAT 원칙**. PR #16 (BeokBeok *주석 → 함수명*) / PR #46 (말리빈 *라면 비유*) 결.
+
+### 5. `Controller InputView 직접 넘기기 vs 람다`
+
+학생: *"직접 inputView와 outputView를 넘겨서 테스트를 해보려는 생각중입니다!"*
+
+→ **InputView 직접 vs 람다 양가성**. 위 §2 의 *람다 전달 = 의존성 끊김* reviewer 인정.
+
+### 6. `BlackJackGame UI 의존 회피`
+
+galcyurio: *"BlackJackGame은 domain 객체이므로 UI layer의 InputView, OutputView에는 의존해선 안됩니다. 지난 번 리뷰 때 봤어야했는데 놓쳤네요 🙏"*
+
+→ **reviewer 자가 *놓침* 사과**. PR #91·#77·#46·#16·#95·#137·#107·#145 결.
+
+### 7. `Pair → Participants` 별도 클래스 권유
+
+galcyurio: *"다음부터는 Pair 대신에 Participants와 같은 별도의 클래스를 선언해보세요!"*
+
+→ **Pair 명명 모호 = 별도 클래스 정공**. PR #39 (rhthrhrl0 *NameAndBet*) 결.
+
+## 리뷰어 의견 요지 (galcyurio)
+
+13 코멘트 특징 (PR #22 와 동일 reviewer):
+
+- **3 단계 리팩토링 가이드** — *UI 분리 + private 노출 최소화 + public 테스트* — **MCP 룰 후보 `domain-isolation-refactoring-steps`**.
+- **메타 권고 어휘** — *"테스트를 위해 함수를 추가하거나 public으로 노출해서는 안됩니다"* — **단단한 원칙 명시**.
+- **자가 *놓침* 사과** — *"지난 번 리뷰 때 봤어야했는데 놓쳤네요 🙏"*. PR #91·#77·#46·#16·#95·#137·#107·#145 결.
+- **`:+1:` 칭찬** — *재입력 받기, BlackJackGame 테스트* 등.
+
+## 대표 인용
+
+> *"controller의 책임을 blackJackGame으로 넘겼는데, 코드의 개선은 전혀 없는 것 같아 생성 후 왜(?) 라는 질문을 가장 많이 남긴 부분 같습니다."* — RightHennessy (학생 자가 *왜?* 의문 = 학습 시그널)
+
+> *"BlackJackGame은 domain 객체입니다. 어떻게 출력되는지에 대해서는 알지 못하므로 당연히 UI에 관한 테스트도 할 수 없는게 정상입니다."* — galcyurio (도메인 vs UI 분리 명확화)
+
+> *"테스트를 위해 함수를 추가하거나 public으로 노출해서는 안됩니다."* — galcyurio (테스트 위해 코드 변경 금지 원칙)
+
+> *"베팅 금액 기능을 추가하면서 코드가 굉장히.. 더럽고 복잡해져서 마음이 불편하네요.. 🙇‍♀️"* — RightHennessy (학생 자가 코드 부채 자가 인정)
+
+## 얻은 교훈
+
+1. **`Controller god-object → BlackJackGame 이전 = 테스트 가능성 시그널`** — *책임 위치 + 테스트 가능성 양립*. **MCP 룰 후보 `controller-to-domain-test-enablement`**.
+
+2. **`3 단계 도메인 분리 리팩토링`** (UI 분리 → private 최소화 → public 테스트). **MCP 룰 후보 `domain-isolation-refactoring-steps`**.
+
+3. **`테스트 위해 함수 추가 / public 노출 = 안티패턴`** — *기존 public 함수만 테스트*. **MCP 룰 후보 `test-only-public-exposure-anti-pattern`**.
+
+4. **`카드 리필 책임 = 외부 + 명시적 확인`** — *내부 자동 리필 X / 외부 (Dealer/Player) 확인 + 채움*. PR #46·#107·#26·#23·#22 결.
+
+5. **`주석 = WHY > WHAT 원칙`** — PR #16 결.
+
+6. **`Pair → 별도 클래스`** = 명명 의도 명시. PR #39 결.
+
+7. **`학생 자가 *왜?* 의문 = 학습 시그널`** — *자가 의문 자체가 학습 활성*.
+
+8. **`1단계 권고 자가 반영 + 명시`** — *학생이 *저번에 리뷰해주신 대로* 명시*. PR #46·#107·#145·#76 결.