LLM 데모는 처음엔 마법처럼 느껴집니다. 이메일을 작성하고, 코드를 고치고, 심지어 휴가 예약까지 척척 해내죠. 하지만 실제 업무에 적용하려는 순간 모든 게 무너집니다. 어제 작성한 인시던트 리포트를 기억하지 못하고, 회사 내부 문서에 접근할 수 없으며, 10분 전 대화조차 까먹은 채 추측만 늘어놓습니다.

데모와 실제 프로덕션 시스템의 차이는 “더 똑똑한 모델”이 아닙니다. 차이는 어떤 정보를 선택하고, 구조화하고, 전달할 것인가에 있습니다. 바로 컨텍스트(Context) 설계입니다.

벡터 데이터베이스 기업 Weaviate가 “Context Engineering for AI Agents”라는 글을 통해 LLM 애플리케이션 개발의 핵심 과제를 정리했습니다. 프롬프트를 잘 쓰는 것만으로는 부족하며, 모델에게 올바른 정보를 적시에 제공하는 시스템 설계가 더 중요하다는 내용입니다.

출처: Context Engineering for AI Agents – Weaviate Blog

컨텍스트 윈도우, 유한한 자원

모든 LLM은 한 번에 처리할 수 있는 정보량에 제한이 있습니다. 이를 컨텍스트 윈도우라고 부르는데, 화이트보드처럼 생각하면 됩니다. 칠판이 가득 차면 오래된 내용을 지우고 새 내용을 써야 하죠. 프롬프트, 검색 결과, 도구 출력, 대화 히스토리까지 모든 것이 이 제한된 공간을 차지합니다.

문제는 컨텍스트 윈도우가 커진다고 해결되지 않는다는 겁니다. 오히려 정보가 많아질수록 새로운 실패 패턴이 등장합니다:

Context Poisoning (오염): 잘못된 정보가 한번 들어가면 에이전트가 계속 재사용하면서 오류가 누적됩니다.

Context Distraction (산만함): 과거 정보가 너무 많아서 새로운 상황을 제대로 판단하지 못하고 과거 패턴만 반복합니다.

Context Confusion (혼란): 관련 없는 도구나 문서가 섞여 들어가면서 엉뚱한 선택을 합니다.

Context Clash (충돌): 서로 모순되는 정보 사이에서 갈팡질팡합니다.

이런 문제는 더 나은 프롬프트나 더 큰 컨텍스트 윈도우로 해결되지 않습니다. 모델 주변의 시스템을 설계해야 합니다.

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

프롬프트 엔지니어링은 “어떻게 질문할 것인가”에 집중합니다. 명확한 지시, 예시 추가, “단계별로 생각해봐” 같은 기법들이죠. 중요하긴 하지만, 모델이 외부 세계와 단절된 상태라면 한계가 명확합니다.

컨텍스트 엔지니어링은 “올바른 정보를 적시에 제공하는 아키텍처”를 설계하는 작업입니다. 단절된 모델을 외부 세계와 연결하는 다리를 놓고, 데이터를 검색하고, 도구를 사용하며, 사실에 기반한 답변을 만들어내는 시스템을 구축하는 것입니다.

비유하자면, 프롬프트 엔지니어링은 질문을 잘하는 법이고, 컨텍스트 엔지니어링은 모델이 생각하기 전에 올바른 교과서, 계산기, 이전 대화 메모를 준비해두는 것입니다.

컨텍스트 엔지니어링의 6가지 핵심 요소

Weaviate는 컨텍스트 엔지니어링을 6개 구성 요소로 정리합니다:

Agents (에이전트): 전체 시스템을 조율하는 두뇌입니다. 언제 검색할지, 어떤 도구를 쓸지, 무엇을 기억할지 결정합니다. 단일 에이전트 시스템에서는 한 에이전트가 모든 파이프라인을 처리하고, 멀티 에이전트 시스템에서는 각자 전문화된 역할을 맡아 협업합니다.

Query Augmentation (쿼리 강화): 사용자의 애매한 입력을 데이터베이스나 에이전트가 이해할 수 있는 형태로 다듬습니다. “오늘 날씨 어때?”라는 질문을 위치 정보와 함께 구조화된 쿼리로 변환하는 작업이죠.

Retrieval (검색): RAG 시스템의 핵심입니다. 문서를 어떻게 쪼갤 것인가(청킹)가 가장 중요한 결정입니다. 작은 청크는 정확하지만 맥락이 부족하고, 큰 청크는 맥락은 풍부하지만 검색이 부정확해집니다. 정밀도와 맥락 사이의 균형을 찾는 게 관건입니다.

Prompting (프롬프팅): 검색한 정보를 모델이 “어떻게 사용할지” 알려주는 제어 계층입니다. 여러 출처를 종합할지, 특정 엔티티를 추출할지, 주어진 맥락만으로 답할지 명확히 지시해야 합니다.

Memory (메모리): 단일 질문을 넘어 대화를 이어가는 능력입니다. 단기 메모리는 현재 대화와 최근 도구 출력을 담고, 장기 메모리는 벡터 데이터베이스에 영구 저장됩니다. 중요한 건 “무엇을 저장할 것인가”입니다. 모든 걸 저장하면 나중에 쓸모없는 정보가 검색되어 컨텍스트를 오염시킵니다.

Tools (도구): 모델을 텍스트 세계 밖으로 끌어냅니다. 실시간 주가 확인, 이메일 발송, 데이터베이스 쿼리, 항공편 예약 등 실제 행동이 가능해지죠. 문제는 도구가 많아지면 선택이 어려워진다는 겁니다. 에이전트가 올바른 도구를 선택하고, 적절한 인자를 넘기고, 결과를 해석하는 전체 오케스트레이션이 필요합니다.

모든 건 함께 작동해야 한다

이 6가지 요소는 독립적으로 존재하지 않습니다. 강력한 에이전트도 엉망인 검색 결과를 받으면 무용지물이고, 완벽한 검색도 잘못된 프롬프트를 만나면 낭비됩니다. 좋은 프롬프트도 메모리가 없으면 대화 흐름을 잃고, 도구 없이는 실제 세계와 단절됩니다.

컨텍스트 엔지니어링은 모델에게 “말을 거는” 프롬프터 역할을 넘어, 모델이 “살아가는 세계”를 설계하는 아키텍트 역할로 전환하는 것입니다. 더 큰 모델이 더 나은 AI 시스템을 만드는 게 아니라, 더 나은 엔지니어링이 만듭니다.

Weaviate는 이런 원칙을 구현한 오픈소스 에이전틱 RAG 프레임워크 Elysia도 공개했습니다. 단순한 검색-생성 파이프라인이 아니라, 상황을 평가하고 전략을 조정하는 의사결정 트리 구조로 설계되었다고 합니다.

참고자료:

• Context Engineering Guide (eBook) – Weaviate
• Elysia GitHub Repository – Weaviate

Like?