OpenClaw 쓸 때 LLM API 95% 이상 아끼는 꿀팁
TL;DR: Hipocampus 쓰세요
http://github.com/kevin-hs-sohn/hipocampus
———
1. 비용의 구조에 대한 이해
LLM API는 모델에 따라 100만 토큰당 $0.1에서 $6 사이의 가격을 형성한다. 100만 토큰은 단어로 치면 약 75만 단어에 해당하며, 이는 백과사전 반권 분량과 맞먹는 양이다. 일반적인 대화라면 하루 종일 대화해도 1만 토큰을 넘기기가 어렵다.
그런데 AI 에이전트를 운영할 때는 이 토큰이 의외로 빠르게 소모된다.
2. 보이지 않는 토큰 소모
대화창에 보이는 결과물만큼만 토큰이 소모된다고 생각하기 쉽지만, 실제로는 보이지 않는 곳에서 훨씬 더 많은 토큰이 소모된다.
• 도구 호출을 위한 검색 결과 페이지 수십 개
• 중간 사고 과정 (Chain of Thought)
• 다양한 도구의 출력물
이 모든 것이 컨텍스트에 누적되고, 그 누적된 내용이 다음 질문에서도 중복으로 주입된다. 심지어 전혀 상관없는 질문에서도 말이다.
3. 구체적인 예시
"김정은 몸무게를 딥리서치해줘"라고 요청했을 때를 생각해보자.
결과물 자체는 A4 용지 한 장 분량에 불과하므로, 토큰도 그만큼만 소모될 것이라고 기대하기 쉽다.
하지만 실제로는 리서치 과정에서 수천 페이지의 정보가 컨텍스트에 쌓인다. 그리고 그 결과를 확인한 후 "내일 날씨는 어때?"라고 물으면, 그 수천 페이지의 리서치 정보가 다시 중복으로 주입된다.
이런 방식으로 5개의 서로 다른 작업을 시킨 후 "안녕?"이라고 인사하면, "응 안녕"이라는 답변을 받는 데에 무려 5만 토큰이 소모될 수 있다.
4. 해결책 1: Subagent로 작업 분리
중간 사고과정이나 중간 결과물이 최종 결과에 중요하지 않은 작업은, 명시적으로 subagent로 작업하도록 명령하는 것이 효과적이다.
예를 들어 김정은 체중 리포트를 .md 파일로 작성하게 한 후, 요약본만 메인 컨텍스트로 가져오는 방식이다.
이렇게 하면 중간 리서치 과정의 수천 페이지는 subagent의 로컬 컨텍스트에서만 존재하고 사라진다. 최종 결과물만 깔끔하게 남는다.
5. 해결책 2: 수시로 /compact
작업이 진행된 후에는 /compact 명령으로 컨텍스트를 요약 정리하는 것이 중요하다.
김정은 체중 리서치 관련 논의가 모두 끝나면 compaction을 통해 "결론만" 남기고, 불필요한 중간 과정을 정리한다. 그러면 다음 날씨 질문을 할 때 김정은 관련 정보가 중복으로 따라오지 않는다.
이 작업을 하지 않으면, 10번째 질문을 할 때 1번째부터 9번째까지의 작업의 쓸모없는 중간 과정이 전부 누적되어 컨텍스트를 오염시키고 있다.
6. 이 방식만으로는 한계가 있다
그러나 subagent와 compaction만으로는 본질적인 한계가 존재한다.
Subagent의 한계는, 당연하게도, 중간 사고과정이 모두 날아간다는 점이다. 중간 과정에서 에이전트가 습득한 정보에 관해 추가적인 질의나 상호작용을 할 수가 없다. 예를 들어 리서치 중간에 "아까 찾은 3페이지의 출처가 어디야?"라고 물을 수 없다. 결과물만 남고 과정은 닫혀버린다.
Compaction의 한계는 반복하면 기억을 다 날려버린다는 점이다. "김정은 체중 프로젝트"가 끝난 후 일주일간 여러 차례 컴팩션을 거치면 일주일 후 "그때 김정은 리서치 뭐였더라?"고 물으면 자세한 맥락을 기억하기 힘들어진다.
7. 근본적인 해결: 메인은 가볍게, 정보는 유실 없이
이 문제를 근본적으로 해결하려면 두 가지를 동시에 실현해야 한다:
• 메인 세션의 컨텍스트는 가볍게: Subagent와 compaction으로 당장 쓰지 않는 정보는 메인에서 제외하고
• 수집한 정보는 유실 없이: 장기 메모리에 체계적으로 기록하고 인덱싱하여 필요시 적절히 retrieve 할 수 있어야 한다.
예를 들어 김정은 체중 리서치를 subagent로 진행하면서, 중간 결과물들은 .md 파일로 저장한다. 메인 컨텍스트에는 요약만 남기고, 상세 내용은 파일로 보관. 리서치가 끝나면 compaction으로 메인을 정리해도, 파일로 저장된 정보는 남아있다.
일주일 후 "그때 김정은 리서치 뭐였더라?"고 물으면, 장기 메모리에서 해당 파일을 검색해서 다시 불러올 수 있다. 필요할 때만 선택적으로 로딩되는 것이다.
8. 시스템화: Hipocampus
지금까지 설명한 방식을 매번 수동으로, ad hoc하게 실행하는 것은 쉽지 않다. 까먹기도 하고, 일관되지도 않고, 결국에는 귀찮아서 안 하게 된다.
이걸 자동화하고 시스템화해주는 것이 바로 Hipocampus다.
3-tier 메모리 구조:
• Hot ( http://WORKING.md/, http://SCRATCHPAD.md/): 매 세션 접근하는 active 상태. 현재 하고 있는 작업, 임시 메모, 진행 중인 맥락
• Warm (Daily logs): 매일 작성되는 raw 로그 ( http://YYYY-MM-DD.md/). full context 보존, revisability 보장
• Cold (Weekly/Monthly summaries): compaction을 거쳐 정리된 장기 기억. 핵심 정보만 추출
9. 장기 메모리를 위한 5-level compaction tree:
Warm과 Cold 레이어를 관리하는 구조로, raw daily → weekly → monthly → root 순으로 컨텍스트가 압축 정리된다.
• Daily: 매일의 raw 로그를 http://WORKING.md/SCRATCHPAD.md에서 추출하여 보존
• Weekly: 일주일치 daily를 요약하여 통합
• Monthly: 월간 weekly들을 더욱 압축하여 통합
• Root ( http://ROOT.md/): 최종적으로 정리된 knowledge awareness. Cold 레이어(daily/weekly/monthly)에 어떤 지식들이 있는지 indexing한 인덱스. 매 세션 시작 시 로드되어 "내가 무엇을 알고 있는지" 파악
Subagent 작업 결과는 .md 파일로 저장되면 자동으로 인덱싱되어, 나중에 필요할 때 검색으로 꺼내쓸 수 있다. 이 모든 것이 프로토콜로 강제되어 까먹을 수가 없다.
10. 이 구조에서는 "김정은 체중 프로젝트"가 끝나서 compact했어도 정보가 유실되지 않는다.
메인 컨텍스트( http://WORKING.md/)는 가볍게, 수집한 정보는 Cold 레이어에 안전하게, 그리고 ROOT.md의 indexing 덕분에 필요할 때만 검색으로 정확히 불러온다.
11. 정리
비효율적인 방식: 모든 작업을 메인 컨텍스트에서 처리하고, 컨텍스트를 무한 누적시키며, 정보를 유실하거나 메인을 과부하시키고, 필요할 때 못 찾는 구조.
효율적인 방식: Subagent로 중간 과정을 분리하고, Compaction으로 정기적으로 정리하며, 3-tier와 compaction tree로 정보를 계층화하여 저장하고, ROOT.md의 indexing으로 필요할 때 검색해서 꺼내쓰는 구조.
결국 비용을 아끼려면 "쓰고 버리는" 것도, "무조건 다 메인에 쌓는" 것도 아니라, 메인은 가볍게 유지하면서도 정보는 유실 없이 계층화하여 저장하고, 필요할 때만 검색으로 꺼내쓰는 구조로 가야 한다.
이걸 매번 수동으로 하지 않고 프로토콜로 만든 것이 Hipocampus다.
