본문으로 건너뛰기
중급

컨텍스트 엔지니어링

프롬프트 엔지니어링은 당신이 선택하는 단어에 관한 것입니다. 컨텍스트 엔지니어링은 당신이 모델에게 건네는 작업 공간에 관한 것입니다 — 그 안에 무엇이 들어 있는지, 어떤 순서로 되어 있는지, 그리고 무엇을 의도적으로 빼두었는지.

이 구분이 중요한 이유는 컨텍스트 윈도우가 메모장이 아니기 때문입니다. 그것은 제한적이고, 비싸며, 주의력을 요하는 자원입니다. 그것을 어떻게 채우느냐가 모델이 무엇에 집중하는지, 비용이 얼마나 드는지, 그리고 세션이 길어질수록 유용함을 유지하는지를 바꿉니다.

What you'll learn
  • 컨텍스트 엔지니어링을 프롬프트 엔지니어링과 구별하고, 이 분야가 왜 옮겨갔는지 이해하기
  • 컨텍스트 윈도우를 저장 공간이 아니라 주의력 예산으로 다루기
  • 긴 세션을 망치기 전에 컨텍스트 로트와 '중간에서 길을 잃는' 현상을 알아차리기
  • 주의력이 실제로 닿는 곳에 지시를 배치하기 — 맨 위, 맨 끝, 절대 중간에 파묻지 않기
  • 세 가지 핵심 전술을 적용하기: 압축, 노트 작성, 적시 검색

컨텍스트 예산​

모든 모델에는 최대 컨텍스트 크기가 있습니다 — 토큰으로 측정되는 단단한 상한선입니다. 이것을 예산이라고 생각하세요. 당신은 다음에 그것을 씁니다:

  • 시스템 프롬프트와 상시 지시
  • 검색된 문서, 코드베이스 조각, 도구 정의
  • 대화 기록
  • 모델의 출력 (멀티턴 세션에서는 이것 또한 윈도우에서 차감됩니다)

다 써버리면 무언가를 포기해야 합니다. 오래된 내용이 버려지거나, 세션이 벽에 부딪힙니다.

대부분의 입문 가이드는 컨텍스트 윈도우를 "많을수록 좋다"고 다룹니다. 컨텍스트 엔지니어링은 그것을 신중하게 배분해야 할 자원으로 다룹니다: 이번 턴에 모델이 실제로 필요로 하는 것에 쓰되, 관련될 수도 있는 모든 것에 쓰지 마세요. Anthropic은 이 분야 전체를 "가능한 한 가장 작은 고신호 토큰 집합"을 찾는 일로 규정합니다 — 당신이 추가하는 모든 토큰은 유한한 주의력 예산을 두고 경쟁하며, 이는 트랜스포머가 모든 토큰을 다른 모든 토큰과 연관시키는 방식의 직접적인 결과입니다.

컨텍스트 로트와 "중간에서 길을 잃는" 현상​

긴 컨텍스트 LLM에는 잘 기록된 현상이 있습니다: 모델은 컨텍스트의 시작과 끝 부근의 내용에 불균형하게 큰 주의를 기울이며, 중간에 파묻힌 내용에 대한 회상은 저하됩니다. 이 효과를 연구한 연구자들은 이를 "중간에서 길을 잃는다(lost in the middle)"고 불렀습니다.

실용적인 결과는 이렇습니다: 10만 토큰짜리 컨텍스트를 문서로 가득 채우고 가장 중요한 지시를 6만 번째 위치에 파묻으면, 모델은 그것을 사실상 무시할 수 있습니다 — 그렇게 멀리까지 읽을 수 없어서가 아니라, 주의력이 윈도우 전체에 고르게 분포되지 않기 때문입니다.

"컨텍스트 로트"는 더 넓은 패턴입니다: 세션이 길어질수록 응답의 품질이 떠밀려 흐트러지는 경향이 있습니다. 초기 지시는 희석됩니다. 반복되는 주고받음이 원래 과제를 밀어냅니다. 모델은 얼버무리거나, 같은 말을 반복하거나, 당신이 실제로 요청한 것의 맥락을 놓치기 시작합니다.

이것들은 더 나은 프롬프트로 완전히 고칠 수 있는 버그가 아닙니다. 그것들은 주의력이 대규모에서 작동하는 방식의 구조적 속성입니다. 엔지니어링적 대응은 컨텍스트를 채우고 잘되기를 바라는 것이 아니라, 더 작고 날카롭게 유지하는 것입니다.

순서가 중요하다​

내용을 어디에 배치하느냐는 무엇을 포함하느냐만큼 중요합니다. 확립된 모범 사례:

위치그곳에 넣을 것
맨 위 (시스템 프롬프트)안정적이고 지속적인 지시. 페르소나, 규칙, 형식 요구사항.
시스템 프롬프트 뒤현재 과제를, 쉬운 말로.
마지막 사용자 턴 직전이 정확한 요청을 위한 가장 중요하고 구체적인 컨텍스트.
중간보조 문서, 검색된 청크 — 시간 순서가 아니라 관련성 순으로 정렬.
대화 기록연속성에 필요한 것만. 적극적으로 가지치기하세요.

일반 규칙: 현재 턴에 가까울수록 더 많은 주의를 받습니다. 긴 기록의 중간에만 존재하는 중요한 지시는 위험에 처합니다.

지시를 위한 "적절한 고도"​

시스템 프롬프트는 정반대의 두 가지 방식으로 실패할 수 있습니다. 너무 낮으면 현실이 달라지는 순간 깨지는 부서지기 쉬운 if-this-then-that 로직을 하드코딩하게 됩니다. 너무 높으면 모델이 갖고 있지 않은 컨텍스트를 가정하는 모호한 지침을 쓰게 됩니다. Anthropic은 그 목표 지점을 **"적절한 고도(right altitude)"**라고 부릅니다 — "행동을 효과적으로 안내할 만큼 충분히 구체적이면서도, 강력한 휴리스틱을 제공할 만큼 충분히 유연한" 골디락스 영역입니다. 그곳을 겨냥하세요: 결정 트리가 아니라, 그리고 분위기가 아니라, 구체적인 규칙과 예시.

욱여넣기보다 검색​

모든 것을 넣고 싶은 유혹이 있습니다: 모든 문서, 전체 코드베이스, 전체 대화. 저항하세요.

더 나은 접근법은 선택적 검색입니다: 모델이 이 특정 요청을 위해 실제로 필요로 하는 것을 식별하고, 오직 그것만 주입하세요. 잘 검색된 2,000 토큰짜리 올바른 문서 조각이, 답이 중간 어딘가에 있는 4만 토큰짜리 덤프를 능가합니다.

이것이 검색 증강 생성(RAG)이 존재하는 이유입니다 — 단지 컨텍스트 한계를 극복하기 위해서가 아니라, 컨텍스트를 엄선된 상태로 유지함으로써 품질을 개선하기 위해서입니다. 에이전트 버전은 **적시 검색(just-in-time retrieval)**입니다: 모든 문서를 미리 로드하는 대신, 에이전트는 가벼운 식별자(파일 경로, ID, 쿼리)를 들고 있다가 실제 내용을 필요한 순간에만 컨텍스트로 끌어옵니다.

대화형 세션에도 같은 논리가 적용됩니다: 모든 것을 쌓아두는 대신, 현재 과제와 더 이상 관련 없는 내용을 제거하기 위해 주기적으로 기록을 압축하거나 비우세요. Claude Code의 /compact와 /clear 명령은 단순한 세션 관리가 아니라 컨텍스트 엔지니어링 도구입니다. API에서는 같은 패턴이 메모리 및 컨텍스트 편집으로 자동화됩니다 — 오래된 도구 결과는 윈도우에서 가지치기되는 한편, 중요한 것은 영속적인 메모리 저장소에 기록됩니다.

세 가지 핵심 전술​

장기적인 작업에서는 세 가지 기법이 대부분의 무거운 짐을 떠맡습니다. 그것들은 조합됩니다 — 대부분의 실제 에이전트는 셋 모두를 사용합니다.

Guided walkthrough1 of 3
  1. 세션이 윈도우 한계에 가까워지면, 그것을 요약하고 증류된 버전으로 다시 초기화하세요. 핵심을 떠받치는 세부사항 — 아키텍처 결정, 미해결 버그, 핵심 구현 선택 — 을 보존하고, 시시콜콜한 경과 기록은 버리세요. 이것이 Claude Code에서 /compact가 하는 일입니다.

비용의 측면​

당신이 보내는 토큰은 당신이 지불하는 토큰입니다 — 돈과 지연 시간 양쪽 모두에서. 느슨하게 관련된 자료로 컨텍스트를 욱여넣으면 둘 다 부풀어 오릅니다. 컨텍스트 엔지니어링과 비용 효율성은 같은 문제입니다.

좀 더 구체적으로:

  • 템플릿에서 복사-붙여넣기한 비대한 시스템 프롬프트는 모든 호출마다 비용이 청구됩니다.
  • "유용할지도 모른다"는 이유로 끌고 가는 오래된 대화 기록은 모든 호출마다 비용이 청구됩니다.
  • "혹시 몰라서" 주입하는 문서는 모든 호출마다 비용이 청구됩니다.

거기 있을 필요 없는 것을 잘라내는 일은 품질에도 더 좋고 운영 비용도 더 싼, 동시에 이루어지는 일입니다.

Claude 사용자를 위한 실용적 전술​

Claude.ai에서:

  • 서로 다른 과제에는 서로 다른 대화를 사용하세요. 오후 내내 이어진 곁가지들이 집중된 프로젝트의 컨텍스트를 오염시키지 않게 하세요.
  • 그것들에 의존하는 복잡한 질문을 하기 전에 긴 스레드를 요약하세요. 명시적인 요약이 원본 기록보다 더 유용한 경우가 많습니다.
  • 긴 메시지에서 당신이 원하는 구체적인 것을 중간에 파묻지 말고 맨 끝에 두세요.

Claude Code에서:

  • CLAUDE.md 파일을 군더더기 없이 유지하세요. 그 안의 모든 줄은 모든 세션에 주입됩니다. CLAUDE.md와 컨텍스트 관리를 참고하세요.
  • 진정으로 다른 과제로 전환할 때는 /clear를 사용하세요. 계속하고 싶지만 세션이 커지고 있을 때는 /compact를 사용하세요.
  • 현재 단계에 전체 파일이 필요하지 않을 때는 내용을 붙여넣기보다 경로로 파일을 참조하세요.

API 수준에서:

  • 시스템 프롬프트가 모든 요청이 진정으로 필요로 하는 것만 담도록 설계하세요. 과제별 지시는 사용자 턴으로 옮기세요.
  • 문서 중심의 사용 사례에서는 전체 말뭉치를 업로드하기보다 관련 청크를 검색해 주입하세요.
  • 안정적이고 재사용 가능한 접두부가 먼저 오도록 프롬프트를 구성하세요 — 이는 또한 프롬프트 캐싱을 가능하게 하는데, 이는 컨텍스트 엔지니어링의 자연스러운 동반자입니다.

긴 문서를 Claude에게 건네고 싶을 때, 배치 규칙은 매번 순수한 분량을 이깁니다:

지시는 처음에, 다시 한 번 끝에

과제: 이 계약서에서 우리의 책임을 제한하는 모든 조항을 찾아, 각각을 조항 번호와 함께 그대로 인용하세요.

[... 여기에 40페이지짜리 전체 계약서를 붙여넣으세요 ...]

과제 상기: 위의 모든 책임 제한 조항을, 정확히 인용하여, 조항 번호와 함께 나열하세요. 하나도 없다면 그렇다고 명시적으로 말하세요.

같은 지시가 맨 위에 그리고 맨 아래에 자리합니다 — 주의력이 선호하는 두 위치 — 그래서 그것은 아주 긴 중간조차 견뎌냅니다.

사고방식의 전환​

프롬프트 엔지니어링은 묻습니다: "나는 무엇을 말해야 하는가?" 컨텍스트 엔지니어링은 묻습니다: "모델이 무엇을, 어떤 순서로 보아야 하는가, 그리고 나는 무엇을 의도적으로 빼두어야 하는가?"

두 번째 질문이 더 어렵지만, 대규모에서 품질을 실제로 결정하는 질문입니다.

Check yourself

0/3
  1. 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 핵심 차이는 무엇인가요?
  2. 10만 토큰짜리 컨텍스트의 6만 번째 토큰에 가장 중요한 단 하나의 지시를 파묻습니다. 가능성 높은 결과는 무엇인가요?
  3. 코딩 에이전트가 긴 과제에서 컨텍스트를 막 다 써가려 합니다. 어떤 전술이 진행 상황을 가장 잘 보존하나요?
어휘를 단단히 익히기
Enter 또는 스페이스 키를 눌러 카드를 뒤집습니다. 좌우 화살표 키로 카드를 이동할 수 있습니다.용어가 표시되었습니다.
1 / 6
Key takeaways
  • 컨텍스트 윈도우는 저장 공간이 아니라 주의력 예산이다 — 고신호 토큰에만 쓰세요.
  • 위치가 분량을 이긴다: 중요한 지시는 맨 위와 마지막 턴 직전에 두고, 절대 중간에 파묻지 마세요.
  • 압축, 노트 작성, 적시 검색은 긴 에이전트를 일관되게 유지하는 세 가지 전술이다.
  • 컨텍스트를 엄선하는 것은 비용을 줄이는 것과 같은 지렛대다 — 더 적은 토큰, 더 나은 답, 더 낮은 청구서.

관련 문서​