기업용 컨텍스트(Enterprise Context)가 새로운 AI 플랫폼 락인(Lock-in)이 되고 있다

Microsoft Build 2026에는 평소와 다름없는 출시 소식들이 가득했습니다. 더 많은 에이전트(Agents), 더 많은 Copilot 접점, 더 많은 모델 선택권, 그리고 당신의 백로그(Backlog)가 곧 자아를 갖게 될 것처럼 가장할 수 있는 더 많은 이유들이 등장했습니다.

제가 계속해서 주목하게 되는 부분은 Microsoft IQ입니다.

이름이 훌륭해서가 아닙니다. 너무 많은 커피를 마시며 진행된 회의에서 만들어진 대시보드 지표처럼 들리기 때문입니다.

하지만 제품의 형태가 중요합니다. Microsoft는 조직의 컨텍스트(Context)를 에이전트를 위한 플랫폼 레이어(Platform layer)로 전환하고 있습니다. Microsoft 365 신호를 위한 Work IQ, 비즈니스 데이터를 위한 Fabric IQ, 애플리케이션 및 에이전트 컨텍스트를 위한 Foundry IQ, 그리고 최신 웹 그라운딩(Web grounding)을 위한 Web IQ가 그것입니다. Work IQ API는 6월 16일에 일반 가용성(General availability)이 예정되어 있으며, 라이선스 페이지에 따르면 API 사용량은 Copilot Credits를 통해 청구됩니다.

이것이 진짜 발표입니다.

기업용 AI 플랫폼은 더 이상 모델만이 아닙니다. 모델 주변의 컨텍스트 레이어(Context layer)입니다.

그리고 컨텍스트는 강력한 고착성(Sticky)을 가집니다.

모델 교체는 점점 더 쉬워지고 있다

지난 2년 동안 많은 AI 전략은 마치 모델 조달(Procurement)처럼 들렸습니다.

어떤 모델이 가장 좋은가? 어떤 제공업체가 가장 긴 컨텍스트 윈도우(Context window)를 가지고 있는가? 어떤 벤치마크(Benchmark)를 신뢰해야 하는가? 요약 작업에 가장 저렴한 모델은 무엇인가? 어떤 모델이 React 코드를 더 잘 작성하는가? 어떤 모델이 고객 데이터를 볼 수 있도록 허용되는가?

이러한 질문들은 여전히 중요하지만, 결정적인 요소로서의 비중은 줄어들고 있습니다.

대형 플랫폼들은 모두 모델 라우팅(Model routing)을 향해 움직이고 있습니다. Microsoft는 OpenAI, Anthropic, 자체 MAI 모델 및 기타 제공업체에 걸친 모델 다양성에 대해 공개적으로 이야기합니다. GitHub와 클라우드 플랫폼들 또한 서로 다른 에이전트가 서로 다른 작업에 대해 서로 다른 모델을 사용할 수 있다는 개념을 점점 더 자연스럽게 받아들이고 있습니다.

그것은 합리적인 방향입니다. 기업은 자신의 전체 엔지니어링 워크플로우 (engineering workflow)를 영원히 단일 모델에만 걸 수는 없습니다. 모델은 개선되고, 가격은 변하며, 지연 시간 (latency)이 변하고, 리스크 프로필 (risk profiles)이 변하며, 어떤 작업들은 단순히 서로 다른 트레이드오프 (tradeoffs)를 필요로 하기 때문입니다.

하지만 모델을 교체하기가 더 쉬워진다면, 지속적인 락인 (lock-in) 효과는 다른 곳으로 이동합니다.

그것은 기업을 알고 있는 레이어 (layer)로 이동합니다.

컨텍스트 (context)가 기업이 존재하는 곳이다

기업용 소프트웨어는 대부분 로컬 진실 (local truth)입니다.

아키텍처 다이어그램 (architecture diagram)은 유용하지만, 진짜 규칙은 마이그레이션 노트 (migration note)에 있습니다. 로드맵 (roadmap)은 한 가지를 말하지만, 고객 에스컬레이션 스레드 (customer escalation thread)는 다른 것을 말합니다. 공개 API 계약 (public API contract)은 문서에 있지만, 중요한 예외 사항은 2023년의 풀 리퀘스트 (pull request) 속에 파묻혀 있습니다. 컴플라이언스 요구 사항 (compliance requirement)은 감사 주간 전까지는 아무도 읽지 않는 정책 문서에 있습니다. 팀의 결정은 회의에서 이루어졌고, 그 후 Teams에서 절반만 요약되었으며, 이내 흥미로운 문장이 삭제된 Jira 티켓 (Jira ticket)이 됩니다.

이것이 바로 범용 에이전트 (generic agents)가 실제 조직 내부에서 한계에 부딪히는 이유입니다.

그들은 코드를 작성할 수 있습니다. API를 설명할 수 있습니다. 웹을 검색할 수 있습니다. 좋은 프롬프트 (prompt)가 갖춰진 깨끗한 저장소 (repository) 안에서는 인상적일 수 있습니다.

하지만 대부분의 유용한 기업 업무는 누가 무엇을 결정했는지, 어떤 시스템이 어떤 동작을 소유하고 있는지, 조직이 무엇을 할 수 있도록 허용되는지, 그리고 기이한 예외 사항들이 어디에 존재하는지를 아는 것에 달려 있습니다.

Microsoft IQ는 이 문제에 정면으로 대응한다는 점에서 흥미롭습니다. 공식적인 프레임워크 (framing)는 에이전트와 Copilot 상호작용이 조직에 대한 공유된 이해를 바탕으로 이루어지는 통합 지능 레이어 (unified intelligence layer)입니다. Work IQ는 권한 및 거버넌스 제어 (governance controls)를 유지하면서 Microsoft 365 컨텍스트 (context)를 노출합니다. Web IQ는 외부 지식에 대해 MCP 네이티브 그라운딩 (MCP-native grounding)을 제공합니다.

이것은 단순히 더 나은 검색 (retrieval)이 아닙니다.

이것은 벤더 (vendor)가 다음과 같이 말하는 것입니다: 당신의 에이전트는 우리가 만든 당신 회사의 지도(map)를 통해 사고해야 합니다.

이것은 유용하면서도 불편하다

나는 이것이 나쁜 기술인 것처럼 꾸미고 싶지는 않습니다.

만약 귀사가 이미 Microsoft 365 환경에서 업무를 수행하고 있다면, 이메일, 캘린더, Teams, SharePoint, OneDrive, 문서, 조직 관계 및 기존 권한(permissions)을 이해하는 컨텍스트 계층(context layer)은 진정으로 유용합니다.

프로젝트를 돕는 에이전트(agent)라면 결정이 내려졌던 회의 내용을 알고 있어야 합니다. 재무 팀이 진실의 원천(source of truth)으로 취급하는 파일이 무엇인지도 알아야 합니다. 또한 인간 직원이 가진 것과 동일한 액세스 제어(access controls)를 준수해야 합니다. 모델이 "이 마이그레이션의 현재 계획은 무엇인가요?"라는 질문에 답할 수 있도록 모든 팀에게 엔터프라이즈 검색(enterprise search)을 처음부터 다시 구축하라고 요구해서는 안 됩니다.

이것이 긍정적인 버전입니다.

불편한 버전은 컨텍스트(context)가 모델 엔드포인트(model endpoint)가 이동 가능한 방식처럼 이식(portable) 가능하지 않다는 점입니다.

일단 여러분의 에이전트가 Work IQ 시맨틱(semantics), Microsoft 365 권한, Copilot 크레딧(Copilot Credits), Fabric 온톨로지(ontologies), 관리 제어(admin controls), MCP 도구(tools), 그리고 어떤 내부 사실이 중요한지를 결정하는 각종 랭킹 로직(ranking logic)에 의존하게 되면, 여러분은 단순한 앱 이상의 것을 구축한 것입니다. 여러분은 귀사의 조직에 대한 벤더(vendor)의 해석 위에 구축한 것입니다.

그럴 만한 가치가 있을 수도 있습니다.

하지만 그것은 여전히 락인(lock-in)입니다.

락인은 항상 함정인 것은 아니다

엔지니어들은 때때로 락인을 마치 자동으로 도덕적 실패인 것처럼 이야기하곤 합니다.

그것은 너무 단순한 생각입니다.

모든 유용한 추상화(abstraction)는 어느 정도의 락인을 만들어냅니다. Postgres는 여러분을 Postgres의 동작 방식에 락인시킵니다. Kubernetes는 여러분을 Kubernetes의 개념에 락인시킵니다. Stripe는 여러분을 Stripe의 결제 모델에 락인시킵니다. GitHub은 여러분을 GitHub의 풀 리퀘스트(pull request) 워크플로우에 락인시킵니다. 질문은 "락인이 있는가?"가 아닙니다. 질문은 "그 가치가 탈출 비용(exit cost)을 감수할 만큼 충분한가?"여야 합니다.

기업용 컨텍스트 플랫폼의 경우, 탈출 비용은 팀이 예상하는 것보다 더 높을 수 있습니다.

하나의 LLM API에서 다른 API로 이동하는 것은 번거롭지만, 대비가 되어 있다면 관리 가능한 수준입니다. 하나의 벡터 스토어(vector store)에서 다른 곳으로 이동하는 것 역시 번거롭지만, 적어도 데이터 형태(data shape)는 어느 정도 가시적입니다.

에이전트의 신경계(nervous system)가 되어버린 컨텍스트 계층으로부터 벗어나는 것은 훨씬 더 어렵습니다.

정확히 무엇을 내보낼(export) 수 있을까요? 문서(Documents)는 가능합니다. 캘린더 이벤트(Calendar events)도 가능합니다. 메시지(Messages)는 아마도 가능할 것입니다. 권한 모델(Permission models), 조직 그래프(Organizational graphs), 랭킹 동작(Ranking behavior), 암묵적 관계(Implicit relationships), 액세스 체크(Access checks), 도구 정의(Tool definitions), 기술(Skills), 정책(Policies), 그리고 사용 이력(Usage history)은 어떨까요? 바로 이 지점에서 상황이 복잡해집니다.

시스템의 가장 가치 있는 부분은 단순히 원시 데이터(Raw data)만이 아닙니다. 플랫폼이 런타임(Runtime)에 원시 데이터를 사용 가능한 컨텍스트(Context)로 어떻게 전환하느냐 하는 것입니다.

그 런타임 동작은 재현하기 어렵습니다.

컨텍스트 거버넌스(Context governance)가 플랫폼 업무가 된다

실질적인 질문은 기업이 Microsoft IQ를 사용해야 하는가 하는 것이 아닙니다. 많은 기업이 사용할 것이며, 그럴만한 타당한 이유도 있습니다.

실질적인 질문은 컨텍스트 계층(Context layer)을 누가 소유하느냐 하는 것입니다.

에이전트(Agents)가 회사의 메모리(Company memory)를 바탕으로 추론(Reasoning)하게 된다면, 컨텍스트는 마법 같은 백엔드 기능처럼 취급되어서는 안 됩니다. 플랫폼 차원의 소유권이 필요합니다.

누군가는 다음과 같은 지루한 질문들에 답해야 합니다:

어떤 데이터 소스가 에이전트의 근거(Grounding)로 허용되는가?
어떤 에이전트가 Work IQ, Web IQ, Fabric IQ 또는 커스텀 MCP 서버를 사용할 수 있는가?
권한은 어떻게 상속되고 감사(Audit)되는가?
에이전트가 오래된(Stale) 컨텍스트를 인용하면 어떻게 되는가?
어떤 팀이 에이전트 환경에 도구(Tools)나 기술(Skills)을 게시할 수 있는가?
사용량은 어떻게 청구되고, 예산이 책정되며, 설명되는가?
컨텍스트 제공자(Context provider)를 사용할 수 없을 때의 폴백(Fallback) 경로는 무엇인가?
검색된 컨텍스트가 충분히 좋았는지 어떻게 테스트하는가?

이러한 질문들은 운영(Operational)적인 질문처럼 들리는데, 실제로 그렇기 때문입니다.

모든 팀이 가장 쉬운 컨텍스트 소스에 에이전트를 직접 연결하도록 방치했다가, 1년 뒤에 어떤 에이전트가 무엇을 알고 있는지 아무도 설명할 수 없다는 사실을 깨닫는 것이 바로 실수입니다.

그렇게 되면 "AI 도입(AI adoption)"은 또 다른 기업 고고학(Enterprise archaeology) 프로젝트가 되어버립니다.

Microsoft만이 이를 수행하고 있는 것은 아니다

Microsoft는 이번 주에 나타난 가장 명확한 사례일 뿐입니다.

AWS는 에이전트 툴링 (agent tooling)을 IAM, CloudTrail, CloudWatch, 관리형 MCP (managed MCP), 문서 검색 (docs retrieval), 그리고 샌드박싱 (sandboxing)과 함께 패키징하고 있습니다. GitHub은 API를 통해 클라우드 에이전트 설정 (cloud-agent configuration)을 노출하고 있습니다. Docker는 이미지와 MCP 서버를 강화 (hardening)하고 있습니다. 모두가 동일한 진실로 수렴하고 있습니다: 에이전트에게는 통제된 컨텍스트 (governed context), 도구 (tools), 권한 (permissions), 로그 (logs), 그리고 런타임 경계 (runtime boundaries)가 필요하다는 것입니다.

모델 (model)은 화려한 부분입니다.

플랫폼 (platform)은 기업이 실제로 구매하는 부분입니다.

이것이 바로 "모델 불가지론적 (model-agnostic)"이라는 주장을 주의 깊게 읽어야 하는 이유이기도 합니다. Web IQ가 MCP 네이티브 (MCP-native)이면서 모델 불가지론적이라는 점은 유용합니다. 이는 반드시 하나의 추론 제공자 (inference provider)에 종속되지 않음을 의미합니다. 하지만 모델 불가지론적인 컨텍스트 레이어 (context layer)라 할지라도 여전히 컨텍스트 락인 (context lock-in)이 될 수 있습니다.

두뇌 (brain)는 교체할 수 있을지 모릅니다.

하지만 메모리 (memory)는 교체할 수 없을지도 모릅니다.

표준화하기 전에 내가 할 일

만약 내가 실제 기업 내부에서 이것을 평가한다면, 거창한 AI 아키텍처 다이어그램부터 시작하지는 않을 것입니다.

컨텍스트가 명백한 병목 현상 (bottleneck)인 단 하나의 워크플로우 (workflow)부터 시작할 것입니다.

아마도 지원 에스컬레이션 요약 (support escalation summaries)일 수도 있고, 엔지니어링 설계 검토 (engineering design reviews)일 수도 있습니다. 혹은 규제 준수가 중요한 제품 변경 (compliance-heavy product changes)이나 내부 개발자 온보딩 (internal developer onboarding)일 수도 있습니다. 에이전트가 단순한 웹 검색이나 코드베이스가 아닌, 실제 조직의 기억 (organizational memory)을 필요로 하는 항목을 선택하십시오.

그런 다음, 화려하지 않은 요소들을 측정하십시오.

에이전트가 올바른 소스 문서를 찾았는가? 권한을 준수했는가? 유용한 근거를 인용했는가? 중요한 컨텍스트를 놓치지는 않았는가? 관련 없는 노이즈를 너무 많이 검색하지는 않았는가? 인간이 답변을 더 신뢰하게 되었는가, 아니면 답변을 검증하는 데 똑같은 시간을 소비했는가? 해당 워크플로우가 Copilot 크레딧 (Copilot Credits)이나 그에 상응하는 사용 단위 측면에서 비용이 얼마나 들었는가?

가장 중요한 것은: 당신이 만들고 있는 의존성 (dependency)을 문서화하는 것입니다.

어떤 API가 이제 임계 경로 (critical path)에 있는가? 어떤 데이터 소스가 중요한가? 어떤 관리자 설정이 보안 경계 (security boundary)를 정의하는가? 어떤 벤더 특유의 의미론 (vendor-specific semantics)이 교체하기 고통스러울 것인가?

이것은 벤더에 대한 피해망상이 아닙니다. 기본적인 엔지니어링 위생 (engineering hygiene)입니다.

결론

Microsoft IQ는 기업용 AI가 어디로 향하고 있는지를 보여주는 좋은 신호입니다.

승리하는 플랫폼은 단순히 더 나은 모델만을 제공하지 않을 것입니다. 그들은 기업 내부의 무질서하고, 권한이 필요하며, 끊임없이 변화하는 컨텍스트 (Context)에 더 나은 접근성을 제공할 것입니다.

그것은 유용합니다. 또한 차세대 락인 (Lock-in)이 존재하게 될 지점이기도 합니다.

과거의 클라우드 락인 (Cloud lock-in)이 컴퓨팅 (Compute), 스토리지 (Storage), 데이터베이스 (Databases), 그리고 배포 파이프라인 (Deployment pipelines)이었다면, 새로운 AI 락인 (AI lock-in)은 조직의 기억 (Organizational memory), 도구 권한 (Tool permissions), 그라운딩 동작 (Grounding behavior), 그리고 이러한 요소들을 사용 가능하게 만드는 에이전트 런타임 (Agent runtime)입니다.

그러니 맞습니다, 컨텍스트 레이어 (Context layer)를 사용하십시오. 조직을 이해하지 못하는 범용 어시스턴트 (Generic assistant)는 진지한 업무를 수행하기에는 너무 얕을 것입니다.

하지만 컨텍스트를 공짜 재료처럼 취급하지 마십시오.

이제 컨텍스트는 인프라 (Infrastructure)입니다.

그리고 일단 당신의 에이전트 (Agents)가 컨텍스트에 의존하게 되면, 그것은 다른 모든 인프라 조각들과 마찬가지로 다음과 같은 지루하지만 중요한 주의를 기울일 가치가 있습니다: 소유권 (Ownership), 관측 가능성 (Observability), 비용 제어 (Cost controls), 보안 경계 (Security boundaries), 이식성 계획 (Portability plans), 그리고 컨텍스트가 거짓 정보를 제공할 때 어떤 일이 발생하는지에 대한 명확한 이해 말입니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.