oh-my-oop 0.2.0

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

@@ -0,0 +1,228 @@
+# PR #16 — [블랙잭 1단계] 베르 미션
+
+- **Reviewee:** [@SeongHoonC](https://github.com/SeongHoonC)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/16
+- **단계:** 1단계
+- **리뷰어:** [@BeokBeok](https://github.com/BeokBeok) (**신규 reviewer**)
+- **라인 코멘트:** 21 스레드 — *요구사항 어휘 + LSP/SRP 원칙 명시 + 외부 글 + 학생 자가 abstract/open 학습*
+- **신규 reviewee** (2023년 3월 코호트, PR #23·#26 와 같은 시기).
+
+## 잘한 점 (설계 관점)
+
+- **abstract vs open 학생 자가 답변 (Kotlin 어휘 정리)** — 벅벅 메타 질문: *"abstract와 open의 차이점은 무엇일까요?"* + 학생 자가 답변: *"abstract class : 인스턴스화 할 수 없습니다. 또한 하위 클래스에서 구현이 없는 abstract method 를 필수로 override 해야 합니다. open class : 인스턴스화 할 수 있습니다. 하위 클래스에서 open fun 을 그대로 쓰거나 override 해서 사용할 수 있습니다."*. **MCP 룰 후보 `abstract-without-abstract-method`** + Kotlin 어휘 학생 자가 학습 모범. PR #74·#95·#108·#133·#137·#147 결.
+- **LSP + MutableList vs List 자가 학습** — 벅벅: *"객체지향의 원칙 중 LSP 라는 것이 있습니다. LSP가 무엇인지 학습해보시고 코드를 개선해보면 어떨까요? 참고로 MutableList는 List의 하위타입입니다."* + 학생 자가 답변: *"상위타입인 List 를 캡슐화하면 하위타입 MutableList 또한 받을 수 있습니다. 현재 가변리스트를 외부에서 받는 구조입니다. 하지만 가변 리스트가 돌아다니면 값이 훼손될 수 있습니다. 때문에 불변 리스트 형태로 받고 가변리스트로 변환하도록 변경하겠습니다."*. **LSP (Liskov Substitution Principle) 자가 학습 + Kotlin List vs MutableList 타입 계층 인지**.
+- **카드 섞기 자가 init 적용** — 벅벅: *"카드를 섞는 함수를 잘 구현해주셨네요. 다만, 개발자가 깜빡하고 이 함수를 호출하지 않게 되면 카드가 섞이지 않게 되는데요. 이 함수를 호출하지 않고 카드를 섞을 수 있도록 코드를 개선해보면 어떨까요?"* + 학생: *"인스턴스화 될 때 init 에서 호출하도록 하였습니다."*. **객체 invariant 자가 학습** = *"객체 생성 시 카드는 섞여 있다" 보장*. PR #146 (yrsel *변경 직후 invariant 보장*) 결.
+- **private 생성자 칭찬** — 벅벅: *"private 생성자 👍"* — *Deck factory 패턴 권고 + 자가 적용*. PR #74·#108·#133·#136·#46·#26·#23 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `Deck` 생성자 부재 — 행동만 가지면 다른 객체와 구별 어려움
+
+벅벅 진단: *"Deck은 반드시 카드 리스트를 가져야 합니다. 그렇다면 카드 리스트를 생성자로 갖도록 코드를 개선해보면 어떨까요? 생성자가 없는 클래스는 오직 프로퍼티와 함수만 갖기 때문에, 다른 객체들과 구별하기 어렵습니다."*
+
+벅벅 별도 (Cards): *"Cards 클래스는 반드시 Card의 리스트를 가지고 있어야 합니다. 그렇다면, 멤버 변수보다는 생성자로 캡슐화하면 어떨까요? 추가로, 클래스는 최소한 무언가는 캡슐화를 하는 것이 좋습니다. 지금과 같은 클래스 구조에서는 오로지 행동(함수)만을 가지므로, 다른 객체들과 구별하기가 어렵습니다."*
+
+→ **2 가지 학습**:
+
+#### 1.1. *생성자 = 객체의 invariant 명시*
+
+- *생성자 없음 + 멤버 변수 늦은 초기화* = *어느 시점에 초기화되는지 모호*.
+- *생성자 (val cards: List<Card>)* = *생성 시점부터 invariant (카드 리스트 보유) 보장*.
+
+#### 1.2. *행동만 가진 클래스 = `static helper` 와 구별 어려움*
+
+- *행동만 = 사실상 함수 모음 (top-level 함수 or object)*.
+- *클래스 = 상태 + 행동 응집*.
+- **MCP 룰 후보 — `class-without-state`** = *상태 없는 클래스는 object / top-level 함수 정공*.
+
+PR #46 (krrong 2단계 *Calculator object*) 결.
+
+### 2. `BlackJackRule` 파일명 — *클래스처럼 보이지만 상수 모음*
+
+벅벅 1차: *"파일명만 봤을 때에는 클래스처럼 느껴지지만, 파일 내부에는 규칙과 관련된 상수값들이 모여있네요. 파일명을 보고서 블랙잭과 관련된 상수값들이 있는지 알 수 있도록 파일명을 개선해보면 어떨까요?"*
+
+벅벅 2차 (후속): *"파일명을 잘 바꿔주셨습니다. 지금과 같은 파일명도 좋지만, `BlackJackConstants` 와 같이 간결하게 작성할 수 있어요. 추가로, top-level 변수로 정의를 해주셔서 외부에서 편하게 접근할 수 있다는 장점이 있지만, 나중에 상수가 많아지게 되면 어디에 정의되어있는지 알기 어렵다는 단점이 있습니다. 해서, object에 관련 상수값을 묶는 것을 권장합니다."*
+
+→ **3 가지 학습**:
+
+#### 2.1. *파일명 = 내용 추론 매개체*
+
+- *`BlackJackRule.kt`* = *클래스/인터페이스 추정* (~`Rule` 명명 패턴).
+- *`BlackJackConstants.kt`* = *상수 모음 명시*.
+
+#### 2.2. *top-level vs object 상수*
+
+- *top-level* = *전역 접근 + 짧은 표기* + *분산 가능성*.
+- *object* = *그룹핑 + 명시적 컨테이너* + *`BlackJackConstants.MAX_SCORE` 형태*.
+- *상수 다중 = object 응집 정공*.
+
+#### 2.3. *Rule 명사 = vague-name 결*
+
+PR #99·#26·#23·#39 의 *vagueName* 결. *`Rule` (추상 명사) 자체가 모호 + 상수 모음 내용과 불일치*.
+
+### 3. `Dealer` 이름 프로퍼티 오버라이딩 + 요구사항 변경 시 — 메타 질문
+
+벅벅: *"프로퍼티를 오버라이딩하여 이름을 설정할 수 있도록 잘 구현해주셨네요. 👍 만약 요구사항이 변경되어 Dealer의 이름을 설정할 수 있도록 된다면, 어떻게 개선할 수 있을까요?"*
+
+→ **요구사항 변경 시나리오 = 설계 유연성 메타 질문**:
+- *현재 = `Dealer.name = "딜러"` 고정*.
+- *변경 시나리오 = `Dealer("이름")` 외부 주입 가능*.
+- *상속 (override) vs 생성자 주입 트레이드오프*.
+
+PR #95·#23·#46 의 *Dealer 책임 위치 + 인스턴스 가변성* 결.
+
+### 4. `Person` 3 변수 제약 + 요구사항 어휘
+
+벅벅: *"프로그래밍 요구사항은 아래와 같은 항목이 있습니다. - 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다. 이 요구사항을 반영해보면 어떨까요?"*
+
+→ **3 변수 제약 (객체지향 생활 체조 원칙)**. PR #98 (chaehyuns *3 변수 제약 자가 의문*) / PR #133·#88·#132·#136·#93 의 *3 변수 제약 부산물 인공 객체* 결.
+
+### 5. `MainView` 입출력 분리 — 요구사항 어휘
+
+벅벅: *"MainView는 입력과 출력에 대한 책임을 가지고 있습니다. 프로그래밍 요구사항에 있는 것처럼, 입력과 관련된 책임과 출력과 관련된 책임을 서로 분리해보면 어떨까요?"*
+
+→ **InputView + OutputView 분리**. PR #98·#88·#131 의 *view-by-stage-split* / PR #28·#79 의 *Controller god-object* 결.
+
+### 6. `테스트 의도-구현 불일치` — 명세서 어휘
+
+벅벅 1차: *"테스트 코드에서는 '52장 생성되어야 한다'인데, 구현부는 단순히 Deck 객체를 생성할 때 예외가 발생하는지만을 체크하고 있네요. 52장이 아닌 카드 리스트를 가진 Deck을 생성했을 때 예외가 발생하는지 테스트 코드를 작성해보면 어떨까요?"*
+
+벅벅 2차: *"테스트 코드에서는 '한장씩 뽑을 수 있다'라고 되어있는데요. 구현부에서는 한 장이 아니라, 해당 인스턴스가 Card인지를 체크하고 있네요. 테스트를 하고자 하는 것과 일치시켜보면 어떨까요?"*
+
+벅벅 3차 (학생 자가 의문 후 부연 + URL 자가 참조): *"제가 설명이 조금 부족한 것 같네요. '덱에서 카드를 뽑을 수 있다' 라는 테스트를 작성해주셨는데요. 하지만 구현부에서는 단순히 뽑은 카드의 인스턴스가 Card인지 비교하고 있습니다. 이는 반드시 성공하는 테스트이지 않을까요? 내가 원하는 카드 리스트를 기반으로 Deck을 완성하고, getCard 함수를 호출했을 때 내가 원하는 카드가 일치하는지 확인해보면 어떨까요?"*
+
+→ **3 가지 학습**:
+
+#### 6.1. *테스트 명 ≠ 검증 내용 = 명세서 불일치*
+
+- *테스트 명*: *"52장 생성되어야 한다"* — *카드 수 검증 의도*.
+- *검증 내용*: *예외 발생 여부* — *카드 수 검증 X*.
+
+#### 6.2. *반드시 성공하는 테스트 = 무의미*
+
+- *`assertThat(deck.getCard()).isInstanceOf(Card::class.java)`* — *`getCard()` 반환 타입이 `Card` 이므로 항상 통과*.
+- *결정적 카드 검증* (e.g., 첫 카드는 ACE) — *실제 동작 검증*.
+
+#### 6.3. *reviewer 자가 부연 + 학생 의도 명확화*
+
+벅벅의 *"제가 설명이 조금 부족한 것 같네요"* — **reviewer 자가 부연 + URL 자가 참조**. PR #95 (말리빈 *두 번 부연*) / PR #99 (KwonDae *궁극적 의도 명시*) / PR #23 (말리빈 *이모지 부연*) 결.
+
+PR #23·#26·#39·#46·#74·#95·#99 의 *갯수만 검증 무의미 + 결정적 검증* 결.
+
+### 7. `원시값 포장 (Int → Score)` — 학생 자가 의문 + SRP 어휘
+
+벅벅 1차: *"ACE의 합을 계산하는 중요한 로직을 잘 구현해주셨네요. 👍 프로그래밍 요구사항에는 아래와 같은 항목이 있습니다. - 모든 원시 값과 문자열을 포장한다. 이 요구사항을 반영해서 점수(Int타입)를 포장해보면 어떨까요?"*
+
+학생 자가 의문: *"같은 클래스 내부에서 호출되는 private 함수인데 Int 타입 포장이 필요한가요...? 잘 모르겠습니다..!!"*
+
+벅벅 메타 답변 (SRP 어휘): *"점수에 해당하는 타입(Int)도 로직이 존재합니다. (최대 점수는 몇점까지 가능한지, 상황에 따라 ACE가 있을 때 점수 계산이 어떻게 되는지 등) 즉, Person 클래스는 플레이어의 책임 뿐만 아니라 점수와 관련된 책임도 가지고 있습니다. 객체지향 원칙 중 SRP에 대해서 학습해보시고, 코드를 개선해보면 어떨까요?"*
+
+→ **3 가지 메타 학습**:
+
+#### 7.1. *학생 자가 의문 = 학습 갭 명시*
+
+*"같은 클래스 내부에서 호출되는 private 함수인데 Int 타입 포장이 필요한가요...? 잘 모르겠습니다..!!"* — **학생 자가 학습 갭 명시 모범**. PR #95·#99·#43 결.
+
+#### 7.2. *원시값 포장 = SRP 적용*
+
+- *`Int 점수` 자체 = *로직 보유 (max, ACE 분기)***.
+- *Person 클래스 가 *점수 로직* 까지 = *책임 다중* (SRP 위반).
+- *`Score` 별도 객체 = *점수 책임 응집* + Person 은 *Score 협력*.
+
+PR #131·#136·#146·#147·#70·#26·#43 의 *점수 책임 위치 트레이드오프* 결.
+
+#### 7.3. *외부 객체와 내부 private 의 차이*
+
+학생의 *"같은 클래스 내부 private 함수"* — *외부 노출 X 라면 캡슐화는 충분히 보장됨* 자가 정당화. **그러나 SRP 는 *외부 노출 여부 ≠ 책임 다중***. *책임 응집 자체* 가 별도 기준.
+
+**MCP 룰 후보 — `primitive-with-domain-logic`** = *원시값 + 도메인 로직 = 포장 정공*. PR #74·#137·#148·#131 결.
+
+### 8. `Decision` constants 패키지 부적합
+
+벅벅: *"상수(constants)는 일반적으로 로직을 가지고 있지 않습니다. 하지만 Decision은 of, has 함수 등 로직을 가지고 있습니다. 그렇다면 constants 패키지에 속하는 것은 부적합한 것 같은데요. constants가 아닌 다른 패키지에 위치시켜보면 어떨까요?"*
+
+학생: *"다른 패키지를 만들어 보려고 했는데 이름이 생각나지 않아서 일단 domain 패키지로만 이동하였습니다!"*
+
+→ **패키지 = 응집 단위**. *상수 패키지 + 로직 객체 = 응집 위반*. *domain 패키지 (도메인 객체) / model 패키지 (가치 객체) / enum 패키지* 등이 후보.
+
+**`enum 에 행동 부여` = enum 어휘 활용 (PR #137·#148·#90·#146)** 와 *패키지 분류* 의 충돌 — *Decision 이 enum 인지 sealed class 인지에 따라 패키지 다름*.
+
+### 9. `when vs if (3 분기 이상)` + 외부 글
+
+벅벅: *"condition이 3가지 이상인 경우에는 if문 보다도 when 절을 사용하는 것을 권장합니다. ref. https://kotlinlang.org/docs/coding-conventions.html#if-versus-when"*
+
+→ **Kotlin 어휘 + 외부 글**. PR #26 (잭슨 *when vs if-else 외부 글*) 와 *같은 외부 글*. **2023년 3월 코호트 reviewer 공통 패턴**.
+
+### 10. `ACE 1↔11` 테스트 부재 — 도메인 핵심 로직
+
+벅벅 1차: *"ACE는 블랙잭 게임에서 중요한 역할을 합니다. 그렇다면, ACE는 어떤 경우에 11이 되고 어떤 경우에 1이 될까요? 이 경우에 대한 테스트 코드를 작성해보면 어떨까요?"*
+
+벅벅 2차: *"카드 패의 합이 21일 경우에 대해서도 테스트 코드를 작성해보면 어떨까요?"*
+
+벅벅 3차: *"ACE를 판단하여 점수를 계산하는 로직은 블랙잭 게임에서의 핵심 로직 중 하나입니다. 이 함수들을 테스트가 가능하도록 코드를 개선해보면 어떨까요?"*
+
+→ **도메인 핵심 로직 = 결정적 테스트 필수**. PR #137·#148·#90·#23·#26 의 *Ace 1↔11 양가성* / PR #46·#26 의 *블랙잭 룰 정확성* 결.
+
+### 11. `주석 → 함수명 개선`
+
+벅벅: *"함수가 어떤 일을 하는지 주석으로 부연설명을 잘 해주셨네요. 👍 이처럼 주석은 코드를 이해하는 데 큰 도움이 되지만, 대체로 주석은 아래와 같은 이유로 유지보수가 잘 되지 않습니다. 1. 다른사람이 작성한 주석은 건드리기가 껄끄럽다. 2. 주석을 수정하지 않아도 코드가 동작하는데 문제가 없다. 그래서 주석의 순기능이 점점 퇴색되게 됩니다. 주석에서 설명하고 하는 바를 최대한 함수명에 잘 드러낼 수 있도록 함수명을 개선해보면 어떨까요?"*
+
+→ **주석 vs 함수명**:
+- *주석 = 코드 변경 시 함께 변경 X 위험*.
+- *함수명 = 코드 변경 시 함께 변경 (컴파일러 강제)*.
+- *복잡한 함수 → 함수명 + 변수명 자가 설명*. PR #46 (말리빈 *라면 비유*) 결.
+
+## 리뷰어 의견 요지 (벅벅 / BeokBeok) — *신규 reviewer*
+
+21 코멘트 특징:
+
+- **요구사항 어휘** — *"프로그래밍 요구사항은 아래와 같은 항목이 있습니다"* (3 회) — **블랙잭 미션 요구사항 명시 인용**. PR #20·#64·#110 (페로로 요구사항 인용) 결.
+- **객체지향 원칙 명시 (LSP / SRP)** — *"객체지향의 원칙 중 LSP 라는 것이 있습니다"* / *"객체지향 원칙 중 SRP에 대해서 학습해보시고"* — **원칙 명시 + 학생 자가 학습 권유**. PR #137·#148·#151·#146 의 *조영호 어휘* 결의 *원칙 어휘*.
+- **외부 글 첨부** — Kotlin 공식 문서 (when vs if). PR #26·#23·#95·#74 결.
+- **메타 질문 + 학생 자가 답변 유도** — *"abstract와 open의 차이점은 무엇일까요?"* / *"ACE는 어떤 경우에 11이 되고 어떤 경우에 1이 될까요?"* — **학생 자가 학습 가시화**.
+- **자가 부연 어휘** — *"제가 설명이 조금 부족한 것 같네요"* + URL 자가 참조. PR #95·#23·#99 결.
+- **`👍` 칭찬 + 권고 분포** — *프로퍼티 오버라이딩, 카드 섞기, ACE 계산, abstract, MutableList 캡슐화, private 생성자, 주석* 칭찬 7회 + 권고 14회. 균형 잡힌 분포.
+
+## 대표 인용
+
+> *"abstract class : 인스턴스화 할 수 없습니다. 또한 하위 클래스에서 구현이 없는 abstract method 를 필수로 override 해야 합니다. open class : 인스턴스화 할 수 있습니다. 하위 클래스에서 open fun 을 그대로 쓰거나 override 해서 사용할 수 있습니다."* — SeongHoonC (Kotlin 어휘 학생 자가 정리)
+
+> *"상위타입인 List 를 캡슐화하면 하위타입 MutableList 또한 받을 수 있습니다. 현재 가변리스트를 외부에서 받는 구조입니다. 하지만 가변 리스트가 돌아다니면 값이 훼손될 수 있습니다. 때문에 불변 리스트 형태로 받고 가변리스트로 변환하도록 변경하겠습니다."* — SeongHoonC (LSP 자가 학습 + Kotlin List vs MutableList 인지)
+
+> *"같은 클래스 내부에서 호출되는 private 함수인데 Int 타입 포장이 필요한가요...? 잘 모르겠습니다..!!"* — SeongHoonC (학생 자가 학습 갭 명시)
+
+> *"점수에 해당하는 타입(Int)도 로직이 존재합니다. (최대 점수는 몇점까지 가능한지, 상황에 따라 ACE가 있을 때 점수 계산이 어떻게 되는지 등) 즉, Person 클래스는 플레이어의 책임 뿐만 아니라 점수와 관련된 책임도 가지고 있습니다. 객체지향 원칙 중 SRP에 대해서 학습해보시고, 코드를 개선해보면 어떨까요?"* — BeokBeok (SRP 어휘 + 원시값 포장 책임 어휘)
+
+> *"생성자가 없는 클래스는 오직 프로퍼티와 함수만 갖기 때문에, 다른 객체들과 구별하기 어렵습니다."* — BeokBeok (생성자 = 객체 invariant 어휘)
+
+> *"제가 설명이 조금 부족한 것 같네요."* — BeokBeok (reviewer 자가 부연 어휘)
+
+## 얻은 교훈
+
+1. **`abstract` vs `open` Kotlin 어휘 학생 자가 정리** — *abstract = 인스턴스화 X + override 강제 / open = 인스턴스화 O + override 선택*. **MCP 룰 후보 `abstract-without-abstract-method`**. PR #74·#95·#108·#133·#137·#147 와 같은 결.
+
+2. **LSP + List vs MutableList 타입 계층** — *MutableList ⊆ List* (Kotlin 타입 계층). *List 캡슐화 시 MutableList 도 받음 → 외부에서 캐스팅 후 변경 가능* = *LSP 위반 가능성*. *불변 List 받고 내부 MutableList 변환* 정공. PR #74 (송핑크 *불변 객체 자가 학습*) / PR #46 (krrong *backing property*) 결.
+
+3. **`생성자 = 객체 invariant 명시`** = *행동만 가진 클래스 = static helper 와 구별 어려움*. **MCP 룰 후보 `class-without-state`**. PR #46 (Calculator object) 결.
+
+4. **`top-level 상수` vs `object 상수`** — *전역 접근 + 분산 위험* vs *그룹핑 + 명시적 컨테이너*. *상수 다중 = object 응집 정공*.
+
+5. **`테스트 명 ≠ 검증 내용 = 명세서 불일치`** — *반드시 성공하는 테스트 = 무의미*. *결정적 카드 검증 + 의도 일치*. PR #23·#26·#39·#46·#74·#95·#99 결.
+
+6. **`원시값 포장 = SRP 적용`** — *`Int 점수` + 도메인 로직 (max, ACE) = Person 의 다중 책임* → *`Score` 별도 객체 + Person 은 협력*. **MCP 룰 후보 `primitive-with-domain-logic`**. PR #131·#136·#146·#147·#70·#26·#43 결.
+
+7. **`주석 vs 함수명`** — *주석 = 코드 변경 시 함께 변경 X 위험* / *함수명 = 컴파일러 강제 + 자가 설명*. PR #46 (말리빈 *라면 비유*) 결.
+
+8. **`when vs if 3 분기 이상` Kotlin 어휘** — *Kotlin 공식 문서 인용*. PR #26 (잭슨 *동일 외부 글*) 결의 *2023년 3월 코호트 reviewer 공통 패턴*.
+
+9. **`패키지 = 응집 단위`** — *상수 패키지 + 로직 객체 = 응집 위반*. *Decision (로직 보유 enum) ≠ constants 패키지*. **MCP 룰 후보 `package-cohesion`**.
+
+10. **`init 블록 = 객체 생성 시 invariant 보장`** — *카드 섞기를 init 에서 강제* = *외부 호출 누락 위험 차단*. PR #146 결.
+
+11. **`요구사항 인용` reviewer 어휘** — *"프로그래밍 요구사항은 아래와 같은 항목이 있습니다"* — *블랙잭 미션 명시 요구사항을 reviewer 가 그대로 인용 + 학생 적용 권유*. PR #20·#64·#110 (페로로) 결.
+
+12. **`SRP / LSP / DIP` 원칙 명시 어휘** — *벅벅이 *원칙 약어 직접 명시 + 학생 자가 학습 권유*. **MCP `oh-my-oop` 룰 의 *guideline* 필드와 일치**.
+
+13. **신규 reviewer 등장 (BeokBeok)** — 2023년 3월 코호트 또 다른 reviewer. *말리빈/잭슨 + BeokBeok* = 3 reviewer 다양성 확보 (2023년 3월 시기).
+
+14. **외부 글 첨부 패턴 (Kotlin 공식 문서)** — *2023년 3월 코호트 reviewer 들 (말리빈/잭슨/벅벅) 공통 패턴*. PR #26·#23 결.

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

@@ -0,0 +1,227 @@
+# PR #54 — [베르] 2단계 블랙잭
+
+- **Reviewee:** [@SeongHoonC](https://github.com/SeongHoonC) (베르)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/54
+- **단계:** 2단계
+- **리뷰어:** [@BeokBeok](https://github.com/BeokBeok) (벅벅)
+- **라인 코멘트:** 13 스레드 — *학생 자가 답변 3 thread + PR 본문 상태 패턴 처음 적용 + 점진적 변경 어려움 메타 / 프로퍼티 = 상태 / 함수 = 행동 + 불필요 간접 호출 = 분석 부담 (PR #72 반대 어휘) + 요구사항 vs 완성도 추가 제약 + 람다 다중 전달 흐름 파악 부담 + val vs var 오버라이딩 어휘*
+- **SeongHoonC 양 단계 완성** (1단계 #16 batch 14).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 상태 패턴 처음 적용 + 점진적 변경 학생 자가 어려움
+
+PR 본문:
+
+> *"먼저 상태패턴 적용 허락해주신 리뷰어님 감사드립니다!*
+>
+> *처음 적용해 보는 것이라 어려웠지만 열심히 했습니다!*
+>
+> ***기존에 있던 파일을 유지한채로 점진적으로 변경하느라 특히 더 힘들었던 것 같습니다..***
+>
+> *코드가 많이 바껴서 힘드시겠지만.. 리뷰 잘부탁드립니다!"*
+
+→ **MCP 룰 `pr-body-incremental-refactor-difficulty`** ⭐⭐ 신규 — *기존 코드 유지 + 점진적 리팩터링 어려움 학생 자가 어휘*. PR #154 (`pr-body-restart-from-scratch` 갈아엎기) 결의 *리팩터링 방향* 다른 축 — *점진적 vs 갈아엎기 어려움 어휘*.
+
+### 2. 상태 패턴 적용 칭찬 (Thread 1·전체)
+
+reviewer: *"대체로 상태 패턴을 잘 적용해주셨네요. 👍"*
+
+### 3. 람다 도메인↔View 의존성 끊기 칭찬 (Thread 10)
+
+reviewer:
+
+> *"전반적으로 람다를 활용하여 domain과 view의 의존성을 잘 끊어내주었습니다. 👍"*
+
+→ PR #62·#42 (콜백·HOF 어휘) 결 합류 누적 다수.
+
+## 못한 점 (설계 관점)
+
+### 1. 프로퍼티 = 상태 / 함수 = 행동 (Thread 1) — 정점
+
+```kotlin
+val hasAce: Boolean
+    get() = cards.any { it.isAce() }
+```
+
+reviewer:
+
+> *"hasAce라는 변수를 잘 정의해주셨네요. 👍 **다만, 프로퍼티는 행동이 아닌 상태를 가져야만 합니다. 행동인 경우에는 함수로 구현해보면 어떨까요?**"*
+
+→ **MCP 룰 `property-vs-function-state-vs-behavior`** ⭐⭐⭐ **신규 정점** — *속성 = 상태 / 함수 = 행동 어휘*. PR #62 (haeum808 PR 본문 *계산 프로퍼티 vs 메서드 자가 질문*) 결 합류 누적 2 PR → ***프로퍼티 vs 메서드 어휘 정점*** ⭐⭐⭐.
+
+### 2. 불필요 간접 호출 = 분석 부담 (Thread 5) — PR #72 반대 어휘
+
+```kotlin
+// Person.kt
+fun getHandCards(): List<Card> = state.hand.cards
+fun getPlayerProfit(...): Profit = state.profit(...)
+```
+
+reviewer:
+
+> *"이 함수들이 반드시 필요한 함수들인지 고민해보면 좋을 것 같아요. **불필요한 \"간접 호출\"은, 코드 분석 시 함수 호출부를 계속해서 타고 들어가야 하므로, 오히려 코드를 이해하기 복잡하게 만들어요.** (getHandCards, getPlayerProfit 포함)"*
+
+학생 자가 답변:
+
+> *"상태값을 변화시키는 것과 상태값에서 값을 가져오는 것에 차이를 두는 것이 좋은 것 같습니다.*
+>
+> *. 으로 타고 들어가는 것을 줄이고자 get을 호출하지 않고 **불필요한 코드를 많이 늘리는 것은 코드를 복잡하게 만드는 것이므로 동의합니다.**"*
+
+→ **MCP 룰 `unnecessary-indirect-call`** ⭐⭐⭐ **신규** — *불필요한 위임 = 분석 부담*.
+
+→ **MCP `oh-my-oop` 핵심 가치 트레이드오프 어휘 정점**: PR #72 (`forward-compatible-delegation` *로직 없는 위임 = 향후 유지보수 가치*) 결과 **반대 어휘** — ***위임 가치 vs 부담 트레이드오프*** ⭐⭐⭐ 신규. *상황에 따라 위임이 가치 / 분석 부담* — **단일 답 X**.
+
+→ **학생 자가 *상태 변화 vs 값 조회 차이* 자가 자각** ⭐⭐ — *Tell-Don't-Ask 어휘 학생 측 자각*.
+
+### 3. 요구사항 vs 완성도 추가 제약 (Thread 3)
+
+```kotlin
+// Participants.kt - 이름 중복 검증 추가
+require(names.toSet().size == names.size)
+```
+
+reviewer:
+
+> *"플레이어의 이름이 중복이 되지 않아야한다는 요구사항이 있을까요? 만약, 플레이어 중 동명이인이 있다면 게임을 할 수 없게 되는걸까요?*
+>
+> ***프로그램의 완성도를 높히는 것도 중요하지만, 가급적이면 요구사항을 준수하도록 프로그램을 작성해보면 어떨까요?***"*
+
+학생 자가 답변:
+
+> *"배팅 금액을 찾을때 객체를 key 로 하도록 하고 이름 중복 체크를 없애는 방식으로 변경하였습니다!"*
+
+→ **MCP 룰 `requirement-as-constraint-not-additional`** ⭐⭐⭐ **신규** — *완성도 추가 제약 ≠ 요구사항*. PR #146·#151 (반란군 비유 *요구사항 vs 좋은 설계 자유 인정*) 결의 *요구사항 어휘* 누적 강화.
+
+→ **`object-as-key-not-name`** ⭐⭐ — *Map<Person, Int> = 객체 자체 키 + 이름 중복 의존 X*. PR #72 (`jvm-type-erase-firstclass-key`) 결 합류.
+
+### 4. `val` vs `var` 오버라이딩 어휘 (Thread 4)
+
+```kotlin
+abstract class Person {
+    abstract val state: State  // 또는 var
+}
+
+class Player : Person() {
+    override var state: State = ...
+}
+```
+
+reviewer:
+
+> *"부모 클래스에서 val을 사용해도, 자식 클래스에서 var로 오버라이딩이 가능해요."*
+
+학생 자가 답변 + reviewer 부연:
+
+> *"만약 부모 클래스에서도 객체를 생성해서 state를 변경한다면, var을 사용하시는 것이 좋습니다. 부모 클래스에서는 state를 변경하지 않고 자식 클래스에서만 state를 변경한다면, **부모에서는 val을 사용하고 자식에서는 var로 오버라이딩해서 사용하는 것을 다른 개발자들에게도 유도할 수 있는 장점이 있습니다.** 😅 하지만 지금 구조에서는 부모 클래스에서도 stay 함수를 통해 state를 변경하고 있으므로, var을 사용하는 것이 좋겠네요. 👍"*
+
+→ **MCP 룰 `val-vs-var-override-discipline`** ⭐⭐⭐ **신규** — *부모 val + 자식 var 오버라이딩 = 다른 개발자 유도 어휘*. PR #154 (`state-pattern-external-mutation-risk`) 결의 *상태 변경 위치 제어* 다른 축 — *상속 시점 가시화*.
+
+### 5. 람다 다중 전달 = 흐름 파악 부담 (Thread 10)
+
+```kotlin
+// handOutCardToPlayers -> handOutCardsToPlayer -> handOutCard
+// 모든 단계에 printPlayerCards 람다 전달
+```
+
+reviewer:
+
+> *"람다를 활용하면 위와 같은 장점이 있습니다. **지금 구조와 같이 handOutCardToPlayers -> handOutCardsToPlayer -> handOutCard 함수를 호출하면서 printPlayerCards 라는 람다를 계속해서 전달하게 되면, 나중에 코드를 분석할 때 람다로 무엇이 전달되는지 흐름을 파악하기 어려워지게 됩니다.** 수정을 권장하는 것이 아니므로 참고 부탁드립니다. 😄"*
+
+→ **MCP 룰 `lambda-chain-as-trace-complexity`** ⭐⭐⭐ **신규** — *람다 다중 전달 = 흐름 파악 부담 + reviewer 수정 권장 X 메타*.
+
+→ **`reviewer-recommend-not-required-meta`** ⭐⭐ — *"수정을 권장하는 것이 아니므로 참고 부탁드립니다"* — PR #62·#89 (`reviewer-self-reflection-mission-goal-return`) 결의 *reviewer 자가 강요 회피* 누적 6 PR 강화.
+
+### 6. GameProfit god-object + 디미터 법칙 (Thread 6)
+
+```kotlin
+// GameProfit
+participants.dealer.getPlayerProfit(player.state, playerBettingMoney).value
+```
+
+reviewer:
+
+> *"GameProfit 클래스는 participants, dealer, profit등 너무 많은 것을 알고 있어요. 디미터 법칙이 무엇인지 학습해보시고, 어떻게 개선하면 좋을지 고민해보면 어떨까요?"*
+
+→ **god-object + 디미터** = PR #38·#89 결 누적.
+
+### 7. `of` 함수 두 가지 일 (Thread 7)
+
+reviewer: *"`of` 함수는 두 가지 이상의 일을 하고 있어요. (Score 객체 생성, 점수 계산 등) 하나의 함수에서는 한 가지 일만 할 수 있도록 코드를 개선해보면 어떨까요?"*
+
+→ **함수 한 가지 일** = 누적 다수.
+
+### 8. 함수명 vs 구현 일치 (Thread 8)
+
+reviewer: *"함수명만 보면 ACE의 개수와 관련된 로직을 테스트하는 것으로 보이지만, 구현부에서는 ACE를 갖고 있는지에 대한 여부를 판단하고 있네요. 테스트를 하고자 하는 것과 함수명을 서로 일치시켜보면 어떨까요?"*
+
+→ **함수명 = 구현 의도 일치** = 누적 15+ PR.
+
+### 9. 부생성자 vs 팩토리 메서드 (Thread 2)
+
+reviewer: *"부생성자를 통해서 money와 rate를 가지고 Profit 객체를 만들 수 있도록 잘 구현해주셨네요. 👍 지금도 좋지만, \"팩토리 메서드\"에 대해서 학습해보시고 \"팩토리 메서드\"를 적용해보면 어떨까요?"*
+
+→ **팩토리 메서드** = 누적 다수.
+
+### 10. 블랙잭 수익 테스트 추가 (Thread 9)
+
+reviewer: *"플레이어가 블랙잭으로 이겼을 때에 대한 수익도 테스트 코드를 작성해보면 어떨까요?"*
+
+→ **블랙잭 양측 도메인 룰 테스트** = 누적.
+
+### 11. private 접근자 + 개행 컨벤션 (Thread 0·11·12)
+
+reviewer (Thread 0): *"클래스 내부에서만 사용하는 상수라면, private 접근자를 붙여보면 어떨까요?"*
+
+reviewer (Thread 11): *"변수와 함수 사이는 개행으로 구분해주는 것이 좋습니다."*
+
+→ 가독성 컨벤션 = 누적.
+
+## 대표 인용
+
+> [BeokBeok Thread 1]
+> *"프로퍼티는 행동이 아닌 상태를 가져야만 합니다. 행동인 경우에는 함수로 구현해보면 어떨까요?"*
+
+→ **프로퍼티 vs 함수 = 상태 vs 행동 어휘 정점**.
+
+> [BeokBeok Thread 5]
+> *"불필요한 \"간접 호출\"은, 코드 분석 시 함수 호출부를 계속해서 타고 들어가야 하므로, 오히려 코드를 이해하기 복잡하게 만들어요."*
+
+→ **불필요 위임 = 분석 부담 어휘 (PR #72 반대 어휘)**.
+
+> [BeokBeok Thread 3]
+> *"프로그램의 완성도를 높히는 것도 중요하지만, 가급적이면 요구사항을 준수하도록 프로그램을 작성해보면 어떨까요?"*
+
+→ **요구사항 vs 완성도 추가 제약 어휘**.
+
+> [BeokBeok Thread 4]
+> *"부모에서는 val을 사용하고 자식에서는 var로 오버라이딩해서 사용하는 것을 다른 개발자들에게도 유도할 수 있는 장점이 있습니다."*
+
+→ **val/var 오버라이딩 어휘**.
+
+> [BeokBeok Thread 10]
+> *"람다를 계속해서 전달하게 되면, 나중에 코드를 분석할 때 람다로 무엇이 전달되는지 흐름을 파악하기 어려워지게 됩니다. 수정을 권장하는 것이 아니므로 참고 부탁드립니다."*
+
+→ **람다 다중 전달 = 흐름 부담 + reviewer 권장 X 메타**.
+
+> [SeongHoonC Thread 5]
+> *". 으로 타고 들어가는 것을 줄이고자 get을 호출하지 않고 불필요한 코드를 많이 늘리는 것은 코드를 복잡하게 만드는 것이므로 동의합니다."*
+
+→ **학생 자가 위임 비용 자각 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **프로퍼티 = 상태 / 함수 = 행동** — **MCP 룰 `property-vs-function-state-vs-behavior` 후보** ⭐⭐⭐ 정점. PR #62 결 누적 2 PR.
+2. **불필요 위임 = 분석 부담 (PR #72 반대 어휘)** — **MCP 룰 `unnecessary-indirect-call` 후보** ⭐⭐⭐. PR #72 `forward-compatible-delegation` 트레이드오프.
+3. **요구사항 vs 완성도 추가 제약** — **MCP 룰 `requirement-as-constraint-not-additional` 후보** ⭐⭐⭐.
+4. **val/var 오버라이딩 어휘** — **MCP 룰 `val-vs-var-override-discipline` 후보** ⭐⭐⭐.
+5. **람다 다중 전달 = 흐름 파악 부담** — **MCP 룰 `lambda-chain-as-trace-complexity` 후보** ⭐⭐⭐.
+6. **점진적 리팩터링 어려움 학생 자가 어휘** — **MCP 룰 `pr-body-incremental-refactor-difficulty` 후보** ⭐⭐.
+7. **reviewer 수정 권장 X 메타 누적 6 PR 강화** = MCP 핵심 가치 어휘 정점.
+
+## 메타 노트
+
+- **SeongHoonC 양 단계 완성 (1단계 #16 batch 14 → 2단계 #54)** — 1단계 → 2단계 *상태 패턴 처음 적용 + 점진적 변경 학생 자가 어려움 어휘*.
+- **BeokBeok reviewer 누적 4 PR (#12 + #15 + #38 + #47 + #54)** — 일관 가이드 + 학생 자가 답변 유도 어휘.
+- **위임 가치 vs 부담 트레이드오프** = MCP `oh-my-oop` 핵심 가치 어휘 정점 — PR #72 (위임 가치) vs PR #54 (위임 부담) — **단일 답 X 어휘**.
+- **reviewer 자가 강요 회피 어휘 누적 6 PR** (#62 ghojeong + #89 ghojeong + #115 laco-dev + #73 ghojeong + #106 말리빈 + #54 BeokBeok) — MCP `oh-my-oop` 핵심 가치 어휘 정점.