컨텍스트 엔지니어링
컨텍스트 엔지니어링은 LLM에 주어지는 컨텍스트(지침, 검색 결과, 도구, 메모리, 대화 기록)를 설계하고 관리해 최적의 출력을 끌어내는 분야입니다. 프롬프트 문구 작성에 집중하는 프롬프트 엔지니어링을 포함하는 더 넓은 개념으로, '무엇을 어떤 형식으로 언제 컨텍스트에 넣을지'를 다룹니다.
- 컨텍스트 엔지니어링은 LLM의 추론 시점에 컨텍스트 윈도우를 채우는 토큰(지침·검색 결과·도구·메모리·대화 기록)을 설계하고 관리하는 분야입니다.
- 프롬프트 문구 자체를 다듬는 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 부분집합으로, 프롬프트는 전체 컨텍스트의 일부일 뿐입니다.
- Anthropic은 "추론 시 최적의 토큰 집합을 큐레이션하고 유지하는 전략의 집합"으로 정의합니다(2025년 9월).
- LangChain은 컨텍스트를 다루는 네 가지 전략으로 쓰기(write)·선택(select)·압축(compress)·격리(isolate)를 제시합니다.
- 컨텍스트 윈도우가 '용량(RAM)'이라면, 컨텍스트 엔지니어링은 그 한정된 공간에 '무엇을 넣을지' 설계·관리하는 실천에 초점을 둡니다.
개요
컨텍스트 엔지니어링은 LLM이 작업을 수행할 때 주어지는 컨텍스트, 즉 시스템 지침·검색 결과·도구 정의·장기 메모리·대화 기록 전체를 설계하고 관리해 최적의 출력을 끌어내는 분야입니다. 같은 모델이라도 컨텍스트 윈도우에 어떤 정보를 어떤 형식으로 넣느냐에 따라 결과가 크게 달라지므로, 모델 선택만큼이나 컨텍스트 구성이 결과 품질을 좌우합니다.
구글 딥마인드의 Phil Schmid는 컨텍스트 엔지니어링을 "올바른 정보와 도구를 올바른 형식으로 올바른 시점에 제공해 LLM이 작업을 완수하는 데 필요한 모든 것을 주는 동적 시스템을 설계·구축하는 분야"로 정의합니다(2025년 6월). 그는 컨텍스트를 "하나의 문자열이 아니라 하나의 시스템(A System, Not a String)"으로 다루어야 한다고 강조하며, 에이전트의 실패는 대개 모델의 한계가 아니라 컨텍스트 품질의 문제에서 비롯된다고 설명합니다.
이 개념은 단발성 질의응답보다 여러 단계에 걸쳐 도구를 호출하고 메모리를 누적하는 AI 에이전트 환경에서 특히 중요해집니다. 작업이 길어질수록 도구 결과와 중간 산출물이 쌓여 컨텍스트 윈도우 한계를 넘기거나, 비용과 지연이 늘거나, 성능이 저하되기 쉽기 때문입니다.
프롬프트 엔지니어링 vs 컨텍스트 엔지니어링
두 개념은 대립하는 것이 아니라 포함 관계입니다. Anthropic은 프롬프트 엔지니어링을 "최적의 결과를 위해 LLM 지침을 작성·구성하는 방법"으로, 컨텍스트 엔지니어링을 "추론 시 최적의 토큰 집합을 큐레이션하고 유지하는 전략의 집합"으로 구분합니다. 즉 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 부분집합이며, 잘 쓴 프롬프트는 여전히 중요하지만 프로덕션 에이전트에서는 전체 컨텍스트의 일부에 불과합니다.
| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 다루는 대상 | 모델에 보내는 텍스트(지침·질문) | 컨텍스트 윈도우 전체(지침·도구·메모리·검색 결과·기록) |
| 핵심 질문 | 무슨 문구로 어떻게 지시할까 | 무엇을 어떤 형식으로 언제 넣을까 |
| 성격 | 정적인 문자열 작성 | 동적인 시스템 설계·관리 |
| 주 무대 | 단발성 질의응답 | 다단계 에이전트, 장기 실행 작업 |
| 관계 | 컨텍스트 엔지니어링의 부분집합 | 프롬프트 엔지니어링을 포함하는 상위 개념 |
컨텍스트를 구성하는 요소
Phil Schmid는 컨텍스트를 구성하는 일곱 가지 요소를 제시합니다. 컨텍스트 엔지니어링은 이 요소들을 선별하고 배치하는 작업입니다.
- 지침 / 시스템 프롬프트 — 에이전트의 행동 규칙과 예시를 담은 초기 지침
- 사용자 프롬프트 — 당장 처리할 질문이나 작업
- 상태 / 기록(단기 메모리) — 직전까지 오간 현재 대화 내용
- 장기 메모리 — 과거 대화에서 누적된 지식과 학습된 선호
- 검색된 정보(RAG) — 문서·데이터베이스·API에서 가져온 외부 최신 지식
- 사용 가능한 도구 — 모델이 호출할 수 있는 함수 정의
- 구조화된 출력 — JSON 스키마 같은 응답 형식 명세
핵심 전략과 근거
LangChain은 2025년 7월 블로그에서 여러 에이전트와 논문을 분석해 컨텍스트 엔지니어링의 네 가지 공통 전략을 정리했습니다. 이 글은 Andrej Karpathy의 비유를 인용하는데, LLM을 "새로운 종류의 운영체제"에 빗대어 "LLM은 CPU, 컨텍스트 윈도우는 작업 기억으로 쓰이는 RAM"과 같다고 설명합니다. RAM 용량이 한정돼 있듯, 어떤 정보를 그 한정된 공간에 올릴지가 핵심입니다.
- 쓰기(Write) — 스크래치패드나 메모리를 활용해 정보를 컨텍스트 윈도우 바깥에 저장해 두고 나중에 다시 씁니다.
- 선택(Select) — 메모리·도구·RAG 등을 통해 필요한 정보만 컨텍스트 윈도우 안으로 가져옵니다.
- 압축(Compress) — 요약과 트리밍으로 "작업 수행에 필요한 토큰만" 남깁니다.
- 격리(Isolate) — 여러 에이전트·샌드박스·상태 객체로 컨텍스트를 분리해 따로 관리합니다.
Anthropic도 2025년 9월 엔지니어링 글에서 장기 실행 작업을 위한 구체적 기법을 제시합니다. 컴팩션(compaction)은 컨텍스트 내용을 요약한 뒤 그 요약으로 새 컨텍스트 윈도우를 다시 시작하는 방식이고, 구조화된 노트 작성은 에이전트가 컨텍스트 윈도우 바깥에 메모를 남겨 두었다가 나중에 불러와 최소한의 오버헤드로 지속 메모리를 유지하는 방식입니다. 이 외에도 깨끗한 컨텍스트를 가진 서브 에이전트가 집중된 작업을 처리한 뒤 압축된 요약만 돌려주는 구조, 그리고 모든 데이터를 미리 넣지 않고 가벼운 식별자만 유지하다 실행 시점에 필요한 데이터를 불러오는 적시 검색(just-in-time retrieval)을 함께 권장합니다.
실행 체크리스트
- 시스템 프롬프트는 명확하고 직접적인 언어로, 너무 구체적이지도 너무 모호하지도 않은 적정 수준에서 작성합니다.
- 도구는 최소한으로 선별하고, 도구 결과에는 모델이 다음 행동을 정하는 데 필요한 메타데이터만 담고 지나치게 긴 결과는 잘라 냅니다.
- 긴 작업에서는 대화 기록을 무한정 쌓지 말고 요약·압축으로 "필요한 토큰만" 남깁니다.
- 상태 데이터는 JSON 같은 구조화 형식, 진행 메모는 비정형 텍스트로 구분해 메모리를 관리합니다.
- 모든 정보를 선제적으로 주입하지 말고, 식별자만 유지하다 필요한 순간에 적시 검색으로 불러옵니다.
- 작업이 한 컨텍스트로 감당하기 버거우면 서브 에이전트로 분리하고 요약만 회수합니다.