긴 컨텍스트는 AI 메모리가 아닙니다: 신뢰할 수 있는 AI 앱을 구축하기 위한 빌더 플레이북

현재 가장 쉬운 AI 실수는 거대한 컨텍스트 윈도우 (context window)를 실제 메모리 시스템처럼 취급하는 것입니다. 이는 합리적으로 느껴질 수 있습니다. 모델이 수십만 또는 수백만 개의 토큰을 수용할 수 있다면, 문서, 로그, 리포지토리 (repo), 채팅 기록을 모두 붙여넣고 모델이 알아서 정리하게 하면 되지 않을까요?

하지만 그 대가는 신뢰성 (reliability) 측면에서 치르게 됩니다.

이번 주의 새로운 신호는 단순히 하나의 제품 출시가 아닙니다. 그것은 하나의 패턴입니다. 빌더들은 Hacker News에서 컨텍스트 부패 (context rot)에 대해 이야기하고 있고, 반복적인 프롬프트 (prompt) 비용이 비싸기 때문에 LMCache와 같은 인프라 프로젝트가 트렌드가 되고 있으며, 에이전트 (agent) 생태계가 이제 심각한 신뢰 문제를 동반하며 기술과 도구를 설치함에 따라 NVIDIA의 SkillSpector와 같은 보안 도구들이 등장하고 있습니다. 메시지는 간단합니다. AI 앱은 프롬프트 데모 단계에서 시스템 엔지니어링 (systems engineering) 단계로 이동하고 있습니다.

컨텍스트 윈도우는 데이터베이스가 아니라 작업 공간입니다

큰 컨텍스트 윈도우는 유용합니다. 모델이 더 많은 소스 파일을 검사하고, 더 긴 문서를 비교하며, 더 많은 작업 상태 (task state)를 시야에 유지할 수 있게 해줍니다. 하지만 그것은 여전히 일시적인 작업 공간입니다. 그것은 내구성이 있는 저장소 (durable store), 랭킹 엔진 (ranking engine), 권한 모델 (permission model), 또는 모델이 모든 세부 사항을 똑같이 잘 사용할 것이라는 보장이 아닙니다.

이러한 차이점은 빌더들에게 중요합니다. 만약 당신의 앱이 모든 것을 프롬프트에 쑤셔 넣는다면, 당신은 모델이 기억하기, 검색하기, 우선순위 정하기, 추론하기라는 네 가지 작업을 동시에 해결하기를 기대하는 것입니다. 때로는 작동합니다. 하지만 실제 운영 환경의 부하 속에서, 지저분한 사용자 데이터와 장기 실행 세션이 결합되면 시스템은 취약해집니다.

더 건강한 설계는 컨텍스트를 책상 위의 화면 공간처럼 취급하는 것입니다. 가장 관련성이 높은 것들을 모델 앞에 두십시오. 나머지는 인덱싱 (indexed), 검색 가능 (retrievable), 요약 (summarized) 또는 캐싱 (cached)된 상태로 유지하십시오. 작업이 변경되면 전체 이력을 영원히 끌고 가는 대신 작업 공간을 새로 고침하십시오.

사용자가 더 큰 컨텍스트로부터 실제로 얻는 것

더 큰 컨텍스트는 여전히 실질적인 역량입니다. 사용자들은 더 적은 급격한 정보 차단(hard cutoffs), 더 나은 긴 문서 워크플로우(long-document workflows), 그리고 다단계 작업(multi-step tasks)을 위한 더 많은 여유 공간을 얻게 됩니다. 개발자들은 정책 팩(policy pack)을 읽거나, 의존성 트리(dependency tree)를 조사하거나, 모든 것을 즉시 아주 작은 조각으로 분할(chunking)하지 않고도 여러 개의 긴 전사 데이터(transcripts)를 비교하는 어시스턴트를 구축할 수 있습니다.

약점은 더 크다고 해서 자동으로 더 정교해지는 것은 아니라는 점입니다. 긴 프롬프트(prompt)는 오래된 메시지, 중복된 사실, 무관한 로그, 그리고 상충하는 예시들 아래에 중요한 지침(instruction)을 묻어버릴 수 있습니다. 고객 지원 봇은 오래된 정책 단락을 바탕으로 답변할 수 있습니다. 코딩 어시스턴트는 버그가 수정된 후에도 이전의 스택 트레이스(stack trace)에 집착할 수 있습니다. 연구 어시스턴트는 프롬프트의 끝부분에 더 가깝다는 이유로 더 약한 출처를 인용할 수도 있습니다.

그렇기 때문에 승리하는 제품 경험은 "우리는 거대한 컨텍스트 윈도우(context window)를 지원합니다"가 아닙니다. 그것은 "우리는 컨텍스트 윈도우에 무엇을 넣어야 할지, 언제 제거해야 할지, 그리고 답변이 올바른 근거로부터 나왔음을 어떻게 증명할지를 알고 있습니다"입니다.

실질적인 컨텍스트 예산 (A practical context budget)

대부분의 AI 앱을 구축한다면, 컨텍스트를 한꺼번에 쏟아붓는(context dump) 대신 컨텍스트 예산(context budget)을 설정하는 것부터 시작할 것입니다:

작업 계약(task contract)을 고정하십시오. 사용자의 현재 목표, 제약 조건, 출력 형식(output format), 그리고 안전 규칙을 짧고 안정적으로 유지하십시오.
최상위 근거만 검색하십시오. 검색(search), 메타데이터 필터(metadata filters), 임베딩(embeddings), 또는 명시적인 사용자 선택을 사용하여 중요한 소수의 문서만을 가져오십시오.
오래된 상태를 요약하십시오. 긴 대화는 모든 메시지를 영원히 가져가는 것이 아니라, 오래된 결정 사항들을 실행 중인 요약본(running brief)으로 압축해야 합니다.
사실과 지침을 분리하십시오. 검색된 문서들은 데이터로 취급되어야 하며, 모델이 반드시 따라야 하는 명령(command)으로 취급되어서는 안 됩니다.
컨텍스트 실패를 측정하십시오. 누락된 사실, 잘못된 출처의 답변, 오래된 메모리, 그리고 지침 충돌에 대한 테스트를 추가하십시오.

이것은 화려하지는 않지만, 영리한 데모와 사람들이 실제 업무를 믿고 맡길 수 있는 도구 사이의 차이를 만듭니다.

캐싱(caching)이 아키텍처의 일부가 되고 있는 이유

LMCache와 같은 프로젝트는 또 다른 실질적인 문제를 지적합니다. 즉, 반복적인 롱 컨텍스트 (long-context) 작업은 비용이 많이 든다는 점입니다. 만약 귀하의 애플리케이션이 동일한 매뉴얼, 코드베이스 (codebase), 계약서 또는 지식 베이스 (knowledge base)를 모델에 반복적으로 전송한다면, 지연 시간 (latency)과 연산 비용 (compute costs)을 계속해서 지불하게 됩니다.

캐싱 (caching)이 검색 (retrieval)이나 정교한 프롬프팅 (prompting)의 필요성을 없애는 것은 아니지만, 경제적 구조를 변화시킵니다. 첫 번째 통과 시 비용이 많이 드는 롱 컨텍스트는 시스템이 중간 상태 (intermediate state)를 재사용할 때 더 사용하기 쉬워질 수 있습니다. 내부 도구, 고객 지원, 코드 리뷰 및 문서 중심의 워크플로우 (workflows)의 경우, 이는 AI를 "인상적이지만 느린" 단계에서 "하루 종일 사용하기에 충분히 빠른" 단계로 전환할 수 있습니다.

빌더의 질문은 단지 "어떤 모델이 가장 큰 컨텍스트 윈도우 (context window)를 가지고 있는가?"에 그쳐서는 안 됩니다. "내 워크로드 (workload) 중 어떤 부분이 반복되는가, 그리고 어떻게 하면 그것들을 재연산하는 것을 피할 수 있는가?"가 되어야 합니다.

에이전트 기술 (Agent skills)에도 보안 검토가 필요합니다

컨텍스트 엔지니어링 (context engineering)의 다른 측면은 도구 신뢰성 (tool trust)입니다. AI 에이전트 (agents)는 점점 더 기술 (skills), 커넥터 (connectors), MCP 서버, 브라우저 액션 (browser actions), 셸 명령 (shell commands) 및 워크플로우 레시피 (workflow recipes)를 로드하고 있습니다. 이는 에이전트를 유용하게 만들지만, 동시에 공격 표면 (attack surface)을 확장합니다.

NVIDIA의 SkillSpector는 에이전트 기술을 소프트웨어 공급망 아티팩트 (software supply chain artifacts)처럼 취급한다는 점에서 흥미롭습니다. 그것이 올바른 사고 모델 (mental model)입니다. 기술에는 프롬프트 인젝션 (prompt injection), 데이터 유출 (data exfiltration), 안전하지 않은 셸 동작 (unsafe shell behavior) 또는 과도한 권한이 숨겨져 있을 수 있습니다. 만약 귀하의 에이전트가 파일을 읽거나, API를 호출하거나, 리포지토리 (repo)를 수정할 수 있다면, 기술을 설치하는 것은 해롭지 않은 프롬프트를 복사하는 것보다 플러그인 (plugin)을 설치하는 것에 더 가깝습니다.

에이전트를 사용하여 구축하는 팀의 경우, 기본 원칙은 간단해야 합니다. 기술을 설치하기 전에 검토하고, 권한을 제한하며, 도구 호출 (tool calls)을 기록하고, 신뢰할 수 없는 지침으로부터 사용자 데이터를 격리하는 것입니다. 편의성이 조용한 자율성 (silent agency)을 맞바꿀 만큼 가치 있지는 않습니다.

빌더를 위한 시사점

AI 앱의 가까운 미래는 컨텍스트 크기만으로 승리하지 못할 것입니다. 컨텍스트 규율 (context discipline)이 승패를 결정할 것입니다.

도움이 될 때는 큰 컨텍스트 윈도우 (large windows)를 사용하세요. 하지만 어텐션 (attention)은 부족하고, 메모리 (memory)는 불완전하며, 지연 시간 (latency)이 중요하고, 도구 (tools)는 위험할 수 있다는 가정하에 설계하십시오. 그러한 사고방식이 더 나은 앱을 만들어냅니다. 즉, 올바른 출처를 인용하는 어시스턴트, 경로를 이탈하지 않는 에이전트 (agents), 최신 상태를 유지하는 지원 봇 (support bots), 그리고 첫 번째 인상적인 데모 이후에도 유용하게 유지되는 개발자 도구 (developer tools)를 만드는 것입니다.

긴 컨텍스트 (Long context)는 강력한 작업 공간입니다. 하지만 신뢰할 수 있는 AI 제품에는 여전히 아키텍처 (architecture)가 필요합니다.

참고 문헌 (References)

원문 게시 위치: https://blog.jenuel.dev/blog/long-context-is-not-ai-memory-builder-playbook