에이전트가 새벽 2시에 작업을 마칩니다. 스냅샷 (Snapshot)이 빌드되었고, 사전 점검 (preflight checks)을 통과했으며, 모든 것이 정상(green)입니다. 그런 다음 에이전트는 배포 요청을 제출하고 멈춥니다.

이것은 의도된 것입니다. 에이전트는 자신의 빌드를 직접 배포할 수 없습니다. 나는 에이전트에게 다른 어떤 권한을 주기 전에 이 능력을 제한했습니다.

게이트(Gate)의 모습

Agent Enterprise (aienterprise.dk)에서는 모든 코드 변경, 콘텐츠 업데이트, 설정 수정 사항이 프로덕션 (production)에 반영되기 전에 배포 요청 스크립트를 거칩니다. 작업을 마친 에이전트는 자신이 무엇을 빌드했는지, 무엇을 변경했는지, 그리고 그 이유와 함께 request-deploy.mjs를 실행합니다. Librarian 배포 루틴 (deploy routine)이 루트 권한 토큰 (root capability token)을 보유하고 있습니다. Librarian이 해당 요청을 처리하지 않으면 아무것도 배포되지 않습니다.

에이전트는 pm2 reload를 사용할 수 없습니다. snapshot:deploy를 실행할 수도 없습니다. 빌드를 승격 (promote)할 수도 없습니다. 하네스 (harness) 내의 PreToolUse 훅 (hook)이 배포 명령처럼 보이는 모든 호출을 가로채서 차단합니다. 즉각적인 중단입니다.

에이전트는 빌드, 테스트, 쓰기, 읽기, 콘텐츠 생성, 데이터베이스 쿼리, 요청 제출 등 많은 일을 할 수 있습니다. 에이전트가 할 수 없는 단 한 가지는 감사 가능한 기록 (auditable record)을 생성하는 중간 단계 없이 자신의 작업물을 프로덕션에 직접 올리는 것입니다.

Librarian 또한 에이전트입니다. 하지만 배포 토큰 (deploy token)을 가진 유일한 에이전트이며, 완전한 출처 (provenance) 정보—누가 빌드했는지, 어떤 스냅샷 ID인지, 의도가 무엇이었는지, 무엇이 변경되었는지—가 포함된 요청만 처리합니다. Librarian은 배포하기 전에 검증합니다. 런타임 로그 (runtime log)에 기록합니다. 플릿 (fleet) 전체에서 무언가가 미완성 상태로 배포되지 않도록 9개 사이트 모두에서 일제히 작업을 수행합니다.

복잡하게 들릴 수 있습니다. 요청을 제출하는 데 약 3분이 걸리고, Librarian이 이를 처리하는 데 약 15분이 걸릴 수 있습니다. 이것이 비용입니다.

왜 이렇게 설계했는가

첫 번째 이유는 돌이켜보면 명백합니다. 자신의 코드를 배포할 수 있는 에이전트는 무엇이든 배포할 수 있습니다. 추론 (reasoning) 과정에서 무언가 잘못되면, 누군가 확인하기도 전에 실수가 라이브 환경에 반영됩니다. 저는 테스트 환경의 초기 프로토타입이 사전 점검 (preflight)이 통과되지 않았음에도 통과되었다고 판단하여, 미완성된 빌드를 자신 있게 배포하는 것을 목격했습니다. 아무것도 망가지지는 않았습니다. 하지만 그 사건은 위험의 형태를 즉각적으로 명확히 해주었습니다.

두 번째 이유는 설명하기 더 어렵지만 더 중요합니다. 만약 에이전트가 스스로를 배포한다면, 행위와 그 행위가 기록되는 시점이 분리되지 않습니다. 배포와 배포 기록이 동일한 이벤트가 됩니다. 새벽 3시에 무언가 잘못되었을 때, 당신은 무엇이 승인되었는지, 누가 승인했는지, 그리고 실제로 어떤 아티팩트 (artifact)가 배포되었는지 알아야 합니다. 요청 및 처리 (request-and-process) 모델은 누군가 로그를 남기는 것을 기억하기를 바라는 것이 아니라, 구조적으로 그 기록을 생성합니다.

세 번째 이유는 이번 달에 나타났습니다. 트럼프 행정부의 지침 이후 Anthropic의 Mythos 모델들이 14일 동안 오프라인 상태가 되었습니다. 타임라인도 없었습니다. 외부에서 볼 수 있는 항소 경로도 없었습니다. 만약 내 스택의 모든 기능이 행정 명령에 의해 중단될 수 있는 단일 모델에 의존하고 있다면, 나는 신뢰할 수 있는 운영을 하고 있는 것이 아닙니다. 나는 타인이 작동하지 않기로 결정할 때까지 작동하는 시스템을 운영하고 있는 것입니다.

배포 게이트 (deploy gate)는 모델 중단에 대비한 방어책은 아닙니다. 하지만 이는 동일한 본능을 반영합니다. 가장 중요한 능력은 당신이 제거하는 것에 대해 가장 깊이 고민했던 능력입니다. 경계는 필요로 한 후가 아니라, 필요로 하기 전에 설계해야 합니다.

트레이드오프 (The tradeoff)

15분의 지연 시간 (latency)이 비용입니다. 때로는 그보다 더 걸릴 수도 있습니다. 새벽 2시에 작업을 마친 에이전트가 새벽 2시에 바로 배포하는 것은 아닙니다. Librarian이 실행될 때 배포됩니다. 이것은 의도적인 선택입니다.

그 대가로, 운영 환경(production)의 모든 배포에는 요청 기록, 아티팩트 ID, 의도 문자열 (intent string), 그리고 검증 로그가 남습니다. 무언가 고장 나면, 나는 무엇이, 언제, 왜 준비되었다고 판단되어 배포되었는지 알 수 있습니다. 특정 스냅샷 (snapshot)으로 롤백 (roll back)할 수 있으며, 그 스냅샷에 정확히 무엇이 포함되어 있었는지 알 수 있습니다.

또한 수치화하기는 더 어려운 부분도 얻었습니다. 기록 없이 아무것도 배포되지 않는다는 사실을 알 때 저는 더 편안하게 잠을 잡니다. 에이전트 (agents)를 신뢰하지 못해서가 아니라, 에이전트들이 설계상 스스로를 신뢰하지 않기 때문입니다. 그들은 자신의 작업이 프로덕션 (production)으로 넘어갈지 여부에 대한 권한이 자신들에게 없다는 것을 알고 있습니다. 그러한 지식은 시스템 프롬프트 (system prompt)가 아니라 하네스 (harness)에 내장되어 있습니다.

에이전트 시스템 (agentic systems)을 구축할 때 대부분의 사람들이 범하는 실수는 모든 능력을 사전에 부여한 뒤 무언가 고장 날 때 제한 사항을 추가하는 것입니다. 저는 제한 사항을 먼저 구축했습니다. 그 외의 모든 것은 그 이후에 따라왔습니다.