CI/CD에서 인간의 승인 단계를 자동화했을 때, 당신은 그 기능이 수행하던 역할을 대체한 것이 아닙니다

새벽 3시, 당신의 파이프라인(pipeline)이 방금 배포를 승인했습니다.
자율적인 야간 루프(autonomous overnight loop)는 더 이상 사고 실험이 아닙니다. 이는 문서화되었고, 제품화되었으며, 실제 운영 환경(production)에서 작동하고 있습니다:

루프 패턴(loop pattern) — 작업 선택, 구현, 검증, 커밋, 컨텍스트 리셋, 반복 —은 Geoffrey Huntley에 의해 대중화되었으며 Addy Osmani에 의해 상세히 기술되었습니다.
Docker는 2026년 1월 30일에 Docker Sandboxes를 출시했습니다. 이는 각 에이전트(agent) 세션이 전용 마이크로VM(microVM)에서 실행되는 MicroVM 기반 격리 기술으로, Claude Code, Copilot CLI, Codex CLI, Gemini CLI 및 Kiro를 지원합니다.
Ramp에서는 Modal의 VM 인프라 위에서 실행되는 자율 에이전트(autonomous agent)가 현재 병합된 모든 풀 리퀘스트(pull requests)의 약 절반을 처리하고 있습니다.
이번 주 DevX 기사에 따르면, 실제 운영 DevOps 환경의 에이전트들은 "장애를 분류(triaging incidents)하고, 일상적인 수정을 위한 풀 리퀘스트를 생성하며, 인프라를 확장하고, 심지어 저위험 배포를 승인하기도" 합니다.

만약 당신이 플랫폼(platform)이나 DevOps를 운영하고 있다면, 이 방식의 어떤 버전이 이미 당신의 파이프라인에 있거나 경영진이 방금 승인한 로드맵에 포함되어 있을 것입니다. 이 글은 이를 실행할 때 구체적으로 무엇이 제거되는지, 그리고 무엇을 다시 채워 넣어야 하는지에 관한 것입니다.

인간의 승인 단계가 실제로 수행하던 역할

지난 10년 동안 CI/CD 릴리스 규율은 너무나 기본적이어서 놓치기 쉬운 속성에 의존해 왔습니다. 바로 특정 작업은 인간의 승인(signing off) 없이는 일어나지 않는다는 점입니다. 프로덕션(production)으로의 승격, 파괴적인 마이그레이션(destructive migration) 실행, 보호된 브랜치(protected branch)로의 강제 푸시(force-push), 자격 증명(credential) 순환 등이 이에 해당합니다. 인간이 루프(loop) 안에 있었고, 그 루프가 곧 제어(control)였습니다.

대부분의 팀이 자동화를 통해 이를 제거할 때 실수하는 부분이 여기 있습니다. 승인 단계의 가치는 인간의 지능에 있었던 것이 아닙니다. 그 단계가 결정론적(deterministic)이었다는 점에 있었습니다. 실제 영향 범위(blast radius)가 큰 그 어떤 것도 그 단계를 통과하지 않고는 배포되지 않았습니다. 인간은 느리고 비용이 많이 들지만, 신뢰할 수 있는 if 문(if statement)이었습니다.

에이전트를 무인 파이프라인(unattended pipeline)으로 옮길 때, 당신은 그 if 문을 삭제하는 것입니다. 그리고 거의 모든 사람이 이를 보완하기 위해 찾는 두 가지 제어 수단은 실제로 그것을 대체하지 못합니다.

샌드박싱(sandboxing)과 RBAC가 승인 단계를 대체할 수 없는 이유

샌드박싱 (Sandboxing) — Docker Sandboxes, MicroVMs, gVisor, 세션별 격리 (per-session isolation) — 는 에이전트가 도달할 수 있는 범위를 제한합니다. 샌드박싱된 에이전트는 호스트 파일 시스템에 접근할 수 없고, 권한이 부여되지 않은 운영 네트워크에 도달할 수 없으며, 자신의 MicroVM을 탈출할 수 없습니다. 이는 필수적이며 반드시 실행해야 하는 사항입니다.

하지만 샌드박싱은 '도달 범위'에 관한 것이지 '판단'에 관한 것이 아닙니다. 스테이징 데이터베이스에 대한 정당한 접근 권한을 가진 샌드박싱된 에이전트라 할지라도, 여전히 해당 데이터베이스에 대해 파괴적인 쿼리를 실행할 수 있습니다. 샌드박스는 "이 데이터베이스에 도달해도 좋습니다"라고 말했을 뿐, "이 테이블을 삭제해서는 안 됩니다"라고 말하지 않았기 때문입니다.

RBAC (역할 기반 액세스 제어)와 최소 권한 토큰 (least-privilege tokens)은 에이전트가 보유한 자격 증명의 범위를 제한합니다. 토큰의 범위를 최소한으로 설정하십시오. 토큰을 교체(Rotate)하십시오. 환경별로 격리하십시오. 이 또한 필수적이지만, 승인 단계는 아닙니다. 당신이 부여한 권한 내에서 — 에이전트가 업무를 수행할 수 있도록 충분한 권한을 부여해야 합니다 — 에이전트는 재량권을 가집니다. "스테이징에 배포 가능"으로 범위가 지정된 토큰이라 할지라도, 에이전트는 새벽 3시에 스테이징에 고장 난 빌드를 배포할 수 있게 합니다.

승인 단계는 세 번째 계층에 존재했습니다. 에이전트가 여기에 도달할 수 있는지, 혹은 여기에 대한 자격 증명을 가지고 있는지의 문제가 아니라, 에이전트가 '지금 이 특정 행동을 취하는 것이 허용되는가'의 문제입니다. 그것이 바로 당신이 제거한 계층입니다. 표준적인 샌드박스 및 RBAC 스택의 그 어떤 것도 그 계층을 다시 채워 넣지 못합니다.

arXiv 논문이 지적하는 공백

이번 달 arXiv에 발표된 논문인 "From Assistance to Agency: Rethinking Autonomy and Control in CI/CD Pipelines" (arXiv 2605.07062)는 제가 본 것 중 이 문제를 가장 명확하게 설명하고 있습니다. 논문의 핵심 주장은 다음과 같습니다:

제어 평면(control-plane)의 권한을 제한할 수 있는 거버넌스 메커니즘이 없다면, 더 넓은 자율성 위임은 CI/CD가 강제하도록 설계된 릴리스 규율(release discipline)을 훼손할 위험이 있다.

이 논문은 제어 평면의 안전성을 에이전트 기반(agentic) CI/CD를 위한 선결 필수 조건으로 다룹니다.

해결책: 결정론적 제어 평면 경계 (a deterministic control-plane bound)

이를 해결하기 위해 더 똑똑한 에이전트가 필요한 것은 아닙니다. 당신에게 필요한 것은 결정론적인 단계, 즉 사람이 깨어 있을 필요가 없는 승인 게이트(approval gate)입니다.

사전 동작 게이트(Pre-action gate)는 에이전트가 새벽 3시에 어떤 추론을 하든 상관없이, 사전에 선언된 금지 카테고리(force-push, 파괴적인 마이그레이션(destructive migrations), env-file 쓰기)를 거부합니다. 결정 과정에 모델은 개입하지 않으며, 사람도 필요하지 않습니다.

기존에 실행 중인 요소들과의 결합 방식

이것은 심층 방어(defense-in-depth)에 관한 이야기입니다:

샌드박스 (Sandbox) → 도달 범위(reach)를 제한
RBAC (Role-Based Access Control) → 자격 증명(credentials)을 제한
사전 동작 게이트 (Pre-action gate) → 도달 범위 내에서 허용된 동작(permitted action)을 제한

하나의 구현체로서의 ThumbGate

저는 오픈 소스 사전 동작 게이트 엔진인 ThumbGate를 유지 관리하고 있습니다. MIT 라이선스이며, 로컬 우선(local-first) 방식이고, 강제 집행 경로(enforcement path)에서 LLM 호출이 전혀 없습니다. 이는 파이프라인 내에서 실행되며 Claude Code, Cursor, Codex, Gemini CLI 및 기타 에이전트 런타임(agent runtimes)에 연결됩니다.

npx thumbgate init

승인 단계는 사람이 제거되었다고 해서 필요성이 사라진 것이 아닙니다. 단지 그 단계를 담당할 인력이 사라진 것뿐입니다. 새벽 3시가 당신 대신 일을 처리하기 전에, 결정론적인(deterministic) 버전을 연결하십시오.

Repo: https://github.com/IgorGanapolsky/ThumbGate