oh-my-oop 0.2.0

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

@@ -0,0 +1,147 @@
+# PR #149 — [블랙잭 2단계] 오이 미션
+
+- **Reviewee:** [@cucumber99](https://github.com/cucumber99)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/149
+- **단계:** 2단계
+- **리뷰어:** [@hyemdooly](https://github.com/hyemdooly) (둘리) — 1단계 #109 동일 reviewer
+- **라인 코멘트:** 13 스레드 — *PR 본문 자가 의문 (수익 계산 책임) + 학생 자가 의견 + Sequence Kotlin 어휘 자가 학습 + reviewer 자가 *뭉치 코드와 같은 의도* + reviewer 자가 *제가 작성한 코드는 ... 문제가 없었던거였어요* 자가 학습 정점 + lateinit var 자가 학습 + 첫 턴 딜러 카드 비즈니스 로직 (학생 자가 *명확한 답 힘들다* 인정)*
+- **양 단계 완성 reviewee** (1단계 #109 batch 21 분석 완료 + 2단계 #149 = batch 23 추가).
+
+## 잘한 점 (설계 관점)
+
+### 1. reviewer 자가 학습 어휘 정점 (Thread 12)
+
+reviewer:
+
+> *"두 패를 비교하는 것을 의도했고, 제가 생각한대로 되는지 코드도 작성해봤었는데요! (현재 뭉치의 코드가 제 리뷰 의도와 똑같아요. 궁금하시면 구경가보셔도..?! 👀)*
+>
+> *제가 작성한 코드는, 딜러의 수익금을 계산할 때 플레이어의 결과 수익금의 합에 -1를 곱한 형태라 문제가 없었던거였어요. 😮 플레이어의 결과만 계산에 사용하는 형태라, Hand 로직이 플레이어 기준이었네요. Hand만 놓고보면 플레이어 기준 로직이기에, 어떻게 보면 어색한 코드였겠군요..?!*
+>
+> *오이 덕분에 놓친 부분을 알았네요. 😅 의견 나누어주셔서 감사합니다!! 👍"*
+
+→ **reviewer 자가 학습 + 학생에게 감사 어휘 + 다른 학생 코드 cross-reference (뭉치)** = *PR #126·#130·#142·#109 (reviewer 자가 한계 인정) 결 정점*. **MCP 룰 `reviewer-self-learning-from-student` 후보** — *reviewer 가 학생 의견에서 자가 학습*.
+
+### 2. Sequence Kotlin 어휘 학생 자가 학습
+
+reviewer (Thread 5): *"Sequence로 변환해주셨네요! Sequence는 어떨 때 사용하면 좋을까요?"*
+
+학생:
+
+> *"수업에서 배운 것처럼, 상태가 없는 연산(map, filter 등)이 자주 일어날 때 사용하면 좋습니다. 위 코드에서는 map, flatMap이 사용되고 있기 때문에 한 번 적용해보고자 했습니다!"*
+
+→ **Sequence 자가 적용** = *Kotlin 어휘 깊은 학습*. **MCP 룰 `sequence-vs-collection-criteria` 후보**.
+
+### 3. value class BettingAmount 칭찬 + ResultState.profitRate 정의 (Thread 3·13)
+
+reviewer: *"원시값들을 모두 포장해주었네요 👍"* + *"ResultState에 profitRate를 정의해주었군요 👍"*.
+
+→ **value class + enum 책임 강화** = PR #138·#142·#143 결.
+
+### 4. 모든 13 스레드 학생 자가 답변 + 자가 의문 4+ 회 (2025 코호트 정점)
+
+## 못한 점 (설계 관점)
+
+### 1. 수익 계산 책임 = 외부 객체 vs 참가자 자가 (PR 본문 자가 의문)
+
+학생 자가 답변:
+
+> *"`List<Card>`를 플레이어와 딜러가 갖고 있으니, 수익금 계산이나 승패 결정도 내부에서 할 수 있겠다고 생각했어요. 다만, 그렇게 되면 플레이어와 딜러가 너무 많은 책임을 갖게 되는 것이 아닌가 고민되는데요🤔"*
+
+reviewer:
+
+> *"단일책임원칙(SRP)에 대해 공부해보시면 좋을 것 같아요! 어떻게 설계하면 한 클래스가 변경되었을 때 다른 클래스가 같이 변경을 안해도 될지 고민해보세요😊"*
+
+→ **SRP + 변경 영향 어휘** = PR #126 (change-impact-as-locus-criteria) 결 합류.
+
+### 2. GameRule 상수 분리 vs 도메인 분산 (PR #109 결 재발)
+
+학생 자가 의문 + reviewer 답변 — *PR #109 1단계 결과 같은 의문 재발*. **MCP 룰 `constant-aggregation-vs-domain-distribution` 강화** 누적 2+ PR (#109·#149).
+
+### 3. 첫 턴 딜러 카드 = 비즈니스 로직 (PR #126·#142 결 재발)
+
+학생: *"`카드 한 장을 보여주지 않는 것은 누구의 책임일까?`에 대해서 크루들과 얘기를 나눈 적이 있어요! 사실 아직도 명확한 답을 내리기가 힘든 것 같은데, 제가 생각하기에는 비즈니스 로직에 조금 더 가까운 것 같아요."*
+
+→ **학생 자가 *명확한 답 힘들다* 메타 학습** = *학습 시간성*. PR #126·#142·#129 결 합류.
+
+### 4. `canHit() = !isBust()` 블랙잭 처리 X (Thread 7)
+
+reviewer: *"블랙잭일 때도 false여야하지 않나요?"*
+
+학생: *"`Game` 객체를 사용하고 있을 때는 블랙잭인 경우를 처리해주고 있었기 때문에 차마 신경쓰지 못한 부분인 것 같아요."*
+
+→ **1단계 → 2단계 회귀 자가 인지** = PR #139 (abs 자가 정정) 결 합류.
+
+### 5. BettingAmount.calculateProfit(ResultState/profitRate) (Thread 8) — Tell-Don't-Ask
+
+reviewer: *"BettingAmount한테, ResultState 또는 비율을 받아 계산하고 ProfitAmount을 리턴하게 하는 것은 어떨까요?"*
+
+→ **value class 책임 강화** = PR #143·#142·#140 결 합류.
+
+### 6. `Participant.visibleCard()` 추상화 + `this is Dealer` 제거 (Thread 9)
+
+reviewer: *"`Participant`의 `visibleCard()`를 추상화해서, 플레이어와 딜러 각각 따로 구현해주고 `this is Dealer` 로직을 삭제할 수 있어보여요."*
+
+→ **다형성 + `is` 연산자 회피** = PR #87 (is-operator-polymorphism-avoidance) 결 합류 누적 7+ PR.
+
+### 7. BettingInfo vs Player.bettingAmount 양방향 토론 (Thread 10)
+
+reviewer:
+
+> *"플레이어가 베팅 금액을 가지고 있지 않은 이유가 있으신가요? 코멘트로 이야기했던대로 내부에서 처리하면 더 객체가 일한다는 느낌을 줄 수 있을 것 같아서요. 저는 플레이어가 베팅 금액을 가지고 있어도 괜찮다는 의견인데(BettingInfo를 묶어두고 하는 일이 없기도 하구요), 오이의 생각은 어떠신지 궁금합니다!"*
+
+학생 자가 답변:
+
+> *"`lateinit var` 키워드를 사용하면, 이름을 다 입력받고 난 후 베팅 금액을 따로 받을 수 있겠다고 생각했는데요. 다만 `lateinit` 키워드를 사용해서 발생할 수 있는 문제점도 생각했어요. (초기화되지 않은 값에 접근 등)"*
+
+→ **BettingInfo 분리 vs Player 멤버 + lateinit 자가 학습** = PR #138 (BlackJackTable 형식 규칙 부산물 자가 비판) 결 합류.
+
+### 8. Dealer.profitOfPlayer 명명 부적합 (Thread 11)
+
+reviewer: *"Dealer 클래스만 봤을 때 이 함수는 딜러의 수익을 리턴할 것 같았는데 속은 플레이어의 수익이군요 🤔"*
+
+→ **이름 의미 정확성** = 누적 11+ PR.
+
+### 9. Hand 책임 vs Participant 책임 — reviewer 자가 학습 (Thread 12)
+
+§1 참조. **MCP 룰 `reviewer-self-learning-from-student` 후보** — *reviewer 의 자가 학습 정점*.
+
+### 10. `lateinit` 학생 자가 학습 + 단점 인지
+
+학생이 *`lateinit` 단점 (초기화되지 않은 값 접근)* 자가 인지 = **MCP 룰 `lateinit-var-call-order-invariant` 강화** 누적 12+ PR.
+
+## 대표 인용
+
+> [hyemdooly Thread 12]
+> *"오이 덕분에 놓친 부분을 알았네요. 😅 의견 나누어주셔서 감사합니다!! 👍"*
+
+→ **reviewer 자가 학생 의견 학습** — *MCP 핵심 가치 정점*.
+
+> [hyemdooly Thread 1]
+> *"단일책임원칙(SRP)에 대해 공부해보시면 좋을 것 같아요! 어떻게 설계하면 한 클래스가 변경되었을 때 다른 클래스가 같이 변경을 안해도 될지 고민해보세요😊"*
+
+→ **SRP + 변경 영향 어휘**.
+
+> [cucumber99 Thread 6]
+> *"사실 아직도 명확한 답을 내리기가 힘든 것 같은데, 제가 생각하기에는 비즈니스 로직에 조금 더 가까운 것 같아요."*
+
+→ **학생 자가 *명확한 답 힘들다* 메타 학습**.
+
+## 얻은 교훈 (보편)
+
+1. **reviewer 자가 학습 (학생 의견 → reviewer 학습)** — **MCP 룰 `reviewer-self-learning-from-student` 후보**.
+2. **Sequence vs Collection (Kotlin 어휘)** — **MCP 룰 `sequence-vs-collection-criteria` 후보**.
+3. **`lateinit var` 단점 자가 인지** — PR #138·#142·#141 결 강화 누적 12+ PR.
+4. **GameRule 상수 분리 1단계 → 2단계 재발** — PR #109·#149 결 합류.
+5. **Hand 책임 양방향 토론 + reviewer 자가 학습** — *학생 ↔ reviewer 양방향 정점*.
+6. **첫 턴 딜러 카드 비즈니스 로직 = 학생 자가 *명확한 답 X* 메타 학습** — *학습 시간성*.
+
+## MCP 룰 후보 신규 + 강화 (PR #149)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `reviewer-self-learning-from-student` | 신규 | 1 (#149) |
+| `sequence-vs-collection-criteria` | 신규 | 1 (#149) |
+| `lateinit-var-call-order-invariant` | 강화 | 12+ |
+| `constant-aggregation-vs-domain-distribution` | 강화 | 2+ (#109·#149) |
+| `is-operator-polymorphism-avoidance` | 강화 | 7+ |
+| `function-name-vs-return-semantic-mismatch` | 강화 | 11+ |

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

@@ -0,0 +1,168 @@
+# PR #121 — [블랙잭 1단계] 이든 미션
+
+- **Reviewee:** [@devfeijoa](https://github.com/devfeijoa)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/121
+- **단계:** 1단계
+- **리뷰어:** [@Gyuil-Hwnag](https://github.com/Gyuil-Hwnag) (두루) — **2024 코호트 reviewer (PR #98·#146 등) + 2025 reviewer 다년 활동** (말리빈에 이어 *두번째 reviewer 다년 활동 메타 케이스*)
+- **라인 코멘트:** 24 스레드 — *PR 본문 *기초지식 부족 + TDD + 페어 학습* 자가 인정 + main 에 모든 코드 학생 초안 (구조 미숙) + 도메인↔View 분리 권유 (4 자리) + Ace/Character/Number → Rank 통합 권유 + 객체 분리 (Hand 점수 / 게임 결과 / Bust 판별) + 하드코딩 상수화 + 매퍼/함수/toString() 변환 트레이드오프 + 블랙잭 도메인 어려움 → 페어/크루 의견 듣기 어휘*
+- **신규 reviewee** (2025년 코호트 — 모바일 안드로이드 7기, 누적 8 reviewees + #121 = 9 reviewees).
+- **메타 케이스**: 두루 (Gyuil-Hwnag) = 2024 reviewer (PR #98 chaehyuns 등) + 2025 reviewer (PR #121) **= 두번째 reviewer 다년 활동** (말리빈 PR #118 결과 같은 패턴).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 한계 인정 + TDD + 페어 학습
+
+PR 본문:
+
+> *"이번 미션을 페어와 TDD에 집중하여 만들었습니다. 제가 기초지식이 부족하여 여러 개념들을 헷갈려하는 부분이 많았고 코드작성이 어려운 부분이 많았습니다. 그럴때마다 페어가 제가 이..."*
+
+→ **학생 자가 *기초지식 부족* 자가 인정 + 페어 학습 의식 + TDD 집중** = PR #130 (medAndro TDD + 페어) 결 합류. **MCP `oh-my-oop` *학습 = 시간 두고 반복* 어휘 정점**.
+
+### 2. 두루 (Gyuil-Hwnag) 2024 → 2025 reviewer 다년 활동 — 메타 케이스 4번째
+
+- **2024 PR 들**: 두루 = PR #98 chaehyuns + PR #146 yrsel reviewer.
+- **2025 PR #121**: 두루 = devfeijoa reviewer.
+
+→ **reviewer 다년 활동 2번째 사례** = *말리빈 PR #118 결과 같은 패턴*. **MCP 룰 `multi-year-reviewer-activity` 강화** 누적 2+ reviewer (말리빈 + 두루).
+
+### 3. 두루 어휘 = *집단 지성 무지하게 중요합니다*
+
+reviewer (Thread 16):
+
+> *"블랙잭이라는 도메인이 많이 어렵다면 다른 크루들이나 페어의 의견을 들어보는 것도 좋을 것 같다는 생각이 듭니다!💪 집단 지성 무지하게 중요합니다..!"*
+
+→ **집단 지성 어휘 + 페어/크루 의견 권유** = PR #95·#23·#26·#108·#136·#151·#146·#148 (말리빈/잭슨·페로로·지훈·크롱) 결의 *다른 크루 의견 어휘* 합류.
+
+**MCP 룰 `collective-intelligence-as-resource` 후보** — *집단 지성 어휘*.
+
+### 4. `Card(val shape, val number)` 통합 권유 학생 자가 적용
+
+reviewer (Thread 12·21): *"각 Shape별로 따로 있을 이유가 있을까요? `Card(val shape, val number)`로 변경한다면, 해당 구현이 정리되겠군요~"*
+
+→ **분리된 객체 통합 (god-class 회피 X = 인공 분리)**. **MCP 룰 `over-separation-into-parallel-classes` 후보** — *Ace/Character/Number 처럼 비슷한 객체 평행 분리 vs 단일 통합*.
+
+### 5. 두루의 *각 객체 담당 최소화* 어휘 (Thread 10)
+
+reviewer:
+
+> *"딜러가 Deck에서 카드를 뽑아서 사용자들한테 나누어주는데, 딜러도 하나의 참가자로 해보도록 하고자 시작한 코멘트였습니다! 각 객체가 담당하는 것을 최소화하도록 구성을 해보는 것도 좋을 것 같습니다💪"*
+
+→ **단일 책임 + 딜러 = 참가자** = PR #87·#129·#126·#138 (Tell-Don't-Ask + Participant 추상화) 결 합류.
+
+## 못한 점 (설계 관점)
+
+### 1. main 에 모든 코드 — 학생 초안
+
+reviewer (Thread 2): *"허걱...🫣 main 에 모든 코드를 올인하셨군요! 해당 내용은 이번 미션을 진행하면서 차근차근 리팩토링을 해봅시다!"*
+
+→ **학생 미숙 = main 에 모든 로직**. *기초지식 부족 인정* + *차근차근 리팩토링 권유*. **MCP 룰 `main-as-god-function` 후보**.
+
+### 2. View ↔ Controller 분리 (Thread 3·4·5·6)
+
+reviewer 가 4 자리에 걸쳐 분리 권유:
+1. View 와 Controller 영역 분리.
+2. main() 함수 분리 (하나의 함수 = 하나의 기능).
+3. View 상수 + 포맷 활용.
+4. Domain ↔ View 책임 구분.
+
+→ **레이어 분리 학생 자가 적용** = PR #21·#117·#129·#143 결 합류 누적 다수 PR.
+
+### 3. Ace/Character/Number → Rank 통합 (Thread 7·21)
+
+reviewer 가 2 자리에 걸쳐 *3 객체 → 1 통합 (Rank)* 권유.
+
+→ **평행 분리 객체 인공 = 단일 통합** = PR #142·#143 결의 *통합 책임* 어휘 합류.
+
+### 4. Deck 하드코딩 → 동적 생성 (Thread 22)
+
+reviewer:
+
+> *"덱을 하드코딩으로 넣어주는 방법외에, 다른 방법은 없을까? 고민이 필요할 것 같습니다💪 현재 구현을 본다면 신규 번호가 추가된다면, 모든 하드코딩된 내용에 추가해야 하군요."*
+
+→ **하드코딩 vs 동적 생성 (flatMap 등) 트레이드오프**. **MCP 룰 `hardcoded-vs-dynamic-generation` 후보** — *카드 52장 하드코딩 vs flatMap 동적 생성*.
+
+PR #117·#118·#130·#138·#142 (Card 생성 = flatMap/Suit×CardRank) 결 합류.
+
+### 5. inputView 에 블랙잭 로직 (Thread 17)
+
+reviewer (학생 자가 의문 답변): *"그렇지만 inputView에 블랙잭의 로직이... 들어가 있군요🥲"*
+
+→ **Domain ↔ View 분리 위반**. PR #126 (Verdict 출력) + PR #142 (에러 메시지 위치) 결 합류.
+
+### 6. Hand 21점 초과 null 반환 vs 점수 반환 학생 자가 의문 (Thread 16)
+
+학생:
+
+> *"21점이 넘으면 null을 반환하고 있었어서 21점이 넘더라도 점수의 결과를 보여줄 때 null 대신 점수를 반환하고자 했습니다. Score에 관련된 모든것들이 nullable해서 연관된 부분들을 다 수정하였습니다."*
+
+→ **nullable vs default 트레이드오프 학생 자가 학습**. PR #138·#35 (Kotlin null vs 예외) 결 합류.
+
+### 7. Bust 판별 = Blackjack 객체 vs 다른 객체 (Thread 20)
+
+reviewer:
+
+> *"Bust인지 판별이 Blackjack 객체의 역활일까요? 그렇게 되면 Blackjack 객체가 너무 많은 역활을 담당하게 된다는 생각이 듭니다! 객체별로 역활을 분리해보는것이 좋을 것 같습니다"*
+
+→ **god-class 회피** = PR #87·#117·#118·#141·#142 결 합류.
+
+### 8. 매퍼 vs 함수 vs `toString()` 트레이드오프 (Thread 24)
+
+reviewer:
+
+> *"toString()을 오버라이딩 해서 작성을 해보는 방법도 있고, 이처럼 매퍼 또는 함수로 변환을 하는 방법이 있습니다! 각 상황마다 이든이 생각하시기에 어떤방법이 좋을지 본인만의 기준을 세우는 것!도 중요합니다~"*
+
+→ **변환 방법 3 안 + 학생 자가 기준 세우기 어휘** = **MCP `oop_propose_alternatives` 핵심 가치 합류**. **MCP 룰 `to-string-vs-mapper-vs-function-conversion` 후보**.
+
+### 9. 하드코딩 상수화 + 학생 자가 장점 의문 (Thread 23)
+
+reviewer:
+
+> *"하드코딩된 내용에 대한 상수화를 한다면, 재사용을 포함해서 여러가지 장점을 얻을 수 있을 것 같은데, 이든이 생각하시기에는 어떤 장점들이 있을까요?"*
+
+→ **reviewer 가 학생에게 *장점 묻기*** = *학생 자가 학습 유도*.
+
+## 대표 인용
+
+> [Gyuil-Hwnag Thread 16]
+> *"블랙잭이라는 도메인이 많이 어렵다면 다른 크루들이나 페어의 의견을 들어보는 것도 좋을 것 같다는 생각이 듭니다!💪 집단 지성 무지하게 중요합니다..!"*
+
+→ **집단 지성 어휘** — *학습 자원 활용 어휘*.
+
+> [Gyuil-Hwnag Thread 10]
+> *"각 객체가 담당하는 것을 최소화하도록 구성을 해보는 것도 좋을 것 같습니다💪"*
+
+→ **단일 책임 어휘**.
+
+> [Gyuil-Hwnag Thread 13]
+> *"이든이 DM에서 언급하신대로 `딱 현재 요구사항에 맞게 돌아만 가게 되어있는 구현`이라는 생각이 진하게 듭니다..🥲"*
+
+→ **DM 토론 + *현재 요구사항만 동작* 자가 인정** = PR #138·#142·#129 (DM 활용) 결 합류.
+
+## 얻은 교훈 (보편)
+
+1. **두루 (Gyuil-Hwnag) 2024 → 2025 reviewer 다년 활동** — **MCP 룰 `multi-year-reviewer-activity` 강화** 누적 2+ reviewer (말리빈 + 두루).
+
+2. **집단 지성 어휘 + 페어/크루 의견 듣기** — **MCP 룰 `collective-intelligence-as-resource` 후보**.
+
+3. **평행 분리 객체 (Ace/Character/Number) → 단일 통합 (Rank)** — **MCP 룰 `over-separation-into-parallel-classes` 후보**.
+
+4. **하드코딩 vs 동적 생성** — **MCP 룰 `hardcoded-vs-dynamic-generation` 후보**.
+
+5. **변환 방법 3 안 (toString/매퍼/함수) + 자가 기준** — **MCP 룰 `to-string-vs-mapper-vs-function-conversion` 후보**.
+
+6. **main 에 모든 코드 = 학생 초안** — **MCP 룰 `main-as-god-function` 후보**.
+
+7. **reviewer 가 *장점 묻기* = 학생 자가 학습 유도**.
+
+8. **DM 토론 + *현재 요구사항만 동작* 자가 인정** = PR #138·#142·#129 결 합류.
+
+## MCP 룰 후보 신규 + 강화 (PR #121)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `multi-year-reviewer-activity` | 강화 | 2+ (말리빈·두루) |
+| `collective-intelligence-as-resource` | 신규 | 1 (#121) |
+| `over-separation-into-parallel-classes` | 신규 | 1 (#121) |
+| `hardcoded-vs-dynamic-generation` | 신규 | 1 (#121) |
+| `to-string-vs-mapper-vs-function-conversion` | 신규 | 1 (#121) |
+| `main-as-god-function` | 신규 | 1 (#121) |

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

@@ -0,0 +1,116 @@
+# PR #153 — [블랙잭 2단계] 이든 미션
+
+- **Reviewee:** [@devfeijoa](https://github.com/devfeijoa)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/153
+- **단계:** 2단계
+- **리뷰어:** [@Gyuil-Hwnag](https://github.com/Gyuil-Hwnag) (두루) — 1단계 #121 동일 reviewer (2024→2025 다년 활동)
+- **라인 코멘트:** 16 스레드 — *PR 본문 *DM 으로 얘기했던 것처럼 새로 코드 작성 + 마감시간이 곧* 학생 자가 한계 인정 + callback 어휘 학생 자가 *푹 빠짐* + Players 8명 제한 블랙잭 도메인 룰 자가 학습 + State interface (Hit/Stay/Finished) + dead code (사용 안 하는 객체) + 테스트 실패 + 패키지 분리 권유*
+- **양 단계 완성 reviewee** (1단계 #121 batch 22 분석 완료 + 2단계 #153 = batch 23 추가).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 한계 인정 (마감시간 + DM 토론)
+
+PR 본문:
+
+> *"안녕하세요 두루 ! 앞서 DM으로 얘기했던것 처럼 새로 코드를 작성하였습니다. 빠진 기능이 꽤나 존재하지만 마감시간이 곧이라 일단 제출하여 피드백을 받고자 합니다..!"*
+
+→ **학생 자가 마감시간 한계 + 새로 코드 작성 + DM 토론** = PR #130·#139·#143·#121 (학생 자가 한계 인정) 결 합류. **DM 활용** = PR #129·#138·#142·#121 결 합류.
+
+### 2. Players 8명 제한 블랙잭 도메인 룰 자가 학습 (Thread 6)
+
+학생: *"원래 블랙잭 도메인이 가지고 있는 조건인 참가자를 8명까지 제한한다라는 조건을 적용했습니다 !"*
+
+→ **블랙잭 도메인 룰 자가 학습** = PR #138 (rosemin928 *8 덱 룰 자가 학습*) 결의 *8 명 룰* 합류. **MCP 룰 `multi-deck-domain-rule` 강화** (8 명 + 8 덱 룰).
+
+### 3. State interface (Hit/Stay/Finished) — State 패턴 자가 적용
+
+학생 자가 적용 — *Hit/Stay/Finished State 자식 + 추상 메서드*. PR #93·#136·#152·#98·#36·#87·#142·#143·#138 결의 *State 패턴* 어휘 합류.
+
+### 4. callback 어휘 학생 자가 *푹 빠짐* + reviewer 권유
+
+reviewer (Thread 7): *"갑자기 callback에 푹빠지셨군요! callback의 생성과정에 대한 설명과 어떤 특징이 있는지에 대해서 이든의 의견을 남겨주세요💪"*
+
+→ **reviewer 학생 자가 의견 요청** = *PR #109·#129·#126·#143 (학생 자가 의견 요청) 결*. *학생이 callback 자가 적용 + reviewer 가 *학생에게 *이유* 묻기**.
+
+## 못한 점 (설계 관점)
+
+### 1. callback 형태 장단점 + 함수 파라미터 (Thread 2·3·7)
+
+reviewer 3 자리에 걸쳐 *callback 사용 이유 + 장단점* 묻기.
+
+→ **고차함수 / callback 활용 학생 자가 학습** = PR #109·#140·#143 (고차함수 = View 의존 X) 결 합류.
+
+### 2. State 가 profit 알 필요 (Thread 8) — 학생/reviewer 양방향
+
+reviewer: *"규칙에서 `profit`에 대해서 반드시 알아야 할 이유가 있을까요?"*
+
+학생:
+
+> *"규칙에 대한 인터페이스가 아니라 말 그대로 상태를 알려준다고 생각해서, 상태에 관련된 함수들을 구현했습니다. 그래서 State에서도 수익을 계산할 수 있다고 생각했습니다. 그래서 수익을 계산할때 상대의 상태를 받아서 계산하는 것으로 수정했습니다 !"*
+
+→ **State 책임 vs 외부 객체 (Result) 양방향** = PR #142·#143 결 합류.
+
+### 3. 사용 안 하는 객체 (Stay, playerTotalScore) — Dead code (Thread 9·10·15)
+
+reviewer 3 자리에 걸쳐 *사용 안 하는 객체/변수 지적*.
+
+→ **Dead code** = PR #139 (이전 단계 코드 잔재 정리) 결 + PR #130 (Translator 과한 구현) 결 합류. **MCP 룰 `dead-code-removal` 후보**.
+
+### 4. 하드코딩 상수화 (Thread 11·14·16)
+
+reviewer 3 자리에 걸쳐 *하드코딩 상수화 권유*.
+
+→ **상수화** = PR #117·#118·#129·#121 결 합류.
+
+### 5. 테스트 실패 + 테스트 빠진 객체 (Thread 12)
+
+reviewer: *"해당 테스트는 실패하는 것처럼 나오는군요😅 테스트가 빠져있는 객체들이 많은 것 같군요🥲"*
+
+→ **테스트 누락 + 실패** = *학생 자가 마감 시간 한계* 결과. **MCP 룰 `failing-test-as-incomplete-submission` 후보** — *실패하는 테스트 + 누락 = 미완성 제출*.
+
+### 6. 패키지 분리 (Thread 13)
+
+reviewer: *"모든 객체들이 도메인안에 한곳에 모여있다보니 헷갈릴 수 있겠다는 생각이 들었어요~ 세부 패키지에 대해서 분리를 해보는 방법도 좋을 것 같다는 생각이 듭니다💪"*
+
+→ **package-by-domain** = PR #142·#118 결 합류.
+
+### 7. Deck 외부 노출 함수 (Thread 4)
+
+학생 자가 답변: *"해당 함수를 외부로 드러나지 않게, 덱을 외부에서 수정할 수 없게 하였습니다 !"*
+
+→ **encapsulation 자가 적용** = PR #21·#117·#138 결 합류.
+
+## 대표 인용
+
+> [devfeijoa PR 본문]
+> *"빠진 기능이 꽤나 존재하지만 마감시간이 곧이라 일단 제출하여 피드백을 받고자 합니다..!"*
+
+→ **학생 자가 마감 한계 인정 + 피드백 우선 전략** = PR #139·#143·#130 결.
+
+> [Gyuil-Hwnag Thread 7]
+> *"갑자기 callback에 푹빠지셨군요! callback의 생성과정에 대한 설명과 어떤 특징이 있는지에 대해서 이든의 의견을 남겨주세요💪"*
+
+→ **reviewer 학생 자가 의견 요청 어휘**.
+
+> [devfeijoa Thread 6]
+> *"원래 블랙잭 도메인이 가지고 있는 조건인 참가자를 8명까지 제한한다라는 조건을 적용했습니다 !"*
+
+→ **블랙잭 8명 도메인 룰 자가 학습** = PR #138 (rosemin928 8 덱 룰) 결 합류.
+
+## 얻은 교훈 (보편)
+
+1. **블랙잭 8명 제한 + 8 덱 도메인 룰** — **MCP 룰 `multi-deck-domain-rule` 강화**.
+2. **Dead code** — **MCP 룰 `dead-code-removal` 후보**.
+3. **실패 테스트 = 미완성 제출** — **MCP 룰 `failing-test-as-incomplete-submission` 후보**.
+4. **callback 학생 자가 *푹 빠짐* + reviewer 의견 요청**.
+5. **State 가 profit 알 필요 = 학생/reviewer 양방향** — PR #142·#143 결 합류.
+
+## MCP 룰 후보 신규 + 강화 (PR #153)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `multi-deck-domain-rule` | 강화 | 3+ (#58·#138·#153) — 8 명 + 8 덱 |
+| `dead-code-removal` | 신규 | 1 (#153) |
+| `failing-test-as-incomplete-submission` | 신규 | 1 (#153) |
+| `package-by-domain` | 강화 | 3+ |