심문 (The Grilling)

Part 1에서 저는 시장에 나와 있는 모든 명세 기반 (spec-driven) AI 프레임워크 — 제 조사에 따르면 16개 모두 — 가 동일한 구조적 사각지대를 가지고 있다고 주장했습니다. 이들은 모두 구현 (implementation) 을 명세 (spec) 와 대조하여 확인합니다. 하지만 그 어떤 것도 명세가 작성되기 전에 공격 (attack) 에 대해 명세를 검증하지는 않습니다.

Part 2는 운영 측면의 심층 분석입니다.

누락된 단계를 실제로 구축할 때 그 모습은 어떠한가?
어떻게 실행되는가?
에이전트 (agents), 프롬프트 (prompts), 종료 조건 (termination conditions), 산출물 (artifacts) 은 무엇인가?
언제 이것을 사용하지 말아야 하는가?

이 파트는 여러분이 Part 1을 읽었거나, 적어도 명세가 복음이 되기 전에 심판을 받아야 한다는 전제에 동의한다는 것을 가정합니다.

왜 “멀티 에이전트 토론 (multi-agent debate)”만으로는 충분하지 않은가

A few 연구 논문들과 몇몇 프레임워크들은 멀티 에이전트 토론 (multi-agent debate) 이라고 부르는 것을 가지고 있습니다. 두 에이전트가 논쟁하고, 세 번째 에이전트가 이를 종합합니다. 이것은 실제 연구를 바탕으로 한 실제 기술이며, 단일 에이전트 추론 (single-agent reasoning) 에 비해 의미 있는 개선입니다.

그것은 심문 (Grilling) 이 아닙니다.

차이점은 중요하며, 정확하게 짚고 넘어갈 가치가 있습니다.

첫 번째 차이점은 근거 설정 (grounding) 입니다.

현재 프레임워크들의 대부분의 토론 설정은 프롬프트 (prompt) 에 들어 있는 내용에 따라 작동합니다. 이들은 코드베이스 (codebase), 기존 테스트 (existing tests), 과거의 실패 사례 (past failures), 적용 가능한 제약 조건 (applicable constraints) 을 먼저 조사하지 않습니다. 그 결과는 두 LLM이 서로에게 정중하게 환각 (hallucination) 을 일으키는 것입니다.

옹호자 (The Advocate) 는 실제 시스템에 적용되지 않는 반론을 만들어내고, 제안자 (the Proposer) 는 설령 적중하더라도 중요하지 않을 공격에 대해 입장을 방어합니다. 두 에이전트 앞에 정찰 보고서 (a Recon Dossier) 가 없다면, 그 토론은 연극에 불과합니다. 그것은 결정이 아닌 대화를 만들어낼 뿐입니다.

심문 (Grilling) 은 그라운드 트루스 (ground truth) 가 확립되고 검증될 때까지 시작하기를 거부합니다. 이것은 스타일의 선택이 아닙니다. 공격이 무게를 갖게 만드는 유일한 방법입니다.

두 번째 차이점은 최적화 목표 (optimization target) 입니다.

표준 토론 (Standard debate)은 선택된 입장의 최선의 버전을 목표로 최적화합니다. 두 에이전트가 서로 반대되는 견해로 시작하면, 합성기 (synthesizer)가 각 입장에서 가장 강력한 부분을 추출합니다. 이는 당신이 이미 무언가를 하기로 결정했고, 그 최선의 방법을 찾으려 할 때 진정으로 유용합니다.

심문 (Grilling)은 전혀 다른 것, 즉 해당 입장을 유지해야 하는지 여부를 목표로 최적화합니다. 제안자 (Proposer)는 단순히 할당되었기 때문에 입장을 방어하는 것이 아닙니다. 그들은 실제로 옳다고 생각하는 해결책을 제안하며, **옹호자 (Advocate)**는 그 제안을 해체하려고 시도합니다.

심문의 정당한 결과물은 아이디어를 완전히 폐기하는 것입니다. 표준 토론의 정당한 결과물이 양측 모두 논점이 없다가 되는 경우는 드뭅니다.

세 번째 차이점은 중단 조건 (stopping condition) 입니다.

그리고 이것이 가장 중요한 차이점일 수 있습니다. 표준 토론은 양측이 각자의 논거를 제시했을 때 종료됩니다. 일반적으로 정해진 라운드 수가 지나거나, 오케스트레이터 (orchestrator)가 논의가 충분히 성숙했다고 판단할 때 종료됩니다. 이는 절차적인 종료이지, 실질적인 종료가 아닙니다. 토론은 질문이 해결되었기 때문이 아니라, 일정이 종료되었다고 말하기 때문에 멈추는 것입니다.

심문은 구조적인 중단 조건을 가집니다: 두 가지 상반된 압력 사이의 평형 상태입니다. 공격자 (attacker)가 더 이상 내세울 것이 없고, 돈 (Don)이 더 이상 내세울 것이 없을 때, 즉 두 압력이 동시에 소진되었을 때입니다. 이 조건이 충족될 때까지 라운드는 계속됩니다 (최대 상한선까지). 이 조건이 충족되면 더 이상의 라운드는 진행되지 않습니다. 더 이상의 라운드는 아무런 가치도 더하지 않기 때문입니다.

중단 조건이 게임의 전부입니다.

만약 당신의 토론이 **'논쟁이 끝났다'**는 이유로 멈춘다면, 당신은 똥을 닦고 있는 것과 같습니다. 에이전트들이 수렴한 내용이 옳은지 여부와 상관없이, 그들이 수렴한 결과물을 가지고 종료하게 되기 때문입니다.

만약 토론이 **'새로운 유효한 반론이 없고, 남은 우려 사항도 없다'**는 이유로 멈춘다면, 당신은 더 강력한 것을 얻게 됩니다. 즉, 공격을 견뎌낸 판결과 살아남은 반론들이 명시적으로 기록된 결과물입니다.

다중 에이전트 토론 (Multi-agent debate)은 유용한 도구입니다. 다만 다른 문제를 해결하는, 다른 종류의 도구일 뿐입니다.

심문 (Grilling) 세션의 구조

심문 (Grilling)은 Heist Pipeline의 2단계 (Phase 2)로 자리 잡고 있습니다. 이것은 단순한 프롬프트도 아니고 독립적인 도구도 아닙니다. 이것은 앞뒤로 엄격한 게이트 (hard gates)가 존재하는 하나의 단계입니다 (정찰 (Reconnaissance)이 완료되어 정찰 보고서 (Recon Dossier)를 생성해야 하며, 어떤 것이 회담 (Sit-Down)으로 넘어가기 전에 돈 (Don, 사용자)이 판결에 서명해야 합니다).

이 프로세스는 구조화된 심문처럼 진행됩니다. 세 명의 하위 에이전트 (subagents)가 특정 역할을 수행하며, 돈 (Don, 사용자)은 매 라운드에 참여하고, 라운드는 정해진 순서를 따릅니다.

**제안자 (The Proposer)**가 시작합니다. 제안자는 1단계에서 검증된 결과물인 정찰 보고서 (Recon Dossier)를 읽고 아키텍처 (architecture), 파일 변경 사항, 식별된 리스크, 예상 동작과 같은 해결책을 제안합니다.

제안자의 임무는 아이디어의 가능한 가장 강력한 버전을 테이블 위에 올려놓는 것입니다. 가장 안전한 버전도, 가장 외교적인 버전도 아닙니다. 가장 강력한 버전이어야 합니다. 만약 아이디어가 나쁘다면, 중얼거리며 죽는 것이 아니라 격렬하게 싸우다 죽게 만들어야 합니다.

**악마의 변호인 (The Devil’s Advocate)**이 공격합니다. 아키텍처 결함, 보안 취약점, 컨스티튜션 (Constitution) 위반, 성능 저하 (performance regressions), 확장성 한계 (scalability ceilings), 그리고 제안자가 생각하지 못한 엣지 케이스 (edge cases) 등을 공격합니다. 악마의 변호인의 임무는 — 이 점이 매우 중요합니다 — 실패 모드 (failure mode)를 찾아내는 것입니다.

예의를 차리는 것이 아닙니다.
개선 사항을 제안하는 것도 아닙니다.
공격하는 것입니다.

만약 제안자가 "이것을 Redis에 캐싱하겠습니다"라고 말한다면, 악마의 변호인은 다음과 같이 말합니다:

Redis가 다운되면 어떻게 됩니까?
캐시가 오염 (poisoned)되면 어떻게 됩니까?
실제 캐시 히트율 (cache hit rate)을 측정했습니까, 아니면 추측하는 것입니까?

잘못된 공격은 제안자의 답변에 의해 걸러집니다.
좋은 공격은 수정을 강제합니다.

돈 (The Don) — 즉 사용자, 당신 — 은 매 라운드마다 의견을 제시합니다. 한 번에 하나의 질문만 합니다. 절대 묶어서 질문하지 마십시오. 이 규칙은 들리는 것보다 훨씬 더 중요합니다.

만약 Don이 한 번에 세 가지 질문을 던진다면, 에이전트(agent)는 쉬운 질문에는 완전히 답하고, 중간 난이도의 질문에는 부분적으로 답하며, 어려운 질문은 조용히 건너뛸 것입니다. 단 하나의 질문만이 실제 답변을 강제합니다. Don의 질문은 보통 심문 (Grilling) 전체에서 가장 가치 있습니다. 왜냐하면 Don은 에이전트들이 알지 못하는 맥락, 즉 팀에 관한 것, 비즈니스에 관한 것, 정치에 관한 것, 그리고 코드베이스 (codebase)에 포함되지 않은 이전에 시도되었던 것들에 대해 알고 있기 때문입니다.

The Synthesizer가 각 라운드를 마무리합니다. 이는 유효한 공격 (attacks)과 Don의 피드백을 통합하여 수정된 솔루션 (solution)을 생성합니다. 원래의 것에 대한 방어가 아니라, 수정 (revision)입니다. 만약 해당 라운드에서 유효한 내용이 나오지 않았다면 수정 사항은 작습니다. 만약 강력한 타격이 있었다면 수정 사항은 구조적 (structural)입니다. 때때로 수정 사항은 이 아이디어를 완전히 폐기하고 다른 접근 방식을 제안하는 것이 될 수도 있으며, 이는 정당한 결과입니다.

그러면 다음 라운드가 시작됩니다.

실제 라운드는 어떤 모습인가

이론은 저렴합니다.

여기 실제 1라운드 사례가 있습니다. 길이를 위해 약간 편집되었으며, 브라우저 기반 Tetris 게임에 로컬 하이스코어 리더보드를 추가하는 작은 기능에 대한 심문 (Grilling) 세션에서 가져온 것입니다.

작업은 사소해 보입니다. 공격을 받을 때 "사소함 (trivial)"이 얼마나 빠르게 무너지는지 지켜보십시오.

The Proposer가 시작합니다. 이는 Recon Dossier를 읽습니다. 3계층의 순수 상태 머신 (pure state machine), 로직 계층 (logic layer) 내 DOM 제로, 261개의 통과된 테스트, 그리고 첫 번째 계율이 게임 로직은 DOM 의존성이 전혀 없어야 한다인 헌법을 확인한 후, 솔루션을 제시합니다:

상태 머신 (state machine)에 name-entry 상태를 추가합니다. 입력된 이니셜을 state.nameEntry = { buffer: '', maxLen: 3 }에 저장합니다. state.events[]에서 gameOver 이벤트를 읽어 게임 종료를 감지한 다음, 키 입력을 버퍼 (buffer)로 라우팅합니다. 리더보드 (leaderboard)는 기존 settings.js를 미러링하여 DOM <div> 오버레이로 렌더링합니다. 순수 함수인 isTopTen(score, entries)가 자격 여부를 결정합니다.

겉보기에는 합리적입니다. 기존 패턴을 반영하고 있으며, 실제 파일명을 명시하고 있습니다. 이것은 가장 안전한 버전이 아니라, 가장 강력한 (strongest) 버전입니다. 제안자 (Proposer)가 마땅히 전달해야 할 결과물이죠.

악마의 변호인 (The Devil’s Advocate)이 공격합니다. 개선 사항을 제안하는 것이 아닙니다. 그는 Dossier를 탄약 삼아 실패 모드 (failure modes)를 파고듭니다:

공격 1 — state.nameEntry는 헌법 제1계율을 위반합니다. 이름 버퍼는 순수한 UI 상호작용 상태입니다. 이는 점수 계산, 물리 엔진, 또는 조각의 움직임에 아무런 영향을 미치지 않습니다. 이를 state.js에 넣는 것은 전체 테스트 스위트 (test suite)가 DOM으로부터 독립되어 있어야 한다고 의존하는 로직 레이어 (logic layer)를 오염시킵니다. 이는 로컬 오케스트레이션 상태 (local orchestration state)로서 main.js에 속해야 합니다. 증거: state.js는 로직 레이어이며, 261개의 테스트가 이를 헤드리스 (headless) 방식으로 임포트(import)합니다.

공격 2 — state.events[]는 잘못된 트리거입니다. Dossier는 해당 배열을 “렌더러/오디오 결합 (renderer/audio coupling)을 위해” 존재한다고 설명합니다. 이것이 프레임당 비워지는지(drained) 아니면 지속되는지 명시되어 있지 않습니다. 만약 렌더러나 오디오 핸들러가 main.js가 읽기 전에 이를 소비해 버린다면, 게임 종료 트리거를 조용히 놓치게 됩니다. 이는 발생하기를 기다리는 레이스 컨디션 (race condition)입니다. 증거: Dossier — “렌더러/오디오 결합을 위한 이벤트 배열,” 비워지는 의미론(drain semantics)은 명시되지 않음.

공격 3 — 키 억제 (key suppression)가 명시되지 않았습니다. S (설정), M (음소거), P (일시정지), R (재시작), L (리더보드)는 모두 main.js에서 라이브 바인딩 (live bindings)을 가집니다. “S”가 포함된 이름을 입력하면 입력 도중에 설정 패널이 열려버립니다. 제안자는 이를 위험 요소로 지적했지만, 아무런 메커니즘도 제공하지 않았습니다. 증거: 기존 main.js의 키 핸들러 (key handlers).

또한 제안자(Proposer)가 전혀 언급하지 않은 두 번째 발견 사항이 있습니다: localStorage에서 DOM으로 직접 렌더링되는 이름은 innerHTML 대신 textContent를 사용하지 않는 한 저장형 XSS (Stored XSS) 벡터가 됩니다.

판결: CHALLENGE (도전). 아이디어는 타당합니다. 하지만 누군가 명세(spec)를 작성하기 전에 반드시 메워야 할 세 가지 구멍이 있는 솔루션입니다.

Don의 의견 개입 — 한 번에 하나씩 질문하며, 결코 묶어서 묻지 않습니다.

공격에 동의합니까? → 전적으로 동의함.

악마의 대변인(Devil’s Advocate)이 놓친 것이 있습니까? → 놓친 것 없음.

종합(synthesis) 전 제안의 어떤 부분을 수정하고 싶습니까? → 수정 사항 없음.

세 가지 강제된 답변.

이 특정 세션은 평형 상태에 도달하기 전, 두 번째 라운드를 진행했습니다. Devil’s Advocate(악마의 변호인)가 여섯 번의 추가 공격을 가했습니다(버퍼에 대한 최대 길이 제한 없음, 순수 대 DOM 모듈 분리, 로드 시 JSON schema 검증 포함). 모든 거부된 대안과 수용된 리스크를 포함한 전체 판결은 계약(Contract)의 근거로서 Sit-Down(정식 회의)으로 곧장 이어졌습니다.

라운드에 대한 엄격한 규칙.

최소 2 라운드 - 단 한 번의 과정으로는 아이디어를 심문(grill)할 수 없습니다. 첫 번째 공격은 항상 피상적이기 때문입니다. 기본 최대 5 라운드 - 대부분의 아이디어는 이 단계에서 살아남거나, 혹은 다른 무언가로 변형됨으로써 해결됩니다.