에이전트에게 제어 흐름 (Control Flow)이 필요한 이유는 루프가 비용을 발생시키기 때문입니다

지난주 HN(Hacker News)에서 "에이전트에게 필요한 것은 더 많은 프롬프트가 아니라 제어 흐름 (Control Flow)이다"라는 제목의 게시물이 화제가 되었습니다 (스레드 48051562, 588점, 293개 댓글). 논점은 공학적인 측면입니다. 즉, 개방형 프롬프트 루프 (Open-ended prompt loops)는 예측 불가능하지만, 결정론적 하네스 (Deterministic harnesses)는 예측 가능하므로, 에이전트를 플로우차트 (Flowchart)로 감싸고 한 번에 한 단계씩 입력하라는 것입니다. 한 댓글 작성자는 정확히 그렇게 하고 있다고 설명했습니다. "플로우차트의 다음 단계를 계속해서 입력하는 루프 안에 에이전트를 감쌌습니다." 모두 사실입니다. 하지만 해당 스레드에서 대부분 피했던 두 번째 축이 있었고, 한 사람이 이를 공개적으로 언급했습니다. "그들이 사람들을 프롬프트 전용 워크플로우로 몰아넣는 이유는 토큰 (Tokens) 비용을 지불하게 만들기 위해서라고 생각했습니다" — DrewADesign, 동일 스레드. 개방형 에이전트 루프는 단순히 신뢰할 수 없는 동작일 뿐만 아니라, 무제한적인 지출 (Unbounded spend)을 의미합니다. 그리고 거의 아무도 계측 (Instrumenting)하지 않는 부분은 이것입니다. 인보이스 (Invoice)가 도착했을 때, 30번의 모델 호출 (Model calls)을 수행한 세션에 대해 하나의 숫자만 알 수 있을 뿐, 그 30번의 호출 중 어떤 호출이 저장소 (Repo)를 세 번 다시 읽어서 1.83달러 중 1.40달러를 소모했는지 알 방법이 없습니다. 지난 30일 동안 루프 비용은 세 번이나 상승했습니다. 여기서 타이밍은 결코 미묘하지 않습니다. 스레드에서 플로우차트에 대해 논쟁하는 동안, 토큰당 가격 (Per-token price)은 모두의 발밑에서 움직였습니다. GitHub Copilot은 동일한 Opus 호출이라도 플랜과 초과 사용 상태에 따라 1x / 7.5x / 27x 배율로 청구되는 토큰 크레딧 모델 (Token-credit model)로 전환했습니다 (HN 47923357). 작업은 동일하지만 가격은 세 가지입니다. Anthropic은 사이클 중간에 Pro 티어에서 Claude Code를 제거하는 A/B 테스트를 진행했습니다 (HN 47854477). 사람들은 자신들이 구축한 하네스가 작동을 멈췄을 때에야 사전 통보 없이 이를 알게 되었습니다. OpenAI는 5월 8일에 GPT-5.5를 출시했는데, 이는 GPT-5.4의 토큰당 가격보다 대략 2배 높았습니다 (HN 48057209, 213점). OpenRouter는 1934%의 토큰 효율성 (Token-efficiency) 향상 이후에도 순 비용이 4992% 증가한 것으로 측정했는데, 이는 효율성 향상보다 가격 변동 폭이 더 컸기 때문입니다. 그곳의 한 댓글 작성자는 다음과 같이 말했습니다. "이것은 또한 상당한 비용 복권 (Cost lottery)이며, 저는 이것이 편안하게 느껴지지 않습니다." 그리고 워크로드 (Workload) 자체도 가격 재책정 이전에 이미 변동성 (Variance)이 매우 큽니다.

reflex.dev는 동일한 관리 패널 (Admin-panel) 작업에 대해 구조화된 API (Structured API)와 컴퓨터 사용 (Computer-use) 능력을 벤치마킹했습니다 (HN 48024859, 댓글 26개): 에이전트 루프 (Agent loop)에는 550,976 ± 178,849개의 입력 토큰 (Input tokens)이 소모된 반면, 구조화된 호출 (Structured call)에는 12,151 ± 27개가 소모되었습니다. 루프의 표준 편차 (Standard deviation)는 평균의 약 32%에 달합니다. 동일한 작업을 두 번 실행하면 400k750k 토큰의 변동이 발생하며, 이에 상응하는 750초1257초의 실제 소요 시간 (Wall-clock) 변동이 나타납니다. 이를 종합해 보면: 실행 시마다 이미 약 2배의 변동성을 보이는 워크로드 (Workload)가, 한 달 사이 세 번이나 변동된 토큰당 가격 위에서, 당신이 아닌 모델에 의해 길이가 결정되는 루프 내부에서 돌아가고 있는 것입니다. "태스크당 평균 비용"은 예산을 세울 수 있는 숫자가 아닙니다. 그것은 단 한 번의 실행에 대해 한때 유효했던 숫자일 뿐입니다. 제가 실제로 측정한 것은—저는 LLM API 비용 추적을 위한 오픈 소스 대시보드인 i build llmeter를 만들었기에 이 데이터를 들여다보는 데 많은 시간을 보냅니다—가장 먼저 문제가 된 것은 가격이 아니었습니다. 그것은 귀속 (Attribution) 문제였습니다. 에이전트적 태스크 (Agentic task)의 형태는 다음과 같습니다: 하나의 사용자 요청이 N개의 모델 호출 (Model calls)이 되는데, 여기서 N은 사용자가 아닌 에이전트의 선택에 의해 결정됩니다. 호출별 귀속 (Per-call attribution) 없이는 해당 세션에 대한 청구서가 단 한 줄로 표시됩니다. 저장소 (Repo)를 세 번이나 다시 읽은 반복 (Iteration) 과정을 지목할 수 없습니다. 이미 성공한 재시도된 도구 호출 (Tool-call) 분기와 실제 작업을 구분할 수 없습니다. "에이전트는 비용이 많이 든다"는 말은 막연한 느낌으로 남습니다. 우리가 API 호출당 비용을 기록하고 사용자별 / 모델별 / 일별로 합산하기 시작하자, 두 가지 사실이 빠르게 드러났습니다: "동일한" 태스크에 걸친 비용 분포는 정규 분포 (Normal distribution)가 아니라 이봉 분포 (Bimodal distribution)라는 점입니다. 대부분의 실행은 저렴하지만, 소수의 실행이 3~5배 더 비싸며, 이 꼬리 (Tail) 부분은 정확히 루프가 추가적인 작업을 수행하기로 결정한 지점입니다. 평균값은 이 꼬리 부분을 숨깁니다. 실제 당신의 청구서를 예측하는 숫자는 p95입니다. 소수의 사용자들—보통 무료 티어(Free tier)를 사용하며, 보통 크론 (Cron) 작업을 실행하는 사용자들—이 토큰 지출의 매우 불균형한 비중을 차지했습니다. 매시간 동일한 문서를 재요약하는 단 하나의 크론 작업이 유료 고객보다 조용히 더 많은 비용을 지출할 것이며, 당신은 이를 통합된 제공업체 청구서 (Aggregate provider bill)에서는 확인할 수 없을 것입니다.

이 모든 것은 가격 책정 (pricing)의 문제가 아닙니다. 가격 변동성 (pricing volatility)이 비용을 비싸게 만드는 가시성 (visibility)의 문제입니다. 이번 주에 해야 할 일 (도구가 필요하지는 않습니다): 이번 달 프로덕션 (production)에서 가장 비용이 많이 발생한 단일 작업을 찾으세요. 평균이 아니라, 단일 최악의 실행 건을 찾아야 합니다. 만약 5분 안에 이를 쿼리 (query)할 수 없다면, 그것이 바로 격차이며, 이를 메우는 것은 보통 5줄의 코드 변경으로 가능합니다: 모든 completion 호출 옆에 model, input_tokens, output_tokens, cached_tokens 및 task_id를 로그 (log)로 남기고, GROUP BY task_id ORDER BY cost DESC LIMIT 10을 실행하면 됩니다. cached-token 라인을 분리하세요. OpenAI, Anthropic, DeepSeek는 각각 cache-hit / cache-miss / cached-input을 다르게 명명하며, 가격 재책정 (repricing) 시 가장 많이 변동하는 부분은 캐시 계층 (cached tier)입니다. 만약 비용 합산 (cost rollup) 과정에서 모든 것을 "input tokens"로 통합해 버린다면, 캐시 계층의 가격 변동은 인보이스 (invoice)를 받기 전까지는 보이지 않습니다. 에이전트 루프 (agent loops)에 task_id를 부여하고 반복 횟수 (iterations)를 세어보세요. Reflex의 수치들은 반복 횟수가 변동성 (variance)의 원인임을 말해줍니다. 만약 "이 사용자 요청이 14번의 모델 호출로 퍼져 나갔다 (fanned out)"라는 것을 로깅 (logging)하고 있지 않다면, 정상적인 실행과 통제 불능인 실행을 구분할 수 없으며, 당연히 이에 대해 알림 (alert)을 보낼 수도 없습니다. 평균 (mean)이 아니라 p95에 대해 알림을 설정하세요. "월간 평균 금액을 모두 지출했습니다"라는 Slack 알림은 피해가 발생한 후에 울립니다. 반면 "이 작업은 해당 작업 유형에 대해 우리가 기록한 비용 중 상위 5%에 해당합니다"라는 알림은 작업이 여전히 실행 중일 때 울립니다. (이 지점이 도구가 제 역할을 하는 유일한 부분입니다. 모델별 / 사용자별 / 일별 예산 알림 — 하지만 로직은 직접 구현할 수 있을 만큼 충분히 간단합니다.) 비용 절감을 위해 DeepSeek로 라우팅 (route)한다면, 날짜를 기록해 두세요. V4-Pro 75% 프로모션은 2026-05-31 15:59 UTC에 만료되며, 그 순간 모든 항목의 비용이 4배로 뜁니다. 이것은 예측이 아니라 달력에 적어두어야 할 일정입니다. 6월 1일이 아니라 5월 30일 이전에 모델링하세요. 핵심은 제어 흐름 (control-flow) 논거와 비용 논거가 결국 같은 논거라는 점입니다. 결정론적 하네스 (deterministic harness)는 예측 가능한 동작과 예측 가능한 청구서를 의미합니다. 개방형 루프 (open-ended loop)는 그 두 가지 모두에 대해 "나를 믿으라"고 말하는 것과 같습니다.

하네스 (harness)를 사용하는 사람들이 옳습니다. 하지만 플로우차트 (flowchart)를 그려야 하는 이유는 단지 에이전트가 더 잘 작동하기 때문만은 아닙니다. 그것은 당신이 돈을 소모한 바로 그 박스를 마침내 지목할 수 있기 때문입니다. 만약 당신의 에이전트 루프 (loop)에 대한 비용 형태 (cost shape)를 그릴 수 없다면, 당신의 제어 흐름 (control flow)은 그저 희망 사항일 뿐입니다. 나는 OpenAI / Anthropic / DeepSeek / OpenRouter / Mistral / Azure OpenAI를 위한 오픈 소스 (AGPL-3.0) 비용 대시보드인 llmeter를 만들었습니다. 모델별, 사용자별, 일별 비용 확인이 가능하며 예산 알림 기능을 제공합니다. 이것은 프록시 (proxy)가 아니며 당신의 요청 경로 (request path)에 위치하지도 않습니다. SDK가 사용 메타데이터 (usage metadata)를 비동기 (async)로 전달합니다. 위에서 언급한 호출당 귀속 (per-call attribution) 기능이 제가 이것을 만들게 된 계기였습니다. 무료 티어 (free tier)는 한 개의 제공업체 / 7일 데이터 보관을 지원합니다. 다른 사람들은 에이전트 비용 (agentic cost)을 어떻게 분류하는지 진심으로 듣고 싶습니다. 당신의 롤업 키 (rollup key)는 무엇을 기준으로 하나요?