왜 프롬프트 엔지니어링만으로는 부족한가
프롬프트 엔지니어링(Prompt Engineering)은 LLM에게 무엇을 어떻게 물어볼지를 다듬는 기술이다. 몇 해 전까지는 이것으로 충분했다. 모델에 단일 질문을 던지고, 표현을 바꾸면서 더 나은 답을 유도하는 것이 AI 적용의 핵심 스킬이었다.
프로덕션 에이전트 시스템이 등장하면서 상황이 달라졌다. 에이전트는 한 번의 응답이 아니라 수십 번의 스텝을 거친다. 각 스텝에서 모델 입력에는 시스템 프롬프트, 도구 정의, 대화 이력, 도구 실행 결과, 검색된 문서, 외부 메모리에서 주입한 정보가 함께 담긴다. 이 집합의 품질이 모델의 판단을 결정한다.
2025년 6월, Andrej Karpathy는 "진지한 LLM 애플리케이션에서 핵심 스킬은 프롬프트 엔지니어링이 아니라 컨텍스트 엔지니어링"이라고 밝혔다. 이후 여러 연구 그룹이 이 개념을 체계화하기 시작했다. 2026년 3월에는 "Context Engineering: From Prompts to Corporate Multi-Agent Architecture"(arXiv:2603.09619)가, 4월에는 "Context Engineering: A Practitioner Methodology for Structured Human-AI Collaboration"(arXiv:2604.04258)이 발표되었다.
컨텍스트 엔지니어링은 모델이 각 스텝에서 필요한 정보를 적시에, 적절한 형태로, 적정 분량으로 받도록 입력 공간 전체를 설계하는 실천이다. 단일 프롬프트 문장을 다듬는 것이 아니라 정보 구조 전체의 아키텍처를 다룬다.
컨텍스트 창: 에이전트의 작업 공간
에이전트 실행 중 컨텍스트 창은 다음 요소들로 구성된다.
| 구성 요소 | 설명 | 특성 |
|---|---|---|
| 시스템 프롬프트 | 에이전트의 역할, 목표, 제약 정의 | 거의 고정, 높은 우선순위 |
| 도구 정의 | 호출 가능한 함수의 시그니처와 설명 | 많아질수록 비용과 혼동 증가 |
| 대화 이력 | 이전 스텝의 사용자·모델·도구 메시지 | 무한 누적되면 창을 넘침 |
| 도구 실행 결과 | 함수 호출의 반환값 | 불필요한 전체 결과는 노이즈 |
| 검색 결과(RAG) | 벡터 검색이나 키워드 검색으로 가져온 청크 | 관련성이 낮으면 방해 요소 |
| 메모리 주입 | 외부 저장소에서 꺼낸 과거 경험·선호 | 선택적 로딩이 핵심 |
이 목록을 보면 무엇이 문제인지 명확해진다. 각 항목은 토큰을 소비하고, 관련 없는 정보는 신호 대 잡음 비율을 낮춘다. 창이 넘치면 모델은 오래된 정보를 잃고, 창이 꽉 찬 상태에서 중요한 최신 도구 결과를 수용할 공간이 없어진다.
메모리 유형: 컨텍스트 창 안팎의 정보
에이전트 메모리는 위치에 따라 두 계층으로 나뉜다.
단기 메모리 (In-Context)
컨텍스트 창 안에 직접 존재하는 정보다. 모델은 이 정보 전체를 한 번에 본다. 현재 대화 흐름, 최근 도구 호출 결과, 시스템 프롬프트가 여기 해당한다. 강점은 모델이 완전한 어텐션으로 처리한다는 것이고, 약점은 토큰 한도가 있고 모델 재시작 시 사라진다는 것이다.
장기 메모리 (External)
컨텍스트 창 바깥의 영구 저장소다. 에이전트가 명시적으로 조회하거나 쓸 때만 접근된다.
- 에피소딕 메모리: 과거 대화 기록, 사용자 선호, 이전 작업 경험. 벡터 데이터베이스에 임베딩으로 저장하고 유사도 검색으로 불러온다.
- 시맨틱 메모리: 세계 지식, 도메인 전문 지식, 정책 문서. RAG가 이 유형을 다룬다.
- 프로시저럴 메모리: 작업 수행 방법, 루틴, 규칙. 시스템 프롬프트나 도구 정의의 형태로 주입된다.
네 가지 핵심 조작: Write · Select · Compress · Isolate
LangChain의 2026년 컨텍스트 엔지니어링 프레임워크는 에이전트가 컨텍스트를 다루는 방식을 네 가지 기본 조작으로 정리한다.
1. Write — 외부로 저장하기
에이전트 스텝의 결과물, 중요한 관찰, 사용자 선호 등을 컨텍스트 창 바깥의 저장소에 기록한다. 다음 스텝이나 다음 세션에서 재사용할 수 있도록 한다.
구현 예: 긴 연구 작업에서 중간 단계의 발견을 요약해 벡터 DB에 저장한다. 나중에 다른 서브에이전트가 이 발견을 검색해 컨텍스트에 포함시킨다. 단일 컨텍스트 창이 감당하기 어려운 장기 작업을 가능하게 하는 기반이다.
2. Select — 필요한 것만 끌어오기
외부 저장소에서 현재 스텝에 관련 있는 정보만 컨텍스트 창에 가져온다. 전부 로드하는 것이 아니라 선별이 핵심이다.
구현 패턴:
- 문서 RAG: 질문의 임베딩과 지식 베이스 청크의 유사도를 계산해 상위 K개만 포함한다.
- 도구 RAG: 도구 정의 자체를 RAG로 관리한다. 200개 도구가 있더라도 현재 쿼리에 관련된 5~10개만 컨텍스트에 넣는다. 연구에 따르면 도구 선택 정확도가 3배 향상된다.
- 메모리 RAG: 에피소딕 메모리에서 현재 작업과 관련된 과거 경험만 선택 주입한다.
3. Compress — 필요한 토큰만 유지하기
컨텍스트 창 안의 정보를 작게 만들어 더 중요한 정보를 위한 공간을 확보한다.
구현 패턴:
- 대화 요약: 긴 대화 이력을 요약해 핵심만 유지한다. LangGraph의 state schema에
summary필드를 두고 N턴마다 압축한다. - 도구 출력 압축: API 응답이 2,000 토큰이라면 에이전트에게 필요한 필드만 추출한 200 토큰으로 줄인다.
- 청크 트리밍: 검색된 문서에서 질문에 직접 답하는 단락만 남긴다.
4. Isolate — 서브에이전트 컨텍스트 분리
멀티에이전트 시스템에서 각 에이전트는 자신의 작업에 필요한 컨텍스트만 받아야 한다. 전체 시스템의 컨텍스트를 모든 에이전트가 공유하면 비용이 폭증하고, 관련 없는 정보가 판단을 방해한다.
구현 패턴:
- 오케스트레이터 에이전트는 서브에이전트에게 전체 대화 이력 대신 해당 서브태스크의 지시와 관련 컨텍스트만 전달한다.
- 결과를 합산할 때만 오케스트레이터가 전체 그림을 본다.
arXiv:2603.09619: 컨텍스트의 다섯 가지 품질 기준
2026년 3월 논문은 컨텍스트의 품질을 평가하는 다섯 기준을 제시한다.
| 기준 | 설명 | 실패 사례 |
|---|---|---|
| 관련성 (Relevance) | 현재 작업과 관련 있는 정보만 포함 | 모든 이전 대화를 무조건 포함 |
| 충분성 (Sufficiency) | 작업 완수에 충분한 정보 보유 | 검색 결과를 너무 적게 포함 |
| 격리성 (Isolation) | 서브에이전트 간 컨텍스트 경계 유지 | 모든 에이전트가 전체 컨텍스트 공유 |
| 경제성 (Economy) | 최소 토큰으로 충분한 정보 전달 | 불필요한 메타데이터와 반복 포함 |
| 출처 추적성 (Provenance) | 각 정보의 출처와 신뢰도 표시 | 검색된 주장과 시스템 지식의 혼합 |
이 기준은 코드 리뷰에서 "코드 품질"을 평가하듯, 에이전트 시스템의 컨텍스트 설계를 객관적으로 검토하는 체크리스트로 쓸 수 있다.
컨텍스트 창 "중간 소실" 문제
컨텍스트 엔지니어링이 중요한 이유 중 하나는 Lost in the Middle 현상이다. 연구에 따르면 LLM은 컨텍스트의 시작과 끝에 있는 정보를 더 잘 처리하고, 중간에 있는 정보는 상대적으로 간과하는 경향이 있다.
실용적 함의:
- 가장 중요한 지시와 제약은 시스템 프롬프트 앞부분에 배치한다.
- 현재 스텝에서 가장 관련 있는 검색 결과는 대화 이력 직전에 배치한다.
- 긴 중간 맥락(이전 도구 결과 전체)은 압축하거나 요약해 중요 정보가 묻히지 않도록 한다.
멀티에이전트 시스템에서의 컨텍스트 설계
단일 에이전트에서 멀티에이전트로 넘어가면 컨텍스트 엔지니어링의 복잡도가 크게 증가한다.
오케스트레이터–서브에이전트 패턴에서 핵심은:
- 오케스트레이터가 전체 작업을 분해할 때 각 서브태스크의 컨텍스트 경계를 명시적으로 정의한다.
- 서브에이전트에게는 해당 태스크에 필요한 최소 컨텍스트만 전달한다. 전체 대화 이력이나 다른 서브에이전트의 결과를 섞지 않는다.
- 서브에이전트 결과를 합산할 때 오케스트레이터가 전체 그림을 구성한다.
실용 체크리스트
에이전트 시스템 설계 시 컨텍스트 엔지니어링 관점에서 확인할 항목이다.
컨텍스트 비용 점검
- 에이전트가 매 스텝마다 사용하는 평균 토큰은 얼마인가?
- 도구 정의가 전체 컨텍스트의 몇 %를 차지하는가? 200개 이상의 도구가 있다면 Tool RAG 도입을 검토한다.
- 대화 이력이 무한 축적되고 있지 않은가? 일정 길이 이후 요약 압축 전략을 적용한다.
정보 관련성 점검
- RAG로 가져온 청크가 실제로 질문에 답하는가? 리랭커(Reranker)를 추가해 관련성을 2차 검증한다.
- 시스템 프롬프트에 에이전트가 절대 쓰지 않는 지시가 포함되어 있는가? 불필요한 지시는 제거한다.
멀티에이전트 컨텍스트 격리 점검
- 서브에이전트가 자신의 태스크와 무관한 대화 이력이나 도구 정의를 받고 있지 않은가?
- 오케스트레이터가 서브에이전트 결과를 병합할 때 중복되거나 충돌하는 정보는 없는가?
프로덕션 모니터링
- 각 에이전트 스텝의 컨텍스트 크기를 로그로 수집한다.
- 컨텍스트 창이 자주 넘치는 스텝을 식별해 그 지점에 Compress 전략을 적용한다.
프롬프트 엔지니어링과의 관계
컨텍스트 엔지니어링이 프롬프트 엔지니어링을 대체하지는 않는다. 프롬프트 엔지니어링은 여전히 중요하다. 관계는 다음과 같다.
- 프롬프트 엔지니어링: "모델에게 어떻게 물어볼까" — 표현, 형식, few-shot 예시, 지시 문장 구성.
- 컨텍스트 엔지니어링: "모델이 볼 정보 전체를 어떻게 설계할까" — 무엇을 포함하고, 무엇을 배제하고, 어디서 가져오고, 얼마나 압축할까.
단일 질의응답 시스템에서는 프롬프트 엔지니어링이 핵심이다. 에이전트 시스템, 멀티턴 어시스턴트, 장기 실행 워크플로우에서는 컨텍스트 엔지니어링이 더 중요한 레버가 된다.
Open question: 컨텍스트 엔지니어링의 효과를 정량적으로 측정하는 표준 벤치마크는 아직 확립되지 않았다. 어느 Compress 전략이 어떤 태스크에서 얼마나 효과적인지는 워크로드마다 다르며 체계적인 측정이 필요하다.
정리
컨텍스트 엔지니어링의 핵심은 모델이 매 스텝에서 올바른 정보를, 올바른 형태로, 올바른 양만큼 받도록 시스템을 설계하는 것이다.
네 조작(Write, Select, Compress, Isolate)은 서로 독립적이지 않다. Write로 외부에 저장하고, Select로 필요할 때 꺼내고, Compress로 창을 효율화하고, Isolate로 서브에이전트 경계를 지킨다. 이 네 가지가 함께 작동할 때 에이전트 시스템은 토큰 비용을 낮추면서도 더 나은 판단을 할 수 있다.
LLM의 성능이 빠르게 좋아지는 지금, 에이전트 시스템의 품질을 결정하는 마지막 남은 변수는 점점 더 "무엇을 모델에게 보여줄 것인가"가 되고 있다.
References
- Context Engineering: From Prompts to Corporate Multi-Agent Architecture — arXiv:2603.09619 (2026-03)
- Context Engineering: A Practitioner Methodology for Structured Human-AI Collaboration — arXiv:2604.04258 (2026-04)
- Context Engineering for Agents — LangChain Blog (2026)
- langchain-ai/context_engineering — GitHub
- Context Engineering Strategies — DeepWiki (LangChain)
- Context Engineering: LLM evolution for agentic AI — Elasticsearch Labs
- Context Engineering — LLM Memory and Retrieval for AI Agents — Weaviate Blog
- A Guide to Context Engineering for LLMs — ByteByteGo