컨텍스트-기초

컨텍스트 엔지니어링 기초

컨텍스트는 추론 시점에 언어 모델이 사용할 수 있는 완전한 상태 정보입니다. 시스템 지침, 도구 정의, 검색된 문서, 메시지 기록, 도구 출력을 포함합니다. 컨텍스트 엔지니어링은 원하는 결과를 얻을 가능성을 최대화하는 가장 작은 고신호 토큰 집합을 선별하는 학문입니다.

이 스킬은 컬렉션의 다른 모든 스킬이 구축되는 개념적 기초입니다. 컨텍스트가 무엇인지, 어텐션 메커니즘이 어떻게 작동하는지, 컨텍스트의 양보다 질이 왜 중요한지, 그리고 다른 모든 컨텍스트 엔지니어링 결정을 해석하는 데 필요한 사고 모델을 설명합니다. 운영 작업을 소유하지 않습니다. 어텐션 실패 디버깅은 context-degradation, 토큰 효율성 전술은 context-optimization, 대화 요약은 context-compression, 파일 기반 오프로딩은 filesystem-context, 프로젝트 형태 결정은 project-development에 속합니다.

활성화 시점

작업이 개념적일 때 이 스킬을 활성화하세요.

• 컨텍스트가 무엇인지, 어텐션 메커니즘이 에이전트 동작을 어떻게 제약하는지 설명할 때.
• 운영 스킬을 배우기 전에 사고 모델이 필요한 새 기여자를 온보딩할 때.
• 특정 전술을 선택하기 전에 컨텍스트 관련 설계 결정을 첫 번째 원칙(이 제약이 의미하는 바는 무엇인지, 이 트레이드오프가 존재하는 이유는 무엇인지)에서 추론할 때.
• 운영 지침을 기본 메커니즘에 근거해야 하는 문서를 작성하거나 검토할 때.

운영 작업에는 이 스킬을 활성화하지 마세요. 전문화된 스킬이 실행을 담당합니다.

• 중간 손실, 컨텍스트 오염, 또는 어텐션 실패 진단: context-degradation.
• 마스킹, 분할, 접두사 캐싱, 예산을 통한 토큰 비용 절감: context-optimization.
• 긴 세션을 인계 요약으로 압축: context-compression.
• 대규모 도구 출력 오프로딩 또는 내구성 있는 스크래치패드 유지: filesystem-context.
• LLM 프로젝트 또는 파이프라인 형태 결정: project-development.

핵심 개념

컨텍스트를 저장소가 아닌 유한한 어텐션 예산으로 취급하세요. 추가된 모든 토큰은 모델의 어텐션을 놓고 경쟁하며 추론 중에 재충전할 수 없는 예산을 소진합니다. 엔지니어링 문제는 세 가지 제약(하드 토큰 한도, 더 부드러운 유효 용량 상한, 중간에 배치된 정보에 불이익을 주는 U자형 어텐션 곡선)에 대해 토큰당 유틸리티를 최대화하는 것입니다.

컨텍스트를 조합할 때 네 가지 원칙을 적용하세요.

1. 완전성보다 정보성 — 현재 결정에 중요한 것만 포함하고 필요에 따라 추가 정보를 검색할 수 있는 시스템을 설계하세요.
2. 위치 인식 배치 — 중요한 제약 조건을 컨텍스트의 시작과 끝에 배치하세요. 장기 컨텍스트 평가는 중간 위치 정보가 가장자리 위치 정보보다 덜 안정적으로 복구됨을 보여주기 때문입니다.
3. 점진적 공개 — 시작 시에는 스킬 이름과 요약만 로드하고 특정 작업에 스킬이 활성화될 때만 전체 내용을 로드하세요.
4. 반복적 큐레이션 — 컨텍스트 엔지니어링은 일회성 프롬프트 작성 연습이 아니라 콘텐츠가 모델에 전달될 때마다 적용되는 지속적인 학문입니다.

상세 주제

컨텍스트의 구조

시스템 프롬프트 XML 태그 또는 마크다운 헤더(배경, 지침, 도구 지침, 출력 형식)를 사용하여 시스템 프롬프트를 별도의 섹션으로 구성하세요. 시스템 프롬프트는 대화 전체에 걸쳐 지속되므로 가장 중요한 제약 조건을 어텐션이 가장 강한 시작과 끝에 배치하세요.

두 가지 실패 모드의 균형을 맞추기 위해 지침 고도를 조정하세요. 너무 낮은 고도는 조건이 변경될 때 깨지는 경직된 로직을 하드코딩합니다. 너무 높은 고도는 원하는 동작에 대한 구체적인 신호를 제공하지 못하는 모호한 지침을 제공합니다. 발견적 지침을 목표로 하세요. 동작을 안내할 만큼 구체적이고 일반화할 수 있을 만큼 유연해야 합니다. 예를 들어 각 단계에서 판단의 여지가 있는 번호가 매겨진 단계가 있습니다.

미리 엣지 케이스를 채우기보다는 최소한으로 시작한 다음 관찰된 실패 모드에 따라 반응적으로 지침을 추가하세요. 가능한 모든 시나리오를 나열하는 대신 예상되는 동작을 묘사하는 다양하고 표준적인 퓨샷 예제를 큐레이션하세요.

도구 정의 도구가 수행하는 작업, 사용 시기, 반환하는 내용이라는 세 가지 질문에 답하는 도구 설명을 작성하세요. 사용 컨텍스트, 매개변수 기본값 및 오류 사례를 포함하세요. 인간 엔지니어가 구분할 수 없는 도구는 에이전트도 구분할 수 없습니다.

도구 세트를 최소한으로 유지하세요. 중복 도구를 통합하세요. 도구 세트가 비대해지면 모호한 의사 결정 지점이 생성되고 JSON 직렬화 후에 불균형적으로 많은 컨텍스트를 소비하기 때문입니다.

검색된 문서 가벼운 식별자(파일 경로, 저장된 쿼리, 웹 링크)를 유지하고 적시 검색을 사용하여 데이터를 동적으로 컨텍스트에 로드하세요. 이는 인간 인지를 반영합니다. 인덱스는 유지하되 복사본은 유지하지 마세요. 강력한 식별자(예: customer_pricing_rates.json)를 사용하면 에이전트가 검색 도구 없이도 관련 파일을 찾을 수 있습니다. 약한 식별자(예: data/file1.json)는 불필요한 로드를 강제합니다.

대용량 문서를 청킹할 때는 임의의 문자 제한보다는 자연스러운 의미 경계(섹션 헤더, 단락 나누기)에서 분할하세요.

메시지 기록 메시지 기록은 진행 상황 추적, 작업 상태 유지, 턴 간 추론 보존을 위한 에이전트의 스크래치패드 메모리 역할을 합니다. 장기 실행 작업의 경우 컨텍스트 사용을 지배할 정도로 커질 수 있으므로 활성 지침을 밀어내기 전에 압축을 모니터링하고 적용하세요.

기록을 주기적으로 개선하세요. 대화 깊숙이 도구가 호출된 후에는 원시 결과가 그대로 남아 있을 필요가 거의 없습니다. 오래된 도구 출력을 간결한 요약이나 참조로 대체하여 낮은 신호의 부피를 줄이세요.

도구 출력 에이전트 궤적에서 도구 출력이 컨텍스트를 지배하는 경우가 많습니다. 관찰 마스킹을 적용하세요. 에이전트가 결과를 처리한 후에는 장황한 출력을 간결한 참조로 대체하세요. 가장 최근에 관련된 파일 내용만 유지하고 오래된 내용은 압축하거나 제거하세요.

컨텍스트 윈도우와 어텐션 메커니즘

어텐션 예산 n개의 토큰에 대해 어텐션 메커니즘은 n제곱의 쌍별 관계를 계산합니다. 컨텍스트가 커짐에 따라 이러한 관계를 유지하는 모델의 능력은 급격한 하강이 아닌 성능 그라데이션으로 저하됩니다. 주로 짧은 시퀀스로 훈련된 모델은 컨텍스트 전체 종속성에 대한 전문화된 매개변수가 더 적어 공칭 윈도우 크기보다 훨씬 낮은 유효 상한을 만듭니다.

이 그라데이션을 위해 설계하세요. 대상 워크로드에서 측정할 때까지 유효 용량이 광고된 윈도우보다 실질적으로 낮다고 가정하세요. 큰 공칭 컨텍스트 윈도우가 작업별 저하 테스트의 필요성을 없애지는 않습니다.

위치 인코딩 제한 위치 인코딩 보간은 훈련 길이를 넘어 시퀀스 처리를 확장하지만 위치 정밀도에 저하를 초래합니다. 확장된 컨텍스트에서는 짧은 입력에 비해 정보 검색 및 장거리 추론의 정확도가 감소할 것으로 예상하세요.

실제 점진적 공개 세 가지 수준에서 점진적 공개를 구현하세요.

1. 스킬 선택 — 시작 시 이름과 설명만 로드하고 필요에 따라 전체 스킬 콘텐츠를 활성화하세요.
2. 문서 로드 — 먼저 요약을 로드하고 작업에 필요한 경우에만 세부 섹션을 가져오세요.
3. 도구 결과 보존 — 최근 결과는 전체를 유지하고 오래된 결과는 압축하거나 제거하세요.

경계를 명확하게 유지하세요. 스킬이나 문서가 활성화되면 부분적으로 로드하지 말고 완전히 로드하세요. 부분 로드는 추론 품질을 저하시키는 혼란스러운 공백을 만듭니다.

컨텍스트의 질 대 양

더 큰 컨텍스트 윈도우가 메모리 문제를 해결한다는 가정을 거부하세요. 처리 비용은 컨텍스트 길이에 따라 불균형적으로 증가합니다. 선형 비용 증가뿐만 아니라 유효 용량 임계값을 넘으면 모델 성능이 저하됩니다. 접두사 캐싱을 사용하더라도 긴 입력은 비용이 많이 듭니다.

신호 밀도 테스트를 적용하세요. 컨텍스트의 각 부분에 대해 이를 제거하면 모델의 출력이 변경될지 물어보세요. 그렇지 않으면 제거하세요. 중복 콘텐츠는 단순히 토큰을 낭비하는 것이 아니라 고신호 콘텐츠에서 어텐션을 적극적으로 분산시킵니다.

실용적인 지침

이 섹션은 개념적 적용 조언을 제공합니다. 운영 스킬에 대한 포인터는 명시적으로 제공됩니다.

컨텍스트 결정에 대한 추론

컨텍스트 관련 설계 결정을 내려야 할 때 개념적 질문과 운영적 질문을 분리하세요. 개념적 질문은 "이것이 무엇을 의미하고 왜 중요한가"이고 운영적 질문은 "어떤 특정 기술을 적용하는가"입니다. 첫 번째 질문에 답하려면 이 스킬을 사용하고 두 번째 질문을 소유하는 전문화된 스킬로 라우팅하세요.

예를 들어, 긴 에이전트 세션을 요약할지 여부를 결정하는 데는 두 부분이 있습니다. (1) 요약이 필요한 이유(어텐션 예산은 유한하고, U자형 곡선은 중간 콘텐츠를 저하시키며, 신호 밀도가 양보다 중요함 - 이 스킬)와 (2) 어떤 압축 전략이 올바른 상태를 보존하고 어떤 활용 임계값에서 이를 트리거할지(context-compression).

새 기여자를 위한 읽기 순서

처음 컨텍스트 엔지니어링에 접하는 기여자는 다음을 읽어야 합니다.

1. 어텐션 예산 프레이밍과 U자형 곡선을 내면화하기 위한 이 스킬.
2. 실제 컨텍스트 실패의 모습과 진단 방법을 확인하기 위한 context-degradation.
3. 프로젝트와 가장 관련 있는 운영 문제에 따라 context-optimization, context-compression, filesystem-context, memory-systems 중 두세 개.

1단계를 건너뛰면 이유를 이해하지 못한 채 기술을 적용하는 실무자가 생깁니다. 운영 스킬을 건너뛰면 어떤 실패 모드에 어떤 기술이 적합한지 모르는 이론가가 생깁니다.

예시

예시 1: 시스템 프롬프트 구성

중요한 제약 조건이 어텐션에 유리한 위치(시작과 끝)에 속하며 명시적인 섹션 경계가 모델이 프롬프트를 구문 분석하는 데 도움이 된다는 개념적 요점을 보여줍니다.

<BACKGROUND_INFORMATION>
You are a Python expert helping a development team.
Current project: Data processing pipeline in Python 3.9+
</BACKGROUND_INFORMATION>

<INSTRUCTIONS>
- Write clean, idiomatic Python code
- Include type hints for function signatures
- Add docstrings for public functions
- Follow PEP 8 style guidelines
</INSTRUCTIONS>

<OUTPUT_DESCRIPTION>
Provide code blocks with syntax highlighting.
Explain non-obvious decisions in comments.
</OUTPUT_DESCRIPTION>

예시 2: 사고 모델로서의 어텐션 예산

대규모 컨텍스트 모델은 동등하게 주의를 기울이는 컨텍스트를 가지고 있지 않습니다. 유효 용량은 워크로드별로 다르며 U자형 곡선은 중간에 배치된 정보에 불이익을 줍니다. 상류 지식 베이스를 얼마나 로드할지 결정할 때는 다음과 같은 사고 모델을 사용하세요. "들어갈까"라고 묻지 말고 "모델이 여전히 중요한 부분에 주의를 기울일까"라고 물어보세요.

해당하는 운영 질문(어떤 기술이 로드를 줄여야 하는지)은 context-optimization에 속합니다.

지침

1. 컨텍스트를 수확 체감이 있는 유한한 자원으로 취급하세요.
2. 중요한 정보를 어텐션에 유리한 위치(시작과 끝)에 배치하세요.
3. 점진적 공개를 사용하여 필요할 때까지 로드를 연기하세요.
4. 시스템 프롬프트를 명확한 섹션 경계로 구성하세요.
5. 개발 중에 컨텍스트 사용량을 모니터링하세요.
6. 70-80% 활용도에서 압축 트리거를 구현하세요.
7. 회피를 바라지 않고 컨텍스트 저하를 위해 설계하세요.
8. 크고 낮은 신호의 컨텍스트보다 작고 높은 신호의 컨텍스트를 선호하세요.

주의사항

1. 공칭 윈도우는 유효 용량이 아닙니다: 큰 컨텍스트 윈도우를 광고하는 모델은 복잡한 검색 또는 추론 작업에서 그 한계에 훨씬 못 미쳐 저하될 수 있습니다. 자체 저하 테스트가 그 반대를 증명할 때까지 공칭 윈도우 아래로 예산을 책정하세요.

2. 문자 기반 토큰 추정은 조용히 표류합니다: 영어 산문에 대한 ~4자/토큰 경험 법칙은 코드(2-3자/토큰), URL 및 파일 경로(각 슬래시, 점, 콜론은 별도의 토큰), 비영어 텍스트(종종 1-2자/토큰)에서 깨집니다. 예산에 중요한 계산에는 제공업체의 실제 토크나이저(예: OpenAI 모델의 tiktoken, Anthropic의 토큰 카운팅 API)를 사용하세요.

3. 도구 스키마는 JSON 직렬화 후 2-3배 증가합니다: 소스 코드에서 간결해 보이는 도구 정의는 직렬화될 때 괄호, 따옴표, 콜론, 쉼표가 각각 토큰을 소비하면서 상당히 확장됩니다. 적당한 스키마를 가진 10개의 도구는 단일 메시지가 전송되기 전에 5,000-8,000 토큰을 소비할 수 있습니다. 소스 코드 줄 수가 아닌 직렬화된 도구 토큰 수를 감사하세요.

4. 메시지 기록은 에이전트 루프에서 조용히 부풀어 오릅니다: 각 도구 호출은 요청과 전체 응답을 모두 기록에 추가합니다. 20-30회 반복 후 기록은 윈도우의 70-80%를 소비할 수 있으며 에이전트는 추론 품질이 무너질 때까지 눈에 보이는 증상을 보이지 않습니다. 기록에 하드 토큰 상한을 설정하고 사전에 압축을 트리거하세요.

5. 중간의 중요한 지침은 손실됩니다: U자형 어텐션 곡선은 컨텍스트 중간이 시작과 끝보다 10-40% 낮은 회상 정확도를 받는다는 것을 의미합니다. 긴 시스템 프롬프트 중간에 안전 제약 조건, 출력 형식 요구 사항 또는 동작 가드레일을 절대 배치하지 말고 상단 또는 하단에 고정하세요.

6. 너무 열심히 로드하는 점진적 공개는 목적을 무효화합니다: 주제가 약간이라도 관련된다는 첫 힌트에 "잠재적으로 관련된" 모든 스킬이나 문서를 로드하면 컨텍스트 채우기 문제가 재현됩니다. 엄격한 활성화 임계값을 설정하세요. 작업이 트리거 조건과 명시적으로 일치할 때만 스킬을 로드해야 하며 주제가 단지 인접할 때는 안 됩니다.

7. 지침 고도를 혼합하면 일관성 없는 동작이 발생합니다: 매우 구체적인 규칙("항상 정확히 3개의 불릿 포인트 사용")을 높은 수준의 원칙("명확하고 간결하게 작성")과 결합하면 모델이 충돌하는 신호를 해결하기 위해 추론해야 합니다. 각 프롬프트 섹션 내에서 단일 고도를 유지하고 고도가 변경되는 위치에 명시적인 경계를 사용하세요.