컨텍스트 엔지니어링

확인 날짜 안내

확인 날짜가 섞인 페이지다. 기본은 원본 발행 2025-09-29 기준이다. 원칙은 오래 가지만, 원본에 나온 Claude Code 동작과 플랫폼 기능은 그 시점 기준이다. "앞선 글과의 관계" 절은 효과적인 에이전트 만들기(2024년 글)의 설계 원칙이라 날짜 계산에서 뺀다. 페이지 확인 날짜는 2026-10-18이다. 이 페이지의 변하는 사실은 "혼합 전략"의 Claude Code 동작 하나이고, Claude Code가 CLAUDE.md를 매 세션 시작 때 읽는다는 점은 공식 메모리 문서가, Read·Grep·Glob 도구로 파일을 찾는다는 점은 공식 권한 모드 문서가 확인하기 때문이다(둘 다 수집 2026-10-18). Claude Code 메모리, Claude Code 권한 모드 다만 하위 디렉터리 CLAUDE.md는 시작 때가 아니라 필요할 때 로드된다(메모리(CLAUDE.md)의 상충 콜아웃). 나머지는 원칙이라 날짜 계산에서 뺀다.

정의#

LLM 추론 중 컨텍스트(용어 사전)에 들어가는 토큰(정보)의 최적 집합을 고르고 유지하는 전략들이다. 프롬프트 바깥에서 들어오는 모든 정보까지 대상으로 한다. 효과적인 컨텍스트 엔지니어링

• 컨텍스트: LLM에서 샘플링할 때 포함되는 토큰 집합. 효과적인 컨텍스트 엔지니어링
• 엔지니어링 문제: LLM의 본래 제약 안에서 그 토큰들의 쓸모를 최적화해 원하는 결과를 꾸준히 얻는 것. 원본은 이를 "thinking in context"(그 순간 LLM이 볼 수 있는 전체 상태와 그 상태가 낳을 행동을 생각하기)라고 표현한다. 효과적인 컨텍스트 엔지니어링

프롬프트 엔지니어링과 무엇이 다른가#

근거: 효과적인 컨텍스트 엔지니어링. Anthropic은 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 다음 단계로 본다. 루프를 도는 에이전트는 다음 턴에 쓸 수도 있는 데이터를 계속 만들어 내므로, 그 정보를 주기적으로 다듬어야 한다.

왜 중요한가: 주의력 예산#

• Context rot: 컨텍스트 창의 토큰이 늘수록 그 안의 정보를 정확히 떠올리는 능력이 떨어진다. 저하 정도는 모델마다 다르지만 모든 모델에서 나타난다. 효과적인 컨텍스트 엔지니어링
• 그래서 컨텍스트는 한계 수익이 줄어드는 유한한 자원으로 다뤄야 한다. 사람의 작업 기억처럼 LLM에도 "attention budget"이 있고, 새 토큰 하나하나가 이 예산을 조금씩 깎는다. 효과적인 컨텍스트 엔지니어링
• 구조적 이유: 트랜스포머는 모든 토큰이 다른 모든 토큰을 참조해 n개 토큰에 n² 쌍의 관계가 생긴다. 길어질수록 이 관계를 잡는 능력이 얇게 펴진다. 또 학습 데이터에는 짧은 시퀀스가 더 흔해서, 모델은 컨텍스트 전체에 걸친 의존성에 경험이 적다. 효과적인 컨텍스트 엔지니어링
• 다만 절벽이 아니라 기울기다. 긴 컨텍스트에서도 모델은 충분히 유능하지만, 짧을 때보다 정보 검색과 장거리 추론의 정밀도가 떨어질 수 있다. 효과적인 컨텍스트 엔지니어링

Claude Code 확장 기능별로 이 예산을 얼마나 쓰는지는 컨텍스트 비용에 있다.

지침 원칙#

원하는 결과의 가능성을 최대로 높이는 가장 작은 고신호(high-signal) 토큰 집합을 찾는다. 원본은 말은 쉽고 실천은 어렵다고 덧붙인다. 효과적인 컨텍스트 엔지니어링

구성 요소별 적용(시스템 프롬프트의 적정 고도, 최소 도구 세트, 대표 예시)은 시스템 프롬프트·도구·예시 설계에 있다. 원본은 시스템 프롬프트, 도구, 예시, 메시지 기록 전반에 걸쳐 컨텍스트를 "정보는 충분하되 군더더기 없이"(informative, yet tight) 유지하라고 정리한다. 효과적인 컨텍스트 엔지니어링

미리 넣기 vs 필요할 때 불러오기#

• 미리 넣기: 많은 AI 앱이 추론 전에 임베딩 기반 검색으로 중요한 컨텍스트를 찾아 넣는다. 효과적인 컨텍스트 엔지니어링
• Just-in-time: 에이전트가 파일 경로, 저장된 쿼리, 웹 링크 같은 가벼운 식별자만 들고 있다가 도구로 필요한 데이터를 런타임에 불러온다. 원본은 점점 더 많은 팀이 기존 검색 시스템에 이 전략을 더하고 있다고 본다. 사람이 모든 것을 외우지 않고 파일 시스템, 받은편지함, 북마크로 필요할 때 찾는 것과 같다. 효과적인 컨텍스트 엔지니어링
• 메타데이터도 신호다: 폴더 위치, 이름 규칙, 타임스탬프가 정보를 언제 어떻게 쓸지 알려 준다. 원본 예: tests 폴더의 test_utils.py와 src/core_logic/의 같은 이름 파일은 목적이 다르다. 효과적인 컨텍스트 엔지니어링
• 점진적 공개(progressive disclosure): 에이전트가 스스로 탐색하며 관련 컨텍스트를 한 겹씩 발견하고, 작업 기억에는 필요한 것만 남기며, 더 오래 남길 것은 노트로 둔다. 효과적인 컨텍스트 엔지니어링
• 대가: 런타임 탐색은 미리 계산한 데이터를 가져오는 것보다 느리다. 적절한 도구와 휴리스틱이 없으면 에이전트가 도구를 잘못 쓰거나 막다른 길을 쫓거나 핵심 정보를 놓쳐 컨텍스트를 낭비할 수 있다. 효과적인 컨텍스트 엔지니어링
• 혼합 전략: 일부는 속도를 위해 미리 가져오고 나머지는 에이전트 판단으로 탐색한다. Claude Code가 이 방식이다: CLAUDE.md는 처음에 컨텍스트에 넣고, glob·grep으로 파일을 그때그때 찾는다. 원본은 혼합 전략이 법률·금융처럼 내용이 덜 동적인 일에 더 맞을 수 있다고 본다. 효과적인 컨텍스트 엔지니어링 → 메모리(CLAUDE.md)

Claude Code에서 본 혼합 전략 (2026-10-18 기준): Claude Code 공식 컨텍스트 창 문서는 무엇을 미리 넣고 무엇을 필요할 때 불러오는지 항목별로 보여 준다. 미리 넣는 것은 시스템 프롬프트, 자동 메모리(MEMORY.md 앞 200줄 또는 25KB), 환경 정보, 전역·프로젝트 CLAUDE.md다. 가볍게 이름만 넣고 필요할 때 불러오는 것은 MCP 도구(이름만, 전체 스키마는 tool search로)와 스킬(설명만, 본문은 쓸 때)이다. 맞는 파일을 읽을 때 따라 들어오는 것은 경로별 규칙이고, 파일 자체는 작업하며 읽는다. Claude Code 컨텍스트 창 편집자 해석: 이 구분은 원본(2025-09-29 글)의 "가벼운 식별자만 들고 있다가 런타임에 불러오기"를 제품 기능 단위로 구현한 예로 볼 수 있다. 근거는 2025년 글의 just-in-time 설명과 공식 문서의 "full schemas stay deferred and Claude loads specific ones on demand", "Full skill content loads only when Claude actually uses one" 문장이다. → 컨텍스트 비용

원본은 적절한 자율성 수준이 작업에 따라 다르며, 모델이 좋아질수록 사람의 큐레이션이 줄어드는 쪽으로 갈 것이라고 본다. 그래도 "do the simplest thing that works"(가장 단순하게 작동하는 것을 하라)가 Claude 위에서 에이전트를 만드는 팀에게 여전히 가장 좋은 조언일 것이라고 말한다. 효과적인 컨텍스트 엔지니어링

앞선 글과의 관계: 증강 LLM과 "가장 단순한 해법" (2024년 글)#

Anthropic의 에이전트 설계 글(2024-12-19)은 에이전트형 시스템의 기본 블록을 검색(retrieval), 도구, 메모리로 증강한 LLM으로 보고, 이 능력을 용도에 맞추고 LLM에게 쉽고 잘 문서화된 인터페이스를 주는 데 집중하라고 한다. 같은 글은 가능한 가장 단순한 해법을 찾고 필요할 때만 복잡도를 올리라고 권한다. 많은 애플리케이션에는 검색과 맥락 내 예시로 단일 LLM 호출을 최적화하는 것으로 보통 충분하다고 본다. 효과적인 에이전트 만들기 → 워크플로와 에이전트, 에이전트 시스템 패턴 고르기

2025-09-29 글은 이 앞선 글을 직접 언급한다. 앞선 글에서 LLM 기반 워크플로와 에이전트의 차이를 강조했고, 그 뒤로는 에이전트를 "루프 안에서 자율적으로 도구를 쓰는 LLM"이라는 단순한 정의로 보게 됐다고 말한다. 효과적인 컨텍스트 엔지니어링 앞선 글도 에이전트를 보통 "환경 피드백을 받아 루프 안에서 도구를 쓰는 LLM"이라고 설명한다. 효과적인 에이전트 만들기

편집자 해석: 위 "do the simplest thing that works" 문장은 앞선 글의 "가장 단순한 해법" 권고와 같은 방향으로 볼 수 있다. 근거는 두 원본의 해당 문장이다. 또 앞선 글이 말하는 증강(검색, 도구, 메모리)은 이 페이지가 다루는 컨텍스트 구성 요소와 겹치는 대상으로 볼 수 있다.

장기 작업#

토큰 수가 컨텍스트 창을 넘는 작업(대규모 코드베이스 마이그레이션, 종합 리서치처럼 수십 분에서 몇 시간 이어지는 일)에는 컴팩션, 구조화된 노트, 서브에이전트 구조 세 기법을 쓴다. 원본은 더 큰 컨텍스트 창을 기다리는 것은 답이 아닐 가능성이 높다고 본다. 가장 강한 성능이 필요한 상황에서는 크기와 무관하게 컨텍스트 오염과 관련성 문제가 당분간 남을 것이기 때문이다. 효과적인 컨텍스트 엔지니어링 → 장기 작업 컨텍스트 관리

이 위키와의 연결 (편집자 해석)#

아래는 원본이 직접 말한 것이 아니라, 원본 개념을 위키의 기존 페이지에 비춰 본 연결이다.

• LLM Wiki의 index는 원본이 말하는 가벼운 식별자 목록에 가깝다. 질의 때 index를 먼저 읽고 필요한 페이지만 여는 방식(index·log 운영)은 just-in-time 불러오기와 같은 모양이다.
• 위키 자체는 원본이 말하는 구조화된 노트(창 밖에 쓰고 나중에 다시 읽는 기억)의 한 형태로 볼 수 있다.
• 사실: Claude Code의 스킬은 세션 시작 때 설명만 넣고 쓸 때 전체 내용을 불러오며, 서브에이전트는 메인 세션과 격리된 새 컨텍스트에서 돈다. Claude Code 확장 기능 개요 → 컨텍스트 비용 해석: 이 설계는 원본의 just-in-time 불러오기·점진적 공개, 서브에이전트 구조와 같은 방향으로 읽을 수 있다.

결론부의 전망#

원본은 모델이 똑똑해질수록 덜 처방적인 엔지니어링이 필요해 에이전트가 더 자율적으로 움직이지만, 컨텍스트를 귀하고 유한한 자원으로 다루는 일은 계속 핵심으로 남을 것이라고 본다. 효과적인 컨텍스트 엔지니어링