마이크로소프트 코어 AI 전략과 한국 기업을 위한 실질적 교훈

AI 시대, 마이크로소프트가 먼저 바꾸고 있는 것들

요즘 AI 논의는 대부분 모델 성능과 GPU 숫자에 쏠립니다. 그러나 마이크로소프트 코어 AI를 총괄하는 제이 퍼릭의 이야기를 따라가다 보면 시선이 조금 달라집니다. 이들의 관심은 "얼마나 큰 모델이냐"가 아니라 "어떻게 일하는 방식을 갈아엎을 것이냐"에 더 가깝습니다.

코어 AI 조직은 개발자 도구와 인프라 팀을 묶어 하나의 수직 통합 조직으로 재구성했습니다. 목표는 단순합니다. 빌더에게 끝까지 책임지는 스택을 주겠다는 것입니다. 상단에서는 코딩 방식 자체를 재발명하는 도구를 만들고, 중간에서는 에이전트를 설계·배포·관찰하는 플랫폼(Foundry/Agent Factory)을 제공하며, 하단에서는 보안과 배포 유연성을 기본값으로 깔아두는 구조입니다.

눈에 띄는 지점은 이 모든 설계가 "사람" 관점에서 시작된다는 점입니다. 전통적인 의미의 개발자가 아니라, 기획자와 디자이너, 현업까지 포함한 더 넓은 의미의 '빌더'를 상정해 도구와 스택을 짜고 있습니다.

사무실 복귀와 'AI를 잘 쓰는 사람'의 조건

코어 AI 팀은 내년부터 전면 오피스 근무 체제로 전환합니다. 이유는 단순한 복귀 명령이 아니라, AI 도입 자체가 일하는 문화 실험이기 때문입니다. AI를 잘 쓰는 방법을 남에게 문서로 전파하는 것만으로는 속도가 나오지 않습니다. 옆자리 사람의 프롬프트를 구경하고, 즉석에서 같이 시도하고, 그 결과를 팀 단위로 빠르게 공유하는 문화가 필요합니다.

퍼릭은 내부에서 이미 역할의 경계가 흐려지고 있다고 말합니다. 주니어 인프라 엔지니어가 UI 목업을 만들고, 기획자가 Copilot을 통해 버그 수정 PR을 올립니다. 중요한 포인트는 특정 직무가 가장 큰 수혜를 본다는 식의 서열이 아니라, 개인의 태도에 따라 생산성 격차가 벌어진다는 관찰입니다.

그는 사용자를 두 부류로 나눕니다. 드물게 AI를 쓰고 매번 감탄만 하는 사람과, 매일 쓰면서 자주 불만을 느끼는 사람입니다. 후자가 더 빠르게 성장합니다. 계속 밀어붙이면서 프롬프트 기법, 컨텍스트 설계, 평가·튜닝 방식을 익히기 때문입니다. "적당히 만족하는 사람보다, 자주 짜증 나는 사람이 더 빨리 배운다"는 메시지에 가깝습니다.

모델 하나로는 부족하다, 엔터프라이즈의 현실적인 선택지

퍼릭의 시선에서 중요한 것은 단일 초거대 모델이 아닙니다. 오히려 모델 포트폴리오와 이를 다루는 플랫폼입니다. 기업 고객은 초기에는 Frontier 모델로 실험을 시작합니다. 그러나 특정 유즈케이스가 자리 잡으면 비용과 지연시간을 맞추기 위해 더 작은 특화 모델로 옮겨갑니다. 오픈소스 모델을 파인튜닝하거나, distillation으로 경량화한 모델을 붙이는 패턴이 자연스럽게 등장합니다.

마이크로소프트는 이런 선택을 돕기 위해 Model Router라는 계층을 노출합니다. 개발자는 비용, 속도, 품질 중 어떤 축을 우선시할지 설정만 하면 됩니다. 라우터가 그 기준에 맞는 모델을 골라 요청을 흘려보냅니다. 기업 입장에서는 모든 모델을 직접 벤치마크하지 않아도, 여러 모델을 혼합 활용하는 구조로 갈 수 있습니다.

또 하나 중요한 부분은 엔터프라이즈 데이터의 위치입니다. 모델이 아무리 좋아도, 기업의 고객·공급망·재무 데이터와 결합되지 않으면 ROI가 나오지 않습니다. 퍼릭은 모델의 영리함이 연구실의 성능 향상이 아니라, 기업 데이터와 파인튜닝·RL을 통해 현업 업무를 얼마나 깊게 처리할 수 있는지에서 결정된다고 봅니다. 오픈 대 클로즈드 소스 논쟁도 이 맥락에서는 부차적입니다. 실제 선택 기준은 라이선스와 성능, 비용, 컴플라이언스, 그리고 내부 데이터와의 결합 용이성입니다.

인프라와 전력, 'GPU를 다 쓰는 법'에 더 큰 의미가 있다

GPU 부족, 전력 부족 논쟁에서 퍼릭은 약간 초점을 비틀어 설명합니다. 물론 전력·부지·변전 설비 같은 물리적 제약은 존재합니다. 몇몇 지역은 데이터센터 신규 건설에 모라토리엄까지 걸려 있습니다. 그러나 실제 운영 관점에서는 "이미 켜둔 전력과 GPU를 얼마나 효율적으로 쓰느냐"가 더 시급한 문제입니다.

마이크로소프트는 내부 워크로드 전반에서 효율을 올리는 데 많은 공을 들입니다. 학습과 추론 방식을 바꾸고, 네트워크·메모리 병목을 분석하고, 다양한 워크로드 패턴에서 얻은 데이터를 활용해 스택 전체를 조정합니다. GPU 한 대에서 0.몇 퍼센트 효율을 올려도, 전체 플릿 단위에서는 막대한 여유 용량이 생기기 때문입니다.

또한 에이전트형 애플리케이션이 늘어나면서, GPU뿐 아니라 일반 CPU, 스토리지, 네트워크까지 동시에 과부하가 걸리는 시스템 전체의 스케일링 문제가 부상합니다. 에이전트가 도구 호출을 많이 할수록 기업 내 기존 시스템 호출이 폭증합니다. AI 데이터센터 투자만으로는 해결되지 않는, 레거시 시스템 부하와 아키텍처 재설계 이슈가 함께 움직입니다.

AI 보안과 거버넌스, "관찰 가능성"이 핵심 설계 요소가 되는 흐름

퍼릭의 백그라운드에는 클라우드 보안 회사 경험이 있습니다. 이 영향 때문인지, 에이전트와 플랫폼을 이야기할 때 보안·거버넌스를 초기에 설계에 박아 넣는 접근이 두드러집니다.

예를 들어, 플랫폼에서 생성된 에이전트는 고유 ID를 갖고 Entra에 등록됩니다. 이 ID를 통해 권한과 정책을 부여하고, 이상 행위를 하면 비활성화할 수 있습니다. 에이전트가 어떤 도구를 호출했고, 어떤 데이터에 접근했고, 인간이 어느 지점에서 승인하거나 수정했는지를 라인 단위로 추적 가능하게 만드는 것이 목표입니다.

이 구조는 단순 보안 통제를 넘어, AI 시스템에 대한 관찰 가능성(Observability)을 핵심 기능으로 끌어올립니다. 고급 에이전트는 도구 체인과 다른 에이전트, 검증 에이전트까지 얽혀 동작합니다. 이런 복잡성을 감당하려면, APM(Application Performance Monitoring)을 하던 것과 비슷한 수준의 추적과 로그가 필수입니다.

현실적으로 따져봐야 할 부분들

퍼릭의 이야기는 방향성을 제시합니다. 그러나 한국 기업이 그대로 따라가기에는 현실적인 간극이 있습니다. 전면 출근과 대면 협업을 전제로 한 "AI 활용 학습 문화"는 조직의 신뢰 수준과 인사 정책에 좌우됩니다. AI 실험을 실패해도 인사상 불이익이 없는 환경이 없다면, 구성원은 적극적인 시도를 피하게 됩니다.

모델 포트폴리오 전략 역시 마찬가지입니다. Model Router 같은 추상화 계층이 없다면, 여러 모델을 섞어 쓰는 일 자체가 부담입니다. 현재 많은 국내 조직은 한 벤더, 한 모델에 의존하는 구조를 선호합니다. 단기적으로는 관리가 편하지만, 장기적으로는 비용·성능·규제 변화에 유연하게 대응하기 어렵습니다. 플랫폼을 직접 만들 여력이 없다면, 최소한 멀티 모델·멀티 벤더를 지원하는 상용 플랫폼을 선택할 눈이 필요합니다.

인프라 효율도 중요한 포인트입니다. 대형 클라우드 사업자가 아닌 이상 GPU·전력 투자 여지는 제한적입니다. 이 경우 과감한 AI 인프라 투자가 아니라, 기존 클라우드 리소스를 AI 워크로드 중심으로 재배치하는 전략이 먼저 검토되어야 합니다. 사용률이 낮은 시스템을 줄이고, AI 관련 프로젝트에 자원을 몰아주는 방식입니다.

마지막으로, 보안과 거버넌스 설계입니다. 에이전트를 조직 계정 체계에 통합하고, 로그를 일관되게 수집하는 구조는 초기에 손이 많이 갑니다. 그러나 이 단계가 빠지면 AI 프로젝트는 파일럿을 넘기 어렵습니다. 규제와 감사를 통과시키기 어렵기 때문입니다. 국내 기업이 지금 당장 할 수 있는 최소한의 준비는, "AI 시스템도 다른 IT 시스템과 동일한 보안·컴플라이언스 체계에 편입한다"는 원칙을 명문화하고, 이에 맞춘 계정·권한·로그 전략을 설계하는 일입니다.

결국 퍼릭의 인터뷰는 화려한 AI 기능 자랑이 아니라, 조직 구조, 개발 문화, 인프라, 보안까지 한 번에 갈아엎어야 진짜 ROI가 나온다는 선언에 가깝습니다. 기술 도입보다 어려운 부분입니다. 그러나 이 부분을 건너뛰면, 어떤 모델을 쓰든 "데모를 넘지 못하는 AI"에 머무를 가능성이 큽니다.

출처 및 참고 :