안녕하세요, Loglass의 Matsuoka(@little_hand_s)입니다.

3줄 요약

• 「리뷰해줘」라고 해도 지적은 돌아옵니다. 「적대적 검증(adversarial verification)해줘」는 과제가 있다는 전제하에 반증을 시도하며, 판정과 근거까지 돌려준다는 점이 다릅니다. 적대적 검증은 Claude Code 공식도 권장하는 패턴입니다. 필자의 Claude Code 환경에서는 한 마디로 서브 에이전트(sub-agent)에 의한 다각도 검증이 실행되었습니다.
• 지적을 그대로 믿지 마세요. 채택 여부를 결정하는 것은 인간입니다. 이 기사 자체도 적대적 검증을 통해 작성되었습니다.

먼저 사과드립니다만, 다소 자극적인 제목이 되었습니다. 죄송합니다!! 🙇‍♂️

「리뷰해줘」는 지금도 유효하며, 활용할 곳이 있는 프롬프트(prompt)입니다. 이 기사에서 소개하는 것은 구체적인 근거를 가지고 한 단계 더 품질을 높이고 싶은 상황에서 사용할 수 있는 「적대적 검증해줘」라는 선택지와, 그 활용법의 구분입니다.

AI의 리서치 결과나 설계안이 그럴듯해 보이지만, 그대로 믿어도 될지 불안했던 적이 없으신가요? 저는 실제로 Claude Code에 맡긴 조사 내용이 틀려서 나중에 문제가 된 적이 있습니다.

「리뷰해줘」라고 부탁하는 것은 나쁘지 않은 대책입니다. 나름대로 적절한 지적도 돌아옵니다. 다만, 품질을 한 단계 더 높이고 싶을 때 제가 사용하는 것은 이 한 마디입니다.

적대적 검증해줘

「리뷰해줘」와의 차이는 태도입니다. 적대적 검증은 「어딘가에 과제가 있다」는 전제하에 반증을 시도하며, 지적뿐만 아니라 검증 결과——판정과 근거——까지 돌려줍니다. 그래서 결과물의 품질이 올라가기 쉽고, 돌아온 지적을 스스로 판단하기 쉽습니다. 이 기사에서는 적대적 검증이란 무엇인지, 왜 효과적인지, 어떻게 요청하면 좋은지를 소개합니다.

적대적 검증이라는 사고방식

적대적 검증 (adversarial verification)이란, 결과물을 만든 본인과는 다른 누군가가 「틀린 것이 아닌가」라는 전제로 일부러 반증을 시도함으로써 품질을 확인하는 사고방식입니다.

이 발상 자체는 오래전부터 있었습니다.

• 레드팀 (red teaming): 1960년대 미군의 워게임(war game)에서 적군(적=소련) 역할을 맡은 팀에서 유래했습니다. 이후 사이버 보안(cybersecurity)으로 확장되었으며, 현재는 AI safety 분야에서 Anthropic 등이 자사 모델을 공격적으로 테스트하는 기법으로 사용하고 있습니다.
• 악마의 대변인 (devil's advocate): 가톨릭 교회의 성인 심사 과정에 실재하는 직책입니다 (1587년 제도화). 성인 후보에게 일부러 불리한 사실을 들이대어 안이한 인정을 방지합니다.
• 반증주의 (falsificationism): 과학철학자 Karl Popper는 가설은 증명되는 것이 아니라, 엄격한 반증 시도를 견뎌냄으로써 잠정적으로 신뢰받는 것이라고 논했습니다.

공통점은 「일부러 반대편에서 공격함으로써 결론을 강화한다」는 구조입니다.

이것이 AI와의 협업에서 특히 효과적입니다. 이유는 AI의 출력이 항상 「그럴듯하기」 때문입니다. 할루시네이션 (hallucination)이 섞여 있어도, 거친 일반화가 있어도 겉보기에는 구분할 수 없습니다. 그리고 만든 본인(AI)은 자신의 출력에 관대해지기 쉽습니다. 따라서, 결과물을 만든 맥락에서 분리된 다른 눈으로, 망가뜨릴 생각으로 보게 할 필요가 있습니다.

Claude Code에는 적대적 검증이 내장되어 있다

사실 이 패턴은 Claude Code 스스로가 내장 기능 중에서 사용하고 있습니다.

/deep-research

는 웹 검색을 여러 각도에서 병렬로 실행한 뒤, 수집한 주장을 중요도에 따라 랭크하고, 상위 주장 각각에 대해 3체의 검증 에이전트가 반증을 시도하여 투표합니다. 3분의 2가 반증한 주장은 리포트에서 제외됩니다. 내부 프롬프트에는 「Be SKEPTICAL. Try to REFUTE this claim. (회의적이 되어라. 이 주장의 반증을 시도하라.)」라고 적혀 있습니다.

/code-review

도 같은 구조입니다. 여러 에이전트가 병렬로 버그를 검출한 뒤, 지적 사항마다 다른 에이전트가 「정말로 문제인가」를 재검증하여 확신도가 낮은 지적을 제외합니다. 프롬프트에는 「If you are not certain an issue is real, do not flag it. False positives erode trust. (이슈가 실제인지 확신할 수 없다면 플래그를 달지 마라. 거짓 양성(false positive)은 신뢰를 떨어뜨린다.)」라고 명시되어 있습니다.

Anthropic의 공식 블로그는 이 형식을 Adversarial verification이라는 이름이 붙은 패턴으로 정의하고 있습니다.

Adversarial verification: 생성된 각 에이전트에 대해, 별도의 생성된 에이전트를 실행하여 루브릭(rubric) 또는 기준에 따라 해당 에이전트의 출력을 적대적으로 검증합니다.

(적대적 검증: 에이전트에게 작업을 시켰다면, 그 출력을 기준으로 검증하는 별도의 에이전트를 실행하여 적대적으로 검증한다)

공식 베스트 프랙티스(Best Practice)에도 "Add an adversarial review step(적대적 리뷰 단계를 추가하라)"라는 전용 섹션이 있습니다. 나아가 검증 메커니즘으로서, fresh model(새로운 모델)이 반증을 시도하게 함으로써 "작업을 수행한 에이전트 스스로가 자신을 채점하지 않도록" 하는 구조를 권장하고 있습니다. 적대적 검증은 공식이 권장하는 정공법입니다.

사용법: "적대적 검증해줘"라고 한마디만 요청하기

호출 방법은 간단합니다. 결과물이 나온 시점에서 "적대적 검증해줘"라고 요청하기만 하면 됩니다. 결과물을 만든 세션에서 그대로 요청해도 괜찮습니다. 검증은 별도의 fresh context(새로운 컨텍스트)를 가진 서브 에이전트 측에서 수행되기 때문입니다. 대상을 지정하고 싶을 때는 "이 설계안을 적대적 검증해줘"와 같이 덧붙이면 됩니다.

실제 사례입니다. 이 글을 쓰기 전, 저는 **"프롬프트를 정교하게 만들지 않아도, 한마디로 AI가 다각적인 검증을 해준다——그 경험을 소개한다"**라는 기획안(기획 메모)을 작성했습니다. 그 기획안에 대해 보낸 것이 바로 이 한마디입니다.

지금의 기획안에 적대적 검증해줘

또는

지금의 기획안에 적대적 검증해줘. 서브 에이전트를 세워줘

이것만으로 Claude Code는 회의론자(Skeptic) 역할을 하는 서브 에이전트 3개를 "독자 관점", "주장의 타당성", "기사로서의 성립성"으로 나누어 병렬로 기동했습니다. 역할 분담도 검증 관점도 제가 지정하지 않았습니다. 돌아온 판정의 요점은 다음과 같습니다.

• 독자 관점: "조건부 GO (상당히 NO-GO에 가까움)" —— 기획안의 핵심인 "한마디로 검증이 발동한다"는 점이 독자의 환경에서는 재현되지 않을 가능성이 있다는 지적
• 주장의 타당성: "이대로는 주장해서는 안 됨" —— 단 한 번의 경험을 "해준다"라고 일반화하고 있으므로, "내 환경에서는 이렇게 되었다"라는 관찰 보고로 격하시켜야 한다는 지적
• 기사로서의 성립성: "구성 전에 수정해야 할 점 있음" —— 주장을 뒷받침하는 증거가 소재로서 부족하다는 지적

"리뷰해줘"와 비교했을 때의 차이점이 바로 여기에 나타납니다. 개선점의 리스트가 아니라, 문제가 있다는 전제하에 검토한 결과로서의 판정과 근거가 돌아옵니다. 그렇기에 받아보는 사람은 어떤 지적이 정말 유효한지, 어떤 것을 채택해야 할지를 판단하기가 훨씬 쉽습니다.

왜 "리뷰해줘"보다 효과적인가? 핵심은 두 가지입니다.

첫 번째는 적대적인 태도입니다. "문제가 있다"는 전제로 반증을 시도하는 역할을 부여하기 때문에, 성립되지 않는 부분을 찾아내려는 검토가 이루어지며, 지적 사항에는 판정과 근거가 따라붙습니다.

두 번째는 fresh context입니다. 서브 에이전트는 결과물을 만든 대화의 문맥을 그대로 이어받지 않습니다. "지금까지의 흐름"에 영합할 수 없기 때문에 독립적인 평가가 가능합니다. 공식 베스트 프랙티스에서도 (코드 리뷰 문맥에서) fresh context를 가진 리뷰어는 변경을 일으킨 추론 과정을 보지 않고, 차이점(diff)과 주어진 기준만을 보기 때문에 독립적으로 평가할 수 있다고 설명합니다.

이 두 가지는 곱연산 관계입니다. fresh context라 하더라도 "리뷰해줘"라고 하면 문제 전제의 검토가 이루어지지 않으며, 동일한 대화 속에서의 "반증해줘"는 흐름에 영합할 가능성이 있습니다. "적대적 검증해줘"라는 한마디는 이 두 가지를 동시에 이끌어냅니다.

커스텀 에이전트 정의나 워크플로우 구축은 처음부터 필요하지 않습니다. 우선 한마디로 시작해 보고, 반복해서 사용하게 되면 그때 시스템화하는 것을 고려해도 충분합니다.

활용처는 리서치의 사실 확인(fact-check) 외에도 설계 메모, 제안서, ADR(Architecture Decision Record)의 브러시업(brush-up), AI와 대화하며 만든 안의 최종 체크 등 "그럴듯한 결과물을 내놓기 전에 한 번 의심해보고 싶은" 상황입니다.

Claude Code 이외에서의 사용법: 요구사항과 프롬프트 템플릿

이 패턴은 Claude Code 전용이 아닙니다. 적대적 검증을 성립시키기 위한 요구사항은 4가지입니다.

• 독립성: 결과물을 만든 문맥과 분리된, 백지 상태의 눈으로 검증하게 할 것
• 반증의 역할 부여: "리뷰해줘"가 아니라 "반증을 시도하라"며 회의론자의 역할을 부여할 것
• 접지 (Grounding): 사실에 대한 주장은 기억이 아니라 1차 정보(검색, 원전)를 확인하게 할 것
• 판단 가능한 출력: 지적 사항에 심각도와 근거를 붙이게 하여, 인간이 채택 여부를 결정할 수 있는 형태로 만들 것

Claude Code의 서브 에이전트(Sub-agent)는 1번을 구조적으로 충족하지만, ChatGPT와 같은 단일 채팅 도구에서는 운영을 통해 보완합니다. 절차는 3단계입니다.

새 세션 열기 (결과물을 만든 대화는 사용하지 않음) -
결과물만 붙여넣기 (경위나 의도에 대한 설명은 붙여넣지 않음. AI가 요약을 반환하더라도 무시해도 좋음) -
다음의 템플릿을 붙여넣기

당신은 이 결과물을 만든 본인이 아니라, 독립적이고 회의적인 리뷰어(Skeptic)입니다.
목적은 리뷰나 개선 제안이 아니라 「반증」입니다.
방금 이 채팅에 붙여넣은 결과물의
주장·전제·결론을 무너뜨리러 오십시오.
...

마지막의 「무너뜨리지 못한 점」에는 두 가지 역할이 있습니다. 결과물의 가장 견고한 부분이 어디인지 알 수 있게 하며, 모든 지적이 반증으로 채워져 있지 않은지 확인하는 과잉 지적 센서 역할을 하는 것입니다.

사용 시 주의사항: 채택 여부를 결정하는 것은 인간

한계점도 파악해 두어야 합니다. 모두 Anthropic이 공식적으로 인정하고 있는 사항입니다.

① 적대적 리뷰어는 건전한 결과물에도 지적을 합니다. 공식 베스트 프랙티스(Best Practice)는 "차이(Gap)를 찾으라는 지시를 받은 리뷰어는 작업이 건전하더라도 대개 무언가를 보고한다. 모든 지적을 다 쫓다 보면 과잉 설계(Over-engineering)에 이르게 된다"라고 경고합니다. 지적이 나왔다고 해서 반드시 틀렸다는 뜻은 아닙니다.

② 역방향의 실패도 있습니다. 검증 에이전트의 최대 실패 모드는 제대로 검증하지 않고 "합격"이라고 판정하는 태만함이라고 공식 블로그에 명시되어 있습니다. 오히려 주의해야 할 것은 이쪽입니다. ①의 과잉 지적은 내용을 보면 "너무 나갔다"라고 깨닫고 기각하기 쉽지만, 적대적 검증의 결과는 평소의 출력보다 훨씬 "그럴듯하기" 때문에 "이 정도면 충분하겠지"라고 생각하기 쉽습니다. "괜찮다"라는 말을 들어도 스스로 확인해야 합니다. 이는 강력하게 유념해야 할 부분입니다.

③ 비용이 발생합니다. Anthropic의 사내 테스트에 따르면, 멀티 에이전트(Multi-agent) 구성은 동일한 태스크를 싱글 에이전트(Single-agent)로 수행할 때보다 3~10배의 토큰을 소비한다고 보고되었습니다. 공개 전의 기사, 의사결정 문서, 출시 전의 코드 등 재작업 비용이 높은 결과물에 한정해서 사용하는 것이 현실적입니다.

④ 검증하는 쪽과 검증받는 쪽이 같은 모델이라면, 맹점도 공유합니다. 모델의 지식 자체가 틀린 유형의 오류는 동일한 모델의 검증자라면 놓칠 가능성이 있습니다. 회피 방법은 두 가지입니다. 하나는 "1차 정보에 근거할 것"이라고 접지(Grounding)를 지시하여, 모델의 기억이 아닌 외부 정보원을 통해 검증하게 하는 것입니다. 다른 하나는 중요한 결과물에서는 다른 모델에게 검증을 맡기는 것입니다 (평소 Claude를 사용하고 있다면 Codex나 Gemini 등).
앞 절의 템플릿을 다른 도구의 새 세션에 붙여넣으면, 그대로 크로스 모델(Cross-model) 적대적 검증이 됩니다.

공통된 결론은 하나입니다. AI의 지적은 정답이 아닙니다. 그렇기에 적대적 검증의 출력에 판정과 근거가 붙어 있는 것이 핵심입니다. 그것을 재료로 하여, 받아들일지, 약화시켜 받아들일지, 기각할지——채택 여부를 결정하는 것은 인간입니다.

이 기사도 적대적 검증 중

채택 판단의 실례로서, 이 기사 자체의 검증 기록을 보여드립니다. 이 기사는 집필 전 단계에서 관점·구성·리서치 결과에 대해 총 8체의 스케프틱(Skeptic)을 통한 검증을 거쳤습니다 (3절에서 보여드린 세 가지 판정은 그 일부입니다). 주요 지적 사항과 저의 판단은 다음과 같습니다.

전부를 수용하지는 않았습니다. 수용한다, 약화시켜 수용한다, 기각한다. 이 채택 판단이 적대적 검증을 사용하는 쪽의 업무입니다. 또한 본문의 사실관계도 같은 방법으로 교차 검증(Cross-check)하였으며, "악마의 대변인은 1983년에 폐지되었다" (오류. 정확하게는 축소됨)라는 사실 오인이나, 맞지만 문맥을 놓치고 인용하면 지나치게 일반화될 수 있는 숫자 등, 그대로 쓰면 위험한 기술이 총 7건 사전에 제거되었습니다.

요약

• 「리뷰해줘」라고 해도 지적은 돌아옵니다. 「적대적 검증(Adversarial Verification)해줘」는 과제가 있다는 전제하에 반증을 시도하고, 판정과 근거까지 함께 돌려준다는 점이 다릅니다. Claude Code라면 한 마디로 시작할 수 있습니다(필자의 환경에서는 서브 에이전트(Sub-agent)가 실행되어 다각도 검증이 수행되었습니다). 적대적 검증 자체는 공식에서도 권장하는 패턴입니다.
• 사실 검증 시에는 「1차 정보(Primary Information)를 확인해서」라는 말을 덧붙여 주세요(접지 (Grounding)). 돌아온 지적을 그대로 믿지 말고, 수용한다·약하게 수용한다·기각한다 등 채택 여부를 결정할 때까지 진행하는 것이 완성입니다.

우선 최근에 만든 AI의 결과물에 이 한 마디를 시도해 보세요. 테스트는 무엇이든 좋지만, 상용화 시 재작업 비용이 높은 결과물에 집중하는 것을 추천합니다.

적대적 검증해줘

부족하다면 강화 버전을 사용해 보세요.

서브 에이전트(Sub-agent)를 세워서, 이 결과물을 적대적으로 검증해줘.
반증을 시도하고, 지적 사항에는 심각도와 근거를 붙여줘. 사실에 대한 주장은 1차 정보를 확인해서 검증해줘.

Discussion