2. 점진적 공개

한 줄 정의. 점진적 공개는 지금 필요한 것만 그 순간 컨텍스트에 올리는 설계 원리이며, 스킬에서 출발해 도구·메모리·문서 전반으로 일반화된다.

왜 중요한가

1장에서 본 스킬의 3단계 로딩은 사실 더 큰 원리의 한 사례입니다. 그 원리는 “컨텍스트는 유한한 예산”이라는 사실에서 나옵니다.

Anthropic의 컨텍스트 엔지니어링 가이드는 LLM에게 “어텐션 예산(attention budget)“이 있다고 말합니다.¹ 토큰 하나하나가 이 예산을 깎아 먹고, 예산을 다 쓰면 능력이 늘기는커녕 오히려 무뎌집니다.

그래서 같은 가이드는 컨텍스트를 “수확 체감(diminishing marginal returns)을 가진 유한 자원”으로 다루라고 못 박습니다.¹ 이 한 문장이 이 장 전체의 출발점입니다. 능력을 더하는 일과 컨텍스트를 채우는 일은 다릅니다. 점진적 공개는 둘을 분리합니다.

어텐션 예산은 왜 유한한가: 두 개의 축

“예산이 유한하다”는 말은 비유가 아니라 두 가지 구체적인 메커니즘에서 나옵니다. 하나는 아키텍처에서, 다른 하나는 학습 분포에서 옵니다. 둘 중 하나만 보면 설명이 반쪽이 됩니다.

축 1 — 트랜스포머의 n² 쌍관계

LLM은 트랜스포머 아키텍처 위에 서 있습니다. 이 구조의 핵심은 “모든 토큰이 컨텍스트 전체에 걸쳐 다른 모든 토큰을 주목(attend)할 수 있다”는 점입니다.¹

표현력이 여기서 나오지만, 동시에 비용도 여기서 나옵니다. 토큰이 $n$개라면 주목해야 할 관계의 수는 $n^2$개의 쌍관계(pairwise relationships)가 됩니다.

흔히 “n²”라고만 말하지만, 정확히는 토큰 쌍 하나하나의 관계가 전부 계산 대상이라는 뜻입니다.¹

문제는 이 쌍관계를 포착하는 모델의 능력이 무한정 늘어나지 않는다는 데 있습니다. 가이드의 표현을 그대로 옮기면, “컨텍스트 길이가 늘어날수록 모델이 이 쌍관계들을 포착하는 능력은 얇게 늘어난다(gets stretched thin)“는 것입니다.¹

같은 양의 어텐션 용량을 점점 더 많은 토큰 쌍에 나눠 써야 하니, 토큰 하나가 가져가는 “주목의 몫”이 묽어집니다.

축 2 — 학습 데이터의 짧은 시퀀스 편중

아키텍처만으로는 절반만 설명됩니다. 두 번째 축은 모델이 무엇을 보고 배웠느냐입니다.

가이드는 모델이 “컨텍스트 전반에 걸친 의존성(context-wide dependencies)을 다룬 경험이 적고, 그것을 위한 전문 파라미터도 적다”고 지적합니다.¹ 이유는 단순합니다.

학습 데이터에서는 “짧은 시퀀스가 긴 시퀀스보다 일반적으로 더 흔하기” 때문입니다.¹ 모델은 짧은 맥락 안의 관계를 압도적으로 많이 보면서 학습하고, 긴 거리 의존성을 다룰 기회는 상대적으로 드뭅니다.

유한성은 구조와 분포의 합작

어텐션 예산이 유한한 이유를 “트랜스포머가 n²이라서”로만 설명하면 반쪽입니다. 정확히는 (1) 아키텍처상 쌍관계가 n²으로 늘어 어텐션이 묽어지고, (2) 학습 시 짧은 시퀀스에 편중돼 긴 컨텍스트 의존성을 다룰 경험·파라미터가 적다는 두 축이 함께 작동합니다.¹ 그래서 컨텍스트를 늘린다고 능력이 비례해 늘지 않습니다.

컨텍스트 부패: 정확한 정의와 1차 근거

이 두 축이 겹친 결과가 컨텍스트 부패(context rot)입니다. 가이드는 이를 “컨텍스트 창의 토큰 수가 늘어날수록, 그 컨텍스트에서 정보를 정확히 떠올리는 모델의 능력이 떨어진다”고 정의합니다.¹

핵심은 이것이 일부 약한 모델만의 문제가 아니라는 점입니다. “어떤 모델은 다른 모델보다 더 완만하게 저하되지만, 이 특성은 모든 모델에 걸쳐 나타난다”는 것이 가이드의 진술입니다.¹

흔히 “모델 크기와 무관”이라고 뭉뚱그리지만, 더 정확히는 완만함의 정도만 다를 뿐 예외가 없다는 쪽입니다.

출처와 규모

이 개념은 needle-in-the-haystack 방식의 벤치마킹 연구에서 드러났고,¹ 1차 근거는 Chroma의 Context Rot 연구입니다.² Chroma는 GPT-4.1, Claude 4(Opus/Sonnet), Gemini 2.5, Qwen3 등 18종의 LLM을 평가했습니다.²

결론은 단호합니다. “모든 실험에 걸쳐, 입력 길이가 늘어나면 모델 성능이 일관되게 저하된다”는 것입니다.²

깨지는 통념

Chroma가 정면으로 겨눈 통념은 “모델이 컨텍스트를 균일하게 처리한다”는 가정입니다. 통념대로라면 “모델은 10,000번째 토큰도 100번째 토큰만큼 안정적으로 다뤄야” 합니다.

“그러나 실제로는 이 가정이 성립하지 않는다”는 것이 Chroma의 핵심 발견입니다.² 대신 “모델은 컨텍스트를 균일하게 사용하지 않으며, 입력이 길어질수록 성능이 점점 더 불안정해진다”고 정리합니다.²

놀라운 점은 이 저하가 어려운 과제에 국한되지 않는다는 것입니다. 단어를 그대로 반복하는 수준의 단순 과제조차, 입력을 25단어에서 10,000단어로 늘리면 성능이 떨어졌습니다.²

무엇이 부패를 가속하나

Chroma는 저하의 결정요인도 짚었습니다.

• 유사도: needle(찾을 정보)과 question(질문)의 의미 유사도가 낮을수록 저하 속도가 빨라집니다.²
• 혼란 항목(distractor): distractor의 영향은 균일하지 않습니다. 어떤 혼란 항목은 다른 것보다 훨씬 더 해롭습니다.²
• 모델별 환각: Claude 계열은 환각률이 가장 낮았고, GPT 계열은 가장 높았습니다.²

프리로드 비용을 “지연·비용”으로만 적지 말 것

프리로드의 진짜 위험은 단순한 지연이 아니라 정확도 자체의 저하입니다. 무관한 토큰이 distractor로 작동하고, 입력 길이가 늘어 부패가 앞당겨집니다.² 즉 “혹시 쓸지 몰라 넣어 둔” 토큰이 정작 필요한 추론의 정확도를 깎습니다.

JIT: 적시 로딩의 정확한 메커니즘

부패가 입력 길이에서 온다면, 해법은 입력을 짧게 유지하는 것입니다. “미리 다 담기”가 아니라 “그때 가서 꺼내기”입니다. 가이드는 이를 적시 로딩(just-in-time) 전략이라 부릅니다.¹

핵심은 에이전트가 데이터 전체를 앞단에 적재하지 않고 “가벼운 식별자(파일 경로, 저장된 질의, 웹 링크 등)를 유지하다가, 이 참조들을 실행 시점에 도구로 동적으로 컨텍스트에 로드한다”는 것입니다.¹ “가벼운 식별자”라는 추상어보다, 그것이 파일 경로·저장된 질의·웹 링크 같은 구체적 종류임을 기억하는 편이 실무에서 유용합니다.

Claude Code의 실천

가이드가 든 1차 사례는 Claude Code입니다. 가이드의 원문 메커니즘은 이렇습니다.

모델은 “표적 질의(targeted queries)를 작성하고, 결과를 저장하며, head·tail 같은 Bash 명령을 활용해 대용량 데이터를 분석하되, 전체 데이터 객체(full data objects)를 절대 컨텍스트에 올리지 않는다”는 것입니다.¹ 여기서 head와 tail은 그 자체로 별난 기법이 아니라 평범한 Bash 명령이고, 진짜 요점은 전체 객체를 통째로 올리지 않는다는 데 있습니다.

# 표적 질의로 후보만 좁히고, 결과를 식별자로 보관
grep -rl "TimeoutError" ./logs > /tmp/hits.txt   # 매칭된 파일 경로만 저장

# 전체를 올리지 않고 양 끝만 들여다봄
head -n 20 "$(head -n1 /tmp/hits.txt)"           # 첫 후보 파일의 앞부분
tail -n 20 "$(head -n1 /tmp/hits.txt)"           # 같은 파일의 끝부분

위 흐름에서 컨텍스트에 들어오는 것은 “파일 경로 목록”과 “양 끝 몇 줄”뿐입니다. 로그 파일 본문 전체는 디스크에 남아 있고, 토큰 예산은 거의 손대지 않습니다.

탐색이 단서를 쌓는다

이런 방식은 한 번에 정답을 인출하지 않습니다. 대신 탐색이 진행되며 단서가 쌓입니다.

가이드의 표현으로는 “매 상호작용이 다음 결정을 알려 주는 컨텍스트를 낳는다”는 것입니다. 파일 크기는 복잡도를 시사하고, 이름 규칙은 용도를 귀띔하며, 타임스탬프는 최신성의 대리 지표가 됩니다.¹

그렇게 “에이전트는 층층이 이해를 조립(assemble understanding layer by layer)“합니다.¹

점진적 공개: 컨텍스트 엔지니어링의 일반 원리

바로 이 JIT 접근이 점진적 공개를 가능하게 합니다. 가이드는 JIT가 “점진적 공개를 가능하게 한다 — 다시 말해, 에이전트가 탐색을 통해 관련 컨텍스트를 점진적으로 발견하도록 한다”고 정의합니다.¹

여기서 분명히 해 둘 것은, 점진적 공개가 1장의 “스킬 3단계 로딩”에만 묶인 규칙이 아니라는 점입니다. 그것은 컨텍스트를 차지하는 거의 모든 자원에 적용되는 컨텍스트 엔지니어링의 일반 원리입니다.

스킬은 그 원리가 가장 또렷하게 구현된 한 사례일 뿐입니다.

스킬 로딩 3단계와 정확한 토큰 예산

스킬은 점진적 공개를 발견(discovery)·활성화(activation)·실행(execution) 세 단계로 구현합니다.³

1. 발견(Discovery): “시작 시점에, 에이전트는 사용 가능한 각 스킬의 이름과 설명만 로드한다 — 언제 관련될 수 있는지 알기에 딱 충분할 만큼.”³
2. 활성화(Activation): “작업이 어떤 스킬의 설명과 매칭되면, 에이전트는 그 SKILL.md의 전체 지침을 컨텍스트로 읽어 들인다.”³
3. 실행(Execution): “에이전트는 지침을 따르며, 필요에 따라 번들된 코드를 실행하거나 참조된 파일을 로드한다.”³

핵심 문장은 이것입니다. “전체 지침은 작업이 그것을 요구할 때만 로드되므로, 에이전트는 작은 컨텍스트 발자국만으로 많은 스킬을 손에 쥘 수 있다.”³

단계별 토큰 예산

스펙은 각 단계의 토큰 예산을 구체적으로 정합니다. 막연히 “가볍다”가 아니라 숫자가 있습니다.⁴

단계	무엇이 로드되나	토큰 예산
메타데이터(발견)	name·description만, 시작 시 전 스킬	스킬당 약 100토큰4
지침(활성화)	SKILL.md 본문 전체	5,000토큰 미만 권장4
리소스(실행)	scripts/·references/·assets/	필요할 때만(as needed)4

“스킬당 약 100토큰”은 정확히 이 스펙의 메타데이터 예산과 일치합니다.⁴ 여기에 더해 스펙은 SKILL.md 본문을 5,000토큰 미만으로, 또 500줄 미만으로 유지할 것을 권합니다.⁴

활성화 시 SKILL.md “전체”가 로드된다

자주 틀리는 지점입니다. 스펙은 “에이전트가 스킬을 활성화하기로 결정하면 이 파일 전체를 로드한다”고 명시합니다.

그래서 “더 긴 SKILL.md 내용은 참조 파일로 분리하는 것을 고려하라”고 권고합니다.⁴ SKILL.md가 길면 매번 그 전체가 컨텍스트로 들어오므로, 본문은 짧게 두고 상세는 references/로 미루는 편이 점진적 공개의 취지에 맞습니다.

프론트매터 제약

스펙은 스킬 프론트매터에 정확한 제약을 둡니다.⁴

• name: 최대 64자, 소문자·숫자·하이픈만 허용. 하이픈으로 시작·끝나거나 연속될 수 없고, 부모 디렉터리명과 일치해야 합니다.
• description: 최대 1024자, 비어 있으면 안 됩니다. “무엇을 하고 언제 쓰는지” + 식별용 키워드를 담아야 합니다. 발견 단계에서 매칭을 좌우하는 것이 바로 이 필드이기 때문입니다.
• 선택 필드: license, compatibility(최대 500자), metadata, 그리고 공백으로 구분한 사전 승인 도구 목록인 allowed-tools(실험적).

---
name: log-analyzer            # 64자 이내, 소문자·숫자·하이픈, 폴더명과 일치
description: 서버 로그에서 오류 패턴을 찾아 요약합니다. 타임아웃·예외·스택트레이스 분석이 필요할 때 사용. (1024자 이내)
allowed-tools: Bash Read Grep  # 공백 구분, 실험적
---

references는 얕게

리소스 로딩에도 원리가 있습니다. 스펙은 “에이전트가 이 파일들을 온디맨드로 로드하므로, 파일이 작을수록 컨텍스트 사용이 적다”고 말합니다.⁴ 또한 파일 참조는 “한 단계 깊이(one level deep)“로 얕게 유지하고, 깊은 중첩 참조 체인은 피하라고 권합니다.⁴ 참조가 참조를 부르는 체인은 결국 통제 불가능한 적재로 번지기 때문입니다.

”필요한 것만, 필요할 때만” — Claude의 능동 스캔

Claude의 스킬 설명도 같은 원리를 다른 각도에서 진술합니다. 핵심 문구는 “오직 필요한 것만, 필요할 때만 로드한다(only loads what’s needed, when it’s needed)“입니다.⁵

메커니즘은 능동적입니다. “작업을 수행하는 동안 Claude는 사용 가능한 스킬들을 스캔해 관련된 것을 찾고, 매칭되면 필요한 최소한의 정보와 파일만 로드한다 — 전문성에 접근하면서도 Claude를 빠르게 유지한다.”⁵

컴포저빌리티: 누적 페널티 없는 공존

스킬은 서로 쌓입니다. “스킬은 함께 쌓이며(stack together), Claude는 어떤 스킬이 필요한지 자동으로 식별하고 그 사용을 조율한다”는 것입니다.⁵

활성화된 자원만 비용을 내므로, 여러 스킬을 손에 쥐고 있어도 쓰지 않는 스킬은 메타데이터 약 100토큰⁴ 외에 예산을 잠식하지 않습니다. 점진적 공개가 컴포저빌리티의 전제 조건인 셈입니다.

실행 코드: JIT의 또 다른 형태

스킬은 “전통적 프로그래밍이 토큰 생성보다 더 신뢰할 수 있는 작업을 위한 실행 가능 코드”를 포함할 수 있습니다.⁵ 블로그에 따르면 스킬은 “실행에 필요한 안전한 환경을 제공하는” Code Execution Tool(베타)을 요구합니다.⁵

즉 토큰을 생성하며 추론하는 대신, 코드를 격리된 실행 환경으로 밀어내는 것입니다. 결정론적 계산을 모델 바깥으로 떼어내는 이런 방식 역시 적시 로딩과 같은 결의 절약으로 볼 수 있습니다.

스킬을 넘어 일반화하기

발견 → 활성화 → 실행이라는 틀은 스킬에만 적용되는 규칙이 아닙니다. 같은 틀을 컨텍스트를 차지하는 거의 모든 자원에 그대로 얹을 수 있습니다.

자원	평소(발견)	필요할 때(활성화·실행)
스킬	이름·설명만 상주(약 100토큰)	SKILL.md 본문·scripts/·references/ 적재
도구	호출 가능하다는 사실만	실제 호출 시 입력·출력만 소비
메모리	어떤 메모가 있는지 색인	관련 항목만 그때 읽기
문서	경로·요약·목차	해당 구간만 발췌

별도의 컨텍스트 창으로 작업을 떼어 내는 서브에이전트도 같은 절약을 구조적으로 실현하는 또 다른 방식입니다.

도구: 프리로드가 안티패턴인 정확한 근거

도구는 특히 함정이 많은 자원입니다. 가이드는 “우리가 보는 가장 흔한 실패 모드 중 하나는, 너무 많은 기능을 덮으려 하거나 어느 도구를 쓸지 모호한 결정 지점을 낳는 비대한 도구 세트(bloated tool sets)“라고 진단합니다.¹

도구가 많으면 정의가 예산을 잠식하는 데 그치지 않고, 어느 도구를 골라야 할지가 흐려져 판단까지 무너집니다.

판별 기준은 실무적입니다. “사람 엔지니어가 주어진 상황에서 어느 도구를 써야 할지 단정적으로 말할 수 없다면, AI 에이전트에게 더 잘하리라 기대할 수 없다”는 것입니다.¹ 도구 개수를 임의로 정하기보다, 사람이 선택을 단정할 수 있을 만큼 도구 경계가 명확한지를 먼저 물어야 합니다.

왜 전부 프리로드가 안티패턴인가 — 비용 3종

“혹시 쓸지 모르니 일단 다 넣자”는 직관은 컨텍스트에서 거꾸로 작동합니다. 세 가지 비용으로 정리됩니다.

1. 예산 잠식: 쓰지 않을 토큰이 어텐션 예산을 미리 소진해, 정작 필요한 추론에 쓸 여력을 줄입니다. 가이드의 “유한 자원·수확 체감” 프레임과 정확히 맞물립니다.¹
2. 혼란 가속: 관련 없는 내용이 distractor로 작동합니다. distractor의 영향은 균일하지 않으며,² 입력이 길어질수록 성능은 점점 더 불안정해집니다.² 무관한 토큰이 부패를 앞당기는 것입니다.
3. 앞단 지연·비용: 적재 자체가 앞단의 지연과 비용을 만듭니다.

프리로드와 JIT의 비용은 방향이 반대다

두 비용을 혼동하면 안 됩니다. 프리로드는 앞단 비용을 키우고(예산 잠식·혼란·적재 지연), JIT는 런타임 비용을 키웁니다. 가이드는 “런타임 탐색이 미리 계산된 데이터를 가져오는 것보다 느리다”고 분명히 말합니다.¹ 둘은 트레이드오프이지, 한쪽이 항상 공짜인 관계가 아닙니다.

JIT의 트레이드오프와 하이브리드 절충

점진적 공개를 절대 원칙으로 떠받들면 도리어 다친다는 점도 가이드가 짚습니다. JIT에는 실제 단점이 있습니다.

런타임 탐색은 미리 계산된 데이터를 가져오는 것보다 느립니다.¹ 또한 “에이전트는 도구를 잘못 쓰거나, 막다른 길을 좇거나, 핵심 정보를 식별하지 못해 컨텍스트를 낭비할 수 있다”는 위험이 있습니다.¹

같은 파일을 반복해 인출하거나 헛다리를 짚는 일이 여기 해당합니다. 그래서 가이드는 “LLM이 자기 정보 지형을 효과적으로 항해할 올바른 도구와 휴리스틱을 갖추도록, 의견 있고 사려 깊은 엔지니어링이 필요하다”고 단서를 답니다.¹

하이브리드 정석

정답은 “전부 프리로드”도 “전부 JIT”도 아닙니다. 가이드가 든 Claude Code의 절충이 정석입니다.

“CLAUDE.md 파일은 앞단에 그냥 떨궈 넣고(naively dropped into context up front), glob·grep 같은 프리미티브가 환경을 항해하며 파일을 적시에 인출하게 해, 낡은 인덱싱(stale indexing) 문제를 효과적으로 우회한다”는 것입니다.¹ 즉 자주 쓰는 일부(CLAUDE.md)는 선적재하고, 나머지는 런타임에 인출합니다.

“전부 프리로드 안티패턴”을 절대화하지 말 것

결정 기준은 작업에 달려 있습니다. 가이드는 “올바른 자율성 수준의 결정 경계는 작업에 따라 다르다”고 말합니다.¹ 동적 콘텐츠가 적은 법률·금융 작업이라면, 사전 계산이나 선적재가 오히려 더 적합할 수 있습니다. 점진적 공개는 기본값이지 유일한 정답이 아닙니다.

예제

같은 일을 두 방식으로 시킨다고 해봅시다. 작업은 “로그 파일에서 오류 패턴을 찾아 요약하라”입니다.

# 안티패턴: 전부 프리로드
[시스템 프롬프트에 10MB 로그 전체 + 분석 스킬 본문 5개 + 사내 위키 전체 적재]
→ 예산 대부분이 소진됨. 무관한 토큰이 distractor로 작동하고,
  입력이 길어 뒤쪽 정보의 회상 정확도가 떨어짐(컨텍스트 부패).

# JIT: 필요할 때만
1) 발견:  사용 가능한 분석 스킬의 이름·설명만 상주(스킬당 ~100토큰)
2) 활성화: 요청이 "로그 분석" 스킬과 매칭 → 그 SKILL.md 본문만 로드(<5000토큰)
3) 실행:  표적 질의로 후보 파일 경로만 저장, head·tail로 양 끝만 확인
         → 전체 데이터 객체가 아니라 관련 조각만 컨텍스트에 들어옴
→ 예산에 여유가 남아 추론과 요약에 집중.

차이는 능력이 아니라 적재 전략입니다. 둘 다 같은 스킬과 같은 로그에 접근하지만, 무엇을 언제 컨텍스트에 올리느냐가 결과를 가릅니다.

다만 JIT 쪽도 공짜는 아닙니다. 표적 질의가 헛다리를 짚으면 같은 로그를 반복 인출하며 도리어 토큰을 낭비할 수 있고,¹ 이때 필요한 것이 “어느 도구를 어떤 휴리스틱으로 쓸지”를 잡아 주는 엔지니어링입니다.¹

요약 · 체크리스트

• 어텐션 예산이 유한한 이유를 두 축(트랜스포머 n² 쌍관계 + 학습 시 짧은 시퀀스 편중)으로 설명할 수 있다.
• 컨텍스트 부패의 정의와 1차 근거(Chroma 18종 모델 평가, 입력 길이↑ 시 단순 과제서도 일관 저하)를 안다.
• JIT 로딩(가벼운 식별자: 파일 경로·저장된 질의·웹 링크 + 동적 인출)이 무엇이며, Claude Code가 표적 질의와 head·tail로 전체 객체를 안 올리는 방식을 안다.
• 스킬 3단계와 토큰 예산(메타데이터 ~100, SKILL.md <5000토큰·500줄, 리소스 온디맨드), 활성화 시 SKILL.md 전체가 로드된다는 주의점을 안다.
• 전부 프리로드가 왜 안티패턴인지(예산 잠식·혼란 가속·앞단 지연)와, 그 절대화가 위험한 이유(JIT의 런타임 지연·하이브리드 절충)를 함께 말할 수 있다.

관련 장

• 1. 스킬 기본형
• 5. 컨텍스트 엔지니어링
• 7. 서브에이전트

Footnotes

1. Effective context engineering for AI agents — Anthropic Engineering ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸

2. Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

3. Agent Skills — Overview (agentskills.io) ↩ ↩² ↩³ ↩⁴ ↩⁵

4. Agent Skills — Specification (agentskills.io) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

5. Equipping agents for the real world with Agent Skills — Claude blog ↩ ↩² ↩³ ↩⁴ ↩⁵