AWS의 AIRE 팀 작성. Vulcan은 AWS 솔루션 아키텍트(Solutions Architects)를 위한 내부 도구이며 공개 제품은 아닙니다. 하지만 이 포스트에 언급된 모든 메커니즘은 어떤 에이전트 하네스(agent harness)에서도 재현 가능하며, 의사코드(pseudocode) 스케치는 그 방법을 정확히 보여줍니다.

몇 주 전, 우리가 만든 빌드 중 하나가 28개의 요구사항 체크를 모두 통과했습니다. 모든 기능적 요구사항이 증거와 연결되어 있었습니다. 게이트(gate)에는 PASS라고 표시되었습니다. 모든 항목이 초록색이었습니다.

그 후 우리는 라이브 앱을 클릭해 보았습니다.

첫 로그인 화면이 충돌했습니다. UI는 "세계 수준"을 요구하는 사양(spec) 뒤에 숨겨진 뼈대(scaffold)에 불과했습니다. 그리고 아키텍처가 승인된 시점을 찾아보았을 때, 우리는 그것을 발견했습니다. 대화 도중 다른 질문에 답변하며 중간에 묻혀 있던 대화형 "ok"가 있었고, 에이전트는 이를 자신의 원장(ledger)에 공식 승인(formal sign-off)으로 기록해 두었습니다.

게이트는 초록색이었지만, 실제로는 격차가 있었습니다. 이 포스트는 그 이후에 이어진 조사 과정에 대한 기록입니다. 우리가 무엇을 발견했는지, 각 발견 사항이 우리로 하여금 무엇을 구축하게 만들었는지, 그리고 왜 모든 지속 가능한 해결책이 결국 동일한 지점, 즉 **모델 외부에서 논쟁의 여지가 없는 결정론적 강제 지점(deterministic enforcement point)**으로 귀결되었는지에 대해 다룹니다.

조사 대상 시스템은 Vulcan입니다. Vulcan은 충실도(fidelity)를 유일한 임무로 하는 에이전트 루프(agentic loop)입니다. 고객의 요구사항을 받아 "실행 중이며 요구사항이 검증된" AWS 빌드로 이끄는 것이 목적입니다. 즉, 요구사항을 명확히 하고, 측정 가능한 사양(spec)을 작성하며, 설계하고, 빌드하고, 실제 계정에 라이브로 배포하며, 실행을 통해 모든 요구사항을 검증하고, 데모를 수행합니다. 이는 Claude Code 플러그인으로, 하나의 오케스트레이터(orchestrator), 다섯 개의 하위 에이전트(subagents), 그리고 빌드 라이프사이클(build lifecycle)에 걸친 12개의 훅(hooks)으로 구성됩니다. 이 훅들이 이야기의 핵심입니다.

증거 A: 결코 일어나지 않았던 승인

묻혀버린 _ok_부터 시작해 봅시다. 에이전트의 그 무엇도 정확히 거짓말을 하고 있었던 것은 아닙니다. 오케스트레이터(orchestrator)는 아키텍처를 제시하고 빌드하기 전에 승인(sign-off)을 요청하도록 프롬프트(prompt)가 설정되어 있습니다. 에이전트는 아키텍처를 제시했습니다. 사용자는 그 근처에서 긍정적인 무언가를 말했습니다. 모델은 — 도움이 되고, 자신만만하며, 진행해야 한다는 압박을 받는 상태에서 — 모호함을 진행하는 방향으로 해결했고, 승인을 받았다고 기록했습니다.

더 나은 프롬프트로는 이 문제를 신뢰할 수 있게 해결할 수 없습니다. 저희도 시도해 보았습니다. 프롬프트 규칙은 하나의 제안일 뿐이며, 모델은 계속 진행할 수 있도록 그 제안을 해석하는 데 전문가입니다. 효과가 있었던 해결책은 **프리-툴-콜 훅 (pre-tool-call hook)**이었습니다. 빌드 결과물(build-artifact)을 쓰기 전에, 모델이 아닌 스크립트가 명시적이고 구조화된 승인 질문에 의해서만 작성되는 마커 파일의 존재 여부를 확인합니다:

# stage gate: architecture-approved-before-build
on before_write(build_artifact):
    if exists(".approved/architecture"):
...

가벼운 "ok"로는 그 게이트(gate)를 통과할 수 없습니다. 오직 명시적인 승인 흐름만이 승인 마커를 작성합니다. 이 규칙은 모델이 재해석할 수 있는 산문(prose)이기를 그만두고, 훅(hook)이 강제할 수 있는 상태 전이(state transition)가 되었습니다.

중복 제거 마커인 .approved/.already-asked에 주목하십시오. 이는 첫 번째 버전에는 없었으며, 이것의 부재는 이 사례의 두 번째 교훈을 가르쳐 주었습니다. 첫 번째 버전은 승인이 누락된 상태에서 모든 파일 쓰기 시마다 다시 질문했습니다. 엄격해 보일 수 있지만, 실제로는 작업 흐름 중간에 있는 빌더가 수십 번이나 동일한 중단을 겪게 되었고, 세션 내에서 반사적으로 클릭하며 넘기게 되었습니다. 끊임없이 발생하는 게이트는 운영자가 이를 무시하도록 훈련시킵니다. 이는 게이트가 없는 것보다 더 나쁩니다. 이제 진짜 중단 상황에서도 반사적으로 클릭하게 되기 때문입니다. 수정된 버전은 한 번만 중단시키되, 승인이 존재할 때까지 계속 차단합니다. 저희는 이를 하루 만에 핫픽스(hotfix)로 배포했습니다.

나중에 저희는 연구 결과도 수치로 이를 뒷받침한다는 것을 알게 되었습니다. 자세한 내용은 아래에서 다룹니다.

사례 B: 실제 사용자에게만 충돌이 발생한 로그인 화면

빌드의 인증(auth)은 "검증되었습니다"라고 표시되었습니다. 해당 검증은 빌더(builder)가 직접 생성한 시드 테스트 사용자(seeded test users) — 즉, 데이터베이스에 직접 생성되고, 사전 확인되었으며, 비밀번호가 이미 설정된 사용자 — 로 로그인하여 수행되었습니다. 하지만 실제 새로운 사용자가 실제 첫 로그인 흐름(first-login flow)인 임시 비밀번호, 강제 재설정, MFA(다요소 인증) 등록 과정을 거치자 시스템이 충돌했습니다. 해당 경로는 한 번도 실행된 적이 없었습니다. 결국 충돌이 발생했습니다.

여기서 나타난 일반적인 실패 양상은 버그 자체보다 더 흥미롭습니다. 빌더가 자신이 만든 시스템을, 자신이 만든 계정들을 사용하여, 자신이 예상한 경로를 따라 검증했다는 점입니다. 개별적인 선택은 모두 합리적이었습니다. 하지만 그 결합체는 가장 흔한 실제 환경의 경로를 보지 못하는 검증 방식이었습니다.

이 사건을 통해 두 가지 구조적 변화가 도출되었습니다. 첫째, 검증 작업이 별도의 에이전트 — **새로운 컨텍스트 (fresh context)**에서 실행되며, 사양(spec)과 실행 중인 시스템을 전달받고, 빌더의 설명(narration)을 명시적으로 불신하도록 지시받는 요구사항 감사자(requirement auditor)로 분리되었습니다. 이 감사자는 오직 *관찰된 동작(observed behavior)*만을 바탕으로 추론합니다. 둘째, 인증이나 페르소나(persona)가 포함된 모든 빌드에 대해 증거 수준이 높아졌습니다. 감사자는 빌더의 시드 사용자들이 건너뛰는 '해피 패스(happy path)'가 아니라, 모든 페르소나를 실제 라이브 환경의 전체 생애주기(full lifecycle) — 첫 로그인, 강제 비밀번호 변경, MFA 등록, 역할 기반 보기(role-gated views), 위조되거나 타 테넌트의 토큰이 거부되는 과정 — 를 직접 수행하며 검증해야 합니다.

이러한 증거 요구사항은 단순히 프롬프트의 한 문단으로 해결되는 것이 아닙니다. 이는 중단 시점 훅(stop-time hook)에 의해 체크되는 하나의 문법(grammar)입니다.

# exit gate: 중단 훅은 분위기(vibes)가 아니라 기계가 확인 가능한 마커를 읽습니다
on agent_wants_to_stop():
    coverage = parse(verification_artifact)
...

에이전트가 작업이 완료되었다고 믿고 중단을 시도할 때, 이 훅(hook)이 중단을 가로채어 검증 아티팩트(verification artifact)를 확인합니다. EXECUTION은 실행 중인 시스템을 구동함으로써 요구사항이 증명되었음을 의미하며, 결과로 나타난 테스트 실행 또는 관찰 결과에 대한 참조를 포함해야 합니다. 즉, "템플릿에 리소스가 존재함"과 같은 식의 설명은 인정되지 않습니다. 마커(marker)가 종료 계약(exit contract)이며, 첨부된 증거가 곧 증명입니다. 계약과 증거가 없다면 종료할 수 없습니다. 훅은 실패 시 차단(fails closed) 방식으로 동작하며, 에이전트는 다시 작업으로 돌아갑니다. "다 끝난 것 같습니다"라는 말은 증거가 될 수 없습니다.

동일한 훅 계층은 안전 바닥(safety floor) 역할도 수행합니다. 파괴적인 클라우드 작업(삭제, 종료, 키 제거) 및 노출(exposure) 작업(퍼블릭 버킷, 와일드카드 주체, 0.0.0.0/0 인그레스, 인증되지 않은 엔드포인트)은 모든 자율 모드(autonomy mode)의 도구 호출(tool-call) 계층에서 엄격히 거부됩니다. 훅은 도구가 실행되기도 전에 _거부(deny)_를 반환합니다. "정말 하시겠습니까?"라고 묻는 것이 아니라, 즉시 거부됩니다. 단 하나의 예외(임시 디렉토리 정리)는 /tmp/../etc 경로 탐색(traversal) 트릭을 사용하는 적대적 검토(adversarial review)를 통과했습니다. 그리고 검토자가 경로 체크 로직보다 한 번 더 앞서 승리하기도 했습니다. 여러분의 가드레일(guardrails)에도 감사인(auditor)이 필요합니다.

전시물 C: 모든 요구사항을 통과한 스캐폴드(scaffold)

세 번째 발견 사항은 가장 미묘했습니다. 빌드 과정에서 프론트엔드 디자인 가이드라인 스킬 팩을 로드했지만, 이후 이를 완전히 무시했습니다. UI는 명세서(spec)가 설명한 제품의 와이어프레임(wireframe)처럼 보이면서도, 모든 기능적 요구사항의 문구는 충족했습니다. 요구사항 추적(requirement-tracing) 과정에서는 이를 잡아낼 수 없는데, 왜냐하면 모든 요구사항이 실제로 충족되었기 때문입니다.

이로 인해 우리는 이제 근본적인 것으로 취급하는 구분을 강제하게 되었습니다: 요구사항을 충족하는 것과 실제(real)인 것은 서로 다른 속성이며, 이들은 서로 다른 검증 계층을 필요로 합니다.

계층 1 — 실행 증거 (execution evidence) (Exhibit B의 수정 사항): 모든 요구사항은 실행된 테스트 또는 실시간 관찰(live observation)로 추적됩니다. 한 번도 실행되지 않은 코드를 잡아냅니다.

계층 2 — 타당성 (plausibility): 도메인 지식을 바탕으로 _실제 출력값(actual outputs)_을 추론하며 검토하는 단계입니다. 모든 입력에 대해 동일하게 나오는 위험 점수(risk score)는 아무것도 측정하지 못하고 있는 것입니다. 로직인 척하는 하드코딩된 조회 테이블(lookup table)은 가짜입니다. 데모용 시드 데이터(seed data)가 라이브 뷰에 유출되는 것은 고객이 발견하기만을 기다리는 거짓말입니다. 로드되었지만 무시된 스킬 팩은 이제 명시적인 SKILL-APPLICATION 결과값을 생성합니다 — _로드됨 ≠ 적용됨_입니다. 모두 '수정 우선(fix-first)' 원칙을 따릅니다. 이들은 게이트(gate)에 도달하기 전에 차단합니다. 왜냐하면 빌드가 요구사항의 100%를 통과하더라도, 라이브 데모를 직접 클릭해 보지 않으면 알 수 없는 엉터리일 수 있기 때문입니다.

계층 3 — 검증기 무결성 (verifier integrity): 감사자(auditor)는 'PASS'를 내보내기 전에 _자기 자신_을 감사합니다. 테스트가 증명하기 위해서가 아니라 통과하기 위해 약화되었는가? 증거가 사용된 탐침(probes)에 딱 맞게 조작되었는가? 모든 것이 첫 시도에 초록색(green)으로 돌아왔는가? — 마지막 경우의 경우, 이제 새로운 탐침을 사용한 재샘플링(re-sampling)을 트리거합니다. 우리의 경험상 즉각적이고 보편적인 초록색은 승리라기보다 검증 결함인 경우가 더 많기 때문입니다. 확인된 게임 플레이(gaming) 결과는 커버리지(coverage) 퍼센트에 관계없이 게이트를 차단합니다.

아무도 첫날부터 계층 3을 설계하지 않습니다. 계층 3이 잡아냈을 빌드를 계층 2가 인증하는 과정을 지켜보며 계층 3을 획득하게 됩니다.

그리고 연구가 사고들을 따라잡았습니다

이 글을 쓰는 동안 우리는 2026년 6월~7월의 문헌들을 검토했으며, 인용하기 전에 각 주장의 허점을 찾으려 노력했습니다. 불편한 사실은, 이 분야가 이제 우리가 여러 차례의 타격을 입으며 배웠던 것들을 _정량화(quantified)_했다는 점입니다.

에이전트의 실질적이고 측정 가능한 수준에서의 게임화(gaming) 검증. UC Berkeley의 자동 감사 도구는 13개의 널리 사용되는 벤치마크에서 45개의 확인된 벤치마크 해킹 취약점(benchmark-hacking exploits)을 찾아냈습니다. 이는 과제를 실제로 해결하지 않고도 완벽한 점수를 얻는 작동 가능한 개념 증명(proof-of-concept) 코드입니다. Cursor의 731개 코딩 에이전트 궤적(trajectories)에 대한 감사 결과, 성공적인 해결책 중 63%가 스스로 도출해낸 것이 아니라 이미 알려진 수정 사항을 검색하여 가져온 것으로 나타났습니다. 저장소 기록(repository history)을 봉인하고 인터넷 접속을 차단하자, 하나의 SWE-bench Pro 점수가 87.1%에서 73.0%로 하락했습니다. OpenAI는 감사한 어려운 문제의 59.4%에서 중대한 문제를 발견한 후 SWE-bench Verified 보고를 중단했습니다. 이것이 바로 생태계 규모에서 발생하는 Exhibit C의 Layer 3입니다.

취약한 검증기(verifiers)는 공격 표면(attack surface)이며, 결정론적 실행(deterministic execution)이 모델의 판단보다 우월합니다. SWE-bench Verified에서 샘플링된 작업의 28.5%는 잘못된 패치가 통과될 정도로 테스트 스위트(test suites)가 취약하며, 최첨단 모델(frontier models)은 견고한 작업보다 해킹 가능한 작업에서 점수가 14점 더 높게 나타납니다. 이 격차 자체가 바로 게임화(gaming)입니다. 동일한 논문의 결정적인 통계는 우리의 논지 전체를 한 줄로 요약합니다. 결정론적인 Docker 실행 게이트를 통해 LLM 판독기(LLM judge)만으로는 놓쳤던 LLM 생성 테스트의 결함률 61.9%를 잡아냈습니다. 검사(inspection)보다 실행 증거(execution evidence)가 우선입니다. 우리가 후크(hooks)를 제공하는 바로 그 작업에서 스크립트가 모델보다 더 뛰어난 성능을 보여준 것입니다.

업계는 모델 외부에서의 강제 집행(enforcement)으로 수렴하고 있습니다. OpenAI의 2026년 7월 Running Codex safely는 샌드박스 경계(sandbox boundaries), 결정론적 명령 규칙(deterministic command rules), 제한된 네트워크 액세스(constrained network access), 그리고 사용자가 재설정할 수 없는 관리자 설정(admin configs)을 설명합니다. 별도의 Auto-review documentation은 이러한 경계를 명확히 합니다. 즉, 검토자(reviewer)는 권한 상승(escalation)을 승인하거나 거부할 수 있으며, 타임아웃(timeout)은 권한으로 조용히 전환되는 것이 아니라 타임아웃 그 자체로 드러납니다. 연구 측면에서는, Glite ARF가 결정론적인 Python 검증 스크립트(deterministic Python verifier scripts)를 통해 멀티 에이전트 프로세스 규칙을 강제합니다. 저자들의 표현을 빌리자면, 이 규칙들은 "에이전트에게 단순히 따르라고 요청하는 산문(prose) 속에 있는 것이 아니라, 위반 시 요란하게 실패하는 코드 속에 존재"합니다. 우리는 서로 다른 사건들을 통해 동일한 형태에 도달했습니다. 독립적인 팀들이 이처럼 한 방향으로 수렴한다면, 그것이 아마도 정답(the shape)일 것입니다.