oh-my-oop 0.2.0

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

@@ -0,0 +1,281 @@
+# PR #63 — [블랙잭 1단계] 누누 미션
+
+- **Reviewee:** [@jinuemong](https://github.com/jinuemong)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/63
+- **단계:** 1단계 (페어 — 클래스 다이어그램 동봉)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 20 / 리뷰이 10)
+
+## 잘한 점 (설계 관점)
+
+- **`State` sealed class — `Action.Hit` / `Finish.Stay`·`BlackJack`·`Bust`** — 상태별 분기 폭증 회피.
+- **`HandCard` + `State` 묶음으로 `BlackJack` 객체 도입** — 손패와 상태를 *Player*에서 분리. (의미는 별도 토론 — 못한 점 §3.)
+- **`Result` enum + win/draw/lose 누적** — `MutableMap<Result, Int>`로 딜러 결과 집계.
+- **`Participants` 일급 컬렉션 + `init` invariant** — 최대 인원, 딜러 1명 등을 생성 시 차단.
+- **클래스 다이어그램을 PR 본문에 첨부** — 페어 토론의 가시화 (리뷰어가 다이어그램을 기반으로 질문 던짐).
+- **`Ace` 1↔11 동적 보정 (`changeAceScore`)** — 21 초과 시 ACE를 1점으로 차감.
+
+## 못한 점 (설계 관점)
+
+### 1. `main()`이 게임 시나리오 결정자
+
+```kotlin
+fun main() {
+    val blackJackController = BlackJackController()
+    blackJackController.apply {
+        startGameFlow()
+        playGame()
+        calculateResult()
+        showResult()
+    }
+}
+```
+
+리뷰어: "컨트롤러가 블랙잭 게임이라는 하나의 프로그램으로 본다면 하나의 함수 대신 여러개의 함수로 분리된 이유는 무엇인가요?" → "블랙잭 게임의 시나리오를 결정하는 것이 현재는 Main 클래스입니다." — *시나리오*는 Controller의 책임. `main()`은 *진입점*만.
+
+### 2. `Controller`의 `lateinit var` 멤버 — 호출 순서 의존
+
+```kotlin
+class BlackJackController {
+    private val gameManager = GameManager()
+    private lateinit var participants: Participants
+    private lateinit var gameResult: GameResult
+
+    fun startGameFlow() { participants = ...; gameManager.setGame(participants) }
+    fun playGame() { participants.getAlivePlayers()... }       // startGameFlow() 호출 안 하면 lateinit 예외
+    fun calculateResult() { gameResult = GameResult(...) }
+    fun showResult() { gameResult.getDealerResults()... }
+}
+```
+
+리뷰어: "참가자와 게임 결과를 멤버 프로퍼티로 만드는 것은 지역 변수로 만드는 것과 어떤 장단점이 있나요?" / "하나의 컨트롤러 인스턴스에서 여러번의 게임이 진행 될 경우 발생할 수 있는 문제가 걱정됩니다. > Controller의 startGameFlow()를 가장 먼저 호출하지 않으면 어떻게 될까?" — *호출 순서 invariant*가 코드로 보호되지 않음.
+
+### 3. `BlackJack` 객체의 의미 모호 — `HandCard + State` 묶음
+
+```kotlin
+class BlackJack {
+    private val handCard = HandCard()
+    private var _state: State = State.Action.Hit
+    val state: State get() = _state
+    fun addCard(card: Card) { handCard.addCard(card); changeState() }
+    fun changeState() { ... }       // public — 테스트용 노출
+}
+class Participant(val name: String) {
+    val blackJack = BlackJack()
+    ...
+}
+```
+
+리뷰어: "참가자가 가지고 있는 블랙잭이라는 객체는 무슨 역할을 하기를 기대할까요? 다이어그램 상으로는 `블랙잭 == 상태` 라는 판단으로 보이지만, 이 블랙잭 객체는 무엇을 하고 싶은 것인지 잘 모르겠어요. > 블랙잭 상태도 있는데 블랙잭 객체는 뭐지? 🤔"
+
+학생 자가 설명: "블랙잭은 상태와 손패(사용자가 가지고 있는 카드 리스트)를 나타냅니다. 처음에 플레이어별로 손패와 state를 가지게 하려했지만, 관심사를 분리하고 확장성을 고려, 생성자의 수를 2로 제한이라는 규칙으로 고민끝에 하나의 객체를 더 만들게 되었습니다." — *생성자 수 2 제한*이라는 형식 규칙을 위해 *의미 없는 묶음 객체*가 탄생. *형식 규칙*과 *도메인 의미*가 충돌하면 의미가 우선.
+
+### 4. `Card`에 `private val` + `getCardDenomination()` 함수형 getter
+
+```kotlin
+class Card(
+    private val denomination: Denomination,
+    private val suit: Suit,
+) {
+    fun getCardDenomination(): Denomination = denomination
+    fun getCardSuit(): Suit = suit
+}
+```
+
+리뷰어: "프로퍼티의 접근자를 public으로 하는 것과, 함수로 getter()를 만드는 것에 차이가 있나요?"
+학생: "좀 더 많은 것을 제어할 수 있다고 생각했습니다. 단순히 getter()로 만드는 것은 함수를 추가적으로 호출하기 때문에 최적의 선택이라고 생각하지는 않습니다. 2단계 미션을 고려하여 추가적인 로직이 있을 것이라고 생각하였고, getter() 사용을 습관화(?)하려 하였습니다." — Kotlin의 `val`은 *이미 getter*이며 *나중에 커스텀 getter로 대체 가능*. Java 습관을 그대로 가져온 함수형 getter.
+
+### 5. `CardDeck`이 `Set<Card>` — "한 장씩 뽑기" 개념과 부정합
+
+```kotlin
+class CardDeck {
+    private var cards: Set<Card> = ... .shuffled().toSet()
+    fun draw(): Card {
+        val popCard = cards.take(DRAW_COUNT).firstOrNull() ?: throw IllegalArgumentException(EMPTY_CARD_DECK)
+        cards -= popCard
+        return popCard
+    }
+}
+```
+
+리뷰어: "카드를 한장 씩 뽑아쓰는 것을 표현하기 위해 다른 자료구조를 사용 해 볼 수 있지 않을까요? 지금의 Set 구조는 이 개념을 나타내기에 적절하지 않아 보이네요" — `ArrayDeque`/`Stack` 또는 가변 `MutableList`로 *맨 위 카드를 뽑는다* 개념을 자료구조 자체로 표현. *셔플 후 Set으로 toSet()* 한 시점에 순서가 무의미해지므로 *항상 같은 카드*가 나올 위험.
+
+또 리뷰어: "준비된 덱이 항상 52장의 랜덤한 카드뭉치로 되어 있다면, 테스트가 어렵지 않을까요? 가령 덱에 스페이드 A 카드 1장이 들어있을 때, 카드를 뽑으면 스페이드 A다 라는 테스트는 어떻게 할 수 있을까요?" — `CardDeck`이 외부에서 주입된 카드 순서를 받을 수 있어야 *결정적 테스트* 가능.
+
+### 6. `Dealer.openFirstCard()`가 정상 흐름에서 예외 던짐
+
+```kotlin
+class Dealer(name: String = DEFAULT_DEALER_NAME) : Participant(name) {
+    fun openFirstCard(): Card =
+        getCards().firstOrNull() ?: throw IllegalArgumentException(ERROR_CARD_INDEX)
+}
+```
+
+리뷰어: "지난 로또 미션에서 오류 발생을 최대한 피하는 전략을 경험했습니다. 첫번 째 카드가 없다는 동작이 오류를 발생시키지 않도록 만들어 보면 어떨까요?" — `Dealer` 생성 직후 `setGame(participants)` 호출로 *2장 분배*가 보장된다면, *카드 분배 후*에만 `openFirstCard()`를 호출하는 흐름이 정상. 그러나 호출 시점 invariant를 깨고 예외로 보호하면 *정상 흐름에서 예외*가 발생할 위험.
+
+### 7. `Dealer.checkDealerScoreCondition()` — 함수명 모호
+
+```kotlin
+fun checkDealerScoreCondition(): Boolean = getBlackJackScore() <= MIN_HAND_CARD_SCORE
+```
+
+리뷰어: "`checkDealerScoreCondition` 라는 이름은 반환 값이 무엇인지 예측이 어려워 보입니다. `점수를 검사한다 --> true --> 뽑는다 ??` 이 의미를 나타내는 적절한 이름은 없을까요?" — `canDraw()` / `shouldHit()` / `mustHit()` — *결과를 동사로*. `check`/`condition` 같은 *검사 동작*은 *반환값과의 연관*이 끊김.
+
+### 8. `GameManager`가 가변 setter 보유 — 게임 단위 인스턴스 아님
+
+```kotlin
+class GameManager {
+    private val cardDeck = CardDeck()
+    fun setGame(participants: Participants) {
+        repeat(INIT_HAND_CARD_COUNT) {
+            participants.getParticipants().forEach { it.draw(cardDeck.draw()) }
+        }
+    }
+}
+```
+
+리뷰어: "게임 매니저가 하나의 게임을 관장한다면, 게임이 시작할 때 새로운 인스턴스가 만들어지고, 게임이 끝나면 인스턴스를 종료하는 그런 설계를 해 볼 수 있지 않을까요? `class GameManager(참가자, 딜러, 덱, ...)`" — *setter 기반 setup*은 *생성 시점의 invariant 보호*를 잃는다.
+
+### 9. `GameResult`에서 *플레이어 상태 판단*
+
+```kotlin
+private fun judgeBlackJackScore(player: Player) {
+    when (player.getBlackJackState()) {
+        is State.Finish.Bust -> addDealerWin(player)
+        is State.Finish.BlackJack -> applyBlackJackState(player)
+        is State.Finish.Stay, State.Action.Hit -> compareToResult(player)
+    }
+}
+```
+
+리뷰어: "플레이어의 상태를 판단하고 변경하는 것 또한 플레이어가 스스로 하도록 할 수 있지 않을까요?" / "마찬가지로 승부를 겨루는 것은, 게임 결과가 하는 대신 참가자가 스스로 하도록 만들어보세요. 승부를 결정하는 것은, 참가자 정보만 있다면 상대가 누구라도 상관이 없습니다. 딜러와 플레이어 / 플레이어와 플레이어 / 딜러와 딜러" — *Tell-Don't-Ask*. `player.compete(other)` 형태로.
+
+학생 자가 토론: "참가자가 죽었는지 확인은 심판의 역할이라고 생각하며, 현재 제가 설계한 객체들에서 참가자가 승부를 결정하는 역할을 하는 것이 맞는지 생각이 듭니다.." — *심판*과 *참가자*의 책임 경계는 도메인 비유에 의존. 리뷰어 입장은 *상대가 누구든 무관한 비교*는 참가자 자신의 책임. *심판*의 진짜 책임은 *룰 적용*(보너스 1.5배 등)이지 *점수 비교*가 아님.
+
+### 10. `Participants` 첫 항목 = `Dealer` invariant — 추상화 누수
+
+```kotlin
+class Participants(private val participants: List<Participant>) {
+    init {
+        require(participants.first() is Dealer) { ERROR_NOT_EXIST_DEALER }
+        require(participants.count { it is Dealer } == DEALER_COUNT) { ERROR_INVALID_DEALER_COUNT }
+    }
+    fun getDealer(): Dealer = participants.first() as Dealer
+    fun getPlayers(): List<Player> = participants.subList(1, participants.size).map { it as Player }
+}
+```
+
+리뷰어: "참가자라는 타입으로 추상화를 했다면, 1번째 항목이 딜러라는 것을 어떻게 신뢰할 수 있을까요?" — *동일 타입 컬렉션*인데 *0번 인덱스만 특별*하면 추상화 위반. `class Participants(val dealer: Dealer, val players: List<Player>)`로 두 역할을 *타입으로 분리*. `as Dealer` 다운캐스트와 인덱스 비교의 *근거*가 사라지면 컴파일러가 *0번 = Dealer* invariant를 보장.
+
+### 11. `Player.checkDuplication`이 정적 메서드
+
+```kotlin
+class Player(name: String) : Participant(name) {
+    companion object {
+        fun checkDuplication(name: String, playerNames: Set<String>) {
+            require(!playerNames.contains(name)) { ERROR_DUPLICATION_NAME }
+        }
+    }
+}
+```
+
+리뷰어: "이름이 중복되었는지 검사하는게 Player 객체의 역할일까요?" — *중복*은 *컬렉션 수준*의 invariant. `Players(names: List<String>)` 의 `init`에 두는 것이 자연.
+
+### 12. `UserDecision` enum / `UserInputValidator` — 도메인 패키지에 UI 형식
+
+```kotlin
+// blackjack/model/user/UserDecision.kt
+enum class UserDecision(private val userDecision: String) {
+    YES("y"),
+    NO("n"),
+    ;
+    companion object {
+        fun getUserDecision(input: String): UserDecision =
+            UserDecision.entries.find { it.userDecision == input }
+                ?: throw IllegalArgumentException(ERROR_DECISION)
+    }
+}
+
+// blackjack/model/user/UserInputValidator.kt
+object UserInputValidator { ... }
+```
+
+리뷰어: ""y"와 "n"으로 결정되는 것은 UI 로직이 아닐까요? 만약 "Y", "N" 으로 입력한다면 도메인 모델이 수정되어야 합니다." / "`UserInputValidator`도 마찬가지로 UI 로직으로 볼 수 있지 않을까요?" — *UI 형식 변경(대소문자)이 도메인 변경을 유발*하면 의존 방향 역전. *도메인은 `Hit`/`Stay` 같은 도메인 어휘만*. `"y"→Hit`/`"n"→Stay` 매핑은 InputView.
+
+### 13. `BlackJack.changeState()` public — 테스트 위해 캡슐화 깸
+
+```kotlin
+fun changeState() {
+    when (val totalScore = handCard.getTotalCardsSum()) {
+        in MIN_SCORE until BLACK_JACK_SCORE -> _state = State.Action.Hit
+        BLACK_JACK_SCORE -> _state = State.Finish.BlackJack
+        in BUST_SCORE..MAX_SCORE -> { _state = State.Finish.Bust; changeAceScore(totalScore) }
+    }
+}
+```
+
+리뷰어: "`changeState`는 외부에서 사용되지 않고 있네요. 테스트를 위해 public으로 함수를 공개하는 것은 적절하지 않습니다. 이 기능을 테스트 하기 위한 다른 방법을 찾아야 합니다. 또한 함수 이름으로 하여금 어떤 역할을 하는 것인지 기대하기가 어려워 보입니다." — 테스트는 *입력 → 출력*을 검증. `addCard(card)` 호출 후 `state`를 확인하면 자연. *내부 메서드 호출*을 테스트하는 패턴은 *구현에 결합된 테스트*.
+
+### 14. Ace 보정 로직 복잡 — `while + 차감` 패턴
+
+```kotlin
+private fun changeAceScore(totalScore: Int) {
+    var currentScore = totalScore
+    var aceCount = handCard.getAceCount()
+    while (aceCount > 0 && state == State.Finish.Bust) {
+        aceCount -= 1
+        currentScore -= Denomination.ACE.getScore() + Denomination.aceTransferScore()
+        checkCurrentScore(currentScore)
+    }
+}
+```
+
+리뷰어 권고: "블랙잭 보너스 점수를 계산할 때 아래 방법으로 간단하게 계산할 수 있습니다. > 카드들에 에이스 번호가 있을 때, 카드들의 점수 합계가 11점 이하라면, 보너스 포인트 10점을 획득한다." — *Ace를 1점으로 시작 + 합 ≤ 11이면 +10*. 한 줄 룰. `while + 차감 + 상태 재검사`보다 *불변식 한 줄*이 도메인 표현에 부합.
+
+## 리뷰어 의견 요지
+
+- **`main`은 진입점, Controller가 시나리오 결정자.**
+- **호출 순서 invariant는 *생성자 주입*으로 보호** — `lateinit var` + `setGame(...)`는 위반.
+- **`BlackJack` 같은 *의미 모호 객체*는 도메인 어휘에 없으면 의심** — *형식 규칙*보다 *도메인 의미*.
+- **`val`은 이미 getter** — `fun getX()`는 Java 습관.
+- **`CardDeck` 자료구조 = 한 장씩 뽑기 = Stack/Deque** — `Set`은 *순서 없음*과 충돌.
+- **`Dealer.openFirstCard`가 예외 던지면 호출 시점 invariant 누락.**
+- **`check*Condition()` 같은 *검사* 동사보다 *결과 동사*** — `canDraw()` / `shouldHit()`.
+- **`GameManager`는 게임 단위 인스턴스 — 생성자 주입 + 종료.**
+- **상태 판단/변경/승부는 *참가자 자신*** — `Tell, Don't Ask`.
+- **`Participants` = `Dealer + Players` 타입 분리** — 인덱스 0번 invariant 회피.
+- **`UserDecision`/`UserInputValidator`는 도메인 X** — UI 입력 형식.
+- **`changeState()` public은 캡슐화 위반** — `addCard()` → `state` 변화로 테스트.
+
+## 대표 인용
+
+> 참가자가 가지고 있는 블랙잭이라는 객체는 무슨 역할을 하기를 기대할까요? 다이어그램 상으로는 `블랙잭 == 상태` 라는 판단으로 보이지만, 이 블랙잭 객체는 무엇을 하고 싶은 것인지 잘 모르겠어요.
+> — @laco-dev on `src/main/kotlin/blackjack/model/BlackJack.kt`
+
+> 마찬가지로 승부를 겨루는 것은, 게임 결과가 하는 대신 참가자가 스스로 하도록 만들어보세요. 승부를 결정하는 것은, 참가자 정보만 있다면 상대가 누구라도 상관이 없습니다. 딜러와 플레이어 / 플레이어와 플레이어 / 딜러와 딜러
+> — @laco-dev on `src/main/kotlin/blackjack/model/GameResult.kt`
+
+> 참가자라는 타입으로 추상화를 했다면, 1번째 항목이 딜러라는 것을 어떻게 신뢰할 수 있을까요?
+> — @laco-dev on `src/main/kotlin/blackjack/model/Participants.kt`
+
+> "y"와 "n"으로 결정되는 것은 UI 로직이 아닐까요? 만약 "Y", "N" 으로 입력한다면 도메인 모델이 수정되어야 합니다.
+> — @laco-dev on `src/main/kotlin/blackjack/model/user/UserDecision.kt`
+
+> 카드를 한장 씩 뽑아쓰는 것을 표현하기 위해 다른 자료구조를 사용 해 볼 수 있지 않을까요? 지금의 Set 구조는 이 개념을 나타내기에 적절하지 않아 보이네요
+> — @laco-dev on `src/main/kotlin/blackjack/model/CardDeck.kt`
+
+## 얻은 교훈
+
+- **`main()`은 *진입점*만, *시나리오*는 Controller.** `apply { startGameFlow(); playGame(); ... }`이 main에 있으면 *흐름 결정자*가 main으로 누수.
+- **`lateinit var` + setter setup = 호출 순서 invariant 누락** — 생성자 주입으로 컴파일러가 invariant 보장.
+- **객체 이름이 *도메인 어휘에 없으면* 의심하라.** `BlackJack` 객체 = 손패 + 상태 묶음은 *생성자 수 제한* 같은 형식 규칙을 위한 *인공물*일 가능성. *형식 규칙은 의미를 만들지 않는다.*
+- **Kotlin `val`은 이미 getter** — `fun getX() = x`는 Java의 *수동 getter* 습관. 필요 시 *커스텀 getter*로 대체 가능.
+- **자료구조가 도메인 개념을 표현해야** — *한 장씩 뽑기* = `ArrayDeque`/`Stack`. `Set + shuffled`은 *순서 없음*과 *뽑기 순서*가 충돌.
+- **`Dealer.openFirstCard()`처럼 정상 흐름에서 예외 던지지 말 것** — 호출 시점 invariant를 *분배 후*로 보장.
+- **함수명 = 결과 동사** — `checkDealerScoreCondition()` 같은 *검사* 동사는 *반환값이 무엇을 의미하는지* 모호. `canDraw()`, `shouldHit()`.
+- **`Tell, Don't Ask` — 상태 판단·변경·승부는 객체 자신**. `GameResult`가 `player.state`를 보고 `addDealerWin`하지 말고, `player.compete(other)`.
+- **추상화한 컬렉션의 *인덱스 특별 처리*는 추상화 누수** — `Participants(dealer, players)`로 타입 분리.
+- **UI 입력 형식(`"y"`/`"n"`, `"Y"`/`"N"`)은 InputView 책임** — 도메인 enum은 `Hit`/`Stay` 같은 도메인 어휘만.
+- **`public` 함수를 *테스트 때문에 노출*하지 말 것** — 입력→출력 경로로 테스트. *내부 메서드 호출*을 검증하는 테스트는 구현 결합.
+- **Ace 보정 = *불변식 한 줄*** — *합 ≤ 11이면 +10*. `while + 차감 + 재검사`는 *알고리즘으로 룰을 흩뜨림*.
+- **도메인 비유로 책임 분배 가능 — 그러나 비유와 SRP가 충돌할 때는 SRP** — 학생 의문(*심판이 점수 비교*)은 도메인 비유 충실. 리뷰어 입장(*비교는 참가자*)은 *상대 무관 비교*의 일반화. 도메인 비유가 *재사용 단위*를 가르치지 않을 때는 *코드의 응집도*가 우선.

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

@@ -0,0 +1,283 @@
+# PR #92 — [블랙잭 2단계] 누누 미션
+
+- **Reviewee:** [@jinuemong](https://github.com/jinuemong)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/92
+- **단계:** 2단계 (베팅 + 수익률 1.5배 룰)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 17 / 리뷰이 13)
+- **참고:** 같은 학생의 1단계 = PR #63
+
+## 잘한 점 (설계 관점)
+
+- **`State` sealed (Action.Hit / Finish.Stay·BlackJack·Bust) 유지** — 1단계에서 도입.
+- **`runBlackJackGame()` 단일 엔트리포인트로 진행 응집 (후속 반영)** — `main`이 시나리오 결정자였던 PR #63 문제 해결.
+- **`Wallet` → `UserInformation` 명명 변경 + `Proceeds` → `revenue` 명명 변경** — 학생 자가 토론으로 이름 개선.
+- **`GameResult` private 멤버 + 접근 메서드** — 외부에서 Map 직접 접근 차단.
+- **블랙잭 1.5배 룰 분리 — `settleBettingPayout(result, isBlackJackState)`**.
+
+## 못한 점 (설계 관점)
+
+### 1. `main` vs Controller 책임 — 학생 자가 의문 + 리뷰어 심층 답변
+
+학생 질문: "요 코드가 *각 함수로 되어져 있다면 하나라도 먼저 호출되지 않는다면 같은 상황이 발생하는 것인가요?* 제가 *코드를 순차적으로 실행하는 것을 보장하고 있지 않은 것*인지, *모든 코드에서 순차 실행이 되지 않을 경우를 생각해야 할까요?*"
+
+리뷰어: "*문제의 본질을 잘 해석하셨습니다.* 마찬가지로 블랙잭 매니저 도메인도 같은 문제를 가질 수 있습니다. 하지만 *컨트롤러는 도메인 로직의 상태를 판단하고, 그에 맞춰 함수를 작성*하는 반면 메인 클래스는 어떻게 해야 할까요? [...] 만약 게임이 *정상적으로 동작하지 않는다면, 개발자는 메인 클래스를 잘못 작성한 것일까요? 컨트롤러를 잘못 작성한 것일까요?* [...] 결론적으로 *컨트롤러와 뷰 없이도 게임을 진행할 수 있는가?* 라는 목표를 예로 둘 수 있겠습니다."
+
+→ **호출 순서 invariant의 책임 위치 = Controller**. *main은 어떤 게임/Controller를 띄울지* 결정만, *각 컨트롤러는 자기 게임의 호출 순서 책임*. 학생 후속: `main` → `runBlackJackGame()` 단일 호출.
+
+### 2. `runBlackJackGame()`의 *void 반환 함수 시퀀스* — 사이드 이펙트 의존
+
+```kotlin
+fun runBlackJackGame() {
+    startGameFlow()      // 사이드 이펙트
+    playGame()           // 사이드 이펙트
+    showResult()         // 사이드 이펙트
+}
+```
+
+리뷰어: "*원래 함수란, 무언가를 반환하도록 설계되었습니다. 만약 아무것도 반환하지 않는다면 사이드 이펙트를 발생시킨다는 것을 의미*할 수 있으니까요. [...] 아래 코드랑 비교했을때 어떤 차이가 있는지 고민 해보시면 좋겠습니다. ```kotlin fun runBlackJackGame() { val gameManager = createGameManager(); readyGame(gameManager); val gameResult: GameResult = playGame(gameManager); showResult(gameResult) } ```"
+
+→ *void 함수 시퀀스 + 멤버 필드 공유*는 *암묵 의존*. *return 값 전달*은 *데이터 흐름 가시화*. 후속 학생 인정: "*사이드 이펙트에 대해서 좀 더 공부를 해보고, 코드를 짤 때 고민해봐야겠습니다*."
+
+### 3. `Wallet(name, balance)` — *지갑에 이름 붙임* + *3변수 제한 회피*
+
+```kotlin
+data class Wallet(val name: String) {
+    private var balance: Int = 0
+    fun setMoney(money: Int) { balance = money }
+    fun getBalance(): Int { return balance }
+}
+```
+
+리뷰어: "*참가자가 이름을 가지지 않고, 지갑에 이름을 붙이는게 맞나요?* *인스턴스 변수 3개 조건을 억지로 지키려고 만들어진 것 같은 느낌*이 듭니다. 우선은 3개를 사용하더라도, 더 좋은 구조라고 생각이 든다면 그렇게 해주시면 됩니다. > 딜러는 "딜러"라는 이름을 가진다. > 딜러는 "딜러"라는 이름의 지갑을 가진다."
+
+학생: "저는 wallet에 *신분증과 베팅 머니를 저장하는 그림*을 생각했습니다. *다시보니 네이밍에 문제가 있었던 것 같습니다*. **UserInformation**으로 전환하니 구조가 괜찮아 진 것 같습니다."
+
+리뷰어 (Dealer.kt에 답변): "*유저정보가 되서 더 좋아졌다고 생각하셨지만... 사실 Information이라는 이름은 객체지향 설계에 굉장한 피곤함을 주는 이름*입니다. 왜냐하면 *만능*이거든요. *정보에는 모든게 다 들어갈 수 있고, 모든 게 다 있으니 아무런 코*..."
+
+→ **PR #135 (ijh1298) `PlayerBetInfo`와 동일 안티패턴**. *형식 규칙(3변수 제한)*이 *인공 객체* 만들어냄. 게다가 *Wallet → UserInformation* 명명 변경도 *Information은 만능 이름*이라 또 다른 안티패턴. *`Player.betAmount`* 자연 표현이 두 번 우회됨.
+
+### 4. `Wallet.balance` `var` + `setMoney()` — 변경 불필요
+
+리뷰어: "*현재 요구사항에서는 돈이 동적으로 변경될 일이 없는 것 같은데요. 상태를 동적으로 변경할 수 있도록 만든 이점이 있을까요?*" — 게임 1회당 *베팅 한 번 + 결과 계산*. *Mutable balance는 가능성 시나리오를 위한 과잉*. `val balance: Int` + *생성 시 결정*이 자연.
+
+### 5. `Proceeds(name, proceeds)` — 모호한 명사
+
+```kotlin
+class Proceeds(val name: String, val proceeds: Int)
+```
+
+리뷰어: "*이 객체는 무슨 역할을 하는지 알려주세요. 🙇🏻 객체 이름과 상태를 봐도 모르겠어서 질문 드립니다.*"
+
+학생: "*한 게임에 대한 수익을 가지고 있습니다. 이름에 대한 뜻이 너무 많아서 **revenue** 로 전환*하였습니다."
+
+→ `Proceeds`/`Revenue`도 *클래스 = 속성*과 다름. `PlayerProfit(player, amount)`가 자연. `name`과 `proceeds` 두 변수면 *플레이어와 그 수익*인데 *이름*이 *모호 명사*로 가려짐. (`Information` 회피와 같은 결.)
+
+### 6. `BlackJack`과 `HandCard` 두 곳에서 점수 계산
+
+```kotlin
+class BlackJack {
+    private val handCard = HandCard()
+    private fun updateGameStateWithScore() {
+        val score = handCard.getTotalCardsSum()
+        when (getGameScoreWithAceCount(score)) { ... }
+    }
+    private fun getGameScoreWithAceCount(score: Int): Int {
+        val transferScore = score + Denomination.TRANSFER_ACE_SCORE
+        return if (handCard.checkStateWithAceCount() && transferScore <= BLACK_JACK_SCORE) transferScore else score
+    }
+}
+```
+
+리뷰어: "*카드들의 점수 합을 계산하는 규칙을 두개로 나눈 이유가 무엇일까요?* 핸드에서도 *총합 점수가 계산*되고 블랙잭에서도 *총합점수가 계산*이 됩니다. [...] *이미 핸드 자체가 블랙잭 도메인에 깊게 관여*를 하고 있기에 *핸드에서 계산을 해도 충분*하다고 생각하는데요. 카드들의 점수 합을 계산하고 *이를 테스트 하려면, 반드시 블랙잭 객체로만 테스트를 해야 하기 때문에 굉장히 난이도가 올라가지는 않았을까요?*" — *점수 계산 = Hand 단일 책임*. *Bust/BlackJack 판정*만 BlackJack에. *테스트 단순화*가 부수 효과.
+
+### 7. `HandCard`의 `private set` 오용
+
+```kotlin
+class HandCard {
+    private var _cards: List<Card> = listOf()
+    var cards: List<Card>
+        get() = _cards
+        private set(value) { _cards = value }      // 외부 setter는 막혔으나 _cards와 중복
+}
+```
+
+리뷰어: "*`private set` 을 사용하는 올바른 사례가 아닙니다.* https://kotlinlang.org/docs/properties.html *backing property랑 비교했을 때 어떤 차이*인지 고민해보시면 좋겠습니다." — *backing property*는 `private val _cards` + `val cards: List<Card> get() = _cards`. `private set`은 *같은 프로퍼티의 setter만 private*. *외부 변경 차단 + 클래스 내부에서만 변경*. **두 패턴이 다른 목적**. 학생이 *둘을 섞어* `private var _cards` + `private set`을 동시에 노출 — 의도 불명.
+
+### 8. `CardDeck(cards: List<Card> = emptyList())` — *빈 덱이면 셔플* 분기
+
+```kotlin
+class CardDeck(cards: List<Card> = emptyList()) {
+    init {
+        if (this.cards.isEmpty()) { cardShuffle() }
+    }
+}
+```
+
+리뷰어: "*다른 사람이 봤을 때, 아래 코드가 논리적으로 좋은 방법일까요..?* ```val cardDeck = CardDeck(cards = emptyList()) // 비어있는 덱을 만들어야지! cardDeck.draw() // A 스페이드``` 테스트로 만든다면, 아래와 같은 케이스가 나올 것 같은데요 🤔 > *비어있는 덱을 만들면 셔플한다*"
+
+→ *`cards = emptyList()` 인자*가 *셔플 트리거*. *호출자 의도*(빈 덱)와 *실제 동작*(셔플 후 52장) 불일치. `CardDeck()` no-arg 생성자 = *셔플된 새 덱*, `CardDeck(cards)` = *주어진 카드들로 덱*. 두 의도 분리.
+
+### 9. `BlackJack.applyGameStateWithAceCount` 깊은 분기 vs 단순 룰
+
+```kotlin
+// Before (학생)
+private fun applyGameStateWithAceCount(totalScore: Int) {
+    if (handCard.updateGameStateWithAceCount(totalScore)) {
+        state = State.Finish.BlackJack
+    }
+}
+```
+
+리뷰어 권고: ```kotlin
+val score = handCard.getTotalScore()
+when {
+   score == 21 && handCard.size == 2 -> State.Finished.BlackJack
+   score == 21 -> State.Finished.Stay
+   score > 21 -> State.Finished.Bust
+   else -> State.Action.Hit
+}
+```
+
+리뷰어: "*점수를 계산하는 것은 내부에서 알아서 할 일인데, 에이스가 포함되어있는지 여부가 밖에서 알 필요가 없지 않을까* 생각해요. *함수의 깊이가 깊어지는 것도 한 가지 이 코드의 아쉬운 점*이라고 생각합니다." — *Ace 보정*은 `HandCard.getTotalScore()` 내부. *외부에서는 보정 후 점수*만 봄. *상태 결정*은 *점수 + 카드 수* 단순 분기.
+
+### 10. `21점일 때 Stay 자동 진입` vs *유저 의지로 Hit 유지* — 학생 자가 의문
+
+리뷰어: "*21점일 때 이 함수로 빠지는데, 카드가 2장이 아니면 어떤 상태가 되는건가요?*"
+
+학생: "*Stay 상태가 되는게 맞나요?* 저는 *21점인지 판단은 유저가 해서 Hit 상태를 유지하는게 맞다*고 봤습니다. *이는 너무 현실세계에 몰입한 것일까요?* 자동으로 Stay 상태가 되는 것이 아닌 *유저가 본인의 점수 계산을 실수할 수도 있다*고 생각했습니다. *어쩌면 블랙잭 규칙을 제대로 모르는 것일 수도 있겠군요.. 수정*하였습니다."
+
+→ *현실 비유 충실*(유저가 카드 계산 실수)과 *도메인 룰*(21점이면 Stay) 충돌. *도메인이 정확한 점수를 안다면* 자동 진입이 자연. PR #112와 같은 *현실 비유 vs 객체지향 자율성* 토론.
+
+### 11. `Dealer.settleBettingMoneys(gameResult: GameResult): List<Proceeds>` — *수익률을 딜러가 계산*
+
+```kotlin
+class Dealer(...) : Participant(...) {
+    fun settleBettingMoneys(gameResult: GameResult): List<Proceeds> {
+        return gameResult.getResultPlayers().map { player ->
+            val payout = gameResult.getPlayerResult(player)?.let { ... } ?: 0
+            val playerBettingResultMoney = player.getBettingMoney() * payout.toInt()
+            Proceeds(player.getName(), playerBettingResultMoney)
+        }
+    }
+    private fun settleBettingPayout(result: Result, isBlackJackState: Boolean): Float {
+        return when (result) {
+            Result.WIN -> if (isBlackJackState) 1.5f else 1f
+            Result.DRAW -> if (isBlackJackState) 1.5f else 1f       // ⚠ DRAW도 1.5배?
+            Result.LOSE -> -1f
+        }
+    }
+}
+```
+
+리뷰어: "1. *딜러가 게임결과를 의존해서 수익률을 계산*하는 것 2. *게임 결과를 통해 수익률을 판단*하는 것 같은 기능에 대해 *어떻게 의존성을 가지도록 하는게 적절*하다고 생각하시나요? *코드가 복잡하게 만들어졌기 때문에 책임과* ..."
+
+→ *Dealer가 GameResult 의존*하면 *Dealer 역할 비대*. *수익률 계산*은 *베팅 + 결과* 별도 객체(`BetRecords` 같은). PR #135와 같은 결.
+
+또 *DRAW도 1.5배* 룰은 *블랙잭 룰 위반*. DRAW는 *원금 반환*(0배 또는 push). 학생 *룰 오해*. 후속 단위 테스트 권고에 *왜 단위 테스트가 없는지* 지적.
+
+### 12. `Dealer.settleBettingMoneys`에 대한 단위 테스트 부재
+
+리뷰어: "*2단계의 핵심 기능입니다. 왜 단위 테스트를 작성하지 않았을까요?* 아마 *아래 테스트를 짜야 한다면, 머리가 아파지실 거*라고 생각이 듭니다. 😱 > *블랙잭 상태라면 수익률은 1.5배이다* / *스테이 상태는 수익률이 1배이다.* / *버스트 상태는 수익률이 0배이다.* / *히트 상태는 수익률 ?????*"
+
+→ **테스트가 어려운 것 = 책임이 잘못 배치된 신호**. *Dealer가 모든 시나리오*(상태 × 결과)를 다 가지면 *조합 테스트 폭증*. *책임 분리*가 테스트 단순화 신호.
+
+### 13. `UserInputValidator.makeParticipants` — *Validator가 Participants 생성*
+
+```kotlin
+object UserInputValidator {
+    fun makeParticipants(): Participants {
+        val dealer = Dealer()
+        val players = InputView.inputPlayers()
+        return Participants(dealer = dealer, players = players)
+    }
+}
+```
+
+리뷰어: "*여러번 같은 질문을 드리는 것 같은데, `UserInputValidator`와 `InputView` 역할이 섞이지 않았나요?* 단순히 *컨트롤러 코드가 길어지는 것을 피하려고 옮긴 것 같은데 저는 결론적으로 이 객체가 왜 필요한가 의문*이 드네요. 🤔" — *Validator*가 *입력 + 도메인 생성 + 검증* 셋. *역할 흡인기*. PR #63에서 받은 같은 지적이 *반복*. 학생이 *이름만 바꿔* 같은 객체를 유지.
+
+또: "*플레이어의 이름을 잘못 정한다면, 오류가 발생하는 것은 View*이고 *입력을 잘못해서 참가자 생성에 실패하면 컨트롤러에서 발생*하고 있네요. *InputValidator라는 역할이 반쪽처럼 느껴지지 않을까요?*" — *검증 책임이 두 곳에 분산*.
+
+### 14. `Dealer.openInitCards(): List<Card>` *비어있으면 오류* — Player와 일관성 없음
+
+```kotlin
+dealer.openInitCards()
+    .also { cards -> if (cards.isEmpty()) println(ERROR_CARD_INDEX) }
+    .forEach { firstCard -> OutputView.outputDealerCurrentHandCard(...) }
+```
+
+리뷰어: "*딜러가 처음 공개하는 카드를 왜 한장씩 출력하는것일까요?* 또한 *비어있을 때 오류로 판단하는 것도 궁금*합니다. 1. *딜러는 비어있는게 오류인데 플레이어는 없기 때문에 일관성이 맞지 않습니다*. 2. *딜러도 참가자도 모두 처음 공개하는 카드들을 받는데, 로직을 분리할 필요가 있는까요?*" — *Dealer.openInitCards() = 1장 / Player.openInitCards() = 2장*인 *비즈니스 룰 차이*면 *공통 추상 메서드*면 충분. *비어있으면 오류*는 *호출 시점에 카드 분배 완료* invariant 보장 누락. PR #135와 같은 결.
+
+### 15. `let` 범위 지정 함수 indent 증가
+
+```kotlin
+fun outputPlayerCurrentHandCard(player: Participant) {
+    player.openInitCards()?.let { playerInitCards ->
+        println(
+            OUTPUT_MESSAGE_PARTICIPANTS_CURRENT_HAND_CARD
+                .format(
+                    player.getName(),
+                    joinCardsInfo(playerInitCards),
+                ),
+        )
+    }
+}
+```
+
+리뷰어: "*let과 같은 범위 지정 함수는, 코드를 편하게 작성할 수 있지만 적절하게 사용하지 않으면 오히려 가독성을 해칠수도 있습니다.* 범위 지정 함수의 여러 레퍼런스를 찾아 보시고, *프로그래밍 요구사항의 indent를 늘리지 않도록 하는 것*을 지켜보도록 해보세요" — `let` 안에서 *3단계 indent*. *let의 가치 = null 처리 + 한 표현식*. *여러 라인 + 깊은 indent*면 *if let != null*이 더 명확.
+
+### 16. `GameManager.draw(participant): Boolean` — *Boolean 반환의 의미 불명*
+
+리뷰어: "*저는 왜 이 함수가 boolean을 반환하는게 계속 어색하게 느껴질까요?* 마치 *draw 함수에서만 오류가 발생할 수 있는 것 처럼*... 현재 구조에서는 *만약 GameManager에 문제가 발생해 false를 반환한다면 모든 플레이어가 갑자기 카드를 받지 않고 게임이 정상 종료되는 이상한 시나리오*가 되겠네요" — *Boolean이 무엇을 의미하는지* 함수명에 없음. *성공/실패 vs 카드를 더 받을 수 있는지 vs Bust 여부* 등 *호출자가 추측*. *명시적 결과 타입* 또는 *예외* 또는 *Optional*.
+
+## 리뷰어 의견 요지
+
+- ***호출 순서 invariant 책임 = Controller, main이 아님*** — *컨트롤러와 뷰 없이도 게임 진행 가능한가* 자가 점검.
+- ***void 함수 시퀀스 + 멤버 필드 공유 = 사이드 이펙트 의존*** — *return 값 전달*.
+- ***형식 규칙(3변수)이 만든 Wallet → UserInformation → 만능 이름 함정***.
+- ***`Mutable balance`는 동적 변경 가능성 시나리오 없으면 과잉***.
+- ***점수 계산 = Hand 단일 책임, BlackJack은 상태 결정만***.
+- ***`private set` vs `backing property` 목적 차이***.
+- ***`CardDeck(emptyList())`가 셔플 트리거 = 의도 ≠ 동작***.
+- ***Ace 보정은 Hand 내부, 외부는 보정 후 점수***.
+- ***DRAW에 1.5배 = 룰 오해***.
+- ***테스트 어려움 = 책임 잘못 배치 신호***.
+- ***`UserInputValidator`가 *입력 + 도메인 생성 + 검증* 셋 = 역할 흡인기***.
+- ***Dealer 1장 / Player 2장 = 공통 추상 메서드의 다른 구현***.
+- ***`let` 깊은 indent = 범위 지정 함수 오용***.
+- ***`Boolean` 반환의 의미 불명*** — 함수명에 결과 의미.
+
+## 대표 인용
+
+> 컨트롤러는 도메인 로직의 상태를 판단하고, 그에 맞춰 함수를 작성하는 반면 *메인 클래스는 어떻게 해야 할까요?* [...] 결론적으로 *컨트롤러와 뷰 없이도 게임을 진행할 수 있는가?* 라는 목표를 예로 둘 수 있겠습니다.
+> — @laco-dev on `Application.kt`
+
+> 원래 함수란, 무언가를 반환하도록 설계되었습니다. *만약 아무것도 반환하지 않는다면 사이드 이펙트를 발생시킨다는 것을 의미*할 수 있으니까요.
+> — @laco-dev on `BlackJackController.kt`
+
+> 참가자가 이름을 가지지 않고, *지갑에 이름을 붙이는게 맞나요? 인스턴스 변수 3개 조건을 억지로 지키려고 만들어진 것 같은 느낌이 듭니다.*
+> — @laco-dev on `Wallet.kt`
+
+> Information이라는 이름은 *객체지향 설계에 굉장한 피곤함을 주는 이름*입니다. 왜냐하면 *만능*이거든요. *정보에는 모든게 다 들어갈 수 있*고 [...]
+> — @laco-dev on `Dealer.kt` (`Wallet → UserInformation` 명명 변경 후 답변)
+
+> 2단계의 핵심 기능입니다. *왜 단위 테스트를 작성하지 않았을까요?* 아마 *아래 테스트를 짜야 한다면, 머리가 아파지실 거*라고 생각이 듭니다. 😱
+> — @laco-dev on `Dealer.kt` (`settleBettingMoneys`)
+
+## 얻은 교훈
+
+- ***호출 순서 invariant는 Controller의 책임*** — main은 *어떤 게임을 띄울지*만. *컨트롤러와 뷰 없이도 게임이 진행되는가*가 *책임 분리 자가 점검 질문*.
+- ***void 함수 + 멤버 필드 공유 = 사이드 이펙트 의존*** — *return 값으로 다음 함수에 전달*하면 *데이터 흐름이 시그니처에 명시*.
+- ***형식 규칙(3변수 제한)이 만든 Wallet은 인공 객체*** — PR #135 (ijh1298) `PlayerBetInfo`와 동일. *형식 규칙*은 *코드 단순화 도구*이지 *목적*이 아님.
+- ***`Information` / `Manager` / `Util` 같은 *만능 명사*는 책임 흡인기*** — 모든 것이 들어갈 수 있으므로 *책임 경계 무너짐*. (STYLE_GUIDE §1-2 `vague-class-name` 룰과 같은 결.)
+- ***`Mutable balance` + setter는 동적 변경 가능성 시나리오가 있을 때만*** — 게임 1회당 베팅 한 번이면 `val` + 생성 시 결정.
+- ***점수 계산 = Hand 단일 책임*** — *BlackJack/Player에서 또 계산*하면 *테스트가 BlackJack 객체로만 가능*해져 난이도 ↑.
+- ***`private set` ≠ `backing property`*** — `private set`은 *같은 프로퍼티의 setter만 차단*, `backing property`는 *외부 노출 타입을 좁힘*. 둘을 섞으면 의도 불명.
+- ***`CardDeck(emptyList())`가 셔플 트리거 = 호출자 의도 ≠ 실제 동작*** — *no-arg = 셔플된 새 덱 / 명시 cards = 그대로*. 분기를 인자 값이 아닌 *생성자 다중 정의*로.
+- ***Ace 보정은 Hand 내부*** — 외부에서 *Ace 여부*를 알 필요 없음. `hand.score()`만 노출.
+- ***DRAW에 1.5배 = 블랙잭 룰 오해*** — *블랙잭 룰 충실히 읽기*. DRAW는 push (0배 또는 원금 반환).
+- ***단위 테스트 작성이 머리 아프면 책임이 잘못 배치된 신호*** — *Dealer.settleBettingMoneys(상태 × 결과)* 조합 폭증 = 책임 분리 신호.
+- ***`UserInputValidator`는 PR #63·#92 두 번 같은 지적*** — *이름 바꿔서 유지*는 안티패턴 회피 X. *역할 자체*가 InputView/도메인에 흡수되어야.
+- ***Dealer 1장 / Player 2장 공개 = 공통 추상 메서드 + 다른 구현*** — *Dealer만 비어있으면 오류*는 invariant 누락. PR #135와 같은 결.
+- ***`let` 안 깊은 indent = 범위 지정 함수 오용*** — `let의 가치 = null 처리 + 한 표현식*. 여러 라인이면 `if (x != null)`이 명확.
+- ***`Boolean` 반환의 의미는 함수명에*** — *카드를 더 받을 수 있는지*, *오류 없이 진행됐는지*, *Bust인지* 호출자가 추측하면 위험.