토큰이 새는 자리는 모델이 아니었다 — 1시간 만에 계정 다섯 개가 녹은 뒤 나온 점검 권고

오후 1시 55분, 한 참가자가 토큰이 빨리 닳는 원인을 모델 탓으로만 돌리지 말자는 얘기를 꺼냈다. 쓰는 사람이 프롬프트를 잘못 쓴 경우도 있고, 프롬프트와 무관하게 AI가 관리를 잘못하는 경우도 있다는 지적이었다. 대화가 길어지면서 구체적인 작업 지침이 무시되는 상황도 같은 원인으로 묶였다.

"토큰소모량 큰게 모델자체 잘못도있지만 저희가 프롬프트를 잘못쓰거나, 아니면 프롬프트 상관없이 ai가 잘못관리하는 경우도 있거든요? 컨텍스트가 길어지면서 구체적인 작업지침을 무시해서 발생하는 경우도 있고"

이어 나온 처방은 아끼라는 훈계가 아니라 재보라는 권고였다. 최근 작업 세션들을 주기적으로 열어 사용량 비중만 볼 게 아니라, 어디서 많이 새는지와 왜 새는지, 그 소모가 합당한지까지 한 번씩 돌려보라는 것이다.

"그래서 주기적으로 최근 작업세션들에 대해 토큰사용량 비중뿐 아니라 어디서 많이 새고 어떤이유로 많이 새는지, 합당한지 한번씩 점검돌려보시길 바랍니다"

1시간에 계정 다섯 개

추상적인 조언이 아니라는 근거는 곧바로 따라왔다. 13시 59분, 지난주 1시간 만에 계정 다섯 개의 사용량이 녹아버렸다는 경험이 공유됐다. 방에 함께 전해진 원인은 서브에이전트 캐시 미스였다. 이 화제에 붙은 사람은 두 명뿐이었지만 오간 메시지는 스무 건에 이르렀다.

캐시 미스라는 단어가 이 대화에서 갖는 무게는 작지 않다. 같은 맥락을 다시 태우는 구조에서는 쓰는 사람이 프롬프트를 아무리 다듬어도 소모가 손 바깥에서 벌어지기 때문이다. 앞서 짚힌 두 원인 가운데 AI가 관리를 잘못하는 쪽이 실제로 어떤 모습인지를 보여준 사례로 읽힌다. 점검을 권한 쪽과 사고를 겪은 쪽이 같은 사람이었다는 점도 그 권고의 무게를 달리 읽게 만든다.

그보다 앞선 13시 46분에는 골든셋 만들기가 너무 어렵다는 토로도 있었다. 기준이 되는 정답 묶음을 갖추기 어렵다는 고민과, 소모가 어디서 나는지 재보자는 제안이 같은 시간대에 나란히 놓인 셈이다. 두 이야기 모두 결국 내 작업을 무엇으로 재느냐는 문제로 모인다.

오후 2시 16분에는 화요일, 한국시간으로는 수요일에 걸린 뱅크드리셋 정보가 있다는 언급이 붙으며 화제가 잠시 일정 쪽으로 옮겨갔다. 한도를 언제 회복하느냐를 챙기는 이야기가 한도를 왜 잃었느냐를 따지는 이야기 바로 옆에 붙어 있었던 셈이다.

이날 대화는 사용량 문제를 어떤 요금제와 어떤 모델을 고를지의 문제로 보던 시선이, 자기 작업 로그를 열어 소모 지점을 찾는 점검 쪽으로 옮겨가고 있음을 시사한다. 모델이 알아서 아껴 쓰기를 기다리는 대신 새는 자리를 직접 재보라는 권고가 방 안에서 먼저 나왔다는 점이 눈에 띈다. 소모를 줄이는 기술보다 소모를 보는 눈이 먼저라는 이야기로도 읽힌다.