oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/ippnsj/67-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,57 @@
+# PR #67 — [글로] 2단계 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@ippnsj](https://github.com/ippnsj)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/67
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 21
+
+## 잘한 점 (설계 관점)
+
+- **의존성 주입 적용** — 리뷰어 명시적 칭찬.
+- **`Cars` 일급 컬렉션 도입** — 자동차들의 책임 일급화.
+- **자기 의문 적극 — split 검증 필요성, mutable 사용 이유 등**.
+
+## 못한 점 (설계 관점)
+
+- **`Controller`가 필드로 값을 보관** — 함수 인자로 받는 게 자연스러움.
+- **for 루프 + map 결과 미사용** — repeat() / forEach 등 표준 도구 활용.
+- **`CarMetadata` 모호한 이름** — Metadata는 추상 일반어, 도메인 의미가 없음.
+- **`Car.isWinner(winnerDistance)`가 String 반환** — is- 접두사는 boolean 약속. 거짓말 시그니처.
+- **Car의 `isLongerDistance` 같은 내부 비교** — distance를 비교의 일급 시민으로 노출하거나 distance 자체를 비교 가능하게.
+- **자동차 이름의 Char 검증** — 다음 요구사항 변경에 대응 어려움. Regex로 일관 검증.
+- **`Cars` 내부 mutableList** — 생성자에서만 사용한다면 List + 즉시 할당으로 immutable.
+- **`CarNamesValidator` 외부 검증기** — 응집도 손상. 검증은 invariants 주인 곁.
+- **테스트가 NumberGenerator를 직접 구현** — fun interface + 람다로 단순화.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 **`is-` 접두사가 boolean을 약속한다** 는 클래식 가이드를 정밀히 짚었다. `isWinner(): String`이 호출자에게 거짓말.
+
+또한 **"비교 메서드의 trade-off"** — `isLongerDistance` 같은 메서드를 만들 것인가, `distance`를 public으로 열 것인가. 두 가지 모두 옵션이지만 메서드 이름으로 의도가 드러나야.
+
+`Validator` 응집 가이드 + split 같은 단순 형식 변환은 View로 옮기는 가이드를 한 번 더 (1단계의 반복).
+
+`mutableList` 사용에 대해서는 학생이 "add 함수 사용"이라 답했지만 리뷰어는 "생성 시 한 번에 할당하면 mutable 필요 없음"이라는 더 단순한 답.
+
+- **대표 인용:**
+  > isWinner인데 String을 반환하는 것은 어색합니다. is~네이밍은 Boolean을 반환하는 것이 일반적이에요.
+  >
+  > — @malibinYun on `src/main/kotlin/domain/Car.kt`
+
+  > winnerDistance로 들어오는 integer 값이 반드시 승자의 값만 들어올까요? 다른 개발자들이 의도에 맞지 않게 사용하게 된다면, 전혀 다른 결과를 낼 것으로 보여요.
+  >
+  > — @malibinYun on `src/main/kotlin/domain/Car.kt:32`
+
+  > validator 객체를 따로 만들어 한꺼번에 관리하기 보다, 검증이 필요한 곳에서 해당 로직을 응집도 있게 구현하시면 좋겠어요.
+  >
+  > — @malibinYun on `src/main/kotlin/utils/CarNamesValidator.kt`
+
+## 얻은 교훈
+
+- **`is-` 접두사 = boolean 약속.** 다른 타입 반환은 시그니처 거짓말. `isXxx`인데 String이면 `getXxx`로 바꾸거나 진짜 boolean으로.
+- **`Manager`, `Metadata`, `Info` 같은 추상 명사는 도메인 어휘 부재의 신호.** 그 뒤에 진짜 도메인 개념이 있다 — `CarMetadata` → `RaceRecord` 같은 식.
+- **파라미터 명명의 가정.** `winnerDistance: Int`라는 이름이 호출자에게 "승자의 distance만 넣어라"고 약속하지만 시그니처는 그것을 강제 못 함. 더 안전한 시그니처가 필요.
+- **MutableList vs 즉시 할당 + List.** map { ... }의 결과를 한 번에 var/val에 할당하면 mutable 필요 없음. `add` 호출이 패턴화돼있으면 의식적 점검.
+- **fun interface + 람다 = SAM의 가치.** NumberGenerator를 inner class로 구현하는 대신 람다로. 코드의 의도가 시그니처에 직결.
+- **검증의 응집 원칙은 반복 강조 필요.** 1단계, 2단계 같은 가이드가 다시 나오면 학생이 흡수 못한 신호. 같은 코멘트가 반복되면 학습 깊이 점검.

package/lessons/woowacourse-racingcar/jaeyeongjo/110-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,39 @@
+# PR #110 — [자동차 경주 - 리팩토링] 재영 미션 제출합니다
+
+- **Reviewee:** [@jaeyeongjo](https://github.com/jaeyeongjo)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/110
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **EOF, ktlintCheck 등 작은 위생 적용**.
+- **runCatching, 재귀로 전환 완료**.
+- **`MoveConstant` 의미별 상수 파일**.
+
+## 못한 점 (설계 관점)
+
+- **GameController가 *class*** — 인스턴스화 필요성 의문 (object 가능).
+- **assertTrue 같은 단조로운 assertion** — assertThat 등 가독성 좋은 옵션.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 메시지:
+
+1. **Class vs Object 선택 이유** — "GameController를 Class로 구현함으로서 얻는 이점은?" 학생이 "여기서는 object로 바꾸는 게 좋겠다"로 답.
+
+2. **테스트 함수명 한국어 활용**.
+
+3. **assertTrue 외 다양한 assertion**.
+
+- **대표 인용:**
+  > GameController를 Class로 구현함으로서 얻는 이점은 어떤 것이 있을까요?
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+## 얻은 교훈
+
+- **"이걸 class로 한 이유는?" 질문이 가장 강력한 SRP 검증법**. 답을 못 하면 object/top-level fun으로 충분.
+- **테스트 함수명 한국어 = 가독성 + 협업 친화**. 한국인 동료가 읽는 코드라면 영어보다 직관적.
+- **assertThat이 assertTrue보다 *왜 실패했는지* 정보 풍부**. assertTrue는 boolean만, assertThat은 값/타입 차이.

package/lessons/woowacourse-racingcar/jaeyeongjo/89-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,46 @@
+# PR #89 — [자동차 경주 - 1단계] 재영 미션 제출합니다
+
+- **Reviewee:** [@jaeyeongjo](https://github.com/jaeyeongjo)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/89
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 12
+
+## 잘한 점 (설계 관점)
+
+- **함수 분리 깔끔**, `Car.position` `private set`.
+- **정규식 + Set 활용한 검증** (이름 형식, 중복).
+- **try-catch 처리 깔끔**.
+- **`ValidationUtil`을 Car 외부로 분리** + 학생이 *이유* 답변 (SRP).
+
+## 못한 점 (설계 관점)
+
+- **while문이 흐름 제어로만 쓰임 (조건 무의미)**.
+- **nullable + `!!` 사용** — non-null로 끌어올리기 가능.
+- **runCatching 미적용** (try-catch).
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 메시지:
+
+1. **while문의 조건 의미 퇴색** — 단순 무한 루프 + break면 while의 의미 무. → 학생 재귀로 변경.
+
+2. **`!!` 회피의 두 방향**:
+   - 입력 단계에서 nullable 제거 (`orEmpty()`, `?: ""`)
+   - 함수 시그니처 non-null로
+
+3. **runCatching의 *extension* (`onSuccess`, `onFailure`)** 활용.
+
+4. **검증을 별도 클래스로 분리 = SRP 정당화** — 학생 답: "Car의 책임은 상태 관리 + 행위 캡슐화. 검증은 또 다른 책임."
+
+- **대표 인용:**
+  > nullable한 값에 대해서 !!로 non-nullable 하게 정의하는 방법도 좋지만 nullable한 요소를 제거해 보는건 어떨까요?? nullable한 코드 마다 매번 non-nullable 하게 정의하는 것과 try catch로 감싸는 내용이 들어가다 보면 보일러 플레이트 코드가 생겨날 것 같다는 생각이 듭니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+## 얻은 교훈
+
+- **`!!`은 *코틀린의 마지막 수단***. 보통은 입력 단계에서 null을 *제거*해서 호출 측은 non-null만 다루는 게 깨끗.
+- **while문의 조건이 무의미하면 while 아님**. 재귀 또는 do-while로 바꾸는 게 흐름 명시적.
+- **SRP의 자가 답변 = 학습의 신호**. "Car의 책임은 상태 + 행위. 검증은 또 다른 책임"이라는 *명확한 한 문장*이 있으면 분리 정당화.
+- **runCatching의 진짜 가치 = Extension 체이닝** (`onSuccess`/`onFailure`). try-catch는 명령형, runCatching은 선언형.

package/lessons/woowacourse-racingcar/jinuemong/104-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 #104 — [자동차 경주] 누누 미션 제출합니다
+
+- **Reviewee:** [@jinuemong](https://github.com/jinuemong)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/104
+- **단계:** 1단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 11
+
+## 잘한 점 (설계 관점)
+
+- **enum class 활용**, `require`/`throw` 잘 적용.
+- **`Validator` 객체, `Constant` 분리**.
+- **PR에 자가 의문 명시** — 재귀 vs lateinit + while 비교.
+
+## 못한 점 (설계 관점)
+
+- **`Application`이 OutputView/InputView/Validator 인스턴스 보유** — object 후보.
+- **`Car.step`을 생성자로 받음** — 0으로 초기화되는 값이 외부 인자.
+- **`InputView`에 출력문 (안내 메시지)** — 출력 책임 침범.
+- **`Message` object에 모든 메시지 모음** — 재사용 안 되면 사용처에 둘 것.
+- **separator 같은 매직 문자열 미상수화**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 메시지:
+
+1. **재귀 vs lateinit + while** — "정답은 없다. 다만 lateinit은 *non-nullable 타입을 생성자 외부에서 초기화*하기 위해 쓰는 도구. *초기화 상태*를 체크하는 용도는 부적절."
+
+2. **`step`을 *body에 두기*** — 생성자가 받을 게 아니라 항상 0으로 시작하는 invariant.
+
+3. **InputView가 출력문을 보유 = 책임 침범**.
+
+4. **상수의 자리 = 사용처와의 거리**. 재사용 안 되면 사용처 내부에 private.
+
+- **대표 인용:**
+  > 누누님이 말씀하신 케이스에서의 `초기화 상태`를 체크하는 용도로 lateinit 사용이 적절할지는 한번 고민해볼 필요는 있을것 같아요. 상태를 관리하는 객체가 따로 존재하지 않은 대신, lateinit 으로 관리되는 상태를 사용할 때 `상태 = 변수 초기화 유무` 이 둘의 상관관계가 자연스러운가? 에 대해 고민해보시기 바랄게요!
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/CarController.kt`
+
+  > step 을 생성자로 받아야 할 필요가 있을까요? step은 처음 Car 클래스가 생성될 때 0으로 초기화 되고, 함수를 통해 변경되는 값이기에 constructor 보다는 body에서 관리되는게 어떨가 싶은데요.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/model/Car.kt`
+
+## 얻은 교훈
+
+- **`lateinit`의 진짜 용도 = "non-nullable 타입 + 생성자 외부 초기화"**. 초기화 *여부*를 흐름 제어로 쓰는 건 부적절. *상태 = 변수 초기화 유무*의 매핑이 부자연스러우면 다른 도구.
+- **생성자 vs body 선언 기준**: 외부에서 주는 값 → 생성자, 항상 같은 초기값으로 시작하는 invariant → body.
+- **InputView에 출력문 = 책임 침범**. 입출력 분리 의미 약화. 입력 안내문도 OutputView로.
+- **상수의 응집도 = 재사용성**. 한 클래스에서만 = 그 클래스 내 private. 여러 클래스 = 의미 있는 파일.

package/lessons/woowacourse-racingcar/jinuemong/117-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,42 @@
+# PR #117 — [자동차 경주 - 리팩토링] 누누 미션 제출합니다
+
+- **Reviewee:** [@jinuemong](https://github.com/jinuemong)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/117
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 5
+
+## 잘한 점 (설계 관점)
+
+- **`RandomNumberMaker` 인터페이스 도입** — 전략 패턴.
+- **검증 + 변환을 한 함수로** — `validateCarNames`가 검증 후 `List<Name>` 반환.
+
+## 못한 점 (설계 관점)
+
+- **Car가 여전히 `Random` 직접 의존** — 부분적 적용.
+- **인터페이스의 패키지 위치** — domain vs data 의문 (리뷰어 가이드 필요).
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 메시지:
+
+1. **Validator의 *검증 + 반환* 패턴** — "Validator는 검증, 이상 시 catch, 정상 시 List 반환 → kotlin.collections.filter와 유사." 흐름이 깔끔해짐.
+
+2. **인터페이스 위치 = domain, 구현체 위치 = data**. "RandomNumberMaker 인터페이스가 domain에 있고, RandomNumberMakerProvider 같은 구현이 데이터 영역에 있으면 자연스럽다." 의존 역전.
+
+3. **Random 의존 분리** — Car가 직접 Random.nextInt 부르면 테스트 어려움.
+
+- **대표 인용:**
+  > 오히려 검증 후 이상없다면 List<Names> 를 반환하는게 어떨까 해서 코멘트 드렸었습니다. Validator는 말그대로 검증하는 로직이기에, 검증시 이상있으면 catch에서 처리될 것이고, 정상이라면 List를 반환하도록 하여 가독성을 더 높일 수 있다는 말씀을 드리고 싶었습니다 👍 마치 kotlin.collections 의 filter 처럼요
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/CarController.kt`
+
+  > 오히려 RandomNumberMarker 인터페이스가 domain 패키지에 있고, 이를 구현하는 ex. RandomNumberMarkerProvider 가 데이터영역에 있으면 조금 더 자연스럽겠네요!
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/data/RandomNumberMaker.kt`
+
+## 얻은 교훈
+
+- **Validator의 `검증 + 변환`은 *kotlin.collections.filter* 패턴**. 검증만 하고 boolean 반환 vs 정상 시 변환된 값 반환. 후자가 호출 측 가독성 높음.
+- **인터페이스 = domain, 구현체 = data/infra**. 의존 역전 원칙. 도메인이 외부를 모르고, 외부가 도메인 인터페이스에 의존.
+- **부분 적용된 추상화의 위험**. RandomNumberMaker 인터페이스 만들었지만 Car가 여전히 Random 직접 부르면 추상화의 절반만 적용. 일관성이 중요.

package/lessons/woowacourse-racingcar/jiyuneel/142-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 #142 — [자동차 경주] 포르 미션 제출합니다
+
+- **Reviewee:** [@jiyuneel](https://github.com/jiyuneel)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/142
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 25
+
+## 잘한 점 (설계 관점)
+
+- **`Game` 도메인 객체 도입** — 게임 진행 로직을 별도 객체로 분리.
+- **`Validator` 별도 클래스** — CarNamesValidator, InputValidator로 분리.
+- **Retry 유틸리티 분리** — 입력 재시도 로직 일반화.
+- **enum `Move`** — 매직넘버 대신 enum.
+- **피드백 흡수 후 도메인 검증을 Car init으로 이동** — Validator → Car 자체로.
+
+## 못한 점 (설계 관점)
+
+- **검증을 모두 Validator/Controller에 모음** — Car init 검증과 분리되어 책임 분산.
+- **`CarNamesValidator` 분리로 Car 테스트가 빈약해짐** — 테스트가 Validator로 옮겨가니 Car는 "move/distance"만 테스트, 도메인 무결성 테스트는 Validator만.
+- **`Car`의 가변성 (var position) vs `copy` 토론에서 결론 미정** — "mutable해도 되긴 하는데"로 끝남.
+- **View가 NotEmpty 같은 사용자 입력 형식 검증을 안 함** — 빈 문자열도 Controller까지 옴.
+- **`InputValidator` 같은 일반 이름** — 다른 게임 추가 시 충돌 가능성 (리뷰어 지적).
+- **테스트 네이밍에 given/when/then 구분 미흡** — 30줄 넘는 테스트에서 가독성 저하.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag은 **"확장 시나리오로 압박 테스트하기"** 스타일.
+
+1. **Validator의 확장 압박** — "KoreanCar, EnglishCar, FrenchCar가 늘어나도 모국어만 쓴다면 Validation이 너무 무거워진다" → Validator가 한 클래스에 도메인별 규칙을 다 안고 있을 때 깨짐.
+
+2. **Validator의 위치** — "ValidationCheck가 과연 Controller에서 담당해야 할 일인가?" → 학생이 "도메인 검증은 Car init으로 이동, 사용자 입력(빈 문자열)은 Controller에 남김"으로 답.
+
+3. **Retry의 실서비스 사용처 질문** — "이 로직은 실서비스에서 언제 쓸 거냐?" → "API 호출 재시도" 답 유도. 추가 "onFailure 시에는 무조건 재호출일까요?" → Retry 정책의 세분화 (재시도 횟수, 백오프, 종류별 분기) 시사.
+
+4. **mutable data class 토론** — "RacingCar는 mutable해도 되지만, 실서비스에서는 사이드이펙트 영향 추적 어렵다. 멀티스레드 동시성도." → 학생은 "구체적 케이스 더 공부할 것" 인정.
+
+5. **테스트 네이밍 핵심** — "주어진 것 / 동작 / 예상 결과를 구분해서 적는다" → given-when-then 구조. 단순 한 줄짜리 fun 이름이 아닌, body 안에서도 구분.
+
+- **대표 인용:**
+  > KoreanCar, EnglishCar, FrenchCar 등등 Car 객체가 늘어나도 해당 Car들은 모국어만 사용할 수 있다고 한다면, Validation이 너무 무거워질 것 같네요.. 또한 구현을 보면서 계속 의문이 들었던 것은 ValidationCheck가 과연 Controller에서 담당을 해야할 일인가?? 인데
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/controller/RacingCarController.kt`
+
+  > 레이싱 게임에서의 Car 객체는 많은 로직이나, 복잡한 유기성을 가지고 있지 않아서 mutable 하게 해도 크게 문제는 안되지만 실제 프로젝트에서는 어떤 영향을 줄지는 알 수가 없는 경우가 많습니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/model/Car.kt:6`
+
+  > 이왕 재실행하는 로직을 만드셨으니, 코멘트 남겨두었습니다! 실제 서비스에서 이 로직은 언제 사용을 하실건가요? (사용한다면, 어떤 부분을 수정하는 것이 좋을지도요!)
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/util/Retry.kt:11`
+
+## 얻은 교훈
+
+- **"확장 시나리오로 압박"이 강력한 리뷰 기법.** 지금 잘 돌아가는 Validator가 도메인 확장(다국어 차, 다게임)에 무너지는지 시뮬레이션 → 진짜 책임 분배를 강제.
+- **유틸리티 함수의 가치 = 실서비스 사용처가 명확할 때.** Retry는 만들기 쉬워도 "언제 어떻게 쓰일지" 답이 없으면 죽은 코드. 만들기 전 "이게 어디서 쓰일까?"를 자문.
+- **검증 책임의 3단 분리.** UI 형식 검증 = View (빈 문자열, 공백), 사용자 입력 정책 = Controller (재입력 흐름), 도메인 무결성 = Domain init (이름 길이 같은 invariant).
+- **mutable의 진짜 위험은 "테스트 가능한 작은 코드"가 아니라 "추적 못 하는 큰 코드"에서 나타난다.** Racing처럼 작은 도메인에서는 mutable로도 충분히 동작 — 다만 "큰 코드에서 깨지는 패턴을 작은 코드에서 연습한다"가 학습의 목적.
+- **테스트 네이밍은 함수 이름만이 아니라 body 안의 given/when/then 구분 주석/공백.** 30줄짜리 테스트에서 어디까지가 setup인지 보이게.

package/lessons/woowacourse-racingcar/junjange/113-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,41 @@
+# PR #113 — [자동차 경주 - 리팩토링] 에디 미션 제출합니다
+
+- **Reviewee:** [@junjange](https://github.com/junjange)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/113
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 10
+
+## 잘한 점 (설계 관점)
+
+- **`RandomNumber`를 object로 (싱글톤)** + 학생이 *왜* 그렇게 했는지 정당화 — 게임이 여러 번 진행돼도 인스턴스 재생성 비용 없음.
+- **`RandomNumberGenerator` 인터페이스 도입** — 리뷰어 권고 즉시 흡수.
+- **테스트 함수명 한국어로 가독성 ↑**.
+
+## 못한 점 (설계 관점)
+
+- **테스트 매직넘버 (3, 4) → 의미 상수 (이동_성공, 이동_실패) 미적용**.
+- **`RandomNumber` 단일 object** — 인터페이스 추상화 전.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 메시지:
+
+1. **object로 만든 *이유* 명시 요구** — 학생이 "랜덤 생성이 자주 호출되어 인스턴스 재생성 비용 회피"로 답.
+2. **확장성 위해 interface 추상화** — 학생이 즉시 적용.
+3. **테스트 매직넘버에 의미 부여** — `MOVE_SUCCESS = 4`, `MOVE_FAIL = 3` 같은 의미 상수.
+
+- **대표 인용:**
+  > RandonNumber를 object 키워드로 생성하신 이유가 궁금합니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/utils/RandomNumber.kt`
+
+  > RandomNumber에 대한 확장성을 위해서 interface로 만드는 방법도 고민해보면 좋을 것 같습니다!!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/utils/RandomNumber.kt`
+
+## 얻은 교훈
+
+- **object 사용 정당화 = 인스턴스 비용 vs 상태 무**. "비용 회피"가 정당화이지, "그냥 한 줄 짧아서"가 아님.
+- **테스트 매직넘버도 도메인 어휘**. 4와 3이 의미하는 *상황*에 이름을 붙이면 테스트 본문이 영어 문장으로 읽힘.
+- **interface 추상화 시점 = 확장성 *예상*되는 시점**. 지금 한 구현체밖에 없어도, 미래 확장이 명확하면 인터페이스로.

package/lessons/woowacourse-racingcar/junjange/87-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,39 @@
+# PR #87 — [자동차 경주 - 1단계] 에디 미션 제출합니다
+
+- **Reviewee:** [@junjange](https://github.com/junjange)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/87
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 14
+
+## 잘한 점 (설계 관점)
+
+- **`RacingCarGame` model + companion object 상수**.
+- **String 확장 함수 활용** — 코틀린 idiom.
+- **`Exceptions` object로 검증 분리** — 확장 함수 형태로 InputView에서 호출.
+- **private 지정자 의식적 사용**.
+
+## 못한 점 (설계 관점)
+
+- **`MESSAGE_ERROR` 상수가 public** — Exceptions 내부에서만 쓰이는데도.
+- **JVM target 19 (관습은 17)** — 의미 없는 차이.
+- **함수 분리 부족** — `setCarNames + setRound` 형태로 SRP 강화 가능.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag의 메시지:
+
+1. **상수의 private 권장** — Exception 메시지처럼 클래스 내부에서만 쓰는 상수는 private. "사람이 실수할 수 있는 상황에 대비."
+2. **함수 분리 SRP** — `initRacingCar()` 같은 작은 단위.
+3. **테스트 함수명 한국어 + given/when/result 주석**.
+
+- **대표 인용:**
+  > MESSAGE_ERROR 같은 경우에도 Exception 에서만 사용하는 상수라면 private로 외부 접근을 막는 것도 좋을 것 같습니다!! 추후에 규모가 커지다 보면 중복으로 선언하는 상수가 생길 수도 있으며, 외부에서도 접근이 가능하게 됩니다. 사람이다 보니 언제든 실수할 수 있는 상황에 대비해서 고려해보셔도 좋을 것 같습니다
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/racingcar/utils/Exceptions.kt`
+
+## 얻은 교훈
+
+- **private의 가치 = 미래의 실수 차단**. 외부 접근 가능한 상수는 누군가 중복 선언/잘못 import할 신호. 처음부터 private으로 막으면 그 위험 0.
+- **확장 함수로 검증 호출 = 호출 측 가독성 ↑**. `input.validate()` 형태가 `Exceptions.validate(input)`보다 읽기 좋음. 단, 확장 함수가 어디서 정의됐는지 추적 부담은 있음.
+- **의미 없는 선택의 정당화는 정직하게**. JVM target 19로 한 이유 = "그냥". 그걸 *PR에 적는 정직함*이 동료가 신뢰하는 신호.

package/lessons/woowacourse-racingcar/junseo511/148-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 #148 — [자동차 경주 구현] 공백 미션 제출합니다
+
+- **Reviewee:** [@junseo511](https://github.com/junseo511)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/148
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 32
+
+## 잘한 점 (설계 관점)
+
+- **Car 생성 시 init 블록에서 자기 invariants 검증** — 이름 빈 값/길이 검증을 `Car` 스스로 책임. 도메인 객체가 자기 무결성을 지키는 방향.
+- **`Judge` 분리 시도** — 우승자 판별을 별도 객체로 빼서 책임 분할 의식을 보여줌. (다만 그게 정말 별도 객체여야 하는지가 토론거리)
+- **ParameterizedTest 활용** — 같은 형태의 케이스를 데이터로 묶어 표현.
+- **자기 의문을 명시적으로 기록** — "유효성 검증의 책임은 누가 가지고 있는가" 같은 메타 질문을 PR description에 적어 토론을 유도.
+
+## 못한 점 (설계 관점)
+
+- **`Judge`의 정체성 모호 — "자동차들"에게 직접 메시지를 던질 수도 있는 세계** — 현실 비유로는 심판이 맞지만, 객체지향에서는 "Cars 자신이 너네 중 우승자를 내놔"라고 응답할 수 있음. 책임 분리가 항상 새 객체를 의미하지는 않음.
+- **`Organizer`라는 모호한 클래스 이름** — 무엇을 organize하는지 이름만으로 짐작 불가. "RaceOrganizer"로 보강했지만 여전히 추상.
+- **`RandomGenerator`를 게임 실행마다 생성** — 한 번 만들면 재사용 가능한데 매번 생성해 객체 라이프사이클 인식이 약함.
+- **공백 = " "만 공백으로 인식** — 탭/줄바꿈 등 다른 whitespace는 잡지 못함. 도메인 무결성 정의가 좁음.
+- **테스트가 예외 종류만 보고 메시지/원인을 검증 안 함** — 같은 IllegalArgumentException이라도 진짜 그 원인으로 실패했는지 확신 불가.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 두 가지 주요 관점을 일관되게 짚었다.
+
+1. **"객체에게 메시지를 던지는 것"** 이 현실 비유와 다를 수 있다는 점 — `Judge`로 분리하기 전에 `Cars`(자동차들) 컬렉션 자체에 "너희 중 우승자를 내놔" 메시지를 보낼 수 있는지 고민.
+2. **이름은 추측이 가능해야 한다** — `Organizer`만 보고 어떤 프로그램인지 짐작이 안 됨. "동료에게 이름만 보여주고 역할을 맞춰보게 한다"는 검증 방법까지 제시.
+
+또 테스트에서 **"같은 예외 종류 안에서 진짜 그 원인으로 실패했는지"** 를 묻는 식의 비판은 예외 검증 설계의 깊이를 끌어올림.
+
+- **대표 인용:**
+  > "자동차들"에게 직접 "너네 중 승자를 내놔" 라고 메시지를 던져보는 게 가능한 세계라는 점, 참고해보세요!
+  >
+  > — @malibinYun on `src/main/kotlin/Judge.kt`
+
+  > 아무 동료를 붙잡고 RaceOrganizer라는 이름만 가지고 어떤 역할을 할 것 같냐고 물어보면 객관적인 검증이 되겠어요!
+  >
+  > — @malibinYun on `src/main/kotlin/Organizer.kt`
+
+  > 공백 케이스를 테스트했는데, IllegalArgumentException가 throw되어 테스트를 성공했을 때, 정말 공백에 대한 IllegalArgumentException임을 확신할 수 있을까요?
+  >
+  > — @malibinYun on `src/test/kotlin/CarTest.kt:19`
+
+## 얻은 교훈
+
+- **"분리 = 새 객체"가 항상 답은 아니다.** 우승자 판별은 `Judge`라는 새 객체가 아니라, `Cars`라는 일급 컬렉션 자신의 책임이 될 수 있다. 객체지향에서는 "컬렉션도 메시지를 받을 수 있다"는 점이 절차적 사고와 다른 결정적 차이.
+- **이름은 외부 검증으로 평가하라.** 그 이름만 보고 동료가 책임을 추측할 수 있어야 한다. 만약 "이건 OO이고 OO은 안 한다"고 보충 설명이 필요하다면, 이름이 책임을 못 드러내는 신호다.
+- **객체의 생애 주기는 사용 패턴이 결정한다.** 매 호출마다 생성되는 자원은 (1) 정말 그래야 하는지, (2) 재사용해도 안전한지 한 번 더 검토할 것. 게임 단위 = 1개라면 멤버로 보관.
+- **도메인 무결성의 정의는 도메인의 어휘로 한다.** "공백 = space"가 아니라 "이름으로 인식할 수 없는 모든 whitespace"가 더 정확한 invariants.
+- **예외 검증의 신뢰도는 종류 + 원인.** 같은 예외 타입 안에서 의도와 다른 이유로 실패하면 테스트가 거짓말을 한다. 메시지 검증이 부담스럽다면, 다른 예외 클래스를 도메인 별로 분리하는 것도 방법.

package/lessons/woowacourse-racingcar/junseo511/165-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 #165 — [자동차 경주 2단계] 공백 미션 제출합니다
+
+- **Reviewee:** [@junseo511](https://github.com/junseo511)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/165
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 23
+
+## 잘한 점 (설계 관점)
+
+- **`Cars` 일급 컬렉션으로 자동차들의 책임 모음** — `Judge`를 따로 두기보다 `Cars`에게 "우승자 골라"라는 메시지를 보내는 방향으로 1단계 피드백 흡수.
+- **`Car` 자체는 군더더기 없이 깔끔** — 리뷰어가 명시적으로 칭찬. 도메인 객체가 자기 책임만 들고 있음.
+- **이름 중복 검증을 `Cars.init`으로 이동** — invariants가 그 invariants의 주인 곁에 위치.
+- **`Race` 객체 도입** — Controller가 라운드 흐름을 직접 돌리던 것을 도메인 객체로 옮기려는 시도.
+
+## 못한 점 (설계 관점)
+
+- **`Race`라는 이름이 여전히 추상적** — "경주"라는 단어가 광범위해 구체적 책임이 안 드러남. `RacingGame`/`CarRace` 같은 더 구체적 명명 필요.
+- **`Race`가 `Cars`에서 cars를 꺼내 직접 다룸** — 디미터의 법칙 위반. `cars.getX()`로 데이터를 꺼내 사용 → 메시지 위임으로 바꿔야.
+- **`moveCars`가 여전히 테스트하기 어려운 형태** — 1단계의 `Car`에는 적용한 "결정적 입력 주입"이 `Cars` 메서드에는 적용 안 됨. 같은 원칙의 일관성 부족.
+- **`Cars.toWinners()`가 수신 객체를 변환한다는 오해 유발** — `to-` 접두사가 새 객체 변환을 의미하는데 사실은 필터 결과. 이름이 동작과 어긋남.
+- **Controller가 여전히 라운드 진행 흐름을 손에 쥠** — `Race` 객체가 도입됐지만 흐름 제어가 완전히 이전되지 않음.
+- **테스트가 목적이 모호** — "1회 또는 2회 실행 후 상태"가 어떠해야 하는지 명확히 검증 안 함.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 이 라운드에서 **객체의 자율성**을 강하게 밀어붙였다. Controller가 라운드 루프를 돌리는 게 아니라 **`Race` 객체에게 startGame()을 보내면 결과 객체가 돌아오는** 형태가 객체지향다움이라는 가이드. 동시에 **디미터의 법칙**을 명시적으로 언급하며 `Cars`에서 cars를 꺼내쓰는 패턴을 지적.
+
+또한 이름이 행동을 거짓말하는 케이스(`toWinners`가 변환이 아니라 필터)와, `Race`같은 너무 일반적 이름의 문제를 짚었다.
+
+- **대표 인용:**
+  > 경주 객체에게 게임을 시작하라고 하면, 진행한 모든 라운드의 기록을 담은 객체를 반환하고, 그 기록을 바탕으로 View를 그려주는 형태로 구성해볼 수 있겠어요. 그러면 더이상 컨트롤러에서 자동차 경주 게임의 흐름 제어를 맡지 않고, 경주 객체 자체가 자율성을 지니겠지요!
+  >
+  > — @malibinYun on `src/main/kotlin/racingcar/model/Race.kt:20`
+
+  > Cars 객체에서 cars를 꺼내 쓰기 보다, 메시지를 던져 값을 가져오는 건 어떨까요? 디미터의 법칙에 대해서도 알아보셔도 좋겠어요.
+  >
+  > — @malibinYun on `src/main/kotlin/racingcar/model/Race.kt:21`
+
+  > 이 메서드 명으로 보면, 수신 객체를 모두 승리한 자동차로 바꾸겠다는 의미로 느껴지네요.
+  >
+  > — @malibinYun on `src/main/kotlin/domain/Cars.kt` (`toWinners`)
+
+## 얻은 교훈
+
+- **객체의 자율성 = 흐름 제어를 객체가 들고 있는 것.** Controller가 라운드 루프를 돌면 그 객체는 데이터 컨테이너에 불과해진다. `Race.startGame()`이 결과 객체를 반환하는 형태가 객체에게 "스스로 일하라"고 시키는 모양.
+- **디미터의 법칙 = "친구의 친구의 메서드를 부르지 않는다".** `cars.getCars()[i].position`처럼 객체 그래프를 타고 내려가는 호출은 캡슐화를 뚫고 들어가는 신호. 한 메시지로 결과를 받게 시그니처를 다시 디자인.
+- **메서드 이름은 동작을 거짓말하면 안 된다.** `to-` 접두사가 변환을 의미한다면, 필터 결과에는 `to-`를 붙이지 않는다. 사용자의 기대를 어기지 않는 약속을 유지.
+- **추상적 이름은 그것이 일반화의 결과일 때만 가치 있다.** `Race`가 자동차 외에도 적용될 일반화라면 OK, 아니면 `CarRace`로 구체화. 이름이 의도를 좁힐 때 더 강력하다.
+- **같은 원칙은 같은 수준에서 적용한다.** `Car`를 결정적 입력으로 테스트 가능하게 만들었다면, 같은 패턴을 `Cars.moveCars`에도 적용해야 한다. 한 군데만 깨끗하면 다른 곳에 비결정성이 흘러들어간다.
+- **테스트는 동작의 명세 — "무엇이 어때야 하는가"가 명확해야 한다.** "1회 실행" 자체가 아니라 "1회 실행 후 자동차 상태가 어떠해야 하는가"가 테스트의 본질.

package/lessons/woowacourse-racingcar/ki960213/32-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 #32 — [토마스] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@ki960213](https://github.com/ki960213)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/32
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 10
+
+## 잘한 점 (설계 관점)
+
+- **`GameCars` 일급 컬렉션 도입** — 자동차들의 책임 일급화.
+- **자기 의문 표명 + 자기 정당화** — Set vs List 선택의 자기 분석.
+- **시도 횟수 검증의 모범 — `AdvanceCount`** — 원시 강박 해소.
+
+## 못한 점 (설계 관점)
+
+- **`Regex`를 매번 생성** — invariant 객체는 캐싱.
+- **에러 메시지에 입력값 포함 안 됨** — 디버깅/UX 미흡.
+- **`common.Const`로 에러 prefix 같은 미미한 상수 모음** — 분리의 정당화 약함.
+- **`Car`가 data class 아닌 그냥 class** — equals/hashCode 자동 생성 활용 가능.
+- **매직 넘버 인라인** (`GameCars` 등).
+- **`InputView`가 Car 생성** — 도메인 객체 생성 책임이 View로.
+- **`main.kt`에 전역 변수** — 객체 간 데이터 흐름이 흐려짐.
+- **`runCatching` 구문 길어 어디서 exception 발생하는지 모호**.
+- **테스트가 production 로직으로 데이터 빌드** — 변경 약함.
+- **NumberGenerator 인터페이스를 SAM 람다로 활용 안 함**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 **테스트 메시지 검증의 trade-off** 에 대한 학생의 self-정당화에 대해 **"여러 제안 중 본인의 것으로 흡수"** 라는 메타 가이드. 학생의 추론(거짓 양성/음성)을 인정하면서도 다른 시각을 제시.
+
+또한 **`GameCars`의 Set vs List 선택** 에 대해 단순 답이 아닌 trade-off 정리: List 받고 검증 후 Exception / Set 활용으로 중복 없는 도메인 / 내부에서 Set만 사용. 모두 가능한 선택.
+
+**`runCatching` 구문이 길면 어디서 exception 발생하는지 모호** — 함수 분리로 명확.
+
+- **대표 인용:**
+  > 여러 제안에 대해서 충분히 고민해보시고, 장단점과 특징을 잘 공부해서 본인의 것으로 잘 흡수했으면 좋겠어요.
+  >
+  > — @malibinYun on `src/main/kotlin/domain/GameCars.kt`
+
+  > runCatching 구문이 길어지면 어디에서 exception이 발생하는 지 알기 어렵습니다.
+  >
+  > — @malibinYun on `src/main/kotlin/main.kt`
+
+  > Car를 만들어내는 일은 View의 일일까요?
+  >
+  > — @malibinYun on `src/main/kotlin/view/InputView.kt:26`
+
+## 얻은 교훈
+
+- **invariant 객체는 매번 생성하지 않는다.** Regex 같은 비용 큰 객체는 companion에서 한 번만.
+- **상수 분리의 정당화 = 도메인적 의미.** "에러 메시지 prefix"는 도메인 의미가 약함. 분리는 의미가 있을 때만.
+- **runCatching의 범위.** 한 번에 너무 많이 잡으면 어디서 던졌는지 모름. 단일 호출 또는 짧은 블록에만.
+- **Set vs List vs 검증 후 List = trade-off.** 정답 없는 선택, 각각 장단점. 자기 결정의 이유가 학습.
+- **테스트 메시지 검증의 trade-off.** 메시지 포함 검사 vs 정확 일치 검사 — 변경 가능성 vs 검증 정확도. 학생의 판단 인정.

package/lessons/woowacourse-racingcar/ki960213/63-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 #63 — [토마스] 2단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@ki960213](https://github.com/ki960213)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/63
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 22 (1단계와 거의 동일한 리뷰 반복 — 학습 누적 신호 약함)
+
+## 잘한 점 (설계 관점)
+
+- **`AdvanceCount` 도메인 객체 도입 + require 활용**.
+- **`GameCars` 일급 컬렉션 유지**.
+- **자기 결정의 정당화 능력** — Set vs List 선택, 메시지 검증 trade-off 등을 자기 논리로 답변.
+
+## 못한 점 (설계 관점)
+
+- **이전 라운드 가이드 미흡 반영** — Regex 캐싱, 에러 메시지에 입력값 포함, InputView가 Car 생성, runCatching 범위, hashCode/equals 도메인 정당화 등 1단계 코멘트가 거의 그대로 재등장.
+- **`Const.kt`의 에러 메시지 prefix** — 의미 약한 상수.
+- **`Car`의 data class 미활용**.
+- **`AdvanceCount`의 require 메시지 통합 가능**.
+- **테스트가 production 로직으로 데이터 빌드 + method source 남용**.
+
+## 리뷰어 의견 요지
+
+이 라운드는 1단계 라운드의 리뷰가 거의 그대로 반복되는 양상. 리뷰어가 같은 가이드를 여러 번 짚는다는 것은 **학생이 핵심 학습을 흡수하지 못한 신호**.
+
+핵심 가이드:
+1. invariant 객체는 캐싱 (Regex)
+2. 에러 메시지 = 입력값 포함
+3. 도메인 객체 생성은 도메인 곁
+4. 테스트는 production 로직으로 데이터 빌드하지 않음 — 하드코딩
+5. SAM 인터페이스는 람다로
+
+학생의 **자기 정당화 능력은 높지만 리뷰 흡수는 낮은 패턴** — 본인 논리는 있지만 외부 가이드의 trade-off를 코드 변경으로 옮기는 부분이 약함.
+
+- **대표 인용:**
+  > 여러 제안에 대해서 충분히 고민해보시고, 장단점과 특징을 잘 공부해서 본인의 것으로 잘 흡수했으면 좋겠어요.
+  >
+  > — @malibinYun on `src/main/kotlin/domain/GameCars.kt`
+
+  > 정확하게 어떤 메세지를 갖고있는 지 테스트를 한다면 메세지가 약간만 변경되더라도 거짓 양성이 발생하게 되어서 특정 문자열만 포함하도록 했습니다 ... 보통 개발자가 테스트 로직을 잘못 만드는 경우까지 고려해야 해서 테스트 코드를 작성해야 하나요?
+  >
+  > — @ki960213 (학생의 깊은 자기 정당화)
+
+## 얻은 교훈
+
+- **자기 정당화 vs 리뷰 흡수의 balance.** 학생의 자기 논리는 학습에 중요하지만 외부 피드백을 코드로 옮기는 능력도 필요. 두 라운드에 걸쳐 같은 리뷰가 반복되면 자기 논리가 변경을 막고 있는지 점검.
+- **반복되는 리뷰는 학생-리뷰어 모두에게 신호.** 같은 코멘트가 두 번 반복되면 (1) 학생이 흡수 못함, (2) 리뷰어 가이드가 학생 언어에 안 맞음, 둘 중 하나. 메타 토론 필요.
+- **리뷰는 trade-off의 제시 + 학생의 선택.** "본인의 것으로 흡수"라는 리뷰어 메시지는 그 균형을 강조. 모든 가이드를 따를 필요는 없지만 trade-off는 인지해야.
+- **테스트 메시지 검증의 trade-off** — `contains` (변경에 강함, 정확도 약함) vs `equals` (정확, 변경에 취약). 본인 결정의 이유가 학습.
+- **사례 학습의 한계** — 학생이 "거짓 음성 vs 양성" 같은 깊은 논리 펼쳐도 실제 코드 변경에는 일관성 부족한 경우가 있음. 사고와 실천의 간극.