Andrej Karpathy가 작년에 명명한 자연어-코드 변환 방식인 바이브 코딩(Vibe coding)은 이제 Inferya의 집계에 따르면 2,500만 개 이상의 앱에 탑재되어 배포되고 있습니다. 이 단 하나의 수치는 "어떤 AI 코딩 도구가 승리하고 있는가"라는 프레임을 폐기해야 함을 시사합니다. 정답은 "모두가 동시에 승리하고 있다, 왜냐하면 기저 기술(substrate)이 승리했기 때문이다"입니다. 더 유용한 질문은 각 도구가 실제로 무엇을 위한 것인가이며, 지난 7월 Exceeds가 발표한 데이터는 그 어떤 모델 벤치마크보다 그 답에 더 가깝게 다가갑니다.

2021년 6월 Copilot의 프리뷰 출시를 도왔던 GitHub의 COO이자 13년 경력의 베테랑인 Kyle Daigle는 Observer에 다음과 같이 말했습니다: "단순히 코드를 생성하는 것에 관한 것이 아닙니다. 소프트웨어를 만드는 것에 관한 것이며, 그러기 위해서는 코드 부분 그 이상을 수행해야 합니다." 이 문장을 시장 상황과 대조해 보십시오. Claude Code가 28%로 주요 도구 점유율 1위를 차지하고 있으며, Cursor가 24%, Copilot이 17%, OpenAI Codex가 11%를 차지하고 있습니다. 그럼에도 불구하고 Copilot은 대기업의 40%가 도입한 도구입니다. GitHub Copilot 대 Claude Code에 관한 모든 논의는 바로 그 격차 속에서 무너집니다.

40% 대 17%의 격차가 비교의 핵심입니다

Copilot이 대기업의 40%에 도입되었지만, 개발자들의 주요 도구로는 17%에 불과하다는 이 12%포인트의 차이는 이 제품들이 실제로 무엇을 하는지에 대한 가장 명확한 해석입니다. Copilot은 Microsoft의 조달 팀이 승인한 기본값(default)입니다. 하지만 개발자들이 가장 먼저 찾는 기본값은 아닙니다.

[[COMPARE: 대기업의 40%에 도입된 GitHub Copilot의 기업 도입 점유율 vs 개발자들 사이에서의 17% 주요 도구 점유율]]

이것은 Copilot에 대한 비판이 아닙니다. 이는 Microsoft 기반의 자산을 사용하는 환경 내 기존 IDE(통합 개발 환경)에 바로 적용되도록 설계된 도구의 자연스러운 형태입니다. 도입 비용이 저렴하고, 유지하기에 마찰이 없으며, 이미 기본 사양(table stakes)이 되어버린 코드 생성의 80% 영역에서 충분히 훌륭합니다. 개발자가 VS Code를 열 때 Copilot은 그곳에 있을 것입니다. 하지만 작업이 어려워질 때 개발자가 선택할 도구는 아닐 것입니다.

반면, Claude Code는 개발자의 의도적인 관심을 끌어냅니다. 훨씬 더 작은 기업 점유율(enterprise footprint) 대비 28%에 달하는 주요 도구 점유율(primary-tool share)은 이 도구가 추천 엔진 — 즉, 입소문, 블로그 포스트, Slack에서의 "이거 꼭 써봐야 해"라는 식의 추천 — 에서 승리했음을 시사합니다. Cursor의 24% 역시 같은 이야기를 하고 있습니다. 코딩 어시스턴트(Coding assistants)는 이제 IT 부서가 밀어붙이는(IT-pushed) 카테고리가 아니라, 개발자가 직접 끌어당기는(developer-pulled) 카테고리가 되었습니다.

GitHub가 2026년에 실제로 판매하고 있는 것

Daigle의 프레임워크 — "단순히 코드 부분 그 이상" — 는 헤드라인 수치들이 숨기고 있는 전략적 움직임을 가리킵니다. GitHub는 모델 군비 경쟁(model arms race)에서 이기려고 노력하는 것이 아닙니다. GitHub는 동일한 IDE 내부에서, 동일한 인증(auth)을 통해, 동일한 리포지토리(repos)를 대상으로 Claude Code, OpenAI Codex, 그리고 더 저렴한 오픈 웨이트(open-weight) 모델들을 사용할 수 있는 장소로 스스로를 포지셔닝하고 있습니다. 플랫폼 자체가 곧 제품인 것입니다.

이것이 개발자에게 제공하는 것은 "이 작업에는 작은 모델이 필요하고, 이 작업에는 큰 모델이 필요하며, 이 작업에는 독점 코드(proprietary code)를 믿고 맡길 수 있는 모델이 필요하다"라는 질문에 대한 단 한 번의 스위치 전환으로 해결 가능한 답변입니다. 이는 Anthropic이 단일 벤더(single-vendor) 업체에 제공하는 답변과 동일합니다. 다만 그들은 이를 다르게 묶어서 제공할 뿐입니다. Anthropic이 하나의 어시스턴트를 배송하며 그것을 표준으로 삼으라고 요구한다면, GitHub는 마켓플레이스(marketplace)를 배송하며 당신이 선택하라고 요구합니다. 이러한 전략 때문에 Copilot의 주요 도구 점유율(primary-tool share)이 계속 줄어들더라도, 기업 점유율(enterprise share)은 아마도 높게 유지될 것입니다.

당신이 실제로 주목해야 할 지표

"주요 도구 점유율(Primary tool share)"은 추천을 얻어내는 도구에 보상합니다. "기업 도입 점유율(Enterprise rollout share)"은 조달(procurement) 과정을 견뎌내는 도구에 보상합니다. 만약 당신이 자신을 위해 선택한다면 전자를 원할 것입니다. 만약 당신이 조직을 위해 선택한다면 후자를 원할 것입니다. 대부분의 비교 분석이 범하는 실수는 이 두 가지를 하나의 차트로 통합하여 "누가 이기고 있는가"를 묻는 것입니다.

더 나은 신호 — 그리고 직접적으로 언급하지 않더라도 데이터 포인트를 초과하는 신호 — 는 _개발자들이 무료 체험이 끝난 후에도 계속 유지하는 도구가 무엇인가_입니다. Copilot의 17%라는 수치는 그 자체로 의구심을 자아냅니다. Copilot은 가장 관대한 무료 티어 (free tier)를 제공하며, Microsoft 생태계 내에서의 전환 비용 (switching cost)이 가장 낮기 때문입니다. 그럼에도 불구하고 그것이 주요 도구가 아니라는 점은 개발자들이 편의성이 아닌 순수한 출력 품질 (output quality)을 기준으로 선택하고 있음을 말해줍니다. 편의성은 GitHub의 강점입니다. 출력물은 다른 모든 이들의 강점입니다.

오늘날의 선택 방법

아래의 결정 매트릭스 (decision matrix)가 모든 것을 포괄하지는 않지만, 제가 친구에게 건네줄 만한 버전입니다.

• 가독성을 중시하는 개인 개발자 또는 소규모 팀: Claude Code 또는 Cursor. 두 도구 모두 추천 엔진 (recommendation engine)의 자격을 갖추고 있습니다. 개발자들이 PR 코멘트나 팟캐스트에서 이들을 언급하기 때문입니다. 28%와 24%의 주요 도구 점유율은 구매(procurement)의 에너지가 아니라, "이것을 가장 먼저 찾았다"는 에너지를 반영합니다. 엔터프라이즈 래퍼 (enterprise wrapper)를 건너뛴다고 해서 잃을 것은 없습니다.

• 실제 구매 기능이 존재하는 Microsoft 환경 내부: Copilot. 통합(integration) 스토리는 실재합니다. PR 리뷰는 GitHub UI 내에서 이루어지고, 저장소 컨텍스트 (repo context)는 에디터 내부에 위치하며, Actions는 나머지 개발 파이프라인 (dev pipeline)과 연결됩니다. 17%의 주요 점유율은 괜찮습니다. 엔지니어들에게는 선택권이 없으며, 별도의 계정이 필요 없는 쉬운 60%의 작업에는 이를 사용할 것입니다. 나머지 어려운 40%는 다른 곳으로 향할 것입니다.

• 멀티 모델 (multi-model), 멀티 테넌트 (multi-tenant), 규제가 적용되는 코드: GitHub의 마켓플레이스 (marketplace) 인터페이스. 에디터를 떠나거나 다시 인증할 필요 없이, 리팩터링 (refactor)은 한 모델로 보내고 보안에 민감한 편집은 다른 모델로 보낼 수 있게 해주는 유일한 주류 어시스턴트입니다. 컴플라이언스 (compliance) 스토리는 설명할 필요도 없이 명확합니다.

• 비용에 민감하거나, 배치 코드 생성 (batch code generation), 또는 에어갭 (air-gapped) 저장소: GitHub이나 Cursor가 노출하는 인터페이스를 통한 오픈 웨이트 (open-weight) 모델. 2025년에 오픈 웨이트 역량 격차는 해소되었습니다. 여기서 실제 순풍(tailwind)은 벤치마크 수치가 아니라 토큰당 경제성 (per-token economics)입니다.

30분 안에 나란히 실행해 보기

차이점을 가장 빠르게 체감하는 방법은 두 모델 모두에 동일한 프롬프트(prompt)를 입력해 보는 것입니다. 두 모델을 하나의 라우터 스크립트(router script)에 넣고 실행하여, 막연한 느낌(vibes) 대신 명확한 증거를 확보하세요:

# .env.local
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...                  # 조직 내에서 Copilot이 노출하는 OpenAI 호환 인터페이스 중 무엇이든 사용
...

// compare.ts — 두 백엔드(backends)를 통해 세 가지 실제 작업을 실행하고 차이점을 직접 확인하세요
import Anthropic from "@anthropic-ai/sdk";
import OpenAI from "openai";
...

여러분의 백로그(backlog)에서 가져온 세 가지 실제 작업을 통해 실행해 보세요. 중요한 격차는 벤치마크(benchmark) 수치가 아닙니다. 모델이 첫 번째 시도에서 여러분의 리포지토리(repo) 컨벤션(conventions)을 잡아내는지 여부입니다.

리더보드(leaderboard)가 바뀌어도 변하지 않는 부분

급격한 변화의 기저에 깔린 지속 가능한 계층은 다음과 같습니다. 이 모든 도구는 컴포넌트(components), 타입(types), 명명 규칙(naming), 파일 구조(file structure)라는 동일한 인터페이스를 통해 여러분의 리포지토리를 읽습니다. 다음 분기에 어떤 모델이 승리하든, 여러분이 배포한 컨벤션 인식(convention-aware) 컴포넌트 계층이 바로 그들이 읽게 될 대상입니다.

OTF는 웹, iOS, Android에서 동일한 컴포넌트입니다. 하나의 API, 하나의 프리미티브(primitives) 세트, 그리고 다음 편집이 Claude Code, Copilot, Cursor, 또는 다음 분기에 라우팅할 오픈 웨이트(open-weight) 모델 중 무엇으로부터 오더라도 올바르게 렌더링되는 동일한 Button입니다. 코드베이스의 이 부분은 모델이 바뀐다고 해서 바뀌지 않습니다. 이는 비교의 전제가 되지만 결코 명시되지 않는 기질(substrate)이며, 리더보드가 재편되는 동안 여러분이 투자해야 할 대상입니다.