프롬프트를 열 번 고쳐도 에이전트가 계속 삐끗한다면, 사실 프롬프트 탓이 아닐 수 있어요.
2025년 6월, Andrej Karpathy가 X에 한 줄을 올렸다. "context engineering is the delicate art and science of filling the context window with just the right information." Shopify CEO Tobi Lutke도 바로 맞장구쳤어요. "프롬프트 엔지니어링"이라는 말 자체가 틀렸고, 진짜 싸움은 컨텍스트에서 벌어진다고요.
다들 이렇게 믿어요
AI 에이전트가 이상한 답을 내놓으면 대부분 여기서 출발해요. 시스템 프롬프트를 더 구체적으로 쓰고, few-shot 예시를 추가하고, 출력 형식을 더 자세하게 지시하는 것. 이걸 반복하다 보면 단일 작업에서는 꽤 잘 먹히거든요.
근데 에이전트가 여러 단계를 거치면서 도구를 쓰고, 이전 대화를 기억하고, 기업 내부 데이터를 참조해야 하는 순간 — 즉 진짜 업무에 투입되는 순간 — 프롬프트 최적화는 점점 의미를 잃어요. 프롬프트를 아무리 다듬어도 에이전트가 모르는 것은 알 수 없으니까요.
근데 숫자는 정반대예요
Firecrawl이 분석한 연구 결과들이 구체적이에요. 프롬프트를 여러 대화 턴에 분산해서 넣으면 집중 제공할 때보다 평균 성능이 39% 떨어진다. 또 Databricks가 Llama 3.1 405b를 테스트했더니 컨텍스트 창이 32,000 토큰을 넘어서는 순간부터 정확도가 확연히 꺾였어요.
컨텍스트 창 안에 뭘 어떻게 넣느냐가 프롬프트 표현보다 훨씬 크게 작동한다는 거예요.
Elastic이 정리한 핵심 구분이 딱 떨어져요: "프롬프트 엔지니어링은 컨텍스트 창을 주어진 것으로 받아들인다. 컨텍스트 엔지니어링은 그걸 능동적으로 설계한다."
Neo4j가 정리한 에이전트 컨텍스트 실패 패턴 4가지를 보면:
| 실패 모드 | 설명 | 증상 |
|---|---|---|
| 컨텍스트 독성 (Poisoning) | 환각이 대화 기록에 남아 계속 참조됨 | 오류가 누적되며 악화 |
| 컨텍스트 분산 (Distraction) | 이전 대화에 과도하게 의존 | 훈련 지식 무시, 틀린 답 반복 |
| 컨텍스트 혼란 (Confusion) | 불필요한 정보가 응답에 영향 | 핵심과 무관한 내용 섞여 들어옴 |
| 컨텍스트 충돌 (Clash) | 모순된 정보가 동시에 컨텍스트 안에 존재 | 답변이 일관되지 않음 |
이 4가지 문제 중 프롬프트 엔지니어링으로 해결할 수 있는 건 없어요. 전부 무엇을 컨텍스트에 넣고, 언제, 어떻게 넣느냐의 문제거든요.
그래서 컨텍스트 엔지니어링이 뭔데?
한 줄로 정리하면: 모델에게 어떻게 질문할지가 아니라 모델이 일할 수 있는 환경 자체를 설계하는 것이에요.
Neo4j는 컨텍스트 엔지니어링의 범위를 이렇게 정의해요: 검색 파이프라인 설계, 메모리 전략 수립, 도구 스키마와 정책 정의, 작업 상태 추적, 추론 히스토리 관리. 프롬프트 엔지니어링과의 차이를 직접 비교하면:
| 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 | |
|---|---|---|
| 핵심 질문 | 어떻게 표현할까? | 무엇을 알아야 할까? |
| 대상 | 단일 입력 텍스트 | 전체 정보 아키텍처 |
| 적합한 작업 | 단일 턴, 간단한 분류·번역 | 멀티스텝 에이전트, 장기 워크플로 |
| 실패 시 대응 | 표현 수정 | 검색·메모리·도구 구조 재설계 |
| 스케일 | 개인 작업, 프로토타입 | 프로덕션 AI 시스템 |
컨텍스트 엔지니어링에서 핵심 개념이 Minimum Viable Context(MVC)예요. 모델에게 필요한 최소한의 고신호 정보만 주는 것. 너무 많이 줘도 집중력이 분산되고, 너무 적게 줘도 환각이 생겨요. 딱 필요한 만큼만.
이상적인 에이전트 호출의 컨텍스트 5요소
① 사용자의 목표 ② 가장 관련 있는 검색 결과만 ③ 필요한 도구 정의 ④ 관련 정책 ⑤ 압축된 메모리 요약 — 이 5가지면 충분해요.
GraphRAG: 컨텍스트 설계의 기반
기존 RAG는 벡터 유사도로 텍스트 조각을 가져와요. 독립된 덩어리들이라 관계를 파악하는 멀티홉 추론에 약하고, 노이즈가 많이 들어오는 단점이 있어요.
GraphRAG는 엔티티와 관계를 구조화해서 저장해요. "A가 B에 영향을 미칠 때 C는?" 같은 복잡한 질문에 답할 수 있고, 검색 시점에 접근 권한을 적용할 수 있고, 어떤 관계 경로를 따라 결론을 냈는지도 추적할 수 있어요. 벡터 검색과 그래프 탐색을 동시에 활용하는 Agentic GraphRAG가 현재 컨텍스트 엔지니어링의 핵심 아키텍처예요.
지금 당장 시작하는 법
- 실패 모드 진단부터
에이전트 에러 로그와 대화 기록을 보면 패턴이 보여요. 독성·분산·혼란·충돌 중 어디에 해당하는지 파악해요. - 핵심 지식 도메인 정의
에이전트가 반드시 알아야 하는 도메인 지식이 무엇인지 목록화해요. 이게 나중에 지식 그래프의 뼈대가 돼요. - RAG 파이프라인 점검
동시에 30개 이상의 도구를 제공하고 있다면 RAG로 필터링해서 줄이세요. 30개 이하로만 줄여도 도구 선택 정확도가 3배 향상된다는 연구 결과가 있어요. - 메모리 전략 분리
단기(현재 세션), 중기(사용자 이력), 장기(도메인 지식)를 분리해서 설계해요. 모든 이전 대화를 쌓으면 컨텍스트 분산이 생겨요. - Minimum Viable Context로 트리밍
컨텍스트 창에 들어가는 내용을 의도적으로 줄여보세요. 덜 넣었을 때 성능이 더 좋아진다면, 그게 바로 컨텍스트 과부하였던 거예요.
프롬프트 엔지니어링이 쓸모없다는 말이 아니에요
컨텍스트 엔지니어링은 프롬프트 엔지니어링을 대체하는 게 아니라 상위 개념이에요. 단일 작업이나 빠른 프로토타이핑에는 여전히 프롬프트 최적화가 효과적이에요. 에이전트가 복잡한 멀티스텝 업무를 처리해야 할 때, 그때 컨텍스트 엔지니어링이 필요한 거예요.
