oh-my-oop 0.2.0

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

@@ -0,0 +1,226 @@
+# PR #19 — [블랙잭 1단계] 빅스 미션
+
+- **Reviewee:** [@briandr97](https://github.com/briandr97)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/19
+- **단계:** 1단계
+- **리뷰어:** [@vagabond95](https://github.com/vagabond95) — *racingcar 인용 reviewer* (PR #75 등) + 2023 코호트
+- **라인 코멘트:** 14 스레드 — *PR 본문 자가 의문 (interface vs abstract class 기준) + 학생 자가 답변 풍부 + Kotlin 어휘 자가 학습 정점 (sealed interface vs sealed class + enum vs sealed) + Person god-object → HandOfCards 일급 컬렉션 자가 적용 + MVC 의 origin 어휘 양방향 토론 + reviewer *제 이야기 또한 정답이 아닌 하나의 의견* 메타 어휘 + 전략 패턴 → 확장함수/object 학생 자가 의문 + label/text/toString 도메인 vs View 4 자리 + 빌더 패턴 X 블랙잭 무관 (study 패키지 이동)*
+- **2023 코호트 마지막 ≥10 thread 1단계 미분석 PR** (batch 22 마무리). 2023 코호트 총 11+ PR 분석 완료.
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 — `interface` vs `abstract class` 기준
+
+PR 본문:
+
+> *"한 가지 궁금한 점이 있습니다. 리뷰어님께서는 interface와 abstract class를 어떤 기준으로 구분하여 사용하시는지 궁금합니다!"*
+
+→ **Kotlin 어휘 자가 의문 + reviewer 의견 직접 요청** = PR #129·#126·#138·#142·#143·#113 (sealed vs abstract vs open) 결의 *학생 자가 의문 합류* 누적 7+ PR.
+
+### 2. Kotlin 어휘 자가 학습 정점 (sealed interface + enum vs sealed)
+
+학생 자가 학습 (Thread 12):
+
+> *"sealed interface가 존재하는지 몰랐습니다! 뭔가 코틀린 인 액션에서 sealed interface는 안된다는 식으로 봤었던 것 같아 존재하는지 몰랐었는데 이번 기회를 통해 알 수 있게 되었습니다! 감사합니다!*
+>
+> *찾아본 결과 sealed class와 sealed interface의 차이점은 추상 클래스냐 인터페이스냐로 다중 상속을 가능하게 하는가?로 이해하였습니다."*
+
+학생 자가 학습 (Thread 14):
+
+> *"enum과 sealed의 큰 차이점은*
+> *- enum에서는 하나의 인스턴스만을 갖고 sealed에선 여러 인스턴스를 생성할 수 있다.*
+> *- enum에선 모두 같은 생성자를 가져야하지만 sealed에서는 다른 형태의 생성자를 가질 수 있다.*
+>
+> *그런데 현재 제 코드에선 sealed class의 서브 클래스들이 object로 선언되어있습니다. 이 경우 여러 인스턴스를 생성할 수 있고 여러 형태의 생성자를 가질 수 있다는 sealed의 이점이 사라져 enum과 거의 동등한 상태가 되는 것 같습니다."*
+
+reviewer 자가 답변 (Thread 14):
+
+> *"공식 docs 에서, enum 의 정의를 보면 다음과 같이 나오고 있습니다. `Each enum constant is an object`. 즉, enum 은 의미 그대로 상수의 집합이라고 보시면 될 것 같아요.*
+>
+> *반면, sealed class 는 말그대로 자식의 확장을 정확하게 제한하는 역할을 할 수 있습니다. enum 처럼 쓸 수도 있지만, 그보다 좀 더 확장시켜 클래스의 집합이라고 보셔도 좋을 것 같아요.*
+>
+> *당장은 이정도만 생각을 해두고, 구현해나가면서 장/단점과 사용처를 경험으로 익혀보시는 것도 좋겠습니다."*
+
+→ **학생 자가 깊은 학습 + reviewer 공식 문서 인용 + 학생 부담 최소화** = *MCP `oh-my-oop` 핵심 가치 합류*. PR #129·#143 (Kotlin 어휘 자가 분류) 결 강화.
+
+**MCP 룰 `enum-vs-sealed-class-criteria` 후보** — *enum (상수 집합) vs sealed class (클래스 집합) 구분 기준*.
+
+### 3. reviewer *제 이야기 또한 정답이 아닌 하나의 의견* 메타 어휘 (Thread 9)
+
+reviewer:
+
+> *"우선 아키텍처 및 이에 대한 세부 구현에 대한 관점은 실제 현업에서도 개발자들의 가치관/관점에 따라 갈리는 부분이 많기 때문에, 제 이야기 또한 정답이 아닌 하나의 의견으로 받아들여주셨으면 합니다. :)"*
+
+→ **reviewer 자가 *의견 ≠ 정답* 메타 어휘** = **MCP `oh-my-oop` 핵심 가치 (단일 답 X + N 안 + 트레이드오프) 정점**. PR #95·#23·#26·#36·#129·#142·#109 결 합류 누적 8+ PR.
+
+### 4. Person god-object → HandOfCards 일급 컬렉션 자가 적용
+
+reviewer (Thread 3): *"person 이 생각보다 많은 역할을 가지고 있는 것 같아요. cards 를 일급 컬렉션으로 분리해보는 것은 어떨까요?"*
+
+학생 자가 적용: *"cards를 손에 쥐고 있는 카드 패라고 인지해 HandOfCards라는 일급 컬렉션으로 분리하여 Person이 훨씬 작아졌습니다!"*
+
+→ **god-object 회피 + 도메인 어휘 (HandOfCards)** = PR #21·#117·#129·#138·#143·#118·#141 결 합류.
+
+### 5. 학생 자가 *확장 함수 vs object* 의문 (Thread 11)
+
+reviewer:
+
+> *"전략 패턴으로 주입받는 구조 👍 한편 클래스 - 함수로 제공하기보다, 확장함수를 사용해보는 것도 같이 고민해보면 좋을 것 같아요! 별다른 상태를 가지고 있는데, 함수를 호출하기 위해 클래스를 재 생성하는 방식은 다소 비효율적이지 않을까요?"*
+
+학생 자가 답변:
+
+> *"하지만 수정하면서 한 가지 의문이 생겼습니다. 이런 식으로 확장 함수를 람다로 넘기게 되면 제가 원한(예측한) 두 가지 경우를 나타내는 함수(min, appropriate)가 아니더라도 Int 값을 반환하는 함수라면 뭐든 들어갈 수 있는 상황이 발생한다고 생각합니다.*
+>
+> *그래서 함수를 호출할 때마다 클래스를 재생성하는 방식이 비효율적이므로 주입하는 클래스를 object로 만든다면 문제가 해결되며 주입될 인자 형태 또한 인터페이스로 지정할 수 있어 더 좋지 않을까? 하고 생각해보았습니다!"*
+
+→ **확장 함수 vs object 트레이드오프 학생 자가 의문 + 타입 안전성 의식** = **MCP 룰 `extension-function-vs-object-strategy` 후보**.
+
+reviewer 자가 답변: *"object 로 제공할 경우 일종의 유틸 클래스의 역할을 하므로 괜찮다고 생각해요!"*
+
+### 6. 빌더 패턴 X 블랙잭 무관 — 학생 자가 *study 패키지* 이동
+
+reviewer (Thread 7): *"빌더 패턴을 생각하고 구현해주신 클래스라면, 접근방식이 잘못된 것 같아요. 추가로, 빌더 클래스를 따로 두었을때의 이점이 있을까요? 빌더 패턴의 구현 방식 및 의의에 대해 학습해보시는 것은 어떨까요?"*
+
+학생 자가 적용 (Thread 8): *"수업에서 다른 실습코드라 test/study로 패키지를 변경하였습니다!"*
+
+→ **블랙잭 무관 코드 = study 패키지 이동** = PR #58 (DSL Builder 의도 위반) + PR #130 (DSL Study 코드 = test) + PR #118 (`pattern-applied-without-need`) 결 합류 누적 8+ PR.
+
+### 7. label/text/toString 도메인 vs View 4 자리 (Thread 4·5·6)
+
+reviewer 3 자리에 걸쳐 *도메인 어휘 vs View 어휘* 분리 권유.
+
+→ **Domain ↔ View 분리** = PR #21·#117·#129·#143·#126 (model-view-dependency-direction) 결 합류 누적 13+ PR ⭐⭐⭐.
+
+### 8. 추가 칭찬
+
+- Thread 1: *"view 를 역할에 잘게 쪼개주신 것으로 보여요!"*.
+- Thread 11: *"전략 패턴으로 주입받는 구조 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. `MainView` 명명 → `DrawView` 자가 변경 (Thread 1)
+
+reviewer: *"MainView 라는 네이밍을 봤을 때는 모든 View 를 포함할 수 있을것 같은 어감을 줍니다. 좀 더 구체적인 이름을 지어볼 수 있을까요?"*
+
+학생 자가 적용 → `DrawView` (카드 뽑는 View).
+
+→ **이름 의미 정확성** = PR #36·#117·#129·#130·#139·#109·#113·#118·#96 결 합류 누적 10+ PR.
+
+### 2. enum `has` 함수 vs `of` nullable (Thread 2)
+
+reviewer: *"enum 에서 has 함수가 꼭 필요한지 고민해보면 좋을 것 같아요. of 로 값을 가져올 수 있고, 없다면 예외를 던지는게 더 자연스럽지 않을까요?"*
+
+학생 자가 적용: *"has는 뷰에서 쓰이던 로직이라 뷰에서 새로운 Decision을 만들어 of의 널 값을 이용해 다시 입력받도록 하였습니다!"*
+
+→ **enum has + of 활용 + nullable 재입력** = PR #138·#35 (Kotlin 예외 처리 nullable) 결 합류.
+
+### 3. BlackJackGame ↔ BlackJackGameBluePrint interface — controller 로직 위치 (Thread 9)
+
+reviewer:
+
+> *"해당 클래스의 로직들은 controller 에서 수행해야할 로직들이 많은 것 같아요. BlackJackGameBluePrint 인터페이스가 컨트롤러 레벨에 위치해주신 것도 그 이유 중 하나일 것 같구요 ㅎㅎ"*
+
+학생 자가 답변:
+
+> *"우선 저는 controller가 뷰와 도메인을 단순히 연결시키는 역할이라고 생각했습니다. (...) BluePrint 인터페이스를 컨트롤러 레벨에 위치한 이유는 BlackJackGame이라는 도메인을 사용하는 방법을 컨트롤러에게 알려주는 설명서라고 생각했기 때문입니다!"*
+
+reviewer 자가 답변 (긴 메타 어휘):
+
+> *"제 이야기 또한 정답이 아닌 하나의 의견으로 받아들여주셨으면 합니다. :)*
+>
+> *저의 경우, 말씀하신 것처럼 controller 는 중계자의 역할을 하는 것이 맞다고 생각해요. 다만, model 과 view 는 controller 의 존재를 알아서는 안된다고도 생각합니다. (이 부분은 해석의 차이가 있지만 MVC, MVP, MVVM 등의 아키텍처의 기원을 공부해보시면 조금 감이 잡히실 수 있을 것 같아요.)*
+>
+> *어쨌든 이 논리를 확장시켜보면, controller 를 모르므로 결국 model 도 view 를 알지 못하고, view 도 model 을 알지 못하는 구조가 되는 것이죠.*
+>
+> *그런데, BlackJackGame 의 경우*
+> *1) 컨트롤러의 명세(BlackJackGameBluePrint) 를 구현하고 있고, (= 컨트롤러의 존재를 알고 있고)"*
+
+→ **MVC 의 origin (MVP/MVVM 비교)** + **BluePrint interface = 도메인이 controller 인지** 안티패턴.
+
+**MCP 룰 `domain-knows-controller-via-interface` 후보** — *도메인이 controller 명세 interface 구현 = MVC 위반*.
+
+### 4. Deck 카드 부족 예외처리 (Thread 10)
+
+reviewer: *"카드를 더이상 뽑을 수 없을 떄의 예외처리가 필요하지 않을까요?"*
+
+학생 자가 적용: *"예외처리하여 카드가 없을 경우 카드 드로우를 종료하고 결과 산출로 넘어가도록 하였습니다!"*
+
+→ **카드 부족 처리 (graceful)** = PR #113·#118·#138·#141·#130 결 합류 누적 6+ PR.
+
+### 5. 전략 패턴 클래스 재생성 비효율 (Thread 11)
+
+§5 참조. **MCP 룰 `extension-function-vs-object-strategy` 후보**.
+
+### 6. sealed interface 학생 자가 학습 (Thread 12)
+
+§2 참조. **MCP 룰 `sealed-interface-vs-sealed-class` 후보**.
+
+### 7. 확장 함수 활용 (Thread 13)
+
+reviewer: *"이 부분도 확장함수로 제공하면 좀 더 가독성 및 사용성이 좋아질 것 같아요! `cardNumber.toText()`"*
+
+→ **Kotlin 확장 함수 + 가독성** = PR #117·#143 (Kotlin 어휘) 결 합류.
+
+### 8. enum vs sealed class 차이 학생 자가 학습 (Thread 14)
+
+§2 참조.
+
+### 9. `Person` god-object — §4 참조
+
+## 대표 인용
+
+> [vagabond95 Thread 9]
+> *"우선 아키텍처 및 이에 대한 세부 구현에 대한 관점은 실제 현업에서도 개발자들의 가치관/관점에 따라 갈리는 부분이 많기 때문에, 제 이야기 또한 정답이 아닌 하나의 의견으로 받아들여주셨으면 합니다. :)"*
+
+→ **reviewer 의 *의견 ≠ 정답* 메타 어휘** — **MCP `oh-my-oop` 핵심 가치 정점**.
+
+> [vagabond95 Thread 14]
+> *"공식 docs 에서, enum 의 정의를 보면 다음과 같이 나오고 있습니다. `Each enum constant is an object`. 즉, enum 은 의미 그대로 상수의 집합이라고 보시면 될 것 같아요. 반면, sealed class 는 말그대로 자식의 확장을 정확하게 제한하는 역할을 할 수 있습니다."*
+
+→ **공식 문서 인용 + 정확한 정의 어휘**.
+
+> [briandr97 Thread 14]
+> *"enum에서는 하나의 인스턴스만을 갖고 sealed에선 여러 인스턴스를 생성할 수 있다. (...) 그런데 현재 제 코드에선 sealed class의 서브 클래스들이 object로 선언되어있습니다. 이 경우 여러 인스턴스를 생성할 수 있고 여러 형태의 생성자를 가질 수 있다는 sealed의 이점이 사라져 enum과 거의 동등한 상태가 되는 것 같습니다."*
+
+→ **학생 자가 깊은 학습 + 자가 코드 자가 분석**.
+
+> [briandr97 Thread 11]
+> *"이런 식으로 확장 함수를 람다로 넘기게 되면 제가 원한(예측한) 두 가지 경우를 나타내는 함수가 아니더라도 Int 값을 반환하는 함수라면 뭐든 들어갈 수 있는 상황이 발생한다고 생각합니다."*
+
+→ **학생 자가 타입 안전성 의식**.
+
+## 얻은 교훈 (보편)
+
+1. **enum (상수 집합) vs sealed class (클래스 집합) 구분 기준** — **MCP 룰 `enum-vs-sealed-class-criteria` 후보**.
+
+2. **sealed interface vs sealed class** — **MCP 룰 `sealed-interface-vs-sealed-class` 후보**.
+
+3. **reviewer *의견 ≠ 정답* 메타 어휘** — **MCP `oh-my-oop` 핵심 가치 정점** 누적 8+ PR.
+
+4. **확장 함수 vs object 전략 패턴 트레이드오프** — **MCP 룰 `extension-function-vs-object-strategy` 후보**.
+
+5. **도메인이 controller 인지 (BluePrint interface) = MVC 위반** — **MCP 룰 `domain-knows-controller-via-interface` 후보**.
+
+6. **빌더 패턴 X 블랙잭 무관 = study 패키지 이동** — *pattern-applied-without-need* 누적 8+ PR.
+
+7. **Person god-object → HandOfCards 일급 컬렉션** — 누적 다수 PR.
+
+8. **MainView → DrawView 명명 정확성** — 누적 10+ PR.
+
+9. **공식 docs 인용 + reviewer 정의 어휘** = *MCP 핵심 가치*.
+
+10. **학생 자가 타입 안전성 의식 (확장함수 람다)** — *깊은 Kotlin 어휘 학습*.
+
+## MCP 룰 후보 신규 + 강화 (PR #19)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `enum-vs-sealed-class-criteria` | 신규 | 1 (#19) |
+| `sealed-interface-vs-sealed-class` | 신규 | 1 (#19) |
+| `extension-function-vs-object-strategy` | 신규 | 1 (#19) |
+| `domain-knows-controller-via-interface` | 신규 | 1 (#19) |
+| `sealed-vs-abstract-vs-open-locator` | 강화 | 7+ |
+| `pattern-applied-without-need` | 강화 | 8+ |
+| `model-view-dependency-direction` | 강화 | 13+ ⭐⭐⭐ |
+| `function-name-vs-return-semantic-mismatch` | 강화 | 10+ |
+| `card-shortage-handling-strategy` | 강화 | 6+ |

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

@@ -0,0 +1,193 @@
+# PR #59 — [빅스] 2단계 블랙잭
+
+- **Reviewee:** [@briandr97](https://github.com/briandr97) (빅스)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/59
+- **단계:** 2단계
+- **리뷰어:** [@vagabond95](https://github.com/vagabond95)
+- **라인 코멘트:** 6 스레드 — *PR 본문 MVC 1인 vs 다인 협업 시나리오 학생 자가 의문 + 수업 시간 템플릿 메서드 패턴 자가 학습 적용 / 다른 팀원 설명 가능 기준 + View vs Output 분리 학생 자가 합당 인정 + return lift vs else 객체지향 생활체조 trade-off + State 인터페이스 = 일반적 / 특정 상태 의존 X*
+- **briandr97 양 단계 완성** (1단계 #19).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — MVC 1인 vs 다인 협업 시나리오 학생 자가 의문 정점
+
+PR 본문:
+
+> *"블랙잭 2단계 제출합니다! 1단계에서 리뷰어님이 말씀해주신 컨트롤러 부분에 대해 잘 생각해보았습니다.*
+>
+> ***현재와 같이 m, v, c 모두를 한 명이 개발하고 있는 전지적 상태에서는 1단계에서 활용한 것처럼 명세를 작성하고 그에 맞춰 블랙잭 게임을 작성하는 것이 컨트롤러를 더욱 읽기 쉽게 해준다고 생각했습니다.***
+>
+> *하지만 **m, v, c를 각자 다른 사람이 개발한다고 생각했을 때 도메인 개발자는 프린트 되는 시점을 알 필요가 없고 단순히 필요한 값들만 전달 받으면 된다고 생각했습니다.***
+>
+> *물론 이 경우에도 도메인은 결국 누군가로부터 (print함수가 아니더라도) 값을 전달받아야하기 때문에 자신에게 값을 전달해줄 Controller의 존재를 알고 있다고 생각되어 **domain과 view는 Controller의 존재를 알지 못한다는 부분은 아직 잘 이해가 가지 않습니다.** (domain과 view가 서로 모른다는 부분은 이해했습니다)*
+>
+> *이 부분에 대한 리뷰어님의 생각이 궁금합니다!*
+>
+> ***수업시간에 배운 템플릿 메서드 패턴을 상태에 적용하여 새로운 방식으로 코드를 작성**해보았습니다!"*
+
+→ **MCP 룰 `mvc-collaboration-scenario-vocabulary`** ⭐⭐⭐ **신규 정점** — *학생 자가 MVC 1인 vs 다인 협업 시나리오 사고 + 도메인 개발자 입장 시뮬레이션*. PR #97 (`maintainability-over-performance-priority`)·PR #154 (`controller-imagination-test`) 결의 *컨트롤러 책임 사고* 다른 축 — *학생 자가 시나리오 사고 정점*.
+
+→ **MCP 룰 `template-method-pattern-on-state`** ⭐⭐ 신규 — *수업 시간 학습 → 상태 패턴 적용 자가 학습*. PR #89 (`pr-body-student-self-study-on-reviewer-recommendation`)·PR #62 결 합류 누적 3 PR.
+
+→ **`student-self-acknowledgment-of-confusion`** ⭐⭐ — *"아직 잘 이해가 가지 않습니다"* 학생 자가 명시.
+
+## 못한 점 (설계 관점)
+
+### 1. 다른 팀원 설명 가능 기준 (Thread 0) — 정점
+
+reviewer 2개 질문:
+
+> *"View 영역에서 View 와 Output 을 별도로 두었을때의 이점이 있을까요?"*
+>
+> *"다른 팀원이 개발을 진행할 때, XxxView 와 XxxOutput 에 어떤 코드를 넣어야할지 명확한 기준을 설명할 수 있을까요?"*
+
+학생 자가 답변:
+
+> *"뷰를 출력하는 구체적이고 상세한 코드들은 Output에 두어 View는 Output의 함수를 호출하게 합니다. View에서 호출된 Output의 함수명으로 무슨 일을 하는지 충분히 알 수 있다고 판단하여 이로써 View의 코드를 깔끔하게하고 해당 뷰가 어떤 일을 하는지 한 눈에 알아볼 수 있도록 하고자 하였습니다.*
+>
+> *분리했던 이유는 앞서 위에서 말했던 이유들 때문이었습니다.*
+>
+> ***사실 다른 뷰들에서는 Input과 Output을 분리하고 Input과 Output의 함수들을 모아 View에서 호출하도록 하였는데 Result의 경우 Input이 없다보니 Output과 View의 역할이 혼동될 수 있다고 생각합니다.***
+>
+> *그러나 다른 뷰들이 분리된 기준과 통일성을 가져가고 싶어 이처럼 작성하게 되었습니다.*
+>
+> *설명하고자 한다면 Output에선 직접적으로 print함수를 호출하여 출력하는 작업을 하고 View에서는 Output에서 정의한 함수들을 호출하는 작업을 수행한다라고 설명할 것 같습니다.*
+>
+> *하지만 결과적으로 Input이 없기 때문에 Output과 View 모두 출력을 하고있어 **혼동 될 수 있다고 생각하고 합쳐야한다는 의견 또한 합당하다고 생각됩니다!***
+>
+> *그래서 합친 코드로 다시 푸시했습니다!"*
+
+→ **MCP 룰 `team-explanation-criteria-test`** ⭐⭐⭐ **신규 정점** — *다른 팀원에게 *어떤 코드를 넣어야할지 명확한 기준 설명 가능?* 시그널*. PR #97 (`code-judgment-criteria-test-fn-clarity`)·PR #134 (`abstract-vs-interface-criteria`) 결 합류 누적 3 PR — *판단 기준 어휘 정점*.
+
+→ **MCP 룰 `student-self-acknowledgment-opposing-view-validity`** ⭐⭐ — *학생 자가 *반대 의견도 합당하다* 자가 인정 어휘*. PR #150 (`accidental-vs-essential-duplication-distinction` reviewer 학생 의견 인정) 결의 *상호 의견 인정* 학생 측 다른 축.
+
+### 2. View loop 부적절 — 컬렉션 변경 시 View 변경 (Thread 1)
+
+reviewer 2개 질문:
+
+> *"names 에 대한 루프를 view 에서 진행하는 것이 적절할까요?"*
+>
+> *"names 의 컬렉션 타입이 바뀌면, View 에도 변경이 발생할 것 같아요."*
+
+학생 자가 답변: *"루프를 Controller로 뺐습니다! 그러므로 names 컬렉션도 사라졌습니다!"*
+
+→ **MCP 룰 `view-no-loop-collection-decoupling`** ⭐⭐⭐ 신규 — *View에서 컬렉션 루프 = 컬렉션 타입 변경 시 View 변경 시그널*. PR #30·#42 (View 책임 어휘) 결 합류 → ***View 책임 어휘 정점***.
+
+### 3. State 인터페이스 = 일반적 / 특정 상태 의존성 부적절 (Thread 5)
+
+reviewer:
+
+> *"State 는 상태에 대한 '일반적인' 기능을 명세해놓은 인터페이스인데, 특정 상태에 대한 의존성이 존재하는 것이 어색한 것 같아요."*
+
+학생 자가 답변: *"넵 toStay를 State에서 삭제하고 Player에서 구현해주었습니다."*
+
+→ **MCP 룰 `interface-no-concrete-dependency`** ⭐⭐⭐ 신규 — *인터페이스 = 일반 기능 / 특정 상태 의존성 X*. PR #150 (`abstract-class-knowing-concretes-anti-pattern`)·PR #154 (`state-pattern-no-if-type-check`) 결 합류 누적 3 PR — *추상↔구현체 분리 어휘 정점*.
+
+### 4. return lift up vs else 객체지향 생활체조 trade-off (Thread 3)
+
+```kotlin
+// 변경 전 - else 회피
+if (handOfCards.isBust()) return Bust(handOfCards)
+return Stay(handOfCards)
+```
+
+reviewer 제안:
+
+```kotlin
+return if (handOfCards.isBust()) {
+    Bust(handOfCards)
+} else {
+    Stay(handOfCards)
+}
+```
+
+reviewer:
+
+> *"저는 개인적으로는 이런 형태의 구현을 더 선호하는데요, return 이 if 문 범위에 묶일 경우 논리 흐름을 다시 거슬러 올라가 생각할 필요가 적어지는 이점이 있습니다.*
+>
+> *현재 구현하신 구조는, return 이 연속으로 선언되어 있어서 Stay 를 리턴하는 경우는 뭐지? 라고 다시 생각하게 되더라구요 ㅎㅎ"*
+
+학생 자가 답변:
+
+> *"return 조건문 형식으로 수정하였습니다! 저도 return을 lift하는 것이 더 가독성이 좋다고 생각됩니다.*
+>
+> *다만 **else를 지양하라는 객체지향 생활체조 원칙 때문에 이렇게 진행하였는데 해당 원칙은 자바를 기반으로 기술되어 코틀린에서는 예외가 있을 수 있다고 생각**됩니다!"*
+
+→ **MCP 룰 `return-lift-vs-else-tradeoff`** ⭐⭐⭐ 신규 — *객체지향 생활체조 else 회피 vs Kotlin lift return 가독성 trade-off*. PR #37 (`principle-as-guide-not-absolute`)·PR #134 (3 인스턴스 변수 원칙) 결 합류 → ***원칙 vs 본질 어휘 누적 5 PR*** 정점.
+
+→ **`java-based-principle-kotlin-exception`** ⭐⭐ — *자바 기반 원칙 = 코틀린 예외 가능 학생 자가 자가 정당화*.
+
+### 5. 확장함수 위치 — 부모 클래스 (Thread 2)
+
+reviewer: *"양수/음수로 전환하는 확장함수를 제공해도 괜찮겠네요!"*
+
+학생 자가 답변:
+
+> *"넵 감사합니다! 추가하였습니다! 다만 해당 확장함수를 선언할 위치가 고민되었는데 **결과값을 계산해야할 State들의 부모 클래스인 Finished 클래스에 추가**하였습니다!"*
+
+→ **`extension-fn-location-near-parent-class`** ⭐⭐ — *확장함수 위치 = 부모 클래스 (계층 정합)*. PR #42 (`mapper-top-level-declaration`) 결 합류.
+
+### 6. Casino + Persons 묶기 (Thread 4)
+
+reviewer: *"리턴하는 모델을 다시 묶어주신 이유가 있을까요?"*
+
+학생 자가 답변: *"Casino에 Persons가 존재하여 굳이 두 번에 나눠서 보내줘야 할 필요가 없다고 느꼈습니다!"*
+
+→ **`return-bundling-via-existing-aggregate`** ⭐⭐ — *기존 집합 객체를 통한 리턴 묶기*. PR #38 (Pair vs data class) 결 합류.
+
+### 7. reviewer 마무리 — 의도 설명 칭찬
+
+reviewer:
+
+> *"각각 구현에 대한 의도를 상세하게 남겨주셔서, 같이 생각해볼 수 있는 기회가 되어 좋았습니다 :)"*
+
+→ **`reviewer-student-detailed-intent-acknowledgment`** ⭐⭐ — *학생 자가 의도 상세 설명 + reviewer 함께 생각하는 기회 인정*. PR #150 (`reviewer-student-passion-acknowledgment`) 결 합류 — *학생 답변 인정 어휘*.
+
+## 대표 인용
+
+> [briandr97 PR 본문]
+> *"m, v, c를 각자 다른 사람이 개발한다고 생각했을 때 도메인 개발자는 프린트 되는 시점을 알 필요가 없고 단순히 필요한 값들만 전달 받으면 된다고 생각했습니다."*
+
+→ **학생 자가 MVC 협업 시나리오 어휘 정점**.
+
+> [briandr97 PR 본문]
+> *"domain과 view는 Controller의 존재를 알지 못한다는 부분은 아직 잘 이해가 가지 않습니다."*
+
+→ **학생 자가 혼동 명시 어휘**.
+
+> [vagabond95 Thread 0]
+> *"다른 팀원이 개발을 진행할 때, XxxView 와 XxxOutput 에 어떤 코드를 넣어야할지 명확한 기준을 설명할 수 있을까요?"*
+
+→ **다른 팀원 설명 가능 기준 어휘 정점**.
+
+> [briandr97 Thread 0]
+> *"혼동 될 수 있다고 생각하고 합쳐야한다는 의견 또한 합당하다고 생각됩니다!"*
+
+→ **학생 자가 반대 의견 합당성 인정 어휘**.
+
+> [briandr97 Thread 3]
+> *"else를 지양하라는 객체지향 생활체조 원칙 때문에 이렇게 진행하였는데 해당 원칙은 자바를 기반으로 기술되어 코틀린에서는 예외가 있을 수 있다고 생각됩니다!"*
+
+→ **자바 기반 원칙 / 코틀린 예외 학생 자가 정당화 어휘**.
+
+> [vagabond95 Thread 5]
+> *"State 는 상태에 대한 '일반적인' 기능을 명세해놓은 인터페이스인데, 특정 상태에 대한 의존성이 존재하는 것이 어색한 것 같아요."*
+
+→ **인터페이스 일반 / 특정 의존성 부적절 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **MVC 1인 vs 다인 협업 시나리오 학생 자가 사고** — **MCP 룰 `mvc-collaboration-scenario-vocabulary` 후보** ⭐⭐⭐ 정점.
+2. **다른 팀원 설명 가능 기준** — **MCP 룰 `team-explanation-criteria-test` 후보** ⭐⭐⭐ 정점.
+3. **View 컬렉션 루프 = 변경 결합 시그널** — **MCP 룰 `view-no-loop-collection-decoupling` 후보** ⭐⭐⭐.
+4. **인터페이스 = 일반 / 특정 의존성 X** — **MCP 룰 `interface-no-concrete-dependency` 후보** ⭐⭐⭐.
+5. **객체지향 생활체조 else 회피 vs Kotlin lift return** — **MCP 룰 `return-lift-vs-else-tradeoff` 후보** ⭐⭐⭐. 원칙 vs 본질 누적 5 PR 정점.
+6. **수업 시간 학습 → 상태 패턴 적용** — **MCP 룰 `template-method-pattern-on-state` 후보** ⭐⭐.
+7. **확장함수 위치 = 부모 클래스 (계층 정합)** — **MCP 룰 `extension-fn-location-near-parent-class` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **briandr97 양 단계 완성 (1단계 #19 → 2단계 #59)**.
+- **vagabond95 reviewer 어휘** — *다른 팀원 설명 가능 기준* 시그니처 (PR #101 결).
+- **학생 자가 시나리오 사고 어휘 정점** — MVC 1인 vs 다인 협업 시뮬레이션 + 수업 시간 학습 자가 적용.
+- **원칙 vs 본질 누적 5 PR** (PR #38 + #62 + #43 + #37 + #59) — *단일 답 거부 어휘 정점*.

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

@@ -0,0 +1,175 @@
+# PR #70 — [블랙잭 1단계] 채채 미션
+
+- **Reviewee:** [@chaehyuns](https://github.com/chaehyuns)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/70
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag (두루)
+- **라인 코멘트:** 26 스레드 — *짧지만 핵심 진단 + 학생 자가 학습 풍부* (양 단계 분석된 reviewee — 2단계 #98 별도)
+
+## 잘한 점 (설계 관점)
+
+- **`ShuffleCardMachine` 전략 + `CardMachineManager` 자가 토론** — 학생 자가 답변: *"처음엔 ShuffleCardMachine을 부 생성자 혹은 주 생성자를 받아서 CardMachine을 관리하려 했습니다. 하지만 ShuffleCardMachine은 각 객체에서 다른 state를 가지지 않기 때문에 object로 관리를 하는게 맞다는 생각이 들어 CardMachineManager을 만들었습니다."* — *상태 없음 → object 자가 학습*. PR #146·#108·#133 와 같은 결.
+- **방어적 복사 자가 적용** — 두루 칭찬: *"방어적 복사의 활용 좋습니다~👍"*. PR #108·#132·#133·#85·#58·#137·#148 와 같은 결.
+- **Dealer 입장에서 추가 카드 비교 → Card 책임 이전 자가 반영** — 두루 진단 *"해당 내용을 Card 에서 던지도록 하는 것은 어떤가 하는 생각이 듭니다!"* + 학생 자가 답변: *"Card 에서 던지는 게 더 올바른 사용인거 같습니다! 감사합니다!"*. *Tell-Don't-Ask 자가 학습*. PR #124·#108·#128·#135·#114·#125 와 같은 결.
+- **추상 클래스 `GameParticipant` 활용** — 두루 칭찬: *"중복을 줄여주기 위한 추상 클래스의 사용 좋습니다~👍"*.
+- **Validation Check 일급 컬렉션** — 두루 칭찬 (중복 제거 권고 + 자가 반영).
+- **Card.toString 오버라이딩** — 두루 칭찬: *"Card 객체의 toString() 오버라이딩하여 적용한 내용 좋네요~👍"*. PR #88·#137·#90·#146 와 같은 결.
+- **테스트 코드 깔끔성** — 두루 칭찬.
+- **`maxOrNull` vs `max()` 명시적 타입 자가 학습** — 두루 진단 *"네이밍만 본다고 Int 로 리턴값이 예상되어 사용하였는데, 실제로 topScore() 메서들 사용시 빨간줄로 되어 있어 살펴보니 Kotlin 에서는 max(): Int? 되어 있었습니다. 현재 코틀린 버전에서는 혼돈을 줄이고자 maxOrNull()로 이름이 변경되어서, 위에서 처럼 혼란을 피하고 위하여 멤버 변수와 리턴 타입을 명시해보는 것도 추후 다른 사람들이 봤을 때 직관적으로 코드를 이해하는데 큰 도움이 될 것 같긴 합니다~"*. **Kotlin 어휘 (max → maxOrNull 변경 + 명시 타입) 자가 학습 모범**.
+- **HandCards 가독성 자가 반영** — 두루 권고 *"baseScore + ANOTHER_CARD_SCORE 를 하나의 변수로 만들어 두고 사용하는 것도 가독성 측면에서 조금이라도 좋아질 수 있을 것 같다는 생각도 듭니다!!"* + 학생: *"ACE 카드 넘버에 10을 더해야한다는 것에 초점을 맞추다 보니 가독성을 잃은 거 같습니다."*.
+- **`isCanAddCard` Controller 책임으로 이전** — 두루 진단 *"controller 에서도 충분히 처리가 가능한 내용을 Player까지 끌고 온것은 아닌가? 라는 생각이 들기도 합니다🥲"* + 학생: *"controller에서 처리하는 것이 더 깔끔하고 직관적으로 이해가 될 수 있고 추상클레스에 addCard를 하도록 바꿀 수 있다는 판단이 드네요!"*. *Tell-Don't-Ask 의 반대 트레이드오프* (도메인 → controller 이전).
+
+## 못한 점 (설계 관점)
+
+### 1. `mutable machine` 외부 변경 가능성 자가 반영
+
+두루 진단: *"해당 machine을 mutable 하게 지정하고 외부에서 변경이 가능하도록 작성하신 이유가 있을까요?? 부 생성자로 CardMachine를 받아서 객체 인스턴스를 생성하는 방법도 있을 것 같은데, 이렇게 지정하신 이유가 궁금합니다!🤔"*
+
+학생 자가 답변: *"지금 다시 보니 mutable하게 지정할 이유는 하나도 없었네요! 감사합니다!"*
+
+→ **외부 변경 가능성 = 캡슐화 부재**. *val + 생성자 주입* 정공. PR #58·#85·#108·#132·#133 와 같은 결.
+
+### 2. `cards` 지연 초기화 권고
+
+두루: *"수정이 반드시 필요한 내용은 아니며, 해당 내용은 cards 를 지연초기화 하여 인스턴스를 생성해두도록 수정해볼 수도 있을 것 같다는 생각이 듭니다!"*
+
+학생 자가 답변: *"리소스 사용을 최적화하고, 객체의 초기화 시점을 실제 사용 시점으로 늦춰 성능을 향상시키는 등 지연 초기화에 대한 이점을 찾아보게 되었습니다😊"*
+
+→ **`by lazy` Kotlin 어휘 학습**. PR #85·#137 와 같은 결.
+
+### 3. 추상클래스 생성자 제약 자가 학습
+
+두루: *"중복을 줄여주기 위한 추상 클래스의 사용 좋습니다~👍 추상클래스에서 생성자를 지정함으로 인하여 여러가지 제약이 생길텐데, 이부분은 고민해봐도 좋을 것 같다는 생각이 듭니다!!"*
+
+학생 자가 답변: *"추상클래스의 이점만을 생각하지 않고 제약에 대한 사항은 잊고 있었는데 다시 한번 리마인드 시켜주셔서 감사합니다!"*
+
+→ **추상 클래스 + 생성자 = 자식 모두 동일 생성자 강제 + 다중 상속 X**. *interface = 다중 구현 + 생성자 X*. PR #74·#108·#133·#137 와 같은 결.
+
+### 4. `HandCards.score 계산 책임` 의문 진단
+
+두루: *"Card의 점수를 계산하는 것이 HandCards에서 맡아서 해야 하는 책임일지 고민해봐도 좋을 것 같습니다~"*
+
+학생: *"객체의 책임을 어디서 맡아야 하는지가 정말 어렵군요! 다시 한번 고민해보겠습니다!"*
+
+→ **점수 계산 책임 위치 트레이드오프**. *HandCards (카드 묶음) vs Score (별도 객체) vs Card (자기 점수)*. PR #131·#136·#146·#147 와 같은 결.
+
+### 5. `Dealer 가 결과 판단 책임 = 너무 큰 책임?` 학생 자가 토론
+
+학생 자가 답변: *"Dealer에 대한 책임이 너무 큰가 하는 의문이 저도 들었습니다! 하지만 딜러가 아니라면 어떤 객체가 이 일을 수행해야하는지에 대한 고민을 하다보니 심판 객체를 만드는 것 또는 어떤 결과 계산기를 만드는 것이 살짝 어색하다는? (너무 현실 세계에 투영해서 보고 있는 걸까요?) 하는 의문이 들었습니다! 혹시 두루의 생각은 어떠신가요? 😥"*
+
+두루 답변: *"딜러에서도 해당 판별을 가져도 되기는 하지만, 억지스럽기는 하지만 만약 요구사항이 `딜러도 플레이어가 될 수 있으며, 플레이어도 딜러가 될 수 있다. 이는 곧 딜러 vs 딜러의 대결도 가능해지며, 플레이어 vs 플레이어의 대결도 가능해진다`라는 조건이 생기게 된다면, 플레이어 vs 플레이어의 경우 점수 계산을 어떻게 할 수 있을것인가??라는 내용에 부딪힐 것 같다는 생각이 듭니다🤔 추후 요구사항의 변경등에 대해서도 유연하게 대처할 수 있도록 만들면 리팩토링을 하고 기능을 추가할 때도 좀 더 유연해지지 않을까 라는 생각이 듭니다~"*
+
+→ **현실 메타포 (Dealer 판단) vs 확장성 (Participant vs Participant) 트레이드오프**. *PR #74 (알송, 말리빈) 의 Referee 자가 토론* / *PR #148·#151·#49·#132 의 참가자 vs 참가자 일반화* 와 같은 결.
+
+### 6. `Dealer 룰 = 변경 시 GameParticipant + 본 객체 모두 수정` 위험
+
+두루: *"해당 내용은 추후 조건이 바뀌게 되었을 때, GameParticipant 뿐만 아니라 해당 내용도 수정이 되어야 할 수도 있다는 생각이 드네요🤔"*
+
+→ **룰 분산 = 변경 파급**. *단일 진입점 (Dealer 자기 메서드)*이 정공.
+
+### 7. `Players` 중복 검증 + 팩토리 검증 중복
+
+두루: *"Validation Check 좋습니다~👍 다만 밑에 팩토리 함수에서 Check를 한 내용이 중복되어 들어가있는 것 같습니다🥲"*
+
+학생: *"허걱 그렇군요! 중복된 로직은 삭제하겠습니다!"*
+
+→ **검증 중복 = init + factory 양쪽 = 코드 중복 + 변경 파급**. PR #58 와 같은 결.
+
+### 8. `OutputView` 메시지 상수화 권고
+
+두루: *"문구가 바뀌었을 때 한곳에서 수정이 가능하다는 이점도 있어서 메시지들을 상수값으로 관리해보는 것도 고민해보면 좋을 것 같습니다!!"*
+
+→ **메시지 상수화 = 변경 시 한 곳 수정**.
+
+### 9. `IsAddCardInputView` Format 권고
+
+두루: *"수정이 필요한 것은 아니며, 해당 내용은 Format을 사용해서 해당 값들을 관리해볼 수도 있겠네요!"*
+
+→ **`String.format` Kotlin 어휘 활용**.
+
+### 10. `HandCards.cards` toString 사용 권고
+
+두루: *"해당 내용은 Cards의 toString을 이용하도록 수정을 해보는 것도 좋을 것 같다는 생각이 듭니다~"*
+
+→ **`toString` 활용 = Card 자기 표현**. PR #88·#137·#90·#146 와 같은 결.
+
+### 11. 테스트 함수명 자가 학습 권고
+
+두루 권고 + 예시:
+```kotlin
+@Test
+fun `자동차가 1칸 이동하면 거리는 1이다`() {
+     // given / when / result
+}
+```
+
+학생: *"네이밍에 대한 고민을 더해보겠습니다!"*
+
+→ **테스트 함수명 = 기능 명세 + given/when/result 주석 분리**. PR #41·#90·#133·#136·#137 와 같은 결.
+
+### 12. `Players` 하드코딩 상수화
+
+두루: *"해당 하드 코딩된 내용도 상수화를 해보는 것도 좋을 수도 있겠다는 생각이 듭니다!💪"*
+
+→ **하드코딩 매직넘버 → 상수화**. PR #53·#75·#114·#146 와 같은 결.
+
+## 리뷰어 의견 요지
+
+- **mutable 외부 변경 = 캡슐화 부재** — *val + 생성자 주입*.
+- **지연 초기화 (`by lazy`) = 리소스 최적화**.
+- **추상클래스 생성자 = 자식 모두 동일 생성자 강제 + 다중 상속 X**.
+- **카드 책임 = Card 자기 메시지** — *Tell-Don't-Ask*.
+- **현실 메타포 (Dealer 판단) vs 확장성 (Participant vs Participant)** — *현실 메타포 정공 + 확장성 미래 가능성*.
+- **메시지 상수화 + format 활용**.
+- **toString = Card 자기 표현**.
+- **테스트 함수명 = 기능 명세 + given/when/result**.
+- **하드코딩 → 상수화**.
+
+## 대표 인용
+
+**두루 (확장성 = 참가자 vs 참가자 추상화, Dealer.kt):**
+> 딜러에서도 해당 판별을 가져도 되기는 하지만, 억지스럽기는 하지만 만약 요구사항이 `딜러도 플레이어가 될 수 있으며, 플레이어도 딜러가 될 수 있다. 이는 곧 딜러 vs 딜러의 대결도 가능해지며, 플레이어 vs 플레이어의 대결도 가능해진다`라는 조건이 생기게 된다면, 플레이어 vs 플레이어의 경우 점수 계산을 어떻게 할 수 있을것인가??라는 내용에 부딪힐 것 같다는 생각이 듭니다🤔
+
+**두루 (max → maxOrNull Kotlin 어휘 변경, Deck.kt):**
+> 개인적으로 멤버 변수와 메서드의 리턴 타입을 모두 명시해주는데, 이는 타입을 직관적으로 알기 위하여 사용하는 것도 좋다고 생각이 들긴 합니다!
+>
+> 예를 들어 아래와 같은 코드가 있다고 하였을 때, 네이밍만 본다고 Int 로 리턴값이 예상되어 사용하였는데, 실제로 topScore() 메서들 사용시 빨간줄로 되어 있어 살펴보니 Kotlin 에서는 max(): Int? 되어 있었습니다
+> ```
+> fun topScore() = counts.max()
+> ```
+> 현재 코틀린 버전에서는 혼돈을 줄이고자 maxOrNull()로 이름이 변경되어서, 위에서 처럼 혼란을 피하고 위하여 멤버 변수와 리턴 타입을 명시해보는 것도 추후 다른 사람들이 봤을 때 직관적으로 코드를 이해하는데 큰 도움이 될 것 같긴 합니다~
+
+**두루 (책임 분산 변경 파급 위험, Dealer.kt:28):**
+> 해당 내용은 추후 조건이 바뀌게 되었을 때, GameParticipant 뿐만 아니라 해당 내용도 수정이 되어야 할 수도 있다는 생각이 드네요🤔
+
+**학생 자가 학습 (현실 메타포 vs 확장성 의문, Dealer.kt):**
+> Dealer에 대한 책임이 너무 큰가 하는 의문이 저도 들었습니다! 하지만 딜러가 아니라면 어떤 객체가 이 일을 수행해야하는지에 대한 고민을 하다보니 심판 객체를 만드는 것 또는 어떤 결과 계산기를 만드는 것이 살짝 어색하다는? (너무 현실 세계에 투영해서 보고 있는 걸까요?) 하는 의문이 들었습니다!
+
+**학생 자가 학습 (지연 초기화 학습, Deck.kt:8):**
+> 리소스 사용을 최적화하고, 객체의 초기화 시점을 실제 사용 시점으로 늦춰 성능을 향상시키는 등 지연 초기화에 대한 이점을 찾아보게 되었습니다 😊
+
+## 얻은 교훈
+
+1. ***mutable 외부 변경 가능성 = 캡슐화 부재***. *val + 생성자 주입 정공*. *학생 자가 인식*. PR #58·#85·#108·#132·#133 와 같은 결.
+
+2. ***Kotlin `max() → maxOrNull()` 변경 = 명시 타입 권고***. *반환 타입 모호 시 코드 이해 ↓*. *명시적 타입 = 다른 개발자 친화*. PR #108 (Effective Kotlin Item 4/14) 와 같은 결.
+
+3. ***책임 분산 = 변경 파급 위험*** — *Dealer 룰이 GameParticipant + 본 객체 두 곳* = *조건 변경 시 양쪽 수정*. *단일 진입점*이 정공.
+
+4. ***현실 메타포 (Dealer 판단) vs 확장성 (참가자 vs 참가자)*** = *두루 명시*. *PR #74 (알송) 의 Referee 자가 토론* / *PR #148·#151·#49·#132 의 참가자 vs 참가자 일반화* 와 같은 결.
+
+5. ***`by lazy` Kotlin 지연 초기화 어휘*** — *리소스 최적화 + 사용 시점 초기화*. PR #85·#137 와 같은 결.
+
+6. ***추상클래스 + 생성자 = 자식 모두 동일 생성자 강제 + 다중 상속 X***. *interface = 다중 구현 + 생성자 X*. *말리빈/두루/페로로 공통 진단*. PR #74·#108·#133·#137 와 같은 결.
+
+7. ***검증 중복 (init + factory) = 코드 중복 + 변경 파급***. *한 곳 검증*. PR #58 와 같은 결.
+
+8. ***메시지 상수화 + `String.format` Kotlin 어휘 활용***.
+
+9. ***`toString` = 도메인 객체 자기 표현 (View 호환)***. PR #88·#137·#90·#146 와 같은 결.
+
+10. ***테스트 함수명 = 기능 명세 + given/when/result 주석 분리***. PR #41·#90·#133·#136·#137 와 같은 결.
+
+11. ***현실 메타포 자가 인식 ("너무 현실 세계에 투영해서 보고 있는 걸까요?") = 양방향 학습 모범***. *학생 자가 의문 + reviewer 미래 시나리오 제시*. PR #74·#137·#148·#151 와 같은 결.
+
+12. ***`isCanAddCard` Controller 책임 이전 = Tell-Don't-Ask 반대 트레이드오프***. *Player 책임 vs Controller 책임* 의 *경계 자가 학습*.