컨텍스트 엔지니어링이란? AI 코딩을 위한 가이드 (2026)

컨텍스트 엔지니어링이란?

컨텍스트 엔지니어링은 언어 모델이 각 추론 호출에서 보게 되는 토큰 전체 집합을 설계하고, 선별하고, 관리하여, 작업을 끝내는 데 필요한 정보를 충분히—그러나 딱 필요한 만큼만—갖추게 하는 분야예요. 그 토큰 집합에는 여러 계층이 있어요. 시스템 프롬프트, 도구 설명, 넘겨주는 코드 파일, 대화 기록, 도구 실행 결과, 그리고 장기 메모리(예: CLAUDE.md 파일)예요.

간단히 말하면, 프롬프트 엔지니어링은 "이 지시문을 어떻게 잘 표현할까?"를 묻고, 컨텍스트 엔지니어링은 "컨텍스트 윈도우에 정확히 무엇을, 어느 시점에 불러오고, 무엇을 빼둘까?"를 물어요. Anthropic은 이를 에이전트가 여러 루프를 돌며 점점 더 많은 데이터를 쌓아가면서 자연스럽게 이어지는 발전 단계라고 설명해요(Effective context engineering for AI agents, 2025-09-29 게시 참고).

AI 코딩에서 이것이 바로 핵심이에요. 같은 모델, 같은 요청이라도 잘못된 파일을 불러오거나, 기록이 부풀어 오르게 두거나, 프로젝트 규칙을 잊어버리면 생성된 코드는 사양에서 벗어나요. 코딩 에이전트의 출력 품질은 모델보다 컨텍스트에 더 좌우돼요. 그래서 컨텍스트를 선별할 줄 아는 개발자는, 동료가 이미 쓰고 있는 것과 완전히 똑같은 도구에서 더 많은 것을 끌어내는 경향이 있어요.

컨텍스트 엔지니어링 vs 프롬프트 엔지니어링

많은 사람이 이 두 용어를 같은 의미로 써요. 프롬프트 엔지니어링이 한물간 건 아니에요—다만 이제는 컨텍스트 엔지니어링 안에 있는 하나의 계층이 되었어요. 프롬프트는 특정 지시문을 어떻게 표현하느냐이고, 컨텍스트는 그 지시문을 둘러싼 정보 환경 전체예요.

이 문장은 벽에 붙여둘 만해요. 나쁜 프롬프트의 비용은 나쁜 답변 하나뿐이지만, CLAUDE.md의 나쁜 한 줄은 몇 달 동안 모든 요청에 붙는 세금이에요. 바로 이 점이 컨텍스트 엔지니어링의 레버리지가 훨씬 큰 이유예요—한 곳만 고치면 이후 수천 번의 세션이 혜택을 봐요. 프로젝트 규칙 파일을 제대로 작성하고 싶다면 Claude Code를 위한 탄탄한 CLAUDE.md 작성하기 가이드를 참고하세요.

AI 코딩에서 컨텍스트가 중요한 이유(컨텍스트 윈도우와 토큰 예산)

모든 모델에는 컨텍스트 윈도우—한 번에 "볼" 수 있는 토큰 수의 한계—가 있어요. 현재 Claude Code에서 쓰이는 Claude 모델의 윈도우는 대략 정도로, 텍스트 수백 페이지에 해당해요. 많아 보이지만, 실제 작업에서는 생각보다 빠르게 소진돼요.

"큰 윈도우"가 "좋은 기억"을 뜻하지 않는 이유는 두 가지 현상으로 설명돼요.

• 어텐션 예산은 줄어들어요: 토큰을 더할 때마다 모델의 어텐션이 옅어져요. 많이 밀어 넣을수록 모델이 정말 중요한 세부 사항에 계속 집중하기가 어려워져요. 컨텍스트는 무한한 창고가 아니라 희소한 자원이에요.
• 컨텍스트 부패 / "중간에서 길을 잃음": 긴 대화의 중간에 놓인 정보는 처음이나 끝에 있는 정보보다 모델이 놓치기 쉬워요. 그래서 코딩 에이전트가 수십 턴 전에 한 말을 종종 "잊거나", 긴 세션 뒤에 틀린 답을 내놓는 거예요.

직접 측정할 수 있는 수치가 있어요. "항상 켜져 있는" 구성(시스템 프롬프트, 도구 정의, 메모리)만으로 이미 윈도우의 약 10~20%를 차지한다면, 나머지가 코드·기록·도구 출력에 쓸 수 있는 몫이에요. 총 사용량이 윈도우의 대부분을 넘어서면 품질이 떨어지기 시작해요—그때가 압축하거나 초기화해야 할 시점이에요. 컨텍스트를 선별한다는 건 정확히, 진짜 중요한 것을 예산 안에 계속 담아두는 작업이에요.

실용적인 멘탈 모델을 하나 소개할게요. 컨텍스트 윈도우를 서류 캐비닛이 아니라 책상이라고 생각하세요. 책상이 아무리 넓어도 결국 복잡해지고, 모든 걸 쌓아 올리면 필요한 서류 한 장을 찾는 게 느려져요. 모델도 똑같아요—"모든 토큰을 꼼꼼하고 고르게 읽는" 게 아니라 어텐션을 배분해요. 그래서 정말 필요한 몇 개의 파일만 넣은 집중된 세션이, "레포 전체를 쏟아붓고 물어보는" 세션보다 대개 더 높은 품질의 코드를 만들어내요. AI 코딩에서는 책상을 깔끔하게 유지하는 규율이 올바른 모델을 고르는 것만큼 중요해요.

네 가지 컨텍스트 엔지니어링 전략(Write, Select, Compress, Isolate)

커뮤니티(LangChain, LlamaIndex 등 다수)는 네 가지 전략이라는 간결한 사고 프레임워크로 수렴했어요. 일상적인 코딩 워크플로에 컨텍스트 엔지니어링을 적용할 때 가장 기억하기 쉬운 묶음이에요.

Write - 바깥으로 덜어내기

모든 걸 컨텍스트에 쑤셔 넣는 대신 정보를 밖으로 밀어내세요. 계획, 메모, 결정 사항을 파일에 적는 거예요(예: NOTES.md, 스크래치패드, 또는 CLAUDE.md 같은 지속 메모리). 컨텍스트는 정보를 가리키는 포인터만 유지하다가 필요할 때 다시 불러와요.

Select - 필요한 것만 가져오기

컨텍스트를 희소한 것으로 다루세요. 레포 전체를 쏟아붓는 대신 지금 작업에 필요한 파일이나 스니펫만 정확히 불러와요. 이것이 검색 증강(RAG), @file 문법, 그리고 적시(just-in-time) 검색의 정신이에요—미리 불러오는 게 아니라 필요한 순간에 데이터를 가져오는 거죠.

Compress - 요약하기

긴 대화 기록과 도구 출력은 보관하기 전에 요약하세요. Anthropic은 이 기법을 compaction이라고 불러요. 컨텍스트가 가득 차려 할 때, 대화 꼬리 전체를 끌고 가는 대신 지금까지 한 일을 짧은 요약으로 압축하고 이어가는 거예요.

Isolate - 떼어내기

부수 작업(조사, 리뷰, 조회)을 자체적인 깨끗한 컨텍스트를 가진 별도의 subagent로 옮기세요. subagent는 작업을 끝내고 오케스트레이션 에이전트에 압축된 요약만 돌려줘요—지저분한 세부 사항이 메인 컨텍스트를 오염시키지 않아요. 예를 들어 낯선 라이브러리를 익혀야 할 때, 문서 페이지 전체를 메인 컨텍스트로 끌어오는 대신 subagent에게 문서를 읽게 하고 "쓸 함수 3개와 호출 방법"만 돌려받는 거예요.

이 네 전략은 서로 배타적이지 않아요—실제 세션에서는 보통 네 가지를 모두 써요. 계획을 NOTES.md에 적고(Write), 편집 중인 파일만 불러오고(Select), 기록이 길어지면 압축하고(Compress), 조사는 서브에이전트에 덜어내요(Isolate). 이 프레임워크가 몸에 배면, Claude Code의 모든 기능을 "이건 어떤 컨텍스트 전략에 도움이 되지?"라는 렌즈로 보게 돼요.

Claude Code로 실전 컨텍스트 엔지니어링 기법

여기가 가장 중요한 부분이에요. 위의 네 전략을 Claude Code에서 매일 쓰는 도구에 대응시키는 거예요. Claude Code의 강점은 각 기능이 컨텍스트 전략으로 되짚어진다는 점이에요—그러니 명령어를 외우는 대신 "이 명령어는 어떤 컨텍스트 문제를 푸는가?"를 묻는 법을 익히세요.

• CLAUDE.md = 지속 메모리(Write). 이 파일에는 프로젝트 규칙, 레포 구조, 해야 할 것과 하지 말아야 할 것이 담겨요. 모든 세션에 불러와지므로 여기에 가장 큰 레버리지가 있어요—한 번 제대로 써두면 모든 요청에서 혜택을 봐요.
• /compact와 /clear(Compress + 초기화). 컨텍스트가 거의 찼을 때 /compact는 기록을 요약으로 압축하고, /clear는 컨텍스트를 깨끗이 비워 완전히 새로운 작업으로 넘어갈 때 새로 시작하게 해줘요.
• /context(측정). 이 명령어는 사용 중인 토큰의 내역을 보여줘요—토큰을 잡아먹는 것은 눈에 보여야 비로소 최적화할 수 있어요.
• 서브에이전트(Isolate). 조사·리뷰 작업을 서브에이전트에 맡겨 자기 컨텍스트를 "태우고" 결과만 돌려받으세요. Claude Code에서 서브에이전트 사용 가이드를 참고하세요.
• MCP와 @file(Select). 미리 불러오는 대신 외부 소스에서 적시에 데이터를 불러오세요. MCP가 처음이라면 MCP란 무엇인가를 읽어보세요.
• 플랜 모드 / NOTES.md 스크래치패드(Write). 긴 계획은 컨텍스트 밖에 두고, 에이전트는 필요할 때만 참조하게 하세요.

짧고 실용적인 CLAUDE.md 예시예요—토큰을 너무 많이 태우지 않으면서 에이전트를 사양에 맞게 유지하기에 충분해요.

# CLAUDE.md

## Project
Booking API, Node.js + Fastify + PostgreSQL (Prisma).

## Structure
- src/routes - endpoint definitions
- src/services - business logic
- src/db - Prisma schema & migrations

## Conventions (DO)
- Validate input with zod at the route layer
- Every query goes through a service; never call Prisma directly in a route
- Commit with Conventional Commits

## Avoid (DON'T)
- Do not add a new dependency without asking first
- Do not edit a migration file that has already been merged
- Do not log user data to the console

토큰 예산 관리: 측정과 최적화

컨텍스트 엔지니어링은 감으로 하는 활동이 아니에요—"측정한 다음 최적화하는" 루프예요.

1. /context를 읽어 토큰이 어디에 배분되는지 확인하세요. 시스템, 도구, 메시지, 파일, 출력이에요.
2. 토큰 먹는 하마를 찾으세요: 보통 긴 도구 출력(로그, 테스트 결과), 통째로 불러온 큰 파일, 또는 부풀어 오른 대화 기록이에요.
3. 원인을 처리하세요: 기록이 길면 압축하고(/compact), 파일이 크면 선택적으로 불러오고(디렉터리 전체 대신 @file), 부수 작업이 너무 시끄러우면 서브에이전트로 떼어내세요.
4. 새 세션을 열 때를 아세요: 정말로 작업을 바꿀 때는 오래된 컨텍스트를 끌고 다니는 것보다 /clear나 새 세션이 나아요.

현장에서 검증된 습관 하나예요. 긴 세션의 시작과 중간, 특히 큰 출력을 반환하는 명령어(빌드, 테스트, 로그) 직후에 /context를 슬쩍 확인하는 습관을 들이세요. 토큰을 잡아먹는 범인은 편집 중인 코드가 아니라 이전 실행에서 붙여넣은 로그 더미인 경우가 아주 많아요. 일찍 잡아내면 /compact 한 번이나 새 세션으로 예산의 대부분을 되찾을 수 있어요.

왜 그럴 가치가 있을까요? 토큰은 곧 돈이고 지연 시간이에요. 컨텍스트가 군더더기 없이 날렵할수록 턴당 비용은 낮아지고 응답은 빨라져요—그리고 그만큼 중요하게도, 모델이 산만해지지 않아 답변 품질이 좋아져요. 비용 측면이 신경 쓰인다면 Claude Code 비용과 토큰 최적화 글을 읽고 토큰 수를 실제 청구서와 연결해 보세요.

흔한 컨텍스트 엔지니어링 실수

솔직히 말해, 코딩 에이전트의 "멍청한" 오류 대부분은 모델이 약해서가 아니라 컨텍스트가 망가져서 생겨요. 실패 유형을 알아보면 도구 탓을 하는 대신 빠르게 고칠 수 있어요. 흔한 네 가지 패턴이에요.

• 컨텍스트 중독(context poisoning): 잘못된 정보(틀린 가정, 이후 바뀐 낡은 결정)가 컨텍스트에 박혀 에이전트를 계속 엉뚱한 방향으로 몰아가요. 예방: 알아차리는 즉시 고치거나 /clear하고, 에이전트가 "잘못된 토대 위에서 자신만만한" 상태로 남지 않게 하세요.
• 컨텍스트 산만(context distraction): 관련 없는 정보가 너무 많아 모델의 어텐션이 옅어져요. 예방: 선택적으로 불러오고, 컨텍스트를 최소한으로, 그러나 충분하게 유지하세요.
• 컨텍스트 충돌(context clash): 서로 모순되는 두 지시가 공존해요(예: CLAUDE.md는 라이브러리 A를 쓰라고 하는데 대화에서는 B를 요구). 예방: 규칙의 출처를 일관되게 유지하고, 방향을 바꾸면 메모리를 갱신하세요.
• 컨텍스트 부패(context rot): 대화가 너무 길어지면 품질이 저하돼요. 예방: 적절한 시점에 /compact하고, 결과를 파일에 고정한 뒤 세션을 새로 고치세요.

컨텍스트 엔지니어링을 돕는 도구와 키트

위 기법 대부분은 전부 손으로 할 수 있어요. CLAUDE.md를 쓰고, /compact를 입력하고, 서브에이전트를 띄우는 거죠. 시작하는 데 뭔가를 살 필요는 없어요. 그 밖에도 이런 패턴—메모리, compaction, isolate—을 묶어 놓은 미리 만들어진 스킬/서브에이전트 번들이 있어서, 처음부터 직접 만들지 않아도 돼요. 예를 들어 Claude Code용 AgentKit(링크로 20% 할인) 번들이에요(ak CLI. 이건 OpenAI의 AgentKit과는 다른 제품이라는 점에 유의하세요). 이런 키트가 컨텍스트 패턴을 어떻게 묶어 놓는지 궁금하다면 AgentKit 리뷰를 읽어보세요. 그리고 특히 메모리와 컨텍스트를 더 깊이 파고들고 싶다면 Claude Code의 컨텍스트와 메모리 관리를 참고하세요.

자주 묻는 질문(FAQ)

컨텍스트 엔지니어링은 프롬프트 엔지니어링과 어떻게 다른가요?

프롬프트 엔지니어링은 한 턴의 특정 지시문을 다듬어요. 컨텍스트 엔지니어링은 여러 턴에 걸친 토큰 전체 집합—시스템 프롬프트, 도구, 코드, 기록, 메모리—을 관리해요. 프롬프트 엔지니어링은 이제 컨텍스트 엔지니어링 안의 한 계층이에요.

컨텍스트 엔지니어링을 배우려면 코딩을 할 줄 알아야 하나요?

개념만 이해하는 거라면 아니지만, AI 코딩에 적용하고 싶다면 크게 필요해요. 가장 효과적인 기법(CLAUDE.md 작성, 불러올 파일 선택, 기록 압축, 서브에이전트 분리)은 모두 실제 프로그래밍 워크플로와 이어져 있어요.

Claude Code의 컨텍스트 윈도우는 몇 토큰인가요?

Claude Code의 Claude 모델은 대략 수십만 토큰의 윈도우를 가져요(한계와 모델이 빠르게 바뀌므로, 의존하기 전에 공식 Claude Code 문서에서 정확한 수치를 확인하세요). 숫자 자체보다 더 중요한 건 /context로 측정하고 중요한 것을 예산 안에 담아두는 방법을 아는 거예요.

/compact는 언제 써야 하나요?

대화 기록이 길어지고 컨텍스트가 거의 찼지만 같은 작업을 계속 이어가고 싶을 때예요. /compact는 대화를 요약으로 압축해 작업 흐름을 유지해요. 완전히 다른 작업으로 넘어간다면 압축하는 대신 /clear를 쓰거나 새 세션을 여세요.

CLAUDE.md는 컨텍스트 엔지니어링인가요?

네, 그건 Write 전략의 교과서적인 예예요. 매번 지시를 반복하는 대신 프로젝트 규칙을 지속되는 파일에 기록해 모든 세션에 불러오는 거죠. 좋은 CLAUDE.md를 쓰는 건 존재하는 컨텍스트 조치 중에서도 레버리지가 가장 큰 것 중 하나예요.

컨텍스트 엔지니어링이 RAG를 대체하나요?

아니에요—RAG(검색)는 그 자체가 컨텍스트 엔지니어링 안의 Select 전략의 일부예요. 컨텍스트 엔지니어링은 더 넓은 프레임워크이고, RAG는 올바른 정보를 컨텍스트에 불러오기 위한 하나의 구체적인 기법이에요.

결론과 다음 단계

컨텍스트 엔지니어링은 효과적인 AI 코딩의 기초 역량이에요. 핵심은 "어떤 모델이 가장 강한가"가 아니라 "얼마나 잘 컨텍스트를 선별하는가"예요. 네 가지 전략—Write, Select, Compress, Isolate—을 익히고, /context로 측정하고, 네 가지 컨텍스트 실패 유형을 일찍 잡아내세요. 그렇게 하면 코딩 에이전트를 "잘 잊는" 존재에서 믿을 수 있는 존재로 바꿀 수 있어요. 메모리 기법을 더 깊이 알고 싶다면 Claude Code의 컨텍스트와 메모리 관리를, 컨텍스트와 비용을 연결하고 싶다면 Claude Code 비용과 토큰 최적화를 이어서 읽어보세요. AI와 함께 일하는 걸 이제 막 시작했다면 바이브 코딩이란 무엇인가와 AI 슬롭을 피하는 법도 살펴보세요.