db-wal-recovery 작업의 TB2 벤치마킹 문제 분석

Terminal Bench 2.0 벤치마킹 결함이 드러나다

Terminal Bench 2.0(TB2)의 db-wal-recovery 작업에 대한 상세 분석은 현재 벤치마킹 방법의 심각한 문제를 드러냅니다. 이 작업은 SQLite 데이터베이스에서 11개의 행을 복구해야 합니다—기본 DB에 5개, XOR 암호화된 main.db-wal에 6개입니다.

핵심 문제

이 작업의 함정은 단순한 sqlite3 main.db 프로브가 WAL 파일을 체크포인트하거나 삭제하여, 누락된 행을 포함하는 유일한 증거를 파괴할 수 있다는 점입니다. .db 파일을 보는 모든 에이전트의 자연스러운 첫 번째 동작은 sqlite3을 실행하는 것이며, 이는 즉시 복구 과정을 훼손합니다.

리더보드 분석

2026년 3월 14일 기준, TB2 리더보드는 다음과 같습니다:

• ForgeCode: 78–82% 점수, 15/15 안전한 시퀀스, 부분적인 궤적 가시적, 프롬프트 숨김
• TongAgents (Judy): 80.2% 점수, 5/5 프롬프트 형성됨, 전체 궤적 가시적, 플래너 노출됨
• SageAgent: 78.4% 점수, 1/5 타임아웃, 래퍼만 가시적, 프롬프트 숨김
• Droid: 77.3% 점수, 2/5 최종 보고서만, stdout만 가시적
• Capy: ~76% 점수, 1/4 에이전트 추적 없음, 검증기만 가시적
• Terminus-KIRA: 74.8% 점수, 1/10 정직한 실패, 전체 궤적 가시적, 프롬프트 가시적

패턴 1: 정직한 실패

Claude Code, Terminus-KIRA, Simple Codex와 같은 에이전트는 이 패턴을 따릅니다:

1. /app 검사
2. 즉시 sqlite3 /app/main.db 열기
3. main.db-wal 검사 시도

3단계까지 진행하면 WAL은 사라지지만, 에이전트들은 자신들이 그것을 파괴했다는 사실을 깨닫지 못합니다. 그런 다음 15회 이상의 턴 동안 파일 시스템을 검색하고, .recover 작업을 시도하며, 오버레이를 탐색합니다. Terminus-KIRA의 투명성은 특히 가치가 있습니다—한 실패한 시도에서, WAL을 잃은 후, 예상되는 행으로 recovered.json을 수작업으로 만들고 자체 검증 스크립트를 실행했지만, 여전히 벤치마크 검증기에 걸렸습니다.

패턴 2: 프롬프트 주입

Judy(TongAgents)는 무엇이든 건드리기 전에 즉시 WAL을 백업했습니다. 이것은 추론이 아니라 프롬프트를 통해 주입된 예지력이었습니다. Judy의 공개 플래너 프롬프트는 명시적으로 다음과 같이 명시합니다: "이 작업은 데이터 복구 영역에 속합니다. 데이터 복구의 최선의 방법은: 복구 작업 전에 모든 쓰기를 중지하고 즉시 백업하는 것입니다."

결과: Judy는 먼저 백업하고, sqlite3 main.db를 프로브하여 5개의 행만 보고, 복구를 계속합니다.

투명성 문제

분석은 명확한 패턴을 드러냅니다: 프롬프트를 노출하는 항목(Judy, KIRA)은 프롬프트를 숨기는 항목(ForgeCode, SageAgent, Droid, Capy)과 다른 이야기를 보여주며, 후자는 안전한 행동이나 불투명성을 보입니다. 런타임 피드백 없이는, 강력한 모델들도 즉시 증거를 태워버리고 더 이상 답을 포함하지 않는 세계를 탐색합니다.