oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/chws0508/73-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,46 @@
+# PR #73 — [스캇] step2 자동차 경주 미션 제출합니다
+
+- **Reviewee:** [@chws0508](https://github.com/chws0508)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/73
+- **단계:** 2단계
+- **리뷰어:** @galcyurio
+- **라인 코멘트:** 5
+
+## 잘한 점 (설계 관점)
+
+- **도메인이 View에 의존하지 않도록 수정** — 1단계 피드백 잘 흡수.
+- **TestOutputView 같은 테스트 더블 시도** — Controller 단위 테스트.
+- **자기 의문의 깊이** — Result vs Exception, View 에러 처리 등.
+
+## 못한 점 (설계 관점)
+
+- **`List<Car>`를 OutputView에 넘기고 OutputView가 Car 내부 꺼냄** — 도메인 약결합 잔존.
+- **OutputView assert 패턴** — 고차 함수로 단순화 가능.
+
+## 리뷰어 의견 요지
+
+리뷰어 @galcyurio는 학생의 깊은 토론에 명확한 답:
+
+1. **"UI 아닌 도메인도 아닌 비즈니스 로직 = Controller"** — validation 후 재입력 같은 흐름이 Controller의 자연스러운 자리. View 변경에 영향 안 받고 단위 테스트 가능.
+
+2. **`Result.failure(Exception)`로 Exception 던지지 않고 표현 가능** — Exception 생성만 하고 던지지 않음. 또는 Either, 자체 Result.
+
+3. **테스트의 고차 함수 활용** — TestOutputView에 람다 넘기는 패턴.
+
+학생의 "이런 식으로 짠 이유" 회고에 대해 리뷰어가 "지금은 잘 수정됨"이라는 인정 메시지.
+
+- **대표 인용:**
+  > UI의 역할은 아닌 것 같은데 그렇다고 domain 이라고 보기 힘든 것들에 대한 비즈니스 로직들은 Controller에 두시면 좋습니다. 지금처럼 validation을 해본 뒤에 실패했다면 다시 View에게 재입력을 받게 하기도 쉬운 layer이며 View와는 다르게 단위 테스트도 가능하기 때문입니다.
+  >
+  > — @galcyurio on `src/main/kotlin/view/InputView.kt:22`
+
+  > Result.Failure를 만들기 위해서는 Exception을 생성하기만 하고 던지지는 않으셔도 됩니다.
+  >
+  > — @galcyurio on `src/main/kotlin/controller/RacingGameController.kt:4`
+
+## 얻은 교훈
+
+- **Controller = "UI도 아니고 도메인도 아닌 비즈니스 흐름의 자리".** validation + 재입력 같은 흐름 제어. 그 위치 자체가 책임 분배 답.
+- **Exception 생성 ≠ 던지기.** `Result.failure(Exception(...))`로 Exception을 값으로 사용. 던지지 않으면 흐름은 정상.
+- **고차 함수로 테스트 더블 단순화.** 람다를 생성자로 넘기면 페이크 객체의 표현이 즉시 가능.
+- **이전 라운드의 흡수 정도가 깊다 = 다음 토론이 더 깊어진다.** 1단계의 도메인-View 분리 가이드를 잘 흡수해 2단계는 약결합 미세 조정 수준.

package/lessons/woowacourse-racingcar/cucumber99/132-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 #132 — [자동차 경주 구현] 오이 미션 제출합니다
+
+- **Reviewee:** [@cucumber99](https://github.com/cucumber99)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/132
+- **단계:** 1단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 30
+
+## 잘한 점 (설계 관점)
+
+- **README 꼼꼼히 작성** — 리뷰어 명시적 칭찬.
+- **`AttemptCount`로 시도 횟수를 도메인 객체화** — 원시 강박 해소 시도.
+- **자기 결정의 회고적 응답** — 시도 횟수를 1번만 쓰니 변환을 늦춤 등 자기 추론 명시.
+
+## 못한 점 (설계 관점)
+
+- **`StringBuilder` 사용 의도 모호** — 내부에서 `+` Concat. 의도와 도구가 어긋남.
+- **`Car`의 position 표현이 백틱 `_position` + getCount 등 우회** — 코틀린 프로퍼티의 자연스러운 표현 활용 누락.
+- **외부에서 Car의 값을 직접 꺼내 사용** — `Race`가 Car의 상태를 꺼내 사용. Tell-Don't-Ask 위반.
+- **`lateinit var`로 Cars 선언** — 필요 없는 가변성. 다른 표현 가능.
+- **예외 메시지에 입력값 미포함** — 사용자가 어떤 입력이 잘못됐는지 모름.
+- **테스트의 공용 필드** — 격리 부족.
+- **테스트 이름이 한글이 아니라 영어 + `@DisplayName`** — 가독성과 일관성 사이 trade-off, 학생의 결정은 가독성 우선이라 답함.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 **도구의 의도 부합** 을 짚었다. `StringBuilder`는 가변 문자열 성능 최적화인데 그 안에서 `+`로 새 String 만들고 있으면 도구의 의도가 무의미.
+
+또한 **객체에 메시지 vs 값 꺼내기** 를 명확히: `cars.parsedCars`를 직접 꺼내 가공하지 말고 `cars.move(...)` 같은 메시지로.
+
+테스트의 자료원/도구 활용에 대해서도 가이드 — `runCatching`, `assertAll` 등 표준 도구의 활용도를 학습 자료로 제시.
+
+`Car.INIT_POSITION + 1`처럼 테스트가 내부 상수에 의존하는 패턴에 대해서는 **"테스트 읽는 이가 그 내부 값을 알아야 하는가?"** 라는 캡슐화 본질 질문.
+
+- **대표 인용:**
+  > StringBuilder를 사용하는데, 내부에서는 String을 + 로 Concat 하고 있네요! StringBuilder를 사용하는 이유를 모르고 있다는 반증이네요.
+  >
+  > — @malibinYun on `src/main/kotlin/controller/UserInterface.kt`
+
+  > 자동차들 객체의 값을 직접 꺼내 사용하기보다, 메시지를 던져보는 건 어떨까요?
+  >
+  > — @malibinYun on `src/main/kotlin/model/Race.kt`
+
+  > 테스트를 읽는 이가 이 내부 값에 대해 알아야하는 것이 부담이라고 생각해요. 내부의 값을 꼭 알아야할까요?
+  >
+  > — @malibinYun on `src/test/kotlin/model/CarTest.kt:52`
+
+## 얻은 교훈
+
+- **도구의 의도와 사용이 일치해야 한다.** StringBuilder + String concat 같은 어긋남은 "도구를 모르고 쓴다"는 신호. 그 도구의 본질을 학습한 뒤 의식적으로 선택.
+- **테스트 가독성 = 외부 컨텍스트 없이 이해 가능성.** 테스트가 `Car.INIT_POSITION + 1`처럼 production 상수를 참조하면, 읽는 이가 그 상수의 의미를 알아야. 캡슐화의 핵심은 "외부가 내부를 알 필요 없음".
+- **표준 도구 학습이 코드 품질의 빠른 향상.** `runCatching`, `assertAll`, `assertSoftly` 같은 도구는 한 번 익히면 코드의 표현력이 크게 올라감.
+- **메시지 vs 데이터 꺼내기는 매번 선택해야 하는 결정.** "메시지를 보내자"는 자동 결정이 아니라 매 호출 시 의식적 선택. 의식적인 메시지 호출 → 캡슐화 보존.
+- **테스트 이름 = 명세.** `@DisplayName`은 메서드명을 줄이는 좋은 도구지만, "긴 한글 메서드명 vs DisplayName"의 선택은 팀 컨벤션과 학생의 가독성 기준이 다양.
+- **예외 메시지에 입력값 포함의 가치.** 사용자가 "어떤 입력이 잘못됐는지" 빠르게 알 수 있어 UX와 디버깅이 동시에 개선.

package/lessons/woowacourse-racingcar/cucumber99/177-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 #177 — [자동차 경주 2단계] 오이 미션 제출합니다
+
+- **Reviewee:** [@cucumber99](https://github.com/cucumber99)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/177
+- **단계:** 2단계
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 12
+
+## 잘한 점 (설계 관점)
+
+- **패키지를 `racingcar/domain/model`로 분리** — 도메인 분리 의식.
+- **`Cars` 일급 컬렉션 도입** — 1단계의 외부 컨테이너에서 도메인 객체화.
+
+## 못한 점 (설계 관점)
+
+- **`AttemptCount`가 문자열을 멤버로 가짐** — 도메인이 입력 형식에 결합. "시도 횟수" 자체는 Int여야 자연스러움.
+- **`Cars`가 이름에 해당하는 문자열 리스트를 멤버로 가짐** — `Cars`라면 Car들의 컬렉션이어야지 이름 리스트는 별개.
+- **도메인이 콘솔 뷰를 직접 그림** — `Cars.kt:38`이 표시 형식까지 만듦. 도메인과 뷰의 강한 결합.
+- **`Cars.getWinner()`가 List를 반환** — 메서드명은 단일 Car를 기대하게 함. 시그니처가 거짓말.
+- **테스트 메시지 검증 누락** — 1단계와 동일 패턴.
+- **검증부 하드코딩 미반영** — 테스트가 production 상수 참조 패턴 잔존.
+- **`stopCar`라는 테스트 픽스처의 의미 모호** — 전진 안 한 자동차를 그렇게 부르는 게 자연스러운지.
+- **컨트롤러에 도메인 로직 잔재** — 분리가 완전하지 않음.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 **도메인 객체가 입력 형식을 알면 안 된다** 는 본질을 1단계에 이어 다시 강조. `AttemptCount`가 String을 멤버로 가지는 어색함을 직접 짚음 — "시도 횟수 객체가 문자열을 가지고 있어야 하는 이유를 잘 모르겠네요".
+
+또한 `Cars`라는 일급 컬렉션의 정체성 — 이름 리스트가 아니라 Car들의 컬렉션이어야. 도메인 표현이 어디까지 들어가는지에 대한 명확한 가이드.
+
+`getWinner(): List<Car>`의 시그니처와 이름 불일치도 짚음 — 단수 이름, 복수 반환은 호출자에게 거짓말.
+
+- **대표 인용:**
+  > "시도횟수" 객체가 문자열을 가지고 있어야하는 이유를 잘 모르겠네요!
+  >
+  > — @malibinYun on `src/main/kotlin/racingcar/domain/model/AttemptCount.kt`
+
+  > 도메인이 콘솔 뷰에 대한 뷰를 직접 그리고 있네요. 도메인과 뷰의 매우 강한 결합이에요. 서로 분리해보는 건 어떨까요?
+  >
+  > — @malibinYun on `src/main/kotlin/racingcar/domain/model/Cars.kt:38`
+
+  > 메서드 명만 보면, cars 객체에서 getWinner를 하는 것이니 당연히 Car 객체를 반환할 것 처럼 느껴지네요. 메서드 스펙을 더 구체적으로 표현해보는 건 어떨까요?
+  >
+  > — @malibinYun on `src/main/kotlin/racingcar/domain/model/Cars.kt:22`
+
+## 얻은 교훈
+
+- **도메인 객체의 멤버는 도메인 의미여야 한다.** "시도 횟수"가 String? 도메인 의미로는 Int가 자연스러움. 입력에서 String을 받았더라도 도메인 진입 전에 Int로 변환.
+- **일급 컬렉션은 그 컬렉션의 정체성을 가진 객체.** `Cars`는 `List<Car>`의 도메인적 표현. `List<String>` 같은 다른 데이터를 같이 가지면 그 정체성이 흐려진다.
+- **단수 이름, 복수 반환은 약속 위반.** `getWinner` → 단수 Car를 기대. `getWinners` 또는 `findWinners`처럼 시그니처가 도메인 의도를 정확히 전달.
+- **연속된 라운드에서 같은 코멘트가 반복되면 학습 누락의 신호.** 1단계와 2단계에서 같은 종류(메시지 검증, 도메인-뷰 결합, 입력값 메시지)가 반복되면 핵심 학습이 일어나지 않은 것. 학생도 리뷰어도 이 신호를 의식해야.
+- **객체 분리의 두 단계** — (1) 도메인 로직을 컨트롤러에서 도메인 객체로, (2) 그 도메인 객체의 책임을 더 세분화. 1단계만 끝났다고 2단계가 자동으로 따라오지 않음.
+- **자기 의문 응답이 학습 사이클의 척도** — "뷰에서 받은 입력값을 직접 변환하는 부분이 강하게 의존적이라는 뜻인가요?"라는 학생의 재질문은 학습 의지 신호. 리뷰어가 더 명확한 가이드를 줄 기회.

package/lessons/woowacourse-racingcar/devfeijoa/146-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,57 @@
+# PR #146 — [자동차 경주 구현] 이든 미션 제출합니다
+
+- **Reviewee:** [@devfeijoa](https://github.com/devfeijoa)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/146
+- **단계:** 1단계 (단일 PR)
+- **리뷰어:** @krrong
+- **라인 코멘트:** 45
+
+## 잘한 점 (설계 관점)
+
+- **InputView/OutputView 분리** — 리뷰어가 명시적으로 칭찬 💯.
+- **`Car`의 책임을 자기 언어로 재정의 후 수정** — "Car의 관심사는 출력이 아니라 위치/이동 여부 관리"로 정리, position 필드 도입.
+- **리뷰의 의도를 자기 사고로 풀어 답변** — 검증, 책임의 자리 등에 대해 길게 답하며 토론을 끌어옴.
+- **테스트 격리 학습** — 단일 인스턴스 공유의 문제를 깨닫고 `@BeforeEach`로 격리.
+- **`Race`의 isMove를 Car로 옮김** — 책임의 자리를 자기 판단으로 재배치.
+
+## 못한 점 (설계 관점)
+
+- **`utils/Constants.kt`로 상수 한 곳에 모음** — 결론적으로 "재사용은 Constants, 단일 사용은 companion"이라는 자기 기준을 만들었지만, 리뷰어는 한 발 더 나가 "Constants 자체가 결합도의 핵심"이라고 짚음.
+- **`ErrorHandler.kt`라는 -er 명사** — 처리만 하는 절차 클래스. 검증의 주인이 도메인이 아님.
+- **`Race.rawCarNames`처럼 입력 형식 단어가 도메인에 침투** — `Motorcycle`이 되면 `rawMotorcycleNames`로 또 바뀜.
+- **`RaceController.start` / `playing` 함수명이 반환값 의도 안 드러냄** — 동사인지 명사인지, 무엇을 돌려주는지 시그니처가 약함.
+- **`Car`에서 `moveOrStop`이 String을 들고 있음** — 출력용 표현을 도메인이 알게 됨.
+- **`GenerateRandomNumber`라는 동사형 클래스 + 자기 검증 반복** — Kotlin 라이브러리를 못 믿는 모양새의 테스트.
+- **이중 리스트(`List<List<X>>`) 출력 구조** — Car 수정 전엔 OutputView가 거부감 있는 시그니처 처리.
+- **입력 공백 처리 누락** — `      이든`처럼 앞뒤 공백 그대로. 도메인 무결성 정의가 좁음.
+- **테스트가 production 상수에 결합 + 랜덤 테스트** — `0~9 검증`은 사실상 라이브러리 검증.
+
+## 리뷰어 의견 요지
+
+리뷰어 @krrong는 **"이 책임의 진짜 주인"** 을 많이 물었다. Car의 출력 책임, Race의 이동 결정 책임, ErrorHandler의 검증 책임 등 — 책임이 어느 객체에 있어야 하는지 학생이 스스로 도달하게 만드는 패턴.
+
+또한 **"라이브러리를 신뢰하라"** 는 명확한 가이드: Random 라이브러리가 0-9 범위 반환하는지 검증하는 테스트는 사실상 의미 없음. 외부 신뢰 가능한 도구까지 검증하면 코드가 무한 검증 루프.
+
+이름의 입력 형식 침투(`rawCarNames`)에 대해 `Motorcycle` 가정 질문으로 추상화 부족을 즉시 드러내는 화법도 인상적.
+
+- **대표 인용:**
+  > Race의 관점에서 바라봤을 때 넘어오는 값이 rawCarNames인지 rawTryCount인지 알 필요가 있을까요? 만약 `Motorcycle` 클래스의 이름이 넘어오면 `rawMotorcycleNames`로 바뀌어야 할까요?
+  >
+  > — @krrong on `src/main/kotlin/racingcar/domain/Race.kt`
+
+  > 생성된 난수가 0~9 사이의 값인가를 검증한다는 말은 코틀린 라이브러리를 믿지 못한다는 말이고, 이는 곧 코틀린에서 제공하는 모든 기능을 사용할 때마다 검증을 해야 하는 것처럼 보여요.
+  >
+  > — @krrong on `src/main/kotlin/racingcar/domain/GenerateRandomNumber.kt`
+
+  > Car 클래스의 관심사는 출력일까요? ... String 값을 가지고 있기보다 위치를 나타내는 Position을 가지고 있는 것이 좋지 않을까요?
+  >
+  > — @krrong on `src/main/kotlin/racingcar/domain/Car.kt`
+
+## 얻은 교훈
+
+- **도메인이 입력 형식 단어를 알면 안 된다.** `raw`-, `Input`-, `Encoded`- 같은 접두사는 입력 경계 어휘. 도메인이 그 단어를 알면, 형식이 바뀌면 도메인이 바뀐다.
+- **신뢰의 경계를 정한다.** 외부 라이브러리(코틀린의 Random, 표준 컬렉션 등)의 행동을 검증하면 검증의 연쇄가 끝없다. 우리는 그 라이브러리를 신뢰하고, 우리 코드가 그 라이브러리를 어떻게 *사용*하는지를 검증.
+- **함수 이름이 반환의 종류를 암시한다.** `start`, `playing`처럼 동작 동사가 값을 반환한다면 호출자가 혼란. `getCars`, `prepareCars`처럼 반환 의도가 보이는 이름이 안전.
+- **도메인 객체가 표현 책임을 갖지 않는다.** Car가 출력용 String을 들고 있는 것은 View 누수. 위치는 `position: Int`로, 표현은 View가 만든다.
+- **테스트 격리는 객체 격리의 거울.** `@BeforeEach`나 새 인스턴스 생성으로 각 테스트가 독립이어야, 한 테스트의 상태가 다른 테스트의 진실을 흔들지 않는다.
+- **자기 결정의 회고 가치.** "왜 Constants에 모았는가" → "재사용 vs 단일 사용으로 분기"라는 결론까지 도달한 학생의 사고 과정은 리뷰어가 짚어주는 다음 단계("companion에 왜 두는가?")로 자연스럽게 이어진다.

package/lessons/woowacourse-racingcar/doabletuple/149-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 #149 — [자동차 경주 구현] 디랙 미션 제출합니다
+
+- **Reviewee:** [@doabletuple](https://github.com/doabletuple)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/149
+- **단계:** 1단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 22
+
+## 잘한 점 (설계 관점)
+
+- **중복 검증을 Set으로 단순화** — 리뷰어 칭찬.
+- **`@ParameterizedTest` 활용**.
+
+## 못한 점 (설계 관점)
+
+- **`util.Constants`로 상수 집중** — 결합도 안티패턴.
+- **Controller가 차의 위치를 직접 바꿈** — 외부 조종.
+- **반환 타입 `MutableList` 광범위 사용** — 한 번 만든 후 변경 없는 자동차 리스트도 mutable.
+- **`maxOf`를 for문 안에서 매번 계산** — 한 번만 계산해야 효율적.
+- **`Car.position`이 public** — 외부 변경 가능.
+- **`Validator`의 오류 메시지 모호** — "유효하지 않은 자동차 이름"이 무엇이 무효인지 안 드러남.
+- **Int 변환 로직 중복** — 한 번에 변환 후 사용.
+- **`BufferedReader` 사용** — readln()으로 충분.
+- **`CarTest`가 Controller 동작도 테스트** — 책임 어긋남.
+- **`OutputView`가 출력 메시지 자체를 InputView가 출력** — 출력 책임이 흩어짐.
+
+## 리뷰어 의견 요지
+
+이 PR은 1단계의 전형적 패턴이 광범위하게 나타남 — Constants, Mutable 남용, 외부 조종, 비대 Controller 등. 리뷰어 @hyemdooly는 한 PR에서 종합적으로 짚어줌.
+
+주요 가이드:
+1. **"차가 직접 움직이게 할 수는 없을까요?"** — Tell-Don't-Ask
+2. **"`Constants` object가 무궁무진하게 커지지 않을까요?"** — 상수 분산의 안티패턴
+3. **테스트 책임 = production 클래스 책임의 거울**
+
+- **대표 인용:**
+  > Controller에서 차의 위치를 바꾸기 보단, 차가 직접 움직일 수 있지 않을까요?
+  >
+  > — @hyemdooly on `src/main/kotlin/RacingController.kt`
+
+  > 만약 기능이 커져서, 더 많은 상수를 정의해야한다면? 1000개의 상수를 정의해야한다면? 이 `Constants` object가 무궁무진하게 커지지 않을까요?
+  >
+  > — @hyemdooly on `src/main/kotlin/util/Constants.kt`
+
+  > 이 테스트는 `Car`에 대한 테스트일까요, `Controller`에 대한 테스트일까요?
+  >
+  > — @hyemdooly on `src/test/kotlin/CarTest.kt`
+
+## 얻은 교훈
+
+- **MutableList의 사용은 정말로 변경되어야 할 때만.** 한 번 만든 자동차 리스트가 변경될 일 없으면 List. 반환 타입의 가변성 = 호출자에게 주는 약속.
+- **`maxOf`/`maxBy` 같은 reduce 연산은 반복문 안에 들어가면 비용이 폭발.** 한 번 계산 후 변수로.
+- **에러 메시지 = UX.** "유효하지 않은 X"는 무엇이 무효인지 안 알려줌. "X는 5자 이하" 같은 구체적 메시지가 사용자 경험.
+- **테스트 클래스명 = 테스트 대상의 책임 정의.** `CarTest`가 Controller 동작을 테스트한다면 두 클래스의 책임이 흐려진 신호.
+- **1단계의 전형적 안티패턴 목록:** (1) Constants 단일 파일, (2) MutableList 남용, (3) Controller가 도메인 조종, (4) 자동차 외부 조종, (5) BufferedReader 같은 자바 잔재, (6) 모호한 에러 메시지. 이 6가지가 거의 모든 1단계 PR에 반복.

package/lessons/woowacourse-racingcar/doabletuple/175-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 #175 — [자동차 경주 2단계] 디랙 미션 제출합니다
+
+- **Reviewee:** [@doabletuple](https://github.com/doabletuple)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/175
+- **단계:** 2단계
+- **리뷰어:** @hyemdooly
+- **라인 코멘트:** 13
+
+## 잘한 점 (설계 관점)
+
+- **`Car.position`을 부생성자로 받아 테스트 가능성 확보** — 결정적 시나리오 빌드.
+- **자기 의문에 대한 깊은 회고** — data class 사용 이유, equals/hashCode 동작, 객체 동등성 등을 디컴파일까지 해서 확인.
+- **공식문서 직접 인용** — 학습 사이클 깊음.
+- **`Car`의 data class → class 전환** — "데이터 보유"가 아닌 "이름 검증 + 전진" 역할이므로 class가 적절.
+
+## 못한 점 (설계 관점)
+
+- **`GameController`를 object로 변경** — 학생 본인이 명확한 이유 없이 "인스턴스 하나면 충분" 정도로 결정. object 선택의 정당화가 약함.
+- **`Car`에 출력 String 반환 함수 잔존** — View 책임이 도메인에.
+- **`Game.cars`를 그대로 반환** — MutableList 그대로 노출. 방어적 복사 누락.
+- **`InputView`가 `OutputView`에 의존** — 책임 결합. Controller가 둘을 조립해야.
+
+## 리뷰어 의견 요지
+
+리뷰어 @hyemdooly는 **"data class 사용 이유의 본질 점검"** 을 짚었다. 공식 문서 직접 인용: "data class는 데이터 보유가 주 목적". Car가 데이터만 가지는가? 검증/이동까지 한다면 데이터 클래스가 아닐 가능성.
+
+또한 **디컴파일 권장** — 학생이 추측("이름 같고 위치 다르면 중복 걸러내지 못한다")으로 결론 내리는 대신 디컴파일 결과로 확인하라는 가이드. 결과적으로 학생의 추측이 틀렸음을 본인이 확인 (data class는 주생성자 프로퍼티로만 equals 자동 생성).
+
+**방어적 복사** — MutableList 반환의 위험을 다시 한 번 짚음.
+
+학생의 깊은 자기 회고에 대해 직접 답변 없이 학습 자료(공식문서, 디컴파일)로 안내하는 리뷰 스타일이 인상적.
+
+- **대표 인용:**
+  > 공식문서에서 데이터 클래스는 데이터를 주로 보유하는데 사용한다고 이야기해요. 지금 자동차는 순수하게 데이터를 갖고 있는 역할일까요?
+  >
+  > — @hyemdooly on `src/main/kotlin/domain/Car.kt`
+
+  > 정말 그런지 한번 디컴파일해서 확인해보세요!
+  >
+  > — @hyemdooly on `src/main/kotlin/domain/Car.kt`
+
+  > MutableList를 그대로 반환하면 어떤 일이 일어날 수 있을까요? 방어적 복사에 대해 학습해보세요.
+  >
+  > — @hyemdooly on `src/main/kotlin/domain/Game.kt:12`
+
+## 얻은 교훈
+
+- **data class 사용의 정당화 = 데이터 보유.** 행위가 있으면 일반 class. 코틀린 공식문서의 기준을 직접 확인하는 것이 가장 안전.
+- **추측 대신 확인.** 학생이 "이렇게 동작할 것 같다"는 추측을 디컴파일 결과로 확인 → 자기 모델 보정. 리뷰어가 답을 주지 않고 도구를 안내한 가치.
+- **방어적 복사의 자리.** 컬렉션을 반환할 때마다 외부 변경 가능성을 차단. `cars.toList()` 또는 `cars.toImmutableList()` 같은 보호.
+- **object 선택의 정당화는 도메인 의미 + 라이프사이클** — "인스턴스 하나로 충분"은 충분하지 않은 정당화. "프로그램 전체에서 단 하나만 존재해야 한다"는 도메인적 의미가 있어야 object.
+- **자기 학습 사이클이 가장 깊은 학습.** 학생이 공식문서 → 디컴파일 → 자기 모델 수정의 과정을 거치면 그 지식이 진짜 본인 것이 된다. 리뷰어는 가이드만 제공.
+- **View → View 의존은 금지.** InputView가 OutputView를 알면 입출력의 책임 경계가 무너진다. 조립은 Controller의 일.

package/lessons/woowacourse-racingcar/donghyun81/154-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 #154 — [자동차 경주] 동현 미션 제출합니다
+
+- **Reviewee:** [@donghyun81](https://github.com/donghyun81)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/154
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 20
+
+## 잘한 점 (설계 관점)
+
+- **InputView/OutputView 분리**.
+- **`require()` 활용한 도메인 무결성**.
+- **`CarFactory`로 객체 생성 로직 분리** — 익명 이름 부여 같은 UX 친화 기능 시도.
+- **PR 본문에 명확한 질문 4개** — 상수화 범위, 함수형 immutable, 검증 위치 등.
+- **사용자 친화 사고** — "매번 이름 입력이 번거롭다 → 자동 부여" 같은 UX 관점.
+
+## 못한 점 (설계 관점)
+
+- **InputView가 검증을 안 함** — "View에서 검증하면 View 의미가 퇴색"이라는 잘못된 일반화. 학생이 후속 토론으로 정리.
+- **`RandomGenerator`가 `Random`에 직접 의존** — Car 테스트 시 결정적 결과 못 만듦. 전략패턴 권장.
+- **`Const.kt` 한 파일에 모든 상수** — 응집도 낮음. 1000개 상수 시 무너짐.
+- **`CarFactory`의 익명 이름 부여 = 함수 두 가지 일** — 같은 함수가 "입력 받은 이름 적용" + "빈 입력 시 기본 이름 부여" 둘 다. 호출 측에서 어느 경로인지 안 보임.
+- **테스트 함수명이 요구사항 표현과 어긋남** — "5자 초과할 수 없다" vs "5자 초과 시 에러" 등.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae의 핵심 메시지:
+
+1. **"한 함수에 두 가지 기능"의 위험** — `CarFactory`가 입력 이름 적용 + 빈 입력 기본값 부여 둘 다. → "동료 개발자가 이 함수가 두 가지 기능을 모두 할 것이라 예상하기 쉬울까요?" 대안: Controller에서 `inputView.getNames() ?: defaultNames()`로 명시적 분기.
+
+2. **View의 자체 검증 책임** — "InputView가 입력값을 *스스로* 검증할 수 있도록 역할을 부여" → 학생은 처음에 "View에서 검증하면 View 의미 퇴색"으로 거부했지만 후속 토론에서 수용.
+
+3. **상수 위치 토론** — 정답 없음을 시인. "공통 상수가 아니면 범위 지정자를 두는 편" → 사용 범위에 맞는 자리.
+
+4. **전략 패턴으로 `RandomGenerator` 대체** — Car 테스트가 Random에 묶여 결정적 검증 불가.
+
+5. **상수화 범위** — `joinTo(",")`의 쉼표까지 상수화할지의 정답 없음. "프로젝트마다 컨벤션, 페어의 의견에 따라".
+
+- **대표 인용:**
+  > 사용자가 이름을 입력하든 하지 않든 위 함수를 거쳐가게 되어있는데, 과연 동료 개발자가 이 함수가 두가지 기능을 모두 할 것이라 예상하기 쉬울까요? `val inputNames = inputView.getNames() ?: defaultNames()` 이런식으로 가독성을 고려해보면 어떨까요?
+  >
+  > — @KwonDae on `src/main/kotlin/CarFactory.kt:13`
+
+  > InputView와 OutputView를 잘 분리해주셨네요. 그렇다면 InputView에서도 입력값에 대해 스스로 검증할 수 있도록 역할을 부여해보는건 어떨까요?
+  >
+  > — @KwonDae on `src/main/kotlin/InputView.kt:3`
+
+  > 만약 프로젝트에서 사용하는 상수가 1000개 이상이 된다면 어떤 일이 발생할까요?
+  >
+  > — @KwonDae on `src/main/kotlin/Const.kt`
+
+## 얻은 교훈
+
+- **"두 가지 일을 하는 함수"는 호출 측에서 보이지 않는다.** 빈 입력 시 기본값을 함수 안에서 처리하면 호출자는 "이름 받기"만 본다. 대안: 호출 측에서 `?: defaultNames()`로 분기를 노출.
+- **View의 검증 = "이건 View의 의미를 퇴색시킨다"가 아니라 "View가 받은 입력의 형식을 보호한다"**. UI 형식 검증과 도메인 규칙 검증은 다른 층이고, View가 형식 검증을 가지는 게 자연스럽다.
+- **상수 1000개 압박 시뮬레이션이 강력하다.** "지금은 잘 작동"이라도 도메인이 성장하면 단일 파일이 깨지는지를 미리 점검.
+- **`Random`에 직접 의존 = 테스트 불가능.** 인터페이스 + 결정적 fake 주입이 단위 테스트의 시작.
+- **사용자 친화 사고는 좋지만, *그 친화가 코드에 어떻게 드러나는지*가 더 중요.** 빈 입력 시 자동 이름 부여를 *명시적으로* 보여주는 코드가 동료 개발자에게 친화적.

package/lessons/woowacourse-racingcar/dpcks0509/103-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 #103 — [자동차 경주] 찬용 미션 제출합니다
+
+- **Reviewee:** [@dpcks0509](https://github.com/dpcks0509)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/103
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **Exception에 케이스별 상세 메시지**.
+- **Validator 검증 로직 분리** + 메시지 상수화.
+
+## 못한 점 (설계 관점)
+
+- **`Exception`이라는 클래스명** — 실제 Exception 타입과 혼동.
+- **`","` 같은 매직 문자열**.
+- **`Validator` 모호한 이름** → `InputValidator` 권고.
+- **`올바르지 않은 레이싱 게임` 테스트명이 너무 포괄적**.
+- **테스트가 랜덤 의존 (값을 임의로 넣어 회피)**.
+- **Car가 랜덤 생성 책임 보유** — 도메인이 외부 비결정성에 의존.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 메시지:
+
+1. **클래스명 = 책임. `Exception` 접미사 ≠ 실제 Exception**. 실제 자바 Exception과 혼동 위험.
+
+2. **모호한 이름 = 모호한 책임의 신호** — `Validator` → `InputValidator`. "정의할 수 있는 범위가 넓을 수 있도록 짓는 것을 지양."
+
+3. **테스트 이름 = 한 시나리오 한 의미**. "올바르지 않은 레이싱 게임"은 너무 포괄적.
+
+4. **Car ↔ 랜덤 연관 없음**. "클래스에는 꼭 해당 클래스에서만 수행하는 것이 적절한 함수만 남겨라."
+
+- **대표 인용:**
+  > input 값에 대한 검증이므로 InputValidator 가 좀 더 적절하지 않을까요~? 클래스/함수 네이밍을 지으실 때, 너무 모호하거나 정의할 수 있는 범위가 넓을 수 있도록 짓는 것을 지양해주시면 좋습니다. 네이밍이 모호하다는 것은 곧 해당 클래스/함수의 역할이 모호하거나 모호해질 수 있다는 신호이기 때문입니다
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/Validator.kt`
+
+  > 자동차라는 도메인을 떠올렸을 때, 랜덤 한 숫자를 생성하는 것과 자동차간에 연관관계는 크지 않을 것 같아요. 클래스에는 꼭 해당 클래스에서만 수행하는 것이 적절한 함수만 남겨보면 어떨까요?
+  >
+  > — @vagabond95 on `src/main/kotlin/racingcar/model/Car.kt`
+
+## 얻은 교훈
+
+- **클래스명에 *타입 시그널*을 잘못 넣지 말 것**. `Exception` 접미사는 *Exception 타입* 의미. 검증 객체엔 `Validator`/`Validation`.
+- **클래스의 함수 = "그 클래스의 책임에 속하는가" 검증**. Car에 랜덤 생성 함수가 있다면 Car의 책임이 *움직임*+*랜덤*으로 흐림. 분리.
+- **테스트 이름의 *정밀도***. "올바르지 않은 게임"은 5가지 실패 케이스 모두 포섭 → 어떤 실패인지 모름. 케이스별 분리.

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

@@ -0,0 +1,48 @@
+# PR #112 — [자동차 경주 - 리팩토링] 찬용 미션 제출합니다
+
+- **Reviewee:** [@dpcks0509](https://github.com/dpcks0509)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/112
+- **단계:** 2단계 (리팩토링)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 9
+
+## 잘한 점 (설계 관점)
+
+- **Controller 코드 간결화**, `private set`.
+- **MovingStrategy 인터페이스 도입** (전략 패턴).
+- **수동 move로 결정적 테스트 시도**.
+
+## 못한 점 (설계 관점)
+
+- **`end()` 함수 — `judgeWinners`까지 포함하면 `progressRacingGame`인지 `end`인지 모호**.
+- **Controller가 winners 만들고 view로 넘김** — RacingGame이 winners 직접 만들어 넘기는 게 더 깔끔.
+- **인터페이스 구현체가 RacingGame 단 하나** — 추상화 이점 미실현.
+- **테스트가 Car 직접 제어** — RacingGame 검증 아닌 Car 재검증.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 핵심 가르침:
+
+1. **함수 이름의 *경계 모호함*** — `end`가 judgeWinners를 포함한다고 볼 수도, progressRacingGame이라고 볼 수도. 한 함수에 2가지 이상 동작이 묶이면 이름 결정 불가.
+
+2. **테스트의 진짜 목적 = "이 객체가 자기 책임을 다하는가"** — Car를 수동 제어해서 winner가 나오면 그건 CarTest 반복. RacingGame을 직접 제어해서 결과 검증해야 RacingGame 테스트.
+
+3. **전략 패턴으로 "랜덤을 결정적으로"** — 움직임 방식이 바꿀 수 있다면 테스트도 가능. 구현체 하나로는 추상화 이점 미실현.
+
+4. **Controller의 책임 = view-domain 연결**. winners 계산 같은 비즈니스 로직은 domain.
+
+- **대표 인용:**
+  > 그런데, 이 코드는 car 를 직접 제어했기 때문에, racingGame 이 정말로 그렇게 동작하는지는 검증할 수 없어요. CarTest 를 다시 반복한 것에 가까워요. 결국 racingGame 을 검증하려면 racingGame 을 직접 제어하고, 이로부터 나온 결과를 활용하여 테스트를 돌려야합니다.
+  >
+  > — @vagabond95 on `src/test/kotlin/racingcar/RacingGameTest.kt`
+
+  > 위에서 작성해주신 것을 조금 더 유연하게 코드로 풀어보는 방법이 있을 것 같아요. 전략 패턴 이라는 키워드가 도움이 되실 것 같습니다
+  >
+  > — @vagabond95 on `src/test/kotlin/racingcar/RacingGameTest.kt`
+
+## 얻은 교훈
+
+- **함수 이름 결정 곤란 = SRP 위반의 진단 도구**. "end가 맞나, progress가 맞나" 고민이 들면 두 동작을 분리.
+- **테스트가 자기 객체를 검증하는지 확인**. Car를 수동 제어한 RacingGameTest = CarTest 재현. RacingGame을 직접 제어해서 검증.
+- **전략 패턴 = 결정적 테스트의 출발점**. "랜덤하게 움직인다"가 본질이 아니라 "움직이는 방식이 *바뀔 수 있다*"가 본질. 인터페이스로 표현하면 테스트도 결정적.
+- **추상화의 이점 = 다른 구현체가 있을 때 발현**. 구현체 하나라면 인터페이스 = 죽은 추상. 적어도 테스트용 fake 구현체 1개 + 프로덕션 구현체 1개로 둘 충족.

package/lessons/woowacourse-racingcar/drunkenhw/82-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,60 @@
+# PR #82 — [자동차 경주] 술향 미션 제출합니다
+
+- **Reviewee:** [@drunkenhw](https://github.com/drunkenhw)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/82
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @sujin9
+- **라인 코멘트:** 18
+
+## 잘한 점 (설계 관점)
+
+- **Position 별도 value class 후보로 분리**.
+- **`runCatching` 시도** — 코틀린 idiom 학습 시도.
+- **`require` 활용**, `repeat` + `joinToString` 등 컬렉션 함수 활용.
+- **String template 활용** (출력).
+
+## 못한 점 (설계 관점)
+
+- **Controller가 기능별로 안 나뉨** — 한 메서드에 여러 책임.
+- **`Car.position`이 var (외부 변경 가능)**.
+- **`InputView`에서 try-catch (runCatching) 안에 입력 형식 검증** — `toIntOrNull` 단순화 가능.
+- **테스트 함수명과 assertion 불일치** — "true를 반환한다"인데 `isFalse()` assert.
+- **테스트 함수명에 라운드 수 같은 구체 조건 누락**.
+- **Position이 data class** — value class가 더 적합 (대수적 동치성 + 인라인).
+
+## 리뷰어 의견 요지
+
+리뷰어 @sujin9의 핵심 가르침:
+
+1. **`runCatching`의 *진짜 가치* = Result extension들의 풍부함**:
+   - `onSuccess / onFailure / getOrThrow / getOrElse / getOrDefault / fold / map / recover`
+   - try-catch + when 분기를 더 짧고 명확하게.
+
+2. **`toIntOrNull() ?: ...` 패턴이 더 단순** — Result wrapper 없이 같은 효과. 입력 형식 검증 정도라면 충분.
+
+3. **코틀린 예외 처리 원칙** — "논리 오류 제외하고 정상 흐름 안에서는 exception을 던지지 않는다." (Elizarov 글, 안드로이드 레벨1 요구사항).
+
+4. **`data class` vs `value class`** — Position 같은 단일 값 wrapper는 value class (Kotlin 1.5+, 인라인). data class는 다중 필드 동치성.
+
+5. **테스트 함수명 = 라운드 수 등 구체 조건**.
+
+- **대표 인용:**
+  > 코틀린에서 예외 처리를 할 때는 논리 오류를 제외한 정상적인 흐름 안에서는 exception을 던지지 않는 것을 지향하고 있어요.
+  >
+  > — @sujin9 on `src/main/kotlin/racingcar/view/InputView.kt`
+
+  > 다음과 같이 써도 무방할 것 같습니다! :) 혹은, 더 간단하게 표현하고 싶다면 `return readln().toIntOrNull() ?: sendRound()` 이러한 방법도 있습니다
+  >
+  > — @sujin9 on `src/main/kotlin/racingcar/view/InputView.kt`
+
+  > 여기서는 value class 를 사용해보셔도 좋을 것 같아요! data class와 value class의 차이는 무엇일까요?
+  >
+  > — @sujin9 on `src/main/kotlin/racingcar/domain/Position.kt:3`
+
+## 얻은 교훈
+
+- **단일 값 wrapper = value class (Kotlin inline)**. Position(value: Int) 같이 1개 필드 + 동치성만 필요하면 data class보다 value class — 런타임 오버헤드 없이 타입 안전성.
+- **`runCatching` extensions가 try-catch보다 강력** — `onFailure { }.getOrElse { }` 같은 체이닝으로 명령형 try-catch가 선언형으로.
+- **입력 형식 검증은 `toIntOrNull() ?:`로 충분**. Result wrapper는 *복잡한 에러 분기*가 필요할 때만.
+- **코틀린의 예외 철학** — 정상 흐름에선 예외 안 던지기. 사용자 재입력 = 정상 흐름. `null` 또는 재귀로.
+- **테스트 함수명과 assertion 일치**. "true를 반환한다"인데 `isFalse()` = 테스트가 *틀린 사실*을 검증. 리뷰에서 잡힐 신호.

package/lessons/woowacourse-racingcar/etama123/145-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 #145 — [자동차 경주] 동희 미션 제출합니다
+
+- **Reviewee:** [@etama123](https://github.com/etama123)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/145
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 19
+
+## 잘한 점 (설계 관점)
+
+- **Validator/도메인 분리, RandomGenerator 추상화**.
+- **피드백을 즉시 흡수** — STANDARD_NUMBER → MOVEMENT_THRESHOLD 같은 이름 개선.
+- **자기 답변에 *이유* 명시** — "var 외부 노출 시 원치 않는 변경 가능 → private set."
+
+## 못한 점 (설계 관점)
+
+- **Controller가 *필드*로 input 보관** — `run` 메서드 안에서만 쓰이는데 클래스 필드.
+- **`Car.position`이 var (외부 변경 가능)**.
+- **`STANDARD_NUMBER`라는 일반 어휘** — 자동차 경주 모르는 사람이 의미 모름.
+- **에러 메시지에 입력값 안 담김** — "잘못된 입력입니다" vs "잘못된 입력 'foo'입니다".
+- **테스트가 단일 케이스 + ParameterizedTest** — 케이스 1개면 ParameterizedTest 무의미.
+- **테스트 함수명이 추상적** — "개별 자동차 이름 유효성 검사".
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun의 핵심 가르침:
+
+1. **에러 메시지에 *입력값*을 담아라** — 디버깅의 시작점. "잘못된 입력입니다"는 무엇이 잘못인지 모름.
+
+2. **상수 이름 = 도메인 무지인이 봐도 의미가 보이는가** — `STANDARD_NUMBER`는 "이게 뭐의 표준?" 모름. `MOVEMENT_THRESHOLD` (이동 임계값).
+
+3. **테스트 setup의 재사용 vs 재생성** — Car 객체를 매 테스트 블록에서 새로 생성. 공유 state로 인한 테스트 간 간섭 제거.
+
+4. **경계값만 테스트** — "4미만과 4이상"이면 3과 4 두 케이스만으로 충분.
+
+5. **`isTrue()` vs `isEqualTo()`** — 가독성 측면. 테스트 읽는 사람이 "머릿속에서 연산하지 않게."
+
+6. **테스트 함수명 = 구체적인 조건이 보여야** — "개별 자동차 이름 유효성 검사"는 어떤 조건인지 모름.
+
+- **대표 인용:**
+  > 전반적으로 어떤 값이 들어왔길래 Exception이 발생하는지 메시지에 담아주는 건 어떨까요? 입력 값을 예외 메시지에 담으면 어떤 장점이 생길 수 있을까요?
+  >
+  > — @malibinYun on `src/main/kotlin/validator/InputValidator.kt`
+
+  > STANDARD_NUMBER는 자동차 경주 게임에 대한 지식이 없는 사람이 보았을 때도 한 번에 알아볼 수 있는 의미를 담은 이름일까요?
+  >
+  > — @malibinYun on `src/main/kotlin/domain/Car.kt`
+
+  > 연산량의 측면보다는, 가독성의 측면에서 남긴 코멘트였어요. 테스트코드를 읽는 사람에게 머릿속으로 몇 번의 연산을 하도록 하기보다, 그저 아무런 계산 과정을 거치지 않고 주르륵 읽을 수 있게 도와주는 게 가장 좋은 테스트라고 생각해요
+  >
+  > — @malibinYun on `src/test/kotlin/domain/CarTest.kt`
+
+## 얻은 교훈
+
+- **에러 메시지의 *문맥*은 비용 없는 디버깅 정보**. 입력값을 메시지에 담으면 운영에서 로그만 보고 원인 추정 가능. 안 담으면 재현 필요.
+- **상수 이름 = "도메인 모르는 사람이 봐도 짐작 가능한가"** 테스트. `STANDARD`, `DEFAULT`, `CONSTANT`는 정보량 0.
+- **테스트는 *계산 없이 주르륵*** 읽혀야. 머릿속 연산이 들어가면 그건 또 하나의 검증 부담. `isTrue()` 위에 boolean 식을 두면 두 번 연산.
+- **경계값 테스트 = 정확한 두 점**. 4를 기준이라면 3 (실패) + 4 (성공) 두 케이스. ParameterizedTest는 케이스 ≥ 2일 때만 의미.
+- **피드백 흡수 속도 = 다음 라운드의 깊이**. 학생이 한 라운드에서 모든 지적을 빠르게 받으면 다음 라운드는 더 미묘한 지적으로 격상.