oh-my-oop 0.2.0

package/lessons/woowacourse-racingcar/whk06061/41-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 #41 — [자동차 경주] 라잇 미션 제출합니다
+
+- **Reviewee:** [@whk06061](https://github.com/whk06061)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/41
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 24
+
+## 잘한 점 (설계 관점)
+
+- **`RandomNumberGenerator` 인터페이스** — Car가 생성기에 의존, 테스트 시 fake 주입 가능.
+- **`boundary` 값 상수화** — 매직넘버 제거.
+- **전략 패턴 활용** — Car가 외부에서 주입된 생성기로 이동 결정.
+- **input 재시도 로직을 별도 모듈로 시도 (RepeatInputProcess)** — 재사용 의식.
+
+## 못한 점 (설계 관점)
+
+- **`it`을 연속으로 함수 인자에 사용** — 어떤 `it`이 무엇인지 혼동.
+- **`Validator`라는 모호한 이름** — 무엇을 validate하는지 불명.
+- **`Car.tryMove`가 매번 generator 받음** — 생성자에서 한 번 주입하면 충분.
+- **`RepeatInputProcess`가 `Any` 반환** — 호출자마다 타입 캐스팅. 재사용성과 안전성의 trade-off에서 안전 잃음.
+- **OutputView가 자동차 거리를 `"-".repeat(...)`로 직접 그림** — 표현 변경 시 OutputView 본문 수정.
+- **"테스트만을 위해 메서드 public" 같은 잘못된 신호** — winner 메서드를 테스트하려고 가시성 변경.
+
+## 리뷰어 의견 요지
+
+리뷰어 @vagabond95의 핵심 메시지는 **"네이밍 모호함 = 책임 모호함의 신호"**.
+
+1. **`Validator` 네이밍의 위험** — "클래스의 네이밍이 모호하다는 것은 해당 클래스가 1가지 역할 이상을 수행할 가능성을 높힌다고 생각하는데요." → 학생은 `InputValidator`로 변경. 리뷰어 추가 가이드: "지금은 InputValidator 정도면 충분, 너무 일찍 CarNameValidator + RoundCountValidator로 쪼개면 오버엔지니어링."
+
+2. **의존성 주입 시점** — generator를 메서드마다 받지 말고 생성자에서 한 번 받기.
+
+3. **함수 이름 = 행위의 사고 흐름** — `RepeatInputProcess`는 "input을 받는다 → repeat한다"인데 함수 본문은 "error handling → 결과 반환". 이름과 사고 흐름이 어긋남.
+
+4. **`Any` 반환의 trade-off** — "결과를 반복해서 받아오는 로직의 재사용과 타입 캐스팅 사이에서" 선택을 강제. 학생은 결국 클래스 자체를 제거.
+
+5. **테스트를 위해 프로덕션을 수정하지 않는다** — "테스트가 프로덕션을 위해 존재하는 것이지 그 역의 관계는 아니다." winner 함수 가시성 변경의 잘못된 방향 시정.
+
+- **대표 인용:**
+  > 클래스의 이름이 모호하게 느껴집니다. 클래스의 네이밍이 모호하다는 것은 해당 클래스가 1가지 역할 이상을 수행할 가능성을 높힌다고 생각하는데요.
+  >
+  > — @vagabond95 on `src/main/kotlin/exception/Validator.kt`
+
+  > Any 로 리턴하게 될 경우 불필요하게 타입 캐스팅이 계속 필요하게 되는데요, 결과를 반복하여 받아오는 로직의 재사용과 타입 캐스팅 사이에서 트레이드 오프를 잘 고민해보면 좋을 것 같습니다!
+  >
+  > — @vagabond95 on `src/main/kotlin/utils/RepeatInputProcess.kt`
+
+  > 기본적으로 테스트만을 위해 프로덕션 코드가 수정되어서는 안된다고 생각합니다. 테스트가 프러덕션을 위해 존재하는 것이지 그 역의 관계는 아니니까요
+  >
+  > — @vagabond95 on `src/test/kotlin/domain/CarTest.kt:8`
+
+## 얻은 교훈
+
+- **모호한 클래스 이름 = SRP 위반 위험 신호.** "Validator", "Manager", "Helper" 같은 이름은 거의 항상 책임을 회피한다. 무엇을 validate하는지가 이름에 들어와야 한다.
+- **분리는 *지금* 필요한 만큼.** `InputValidator`로 충분한 시점에 `CarNameValidator + RoundCountValidator`로 쪼개면 오버엔지니어링. "Input과 관련된 규칙이 더 늘어나서 클래스가 비대해질 때" 그때 쪼개기.
+- **테스트 ≠ 프로덕션 캡슐화 깨기.** winner를 테스트하려고 public 만들지 말 것. 대안: (1) 테스트 가능한 단위로 도메인을 재구성, (2) Domain 객체에서 winner를 반환하는 정상 API.
+- **재사용성과 타입 안전성의 trade-off에서 보통 후자가 이긴다.** `Any` 반환 + 캐스팅은 "재사용한다"는 환상의 비용을 호출자에게 떠넘긴 것. 차라리 중복을 두는 게 안전.
+- **의존성 주입은 객체 생성 시점에 한 번.** 메서드 호출마다 주입하면 그건 의존성이 아니라 그냥 인자.

package/lessons/woowacourse-racingcar/wondroid-world/136-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 #136 — [자동차 경주 구현] 모찌 미션 제출합니다
+
+- **Reviewee:** [@wondroid-world](https://github.com/wondroid-world)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/136
+- **단계:** 1단계 (구현)
+- **리뷰어:** @lee-ji-hoon
+- **라인 코멘트:** 46
+
+## 잘한 점 (설계 관점)
+
+- **View/Controller/Model 분리** — Input/Output을 분리한 점은 리뷰어가 명시적으로 칭찬 ("Input / Output을 나눠주신분 좋습니다!").
+- **예외 케이스 식별** — README에 예외 상황을 잘 나눠놓은 점.
+- **추상화 시도** — 난수 생성을 `NumberGenerator`라는 추상으로 빼내려는 의도 자체는 옳음 (다만 추출 명분이 약했음).
+- **리뷰 반영의 회고적 태도** — 단순히 코드를 고친 게 아니라 "왜 그렇게 짰는지" 자기 입장을 먼저 적고 그 다음 수정. 학습이 깊게 일어남.
+
+## 못한 점 (설계 관점)
+
+- **Car가 자기 이름의 유효성을 직접 검사** — 도메인 객체가 입력 검증을 책임지면서 "공장 검수"와 "달리기"가 한 클래스에 섞임.
+- **AttemptCount의 이중 책임** — "현재 시도 횟수를 안다" + "입력 유효성을 검사한다" 두 가지가 한 클래스에 있음.
+- **경기 규칙이 Car 내부 상수로** — `MINIMUM_MOVE_POINT = 4`가 `Car`에 박혀 있어 경기 규칙이 바뀌면 `Car`가 바뀜 (변경 이유가 늘어남).
+- **Position 게터 노출** — `position`을 외부에서 가공해 화면 표시 데이터를 만들고 있어 Tell-Don't-Ask 위배.
+- **RandomNumberGenerator의 정체성 모호** — 클래스 이름은 "난수"지만 내부에 `MAX_VALUE = 9`가 박혀 있어 "범위 0-9 난수기"가 됨. 이름과 책임의 미스매치.
+- **테스트가 production 상수에 결합** — `Car.MINIMUM_MOVE_POINT`를 그대로 참조하여 규칙이 바뀌면 잘못된 테스트가 통과.
+- **전역 픽스처로 테스트 격리 깨짐** — 여러 테스트가 공유 객체에 의존해 순서/상태에 영향을 받을 위험.
+
+## 리뷰어 의견 요지
+
+리뷰어 @lee-ji-hoon는 **"이 객체의 역할은 무엇인가?"** 라는 질문을 일관되게 반복했다. 책임/역할이 클래스 이름·내용과 어울리지 않을 때, 잘라내거나 옮기라는 방향. 또 **테스트가 production 상수에 결합되는 것**과 **객체에 메시지를 던지는 형태**(`cars.parsedCars` 직접 접근 대신 메시지로 가공)를 강조.
+
+- **대표 인용:**
+  > `Car` 라는 객체가 해야 하는 역할은 무엇일까?를 페어 분이랑 고민을 해보시고 결정을 내려보시면 좋을거 같습니다.
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/model/Car.kt` (Car 자체가 이름 유효성 검사를 들고 있는 것에 대해)
+
+  > `MINIMUM_MOVE_POINT` 은 `경기의 규칙` 이라고 보는데 모찌도 한 번 생각해보면 좋을거 같습니다.
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/model/Car.kt` (경기 규칙이 Car 내부에 박힌 점)
+
+  > position 자체에 접근을 막아 볼 수 있을거 같네요 (객체에 메세지를 던지는 형태)
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/model/Car.kt` (Tell-Don't-Ask)
+
+## 얻은 교훈
+
+- 객체 이름은 "어떤 자원을 다루는가"가 아니라 **"어떤 역할을 수행하는가"** 로 짓는다. `RandomNumberGenerator`처럼 자원 중심 이름은 내부 상수가 박힌 순간 정체성이 흐려진다.
+- "내가 안다"와 "내가 검증한다"는 다른 책임이다. **InformationHolder와 ServiceProvider를 한 클래스에 섞지 말 것.**
+- 객체의 상태를 게터로 꺼내 외부에서 가공하지 말고 **메시지를 보내 결과를 받는다.** 그러면 내부 표현이 바뀌어도 호출자가 영향받지 않는다.
+- **도메인 규칙(경기의 4)은 도메인 객체(Car)가 아닌 그 규칙을 적용하는 주체(Race/Game)가 들고 있어야** 변경 이유가 한 곳에 모인다.
+- 테스트가 production 상수를 참조하는 순간 **"규칙이 잘못 바뀌어도 테스트가 통과"** 한다. 테스트는 의도(behavior)에 결합해야 한다.

package/lessons/woowacourse-racingcar/wondroid-world/166-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 #166 — [자동차 경주 2단계] 모찌 미션 제출합니다
+
+- **Reviewee:** [@wondroid-world](https://github.com/wondroid-world)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/166
+- **단계:** 2단계
+- **리뷰어:** @lee-ji-hoon
+- **라인 코멘트:** 27
+
+## 잘한 점 (설계 관점)
+
+- **MVC 적용 의도가 분명함** — Controller / Model / View 경계를 의식하고 작성. 리뷰어가 "MVC를 잘 적용했다"고 칭찬.
+- **이전 PR의 피드백을 회고적으로 흡수** — 1단계에서 `Car`가 가진 검증 책임을 빼서 상위로 옮긴 시도. (다만 옮긴 곳이 또 어색해 다음 라운드의 토론거리가 됨)
+- **로또 과제 학습이 코드에 반영됨** — "다음에 이름은 원시 타입을 감싸는 객체로" 처럼, **일급 컬렉션/값 객체** 개념을 다른 미션에서 익히고 적용 의도를 보임.
+- **네이밍 개선 즉시 반영** — `RandomNumberGenerator` → `CarMovementPolicy`로 역할을 드러내는 이름으로 변경.
+
+## 못한 점 (설계 관점)
+
+- **경기 규칙(4)이 `Cars`로 이동** — 1단계에서 Car에 박혔던 `MINIMUM_MOVE_POINT`가 이제는 `Cars` 안에서 검증되고 있어, 규칙의 자리가 여전히 어색함.
+- **`Cars`가 단순 `List<Car>` 와 다를 바 없는 컨테이너로 보임** — `playOneRound`, `getWinner` 같은 행위를 가지면서도 `Cars`만의 도메인적 정체성이 약함. **일급 컬렉션의 존재 이유**가 흐려짐.
+- **`getWinner`의 반환 타입이 `List<String>`** — "Winner"라는 도메인 개념이 String으로 사라져, 호출자가 의미를 추측해야 함 (원시 강박).
+- **`","` 파싱이 Model 안에서 일어남** — 입력 포맷에 대한 책임이 도메인으로 새어 들어옴. View의 입력을 그대로 by-pass로 받으면 형식상 의존이 아니어도 의미상 의존.
+- **테스트가 production 상수에 결합** — `INIT_POSITION`을 그대로 참조해서 상수가 바뀌면 의도와 다르게 통과/실패.
+- **전역 픽스처로 테스트 격리** — 1단계와 같은 문제가 다시 등장. `BeforeEach`로 분리 필요.
+
+## 리뷰어 의견 요지
+
+리뷰어 @lee-ji-hoon는 **"Model이 어디까지 알아야 하는가"** 와 **"이름이 책임을 드러내는가"** 를 일관되게 묻는다. Cars의 정체성(컬렉션이냐 도메인이냐), 파싱 책임의 위치, 그리고 Car의 `moveForward(number)` 시그니처가 "객체 스스로 일하기" 관점에서 적절한지 등.
+
+리뷰어는 또한 **MVC의 한계**도 친절히 안내 — Controller가 Model 간 연결이나 View 표시용 Model 변환을 맡되, 검증은 Model이 가질 수도 Controller가 가질 수도 있는 그라데이션이라는 점.
+
+- **대표 인용:**
+  > `Cars` 만 봤을 때 `List<Car>` 랑 다름이 없는 Model로 느껴지는데요 🤔
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/racingCar/model/Cars.kt` (일급 컬렉션의 정체성)
+
+  > Model이 View에 직접적인 의존은 아니지만 View의 입력 자체를 그대로 by pass 로 받는 행위는 거의 의존을 하는 것이나 마찬가지라고 할 수 있습니다.
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/racingCar/model/Cars.kt` (입력 형식 결합)
+
+  > 객체지향에서는 객체 스스로 일을 할 수 있게 해야 한다 ... number를 기름이라고 생각을 하고 어떤 차는 기름이 4칸을 필요로 한다!라는 관점
+  >
+  > — @lee-ji-hoon on `src/main/kotlin/racingCar/model/Car.kt` (Tell-Don't-Ask vs 외부에서 number 주입)
+
+## 얻은 교훈
+
+- **일급 컬렉션은 컬렉션을 감싸는 것이 아니라 도메인 행위를 입힌 것**. 단지 `playOneRound`를 가진 `Cars`는 여전히 List 래퍼다. 그 컬렉션만의 invariants와 도메인적 의사결정이 있어야 1급 시민이 된다.
+- **반환 타입이 곧 메시지의 약속이다.** `getWinner: List<String>`은 의미를 잃어버린 시그니처. `Winners`, `WinnerNames`처럼 도메인 개념을 타입으로 표현해야 호출자가 안전하다.
+- **"의존하지 않는다"와 "의존하는 입력을 받는다"는 다르다.** Model이 View의 입력 형식을 그대로 받으면 형식상 의존은 아니어도 의미상 결합이 생긴다 — 파싱은 경계에서.
+- **객체에게 무엇을 넘길지 vs 객체가 스스로 결정할지** 는 의도적 선택이다. `moveForward(number)`가 Car에게 "기름"을 주는 모델이라면 OK, 단순히 "랜덤 결과를 떠넘기는" 거라면 Car의 자율성이 사라진다. — 이건 같은 코드를 두 가지 의미로 읽게 만드는 단서.
+- **이름은 클래스의 정체성을 드러내야 한다.** `RandomNumberGenerator`처럼 자원 중심 이름은 사용처가 바뀌면 다시 짓게 되지만, `CarMovementPolicy`처럼 역할 중심 이름은 구현이 바뀌어도 살아남는다.

package/lessons/woowacourse-racingcar/yrsel/139-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 #139 — [자동차 경주 구현] 채넛 미션 제출합니다
+
+- **Reviewee:** [@yrsel](https://github.com/yrsel)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/139
+- **단계:** 1단계 (단일 PR)
+- **리뷰어:** @malibinYun
+- **라인 코멘트:** 31
+
+## 잘한 점 (설계 관점)
+
+- **자기 결정 회고와 명확한 답변** — 상수 위치, toString 재정의, RacingCar→RacingGame 명명 등.
+- **`Car.toString()` 의도적 재정의** — "자기 정보 표시"라는 의도 명시.
+- **CarsArgumentConverter 도입 (싱글톤)** — 역할 분리 시도.
+
+## 못한 점 (설계 관점)
+
+- **`Constants.kt` 한 파일에 상수 모음**.
+- **`RacingCar` / `Car` 둘 다 존재해 정체성 혼란** — 학생이 RacingCar → RacingGame으로 변경.
+- **에러 메시지 상수의 미래 확장 위험** — 입력값을 메시지에 끼울 자리가 늘면 상수 표현으로 안 잡힘.
+- **Cars가 자동차 이름 분리(split)까지 수행**.
+- **`CarsArgumentConverter`라는 추상 이름** — Argument가 무엇인지 시그니처만으로 모름.
+- **커밋 메시지가 실제 변경과 어긋남** — "fix: 접근제한자 수정" 커밋에 Car 테스트 추가.
+
+## 리뷰어 의견 요지
+
+리뷰어 @malibinYun는 매우 인상적인 **"메시지 상수의 확장 위험"** 가이드 — 지금 잘 작동하는 상수 형식이 미래 요구사항(여러 입력값, 중간 삽입, 타입 정보 추가)에 무너질 수 있다는 시뮬레이션.
+
+또한 **이름의 정확성** — `CarsArgumentConverter`의 "Argument"가 무엇인지, "String이기만 하면 input?"인지 본질 질문.
+
+커밋 단위 가이드: 커밋 메시지와 실제 변경 일치, 패키지 변경과 기능 추가는 별개 커밋.
+
+학생이 `toString()` 재정의에 대한 의도를 표명한 것에 대해 리뷰어가 후속 토론을 유도.
+
+- **대표 인용:**
+  > Exception 메시지가 친절해지면 친절해질수록 이런 구조들이 점점 복잡해질 것이 우려되네요. 입력 값이 여러개가 되어서 각 입력 값의 타입을 또 찍어주거나, 한 줄에 입력 값을 여러개 보여주는 게 아니라, 문자열 내 중간중간 보여주어야한다던지...
+  >
+  > — @malibinYun on `src/main/kotlin/Constants.kt:9`
+
+  > "CarsArgument" 는 무엇일까요? input은 무엇일까요? 반환 값인 List<Car>를 만들기 위해, 문자열이기만 하면 전부 괜찮은 input인가요?
+  >
+  > — @malibinYun on `src/main/kotlin/CarsArgumentConverter.kt:5`
+
+  > 파일 목록만을 보았을 때, RacingCar와 Car라는 파일명을 보면, 어떤 역할을 수행하는 객체인지 바로 구분해낼 수 있을까요?
+  >
+  > — @malibinYun on `src/main/kotlin/RacingCar.kt`
+
+## 얻은 교훈
+
+- **상수의 미래 확장 시뮬레이션.** 지금 작동하는 메시지 상수가 (1) 입력값 여러 개, (2) 중간 삽입, (3) 타입 정보 추가 같은 변경에 무너질지 사전 점검.
+- **"Argument", "Data", "Info" 같은 일반어 이름의 함정.** 그 추상이 무엇을 의미하는지 호출자가 본문을 봐야 앎. 도메인 이름 찾기.
+- **파일명만으로 책임 추측 가능해야** — `RacingCar` vs `Car`는 외부인이 구분 못함. `RacingGame` 같은 도메인 이름.
+- **커밋 메시지와 실제 변경의 일치.** 커밋 단위는 의미 단위 + 메시지는 그 의미. 어긋나면 git log가 진실을 말하지 않는다.
+- **toString 재정의의 trade-off.** "자기 정보 표시"는 의도가 명확하지만, 출력 형식이 바뀌면 도메인이 흔들림. 출력 메서드를 별개로 두는 게 안전.

package/lessons/woowacourse-racingcar/yujamint/83-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 #83 — [자동차 경주] 유리 미션 제출합니다
+
+- **Reviewee:** [@yujamint](https://github.com/yujamint)
+- **PR:** https://github.com/woowacourse/kotlin-racingcar/pull/83
+- **단계:** 2단계 (단일 PR)
+- **리뷰어:** @s9hn, @kdkdhoho
+- **라인 코멘트:** 25
+
+## 잘한 점 (설계 관점)
+
+- **Name, Position, TrialCount를 별도 도메인 객체로** — 원시 강박 탈출 시도.
+- **Car에 `private set` 사용** — 외부 쓰기 차단 인지.
+- **자기 의견 표명** — 콘솔 문자열 상수화 여부에 대해 "(1) 재사용 안 됨 (2) 리터럴이 가독성 좋음" 근거 제시.
+- **백엔드 크루와의 사전 토론을 PR에 반영** — 결정 배경이 명확.
+
+## 못한 점 (설계 관점)
+
+- **Controller에서 try-catch로 도메인 예외 잡아 흐름 제어** — 예외를 흐름 제어로 쓰는 안티패턴.
+- **도메인 init에서 `IllegalArgumentException` throw → Controller에서 catch** — 입력 오류 경로가 예외 채널을 빌림.
+- **Position이 일반 클래스** — data class 후보를 못 잡음.
+- **InputView에 출력 메시지 (안내문) 보유** — 입력 객체가 출력 책임도 가짐.
+- **상수 위치 혼란** — 파일 위 `const val`, companion object, 익명 object 어느 게 맞는지 결정 기준 부재.
+
+## 리뷰어 의견 요지
+
+리뷰어 @s9hn의 핵심 메시지는 **"예외는 정말 예외일 때만"**.
+
+1. **try-catch 지양 원칙** — Effective Kotlin Item 7 인용:
+   - 논리 오류일 때만 예외를 던진다
+   - 논리 오류가 아니면 null 반환
+   - null로 처리할 수 없으면 sealed class 반환
+   - 일반 코틀린 코드에서 try-catch를 사용하지 않는다
+   
+2. **사용자 입력 오류는 View의 책임** — "입력받는 메서드에서 엘비스연산자를 활용한 재귀처리" → 안전한 값만 도메인에 넘김. 도메인은 논리 오류만 다룬다.
+
+3. **require()는 "널/조건 검사 축약"이며 try-catch 회피와 충돌 아님** — try-catch 지양 ≠ Exception 지양.
+
+4. **runCatching의 강력함** — 예외 발생부터 분기까지 일급 객체로 다룸.
+
+학생 yujamint의 후속 질문 (`Controller에서 객체 생성 때마다 null 체크 분기를 해야 하는가?`)에 대한 답: **사용자 입력 검증을 View 쪽으로 끌어올리면 Controller에서 null 체크 자체가 줄어든다.**
+
+@kdkdhoho (다른 크루)도 이 토론에 참여 — "다른 조 PR에서는 같은 코드에 다른 반응이 왔다"며 일관성 없음 지적. → @s9hn의 추가 설명으로 "try-catch 지양 = 흐름 제어용 예외 회피"임을 명확화.
+
+- **대표 인용:**
+  > Exception을 throw한다는 것은, 결국 어딘가에서 catch 해서 별도 처리를 반드시 하겠다는 의미가 있습니다... 결국 사용자입력오류에 대한 처리는 입출력뷰의 책임이라고 생각했어요. 그래서 입력받는 메서드에서 엘비스연산자를 활용한 재귀처리를 구현했습니다.
+  >
+  > — @s9hn on `src/main/kotlin/controller/ConsoleController.kt:34`
+
+  > 논리적인 오류가 아니면 예외를 던지지 말고 null을 반환한다... 일반적인 코틀린 코드에서 try-catch를 사용하지 않는다.
+  >
+  > — @s9hn on `src/main/kotlin/controller/ConsoleController.kt:34`
+
+## 얻은 교훈
+
+- **예외는 흐름 제어용이 아니다.** "잘못된 입력 → 다시 받기"는 정상 흐름이지 예외 상황이 아님. View에서 재귀/루프로 처리해야 함.
+- **검증 책임의 두 갈래.** 사용자 입력 검증 = View 책임 (UI 경로), 도메인 무결성 검증 = Domain 책임 (논리 오류). 두 가지를 같은 `try-catch + IllegalArgumentException` 채널로 합치지 말 것.
+- **"같은 코드에 다른 반응"은 리뷰어 차이가 아니라 *맥락*의 차이일 수 있다.** 한 PR에서는 도메인 검증으로 적절했고, 다른 PR에서는 사용자 입력을 도메인이 막고 있는 형태였을 수 있음. 코드만이 아니라 책임 위치를 보고 판단.
+- **상수의 자리는 *재사용 범위*가 결정한다.** 한 함수 안에서만 쓰이면 리터럴, 한 클래스 안 = companion object, 여러 클래스 = top-level const.
+- **PR 질문에 "백엔드 크루와 사전 토론 결과"를 적어두면 리뷰어가 그 합의를 검증할 수 있게 된다** — 개인 결정이 아닌 토론된 결정으로 격상.

package/package.json

@@ -0,0 +1,46 @@
+{
+  "name": "oh-my-oop",
+  "version": "0.2.0",
+  "description": "OOP/RDD design toolkit: choose a portable Agent Skill with CLI or an MCP server",
+  "type": "module",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/no1msh/Oh-My-OOP.git"
+  },
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org/"
+  },
+  "bin": {
+    "oh-my-oop": "dist/index.js"
+  },
+  "files": [
+    "dist",
+    "skills",
+    "lessons",
+    "MCP_STRUCTURE.md",
+    "SCOPE.md"
+  ],
+  "scripts": {
+    "build": "tsc -p .",
+    "prepack": "npm run build",
+    "dev": "tsx src/index.ts",
+    "test": "vitest run",
+    "test:watch": "vitest"
+  },
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "^1.0.4",
+    "gray-matter": "^4.0.3",
+    "zod": "^3.23.8",
+    "zod-to-json-schema": "3.25.2"
+  },
+  "devDependencies": {
+    "typescript": "^5.5.0",
+    "@types/node": "^20.14.0",
+    "tsx": "^4.19.0",
+    "vitest": "^4.1.11"
+  },
+  "engines": {
+    "node": ">=18.17"
+  }
+}

package/skills/oh-my-oop/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: oh-my-oop
+description: Help design or review object responsibilities, CRC cards, collaborations and OOP/RDD alternatives using the Oh-My-OOP CLI. Use for object-oriented modeling and design-model checks, not whole-application architecture orchestration.
+---
+
+# Oh-My-OOP
+
+Use the shared OOP core through the CLI; an MCP connection is not required.
+
+Requires Node.js 18.17 or later, the built Oh-My-OOP CLI, and an agent allowed to read local files and execute commands. No model API key is required by the toolkit.
+
+## Execution
+
+Skill distribution is managed by `npx skills`; it installs these instructions, not the OOP executable. Use `oh-my-oop` on PATH, or `node "/absolute/Oh-My-OOP/dist/index.js"` when the user/project explicitly supplied that CLI path. Check `--version` before first use. If neither is available, ask the user to build/configure the CLI; do not silently download software or run `npx oh-my-oop`. Do not infer the executable location relative to this Skill: installation may copy or symlink only the Skill folder. There is no generated `runtime.json` dependency.
+
+Always specify `--root "<target-project>"` for OOP operations. Do not confuse the toolkit directory with the user's project. The core stores design records in that project's `.oop/` directory. Installing this Skill does not initialize project state or authorize modifications.
+
+Discover operations with `system capabilities`. Before an unfamiliar operation, obtain its executable input schema:
+
+```sh
+echo '{"command":"oop","operation":"class_upsert"}' | oh-my-oop system describe --input -
+```
+
+Run `oop <operation> --root "<target-project>" --input <json-file>`, or pass a JSON object on stdin using `--input -`. Do not put an `action` field in that JSON. JSON stdout is the result; stderr is diagnostics. Do not invoke the CLI without arguments: that starts an MCP server instead.
+
+## Working with the user
+
+- For an existing design, start with `oop state_read`. If no workspace exists, initialize with `oop init` only when the user wants to create/save a design. A conceptual explanation need not create files.
+- For new modeling, clarify the use case and collaboration before assigning classes. Use `use_case_add`, `propose_responsibilities`, `class_upsert`, `assign_responsibility` and `collaboration_define` as needed, not as a mandatory checklist for every question.
+- Use `propose_alternatives` to compare responsibility ownership or collaboration choices. Present multiple viable alternatives and concrete domain-specific tradeoffs; do not treat heuristic seeds as the single correct answer.
+- Use `design_validate` to review the stored design model. Findings are advisory, not approval or implementation proof. Preserve the multiple remedies and explain when each fits.
+- For implementation review, `conformance_check` returns a contract/checklist. Read authorized implementation evidence and compare it yourself. It does not parse Kotlin, verify all source, or prove behavior. Name missing evidence and ask contextual questions when intent cannot be inferred.
+- `diagram_generate` writes by default; use `write_current:false` for preview. `design_compare` compares diagrams/history, not arbitrary source trees. Do not use `init force:true` to solve missing-context errors.
+
+Retain user decisions and distinguish facts, assumptions and unresolved intent. Use “비즈니스 로직” in Korean. Do not reclassify a user's scoped decision without explaining changed evidence. Do not expand a design review into implementation or worker execution.
+
+## Choosing the interface
+
+If the user chose this Skill, use the CLI without asking to connect MCP. If the user explicitly chooses an already connected MCP interface instead, use its `oop_*` equivalents. Do not execute a state-changing operation through both interfaces. They share `.oop` data, but do not share chat history or provide concurrent-edit locking.