oh-my-oop 0.2.0

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

@@ -0,0 +1,278 @@
+# PR #51 — [블랙잭 2단계] 부나 미션
+
+- **Reviewee:** [@tmdgh1592](https://github.com/tmdgh1592)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/51
+- **단계:** 2단계 (베팅 + State 패턴 + Composition)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 19 / 리뷰이 11)
+- **참고:** 같은 학생의 1단계 = [PR #29](./29-1단계-블랙잭.md)
+
+## 잘한 점 (설계 관점)
+
+- **State 패턴 도입** — `CardState` 추상 + `StartState`/`HitState`/`StayState`/`BustState`/`BlackjackState`.
+- **`Money` + `BetMoney` 도메인** — *연산자 오버로딩* (`+`, `*`, `unaryMinus`) — 리뷰어 칭찬.
+- **`Participants.takePlayerTurns / takeDealerTurns`** — 진행자 메서드.
+- **`BlackjackEventListener`로 콜백 통합 (후속 반영)** — Controller god-object 회피.
+- **Fixtures.kt 테스트 fixture** — 리뷰어 칭찬.
+- **후속 반영 — Blackjack 생성자에 deck + players 동시 주입 + 불변 RunningState (add 시 새 List) + canDraw 내부 호출 + while → do-while 변경**.
+
+## 못한 점 (설계 관점)
+
+### 1. `Int.isGreaterThan(value: Int): Boolean` 확장 함수 — 친숙성 ↓
+
+```kotlin
+// blackjack/Extensions.kt
+fun Int.isGreaterThan(value: Int): Boolean = this > value
+```
+
+리뷰어: "*이 함수를 사용하는 것과 Int > Int 를 비교하는 것중 무엇이 더 개발자에게 친숙할까요?* `val isBust = 5 > 10` vs `val isBust = 5.isGratherthan(10)`"
+
+학생 자가 인정: "*한글자로 끝낼 수 있는걸 늘려놓은 느낌인 것 같아 전자가 더 친숙해보입니다! 수정하겠습니다 : )*" — **확장 함수 *과잉*. *기본 연산자가 명확*하면 *DSL 효과 없음***. PR #34·#92와 같은 결.
+
+### 2. `BlackjackController.start()`가 *5개 callback 인자*
+
+```kotlin
+fun start() {
+    Blackjack(CardDeck()).start(
+        players = InputView.inputPlayers(),
+        onStartFirstDrawn = OutputView::printFirstDrawnMessage,
+        onFirstDrawn = OutputView::printFirstOpenCards,
+        onDrawnMore = OutputView::printAllCards,
+        onEndGame = OutputView::printBlackjackResult
+    )
+}
+```
+
+리뷰어: "*출력에 대해서 요구사항이 변경될 때 마다 start() 함수의 파라미터로 많은 값을 넘겨야 할 수 있습니다.* *이와 관련된 리스너 인터페이스를 만들어서 전달 해 보는건 어떨까요?*"
+
+학생: "*BlackjackEventListener를 통해서 하나의 객체만 전달하도록 해보겠습니다!*" — **5개 callback = 인터페이스 신호**. `interface BlackjackEventListener { fun onStartFirstDrawn(); fun onFirstDrawn(); ... }`. *EventListener 패턴*.
+
+### 3. `Blackjack(deck)` — 덱 보유, 플레이어는 start() 인자
+
+```kotlin
+class Blackjack(private val deck: CardDeck) {
+    fun start(players: List<Player>, ...) { ... }
+}
+```
+
+리뷰어: "*하나의 블랙잭 게임에서 덱은 재사용되고있고 플레이어는 매번 새로가 준비되는 것이 어색하다고 느껴집니다.* *(게임을 두번 이상할 때 덱은 그대로 사용하고 플레이어만 변경되는가?)* *하나의 블랙잭 게임에서는 하나의 덱과 플레이어들로 이루어진 게임으로 만들어 보면 어떨까요?*"
+
+학생 자가 인정: "*블랙잭 객체를 하나 생성하고 start() 메서드를 호출할 때마다, 카드덱은 소모된 상태이고 플레이어만 새롭게 변경되는 문제가 발생하는군요..!* 블랙잭 객체 생성시 *카드덱과 플레이어를 동시에 전달받고, 해당 인자에 대해 게*..."
+
+→ **객체 생명주기 일관성**. *한 게임 = 한 인스턴스 + 덱 + 플레이어 모두 생성자*. PR #92·#114와 같은 결.
+
+### 4. `ParticipantsTest`에 *주석 처리된 테스트*
+
+```kotlin
+class ParticipantsTest {
+    // @Test
+    // fun `참여자들은 최대 8명까지 가능하다`() { ... 주석 ... }
+}
+```
+
+리뷰어: "*테스트 코드 곳곳에 이유를 알 수 없는 주석이 쳐져 있습니다. 왜일까요?*" — PR #17 (rhkrwngud445)과 같은 *주석 처리 코드 = 의도 불명*. *TODO 코멘트* 또는 *삭제*.
+
+### 5. `BetMoney : Money` 상속 — Liskov 위반 위험
+
+```kotlin
+open class Money(private val amount: Int) {
+    operator fun times(operand: Double): Money = Money((amount * operand).toInt())
+    operator fun plus(money: Money): Money = Money(amount + money.amount)
+}
+class BetMoney(amount: Int) : Money(amount) {
+    init { require(amount > 0); require(amount % 1000 == 0) }
+}
+```
+
+리뷰어: "*배팅 금액이 돈의 성격을 띄고 있어서 단순히 Money를 상속한 것으로 보입니다.* 하지만 *Money에서 제공하는 함수가 다시 Money 타입을 반환하기 때문에* 아래와 같은 상황이 발생할 수 있습니다. ```kotlin val baseBetMoney: BetMoney = BetMoney(10000); val myBetMoney: Money = baseMetMoney * (-2) // -2만원``` 즉 *Money 함수를 사용하고 나면 더이상 BetMoney 타입이 아닌 Money 타입이 되어 기존의 로직이 손상되는 결과로 이어질 수* 있습니다. *상속 대신 Composition을 이용*해 보면 어떨까요?"
+
+→ **상속 + 반환 타입 불일치 = Liskov 위반**. `BetMoney * (-2)`가 *유효한 BetMoney가 아닌 Money*. *Composition* (BetMoney가 Money를 *멤버*로 보유)이 *invariant 보호*. **상속의 깊은 함정**.
+
+### 6. `Dealer.stay()` — *상태 변경 없음*
+
+```kotlin
+class Dealer(cardState: CardState = StartState()) : Participant(...) {
+    override fun stay(): Participant = Dealer(cardState)   // ⚠ 같은 상태로 반환
+}
+```
+
+리뷰어: "*스테이 요청에 카드의 상태가 아무런 변경이 되지 않는 것 같습니다.*" — `stay()`가 *동작 동사*인데 *실제로는 상태 변경 X*. `StayState`로 *명시 전이*가 자연.
+
+### 7. `Participant.draw(card: Card): Participant` 추상 — *Dealer/Player 자율성 차이*
+
+```kotlin
+abstract class Participant(...) {
+    abstract fun draw(card: Card): Participant
+    abstract fun stay(): Participant
+    abstract fun getProfit(other: Participant): Money
+}
+```
+
+리뷰어: "*더 뽑을지 말지를 선택하는 것은 딜러와 플레이어가 각각 다른데, 이 규칙을 상태에게 전파시킬 필요는 없는 것 같습니다.* 어떤 기능을 추상화 하는가에따라 구현이 달라진다는 의미로 볼 수 있는데요. *결국 트레이드 오프의 영역*이라고 하는 부분이죠. 저는 이렇게 작성 해볼 것 같아요 ```class Dealer { override fun draw(card: Card): Participant { if (canDraw()) return copy(state = state.draw(card)) else return stay() }; fun canDraw(): Boolean { ... } }```"
+
+→ **State 패턴의 *전이 책임* 위치**: *Participant.draw가 canDraw() 확인 + draw/stay 분기*가 자연. *State에 직접 전파*하면 *State가 Dealer/Player 룰 알아야*.
+
+### 8. `Participants.onStartFirstDrawn()` callback — 외부 책임
+
+리뷰어: "*onStartFirstDrawn()은 사용하는 곳에서 처리하는 곳의 책임으로 볼 수 있지 않을까요?* ```val participants: Participants; onStartDrawn(participants); participants.drawFirst(...)```"
+
+학생: "*onStartFirstDrawn()은 인자로 참여자 객체를 넘겨주기 때문에 내부에서 직접 실행하는 것보다 외부에서 호출하도록 변경*했습니다!" — **callback 내부 호출 vs 외부 호출**. *외부 호출이 도메인 → View 의존* 회피.
+
+### 9. `Participants.getDealer()` / `getPlayers()` 함수 vs 프로퍼티
+
+```kotlin
+class Participants(private val participants: List<Participant>) {
+    fun getDealer(): Dealer = participants.first() as Dealer
+    fun getPlayers(): List<Player> = participants.subList(1, ...).map { it as Player }
+}
+```
+
+리뷰어: "*Participants 객체가 딜러 1명, 그리고 플레이어들을 가지고 있는 개념이 명확하다면 위 값들을 매번 함수로 호출하는 것이 아닌, 프로퍼티로 만들어서 가지고 있어도 좋을 듯 합니다.* 또한 *지금 생성자에서 딜러를 포함해 2 명 ~*..." — *getXxx() 매번 캐스팅*보다 *생성자에서 분리 + 프로퍼티*. PR #63·#28과 같은 결.
+
+### 10. `Participants.takePlayerTurn`의 *do-while* 구조
+
+```kotlin
+do {
+    val choice = participant.needToDraw()
+    if (choice) result = result.draw(...)
+} while (...)
+```
+
+리뷰어: "*do, while 문을 이용하는 것 보다는 while 문 하나로 해결할 수 없을지? 생각해보고 적용하는게 좋습니다.* *while이 조건을 먼저 확인하기 때문에 코드 이해에도 도움이 되고 가독성도 좋습니다* ```var result: Participant = participant ...```"
+
+학생: "*canDraw()를 내부에서 호출하도록 하고, do-while 대신 while문으로 변경*하였습니다! 대신 *canDraw() 마다 플레이어는 람다를 호출하기 때문에 while 조건에 `result.isRunning`를 추가하여 플레이어가 아직 카드 뽑기를 실행중인지 체크하도*..." — **`do-while < while`** — *조건 먼저 확인*이 가독성. 학생 후속 반영 + *람다 호출 비용*까지 고려.
+
+### 11. `Participants.needToDraw()` 호출 위치 — Player 내부?
+
+리뷰어: "*needToDraw()를 참가자들에서 호출하는 것이 아닌 플레이어 객체에서 직접 호출해야 하지 않을까요?* 앞서 남겨드린 *canDraw()와 draw() 함수의 개선 피드백과 같이 생각*해보세요"
+
+학생: "*다시 생각해보니 Player가 가지고 있는 함수인만큼 내부에서 호출하는 것이 좋을 것 같습니다!*" — **Tell-Don't-Ask**. *플레이어가 자기 의지를 묻는 callback*은 *Player 내부*. PR #20과 같은 결.
+
+### 12. `Participants.calculateProfit(participants)` — Participant 메서드로
+
+```kotlin
+class Participants { fun calculateProfit(): Map<Participant, Money> { ... } }
+```
+
+리뷰어: "*이 기능도 잘 돌려보면 Participant에서 구현할 수 있을 것 같네요!?* `abstract class Participant { abstract fun getProfit(others: List<Participant>: Money }`" — *수익 계산*도 *참가자 자율 = Tell-Don't-Ask*. 1대다 확장.
+
+### 13. `BustState.earningRate = 1.0`
+
+```kotlin
+class BustState : FinishedState() { override val earningRate: Double = 1.0 }
+```
+
+리뷰어: "*earningRate를 음수로 생각해볼 수 도 있지 않을까요?*" — **Bust = 패배 = 음수 earningRate**. *호출자가 *-1 곱셈*하는 트릭*보다 *enum/state에 음수*가 자연. PR #135·#119와 같은 결.
+
+### 14. `FinishedState`에서 *draw/stay 시 IllegalStateException*
+
+```kotlin
+abstract class FinishedState : CardState {
+    override fun draw(card: Card): CardState = throw IllegalStateException(...)
+    override fun stay(): CardState = throw IllegalStateException(...)
+}
+```
+
+리뷰어: "*종료 상태에서 카드를 더 뽑거나 스테이를 하는 것이 충분히 논리적으로 가능할 수 있지 않을까요?* *비즈니스 상태를 가급적 오류를 발생시키기 보다는, 논리적으로 계산을 하는 것도 방법*입니다. `override fun draw(card: Card): CardState = this  // 변화 없음`"
+
+학생: "*확실히 오류를 발생시키지 않는 것이 더 안전할 것 같습니다!*" — **State 패턴 + 종료 상태에서의 *no-op*** = *invariant 깨짐 회피 + 호출자 코드 단순*. PR #34와 같은 결.
+
+### 15. `HitState.draw`가 *무조건 BustState로*
+
+```kotlin
+class HitState : RunningState() {
+    override fun draw(card: Card): CardState = BustState(cards + card)   // ⚠ 항상 Bust?
+}
+```
+
+리뷰어: "*히트 상태에서는 스테이 혹은 버스트로 넘어갈 수 있지 않을까요?* *다음 상태가 무조건 버스트가 되는 것이 맞을까요?* *다음 상태라는 추상 함수로 정의*하는 것이 맞을까? 를 생각 해보세요"
+
+학생 자가 답변: "*제가 잘 이해한지 모르겠습니다만..*🥲 > *히트 상태에서는 스테이 혹은 버스트로 넘어갈 수 있지 않을까요?* 우선 *히트 상태에서는 스테이와 버스트가 될 수 있습니다*. 플레이어라면 n을 입력했을 때, *딜러라면 17점 이상일*..." — **State 전이의 의미 토론**. *HitState.draw* 이후 *점수에 따라 다음 상태 결정* (RunningState 유지 또는 BustState로). 무조건 BustState는 *조기 종료*.
+
+### 16. `RunningState.draw(card)` mutable cards 위험
+
+```kotlin
+abstract class RunningState : CardState {
+    protected val cards: MutableList<Card>   // ⚠ mutable
+    override fun draw(card: Card): CardState {
+        cards.add(card)
+        return ...
+    }
+}
+```
+
+리뷰어: "*cards 객체가 내부적으로 가변 컬렉션으로 이루어져 있기 때문에, 아래와 같은 시나리오가 생길 수 있어요.* ```val currentState: RunningState // 2장; val nextState: CardState = currentState.draw(card) // 3장; // 이 시점에, currentState 는 카드를*..."
+
+학생: "*아.. 불변을 구현하고 싶었지만 이런 문제가 있었군요..! 카드 목록에 add() 하면 새로운 카드 목록을 반환하도록 변경해보겠습니다!*" — **State 패턴 + immutable cards = 정확한 패턴**. *draw → 새 RunningState 반환*. `currentState`는 *불변 상태*.
+
+### 17. `HitState`와 `StayState`의 *2장 invariant*
+
+리뷰어: "*스테이 상태에도 동일하게 최소 2장의 카드를 가져야 하지 않을까요?*"
+
+학생: "*Stay 상태에서는 FinishedState를 상속하고 있어서 `최소 2장의 카드를 갖는다` 라는 조건을 검증하고 있습니다!*" — **상속을 통한 invariant 검증 공유** — *Hit/Stay 둘 다 적용*은 다른 메커니즘.
+
+### 18. `StayState.matchWith`의 *if/else if*
+
+```kotlin
+if (other is BustState) return WIN
+else if (other is StayState) { ... }
+else { ... }
+```
+
+리뷰어: "*if, else if 구문 대신 when 조건을 사용 해보세요*" — Kotlin 컨벤션. PR #33·#34와 같은 결.
+
+## 리뷰어 의견 요지
+
+- ***확장 함수 과잉 (`isGreaterThan`) = 기본 연산자가 친숙***.
+- ***5개 callback = Listener 인터페이스 신호***.
+- ***Blackjack 객체 생명주기 = 덱 + 플레이어 모두 생성자***.
+- ***주석 처리 테스트 = 의도 불명***.
+- ***`BetMoney : Money` 상속 = Liskov 위반*** — Composition.
+- ***`Dealer.stay()` 상태 변경 없음 = StayState 명시 전이***.
+- ***`draw(card): Participant` 추상은 Dealer/Player 자율성 다름*** — Participant 분기 + canDraw().
+- ***callback 내부 호출 < 외부 호출 (도메인 → View 의존 회피)***.
+- ***`getDealer()` 함수 매번 캐스팅 < 생성자 분리 + 프로퍼티***.
+- ***do-while < while*** (조건 먼저 확인).
+- ***needToDraw 호출 위치 = Player 내부 (Tell-Don't-Ask)***.
+- ***calculateProfit = Participant 메서드 (1대다 확장)***.
+- ***Bust earningRate = -1.0 (음수)***.
+- ***FinishedState에서 IllegalStateException < no-op***.
+- ***HitState.draw = 무조건 Bust X = 점수에 따라 분기***.
+- ***RunningState mutable cards = stale 위험 = immutable 새 인스턴스***.
+- ***`if/else if` < `when`***.
+
+## 대표 인용
+
+> 이 함수를 사용하는 것과 *Int > Int 를 비교하는 것중 무엇이 더 개발자에게 친숙*할까요?
+> — @laco-dev on `Extensions.kt`
+
+> 출력에 대해서 요구사항이 변경될 때 마다 start() 함수의 *파라미터로 많은 값을 넘겨야 할 수 있습니다.* 이와 관련된 *리스너 인터페이스를 만들어서 전달*해 보는건 어떨까요?
+> — @laco-dev on `BlackjackController.kt`
+
+> 배팅 금액이 돈의 성격을 띄고 있어서 단순히 Money를 상속한 것으로 보입니다. 하지만 *Money에서 제공하는 함수가 다시 Money 타입을 반환하기 때문에* [...] *즉 Money 함수를 사용하고 나면 더이상 BetMoney 타입이 아닌 Money 타입이 되어 기존의 로직이 손상*되는 결과로 이어질 수 있습니다. *상속 대신 Composition을 이용*해 보면 어떨까요?
+> — @laco-dev on `BetMoney.kt`
+
+> cards 객체가 내부적으로 *가변 컬렉션으로 이루어져 있기 때문에*, 아래와 같은 시나리오가 생길 수 있어요. `val nextState: CardState = currentState.draw(card) // 3장; // 이 시점에, currentState 는 카드를`...
+> — @laco-dev on `RunningState.kt`
+
+> 종료 상태에서 카드를 더 뽑거나 스테이를 하는 것이 *충분히 논리적으로 가능할 수 있지 않을까요?* *비즈니스 상태를 가급적 오류를 발생시키기 보다는, 논리적으로 계산을 하는 것도 방법*입니다.
+> — @laco-dev on `FinishedState.kt`
+
+## 얻은 교훈
+
+- ***확장 함수 과잉 (`Int.isGreaterThan`) = 기본 연산자가 친숙*** — *DSL 효과 없으면 과잉*.
+- ***5개 callback = Listener 인터페이스 신호*** — *EventListener 패턴*.
+- ***Blackjack 객체 생명주기 = 덱 + 플레이어 모두 생성자*** — *한 게임 = 한 인스턴스*.
+- ***주석 처리 테스트 = 의도 불명*** — *TODO 코멘트* 또는 *삭제*. PR #17·#8과 같은 결.
+- ***`BetMoney : Money` 상속 = 반환 타입 불일치로 Liskov 위반*** — *상속의 깊은 함정*. **Composition으로 invariant 보호**.
+- ***`Dealer.stay()` 상태 변경 없음 = State 패턴의 명시 전이*** — *StayState로 명시*.
+- ***State 패턴 + immutable cards = 정확한 패턴*** — *draw → 새 인스턴스 반환*. *currentState 불변* 보장.
+- ***FinishedState에서 IllegalStateException < no-op*** — *비즈니스 상태 = 호출 가능한 모든 메서드는 논리적 결과 반환*. *예외는 invariant 깨짐* 시에만.
+- ***HitState.draw = 점수에 따라 RunningState/BustState 분기*** — *조기 종료 X*.
+- ***Bust earningRate = -1.0 음수*** — *호출자가 곱셈 트릭* X. 의미 명시.
+- ***do-while < while*** — *조건 먼저 확인*이 가독성.
+- ***`needToDraw` callback = Player 내부 호출 (Tell-Don't-Ask)***.
+- ***calculateProfit = Participant.getProfit(others) 메서드 (1대다 확장)*** — PR #24와 같은 결.
+- ***`getDealer()` 매번 캐스팅 = 생성자 분리 + 프로퍼티***.
+- ***callback 내부 호출 vs 외부 호출 = 도메인 → View 의존 회피***.
+- ***`if/else if` < `when` Kotlin 컨벤션***.

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

@@ -0,0 +1,305 @@
+# PR #115 — [블랙잭 1단계] 토바에 미션
+
+- **Reviewee:** [@tobae-time](https://github.com/tobae-time) (토바에) — 2025 모바일 안드로이드 7기 코호트
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/115
+- **단계:** 1단계
+- **리뷰어:** [@laco-dev](https://github.com/laco-dev) (페로로) — 누적 14명 reviewer
+- **라인 코멘트:** 15 스레드 — *학생 자가 `Rule` god-object 시도 + reviewer 강한 반대 메타 정점 (4 thread 동일 패턴 반복) + 현실 세계 vs 객체지향 세계 메타포 충돌 어휘 + 패키지로 enum/data class 종류 구분 비판 + 출력 표현 UI 책임 + 참가자 vs 딜러 vs 플레이어 일반화 + 빌더 필수 속성 vs 미초기화 위험 + Deck mutable 직접 접근 시나리오 + 점진적 테스트 묘사*
+- **신규 reviewee** (2025 모바일 안드로이드 7기). PR 본문에 *셀프 체크리스트 + 집중 리뷰 요청* (네이밍).
+- **메타 케이스 정점**: 학생 자가 *`Rule` 객체 시도* → reviewer *"모든 메서드 Rule.canX() 변환 가능 = god-object"* 4 thread 반복 비판 + *"쎄게 피드백 양해부탁드립니다"* 메타 어휘.
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 셀프 체크리스트 + 집중 리뷰 요청
+
+PR 본문에 7개 체크리스트 (기능/테스트/이전 피드백/스타일/요구사항/README) 모두 체크 + *"네이밍 읽기 어떠신지 궁금합니다"* 집중 리뷰 요청.
+
+→ **`pr-self-checklist-vocabulary`** + **`pr-focused-review-request`** = PR #144 (m6z1 셀프 코드 리뷰) 결 합류.
+
+### 2. 학생 자가 답변 매우 적극적 + 커밋 SHA 첨부
+
+15 thread 중 **10 thread 학생 자가 답변** + 모두 *커밋 SHA + 변경 사항 인용* 첨부. *학습 가시화 정점*.
+
+### 3. HandTest 점진적 묘사 칭찬 (Thread 6)
+
+reviewer:
+
+> *"카드뭉치에 대한 기능과 테스트를 역할에 맞게 잘 구현해주셨습니다. 👍🏻"*
+
+## 못한 점 (설계 관점) — 핵심: `Rule` god-object 메타
+
+### 1. `Rule` 객체 도입 — god-object 신규 모범 사례 (Thread 11·12·13·14, 4 thread 반복)
+
+#### 학생 자가 시도 + 의문
+
+PR 첫 답변에서 학생 자가 답변:
+
+> *"안녕하세요, 페로로! 결과를 만드는 것이 참가자 객체의 역할 보다는 블랙잭 규칙의 역할이라는 생각을 하게 되어 Rule이라는 객체를 만들었습니다. **블랙잭 규칙에 관련된 행위를 모으다 보니, Rule이 너무 커진 것 같습니다.** 이전에는 컨트롤러에 있던 비즈니스 로직(딜러 결과 함수)을 옮겨 왔지만 딜러와 플레이어가 각각 들고 있는 편이 더 좋았을지 고민됩니다."*
+
+#### Thread 11 (Rule.kt) — reviewer 강한 반대
+
+```kotlin
+object Rule {
+    fun ...(...) { ... }  // 결과 계산
+}
+```
+
+reviewer:
+
+> *"왜 참가자의 규칙이 아니라고 생각하는지 궁금합니다. **현실세계라면 블랙잭 게임에서의 규칙이지만, 객체지향 세계에서 객체는 모두 스스로 일을 합니다.** 또한 객체들은 서로 긴밀하게 협력을 통해 필요한 정보를 요청하는데 Rule은 그 역할을 다 하고 있다고 보시나요?"*
+
+#### Thread 12·13 (Players.kt + Participant.kt) — 반복 비판
+
+reviewer Thread 12: *"토바에가 제시한 방향에 따르면 **이런것도 전부 Rule 아닌가요?**"*
+
+reviewer Thread 13:
+
+> *"Rule 논리대로면 이것도 다 Rule입니다.*
+> *`Rule.canDealerDraw()`*
+> *`Rule.canPlayerDraw()`*"*
+
+→ **MCP 룰 `rule-as-god-object-anti-pattern`** ⭐⭐⭐ **신규 정점**:
+- 학생이 *모든 도메인 행위*를 `Rule` 클래스로 모음 = *god-object 변형*.
+- reviewer 강한 어휘 — *"모든 메서드를 `Rule.canX()` 형태로 만들 수 있다 = god-object 시그널"*.
+- 책임 분배 = *참가자가 자기 카드로 결과 도출 + 메시지 협력*.
+
+#### Thread 14 (OutputView.kt) — 출력 규칙도 Rule?
+
+```
+> 최초 공개시 딜러는 1장, 플레이어는 2장을 노출한다.
+```
+
+reviewer:
+
+> *"이는 게임에서 결정한 규칙으로 명확한 비즈니스 로직이지 않을까요? 이것을 UI에서 결정하는 것이 게임의 규칙인지? UI의 규칙인지? 고민할 필요가 있습니다. (...) **하지만 이것도 Rule에 구현을 해야 할까요...?**"*
+
+→ **`Rule god-object 반복 시그널 — 모든 도메인을 Rule로 모으면 다음 규칙도 Rule이 됨`** ⭐⭐⭐.
+
+#### reviewer 최종 메타 어휘 — *"쎄게 피드백 양해"*
+
+reviewer 마지막 review:
+
+> *"지금까지 3개의 미션을 통해 객체가 무엇인지, 스스로 일을 하거나 기능을 작게 나누어 객체의 책임을 분리하는 등 여러가지 연습을 해왔는데 그걸 모두 걷어차고 클래스 하나에 다 몰아 넣은 이유를 잘 모르겠어요.*
+>
+> *모든 도메인 클래스를 게임과 의존하지 않도록 만들 의도였으면 blackjack 패키지도 필요 없었습니다. blackjack.Rule만 유의미하지 나머지는 블랙잭이랑 관계 없으니까요.*
+>
+> *한편으로는 **왜 블랙잭 규칙이 유일하다고 보시는지도 고민해보셨으면 좋겠어요. 규칙의 세부사항은 언제나 바뀔 가능성이 있지 않을까요?***
+>
+> *시간이 지체되어서 1단계는 마무리 하고 2단계에서 다시 보도록 하겠습니다.*
+>
+> ***힘드시겠지만, 그동안 학습한 경험이 아쉬워서 조금 쎄게 피드백을 드린 점 양해부탁드립니다.***"*
+
+→ **MCP 룰 `reviewer-strong-feedback-apology-meta`** ⭐⭐⭐ **신규** — *피드백 강도 + 학생 학습 경험 아쉬움 + 양해 표현*. PR #106 (말리빈 *권력 자제*) 결의 *피드백 강도 메타* 다른 축 (`자제` vs `쎄게 + 양해`).
+
+→ **MCP 룰 `rule-uniqueness-assumption-question`** ⭐⭐ — *"왜 규칙이 유일하다고 보시는지" — 규칙의 변경 가능성 시그널*.
+
+→ **MCP `oh-my-oop` 핵심 가치 메타 어휘 정점** — *현실세계 메타포 vs 객체지향 세계 책임 분배 충돌*.
+
+학생 자가 답변 (Thread 7):
+
+> *"결과를 내는 것은 블랙잭 룰에 의한 것이고, 룰이 바뀌었을 때 참가자에서 변경하는 것보다 블랙잭 규칙을 찾아 변경하는 것이 적절하다고 생각하여 변경하였습니다.*
+> *+) 7a55ba918b73e04563816f36f10d5b24c4b3c5f9 **블랙잭 규칙은 유일하게 존재하는 개념이라고 보고 object로 변경하였습니다!**"*
+
+→ **학생 자가 *유일성 + object* 추가 시도 (그러나 reviewer 강한 거부 후)** = 학습 시간성 메타.
+
+### 2. enum vs data class 패키지 구분 비판 (Thread 0)
+
+```kotlin
+// 패키지 구조
+blackjack/enums/Action.kt
+blackjack/enums/Suit.kt
+blackjack/enums/Result.kt
+```
+
+reviewer:
+
+> *"만약 Action 객체가 enum class가 아닌 data class가 된다면 패키지가 바뀌어야 할까요? **객체의 타입은 상황에 따라 달라질 수 있습니다. 그렇기 때문에 특정 종류를 패키지로 구분하는 것은 좋지 않은 방법입니다.**"*
+
+→ **MCP 룰 `package-by-type-anti-pattern`** ⭐⭐ 신규 — *enum/data class 등 *타입 종류*로 패키지 분리 = 변경 시 패키지 이동 필요 = 잘못된 분리*. PR #80 (util-package-definition) 결의 *패키지 분류 기준* 다른 축.
+
+### 3. Suit `♥` 출력 = UI 책임 (Thread 1)
+
+```kotlin
+enum class Suit(val display: String) {
+    HEART("하트"), ...
+}
+```
+
+reviewer:
+
+> *"만약 하트를 ❤️이렇게 출력해달라고 한다면. 우리는 도메인 모델을 수정해야 할까요? 혹은 문자가 아닌 그림으로 나타내달라고 하면 어떻게 해야 할까요?"*
+
+→ **출력 표현 = UI 책임 (도메인 수정 필요 X)** = 누적 다수 (PR #15 다국어 어휘 + PR #130 medAndro 안드로이드 리소스).
+
+### 4. 승부 결과 = UI 관심사 (Thread 2)
+
+```kotlin
+enum class Result(val display: String) {
+    WIN("승"), LOSE("패"), DRAW("무")
+}
+```
+
+reviewer: *"승부 결과 또한, 어떻게 출력될지를 결정하는 것은 UI의 관심사로 보입니다 😓"*
+
+→ **enum 출력 문자열 = UI 책임** = 누적 다수.
+
+### 5. 결과 도출 책임 = 참가자 vs Rule (Thread 3·7)
+
+reviewer Thread 3:
+
+> *"블랙잭 규칙으로 보면, 21점이 넘는다거나 하면 무조건 패배가 됩니다. 참가자 입장에서 승부가 벌어지고 있는데 단순히 점수만으로 추가로 결정하기에는 로직이 분산되어 있는 느낌이 들기도 합니다. **가령 점수가 높더라도 질 수도 있으니까요.**"*
+
+reviewer Thread 7:
+
+> *"승부를 벌이는 것은 플레이어 vs 딜러가 아니더라도 **참가자끼리라면 누구라도 결과를 만들어 낼 수 있지 않을까요?** 그렇다면 참가자 객체가 할 역할로 볼 수도 있지 않나요?*
+> *> 딜러 vs 플레이어*
+> *플레이어 vs 딜러*
+> *플레이어 vs 플레이어*"*
+
+→ **참가자 vs 참가자 일반화** = PR #148·#151·#49·#132 결 합류 누적 5+ PR.
+
+→ **점수만으로 승부 결정 ≠ 블랙잭 규칙 (21점 초과 = 패)** ⭐⭐ — *도메인 룰 정확성*. PR #19·#125 (블랙잭 룰 오해) 결.
+
+### 6. Deck 유일성 + static 결합 위험 (Thread 4·5·10)
+
+```kotlin
+// Deck.kt - 모든 곳에서 접근 가능
+object Deck { val cards = mutableListOf(...) }
+```
+
+reviewer Thread 4: *"모든 게임에 덱이 유일하게 존재하는 개념이라고 봐도 될까요? 그렇다면 여기저기서 덱에 접근하면 참사가 벌어지지는 않을까요?"*
+
+학생 자가 답변:
+
+> *"덱이 유일하게 존재하는 개념보다는 게임이 시작할 때마다 새로운 덱을 사용하게 하고 덱이 필요한 곳에 주입하는 것이 좋을 것 같습니다."*
+
+→ **학생 자가 답변 — *유일성 가정 거부 + DI*** ⭐⭐ 학습 모범.
+
+reviewer Thread 10 (시나리오 예시):
+
+```kotlin
+val deck = Deck.create()
+deck.cards.remove()
+deck.cards.remove()
+deck.cards.clear()
+deck.pick()
+deck.cards.remove()
+deck.pick()
+deck.cards.remove()
+```
+
+reviewer: *"아래 코드는 어떤 문제가 있나요?"*
+
+→ **`mutable-collection-direct-access-scenario`** = **MCP 룰 후보** ⭐⭐ — *외부 mutable 직접 접근 시나리오 예시 + 학생 자가 진단*. PR #22 (`static-mutable-collection-unsafe`) 결.
+
+→ **테스트 가능성 (Thread 5)**: *"덱에서 카드를 한장 뽑으면 마지막 카드가 나온다 — 기본적인 기능에 대한 테스트도 누락"* = 누적 다수.
+
+### 7. 빌더 필수 속성 + `lateinit` 위험 (Thread 9)
+
+```kotlin
+class PersonBuilder {
+    lateinit var name: String
+    fun name(v: String) { name = v }
+    fun build() = Person(name)
+}
+```
+
+reviewer:
+
+> *"Builder의 특징은 선택적으로 속성을 부여하는 것 일텐데, name을 호출하지 않고 build() 하면 어떤 문제가 생기나요? 어떻게 해결해야 할까요? **\"호출하지 않으면 이름은 빈값이다\" 라는 답변은 아니길 바랍니다..** 힌트는 이름은 필수라는 점입니다."*
+
+학생 자가 답변:
+
+> *"이름 없이 build() 했을 때, 해당 오류 메세지 확인했습니다!*
+> *`Exception in thread \"main\" kotlin.UninitializedPropertyAccessException: lateinit property name has not been initialized`*
+> ***생성자로 이름을 받게 하도록 변경하였습니다.**"*
+
+→ **`builder-required-property-as-constructor`** = **MCP 룰 후보** ⭐⭐ — *Builder = 선택적 속성 / 필수 속성 = 생성자*. PR #38 (`lateinit` 위험) 결 합류 누적 2 PR → ***`lateinit` 위험 어휘*** ⭐⭐⭐ 강화.
+
+→ **`reviewer-hint-vocabulary`** — *"힌트는 X"* = 학생 사고 유도 어휘.
+
+### 8. 점진적 테스트 묘사 (Thread 6)
+
+reviewer:
+
+> *"디테일하게 들어가본다면, 왜 Ace 한장이 있는데 점수가 다른지에 대한 묘사를 점진적으로 풀어주면 더욱 좋습니다.*
+> *> 퀸 한장은 10점이다.*
+> *> 에이스 카드가 포함되어 있을 때, 다른 카드의 합이 11점 이하면 보너스 점수 10점을 획득한다.*
+> *> 에이스 카드가 포함되어 있을 때, 다른 카드의 합이 11점을 초과하면 총 보너스 점수가 없다."*
+
+학생 자가 답변: *"점진적인 묘사가 이해하기 쉬운 것 같아서 테스트에 반영하였습니다."*
+
+→ **`test-narrative-incremental-build`** ⭐⭐ — *기본 케이스 → 추가 조건 → 경계 조건*. PR #109 (BDD given-when-then) 결 합류.
+
+### 9. Dealer canDraw — static Deck 결합 (Thread 8)
+
+```kotlin
+// Dealer.kt - Deck.shared 결합
+fun draw() { cards.add(Deck.pop()) }
+```
+
+reviewer 코드 제안:
+
+```kotlin
+val participant: Participant
+if (participant.canDraw()) { ... }
+// 딜러는 16점 이하라면 항상 받지만, 플레이어는?
+```
+
+→ **`can-draw-vs-blind-draw`** ⭐⭐ — *카드 받기 전 받을 수 있는지 판단* + 딜러/플레이어 다형성 어휘. PR #151 (`canHit` vs `isBust` 부울 의미) 결.
+
+## 대표 인용
+
+> [laco-dev Thread 11]
+> *"현실세계라면 블랙잭 게임에서의 규칙이지만, 객체지향 세계에서 객체는 모두 스스로 일을 합니다."*
+
+→ **현실 세계 vs OOP 세계 메타포 충돌 어휘 정점**.
+
+> [laco-dev Thread 13]
+> *"Rule 논리대로면 이것도 다 Rule입니다. Rule.canDealerDraw(), Rule.canPlayerDraw()"*
+
+→ **Rule god-object 반복 시그널 어휘**.
+
+> [laco-dev 최종 review]
+> *"왜 블랙잭 규칙이 유일하다고 보시는지도 고민해보셨으면 좋겠어요. 규칙의 세부사항은 언제나 바뀔 가능성이 있지 않을까요?"*
+
+→ **규칙 유일성 가정 거부 어휘**.
+
+> [laco-dev 최종 review]
+> *"힘드시겠지만, 그동안 학습한 경험이 아쉬워서 조금 쎄게 피드백을 드린 점 양해부탁드립니다."*
+
+→ **reviewer 강한 피드백 양해 메타 어휘**.
+
+> [tobae-time 최초 자가 답변]
+> *"블랙잭 규칙에 관련된 행위를 모으다 보니, Rule이 너무 커진 것 같습니다."*
+
+→ **학생 자가 god-object 인지 메타 어휘**.
+
+> [laco-dev Thread 9]
+> *"\"호출하지 않으면 이름은 빈값이다\" 라는 답변은 아니길 바랍니다.."*
+
+→ **reviewer 답변 유도 + 부정 가이드 어휘**.
+
+> [laco-dev Thread 0]
+> *"객체의 타입은 상황에 따라 달라질 수 있습니다. 그렇기 때문에 특정 종류를 패키지로 구분하는 것은 좋지 않은 방법입니다."*
+
+→ **패키지 = 타입 종류로 분리 X 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **`Rule` god-object 신규 모범 사례** — **MCP 룰 `rule-as-god-object-anti-pattern` 후보** ⭐⭐⭐ 신규 정점.
+2. **reviewer 강한 피드백 양해 메타** — **MCP 룰 `reviewer-strong-feedback-apology-meta` 후보** ⭐⭐⭐ 신규.
+3. **현실 세계 vs OOP 세계 메타포 충돌** — *MCP `oh-my-oop` 핵심 가치 메타 어휘*.
+4. **규칙 유일성 가정 거부** — **MCP 룰 `rule-uniqueness-assumption-question` 후보** ⭐⭐.
+5. **패키지 = 타입 종류 분리 X** — **MCP 룰 `package-by-type-anti-pattern` 후보** ⭐⭐.
+6. **빌더 필수 속성 = 생성자 + `lateinit` 위험 누적 2 PR** — **MCP 룰 `builder-required-property-as-constructor` + `lateinit-initialization-checking-burden` 후보** ⭐⭐⭐.
+7. **외부 mutable 직접 접근 시나리오 진단** — **MCP 룰 `mutable-collection-direct-access-scenario` 후보** ⭐⭐.
+8. **점진적 테스트 묘사 (기본 → 조건 → 경계)** — **MCP 룰 `test-narrative-incremental-build` 후보** ⭐⭐.
+9. **참가자 vs 참가자 일반화** = 누적 5+ PR.
+10. **출력 표현 = UI 책임** = 누적 다수.
+
+## 메타 노트
+
+- **tobae-time 2025 모바일 안드로이드 7기 코호트** — PR #115 1단계로 합류. PR #142 (doabletuple)·PR #143 (medAndro)·PR #109 (cucumber99)·PR #118 (jiyuneel)·PR #113 (gahyunkim) 외 다수 결의 *2025 코호트 누적 ≥12 PR*.
+- **메타 케이스 6번째 — Rule god-object 학생 자가 시도 → reviewer 4 thread 반복 비판 → 강한 양해 메타** (학습 시간성 메타와 다른 *학습 *방향성* 충돌* 메타).
+- **`Rule.kt` 같은 god-object 변형 — MCP validate 룰 후보 1순위**: lotto의 `god-object` 룰을 *클래스명 기반 god-object* (Rule/Game/Manager 등) 패턴 변형으로 확장 가능. evidence = laco-dev *"모든 메서드를 Rule.canX() 변환 가능"* 어휘.