컨텍스트 엔지니어링
프롬프트 엔지니어링은 당신이 고르는 단어에 관한 것입니다. 컨텍스트 엔지니어링은 당신이 모델에게 건네는 작업 공간에 관한 것입니다 — 그 안에 무엇이 있고, 어떤 순서로 있으며, 무엇을 의도적으로 빼두었는지.
이 구분이 중요한 이유는 컨텍스트 윈도우가 메모장이 아니기 때문입니다. 그것은 제한되고, 비싸며, 주의력의 자원입니다. 그것을 어떻게 채우느냐가 모델이 무엇에 집중하는지, 비용이 얼마나 드는지, 그리고 세션이 길어져도 유용함을 유지하는지를 바꿉니다.
컨텍스트 예산
모든 모델에는 최대 컨텍스트 크기가 있습니다 — 토큰으로 측정되는 단단한 상한선입니다. 그것을 예산이라고 생각하세요. 당신은 그것을 다음에 씁니다:
- 시스템 프롬프트와 상시 지시
- 검색된 문서, 코드베이스 조각, 도구 정의
- 대화 기록
- 모델의 출력(멀티턴 세션에서는 이것도 윈도우에 포함됩니다)
다 떨어지면 무언가는 양보해야 합니다. 오래된 내용이 버려지거나, 세션이 벽에 부딪힙니다.
대부분의 입문 가이드는 컨텍스트 윈도우를 "많을수록 좋다"로 다룹니다. 컨텍스트 엔지니어링은 그것을 신중하게 배분할 자원으로 다룹니다. 관련 있을 법한 모든 것이 아니라, 이번 턴에 모델이 실제로 필요로 하는 것에 그것을 쓰세요.
컨텍스트 부패와 "중간에서 길을 잃다"
장문맥 LLM에는 잘 문서화된 현상이 있습니다. 모델은 컨텍스트의 시작과 끝 근처의 내용에 불균형적으로 주의를 기울이고, 중간에 파묻힌 내용에 대한 회상은 떨어집니다. 이 효과를 연구한 연구자들은 그것을 "중간에서 길을 잃다(lost in the middle)"라고 불렀습니다.
실질적인 결과: 만약 당신이 100,000토큰짜리 컨텍스트를 문서로 채우고 가장 중요한 지시를 60,000번째 위치에 파묻는다면, 모델은 사실상 그것을 무시할 수 있습니다 — 거기까지 읽을 능력이 없어서가 아니라, 주의력이 윈도우 전체에 고르게 분포되지 않기 때문입니다.
"컨텍스트 부패(context rot)"는 더 넓은 패턴입니다. 세션이 길어질수록 응답의 품질이 떠내려가는 경향이 있습니다. 초기 지시가 희석됩니다. 반복되는 주고받음이 원래 작업을 밀어냅니다. 모델이 얼버무리기 시작하고, 같은 말을 반복하거나, 당신이 실제로 요청한 것의 흐름을 잃습니다.
이것들은 더 나은 프롬프트로 완전히 고칠 수 있는 버그가 아닙니다. 대규모에서 주의력이 작동하는 방식의 구조적 속성입니다. 엔지니어링적 대응은 컨텍스트를 채우고 바라는 것이 아니라 더 작고 날카롭게 유지하는 것입니다.
순서가 중요하다
내용을 어디에 두느냐는 무엇을 포함하느냐만큼 중요합니다. 확립된 좋은 관행:
| 위치 | 거기에 무엇을 둘 것인가 |
|---|---|
| 맨 위(시스템 프롬프트) | 안정적이고 내구성 있는 지시. 페르소나, 규칙, 형식 요구 사항. |
| 시스템 프롬프트 다음 | 현재 작업을 평이한 말로. |
| 마지막 사용자 턴 바로 앞 | 바로 이 요청에 가장 중요하고 구체적인 컨텍스트. |
| 중간 | 보조 문서, 검색된 조각 — 시간순이 아니라 관련성순으로 정렬. |
| 대화 기록 | 연속성에 필요한 것만. 공격적으로 가지치기. |
일반 규칙: 현재 턴에 가까울수록 더 많은 주의를 받습니다. 긴 기록의 중간에만 존재하는 중요한 지시는 위험에 처합니다.
욱여넣기보다 검색
유혹은 모든 것을 넣는 것입니다. 모든 문서, 전체 코드베이스, 대화 전체. 저항하세요.
더 나은 접근은 선택적 검색입니다. 이 특정 요청에 모델이 실제로 필요로 하는 것을 식별하고, 그것만 주입하세요. 잘 검색된 2,000토큰짜리 올바른 문서 조각은, 답이 어딘가 중간에 있는 40,000토큰짜리 덤프를 능가합니다.
이것이 검색 증강 생성(RAG)이 존재하는 이유입니다 — 단지 컨텍스트 한계를 극복하기 위해서가 아니라, 컨텍스트를 큐레이션된 상태로 유지함으로써 품질을 높이기 위해서입니다.
대화형 세션에도 같은 논리가 적용됩니다. 모든 것을 쌓아가는 대신, 현재 작업에 더 이상 관련 없는 내용을 제거하기 위해 주기적으로 기록을 압축하거나 비우세요. Claude Code의 /compact와 /clear 명령은 단순한 세션 관리가 아니라 컨텍스트 엔지니어링 도구입니다.
비용의 측면
당신이 보내는 토큰은 당신이 비용을 치르는 토큰입니다 — 돈으로도, 지연 시간으로도. 느슨하게 관련된 자료로 컨텍스트를 욱여넣으면 둘 다 부풀어 오릅니다. 컨텍스트 엔지니어링과 비용 효율성은 같은 문제입니다.
더 구체적으로:
- 템플릿에서 복사-붙여넣기 한 비대한 시스템 프롬프트는 매 호출마다 비용을 치릅니다.
- "유용할지도 모른다"는 이유로 들고 가는 오래된 대화 기록은 매 호출마다 비용을 치릅니다.
- "혹시 몰라서" 주입하는 문서는 매 호출마다 비용을 치릅니다.
거기 있을 필요가 없는 것을 덜어내는 것은 품질에도 더 좋고 운영에도 더 쌉니다.
Claude 사용자를 위한 실용적 전술
Claude.ai에서:
- 별개의 작업에는 별개의 대화를 쓰세요. 한나절의 옆길이 집중된 프로젝트의 컨텍스트를 오염시키지 않게 하세요.
- 긴 스레드에 의존하는 복잡한 질문을 하기 전에 그것을 요약하세요. 명시적 요약이 종종 원본 기록보다 더 유용합니다.
- 원하는 구체적인 것을 긴 메시지의 중간에 파묻지 말고 끝에 두세요.
Claude Code에서:
CLAUDE.md파일을 군더더기 없이 유지하세요. 그 안의 모든 줄이 모든 세션에 주입됩니다. CLAUDE.md와 컨텍스트 관리를 참고하세요.- 진정으로 다른 작업으로 전환할 때
/clear를 쓰세요. 계속하고 싶지만 세션이 커지고 있을 때/compact를 쓰세요. - 현재 단계에 전체 파일이 필요하지 않다면 내용을 붙여 넣는 대신 경로로 파일을 참조하세요.
API 수준에서:
- 시스템 프롬프트를 모든 요청이 진정으로 필요로 하는 것만 담도록 설계하세요. 작업별 지시는 사용자 턴으로 옮기세요.
- 문서가 많은 사용 사례에서는 전체 말뭉치를 업로드하는 대신 관련 조각을 검색해 주입하세요.
- 안정적이고 재사용 가능한 접두부가 먼저 오도록 프롬프트를 구조화하세요 — 이것은 프롬프트 캐싱도 가능하게 하며, 캐싱은 컨텍스트 엔지니어링의 자연스러운 동반자입니다.
사고방식의 전환
프롬프트 엔지니어링은 묻습니다: "나는 무엇을 말해야 하나?" 컨텍스트 엔지니어링은 묻습니다: "모델이 무엇을 봐야 하고, 어떤 순서로 봐야 하며, 나는 무엇을 의도적으로 빼두어야 하나?"
두 번째 질문이 더 어렵지만, 대규모에서 품질을 실제로 결정하는 것은 그쪽입니다.