컨텍스트 엔지니어링이란
1. 프롬프트 한 줄로는 닿지 않는 영역
지금까지 우리가 다룬 프롬프트 엔지니어링은 "어떻게 말할 것인가"에 대한 기술이었습니다. 같은 모델에 같은 정보를 줘도 어떤 단어, 어떤 구조, 어떤 형식으로 던지느냐에 따라 답이 달라진다는 이야기였지요.
그런데 회사 일에서 ChatGPT나 Claude를 본격적으로 쓰기 시작하면 곧 한계에 부딪칩니다. 모델은 우리 회사 사정을 모릅니다. 우리 제품의 가격표를 모르고, 우리 코드베이스의 컨벤션을 모르고, 어제 우리 팀이 결정한 내용을 모릅니다. 프롬프트만 아무리 잘 짜도, 그 안에 우리 회사 정보가 들어가 있지 않으면 모델은 "일반론"으로 답할 수밖에 없습니다.
이걸 해결하기 위한 기술이 컨텍스트 엔지니어링입니다. 1장에서 봤듯이 2025년 6월 Tobi Lutke, Andrej Karpathy, Simon Willison이 거의 동시에 이 단어를 쓰면서 자리잡았고, Anthropic의 공식 가이드는 이를 "LLM 추론 과정에서 최적의 토큰 집합을 큐레이팅하고 유지하는 전략"으로 정의했습니다.
좀 더 풀어서 말하면, 프롬프트는 모델에게 "무엇을 시킬지" 말하는 것이고, 컨텍스트는 모델에게 "무엇을 보면서 답하라"고 같이 깔아두는 것입니다.
이 여섯 가지가 모델 앞에 깔리는 "책상" 전체이고, 그 위에서 모델이 답을 만듭니다. 책상 위에 무엇을 놓을지 정하는 일이 컨텍스트 엔지니어링의 본질입니다.
1.1 한눈에 보이는 차이
가장 간단한 예로, 코드 리뷰를 부탁하는 경우를 비교해봅시다.
프롬프트만 줄 때:
이 코드를 리뷰해줘.
function add(a, b) { return a + b; }
모델은 우리 팀의 코딩 컨벤션을 모르니까 "TypeScript로 바꾸세요", "JSDoc을 다세요" 같은 교과서적인 조언만 합니다. 그 조언이 우리 팀의 컨벤션과 맞을 수도 있고 어긋날 수도 있습니다.
컨텍스트를 같이 줄 때:
[시스템 프롬프트]
너는 위니브 팀의 코딩 컨벤션에 따라 코드를 리뷰하는 시니어 개발자야.
[참조: 우리 팀 컨벤션]
- 모든 함수는 TypeScript로 작성
- JSDoc 주석 필수
- 에러 처리는 try-catch 패턴
- 타입 검증은 zod 라이브러리 사용
[참조: 같은 파일의 다른 함수]
// utils/math.ts의 기존 함수들...
[리뷰 대상]
function add(a, b) { return a + b; }
이때 받는 답은 우리 팀의 실제 규칙에 맞춘 리뷰입니다. "TypeScript를 쓰세요"가 아니라 "위니브 컨벤션에 따라 zod로 타입을 검증하고, 같은 파일의 multiply 함수처럼 JSDoc을 다세요"가 됩니다. 같은 모델, 같은 코드인데 결과의 실용성이 완전히 달라집니다.
2. 위치도 분량도 모두 중요하다
3장 마지막에서 본 두 가지를 짧게 되짚어보고 갑니다. 컨텍스트 윈도우가 1M 토큰이라고 해도 그 안에 무엇을, 어디에 두느냐에 따라 모델이 같은 정보를 다르게 활용한다는 사실이었습니다.
- 위치. Lost in the Middle 현상 때문에 컨텍스트 중간에 묻힌 정보는 모델이 자주 놓칩니다. 시작과 끝이 가장 잘 활용됩니다.
- 분량. Context Rot 때문에 길어질수록 정확히 떠올릴 확률이 떨어집니다. 무작위로 넣은 50만 토큰보다 골라 넣은 5만 토큰이 답이 더 정확합니다.
이 두 가지가 컨텍스트 엔지니어링이 "최대한 많이 넣기"가 아닌 이유입니다. 좋은 자리에, 필요한 만큼만, 잘 정리해서 넣어야 합니다.
3. 컨텍스트 엔지니어링의 세 가지 원칙
위 두 가지(좋은 위치 + 적정 양)를 일반화하면 컨텍스트 엔지니어링의 기본 원칙 세 개가 나옵니다.
3.1 관련성, 필요한 것만 넣기
지금 작업에 직접 관계 있는 정보만 컨텍스트에 넣습니다. "혹시 모르니까" 넣은 정보가 모델의 주의를 분산시킵니다.
나쁜 예: 우리 회사 전체 위키 50개 문서를 통째로 붙임
좋은 예: 지금 질문과 관련된 3~5개 문서만 추려서 붙임
3.2 구조화, 모델이 읽기 좋게 정리하기
같은 정보라도 줄글로 늘어놓는 것보다 섹션·레이블·표로 구조화하면 모델이 훨씬 잘 활용합니다. 사람이 읽기 좋은 자료가 모델한테도 대체로 읽기 좋습니다.
나쁜 예: 한 덩어리 텍스트 5000자
좋은 예: [배경][제약][요청] 같은 레이블 + 마크다운 표·리스트
3.3 최신성, 동적으로 가져오기
회사 정책, 가격표, 재고, 환율 같은 정보는 어제와 오늘이 다릅니다. 미리 컨텍스트에 박아두면 금방 낡습니다. 그래서 컨텍스트 엔지니어링의 큰 축은 "필요한 순간에 가져온다(Just-in-Time)"는 패턴입니다. 1장에서 이름만 스쳐 간 RAG가 이 역할을 하는 도구이고, 뒤에서 본격적으로 다룹니다.
이 세 원칙(관련성 · 구조화 · 최신성)이 뒤에서 다룰 모든 기법의 밑바닥에 깔려 있습니다. 시스템 프롬프트 설계, RAG, CLAUDE.md 같은 프로젝트 컨텍스트 파일까지 결국 같은 질문에 답하기 위한 도구들입니다. "지금 이 작업에 필요한 정확한 정보를, 모델이 잘 보는 자리에, 적정 양으로 깔아두려면 어떻게 해야 하는가."