oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/Leeyerin0210/133-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,50 @@
+# PR #133 — [자동차 경주 구현] 시아 미션 제출합니다
+
+- **Reviewee:** [@Leeyerin0210](https://github.com/Leeyerin0210)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/133
+- **단계:** 1단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 32
+
+## 잘한 점 (설계 관점)
+
+- **`Car`에 require로 invariants 검증** — 리뷰어 칭찬.
+- **자동차에 move 메시지를 던지는 구조** — Tell-Don't-Ask 적용. 리뷰어 명시적 칭찬.
+- **`ErrorConstant` object 활용** — 도메인 어휘로 에러 분류.
+- **자기 학습 의지 표명** — var/private val 차이 등 핵심 질문을 적극 제기.
+- **전략 패턴 적용 시도** — 리뷰 후 완전랜덤/4이상/3이하 세 전략 구현으로 무작위 격리.
+
+## 못한 점 (설계 관점)
+
+- **`InOutView` 한 클래스에 입출력 합침** — 테스트 분리 어려움. 책임이 한 곳에 묶임.
+- **`InOutController`도 같은 패턴** — 책임을 단일 클래스에 합침.
+- **`enum` + `getData()` 2단 depth 상수 접근** — 단순 const val로 충분한데 우회.
+- **`Car.currentPosition`이 var public** — 외부 직접 수정 가능.
+- **`InputTest`가 InController + InOutView 둘 다 테스트** — 테스트 명칭과 대상 어긋남.
+- **공백 처리/5글자 검증 미흡** — 도메인 invariants 정의 좁음.
+- **`DTO`라는 패턴 도입했지만 정의에 안 맞는 사용** — 단순 데이터 운반이 아니라 검증까지 가지고 있음.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae는 **"하나의 클래스에 묶여 있으면 분리 테스트가 어렵다"** 는 본질을 일관되게 짚었다. `InOutView`/`InOutController`가 한 클래스에 입출력을 묶으면, 그 자체로 단일 책임 위반 + 테스트 격리 어려움 + 변경 영향 확대 — 한 문제로 세 가지가 동시에 발생.
+
+또한 **var vs private val + 메서드** 의 차이를 학생이 직접 답하게 만든 가이드도 강력. "직접 접근으로 수정"과 "행동에 따라 값이 바뀜"의 차이는 추적 가능성/관리 용이성에 직결.
+
+전략 패턴을 적용하라는 가이드는 학습 자료(블로그) 링크와 함께 명확히 제시.
+
+- **대표 인용:**
+  > In 과 Out은 하나의 클래스에서 관리되어야 할까요? 생각해보면 둘은 다른 기능을 할텐데 입력과 출력에 대해 별도로 테스트를 한다고 하면 어떤 일이 발생할까요?
+  >
+  > — @KwonDae on `src/main/kotlin/view/InOutView.kt`
+
+  > 프로퍼티로 variable로 생성하여 외부에서 쉽게 접근하여 값을 수정할 수 있는것 / 값에 직접 접근하지 못하고 어떠한 행동(자동차가 움직인다)에 따라 값이 바뀌는 것 / 이 두가지는 어떤 차이점이 있을지 고민해보시면 좋을 것 같아요!
+  >
+  > — @KwonDae on `src/main/kotlin/model/Car.kt:19`
+
+## 얻은 교훈
+
+- **합쳐진 클래스 = 분리된 테스트 어려움.** Input과 Output을 한 클래스에 두면 (1) 책임 모호, (2) 테스트 클래스 명칭 모호, (3) 한쪽 변경이 다른 쪽에 영향 — 세 가지 문제가 동시에. 분리는 무겁지만 명확.
+- **외부 직접 접근 vs 메서드 호출의 차이는 추적 가능성.** `car.position = 5`는 어디서 호출됐는지 알기 어렵지만, `car.moveTo(5)`나 `car.move()`는 그 메서드가 호출된 곳을 추적 가능.
+- **전략 패턴은 무작위 격리의 표준.** RandomStrategy / FixedStrategy / NeverMoveStrategy 같은 구현체로 같은 인터페이스를 만족. 테스트는 결정적 전략으로, production은 랜덤 전략으로.
+- **DTO와 검증의 분리.** DTO에 검증을 넣으면 어디서 검증이 일어나는지 모호해진다. DTO는 단순 운반, 검증은 도메인 객체의 init.
+- **테스트 클래스명 = 테스트 대상명.** `InputTest`가 다른 객체들을 함께 테스트하면 이름이 거짓말. 한 단위 테스트는 한 production 클래스.

package/lessons/woowacourse-racingcar/Leeyerin0210/159-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 #159 — [자동차 경주 2단계] 시아 미션 제출합니다
+
+- **Reviewee:** [@Leeyerin0210](https://github.com/Leeyerin0210)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/159
+- **단계:** 2단계
+- **리뷰어:** @KwonDae
+- **라인 코멘트:** 11
+
+## 잘한 점 (설계 관점)
+
+- **이름 변경: `MainController` → `RacingController`, `RaceService` → `RacingGame`** — 도메인 어휘로 구체화. 추상적 일반어 회피.
+- **여러 Controller를 `RaceController` 하나로 통합** — 1단계의 InController/OutController 분리 과잉을 정리.
+- **`Car` 이름 invariants를 Car 생성자에서 처리** — 자기 책임을 자기가 들도록 옮김.
+- **`CarManager` 도입으로 중복 검증 및 carList 생성 분리** — 다음 단계에서 일급 컬렉션 학습으로 자연스럽게 이어질 자리.
+
+## 못한 점 (설계 관점)
+
+- **`Service`라는 추상적 명칭** — 도메인 어휘로 답할 수 있는 자리에 추상 일반어 사용. `RaceService` 대신 `RacingGame`이 더 어울린다는 리뷰어 지적.
+- **`OutController` / `InController` 잔재** — 1단계 분리가 일부 남음.
+- **`RacingGame` 내부에서 의존 객체 직접 생성** — 외부에서 주입받으면 (1) 테스트 페이크 주입, (2) 라이프사이클 결정의 자유.
+- **`CarManager` 이름 — Manager는 절차적 -er 명사** — 일급 컬렉션(Cars)의 자리에 Manager가 들어선 식.
+- **`RaceControllerTest`인데 RaceController 존재 안 함** — 코드와 테스트의 어긋남.
+- **테스트가 무작위 의존** — `[3,4], [4,5], [5,6]에서 C 우승` 같은 결정적 시나리오로 바꿔야.
+
+## 리뷰어 의견 요지
+
+리뷰어 @KwonDae는 이 라운드에서 **"요구사항의 어휘를 그대로 코드 어휘로"** 라는 강한 메타 가이드를 짚었다. 프로그래밍 요구사항의 단어(예: "RacingGame")를 그대로 클래스 이름으로 쓰면 리뷰어와 리뷰이가 같은 단어로 소통할 수 있어 리소스가 효율적.
+
+또한 **의존성 주입의 가치** 를 다시 짚음 — RacingGame이 내부에서 생성하지 말고 외부에서 받으면 테스트와 라이프사이클 자유도 상승.
+
+`CarManager`라는 명명에 대해서는 학습 자료 키워드(일급 컬렉션)를 제시하며 다음 단계 학습으로 자연스럽게 연결.
+
+- **대표 인용:**
+  > Service는 어떤 역할을 하나요? 자동차 경주 Controller는 RaceController가 MainController 라는 추상적인 명칭보다 명확해보이는데 시아 생각은 어떤가요?
+  >
+  > — @KwonDae on `src/main/kotlin/model/RaceService.kt`
+
+  > 프로그래밍 요구사항에 맞게 구현을 하는 것은 리뷰어와 리뷰이의 모든 리소스를 효율적으로 사용할 수 있게 해준답니다.
+  >
+  > — @KwonDae on `src/main/kotlin/model/RaceService.kt`
+
+  > 일급 컬렉션이라는 키워드에 대해 살짝 찾아보셔도 다음 학습에 도움이 될 것 같아요. 그 후에 지금 사용하려는 CarManager를 다시 살펴보시면 어떤 의미인지 알게 되실거에요!
+  >
+  > — @KwonDae on `src/main/kotlin/model/CarManger.kt`
+
+## 얻은 교훈
+
+- **요구사항의 어휘 = 코드의 어휘.** 프로그래밍 요구사항이 "자동차 경주(RacingGame)"를 말하면 그 이름이 그대로 클래스로. 리뷰어와 학생이 같은 단어를 쓰면 토론이 명확하고 리소스 효율도 올라간다.
+- **`Manager` / `Service` 같은 일반어 회피.** 도메인이 그것을 부르는 더 구체적 이름이 있을 가능성 — `Cars`(일급 컬렉션), `RacingGame` 등. 추상 명사는 종종 도메인 누락의 신호.
+- **의존성 주입의 두 가지 가치.** (1) 테스트에서 페이크/스텁 주입, (2) 라이프사이클을 외부에서 결정. 둘 다 객체의 자유를 넓힌다.
+- **테스트의 결정성을 결정적 입력으로.** 무작위에 의존하면 테스트가 "통계적 신뢰" 수준. "[3,4],[4,5]에서 C 우승" 같은 시나리오는 100% 재현 가능.
+- **이름의 변경이 학습의 가시화다.** "MainController → RacingController"라는 한 단어의 변경이, 책임의 명확화라는 큰 학습을 보여준다.
+- **두 PR을 연결하는 리뷰** — 1단계의 코멘트가 2단계까지 끌고 가는 리뷰어 패턴이 학습 연속성을 만든다.

package/lessons/woowacourse-racingcar/PROGRESS.md

@@ -0,0 +1,94 @@
+# 진행 상황 (작업 일지)
+
+이 문서는 `woowacourse/kotlin-racingcar` PR 리뷰 분석 작업의 **상태 추적용**이다. 다음 세션이 어디서부터 이어가야 하는지를 알린다.
+
+## 데이터셋
+
+- 출처: https://github.com/woowacourse/kotlin-racingcar/pulls?q=is:pr+is:closed
+- 전체 closed PR: **188개**
+- 분석 대상 필터: **라인 레벨 reviewer 코멘트 ≥ 5개**
+- 통과한 PR: **133개**, 고유 reviewee: **77명**
+
+## 분석 어휘
+
+- 유지: 책임/응집/결합/캡슐화/Tell-Don't-Ask/테스터빌리티/도메인 모델링/일급 컬렉션/원시 강박/의존 방향/명명 설계
+- 제외: Kotlin 관용구 (scope function, smart cast, null 처리, val/var, data class 사용 여부, init 블록 형태, collection API 선택, extension 위치)
+
+## 진행 상태
+
+**✅ 완료: 133 PRs / 77 reviewees** — 2026-05-22
+
+`SUMMARY.md` + `README.md` 작성 완료. 메인 README 링크 추가 완료.
+
+---
+
+이전 진행 로그:
+
+**76 PRs 완료 / 40+ reviewees 완료**
+
+완료된 reviewees (코멘트 많은 순):
+- wondroid-world, tmdgh1592, chanho0908, rosemin928, junseo511, haeum808, m6z1
+- songpink, SeongHoonC, gahyunkim, HamBeomJoon, hwannow, Hevton, boogi-woogi
+- devfeijoa, pingu244, oungsi2000, Leeyerin0210, murjune, kkosang, cucumber99
+- DYGames, RightHennessy, 2chang5, parkjiminnnn, no1msh, re4rk, kimhm0728
+- chaehyuns, doabletuple, hyunji1203, otter66, ippnsj, gaeun5744
+- aprilgom, medAndro, giovannijunseokim, ki960213, tobae-time, rhkrwngud445
+
+## 다음 우선순위 (남은 high-comment reviewees)
+
+대략 57 PR / 37 reviewees 남음. /tmp/oop-lessons-cache/grouped.tsv를 보면 정확한 순서를 알 수 있음.
+
+다음 우선:
+- chws0508 (31, 2)
+- yrsel (31, 1)
+- kmkim2689 (30, 2)
+- Yunseok-Nam (30, 2)
+- s6m1n (29, 2)
+- Hogu59 (29, 2)
+- EmilyCh0 (29, 2)
+- hxeyexn (28, 2)
+- inseonyun (27, 2)
+- ijh1298 (27, 1)
+- sujin9 (25, 2)
+- moondev03 (25, 2)
+- yujamint (25, 1)
+- jiyuneel (25, 1)
+- junjange (24, 2)
+- JoYehyun99 (24, 2)
+- whk06061 (24, 1)
+- Songusika (24, 1)
+- sh1mj1 (23, 2)
+- hyemdooly (23, 2)
+- ... (잔여 reviewees는 grouped.tsv 참조)
+
+## 캐시 위치
+
+`/tmp/oop-lessons-cache/`:
+- `prs.json` — 188개 PR 메타
+- `nums.txt` — PR 번호 목록
+- `counts.tsv`, `reviewer_counts.tsv`, `authors.tsv`
+- `grouped.tsv` — number / reviewer_count / distinct_reviewers / author
+- `comments/<N>.json`, `pr_meta/<N>.json`, `reviews/<N>.json`, `issues/<N>.json`
+
+**주의:** `/tmp`는 재부팅 시 사라질 수 있음. 시작 전 캐시 확인 후 없으면 재생성.
+
+## 다음 세션 시작 시
+
+1. 이 파일 + 가장 최근 commit 확인
+2. 캐시 존재 여부 확인 (`ls /tmp/oop-lessons-cache/comments/ | wc -l == 133` 이어야)
+3. 캐시 있으면 다음 우선순위(chws0508부터) 진행
+4. 5-10 PR마다 commit + push로 안전 저장
+5. 전체 133개 완료 후 `SUMMARY.md` + `README.md` + 메인 README 링크 작성
+
+## 작성 패턴 (효율을 위해)
+
+- 1단계 PR이 비슷한 안티패턴(Constants, Util, MutableList, Controller 비대 등) 반복하므로 두 번째 라운드부터는 좀 더 짧게 작성
+- 핵심 트레이드오프나 새로운 패턴이 나오는 PR에 더 집중
+- 사람마다 30-60 lines 정도가 적정 (1단계 = 50-100, 리팩터링/2단계 = 40-70)
+
+## 검증 — 최종 단계에서 수행
+
+- 무작위 3개 PR 파일을 GitHub 원본과 대조
+- `grep -r -E "scope function|apply *\{|let *\{|smart cast|nullable|val vs var|data class" lessons/` Kotlin 관용구 누수 점검
+- `SUMMARY.md`의 PR 카운트 = 실제 `.md` 수
+- 모든 reviewee 폴더에 최소 1개 .md

package/lessons/woowacourse-racingcar/README.md

@@ -0,0 +1,69 @@
+# 우아한테크코스 kotlin-racingcar PR 리뷰 OOP 교훈
+
+[`woowacourse/kotlin-racingcar`](https://github.com/woowacourse/kotlin-racingcar) 리포의 closed PR 188개 중 라인 코멘트 ≥ 5개인 **133개 PR (77명 reviewee)**을 분석해 도출한 OOP 설계 교훈 모음.
+
+## 📖 시작하기
+
+- **[SUMMARY.md](SUMMARY.md)** — 전체 정리 (자주 하는 실수 TOP 10, 리뷰어 명언, 조영호 강의 토픽 매핑, 단계별 학습 곡선)
+- **개별 PR 분석** — 각 reviewee 폴더 안에 `<PR번호>-<단계>-자동차-경주.md` 형태로 정리
+
+## 🎯 분석 범위
+
+**OOP 설계 관점만**:
+책임 분배 / 응집도 / 결합도 / 캡슐화 / Tell-Don't-Ask / 테스터빌리티 / 도메인 모델링 / 일급 컬렉션 / 원시 강박 / 의존 방향 / 명명 설계
+
+**제외**:
+Kotlin 관용구 (scope function, smart cast, null 처리 idiom, val/var, data class 문법 자체, init 블록 형태, collection API 선택)
+
+## 📂 폴더 구조
+
+```
+woowacourse-racingcar/
+├── README.md (이 문서)
+├── SUMMARY.md (총정리)
+├── PROGRESS.md (작업 진행 로그)
+└── <reviewee-name>/
+    └── <PR번호>-<단계>-자동차-경주.md
+```
+
+각 PR 분석은 다음 구조:
+- **잘한 점** (설계 관점)
+- **못한 점** (설계 관점)
+- **리뷰어 의견 요지** (대표 인용 1~3개 + 출처)
+- **얻은 교훈**
+
+## 🔥 가장 인상적인 PR
+
+학습 곡선의 본보기로 참고할 만한 PR:
+
+- **[sh1mj1/115](sh1mj1/115-2단계-자동차-경주.md)** — 1단계 피드백을 *자가 학습*으로 발전시킨 이상적 사례. 리뷰어 평: "박수 쳤습니다." MoveStrategy 인터페이스 도입, DI 깊이 자가 인지/해결.
+
+- **[moondev03/161](moondev03/161-2단계-자동차-경주.md)** — 1단계 피드백을 *맹목 흡수*하지 않고 *재검토*. "InputView에 검증 옮겨라" 가이드를 따랐지만 결합도 우려로 재조정.
+
+- **[hxeyexn/109](hxeyexn/109-1단계-자동차-경주.md)** — 리뷰어 @ghojeong의 명문장 다수. "Depth = abstraction level", "휴가 가도 동료가 일할 수 있는 코드", "최대한도로 세분화하라".
+
+- **[Songusika/84](Songusika/84-2단계-자동차-경주.md)** — 페어 프로그래밍 + 학생 *역질문*으로 토론 깊어진 PR. data class vs record 5가지 차이 정리.
+
+- **[injoon2019/24](injoon2019/24-2단계-자동차-경주.md)** — 3명 리뷰어 협력 리뷰. 코틀린 idiom + OOP 개념 + 테스트 DSL (kotest).
+
+## 🎓 단계별 학습 곡선
+
+리뷰어들이 반복적으로 짚는 안티패턴은 **단계가 진행되면서 다른 깊이**로 나타남:
+
+**1단계 흔한 실수:**
+- `Const.kt` 한 파일 / `Validator` / `Util` 모호한 이름 / Controller god-object / Car.position var / 검증 위치 혼란 / 매직넘버 / 추상적인 테스트명
+
+**2단계 부각 이슈:**
+- 전략 패턴 / 일급 컬렉션 / VO / 테스트 가능성 / Controller-Domain 책임 재분배 / 도메인-UI 의존 방향
+
+자세한 분석은 [SUMMARY.md의 "단계별 학습 곡선"](SUMMARY.md#단계별-학습-곡선) 참고.
+
+## 🔗 관련 리소스
+
+- 원본 리포: https://github.com/woowacourse/kotlin-racingcar
+- 분석 도구 (Oh-My-OOP MCP): [상위 리포 README](../../README.md)
+- 조영호 "객체지향의 사실과 오해" — 책임/역할/협력 3요소가 본 분석의 주요 어휘
+
+## 📝 작업 로그
+
+분석 과정과 데이터 위치는 [PROGRESS.md](PROGRESS.md) 참고. 캐시된 PR 메타와 코멘트 JSON은 `/tmp/oop-lessons-cache/`에 저장됨 (재부팅 시 사라질 수 있음).

package/lessons/woowacourse-racingcar/RightHennessy/51-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 #51 — [링링] 1단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@RightHennessy](https://github.com/RightHennessy)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/51
+- **단계:** 1단계
+- **리뷰어:** @woowahan-leah
+- **라인 코멘트:** 17
+
+## 잘한 점 (설계 관점)
+
+- **`Name.init` 블록에서 require로 유효성 검증** — 자기 invariants를 자기가 든다. 리뷰어 칭찬.
+- **요구사항 외 자체 판단 구현** — 리뷰어 명시적 칭찬. 학습 의지.
+- **자기 결정의 회고적 응답** — try-catch 줄임 의도, catch가 에러 먹을 수 있음 학습.
+
+## 못한 점 (설계 관점)
+
+- **`catch (e: Exception)`로 모든 예외 포괄** — 프로그램이 커지면 예상 못한 버그를 catch가 삼킬 위험.
+- **InputView/OutputView 인스턴스를 World가 보유** — 상태 없는 View는 object로 충분.
+- **`Car.toString()` 오버라이드** — UI 변경(이모지 추가 등)이 도메인 변경으로 연결.
+- **`Util` 클래스에 `generateRandom` + `tryAndRerun` 묶음** — 두 함수의 응집 근거 약함. 자기 답변에서 "프로젝트 전역 사용 + 독립 기능"이라는 기준을 정립한 후 generateRandom을 분리.
+- **`Values.kt` 매직넘버 상수 컨테이너** — 결합도 증가.
+- **`CarManager.init`을 외부에서 호출하는 구조** — 인스턴스 생성과 초기화가 분리되어 외부가 그 절차를 알아야.
+- **랜덤 의존 메서드 테스트 누락**.
+
+## 리뷰어 의견 요지
+
+리뷰어 @woowahan-leah는 **catch의 위험성** 을 정확히 짚었다 — `catch (Exception)`이 모든 예외를 삼키면 진짜 버그를 가린다. 구체적 catch가 안전.
+
+또한 **이모지 비유로 UI/도메인 결합 시각화** — UI 요구가 "자동차명 앞뒤에 이모지 붙이기"로 바뀌면 도메인 객체의 toString을 바꿔야 한다는 어색함을 한 줄로 보여줌.
+
+**객체 인스턴스화의 정당화** — InputView/OutputView가 인스턴스를 가질 이유가 없으면 object. 학생이 "메모리 소요 줄임"이라고 답해 학습 흡수.
+
+`CarManager.init`을 외부에서 호출하는 구조에 대해 "생성과 동시에 초기화"라는 깔끔한 가이드 — 호출자가 절차를 알 필요 없도록.
+
+- **대표 인용:**
+  > catch (e: Exception)문으로 모든 에러를 catch하고 있는데요, 이러한 코드는 프로그램이 커질수록 예상치 못한 버그를 발견하기 어렵게 만들 수 있어요.
+  >
+  > — @woowahan-leah on `src/main/kotlin/racingcar/Application.kt:14`
+
+  > UI 요구사항이 바뀌어 자동차명 앞뒤에 이모지를 붙이는 것으로 바뀐다면 어떻게 될까요? UI 로직의 변경사항으로 인해 도메인 로직이 수정되는 상황이 발생하게 됩니다.
+  >
+  > — @woowahan-leah on `src/main/kotlin/racingcar/entity/Car.kt:14`
+
+  > 외부에서 CarManager를 깊게 알지 않으면 인스턴스를 생성할 때 init 함수를 호출해야 한다는 것을 잘 모를 수 있어요. CarManager를 생성할때부터 초기화할 수 있도록 해보면 어떨까요?
+  >
+  > — @woowahan-leah on `src/main/kotlin/racingcar/model/CarManager.kt:16`
+
+## 얻은 교훈
+
+- **catch는 좁게 잡는다.** `catch (Exception)`은 안전망이 아니라 위장막. 진짜 버그를 가리는 가장 큰 코드 안티패턴 중 하나. 구체적 예외 클래스를 명시.
+- **생성과 초기화는 한 단계.** 생성자가 끝나면 객체가 완전히 사용 가능해야. 별도 init() 호출이 필요하면 사용자가 그 절차를 알아야 — 깨지기 쉬운 API.
+- **UI 변경 시뮬레이션 = 결합도 진단.** "이모지 추가하면 어디가 바뀌나"를 시뮬레이션하면 결합 위치가 즉시 드러남. UI 변경이 도메인을 흔들면 결합도 문제.
+- **인스턴스화의 정당화 = 다양한 상태/의존성.** 상태 없고 의존성 없으면 object. 인스턴스화는 비용을 지불하는 선택.
+- **자기 답변으로 학습 흡수 확인.** 리뷰어가 "object의 차이는?"이라고 물었을 때 학생이 "싱글톤 + 메모리 소요 절감"이라 답한 흐름이 학습을 명시화. 리뷰어가 그 답을 확인해주면 안정적 학습.
+- **요구사항 외 자체 구현의 가치 vs 위험.** 학생의 자발적 확장은 학습 가치가 크지만, 동시에 검증 부담이 커진다. 리뷰어가 그 의지를 인정하면서 추가 학습 도구(runCatching 등)를 제시하는 균형 가이드가 인상적.

package/lessons/woowacourse-racingcar/RightHennessy/58-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 #58 — [링링] 2단계 자동차 경주 제출합니다
+
+- **Reviewee:** [@RightHennessy](https://github.com/RightHennessy)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/58
+- **단계:** 2단계
+- **리뷰어:** @woowahan-leah
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **Util 클래스의 자기 기준 정립** — "프로젝트 전역 사용 + 독립적 기능"이라는 기준으로 Util의 자리를 재고. `tryAndRerun`은 두되 `generateRandom`은 CarManager 곁으로.
+- **try-catch에서 runCatching으로의 학습 의지** — 시간 부족하지만 다음 시도 표명.
+- **NumberGenerator 인터페이스 + 테스트 fake로 결정성 확보** — 리뷰어 명시적 칭찬.
+- **불필요한 mutable 제거** — `cars`를 List로 충분.
+- **자기 답변으로 가이드를 풀어 설명** — "메시지 던지기"의 세 가지 효과(호출자 무지/검색 부담/변경 전파)를 정리.
+
+## 못한 점 (설계 관점)
+
+- **`World.kt`의 컨트롤러가 OutputView의 상수를 알고 있음** — `MSG_INPUT_CAR_NAME` 같은 구현 상세 참조. 메시지만 던지면 됨.
+- **`Car.position`이 외부에서 수정 가능** — 캡슐화 누락.
+- **`OutputView`가 도메인 로직 참조** — `it.position.toInt()` 같은 도메인 내부 참조.
+- **Model에서 View 함수 호출** — `CarManager`가 직접 View 함수 호출. Model → View 역방향 의존.
+- **`RandomNumber object`가 싱글톤** — 정말 싱글톤이 맞는가에 대한 정당화 부족.
+- **GWT 패턴 미적용** — 테스트 구조가 비정형.
+
+## 리뷰어 의견 요지
+
+리뷰어 @woowahan-leah는 **"메시지를 던져라"** 라는 객체지향 핵심을 매우 강하게 짚었다. Controller가 OutputView의 상수를 직접 참조하지 말고 의미 있는 메시지(예: `자동차이름을받을때사용할안내메세지를출력해줘()`)를 던지는 식.
+
+또한 **"OOP의 본질은 변경 전파를 막기 위함"** 이라는 메타 가이드: 호출부가 구체적 요구사항에 의존하면 요구사항 변경이 호출부까지 영향. 추상에 의존하면 그 변경이 한 곳에 갇힘.
+
+학생이 자기 답변에서 정확한 답을 도출했을 때 리뷰어가 명시적으로 인정하면서 더 깊은 가이드(변경 전파)를 보강 — 학습 사이클의 좋은 예.
+
+- **대표 인용:**
+  > 컨트롤러에서 OutputView에 `MSG_INPUT_CAR_NAME`라는 상수가 존재한다는 것을 알 필요가 있을까요~? 외부에서 객체의 구체적인 구현을 참조하기보다 메세지만 던져보는 구조로 개선해보세요.
+  >
+  > — @woowahan-leah on `src/main/kotlin/racingcar/controller/World.kt`
+
+  > OOP의 가장 중요한 본질 중 하나는 프로그램이 커졌을 때 유지 보수와 변경사항의 전파를 막기 위함에 있다는 것을 기억하며 메세지를 던져보세요.
+  >
+  > — @woowahan-leah on `src/main/kotlin/racingcar/controller/World.kt`
+
+  > 확신이 들지 않는 이유는 model에서 View를 참조하고 있기 때문입니다. model에서 직접적으로 View의 함수를 호출하기보다 model의 결과물을 View에 넘겨주는 방향으로 구현한다면 이러한 참조를 끊을 수 있습니다.
+  >
+  > — @woowahan-leah on `src/main/kotlin/racingcar/model/CarManager.kt:24`
+
+## 얻은 교훈
+
+- **OOP의 본질 = 변경 전파 차단.** 작은 코드에서는 직접 상수 참조가 편해 보이지만, 시스템이 커지면 한 상수 변경이 모든 사용처로 퍼진다. 추상 메시지에 의존하면 변경이 한 곳에 갇힌다.
+- **메시지 던지기의 세 가지 효과** (학생 정리):
+  1. 호출자가 OutputView의 내부 구성을 알 필요 없음 (지식 축소)
+  2. print 함수 후보 검색 비용 없음 (탐색 비용 축소)
+  3. View 변경이 호출부에 전파되지 않음 (변경 영향 차단)
+- **Model → View 방향 의존 금지.** Model이 View 함수를 호출하면 의존 그래프가 뒤집힌다. Model의 결과를 View에 넘기는 방향 통일.
+- **자기 의문이 답으로 가는 경로.** "확신이 들지 않는 이유는?"이라는 학생의 질문에 리뷰어가 "model에서 View를 참조하고 있기 때문"이라고 답하는 흐름이 가장 깊은 학습.
+- **싱글톤의 정당화는 도메인에서 시작.** "한 인스턴스만 있어야 하는 도메인적 이유"가 있어야. 메모리 절감이나 편의는 부수적.
+- **GWT(Given-When-Then) 같은 정형 패턴의 가치** — 테스트 구조가 명세화되면 다른 개발자가 빠르게 이해.

package/lessons/woowacourse-racingcar/RunaNam/81-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,44 @@
+# PR #81 — [자동차 경주] 루나남 미션 제출합니다
+
+- **Reviewee:** [@RunaNam](https://github.com/RunaNam)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/81
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @nbalance97, @sinb57
+- **라인 코멘트:** 8
+
+## 잘한 점 (설계 관점)
+
+- **Car의 `position`을 외부에서 var로 노출 → setter 사용 분명**.
+- **`Cars.value.forEach(Car::move)` 같이 메서드 참조 활용**.
+- **문자열 템플릿 활용**.
+
+## 못한 점 (설계 관점)
+
+- **재귀 호출이 try-catch 안 → tailrec 최적화 안 됨** (StackOverflow 위험).
+- **확장 함수가 top-level + InputValidation 파일** — 로직 추적 어렵고 InputView 중복 이름 충돌 위험.
+- **`for vs forEach` 스타일 선택의 정당화 부재**.
+
+## 리뷰어 의견 요지
+
+두 리뷰어의 메시지:
+
+1. **재귀 호출 + try-catch = tailrec 미적용** — JVM 최적화 안 됨, StackOverflow 위험.
+
+2. **확장 함수의 *최상위 위치 위험*** — "로직 추적 힘들고(시간 흘러 그 확장 함수 존재 잊을 휴먼에러), 타겟 클래스(InputView)에 중복된 이름 생기면 충돌." → 클래스로 묶어 캡슐화 권장.
+
+3. **for vs forEach = 팀 스타일** — 정해진 답 없음. 팀 그라운드에 맞춰.
+
+- **대표 인용:**
+  > 확장함수가 최상위에 선언되면, 로직 추적이 힘들뿐더러(시간이 흘러 해당 확장함수가 존재하는지 잊어버리는 휴먼에러가 발생할 수 있음) 타켓이 되는 InputView에 중복된 이름이 생겼을때 문제가 나타날 수 있어요. 별도의 클래스를 묶어서 함수를 캡슐화하는 것이 어떨까요
+  >
+  > — @sinb57 on `src/main/kotlin/view/InputValidation.kt`
+
+  > 재귀호출은 StackOverFlow를 야기할 수 있기에 주의해야합니다. 꼬리 재귀의 경우, JVM이 최적화를 진행해서 for반복문으로 바꿔준다고 알고 있는데요. 최근 `try/catch문이 사용되면 꼬리 재귀 최적화가 되지 않는다`는 문구를 본 적이 있어서 한번 찾아보셨으면 좋겠네요.
+  >
+  > — @sinb57 on `src/main/kotlin/Application.kt`
+
+## 얻은 교훈
+
+- **재귀 호출의 첫 점검 = 꼬리 위치 + try-catch 부재**. try-catch 안에 재귀 두면 tailrec 최적화 안 됨 → StackOverflow.
+- **확장 함수의 위치 = 추적 가능성과 충돌 방지의 trade-off**. 최상위 = 짧은 코드, 추적 어려움. 클래스 안 = 캡슐화, 명확.
+- **확장 함수의 *수신 객체와 동명 메서드* 충돌**. 클래스에 같은 시그니처 메서드가 추가되면 확장 함수는 *무시됨* (조용한 버그).