Accelerate Edge AI Development with Foundry Local
Microsoft는 Foundry Local 1.2.0을 발표하며, 실시간 음성 텍스트 변환 API에 40개 이상의 언어를 지원하는 다국어 기능을 추가했다. 또한, ARM 기반 리눅스 시스템에서 Foundry Local을 실행할 수 있도록 지원하며, 모델 다운로드 속도를 개선하고, 모든 SDK에서 다운로드 취소 기능을 제공한다.
원문 출처
Microsoft Foundry Blog (Azure AI)
2026 상반기 RAG 검색 품질의 정석 조합이 굳어졌다. 임베딩은 최고 품질 API로 Voyage voyage-3-large, 범용으로 OpenAI text-embedding-3-large, 멀티미디어(텍스트+이미지 단일 임베딩)로 Cohere embed-v4, 다국어/교차언어로 Gemini Embedding 2가 꼽힌다. 셀프호스팅은 BGE-M3가 dense+BM25+리랭커 세 모델을 하나로 대체하는 하이브리드 모드로 현실적 1순위이고, Apache-2.0로 풀린 Qwen3-Embedding 시리즈(0.6B/4B/8B)는 8B가 MTEB 다국어 리더보드 1위(70.58, 2025-06 기준)에 100개 이상 언어를 지원해 오픈소스 진영을 끌어올렸다. 핵심 실무 원칙: 'top-50 안에는 정답 문서가 있는데 top-5에는 없다'면 더 좋은 임베딩으로 갈아타는 것보다 리랭커 추가가 더 큰 이득을 준다. 리랭커는 프로토타입엔 CPU에서 도는 무료 ms-marco-MiniLM-L-6-v2, 운영엔 Cohere rerank-v3나 BGE 리랭커를 붙이는 식으로 비용·지연·언어지원을 저울질한다.
임베딩 모델 벤치마크 순위에만 매달리는 팀이 많지만, 실제 정확도 병목은 1차 검색이 아니라 재정렬 단계에 있는 경우가 흔하다. AIPida처럼 한국어 콘텐츠를 다루면 영어 MTEB 1위보다 다국어/한국어 실측이 중요하므로, Gemini Embedding 2나 Qwen3-8B를 자체 데이터로 리랭커와 함께 A/B 하는 것이 정답에 가깝다. '임베딩 한 번 정하고 끝'이 아니라 리랭커를 별도 레버로 두는 2단 검색 구조를 기본값으로 깔아두면 모델 교체 비용 없이 품질을 끌어올릴 수 있다.
Model Context Protocol(MCP) 메인테이너가 2026년 로드맵을 공개했다. 네 가지 우선순위는 (1) 전송 계층 확장성 — 원격 HTTP 전송을 개선해 수평 확장을 가능케 하고 .well-known 메타데이터로 서버 역량을 탐색, (2) 에이전트 통신 — 장시간 작업을 다루는 Tasks 프리미티브에 재시도·만료 정책을 추가, (3) 거버넌스 성숙 — Working Group 중심으로 SEP(스펙 개선 제안) 검토를 위임, (4) 엔터프라이즈 준비 — 감사 로그·SSO 인증·게이트웨이·설정 이식성이다. 핵심은 로컬 stdio 중심에서 평범한 HTTP 인프라 위에서 스케일하는 상태 비저장(stateless) 원격 서버로 무게중심이 옮겨간다는 점이다. 한국 개발자라면 사내 MCP 서버를 round-robin 로드밸런서 뒤에 둘 수 있는지, Tasks 확장으로 장시간 잡을 어떻게 모델링할지 미리 검토할 가치가 있다.
MCP가 개인 데스크톱 통합을 넘어 멀티테넌트 프로덕션 표준으로 진화하면서, 사내 도구를 에이전트에 연결하는 아키텍처 결정이 달라진다.
Anthropic의 Claude API 프롬프트 캐싱이 2026년 2월부터 조직 단위가 아닌 워크스페이스 단위 격리로 바뀌었다. 같은 조직 안에서도 워크스페이스 간 캐시가 분리돼 데이터 경계가 명확해진다. 캐시 읽기 비용은 표준 입력가의 10% 수준이라 동일 컨텍스트를 반복 주입할 때 최대 90%를 아낄 수 있고, 기본 5분 TTL 외에 추가 비용으로 1시간 캐시도 선택할 수 있다. 긴 시스템 프롬프트, 도구 정의, RAG로 끌어온 문서 블록처럼 매 호출 동일하게 들어가는 앞부분에 cache breakpoint를 두는 것이 핵심 패턴이다. 여기에 Batch API(입·출력 50% 할인), 모델 라우팅, 컨텍스트 편집(오래된 도구 결과·thinking 블록 정리)을 결합하면 에이전트 워크로드의 토큰 비용 구조를 크게 바꿀 수 있다. 한국 팀이 다회전 대화형 서비스를 운영한다면 캐시 적중률을 KPI로 잡을 만하다.
에이전트와 RAG 서비스의 운영비 대부분이 반복 입력 토큰에서 나오므로, 캐싱 설계가 곧 마진과 직결된다.
자체 모델을 서빙할 때 어떤 추론 엔진을 고르느냐가 비용·지연·처리량을 모델 아키텍처보다 더 크게 좌우한다. vLLM은 빠른 기동과 폭넓은 모델 호환성이 강점이라 합리적인 기본값이다. SGLang은 RadixAttention(접두사 공유 KV 캐시 재사용), 커널 퓨전, 구조적 생성에 강해 공통 시스템 프롬프트나 RAG 접두사를 공유하는 워크로드, 구조화 출력에서 큰 이득을 낸다. TensorRT-LLM은 NVIDIA GPU에 깊게 최적화돼 최대 처리량을 노리지만 빌드·운영 복잡도가 높다. 실무 원칙은 단순하다 — 워크로드가 긴 공유 접두사를 자주 쓰면 SGLang을, 다양한 모델을 빠르게 띄워야 하면 vLLM을, 고정 모델로 극한 처리량이 필요하면 TensorRT-LLM을 검토한다. 어떤 경우든 자사 트래픽 패턴(입력/출력 길이 분포, 동시성)으로 직접 벤치마크해야 한다.
GPU 비용이 서비스 손익의 큰 축인 상황에서, 엔진 선택과 튜닝만으로 동일 하드웨어의 처리량을 배수로 끌어올릴 수 있다.
이 브리핑에서 궁금한 점이 있다면 먼저 질문을 남겨보세요.
첫 댓글을 남겨보세요.
매일 쏟아지는 소식 중 꼭 봐야 할 것만 골라 실무 가이드와 함께 보냅니다.
핵심 뉴스 5 · 추천 가이드 3 · 인기 Q&A