토큰을 어디에 얼마나 썼는지 모르면 통제가 안 된다 — OpenClaw가 멀티 프로바이더 사용량을 집계한 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰면서 화면을 하나씩 뜯어봤다. 그중 의외로 인상 깊었던 게 "Usage"(사용량) 메뉴였다. AI 에이전트는 클로드(Anthropic), GPT(OpenAI), 로컬 모델(Ollama) 같은 여러 LLM 프로바이더를 한꺼번에 섞어 쓴다. 그런데 이걸 며칠 굴리고 나면 단순한 질문 하나에 답을 못 하게 된다 — "지난주에 토큰을 얼마나 썼지? 그 비용은 어디서 나왔지? 클로드야, GPT야?" 이 글은 그 "모름"이 왜 통제 불능으로 이어지는지, 그리고 OpenClaw의 Usage 화면이 프로바이더별 사용량과 비용을 어떻게 집계해 그 질문에 답하는지를 따라간다.

배경 — 에이전트는 "여러 청구서가 동시에 늘어나는 시스템"이다

예전 챗봇은 모델 하나에 연결돼 있었다. 비용을 알고 싶으면 그 프로바이더의 대시보드 하나만 보면 됐다. 하지만 OpenClaw 같은 에이전트는 다르다. 같은 봇이 대화는 클로드로, 코드 작업은 GPT로, 가벼운 요약은 로컬 모델로 돌리도록 모델을 갈아 끼우며 일한다. 게다가 한 번의 답변 안에서도 토큰은 여러 종류로 쪼개진다.

다이어그램 설명. 이 그림은 에이전트 한 대가 실제로는 여러 프로바이더(LLM을 제공하는 회사·서버)에 동시에 연결돼 있고, 게다가 한 번의 응답조차 단일 숫자가 아니라 여러 종류의 토큰으로 나뉜다는 걸 보여준다. 토큰(token)은 모델이 글자를 처리하는 최소 단위로, 입력 토큰(질문)과 출력 토큰(답변)은 가격이 다르고, 여기에 캐시 읽기·쓰기(prompt caching — 같은 맥락을 다시 보낼 때 재계산을 건너뛰려고 저장해 두는 부분)까지 별도 단가로 붙는다. 핵심은 "청구서가 하나가 아니다"라는 점이다 — 프로바이더 수만큼, 그리고 토큰 종류 수만큼 비용 항목이 늘어난다. 흔한 오해가 "에이전트 비용 = 토큰 개수 하나"라는 가정인데, 실제로는 어느 프로바이더의 어떤 토큰이냐에 따라 단가가 다 다르다. 그래서 합계 하나만으로는 "왜 이만큼 나왔는지"를 설명할 수 없다.

핵심 문제 — 합계 하나로는 아무것도 통제하지 못한다

가장 단순한 사용량 화면은 "이번 달 총 토큰 1,200만 개, 추정 비용 $18"처럼 큰 숫자 하나를 보여주는 것이다. 이게 왜 부족한지는 실제 상황을 그려 보면 드러난다. 어느 날 비용이 평소의 세 배로 튀었다고 하자. 합계만 보는 화면 앞에서 할 수 있는 건 막막함뿐이다.

다이어그램 설명. 이 그림은 "큰 숫자 하나"만 보여주는 사용량 화면이 비용 급증 앞에서 어떻게 막히는지를 보여준다. 위에서 던진 비용 급증이라는 사건이 세 갈래 질문으로 갈라지는데 — 어느 프로바이더가 원인인지, 어떤 종류의 토큰이 늘었는지, 어느 에이전트·채널이 썼는지 — 합계 하나만으로는 셋 다 답할 수 없어 모든 갈래가 맨 아래 "손 못 댐"으로 모인다. 이 패턴을 쓴 이유는, 통제(control)란 결국 "원인을 특정해 그 부분만 손대는 능력"인데 합계 화면은 그 특정 단계 자체를 막아버린다는 걸 보이기 위해서다. 놓치기 쉬운 함정은 "숫자를 보여주면 사용량을 추적한 것"이라는 착각이다 — 보여주는 것과 분해할 수 있게 보여주는 것은 전혀 다르다. 쪼갤 수 없는 숫자는 정보가 아니라 불안만 준다.

그래서 통제 가능한 사용량 화면이 풀어야 할 문제는 분명하다. 같은 사용량 데이터를 프로바이더별·모델별·토큰종류별·에이전트별로 동시에 쪼개어, 큰 숫자 하나를 "누가, 무엇으로, 어떤 토큰을" 썼는지로 분해해야 한다. 이게 안 되면 사용자는 비용을 줄이려 해도 어디를 줄일지 모른다.

해결 방법 — 세션 로그 한 벌을 여러 축으로 동시에 집계한다

OpenClaw의 Usage 화면은 별도의 사용량 데이터베이스를 따로 두지 않는다. 대신 봇이 이미 남기는 세션 로그(session log — 각 대화 세션이 어떤 모델로 토큰을 얼마나 썼는지 기록한 항목)를 단일 원본으로 삼아, 이 한 벌을 화면에서 여러 집계 축(aggregate — 같은 데이터를 특정 기준으로 묶어 합산한 결과)으로 동시에 펼친다.

다이어그램 설명. 이 그림은 Usage 화면의 핵심 설계를 보여준다 — 맨 위 세션 로그라는 단 하나의 원본을 그 아래 다섯 개의 집계 축(프로바이더·모델·에이전트·채널·날짜)으로 동시에 펼치는 구조다. 한 세션이 들어오면 화면은 그 세션의 프로바이더 이름으로 한 묶음에 더하고, 동시에 모델 이름으로 다른 묶음에, 또 에이전트·채널·날짜 묶음에도 같은 값을 더한다. 이 패턴(원본 하나 → 여러 축 동시 집계)을 고른 이유는 앞 절의 세 갈래 질문에 한 화면에서 동시에 답하기 위해서다. 비용이 튀었을 때 프로바이더 묶음을 보면 클로드인지 GPT인지가, 모델 묶음을 보면 어느 버전인지가, 에이전트·채널 묶음을 보면 텔레그램 봇인지 cron 작업인지가 곧바로 드러난다. 함정은 "집계 축마다 별도 저장소가 필요하다"고 생각하는 것이다 — OpenClaw는 저장은 세션 로그 한 곳에만 하고, 쪼개기는 화면에서 매번 계산한다. 그래서 원본과 화면 사이에 어긋남(drift)이 생기지 않는다.

비용을 토큰 종류별로 쪼개는 이유 — 캐시가 깨졌는지 보이게

각 집계의 합계 항목(코드에서 UsageTotals)은 토큰을 단일 숫자로 뭉치지 않는다. 입력·출력·캐시 읽기·캐시 쓰기를 각각의 토큰 수와 각각의 추정 비용으로 따로 들고 있다. 왜 이렇게까지 쪼개는지는 코드의 누적 구조를 보면 분명하다.

다이어그램 설명. 이 그림은 세션 하나의 사용량이 합계로 누적될 때 토큰과 비용이 네 종류(입력·출력·캐시 읽기·캐시 쓰기)로 따로따로 더해지고, 거기에 더해 "가격을 모르는 항목 수"까지 별도로 센다는 걸 보여준다. 네 항목이 각각의 토큰 수와 비용을 차례로 쌓아 합계로 모이는 흐름이다. 이렇게 쪼개는 이유는 같은 "비용 1달러"라도 정상인지 비정상인지를 구별하기 위해서다 — 예를 들어 캐시 읽기 비중이 높으면 같은 맥락을 효율적으로 재사용 중이라는 건강한 신호이고, 반대로 어느 날부터 캐시 읽기가 사라지고 입력 토큰이 폭증했다면 프롬프트 캐시가 깨져 매번 전체 맥락을 다시 비싼 입력으로 보내고 있다는 위험 신호다. 합계만 보면 둘 다 "비용 증가"로 똑같이 보이지만, 토큰 종류별로 쪼개면 원인이 다르다는 게 드러난다. 맨 아래 갈래가 중요한 함정 하나를 짚는다 — 토큰은 분명히 썼는데 비용이 0으로 잡히는 경우다. 이건 그 모델의 로컬 가격표가 설정돼 있지 않다는 뜻이고, OpenClaw는 이런 항목 수를 따로 세어 "비용이 실제보다 적게 보일 수 있다"는 경고를 띄운다. 비용 0을 "공짜"로 오해하지 않게 막아 주는 장치다.

추정 비용 vs 프로바이더 실제 잔량 — 섞으면 안 되는 두 숫자

여기서 OpenClaw가 의도적으로 구분하는 두 종류의 "사용량"이 있다. 하나는 Usage 화면이 보여주는 로컬 추정 비용이고, 다른 하나는 프로바이더가 직접 알려주는 실제 잔량(quota)이다. 둘은 출처도 신뢰도도 다르다.

▲ 추정 비용 — 내가 가진 로그로 계산한 값

다이어그램 설명. 이 그림은 Usage 화면이 보여주는 비용이 어떻게 만들어지는지를 보여준다. 봇이 자기 세션 로그에 적어 둔 토큰 수에, 사용자가 설정해 둔 로컬 가격표를 곱해 비용을 추정한다. 이 방식의 장점은 프로바이더에 따로 물어보지 않고 내 데이터만으로 즉시 계산된다는 것이고, 한계는 명확하다 — 어떤 모델의 가격을 설정하지 않았으면 그 부분은 0으로 빠져 실제보다 싸게 보인다(앞에서 본 비용 누락 경고가 이걸 잡는다). 즉 이 숫자는 "정확한 청구서"가 아니라 "내 기록 기준 추정"이다.

▲ 실제 잔량 — 프로바이더에게 직접 물어본 값

다이어그램 설명. 이 그림은 다른 경로를 보여준다. 채팅의 사용량 커맨드나 명령줄 도구는 클로드·GitHub Copilot·Gemini·OpenAI Codex·MiniMax 같은 프로바이더의 사용량 API(quota — 요금제 안에서 얼마나 남았는지 알려주는 엔드포인트)를 직접 호출해, 거기서 받은 값을 추정 없이 그대로 보여준다. 표시는 프로바이더마다 제각각인 형식(소비량·잔여량·원시 카운트)을 "X% 남음"이라는 한 가지 형태로 정규화한다. 두 다이어그램을 같은 축에서 비교하면 차이가 분명하다 — 추정 비용은 내 로그로 계산한 추정치라 비용(달러)을 말하지만 부정확할 수 있고, 실제 잔량은 프로바이더가 알려준 사실값이라 정확하지만 비용이 아니라 "요금제의 몇 %가 남았나"를 말한다. OpenClaw가 이 둘을 굳이 다른 화면·다른 명령으로 분리해 둔 이유가 여기 있다 — 추정과 사실을 한 숫자로 뭉쳐 버리면 사용자가 "이게 진짜 청구될 돈인가, 내 계산인가"를 구별하지 못하기 때문이다. 함정은 Usage 화면의 $18을 "이번 달 실제 청구액"으로 오해하는 것이다. 그건 어디까지나 내 가격표 기준 추정이고, 진짜 잔량은 프로바이더에게 따로 물어야 한다.

필터로 같은 데이터를 다시 좁힌다

집계 축을 나눠 놓아도, 사람이 실제로 던지는 질문은 "지난 7일 동안 클로드만, 텔레그램 채널에서, 비용 기준으로 얼마"처럼 여러 조건이 겹친다. Usage 화면은 같은 세션 로그에 필터를 겹쳐 씌워 이 질문에 답한다.

다이어그램 설명. 이 그림은 전체 세션 로그가 여러 단계의 필터를 통과하며 좁혀지는 흐름을 보여준다. 위에서부터 기간을 고르고(오늘·7일·30일 같은 버튼이 있다), 프로바이더·모델·채널·에이전트·도구 같은 축으로 거르고, provider:anthropic 같은 검색어 토큰을 더 얹은 뒤, 마지막으로 화면을 토큰 기준으로 볼지 비용 기준으로 볼지 고른다. 중요한 점은 필터가 걸릴 때마다 화면이 좁혀진 집합만으로 합계·집계·차트를 다시 계산한다는 것이다 — 미리 만들어 둔 요약을 잘라 보여주는 게 아니라, 그 조건에 해당하는 세션만 골라 처음부터 다시 합산한다. 이 패턴 덕분에 어떤 조건 조합이든 정확한 숫자가 나온다. 맨 아래 갈래가 실용적 마무리다 — 좁힌 결과를 CSV(표 계산용)나 JSON(프로그램 처리용)으로 내보낼 수 있어, 화면 안에 갇히지 않고 가계부나 외부 분석으로 가져갈 수 있다.

결과 — "모름"이 "특정"으로 바뀐다

이 구조가 들어오면서 앞에서 막혔던 비용 급증 시나리오가 이렇게 풀린다.

합계 하나만 보던 때	프로바이더별 집계가 생긴 뒤
비용이 튀어도 어느 프로바이더 탓인지 모름	프로바이더별 묶음에서 클로드·GPT·로컬을 즉시 구분
입력·출력·캐시가 한 숫자로 뭉쳐 원인 불명	토큰 4종을 분리 — 캐시가 깨졌는지까지 보임
비용 0을 공짜로 오해	가격표 없는 항목을 세어 "비용 누락" 경고
추정과 실제 잔량을 한 숫자로 혼동	로컬 추정 비용과 프로바이더 실제 잔량을 분리
"클로드만, 지난주, 텔레그램" 같은 질문 불가	기간·프로바이더·채널 필터를 겹쳐 정확히 조회

정리하면, OpenClaw의 Usage 메뉴가 한 일은 화려한 기능이 아니라 "통제의 전제 조건인 분해 가능성"을 채운 것이다. 여러 LLM 프로바이더를 섞어 쓰는 에이전트에서 비용과 토큰은 가만히 둬도 여러 갈래로 늘어난다 — 그걸 합계 하나로 보면 불안만 남고, 프로바이더별·모델별·토큰종류별로 쪼개어 보면 비로소 "여기를 줄이자"가 가능해진다. 자율적으로 며칠씩 돌아가는 에이전트일수록 이 분해 능력은 더 중요해진다. 사람이 매 응답을 지켜보지 않는 대신, 나중에 로그를 펼쳐 "지난 사흘간 무엇에 얼마를 썼는지"를 정확히 되짚을 수 있어야 안심하고 맡길 수 있기 때문이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.