oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/kimhm0728/100-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,52 @@
+# PR #100 — [자동차 경주 구현] 올리브 미션 제출합니다
+
+- **Reviewee:** [@kimhm0728](https://github.com/kimhm0728)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/100
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 17
+
+## 잘한 점 (설계 관점)
+
+- **자기 결정 기준의 명확한 표현** — object/class 구분("상태 유무"), model/service 패키지 구분 ("데이터 저장 vs 비즈니스 로직 주목적") 등 자기 언어로 분류 기준 표명.
+- **`TryCount` 값 객체 도입 시도** — 원시 강박 해소 의지.
+- **자기 의문을 적극 제기** — service 패키지 class 선택 이유, 랜덤 테스트 방법 등에 대해 깊은 토론.
+
+## 못한 점 (설계 관점)
+
+- **`TryCount`가 repeat을 단순 wrapping** — 특별한 비즈니스 로직 없으면 `repeat(count)`이 충분. 학생도 회의.
+- **`processStep` 같은 모호한 함수명** — 처리/실행 같은 일반어. 비대화의 신호.
+- **Controller가 너무 많은 책임** — RandomGenerator + ForwardService를 직접 조합. 도메인이 자기 일을 안 함.
+- **service 패키지가 비즈니스 로직 컨테이너** — 사실상 도메인의 일. model/service 분리가 인위적.
+- **`WinnerService`가 class** — 상태 없음에도 class. object가 더 자연스러움.
+- **랜덤 테스트가 repeat 횟수로 우회** — 100% 보장 불가. 전략 패턴으로 결정성.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95는 **object/class의 진짜 기준 = 생명주기** 라는 명료한 가이드 제시. "상태 없는 class를 object로 선언하면 자연스러운 이유"까지 설명. 학생의 이해에 정확히 답함.
+
+또한 **"process / execute는 모호하다 → 비대화의 신호"** — 일반어 함수명이 책임 식별을 흐리게 만든다는 강한 가이드. 더 나아가 "Controller가 너무 많은 일을 하는지 자문하라"는 메타 가이드.
+
+랜덤 테스트의 본질에 대해 **"자동차 게임의 관심사는 무엇인가?"** 라는 본질 질문 — (1) 자동차가 잘 움직이고 (2) 우승자를 구하는 것. 무작위 자체는 관심사가 아니므로 다른 규칙으로 교체 가능한 구조(전략 패턴).
+
+- **대표 인용:**
+  > process, execute 와 같은 네이밍은 사실상 어떤 내용이 들어가도 크게 이상하지 않습니다. 다르게 얘기하면, 그만큼 모호하고 포괄적이기 때문에 함수의 역할을 이해하기 어렵고 금방 비대해질 수 있다는 신호로 받아들일 수 있습니다.
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/controller/RacingCarController.kt`
+
+  > Controller 자체가 View 와 Model 을 연결하는 일을 할 뿐, Model 이 실제로 어떻게 동작할지는 주 관심사가 아닙니다. 즉, 이러한 비즈니스 로직을 모아서 하나의 Model 혹은 domain 으로 정의해볼 수 도 있겠습니다.
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/controller/RacingCarController.kt`
+
+  > 우리가 자동차 게임에서 관심이 있는 부분은, 랜덤하게 움직이는 것이 아니라 1) 자동차가 잘 움직이고, 2) 이동거리를 바탕으로 우승자를 구하는 것이지 않을까요? 그렇다면, 랜담하게 움직이는 것은 '움직임'에 대한 하나의 규칙이므로, 이러한 규칙을 갈아끼울 수 있다면 어떨까요?
+  >
+  > — @vagabond95 on `src/test/kotlin/racingcar/ServiceTest.kt`
+
+## 얻은 교훈
+
+- **함수명의 모호함 = 비대화의 신호.** `process`, `execute`, `handle`, `run` 같은 동사는 어떤 내용도 담을 수 있어 책임이 무한정 늘어난다. 구체적 동사가 책임을 좁히는 첫 단계.
+- **object vs class = 생명주기.** 프로그램 종료까지 같은 인스턴스가 필요하면 object, 인스턴스마다 다른 상태/의존성이 있으면 class. 상태 없음 + class = 메모리 낭비 + 자연스럽지 않음.
+- **랜덤 테스트의 본질적 한계.** 결정성을 확보하려면 전략 패턴 — 무작위 규칙을 외부에서 교체 가능하게. "1000번 돌리면 통과"는 통계적 보증일 뿐 단위 테스트가 아님.
+- **TryCount의 trade-off:** (1) `repeat(count)` = 간결, 객체 생성 없음 / (2) `TryCount.forEach { }` = 도메인 의미 캡슐화, 재사용. 정답이 아닌 trade-off 결정. 학생이 양쪽 다 인식한 것이 학습의 정점.
+- **model/service 패키지 분리의 인위성.** "데이터 vs 비즈니스 로직"으로 나누면 결국 도메인이 두 갈래로 흩어진다. 단일 도메인 패키지로도 충분히 표현 가능.
+- **자기 분류 기준 표명의 학습 효과** — 학생이 자기 결정의 기준을 말로 표현하면 그것의 약점이 즉시 드러난다. 리뷰어가 그 기준의 한계를 짚으면 학습이 가속.

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

@@ -0,0 +1,54 @@
+# PR #116 — [자동차 경주 리팩터링] 올리브 미션 제출합니다
+
+- **Reviewee:** [@kimhm0728](https://github.com/kimhm0728)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/116
+- **단계:** 리팩터링 (PR #100의 후속)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **`RacingGame` 도메인 도입으로 비즈니스 로직 캡슐화** — 리뷰어 명시적 칭찬.
+- **`ForwardService` 전략 격리** — "움직임 규칙 바뀌어도 유연" 칭찬.
+- **이전 라운드의 학습을 다음 PR에 일관되게 적용** — service class → object, Controller 비대 → RacingGame.
+- **자기 분류 기준의 명료한 표명** — model vs service 패키지 구분 ("데이터 저장 vs 비즈니스 로직 주목적")까지 자기 언어로 설명.
+
+## 못한 점 (설계 관점)
+
+- **`RacingGame`을 `service`로 분류** — RacingGame은 도메인. service/model 분리가 인위적.
+- **`RacingGame`이 cars만 보고 winners를 직접 찾지 않음** — Controller가 winners를 따로 호출. RacingGame이 가진 데이터로 결과를 만들 수 있는데 책임이 분산.
+- **`RacingGame`이 `forwardNumberGenerator`를 주입받지 않음** — 도메인이 유연해지려면 외부 주입.
+- **랜덤 테스트가 repeat으로 우회** — 100% 보장 부족 (학생도 인정).
+- **Controller가 여전히 model/service 패키지를 광범위 import** — 의존 그래프 좁히기 가능.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95는 학생의 자기 분류 기준에 대해 **"service라는 분류 자체가 의미 있는가"** 라는 본질 질문 — 도메인 객체에 service 라벨을 붙이는 게 정말 명확한가?
+
+또한 **"RacingGame이 cars를 안다면 winners도 RacingGame에서"** 라는 책임 응집 가이드. Controller가 가져야 할 import를 줄이라는 식의 의존 그래프 가이드.
+
+`forwardNumberGenerator` 주입에 대해 **"도메인을 유연하게 다루려면 외부 주입"** 가이드 — 도메인 객체도 의존 주입의 대상.
+
+학생이 "다양한 분류 기준"을 자기 언어로 표명한 것에 대해 리뷰어가 그 기준의 한계까지 짚는 식의 깊은 학습 사이클.
+
+- **대표 인용:**
+  > RacingGame 이 cars 를 알고 있으므로, winners 를 구하는 것도 RacingGame 에서 처리될 수 있지 않을까요? Controller 의 import 에서 최대한 model 혹은 service 패키지를 줄여보면 좋을 것 같아요.
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/controller/RacingCarController.kt`
+
+  > RacingGame 에서도 forwardNumberGenerator 를 주입받을 수 있으면 도메인을 좀 더 유연하게 다룰 수 있을 것 같아요!
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/service/RacingGame.kt`
+
+  > RacingGame 을 service 라고 판단해주신 이유가 있을까요?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/service/RacingGame.kt:1`
+
+## 얻은 교훈
+
+- **"데이터의 주목적 vs 행동의 주목적"으로 패키지를 나누면 인위적 경계 생긴다.** OOP는 데이터와 행동이 한 객체에 모이는 게 정상. 그 둘을 분리한다는 발상이 절차적 사고의 잔재일 수 있음.
+- **데이터 + 행위가 한 객체에 = 응집의 본질.** RacingGame이 cars를 알면 winners도 거기서. 데이터를 가진 자가 그 데이터로 일하는 게 가장 자연스럽다.
+- **Controller의 import 수 = 결합도 척도.** Controller가 너무 많은 모듈을 알면 그 자체가 비대화의 신호. 도메인 객체 하나에 일을 모으면 Controller의 import가 감소.
+- **도메인 객체도 의존성 주입 대상.** "도메인은 의존성 없는 순수 객체"라는 단순화가 모든 경우에 맞는 건 아님. 외부 자원에 의존하는 도메인 행위(난수, 시각 등)는 인터페이스로 주입.
+- **자기 분류 기준의 표명 → 리뷰어가 한계 짚음** 사이클의 가치. "model/service" 같은 단순 분류가 가진 한계를 학생이 표명하면 리뷰어가 그 한계를 보여줄 수 있다.
+- **이전 라운드 학습의 일관 적용.** PR #100에서 받은 가이드(repeat, object class, RacingGame 도입)가 이 PR에서 실제 코드 변경으로 반영됨. 학습이 누적된 흔적.

package/lessons/woowacourse-racingcar/kkosang/105-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 #105 — [자동차 경주 구현] 꼬상 미션 제출합니다
+
+- **Reviewee:** [@kkosang](https://github.com/kkosang)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/105
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 28
+
+## 잘한 점 (설계 관점)
+
+- **PR description에 깊은 메타 질문 정리** — "검증을 입력에서 vs 컨트롤러에서" 등 책임 위치를 적극 질문.
+- **리뷰의 의도를 자기 언어로 정리** — "자동차가 스스로 이동" 학습, "정수가 더 명확하다" 등 자기 표현으로 흡수.
+
+## 못한 점 (설계 관점)
+
+- **`gameController.kt` 파일명 lowercase** — 코틀린 컨벤션 위반.
+- **자동차가 외부에서 이동되는 절차적 구조** — `car.move()`가 아니라 외부가 자동차의 위치를 변경.
+- **`Car("ASDIOSAJDAOIDJAOIDJSAOID")`도 통과** — Car 자기 invariants 미보유.
+- **InputView가 입력 일부, Controller가 다른 입력** — 입력 책임이 두 곳에 흩어짐.
+- **`InputView`가 반환값 없음** — 입력의 결과가 어디로 가는지 모호.
+- **자동차 위치를 "-" 문자열로 표현** — 도메인 상태가 표시 형식으로 표현되어 도메인이 표시를 알게 됨.
+- **단위 테스트 누락** — 자동차 이동 같은 핵심 도메인 검증 미작성.
+- **린트 미준수** — ktlintCheck로 잡히는 표준 컨벤션 위반 다수.
+- **`build.gradle.kts`에 목적 불명 의존성** — "왜 있는지 모름"이라는 본인 답변.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **"객체는 스스로 행동한다"** 와 **"검증의 자리는 그 invariant의 주인 곁"** 두 가지 본질을 강하게 짚었다. slipp 글 링크와 함께 자동차의 자율성을 학습하도록 안내.
+
+또한 **"InputView가 무엇을 반환하는가"** — 함수 시그니처가 책임을 드러내는지 묻는 패턴. 반환 없는 InputView는 입력 책임이 어디로 갔는지 추적이 어려움.
+
+`"-" 문자열 vs 정수` 같은 도메인 상태의 표현 타입 결정도 작은 가이드로 짚음 — 도메인 모델과 표시 모델의 분리.
+
+- **대표 인용:**
+  > 객체는 스스로 행동하는 녀석이라고 배우셨을거에요. 그렇다면 지금 자동차는 스스로 이동하고 있나요? 아니면 남에 의해 이동이 되어지고 있나요?
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/model/racing.kt`
+
+  > Car 라는 객체를 다른곳에서도 사용이 가능할텐데요. 자동차 이름의 유효성을 검사하고 테스트를 하는 것은 어디에 위치해야 할까요?
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/controller/gameController.kt`
+
+  > 자동차의 위치를 표현하는데 있어서 "-" 와 정수값중 무엇이 좋은 타입이 될까요?
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/model/racing.kt`
+
+## 얻은 교훈
+
+- **객체는 스스로 행동한다.** 외부가 객체의 상태를 직접 바꾸는 코드는 절차적 사고의 잔재. `car.move()`로 메시지를 보내고 결과만 받는 게 객체지향다움.
+- **invariants는 invariant의 주인 곁.** "이름 5글자 제한"이 Controller에 있으면 Car는 어떤 이름이든 받는 무방비 객체. invariants가 Car의 init에 있어야.
+- **도메인 상태의 타입은 도메인 의미를 반영한다.** "위치"는 정수가 도메인 모델, "-"는 표시 모델. 도메인 안에 표시 형식이 들어가면 변경이 도메인을 흔든다.
+- **함수 시그니처가 책임을 보여줘야 한다.** `InputView.input(): Unit`은 어디로 결과가 가는지 모름. `InputView.read(): String` 같은 시그니처가 흐름을 드러낸다.
+- **표준 도구를 신뢰하라.** ktlint, ktlintCheck 같은 표준 도구가 잡아주는 일관성은 자기 손으로 짤 일이 아님. 자동 검증 도구는 리뷰의 인지 부하를 크게 낮춤.
+- **"왜 있는지 모르는 의존성/코드" = 즉시 제거 후보.** 빌드 설정에 의도 불명 라이브러리가 있으면 보안/충돌/혼란의 원천. 모르면 빼고, 정말 필요하면 다시 추가하며 의도를 기록.

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

@@ -0,0 +1,53 @@
+# PR #126 — [자동차 경주 리팩터링] 꼬상 미션 제출합니다
+
+- **Reviewee:** [@kkosang](https://github.com/kkosang)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/126
+- **단계:** 리팩터링
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 14
+
+## 잘한 점 (설계 관점)
+
+- **`Validation` object로 검증 로직 분리 시도** — 의도는 명확. 다만 자리 자체가 다음 토론거리.
+- **자기 의문을 깊이 정리** — Util의 정당화, input/output을 object로 할지 등 적극 질문.
+
+## 못한 점 (설계 관점)
+
+- **`util.Validation`이 도메인 invariants를 들고 있음** — 자동차 이름 5글자 제한이 Util에. 도메인 변경이 Util 변경으로 이어짐.
+- **`","` 구분자 처리가 Controller에** — 입력 형식 결정이 Controller로 새어 들어옴. InputView가 `List<String>`을 반환하면 해결.
+- **`inputCarName()`과 `inputTryCnt()` 함수가 서로 다른 구조** — 비슷한 책임인데 일관성 부족.
+- **테스트가 자동차 값을 직접 바꿔 검증** — Racing의 public 메서드 테스트가 누락. 테스트 본질이 production API 검증인데 내부 상태 조작으로 우회.
+- **테스트가 Random에 의존** — 결정적이지 않은 테스트는 단위 테스트가 아님.
+- **public/private의 결정 기준 부재** — 어떤 함수가 진짜 외부 API인지 결정이 흐림.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **"Util이 무엇이고, 무엇이 Util을 결정하는가?"** 라는 근본 질문을 짚었다. "자율적으로 동작하는 것이 객체"라면, 메시지/유효성 검사 등을 외부에서 하는 것은 그 객체의 자율성을 떼어가는 행위. 즉 Util 자체가 객체지향에 안 맞을 가능성.
+
+또한 **"Validation 클래스를 지우고 모든 로직이 기존대로 잘 동작하도록 만들어주세요"** 라는 매우 직접적이고 강한 가이드. "감을 잡기 쉽도록"이라는 표현은 학습의 명확성을 높임.
+
+`InputView`의 책임에 대해서도 명확한 가이드: "," 구분자 결정이 어디에서 일어나는가? 그 결정은 InputView의 일이어야 확장성이 생긴다.
+
+테스트에 대해서는 학생에게 "다른 크루들이 어떻게 하는지 찾아보세요"라는 메타 학습 방향 제시.
+
+- **대표 인용:**
+  > Util이 무엇인가요? 그렇다면 Util을 결정하는 기준은 무엇인가요? 자율적으로 동작하는 것을 객체라고 이야기 하고 있다면, 메시지, 유효성 검사 등을 비롯한 것을 외부에서 하는게 스스로 하는 것이라고 볼 수 있을까요?
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/util/Validation.kt`
+
+  > Validation 클래스를 지우고 모든 로직이 기존대로 잘 동작하도록 만들어주세요
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/util/Validation.kt`
+
+  > 만약 다른 InputView에서는 따옴표가 아닌 개행 문자로 이름이 구분된다면 이 프로그램은 고장나게 됩니다 ... InputView가 분리된 자동차 이름들을 반환하도록 하는게 더욱 확장성 있는 구조가 되지 않을까요?
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+## 얻은 교훈
+
+- **Util은 객체지향의 잔재 패턴.** "자율적 객체"라는 객체지향 정의를 따른다면 검증/메시지/계산을 외부에 두는 Util은 자율성을 떼어내는 행위. Util이 아닌 도메인 객체 내부로.
+- **"이 클래스를 지우고도 작동하게 만들어라"는 가장 강력한 가이드.** 직관적이고 검증 가능. 클래스가 정말 필요한지 의심하는 가장 좋은 도구.
+- **입력 형식 결정 = InputView의 일.** `","`, 개행, JSON, XML 등 형식은 입력 매체의 책임. 도메인이 형식을 알면 형식 변경이 도메인을 흔든다.
+- **테스트 = production API 검증.** 객체 내부 상태를 직접 바꿔 검증하면 테스트 가치가 거의 없음. public 메서드를 통해 도메인 행위를 검증.
+- **자료원의 메타 학습.** 리뷰어가 "다른 크루들이 어떻게 하는지 찾아보세요"라고 안내하면, 학생은 자기 학습 방법론을 키운다. 답을 받지 않고 답을 찾는 능력이 성장.
+- **함수 시그니처 일관성** — 비슷한 책임이라면 비슷한 구조. `inputXxx`와 `inputYyy`가 다르게 동작하면 호출자가 그 차이를 학습해야.

package/lessons/woowacourse-racingcar/kmkim2689/123-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,50 @@
+# PR #123 — [자동차 경주 - step2] 빙티 미션 제출합니다
+
+- **Reviewee:** [@kmkim2689](https://github.com/kmkim2689)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/123
+- **단계:** 2단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 11
+
+## 잘한 점 (설계 관점)
+
+- **`MovementDecisionMaker` 인터페이스 도입** — 1단계 MoveManager의 모호함 해소: 결정 책임을 명시.
+- **`position`을 body에 두고 `private set`** — 1단계 피드백 흡수.
+- **`RacingStatusManager` 별도 객체로 비즈니스 로직 이동** — Controller에서 도메인 책임 분리.
+- **함수형 인터페이스 활용** — `getNumber: () -> Int, isMovable: (Int) -> Boolean` 람다 주입.
+- **테스트 코드가 랜덤 의존성 제거 → 결정적 검증** 가능해짐.
+
+## 못한 점 (설계 관점)
+
+- **Controller가 처음엔 모든 도메인 로직 보유** — 학생이 RacingStatusManager로 이동.
+- **`RacingStatusManager`의 "Manager" 접미사** — 여전히 일반 어휘. RacingGame 같은 도메인 이름이 더 적절.
+- **랜덤 테스트에 fuzz 형태** — Random.nextInt를 100회 돌리며 통과 여부.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 메시지:
+
+1. **Controller의 책임 = "View ↔ Model 연결"이지 *Model 동작*이 아님** — "현재 controller가 model에 대해 너무 많은 걸 알고 있어야 한다. 위와 같은 비즈니스 로직을 처리하는 도메인 모델을 하나 더 두고, controller는 트리거만 해주는 방식." → 학생이 RacingStatusManager 신설.
+
+2. **불변값 trade-off** — "name과 position이 모두 val로 copy. 불변 관점에선 좋지만 상태 N개면 N번 객체 생성으로 비효율. 외부엔 수정 불가, 내부에선 수정 가능한 property 방법을 찾아봐라" → `private set`.
+
+3. **return 값으로 흐름 단순화** — `setRacingResult`가 `currentRacingStatus`를 변경한다면 그 결과를 바로 반환. 호출 측 코드 축소.
+
+4. **랜덤 테스트 = 사실 테스트할 가치 없음** — 이건 1단계에서 다른 리뷰어 ghojeong이 같은 지적. 자기가 구현 안 한 부분(Random.nextInt) 테스트는 fuzz일 뿐. 학생이 두 라운드에 걸쳐 인지.
+
+- **대표 인용:**
+  > 현재는 controller 가 domain 에 대해 너무 많은 걸 알고 있어야하는 것 같아요. MVC 구조에서 controller 의 주 역할은 View 와 model 을 연결해주는 것이지, model 그 자체가 어떻게 동작할지는 주 관심사가 되어서는 안됩니다. 이러한 측면에서 현 구조에서는 controller 가 model 의 역할도 하고 있다고 볼 수 있습니다. 위와 같은 비즈니스 로직을 처리하는 도메인 모델을 하나 더 두고, controller 는 트리거만 해주는 방식으로 개선해보면 어떨까요?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/controller/RacingController.kt`
+
+  > kotlin 에서는 외부에서는 수정이 가능하고 내부에서는 수정이 가능하도록 property 를 설정할 수 있는 방법이 있는데, 한번 찾아보시면 좋을 것 같습니다
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/model/Car.kt`
+
+## 얻은 교훈
+
+- **Controller가 *Model을 알면 알수록* 책임 누수**. Controller가 "어떻게 차량들을 움직여서 결과를 만든다"를 알면 그건 도메인 책임. Controller는 "model에 요청 던지고 view로 결과 전달"만.
+- **불변성과 효율의 trade-off는 *책임 위치*로 풀린다**. 모든 변경마다 copy = 비효율. 외부 immutable + 내부 mutable (private set)이 절충안.
+- **함수형 인터페이스 (람다 주입) = 경량 전략 패턴**. `(Int) -> Boolean` 같은 함수 타입을 생성자로 받으면 인터페이스 만들 필요 없이 의존성 분리 + 테스트 fake 주입.
+- **테스트가 결정적이 되면 = 의존성 분리가 잘된 신호**. 이전엔 Random 의존으로 테스트 불가, 람다 주입 후 결정적 검증 가능. 테스트가 짜이는 모양이 설계의 거울.
+- **"Manager" 같은 일반 어휘는 책임을 가린다**. RacingStatusManager → RacingGame처럼 도메인 어휘로 재명명하면 책임이 자연스럽게 따라옴.

package/lessons/woowacourse-racingcar/kmkim2689/92-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 #92 — [자동차 경주] 빙티 미션 제출합니다
+
+- **Reviewee:** [@kmkim2689](https://github.com/kmkim2689)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/92
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **Constants 파일로 상수 모음**, `MoveManager` 분리 시도.
+- **`InputValidator` + 테스트 작성** — 입력 검증을 객체로.
+- **자기 학습 의지** — 가변성 제약 칼럼 읽고 정리해 코멘트 작성.
+- **개념 정리 답변의 깊이** — MutableList vs List, replaceAll/copy 사용처까지 직접 학습.
+
+## 못한 점 (설계 관점)
+
+- **`MoveManager`의 이름** — 움직임 *판단*인지 *실행*인지 모호. 학생이 후속 답에서 "결정 책임"을 의도했다고 정리.
+- **`Constants.kt`에 "1~5글자" 같은 메시지 상수 하드코딩** — 요구사항 변경 시 메시지/검증 두 곳 모두 수정.
+- **Controller가 `lateinit var MutableList`** — 자동차 수 변하지 않는데 Mutable.
+- **`Car.position`이 var (외부 변경 가능)**.
+- **상태 변경마다 새 Car 객체 생성하려는 시도** — 학생이 처음엔 immutable 시도. 비효율 우려.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 핵심 메시지:
+
+1. **메시지 상수와 검증 로직의 결합 위험** — "1, 5 같은 내용이 상수 문자열에 포함되면 요구사항 변경 시 항상 수정 필요." → 학생: 템플릿 `$MIN ~ $MAX`로 변경.
+
+2. **테스트 코드의 변경 유연성** — "테스트 함수명에 `4`라는 기준점 들어가면 변경 시 테스트도 변경." → 학생: "기준 숫자 이하" 같은 추상화.
+
+3. **MutableCollection의 *element*는 변경 가능** — "MutableCollection에 추가/삭제는 불가능해도 element 자체는 변경 가능. element가 스스로 상태를 변경할 수 있다면 매번 새 컬렉션을 만들 필요 없다." → Car가 스스로 position 변경, 컬렉션은 immutable. **Tell Don't Ask의 응용.**
+
+4. **MoveManager의 trade-off (외부 분리 vs 내부 포함)** — 학생이 길게 답: 외부 분리 = OCP 이득, 의존관계 형성. 내부 = 단순. 그러나 결국 추상적이라 다음 단계에서 구현으로 토론.
+
+- **대표 인용:**
+  > MutableCollection 에 숨겨진(?) 사실 하나는 컬렉션에 추가적인 element 에 대한 액션 (추가/삭제 등)은 불가능하지만, elememt 자체는 변경할 수 있다는 것인데요. 만약 element 가 스스로 상태를 변경할 수 있다면, 매번 새로운 컬렉션을 만들지 않아도 되지 않을까요?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/controller/RacingController.kt:12`
+
+  > var 로 선언할 경우, 외부에서도 position 값을 변경할 수 있게 되는데요. 이러한 구조를 지양해야한다면, 이유는 무엇일까요~?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/model/Car.kt:5`
+
+  > 1, 5 와 같은 내용이 상수 문자열에 포함될 경우, 요구사항의 변경에 따라 항상 수정이 필요하게 됩니다. 좀 더 유연하게 관리할 수 있는 방법이 있을까요?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/constants/Constants.kt:7`
+
+## 얻은 교훈
+
+- **메시지 상수에 숫자 박지 말 것.** "1~5글자" 메시지에 1과 5를 박으면 검증 로직과 두 군데 수정 필요. 템플릿 `"$MIN~$MAX 글자"` + 상수 한 곳에 두면 한 줄 수정으로 끝.
+- **컬렉션의 immutability ≠ element의 immutability**. `List<Car>`는 컬렉션이 immutable, 그 안의 Car는 `private set`으로 자기 상태 변경 가능. Tell Don't Ask로 Car에게 "움직여라" 메시지를 던지면 새 List 만들 필요 없음.
+- **테스트 함수명의 추상화 vs 구체화 trade-off**. 학생은 "기준 숫자 이하"로 추상화 → 다음 라운드에서 다른 리뷰어가 "요구사항 바뀌면 테스트 새로 짜는 게 자연스럽다"는 반대 의견. 정답은 없음.
+- **자기 학습 의지의 PR 흔적**. 학생이 자료 찾고 직접 정리한 댓글 → 리뷰어가 같은 자료를 본인도 정독하게 되는 *상호 학습*. 좋은 PR의 신호.
+- **"매번 새 객체 만들기" 함수형 시도의 비용**. 모든 상태 변경에 copy() = 객체 N개 생성. 도메인이 작을 땐 OK지만 *element 책임 분리*가 더 본질적인 답.

package/lessons/woowacourse-racingcar/krrong/34-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,63 @@
+# PR #34 — [자동차 경주] 끄롱 미션 제출
+
+- **Reviewee:** [@krrong](https://github.com/krrong)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/34
+- **단계:** 1단계 (단일 PR)
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **`NumberGenerator` 추상화** — Car가 외부 생성기를 받아 이동 판단.
+- **PR 본문에 명확한 질문 3개** — 함수 네이밍, 예외 처리 위치, 단위 테스트 가능성 등 토론 시발점이 풍부.
+- **피드백 흡수 후 View를 인터페이스로 분리하고 단위 테스트 작성** — 큰 구조적 변경 수용.
+- **`_cars` 패턴 인지 → 외부 비공개시엔 `cars` 하나로 충분** 학습.
+
+## 못한 점 (설계 관점)
+
+- **`String.kt`에 모든 상수 모음** — 연관성 무관하게 한곳에.
+- **`Car.move`의 이동 판단 로직이 외부에서 받은 condition** — 학생 자신이 "이 검증이 RaceManager에 가는 게 맞나"를 후속 질문.
+- **Controller가 View를 직접 생성** — 플랫폼 결합. 인터페이스 미분리.
+- **`lateinit var` / `lazy()` 사용 시점 혼란** — 사용 후 학생이 답을 정리.
+- **`MutableList`를 `_cars` + `cars` getter로 노출하지만 외부에 안 쓰임** — 패턴 오용.
+
+## 리뷰어 의견 요지
+
+리뷰어 @galcyurio의 핵심 가이드 셋:
+
+1. **예외 처리 4단 원칙** — Effective Kotlin Item 7 인용:
+   - 논리 오류일 때만 예외
+   - 그 외엔 null 반환
+   - null 안 되면 sealed class
+   - 일반 코틀린 코드에서 try-catch 미사용
+   
+2. **검증의 위치** — "유효성 검사가 도메인 로직인가?"를 자문. 그렇다면 도메인, 아니면 UI. 단, 답은 개발자마다 다를 수 있음을 솔직히 시인 ("저도 명확한 답 못 드림"). → **리뷰어가 단일 정답 없음을 인정하는 점이 인상적.**
+
+3. **View는 인터페이스로 분리** — Controller가 View 구현체 생성 = "Android/Swing 같은 플랫폼에 의존". 인터페이스 + 주입으로 Controller가 단위 테스트 가능.
+
+4. **`_xxx`/`xxx` 패턴은 read-only 노출용** — 외부에 공개 안 하면 그냥 `var cars`로.
+
+5. **lazy vs lateinit** — 학생이 "초기화 후 변경 가능성"으로 답. 리뷰어 추가 가이드: View는 인터페이스 분리 + 생성자 주입이 더 안전.
+
+6. **함수 이름은 도메인 어휘** — `grep.app` 같은 사이트로 흔한 네이밍 확인. `awaitInput / receiveInput`처럼 행위의 의미가 보이게.
+
+- **대표 인용:**
+  > Controller에서 View를 생성한다는 것은 View에 의존한다는 것과 같습니다. 예를 들면, Android 또는 Swing과 같은 플랫폼에 의존하게 되는 것입니다. 더 엄격하게 UI에 대한 의존성을 분리하기 위해서는 View를 interface로 분리하고 구현체를 생성자로 주입받는 것이 더 좋습니다.
+  >
+  > — @galcyurio on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+  > 판단 방식은 주로 "유효성 검사가 도메인 로직이냐? 아니냐?"와 같은 질문을 던져보고 맞다면 1번처럼 domain으로 분류하고 아니라면 2번처럼 UI 단에서 처리합니다. 다만, 도메인 로직인지 아닌지에 대한 판단은 개발자마다 다를 수 있어서
+  >
+  > — @galcyurio on `docs/README.md:1`
+
+  > 이미 Car 객체의 move() 함수까지 들어와버렸으니 여기서 처리하기 위해서는 Exception을 던지거나 Result 객체를 반환해서 복잡하게 처리해야 합니다. 이런 상황에서는 domain 객체 대신에 UI 객체에서 처리한다면 조금 더 간단하지 않을까요?
+  >
+  > — @galcyurio on `src/main/kotlin/racingcar/domain/Car.kt:14`
+
+## 얻은 교훈
+
+- **"이 검증을 어디서 할까"의 핵심 질문 = "그게 도메인 로직이냐?"** 답이 갈리는 회색지대지만, 도메인 깊숙이 들어가서 검증하려면 Exception/Result 같은 복잡한 반환 채널이 필요. UI에서 잡으면 간단.
+- **상수의 자리는 *연관성*이 결정한다.** 한 클래스에서만 쓰이면 그 클래스의 companion object. 한 파일에 다 모으는 String.kt는 응집도 낮음.
+- **`_xxx` + `xxx` getter 패턴은 외부에 read-only를 공개할 때만.** 외부 미공개라면 그냥 `private var`로 끝.
+- **View를 인터페이스로 분리 → Controller 단위 테스트 가능.** Controller가 View 구현체를 안다 = 콘솔/Android/Swing/Web 의존. 인터페이스 + 생성자 주입은 곧 테스트 가능성.
+- **리뷰어가 "이건 답이 없다"고 인정할 줄 아는 것도 중요한 신호.** 단일 정답을 강요하지 않고 "기준은 팀/맥락마다 다르다"고 솔직히 말함 → 학생이 자기 기준을 세울 여지를 줌.

package/lessons/woowacourse-racingcar/m6z1/150-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 #150 — [자동차 경주 구현] 뭉치 미션 제출합니다
+
+- **Reviewee:** [@m6z1](https://github.com/m6z1)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/150
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 48
+
+## 잘한 점 (설계 관점)
+
+- **`Judge`/`Organizer`/`OutputPrinter`로 책임 분리 시도** — 1단계임에도 책임 분할 의식이 보임. (역할 정체성은 다음 라운드 토론으로 이어짐)
+- **상수의 위치를 자기 언어로 정리** — "각 객체에 상수 vs 한 곳에 모으기" 트레이드오프를 자기 머릿속에서 정리해 답함.
+- **에러 상수와 검증 로직을 한 클래스로 묶는 시도(`CarError`)** — 정답은 아니지만 "에러 메시지 + 검증"이라는 응집을 만들어보려는 시도.
+- **공백 검증 등 도메인 invariants 식별** — `1, 2, 3` 같은 입력의 공백 문제를 사용자/리뷰어 시점으로 토론.
+
+## 못한 점 (설계 관점)
+
+- **`Judge`가 하나의 함수에 두 가지 책임** — maxPosition 계산 + winner 식별이 한 함수에 들어감.
+- **`Organizer`의 이름이 정체 불명** — Controller 역할인데 이름만으로 추측 불가. `RaceGame`/`RaceController`처럼 도메인을 반영해야.
+- **`OutputPrinter`도 의미 부족** — `OutputView`와 같은 추상이라면 이름이 그 정도여야.
+- **에러 클래스(`CarError`)가 "상수 + 검증 + 일급 컬렉션 검증" 다중 책임** — `BLANK_NAME`, `OUT_OF_RANGE_NAME_LENGTH`는 `Car`의 책임인데 외부 검증기에 위치.
+- **enum class로 에러를 분류 — 정말 enum이 필요한가** — 단순 상수 집합이라면 `object`로 충분. enum은 다형성과 상태가 함께 있을 때 가치.
+- **`Referee` 추가 도입 — `Cars`/Car에 책임을 두는 게 더 자연스러울 수 있음** — "심판" 비유가 그럴듯해 보이지만 메시지 모델로는 `Cars.findWinners()`가 더 객체지향적.
+- **테스트 이름이 도메인 의도를 안 드러냄** — 무엇이 어때야 하는지가 테스트명에서 안 보임.
+- **`OutputView`의 하드코딩 문자열** — 매직 리터럴이 표시 코드에 박혀 있음.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag는 **"재사용 가능한 것은 재사용 가능하게 + 도메인이 들어야 하는 것은 도메인에"** 라는 균형을 일관되게 제시. 모든 검증을 Validator에 몰아넣지도 말고, 모든 검증을 도메인에만 두지도 말 것 — "그 중간점의 기준을 세우는 것이 학습"이라는 메타 가이드.
+
+또한 (1) **함수는 한 가지 일** (Judge의 maxPosition + winner 분리), (2) **이름이 책임을 드러낼 것** (Organizer → RaceGame), (3) **enum vs object 선택의 기준** (다형성이 필요한가)을 짚었다.
+
+- **대표 인용:**
+  > 함수는 하나의 기능을 하도록 분류를 해보는 것은 어떨까요? 1. maxPosition 을 구하는 함수 2. winner를 알려주는 함수
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/Judge.kt`
+
+  > `재 사용할 수 있는 것들은 재사용이 가능하게` 구조를 갖추는 것이 포인트 입니다 ... 과하게 묶는다면, 오히려 자칫 확장하기 어려운 구조가 될 수도 있어서, 적당하게 공통된 부분을 묶어 보도록 해보는 것은 어떨까요?
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/InputReader.kt`
+
+  > BLANK_NAME, OUT_OF_RANGE_NAME_LENGTH 이 두가지는 Car 객체에 존재한다면, 해당 네이밍을 ex) CarsValidator 등등으로 변경이 가능해 보입니다.
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingCar/CarError.kt`
+
+## 얻은 교훈
+
+- **검증의 위치는 이분법이 아니다.** "전부 도메인" 혹은 "전부 Validator"가 아니라, **그 invariant의 주인이 누구인가**에 따라 결정. `Car` 이름 규칙은 `Car`가, "자동차 목록은 중복 없음"은 `Cars`가, "입력 형식이 숫자인가"는 입력 경계가.
+- **enum은 다형성/상태가 있을 때 가치 있다.** 단순 상수 집합은 `object`로. 데이터+행동의 변형이 필요할 때 enum이 빛난다.
+- **함수는 한 가지 일.** `Judge` 안에 maxPosition 계산과 winner 추출이 함께 있다면 두 가지 단위로 단위 테스트가 갈라진다. 작은 함수가 검증 가능성을 만든다.
+- **이름이 책임의 추측 가능성을 만든다.** `Organizer` 같은 일반어는 호출자에게 정보를 거의 주지 않는다. 도메인을 반영한 `RaceGame`은 호출자가 무엇을 호출하는지 짐작하게 한다.
+- **"심판/배심원" 같은 현실 비유가 항상 좋은 객체 모델은 아니다.** 객체지향 세계에서는 "심판이 자동차들을 본다"보다 "자동차들이 자기들 중 우승자를 안다"가 더 직접적 — Tell-Don't-Ask.
+- **에러 메시지의 자리는 그 invariant의 주인 곁.** 에러를 한 클래스로 모으면 "한 곳에서 관리"가 되지만, "왜 그 invariant가 이 메시지를 가져야 하는가"라는 응집 근거를 잃는다.

package/lessons/woowacourse-racingcar/m6z1/156-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,40 @@
+# PR #156 — [자동차 경주 2단계] 뭉치 미션 제출합니다
+
+- **Reviewee:** [@m6z1](https://github.com/m6z1)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/156
+- **단계:** 2단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 5 (1단계의 큰 피드백을 흡수한 단단한 리팩터링 PR)
+
+## 잘한 점 (설계 관점)
+
+- **`Referee` → `RaceRule`로 책임 정체성 재정의** — "심판"이라는 현실 비유를 깨고 "경기 규칙"이라는 추상으로 옮김. 리뷰어가 명시적으로 칭찬.
+- **패키지 분리** — `racingCar` 한 곳에 있던 것을 모델/뷰/컨트롤러 단위로 분리.
+- **테스트에서 `position`을 생성자로 주입 가능하게 변경** — 도메인 객체의 결정적 테스트 가능성 확보.
+- **`Car`의 책임이 깔끔하게 정돈** — 1단계의 비대함이 사라지고 군더더기 없는 단위로.
+
+## 못한 점 (설계 관점)
+
+- **테스트의 fixture 중복** — `repeat(4) { car1.moveForward() }` 같은 반복이 그대로 있어, 의도가 흐려짐. `@BeforeEach`나 헬퍼 함수로 묶는 편이 가독성에 유리.
+
+(이 PR은 1단계의 큰 피드백을 흡수한 안정화 PR이라 OOP 관점의 critical 이슈가 거의 없다.)
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag는 이 라운드에서 **반영 결과에 대한 강한 긍정**을 주로 전달했다. `Referee`→`RaceRule`의 이름 변경과 패키지 분리에 대해 명확한 칭찬. 남은 가이드는 테스트 fixture 같은 미세한 항목 위주.
+
+- **대표 인용:**
+  > Refree 에서 RaceRule로 네이밍이 변경되었군요~👍
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingCar/model/RaceRule.kt`
+
+  > 위와 같이 중복된 내용들을 함수로 뽑아보는 방법도 있을 것 같습니다! 테스트 코드에는 test fixture 라는 개념이 존재하는데 내용을 살펴보는 것도 좋을 것 같습니다.
+  >
+  > — @Gyuil-Hwnag on `src/test/kotlin/racingCar/RaceRuleTest.kt`
+
+## 얻은 교훈
+
+- **현실 비유는 도메인 모델링의 시작이지만 끝이 아니다.** "심판" → "경기 규칙"으로의 변경처럼, 비유로 시작한 추상이 코드 안에서 "더 추상적인 본질"로 도달하면 정체성이 견고해진다.
+- **두 번째 라운드의 코멘트 수는 학습의 척도다.** 1단계에서 48개 코멘트가 달리고 2단계에서 5개로 줄었다면, 큰 피드백을 구조적으로 잘 흡수했다는 신호. 양 자체가 학습의 깊이를 말해줌.
+- **테스트 fixture는 의도의 명료성 도구.** 같은 setup을 여러 번 반복하면 "무엇이 진짜 테스트의 차이인가"가 가려진다. 공통 부분을 묶어내면 그 다음의 비교가 선명해진다.
+- **도메인 객체의 생성자가 받는 것이 곧 결정적 테스트의 입구.** `Car(name, position)`처럼 초기 상태를 받을 수 있으면, 별도 setter나 reflection 없이 테스트 시나리오를 만들 수 있다.

package/lessons/woowacourse-racingcar/medAndro/153-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 #153 — [자동차 경주 구현] 메다 미션 제출합니다
+
+- **Reviewee:** [@medAndro](https://github.com/medAndro)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/153
+- **단계:** 1단계 (단일 PR)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 33
+
+## 잘한 점 (설계 관점)
+
+- **자기 의문을 명확히 제기** — 랜덤 테스트 방법, private 함수 테스트 등.
+- **`ByteArrayInputStream`으로 콘솔 입력 모사 학습** — 깊은 테스트 도구 학습.
+- **리뷰의 의도를 자기 언어로 정리** — 확장성, 콘솔 vs 키오스크 등.
+
+## 못한 점 (설계 관점)
+
+- **`ApplicationTest`에 모든 테스트 모음** — 1000개 기능이면? 객체별 분리 필요.
+- **랜덤 확률 테스트 (60%~60.01%)** — 표준 라이브러리 신뢰 문제. 학생이 즉시 흡수.
+- **`Car.distance`가 외부 변경 가능** — `car.distance = 0`이 가능한 무방비 상태.
+- **`Car("AsdfiasjdoiAsdjasodjasodjasdjsaisajdia", 10)`이 통과** — 자동차 invariants 미보유.
+- **`Application.run()`을 여러 번 호출 시 문제** — 라이프사이클이 클래스가 아니라 한 번의 호출.
+- **`InputValidator`가 Car 생성** — Validator가 도메인 생성 책임까지.
+- **`RaceService.race()` 반환값 불명** — 호출자가 무엇을 받는지 모름.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **표준 라이브러리 신뢰** 가이드를 코틀린 스탠다드 라이브러리의 RandomTest 링크와 함께 명확히 제시. 우리가 검증해야 할 것은 우리 코드가 그 라이브러리를 *어떻게 사용하는지*.
+
+또한 **"1000개 기능이면?"** 시뮬레이션 — 모든 테스트를 한 파일에 두는 안티패턴을 극단적 상황으로 시각화. 학생이 즉시 흡수.
+
+**"객체는 자기만의 역할 + 기능"** 이라는 OOP 본질을 테스트와 연결: 객체별 책임 = 객체별 테스트.
+
+`Application.run()`을 5번 호출하는 시뮬레이션 — 라이프사이클 어색함을 즉시 보여주는 코드 예시.
+
+- **대표 인용:**
+  > 코틀린 팀에서 작성한 이 테스트는 무용지물이..되는 것일까요? https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/test/random/RandomTest.kt ... 표준 라이브러리에서 제공하는 함수를 테스트 하려는 의도에 대해서입니다.
+  >
+  > — @laco-dev on `src/test/kotlin/ApplicationTest.kt`
+
+  > 만약 이 프로그램에 존재하는 기능이 1000개가 넘는다면 모든 기능을 전부 하나의 테스트 파일에 작성을 해야 할까요?
+  >
+  > — @laco-dev on `src/test/kotlin/ApplicationTest.kt`
+
+  > val application = Application()  application.run() application.run() application.run() ... 이렇게 호출하면 어떤 문제가 있나요??
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/Application.kt`
+
+## 얻은 교훈
+
+- **표준 라이브러리 신뢰의 경계.** 코틀린 팀이 이미 테스트한 함수를 다시 테스트하면 무한 검증 루프. 우리는 우리 코드의 *사용 패턴*만 테스트.
+- **"1000개라면?" 시뮬레이션 = 안티패턴 탐지 도구.** 작은 코드에서 보이지 않는 문제(테스트 한 파일 집중, Util 한 파일 집중 등)가 큰 규모에서 명백.
+- **객체 단위 테스트 = 객체 단위 책임 + 객체 단위 검증.** 같은 객체의 책임을 같은 테스트 클래스에 모으는 게 OOP 학습의 한 형태.
+- **호출 패턴 시뮬레이션 = 라이프사이클 진단.** `application.run()`을 5번 호출해도 동작해야 하는지, 한 번만 해야 하는지 — 코드의 의도를 호출 패턴으로 명확히.
+- **Validator가 Car 생성 = 책임 침해.** Validator는 검증만, 생성은 생성자 또는 팩토리. 두 책임이 한 곳에 있으면 둘 다 흐려진다.

package/lessons/woowacourse-racingcar/moondev03/135-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 #135 — [자동차 경주] 다온 미션 제출합니다
+
+- **Reviewee:** [@moondev03](https://github.com/moondev03)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/135
+- **단계:** 1단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 20
+
+## 잘한 점 (설계 관점)
+
+- **InputView/OutputView 분리**.
+- **`require()` 활용한 무결성 검증**.
+- **`RandomNumberGenerator` 인터페이스 + Impl 분리** — 전략 패턴 적용.
+- **PR에 4개의 명확한 질문** — 입력 검증 위치, require의 별도 함수 분리, 출력 함수 통합 여부, MethodSource 활용.
+- **피드백 흡수 후 검증을 View로 이동 + InputViewTest 작성** — 큰 구조 변경 수용.
+
+## 못한 점 (설계 관점)
+
+- **`RacingGame`이 검증 책임 보유** — 처음엔 모델이 입력 검증까지. 학생이 InputView로 이동.
+- **InputView가 object 아닌 class** — 상태 없는 View가 인스턴스를 가질 이유 부재.
+- **`RacingGameTest`에 입력값 테스트** — 입력 검증이 RacingGame 책임이 아니라 RacingGame 테스트의 자리도 아님.
+- **요구사항 표현 오류** — "5자를 초과할 수 없다"가 테스트 fun 이름에 "5자 초과해야 에러"로 잘못 표현.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 메시지는 **"객체에게 메시지를 던져라 (Tell Don't Ask)"**.
+
+1. **검증의 책임 = 입력을 받는 객체** — "객체를 잘 분리해주신 만큼, 각 클래스(객체)에게 메시지를 던져보는건(입력을 받아!) 어떨까요?" → RacingGame이 결과만 받고 검증은 InputView에서.
+
+2. **테스트가 본질을 가리키는가?** — "입력값에 대한 테스트는 RacingGame에 대한 테스트일까요?" → 테스트 위치가 책임 위치를 폭로. RacingGameTest에서 InputViewTest로 이동해야 함.
+
+3. **object vs class** — 상태 없으면 object. View처럼 인스턴스 여러 개 필요 없는 경우.
+
+4. **출력 함수 통합 토론** — 정답 없음. "공통으로 자주 쓰이면 분리". 책임이 안 갈리면 합치는 게 맞을 수도.
+
+5. **MethodSource + 명확한 테스트 이름** — 둘 다 적절히 결합.
+
+- **대표 인용:**
+  > 입력을 받았을 때 먼저 검증을 하도록 Input쪽에 역할을 부여해보는건 어떨까요? 테스트 관점에서 어떤 차이가 있을지 고민해보시고, **저에게도 공유해주세요!**
+  >
+  > — @KwonDae on `src/main/kotlin/model/RacingGame.kt`
+
+  > 입력값에 대한 테스트는 RacingGame에 대한 테스트일까요?
+  >
+  > — @KwonDae on `src/test/kotlin/model/RacingGameTest.kt`
+
+  > 클래스를 잘 분리해주신 만큼, 각 클래스(객체)에게 메시지를 던져보는건(입력을 받아!) 어떨까요?
+  >
+  > — @KwonDae on `src/main/kotlin/model/RacingGame.kt`
+
+## 얻은 교훈
+
+- **테스트 위치 = 책임 위치의 폭로.** RacingGame 테스트에 입력 검증이 보이면 RacingGame이 그 책임을 들고 있다는 신호. 테스트가 어색하면 책임을 옮길 자리를 가리킴.
+- **Tell Don't Ask의 첫 단계 = "이 객체에게 메시지를 던졌을 때 책임을 다할 수 있는가?"** InputView에게 "검증해라"가 자연스러우면 그게 그 객체의 역할.
+- **검증의 분류** — UI 형식 검증 (빈 문자열, 숫자 아님) = View, 도메인 규칙 검증 (자동차 두 대 이상, 이름 중복) = Domain. 학생은 다음 PR에서 정확히 이 분류를 깨달음.
+- **상태 없는 View = object.** 인스턴스 여러 개 필요 없고 상태 없으면 object. class는 인스턴스마다 다른 상태가 필요할 때.
+- **"각 객체에게 메시지를 던진다"는 RDD의 핵심.** Controller가 모든 걸 조립하는 게 아니라, 적절한 객체에게 자기 책임을 하게 하는 게 RDD.