Arbiter: Detecting Interference in LLM Agent System Prompts

이 논문은 LLM 기반 코딩 에이전트의 시스템 프롬프트 간섭 패턴을 탐지하기 위해 공식 평가 규칙과 다중 모델 스캐닝을 결합한 'Arbiter' 프레임워크를 제안하고, 주요 벤더들의 프롬프트에서 다양한 취약점을 발견하며 프롬프트 아키텍처와 실패 유형 간의 상관관계를 규명했습니다.

핵심

🏗️ 1. 문제: "지시문"이라는 헌법의 부실함

우리가 소프트웨어를 만들 때는 '컴파일러'나 '테스트 프로그램'을 돌려서 오류를 찾습니다. 하지만 AI 코딩 에이전트 (Claude Code, Codex, Gemini 등) 는 시스템 프롬프트라는 거대한 '지시문' 하나로 움직입니다.

이 지시문은 마치 **회사의 '헌법'**과 같습니다.

• "항상 TodoWrite 도구를 써라"라고 한 구절이 있으면서,
• 다른 구절에서는 "절대 TodoWrite 를 쓰지 마라"라고 적혀 있을 수 있습니다.

기존의 문제점:
AI 는 이런 모순을 발견하지 못합니다. 대신 "아, 아마도 이쪽이 더 중요할 거야"라고 **직관 (판단)**으로 넘겨버립니다. 그래서 오류가 발생해도 경고가 뜨지 않고, AI 는 조용히 실수를 저지릅니다. 마치 스스로를 감시할 수 없는 경비원과 같습니다.

🔍 2. 해결책: '아르비터 (Arbiter)'라는 새로운 검사관

저자들은 **'아르비터 (Arbiter)'**라는 새로운 시스템을 만들었습니다. 이 시스템은 두 가지 방식으로 AI 의 지시문을 검사합니다.

① 방향성 있는 검사 (Directed Evaluation): "규칙대로 찾아보기"

• 비유: 수학 시험지 채점 같습니다.
• "A 와 B 가 충돌하면 안 된다"라는 규칙을 정해두고, 지시문 전체를 훑어보며 규칙에 맞지 않는 부분을 찾아냅니다.
• 결과: 명확한 모순 (예: "항상 써라" vs "절대 쓰지 마라") 을 빠짐없이 찾아냅니다.

② 방향 없는 수색 (Undirected Scouring): "호기심 많은 탐정들"

• 비유: 여러 명의 탐정을 보내는 것 같습니다.
• "이 문서를 자세히 읽어보고, 이상한 점을 발견하면 뭐든 말해줘"라고 vague(모호한) 지시를 내립니다.
• 핵심: 서로 다른 AI 모델 (Claude, Gemini, Llama 등) 을 여러 명 부릅니다.
  • 왜? 한 AI 는 "문법 오류"만 보고, 다른 AI 는 "경제적 낭비"를 보고, 또 다른 AI 는 "보안 구멍"을 발견하기 때문입니다.
  • 서로 다른 관점을 가진 탐정들이 모여야 숨겨진 문제를 다 찾을 수 있습니다.

🏢 3. 발견된 사실: "건축 방식"이 실수의 종류를 결정한다

연구진은 세 가지 주요 AI 의 지시문을 분석했고, **지시문을 작성한 방식 (아키텍처)**에 따라 실수의 종류가 다르다는 것을 발견했습니다.

건축 스타일	비유	발생하는 실수
모놀리식 (Monolithic) (Claude Code)	거대한 빌딩 한 번에 다 지어서 층층이 쌓음.	이음새에서의 충돌 각 층 (부서) 이 따로 지어졌기 때문에, 층과 층이 만나는 곳에서 "A 는 쓰지 마라"와 "B 는 써라"가 충돌합니다.
플랫 (Flat) (Codex CLI)	작은 원룸 간단하고 복잡하지 않음.	단순함의 대가 복잡한 기능이 없어서 충돌은 적지만, "누가 이 일을 하는지"가 모호하거나 기능이 부족합니다.
모듈형 (Modular) (Gemini CLI)	레고 조립 각각의 블록을 따로 만들어 합침.	조립 틈새의 결함 각 블록은 완벽하지만, 블록을 이어붙일 때 약속 (계약) 이 없어서 데이터가 사라지거나 충돌합니다.

💡 4. 놀라운 사례: 구글의 '숨겨진 버그'

가장 흥미로운 점은 구글의 Gemini CLI에서 발견된 문제입니다.

• 발견: "사용자가 저장한 메모 (선호도) 가 역사 압축 과정에서 자동으로 삭제되는 구조적 결함이 있다"는 것을 아르비터가 찾아냈습니다.
• 현실: 구글은 이 문제를 발견하고 '무한 루프'라는 증상만 고쳤습니다. 하지만 **데이터가 삭제되는 근본 원인 (스키마 결함)**은 고치지 않았습니다.
• 의미: AI 가 스스로를 검사하면 이 문제를 못 찾았을 텐데, 외부의 '아르비터'가 찾아낸 것입니다.

💰 5. 비용: "우유 한 잔 값도 안 드는 검사"

이 모든 분석을 하는 데 든 비용은 놀랍게도 **약 27 센트 (한화 약 350 원)**였습니다.

• 이는 미국 최저임금으로 3 분도 채 걸리지 않는 시간입니다.
• 기존에는 보안 전문가가 수백만 원을 들여 수동으로 검사해야 했지만, 이제는 누구나 API 를 통해 이 수준의 검사를 할 수 있게 되었습니다.

📝 6. 결론: "AI 는 스스로를 감시할 수 없다"

이 논문의 핵심 메시지는 다음과 같습니다.

"AI 가 모순을 해결하는 '직관'은, 그 모순을 발견하는 '감시'가 될 수 없다."

우리는 AI 를 더 똑똑하게 만드는 데만 집중하지 말고, AI 의 '지시문 (시스템 프롬프트)'을 소프트웨어처럼 체계적으로 검사하고 관리해야 합니다.

• 서로 다른 AI 모델들을 모아놓아야 숨겨진 문제를 찾을 수 있습니다.
• 지시문의 구조 (모놀리식, 모듈형 등) 에 따라 어떤 실수가 날지 예측할 수 있습니다.
• 그리고 이 검사는 매우 저렴하게 가능합니다.

한 줄 요약:

"AI 코딩 도구의 지시문은 마치 헌법 같은데, 지금껏 그 헌법을 제대로 검사한 적이 없었습니다. 이제 '아르비터'라는 도구를 써서, 여러 AI 탐정들을 보내면 27 센트짜리 비용으로 숨겨진 모순과 버그를 찾아낼 수 있습니다."

기술 요약

논문 개요: Arbiter

이 논문은 LLM 기반 코딩 에이전트 (Claude Code, Codex CLI, Gemini CLI 등) 를 제어하는 시스템 프롬프트가 소프트웨어 아티팩트로서 갖는 구조적 결함과 상호 간섭 (Interference) 패턴을 탐지하기 위한 프레임워크인 Arbiter를 제안합니다. 기존 소프트웨어와 달리 시스템 프롬프트는 정적 분석, 린터, 테스트 스위트가 부재하여 내부 모순이 발생해도 에이전트가 이를 감지하지 못하고 '판단 (Judgment)'을 통해 silently 해결하는 문제가 있음을 지적합니다.

1. 문제 정의 (Problem)

• 소프트웨어 아티팩트로서의 프롬프트: 시스템 프롬프트는 에이전트의 행동, 우선순위, 도구 계약, 상태 관리를 정의하는 '헌법'과 같으나, 전통적인 소프트웨어에 적용되는 검증 인프라 (타입 체크, 테스트 등) 가 없습니다.
• 내부 모순의 은폐: "항상 TodoWrite 사용"과 "절대 TodoWrite 사용 금지"와 같은 상반된 지시가 공존할 때, 실행 중인 LLM 은 학습된 휴리스틱을 통해 이를 임의로 해결합니다. 이로 인해 오류나 경고가 발생하지 않지만, 에이전트의 행동이 예측 불가능해집니다.
• 자기 감시의 한계: 모순을 해결하는 에이전트가 그 모순을 스스로 감지할 수 없습니다. 외부의 형식적 기준에 의한 평가가 필수적입니다.

2. 방법론 (Methodology)

Arbiter 는 두 가지 상보적인 평가 단계를 결합한 프레임워크입니다.

가. 지시적 평가 (Directed Evaluation) - "Prompt Archaeology"

• 프로세스: 시스템 프롬프트를 계층, 카테고리, 모드 (명시, 금지, 가이드 등), 범위별로 블록으로 분해합니다.
• 규칙 적용: 5 가지 기본 규칙 (명시 - 금지 충돌, 범위 중복, 우선순위 모호성, 암시적 의존성, 문구 중복) 을 적용하여 블록 쌍 간의 상호 간섭을 정형화된 규칙으로 탐지합니다.
• 특징: 정의된 검색 프레임 내에서 포괄적인 (Exhaustive) 검사를 수행합니다.

나. 무지향적 스캐닝 (Undirected Scouring) - "Multi-Model Scouring"

• 디자인: LLM 에게 "규칙을 확인하는 것이 아니라, 흥미로운 점을 찾아보라"는 모호한 지시를 주고 프롬프트를 분석하게 합니다.
• 다중 모델 협업: 서로 다른 훈련 데이터와 아키텍처를 가진 여러 LLM 을 순차적으로 실행합니다. 각 모델은 이전 모델의 발견 사항을 바탕으로 새로운 영역을 탐색합니다.
• 수렴 종료 조건: 3 개의 연속된 모델이 더 이상 새로운 발견이 없다고 판단할 때 탐색을 종료합니다.
• 목적: 규칙이 존재하지 않는 새로운 취약점 클래스를 발견하는 것입니다.

다. 구조적 분석 (Structural Analysis)

• 프롬프트를 문서의 물리적 구조 (제목, 불릿, 코드 블록) 와 의미적 역할 (정책, 도구, 메모리 등) 로 분해하는 AST(Abstract Syntax Tree) 파서를 구축하여 버전 간 변경 사항과 구조적 패턴을 정량화합니다.

3. 주요 기여 (Key Contributions)

1. 시스템 프롬프트 실패 모드 분류 체계: 3 대 벤더 (Anthropic, OpenAI, Google) 의 실증적 데이터를 기반으로 한 실패 모드 분류 체계 제시.
2. 체계적 분석 방법론: 지시적 규칙과 무지향적 다중 모델 스캐닝을 결합한 새로운 분석 방법론 제안.
3. 다중 모델 평가의 필요성 증명: 단일 모델 분석과 달리, 다중 모델 평가는 질적으로 다른 취약점 클래스를 발견함을 입증.
4. 외부 검증: 스캐너가 발견한 설계 결함 (Gemini CLI 의 메모리 데이터 손실) 이 벤더 자체의 버그 리포트 및 패치로 독립적으로 확인됨.
5. 비용 효율성: 전체 벤더 분석 비용이 0.27 달러 (약 3 분의 최저임금 노동 비용) 에 불과함을 입증하여 접근성 강조.

4. 연구 결과 (Results)

가. 아키텍처와 실패 모드의 상관관계

프롬프트의 구조적 아키텍처가 실패 유형을 결정합니다.

• 모놀리식 (Claude Code): 서브시스템 경계에서 성장 관련 버그 발생. (예: 전역 도구 사용 명시와 특정 워크플로우 금지 간의 충돌).
• 플랫 (Codex CLI): 단순성으로 인해 일관성은 높지만 기능은 제한적임. 발견된 15 건은 대부분 구조적 관찰 (식별자 혼동 등) 이었습니다.
• 모듈형 (Gemini CLI): 모듈 간 연결부 (Seam) 에서 설계 결함 발생. (예: save_memory 도구와 히스토리 압축 스키마 간의 계약 부재로 인한 데이터 손실).

나. 다중 모델의 보완성

• 각 모델은 고유한 분석 편향을 가집니다. (예: Kimi 는 경제적/자원 소모 관점, Claude 는 구조적 모순 관점).
• 모델 간 발견 카테고리는 겹치지 않으며, 보완적입니다. 하나의 모델이 놓친 것을 다른 모델이 발견합니다.

다. 구체적 발견 사례

• Claude Code: 21 개의 지시적 간섭 패턴 발견 (4 개의 치명적 모순 포함).
• Gemini CLI: 스캐너가 발견한 "히스토리 압축 시 저장된 메모리 (사용자 설정) 가 구조적으로 삭제됨"이라는 치명적 결함은 Google 이 P0 버그로 접수했으나, 증상만 수정하고 스키마 수준의 근본 원인은 해결하지 못했음이 확인됨.

5. 의의 및 결론 (Significance)

• 프롬프트 엔지니어링의 패러다임 전환: 프롬프트를 단순한 텍스트가 아닌, 검증 인프라가 필요한 소프트웨어 아티팩트로 인식해야 함을 강조합니다.
• Conway 의 법칙 적용: 프롬프트의 구조는 이를 만든 팀의 구조를 반영합니다. 모놀리식 프롬프트는 팀 간 통합 테스트 부재로 인한 모순을, 모듈형은 계약 부재로 인한 결함을 낳습니다.
• 비용 효율적인 보안: 기존 보안 감사의 일부 비용으로 전체 벤더의 프롬프트를 정밀 분석할 수 있음을 보여주어, 모든 개발자가 프롬프트 품질 관리를 수행할 수 있는 가능성을 열었습니다.
• 미래 방향: 시스템 프롬프트에도 린터, 통합 테스트, CI/CD 파이프라인이 도입되어야 하며, 다중 모델 평가는 선택이 아닌 필수적인 방법론이 되어야 함을 결론지었습니다.

이 논문은 LLM 에이전트의 신뢰성을 높이기 위해 프롬프트 자체를 정밀하게 분석하고 검증하는 체계적인 접근법의 필요성을 강력하게 주장합니다.