oh-my-oop 0.2.0

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

@@ -0,0 +1,683 @@
+# PR #130 — [블랙잭 1단계] 메다 미션
+
+- **Reviewee:** [@medAndro](https://github.com/medAndro)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/130
+- **단계:** 1단계
+- **리뷰어:** [@hyemdooly](https://github.com/hyemdooly) (둘리) — **신규 reviewer — 14번째** + **메타 케이스: 2023년 3월 학생 (PR #21·#35) → 2025년 reviewer 진화** (krrong 결과 같은 *학생 → reviewer* 패턴 2번째 사례)
+- **라인 코멘트:** 25 스레드 — *PR 본문 자가 의문 3개 (TDD 학습 + 책임 분리 인사이트 + WinLossStatistics 자가 한계) + InputView 가 Player 생성 vs InputView 책임 한계 3-라운드 양방향 토론 + ArrayDeque vs MutableList vs Stack vs Queue 자료구조 자가 분석 (페어 학습) + 블랙잭 룰 정확성 자가 학습 (딜러 블랙잭 vs 플레이어 21점) + Deck object (싱글턴) 문제 학생 자가 인지 + outputView 함수 한번만 호출 학생/reviewer 양방향 자가 한계 인정 + Translator 과한 구현 + Card(cardIndex) 부생성자 의도 자가 토론*
+- **신규 reviewee** (2025년 코호트 — 모바일 안드로이드 7기, PR #117·#129·#138·#126·#130 = **2025 코호트 5 PR 코퍼스 형성**).
+- **메타 학습 케이스**: 학생 hyemdooly (PR #21·#35, 2023년 3월) = PR #130 의 reviewer 본인 → **2년 학생 → reviewer 진화** (krrong PR #32 → PR #148·#151 결과 같은 패턴).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 3개 + 학생 자가 한계 명시 (2025 코호트 정점)
+
+PR 본문:
+
+> *"이번에 미션을 진행하면서 페어와 함께 TDD로 구현하여 정상적으로 동작시키는것을 최우선 목표로 삼았고 아직은 미숙하지만 모든 과정에서 최대한 TDD로 구현하도록 노력했습니다 현재의 TDD로 구현하고 있는 방식이 둘리가 보시기에 어떻게 생각하는지 궁금합니다."*
+
+> *"현재로서는 각각의 객체들이 너무 많은 책임을 가지고 있고 패키지도 올바르게 분리하지 않았다고 생각합니다. 개선을 시키기 위한 인사이트를 던져주시면 감사하겠습니다!"*
+
+> *"가장 마지막에 구현한 `WinLossStatistics` 클래스의 로직들은 TDD로는 구현하였으나 상수를 하드코딩하고 if문이 난무하고 메서드의 라인수가 길어지는 문제, `GameParticipant`의 `abstract fun play()`의 미사용, 예외 처리의 부재 등 여러 시간부족 이슈등으로 발생한 문제들을 인지하고 있으며 차차 개선해 나가고자 합니다!"*
+
+→ **학생 자가 의문 3개 + 한계 4개 명시 + 페어 프로그래밍 어휘 + TDD 학습 의도 + 시간 부족 인정**:
+
+#### 1.1. *자가 한계 명시 4개*
+- *각 객체 너무 많은 책임 (god-object)*
+- *패키지 분리 안 됨*
+- *상수 하드코딩 + if 난무 + 메서드 라인 ↑*
+- *예외 처리 부재*
+
+→ **학생 자가 *코드 한계 자가 인지 정점*** = *MCP `oh-my-oop` *학습 = 시간 두고 반복* 어휘 정점*. PR #35 (hyemdooly 본인 자가 의문 3개) 결과 같은 어휘 = *학생 → reviewer 진화 후 학생 시기 어휘 일관*.
+
+**MCP 룰 `student-self-limitations-explicit` 후보** — *학생 자가 한계 명시 = 학습 적극성 지표*.
+
+### 2. 학생 → reviewer 진화 메타 케이스 (hyemdooly 2년 학생 → reviewer)
+
+- **2023년 3월**: hyemdooly = 학생 (PR #21 + PR #35 = 둘리 미션).
+- **2025년 3월**: hyemdooly = reviewer (PR #130 medAndro 미션).
+
+→ **2년 학생 → reviewer 진화** = **krrong (PR #32 → PR #148·#151) 결과 같은 *학생 → reviewer 진화 패턴 2번째 사례***. **MCP `oh-my-oop` *학습 = 시간 두고 반복* 어휘 정점**.
+
+#### 2.1. *학생 시기 hyemdooly 어휘 ↔ reviewer 시기 hyemdooly 어휘 일관성*
+
+| 시기 | 어휘 |
+|---|---|
+| 2023 학생 (PR #21·#35) | PR 본문 자가 의문 3개 / 자가 의견 명시 / 도메인↔View 자가 입장 |
+| 2025 reviewer (PR #130) | 학생 자가 의문 격려 / 양방향 토론 / 도메인↔View 자가 후퇴 |
+
+→ **학생 시기 자가 의문 어휘 → reviewer 시기 학생 자가 의문 격려 어휘** = *학습 시간성*. PR krrong 결과 같은 패턴.
+
+**MCP 룰 `student-to-reviewer-evolution-meta` 강화** 누적 2+ PR (krrong + hyemdooly).
+
+### 3. 모든 25 스레드 학생 자가 답변 + commit SHA + 자가 후속 의문 5+ 회 (2025 코호트 정점)
+
+- Thread 1: *InputView ↔ Player 생성 3-라운드 양방향 토론 + 외부글 (제리 테코톡 + 로또 PR 인용)*.
+- Thread 6: *자료구조 ArrayDeque vs MutableList vs Stack vs Queue 자가 분석 + 페어 학습 인용*.
+- Thread 11: *Deck object 의존성 문제 학생 자가 인지 + 대안 코드 제시*.
+- Thread 15: *outputView.lineSeparator vs 함수 호출 위치 양방향 토론*.
+- Thread 18: *outputView 함수 한번만 호출 학생 자가 한계 인정 + 학생 코드 제시 + reviewer 자가 한계 인정*.
+
+→ **PR #117·#129·#138·#126 결의 *학생 자가 학습 가시화 정점* 유지** + **2025 코호트 5 PR 합류**.
+
+### 4. ArrayDeque vs MutableList vs Stack vs Queue 자가 분석 (페어 학습)
+
+reviewer (Thread 6): *"여러 자료구조 중에 `ArrayDeque`를 사용하신 이유가 무엇인지 궁금합니다!"*
+
+학생 자가 답변:
+
+> *"카드를 한장씩 Pop해야 하는 상황에서 어떤 자료구조를 쓰면 좋을까 페어와 논의하다가 (페어의 제안 인용) 라는 페어의 제안으로 사용해보게 되었습니다.*
+>
+> *- ArrayDeque: 양쪽 끝에서 O(1) 시간 복잡도로 효율적인 추가/제거 작업 가능하며 메모리 효율적이지만, 제거 작업을 해도 내부 배열의 크기가 줄어들지 않음*
+> *- MutableList: 끝에서 요소 추가/제거시 효율적이지만, 중간이나 처음에서 제거하는 작업은 O(n) 시간 복잡도로 비효율적*
+> *- Stack: LIFO(Last-In-First-Out) 원칙을 따르며 한쪽 끝에서만 O(1) 시간 복잡도로 요소 추가/제거가 가능하지만 Java의 레거시 클래스로 성능 이슈 존재*
+> *- Queue: FIFO(First-In-First-Out) 원칙을 따르며 한쪽 끝에서 추가하고 반대쪽 끝에서 제거하는 구조로, 자바의 Queue자체는 인터페이스이며 LinkedList나 ArrayDeque로 구현 가능*
+>
+> *라는걸 공부하게 되었고 현재로서는 ArrayDeque를 유지할 생각입니다."*
+
+→ **자료구조 4 안 자가 분석 + 페어 학습 + 다른 PR 인용**:
+
+#### 4.1. *Kotlin 어휘 깊은 자가 학습*
+
+PR #21·#23·#26·#58 결의 *카드덱 자료구조 (LinkedList vs ArrayDeque vs MutableList 뒤에서 pop)* 어휘 합류. 
+
+#### 4.2. *페어 학습 + 외부 인용*
+
+페어와의 토론 인용 + 다른 PR (`pull/128#discussion_r1986069929`) 인용 = **다른 학생의 학습 자가 참조**.
+
+**MCP 룰 `peer-learning-cross-pr-reference` 후보** — *페어/다른 학생 학습 인용*.
+
+### 5. 블랙잭 룰 정확성 자가 학습 (딜러 블랙잭 vs 플레이어 21점)
+
+reviewer (Thread 9):
+
+> *"처음 2장의 카드가 에이스와 10(J·Q·K를 포함)으로 21점이 된 것을 '블랙잭'이라고 하며, 베팅액의 1.5배를 얻는다. 딜러가 블랙잭이라면 같은 블랙잭을 가진 플레이어를 제외한 모든 플레이어는 즉시 패배하며 베팅액을 잃는다. 딜러와 플레이어가 동시에 블랙잭인 경우에는 푸시(Push)라 하여 무승부가 된다. 푸시가 될 경우, 해당 플레이어는 자신이 베팅한 금액을 돌려받는다.*
+>
+> *딜러가 블랙잭인 경우에도 고려해주셔야 합니다! 딜러가 블랙잭(A + 10인 카드)이고 플레이어가 블랙잭이 아니지만 합이 21인 경우에도 딜러 승리입니다. 🥲"*
+
+학생: *"이런 룰을 몰랐습니다... 반영 해보겠습니다!"*
+
+→ **reviewer 가 *블랙잭 도메인 룰 인용 + 학생 자가 도메인 학습***:
+
+#### 5.1. *블랙잭 룰 정확성 = 도메인 깊이*
+
+- *블랙잭 (A + 10) 2장 = 즉시 21*.
+- *딜러 블랙잭 vs 플레이어 21 (3장 이상) = 딜러 승리*.
+- *딜러 vs 플레이어 동시 블랙잭 = 푸시 (DRAW)*.
+
+PR #20·#64·#110·#28·#125·#147·#36·#26·#138 결의 *블랙잭 1.5배 룰 정확성* 어휘 강화.
+
+**MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 15+ PR ⭐⭐⭐.
+
+### 6. Deck object (싱글턴) 문제 학생 자가 인지 + 대안 제시
+
+reviewer (Thread 11):
+
+> *"덱에서 카드를 뽑는다는 것을 코드를 들어가서 보지 않으면 알기 어려워 보여요! object인 Deck을 도메인 모델 여기저기서 사용한다면 어떤 어려움이 있을 수 있을까요?"*
+
+학생 자가 답변 + 대안 코드 제시:
+
+> *"의도치 않은 도메인에서 접근해서 덱이 보유한 카드를 소진시켜 버리는 문제가 발생하고 Deck이 여러 도메인과 결합되어 추후에 수정하기 까다로워질 같네요. 그리고 항상 Deck이 랜덤으로만 카드를 보관하고 있어서 테스트 하기 어려운것 같습니다.*
+>
+> *Deck이 Object가 아니라고 한다면 `Deck.giveCard()` 같은 코드는 애초에 불가능하고 컨트롤러에서 아래와 같이 덱 인스턴스에서 뽑아 직접 꽂아주며*
+> ```kt
+> player1.handCards.addCard(deck.giveCard())
+> ```
+> *GameParticipant 입장에서는 덱이 주든 딜러가주든 관심 없게끔 해야 할 것 같네요"*
+
+→ **Singleton Deck 안티패턴 자가 인지 4 가지**:
+1. *의도치 않은 접근 → 카드 소진 부작용*.
+2. *Deck ↔ 여러 도메인 결합 ↑*.
+3. *테스트 어려움 (항상 랜덤)*.
+4. *GameParticipant 가 카드 출처 모름 = Tell-Don't-Ask 정공*.
+
+**MCP 룰 `singleton-deck-via-companion` 강화** 누적 19+ PR ⭐⭐⭐.
+
+다만 *학생 답변 *현재로서는 ArrayDeque를 유지할 생각* (Thread 6)* — *Singleton 자가 인지 vs 시간 부족 정공 X 양가성*.
+
+### 7. 학생 ↔ reviewer 양방향 토론 + 외부글 + 외부 PR 인용 (InputView ↔ Player 생성)
+
+reviewer (Thread 1): *"`InputView`에서 `Player`를 생성해서 넘겨주지 않은 이유가 있으신가요?"*
+
+학생 자가 답변 (1라운드):
+
+> *"이전 미션에서 `InputView`의 역할은 사용자의 입력을 받아 입력값을 가능한 원형을 유지한 채 컨트롤러로 전송하는것으로 이해했습니다. `Player`를 생성하는건 단순히 데이터를 담아서 넘겨주는게 아닌가? 싶기도 했는데 뷰에서 도메인 객체를 만들 때 예외가 발생한다면 도메인의 예외처리를 inputView에서 하게 되어 도메인의 역할을 침범하게 될 것 같다고 생각했습니다."*
+
+reviewer (2라운드):
+
+> *"아하! InputView에서 도메인을 몰라야한다면, OutputView에서 동일하게 몰라야할 것 같은데 OutputView에서는 참조를 하고 있어서 리뷰 드렸어요. 그렇다고 해서 뷰를 위한 모델을 만드는 것은 지금 단계에서 과할 수도 있다고 생각하는데, 이 부분은 크루들과 같이 얘기해보면 좋을 것 같아요!"*
+
+학생 자가 답변 (3라운드 + 외부 자료):
+
+> *"처음엔 [3기 제리의 테코톡](https://youtu.be/ogaXW6KPc8I?t=236) 을 참고해서 View에서는 모델을 참조하거나 만들어도 되겠구나 라고 생각했었는데 [로또 리뷰 과정](https://github.com/woowacourse/kotlin-lotto/pull/127/files/00ec1f0f347e9f68fe406cf135068d75e602a6d1#r1965102144)에서 참조만 가능하고 생성은 불가능하게 하는게 좋겠다는 결론을 내려서 현재와 같아졌습니다. 다음 단계로 나아가면 DTO를 써야 할 것 같네요 현재단계에선 언급해주신대로 과한것 같구요...!"*
+
+→ **3 라운드 양방향 토론 + 외부글 (테코톡) + 외부 PR 인용 (로또 #127)**:
+
+#### 7.1. *외부 자료 다양성*
+
+- *3기 제리 테코톡* (선배 학생 자료).
+- *로또 PR #127* (현재 미션 직전 학생 PR).
+
+PR #87·#36·#21·#117·#129 결의 *외부글 + 자가 학습* 어휘 강화.
+
+#### 7.2. *학생 자가 *View → DTO* 진화 의식*
+
+학생 *"다음 단계로 나아가면 DTO를 써야 할 것 같네요"* = *현재 단계 적절성 + 미래 단계 확장 의식*.
+
+PR #21·#35 (hyemdooly 본인 학생 시기 `SuitModel/RankModel`) 결의 *미래 학습 어휘* 와 *시간 일치 (2년 후 medAndro 동일 의문)*.
+
+**MCP 룰 `view-model-future-learning-awareness` 후보**.
+
+### 8. `enum Number` Suit/CardNumber 상수화
+
+reviewer (Thread 3):
+
+> *"suit, cardNumber를 상수화한다면 어떨까요? 스페이드, 하트, 다이아몬드, 클로버 / ACE, J, Q, K,... 더 명시적으로 표현할 수 있고, 점수도 갖고 있게 할 수 있으니, 점수 계산할 때도 편할 것 같아요!"*
+
+학생 자가 적용 (수정 후 `enum Number` 자가 구현):
+
+```kotlin
+enum class Number(val value: List<Int>, val orderNumber: Int, val initial: String) {
+    ACE(listOf(1, 11), 1, "A"),
+    TWO(listOf(2), 2, "2"),
+    ...
+}
+```
+
+→ **enum 변환 정공** = PR #117·#20·#28·#125 결.
+
+**`Number` 클래스 명명 양가** — *Kotlin 표준 `kotlin.Number` 와 충돌 위험*. **MCP 룰 `class-name-vs-stdlib-collision` 후보**.
+
+### 9. `Rule` god-object 자가 인지 + class → object 변환
+
+reviewer (Thread 4):
+
+> *"class에 companion object만 있다면 class를 object로 만드는 것이 좋겠어요. 추가로, Rule이 하는 일을 각 객체에게 주어, 객체가 스스로 일을 하도록 하면 어떨까요?"*
+
+학생: *"object라는게 있다는걸 푸시하고 페어와 함께 서로 알게 되었습니다. (...) PR에서 언급했듯 각각의 객체, 특히 Rule이 너무 많은 일을 하는 것 같아서 책임을 분리하는 방향으로 리팩터링 해봐야 겠습니다!"*
+
+→ **Kotlin object 자가 학습** + **Rule god-object 자가 인지 (PR 본문에 명시 후 학생 자가 적용 권유)**.
+
+**MCP 룰 `class-with-only-companion-to-object` 후보**. PR #117 (stateless 클래스 인스턴스화 vs companion) 결 강화.
+
+### 10. 추가 칭찬
+
+- Thread 5: *"todo 주석 활용 👍"* — `// TODO` 주석 사용.
+- Thread 19: *"손에 쥐고 있는 카드들이 직접 일을 하고 있네요 👍"* (HandCards Tell-Don't-Ask).
+
+## 못한 점 (설계 관점)
+
+### 1. `inputView` `outputView` private 처리 — 1단계 학습 시간성 한계
+
+reviewer (Thread 2):
+
+> *"inputView, outputView는 외부에서 사용하지 않도록 private 처리를 하면 좋겠어요!"*
+
+학생: *"이전 로또 미션에서도 받은 리뷰라 반성중입니다..."*
+
+→ **학습 시간성 한계 자가 인정** — *이전 미션 리뷰 재발*. **MCP 룰 `repeated-feedback-across-missions` 후보** — *미션 간 학습 시간성 한계*.
+
+### 2. `show` 이름 의미 vs 실제 (카드 리턴)
+
+reviewer (Thread 7): *"`show`이지만 카드를 리턴하는 역할을 하고 있어요. 바꿔볼 수 있을까요?"*
+
+학생: *"확실히 잘못된 이름이네요 고민해서 바꿔보겠습니다"*
+
+→ **이름 의미 정확성** — PR #117 (createCardRank), PR #129 (이름 = 의미), PR #36 (decideAceValue) 결의 *이름 vs 실제 반환 의미 불일치*. **MCP 룰 `function-name-vs-return-semantic-mismatch` 강화** 누적 4+ PR.
+
+### 3. `WinLossStatistics` 도메인 vs View 책임
+
+reviewer (Thread 8):
+
+> *"아직 이쪽을 더 수정하겠다고 하셨지만 코멘트 조금 남겨봅니다! 출력을 위한 `String` 생성은 도메인이 아닌 뷰의 역할 아닐까요? 🤔"*
+
+학생: *"확실하게 뷰의 역할이 맞다고 생각합니다 (...) OutputView에서 처리 시켜 보겠습니다."*
+
+→ **String 생성 = View 책임** = PR #126 (Verdict 문자열 = View 책임) 결 합류. **MCP 룰 `string-formatting-view-responsibility` 후보**.
+
+### 4. `Deck = object (싱글턴)` 의 도메인 결합 문제 — §6 참조
+
+학생 자가 인지. **MCP 룰 `singleton-deck-via-companion` 강화** 누적 19+ PR.
+
+### 5. `drawCard` 위임 vs `handCards.addCard(deck.giveCard())` Tell-Don't-Ask
+
+reviewer (Thread 11 후속): *"handCards에 다이렉트로 꽂기보다, drawCard에 넘기는 형태면 더 객체가 일을 하는 형태가 될 것 같아요!"*
+
+→ **Tell-Don't-Ask 정공** — *handCards.addCard 외부 호출 vs player.drawCard(card) 메시지 던지기*. PR #87·#129·#138·#126 결 합류.
+
+### 6. DSL Study 코드 = test 에 옮김
+
+reviewer (Thread 12): *"DSL Study로 사용한 코드들은 test 코드에 같이 포함해도 되지 않을까요? test에만 사용하고 있으니까요!"*
+
+→ **production vs test 코드 분리** — *DSL 학습 코드 = production 의도 X*. PR #35 (hyemdooly *DSL 활용 시점*) 결의 *학생 → reviewer 진화 일관* (학생 시기 DSL 권유 → reviewer 시기 DSL 위치 권유).
+
+**MCP 룰 `production-vs-test-code-separation` 후보**.
+
+### 7. `Deck.giveCard()` 테스트 = 카드 생성 + 반환만? — 유효 테스트
+
+reviewer (Thread 13):
+
+> *"`giveCard`를 했는데 안에서 카드를 생성해서 주기만 한다면 어떨까요? 유효한 테스트 코드라고 할 수 있을까요?"*
+
+학생: *"`덱의 카드를 한장 줄 수 있다`라고 바꾸고 카드의 수량이 줄어드는지도 검사해야 할 것 같습니다"*
+
+→ **테스트 = 동작 명세 (단순 동작 + 부작용 검증)** = PR #87·#129 결의 *테스트 = 객체 설계 명세서* 어휘. **MCP 룰 `test-side-effect-verification` 후보**.
+
+### 8. `PlayerTest` 가 Deck object 사용 = 외부에서 카드 출처 확인 불가
+
+reviewer (Thread 14):
+
+> *"이 코드만 보더라도 덱에서 카드를 뽑는지 겉으로 봐서는 알 수 없어요. `drawCard` 함수에서 카드를 생성해서 추가하기만 해도, 이 테스트는 통과할거에요!"*
+
+학생 자가 답변:
+
+> *"이것도 덱이 Object라서 발생하는 문제 같습니다. 카드 인스턴스를 한장 전달받아 손패에 추가하면 애초에 이런 테스트가 안 생기겠네요"*
+
+→ **테스트 = 코드 의도 가시화 도구 + Singleton 의 테스트 문제 자가 인지**. PR #87·#129·#138 결의 *테스트 가능성 = 객체 설계 지표* 어휘.
+
+### 9. `outputView 함수 한번만 호출` — 학생 자가 한계 + reviewer 자가 한계 (4 라운드 양방향 토론)
+
+reviewer (Thread 18): *"이 OutputView 함수를 한번만 쓰도록 수정해볼 수 있을까요?"*
+
+학생 자가 한계 인정 + 코드 제시:
+
+> *"몇시간 고민해봤는데 답을 못찾겠습니다. 히트를 하면 한장을 드로우하고 카드 정보를 표시해야하고 히트를 한번 이상 하고 스테이 할 경우 카드 정보를 표시하지 말하야 하고 히트를 한번도 하지 않고 스테이 했을떄는 카드 정보를 표시해야 하는걸 다 지켜가면서 (...) 이런 코드는 짰는데 depth문제도 있고 딱봐도 정답은 아닌것 같네요... 힌트 부탁드립니다."*
+
+reviewer 자가 한계 인정:
+
+> *"아 제가 이 조건을 놓쳤군요 😢😢😢 저도 해봤는데 메다가 올려주신 코드가 최선이네요.. 이 리뷰는 넘겨주세요! 정말정말 미안해요!!🧎‍♀️"*
+
+학생: *"아니에요 고민하는 과정에서 저도 공부가 많이 되었어요 ☺️"*
+
+→ **4 라운드 양방향 토론 + 학생 자가 한계 + reviewer 자가 한계 인정 + 학생 격려**:
+
+#### 9.1. *reviewer 자가 후퇴 (강한 어휘)*
+
+PR #87·#129·#126 결의 *reviewer 자가 한계 인정* 어휘 정점. *"정말정말 미안해요!!"* = *강한 사과 어휘* = *학습 가시화 가치*.
+
+**MCP 룰 `reviewer-self-limitation-explicit-apology` 후보** — *reviewer 가 자가 한계 강한 어휘 인정*.
+
+#### 9.2. *학생이 reviewer 부담 최소화*
+
+학생 *"고민하는 과정에서 저도 공부가 많이 되었어요"* = *reviewer 부담 최소화 + 학습 가시화*.
+
+### 10. `Translator` 과한 구현 — Locale 변환
+
+reviewer (Thread 16): *"이렇게 Locale에 따라 변환하는건 요구사항이 아니었는데 꼭 필요할까요? 🤔"*
+
+학생:
+
+> *"`가령 2하트 라고 출력하는 것을 화면에 따라 ❤️2 이렇게 출력할지도 모릅니다.` 라는 다른 리뷰어의 리뷰를 우연히 보고 Suit enum을 Output에서 그대로 받아 처리해야 한다고 생각했고 더 나아가 현재는 한국어로만 출력하지만 다르게 출력하려면 어떻게 해야 할까 고민해 보다가 저렇게 구현해 보았습니다. 결론은 꼭 필요하지는 않지만 이미 구현해놓은걸 수정할 이유도 없어보입니다."*
+
+→ **YAGNI 위반 자가 인지 + 이미 구현된 코드 제거 비용** — *YAGNI (You Aren't Gonna Need It) 트레이드오프*. PR #146 결 어휘 합류.
+
+**MCP 룰 `yagni-violation-removal-cost` 후보** — *YAGNI 위반 자가 인지 vs 제거 비용*.
+
+### 11. 초기 카드 장수 = 도메인 vs 컨트롤러
+
+reviewer (Thread 17): *"초기 카드 장수를 컨트롤러가 들고 있는 이유는 무엇일까요?"*
+
+학생:
+
+> *"플레이어의 카드를 초기화하는 등의 게임 진행 역할은 컨트롤러가 맡아야 하고 그때 필요한 상수라서 들고 있게 했던 것 같습니다. 초기 카드가 2장이라는 것은 게임의 본질적인 규칙이라 도메인이 가지는게 맞을 것 같고 HandCards에게 줄 것 같습니다."*
+
+→ **도메인 룰 = 도메인 상수 위치** = *INIT_CARD_SIZE = 도메인*. PR #129·#138 결.
+
+**MCP 룰 `domain-constant-locator` 후보** — *도메인 룰 상수 위치 = 도메인*.
+
+### 12. `backing property` 학습 권유
+
+reviewer (Thread 20): *"backing property에 대해 배우셨다면 활용해보세요!"*
+
+→ **Kotlin 어휘 자가 학습 권유** = PR #117 결.
+
+### 13. 테스트 fixture 초기값 세팅 - vararg 부생성자 자가 학습
+
+reviewer (Thread 21): *"초기값을 세팅하기 위해 일일히 add하고 있군요! 더 간단하게 세팅할 방법이 없을까요?"*
+
+학생:
+
+```kt
+class HandCards(
+    private val cards: MutableList<Card> = mutableListOf(),
+)
+```
+*로 HandCards를 수정하면 간단해 질 것 같아요...!"*
+
+→ **테스트 fixture 부생성자 자가 학습** = PR #126 (test-fixture-secondary-constructor) 결 합류.
+
+### 14. `CardStatus` 자가 계산 vs `HandCards` 자가 계산
+
+reviewer (Thread 22): *"손에 쥔 카드들이 직접 자신의 상태를 계산한다면 어떨까요?"*
+
+학생:
+
+> *"`CardStatus`가 직접 카드를 보고 `CardStatus`를 알려주는게 직관적인거 같고 이곳 저곳에서 불러다가 사용할 것 같아서 추가했었습니다. `calculateCardsStatus()`는 `HandCards` 클래스 에서만 사용하고 있고 앞으로도 그럴 것 같아서 옮겨볼게요!"*
+
+→ **상태 계산 책임 위치** — *enum companion 정적 vs HandCards 자가 계산*. **MCP 룰 `state-calculation-locator` 후보**. PR #117 (stateless 클래스 vs companion) 결.
+
+### 15. `orderNumber` 멤버 — enum 제공 기능 (ordinal) 활용
+
+reviewer (Thread 23):
+
+> *"`orderNumber`을 선언해주신 이유가 있으실까요? 순서때문이라면 `enum class`가 제공해주는 것들을 사용해서 다른 방법이 있을 것 같아요!"*
+
+학생: *getByOrderNumber 메서드 수정 + orderNumber 삭제 자가 적용*.
+
+→ **enum.ordinal 활용** — *Kotlin enum 자가 학습*. **MCP 룰 `enum-ordinal-vs-custom-property` 후보**.
+
+### 16. `Card(cardIndex: Int)` 부생성자 — 카드 섞기 의도 vs 도메인 위반
+
+reviewer (Thread 24): *"Card를 생성할 때, cardIndex를 받아서 이렇게 계산해야만 할까요? 🤔 사실 카드 몇 번째가 어떤 문양과 번호인지는 관심사가 아닌 것 같은데.. 복잡한 것 같아요…"*
+
+학생 자가 답변:
+
+> *"Deck에서 (...) 와 같이 섞여있는 카드를 쉽게 만들 수 있게 하기 위해서 고안된 부 생성자입니다. 전체 카드 인스턴스를 순서대로 일단 생성하고 섞는 방법도 생각해 보았는데 카드번호와 문양 조합 전부를 한장씩 가진 카드 컬렉션을 이중 for문을 사용하거나 flatMap을 사용해하여 생성한 뒤 섞는 방법만 생각나서 오히려 더 복잡해질 것 같아 이렇게 처리했습니다. 더 쉬운 방법이 떠오르진 않네요..."*
+
+→ **인덱스 기반 Card 생성 = 도메인 의미 누수** — *Card 의 도메인 의미 = (number, suit) / cardIndex = Deck 내부 위치*. **MCP 룰 `card-index-vs-card-identity` 후보**.
+
+#### 16.1. *대안 3 가지*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| `Card(cardIndex)` (현재) | *Deck.shuffled().map { Card(it) } 간결* | *Card 가 cardIndex 알아야 함 = 도메인 누수* |
+| `Card(number, suit)` + Deck flatMap | *Card 가 도메인 의미만* | *Deck 이 이중 for/flatMap 복잡* |
+| `Card.entries` (sealed/enum) | *모든 카드 자가 정의* | *52 케이스 enum* |
+
+### 17. `Deck` 안에서 카드 생성 자연스러운가?
+
+reviewer (Thread 25): *"Deck 안에서 카드를 생성하는 것이 자연스러운 걸까요? 🤔"*
+
+학생 자가 답변:
+
+> *"블랙잭 모듈 내에서 싱글턴으로 랜덤한 카드를 들고 있어야 하는 환경에서는 자연스러운 것 같은데 외부에서 카드 컬렉션을 받아서 초기화 되는 덱이라면 이상한 것 같네요..."*
+
+→ **Singleton 의도 vs DI 의도 트레이드오프**:
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Deck object + 자가 생성 (현재) | *Singleton + 카드 자동 생성* | *DI 불가 + 테스트 어려움* |
+| `class Deck(cards: List<Card>)` + 외부 주입 | *DI 정공 + 테스트 가능* | *생성자가 cards 받음* |
+| `class Deck` + companion factory `from(cards)` | *factory 패턴 + 명시적 생성* | *companion ↑* |
+
+PR #138 (학생 자가 interface Deck 분리) 결의 *Deck 테스트 가능성* 어휘 합류.
+
+### 18. `outputView.lineSeparator` Controller → OutputView 책임
+
+reviewer (Thread 15): *"이런 함수는 다음에 나올 outputView 함수에 껴넣을 수 있을 것 같다는 생각이 들어요. 🤔 콘솔이 아닌 다른 뷰로 플랫폼이 바뀐다면?! 이라는 생각이 드네요!"*
+
+학생 자가 답변:
+
+> *"`outputView.lineSeparator()` 한정으로는 OutputView 책임인데 컨트롤러로 잘못 들어간게 맞다고 생각합니다. (다른 코드 선택 의문)"*
+
+→ **lineSeparator = OutputView 책임 자가 인지** + **학생 코드 선택 의문 (드래그 오류)** = *양방향 토론 명료성 어휘*.
+
+reviewer 자가 후속 (드래그 오류 인정): *"오우 제가 드래그를 잘못했군요?!"* — **reviewer 자가 한계 인정 어휘** (Thread 15·18 합쳐 2 자리 이상).
+
+### 19. 학생 코드 한계 자가 인지 vs reviewer 자가 한계 인정 = 양방향 학습 시간성
+
+§9 §15 참조. **MCP `oh-my-oop` *학습 = 시간 두고 반복* 어휘 정점**.
+
+### 20. `Player.isDrawFinish() = handCards.getStatus() == CardStatus.BUST` — 21 시 hit 가능
+
+```kotlin
+override fun isDrawFinish(): Boolean = handCards.getStatus() == CardStatus.BUST
+```
+
+→ **Player BUST 시점 hit 종료** = *PR #129·#138·#139·#126 결과 동일 (21 시 hit 가능)*. *PR #35 (hyemdooly *21 시 stop*) 반대 시점*.
+
+다만 *hyemdooly = reviewer 본인 (학생 시기 21 시 stop 적용)* → *reviewer 가 학생 코드 *21 시 hit 가능* 명시 X* = *학생 자가 자율*.
+
+**MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 15+ PR ⭐⭐⭐.
+
+### 21. `Dealer.isDrawFinish() = bestCardValue <= DEALER_DRAW_LIMIT` 명명 양가
+
+```kotlin
+override fun isDrawFinish(): Boolean {
+    val bestCardValue = handCards.calculateBestCardValue()
+    return bestCardValue <= DEALER_DRAW_LIMIT
+}
+
+companion object {
+    private const val DEALER_DRAW_LIMIT = 16
+}
+```
+
+→ **`isDrawFinish` 명명 양가** — *DrawFinish (그리기 종료) vs isDrawable (그릴 수 있음)*. 
+
+학생 코드의 *`isDrawFinish() return bestCardValue <= 16`* = *16 이하 시 종료* = **블랙잭 룰 와전**:
+- 블랙잭 표준 = *Dealer 16 이하 = hit (계속) / 17 이상 = stop (종료)*.
+- 학생 코드 = *16 이하 → finish = true (종료)* = **반대 시점**.
+
+대안: *`isDrawFinish() return bestCardValue > 16`* (17 이상 시 finish).
+
+**MCP 룰 `boolean-method-semantic-inversion` 후보** — *Boolean 메서드 의미 반전 = 호출자 혼동*. PR #117·#139 (turn 반환 의미 역방향) 결 합류.
+
+### 22. `CardStatus.calculateCardsStatus(cards: Collection<Card>)` — 외부에서 cards 받아 계산
+
+```kotlin
+enum class CardStatus {
+    BLACKJACK, BUST, NORMAL;
+
+    companion object {
+        const val BLACKJACK_NUMBER = 21
+
+        fun calculateCardsStatus(cards: Collection<Card>): CardStatus = when {
+            cards.size == INIT_CARD_SIZE && cards.sumOf { it.getMaximumValue() } == BLACKJACK_NUMBER -> BLACKJACK
+            cards.sumOf { it.getMinimumValue() } > BLACKJACK_NUMBER -> BUST
+            else -> NORMAL
+        }
+    }
+}
+```
+
+→ **enum companion 정적 메서드 + cards 외부 인자** = *Tell-Don't-Ask 부분 위반*. reviewer (Thread 22) 권유 = *HandCards 가 자가 계산*. 학생 자가 적용 권유.
+
+### 23. `Card.getMinimumValue() / getMaximumValue()` Ace 양가성
+
+```kotlin
+fun getMinimumValue(): Int = number.value.first()  // ACE = 1
+fun getMaximumValue(): Int = number.value.last()   // ACE = 11
+```
+
+→ **Ace 1↔11 양가 표현** — *value: List<Int>* 자가 활용. *NUMBER 가 multi-value 보유 (Ace: [1, 11])* = 정공.
+
+PR #117·#138 결의 *Ace soft/hard 처리* 변형 — *List<Int> + first/last* 활용.
+
+### 24. `Number` 클래스 명명 = `kotlin.Number` 충돌 위험
+
+```kotlin
+enum class Number(...)
+```
+
+→ **`kotlin.Number` 표준 클래스 명명 충돌 위험**. *import 시 명시 필요* + *호출자 가독성 ↓*.
+
+대안: `CardNumber` / `Rank` / `CardValue`.
+
+**MCP 룰 `class-name-vs-stdlib-collision` 후보** — *표준 라이브러리 명명 충돌*.
+
+### 25. `HandCards.cards: MutableList<Card>` private — backing property 자가 적용
+
+```kotlin
+class HandCards {
+    private val cards: MutableList<Card> = mutableListOf()
+
+    fun currentCards(): List<Card> = cards.toList()
+    ...
+}
+```
+
+→ **mutable list private + `currentCards()` toList 방어적 복사** = PR #21·#117·#138 결의 *backing property + 방어적 복사* 일관.
+
+reviewer (Thread 20) *"backing property에 대해 배우셨다면 활용해보세요!"* — *현재 안 OK + 추가 학습*.
+
+## 리뷰어 의견 요지
+
+- **InputView 의 Player 생성 vs InputView 책임 한계** — 3 라운드 양방향 토론 + 외부 자료.
+- **inputView/outputView private 처리** — 이전 미션 학습 시간성 한계.
+- **suit/cardNumber 상수화 (enum)** — 명시적 표현 + 점수 보유.
+- **class에 companion object만 있다면 → object 변환** + Rule god-object.
+- **todo 주석 활용 칭찬**.
+- **ArrayDeque 자료구조 자가 분석 (페어 학습)**.
+- **`show` 이름 vs 카드 리턴 의미 불일치**.
+- **String 생성은 도메인 vs View 책임 (WinLossStatistics)**.
+- **블랙잭 룰 정확성 자가 학습 (딜러 블랙잭 vs 플레이어 21)**.
+- **Deck object 의존성 문제 + 학생 자가 인지 + 대안 코드**.
+- **DSL Study 코드 = test 에**.
+- **Deck.giveCard 테스트 = 카드 수량 감소 검증**.
+- **PlayerTest 가 Deck object 사용 = 외부에서 카드 출처 확인 불가**.
+- **outputView.lineSeparator OutputView 책임 + reviewer 드래그 오류 자가 인정**.
+- **Translator 과한 구현 (YAGNI 위반)**.
+- **초기 카드 장수 = 도메인 상수**.
+- **outputView 함수 한번만 호출 4 라운드 양방향 + reviewer 자가 한계 인정**.
+- **HandCards 자가 일 칭찬**.
+- **backing property 학습 권유**.
+- **테스트 fixture 부생성자 자가 학습**.
+- **CardStatus 자가 계산 vs HandCards 자가 계산**.
+- **orderNumber 멤버 vs enum.ordinal 활용**.
+- **Card(cardIndex) 부생성자 의도 vs 도메인 누수**.
+- **Deck 안에서 카드 생성 자연스러운가? (DI vs Singleton)**.
+
+## 대표 인용
+
+> [medAndro PR 본문]
+> *"가장 마지막에 구현한 `WinLossStatistics` 클래스의 로직들은 TDD로는 구현하였으나 상수를 하드코딩하고 if문이 난무하고 메서드의 라인수가 길어지는 문제, `GameParticipant`의 `abstract fun play()`의 미사용, 예외 처리의 부재 등 여러 시간부족 이슈등으로 발생한 문제들을 인지하고 있으며 차차 개선해 나가고자 합니다!"*
+
+→ **학생 자가 한계 4 종 명시 + 시간 부족 인정**.
+
+> [hyemdooly Thread 18]
+> *"아 제가 이 조건을 놓쳤군요 😢😢😢 저도 해봤는데 메다가 올려주신 코드가 최선이네요.. 이 리뷰는 넘겨주세요! 정말정말 미안해요!!🧎‍♀️"*
+
+→ **reviewer 자가 한계 강한 어휘 인정 + 사과**. **MCP 핵심 가치 합류 정점**.
+
+> [medAndro Thread 18]
+> *"아니에요 고민하는 과정에서 저도 공부가 많이 되었어요 ☺️"*
+
+→ **학생이 reviewer 부담 최소화 + 학습 가시화**.
+
+> [medAndro Thread 11]
+> *"의도치 않은 도메인에서 접근해서 덱이 보유한 카드를 소진시켜 버리는 문제가 발생하고 Deck이 여러 도메인과 결합되어 추후에 수정하기 까다로워질 같네요. 그리고 항상 Deck이 랜덤으로만 카드를 보관하고 있어서 테스트 하기 어려운것 같습니다."*
+
+→ **Singleton 안티패턴 4 가지 자가 인지** — *부작용 + 결합 + 테스트 + Tell-Don't-Ask 위반*.
+
+> [hyemdooly Thread 9]
+> *"딜러가 블랙잭이라면 같은 블랙잭을 가진 플레이어를 제외한 모든 플레이어는 즉시 패배하며 베팅액을 잃는다. (...) 딜러가 블랙잭(A + 10인 카드)이고 플레이어가 블랙잭이 아니지만 합이 21인 경우에도 딜러 승리입니다. 🥲"*
+
+→ **블랙잭 도메인 룰 인용 + 학생 자가 도메인 학습** — *reviewer 가 도메인 룰 깊이 명시*.
+
+> [medAndro Thread 1]
+> *"처음엔 3기 제리의 테코톡 을 참고해서 View에서는 모델을 참조하거나 만들어도 되겠구나 라고 생각했었는데 로또 리뷰 과정에서 참조만 가능하고 생성은 불가능하게 하는게 좋겠다는 결론을 내려서 현재와 같아졌습니다. 다음 단계로 나아가면 DTO를 써야 할 것 같네요"*
+
+→ **외부 자료 다양성 (테코톡 + 다른 PR) + 미래 학습 의식**.
+
+## 얻은 교훈 (보편)
+
+1. **학생 → reviewer 진화 메타 케이스 (hyemdooly 2년)** — *krrong 결과 같은 패턴 2번째*. **MCP 룰 `student-to-reviewer-evolution-meta` 강화** 누적 2+ PR.
+
+2. **PR 본문 자가 한계 4 종 명시 + 시간 부족 인정** — *학생 자가 한계 명시 = 학습 적극성*. **MCP 룰 `student-self-limitations-explicit` 후보**.
+
+3. **3-4 라운드 양방향 토론 + 외부 자료 + 외부 PR 인용** — *학생 ↔ reviewer 깊이*. PR #87·#129·#138·#117 결 강화.
+
+4. **자료구조 4 안 자가 분석 + 페어 학습** — *ArrayDeque/MutableList/Stack/Queue*. **MCP 룰 `peer-learning-cross-pr-reference` 후보**.
+
+5. **블랙잭 룰 정확성 자가 학습 (딜러 블랙잭 vs 플레이어 21)** — *도메인 룰 깊이*. **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 15+ PR ⭐⭐⭐.
+
+6. **Singleton Deck 안티패턴 4 가지 자가 인지** — *부작용 + 결합 + 테스트 + Tell-Don't-Ask 위반*. **MCP 룰 `singleton-deck-via-companion` 강화** 누적 19+ PR ⭐⭐⭐.
+
+7. **이전 미션 리뷰 재발 (`inputView` private)** — *학습 시간성 한계*. **MCP 룰 `repeated-feedback-across-missions` 후보**.
+
+8. **함수 이름 vs 실제 반환 의미 불일치 (`show`)** — **MCP 룰 `function-name-vs-return-semantic-mismatch` 강화** 누적 4+ PR.
+
+9. **String 생성 = View 책임 (PR #126 결)** — **MCP 룰 `string-formatting-view-responsibility` 후보**.
+
+10. **DSL Study 코드 = test 위치 (production vs test 분리)** — **MCP 룰 `production-vs-test-code-separation` 후보**.
+
+11. **테스트 = 동작 명세 + 부작용 검증** — **MCP 룰 `test-side-effect-verification` 후보**.
+
+12. **reviewer 자가 한계 강한 어휘 인정 + 사과** — *"정말정말 미안해요!!"*. **MCP 룰 `reviewer-self-limitation-explicit-apology` 후보**.
+
+13. **YAGNI 위반 자가 인지 vs 제거 비용 (Translator)** — **MCP 룰 `yagni-violation-removal-cost` 후보**.
+
+14. **도메인 룰 상수 위치 = 도메인 (초기 카드 장수)** — **MCP 룰 `domain-constant-locator` 후보**.
+
+15. **enum.ordinal vs 커스텀 orderNumber** — **MCP 룰 `enum-ordinal-vs-custom-property` 후보**.
+
+16. **Card 인덱스 기반 생성 vs 도메인 의미 누수** — **MCP 룰 `card-index-vs-card-identity` 후보**.
+
+17. **Boolean 메서드 의미 반전 (`isDrawFinish` 16 이하 = 종료)** — **MCP 룰 `boolean-method-semantic-inversion` 후보**.
+
+18. **클래스 명 vs 표준 라이브러리 충돌 (`Number`)** — **MCP 룰 `class-name-vs-stdlib-collision` 후보**.
+
+19. **상태 계산 위치 (enum companion 정적 vs HandCards 자가)** — **MCP 룰 `state-calculation-locator` 후보**.
+
+20. **모든 25 스레드 학생 자가 답변 + commit SHA + 자가 후속 의문 5+ 회** — *2025 코호트 5 PR 합류 정점*.
+
+21. **2025 코호트 5 PR 코퍼스 형성 (#117·#129·#138·#126·#130)** — *셀프 체크리스트 + 학생 자가 의문 + commit SHA 일관 패턴*.
+
+22. **외부 자료 다양성 (테코톡 + 외부 PR + Kotlin 공식 문서 + Medium 글 + Wikipedia)** — *학생/reviewer 자가 학습 모범*.
+
+## 얻은 교훈 (도메인)
+
+1. **블랙잭 룰 정확성 = 딜러 블랙잭 vs 플레이어 21 (3장 이상) = 딜러 승리** — 학생 자가 도메인 학습.
+
+2. **Ace List<Int> = [1, 11] 양가 표현** — *getMinimumValue / getMaximumValue 자가 활용*.
+
+3. **Dealer 16 이하 hit = `<= 16` 종료** = *PR #129 (`< 16` 와전) 결과 동일 = 명명 + 비교 양립 와전*. **PR #126·#138 정공 (`<= 16` 명명 hit)** 와 반대 시점.
+
+4. **카드덱 자료구조 (ArrayDeque) 자가 분석** — *4 안 + 페어 학습*.
+
+5. **`Number` enum + multi-value (Ace: [1, 11])** — *Ace 1↔11 자가 표현*.
+
+6. **Card(cardIndex) 부생성자 = Deck 섞기 의도** — *도메인 의미 누수 vs Deck flatMap 복잡도 트레이드오프*.
+
+7. **Singleton Deck (object) = 19+ PR 누적 안티패턴** — *학생 자가 인지 후 유지* (시간 부족).
+
+## MCP 룰 후보 신규 + 강화 (PR #130)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `student-to-reviewer-evolution-meta` | 강화 | 2+ (krrong + hyemdooly) |
+| `student-self-limitations-explicit` | 신규 | 1 (#130) |
+| `peer-learning-cross-pr-reference` | 신규 | 1 (#130) |
+| `blackjack-rule-fidelity-comparison` | 강화 | 15+ ⭐⭐⭐ |
+| `singleton-deck-via-companion` | 강화 | 19+ ⭐⭐⭐ |
+| `repeated-feedback-across-missions` | 신규 | 1 (#130) |
+| `function-name-vs-return-semantic-mismatch` | 강화 | 4+ |
+| `string-formatting-view-responsibility` | 신규 | 2+ (#126·#130) |
+| `production-vs-test-code-separation` | 신규 | 1 (#130) |
+| `test-side-effect-verification` | 신규 | 1 (#130) |
+| `reviewer-self-limitation-explicit-apology` | 신규 | 1 (#130) |
+| `yagni-violation-removal-cost` | 신규 | 2+ (#146·#130) |
+| `domain-constant-locator` | 신규 | 1 (#130) |
+| `enum-ordinal-vs-custom-property` | 신규 | 1 (#130) |
+| `card-index-vs-card-identity` | 신규 | 1 (#130) |
+| `boolean-method-semantic-inversion` | 신규 | 2+ (#117·#139·#130) |
+| `class-name-vs-stdlib-collision` | 신규 | 1 (#130) |
+| `state-calculation-locator` | 신규 | 1 (#130) |
+| `view-model-future-learning-awareness` | 신규 | 3+ (#21·#35·#130) |
+| `class-with-only-companion-to-object` | 신규 | 1 (#130) |
+
+## 메타 어휘 (14 reviewer + MCP 핵심 가치 합류 정점 유지)
+
+- ***hyemdooly (둘리) = 14번째 reviewer + 학생 → reviewer 진화 (2년)*** — *krrong 결과 같은 메타 케이스 2번째*. **MCP `oh-my-oop` *학습 = 시간 두고 반복* 정점**.
+- ***reviewer 자가 한계 강한 어휘 인정*** — hyemdooly PR #130 — *"정말정말 미안해요!!🧎‍♀️"* — *reviewer 가 자가 한계 명시 + 학생 부담 최소화*.
+- ***학생이 reviewer 부담 최소화*** — medAndro PR #130 — *"고민하는 과정에서 저도 공부가 많이 되었어요 ☺️"* — *양방향 격려 어휘*.
+- ***학생 자가 한계 4 종 명시 + 시간 부족 인정*** — medAndro PR #130 — *학생 자가 *코드 한계 자가 인지 정점***.
+- ***외부 자료 다양성 (테코톡 + 외부 PR + 페어 + Medium + Wikipedia)*** — medAndro PR #130 — *학생 자가 학습 정점*.
+- ***Singleton 안티패턴 4 가지 자가 인지*** — medAndro PR #130 — *부작용 + 결합 + 테스트 + Tell-Don't-Ask 위반*.
+- ***블랙잭 도메인 룰 인용 + 학생 자가 도메인 학습*** — hyemdooly PR #130 — *reviewer 가 블랙잭 정확성 인용*.
+
+→ **14 reviewer + MCP 핵심 가치 어휘 합류 정점 유지**. **2025 코호트 5 PR 코퍼스 형성 (#117·#129·#138·#126·#130)** + **학생 → reviewer 진화 메타 케이스 2번째 (hyemdooly = 2년)**. 
+
+## 메타 케이스 비교 (krrong vs hyemdooly)
+
+| 항목 | krrong (PR #32 → #148·#151) | hyemdooly (PR #21·#35 → #130) |
+|---|---|---|
+| 학생 시기 | 2023년 3월 | 2023년 3월 |
+| reviewer 시기 | 2024년 3월 | 2025년 3월 |
+| 진화 기간 | 1년 | 2년 |
+| 학생 시기 어휘 | 자가 의문 + 학습 진행 | PR 본문 자가 의문 3개 + 자가 의견 명시 |
+| reviewer 시기 어휘 | 양방향 토론 + reviewer 메타 | 양방향 토론 + reviewer 자가 한계 인정 |
+| MCP `oh-my-oop` 합류 | *학습 = 시간 두고 반복* | *학습 = 시간 두고 반복 + reviewer 자가 한계* |
+
+→ **2년 진화 = 더 깊은 reviewer 어휘** (krrong 1년 < hyemdooly 2년). **MCP `oh-my-oop` 핵심 가치 정점 유지**.