하루 222M은 많은 걸까, 토큰 소모량을 서로 재본 하루

전날 밤, 새 모델을 써보니 어떠냐는 물음에 성능이 아니라 소모량이 먼저 돌아왔다. 체감이 확 된다는 반응이었는데 그 대상이 결과물 품질이 아니라 토큰이었다는 점이 이날 화제의 방향을 정했다.

"체감이 확 됩니다! 토큰이 녹는게;;;"

같은 시간대에 반론에 가까운 후기도 붙었다. 자신은 상대적으로 덜 녹는 편이라며 평소 쓰는 노력 수준과 요금제를 함께 밝힌 사례였다. 같은 모델을 써도 설정과 작업 성격에 따라 소모량 체감이 갈린다는 점이 여기서 드러났다.

"약간 덜 녹긴함요"

아침에는 질문의 형태가 바뀌었다. 회사 사용량 대시보드를 처음 발견했다는 참가자가 하루 평균 222M 토큰이면 많이 쓰는 편이냐고 물은 것이다. 개발자로 일하면서도 주변에 물어볼 사람이 없어 기준을 몰랐다는 배경 설명이 붙었다.

"하루에 222M 토큰 쓰면 많이 쓰는거에요? 제가 개발자인데 회사 사용량 대시보드를 좀전에 발견했는데 평균 그렇게쓰네요"

돌아온 답은 기준선이 그보다 훨씬 위에도 있다는 것이었다. 헤비 사용자가 몰린 표본이라 평균은 아니라는 단서가 붙긴 했지만, 하루 30억 토큰이라는 사례가 언급됐고 자신이 가장 많이 쓴 날은 400억 토큰이었다는 회고도 나왔다. 많이 쓰는 것 자체가 중요한지 되묻는 반응도 함께였다.

"저도 제일많이 썼던날이 400억토큰썼던날이었던거 같아요"

낮에는 한도에 걸려 작업이 끊겼을 때 어떻게 잇느냐는 실무 질문이 올라왔다. 진행한 지점을 파악해서 이어서 하라고 지시하는 방식은 비효율적이라는 문제 제기였다. 답변은 두 갈래였다. 하나는 남은 할당량을 보면서 미리 정리 문서를 만들어 넘기는 방식이고, 다른 하나는 디스크에 남아 있는 대화 세션 파일을 다른 도구가 직접 찾아 읽게 하는 방식이었다.

"적당하게 할당량 보고 핸드오프 만든 다음에 넘겨주기?"

"codex 로 옮겨도 하드에서 클로드 대화세션 찾아서 직접 읽으라고하면 세션 찾아서 읽던데용"

문제는 그 타이밍을 놓치기 쉽다는 데 있었다. 정리 문서를 만들어 두려다가 한눈팔면 끝까지 소진해버린다는 토로가 붙었고, 딱히 더 나은 방법이 없다는 정리로 이 대목은 닫혔다.

오후에는 사용량 표시 자체를 믿기 어렵다는 이야기가 나왔다. 앱에서 잔여량이 50퍼센트로 보이다가 업데이트 후 다시 켜니 10퍼센트로 표시됐다는 보고였다. 당분간 업데이트를 미루라는 조언이 붙었고, 동기화 오류가 잦으니 명령줄 도구에서 확인하는 편이 오차가 적다는 경험이 이어졌다.

"동기화 에러나는경우가 워낙 많더라구요, 그나마 cli에서 사용하면서 남은 양 체크하는게 제일 오차가 적긴하더라구요"

하루를 통과한 흐름을 놓고 보면 세 층위가 겹쳐 있다. 얼마나 쓰는지 기준선이 공유돼 있지 않고, 남은 양을 알려주는 표시도 신뢰가 흔들리며, 끊겼을 때 이어붙이는 절차는 각자 손으로 만들고 있다. 성능 비교만큼이나 소모량 관리가 작업 설계의 변수가 됐다는 뜻으로 읽힌다.