내 하루 토큰 사용량의 분모는 얼마인가?

이틀 전에 게임 저장소에 문서 MCP 서버를 붙였다. 문서 14개를 통째로 읽히는 대신 질문에 맞는 섹션만 돌려주게 만든 것이고, 그 과정은 따로 적었다. 그 글 끝에 나는 이렇게 썼다. get_rules 호출 기준 토큰이 13~20% 줄었다고.

그 문장을 쓸 때는 만족스러웠다. 측정을 했고 숫자가 나왔으니까.

며칠 지나고 나서 그 문장이 이상하게 걸렸다. 13~20%가 줄었다는 건 분자다. 분모는 무엇인가. 나는 하루에 토큰을 얼마나 쓰고 있나. 13%를 줄인 게 밥 한 숟갈인지 한 끼인지 나는 모르고 있었다.

모르는 채로 절감률만 적어둔 것이다.

분모를 세어보기로 했다

Claude Code는 대화 기록을 로컬에 남긴다. ~/.claude/projects/ 아래에 저장소별 디렉터리가 있고 그 안에 .jsonl 파일이 쌓인다. 각 줄이 메시지 하나고, 어시스턴트 메시지에는 usage 필드가 붙어 있다. 거기에 네 가지 숫자가 들어 있다.

input_tokens 는 캐시에 없어서 새로 읽은 입력이고, output_tokens 는 모델이 생성한 출력이다. cache_creation_input_tokens 는 캐시에 새로 쓴 입력, cache_read_input_tokens 는 캐시에서 읽은 입력이다.

이 네 개를 저장소별로 더하는 스크립트를 40줄쯤 짰다. 48개 파일, 56MB였다.

결과를 처음 봤을 때 나는 자릿수를 잘못 읽은 줄 알았다.

6억 4,619만

로블록스 게임 저장소 한 곳이 153,811,746 토큰으로 23.8% 다. 블로그 저장소 두 곳이 252,075,809 로 39.0% 라 제일 크고, 개인 앱 프로젝트 한 곳이 133,050,923 으로 20.6% 다. 책 작업 세 곳이 76,789,730 으로 11.9%, 도구와 기타 두 곳이 18,243,049 로 2.8%, 업무 관련 저장소 네 곳이 12,220,298 로 1.9% 다. 열세 곳을 합치면 646,191,555 다.

6억 4,619만 토큰이다. 메시지 수로는 4,313개.

업무 저장소는 회사 코드라 이름을 적지 않는다. 어차피 전체의 1.9%다. 이 숫자가 말해주는 건 하나뿐이다. 나는 회사에서 이 도구를 거의 안 쓰고 개인 작업에서 태우고 있다.

가장 눈에 띄는 건 첫 줄이다. 로블록스 게임 저장소 하나가 1억 5,381만이다. 전체의 23.8%.

그 저장소를 만든 기간은 이틀이다. 8월 5일에 첫 커밋이 들어갔고 8월 6일이 마지막이다. 커밋 11개, Lua 파일 43개 25,220줄, 문서 11개 2,990줄, MCP 서버 691줄. 대화 메시지는 945개였다.

이틀 만에 게임 하나를 만들면서 1억 5천만 토큰을 썼다.

그리고 표에서 두 번째로 눈에 띈 건 순서가 내 예상과 달랐다는 점이다. 나는 코드를 짜는 작업이 가장 비쌀 거라고 생각했다. 게임 로직, 리팩터링, 버그 수정 같은 것들. 실제로는 글을 쓰는 저장소 두 곳이 39%로 1위였다. 게임 저장소보다 1.6배 많다.

생각해보면 이유는 단순하다. 코드 작업은 대상 파일이 좁다. 함수 하나를 고칠 때는 그 파일과 주변 몇 개만 있으면 된다. 반면 긴 글을 쓸 때는 앞서 쓴 본문 전체가 매 턴 다시 올라간다. 만 자짜리 글을 고치면 만 자가 통째로 다시 들어간다. 그게 스무 번 반복되면 이십만 자다.

길이가 긴 산출물일수록 반복 비용이 붙는다. 이건 코드냐 글이냐의 문제가 아니라 한 덩어리로 다뤄야 하는 크기의 문제다.

이 문장을 쓰고 나서 한참 앉아 있었다. 나는 그동안 이걸 "AI로 이틀 만에 게임을 만들었다"로 기억하고 있었다. 만들기 전에 공부부터 시켰다는 글도 썼다. 그 글에서 내가 자랑한 건 순서였다. 학습을 먼저 시키고 구현을 나중에 시켰다는 것.

순서는 맞았다. 그런데 그 순서를 실행하는 데 든 비용은 한 번도 세어본 적이 없었다.

이 숫자의 96.7%는 캐시 읽기다

네 항목을 쪼개면 그림이 달라진다.

cache_read_input_tokens 가 624,975,503 으로 96.72% 다. cache_creation_input_tokens 가 15,469,033 으로 2.39%, output_tokens 가 5,688,663 으로 0.88% 다. 정작 input_tokens 는 58,356 으로 0.01% 밖에 안 된다.

모델이 실제로 생성한 글자는 568만 토큰이다. 전체의 0.88%.

나머지 99%는 읽기다. 그중에서도 거의 전부가 캐시 읽기다.

이게 무슨 뜻인지 잠깐 풀어야 한다. 에이전트에게 일을 시키면 매 턴마다 앞선 대화 전체가 다시 모델에게 들어간다. 시스템 프롬프트, 규칙 파일, 읽은 파일들, 지금까지의 대화. 턴이 쌓일수록 이 덩어리가 커지고, 매 턴 그 덩어리 전체가 다시 올라간다. 프롬프트 캐시는 이 반복되는 앞부분을 서버가 기억해두고 재계산을 건너뛰게 하는 장치다. 그래서 값이 싸다. 그래서 숫자가 이렇게 크다.

내가 945번 대화한 게임 저장소에서 캐시 읽기가 1억 5,055만이었다. 저장소 총량의 97.9%다.

한 마디 하려고 15만 토큰을 읽는다

비중보다 더 놀란 건 메시지당으로 나눴을 때였다.

전체 토큰 646,191,555 ÷ 메시지 4,313 = 메시지당 149,824
출력 토큰   5,688,663 ÷ 메시지 4,313 = 메시지당   1,319

메시지 하나를 만들 때마다 평균 14만 9,824토큰을 읽고 1,319토큰을 쓴다. 읽기와 쓰기의 비가 114 대 1이다.

게임 저장소만 따로 보면 메시지당 16만 2,764토큰이다. 전체 평균보다 높다. 945번 대화하는 동안 컨텍스트가 거의 내내 꽉 찬 상태로 돌았다는 뜻이다.

이 숫자를 다르게 놓아보면 이렇게 된다. 그 저장소의 Lua 코드는 25,220줄이다.

153,811,746 토큰 ÷ 25,220 줄 = 코드 한 줄당 6,099 토큰

코드 한 줄을 얻는 데 6,099토큰이 오갔다. 물론 이 나눗셈은 거칠다. 토큰의 상당 부분은 코드가 아니라 문서·설계·수정·되돌리기에 들어갔고, 남은 25,220줄은 그 과정의 최종 잔여물이다. 중간에 썼다가 지운 코드는 이 분모에 안 잡힌다.

그래도 자릿수는 말해준다. 나는 한 줄을 얻으려고 6천 토큰 규모의 왕복을 했다.

여기서 문서 MCP 서버 이야기로 돌아온다. 그 서버가 줄인 건 정확히 이 부분이다. 문서 14개 250KB를 통째로 읽히면 그게 컨텍스트에 박히고, 박힌 다음부터는 매 턴 다시 올라간다. 한 번 절약하는 게 아니라 남은 대화 전체에서 반복 절약된다.

13~20%라는 숫자를 나는 get_rules 호출 한 번 기준으로 쟀다. 그런데 실제 효과는 그 호출 이후 모든 턴에 누적된다. 즉 내가 잰 건 절감의 순간값이었고 총량은 아니었다.

정확히 얼마인지는 아직 모른다. 재려면 MCP 서버를 붙이기 전과 후의 같은 작업을 비교해야 하는데, 나는 붙이자마자 계속 붙여둔 채로 썼다. 대조군이 없다.

전기로 바꾸려다 실패했다

여기까지는 그냥 내 사용량 집계다. 문제는 그다음이었다.

6억 4,619만 토큰이 전기로 얼마인지 궁금해졌다. 검색해보니 추정치가 여러 개 있었다.

• 출력 토큰 기준 0.0001~0.002 Wh/token (모델 크기에 따라)
• 2,000억 파라미터 이상 프론티어 모델을 H100 노드에서 돌릴 때 질의당 중앙값 0.31 Wh
• 입출력 합쳐 500토큰짜리 표준 질의창 기준 약 3×10⁻⁴ Wh/token

세 번째 값을 총 토큰에 그냥 곱하면 이렇게 된다.

646,191,555 × 0.0003 Wh = 193,857 Wh ≈ 194 kWh

194kWh다. 한국 4인 가구 월평균 전력사용량이 대략 300kWh니까 그 3분의 2에 해당한다. 넉 달 남짓 쓴 양치고는 그럴듯해 보인다.

그럴듯해 보여서 위험하다.

이 곱셈은 틀렸다. 내 토큰의 96.7%가 캐시 읽기인데, 캐시 읽기는 prefill 재계산을 건너뛰는 경로다. 정가로 계산하면 안 된다. 얼마나 싼지는 서빙 구현에 달렸고 나는 그 구현을 모른다.

그래서 반대쪽으로 계산해봤다. 출력 토큰만 정직하게 세는 방식이다.

5,688,663 × 0.0001 Wh =   568.9 Wh ≈ 0.57 kWh
5,688,663 × 0.002  Wh = 11,377.3 Wh ≈ 11.4 kWh

0.57kWh는 전기밥솥으로 밥 한 번 짓는 정도다. 11.4kWh는 그 스무 배다. 그리고 앞의 194kWh는 여기서 또 열일곱 배다.

최저 추정과 최고 추정이 340배 차이 난다.

나는 내가 밥 한 번 지을 전기를 썼는지 두 달 치 가정용 전력을 썼는지 모른다. 넉 달 동안 매일 이 도구를 썼는데도 모른다.

이건 계산 실력의 문제가 아니다. 필요한 값을 내가 가질 수 없어서 생기는 문제다. 토큰당 전력은 어떤 모델이 어떤 하드웨어에서 어떤 배치 크기로 돌았는지, 캐시가 어디에 어떻게 얹혔는지, 그 데이터센터의 PUE가 얼마인지에 전부 달려 있다. 나는 그중 하나도 모른다. 청구서에는 달러만 찍힌다.

내가 확실히 아는 건 토큰 수 하나뿐이다. 나머지는 전부 남의 추정치를 빌려온 것이고, 빌려온 추정치끼리 340배가 벌어진다.

같은 시각 미국에서는

이 숫자를 못 풀고 있는 동안 뉴스를 봤다. 내가 못 계산한 그 전기를, 미국에서는 사람들이 고지서로 받고 있었다.

확인된 것만 시간순으로 놓는다. 아래는 전부 보도를 통해 확인한 사실이고 내가 직접 본 건 없다.

2025년 말에 데이터센터 반대 지역 단체가 약 76개였다. 2026년 3월 말에 AI 데이터센터 신규 건설을 일시 중단하는 법안이 발의됐고, 4월에 단체가 268개로 늘었다. 같은 해 1분기에 1,300억 달러 규모 75개 프로젝트가 지연되거나 취소됐는데 조직된 지역 반대가 원인의 일부로 꼽혔다. 7월 18일에는 42개 주에서 하루 142건의 반대 시위가 있었고, 7월 기준 단체는 430개에 40개 주 이상으로 퍼졌다. 같은 달 300개 이상 시와 군이 하이퍼스케일 데이터센터 건축 금지나 모라토리엄을 시행했고, 뉴욕주지사가 전국 첫 주 단위 하이퍼스케일 모라토리엄 행정명령에 서명했다.

그리고 요금이다. 데이터센터가 밀집한 주에서 전기요금이 최근 5년간 최대 267% 올랐다.

76에서 430은 여덟 달 만에 5.7배다. 4월의 268에서 7월의 430은 석 달 만에 60% 증가다. 이 곡선은 아직 꺾이지 않았다.

267%는 누구 고지서인가

이 표에서 내 눈이 가장 오래 머문 칸은 267%다.

데이터센터를 유치하면 지역에 세수가 들어온다. 건설 일자리도 생긴다. 그래서 지자체들이 세제 혜택까지 얹어가며 유치 경쟁을 했다. 여기까지는 계산이 맞는 거래처럼 보인다.

문제는 전력망이 공유 자산이라는 것이다.

수백 메가와트를 새로 끌어오려면 송전 설비를 증설해야 하고, 그 비용은 요금 기반에 얹힌다. 요금 기반에 얹힌 비용은 그 지역 전체 사용자가 나눠 낸다. 데이터센터 한 곳 때문에 늘어난 설비 비용을, 그 데이터센터를 한 번도 써본 적 없는 옆 동네 사람이 자기 고지서로 나눠 받는다.

그 사람은 자기 고지서가 왜 올랐는지 처음엔 모른다. 알게 되는 데 시간이 걸린다. 76에서 430으로 가는 여덟 달이 그 시간이었을 것이다.

시차도 한몫한다. 데이터센터 유치를 결정하는 회의와 요금이 오르는 시점 사이에는 몇 년이 있다. 설비 증설이 끝나고 요금 산정에 반영될 때쯤이면 유치를 결정한 사람은 이미 자리에 없을 수도 있다. 결정하는 사람과 청구서를 받는 사람이 다르고, 심지어 시점도 다르다.

세제 혜택은 이 비대칭을 한 겹 더 얹는다. 유치를 위해 재산세를 깎아주면 세수는 예상보다 덜 들어오는데 전력 설비 비용은 예정대로 요금에 얹힌다. 계산이 맞아 보이던 거래에서 들어오는 쪽이 줄고 나가는 쪽은 그대로다.

300개 넘는 시·군이 금지나 모라토리엄을 건 건 이 계산을 다시 해본 결과일 것이다. 1분기에 1,300억 달러어치 프로젝트가 멈춘 것도 마찬가지다. 사업자 입장에서 보면 이건 규제 리스크가 아니라 입지 자체가 줄어드는 문제다. 전력이 싸고 땅이 넓은 곳을 찾아가는 게 데이터센터 입지의 기본인데, 그 조건을 만족하는 지역이 하나씩 문을 닫고 있다.

이 구조가 낯익다. 나는 얼마 전에 비슷한 모양의 글을 썼다. 노후 서버 패치를 미룬 결정은 매번 옳아 보였고, 청구서는 미룬 사람이 아니라 사고가 났을 때 그 자리에 있던 사람에게 왔다는 이야기였다.

여기서도 비용을 만든 쪽과 비용을 받는 쪽이 다르다. 다만 이번엔 내가 받는 쪽이 아니다.

나는 만드는 쪽이다.

1억 5천만 토큰을 태워서 게임을 만든 사람이 나다. 그 계산이 어느 데이터센터에서 돌았는지, 그 데이터센터가 어느 동네 전력망에 붙어 있는지, 그 동네 고지서가 얼마나 올랐는지 나는 모른다. 알 방법도 없다. 내 화면에는 응답만 돌아온다.

이 비대칭이 이 글의 진짜 주제다. 내 쪽에서는 어떤 물리적 신호도 오지 않는다. 팬이 도는 소리도 안 나고 방이 더워지지도 않는다. 노트북은 미지근하다. 실제 열은 내가 모르는 어딘가에서 나고, 그 열을 식히는 비용은 내가 모르는 누군가의 고지서에 들어간다.

절감은 미덕이 아니라 청구서 읽기다

이 지점에서 내가 처음에 만족스러워했던 문장으로 돌아온다.

"토큰이 13~20% 줄었다."

나는 이 문장을 최적화 성과로 썼다. 문서를 통째로 읽히는 대신 필요한 섹션만 주니까 효율이 올랐다는, 엔지니어링 자랑이었다.

지금 다시 보면 그 문장은 성과가 아니라 내가 청구서를 처음으로 들여다본 기록이다. 다만 그때는 청구서인 줄 모르고 봤다.

차이가 있다. 최적화는 하면 좋고 안 해도 그만인 일이다. 청구서는 다르다. 청구서는 누군가 이미 지불한 것의 명세다.

여기서 조심할 게 하나 있다. 나는 지금 "AI를 쓰지 말자"는 얘기를 하는 게 아니다. 나는 계속 쓸 것이고 내일도 쓸 것이다. 이 도구로 만든 결과물이 실제로 있고, 그건 넉 달치 6억 4천만 토큰이 실제로 뭔가로 바뀌었다는 뜻이다.

그리고 개인이 토큰을 아껴서 전력망 문제가 풀리지도 않는다. 내 568만 출력 토큰은 하이퍼스케일 사업자의 하루 처리량에서 반올림하면 사라지는 크기다. 이건 텀블러를 들고 다니면 기후가 해결된다는 식의 이야기가 아니다.

내가 말하려는 건 훨씬 좁다. 자기가 쓴 양을 아는 것과 모르는 것은 다르다.

넉 달 동안 나는 모르고 썼다. 세어보기 전까지 나는 내 사용량의 자릿수도 못 맞혔다. 1억 대일 거라고 생각했는데 6억이었다. 그리고 세어보고 나서야 절감률 13%의 분모가 무엇인지, 그게 어느 정도 크기의 절감인지 감이 잡혔다.

MCP 서버로 문서를 쪼개 준 건 전기를 아끼려고 한 일이 아니었다. 에이전트가 규칙을 더 정확히 읽게 하려고 한 일이었다. 그런데 결과적으로 같은 방향이었다. 필요한 것만 읽히면 정확도가 오르고, 반복해서 올라가는 덩어리가 줄고, 태우는 양이 준다. 세 가지가 같은 조치에서 나온다.

이게 실용적인 결론이다. 컨텍스트를 줄이는 작업은 절약 캠페인이 아니라 정확도 작업이고, 절약은 그 부산물로 따라온다. 반대로 하면 잘 안 된다. 아끼자고 컨텍스트를 줄이면 에이전트가 알아야 할 걸 못 읽어서 헛다리를 짚고, 헛다리를 정정하느라 턴이 늘고, 턴이 늘면 매 턴 올라가는 덩어리가 다시 커진다.

세어보고 나서 바꾼 세 가지

집계 결과를 보고 실제로 손댄 게 있다. 대단한 건 아니고 셋 다 십 분 안에 끝나는 것들이다.

하나, 규칙 파일을 통째로 읽히지 않게 했다. 앞서 말한 문서 MCP 서버가 이 조치였다. 문서 14개 250KB를 컨텍스트에 얹으면 그게 남은 대화 내내 매 턴 따라다닌다. 질문에 맞는 섹션만 돌려주게 바꾸면 그 꼬리가 짧아진다. 효과가 한 번이 아니라 누적이라는 걸 이번에 숫자로 확인했다.

둘, 긴 산출물은 파일로 내보내고 컨텍스트에서 뺐다. 만 자짜리 글을 대화 안에서 계속 굴리면 만 자가 매 턴 왕복한다. 파일에 쓰고 필요할 때 필요한 부분만 다시 읽으면 그 왕복이 사라진다. 글 저장소가 39%였던 이유가 정확히 이거였다.

셋, 세션을 길게 끌지 않기로 했다. 메시지당 15만 토큰은 컨텍스트가 꽉 찬 채로 돌고 있다는 신호다. 작업이 한 단락 끝나면 정리하고 새로 시작하는 게, 같은 세션에서 백 턴을 더 가는 것보다 싸다. 그리고 대체로 결과도 더 낫다. 컨텍스트가 길어질수록 앞쪽에 깔린 낡은 맥락이 판단을 흐리기 때문이다.

셋 다 원래는 정확도를 위해 하던 일이었다. 비용 측면에서도 같은 방향이라는 걸 이번에 알았다.

다만 정직하게 덧붙이면, 이 세 가지가 실제로 얼마를 줄였는지는 아직 안 쟀다. 조치하고 나서 며칠밖에 안 됐고, 앞서 말한 대로 대조군을 안 남겼다. 다음 집계 때 확인할 항목으로 적어뒀다.

내가 확인하지 못한 것

이 글에서 내가 직접 잰 건 토큰 수 하나다. 나머지는 전부 남의 숫자를 빌렸고, 빌린 것에는 한계가 있다. 정리해둔다.

우선 집계가 전수가 아니다. ~/.claude/projects/ 아래에 저장소 디렉터리가 22개 있는데 usage 기록이 남아 있는 건 13개뿐이다. 나머지 9개는 0으로 나온다. 그중 하나는 커밋 219개에 넉 달 동안 작업한 Unity 게임 저장소다. 그 저장소에서 토큰을 안 썼을 리가 없다. 기록이 지워졌거나, 다른 형식으로 남았거나, 다른 도구로 작업했거나 셋 중 하나인데 어느 쪽인지 확인하지 못했다.

그러니까 6억 4,619만은 하한이다. 실제로는 이보다 크다. 얼마나 큰지는 모른다.

전력 환산에도 성공하지 못했다. 위에서 340배 범위가 나왔다고 썼는데, 그건 "대략 이 사이 어딘가"라는 뜻이 아니다. 340배가 벌어지면 그 범위는 정보가 아니다. 나는 계산을 한 게 아니라 계산이 안 된다는 걸 확인했다. 194kWh라는 숫자를 이 글에 적어둔 건 그게 답이어서가 아니라, 그럴듯한 곱셈이 얼마나 쉽게 나오는지 보여주려고 적었다.

미국 데이터센터 통계와 내 토큰 사이에는 직접 연결이 없다. 내가 쓴 계산이 미국에서 돌았는지도 확실하지 않고, 돌았다 해도 어느 주인지 모른다. 두 이야기를 한 글에 놓은 건 인과를 주장하려는 게 아니라, 한쪽 끝(내 화면)과 다른 쪽 끝(누군가의 고지서) 사이가 이렇게까지 안 보인다는 걸 말하려는 것이다.

MCP 서버의 총 절감량도 아직 못 쟀다. 대조군을 안 남겼기 때문이다. 다음에 비슷한 걸 붙일 때는 붙이기 전 며칠치를 먼저 집계해두려고 한다. 그러면 전후 비교가 되고, 그때는 "13~20%"가 아니라 "며칠에 몇 토큰"으로 적을 수 있다.

못 잰 것들

절감률을 적으려면 분모를 알아야 한다. 나는 분모를 모르고 분자만 적었고, 그걸 며칠 뒤에야 알아챘다.

세어보는 데 든 시간은 40줄짜리 스크립트 하나였다. 그 40줄이 넉 달치 자릿수를 고쳐줬다.

내가 태운 전기가 얼마인지는 여전히 모른다. 그건 아마 계속 모를 것이다. 그런데 모른다는 걸 아는 것과 처음부터 생각조차 안 한 것은 다르다. 지금은 최소한 내가 뭘 모르는지 안다. 토큰은 6억 4,619만 이상이고, 그중 96.7%가 캐시 읽기이며, 메시지 하나마다 15만을 읽고 1,300을 쓰고, 전력 환산 계수를 나는 못 구한다.

다음에 또 절감률을 적게 되면 분모부터 적으려고 한다. "13% 줄었다"가 아니라 "몇에서 몇으로 줄었다"로. 분자만 적힌 숫자는 성과처럼 보이지만 실제로는 아무것도 말해주지 않는다는 걸 이번에 배웠다.

그리고 그 계수를 못 구하는 동안, 미국의 42개 주에서는 하루에 142번 시위가 있었다.