빌드는 코드가 실행될 때 완료되는 것이 아닙니다. 코드가 올바를 때 완료됩니다.
AI는 빠르게 움직입니다. 빠르다는 것은 표면적으로는 작동하지만 아키텍처에서 벗어나고, 디자인 시스템을 위반하거나, 중요한 엣지 케이스를 놓치는 것들이 만들어짐을 의미합니다. 이 스킬은 이러한 문제들이 더 큰 문제로 이어지기 전에 잡아냅니다.
모든 기능 이후에, 다음으로 넘어가기 전에 이 스킬을 실행하세요.
이 스킬이 하지 않는 일
이 스킬은 어떤 것도 수정하지 않습니다. 발견한 내용을 보고하고, 개발자가 무엇이 중요하고 어떻게 처리할지 결정하도록 합니다. 이해 없이 수정하는 것은 문제를 해결하는 것이 아니라 묻어버리는 것입니다.
1단계 — 무엇이 구축되었어야 하는지 이해하기
검토를 시작하기 전에 기준을 설정하세요.
다음 순서로 읽으세요:
/architect의 구현 계획 (존재하는 경우)- 주어진 기능 설명 또는 작업
- 관련 컨텍스트 파일 — 아키텍처 경계, 코드 표준, 디자인 규칙
계획이 없다면, 검토하기 전에 개발자에게 해당 기능이 무엇을 해야 했는지 설명해 달라고 요청하세요. 올바름이 무엇인지 알지 못하면 정확성을 확인할 수 없습니다.
2단계 — 세 가지 계층으로 검토하기
계층 1 — 계획과 일치합니까?
구축된 것을 계획된 것과 비교하세요.
확인:
- 기능 설명의 모든 부분이 모두 구현되었는가?
- 계획 중에 내려진 결정들이 코드에 반영되었는가?
- 범위 — 구현이 경계 내에 머물렀는가, 아니면 요청되지 않은 것들이 추가되었는가?
계획되었지만 누락된 것은 플래그를 지정하세요. 구축되었지만 계획되지 않은 것도 플래그를 지정하세요.
계층 2 — 시스템을 존중합니까?
이곳이 AI 드리프트가 가장 흔히 발생하는 지점입니다. 기능은 작동하지만 프로젝트가 의존하는 규칙을 위반합니다.
확인:
- 아키텍처 경계 — 코드가 올바른 위치에서 올바른 책임을 가지고 있는가? API 라우트에 UI 로직이 없어야 합니다. 컴포넌트에 DB 호출이 없어야 합니다. 프로젝트의 경계가 무엇이든 존중되고 있는가?
- 디자인 시스템 — 올바른 토큰, 클래스, 패턴이 사용되었는가? 변수여야 할 하드코딩된 값이 있는가? 디자인 시스템을 사용해야 할 원시 색상 클래스가 있는가?
- 코드 표준 — 네이밍 규칙, 파일 구성, TypeScript 엄격함, 에러 처리 패턴 — 프로젝트가 정한 것과 일치하는가?
- 기존 패턴 — 이 기능이 기존 패턴 대신 새로운 패턴을 도입하고 있는가?
계층 3 — 프로덕션 준비가 되었습니까?
확인:
- 에러 처리 — 문제가 발생했을 때 어떤 일이 일어나는가? 에러가 캐치되어 처리되는가, 아니면 기능이 조용히 실패하는가?
- 엣지 케이스 — 빈 상태, 로딩 상태, 누락된 데이터 — 이러한 것들이 처리되었는가?
- 콘솔 에러 — 브라우저나 터미널에 에러나 경고가 있는가?
- 명백한 버그 — 실제 사용자에게 분명히 문제가 될 만한 것이 있는가?
3단계 — 발견한 내용 보고하기
세 가지 계층을 모두 완료한 후, 명확한 보고서를 작성하세요. 문제를 묻지 마세요. 부드럽게 말하지 마세요. 개발자가 정보에 기반한 결정을 내릴 수 있도록 정직하게 보고하세요.
## 검토 — [기능 이름]
### 계층 1 — 계획 정렬
[통과 / 문제 발견]
[계획된 것과 구축된 것 사이의 차이점을 나열]
### 계층 2 — 시스템 무결성
[통과 / 문제 발견]
[아키텍처, 디자인 또는 코드 표준 위반 사항을 나열]
### 계층 3 — 프로덕션 준비 상태
[통과 / 문제 발견]
[에러 처리 누락, 엣지 케이스 또는 명백한 버그를 나열]
### 요약
[Y]개 계층에서 [X]개의 문제가 발견되었습니다.
[문제가 없는 경우: "문제가 발견되지 않았습니다. 이 기능은 출시 준비가 되었습니다."]
[문제가 있는 경우: "다음 기능으로 넘어가기 전에 위 문제를 해결하십시오."]
4단계 — 개발자가 결정하도록 하기
보고서를 제시한 후 멈추세요. 수정을 시작하지 마세요. 개발자가 요청하지 않는 한 수정을 제안하지 마세요.
개발자가 다음을 수행할 때까지 기다리세요:
- 특정 문제를 수정해 달라고 요청
- 문제가 의도적이며 무시해도 된다고 알림
- 모든 것이 해결되었고 다음 단계로 넘어갈 준비가 되었음을 확인
개발자가 품질 결정을 책임집니다. 당신은 정보를 제공할 뿐입니다.
심각도 가이드
모든 문제가 동일하지는 않습니다. 개발자가 우선순위를 정할 수 있도록 다음을 사용하세요:
치명적 — 다음으로 넘어가기 전에 반드시 수정
- 향후 기능을 망가뜨릴 아키텍처 경계 위반
- 무음 실패를 유발하는 에러 처리 누락
- 계획되었지만 완전히 누락된 기능
중요 — 곧 수정
- UI 불일치를 유발할 디자인 시스템 이탈
- 코드베이스 전체에 걸쳐 누적될 코드 표준 위반
- 실제 사용자가 마주칠 엣지 케이스
사소 — 편할 때 수정
- 동작에 영향을 주지 않는 네이밍 불일치
- 누락된 최적화
- 디자인 시스템에 영향을 주지 않는 스타일 문제
각 문제에 심각도를 표시하여 개발자가 빠르게 분류할 수 있도록 하세요.
기준
이 스킬이 답하는 질문은 "작동합니까?"가 아닙니다.
질문은 "올바릅니까?"입니다.
작동하는 것과 올바른 것은 같지 않습니다. 기능이 오늘 작동할 수 있지만 내일 프로젝트를 망가뜨릴 수도 있습니다. 리뷰는 그 차이를 잡기 위해 존재합니다.