■ 효과적인 컨텍스트 엔지니어링

ITworld 칼럼 하나 소개한다. 내용이 참고할만다. 

성공적인 시스템은 가장 많은 컨텍스트를 보내는 시스템이 아니라, 가장 관련성 높은 컨텍스트를 보내는 시스템이다.

www.itworld.co.kr/article/4097715 

“무조건 많은 게 정답은 아니다” LLM 최적화의 핵심, 컨텍스트 엔지니어링의 기술

2025.11.28 By Md Abdul Halim Rafi

AI CRM을 구축하며 얻은 4가지 핵심 교훈, 7가지 실무 팁, 3가지 유용한 고급 패턴, 그리고 5가지 피해야 할 패턴을 알아본다.

컨텍스트 엔지니어링(Context Engineering)이 LLM을 다루는 데 있어 핵심 역량으로 부상하고 있다. 지금까지는 프롬프트 엔지니어링에 주로 초점이 맞춰졌지만, 실제로 AI 애플리케이션의 품질을 가르는 결정적 요소는 모델이 응답을 생성할 때 접근할 수 있는 정보, 즉 컨텍스트를을 얼마나 효과적으로 관리하느냐에 달려 있다. 컨텍스트 엔지니어링은 단순한 기술적 보조 작업이 아니라 AI의 성능을 ‘평범함과 탁월함’ 사이에서 갈라놓는 예술이자 과학으로 평가받는다.

필자는 LLM을 활용해 수년간 시스템을 구축해 오면서 분명한 교훈을 얻었다. 컨텍스트란 단순히 가능한 한 많은 정보를 프롬프트에 집어넣는 것이 아니다. 오히려 기술적 제약 안에서 모델의 성능을 극대화하기 위한 전략적 정보 아키텍처의 문제다.

컨텍스트 창의 기술적 현실

현대의 LLM은 대략 8,000개에서 많게는 20만 개 이상의 토큰을 처리할 수 있는 컨텍스트 창을 지원한다. 일부 모델은 이보다 훨씬 큰 크기를 제공한다고 주장한다. 크기가 어떻든 실제로 컨텍스트를 설계하고 활용할 때는 몇 가지 기술적 현실을 반드시 고려해야 한다.

• 중간 정보 손실 : 여러 연구에 따르면, LLM은 긴 컨텍스트를 다룰 때 중간 부분의 정보에 대한 주의가 약화되는 경향을 보인다. 모델은 컨텍스트 윈도의 앞부분과 뒷부분에 위치한 정보에 훨씬 더 민감하게 반응한다. 이는 단순한 오류나 결함이 아니라, 트랜스포머 아키텍처가 순차 데이터를 처리하는 구조적 특성에서 비롯된 현상이다.

• 이론적 용량 vs. 실제 처리 한계 : 컨텍스트 윈도가 12만 8,000개(128K) 토큰이라 하더라도, 모델이 모든 토큰을 동일한 정확도로 처리하는 것은 아니다. 일반적으로 약 3만 2,000~6만 4,000 토큰을 넘어서면 정확도가 점차 감소하는 경향이 있다. 이는 인간의 작업 기억(Working Memory)과 비슷하다. 머릿속에 많은 정보를 담을 수는 있지만, 실제로 효율적으로 사고하는 데에는 일부 핵심 정보에 집중하는 것이 더 효과적이다.

• 연산 비용 : 컨텍스트 길이는 지연 시간과 비용 모두에 제곱 비율로 영향을 미친다. 예를 들어 1만 토큰짜리 컨텍스트를 10만 토큰으로 늘린다고 해서 비용이 단순히 10배로 증가하지 않는다. 실제 연산 비용은 최대 100배 이상 커질 수 있다. 비록 일부 서비스 제공자가 모든 비용을 사용자에게 전가하지는 않더라도, 컨텍스트가 길어질수록 연산 부담과 비용이 기하급수적으로 늘어난다는 점은 변하지 않는다.

컨텍스트 엔지니어링에서 얻은 교훈 4가지

AI CRM 스타트업 옥톨레인(Octolane)은 AI 기반 CRM을 구축하는 과정에서 컨텍스트 엔지니어링과 관련해 4가지 중요한 교훈을 얻었다.

• 최신성과 관련성이 양보다 중요하다.

• 콘텐츠만큼 구조도 중요하다.

• 컨텍스트 계층화가 더 나은 검색을 만든다.

• 무상태(stateless)는 결함이 아니라 기능이다.

***

이제 각 항목을 구체적으로 살펴보고, 실제 적용할 수 있는 실무 팁과 효과적인 패턴, 그리고 피해야 할 비효율적 접근 방식을 정리한다.

1. 최신성과 관련성이 양보다 중요하다

가장 중요한 인사이트는 명확하다. 컨텍스트가 많다고 해서 좋은 컨텍스트가 되는 것은 아니다. 옥톨레인은 실제 운영 환경에서 컨텍스트의 양을 줄이고, 대신 관련성과 최신성을 높였을 때 모델 성능이 눈에 띄게 개선되는 것을 확인했다.

예를 들어, 지메일에서 거래 관련 정보를 추출할 때 특정 연락처와 주고받은 모든 이메일을 모델에 입력하는 것보다, 현재 진행 중인 거래와 의미적으로 연관된 이메일만 제공할 때 훨씬 더 정확한 결과를 얻을 수 있었다. 컨텍스트가 너무 많으면 모델은 핵심 신호와 잡음을 구분하지 못한다. 실제로 일부 모델은 6개월 전 전혀 다른 거래에서 언급된 날짜를 혼동해 ‘거래 종료일’을 잘못 추론하기도 했다.

2. 콘텐츠만큼 구조도 중요하다

LLM은 비구조적 데이터 덤프보다 구조화된 컨텍스트에 훨씬 더 잘 반응한다. XML 태그, 마크다운 헤더, 구분선 등 명확한 구조를 제공하면 모델이 어떤 정보에 주의를 기울여야 하는지를 더 쉽게 파악할 수 있다.

예를 들어, 다음과 같은 비구조적 컨텍스트는 모델의 이해를 방해한다.

사용자 정보 : 존 스미스, 35세, 뉴욕 거주, 피자를 좋아함, A회사 근무, 2020년 가입, 마지막 로그인은 어제

다음과 같은 컨텍스트 구조다 훨씬 더 낫다.

xml

<user_profile>

  <identity>

    <name>John Smith</name>

    <age>35</age>

    <location>New York</location>

  </identity>

  <account>

    <signup_date>2020-03-15</signup_date>

    <last_login>2024-10-16</last_login>

  </account>

  <preferences>

    <food>Pizza</food>

  </preferences>

</user_profile>

구조화된 형태는 모델이 자연어 설명을 해석하지 않고도 관련 정보를 빠르게 찾을 수 있도록 돕는다.

3. 컨텍스트 계층화가 더 나은 검색을 만든다

컨텍스트는 시간순이나 알파벳순으로 나열하기보다, 중요도와 관련성 기준으로 조직화해야 한다. 핵심 정보는 컨텍스트 창의 앞부분과 뒷부분에 배치하는 것이 가장 효과적이다. 최적의 구성 예시는 다음과 같다.

• 시스템 지시문 (시작 부분)

• 현재 사용자 질의 (시작 부분)

• 가장 관련성 높은 검색 정보 (시작 부분)

• 보조 컨텍스트 (중간 부분)

• 예시 및 예외 사례 (중간~후반부)

• 최종 지시문 또는 제약 조건 (마지막 부분)

4. 무상태는 결함이 아니라 기능이다

모든 LLM 호출은 무상태(stateless)로 작동한다. 이는 극복해야 할 한계가 아니라, 설계상 의도된 아키텍처적 선택이다. 따라서 방대한 대화 이력을 그대로 유지하려 하기보다는, 똑똑한 컨텍스트 관리 방식을 도입하는 것이 효율적이다.

• 전체 대화 상태를 애플리케이션 내에서 관리한다.

• 요청마다 필요한 관련 이력만 모델에 전송한다.

• 시맨틱 청킹(semantic chunking)을 통해 중요한 정보만 선별한다.

• 대화 요약 기능을 도입해 긴 상호작용을 효율적으로 관리한다.

***

프로덕션 시스템을 위한 실무 팁 7가지

1. 시맨틱 청킹 구현하기

전체 문서를 그대로 모델에 전달하지 말라. 의미 단위(주제, 섹션, 개념 등)로 콘텐츠를 분할해 저장하고, 임베딩을 활용해 요청 시 관련된 청크만 불러오는 방식으로 처리해야 한다.

구현 패턴 예시는 다음과 같다.

Query → Generate embedding → 

Similarity search → Retrieve top-k chunks → 

Rerank if needed → Construct context → LLM call

이 접근 방식은 일반적으로 컨텍스트 크기를 60~80% 줄이면서도 응답 품질을 20~30% 향상시키는 효과를 보인다.

2. 단계적 컨텍스트 로딩 사용하기

복잡한 질의에는 최소한의 컨텍스트로 시작하고, 필요할 때 단계적으로 추가한다.

• 첫 시도 : 핵심 지시문과 질의만 전달

• 확신이 없을 때 : 관련 문서 추가

• 여전히 불확실할 때 : 예시와 엣지 케이스 추가

이 방식은 복잡한 질의에서도 품질을 유지하면서 평균 지연 시간과 비용을 줄이는 데 도움이 된다.

3. 컨텍스트 압축 기술 활용하기

정보 손실 없이 컨텍스트를 줄이는 3가지 주요 방법이 있다.

• 엔티티 추출 : 전체 문서를 전달하는 대신, 핵심 엔티티(개체), 관계, 사실만 추출해 전송한다.

• 요약 : 과거 대화 내용은 원문 전체를 보내지 말고 요약본으로 대체한다. 이때 요약 작업은 LLM 자체를 활용해 자동화할 수 있다.

• 스키마 적용 : JSON, XML 등 구조화된 형식을 사용하면 자연어보다 훨씬 적은 토큰으로 같은 정보를 표현할 수 있다.

압축 기법은 컨텍스트 창의 효율성을 높이는 동시에, 비용 절감과 응답 품질 유지라는 2가지 목표를 동시에 달성할 수 있다.

4. 컨텍스트 창 구현하기

대화형 시스템에서는 크기가 다른 슬라이딩 창(sliding window)를 유지해 컨텍스트를 효율적으로 관리해야 한다.

• 즉시 창(immediate window) : 최근 3~5회 발화. 전체 메시지를 원문 그대로 포함한다.

• 최근 창(recent window) : 최근 10~20회 발화. 주요 요점을 요약한 형태로 저장한다.

• 히스토리 창(historical window) : 그 이전 대화. 전체 대화의 주제를 간략히 정리한 고수준 요약만 유지한다.

5. 스마트 캐싱 활용하기

최근 많은 LLM 서비스 업체가 프롬프트 캐싱(prompt caching) 기능을 지원한다. 이를 효과적으로 활용하려면 컨텍스트를 캐싱 구조에 맞게 구성해야 한다. 변하지 않는 부분(시스템 지시문, 참조 문서 등)은 앞부분에 배치해 캐시가 가능하도록 하고, 자주 바뀌는 부분(사용자 질의, 검색된 컨텍스트 등)은 캐시 경계 이후에 배치하는 것이다.

이 방식은 반복되는 요청에서 입력 토큰 비용을 50~90%까지 절감할 수 있는 효과적인 전략이다.

6. 컨텍스트 활용도 측정하기

시스템이 컨텍스트를 얼마나 효율적으로 사용하고 있는지 측정하기 위해 모니터링 지표를 도입한다. 다음 항목을 추적하면 컨텍스트 최적화 기회를 명확히 파악할 수 있다.

• 요청당 평균 컨텍스트 크기

• 캐시 적중률

• 검색된 컨텍스트의 관련성 점수

• 컨텍스트 크기에 따른 응답 품질 변화

데이터를 분석하면 과도한 컨텍스트 사용을 줄이고 효율성을 높일 수 있는 지점이 드러난다. 실제로 옥톨레인은 많은 운영 시스템이 최적값보다 2~3배 더 많은 컨텍스트를 사용하고 있다는 사실을 확인했다.

7. 컨텍스트 초과 상황을 안정적으로 처리하기

모델의 컨텍스트 용량을 초과하는 상황이 발생할 때는 단순히 잘라내는 대신, 명확한 우선순위와 예외 처리 전략을 적용해야 한다.

• 사용자 질의와 핵심 지시문을 최우선으로 유지한다.

• 앞뒤보다 덜 중요한 중간 구간을 먼저 제거한다.

• 자동 요약 기능을 활용해 초과된 부분을 압축 저장한다.

• 조용히 잘라내지 말고 명확한 오류 메시지를 반환해 상황을 알린다.

이 접근법은 정보 손실로 인한 품질 저하를 방지하고, 시스템이 예측 가능한 방식으로 컨텍스트 한계를 관리하도록 돕는다.

***

고급 패턴 3가지

1. 다중 턴 컨텍스트 관리

여러 차례 LLM 호출을 수행하는 에이전틱 시스템에서는 다중 턴 컨텍스트 관리가 핵심이다.

패턴 : 각 턴마다 누적되는 컨텍스트 누적기(Context Accumulator)를 유지하되, N번째 턴 이후에는 스마트 요약(Smart Summarization)을 적용해
컨텍스트가 무한히 커지는 것을 방지한다.

Turn 1: Full context

Turn 2: Full context + Turn 1 result

Turn 3: Full context + Summarized(Turns 1-2) + Turn 3

2. 컨텍스트 검색

검색증강생성(retrieval-augmented generation, RAG) 시스템에서는 다단계 검색을 구현해야 한다.

• 관련 문서를 검색한다.

• 문서 내부에서 관련 섹션을 검색한다.

• 섹션 내부에서 관련 문단을 검색한다.

각 단계는 초점을 좁혀 관련성을 높인다.

3. 컨텍스트 인지형 프롬프트 템플릿

사용 가능한 컨텍스트에 따라 동적으로 적응하는 템플릿을 작성한다.

if context_size < 4000:

    template = detailed_template  # Room for examples

elif context_size < 8000:

    template = standard_template  # Concise instructions

else:

    template = minimal_template  # Just essentials

피해야 할 패턴 5가지

• 전체 대화 이력을 그대로 전송하기 : 인사말, 확인 응답, 잡담 등 불필요한 내용까지 포함돼 토큰이 낭비된다.

• 필터링 없이 데이터베이스 전체를 덤프하기 : 질의와 관련된 필드만 전송해야 한다.

• 모든 메시지에 동일한 지시문 반복하기 : 지속적인 규칙은 시스템 프롬프트나 캐시된 프리픽스를 활용한다.

• 중간 정보 손실 현상을 무시하기 : 긴 컨텍스트의 중간에 핵심 정보를 배치하지 않는다.

• 최대 컨텍스트 창에 과도하게 의존하기 : 128K 토큰을 지원한다고 해서 항상 그만큼 사용할 필요는 없다.

앞으로의 전망

모델이 진화함에 따라 컨텍스트 엔지니어링은 계속해서 핵심 기술로 남을 것이다. 최근에는 다음과 같은 새로운 패턴이 부상하고 있다.

• 무한 컨텍스트 모델(Infinite Context Models) : 검색증강을 활용해 사실상 무제한 길이의 컨텍스트를 처리하는 기술

• 컨텍스트 압축 모델(Context Compression Models) : 주요 LLM에 전달하기 전에 컨텍스트를 압축·요약하는 특화 모델

• 학습 기반 컨텍스트 선택(Learned Context Selection) : 질의에 최적화된 컨텍스트를 예측·선정하는 머신러닝 모델

• 멀티모달 컨텍스트(Multi-modal Context) : 이미지, 오디오, 구조화 데이터 등을 자연스럽게 통합하는 차세대 컨텍스트 처리 방식

효과적인 컨텍스트 엔지니어링을 위해서는 LLM의 기술적 제약과 애플리케이션의 정보 아키텍처를 모두 이해해야 한다. 목표는 컨텍스트를 최대한 늘리는 것이 아니다. 적절한 정보를, 올바른 형식으로, 올바른 위치에 제공하는 것이다.

현재 시스템의 컨텍스트 활용도를 측정하고, 시맨틱 검색을 구현하며, 컨텍스트를 명확한 구조로 정리하라. 그런 다음 품질 지표를 기반으로 지속적으로 개선해야 한다. 

성공적인 시스템은 가장 많은 컨텍스트를 보내는 시스템이 아니라, 가장 관련성 높은 컨텍스트를 보내는 시스템이다.

LLM 애플리케이션의 미래는 더 큰 컨텍스트 창에 있지 않다. 더 똑똑한 컨텍스트 엔지니어링에 달렸다.