서문
마이크로소프트 CEO 사티아 나델라는 모든 업무를 단일 AI 플랫폼에 표준화하려는 기업들에게 경고를 보냈다. 가장 큰 위험은 모델 품질이나 토큰 가격이 아니라, 회사의 가치 자체를 구성하는 지식에 대한 통제권을 잃는 데 있을 수 있다는 것이다.
2026년 7월 26일 CNN의 '파리드 자카리아 GPS' 프로그램과의 인터뷰에서 나델라는 기업이 직원들이 AI를 사용하는 과정에서 생성된 데이터, 프롬프트, 메타데이터, 맥락, 기억 및 오케스트레이션 계층에 대한 소유권을 보유해야 한다고 주장했다.
그의 우려는 매우 직설적이다.
기업이 AI를 일상 업무에 더 깊이 통합할수록, 조직이 실제로 어떻게 운영되는지에 대한 정보를 시스템에 더 많이 제공하게 된다: 팀이 어떻게 고객에게 서비스를 제공하는지, 관리자가 어떻게 결정을 내리는지, 엔지니어가 어떻게 제품을 디버깅하는지, 분석가가 어떻게 위험을 평가하는지, 직원이 어떻게 불완전한 모델 출력물을 수정하는지 등이다.
시간이 지남에 따라 이러한 상호작용은 회사 운영 지식의 디지털 기록으로 점차 형성된다.
이 기록이 특정 모델 제공업체의 독점 제품에만 존재한다면, 나중에 공급업체를 변경하는 것은 챗봇 통합을 넘어 훨씬 더 많은 것을 재구축해야 함을 의미할 수 있다.

나델라가 제시한 해결책은 모든 회사가 자체 최첨단 기반 모델을 훈련하도록 하는 것이 아니다.
대신, 그는 분리를 주장한다.
모델은 교체 가능해야 한다. 회사의 맥락, 기억, 메타데이터, 에이전트 프레임워크, 워크플로우 및 축적된 지식은 항상 회사가 통제할 수 있어야 한다.
이러한 아키텍처는 조직이 특정 작업에 가장 강력한 모델을 사용할 수 있게 하면서도, 어떤 단일 공급업체가 기관 지식의 유일한 저장소가 되는 것을 방지한다.
단일 AI에 모든 것을 거는 것은 역량을 아웃소싱하는 것과 같다
언뜻 보기에 단일 AI 공급업체를 사용하기로 약속하는 것은 효율적으로 보일 수 있다.
직원들은 하나의 인터페이스만 있으면 된다. 조달이 더 간단하다. 보안 팀은 하나의 플랫폼만 승인하면 된다. 개발자는 하나의 통합 세트만 구축하면 된다. 조직은 단일 기술 스택에서 프롬프트, 에이전트 및 내부 워크플로우를 표준화할 수 있다.
문제는 점진적으로 나타난다.
엔터프라이즈급 AI 시스템은 더 이상 모델 API에 연결된 단순한 텍스트 상자가 아니다.
채택이 증가함에 따라 시스템은 축적하게 된다:
- 내부 문서
- 프롬프트 라이브러리
- 대화 기록
- 사용자 선호도
- 장기 에이전트 기억
- 평가 결과
- 도구 권한
- 워크플로우 규칙
- 검색 색인
- 수동 수정 기록
- 도구 호출 기록
- 업무별 지침
- 승인 패턴
- 내부 용어
- 성공 및 실패 사례
이러한 항목 각각은 개별적으로는 전략적 자산처럼 보이지 않을 수 있다.
하지만 함께 모이면 회사의 사고 방식을 상세하게 묘사하는 지도가 될 수 있다.
AI 사용은 새로운 형태의 기관 기억을 창출한다
전통적인 조직 지식은 여러 곳에 분산되어 있다.
그 중 일부는 정책, 매뉴얼, 데이터베이스 및 위키에 기록되어 있지만, 상당 부분은 기록되지 않는다.
그것들은 직원들이 반복적으로 내리는 결정들 속에 존재한다:
- 어떤 고객 요청이 에스컬레이션할 가치가 있는가?
- 어떤 판매 리드가 진정으로 적격한가?
- 어떤 엔지니어링 단축이 허용 가능한가?
- 회사는 비정상적인 환불 요청에 어떻게 대응하는가?
- 규제 시장에서 어떤 언어가 허용되는가?
- 어떤 제품 결함이 즉시 롤백되어야 하는가?
- 경험 많은 관리자는 무엇을 알아차리는 반면, 주니어 직원은 놓치는가?
인공지능 시스템이 이러한 결정에 참여할 때, 상호작용 기록은 이러한 암묵적 지식의 일부를 포착하기 시작한다.
사용자가 질문을 한다.
AI가 정보를 검색한다.
직원이 답변을 수정한다.
시스템이 도구를 호출한다.
사용자가 한 결과를 거부하고 다른 것을 선택한다.
워크플로우가 업데이트된다.
수천 번의 상호작용 후, 회사는 의도했든 아니든 귀중한 훈련 및 평가 데이터 세트를 생성했다.
핵심 질문은: 누가 이 데이터 세트를 소유하고 재사용할 수 있는가이다.
공급업체 종속은 API 호환성 문제를 훨씬 넘어선다
기업은 일반적으로 AI 종속을 API 문제로 간주한다.
공급업체 A가 너무 비싸지면 공급업체 B의 API 엔드포인트로 교체하면 된다.
이 접근 방식은 모델 자체가 주요 의존성일 때만 유효하다.
현대 에이전트 시스템은 훨씬 더 많은 계층을 포함한다.
| 계층 | 예시 |
|---|---|
| 기반 모델 | OpenAI, Anthropic, Microsoft 호스팅, 오픈소스 가중치 모델 |
| 시스템 프롬프트 | 기업 규칙 및 작업 지침 |
| 맥락 | 관련 비즈니스 문서 및 검색된 정보 |
| 기억 | 지속적인 사용자, 팀, 프로젝트 또는 고객 기록 |
| 프레임워크 | 계획, 도구 호출, 재시도 및 평가를 위한 에이전트 루프 |
| 도구 | CRM, 데이터베이스, 코드 저장소, ERP, 이메일, 내부 API |
| 메타데이터 | 프롬프트, 모델 선택, 출력, 지연 시간, 비용, 수정 |
| 평가 | 워크플로우 신뢰성을 결정하는 테스트 |
| 정책 | 권한, 보안 규칙, 규정 준수 요구 사항 |
| 관찰 가능성 | 로그, 추적, 사용 지표 및 이벤트 기록 |
이러한 모든 계층이 단일 공급업체의 독점 제품에 내장되어 있다면, 기반 모델을 교체하는 것은 전체 기술 스택을 재설계해야 함을 의미할 수 있다.
이는 사실상의 의존 관계를 만든다.
원래 공급업체는 다음과 같은 행동을 할 수 있다:
- 가격 인상
- 특정 모델 중단
- 속도 제한 변경
- 기억 동작 변경
- 에이전트 기능 수정
- 특정 기능 제한
- 지역 가용성 변경
- 데이터 처리 정책 변경
- 중요한 작업에서 다른 모델에 뒤처짐
모듈식 아키텍처를 가진 회사는 모델을 교체함으로써 대응할 수 있다.
하지만 기억, 프레임워크, 맥락 및 워크플로우 로직이 단일 서비스에 융합된 회사의 경우 선택권이 훨씬 적을 수 있다.
진정한 위험은 작업 수행 방식을 설명할 능력을 잃는 것이다
조직이 AI 지원 작업과 관련된 추론 및 피드백에 대한 자체 기록을 더 이상 유지하지 않을 때 가장 깊은 형태의 종속이 발생한다.
2년 동안 수천 번의 AI 상호작용을 통해 개선된 고객 지원 워크플로우를 상상해보라.
직원들은 반복적으로 시스템을 수정했다.
이러한 수정은 워크플로우가 언제 환불해야 하는지, 언제 에스컬레이션해야 하는지, 어떤 어조를 사용해야 하는지 가르쳤다.
사용 패턴, 존재하는 예외 사항 및 관련된 내부 팀 등이 있다.
이러한 모든 학습 결과가 독점 에이전트 서비스에만 존재한다면, 마이그레이션은 워크플로우를 효과적으로 만든 기록을 잃는 것을 의미할 수 있다.
회사는 여전히 원본 문서를 가지고 있을 수 있다.
하지만 이러한 문서 사용으로 인해 생성된 완전한 운영 기억은 더 이상 없을 수 있다.
이것이 바로 나델라의 경고가 내포하는 우려, 즉 회사가 궁극적으로 사고 능력의 일부를 아웃소싱할 수 있다는 것이다.
이 말은 극적으로 들릴 수 있지만, 아키텍처 문제 자체는 매우 구체적이다: 기업은 AI가 생성한 지식에 대해 자체 워크플로우를 재구성, 감사, 마이그레이션 및 개선할 수 있을 만큼 충분한 통제권을 가져야 한다.
가장 똑똑한 모델은 빌릴 수 있지만, 기업의 '두뇌'는 내부에 남아 있어야 한다
나델라가 제시한 해결책은 기반 모델을 기업이 소유한 주변 계층과 분리하는 것이다.
CNN 인터뷰에서 그는 특히 제어 프레임워크를 모델과 분리하고 맥락과 기억을 모델과 분리할 것을 주장했다.

이는 다른 아키텍처를 형성합니다.
기업은 더 이상 단일 AI 제공업체를 완전한 지능형 플랫폼으로 보지 않고, 기초 모델을 교체 가능한 추론 엔진으로 간주합니다.
기업은 다음에 대한 통제권을 유지합니다:
- 자체 데이터
- 자체 프롬프트
- 자체 메모리
- 자체 워크플로 상태
- 자체 평가 데이터
- 자체 도구 계층
- 자체 메타데이터
- 자체 권한
- 자체 비즈니스 규칙
- 자체 감사 추적
모델은 현재 작업에 필요한 컨텍스트만 수신합니다.
나델라가 언급한 메타데이터
기업 AI 시스템에서 메타데이터는 다음 정보를 포함할 수 있습니다:
- 직원이 어떤 질문을 했는지
- 어떤 모델이 해당 요청을 처리했는지
- 어떤 문서가 검색되었는지
- 어떤 도구가 호출되었는지
- 어떤 도구 매개변수가 사용되었는지
- 모델이 어떤 결과를 생성했는지
- 사용자가 해당 결과를 수락했는지 거부했는지
- 직원이 출력 내용을 어떻게 편집했는지
- 작업에 소요된 시간
- 작업 비용
- 워크플로 성공 여부
- 어떤 보안 또는 정책 검사가 트리거되었는지
이러한 기록은 매우 가치 있게 활용될 수 있습니다.
다음과 같은 용도로 사용될 수 있습니다:
- 모델 평가
- 일반적인 오류 패턴 식별
- 프롬프트 개선
- 분류기 훈련
- 라우팅 규칙 튜닝
- 내부 데이터 세트 구축
- 도메인 특화 모델 생성
- 에이전트 워크플로 개선
- 중요한 의사 결정 감사
나델라의 핵심 주장은 이 학습 주기가 항상 기업의 소유여야 한다는 것입니다.
조직이 자체 상호작용 기록을 유지하면, 기초 모델이 변경되더라도 지속적으로 개선할 수 있습니다.
제어 프레임워크를 독립적으로 유지하기
제어 프레임워크는 AI 모델을 둘러싼 소프트웨어 계층으로, 원시 모델 응답을 에이전트 워크플로로 변환합니다.
다음 사항을 처리할 수 있습니다:
- 프롬프트 구성
- 컨텍스트 검색
- 계획
- 도구 선택
- 도구 실행
- 메모리 읽기/쓰기
- 재시도 메커니즘
- 출력 검증
- 승인 프로세스
요청
10. 로깅
11. 모델 라우팅
12. 최종 응답 생성
프레임워크가 특정 제공업체의 모델에 밀접하게 결합되어 있으면, 모델을 교체할 때 전체 에이전트 시스템을 교체해야 할 수 있습니다.
프레임워크가 제공업체와 무관하면, 동일한 워크플로로 다른 모델을 호출할 수 있습니다.
예를 들어:
- 코딩 작업에는 강력한 코딩 모델을 사용할 수 있습니다.
- 긴 문서 작업에는 큰 컨텍스트 창을 가진 모델을 사용할 수 있습니다.
- 간단한 분류 작업에는 소형 모델을 선택할 수 있습니다.
- 민감한 작업에는 자체 호스팅 오픈 가중치 모델을 배포할 수 있습니다.
- 복잡한 계획 작업에는 최첨단 추론 모델로 업그레이드할 수 있습니다.
비즈니스 프로세스는 안정적으로 유지되고, 추론 엔진은 유연하게 전환될 수 있습니다.
다중 모델 아키텍처가 실제 기업 패턴이 되고 있습니다
이는 더 이상 개념 설계에 불과하지 않습니다.
마이크로소프트 자체도 현재 다중 AI 모델 간 라우팅을 위한 인프라를 제공하고 있습니다.
Microsoft Foundry의 모델 라우터는 프롬프트를 분석하여 품질, 비용, 지연 시간 및 구성된 모델 하위 집합에 따라 적합한 기초 모델로 라우팅합니다.
Azure API Management의 AI 게이트웨이는 통합된 기업 경계를 통해 여러 모델 제공업체를 노출할 수 있습니다. 마이크로소프트 문서는 Microsoft Foundry, Azure OpenAI, AWS Bedrock, Google Vertex, OpenAI, Anthropic 및 사용자 정의 모델 엔드포인트를 포함한 백엔드 지원을 설명합니다.
게이트웨이 아키텍처는 다음을 중앙에서 관리할 수 있습니다:
- 인증
- 모델 선택
- 제공업체 자격 증명
- 토큰 제한
- 속도 제한
- 로깅
- 모니터링
- 콘텐츠 보안 정책
- 네트워크 정책
- 비용 추적
애플리케이션은 전체 코드베이스에 단일 제공업체를 직접 포함시키는 대신, 기업이 제어하는 게이트웨이를 호출합니다.
이는 잠금 문제를 완전히 제거하는 것은 아닙니다. 게이트웨이 자체가 관리 및 마이그레이션이 필요한 인프라가 될 수 있습니다.
하지만 모델 선택을 기업이 제어할 수 있는 계층으로 끌어올립니다.
실용적인 기업 AI 아키텍처
공급업체 중립적인 기업 AI 스택은 여러 독립 계층으로 볼 수 있습니다:
직원/애플리케이션
|
v
기업 에이전트/프레임워크
|
+------ 기업 메모리
|
+------ 검색/컨텍스트
|
+------ 도구/MCP/내부 API
|
+------ 평가/정책
|
+------ 관찰 가능성/메타데이터
|
v
AI 게이트웨이/모델 라우터
/ | \
v v v
모델 A 모델 B 내부 모델
핵심 경계는 기업 지식과 모델 추론 사이에 있습니다.
회사의 메모리, 프롬프트, 워크플로, 도구 및 평가 데이터는 모델 계층 위에 있습니다.
모델은 교체될 수 있으며, 그 주위에 구축된 조직화된 상태를 버릴 필요가 없습니다.
첫 번째 계층: 기업 데이터
권위 있는 비즈니스 정보를 조직이 제어하는 시스템에 보관합니다.
예시는 다음과 같습니다:
- 데이터 웨어하우스
- 문서 저장소
- CRM 시스템
- 제품 데이터베이스
- 소스 코드 관리 플랫폼
- 내부 지식 베이스
모델은 필요한 내용을 검색해야 하며, 정보의 유일한 영구 복사본이 되어서는 안 됩니다.
두 번째 계층: 컨텍스트와 검색
검색을 독립 서비스로 구축합니다.
이를 통해 조직은 임베딩 모델, 재정렬기 또는 생성 모델을 교체하면서 원래 지식 베이스를 다시 구축할 필요가 없습니다.
검색 계층은 출처 정보를 유지하여, 사용자가 어떤 내부 자료가 답변에 영향을 미쳤는지 알 수 있도록 해야 합니다.
세 번째 계층: 메모리
메모리가 전략적 중요성을 가질 때, 장기 메모리를 모델 제공업체의 기본 채팅 기록과 별도로 저장합니다.
가능한 메모리 범위는 다음과 같습니다:
- 사용자 메모리
- 프로젝트 메모리
- 고객 메모리
- 에이전트 메모리
- 조직 메모리
각 메모리 유형에는 명확한 보존, 권한, 내보내기 및 삭제 규칙이 있어야 합니다.
네 번째 계층: 에이전트 프레임워크
비즈니스 로직을 기업이 검사하고 버전을 관리할 수 있는 시스템에 배치합니다.
프레임워크는 다음을 정의해야 합니다:
- 어떤 도구가 존재하는지
- 누가 사용할 수 있는지
- 어떤 작업에 승인이 필요한지
- 재시도 메커니즘이 어떻게 작동하는지
- 어떤 상태를 지속해야 하는지
- 언제 모델을 전환할 수 있는지
- 무엇이 성공으로 간주되는지
이를 통해 에이전트를 공급업체 특정 기능에서 기업 워크플로로 전환할 수 있습니다.
다섯 번째 계층: AI 게이트웨이 또는 라우터
다중 모델 유연성이 중요할 때, 애플리케이션과 모델 사이에 라우팅 계층을 배치합니다.
라우터는 다음 요소에 따라 모델을 선택할 수 있습니다:
- 작업 유형
- 품질 요구 사항
- 비용
- 지연 시간
- 데이터 거주지
- 컨텍스트 길이
- 보안 요구 사항
- 제공업체 가용성
게이트웨이는 장애 조치 기능도 제공할 수 있습니다.
모델 엔드포인트를 사용할 수 없는 경우, 워크플로는 다른 적격 모델을 사용하여 계속될 수 있습니다.
여섯 번째 계층: 메타데이터와 평가
시스템이 제대로 작동하는지 이해할 수 있도록 충분한 상호작용 메타데이터를 저장합니다.
모든 데이터를 무차별적으로 보관하지 마십시오. 개인정보 보호, 보안 및 규제 요구 사항은 여전히 적용됩니다.
적절한 워크플로의 경우, 유용한 기록에는 다음이 포함될 수 있습니다:
- 모델 버전
- 프롬프트 템플릿 버전
- 검색된 출처
- 도구 사용
- 지연 시간
- 토큰 사용량
- 사용자 피드백
- 수동 수정
- 평가 점수
- 최종 결과
이 데이터는 AI 시스템이 시간이 지남에 따라 개선되도록 하면서, 이러한 개선을 특정 제공업체에 묶지 않을 수 있습니다.
현재 특정 모델이 분명히 최고여도 이것이 중요한 이유
몇 분 만에 쇼케이스 사이트를 만들고 리드를 늘리세요
아이디어를 한 문장으로 입력하면 We0 AI가 쇼케이스 사이트, 페이지, CMS를 생성하고 출시 후 고객과 트래픽 확보를 돕습니다.
무료 등록을 위한 하나의 완전한 프로젝트 생성
하나의 완전한 생성 흐름을 시도하고 첫 번째 프로젝트 초안을 빠르게 보는 데 가장 적합합니다.
기업 아키텍처는 벤치마크 순위표보다 더 긴 시야를 가지고 구축됩니다.
오늘 가장 강력한 모델은 6개월 후에는 그렇지 않을 수 있습니다.
AI 시장은 빠르게 변화하는데, 개선은 다음에서 비롯될 수 있기 때문입니다:
- 새로운 사전 훈련
- 더 나은 추론 능력
- 더 낮은 추론 비용
- 새로운 컨텍스트 창 기술
- 새로운 멀티모달 능력
- 더 나은 코딩
- 더 나은 도구 사용
- 더 빠른 서빙
- 오픈 가중치 공개
- 전문 도메인 모델
운영 체제를 변경하지 않고도 모델을 교체할 수 있는 회사는 이러한 경쟁의 혜택을 누릴 것입니다.
그러나 특정 독점 기술 스택에 깊이 묶인 회사는 혜택을 얻지 못할 수 있습니다.

그는 검은 정장을 입고 안경을 착용했으며, 미소를 띠고 생동감 있는 손짓을 하고 있다. 배경에는 책, 모자, 액자 등이 놓인 책장이 있다. 화면 아래에는 중영문 이중 자막이 있으며, 영어는 “at the same time anyone model can go away and you can”, 중국어는 “同时,任何模型都可能被淘汰,而你则可以继续使用自己的模型。”이다. 이 이미지는 맥락과 밀접하게 연결되어 있으며, 해당 맥락에서는 기업이 단일 AI 공급업체에 지나치게 의존하지 않아야 하며, 모델 교체 가능성을 갖춰 모델 도태 등의 변화에 대비해야 한다는 점을 논의하고 있다.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c44f3901-7bd5-4733-895d-6fa0b47f301e-50fd6d0f-c3d0-483b-893a-0dbdce1e7527.png)
이는 기업이 모델을 끊임없이 전환해야 한다는 주장이 아니다.
잦은 전환 자체도 문제를 초래할 수 있다:
- 출력 불일치
- 새로운
평가 작업
- 보안 검토
- 프롬프트 비호환성
- 다른 도구 동작
- 새로운 유형의 오류 모드
목표는 선택 가능성이지, 영구적인 교체가 아니다.
회사는 충분한 이유가 있을 때 변경할 수 있어야 한다.
YC 토큰 제안, 스타트업이 플랫폼 의존을 우려하는 이유를 드러내다
원문은 나델라의 경고를 스타트업 커뮤니티의 이전 논의와 연결짓는다.
2026년 5월, OpenAI CEO 샘 올트먼은 현재 Y Combinator 배치의 각 스타트업에 200만 달러 상당의 OpenAI 토큰을 지분과 교환하여 제공했다.
TechCrunch는 이 투자가 상한선 없는 SAFE 형태로 이루어지며, 이후 가격이 결정된 자금 조달 라운드에서 전환된다고 보도했다.
이는 AI 스타트업에게 매력적이다.
모델 추론은 초기 기업의 가장 큰 지출 중 하나일 수 있다. 대규모 토큰 할당을 받으면 팀은 동일한 현금을 지출하지 않고도 제품을 구축하고 테스트할 수 있다.
하지만 이는 전략적 의존에 대한 명백한 의문을 제기한다.
투자자 제이슨 칼라카니스는 창업자들에게 플랫폼 제공자가 스타트업의 개발 내용을 알게 된 후 경쟁할 수 있다고 공개적으로 경고했다.
이 우려는 OpenAI가 실제로 회사의 제품을 베낄 것이라는 증명이 아니다.
이는 전형적인 플랫폼 리스크 논쟁이다: 인프라 제공자가 비즈니스에 더 핵심적일수록, 해당 제공자가 어떤 데이터에 접근할 수 있는지와 전환 비용이 얼마나 되는지 이해해야 한다.
OpenAI 제안은 YC 표준 거래와 별개
Y Combinator 자체의 표준 투자는 여전히 독립적이다.
YC는 현재 표준 거래를 50만 달러 투자로 설명하며, 여기에는 다음이 포함된다:
- 12만 5천 달러에 고정 7% 지분
- 최혜국 조항이 포함된 상한선 없는 SAFE를 통한 37만 5천 달러
TechCrunch가 보도한 OpenAI 토큰 배치는 추가 제안일 뿐, YC 표준 자금 조달을 대체하는 것이 아니다.
따라서 창업자에게 전략적 문제는 단순히 무료 또는 보조금 지원 추론의 가치에 관한 것이 아니다.
이 혜택을 수락하는 것이 스타트업의 구조를 변화시켜 향후 독립적인 운영을 어렵게 할지 여부다.
기업 AI 지식이 새로운 전략적 자산이 되다
과거 회사의 강점은 종종 인재와 프로세스에 있었다.
경험 많은 직원은 비정상적인 문제를 해결하는 방법을 알고 있었다. 관리자는 어떤 예외 사항이 중요한지 이해하고 있었다. 영업팀은 어떤 신호가 실제 구매 의향을 나타내는지 알고 있었다. 엔지니어는 수년 전 이상해 보였던 아키텍처 결정의 이유를 기억하고 있었다.
AI 시스템은 이러한 축적된 판단력 중 일부를 기계가 읽을 수 있는 산출물로 코딩하기 시작했다.
이 산출물에는 다음이 포함된다:
- 프롬프트 라이브러리
- 에이전트 지침
- 컨텍스트 저장소
- 평가 도구 세트
- 인간 피드백 데이터
- 도구 사용 궤적
- 의사 결정 로그
- 에이전트 메모리
- 미세 조정 데이터
- 워크플로 정의
이는 AI가 조직의 모든 지능을 장악했다는 의미가 아니다.
많은 전문 지식은 여전히 인재, 문화, 인간 관계 및 암묵적 판단에 존재한다.
하지만 기계가 읽을 수 있는 부분의 비중이 커지고 있다.
이로 인해 소유권과 이식성이 더욱 중요해진다.
모델은 점점 상품 계층이 되고 있다
비용이 많이 들고 기술적으로 어렵다.
대부분의 기업에게 처음부터 모델을 훈련하는 것은 경제적으로 무의미하다.
진정한 변화는 기업이 더 많은 선택지를 가지게 되었다는 점이다.
예를 들어, Microsoft Foundry는 Microsoft, OpenAI, Meta, DeepSeek 및 기타 공급업체의 모델에 대한 접근을 제공한다. 기업 게이트웨이는 다른 클라우드 플랫폼에서 호스팅되거나 타사에서 직접 제공하는 모델로 라우팅할 수도 있다.
따라서 모델은 전문적인 인프라 구성 요소로 간주될 수 있다.
기업의 지속적인 고유 가치는 다음 계층에 존재한다:
- 독점 데이터
- 워크플로 지식
- 내부 피드백
- 평가 시스템
- 비즈니스 규칙
- 메모리 시스템
- 고객 컨텍스트
- 조직적 의사 결정
바로 이러한 계층이 범용 모델이 기업의 고유한 AI 역량을 발휘하도록 만든다.
모든 기업이 실행해야 할 마이그레이션 테스트
AI 종속성을 측정하는 실용적인 방법은 간단한 질문을 던지는 것이다:
내일 우리의 주요 모델 공급업체가 사라진다면, 우리는 무엇을 잃을까?
답변은 문서화되어야 한다.
- 모델 접근
애플리케이션이 다른 모델 엔드포인트를 가리킬 수 있는가?
가능하다면, 코드를 얼마나 수정해야 하는가?
- 프롬프트
시스템 프롬프트와 에이전트 지침이 기업 자체 저장소에 저장되어 있는가?
내보내고 버전 관리할 수 있는가?
- 컨텍스트
소스 문서와 검색 인덱스가 회사에 의해 통제되는가?
모델을 변경하면 지식 계층을 재구축해야 하는가?
- 메모리 시스템
장기 메모리를 내보낼 수 있는가?
조직이 그 아키텍처를 이해하고 있는가?
이 메모리가 다른 에이전트 시스템과 호환되는가?
- 도구 통합
도구 통합이 이식 가능한 API나 MCP 같은 표준을 기반으로 구축되었는가?
아니면 핵심 워크플로가 특정 공급업체의 독점 에이전트 제품에만 존재하는가?
- 메타데이터
회사가 자체 상호작용 로그와 모델 평가 결과를 보유하고 있는가?
역사적 작업을 통해 두 공급업체의 성과를 비교할 수 있는가?
- 평가 시스템
다른 모델로 동일한 합격 기준을 테스트할 수 있는가?
재사용 가능한 평가 도구 세트가 없다면, 모델 변경은 주관적인 이전 시도에 그칠 것이다.
- 신원 및 권한
비즈니스 권한이 기업 시스템 자체에 의해 시행되는가?
모델 마이그레이션이 회사의 권한 모델을 재구축하도록 요구해서는 안 된다.
- 규정 준수
회사가 데이터 흐름, 처리 모델 및 보유 내용을 설명할 수 있는가?
거버넌스 시스템이 온전히 유지될 때만 다중 모델 유연성이 가치가 있다.
- 운영 장애 조치
주요 공급업체를 사용할 수 없을 때 어떤 일이 발생하는가?
핵심 워크플로가 우아하게 저하될 수 있는가?
마이그레이션 테스트 한 번이 아키텍처 다이어그램이 놓친 종속성을 드러내는 경우가 많다.
다중 모델이 모든 프롬프트를 모든 곳에 보내는 것은 아니다
공급업체 종속을 피하는 것이 동시에 여러 모델 공급업체에 데이터를 보내는 것을 의미하지는 않는다.
이는 불필요한 프라이버시 및 보안 위험을 초래한다.
통제된 다중 모델 전략은 라우팅 규칙을 사용해야 한다.
예:
| 워크로드 | 가능한 라우팅 전략 |
|---|---|
| 저위험 분류 | 소형 저비용 호스팅 모델 |
| 복잡한 코딩 | 강력한 코딩 모델 |
| 긴 문서 분석 | 긴 컨텍스트 모델 |
| 민감한 내부 데이터 | 비공개 또는 자체 호스팅 모델 |
| 고위험 의사 결정 | 감사 가능한 기업 모델 |
의사 결정 지원 | 승인된 모델 + 인간 검토
| 공급업체 중단 | 사전 승인된 장애 조치 모델 |
회사는 어떤 모델이 어떤 정보를 처리할 수 있는지 정의하는 데이터 거버넌스 전략을 수립해야 한다.
모델 선택은 유연해야 한다.
데이터 처리는 엄격해야 한다.
아키텍처 자체에 트레이드오프가 존재한다
나델라의 제안은 매력적으로 들리지만, 모든 계층을 분리하면 엔지니어링 작업량이 증가한다.
다중 모델 시스템에는 다음이 필요할 수 있다:
- 호환성 테스트
- 프롬프트 표준화
- 공급업체별 어댑터
- 평가 인프라
- 비용 추적
- 라우팅 전략
- 통합 관찰 가능성
- 다중 공급업체 보안 검토
- 데이터 상주 통제
- 모델별 폴백 로직
소규모 회사는 처음에 단일 공급업체를 선택하는 것이 합리적일 수 있다.
핵심은 불필요한 종속을 피하는 것이다.
스타트업은 제품-시장 적합성을 찾기 전에 복잡한 내부 AI 플랫폼을 구축할 필요가 없다.
여전히 할 수 있는 것:
- 프롬프트를 자체 코드베이스에 저장
- 소스 데이터를 모델 공급업체 외부에 유지
- 이식 가능한 메모리 패턴 유지
- 일관된 내부 인터페이스 뒤에 모델 호출 추상화
- 모델 버전 기록
- 평가 데이터 세트 보존
이러한 비교적 간단한 결정이 미래의 마이그레이션을 더 쉽게 만들 수 있다.
전략적 문제는 누가 학습 루프를 소유하는가
기업 AI에서 가장 가치 있는 부분은 모델 자체가 아닐 수 있다.
오히려 직원이 모델을 사용할 때 생성되는 피드백 루프다.
회사가 문제를 제기한다.
모델이 답변을 제공한다.
직원이 오류를 수정한다.
도구를 호출한다.
결과를 측정한다.
더 나은 워크플로우가 탄생한다.
조직이 이 사이클을 보유하면, 축적된 학습成果를 한 세대의 모델에서 다음 세대로 이전할 수 있다.
이 사이클이 완전히 공급업체에 속할 경우, 회사는 AI 시스템이 개선되는 것을 볼 수 있지만, 자체 이식 가능성은 향상되지 않을 수 있다.
이 때문에 나델라의 경고는 단순히 여러 공급업체를 사용하라는 조언보다 더 깊은 의미를 지닌다.
이는 기업 지능이 어디에 있어야 하는지에 대한 제안이다.
모델은 임대할 수 있다.
그러나 조직은 모델이 작동하도록 하는 맥락을 유지해야 한다.
자주 묻는 질문
사티아 나델라는 단일 AI 모델 의존에 대해 어떻게 생각하나요?
2026년 7월 26일 파리드 자카리아와의 인터뷰에서 나델라는 회사가 단일 AI 공급업체가 데이터, 메타데이터, 맥락, 메모리 및 에이전트 프레임워크를 통제하도록 해서는 안 된다고 보았다. 그는 회사가 이러한 계층에 대한 통제를 잃으면 사고 능력의 일부를 아웃소싱하게 될 수 있다고 경고했다.
나델라는 회사가 자체 기반 모델을 구축해야 한다고 생각하나요?
반드시 그런 것은 아니다. 그의 제안은 기업 자체의 맥락, 메모리, 메타데이터 및 오케스트레이션 계층을 모델과 분리하여, 회사가 여러 최첨단 또는 오픈 가중치 모델을 사용하면서도 자체 지식을 유지할 수 있도록 하는 것이다.
AI 에이전트 프레임워크란 무엇인가요?
프레임워크는 모델을 둘러싼 소프트웨어 계층으로, 프롬프트, 도구, 맥락, 메모리, 계획, 재시도, 권한, 평가 및 실행을 관리한다. 이를 단일 모델 공급업체와 분리하면 비즈니스 프로세스의 이식성을 높이는 데 도움이 된다.
AI 게이트웨이란 무엇인가요?
AI 게이트웨이는 기업 애플리케이션과 모델 공급업체 사이에 위치한 제어된 계층이다. 인증, 라우팅, 속도 제한, 모니터링, 정책, 모델 선택 및 공급업체 자격 증명을 중앙에서 관리할 수 있다.
기업이 AI 메타데이터를 유지해야 하는 이유는 무엇인가요?
AI 메타데이터는 사용된 프롬프트, 검색된 정보, 호출된 도구, 사용자가 출력을 수정한 방식 및 작업 성공 여부를 보여준다. 이 기록은 평가, 워크플로우 최적화, 모델 라우팅 또는 향후 내부 교육에 사용될 수 있다.
다중 모델 아키텍처가 공급업체 종속을 없앨 수 있나요?
아니요. 모델 계층의 의존성을 낮추지만, 게이트웨이, 벡터 데이터베이스, 메모리 시스템, 에이전트 프레임워크 또는 클라우드 플랫폼이 새로운 종속 형태를 만들 수 있다. 이식성은 전체 기술 스택에서 종합적으로 고려해야 한다.
OpenAI는 Y Combinator 스타트업에 무엇을 제공했나요?
2026년 5월 TechCrunch 보도에 따르면, OpenAI는 현재 YC 배치의 각 스타트업에 200만 달러 상당의 토큰을 무제한 SAFE를 통해 지분과 교환하여 제공했다. 이 계약은 YC 표준 50만 달러 투자 계약과 별도로 이루어졌다.
소규모 스타트업이 즉시 다중 모델 플랫폼을 구축해야 하나요?
보통은 필요하지 않다. 초기 팀은 단일 공급업체를 사용하면서도 모델 호출의 추상화, 프롬프트의 버전 관리, 데이터의 자체 통제 및 평가의 이식성을 유지할 수 있다. 이러한 선택은 불필요한 인프라를 추가하지 않고도 향후 조정 가능성을 보존한다.
관련 도구
- Microsoft Foundry: 다양한 AI 모델을 발견, 평가, 배포 및 운영하기 위한 마이크로소프트 플랫폼.
- Microsoft Foundry Model Router: 품질, 비용 및 구성 정책에 따라 적격 모델을 선택하는 중간 라우팅 계층.
- Azure API Management AI Gateway: 여러 AI 모델 및 MCP 도구에 대한 액세스를 관리하는 호스팅 게이트웨이.
- Model Context Protocol: 표준화된 인터페이스를 통해 AI 애플리케이션을 도구 및 데이터 소스에 연결하는 개방형 프로토콜.
- OpenTelemetry: AI 애플리케이션 인프라의 추적, 지표 및 로그를 수집하기 위한 오픈 소스 관측 가능성 프레임워크.
- Y Combinator SAFE: 미래 지분 단순 계약 투자 구조에 대한 YC 공식 자료.
관련 링크
- Fareed Zakaria GPS 인터뷰: 사티아 나델라: 2026년 7월 26일 인터뷰에서 나델라가 기업 AI의 위험과 이점에 대해 논의.
- TechCrunch: 사티아 나델라가 단일 AI 의존에 대해 말하다: 기업 맥락, 메모리 및 제어 계층을 기반 모델과 분리하라는 나델라의 제안에 대한 보도.
- Microsoft Foundry Model Router: 마이크로소프트 다중 모델 라우팅 시스템 공식 문서.
- Azure AI Gateway 개요: 단일 기업 엔드포인트를 통해 다양한 AI 모델과 도구를 관리하는 공식 문서.
- Azure API Management 통합 모델 API: 클라이언트 측 단일 API 뒤에 여러 모델 백엔드를 제공하는 마이크로소프트 공식 문서.
- TechCrunch: OpenAI, YC 스타트업에 200만 달러 토큰 제안: 2026년 YC 배치 기업을 대상으로 한 OpenAI의 "토큰 대 지분" 제안 보도.
- Y Combinator 표준 투자 조건: 50만 달러 표준 투자 구조에 대한 YC 공식 설명.
요약
사티아 나델라의 경고는 단순히 기업이 여러 AI 모델을 구독하라는 조언이 아니다. 더 깊은 의미는 기업이 축적한 맥락, 메모리, 메타데이터, 에이전트 로직 및 운영 지식을 독립적으로 저장하거나 이전할 수 없는 시스템에 두지 말아야 한다는 점이다.
모듈식 아키텍처는 기업의 지식 계층을 모델 계층과 독립적으로 유지한다. 기업은 코딩, 긴 컨텍스트 처리, 저비용 작업, 민감한 워크로드 또는 장애 조치 등의 요구에 따라 모델을 선택할 수 있으며, 완전한 AI 운영 체제를 재구축할 필요가 없다.
이러한 유연성은 엔지니어링 복잡성을 수반하지만, 소규모 팀도 초기 단계에서 자체 데이터, 프롬프트, 메모리 아키텍처, 평가 기준 및 모델 인터페이스를 통제함으로써 미래의 선택권을 유지할 수 있다.
최첨단 모델은 임대할 수 있지만, 기업 운영 방식을 설명하는 학습 루프는 영원히 당신의 것이어야 한다.



