다섯 명짜리 팀이 새 AI agent를 시험해 봤다. AI agent는 여러 단계를 스스로 이어서 실행하는 AI 도우미다. 경쟁사 발표 자료 20건을 정리하고 요점을 사내 문서에 옮기게 했다. 모델 가격은 매력적이었다. 입력 token(모델이 글의 양과 요금을 세는 단위) 100만 개당 2달러였다. 그런데 일주일 뒤 청구서는 처음 예상한 금액의 몇 배였다. 아무도 함부로 쓰지 않았고, 작업도 열몇 번 돌렸을 뿐이었다.
돈은 어디로 갔을까. 대부분은 “모델이 발표 자료 20건을 읽은 일"에 쓰이지 않았다. 긴 작업에서만 생기는 두 가지 반복에 쓰였다. 단계마다 컨텍스트 전체를 다시 보내는 일, 그리고 실패한 뒤 처음부터 다시 돌리는 일이다. 둘 다 가격표에는 나오지 않지만, 긴 작업의 청구액을 결정하는 건 이 둘이다. 그래서 긴 작업의 상한은 프롬프트에 적는 것만으로는 부족하다. 모델 바깥의 프로그램이 작업 전체가 함께 쓰는 하나의 예산으로 지켜야 한다.
단가는 내려가도 청구액은 따라 내려가지 않는다
올해 7월, 일론 머스크 산하의 옛 xAI인 SpaceXAI가 새 모델 Grok 4.5를 내놓았다. 가격은 입력 token 100만 개당 2달러, 출력 token 100만 개당 6달러다. TechCrunch는 이를 Anthropic의 플래그십 모델 Opus 4.7과 비교했는데, 그쪽은 5달러와 25달러다. SpaceXAI는 같은 종류의 코딩 작업에서 경쟁 모델보다 출력 token을 적게 쓴다며 token 효율도 강조했다.
이런 숫자를 보면 예전에는 비싸서 엄두가 안 나던 긴 작업들이 해 볼 만해 보인다. 많은 자료를 정리하거나, 여러 파일에 걸쳐 코드를 고치거나, 고객 문의 기록을 한꺼번에 읽고 분류하는 일이다. 문제는 가격표가 답하는 것은 “100만 token을 읽는 데 얼마인가"인데, 긴 작업의 청구액은 “모두 합쳐 몇 번 읽었는가"로 정해진다는 점이다.
돈이 나가는 곳: 호출할 때마다 컨텍스트 전체를 다시 읽는다
긴 작업이란 agent가 여러 단계를 이어 가야 끝낼 수 있는 일을 말한다. 파일을 읽고, 도구를 호출하고, 결과를 보고, 다음에 할 일을 정한다. Anthropic 문서는 도구를 쓰는 agent를 설명하면서 분명히 적었다. 각 단계는 보통 새로운 API 호출, 즉 프로그램이 모델에 보내는 새 요청 한 번이다. 모델은 이전 호출의 내용을 기억하지 못하기 때문에, 호출할 때마다 지금까지의 대화, 읽은 파일, 도구가 돌려준 결과를 모두 다시 보내야 한다.
그래서 비용은 단계 수에 따라 고르게 늘지 않는다. 가정한 예로 계산해 보자. 단계마다 컨텍스트가 2,000 token씩 늘어난다면, 1단계에서는 2,000 token, 10단계에서는 20,000 token을 보내고, 30단계에 이르면 한 번에 60,000 token을 보낸다. 30단계를 모두 합치면 모델이 읽어 들인 입력은 약 93만 token인데, 그중 정말 “새로운” 내용은 6만 token뿐이다.
업체들은 이런 반복을 줄이도록 캐시를 제공한다. Anthropic의 설명을 예로 들면, 캐시에서 읽는 token은 기본 입력 가격의 10분의 1만 받고, 캐시에 쓰는 데는 25%를 더 받는다. 다만 캐시는 기본적으로 5분만 유지되고, 사용할 때마다 시간이 다시 계산된다. 이 세부 사항은 실무에서 꽤 중요하다. agent가 사람의 확인을 기다리며 멈췄는데 그 사람이 20분짜리 회의에 들어가 있었다면, 돌아왔을 때 캐시는 이미 만료됐고 다음 단계에서 컨텍스트 전체를 다시 써넣어야 한다.
두 번째 비용: 실패하면 처음부터
두 번째 반복은 재실행이다. 긴 작업이 25단계에서 어떤 파일의 형식이 예상과 달라 실패했다고 하자. 가장 흔한 대응은 처음부터 다시 하는 것이다. 앞의 24단계 동안 쌓인 입력 전부에 돈을 한 번 더 내게 된다. “실패하면 자동으로 두 번까지 재시도"로 설정해 두었다면, 최악의 경우 같은 작업에 세 번 돈을 내고 세 번 모두 실패한다.
이 비용이 골치 아픈 이유는 보이지 않기 때문이다. 청구서에는 token을 얼마나 썼는지만 나오고, 그중 얼마가 다시 한 작업이었는지는 나오지 않는다. 팀이 보는 건 “이번 달은 좀 비싼 것 같다"는 느낌뿐이고, 어떤 종류의 작업이 어느 단계에서 돈을 태웠는지는 찾을 수 없다.
프롬프트에 적은 상한이 상한이 아닌 이유
많은 팀이 처음 떠올리는 방법은 agent의 시스템 프롬프트에 “비용이 5달러를 넘으면 멈춰라"라는 한 줄을 넣는 것이다. 문제는 모델이 청구서를 볼 수 없다는 데 있다. 모델은 지금까지 token을 얼마나 썼는지도, 이번 호출이 얼마인지도 모른다. 기껏해야 “아껴 써야지” 하고 스스로 되새길 뿐, 예산이 바닥났을 때 실제로 멈추지는 못한다.
상한을 확실히 지킬 수 있는 건 모델을 호출하는 쪽의 프로그램뿐이다. 호출할 때마다 API는 이번에 입력과 출력 token을 얼마나 썼는지 알려 준다. 프로그램은 이를 더해 가며, 다음 호출을 보내기 전에 남은 예산을 확인한다. 모자라면 보내지 않고, 그때까지의 결과와 멈춘 이유를 담당자에게 넘긴다.
이 예산은 “작업 전체"를 단위로 잡아야 한다. 재시도에 새 한도를 주지 말고, 첫 실행과 같은 예산을 함께 쓰게 해야 한다. 그렇지 않으면 “재시도는 최대 두 번"이 사실상 상한을 세 배로 늘린다.
엄격한 상한의 대가
엄격한 상한에도 대가는 있다. 작업이 90%쯤 진행됐을 때 상한에 걸리면, 그때까지 쓴 돈으로 얻는 건 미완성 결과물이다. 이런 낭비를 줄이려면 상한과 함께 중간 저장을 두는 것이 좋다. 한 단계를 마칠 때마다 정리된 중간 결과를 저장해 두고, 다시 돌릴 때는 마지막 저장 지점부터 이어 가서 처음부터 다시 읽지 않게 한다. 그러면 실패의 대가는 작업 전체가 아니라 한 단계로 줄어든다.
또 모든 작업에 이런 장치가 필요한 것은 아니다. 서너 단계면 끝나는 짧은 작업은 컨텍스트가 크게 쌓이지 않고 다시 돌려도 싸다. 예산 통제를 설계하는 수고가 오히려 더 든다. 상한을 둘 만한 일은 단계가 많거나, 파일을 많이 읽거나, 자동으로 재시도할 수 있는 작업이다.
일주일 먼저 재 보고 상한을 정한다
상한을 얼마로 할지에 정답은 없다. 작업마다 단계 수도, 컨텍스트 크기도, 실패율도 다르다. 남의 숫자를 그대로 가져오면 너무 빡빡해서 작업이 자꾸 중간에 멈추거나, 너무 느슨해서 상한이 없는 것과 같아진다.
더 현실적인 방법은 팀이 이미 돌리고 있는 긴 작업 하나를 골라 일주일 동안 기록하는 것이다. 한 번 실행할 때 몇 단계를 거쳤는지, 단계마다 token을 얼마나 보냈는지, 몇 번 재시도했는지, 캐시가 얼마나 적중했는지. 일주일이 지나면 이 작업이 보통 얼마에 끝나는지 대략 알게 된다. 상한은 그 보통 값보다 조금 높게 잡으면 된다. 상한을 넘은 몇 번이 바로 사람이 한번 들여다볼 만한 이상 신호다.
이 기록은 어디서 아껴야 할지도 알려 준다. 다시 보낸 컨텍스트가 대부분을 차지한다면, 먼저 캐시가 제대로 작동하는지, 쓰지도 않는 파일을 통째로 컨텍스트에 넣고 있지 않은지 확인한다. 확인을 기다리는 동안 캐시가 자주 만료된다면, 확인을 몇 단계에 모으거나 더 긴 캐시 시간을 검토한다. Anthropic의 경우 1시간 캐시 쓰기는 기본 입력 가격의 두 배지만, 대기 시간이 긴 작업이라면 거듭 다시 쓰는 것보다 쌀 수 있다. 재시도가 대부분을 차지한다면 고쳐야 할 것은 실패의 원인이다. 상한을 올리면 같은 실패에 돈을 몇 번 더 낼 뿐이다.
이 글이 다루는 것은 작업 하나의 예산이다. 팀 전체가 매달 AI 비용을 어떻게 나누고 누가 얼마를 쓸 수 있는지는 또 다른 층위의 문제이며, AI 청구서는 백만 토큰당 가격이 아니라, 채택된 결과물 한 건에 든 비용으로 잰다을 참고할 수 있다.
그 긴 작업이 코딩이라면, 넘기기 전에 더 작게 나눌 수 있는지부터 살펴보자. 이 issue를 coding agent에 맡길 수 있는지는 첫 번째 diff를 적을 수 있느냐에 달렸다도 참고할 만하다. 작게 나눌수록 조각마다 컨텍스트가 짧아지고, 실패했을 때 다시 할 일도 줄어든다.
AI 정리 카드
긴 작업의 실제 비용을 AI에게 추정해 달라고 하기 이 프롬프트는 먼저 작업이 어떻게 돌아가는지 묻고, 컨텍스트 재전송과 재시도가 각각 얼마나 차지하는지 계산한 뒤, 첫 예산 상한과 저장 지점을 제안한다.
긴 AI 작업 하나의 실제 비용을 추정하고 첫 예산 상한을 정하고 싶다.
배경은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/long-running-ai-task-token-cost-limits/
글의 관점은 이렇다. 긴 작업의 청구액은 주로 단계마다 컨텍스트를 다시 보내는 일과 실패 후 다시 돌리는 일에서 나온다. 상한은 프롬프트에 적는 것으로 끝나지 않고, 모델을 호출하는 프로그램이 "작업 전체가 함께 쓰는 하나의 예산"으로 지켜야 한다.
먼저 나에게 질문 3개를 해 달라:
1. 이 작업은 평균 몇 단계를 거치고, 단계마다 새 내용을 대략 얼마나 읽어 들이는가;
2. 실패했을 때 지금은 어떻게 처리하는가: 전체를 다시 돌리는가, 중간부터 이어 가는가, 자동으로 몇 번 재시도하는가;
3. 작업 도중 사람의 확인을 기다리며 멈추는 일이 있는가, 보통 얼마나 기다리는가.
내 답을 바탕으로 다음을 출력해 달라:
- 간단한 계산식으로 한 번의 완전한 실행에 드는 입력 token 총량을 추정하고, 그중 다시 보낸 컨텍스트가 얼마인지 표시;
- 한 번 실패하고 다시 돌리면 얼마가 더 드는지;
- 작업 전체의 예산 상한 제안과, 어느 단계에서 중간 저장을 해야 하는지;
- 이 상한을 고치려면 앞으로 일주일 동안 어떤 숫자를 기록해야 하는지.
모든 추정에는 전제를 적을 것. 정보가 부족하면 숫자를 지어내지 말고 먼저 나에게 물어볼 것.
추정은 출발점일 뿐이다. 실제 상한은 일주일 동안의 실제 기록을 바탕으로 정한다.
참고 자료
- TechCrunch: SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’ — https://techcrunch.com/2026/07/08/spacexai-releases-grok-4-5-which-elon-describes-as-an-opus-class-model/ (2026-07-08)
- SpaceXAI: Introducing Grok 4.5 — https://x.ai/news/grok-4-5 [accessed: 2026-10-11]
- Anthropic Docs: Prompt caching — https://platform.claude.com/docs/en/docs/build-with-claude/prompt-caching [accessed: 2026-10-11]
