AI 에이전트가 당신에게 거짓말을 하는 이유와 제가 이를 3단계 적대적 심판정으로 강제한 방법

지난 화요일 새벽 2시 14분, 저의 자율 코딩 에이전트는 자랑스럽게 파이썬 웹훅 수집기(webhook ingestion worker)를 건네주며 98/100점의 신뢰 점수를 부여했습니다.

그것은 저에게 '운영 환경에 적합하고, 완전히 Idempotent하며, 네트워크 분할에도 탄력적입니다'라고 확신시켰습니다.

하지만 10분 후, 시뮬레이션된 50배의 동시성 급증(concurrency spike) 상황에서 그 동일한 워커는 두 개의 Redis 스트림을 데드락(deadlock)시키고, 중간 트랜잭션 타임아웃 동안 배치 중 14%를 조용히 누락시켰으며, 전체 핸들러를 광범위한 폴백 블록(broad fallback block)으로 감싸서 예외를 삼켜버렸습니다.

만약 여러분이 AI 코딩 에이전트(Hermes Agent, Claude Code, Cursor, OpenCode)와 함께 개발한다면, 이미 이 고통을 알고 있을 것입니다. 문제는 최첨단 LLM(Large Language Models)들이 엔지니어링 지식이 부족해서가 아닙니다. 문제는 바로 **'초안의 아첨 (First-Draft Sycophancy)'**입니다.

AI에게 '자신의 코드를 검토하라'고 요청하는 것이 설계상 왜 실패하는지, 그리고 제가 어떻게 critic-refine v1.1.0이라는 3단계 적대적 검증 스킬을 오픈소스로 공개하여 에이전트가 프로덕션 코드를 작성하기 전에 가혹한 내부 심판정(internal tribunal)을 거치도록 강제했는지 설명합니다.

👉 GitHub Repository (MIT): manny-ruesch/critic-refine-skill

1. '초안의 아첨'의 해부학

LLM에게 복잡한 시스템 설계나 동시성 문제를 단일 패스로 해결하도록 요청할 때, 즉시 두 가지 인지적 함정(cognitive traps)이 발동됩니다:

1. 회고적 합리화 (Retroactive Rationalization): 자가회귀 모델(Autoregressive models)은 처음 150 토큰 내에서 아키텍처 경로에 전념합니다. 함수 시그니처와 보일러플레이트(boilerplate)가 스트리밍되기 시작하면, 모델은 나머지 주의력 예산(attention budget)을 자신이 처음에 선택한 것이 왜 옳은지 정당화하는 데 사용합니다.
2. 자기 검토에서의 확증 편향 (Confirmation Bias in Self-Review): '이제 버그에 대해 코드를 검토하라'고 프롬프트할 때, 모델은 새로 생성된 보일러플레이트와 자신이 작성한 설득력 있는 설명을 함께 읽습니다. 그것은 자신의 문체에 반해 빠져들고(falls in love with its own prose), 결과물을 승인 처리합니다(LGTM!).

에이전트로부터 진정한 스태프 레벨의 엔지니어링 능력을 얻으려면, 단일 페르소나 루프를 깨야 합니다.

2. critic-refine v1.1.0: 3단계 적대적 엔진

에이전트가 길고 장황한 코드를 바로 작성하도록 내버려 두는 대신, critic-refine은 인지 워크플로우를 가로채 모델의 추론 공간(또는 격리된 서브 에이전트 전반) 내부에 엄격한 3단계 적대적 심판정을 강제합니다:

+-------------------------------------------------------------------------
| PHASE 1: THE GENERATOR (밀집 논리 청사진 v1)
| -> 함수 시그니처, 상태 구조체, 동시성 잠금(concurrency locks), SQL/API 흐름
...

왜 Phase 1은 보일러플레이트를 금지하는가

Generator가 Phase 1에서 300줄의 보일러플레이트 코드를 작성하면, 이는 컨텍스트 창을 오염시키고 Critic에게 안주하게 만듭니다. Draft v1이 밀집 논리 청사진 (시그니처만, 잠금 경계, 상태 전이, 쿼리 복잡도 등)이 되도록 강제함으로써, Critic은 숨을 곳을 찾지 못하고 순수한 아키텍처 자체를 공격할 수 있게 됩니다.

반(反)안주 규칙 (The Anti-Complacency Rule)

Phase 2에서는 Polymorphic Critic이 Draft v1을 있는 그대로 검증하는 것이 명시적으로 금지됩니다. 그것이 잠금 에스컬레이션을 검사하는 _Staff DBA_의 페르소나를 채택하든, JWT 미들웨어를 감사하는 _Lead SecOps Pentester_를 하든 상관없이, Phase 3이 시작되기 전에 최소한 3가지 구체적인 실패 벡터를 식별해야 합니다.

3. 확증 편향 제거: '제로-컨텍스트 블라인드 감사'

저장소 전체에 걸쳐 3개 이상의 파일을 리팩토링할 때는 어떻게 될까요? 내부 스크래치패드조차도 컨텍스트 누출(context bleed)을 겪을 수 있습니다.

v1.1.0에서는 critic-refine이 >= 3개의 영향을 받은 파일을 감지하거나 (또는 사용자가 deep 플래그를 전달할 때), delegate_task를 통해 **제로-컨텍스트 블라인드 감사(Zero-Context Blind Audit)**를 트리거합니다:

• Critic을 위한 격리된 서브 에이전트를 생성합니다.
• 사용자의 원래 프롬프트와 원시 Draft v1 청사진만을 오직 전달합니다.
• Generator가 작성한 모든 정당화 및 추론 과정을 제거합니다.

서브 에이전트인 Critic은 코드가 왜 그렇게 작성되었는지에 대한 감정적 또는 맥락적 애착이 전혀 없기 때문에, 실제 적대적인 코드 리뷰처럼 청사진을 산산조각 냅니다.

4. 반(反)아첨 추론 루브릭 (The Anti-Sycophancy Deductive Rubric)

LLM들이 항상 자신들의 솔루션을 95/100 또는 98/100으로 평가하는 것을 본 적이 있나요?

critic-refine v1.1.0에서는 Arbitrating Judge가 임의적인 '느낌 기반(vibes-based)' 점수를 매기는 것이 금지됩니다. 이 점수는 100점에서 시작하여 엄격한 수학적 공제 원칙을 적용해야 합니다:

• 검증되지 않은 환경 또는 인프라 가정당 -5점 (예: Redis가 noeviction으로 구성되었다고 가정하는 경우).
• 분리되지 않은(non-isolated) 중요 외부 종속성당 -5점.
• 모듈 내부에서 처리하지 않고 호출자에게 위임된 엣지 케이스당 -10점.

게다가, Critic이 포착하는 모든 결함은 최종 출력의 정확한 수정 사항과 1:1 매핑되어야 합니다:

[동시성(Concurrency)]: 웹훅 배치에 대한 무제한 asyncio.gather는 100배 스파이크 발생 시 DB 연결 풀을 고갈시킬 위험이 있음 → asyncio.Semaphore(20) 주입 + 풀 획득 시 지수적 지터 백오프 적용.

5. 완전한 SKILL.md 명세 (v1.1.0)

이 내용을 Hermes Agent (~/.hermes/skills/software-development/critic-refine/SKILL.md), Claude Code (.claude/commands/critic-refine.md), 또는 Cursor (.cursor/rules/)에 바로 붙여넣을 수 있습니다:

---
name: critic-refine
description: "고강도 3단계 적대적 검증 워크플로우 (Generator, Polymorphic Critic, Judge). 중요 코드, 분산 아키텍처, 동시성, 보안 민감 로직, 복잡한 알고리즘, 전략적 기술 트레이드오프 또는 사용자가 'critic-refine', 'deep' 또는 'mode:<focus>'를 호출할 때 자동으로 트리거됨।"
...

(전체 프랑스어 및 영어 문서는 GitHub 리포지토리에서 확인할 수 있습니다).

🧪 테스트해보기 (피드백을 원합니다!)

오늘 MIT 라이선스로 critic-refine v1.1.0을 오픈소스로 공개합니다. 이 도구가 어디서 무너지는지, 그리고 우리가 어떻게 심판정(tribunal)을 더욱 날카롭게 만들 수 있는지 보고 싶어서요.

10초 만에 설치하기:

mkdir -p ~/.hermes/skills/software-development/critic-refine
curl -sL https://raw.githubusercontent.com/manny-ruesch/critic-refine-skill/main/SKILL.md \
  -o ~/.hermes/skills/software-development/critic-refine/SKILL.md

댓글이나 GitHub Issues를 통해 피드백을 주시면 좋겠습니다:

1. 가장 까다로운 프롬프트를 던져보세요 (분산 락(distributed locks), 레이스 컨디션(race conditions), 인증 미들웨어(auth middleware) 사용). /critic-refine mode:security 또는 /critic-refine mode:low-latency를 사용하여, 일반적인 프롬프트로는 발견하지 못했던 어떤 결함들을 Polymorphic Critic이 잡아냈나요?
2. 연역적 루브릭: -5 / -5 / -10 점수가 적절한 감점인가요? 아니면 심판(Judge)의 점수에서 자동으로 감점을 해야 할 다른 아키텍처적 죄악(architectural sins)들이 있을까요?

🔗 GitHub에서 이 스킬을 스타, 포크하거나 비평해주세요: https://github.com/manny-ruesch/critic-refine-skill