코딩 도구 경쟁은 처음에 코드 생성 능력의 경쟁처럼 보였다. 누가 더 정확한 함수를 만들고, 다음 줄을 더 자연스럽게 추천하며, 복잡한 코드를 한 번에 써내는지가 중요해 보였다.
하지만 경쟁의 단위는 이미 옮겨갔다. AI 코딩 도구는 코드를 대신 써주는 단계를 넘어, 개발자가 실제로 일하는 흐름 안으로 들어오고 있다. 이슈를 읽고, 코드베이스를 탐색하고, 수정안을 만들고, 테스트와 리뷰, PR까지 연결한다. 그래서 지금의 질문은 "누가 코드를 더 잘 쓰는가"가 아니라 "누가 개발자가 일하는 흐름을 장악하는가"다.
이 흐름은 사실 두 개의 층으로 나뉜다. 하나는 코드를 만드는 층이다. 개발자가 어떤 도구로 코드를 작성하고 수정하는가의 문제다. 다른 하나는 만들어진 코드를 통제하는 층이다. 그 코드가 검토됐는지, 정책을 통과했는지, 배포해도 되는지, 감사 기록은 남았는지를 조직 전체가 관리하는 문제다. 이 글은 앞의 층, 곧 코드를 만드는 도구들 사이의 경쟁을 본다. 뒤의 층 — 거버넌스와 배포 통제 — 은 별도의 플랫폼이 벌이는 다른 싸움이다. 그 통제 층의 한 사례로 GitLab의 전략을 다룬 글이 메타엑스의 「GitLab, AI 에이전트 시대의 '소프트웨어 생산라인'으로 재편된다」(이든, 2026-06-09)이며, 이 글은 그 아래층을 본다.
여기서, 도구 층으로 좁혀 보면 흥미로운 지점이 있다. 만약 경쟁의 단위가 코드 한 줄이 아니라 개발 워크플로 전체라면, 그 흐름이 가장 많이 모이는 곳을 쥔 쪽이 유리할 것이다. 그리고 그 자리는 오랫동안 GitHub의 것이었다. 저장소, 이슈, PR, 리뷰, Actions가 한곳에 모이는 플랫폼. 워크플로 경쟁이라면 GitHub Copilot이 앞설 것이라는 예측이 자연스러웠다.
그런데 2026년의 데이터는 그 예측과 어긋난다. Copilot은 여전히 가장 많이 쓰이는 도구이지만, 성장은 정체됐고 만족도와 신뢰 지표에서는 후발 도구들에 밀리기 시작했다. 가장 유리한 카드를 쥐고 있던 쪽의 우위가 그대로 굳어지지 않은 것이다.
그렇다면, 긴 시간 동안 GitHub는 왜 유리했을까? 그리고 그 우위는 왜 그대로 이어지지 않았을까? 그리고 결국 무엇이 승부를 가를 것인가.
자동완성에서 워크플로로
초기의 AI 코딩 도구는 자동완성에 가까웠다. 코드를 쓰는 도중 다음 줄을 추천하고, 반복 코드를 완성하고, 간단한 함수를 생성했다. 이때 AI는 개발자의 손 옆에 붙은 보조 도구였고, 경쟁 기준도 단순했다. 더 빠르게, 더 정확하게, 더 많은 언어를 지원하며, 흐름을 끊지 않고 따라오는 것.
그러나 자동완성은 개발 과정의 일부일 뿐이다. 실제 개발은 코드를 입력하는 순간만으로 이루어지지 않는다. 요구사항을 이해하고, 기존 구조를 파악하고, 수정 범위를 정하고, 테스트하고, 리뷰받고, 병합하는 과정 전체를 포함한다. AI가 이 과정 안으로 들어오면서 경쟁의 단위도 자연히 커졌다.
이 변화는 최근 개발자 설문에서도 확인된다. Stack Overflow 2025 개발자 설문은 이 간극을 잘 보여준다. 응답자의 84%가 AI 도구를 사용 중이거나 사용할 계획이라고 답했지만, AI 결과를 신뢰한다고 답한 비율은 29%에 그쳤고, 정확성을 불신한다는 응답은 46%로 신뢰한다는 응답 33%보다 높았다..(Stack Overflow 2025 개발자 설문). 하나의 도구만 쓰는 흐름도 아니다. 기업 현장에서는 복수의 AI 코딩 도구를 함께 쓰는 사례가 늘고 있다. GitLab의 AI Accountability Report에 따르면, 조사 대상 조직의 90% 이상이 두 개 이상의 AI 코딩 도구를 사용 중이고, 54%는 세 개 이상을 사용 중이라고 답했다. 자동완성용 도구 하나, 복잡한 작업을 통째로 맡기는 에이전트형 도구 하나를 나란히 두는 식이다. 경쟁의 단위가 "한 줄"에서 "흐름"으로 넘어갔다는 가장 분명한 증거다.
흐름이 모이는 자리가 유리하다
여기서 Copilot, Cursor, Claude Code, Codex 같은 도구들이 갈라진다. 모두 AI 코딩 도구로 묶이지만, 실제로는 서로 다른 개발의 길목을 겨냥한다.
GitHub Copilot은 GitHub 생태계 안에서 강점을 가진다. 저장소, 이슈, PR, 코드리뷰, Actions 같은 협업 흐름과 직접 연결되기 때문이다. Cursor는 IDE 자체를 AI 중심으로 재구성한다. 편집기 안에서 AI와 대화하고, 코드베이스를 탐색하고, 수정하는 경험을 강조한다. Claude Code는 터미널과 코드베이스 작업에 가깝다. 기존 프로젝트를 읽고, 파일을 수정하고, 명령어를 실행하는 에이전트형 작업에 무게가 있다. Codex는 작업을 맡기고 결과를 검토하는 위임형 인터페이스를 보여준다.
네 도구의 경쟁은 "어느 AI가 코드를 더 잘 쓰는가"가 아니라, 각각 개발자가 일하는 서로 다른 위치를 차지하려는 경쟁이다. 하나는 저장소와 PR의 흐름을, 하나는 IDE를, 하나는 터미널과 코드베이스를, 하나는 작업 위임의 인터페이스를 겨냥한다.
그리고 워크플로 안으로 들어오려면 코드만 알아서는 부족하다. 맥락을 함께 잡아야 한다. 단일 파일만 보는 AI와, 저장소 전체·이슈·PR·리뷰 코멘트·테스트 실패 로그·팀의 규칙까지 보는 AI는 전혀 다르다. 개발자는 빈 화면에서 코드를 쓰지 않는다. 이미 존재하는 구조 안에서 일한다. 어떤 함수는 다른 모듈과 얽혀 있고, 어떤 수정은 테스트를 깨뜨리며, 어떤 코드는 팀의 규칙과 충돌한다.
이 가설에서 GitHub은 유리한 위치에 있었다. GitHub은 코드를 저장하는 곳이 아니라 이슈, PR, 리뷰, Actions, 배포 흐름이 모이는 공간이기 때문이다. 흐름과 맥락이 한곳에 쌓이는 자리를 이미 쥐고 있었다. 그 우위는 지금도 일부 실재한다. GitHub의 구조적 유통력은 여전히 크다. GitHub 공식 Newsroom 기준으로 GitHub는 1억8천만 명 이상의 개발자, Fortune 100의 90% 이상, 400만 개 이상의 조직이 사용하는 플랫폼이며, Copilot 역시 470만 유료 가입자와 7만7천 개 이상의 도입 조직을 확보하고 있다(GitHub 공식 블로그).
흐름은 한 플랫폼에 모이지 않았다
2026년의 데이터는 가설과 다른 방향을 가리킨다. Copilot은 여전히 가장 널리 알려지고 업무에서 가장 많이 쓰이는 AI 코딩 도구다. 다만 JetBrains AI Pulse 2026 조사에서는 Copilot의 인지도와 업무 채택 성장이 전년 대비 정체됐다는 진단도 함께 나온다. 반면 Claude Code는 빠르게 성장했고, 만족도와 추천 의향 지표에서 강한 신호를 보였다. "기본 Microsoft 옵션"이라는 지위가 초기 우위를 만들었지만, 이제는 그게 천장이 됐다는 것이다. 한편 업계 전반에서는 AI 도구를 점점 더 많이 쓰면서도 그 정확성에 대한 신뢰는 오히려 떨어지는 흐름이 확인된다. Stack Overflow 2025 개발자 설문은 이 간극을 잘 보여준다. 응답자의 84%가 AI 도구를 사용 중이거나 사용할 계획이라고 답했지만, AI 결과를 신뢰한다고 답한 비율은 29%에 그쳤고, 정확성을 불신한다는 응답은 46%로 신뢰한다는 응답 33%보다 높았다. 도구가 많이 쓰인다는 것과 그 도구가 신뢰를 굳혔다는 것은 다른 이야기다.
흐름이 한 플랫폼에 모이지 않았다는 신호는 세 가지로 정리된다.
첫째, 플랫폼 종속이 양날이 됐다. GitHub 안에 있다는 강점은 GitHub 밖으로 나가지 않으려는 이유가 되기도 한다. 하지만 개발자들은 만족도와 작업 적합성을 따라 움직였고, 에이전트형 작업에서는 터미널·IDE 중심 도구를 선택하는 경우가 늘었다.
둘째, GitHub 스스로 경계를 열었다. 2026년 2월 4일, GitHub은 Agent HQ에서 Anthropic의 Claude와 OpenAI Codex를 public preview로 제공하기 시작했다. 이는 GitHub이 Copilot만으로 개발 흐름을 닫아두기보다, 여러 공급자의 에이전트를 GitHub와 VS Code 안에서 함께 실행하는 방향을 택했다는 신호다. 에디터·플랫폼 중심 모델만이 AI 개발의 유일한 아키텍처가 아니라는 것을, Microsoft 자신의 플랫폼이 받아들인 셈이다. "흐름을 한 플랫폼이 독점한다"는 전제에 가장 큰 의문을 던진 건 경쟁자가 아니라 GitHub 자신이었다.
셋째, 개발자는 한 도구가 아니라 스택을 쓴다. 앞서 본 대로 경험 많은 개발자들은 평균 두 개 이상의 도구를 병행한다. 그렇다면 "흐름 전체를 한 곳이 장악한다"는 그림 자체가 성립하기 어렵다. 흐름은 쪼개져서 각 구간마다 가장 잘 맞는 도구에 분배되고 있다.
단, 점유율이 내려갔다는 것이 우위가 사라졌다는 뜻은 아니다. Copilot을 위기의 제품으로 단정하는 건 성급하다. 막대한 설치 기반과 유통력은 그대로다. 변화의 핵심은 규모가 아니라 궤적이다. 가장 유리한 자리를 쥔 쪽이 그 자리만으로는 더 이상 격차를 벌리지 못한다는 것, 그것이 2026년이 보여준 그림이다.
무엇이 승부를 가를까
흐름이 한 플랫폼에 모이지 않는다면, 승부는 다른 데서 갈린다. 여기 세 가지 변수는 아직 결판나지 않았다. 어느 도구도 이 셋을 모두 장악하지 못했다.
첫째, 과금 구조다. AI가 워크플로에 깊이 들어올수록 비용은 단순 기능이 아니라 인프라에 가까워진다. 더 많은 파일을 읽고, 더 긴 맥락을 처리하고, 여러 작업을 병렬로 돌린다. 토큰 사용량, 모델 선택, 실행 시간, 자동화 비용이 함께 따라온다. 이 변화는 이미 현실이 됐다. GitHub는 2026년 6월 1일부터 Copilot 사용을 GitHub AI Credits 기반의 사용량 과금으로 전환했다. 사용량은 입력·출력·캐시 토큰 소비를 기준으로 계산되며, GitHub은 Copilot이 장시간·다단계 에이전트 세션을 수행하는 플랫폼으로 진화하면서 기존 과금 모델이 지속 가능하지 않다고 설명했다(GitHub 공식 블로그 · 시행 안내). 결국, 일부 사용자는 작업량에 따라 예측하기 어려운 비용을 마주하게 됐다. GitHub는 그 이유로 Copilot이 길고 여러 단계에 걸친 에이전트형 세션을 수행하는 플랫폼으로 진화해 컴퓨팅·추론 비용이 크게 늘었고, 기존 정액 모델이 더는 지속 가능하지 않다는 점을 들었다. 자율 에이전트의 추론 비용을 정액제로 감당하기 어렵다는 판단이 업계 전반으로 번지는 신호다. 기업 입장에서는 "AI가 코드를 잘 쓰는가"만큼 "비용을 예측하고 통제할 수 있는가"가 중요해진다. 누가 이 비용을 투명하고 예측 가능하게 만들어주느냐는 아직 누구도 분명히 답하지 못한 질문이다.
두 번째는 모델 선택권이다. 워크플로 안에서 하나의 모델로 모든 작업을 처리하긴 어렵다. 어떤 작업은 강력한 모델이, 어떤 작업은 빠르고 저렴한 모델이면 충분하다. 보안·데이터 정책 때문에 자체 계약 모델이나 로컬 모델을 원하는 기업도 있다. 그래서 여러 모델을 흐름 안에 자연스럽게 붙이고 조합하게 해주는 쪽이 단순 코딩 보조를 넘어 개발 AI 허브에 가까워진다. 이 변수는 빠르게 평준화되고 있다. 한때 단일 공급사 모델에 묶여 있던 Copilot조차 이제 여러 공급사의 모델을 함께 지원한다. 모델 성능 자체보다 "모델을 언제 어디에 배치하게 해주는가"가 경쟁의 축이 됐고, 이 축에서 결정적 우위를 가진 쪽은 아직 없다.
셋째는 검수와 책임이다. AI가 코드를 많이 만들수록 개발자의 일은 사라지지 않고 이동한다. 입력하는 시간은 줄지만, 그 코드가 맞는지 판단하는 일은 더 중요해진다. 유지보수 가능한지, 아키텍처와 맞는지, 보안상 안전한지, 운영에 들어가도 되는지는 여전히 사람이 판단해야 한다. 앞서 본 신뢰의 간극이 여기서 다시 문제가 된다. 개발자들은 AI 도구를 그 어느 때보다 많이 쓰면서도, AI 출력의 정확성을 신뢰한다는 응답은 1년 사이 눈에 띄게 줄었다. 같은 설문에서 정확성을 적극적으로 불신한다는 응답이 신뢰한다는 응답보다 많았다. 다음 국면을 가져가는 건 자동완성을 더 빨리 내놓는 쪽이 아니라, 이 신뢰의 간극을 메우는 쪽일 수 있다.
다만 짚어둘 것이 있다. 개발자가 자기 손끝에서 결과물을 검수하는 것은 도구 층의 문제다. 그 위에서 조직 전체가 정책을 주입하고, 어떤 에이전트가 무엇을 했는지 감사하고, 배포를 통제하는 것은 한 층 위의 문제다. 후자는 이미 별도의 전장이 되고 있고, 그 자리를 노리는 건 코딩 도구가 아니라 개발 플랫폼들이다. 메타엑스의 「GitLab, AI 에이전트 시대의 '소프트웨어 생산라인'으로 재편된다」(이든)가 다룬 GitLab의 거버넌스 전략이 바로 이 통제 층의 사례다. 이 글이 다루는 도구 층의 승부와, 그 위 통제 층의 승부는 서로 다른 무대에서 동시에 진행되고 있다.
승부는 코드가 아니라 '흐름'이다
AI 코딩 도구 경쟁의 단위는 분명히 바뀌었다. 초기의 경쟁이 코드 자동완성과 생성 능력이었다면, 지금의 경쟁은 개발자가 일하는 흐름 전체를 둘러싼 경쟁으로 이동했다. 여기까지는 데이터가 일관되게 가리킨다.
확정되지 않은 건, 그 흐름을 누가 장악할지다. 워크플로 경쟁이라면 흐름이 모이는 자리를 쥔 GitHub이 앞설 것이라는 가설은 자연스러웠지만, 2026년의 시장은 그 가설을 단순하게 확인해주지 않았다. 플랫폼을 쥔 쪽의 우위는 천장에 부딪혔고, GitHub은 자기 플랫폼에 경쟁자를 들였으며, 개발자들은 한 도구 대신 스택을 골랐다. 그렇다고 후발주자가 승부를 끝냈다는 뜻도 아니다. 유통력과 설치 기반이라는 구조적 우위는 그대로 남아 있다.
결국 도구 층의 승부는 코드 한 줄이 아니라, 개발의 시작부터 병합과 배포까지 이어지는 흐름 위에서 갈릴 것이다. 그리고 그 흐름 위의 승부를 가를 변수들 — 비용을 예측 가능하게 만드는 과금, 여러 모델을 자연스럽게 붙이는 유연성, 신뢰의 간극을 메우는 검수 지원 — 은 아직 어느 쪽도 손에 넣지 못했다.
한 발 물러서서 보면 그림은 더 커진다. 코드를 만드는 도구의 승부가 아직 나지 않았듯, 그 위에서 만들어진 코드를 통제하는 플랫폼의 승부도 진행 중이다. AI 시대 개발의 주도권은 이 두 층 — 생성과 통제 — 위에서 동시에 갈리고 있다.
누가 코드를 더 많이 쓰느냐의 시대는 끝났다.
진짜 질문은 이제부터다.
누가 그 흐름을, 그리고 그 위의 흐름을 쥘 것인가.
