컨텍스트 엔지니어링 (Context Engineering)

AI 에이전트에게 「무엇을 보여줄 것인가」를 설계하는 기술

이 시리즈는 「AI 개발 규율의 진화」를 순서대로 해설합니다.

본 기사는 제2회: Context Engineering입니다.

제1회 「Prompt Engineering」은 이쪽 → （링크）

왜 「무엇을 보여줄 것인가」가 중요한가

우수한 외과의사를 고용했다고 가정하자.

하지만 수술실에 들어갔을 때, 환자의 차트가 없었다. 검사 결과도 없다. 과거 병력도 없다. 있는 것이라고는 「환자는 60세 남성입니다」라는 한 줄뿐이다.

이 상황에서는 아무리 우수한 외과의사라도 최선의 판단을 내릴 수 없다. 문제는 외과의사의 실력이 아니라, 전달된 정보의 질과 양이다.

AI 에이전트도 완전히 동일한 구조를 가지고 있다.

모델이 아무리 똑똑해도, 컨텍스트 윈도우 (Context Window)에 전달되는 정보가 빈약하면 출력도 빈약해진다. 반대로 정보가 너무 많으면 비용이 급증하고, 오히려 정밀도가 떨어진다.

「무엇을, 어느 타이밍에, 어떤 형식으로 모델에게 보여줄 것인가」를 설계하는 기술 —— 그것이 컨텍스트 엔지니어링 (Context Engineering)이다.

정의와 배경

Andrej Karpathy가 2025년 6월에 제창한 정의가 그대로 업계 표준이 되고 있다.

「컨텍스트 엔지니어링이란, 다음 단계를 위해 컨텍스트 윈도우에 적절한 정보를 채워 넣는 섬세한 기술이자 과학이다」

「너무 적거나 형식이 맞지 않으면 모델은 최적의 퍼포먼스를 발휘할 수 없다. 너무 많거나 형식이 맞지 않으면 비용이 올라가고 정밀도가 떨어진다」라고 그는 덧붙였다.

Anthropic도, Shopify의 CEO Tobi Lütke도 비슷한 시기에 같은 말을 사용하기 시작했으며, 2025년 후반에는 「context engineering is the job」(에이전트를 구축하는 엔지니어의 가장 중요한 업무는 컨텍스트 엔지니어링이다)라는 인식이 확산되었다.

현실 세계의 비유

우수한 탐정, 하지만 정보가 없음

셜록 홈즈를 상상해 보라.

그에게 「이 사건을 해결해 주세요」라고만 전달했다고 가정하자. 증거물 없음, 증언 없음, 현장 사진 없음. 아무리 추리력이 높아도 답을 낼 수 없다.

다음으로 증거물을 너무 많이 주었다고 가정하자. 골판지 상자 50개 분량의 자료를 쌓아두고 「이 안에 답이 있습니다」라고 말한다. 홈즈는 자료를 정리하는 데만 일주일이 걸리고, 정작 중요한 추리에 쓸 에너지가 남지 않는다.

최고의 결과를 끌어내기 위해서는 「지금 이 추리 단계에 필요한 정보만을 적절한 형식으로 전달하는 것」이 필요하다.

AI 에이전트에 대한 컨텍스트 설계란, 바로 이 「홈즈에게 정보를 전달하는 방식」의 설계다.

컨텍스트 윈도우 (Context Window)란 무엇인가

기술적인 전제로 파악해 두자.

LLM은 「컨텍스트 윈도우 (Context Window)」라고 불리는 유한한 메모리 공간 안에서만 사고할 수 있다. 이 윈도우에 포함된 것 전체가 모델이 「보고 있는 세계」다.

┌─────────────────────────────────────────┐
│ 컨텍스트 윈도우 │
│ │
...

중요한 특성이 2가지 있다.

첫 번째, 유한하다는 것. Claude 3.7은 20만 토큰, GPT-4o는 12.8만 토큰과 같은 상한선이 있다. 채워 넣으면 채워 넣을수록 비용이 올라간다.

두 번째, 위치에 따라 중요도가 달라진다는 것. 연구에 따르면 윈도우의 앞부분과 뒷부분에 있는 정보는 모델이 참조하기 쉽고, 중간에 파묻힌 정보는 간과되기 쉬운 경향이 있다 (Lost in the Middle 문제).

컨텍스트 엔지니어링의 4가지 전략

LangChain의 Lance Martin이 정리한 4가지 전략이 가장 널리 사용되는 프레임워크다.

전략 1: Write (쓰기)

컨텍스트에 포함할 정보를 직접 써넣는다. 가장 단순한 전략이다.

# 시스템 프롬프트에 직접 쓰는 예
당신은 EC 사이트의 서포트 에이전트입니다.
## 현재 상황
...

에이전트가 매번 확실히 필요로 하는 정적인 정보는 여기에 쓴다. 단, 정보가 오래될 가능성이 있는 것은 동적으로 취득할 필요가 있다.

전략 2: Select (선택하기)

모든 정보를 전달하는 것이 아니라, 지금 필요한 정보만을 골라서 전달한다. RAG (Retrieval-Augmented Generation)는 이 전략의 대표적인 예시다.

사용자: 「주문 번호 #12345의 배송 상황을 알려주세요」
❌ 나쁜 설계 (전부 전달)
→ 모든 고객의 주문 이력 10만 건을 컨텍스트 (Context)에 투입
...

def build_context(user_query, order_id):
# 필요한 정보만 골라서 가져온다
order_info = order_api.get(order_id) # 주문 정보
...

「코드베이스 전체를 컨텍스트에 때려 넣는 것」은 **컨텍스트 방화 (Context Arson)**라고 불리는 악수다. 필요한 부분만을 필요한 타이밍에 가져오는 설계가 올바르다.

⚠️ 「벡터 검색 (Vector Search)으로 상위 10개를 채워 넣는 것」도 위험하다

RAG를 사용하면 해결된다는 뜻은 아니다. 벡터 검색으로 걸러진 상위 10개를 그대로 컨텍스트에 채워 넣는 설계는 **일종의 컨텍스트 오염 (Context Pollution)**이다.

유사도 점수가 높더라도, 실제로는 현재 태스크와 무관한 문서가 혼입될 수 있다. 이것이 정밀도를 떨어뜨린다.

현장에서 주류가 되고 있는 것이 리랭킹 (Re-ranking, 재순위화) 단계다.

def select_with_reranking(user_query, top_k=10, final_k=3):
# 스텝 1: 벡터 검색으로 후보를 넓게 잡는다
candidates = vector_store.search(user_query, top_k=top_k)
...

벡터 검색 (Bi-Encoder)은 빠르지만 거칠다. 리랭커 (Re-ranker, Cross-Encoder)는 느리지만 정밀하다. 넓게 잡고, 엄선해서 전달한다는 2단계 방식이 현장의 표준이 되고 있다.

홈즈의 비유를 들자면 「증거품을 50상자에서 10상자로 좁힌 (벡터 검색) 후, 홈즈의 조수가 다시 정말 관련 있는 3상자만을 책상 위에 올려두는 (Re-ranking)」 이미지다.

전략 3: Compress (압축하기)

축적된 정보를 요약·압축하여 토큰 (Token)을 절약한다. 장시간 작동하는 에이전트 (Agent)에서 특히 중요해진다.

긴 대화나 작업 로그를 그대로 컨텍스트에 쌓아 올리면, 윈도우 (Window)가 순식간에 넘쳐버린다.

def compress_history(conversation_history, max_tokens=2000):
"""
대화 이력이 길어지면 요약하여 압축한다
...

사람으로 치면 「긴 회의록을 작성하여 중요한 결정 사항만을 다음 회의에 가져가는」 감각에 가깝다. 모든 발언록을 그대로 다음 회의에 가져오는 사람은 없다.

실무에서의 구현: LangGraph의 State Reducer

위의 코드 예시는 개념 이해를 위한 것이지만, 실무에서는 **LangChain / LangGraph 프레임워크 레이어 (Framework Layer)**에서 이 축약 처리를 포함하는 경우가 많다.

LangGraph에서는 「상태 (State)의 Reducer」로서, 오래된 메시지 리스트를 정기적으로 요약본(Summary)으로 교체하는 기구를 그래프의 일부로서 선언적으로 정의할 수 있다.

from langgraph.graph import StateGraph
from langchain_core.messages import RemoveMessage
def summarize_messages(state):
...

수동으로 토큰을 세는 것보다, 프레임워크의 State 라이프사이클 (Lifecycle)에 압축 로직을 포함시키는 것이 실운용에서는 더 안정적이다. 에이전트가 장시간 가동될수록 이 접근 방식의 혜택이 커진다.

전략 4: Isolate (분리하기)

관계없는 정보를 별도의 에이전트에게 나누어 맡긴다. 멀티 에이전트 (Multi-Agent) 구성의 핵심이다.

❌ 하나의 에이전트에게 전부 맡긴다
┌──────────────────────────────┐
│ 재고 정보 + 배송 정보 + 고객 정보 │
...

각 에이전트는 자신의 전문 영역 정보만을 가지며, 컨텍스트를 깨끗하게 유지한다. 이것이 하네스 엔지니어링 (Harness Engineering) · 루프 엔지니어링 (Loop Engineering)으로 이어지는 사고방식이다.

컨텍스트 설계의 실패 패턴

❌ 패턴 1: 컨텍스트 방화

코드베이스 전체, 모든 문서, 모든 이력을 그대로 때려 넣는다. 토큰 비용이 폭발하며, 「Lost in the Middle」 현상으로 인해 정밀도가 떨어진다.

❌ 패턴 2: 정보의 신선도 저하

시스템 프롬프트 (System Prompt)에 직접 작성한 정보가 오래되었음에도 업데이트되지 않는다. 「현재 캠페인 정보」가 3개월 전 상태 그대로인 패턴이다.

❌ 패턴 3: 컨텍스트 오염 (Context Contamination)

여러 태스크 (Task)의 실행 결과가 계속해서 축적되어, 후반부의 태스크가 전반부의 불필요한 정보에 영향을 받는 현상이다. 에이전트 (Agent)를 장시간 구동할 때 발생하기 쉽다.

❌ 패턴 4: 포맷 불일치 (Format Inconsistency)

정보는 전달되고 있지만, 모델 (Model)이 해석하기 어려운 형식으로 되어 있는 경우다. 가공되지 않은 JSON 덤프 (JSON dump)보다 구조화된 마크다운 (Markdown) 형식이 더 높은 정확도를 보이는 경우가 많다.

프롬프트 엔지니어링 (Prompt Engineering)과의 차이점

지난 기사에서 다루었던 프롬프트 엔지니어링과의 관계를 정리한다.

구분	프롬프트 엔지니어링 (Prompt Engineering)	컨텍스트 엔지니어링 (Context Engineering)
대상	"무엇을 말할 것인가" (지시어)	"무엇을 보여줄 것인가" (정보의 설계)
...

단순하게 말하자면, 프롬프트는 "어떻게 부탁할 것인가"이고, 컨텍스트는 "무엇을 보여준 상태에서 부탁할 것인가"이다.

요약

컨텍스트 엔지니어링의 본질은 한 문장으로 요약된다.

"모델에 전달할 정보를 너무 많지도 적지도 않게, 적절한 타이밍에, 적절한 형식으로 설계하는 것"

4가지 전략으로 정리하면 다음과 같다:

전략	수행 내용	사용하는 타이밍
Write	필요한 정보를 직접 작성	정적이고 확실히 필요한 정보
...

프롬프트 엔지니어링이 "외과의사의 실력을 연마하는" 기술이라면, 컨텍스트 엔지니어링은 "외과의사에게 전달할 정보(진료 기록, 검사 결과, 환자의 상태)를 정돈하는" 기술이다. 두 가지가 모두 갖춰져야 비로소 최선의 수술을 할 수 있다.

다음 기사에서는 에이전트의 행동 사이클 (Action Cycle) 그 자체를 설계하는 **에이전틱 엔지니어링 (Agentic Engineering)**을 다룬다. 컨텍스트를 올바르게 전달받은 에이전트가 어떻게 계획, 실행, 검증을 반복하는지에 대한 설계론이다.

시리즈 목록

• 【첫 번째 기사】 왜 "○○ 엔지니어링"은 계속해서 생겨나는가 (공개 예정)
• 제1회: Prompt Engineering
• [본 기사] 제2회: Context Engineering
• 제3회: Agentic Engineering (공개 예정)
• 제4회: Harness Engineering (공개 예정)
• 제5회: Loop Engineering (공개 예정)

Discussion