이 글의 흐름

• 우선 정리: Claude Code / Codex와 GitHub Copilot은 성격이 다르다
• 왜 '같은 모델'이라도 경험이 같지 않은가
• 비유로 보기: 같은 엔진, 다른 차체
• 하네스(Harness)의 정체 (이 부분이 가장 핵심)
• 그래서, 내일부터 어떻게 구분해서 사용할 것인가
• 이것은 도구 비교가 아니라, 하네스 엔지니어링(Harness Engineering)에 관한 이야기

우선 정리: Claude Code / Codex와 GitHub Copilot은 성격이 다르다

먼저, 세 가지 성격의 차이를 한 장으로 정리합니다.

GitHub Copilot은 Claude Code나 Codex와는 성격이 조금 다르다고 생각합니다.

Claude Code는 Anthropic이 자사 모델인 Claude를 전제로 만든 전용 하네스(Harness)입니다. Codex 역시 OpenAI가 자사 모델을 전제로 설계한 코딩 에이전트(Coding Agent)입니다. 반면 GitHub Copilot은 OpenAI, Anthropic, Google 등 여러 모델을 GitHub나 VS Code, 기업의 개발 워크플로우에 통합하는 플랫폼에 가까운 존재입니다.

물론 Microsoft도 자사 모델을 육성하고 있습니다. 따라서 "Microsoft는 단순한 플랫폼 사업자일 뿐이다"라고 단정 짓는 것은 조금 무리가 있을지도 모릅니다. 다만, 적어도 코딩 AI의 최전선에서는 GitHub Copilot이 "자사 모델과 자사 전용 하네스로 완결되는 제품"이라기보다, 여러 외부 모델을 탑재하는 범용 샤시(Chassis)로서의 성격이 강해 보입니다.

이 점이 Claude Code나 Codex와의 큰 차이점이라고 느낍니다.

🔧 엔지니어를 위한 기술적 설명

정확히 말하면, 세 가지는 '모델'이 아니라 '모델 + 그것을 구동하는 제품(에이전트)'의 레이어에서 비교해야 합니다. Claude Code / Codex는 제공처가 자사 모델에 맞춰 툴 정의(Tool Definition), 시스템 프롬프트(System Prompt), 에이전트 루프(Agent Loop), 컨텍스트 관리(Context Management)까지 수직 통합한 일체형 에이전트입니다. GitHub Copilot은 여러 벤더의 모델(OpenAI / Anthropic / Google 등)을 전환하며 에디터, 리포지토리, 기업 정책에 통합하는 오케스트레이션(Orchestration) 계층에 가까운 설계입니다.

Microsoft도 자사 모델(MAI 계열)을 보유하고 있으므로 "모델을 가지고 있지 않다"는 부정확한 표현이지만, 코딩 에이전트의 최전선에서는 외부 모델을 탑재하는 비중이 크다는 것이 타당한 설명입니다. 따라서 비교의 축은 "어떤 모델인가"뿐만 아니라 "모델을 어떻게 감싼 제품인가"가 되어야 합니다. 이 부분을 나누어 보면 체감 차이를 설명할 수 있습니다.

왜 '같은 모델'이라도 경험이 같지 않은가

이 "성능이 다 발휘되지 않는" 느낌을 먼저 한 장으로 정리합니다.

그렇기 때문에 같은 Claude Sonnet이나 GPT 계열의 모델을 사용하고 있더라도, 경험이 반드시 같아지는 것은 아닙니다.

개인적으로는 같은 모델을 사용하더라도 Copilot에서는 조금 "성능이 다 발휘되지 않는" 느낌이 있습니다. 이는 모델 자체가 나쁘다는 이야기가 아닙니다. 오히려 모델 주변에 있는 하네스(Harness)의 차이라고 생각합니다.

어떤 시스템 프롬프트로 구동하는가. 어떤 파일을 어떤 순서로 문맥(Context)에 넣는가. 어디까지 자율적으로 리포지토리를 탐색하는가. 명령 실행이나 테스트 실패를 얼마나 끈기 있게 수정하는가. 어느 정도의 문맥 예산(Context Budget)이나 토큰 예산(Token Budget)을 사용할 수 있는가. 어떤 안전 제약이나 기업 정책 안에서 작동하는가. 이 부분이 다르면 같은 모델명이라도 나오는 결과는 상당히 달라집니다.

🔧 엔지니어를 위한 기술적 설명

같은 가중치(Weight, 모델)라도 추론(Inference) 시의 발판이 다르면 출력은 달라집니다. 주로 영향을 미치는 레버(Lever)는 다음과 같습니다.

시스템 프롬프트와 툴 스키마(Tool Schema): 함수 호출(Function-calling)의 정의, 허용된 조작, 정지 조건. 에이전트의 "움직임"을 거의 규정함 -
컨텍스트 구성 방식: 임베딩 검색(Embedding Search)으로 스니펫을 소량 전달하는지, 리포지토리 맵(Repository Map)·AST·관련 파일을 풍부하게 전달하는지. 투입 순서와 위치("Lost in the middle"의 영향), 토큰 예산, 프롬프트 캐시(Prompt Cache)의 효율 -
에이전트 루프의 깊이: 관찰(Observe) → 행동(Act)의 반복 횟수, 테스트/빌드 실패로부터의 자기 수정, 계획(Planning)·스크래치패드(Scratchpad), 턴(Turn)을 넘나드는 요약과 컨텍스트 압축 -
디코딩 설정과 모델 버전: Temperature, 최대 출력 토큰, 확장 사고(Reasoning) 유무, 스냅샷 버전, 대규모 제공 시의 최적화 또는 저가형 모델로의 라우팅(Routing), 속도 제한(Rate Limit) -

각 기업이 설정의 상세 내용을 공개하고 있는 것은 아니므로, 여기서는 '제품별 주장'이 아니라 '결과를 좌우하는 설계 차원'으로 읽어주시기 바랍니다. 어찌 되었든, '같은 모델명'이 '같은 경험'을 의미하지는 않습니다.

비유로 보기: 같은 엔진, 다른 차체

이 비유를 한 장의 그림처럼 정리해 보겠습니다.

비유하자면, 같은 엔진이라도 F1 머신에 얹느냐, 업무용 차량에 얹느냐, 배송 트럭에 얹느냐에 따라 주행 성능이 달라지는 것과 같습니다.

Claude Code나 Codex는 모델의 힘을 직접 끌어내기 위해 만들어진 전용 머신에 가깝습니다. 반면 Copilot은 기업의 개발 현장에 폭넓고 안전하게, 표준 도구로서 배포하기 위한 범용 차량에 가깝습니다. 어느 쪽이 더 우월하다는 이야기가 아니라, 설계의 목적이 다르다고 생각합니다.

그렇기에 짧은 인라인 보완(Inline Completion)이나 간단한 코드 생성에서는 Copilot으로도 충분히 편리합니다. 오히려 VS Code나 GitHub에 자연스럽게 통합되어 있는 만큼, 일상적인 사용에서는 매우 강력한 측면이 있습니다. 다만, 긴 호흡의 여러 파일을 가로지르는 에이전트(Agent) 작업으로 넘어가면 차이가 나기 쉽습니다.

Claude Code나 Codex는 읽고, 생각하고, 고치고, 실행하고, 테스트하고, 실패 로그를 보고, 다시 고치는—이러한 루프(Loop)를 깊게 돌려준다는 인상이 있습니다. 반면 Copilot은 기업용으로 안전하고 폭넓게 배포하기 위한 설계인 만큼, 상황에 따라서는 조금 신중하며 문맥(Context)을 파악하는 방식이나 에이전트 루프의 깊이가 절제되어 있다고 느껴질 수 있습니다.

하네스(Harness)의 정체 (이 부분이 가장 핵심)

여기서 잠시, 무엇이 영향을 미치고 있는지 나열해서 살펴보겠습니다. 결과에 영향을 주는 것은 모델 그 자체보다, 그 주변의 다음과 같은 요소들입니다.

• 어떤 시스템 프롬프트(System Prompt)로 구동하는가
• 어떤 파일을 어떤 순서로 문맥(Context)에 넣는가
• 어디까지 자율적으로 리포지토리(Repository)를 탐색하는가
• 명령 실행이나 테스트 실패로부터 얼마나 끈기 있게 회복(Recovery)하는가
• 어느 정도의 문맥/토큰(Token) 예산을 사용할 수 있는가
• 어떤 안전 제약이나 기업 정책(Policy) 안에서 동작하는가

이것들을 통칭하여 '하네스(Harness)'라고 부릅니다. 전용 하네스를 갖춘 Claude Code나 Codex는 이 하나하나가 자사 모델에 맞춰 정교하게 만들어져 있습니다. 범용 샤시(Chassis)를 사용하는 Copilot은 어떤 모델이라도 안전하게 돌릴 수 있도록 만들어져 있는 만큼, 이 부분이 다소 절제되기 쉽습니다.

🔧 엔지니어를 위한 기술적 관점

하네스를 분해하면 대략 다음과 같은 부품들로 구성됩니다.

• 오케스트레이션 루프(Orchestration Loop): ReAct적인 '관찰→행동→관찰'을 돌리는 제어. 반복 상한·종료 판정·실패 시의 재시도(Retry) 방침
• 도구/함수 인터페이스(Tool/Function Interface): 파일 읽기/쓰기, 셸(Shell) 실행, 테스트 실행, 검색. 스키마(Schema)와 권한이 에이전트의 한계를 결정함
• 컨텍스트 매니저(Context Manager): 무엇을, 얼마나, 어떤 순서로 넣을 것인가. 검색, 리포지토리 맵(Repository Map), diff, 턴(Turn) 간 메모리, 압축
• 회복 전략(Recovery Strategy): 컴파일/테스트 실패 로그를 읽고 수정하기, 막다른 길(Deadlock) 탐지, 재계획(Replanning)
• 가드레일/정책 계층(Guardrail/Policy Layer): 실행 가능한 작업, 리뷰 필수 범위, 사내 규정 반영
• 평가 하네스(Evaluation Harness): 회귀 테스트(Regression Test)나 벤치마크를 통해 기반 자체를 측정하고 개선을 반복

에이전트의 강함은 대체로 '모델의 지능 × 이 기반(Harness)의 질'로 결정됩니다. 같은 모델이라도 루프가 얕거나, 문맥이 얇거나, 회복력이 없는 기반이라면 힘을 다 발휘할 수 없습니다.

그래서, 내일부터 어떻게 구분해서 쓸 것인가

그렇게 생각하면, Copilot을 사용할 때는 Claude Code나 Codex보다 사용자 측에서 프롬프트를 더 정성스럽게 설계해야 할 필요가 있다고 느낍니다. 어떤 파일을 봐주길 원하는지, 어떤 전제를 지켜주길 원하는지, 어디까지 자율적으로 변경해도 되는지, 무엇을 결과물로 내놓길 원하는지, 사내 표준이나 공식 문서를 우선시해야 하는지, 설계·구현·리뷰·테스트 중 어디까지를 맡기고 싶은지 말입니다. 이러한 지시를 명확히 하지 않으면, 편리하기는 하지만 모델의 능력이 다 발휘되지 못한 채 끝나버릴 수 있습니다.

현재로서는 짧은 보완이나 일상적인 개발 지원에는 Copilot, 긴 호흡의 여러 파일을 가로지르는 자율적인 작업에는 Claude Code나 Codex를 사용하는 것이 자연스럽게 느껴집니다. 물론 이 차이가 영원히 고정된 것은 아닙니다. Microsoft와 GitHub도 Copilot의 에이전트 기능을 강화하고 있으므로, 하네스가 개선된다면 이러한 체감 차이는 줄어들 가능성이 있습니다.

🔧 엔지니어를 위한 기술적 관점

범용 하네스 측의 부족함은 이용자 측의 입력 설계(Input Design)를 통해 어느 정도 메울 수 있습니다. 실무적으로는 이 지점입니다.

• 보고 싶은 파일/디렉터리를 명시한다 (자율 탐색에만 전적으로 맡기지 않는다)
• 수락 조건(Acceptance Criteria)을 테스트나 기대 출력으로 구체화한다. 가능하다면 실패하는 테스트를 먼저 전달한다
• 변경해도 좋은 범위와 지켜야 할 전제(API 호환성, 사내 표준, 공식 문서 우선)를 선언한다
• "먼저 계획을 세워줘"와 같이 단계를 나누어, 설계→구현→테스트→리뷰 중 어느 부분을 맡길지 구분한다
• 긴 다중 파일 작업은 에이전트 모드(Agent Mode)나 전용 도구를 사용하고, 짧은 보완은 인라인(Inline)으로 사용하는 등 작업에 따라 구분하여 사용한다

요컨대, 전용 하네스(Harness)가 내부에서 수행하는 '문맥(Context) 준비'와 '루프(Loop) 설계'를, 얇은 측면(Thin side)에서는 인간이 프롬프트(Prompt)로 대신 수행한다는 발상입니다. 이 지점을 의식할 수 있느냐가 동일한 도구를 사용하더라도 성과의 차이로 나타납니다.

이것은 도구 비교가 아니라, 하네스 엔지니어링(Harness Engineering)에 관한 이야기입니다

마지막으로, 지금까지의 내용을 한 장으로 정리합니다.

그리고 이 이야기는 단순한 도구 비교가 아니라고 생각합니다.

AI 시대의 성과는 모델 그 자체만으로 결정되지 않습니다. 그 모델을 어떻게 둘러싸고, 어떻게 문맥을 전달하며, 어떻게 도구를 사용하게 하고, 어떻게 실패로부터 회복하게 할 것인가. 즉, 주변 시스템 = 하네스의 설계가 상당히 크게 작용합니다.

같은 엔진이라도 얹는 차체가 다르면 주행 성능이 달라집니다. 같은 연주자라도 홀이나 지휘자, 악보를 전달하는 방식이 다르면 연주가 달라집니다. GitHub Copilot에서 느끼는 '성능이 다 발휘되지 않는' 듯한 감각은, 바로 그 차이가 겉으로 드러난 하나의 사례라고 생각합니다.

모델의 이름만 보고 속도를 논하는 것이 아니라, 그 주변을 어떻게 설계할 것인가. 앞으로는 이 부분을 고민할 수 있는 능력이 AI를 사용하는 측의 실력이 되어갈 것이라고 느낍니다.