oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/s9hn/53-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,44 @@
+# PR #53 — [자동차 경주] 산군 미션 제출합니다
+
+- **Reviewee:** [@s9hn](https://github.com/s9hn)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/53
+- **단계:** 2단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 7
+
+## 잘한 점 (설계 관점)
+
+- **Driver 인터페이스로 느슨한 연결** — 움직임 결정의 추상화.
+- **DriverDecision enum** — 결정 결과의 의미 명시.
+- **backing field로 외부 read-only**.
+- **colon/separator 상수화 (꼼꼼한 위생)**.
+
+## 못한 점 (설계 관점)
+
+- **`Application`이 Controller 책임 일부 보유** — Controller 분리 의미 약화.
+- **`Referee.filter`로 별도 함수 선언 가능한데 그대로 둠**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 메시지:
+
+1. **원시값은 `private set`이 backing field보다 간결** — "컬렉션처럼 mutableXXX 노출 회피가 필요한 케이스만 backing field 정당화."
+
+2. **Application은 *실행 진입점*만** — 비즈니스 의존성 보유 회피.
+
+3. **enum + 인터페이스 활용 칭찬**.
+
+- **대표 인용:**
+  > backing field 로 처리해주신 부분 좋습니다 👍 다만, 저는 원시값인 경우에는 setter 를 오버라이딩하는 방식을 더 선호하는데요. 컬렉션과 같이 read only 타입이 별도로 존재하는 케이스에서는, mutableXXX 같은 타입을 리턴해서는 안되기 때문에 backing field 를 통해 분리하는 것이 유의미 할 수 있지만 원시값은 크게 상관이 없기 때문입니다. 변수도 하나 줄일 수 있구요
+  >
+  > — @vagabond95 on `src/main/kotlin/domain/Car.kt`
+
+  > Controller 를 별도로 둔 이상, main 에서는 실제 동작에 대한 정보 혹은 의존성을 최대한 가지지 않으면 좋을 것 같아요.
+  >
+  > — @vagabond95 on `src/main/kotlin/Application.kt`
+
+## 얻은 교훈
+
+- **원시값 = `private set`. 컬렉션 = backing field**. 컬렉션의 mutable/immutable 노출 분리에는 backing field가 필요하지만 원시값은 `private set`이 깔끔.
+- **Application/main = 의존성 0**. 진입점은 Controller 생성하고 호출만. 비즈니스 의존성이 main에 있으면 Controller 분리 무의미.
+- **enum + 인터페이스**의 협력 — DriverDecision enum이 결과의 *의미*를, Driver 인터페이스가 *결정 방식*을 표현. 두 추상이 협력.

package/lessons/woowacourse-racingcar/s9hn/78-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 #78 — [자동차 경주 - 리팩토링] 산군 미션 제출합니다
+
+- **Reviewee:** [@s9hn](https://github.com/s9hn)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/78
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 5
+
+## 잘한 점 (설계 관점)
+
+- **`set private`로 backing field 단순화** — 원시값 적용.
+- **접근 제한자 꼼꼼**.
+- **enum + 인터페이스**.
+
+## 못한 점 (설계 관점)
+
+- **`DriverDecision`의 `distance`가 String** — UI 표현이 도메인 enum에 침투.
+- **CarTest가 "-" 표현에 의존** — 도메인 테스트가 UI 결과 검증.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 핵심 메시지:
+
+1. **enum의 *데이터*는 도메인 의미** — `distance`가 "-" 같은 UI 문자면, *UI 요구사항 변경 시 도메인 변경*. boolean (`true`/`false`)이 도메인.
+
+2. **테스트의 의존 = 검증 대상**. CarTest가 UI 표현 ("-")에 의존하면 UI 변경 시 CarTest도 깨짐. 도메인 테스트는 도메인 값만 검증.
+
+3. **`set private`로 backing field 대체 칭찬** — 원시값 케이스에 적합.
+
+- **대표 인용:**
+  > 다만, distance 를 string 이 아닌 true / false 등으로 표현했으면 더 좋았을거 같아요. `"-"` 값은 어디까지나 UI 와 연관된 부분이고, UI 와 관련된 요구사항이 변경되었을 때 domain 영역의 코드에도 변경사항이 발생하는 것은 바람직하지 않아보입니다.
+  >
+  > — @vagabond95 on `src/main/kotlin/domain/DriverDecision.kt`
+
+  > DriverDecision 에 대한 코드리뷰의 연장선으로, 해당 테스트 코드 역시 '도메인'에 대한 테스트 이므로 테스트 결과를 "ui" 결과에 의존해서는 안될거 같아요. '자동차의 주행 거리를 어떻게 표시할 것인지'에 대한 요구사항이 바뀌면 CarTest 의 코드 역시 변경이 발생할테니까요.
+  >
+  > — @vagabond95 on `src/test/kotlin/domain/CarTest.kt`
+
+## 얻은 교훈
+
+- **enum의 데이터는 *도메인 의미*만**. `"-"` 같은 UI 표현이 enum에 들어가면 UI 변경이 enum 변경, 도메인 변경. 두 변경 이유가 하나의 enum에 모임.
+- **테스트의 의존 = 검증 대상의 일부**. 도메인 테스트가 UI 값을 검증하면, 그 테스트는 도메인이 아닌 *도메인 + UI* 통합 테스트. 단위 테스트의 격이 무너짐.
+- **`"-"`의 자리 = OutputView 상수**. 도메인은 boolean / 거리(Int), 표현은 View가 책임.

package/lessons/woowacourse-racingcar/sh1mj1/107-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 #107 — [자동차 경주] 심지 미션 제출합니다
+
+- **Reviewee:** [@sh1mj1](https://github.com/sh1mj1)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/107
+- **단계:** 1단계
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 8
+
+## 잘한 점 (설계 관점)
+
+- **`TryCount` 도메인 객체 + 팩토리 패턴** — 원시 강박 탈출.
+- **`NumberGenerator` 인터페이스 + `ExplicitNumberGenerator` 테스트 더블**.
+- **`Car`의 이름 검증을 model에서** — 도메인 invariant.
+- **상수에 `private` 적용**.
+
+## 못한 점 (설계 관점)
+
+- **`RacingGame`(Controller)이 NumberGenerator를 직접 받음** — DI 흐름 길어짐.
+- **`TryCount`를 data class로 쓰고 싶지만 private constructor와 충돌** — copy로 우회 가능해서 진정한 private 아님.
+- **Car는 data class, TryCount는 일반 class** — 둘 사용 기준 비대칭.
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong의 핵심 가르침:
+
+1. **DI 키워드보다 *역할과 책임*** — "DI 라는 키워드에 집착하기 보다는 NumberGenerator 와 의존관계를 가질 class 가 누가 되어야 하는지, 역할과 책임 관점에서 생각." 조영호 "객체지향의 사실과 오해" 3요소 (역할, 책임, 협력).
+
+2. **이름 검증의 *모델 위치* 정당화** — "이름이 5자 넘은 채로 서버 통신하면 크래시 가능. 그러면 모델 검증이 맞다." 검증 위치는 *실패의 영향*으로 결정.
+
+3. **상수 private 권장** — IDE 자동완성에 너무 많은 항목이 뜨면 협업자 혼란.
+
+4. **data class 사용 일관성** — Car는 data class, TryCount는 일반 class. 학생이 *왜* 다르게 선택했는지 경험을 공유하기.
+
+5. **테스트 코드의 *진정한 가치* = "무엇을 테스트하려는지" 명확**. toInt 호출이 군더더기여도 의도가 명확하면 OK.
+
+- **대표 인용:**
+  > DI 라는 키워드에 집착하기 보다는 NumberGenerator 와 의존관계를 가질 class 가 누가 되어야 하는지, 역할과 책임 관점에서 생각을 해보시면 좋을 것 같습니다. 객체설계를 할 때의 3가지 요소를 역할, 책임, 협력이라고 객체지향의 사실과 오해 책에서 꼽습니다.
+  >
+  > — @ghojeong on `src/main/kotlin/controller/RacingGame.kt:24`
+
+  > 가령 이름이 공백이 허용되거나 5글자를 넘은 상태로 서버와 통신하면, 서버가 요청을 받아들이지 못해 크래시가 나는 중대한 버그가 생길 수 있다면, 저도 이렇게 모델을 통해 검증하고 테스트 코드를 작성했을 것 같습니다.
+  >
+  > — @ghojeong on `src/test/kotlin/domain/CarTest.kt:21`
+
+  > Car 는 data class 를 활용하셨지만, count 원시값을 포장한 TryCount 는 data class 를 활용하지 않으셨군요. 심지님은 Car 에 data class 문법을 사용해서 어떤 편리함을 얻으셨는지, TryCount 에서는 왜 data class 문법이 불편하였는지 경험을 공유해주시면 좋을 것 같습니다!
+  >
+  > — @ghojeong on `src/main/kotlin/domain/Car.kt:6`
+
+## 얻은 교훈
+
+- **DI는 *수단*이지 *목적* 아니다**. "어디서 어떻게 주입할지"가 아니라 "이 객체가 누구와 협력해야 하는가"가 출발점. 협력자가 정해지면 주입 자리는 따라옴.
+- **검증의 위치 = "실패의 영향"으로 결정**. 도메인이 외부 시스템(서버, 파일, DB)과 통신하면, 잘못된 입력이 *외부에서 깨지는 게* 더 위험. 모델 검증이 정당화됨.
+- **모든 사소한 결정에는 *이유*가 있어야 한다**. data class vs class를 *왜* 다르게 골랐는지가 학생의 기준이 됨. 결과보다 *과정의 이유*가 학습.
+- **public 상수의 비용 = IDE 자동완성 노이즈**. private는 단지 캡슐화 도구가 아니라 *동료를 위한 청결*.
+- **테스트 함수의 가치 = "무엇을 테스트하는지" 명확함**. 군더더기 toInt 호출이 있어도 의도가 명확하면 OK. *지나친 미적 추구*는 학습 단계에 방해.

package/lessons/woowacourse-racingcar/sh1mj1/115-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,61 @@
+# PR #115 — [자동차 경주 - 리팩토링] 심지 미션 제출합니다
+
+- **Reviewee:** [@sh1mj1](https://github.com/sh1mj1)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/115
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 15
+
+## 잘한 점 (설계 관점)
+
+- **`MoveStrategy` 인터페이스 + 전략 패턴 본격 도입** — Car는 어떻게 숫자가 만들어지는지 모름.
+- **`MoveStrategyUsingNumber`를 *별도 클래스*로** (익명 함수 대신) — 요구사항에 부합하는 자리 명확.
+- **NumberGenerator + MoveStrategy 분리** — 두 책임이 한 객체에 합쳐지지 않음.
+- **타입을 인터페이스로 받기** (Controller가 MoveStrategy 받기).
+- **테스트 패키지에 `MoveStrategyIsAlways` 별도 구현** — 테스트 더블의 자리 분명.
+- **테스트 타입을 *구현체*로 명시** — 인터페이스 대신 실구현체로 함으로써 *어떤 구현*을 테스트하는지 명시.
+- **자가 분석으로 DI 깊이 문제 *스스로 해결*** — Car는 숫자 생성을 알 필요 없음 → MoveStrategy로 위임.
+
+## 못한 점 (설계 관점)
+
+- **`TryCount`의 private constructor + data class 충돌 미해결** — 학생이 일반 class로 회피.
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong의 *최상위 칭찬* 리뷰. 학생이 1단계 피드백을 자가 학습으로 발전시킨 이상적 사례.
+
+1. **불편 인지 + 자가 해결 = 객체지향의 본질** — "객체지향 패러다임은 별로 안 중요. 불편함을 스스로 인지하고, 인지한 부분을 다시 스스로 해결하는 과정이 제일 중요. 객체지향 패러다임은 불편을 해결하는 수많은 방법 중 정형화된 방법 하나에 불과."
+
+2. **"객체지향에 맞느냐"의 답 = "무슨 객체가 개선되었나"** — 학생 스스로 답할 수 있으면 충분. 학생은 이미 답을 들고 있음.
+
+3. **data class + private constructor의 충돌** — `copy()` 메서드로 우회 가능. *진정한 private*은 불가. 안드로이드 렌더링 최적화 관점에서 "같은 data → 같은 참조" 유지가 유지보수성 향상.
+
+4. **익명 함수 vs 별도 클래스** — 인터페이스 만들고 실구현을 익명으로 자주 쓰지만, 별도 클래스가 *요구사항을 명시*.
+
+5. **테스트의 타입 = 구현체로 명시** — 인터페이스가 아닌 구현체로 받으면 "이건 *이 구현*을 테스트한다"가 분명.
+
+- **대표 인용:**
+  > 객체지향 패러다임은 사실 별로 안 중요합니다. 심지님이 불편함을 느낀 부분을 스스로 인지하고, 인지한 부분을 다시 스스로 해결하는 과정이 제일 중요합니다. 객체지향 패러다임은 불편함을 해결할 수 있는 수많은 방법 중, 정형화되어 업계에 통용되는 방법 중 하나에 불과합니다.
+  >
+  > — @ghojeong on `src/main/kotlin/Application.kt:1`
+
+  > 객체지향 패러다임에 들어맞느냐라는 질문에는 제가 아니라 심지님 스스로, 무슨 "객체" 가 개선되었는지 답할 수 있으면 됩니다.
+  >
+  > — @ghojeong on `src/main/kotlin/Application.kt:1`
+
+  > 기껏 MoveStrategy 를 인터페이스로 추상화했지만, 익명 함수를 사용하시는 분들이 많은데, 요구사항에 부합되는 MoveStrategyUsingNumber 를 별도 클래스로 선언해주신점 멋집니다.
+  >
+  > — @ghojeong on `src/main/kotlin/domain/MoveStrategyUsingNumber.kt:8`
+
+  > 동일한 상태를 가지는 두 객체가 서로 다른 참조를 가질 경우 이 최적화에 문제가 생길 수 있습니다... 안드로이드를 포함한 모든 프론트 관련 프레임워크 혹은 라이브러리는, 데이터를 변경하는 함수 호출 이후에, 데이터 값이 실제로 변경되지 않았다면 화면을 리렌더링하지 않는 최적화를 합니다.
+  >
+  > — @ghojeong on `src/main/kotlin/domain/TryCount.kt:1`
+
+## 얻은 교훈
+
+- **객체지향 패러다임 = 도구. 불편 인지 = 진짜 본질.** "이 코드의 불편함이 뭐지? → 어떻게 해결? → OOP가 그 해결의 *정형화된* 방식 중 하나"가 사고 흐름.
+- **자가 점검의 질문**: "내가 풀었다고 생각하는데, *무슨 객체*가 개선되었나?" 그 답이 분명하면 OOP 잘 적용한 것. 답 못 하면 표면만 흉내.
+- **인터페이스 + 익명 함수 vs 별도 클래스**. 별도 클래스가 *요구사항 자체*를 코드에 남김. 익명은 빠르지만 그 자리를 검색하기 어려움. *요구사항이 영구한 것*은 클래스로.
+- **data class의 동치성 = 참조 동치성과 맞물려 렌더링 최적화 영향**. value 같으면 참조도 같게 = 프레임워크가 리렌더링 스킵 가능. private constructor + copy 우회는 이 invariant 깨뜨림.
+- **테스트의 타입 = 인터페이스 vs 구현체 선택**. 인터페이스는 "이 추상에 대한 검증"이지만 구현체로 받으면 "이 구현체 검증"으로 명시. *어느 게 맞느냐*는 테스트 의도에 따라.
+- **리뷰어가 "박수쳤습니다"라고 칭찬하는 PR의 특징** = (1) 1단계 피드백 흡수 (2) 자가 학습으로 다음 단계로 발전 (3) 그 결정의 이유를 PR 본문에 정리. 이상적 학습 곡선.

package/lessons/woowacourse-racingcar/songpink/119-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,51 @@
+# PR #119 — [자동차 경주 구현] 알송 미션 제출합니다 (2단계)
+
+- **Reviewee:** [@songpink](https://github.com/songpink)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/119
+- **단계:** 2단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 18
+
+## 잘한 점 (설계 관점)
+
+- **MVC의 의미를 자기 언어로 정리** — "Controller는 명령을 내리고, 정보 관리는 model"이라는 정의를 직접 시도하며 토론을 끌어옴.
+- **`RacingGame` 모델 도입으로 게임 상태의 자리 정착** — 리뷰어 피드백 후 "경주장"이라는 도메인 모델을 추가해 Car들을 한 곳에 모음.
+- **우승자 판별 책임을 경주장으로 이동** — `FinalWinner`라는 절차적 함수형 클래스에서 도메인 객체의 메서드로.
+- **Car가 자동차 데이터와 움직인다는 핵심 비즈니스 로직을 갖는다는 정의를 명확히** — 리뷰어가 "맞습니다 👍"로 확인.
+
+## 못한 점 (설계 관점)
+
+- **Model의 단위 테스트 누락** — `Car` 같은 도메인 객체에 단위 테스트가 부족. 도메인 로직이 검증 없이 진화.
+- **`RandomNumberGenerator`가 Model에 종속** — 무작위가 도메인 안에 있어 도메인 테스트가 어려워짐. 인터페이스 추상으로 분리 필요.
+- **`OutputView`가 Car를 직접 움직이려는 흔적** — 출력 책임자가 도메인을 조작. 출력은 받아서 그리기만.
+- **`FinalWinner`라는 절차 클래스** — "우승자를 가리는" 함수일 뿐인데 클래스로. 단독 object로 분리할 만큼 응집된 책임이 아님 — 그 행위의 주인은 경주장(`RacingGame`).
+- **반영 미완**: 리뷰어가 가이드한 전략 패턴/추상화 적용이 시간 부족으로 일부 미반영.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae는 이 라운드에서 **체스판 비유**로 MVC의 책임을 시각화했다. "체스판 = 경주장(RacingGame model), 플레이어 = Controller". 모델은 상태를 관리하고 컨트롤러는 명령만 내린다. 이 한 가지 비유로 모든 책임 위치 질문이 정리됨.
+
+또한 **"우승자를 가리는 책임은 어디에?"** 라는 질문에 세 후보를 명시적으로 제시(controller / 경주장 / 차)해서 reviewee가 스스로 답에 도달하게 함. 이런 질문 설계가 학습을 유도.
+
+랜덤 의존에 대해서는 **추상화(interface)와 전략 패턴**을 직접 명시하며 학습 자료 링크까지 함께 제공.
+
+- **대표 인용:**
+  > 체스판을 예로 들어 볼게요, 체스를 플레이하는 두 유저는 Controller가 될 수 있을것이고, 체스판은 RacingGame이 될 수 있겠죠. 체스판에는 현재 체스판의 상태(누가 이기고 있는지, 어떤 말들이 죽고 살았는지 등등) 상태를 갖고있습니다. 유저는 단지 체스판에게 어떤 말을 얼마나 움직이라고 명령할 뿐이죠
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/RacingCarRun.kt`
+
+  > 하나의 경주장에는 여러개의 차량들이 있을겁니다. 그렇다면 여러개의 차량들 중 우승자를 가리는 책임은 어디에 있으면 좋을까요. 명령을 하는 controller vs 전체적인 경주 상태를 관리하는 경주장 vs 차
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/model/FinalWinner.kt`
+
+  > 실제로 domain 에서는 추상화를 통한 로직을 호출하고, 이를 통해 의존성을 분리하여 테스트를 가능하게끔 할 수 있죠. (interface를 테스트하는곳에서 override를 할 수 있다!)
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/model/RandomNumberGenerator.kt`
+
+## 얻은 교훈
+
+- **모델 = 상태 + 행동, Controller = 흐름 명령.** 체스판 비유처럼 모델이 게임 상태를 들고 있고 자기 규칙으로 행동한다. Controller는 "이 칸으로 움직여"라고 명령할 뿐. 흐름 제어를 모델이 안 갖는다는 게 핵심.
+- **"X-er"라는 절차적 명사 클래스는 항상 의심하라.** `FinalWinner`, `Generator`, `Handler`, `Manager` 같은 -er 접미사는 행위만 들고 상태가 없는 함수형 객체일 때가 많다. 그 행위의 진짜 주인이 누구인지 물어보면 보통 답이 나온다.
+- **무작위는 도메인 밖.** Random/Clock/HTTP 같은 외부 자원은 도메인이 직접 의존하면 도메인 테스트가 비결정적이 된다. 인터페이스로 추상하고 주입.
+- **세 후보 제시법** — 좋은 리뷰어 패턴: "A vs B vs C"로 후보를 보여주면 학생이 스스로 비교/선택할 수 있다. "정답은 X"보다 학습 효과가 크다.
+- **현실 비유의 강력함과 한계.** 체스판/마트/주차장 같은 비유는 책임 위치 발견의 첫 도구. 단, 비유에 멈추지 말고 "객체에게 메시지를 보낸다"는 추상으로 한 발 더 가야 OOP가 된다.

package/lessons/woowacourse-racingcar/songpink/98-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 #98 — [자동차 경주 구현] 알송 미션 제출합니다
+
+- **Reviewee:** [@songpink](https://github.com/songpink)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/98
+- **단계:** 1단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 34
+
+## 잘한 점 (설계 관점)
+
+- **`Car`에 움직이는 책임을 부여한 시도** — 리뷰어가 "움직임 책임을 자동차에게 완전히 부여했네요 👍"라며 명시적 칭찬.
+- **상수화 의도 자체는 명확** — Settings/Ranges로 매직 넘버를 추출하려는 노력. (위치 선택이 다음 토론)
+- **PR description에 자기 의문 제기** — "moveRange가 아니라 move여도 의미 전달이 되는가" 같은 메타 질문 적극.
+- **리뷰 흐름에 대한 솔직한 응답** — 시간 부족, 누락 등을 인정하고 다시 요청하는 태도.
+
+## 못한 점 (설계 관점)
+
+- **`Run.fun()` 메서드가 비대 — 모든 책임이 한 함수에** — 사용자 입력 + 검증 + 게임 진행 + 결과 출력이 한곳에 있어 객체지향이 아니라 절차적 모놀리스.
+- **`Ranges` / `Settings`라는 정적 상수 컨테이너 클래스** — 재사용되지도 않는데 public으로 열어 사용처 모두가 결합. 도메인 위치를 잃은 데이터.
+- **`Ranges.move`처럼 추상적 이름** — 무엇의 범위인지 사용자가 모름. 도메인 어휘를 잃은 네이밍.
+- **`ExceptionHandling`이 boolean 반환하는 검증기** — 검증은 throw로 끝나야 호출자가 분기를 안 만든다. boolean 반환은 호출자에 제약을 만듬.
+- **검증이 Controller 안에서 직접 일어남** — 입력 경계(InputView)나 도메인 객체(Car)가 아니라 흐름 제어자가 invariants를 들고 있음.
+- **`Car`가 `var` 프로퍼티** — 외부에서 값을 바꿀 수 있는 상태. 캡슐화 미흡.
+- **최종 우승자 출력 + 라운드 횟수 처리가 같은 함수에** — 두 책임의 결합.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae는 두 가지 큰 메타 가이드를 일관되게 제시한다.
+
+1. **"객체스럽게 사용하라"** — Car 객체에 매세지를 보내 스스로 판단하게 한다는 원칙(slipp 글 인용). 상태를 꺼내 로직을 처리하는 절차적 사고를 깨는 방향.
+2. **"검증은 책임 분리의 시작"** — Validation은 검증만 한다(정상 진행 or throw), 재입력 같은 흐름은 호출자의 일이다. 마트 비유로 키오스크/스캐너/모니터의 분리를 설명.
+
+또한 매직 넘버에 대한 가이드를 단순 "상수화 무조건"이 아니라 **"의미가 있을 때만 의미를 부여하라"** 는 식으로 균형 있게 제시.
+
+- **대표 인용:**
+  > 상태 데이터를 꺼내 로직을 처리하도록 구현하지 말고 객체에 메시지를 보내 일을 하도록 리팩토링한다. ... Car 객체에게 메세지를 던져 스스로 판단하고 결과값을 내게끔 하는게 객체를 객체스럽게 사용하는 방법이겠죠?
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/Car.kt:12`
+
+  > Validation(검증)을 하는 부분에서는 정상 동작이라면 진행, 예외 발생시 IllegalArgumentException 만 발생시키는게 담당 역할입니다. 그 이후에는 검증을 호출한곳에서 할일입니다.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/ExceptionHandling.kt`
+
+  > 우리가 마트를 가서 계산대에 물건을 올려놓았어요 ... 그럼 물건을 올려놓는 곳, 스캔하는 장치, 보여주는 모니터 모두 분리가 되어있는데 이것처럼 각자 할 일을 분리해볼까요?
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/Run.kt`
+
+## 얻은 교훈
+
+- **검증의 책임은 "정상 통과 또는 throw" 두 가지뿐.** 재입력/에러 표시는 호출자의 책임. 검증이 boolean을 반환하면 호출자가 if를 만들어 또 분기 결정을 해야 한다 — 결합도 증가.
+- **객체스러움 = 메시지로 일을 시킨다.** 객체의 상태를 꺼내서 외부가 가공하는 코드는 절차적이다. `car.move()`를 호출해 결과를 받는 것이 객체에게 자율성을 주는 가장 단순한 표현.
+- **상수의 자리는 그 도메인의 주인 곁.** "재사용되는가"가 첫 질문. 재사용되지 않으면 사용처의 private으로. 재사용되면 그 도메인의 companion으로.
+- **이름은 도메인 어휘를 살린다.** `move`보다 `moveCondition` 또는 `moveThreshold` — 이 변수가 무엇을 의미하는지 외부 컨텍스트 없이 보이게.
+- **함수 한 가지 책임 = 작은 함수.** "15라인 + 한 가지 일"이라는 우테코의 요구는 함수형 사고가 아니라 책임 분배의 첫 훈련. 큰 함수는 항상 책임 식별의 신호.
+- **현실 비유는 책임 분배의 1차 도구.** 마트의 키오스크/스캐너/모니터 비유처럼, 현실에서 누가 무엇을 하는지 그리면 객체 분리가 자연스럽게 따라온다 — 단, 비유에 갇히지 말고 메시지 모델로 한 단계 더 추상화할 것.

package/lessons/woowacourse-racingcar/sujin9/52-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 #52 — [자동차 경주] 수진 미션 제출합니다
+
+- **Reviewee:** [@sujin9](https://github.com/sujin9)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/52
+- **단계:** 2단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 13
+
+## 잘한 점 (설계 관점)
+
+- **`RacingCar`, `RacingGame`, `Validator`, `InputView`, `OutputView` 책임 분리**.
+- **상수 `Const`로 모음** (이후 학생이 분산).
+- **테스트 코드 명확성**.
+
+## 못한 점 (설계 관점)
+
+- **`Validator` 모호한 이름** → `InputValueValidator`로 변경 (god-object 위험).
+- **`Const.kt` 단일 파일에 모든 상수** — 응집도 낮음.
+- **`RacingCar`에 출력 형식 (toString) 보유** — OutputView 책임 침범.
+- **`maxOf` 미사용 (수동 비교)**.
+- **`it` 연속 사용으로 가독성 저하**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 핵심:
+
+1. **모호한 이름 = god-object의 신호** — Validator → InputValueValidator → "지금은 충분하지만, 더 세분화하면 오버엔지니어링."
+
+2. **상수의 자리 = 재사용성**. 한 곳만 쓰면 그 자리에. 여러 곳이면 파일 분리, 단 *공통 성격이 드러나는 이름*.
+
+3. **출력 형식 책임 = OutputView**. `toString()`이 도메인 모델에 들어가면 출력 변경 시 도메인 변경.
+
+4. **`maxOf` 같은 컬렉션 함수 적극 활용**.
+
+- **대표 인용:**
+  > 무엇을 검증하는지가 이름에 좀 더 드러나면 좋겠어요. 네이밍이 모호할수록 안티패턴인 god-object 가 되기 쉽다고 생각합니다.
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/domain/Validator.kt`
+
+  > 이부분은 '어떻게 그릴지'에 대한 내용이므로 OutputView 에서 수행하는 것이 적절하지 않을까요~?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/domain/RacingCar.kt`
+
+## 얻은 교훈
+
+- **모호한 이름 → god-object 위험**. "Manager", "Util", "Validator"는 무엇을 *Manage/Util/Validate*하는지 명시해야 함.
+- **상수의 응집도 = 사용처와의 거리**. 한 클래스에서만 쓰면 그 클래스의 companion object. 여러 곳이면 *목적별 파일*. `Const.kt`처럼 잡탕은 가장 나쁜 형태.
+- **toString의 함정** — 도메인에 두면 "도메인이 자기 표현 방식을 알아야 함" → 출력 변경이 도메인 변경. 백엔드 컨벤션은 OutputView로.

package/lessons/woowacourse-racingcar/sujin9/61-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,47 @@
+# PR #61 — [자동차 경주 - 리팩토링] 수진 미션 제출합니다
+
+- **Reviewee:** [@sujin9](https://github.com/sujin9)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/61
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 12
+
+## 잘한 점 (설계 관점)
+
+- **`_movingState` + custom getter (backing property)** — Kotlin idiom 도입.
+- **`InputValueValidator`로 이름 명확화**.
+- **상수 사용처에 분산**.
+- **확장 함수 적용** — `"89".isNumber()`.
+
+## 못한 점 (설계 관점)
+
+- **확장 함수가 `NumberValidator` 클래스 내부에** — top-level이 더 적합.
+- **`NumberValidator` 자체 책임 부재** — 확장 함수 호스팅하는 빈 클래스.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 메시지:
+
+1. **단일 책임 의문 자체가 경고 신호** — "클래스의 역할을 어디까지 세분화해야할지 고민되는 부분 자체가 SRP를 못 지키고 있는 신호일 수 있다."
+
+2. **확장 함수의 자리 = top-level** — `String.isNumber()`는 클래스 내부에 둘 필요 없음.
+
+3. **상수 파일의 *공통 성격 이름*** — `Const`보다 `MessageConst`, `LimitConst` 같이.
+
+4. **backing property** — `_xxx`/`xxx` 패턴이 Kotlin idiom. 단, 단일 변수 + custom setter로도 동일 효과.
+
+- **대표 인용:**
+  > 클래스의 역할을 어디까지 세분화해야할지 고민되는 부분 자체가 단일 책임 원칙을 지키지 못하고 있거나, 클래스 자체가 너무 커질 수 있는 잠재성을 가지게 되는 신호일수도 있다고 생각해요!
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/domain/InputValueValidator.kt`
+
+  > 해당 extension function 은 굳이 NumberValidator 내부에 존재하지 않아도 되고 NumberValidator 역할 자체도 현재는 무의미하므로 제거해도 괜찮아 보여요!
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/domain/validator/NumberValidator.kt`
+
+## 얻은 교훈
+
+- **"어디까지 분리할까"의 고민 자체가 SRP 위반 신호일 수 있다**. 자연스러운 책임 분리는 자명함. 고민이 길어지면 클래스가 잘못 나뉜 상태일 가능성.
+- **확장 함수의 자리 = top-level**. 클래스 내부 확장 함수는 *그 클래스의 멤버처럼* 동작하지만, 진짜 *유틸*이면 top-level이 깔끔.
+- **빈 클래스 (확장 함수만 호스팅)는 객체 아님**. 멤버 없이 함수만 있으면 그건 함수 모음 = top-level 또는 object.
+- **backing property** = `private var _xxx` + `val xxx: Type get() = _xxx`. Kotlin에서 외부 read-only + 내부 mutable의 표준 패턴.

package/lessons/woowacourse-racingcar/tmdgh1592/47-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,49 @@
+# PR #47 — [부나] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@tmdgh1592](https://github.com/tmdgh1592)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/47
+- **단계:** 1단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 38
+
+## 잘한 점 (설계 관점)
+
+- **생성자 주입과 기본값 활용** — 의존성을 명시적으로 받는 시도. 리뷰어가 명시적으로 칭찬.
+- **랜덤 결과를 `isMove` 형태로 변환해 노출** — 외부에 raw 난수를 흘리지 않고 의미 있는 boolean으로 변환한 점은 캡슐화 시도로 긍정적 (다만 Random 자체 의존은 남음).
+- **테스트 코드를 적극 작성** — 단순 happy path가 아니라 예외 상황까지 다루려는 시도.
+- **리뷰의 의도를 깊게 곱씹는 응답** — 단순 "수정했습니다"가 아니라 DTO 경계, Repository 필요성 등을 본인의 언어로 재정리한 긴 응답을 남김.
+
+## 못한 점 (설계 관점)
+
+- **`Random`에 대한 직접 의존** — `RacingService`가 `Random`을 직접 호출. 단위테스트에서 결과를 통제할 수 없음 (non-newable).
+- **`BlankRemover`, `Strings`, `Dimens`, `Validator` 같은 유틸 클래스가 산재** — 책임이 분산되고 강한 결합이 생기는 구조. 특히 `Validator`는 이름이 너무 광범위해 사용처가 모두 의존.
+- **`Validator` 같은 헬퍼 객체가 도메인 안에 살아 있음** — 검증을 별도 객체로 빼놓으니 "검증은 누가 하는가"가 흩어짐. 정작 도메인 객체(Car)는 자기 invariants를 안 지키는 무방비 상태.
+- **Controller → Service.createCars → Service.insertCars 절차 호출** — 외부가 service의 절차를 알고 순서대로 호출. Tell-Don't-Ask 위배.
+- **`getWinners` 테스트가 `insertCars`/`getAll`에 의존** — 다른 함수에 결함이 생기면 무관한 테스트도 깨짐. 테스트 격리 부족.
+- **private 함수를 테스트하려고 가시성을 풀어버림** — "테스트를 위한 코드"가 production 표면적을 늘리는 안티패턴.
+- **View 표시용 문자열("-" 등)이 Model 안에서 만들어짐** — View가 알아야 할 표현 책임이 도메인으로 새어 들어옴.
+
+## 리뷰어 의견 요지
+
+리뷰어 @namjackson은 **"Random에 대한 강한 의존"** 과 **"Service에 메시지로 위임"** 을 반복적으로 짚었다. 또한 유틸성 클래스(Validator, BlankRemover)가 만드는 분산된 책임과 결합도 경고. 테스트 관점에서는 (1) 다른 함수에 의존하는 테스트의 취약성, (2) private 함수 노출이 테스트 설계의 신호임을 강조.
+
+- **대표 인용:**
+  > Random클래스에 대한 강한 의존이 생겼네요! Random함수는 테스트하기가 어렵습니다. 의존도를 줄일수 있는 방법을 고민해보시면 좋을거같아요!
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/service/RacingService.kt`
+
+  > racingService에게 메세지를 주어 해당 기능을 하도록 책임을 위임해보면어떨까요?
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/controller/RacingController.kt:16`
+
+  > 테스트를 위한 함수나, 테스트를 위한 코드는 지양해주세요! 해당 함수를 공개하지않고 테스트할수 있는 방법을 고민해보시면 좋을것 같아요!
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/service/RacingService.kt:10`
+
+## 얻은 교훈
+
+- **테스트하기 어려운 코드는 설계의 신호다.** Random/Clock 같은 외부 자원은 인터페이스로 추상화하고 주입받으면, 도메인은 순수해지고 테스트는 결정적이 된다.
+- **유틸리티 클래스는 책임을 흩어놓는다.** "어디 두지 모를 때 임시로 뽑아 둔 자리"가 굳어지면, 모든 사용처가 그 유틸에 결합되어 더 이상 옮길 수 없게 된다. 검증 같은 invariant는 그 invariant를 가진 도메인 객체가 들고 있어야 한다.
+- **"createX 후 useX"는 메시지를 두 번 보내라는 신호가 아니다.** 외부가 객체의 절차를 알고 순서대로 호출한다면, 그 절차는 객체 내부로 들어가야 한다 (Tell-Don't-Ask).
+- **테스트는 다른 메서드를 거치지 않고 검증 대상에 도달할 수 있어야 한다.** 의존이 길어질수록 테스트는 다른 코드의 인질이 된다. 생성자 주입으로 격리하라.
+- **private 함수를 테스트하고 싶다면 그건 별개의 책임일 가능성이 높다.** 가시성을 푸는 대신, 그 책임을 별개의 클래스로 추출하는 편이 보통 더 옳다.

package/lessons/woowacourse-racingcar/tmdgh1592/64-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,53 @@
+# PR #64 — [부나] 2단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@tmdgh1592](https://github.com/tmdgh1592)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/64
+- **단계:** 2단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **이전 라운드 피드백을 구조 변경으로 흡수** — Repository 레이어 제거, `CarName`/`CarsDto` 등 값 객체화·DTO 분리를 직접 단행.
+- **검증이 필요한 원시값을 객체로 감쌈** — `CarName`처럼 도메인 invariants를 들고 있는 값 객체를 도입해 원시 강박을 해소하려는 시도.
+- **Fake 객체로 Mock 라이브러리를 대체** — 테스트 더블에 대한 이해를 행동으로 옮긴 모범 사례. `CarMoveCondition` 인터페이스 + `FakeForSuccess`/`FakeForFailed` 구현.
+- **OCP를 의식한 전략 추상화** — `CarMoveCondition`, `MoveStep`(sealed) 등 변화 가능 지점을 인터페이스로 격리한 시도.
+- **리뷰의 의도를 본인 언어로 깊게 곱씹음** — 단순 적용이 아니라 자신이 어떻게 이해했는지 길게 정리하며 토론을 끌어감.
+
+## 못한 점 (설계 관점)
+
+- **Domain Model이 DTO를 알고 있음** — `Car`가 `CarDto`에 의존. 레이어 경계가 새고, 도메인이 외부 형식의 변화에 끌려다니게 됨.
+- **인터페이스 이름에 구현 단서가 박힘** — `RandomGenerator`처럼 "어떻게 만드는가"가 인터페이스 이름에 들어가면, 구현이 바뀌면 이름이 무의미해짐. 추상은 "무엇을 한다"로.
+- **"이동 결정"의 책임 위치가 흔들림** — `Cars`가 `generateNumber`를 가지면서, Car는 단지 받은 수를 비교만 함. "전진할지 말지"의 의사결정 주체가 모호.
+- **YAGNI 위배 가능성 — 과한 사전 추상화** — `MoveStep` sealed로 0/1만 표현하는데 이미 두 클래스를 만듦. 가변성이 실제로 들어왔을 때 추가하는 편이 보통 더 안전.
+- **Fake 객체가 production 패키지에 위치** — 실 배포 코드에 테스트용 구현이 섞이면 production 의존 그래프가 오염.
+
+## 리뷰어 의견 요지
+
+리뷰어 @namjackson은 이 라운드에서 두 가지 큰 주제를 짚었다.
+
+1. **추상화의 의도** — 인터페이스 이름이 "어떻게"를 노출하지 말 것(`RandomGenerator` → `NumberGenerator`), Fake를 production 패키지에 두지 말 것.
+2. **책임의 진짜 자리** — `Cars`가 number를 생성하면서 Car가 받기만 한다면 "Car 자신의 의사결정"이 사라진다는 점. 그리고 변화 가능성(자동차마다 다른 조건, 이동 거리 다름)을 예로 들어 "어디에 책임을 두면 변화에 유연한가"를 묻는 식.
+
+또한 YAGNI를 명시적으로 언급 — "변경 예상해 미리 짜는 것보다, 책임을 잘 나눈 코드 + 테스트가 더 큰 안전망."
+
+- **대표 인용:**
+  > 인터페이스에서는 Random으로 생성된다는 정보를 포함하는게 좋은 방법일까요? 해당 인터페이스의 주요기능은 Number를 generate해주는것이지, 해당 Number가 Random으로 발생하는지, 일정한 Number가 발생하는지는 해당 인터페이스를 구현한 클래스의 책임이지 않을까욤?
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/utils/random/RandomGenerator.kt`
+
+  > number를 가지고 전진할지 말지에 대한 책임은 어디에 있는것이 좋을까요? Car가 움직이는 기준이 랜덤번호가 아닌 다른 방법 변경된다면, Car마다 움직이는 기준이 달라진다면, Car마다 한번에 이동하는 거리가 달라진다면, 어떤구조가 좀더 유연하게 대처할수 있는 구조가 되고...
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/service/RacingService.kt`
+
+  > YAGNI ... 확장을 예상해서 오버 엔지니링하여 구현하게되면, 예상된 확장이 아닌 경우, 더 안좋은 결과가 나올수도 있어요!
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/service/RacingService.kt`
+
+## 얻은 교훈
+
+- **추상의 이름은 What이지 How가 아니다.** "Random"이라는 구현 단서가 인터페이스명에 들어가는 순간, 그 추상은 잠재적 구현 한 가지에 종속된다. `NumberGenerator`라고 부르면 fake/random/sequential이 모두 자연스럽다.
+- **레이어 사이는 단방향 의존이어야 한다.** Domain은 DTO를 모르고, DTO만 도메인 객체로 매핑하는 mapper가 경계를 책임진다. 도메인이 DTO를 알면 외부 형식이 바뀔 때마다 도메인이 흔들린다.
+- **OCP는 예측이 아니라 신호에 답한다.** 한 가지 변화 가능성을 미리 추상화하는 것은 종종 YAGNI 위반이다. 실제로 두 번째 변형이 등장할 때 추상화하면, 추상의 형태가 자연스럽게 결정된다.
+- **Fake는 production 코드가 아니다.** 테스트 패키지(`src/test/...`)에 두어야 production 의존 그래프가 깨끗해진다. "정 안 되면 mock 라이브러리"라는 현실적 가이드도 함께 기억할 것.
+- **테스트가 좋으면 미래의 자유가 늘어난다.** 변경에 닫혀 있고 확장에 열린 구조를 미리 만드는 것보다, **책임 분리 + 빠른 테스트**가 리팩터링의 자유를 더 많이 만든다.

package/lessons/woowacourse-racingcar/tobae-time/151-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,51 @@
+# PR #151 — [자동차 경주 구현] 토바에 미션 제출합니다
+
+- **Reviewee:** [@tobae-time](https://github.com/tobae-time)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/151
+- **단계:** 1단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 25
+
+## 잘한 점 (설계 관점)
+
+- **`Racecourse`로 도메인 객체화** — 레이스 준비물을 받음. 리뷰어 칭찬.
+
+## 못한 점 (설계 관점)
+
+- **`!!` 사용** — 검증 함수가 따로 있다고 안심하지 말 것. 함수 로직이 바뀌면 NPE.
+- **`Main.kt`가 비대** — 입력 + 가공 + 검증 + 실행.
+- **`Car`가 너무 많은 일** — 랜덤 생성 + 움직임 판단 + 전진 + 결과 출력.
+- **`Car`에 hashCode/equals 도메인 필요 없이 구현**.
+- **`Car`가 표시용 String 생성** — View 책임 침해 ("-".repeat(distance) 같은 표시 함수).
+- **`ApplicationTest`에 모든 테스트** — Main/Car/Racecourse 전부 한 파일.
+- **테스트가 "전진 가능 vs 불가" 케이스 분리 안 됨** — 개발자 실수 검증 어려움.
+- **테스트 이름이 결과를 안 드러냄**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @hyemdooly는 **"개발자 실수 검증 가능한 테스트"** 라는 본질 질문 — "자동차가 무조건 전진만 하거나 무조건 멈춘다면 이 테스트가 잡아낼까?" 이 질문 한 줄이 테스트의 가치를 진단.
+
+또한 **`!!`의 위험** — 검증 함수가 따로 있어도 그 로직이 바뀌면 NPE. 안전성에 대한 false sense.
+
+**Car가 액션을 너무 많이 함** — 객체 책임 단위 분해 가이드.
+
+- **대표 인용:**
+  > 개발자의 실수로 현재 코드가 자동차가 무조건 전진만 하거나, 멈출 수 밖에 없다면 이 테스트 코드는 개발자의 실수를 검증할 수 있는 테스트 코드일까요?
+  >
+  > — @hyemdooly on `src/test/kotlin/ApplicationTest.kt`
+
+  > 차가 직접 랜덤 수를 생성하고, 움직일 수 있는지 판단하고, 전진도 하고, 결과값을 출력도 하고 있네요! 액션을 더 잘게 나눠볼 수 있을까요?
+  >
+  > — @hyemdooly on `src/main/kotlin/Car.kt`
+
+  > `checkRoundValid` 함수로 검사를 한번 해줬더라도, 만약 이 함수의 로직이 바뀐다면 `readRound`에서 Exception이 발생할 가능성이 생기게 됩니다.
+  >
+  > — @hyemdooly on `src/main/kotlin/Main.kt`
+
+## 얻은 교훈
+
+- **테스트의 본질 = 실수 잡기.** "이 코드가 의도와 다르게 동작하면 이 테스트가 알려주는가?"가 핵심 질문. 그렇지 않으면 테스트는 검증이 아니라 동어반복.
+- **`!!`는 false sense of safety.** "이미 검증했으니 안전"이라는 가정은 그 검증 로직이 바뀔 때 깨진다. nullable 처리는 코드 위치에서 항상 명시적.
+- **Car가 많은 액션 = 책임 분배 신호.** "랜덤 + 결정 + 이동 + 출력"이 한 객체면 (1) 단위 테스트 어려움, (2) 변경 영향 큼, (3) Tell-Don't-Ask 깨짐. 단위로 분리.
+- **`"-".repeat(distance)` 같은 표준 도구.** Kotlin 표준 함수가 가독성 + 안전.
+- **테스트 파일 분리 = 클래스 분리의 거울.** Application에 모든 테스트가 있으면 production도 분리 안 됐을 가능성.

package/lessons/woowacourse-racingcar/tobae-time/167-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 #167 — [자동차 경주 2단계] 토바에 미션 제출합니다
+
+- **Reviewee:** [@tobae-time](https://github.com/tobae-time)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/167
+- **단계:** 2단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 6
+
+## 잘한 점 (설계 관점)
+
+- **잘못된 값 반복 처리를 Controller로** — 리뷰어 칭찬.
+- **InputView/OutputView 분리** — 1단계의 통합 패턴 정리.
+
+## 못한 점 (설계 관점)
+
+- **`Racecourse`가 출력 책임** — View 침해 잔존.
+- **`Controller` 내부에서 InputView/OutputView 생성** — 외부 주입이 더 자연스러움.
+- **`dooly,hyem` 정상 입력이 예외 처리됨** — 공백/길이 검증 로직 오류.
+- **`@get()` 커스텀 프로퍼티 vs 함수 — 학생의 결정 기준 부재**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @hyemdooly는 **외부 주입을 통한 캡슐화** — Controller 내부에서 InputView 생성하지 말고 외부에서 받기. 그렇게 하면 외부가 View에 직접 접근할 필요 없는 구조.
+
+또한 **검증 케이스의 실제 테스트** — `dooly,hyem`처럼 정상 케이스가 실패하는 버그 발견. 케이스 분리 부족.
+
+`get() 커스텀 프로퍼티` vs 함수 차이 — 학생이 그 차이를 인지하고 의도적으로 선택하는 훈련.
+
+- **대표 인용:**
+  > Controller 내부에서 InputView와 OutputView를 생성하고 있네요 🤔 외부에서 생성하고 받아올 수 있을까요? 외부에서는 이 뷰들을 사용할 수 없게하면 더 좋겠어요!
+  >
+  > — @hyemdooly on `src/main/kotlin/racingcar/controller/RacingCarController.kt`
+
+  > `dooly,hyem`와 같이 입력하면 정상케이스인데 `자동차 이름은 5자를 초과하거나 공백일 수 없습니다. 다시 입력해주세요.`라는 메시지가 출력돼요.
+  >
+  > — @hyemdooly on `src/main/kotlin/racingcar/view/InputView.kt`
+
+## 얻은 교훈
+
+- **검증 로직의 실제 테스트.** 정상 케이스가 실패하는 버그는 검증 로직의 단위 테스트 부족 신호. 도메인 invariants를 production 코드와 테스트가 같이 합의해야.
+- **외부 주입의 두 가지 효과.** (1) 테스트에서 페이크 주입, (2) 외부가 그 객체에 직접 접근하지 않는 캡슐화. 후자가 종종 간과됨.
+- **`get() {}` vs 함수의 차이.** 프로퍼티는 데이터 접근, 함수는 행위. `winners`가 컬렉션 반환 = 상태 같지만 매번 계산이라면 함수가 더 명확.
+- **이전 라운드의 흡수 정도.** 1단계 코멘트가 일부 그대로 재등장 (Racecourse 출력 등) — 학습이 부분적이라는 신호.