코딩 에이전트 비용, 청구서 문제가 아니라 하네스 설계 문제다

주간 청구서에 개발자 한 명 이름 옆으로 몇천 달러가 찍혀 있으면 그때야 알아챈다. 누가 막을 새도 없이 이미 쓴 돈이다. 코딩 에이전트를 굴리는 팀 대부분이 겪는 장면이고, LangChain도 예외가 아니었다.

LangChain 팀이 공개한 내부 운영 사례에 따르면, 몇 해 전만 해도 AI 사용량은 예산에서 크게 신경 쓸 항목이 아니었다고 한다. 몇몇 팀만 쓰고, 사용량은 예측 가능했고, 청구서도 관리할 만했다. 그런데 AI 사용이 회사 전체로 퍼지고, 성능 좋은 모델일수록 비싸지고, 에이전트가 작업 하나를 끝내려고 수십 번씩 모델을 호출하기 시작하면서 상황이 뒤집혔다. 개발자 한 명이 코딩 에이전트를 열심히 굴리면 아무도 모르는 새 주간 비용이 수천 달러까지 올라갈 수 있었다고 한다.

이 문제를 가격표로 풀려는 사람이 많다. 더 싼 모델로 바꾸거나 호출 횟수를 줄이라는 식이다. 그런데 LangChain이 실제로 손댄 곳은 가격이 아니라 구조였다. 비용이 새는 진짜 이유는 하네스(harness, AI 에이전트가 돌아가는 실행 환경 전체)에 예산창·귀속·예외 절차가 없었기 때문이다.

청구서 탓이 아니라 설계 탓이다

비용이 새는 자리를 한번 상상해 보자. 창고에 물건이 계속 없어지는데 아무도 언제 누가 얼마나 가져갔는지 모른다. CCTV도 없고 입출고 장부도 없다. 이런 창고에서 "물건값을 낮추자"는 해법은 핵심을 비켜간다. 진짜 문제는 가격이 아니라 추적이 안 된다는 것이다.

AI 코딩 비용도 똑같다. 모델 호출 하나하나의 단가는 이미 공개돼 있고 크게 바뀌지도 않는다. 문제는 그 호출이 누구 것인지, 얼마나 쌓였는지, 한도에 다가가는지를 실시간으로 보는 창구가 없다는 데 있다. 월말 청구서를 열어야 아는 구조라면 그건 이미 늦은 정보다. 사고는 이미 일어난 뒤다.

LangChain은 이 문제를 매일 쓰는 제품 안에 LangSmith LLM Gateway(관문, 모든 모델 호출이 지나가는 중앙 통로)를 직접 만들어 넣는 방식으로 풀었다. 가격표를 다시 협상한 게 아니라 통제점을 만든 것이다.

모든 호출을 한 문으로 통과시킨다

통제하려면 먼저 지나가는 길목이 하나여야 한다. 문이 여러 개면 지키는 사람이 아무리 많아도 다 못 지킨다. LangChain은 중앙에서 관리 가능한 코딩 에이전트 호출, 예를 들어 Claude Code·Codex·LangChain Deep Agents를 이 관문 하나로 모았다고 밝혔다. 회사 안에서 적용 가능한 모든 호출이 이 문을 지나가면 엔지니어링 리더십은 회사 전체 비용을 분 단위로 들여다볼 수 있게 된다.

LangChain 엔지니어링 부사장 Alex Lunev는 이 방식의 장점을 이렇게 설명했다고 한다. "Gateway의 장점은 중앙 통제를 통해 더 큰 확실성을 얻는다는 점입니다. 대시보드를 열었을 때 예상치 못한 수천 달러 청구서를 보게 되지 않을 것이라는 확신이 생깁니다." 확신이라는 단어가 눈에 띈다. 통제란 결국 다음 청구서를 열기 전에 이미 무슨 일이 있었는지 안다는 뜻이다.

다만 문 하나로 다 모이지는 않았다. LangChain이 실제로 겪은 부분인데, 클라이언트마다 이 관문을 얼마나 순순히 통과하는지가 달랐다. 예를 들어 Cursor는 관문으로 우회시키는 설정(base-url 교체)을 사용자별로만 열어 뒀고 그마저도 채팅 기능에만 해당됐다고 한다. Claude Desktop은 관리형 설정으로 관문을 지나가게 할 수는 있었지만, 그 설정을 켜면 앱 동작 자체가 표준 채팅에서 로컬 에이전트 방식으로 바뀌어 버렸다고 밝혔다. 통제점을 하나 만들었다고 모든 문제가 끝나지 않는다. 문을 안 지나가는 손님이 있으면 그 몫은 다른 방법으로 세야 한다.

예산은 창 하나가 아니라 네 개다

예산을 한 달 한도 하나로만 잡으면 어떻게 될까. 한 달 예산 100만 원을 첫 사흘 만에 다 쓰는 사람이 나온다. 월간 총량은 안 넘었으니 규칙상 문제는 없다. 그런데 그 사흘 동안 다른 팀원은 정작 필요한 순간에 쓸 예산이 없다. 창이 하나뿐이면 몰림을 못 막는다.

LangChain은 예산 창을 월간·주간·일간·시간 단위 네 겹으로 뒀다고 한다. 월 한도만 지키면 되는 게 아니라 이번 시간, 오늘, 이번 주 한도도 같이 지켜야 한다. 창을 여러 겹으로 두면 몰아 쓰기가 자연스럽게 눌린다. 폭주가 한 시간 안에 벌어져도 시간 단위 창이 먼저 걸린다.

예산창 단위	주로 잡아내는 문제	놓치는 것
시간 단위	루프 폭주, 짧은 시간 집중 호출	느리게 쌓이는 만성 초과
일간	하루짜리 몰아 쓰기	월초·월말 패턴 차이
주간	스프린트 단위 집중 작업	순간적인 폭주
월간	전체 예산 총량 관리	월 중간의 이상 신호 탐지 지연

이 표에서 중요한 건 "놓치는 것" 칸이다. 어느 창 하나도 혼자서는 완전하지 않다. 시간 단위만 있으면 느리게 새는 비용을 못 잡고, 월간만 있으면 순간 폭주를 못 잡는다. 네 겹을 같이 둬야 서로의 구멍을 메운다.

누가 썼는지 알아야 막을 수 있다

예산창을 아무리 촘촘히 나눠도 그 예산이 누구 몫인지 모르면 소용없다. 귀속(attribution, 비용을 특정 단위에 정확히 연결하는 일)이 빠지면 한도 초과 알림이 와도 누구에게 연락해야 할지 모른다.

LangChain은 조직 전체, 워크스페이스, 사용자, API 키까지 네 층으로 예산을 나눴다고 한다. 모든 직원은 각 기간 단위마다 도달할 수 있는 기본 예산을 갖고, 더 많이 써야 하는 프로젝트에는 별도 예외를 걸어 뒀다. 층을 나누면 "회사 전체가 얼마 썼다"는 뭉뚱그린 숫자 대신 "이 워크스페이스의 이 사용자가 이 API 키로 얼마 썼다"까지 짚을 수 있다.

귀속이 얼마나 세밀한지는 문제를 발견했을 때 바로 드러난다. 뭉뚱그린 숫자만 있으면 "이번 주 비용이 늘었다"까지만 안다. 층이 나뉘어 있으면 "이 사용자가 이 워크스페이스에서 평소보다 세 배 더 썼다"까지 안다. 후자라야 다음 행동을 정할 수 있다.

막기만 하면 다음엔 몰래 돌아간다

한도를 걸어 두고 넘으면 바로 차단하면 되지 않을까. 실제로 해 보면 그 방식이 오히려 일을 막는다. LangChain이 내부에 먼저 이 관문을 적용해 보며(dogfooding, 만든 제품을 만든 조직이 직접 써 보는 일) 얻은 교훈 중 하나가 이거였다. runway(활주로, 한도에 닿기 전 미리 알아채고 대응할 여유 구간) 없는 한도는 그냥 일을 막을 뿐이라고.

엔지니어들이 원한 건 한도 자체를 없애는 게 아니라 한도에 닿기 훨씬 전에 조기 경고를 받고, 필요하면 빠르고 감사 가능한 방법으로 한도를 올리는 절차였다고 한다. 이 피드백을 받아들여 LangChain은 한도를 고정된 장벽에서 하나의 워크플로우로 바꿨다. 임계치에 닿기 전 단계별 경고를 추가하고, 한도를 올릴 때 기록이 남는 요청 흐름을 만드는 방향으로 움직이고 있다고 밝혔다.

이 대목이 실은 가장 인간적인 통찰이다. 규칙만 있고 숨 쉴 구멍이 없으면 사람들은 규칙을 우회할 방법을 찾는다. 관문을 피해 개인 키를 쓰거나 다른 도구로 옮겨 간다. 예외를 정식 절차로 만들어 두면 우회할 이유가 줄어든다. 막는 게 아니라 다음 행동을 정해 주는 게 진짜 통제다.

비용은 재무 보고서가 아니라 품질 신호다

비용 통제를 재무팀 보고서로만 다루면 딱 한 가지만 알 수 있다. 얼마를 썼는가. 그런데 왜 그렇게 썼는지는 알 수 없다. LangChain이 강조한 지점이 바로 이거였다. Gateway가 만드는 데이터를 trace(추적 기록), 모델 호출, 실패 사례와 함께 놓고 보면 비용 데이터가 훨씬 쓸모 있어진다고 밝혔다. 코딩 에이전트가 예상보다 많이 썼을 때 trace를 열어 무슨 일이 있었는지 이해하고, 그 관찰을 다시 에이전트 동작을 고치는 데 쓸 수 있다는 것이다.

비용이 갑자기 튀는 건 대개 사고가 아니라 신호다. 같은 작업을 반복하는 루프에 빠졌거나, 실패한 호출을 계속 재시도하거나, 컨텍스트(맥락, 모델에 매번 함께 넘기는 배경 정보)를 필요 이상으로 크게 넘기고 있을 수 있다. 비용만 보고 한도를 낮추면 이 원인은 그대로 남는다. trace까지 열어 봐야 진짜 문제가 보인다.

LangChain이 내부 롤아웃에서 확인한 또 다른 사실은 모델 가격이 고정된 표가 아니라는 점이다. 캐싱, 토큰 등급, 공급자의 잦은 가격 변경이 겹치면 예전에 맞춰 둔 조회표는 금방 낡는다. LangChain은 가격을 상수가 아니라 계속 감사하고 갱신해야 하는 시스템으로 다루고 있다고 밝혔다.

정리하면 이렇다.

• 모든 코딩 에이전트 호출을 하나의 관문으로 모았는가.
• 예산을 월·주·일·시간 단위로 겹쳐 뒀는가.
• 조직·워크스페이스·사용자·API 키까지 귀속이 갈라지는가.
• 관문을 못 지나가는 클라이언트의 사용량도 따로 집계하는가.
• 한도 초과를 차단이 아니라 조기 경고 + 감사 가능한 상향 절차로 다뤘는가.
• 비용 급증을 trace·실패 사례와 함께 원인 조사에 쓰는가.
• 모델 가격표를 상수가 아니라 주기적으로 갱신하는 시스템으로 관리하는가.

여기서부터는 LangChain 발표를 그대로 옮긴 내용이 아니라, 위 사례를 실제 팀에 적용하기 위한 필자의 운영 제안이다. 첫 단계는 새 한도를 정하는 일이 아니라 현재 호출 경로를 목록으로 만드는 일이다. 중앙 관문을 지나는 호출, 공급자에게 직접 가는 호출, 개인 키나 정액제 계정에서 발생하는 호출을 나눠야 관문이 포착하지 못하는 비용까지 볼 수 있다. 이 목록에는 담당 팀과 확인 가능한 로그 위치도 함께 적어 둔다.

두 번째 단계는 비용 기록에 최소한의 귀속 정보를 붙이는 일이다. 사용자 이름만 남기면 공용 자동화가 섞이고, API 키만 남기면 실제 담당자를 찾기 어렵다. 조직·워크스페이스·사용자·키를 함께 남기되, 각 요청이 어떤 프로젝트와 실행 환경에서 시작됐는지 연결할 수 있어야 한다. 그래야 급증 알림을 받은 사람이 단순히 한도를 낮추는 데서 멈추지 않고 해당 trace와 실패 반복을 찾아갈 수 있다.

세 번째 단계는 경고 뒤의 행동을 미리 정하는 일이다. 시간 한도의 70%, 90%, 100%처럼 임계 구간을 나누고, 각 구간에서 누가 알림을 받는지, 임시 상향은 누가 승인하는지, 언제 원래 한도로 돌아가는지를 운영 문서에 적는다. 숫자 자체는 팀의 예산과 업무 패턴에 맞춰야 한다. 중요한 것은 차단이 일어난 뒤 사람을 찾는 대신, 차단 전에 책임자와 다음 행동이 이미 정해져 있는 상태다.

마지막으로 가격 계산과 라우팅 범위를 같은 점검표에서 주기적으로 확인한다. 공급자 가격표가 바뀌었는지, 캐시 할인이 제대로 반영되는지, 새로 도입한 클라이언트가 관문을 우회하는지 따로 보면 놓치는 지점이 생긴다. 계산식과 실제 청구액의 차이, 관문 집계와 공급자 집계의 차이를 함께 기록하면 어느 쪽을 먼저 고쳐야 할지 판단하기 쉽다. 이는 LangChain이 발표한 새로운 사실이 아니라, 발표된 세 가지 교훈을 운영 순서로 재구성한 제안이다.

LangChain은 이 관문을 내부에 롤아웃한 뒤로 LLM 비용이 예산 범위 안에 머물렀다고 밝혔다. 다만 더 큰 변화는 액수 자체가 아니라 비용을 이해하는 시점이 바뀐 것이라고 강조했다. 월말에야 알던 숫자를 이제는 쓰는 순간 본다는 것이다. LangChain이 2026년 7월 30일 공개한 공식 안내에 따르면, 2026년 8월 기준 LangSmith LLM Gateway는 Public Beta(공개 베타)이며 LangSmith Plus와 Enterprise 플랜에서 제공된다. 도입 전에는 공식 채널에서 최신 제공 범위와 가격 정책을 다시 확인하는 편이 안전하다.

비용 통제는 결국 하네스 설계의 일부다. 코드 품질을 교차 검증으로 다루는 것과 같은 이야기다. 관련해서 AI 산출물을 어떻게 신뢰할지 다룬 글은 한 모델만 믿지 말고 AI 코드 교차 검증하는 법에도 정리해 뒀다. 다음 숙제는 관문을 통과하지 못하는 클라이언트의 비율을 어떻게 줄이느냐다. 지금은 우회 경로가 남아 있는 만큼 측정으로 메우고 있지만, 결국은 그 경로 자체를 좁히는 쪽이 더 근본적인 해법이다.

자주 묻는 질문

중앙 게이트웨이를 통과하지 못하는 클라이언트 사용량은 어떻게 다뤄야 하나요?

관문을 못 지나는 호출은 별도 방식으로 집계해 통제의 빈틈을 측정해야 한다. 당장은 우회 경로를 측정으로 메우되, 장기적으로는 그 경로 자체를 줄여 모든 호출이 한 통제점을 지나게 해야 한다.

월간 예산 한도 하나만 두면 왜 부족한가요?

월간 창만으로는 월초의 몰아 쓰기나 한 시간 안의 루프 폭주를 제때 막기 어렵다. 시간·일간·주간·월간 창을 겹쳐 두어 순간 폭주와 느리게 쌓이는 만성 초과를 서로 다른 창에서 잡아야 한다.

한도 초과 시 즉시 차단하는 것이 가장 안전하지 않나요?

고정 차단만 두면 필요한 작업까지 막혀 사용자가 개인 키나 다른 도구로 우회할 수 있다. 한도 전에 단계별 경고를 주고, 기록이 남는 요청 절차로 예외 상향을 허용해야 통제를 유지할 수 있다.