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

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

Tuesday, September 22, 2026Omid Saffari
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 자동화를 살펴보십시오.

마지막 업데이트
2026년 9월 22일
카테고리
Build

Google에서 이 사이트를 우선하기

Google 검색에서 omidsaffari.com을 선호 소스로 추가

omidsaffari.com을 선호 소스로 지정하면 Google이 Top Stories, AI Overviews, AI Mode에서 우선적으로 보여 줍니다.

MindStudio로 AI 에이전트 만들기: 기능·가격·도입 판단

MindStudio로 AI 에이전트 만들기: 기능·가격·도입 판단

MindStudio로 AI 에이전트를 만드는 방법과 노코드 워크플로우 기능을 검토합니다. Free·Individual 요금제, 1,000건과 10,000건 운영비, 팀 협업 한계, 도입 전 20건 테스트 기준까지 공개 자료로 도입 여부를 꼼꼼히 따져봅니다.2026년 9월 22일Build
Wispr Flow vs Superwhisper: AI 받아쓰기 툴 비교

Wispr Flow vs Superwhisper: AI 받아쓰기 툴 비교

Superwhisper와 Wispr Flow의 가격, 로컬·클라우드 처리 방식, 지원 기기, 팀 기능을 비교합니다. 20개 문장 교정 테스트 절차와 1인·5인 비용표를 바탕으로 개인정보 보호, 운영 편의성, 장기 비용 중 무엇을 우선할지 판단하고 AI 받아쓰기 툴을 선택하세요.2026년 9월 22일Build
업무 자동화 에이전시 선택법: 주요 업체와 90일 비용 비교

업무 자동화 에이전시 선택법: 주요 업체와 90일 비용 비교

업무 자동화와 AI 에이전트 개발을 맡길 AI 자동화 업체를 워크플로 적합성, 90일 총비용, 지원 범위, 소유권으로 비교합니다. HatchWorks AI, Leanware, Axe Automation, Coretus의 차이와 20개 사례 파일럿, 인수인계 조건까지 확인하세요.2026년 9월 22일Build
Claude Code 사용법: Projects 베타 실전 가이드

Claude Code 사용법: Projects 베타 실전 가이드

Claude Code 사용법을 Projects 베타 기준으로 정리했습니다. 계정 접근 확인부터 GitHub 설정, 병렬 클라우드 스레드 배정, 프로젝트 맥락과 로컬 툴의 경계, 하루 새 스레드 200개 한도, 브랜치 검토까지 첫 실행 절차를 안내합니다.2026년 9월 21일Build
Jev로 티켓 라우팅을 안전하게 설계하는 법

Jev로 티켓 라우팅을 안전하게 설계하는 법

Jev로 고객 지원 티켓을 분류하고 큐·심각도·긴급도 신호를 코드에서 다루는 방법을 설명합니다. 라벨링한 티켓 30건, 신뢰도 임계값, 사람 검토 큐를 활용해 자동 티켓 라우팅의 오분류를 드러내고 안전한 운영 경계를 세우는 과정을 단계별로 정리한 실무 가이드입니다.2026년 9월 21일Build
Claude Code 사용법: AGENTS.md를 프로젝트 지침으로 불러오기

Claude Code 사용법: AGENTS.md를 프로젝트 지침으로 불러오기

Claude Code v2.1.277에서 AGENTS.md를 프로젝트 지침으로 직접 불러오는 조건과 설정법을 정리합니다. CLAUDE.md 우선순위, 제공업체와 기능 플래그 제한, /config 모드 선택, 새 세션에서 실제 로드 여부를 검증하는 방법까지 단계별로 확인하세요.2026년 9월 19일Build
Claude Code MCP 시작 대기 시간, 제대로 설정하는 법

Claude Code MCP 시작 대기 시간, 제대로 설정하는 법

Claude Code 2.1.274에 추가된 MCP 시작 대기 환경 변수의 범위와 0의 의미를 설명합니다. 서버 시작, 툴 실행, 전체 작업의 제한을 구분하고 CI와 예약 작업에서 필수 서버의 연결 상태를 검증해 불완전한 결과를 막는 실전 설정 기준까지 한 번에 정리했습니다.2026년 9월 17일Build
검색 노출을 지키는 Cloudflare AI 크롤러 차단 설정법

검색 노출을 지키는 Cloudflare AI 크롤러 차단 설정법

Cloudflare에서 검색 노출은 유지하면서 AI 학습 크롤러만 막는 안전한 설정법을 정리했습니다. 2026년 9월 15일 달라진 Block 정책부터 마이그레이션 점검, robots.txt 검증, Bing 예외와 운영상 한계까지 실무 순서대로 확인하세요.2026년 9월 16일Build
뉴스레터

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

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