Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

컨텍스트 엔지니어링

컨텍스트 엔지니어링(Context Engineering)은 대규모 언어 모델(LLM)의 제한된 입력 공간(Context Window)에 모델이 최선의 답변을 낼 수 있도록 입력 데이터(맥락, 규칙, 리소스 등)를 체계적으로 기획, 선별, 구조화, 압축 및 제어하는 종합적인 기술이자 방법론입니다.

언어 모델의 가중치(Weights)를 직접 업데이트하는 사전 훈련(Pre-training)이나 미세 조정(Fine-Tuning)과 달리, 컨텍스트 엔지니어링은 모델을 그대로 둔 상태에서 모델에 공급하는 **‘맥락 정보의 밀도와 전달력’**을 극대화하는 것에 초점을 맞춥니다.

1컨텍스트 엔지니어링의 핵심 배경: 인컨텍스트 러닝 (In-Context Learning)

컨텍스트 엔지니어링이 강력한 힘을 발휘하는 이론적 기반은 인컨텍스트 러닝(In-Context Learning, I-CL)에 있습니다. Brown et al. (2020)

인컨텍스트 러닝은 LLM이 가중치를 변경하는 추가적인 학습 과정 없이, 오직 입력 프롬프트 내에 제시된 설명과 몇 가지 예시(Few-shot)만으로 새로운 작업을 학습하고 수행하는 현상입니다.

1.1I-CL의 특징

따라서 모델의 지능을 특정 작업에 고정시키는 파인튜닝과 다르게, 프롬프트에 주입하는 맥락 정보를 정밀하게 디자인하여 지능적 판단력을 순간적으로 끌어올리는 컨텍스트 엔지니어링은 최신 LLM 시스템 개발의 중추적인 기둥이 되었습니다.

2긴 컨텍스트의 비용과 품질 문제

컨텍스트는 길수록 좋은 것이 아닙니다. 입력이 길어지면 연산·메모리 비용이 늘고, 응답 품질도 떨어질 수 있습니다. 무엇을 얼마나 어떻게 넣을지를 설계해야 하는 이유입니다.

2.1KV 캐시(KV Cache)와 메모리 비용

트랜스포머 모델은 추론할 때 이전 토큰들과의 어텐션 연산을 반복하지 않기 위해 키-값 상태(Key-Value States)를 메모리에 저장해 둡니다. 이를 KV 캐시(KV Cache)라고 합니다.

문제는 입력 컨텍스트의 길이(LL)가 길어질수록 KV 캐시가 점유하는 메모리 크기가 선형적으로 늘어난다는 점입니다.

KV Cache Size (Bytes)≈2×nlayers×nheads×dhead×L×nsequences×Bytes per Parameter\text{KV Cache Size (Bytes)} \approx 2 \times n_{\text{layers}} \times n_{\text{heads}} \times d_{\text{head}} \times L \times n_{\text{sequences}} \times \text{Bytes per Parameter}
(1)

예를 들어 8B(80억 매개변수) 규모의 모델에서 컨텍스트 길이가 32K 토큰에 도달하면, 동시 요청 하나(n_sequences=1)만으로도 KV 캐시가 수 기가바이트(GB)의 메모리를 차지합니다.

이 비용은 배포 방식과 무관합니다. 클라우드 API에서는 입력 토큰 단가와 모델별 컨텍스트 한도로, 직접 호스팅에서는 GPU 메모리(VRAM) 점유로 나타날 뿐입니다.

2.2Lost in the Middle (맥락 유실 현상)

트랜스포머의 어텐션 메커니즘은 구조적 한계로 인해, 입력 프롬프트의 처음(시작)과 끝(결론) 부분의 정보에 과도하게 주의를 기울이고, 중간(Middle)에 배치된 세부 정보를 유실하거나 찾아내지 못하는 경향이 있습니다. Liu et al. (2024)

따라서 수만 토큰의 문서를 통째로 프롬프트에 구겨 넣으면, 모델은 중간 영역의 핵심 내용을 건너뛰어 엉뚱한(할루시네이션) 응답을 내놓게 됩니다. 정보의 가치 우선순위에 따라 컨텍스트 내의 정보를 영리하게 재배치하고 필터링하는 엔지니어링이 필수적인 이유가 바로 여기에 있습니다.

3컨텍스트를 조정하는 방법

앞서 본 인컨텍스트 러닝(왜 맥락이 곧 성능인가)과 비용·품질 제약(왜 조정해야 하는가)이 컨텍스트 엔지니어링의 근거라면, 실제로 맥락을 조정하는 방법은 크게 프롬프트 · 문서 · 도구, 그리고 이 셋을 묶어 재사용하는 스킬입니다. 무엇을 어떻게 컨텍스트에 넣고 다듬을지를 결정하는 이 방법들이 컨텍스트 엔지니어링의 방법론을 이루며, 각각 별도의 기법으로 발전해 왔습니다.

이 책은 프롬프트 · 문서 · 도구를 프롬프트 엔지니어링 → RAG → MCP 순으로 실습하고, 이들을 묶어 재사용하는 스킬로 마무리합니다. 대화 이력·장기 기억을 다루는 메모리는 범위 밖이며, 어떤 방법에든 공통으로 필요한 선별·압축·재배치(앞서 본 Lost in the Middle 대응 포함)는 뒤의 「고급 최적화 기법」 절에서 보완합니다.

3.1프롬프트

3.2문서

외부 문서·지식을 컨텍스트에 들이는 방법은 여러 가지입니다.

이 책에서는 이 가운데 문서가 많고 길어도 확장되는 RAG를 구현합니다.

3.3도구

3.4스킬

4비용과 지연을 줄이는 고급 최적화 기법

컨텍스트 엔지니어링의 고급 영역에서는 비용과 지연 시간을 줄이기 위한 기술적 장치들이 활용됩니다.

4.1프롬프트 캐싱 (Prompt Caching)

시스템 지시문이나 대형 문서 등 자주 바뀌지 않는 정적 텍스트가 컨텍스트 앞부분(Prefix)에 배치되는 경우, 많은 LLM 서비스는 해당 구간의 KV 캐시를 보존해 재사용합니다(클라우드 API와 로컬 서빙 엔진 모두 지원).

4.2컨텍스트 압축 (Context Compression)

수많은 정보 조각을 그대로 프롬프트에 나열하면 조사, 수식어 등 정보 밀도가 낮은 불필요한 토큰들이 대량 소비됩니다.

실제로 문서를 임베딩하고 검색 결과 조각들을 압축하거나, 맥락 유실(Lost in the middle) 문제를 예방하기 위해 정보를 재정렬하는 파이썬 코드 구현은 RAG 컨텍스트 최적화 실습 장을 참고하십시오.

5요약

LLM 서비스와 에이전트를 성공적으로 동작하게 만드는 핵심 열쇠는 모델을 무작정 큰 것으로 바꾸는 것이 아닌, 모델에게 전달되는 컨텍스트의 품질을 지휘하고 관리하는 능력에 달려 있습니다.

이어지는 하위 챕터들에서는 네 가지 조정 방법을 차례로 실습합니다. 프롬프트 설계의 기초 규칙을 배우고, 외부 문서를 검색해 주입하는 RAG 아키텍처를 구현하고, 도구·데이터를 표준으로 연결하는 MCP를 다룬 뒤, 이를 묶어 재사용하는 스킬까지 단계별로 살펴봅니다.

References
  1. Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D. M., Wu, J., Winter, C., … Amodei, D. (2020). Language Models are Few-Shot Learners. https://arxiv.org/abs/2005.14165
  2. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172
기초 환경 및 개념
엔터프라이즈 보안
기초 환경 및 개념
프롬프트