oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/hyemdooly/50-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,48 @@
+# PR #50 — [자동차 경주] 혜미 미션 제출합니다
+
+- **Reviewee:** [@hyemdooly](https://github.com/hyemdooly)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/50
+- **단계:** 1단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 12
+
+## 잘한 점 (설계 관점)
+
+- **Cars, Car, RandomGenerator, Validator 분리**.
+- **`require` + `throw` 활용**.
+- **테스트 코드 풍부**.
+
+## 못한 점 (설계 관점)
+
+- **`RaceGame`(Controller)이 멤버 변수 다수** — 함수 결과 예측 어려움.
+- **`Cars`가 우승자 찾기까지 담당** — 책임 두 가지 (리스트 관리 + 우승자 판단).
+- **`Pair` 사용** — first/second가 무엇인지 모름. data class가 더 명확.
+- **`CarInfo`와 `Car` 프로퍼티 중복** — 캡슐화 대상 동일.
+- **0과 9 매직넘버**.
+- **`Constants.kt` class + companion object** — object가 더 적합.
+- **테스트에 두 케이스 한 함수** — 분리 권장.
+- **`CarsHelper`라는 모호한 Helper 접미사**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @BeokBeok의 메시지:
+
+1. **Pair 회피 → data class** — first/second는 의미 미상.
+2. **Cars의 책임 = 리스트 관리, 우승자는 별도 객체** — 두 책임을 한 클래스에 넣지 말 것.
+3. **`!!` 회피, 멤버 변수 회피** (의존성 주입 글 인용).
+4. **테스트 케이스는 한 함수 = 한 시나리오**.
+
+- **대표 인용:**
+  > Pair는 두 개의 값을 편하게 wrapping할 수 있다는 장점이 있지만, first와 second가 어떤 것을 의미하는지 알기가 어렵습니다. Pair 대신 data class를 활용해보면 어떨까요?
+  >
+  > — @BeokBeok on `src/main/kotlin/model/Cars.kt`
+
+  > 하지만 Cars 클래스는 자동차의 리스트를 관리하는 책임을 가지고 있는데, 우승자를 찾는 함수로 인하여 우승자를 관리하는 책임까지 가지게 됩니다. 우승자를 찾는 책임을 갖는 클래스를 만들어보면 어떨까요?
+  >
+  > — @BeokBeok on `src/main/kotlin/model/Cars.kt`
+
+## 얻은 교훈
+
+- **Pair는 *지름길*이지 *설계*가 아님**. 두 값이 영구히 함께 다닐 거면 data class. 일회용 반환이면 Pair OK.
+- **일급 컬렉션의 책임 = 컬렉션 관리만**. 우승자 판단 같은 비즈니스 로직은 별도 객체. 일급 컬렉션이 god-object 되지 않게.
+- **`Helper`/`Manager` 접미사 회피**. 클래스가 *무엇을* 돕는지 이름에 명시.

package/lessons/woowacourse-racingcar/hyemdooly/68-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 #68 — [자동차 경주 - 리팩토링] 혜미 미션 제출합니다
+
+- **Reviewee:** [@hyemdooly](https://github.com/hyemdooly)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/68
+- **단계:** 1단계 (리팩토링)
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 11
+
+## 잘한 점 (설계 관점)
+
+- **검증을 Controller로, 재입력 흐름 분리**.
+- **방어적 복사 적용**.
+- **backing property + custom getter 시도**.
+
+## 못한 점 (설계 관점)
+
+- **`Cars.move()`가 함수 내부에서 랜덤 생성** — 테스트 불가.
+- **`Validator`가 OutputView 의존** — Controller 아닌 곳이 View 의존.
+- **`CarsHelper` 여전히 모호한 이름**.
+- **InputView에서 null 시 자기 재호출** — InputView 책임 침범.
+- **`executeInputTryNumber` 같이 동사 두 개 (간접 호출)**.
+- **backing property를 *생성자*에서 _xxx로** — 코틀린 컨벤션은 별도 위치.
+
+## 리뷰어 의견 요지
+
+리뷰어 @BeokBeok의 메시지:
+
+1. **간접 호출의 함정** — `executeInputTryNumber` = "execute" + "input". 동사 두 개. 함수는 한 동사.
+
+2. **backing property 컨벤션** — 생성자에 `_xxx` 두지 말고, 클래스 body에서 별도 선언.
+
+3. **빈 리스트 = `emptyList()` (가독성)**.
+
+4. **랜덤 의존성 분리** — `Cars.move` 안에 랜덤이 있으면 테스트 불가. 외부에서 주입.
+
+5. **Validator의 View 의존 제거** — Validator는 도메인 검증만, View는 Controller가 다룸.
+
+- **대표 인용:**
+  > executeInputTryNumber함수보다는 inputTryNumber라는 함수가 더 잘 이해가 돼요. executeInputTryNumber함수를 사용하는 것을 "간접 호출"이라고 합니다. "간접 호출"은 유용한 경우도 많지만, 자칫 잘못하게 되면 과하게 함수를 호출하게 되는 상황을 만들기도 해요.
+  >
+  > — @BeokBeok on `src/main/kotlin/controller/RaceGame.kt`
+
+  > domain과 view에 둘 다 접근이 가능한 것은 Controller입니다. Controller의 역할에 대해서 다시 한번 학습해보시고, Validator는 Controller가 아니므로 OutputView의 의존성을 제거해보면 어떨까요?
+  >
+  > — @BeokBeok on `src/main/kotlin/util/Validator.kt`
+
+## 얻은 교훈
+
+- **함수명에 동사는 *하나만***. `executeInput` = 두 동사. `executeXxx` 같은 간접 호출은 단순 `xxx`로 충분.
+- **backing property는 *body 선언***. 생성자에 `_xxx`는 컨벤션 위반.
+- **`emptyList()` vs `listOf()`** — 의미 명시.
+- **랜덤은 함수 안이 아닌 *주입*으로**. 함수 안에 두면 테스트 시 결정적 결과 불가.
+- **Validator의 View 의존 = 의존 방향 거꾸로**. Validator는 가장 안쪽 (도메인 가까이), View는 가장 바깥 (UI). 안쪽이 바깥을 알면 의존 역전.

package/lessons/woowacourse-racingcar/hyunji1203/29-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 #29 — [뽀또] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@hyunji1203](https://github.com/hyunji1203)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/29
+- **단계:** 1단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 14
+
+## 잘한 점 (설계 관점)
+
+- **`NumberGenerator` 인터페이스 + 분리** — 리뷰어 명시적 칭찬.
+- **Fake 객체로 결정적 테스트** — 리뷰어 칭찬.
+- **생성자 주입 적용** — 리뷰어 칭찬.
+- **테스트 코드 적극 작성** — 리뷰어 💯.
+
+## 못한 점 (설계 관점)
+
+- **`lateinit var cars`로 지연 초기화** — 초기화 전 호출 시 에러 위험. 학생이 디폴트값 또는 생성자 주입으로 변경.
+- **`resources/String.kt`로 문자열 모음** — 안드로이드 리소스 비슷. 결합도 증가.
+- **`","`, `"-"` 매직 리터럴 인라인** — 상수화 가능.
+- **테스트 이름 추상화** — "잘 작동하는지" 등 모호.
+- **`GameController`가 `racingManager.over`를 알아야** — Controller 관심사가 아님. 메시지 위임으로.
+- **`Fake` 객체에 list를 생성자 주입 안 함** — 재활용 어려움.
+- **`result` 같은 모호한 변수명**.
+- **`mutableListOf`를 val 대신 var로** — 가변 컬렉션이면 불변 변수가 자연스러움.
+
+## 리뷰어 의견 요지
+
+리뷰어 @namjackson는 lateinit의 위험성을 짚으면서 **"초기화를 강제하는 다른 방법(디폴트, 생성자 주입)"** 가이드. 학생이 즉시 흡수.
+
+또한 **"GameController가 race over를 안다 = 관심사 침해"** 라는 가이드 — 그 결정은 RacingManager가 직접 해야. Tell-Don't-Ask와 책임 위임의 명확한 적용.
+
+테스트 이름 명세화와 Given-When-Then 패턴 가이드는 다른 reviewees와 동일.
+
+- **대표 인용:**
+  > lateinit는 초기화를 지연시킬수 있지만, 한편으로는 초기화 이전에 호출이 된다면 에러가 발생하곤 합니다! ... 디폴드값을 사용하거나, 생상자로 주입받는 방식 등이 있을거같은데, 고민해보셔도 좋을거같아요!
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/domain/RacingManager.kt`
+
+  > GameController에서는 레이싱이 종료되었는지는 불필요한 관심사가 아닐까요? RacingManager 에게 메세지를 보내 race를 진행하는 책임을 위임해보면 어떨까요?
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/controller/GameController.kt`
+
+  > "Car 객체의 이름은 1자 이상 5자 이하만 가능"이라는 테스트 케이스지만, 실제로는 ... 공백이나 6글자 이상의 이름으로 Car 객체 생성시, IllegalArgumentException 에러가 발생하는 부분을 테스트하고 있어요!
+  >
+  > — @namjackson on `src/test/kotlin/racingcar/domain/CarTest.kt`
+
+## 얻은 교훈
+
+- **lateinit의 위험.** 초기화 전 접근 시 UninitializedPropertyAccessException. 생성자 주입 또는 디폴트값이 더 안전.
+- **`Controller`가 도메인 상태(over)를 알면 책임 침해.** 도메인 객체가 자기 흐름을 알고 메시지로 진행 결과 알림.
+- **테스트 이름과 검증 대상의 일치.** "1~5자 정상" 테스트가 실제로 "공백/6글자 예외"를 검증하면 이름이 거짓말. 한 테스트에 한 시나리오.
+- **변수 가변성과 변수 자체의 가변성 분리.** `var mutableListOf<X>()`는 변수와 컬렉션 모두 가변. 컬렉션이 가변이면 변수는 보통 val로.
+- **자료 추천 → 학생 흡수 → 적용** 의 학습 사이클이 한 PR에 다수 사례. lateinit 가이드 + 책임 위임 가이드 모두 학생이 즉시 반영.

package/lessons/woowacourse-racingcar/hyunji1203/60-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 #60 — [뽀또] 2단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@hyunji1203](https://github.com/hyunji1203)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/60
+- **단계:** 2단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 20
+
+## 잘한 점 (설계 관점)
+
+- **`RaceResultDto` 도입 → 후속 라운드에서 삭제** — 필요 없음을 자기 회고로 인식.
+- **`RaceManager`가 생성자로 names/count를 받도록 수정** — 사전 setGame 호출 제거.
+- **자기 결정의 깊은 회고** — "Car의 기준이 변경되거나 이동 거리가 다양해진다면 Car에 책임 부여"라는 자기 판단을 명확히 표명.
+
+## 못한 점 (설계 관점)
+
+- **`Car.location` 외부 수정 가능** — 원래대로 되돌렸지만 캡슐화 인식 필요.
+- **`RaceResultDto`가 `List<List<Int>>` 사용** — 데이터 구조 의미 모호. names + cars 중복.
+- **`Application.kt` main 함수가 비대** — 초기화 + 실행 흐름을 모두 처리.
+- **roundHistory를 함수 내부 참조 방식으로 수정** — 반환값 사용이 더 단순.
+- **테스트 이름이 모호** — "RaceResultDto 정상 반환 확인"이 무엇을 검증하는지 모름.
+
+## 리뷰어 의견 요지
+
+리뷰어 @namjackson는 **"이중 리스트 = 데이터 구조 신호"** 라는 가이드를 반복. `List<List<Int>>`가 보이면 항상 도메인 객체로 wrapping 후보. 자동차별 히스토리인지 step별 히스토리인지 시그니처만으로 모름.
+
+또한 **"setGame 호출 제약 = 생성자로 해결"** — 객체가 사용되기 전 별도 설정 메서드가 필요하면 그것은 깨지기 쉬운 API. 생성자에서 모두 받아 즉시 사용 가능한 상태로.
+
+학생이 "다양한 기준 → Car에 책임"이라는 답에 도달한 회고가 인상적 — 외부 Manager가 늘어나는 패턴을 피하려는 사고가 자연스럽게 객체에 책임 부여로 이어짐.
+
+- **대표 인용:**
+  > List<List<Int>> 이중 리스트 구조는 어떤 데이터구조인지 알기가 힘들어지는데, List<Int>를 래핑해보면 어떨까요?
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/domain/RaceResultDto.kt`
+
+  > 현재의 RaceManager는 race이전에 setGame을 호출해야하는 제약사항이 있어요! 기본값을 선언해주셔서, 에러는 나지않지만, 구현부를 보기전엔 이러한 제약사항을 파악하기는 힘들수도 있다는 생각이 들어요!
+  >
+  > — @namjackson on `src/main/kotlin/racingcar/domain/RaceManager.kt`
+
+  > "RaceResultDto 정상 반환 확인" 이라는 테스트 케이스명과 같은 모호한 이름은, 정상 반환에 대한 요구사항을 먼저 살펴봐야할것 같아요.
+  >
+  > — @namjackson on `src/test/kotlin/racingcar/domain/RaceManagerTest.kt`
+
+## 얻은 교훈
+
+- **이중 컬렉션은 도메인 모델 누락의 신호.** `List<List<Int>>` / `Map<X, List<Y>>` 등이 보이면 의미 모호. 도메인 객체로 wrap.
+- **생성과 사용 사이에 setup 메서드는 깨지기 쉬운 API.** 생성자가 끝나면 즉시 사용 가능해야. 별도 setX() 호출이 필요하면 사용자가 그 순서를 학습해야.
+- **객체 책임 부여의 본질 = "외부 관리자 늘어남"의 회피.** Car 책임을 외부 Manager로 빼면 다양한 기준마다 새 Manager. Car 자신이 책임을 들면 확장이 Car의 변경으로 모임.
+- **테스트 이름은 시나리오를 표현.** "정상 반환"은 무엇이 어떤 상태에서 어떤 반환을 하는지 안 알려줌. "2라운드 실행 시 2라운드 히스토리 반환" 같은 시나리오.
+- **자기 회고를 통한 결정 = 진짜 학습.** 학생이 "기준이 다양해질 때 Car에 책임"이라는 답을 자기 추론으로 도달. 리뷰어의 가이드가 그 추론을 끌어냄.

package/lessons/woowacourse-racingcar/ii2001/102-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,42 @@
+# PR #102 — [자동차 경주] 인기 미션 제출합니다
+
+- **Reviewee:** [@ii2001](https://github.com/ii2001)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/102
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 8
+
+## 잘한 점 (설계 관점)
+
+- **InputView/OutputView/model 분리**.
+
+## 못한 점 (설계 관점)
+
+- **`main.kt`의 함수명이 명사** — 동사 컨벤션 위반.
+- **`Car.position`이 String 타입** — 표현용 String을 도메인에 둠. Int가 도메인 의미.
+- **`racing.kt`가 함수만 모아둠** — 클래스로 묶어야 Controller가 비즈니스 로직 직접 처리 안 함.
+- **`goOrStop` 함수명 모호** — 무엇을 하는지 본문 봐야.
+- **테스트 누락** — 입력값 검증, 자동차 움직임.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 메시지:
+
+1. **함수 이름 = 동사형 (코드 컨벤션)**.
+
+2. **도메인 타입 = 도메인 의미를 반영** — position이 *증가/감소 가능한 성질*이면 Int. String으로 두면 표현 형식이 도메인을 침범.
+
+3. **함수 모음 파일 → 클래스로 묶기**. 함수만 노출하면 Controller가 비즈니스 로직을 *직접 호출*. MVC의 model 의미가 없어짐.
+
+4. **테스트 커버리지 = 입력 검증 + 자동차 움직임 필수**.
+
+- **대표 인용:**
+  > position 을 String 타입으로 선언해주신 것은 실제로 postiion 을 표현 할 때 String 타입으로 이용되기 때문이라고 생각되는데요. model 의 경우 보통 도메인을 표현하는 영역이므로 실제 동작의 속성을 지켜주면 좋다고 생각합니다. position 은 증가(혹은 감소) 할 수 있는 성질이 있으므로, 숫자 타입으로 선언되면 좀 더 활용할 수 있는 범위가 넓지 않을까요~?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/model/Car.kt`
+
+## 얻은 교훈
+
+- **도메인 타입 ≠ 표현 형식**. position이 표시에 String으로 쓰이더라도, 도메인은 *Int* (증가/감소 가능한 성질). 표현은 OutputView가 변환.
+- **함수만 노출하는 model = 책임 누수**. Controller가 함수들을 직접 부르면 비즈니스 흐름이 Controller에 모임. model이 클래스로 묶여야 책임이 분배.
+- **테스트 부재 = 검증 의지 부재**. "이 검증이 가치 있다"고 판단해서 model로 옮겼다면 *반드시* 테스트.

package/lessons/woowacourse-racingcar/ii2001/122-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 #122 — [자동차 경주 - 리팩토링] 인기 미션 제출합니다
+
+- **Reviewee:** [@ii2001](https://github.com/ii2001)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/122
+- **단계:** 1단계 (리팩토링)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 10
+
+## 잘한 점 (설계 관점)
+
+- **backing property 도입**.
+- **자동차 이름 검증** + 입력값 메시지 표시.
+- **상수화 진행**.
+
+## 못한 점 (설계 관점)
+
+- **`Car`가 여전히 var 선언 (외부 변경 가능)** — backing property로 보완.
+- **`racing.kt` 함수 모음 잔존** — 클래스로 묶지 않음.
+- **상수 옆 주석으로 부연** — 변경 시 주석도 동기화 필요.
+- **`-` 매직 문자열 (출력)** — 상수화.
+- **포매팅 (reformat) 누락**.
+- **private 가시성 일부 누락**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 메시지:
+
+1. **`var position; private set`이 backing property보다 *간결*** — 같은 효과, 변수 하나.
+
+2. **함수 모음 → 클래스 캡슐화 재강조** — "객체를 객체스럽게" 글 인용. 함수만 제공 시 Controller-model 구분 무의미.
+
+3. **주석 → 상수로 표현력 대체**. 상수 이름이 의미를 담으면 주석 불필요. 주석은 변경 동기화 부담.
+
+4. **reformat IDE 기능 활용**.
+
+- **대표 인용:**
+  > 해당 파일의 함수들을 적절한 클래스로 묶어서 클래스 내부에서 처리해볼 수 있을까요? 이러한 방식으로 함수만 제공이 될 경우 controller 에서 모든 비즈니스 로직을 직접 처리해야하는데, 이 경우 controller 와 model 을 나눈 의미가 없어질 것 같아요.
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/model/racing.kt`
+
+  > 주석으로 추가 정보를 남겨주는 것도 좋지만, 이럴 경우 요구사항이 바뀔때마다 주석도 같이 변경되어야하므로 관리포인트가 늘어난다고 할 수 있습니다. "-" 값을 상수로 선언하고 활용한다면 주석 없이도 충분히 설명력 있는 코드가 되지 않을까요?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/view/output.kt`
+
+## 얻은 교훈
+
+- **`private set` vs backing property**. 원시값이면 `private set`이 변수 1개로 충분. 컬렉션은 mutableXXX 외부 노출 회피로 backing property 필요.
+- **주석은 코드의 *복사본*이 아닌 *이유***. 의미는 상수 이름에, 주석은 *왜* 필요한지.
+- **함수 모음 = 객체지향 아님**. 클래스로 묶으면 *상태*와 *행위*가 한 곳에. 협력자도 명확.

package/lessons/woowacourse-racingcar/ijh1298/144-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 #144 — [자동차 경주] 크림 미션 제출합니다
+
+- **Reviewee:** [@ijh1298](https://github.com/ijh1298)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/144
+- **단계:** 2단계
+- **리뷰어:** @lee-ji-hoon
+- **라인 코멘트:** 27
+
+## 잘한 점 (설계 관점)
+
+- **Validator를 별도 클래스로 분리** — 책임 분리 시도.
+- **자기 의문을 PR에 명시 (object vs class, lateinit, validation 위치)** — 토론의 시작점 풍부.
+- **피드백 흡수 후 자기 근거 재정리** — "RacingController는 cars만 받아 racing 흐름만 관리"로 수정.
+
+## 못한 점 (설계 관점)
+
+- **`RacingController.run`이 너무 많은 일** — input validation, view 호출, racing 진행, 결과 출력까지.
+- **Controller가 `lateinit var`로 입력값을 필드에 보관** — `run`이 비대해진 신호. 지역 변수로 충분.
+- **Controller가 InputView/OutputView 직접 의존** — "Racing을 진행한다"는 책임에 IO는 불필요.
+- **`Car.move(randomNum)`가 외부에서 받은 숫자가 임계값 넘는지 판단** — Car가 알 일 아님. 경기 규칙(>=4)도 Car의 자리 아님.
+- **`InputValidator` 분리는 했지만 어디서 호출될지 모호** — 클래스만 만들고 자리 미정.
+- **Car init 블록에 validate 옮김 (근거 없이)** — 다른 크루 따라함.
+- **`RandomGenerator` object의 테스트성 문제 미인지** — 싱글톤 = 모킹 어려움.
+
+## 리뷰어 의견 요지
+
+리뷰어 @lee-ji-hoon은 **"질문으로 학생 스스로 답을 찾게 하는" 스타일**의 리뷰. 직접 정답을 주지 않고 "이 클래스가 이 일을 하는 게 맞을까?"를 반복.
+
+1. **Controller의 본질 질문** — "MVC 모르는 상태에서 Controller가 View를 의존할 필요가 있을까?" → 학생이 View 의존성 제거하자 다음 리팩토링에서 더 깊게 다루자고 예고.
+
+2. **`move()` 책임** — "Car는 그냥 move() 호출되면 움직여야 하는 거 아닐까?" → 임계값 판단은 경기 규칙, Car가 알 일 아님. 학생이 SRP 위반 인지.
+
+3. **object 테스트성** — "object라고 무조건 테스트 어려운 건 아니다 (validateEmail 같은 순수 함수). 그럼 *언제* 어려운가?"를 스스로 생각하게.
+
+4. **Validation 위치는 학생의 기준** — "리뷰어들이 의견을 남길 테니 항상 본인 의견을 이야기하는 습관"이 더 중요.
+
+- **대표 인용:**
+  > Racing을 run 할 때 사용할 함수들인데 지역 변수로 빼는게 더 깔끔해보이는 이유는 run이 너무 많은 역할을 하고 있기 때문이 아닐까요?
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/controller/RacingController.kt`
+
+  > RacingController 입장에서 생성이 될 때 Input / Output View들을 알아야 할 이유가 있을까요? RacingController 의 역할은 Racing을 진행하고 그 결과를 보여줘야 하지 않을까 하는데
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/controller/RacingController.kt`
+
+  > move라는 함수 역할 기준으로 봤을 때 randomNum 이라는 파라미터를 받는 것과 여기서 STANDARD_NUMBER 를 넘는지 받는게 맞을까요?
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/domain/Car.kt`
+
+## 얻은 교훈
+
+- **"지역 변수로 빼면 깔끔해진다"는 메서드가 비대하다는 신호.** lateinit var의 유혹은 보통 한 메서드가 여러 책임을 갖기 때문에 생긴다. 책임을 쪼개면 변수는 따라 들어간다.
+- **Controller의 본질은 "흐름 제어"이지 "IO 보유"가 아니다.** Racing을 진행하는 객체가 InputView를 알아야 할 이유는 없다.
+- **메서드 이름의 약속 = 그 안의 코드.** `move()`는 움직임만, `moveOrStop()`은 조건 판단까지. 이름이 SRP를 강제.
+- **다른 사람의 패턴을 자기 근거 없이 따라하지 말 것.** "다른 크루가 init에서 validate하길래"는 결국 자기 코드에 정착하지 않는다.
+- **object의 단위 테스트 어려움은 "싱글톤 + 의존 모킹"의 조합 문제이지 object 자체 문제가 아니다.** 순수 함수 object는 멀쩡히 테스트 가능.
+- **리뷰는 답을 주는 게 아니라 질문으로 학생의 기준을 만들게 하는 도구** — 학생이 매번 "내 의견은 이렇다"로 말하는 게 다음 단계.

package/lessons/woowacourse-racingcar/injoon2019/24-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,58 @@
+# PR #24 — [자동차 경주] 콩하 미션 제출합니다
+
+- **Reviewee:** [@injoon2019](https://github.com/injoon2019)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/24
+- **단계:** 2단계 (단일 PR, 3 reviewers)
+- **리뷰어:** @kbsat, @cjlee38, @jayjaehunchoi
+- **라인 코멘트:** 18
+
+## 잘한 점 (설계 관점)
+
+- **Position 별도 객체** — 원시 강박 탈출.
+- **`AlwaysMoveStrategy` 인터페이스 + 전략 패턴** — 테스트용 결정적 전략.
+- **Cars 일급 컬렉션 후보** — `cars.map { it.moveForward(strategy) }`.
+
+## 못한 점 (설계 관점)
+
+- **Position의 디폴트 값 처리 미흡** — 보조 생성자 대신 디폴트 인자.
+- **Car.move가 전략을 안 받음** — 인터페이스 만들어놓고 미적용.
+- **Position 검증 `if-throw` 대신 require/check 미사용**.
+- **테스트 코드 어색함** — Position 비교를 `isSamePosition()` 대신 `==`로 충분.
+
+## 리뷰어 의견 요지
+
+3명의 리뷰어가 협력해서 코틀린 idiom + OOP 개념을 토론.
+
+1. **`require`/`check`로 검증 단순화** — 코틀린 idiom. `IllegalArgumentException` 자동.
+
+2. **식이 본문인 함수** — `override fun isMovable(): Boolean = true`. 한 줄 함수는 `=` 표현.
+
+3. **kotest 도입 권장** — `shouldBeTrue()`, `shouldThrow<>`, `position1 shouldBe position2` 같은 자연스러운 DSL.
+
+4. **companion object의 의미** — "특정 클래스의 support 역할, static과는 다른 녀석" (cjlee38 인용 블로그).
+
+5. **인터페이스 만들고 미적용** — Strategy 인터페이스가 Car에 적용되어 있나? 학생 답: "Cars에 적용. Car에는 미적용."
+
+6. **`maxByOrNull` 같은 안전 컬렉션 API**.
+
+- **대표 인용:**
+  > 이미 보셨을수도 있지만 [bsidesoft.com 링크] companion object 는 특정 클래스의 support 역할을 해주는, static 과는 조금 다른 녀석이라고 생각해요.
+  >
+  > — @cjlee38 on `src/main/kotlin/racingcar/domain/Cars.kt:16`
+
+  > 전략 안쓰는데요? 😋
+  >
+  > — @kbsat on `src/main/kotlin/racingcar/domain/Car.kt`
+
+  > 모든 중괄호를 개행할 필요는 없을것같네용
+  >
+  > — @cjlee38 on `src/main/kotlin/racingcar/domain/Cars.kt`
+
+## 얻은 교훈
+
+- **인터페이스를 만들었다면 *반드시 사용*하기**. 전략 패턴 인터페이스 만들고 Car에 안 쓰면 "선언만 한 죽은 추상". 리뷰어가 즉시 잡음.
+- **`require` + `check`의 의미 차이**. `require` = 인자 검증 (IllegalArgumentException), `check` = 상태 검증 (IllegalStateException). 사용자 입력 = require, 객체 내부 invariant = check.
+- **companion object ≠ Java static**. Companion은 *그 클래스의 컴패니언 인스턴스*. 메서드/속성도 일반 클래스처럼 가질 수 있음. 진정한 static은 Kotlin에서 top-level이나 `@JvmStatic`.
+- **kotest의 DSL** = "사람이 읽는 영어 문장". `position1 shouldBe position2`는 assertion이 아니라 *주장*처럼 읽힘. 테스트 가독성에 큰 이점.
+- **여러 리뷰어가 한 PR에 모이면 협력적 학습** — 각자 다른 관점 (코틀린 idiom, OOP, 테스트). 학생이 한 라운드에 여러 깊이의 토론을 동시에 받음.
+- **`maxByOrNull` = 안전 default 미반환**. 빈 컬렉션 시 null 반환 → null 처리 강제. 빈 컬렉션에서 max 부르는 잠재적 NPE 차단.

package/lessons/woowacourse-racingcar/inseonyun/44-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 #44 — [자동차 경주 - 1단계] 인선 미션 제출합니다
+
+- **Reviewee:** [@inseonyun](https://github.com/inseonyun)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/44
+- **단계:** 1단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **Controller, View, Model, Exception 패키지 분리** — MVC 의식.
+- **`NameException`, `TryCountException` 별도 객체로 검증 분리**.
+- **메시지 상수 `ExceptionMessage` 분리**.
+
+## 못한 점 (설계 관점)
+
+- **Controller가 멤버 변수 다수 보유** — 함수 호출마다 결과 예측 어려움 (의존성 주입 글 참고).
+- **`getCarNames()` 같은 함수가 *반환 안 함*** — 이름이 거짓말.
+- **`NameException`, `TryCountException` 이름이 Exception이지만 *Exception 타입 아님*** — 검증 객체에 Exception 접미사.
+- **`ExceptionMessage`가 class with companion object** — 캡슐화할 게 없으면 object.
+- **재귀 입력 호출이 Controller에서 발생** — 입력 책임은 InputView에.
+- **`DEFAULT_TRY_COUNT` private 미적용** — 외부 공개 불필요.
+- **`DomainTest`가 여러 도메인 테스트** — Test 클래스는 1:1 매핑이 표준.
+- **요구사항 체크박스 미반영** — README 진행 상태 불일치.
+- **테스트 함수명에 "테스트" 단어 중복**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @BeokBeok의 핵심 가르침:
+
+1. **멤버 변수 의존 vs 의존성 주입** — "멤버 변수에 따라 함수 호출 시 결과가 매번 달라져 예측 어려움." Imposter's Guide to DI 글 인용.
+
+2. **함수명 = 외부에서 본 행위 + 반환값** — `getCarNames()`가 안 반환하면 거짓말. `setupCarNames()` 같은 이름이 진실.
+
+3. **클래스명 = 그 클래스의 *책임*** — `Exception` 접미사인데 Exception 타입 아니면 동료 혼란. `Validation` 접미사로 바꿔야.
+
+4. **`require`/`check` vs 조건문 throw** — require/check가 가독성, 스마트캐스팅 이점. 코틀린 idiom에 가까움.
+
+5. **클래스 vs object 선택 기준** — "클래스는 최소 하나의 캡슐화. 그렇지 않으면 object." 상수만 있는 클래스는 object로.
+
+- **대표 인용:**
+  > 멤버 변수를 활용하면 클래스 내부에서 값을 편하게 가져다 쓸 수 있는 장점이 있지만, 멤버 변수의 값에 따라 함수 호출 시 결과가 매번 달라지게 되서, 함수의 결괏값을 예측하기가 어려워져요.
+  >
+  > — @BeokBeok on `src/main/kotlin/controller/RacingGameController.kt`
+
+  > 클래스명을 보니 Exception을 custom한 것으로 보이지만, 실제로는 Exception 타입이 아니네요. 이 클래스가 하는 책임에 대해서 다시 한번 고민해보면 어떨까요?
+  >
+  > — @BeokBeok on `src/main/kotlin/exception/TryCountException.kt`
+
+  > 대체로 클래스는 최소한 하나 이상을 캡슐화를 해야합니다. 그렇지 않으면, 클래스를 사용하는 것 보다는 object를 사용하는 것을 권장합니다.
+  >
+  > — @BeokBeok on `src/main/kotlin/message/ExceptionMessage.kt`
+
+## 얻은 교훈
+
+- **멤버 변수는 *함수의 입력*을 가린다.** 같은 함수를 두 번 호출해도 멤버 변수가 바뀌었으면 다른 결과. *순수 함수*로 갈수록 예측 가능, 테스트 가능.
+- **클래스명 = 책임 ≠ 사용처**. "Exception" 접미사는 *Exception 타입*을 의미. 검증 객체는 `Validation` / `Validator`. 이름은 사용자가 *유추할 수 있는* 의미여야.
+- **`require`/`check`의 가독성 이점** — `if (!cond) throw ...` 5줄이 `require(cond) { msg }` 1줄. 스마트캐스팅도 자연스럽게 적용.
+- **클래스 = 캡슐화. object = static.** 상수만 있는 클래스는 캡슐화할 게 없음 → object.
+- **Test 클래스 1:1 매핑**. `CarTest`는 Car만, `CarsTest`는 Cars만. `DomainTest`처럼 묶으면 어디서 무엇이 깨졌는지 추적 어려움.

package/lessons/woowacourse-racingcar/inseonyun/76-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 #76 — [자동차 경주 - 2단계] 인선 미션 제출합니다
+
+- **Reviewee:** [@inseonyun](https://github.com/inseonyun)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/76
+- **단계:** 2단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 8
+
+## 잘한 점 (설계 관점)
+
+- **`Validation` 클래스로 검증 책임 분리** — Exception 이름 → Validation.
+- **`Service` 레이어 도입** — 도메인 비즈니스 로직 분리.
+
+## 못한 점 (설계 관점)
+
+- **`NameValidation`이 OutputView 의존** — Validation은 Controller도 View도 아닌데 View를 알면 안 됨.
+- **InputView에서 입력값 유효할 때까지 반복** — InputView의 책임 확장.
+- **`RacingCarGameService.kt`에 출력 문구 작성** — 출력은 OutputView 책임.
+
+## 리뷰어 의견 요지
+
+리뷰어 @BeokBeok의 메시지:
+
+1. **Validation의 의존 방향** — "Validation은 Controller가 아닙니다. 즉, View와 관련된 의존성을 가지면 안 됩니다." Validation = 순수 검증 함수, 결과는 호출 측이 판단.
+
+2. **InputView의 책임 재정의** — "InputView는 입력값을 받아서 전달하는 역할일 뿐. 올바른 입력값을 받을 때까지 계속 호출하는 것과는 별개." 반복은 호출 측이.
+
+3. **재귀 입력의 *적절한 자리*** — "inputName()을 호출한 곳에서 반환값을 판단. 유효하지 않으면 inputName()을 다시 한 번 호출." → 호출 측의 책임.
+
+4. **출력 책임 일원화** — Service에 출력 문구 만들지 말 것. OutputView로.
+
+5. **"유효한 값을 받을 때까지 종료되지 않는다는 요구사항은 없다"** — 학생이 만든 가상의 요구사항으로 책임이 부풀어 오름.
+
+- **대표 인용:**
+  > Validation은 Controller가 아닙니다. 즉, View와 관련된 의존성을 가지면 안됩니다. OutView의 의존성을 가지지 않도록 코드를 개선해보면 어떨까요?
+  >
+  > — @BeokBeok on `src/main/kotlin/validation/NameValidation.kt`
+
+  > InputView가 어떤 책임을 갖는지 다시 한번 생각해보시면 좋을 것 같아요. InputView는 입력값을 받아서 전달하는 역할을 할 뿐이지, 올바른 입력값을 받을때까지 계속해서 호출하는 것과는 별개입니다.
+  >
+  > — @BeokBeok on `src/main/kotlin/view/InputView.kt`
+
+  > 참고로 프로그래밍 요구사항에는 "유효한 값을 받을때까지 프로그램이 종료되지 않는다"와 같은 항목은 없습니다. 😅
+  >
+  > — @BeokBeok on `src/main/kotlin/view/InputView.kt`
+
+## 얻은 교훈
+
+- **Validation의 의존 방향 = 순수 함수에 가깝게**. View나 Controller 의존 없이 입력 → 결과 (bool/exception). 결과 해석은 호출 측.
+- **InputView의 책임 = "받아서 넘기기"**. 검증, 재시도, 형식 변환은 모두 호출 측 (Controller) 또는 Validation. View가 너무 많이 하면 동료가 InputView 안에서 비즈니스 로직 추적해야 함.
+- **재귀 입력은 *호출 측*에서**. View가 재귀 호출하면 View가 흐름 제어. 호출 측에서 `validate(input) ? input : inputView.read()` 형태가 깨끗.
+- **자가 요구사항 생성의 위험**. "유효한 값까지 종료되지 않게"라는 요구사항이 없는데 학생이 가정. 그 가정이 책임 누수의 원인.
+- **출력 책임 일원화**. 출력 문구가 도메인/Service/Controller 어디에든 생기면 변경 시 추적 어려움. OutputView 한 곳에.

package/lessons/woowacourse-racingcar/ippnsj/36-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 #36 — [글로] 코틀린 자동차 경주 제출합니다
+
+- **Reviewee:** [@ippnsj](https://github.com/ippnsj)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/36
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 12
+
+## 잘한 점 (설계 관점)
+
+- **DTO 패턴 도입 시도** — CarsDTO, WinnersDTO로 데이터 운반 책임 분리.
+- **`Judgement` 별도 객체** — 우승자 판별 책임 분리 시도.
+- **`NumberGenerator` 분리**.
+
+## 못한 점 (설계 관점)
+
+- **`CarsDTO`가 검증 + 가공 수행** — DTO의 정체성 위반. DTO는 단순 데이터 운반.
+- **`Controller`에 cars 멤버 변수** — 게임 단위 라이프사이클.
+- **`Controller.inputCarNames(): Boolean`** — 자동차를 받을 것 같은 메서드명이 Boolean 반환.
+- **`Judgement`의 우승자 알고리즘 복잡** — O(n) 두 번이 O(2n)에 비해 더 단순/가독.
+- **`Car.checkGo(number)`가 in range 비교** — `in 4..9` 같은 코틀린 표현 활용 가능.
+- **테스트가 production 로직으로 데이터 빌드** — 변경에 약함. 하드코딩이 더 안정.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 **DTO의 정체성** 을 강하게 짚었다. "이름 그대로 데이터를 전달만 하는 객체" — 검증/가공은 다른 책임자에게.
+
+또한 **"테스트는 하드코딩이 더 가독성 좋다"** 는 비교 가이드. 학생이 "하드코딩이 좋지 않다고만 생각했다"는 응답에 대해 "직접 비교해보고 다른 사람 의견 들어보라"는 메타 학습 가이드 + 자료 추천.
+
+`Judgement`의 알고리즘 단순화 — "두 번 탐색이 O(2n)이지만 더 단순하고 가독성 높다"는 trade-off 표현. 학생이 즉시 흡수.
+
+`inputCarNames(): Boolean` 시그니처 거짓말에 대해 "입력 다시 받기는 InputView의 일"이라는 책임 위치 가이드.
+
+- **대표 인용:**
+  > dto가 값을 가공하고, 검증하고 있는 것이 매우 어색합니다. dto는 이름 그대로 데이터를 전달만 하는 객체입니다.
+  >
+  > — @malibinYun on `src/main/kotlin/dto/CarsDTO.kt:22`
+
+  > 우승자를 구하기 위해 복잡한 로직이 들어가고 있어 가독성이 떨어집니다. 단순하게, 가장 멀리있는 자동차의 거리를 구하고, 그 거리에 있는 자동차들을 구해보는 것은 어떨까요?
+  >
+  > — @malibinYun on `src/main/kotlin/domain/Judgement.kt:22`
+
+  > 필요한 값을 하드 코딩으로 적은 것과, 로직으로 적은 것을 비교해보고, 어떤 것이 테스트 코드를 읽을 때 편한지 스스로와 다른 사람들에게 의견을 들어보는 것은 어떨까요?
+  >
+  > — @malibinYun on `src/test/kotlin/domain/JudgementTest.kt:13`
+
+## 얻은 교훈
+
+- **DTO의 정체성 = 데이터 운반.** 검증/가공/계산은 DTO의 일이 아님. DTO에 로직이 생기면 그것은 사실 다른 객체.
+- **알고리즘 단순함 vs 효율.** O(n) 1회 vs O(n) 2회는 사실상 같은 클래스. 가독성이 우선. 진짜 성능 문제가 생긴 후 최적화.
+- **테스트 하드코딩의 가치.** "DRY 원칙"이 테스트에 그대로 적용되지 않음. 테스트는 시나리오 명세이므로 데이터가 명시될수록 가독성.
+- **시그니처 거짓말 = 호출자 혼란.** `inputCarNames: Boolean`은 메서드 이름과 반환 타입이 어긋남. 호출자가 함수 본문을 봐야.
+- **`in range` 표현 활용** — 코틀린의 `number in 4..9`가 `number >= 4 && number <= 9`보다 가독성 + 의도.
+- **메타 학습 가이드의 가치** — "왜 그렇게 생각했는지 직접 비교해보고 의견을 들어라"는 가이드는 학생이 자기 추론을 검증하는 훈련.