최근 AI에게 전달하는 작업 지시가 눈에 띄게 짧아졌다.
예전에는 프로젝트 상태, 이전 작업, 주의사항, 다음 단계까지 한 프롬프트에 길게 넣는 경우가 많았다. 프로젝트가 커지면서 이 방식은 점점 부담스러워졌고, 안정적인 정보는 Git과 프로젝트 문서로 옮기고 현재 작업에 필요한 delta만 전달하는 방향으로 바꿨다.
겉으로 보기에는 성공적이었다.
한 비교 표본에서 Human이 직접 전달하는 instruction payload는 약 13,991 bytes에서 3,268 bytes로 줄었다. 대략 76~77% 감소다.
그런데 여기서 질문이 생겼다.
프롬프트가 77% 짧아졌다면
AI가 실제로 읽는 input도 77% 줄었을까?
측정해보니 그렇게 단순하지 않았다.
이 글은 그 과정에서 prompt size, context transport, retrieval cost를 서로 다른 문제로 보게 된 기록이다.
이 글의 수치는 주로 파일 크기와 instruction payload의 UTF-8 byte 측정값이다. provider billing token이나 실제 cached-input token telemetry를 직접 측정한 결과가 아니다.
먼저 확실히 줄어든 것: Human prompt
현재 Workspace Ops 작업 중 하나였던 OPS-UX-02의 Human instruction을 측정했다.
characters: 3,254
UTF-8 bytes: 3,268
lines: 177
비교 대상으로 과거 CharaWeave capability audit 지시를 같은 방식으로 봤다.
characters: 13,697
UTF-8 bytes: 13,991
lines: 578
비율은 다음과 같았다.
| 항목 | 과거 표본 | compact 표본 | 변화 |
|---|---|---|---|
| Characters | 13,697 | 3,254 | 약 -76% |
| UTF-8 bytes | 13,991 | 3,268 | 약 -77% |
| Lines | 578 | 177 | 약 -69% |
Human이 직접 작성해서 전달하는 payload만 놓고 보면 명확한 개선이었다.
이전처럼 현재 상태 전체를 다시 설명하지 않고, 이미 저장된 상태를 가리키면서 이번 작업의 delta만 전달하기 시작했기 때문이다.
FULL CONTEXT RECONSTRUCTION
→ POINTER / DELTA TRANSPORT
Handoff도 실제로 작아졌다
비슷한 변화는 session/device handoff에서도 보였다.
초기 continuation 계열 두 표본은:
9,935 B
10,833 B
average: 10,384 B
이후 compact handoff 10개는 평균 약:
3,285 B
였다.
평균 기준으로 약 68% 감소다.
CharaWeave의 최근 handoff 10개도 평균 약 2,180 B 수준까지 내려가 있었다.
여기까지만 보면 context compaction은 잘 되고 있는 것처럼 보였다.
Human prompt ↓
Handoff ↓
Repeated prose ↓
그런데 repository 쪽까지 보기 시작하면서 결과가 달라졌다.
첫 번째 반전: Git으로 옮긴 context도 결국 읽으면 input이다
프롬프트가 짧아진 이유 중 하나는 안정적인 규칙과 상태를 repository에 보관했기 때문이다.
예를 들어 측정 당시 주요 AGENTS.md 크기는 대략 다음과 같았다.
workspace-ops/AGENTS.md ≈ 16,275 B
PhotoGramPJ/AGENTS.md ≈ 6,169 B
charaweave/AGENTS.md ≈ 3,152 B
OPS-UX-02는 짧은 Human prompt 대신 repository의 AGENTS.md를 읽도록 요구했다.
따라서 아주 단순하게 둘만 합쳐보면:
OPS-UX-02 Human prompt 3,268 B
workspace-ops AGENTS 16,275 B
--------------------------------
minimum 19,543 B
과거 CharaWeave 표본도 똑같이 prompt + AGENTS만 계산하면:
CW-PG prompt 13,991 B
charaweave AGENTS 3,152 B
--------------------------------
minimum 17,143 B
Human prompt는 훨씬 짧아졌는데, 이 단순 비교에서는 오히려 새 작업 쪽이 더 컸다.
물론 이 숫자를 곧바로 실제 model input이라고 부를 수는 없다. provider cache, tool 결과 전달 방식, 실제 read 범위가 다르기 때문이다.
하지만 한 가지는 명확했다.
CONTEXT MOVED TO GIT
!=
CONTEXT COST ELIMINATED
정보를 프롬프트에서 파일로 옮겼다고 해서 그 정보가 공짜가 되는 것은 아니다.
agent가 매번 그 파일을 다시 읽는다면 비용의 위치만 바뀐 것이다.
두 번째 반전: 작은 handoff보다 큰 Always-Read set이 더 중요했다
CharaWeave workflow를 보면서 이 문제가 더 선명해졌다.
당시 workflow contract에는 future Story마다 다음 문서들을 Always read하도록 명시한 구간이 있었다.
AGENTS.md
ORCA_GIT_WORKFLOW.md
ARCHITECTURE_BASELINE.md
PROJECT_EVOLUTION_MAP.md
DELIVERY_PLAN.md
1_0_READINESS_LEDGER.md
파일 크기를 합치면 약:
134,673 B
였다.
약 131.5 KiB의 static context다.
Browser나 React 관련 Story라면 여기에 integration 문서가 추가되고, 현재 Story의 preceding work item과 handoff까지 읽도록 되어 있었다.
재미있는 점은 같은 시점 CharaWeave의 handoff 자체는 이미 평균 약 2 KB 수준으로 충분히 작아졌다는 것이다.
즉 큰 비용 후보는 더 이상 handoff가 아니었다.
Handoff transport
= compact
Mandatory retrieval surface
= still large
여기서 처음 연구 질문이 바뀌었다.
Transport Compaction과 Retrieval Compaction은 다르다
처음에는 이렇게 물었다.
프롬프트가 얼마나 짧아졌는가?
측정 후에는 질문이 이렇게 바뀌었다.
agent가 같은 작업을 하기 위해
stable context graph를 얼마나 다시 traverse하는가?
이 둘을 분리하기 위해 context compaction을 세 단계로 보기 시작했다.
1. Transport Compaction
사람이나 이전 session이 다음 actor에게 직접 전달하는 양을 줄이는 것이다.
Human prompt
handoff
resume delta
이 부분은 확실히 줄었다.
2. Storage Separation
서로 성격이 다른 정보를 적절한 owner로 분리한다.
stable governance → Git / AGENTS
current durable state → control state / checkpoint
history → history repository
current request → prompt delta
이것도 구조적으로는 상당히 개선됐다.
3. Retrieval Compaction
실제 작업에서 필요한 것만 필요한 순간에 읽게 만드는 것이다.
필요한 문서만
필요한 시점에
필요한 범위만
실제 input 효율과 가장 직접적으로 연결되는 부분은 이 세 번째 단계였다.
TRANSPORT COMPACTION
!= RETRIEVAL COMPACTION
프롬프트를 아무리 짧게 만들어도 agent가 시작할 때마다 100 KB가 넘는 baseline을 다시 읽는다면 전체 비용은 생각만큼 줄지 않을 수 있다.
모든 reference를 Always Read로 취급해도 안 된다
여기서 반대 방향의 과대계산도 조심해야 했다.
PhotoGram AGENTS.md에는 여러 Workspace governance 문서가 required reference로 연결되어 있었다.
당시 그 문서들과 PhotoGram AGENTS.md의 파일 크기를 단순 합산하면 약:
100,651 B
였다.
하지만 이것을:
PhotoGram per-session input = 100,651 B
라고 부를 수는 없었다.
CharaWeave의 경우에는 workflow가 명시적으로 Always read를 요구했다. 반면 PhotoGram은 reference/authority surface를 선언한 것이지 모든 파일을 매 session마다 전부 읽는다는 증거는 아니었다.
실제 canary 기록에서도 targeted governance/history reread는 2회였고, manual handoff나 same-owner full context reconstruction은 없었다.
그래서 다음을 분리하게 됐다.
DECLARED REFERENCE SURFACE
!=
PROVEN ACTUAL RETRIEVAL
파일이 존재한다는 이유만으로 input 비용에 전부 더하는 것도 잘못이고, prompt에 없다는 이유로 비용에서 빼는 것도 잘못이다.
결국 필요한 것은 실제 retrieval trace다.
Context 비용은 문서 크기 하나로 설명되지 않는다
이 관찰을 바탕으로 context load를 개념적으로 다음처럼 보기 시작했다.
Context Load Cost
≈ Σ(
context size
× actual read frequency
× relevance
× cache behavior
)
정확한 billing formula라는 뜻은 아니다.
특히 cache behavior는 provider telemetry가 없으면 수치화하면 안 된다.
다만 최적화 방향을 생각하기에는 이 모델이 단순 prompt-size보다 유용했다.
예를 들어 50 KB짜리 문서라도 operation 전체에서 한 번만 읽고 이후에는 필요한 section만 가져온다면 비용 특성이 달라진다.
반대로 5 KB짜리 문서를 매 step마다 반복해서 읽으면 누적 비용은 커질 수 있다.
그래서 document size만 볼 게 아니라 다음을 같이 보게 됐다.
SIZE
× READ FREQUENCY
× RELEVANCE
× CACHE BEHAVIOR
측정 항목도 다시 나눴다
처음에는 prompt bytes 하나면 충분하다고 생각했다.
지금은 적어도 다음 정도는 분리해야 한다고 본다.
HUMAN PAYLOAD
= 사람이 이번 작업에 직접 전달한 instruction
FIXED GOVERNANCE COST
= 실제 mandatory / always-read stable context
DECLARED REFERENCE SURFACE
= 접근 가능해야 하지만 실제 read가 증명되지 않은 문서
DURABLE STATE COST
= checkpoint / operation / current control state
ROUTING COST
= handoff / continuation delta
TARGETED EVIDENCE COST
= 이번 step 때문에 실제로 읽은 evidence
REPEATED CONTEXT COST
= 같은 정보를 동일 operation에서 다시 읽은 양
FULL CONTEXT RECONSTRUCTION COUNT
= 전체 context를 다시 조립한 횟수
provider가 telemetry를 제공한다면 그때 별도로:
input tokens
cached input tokens
output tokens
reasoning tokens, when exposed
을 기록하면 된다.
없는 telemetry를 추정해서 실제값처럼 다루지는 않는 편이 낫다.
그래서 77%는 무엇을 의미했는가
처음의 77%라는 수치는 틀리지 않았다.
다만 의미가 더 좁았다.
Human-supplied instruction payload
= 약 76~77% 감소
이지:
Total model input cost
= 77% 감소
가 아니었다.
당시 evidence를 다시 정리하면 이렇다.
HUMAN PROMPT COMPACTION
= CLEAR PASS
HANDOFF / TRANSPORT COMPACTION
= CLEAR PASS
CONTEXT STORAGE SEPARATION
= CLEARLY IMPROVED
RETRIEVAL COMPACTION
= PROJECT-DEPENDENT / NOT YET COMPLETE
TOTAL EFFECTIVE INPUT COMPACTION
= PARTIALLY SUPPORTED, NOT YET TOKEN-PROVEN
이 구분을 하지 않았다면 "프롬프트를 77% 줄였더니 AI 비용도 77% 줄었다"는 훨씬 보기 좋은 결론을 쓸 수도 있었을 것이다.
하지만 현재 evidence가 말하는 것은 그보다 조금 더 복잡했다.
Pointer가 항상 duplication보다 싸지는 않다
현재 내가 가장 중요하게 보는 결론은 이것이다.
POINTER > DUPLICATION
이라는 원칙은 대체로 맞다.
같은 긴 context를 매번 prompt에 복제하는 것보다 canonical source를 가리키는 편이 관리와 provenance 측면에서도 좋다.
하지만 효율 측면에서는 조건이 하나 붙는다.
POINTER TARGET을
매번 처음부터 끝까지 읽지 않아도 되어야 한다.
pointer를 만들고도 매 작업마다 target 전체를 다시 읽는다면 transport만 줄었을 뿐 retrieval은 줄지 않는다.
그래서 다음 최적화 대상은 더 짧은 prompt가 아니라 더 좋은 retrieval policy가 됐다.
index first
→ identify relevant source
→ targeted read
→ expand only when necessary
정보를 없애는 것이 아니라, 필요한 순간까지 읽기를 지연시키는 방식이다.
다음 질문
이 연구는 아직 끝나지 않았다.
다음으로 확인하고 싶은 것은 byte 단위 관찰을 실제 execution trace와 provider telemetry에 연결하는 것이다.
- 실제 session이 읽은 file path와 byte 총량을 추적할 수 있는가?
Always read를index → targeted read로 바꿔도 correctness가 유지되는가?- 같은 stable document를 operation 안에서 몇 번 다시 읽는가?
- provider cache가 이런 stable context를 실제로 얼마나 흡수하는가?
- byte 기반 context-load 추정치와 actual input token은 어느 정도 상관관계가 있는가?
처음에는 프롬프트를 짧게 만드는 문제라고 생각했다.
지금은 조금 다르게 본다.
Context engineering의 핵심은 정보를 어디에 저장하느냐만이 아니라, 실제 작업에서 그 정보를 언제 얼마나 다시 읽게 하느냐에 있다.
짧은 prompt는 좋은 시작이었다.
하지만 전체 input 비용을 줄이려면 transport 다음으로 retrieval을 설계해야 했다.