AI 코딩 에이전트가 실제로 수행한 작업을 검증하기 위한 도구 구축

AI 코딩 에이전트는 코드를 작성하는 것 외에 한 가지, 즉 '단언(asserting)'하는 데 매우 능합니다. "테스트를 통과했습니다." "파일이 업데이트되었습니다." "수정 사항을 푸시했습니다." 실제로 에이전트를 업무에 사용해 본 사람이라면, 이러한 주장들이 때로는... 낙관적이라는 것을 알고 있을 것입니다.

저는 Devin을 매일 사용하는 QA 엔지니어입니다. 어느 순간부터 저는 에이전트의 주장이 현실과 일치하는지 수동으로 확인하는 것에 지쳤고, 그래서 QA 엔지니어가 하는 일을 했습니다. 테스트 하네스(test harness)를 만들었습니다. 그다음 평가 스위트(eval suite)를 만들었고, 정책 계층(policy layer)을 만들었으며, 결정 계층(decision layer)까지 만들었습니다. 이십 개의 로컬 우선 도구들 덕분에 전체 스택은 기기에서 어떠한 원격 전송(telemetry)도 발생하지 않는 RAM 제약형 노트북에서 실행됩니다.

이것은 존재하는 것, 이유, 그리고 제가 배운 것의 간략한 버전입니다.

격차: 에이전트는 단언하고, QA는 검증한다

계기는 간단했습니다. 에이전트 세션이 "수정 완료, 모두 정상"이라고 보고했지만, 디스크의 파일은 그와 달랐습니다. 악의적인 의도는 없었습니다. 에이전트는 지상 진실(ground truth)에서가 아니라 자신만의 서사(narrative)를 바탕으로 보고합니다. 전형적인 QA 문제입니다: _주장(claim)_과 _상태(state)_는 서로 다른 아티팩트이며, 그중 오직 하나만이 증거입니다.

모든 것을 가능하게 만든 통찰은 다음과 같습니다: 에이전트 CLI는 이미 로컬에 구조화된 원격 전송(structured telemetry)을 작성합니다. 세션 파일, 도구 호출 상태, 토큰 사용량 같은 것들이요. 증거는 처음부터 디스크 위에 놓여 있었습니다. 저는 그저 이야기에 대한 신뢰를 멈추고 로그를 읽기 시작해야 했을 뿐입니다.

다섯 가지 도구, 하나의 파이프라인

이 도구들은 이해(understand) → 검증(verify) → 측정(measure) → 제어(control) → 판단(judge)의 순서로 구성됩니다.

devin-internals-spec — 이해하기. 도구 출력을 신뢰하려면 계약(contract)을 알아야 합니다: 파일 형식, 종료 코드, 그리고 런타임 자체의 행동 규칙입니다. 이것이 스펙 계층(spec layer)이며, 모든 다운스트림 요소는 이를 기준으로 읽힙니다.

devin-qa-pack — 검증(verify). 실제 에이전트 작업에 대한 QA 감사를 실행합니다: 파일 차이점(file diffs) 존재 여부, 테스트 실행 여부, 커밋 존재 여부, 푸시 완료 여부, 검증 명령어 실행 여부. 주장은 에이전트의 서사(narrative)가 아닌 tool_call_state를 기준으로 확인됩니다. 47개의 테스트 케이스, Ubuntu + Windows에서 CI 지원. 이 도구가 모든 것을 시작하게 했습니다.

devin-evals — 측정(measure). 검증이 작동하면 더 어려운 질문을 할 수 있습니다: 에이전트가 이러한 종류의 작업에서 얼마나 좋은가? 골든 태스크(Golden tasks), 루브릭 점수화(rubric scoring), 세션 간 회귀 추적(regression tracking) 기능입니다.

devin-bridge — 제어(control). 의도와 실행 사이에 놓인 정책 게이트입니다. ACP 기반 제어로, --devin-only 모드를 통해

• devin-history — 세션 간 메모리(cross-session memory): 모든 과거 세션을 검색 가능한 SQLite 데이터베이스로 제공합니다 (grep 가능한 에이전트 고고학 7개 이상의 명령어).
• devin-metrics — 시간에 따른 품질 신호 측정을 위한 원격 측정(telemetry) 집계 기능입니다.
• devin-memory + devin-search + devin-graph — 세션, 프로젝트 및 의사결정 전반에 걸친 메모리 저장소, 검색 및 지식 그래프를 제공합니다.
• devin-doctor — Windows/Linux 환경 전반의 진단 기능을 수행합니다.
• devin-backup — 에이전트 상태의 스냅샷(snapshot) 생성, 검증 및 복원 기능입니다.
• devin-janitor + devin-redact — 상태가 안전하게 이동할 수 있도록 정리(cleanup)하고 비밀 정보를 마스킹(secret-redaction)하는 기능을 제공합니다.
• devin-office — 재미있는 기능으로, 로컬 저장소에서 실제 세션, 서브 에이전트 및 도구 호출을 렌더링하는 실시간 회로 기판 대시보드입니다. 순전히 시각적이며, 읽기 전용(read-only)이고 원격 측정 데이터가 전혀 필요하지 않으며 — 멋진 데모 GIF를 만들기에 완벽합니다.

이것을 구축하며 얻은 세 가지 교훈

1. 에이전트 자체의 원격 측정 데이터는 활용되지 않은 QA(품질 보증) 데이터 소스입니다. 세션 파일과 도구 호출 상태는 대부분의 사람들이 무시하는 구조화된 증거물입니다. 이를 읽어보는 것은

• Profile/catalog: github.com/Icaro0310
• Website: icaro0310.github.io
• Start here: devin-qa-pack (검증기) 또는 poordjaevin (보정된 평가자 — pip install poordjaevin / uv tool install poordjaevin)

댓글에 솔직히 묻겠습니다. 만약 여러분이 실제 업무 환경에서 AI 에이전트(Copilot, Devin, Cursor, Claude Code 등)를 구동한다면, 오늘날 그들의 주장을 어떻게 검증하시나요? 수동적인 부분 점검인가요? CI 게이트(CI gates)인가요? 아니면 아무것도 안 하나요? 저는 '아무것도 아니다'가 가장 흔한 답변일 것이라고 의심하며, 이 스택을 구축하게 된 이유도 저 자신이 그럴까 봐 두려웠기 때문입니다.