SPEAKER 1: 우리는 새로운 시대에 들어섰습니다. 정보에 대한 접근이 곧 전문성에 대한 접근이 되는 시대입니다. 농장에서 연구실로, 이사회 회의실에서 교실로까지, 이 새로운 세대의 AI는 모든 사람을 위해, 어디에서나 쓰일 수 있습니다. 이제 누구나 개인 비서로 시간을 절약할 수 있습니다. SPEAKER 2: 패턴을 감지하고, 의미를 파악하며, 수사 자체의 방향을 말해 줄 수 있는 에이전트(agent)를 둘 수 있습니다. SPEAKER 1: 누구나 새로운 기술을 배우기 위한 개인 튜터에 접근할 수 있습니다. 개인 코치와 함께 분석하는 새로운 방식입니다. SPEAKER 3: AgriPilot.ai는 농부들이 감(guesswork)에 의존하지 않도록 돕고, 과학을 활용해 성공할 수 있게 해줍니다. SPEAKER 1: AI는 우리 모두의 창의성을 열어주고 있습니다. SPEAKER 4: Shiksha Copilot은 교사들이 교실을 위한 매력적인 콘텐츠를 만들 수 있도록 역량을 강화하고자 하는 생성형 AI 솔루션입니다. SPEAKER 5: AI는 이 나라의 개인과 청년들에게 기회를 제공하는 데 도움이 되고 있습니다. SPEAKER 1: 그리고 우리는 이제 막 시작했을 뿐입니다. SATYA NADELLA: 자, 좋습니다. 좋은 아침입니다(박수). 좋은 아침입니다. 다시 벵갈루루에 와서 이곳의 에너지를 느낄 수 있어 정말 기쁩니다. 여기서는 모두가 이번 **플랫폼 전환(platform shift)**이 무엇인지 이야기하고, उपलब्ध한 모든 도구를 쓰는 것뿐 아니라, 무엇보다도 **직접 만드는 것(building)**에 집중하고 있습니다. 플랫폼 기업으로서 우리에게 늘 흥미로운 것은, 어떤 플랫폼 전환이 오든 그것을 ‘자기 것으로’ 만들고자 하는 **빌더(builder)**들을 보는 일입니다. 그들이 자신의 창의성과 기업가적 에너지를 가져와 적용하는 모습을 보는 건 정말 멋집니다. 그래서 오늘은, 빌더로서 우리가 어떻게 ‘프런티어(frontier)’를 넓혀 가는지 이야기해 보려 합니다. 결국 우리의 출발점은 언제나 ‘지구상의 모든 사람과 모든 조직이 더 많은 것을 성취하도록 돕는다’는 사명입니다. 우리가 만드는 이유가 그것이고, 이는 개인과 조직이 만들어내는 **성과(outcome)**의 경계를 넓힌다는 뜻입니다. 우리는 ‘만들기 위한 만들기’를 하는 게 아니라, **임팩트(impact)**를 내기 위해 만듭니다. 궁극적으로는 고객 경험이 바뀌고, 직원 경험이 바뀌며, 어떤 기관이든 우리가 가져올 수 있는 운영 효율이 달라집니다. 그리고 혁신 자체의 속도, 즉 ‘얼마나 빠르게 혁신할 수 있는가’가 결국 어떤 기술이든 그 성과를 재는 척도입니다. 그리고 이를 해내기 위해, 솔직히 말해 가장 흥미로운 변화 중 하나는 ‘이 시스템을 만드는 방식’ 자체가 바뀌고 있다는 점입니다. 이전 어느 소프트웨어 시대와도 달리, 이번에는 우리가 구축하는 라이프사이클(lifecycle) 자체를 다시 생각해야 합니다. 예를 들어 보죠. 우리는 이제 단순히 스펙(spec)부터 시작하지 않습니다. 오히려 반대편에서, 즉 **평가 루프(eval loop)**를 먼저 생각하며 시작합니다. 어떤 의미에서는 ‘스펙이 아니라 **테스트(test)**부터 시작한다’고 저는 종종 말하곤 합니다. 이건 전체 프로세스를 완전히 뒤집는 일이며, 그에 맞는 마인드셋 전환이 필요합니다. 그래서 여러분은 ‘현실 세계에서 바꾸고 싶은 결과’에 훨씬 더 단단히 발을 붙이고 있어야 합니다. 세상(world)은 무엇이고, 평가 기준(rubric)은 무엇이며, 어떤 일(job)·과제(task)를 어떤 평가(eval)로 보겠다는 것인지, 먼저 그 지점으로 가야 합니다. 그리고 나서 그걸 바탕으로 나머지 워크플로우를 역으로 설계하게 됩니다. 제게는, 개발자에게도 이런 마인드셋 전환이 매우 중요해질 것입니다. 물론 그 전환을 실제로 만들어낼 수 있도록, 우리가 필요한 기술을 새로 익혀야 합니다. 그리고 해법을 만들 때 함께 작동하는 **툴 체인(tool chain)**이 필요합니다. 또 ‘컨텍스트 엔지니어링(context engineering)’이라고 말할 때의 데이터는, 예전의 데이터 엔지니어링과 닮았지만 다른 형태입니다. 즉, 데이터를 ‘지능(intelligence)’에 먹일 수 있는 형태로 가공하고, 그 위에서 오케스트레이션(orchestration)을 제대로 할 수 있도록 데이터의 모양을 잡아야 합니다. 이런 관점에서, 고전적 SDLC(Software Development Life Cycle)의 프런티어도, AI 주도 SDLC라는 새로운 형태로 바뀌어야 하며, 이는 매우 중요합니다. 이런 변화에 대응하기 위해 Microsoft가 하는 일은, 이를 활용할 수 있도록 **풀 스택(full stack)**을 구축하는 것입니다. 첫 번째는 ‘경험(experience) 레이어’입니다. 우리가 매일 사용하는 모든 곳에, 상태를 가지는(stateful) Copilot 경험을 깔 수 있을까요? Copilot 앱 자체이든, Excel이든 Word이든 Outlook이나 Teams 등 무엇이든, 대화(conversation)로 시작해 요청-응답(request/response)을 넘어서, 완전히 **에이전틱(agentic)**한 시스템과 상호작용하는 능력을 제공할 수 있을까요? 즉, 작업을 **할당(assign)**하고, 다시 돌아와 결과를 **검토(inspect)**하며, 한 명의 에이전트만이 아니라 여러 에이전트를 발견(discover)해 한 경험 안에서 함께 쓰는 것입니다. 우리는 이 경험 레이어를 구축해 왔고, 그 진전이 정말 반갑습니다. 제 일상만 봐도 이제는 단순히 ‘채팅 중심’ 경험이 아닙니다. 예를 들어 Researcher, 그리고 Researcher with CUA를 보면, 내가 작업을 맡기면 스스로 나가서 깊이 있는 리서치를 수행하고, **컴퓨터 사용(computer use)**을 또 하나의 도구처럼 활용하는 연구원을 둔 느낌입니다. 그게 Researcher입니다. Analyst는 늘 곁에 있는 데이터 분석가 같습니다. OneDrive에 있는 Excel 스프레드시트 묶음을 업로드하거나 가리키고, “그냥 인사이트를 줘(Please give me insight)”라고 말하면 됩니다. 제가 가장 좋아하는 질의가 사실 그겁니다. 스프레드시트를 한꺼번에 던져 넣고, 빈 질문에서 시작해 “인사이트를 달라”고 묻는 거죠. 이제 그런 걸 할 수 있다는 사실이 정말 해방감이 있습니다. 그리고 물론 Excel의 agent mode도 있습니다. 다음으로 모두가 ‘왜 내가 이 에이전트와 같이 있어야 하지?’라고 느끼게 될 큰 변화가 될 겁니다. 정말 놀라울 정도입니다. 저는 Excel 챔피언십에서 디지털 챌린지를 했는데, Excel을 평생 다뤄 온 사람으로서 정말 ‘쿨’했습니다. agent mode가 Office JS를 네이티브하게 이해하고, Excel의 모든 오브젝트(object)를 이해해 파일을 조작하고 훌륭하게 다루는 모습을 보는 건 대단했습니다. 어쨌든, 이런 에이전트들이 이제 Copilot 경험의 아주 핵심이 되었습니다. 오늘 이 나라(인도)에서는 이런 애플리케이션들이 깊이 있게 배포되는 모멘텀이 대단합니다. 특히 이번 주와 오늘의 발표로, Cognizant, Infosys, TCS, Wipro를 포함한 여러 곳에서 이를 5만 명 이상(50,000+) 규모로 배포하고 있다는 점이 매우 기대됩니다(박수). 제가 좋아하는 점은, 그들이 단지 Copilot을 여기저기 배포하는 데 그치지 않고, ‘딥 에이전트 팩토리’, 즉 AI 팩토리를 구축해 이 경험 레이어와 통합하고 있다는 것입니다. 이들은 집단적 고객을 변혁시키기 위해, 경험 레이어가 각 작업·직무·역할·비즈니스 프로세스마다 구축되는 에이전트들과 만나는 구조를 만들고 있습니다. 그 기회가 바로 지금 우리 앞에 있고, 저는 이 모든 흐름이 정말 기대됩니다. 그럼 Copilot 측면에서 우리가 무엇을 해왔는지 조금 보여드리기 위해, 제 동료 Zoe를 소개하겠습니다. Zoe, 올라와 주세요. ZOE HAWTOF: 고마워요, Satya. 여러분 안녕하세요. 저는 Microsoft 365 Copilot 팀의 Zoe입니다. 여러분과 마찬가지로(다만 교통 체증은 조금 덜하지만), 저는 출근길에 하루 일정을 준비하며 하루를 시작합니다. 그럴 때 저는 모바일에서 Copilot을 씁니다. ‘Hey, Copilot, 오늘 일정이 뭐야?’ COPILOT: 오늘은 몇 가지 일정이 있습니다. 먼저, 오늘 아침 일찍 시작된 AI Tour India 미팅이 있습니다. 그리고 오전 **11시(11 a.m.)**에는 Contoso 영업 콜이 있습니다. 오후에는 **2시(2 p.m.)**에 팀 싱크(team sync)가 예정되어 있습니다. ZOE HAWTOF: 고마워, Copilot. 그리고 매니저에게 온 이메일이 있어? COPILOT: 네, Nicole에게서 온 이메일이 몇 통 있습니다. 어제는 공용 공간에서 열리는 금요일 믹서(Fri­day mixer)에 대해 팀에 다시 안내했고, 월간 비즈니스 리뷰(monthly business review)를 마무리하는 것이 높은 우선순위라고도 언급했습니다. 또한 — ZOE HAWTOF: 고마워, Copilot. 이제 Copilot은 제 ‘업무 데이터’만 가지고 있는 게 아닙니다. Copilot은 제가 누구인지, 무엇을 하는지, 누구를 위해 일하는지까지 이해합니다. 그래서 저는 Copilot을 씁니다. Copilot은 제 AI 어시스턴트입니다. 이제 매니저가 요청한 ‘월간 비즈니스 리뷰(monthly business review) 업데이트’ 내용을 더 깊게 파악하고 싶어서, Copilot에게 그걸 정리해 달라고 부탁하겠습니다. Copilot은 필요한 **컨텍스트(context)**를 모두 갖고 있기 때문에, 제가 무엇을 해야 하는지에 대한 ‘실시간’이면서 매우 쉬운 이해를 제공해 줍니다. 예를 들어 현재 상태, 그리고 제가 내려야 할 핵심 의사결정 같은 것들이요. 해야 할 일을 파악했다고 느낀 다음에는, 월간 비즈니스 리뷰 템플릿을 업데이트하고 싶습니다. 기존 문서의 프레임워크를 정확히 유지한 채로, 11월(November) 데이터로 이 문서를 업데이트해 달라고 할 겁니다. 그때 저는 agent mode를 사용하겠습니다. Word의 agent mode는 에이전트가 왼쪽 패널에서 바로 편집(edit)·서식(format)·초안 작성(draft)을 할 수 있게 해줍니다. 물론 통제권은 전적으로 제가 갖고 있지만, 제 일에서 번거로운 부분을 크게 덜어줍니다. 저는 에이전트가 제 모든 업무 컨텍스트, 이메일, 미팅, 팀 채팅, 파일을 훑고 있는 것을 볼 수 있습니다. 예전에는 이런 작업을 하는 데 몇 시간이 걸렸습니다. 정보를 찾아서, 올바른지 확인하고, 이 템플릿에 복사-붙여넣기 해야 했죠. 지금은 에이전트가 그 모든 귀찮은 작업을 제 손에서 가져가, 왼쪽의 형식을 그대로 존중하면서도, 제 왼쪽 패널로 그대로 가져다주는 모습을 보여드리겠습니다. 이미 문서를 훑어가며 바꾸는 부분을 **파란색(blue)**으로 하이라이트하면서 작업을 시작한 게 보입니다. 굵게(bold) 처리하거나, 모든 폰트를 **초록색(green)**으로 바꾸는 같은 것도 할 수 있지만, 지금은 문서 전체를 아주 빠르게 처리하고 있습니다. 다시 말해, 스코어카드(scorecard)처럼 동일한 포맷을 유지한 채로 업데이트하고 조정하되, 미션(mission)과 오브젝티브(objective)처럼 변하지 않는 항목은 그대로 유지합니다. 그 부분은 건너뛰었죠. 달마다 바뀌는 게 없으니까요. 다음으로, 팀 예산을 다루고 다음 회계연도에 대한 마케팅 활동을 이해하는 방법을 보여드리겠습니다. 다시 agent mode를 쓰고, FY25(Fiscal Year 25) 마케팅 지출에서 무엇이 커밋(committed)되어 있고, 무엇이 계획(planned)되어 있으며, 무엇이 위험(at risk)한지 더 잘 이해하도록 도와달라고 요청하겠습니다. 그리고 이해가 쉬우도록 시각적 대시보드(visual dashboard)로 만들어 달라고 할 겁니다. Word의 agent mode와 마찬가지로, Excel의 agent mode는 왼쪽에서 Excel을 ‘네이티브하게’ 말하며, 숫자만이 아니라 실제 수식(formulas), 네이티브 차트(native charts)와 테이블(tables) 등도 함께 만들어 줍니다. 그래서 에이전트가 워크시트 안에서 무엇을 하고 있는지 제가 실제로 이해할 수 있습니다. 또 작업하는 동안 오른쪽에서는, 대시보드를 어떻게 세팅하고 무엇을 해야 하는지 등 ‘무엇을 하고 있는지’를 계속 설명합니다. 그래서 매니저 Nicole이 와서 “어떻게 이 답에 도달했어?”라고 물어보면, 에이전트가 한 일을 단계별로 설명할 수 있습니다. 다시 말하지만, 예전에는 이런 작업에 몇 시간이 걸렸습니다. Satya가 말했듯, 제 데이터에서 전반적인 인사이트를 얻는 것 자체가 시간이 많이 들었죠. 하지만 여기서는 agent mode가 제 데이터가 이미 있는 그 자리에서 계속 작업할 수 있게 해주고, 이런저런 ‘지저분한(messy) 데이터’를 제가 더 이해하기 쉬운 단순한 형태로 끌어모으면서 구축할 수 있게 해줍니다. Excel의 agent mode는 조건부 서식(conditional formatting)처럼 단순한 것도 할 수 있습니다. 예를 들어 위험(at-risk) 지표를 전부 **빨간색(red)**으로 하이라이트하고 싶다면 그것도 해줍니다. 그리고 지금 우리가 보는 것처럼, 불과 1분 남짓한 시간 안에 전체 마케팅 대시보드가 만들어졌습니다. 제가 클릭해 들어가 보면, 어떤 복잡한 수식을 썼는지, 어떤 조건부 서식을 써서 위험·커밋 항목을 표시했는지 볼 수 있습니다. 또 테이블을 만들었다는 것도 보여주는데, 이것 역시 Excel에 완전히 네이티브한 것입니다. 저는 필요에 따라 편집하고 조정할 수 있습니다. Copilot은 제 일을 더 빠르게 만들어 준 것뿐 아니라, 실제로 더 큰 임팩트를 내도록 도와줬습니다. 이제 Copilot 없이 일하는 건 상상하기 어렵습니다. Satya, 다시 넘기겠습니다. SATYA NADELLA: 고마워요, Zoe(박수). 정말 고마워요. 진척을 보니 정말 흥미롭습니다. 사실 어젯밤에 제가 뭔가를 쓰고 있었는데, 원래는 말하면 안 된다고 들었습니다만, 내일은 더 이야기할 수 있을 겁니다. 또 **새 모델 드롭(model drop)**도 있을 텐데, 그게 전체 경험을 한 단계 끌어올릴 겁니다. 이제 여러분은 경험 레이어, agent mode에 대한 접근, 그리고 우리가 만든 에이전트들을 조금 보셨습니다. 제가 가장 기대하는 점은, 여러분이 만든 어떤 에이전트든 그 캔버스(canvas) 컨텍스트 안에서 ‘발견(discover)’될 수 있다는 것입니다. 제게는 그게 정말 흥미롭고, 게임 체인저가 될 겁니다. 그 아래의 다음 레이어는 제가 **IQ 팩토리 레이어(IQ factory layer)**라고 부르는 것입니다. 우리가 ‘컨텍스트 엔지니어링(context engineering)’이라고 말할 때, 가장 중요한 엔지니어링 고려사항 중 하나가 바로 이것입니다. 경험이 있고, 에이전트가 있다면, 거기에 ‘관련 있는’ 컨텍스트 데이터를 제대로 먹이는 것이 매우 중요합니다. 그 컨텍스트에서 가장 좋은 부트스트랩(bootstrap)은 조직 안에서 아마도 가장 중요한 데이터베이스, 즉 Microsoft 365 아래에 있는 데이터베이스일 겁니다. 사람(people)과 그들의 관계, 그들이 다루는 작업 산출물(work artifacts)과의 관계(OneDrive나 SharePoint에 있는 파일들), 프로젝트, 팀의 미팅과 대화(conversations), 이메일 등 모든 것이 work IQ로 함께 묶일 수 있습니다. 그리고 또 하나의 축은, 모두가 Power BI를 쓰고 있다는 점입니다. Fabric을 보면 Power BI 데이터뿐 아니라, 오늘날의 운영 데이터(operational data), 분석 데이터(analytic data), 실시간 데이터(real-time data), 시계열 데이터(time series data)까지 모두 갖고 있습니다. 하지만 무엇보다 중요한 건, Power BI가 **시맨틱 레이어(semantic layer)**를 이미 부트스트랩해 두었다는 점입니다. 단지 데이터만 있는 것이 아니라, 데이터의 ‘의미(semantics)’가 함께 있는 거죠. 이것이 우리가 말하는 Fabric IQ입니다. 여기에 Foundry IQ는 비정형(unstructured) 데이터까지 가져와서 함께 묶습니다. 결국 Foundry를 통해 이 모든 것 위에서 RAG를 할 수 있게 됩니다. 그리고 단순 RAG가 아니라, graph RAG, multi-hop RAG도 가능합니다. 즉, work IQ + Fabric IQ + Foundry IQ를 결합하고, Foundry가 모델 레이어에 넣어야 할 ‘올바른 컨텍스트’를 구축(build)해 주는 겁니다. 이것이 IQ 레이어가 하는 일이고, 우리는 이를 통해 에이전트 개발을 다음 단계로 끌어올리는 데 큰 기대를 걸고 있습니다. 이제 경험이 있고, 데이터와 IQ 레이어가 있고, 그 다음은 에이전트를 ‘만드는’ 일입니다. 그래서 툴 체인이 중요합니다. 우리에게 에이전트 팩토리는, 사실 진입점(entry point)이 아주 많습니다. Copilot 안에 내장된 agent builder가 있고, 그리고 app builder도 있습니다. 이건 ‘프롬프트에서 앱으로(prompt to app)’ 가는 것입니다. 제가 1992년에 입사한 날부터 지금까지 늘 생각해 온 것이, ‘문서(document)와 웹사이트(website)와 애플리케이션(application)의 차이가 대체 뭐지?’라는 질문이었습니다. 그런데 이제는 차이가 없습니다. app builder 같은 것으로 자연어만으로 문서도, 앱도, 웹사이트도 만들 수 있습니다. 정말 흥미롭습니다. 그리고 Copilot Studio도 같은 개념을 에이전트에 적용합니다. 자연어 프롬프트로 시작해, 특정 지식(knowledge)에 그라운딩(grounding)해서 프롬프트만으로 에이전트를 만들어 갈 수 있을까요? 그게 Copilot Studio입니다. 그리고 여기서 끝(클리프)이 없습니다. 곧바로 Foundry로 갈 수 있고, Foundry는 에이전트뿐 아니라 **멀티 에이전트 시스템(multi-agent systems)**을 만들기 위해 필요한 서비스를 제공합니다. 이것이 Microsoft Foundry가 하는 일입니다. 그 위에는 모델 레이어가 있습니다. 우리는 **11,000개(11,000+)**가 넘는 모델을 갖고 있습니다. 흔히 말하는 ‘usual suspects’도 모두 있고, 모델 드롭도 매일 이어집니다. 그래서 여러분은 그 모든 모델에 접근해, 멀티 에이전트·멀티 모델 시스템을 만들 수 있습니다. ‘왜 11,000개나 되는 모델이 필요하냐’고 물을 수도 있겠죠. 어제 저는 Microsoft가 Providence, University of Washington과 함께 한 작업으로 발표한 Cell 논문, GigaTIME에 관한 글을 읽을 기회가 있었습니다. 가끔 우리는 게임을 하느라 ‘왜 게임을 하는지’를 잊곤 하는데, 그 논문은 왜 우리가 이 일을 하는지 다시 상기시켜 줬습니다. GigaTIME이 하는 일을 아주 단순하게 말하면 이렇습니다. 오늘날 특정 암 종양(cancerous tumor)에 면역치료(immunotherapy)가 효과가 있을지 알아보려면, ‘IMF’라는 매우 정교한 테스트가 필요합니다. 비용도 많이 들고, 시간도 오래 걸립니다. 그래서 팀은 ‘생성형 AI(gen AI)’로 그 테스트를 시뮬레이션(simulate)할 수 없을까를 생각했습니다. 단순한 병리 슬라이드(pathology slide)에서, 고도화된 공간 단백질체학(spatial proteomics) 테스트를 시뮬레이션하는 것을 상상해 보세요. 그러면 면역 시스템이 작동하는지 여부를 더 잘 파악할 수 있고, 정밀 종양학(precision oncology)도 더 좋아질 수 있습니다. 여기에 Ayushman Bharat 같은 것을 결합하면, 이 나라 어느 도시의 어떤 병원이라도 이런 모델을 이용해 검사를 수행하고, 정밀 종양학을 **대규모(scale)**로 가능하게 만드는 스타트업이 나올 수도 있습니다. 이게 바로 우리가 왜 더더욱 ‘더블 다운(double down)’해야 하는지, 왜 이 게임을 하는지 보여주는 이유라고 생각합니다. 그걸 잊지 않는 게 중요합니다. 이 모든 것을 Microsoft Foundry에서 1급(first-class) 툴 체인으로 만들고, 개발자 도구(developer tools)로 감싸는 일도 중요합니다. GitHub, Visual Studio 등으로 대표되는 개발자 도구 회사로서의 정체성은 우리에게 매우 큰 우선순위입니다. GitHub의 진전을 보는 것도 정말 의미가 큽니다. 사실 인도는 2030년까지 GitHub에서 세계 1위 커뮤니티가 될 것으로 예상되고 있습니다(박수). 이곳에서 나오는 프로젝트, 인도에서의 기여를 보는 것은 정말 환상적입니다. 우리는 GitHub를 본질적으로 agent HQ로 만들고 있습니다. 요즘 모두가 하는 재미있는 일은, 아침에 GitHub 리포지토리(repo)에 들어가 Copilot을 켠 다음, 에이전트 다섯 개를 던져서 일을 시키고, 폰으로 계속 돌아와 확인하는 것입니다. 제 일상도 이제는 받은 편지함(inbox)보다, 토큰(tokens) 수를 보는 쪽에 더 가까워졌습니다. 사실 제 아내가 제 신용카드를 뺏어 갔을 정도예요. 그래도 GitHub로 계속 놀면서 끊임없이 수정해 갈 수 있다는 게 재미있습니다. 어떤 의미에서는 ‘온디맨드 소프트웨어(software on demand)’에 가깝죠. 그리고 GitHub의 프리미티브(primitives)와 VS Code/Visual Studio, 그리고 여러 폼팩터(form factors) 사이의 ‘결합 조직(connective tissue)’을 만드는 일도 매우 중요합니다. 사람들이 ‘무엇을 쓰고 있냐’고 물으면, 저는 ‘전부 쓴다’고 답합니다. GitHub CLI도 쓰고, VS도 쓰고, agent mode도 쓰고, 자율(autonomous) 에이전트도 씁니다. 어떤 한 가지 폼팩터만 중요한 게 아니라, 사실 모든 폼팩터가 중요합니다. 그래서 이 모든 것을 하나의 응집된(cohesive) 툴 체인 시스템으로 만드는 일이 너무나 중요합니다. 이 모든 것을 보여드리기 위해, 언제나 그렇듯 GitHub 팀의 Karan을 소개하겠습니다. Karan, 부탁합니다. KARAN M V: 고마워요, Satya. 몇 주 전 GitHub Universe에서 우리는 Agent HQ를 발표했습니다. Agent HQ는 모든 에이전트를 하나로 묶어, 여러분이 이미 익숙한 GitHub 플로우(flow) 안에서 ‘네이티브하게’ 동작하도록 만드는 에이전틱(agentic) 플랫폼입니다. 그게 어떤 모습인지 데모로 보여드리겠습니다. 여기 향수를 자극하는 장난감들을 파는 스토어프런트(storefront) 데모 앱이 하나 있습니다. 아마 많은 가정에서 익숙한 장난감들일 겁니다. 그런데 보시다시피 검색(search)이나 필터(filter) 옵션이 전혀 없어서, 그 기능을 추가하고 싶습니다. 여기가 GitHub에 있는 제 코드 리포지토리(repo)입니다. 새로운 agents 패널을 통해, 저는 GitHub 어디에서든 작업을 설명하고 Copilot 코딩 에이전트(coding agent)에게 위임(delegating)하는 방식으로 에이전틱 작업을 시작(kick off)할 수 있습니다. Copilot은 백그라운드에서 그 작업을 진행합니다. 저는 github.com에서든, VS Code에서든, CLI에서든, 심지어 모바일에서도 작업을 Copilot에게 할당할 수 있습니다. 자, 이제 여러 리포지토리와 여러 작업을 동시에 하면서 저는 많은 작업을 Copilot에게 위임해 두었습니다. 그리고 이제 단일 ‘미션 컨트롤(mission control)’ 화면에서, 진행 중인 세션과 완료된 세션을 한눈에 볼 수 있습니다. 또 여기서 바로 에이전트 작업을 새로 시작할 수도 있고, 제가 만든 커스텀 에이전트(custom agents)나 파트너가 만든 커스텀 에이전트도 사용할 수 있습니다. 이 커스텀 에이전트들은 특정 도메인의 전문가로서, Copilot 코딩 에이전트를 여러분의 모든 도구와 워크플로우 전반으로 확장(extending)해 줍니다. 그럼 방금 시작한 에이전트 세션으로 들어가 Copilot이 무엇을 하고 있는지 보겠습니다. 왼쪽에는 Copilot의 진행 상황(progress), 오른쪽에는 드래프트 PR(draft PR)이 보입니다. 개발자인 저는 여전히 통제권을 갖고 있습니다. 즉, 진행 중인 세션을 중간에라도 ‘조종(steer)’해서 Copilot이 약간 다른 방향으로 일하도록 유도할 수도 있습니다. 이건 몇 분 걸릴 테니, Copilot이 계속 진행하도록 두겠습니다. 그 사이에, 이전에 같은 기능을 위해 제가 먼저 시작해 둔 다른 에이전트 세션을 보겠습니다. 설명이 있고, 오, 멋진 스크린샷도 있네요. Playwright MCP 덕분입니다. 또 Copilot이 변경한 파일들을 모두 확인할 수 있고, 필요하다면 추가 변경을 요청할 수도 있습니다. 그리고 Copilot에게 뭐든 물어보고 싶으면 여기서 바로 채팅(chat)으로 들어갈 수 있습니다. Copilot은 다양한 모델(model)과 다양한 프로바이더(provider)를 선택할 수 있게 해주는데, 그게 전부가 아닙니다. Microsoft Foundry에서 제가 직접 가져온(bring in) 모델도 사용할 수 있습니다. 저는 Foundry에 몇 가지 모델을 배포(deployed)해 두었고, 그중에는 제가 직접 파인튜닝(fine-tune)한 모델도 있습니다. 이 모델들을 Foundry 배포와 연결(connect)해 Copilot에 가져오면, github.com에서도, VS Code에서도 Copilot 안에서 이 모델을 직접 사용할 수 있습니다. 재미로, 제가 파인튜닝한 모델 하나는 벵갈루루 개발자처럼 말하도록 만들어 봤습니다. 그래서 아주 단순한 질문, “500 internal server error가 뭐야?”라고 물어보면, “I don't know on the response kodthade.” 같은 식으로 말합니다. 이 말투는 제가 Foundry에 배포한 제 모델에서 나온 것입니다. 에러와 앱 이야기가 나온 김에, 저는 앱에 새 제품 상세 페이지(product detail page)를 구현하는 PR을 만들어 두기도 했습니다. 여기 보시면 Copilot이 그것도 리뷰(review)해서 코멘트를 남겼습니다. 예를 들어 여기에는 DB 커넥션 풀(connection pool) 고갈(exhaustion)에 대한 언급이 있고, 또 다른 곳에는 타입 안정성(type safety)에 대한 이야기도 있습니다. 이것이 새로운 에이전틱 Copilot 코드 리뷰(agentic Copilot code review)입니다. LLM 탐지(detections), 툴 호출(tool calling), 그리고 결정론적 스캔(deterministic scans)을 결합해 더 똑똑한 리뷰를 제공합니다. 그리고 그것만이 아닙니다. 저는 Copilot에게 이 제안들을 ‘한 번에’ 구현하도록 요청해, 단일 PR에서 처리하는 에이전틱 작업을 시작할 수도 있습니다. Copilot이 그 작업도 백그라운드에서 계속 진행하도록 두겠습니다. 보안(security)이 얼마나 중요한지는 모두 잘 아시죠. 다행히 저는 이 GitHub 계정의 보안 관리자(security admin)이기도 합니다. Microsoft Defender for Cloud와 GitHub Advanced Security의 새로운 통합을 통해, Defender가 프로덕션(production) 환경에서 식별한 런타임 리스크(runtime risk) 이슈만 따로 필터링할 수도 있습니다. 여기 보시면 그런 이슈들이 있고, 이를 해결하기 위한 캠페인(campaign)도 만들어져 있습니다. 앗, 제 리포에도 일부가 보이네요. 하지만 걱정할 필요는 없습니다. Copilot이 이런 보안 이슈도 고쳐줄 수 있습니다. 저는 여기서 전부 선택하고 ‘assign to Copilot’을 누르면, 이 알림(alert)들을 역시 단일 PR로 처리하는 작업이 시작됩니다. 여러 에이전트가 각자 다른 일을 백그라운드에서 하는 동안, 저도 코드를 직접 작성합니다. 여기가 앞서 보던 검색·필터링 기능에 대한 에이전트 세션이고, 저는 여기서 몇 가지 변경을 더 하고 싶습니다. 이 작업은 VS Code에서 바로 열어서 계속 반복(iterate)할 수 있습니다. 그러면 VS Code가 열리고, 브랜치를 체크아웃(check out)하거나 변경사항을 바로 적용(apply)한 뒤 계속 진행할 수 있습니다. 그리고 Copilot을 열어 agent mode를 선택하고, Foundry에서 가져온 커스텀 모델과 함께 아주 작은 변경을 또 요청할 수도 있습니다. 그 작업은 로컬에서 agent mode로 계속 돌려두겠습니다. github.com에서처럼 VS Code에도 미션 컨트롤 뷰가 있어서, 로컬 agent mode에서 돌고 있는 세션, 클라우드에서 돌고 있는 세션, CLI에서 돌고 있는 세션까지 한곳에서 볼 수 있습니다. 몇 가지 기능을 이야기했지만, 제가 정말 만들고 싶은 기능이 하나 더 있습니다. 장난감들을 번들(bundle)로 묶어서 ‘플레이 박스(play box)’로 제공하는 기능입니다. 여러분도 좋아하실 겁니다, 그렇죠? 다만 구현 방법을 먼저 계획(plan)해야 합니다. VS Code의 새로운 plan agent를 사용하면, Copilot에게 구현 계획을 만들게 하고, 제가 확신이 들 때까지 질문을 던지며 계속 다듬을 수 있습니다. 여기 이미 제가 만들어 둔 계획이 있고, 준비가 되면 제가 직접 코딩할 수도 있고, 에이전트에게 넘겨 구현을 돕게 할 수도 있습니다. 이번에는 Copilot CLI 에이전트에게 넘겨서 백그라운드에서 작업하게 하겠습니다. 이 모든 작업이 완료되면, 앱은 이렇게 보일 겁니다. 멋진 필터 바(filter bar)가 생기고, 여기서 우리가 실제로 즐길 수 있는 꽤 좋은 게임들도 보이죠. 즉, 지난 몇 분 동안 우리는 아이디어에서 출발해, github.com에서 Copilot 에이전트로 코딩하고, VS Code와 CLI에서도 작업하고, 에이전틱 Copilot 코드 리뷰로 리뷰를 받고, Copilot auto-fix 에이전트로 보안 이슈 수정을 구현했습니다. 그 모든 과정에서 GitHub와 VS Code의 미션 컨트롤 뷰로 모든 에이전트를 보고, 하나의 화면에서 조종(steer)할 수 있었습니다. 이것이 Agent HQ입니다. 감사합니다. Satya에게 다시 넘기겠습니다. SATYA NADELLA: 고마워요, Karan. 여러분도 이런 데모를 보면 “와, 나도 저렇게 할 수 있어야 하는데”라고 생각하실 겁니다. 몇 주 전 미국에서는 추수감사절(Thanksgiving) 연휴가 있었는데, 그때 저는 ‘추수감사절에 만드는 것(building) 말고 또 뭘 할 수 있지?’라고 생각했고, Karan이 보여준 것들을 그대로 써서 제 앱을 하나 직접 만들었습니다. 여기가 제 Azure 환경입니다. 참고로 이건 제가 여행할 때 들고 다니는 ‘평소 PC’라서, 아무 일도 없길 바랍니다만…(웃음) 어쨌든 앱은 아마 southcentral Canada에 배포해 둔 걸로 기억합니다. 여기가 제 GitHub 리포이고, 꽤 재미있습니다. 제 전형적인 셋업은 사실 Windows 365입니다. 거의 어디든 저와 함께 다니죠. 그 안에 GitHub가 있고, 거기에 Codespaces가 있습니다. 그러니까 ‘거북이 위에 거북이(turtles all the way)’ 같은 느낌입니다. Windows 365 인스턴스 안에서 GitHub의 Codespaces가 돌아가는 구조니까요. 그리고 아침에 들어가서 코딩 작업을 막 던지는 게 제 가장 좋아하는 일입니다. 저는 보통 아침에 다섯, 여섯 가지 일을 한꺼번에 던집니다. 그러면 다섯, 여섯 개의 드래프트 브랜치(draft branches)가 생기고, 결국 하루 끝에는 대부분 브랜치를 삭제하지만, PR 한두 개는 받아들이고 계속 작업을 이어가기도 합니다. 재미있죠. 그리고 이제는 모델(model)이 정말 많습니다. 요즘 저는 Codex Max도 많이 쓰고 있습니다. 정말 훌륭하고 빠릅니다. 물론 Claude Opus 4.5도 씁니다. 그런데 제가 익숙해진 건, ‘auto’를 눌러서 알아서 고르게 하는 것입니다. 저는 토큰 한도(token limits)를 효율적으로 쓰고 싶을 때가 많은데, ‘auto’가 정말 괜찮은 방식처럼 느껴집니다. 자, 그럼 제가 뭘 만들었을까요? 제 꿈은 ‘이 Copilot 팀에서 일자리를 얻는 방법’을 알아내는 것이었습니다(웃음). 그래서 저는 ‘딥 리서치(deep research) 기능은 마음에 드는데, 딥 리서치에 더 많은 것을 얹고 싶다’고 생각했고, 제 나름의 딥 리서치를 만들었습니다. 모델이 많아졌으니, ‘새로운 의사결정 프레임워크(decision framework)’를 넣어보자고 했습니다. 그중 하나가 Andrej Karpathy가 최근에 이야기했던 LLM Council 아이디어입니다. 저는 그게 정말 마음에 들었습니다. 그래서 이제 여러분은 사용 가능한 모든 모델을 넣을 수 있습니다. GPT, Opus, Gemini, Kimi K2, Grok 등등, 원하는 모델들을 고를 수 있습니다. 그리고 의장을 하나 선택합니다. 즉, 위원(council members) 또는 선정위원회(selection committee)가 있고, 그 위에 의장(chair)이 있는 구조입니다. 그 다음 어떤 질의를 던지면, 각 모델이 답을 내고, 의장이 종합해 ‘무엇을 어떻게 생각하는지’를 알려줍니다. 제가 구현한 또 다른 의사결정 프레임워크는 DxO라는 것입니다. 이건 우리가 처음에는 헬스케어에서 구현했던 것입니다. 여기 보이죠. DxO는 역할(role)을 나눕니다. 예를 들어 리드 리서처(lead researcher)는 Opus로 두었습니다. 이 역할은 폭넓은(breadth-first) 리서치를 수행합니다. 그리고 비판적 리뷰어(critical reviewer)는 GPT 5.1을 골랐습니다. 이 역할은 특히 방법론 오류(method errors), 편향(bias)과 최신성 편향(recency bias) 같은 것을 찾아냅니다. 그리고 데이터 분석가(data analyst) 역할에는, 도메인 전문가(domain expert)로 Gemini를 선택했습니다. 또 데이터 분석가로는 Kimi K2를 선택했습니다. 우리가 DxO 논문을 발표했을 때, 이 방식은 어떤 단일 최전선 모델(frontier model)보다 더 나은 성능을 보였습니다. 특히 매우 높은 수준의 ‘고위험(high stakes)’ 건강 결과를 다루는 맥락에서요. 저는 ‘내가 내리는 어떤 의사결정에도 이런 방식을 쓰고 싶다’고 생각했고, 그래서 이를 구현했습니다. 또 하나는 Ensemble입니다. 이건 모든 모델을 MCP 서버들의 집합처럼 쓰는 방식입니다. 각 응답에서 누가 답했는지(누가 어떤 모델인지) 정보를 제거(anonymize)합니다. 즉, 응답자를 alpha, beta, gamma처럼 표시해 익명화한 뒤, 하나의 응답으로 합성(synthesize)합니다. 이렇게 세 가지 의사결정 프레임워크를 만들었습니다. 사실 저는 이걸 더 확장했습니다. 쇼핑(shopping)도 만들고, 파이낸스(finance)도 만들었습니다. 핵심은 ‘의사결정 프레임워크’입니다. 그리고… ‘제대로 된’ 남아시아 크리켓(cricket) 팬이라면 이걸 어디에 쓰겠습니까?(웃음) 인도 역대 최고의 테스트 크리켓 팀(all-time best Indian test cricket team)을 고르는 데 쓰는 거죠. 특히 지난 테스트 시리즈에서 있었던 일을 생각하면, 이제는 일을 해야 할 때입니다. 그래서 저는 히스토리(history) 쪽을 보여드리겠습니다. 사실 제가 주로 이걸 어디에 쓰는지 보면… MLB 라인업(lineup)도 정말 미쳤을 정도로 좋았지만, 테스트 팀이 핵심입니다. 자, 무슨 일이 있었냐면요. 여기 보이는 건 ‘의장 종합(chairman synthesis)’입니다. AI Council 결과죠. 예를 들어 Sunil은 오프닝을 하고, Sehwag가 그와 함께 오프닝을 하고, Dravid가 들어가고, 당연히 Tendulkar가 있고, 이런 식으로 팀을 구성합니다. 여기 보시면, 완전한 컨센서스(consensus) 영역으로 Gavaskar, Sehwag, Dravid, Tendulkar, Kohli, Kapil Dev, Ashwin, Bumrah가 있습니다. 그리고 핵심 논쟁(key debates)도 나옵니다. 예를 들어 VVS를 넣을 것인가 말 것인가. 또 결정이 어떻게 내려졌는지도 보이죠. GPT 5.1은 ‘Claude가 Laxman을 포함시킨 이유를 위기관리(crisis management) 관점에서 매우 크게 반영했다’고 말합니다. 저는 하이데라바드(Hyderabad) 사람으로서 GPT 5.1과 Claude를 정말 좋아합니다(웃음). 그리고 Kumble versus Zaheer. 꽤 재미있죠. 왼손 스윙(left arm swing)이 필요한가, 아니면 Kumble이 하는 — 뭐라고 불러야 할지 모르겠지만 — 그런 볼링이 필요한가(웃음). 결국 통계가 이겼습니다. 619 wickets라는 기록을 근거로 Kumble을 선택했습니다. 그리고 주장(captaincy) 논쟁, Kohli versus Dhoni에서는 Kohli를 선택했습니다. 이렇게 결과가 나오고, 그 뒤로 주석(annotation)까지 달립니다. 참고로 제가 좋아하는 점은, 이것을 스트리밍(streaming) 형태로 구현해 두었다는 것입니다. 만약 이게 southcentral Canada에 배포되어 있지 않았다면 여기서 바로 보여드릴 텐데, 어쨌든 핵심은 ‘생각의 사슬(chain of thought)’이 아니라, 사실상 ‘논쟁의 사슬(chain of debate)’을 볼 수 있다는 점입니다. 모델들이 서로 논쟁하고, 그걸 종합(synthesize)하는 과정을 제가 볼 수 있습니다. 어쨌든, Ensemble도 같은 식입니다. 제가 말하고 싶은 요점은 이겁니다. 저는 이걸 대략 몇 시간(두어 시간) 안에 만들었고, 지금도 계속 다듬고 있습니다. 그리고 앞서 말했듯, 언젠가는 Copilot 팀에서 일할 수 있기를 바랍니다. 참고로 이건 전부 Copilot에 들어올 겁니다. 저는 친구들을 설득하고 있는데, 친구들은 “그래, 충분히 유능하면 주니어 프로덕트 매니저(junior product manager)로 지원할 수 있겠다”고 하더군요. 그래서 저는 지금도 면접 중입니다(웃음). 하지만 저는 이런 것들이 결국 다 들어올 거라고 생각합니다. 왜냐하면 이것이 제게는 ‘다음 세대의 메타인지(metacognition)’이기 때문입니다. 이런 의사결정 프레임워크를 생각해 보면, 우리는 많은 에이전트와 함께 일하지만, 메타인지는 여전히 인간(우리)에게 남아 있습니다. 그래서 저는 이것을 ‘메타인지를 위한 도구(tools for metacognition)’라고 봅니다. 인도 테스트 크리켓 팀을 고르는 데도 재미있지만, 공급망(supply chain) 의사결정이든, 헬스케어 의사결정이든, 파이낸스(finance) 의사결정이든, 여러 에이전트가 참여하는 이런 ‘논쟁의 사슬’은 우리가 앞으로 에이전틱 시스템(agentic systems)에서 많이 만들게 될 것입니다. 저는 이게 정말 기대됩니다. 그리고 여기에서의 모멘텀도 대단합니다. 참, 모멘텀 이야기로 넘어가기 전에 Agent 365에 대해 말씀드려야겠습니다. 저는 방금 보여드린 것들을 모두 만들었고, 심지어 이것을 Copilot 안에서 ‘선언형(declarative) 에이전트’로 만들고 싶었습니다. 그래서 커넥터(connector)를 만들고, 훌륭한 API로 연결하는 등 ‘힘든 일’을 다 했습니다. 그리고 “좋아, 이제 배포(deploy)하자”라고 했더니, outcomes DLP가 “안 돼(No, you can't)”라고 하더군요. 그건 Agent 365 덕분이었습니다. 왜냐하면 Agent 365는 악의적(malicious) 에이전트로부터 테넌트(tenant)를 항상 보호하는 런타임(runtime)이기 때문입니다. Agent 365의 아이디어는 Entra, Defender, Purview를 가져와서, 그것을 모든 에이전트로 확장하는 것이었습니다. 제가 만든 에이전트를 Microsoft 테넌트에서 배포하려고 하자, 시스템은 “승인을 받아야 한다”라고 했습니다. 우선 그것은 제 개인 테넌트(private tenant), 즉 Azure의 개인 구독(subscription) 위에 배포되어 있었기 때문에, “먼저 Microsoft 테넌트로 옮겨야 하고, Microsoft 테넌트로 옮기려면 관리자(admin)에게 가야 한다”라고 했습니다. 그래서 저는 거기서 걸려 더 진행하지 못했습니다. 그런데 이게 바로 Agent 365 덕분에 가능했던 차단이었고, 좋은 일입니다. 왜냐하면 Agent 365 런타임은 멀티 에이전트, 에이전틱 세계에서 ‘핵심, 핵심, 핵심’ 조직 레이어(organizing layer)가 될 것이기 때문입니다. 여기에는 완전한 관측가능성(observability), 컴플라이언스(compliance), 거버넌스(governance) 같은 것들이 포함될 것입니다. 우리는 이 모든 것에서 엄청난 모멘텀을 보고 있습니다. 그리고 오늘 아침에도 많은 ‘만드는 사람들(builders)’을 만나볼 기회가 있었습니다. 예를 들어 Cognizant의 개발자들은 자신들의 멀티 에이전트 프레임워크를 직접 만들었고, 그것을 회사 내부에서 이미 매우 높은 볼륨(high-volume)의 애플리케이션에 배포해서 쓰고 있었습니다. Wipro는 Fabric의 데이터 에이전트(data agents)를 사용해 세일즈와 파이낸스, 그리고 전체 기능(function)이 어떻게 변할 수 있는지 생각하는 방식 자체를 완전히 바꿨습니다. Collective Artists Network 팀도 만났는데, 그들은 애니메이션 장편 영화(animated feature films)를 만들기 위한 툴 체인(tool chain)을 보여줬습니다. 그들은 AI 스튜디오(AI studio)를 만들고 있습니다. Hanuman이 곧 나온다고 들었고, 그들은 과거에 Mahabharat도 만들었죠. 정말 멋진 것은, 그들이 자신들의 모델과 오케스트레이터(orchestrator)로 전체 파이프라인(pipeline)을 구축했고, 이제 누구나 사용할 수 있게 만들어 놓았다는 점입니다. Persistent도 Cognizant처럼 비슷한 방식으로, 회사 전반에 배포할 수 있는 자신들의 작업을 해왔습니다. PhonePe는 멋진 애플리케이션을 보여줬습니다. Foundry Local을 사용해서 앱에서 훌륭한 검색(search)을 구현했을 뿐 아니라, Foundry Local로 **온디바이스(on-device)**에 배포되는 모델도 만들었습니다. 정말 대단했습니다. 그리고 Swiggy의 개발자들을 만난 것도 매우 반가웠습니다. 그들은 Fabric과 Fabric의 실시간 데이터(real-time data), Fabric 에이전트(agents)를 사용해 퀵 커머스(quick commerce)를 다음 단계로 끌어올리고 있었습니다. 그럼 영상으로 보시죠. 비디오를 틀어주세요. MADHUSUDHAN RAO: Swiggy는 인도의 대표적인 음식 배달 및 퀵커머스(q-commerce) 기업 중 하나입니다. 우리는 **700개 이상(700+)**의 도시에서 서비스를 제공하고, **수십만 명(hundreds of thousands)**의 드라이버가 있으며, **1억 명 이상(over 100 million)**의 고객을 지원합니다. 우리 고객들은 ‘속도(speed)’, ‘선택(selection)’, ‘가격(price)’을 정말 중요하게 생각합니다. IPSITA DUTTA GUPTA: 교통 체증 때문에 장을 보는 게 정말 어렵고, 업무 일정도 너무 바쁩니다. 앱이 30분이 지나서야 배달해 주길 기다릴 수는 없어요. MADHUSUDHAN RAO: Instamart는 우리의 퀵커머스 플랫폼으로, 고객은 1,000개 이상(over a thousand)의 다크스토어(dark stores)에서 식료품과 생활필수품을 주문할 수 있습니다. 그리고 이 모든 것은 10분(10 minutes) 안에 배송되어야 합니다. 10분 배송은 어렵습니다. 이를 위해서는 우리가 내리는 모든 의사결정 뒤에 방대한 데이터가 있습니다. 우리는 신호등(traffic signals), 라이더(riders)가 어디에 있는지 등을 이해해야 하고, 이 모든 데이터를 모아 매우 짧은 시간 안에 분석해야 합니다. VIPINKUMAR TIWARI: 과거에는 서로 다른 소스에서 데이터를 가져와 변환(transform)하고, 비즈니스에 의미가 있도록 가공해야 했습니다. 그 과정은 몇 시간이 넘게 걸리곤 했습니다. Microsoft Fabric의 Real-Time Intelligence는 데이터 지연(latency)을 **분 단위(minutes)에서 초 단위(seconds)**로 줄이는 데 도움이 되었습니다. 또한 분석팀의 쿼리 실행 시간을 **수 시간(hours)에서 수 분(within minutes)**으로 줄이는 데도 도움이 되었습니다. Fabric RTI는 하루 **수백만 건(millions)**의 주문을 라이프사이클 전체에 걸쳐 추적(track)해, 고객에게 정확한 주문 상태(order status)를 제공하도록 해줍니다. 그 결과 수요 예측(demand prediction)과 재고 관리(inventory management)가 개선되었습니다. 이제 우리는 다크스토어에서 더 나은 가시성(visibility)을 확보해, 고객을 더 만족스럽게 서비스할 수 있습니다. IPSITA DUTTA GUPTA: 만약 앱이 **8분(8 minutes)**이나 **10분(10 minutes)**이라고 표시하면, 그 시간을 지킬 거라고 믿을 수 있어요. 그게 중요한 이유는 제가 그 시간을 기준으로 하루를 계획하기 때문입니다. 저는 여기저기 돌아다니며 심부름하는 것보다, 사람들과 함께 시간을 보내는 게 더 좋아요. 저는 그 경험이 정말 마음에 듭니다. SATYA NADELLA: 정말 멋지지 않습니까. 실제로 Swiggy는 다크스토어 전체와 중앙 커맨드 센터(central command center) 전반에서 Fabric을 사용하고 있었습니다. 그리고 이제는 당연히 실시간 데이터(real-time data)에 대해 ‘행동(act)’할 수 있는 추가 데이터 에이전트(data agents)까지 만들 수 있게 됐습니다. 이런 유형의 에이전틱 시스템(agentic systems)이 Swiggy에 실제로 배포되고 있다는 게 정말 흥미롭습니다. 자, 마지막 퍼즐 조각은 이겁니다. 이제 에이전트 팩토리(agent factory)가 있고, 여러분이 에이전트를 계속 만든다면, 이제는 가장 효율적인 **토큰 팩토리(token factory)**가 필요합니다. 결국 이 모든 것을 돌릴 인프라(infrastructure)가 필요하니까요. 그리고 이는 하나의 단순하지만 매우 중요한 방정식으로 귀결됩니다. 바로 **루피(rupee)당·와트(watt)당 성능(performance per rupee per watt)**입니다. 우리는 인도와 전 세계에서 구축하고 있는 모든 것을 통해, 그 방정식의 성능을 실제로 끌어올리고 있습니다. 우리는 Azure를 ‘세상의 컴퓨터(the world's computer)’로 만들고 있고, 전 세계에 **70개 이상(70+)**의 데이터센터 리전(data center regions)을 보유하고 있습니다. 인도에서도 이 발자국(footprint)은 계속 커지고 있습니다. 지금은 Central India, West India, South India가 있고, Jio와의 파트너십(partnership)도 있습니다. 그리고 우리는 **2026년('26)**에 South Central에 새로운 데이터센터(DC)를 오픈할 예정이라는 점이 매우 기대됩니다. 그리고 제게 가장 흥분되는 부분은, 그것이 **100% 지속가능(sustainable)**하다는 점입니다. 우리는 핵심을 놓치지 않고 있습니다(박수). 그곳은 **100% 재생에너지(renewable power)**로 운영됩니다. 우리는 인프라를 빠르게 확장할 뿐 아니라, ‘주권(sovereignty)’을 구현하고, 주권을 위한 선택지 포트폴리오(portfolio of options)를 마련하고 있습니다. 즉, 퍼블릭 클라우드(public cloud)가 있고, 퍼블릭 클라우드 안에서의 주권 통제(sovereign controls)도 있습니다. 예를 들어 여러분이 키 관리(key management)를 직접 갖고, 저장 시 암호화(encrypt at rest), 전송 시 암호화(encrypt in flight), 그리고 기밀 컴퓨팅(confidential computing)을 통해 사용 중(in use)에도 암호화할 수 있습니다. 따라서 퍼블릭 클라우드에서도 완전한 주권을 가질 수 있습니다. 그 위에, 주권 프라이빗 클라우드(sovereign private cloud)도 있습니다. 여러 로컬 파트너가 이런 주권 프라이빗 클라우드를 배포하고 싶어 합니다. 그리고 앞서 말했듯, Azure의 Jio 리전(region)도 있습니다. 즉 어떤 회사든 리스크 기반(risk-based) 의사결정을 통해, 퍼블릭 클라우드, 주권 서비스를 갖춘 퍼블릭 클라우드, 주권 프라이빗 클라우드, Jio 등 다양한 옵션 중 무엇이 최선인지 판단할 수 있는 포트폴리오가 존재합니다. 다만 주권을 논할 때 한 가지 더 반드시 함께 생각해야 할 요소가 있습니다. 바로 **사이버 레질리언스(cyber resilience)**입니다. 결국 사이버 보안(cybersecurity)은 ‘시그널(signals) 게임’이고 ‘인텔리전스(intelligence) 게임’입니다. 여러분이 주권적일 수는 있지만, 글로벌 인텔리전스(global intelligence)가 없다면, 사실상 취약해질 수 있습니다. 전 세계의 위협 행위자(threat actors)가 무엇을 하고 있는지 보지 못하면, 신호를 놓치게 되니까요. 그래서 리스크 방정식(risk equation)에서는 주권과 사이버 레질리언스를 별개가 아니라 ‘결합된 고려사항’으로 생각해야 합니다. 우리는 전 세계에서 일어나는 위협 행위를 보고, 매일 **수조(trillions)**에 달하는 신호를 수집해, 이를 일상의 방어(everyday defense)로 전환합니다. Azure에서든, M365에서든, Windows에서든 마찬가지입니다. 이것이 우리가 져야 할 핵심 책임이라고 생각하며, 그 책임은 당연히 모든 제품에 반영됩니다. 이 모든 맥락에서, 우리는 인도에 대한 투자로 ‘최고 수준(best-in-class)’ 인프라를 이곳에 가져오는 것을 매우 기대하고 있습니다(박수). 저는 며칠 전 총리(Prime Minister)를 만나, 인도에서 우리가 하려는 일들을 이야기했고, 특히 이 투자에 대해 매우 격려를 받았습니다. 이번 175억 달러($17.5 billion) 투자로 사회와 경제, 성장에 기여하고, 무엇보다 세계적 수준의 인프라에 대한 접근(access)을 제공하려 합니다. 이는 우리가 아시아에서 집행한 투자 중 **최대 규모(largest)**입니다. 그리고 이는 제가 지난번 인도 방문 때 발표했던 30억 달러($3 billion) 투자에 ‘추가로’ 더해지는 것입니다. 우리는 이 전체 스택(stack)을 인도로 가져오는 데 매우 기대하고 있습니다. 하지만 저는 처음에 말한 지점으로 돌아가 마무리하고 싶습니다. 결국 이 모든 것은 인도의 모든 사람과 모든 조직이 더 많은 것을 성취하도록 돕는 것입니다. 그리고 그 출발은, 이 나라의 인적 자본(human capital)이 기술을 갖추고(skilled), 자신감을 갖고(confident), 더 많은 것을 성취할 수 있어야 한다는 점입니다. 그래서 우리는 스킬링(skilling) 약속에도 더블 다운하고 있으며, 인도 전역에서 **2,000만 명(20 million)**에게 AI 스킬을 교육할 것입니다(박수). 어제는 노동부 장관(Minister of Labor)을 만날 기회도 있었는데, e-Shram 프로그램에 대해 듣는 것이 정말 인상적이었습니다. 비공식/비조직 노동(unorganized labor)을 AI로 부스트(boost)해 자격증명(credential)과 스킬을 갖추게 하고, 고용 기회(employment opportunity)를 얻도록 돕는 것은, 우리의 AI 주도 경제에서 가장 큰 혜택 중 하나일 수 있습니다. 정부가 이 기술에 관심을 갖고, 비조직 부문(unorganized sector)에 적용하려는 모습은 정말 멋집니다. 그럼 영상으로 마무리하겠습니다. 모두 정말 감사합니다. 그리고 계속 만들어 갑시다. (박수) ANJALI RAWAT: 인도에는 **4억 명 이상(more than 400 million)**의 비조직 노동자(unorganized workers)가 있습니다. 그들은 하루 벌어 하루 사는 일당(day-to-day wages)을 받지만, 어떤 혜택(benefits)도 받지 못하는 경우가 많습니다. 우리는 사람들을 비공식(informal) 부문에서 공식(formal) 부문으로 전환시켜야 합니다. 그래야 경제를 발전시킬 수 있습니다. e-Shram 이니셔티브를 통해, 국가 비조직 노동자 데이터베이스(national unorganized workers database)가 구축되었습니다. 그리고 우리는 그 노동자들에게 사회보장(Social Security) 혜택을 제공하고, National Career Service 포털에 접근할 수 있도록 하고 있습니다. MANOJ SAXENA: NCS는 구직자(job seekers), 고용주(employers), 훈련 제공자(training providers), 상담사(counselors)를 위한 원스톱(one-stop) 솔루션입니다. ANJALI RAWAT: 우리는 구직자의 스킬(skills)과 고용주의 요구를 AI 기반으로 매칭(AI-based matching)합니다. 그래서 어떤 비공식 노동자라도 NCS 포털로 들어가 적합한 고용주와 매칭될 수 있습니다. NCS에는 AI 이력서 빌더(AI resume builder)도 있습니다. 그리고 어떤 사람이 특정 스킬이 부족하다면, AI 도구가 추천(recommendations)을 제공해 그 스킬을 개발하도록 돕습니다. MANOJ SAXENA: 우리는 수백만 명(millions)의 비조직 노동자가 이 시스템에 등록할 것으로 예상했기 때문에, 확장성(scalability), 신뢰성(reliability), 보안(security)이 필요했습니다. Microsoft Azure는 이 모든 요건을 충족했습니다. 게다가 Azure OpenAI는 비조직 노동자들에게 게임 체인저(game-changer)가 되었습니다. ANJALI RAWAT: 현재 NCS 포털에는 약 **1억 5천만 명(around 150 million)**의 노동자가 등록되어 있습니다. 또 우리는 더 많은 제도(schemes)를 도입해 이 노동자들이 혜택을 받을 수 있도록 하려 합니다. AI는 이 나라의 개인과 청년들에게 기회를 제공하는 데 도움을 주고 있습니다.