oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/SUMMARY.md

@@ -0,0 +1,339 @@
+# 우아한테크코스 kotlin-racingcar PR 리뷰 분석 — 총정리
+
+133개의 closed PR (라인 코멘트 ≥ 5개), 77명의 reviewee를 분석해 도출한 OOP 설계 교훈 모음.
+
+> **분석 범위:** 책임/응집/결합/캡슐화/Tell-Don't-Ask/테스터빌리티/도메인 모델링/일급 컬렉션/원시 강박/의존 방향/명명 설계.
+> **제외:** Kotlin 관용구 (scope function, smart cast, null 처리 idiom, `val/var`, data class *문법* 자체, init 블록 형태, collection API 선택).
+
+---
+
+## 자주 하는 설계 실수 TOP 10
+
+리뷰 빈도와 안티패턴의 심각도로 순위.
+
+### 1. **Controller가 god-object 되기** — Tell Don't Ask 위반
+
+**증상:** RacingController가 InputView/OutputView/Validator/RacingGame 모두를 인스턴스로 보유, `run()` 메서드 하나가 입력 검증, 게임 진행, 우승자 판단, 출력까지 다 함.
+
+**예시 PR:** [#108](Hogu59/108-1단계-자동차-경주.md), [#92](kmkim2689/92-1단계-자동차-경주.md), [#144](ijh1298/144-2단계-자동차-경주.md), [#41](whk06061/41-2단계-자동차-경주.md), [#40](EmilyCh0/40-1단계-자동차-경주.md), [#125](Hogu59/125-2단계-자동차-경주.md)
+
+**해법 패턴:**
+- Controller는 "명령 + view-domain 연결"만
+- 도메인 주체 (RacingGame)가 상태 관리 + 라운드 진행 + 우승자 판단
+- "체스 비유" — 유저(Controller) → 체스판(RacingGame) → 말(Car)
+
+### 2. **검증 위치 혼란** — UI/Domain/Controller 세 갈래 책임 분리 실패
+
+**증상:** Validator가 InputView, Controller, Domain init 어디에 가야 할지 모름. 학생마다 다른 답.
+
+**예시 PR:** [#85](CFalws/85-2단계-자동차-경주.md), [#108](Hogu59/108-1단계-자동차-경주.md), [#135](moondev03/135-1단계-자동차-경주.md), [#161](moondev03/161-2단계-자동차-경주.md), [#142](jiyuneel/142-2단계-자동차-경주.md), [#34](krrong/34-1단계-자동차-경주.md), [#44](inseonyun/44-1단계-자동차-경주.md), [#76](inseonyun/76-2단계-자동차-경주.md)
+
+**해법 패턴 (3분류):**
+- **UI 형식 검증** (빈 문자열, 숫자 아님, 형식) → View
+- **사용자 입력 정책** (재입력 흐름) → Controller
+- **도메인 무결성 invariant** (이름 길이, 자동차 두 대 이상, 중복) → Domain init / 일급 컬렉션
+
+이 분류는 학생들이 PR 두세 라운드에 걸쳐 자가 학습으로 도달.
+
+### 3. **`Car.position`이 var (외부 변경 가능)** — 캡슐화 누수
+
+**증상:** `class Car(var name, var position)` 또는 `val position: Int` 그대로 public.
+
+**예시 PR:** 거의 모든 1단계 PR — [#46](Choisehyeon/46-1단계-자동차-경주.md), [#84](Songusika/84-2단계-자동차-경주.md), [#91](s6m1n/91-1단계-자동차-경주.md), [#145](etama123/145-2단계-자동차-경주.md), [#82](drunkenhw/82-2단계-자동차-경주.md), [#92](kmkim2689/92-1단계-자동차-경주.md), 등 다수.
+
+**해법 패턴:**
+- `var position: Int = 0; private set` (가장 흔한 권장)
+- backing property `private var _position` + `val position get() = _position` (컬렉션 경우)
+- Tell Don't Ask: 외부에서 position을 읽어 비교하지 말고 `car.isAtMaxPosition(maxPos)` 메시지 던지기
+
+### 4. **모호한 클래스 이름** = god-object 안티패턴의 시그널
+
+**증상:** `Validator`, `Manager`, `Helper`, `Service`, `Util`, `Common`, `Const`.
+
+**예시 PR:** [#41](whk06061/41-2단계-자동차-경주.md), [#52](sujin9/52-2단계-자동차-경주.md), [#103](dpcks0509/103-1단계-자동차-경주.md), [#96](Yunseok-Nam/96-1단계-자동차-경주.md), [#88](JoYehyun99/88-1단계-자동차-경주.md), [#50](hyemdooly/50-1단계-자동차-경주.md), [#68](hyemdooly/68-1단계-자동차-경주.md)
+
+**리뷰어 명언:** *"네이밍이 모호하다는 것은 곧 해당 클래스/함수의 역할이 모호하거나 모호해질 수 있다는 신호이기 때문입니다"* — @vagabond95
+
+**해법 패턴:** 무엇을 *Validate/Manage/Util*하는지 이름에 명시. `InputValidator`, `RacingGame`, `OutputFormatter` 등.
+
+### 5. **상수의 god-folder** — `Const.kt` / `common/` 한 파일에 모든 상수
+
+**증상:** 한 클래스에서만 쓰는 상수까지 공용 파일에 박혀 있음. 외부에서 접근 가능.
+
+**예시 PR:** [#139](yrsel/139-1단계-자동차-경주.md), [#103](dpcks0509/103-1단계-자동차-경주.md), [#92](kmkim2689/92-1단계-자동차-경주.md), [#52](sujin9/52-2단계-자동차-경주.md), [#31](rhthrhrl0/31-1단계-자동차-경주.md), [#83](yujamint/83-2단계-자동차-경주.md), [#154](donghyun81/154-2단계-자동차-경주.md)
+
+**리뷰어 명언:** *"만약 프로젝트에서 사용하는 상수가 1000개 이상이 된다면 어떤 일이 발생할까요?"* — @KwonDae
+
+**해법 패턴 (재사용 범위로 결정):**
+- 한 함수만 사용 → 리터럴 OK
+- 한 클래스 내부만 사용 → 그 클래스의 `companion object` + `private`
+- 여러 클래스 사용 → top-level `const val` + 의미 있는 파일명
+
+### 6. **랜덤이 도메인에 침투** — 테스트 불가
+
+**증상:** `Car.move()`나 `Cars.move()` 안에서 `Random.nextInt(0, 9)` 호출. 결정적 테스트 불가.
+
+**예시 PR:** [#108](Hogu59/108-1단계-자동차-경주.md), [#125](Hogu59/125-2단계-자동차-경주.md), [#127](Junyoung-WON/127-2단계-자동차-경주.md), [#117](jinuemong/117-2단계-자동차-경주.md), [#112](dpcks0509/112-2단계-자동차-경주.md), [#103](dpcks0509/103-1단계-자동차-경주.md), [#92](kmkim2689/92-1단계-자동차-경주.md)
+
+**해법 패턴 (전략 패턴):**
+1. `interface NumberGenerator { fun generate(): Int }` 또는 `fun interface MoveStrategy { fun isMovable(): Boolean }`
+2. 도메인은 인터페이스만 의존
+3. 프로덕션은 `RandomNumberGenerator` 구현체 주입
+4. 테스트는 `FakeGenerator(values: List<Int>)` 같은 결정적 fake 주입
+
+이 패턴은 거의 모든 2단계 PR의 핵심 학습 포인트.
+
+### 7. **데이터 클래스 + var** 또는 **data class에 비즈니스 로직**
+
+**증상:** `data class Car(val name: String, var position: Int = 0) { fun move() ... }` — equals/hashCode가 주생성자만 보는데 var면 동치성 깨질 위험.
+
+**예시 PR:** [#108](Hogu59/108-1단계-자동차-경주.md), [#31](rhthrhrl0/31-1단계-자동차-경주.md), [#175](doabletuple/175-2단계-자동차-경주.md), [#59](boogi-woogi/59-2단계-자동차-경주.md), [#83](yujamint/83-2단계-자동차-경주.md), [#82](drunkenhw/82-2단계-자동차-경주.md)
+
+**해법 패턴:**
+- data class = *데이터 운반 + 동치성*만. 행위가 있으면 일반 class.
+- 단일 값 wrapper = `@JvmInline value class` (Kotlin 1.5+, 인라인)
+- VO(값 객체)는 모든 식별 속성을 주생성자에 (data class가 본업)
+
+### 8. **테스트 함수명의 추상화** — 시나리오 불분명
+
+**증상:** "정상 동작한다", "예외가 발생한다", "올바르지 않은 게임", "유효성 검사".
+
+**예시 PR:** [#40](EmilyCh0/40-1단계-자동차-경주.md), [#57](EmilyCh0/57-2단계-자동차-경주.md), [#103](dpcks0509/103-1단계-자동차-경주.md), [#145](etama123/145-2단계-자동차-경주.md), [#54](briandr97/54-1단계-자동차-경주.md), [#46](Choisehyeon/46-1단계-자동차-경주.md), [#88](JoYehyun99/88-1단계-자동차-경주.md)
+
+**해법 패턴:**
+- `~하면 ~한다` 형식: `randomNumber가 4 이상이면, 자동차가 움직인다`
+- 시나리오 + 결과 함께
+- 요구사항을 그대로 테스트 이름으로
+- given/when/then 주석 (body 안)
+
+### 9. **`it` 연속 사용 + 익명 람다 남용**
+
+**증상:** `cars.filter { it... }.map { it... }.find { it... }`에서 it이 무엇을 가리키는지 매번 다름.
+
+**예시 PR:** [#41](whk06061/41-2단계-자동차-경주.md), [#40](EmilyCh0/40-1단계-자동차-경주.md), [#52](sujin9/52-2단계-자동차-경주.md), [#82](drunkenhw/82-2단계-자동차-경주.md)
+
+**해법 패턴:**
+- 변수명 명시: `cars.filter { car -> ... }` (`it` 대신 `car`)
+- 익명 람다 대신 별도 클래스 — [#115](sh1mj1/115-2단계-자동차-경주.md)에서 `MoveStrategyUsingNumber`를 익명 함수 대신 *별도 클래스*로 둔 게 칭찬받음
+
+### 10. **toString이 도메인에 출력 형식 보유** — OutputView 책임 침범
+
+**증상:** `Car.toString()`이 `"name : ---"` 같은 출력 형식 반환. 출력 변경 시 도메인 변경.
+
+**예시 PR:** [#83](yujamint/83-2단계-자동차-경주.md), [#52](sujin9/52-2단계-자동차-경주.md), [#88](JoYehyun99/88-1단계-자동차-경주.md), [#111](JoYehyun99/111-2단계-자동차-경주.md), [#78](s9hn/78-2단계-자동차-경주.md), [#76](inseonyun/76-2단계-자동차-경주.md)
+
+**해법 패턴:**
+- 백엔드 컨벤션 = OutputView가 표현 담당, 도메인은 원시 값만 노출
+- 안드로이드는 toString을 UI에서 쓰는 경우 OK (회색지대)
+- **enum의 데이터에 UI 표현 (`"-"`)을 넣지 말 것** — UI 변경이 도메인 변경 ([#78](s9hn/78-2단계-자동차-경주.md))
+
+---
+
+## 리뷰어들이 반복적으로 하는 말
+
+### 🎯 "이 클래스의 책임을 한 문장으로 적어보세요"
+
+SRP 자가 검사법. 그 문장이 모호하거나 길면 SRP 위반.
+
+> 단일 책임 원칙이 어긋나 있는지 확인하는 좋은 방법 중 하나는, 이 클래스의 역할과 책임이 무엇인지 한 문장으로 적어보는 것입니다.
+> — @ghojeong on [#91](s6m1n/91-1단계-자동차-경주.md)
+
+**출현 PR:** [#91](s6m1n/91-1단계-자동차-경주.md), [#88](JoYehyun99/88-1단계-자동차-경주.md), [#111](JoYehyun99/111-2단계-자동차-경주.md), [#107](sh1mj1/107-1단계-자동차-경주.md), [#115](sh1mj1/115-2단계-자동차-경주.md)
+
+### 🎯 "휴가 가도 동료가 일할 수 있는 코드를 짜주세요"
+
+함수명 + 시그니처만 보고 동료가 같은 일을 할 수 있는가 = SRP 검사법.
+
+> 조직에서 함께 일할 때 중요한 점은, 내가 마음 편하게 휴가를 가더라도, 동료에게 자신의 일을 믿고 맡길 수 있어야 한다는 점입니다... 업계에 떠도는 맨날 야근하는 개발 조직 괴담이 역할과 책임이 명확하지 않은 함수, 클래스, 혹은 모듈로 인해서 생긴다고 생각해주세요.
+> — @ghojeong on [#109](hxeyexn/109-1단계-자동차-경주.md)
+
+### 🎯 "객체에 메시지를 던져라 (Tell Don't Ask)"
+
+> 클래스를 잘 분리해주신 만큼, 각 클래스(객체)에게 메시지를 던져보는건(입력을 받아!) 어떨까요?
+> — @KwonDae on [#135](moondev03/135-1단계-자동차-경주.md)
+
+> 객체가 자동차를 받아, 자동차에게 단지 메세지만 던져 자동차 스스로 판단해 움직일지 말지 역할을 부여하는것 또한 좋은 방법입니다. 이런식으로 역할을 분리해서 depth를 줄일 수 있습니다.
+> — @KwonDae on [#108](Hogu59/108-1단계-자동차-경주.md)
+
+**출현 PR:** [#108](Hogu59/108-1단계-자동차-경주.md), [#125](Hogu59/125-2단계-자동차-경주.md), [#127](Junyoung-WON/127-2단계-자동차-경주.md), [#135](moondev03/135-1단계-자동차-경주.md), [#161](moondev03/161-2단계-자동차-경주.md)
+
+### 🎯 "테스트하기 쉬운가? = 객체 분리의 기준"
+
+> 제가 객체를 쪼개고 합치는 기준을 오직 "테스트 하기 쉬운가?" 로 한다고 말씀드렸는데...
+> — @ghojeong on [#128](hxeyexn/128-2단계-자동차-경주.md)
+
+분리해도 테스트가 더 명확해지지 않으면 분리할 이유 없음. *분리의 정당화는 테스트 개선이 와야 함*.
+
+### 🎯 "한 문장으로 답할 수 없는 함수 이름 = SRP 위반"
+
+> 그런데, 이 함수에는 동사가 2개가 존재합니다. (input, try) 함수에는 하나의 동사만 포함시켜보면 어떨까요?
+> — @BeokBeok on [#68](hyemdooly/68-1단계-자동차-경주.md)
+
+> end 라는 의미가 조금 모호한 것 같아요... 해당 함수의 역할이 모호하고 비대해질 수 있는 신호를 가지고 있다고 생각해요.
+> — @vagabond95 on [#112](dpcks0509/112-2단계-자동차-경주.md)
+
+### 🎯 "예외는 정말 예외일 때만"
+
+Effective Kotlin Item 7 인용 — 리뷰어 5명 이상이 같은 글 인용.
+
+> - 논리적인 오류일 때만 예외를 던지세요.
+> - 논리 오류가 아니면 예외를 던지지 말고 null을 반환하세요.
+> - 실패하는 경우가 복잡해서 null로 처리할 수 없으면 sealed class를 반환하세요.
+> - 일반적인 코틀린 코드에서 try-catch를 사용하지 마세요.
+> — @s9hn on [#83](yujamint/83-2단계-자동차-경주.md), @galcyurio on [#34](krrong/34-1단계-자동차-경주.md), [#46](Choisehyeon/46-1단계-자동차-경주.md), @sujin9 on [#82](drunkenhw/82-2단계-자동차-경주.md)
+
+### 🎯 "단일 정답 없음, 본인 기준을 가지세요"
+
+> 다만, 도메인 로직인지 아닌지에 대한 판단은 개발자마다 다를 수 있어서 저 또한 팀원들이랑 코드리뷰를 하면서 기준이 바뀌기도 합니다. 이 부분은 저도 명확하게 답변을 드리기가 쉽지 않네요
+> — @galcyurio on [#34](krrong/34-1단계-자동차-경주.md)
+
+> 계속 미션을 진행하면서 크림만의 기준을 잡고 그 기준이 객체지향에서 문제가 없는지는 리뷰어들이 계속해서 의견을 남겨주실테니 항상 본인의 의견을 이야기 해보는 습관을 들이신다면 너무 좋을거 같네요!
+> — @lee-ji-hoon on [#144](ijh1298/144-2단계-자동차-경주.md)
+
+### 🎯 "리뷰어가 *질문으로* 자가 학습 유도"
+
+대부분의 리뷰어가 직접 답을 주지 않고 질문으로 학생이 스스로 답하게 함:
+
+- "이건 어디서 검증해야 할까요?"
+- "object/class 선택 기준은?"
+- "이 함수가 두 가지 일을 하는 것 같은데, 한 가지로 하려면?"
+- "이 클래스의 책임은 무엇인가요?"
+
+가장 칭찬받은 PR [#115](sh1mj1/115-2단계-자동차-경주.md) 리뷰어 평:
+
+> 객체지향 패러다임은 사실 별로 안 중요합니다. 심지님이 불편함을 느낀 부분을 스스로 인지하고, 인지한 부분을 다시 스스로 해결하는 과정이 제일 중요합니다.
+> — @ghojeong
+
+---
+
+## 조영호님 강의 토픽과의 매핑
+
+### `god-object` (자기 책임 외 모든 일을 떠안는 객체)
+
+- **Controller가 god-object**: [#108](Hogu59/108-1단계-자동차-경주.md), [#92](kmkim2689/92-1단계-자동차-경주.md), [#144](ijh1298/144-2단계-자동차-경주.md), [#41](whk06061/41-2단계-자동차-경주.md)
+- **`Cars`(일급 컬렉션)가 god-object**: 우승자 판단 + 컬렉션 관리 — [#50](hyemdooly/50-1단계-자동차-경주.md), [#46](Choisehyeon/46-1단계-자동차-경주.md)
+- **모호한 이름 = god-object 신호**: [#41](whk06061/41-2단계-자동차-경주.md), [#52](sujin9/52-2단계-자동차-경주.md), [#103](dpcks0509/103-1단계-자동차-경주.md)
+
+### `feature-envy` (다른 객체 정보를 묻고 비교)
+
+- `name`, `position` getter 호출 후 외부에서 로직 — [#46](Choisehyeon/46-1단계-자동차-경주.md), [#52](sujin9/52-2단계-자동차-경주.md)
+- Controller가 Car를 받고 외부에서 `if (car.position > maxPos)` — 거의 모든 1단계 PR
+
+### `non-newable` (`new`로 만들지 않을 객체 — 항상 한 개)
+
+- Controller, View 같은 객체는 보통 인스턴스 1개 → object 후보
+- [#91](s6m1n/91-1단계-자동차-경주.md): "object 사용 기준 = 상태 무 + static 메서드/상수만"
+- [#127](Junyoung-WON/127-2단계-자동차-경주.md), [#107](sh1mj1/107-1단계-자동차-경주.md), [#90](Junyoung-WON/90-1단계-자동차-경주.md): object vs class 의문
+
+### `mocking-pressure` (테스트 작성 어려움 = 설계 문제 신호)
+
+- Random 의존 → 테스트 불가 → 인터페이스 + Fake 주입 — [#108](Hogu59/108-1단계-자동차-경주.md), [#127](Junyoung-WON/127-2단계-자동차-경주.md), [#103](dpcks0509/103-1단계-자동차-경주.md), [#125](Hogu59/125-2단계-자동차-경주.md), [#92](kmkim2689/92-1단계-자동차-경주.md), [#82](drunkenhw/82-2단계-자동차-경주.md)
+- Controller 단위 테스트의 함정 — [#40](EmilyCh0/40-1단계-자동차-경주.md): "Controller는 IO 결합 → 단위 테스트 부적합, 통합 테스트가 맞음"
+
+### `Tell-Don't-Ask`
+
+- 메서드 호출로 메시지 던지기 vs property로 묻기 — [#46](Choisehyeon/46-1단계-자동차-경주.md), [#92](kmkim2689/92-1단계-자동차-경주.md), [#108](Hogu59/108-1단계-자동차-경주.md), [#135](moondev03/135-1단계-자동차-경주.md), [#127](Junyoung-WON/127-2단계-자동차-경주.md)
+- `cars.filter { it.position == maxPos }` → `cars.findWinners()` 메시지 형태로
+
+### `책임-역할-협력` (조영호 "객체지향의 사실과 오해" 3요소)
+
+- [#107](sh1mj1/107-1단계-자동차-경주.md): "DI 키워드보다 *역할과 책임* 관점에서. 객체설계 3요소 = 역할, 책임, 협력."
+- [#125](Hogu59/125-2단계-자동차-경주.md): "체스 비유 — 유저(Controller) → 체스판(RacingGame) → 말(Car). 책임의 3층."
+- [#54](briandr97/54-1단계-자동차-경주.md): "차량이 driver를 가짐 — 현실 모델링"
+
+### `의존 방향` (Domain ← Infra/UI)
+
+- Validator가 OutputView 의존 — [#76](inseonyun/76-2단계-자동차-경주.md), [#68](hyemdooly/68-1단계-자동차-경주.md)
+- 인터페이스는 domain, 구현체는 data/infra — [#117](jinuemong/117-2단계-자동차-경주.md): "RandomNumberMaker 인터페이스가 domain에, Provider가 data에"
+
+### `일급 컬렉션`
+
+- `Cars` 일급 컬렉션 표준 패턴 — [#46](Choisehyeon/46-1단계-자동차-경주.md): `List<Car>` 생성자 + `get()` override + companion object 팩토리
+- 컬렉션 자체에 도메인 규칙 (중복, 크기) — [#161](moondev03/161-2단계-자동차-경주.md) 예고편으로 등장
+
+### `원시 강박 (Primitive Obsession)`
+
+- `String` 이름을 그대로 → `Name` 값 객체 — 거의 모든 2단계 PR
+- `Int` 위치를 그대로 → `Position` value class — [#82](drunkenhw/82-2단계-자동차-경주.md), [#83](yujamint/83-2단계-자동차-경주.md), [#24](injoon2019/24-2단계-자동차-경주.md), [#23](awesomeo184/23-2단계-자동차-경주.md)
+- `Int` 시도 횟수 → `TryCount` — [#107](sh1mj1/107-1단계-자동차-경주.md), [#115](sh1mj1/115-2단계-자동차-경주.md)
+
+### `명명 설계`
+
+- 함수명은 동사형 (`generate()` not `generateNumber()`) — [#46](Choisehyeon/46-1단계-자동차-경주.md), [#102](ii2001/102-1단계-자동차-경주.md), [#110](jaeyeongjo/110-2단계-자동차-경주.md)
+- 클래스명은 도메인 의미 (`STANDARD_NUMBER` vs `MOVEMENT_THRESHOLD`) — [#145](etama123/145-2단계-자동차-경주.md)
+- *오해의 비용*을 최소화 (`InputExceptions`가 Exception처럼 보임) — [#111](JoYehyun99/111-2단계-자동차-경주.md), [#44](inseonyun/44-1단계-자동차-경주.md)
+
+---
+
+## 단계별 학습 곡선
+
+### 1단계 흔한 실수 (1단계 PR 다수에 공통)
+
+- `Const.kt` 한 파일에 모든 상수
+- `Validator` / `Util` 같은 모호한 이름
+- Controller가 InputView/OutputView 인스턴스 직접 생성
+- Car.position이 var로 외부 노출
+- 검증을 어디서 할지 결정 못함 (Controller에 그냥 둠)
+- `MutableList`를 외부에 노출
+- 테스트 함수명이 "정상 동작한다" 류
+- 메시지 상수에 매직넘버 박힘 ("1~5글자")
+
+### 2단계에서 부각되는 이슈
+
+- **전략 패턴** 도입 (`NumberGenerator` 인터페이스) — Random 의존 분리
+- **일급 컬렉션** (`Cars`) 본격 시도
+- **VO** (`Name`, `Position`, `TryCount`) — 원시 강박 탈출
+- **검증 위치 재조정** — Controller에서 도메인으로 이동
+- **메서드 vs 클래스 분리 깊이** — "어디까지 분리할까"의 trade-off
+- **테스트 가능성 의식** — Random/IO 분리 시도
+- **`it` → 명시적 변수명** — 가독성
+
+### 1단계 → 2단계 학습 곡선의 시그니처
+
+가장 잘된 PR ([#115](sh1mj1/115-2단계-자동차-경주.md), [#161](moondev03/161-2단계-자동차-경주.md), [#114](Yunseok-Nam/114-2단계-자동차-경주.md))은:
+
+1. 1단계 피드백을 즉시 흡수 (작은 위생부터 큰 구조까지)
+2. 흡수한 피드백을 *자가 검토*로 다시 평가 (맹목 흡수 아님)
+3. 자신의 결정 *이유*를 PR 본문에 명시
+4. 더 깊은 자가 의문을 던짐 ("Controller가 너무 많은 일?")
+
+평범한 학습 곡선 PR은:
+- 1단계 피드백 일부만 반영
+- 같은 안티패턴 (var position, Validator 이름, 매직넘버) 잔존
+- "감사합니다" 답변만 + 자가 회고 부재
+
+---
+
+## 부록: 가장 강력한 리뷰어 명언 10선
+
+1. *"객체지향 패러다임은 사실 별로 안 중요합니다. 불편함을 스스로 인지하고, 인지한 부분을 다시 스스로 해결하는 과정이 제일 중요합니다."* — @ghojeong on [#115](sh1mj1/115-2단계-자동차-경주.md)
+
+2. *"휴가를 가도 동료가 일할 수 있는 코드를 짜주세요... 업계에 떠도는 맨날 야근하는 개발 조직 괴담이 역할과 책임이 명확하지 않은 함수, 클래스, 혹은 모듈로 인해서 생긴다고 생각해주세요."* — @ghojeong on [#109](hxeyexn/109-1단계-자동차-경주.md)
+
+3. *"네이밍이 모호하다는 것은 곧 해당 클래스/함수의 역할이 모호하거나 모호해질 수 있다는 신호이기 때문입니다."* — @vagabond95 on [#103](dpcks0509/103-1단계-자동차-경주.md)
+
+4. *"객체에게 메시지만 던져 자동차 스스로 판단해 움직일지 말지 역할을 부여하는것 또한 좋은 방법입니다. 이런식으로 역할을 분리해서 depth를 줄일 수 있습니다."* — @KwonDae on [#108](Hogu59/108-1단계-자동차-경주.md)
+
+5. *"테스트하기 쉬운가?를 기준으로 객체를 쪼개고 합칩니다."* — @ghojeong on [#128](hxeyexn/128-2단계-자동차-경주.md)
+
+6. *"클래스명을 보니 Exception을 custom한 것으로 보이지만, 실제로는 Exception 타입이 아니네요. 이 클래스가 하는 책임에 대해서 다시 한번 고민해보면 어떨까요?"* — @BeokBeok on [#44](inseonyun/44-1단계-자동차-경주.md)
+
+7. *"DI 라는 키워드에 집착하기 보다는, NumberGenerator 와 의존관계를 가질 class 가 누가 되어야 하는지, 역할과 책임 관점에서 생각을 해보시면 좋을 것 같습니다."* — @ghojeong on [#107](sh1mj1/107-1단계-자동차-경주.md)
+
+8. *"기본적으로 테스트만을 위해 프로덕션 코드가 수정되어서는 안된다고 생각합니다. 테스트가 프러덕션을 위해 존재하는 것이지 그 역의 관계는 아니니까요."* — @vagabond95 on [#41](whk06061/41-2단계-자동차-경주.md)
+
+9. *"객체는 메서드 뿐만 아니라 맴버로도 구성된다는 사실을 잊지 말아주세요."* — @ghojeong on [#128](hxeyexn/128-2단계-자동차-경주.md)
+
+10. *"처음에 최대한도로 세분화하라는 조언은, 보통 합쳐진것을 쪼개는 리팩토링 보다, 쪼개진 것을 합치는 리팩토링이 더 쉽기 때문입니다."* — @ghojeong on [#109](hxeyexn/109-1단계-자동차-경주.md)
+
+---
+
+## 통계
+
+- **분석된 PR:** 133개
+- **분석된 reviewee:** 77명
+- **고유 reviewer:** ~25명 (vagabond95, ghojeong, KwonDae, galcyurio, Gyuil-Hwnag, BeokBeok, laco-dev, malibinYun, sujin9 등이 다수 PR 리뷰)
+- **단계별:** 1단계 = 약 40 PR, 2단계 = 약 90 PR (리팩토링 포함)
+- **분석 기간:** 2022~2025 (closed PR)
+
+이 코퍼스는 "OOP 학습 곡선의 살아있는 데이터"로, 리뷰어들이 같은 안티패턴을 반복 지적하면서 학생들이 라운드를 거듭해 자기 기준을 세워가는 과정의 흔적이다.

package/lessons/woowacourse-racingcar/SeongHoonC/37-1/353/213/250/352/263/204-/354/236/220/353/217/231/354/260/250-/352/262/275/354/243/274.md

@@ -0,0 +1,57 @@
+# PR #37 — [베르] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@SeongHoonC](https://github.com/SeongHoonC)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/37
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 40
+
+## 잘한 점 (설계 관점)
+
+- **MVC 의식적 분리** — Controller / Domain / View / DTO / Data 패키지로 책임 영역 구분 시도.
+- **테스트 코드를 적극 작성** — 도메인 객체에 단위테스트 동반.
+- **자기 판단의 장단점 정리 능력** — 멤버 변수 vs 함수 인자에 대해 장점/단점/생각을 명확히 분리해 답변.
+
+## 못한 점 (설계 관점)
+
+- **DTO에 검증 로직이 들어감** — `CarNamesDTO`가 자동차 개수/이름 길이/중복 검증을 가지고 있어, DTO의 정체성(계층 간 단순 데이터 운반)을 잃음.
+- **도메인 모델이 DTO를 직접 인지** — `Car`가 DTO를 알고 있으면 의존 방향이 역전됨. DTO는 경계에서만 만져야.
+- **`data` 패키지의 정체 불명** — `ComparisonResult`가 왜 도메인 밖에 있어야 하는지 근거가 약함. data 패키지의 존재 이유 자체가 모호.
+- **`ComparisonResult.NONE` 같은 의미 없는 enum 값** — 비즈니스 도메인에서 "승/패/무"를 벗어나는 NONE이 어떤 상황을 표현하는지 불분명. 도메인 어휘를 잃음.
+- **`Car.compare(winner)`처럼 절대적 이름** — 비교는 상대적인데 인자 이름이 `winner`로 결과를 가정. `other`가 자연스러움.
+- **`Judgement`라는 절차 객체** — 우승자 판별이 멤버 변수를 가지고 있어야 할 이유가 없는데 객체로. 행위만 있는 -ment 명사.
+- **`CarMetadataDTO`라는 의미 없는 이름** — "Metadata"는 도메인 어휘 회피의 신호. 실제 의미는 "경주 결과"인데 일반어로 도망.
+- **Controller가 멤버 변수로 게임 상태를 가짐** — 재실행/재사용이 어렵고, 메서드 인자로 전달할 수 있는 값을 굳이 상태화.
+- **`map` 오남용** — 반환을 안 쓰는 곳에 `map`. forEach가 적절.
+- **이동 조건이 "0-9 중 4 이상"으로 도메인에 박힘** — 0-9 발생은 무작위의 관심사인데 자동차가 알게 됨.
+- **테스트 이름이 추상적** — "자동차 이동 테스트", "오류 발생" 같은 표현이 무엇을 테스트하는지 안 드러냄.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **도메인 모델과 DTO의 차이**를 일관되게 짚었다. "DTO는 계층 간 의존성 없이 데이터를 전달하기 위한 것"이며 검증은 도메인이 들어야 한다는 명확한 가이드. 또한 DTO를 도메인이 알게 두면 의존 방향이 역전된다는 점.
+
+또 다른 큰 가이드는 **"도메인 우선 구현"** — InputView부터 만들면 도메인이 정의될 때 View가 다시 바뀌므로, 도메인부터 만들고 거꾸로 입출력 경계를 그려라.
+
+이름에 대해서도 강력한 가이드: `winner`(상대성 무시), `CarMeta`(도메인 어휘 회피), 테스트 이름의 명세화.
+
+- **대표 인용:**
+  > DTO의 역할은 무엇일까요? DTO가 필요한 곳마다 이와 같은 검증 로직이 필요하다면, 모든 계층마다 매번 같은 코드를 작성해야 하지는 않을까요?
+  >
+  > — @laco-dev on `src/main/kotlin/dto/CarNamesDTO.kt`
+
+  > 비교하는 과정에서 winner라는 것은 상대적이지 않을까요? 이기거나 지거나 하는 결과가 나올 수 있어서 `other` 같은 이름도 괜찮을 것 같아요.
+  >
+  > — @laco-dev on `src/main/kotlin/domain/Car.kt`
+
+  > 자동차가 이동하는 조건은 4 이상으로만 볼 수 있지 않을까요? 0 부터 9 사이의 값이 발행되는 것은 랜덤의 관심사로 볼 수 있을 것 같아요.
+  >
+  > — @laco-dev on `src/main/kotlin/domain/Car.kt`
+
+## 얻은 교훈
+
+- **DTO는 데이터 운반체, 도메인은 행위와 invariants의 주인.** 두 가지가 섞이면 (1) 검증이 여러 계층에서 중복되고, (2) DTO가 무거워지고, (3) 도메인이 외부 형식에 끌려간다. DTO는 정말 단순한 데이터 컨테이너로 유지.
+- **도메인 우선 구현이 시간을 아낀다.** Input/View부터 짜면 도메인이 등장할 때 두 번 수정한다. 도메인 모델로 시작하면 View가 거기에 맞춰져 한 번에 정해진다.
+- **enum의 값은 도메인 어휘여야 한다.** `NONE`처럼 "없음을 위한 없음"은 보통 모델링 누락의 신호. 진짜 의미가 있으면 그 이름으로, 없으면 그냥 null 또는 다른 모델로.
+- **인자 이름은 호출자 입장에서 본다.** `compare(winner)`처럼 결과를 가정하면 비교를 호출하기 전에 답을 안다는 가정이 코드에 박힌다. `other`처럼 중립적이어야 비교가 진짜 비교가 된다.
+- **무작위/외부 자원의 출력 범위는 그 자원의 관심사.** "0-9 중 4 이상"이 자동차에 박히면 자동차가 난수 표현을 알게 된다. 자동차는 단지 "이번에 움직일까?"라는 boolean을 받는 쪽이 자연스럽다.
+- **`X-er`, `X-ment`, `X-Metadata`는 도메인 어휘 회피의 신호.** 그 이름 뒤에 진짜 도메인 개념이 있다. `Judgement` → `RaceResult`, `CarMetadata` → `RaceRecord` 같은 식으로.

package/lessons/woowacourse-racingcar/SeongHoonC/66-2/353/213/250/352/263/204-/354/236/220/353/217/231/354/260/250-/352/262/275/354/243/274.md

@@ -0,0 +1,48 @@
+# PR #66 — [베르] 2단계 자동차 경주 미션 제출합니다
+
+- **Reviewee:** [@SeongHoonC](https://github.com/SeongHoonC)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/66
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 12
+
+## 잘한 점 (설계 관점)
+
+- **`RaceTime` 도메인 객체 도입** — 1단계의 raw Int를 도메인 개념으로 승격. 원시 강박 해소 시도.
+- **`CarsFactory`로 Cars 생성 책임 분리** — 자동차 묶음 생성 로직을 별도 객체로.
+- **`NumberGenerator` 인터페이스 도입** — 무작위 의존을 추상 뒤로 격리.
+- **리뷰 후 빠른 반영과 학습 의지** — 고차 함수 적용을 "너무 신기하네요"라는 반응으로 흡수.
+
+## 못한 점 (설계 관점)
+
+- **`RaceTime`이 한 번 쓰면 끝나는 가변 객체** — `raceTime.reduceTime()`로 내부 상태가 소진되면 두 번째 호출에서 의도와 다른 동작. 사이드 이펙트가 시그니처 밖에서 발생.
+- **`CarsFactory`가 구체 타입을 받음** — `NumberGenerator` 인터페이스 대신 구현체를 직접 받으면 추상의 가치가 무효.
+- **테스트 이름이 "에러가 발생하지 않는다" 같은 추상 표현** — 무엇이 정상인지를 명세하지 못함.
+- **`Controller.getRaceTime()`이 raw Int 반환** — 도메인 객체 `RaceTime`을 만들었으면서 정작 흐름은 원시 타입을 주고받음.
+- **테스트만을 위한 public 노출** — 에러 메시지 상수 같은 것을 테스트 때문에 외부에 노출.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 두 가지 중요한 관점을 짚었다.
+
+1. **불변성과 재사용성** — `RaceTime`이 자기 상태를 소진하는 가변 객체면 호출자가 라이프사이클을 매번 신경 써야 한다. 고차 함수로 "횟수만 받아서 N번 반복" 형태로 만들면 객체 자체는 불변이 된다.
+2. **테스트 이름은 명세** — "에러가 발생하지 않는다", "정상 작동" 같은 추상 표현 대신 도메인 규칙을 직접 적기. "자동차는 한번에 1대에서 20대 이하로만 만들 수 있다"처럼.
+
+또한 **추상 타입을 받기** — Factory가 구체 NumberGenerator 대신 인터페이스를 받아야 추상의 의미가 산다.
+
+- **대표 인용:**
+  > RaceTime을 파라미터로 넘기다 보면 의도치 않은 동작을 만들 수 있는 사이드 이펙트가 발생할 수 있다는 뜻이 됩니다 ... 재사용 가능하도록 만들려면 어떤 전략을 사용할 수 있을까요? 코틀린의 repeat() 함수처럼 반복하는 기능에 집중을 할 수 있도록 개선 해 보면 어떨까요?
+  >
+  > — @laco-dev on `src/main/kotlin/domain/RaceTime.kt`
+
+  > 자동차 개수가 1 이상 20대 이하이고 중복이 없다면 에러가 발생하지 않는다 --> 자동차는 한번에 1대에서 20대 이하로만 만들 수 있다 ... 자동차 이름에 중복이 있으면 에러가 발생한다 --> 자동차는 같은 이름으로 만들 수 없다
+  >
+  > — @laco-dev on `src/test/kotlin/domain/CarsFactoryTest.kt`
+
+## 얻은 교훈
+
+- **불변 객체는 라이프사이클의 자유를 준다.** 자기 상태를 소진하는 객체는 호출자가 "이미 썼나?"를 신경 써야 한다. 불변으로 만들면 동일 객체가 N번 안전하게 쓰일 수 있다 — 사이드 이펙트의 첫 번째 격리 전략.
+- **고차 함수로 "반복"을 표현하면 객체는 데이터에만 집중한다.** `RaceTime(5).reduceUntilZero()`보다 `repeat(raceTime) { ... }`이 데이터(횟수)와 행동(반복)을 분리. 객체는 단지 횟수를 알 뿐.
+- **추상은 사용 시점에 받는다.** 구체 타입을 받으면 그 자리에서 추상이 무너진다. Factory/Service가 추상 인터페이스를 받아야 진짜 격리.
+- **테스트 이름 = 시스템 요구사항.** "에러 안 남"은 단언 기준일 뿐 명세가 아니다. 도메인 규칙 그 자체를 문장으로 적어야 코드 외부에서 시스템을 이해할 때 가치를 한다.
+- **도메인 객체를 만들었다면 그 객체로 흐름을 채워라.** `RaceTime` 클래스가 있는데 정작 `getRaceTime()`이 Int를 반환하면, 그 객체는 정의만 있고 사용되지 않는다. 흐름 전체가 도메인 어휘로 통일되어야 의미가 산다.

package/lessons/woowacourse-racingcar/Songusika/84-2/353/213/250/352/263/204-/354/236/220/353/217/231/354/260/250-/352/262/275/354/243/274.md

@@ -0,0 +1,60 @@
+# PR #84 — [페어 자동차 경주 미션 제출] 송이카
+
+- **Reviewee:** [@Songusika](https://github.com/Songusika), 페어로 진행
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/84
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @RightHennessy
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **Name, Count, Cars 등 도메인 분리** — 원시 강박 탈출.
+- **`Name`을 data class로 (VO 의도)** — 값 객체 모델링 시도, 페어가 자바 record와의 차이까지 직접 정리.
+- **`RandomNumberGenerator` 인터페이스** — 테스트 가능성 인지.
+- **`RacingGameController`의 재입력 처리** — 사용자 입력 오류 회복 흐름 정리.
+- **페어 진행** — 두 사람의 토론 결과가 PR에 풍부함 (data class vs record 비교 등).
+
+## 못한 점 (설계 관점)
+
+- **`Car.position`이 외부 접근 가능 (public var)** — `private set` 누락. 리뷰 후 수정.
+- **`Cars`의 `filter().map()` 체이닝 결과를 List로 다시 받음 → 일급 컬렉션을 새로 만들어주는 시점 누락** — `map` 반환이 `List<T>`인데 그걸 또 Cars로 감싸야 했음.
+- **`maxOf` vs `maxBy` 혼용** — 최댓값 vs 최댓값 객체. 도메인 의도에 맞는 선택 안 됨.
+- **`InputView`에서 null 처리를 throw로 끝냄** — smart cast/`readln()`로 도메인 향한 안전 보장 안 함.
+
+## 리뷰어 의견 요지
+
+리뷰어 @RightHennessy는 **"질문 + 자료 링크"**로 학생의 추가 학습 유도.
+
+1. **data class vs record** — "왜 data class를 썼는가? 자바 record와 차이는?" → 페어가 5가지 차이점 정리 (copy, var/val, 비구조화, 상속, 인스턴스 프로퍼티). 그리고 역질문 "Sample1 vs Sample2 차이는?" → 리뷰어가 답: `equals/hashCode`는 주 생성자만 고려 → 주 생성자 밖 프로퍼티는 동치성 비교에서 빠진다.
+
+2. **`maxOf` vs `maxBy`** — "최댓값" vs "최댓값을 가진 객체". 도메인 표현(우승자는 객체)에 맞는 함수.
+
+3. **`map`의 반환 = `List<T>`** — `filter().map()`이 List를 만드는데, 호출자가 또 List로 감싸 이중 작업.
+
+4. **Car.position 캡슐화** — 외부 접근 가능. `private set` 권장.
+
+5. **smart cast** — `val input = readLine() ?: throw IllegalArgumentException()` 이후 컴파일러가 input을 non-null로 추론 → 반환 타입을 nullable로 유지할 필요 없음.
+
+학생과 리뷰어가 **양방향 질문**으로 진행 — 학생이 역으로 퀴즈를 내고 리뷰어가 답하는 흥미로운 상호작용.
+
+- **대표 인용:**
+  > Name 클래스를 data class로 만들어주셨군요! 혹시 사용한 이유를 설명해 주실 수 있을까요? 추가적으로, java의 record와는 어떤 차이점이 있을까요?
+  >
+  > — @RightHennessy on `src/main/kotlin/racingCar/domain/Name.kt`
+
+  > equals와 hashCode는 주 생성자에 나열된 모든 프로퍼티를 고려해 만들어진다. 이때 주 생성자 밖에 정의된 프로퍼티는 eqauls나 hashCode를 계산할 떄 고려의 대상이 아니다.
+  >
+  > — @RightHennessy on `src/main/kotlin/racingCar/domain/Name.kt` (kotlin in action 인용)
+
+  > 현재 Car의 postion은 외부에서 접근이 가능하네요. 외부에서 접근하지 못하도록 변경해보시는 것은 어떨까요 ~ ?
+  >
+  > — @RightHennessy on `src/main/kotlin/racingCar/domain/Car.kt:5`
+
+## 얻은 교훈
+
+- **data class의 `equals/hashCode`는 주 생성자만 본다.** "본문에 선언한 프로퍼티"는 동치성 비교에서 빠짐. VO를 만들 때 모든 식별 속성은 주 생성자에 넣어야 함.
+- **`maxOf` vs `maxBy`의 의미 차이.** 도메인이 "우승자(객체)"를 표현해야 하면 `maxBy`. "거리(스칼라)"라면 `maxOf`. 함수 이름이 도메인 의도를 반영.
+- **일급 컬렉션의 변환 = 한 번만 감싼다.** `cars.filter().map()`의 반환이 `List<Car>`인데 다시 `Cars(it)`로 감싸야 하면 중간에 List를 두는 게 의미 없음.
+- **smart cast로 nullable의 흐름 종결.** null 검사 후 컴파일러가 non-null로 좁히면, 반환 타입까지 non-null로 끌어올림. throw 한 줄로 도메인이 깨끗.
+- **페어 프로그래밍의 가치 = PR에 토론이 보임.** "왜 이렇게 했는가"가 두 사람의 합의로 들어오면 리뷰가 그 합의를 검증하는 단계로 격상.
+- **양방향 질문 = 깊이의 신호.** 학생이 "이 두 코드의 차이가 뭘까요?"로 역질문하면 리뷰어가 자료를 인용해 답하면서 토론의 격이 올라감.

package/lessons/woowacourse-racingcar/Yunseok-Nam/114-2/353/213/250/352/263/204-/354/236/220/353/217/231/354/260/250-/352/262/275/354/243/274.md

@@ -0,0 +1,43 @@
+# PR #114 — [자동차 경주 - 리팩토링] 서기 미션 제출합니다
+
+- **Reviewee:** [@Yunseok-Nam](https://github.com/Yunseok-Nam)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/114
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 6
+
+## 잘한 점 (설계 관점)
+
+- **이전 라운드 피드백 흡수 (EOF, 함수 분리, 테스트 네이밍)** — 작은 지적도 끝까지 반영.
+- **`@JvmStatic` 이해 + 자체 정리** — `companion object` 메서드가 자바 변환 시 Companion 내부 메서드가 되고, JUnit5(Java)가 `@MethodSource`에 static 요구 → `@JvmStatic` 필요. 깊이 있는 답변.
+
+## 못한 점 (설계 관점)
+
+- **테스트 내부 헬퍼 메서드 (`moveTwice`)가 public** — 테스트 클래스 외부에서 접근 가능 (불필요). private 접근 제한자 누락.
+- **`@MethodSource` factory 메서드의 case 데이터를 별도 TestCase 클래스로 분리하지 않음** — 케이스 수 늘면 가독성 저하 가능.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag은 **"고민해볼 점"으로 던지고 학생이 자가 답변** 스타일 유지. 이번 라운드는 리팩토링이라 코멘트도 적음 (6개).
+
+1. **`@JvmStatic`의 이유** — 정답을 묻지 않고 "차이점이 무엇일까요?"로 던짐. 학생이 자바 변환 코드까지 직접 디컴파일해 정리.
+
+2. **테스트 헬퍼의 접근 제한자** — "private으로 막는 방식"이 안 보인다는 지적. 테스트 코드도 캡슐화 대상.
+
+3. **TestCase 분리 trade-off 명시** — "별도 파일로 뽑으면 케이스 한눈에 보기 좋다 / 단점은 두 파일을 살펴봐야 함" → 양면 트레이드오프를 학생에게 던짐.
+
+- **대표 인용:**
+  > moveTwice의 경우 해당 CarTest에서만 사용을 하므로 private 접근 지정자로 외부에서의 접근을 막는 방식으로 가봐도 좋을 것 같습니다!! 그외에 테스트에 대한 케이스 관리를 위해서 TestCase로 뽑아두는 방식도 고민해볼 필요는 있는 것 같습니다~
+  >
+  > — @Gyuil-Hwnag on `src/test/kotlin/model/CarTest.kt:16`
+
+  > 과연 @JvmStatic 어노테이션을 정의 안한것이랑 정의한 것에는 어떤 차이점이 있을까요??
+  >
+  > — @Gyuil-Hwnag on `src/test/kotlin/model/CarsManagerTest.kt:33`
+
+## 얻은 교훈
+
+- **테스트 코드도 캡슐화 대상.** 헬퍼 함수가 외부에서 안 쓰이면 private. 테스트라고 접근 제한 자유로운 게 아님.
+- **`@JvmStatic`의 본질 = "JVM 바이트코드 레벨 static 강제"**. Kotlin `companion object` 메서드는 Companion 인스턴스 메서드로 컴파일됨. Java가 진짜 static을 요구하는 자리에서는 어노테이션이 필요.
+- **TestCase 분리는 케이스 수의 함수**. 케이스 3-5개면 inline, 10개 넘으면 별도 파일로 빼는 게 가독성. "이 한 줄에서 모든 케이스를 볼 수 있나?"가 기준.
+- **자가 답변의 깊이 = 학습 곡선의 신호.** 리뷰어가 "차이점이 뭘까요?"로 던졌을 때 디컴파일까지 가서 답한 깊이는 다음 라운드의 리뷰 깊이도 끌어올림.

package/lessons/woowacourse-racingcar/Yunseok-Nam/96-1/353/213/250/352/263/204-/354/236/220/353/217/231/354/260/250-/352/262/275/354/243/274.md

@@ -0,0 +1,54 @@
+# PR #96 — [자동차 경주] 서기 미션 제출합니다
+
+- **Reviewee:** [@Yunseok-Nam](https://github.com/Yunseok-Nam)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/96
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`Validation` object 분리** — 검증 로직 외부화.
+- **`RandomNumber` 인터페이스 도입** — 테스트 가능성 확보를 위한 추상화.
+- **`CarsManager`로 Cars 컬렉션 관리** — 일급 컬렉션의 초기 형태.
+- **`forwardCount`를 주 생성자에서 빼고 내부 초기화** — "Car 생성 시 forwardCount 0이어야 한다"는 invariant 보호.
+- **getter 제거 후 property 사용** — 코틀린식 캡슐화.
+- **`require` 활용** — 도메인 무결성 검증.
+
+## 못한 점 (설계 관점)
+
+- **`Validation`이라는 일반 이름** — 무엇을 검증하는지 모름. `carName` 같은 동사형으로도 부족 (`checkName`이 낫다).
+- **`Car`가 검증을 직접 안 하고 `Validation` object에 위임** — 도메인 무결성을 외부 유틸리티가 책임.
+- **Controller의 `run`이 여러 단계 (초기화/플레이/결과) 한 메서드에 뭉침** — 함수 분리 필요.
+- **`CarsManager`의 "Manager" 접미사** — 책임이 모호한 일반어. 무엇을 manage 하는지 코드 본문 봐야 앎.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag은 **확정 의견보다는 "고민해볼 점" 던지기** 스타일.
+
+1. **함수 책임 분리** — Controller의 `run`을 `initialize / play / result` 셋으로 쪼개라.
+
+2. **Validation의 위치 토론** — "Car에서 직접 안 하고 ValidationUtils로 뽑은 이유는?" → 학생은 "InputView 선에서 사용자 입력 에러 잡고, 도메인 검증은 입력 재시도 확장에 유리하다"로 답. 리뷰어 수용.
+
+3. **테스트 네이밍 GWT** — `자동차가 1칸 이동하면 거리는 1이다` 같은 한국어 fun 이름 + body 안 given/when/then 주석.
+
+4. **forwardCount 위치** — 주 생성자 파라미터로 받지 말고 내부에서 0으로 초기화. → 학생이 정확히 이 변경을 적용.
+
+5. **함수 이름 = 동사** — `Validation.carName()` 같은 명사 이름은 "이게 뭐 하는 함수냐"가 안 보임. `checkName()`처럼 동사.
+
+- **대표 인용:**
+  > 참고로 함수 네이밍의 경우 Validation(확인) 이라는 뜻에 맞게 carName -> checkName으로 변경 고려해 해보는 것도 좋을 것 같습니다!! import 하였을 때 단순히 carName 만으로는 어떤 기능을 담당하는 함수인지에 대한 판별이 어려울 수도 있겠다는 생각이 들어
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/util/Validation.kt`
+
+  > 개인적인 생각이지만 Car라는 class에 fowarCount 값을 파라미터로 가지면서 변경하는 방법도 좋지만 Car 클래스 내부적으로 forwardCount를 가지고 있는 것도 고민해볼 필요는 있는 것 같습니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/model/Car.kt`
+
+## 얻은 교훈
+
+- **도메인 객체의 초기 상태는 생성자가 아니라 init/default가 담아야 한다.** `Car(name)`로 받고 forwardCount는 0으로 시작. 외부가 초기 위치를 정할 권리가 없다.
+- **함수 이름은 동사형 + 무엇에 대한 동사**. `carName()`은 명사라 부르는 쪽에서 "이 함수는 뭘 하는 거지?"가 됨. `checkName()`, `validateName()`처럼 동사로.
+- **검증의 위치 = 입력 재시도 확장성으로 정해질 수 있다.** "도메인 init에서 던지면 catch해서 재입력 어렵다 → InputView/Validator 선에서 잡고 정상 흐름으로"라는 논리가 성립.
+- **getter 메서드 제거 = property 활용.** Kotlin에서 `getForwardCount()` 자바식 메서드는 자동 생성된 property getter가 이미 있는데 또 만든 셈. 호출 측에서 `car.forwardCount`로 단순화.
+- **"Manager", "Util", "Helper" 같은 일반어 접미사는 책임 회피의 흔적.** 무엇을 관리하는지 / 무엇을 돕는지가 이름에 드러나야 함.