AI 루틴의 토큰, 새로 쓰기보다 다시 읽기에 썼어요

이랩스튜디오는 글 발행, 영상 제작, 공모전 준비 같은 일을 AI 에이전트 루틴으로 돌려요. 루틴은 정해진 시각에 새 세션으로 시작해서, 규칙 파일을 읽고, 브라우저와 도구를 써서 결과물을 만들고 끝나요.

10월 13일에 이런 질문이 나왔어요. "루틴 중에 매번 처음부터 다 읽고 시작하는 게 있나?" 토큰이 생각보다 많이 나가는 것 같다는 뜻이었어요. 그래서 짐작 대신 실행 기록을 직접 재 봤어요.

먼저 큰 파일부터 의심했어요

최근 3일 동안 돈 루틴 회차 236개(보조 세션 포함)의 기록을 열어, 회차마다 어떤 파일을 얼마나 읽었는지 셌어요. 결과는 예상과 달랐어요. 큰 규칙 파일을 통째로 읽는 루틴은 없었고, 대부분 프롬프트가 지정한 절만 골라 읽고 있었어요. 자주 도는 루틴이 한 회차에 읽는 글 파일은 3~18KB 정도였어요.

다음으로 이미지를 의심했어요. 화면 점검용 캡처를 많이 여니까요. 그런데 기록 파일 용량이 아니라 토큰으로 다시 재 보니, 이미지는 회차 전체 토큰의 0.1~0.2%뿐이었어요. 처음에 "이미지가 많이 먹는다"고 했던 건 파일 용량만 보고 내린 잘못된 판단이었고, 바로 정정했어요.

진짜 원인은 '다시 읽기'였어요

AI 에이전트는 한 단계를 끝낼 때마다 그 회차의 대화 전체를 처음부터 다시 읽고 다음 행동을 정해요. 캐시 덕분에 다시 읽는 값은 싸지만, 양이 쌓여요. 토큰의 대부분이 바로 이 다시 읽기(캐시 읽기)였어요.

10월 6일부터 13일까지의 기록으로 보면 무거운 루틴은 한 회차에 75~163단계를 돌았어요. 글 발행 루틴은 회차당 평균 163단계, 4,560만 토큰을 썼고, 회차 끝 무렵에는 한 단계마다 최대 약 49만 토큰의 문맥을 다시 읽고 있었어요. 단계가 늘수록, 그리고 각 단계의 출력이 길수록 뒤쪽 단계가 점점 비싸지는 구조예요.

그래서 "무엇이 문맥을 불렸나"를 루틴별로 나눠 봤어요.

• 웹페이지를 많이 오가는 루틴: 페이지 구조를 통째로 읽은 출력이 컸어요. 한 루틴은 문맥을 불린 출력의 81%가 이것이었어요.
• 영상과 문서를 만드는 루틴: 렌더와 실행 로그가 약 절반을 차지했어요.
• 강의 영상과 쇼츠를 만드는 루틴: 파일 읽기 결과가 38~44%였어요.

그래서 이렇게 바꿨어요

효과가 크고 위험이 낮은 순서로 세 가지를 정했어요.

1. 출력 줄이기: 실행 로그는 오류와 끝 15줄만 남기고, 페이지는 필요한 부분만 읽고, 행동 뒤에는 바뀐 부분만 봐요. 긴 결과는 파일로 저장한 뒤 필요한 줄만 찾아 읽어요.
2. 긴 중간 작업 나누기: 조사나 렌더처럼 출력이 긴 일은 보조 세션에 맡기고, 본 루틴은 요약만 받아요. 효과는 가장 클 수 있지만 흐름이 바뀌어서, 무거운 루틴 3개에만 먼저 시험해요.
3. 묶어서 한 번에: 서로 기다릴 필요 없는 동작은 한 번의 호출로 묶어요.

1번 규칙은 무거운 루틴 9개 프롬프트 앞부분에 공통 블록으로 넣었어요. 단, 사실 확인과 결과 점검은 줄이지 않는다는 조건을 같이 적었어요. 토큰을 아끼려다 틀린 결과물을 내면 의미가 없으니까요.

배운 것: 줄이기 전에 먼저 재기

이번에 가장 크게 배운 건 순서였어요. 처음 떠오른 원인(큰 파일, 이미지)은 둘 다 틀렸고, 실제 기록을 단위까지 맞춰 재고 나서야 진짜 원인이 보였어요. 감으로 이미지를 줄였다면 거의 아무것도 아끼지 못했을 거예요.

효과는 아직 모르는 상태예요. 바꾸기 전 일주일 기록을 기준선으로 저장해 두었고, 10월 21일에 바꾼 뒤 일주일과 비교해 유지할지, 넓힐지, 되돌릴지 정할 예정이에요. 결과가 나오면 숫자 그대로 다시 정리할게요.

출처: 이랩스튜디오 루틴 실행 기록(세션 기록과 토큰 집계) 직접 측정. 10월 13일 기준 최근 3일 회차 236개 분석, 기준선은 10월 6일부터 13일까지의 회차.