대부분의 AI 결과가 실망스러운 것은 모델이 나쁜 게 아니라 컨텍스트가 빈약하기 때문입니다. 컨텍스트 엔지니어링에 대한 실용적인 가이드 — 모델 윈도우에 무엇이 있는지, 훌륭한 컨텍스트의 다섯 기둥, 흔한 안티패턴, 그리고 일관되게 더 나은 결과를 내는 재사용 가능한 템플릿.
작성자: Nguyen Le Phong··15분 읽기
AI
컨텍스트 엔지니어링
프롬프트 엔지니어링
LLM
개발자 생산성
AI 도구
이런 경험 아시죠. 명확해 보이는 질문을 AI에 입력하면 돌아오는 답변은... 살짝 빗나간다. 기술적으로는 관련이 있지만 핵심을 놓친다. 다시 표현해보고, 재시도하고, 또 빗나간 답변을 받는다. 다섯 번의 왕복 끝에 겨우 쓸 만한 것을 얻지만, 처음부터 직접 했으면 더 빨랐을 것이다.
실제로 일어나는 일은 이렇습니다: 모델은 앞에 놓인 것만으로 작업할 수 있습니다. 코드베이스가 어떻게 생겼는지, 제약 조건이 무엇인지, 이미 무엇을 시도했는지, 왜 묻는지를 전혀 모릅니다. AI 응답이 빗나갈 때, 근본 원인은 거의 항상 정보 부족입니다. 말 선택이나 프롬프트 기술이 아닙니다. 이것이 AI 커뮤니티가 컨텍스트 엔지니어링이라고 부르는 것의 핵심입니다.
정의
컨텍스트 엔지니어링은 AI에게 제공하는 정보——역할, 배경 상태, 작업, 제약, 출력 형식——를 의도적으로 설계하여 반복적인 대화 없이 일관되게 유용한 결과를 얻는 기술입니다.
컨텍스트 엔지니어링이란 실제로 무엇인가
2025년 Andrej Karpathy가 대중화한 이 용어는 "프롬프트 엔지니어링"과의 차이가 중요합니다. 프롬프트 엔지니어링은 단어 선택에 관한 것입니다. 컨텍스트 엔지니어링은 한 단계 더 깊이 들어가서, 모델이 생성하기 전에 어떤 정보를 제공하는지에 관한 것입니다.
미장 플라스(요리 전 식재료 준비)로 생각해보세요. 훌륭한 셰프는 요리를 시작하기 전에 모든 재료를 준비합니다. 컨텍스트 엔지니어링은 AI 협력자를 위해 그 준비 작업을 하는 것입니다.
컨텍스트 윈도우 해부
AI와의 모든 상호작용은 컨텍스트 윈도우라는 작업 메모리 안에서 일어납니다. 네 가지 레이어가 있습니다.
컨텍스트 윈도우의 네 레이어. 대부분의 사람들은 4번 레이어(사용자 메시지)에만 집중하지만, 가장 강력하고 간과되는 것은 1, 2번 레이어입니다.
시스템 프롬프트는 가장 강력하지만 가장 간과되는 레이어입니다. 모델의 페르소나, 전문 지식 수준, 모든 응답을 지배하는 규칙을 설정합니다.
주입 컨텍스트는 원자재를 제공하는 곳입니다: 코드 파일, 문서, 오류 로그. 모델이 추론하는 재료입니다.
대화 기록은 세션이 진행되면서 축적됩니다. 유용하지만 토큰 비용이 높습니다.
사용자 메시지는 실제 질문이나 작업입니다. 잘 설계된 설정에서는 전체 토큰의 5% 미만인 경우가 많습니다.
훌륭한 컨텍스트의 다섯 기둥
다섯 기둥. 기둥 3(Task)이 가장 많은 주목을 받지만, 나머지 네 기둥이 그 작업을 잘 답변할 수 있게 만드는 것입니다.
기둥 1: 역할(Role)
모델이 누구여야 하는지 정의하세요——전문성, 관점, 소통 스타일.
역할 없음
역할 있음
인증을 설명해.
당신은 보안 전문 시니어 백엔드 엔지니어입니다. JavaScript는 알지만 auth 구현은 처음인 주니어 개발자를 위해 JWT의 보안 트레이드오프와 주의사항을 설명하세요.
기둥 2: 상태(State)
현재 상황을 알려주세요——코드베이스 구조, 시도한 것, 효과 없는 것, 결정된 사항, 적용 중인 제약.
상태 없음
상태 있음
이 버그 고쳐. (코드만 붙여넣기)
[코드] 이 debounce 함수는 일반 입력에서는 작동하지만 빠른 스크롤에서는 대기 없이 즉시 실행됨. clearTimeout 시도해봤지만 여전히 실행됨. React 18, TypeScript. 콘솔 오류: [메시지].
기둥 3: 작업(Task)
원하는 것을 정확하게 지정하세요, 카테고리가 아니라. "API 도와줘"는 카테고리입니다. "JWT 토큰을 검증하고, 없거나 유효하지 않으면 401을 반환하고, 디코딩된 사용자를 req.user에 첨부하는 Express 미들웨어를 작성해줘"가 작업입니다.
기둥 4: 제약(Constraints)
무엇을 해서는 안 되는지, 범위 제한, 절대 규칙을 알려주세요. 제약은 제한적으로 들리지만 실제로는 응답을 해방시킵니다.
제약 작성법
"하지 마세요", "피해주세요"처럼 명시적인 부정문으로 작성하세요. 모델은 도움이 되도록 학습되어 자연스럽게 범위를 넓히려 합니다. 명시적 부정이 가장 신뢰할 수 있는 가드레일입니다.
기둥 5: 형식(Format)
출력의 형태를 지정하세요: 길이, 구조, 세부 수준. 형식 지침 없이는 모델이 적절하다고 판단하는 것을 받게 됩니다.
재사용 가능한 컨텍스트 템플릿 만들기
## 역할
당신은 [역할], [도메인] 전문가입니다.
대상 독자는 [대상]입니다.
## 배경 상태
기술 스택: [언어 / 프레임워크]
현재 상태: [간단한 설명]
시도한 것: [시도와 결과]
관련 오류: [해당하는 경우]
## 작업
[정확히 한 문장: 동사 + 대상 + 범위]
## 제약
- [라이브러리/접근법] 사용하지 마세요
- [측면]을 [한도] 이내로 유지하세요
## 출력 형식
[길이] — [구조] — [세부 수준]
핵심 정리
컨텍스트 엔지니어링 > 프롬프트 엔지니어링: 단어 선택보다 제공하는 정보가 더 중요합니다.
네 레이어, 하나의 예산: 각각 다른 목적을 가지며 같은 토큰을 두고 경쟁합니다.
다섯 기둥, 다섯 격차: Role, State, Task, Constraints, Format. 다섯 가지를 모두 다루면 반복 대화가 급격히 줄어듭니다.
품질이 양보다 중요: 관련성 있고 집중된 컨텍스트가 크고 집중되지 않은 덤프보다 항상 낫습니다.
이 글 어떠셨나요?
자주 묻는 질문
What is context engineering and why does it matter for developers?
Context engineering is the skill of deliberately designing the information you provide to an AI — its role, background state, task, constraints, and output format — so it produces useful results without back-and-forth. It matters because the quality of AI output is almost entirely determined by the quality of input: vague, thin context produces generic, off-target answers, while rich, structured context produces specific, actionable ones. Most developers underestimate this and focus on rephrasing prompts instead.
What is the difference between context engineering and prompt engineering?
Prompt engineering is about word choice — how to phrase a request so the model interprets it correctly. Context engineering is a level deeper: it's about what information you make available before the model generates anything. You can have a perfectly phrased prompt and still get a poor answer because the model lacks background, state, or constraints. Context engineering addresses the information architecture; prompt engineering addresses the wording within it.
What are the five pillars of great context?
The five pillars are: (1) Role — who the model should be (persona, expertise, audience perspective); (2) State — what already exists, what's been tried, what constraints apply; (3) Task — exactly what you want done, not a vague category; (4) Constraints — what to avoid, scope limits, hard rules; (5) Format — the shape of the output (length, structure, level of detail). Addressing all five reduces back-and-forth dramatically and improves first-draft quality.
How do I build a reusable context template?
Structure your template around the five pillars: Role (who the model is and for whom), Background State (tech stack, what exists, what's been tried), Task (one precise sentence), Constraints (explicit negatives: what not to do), and Output Format (length, structure, detail level). You don't need to fill in every field every time — for a simple lookup, role + task + format is enough. For complex debugging or code review, all five matter. The template is a scaffold, not a form.
What does 'token budget' mean in context engineering?
Every interaction with an AI happens inside a context window with a fixed size measured in tokens. Everything you include — the system prompt, pasted code, conversation history, your question — competes for space in that window. Token budget management means being selective about what you include: paste specific functions rather than whole files, strip boilerplate from pasted code, summarize conversation history after long sessions, and put standing instructions in the system prompt rather than repeating them per-message. Irrelevant content isn't neutral — it's noise the model has to reason through.