컨텍스트 엔지니어링: LLM 에이전트의 정보 주입을 설계하는 법

모델의 실패는 정보 배치에서 시작될 수 있다

2025년부터 2026년까지 업계에서는 에이전트 실패를 모델 능력만의 문제로 보기 어렵다는 인식이 확산됐다. 모델에 전달하는 정보를 어떻게 구성했는지가 결과를 크게 좌우하기 때문이다.

컨텍스트를 무조건 많이 넣는다고 판단 근거가 풍부해지는 것은 아니다. 정보가 과도하면 중요한 신호가 묻히고, 반대로 너무 줄이면 모델이 판단할 근거가 사라진다. 컨텍스트가 길어질수록 출력 품질이 저하되는 context rot는 컨텍스트 창이 가득 차기 전에도 나타날 수 있다. 트랜스포머의 어텐션 계산은 시퀀스 길이에 대해 제곱으로 증가하며, 최근 토큰과 맥락의 시작 부분에 가중치가 쏠리고 중간의 지시나 사실을 놓치는 “로스트 인 더 미들” 현상으로 이어질 수 있다. 의미는 비슷하지만 작업과 무관한 정보가 판단을 흐리는 distractor interference도 같은 문제를 키운다.

따라서 핵심 질문은 정보량 자체가 아니다. 어떤 정보를 어느 시점에 어떤 형태로 넣을지 결정하는 일이 중요하다. 프롬프트 엔지니어링이 모델과의 대화 방식을 다룬다면, 컨텍스트 엔지니어링은 모델이 응답을 생성할 때 어떤 정보를 갖도록 할지를 설계한다. 프롬프트는 컨텍스트의 한 구성 요소일 뿐이다.

컨텍스트 예산에서 관측까지 이어지는 파이프라인

컨텍스트 엔지니어링은 예산을 정하고 정보를 선별하는 데서 끝나지 않는다. 수집, 분류, 압축, 만료, 기록이 이어지는 운영 구조가 필요하다.

⤢✕

명목 창 크기와 실제 예산은 다르다

예산 산정은 모델의 물리적 컨텍스트 창에서 출력 토큰 여유분, 시스템 지시문, 툴 정의처럼 고정으로 드는 비용을 제외하는 데서 시작한다. 다만 창이 넓어진다고 안전한 예산이 그만큼 늘어나는 것은 아니다. context rot를 고려하면 실제로 안정적으로 활용할 수 있는 예산은 명목 창 크기보다 훨씬 작게 잡아야 한다.

운영에서는 총 예산을 시스템·지시 영역, 작업 이력 영역, 검색·메모리 영역으로 나누고 각 영역의 상한을 둔다. 특정 기능이 컨텍스트를 계속 점유해 다른 작업의 근거가 사라지는 일을 막기 위해서다.

정보의 성격에 따라 주입 시점을 나눈다

정보는 모두 같은 기간 동안 가치를 유지하지 않는다. 사용자의 핵심 의도와 제약은 세션 내내 보존해야 하지만, 툴 호출 결과나 중간 추론 로그는 몇 턴 뒤 의미를 잃을 수 있다.

그래서 정보 범주와 주입 지점을 사전에 정의해야 한다. 계획 단계에는 목표와 제약을, 실행 단계에는 검색 결과와 툴 출력을 두고, 검증 단계에는 앞선 작업의 요약만 남기는 방식이 가능하다. 정보의 수명과 현재 작업의 관계를 기준으로 조립 순서를 정하는 구조다.

관련성 판정은 중복 제거와 함께 작동한다

단순 키워드 일치만으로 후보 정보를 고르면 필요한 근거를 놓치거나 무관한 문서를 넣기 쉽다. 임베딩 유사도, 최근성, 작업 목표와의 연결 강도를 함께 고려하는 편이 안정적이다.

대화 이력, 검색 결과, 메모리처럼 서로 다른 출처에 동일하거나 거의 동일한 정보가 존재할 수 있다. 이런 중복은 예산을 낭비할 뿐 아니라 distractor를 늘린다. 최종 컨텍스트를 조립하기 직전에 중복을 제거하는 단계가 필요한 이유다.

압축과 만료 규칙은 함께 설계한다

요약 압축은 정보가 아직 필요하지만 원문 전체를 유지할 가치는 줄었을 때 적용한다. 너무 늦으면 컨텍스트가 이미 불어나고, 너무 빠르면 이후 작업에 필요한 세부 사항을 잃는다. 턴 수나 토큰 사용량 임계치를 기준으로 압축을 자동화하는 방식이 실무에서 쓰인다.

오래된 정보는 N턴 경과, 작업 완료, 상위 목표 변경 같은 명시적 만료 규칙에 따라 폐기한다. 이런 규칙이 없으면 세션이 길어질수록 컨텍스트는 누적된 잡음으로 채워진다.

무엇을 넣었는지 기록해야 실패 원인을 찾는다

각 응답에 어떤 정보가 언제, 왜 들어갔는지 남기지 않으면 품질 저하를 사후에 분석할 수 없다. 주입 이력은 정보가 과도했는지, 필요한 근거가 빠졌는지, 압축 중 손실이 발생했는지를 구분하는 근거가 된다.

팀 도입은 현재 주입 구조를 드러내는 일부터 시작한다

조직 차원의 도입에서는 이상적인 설계보다 현재 프롬프트와 파이프라인이 실제로 무엇을 주입하고 있는지 파악하는 일이 먼저다. 입력 항목의 종류, 순서, 분량을 목록화하면 중복되거나 더는 쓸모없는 정보가 드러나는 경우가 많다.

이후 시스템 지시, 대화 이력, 검색 결과, 툴 출력 등 범주별 예산 상한을 팀 차원에서 합의한다. 합의가 없으면 각 기능이 개별적으로 예산을 잠식하고 전체 균형이 무너질 수 있다.

선별 기준도 문서화해야 한다. 관련성 점수 임계치나 최근성 가중치처럼 무엇을 포함하고 무엇을 제외할지에 대한 최소 기준이 필요하다. 동시에 정보 누락으로 발생한 실패 사례를 수집·분류해야 한다. 이 사례가 선별 기준을 조정할 실증 자료가 된다.

압축 품질 역시 운영 기준이 필요하다. 요약에서 수치, 제약 조건, 예외 사항 등 무엇을 반드시 보존해야 하는지 정하고, 압축 결과는 정기적으로 샘플 검증한다. 모델이 바뀌거나 창 크기가 확대될 때는 예산도 다시 산정해야 한다. 창이 커졌다는 이유만으로 예산을 그대로 늘리면 context rot 위험이 커질 수 있다.

마지막으로 정보 범주의 소유자와 예산 변경 승인자를 정한다. 컨텍스트는 여러 기능팀이 공유하는 자원이므로, 소유권이 불명확하면 예산 침식이 반복된다.

전량 주입과 검색, 압축의 선택 기준

전량 주입은 구현이 단순하고 초기 정확도가 준수해 보일 수 있다. 그러나 토큰 원가는 선형 이상으로 증가하며, 특정 임계치를 넘으면 context rot로 정확도가 하락할 수 있다. 선별 주입은 설계 비용이 필요하지만 작업에 필요한 토큰만 쓰므로 원가 효율이 높고, 관련성이 낮은 정보가 판단을 왜곡할 가능성을 줄인다. 반대로 선별 기준이 부실하면 필요한 근거를 누락하는 위험을 만든다.

동적 검색 주입은 필요한 시점에 필요한 정보만 가져온다. 전체 컨텍스트를 매번 채우지 않아도 되므로 적시성이 높고, 캐시 효율과 비용 측면에서 유리하다는 연구 결과가 반복적으로 보고된다. 정적 고정 주입은 항상 같은 내용을 사용해 캐시 적중률은 높지만 최신 정보를 반영하지 못할 위험이 있다.

강력한 모델과 방대한 컨텍스트 창을 가진 환경에서는 긴 컨텍스트를 통째로 넣는 방식이 검색 방식보다 높은 정확도를 보이는 사례도 있다. 다만 검색 방식은 훨씬 적은 토큰으로 근접한 성능을 내는 경우가 많다. 정확도만 보지 않고 토큰당 정확도와 캐시 재사용률까지 함께 비교해야 하는 이유다.

요약 압축과 원문 유지도 같은 방식으로 판단한다. 최근 정보나 현재 작업과 직접 연결된 정보는 원문으로 두고, 오래되었거나 완료된 하위 작업의 정보는 압축하는 계층적 접근이 균형점으로 자리 잡고 있다. 압축은 컨텍스트 여유를 만들지만 세부 정보 손실을 수반하며, 원문 유지는 손실이 없는 대신 예산을 빠르게 소진시키고 context rot 위험을 높인다.

컨텍스트 관리는 에이전트 인프라의 거버넌스가 된다

정보관리기술사의 관점에서 컨텍스트 예산 설계는 새로운 원리가 아니다. 정보 수명주기 관리의 생성·활용·보관·폐기, 데이터 관리의 품질·중복·무결성, 성능 관리의 응답 지연·처리량·비용이라는 기존 원칙을 LLM 에이전트 환경에 적용한 것이다.

정보 만료 규칙은 수명주기 관리의 폐기 단계에 대응한다. 중복 제거와 관련성 판정은 데이터 품질 관리에, 예산 산정과 캐시 효율은 성능 관리에 연결된다. 2026년의 방향은 이 관리 영역을 서로 다른 팀이 따로 다루기보다 하나의 컨텍스트 거버넌스 체계 아래 통합하는 쪽으로 수렴하고 있다.

MCP(Model Context Protocol)가 에이전트와 외부 도구·데이터를 연결하는 표준으로 자리 잡으면서, 컨텍스트 관리 역시 애드혹한 프롬프트 조정에서 벗어나 프로토콜과 거버넌스를 갖춘 인프라 계층으로 이동하고 있다. 에이전트 품질을 개선하려면 모델 변경 전에도 현재 컨텍스트가 어떤 기준과 흐름으로 조립되는지부터 확인할 필요가 있다.

Sources

• Context Engineering AI: How To Build Smarter LLM Agents In 2026
• Context Engineering: A Practical Guide for AI Agents (2026) | Sourcegraph
• State of Context Engineering in 2026 | Towards AI
• Context rot: why your AI agent gets dumber the longer it runs - DEV Community
• Context Rot: Why LLMs Degrade as Context Grows | Morph
• Context rot explained (& how to prevent it) - Redis
• Context Management for Deep Agents - LangChain
• RAG vs. Long Context Windows in 2026: When Should You Use Which? - Medium
• RAG vs Fine-Tuning vs Long Context: A 2026 Decision Method
• Why AI teams are moving from prompt engineering to context engineering - Neo4j
• Context engineering vs prompt engineering: the difference - Redis