oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/EmilyCh0/57-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,55 @@
+# PR #57 — [자동차 경주 - 리팩토링] 에밀리 미션 제출합니다
+
+- **Reviewee:** [@EmilyCh0](https://github.com/EmilyCh0)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/57
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 13
+
+## 잘한 점 (설계 관점)
+
+- **`Referee` 도메인 분리** — 우승자 판단 책임 분리.
+- **while 재입력을 재귀로 변경** — 가독성 개선.
+- **테스트 시 Car를 생성자 + moveCount 직접 주입** — `tryMove()` 우회.
+- **상수 활용 + 기댓값 분리** — 1단계 피드백 흡수.
+
+## 못한 점 (설계 관점)
+
+- **`Referee`가 상태 없음에도 class** — object 후보.
+- **`Car.moveCount`가 외부 접근 가능** — private 누락.
+- **테스트 함수명이 추상적** — "예외가 발생한다", "우승자를 판단한다" → 동작 예측 불가.
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 핵심 가르침:
+
+1. **테스트 메서드명은 구체적인 *시나리오*** — "예외가 발생한다" → "자동차 이름은 항상 5글자 미만의 길이를 가진다" / "자동차 이름은 비어있을 수 없다". 동작 예측 가능해야.
+
+2. **테스트 setup은 우회 없이** — Car의 현재 위치를 테스트하려고 tryMove()를 N번 호출하지 말 것. 생성자에 moveCount를 직접 받아 *상태를 설정*하는 게 깔끔.
+
+3. **상태 없는 클래스는 object** — Referee가 인스턴스 여러 개 필요 없으면 object.
+
+4. **외부에서 호출되지 않는 속성은 private**.
+
+5. **재귀 vs while** — 재입력 흐름에서 재귀가 가독성 좋음 (조건 검사 한 곳, return 자연스러움).
+
+- **대표 인용:**
+  > 테스트 코드를 작성할 떄에는 예외가 발생하거나, 정상 동작한다 처럼 추상적인 의미를 가지기보다는, 보다 구체적이고 보는 사람이 이해가 쉽도록 작성 하면 더욱 좋습니다.
+  >
+  > — @laco-dev on `src/test/kotlin/domain/CarTest.kt`
+
+  > 비슷하게, 우승자를 판단한다는 내용이 어떻게 동작할 것이라는 예측으로 이어지지 않아요. 위 테스트에 대해서도 아래처럼 작성 해 볼 수 있겠죠? `우승자를 판단한다` --> `자동차들 중에 가장 먼 거리에 있는 자동차가 우승자다`
+  >
+  > — @laco-dev on `src/test/kotlin/domain/RefereeTest.kt`
+
+  > 테스트하기 위해 필요한 조건은 자동차의 "현재 위치"입니다. tryMove()를 사용하는 것이 아닌 자동차의 현재 위치를 변경하기 위한 다른 좋은 방법이 있지 않을까요?
+  >
+  > — @laco-dev on `src/test/kotlin/domain/RefereeTest.kt`
+
+## 얻은 교훈
+
+- **테스트 함수명 = "이 시나리오의 *결과*가 무엇인가" 한 문장**. "예외가 발생한다"는 결과만 명시; 시나리오 ("5글자 초과") + 결과 ("예외")가 같이 들어와야.
+- **테스트 setup이 우회 메서드 호출이면 = 도메인이 setup을 안 받는 신호.** Car 생성자에 moveCount를 받게 만들거나 별도 setter 두기. tryMove를 N번 호출해서 위치 만드는 건 테스트도 도메인 룰을 따르게 함 (랜덤 의존, 부정확).
+- **상태 없는 클래스는 object.** 단, 한 줄이라도 상태가 끼면 class로. Referee가 게임 동안 우승자 history 같은 상태를 가지면 class.
+- **재귀 vs while의 trade-off**. 재귀 = 조건 + return 자연스러움, 스택 깊이 위험은 입력 재시도 횟수에 비해 무시. while = 명시적 break 필요, depth 증가.
+- **리뷰어가 같은 학생을 두 번 보면 ↑ 단계의 피드백을 줄 수 있다**. 1단계에서 "테스트 기댓값 하드코딩"이었다면 2단계는 "테스트 함수명도 구체적으로", 3단계는 "테스트 setup 우회 없이". 점진적 깊이.

package/lessons/woowacourse-racingcar/HamBeomJoon/137-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 #137 — [자동차 경주 구현] 미플 미션 제출합니다
+
+- **Reviewee:** [@HamBeomJoon](https://github.com/HamBeomJoon)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/137
+- **단계:** 1단계
+- **리뷰어:** @krrong
+- **라인 코멘트:** 40
+
+## 잘한 점 (설계 관점)
+
+- **require 사용으로 검증 표현 단순화** — 리뷰어가 명시적으로 칭찬.
+- **`@ParameterizedTest` 활용** — 여러 케이스를 한 테스트로.
+- **자기 의문을 PR description에 풍부하게 적시** — 검증 위치, 상수화 기준, MutableList vs List 등 메타 질문 적극.
+- **리뷰 후 책임을 재배치하는 빠른 흡수** — `Cars` 클래스를 추가로 만들어 자동차 이동/우승자 검증을 옮김.
+
+## 못한 점 (설계 관점)
+
+- **`Car.position`이 외부에서 수정 가능** — 캡슐화 누락. private set 필요.
+- **`util.Constants`로 상수 한 곳에 집중** — 1단계의 흔한 패턴. 모든 사용처가 한 파일에 결합.
+- **`util.Validator`에 모든 검증 로직 집중** — 도메인이 자기 invariants를 안 들고, 외부 검증기에 의존.
+- **`RacingController`가 `MutableList`를 반환** — 호출자가 컬렉션을 수정할 수 있는 표면적 노출.
+- **`CarTest`가 사실은 `RacingController`를 테스트** — Car의 동작이 Controller 안에 있어서, Car 단독 테스트가 안 됨 (책임 분배의 신호).
+- **테스트가 Car의 상수(`MOVE_THRESHOLD`)를 직접 참조** — 상수가 6으로 바뀌면 테스트는 통과하면서 의미가 깨짐.
+- **input 검증과 도메인 검증이 한 Validator에 함께** — 두 가지 다른 종류의 invariants가 한 곳에.
+- **예외 메시지가 사용자에게 도움이 안 됨** — "왜 무효인지"가 안 보임.
+
+## 리뷰어 의견 요지
+
+리뷰어 @krrong는 일관되게 **"이 책임이 진짜 여기 있어야 하는가"** 를 묻는다. 특히 `CarTest`가 사실은 `RacingController`를 테스트한다는 지적은 강력 — 테스트 분포가 책임 분포의 거울임을 짚는다.
+
+또한 **검증의 자리는 검증 대상이 결정** 한다는 원칙: "입력값 검증은 입력 처리 곳에서, 도메인 검증은 도메인에서". 같은 코멘트로 검증의 종류와 자리를 한 번에 정리.
+
+**테스트가 production 상수를 참조하는 안티패턴** 에 대해서도 강한 가이드: 상수가 바뀌면 테스트가 의미 없이 통과한다는 점. private 가시성을 두려면 테스트에서 상수에 의존하지 않는 다른 방법을 써야 함.
+
+- **대표 인용:**
+  > `CarTest`이지만, 실제로는 `RacingController`를 테스트하고 있는 것처럼 보여요. 어떤 이유 때문일까요? 🤔
+  >
+  > — @krrong on `src/test/kotlin/CarTest.kt:7`
+
+  > 검증을 어디서 하느냐는 **어떤 값**을 **왜** 검증하느냐를 고민해보시면 좋을 것 같아요. 입력값이 유효한가? 를 검증하기 위해서는 입력을 처리하는 곳에서 검증하는 것이 맞고, 검증하는 로직이 도메인 로직이라면 도메인 로직을 처리하는 곳에서 검증하는 것이 맞습니다.
+  >
+  > — @krrong on `src/main/kotlin/util/Validator.kt`
+
+  > MOVE_THRESHOLD를 그대로 가져다 쓰는 경우 상수의 값을 변경하여 6이 된 경우에도 테스트가 정상적으로 통과가 될거에요. 단순히 Car 클래스에 있는 코드를 붙여넣은 것과 다름이 없는데, 과연 의미가 있는 테스트일까요?
+  >
+  > — @krrong on `src/test/kotlin/CarTest.kt:21`
+
+## 얻은 교훈
+
+- **테스트가 어느 클래스에 살고 있는가 = 책임이 어디에 있는가의 거울.** `CarTest`가 Controller를 테스트한다면, Car의 책임이 Controller에 있다는 신호. 테스트 분포의 어색함이 책임 재배치의 단서.
+- **검증의 두 종류:** (1) 입력 형식이 맞는가 — 입력 경계, (2) 도메인 invariants가 지켜졌는가 — 도메인 객체. 같은 Validator에 섞이면 둘 다 흐려진다.
+- **테스트는 production 상수에 의존하지 않는다.** `Car.MOVE_THRESHOLD`를 그대로 참조하면 그 상수가 바뀌어도 테스트는 통과 — 잘못된 안전 감각. 의도(behavior)에 결합해야 한다.
+- **반환 타입은 호출자에게 주는 약속.** `MutableList`를 반환하면 호출자가 컬렉션을 자유롭게 바꿀 수 있다고 약속한 것. 보통은 `List`로 read-only 약속이 더 안전.
+- **"테스트를 위해 가시성을 풀면" 안티패턴 시작.** private을 열어 테스트하는 대신, 그 책임이 정말 private이어야 하는지 또는 별개 클래스로 추출할 수 있는지 물어볼 것.
+- **자기 의문을 적극적으로 적는 학습 태도** — 미플의 PR description은 토론을 끌어내는 명확한 질문들로 가득. 이런 PR은 리뷰어의 시간을 효율적으로 쓰게 만들고 학습이 빠르게 일어난다.

package/lessons/woowacourse-racingcar/HamBeomJoon/170-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 #170 — [자동차 경주 2단계] 미플 미션 제출합니다
+
+- **Reviewee:** [@HamBeomJoon](https://github.com/HamBeomJoon)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/170
+- **단계:** 2단계
+- **리뷰어:** @krrong
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **InputView/OutputView를 생성자 주입** — Controller가 View 의존성을 외부에서 받음. 결합도 감소 + 테스트 가능성 향상.
+- **테스트 이름이 명세화** — 1단계의 모호한 이름에서 "무엇을 테스트하는지 명확"하게 개선.
+- **Cars 생성 방식 재설계** — 우승자 테스트에서 위치를 지정하기 어려운 점을 깨닫고, Controller에서 생성한 자동차 리스트를 Cars에 주입하는 방식으로 변경.
+
+## 못한 점 (설계 관점)
+
+- **`Controller` 안에 object `OutputView`와 주입받은 `outputView` 혼용** — 같은 역할의 두 인스턴스가 한 클래스에 공존. 의도를 알 수 없는 일관성 부족.
+- **상수 위치 리뷰가 미반영** — 1단계의 `util.Messages` 같은 상수 컨테이너가 그대로 유지.
+- **`return validateCount(count)` 같은 가독성 트레이드오프** — 한 줄 줄이려다 의도가 흐려짐.
+- **우승자 케이스 다중성 누락** — 우승자가 한 명/여러 명인 두 케이스를 모두 테스트하지 않음.
+
+## 리뷰어 의견 요지
+
+리뷰어 @krrong는 두 가지 주제를 짚었다.
+
+1. **의존성 주입의 장점** — Reviewee의 답("의존도가 높아지는 걸 해결")이 정확. 추가로 리뷰어가 명시적 확인은 안 하지만 일관성 있는 적용을 기대.
+2. **혼용 패턴의 위험성** — object `OutputView`와 주입받은 `outputView` 둘이 공존하면 호출자가 어느 쪽이 정답인지 모름. 1단계 학습이 2단계에서 일관되게 적용되지 않은 신호.
+
+또한 **테스트의 케이스 다양성** — 우승자가 한 명/여러 명인 두 시나리오를 모두 다뤄야 도메인 규칙의 명세가 된다.
+
+- **대표 인용:**
+  > `RacingController`를 만들 때 `InputView`와 `OutputView`를 주입해주고 있어요. 이렇게 했을 때의 장점이 무엇이라고 생각하나요?
+  >
+  > — @krrong on `src/main/kotlin/racingcar/Racingcar.kt`
+
+  > `RacingController`에서 object로 선언된 `OutputView`와 인자로 넘겨받은 `outputView`를 혼용하여 사용하고 있네요. 😅
+  >
+  > — @krrong on `src/main/kotlin/racingcar/RacingController.kt:11`
+
+  > 우승자를 확인하기 위한 테스트도 추가해볼까요? 도움을 드리자면 우승자는 한명일수도, 여러명일수도 있습니다.
+  >
+  > — @krrong on `src/main/kotlin/racingcar/model/Cars.kt:17`
+
+## 얻은 교훈
+
+- **의존성 주입의 일관성** — 주입의 의도는 "외부에서 의존성을 통제"하는 것. object와 주입받은 동일 타입이 한 클래스에 공존하면 그 의도가 무너진다. 둘 중 하나로 통일.
+- **테스트의 케이스 다양성 = 도메인 규칙의 완전성.** 우승자가 "한 명" 케이스만 테스트하면 "여러 명" 규칙은 정의되지 않은 상태. 도메인 규칙이 둘 다 허용한다면 테스트도 둘을 모두 명세.
+- **테스트 가능성이 설계를 끌어당긴다.** "Cars의 위치를 지정하기 어렵다"는 문제가 "Cars의 생성 방식을 바꾸자"는 설계 결정을 끌어낸 사례. 테스트하기 어려운 곳은 보통 책임 분배의 흔적이다.
+- **가독성 vs 한 줄 줄이기.** 한 줄 줄임은 가독성과 자주 충돌한다. 짧은 코드가 항상 좋은 코드는 아님. 읽는 사람이 "왜 이렇게 했지?"를 잠시라도 멈추게 되면 그 짧음은 비용이 된다.
+- **이전 라운드 학습이 다음 라운드에 일관되게 적용되는지가 진짜 학습.** 상수 위치 가이드를 받고도 다음 PR에 안 반영되면 학습이 일회성에 그친다. 한 라운드의 학습을 다음에 점검하는 자기 검증 루프가 필요.

package/lessons/woowacourse-racingcar/Hevton/106-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 #106 — [자동차 경주 구현] 팡태 미션 제출합니다
+
+- **Reviewee:** [@Hevton](https://github.com/Hevton)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/106
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 22 (양은 보통, 1단계임에도 설계 완성도 높음)
+
+## 잘한 점 (설계 관점)
+
+- **`Car` 생성 시 init 블록에서 invariants 검증** — 도메인 객체가 자기 무결성을 직접 지킴. 리뷰어 칭찬.
+- **`Cars`, `TryCount` 같은 일급 컬렉션/값 객체로 원시 강박 해소** — 1단계임에도 도메인 어휘 충실.
+- **`NumberGenerator` 인터페이스 + `RandomNumberGenerator` 구현** — 무작위 의존을 추상 뒤로 격리.
+- **companion object로 도메인 상수 묶음** — Car/Cars의 상수가 그 도메인 곁에 위치. `Constants.kt` 같은 안티패턴 회피.
+- **`InputView` / `OutputView` 명확한 분리** — 기능별 함수 분리도 잘됨.
+- **테스트 함수명이 도메인 의도를 명확히 드러냄** — "함수명만 봐도 유추 가능"이라는 리뷰어 칭찬.
+
+## 못한 점 (설계 관점)
+
+- **`validateCars` 같은 `Cars` 전용 검증이 외부 확장 함수로 존재** — `Cars` 내부 invariants는 `Cars`가 들고 있어야 한다. 확장 함수로 두면 외부에서 호출/재정의 가능성이 생기고 검증의 자리가 흐려짐.
+- **`TryCount`의 동일 패턴** — 자기 검증이 외부 확장 함수로 빠짐.
+- **`OutputView`가 우승자 계산 로직을 직접 함** — "승자를 구하는 로직이 View에 있는 게 맞는가" — MVC상 도메인 계산은 도메인에.
+- **`InputView`의 상수가 외부 노출** — Input 안에서만 쓰는 상수가 public.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag는 전반적으로 **높은 만족도** 를 표시하면서도, 두 가지 중요한 가이드를 일관되게 짚었다.
+
+1. **자기 invariants는 자기가 든다** — `validateCars`, `TryCount` 검증 같은 확장 함수가 외부에 있으면, 그 도메인 객체가 자기 무결성을 잃는다. 객체 내부에 두는 것이 응집의 원칙.
+2. **계산은 도메인의 일** — View가 승자를 계산하면 MVC가 깨진다. View는 받아서 그리기만.
+
+이 PR은 1단계 PR 중 가장 완성도가 높은 편이라 리뷰가 칭찬 위주이지만, 그 안에서도 짚어내는 두 가지는 OOP의 핵심.
+
+- **대표 인용:**
+  > MVC로 구현한다고 했을 때 승자를 구하는 로직이 View에 존재하는게 맞는가? 라는 고민이 들긴 해서 Cars 내부에 함수로 기능을 빼두는 것도 좋을 것 같다는 생각이 듭니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/view/OutputView.kt`
+
+  > fun validateCars() 의 경우 Cars 클래스에서만 사용하는 함수라면 Cars 클래스 내부에 선언해도 좋을 것 같다는 생각이 듭니다!!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/domain/Cars.kt`
+
+## 얻은 교훈
+
+- **확장 함수의 자리는 "도메인 객체가 컨트롤하지 못하는 외부 위치"가 아니라야 한다.** 그 객체의 invariants나 핵심 동작이 확장 함수로 빠지면 외부가 그 무결성을 우회할 수 있다. invariants는 내부에.
+- **MVC에서 View의 책임은 "받아서 그리기"로 좁힌다.** 표시 데이터를 만들어 View에 주는 책임은 도메인의 일이다. View가 계산을 하면 도메인 변경이 View로 새어 들어온다.
+- **1단계에서 객체지향 기초가 잘 잡힌 PR의 특징:**
+  1. 도메인 어휘로 클래스 이름 (`Cars`, `TryCount`)
+  2. 자기 invariants를 init에서 검증
+  3. 추상 인터페이스로 외부 자원 격리
+  4. companion object로 도메인 상수 결합
+  5. 테스트 함수명이 도메인 문장
+  이 다섯 가지가 함께 있으면 "객체지향답다"고 느껴진다.
+- **칭찬 리뷰가 많을 때도 핵심 가이드는 짧고 정확하다.** 좋은 리뷰어는 칭찬 사이에서도 본질적 약점을 짚는다 — "검증의 자리" / "View의 책임".

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

@@ -0,0 +1,51 @@
+# PR #118 — [자동차 경주 리팩터링] 팡태 미션 제출합니다
+
+- **Reviewee:** [@Hevton](https://github.com/Hevton)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/118
+- **단계:** 리팩터링
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 26
+
+## 잘한 점 (설계 관점)
+
+- **`Winners` 일급 객체 도입** — `List<Car>` 그대로 노출하지 않고 도메인 의미가 담긴 클래스로 감쌈. 도메인 어휘 보존.
+- **`Car`의 `private set`으로 외부 변경 차단** — 캡슐화의 기본기.
+- **InputView를 object로 재정의** — "상태 없음 + 의존성 없음 + 생성자 불필요"라는 자기 기준을 명확히 표명하며 변경. 리뷰어가 "정확한 대답"이라고 인정.
+- **`ExplicitNumberGenerator`로 결정적 테스트** — Random 의존을 추상으로 격리한 뒤 테스트용 구현체 제공.
+- **메서드 가시성을 한 번 더 점검** — private 노출 범위에 대해 자기 기준을 갖춤.
+
+## 못한 점 (설계 관점)
+
+- **`Winners` 클래스가 사실상 단순 wrapper** — 현재로선 추가 정보나 행위가 없어 단순 List 래핑. reviewee 본인도 "현재는 추가 정보가 없으므로 없어도 될 것 같다"고 인정. 도메인이 진짜로 필요로 할 때 만들 것.
+- **`OutputView`가 `Winners`의 표현을 직접 만듦** — `Winner.toString()` 오버라이딩으로 표현 책임을 도메인 객체로 옮기는 옵션도 있음.
+- **`getWinners()` 테스트 누락** — 리팩터링 라운드인데 핵심 기능의 테스트가 빠짐.
+- **이동 성공/실패 케이스에 매직 넘버(4) 직접 사용** — `MOVE_SUCCESS`/`MOVE_FAIL` 같은 상수로 의도를 드러내는 편이 가독성에 유리.
+
+## 리뷰어 의견 요지
+
+리뷰어 @Gyuil-Hwnag는 이 라운드에서 **"왜 만들었는가"** 를 명확히 묻는 패턴을 자주 보임 — `Winners` 데이터 클래스가 왜 필요한지, `InputView`가 왜 class인지. 이 질문은 학생이 자기 결정을 회고하게 만드는 좋은 도구.
+
+또한 **toString 오버라이딩으로 표현 책임을 도메인으로** 옮기는 옵션을 힌트로 제시하면서 "반드시 수정이 필요한 내용은 아니다"라고 함께 안내 — 강요하지 않는 학습 가이드.
+
+테스트 측면에서는 **상수로 의도 표현** (MOVE_SUCCESS 등)과 **누락된 케이스 보강** 가이드.
+
+- **대표 인용:**
+  > Winners 데이터 클래스가 존재하는 이유에 대해서 궁금합니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/domain/Winners.kt`
+
+  > InputView를 Class로 설정하시는 이유에 대해서 궁금합니다!
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/view/InputView.kt`
+
+  > Cars 에서 고민해보았던 toString()을 Winner 객체에서도 toString()을 오버라이딩 할 수 있지 않을까요? 반드시 수정이 필요한 내용은 아니고 ...
+  >
+  > — @Gyuil-Hwnag on `src/main/kotlin/view/OutputView.kt:21`
+
+## 얻은 교훈
+
+- **"왜 만들었는가"는 가장 가치 있는 리뷰 질문.** 학생이 자기 결정을 재현/회고하면 그 자체가 학습. `Winners`처럼 "추가 정보 없으면 없어도 된다"는 솔직한 회고가 가능해진다.
+- **클래스 vs object 선택의 기준 = (1) 상태, (2) 의존성, (3) 인스턴스 다수성.** 이 셋 모두 없으면 object가 자연스럽다. 단순히 "InputView니까 class"는 자동 결정이 아님.
+- **도메인 객체로 감싸기는 의미가 있을 때만.** 단순 wrapping은 표면적 추상화. 그 추상이 향후 invariants나 도메인 행위를 들 가능성이 있을 때 만들고, 아니면 미루는 것이 YAGNI에 맞음.
+- **표현 책임의 옵션:** (1) View가 도메인 객체를 받아 표현 만들기, (2) 도메인 객체의 `toString()` 오버라이딩, (3) 별도 formatter. 어떤 게 정답인지는 도메인의 특성에 따라 — 단, View가 도메인 계산을 하는 것은 보통 안티패턴.
+- **테스트 코드의 매직 넘버도 의도를 흐린다.** `4`라는 숫자 대신 `MOVE_SUCCESS_THRESHOLD` 같은 상수로 표현하면 테스트가 시나리오를 더 명확히 전달.

package/lessons/woowacourse-racingcar/Hogu59/108-1/353/213/250/352/263/204-/354/236/220/353/217/231/354/260/250-/352/262/275/354/243/274.md

@@ -0,0 +1,56 @@
+# PR #108 — [자동차 경주] 악어 미션 제출합니다
+
+- **Reviewee:** [@Hogu59](https://github.com/Hogu59)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/108
+- **단계:** 1단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 20
+
+## 잘한 점 (설계 관점)
+
+- **`require()` 활용**.
+- **상수 활용 (companion object)**.
+- **`runCatching` 활용** — 재입력 흐름에 적용.
+- **PR 질문이 명확** — 검증 위치, depth 줄이는 법, 출력 메서드 분리 등.
+
+## 못한 점 (설계 관점)
+
+- **`Race`(Controller)에서 model + controller 양쪽에 검증 분산** — 학생이 "depth 깊어진다" 자가 인식.
+- **검증 분리를 안 함 → 컨트롤러 비대**.
+- **`Car`가 data class with var** — data class + var의 문제 (equals/hashCode 동작).
+- **상수에 한정자 미적용** — 다른 곳에서 안 쓰여도 public.
+- **assertEquals 사용** — assertThat이 더 가독성.
+- **Car constructor에서 validation 직접 수행** — Validator 분리 후에도 Car 안에서 또 검증.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 메시지:
+
+1. **Validation 클래스로 분리해서 책임 시작** — "검증을 담당하는 클래스를 두어서 책임을 분리하는 것으로 시작" → model/controller 어디서든 호출 가능.
+
+2. **Depth 줄이는 두 가지 방법**:
+   - **함수 분리** — 검증 끝낸 뒤 움직임 명령
+   - **객체에 메시지 던지기** — 자동차에게 직접 메시지, 자동차 스스로 판단해 움직임. **이 두 번째가 RDD의 핵심.**
+
+3. **3줄 함수 예시** — `getCars` 안에 출력 가이드 + 검증 + 차량 생성을 3줄로 분리.
+
+4. **검증된 값만 Car constructor로 들어오게** — `Car`와 `Validation` 사이 의존성 제거. 검증은 호출 측에서 끝낸 후 깨끗한 값을 전달.
+
+5. **이름 목록 검증 vs 개별 이름 검증 분리** — 학생이 답: "예외 종류가 다르다" (목록 = 빈/중복/크기, 개별 = 길이/공백).
+
+- **대표 인용:**
+  > 객체가 자동차를 받아, 자동차에게 단지 메세지만 던져 자동차 스스로 판단해 움직일지 말지 역할을 부여하는것 또한 좋은 방법입니다. 이런식으로 역할을 분리해서 depth를 줄일 수 있습니다.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/Race.kt`
+
+  > Car 객체를 생성할때는 constructor로 들어오는 값들은 이미 검증이 완료된 상태로 들어오게 하는건 어떨까요? Car 와 Validation 간 의존성은 없어도 됩니다.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/model/Car.kt:9`
+
+## 얻은 교훈
+
+- **Depth 줄이기의 본질 = 책임 분리.** if-if-if가 늘어나면 그건 "내가 모든 걸 검증 후 판단한다"는 god-object의 신호. 각 객체에 메시지를 던져 스스로 판단하게.
+- **검증 책임의 분리 = 객체 간 의존성 제거.** Car가 검증을 알면 Car ↔ Validation 의존. Car는 "검증된 값을 받기만" 하면 의존성 없음.
+- **검증의 두 층 (목록 vs 개별)**. 컬렉션 수준 (개수, 중복) ≠ 개별 수준 (길이, 형식). 함수도 두 개.
+- **data class + var는 위험.** equals/hashCode는 주 생성자만 보는데 var면 동치성이 깨질 수 있음. data class는 immutable VO가 본업.
+- **3줄짜리 흐름 함수 = 잘 분리된 책임의 신호.** `getCars()`가 "안내 출력 → 검증 → 차량 생성" 3줄이면 각 줄이 명확한 책임을 가진 작은 메서드 호출.

package/lessons/woowacourse-racingcar/Hogu59/125-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 #125 — [자동차 경주 - 리팩토링] 악어 미션 제출합니다
+
+- **Reviewee:** [@Hogu59](https://github.com/Hogu59)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/125
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **Cars, RoundNumber, Winner를 도메인 객체로 분리** — 일급 컬렉션 + 값 객체.
+- **랜덤 생성 로직을 도메인에서 분리** — "랜덤이 도메인에 의존성 가질 이유 없음" 자가 인식.
+- **테스트가 controller가 아닌 model 단위로 재배치**.
+- **모델별 테스트 분리 + `move()` 테스트 작성**.
+- **`init` 블록 검증으로 이동 + 자가 의문** ("이게 맞나요?").
+
+## 못한 점 (설계 관점)
+
+- **`Cars`, `RoundNumber`, `Winner`가 모두 평행하게 존재** — 이들을 묶는 `RacingGame` 같은 도메인 주체 부재.
+- **컨트롤러가 여전히 상태 관리 + 우승자 판단**.
+- **`getRandomNumber`가 `kotlin.random.Random` 직접 의존** → 처음엔 테스트 불가, 학생이 분리.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 핵심 가르침:
+
+1. **"경주장(RacingGame)을 도메인 주체로"** — Cars, RoundNumber, Winner는 모두 "자동차 경주"라는 토픽에 관심. RacingGame이 이들의 상태 관리 책임을 가져야 함.
+
+2. **Controller의 책임 = 명령 + 외부 통신** — "명령은 Controller 담당. 경주장에 대한 상태 관리와 들어온 명령에 대한 판단은 경주장 몫. 차량은 자신이 얼마나 움직일지에 대한 책임." → 책임의 3층 명확화.
+
+3. **랜덤은 도메인 의존성이 아니다** — Functional Interface + 전략 패턴으로 추상화. 도메인은 인터페이스에만 의존, 테스트에서 override.
+
+4. **`move()` 테스트 부재 = 핵심 비즈니스 로직 미검증** — "가장 핵심적인 비즈니스 로직"을 빠뜨림.
+
+5. **init 검증의 trade-off** — "정답 없음. 개인적으론 모델은 비즈니스 로직 집중, 검증은 모델 밖. 하지만 모델 따라 다를 수 있음." → 학생이 매번 자기 기준을 세우길.
+
+- **대표 인용:**
+  > 지금은 경주장이 아닌 컨트롤타워에서 경주에 대한 상태, 우승자 판단 같은 것들을 혼자 다 맡아서 하고 있습니다. 때문에 테스트에서도 domain 비즈니스 로직 검증이 아닌 race 의 함수를 호출하고 있죠. 즉, 명령은 Controller 담당입니다. 경주장에 대한 상태 관리와 들어온 명령에 대한 판단은 경주장 몫입니다. 차량은 자신이 얼마나 움직일지, 얼만큼 움직였는지에 대한 책임을 갖습니다.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/Race.kt:1`
+
+  > 지금 Cars, RoundNumber, Winner 같은 클래스들로 분리가 되었는데 이들의 공통점은 자동차 경주 라는 토픽에 관심사가 있다는 것입니다. 이들이 ex. RacingGame 이라는 도메인 모델안에 들어가 관리가 된다면 어떨까요?
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/model/Cars.kt:8`
+
+  > 만약 정해진 숫자가 나온다면 함수 호출 후의 상태 변화 혹은 결과가 예측되기에 테스트를 쉽게 작성할 수 있는데요, 어떻게 하면 Car 모델에서 getRandomNumber 메소드가 Random 에 의존하지 않고 테스트 가능하게끔 할 수 있을까요?
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/model/Car.kt`
+
+## 얻은 교훈
+
+- **책임의 3층 (Controller / 도메인 주체 / 부분 객체)**:
+  - **Controller** = 외부 명령 (사용자 입력 받고 도메인에 전달)
+  - **도메인 주체** (RacingGame) = 상태 관리 + 명령 판단 (라운드 진행, 우승자 결정)
+  - **부분 객체** (Car) = 자기 행위 (움직임, 자기 위치)
+- **테스트 위치 = 책임 위치의 폭로 (재확인).** Controller에 테스트가 모이면 Controller가 도메인 책임을 가진 신호. 도메인 단위 테스트가 가능해지면 책임이 도메인으로 이동한 것.
+- **랜덤은 도메인 의존성이 아니다.** "랜덤 = 외부 비결정성", 도메인 = "결정적 규칙". 인터페이스로 둘을 분리 → 테스트에서 결정적 fake 주입.
+- **여러 도메인 객체를 *묶는 주체*가 없으면 Controller가 그 역할을 떠안는다.** Cars + RoundNumber + Winner를 묶는 RacingGame이 없으면 Controller가 "이 셋의 협력"을 직접 진행 = 책임 누수.
+- **Functional Interface = SAM (Single Abstract Method) interface** — Kotlin의 `fun interface`로 람다로도 구현 가능. 전략 패턴의 경량 형태.

package/lessons/woowacourse-racingcar/JoYehyun99/111-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 #111 — [자동차 경주 - 리팩토링] 예니 미션 제출합니다
+
+- **Reviewee:** [@JoYehyun99](https://github.com/JoYehyun99)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/111
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 14
+
+## 잘한 점 (설계 관점)
+
+- **상세한 테스트 함수명** — 1단계 피드백 흡수.
+- **trim 활용**.
+- **에러 메시지 케이스별 구분**.
+- **`Car.init`에 `require` 추가** — 도메인 invariant.
+
+## 못한 점 (설계 관점)
+
+- **`InputExceptions` 객체명** — 커스텀 예외 클래스로 오해. 실제는 유틸.
+- **List size 비교 + 리스트 비교 중복 테스트** — 군더더기.
+- **`Car.toString()` + `RacingCarGame.race()` public 메서드의 테스트 누락** — 모델 테스트 커버리지 < 100%.
+- **시도 횟수가 Controller에 — RacingCarGame이 자기 라운드 수를 모름**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong (파이로)의 가르침:
+
+1. **유틸 클래스 이름은 *유틸임이 보여야*** — `InputExceptions`는 Exception 클래스 같음. `InputUtils` 또는 `InputValidator`로.
+
+2. **요구사항 변경 시뮬레이션** — "이름 글자수와 시도 횟수는 빈번히 바뀜. 어떻게 유지보수할 것인가?" 학생: `Car.init` + `RacingCarGame` 생성자에 require → 한 곳에서 변경 가능.
+
+3. **시도 횟수의 위치 = "횟수를 관리한다는 로직"의 자리** — "조건문이 곧 로직. 로직은 모델에서 + 테스트." 학생이 한 라운드마다 출력해야 해서 Controller로 빼냈는데, 파이로는 "그럼에도 모델로" 권장.
+
+4. **모델 테스트 커버리지 100% (method 단위)** — 모델로 옮긴 = "모든 public 메서드를 테스트하겠다는 의지의 표명."
+
+5. **`toString` 책임의 회색지대** — 백엔드면 OutputView, 안드로이드면 toString 허용. 둘 다 답이 됨.
+
+- **대표 인용:**
+  > 자동차 이름의 글자수 제한과, 시도 횟수와 관련된 요구사항이 변경 되었을 때, 에러 메시지, 테스트 코드, 그리고 실제 로직 코드를 어떻게 유지보수를 하실 계획이신가요?
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/utils/InputExceptions.kt`
+
+  > "횟수를 관리" 한다는 말을 코드로 풀어보면, 결국 조건문이 된다고 생각합니다. 그리고 조건문은 튜링 머신에서 데이터가 아닌 머신 자체의 움직임인 로직을 뜻합니다. 로직은 가능한 컨트롤러가 아니라, 모델에서 담당하고 이에 대한 테스트 코드를 함께 작성하는 것을 저는 선호합니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/utils/InputExceptions.kt`
+
+  > 다른 패키지는 몰라도 model 패키지에서 만큼은 Method 의 테스트 커버리지가 100% 가 될 수 있도록 해주세요... model 에서 public 하게 공개된 모든 메서드는 테스트 코드가 작성되어야 합니다.
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/model/RacingCarGame.kt`
+
+## 얻은 교훈
+
+- **조건문 = 로직 = 모델에 있어야 함**. "관리"라는 동사가 들어가면 조건이 끼고, 조건은 모델의 자리. Controller에 조건이 모이면 로직 누수.
+- **클래스명 = *오해의 비용*을 최소화하기**. `Exceptions` 접미사는 Exception 타입 오해. 유틸은 `Utils`, 검증은 `Validator`.
+- **요구사항 변경 시뮬레이션 = 좋은 설계 검증법**. "이름 글자수 1~5 → 3~8 바뀌면?" 한 곳만 바꿔서 끝나면 OK. 여러 곳 손대야 하면 응집도 낮음.
+- **모델 메서드 = 100% 테스트 커버리지**. "이 메서드를 모델로 옮겼다 = 검증 의지." 옮긴 후 테스트 없으면 옮긴 이유 부정.
+- **toString의 회색지대**. 책임 분리 엄격 = OutputView, 안드로이드 UI 모델 = toString. 도메인 어휘로 정해진 답 없음 — 팀 컨벤션.
+- **테스트 코드는 *그 자체로* 요구사항 문서**. TDD에서 테스트가 먼저, 로직이 나중. 가독성 나쁜 테스트는 "그냥 지워버린다"는 현실 경고.

package/lessons/woowacourse-racingcar/JoYehyun99/88-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,45 @@
+# PR #88 — [자동차 경주] 예니 미션 제출합니다
+
+- **Reviewee:** [@JoYehyun99](https://github.com/JoYehyun99)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/88
+- **단계:** 1단계
+- **리뷰어:** @ghojeong
+- **라인 코멘트:** 10
+
+## 잘한 점 (설계 관점)
+
+- **`repeat` 등 코틀린 네이티브 문법 활용**.
+- **companion object로 매직넘버 상수화**.
+- **`racingCarGame` 멤버 변수 사용 의도 정당화** — "메서드마다 인자로 넘기는 것보다 간편."
+
+## 못한 점 (설계 관점)
+
+- **Exceptions의 에러 메시지가 모두 같은 공통 메시지** — 어느 상황의 오류인지 디버깅 불가.
+- **`split(", ")` (쉼표+공백)** — 요구사항은 쉼표만. trim 안 해서 공백 의존.
+- **EOF 줄바꿈 누락**.
+- **`Car.toString()` 출력 형식 보유** — OutputView 책임 침범 의문.
+
+## 리뷰어 의견 요지
+
+리뷰어 @ghojeong (파이로)의 가르침:
+
+1. **에러 메시지의 *구분* = 동료 디버깅의 시작점** — 다 같은 메시지면 어느 경로 실패인지 모름.
+2. **`split` 전 trim 습관** — JSON이 아닌 문자열 파싱에서 공백이 예기치 못한 크래시 원인.
+3. **테스트 메시지 = "어떻게 성공할 수 있는지" 동료가 즉시 알 수 있도록** — `randomNumber가 4 이상이면, 자동차가 움직인다` 같은 "~하면 ~한다" 형식.
+4. **함수 파라미터 vs 객체 멤버의 trade-off** — 멤버 = 간편, 파라미터 = 함수 순수성. 학생이 인지하고 있어 칭찬.
+
+- **대표 인용:**
+  > 에러 메세지가 무엇이 잘못되었는지 모호하고, 다 같은 공통 메시지로 되어있어서, 어떤 이유로 Exception 이 나는지 알기 어려울 것 같아요!
+  >
+  > — @ghojeong on `src/main/kotlin/racingcar/utils/Exceptions.kt`
+
+  > 가령 저는 `randomNumber 가 4 이상이면, 자동차가 움직인다.` 처럼 ~하면 ~한다 라는 형식의 테스트명을 좋아합니다. 테스트 코드는 특히나 가독성이 나쁘면, 다른 동료들이 그냥 지워버리는 개인 경험이 있어서 공유해보았습니다.
+  >
+  > — @ghojeong on `src/test/kotlin/racingcar/model/RacingCarGameTest.kt`
+
+## 얻은 교훈
+
+- **에러 메시지의 *구분* = 디버깅의 비용**. 모두 같은 메시지면 운영에서 로그 보고 원인 추정 불가. 케이스마다 다른 메시지 = 비용 거의 없는 정보.
+- **trim 습관 = 예기치 못한 크래시 방지**. 사용자 입력은 항상 trim 후 파싱.
+- **테스트 메시지 = "~하면 ~한다"**. 동료가 테스트 실패 시 *어떻게 성공시킬 수 있는지* 즉시 보임.
+- **함수 파라미터 vs 객체 멤버**. 멤버 = 매번 안 넘겨도 됨 (간편), 파라미터 = 함수 결과 예측 가능 (순수). 작은 클래스/이 함수만 쓰는 데이터 = 파라미터, 클래스 전체가 공유 = 멤버.

package/lessons/woowacourse-racingcar/Junyoung-WON/127-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,49 @@
+# PR #127 — [자동차 경주 - 리팩토링] 준영 미션 제출합니다
+
+- **Reviewee:** [@Junyoung-WON](https://github.com/Junyoung-WON)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/127
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 6
+
+## 잘한 점 (설계 관점)
+
+- **`RacingGame` 도메인 모델 도입** — 경주장.
+- **`Car.move()`로 자동차 스스로 움직임 결정** — Tell Don't Ask.
+- **kotlin.collections 활용**.
+
+## 못한 점 (설계 관점)
+
+- **Controller가 여전히 랜덤 생성 + 범위까지 정함** — 도메인 정보를 Controller가 결정.
+- **Car의 move()가 Random에 직접 의존** — 테스트 가능성 부재.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 핵심 가르침 (체스 비유):
+
+1. **Controller = 유저, RacingGame = 체스판, Car = 말** — "유저는 단지 체스판에게 어떤 말을 얼마나 움직이라고 명령할 뿐. 체스판이 상태(누가 이기고 있는지, 어떤 말들이 죽고 살았는지)를 가짐." → 책임의 3층 구조.
+
+2. **랜덤은 도메인 의존성이 아니다** — Functional Interface로 추상화. 테스트 가능성.
+
+3. **Domain ↔ Controller의 흐름** — 명령은 Controller → Domain. 상태는 Domain. 결과는 Domain → Controller → View.
+
+4. **자동차 스스로 결정 후 단위 테스트** — `move()`가 Random에 의존하면 테스트 불가. 추상화로 결정적 fake 주입.
+
+- **대표 인용:**
+  > Controller 는 Domain(model)과 상호작용을 합니다. 그리고 domain에는 여러개의 경주차량을 관리하는 경주장(RacingGame)과 여러개의 차량(car)들로 이루어져 있죠. 그런데 지금은 경주장이 아닌 컨트롤타워에서 경주에 대한 상태, 우승자 판단 같은 것들을 혼자 다 맡아서 하고 있습니다.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+  > 체스판을 예로 들어 볼게요, 체스를 플레이하는 유저는 Controller가 될 수 있을것이고, 체스판은 RacingGame이 될 수 있겠죠. 체스판에는 현재 체스판의 상태(누가 이기고 있는지, 어떤 말들이 죽고 살았는지 등등) 상태를 갖고있습니다. 유저는 단지 체스판에게 어떤 말을 얼마나 움직이라고 명령할 뿐이죠.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+## 얻은 교훈
+
+- **체스 비유 = 책임의 3층 구조**:
+  - **유저 (Controller)** = 명령만 (이 말을 저기로)
+  - **체스판 (RacingGame)** = 상태 + 명령 해석 (체스판 위에서 일어나는 모든 일)
+  - **말 (Car)** = 자기 위치 + 자기 행위 (앞으로 한 칸)
+- **랜덤은 외부 비결정성. 도메인은 결정적 규칙.** 둘이 합쳐지면 테스트 불가. 인터페이스로 분리하면 도메인은 결정적 → fake 주입으로 검증 가능.
+- **`move()`의 테스트 가능성 = 추상화의 결과**. Random 의존 = 테스트 결과 예측 불가. NumberGenerator 인터페이스 + fake → 결정적.
+- **명령-상태-행위의 흐름**. Controller가 RacingGame에게 "라운드 진행해라", RacingGame이 각 Car에게 "움직임 결정해라", Car가 NumberGenerator에게 "숫자 줘라". 메시지가 한 방향으로.

package/lessons/woowacourse-racingcar/Junyoung-WON/90-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 #90 — [자동차 경주 - 1단계] 준영 미션 제출합니다
+
+- **Reviewee:** [@Junyoung-WON](https://github.com/Junyoung-WON)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/90
+- **단계:** 1단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 14
+
+## 잘한 점 (설계 관점)
+
+- **InputView/OutputView 분리, `ValidationUtil`, `WinnerService` 등 책임 단위로 클래스 분리**.
+- **`require` 활용**, `repeat` 활용.
+- **`IllegalArgumentException` 명확히 사용** — 단순 Exception 아님.
+- **EOL 문제 원인을 *근본적으로* 파악** — CR vs LF, POSIX 표준, gcc 컴파일러 행 처리까지.
+
+## 못한 점 (설계 관점)
+
+- **GameController가 InputView, OutputView, ValidationUtil, WinnerService를 *인스턴스*로 보유** — 상태 없는 객체들이 인스턴스화 필요?
+- **try-catch로 입력 흐름 처리** — runCatching 미사용.
+- **`WinnerService` 같은 "Service" 접미사** — 객체보다 함수 모음에 가까움.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 핵심 가르침:
+
+1. **상태 없는 클래스는 object** — InputView, OutputView, ValidationUtil, WinnerService 모두 인스턴스화할 필요 없음 → object.
+
+2. **runCatching 소개** — try-catch 대신 Result 기반.
+
+3. **요구사항과 커밋의 일대일 매핑** — 같은 메시지의 중복 커밋은 의미 단위가 모호한 신호.
+
+4. **IllegalArgumentException vs 단순 Exception** — 의미 있는 예외 타입 선택.
+
+- **대표 인용:**
+  > InputView, OutputView, ValidationUtil, WinnerService 인스턴스를 GameController가 갖고 있어야 하는지 고민해보시겠어요? GameController에서 인스턴스화 할 필요 없는 클래스라면 object 키워드를 활용해보는건 어떨까요?
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/controller/GameController.kt:14`
+
+  > 어떠한 기능을 제공하는 비즈니스 로직 단위를 관리하는 클래스라면 object 활용도 고민해보시면 좋을것 같습니다.
+  >
+  > — @KwonDae on `src/main/kotlin/racingcar/service/WinnerService.kt:5`
+
+## 얻은 교훈
+
+- **상태 없음 + 함수만 = object**. InputView, ValidationUtil처럼 인스턴스마다 다른 동작을 안 가지면 object가 정답.
+- **EOL 문제는 *근본 이해*가 진짜 학습**. CR vs LF + POSIX + gcc까지 파고들면 "왜 안 되는가"가 명확. 표면 해결 (체크박스만 켜기)은 다음에 또 만남.
+- **try-catch → runCatching 이행**. Kotlin idiom의 흐름. 다음 라운드의 피드백 예고편.
+- **커밋 메시지 중복 = 책임 단위 모호의 신호**. 두 번 같은 메시지가 보이면 "이 두 변경이 *실제로 다른 작업*이었는가" 자문.
+- **`Service` 접미사의 의문**. 백엔드 관습이지만, 상태 없는 함수 모음이면 object 또는 top-level fun으로 충분. 굳이 Service 인스턴스가 필요한가?