왜 나의 AI 에이전트들은 코드를 작성할 수는 있지만 배포는 할 수 없는가

지난달 한 에이전트가 새벽 2시에 콘텐츠 업데이트를 완료하고, diff를 작성하고, 배포 전 점검(pre-deploy checks)을 실행한 뒤 멈췄습니다. 에이전트는 요청을 제출하고 유휴(idle) 상태로 들어갔습니다. 배포는 다음 날 아침, Librarian 프로세스가 예정된 검증을 실행하고 배포(ship)를 완료할 때까지 이루어지지 않았습니다.

그 일시 정지는 버그가 아니었습니다. 제가 그렇게 설계했습니다.

내가 제한한 권한

aienterprise.dk에서 운영 중인 모든 에이전트는 자신의 워크스페이스에 대한 파일 쓰기 권한(file write access)을 가집니다. 에이전트는 데이터베이스를 읽고, 외부 API를 호출하며, 콘텐츠를 생성하고 수정할 수 있습니다. 하지만 할 수 없는 것이 있는데, 바로 프로덕션(production)으로 푸시(push)하는 것입니다. pm2 reload 명령, 배포 스크립트(deploy script), 스냅샷 프로모터(snapshot promoter) 중 그 어떤 것도 배포 권한(deploy authority)으로 지정된 단 하나의 프로세스를 제외하고는 에이전트의 범위(scope)에 포함되지 않습니다.

이것은 불신에 관한 문제가 아닙니다. 에이전트가 작성한 코드는 대개 괜찮습니다. 문제는 리스크 비대칭성(risk asymmetry)입니다.

잘못된 파일 쓰기는 다음 리뷰 사이클에서 발견됩니다. 하지만 잘못된 프로덕션 배포는 실행되는 즉시 라이브(live) 상태가 됩니다. 이 둘은 실패 모드(failure mode)가 다르며, 동일한 액세스 모델(access model)을 가져서는 안 됩니다.

한 에이전트가 전체 식별자(full identifier) 대신 이름 접두사(name prefix)가 일치한다는 이유로 스키마 마이그레이션(schema migration)을 잘못된 사이트 인스턴스에 배포했을 때, 저는 그 간극을 닫았습니다. 아무도 다치지 않았고 롤백(rollback)은 4분 만에 끝났지만, 그 경로는 분명히 잘못되었습니다. 무언가를 만드는 에이전트가 그것을 언제 배포할지 결정하는 주체까지 되어서는 안 됩니다.

게이트(Gate)의 실제 모습

이 메커니즘은 의도적으로 단순하게 설계되었습니다. 에이전트가 배포 가능한 작업을 마치면 단 하나의 스크립트인 request-deploy.mjs를 호출합니다. 이 스크립트는 대상(surface), 의도 문자열(intent string), 그리고 아티팩트 ID(artifact ID)를 인자로 받습니다. 그게 전부입니다. 에이전트의 업무는 끝납니다.

별도의 프로세스인 Librarian이 실제 배포 토큰(deploy token)을 보유합니다. 이 프로세스는 15분 간격의 하트비트(heartbeat)와 요청이 도착했을 때 실행되는 자동 실행 트리거(autorun trigger)를 기반으로 작동합니다. Librarian은 새로운 스냅샷이 현재 진행 중인 다른 작업과 충돌하는지 확인하고, 배포 전 검증(pre-deploy verification)을 실행하며, 6개의 모든 사이트를 일제히 배포(ships in lockstep)합니다. 또한 의도 문자열을 변경 로그(changelog) 항목으로 사용하여 버전을 올리고, 배포 내용을 런타임 로그(runtime log)에 기록합니다.

에이전트는 Librarian(사서)와 직접 상호작용하지 않습니다. 이러한 분리는 마찰을 만들기 위한 것이 아닙니다. 에이전트 계층(agent layer)에 어떠한 예외 사항도 포함되지 않도록, 구축(build)하는 주체와 배포(ship)하는 주체가 결코 동일하지 않음을 보장하기 위해 존재합니다.

만약 배포가 진정으로 차단된다면, Librarian이 이를 에스컬레이션(escalate)합니다. 저는 알림을 받고 이를 해결합니다. 하지만 시스템은 에이전트가 긴급성을 주장하며 게이트(gate)를 우회하여 작업하는 것을 허용하지 않습니다.

왜 지금 이 문제를 고민해야 하는가

EU AI Act(EU 인공지능법)의 2027년 12월 마감 기한은 확정되었습니다. 고용, 핵심 인프라 또는 이주(migration) 맥락에서 에이전트 시스템(agentic systems)을 운영하는 덴마크 운영자들은 이를 기준으로 역산하여 계획을 세울 수 있는 계획 기간을 가지고 있습니다. 초안 Article 6 가이드라인은 고위험(high-risk)이 실무적으로 무엇을 의미하는지 정의하고 있으며, 그 답은 대부분의 개발자가 예상하는 것보다 더 광범위합니다.

하지만 승인 게이트(approval gates)를 구축해야 하는 이유는 규제 때문만은 아닙니다. 프로덕션 시스템(production systems)은 데모와는 다른 방식으로 고장 나기 때문입니다. 작성(write)과 배포(ship)를 모두 할 수 있는 에이전트는 잘못된 결정의 폭발 반경(blast radius)이 한 축을 따라 무제한이 되는 시스템입니다. 그것이 바로 문제가 발생한 후가 아니라, 발생하기 전에 통제해야 할 축입니다.

제가 에이전트로부터 배포 권한을 제한한 이유는 구축된 것과 배포된 것 사이의 경계에 책임성(accountability)이 존재하기 때문입니다. 에이전트가 구축하고 배포까지 했는데 무언가 고장 난다면, 감사 추적(audit trail)을 읽기가 더 어려워집니다. 반면 에이전트가 구축하고 별도의 프로세스가 검증 후 배포한다면, 모든 단계가 기록되고 추적 가능(attributable)해집니다.

이것이 바로 거버넌스(governance) 메커니즘입니다. 이는 단순한 정책 문서가 아닙니다. 정책을 강제할 수 있게 만드는 아키텍처 결정(architecture decision)입니다.