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

주간 청구서에 개발자 한 명 이름 옆으로 몇천 달러가 찍혀 있으면 그때야 알아챈다. 누가 막을 새도 없이 이미 쓴 돈이다. 코딩 에이전트를 굴리는 팀 대부분이 겪는 장면이고, 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은 가격을 상수가 아니라 계속 감사하고 갱신해야 하는 시스템으로 다루고 있다고 밝혔다. 표시된 모델 이름과 실제로 호출된 모델이 다를 수 있다는 점도 같은 맥락이다. 화면에 뜨는 이름을 그대로 믿기보다 실제 로그로 확인하는 습관이 필요하다.

정리하면 이렇다.

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

LangChain은 이 관문을 내부에 롤아웃한 뒤로 LLM 비용이 예산 범위 안에 머물렀다고 밝혔다. 다만 더 큰 변화는 액수 자체가 아니라 비용을 이해하는 시점이 바뀐 것이라고 강조했다. 월말에야 알던 숫자를 이제는 쓰는 순간 본다는 것이다. 참고로 LangSmith LLM Gateway는 이 글을 쓰는 시점 기준 private beta(제한적 사전 공개) 상태로 알려져 있으니, 실제 도입을 검토한다면 최신 공개 범위와 가격 정책은 공식 채널에서 다시 확인하는 편이 안전하다.

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