▲

Claude Code가 마이크로소프트 내부에서 급속히 확산 중

 (theverge.com)
5P by GN⁺ 3시간전 | ★ favorite | 댓글 3개
  • Anthropic의 Claude Code가 Microsoft 내부에서 빠르게 확산되며, 개발자뿐 아니라 비개발자도 활용 중임
  • Microsoft는 GitHub Copilot을 외부 고객에게 판매하면서도 내부적으로는 Claude Code 사용을 장려하고 있음
  • CoreAI, Experiences + Devices 등 주요 부서에서 Claude Code를 테스트 및 설치 중이며, Windows·Teams·Surface 팀까지 포함됨
  • 마이크로소프트는 Anthropic과의 협력을 확대하며 Azure 판매 실적에도 Claude 모델을 포함시키고 있음
  • 이 변화는 AI 코딩 도구의 주도권 경쟁 속에서 마이크로소프트가 자사 생태계 내에서도 다양한 AI 모델을 병행 활용하는 흐름을 보여줌

마이크로소프트 내부의 Claude Code 확산

  • 마이크로소프트는 GitHub Copilot을 고객에게 판매하지만, 내부적으로는 Claude Code 사용을 확대 중임
    • 수천 명의 직원이 Claude Code를 설치하도록 권장받고 있으며, 비개발자도 포함됨
    • Claude Code는 개발자와 비기술자 모두에게 사용이 쉬운 도구로 평가받고 있음
  • Claude Sonnet 4 모델은 2025년 6월 개발자 부서에서 처음 도입되었고, 이후 GitHub Copilot 유료 사용자에게도 적용됨
  • 현재는 Anthropic의 AI 모델을 광범위하게 채택하며, 주요 엔지니어링 팀 전반으로 확산 중임

주요 부서와 사용 범위

  • CoreAI 팀과 Experiences + Devices 부문이 Claude Code를 테스트 및 설치 중임
    • Experiences + Devices 부문은 Windows, Microsoft 365, Outlook, Teams, Surface 등을 담당
  • 비개발자 직원도 Claude Code를 활용해 아이디어 프로토타입 제작 가능
  • Business 및 Industry Copilot 팀의 모든 코드 저장소에서도 Claude Code 사용이 승인됨

내부 테스트와 상용화 가능성

  • 마이크로소프트 엔지니어들은 Claude Code와 GitHub Copilot을 병행 사용하며 피드백을 제공해야 함
  • 내부 시범 운영이 성공하면, Claude Code를 클라우드 고객에게 직접 판매할 가능성도 있음
  • 마이크로소프트는 현재 Anthropic의 주요 고객 중 하나로, Anthropic AI 모델 판매를 Azure 실적에 포함시키고 있음

Anthropic과의 협력 확대

  • 2025년 11월 체결된 협약을 통해 Claude Sonnet 4.5, Claude Opus 4.1, Claude Haiku 4.5 모델이 Microsoft Foundry 고객에게 제공됨
  • Anthropic은 Azure 컴퓨팅 용량 300억 달러어치 구매를 약속함
  • 마이크로소프트는 Microsoft 365 앱과 Copilot 기능 내에서도 Claude 모델을 채택 중이며, 특정 기능에서는 OpenAI 모델보다 우수한 성능을 보임

내부 AI 도구 사용 현황과 변화

  • 마이크로소프트는 2024년 기준 91%의 엔지니어링 팀이 GitHub Copilot을 사용
  • 기존에는 AI 도구 사용이 주로 개발자에 국한되었으나, Claude Code와 Claude Cowork의 도입으로 비개발자도 코딩 및 비코딩 작업 수행 가능
  • Claude Code의 도입은 AI가 코드 작성의 자율성을 높이고, 주니어 개발자 역할 감소 우려를 낳는 변화로 평가됨

마이크로소프트의 공식 입장

  • 커뮤니케이션 책임자 Frank Shaw는 “기업은 경쟁 제품을 정기적으로 시험한다”고 언급
    • OpenAI가 여전히 주요 파트너이며, 장기적 협력 관계를 유지 중임
  • 그러나 실제로는 Anthropic 모델과 도구를 내부 및 고객용 제품에 점점 더 통합하고 있음
▲
xguru 2시간전  [-]

두 가지 유형의 AI 사용자가 등장하고 있으며, 그 격차는 놀랍습니다
이 글에서는 Copilot 별로라고 열심히 비판하는데, 정작 Microsoft는 Claude Code로..

답변달기
▲
crawler 3분전  [-]

마소랑 OpenAI랑 친구라 사실상 클코드가 깃허브 코파일럿, openai codex보다 낫다는 건데요 ㅋㅋㅋ
진짜 코딩은 클로드가 맞나 보네요

답변달기
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • Microsoft가 이름 규칙을 정말 제대로 다뤄야 한다고 생각함
    Copilot이 너무 많음 — Bing Chat, Cortana를 대체한 Microsoft Copilot, 코드 자동완성용 Github Copilot, Office에 통합된 Microsoft 365 Copilot, 그리고 모델 백엔드를 선택할 수 있는 Copilot CLI까지 있음
    이제는 노트북에도 Copilot 버튼이 달려 있음
    문제는, 사람들이 “Copilot”이라고 말할 때 도대체 어떤 Copilot을 말하는지 알 수 없다는 점임
    나는 주로 Office용 Copilot을 써봤는데, 2년 전 광고에서 약속한 기능을 전혀 수행하지 못함
    SharePoint나 OneDrive에 있는 문서들을 기반으로 PowerPoint를 만들라고 하면 엉뚱한 결과물만 내놓음
    결국 내가 직접 프레젠테이션을 만드는 게 훨씬 빠름
    Microsoft가 자기 제품을 직접 써보지도 않는 것 같음. 이런 상황에서 누가 Copilot에 돈을 내겠음

    • Microsoft는 이런 이름 혼란을 반복하는 회사임
      예전엔 모든 게 “365”, 그 전엔 “One”, 그 전엔 “Live”, 2000년대 초엔 “.NET”, 90년대엔 “Active”였음
      이름 붙이기 유행이 계속 바뀌는 게 전통처럼 됨
    • Microsoft가 이름을 잘 붙이는 날에는 우주가 갈라질지도 모름
      .Net이냐 dotnet이냐 하는 혼란도 여전함
    • 실제로 Office를 Microsoft 365로 바꾼 게 가장 황당했음
      지금은 “Microsoft 365 Copilot”인지 “Microsoft 365”인지조차 헷갈림
      공식 사이트(링크)에서도 혼용되고 있음
    • Copilot을 매일 쓰는 사람들은 대부분 단순한 작업 자동화에만 활용함
      예를 들어 PowerPoint 전환 효과 추가나 Word 서식 정리 같은 것임
      결국 이런 LLM 제품들이 해결하는 문제는 “복잡한 UI를 대신 다뤄주는 것”뿐임
      근본적인 해결책은 개발자들이 실제 사용자가 프로그램을 어떻게 쓰는지 관찰하는 것임
    • 2000년대 초반의 “.NET” 광풍에 비하면 지금의 Copilot 네이밍은 아무것도 아님
      그땐 인터넷과 전혀 상관없는 제품에도 전부 .NET을 붙였음

  • 모든 회사의 AI 전략은 “생산성 향상에 진짜 필요한 게 뭘까”에서 출발했어야 함
    그런데 Microsoft는 그 대신 사용자 데스크톱을 주기적으로 캡처하는 기능(Recall)에 집중했음. 그게 생산성이라니 웃김

    • 예전에 나도 몇 분마다 자동 스크린샷을 찍는 프로그램을 썼었음
      가끔은 유용했지만, 결국 보안 위험과 사생활 문제 때문에 그만뒀음
    • Anthropic은 모델을 직접 보유하고 있지만 Microsoft는 그렇지 않음
    • Recall은 비판받을 만하지만, Microsoft의 AI 전략 전체에서 보면 큰 비중은 아님
    • 기능 자체는 유용해 보이지만 Microsoft를 신뢰할 수 없다는 게 문제임

  • 요즘 다들 Gemini를 과소평가하는 것 같음
    나는 Gemini 3 Flash로 코딩하는데, Opus 같은 모델과 견줄만하면서 훨씬 빠르고 저렴함
    Antigravity와 조합하면 거의 치트키 수준임

    • 나는 Antigravity를 3주 전에 써봤는데 아직 미완성 느낌이었음
      Claude는 프로젝트의 큰 그림을 잘 잡는데, Gemini 3는 사소한 부분에 집착했음
      그래도 몇 번의 반복 끝에는 정답에 도달하긴 함
      Grok은 중간 난이도 작업에서 금방 막혔음
      혹시 Antigravity를 더 효과적으로 쓰는 팁이 있는지 궁금함
    • Opus 4.5가 장기 에이전트형 코딩에선 더 낫다는 얘기도 들었지만, 나도 Gemini 3 Flash를 주로 씀
      이유는 단순히 내 필요를 충족시키고, Google의 가족 요금제가 훌륭하기 때문임
      5명이 Gemini Pro를 공유할 수 있는데, OpenAI나 Anthropic엔 이런 게 없음
      아내는 공부용으로, 나는 코딩용으로 쓰는데 제한에 걸린 적이 없음
    • Antigravity, Jules, Gemini CLI 모두 훌륭하고 가성비가 좋음
      Google AI 플랜 월 20달러면 충분함
    • 내 경우엔 반대임. Gemini는 허구 정보나 오래된 내용을 자주 만들어냄
    • 회사 구독에 포함된 Gemini CLI도 써봤는데, 자신감 넘치는 오류가 많음
      문제를 찾았다고 확신하지만 틀린 경우가 많아서 검증에 시간이 더 듦
      Claude Code는 이런 과신이 훨씬 적음

  • Github Copilot이 최초의 대중적 AI 코딩 도구였는데, Microsoft는 그 기회를 살리지 못했음

    • 나는 VSCode에서 Copilot을 쓰는데 꽤 쓸만함
      여러 모델 중 선택할 수 있고, IDE 내에서 에이전트형 편집도 가능함
      웹 기반 Copilot Chat은 모델이 뭔지 불분명하고, 이미지 처리는 약함
      Office용 Copilot은 여전히 무용지물임
    • GitHub Codespaces는 무료 컨테이너 개발환경이지만 불안정함
      확장 기능이 자주 깨지고, 웹 인터페이스도 불편해져서 이제는 거의 안 씀
      아이러니하게도 Copilot CLI가 VSCode 확장보다 코드 작성이 훨씬 잘 됨
    • 여전히 자동완성 기능이 가장 유용함. 그거 하나 때문에 구독 유지 중임
    • 데모로는 괜찮았지만, Claude Code가 진짜 게임 체인저였음
    • 결국 Microsoft는 여전히 Microsoft임

  • Microsoft/Github가 몇 년간 Copilot을 밀어붙였지만, Anthropic은 짧은 시간에 Claude Code를 만들어 성공시킴
    Copilot은 왜 실패했을까?
    너무 작은 야망, VSCode/Github에 과도하게 묶인 구조, 그리고 기업 정치 때문이라고 봄

    • Microsoft는 “모든 제품에 Copilot을 넣어라”는 탑다운 명령으로 움직였음
      실제 문제를 해결하기보다 유행어를 좇았음
      반면 Anthropic은 개발자가 스스로 문제를 해결하도록 두었고, 그 결과 진짜 유용한 제품이 나왔음
      경영진이 생산성보다 기술 유행어에 집착한 결과의 차이임
    • 사실 Microsoft도 개발자 한 명만 붙여도 코딩 에이전트를 만들 수 있었음
      그런데 다들 Anthropic이 제시한 “개발자 감축의 꿈”에 매료된 듯함
      CC보다 Gemini, Crush, Codex, Opencode도 충분히 경쟁력 있음
    • 대기업은 구조적으로 사용자가 원하는 제품을 만들기 어려움
      고객이 이미 락인되어 있어서 진짜 혁신이 필요 없기 때문임
      Anthropic은 시장 점유를 위해 진짜 제품을 만들었고, 나중에야 변질될 것임
      Microsoft는 이런 스타트업을 인수하는 전략조차 실패함
    • 단순히 인재 부족 문제일 수도 있음
    • Claude Code는 모델과 구현이 완전히 통합된 풀스택 접근임
      반면 Microsoft와 Github은 ChatGPT의 흔적만 좇고 있음

  • 우리 회사도 Copilot 라이선스가 있지만, 실제로는 Claude Sonnet/Opus 모델을 OpenCode로 접속해 씀

  • Claude를 좋아하는 사람이 많지만, 나는 Kotlin을 주로 써서 IntelliJ 통합이 중요함
    플러그인 평가는 형편없지만 Copilot도 마찬가지임
    Copilot은 그럭저럭 괜찮지만 터미널에서 자주 멈춤

    • 그냥 터미널에서 쓰는 게 정석임. 원래 그 용도로 만들어졌음

  • 나는 아직도 Claude Code의 열풍을 이해 못하겠음
    Copilot이나 Cursor는 잘 쓰지만, 터미널에서 대화하며 개발하는 게 어색함
    다른 사람들은 어떻게 워크플로를 구성하는지 궁금함

    • 내 워크플로는 이럼
      Emacs로 코드 편집, 별도 터미널에서 1~3개의 Claude 세션 운영
      작업을 작은 단계로 나눠 Claude에게 맡기고, git이나 DB 마이그레이션은 직접 처리함
      마치 주니어 개발자 팀을 관리하는 느낌임
    • 비슷한 코드가 많은 프로젝트에서 특히 유용함
      예를 들어 plugin 디렉토리에 “sample” 플러그인을 추가하라고 하면,
      기존 구조를 파악하고 테스트까지 자동으로 작성함
      다만 대규모 코드 수정에는 덜 유용함
    • 나는 iTerm에서 Claude와 대화하고, command+tab으로 VSCode 전환해 수정함
      Superpowers 플러그인을 쓰면 대규모 작업에 도움됨
      코드 리뷰어, 구현자, 테스터가 서로 논쟁하는 걸 보는 게 재밌음
    • Cursor를 먼저 썼지만, Emacs 환경에 익숙해서 CC 터미널을 병행함
      프로젝트별로 CC 세션을 열어두고 필요할 때 불러옴

  • Github Copilot에 Opus 4.5 모델을 연결해 쓰는데 꽤 만족스러움
    Claude Code는 아직 안 써봐서 비교는 어려움

    • 나도 원래 Microsoft 충성심이 있었지만, Claude Code를 써보고 차이를 바로 느꼈음
      Copilot은 일정 횟수 이상 툴 호출이 쌓이면 갑자기 멈추거나,
      단순 파일 읽기조차 매번 허락을 구함
      결국 포기하고 회사의 LLM 인프라를 전부 Claude Code 기반으로 바꿨음
    • 왜 아무도 AugmentCode 얘기를 안 하는지 모르겠음
      Claude 등 여러 모델을 활용하면서 프로젝트 맥락을 잘 이해함
답변달기