adversarial-reviewer

adversarial-reviewer skill 개요

adversarial-reviewer가 하는 일

adversarial-reviewer는 적대적 코드 리뷰를 위한 prompt-only Claude skill입니다. 일반적인 “이 PR을 리뷰해 주세요” 방식으로 훑는 대신, 모델이 변경 사항을 의도적으로 까다로운 리뷰어 페르소나로 살펴보게 합니다. 운영 장애를 일으키려는 방해자, 맥락을 잘 모르는 신입 엔지니어, 보안 감사관의 관점에서 코드를 검토합니다. 목표는 친절한 어시스턴트나 자기 검토 루프가 무심코 넘어갈 수 있는 위험을 드러내는 것입니다.

코드 리뷰 의사결정에 가장 잘 맞는 경우

adversarial-reviewer skill은 diff, commit, 위험도가 높은 파일을 병합 전에 더 날카롭게 검토하려는 엔지니어, 테크 리드, AI 지원 개발팀에 잘 맞습니다. 특히 인프라 변경, 인증 로직, migration, API contract 변경, refactor, 어시스턴트로 생성한 코드를 병합하기 전에 유용합니다.

일반 리뷰 프롬프트와 다른 점

일반적인 리뷰 프롬프트는 균형 잡힌 피드백을 내놓는 경우가 많고, 코드가 “괜찮아 보이면” 일찍 멈출 수 있습니다. 이 skill은 의도적으로 불편하게 설계되어 있습니다. 각 페르소나는 최소 하나의 이슈를 찾아야 하고, 발견 사항은 심각도별로 분류되며, 여러 페르소나가 동시에 지적한 이슈는 심각도가 올라갑니다. 따라서 변경 사항이 대체로 괜찮다는 확인용이라기보다, 놓치기 쉬운 사각지대를 드러내는 데 적합합니다.

도입 시 고려할 점

adversarial-reviewer는 외부 의존성이 없고 단일 SKILL.md 안에 담긴 것으로 보이므로, 검토하고 설치하기가 간단합니다. 다만 테스트, 정적 분석, 보안 스캐너를 대신 실행해 주지는 않습니다. 결과의 품질은 사용자가 제공하는 diff, 주변 맥락, 제약 조건에 크게 좌우됩니다.

adversarial-reviewer skill 사용 방법

adversarial-reviewer 설치 및 소스 확인

Claude skills installer로 GitHub skill directory에서 설치합니다. 예를 들면 다음과 같습니다.

npx skills add alirezarezvani/claude-skills --skill adversarial-reviewer

팀 워크플로에 넣어 신뢰하기 전에 upstream skill 파일을 읽어 보세요.

engineering-team/skills/adversarial-reviewer/SKILL.md

이 파일이 동작 방식의 핵심 출처입니다. 페르소나, 리뷰 명령, 심각도 모델, verdict 형식을 정의합니다. scripts/, rules/, references/ 같은 지원 폴더는 보이지 않으므로, 이 skill은 도구 기반 리뷰 시스템이라기보다 주로 프롬프트 로직에 가깝습니다.

더 강한 리뷰를 만드는 입력

adversarial-reviewer를 제대로 활용하려면 구체적인 리뷰 대상과 운영 맥락을 함께 제공해야 합니다. 약한 입력은 “이 코드 리뷰해 줘”입니다. 더 좋은 입력은 다음과 같습니다.

• HEAD~3, PR diff, 선택한 파일처럼 diff 또는 branch range
• 코드가 의도한 동작
• 실패했을 때의 production 영향
• 보안 민감 영역, 데이터 타입, auth boundary, migration 위험
• 이미 추가한 테스트 커버리지 또는 의도적으로 빠진 테스트
• “전체 rewrite는 제안하지 말 것”, “backwards compatible이어야 함” 같은 제약 조건

좋은 프롬프트 예시는 다음과 같습니다. “Use adversarial-reviewer for Code Review on this PR diff. Focus on payment webhook idempotency, database transaction safety, and whether a new engineer could safely maintain this in six months. Treat regressions that can double-charge users as blockers.”

실무 리뷰 워크플로

첫 번째 self-review를 마친 뒤, merge 전에 이 skill을 사용하세요. 신호 대 잡음비가 높은 워크플로는 다음과 같습니다.

1. 먼저 테스트, type check, linter를 실행해 skill이 뻔한 실패에 주의를 낭비하지 않게 합니다.
2. adversarial-reviewer에 diff 또는 commit range 리뷰를 요청합니다.
3. 발견 사항을 실제 blocker, 유용한 concern, false positive로 나눕니다.
4. 가장 강한 지적에 대해 코드를 수정하거나 테스트를 추가합니다.
5. 수정된 diff에 대해 skill을 다시 실행하되, 아직 해결되지 않은 위험에만 집중하도록 요청합니다.

이 순서는 전체 repository에 대한 광범위한 비평을 요청하는 것보다 더 잘 작동합니다. 이 skill은 최근 변경 사항과 merge 판단을 돕도록 설계되었지, 제한 없는 architecture review를 위한 도구는 아닙니다.

실제 팀을 위한 프롬프트 패턴

변경의 위험도가 높다면 명시적으로 프레이밍하세요.

Use adversarial-reviewer on the staged changes. Return BLOCK / CONCERNS / CLEAN. Pay special attention to auth bypass, data loss, migration rollback, and observability gaps.

유지보수성 중심 리뷰에는 다음처럼 요청할 수 있습니다.

Apply adversarial-reviewer as if the next maintainer is a new hire. Identify confusing abstractions, hidden coupling, missing invariants, and tests that would fail to explain intent.

보안 민감 리뷰에는 다음처럼 요청하세요.

Use the Security Auditor persona aggressively. Assume hostile input, privilege escalation attempts, broken access control, insecure defaults, and unsafe error messages.

adversarial-reviewer skill FAQ

adversarial-reviewer는 초보자에게도 적합한가요?

네. 다만 초보자는 이 skill을 권위 있는 판정자가 아니라 구조화된 비평자로 받아들여야 합니다. 페르소나가 반드시 이슈를 찾아야 하므로, 지적이 강하게 나올 수 있습니다. 코드 리뷰에 익숙하지 않다면 각 발견 사항마다 “why this matters”, “how to verify”, “minimal fix”를 포함해 달라고 요청하세요.

이 skill을 쓰지 않는 편이 좋은 경우는 언제인가요?

adversarial-reviewer를 테스트, 정적 분석, dependency scanning, 규제 대상 시스템의 human approval을 대체하는 용도로 쓰지 마세요. 단순한 스타일 정리, 문서 다듬기, 격려가 필요한 상황에도 잘 맞지 않습니다. 맥락을 충분히 제공하지 않으면 적대적 관점 때문에 위험을 과장할 수 있습니다.

일반 Claude Code Review 프롬프트와 비교하면 어떤가요?

일반 프롬프트는 유연하고 작은 변경에는 충분할 수 있습니다. adversarial-reviewer skill은 production failure mode, maintainability trap, security concern처럼 압박 테스트를 거친 반론이 필요할 때 더 적합합니다. 구조와 역할 분리를 추가해 모델이 작성자의 가정을 그대로 공유하는 일을 줄이는 데 도움이 됩니다.

외부 도구가 필요한가요?

아니요. Repository metadata상 prompt-only이며 외부 의존성이 없습니다. 그래서 설치 부담은 낮지만, agent environment가 diff, 파일, test output, log, command result를 제공하지 않는 한 skill이 runtime behavior를 독립적으로 검사할 수는 없습니다.

adversarial-reviewer skill 개선 방법

출력 탓을 하기 전에 adversarial-reviewer 입력부터 개선하기

약한 결과는 대부분 범위가 모호할 때 나옵니다. “내 branch 리뷰해 줘” 대신 정확한 diff, 변경된 파일, 비즈니스 의도, 실패 비용을 제공하세요. 코드가 인증, 결제, queue, migration, 사용자 데이터를 건드린다면 명시해야 합니다. 운영 맥락이 구체적일수록 리뷰가 일반적인 경고로 흐를 가능성이 줄어듭니다.

심각도와 merge 기준 조정하기

skill의 BLOCK / CONCERNS / CLEAN verdict는 유지하되, 팀에서 각 기준이 무엇을 의미하는지 정의하세요. 예를 들어 “BLOCK means a plausible production incident, security exposure, data corruption, or migration failure. CONCERNS means fix soon or add tests before release.”처럼 정할 수 있습니다. 이렇게 하면 심각도 부풀림 때문에 생기는 논쟁을 줄일 수 있습니다.

false positive를 생산적으로 다루기

각 페르소나는 반드시 이슈를 찾아야 하므로, 일부 발견 사항은 추측에 가까울 수 있습니다. 그렇다고 리뷰 전체를 버리지 마세요. 각 항목에 대해 “What evidence would confirm this?” 또는 “What test would disprove this?”라고 물어보세요. 그러면 적대적 결과를 검증 체크리스트로 바꿀 수 있고, 첫 번째 패스가 지나치게 엄격하더라도 리뷰의 실용성을 유지할 수 있습니다.

수정 후 반복하기

발견 사항을 처리한 뒤에는 좁은 프롬프트로 수정된 diff에 대해 adversarial-reviewer를 다시 실행하세요. “Only review changes made since the last pass and confirm whether previous blockers are resolved.”처럼 요청하면 됩니다. 이렇게 하면 두 번째 패스에서 관련 없는 주제를 다시 열지 않게 되고, 실제 Code Review 사이클에서 skill을 더 실용적으로 쓸 수 있습니다.