Context Engineering vs Prompt Engineering for AI Agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

컨텍스트 엔지니어링은 프롬프트 작성을 넘어 매 LLM 호출의 정보·기억·도구·형식을 선별하고 관리해, 긴 컨텍스트와 누적 오류로 인한 에이전트 성능 저하를 줄이는 운영 체계다.

📌 핵심 요약

• 컨텍스트 엔지니어링은 매 LLM 호출 전에 필요한 정보와 도구를 적절한 형식과 시점에 제공하는 동적 시스템을 설계·모니터링·유지하는 분야이며, 프롬프트 엔지니어링을 포함한다.
• Stanford의 'lost in the middle' 연구는 긴 입력에서 핵심 정보의 위치가 성능에 영향을 준다고 보고했다. 2025년 7월 Chroma Research의 18개 LLM 연구는 입력 길이에 따른 성능 불안정성을, Databricks 연구는 Llama 3.1 405b에서 약 32,000토큰부터 정확도가 떨어지는 현상을 제시했다.
• Gemini 2.5의 Pokémon 에이전트는 컨텍스트가 100k토큰을 크게 넘으면 과거 행동을 반복하는 경향을 보였다. 별도의 다중 턴 연구에서는 정보를 여러 대화 턴으로 나누자 테스트한 모델 전체에서 평균 39%의 성능 하락이 나타났다.
• 원문은 컨텍스트 실패를 오류가 누적되는 오염, 과거 이력에 치우치는 주의 분산, 불필요한 정보·도구가 개입하는 혼란, 정보 간 충돌로 구분한다. 대응책으로 검증·격리, 요약, RAG 기반 도구 선별, 오래되거나 충돌하는 정보의 제거·외부 분리를 제시한다.
• 실무 기법은 명시적 제약을 담은 프롬프트 명세, JSON 스키마, 최소한의 고신호 정보 선별이다. Firecrawl은 실시간 웹 데이터 수단으로 소개되며, 선택 기능인 checkPromptInjection은 숨은 지시를 검사하고 탐지 시 HTTP 403으로 요청을 차단한다고 설명된다.

🧩 주요 포인트

1. 관리 범위가 단일 지시문에서 기억·검색·도구·대화 이력 전체로 확대됨 → 운영 중 품질 문제도 전체 컨텍스트와 토큰 흐름을 살펴야 함.
2. 정보 위치·입력 길이·대화 누적에 따라 성능이 저하됨 → 큰 컨텍스트 창보다 필요한 정보의 최소화와 배치가 중요함.
3. 오염·주의 분산·혼란·충돌은 발생 원인이 다름 → 검증, 요약, 도구 선별, 정보 제거를 실패 유형에 맞게 적용해야 함.

🧠 상세 정리

1. 컨텍스트 계층 구축 이후의 운영 문제

Rafael Miller는 AI 에이전트의 Context Layer를 구축했더라도 아키텍처 문제만 해결했을 뿐, 실제 과제는 그 시스템을 운영하는 데 있다고 설명한다. 필요한 정보를 모두 제공했다고 생각하는 상황에서도 환각이 발생할 수 있으며, 컨텍스트가 실제로 좋은지 측정하고 실패 원인을 추적하는 일이 남는다. 지식 기반이 100개 문서에서 100,000개 문서로 커질 때 품질을 어떻게 유지할지도 같은 운영 문제에 속한다. 원문은 이를 프로덕션 AI 시스템의 컨텍스트 파이프라인을 설계·모니터링·유지하는 컨텍스트 엔지니어링으로 정의하고, DevOps와 MLOps에 비유한다. Shopify CEO Tobi Lutke의 설명처럼 목표는 LLM이 과제를 해결할 수 있을 만큼 충분한 맥락을 제공하는 것이며, 필요한 정보와 도구를 적절한 형식과 시점에 조립하는 동적 시스템이 핵심이다.

2. 프롬프트 작성에서 정보 환경 설계로

프롬프트 엔지니어링은 특정 작업을 위한 지시문을 작성하는 활동이고, 컨텍스트 엔지니어링은 그 지시문을 포함해 모델이 무엇을 보게 할지 결정하는 활동이다. 원문은 이에 따라 프롬프트 엔지니어링을 컨텍스트 엔지니어링의 하위 집합으로 구분한다. 관리 대상에는 시스템 프롬프트, 사용자 요청, 대화 이력, 장기 기억, 검색된 문서·데이터베이스·API 응답, 도구 정의, 구조화된 출력 형식이 모두 포함된다. 따라서 관심도 '무엇이라고 말할까'에서 '모델이 무엇을 알아야 할까'로 확장되고, 디버깅 역시 문구 수정에서 전체 컨텍스트·토큰 흐름·기억 점검으로 옮겨간다. 훌륭한 프롬프트라도 관련 없는 대화 이력 6K토큰이나 형식이 나쁜 검색 문서에 묻히면 효과를 잃을 수 있다는 예시는, 첫 번째 좋은 응답과 1,000번째까지 유지되는 품질의 차이를 설명한다.

3. 큰 컨텍스트 창의 한계와 정보 배치

원문은 Gemini의 200만 토큰 같은 큰 컨텍스트 창을 이유로 모든 정보를 넣으면 된다는 생각에 반대하며, 입력의 길이뿐 아니라 배치도 성능을 좌우한다고 주장한다. Stanford의 'lost in the middle' 연구에서는 관련 정보가 긴 입력의 중간에 있을 때 성능이 떨어지고, 시작이나 끝에 있을 때 더 좋은 성능을 보였다. 2025년 7월 Chroma Research는 Claude 4, GPT-4.1, Gemini 2.5, Qwen3 등을 포함한 18개 LLM을 시험해, 단순한 반복 단어 재현이나 검색 작업에서도 길이가 늘수록 성능이 불안정해진다고 보고했다. 이 연구에서는 질문과 정답 단서의 유사성이 낮을수록 성능이 더 빨리 저하됐으며, 방해 정보의 영향은 균일하지 않았고 논리적으로 정돈한 내용보다 섞인 내용이 더 좋은 결과를 내는 경우도 있었다. Databricks 연구는 Llama 3.1 405b의 정확도가 약 32,000토큰부터, 작은 모델은 그보다 이르게 떨어진다고 제시했다. 원문은 큰 창이 요약과 사실 검색에는 유용할 수 있지만, 다른 작업에서는 모델이 방해 정보에 취약해지는 한계를 경계해야 한다고 설명한다.

4. 대화 이력과 관련 정보도 성능을 떨어뜨릴 수 있음

Gemini 2.5 기술 보고서에 등장하는 Pokémon 에이전트는 컨텍스트가 100k토큰을 크게 넘자 새로운 계획을 세우기보다 방대한 이력 속 행동을 반복하는 경향을 보였다. 원문은 이 사례를 과거 기록의 누적이 새로운 전략 형성을 방해할 수 있다는 근거로 제시한다. 장문 컨텍스트 활용 연구에서는 관련 있는 정보라도 여러 위치에 흩어져 있으면 모델이 이를 종합하기 어려워, 추가 정보가 오히려 성능을 떨어뜨릴 수 있다고 설명한다. 별도의 다중 턴 연구는 벤치마크 요청에 필요한 정보를 여러 대화 턴으로 나눴을 때 최첨단 추론 모델을 포함한 테스트 모델 전체에서 평균 39%의 성능 하락이 나타났다고 보고했다. 원문이 제시하는 이유는 모델이 정보가 충분하지 않은 초기 단계에 만든 오답이 컨텍스트에 남아 이후 추론을 오염시킨다는 것이며, 따라서 최적의 입력은 모든 관련 정보가 아니라 주의를 집중할 수 있도록 구성한 최소한의 관련 정보라는 결론으로 이어진다.

5. 실패 유형 1·2: 오염과 주의 분산

원문은 Drew Breunig과 Gemini 팀의 연구를 바탕으로 컨텍스트 실패를 네 가지로 나누며, 먼저 오염은 환각이나 오류가 컨텍스트에 들어가 반복적으로 참조되는 현상이라고 설명한다. Gemini의 Pokémon 에이전트는 게임 상태를 잘못 이해한 내용을 목표 영역에 넣은 뒤, 달성할 수 없는 목표를 좇는 비합리적인 전략을 오랫동안 수행하기도 했다. 이에 대한 대응은 정보를 장기 기억에 넣기 전에 검증하고, 서로 다른 컨텍스트 유형을 별도 스레드로 격리하며, 오염을 발견하면 새 스레드에서 시작하는 것이다. 두 번째인 주의 분산은 컨텍스트가 커지면서 모델이 학습한 지식보다 누적 이력에 지나치게 집중해 과거 행동을 반복하는 현상이다. 원문은 중요한 세부사항을 보존하면서 중복 이력을 제거하는 짧은 요약을 해법으로 제시하며, 컨텍스트 압축은 이러한 목적을 수행한다고 설명한다.

6. 실패 유형 3·4: 불필요한 도구와 정보 충돌

세 번째 실패인 혼란은 작업과 관계없는 내용이 응답에 영향을 주는 현상이며, 원문은 Berkeley Function-Calling Leaderboard에서 도구가 하나를 넘으면 모든 모델의 성능이 낮아진다고 소개한다. 또 다른 연구에서는 양자화된 Llama 3.1 8b가 16k 컨텍스트 창 안에서도 도구 46개를 제공받으면 실패했지만, 19개만 제공받으면 성공했다. 대응책은 RAG로 도구 설명을 검색해 필요한 도구를 선별하는 것이며, 원문은 선택을 30개 미만으로 유지하는 방식이 도구 선택 정확도를 3배 높였다는 연구 결과를 제시한다. 네 번째인 충돌은 외부 MCP 도구 설명이 기존 프롬프트와 어긋나거나, 단계적으로 수집한 정보가 이전 가정과 직접 모순되는 경우다. 원문은 새로운 정보가 들어올 때 오래되거나 충돌하는 내용을 제거하고, Anthropic의 'think' 도구처럼 별도 작업 공간을 두어 주요 컨텍스트를 복잡하게 만들지 않고 정보를 처리하는 방식을 해법으로 소개한다.

7. 명시적 제약과 JSON 스키마를 통한 출력 통제

실무 기법으로 넘어가면서 원문은 Anthropic, Google, Claude Code 개발 팀 등의 프로덕션 경험을 바탕으로 자유 형식 텍스트보다 구조화된 프롬프트 명세를 권한다. 제공된 본문에서 구체적으로 제시된 항목은 예산 한도, 금지 행동, 문체 요구처럼 반드시 지켜야 하는 제약이다. 이러한 명세는 작성자가 예외 상황을 검토하도록 돕고, 모델에는 모호한 지시 대신 분명한 경계를 제공한다. 구조화된 데이터가 필요하다면 JSON 스키마를 먼저 정의해 모델이 필드명이나 형식을 임의로 바꾸면서 후속 코드를 깨뜨리는 일을 줄이라고 설명한다. Pydantic 예제의 ExtractedEntity는 name, type, confidence를 정의하고 confidence를 0 이상 1 이하로 제한하며, 원문은 이런 스키마가 단순한 파싱 편의를 넘어 모델의 출력 범위를 제한하고 환각을 줄이는 컨텍스트의 일부라고 주장한다.

8. 최소 정보 원칙과 웹 데이터의 최신성·보호

실무 설명의 핵심 원칙은 원하는 결과를 얻을 가능성을 최대화하는 최소한의 토큰 집합을 찾는 것으로, 원문은 컨텍스트에 들어갈 정보를 엄격하게 선별하고 데이터를 준비하는 일이 중요하다고 강조한다. 이는 앞서 제시한 길이 증가, 불필요한 도구, 누적 오류 문제를 정보 선택의 관점에서 묶는 방향이다. 글의 도입부 요약에서는 Firecrawl을 실시간 웹 데이터에 접근해 오래된 학습 지식에만 의존하지 않도록 돕는 수단으로 소개한다. 동시에 JSON 추출을 프롬프트 인젝션으로부터 보호하기 위한 선택 기능 checkPromptInjection이 수집한 페이지의 숨은 지시를 검사하고, 탐지 시 공격자가 통제하는 데이터를 반환하는 대신 HTTP 403으로 요청을 차단한다고 설명한다. 다만 제공된 본문은 문서 전체를 그대로 넣지 말라는 검색 관련 실무 항목 도중에 끊겨 있으므로, 목차에만 등장하는 다섯 가지 지시 스타일이나 컨텍스트 품질 측정법의 구체적인 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 컨텍스트 품질은 정보량만으로 판단하기 어렵다. 관련 정보도 위치와 분산 정도에 따라 활용을 방해할 수 있으므로, 선별과 배치가 함께 중요하다.
• 대화 이력과 장기 기억은 유용한 자원이면서 오류를 지속시키는 경로이기도 하다. 정보를 축적하는 기능과 검증·압축·제거하는 기능을 함께 다뤄야 한다.
• 도구 정의와 출력 스키마도 모델의 판단 환경을 구성한다. 필요한 도구만 제공하고 출력 제약을 명확히 하는 작업은 프롬프트 문구 개선과 연결된 시스템 설계다.

✅ 액션 아이템

• 매 LLM 호출의 기억·검색·도구·대화 이력을 살펴 필요한 정보의 최소화와 배치를 검토함.
• 오염·주의 분산·혼란·충돌을 구분하고 검증·격리, 요약, RAG 기반 도구 선별, 정보 제거를 원인에 맞게 적용함.
• 구조화된 출력에 JSON 스키마를 명시하고, Firecrawl 웹 데이터 사용 시 checkPromptInjection 적용을 검토함.

❓ 열린 질문

• 매 LLM 호출에 포함되는 기억·검색·도구·대화 이력에서 필요한 정보의 최소화와 배치를 어떤 기준으로 판단할 것인가?
• 에이전트의 성능 저하가 오염·주의 분산·혼란·충돌 중 어디에서 발생했는지 어떻게 구분할 수 있는가?
• JSON 스키마와 Firecrawl의 checkPromptInjection을 적용했을 때 출력 형식 준수와 숨은 지시 차단이 작동하는지 어떻게 확인할 것인가?