Claude Code, 프롬프트를 넘어서 — 파트 7 (최종장): Claude Code에서 라이브 자동 매매 시스템을 운영하며 얻은 패턴들. 파트 6: Claude의 작업 큐로서의 GitHub.

Claude가 읽는 모든 토큰(token)은 두 가지 측면에서 비용을 발생시킵니다: 한 번은 돈으로, 또 한 번은 시간으로 말이죠. 비대해진 컨텍스트 (context)는 단순히 더 큰 청구서만을 의미하지 않습니다. 매 턴마다 더 느린 응답을 의미하기도 합니다.

사람들이 이를 해결하려고 할 때, 잘못된 레버를 잡곤 합니다: 더 저렴한 모델로 전환하는 것. 하지만 낭비가 발생하는 지점은 모델이 아닙니다. 낭비는 Claude가 읽을 필요가 없는 것을 읽게 하고, 하지 않아도 될 일을 다시 하게 만드는 것에서 발생합니다. 그리고 이 시리즈에서 다룬 여섯 가지 요소들이 — 비록 다른 이유로 만들어졌지만 — 거의 우연히도 토큰 절감 시스템이 된다는 사실이 밝혀졌습니다.

절감이 실제로 어떻게 이루어지는지, 그리고 여러분의 비용을 어떻게 측정할 수 있는지 설명하겠습니다. 이 글은 결론에 해당하는 기사이므로 구체적인 내용을 다룹니다.

핵심 통찰: 토큰은 비용과 속도 모두의 통화이다

이것은 여러분의 작업 방식을 바꾸는 사고 모델입니다: 토큰은 청구 금액과 지연 시간 (latency) 모두의 공통 통화입니다. Claude가 읽거나 재생성해야 하는 양을 줄이는 모든 것은 두 축 모두에서 동시에 승리합니다. 여러분은 비용과 속도를 맞바꾸는 것이 아니라, 동일한 동전으로 두 가지를 모두 사는 것입니다.

따라서 최적화 목표는 "더 저렴한 모델"이 아닙니다. 그것은 바로 **정보 밀도 (information density)**입니다: 매 턴마다 최대의 관련 컨텍스트를 유지하면서 최소한의 노이즈를 유지하는 것입니다.

토큰이 실제로 새어나가는 곳

단순한 세션을 관찰해 보면, 어디를 봐야 할지 아는 순간 낭비가 명확히 보입니다. 각 누출은 우리가 이미 구축한 요소와 매칭됩니다:

가장 큰 두 가지는 거의 항상 첫 번째와 다섯 번째 요소입니다.

컨텍스트 재설명 (Part 1): 메모리 파일이 없다면, 매 세션의 시작마다 스택(stack), 컨벤션(conventions), 그리고 현재 상태를 다시 설정하는 데 시간을 허비하게 됩니다. 즉, 실제 작업이 시작되기도 전에 수백 개의 토큰이 서문(preamble)으로 소모됩니다. 메모리 파일이 있다면, 해당 컨텍스트는 Claude가 한 번만 읽으면 되는 압축된 파일이 됩니다. 이를 모든 세션에 곱해본다면 그 차이는 영원히 지속됩니다.

전체 파일 읽기 (Part 5): 이것이 가장 거대한 요소입니다. 코드를 찾기 위해 Grepping-and-reading(그레핑 및 읽기)을 수행하면, 정작 중요한 30줄을 찾기 위해 통상 5개 파일에 걸쳐 약 6,000개의 토큰을 소모합니다. 반면 훌륭한 시맨틱 룩업(semantic lookup, 의미론적 조회)은 적절한 청크(chunk)인 약 300개의 토큰만을 반환합니다. 이는 단일 조회 시 약 20배의 감소를 의미하며, 이러한 조회는 끊임없이 발생합니다. (이는 실험실 측정값이 아닌 예시일 뿐이지만, 그 규모의 차이는 실재하며 직접 비교해 보는 순간 체감하게 될 것입니다.)

대부분의 사람들이 놓치는 세 가지 플랫폼 레버

앞서 언급한 여섯 가지 요소 외에도, Claude Code는 순수하게 토큰을 절약할 수 있는 세 가지 레버를 더 제공합니다.

1. 프롬프트 캐싱 (Prompt caching). 컨텍스트의 안정적인 접두사(prefix)가 캐싱됩니다. 따라서 안정적이고 훑어보기 좋은 CLAUDE.md 파일은 여러 턴(turn)에 걸쳐 캐싱된 상태로 유지되어, 저렴하고 빠르게 재사용할 수 있습니다. 이것이 바로 Part 1의 분리 방식이 경제적(dollars)이고 시간적(milliseconds)으로 이득이 되는 구체적인 이유입니다. 즉, 안정적인(stable) 파일은 깔끔하게 캐싱되고, 동적인(dynamic) 파일은 작게 유지됩니다. 항상 로드되는 컨텍스트가 계속 변한다면(churn), 캐시를 계속 깨뜨리게 되어 비용을 전액 지불해야 합니다. 안정성은 단순히 깔끔함을 넘어, 캐싱을 가능하게 합니다.

2. 지연/연기된 도구 로딩 (Lazy / deferred tool loading). 로드하는 모든 도구는 컨텍스트에 위치하는 스키마(schema)를 포함합니다. 200개의 도구를 즉시(eagerly) 로드한다면, 한 마디를 내뱉기도 전에 수천 개의 토큰을 소모하게 됩니다. Claude Code는 도구 스키마를 연기했다가 필요할 때(on demand) 로드할 수 있으므로, 세션은 실제로 사용하는 도구에 대해서만 비용을 지불합니다. 스킬(Skills)도 동일한 방식으로 작동합니다 (Part 3). 짧은 설명만 항상 로드되며, 본문은 관련이 있을 때 로드됩니다. 점진적 공개(Progressive disclosure)는 단순한 정리 기법이 아니라, 하나의 토큰 전략입니다.

3. 대용량 독해를 위한 서브에이전트(Subagents). Claude가 많은 양의 내용을 읽어야 하는 작업 — 수십 개의 파일을 검색하거나, 거대한 디렉토리를 훑어보는 경우 — 서브에이전트를 구동하여 해당 에이전트 자체의 컨텍스트에서 대량 독해를 수행하게 하고, 그 결과로 정제된 결론만을 반환받습니다. 50,000 토큰 규모의 탐색 작업은 옆에서 처리되고, 사용자의 메인 스레드는 500 토큰 분량의 답변만 받게 됩니다. 대규모 팬아웃(fan-out) 작업에서는 이것이 가장 큰 단일 절감액 중 하나이며, 실제 작업을 위한 메인 컨텍스트를 깨끗하게 유지할 수 있게 합니다.

핵심은 이들이 복합적으로 작용한다는 점입니다 (The point is that they compound)

여기에 이 방법론이 단순한 참고 사항이 아니라 결말(finale)인 이유가 있습니다. 이들은 단순히 더해지는 것이 아니라, 각각 세션의 다른 부분을 공략하기 때문에 곱해집니다(multiply).

순진한 세션은 다음과 같습니다: 모든 것을 다시 설명하기 + 10개 파일 grep으로 읽기 + 로그 덩어리 붙여넣기 + 오래된 상태를 가정했던 작업 재수행. 이러한 수정 사항들을 쌓으면 같은 세션이 다음처럼 변합니다: 압축된 메모리 파일 읽기 + 하나의 의미론적 조회(semantic lookup) + 구조화된 도구 결과 + 근거 기반, 재작업 없는 실행. 모든 단계가 더 밀도 높아졌습니다. 총량은 결코 가깝지 않습니다.

제가

사고방식의 전환

이 글에서 단 한 가지만 얻어가신다면 이것입니다: "어떻게 하면 프롬프트를 더 잘 작성할까"라고 묻는 것을 멈추고, "Claude가 읽을 필요가 없는데 읽고 있는 것은 무엇인가, 그리고 Claude가 하지 않아도 될 일을 다시 하고 있는 것은 무엇인가?"라고 묻기 시작하십시오.

제거하는 모든 토큰(Token)은 절약된 비용이자 단축된 지연 시간(Latency)입니다. 컨텍스트(Context)를 신호(Signal)를 위해 소비되는 희소한 예산으로 재정의하는 것 — 이것이 거대한 월간 청구서를 작은 것으로, 느릿한 어시스턴트를 빠른 어시스턴트로 바꾸는 핵심입니다.

시리즈를 마치며

7부 전, 저는 다음과 같은 주장을 했습니다: Claude Code로부터 극적인 성능 향상을 이끌어내는 것은 더 나은 프롬프트를 작성하는 것과 거의 관련이 없다고 말입니다. 이제 그 근거가 충분히 제시되었기를 바랍니다.

레버리지(Leverage)는 결코 프롬프트에 있지 않았습니다. 그것은 프롬프트를 둘러싼 스캐폴딩(Scaffolding, 구조물)에 있었습니다:

• 메모리 (Memory): 프로젝트를 절대 잊지 않도록 (Part 1).
• 의식 (Rituals): 행동하기 전에 사실에 기반하도록 (Part 2).
• 명령어 (Commands): 워크플로우와 판단력을 한 번에 캡처하도록 (Part 3).
• MCP 도구 (MCP tools): 당신이 구축한 울타리 안에서 시스템에 작용할 수 있도록 (Part 4).
• 시맨틱 검색 (Semantic search): 추측이 아닌 의미에 따라 찾을 수 있도록 (Part 5).
• GitHub: 공유되고 지속적인 진실의 원천(Source of truth)을 갖도록 (Part 6).
• 토큰 감각 (Token sense): 이 모든 것이 저렴하고 빠르게 실행되도록 (Part 7).

이 중 그 어떤 것도 더 큰 모델을 필요로 하지 않았습니다. 모든 요소는 오늘 오후 10분짜리 메모리 파일을 만드는 것부터 시작하여 점진적으로 구축할 수 있는 것들입니다. 순서대로 진행하면, 다음 단계를 구축하기 전에 각 단계가 스스로의 비용을 회수할 것입니다. 이 요소들이 결합되면 Claude Code는 단순한 채팅창에서 실제 업무를 위한 운영 계층(Operational layer)으로 변모합니다. 이는 제가 매일 라이브 시스템을 Claude Code로 운영하며 경험하고 있는 바로 그 모습입니다.

더 깊이 들어가기

제가 계속해서 언급을 피했던 부분 — 시맨틱 검색 (Semantic Search) 및 메모리 하단의 검색 메커니즘(retrieval machinery) — 은 저의 오픈 소스 프로젝트인 RE-call에 담겨 있습니다. 이 프로젝트는 에이전트에게 진정으로 작동하는 메모리를 부여하는 방법 — 아키텍처 (Architecture), 평가 하네스 (Evaluation harness), 그리고 실패한 실험들을 포함한 솔직한 결과들 — 을 심도 있게 다루며, docs/WRITEUP.md에 상세한 기록이 포함되어 있습니다. 만약 이번 시리즈의 RAG 관련 내용이 마음에 드셨다면, 다음 단계로 이곳을 확인해 보세요.

그리고 만약 여러분을 사로잡는 것이 '증거'라면: 저는 실제 예측 시스템에서 약 12개의 파인튜닝 (Fine-tuning) 및 RAG 실험을 수행했습니다 — 워크포워드 분할 (Walk-forward splits), 순열 테스트 (Permutation tests), 사전 등록된 킬 게이트 (Pre-registered kill-gates) 등을 활용하여 — 그리고 그중 대부분은 실패했습니다. 그 사후 분석 (Autopsies)은 그 어떤 자극적인 의견보다 가치가 있습니다. 왜 더 나은 손실 함수 (Loss)를 가진 더 큰 모델이 더 나쁜 결정을 내렸는지, 왜 프롬프트 내 RAG (RAG-in-the-prompt) 방식이 8번 연속으로 실패했는지, 그리고 이 모든 것을 설명하는 단 하나의 규칙은 무엇인지에 대한 내용입니다. 모든 내용은 여기에 있습니다: Fine-Tuning and RAG: What a Dozen Failed Experiments Taught Me.

끝까지 읽어주셔서 감사합니다. 만약 여러분이 이 중 하나라도 구축하신다면, 어떻게 되었는지 알려주세요 — 저는 모든 답글을 읽습니다.

Claude Code, Beyond the Prompt의 피날레입니다. 이와 유사한 것을 직접 만드시겠습니까, 아니면 이를 수행할 사람들을 고용하시겠습니까? 더 깊은 에이전트 메모리 연구는 오픈 소스로 공개되어 있습니다 — 위에 링크된 RE-call. 다음 시리즈를 위해 팔로우해 주세요.