AI 에이전트가 코드를 배포하기 전에 인간의 승인을 추가하세요 — 배포 호출 자체를 차단하고, diff(차이점)와 롤백 계획을 검토하며, 잘못된 배포가 배포되기 전에 중단하십시오.

"테스트 실행"이 "배포 안전"과 같지 않은 이유

PR(Pull Request)을 생성하고, CI(지속적 통합) 실패를 수정하며, 테스트 통과 시 머지(Merge)를 수행하는 코딩 에이전트는 이제 흔합니다. 다음 단계인 — 머지가 완료된 후 동일한 에이전트가 배포를 트리거하도록 허용하는 것 — 단계에서 팀들이 긴장하는 데에는 타당한 이유가 있습니다. 통과된 테스트는 코드가 테스트 스위트가 확인한 대로 작동한다는 것을 확인해 줍니다. 하지만 이것이 스키마 마이그레이션(Schema Migration)을 배포하기에 적절한 주간인지, 변경 사항이 현재 장애가 발생 중인 서비스에 영향을 미치는지, 또는 에이전트가 불안정한 테스트(Flaky test)를 수정한 결과가 하류 API(Downstream API)를 압박하는 재시도 루프(Retry loop)를 조용히 확장시켰는지에 대해서는 아무것도 말해주지 않습니다. 사람이 diff와 대상 환경을 10초 동안 훑어보는 것만으로도 테스트 스위트가 구조적으로 잡아낼 수 없는 것들을 포착할 수 있습니다.

에이전트의 프롬프트(Prompt)에 "배포 전 확인" 지침을 끼워 넣는 것은 다른 통제되지 않은 작업들이 겪는 것과 동일한 실패 모드에서 버티지 못합니다. 그것은 게이트(Gate, 관문)가 아니라 제안일 뿐이며, 벽처럼 쌓인 CI 로그를 추론하는 에이전트는 스스로 그 제안을 무시하고 넘어갈 수 있습니다. 실제로 효과가 있는 방법은 외부의 결정이 내려질 때까지 배포 호출 자체를 도달할 수 없게 만드는 것입니다.

머지가 아닌 배포 호출을 차단하기

실제로 배포를 수행하는 파이프라인 단계 이전에 배포를 하나의 액션으로 밀어 넣은 다음, 결정 단계에서 차단하십시오. 다음은 Kubernetes 롤아웃(Rollout)을 트리거하는 서비스에 대한 Go 언어 패턴입니다:

package main

import (
...

여기에 editable 필드가 없다는 점에 주목하십시오. 소셜 포스트나 이메일 초안은 검토자가 인라인(Inline)으로 합리적으로 수정할 수 있는 텍스트이지만, 배포 계획은 그렇지 않습니다. 검토자가 어떤 커밋을 배포할지 직접 편집하기를 원치 않기 때문입니다. 결정은 이진적(Binary)입니다: 정확히 이 diff를 정확히 이 환경에 배포할 것인가, 아니면 하지 않을 것인가.

승인 카드에 포함되어야 할 내용

휴대폰 알림을 통해 배포를 승인하는 검토자(reviewer)는 클릭 없이도 세 가지 사항을 알 수 있어야 합니다: 어떤 환경(environment)인지, 어떤 커밋(commit)인지, 그리고 마이그레이션(migration)이 포함되어 있는지 여부입니다 (마이그레이션은 이전 이미지를 재배포하는 것만으로는 롤백(rollback)할 수 없는 유일한 유형의 배포입니다). 그 외의 모든 것 — 전체 diff, 테스트 결과, 영향을 받는 서비스 등 — 은 미리보기 본문에 쑤셔 넣는 것이 아니라, CI 실행으로 연결되는 target_url 링크 뒤에 배치해야 합니다.

스테이징(Staging) 대 운영(production)

모든 환경에 동일한 게이트(gate)가 필요하지는 않습니다. 합리적인 기본 설정은 다음과 같습니다:

거절됨(Rejected), 만료됨(expired), 그리고 롤백(rollback)

rejected와 expired는 모두 exec.Command가 실행되지 않음을 의미하며, 이는 게이트가 있는 모든 작업과 동일한 규칙입니다. expires_in을 배포 가능 시간(deploy window)을 넘겨 승인이 방치되지 않을 만큼 충분히 짧게 설정하십시오. 세 개의 커밋이 추가로 머지(merge)된 후 이틀 뒤에 승인된 운영(production) 배포는, 검토자가 처음에 확인했던 그 배포와 동일한 것이 아닙니다. 코드를 여전히 배포해야 한다면, 오래된 승인을 되살리기보다는 현재 커밋에 대해 새로운 액션(action)을 푸시하십시오.

Impri가 여기서 하고 있지 않은 것

Impri는 배포 요청을 저장하고, 사람에게 알림을 보내며, 결정을 보류합니다. Impri 자체가 kubectl apply를 실행하거나, 귀하의 테스트가 신뢰할 수 있는지 여부를 알거나, 차이점(diff)이 실제로 안전한지 평가하지는 않습니다. 그 판단은 휴대폰을 들고 있는 사람의 몫으로 남습니다. 이 기능의 기반이 되는 기본 3단계 호출 패턴(base three-call pattern)에 대해서는 AI 에이전트에 인간 승인을 추가하는 방법을 참조하십시오. 만약 머지(merging)를 수행하는 에이전트가 Claude Agent SDK에서 실행된다면, 동일한 프로세스 내에 게이트(gate)를 연결하는 방법에 대해 해당 통합 가이드를 참조하십시오. 배포에 게이트를 설정하고 나면, 감사 로그 (audit log)를 통해 모든 프로덕션 롤아웃(production rollout) 내역, 승인자, 승인 시점에 대한 기록을 확인할 수 있습니다. 이는 나중에 누군가 "누가 이걸 배포했나요?"라고 물을 때 유용합니다.

다음 단계: 퀵스타트 (quickstart)를 통해 API 키를 발급받고, 먼저 스테이징 파이프라인(staging pipeline)을 대상으로 테스트해 보십시오.