언어 모델(Language model)이 접근할 수 있는 것은 단 한 가지뿐입니다: 바로 이번 호출의 컨텍스트 윈도우 (context window)에 놓여 있는 토큰 (tokens)들입니다. 모델은 당신의 지난 세션을 기억하지 못하며, 당신의 데이터베이스를 볼 수 없고, 도구 (tool)가 반환한 내용이 지금 프롬프트 (prompt)에 포함되어 있지 않다면 그 내용을 알 수 없습니다. 모델이 알고 있는 것처럼 보이는 모든 것은 시스템의 어떤 부분이 그곳에 넣기로 결정했기 때문에 존재하는 것입니다.

컨텍스트 엔지니어링 (Context engineering)은 엄격한 토큰 예산 (token budget) 하에서, 매 요청마다 이러한 결정을 잘 내리는 규율입니다. 이는 인상적인 AI 데모와 수개월 동안 실제 사용자들과 함께 유지되는 시스템을 구분 짓는 주요한 요소로 조용히 자리 잡았습니다.

왜 프롬프트 문구보다 컨텍스트가 중요한가

이제 모델의 품질은 더 이상 병목 현상 (bottleneck)인 경우가 드뭅니다. 프런티어 모델 (Frontier models)은 적절한 정보가 앞에 놓여 있을 때는 매우 유능하며, 정보가 없을 때는 예측 가능한 방식으로 실패합니다.

잘못된 환불 답변을 제공하는 고객 지원 에이전트는 대개 지식 베이스 (knowledge base)에 올바른 정책을 가지고 있었음에도 불구하고, 단순히 그것을 컨텍스트 (context)로 검색해오지 못한 것입니다. 잘못된 함수를 수정하는 코딩 어시스턴트는 대개 중요한 파일을 보여주지 못한 것입니다. 이것들은 추론 (reasoning)의 실패가 아니라 컨텍스트의 실패이며, 정답이 의존하고 있는 단 하나의 문서를 놓친 윈도우 (window)를 지시문 (instruction)을 아무리 다시 써본들 고칠 수 없습니다.

프롬프트 엔지니어링 (Prompt engineering)은 실제 기술이며, 이는 컨텍스트 엔지니어링의 하위 집합입니다. 프롬프트는 한 번 작성하여 재사용하는 정적인 텍스트입니다. 반면 컨텍스트는 런타임 (runtime)에 지시문 (instructions), 대화 기록 (conversation history), 검색된 지식 (retrieved knowledge), 장기 기억 (long term memory), 도구 정의 (tool definitions) 및 도구 결과 (tool results)를 통해 조립되며, 그 적절한 조합은 매 요청마다 달라집니다.

설계 제약 조건으로서의 토큰 예산

답변이 잘못될 때 본능적으로 하게 되는 행동은 윈도우 (window)에 더 많은 것을 넣는 것입니다. 더 큰 윈도우는 그것을 쉽게 만들지만, 이는 대개 잘못된 선택입니다.

매우 큰 윈도우 (window)를 광고하는 모델들조차 윈도우가 채워질수록 성능이 저하됩니다. 관련 있는 토큰들이 관련 없는 토큰들에 의해 희석되고, 어텐션 (attention)이 전체에 걸쳐 얇게 분산되기 때문입니다. 또한, 매 호출마다, 영원히, 모든 토큰에 대해 비용과 지연 시간 (latency)을 지불해야 합니다.

따라서 유용한 프레임워크는 저장 창고 (storage locker)라기보다는 예산 (budget)으로 보는 것입니다. 시스템 규칙 (system rules)에 할당량이 주어집니다. 실시간 대화 (live conversation)에 할당량이 주어집니다. 검색된 지식 (retrieved knowledge), 메모리 (memory), 그리고 도구 출력 (tool output)에 각각의 할당량이 주어집니다. 자신의 할당량에 맞지 않는 모든 것은 호출이 나가기 전에 요약되거나 삭제됩니다. 최적화할 가치가 있는 수치는 관련성 밀도 (relevance density)로, 윈도우 내의 토큰 중 현재 요청과 실제로 관련이 있는 토큰의 비율을 의미합니다. 단 하나의 배송 질문에 답하기 위해 매뉴얼 전체를 채워 넣은 윈도우는 관련성 밀도가 낮으며, 기술적으로는 정답을 포함하고 있을지라도 배송 섹션만 담고 있는 윈도우보다 더 나쁜 답변을 생성할 것입니다.

에이전트 (Agents)에서 컨텍스트가 실패하는 지점

에이전트 시스템은 윈도우가 움직이는 목표 (moving target)이기 때문에 이 모든 과정을 더 어렵게 만듭니다. 모든 도구 호출 (tool call)이 출력을 추가합니다. 모든 단계 (step)가 이력 (history)을 추가합니다. 20단계를 실행하는 루프는 1단계일 때와 20단계일 때의 윈도우 상태가 매우 다릅니다.

이로 인해 발생하는 실패는 간헐적이기 때문에 매우 좌절스럽습니다. 월요일에는 잘 작동하던 동일한 질문이 금요일에는 실패할 수 있는데, 이는 검색 인덱스 (retrieval index)가 커지면서 거의 중복된 문서가 올바른 문서보다 더 높은 순위를 차지하게 되었기 때문입니다. 긴 대화는 시스템 지침 (system instructions)을 윈도우 밖으로 조용히 밀어내고, 에이전트는 한 시간 전에 따랐던 규칙들을 무시하기 시작합니다. 오류가 발생하는 것은 아닙니다. 그저 출력이 나빠질 뿐입니다.

무엇을 포함할지에 대한 명시된 규칙과 윈도우의 각 부분에 대한 고정된 예산을 가진 명시적인 컨텍스트 파이프라인 (context pipeline)을 구축하면, 이러한 조용한 실패를 측정, 테스트 및 디버깅할 수 있는 대상으로 바꿀 수 있습니다.

컨텍스트 레이어로서의 메모리 (Memory)

검색 (Retrieval)은 "이 쿼리와 관련된 문서가 무엇인가"라는 질문에 답합니다. 메모리 (Memory)는 다른 질문에 답합니다: "답변의 형태를 결정해야 하는 이 사용자, 이 프로젝트, 이 작업에 대해 우리가 이미 알고 있는 것은 무엇인가?"

메모리를 단순히 또 다른 검색 인덱스 (retrieval index)로 취급하는 것이 많은 시스템이 잘못되는 지점입니다. 메모리는 한 팀의 사실이 다른 팀의 답변으로 흘러 들어가지 않도록 범위를 지정 (scoping)해야 하며, 모순을 축적하기보다는 오래된 항목을 대체할 수 있는 방법이 필요하고, 다른 모든 요소와 마찬가지로 매 호출 시 예산 (budget) 내에서 그 자리를 확보할 가치가 있어야 합니다. 이를 잘 수행한다면, 사용자가 매 세션마다 자신의 상황을 다시 설명하게 만드는 상황을 방지할 수 있으며, 이는 사람들이 조용히 어시스턴트 사용을 중단하게 만드는 가장 흔한 이유입니다.

핵심 요약 (The Takeaway)

컨텍스트 엔지니어링 (Context engineering)은 단순히 이름만 바꾼 프롬프트 튜닝 (prompt tuning)이 아닙니다. 이는 모델이 무엇을 볼지 결정하는 런타임 시스템 (runtime system)이며, 그 목표는 명확하지만 달성하기는 어렵습니다: 고정된 예산 내에서, 프로덕션 (production) 환경에서 실행될 수 있을 만큼 충분히 빠르게, 의미 있는 토큰 (tokens)의 비율을 최대한 높이는 것입니다.

만약 잘못된 출력값 때문에 디버깅 중이라면, 실패한 호출 당시 윈도우 (window) 안에 실제로 무엇이 들어 있었는지 묻는 것부터 시작하십시오. 대부분의 경우 그 답이 모든 것을 설명해 줄 것입니다.

4가지 컨텍스트 전략, 토큰 예산 (token budget), 그리고 일반적인 실패 모드 (failure modes)를 포함한 전체 분석 내용은 여기에서 확인할 수 있습니다: https://www.adaptiverecall.com/context-engineering/