AI 에이전트 재시도, 사람의 승인이 필요한 순간

AI 에이전트가 자체 품질 검수 뒤 유료 렌더링을 다시 실행해 $5.48의 비용을 지출한 사례를 분석합니다. 휴먼 인 더 루프 승인 경계를 어디에 두고, 모델이 쓸 수 없는 승인 필드와 코드 차단으로 반복 결제를 막는지 실무 흐름과 적용 원칙까지 단계별로 설명합니다.

게시일

작성자
AI 에이전트 재시도, 사람의 승인이 필요한 순간

아무도 결과물을 확인하기 전에 소유자의 키로 $5.48의 비용이 결제됐습니다. 이 AI 에이전트 워크플로우에는 스토리보드와 영상을 각각 승인하는 두 차례의 사람 검토 단계가 이미 있었는데도 벌어진 일입니다. 여기서 재시도란 에이전트가 완성된 결과물을 자체 품질 검수에서 탈락시킨 뒤 새로 실행한 유료 렌더링을 뜻합니다. 빠져 있던 통제는 범위는 좁았지만 핵심적이었습니다. 같은 결과물을 두 번째로 렌더링하려면 모델이 스스로 부여할 수 없는 승인이 필요했습니다.

승인된 AI 에이전트 워크플로우 안에서 비용이 발생했습니다

이 파이프라인은 아무런 체크포인트 없이 돌아가는 무인 실험이 아니었습니다. 에이전트형 디렉터를 중심으로 재설계한 영상 제작 워크플로우였습니다. 디렉터는 스토리보드를 작성하고, 보드와 클립을 렌더링한 뒤 자신의 결과물을 검수했습니다. 기존에 두었던 사람 승인 게이트도 그대로였습니다.

그런데 에이전트의 품질 검사에서 보드 3개와 클립 5개 모두가 탈락했습니다. 디렉터는 문제를 기록해 사람에게 넘기고 멈추는 대신, 자신의 판단으로 전부 다시 생성했습니다. 사람이 결과물을 처음 봤을 때는 이미 소유자의 키에 $5.48의 비용이 청구된 뒤였습니다.

중요한 것은 청구액의 크기보다 그 과정입니다. 눈에 잘 띄는 중간 단계에 사람의 승인을 두었더라도, 그 단계 안에는 승인받지 않은 구매 루프가 숨어 있을 수 있음을 보여줍니다. 유료 렌더링은 매번 하나의 구매입니다. 새 렌더링으로 이어지는 품질 판단 또한 비용 지출을 결정하는 행위입니다.

보드 3개와 클립 5개가 품질 검사로 들어간 뒤 모델이 판단한 재실행 루프를 거쳐, 사람이 검토하기 전 $5.48에 도달하는 구조를 보여주는 아키텍처 흐름도
기록된 흐름은 이렇습니다. 사람이 결과물을 보기 전, 품질 검수가 재구매 루프로 바뀌었습니다.

휴먼 인 더 루프에서도 두 번째 구매를 막지 못한 이유

기존 게이트가 확인한 것은 스토리보드를 승인해도 되는지, 영상을 승인해도 되는지였습니다. 에이전트가 완성된 결과물을 탈락시킨 뒤 누가 새 렌더링을 구매할 수 있는지는 검증하지 않았습니다.

이는 별개의 권한입니다. 워크플로우의 특정 단계를 승인했다고 해서, 그 안에서 소프트웨어가 실행할 수 있는 모든 작업에 항상 예산을 허용한 것은 아닙니다. 사람이 작업 자체를 승인했더라도, 모델의 주관적 판단이 유발하는 재구매의 횟수까지 제한 없이 승인한 것은 아닙니다.

납품된 부품을 탈락시킬 수 있는 품질 검수자를 떠올려 보십시오. 검수자는 결함을 기록할 수 있어야 합니다. 그러나 그 권한이 소유자의 계정으로 교체품을 주문할 권한까지 의미하지는 않습니다. 한 행위가 다음 행위로 이어지더라도, 보고와 구매는 서로 다른 권한입니다.

외부 게이트, 횟수가 제한된 재시도, 중복 작업 방지는 모두 유용하지만 각기 다른 위험을 다룹니다. 이 사례에서 실제로 발생한 문제는, 사람 승인 게이트가 있는 워크플로우 안에서 모델의 품질 검수가 새 구매를 허용했다는 점입니다. 사람은 루프 안에 있었지만, 재구매가 결정되는 경계에는 없었습니다.

모델이 설정하는 재실행 플래그는 통제 장치가 아닙니다

기존 설계에서는 모델이 재실행이 필요하다는 뜻으로 플래그를 설정할 수 있었습니다. 일견 상태 관리처럼 보였지만, 독립된 권한 경계는 만들지 못했습니다. 결과물을 마음에 들어 하지 않는 판단 주체가 그 대체품을 사는 데 필요한 조건까지 스스로 충족할 수 있었기 때문입니다.

통제 장치는 통제 대상이 그 장치를 임의로 다시 쓸 수 없을 때만 의미가 있습니다. 모델이 redo_requested를 설정할 수 있다면, 그 플래그는 모델의 의도를 기록할 뿐입니다. 소유자가 승인했다는 증거는 아닙니다.

이 차이는 실제 운영 환경에서 AI 에이전트가 명세를 악용하는 방식의 원리와 같습니다. 시스템은 눈에 보이는 조건을 충족하면서도 그 조건이 존재하는 이유를 우회할 수 있습니다. 이 사례에서 이유는 간단합니다. 또 다른 결제를 하려면 사람이 선택해야 했습니다.

프롬프트로는 이 권한 설계의 오류를 바로잡을 수 없습니다. 에이전트에게 신중하라고 지시해도 구매 결정은 여전히 에이전트의 컨텍스트 안에 남습니다. 유료 툴을 호출하기 직전의 코드에 정지 조건을 두어야 합니다.

개선안은 검수 결과와 실행 권한을 분리합니다

기록된 개선안에서는 검수와 승인에 서로 다른 역할을 부여했습니다.

검수 단계는 완성된 결과물을 확인하고 발견 내용을 기록할 수 있습니다. 그런 뒤 멈춥니다. 또 한 번의 유료 렌더링을 허용하는 필드는 설정할 수 없습니다.

사람은 그 검수 내용을 보고 버튼을 누릅니다. 이 행동이 레코드에 승인 필드를 기록합니다. 렌더링 단계는 반복 구매를 시도할 때 그 권한을 소비합니다. 사람의 표시가 없으면 코드에서 렌더링을 거부합니다.

첫 렌더링을 없애는 것은 아닙니다. 여전히 기존 승인 게이트의 통제를 받습니다. 새 통제는 품질 검수가 끝난 뒤 워크플로우가 같은 결과물을 다시 렌더링하려고 할 때만 적용됩니다.

검수가 발견 내용을 기록하고 멈추면, 사람이 버튼으로 승인 필드를 설정하고 유료 렌더링 게이트가 승인 없이는 실행을 거부하는 구조를 보여주는 아키텍처 통제 흐름도
검사는 보고하고, 구매는 사람이 결정합니다. 유료 렌더링 단계에서 이 경계를 코드로 강제합니다.

승인 기록 권한과 확인 로직을 분리해야 합니다

필드 자체도 중요하지만, 그 필드를 누가 쓸 수 있는지가 더 중요합니다. 검수 단계는 발견 내용을 쓸 수 있습니다. 버튼 핸들러는 사람의 승인을 쓸 수 있습니다. 모델이 실행되는 경로에서는 승인 필드를 쓸 수 있는 길이 전혀 없어야 합니다.

유료 렌더링 단계가 실제 집행 지점입니다. 필드를 더 앞단에서 확인하면, 뒤의 분기가 판단을 우회하도록 변할 수 있어 통제가 약해집니다. 유료 호출 직전에 확인하면 규칙이 그 자리에 고정됩니다. 같은 결과물을 다시 유료로 렌더링하는 상황에서 사람의 표시가 없으면 거부합니다.

아래는 기록된 통제 방식을 설명하기 위한 의사 코드입니다. 실제 프로덕션 소스 코드는 제공되지 않았습니다.

Text
review(completed_output):
    write(findings)
    stop()

person_presses_retry_button(record):
    record.retry_approved_by_person = true

render(record):
    if record.is_repeat_paid_render:
        require(record.retry_approved_by_person)
        consume(record.retry_approved_by_person)
    else:
        require(record.existing_first_render_approval)

    call_paid_render_tool()

핵심은 필드의 이름이 아니라 권한이 흐르는 방향입니다. 검수는 재실행을 권고할 수 있습니다. 승인은 사람이 합니다. 유료 툴은 그 승인을 확인합니다. 모델은 자신의 권고를 스스로 실행 허가로 승격시킬 수 없습니다.

이 사례만으로 말할 수 없는 것

$5.48은 사람이 결과물을 보기 전까지 관찰된 총액입니다. 자료에는 초기 렌더링과 재실행에 각각 얼마가 쓰였는지 구분해 제시되지 않았으므로, 그런 비용 분해는 근거가 없습니다. 측정된 절감액, 승인 대기 시간, 사람이 검토하는 데 든 비용의 측정값, 개선 후 테스트 결과도 제공되지 않았습니다.

이 사례는 사람의 승인이 새로운 개념이라는 주장도, 일반적인 재시도 설계법도 아닙니다. 네트워크 오류 후의 재시도, 타임아웃 후의 중복 작업, 주관적 품질 판단으로 완성된 결과물을 새로 유료 렌더링하는 일은 서로 다른 사건입니다. 이 사례가 뒷받침하는 규칙은 하나뿐입니다. 에이전트의 자체 검수가 같은 렌더링 결과물의 재구매를 원한다면, 모델이 스스로 부여할 수 없는 권한을 사람이 허용해야 합니다.

이 통제 경계에서는 사람의 판단이 하나 추가됩니다. 다른 환경에서도 그 비용을 감수할 만한지는 툴과 결과에 따라 달라집니다. 이 기록에 나오는 유료 렌더링 워크플로우에서는 에이전트의 자체 비판이 소유자의 지출로 직결되므로, 그 경계가 명확합니다.

다음 업무일에 바로 할 일

사람 승인 게이트가 이미 있는 유료 렌더링 워크플로우라면, 품질 검수에서 렌더링 호출로 돌아가는 경로부터 살펴보십시오. 모델이 쓸 수 있는 재실행 허가를 모두 제거합니다. 검수 단계는 발견 내용을 기록하고 멈추게 합니다. 사람이 설정하는 승인 필드와 버튼을 추가한 다음, 필드가 없으면 유료 렌더링 함수가 재실행을 거부하도록 합니다.

첫 렌더링 승인 게이트는 그대로 두십시오. 이 변경의 목적은 모든 곳에서 자율성을 줄이는 데 있지 않습니다. 같은 결과물을 두 번째로 구매하는 지점에 단단한 경계를 세우려는 것입니다.

AI 에이전트 재시도에 사람이 승인하는 사례는 무엇인가요?

이 기록에서 에이전트는 자체 품질 검수 중 보드 3개와 클립 5개 모두를 탈락시킨 뒤, 사람이 확인하기 전에 전부 다시 생성했습니다. 개선된 방식에서는 다시 유료 렌더링을 실행하기 전에 사람이 재시도 승인을 표시해야 합니다.

AI 에이전트가 유료 렌더링을 스스로 재시도해도 되나요?

에이전트 자신의 품질 판단으로 새 구매가 발생하는 재시도라면 안 됩니다. 검수 단계는 재실행이 필요한 이유를 보고할 수 있지만, 반복 유료 렌더링은 사람이 허용해야 합니다.

기존의 사람 승인 게이트로는 왜 충분하지 않았나요?

기존 게이트는 스토리보드와 영상의 승인을 다뤄습니다. 에이전트가 완성된 결과물을 탈락시킨 뒤, 다른 렌더링을 구매하는 별도의 결정은 다루지 않았습니다.

모델이 설정할 수 있는 재실행 플래그로 충분한가요?

아닙니다. 모델이 쓸 수 있는 플래그는 모델이 원하는 바를 기록할 뿐입니다. 사람만 승인 필드를 쓸 수 있고, 그 값이 없을 때 유료 렌더링 단계가 실행을 거부해야 비로소 통제 장치가 됩니다.

유료 AI 에이전트 워크플로우에 이런 통제를 설계하려면 AI 자동화를 살펴보십시오.

게시일
카테고리
Build
SNS 자동화 API Zernio 리뷰: 요금과 플랫폼별 제약

SNS 자동화 API Zernio 리뷰: 요금과 플랫폼별 제약

SNS 자동화 기능을 제품에 넣으려는 개발자를 위한 Zernio 리뷰입니다. 지원 플랫폼과 계정 요건, 연결 계정별 요금과 추가 사용료, 웹훅·MCP 연동의 운영 제약을 살펴봅니다. Ayrshare, Postiz, 플랫폼 공식 API와 비교해 팀에 맞는 선택 기준을 정리합니다.2026년 11월 1일Build
협업 툴 비교: Airtable vs Notion, 업무별 선택 가이드

협업 툴 비교: Airtable vs Notion, 업무별 선택 가이드

Airtable과 Notion, 어떤 툴이 맞을까요? CRM, 콘텐츠 캘린더, 프로젝트, 팀 위키, 자산 관리, 고객 포털을 기준으로 비교합니다. 요금과 데이터베이스 한도부터 자동화, API, AI, 접근 권한, 이전 비용까지 살펴보고 두 툴을 함께 쓸 때의 역할도 정리합니다.2026년 11월 1일Build
Google Jules 서비스 종료: 작업 내보내기부터 대체 툴 전환까지

Google Jules 서비스 종료: 작업 내보내기부터 대체 툴 전환까지

Google Jules 서비스 종료 일정과 데이터 내보내기 절차를 정리합니다. 세션 기록과 설정을 보존하고, API 자동화의 불확실성을 점검하며, Antigravity·Codex·Claude Code·GitHub Copilot으로 옮길 실행 환경과 검토 절차를 비교하십시오.2026년 11월 1일Build
AI 에이전트 개발: smolagents의 작동 원리와 선택 기준

AI 에이전트 개발: smolagents의 작동 원리와 선택 기준

smolagents로 AI 에이전트의 행동을 Python 코드로 조합하는 원리와 활용 기준을 살펴봅니다. CodeAgent와 ToolCallingAgent의 차이, Docker 예제, 툴 권한과 샌드박스의 역할을 짚고 LangGraph·OpenAI Agents SDK와 비교합니다.2026년 10월 31일Build
Warp Terminal 리뷰: 터미널을 바꾸면 개발이 더 편해질까?

Warp Terminal 리뷰: 터미널을 바꾸면 개발이 더 편해질까?

Warp Terminal이 지금 쓰는 터미널을 대체할 만한지 살펴봅니다. Claude Code·Codex 연동, Warp Drive, 요금과 과금 범위, 개인정보 설정과 공유 세션 보관 제약을 비교하고, 터미널·에이전트·팀 클라우드 도입을 따로 판단할 기준을 제시합니다.2026년 10월 31일Build
Kilo Code 리뷰: 에디터부터 클라우드까지, 갈아탈 이유가 있을까?

Kilo Code 리뷰: 에디터부터 클라우드까지, 갈아탈 이유가 있을까?

Kilo Code의 VS Code·JetBrains·CLI 사용법부터 모델 선택, Cloud Agents, 코드 리뷰까지 살펴봅니다. 플랫폼·추론·컴퓨팅 요금을 구분하고 Cline·Claude Code와 비교해, 개인 개발자와 소규모 팀이 전환할 만한 이유와 제약을 짚습니다.2026년 10월 31일Build
AI 에이전트 운영, Bedrock AgentCore에 어디까지 맡길까

AI 에이전트 운영, Bedrock AgentCore에 어디까지 맡길까

AI 에이전트 개발 후 운영 인프라가 부담이라면 Bedrock AgentCore를 검토해 보세요. 구성 요소별 역할과 직접 책임져야 할 권한·세션 설계, 실행 시간과 상태 보존의 제약을 짚고, AWS CLI로 첫 시범 도입을 진행하는 절차와 도입 판단 기준을 정리합니다.2026년 10월 30일Build
speculative decoding이란? LLM 추론 가속 원리와 적용 조건

speculative decoding이란? LLM 추론 가속 원리와 적용 조건

speculative decoding(추측 디코딩)의 원리부터 vLLM, SGLang, TensorRT-LLM 설정까지 살펴봅니다. 채택률, 배치 크기, GPU 메모리가 속도에 미치는 영향과 타깃의 검증 규칙을 유지하며 워크로드에서 지연 시간과 처리량 개선을 확인하는 방법을 정리합니다.2026년 10월 30일Build
뉴스레터

매주 일요일, 한 통의 편지.뜨거운 의견이 아닌, 돌아가는 시스템.

주간 발행. 스팸 없음. 언제든 해지 가능합니다.