사용량이 얼마나 남았는지는 알겠는데, 어느 작업에서 왜 소모됐는지는 모르겠다. 코딩 도구와 자동화 작업을 함께 돌리면 이런 문제가 생긴다. 한도가 빨리 닳았다는 사실만으로는 모델을 바꿔야 할지, 같은 요청이 반복되는지 판단하기 어렵다.
개발자 재러드 시걸(Jared Siegel)은 10월 18일 공개한 글에서 자신이 관리하는 LLM 프록시의 요청 기록을 보여줬다. LLM 프록시는 클라이언트와 언어모델 제공자 사이에서 요청을 전달하는 서버다. 시걸이 강조한 것은 특정 제품의 도입이 아니라, 어느 키와 클라이언트가 언제 어떤 모델을 호출했는지 운영자가 직접 볼 수 있어야 한다는 점이다.
사용량 비중을 알아도 원인을 찾기 어려운 까닭
원문에 실린 사용량 화면은 2026년 9월 19일부터 10월 18일까지의 소비를 기능별로 보여준다. ‘분류 불명(Unknown)’이 71.8%, 대화가 16.8%, 서브에이전트가 11.4%다. 자동 검토·시스템·음성 대화는 각각 0.1% 미만으로 표시된다. 이 화면의 안내에 따르면 일반 Chat 대화는 집계에 포함되지 않는다. 따라서 이 숫자를 계정 전체의 모든 대화 비용으로 읽어서는 안 된다.
분류 불명이 큰 비중을 차지한다는 사실은 보인다. 하지만 그 안에서 어느 작업이 반복됐는지, 어떤 모델이 호출됐는지는 이 집계만으로 좁힐 수 없다. 그래프가 세밀해져도 기록의 단위가 계속 기능별 합계라면 같은 문제가 남는다. 비용을 줄이려면 기능별 합계에서 해당 작업의 호출 기록으로 내려가 볼 수 있어야 한다.
요청 한 건에 시간과 키 이름이 함께 붙으면
시걸이 공개한 프록시 화면은 요청 시각, 종류, 성공 여부, 세션 ID와 요청 ID를 행별로 보여준다. 비용과 소요 시간, 첫 토큰까지 걸린 시간(TTFT), 팀 이름, 키 별칭도 같은 행에서 볼 수 있다. ‘jared-laptop’과 ‘n8n’처럼 호출 주체를 구분할 수 있는 별칭이 있어 노트북에서 쓴 요청과 자동화 요청을 나눠 살필 수 있다.
예를 들어 화면 맨 위의 세션 합계는 비용 0.053142달러, 소요 시간 310.81초로 표시돼 있다. 아래에는 개별 LLM 요청과 MCP 호출이 따로 나온다. 도구나 외부 데이터에 접근하는 MCP 호출 행 중에는 비용이 비어 있는 것도 있다. 이 빈칸을 무료라는 뜻으로 바꾸거나, 세션 합계와 개별 요청 비용을 다시 더하면 화면이 말하지 않는 결론을 내리게 된다.
이런 기록이 있으면 특정 시간대에 오래 걸린 요청을 찾고, 같은 키로 발생한 다른 요청과 비교할 수 있다. 첫 응답이 늦었는지 전체 처리가 길었는지도 구분된다. 시걸은 코딩 도중 캐시 미스가 생기면 그 이유를 수작업으로 약 20초 안에 짚을 수 있다고 썼다. 공개 화면에는 캐시 원인 분석 과정 대신 요청별 비용과 지연 기록이 나온다. 사용하는 프록시에 API가 있어 분석을 자동화할 여지도 있다고 덧붙였다.
주 키 하나를 여러 도구에 복사하지 않는 방법
시걸이 든 또 다른 이유는 가상 API 키다. 모델 제공자의 주 키를 모든 작업과 에이전트에 흩어 두는 대신, 프록시가 관리하는 가상 키를 클라이언트에 나눠 주는 방식이다. 요청을 전달하는 지점에서 키를 구분하므로 호출 기록에도 그 구분을 붙일 수 있다.
여러 제공자와 모델을 자신이 관리하는 단일 접속 주소 뒤에 둘 수 있다는 점도 연결된다. 도구마다 접속 설정을 다시 고치는 부담을 줄이고, 모델이나 제공자를 바꿀 때 중간 서버에서 조정할 수 있다. 시걸은 자신의 프록시를 관찰 기능과 사용자 정의 MCP 서버 접속 지점 등을 위해 수정했다고 밝혔다. 어떤 프록시 제품인지는 추천하지 않았다.
프록시를 추가하기 전에 정할 기록의 범위
이 경험을 곧바로 ‘모든 사용자는 프록시를 직접 운영해야 한다’는 결론으로 옮길 필요는 없다. 구독 서비스의 사용량 화면과 모델 API를 중계하는 서버는 관찰할 수 있는 범위가 다르다. 프록시를 지나지 않는 앱 내부의 호출까지 저절로 기록되지는 않는다. 이미 필요한 요청 기록을 제공하는 도구를 쓰고 있다면, 서버를 하나 더 만드는 것보다 그 기록을 먼저 살피는 편이 낫다.
직접 운영한다면 기록을 남기는 서버의 장애와 접근권한도 관리해야 한다. 요청을 식별하려고 프롬프트와 응답 전문을 모두 저장할 필요는 없다. 어떤 키·클라이언트·모델이 호출됐는지와 시각, 상태, 사용량 등 원인 추적에 필요한 항목부터 정하고, 본문 데이터는 업무상 필요한 범위에서 보관 기간과 열람 권한을 따로 정하는 편이 안전하다.
다음에 사용량이 예상보다 빨리 늘었다면 먼저 어느 작업의 어느 요청까지 확인할 수 있는지 살펴보자. 호출을 구분할 수 있게 됐다면 완료한 작업 단위로 비용을 비교하는 방법으로 분석 범위를 넓힐 수 있다.
출처: Jared Siegel, 직접 운영하는 LLM 프록시의 관찰 가능성에 관한 글 (2026년 10월 18일)