에이전트가 코드를 생성하는 단계는 이미 지났다. 지금 현장에서 실제로 벌어지는 일은 에이전트가 인보이스를 만들고, 클라우드 인스턴스를 종료하고, 배포 파이프라인을 트리거하는 것이다. '쓰기 권한을 가진 에이전트'는 더 이상 미래 시나리오가 아니다. 그리고 바로 이 지점에서 팀이 아무것도 설계하지 않았다는 사실이 가장 비싸게 드러난다.
세 개의 독립적인 기술 사례가 동시에 같은 결론을 가리키고 있다. MCP 서버에서 멱등성 없이 에이전트 쓰기 작업을 열어둔 경우, AI 빌더가 regex 기반 완료 판정으로 실제 렌더링 실패를 성공으로 처리한 경우, 그리고 클라우드 IAM에서 최소 권한 원칙이 지켜지지 않은 채 에이전트에게 AdministratorAccess를 부여한 경우. 각각 다른 문제처럼 보이지만, 에이전트가 '실제 쓰기 작업을 수행하는 순간'에 설계가 없으면 어떤 일이 생기는지를 보여주는 동일한 패턴이다.
레이어 1. 멱등성 — 에이전트는 재시도를 '당연히' 한다
분산 시스템 엔지니어라면 익숙한 개념이지만, 에이전트 환경에서는 그 전제 자체가 달라진다. dev.to의 Frihet MCP 사례가 정확하게 짚고 있다. 사람이 버튼을 두 번 누르는 건 예외 상황이지만, 에이전트는 구조적으로 재시도한다. 429 응답에 지수 백오프를 적용하고, 세션이 타임아웃되면 플래너가 '아직 실행 안 된 것'으로 판단해 같은 작업을 다시 실행한다. 병렬 팬아웃 상황에서는 두 개의 에이전트 호출이 동일한 쓰기 작업을 동시에 실행한다.
MCP 프로토콜 자체는 이 문제를 해결하지 않는다. create_invoice를 두 번 호출하면 인보이스가 두 개 생기는지 하나만 생기는지—그건 전적으로 서버 설계자의 몫이다. 설계하지 않으면 답은 '두 개'다. 세금 신고 도메인에서 팬텀 인보이스가 하나 더 생기는 건 버그가 아니라 법적 리스크다.
실전 설계 포인트는 단순하다. 클라이언트가 요청 생성 시점에 멱등성 키(UUID)를 한 번만 발급하고, 재시도 전체에서 동일한 키를 유지한다. 서버는 이 키를 원자적으로 클레임(Postgres의 INSERT ... ON CONFLICT DO NOTHING)하고, 이미 처리된 키라면 동일한 결과를 반환한다. 핵심은 두 가지다. 키는 테넌트 단위로 스코프해야 한다(글로벌 스코프면 다른 고객의 요청 결과가 반환될 수 있다). 그리고 페이로드 핑거프린트를 함께 저장해, 같은 키로 다른 내용이 들어오면 클라이언트 버그로 명시적으로 거부해야 한다.
레이어 2. 검증 로직 — '완료'의 정의를 다시 써라
Zugo의 사례는 AI 빌더 팀이 스스로 공개한 실수인데, 읽으면서 불편한 이유는 이게 낯선 실수가 아니기 때문이다. 성공 판정 기준이 </html> 태그 존재 여부였다. 스트림이 끝나면 초록 체크가 뜨고, 크레딧이 차감됐다. 실제로 페이지가 열리는지는 그 시점에 아무도 보지 않았다.
이건 단순히 Zugo만의 문제가 아니다. AI 에이전트가 '작업 완료'를 판정하는 시점과 실제 효과가 발생하는 시점 사이의 간극이 바로 리스크 구간이다. 태그 밸런스 체크는 렌더링 실패를 잡지 못한다. 스트림 종료는 코드 실행 성공을 보장하지 않는다. 그리고 Zugo가 측정한 결과, 이 간극은 사이트 기준 2.6초, React 앱 기준 6.2초였다. 그 12초 동안 사용자는 초록 체크와 빈 흰 화면을 함께 봤다.
해결 방향은 세 가지 질문으로 정리된다. 지금 팀의 성공 신호가 실제로 무엇을 관찰하는가(이름이 아니라 실제 관찰 대상). 비가역적인 행위—청구, 배포, 데이터 변경—가 실제 검증 결과 도착 전에 실행되는가. 그리고 실패 판정이 이후의 조용한 신호에 의해 성공으로 뒤집힐 수 있는가. Zugo가 도입한 원칙 중 가장 실용적인 건 마지막 것이다. 한 번 실패로 판정된 빌드는 어떤 후속 신호도 성공으로 뒤집을 수 없다. 검증 로직의 단방향성.
레이어 3. 최소 권한 — 에이전트는 습관이 없다
Microsoft의 2024 멀티클라우드 리스크 보고서는 숫자 두 개로 상황을 설명한다. 2023년, 전체 클라우드 자격증명의 2%만 실제로 사용됐다. 그리고 50% 이상의 클라우드 아이덴티티가 모든 권한과 모든 리소스에 접근할 수 있었다. 사람에게 이건 위험한 설정이지만 '대부분 쓰지 않는' 상태였다. 에이전트에게는 다르다.
사람은 런북 밖으로 잘 나가지 않는다. 파괴적인 명령 앞에서 망설이고, 습관적으로 좁은 범위만 쓴다. 에이전트에게는 그 습관이 없다. AdministratorAccess를 주고 목표를 주면, 에이전트의 실제 행동 공간은 런북이 아니라 부여된 권한 전체다. 에이전트가 권한을 확장한 게 아니다. 부여된 권한과 실제로 쓰인 권한 사이의 간극을 닫은 것이다.
'인간 승인'을 루프에 넣겠다는 설계도 절반짜리다. AWS의 aws:MultiFactorAuthAge 조건 키로 MFA 완료 후 5분 이내에만 파괴적 작업을 허용하는 정책은 이미 구현 가능하다. 문제는 세션 인증이 액션 인가를 보장하지 않는다는 점이다. MFA를 완료한 에이전트는 그 세션 동안 '당신의 동의 토큰'을 들고 다닌다. 유럽 결제 규제(EU 2018/389)가 동적 링킹으로 해결한 문제—인증 코드가 특정 금액과 특정 수취인에 묶여 있어야 한다는 원칙—를 에이전트 설계에 적용하면, 세션이 아니라 개별 액션 단위로 승인해야 한다. 클라우드 IAM은 아직 이걸 지원하지 않는다. 이건 해결된 문제가 아니다.
설계 우선순위는 실행 순서와 같다
세 레이어는 독립적으로 작동하지만 우선순위는 명확하다. 멱등성이 없으면 재시도가 데이터를 망친다. 검증 로직이 없으면 에이전트가 '완료'라고 판정한 작업이 실제로는 실패한 상태다. 최소 권한이 없으면 에이전트의 실수 하나가 시스템 전체에 닿는다. 세 가지 중 하나라도 빠지면 나머지 둘이 커버할 수 없다.
에이전트가 단순 코드 생성 도구에서 실제 시스템 변경자로 전환하는 지금이 이 설계를 가장 싸게 할 수 있는 마지막 시점이다. 사고가 나고 나서 멱등성을 추가하고, 권한을 조이고, 검증 로직을 보완하는 건 코드 수정 문제가 아니라 신뢰 복구 문제다. 팀이 에이전트를 얼마나 빠르게 배포하느냐보다, 에이전트가 실제 쓰기 작업을 수행하는 순간을 얼마나 설계해뒀느냐가 지금부터의 AI-First 팀을 가르는 기준이 될 것이다.