Context Engineering 완전 정복 (2): 이론적 기반과 핵심 개념

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy, 2025년 6월

들어가며

이전 글에서 우리는 Vibe Coding과 Spec Driven Development가 왜 실패하는지 살펴보았습니다. 핵심은 맥락의 제거였습니다.

이번 글에서는 그 해답인 Context Engineering의 이론적 기반을 깊이 있게 다룹니다. 단순히 "맥락을 더 주면 된다"가 아닌, 어떤 맥락을, 어떻게, 언제 제공해야 하는지의 과학과 예술을 탐구합니다.

이 글에서 다루는 내용:

Part 1: Context Engineering의 정의 — 용어의 기원과 정확한 의미
Part 2: LLM Context Window의 이해 — 크기, 한계, "Lost in the Middle"
Part 3: 맥락의 5가지 구성 요소 — 실전 적용을 위한 프레임워크
Part 4: Agentic AI와 맥락의 깊은 관계

Part 1: Context Engineering의 정의

1.1 용어의 기원과 진화

Prompt Engineering의 시대 (2022-2024)

ChatGPT의 등장 이후, "Prompt Engineering"이 핵심 기술로 부상했습니다:

더 나은 결과를 위한 프롬프트 작성법
Few-shot prompting, Chain-of-Thought 등 기법
"프롬프트 엔지니어" 직군의 등장

하지만 문제가 있었습니다. Simon Willison의 지적:

"The term prompt engineering makes people think it's 'typing something into a chatbot.'"

사람들은 Prompt Engineering을 **"챗봇에 뭔가 타이핑하는 것"**으로 오해했습니다. 실제로는 훨씬 복잡한 시스템 설계가 필요한데도.

Context Engineering의 등장 (2025)

2025년 중반, 업계 리더들이 새로운 용어를 제안하기 시작했습니다.

Shopify CEO Tobi Lutke:

"I really like the term context engineering over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM."

Andrej Karpathy:

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

1.2 Karpathy 정의의 심층 분석

Karpathy의 정의를 분해해봅시다:

"delicate art and science"

Art (예술): 직관, 경험, 창의성이 필요
Science (과학): 체계적 방법론, 측정 가능한 결과
Delicate (섬세한): 미세한 차이가 큰 결과 차이를 만듦

"filling the context window"

Context Window: LLM이 한 번에 처리할 수 있는 토큰의 양
Filling: 단순히 채우는 것이 아닌, 전략적으로 구성

"just the right information"

너무 적으면: AI가 추론할 근거 부족
너무 많으면: 노이즈, "Lost in the Middle" 문제
적절한 정보: 양보다 질, 관련성이 핵심

"for the next step"

정적이 아닌 동적 맥락
각 단계에 맞는 맥락 제공
Agentic AI의 ReAct 패턴과 연결

1.3 Prompt Engineering vs Context Engineering

측면	Prompt Engineering	Context Engineering
초점	입력 텍스트 최적화	전체 정보 환경 설계
성격	정적 (한 번 작성)	동적 (상황에 따라 변화)
범위	단일 프롬프트	시스템 전체
시간	요청 시점	지속적 (세션, 프로젝트)
구성요소	지시문, 예시	지시문, 예시, RAG, 상태, 도구, 히스토리
비유	질문 잘 하기	협업 환경 구축

1.4 Context Engineering의 공식 정의 제안

이 시리즈에서 사용할 정의:

Context Engineering은 LLM 또는 AI 에이전트가 주어진 작업을 효과적으로 수행할 수 있도록, 적절한 정보를 적절한 시점에 적절한 형식으로 제공하는 동적 시스템을 설계하고 구축하는 기술이다.

핵심 요소:

적절한 정보: 관련성 높은 맥락 선별
적절한 시점: 동적, 단계별 제공
적절한 형식: AI가 이해하기 쉬운 구조
동적 시스템: 정적 템플릿이 아닌 적응형 시스템

Part 2: LLM Context Window의 이해

2.1 Context Window란 무엇인가

정의: Context Window는 LLM이 한 번의 입력-출력 사이클에서 처리할 수 있는 최대 토큰 수입니다.

토큰이란:

단어, 기호, 문자의 인코딩된 형태
영어 기준: 약 4문자 = 1토큰
128,000 토큰 ≈ 약 100,000 단어 ≈ 약 300페이지

비유: 화이트보드를 생각해보세요. 공간이 클수록 더 많은 코드와 주석을 한 번에 검토할 수 있습니다.

2.2 주요 모델별 Context Window 크기 (2025년 기준)

모델	Context Window	비고
GPT-5	400K 토큰	128K 출력 윈도우
GPT-4.1	1M 토큰 (API)	ChatGPT는 제한적
Claude 3.5 Sonnet	200K 토큰
Gemini 2.5	1M 토큰
Llama 4	10M 토큰	2025년 4월 출시

트렌드:

Context Window 크기는 급격히 증가 중
하지만 크기가 전부가 아님

2.3 "Lost in the Middle" 현상

문제의 발견:

연구에 따르면, LLM은 긴 컨텍스트에서 중간에 있는 정보를 잘 활용하지 못합니다.

"Performance can degrade by more than 30% when relevant information shifts from the start or end positions to the middle of the context window." — GetMaxim.ai, 2025

현상 설명:

LLM은 컨텍스트의 시작과 끝에 있는 정보를 잘 기억
중간에 있는 정보는 "잃어버림"
이를 "Lost in the Middle" 또는 "U자형 주의력"이라 부름

NeurIPS 2024 연구:

"While many contemporary large language models (LLMs) can process lengthy input, they still struggle to fully utilize information within the long context, known as the lost-in-the-middle challenge."

실제 영향:

RAG 시스템에서 여러 문서를 연결할 때 문제
긴 코드베이스 분석 시 중간 부분 누락
대화 히스토리가 길어질수록 초기 맥락 손실

2.4 Context Window의 한계

1. 이차 스케일링 (Quadratic Scaling)

Attention 메커니즘은 토큰 수의 제곱에 비례하는 계산 필요
컨텍스트가 2배 → 계산량 4배
비용과 지연 시간 급증

2. 토큰 수 ≠ 정보 품질

100K 토큰의 관련 없는 정보 < 10K 토큰의 핵심 정보
노이즈가 많으면 오히려 성능 저하

3. 모델별 실제 활용 능력 차이

공식 Context Window 크기와 실제 활용 능력은 다름
일부 모델은 긴 컨텍스트에서 성능 급락

2.5 효과적인 Context Window 활용 전략

1. 중요한 정보는 시작과 끝에

[시스템 지시문 - 가장 중요] ← 시작
[배경 정보]
[참조 문서들] ← 중간 (Lost in the Middle 위험)
[현재 작업 맥락]
[구체적 요청 - 가장 중요] ← 끝

2. 맥락 압축과 요약

전체 문서 대신 관련 섹션만 추출
이전 대화를 요약하여 제공
핵심 결정사항만 유지

3. 계층적 맥락 구조

Level 1: 항상 포함 (프로젝트 개요, 핵심 제약)
Level 2: 작업별 포함 (관련 모듈, API)
Level 3: 필요시 포함 (상세 구현, 히스토리)

4. 동적 맥락 관리

작업 단계에 따라 맥락 교체
관련성 낮아진 정보 제거
새로운 결정사항 추가

Part 3: 맥락의 5가지 구성 요소

Karpathy와 업계 전문가들의 관점을 종합하면, 효과적인 맥락은 5가지 핵심 요소로 구성됩니다.

3.1 Task Description (작업 설명)

정의: AI가 수행해야 할 작업에 대한 명확한 설명

포함해야 할 것:

목표: 무엇을 달성하려 하는가
배경: 왜 이 작업이 필요한가
성공 기준: 어떻게 되면 성공인가
범위: 무엇이 포함되고 제외되는가

나쁜 예:

로그인 기능 만들어줘

좋은 예:

[목표]
기존 세션 기반 인증을 JWT로 전환하는 로그인 API 구현

[배경]
- 모바일 앱 출시 예정으로 stateless 인증 필요
- 현재 10,000명 사용자의 세션 마이그레이션 필요

[성공 기준]
- 기존 사용자가 재로그인 없이 전환 가능
- 응답 시간 200ms 이하 유지
- 보안 감사 통과

[범위]
- 포함: 로그인, 토큰 갱신, 로그아웃
- 제외: 회원가입, 비밀번호 재설정 (별도 작업)

핵심 원칙:

암묵적 가정을 명시화
"왜"를 포함
측정 가능한 기준 제시

3.2 Few-shot Examples (예시)

정의: 원하는 출력의 구체적인 예시

Few-shot Learning의 원리:

LLM은 예시에서 패턴을 학습
명시적 규칙보다 예시가 더 효과적인 경우 많음
2-5개의 예시가 일반적으로 최적

효과적인 예시 선택 기준:

대표성: 일반적인 케이스를 커버
다양성: 다른 유형의 입력/출력 포함
경계 케이스: 엣지 케이스 포함
품질: 원하는 수준의 출력

예시 구조:

[예시 1]
입력: 사용자가 잘못된 이메일 형식으로 로그인 시도
출력: { "error": { "code": "INVALID_EMAIL", "message": "올바른 이메일 형식이 아닙니다" } }

[예시 2]
입력: 존재하지 않는 사용자로 로그인 시도
출력: { "error": { "code": "USER_NOT_FOUND", "message": "등록되지 않은 이메일입니다" } }

[예시 3 - 성공 케이스]
입력: 올바른 인증 정보로 로그인
출력: { "success": true, "token": "eyJ...", "expiresIn": 3600 }

네거티브 예시의 활용:

[하지 말아야 할 것]
❌ { "error": "Something went wrong" }  // 모호한 에러
❌ { "err": "invalid" }  // 일관성 없는 형식

3.3 RAG (Retrieval Augmented Generation)

정의: 외부 지식 소스에서 관련 정보를 검색하여 맥락으로 제공

RAG의 구조:

사용자 질문 → 검색 쿼리 생성 → 벡터 DB 검색 → 관련 문서 추출 → LLM에 맥락으로 제공 → 응답 생성

RAG가 필요한 이유:

최신 정보: LLM 학습 데이터의 컷오프 이후 정보
도메인 지식: 회사/프로젝트 특화 정보
정확성: 환각(hallucination) 감소
맥락 효율: 필요한 정보만 선별

코드베이스 RAG 예시:

[검색된 관련 코드]
// auth/middleware.js
export const authMiddleware = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  // 기존 구현...
}

// models/User.js
const UserSchema = new Schema({
  email: { type: String, unique: true },
  passwordHash: String,
  // 기존 스키마...
});

RAG vs Long Context:

측면	RAG	Long Context
정보량	선별적	전체 포함
비용	검색 비용	토큰 비용
정확도	검색 품질에 의존	Lost in the Middle 위험
최신성	실시간 업데이트 가능	컨텍스트 재구성 필요

3.4 State & History (상태와 히스토리)

정의: 이전 상호작용과 결정의 기록

포함해야 할 것:

1. 대화 히스토리

[이전 대화 요약]
- 사용자가 JWT 인증 구현 요청
- Refresh 토큰 전략으로 sliding window 방식 합의
- 토큰 저장소로 Redis 선택

2. 결정 로그

[결정 사항]
1. 토큰 만료: 1시간 (보안 vs UX 균형)
   - 이유: 금융 규제 요구사항
2. Refresh 토큰: 7일
   - 이유: 모바일 앱 사용 패턴 고려

3. 피드백 히스토리

[이전 피드백]
- "에러 응답에 더 구체적인 코드 필요" → 반영됨
- "로깅이 너무 상세함" → 프로덕션 레벨로 조정

세션 간 연속성:

[이전 세션 요약]
마지막 작업: 로그인 API 기본 구조 완성
다음 단계: 토큰 갱신 로직 구현
미해결 이슈: Redis 연결 설정 필요

3.5 Tools & Constraints (도구와 제약)

정의: AI가 사용할 수 있는 도구와 지켜야 할 제약 조건

도구 명시:

[사용 가능한 도구]
- 파일 읽기/쓰기
- 터미널 명령 실행
- 웹 검색
- 코드 실행

[사용 불가]
- 외부 API 직접 호출
- 데이터베이스 직접 수정

제약 조건:

[기술적 제약]
- Node.js 18+ 환경
- ESM 모듈 시스템 사용
- TypeScript strict 모드

[비즈니스 제약]
- 개인정보 로깅 금지
- 외부 서비스 의존성 최소화

[스타일 제약]
- 함수는 단일 책임 원칙
- 에러는 커스텀 Error 클래스 사용
- 주석은 "왜"를 설명

출력 형식 지정:

[응답 형식]
1. 먼저 접근 방식 설명
2. 코드 블록으로 구현
3. 주요 결정 사항 설명
4. 테스트 방법 제안

가드레일:

[금지 사항]
- 하드코딩된 비밀키 사용 금지
- console.log 대신 로거 사용
- any 타입 사용 금지
- 동기 파일 I/O 금지

Part 4: Agentic AI와 맥락의 깊은 관계

4.1 Agentic AI의 핵심 패턴들

Agentic AI는 여러 디자인 패턴을 활용합니다. 각 패턴에서 맥락이 어떤 역할을 하는지 살펴봅시다.

1. ReAct (Reasoning + Acting)

맥락의 역할:
- Reasoning: 맥락을 기반으로 다음 행동 결정
- Acting: 맥락에 맞는 도구 선택 및 실행
- Observing: 결과를 맥락에 추가

2. Reflection (자기 성찰)

맥락의 역할:
- 이전 출력과 피드백을 맥락으로 제공
- AI가 자신의 출력을 평가하고 개선
- 개선 히스토리가 다음 맥락이 됨

3. Planning (계획 수립)

맥락의 역할:
- 목표와 제약을 맥락으로 제공
- AI가 단계별 계획 수립
- 각 단계 실행 시 계획이 맥락으로 작용

4. Multi-Agent (다중 에이전트)

맥락의 역할:
- 에이전트 간 공유 맥락
- 역할별 특화 맥락
- 결과 전달 시 맥락 변환

4.2 맥락이 Agent 성능에 미치는 영향

연구 결과 요약:

맥락 품질과 작업 성공률
- 고품질 맥락: 작업 성공률 85%+
- 저품질 맥락: 작업 성공률 40% 이하
- 맥락 없음: 단순 작업만 가능
맥락 양과 성능의 관계
- 적정 맥락: 최고 성능
- 과소 맥락: 추론 근거 부족
- 과다 맥락: 노이즈로 인한 성능 저하
맥락 구조의 중요성
- 구조화된 맥락 > 비구조화된 맥락
- 계층적 구조가 가장 효과적

4.3 맥락 설계의 원칙

1. 관련성 (Relevance)

현재 작업에 직접 관련된 정보만 포함
"있으면 좋을 것 같은" 정보는 제외

2. 구체성 (Specificity)

일반적 설명보다 구체적 예시
추상적 규칙보다 실제 코드

3. 구조화 (Structure)

명확한 섹션 구분
일관된 형식
계층적 조직

4. 최신성 (Recency)

오래된 정보 제거 또는 업데이트
최근 결정사항 우선

5. 검증 가능성 (Verifiability)

AI가 맥락의 정확성을 확인할 수 있도록
모순되는 정보 제거

결론: 이론에서 실천으로

이 글에서 배운 것

Context Engineering의 정의
- Prompt Engineering의 진화
- "적절한 정보를 적절한 시점에 적절한 형식으로"
- 정적 템플릿이 아닌 동적 시스템
Context Window의 이해
- 크기만이 전부가 아님
- "Lost in the Middle" 현상
- 전략적 배치의 중요성
맥락의 5가지 구성 요소
- Task Description: 명확한 목표와 배경
- Few-shot Examples: 패턴 학습을 위한 예시
- RAG: 외부 지식 통합
- State & History: 연속성 유지
- Tools & Constraints: 경계와 가드레일
Agentic AI와의 관계
- 각 패턴에서 맥락의 역할
- 맥락 품질이 성능을 결정

다음 글 미리보기

Article 3: Context Engineering 실전 - 프로젝트 셋업에서는:

CONTEXT.md, agents.md 작성 가이드
Cursor Rules 완전 가이드
MCP (Model Context Protocol) 활용
실제 템플릿과 체크리스트

실천 과제

이 글을 읽은 후 시도해볼 것:

현재 프로젝트의 맥락 감사
- 5가지 구성 요소 중 무엇이 부족한가?
- 어떤 정보가 암묵적으로 가정되고 있는가?
맥락 문서 초안 작성
- 프로젝트 개요
- 핵심 제약 조건
- 주요 결정 사항
AI 대화 패턴 점검
- "Lost in the Middle"을 피하고 있는가?
- 중요한 정보가 시작과 끝에 있는가?

References

Karpathy, A. (2025, June). "Context Engineering" - X/Twitter post.
Willison, S. (2025, June 27). "Context Engineering." simonwillison.net.
Lutke, T. (2025). Context Engineering에 대한 X/Twitter post.
GetMaxim.ai. (2025). "Advanced RAG Techniques for Long-Context LLMs."
NeurIPS. (2024). "Make Your LLM Fully Utilize the Context."
DataStudios. (2025). "How Large Language Models Handle Extended Context Windows."
Thoughtworks. (2025, November). "Technology Radar Vol. 33."
Codingscape. (2025). "LLMs with Largest Context Windows."

다음 글에서는 이론을 실제 프로젝트에 적용하는 방법을 다룹니다. Context Engineering을 어떻게 시작하셨나요? 댓글로 공유해주세요.