기업 팀이 2주 차에 즉시 해결해야 하는 GPT 비용 실패 사례

하루에 12달러에서 60달러. 환경당 말입니다.

기업 팀이 왜 GPT 청구서가 데모(demo)와 일치하지 않는지 저에게 물을 때마다 제가 계속해서 발견하게 되는 새로운 지출 규모입니다.

여기 아무도 듣고 싶어 하지 않는 부분이 있습니다.

청구서는 영수증일 뿐입니다. 이 영수증 뒤에는 팀이 인지하지 못한 채 내린 아키텍처(architecture) 결정이 자리 잡고 있습니다.

데모가 당신에게 거짓말을 하는 이유

개발(Dev) 작업은 짧습니다. 두세 번의 도구 호출(tool calls)이면 충분하며, 비용도 저렴합니다.

프로덕션(Production) 작업은 깊게 실행됩니다. 에이전트(agent)가 결과를 읽고, 결정하고, 또 다른 결과를 읽고, 다시 결정합니다.

각 단계(hop)마다 지금까지의 대화 전체를 다시 전송합니다.

따라서 비용은 작업이 스스로를 얼마나 많이 다시 읽는지에 따라 결정됩니다. 실제로 수행된 작업량은 수치에 거의 영향을 주지 못합니다.

징후를 읽는 법

이 문제는 개발 단계에서는 절대 나타나지 않습니다.

첫 번째 실제 워크로드(workload)가 깊은 루프(loops)를 실행하고, 재시도(retries)가 단계(hops) 위에 단계를 쌓아 올린 후, 프로덕션 2주 차에 접어들 때 비로소 나타납니다.

한 번 발생하면 단순히 비용이 많이 든 날로 치부하기 쉽습니다.

하지만 서로 다른 고객들에게서 세 번을 목격하게 된다면, 그 형태(shape)가 중요해집니다.

그 형태는 다음과 같습니다. 비용은 에이전트가 수행하는 단계 수의 제곱에 비례하여 증가합니다. 작업 횟수(task count)는 계산식에 거의 영향을 미치지 않습니다.

15단계의 작업은 3단계 작업보다 5배의 비용이 드는 것이 아닙니다. 훨씬 더 많은 비용이 듭니다. 왜냐하면 각 단계가 뒤로 갈수록 이전 단계들이 생성한 모든 것을 끌어안고 가기 때문입니다.

기업이 더 힘들게 느끼는 이유

이 글을 읽고 있는 대부분의 팀은 매출, 고객 지원 대기열, 또는 경영진(C-suite)이 월요일에 확인하는 대시보드와 연결된 자동화(automation)를 실행합니다.

또한 이들은 동시성(concurrency) 환경에서 이를 실행합니다. 수백 개의 루프가 동시에 돌아갑니다.

루프당 비용은 개별적으로 보면 아주 작아 보입니다. 여기에 깊이(depth), 재시도(retries), 동시성(concurrency), 환경(environment)을 곱하면, 재무 부서에서 2주 차부터 질문을 던지기 시작합니다.

집에서 개인 개발자로서 동일한 워크로드를 실행하더라도 그 형태는 여전히 유지됩니다. 단지 0의 개수만 달라질 뿐입니다.

팀들이 시도하지만 효과가 없는 것들

• 더 저렴한 모델로 전환하기. 단가(unit price)는 낮아지지만, 홉(hop)의 곱셈 효과에는 아무런 영향을 주지 못합니다. 당신의 비싼 작업은 여전히 비싼 상태로 남으며, 이제는 추론 능력(reasoning)이 더 떨어지는 모델에서 실행될 뿐입니다.
• 출력 토큰(output tokens) 제한하기. 방향이 틀렸습니다. 비용은 출력이 아니라 다시 전송되는 입력(input)에서 발생합니다.
• 프롬프트 캐싱(prompt caching)을 켜고 요행을 바라기. 캐싱은 입력의 앞부분이 안정적으로 유지될 때만 이득을 봅니다. 하지만 에이전트의 이력이 계속 늘어나면, 홉(hop)이 거듭될수록 스스로 캐시 히트(cache hits)를 깨뜨리게 됩니다.

이 각각의 방법은 청구서 금액을 아주 조금 줄여줄 뿐입니다. 그 어떤 것도 이 부류의 실패(class of failure)를 근본적으로 해결하지 못합니다.

이 방법들은 요란한 비용을 조용한 비용으로 바꿀 뿐이며, 이는 더 나쁩니다. 조용한 비용은 분기가 마감될 때까지 숨어 있기 때문입니다.

실제로 이 문제를 해결하는 방법

제가 목격한 바로는 매번 해결책은 동일합니다.

에이전트의 실행 이력(running history)을 공짜 연습장처럼 취급하는 것을 멈추십시오. 매 홉(hop)마다 이를 예산처럼 사용하십시오.

이러한 관점의 전환은 팀이 처음에 건너뛰었던 세 가지 결정을 강제합니다.

• 에이전트가 다음 홉으로 무엇을 가져가고, 무엇을 요약하거나 버릴 것인가.
• 깊이(depth)가 버그가 되기 전까지 작업이 몇 번의 홉을 거치게 할 것인가. 제한된 홉 횟수는 제한된 비용을 의미합니다.
• 어떤 도구 결과(tool results)를 이후의 모든 홉에 포함시키고, 어떤 것을 한 번만 사용하고 버릴 것인가.

대부분의 도구 출력은 한 번 읽히고 다시는 필요하지 않습니다. 하지만 아무도 내리라고 말하지 않았기 때문에, 도구 출력은 어쨌든 계속 따라다니며 이후의 모든 홉에서 다시 비용이 청구됩니다.

어떤 도구도 이를 자동으로 처리해주지 않습니다. 당신이 결정해야 합니다.

이를 실행하는 팀은 첫 달에 딥 루프(deep-loop) 비용을 절반 이상 절감하며, 더 이상 청구서 때문에 놀라는 일이 발생하지 않습니다.

올바른 단위를 측정하라

마지막 한 가지 변화가 나머지 모든 것을 정착시킵니다.

호출당 비용(cost per call)을 읽는 것을 멈추십시오. 완료된 작업당 비용(cost per finished task)을 읽으십시오.

호출당 비용은 곱셈 효과를 숨깁니다. 작업당 비용은 어떤 루프가 예산을 잡아먹는지 보여주며, 재무 부서에서 문제를 제기하기 전에 미리 이를 보여줍니다.

살아남는 팀은 대시보드의 단위를 작업(task)으로 옮깁니다. 호출당 비용만 계속 지켜보는 팀은 계속해서 (비용에) 놀라게 될 것입니다.

이 글이 제공하지 않는 것

저는 이 방식의 작동하는 버전을 실제 운영 환경(production)에서 실행하고 있습니다.

홉 제한(Hop limits), 이월 규칙(carry-forward rules), 작업당 미터기(per task meter)가 워크플로우에 연결되는 방식, 이것들이 제가 고객 프로젝트에 가져가는 결과물입니다.

제가 이것들을 붙여넣지 않는 이유는 솔직한 이유 때문입니다.

연결 방식(wiring)을 게시해 버리면, 다음 팀들은 검색하고 복사만 할 뿐, 왜 자신들의 루프(loop)가 처음에 그렇게 깊어졌는지를 밝혀내는 대화를 결코 나누지 않습니다. 깊이(Depth)가 진짜 문제입니다. 비용은 단지 영수증일 뿐입니다.

마지막 질문 하나

외부에서 보기에는 이 글이 실패 사례들의 벽처럼 읽힌다는 것을 알고 있습니다.

만약 여러분의 GPT 청구서가 데모와 일치하지 않기 시작했다면, 진단은 보통 하나의 숫자에서 시작됩니다. 여러분의 평균적인 운영(production) 작업이 실제로 몇 번의 홉(hop)을 거치나요? 대부분의 팀은 이를 측정해 본 적이 없습니다.

여러분이 보고 있는 형태, 청구서가 급증한 주간, 루프의 깊이, 그리고 효과가 없었던 시도했던 해결책을 댓글로 남겨주세요.

가장 빠르게 범위를 좁힐 수 있는 질문으로 답변해 드리겠습니다.

이 패턴 라이브러리는 더 많은 팀이 실제로 겪은 비용 실패 사례를 명시할 때만 성장합니다.