리뷰 루프은(는) 무엇을 하나요?

단일 세션 내에서 작업자-검토자의 반복적 주기. 작업을 수행하고, 검토자 서브에이전트를 생성하여 비판하고, 피드백에 따라 수정하고, 품질 관문이 충족될 때까지 반복합니다.

핵심 원칙: 초고는 절대 최종본이 아닙니다. 반복적인 비판이 단일 패스보다 더 나은 결과를 만들어냅니다.

플랫폼 참고: 이 스킬은 서브에이전트 생성을 지원하는 에이전트에서 가장 잘 작동합니다. 해당 기능이 없는 플랫폼에서는 새로운 채팅 컨텍스트를 열고 작업 산출물만(이전 추론 과정 없이) 붙여넣은 후 1-10점과 구체적인 피드백을 요청하는 방식으로 검토 단계를 시뮬레이션하세요.

빠른 시작

다음과 같이 말합니다: "implement X, use review-loop" 또는 "run review-loop on the file I just wrote"
에이전트가 작업을 수행합니다(또는 기존 작업을 읽습니다)
별도의 비판자 서브에이전트가 1-10점으로 구체적인 피드백과 함께 평가합니다
에이전트는 점수가 8점(기본 품질 관문) 이상이 될 때까지 수정하고 반복합니다
최종 결과물과 함께 루프 요약이 제공됩니다

사용 시기

사용자가 "use review-loop", "polish this", "iterate on this", "/review-loop"라고 말할 때
품질이 속도보다 중요한 복잡한 구현
설계 문서, 명세서 또는 기술 문서
견고함이 필요한 코드(보안, 데이터 파이프라인, 금융 로직)
사용자가 프로세스에 적대적 비판을 포함시키려 할 때

사용하지 말아야 할 시기

간단한 수정, 빠른 편집, 한 줄 변경
테스트가 품질 관문인 작업(TDD + CI 사용)
사용자가 단순히 빠른 완료를 원할 때
목표가 출시가 아닌 학습인 탐색/스파이크 작업
명확한 승인 기준이 없는 작업 — 먼저 기준을 정의한 후 review-loop 사용

기본값

설정	기본값
최소 루프	2
최대 루프	4
품질 관문	8/10
작업자 모델	(현재 모델)
검토자 모델	(현재 모델 또는 빠른/균형 잡힌 대안)

모델 선택

검토자 작업은 로직과 제약 조건을 평가합니다. 작업자 작업은 코드를 작성하고 수정합니다. 그에 따라 서브에이전트 기능을 선택하세요.

중요 규칙: 검토자는 항상 작업자와 동등하거나 더 강력해야 합니다. 검토자가 작업자보다 약하면 복잡한 로직을 제대로 비판하거나 미묘한 회귀를 잡아낼 수 없습니다.

작업 복잡도	작업자 성능	검토자 성능	근거
단순/기계적 (CRUD, 포맷팅, 보일러플레이트)	빠름 / 경량	균형 잡힘	경량 작업자는 빠르고, 균형 잡힌 검토자가 문제를 쉽게 찾음
표준 (기능, 리팩터링, 문서)	균형 잡힘	균형 잡힘	비용, 속도, 품질의 좋은 조화
복잡 (다중 파일, 통합, 설계)	균형 잡힘	고급 / 추론	고급 검토자가 미묘한 아키텍처 문제를 찾고, 균형 잡힌 작업자가 구현 가능
매우 복잡 (보안, 금융, 분산 시스템)	고급 / 추론	고급 / 추론	둘 다 전체 컨텍스트와 추론 능력 필요. 검토자는 작업자와 성능이 일치해야 함

황금률: 작업자는 검토자의 피드백에 따라 행동할 만큼 충분히 똑똑해야 합니다. 검토자가 "채널 기반 세마포어로 경쟁 조건을 고치세요"라고 말했는데 작업자가 동시성을 이해하지 못하면 루프가 수렴되지 않습니다.

에스컬레이션 신호: 동일한 피드백으로 2회 연속 루프 후에도 점수가 개선되지 않으면 작업자 모델이 너무 약한 것입니다. 에스컬레이션:

옵션 A: 사용자에게 더 강력한 모델로 전환 요청
옵션 B: 품질 관문을 임시로 낮추고 차이를 사용자에게 알림
옵션 C: 작업을 더 작은 하위 작업으로 분할하고 각각에 review-loop 실행

기본 동작: 주 에이전트가 작업자이므로, 작업에 따라 현재 성능과 동일하거나 그 이상인 검토자 서브에이전트를 생성합니다:

대부분의 작업 → 표준/균형 잡힌 검토자
전문/어려운 작업 → 고급/추론 검토자
빠른 확인 → 빠른/경량 검토자(자신도 경량 작업자로 동작하는 경우에만)

사용자 재정의

사용자는 요청 시 인라인으로 모든 기본값을 재정의할 수 있습니다. 자연스럽게 파싱하세요:

"implement X with review-loop, quality gate 9, use advanced model for review, max 5 loops"
"polish this, 2 loops minimum, gate at 8"
"run review-loop with fast reviewer, max 2 loops"
"use review-loop, reasoning reviewer, quality gate 9, min 3 max 6"

파싱 규칙:

"quality gate N" 또는 "gate N" → quality_gate = N
"[model] reviewer" 또는 "review with [model]" → 검토자 모델 재정의
"max N loops" → max_loops = N
"min N loops" → min_loops = N
사용자가 지정하지 않으면 기본값 사용
사용자가 "thorough" 또는 "strict"라고 말하면 quality_gate 8, min_loops 2로 해석
사용자가 "quick" 또는 "fast"라고 말하면 max_loops 2, quality_gate 6으로 해석

프로세스

flowchart TD
    A[작업 수행] --> B[검토자 서브에이전트 생성]
    B --> C{최소 루프 충족?}
    C -- 아니오, 항상 계속 --> E[피드백 기반 수정]
    C -- 예 --> D{점수 >= 품질 관문?}
    D -- 예 --> F[최종 마무리]
    D -- 아니오 --> G{최대 루프 도달?}
    G -- 예, 그래도 중단 --> F
    G -- 아니오 --> E
    E --> B
    F --> H([완료])

단계별 가이드

1단계: 작업 수행

평소처럼 작업을 완료합니다. 코드를 작성하고, 명세를 만들고, 기능을 구현합니다. 망설이지 말고 최선의 첫 번째 시도를 만드세요.

2단계: 검토자 서브에이전트 생성

에이전트 도구를 사용하여 검토자를 파견합니다. 검토자는 다음을 충족해야 합니다:

별도의 서브에이전트(새로운 컨텍스트, 추론에 고정되지 않음)
작업 산출물(파일, diff)만 받음 — 사고 과정은 받지 않음
1-10점으로 구체적이고 실행 가능한 피드백 제공
기본적으로 균형 잡힌/표준 모델 사용(복잡/전문 작업의 경우 고급 추론 모델 사용)

검토자 프롬프트 템플릿:

당신은 비판적인 검토자입니다. 다음 작업을 1-10점으로 평가하고 구체적이고 실행 가능한 피드백을 제공하세요.

## 수행된 작업
{작업에 대한 간략한 설명}

## 검토 기준
{작업별 기준 — 이 작업에 중요한 사항}

잘 작성된 기준의 예:
  REST API 엔드포인트의 경우:
    - 올바른 HTTP 상태 코드 사용
    - 모든 매개변수에 입력 검증 존재
    - 인증 적용, 인증되지 않은 접근 차단
    - N+1 쿼리 패턴 없음

  설계 문서의 경우:
    - 문제 설명이 명확함
    - 대안을 고려하고 장단점을 제시
    - 구현 복잡성에 대한 모호한 표현 없음
    - 성공 지표가 측정 가능함

  데이터 파이프라인의 경우:
    - 멱등성 — 재실행해도 안전
    - 스키마 변경을 우아하게 처리
    - 실패 모드 문서화
    - 개인정보(PII) 처리 명시

## 지침
1. 작업물을 주의 깊게 읽으세요
2. 1-10점으로 평가하세요:
   - 1-3: 근본적으로 손상되었거나 주요 요구사항 누락
   - 4-6: 작동하지만 심각한 문제 있음
   - 7-8: 좋음, 사소한 문제만 있음
   - 9-10: 우수함, 출시 준비 완료
3. 해당되는 경우 파일:줄 참조와 함께 구체적인 문제를 나열하세요
4. 각 문제에 대해 왜 중요한지(WHY)와 무엇을 고칠지(WHAT) 설명하세요
5. 정중할 필요 없습니다 — 정직하고 직접적으로 말하세요
6. 점수를 "Score: N/10" 형식으로 명확히 표시하세요

## 검토할 파일
{파일 내용을 붙여넣거나 관련 발췌문과 함께 파일 경로를 나열}

3단계: 피드백 파싱

검토자 응답에서 다음을 추출합니다:

점수 (숫자)
문제점 (심각 / 중요 / 사소로 분류)
구체적인 수정 사항 (무엇을 변경할지)

사용자에게 보고:

루프 {N}/{max}: 점수 {X}/10
- {주요 피드백 요약}

4단계: 중지 조건 확인

다음 순서로 확인:

완료된 루프 < 최소 루프 → 계속 (항상)
점수 >= 품질 관문 → 중지, 최종 마무리로 이동
완료된 루프 >= 최대 루프 → 중지, 최종 마무리로 이동
그 외 → 수정 후 반복

5단계: 수정

검토자의 피드백을 처리합니다. 심각 및 중요 문제를 해결합니다. 사소한 문제는 선택 사항입니다. 그런 다음 2단계로 돌아갑니다.

중요: 각 수정은 목표 지향적이어야 합니다. 모든 것을 다시 작성하지 말고 검토자가 지적한 부분만 고치세요. 이전 피드백을 모두 기억하여 회귀를 방지하세요.

6단계: 최종 마무리

루프가 종료되면(품질 관문 충족 또는 최대 루프 도달):

남은 사소한 문제가 있다면 간단히 해결
최종 결과물이 일관적인지 확인(수정 주기로 인한 흔적 없음)
최종 점수와 루프 횟수를 사용자에게 보고

작업 유형별 검토 기준 조정

작업 유형	검토자가 중점을 둘 사항
코드	정확성, 경계 조건, 오류 처리, 가독성, 보안 문제 없음
명세/설계	완전성, 실현 가능성, 모호함 없음, 구현 가능성
리팩터링	동작 변경 없음, 회귀 없음, 이전보다 깔끔함
문서	명확성, 구조, 대상 독자에 적합, 불필요한 내용 없음
버그 수정	근본 원인 해결, 회귀 테스트 존재, 부작용 없음
인프라/IaC	멱등성, 최소 권한, 하드코딩된 비밀 없음, 삭제 안전성
데이터베이스 마이그레이션	되돌리기 가능성, 인덱스 전략, 데이터 손실 위험, 대규모 성능
API 설계	하위 호환성, 인증, 버전 관리, 오류 계약
테스트 스위트	경계 조건 커버리지, 테스트 간 의존성 없음, 의미 있는 단언

두 가지 작동 모드

모드 A: "수행 및 검토" (전체 주기)

사용자가 작업을 주고 review-loop 사용을 지시합니다. 작업을 수행하고 검토 루프를 실행합니다.

사용자: "캐싱 레이어를 구현하세요. review-loop 사용, 품질 관문 8."

당신:
1. 캐싱 레이어 구현
2. 검토자 생성 → 점수 6, 피드백: 제거 정책 누락, TTL 없음
3. 수정: 제거 정책 + TTL 추가
4. 검토자 생성 → 점수 8, 피드백: 사소한 명명 문제
5. 최종 마무리, 완료

모드 B: "기존 작업 검토" (검토만)

사용자가 이미 작업을 수행했거나 당신이 이미 작업을 수행했습니다. 기존 작업에 대해 검토 루프만 실행합니다.

사용자: "방금 작성한 인증 모듈에 대해 review-loop를 실행하세요"

당신:
1. 인증 모듈 읽기
2. 검토자 생성 → 점수 5, 피드백: SQL 인젝션, 속도 제한 없음
3. 수정: 쿼리 매개변수화, 속도 제한기 추가
4. 검토자 생성 → 점수 8, 승인
5. 완료

위험 신호

절대 하지 말아야 할 것:

서브에이전트 대신 스스로 검토(앵커링 편향)
정당한 이유 없이 "피드백이 틀렸다"며 수정 주기를 건너뛰기
스스로 점수를 부풀리기("내 생각에는 이게 9점인데")
사용자 동의 없이 최대 루프를 넘어 계속 진행
전체 추론/이력을 검토자에게 전달(의도가 아닌 작업 자체를 검토해야 함)

검토자가 틀렸다면:

증거를 제시하여 반박(피드백을 반증하는 코드/테스트 보여주기)
해당 사항을 수정에서 제외
사용자 보고 시 메모
품질 기준을 낮추어 보상하지 않음

예시 보고서 형식

--- 리뷰 루프: {작업 이름} ---

루프 1/4: 점수 6/10
  검토자: 입력 검증 누락, 네트워크 타임아웃 오류 처리 없음,
            함수가 너무 김(80줄).
  조치: 세 가지 문제 모두 수정.

루프 2/4: 점수 8/10
  검토자: 깔끔함. 사소: 변수명 `d`가 더 설명적이면 좋겠음.
  조치: 품질 관문 충족(8 >= 8). 최종 마무리.

결과: 2루프 만에 8/10. 완료.

알려진 제한 사항

검토자 서브에이전트는 이전 루프에 대한 기억이 없습니다. 각 검토자 프롬프트에 이전 피드백 컨텍스트를 명시적으로 포함하여 해결된 문제가 반복되지 않도록 하세요.
검토자 프롬프트 기준이 너무 모호하면 점수가 부풀려질 수 있습니다. 구체적이고 측정 가능한 기준을 작성하는 데 시간을 투자하세요.
이 스킬은 보안이 중요하거나 규정 준수가 필요한 코드에 대한 사람의 코드 리뷰를 대체하지 않습니다. 결과물을 강력한 첫 번째 패스로 취급하세요.
작업이 불충분하게 정의되면 루프 수렴이 보장되지 않습니다. 시작하기 전에 명확한 승인 기준을 정의하세요.

비용 및 속도

각 루프 = 검토자 서브에이전트 호출 1회
전체 3루프 주기의 경우 단일 구현 패스 시간의 약 1~2배 소요 예상
버그 있는 코드, 모호한 명세를 출시하거나 늦은 단계의 검토 주기를 유발하는 것보다 저렴합니다.
대부분의 검토에는 기본/표준 모델을 사용하고, 전문 영역(보안 감사, 분산 시스템, 금융 공학)에만 고급 추론 모델로 업그레이드하세요.

라이선스

MIT — 모든 AI 도구 또는 플랫폼에서 자유롭게 사용, 수정, 재배포할 수 있습니다. 저작자 표시를 권장합니다. 기여를 환영합니다.

리뷰 루프

리뷰 루프란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서