oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/gaeun5744/124-/353/246/254/355/214/251/355/204/260/353/247/201.md

@@ -0,0 +1,53 @@
+# PR #124 — [자동차 경주 리팩터링] 벼리 미션 제출합니다
+
+- **Reviewee:** [@gaeun5744](https://github.com/gaeun5744)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/124
+- **단계:** 리팩터링
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 8
+
+## 잘한 점 (설계 관점)
+
+- **`Car` 초기값 생성자 주입 가능** — 리뷰어 명시적 칭찬.
+- **`@CsvSource` 활용** — 리뷰어 칭찬.
+- **자기 의문의 깊이** — "검증 중복 vs 한 곳에 모으기"에 대한 trade-off 분석 시도.
+
+## 못한 점 (설계 관점)
+
+- **Controller가 라운드 진행 직접 수행** — 핵심 미션의 도메인 로직이 Controller에. (다른 reviewee들과 같은 패턴)
+- **`CarsManager.create` 사용 — 외부 검증의 초기값 활용 어려움** — 학생 본인이 어려움을 표명.
+- **검증 중복 (Car + InputView)** — 학생이 자기 trade-off를 인식.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 이 PR에서 매우 인상적인 **시나리오 시뮬레이션 가이드**를 제시:
+
+**시나리오 1:** "자동차 이름 요구사항이 변경 - 숫자/특수문자 필요, 1~10자" 시 어떤 변경점/장단점?
+**시나리오 2:** "InputView 검증 없이 사용자가 잘못 입력하면 매번 종료 → try-catch가 범벅" 시 어떤 장단점?
+
+두 시나리오로 학생이 "한 곳 vs 여러 곳"의 trade-off를 직접 시뮬레이션하게 만든다. 답을 주지 않고 학생이 도달하게 함.
+
+**"중복 코드인가 반복 코드인가"** 라는 메타 질문 — 시니어와의 대화에서 받은 화두. 같은 코드라도 "중복(제거할 것)"과 "반복(허용할 것)"의 의도 차이가 있음.
+
+**"개발의 세계는 trade-off가 떡칠된 세상"** — 학생이 합리적인 사고를 하고 있다는 인정 + 정답을 주지 않는 리뷰 스타일.
+
+- **대표 인용:**
+  > 자동차에 이름에 대한 요구사항이 변경되었어요. 숫자와 특수 문자는 반드시 들어가야하고요, 글자수도 1~10로 범위가 늘어나게 되었어요. 이런 경우 지금의 프로젝트는 어떤 변경점과 장단점이 생겨날까요?
+  >
+  > — @malibinYun on `src/main/kotlin/view/InputView.kt:42`
+
+  > InputView에다가 검증 로직을 작성하지 않게 되었다고 가정해볼게요 ... try-catch가 범벅되어서 그래서 뭐가 로직인지 눈에 들어오지 않게됐어요. 이런 경우 지금의 프로젝트는 어떤 장단점이 생겨날까요?
+  >
+  > — @malibinYun on `src/main/kotlin/view/InputView.kt:42`
+
+  > "중복 코드인가요? 반복 코드인가요?" 무슨 의미인지 물어보지 않고 혼자 곱씹으면서 많은 생각들을 하게 되더라구요.
+  >
+  > — @malibinYun on `src/main/kotlin/view/InputView.kt:42`
+
+## 얻은 교훈
+
+- **시나리오 시뮬레이션 = 결정 trade-off의 진단 도구.** "X가 바뀌면 어디가 영향받나"를 두 가지 다른 설계에 대해 시뮬레이션하면 trade-off가 즉시 보임.
+- **"중복 vs 반복" 화두.** 같은 코드가 두 군데 있어도, (1) 우연히 같은 것(중복, 한곳에 통일 필요) vs (2) 의도적으로 같은 것(반복, 허용 가능)이 다름. 코드의 의도가 결정 기준.
+- **검증 중복의 합리성.** 사용자 안내(InputView) vs 도메인 무결성(Car)은 다른 목적. 둘 다 필요할 수 있고, 그 경우는 "반복"이지 "중복"이 아님.
+- **답을 주지 않는 리뷰의 가치.** 시나리오만 제시하면 학생이 자기 추론으로 답에 도달. 그 답이 자기 것이 됨.
+- **trade-off가 떡칠된 세상.** OOP의 결정 거의 모든 곳에 trade-off가 있다. "정답"이 아니라 "이 맥락에서 더 나은 것"을 찾는 훈련.

package/lessons/woowacourse-racingcar/gaeun5744/93-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,60 @@
+# PR #93 — [자동차 경주 구현] 벼리 미션 제출합니다
+
+- **Reviewee:** [@gaeun5744](https://github.com/gaeun5744)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/93
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 25
+
+## 잘한 점 (설계 관점)
+
+- **README에 기능 목록 정리** — 리뷰어 칭찬.
+- **`RandomNumber` 분리로 테스트 가능성 확보** — 리뷰어 칭찬.
+- **자기 결정 논리적 표명** — Validation 위치를 두 가지 이유로 정리. 검증의 자리에 대한 깊은 회고.
+- **객체지향의 사실과 오해 인용** — "메서드는 객체의 상태 변화 + 상호작용 수단"이라는 정의를 자기 결정에 적용.
+
+## 못한 점 (설계 관점)
+
+- **`util.Validation`으로 검증 모음** — 검증을 helper로 분리. 응집도 손상.
+- **`util.NumberGenerator`** — 도구 상자 비유로 모호한 명명.
+- **`CarsManager`가 `create` 호출 강제** — 생성자 + init 블록으로 해결.
+- **`getForwardCount()` 자바 스타일 게터** — 코틀린 프로퍼티 활용 부족.
+- **마지막 라인 줄바꿈 누락** — POSIX 컨벤션 위반.
+- **테스트 이름 모호**.
+- **`OutputView`가 companion object에 함수** — class member로 두는 게 자연스러움 (다만 학생 본인이 회고로 object로 변경).
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 이 PR에서 인상적인 **메타 가이드** 들을 다수 전달:
+
+1. **"투머치코틀린"** — 가독성을 해치는 과한 문법 활용 경계.
+2. **"코드 = 언어"** — 일상 생활에서 알아들을 수 있는 코드. 게임 커뮤니티 용어로 일상에서 말 못 함.
+3. **"한국에서 익숙함을 따르는 vs 자기 결정"** — 익숙한 패턴을 따르는 것도 가치 있지만, 더 낫다고 생각하면 그 이유를 단단히 다져라.
+
+또한 **"도구 상자 비유"** 로 Util 명명 안티패턴 시각화 — 본인은 알지만 친구가 컨실러를 찾으러 왔을 때 "도구 상자"에서 찾기 어렵다.
+
+`CarsManager.create` 호출 강제는 **생성자 + init**으로 해결.
+
+학생의 self-reflection이 깊고 리뷰어가 그것을 자극하는 흐름이 가장 인상적.
+
+- **대표 인용:**
+  > 파운데이션, 하이라이터, 컨실러 등등.. 이것들이 담긴 상자에 "도구 상자" 라는 이름을 적어두어도, 사실 올바른 표현이지요! ... 하지만, 과연 피부화장을 위한 도구를 찾아야할 때, "도구 상자" 라는 이름이 붙은 상자에 원하는 화장품들이 존재할 거란 생각이 한 번에 들 수 있을까요?
+  >
+  > — @malibinYun on `src/main/kotlin/util/NumberGenerator.kt:2`
+
+  > 코틀린 문법을 엄청나게 활용해서 이렇게까지 된다고?? 할 정도의 무언가를 내놓더라도, 읽는 데 한세월이고 알아보기 어렵다면 저는 "투머치코틀린" 이라고 생각해요.
+  >
+  > — @malibinYun on `src/main/kotlin/model/Car.kt`
+
+  > 그만큼, 더 낫다고 생각하게 된 스스로의 이유를 단단히 다져보세요. 그리고 설득력있게 다듬어보세요.
+  >
+  > — @malibinYun on `src/main/kotlin/util/Validation.kt`
+
+## 얻은 교훈
+
+- **"도구 상자" 비유의 본질 = Util 명명의 한계.** 본인은 알지만 외부인에게는 무엇이 들었는지 모름. 도메인 어휘로 명명해야 외부가 찾기 쉬움.
+- **"투머치코틀린" 경계.** 언어의 강력한 기능을 사용 = 항상 좋음이 아님. 가독성 + 다른 개발자의 학습 비용 trade-off.
+- **코드 = 언어, 일상 생활 어휘로.** "이게 된다고??" 수준의 코드는 게임 커뮤니티의 용어와 같음. 코드는 일상 생활 어휘로 작성하라.
+- **객체지향의 사실과 오해의 메서드 정의 적용** — "상태 변화 + 상호작용 수단"이라는 정의로 OutputView를 점검 → object로 결정. 책에서 배운 개념을 코드에 적용한 학습.
+- **익숙함 따르기 vs 자기 결정.** 두 가지 모두 가치 있지만, 자기 결정의 이유를 단단히 다져라. 논리가 무너지면 의견을 되돌아보면 됨.
+- **POSIX 줄바꿈** — 마지막 라인의 `\n`은 단순 컨벤션이 아니라 POSIX 정의. 학생이 자료 추천 후 학습.

package/lessons/woowacourse-racingcar/gahyunkim/134-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,53 @@
+# PR #134 — [자동차 경주 구현] 조이 미션 제출합니다
+
+- **Reviewee:** [@gahyunkim](https://github.com/gahyunkim)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/134
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 36
+
+## 잘한 점 (설계 관점)
+
+- **`RandomNumberGenerator` 인터페이스로 추상화** — 무작위 의존을 추상으로 격리.
+- **자기 의문을 PR description에 상세히 기록** — 검증 위치, 한 줄 require의 가독성, 테스트 케이스 분리 등 메타 질문을 적극 제시.
+- **리뷰 반영의 메타 정리 능력** — `OutputView`/`RacingGame`/검증의 자리를 자기 언어로 재정의.
+
+## 못한 점 (설계 관점)
+
+- **`RacingGame`이 자동차 이름 분리/준비/검증/경주 진행을 모두 함** — 한 클래스가 게임 전체의 라이프사이클을 책임.
+- **`tryRacing()` 함수의 반환값이 String** — 무엇을 반환하는지 호출자가 함수 본문을 봐야 앎. 시그니처가 의도를 말하지 못함.
+- **`RandomNumberGenerator`라는 구현 단서를 인터페이스에 박음** — 구현체가 `Fixed`/`Sequential`이 되면 이름이 거짓말이 됨.
+- **`OutputView`가 외부에서 만들어진 문자열을 받아 출력** — View가 어떻게 표현할지 결정하지 못하고 단순 println으로 격하.
+- **`Controller.run()`이 "입력 → 입력 → 출력"의 흐름이지 "준비 → 경주 → 결과"가 아님** — 함수의 흐름이 도메인 이야기를 따라가지 않음.
+- **`Car.getPosition()`처럼 자바 스타일 게터** — 코틀린 프로퍼티 직접 노출로 충분.
+- **테스트 이름이 "여러가지 유효성을 테스트한다"처럼 모호** — 무엇이 어떻게 검증되는지 명세화 부족.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **함수의 흐름이 도메인 이야기여야 한다** 는 강력한 가이드를 제시. "이름 입력 → 횟수 입력 → 우승자 출력"이 아니라 "자동차 준비 → 횟수 입력 → 경주 → 우승자 찾기 → 출력". 같은 코드를 두 가지 다른 흐름으로 보여주며 "대화처럼 흘러야 좋은 코드"라는 메타 가이드.
+
+또한 **인터페이스의 이름은 What** — `RandomNumberGenerator` 안에 `FixedNumberGenerator`도 들어갈 수 있어야 함. 같은 코드가 보이지 않는 미래 구현을 허용하는지 묻는 식.
+
+OutputView에 대해서는 **"깔끔 vs 옳은 방법"** 의 메타 가이드 — 외부에서 만든 문자열을 받아 출력하는 OutputView는 "Any를 받는 print()"와 같다는 식의 강한 비판.
+
+- **대표 인용:**
+  > 게임을 준비하고, 진행하고, 결과를 만들어내기 위한 흐름이 잘 드러나고 있을까요? ... 코드를 작성하는 것도, 결국 대화를 이어가는 것처럼 순서와 흐름이 자연스럽게 흘러갈수록 좋은 코드가 될 수 있습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/RacingController.kt`
+
+  > 다른 개발자가 게임을 이용한다고 했을떄 tryRacing이 무엇을 반환할지 예측이 될까요? 저라면 반환하는 String이 무엇인지 도저히 모를 것 같습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/model/RacingGame.kt`
+
+  > 이 객체가 할 역할은 숫자를 생성하는 건가요? 랜덤 숫자를 생성하는 건가요? ... class FixedRandomNumberGenerator: RandomNumberGenerator { override fun generate(...) = 10 }
+  >
+  > — @laco-dev on `src/main/kotlin/model/RandomNumberGenerator.kt`
+
+## 얻은 교훈
+
+- **흐름은 도메인 이야기로 짜여야 한다.** 함수가 입력/출력의 나열이 아니라 **"준비 → 진행 → 결과"** 같은 도메인 서사를 따라야 호출자가 한눈에 의도를 잡는다.
+- **함수 시그니처는 호출자와의 약속.** `tryRacing(): String`은 무엇의 String인지 호출자가 본문을 읽어야 안다 — 의도가 시그니처에 없는 약속. `runRace(): Unit` + `getWinners(): List<Car>`처럼 의도를 시그니처에 박는다.
+- **인터페이스 이름은 미래의 구현체에 열린다.** `RandomXxx`처럼 한 구현을 못 박지 말 것. 인터페이스는 "다른 구현이 들어와도 자연스러운가"로 평가.
+- **View는 단순한 println 어댑터가 아니다.** 출력 형식을 어디서 만드는가 = 표시 책임의 자리. View가 도메인 객체를 받아 표현해야 도메인이 표시 형식을 알 필요가 없다.
+- **클래스 프로퍼티는 라이프사이클이 클래스 = 객체와 일치할 때만.** 한 번의 게임이라는 흐름이라면 함수 지역 변수가 더 자연스럽다. "가시성과 지역성을 가장 작은 것부터 시작"하라는 원칙.
+- **테스트 케이스명은 시스템 명세** — "여러 유효성을 테스트한다"는 표현은 무엇이 무엇과 어떻게 다른지 안 드러낸다. 각 케이스는 그 자체로 도메인 규칙이어야.

package/lessons/woowacourse-racingcar/gahyunkim/164-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,54 @@
+# PR #164 — [자동차 경주 2단계] 조이 미션 제출합니다
+
+- **Reviewee:** [@gahyunkim](https://github.com/gahyunkim)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/164
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 14
+
+## 잘한 점 (설계 관점)
+
+- **`CarFactory`로 자동차 생성 책임 분리** — 1단계의 비대한 `RacingGame`에서 책임을 떼냄. 이름도 `CarCreator`에서 `CarFactory`로 통상적 도메인 어휘로 개선.
+- **`RaceResult` 클래스 도입** — `List<List<Car>>` 같은 원시 강박 시그니처를 도메인 객체로 승격.
+- **`CarState` 도입으로 라운드별 상태 표현** — copy() 남용을 줄이고 의미 있는 도메인 모델로 표현.
+- **private 가시성을 적극 사용** — 외부에 노출할 필요 없는 메서드를 private로.
+- **리뷰의 메타 가이드를 자기 언어로 흡수** — "가시성은 가장 작은 것부터"라는 캡슐화 원칙을 코드에 적용.
+
+## 못한 점 (설계 관점)
+
+- **`CarCreator`라는 -er 명사** — Factory로 바뀌면서 해결됨. 그 전 단계에서는 행위만 있는 절차 객체였음.
+- **파싱(따옴표 기준 split)이 도메인에 위치** — UI 형식이 도메인을 변경시키는 결합.
+- **`Constants` 파일 사용에 대한 의구심** — reviewee가 직접 "어떻게 생각하시나요"라고 물어볼 만큼 가시성 전략이 흔들리는 모습. 답은 "캡슐화는 가장 작은 가시성에서 시작".
+- **`getWinners()`가 알고리즘을 직접 풀이** — `cars.maxOf { ... }` + filter 두 단계로 충분한데 절차적 풀이로.
+- **`repeatRacing`과 `runRace`가 외부에 둘 다 노출** — 비슷한 의미의 두 메서드가 공개 인터페이스에 있으면 호출자가 혼란.
+- **테스트가 무엇을 검증하는지 데이터를 안 드러냄** — 자동차들의 위치를 모르고 우승 검증을 하면 의미를 알기 어려움.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 이 라운드에서 두 가지 큰 가이드를 짚었다.
+
+1. **"Constants는 좋지 않습니다"** — 객체지향 캡슐화의 가장 기본은 "가장 작은 가시성에서 시작". 모든 곳이 의존하는 공유 상수 컨테이너는 변경 영향이 큼.
+2. **반환 타입은 도메인 객체로** — `List<List<Car>>` 같은 원시 시그니처는 호출자에게 거부감을 준다. `RaceResult` 같은 클래스로 의미를 부여.
+
+또한 알고리즘이 풀이로 나타나는 부분에 대해 **"maxOf + filter 두 단계로 충분"** 처럼 의도가 드러나는 함수형 구성을 제시.
+
+- **대표 인용:**
+  > Constants 만들어서 사용하는 방법은 좋지 않습니다. ... 객체지향 프로그래밍에서의 가장 기본적인 캡슐화 전략은, 가시성을 제일 작은 곳에서부터 시작하는 것입니다.
+  >
+  > — @laco-dev on `src/main/kotlin/view/OutputView.kt:21`
+
+  > `List<List<Car>>` 라는 반환 타입을 보면 아무래도 거부감이 들지 않을까요? 클래스를 만드는 습관을 가져보면 어떨까요?
+  >
+  > — @laco-dev on `src/main/kotlin/model/RacingGame.kt`
+
+  > 따옴표를 기준으로 자동차 이름이 구분된다는 것은 UI 로직입니다. 만약 따옴표가 아닌 개행으로 바뀌면 도메인 모델이 수정되어야 합니다.
+  >
+  > — @laco-dev on `src/main/kotlin/model/CarCreator.kt`
+
+## 얻은 교훈
+
+- **공유 상수 컨테이너는 결합도의 흑막.** 100개 기능에서 모두 의존하면 한 곳 변경이 전체에 영향. 캡슐화 원칙대로 "한 곳에서만 쓰면 private, 두세 곳이면 그 도메인의 companion"로.
+- **반환 타입이 곧 의도.** `List<List<X>>`가 보이면 거의 항상 도메인 모델 누락의 신호. 그 의미를 가진 클래스를 만들면 호출자가 안심한다.
+- **UI 형식의 결정은 UI 경계에서.** 도메인이 따옴표 split을 알면 형식이 바뀔 때마다 도메인이 흔들린다. 형식 해석은 입력 경계에서.
+- **공개 API의 일관성.** `runRace`와 `repeatRacing`이 모두 public이면 호출자가 어떤 걸 써야 하는지 모른다. 한 가지 인터페이스로 명확하게.
+- **점진적 학습이 명확히 드러난 PR.** 1단계의 큰 비대함을 리팩토링으로 정리했고, copy() 남용 → `CarState` 도입처럼 한 가지 통증의 더 깊은 해결로 나아감.

package/lessons/woowacourse-racingcar/giovannijunseokim/140-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 #140 — [자동차 경주 구현] 지오 미션 제출합니다
+
+- **Reviewee:** [@giovannijunseokim](https://github.com/giovannijunseokim)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/140
+- **단계:** 1단계 (단일 PR)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 33
+
+## 잘한 점 (설계 관점)
+
+- **README에 설계 정리** — 리뷰어 칭찬.
+- **`Car`에 `initialDistance` 생성자 주입** — 테스트 결정성 확보 (학생이 자기 의문도 표명).
+- **팩토리 함수 도입** — `checkCarNameValid`가 외부에서 호출되지 않을 위험을 인지하고 팩토리로 검증 강제.
+- **자기 결정의 회고** — String + 연산 성능 확인, equals/hashCode 도입 이유 등.
+
+## 못한 점 (설계 관점)
+
+- **`ApplicationTest`에 모든 테스트** — 100개 기능이면? 객체별 분리 필요.
+- **`Car`에 hashCode/equals 구현** — 도메인적 필요가 아니라 테스트 위함.
+- **`Car("긴긴이름", 5)`가 통과 가능** — invariants가 별도 함수에 있어 우회 가능.
+- **`Racecourse`가 라운드 진행 출력까지** — 도메인이 View 책임 가짐.
+- **랜덤 테스트의 우회** — "4 이상이면 움직일 수 있다"가 아니라 "4 이상이면 한 칸 전진"으로 명세화 필요.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **"확장성을 고려한 코드는 무조건 잘못된 게 아니다"** 라는 메타 가이드. `initialDistance`가 요구사항에 없어도 테스트와 유지보수에 도움이 되면 OK.
+
+또한 **"하나의 큰 기능 → 여러 작은 기능"** 분해 가이드: "자동차 경주 = 모든 것 한 덩어리"가 아니라 "가장 멀리 전진한 자동차가 우승자", "랜덤으로 움직임" 같은 작은 단위로.
+
+**`100개 기능이면?`** 시뮬레이션으로 ApplicationTest 한 파일의 안티패턴 시각화.
+
+**`Car("...", 5)`** 코드 예시로 invariants 우회 가능성을 즉시 보여줌. 학생이 팩토리 함수로 해결.
+
+- **대표 인용:**
+  > 현재 요구사항과 일치하지 않는다면 무조건 잘못된 구현은 아닙니다. ... 확장성을 고려하여 개발하는 것이 중요합니다.
+  >
+  > — @laco-dev on `src/test/kotlin/ApplicationTest.kt`
+
+  > 하나의 큰 기능을, 여러개의 작은 기능으로 나눠서 생각한다면 그 기능을 구현하는 객체와 테스트를 작성할 수 있지 않을까요?
+  >
+  > — @laco-dev on `src/test/kotlin/ApplicationTest.kt`
+
+  > 자동차의 이름은 5자를 초과할 수 없다는 것은 자동차의 기능일까요? 아니면 checkCarNameValid() 함수의 기능일까요? 이렇게 만든 코드는 논리적으로 정상적인 코드인지 궁금합니다~ ```val car = Car("긴긴이름", 5)```
+  >
+  > — @laco-dev on `src/test/kotlin/ApplicationTest.kt`
+
+## 얻은 교훈
+
+- **요구사항 외 확장 = 무조건 잘못이 아니다.** 유지보수와 테스트에 도움이 되면 확장성 고려는 OK. "요구사항만 정확히"라는 강박은 학습을 저해.
+- **큰 기능 → 작은 기능 분해.** "자동차 경주"가 통째로 하나의 테스트가 아니라 "가장 멀리 전진한 자동차 = 우승"이 한 단위, "4 이상 = 전진"이 한 단위. 작은 단위로 분해해야 검증 가능.
+- **팩토리 함수로 invariants 강제.** 생성자가 public이고 외부 함수가 검증하면 우회 가능. 팩토리 함수에 검증을 넣으면 그 함수를 통한 생성이 유일한 경로 (생성자 private + factory).
+- **`Car`에 hashCode/equals 구현 이유 = 도메인 의미가 있을 때.** 단지 테스트 비교를 위해서라면 다른 방법(필드 단위 비교) 필요.
+- **라운드 진행 출력 = View 책임.** `Racecourse`가 출력하면 도메인 변경이 출력 변경으로, 그 반대도 마찬가지. 분리.
+- **시뮬레이션 예시 코드의 가치.** `Car("긴긴이름", 5)`이라는 한 줄이 invariants 우회 가능성을 즉시 보여줌. 추상 설명보다 강력.

package/lessons/woowacourse-racingcar/haeum808/101-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,55 @@
+# PR #101 — [자동차 경주 구현] 해음 미션 제출합니다
+
+- **Reviewee:** [@haeum808](https://github.com/haeum808)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/101
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 45
+
+## 잘한 점 (설계 관점)
+
+- **`CommaSeparatedListBuilder` 분리** — 문자열 파싱을 별도 책임으로 빼내려는 시도. (리뷰 후엔 파라미터 이름이 `carNames`일 필요가 없을 만큼 일반화됨)
+- **OutputView / InputView 분리** — 입력과 출력의 책임을 의식적으로 나눔.
+- **`private setter` 활용** — `Car.position` 같은 상태를 외부 변경 불가로 관리.
+- **자기 의문을 PR description에 명시** — "Controller가 여러개여도 괜찮은지", "모든 매직 리터럴을 상수화" 같은 메타 질문을 적극 제기해 토론을 끌어옴.
+
+## 못한 점 (설계 관점)
+
+- **`ExceptionHandling` / `FinalWinner` / `MoveOrStay`라는 "역할 없는 절차 클래스" 남발** — "기능을 클래스로 빼야 한다"는 강박이 만들어낸 결과물. 자신만의 상태나 역할이 없는 함수 같은 클래스.
+- **`Run`이라는 Application 시작 클래스 이름** — `run()` 메서드만 가진 무정형 진입점. 자동차 경주의 의미를 담지 못함.
+- **`Messages` / `Ranges` / `Settings` 같은 정적 상수 컨테이너 클래스** — UI 관심사(메시지)와 도메인 설정이 한 클래스에 모임. 결국 모든 사용처가 이 컨테이너에 의존.
+- **`Car`가 자기 이름 규칙(영어/한글)을 안 지킴** — Car("12345"), Car("!@#$") 모두 통과. 도메인 객체가 invariants를 안 가짐.
+- **Controller가 비대 — "모든 객체의 책임"을 한 곳에서 다 함** — 새 클래스를 만들고도 실질은 함수 추출로 끝남.
+- **`Car.position`이 `var`** — 외부에서 직접 수정 가능. private setter 권고.
+- **OutputView가 입력 안내 메시지까지 출력** — 입력 안내 = Input의 일이라는 관점 분리 누락 (콘솔에 묶여 사고).
+- **테스트 이름이 동작 의미를 안 드러냄** — "최종 우승자가 누구냐"의 기준이 테스트만 보고 추측 안 됨.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 가장 강력하게 **"역할 없는 클래스를 만들지 말 것"** 을 짚었다. `ExceptionHandling`을 두고 "이 객체를 지우고 모든 요구사항이 유지되도록 만들면 됩니다"라는 식의 강한 가이드. `FinalWinner`도 "함수가 맞을지 클래스가 맞을지" 묻고, `Cars.findWinners()` 형태를 직접 제시.
+
+또한 **"비대한 Controller의 정공 해법은 함수 추출"** 이라는 매우 실용적인 가이드. 새 클래스를 만들기 전에, Controller 내부에서 의미 단위로 private 함수로 묶기만 해도 가독성이 크게 올라간다는 점.
+
+키오스크 비유로 **"콘솔에 결합된 사고"를 깨는** 가이드도 인상적: "Input = 입력을 받는, Output = 결과를 발행하는"으로 추상하면 입력 안내 메시지를 표시하는 일조차 Input 쪽이 가져갈 수 있다.
+
+- **대표 인용:**
+  > 이 객체를 지우고 모든 요구사항이 유지되도록 만들면 됩니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/controller/ExceptionHandling.kt`
+
+  > 비대한 코드를 줄이는 가장 기본적인 방법은 함수를 사용하는 것입니다 ... 새 클래스를 만들고 잘못 분리가 되었습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/controller/Run.kt`
+
+  > 클래스(객체)는 어떠한 역할을 수행하고 상태를 가질 수 있는 녀석입니다. FinalWinner라는 객체는 무슨 역할을 하는 것일까요?
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/controller/FinalWinner.kt`
+
+## 얻은 교훈
+
+- **"클래스 분리"는 항상 답이 아니다.** 자신만의 상태나 행위 없는 클래스는 사실 함수다. `ExceptionHandling`, `FinalWinner`, `MoveOrStay` 같은 절차적 명사는 함수로 충분하다. 클래스는 역할과 상태를 함께 들 때 가치.
+- **비대한 Controller의 첫 해법은 새 클래스가 아니라 함수 추출.** 의미 단위로 private fun을 만들기만 해도 `run() { getCars(); race(cars); printResult(cars) }`처럼 흐름이 한눈에 들어온다. 이렇게 정리된 뒤에야 진짜 객체 후보가 보인다.
+- **도메인 invariants는 도메인 객체가 들고 있어야 한다.** `Car("12345")`가 통과되는 코드는 외부 검증을 통과한 척하지만 객체 자체가 무방비. 규칙은 그 규칙의 주인이 들어야 한다.
+- **상수 컨테이너 클래스는 분산된 응집을 만든다.** `Messages`, `Settings`처럼 모든 곳이 의존하는 정적 컨테이너는 자기 도메인 위치를 잃은 데이터. 그 데이터를 쓰는 곳이 한 곳이면 그 도메인의 companion으로, 여러 곳이면 그 도메인을 가진 객체로.
+- **클래스 키워드(data, enum, abstract)는 결정 변수가 아니다.** "data class라서 DTO다"는 사고는 본말이 전도된 것. 호출자에게 `Car`는 그냥 `Car`다. 키워드는 표현 수단일 뿐.
+- **입력/출력의 정의는 콘솔이 아니라 의도.** "Input = 입력을 받는 책임"으로 추상하면 입력 안내 메시지도 Input의 일. 키오스크/안드로이드/콘솔이 다르더라도 추상 위에서는 같은 책임 분할.

package/lessons/woowacourse-racingcar/haeum808/129-/353/246/254/355/214/251/355/204/260/353/247/201.md

@@ -0,0 +1,46 @@
+# PR #129 — [자동차 경주 리팩터링] 해음 미션 제출합니다
+
+- **Reviewee:** [@haeum808](https://github.com/haeum808)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/129
+- **단계:** 리팩터링 (별도 라운드)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 10
+
+## 잘한 점 (설계 관점)
+
+- **`RacingCars`로 도메인 컬렉션 일급화** — 1단계의 절차 클래스 정리를 받아 일급 컬렉션으로 책임 흡수.
+- **순수 함수에 대한 자기 학습 의지** — `RacingCars`의 의존을 어떻게 줄일지 PR description에서 직접 고민.
+- **테스트에서 랜덤 자체를 테스트하지 않기로 결정** — "통제 못하는 영역은 단위 테스트가 아니다"라는 학습 흡수.
+
+## 못한 점 (설계 관점)
+
+- **고차 함수(람다)로 의도가 흐릿해지는 추상화** — 함수형 표현을 쓰면서 도메인 의도가 이름으로 드러나지 않게 됨. 인터페이스가 의도 이름을 가지는 자리.
+- **`middleResults`처럼 함수 이름과 중복된 파라미터 명명** — 함수 이름이 이미 "중간 결과"를 말하는데 인자도 `middleResults`. 이름의 정보 가치가 낮아짐.
+- **`RandomNumberGenerator`의 단위 테스트** — 통제 불가능한 출력에 단언을 거는 테스트. 단위 테스트가 외부 무작위 위에 서면 결정적이지 않음.
+- **`Position`을 표현하는 타입이 여전히 부족** — 1단계에서 받은 원시 강박 피드백이 부분만 반영.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 두 가지 메타 가이드를 짚었다.
+
+1. **"람다보다 인터페이스로 의도를 드러내라"** — 함수형 시그니처는 호출자가 의도 이름을 잃게 만듦. 객체지향 학습 단계에서는 이름 있는 추상이 더 유익.
+2. **"테스트할 수 있는 것과 없는 것의 구별"** — 랜덤 자체는 단위 테스트의 대상이 아님. 통제 가능한 동작에만 단언을 건다.
+
+또한 **순수 함수 키워드를 명시적으로 제안** — 상태와 동적 변경을 줄이면 테스트와 상태 관리가 쉬워진다는 가이드.
+
+- **대표 인용:**
+  > 고차 함수를 적용하는 방법도 좋지만 객체지향 프로그래밍을 공부하는 과정에서는 가급적 인터페이스를 사용하도록 해보시면 좋겠습니다. 람다로 사용하게 되면 해당 동작이 어떤 의도를 가지는지 이름으로 드러내기가 어려워 집니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/model/RacingCars.kt`
+
+  > 랜덤기능 자체를 테스트 하는 것은 단위 테스트에 적절하지 않습니다. 실제 반환하는 결과가 0부터 9 사이에 있을 것이라는 것을 신뢰 할 수 없고, 100번을 돌려도 안나올 수도 있다는 의미가 됩니다.
+  >
+  > — @laco-dev on `src/test/kotlin/racingcar/model/RandomNumberGeneratorTest.kt`
+
+## 얻은 교훈
+
+- **추상은 이름을 갖는다.** `(Int) -> Boolean` 같은 람다 시그니처는 강력하지만, 그 추상이 무엇인지 호출자가 이해하려면 사용처를 봐야 한다. 인터페이스로 이름을 주면 그 자체가 문서가 된다 — 객체지향 학습 단계에서 특히 유효.
+- **단위 테스트의 대상은 결정적 행동.** 무작위 자체는 단위 테스트 밖. 무작위가 영향을 주는 도메인 행동은 페이크/스텁으로 무작위를 통제한 뒤 테스트.
+- **순수 함수성과 클래스 책임은 한 방향에서 만난다.** 클래스가 가능한 한 상태를 가지지 않으면 테스트가 결정적이 된다. 객체지향과 함수형이 만나는 자리.
+- **이름의 정보량은 호출자가 새로 알게 되는 것에 비례한다.** 함수가 "중간 결과를 출력한다"고 말하는데 인자 이름이 `middleResults`라면, 호출자가 새로 알게 되는 게 없다. `cars` 같이 다른 차원의 정보를 담은 이름이 더 가치 있다.
+- **점진적 반영도 학습이다.** 1단계의 피드백을 다 받아내지 못해도, 핵심 한두 개를 깊게 이해하고 적용하는 편이 흘려보내는 것보다 훨씬 가치 있다 — 이 PR의 학습 곡선이 그런 흐름.

package/lessons/woowacourse-racingcar/hwannow/141-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,56 @@
+# PR #141 — [자동차 경주 구현] 환노 미션 제출합니다
+
+- **Reviewee:** [@hwannow](https://github.com/hwannow)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/141
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 39
+
+## 잘한 점 (설계 관점)
+
+- **에러 메시지를 상수화** — 오타/유지보수 측면 고려한 좋은 답변. 리뷰어가 명시적 칭찬.
+- **테스트 코드를 깔끔하게 작성** — given/when/then 의식적 분리.
+- **자기 의문을 PR description에 적극 제기** — "Main에서 InOutController를 거쳐 InOutView를 호출하는 게 맞는가" 같은 메타 질문.
+- **`Mutable` → `List` 적극 반영** — 습관적으로 쓰던 Mutable을 한 번에 정리.
+
+## 못한 점 (설계 관점)
+
+- **`InOutController`라는 합쳐진 책임** — 입력과 출력을 한 컨트롤러가 다룸. 의도는 단순화지만 분리 동기가 약해짐.
+- **`enum class InOutConstant`로 상수 wrap + `getData()` 함수** — 단순 const value로 가능한데 enum + getter 2단 depth로 복잡화. 같은 결과를 두 가지 방식(`InOutConstant.NAME.constant` vs `inOutView.getData(InOutConstant.NAME)`)으로 얻을 수 있어 일관성 부족.
+- **Controller가 View를 직접 알고 있음** — RacingCar/BlueCar/RedCar처럼 View 변형이 생기면 Controller마다 추가해야 하는 결합 구조.
+- **`RaceController.oneRace`처럼 추상적 이름** — `runRace`/`executeRound`처럼 도메인 동작 어휘로 개선 여지.
+- **`MainController`라는 무정형 이름** — 담당 책임이 이름에 안 드러남.
+- **`RaceController.ViewController`라는 비대한 의존** — RaceController가 ViewController를 생성자로 받음. 도메인 계산 책임자와 표시 책임자의 결합.
+- **`ViewController`가 자동차 객체를 생성** — 비유로 "홀 담당자가 재료까지 준비해서 요리사한테 준다"는 어색함.
+- **테스트가 `cars: MutableList<Car>` 멤버를 통해 동작** — 개별 시나리오에 맞는 자동차 위치 표현이 어려움.
+- **상수가 일부만 상수화** — `name.length <= 5`처럼 도메인 매직 넘버가 인라인.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag는 **음식점 비유**(홀 담당자/요리사/재료)로 책임 분리를 시각화. ViewController가 자동차를 만드는 것은 "홀 담당자가 재료를 준비"하는 어색함이라는 비판.
+
+또한 enum의 과잉 사용에 대한 명확한 비교 — 같은 결과를 두 가지 방식으로 접근 가능한 코드는 호출자에게 혼란을 준다는 가이드.
+
+Controller가 View를 직접 아는 결합에 대해 **인터페이스를 통한 재사용** 방향을 힌트로 제시 — 단, "지금 미션에 적용하기엔 오버엔지니어링"이라는 균형 잡힌 가이드도 함께.
+
+- **대표 인용:**
+  > Controller 에서 View를 알게되면 어떤 점이 안좋게 될까요? ... RacingCar, BlueCar, RedCar 등 View에서 조금씩 출력하는 내용이 다르게 되면 모든 객체마다 Controller를 만들어야 하게 되지 않을까 싶네요
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/controller/InOutController.kt`
+
+  > ViewController : 입/출력을 담당하니 가계의 홀 담당자 / RaceController : 입력 받은 내용을 가지고 요리를 하는 요리사 / Car 객체 : 요리를 하기 위한 재료 ... `홀 담당자가 재료까지 준비해서 요리사 한테 준다?` 같은 느낌이라서요!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/controller/ViewController.kt`
+
+  > getData()를 통해서만 InOutConstant를 추출하고 싶었다면, InOutConstant에 대한 접근을 제한하는 방식으로 되어야 했을텐데, 아래와 같이 사용이 2가지 방식으로 되면서 같은 결과를 내지만 사용방법이 2가지나 되는군요..
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/view/InOutView.kt`
+
+## 얻은 교훈
+
+- **추상화는 사용 비용을 줄이는 방향이어야 한다.** enum + getter로 상수를 감싸면 단순 const일 때보다 사용 depth가 늘고 사용법이 다양해진다. 추상은 단순화의 도구.
+- **Controller가 View를 직접 알면 변형마다 새 Controller가 필요해진다.** 인터페이스를 통해 View의 변형을 흡수하면 Controller가 재사용 가능. 단, **YAGNI** — 변형 가능성이 실재할 때 도입.
+- **현실 비유는 책임의 어색함을 빠르게 드러낸다.** "홀 담당자가 재료를 준비?" 같은 비유 한 줄이 ViewController의 책임 누수를 즉시 보여준다.
+- **단일 결과를 얻는 두 가지 경로 = API 부담.** 같은 데이터에 도달하는 길이 두 가지면 호출자가 선택을 강요받고, 일관성을 잃는다. 한 가지 경로로 통일.
+- **테스트 픽스처는 시나리오에 맞춰 만들어야** — 멤버 변수의 `cars`로 모든 케이스를 표현하려 하면 개별 시나리오의 입력이 모호해진다. 각 테스트가 자기 데이터를 빌드하는 편이 명확.
+- **오버엔지니어링의 균형 가이드** — 리뷰어가 "이 패턴은 미래를 위한 학습 포인트일 뿐 지금 적용은 과하다"고 짚는 것은 매우 가치 있다. 좋은 리뷰어는 도구와 시점 모두를 짚어준다.

package/lessons/woowacourse-racingcar/hwannow/157-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,45 @@
+# PR #157 — [자동차 경주 2단계] 환노 미션 제출합니다
+
+- **Reviewee:** [@hwannow](https://github.com/hwannow)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/157
+- **단계:** 2단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **`Message` → `RacingGameOutputConstant` 네이밍 개선** — 클래스가 무엇을 담당하는지 이름으로 명확.
+- **`RoundResult`로 책임 분리** — 1단계의 비대한 Controller에서 라운드 결과 책임을 떼냄.
+- **`RandomGenerator` 인터페이스 도입** — 무작위 의존을 추상으로.
+- **"전진할지 말지의 판단 책임이 어디 있나"를 깊이 고민** — Car에서 RoundResult로 옮긴 자기 결정 과정을 자기 언어로 정리.
+
+## 못한 점 (설계 관점)
+
+- **테스트를 위해 메서드 가시성을 public으로 노출** — `RoundResult`의 메서드를 외부에서 호출 가능하게 둔 것이 테스트 목적. "테스트 코드를 위한 코드"의 신호.
+- **`Car.moveCar(random: Random)` 시그니처** — Car가 Random 자체를 알고 있어 결합도 증가. `Car.move()`로 단순화하고 의사결정을 외부로 옮기는 방향이 더 자연스러움.
+- **`RoundResult`라는 모호한 이름** — "라운드의 결과를 담는 객체"인지 "라운드의 진행을 담당하는 객체"인지 이름에서 안 드러남. RaceRule, Game 등 도메인 어휘 후보 있음.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag는 **"의사결정의 자리"** 를 정밀하게 물었다. Car가 Random을 직접 받는 것보다 `availableMove(random: Int): Boolean` 같은 인터페이스로 외부에서 결정 입력을 받게 한 뒤, Car는 단지 `moveCar()` 하는 식. 이 분리가 테스트 가능성과 책임의 깔끔함을 동시에 만든다.
+
+또한 **이름이 마지막 학습 영역** — `RoundResult`라는 이름의 어색함을 짚고, "어려운 네이밍"이라는 메타 코멘트와 함께 후보를 함께 던짐.
+
+자기 결정의 회고를 reviewee가 길게 적은 것에 대해 **"환노의 의견이 좋다"** 고 명시적으로 인정 — 좋은 학습 사이클.
+
+- **대표 인용:**
+  > moveCar 에 `random : Random` 이 부분을 없애고 싶었습니다 ... // 예시: fun availableMove(random: Int): Boolean { return random >= FORWARD_NUMBER }
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/domain/RoundResult.kt:22`
+
+  > 우선 테스트를 위해 Car 객체와 Random을 분리시켜야겠다는 생각을 했습니다 ... 전진할지 말지를 **판단하는 건 심판의 역할**이고, 사실상 Car는 숫자가 랜덤한 값인지, 어떤 기준으로 전진하는지 몰라도 된다!
+  >
+  > — @hwannow on `src/main/kotlin/domain/RoundResult.kt:22` (자기 결정 회고)
+
+## 얻은 교훈
+
+- **결정과 실행을 분리한다.** Car가 "전진할지 말지"를 결정하면 Random과 결합. 결정은 별도의 판단자(심판/규칙)에게 두고 Car는 `move()`만 수행하는 분리 — 테스트 가능성과 책임 분배를 동시에 해결.
+- **테스트를 위한 코드는 안티패턴.** 테스트하려고 가시성을 풀거나 인터페이스를 확장하면, production 표면적이 테스트 의도로 오염된다. 테스트가 어려운 곳은 책임 재분배의 신호.
+- **자기 결정의 회고가 학습이다.** 단순 "리뷰 따라 고쳤습니다"가 아니라 "왜 그렇게 고쳤는지" 자기 언어로 적는 응답이 가장 깊은 학습. 리뷰어도 이런 응답에 가장 명확한 피드백을 준다.
+- **단위가 시그니처에 새는지 확인.** `move(random: Random)`은 Car가 random의 구체 표현을 안다는 신호. `move(steps: Int)` 또는 `move()`로 단순화하면 의존이 사라진다.
+- **이름 후보 N개로 비교** — RoundResult / RaceRule / Game 등 후보를 비교해보면 가장 정합하는 이름이 자연스럽게 떠오른다. 한 이름에 집착하지 말고 N안을 그려보는 습관.

package/lessons/woowacourse-racingcar/hxeyexn/109-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,61 @@
+# PR #109 — [자동차 경주] 해나 미션 제출합니다
+
+- **Reviewee:** [@hxeyexn](https://github.com/hxeyexn) (해나)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/109
+- **단계:** 1단계
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **README에 요구사항 정리**, 검증 로직 테스트 작성.
+- **명확한 질문을 PR에 첨부** — 출력부 메서드 분리 여부, 검증 위치, depth 줄이는 법.
+
+## 못한 점 (설계 관점)
+
+- **테스트 코드가 통과 안 함** — 리팩토링 후 에러 메시지 변경했는데 테스트 코드 미반영.
+- **`getNames()` 메서드가 4가지 일** — 입력 받기, split, 검증, Car 생성.
+- **try-catch + while + break의 깊은 depth** — 메서드 분리 못 함.
+- **`Race`(Controller)가 너무 많은 비즈니스 로직 보유** — 학생이 자가 인식.
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong (파이로)의 명문장 메시지들:
+
+1. **Depth = abstraction level** — "depth를 indentation으로 설명하지만 엄밀히는 abstraction level. SOLID의 SRP는 한 함수가 abstraction level 2를 넘지 않게 추상화하라는 의미도 있음." 재귀로 indentation을 줄이지 말고, *함수 쪼개기*로 abstraction level을 줄여라.
+
+2. **"휴가를 가도 동료가 일할 수 있는 코드"** — 동료에게 함수명 + 입력 타입 + 반환 타입만 알려주면 동일 기능을 구현할 수 있어야 함. 그렇지 않으면 휴가 중 동료가 전화. **개발 조직의 야근 괴담은 역할·책임이 명확하지 않은 함수에서 생긴다.**
+
+3. **메서드 세분화의 학습법** — "최대한도로 세분화하라. 그 후 합치는 리팩토링은 쪼개는 리팩토링보다 *쉽다*. 너무 세분화한 경험이 본인의 합치는 기준을 만든다."
+
+4. **DisplayName 어노테이션** — 한국인 동료와 협업 가정하고 테스트 설명을 자세히.
+
+5. **단순한 명령형 메서드 명명** — 메서드는 동사로 (`generate()` not `randomNumber`). 메서드 = 행위.
+
+6. **테스트가 깨진 상태로 리뷰 요청** — 리팩토링 후 실행 안 함. 검증 위생.
+
+- **대표 인용:**
+  > depth 를 이야기할 때, 쉬운 설명을 위해서 indentation 을 이야기하지만, 엄밀히 이야기하면 abstraction level 을 뜻합니다. SOLID 원칙 중 Single Responsibility 원칙은 한 함수가 하나의 목적을 위해 동작하기를 권장하는데, 이는 abstraction level 이 2가 넘지 않도록 한 함수내의 로직을 추상화 하라는 의미도 있습니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/controller/Race.kt`
+
+  > 조직에서 함께 일할 때 중요한 점은, 내가 마음 편하게 휴가를 가더라도, 동료에게 자신의 일을 믿고 맡길 수 있어야 한다는 점입니다... 업계에 떠도는 맨날 야근하는 개발 조직 괴담이 역할과 책임이 명확하지 않은 함수, 클래스, 혹은 모듈로 인해서 생긴다고 생각해주세요.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/controller/Race.kt`
+
+  > 처음에 최대한도로 세분화하라는 조언은, 보통 합쳐진것을 쪼개는 리팩토링 보다, 쪼개진 것을 합치는 리팩토링이 더 쉽기 때문입니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/controller/Race.kt`
+
+  > 잘 쪼개진 함수는 동료가 스킵해서 읽을 수 있는 것처럼, 잘 쪼개진 클래스 또한 동료가 스킵해서 읽을 수 있습니다. 저는 보통 클래스에 IDE 에서 점을 찍으면 자동완성으로 보이는, public 메서드만 읽고 해당 클래스 코드를 읽는 것을 스킵하고는 합니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/controller/Race.kt:109`
+
+## 얻은 교훈
+
+- **Depth는 abstraction level이지 indentation이 아니다.** 재귀로 indentation을 줄여도 abstraction level이 그대로면 SRP는 깨진 채. 함수를 쪼개라.
+- **"휴가 가능한 코드" 기준**. 함수명 + 시그니처만 보고 동료가 같은 일을 할 수 있는지가 SRP 검사법. 휴가 중 전화 오면 추상화 실패.
+- **세분화 학습법: 최대한도 쪼개고 합치기**. 합치는 리팩토링이 쪼개는 것보다 쉬움. 너무 쪼갠 경험이 내가 합칠 기준을 만듦. 거꾸로는 안 된다.
+- **잘 쪼개진 클래스 = public method만 읽고 내부 스킵 가능**. 외부 라이브러리를 쓸 때 우리가 그렇게 함. 우리 코드도 동료가 그러길.
+- **리팩토링 후 테스트 실행 = 위생.** 메시지 하나만 바꿔도 테스트 깨질 수 있음. 리뷰 요청 전 `gradlew test` 한 번.
+- **테스트 함수명은 *시나리오 + 결과* 한 문장**. 동사로, 도메인 어휘로.

package/lessons/woowacourse-racingcar/hxeyexn/128-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,59 @@
+# PR #128 — [자동차 경주 - 리팩토링] 해나 미션 제출합니다
+
+- **Reviewee:** [@hxeyexn](https://github.com/hxeyexn)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/128
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **`Cars`, `Winner`, `RandomNumber` 클래스 분리** — 1단계 함수 쪼개기 → 2단계 클래스 쪼개기.
+- **`Cars`에 이름 유효성 검증 담당** — 도메인 객체로 invariant 이동.
+- **getNames, getRoundNumber 메서드를 직관적 단위로 쪼갬**.
+- **테스트 분리** — model 별 단위 테스트.
+
+## 못한 점 (설계 관점)
+
+- **`Race`(Controller)가 names 리스트를 또 보유** — Cars가 이미 가지고 있는데 중복. 데이터 동기화 부담.
+- **`Winner` 클래스가 멤버 없음 + judge 함수만 보유** — 사실상 유틸 함수. 객체로서 가치 부재.
+- **`getCars()`가 리스트 반환하지만 호출 측에서 안 씀** — 메서드 이름과 실제 행위 불일치.
+- **`RandomNumber.generate`가 명사형 (이전 라운드 피드백) 잔존**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong의 핵심 가르침:
+
+1. **"객체는 메서드 + *멤버* 둘 다로 구성"** — Winner가 멤버 없이 함수만 있으면 그건 함수일 뿐 객체가 아님. "Winner의 역할은 우승자 판단, 책임은 우승자 반환"이라는 학생의 답에서 *역할 ≈ 함수*이면 별도 클래스 분리 불필요.
+
+2. **"테스트하기 쉬운가?"가 객체 분리 기준** — Winner를 분리해서 테스트하나, Cars 안에서 getWinners를 테스트하나 *난이도 같음*. 그러면 분리할 이유 없음. **분리의 정당화는 테스트 개선이 와야 함.**
+
+3. **데이터 중복 보유의 신호** — Cars와 Race가 모두 names를 들고 있음. 한 곳에서 진실의 출처를 두기.
+
+4. **메서드 이름 = 실제 행위와 일치** — `getCars()`가 리스트를 반환하지만 호출 측에서 안 쓰면 이름과 의미 어긋남.
+
+5. **랜덤은 전략 패턴으로 추상화** — 통제 어려운 외부 라이브러리는 전략 패턴으로 갈아끼움 가능.
+
+6. **상수는 *역할*로 명명** — `","` 보다 `NAME_DELIMITER` — 요구사항 변경 시 (특수기호로) 같은 이름으로 작동.
+
+- **대표 인용:**
+  > Winner 클래스는 그 어떤 멤버도 갖고 있지 않고, judge 함수만을 유틸처럼 제공하고 있습니다... 만약 judge 라는 함수가 곧 클래스의 역할이라면, 별도 클래스로 분리할 필요가 없지 않았을까 해서 의견을 남겨보았습니다. 객체는 메서드 뿐만 아니라 맴버로도 구성된다는 사실을 잊지 말아주세요.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/model/Winner.kt:13`
+
+  > 제가 객체를 쪼개고 합치는 기준을 오직 "테스트 하기 쉬운가?" 로 한다고 말씀드렸는데, 이 경우가 그런 경우 같습니다... 바뀐 테스트가 작성하거나 더 읽기 쉬워보이지 않기에 저는 이런 경우라면 Winner 라는 클래스를 분리하는 것에 대해, 왜 굳이 분리해야할지 의문을 표할 것 같습니다.
+  >
+  > — @ghojeong on `src/test/kotlin/racingcar/WinnerTest.kt:40`
+
+  > Cars 에서 이미 names 리스트를 맴버로 가지고 있는데, Race 에서 다시 names 리스트를 가지고 있도록 하신 의도가 궁금합니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/controller/Race.kt:14`
+
+## 얻은 교훈
+
+- **클래스 분리의 정당화 = 테스트 개선**. 분리해도 테스트가 더 명확해지지 않으면 분리할 이유 없음. "객체로 만들면 OOP 같다"는 가짜 정당화.
+- **"객체 = 메서드 + 멤버 둘 다"**. 멤버 없이 함수만 가진 클래스는 함수일 뿐. judge 함수만 있는 Winner는 그냥 `findWinner(cars: Cars)` 함수로 충분 — 혹은 `Cars.findWinner()`로 일급 컬렉션에 통합.
+- **데이터 동기화는 *진실의 출처* 한 곳**. Cars와 Race가 names를 모두 가지면 한쪽 변경 시 다른 쪽 어긋남. Cars가 가지고 Race는 Cars 자체를 들기.
+- **메서드 이름 = 외부에서 본 행위**. `getCars()`인데 반환값 안 쓰이면 이름이 거짓말. `setupCars()` 같은 이름이 진실. (또는 별도 책임으로 분리.)
+- **상수는 *의미*로 명명**. `","` → `NAME_DELIMITER`. 요구사항 바뀌면 값만 갈아끼우면 끝, 호출처는 그대로.
+- **점진적 학습 곡선의 시그니처**: 1단계 = 함수 쪼개기, 2단계 = 클래스 쪼개기, 그 다음 = "왜 굳이 분리?"의 정당화 묻기. 깊이가 점점 올라감.