컨텍스트 엔지니어링: 그것이 무엇이며 더 나은 AI 에이전트를 구축하기 위해 어떻게 사용하는가

목차

2026년 7월 게시.

TL;DR: 프롬프트 엔지니어링은 단어 선택에 관한 것이고, 컨텍스트 엔지니어링은 정보 아키텍처에 관한 것입니다. 유한한 컨텍스트 윈도우가 있고 모든 토큰은 트레이드오프입니다. 에이전트 컨텍스트를 네 가지 레이어로 구성하며, 윈도우를 예산으로 취급하는 것이 모델을 전환하는 것보다 신뢰성을 더 향상시켰습니다.

[운영자 노트] 30개 이상의 에이전트를 프로덕션에서 운영하고 있습니다. 지난해 가장 큰 차이를 만든 개선은 더 나은 모델도, 더 정교한 프레임워크도 아닙니다——컨텍스트 윈도우에 무엇이 들어가고 무엇이 남는지에 대해 더 의식적이 되는 것입니다. 컨텍스트 엔지니어링은 이제 에이전트 작업을 평가할 때 제가 찾는 핵심 기술입니다.

대부분의 사람들은 여전히 AI와 작업하기 위한 중요한 기술로 “프롬프트 엔지니어링”에 대해 이야기합니다. 프롬프트 엔지니어링은 실재하고 중요합니다. 하지만 그것은 더 큰 학문의 하위 집합입니다——그것을 전체 작업으로 취급하는 것이 데모에서는 좋아 보이지만 프로덕션에서 실패하는 많은 에이전트가 있는 이유입니다.

”프롬프트 엔지니어링”이 잘못된 프레임이 된 이유

“프롬프트 엔지니어링”은 핵심 레버가 시스템 프롬프트나 사용자 메시지에 쓰는 텍스트임을 암시합니다. 올바른 지침, 올바른 단어, 올바른 형식을 만드는 데 충분한 시간을 쏟으면 모델이 필요한 것을 해줄 것이다.

이것은 어느 정도까지는 사실입니다. 잘 작성된 시스템 프롬프트는 필요합니다. 하지만 모델의 동작은 컨텍스트 윈도우에 있는 모든 것에 의해 결정됩니다——시스템 프롬프트만이 아닙니다. 다음에 의해 형성됩니다:

• 대화 기록 (이전 턴에서 무슨 일이 있었는지)
• 검색하여 주입한 문서나 데이터
• 모델이 지금까지 본 도구 호출 결과
• 각 정보의 토큰 수와 위치

프롬프트 단어 선택만 생각하고 컨텍스트 윈도우를 채우는 나머지를 무시한다면, 하나의 입력을 최적화하면서 다른 것들을 관리되지 않은 상태로 남겨두는 것입니다. 그래서 “컨텍스트 엔지니어링”이 진지한 에이전트 작업을 위한 더 정확한 프레임입니다.

컨텍스트 엔지니어링이 실제로 무엇인가

컨텍스트 엔지니어링은 어떤 정보가 모델의 컨텍스트 윈도우에 들어가는지, 어떤 순서로, 대화의 어느 시점에 결정하는 학문입니다.

컨텍스트 윈도우는 모델의 작업 메모리입니다. 유한합니다. 안에 넣는 모든 토큰은 다른 것을 밀어냅니다——또는 비용을 증가시킵니다. 그리고 인간의 작업 메모리와 달리, 모델은 윈도우 외부에서 무언가를 “찾아볼” 방법이 없습니다 (그렇게 할 도구를 주지 않는 한). 보이는 것이 전부입니다.

컨텍스트 엔지니어링은 그 윈도우를 의도적으로 관리되는 리소스로 취급하는 실천입니다:

• 이 단계를 완료하기 위해 모델이 무엇을 알아야 하는가?
• 이전 단계에서 알아야 했지만 더 이상 필요하지 않은 것은 무엇인가?
• 실행 전반에서 안정적인 것과 요청별로 동적인 것은 무엇인가?
• 윈도우의 어디에 각 정보가 나타나야 하는가?

이것들은 프롬프트 단어 선택에 관한 질문이 아닙니다. 정보 아키텍처 질문입니다. 그리고 답변은 모델 선택과 마찬가지로 에이전트 신뢰성을 좌우합니다.

내가 설계하는 네 가지 레이어

내가 구축하는 모든 에이전트에는 네 가지 별개의 컨텍스트 레이어가 있습니다. 각각을 별도로 생각합니다.

레이어 1: 시스템 프롬프트

이것은 안정적이고 턴 독립적인 기반입니다. 에이전트가 누구인지, 무엇을 할 수 있는지, 무엇을 할 수 없는지, 엣지 케이스를 어떻게 처리해야 하는지를 정의합니다.

대부분의 사람들이 여기서 하는 실수는 시스템 프롬프트를 한 번 작성하고 완성된 것으로 취급하는 것입니다. 실제로 시스템 프롬프트는 세 가지 질문에 명시적으로 답해야 합니다:

1. 이 에이전트는 무엇을 위한 것인가? (모델에게는 막연한 임무가 아닌 정확한 범위가 필요합니다.)
2. 입력이 모호하거나 불완전할 때 어떻게 해야 하는가?
3. 절대 해서는 안 되는 것은 무엇인가? (부정적 제약이 중요합니다.)

시스템 프롬프트를 최소화하세요. 불필요한 문장은 실제 추론이 일어나는 동적 콘텐츠와 경쟁하는 오버헤드입니다.

실용적인 팁: API와 함께 Claude를 사용하고 있다면, 시스템 프롬프트에 cache_control을 사용하세요. 캐시된 크고 안정적인 시스템 프롬프트는 턴당 캐시되지 않은 것의 약 10% 비용이 듭니다.

레이어 2: 대화 기록

멀티 턴 에이전트에서 대화 기록은 동적이며 매 턴마다 증가합니다. 관리 없이는 컨텍스트 인플레이션의 가장 큰 원인이 됩니다.

문제: 초기 턴에는 모델이 더 이상 필요로 하지 않는 정보가 포함되어 있습니다. 모든 것을 유지하는 것은 토큰을 낭비하고, 오래된 컨텍스트에서 추론하게 하여 모델을 혼란스럽게 할 수 있습니다.

내가 하는 것:

• 기록이 임계값을 초과하면 이전 턴을 자르거나 요약한다.
• 여전히 관련 있는 도구 호출 결과만 유지한다.
• 장기 실행 에이전트에서 기록이 무한정 증가하지 않도록 한다.

레이어 3: 검색된 콘텐츠

이것이 평범한 에이전트와 좋은 에이전트를 구분하는 레이어입니다. 대부분의 에이전트는 런타임에 외부 데이터를 가져와야 합니다.

내가 적용하는 두 가지 원칙:

현재 단계에 관련 있는 것만 검색한다. 현재 단계가 한 섹션만 필요할 때 50페이지 문서를 주입하지 마세요.

위치가 중요합니다. 컨텍스트의 시작과 끝에 있는 정보는 중간에 있는 정보보다 더 높은 가중치를 받습니다. 모델이 반드시 사용해야 하는 검색된 콘텐츠가 있다면, 긴 주입의 중간에 묻지 마세요.

레이어 4: 도구 출력

에이전트 루프에서 모델은 도구를 호출하고 결과를 받습니다. 그 결과들이 누적됩니다. 그리고 대화 기록과 달리, 사람들은 그것들을 관리하는 것에 대해 거의 생각하지 않습니다.

해결책은 같습니다: 도구 결과가 그 목적을 달성했다면, 윈도우에 유지할 필요가 없습니다. 멀티 스텝 에이전트에서 이전 각 단계의 원시 출력 대신 “지금까지 확립한 것”의 구조화된 요약을 앞으로 전달합니다.

컨텍스트 예산: 무엇을 포함하고 무엇을 삭제할 것인가

간단한 멘탈 모델을 사용합니다: 컨텍스트 윈도우는 예산이고 모든 토큰은 지출입니다. 각 에이전트 턴 전에 묻습니다:

• 이 단계를 수행하기 위해 모델이 지금 무엇을 알아야 하는가?
• 중요한 것을 잃지 않고 무엇을 생략하거나 요약할 수 있는가?
• 레이어 간에 중복된 것은 무엇인가?

목표는 포괄적인 것이 아니라 각 단계에서 가능한 가장 높은 신호 정보로 윈도우를 채우는 것입니다.

프로덕션에서 내가 한 세 가지 컨텍스트 엔지니어링 실수

1. 안정된 접두사에서 부동 타임스탬프. 시스템 프롬프트 상단에 현재 날짜: {{날짜}}를 두었습니다. 그 문자열은 매일 바뀌어, 매 24시간마다 프롬프트 캐시를 조용히 무효화했습니다. 타임스탬프, 사용자 ID 같은 휘발성 정보를 안정된 접두사 뒤의 컨텍스트 끝으로 이동하세요.

2. 도구 출력을 추가 전용으로 취급하기. 각 도구 호출 결과가 컨텍스트에 남아있는 에이전트 루프를 실행했습니다. 8번째 턴에서 모델은 80%가 오래된 도구 출력으로 구성된 컨텍스트에서 추론하고 있었습니다.

3. 컨텍스트 변경 시 평가 건너뛰기. 컨텍스트 변경은 모델 동작 변경입니다. 이제 프롬프트 변경에 사용하는 것과 동일한 평가 하네스를 컨텍스트 변경에도 실행합니다.

실제로 내 컨텍스트 엔지니어링 워크플로우

에이전트 코드 한 줄을 쓰기 전에, 컨텍스트 레이어를 스케치합니다:

시스템 프롬프트:     ~500 토큰, 안정적, 캐시됨
기록 예산:           ~2000 토큰 최대, 각 단계 후 요약
검색된 컨텍스트:     단계당 ~1000-3000 토큰, 관련 청크만
출력 예산:           현재 단계만, 앞으로 요약하여 전달

모델 선택 질문은 그 다음입니다. 어떤 컨텍스트 엔지니어링이 필요한지 알게 되면, 올바른 컨텍스트 구성으로 신뢰성 기준을 유지하는 가장 저렴한 모델을 선택합니다.

FAQ

프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이는 무엇입니까?

프롬프트 엔지니어링은 시스템 프롬프트와 사용자 메시지의 단어 선택에 집중합니다. 컨텍스트 엔지니어링은 더 넓은 학문입니다: 전체 컨텍스트 윈도우 (대화 기록, 검색된 데이터, 도구 출력 포함)에 어떤 정보가 들어가는지, 어떤 순서로, 어떤 토큰 비용으로 결정하는 것입니다.

시스템 프롬프트는 얼마나 커야 합니까?

구체적이면서 가능한 한 작아야 합니다. 대부분의 에이전트에서 800 토큰 미만을 목표로 합니다. 모든 시나리오를 예상하려는 시스템 프롬프트는 결국 모델이 신뢰성 있게 읽기에 너무 길어집니다.

컨텍스트 엔지니어링이 일부 모델에서 다른 모델보다 더 중요합니까?

모든 모델에 중요하지만, 더 작은 모델에서 위험이 더 높습니다. 큰 프런티어 모델은 때로 잘못 구조화된 컨텍스트에서 회복할 수 있습니다; 더 빡빡한 예산을 가진 작은 모델은 그럴 수 없습니다.

컨텍스트 엔지니어링이 작동하는지 어떻게 알 수 있습니까?

신뢰성 변경에 추적할 것과 동일한 지표를 추적하세요: 평가 세트의 성공률, 성공적인 결과당 비용, 단계별 오류 분포.

항상 기록을 압축하거나 요약해야 합니까?

짧은 트랜잭션 에이전트의 경우: 아니요. 5-6회 이상의 교환을 실행하는 멀티 턴 에이전트의 경우: 예, 항상. 내가 사용하는 경험 법칙——기록 예산이 총 컨텍스트 예산의 30%를 초과하면 요약을 시작합니다.