oh-my-oop 0.2.0

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

@@ -0,0 +1,122 @@
+# PR #37 — [코건] 2단계 블랙잭
+
+- **Reviewee:** [@DYGames](https://github.com/DYGames) (코건)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/37
+- **단계:** 2단계
+- **리뷰어:** [@galcyurio](https://github.com/galcyurio)
+- **라인 코멘트:** 9 스레드 — *학생 자가 답변 4 thread + PR 본문 자가 질문 2개 / `process()` Controller vs main 테스트 가능성 + 3개 인스턴스 변수 원칙 = 가이드 / 절대 X + Money 연산자 오버로딩 + Controller 테스트 도전 + Fake 구현체 + `onPrint()` 고차함수 출력 호출 체크*
+- **DYGames 양 단계 완성** (1단계 #14).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 질문 2개
+
+PR 본문:
+
+> *"현재 컨트롤러 로직을 최대한 간소화해보았는데, 여기서 더 불필요한 로직이 있는지 궁금합니다. 또한 **컨트롤러에 `process()`라는 함수가 있는데, 이를 `main()` 함수로 이동해야 할지, 컨트롤러에 두는게 맞는지 궁금합니다.**"*
+
+### 2. Controller 테스트 + Fake 구현체 칭찬 (Thread 5·7)
+
+reviewer Thread 5: *"Controller 테스트 :+1:"*
+
+reviewer Thread 7: *"Fake 구현체 :+1:"*
+
+## 못한 점 (설계 관점)
+
+### 1. `process()` Controller vs main = 테스트 가능성 (Thread 0) — 정점
+
+reviewer (학생 PR 본문 자가 질문 답):
+
+> *"지금처럼 Controller에 위치시키는게 더 올바른 위치로 보입니다. **Controller에 있으면 `process()` 함수도 테스트가 가능하지만 `main()` 함수에 위치시키는 순간 해당 코드들은 테스트가 힘들어지기 때문입니다.**"*
+
+→ **MCP 룰 `process-in-controller-vs-main-testability`** ⭐⭐⭐ **신규** — *진행 흐름 위치 = 테스트 가능성으로 판단*. PR #42 (`controller-presentation-logic-must-test`)·PR #48 (`controller-to-domain-test-enablement`) 결 합류 → ***Controller 테스트 가치 어휘 누적 7 PR*** ⭐⭐⭐ 정점 강화.
+
+### 2. 3개 인스턴스 변수 원칙 = 가이드 / 절대 X (Thread 6) — 정점
+
+학생 자가 의문 정점:
+
+> *"또 미션 요구 사항 중 `3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.`라는 사항이 있는데, `Player`클래스에서 `name`,`bet`,`cards` 이렇게 3개의 인스턴스 변수를 가지고 있는데 `bet`과 `cards`를 `BetInfo`새로운 클래스로 분리한다고 하면 `Player` 클래스는 단순히 `name`과 `BetInfo`라는 **두개의 상태를 가지고 있고 역할은 없는 클래스로 변한다고 생각**됩니다.*
+>
+> *혹시 해당 요구 사항을 지키기 위해 제가 다른 관점에서 생각해볼 점이 있는지 궁금합니다!"*
+
+reviewer:
+
+> *"지금 상황에서는 오히려 나누지 않는게 더 나아보입니다.*
+>
+> *해당 요구사항은 클래스를 잘게 나누도록 가이드하는 하나의 원칙일 뿐입니다. **원칙을 따르는 것은 좋지만 절대적으로 항상 올바른 원칙은 없기에 모든 경우에 적용시켜서는 안됩니다.**"*
+
+→ **MCP 룰 `principle-as-guide-not-absolute`** ⭐⭐⭐ **신규 정점** — *3 인스턴스 변수 원칙 = 가이드 / 절대 적용 X*. PR #38 (`primitive-fn-conversion-as-temporary-fix` 임시 방편 vs 본질)·PR #62 (`mutable-team-policy-no-single-answer`)·PR #43 (`responsibility-of-judging-no-single-answer`) 결 합류 누적 **4 PR 원칙 vs 본질 단일 답 거부 정점**.
+
+→ **MCP 룰 `forced-class-division-without-role`** ⭐⭐⭐ 신규 — *역할 없는 클래스 분리 = 분리 X 권유*. PR #42 (`info-suffix-as-misplaced-data` PlayerInfo) 결 합류 누적 2 PR.
+
+→ **MCP `oh-my-oop` 핵심 가치 학생 측 메타 어휘** — *원칙 준수 vs 역할 명시 학생 자가 의문* = 도구 핵심 가치 (책임-역할-협력) 학생 측 자각.
+
+### 3. Controller 테스트 도전 (Thread 1)
+
+reviewer:
+
+> *"BlackjackController에 대한 테스트 코드를 작성해보는 것에 도전해보시면 좋겠습니다. 현재는 View를 직접적으로 의존하고 있어서 테스트하기 힘든 코드입니다. **어떻게하면 Controller에 대한 테스트 코드도 작성할 수 있을지 고민해보세요.**"*
+
+→ **Controller 테스트 = 7 PR 누적** = PR #37·#42·#48·#47·#72·#43·#54 — Controller 어휘 최정점.
+
+### 4. Money 연산자 오버로딩 (Thread 2)
+
+reviewer: *"값을 꺼내서 쓰는 대신 `bet * 2`와 같이 코드를 작성할 수 있도록 만들어보세요."*
+
+학생 자가 답변: *"`Money` 클래스에서 `times()` 연산자를 오버로딩 해 구현하였습니다."*
+
+→ **MCP 룰 `operator-overload-times-domain`** ⭐⭐ 신규 — *연산자 오버로딩 = 도메인 어휘*. PR #47 (`operator fun` 칭찬) 결 합류 누적 2 PR.
+
+### 5. 한 줄 너무 많은 처리 → 변수/함수 분리 (Thread 3·4)
+
+reviewer Thread 3:
+
+> *"한 줄에서 너무 많은 것을 처리하고 있습니다. `playerCardNumberSum in (dealerCardNumberSum + 1)..GameRule.WINNING_NUMBER`이 무엇인지 (...) **변수로 선언하고 해당 변수의 이름을 통해 역할을 드러내주세요.**"*
+
+reviewer Thread 4:
+
+> *"한 줄에서 너무 많은 일을 하고 있습니다. 함수로 분리하거나 지역 변수로 분리해보세요. **불필요한 `let()` 사용입니다. 오히려 변수를 선언하는 것이 가독성에 더 도움이 됩니다.**"*
+
+학생 자가 답변: *"적절한 변수명으로 조건들을 분리해주었습니다." / "함수로 분리하였습니다."*
+
+→ **MCP 룰 `unnecessary-let-as-readability-loss`** ⭐⭐ 신규 — *`let()` = 가독성 손실 / 변수 분리 권장*. PR #42 (`expression-body-too-long-as-local-var`) 결 합류 누적 2 PR.
+
+### 6. 출력 함수 호출 체크 — `onPrint()` 고차함수 (Thread 8)
+
+reviewer:
+
+> *"출력의 경우에는 반환값이 없기 때문에 함수가 호출되었는지를 체크해야 합니다. 이 경우에는 **생성자로 `onPrint()`, `onPrintln()`과 같은 고차함수를 받도록 처리**해주시면 좋습니다."*
+
+→ **MCP 룰 `output-fake-with-print-callback`** ⭐⭐⭐ 신규 — *Fake 출력 = 함수 호출 체크 + 고차함수 콜백 어휘*. PR #14 (`test-fake-self-test-anti-pattern`) 결 합류.
+
+## 대표 인용
+
+> [galcyurio Thread 0]
+> *"Controller에 있으면 `process()` 함수도 테스트가 가능하지만 `main()` 함수에 위치시키는 순간 해당 코드들은 테스트가 힘들어지기 때문입니다."*
+
+→ **`process()` 위치 = 테스트 가능성 어휘**.
+
+> [galcyurio Thread 6]
+> *"원칙을 따르는 것은 좋지만 절대적으로 항상 올바른 원칙은 없기에 모든 경우에 적용시켜서는 안됩니다."*
+
+→ **원칙 = 가이드 / 절대 X 어휘 정점**.
+
+> [DYGames Thread 6]
+> *"`Player` 클래스는 단순히 `name`과 `BetInfo`라는 두개의 상태를 가지고 있고 역할은 없는 클래스로 변한다고 생각됩니다."*
+
+→ **학생 자가 역할 없는 클래스 분리 시그널 자각 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **`process()` Controller vs main = 테스트 가능성** — **MCP 룰 `process-in-controller-vs-main-testability` 후보** ⭐⭐⭐. Controller 어휘 누적 7 PR 정점.
+2. **원칙 = 가이드 / 절대 X (3개 인스턴스 변수 원칙)** — **MCP 룰 `principle-as-guide-not-absolute` 후보** ⭐⭐⭐ 정점. 단일 답 거부 누적 4 PR.
+3. **역할 없는 클래스 분리 X (BetInfo 분리 거부)** — **MCP 룰 `forced-class-division-without-role` 후보** ⭐⭐⭐. PR #42 결 누적 2 PR.
+4. **Money 연산자 오버로딩 도메인** — **MCP 룰 `operator-overload-times-domain` 후보** ⭐⭐.
+5. **출력 Fake = `onPrint()` 고차함수** — **MCP 룰 `output-fake-with-print-callback` 후보** ⭐⭐⭐.
+6. **불필요한 `let()` = 가독성 손실** — **MCP 룰 `unnecessary-let-as-readability-loss` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **DYGames 양 단계 완성** — galcyurio reviewer (PR #30·#42 ippnsj 결).
+- **Controller 어휘 누적 7 PR 정점** (PR #37·#42·#48·#47·#72·#43·#54) — Controller 책임 + 테스트 + 분류 어휘 최정점.
+- **원칙 vs 본질 단일 답 거부 누적 4 PR** (PR #38·#62·#43·#37) — MCP 핵심 가치 어휘 정점.

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

@@ -0,0 +1,117 @@
+# PR #12 — [해시] 1단계 블랙잭
+
+- **Reviewee:** [@EmilyCh0](https://github.com/EmilyCh0)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/12
+- **단계:** 1단계
+- **리뷰어:** [@BeokBeok](https://github.com/BeokBeok) (벅벅) — 2023 코호트 reviewer
+- **라인 코멘트:** 10 스레드 — *단방향 리뷰 (학생 자가 답변 X) / `init` 함수명 의미 + Mutable 노출 + 언더바 backing property 컨벤션 + Ace 책임 위치 + 원시값 포장 + 함수명 의도 일치 + 테스트 함수명 구체성*
+- **신규 reviewee** (2023 코호트). PR #15 (sujin9 1단계, BeokBeok)와 동일 가이드 결.
+
+## 잘한 점 (설계 관점)
+
+- Card 클래스 내 Shape/Value 잘 구현 (Thread 2 — 다만 파일 분리 권유).
+- A 판단 테스트 코드 작성 (Thread 9 — 다만 함수명 구체성 보완).
+
+## 못한 점 (설계 관점)
+
+### 1. `init` 함수명 의미 (Thread 0)
+
+```kotlin
+fun init(...)  // 별도 리턴값이 있는 함수
+```
+
+reviewer:
+
+> *"init이라는 함수는 대체로 \"값을 초기화한다\" 라는 의미를 가집니다. 다만 초기화는 아래와 같이 별도의 리턴값이 있을 것이라 예상되지 않습니다. `val a = 1`. 구현부의 의도를 잘 알 수 있도록 함수명을 개선해보면 어떨까요?"*
+
+→ **`init` = 초기화 어휘 (리턴 X 예상)** = **MCP 룰 `init-name-implies-no-return` 후보** ⭐ 신규.
+
+### 2. 상수값 집합 = enum (Thread 1)
+
+`Answer` 클래스를 enum으로 권유. 누적 다수.
+
+### 3. 하나의 파일 = 하나의 클래스 (Thread 2)
+
+reviewer: *"Card 클래스 내에 Shape와 Value를 잘 구현해주셨네요. 지금처럼 하셔도 좋지만, 가급적이면 하나의 파일에는 하나의 클래스를 관리하는 것이 좋습니다. 현재 구조에서는 Shape 혹은 Value 클래스가 변경이 되면 Card 클래스도 영향을 받기 쉬운 구조이기 때문입니다."*
+
+→ **단일 책임 파일 분리 + 변경 전파 영향 어휘** = 누적 다수.
+
+### 4. `List<List<Card>>` 포장 (Thread 3)
+
+reviewer: *"List<List<Card>>를 포장해보면 어떨까요?"*
+
+→ **이중 컬렉션 포장 (일급 컬렉션)** = 누적 다수.
+
+### 5. `MutableList` 외부 노출 (Thread 4)
+
+```kotlin
+// Dealer.kt
+class Dealer(name: String = DEALER_NAME, cards: MutableList<Card>) : Player(name, cards)
+```
+
+reviewer:
+
+> *"cards의 타입이 Mutable 타입이네요. 이렇게 되면 외부에서는 Mutable 타입이 노출되기 때문에, 클래스를 내부가 아닌 외부에서 값을 변경하기 쉬운 구조가 됩니다."*
+
+→ **Mutable 타입 외부 노출 = 캡슐화 위반** = 누적 다수.
+
+### 6. 언더바 `_` = backing property 컨벤션 (Thread 5)
+
+```kotlin
+class Player(name: String, _cards: MutableList<Card>)
+```
+
+reviewer:
+
+> *"프로퍼티에 언더바(_)를 붙이는 경우는, backing property 기법을 적용할 때 사용하는 컨벤션입니다. 또한, 언더바는 private를 의미하기도 하기 때문에, 외부에서 값을 생성해서 전달해주는 생성자와는 맞지 않습니다."*
+
+→ **언더바 = backing property 전용 컨벤션 (생성자 인자 X)** = **MCP 룰 `underscore-prefix-backing-property-only` 후보** ⭐ 신규. PR #18 (boogi-woogi) backing property 어휘 결 합류.
+
+### 7. 함수명 = 유효성 체크 시 Boolean 기대 (Thread 6)
+
+reviewer: *"함수명만 봤을 때에는 플레이어의 합의 유효성을 체크하는 것으로 보입니다. \"유효성을 체크한다\" 라고 하면, 흔히 Boolean 타입을 떠올리곤 합니다."*
+
+→ **`isXX` / `checkXX` = Boolean 기대 어휘** = **MCP 룰 `validate-fn-name-implies-boolean` 후보** ⭐⭐. 함수명 의도 일치 누적 15+ PR과 결 합류.
+
+### 8. ACE 책임 위치 (Thread 7)
+
+reviewer: *"ACE를 판단하는 로직을 Player가 갖도록 구현해주셨네요. ACE는 어떤 클래스에서 책임을 가지고 있는지 확인해보시고, 이 로직을 어디에 위치해야 적합한지 고민해보면 어떨까요?"*
+
+→ **Tell-Don't-Ask + Ace 책임 위치** = 누적 다수.
+
+### 9. Score Int 포장 (Thread 8)
+
+reviewer: *"Score의 타입이 Int이니, 이 값을 포장해보면 어떨까요?"*
+
+→ **원시값 포장** = 누적 다수.
+
+### 10. 테스트 함수명 구체성 (Thread 9)
+
+reviewer: *"하지만 함수명만 봐서는 한 장인 경우와 두 장인 경우, 그리고 세 장인 경우 어떤 것을 테스트를 하려고 하는지 알기가 어렵습니다. 가령, \"A가 한 장인 경우는 11점이다\" 와 같이 함수명을 좀 더 자세하게 작성해보면 어떨까요?"*
+
+→ **테스트 함수명 구체성 (입력→기대 명시)** = PR #15 (sujin9 1단계) 동일 가이드 + 누적 다수.
+
+## 대표 인용
+
+> [BeokBeok Thread 0]
+> *"init이라는 함수는 대체로 \"값을 초기화한다\" 라는 의미를 가집니다."*
+
+→ **`init` 함수명 의미 어휘**.
+
+> [BeokBeok Thread 5]
+> *"언더바(_)를 붙이는 경우는, backing property 기법을 적용할 때 사용하는 컨벤션입니다."*
+
+→ **언더바 = backing property 컨벤션 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **`init` 함수명 의미 (리턴 X 예상)** — **MCP 룰 `init-name-implies-no-return` 후보** ⭐ 신규.
+2. **언더바 `_` 접두사 = backing property 컨벤션** — **MCP 룰 `underscore-prefix-backing-property-only` 후보** ⭐ 신규.
+3. **`isXX` / `checkXX` 함수명 = Boolean 기대 어휘** — **MCP 룰 `validate-fn-name-implies-boolean` 후보** ⭐⭐.
+4. **Mutable 타입 외부 노출 = 캡슐화 위반** = 누적 다수.
+5. **테스트 함수명 입력→기대 구체성** = PR #15 결 합류.
+
+## 메타 노트
+
+- 학생 자가 답변 / 토론 X — *단방향 reviewer 가이드만* (PR #12 학생 첫 1단계 시작 시기).
+- 2025-05-24 시점에서 PR #15 sujin9 1단계 (BeokBeok 동일 reviewer, 같은 시기) 가이드 결과 *3가지 신규 패턴* (`init` / 언더바 / `isXX` Boolean) 명확화 — *동일 reviewer 가이드가 다른 학생에게 반복되며 신규 안티패턴 어휘를 정착시키는 사례*.

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

@@ -0,0 +1,291 @@
+# PR #38 — [해시] 2단계 블랙잭
+
+- **Reviewee:** [@EmilyCh0](https://github.com/EmilyCh0)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/38
+- **단계:** 2단계
+- **리뷰어:** [@BeokBeok](https://github.com/BeokBeok) (벅벅) — 2023 코호트 reviewer
+- **라인 코멘트:** 18 스레드 — *학생 자가 의문 + 답변 풍부 (9 thread 학생 자가 응답) / runCatching 예측 가능/불가 오류 + 입력 검증 재귀 호출 위험 + 멤버 변수 상태 의존 함수 결과 + Tell-Don't-Ask 메시지 어휘 \"내 X 넘겨줄테니 Y 알려줘\" + 디미터 점(.) 2개 이하 + `lateinit` 초기화 미인지 위험 + Pair vs data class 의미 명확성*
+- **양 단계 완성** (1단계 #12, BeokBeok). EmilyCh0 양 단계 완성.
+- **PR 본문 자가 학습 명시**: *"1단계 미션에서 받은 피드백 반영하고, 컨트롤러에 있던 로직을 도메인으로 분리하려고 새로운 방식을 시도해봤습니다."*
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 학습 시도 명시
+
+PR 본문에 *"컨트롤러에 있던 로직을 도메인으로 분리하려고 새로운 방식을 시도"* 라는 1단계 → 2단계 자가 학습 명시.
+
+→ **PR 본문 자가 학습 진화 명시** = PR #15·#35·#126 결 합류.
+
+### 2. 학생 자가 답변 9 thread (학습 가시화)
+
+18 thread 중 **9 thread 학생 자가 답변** + 코드 수정 보고 — *학습 가시화 최상위 모범*. PR #144 (m6z1)·PR #149 (cucumber99) 결.
+
+### 3. 추가 칭찬
+
+- Thread 0: runCatching 반복 구조 활용 (다만 본질 = 예외 처리 위치 고민).
+- Thread 9: 수익률 테스트 코드 칭찬.
+
+## 못한 점 (설계 관점)
+
+### 1. runCatching 예측 가능 vs 불가 오류 (Thread 0) — 학생 자가 깊은 의문 정점
+
+reviewer:
+
+> *"runCatching 내부는 try-catch로 이루어져있습니다. 코틀린에서는 오류는 아래와 같이 처리하고 있습니다. - 오류가 예상되는 경우 - 오류가 예상되지 않는 경우. 위의 경우에는 어떤 오류인지 고민해보시고, 나아가 어떻게 개선하면 좋을지 고민해보면 어떨까요?"*
+
+학생 자가 답변 (의문 정점):
+
+> *"코틀린에서 예측되는 범위의 오류는 null 또는 sealed class의 Failure를 리턴하여 처리하고, 예측되지 않는 범위의 오류는 예외를 throw 해서 처리합니다. **그런데 예측할 수 있는 오류와 예측하기 어려운 오류의 차이를 잘 모르겠습니다.**🥲 현재 코드에서는 UserNameContainer 생성 시 require를 통해 이름 중복과 빈 이름을 검증하고 있는데, 예외를 던지는 require가 아니라 null 또는 Failure로 처리하는 것이 좋을까요?*
+>
+> *예외 처리 방식도 궁금하지만, 예외 처리를 어디에서 하는 것이 좋을지도 궁금합니다. 지금까지는 \"문자열 Int로 파싱\", \"빈 입력\" 정도는 사용자 입력 오류라고 생각해서 InputView에서 toIntOrNull() 등을 사용하여 처리하고 나머지 논리적 오류는 도메인에서 예외를 throw하고 컨트롤러에서 runCatching하는 방식을 사용했는데, 이번 미션을 진행하면서 점점 뷰에서 검증하는 비중이 높아지는 것 같습니다. **뷰에서 아예 검증을 완료한 도메인 객체를 리턴하는 방식까지 생각해봤는데** 이러한 방식에는 문제가 없을지 궁금합니다."*
+
+reviewer:
+
+> *"너무 어렵게 생각하시는 것이 아닌가 싶습니다. 😅 값을 입력받을 때 아래와 같은 함수를 사용하고 계십니다. `readln().toIntOrNull()`. 즉, Int 타입으로 변환하되, 변환이 되지 않으면 null을 반환한다고 쉽게 이해할 수 있습니다. (...) 반대로 예외를 예측하기 어려운 대표적인 오류는, 0으로 나누는 경우입니다. (...) ArithmeticException이 발생하게 됩니다.*
+>
+> *또한, 함수 내에서 재귀호출을 하는 방식은 굉장히 위험합니다. 예상하지 못한 오류가 발생했을 경우, 영문도 모른채 프로그램이 영원히 종료되지 않을 가능성이 높습니다.*
+>
+> *예외처리를 어디에서 하는지에 대한 여부는 개발자마다 의견이 다르기에 정답이 없습니다. 말씀하신대로 뷰에서 도메인 객체를 리턴하는 방식도 문제가 없습니다. 😅"*
+
+→ **`predictable-vs-unpredictable-error-distinction`** = **MCP 룰 후보** ⭐⭐⭐:
+- 예측 가능 (`toIntOrNull` = 변환 안되면 null) → 다른 방식으로 처리.
+- 예측 불가 (`0`으로 나누기 → ArithmeticException) → throw.
+
+→ **`view-as-domain-validator-pattern`** = *뷰에서 검증 완료한 도메인 객체 리턴* 패턴 — 학생 자가 의문 + reviewer 인정 *"정답 없다"*. ⭐⭐ 신규.
+
+→ **`exception-handling-location-no-right-answer`** = *"개발자마다 의견 다르기에 정답이 없습니다"* — **MCP `oh-my-oop` 핵심 가치 어휘 정점** ⭐⭐⭐ (단일 답 거부).
+
+### 2. 입력 검증 재귀 호출 위험 (Thread 17)
+
+```kotlin
+// LoginView.kt
+fun getBetAmount(): Int {
+    val input = readln().toIntOrNull() ?: return getBetAmount()
+    require(input > 0)
+    return input
+}
+```
+
+reviewer:
+
+> *"배팅 금액을 음수를 두 번 입력하게 되면, `return input`은 몇 번 호출될까요? 양수를 입력받기 위한 예외처리로 인해, 프로그램의 오류가 발생하게 됩니다. 이 부분이 재귀 호출을 신중하게 하지 않았기에, 예상하지 못한 오류가 발생하게 됩니다."*
+
+(스크린샷 첨부 — 실제 오류 재현)
+
+학생 자가 답변: *"리턴 처리해서 정상 작동하도록 수정했습니다 🥹"*
+
+→ **`recursive-input-validation-bug`** = **MCP 룰 후보** ⭐⭐⭐ 신규 — *입력 검증 재귀 호출 시 예외처리 빠지면 예측 못한 오류*.
+
+→ **reviewer 스크린샷 = 도메인 룰 증거**: PR #144 결 (m6z1 — reviewer 이미지 첨부) 합류 — *스크린샷 = 버그 재현 증거*. ⭐ 강화.
+
+### 3. 멤버 변수 상태 의존 함수 결과 (Thread 1)
+
+```kotlin
+class BlackJackGame {
+    private var deck: Deck = Deck.empty()
+    private var players: Players = Players.empty()
+
+    fun setUpBlackJackGame(...) { deck = ...; players = ... }
+    fun playDealerTurn() { /* deck, players 사용 */ }
+}
+```
+
+reviewer:
+
+> *"멤버 변수는 클래스 내부에서 데이터에 편하게 접근하고 변경할 수 있는 장점이 있지만, **멤버 변수의 상태에 따라서 함수의 호출 결괏값이 달라지는 단점이 있습니다.** setUpBlackJackGame 함수를 호출하지 않고, playDealerTurn 함수를 호출하게 되면 어떻게 될까요?"*
+
+학생 자가 답변:
+
+> *"deck과 players를 갖는 BlackJackGameData를 추가했습니다. setUpBlackJackGame을 통해 BlackJackGameData를 생성할 수 있고, BlackJackGame 내의 나머지 함수가 BlackJackGameData를 인자로 받아 setUpBlackJackGame 이전에 호출할 수 없도록 했습니다."*
+
+→ **`mutable-member-var-state-dependent-result`** = **MCP 룰 후보** ⭐⭐⭐ 신규 — *멤버 변수 상태에 따라 함수 결과 달라짐 = 호출 순서 의존*.
+
+→ **`function-call-order-dependency-violation`** = **MCP 룰 후보** ⭐⭐⭐ — *호출 순서가 강요되는 API = 잘못된 설계*. 학생 자가 답변 = *데이터 객체 인자 + 컴파일러 강제* 해결.
+
+→ **타입으로 호출 순서 강제** 어휘 (BlackJackGameData 인자 = setUp 이전 호출 못함) — *type-safety로 invariant 강제* ⭐⭐.
+
+### 4. Pair vs data class 의미 명확성 (Thread 2)
+
+reviewer:
+
+> *"Pair를 활용해주셨네요. 👍 Pair는 두 개의 타입을 간편하게 정의하고 사용할 수 있는 장점이 있지만, **first가 무엇인지 second가 무엇인지 알기 어렵다는 단점이 있습니다.** Pair 대신 data class를 활용해보면 어떨까요?"*
+
+학생 자가 답변: *"data class로 변경했습니다!"*
+
+→ **`pair-vs-data-class-naming-clarity`** = **MCP 룰 후보** ⭐⭐ 신규 — *Pair = first/second 의미 잃음*. PR #137·#107 (`typealias vs class`) 결 합류 — *익명 타입 어휘 손실*.
+
+### 5. BlackJackGame god-object (Thread 3) — 디미터 법칙
+
+reviewer:
+
+> *"BlackJackGame는 Score, Players, Dealer, Cards 등 다른 객체들을 너무 잘 알고 있는 것은 아닌지 고민해보시면 좋을 것 같아요. 각 객체에 메시지를 보내도록 코드를 개선해보면 어떨까요? **대체로 점(.)을 통해서 두세번 접근을 하게 되면, 객체를 능동적으로 관리하고 있는지 고민**해보시면 좋을 것 같아요."*
+
+학생 자가 답변: *"`val dealerScore get() = dealer.cards.score` 와 같은 변수, 함수를 추가하여 BlackJackGame에서 직접 접근하지 않도록 했습니다."*
+
+→ **god-object + 디미터 점(.) 2-3개 시그널** = 누적 다수.
+
+### 6. Cards → Score 리턴 타입 일치 (Thread 4)
+
+reviewer: *"리턴 타입이 Int인데, 이미 구현하신 Score 객체를 활용해보면 어떨까요?"*
+
+→ **`primitive-return-on-wrapped-value`** = 누적 다수.
+
+### 7. enum exhaustive when (Thread 7)
+
+누적.
+
+### 8. Score 책임 — 상태 + 계산 로직 (Thread 8)
+
+reviewer: *"점수를 관리하는 Score 클래스를 잘 구현해주셨네요. 👍 **상태 외에도 점수를 계산하는 로직도 Score 클래스에서 책임을 갖도록** 개선해보면 어떨까요?"*
+
+학생 자가 답변: *"Cards에 있던 점수 계산 로직을 Score로 옮겼습니다!"*
+
+→ **`value-holder-vs-value-calculator-conflation`** = *값을 가진 객체가 값 계산 책임도 가짐* = 누적 다수.
+
+### 9. 테스트 명명 도메인 어휘 (Thread 9)
+
+reviewer:
+
+> *"`점수가 21이면 블랙잭이다`. 21은 블랙잭을 상징하니, 버스트가 아니다라는 것보다는 블랙잭임을 나타내는 것이 더 좋을 것 같아요."*
+
+→ **테스트 명명 = 도메인 어휘 (Bust 아니다 ✗ / 블랙잭이다 ✓)** = 누적 다수.
+
+### 10. 개행 = 흐름 단위 (Thread 11)
+
+reviewer: *"프로그램의 흐름 단위로 개행을 해주시면, 좀 더 로직을 이해하는 데 수월합니다."*
+
+→ **`blank-line-as-flow-boundary`** = ⭐ (가독성 컨벤션).
+
+### 11. 3개 이상 인스턴스 변수 제약 — 임시 방편 vs 본질 (Thread 12)
+
+reviewer: *"3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다 — 위 요구사항을 반영해보면 어떨까요?"*
+
+학생 자가 답변: *"score와 numbers를 함수로 변경하여 해결할 수 있을 것 같습니다. **하지만 이게 적절한 해결 방법인지, 이점이 무엇인지 잘 모르겠습니다.**"*
+
+reviewer:
+
+> *"score와 numbers를 단순히 함수로 바꾸는 것은, **임시 방편일 뿐 해결방법은 아닙니다.** score와 numbers는 isBlackJackScore 함수를 호출하기 위해 필요합니다. 그렇다면, score와 numbers를 멤버 변수로 가지고 있어야 할까요? 멤버 변수로 가지지 않아도 isBlackJackScore 함수를 호출할 수 있도록 개선할 수 있지 않을까요?"*
+
+→ **`primitive-fn-conversion-as-temporary-fix`** = **MCP 룰 후보** ⭐⭐⭐ 신규 — *멤버 변수 제약 위반 시 *함수로 변경* = 임시 방편. 본질 = 멤버 변수 필요성 고민*.
+
+→ ***임시 방편 vs 본질 해결* 어휘** ⭐⭐ — reviewer 코드 변경 *형태*가 아닌 *왜 멤버 변수인가* 고민 유도.
+
+### 12. Tell-Don't-Ask 메시지 어휘 — *"내 X 넘겨줄테니 Y 알려줘"* (Thread 13)
+
+reviewer:
+
+> *"isBlackJackScore 함수는 블랙잭 스코어 여부에 대해서 판단해주는 함수로 보입니다. 그렇다면, Score 에 메시지를 보내도록 코드를 개선해보면 어떨까요? **\"내 카드들의 정보를 넘겨줄테니 블랙잭인지 아닌지 알려줘\"**"*
+
+학생 자가 답변:
+
+```kotlin
+fun isBlackJack(numbers: List<Int>, hasAce: Boolean): Boolean =
+    (valueOfCards(numbers, hasAce).value == BLACKJACK_CONDITION)
+```
+
+→ **`tell-dont-ask-message-vocabulary`** = **MCP 룰 후보** ⭐⭐⭐ 신규 정점 — *"내 X를 넘겨줄테니 Y 알려줘"* 어휘. PR #15·#80 (`onXX` 콜백 어휘)·PR #133 (Player → Score 메시지) 결 합류.
+
+→ **메시지 어휘 명시화** = MCP `oh-my-oop` 핵심 가치 (책임-역할-협력) 정점.
+
+### 13. sumOf 활용 (Thread 15)
+
+reviewer: *"sumOf를 활용하면 좀 더 간결한 코드를 작성할 수 있어요."*
+
+→ Kotlin stdlib 어휘 = 누적.
+
+### 14. `lateinit` 초기화 위험 (Thread 16)
+
+```kotlin
+class User(val name: String, val cards: Cards, val bettingMoney: Double) {
+    var gameResult: GameResult = GameResult.UNKNOWN  // 또는 lateinit
+}
+```
+
+reviewer:
+
+> *"아래와 같은 코드를 작성하게 되면 어떤 일이 발생하게 될까요? `val user = User(\"커트\", Cards(listOf()), 0.0); user.gameResult.label`. 이 문제를 해결하기 위해 어떻게 개선하면 좋을까요?"*
+
+학생 자가 답변:
+
+> *"아래 코드처럼 초기화되지 않은 상태에서는 IllegalStateException이 발생하도록 할 수 있습니다. 하지만 이 경우 별도의 예외 처리를 해주지 않으면 IllegalStateException이 발생했을 때 프로그램이 종료됩니다.*
+>
+> *또는 gameResult를 nullable한 타입으로 바꾸고 초기값을 null로 하는 방법도 있습니다."*
+
+reviewer:
+
+> *"**지연초기화는 초기화가 안된 상태에서도 접근할 수 있다는 점을 반드시 알고 넘어가셨으면 좋겠습니다.** 초기화가 되지 않은 상태에서 접근하는 경우가 생각보다 많습니다. 😅 그리고, 일반초기화가 아닌 지연초기화를 쓰는 것이 적합한지에 대해서도 고민하시고 사용하시는 것을 권장합니다."*
+
+→ **`lateinit-initialization-checking-burden`** = **MCP 룰 후보** ⭐⭐⭐ 신규 — *`lateinit` 미초기화 접근 위험 + 적합성 자가 고민*. PR #100 (`mutable-state-open-violation`)·PR #18 (`enum-companion-init-order`) 결 합류 — *초기화 시점 어휘 누적 3 PR*.
+
+### 15. 디미터 법칙 — 점(.) 2개 이하 (Thread 17)
+
+reviewer (Thread 1 링크):
+
+> *"디미터 법칙에 대해서 학습해보시고 코드를 개선해보면 어떨까요?"*
+
+학생 자가 의문:
+
+> *"Player에 `getCards()`라는 함수를 만들었는데, **어느 정도까지 디미터 법칙을 준수해야 하는지** 궁금합니다. 아예 Players에 `getDealerCards()`도 만들어서 `player.dealer` 코드까지 없애는 것이 좋을까요?"*
+
+reviewer:
+
+> *"점(.)을 2개 이하로 유지하는 것을 권장합니다. 오직 인접한 친구에게만 소통한다라고 이해해주시면 될 것 같습니다. 말씀하신 `player.dealer`를 풀어보면, `player.getDealer()` 와 동일하다고 볼 수 있습니다. 가령, \"딜러의 카드들을 출력해줘\" 라고 메시지를 보낸다고 하면, **Dealer 클래스에 카드 리스트를 출력하는 함수를 구현해주시면 됩니다.**"*
+
+→ **`dot-2-or-fewer-rule`** = **MCP 룰 후보** ⭐⭐⭐ 신규 — *디미터 법칙 = 점(.) 2개 이하 + 인접한 친구만 + `a.b` = `a.getB()` 동일성*.
+
+→ **메시지 어휘 — Tell View (출력 책임 위치)**: *"딜러의 카드들을 출력해줘" = Dealer가 출력 메서드* — Thread 13 (Tell-Don't-Ask 메시지 어휘) 결 합류 정점.
+
+## 대표 인용
+
+> [BeokBeok Thread 0]
+> *"예외처리를 어디에서 하는지에 대한 여부는 개발자마다 의견이 다르기에 정답이 없습니다. 말씀하신대로 뷰에서 도메인 객체를 리턴하는 방식도 문제가 없습니다."*
+
+→ **단일 답 거부 + 학생 대안 존중** — MCP `oh-my-oop` 핵심 가치 어휘.
+
+> [EmilyCh0 Thread 0]
+> *"예측할 수 있는 오류와 예측하기 어려운 오류의 차이를 잘 모르겠습니다."*
+
+→ **학생 자가 깊은 의문 어휘**.
+
+> [BeokBeok Thread 1]
+> *"멤버 변수의 상태에 따라서 함수의 호출 결괏값이 달라지는 단점이 있습니다."*
+
+→ **멤버 변수 상태 의존 = 호출 순서 의존 어휘**.
+
+> [BeokBeok Thread 12]
+> *"단순히 함수로 바꾸는 것은, 임시 방편일 뿐 해결방법은 아닙니다."*
+
+→ **임시 방편 vs 본질 어휘**.
+
+> [BeokBeok Thread 13]
+> *"\"내 카드들의 정보를 넘겨줄테니 블랙잭인지 아닌지 알려줘\""*
+
+→ **Tell-Don't-Ask 메시지 어휘 정점**.
+
+> [EmilyCh0 Thread 17]
+> *"어느 정도까지 디미터 법칙을 준수해야 하는지 궁금합니다."*
+
+→ **학생 자가 *정도* 의문 어휘** = MCP `oh-my-oop` 학생 측 메타 어휘.
+
+> [BeokBeok Thread 17]
+> *"점(.)을 2개 이하로 유지하는 것을 권장합니다."*
+
+→ **디미터 점(.) 2개 이하 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **예측 가능 vs 불가 오류 구분** — **MCP 룰 `predictable-vs-unpredictable-error-distinction` 후보** ⭐⭐⭐.
+2. **입력 검증 재귀 호출 위험** — **MCP 룰 `recursive-input-validation-bug` 후보** ⭐⭐⭐.
+3. **멤버 변수 상태 의존 = 호출 순서 강요** — **MCP 룰 `mutable-member-var-state-dependent-result` + `function-call-order-dependency-violation` 후보** ⭐⭐⭐.
+4. **임시 방편 vs 본질 해결** — **MCP 룰 `primitive-fn-conversion-as-temporary-fix` 후보** ⭐⭐⭐.
+5. **Tell-Don't-Ask 메시지 어휘 *"내 X 넘겨줄테니 Y 알려줘"*** — **MCP 룰 `tell-dont-ask-message-vocabulary` 후보** ⭐⭐⭐ 정점.
+6. **디미터 점(.) 2개 이하** — **MCP 룰 `dot-2-or-fewer-rule` 후보** ⭐⭐⭐.
+7. **`lateinit` 초기화 미인지 위험** — **MCP 룰 `lateinit-initialization-checking-burden` 후보** ⭐⭐⭐.
+8. **Pair vs data class 의미 명확성** — **MCP 룰 `pair-vs-data-class-naming-clarity` 후보** ⭐⭐.
+9. **예외 처리 위치 정답 없음** — *MCP `oh-my-oop` 핵심 가치 어휘*.
+
+## 메타 노트
+
+- **EmilyCh0 양 단계 완성 (1단계 #12 → 2단계 #38)** — 1단계 단방향 가이드만 → 2단계 9 thread 학생 자가 답변 + PR 본문 자가 학습 진화 명시 → *학습 가시화 진화*. PR #144 (m6z1 *셀프 코드 리뷰*) 결.
+- **BeokBeok reviewer 다년 활동 강화** — 1단계 #12·#15 + 2단계 #38 + 누적 시기 코호트.
+- **메타 케이스 6번째 — 단방향 가이드 → 학생 자가 답변 진화 학습 시간성** (#12 단방향 0 → #38 자가 답변 9 thread): PR #71 → #96 (Hogu59 1년 늦은 2단계) 결과 *시간성 학습 모범* 다른 축.