oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/pingu244/38-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,58 @@
+# PR #38 — [핑구] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@pingu244](https://github.com/pingu244)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/38
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **require 적극 활용** — 검증 표현이 깔끔.
+- **`NumberGenerator` SAM 인터페이스 도입** — 무작위 격리 의도.
+- **`util.Constants`로 상수 모음 시도** — 하드코딩 분리는 의식적.
+- **`Player`로 도메인 모델링 시도** — 자동차를 다루는 주체 추상화.
+
+## 못한 점 (설계 관점)
+
+- **`Player`라는 중간 객체가 너무 많은 일을 함** — Game이 Car를 움직이기까지 거치는 단계가 과다. `Player`가 정말 필요한가에 대한 정당화 부족.
+- **외부에서 Car를 직접 조작** — Player가 Car의 상태를 보고 움직임 결정. Tell-Don't-Ask 위반 — `car.move()` 후 결과를 받으라는 가이드.
+- **`util.Constants`** — 결합도 안티패턴.
+- **`util.Extension`이 OutputView 전용 기능** — 그 객체의 확장함수로 두는 게 응집도.
+- **축약어 사용** — `View.kt`의 변수명 등.
+- **빈 리스트에 반복문 채우기 패턴** — 함수형 표현(`map`/`filter`)으로 의도 표현 가능.
+- **`RacingNumberGenerator`를 매 호출마다 새로 생성** — 한 번 만들고 재활용 가능.
+- **`CarMovingTest`라는 별도 테스트 클래스** — 테스트 클래스명-Test 컨벤션 위반.
+- **테스트 패키지 경로 production 미러링 누락** — 테스트가 어디에 있는지 빨리 찾기 어려움.
+- **테스트의 fake Generator가 랜덤 반환** — 결정성을 잃은 페이크.
+- **Exception 종류/메시지 검증 누락** — 어떤 예외인지 확신 못함.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 **"Player가 정말 필요한가?"** 라는 본질 질문을 짚었다. 객체를 새로 만들기 전에 "이 객체의 존재 이유가 무엇인가"를 먼저 묻는 식. 또한 **"외부에서 조종 vs 메시지로 시키기"** 라는 객체지향 기초도 짧고 명확하게.
+
+테스트 측면에서는 (1) SAM 인터페이스를 람다로 활용, (2) 페이크는 결정적 값 반환, (3) Exception 종류/메시지 검증의 세 가지 가이드.
+
+`CarMovingTest` 같은 별도 테스트 클래스 분리에 대해서도 "Car의 테스트인가, CarGenerator의 테스트인가?"라고 짚어 책임 분리의 거울임을 짚는다.
+
+- **대표 인용:**
+  > Player가 너무 많은 일을 맡고 있어요. 먼저, Player라는 객체가 정말 필요한지 먼저 고민해보셨으면 좋겠어요.
+  >
+  > — @malibinYun on `src/main/kotlin/data/CarRacingGamePlayer.kt`
+
+  > 외부에서 car를 조종하는 것 보다, car에게 메시지를 던져서 움직였는 지에 대한 유무를 받아보는 것은 어떨까요?
+  >
+  > — @malibinYun on `src/main/kotlin/data/CarRacingGamePlayer.kt`
+
+  > 이 파일은 Car의 테스트일까, CarGenerator의 테스트일까? `유효하지 않은 자동차 이름을 확인`하는 것은 어느 테스트 코드의 역할일까?
+  >
+  > — @malibinYun on `src/test/kotlin/CarTest.kt`
+
+## 얻은 교훈
+
+- **"이 객체가 정말 필요한가?"는 새 객체 생성의 첫 질문.** Player 같은 매개 객체가 모델을 풍부하게 만드는지 아니면 단지 단계를 늘리는지 구분. 단계만 늘리면 절차적 사고로 되돌아간 신호.
+- **객체 조종 vs 메시지 던지기.** 외부에서 객체의 상태를 보고 조건 분기를 하면 캡슐화가 깨진다. `car.move()` 후 결과(boolean)를 받으면 결정이 객체 안으로 들어간다.
+- **유틸 확장함수의 자리 = 그 사용자의 곁.** `Extension.kt`가 OutputView 전용이면 OutputView의 확장으로. 공유 유틸은 결합도의 시작.
+- **테스트 클래스명 = Production 클래스명 + Test.** `XxxMovingTest`처럼 동작 단위로 분리되면 production 클래스가 그 동작 단위로 책임을 다양하게 가진다는 신호.
+- **테스트 페이크는 결정적이다.** 결정 가능한 fake가 의미. 페이크가 랜덤이면 페이크의 가치가 없다.
+- **메서드 체이닝은 의도의 표현.** `filter.map`처럼 도메인 의도가 시퀀스로 드러나면 빈 리스트 + 반복문보다 가독성이 높다 — 절차적 사고를 함수형 표현으로.

package/lessons/woowacourse-racingcar/pingu244/62-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 #62 — [핑구] 2단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@pingu244](https://github.com/pingu244)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/62
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **`PathState` 도입으로 표현 명시화** — 매직 String 대신 enum-like 추상.
+- **`Referee` 분리** — 우승자 판별 책임을 별개로.
+- **테스트에서 equals/hashCode 학습** — `==`가 주소 비교임을 깨닫고 Car에 오버라이딩. 객체 동일성/동등성 차이 이해.
+- **결정적 페이크로 테스트** — 1단계의 랜덤 페이크에서 진보.
+
+## 못한 점 (설계 관점)
+
+- **`Initialize`라는 동사형 클래스 이름** — 명사형이 객체 모델링에 자연스러움.
+- **`PathState`가 도메인이면서 View용 문자열까지 들고 있음** — 도메인이 표현을 알게 됨.
+- **`InputRefinement`가 입력 가공 + Car 반환의 다중 책임** — "가공"이라는 이름과 "Car를 만든다"는 행위가 어긋남.
+- **`InputRefinement`가 시도 횟수까지 반환** — 호출자가 거쳐갈 단계를 만들고 또 거쳐가는 식의 우회.
+- **`numberOfTry`가 `carPath.size`와 중복** — 같은 정보를 두 군데에서 들고 있음.
+- **테스트 매직 리터럴 상수화** — 테스트는 오히려 인라인이 가독성에 좋음.
+- **NumberGenerator를 익명 클래스로 override** — SAM이라 람다로 충분.
+- **빈 리스트 + 반복문 채우기 패턴** — 함수형 표현으로 단순화 가능.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 **객체 동일성/동등성** 의 본질 질문을 잘 끌어냈다. "Car("1") == Car("1")"이 어떤 값을 비교하는가? 학생이 답에 도달한 후 "equals/hashCode 오버라이드가 테스트만을 위한 코드인가?"라는 질문에는 "이름과 위치가 같으면 동일 자동차"라는 도메인 의미를 함께 제시 — 즉, 그것은 도메인의 일.
+
+또한 **테스트에서의 매직 리터럴은 인라인이 낫다** 는 반대 가이드: production은 상수가 가독성, 테스트는 인라인이 가독성. 이 이중성을 명확히 설명.
+
+`InputRefinement`처럼 이름과 책임의 어긋남, `numberOfTry`의 중복 같은 작은 결함도 정확히 짚어낸다.
+
+- **대표 인용:**
+  > `Car("1") == Car("1")`를 실행할 때, ==는 어떤 값을 비교하고 있을까요?
+  >
+  > — @malibinYun on `src/test/kotlin/model/generator/CarGeneratorTest.kt`
+
+  > 저는 이름이 같고 동일 거리에 있는 자동차라면 동일 자동차라고 생각해요 ... 해당 메서드들을 직접 오버라이드 하는 것이 비단 테스트 만을 위한 코드라고 생각하진 않아요.
+  >
+  > — @malibinYun on `src/test/kotlin/model/generator/CarGeneratorTest.kt`
+
+  > 테스트에서는 매직 리터럴들을 상수로 분리할 필요가 없다고 생각해요. 오히려 어떤 값이 들어가는 지 아래에서 보고 와야하기에 가독성을 해질 수 있다고 생각해요.
+  >
+  > — @malibinYun on `src/test/kotlin/domain/CarRacingGameTest.kt`
+
+  > 이 객체는 각기 다른 일들을 맡고있어 보여요. 입력 값 가공기인데, Car를 반환하는 것은 다소 어색해보입니다.
+  >
+  > — @malibinYun on `src/main/kotlin/domain/InputRefinement.kt`
+
+## 얻은 교훈
+
+- **동일성(identity) vs 동등성(equality).** `==`는 주소(JVM에서는 참조), `.equals()`는 내용. 도메인 객체의 동등성을 정의하는 것은 테스트의 필요가 아니라 도메인의 의미. "내용이 같으면 같은 차"라는 도메인 결정.
+- **production vs 테스트에서의 가독성 다름.** Production은 의도가 상수에 담겨야, 테스트는 데이터가 인라인에 보여야 — 테스트는 시나리오를 보여주는 게 본질이라 데이터가 명시될수록 좋음.
+- **이름과 책임의 일치 검사.** `InputRefinement`라는 이름은 "입력 가공" — Car 반환은 그 책임 밖. 이름과 동작이 어긋나면 호출자가 우회 경로를 만든다.
+- **중복된 정보의 신호.** `numberOfTry` + `carPath.size`가 같은 의미라면 한쪽은 제거. 두 군데에서 들고 있으면 둘이 어긋나는 버그가 생긴다.
+- **SAM 인터페이스 → 람다.** `object : NumberGenerator { override fun ... }`보다 `NumberGenerator { ... }` 람다가 의도 더 명확. 키워드의 무게가 줄어들면 의도가 보인다.
+- **클래스 이름은 명사.** `Initialize` → `Initializer` 또는 더 좋게는 그 책임의 본질을 가진 명사. 동사는 함수.

package/lessons/woowacourse-racingcar/re4rk/28-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 #28 — [아크] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@re4rk](https://github.com/re4rk)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/28
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`NumberGenerator` 인터페이스 도입** — 무작위 격리.
+- **ParameterizedTest 활용** — 여러 케이스 표현.
+- **자기 의문 적극 제기** — 멤버 변수 vs 함수 인자 trade-off 등.
+- **리뷰 반영 빠름** — Controller의 생성자 주입, `assertDoesNotThrow` 도입 등.
+
+## 못한 점 (설계 관점)
+
+- **`resources/String.kt`로 모든 문자열 모음** — 안드로이드 리소스 비슷한 패턴, 결합도 증가의 시작.
+- **`Car`가 0~9 무작위 범위를 알게 됨** — 자동차의 관심사가 아닌 무작위 표현.
+- **`GameController.racingManager`가 lateinit + 멤버** — 라이프사이클 1회 게임이라면 함수 지역 변수.
+- **`RacingManager`가 cars/racingCount를 멤버로** — 함수 인자로 받는 게 자연스러움.
+- **`InputView.getCarNames()`가 빈 입력 시 `listOf("")` 반환 가능** — 비어있음의 표현이 모호.
+- **`OutputView`가 `List<Car>`를 받지 않음** — domain 의존을 끊으려고 했지만 표시할 데이터를 다른 형식으로 받음.
+- **`MIN_NUMBER`, `MAX_NUMBER` 같은 파라미터 대문자 명명** — 코틀린 컨벤션 위반.
+- **테스트 이름 명확성 부족** — "정상 동작"의 의미 모호.
+- **커밋이 코드 + 테스트 분리** — 하나의 기능 = 구현 + 테스트가 세트.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **"한 기능 = 한 커밋 (구현 + 테스트)"** 라는 강한 가이드. 분리 커밋은 롤백 시 하나 이상을 되돌려야 하는 문제.
+
+또한 **"도메인 우선 구현"** — InputView부터 짜면 도메인이 등장할 때 InputView가 다시 바뀜.
+
+`Car`가 0~9를 아는 것에 대해서는 **"자동차의 관심사가 0~9인가?"** 라는 즉시 통증을 짚는 질문.
+
+`RacingManager`의 멤버 변수에 대해서는 **"라이프사이클 1회 게임이라면 함수 인자가 더 단순"** 이라는 가이드, 결과 객체 반환 패턴까지 제시.
+
+학생의 적극적 자기 회고("멤버 변수로 안 되는 것일까요?")에 명확히 응답하는 토론 흐름도 인상적.
+
+- **대표 인용:**
+  > 자동차의 입장에서, 0부터 9 사이라는 값이 관심사일까요? 0부터 9 사이라는 값을 자동차의 책임으로 보는게 맞을지 생각 해 볼 수 있겠습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/domain/Car.kt`
+
+  > racingManager가 멤버 변수, 그리고 lateinit으로 작성될 필요가 있을까요? 하나의 게임에서 하나의 RacingManager 인스턴스를 활용하고 있어요.
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+  > 하나의 기능은 구현 코드와 테스트 코드가 세트라고 생각해주시면 됩니다!
+  >
+  > — @laco-dev on `src/test/kotlin/racingcar/domain/CarTest.kt:11`
+
+## 얻은 교훈
+
+- **한 기능 = 구현 + 테스트 (한 커밋).** 둘이 분리되면 롤백/리뷰 단위가 흐려진다. 기능의 시작과 끝이 한 커밋에 갇히는 게 가장 깨끗한 단위.
+- **객체의 관심사 = 그 객체가 알아야 하는 것.** Car에 0~9 범위가 박히면 자동차가 무작위 표현을 안다. 그 결정은 다른 곳으로.
+- **라이프사이클 = 변수의 자리 결정.** 1회 게임 = 함수 호출 1회면 함수 지역 변수. 라이프사이클이 객체보다 짧으면 멤버일 필요 없음.
+- **빈 값의 표현 = 도메인 결정.** `listOf("")`가 "비어 있음"을 의미하는지 "빈 이름 하나"를 의미하는지 모호. 명확한 표현(`emptyList()`/`null`/예외) 선택.
+- **유지보수 vs 적절성.** 학생이 "추후 Car 검사를 위해 0~9 검증을 둔다"는 정당화를 했지만, 리뷰어는 그 위치 자체에 의문 — 검증 위치는 책임 분배의 결정이지 유지보수 옵션이 아님.
+- **자기 의문이 학습의 정점.** "...안 되는 것일까요?"라는 질문은 리뷰어가 더 깊은 가이드를 줄 기회. 단순 반영보다 질문이 학습을 가속.

package/lessons/woowacourse-racingcar/re4rk/55-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 #55 — [아크] 2단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@re4rk](https://github.com/re4rk)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/55
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 15
+
+## 잘한 점 (설계 관점)
+
+- **`CarFactory` 도입으로 Car 생성 책임 분리** — (다만 책임 범위는 다음 토론).
+- **`RaceResult` 도메인 객체** — 결과를 일급 객체로.
+- **Mapper를 확장 함수로 정리** — `raceResult.toDto()`. 리뷰어 칭찬.
+- **`StepResult` 도입으로 의미 부여** — `List<List<Int>>` 같은 모호 타입을 도메인 객체로.
+
+## 못한 점 (설계 관점)
+
+- **`CarFactory`의 책임 범위 모호** — 생성만? 이동도? 결과 만들기까지? 이름은 Factory인데 범위는 불분명.
+- **`RaceInfo`라는 모호한 이름** — Info 접미사는 일반어. 결합 데이터의 의미가 안 드러남. 리뷰어는 차라리 파라미터 2개 명시가 낫다고 평가.
+- **`Cars` 일급 컬렉션이 우승자 찾기에 복잡** — 생성 시 Car에 location을 받을 수 있는 구조가 더 단순한 테스트.
+- **`StepResult`가 자동차 이름과 별개로 위치만 가짐** — 라운드 = (자동차, 위치) 세트가 자연스러움.
+- **GameController 패턴 답 미흡** — 1단계 멤버 변수 가이드의 적용이 일부 우회로 (RaceInfo 데이터 클래스).
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **"파라미터 두 개 vs 데이터 클래스 래퍼"** 의 trade-off를 명확히 제시. 학생이 파라미터 두 개를 피하려고 `RaceInfo`를 만들었지만, 리뷰어는 (1) Info 같은 일반어 회피, (2) Controller 내부에서만 쓰이는 결합 = 파라미터 두 개가 더 간결하다는 결론.
+
+또한 **`Cars(carNames: List<String>)` 정적 팩토리 vs `Cars(List<Car>)` 주생성자** 패턴을 제시 — 테스트 시 위치 지정한 Car들을 직접 넘기는 단순함의 가치.
+
+`Mapper`를 생성자로 받을 필요 없이 **확장 함수 또는 정적 메서드** 사용 가이드.
+
+`StepResult.name 포함` — 라운드의 결과가 (자동차, 위치) 세트라는 자연스러운 묶음.
+
+- **대표 인용:**
+  > Info라는 이름은 그만큼 난해한 이름이 된다는 뜻이 됩니다. 결국 컨트롤러 안에서만 사용되는 개념이라서, 파라미터로 두개를 넘기는게 훨씬 간결하지 않을까? 라는 결론입니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+  > CarFactory의 역할은 무엇인가요? 자동차를 생성만 하는 역할인가요? 자동차를 생성도하고 이동도 시키고 결과도 만들고 출력도 하는 역할인가요?
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/domain/CarFactory.kt`
+
+  > StepResult에서 name을 같이 가지고 있어도 되지 않을까요? 하나의 라운드에서 자동차, 위치가 하나의 세트로 생각이 듭니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racingcar/domain/raceresult/RaceResult.kt`
+
+## 얻은 교훈
+
+- **파라미터 합치기 vs 그대로 두기.** 두 파라미터를 데이터 클래스로 묶으면 시그니처는 짧지만 데이터 클래스에 이름을 줘야 한다. 그 이름이 일반어(Info, Data)면 묶지 않는 게 낫다. 도메인 의미가 있는 묶음일 때만 합치기.
+- **Factory의 역할 범위 명시.** Factory가 생성만 하는지, 생성 + 다른 일까지 하는지 이름만으로 안 보이면 책임 모호. 단순 생성이면 `Cars.create(...)` 같은 정적 메서드로 충분.
+- **일급 컬렉션의 생성자 = 주된 입력.** `Cars(cars: List<Car>)`가 주생성자, `Cars(carNames: List<String>)`가 보조생성자 또는 정적 팩토리. 테스트가 자연스러운 쪽이 주생성자.
+- **`Info` / `Data` / `Wrapper` 같은 접미사는 도메인 어휘 부재의 신호.** 더 구체적인 도메인 이름을 찾으면 그 이름이 정체성. 못 찾으면 묶지 말 것.
+- **묶음의 자연스러움.** (자동차, 위치)는 라운드 결과의 자연스러운 세트. 분리되면 호출자가 두 인덱스를 동기화해야.
+- **이전 라운드 가이드를 다음에 변형 적용한 흔적.** 1단계 "멤버 변수 줄여라" → 2단계에서 `RaceInfo`로 우회. 학습이 완전히 닫히지 않은 신호 — 리뷰어가 다시 짚어 학습 완료.

package/lessons/woowacourse-racingcar/rhkrwngud445/42-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 #42 — [코비] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@rhkrwngud445](https://github.com/rhkrwngud445)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/42
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`RacingGame` 도메인 객체** — 경주 진행을 모델.
+- **InputView 분리** — View 책임 의식.
+
+## 못한 점 (설계 관점)
+
+- **"뼈대 코드 작성" 커밋** — 기능별 커밋이 아닌 우회.
+- **테스트 코드를 별도 커밋** — 기능 = 구현 + 테스트가 세트.
+- **`RacingCarController` 멤버 변수(racingGame, maxMoveCount)** — 한 게임 라이프사이클이면 함수 지역.
+- **Controller가 InputView용 메시지 출력** — UI 관심사 침해.
+- **`initRacing()` 호출 시 cars에 누적** — 초기화의 의도와 다름. 재호출 시 버그.
+- **`Car.move(randomNumber)`** — 자동차가 무작위 표현 인지.
+- **우승자 알고리즘 복잡** — maxOf + filter로 충분.
+- **자동차 사전 계산 (모두 미리 계산)** — 전략 패턴으로 lazy 계산.
+- **`for ... { add }` 패턴** — `map`으로 단순화.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **"전략 패턴 + lazy 계산"** 가이드를 명확히 제시. 1000대의 자동차를 모두 사전 계산하면 N초 소요. 실제 이동할 때 계산하면 즉시. 디자인 패턴이 성능에 직접 기여하는 예시.
+
+또한 **`initRacing()` 호출 패턴 시뮬레이션** — 같은 메서드를 5번 호출하면 어떻게 되는지 코드로 보여 호출 사이드 이펙트를 즉시 드러냄.
+
+`Car.move(randomNumber)` 매개변수 이름이 무작위 표현을 자동차에 새는 신호. 적절한 추상 이름으로.
+
+- **대표 인용:**
+  > 가령, 자동차가 움직이기 위한 조건을 계산하는데 차 한대당 1초가 걸린다고 한다면, 1000대의 자동차를 모두 준비시키는데에만 많은 시간이 소요될 수 있습니다. 디자인 패턴의 전략 패턴을 사용해 보거나...
+  >
+  > — @laco-dev on `src/main/kotlin/racing/model/RacingGame.kt`
+
+  > val racingGame = RacingGame() racingGame.initRacing(cars) racingGame.initRacing(cars) ... 초기화의 의도와 맞지 않게 동작하지는 않을까요?
+  >
+  > — @laco-dev on `src/main/kotlin/racing/model/RacingGame.kt`
+
+  > 자동차가 움직이기 위해 필요한 값이 랜덤? 이라는 것을 알 필요가 있을까요? 어떤 값이 들어올지 는 바깥에서 결정되기 때문에 randomNumber 대신 적절한 이름으로 변경해보면 어떨까요?
+  >
+  > — @laco-dev on `src/main/kotlin/racing/model/Car.kt`
+
+## 얻은 교훈
+
+- **이름이 외부 표현(랜덤)을 새면 결합도가 즉시 보임.** `move(randomNumber)` → `move(moveValue)` 또는 `move(number)`로 추상화.
+- **`initX()` 호출 패턴 = 라이프사이클 진단.** 같은 메서드 N번 호출 시 누적되면 의도와 다른 결과. 멱등성이 깨짐.
+- **전략 패턴의 lazy 계산 가치.** 도메인 객체가 사전 계산하지 않고, 실제 사용 시점에 외부 전략으로 계산. 성능 + 추상화.
+- **자동차 무작위 표현 = 도메인 외부의 관심사.** 0~9 범위가 자동차의 일이 아님.
+- **"뼈대 코드" 커밋의 안티패턴.** 의미 단위가 아닌 시점 단위로 커밋하면 코드 변경의 의도가 사라짐.

package/lessons/woowacourse-racingcar/rhkrwngud445/74-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 #74 — [코비] 2단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@rhkrwngud445](https://github.com/rhkrwngud445)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/74
+- **단계:** 2단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 7
+
+## 잘한 점 (설계 관점)
+
+- **NumberGenerator 인터페이스 도입 시도**.
+- **테스트 이름의 단위 개선 시도**.
+
+## 못한 점 (설계 관점)
+
+- **`forEach` 남용 — `map` 자리 침범** — 반환을 활용하는 자리에 forEach 쓰면 다시 add 패턴이 등장.
+- **`RacingGame`이 `RandomNumberGenerator()` 디폴트 파라미터** — 도메인이 구체 구현체 알게 됨. Controller에서 주입해야.
+- **`randomGenerator` 같은 구현체 정보가 인터페이스 이름에 침투**.
+- **테스트 이름 추상 ("예외 발생", "정상 작동")**.
+- **`Car`의 move()로만 위치 변경 가능 → 테스트 준비 어려움** — 생성자에서 초기 위치 받게.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev는 **`forEach` 남용을 강하게 짚음** — `map`의 올바른 사용법 학습 필요. 학생이 흔히 함수형 도구를 절차적으로 사용하는 패턴.
+
+또한 **"구현 구체와 인터페이스 이름의 분리"** — `RandomXxxGenerator` 같은 이름은 인터페이스에 구현 단서를 새는 신호.
+
+테스트 이름은 도메인 명세 ("차 이름이 5글자 넘으면 예외" → "자동차 이름은 최대 5글자").
+
+- **대표 인용:**
+  > forEach 대신 map을 이용해서 만들도록 개선해보세요. map의 올바른 사용 방법을 학습 하셔야 합니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racing/controller/RacingCarController.kt`
+
+  > 인터페이스를 사용한다면, randomGenerator와 같이 실제 구현과 관련이 있는 형태로 네이밍을 작성하지 않아야 합니다.
+  >
+  > — @laco-dev on `src/main/kotlin/racing/model/RacingGame.kt`
+
+  > 예외 발생, 정상 작동 처럼 추상적인 개념은 테스트 이름으로 사용하기 적합하지 않습니다 ... 차 이름이 5글자가 넘으면 exception 발생 → 자동차 이름은 최대 5글자이다
+  >
+  > — @laco-dev on `src/test/kotlin/racing/model/CarTest.kt`
+
+## 얻은 교훈
+
+- **`forEach` vs `map`.** map의 반환을 사용할 때만 map. 사용 안 하면 forEach. 반대로 쓰면 함수형 도구가 절차적 사용으로 격하.
+- **인터페이스 이름의 추상.** What만 이름에. How(랜덤, 시퀀셜, 페이크)는 구현체에.
+- **테스트 이름은 도메인 명세.** "예외" 같은 결과가 아니라 "5글자 제한" 같은 규칙 자체.

package/lessons/woowacourse-racingcar/rhthrhrl0/31-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,43 @@
+# PR #31 — [자동차 경주] 럭키 미션 제출합니다
+
+- **Reviewee:** [@rhthrhrl0](https://github.com/rhthrhrl0)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/31
+- **단계:** 1단계 (단일 PR)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **`Car` `read-only` 외부 노출**, runCatching 활용.
+- **`MovingStrategy` 인터페이스 + `RandomMovingStrategy` 구현** — 전략 패턴.
+- **`CarRacingGameManager` 인터페이스로 느슨한 연결**.
+
+## 못한 점 (설계 관점)
+
+- **`Car`가 data class인데 비즈니스 로직 보유** — data class의 의도는 데이터 운반.
+- **`Common/Const.kt` 단일 상수 파일** — 사용처 분산 vs 일관성 trade-off.
+- **`RandomMovingStrategy` public** — 내부에서만 쓰이면 private.
+- **`-` 매직 문자열**, OutputView에 그리는 로직 직접 포함.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 핵심 가르침:
+
+1. **data class에 비즈니스 로직?** — "데이터 클래스의 의도는 무엇? data class에 변경이 발생해야 한다면 그 이유는?" 데이터 운반 + 동치성이 본업이지 로직 호스팅이 아님.
+
+2. **`Const` 단일 파일 → 의미별 분리 또는 사용처 내부 선언**. "common"이라는 패키지가 곧 god-folder.
+
+3. **OutputView의 그리기 로직 = 별도 함수 분리** — 자동차 그리는 요구사항이 복잡해지면 println의 결과 예측 어려움.
+
+4. **전략 패턴 활용 칭찬** — 의도에 맞게 잘 사용.
+
+- **대표 인용:**
+  > 현재, 크게 문제가 되는 부분은 아니지만 데이터 클래스에서 비즈니스 로직을 수행하는 것이 적절할지에 대해 고민해보면 좋을 것 같아요. - 데이터 클래스라는 개념을 추가한 이유는 무엇일까? - 데이터 클래스에 변경이 발생해야한다면 그 이유는 무엇일까?
+  >
+  > — @vagabond95 on `src/main/kotlin/domain/Car.kt`
+
+## 얻은 교훈
+
+- **data class의 의도 = 데이터 + 동치성**. 비즈니스 로직 (이동, 검증, 변환)이 들어오면 *왜 data class인가* 의문. 일반 class로 충분할 수 있음.
+- **`common`/`Const`/`Util` 같은 일반 패키지명은 god-folder**. 시간 흐르면 모든 게 그곳에 모임. 의미별 분리 또는 사용처 옆에 둘 것.
+- **OutputView의 그리기 = 별도 함수**. `"-".repeat(...)` 같은 표현이 인라인되어 있으면 출력 요구사항 변경 시 println 예측 어려움.

package/lessons/woowacourse-racingcar/rosemin928/138-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 #138 — [자동차 경주 구현] 비비 미션 제출합니다
+
+- **Reviewee:** [@rosemin928](https://github.com/rosemin928)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/138
+- **단계:** 1단계
+- **리뷰어:** @krrong
+- **라인 코멘트:** 46
+
+## 잘한 점 (설계 관점)
+
+- **`NumberGenerator` 인터페이스로 전략 패턴 활용** — 난수 생성을 인터페이스로 추상화해 테스트 가능성과 교체 가능성을 동시에 확보. 리뷰어가 명시적으로 칭찬.
+- **InputView/OutputView 분리** — View 계층의 입출력 책임을 의식적으로 나눔.
+- **`@ParameterizedTest` 활용** — 여러 시나리오를 깔끔하게 검증.
+- **TestNumberGenerator 도입** — 테스트에서 결정적인 결과를 받기 위한 페이크 구현.
+
+## 못한 점 (설계 관점)
+
+- **`Constants.kt` 한 곳에 상수 몰아넣음** — 도메인 결합도가 낮은 곳에 모이면서 사용 시 모든 곳이 이 파일에 의존. 상수는 자신을 소유한 도메인 객체와 함께 살아야.
+- **`InputValidator` 같은 범용 검증기** — `validateCarName` 같은 이름이 시작부터 "이 검증기는 Car 전용"임을 노출. `Motorcycle`이 들어오면 `validateMotorcycleName`이 추가되는 구조. 정작 도메인 객체는 자기 invariants를 안 지킴.
+- **함수명 `moveOrStop` / `lap` 등 의도 불명** — `lap()`은 "한 바퀴"인지 "주파"인지 사용자 입장에서 불명확. 추상화 vs 직관 사이에서 직관이 부족.
+- **`updateDistanceIfMovable`처럼 if 조건이 이름에 노출** — 조건은 구현 상세인데 이름에 들어가니, 조건이 바뀌면 이름도 바뀌어야.
+- **`TestNumberGenerator`가 production 패키지에 위치** — 테스트 의존이 production 의존 그래프에 새어 들어옴.
+- **`Car`가 출력용 `toString()` 정의** — 도메인 객체가 표시 형식을 책임지면서 View 책임이 새어 들어옴.
+- **테스트가 "위치를 출력하는 것"까지 검증** — `Car`가 정말 출력을 책임지는지 의문. 테스트가 관심사 밖까지 확장.
+- **상수가 사용하는 곳보다 넓은 가시성** — 한 클래스에서만 쓰는 상수가 public.
+
+## 리뷰어 의견 요지
+
+리뷰어 @krrong는 일관되게 **"이 클래스의 역할과 책임이 무엇인가?"** 를 묻는다. `Car`, `Cars`에 대해 직접 질문하며 학생이 정의를 시도하게 만드는 식. 또한 **"테스트를 위한 코드가 production에 있으면 다른 개발자에게 혼란"** 이라는 명시적 가이드, 그리고 **"명세된 요구사항만 검증해라"** 는 YAGNI 가이드까지.
+
+함수명에 대해서도 강한 가이드: "if문이 있는 모든 함수에 `xxxIfcondition` suffix를 붙일 거냐"는 반어로, **이름은 단순하고 직관적일수록 자연스럽다** 는 원칙.
+
+- **대표 인용:**
+  > `InputValidator`의 모든 함수명에 `Car`가 있는데, 새로운 `Motorcycle` 클래스의 검증이 필요하다면 `validateMotorcycleName`이라는 함수가 새로 생겨야 할까요?
+  >
+  > — @krrong on `src/main/kotlin/InputValidator.kt`
+
+  > 비비는 `Car`의 역할과 책임을 무엇이라고 정의했나요? 비비의 의견을 알려주세요!
+  >
+  > — @krrong on `src/main/kotlin/domain/cars/Car.kt:23`
+
+  > if문이 있는 모든 함수들은 `xxxIfcondition`이러한 suffix가 붙어야할까요? 함수명은 **간단**하고 **직관적**일수록 다른 개발자로 하여금 자연스럽게 받아들일 수 있게 도와줘요.
+  >
+  > — @krrong on `src/main/kotlin/domain/cars/Car.kt:12`
+
+## 얻은 교훈
+
+- **검증기는 그 검증을 가지는 도메인의 일부여야 한다.** `InputValidator.validateCarName`는 일견 단정해 보이지만, 확장될수록 도메인 종류만큼 함수가 늘어난다. invariants는 그 invariants의 주인이 들고 있어야 한 곳에서 변한다.
+- **상수는 자신을 소유한 도메인과 함께 산다.** `Constants.kt`라는 공유 저장고는 모든 코드를 한 파일에 결합시키는 안티패턴이다. 어떤 상수가 한 클래스에서만 쓰인다면 `private`로, 도메인 전체가 공유한다면 그 도메인 객체의 `companion object`로.
+- **이름은 구현 조건을 노출하지 않는다.** `updateDistanceIfMovable`는 함수 안의 if를 이름으로 드러낸 것. 조건이 바뀌면 이름이 바뀐다 — 안정적인 추상이 아니다. `move()`처럼 What을 적어라.
+- **테스트가 검증해야 할 것은 도메인 행위.** "Car가 위치를 출력하는가"는 도메인 행위가 아닐 가능성이 크다. 위치 변화 자체가 도메인이고 표시 방법은 View의 일.
+- **테스트 더블은 테스트 영역에 머문다.** Fake 구현이 production 패키지에 있으면 그 코드를 읽는 다른 개발자가 "이것이 production에서 쓰이는가" 의문을 가진다. 의존성 그래프를 깨끗이.
+- **예외 검증은 메시지가 아니라 종류로.** 메시지는 유지보수/다국어로 흔들리지만, 예외 타입은 안정적 계약이다. 테스트는 안정적 계약에 결합해야 한다.

package/lessons/woowacourse-racingcar/rosemin928/171-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,38 @@
+# PR #171 — [자동차 경주 2단계] 비비 미션 제출합니다
+
+- **Reviewee:** [@rosemin928](https://github.com/rosemin928)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/171
+- **단계:** 2단계
+- **리뷰어:** @krrong
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **출력 책임을 도메인 객체에서 분리** — 1단계의 `Car.toString()` 출력 로직을 `OutputView`로 이동. 표시 형식을 View의 일로 명확히 옮김.
+- **`Cars`의 책임을 자기 언어로 정의** — "전체 자동차들의 이동을 처리하고 우승자를 선정하는 것"으로 명시. 책임을 말로 표현하는 훈련.
+- **검증과 변환의 분리 시도** — 두 가지가 한 클래스에 모이는 것을 자각하고 `CarNameConverter` 클래스를 분리.
+
+## 못한 점 (설계 관점)
+
+- **`Cars`가 여전히 String split을 수행** — 입력 형식 의존이 도메인까지 새어 들어옴. 1단계와 동일한 패턴이 잠복.
+- **`CarNameConverter`로 분리했지만 진짜 자리는 `InputView`** — 변환을 별도 클래스로 빼는 것보다 InputView가 `List<String>`을 반환하면 변환기가 아예 불필요. 책임의 자리 선택이 한 단계 더 필요.
+- **`InputValidator`가 여전히 object로 도메인+입력 검증 혼재** — 1단계 패턴을 그대로 유지. 도메인 invariants와 입력 형식 검증이 한 곳에.
+- **테스트의 import 단순화 같은 점진적 정리가 늦음** — assert import 정리 같은 작은 가독성 개선이 미반영.
+
+## 리뷰어 의견 요지
+
+리뷰어 @krrong는 1단계의 코멘트를 한 번 더 강조하면서 **"도메인이 알 필요 없는 입력 형식이 도메인에 새고 있음"** 을 다시 짚었다. 동시에 reviewee가 "변환을 별도 클래스로 빼면 해결된다"는 자기 결론에 도달했을 때 그것보다 한 발 더 나간 답("그 책임은 InputView가 `List<String>`을 주는 것이다")을 제시.
+
+또한 "object의 장단점을 묻는 의도"가 단순히 답을 듣는 것이 아니라 학습을 유도하는 것임을 솔직히 밝히는 식의 메타 가이드도.
+
+- **대표 인용:**
+  > String을 받아와 `split` 하는 과정이 `Cars`에 있어야 하는가를 물어보고 싶었어요. 입력값에 대한 검증을 `RacingCar`가 아닌, `InputView`에서 진행할 수 있고, 이는 곧 `InputView`가 `List<String>`의 형태로 반환이 가능하다는 말이 될 거에요. `CarNameConverter`를 생성하지 않아도 되는 또 다른 하나의 방법이 되겠죠.
+  >
+  > — @krrong on `src/main/kotlin/domain/cars/Cars.kt`
+
+## 얻은 교훈
+
+- **"변환을 별도 클래스로 빼라"가 첫 답이 아닐 때가 많다.** 진짜 답은 한 단계 위 — "변환을 누가 책임지는가? 그 변환이 필요 없는 경계가 있는가?"이다. `CarNameConverter`라는 새 클래스를 만들기 전에 `InputView`가 `List<String>`을 반환할 수 있는지 묻는 게 우선.
+- **도메인이 받는 인자의 타입이 추상의 약속을 결정한다.** `Cars`가 String을 받아 split한다면 도메인이 형식을 안다. `Cars`가 `List<Car>` 또는 `List<String>`을 받는다면 도메인이 깨끗하다.
+- **자기 책임을 말로 표현해보는 것은 가장 단순하지만 강력한 진단.** `Cars`의 책임을 "전체 자동차의 이동과 우승자 선정"이라고 정의한 순간, "그럼 input split이 왜 여기 있지?"라는 모순이 자동으로 드러난다.
+- **리뷰어의 질문은 답을 듣기 위한 게 아닐 수 있다.** "object의 장단점은?"이 학습을 시킬 의도라는 메타 가이드는, 답을 빨리 내려는 충동을 멈추고 스스로 모델을 만들 시간을 갖게 만든다.

package/lessons/woowacourse-racingcar/s6m1n/120-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 #120 — [자동차 경주 - 리팩토링] 새미 미션 제출합니다
+
+- **Reviewee:** [@s6m1n](https://github.com/s6m1n)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/120
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 10
+
+## 잘한 점 (설계 관점)
+
+- **`object → class` 변경**, MutableList → List — 1단계 피드백 흡수.
+- **`Car.position`에 `private set`** — 외부 변경 차단.
+- **메시지 템플릿화** — 1~5 같은 매직넘버 제거.
+- **`toIntOrNull()` 도입** — try-catch 없이 형변환 실패 처리.
+- **단순 println까지 OutputView로 이동** — 출력 책임 통일.
+
+## 못한 점 (설계 관점)
+
+- **초기 위치 `0`이 매직넘버**.
+- **try-catch가 너무 큰 범위 감쌈** — type 검증 + trialNum 범위 검증 한꺼번에. 책임 혼합.
+- **Random.nextInt 테스트가 여전히 남음** (리뷰 후 삭제).
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong의 메시지:
+
+1. **try-catch 범위 좁히기 두 가지 방법**:
+   - **type 검증만 try-catch 감싸기** — 한 가지 예외 한 가지 처리
+   - **toIntOrNull() + 엘비스 연산자** — try-catch 없이 처리
+
+2. **초기 위치 0도 매직넘버** — 상수화. 의미가 분리되어야 도메인 어휘.
+
+3. **불필요한 테스트는 삭제하는 유지보수** — 테스트가 많아지면 실행 시간 부담. Random 테스트는 가치 없으니 삭제.
+
+4. **`(MIN..MAX).random()` 대 `Random.nextInt(MIN, MAX)`** — 코틀린 idiom. 포함/배타 경계가 명확해짐.
+
+5. **단순 println 이동 = 책임 명시화의 신호** — "단순한 코드일지라도 역할과 책임에 대해 명시적으로 짚고 넘어가려는 모습이 멋집니다."
+
+- **대표 인용:**
+  > try catch 가 input type 에 대한 검증과 trialNum 범위에 대한 검증 전체를 감싸고 있어서 읽기가 어려워보입니다... try catch 대신, String 타입의 input 을 Int 로 변환에 실패하면 null을 반환하는 toIntOrNull() 를 사용해서 type 변환 실패를 처리할 수도 있습니다!
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/utils/InputValidator.kt`
+
+  > 테스트를 많이 작성해서 쌓이다보면, 테스트를 돌리는 시간을 줄이기 위해, 불필요한 테스트를 삭제하는 유지보수를 하기도 합니다.
+  >
+  > — @ghojeong on `src/test/kotlin/racingcar/model/RandomNumberGeneratorTest.kt`
+
+## 얻은 교훈
+
+- **try-catch는 최대한 좁게**. 한 가지 예외만, 한 가지 처리. 두 가지 검증을 한 catch에 합치면 어디서 무엇이 실패했는지 모름.
+- **`toIntOrNull()` ?: throw 패턴**. try-catch보다 흐름이 명시적이고, null이 의미하는 바가 명확.
+- **테스트도 *삭제*가 유지보수의 일부**. 가치 없는 테스트는 빌드 시간만 잡아먹는 데드 코드. "이 테스트가 깨지면 무엇이 망가진 것인가?" 답 없으면 삭제.
+- **초기값 0, 1 같은 작은 숫자도 의미가 있으면 상수**. `INITIAL_POSITION = 0`은 "위치는 0에서 시작"이라는 도메인 의미를 코드에 남김.
+- **단순한 print 한 줄도 책임을 따진다**. 큰 책임 분리는 작은 코드 한 줄의 책임 위치에서 검증됨. 사소함을 견디는 게 SRP의 진짜 시험.

package/lessons/woowacourse-racingcar/s6m1n/91-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,62 @@
+# PR #91 — [자동차 경주] 새미 미션 제출합니다
+
+- **Reviewee:** [@s6m1n](https://github.com/s6m1n) (페어 진행)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/91
+- **단계:** 1단계
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **InputValidator + 테스트 코드 풍부**.
+- **`MoveManager`로 움직임 판단 분리** + 꼼꼼한 private 상수.
+- **단일 책임 자가 의문 PR에 명시** — "단순 println 하나가 SRP 위반인가?"
+- **클래스 인스턴스 책임 자가 의문** — object vs class 기준 질문.
+- **테스트 함수명의 가독성** — `4 미만의 정수가 뽑혔을 경우 false를 반환`.
+
+## 못한 점 (설계 관점)
+
+- **`RacingController`가 object (싱글톤) + `lateinit var currentRacingStatus`** — 상태 있는 싱글톤 = 멀티스레드 위험.
+- **단순 개행을 위한 println()을 Controller에서 직접 호출** — 출력 책임이 OutputView에 모이지 않음.
+- **메시지 상수에 "1~5글자" 박힘** — 요구사항 변경 시 코드+메시지 두 곳.
+- **`Car.position`이 외부 접근 가능**.
+- **Random.nextInt 테스트 (fuzz)** — 자기가 구현 안 한 부분 테스트.
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong의 핵심 가르침:
+
+1. **object vs class의 기준 = "상태 유무"** — "상태 없이 특정 기능만 제공하면 object. 메서드 전부 static + static 상수만 가질 때." → Controller가 currentRacingStatus를 가지면 이미 object의 자격 잃음. 멀티스레드에서 `lateinit var`가 어떻게 망가질지 시뮬레이션.
+
+2. **SRP 검사법 = "이 클래스의 역할을 한 문장으로"** — Controller가 "데이터를 전달한다"면 println 추가 = SRP 위반. "데이터를 받아 출력한다"면 OK. **네이밍이 SRP를 결정.**
+
+3. **테스트 코드 = 요구사항이지 구현체 아님** — "요구사항이 바뀌면 테스트 코드 갈아엎고 새로 짜는 게 자연스럽다. 지나친 보편화는 오히려 유지보수 어렵게 만든다." → 다른 리뷰어 vagabond95의 "추상화" 의견과 충돌, 토론.
+
+4. **자기가 구현 안 한 부분은 테스트 안 함** — Random.nextInt 테스트 = Fuzzing. 단위 테스트가 아니라 확률 보장. "이건 자동차 경주 게임을 구현한 거지 Random.nextInt를 구현한 게 아니다."
+
+5. **메시지 상수와 검증값의 결합 → "누군가의 야근"** — 1~5 변경 시 Constants는 테스트 없어 사람 검증.
+
+- **대표 인용:**
+  > 객체가 **상태** 없이 특정 기능만을 제공하는 경우 (예: ~Util) 여기서 상태가 없다는게 저의 판단 기준의 핵심입니다. 메서드는 전부 static 메서드이어야 하며, static 상수만을 가질 경우에 object 문법을 사용합니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/controller/RacingController.kt:20`
+
+  > 단일 책임 원칙이 어긋나 있는지 확인하는 좋은 방법 중 하나는, 이 클래스의 역할과 책임이 무엇인지 한 문장으로 적어보는 것입니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/controller/RacingController.kt:42`
+
+  > 제 입장에서 테스트 코드란 구현해야할 요구 사항이지, 요구사항에 대한 구현체가 아니기 때문입니다. 따라서 요구사항이 바뀌었다면, 테스트 코드 또한 바뀌어야 한다는게 저는 자연스럽다고 생각합니다.
+  >
+  > — @ghojeong on `src/test/kotlin/racingcar/model/MoveManagerTest.kt:23`
+
+  > 빙티님이 구현하신 것은 "자동차 경주" 게임이지, Random.nextInt 를 구현하신게 아니기 때문입니다.
+  >
+  > — @ghojeong on `src/test/kotlin/racingcar/model/RandomNumberGeneratorTest.kt:20`
+
+## 얻은 교훈
+
+- **object 사용 기준 = 상태 없음 + static 메서드/상수만**. 상태 한 줄이 끼면 object를 쓸 자격 잃음. 멀티스레드 시 lateinit var의 race 상태를 시뮬레이션해보면 명확.
+- **SRP 자가 검사 = "이 클래스의 책임을 한 문장으로"**. 그 문장이 모호하거나 너무 길면 SRP 위반. "전달한다" vs "받아 출력한다"의 한 단어 차이가 println 한 줄을 결정.
+- **테스트는 요구사항의 거울이지 구현의 일부가 아니다**. 요구사항 바뀌면 테스트 갈아엎기. 지나친 보편화 ("기준 숫자 이하")는 미래의 자기 통제권 줄이는 환상.
+- **자기가 안 짠 코드는 자기가 테스트 안 한다**. `Random.nextInt`, `String.split` 같은 표준 라이브러리는 자신이 구현한 게 아니므로 단위 테스트 대상이 아님. 그건 fuzz / 확률 보장.
+- **"누군가의 야근" 패턴**. 메시지 상수 / 코드 검증값이 어긋나면 빌드는 통과해도 운영에서 사용자 메시지가 잘못 나옴. 그 버그는 보통 새벽에 발견됨.