AI 에이전트 비용 누수의 시작: 유료 폴백이 기본 경로가 된 날

AI 에이전트 비용 누수: 기록으로 재구성한 장애

비용을 키운 원인은 이례적으로 큰 모델 호출이 아니었습니다. 차단된 파일 전달 때문에, 애초에 기본 작업을 맡아서는 안 될 종량제 폴백이 그 일을 떠안았습니다.

2026-09-18 → 09-19 동안 자율 게시 에이전트 2개가 대체로 같은 방식으로 움직였습니다. 샌드박스에 격리된 작성 에이전트가 글을 만들고, 사이트가 이를 게시하는 구조였습니다. 그중 1개는 새 서버에서 다시 시작된 상태였습니다. 이 에이전트는 12시간 동안 글 18편을 게시했는데, 18개 페이로드 모두 이미지 설명은 담고 있었지만 실제 이미지 파일은 0개였습니다.

사이트는 이 설명을 이미지 생성 요청으로 처리했습니다. 유료 이미지 모델을 통해 커버 18개와 본문 이미지 약 26개를 만들었고, 글 1편당 비용은 약 $0.45였습니다. 종량제 게이트웨이 잔액은 두 게시 시스템이 함께 쓰고 있었습니다. 이 잔액은 $8.30에서 01:15 UTC에 $0으로 떨어졌습니다.

이미지 수와 글당 비용은 근삿값이므로 그대로 근삿값으로 다뤄야 합니다. 이 수치만으로 공유 잔액의 사용 내역을 정확히 역산할 수는 없습니다. 결과물 누락 수치 2개도 서로 별개의 관찰 결과입니다. 이를 합쳐 영향을 받은 고유 글의 수를 계산할 근거는 없습니다.

증거가 가리키는 곳은 업로드 경계입니다

페이로드와 저널, 잔액 기록은 모두 같은 단절 지점을 가리킵니다. 작성 에이전트는 이미지를 설명할 수 있었지만, 이미지 파일을 전달하지는 못했습니다.

• 18개 페이로드 모두 장면 설명은 있었고 이미지 파일은 0개였습니다. 이는 사소한 렌더링 품질 문제가 아닙니다. 아티팩트가 게시 경계를 아예 넘지 못했다는 뜻입니다.
• 한 저널에는 이미지 툴이 10번 언급됐지만 다른 저널에는 0번 언급됐습니다. 두 에이전트는 같은 CLI 버전과 같은 툴, 같은 플래그를 사용했습니다. 기능 자체는 존재했지만 두 번째 작성 에이전트가 도달할 수 있는 경로에는 포함되지 않았다는 차이입니다.
• 사이트가 설명을 유료 이미지로 바꾸는 동안 공유 잔액은 $8.30에서 01:15 UTC에 $0으로 줄었습니다. 결제 경로가 멈추자 두 게시 시스템에서 커버와 임베딩이 사라졌습니다.

이 사고가 게시 시스템 밖에서도 중요한 이유가 여기에 있습니다. 에이전트 비용을 말할 때는 흔히 모델 선택, 토큰 사용량, 재시도 횟수부터 떠올립니다. 하지만 이번 비용은 그보다 한 단계 앞에서 발생했습니다. 파일을 만든 프로세스와 업로드에 필요한 자격 증명을 보안 경계가 갈라놓은 지점이었습니다.

안전한 샌드박스가 유료 경로만 남긴 과정

사이트 키를 샌드박스의 작성 에이전트에 주지 않은 판단은 옳았습니다. 문제는 키가 꼭 필요한 업로드 단계를 여전히 그 에이전트의 워크플로 안에 둔 아키텍처였습니다.

샌드박스는 에이전트가 접근하고 변경할 수 있는 범위를 제한합니다. 이 사례에서 작성 에이전트의 셸은 사이트 키를 받을 수 없었습니다. 이미지 업로드 단계에는 그 키가 필요했으므로, 렌더링된 파일을 저장소까지 직접 보내는 경로는 샌드박스 안에서 도달할 수 없었습니다.

그런데 페이로드는 커버 장면과 본문 이미지 장면 설명을 계속 받을 수 있었습니다. 폴백은 우선 경로가 완료되지 못할 때 쓰는 대체 경로입니다. 설명만 있고 파일은 없는 페이로드가 도착하자, 사이트는 종량제 게이트웨이로 이미지를 생성했습니다. 대체 경로가 아무도 결정하지 않은 사이 사실상 유일한 경로가 된 셈입니다.

다른 에이전트는 도달 가능한 별도 경로를 택했습니다. 구독에 포함된 이미지 툴로 파일을 렌더링하고 직접 업로드했습니다. 여기서 "구독에 포함됐다"는 말은 구독이 무료였다는 뜻이 아닙니다. 단지 해당 작업에서는 누락된 이미지마다 이번 사고의 별도 종량제 폴백을 거치지 않았다는 의미입니다.

해법은 샌드박스를 약화하는 것이 아닙니다. 자격 증명이 필요한 작업을 경계 밖의 신뢰할 수 있는 영역에 배치해야 합니다. AI 에이전트 코드 샌드박스를 신중히 고르는 일도 중요하지만, 어떤 샌드박스 제품도 작성 에이전트에게 도달 불가능한 자격 증명 단계를 맡긴 워크플로까지 고쳐 주지는 못합니다.

왜 done은 잘못된 상태였나

결제 오류가 발생했다면 작업 결과도 달라졌어야 합니다. 하지만 402는 소프트 실패로 처리됐습니다. 시스템이 오류를 기록하거나 허용한 채 작업을 중단하지 않고 계속했다는 뜻입니다.

그 결정으로 작업 완료와 결과물 완료가 분리됐습니다. 글 본문은 게시할 수 있었기 때문에, 필수 커버나 임베딩이 없어도 작업은 done을 보고했습니다.

임베딩은 이 시스템이 내부 링크와 검색에 활용할 관련 콘텐츠를 찾도록, 콘텐츠를 표현해 저장한 값입니다. 커버 누락은 페이지에서 바로 보입니다. 임베딩 누락은 훨씬 조용합니다. 글은 존재하지만 이를 발견하고 연결하는 시스템에서는 빠질 수 있습니다. 그래서 글 5편이 임베딩 없이 게시됐는데도 최종 상태에는 결함이 드러나지 않았습니다.

올바른 완료 계약은 단순합니다. 워크플로가 필수로 정의한 결과물이 모두 존재하기 전에는 작업이 끝난 것이 아닙니다. 커버가 필수라면 커버를 확인하고, 임베딩이 필수라면 임베딩을 확인해야 합니다. 데이터베이스에 텍스트 행 하나가 생겼다는 사실만으로 게시 작업 완료를 증명할 수는 없습니다.

구축자·운영자·구매자가 각각 봐야 할 것

같은 사고라도 역할에 따라 내려야 할 결정은 3가지로 달라집니다.

구축자: 샌드박스뿐 아니라 전달 과정까지 설계해야 합니다

구축자는 자격 증명 경계를 그리고, 그 경계를 넘는 모든 단계에 담당자를 지정해야 합니다. "작성 에이전트는 키를 받을 수 없다"는 보안 규칙입니다. 그 옆에 "작성 에이전트가 그 키로 업로드한다"는 워크플로 요구사항을 그대로 둘 수는 없습니다.

모든 에이전트 시스템이 맞닥뜨리는 벽은 생성된 의도와 외부 부수 효과 사이의 경계입니다. 설명 작성은 의도입니다. 이미지 저장, 종량제 공급자 과금, 글 게시는 부수 효과입니다. 각각에는 신뢰할 수 있는 명시적 담당자, 관측 가능한 결과, 그리고 상위 작업까지 전달되는 실패 상태가 필요합니다.

운영자: 여러 제품이 공유하는 의존성을 감시해야 합니다

공유 종량제 잔액은 사소한 공급자 설정이 아니라 공용 인프라로 다뤄야 합니다. 이 사고에서는 두 게시 시스템의 커버, 본문 이미지, 임베딩이 같은 잔액에 의존했습니다. 그 결과 한 작성 에이전트의 폴백 동작이 다른 게시 시스템의 안정성까지 바꿨습니다.

AI 에이전트 API 예산 통제로 지출을 제한할 수는 있지만, 한도를 둔다고 아티팩트 경로까지 올바르게 바뀌지는 않습니다. 공유 퓨즈에 이름을 붙이고, 상태 알림을 설정하며, 잔액 소진 사실을 이에 의존하는 모든 워크플로에 보여 줘야 합니다. 원본 기록에는 알림 임계값이나 수정 후 측정치가 없으므로, 여기서 임의로 만들어 내서는 안 됩니다.

구매자: 정상 경로가 깨진 뒤를 물어야 합니다

구매자는 폴백이 종량제인지, 어떤 제품들이 그 예산을 공유하는지, 폴백이 결제하지 못하면 작업이 어떤 상태를 보고하는지 확인해야 합니다. 한 번 정상 완료된 데모만으로는 이 질문에 답할 수 없습니다.

유용한 계약에는 필수 결과물, 자격 증명 보유 주체, 유료 폴백, 결과물 누락 시 반환할 상태가 명시돼야 합니다. 비용을 쓰거나 불완전한 결과를 게시할 수 있는 재시도에는 AI 에이전트 재시도에 대한 사람의 승인도 또 하나의 통제 수단입니다. 이는 아티팩트 계약을 보완하지만 대체하지는 않습니다.

지금 조치할지, 기다릴지, 그대로 둘지

샌드박스의 작성 에이전트가 설명은 제출하지만 그 설명을 대체할 파일을 스테이징할 수 없거나, 여러 제품이 같은 유료 의존성을 공유하거나, 실패한 폴백인데도 done으로 끝날 수 있다면 지금 조치해야 합니다. 현재 로그만으로 저장된 파일이 경계를 넘는다는 사실과 필수 결과물 누락 시 이미 성공을 차단한다는 사실을 입증할 수 있을 때만 재설계를 미뤄도 됩니다. 필수 게시 결과물이 직접적으로든 폴백 생성을 통해서든 해당 잔액에 의존하지 않는 워크플로라면, 이 특정 공유 잔액 장애의 영향은 받지 않습니다.

과장된 믿음: 폴백이 많다고 복원력이 높아지지는 않습니다

작업을 계속 진행시킨다는 이유만으로 폴백이 곧 복원력인 것은 아닙니다. 비용과 의존성, 결과물 품질, 실패 상태를 모두 이해할 때만 복원력 있는 폴백이라고 할 수 있습니다.

이 사례의 폴백은 잔액이 남아 있는 동안 필요한 일을 해냈습니다. 동시에 기본 업로드 경로에 도달할 수 없다는 사실도 감췄습니다. 겉으로 보이는 가용성이 경계 오류를 드러낼 신호를 늦춘다는 점에서 위험한 조합입니다.

공급자를 하나 더 추가해도 핵심 문제는 해결되지 않습니다. 필수 아티팩트와 done이 계속 분리된 상태에서 비용 청구서와 소프트 오류만 하나씩 늘어날 수 있습니다. 엔지니어링 목표는 대체 경로를 최대한 많이 모으는 것이 아닙니다. 에이전트가 실제로 도달할 수 있는 기본 경로, 그리고 유료임이 분명하고 큰 소리로 실패할 수 있는 폴백을 만드는 것입니다.

AI 에이전트 운영 비용을 드러내는 엔지니어링 원칙

해결은 담당자를 분명히 하는 데서 시작하며, 비용과 완료 조건까지 명시해야 끝납니다.

자격 증명은 신뢰할 수 있는 프로세스에 둡니다

샌드박스의 작성 에이전트는 글과 페이로드, 그리고 자신이 렌더링할 수 있는 이미지 파일을 만들어야 합니다. 인증이 필요한 업로드는 샌드박스 밖의 신뢰할 수 있는 프로세스가 수행해야 합니다. 이렇게 해야 보안 경계에 키 모양의 구멍을 내지 않고 그대로 지킬 수 있습니다.

파일과 설명은 서로 다른 입력 유형으로 구분합니다

파일은 바로 쓸 수 있는 아티팩트입니다. 설명은 아티팩트를 만드는 레시피입니다. 둘을 같은 것으로 취급하면 비용과 실패 동작이 모두 가려집니다.

게시 계약은 스테이징된 파일을 우선해야 합니다. 설명은 출처와 복구 데이터로 계속 붙여 둡니다. 시스템이 이를 폴백 생성에 사용한다면, 해당 분기는 유료라고 명시하고 실제로 유료 경로가 실행됐다는 사실을 보고해야 합니다.

done을 필수 결과물과 묶습니다

상위 작업은 약속한 아티팩트가 준비될 때까지 기다려야 합니다. 커버나 임베딩 계약이 충족되지 않았다면, 결제 오류를 소프트 실패로 처리한 뒤 done으로 끝내서는 안 됩니다. 필수 결과물 검사는 피해를 보고할 수만 있는 사후 리포트가 아니라 최종 성공 상태에 들어가기 전에 수행해야 합니다.

의존성 상태와 작업 로그를 분리합니다

한 에이전트는 이미지 툴을 사용했고 다른 에이전트는 사용하지 않았다는 점을 보여 준 저널 비교는 가치 있는 신호였습니다. 이 신호는 유지해야 합니다. 그와 별도로, 공유 종량제 의존성의 상태도 이를 사용하는 모든 게시 시스템에 공개해야 합니다. 작업 로그는 한 작업자가 무엇을 시도했는지 답하고, 의존성 텔레메트리는 공유 경로가 여전히 누구에게든 서비스를 제공할 수 있는지 답합니다.

아래 코드는 운영 소스가 아니라 구조를 설명하기 위한 예시입니다. 담당자와 상태의 흐름만 보여 줍니다. 원본 자료에는 구현 세부 정보나 수정 후 측정 결과가 없으므로 여기서도 제시하지 않습니다.

// Illustrative only. This is not production source.
const handoff = {
  payload: writerOutput.payload,
  pictureFiles: writerOutput.pictureFiles,
  pictureDescriptions: writerOutput.pictureDescriptions,
};

const stagedFiles = await trustedProcess.stage(
  handoff.pictureFiles,
  "presigned PUT",
);

const fallbackRender = stagedFiles.complete
  ? null
  : await paidFallback(handoff.pictureDescriptions);

if (fallbackRender?.status === 402) {
  failJob("Paid fallback unavailable");
}

const publishableArtifacts = mergeArtifacts(
  stagedFiles,
  fallbackRender,
);

const rewrittenPayload = rewritePictureReferences(
  handoff.payload,
  publishableArtifacts,
);

rewrittenPayload.pictureDescriptions = handoff.pictureDescriptions;

assertRequiredArtifacts(rewrittenPayload);
markDone();

핵심은 순서입니다. 작성 에이전트는 사이트 자격 증명을 받지 않고 파일을 만들고, 신뢰할 수 있는 프로세스가 파일을 스테이징하며, 페이로드는 저장된 아티팩트를 가리킵니다. 검증된 완료 상태만 done이 될 수 있습니다.

비용 누수를 막는 아티팩트 전달 방식

지속 가능한 해결책은 두 부분으로 이뤄진 전달 과정입니다. 작성 에이전트가 렌더링하고, 신뢰할 수 있는 주체가 스테이징합니다.

작성 에이전트는 이미 만들 수 있도록 허용된 출력 안에서 이미지 파일을 페이로드 옆에 배치합니다. 샌드박스 밖의 신뢰할 수 있는 프로세스가 이 파일을 받아, 해당 전달 작업에 권한을 부여한 업로드 방식인 presigned PUT으로 전송합니다. 제공된 기록에는 만료 시간이나 권한이 정의돼 있지 않으므로, 이런 세부 사항은 사실 주장으로 다루지 않고 구현 선택지로 남겨 둡니다.

스테이징이 끝나면 신뢰할 수 있는 프로세스가 페이로드를 다시 작성해 이미지 참조가 저장된 파일을 가리키게 합니다. 이제 사이트는 생성 지시가 아니라 아티팩트를 받습니다. 작성 에이전트는 사이트 키를 받지 않으며, 게시 경로도 키를 받은 척하는 전제에 더 이상 의존하지 않습니다.

설명은 페이로드에 그대로 남습니다. 작성 에이전트가 이미지를 렌더링할 수 없을 때 쓸 복구 기록이자 유료 폴백입니다. 따라서 폴백에는 여전히 비용이 들 수 있습니다. 이 수정은 폴백을 없애거나 측정된 절감 효과를 주장하지 않습니다. 파일 스테이징을 다시 도달 가능한 기본 경로로 만들고, 유료 생성을 조건부 경로로 되돌립니다.

월요일에 바로 할 일

자격 증명이 필요한 필수 단계를 모두 추적합니다. 작성 에이전트가 그 자격 증명을 보유할 수 없다면, 해당 작업을 신뢰할 수 있는 프로세스로 옮기고 둘 사이의 아티팩트 전달 방식을 정의합니다. 그런 다음 최종 작업 상태가 필수 커버, 임베딩, 저장된 파일 참조에 따라 결정되도록 만듭니다. 설명은 파일 옆에 보존하되, 설명이 실행하는 경로에는 정확한 이름을 붙여야 합니다. 바로 유료 폴백입니다.

자주 묻는 질문

뉴스레터에서 다음 운영 장애 분석을 받아보세요.