들어가며: 모델을 바꾸는 게 답이 아닐 수도 있어요

AI 에이전트를 운영하다 보면 어느 순간 청구서를 보고 놀라게 됩니다. "프로토타입에서는 이 정도가 아니었는데?" 싶죠. 대부분의 팀이 가장 먼저 하는 선택은 더 저렴한 모델로 갈아타는 겁니다. 하지만 이 선택은 곧바로 품질 저하라는 반대급부를 부릅니다.

여기서 한 가지 사실을 짚고 갈게요. 모델은 자체 메모리가 없습니다. 매 턴(turn)마다 컨텍스트 윈도우가 지시문, 도구 설명, 검색된 문서, 대화 기록을 전부 다시 공급해줘야 해요. 그리고 이 컨텍스트는 매 턴마다 다시 청구됩니다.

챗봇이 한 번 답하고 끝나는 구조라면 이 비용은 감당할 만합니다. 하지만 하나의 결과물을 향해 여러 턴을 도는 에이전트라면 이야기가 완전히 달라져요. 컨텍스트 윈도우는 에이전트 운영비의 가장 큰 항목이 되는 경우가 많습니다.

이 글에서는 Microsoft Foundry가 제안하는 컨텍스트 엔지니어링(Context Engineering) 관점에서, 에이전트를 다시 만들지 않고도 더 똑똑하고 더 저렴하게 만드는 방법을 정리해볼게요. (근거자료: The economics of agent optimization)

AI agent context window diagram showing knowledge retrieval and tool selection for enterprise cost optimization Developer Related Image

컨텍스트 윈도우가 왜 비용을 결정하는가

컨텍스트가 커지면 두 가지 비용이 발생합니다.

1) 보이는 비용: 토큰

매 턴마다 동일한 지시문, 동일한 도구 설명, 동일한 대화 기록이 재전송됩니다. 40페이지짜리 문서를 매번 프롬프트에 넣는다고 상상해보세요. 모델이 그중 한 줄만 써도, 40페이지 값은 매번 지불됩니다.

2) 안 보이는 비용: 품질

컨텍스트가 많다고 답이 좋아지지 않습니다. 오히려 반대예요.

  • 40페이지 속에 파묻힌 정답 한 줄은 찾기 어렵습니다.
  • 도구 목록이 길면 잘못된 도구를 고를 확률이 올라갑니다.
  • 잘못된 선택은 복구 턴을 만들고, 그 턴이 또 비용을 만듭니다.

그래서 컨텍스트가 리더의 관심사인 이유

대부분의 비용 절감은 트레이드오프를 동반합니다. 더 싼 모델은 품질을 깎고, 지시문을 줄이면 답이 약해지죠. 반면 불필요한 컨텍스트 제거는 품질을 깎지 않고 비용만 내리는, 팀이 설득하기 쉬운 최적화입니다.

# 예시: 컨텍스트 다이어트 전/후 비교 (의사 코드)

# ❌ Before: 매 턴마다 전체 문서 + 모든 도구 설명을 전송
def build_prompt_naive(user_query, all_docs, all_tools, history):
    return {
        "documents": all_docs,          # 40페이지 전체
        "tools": [t.description for t in all_tools],  # 도구 200개 설명
        "history": history,             # 전체 대화 기록
        "query": user_query,
    }

# ✅ After: 필요한 것만 선별해서 전송
def build_prompt_engineered(user_query, knowledge_base, toolbox, memory):
    # 1) 지식: 시맨틱 재랭킹 후 상위 근거 문단만
    passages = knowledge_base.search(user_query, top_k=5, rerank=True)

    # 2) 도구: 검색 가능한 엔드포인트만 노출 (전체 목록 X)
    tool_search_endpoint = toolbox.search_endpoint

    # 3) 메모리: 세션/사용자/절차 메모리에서 필요한 것만
    relevant_memory = memory.recall(user_query, scope=["session", "user", "procedural"])

    return {
        "grounded_passages": passages,   # 인용 포함 근거만
        "tool_search": tool_search_endpoint,
        "memory": relevant_memory,
        "query": user_query,
    }

핵심은 "이번 요청에 필요한 것"만 넣는 것입니다. "언젠가 필요할지도 모르는 것"을 다 넣지 마세요.

Cloud-based enterprise AI agent architecture with Foundry IQ knowledge base and managed tool endpoints IT Technology Image

실전 4단계: 무엇을 넣고, 무엇을 빼는가

컨텍스트 엔지니어링은 네 가지 질문으로 정리됩니다. 팀들은 보통 이 순서로 진행해요.

1단계. 에이전트가 무엇을 알아야 하는가? (지식)

많은 팀이 문서 전체를 프롬프트에 밀어 넣는 넓은 검색으로 시작합니다. 만들기는 쉽지만, 돌리기는 비쌉니다.

여기서 필요한 것이 관리형 지식 레이어입니다. Foundry IQ 같은 계층을 두면 쿼리를 서브쿼리로 분해하고, 여러 소스를 병렬 검색한 뒤, 시맨틱 재랭킹을 거쳐 인용이 포함된 근거 문단만 반환합니다. 내부 평가에 따르면 BrowseComp-Plus 벤치마크에서 근거 재현율이 최대 54% 향상, 검색 토큰 비용은 34% 절감됐다고 합니다.

2단계. 에이전트가 무엇에 닿을 수 있어야 하는가? (도구)

도구 하나 추가하는 건 코드 한 줄이지만, 그 도구의 전체 설명은 매 턴 프롬프트에 실립니다. 엔터프라이즈 에이전트는 시스템이 늘어날수록 도구가 눈덩이처럼 붙죠.

해결책은 **툴박스 + 도구 검색(Tool Search)**입니다. 모델에게 전체 목록을 주는 대신, "필요한 걸 자연어로 설명하는 방법"과 "돌아온 걸 호출하는 방법"만 줍니다. 그러면 도구 목록이 아무리 커져도 비용은 평평하게 유지됩니다. 내부 벤치마크에서는 대규모 도구 라이브러리에서 평균 입력 토큰 소비가 약 97% 감소했다고 해요.

3단계. 에이전트가 일을 어떻게 해야 하는가? (스킬)

지식과 도구는 "찾을 수 있는 것"과 "할 수 있는 것"을 다룹니다. 하지만 **"우리 회사는 이 일을 이렇게 한다"**는 다루지 않죠. 에스컬레이션 경로, 코드 리뷰 체크리스트 같은 것들입니다.

이걸 **스킬(Skill)**로 만들어 중앙에 두세요. 에이전트는 처음엔 스킬의 이름과 짧은 설명만 봅니다. 실제로 관련 있을 때만 전체 지침을 로드합니다. 절차가 바뀌면 새 버전을 배포하고 기본값으로 지정하면, 모든 에이전트가 코드 변경 없이 최신 절차를 따릅니다.

4단계. 에이전트가 무엇을 기억해야 하는가? (메모리)

대화 전체를 매번 재전송하는 건 비용이자 컨텍스트 낭비입니다. 메모리는 세 종류로 나눠서 다루세요.

  • 세션 메모리: 현재 대화용
  • 사용자 메모리: 세션을 넘어 유지되는 선호/사실
  • 절차 메모리: 학습된 워크플로우와 작업 실행 패턴

절차 메모리를 켰을 때 STATE-Bench, Tau-Bench에서 약 5% 성능 향상이 있었다는 게 Microsoft의 평가 결과입니다.

⚠️ 주의사항: 이 기술의 한계

  • 지식 레이어는 소스 최신성에 의존합니다. 인덱서 스케줄이 밀리면 에이전트는 오래된 답을 자신 있게 말합니다.
  • 도구 검색은 검색 품질에 성능이 좌우됩니다. 검색이 잘못된 도구를 반환하면, 잘못된 도구를 빠르게 호출할 뿐입니다.
  • 메모리는 프라이버시 리스크를 동반합니다. 사용자별 격리, 보존 기간, TTL 정책을 반드시 설계 단계에서 정하세요.
  • 스킬 중앙화는 조직 프로세스가 성숙해야 의미가 있습니다. 절차 자체가 매번 바뀌는 조직이라면, 스킬은 또 하나의 관리 부채가 됩니다.

Server-side agent memory and skill management system reducing inference token costs over time Software Concept Art

마무리: 에이전트는 '쓸수록 좋아지는' 시스템이어야 합니다

컨텍스트 엔지니어링의 목표는 단순히 프롬프트 크기를 줄이는 게 아닙니다. 쓸수록 좋아지는 에이전트를 만드는 것이죠.

  • 지식 베이스는 소스 시스템이 바뀌면 갱신됩니다.
  • 스킬은 정책이 진화하면 함께 진화합니다.
  • 메모리는 사용자와 성공한 워크플로우에 대해 중요한 것만 축적합니다.
  • 도구 검색은 사람들이 실제로 쓰는 기능에 적응합니다.

한국 개발 생태계에서의 적용 맥락

국내 SI·엔터프라이즈 환경에서는 이 관점이 특히 중요합니다. 프로젝트 특성상 에이전트를 한 번 만들고 오래 유지보수하는 경우가 많고, 조직별 권한 체계(Entra ID, 사내 ACL)가 복잡하게 얽혀 있거든요. 컨텍스트를 매 턴 재조립하는 구조로 만들어두면, 나중에 소스 시스템이 바뀌거나 정책이 갱신돼도 에이전트를 다시 배포하지 않고 대응할 수 있습니다. 반대로 프로토타입 단계에서 컨텍스트를 하드코딩해두면, 운영 단계에서 그 부채를 토큰 비용으로 계속 갚게 됩니다.

다음 단계 학습 방향

  1. 측정부터 하세요. 매 턴 컨텍스트에 무엇이 들어가는지 로깅하세요. 대부분 여기서 절반이 해결됩니다.
  2. 모델 교체보다 입력 개선을 먼저 시도하세요. 대개 효과가 더 크고, 되돌리기도 쉽습니다.
  3. 권한 경계를 데이터 검색 지점에 두세요. 에이전트가 접근 권한을 "물려받는" 구조가 안전합니다.

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.