AI 비서의 토큰 최적화 여정

실수했던 부분

이전 글(my previous article)에서 저는 AI 비서에게 기억력과 개성을 부여하여 저의 비서로 활용하는 것에 대해 글을 썼습니다. 저는 '나만의 전담 AI 비서를 갖게 되었으니, 이제 본격적인 운영만 남았다'고 생각하며 흥분했습니다.

하지만 일주일 제한에 사흘 만에 도달했습니다.

Claude의 MAX 플랜은 20배의 한도를 가지고 있습니다. 이는 보통 무거운 개발을 할 때도 주말까지 지속되는 할당량입니다. 그런데 제가 그것을 사흘 만에 다 써버린 것입니다. 저 자신도 놀랐습니다. 화면에 '이번 주 사용량을 초과했습니다'라는 메시지가 떴을 때, 저는 실제로 '벌써?'라고 말했습니다.

원인은 명확했습니다. 비서가 24시간 연중무휴로 제 이메일, 달력, Discord를 읽고 결정을 내리고 있었기 때문입니다. 당연히 소진될 수밖에 없었습니다. AI가 한 인간의 행정 업무를 하루 종일 처리하게 한다면, 토큰을 다 써버리지 않을 방법은 없습니다.

하지만 이것은 문제가었습니다. 큰 문제였습니다. 그래서 저는 필사적으로 해결책을 연구했습니다. 이 글은 그 여정에 대한 기록입니다.

토큰 절약의 세계를 헤매다

저는 'Claude Code token savings' 같은 것을 검색했고, 세 가지 주요 항목에 도달했습니다:

• ECC (Everything Claude Code)
• RTK (Rust Token Killer)
• Caveman

처음에는 이름만 보고는 이것들이 무엇인지 전혀 알지 못했습니다. 하지만 가지고 놀아보고 연구하면서, 이 모든 것이 하나의 공통 원칙을 공유하고 있다는 것을 깨달았습니다.

발견된 공통 원칙

인간을 위해 설계된 형식은 AI에게는 낭비가 가득하다.

곰곰이 생각해보니 당연했습니다. 명령어 출력, 파일 내용, 오류 메시지 등 모든 것은 '사람이 읽기 쉽게' 만들어집니다. 공백(Whitespace), 테두리(borders), 색상(colors), 도움이 되는 설명, 헤더 등이요. AI에게 있어 이 대부분은 그저 노이즈일 뿐이며, 토큰을 소모하는 장식에 불과합니다.

토큰 보존의 핵심은 AI에게 전달하기 전에 인간 중심의 형식을 제거하는 것입니다. 그리고 그 다음, AI가 생성한 출력을 더욱 압축하는 것입니다. 이 세 가지 도구는 서로 다른 각도에서 이 전제를 해결합니다.

ECC — 전문가들이 잘 설정해 놓은 것들

솔직히 말해서, 저는 아직 전체 그림을 완전히 파악하지는 못했습니다. 하지만 일단 설치하여 실행하면, Claude의 동작이 확실히 더 체계적으로 변합니다. ECC는 기술(skills), 훅(hooks), 에이전트 정의(agent definitions)로 가득 차 있어, Claude가 "이 상황에서는 이렇게 행동하라"는 궤도 위에 올라타게 만듭니다.

제가 이해하기로 ECC는 "전문가들의 노하우가 담긴 설정 모음"과 같습니다. 스스로 생각하지 않더라도 베스트 프랙티스(best practices)를 따르게 됩니다. 토큰 절약 관점에서 보면, 불필요한 탐색과 우회 과정을 줄여주어 궁극적으로 소모량을 낮춥니다. 이는 출력을 직접적으로 자르는 방식이라기보다, 불필요한 일을 하지 않음으로써 얻는 절약 방식입니다.

RTK — AI를 위한 명령 응답 단순화

이것은 명확합니다. Claude가 명령을 실행할 때, RTK는 출력을 가로채서 AI가 소비하기 좋게 다듬습니다.

예를 들어, git status나 ls의 출력은 보통 인간 중심의 장식들이 포함되어 있지만, RTK를 통하면 불필요한 정보가 제거된 상태로 Claude에게 전달됩니다. 명령 앞에 rtk 접두사만 붙이면 됩니다. 또한 필터가 없는 대상은 단순히 그대로 통과시키기 때문에 시스템을 망가뜨리지 않는다는 점도 훌륭합니다.

전역 CLAUDE.md 파일에 "모든 명령에 rtk 접두사를 붙여라"라고 작성해 두면, Claude가 자동으로 수행합니다. 노력은 적게 들면서 효과는 매우 큽니다.

Caveman — AI 출력 요약 (현재 건너뜀)

이것은 아직 설치하지 않았습니다. RTK가 "입력(input)" 측면을 다듬는다면, 제가 이해하기로 Caveman은 "출력(output)" 측면을 다듬습니다. Claude 자신의 응답을 더 짧게 압축하는 방향인 것으로 보입니다.

제가 그것을 포함하지 않은 이유는 간단합니다. 제 비서가 로봇처럼 들리는 것을 원치 않기 때문입니다. 저는 제 비서의 성격과 말투를 구축하는 데 많은 공을 들였기에, 갑자기 무미건조하게 응답하기 시작한다면 실망스러울 것입니다. 선택적으로 사용할 수도 있었을 것입니다. 예를 들어 개발 세션에서만 활성화하는 방식 말이죠. 하지만 그 부분을 깊이 파고들기 전에, 저는 "일단 이번에는 건너뛰자"라고 결정했습니다.

이것은 단지 저의 개인적인 사용 사례(use case)에 따른 문제일 뿐입니다. 순수하게 개발 목적으로만 사용하는 분들에게는 아마 매우 강력한 도구가 될 것이라고 생각합니다.

저의 개발 스타일에 따라 다음에 추가할 수도 있는 것들

저는 이 세 가지 도구를 통해 토큰을 절약하기 위한 "기초(foundation)"를 세웠습니다. 이제부터는 저의 습관에 기반하여 내용을 더 다듬을 수 있는 추가적인 방법들을 고민하고 있습니다. 이것들은 아직 시도해보지 않았지만, 다음에 실행할 계획인 것들입니다.

변수명이나 함수명을 사용하여 보고한다면, 저에게는 아무런 의미가 없습니다

저의 개발 스타일은 코드를 거의 작성하지 않는 방식입니다. 모든 명명(naming)은 Claude가 수행합니다. 따라서 Claude가 "handleUserSubmit를 수정했습니다"라고 말하더라도, 솔직히 저에게는 와닿지 않습니다.

반대로 말하면, Claude가 보고서에서 변수명이나 함수명을 인용하는 것은 저에게 정보 가치가 제로라는 뜻입니다. 설령 그 정보가 사람에게는 도움이 될지라도, 저와 같은 독자에게는 소음에 더 가깝습니다.

그런 경우라면, 차라리 "제출 버튼이 눌렸을 때의 처리를 수정했습니다"와 같이 제가 이해할 수 있는 말로 설명하도록 시켜야 합니다. 이름의 인용 횟수를 줄이면 보고서가 더 짧아지고, 저는 더 빠르게 이해할 수 있습니다. 일거양득(Killing two birds with one stone)인 셈이죠.

결정이 필요한 부분은 상세하게, 앞선 설명은 가볍게

또한 Claude의 보고서가 "무엇을 했는지"를 설명할 때 상당히 길어진다는 점을 깨달았습니다. 하지만 제가 가장 읽고 싶은 부분은 마지막의 "그래서, 우리는 무엇을 해야 할까요?" 섹션입니다.

결정이 필요한 부분, 즉 제가 답변하지 않으면 진행되지 않는 부분들은 상세하게 작성되기를 원합니다. 하지만 그 앞부분들—어떤 파일을 읽었는지, 무엇을 확인했는지, 사건의 순서 등—은 솔직히 결정을 내리는 데 그리 필수적이지 않습니다. 나중에 필요하면 요청할 테니, 기본값은 가볍게 설정해도 됩니다.

이 두 가지 사항을 규칙 파일(rule file)에 작성하여 전달하면 효과가 있을 것이므로, 다음 단계로 이를 작업할 계획입니다.

요약 (Summary)

이번에 얻은 가장 큰 교훈은, 요약하자면 토큰 보존이란 AI가 인간 중심적인 형식을 읽지 않게 만드는 것이라는 점입니다.

ECC는 "불필요한 일을 하지 않음"으로써, RTK는 "입력값(inputs)을 다듬음"으로써, 그리고 Caveman은 "출력값(outputs)을 다듬음"으로써 각각 다른 각도에서 동일한 원칙을 다루며 이 문제를 해결합니다. 모든 것을 다 집어넣으려 하기보다 자신의 필요에 맞는 것을 선택하는 것이 더 나아 보입니다. 저의 경우, 비서의 말투를 유지하고 싶기 때문에 Caveman은 건너뛰었습니다.

그리고 이제부터는 저만의 독서 습관에 맞춰 더욱 다듬어 나갈 차례입니다. 이름 대신 의미로 설명하게 하고, 도입부는 가볍게 유지하며, 결정이 필요한 부분은 상세하게 만드는 식입니다. 이러한 점들을 정교화한 후에 다시 업데이트를 작성할 수 있을 것 같습니다.

한계에 부딪히는 과정은 고통스러웠지만, "AI에게 전달할 정보를 설계하는 것"이라는 주제를 직면할 수 있는 기회가 되었습니다. 어쩌면 전화위복(blessing in disguise)이었을지도 모릅니다.