가장 저렴하게 잡을 수 있는 버그는 리뷰어가 40번 라인에 동그라미를 치는 버그입니다. 비싼 버그는 잘못된 라인으로 나타나지 않고, 깨끗하고 완벽한 상태로 잘못된 접근 방식 (wrong approach) 자체로 배포됩니다. 당신의 재시도 루프 (retry loop)는 올바르지만, 잘못된 레이어 (layer)에서 재시도를 수행하고 있습니다. 당신의 캐시 (cache)에는 버그가 없지만, 잘못된 키 (key)에서 무효화됩니다. 일반적인 리뷰어(사람 또는 AI)는 이를 그냥 지나칩니다. 왜냐하면 그들의 초점이 _"이 라인이 맞는가"_에 맞춰져 있지, _"이것이 구축해야 할 올바른 것인가"_에 맞춰져 있지 않기 때문입니다.

이번 주에 저는 cursor-plugin-cc의 v0.4.0을 배포했으며, 핵심은 바로 그 두 번째 질문을 수행하는 것이 유일한 임무인 리뷰 명령어입니다.

이 플러그인을 아직 보지 못하셨다면 간단한 배경 설명을 드리겠습니다: 이것은 Claude Code TUI를 떠나지 않고도 Claude가 계획하고, Cursor의 Composer가 코드를 작성하며, Claude가 diff를 리뷰하는 하나의 루프를 계속 실행하는 Claude Code 플러그인입니다. 두 도구가 각각 가장 잘하는 절반씩을 수행합니다. v0.4.0은 이 중 리뷰 (review) 부분을 강화했습니다.

/cursor:adversarial-review

단순히 구현 결함을 찾는 대신, 선택된 구현과 설계에 의문을 제기하는 읽기 전용 (read-only) 리뷰입니다. 이를 diff에 적용하면 (기본적으로 working tree, 브랜치의 경우 --base <ref>, --scope, --model은 일반적인 /cursor:review와 동일한 대상 선택 방식 사용) 다음과 같은 사항들을 압박 테스트 (pressure-tests) 합니다:

• 변경 사항이 의존하는 가정 (assumptions),
• 명시적으로 말했든 아니든 당신이 내린 트레이드오프 (tradeoffs),
• 실제 부하 (load), 동시성 (concurrency), 그리고 엣지 케이스 (edge cases) 상황에서의 실패 모드 (failure modes),
• 그리고 가장 중요한 것 — 더 단순하거나 더 안전한 접근 방식이 목적을 달성할 수 있었을지 여부.

이 기능은 조종 가능 (steerable) 합니다. 뒤에 오는 모든 텍스트는 집중 대상이 됩니다. "is the retry/backoff design sound under load?"라고 입력하면 당신이 불안해하는 바로 그 지점에 모든 도전 과제를 집중시킵니다.

/cursor:adversarial-review
/cursor:adversarial-review --base main
/cursor:adversarial-review "question the retry/backoff design under load"
...

내부적으로는 /cursor:review --adversarial로 작동하므로, /cursor:status, /cursor:result, /cursor:cancel에서 일반적인 작업(job)으로 표시됩니다. 대부분의 사람들이 결코 찾지 못했던 기존의 --adversarial 플래그는 이제 일급 객체(first-class)이자 발견 가능한 명령어가 되었습니다. 또한 이는 사용자 호출 전용(disable-model-invocation: true)입니다. 설계에 대한 도전(design challenge)은 의도적으로 수행해야 하는 것이지, 에이전트가 스스로 실행해서는 안 되는 것이기 때문입니다.

단순히 /cursor:review에게 "더 열심히 해봐"라고 말하는 대신 왜 이를 분리했을까요? 더 엄격한 버그 검사(bug pass)와 설계 도전(design challenge)은 서로 다른 작업이며, 이 둘을 혼동하면 어느 쪽도 제대로 얻을 수 없기 때문입니다. 두 번째 작업에 이름을 붙임으로써, 당신은 자신이 완전히 확신하지 못하는 변경 사항을 배포하기 직전에 실제로 이를 실행하게 됩니다. 바로 그때가 아무도 신경 쓰지 않는 시점입니다.

내가 조용히 자랑스러워하는 부분: 당신의 코드를 건드릴 수 없다는 점

두 리뷰 명령어 모두 선의가 아닌 구조적으로(by construction) 읽기 전용입니다. 작업이 실행된 후, 사후 점검(post-flight check) 단계에서 워킹 트리(working tree)가 변경되었다면 해당 작업을 실패 처리합니다. 따라서 동일한 플러그인이 다른 곳에서 자동 승인(auto-approve) 기능과 함께 Composer를 실행하더라도, 리뷰가 몰래 편집으로 변질되는 일은 결코 발생할 수 없습니다. 빠른 모델에 당신의 디프(diff)를 전달하더라도, 그 모델이 할 수 있는 최악의 행동은 오직 _말하는 것_뿐임을 확신할 수 있습니다.

이러한 보장이 제가 적대적 검사(adversarial pass)를 신뢰하는 이유의 전부입니다. 논쟁을 벌이는 동안 "도움이 되겠다며" 리팩터링(refactor)까지 시도하는 리뷰어라면, 당신이 일일이 감시해야 하는 리뷰어일 뿐입니다.

먼저 추정하고, 그다음에 요청하기

매일 겪던 사소한 불편함(papercut)을 제거하는 작은 인체공학적(ergonomics) 수정 사항입니다. --wait 또는 --background를 전달하지 않으면, 이제 명령어가 먼저 디프(diff)의 크기를 측정합니다(git status, git diff --shortstat, 추적되지 않는 파일 수 계산 등). 그런 다음 대기할 것인지 아니면 백그라운드에서 실행할 것인지 사용자에게 단 한 번 묻습니다. 이때 1~2개의 아주 작은 파일 변경을 넘어선다면 백그라운드 실행을 권장합니다. 여러 파일에 대한 리뷰는 시간이 걸립니다. 다음 2분 동안 터미널이 차단될지 아닐지를 미리 추측해야 할 필요는 없습니다.

진짜 교훈: 노하우를 기술(skill)로 옮겼다

가장 흥미로운 변화는 명령어가 아닙니다. 한동안 작업을 타겟 저장소(repo)의 컨벤션에 맞추고, 5가지 필수 섹션(목표(Goal) / 저장소 컨텍스트(Repo context) / 수락 기준(Acceptance criteria) / 수정할 파일(Files to touch) / 검증 방법(How to verify))과 가드레일(guardrails) 블록을 포함하며, 약 5단계 또는 약 10개 파일 또는 2개의 아키텍처 레이어를 초과하는 것은 청킹(chunk)하고, 적합한 가장 작은 모델을 선택하며, 재개(resume)할지 새로 시작(fresh)할지를 결정하는 등의 작업을 정교한 Cursor 프롬프트로 전환하는 가이드라인은 cursor-runner 서브에이전트(subagent)의 프롬프트 내에 _인라인(inline)_으로 존재했습니다.

v0.4.0에서 이것은 composer-prompting **기술(skill)**로 이동했습니다. 이제 서브에이전트는 단 한 줄의 skills: 라인으로 이를 참조하며, 운영상의 핵심 골격인 _그라운딩(ground) → /cursor:delegate 호출 → Cursor의 출력을 있는 그대로 반환(return verbatim)_으로 축소되었습니다.

이 교훈은 이 플러그인을 넘어 일반화되며, 제가 MCP와 에이전트(agents)에 대해 써온 모든 글을 관통하는 동일한 맥락입니다: 에이전트의 프롬프트는 매 실행마다 비용을 지불하는 컨텍스트(context)입니다. 재사용 가능한 노하우는 그것이 필요한 각 에이전트 내부에 다시 기술되어 있어서는 안 됩니다. 대신 실제로 관련이 있을 때 로드되는, 참조된 하나의 기술(skill)에 속해야 합니다. 이렇게 하면 에이전트는 더 가벼워지고, 지식은 떠도는 세 개의 복사본 대신 하나의 집을 갖게 되며, 유지보수해야 할 대상은 줄어듭니다. 이는 MCP 서버에서 도구(tools)와 리소스(resources)를 분리하는 것과 같은 직관입니다: 가치가 있는 곳에만 무게를 두고, 그 외의 곳에는 두지 마십시오.

지루한 보장 사항들

여전히 런타임 의존성(runtime dependencies)은 제로입니다 — 순수 ESM, Node 표준 라이브러리(stdlib), 빌드 단계 없음, dist/ 폴더 없음. 여전히 MIT 라이선스입니다. CI는 모든 PR에 대해 Linux 및 macOS의 Node 18.18 / 20 / 22 환경에서 테스트와 린트(lint)를 실행합니다. 그리고 이 프로젝트는 OpenAI 측에서 동일한 트릭을 사용하는 Codex/GPT의 원형인 openai/codex-plugin-cc를 공개적으로 채택하여 Cursor CLI로 포팅한 것입니다. 공로를 인정해야 할 부분입니다.

사용해 보기

/plugin marketplace add freema/cursor-plugin-cc
/plugin install cursor@tomas-cursor
/reload-plugins
...

👉 github.com/freema/cursor-plugin-cc — v0.4.0, MIT.

코드 리뷰가 여러분의 코드 라인이 아닌, 여러분의 접근 방식 (approach) 자체를 마지막으로 변화시켰던 적이 언제인가요? 그것이 제가 실제로 원하는 리뷰이며, 동시에 거의 아무도 수행하지 않는 리뷰이기도 합니다. 여러분은 이를 습관으로 만들기 위한 방법을 찾으셨는지 궁금합니다.