안녕하세요, 닥스훈트입니다.

최근 몇 달간 X(구 Twitter)에서는 「Claude Code로 ○○○를 할 수 있어서 정말 대단하다!」, 「Claude Code를 사용한 ○○○가 해외에서 대유행! 이걸 안 하는 사람은 진짜 손해다!」, 「Claude Code 개발자가 24시간 풀가동되는 AI 조직 만드는 법을 공개했는데 내용이 너무 대단했다」와 같은 게시물을 매일같이 엄청나게 많이 보게 되었습니다. 하지만 그중에는 정보 상품(Information Product)으로 유도하려는 의도가 보이거나, 과대광고적인 내용도 적지 않습니다. 솔직히 이런 진위가 의심스러운 정보가 계속 흘러넘치면, 편리해야 할 기술 토픽조차 따라가는 것만으로도 지치게 됩니다.

반면, Mercari, LayerX 등 실제로 프로덕트 개발 현장에서 AI 활용을 추진하고 있는 엔지니어들의 발신을 보면, 「Claude Code는 기존의 코딩 지원보다 한 단계 더 사용하기 편하다」, 「제안이나 구현 성능이 높다」와 같은 평가가 나오고 있습니다. 이쪽은 일상적인 실무와 검증에 기반한 이야기이므로, 단순한 유행과는 분리해서 받아들일 필요가 있다고 느꼈습니다.

저는 GitHub Copilot과 Claude Code를 둘 다 어느 정도 사용해 왔습니다. 기능적인 면만 보면 VSCode 확장 기능에 의한 채팅 인터페이스, Plan 모드, Agent 모드, Skill, MCP 등 할 수 있는 일은 대체로 비슷해 보입니다. 차이가 있다면 모델 부분인데, Claude Code는 Claude 모델을, Copilot은 Auto 모드 시의 모델 선택(GPT 모델이나 Codex 모델이 선택되기 쉬움)에 따른 차이가 있습니다.

다만, 체감상 나타나는 제안 품질이나 구현·수정 정밀도의 차이는 모델 차이만으로는 설명하기 어려운 장면이 있습니다. 그렇기에 「차이는 모델뿐인가, 아니면 내부 설계나 실행 플로우에도 차이가 있는가」가 궁금해졌습니다.

이번 기사는 「Copilot 사용자는 지금 당장 이주해야 한다」고 부추기기 위한 것이 아닙니다. 오히려 반대로, Copilot을 사용하고 계신 분들도 안심하고 읽으실 수 있도록 공개 문서와 벤치마크(Benchmark)를 바탕으로 Claude Code와 Copilot이 무엇이 어떻게 다르고, 왜 체감 차이가 발생하는지를 냉정하게 조사해 나가겠습니다. 비교 축은 개발에서의 제안 내용과 구현·수정 내용의 품질 차이로 한정하며, 보안 설정 및 유지보수성 등은 대상으로 하지 않습니다.

또한, 「Claude Code」뿐만 아니라 다음에는 「Codex」가 정보 상품의 타겟이 되기 시작하고 있다는 인상도 있습니다. 여력이 된다면 다음 기회에 「Codex」나 「Cursor」에 대해서도 동일하게 조사해 보고 싶습니다.

TL;DR

• SNS에 넘쳐나는 「Claude Code가 너무 대단하다」는 게시물의 대부분은 정보 상품으로의 유도 경로이다. 반면, 실무 엔지니어들로부터는 구체적인 평가가 나오고 있으며, 양자는 분리해서 읽을 필요가 있다.
• Claude Code와 Copilot은 「기능은 거의 같고 차이는 모델뿐」으로 보이지만, 컨텍스트(Context)를 가져오는 방식과 에이전트(Agent)의 움직임 방식에 설계상의 차이가 있다. - Claude Code는 그때마다 파일을 동적으로 탐색하는 설계이다. Copilot은 처음에 모든 파일의 벡터 인덱스(Vector Index)를 생성해 두는 설계이다. 이 차이가 코드베이스 전체를 가로지르는 구현·수정의 정밀도 차이로 이어지기 쉽다.
• 벤치마크(SWE-bench 등)에서도 Claude 계열 모델은 코드 수정 태스크에서 높은 점수를 보여주고 있으며, 체감 차이에는 수치적인 뒷받침이 있다.
• 「지금 당장 Copilot에서 이주해야 한다」는 이야기가 아니다. 인라인 보완(Inline Completion)이 필요한 장면이나 IDE 통합의 사용 편의성은 Copilot이 우위에 있다. 또한 Agent 모드에 대한 대응도 착실히 진행되고 있기 때문에, 점진적으로 성능이 올라갈 가능성이 충분히 있다.

목차

• 「Claude Code가 너무 대단하다」는 말에 지친 이야기
• 신뢰할 수 있는 목소리: 실무 엔지니어의 평가
• 「기능은 같고 모델만 다르다」는 사실일까?
• Claude Code의 내부 설계
• GitHub Copilot의 내부 설계
• 내부 설계의 차이가 만드는 성능 차이
• 벤치마크로 보는 수치
• 요약: 어떻게 구분해서 사용할 것인가

1. 「Claude Code가 너무 대단하다」는 말에 지친 이야기

SNS상에서 「Claude Code」의 이름을 보는 빈도가 급증하고 있습니다. 다만 자세히 보면 발신처의 대부분은 무언가를 팔려고 하는 계정이거나, 인게이지먼트(Engagement)를 얻는 것을 목적으로 한 「선동형」 게시물인 경우가 많습니다.

실태에 대해서는 Note의 기사 「(전편) 정보 상품 판매자에게 안성맞춤인 Claude Code · (후편) 정보 상품 판매자에게 안성맞춤인 Claude Code」가 자세히 정리하고 있습니다. 몇 가지 소개하자면:

• 「최강 프롬프트 집 25선」으로 배포되고 있는 PDF의 내용은 「역할을 지정하세요. 답변에는 일본어를 사용하도록 지정하세요.」 등과 같이 흔한 내용이었으며, 생성형 AI (Generative AI)를 사용하면 몇 초 만에 생성할 수 있는 수준이었다
• 「무료 세미나」의 내용은 Claude Code 설치 단계에서 끝나며, 프로그래밍 경험이 없는 참가자는 CLI (Command Line Interface)에서 채팅을 입력하는 것만으로 「엄청난 것을 할 수 있게 되었다」는 착각에 빠지게 된다
• 「이쪽 무료 세미나로」「최강 프롬프트 집은 여기서 다운로드」와 같이 유도하여, 유료 세미나로의 유입으로 연결한다

왜 Claude Code가 표적이 되기 쉬운가 하면, 비엔지니어의 관점에서는 설치 후 CLI에서 명령어를 입력하는 것만으로도 「무언가 대단한 것을 해냈다」는 경험을 주기 쉽기 때문입니다. 커맨드 라인(Command Line)이라는 생소한 화면과 유창하게 대답하는 AI의 조합은 확실히 처음 접했을 때 압도적인 느낌을 줍니다.

또한, 「Claude Code 최강 활용 사례」라고 소개되지만, 막상 확인해 보면 채팅형 Gemini나 ChatGPT에서도 똑같이 할 수 있는 내용인 경우도 있습니다. 예를 들어 「최강 자료 작성술」이라고 내세운 기사의 실체를 확인해 보니, Claude Code로 채팅하여 얻은 답변을 슬라이드에 복사하여 붙여넣는 **거의 수동에 가까운 작업 흐름 (Workflow)**이었습니다. Claude Code 고유의 기능(에이전트 루프 (Agent Loop) · 파일 편집 · 멀티 스텝 실행)은 전혀 사용되지 않았으며, 채팅 상대가 Claude Code인지 여부는 본질적으로 관계가 없습니다. 「Claude Code로 할 수 있는 것」이 아니라 「LLM 채팅으로 할 수 있는 것」을 Claude Code라는 이름으로 포장하여 발신하고 있을 뿐인 패턴입니다.

그리고 지금, 다음 타겟이 되기 시작한 것이 바로 **「Codex」**입니다. 「아직도 Claude Code를 써? Codex를 안 쓰다니 너무 심각해!」라는 취지의 게시물도 X(구 트위터)에서 보이기 시작하며, 동일한 구도가 반복되고 있습니다.

2. 신뢰할 수 있는 목소리: 실무 엔지니어의 평가

한편, 일상적인 실무에서 AI 도구를 사용하며 검증을 계속하고 있는 엔지니어들로부터도 Claude Code에 관한 발신이 늘고 있습니다. 이쪽은 실제 도입 경위나 설정 내용, 활용 방안이 구체적이며 신뢰할 수 있는 내용입니다.

Claude Code Meetup Japan (connpass)은 2025년부터 지속적으로 개최되고 있으며, 2026년 5월 시점에서 도쿄 개최를 포함한 여러 차례의 스터디 모임이 YouTube 아카이브와 함께 공개되어 있습니다. 참가자들의 발표 내용은 도입 절차 · 보안 설정 · 실제 유스케이스 (Use Case) 등 실무에 가까운 것들이 중심입니다.

LayerX는 Claude 4 출시 이후 Claude MAX 플랜을 채택했습니다. 엔지니어 블로그에 따르면 도입 후 하루당 이용 소비가 $200 상당에 달했다고 보고되어 있어, 적극적인 활용을 엿볼 수 있습니다 (LayerX 엔지니어 블로그, 2025년 6월). 또한, 「Bakuraku의 모노레포(Monorepo)에서의 AI Coding을 위한 환경 정비와 {Roo, Claude} Code 활용 사례」라는 슬라이드에서는 모노레포 구성에서의 Claude Code 활용에 관한 구체적인 설정이 공개되어 있습니다.

Mercari는 Claude Code Meetup Japan #4에서 보안 담당 엔지니어가 발표하였으며, MDM을 통한 설정 일괄 배포나 엔지니어/비엔지니어 간의 권한 레벨 분리 등 조직적인 운영 방법을 발표했습니다 (Speaker Deck).

이러한 실무 엔지니어들의 발신에서 공통적으로 나타나는 점은, 「Claude Code를 무조건 찬양하는 것」이 아니라 「어떤 설정으로 · 어떤 태스크 (Task)에 사용하면 효과적인가」라는 구체적인 구분 관점입니다. 그렇기에 SNS의 「너무 심각해」 계열의 게시물과는 내용의 질이 명확히 다릅니다.

따라서 지금부터는 표면적인 기능 비교가 아니라, 제안 품질이나 구현 · 수정의 용이성에 영향을 미치는 내부 설계의 차이에 집중하여 Claude Code와 Copilot을 정리해 나가겠습니다.

3. 「기능은 같고 모델만 다른 것」은 사실인가?

Claude Code와 GitHub Copilot을 비교했을 때, 할 수 있는 일의 표면만 보면 상당히 비슷합니다. 아래 표에 정리합니다.

언뜻 보면 "인라인 보완이 있고 없음의 차이 외에는 거의 같다"라고 보일 수 있습니다. 하지만 이 표에 나타나지 않는 부분——컨텍스트(Context)를 어떻게 수집하는가, 에이전트(Agent)가 어떻게 움직이는가——에 실제 체감 차이를 만드는 설계의 차이가 존재합니다.

모델의 차이(Claude 모델인지 GPT/Codex 모델인지)도 당연히 영향을 미치지만, 같은 모델을 사용하더라도 내부 설계의 차이는 남습니다. 다음 두 장에서는 Claude Code와 Copilot 각각의 내부 설계를 살펴보겠습니다.

4. Claude Code의 내부 설계

4-1. 에이전트 루프 (ReAct 패턴에 가까운 구조)

Claude Code의 핵심은 "에이전트 루프 (Agent Loop)"라고 불리는 실행 사이클입니다. 공식 문서(How the agent loop works)에 따르면, 이 루프는 다음과 같은 사이클을 반복하는 비동기 제네레이터(Asynchronous Generator)로 구현되어 있습니다.

도구 호출 → 실행 → 결과 피드백 → 다음 도구 호출 또는 최종 응답

루프는 "도구 호출이 없는 응답이 나올 때까지 지속된다"라는 설계로, 태스크가 끝날 때까지 AI가 자율적으로 다음 행동을 계속 결정합니다. arXiv 논문 「Dive into Claude Code (2604.14228)」에서는 이 구조를 ReAct 패턴에 가깝다고 분석하고 있습니다 (Anthropic 공식이 "ReAct형"이라고 명시한 것은 아니므로, 본 기사에서도 "가까운 구조"로 소개합니다).

도구의 실행 방식에도 정교함이 있습니다.

• 읽기 전용 도구 (Glob, Grep, Read 등)는 병렬 실행 (Parallel Execution) 가능
• 상태 변경 도구 (Edit, Write, Bash 등)는 **순차 실행 (Sequential Execution)**으로 안전성 담보

이러한 병렬/순차의 구분 사용을 통해, 파일 읽기를 가속화하면서도 잘못된 쓰기가 누적될 리스크를 억제하고 있습니다.

4-2. 컨텍스트 수집 메커니즘

Claude Code는 세션 시작 시 리포지토리 전체를 스캔하지 않습니다. 대신, AI가 스스로 필요한 도구를 호출하면서 동적으로 컨텍스트를 쌓아 올리는 설계로 되어 있습니다.

예를 들어 "이 파일의 버그를 고쳐줘"라고 요청하면, Claude Code는 먼저 Glob으로 파일 구조를 파악하고, 다음으로 Read로 대상 파일을 읽어 들인 뒤, 필요에 따라 Grep으로 관련 코드를 검색하는 단계를 자율적으로 밟습니다. 사람이 조사할 때의 흐름과 유사한 이미지입니다.

이 설계의 장점은 대규모 리포지토리에서도 필요한 정보만을 컨텍스트에 담을 수 있다는 점입니다. 모든 파일을 처음에 읽으려고 하면 컨텍스트 윈도우 (Context Window)가 금방 가득 차 버립니다. 동적 취득형 설계는 그 리스크를 낮추고, 긴 에이전트 루프를 지속할 수 있는 여지를 넓혀줍니다.

컨텍스트에 포함되는 정보를 크게 분류하면 다음과 같습니다.

4-3. CLAUDE.md · 스킬 · MCP의 역할

CLAUDE.md는 세션 시작 시 로드되며, 매 턴의 요청에 자동으로 재주입됩니다. 컨텍스트 압축 (Context Compression)이 실행되어도 사라지지 않는 유일한 영구적 지시서로, 프로젝트 고유의 규칙이나 작업의 전제 조건을 적어두기에 적합합니다.

스킬 (Skill) (슬래시 명령어로 호출할 수 있는 커스텀 프롬프트)은 설명문만을 세션 시작 시 로드하며, 스킬의 전문은 호출되었을 때만 컨텍스트에 들어갑니다. 자주 사용하는 워크플로우를 스킬로 분리해 두면 매번 프롬프트를 작성할 필요가 없을 뿐만 아니라 컨텍스트 절약에도 도움이 됩니다.

MCP (Model Context Protocol)는 외부 도구 및 데이터 소스를 연결하는 메커니즘으로, 기본적으로 모든 도구 정의가 요청마다 컨텍스트에 포함됩니다. ToolSearch 기능을 사용하면 온디맨드 로드 (On-demand load)도 가능합니다.

4-4. 「AI는 1.6%, 인프라가 98.4%」라는 설계 사상

앞서 소개한 arXiv 논문(2604.14228)에는 흥미로운 수치가 실려 있습니다. Claude Code의 AI 의사결정 로직은 코드베이스 전체의 단 **1.6%**에 불과하며, 나머지 **98.4%**는 권한 게이트 (Permission gate), 컨텍스트 관리, 도구 라우팅 (Tool routing), 에러 복구 (Error recovery)와 같은 결정론적인 인프라(흔히 말하는 하네스 엔지니어링 (Harness engineering))로 구성되어 있다는 것입니다.

「AI가 모든 것을 결정한다」가 아니라, 「AI의 판단을 인프라 측에서 받아들여 안전하게 실행한다」는 구조로 되어 있습니다. 이러한 설계 덕분에 AI가 판단을 그르쳤을 때(잘못된 파일을 편집하려고 하거나, 위험한 명령어를 실행하려고 할 때) 인프라 측에서 제동을 걸 수 있습니다.

여담: 2026년 3월의 Claude Code 소스 코드 유출 사건
2026년 3월 31일, npm 패키지 v2.1.88에서 .npmignore 기재 누락이라는 단 한 줄의 휴먼 에러로 인해 512,000행 이상의 소스 코드가 잘못 공개되었습니다 (VentureBeat / Gizmodo Japan). 시스템 프롬프트(System prompt)나 미공개 플래그, Undercover Mode와 같은 "비법 소스"가 전 세계에 공개되는 사태가 발생했으며, Anthropic이 DMCA 테이크다운(Take-down)을 요청하는 사이에도 같은 날 Python을 이용한 클린룸 재구현 버전이 공개되어 버렸습니다 (Qiita). 본 장의 「AI 1.6% / 인프라 98.4%」라는 수치도 유출된 코드를 분석한 arXiv 논문이 근거 중 하나가 되었습니다. 이러한 인시던트 사고를 교훈 삼아, 정교하게 다듬은 CLAUDE.md나 스킬 파일을 공개 리포지토리(Repository)나 공개 패키지에 실수로 포함하지 않도록 주의해야 한다고 생각합니다.

4-5. 컨텍스트 압축 (Compaction)

Claude Code는 컨텍스트 윈도우 (Context window) 사용률이 약 **92%**에 도달하면 자동으로 압축 (Compaction)을 실행합니다. 오래된 대화 이력을 요약본으로 교체함으로써 윈도우 공간을 확보하고, 긴 세션을 지속할 수 있도록 합니다.

이때 CLAUDE.md의 내용은 압축 후에도 다시 주입되므로, 「내용이 길어지면 지시 사항을 잊어버리는」 문제가 잘 발생하지 않는 구조로 되어 있습니다.

5. GitHub Copilot의 내부 설계

GitHub Copilot은 2021년 출시 이후, 「타이핑하는 동안 보완 후보(입력 중에 회색으로 표시되는 텍스트)가 나타나는」 인라인 보완 (Inline completion)을 주력으로 설계 및 최적화해 온 도구입니다. 후술할 FIM이나 Neighboring Tabs와 같은 기술 투자는 이 기능을 연마하기 위해 쌓아온 것입니다.

한편, 2025~2026년에 걸쳐 에이전트 모드 (Agent Mode)에 대한 투자도 급증하고 있으며, 기존의 인라인 보완 중심의 사용법에서 채팅으로 여러 파일을 다루는 에이전트적인 사용법으로 확장되고 있습니다.

이 장에서는 공식 정보와 VS Code 확장 프로그램의 소스를 리버스 엔지니어링 (Reverse engineering)한 제3자 조사(후술) 모두를 다룹니다. 후자는 현재의 구현과 다를 가능성이 있으므로, 기사 내에서 각각의 출처를 명시하겠습니다.

5-1. Prompt Library와 프롬프트 생성 파이프라인

GitHub Copilot의 컨텍스트 수집 메커니즘에는 Prompt Library가 사용됩니다.

공식 블로그 (How GitHub Copilot is getting better at understanding your code)에 따르면, 이 라이브러리는 사내 머신러닝 (ML) 전문가들이 설계한 알고리즘을 사용하여 다양한 정보원으로부터 정보를 추출하고 우선순위를 지정하며 프롬프트를 구성하는 것으로 보입니다.

Most of this work takes place in what's called a prompt library, which is where our in-house ML experts work with algorithms to extract and prioritize a variety of sources of information.

공식 블로그에서 확인할 수 있는 범위 내에서 정보원이 되는 컨텍스트 (Context) 요소는 커서 전후의 코드 (Prefix/Suffix), 현재 파일, 그리고 열려 있는 모든 탭입니다.

여기서부터는 리버스 엔지니어링 (Reverse Engineering)을 통한 조사 보고 내용입니다. 개발자 Parth Thakkar 씨가 VS Code 확장 기능의 코드를 분석한 조사 기사 (copilot-explorer)에서는 더욱 상세한 동작 방식이 밝혀져 있습니다. 확장 기능의 특정 버전 시점의 분석이며 현재도 동일한 구현인지는 확인되지 않았으나, 설계 사상으로서 참고할 가치가 있기에 소개합니다.

조사에 따르면, 프롬프트 (Prompt) 생성은 extractPrompt(ctx, doc, insertPos)라는 함수에서 시작되며, 가장 최근에 액세스한 동일 언어의 20개 파일을 후보로 가져옵니다. 그 후, 컨텍스트 요소를 '위시리스트 (Wishlist)'로서 우선순위를 부여하여 쌓아 올리고, 토큰 예산 (Token Budget)에 도달할 때까지 탐욕 알고리즘 (Greedy Algorithm) 방식으로 채택하는 설계로 되어 있습니다.

또한, 컨텍스트를 구성한 후 클라우드로 전송하기 전에 **컨텍스트 필터 (Context Filter)**가 작동합니다. 언어, 직전의 제안 수락/거절 상황, 프롬프트 끝부분의 문자 종류 등 11가지 특성을 입력값으로 하는 **로지스틱 회귀 모델 (Logistic Regression Model)**을 통해 품질 점수를 산출하며, 점수가 임계값 15% 미만인 경우에는 API 호출을 수행하지 않고 취소합니다. 키를 입력할 때마다 클라우드 요청이 발생하는 것이 아니라, "유용한 제안으로 이어질 것 같은 경우에만 보낸다"는 설계입니다.

여담: "40%"라는 수치의 정체. GitHub Copilot이 공표하는 "개발자가 작성하는 코드의 40%는 AI가 작성하고 있다"라는 수치가 있는데, 사실 이 수치는 계산 방법에 상당한 공을 들인 것으로 보입니다. copilot-explorer의 조사에 따르면, 제안을 수락한 후

15초에서 10분 사이의 여러 시간대에서 관찰을 지속하며, "수락한 코드에 거의 변경 없이 그대로 사용되고 있는가 (편집 거리 (Edit Distance)가 단어 수준에서 50% 미만의 변경에 그치고 있는가)"로 판정한다고 합니다. "수락 직후에만 측정하는 것"이 아니라, 일정 시간이 지난 후에도 남아 있어야 비로소 카운트되는 메커니즘입니다. 참고로 코드 스니펫은 수락 30초 후에 스냅샷 (Snapshot)으로 수집되어 텔레메트리 (Telemetry) 데이터에 포함되지만, "제품 개선 목적의 이용"을 옵트아웃 (Opt-out)하면 외부로의 전송을 중단할 수 있음을 해당 조사자가 검증했습니다.

5-2. Neighboring Tabs와 Jaccard 유사도

열려 있는 모든 탭을 컨텍스트에 포함시키는 메커니즘이 Neighboring Tabs입니다. 공식 블로그에서는 이 도입을 통해 제안 수락률이 상대적으로 +5% 향상되었다고 보고되었습니다.

여기서부터는 리버스 엔지니어링 조사 내용입니다. copilot-explorer의 분석에 따르면, 내부에서는 FixedWindowJaccardMatcher라고 불리는 메커니즘이 작동하고 있습니다. 이 메커니즘을 통해 각 파일마다 유사도가 높은 부분(특정 윈도우 폭)만을 프롬프트에 포함시킵니다.

• 각 파일을 **60행의 고정 윈도우 (Fixed Window)**로 슬라이스 (Slice)
• 각 윈도우와 편집 중인 파일 간의 Jaccard 유사도 (Jaccard Similarity) (토큰 중복도)를 계산
• 파일별로 최고 점수의 윈도우 1개만 프롬프트에 채택

채택된 스니펫은 다음과 같은 포맷으로 프롬프트의 맨 앞에 추가됩니다.

# Compare this snippet from [다른 파일 경로]:
# [스니펫 내용...]

"지금 작성 중인 코드와 유사한 구조를 가진 다른 파일"의 내용이 제안에 반영되기 쉬운 이유는 바로 이 메커니즘 덕분입니다. Jaccard 유사도라는 고속 토큰 중복 알고리즘을 사용하기 때문에, 타이핑 속도에 가까운 타이밍에 평가하더라도 처리 부하를 억제할 수 있습니다.

5-3. Fill-in-the-Middle (FIM)

일반적인 코드 완성은 커서 이전의 코드(Prefix)를 보고 다음에 올 내용을 예측하지만, GitHub Copilot은 FIM (Fill-in-the-Middle) 이라는 기법도 채택하고 있습니다. 커서 이후의 코드(Suffix)도 프롬프트에 포함하여, "앞뒤 사이에 끼워 넣을 부분을 완성하는" 태스크로서 모델에 제시합니다. copilot-explorer의 분석에서도 isFimEnabled: true로 확인되고 있습니다.

공식 블로그(How GitHub Copilot is getting better at understanding your code)에 따르면, FIM 도입을 통해 제안 수락률(Acceptance Rate)이 +10% 향상되었습니다. 나아가 2025년에는 FIM에 특화된 커스텀 모델을 신규 학습 및 적용하여(The road to better completions), 기존 대비 수락률 +12% · 수락 및 유지 글자 수 +20% · 처리량(Throughput) 3배 · 지연 시간(Latency) 35% 감소를 달성했습니다.

예를 들어 함수의 중간에 처리를 추가하거나, 기존 코드 블록 내의 일부만 다시 쓰는 등의 용도에서 특히 효과를 발휘합니다.

5-4. 백엔드 아키텍처와 프록시

GitHub Copilot의 요청은 다음 경로를 거칩니다.

IDE 확장(VSCode 등)
↓ HTTPS
GitHub 프록시
...

백엔드는 선택하는 모델과 플랜에 따라 다릅니다. 공식 문서(Hosting of models for GitHub Copilot)에 기재된 내용을 정리하면 다음과 같습니다.

"Copilot의 백엔드는 Azure OpenAI Service"라고 설명되는 경우가 있으나, 정확하게는 모델과 플랜에 따라 다릅니다.

프록시 계층에서는 부적절한 콘텐츠나 탈옥(Jailbreak) 시도에 대한 스크리닝과 속도 제한(Rate Limiting)이 수행됨을 공식 문서에서 확인할 수 있습니다.

또한, 응답 생성 후에는 중복 탐지 필터 (Duplicate Detection Filter) 가 작동합니다. 제안된 코드와 그 주변 코드가 공개된 GitHub 상의 코드와 65 렉시엄(Lexeme, 약 150자) 이상 일치할 경우 제안을 숨기는 메커니즘입니다 (공식 문서).

5-5. 리포지토리 인덱스 및 시맨틱 검색

2025년 3월 12일, 리포지토리의 시맨틱 검색 인덱스가 모든 Copilot 사용자(무료 플랜을 포함한 모든 티어)를 대상으로 GA(General Availability)되었습니다 (GitHub Changelog, 2025-03-12). @workspace나 @repo 컨텍스트를 통해 리포지토리 전반에 걸친 시맨틱 검색을 이용할 수 있습니다.

인덱싱 완료 시간은 기존 약 5분에서 "수 초 ~ 최대 60초 정도"로 대폭 단축되어, 거의 즉시 사용할 수 있게 되었습니다. 자세한 설정 방법은 공식 문서(Indexing repositories for GitHub Copilot)를 참조하십시오.

또한, Copilot Coding Agent는 2026년 3월에 시맨틱 코드 검색 가속화가 추가되어, Agent Mode에서의 리포지토리 횡단적 이해 정밀도가 향상되었습니다.

5-6. Agent Mode의 아키텍처 (2025~2026년)

2025년 2월 VS Code의 프리뷰로 Agent Mode가 공개된 이후, GitHub Copilot은 에이전트적인 활용 방식에 대한 투자를 급격히 늘리고 있습니다.

공식 블로그(Agent mode 101)에 따르면, Agent Mode는 백엔드의 시스템 프롬프트(쿼리, 워크스페이스 구조, 머신 컨텍스트, 도구 정의 포함)를 통해 Copilot을 "최종 상태에 도달할 때까지 반복 수행하는" 오케스트레이터(Orchestrator)로 동작하게 하는 설계입니다.

도구(read_file · edit_file · run_in_terminal

등)의 호출 루프를 통해 태스크를 진행하면서, 구문 오류(Syntax Error)·테스트 결과·빌드 오류를 감지하여 자율적으로 수정합니다. MCP 서버와 결합함으로써 외부 리소스에 대한 액세스도 가능합니다. 구조적으로는 Claude Code의 에이전트 루프(Agent Loop)와 유사한 발상입니다.

6. 내부 설계의 차이가 만드는 성능 차이

4장과 5장의 설계 정보를 바탕으로, "왜 체감 성능의 차이가 발생하는가"를 정리합니다.

설계 대비

왜 Claude Code가 대규모 태스크에 강한가

Claude Code 설계의 근간에 있는 "필요할 때 도구로 가져온다"는 동적 컨텍스트 수집 방식은, 대규모 리포지토리(Repository)와 특히 궁합이 좋습니다.

사전에 모든 파일을 읽으려고 하면 컨텍스트 윈도우(Context Window)는 금방 한계에 도달합니다. Claude Code는 그렇게 하지 않기 때문에, 파일 수가 많은 리포지토리에서도 정보의 과적재(Overloading) 없이 긴 에이전트 루프를 지속할 수 있습니다. "여러 파일에 걸친 수정을 한 번의 세션으로 완수한다"는 태스크에서 체감 차이가 나타나기 쉬운 이유는 바로 이 때문이라고 생각됩니다.

게다가, 98.4%의 결정론적 인프라(Deterministic Infrastructure)가 AI의 판단 실수를 인프라 측에서 받아내는 구조로 되어 있어, "도중에 이상한 동작을 하더라도 되돌릴 수 있다"는 안심감을 줍니다.

왜 Copilot이 인라인 완성(Inline Completion)에 강한가 (오랜 기간 연마해 온 설계 배경)

Copilot의 강점은 "지금 쓰고 있는 행의 다음에 올 코드를 저지연(Low Latency)으로 제안한다"는 경험을 계속해서 연마해 온 설계에 있습니다.