oh-my-oop 0.2.0

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

@@ -0,0 +1,458 @@
+# PR #72 — [블랙잭 1단계] 올리브 미션
+
+- **Reviewee:** [@kimhm0728](https://github.com/kimhm0728)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/72
+- **단계:** 1단계
+- **리뷰어:** [@ghojeong](https://github.com/ghojeong) (파이로) (**신규 reviewer — 11번째**)
+- **라인 코멘트:** 17 스레드 — *학생 매우 깊은 양방향 토론 + Lazy Evaluation 자가 학습 + Controller 판단 기준 + 캐싱 양가성 + 함수형 (순수함수) 자가 학습*
+- **신규 reviewee** (2024 코호트).
+
+## 잘한 점 (설계 관점)
+
+- **`Controller.run 함수 감탄 칭찬`** — ghojeong: *"Controller 의 run 함수는 감탄을 포함한 칭찬을 드리고 싶습니다. 👍 💯 게임이 어떻게 진행되는지, 한눈에 알아볼 수 있네요. 무척 마음에 듭니다."* — **reviewer 의 *감탄* 어휘 강한 칭찬**. PR #39 (말리빈 *Phase 신선한 발상*) 결.
+- **`반복문 (시스템 입출력 절차지향) 칭찬`** — ghojeong: *"시스템 입력에 의존하는 로직을 반복문으로 작성해 주신 점 또한 마음에 듭니다. 👍 반복문이 굉장히 절차지향적인 문법이라 쓰고 싶지 않아하는 팀도 있지만, 저는 시스템 입출력과 관련된 로직은 절차지향적으로 짜는 편이 성능문제를 덜 일으키는 것 같습니다."* — **함수형 vs 절차지향 메타 어휘** + *팀별 컨벤션 차이 명시*.
+- **`mutableList + 방어적 복사 칭찬`** — ghojeong: *"mutableList 를 선언했지만, 방어적 복사를 할 때는 불변 List 를 반환하도록 해주신 점 좋습니다. 👍"*. PR #74·#108·#133·#46·#23 결.
+- **`Lazy Evaluation` 자가 학습 + ScoreBoard 자가 제거** — ghojeong: *"전혀 괜찮지 않습니다. 저는 애초에 cardSum 이라는 값을 멤버로서 가지고 있으면 안된다고 생각이 듭니다. cardSum 은 언제나 Lazy Evaluation 을 통해 계산되도록 해주세요."* + 학생: *"덕분에 `Lazy Evaluation`에 대해 공부해볼 수 있었습니다! 지금의 코드는 `cardSum`이 필요하지 않은 경우에도 `cardSum`을 매번 계산해주고 있네요,, 말씀하신 사항 반영해서 커밋했습니다. `ScoreBoard`라는 클래스에서 `handCards`와 `cardSum`을 멤버로 가지고 있었는데, `cardSum`을 멤버로 가지지 않게 되면서 `ScoreBoard`가 더이상 의미가 없어져서 제거했습니다."*. **Lazy Evaluation 자가 학습 + 객체 자가 제거 모범** — PR #39 (rhthrhrl0 *immutable-recompute-on-call*) 결의 *반대 방향* (Lazy 적용).
+- **`테스트용 of` 자가 정당화 + reviewer 동의** — 학생 자가 의문: *"`of()` 함수는 오로지 테스트를 위해서만 작성된 코드이니 지양하시는 편인가요? 저는 클라이언트에게 `Card`의 생성 방법을 여러개 열어둔 것이라고도 생각을 해서 이렇게 구현을 했는데, 파이로는 어떻게 생각하시는지 궁금합니다 😀"* + ghojeong: *"팀마다 방향이 다를 수 있다고 생각하는데, 저는 테스트를 위해 작성된 생성자 함수는 결국 실제 프로덕트 코드에서도 쓰이게 되더라 하는 개인경험이 많았습니다. 그래서 저는 `클라이언트에게 Card의 생성 방법을 여러개 열어둔 것` 이라고 표현한 올리브의 의견에 동의합니다."*. **PR #86 (Yunseok-Nam *테스트 목적 생성자 안티패턴*) 와 정반대 시점 + reviewer 다양성**.
+
+## 못한 점 (설계 관점)
+
+### 1. `ScoreBoard` 매번 0 초기화 → Lazy Evaluation 자가 학습 (위 §잘한점)
+
+상세 토론:
+
+학생 자가 추가 의문: *"그런데 지금은 getCardSum()이 여러군데에서 사용되면서, 같은 값을 여러번 계산하기 때문에 오히려 더 비효율적이라고 느껴졌습니다..!"*
+
+ghojeong 답변 (성능 vs 최신값 보장):
+
+> *"이건 관점의 차이가 있을 것 같습니다. 같은 값을 여러번 계산하지 않도록 하는 것은 결국 캐싱을 뜻합니다. 만약 getCardSum 을 할 때 더해야할 데이터가 수천, 수만개라면 이 비효율을 해결해하기 위해 캐싱을 해야합니다.*
+>
+> *반면 클라이언트 개발을 할 경우, 그 데이터가 수백개 정도라면, 비효율을 감수하고서라도 데이터가 항상 최신이 되도록 보장하는게 버그를 줄이는 일일 수 있습니다.*
+>
+> *결국 정답은 없습니다. 성능을 위해 효율을 생각해서, 같은 값을 여러번 계산하지 않도록..."*
+
+학생 자가 캐싱 방법 제안 + 자가 결정 (캐싱 안 함):
+
+> *"객체의 멤버로 `Map<List<Card>, Int>>`를 가짐. 여기서 `Map`의 `key`는 '카드의 조합', `value`는 '카드의 조합'에 대한 cardSum. 즉, 동일한 카드의 조합이면 cardSum을 매번 새로 계산하는 것이 아닌 `Map`에 캐싱된 cardSum을 바로 꺼내옴."*
+
+학생 자가 결정 (현재 미션 캐싱 X): *"그런데 현재 블랙잭 미션에서는 캐싱을 구현하지 않을 것 같습니다. 이유는 아래와 같습니다. - `getCardSum()` 함수는 많은 비용이 들어가지 않는 연산임 - 프로젝트 규모가 커져서 캐싱을 구현하게 되더라도, 클라이언트 코드를 변경하지 않고 `HandCards` 클래스 내부만 변경하면 됨"*
+
+ghojeong 추가 메타:
+
+> *"카드의 조합에 대한 캐싱은 충분히 가능하다고 생각합니다. 하지만 `Map<List<Card>, Int>` 에서 Key 로 List 자료구조를 바로 쓰기 보다는, 일급 컬렉션으로 키를 위해서 한번 포장된 객체를 사용하는게 나을 것 같습니다.*
+>
+> *이건 JVM 머신에서의 컴파일에 대해서 이해도가 필요한데, generic 에 해당되는 `<Card>` 는 컴파일을 성공하고 나면 지워지는 정보이기 때문입니다.*
+>
+> *그리고 보통 키-벨류 형태로 캐싱을 구현할 때, Key 는 Value 보다 데이터 크기가 작아질 수 있도록 설계하는게, 원칙임을 강조해봅니다."*
+
+→ **5 가지 학습**:
+
+#### 1.1. *Lazy Evaluation = `by lazy` Kotlin 어휘*
+
+- *멤버 변수 미리 계산 X + 최초 접근 시 계산 + 이후 캐싱*.
+- *cardSum 이 필요한 경우만 계산*.
+
+PR #39·#13 결.
+
+#### 1.2. *성능 (캐싱) vs 최신값 보장* 양가성
+
+ghojeong 의 *"정답은 없습니다"* — **MCP `oh-my-oop` 핵심 가치 합류 (11번째 reviewer)**. PR #43·#23·#26·#46·#91·#107 결.
+
+#### 1.3. *데이터 규모별 결정 기준 명시*
+
+- *수천/수만 = 캐싱 필요*.
+- *수백 = 비효율 감수 + 최신값 보장*.
+
+**MCP 룰 후보 `caching-decision-by-data-scale`**.
+
+#### 1.4. *JVM Type erase + 일급 컬렉션 키*
+
+- *`Map<List<Card>, Int>` Key 의 `<Card>` 타입 erase*.
+- *일급 컬렉션 (`Hand` 등) 으로 포장 = 컴파일 시점 타입 보장*.
+
+**MCP 룰 후보 `jvm-type-erase-firstclass-key`**. PR #76 (Yunseok-Nam *Type erase 팩토리 메서드*) 결.
+
+#### 1.5. *Key 크기 < Value 크기 원칙*
+
+- *Key 는 식별 + 작은 크기*.
+- *Value 는 데이터 + 큰 크기 가능*.
+
+**MCP 룰 후보 `cache-key-smaller-than-value`**.
+
+### 2. `BlackjackGame` Controller vs Model 판단 기준
+
+학생 자가 의문: *"해당 클래스는 상태를 가지지 않고 인자로 받아온 값들을 통해 기능을 수행하고 있습니다. '초기에 2장의 카드를 나누어주는 기능'과 '게임 결과를 계산하는 기능'을 어떤 객체의 책임으로 할당해주어야 할지 잘 모르겠어서 이러한 클래스를 작성했는데, 이 클래스가 왠지 컨트롤러와 비슷한 역할을 하는 것 같아서 어색하게 느껴집니다.. 파이로는 어떻게 생각하시나요?? 🤔"*
+
+ghojeong:
+
+> *"제가 Controller 인지 여부를 판단할 때 확인하는 두가지가 있습니다.*
+> *1. view 에 의존성이 있는가? 있다면 Controller 입니다.*
+> *2. 테스트 코드가 작성되었는가? 작성할 수 없다면 Controller 입니다.*
+>
+> *BlackjackGame 은 view 에 대한 의존성이 없고, 테스트 코드 또한 작성 되었으므로, 제 기준에서는 충분히 model 이라고 생각을 합니다.*
+>
+> *다만 제가 느끼기에 '초기에 2장의 카드를 나누어주는 기능' 은 앱을 처음 시작하는 기능이고, '게임 결과를 계산하는 기능' 은 앱을 종료할 때의 기능이라 생각됩니다. 그리고 앱의 시작과 종료는 일반적으로 처리할 로직이 굉장히 많습..."*
+
+ghojeong 메타 비유:
+
+> *"저는 지나치게 프로그래밍 적으로 생각하기 보다는, Dealer 와 Player 를 의인화 한 것 처럼, 게임에서 게임판을 깔고, 게임판을 정리해주는 서포터 같은 느낌의 다른 직원이 존재한다고 상상하면 좀더 재밌지 않을까 제안해봅니다.*
+>
+> *역할과 책임 모호할 때는, 해당 역할을 컴퓨터가 아니라 사람에게 시키려고 했을 때, 사람이 한명 더 필요한가 아니면 같은 사람에게 시킬 수 있을까를 고민해보시면 좋습니다.*
+>
+> *Player 는 본인이 손님이므로 직접 게임판을 깔거나, 정리해주는 것은 이상할 것 같습니다. 그렇다면 Dealer 에게 일을 더 시킬 건지, 아니면 사람을 한명 더 고용할 건지 생각해보시면 좋을 것 같습니다."*
+
+학생 자가 결정: *"`initCard()`를 `Role`으로 옮겨서, 게임에 참여하는 딜러와 플레이어들이 직접 카드를 뽑도록 수정했습니다. 그리고 실제 게임과 동일하게 `Dealer`가 게임 결과를 계산하도록 수정했습니다."*
+
+→ **5 가지 학습**:
+
+#### 2.1. *Controller 판단 기준 2 가지*
+
+- *view 의존성 + 테스트 가능성* — 둘 다 *Controller 시그널*.
+
+**MCP 룰 후보 `controller-classification-criteria`** = *view 의존 + 테스트 불가 = Controller / 둘 다 없음 = Model*.
+
+#### 2.2. *비유 = 사람 vs 컴퓨터*
+
+ghojeong: *"해당 역할을 컴퓨터가 아니라 사람에게 시키려고 했을 때, 사람이 한명 더 필요한가 아니면 같은 사람에게 시킬 수 있을까"* — **MCP `oh-my-oop` 의 *현실 메타포* 어휘 강화**. PR #74 (송핑크 *Referee*) / PR #46 (말리빈 *라면 비유*) / PR #82 (KwonDae *현실 카지노 6덱*) / PR #72 (ghojeong *서포터 비유*) 결.
+
+#### 2.3. *Player 손님 vs Dealer 직원 vs 추가 사람*
+
+학생이 *Dealer 가 결과 계산* 자가 선택 = *현실 메타포 (딜러가 결과 알려줌)*. PR #23 (멘델 *Dealer 결과 책임*) / PR #74 (송핑크) / PR #98 (chaehyuns *Judge 분리*) 결.
+
+#### 2.4. *학생 자가 *"BlackjackGame 어색하게 느껴진다"* 자가 인정*
+
+*어색함 = 코드 시그널* — **MCP 룰 후보 `awkward-feeling-signal`**.
+
+#### 2.5. *역할 모호 시 = 사람 시뮬레이션*
+
+ghojeong 비유 = **MCP `oh-my-oop` 의 *역할-책임-협력 (RDD)* 어휘와 일치**. *조영호 「객체지향의 사실과 오해」* 결.
+
+### 3. `CardDecision interface` 자가 학습
+
+ghojeong: *"만약 입출력 관련된 의존성을 분리를 하고 싶다면, 입출력 관련된 메서드를 인터페이스로 분리를 하면 됩니다. 사용자가 숫자를 입력하는 것과, 랜덤함수에서 값을 받는 것은 근본적으로 차이가 없습니다. 값을 받는 다는 부분을 인터페이스화 해서, 실제 입력받는 값이 아닌, 입력을 받을 수 있는 인터페이스만을 도메인에게 넘기도록 리팩토링하면 됩니다. 아마 자동차 미션과 로또 미션에서 랜덤 요소의 추상화 관련된 부분을 굉장히 많이 학습하셨으리라 생각합니다."*
+
+학생 자가 적용 + 자가 의문: *"`InputView`를 '플레이어 이름', '카드 더 받을지 여부'를 기준으로 각각 분리하는 방향으로 생각했습니다. 컨트롤러가 더 가벼워졌다는 점은 마음에 드는데, 카드를 더 받을지에 대한 값을 받아오는 인터페이스인 `CardDecision`을 어떤 패키지에 놓으면 좋을지, 인터페이스 내의 함수명은 적절한지 잘 모르겠습니다."*
+
+ghojeong:
+
+> *"`isMoreCardDecision` 이 조금 헷갈리는 함수명인 것 같기는 합니다. is 말고 has 라는 표현을 쓰는 건 어떤가요?*
+>
+> *인터페이스의 최대 장점 중 하나는 로직을 담고 있지 않기에, 테스트를 할 필요가 없다는 점입니다. 저는 개인적으로 해당 인터페이스를 가장 많이 활용하는 모델 객체 근처에 해당 인터페이스를 위치시키는 편입니다."*
+
+→ **3 가지 학습**:
+
+#### 3.1. *사용자 입력 vs 랜덤 함수 = 본질적 차이 X*
+
+- *둘 다 *외부에서 값 받기* = *Provider interface*.
+
+**MCP 룰 후보 `input-source-abstraction`**. PR #74·#95·#99·#23·#26·#77·#82 결.
+
+#### 3.2. *인터페이스 위치 = 가장 많이 활용 모델 근처*
+
+- *인터페이스 = 로직 X = 테스트 X*.
+- *모델 객체 근처 위치 = 응집*.
+
+#### 3.3. *부울 명명 `is` vs `has`*
+
+- *`isMoreCardDecision`* — *동사 X = 의미 모호*.
+- *`hasMoreCardDecision`* — *동사 has = 보유 의미*.
+
+PR #66·#107·#151·#98 의 *부울 명명 기준점* 결.
+
+### 4. `BlackjackGame` 유틸 vs 도메인
+
+ghojeong: *"현재 BlackjackGame 은 유틸적인 성격이 굉장히 강하다고 생각이 듭니다. 만약 객체지향적인 설계를 강화하고 싶다면, BlackjackGame 이 가질 수 있는 유의미한 멤버가 있을지 고민해보면 좋으실 것 같습니다."*
+
+→ **상태 없는 클래스 = util 시그널**. PR #46·#16·#11 의 *class-without-state* 결.
+
+### 5. `함수형 = 순수 함수` 자가 학습
+
+ghojeong: *"만약 함수형적으로 설계를 강화하고 싶다면, forEach 나 repeat 를 통해서 Card 를 받아오는게 아니라, 한번에 Card 를 전부 받아오고 불변 Card List 를 넘길 수 있도록 리팩토링을 하는 법도 고민해볼 수 있을 것 같습니다."*
+
+학생 자가 적용 + 자가 의문 + 자가 학습:
+
+> *"수정해서 커밋했습니다! 테스트 코드에서도 `forEach`를 통해 `receiverCard()`를 여러번 호출해서 코드가 지저분했었는데, 훨씬 더 깔끔하게 바뀐 것 같아 좋네요.ㅎㅎ 감사합니다!*
+>
+> *해당 방법이 '함수형'적이라고 말씀해주셨는데, 이전 코드는 `forEach`나 `repeat`을 통해서 `HandCards`에 있는 `List<Card>`를 하나씩 더해주는 방식이기 때문에 '절차지향'적이고, 현재 코드는 `CardProvider`에서 `take` 등을 활용해 한..."*
+
+ghojeong:
+
+> *"보통 return 이 없는 블락{} 은 순수함수가 아닌, side effect 를 일으키는 경우가 많습니다. 가령 여기서는 receiveCard 를 통해 결과적으로는 mutableList 를 변형시킵니다.*
+>
+> *forEach 나 repeat 가 나쁘다는 의미가 아닌, forEach 혹은 repeat 를 통해 실행시키는 로직은 side effect 를 일으키는 경우가 대부분이기에, 순수함수가 아닌경우가 많아서 함수형이 아니라는 피드백을 드렸습니다."*
+
+학생: *"아! 함수형의 중요한 키워드가 '순수 함수'라는 걸 배웠는데 이렇게 적용시키는 거군요!!! 앞으로도 인자로 받은 값을 통해 어떠한 값을 리턴하도록 신경써서 구현해보겠습니다."*
+
+→ **3 가지 학습**:
+
+#### 5.1. *forEach / repeat = side effect 시그널*
+
+- *`forEach { }` Unit 반환 + 람다 내 변경 = side effect*.
+- *`map { }` 값 변환 + 순수* — 함수형 정공.
+
+**MCP 룰 후보 `foreach-repeat-as-side-effect-signal`**.
+
+#### 5.2. *함수형 = 순수 함수 + 인자 + 반환값*
+
+- *외부 상태 변경 X + 동일 인자 = 동일 결과 + side effect X*.
+
+PR #145·#23·#13 결.
+
+#### 5.3. *학생 자가 *함수형 키워드 순수함수* 자가 학습*
+
+PR #13 (vagabond95 *Kotlin 어휘 사용 기준*) 결의 *함수형 어휘 강화*.
+
+### 6. `HandCards` 명명 = 도메인 어휘 vs 일반 개발자 이해
+
+ghojeong: *"현재 HandCards 는 Card 의 일급 컬렉션 처럼 쓰이고 있는 듯 한데, Hand 라는 의미를 앞에 붙인 의도가 있을까요? 동료 개발자 입장에서 HandCards 를 보면, 혹시 Hand 말고 다른 Cards 일급 콜렉션도 존재할 수 있나? 하는 생각이 들 것 같습니다."*
+
+학생: *"사실 처음에는 `Cards`라는 클래스가 있었는데요, `Cards`와 혼동을 방지하기 위해 `HandCards`라는 클래스를 생성한 것이 맞습니다! 구현하다가 `Cards` 클래스가 불필요하다고 판단해서 삭제했고, 다른 크루가 실제 게임 용어 중에 `HandCards`라는 용어가 있다고 알려줘서 `HandCards` 클래스 이름을 변경하지 않고 그대로 두었습니다..!! 실제 블랙잭에서 쓰이는 용어가 더 의미(참가자의 손에 들려있는 카드)를 잘 담는다고 생각을 했습니다!"*
+
+학생 자가 양가성 인정: *"그런데 파이로가 저한테 질문하신 것처럼, 이 용어를 모르는 다른 개발자들은 오히려 바로 의미를 파악하지 못 할 수도 있겠다는 생각이 드네요..!! 비교적 다수가 쉽게 이해할 수 있는 용어를 사용하는 것이 맞는 것 같습니다."*
+
+학생 자가 후속 결정 (유지): *"좀 더 일반적인 용어를 사용하기 위해 `Cards`로 변경하려고 했는데, 그러면 캡슐화하고 있는 `List<Card>`를 어떤 프로퍼티명으로 변경할지 모르겠습니다.. 그리고 `HandCards`가 '딜러나 플레이어가 손에 쥐고 있는 카드'이기 때문에, 'participant' 패키지에 포함시키는 것이 맞다고 생각합니다."*
+
+ghojeong: *"아닙니다. 충분한 이유가 있어서 그렇게 생각하셨다면, 저는 유지해도 괜찮다고 생각합니다. 무조건 이렇게 해야한다고 피드백을 생각하지 마시고, 동료 개발자와 협업한다면 이런 부분을 궁금해 할 수도 있겠구나! 라고 생각해주세요 ㅎㅎ"*
+
+→ **5 가지 학습**:
+
+#### 6.1. *도메인 용어 (HandCards) vs 일반 개발자 이해*
+
+- *도메인 용어 = 의미 풍부 (블랙잭에서 손에 든 카드) + 도메인 전문가 이해*.
+- *일반 명사 (Cards) = 보편 이해 + 의미 약함*.
+
+**MCP 룰 후보 `domain-vocabulary-vs-general-noun`**. PR #82 (Hevton *Hand vs Deck 혼동*) 결.
+
+#### 6.2. *학생 자가 양가성 인정 후 유지 결정*
+
+*"비교적 다수가 쉽게 이해할 수 있는 용어를 사용하는 것이 맞는 것 같습니다"* → *"그러나 패키지 응집 이유로 유지"* — **양가성 인정 + 자가 결정 유지**.
+
+#### 6.3. *reviewer 가 *학생 결정 존중* + *생각의 가능성* 명시*
+
+*"무조건 이렇게 해야한다고 피드백을 생각하지 마시고, 동료 개발자와 협업한다면 이런 부분을 궁금해 할 수도 있겠구나! 라고 생각해주세요"* — **MCP 핵심 가치 (단일 답 X)** 강화. PR #145 (lee-ji-hoon *"의견을 너무 어필 시 그대로 따라갈까 봐"*) 결.
+
+#### 6.4. *Hevton 의 Hand-Deck 혼동* + *kimhm0728 의 HandCards-Cards 혼동* — *비슷한 명명 영역*
+
+PR #82·#100 의 *Hand vs Deck* 결의 *변형*.
+
+#### 6.5. *participant 패키지 응집 이유로 명명 유지*
+
+학생 자가 *패키지 응집* 이유 명시.
+
+### 7. `Card.isAce()` 디미터 법칙 자가 학습
+
+ghojeong: *"[디미터 법칙](https://dl.acm.org/doi/10.1145/62084.62113) 에 따라, Card 에서 denomination 까지 타고 내려가지 않더라도 isAce 인지 여부를 알 수 있거나, 숫자를 셀 수 있으면 좋을 것 같습니다."*
+
+학생 자가 의문: *"수정하면서 `Card`에 `isAce()`와 `getScore()`라는 함수를 생성했는데요, 특별한 로직을 담고 있지 않고 `denomination`의 멤버 프로퍼티나 함수만을 호출해서 반환하고 있다는 점이 왠지 어색하게 느껴지는데, 아직 디미터 법칙에 익숙하지 않아서 그런 걸까요?? 🤔"*
+
+ghojeong:
+
+> *"제 개인 경험을 기반으로 디미터 법칙의 유용성에 대해서 말씀드리자면, 설사 로직없이 멤퍼 프로퍼티나 함수만을 호출해서 반환하더라도, 추후에 유지보수성에 있어서 매우 유용했습니다.*
+>
+> *가령 언젠가 denomination 을 다른 객체로 리팩토링하거나, 맴버값이 아닌 무언가 추가적인 연산이 들어가도록 하고 싶은데, isAce() 와 getScore() 함수로 감싸져 있다면, 함수 내부의 로직만 바꾸면 됩니다. 하지만 `it.denomination.is..."*
+
+→ **3 가지 학습**:
+
+#### 7.1. *디미터 법칙 외부 학술 자료*
+
+[ACM Digital Library 1989 논문](https://dl.acm.org/doi/10.1145/62084.62113) — **공식 학술 자료 인용**. PR #66·#100·#67·#93·#133·#146·#137 결.
+
+#### 7.2. *로직 없는 위임 함수 = 향후 유지보수 가치*
+
+- *현재: `Card.isAce()` = `denomination.isAce()` 단순 위임*.
+- *향후: denomination 리팩토링 시 함수 내부만 변경*.
+
+**MCP 룰 후보 `forward-compatible-delegation`**.
+
+#### 7.3. *디미터 법칙 = *친구의 친구의 친구 X***
+
+PR #66·#100·#67 결.
+
+### 8. `Card` 역할/책임 자가 토론 + 값 vs 행동
+
+ghojeong: *"저는 from 외에도 of 라는 static 팩토리가 있다는 것은 별 문제가 되지 않지만, Card 라는 객체가 static 팩토리 외에는 아무런 public 메서드가 없다는 것은 문제라고 생각합니다. Card 라는 객체가 생성된 이후의 역할 혹은 책임이 이 객체에는 존재하지 않는 다는 의미이니까요. Card 의 역할과 책임이 무엇인지 메서드로 나타날 수 있도록 해주시고, 만약 없다면 data class 로 다뤄주시면 좋을 것 같습니다."*
+
+학생 자가 매우 긴 답변:
+
+> *"저는 현재 `Card`에도 역할과 책임이 있다고 생각합니다. (말씀해주신 디미터 법칙을 적용하면서, `Card` 내에 메서드가 추가되었지만, 메서드가 추가되기 전에도 `Card`에는 역할과 책임이 있다고 생각합니다.) 그렇게 생각하는 이유는 아래와 같습니다.*
+>
+> *1. `Card` 클래스를 생성함으로써 'denomination과 suite를 가지고 있는 하나의 카드'라는 의미를 담을 수 있음*
+>
+> *2. 유효한 denomination과 suite만을 멤버로 가질 수 있기 때문에, ..."*
+
+ghojeong:
+
+> *"이게 Card 의 핵심 역할이라고 하셨는데, 결국 핵심 역할은 유효한 카드'값' 이라고 할 수 있습니다. 저는 값이 핵심 역할일 경우는 명시적으로 value 혹은 data 키워드를 붙이는 것을 좋아합니다. 참고로 이건 취향의 차이라 부를 수 있으므로 꼭 반영할 필요는 없겠네요.*
+>
+> *그 보다는 값을 포장한 클래스라 하더라도, 단순한 값 이상의 역할이 존재할 수 있을까 고민해보면 좋겠다는 의미로 언급했다고 생각해주시면 좋을 것 같습니다."*
+
+→ **3 가지 학습**:
+
+#### 8.1. *Card = 값 vs 행동 양가성*
+
+- *값 (값만 보유)* = *data class / value class 명시*.
+- *행동 (메서드 보유)* = *일반 class*.
+
+**MCP 룰 후보 `value-vs-behavior-class-distinction`**. PR #46 (krrong *data class private constructor*) / PR #86 (Yunseok-Nam) 결.
+
+#### 8.2. *학생 자가 *Card 역할/책임* 자가 정당화*
+
+*"유효한 denomination과 suite만을 멤버로 가질 수 있기 때문에..."* — **type system 활용 + 도메인 의미 응집**.
+
+#### 8.3. *reviewer 의 *취향 차이* 메타*
+
+*"꼭 반영할 필요는 없겠네요. 참고로 이건 취향의 차이라 부를 수 있으므로"* — **MCP `oh-my-oop` 의 *학생 결정 존중* 어휘**.
+
+### 9. `패키지 entryPoint` 자가 정의
+
+ghojeong: *"HandCards 는 participant 패키지에 배치하였지만, CardProvider 는 card 패키지에 배치한 기준이 무엇인지 궁금합니다. 패키지를 설계할 때는 객체를 설계할 때와 마찬가지로, 패키지의 역할과 책임을 고려하면 좋습니다. 그런 의미에서 저는 해당 패키지를 대표할 수 있는 entryPoint 같은 객체가 존재하는 지를 살펴보고는 합니다. card, participant, result 3개 의 패키지를 대표하는 하나의 객체가 무엇인지 각각 설명해주시고, 다른 객체들은 이 대표 객체와 어떤 관계인지에 대한 설명을 해주시면 좋겠습니다."*
+
+학생 자가 답변: *"제가 생각한 패키지를 대표할 수 있는 객체는 아래와 같습니다. - card -> `Card` - participant -> `Role` - result -> `GameResultStorage`"*
+
+→ **패키지 entryPoint 자가 정의**. **MCP 룰 후보 `package-entry-point-classification`**. PR #13 (vagabond95 *etc 패키지 안티패턴*) 결.
+
+### 10. `result 패키지 = DTO vs Model` 자가 토론
+
+ghojeong: *"result 패키지는 현재 model 로 분류되어 있습니다. 다르게 이야기하면 result 패키지 내부의 객체들은 모두 자신만의 역할과 책임을 가지며, 그에 따라 테스트할 필요성이 있는 비즈니스 로직을 가지고 있다는 의미로도 생각할 수 있습니다. 하지만 다른 card, participant 패키지 안의 객체들과 다르게, result 패키지 내부의 객체들은 유의미한 테스트를 하고 있는 것 같지 않아보입니다."*
+
+학생: *"`GameResultStorage` 클래스처럼 데이터만 저장하고 있는 클래스는 model이 아닌 다른 패키지(ex: entity)가 더 적절하다고 생각하시나요?"*
+
+ghojeong: *"제가 이해하기로 result 패키지 안에 있는 클래스들은 그 목적이 모델의 데이터를 OutputView 로 전달(Transfer) 하는것이라고 이해했습니다. 그럴 경우 저는 Data 를 전달(Transfer)하는 Object 라는 의미에서 model 보다는 DTO 라는 표현을 쓰는 것을 좋아합니다."*
+
+→ **3 가지 학습**:
+
+#### 10.1. *DTO 정의 = Data Transfer Object*
+
+- *목적 = View 에 데이터 전달*.
+- *비즈니스 로직 X + 테스트 X*.
+
+**MCP 룰 후보 `dto-vs-model-classification`**. PR #145·#31·#91 의 *DTO 위치* 결.
+
+#### 10.2. *팀별 컨벤션 + 문서화 강조*
+
+ghojeong: *"개발팀마다 모두 다릅니다. 중요한 것은 팀 전체가 납득할 수 있는 컨벤션을 만들고 문서화하는 일입니다."* — **팀 컨벤션 어휘**. PR #72 ghojeong 의 *팀 다양성* 강조 메타.
+
+#### 10.3. *Google Style Guide* 외부 자료
+
+ghojeong: *"가령 구글만 해도 구글만의 [Style Guide 가 존재해서 파일과 패키지를 어떻게 선언해야할지](https://google.github.io/styleguide/javaguide.html#s3-sour..."* — **외부 자료**. PR #22·#13·#16 결.
+
+### 11. `getCardSum` fold + Ace 분기 — suggestion
+
+ghojeong suggestion:
+
+```kotlin
+fun getCardSum(burstCondition: Int): Int {
+    return _cards.fold(
+        _cards.sumOf { it.getScore() }
+    ) { total, card ->
+        if (!card.isAce()) return@fold total
+        if (total + Denomination.ADDITIONAL_ACE_SCORE > burstCondition) return total
+        total + Denomination.ADDITIONAL_ACE_SCORE
+    }
+}
+```
+
+학생: *"말씀하신 방법대로 구현하면 cardSum이라는 별도의 가변 변수를 생성하지 않아도 되어서 훨씬 깔끔해지네요!! 감사합니다 (...) 사실 저도 fold 내의 if문이 마음에 안 들어서 수정하려고 여러번 시도해봤는데요... 첫 번째 if는 fold만 return하고 두 번째 if는 함수 자체를 return해서 어떻게 리팩토링해야 할지 잘 모르겠습니다."*
+
+→ **Kotlin `fold` + `return@fold` vs `return` 어휘**. **MCP 룰 후보 `fold-with-label-return`**.
+
+### 12. `Role.initCard` 위치 자가 학습
+
+ghojeong: *"initCard 을 Role 로 옮기신 이유나 기준이 있으실까요? 물론 BlackjackGame 에서 어딘가로 옮기는 리팩토링에는 동의하지만, 왜 Role 을 선택하셨는지는 궁금합니다. Role 이 기존에 가지고 있던 상수, 멤버, 메서드와 initCard 아 연관은 없어보여서요."*
+
+학생: *"Dealer와 Player가 카드를 직접 두 개씩 뽑도록 구현하려고 함 → Dealer와 Player 클래스 내에 `initCard()`를 추가함 → `initCard()` 함수의 코드가 중복되기 때문에 Role로 이동. 코멘트 읽고 다시 생각해보니, Dealer와 Player는 받은 카드를 인자로 받아서 처리만 하고 있는데(`receiveCards()`), 갑자기 Dealer와 Player가 카드를 직접 뽑는 것이 어색한 것 같네요."*
+
+→ **함수 위치 = 도메인 객체 본연의 책임과 일치 권유**. PR #82 (KwonDae *participant.initGame*) / PR #145 결.
+
+### 13. `Dealer 결과 계산` 현실 메타포
+
+ghojeong: *"calculateGameResult 는 Dealer 의 책임으로 옮겨주셨군요. 게임이 끝났을 때, 점수를 계산하는 것은 딜러의 책임이라는 것은, 현실의 게임 상황을 생각하면 자연스러운 것 같습니다. 👍"*
+
+→ **현실 메타포 + Dealer 책임**. PR #23·#74·#98 결.
+
+### 14. `GameResultStorage` 명명 = dto 추측 어려움
+
+ghojeong: *"이건 정말 제 장담컨데, result 라는 패키지명과 Storage 라는 클래스명 만으로는 dto 라는 것을 추측하기 쉽지 않을 것 같다고 말씀을 드려봅니다."*
+
+학생: *"step2 구현하면서 result 패키지는 제거했습니다."*
+
+→ **명명 정확성 + dto 명시**. PR #99·#9·#39·#11·#107 결.
+
+### 15. `README` 체크리스트 미체크
+
+ghojeong: *"README 에 체크를 하지 않은 항목이 있는데, 일부러 체크를 하지 않으신 건가요?"*
+
+학생: *"실수로 체크하는 걸 깜빡했습니다.. 이런 실수를 하다니 🥲 수정하겠습니다!"*
+
+→ **PR 본문 셀프 체크리스트 활용**. PR #107·#145 결.
+
+### 16. `Cards.value`/`HandCards.cards` 접근자 패턴 (위 §6 와 같음)
+
+### 17. `RandomCardProvider 파라미터` 활용 — (학생 자가 적용 완료)
+
+학생 자가 [반영 커밋](https://github.com/woowacourse/kotlin-blackjack/pull/72/commits/6c1cedb7da98e329653a427ae6da9ec0ed359900) 명시.
+
+→ **반영 커밋 URL 첨부 패턴**. PR #46 (krrong *반영커밋 URL 14회 중 11회*) 결.
+
+## 리뷰어 의견 요지 (ghojeong / 파이로) — **신규 reviewer (11번째)**
+
+17 코멘트 특징:
+
+- **`Controller 판단 기준 2 가지` 명시** — *view 의존 + 테스트 가능* — **MCP 룰 후보 `controller-classification-criteria`**.
+- **`사람 시뮬레이션 비유`** — *서포터 직원 비유* — **현실 메타포 어휘**.
+- **`데이터 규모별 캐싱 결정`** — *수천/수만 = 캐싱 / 수백 = 최신값*.
+- **`JVM Type erase + 일급 컬렉션 키`** + **`Key 크기 < Value 크기 원칙`** — JVM 내부 동작 + 캐싱 원칙.
+- **외부 학술 자료 (디미터 법칙 ACM 논문 + Google Style Guide)** — **공식 자료**. PR #22·#13·#16 결.
+- **`팀 컨벤션 + 문서화 강조`** — *"개발팀마다 모두 다릅니다. 중요한 것은 팀 전체가 납득할 수 있는 컨벤션을 만들고 문서화하는 일입니다"*.
+- **`개인 경험 메타 어휘`** — *"제 개인 경험을 기반으로"* — **MCP 핵심 가치 (11번째 reviewer 합류)**.
+- **`감탄 칭찬`** — *"감탄을 포함한 칭찬을 드리고 싶습니다 👍 💯"* — PR #39 (말리빈 *Phase 신선한 발상*) 결.
+
+## 대표 인용
+
+> *"Controller 인지 여부를 판단할 때 확인하는 두가지가 있습니다. 1. view 에 의존성이 있는가? 있다면 Controller 입니다. 2. 테스트 코드가 작성되었는가? 작성할 수 없다면 Controller 입니다."* — ghojeong (Controller 판단 기준)
+
+> *"역할과 책임 모호할 때는, 해당 역할을 컴퓨터가 아니라 사람에게 시키려고 했을 때, 사람이 한명 더 필요한가 아니면 같은 사람에게 시킬 수 있을까를 고민해보시면 좋습니다."* — ghojeong (사람 시뮬레이션 비유)
+
+> *"이건 관점의 차이가 있을 것 같습니다. (...) 결국 정답은 없습니다."* — ghojeong (MCP 핵심 가치 11번째 reviewer 합류)
+
+> *"개발팀마다 모두 다릅니다. 중요한 것은 팀 전체가 납득할 수 있는 컨벤션을 만들고 문서화하는 일입니다."* — ghojeong (팀 컨벤션 + 문서화 강조)
+
+> *"forEach 혹은 repeat 를 통해 실행시키는 로직은 side effect 를 일으키는 경우가 대부분이기에, 순수함수가 아닌경우가 많아서 함수형이 아니라는 피드백을 드렸습니다."* — ghojeong (함수형 = 순수 함수 자가 학습)
+
+> *"제 개인 경험을 기반으로 디미터 법칙의 유용성에 대해서 말씀드리자면, 설사 로직없이 멤퍼 프로퍼티나 함수만을 호출해서 반환하더라도, 추후에 유지보수성에 있어서 매우 유용했습니다."* — ghojeong (forward-compatible-delegation 메타)
+
+## 얻은 교훈
+
+1. **`Controller 판단 기준 2 가지`** — *view 의존 + 테스트 가능*. **MCP 룰 후보 `controller-classification-criteria`**.
+
+2. **`Lazy Evaluation` Kotlin 어휘 자가 학습** — *`by lazy` + 최초 접근 시 계산 + 캐싱*. PR #39·#13 의 *immutable-recompute-on-call* 결의 *해결*.
+
+3. **`데이터 규모별 캐싱 결정`** — *수천/수만 = 캐싱 / 수백 = 최신값 보장*. **MCP 룰 후보 `caching-decision-by-data-scale`**.
+
+4. **`JVM Type erase + 일급 컬렉션 키`** — *`Map<List<Card>, Int>` 의 List<Card> Key = 일급 컬렉션 포장 정공*. **MCP 룰 후보 `jvm-type-erase-firstclass-key`**.
+
+5. **`Key 크기 < Value 크기` 캐싱 원칙** — **MCP 룰 후보 `cache-key-smaller-than-value`**.
+
+6. **`사람 시뮬레이션 비유` (RDD)** — *컴퓨터 vs 사람 + 새 직원 vs 기존 직원에게 더 시킴*. **MCP `oh-my-oop` *역할-책임-협력* 어휘 강화**.
+
+7. **`함수형 = 순수 함수` 자가 학습** — *forEach/repeat = side effect 시그널 / map = 값 변환 정공*. **MCP 룰 후보 `foreach-repeat-as-side-effect-signal`**.
+
+8. **`디미터 법칙 forward-compatible-delegation`** — *로직 없는 위임 함수 = 향후 유지보수 가치*. **MCP 룰 후보 `forward-compatible-delegation`**.
+
+9. **`Card = 값 vs 행동 양가성`** — *data class / value class vs 일반 class*. **MCP 룰 후보 `value-vs-behavior-class-distinction`**.
+
+10. **`패키지 entryPoint 자가 정의`** — *각 패키지 대표 객체*. **MCP 룰 후보 `package-entry-point-classification`**.
+
+11. **`DTO vs Model 분류`** — *DTO = 데이터 전달 + 테스트 X*. **MCP 룰 후보 `dto-vs-model-classification`**.
+
+12. **`도메인 용어 vs 일반 명사`** — *HandCards (도메인 용어) vs Cards (일반 명사)* — **MCP 룰 후보 `domain-vocabulary-vs-general-noun`**.
+
+13. **`fold + return@label vs return` Kotlin 어휘** — **MCP 룰 후보 `fold-with-label-return`**.
+
+14. **`팀 컨벤션 + 문서화 강조`** — *팀 다양성 인정 + 컨벤션 문서 핵심*. **MCP 룰 후보 `team-convention-documentation`**.
+
+15. **`테스트 목적 생성자` PR #76 안티패턴 vs PR #72 ghojeong 동의** — *학생 + reviewer 의견 분열* = **MCP `oh-my-oop` 의 *단일 답 X* 어휘 강화**.
+
+16. **`Controller.run 감탄 칭찬`** — PR #39 (Phase 신선한 발상) / PR #82·#107 결.
+
+17. **`참조 PR URL` (반영 커밋) 첨부** — PR #46 결.