프롬프트를 바꿔가며 테스트해도 AI가 같은 실수를 반복한다면, 문제는 프롬프트에 없을 수 있어요.
Shopify CEO Tobi Lutke가 2025년 6월 X에 올린 한 문장이 AI 개발자 사이에서 빠르게 퍼졌어요. "컨텍스트 엔지니어링이 더 정확한 이름이다. 이 기술의 본질은 AI가 문제를 풀 수 있도록 모든 맥락을 설계하는 것이기 때문이다." 82%의 IT·데이터 리더가 "프롬프트 엔지니어링만으로는 충분하지 않다"고 답한 배경이기도 해요.
프롬프트가 완벽해도 AI가 틀리는 4가지 이유
프롬프트 엔지니어링은 "AI에게 무엇을 어떻게 말할지" 최적화하는 기술이에요. 2023~2024년엔 이게 핵심 기술처럼 보였죠. 근데 AI를 실전 시스템에 붙여보면 프롬프트만으로는 막히는 순간이 생겨요. 단순한 챗봇이 아니라 복잡한 워크플로우, RAG, 에이전트를 쓸 때 특히요.
Firecrawl과 DataCamp 연구는 이 실패를 4가지 패턴으로 정리했어요:
| 실패 모드 | 증상 | 실제 사례 |
|---|---|---|
| 오염 (Poisoning) | 한 번 틀린 사실이 이후 답변에 계속 영향 | 잘못된 날짜를 한 번 언급하면 이후 추론도 그 날짜 기반으로 꼬임 |
| 혼선 (Distraction) | 대화가 길어질수록 AI가 초반 지시를 무시 | 10번 주고받은 뒤 처음에 설정한 역할 페르소나를 잊어버림 |
| 혼란 (Confusion) | 관련 없는 문서 포함 시 엉뚱한 응답 | 50페이지 문서 통째로 넣으면 가운데 핵심 내용을 못 집어냄 |
| 충돌 (Clash) | 모순된 정보가 같은 창에 있을 때 성능 급락 | OpenAI o3가 98.1%에서 64.1%로 하락 |
컨텍스트 충돌은 평균 성능 39% 저하로 이어졌어요. Databricks 분석에 따르면 Llama 3.1 405B 같은 대형 모델도 32,000 토큰 언저리부터 정확도가 떨어지기 시작했고요. 100만 토큰 창이 있어도 전부 잘 처리하지 못한다는 거예요. Stanford의 "lost in the middle" 연구도 같은 결론이에요 — AI는 컨텍스트의 시작과 끝은 잘 기억하지만, 가운데에 있는 건 놓쳐요.
컨텍스트 엔지니어링, 뭐가 다른 건데?
Anthropic은 이걸 "LLM 추론 시 최적의 토큰 집합을 선별하고 유지하는 전략의 총체"라고 정의해요. 쉽게 말하면, 프롬프트 엔지니어링이 "무엇을 말할지"라면 컨텍스트 엔지니어링은 "AI가 무엇을 보게 할지 설계하는 것"이에요.
의사에게 진단을 받는다고 생각해봐요. "두통이에요"라고만 말하는 것과, 최근 복용 약물·수면 패턴·스트레스·과거 병력을 함께 제공하는 건 결과가 완전히 달라요. 프롬프트 엔지니어링이 "두통이에요"를 더 정확히 표현하는 것이라면, 컨텍스트 엔지니어링은 의사가 정확한 진단을 내리기 위해 필요한 모든 배경 정보를 설계하는 거예요.
| 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 | |
|---|---|---|
| 핵심 질문 | 어떻게 말해야 할까? | AI가 무엇을 알아야 할까? |
| 범위 | 단일 입력-출력 최적화 | AI가 보는 모든 정보 설계 |
| 잘 맞는 상황 | 단순 챗봇, 일회성 작업 | 에이전트, RAG, 복잡한 워크플로우 |
| 실패 원인 | 지시가 모호하거나 불명확 | 정보 아키텍처 문제 |
프롬프트 엔지니어링이 쓸모없어진 게 아니에요. 컨텍스트 엔지니어링이 프롬프트를 포함한 상위 개념이에요. 단, AI를 단순 대화 이상으로 쓰기 시작하면 — 복잡한 에이전트, RAG, 코파일럿 — 컨텍스트 아키텍처가 결과를 결정해요.
바로 적용하는 5가지 컨텍스트 기법
Anthropic·Firecrawl·DataCamp 연구를 바탕으로 효과가 검증된 5가지를 정리했어요. 개발 경험 없어도 오늘 바로 적용 가능한 것들이에요.
- 핵심 정보는 처음과 끝에 배치하기
Stanford의 "lost in the middle" 연구에 따르면 AI는 컨텍스트의 시작과 끝 부분을 가장 잘 처리해요. 시스템 프롬프트에서 가장 중요한 규칙은 첫 섹션에, 사용자 쿼리는 맨 마지막에 배치하세요. 핵심 참고 문서나 데이터는 쿼리 바로 앞에 두는 게 가장 효과적이에요. - 덜 넣을수록 잘한다 — 최소 유효 컨텍스트
Firecrawl이 "Minimum Viable Context(MVC)"라고 부르는 원칙이에요. 문서 전체 대신 쿼리와 관련된 섹션만 추출해서 넣어요. 도구 46개를 모두 연결하는 것보다 관련된 19~30개만 선택했을 때 도구 선택 정확도가 300% 향상됐다는 실험 결과가 있어요. - 변하지 않는 정보는 캐싱하기
같은 시스템 프롬프트, DB 스키마, 정책 문서를 매번 새로 넘기면 토큰 낭비예요. Claude와 Gemini의 컨텍스트 캐싱 기능을 쓰면 반복 컨텍스트 블록에서 비용을 75~90% 절약할 수 있어요. 바뀌지 않는 내용은 앞에, 매번 달라지는 내용은 뒤에 두어야 캐싱 효율이 극대화돼요. - 긴 대화는 잘라내지 말고 요약하기 (Compaction)
대화가 컨텍스트 한계에 가까워지면, 내용을 삭제하는 게 아니라 요약해서 초기화해야 해요. 보존할 것: 중요한 결정, 미해결 문제, 핵심 선택. 버려도 되는 것: 중간 시도, 반복 확인, 실패한 실험. Anthropic은 처음엔 기억 우선으로 요약하다가, 불필요한 내용을 걷어내는 방향으로 정밀화하길 권장해요. - 서브에이전트로 컨텍스트 분리하기
복잡한 작업은 하나의 AI에게 전부 맡기지 말고, 작업별 전문 서브에이전트를 구성해요. 각 에이전트는 깨끗한 컨텍스트 창을 갖고, 결과만 압축해서 메인 에이전트에 전달해요 (보통 1,000~2,000 토큰). 이 방식으로 특화 에이전트 벤치마크에서 54% 성능 향상을 보인 사례도 있어요.
지금 바로 해볼 수 있는 것
Claude나 ChatGPT로 긴 작업을 할 때, 시스템 프롬프트 첫 섹션에 "절대 바뀌지 않는 규칙"만 명확히 적고, 문서는 전체 대신 관련 부분만 발췌해서 넣어보세요. 프롬프트를 바꾸지 않아도 답변 품질이 달라질 거예요.
