oh-my-oop 0.2.0

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

@@ -0,0 +1,206 @@
+# PR #13 — [블랙잭 1단계] 뽀또 미션
+
+- **Reviewee:** [@hyunji1203](https://github.com/hyunji1203)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/13
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 19 스레드 — *View 게임 단계별 분리 자가 시도 + Kotlin 어휘 (extension function vs object function vs top-level) 매우 긴 자가 학습*
+- **신규 reviewee** (2023년 3월 코호트). PR #11·#31·#66 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 시도 명시** — *"이번에 새롭게 시도해 본 부분이, View 부분을 Input과 Output으로 나눠 작성하지 않고 게임의 단계별로 필요한 view로 묶어 작성해보았습니다."* — **`view-by-stage-split` 자가 시도** (PR #88·#131 결).
+- **`인터페이스 활용`** — vagabond95: *"인터페이스 활용 👍"* (CardFactory).
+- **`backing field`** — vagabond95: *"backing field 활용 👍"* (Cards).
+- **`CardDistributeCondition` 별도 분리** — vagabond95: *"별도로 잘 분리해주셨네요 👍"*.
+- **`함수 재활용`** + **`구현 방식 통일`** + **`코드 흐름 명확화`** — vagabond95 칭찬 3회: *"전반적으로 코드 흐름이 아주 명확해졌습니다! 👍"*. **피드백 반영 후 칭찬**.
+- **`object function vs top-level extension function` 학생 자가 매우 긴 학습 + reviewer 답변** — vagabond95: *"비즈니스 로직을 이렇게 별도 클래스로 함수로 빼주시는 것과, 필요한 곳에서 내부 함수로 선언하시는 각각의 기준이 있으실까요?"* + 학생 자가 깊은 답변 + 자가 의문: *"실례되지 않는다면 리뷰어님께서는 '별로 클래스 분리 or 필요한 곳 내부 함수 선언' 을 어떤 기준으로 나누시는지 여쭤보고 싶습니다!"* + reviewer 매우 긴 답변:
+
+> *"우선, 클래스의 상태를 이용하여 '스스로' 처리할 수 있고, 아키텍처 레이어 상으로도 적절한 처리 (= domain 에선 domain 과 연관된 로직) 함수의 경우에는 자연스럽게 클래스 내부에 함수를 선언해요. 남은건, 일종의 Utils 성 클래스 or 외부 아키텍처 레이어에 적합한 로직 (= domain 의 결과를 view 에서 활용하기 위해서 가공) 등이 있을 것 같아요. 이에 대해 java -> kotlin 으로 넘어온 후에는 다음과 같은 기준을 가지고 처리하고 있어요. 1. 비교적 단순한 가공 / 변환의 로직 : top level extension function 2. 비즈니스 로직이 들어가는 로직 or 1번의 사례에서 원시값에 대한 케이스 : object function (= util class) ..."*
+
+**reviewer 의 *Kotlin 어휘 사용 기준* 매우 긴 메타 답변 + 학생 자가 학습 모범** — PR #11·#31·#66·#46·#91 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `misc` 패키지 — 일반 명명 + etc/common/misc 함정
+
+vagabond95: *"해당 클래스만 misc 패키지로 두신 이유가 있을까요?"*
+
+학생: *"게임의 다양한 곳에서 자주 쓰일 상수를 넣을 클래스를 찾다가, 게임 규칙이라는 클래스에 넣으면 어떨까 생각해 기타 패키지 안의 GameRule을 만들어 저장해보았습니다! 혹시 이런 방식 말고 그냥 존재하는 다른 클래스에 해당 상수를 놓는 방식이 더 좋을까요?"*
+
+vagabond95: *"우선, etc / common / misc 같은 패키지는 무엇이든 들어갈 수 있기 때문에 저같은 경우에는 최대한 만드는 것을 뒤로 미루려고 합니다. 그리고 기존에 만들어두신 다른 패키지로 들어가기에도 적절해보여서요! 만약 공용으로 사용될 파일을 둘 수 있는 패키지를 두고 싶을지라도, view / model / entity 등의 하위 패키지로 두어 한번더 구분을 지어주면 좋을 것 같아요."*
+
+→ **`etc / common / misc` 패키지 = 일반 명명 안티패턴**:
+- *무엇이든 들어갈 수 있음 = 비대화 + 응집 X*.
+- *생성 시점 = 마지막까지 미루기 + 적합 패키지 우선 탐색*.
+
+**MCP 룰 후보 `etc-package-anti-pattern`** = *etc/common/misc 패키지 = 마지막 수단*. PR #11 (vagabond95 *Const.kt 일반 명명*) / PR #16 (BeokBeok *BlackJackRule*) 결.
+
+### 2. `Init` 클래스명 — 일반 명명
+
+vagabond95: *"Init 이라는 단어는 common 한 네이밍이라 어떤 함수가 들어가도 크게 어색하지 않기 때문에 해당 클래스로 view 로직이 몰릴 수 있을 것 같아요. 좀 더 구체적인 이름을 지어보는 것은 어떨까요?"*
+
+학생: *"게임의 초기세팅을 관리하는 뷰라는 뜻으로 GameSetView라는 이름으로 수정하였습니다!"*
+
+→ **`vagueName` + 비대화 시그널**. PR #16·#11·#107·#9 결.
+
+### 3. `it2` 변수명 — vagueName 강화
+
+vagabond95: *"`it2` 같은 네이밍은 무엇을 의미하는지 알기 어려워요. 좀 더 구체적인 이름을 사용해주세요."*
+
+학생: *"가독성이 좋아지도록 it은 type으로 it2는 number로 수정하였습니다!"*
+
+→ **중첩 람다 = `it` 다중 = 모호**. 명시적 파라미터명 정공. PR #107 (junseo511 *it → player*) / PR #95·#39 결.
+
+### 4. `RandomCardFactory` 인덱스 예외 처리
+
+vagabond95: *"해당 함수는 index 가 size 를 넘어갈 경우 예외가 발생할 것 같아요. 별도 처리가 필요하지 않을까요?"*
+
+학생: *"넵! 처리했습니다!"*
+
+→ **경계 조건 방어**. PR #46·#26·#9 결.
+
+### 5. `CardNumber` ACE 비즈니스 로직 enum 누수
+
+vagabond95: *"ace 에 대한 비즈니스 로직을 다른 곳으로 이동시켜보는 것도 좋을 것 같아요. enum value 가 선언되는 과정에서 비즈니스 로직이 많아질수록 코드를 이해하기 어렵기도 하고, 함수형태가 가독성이 그리 뛰어나지 않을 것 같아요!"*
+
+학생: *"해당 비즈니스 로직을 관리할 클래스를 새로 만들어 로직을 분리시켰습니다!"*
+
+→ **enum 부가 로직 분리** — PR #137 (HamBeomJoon *Rank.label*) / PR #16 (SeongHoonC *Score 분리*) / PR #43 (chws0508) / PR #74 (송핑크 *Rank 보너스 점수*) 결.
+
+### 6. `CardDistributeCondition` 입력 판단 = View 영역
+
+vagabond95: *"`입력` 에 대한 판단 및 관련된 값은 view 에서 다뤄야할 내용 아닐까요?"*
+
+학생: *"맞습니다! 생각해본 결과 해당 로직을 아예 삭제하는 방향으로 바꿨습니다"*
+
+→ **불필요 객체 자가 삭제**. PR #145·#146·#31 결.
+
+### 7. `Cards.value` 매번 `toList()` 호출 비효율
+
+vagabond95: *"현재는 매번 value 를 가져올 때마다 toList() 가 호출 될 것 같은데, 좀 더 효율적인 방식으로 개선해볼 수 있을까요?"*
+
+→ **불변 객체 + 매번 계산** = *PR #39 (rhthrhrl0 *immutable-recompute-on-call*)* 결.
+
+### 8. `ResultView` 문자열 상수화 + ViewUtils 응집
+
+vagabond95 다중: *"해당 문자열들도 상수로 관리해주면 좋을 것 같아요~!"* + *"이 부분도 ViewUtils 로 관리해보는 것은 어떨까요?"* + *"혹은 View Utils 내용을 외부로 꺼내도 좋겠구요 :) 핵심은, 비슷한 일을 하는 코드는 비슷한 방식으로 접근할 수 있으면 사용자 입장(=다른 개발자)에서 좋을 것 같아요."*
+
+→ **비슷한 일 = 비슷한 방식 (일관성)**. PR #11 (vagabond95 *inconsistent-accessor-pattern*) 결.
+
+### 9. `NumberStrategy` object 도입 + 클래스 분리 기준 자가 학습
+
+vagabond95: *"해당 클래스는 별도로 상태를 가지고 있지 않으므로 object 로 관리해도 좋을 것 같아요!"*
+
+이어서 *클래스 분리 vs 내부 함수 기준 자가 질문* → 위 §잘한점 학생/reviewer 매우 긴 토론.
+
+학생 자가 답변: *"사실 이번 Ace 판단 로직을 수 결정 도메인으로 생각한 후 수 결정 도메인이 겹치는게 없다 판단해서, NumberStrategy() 로직 클래스를 만들어 그 안에 선언했었습니다! 하지만 리뷰어님의 말씀대로 해당 클래스는 별도의 상태를 갖고 있지 않은 점, 카드의 수 합을 계산하는 함수가 있는 class에 선언해도 카드의 합을 계산한다는 역할의 통일성이 있다는 점을 고려해 Cards의 클래스안에 내부 함수 선언으로 수정하였습니다!"*
+
+→ **3 가지 학습**:
+
+#### 9.1. *상태 없는 클래스 = object 정공*
+
+PR #46 (krrong *Calculator object*) / PR #11 (ki960213 *Deck object 자가 학습*) 결.
+
+#### 9.2. *역할 통일성 vs 별도 분리*
+
+- *카드 합 계산 = Cards 의 역할* → *Cards 내부 함수로 응집*.
+- *완전 별도 로직 = 별도 클래스 (object/class)* 분리.
+
+#### 9.3. *reviewer 의 Kotlin 어휘 사용 기준 메타 답변 (위 §잘한점)*
+
+**Kotlin top-level extension function vs object function = 사용 기준 명시 메타 학습 모범**.
+
+### 10. `함수형 파라미터 중첩 + it 모호`
+
+vagabond95: *"중첩하여 함수형 파라미터를 전달할 경우 it 보다 명시적인 이름을 사용해보는 것은 어떨까요?"* + *"전반적으로 함수를 전달하여 카드를 분배하는 방식으로 구현되고 있는데, 중첩하여 구성될수록 흐름을 따라가기 어려운 것 같아요. ㅜㅜ"*
+
+학생: *"it 대신 player 이름으로 변경 후 흐름을 따라가기 쉽도록 함수 중첩 전달 방식에서 컨트롤 기반 제어 방식으로 수정했습니다!"*
+
+→ **람다 중첩 = 흐름 추적 어려움**. PR #145·#107·#137 결.
+
+### 11. `BlackjackStage` 구현 방식 통일 (직접 vs 외부 위임)
+
+vagabond95: *"어떤 함수는 카드 분배에 직접 관여하고, 어떤 함수는 카드 분배를 외부로 위임하고 있어요. 구현방식을 통일해보면 좋을 것 같아요."*
+
+→ **일관성 = 비슷한 일 비슷한 방식**.
+
+### 12. `domain 이 print 가정` X
+
+vagabond95: *"domain 에서 `print 가 될 것이다` 라고 가정하는 것이 적절할까요? domain 은 비즈니스 로직만 수행하고, 외부에서 print 에 관여 하도록 수정해볼 수 있을까요?"*
+
+학생: *"컨트롤러에서 print를 관여하도록 수정하였습니다!"*
+
+→ **MVC 경계 + Tell-Don't-Ask**. PR #66·#26·#23·#16·#9 결.
+
+### 13. `"y" 상수화`
+
+vagabond95: *"'y' 값은 상수로 선언하면 재활용 및 수정에 용이할 것 같아요."*
+
+→ **상수 응집**. PR #145·#31 결.
+
+### 14. `extension function` 활용
+
+vagabond95: *"extension function 방식을 이용하면, 좀 더 자연스럽게 사용이 가능할 것 같아요. `cardNumber.toXXX()`"*
+
+→ **Kotlin 확장 함수 어휘**. PR #9·#46·#31·#107 결.
+
+### 15. `when 활용`
+
+vagabond95: *"when 을 활용해보는 것은 어떨까요?"*
+
+→ **Kotlin when 어휘**. PR #91·#9·#26·#43·#16 결.
+
+### 16. `distributePlayer 재활용`
+
+vagabond95: *"distributePlayer(..) 함수를 재활용해보는 것은 어떨까요?"*
+
+→ **DRY**. PR #9·#31·#46 결.
+
+## 리뷰어 의견 요지 (vagabond95)
+
+19 코멘트 특징 (PR #11·#31·#66 와 동일 reviewer):
+
+- **Kotlin 어휘 사용 기준 매우 긴 메타 답변** — *top-level extension function vs object function vs 내부 함수* 사용 기준 명시. **PR #11·#31·#66 와 다른 특징** = *학생 자가 질문 시 매우 긴 답변*.
+- **칭찬 분포** — *코드 흐름 명확화, 인터페이스 활용, backing field, 별도 분리* 등 6회 칭찬 + 권고 13회 = 균형.
+- **메타 질문 어휘** — *"어떤 기준이 있으실까요?"*, *"어떤 문제점이 생길 수 있을까요?"*.
+- **`view-by-stage-split` 자가 시도 인정** — *학생이 PR 본문에 시도 명시 + reviewer 가 *이름 구체화* 권고 (Init → GameSetView)*.
+
+## 대표 인용
+
+> *"우선, 클래스의 상태를 이용하여 '스스로' 처리할 수 있고, 아키텍처 레이어 상으로도 적절한 처리 (= domain 에선 domain 과 연관된 로직) 함수의 경우에는 자연스럽게 클래스 내부에 함수를 선언해요. ... 1. 비교적 단순한 가공 / 변환의 로직 : top level extension function 2. 비즈니스 로직이 들어가는 로직 or 1번의 사례에서 원시값에 대한 케이스 : object function (= util class)"* — vagabond95 (Kotlin 어휘 사용 기준 메타)
+
+> *"etc / common / misc 같은 패키지는 무엇이든 들어갈 수 있기 때문에 저같은 경우에는 최대한 만드는 것을 뒤로 미루려고 합니다."* — vagabond95 (etc 패키지 안티패턴)
+
+> *"사실 이번 Ace 판단 로직을 수 결정 도메인으로 생각한 후 수 결정 도메인이 겹치는게 없다 판단해서, NumberStrategy() 로직 클래스를 만들어 그 안에 선언했었습니다! 하지만 리뷰어님의 말씀대로 (...) Cards의 클래스안에 내부 함수 선언으로 수정하였습니다!"* — hyunji1203 (역할 통일성 자가 학습)
+
+> *"실례되지 않는다면 리뷰어님께서는 '별로 클래스 분리 or 필요한 곳 내부 함수 선언' 을 어떤 기준으로 나누시는지 여쭤보고 싶습니다!"* — hyunji1203 (학생 자가 기준 의문)
+
+## 얻은 교훈
+
+1. **`etc / common / misc` 패키지 안티패턴** — *일반 명명 = 비대화 + 응집 X = 마지막 수단*. **MCP 룰 후보 `etc-package-anti-pattern`**. PR #11·#16 결.
+
+2. **`Kotlin 어휘 사용 기준` 메타 학습**:
+   - *클래스 상태 + 도메인 로직* → 내부 함수.
+   - *단순 가공/변환* → top level extension function.
+   - *비즈니스 로직 + 원시값* → object function (util class).
+   
+   **MCP 룰 후보 `kotlin-function-locus-criteria`**. PR #11·#46·#91·#107 결.
+
+3. **`상태 없는 클래스 = object 정공`** — PR #46·#11·#16 결.
+
+4. **`역할 통일성 vs 별도 분리`** — *카드 합 계산 = Cards 역할 → 내부 함수 응집*. PR #16·#43·#74 결.
+
+5. **`중첩 람다 + it 다중 = 흐름 추적 어려움`** — *명시적 파라미터명 정공*. PR #107·#145·#137 결.
+
+6. **`Init` 같은 일반 명명 = 비대화 시그널**. PR #16·#11·#107·#9 결.
+
+7. **`it2` 같은 변수명 = vagueName 강화**.
+
+8. **`불변 객체 + 매번 `toList()` 호출`** = *PR #39 immutable-recompute-on-call* 결.
+
+9. **`구현 방식 통일`** — *비슷한 일 = 비슷한 방식 (일관성)*. **MCP 룰 후보 `inconsistent-approach-pattern`**.
+
+10. **`view-by-stage-split` 자가 시도** — *PR 본문 명시 + 학습 가시화*. PR #88·#131 결.
+
+11. **`reviewer 가 Kotlin 어휘 사용 기준 매우 긴 답변` = 학생 자가 질문 트리거** — *학생 자가 *기준 의문* → reviewer 매우 깊은 답변*. PR #11·#46·#91·#107 결의 *학생 자가 의문 풍부 시리즈*.

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

@@ -0,0 +1,153 @@
+# PR #79 — [블랙잭 1단계] 하디 미션
+
+- **Reviewee:** [@ii2001](https://github.com/ii2001)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/79
+- **단계:** 1단계 (PR #78 dpcks0509와 *코드가 동일* — 페어 또는 fork 추정. 리뷰어/토론이 별개)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 30 (리뷰어 21 / 리뷰이 9)
+
+> ⚠ **노트:** 코드는 PR #78과 동일. *공통 안티패턴*은 PR #78 분석 참고하고, 본 파일은 *laco-dev의 시각*과 *학생의 자가 토론*만 다룬다.
+
+## 잘한 점 (설계 관점)
+
+- **`State` sealed interface 적용 + `Referee` 객체 분리 + `PlayerEntry` 일급 컬렉션** — PR #78 참고.
+- **학생이 PR 본문에 *TDD vs 일괄 구현* 자가 의문을 명시** — 리뷰어 코칭이 깊어지는 출발점 (못한 점 §1).
+- **후속 반영 — `ScoreCalculation` → `Hand` 내부 이동 + `Deck` class 전환 + `Hand.totalScore` custom getter로 동기화 해결**.
+
+## 못한 점 (설계 관점)
+
+### 1. PR 본문 — *TDD 부정* 발언
+
+학생: "처음부터 모델을 설계하고 코딩을 할 필요있을까..? 어차피 리펙토링을 할건데 *전부 구현해놓고 그때부터 리펙토링을 하면 안되는 것인가?*"
+
+리뷰어: "*TDD를 전면으로 부정하고 계시는군요..* 객체지향 프로그래밍에 있어서도 상당히 좋지 않은 접근입니다. 가장 작은 기능단위부터 설계를 하고 *협력관계를 만들어 객체들간의 설계를 만들어 갑니다*. 어차피 리팩토링을 한다면 --> 코드 *100번 넘게 다시 만들고 싶으시지는 않을거잖아요?* 😱" — *일괄 구현 후 리팩토링*은 *협력 관계 설계 누락*. 객체지향 설계는 *작은 협력 단위로 키워나감*. *큰 덩어리 후 분해*는 *원래의 형상에 갇힘*.
+
+### 2. *Controller가 Input + 예외처리* — 학생 자가 변호 + 리뷰어 반박
+
+학생: "저는 Controller에서 Input을 받고 예외처리까지 하는 것이 *MVC패턴에 더 잘 맞다고 생각*하는데 Input부분을 View에 꼭 넣어야 할까요?? 정말 많이 찾아본 결과 *사람마다 다를 수 있다*하고 많은 사람들이(+Gpt) Controller에서 수행을 하는것 같기에 이렇게 생각했었습니다!"
+
+리뷰어: "말씀하신 대로면 *MVC가 아니고 MC 패턴*이 아닌가요? *MVC 패턴에서 View 레이어를 만드는 이유가 무엇인가요?*" — *Input == 사용자와의 인터페이스 == View*. View 없는 MVC는 정의상 모순. *GPT 다수결*이 아닌 *각 레이어의 책임 정의*로 판단해야.
+
+### 3. View *3종 분리* (Input/Progress/Result) — 학생 자가 토론
+
+학생: "저는 View를 3가지로 나눴습니다 1. 사용자에게 입력을 받기 전 메세지를 보여줘야하는 View 2. 프로그램 진행상황에 나와야할 View 3. 최종적으로 결과만 출력하는 View 이 3가지로 나눠놓으면 *나중에 추가 기능을 넣을떄 올바른 위치에 편하게 올릴* 수 있을 것 같았습니다!"
+
+리뷰어: "*각 역할에 맞게 나누는 건 좋습니다*. 다만 모든 함수가 *최상위 함수로 선언*되어 있기 때문에, 사용하는 측 입장에서는 *어떤 역할인지 알기가 어려운 문제*가 있습니다. ```import blackjack.view.showHands``` ```import blackjack.view.showPlayerDrawDecision``` 객체지향 프로그래밍 학습을 하는 과정이니, *객체를 만들어서 코드가 동작하도록* 만들어 보면 좋겠습니다." — *역할 분리 자체*는 좋으나 *Kotlin top-level fun*으로만 두면 *import 위치*만 *분류 정보*를 보유. *클래스/object*로 묶어 *호출 시점에 역할*이 드러나게.
+
+### 4. `Hand(mutableListOf<Card>())` — 외부 mutable 참조 누수
+
+```kotlin
+class Hand(val cards: MutableList<Card>) {
+    // 호출자가 보유한 list 참조를 그대로 노출 → 외부에서 마음대로 add 가능
+}
+```
+
+리뷰어가 코드 예시로 *문제 시뮬레이션*:
+```kotlin
+val cards = mutableListOf<Card>()
+val hand = Hand(cards)
+cards.add(Card(...))    // hand 모르게 카드 추가
+cards.add(Card(...))
+cards.add(Card(...))    // 손패가 5장!
+```
+
+리뷰어: "아래 코드는 어떤 문제점을 가지고 있는지 알려주세요" — *방어적 복사 없이 외부 참조 보유*하면 *invariant 무방비*. `class Hand(private val _cards: MutableList<Card> = mutableListOf())` + `val cards: List<Card> get() = _cards` 가 자연. PR #28 (inseonyun)의 `Cards` 방어적 복사가 정답 패턴.
+
+### 5. `A 카드 기본 1점` vs `기본 11점` — 학생 자가 의문 + 리뷰어 신중 답변
+
+학생: "*꼭 A카드의 점수가 1점 이어야 하나요?* 기본적으로 11점이라 생각하고 한다면 문제가 생기는 것인가요??? 만약 사용자가 *A를 13점으로 바꾸고 싶을 수도 있다*고 생각합니다.!! (ex 특수룰)"
+
+리뷰어: "규칙에 대한 *확장성 보다는, 알고리즘 입장에서 더 간단하게 처리*할 수 있을 것 같아서 의견 드렸습니다. 11점을 기본으로 판단하기로 결정 했다면, 수정하지 않아도 좋습니다. 말씀하신 점수에 대한 *계산 자체의 확장성을 고려 한다면 모든 점수가 기본 점수를 가지면 안될 것 같네요.*" — *Ace 1 vs 11* 선택은 *알고리즘 단순화*가 주 근거. *특수룰 확장* 이야기를 끌면 *모든 카드가 변동 점수를 가져야 일관*. *현재 요구사항*에 맞춘 *가장 단순한 룰* 선택. 학생의 *과잉 확장성 사고*에 *YAGNI*로 응답.
+
+### 6. `Deck(cardsInput: MutableList<Card>? = null)` — `cardsInput`와 `cards` 두 필드 동거
+
+```kotlin
+class Deck(cardsInput: MutableList<Card>? = null) {
+    val cards: MutableList<Card> = cardsInput ?: mutableListOf()
+}
+```
+
+리뷰어: "`cardsInput`와 `cards` *두개를 사용한 전략은 무슨 전략인가요?*" — *생성자 인자 이름*과 *프로퍼티 이름*이 다른 *반쪽 패턴*. Kotlin은 *생성자 인자 = 프로퍼티*가 일반적. `Deck(private val cards: MutableList<Card> = mutableListOf())`로 충분. *명시적 분리*가 필요한 경우는 *transformation*(예: 정규화)일 때만.
+
+### 7. `Dealer.state`와 `Hand` 동기화 누락
+
+```kotlin
+class Dealer(val hand: Hand) {
+    var state: State = State.Running.Hit
+}
+```
+
+리뷰어: "*Hand의 상태가 바뀌면, State도 영향을 받습니다.* 지금의 구조는 이 로직에 문제가 없을까요?" — `hand.draw(card)` 후 *Bust인지 BlackJack인지*가 `state` 변경 *외부 책임*. Controller의 `determinestate(dealer)`가 *동기화 강제*. *cohesive 상태 관리*가 *외부 분산*. `hand.draw(card)` 안에서 *state도 갱신*하거나 *state를 hand 기반 derived*로.
+
+### 8. 함수 *선언 순서*가 *읽는 순서*와 불일치
+
+```kotlin
+object BlackJackController {
+    fun run() {                          // 1. 호출
+        ...
+        showGameResult(...)              // 2. 아래로 내려가야
+    }
+    private fun showGameResult(...)      // 위에 선언 → 위로 점프
+    private fun judgeOfWinOrLose(...)
+    private fun playGame(...)
+    private fun showDealerDraw(...)
+    ...
+}
+```
+
+리뷰어: "코드를 읽을 때에는 자연스럽게 *위에서 부터 아래로 읽도록* 하는데요. 그에 맞춰서 *함수의 선언 순서도 맞춰주시면 좋습니다*." — *Stepdown rule*. `run()` → 호출되는 순서대로 *위에서 아래*로 선언. *읽으면서 점프*하지 않게.
+
+### 9. PR #78과 공유 안티패턴 (요약만)
+
+PR #78 (dpcks0509)에서 동일 코드를 받은 *다른 리뷰어*가 지적한 항목 중 *laco-dev도 동일 지적*:
+
+- **Controller god-object** — laco-dev: "요구 사항을 지켜주세요 > UI 로직을 InputView, ResultView와 같은 클래스를 추가해 분리한다"
+- **함수 반환 타입 모호** — laco-dev: "이 함수가 몇 가지 역할을 하고 있는지, 그리고 *반환하는 타입을 통해 어떤 동작을 하는지 의미를 잘 드러내고 있나요?*"
+- **`Card.toString` UI 결합** — laco-dev: "카드가 어떻게 출력될지는 UI 로직입니다. 가령 *♤ ♠ Space A ♠ ♤*"
+- **`Deck` object Singleton** — laco-dev: "Deck이 object로 설계되는 것이 맞을까요?"
+- **`Deck` 결정적 테스트 불가** — laco-dev: "*덱에 A 스페이드가 한 장 있을 때, 카드를 뽑으면 A 스페이드이다.*"
+- **`ScoreCalculation` 별도 객체 vs Hand 책임** — laco-dev: "*카드의 점수는 Hand로만 결정이 되는데 ScoreCalculation를 분리한 이점이 있을까요?*"
+- **A 카드 1점 기본 권고**
+- **Controller가 *도메인 로직 보유*** — laco-dev: "이 기능은 도메인 로직이 아닐까요? 이 동작을 해야 하는 적절한 객체는 무엇인가요?"
+- **DealerTest가 *딜러를 테스트하지 않음*** — laco-dev 동일 지적.
+- **PlayerTest에 *Bust 케이스 누락*** — laco-dev: "DealerTest와 마찬가지로 *플레이어도 카드를 더 뽑을 수 없는 상황*이 있지 않을까요?"
+
+## 리뷰어 의견 요지
+
+- ***TDD 부정 = 협력 관계 설계 누락 신호*** — 일괄 구현 후 분해는 *원래 형상에 갇힘*.
+- ***MVC에서 View 없으면 MC*** — Input == View. GPT 다수결 X, 정의 ○.
+- ***top-level fun 분류는 *import 경로*만 분류 정보 보유*** — 객체로 묶어 *호출 시점에 역할* 드러나게.
+- ***`Hand(mutableListOf())` 외부 참조 보유 = invariant 무방비*** — 방어적 복사 / private backing.
+- ***Ace 기본 11 선택은 알고리즘 단순화 근거*** — *특수룰 확장*은 YAGNI.
+- ***`cardsInput`/`cards` 두 필드 동거*** — Kotlin은 생성자 인자 = 프로퍼티가 일반.
+- ***Hand 변경 → State 영향 동기화 외부 분산*** — 응집도 ↓.
+- ***Stepdown rule*** — 호출 순서대로 선언.
+
+## 대표 인용
+
+> TDD를 전면으로 부정하고 계시는군요.. 객체지향 프로그래밍에 있어서도 상당히 좋지 않은 접근입니다. *가장 작은 기능단위부터 설계를 하고 협력관계를 만들어* 객체들간의 설계를 만들어 갑니다. 어차피 리팩토링을 한다면 --> 코드 100번 넘게 다시 만들고 싶으시지는 않을거잖아요?
+> — @laco-dev on `README.md`
+
+> 말씀하신 대로면 *MVC가 아니고 MC 패턴*이 아닌가요? *MVC 패턴에서 View 레이어를 만드는 이유가 무엇인가요?*
+> — @laco-dev on `src/main/kotlin/blackjack/controller/BlackJackController.kt`
+
+> 모든 함수가 *최상위 함수로 선언*되어 있기 때문에, 사용하는 측 입장에서는 *어떤 역할인지 알기가 어려운 문제*가 있습니다. [...] *객체를 만들어서 코드가 동작*하도록 만들어 보면 좋겠습니다.
+> — @laco-dev on `src/main/kotlin/blackjack/view/ProgressView.kt`
+
+> 규칙에 대한 *확장성 보다는, 알고리즘 입장에서 더 간단하게 처리*할 수 있을 것 같아서 의견 드렸습니다. [...] *말씀하신 점수에 대한 계산 자체의 확장성을 고려 한다면 모든 점수가 기본 점수를 가지면 안될 것 같네요.*
+> — @laco-dev on `src/main/kotlin/blackjack/model/card/Hand.kt`
+
+> Hand의 상태가 바뀌면, State도 영향을 받습니다. 지금의 구조는 이 로직에 문제가 없을까요?
+> — @laco-dev on `src/main/kotlin/blackjack/model/player/Dealer.kt`
+
+## 얻은 교훈
+
+- **TDD 부정 = *협력 관계 설계 누락 신호*** — *일괄 구현 후 리팩토링*은 *원래 형상에 갇힘*. *작은 협력 단위*부터 키워야 *역할*이 드러남.
+- ***GPT 다수결이 설계 근거가 아님*** — *각 레이어의 정의*로 판단. *MVC에서 View가 빠지면 정의상 MC*.
+- ***Kotlin top-level fun으로 역할 분리하면 분류 정보가 import 경로에만 있음*** — *객체로 묶어 호출 시점에 역할*이 드러나게.
+- ***`Hand(mutableListOf())`로 외부 참조 보유 = invariant 무방비*** — `private val _cards` + `val cards: List<Card> get() = _cards` 방어적 복사.
+- ***Ace 기본 점수 선택은 알고리즘 단순화 근거가 일반적*** — *특수룰 확장*은 *YAGNI*. *현 요구사항에 가장 단순한 룰*.
+- ***`cardsInput`/`cards` 두 필드 동거는 *반쪽 변형*** — Kotlin은 *생성자 인자 = 프로퍼티*가 자연. *별도 명시*는 *정규화 transformation*일 때만.
+- ***상태 동기화는 응집된 한 곳에*** — `Hand` 변경 → `Dealer.state` 변경이 *외부 강제 분산*이면 *한 객체로 응집* (state derived from hand) 또는 *명시적 옵저버*.
+- ***Stepdown rule*** — 호출되는 순서대로 위→아래 선언. *읽으면서 점프하지 않게*.
+- ***PR #78과 동일 코드 + 다른 리뷰어 = 같은 안티패턴 다른 표현*** — 안티패턴이 *리뷰어 취향* 차이가 아닌 *코드 자체의 문제*임을 증명. MCP 룰 후보 신뢰도 ↑.