왜 지금 '컨텍스트 엔지니어링'인가

AI 에이전트를 운영하다 보면 누구나 같은 벽에 부딪혀요. "모델을 더 싼 걸로 바꾸면 답변 품질이 떨어지고, 프롬프트를 줄이면 답이 부실해진다." 이 딜레마를 벗어나려면 비용 구조를 뜯어봐야 합니다.

에이전트의 비용은 크게 두 가지에서 나옵니다.

  • 모델 자체 비용: 우리가 고른 모델의 단가. 우리가 바꾸지 않는 한 고정이에요.
  • 컨텍스트 비용: 매 턴마다 모델에 다시 실려 나가는 입력 토큰. 여기가 대부분의 운영비를 잡아먹습니다.

모델은 학습이 끝난 순간 능력이 고정됩니다. 지시문(instruction)도 누군가 다시 쓰기 전까지 그대로죠. 하지만 에이전트가 알고, 접근하고, 기억하는 것은 실행하면서 계속 늘어납니다. 이걸 잘 설계하는 게 컨텍스트 엔지니어링이고, 결과적으로 품질을 유지하면서 비용을 낮추는 유일한 레버예요.

근거자료: The Economics of Agent Optimization: Context engineering for enterprise AI agents

모델은 기억이 없습니다

모델은 스스로 아무것도 기억하지 않아요. 매 턴마다 컨텍스트 윈도우가 다음을 다시 실어다 줍니다.

  1. 시스템 지시문
  2. 사용 가능한 도구 설명
  3. 검색된 문서
  4. 대화 히스토리

턴이 끝나면 이 컨텍스트는 사라지고, 다음 턴에 또 다시 전부 실려 나갑니다. 챗봇 한 번 답변에는 티가 안 나지만, 여러 턴을 돌며 하나의 결과물을 만드는 에이전트에서는 이게 가장 큰 지출 항목이 돼요. 컨텍스트는 매 턴 과금되니까, 불필요한 내용은 계속 청구서에 찍힙니다.

더 무서운 건 품질 비용이에요. 컨텍스트가 많다고 답이 좋아지지 않습니다. 40페이지 속에 파묻힌 정답은 오히려 찾기 어렵고, 도구 목록이 길면 엉뚱한 걸 고르기 쉬워요. 잘못 고르면 복구하느라 턴이 늘고, 턴이 늘면 비용이 늘죠.

AI agent context window diagram showing instructions, tools and memory tokens flowing per turn Software Concept Art

실전 4단계: 무엇을 컨텍스트에 넣을 것인가

컨텍스트 엔지니어링은 결국 **"이번 요청에 필요한 것만 넣는다"**는 결정입니다. 한 번 정하고 끝나는 설계가 아니라, 매 턴 드러나는 사용 패턴을 보고 계속 다듬는 작업이에요. 실무에서는 아래 네 가지 질문을 이 순서대로 다룹니다.

1) 에이전트가 '알아야' 할 것 — 지식 검색

많은 팀이 처음엔 전체 문서를 프롬프트에 밀어 넣는 방식으로 시작합니다. 만들기는 쉽지만, 돌릴 때마다 비싸고 모델이 그 속에서 한 줄짜리 정답을 찾아야 하죠.

Microsoft Foundry의 Foundry IQ는 이 부분을 관리형 지식 레이어로 대체합니다. 에이전트가 쿼리를 던지면:

[Agent Query]
   ↓
[Foundry IQ]
   ├─ 서브쿼리로 분해
   ├─ 연결된 소스 병렬 검색 (Work IQ, Fabric IQ, Web IQ,
   │   Azure Blob, SharePoint, OneLake, Azure SQL)
   ├─ 시맨틱 재정렬
   └─ 인용 포함 그라운딩 패시지 반환
   ↓
[Model Context] ← 가장 관련성 높은 근거만 주입

핵심은 재사용성과 거버넌스예요. 하나의 지식 베이스를 여러 에이전트가 공유할 수 있고, 인덱서 스케줄에 따라 증분 갱신되며, 쿼리 시점에 호출자의 Entra ID·ACL·Purview 민감도 레이블을 그대로 존중합니다. 즉, 호출자가 접근 권한을 가진 콘텐츠만 검색돼요.

내부 평가에서 Foundry IQ 지식 베이스는 BrowseComp-Plus 기준 근거 재현율을 최대 54% 향상시키고, 검색 토큰 비용은 34% 절감했습니다.

2) 에이전트가 '닿을 수 있어야' 할 것 — 툴박스

도구 오버헤드는 놓치기 쉬워요. 도구 하나 추가는 코드 한 줄이지만, 그 도구의 전체 설명은 매 턴 프롬프트에 실려 나갑니다. 안 쓰는 턴에도요. 엔터프라이즈 에이전트는 시스템이 늘어날수록 도구를 우후죽순으로 붙이게 되죠.

Foundry의 Toolboxes는 웹 검색·코드 인터프리터·파일 검색 같은 내장 도구와 커스텀 MCP 서버, OpenAPI 3.0/3.1, A2A 에이전트를 하나의 MCP 엔드포인트로 묶어줍니다. 인증·접근 정책·버전 관리를 한 곳에서 하니까, 새 버전을 승격해도 연결된 에이전트는 코드 변경 없이 그대로 씁니다.

진짜 절약은 tool search에서 나옵니다. 모델은 전체 도구 목록 대신 두 가지만 받아요.

  • 자연어로 "필요한 걸 설명하는 방법"
  • "돌려받은 걸 호출하는 방법"

이렇게 하면 툴박스가 아무리 커져도 도구 목록 비용은 평평하게 유지됩니다. 공개 오픈소스 도구 검색 데이터셋 대비 내부 벤치마킹에서, 대규모 도구 라이브러리 기준 평균 입력 토큰 소비가 약 97% 감소했어요. 추론 비용이 그대로 줄어든다는 뜻입니다.

3) 에이전트가 '일하는 방식' — 스킬

지식과 도구는 "찾을 수 있는 것"과 "할 수 있는 것"을 커버합니다. 하지만 **"우리 회사는 이 일을 이렇게 한다"**는 커버하지 않아요. 예를 들어:

  • CS 에이전트의 에스컬레이션 경로
  • 코드 리뷰 체크리스트

이런 절차는 보통 지시문에 들어가는데, 여러 에이전트에 복사되고, 매 요청에 실려 나갑니다. 관련 없을 때도요.

Skill은 이 지침을 이름 붙은 재사용 절차로 만듭니다. Foundry에 중앙 저장되고, 툴박스를 통해 에이전트에 노출돼요. 절차가 개선되면 새 버전을 기본값으로 승격하면 끝. 모든 에이전트가 코드 변경 없이 갱신된 절차를 따릅니다.

컨텍스트 절약의 비밀은 지연 로딩이에요. 에이전트는 처음엔 각 스킬의 이름과 짧은 설명만 봅니다. 관련 있을 때만 전체 지침을 로드하죠. 덕분에 상세 절차 라이브러리를 크게 키워도 매 상호작용마다 불필요한 내용이 실리지 않아요.

4) 에이전트가 '기억해야' 할 것 — 메모리

에이전트에는 연속성이 필요하지만, 모든 대화의 모든 디테일을 들고 다닐 필요는 없습니다. 전체 대화를 매번 다시 보내면 비용도 컨텍스트도 낭비예요.

Foundry Agent Service의 Memory는 세 가지를 지원합니다.

  • Session memory: 현재 대화
  • User memory: 세션을 넘어 유지되는 선호·사실
  • Procedural memory: 학습된 워크플로·작업 실행 패턴

돌아온 고객이 이전 맥락에서 이어갈 수 있고, 에이전트는 매번 재지시 없이 검증된 프로세스를 따를 수 있어요. Microsoft 평가에서 procedural memory를 켰을 때 STATE-Bench와 Tau-Bench에서 약 5% 향상이 나왔습니다. 사용자 단위 격리, 보존 설정, TTL 정책으로 저장·만료도 제어 가능하고요.

Enterprise AI agent architecture with knowledge base, toolboxes and memory layers on Microsoft Foundry Development Concept Image

주의사항: 컨텍스트 엔지니어링이 만능은 아닙니다

여기까지 읽고 "그럼 무조건 도입하면 되겠네"라고 생각했다면, 잠깐 멈춰야 해요. 실무에서 자주 밟는 지뢰들을 정리해봅니다.

1) 관리형 레이어에 대한 락인(Lock-in) 리스크

Foundry IQ, Toolboxes, Memory는 강력하지만 Microsoft 생태계에 깊이 결합됩니다. Entra ID, Purview, Fabric IQ 같은 사내 인프라가 이미 Azure 중심이라면 시너지가 크지만, 멀티클라우드나 온프레미스 비중이 높다면 오히려 통합 비용이 커질 수 있어요. LangGraph, GitHub Copilot SDK, Claude Agent SDK와 호환된다고는 하지만, "호환"과 "동일한 수준의 거버넌스"는 다른 얘기입니다.

2) 재현율 54%는 워크로드 의존적

54% 향상, 34% 절감, 97% 토큰 감소 같은 숫자는 특정 벤치마크(BrowseComp-Plus, 공개 도구 검색 데이터셋)에서의 결과예요. 사내 문서가 짧고 정형화되어 있거나, 도구가 5개 미만인 팀에서는 절감 폭이 훨씬 작을 수 있습니다. 도입 전에 자사 워크로드로 파일럿을 돌려서 실측하세요.

3) Procedural memory의 5%는 '평균'입니다

STATE-Bench/Tau-Bench에서의 5%는 특정 태스크 패밀리에서 나온 수치예요. 반복성이 낮은 창의적 태스크에서는 오히려 잘못된 절차를 학습해서 성능이 떨어질 위험이 있습니다. TTL과 사용자 격리를 적극적으로 걸어두세요.

4) '지연 로딩'은 지연을 만든다

Skill과 tool search는 컨텍스트를 줄이는 대신 한 턴을 더 씁니다. 짧은 상호작용이 많고 지연에 민감한 UX(예: 실시간 챗)에서는 오히려 체감 품질이 떨어질 수 있어요. 반대로 배치성·비동기 에이전트에서는 거의 공짜 이득입니다.

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

국내 SI·엔터프라이즈 환경에서 이 글을 읽는다면 몇 가지가 특히 중요합니다.

  • 사내 문서 접근 권한 문제: 국내 대기업은 부서별 문서 권한이 매우 촘촘하게 나뉘어 있어요. Foundry IQ의 ACL 동기화·Purview 레이블 연동은 이 문제를 상당 부분 해결하지만, 사내 AD/Entra 하이브리드 구성이 전제되어야 합니다. 온프레미스 AD만 쓰는 환경이라면 별도 설계가 필요해요.
  • 공공/금융 규제: 외부 SaaS로 데이터가 나가는 것에 민감한 업종에서는 관리형 지식 레이어 도입 자체가 심의 대상입니다. Foundry의 리전 선택과 데이터 레지던시 옵션을 먼저 확인하세요.
  • 스킬 = 사내 표준 절차서: 국내 SI 프로젝트 특성상 "표준 절차"가 문서로만 존재하고 시스템화되지 않은 경우가 많아요. Skill 기능은 이걸 코드로 옮기는 좋은 계기가 될 수 있습니다. 다만 절차 자체가 명문화되어 있지 않다면 먼저 그걸 정리해야 해요.

다음 단계 학습 방향

이 글을 다 읽었다면 다음 순서로 파보시길 권합니다.

  1. Foundry IQ 지식 베이스 하나 붙여보기 — 기존 RAG 파이프라인과 토큰 소비를 A/B로 비교
  2. Tool search 켜고 도구 목록 토큰 측정 — 도구 10개 이상인 에이전트에서 효과가 큼
  3. Skill 하나 만들어 중앙 배포 — 코드 리뷰 체크리스트처럼 반복되는 지침부터
  4. Memory TTL 정책 설계 — 개인정보·규제 관점에서 무엇을 얼마나 보관할지 먼저 결정

에이전트 옵티마이저(Agent optimizer)까지 붙이면 지시문·스킬·도구 설명을 자동으로 개선하는 루프가 완성됩니다. 하지만 그 전에 위 4단계를 수동으로 한 번 돌려보는 게 감을 잡는 데 훨씬 도움이 돼요.

Cloud cost dashboard comparing context engineering token savings for enterprise AI agents Programming Illustration

정리: 모델을 바꾸기 전에 컨텍스트를 보세요

핵심은 단순합니다.

  • 에이전트 운영비의 대부분은 매 턴 다시 실려 나가는 컨텍스트에서 나옵니다.
  • 컨텍스트를 줄이는 건 품질을 깎지 않고도 비용을 낮출 수 있는 드문 최적화예요.
  • 네 축 — 지식(Foundry IQ) / 도구(Toolboxes) / 절차(Skills) / 기억(Memory) — 을 순서대로 다듬으면 에이전트가 쓸수록 좋아집니다.

가장 빠른 시작은 이거예요. "지금 매 턴 컨텍스트에 뭐가 들어가는지" 한 번 나열해보세요. 검색되는 문서, 노출되는 도구, 반복되는 지시문, 실려 나가는 대화 히스토리. 대부분의 팀에서 모델을 바꾸는 것보다 이 목록을 다듬는 게 비용과 품질에 더 큰 임팩트를 줍니다.

함께 보면 좋은 글

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