1 왜 이 비교가 필요한가
AI 코딩 에이전트 시장이 급속히 수렴하고 있다. 2024년 초까지만 해도 Claude Code 는 “에이전트”, GitHub Copilot CLI 는 “셸 명령 도우미” 로 체급이 달랐지만, 2025년 들어 Copilot CLI 가 에이전트 모드로 진화하며 카테고리 경계가 흐려졌다. 더욱이 Copilot CLI 가 기본 모델로 Claude Sonnet 4.6 을 쓸 수 있게 된 순간, 두 도구를 가르는 변수는 하네스 설계 하나만 남았다.
이 글은 구체적 질문에서 출발한다.
“동일한 Claude Sonnet 4.6 을 백엔드로 쓰고 동일한 시스템 프롬프트(CLAUDE.md)를 주면, 두 CLI 가 같게 동작할까?”
답은 아니다. 그것도 사소한 차이가 아니라 깊은 routing 시나리오에서 완전히 다른 충실성 을 보인다. 이 글은 그 차이의 원인을 역추적하고, 어떤 task 에서 어느 도구가 적합한지 정리한다.
어느 한쪽이 우월하다는 주장이 아니다. 두 하네스는 다른 설계 철학을 구현한 것이며, 각각이 최적화한 영역이 다르다. 목표는 “Task 의 성질에 맞춰 도구를 선택적으로 사용” 하는 실무 판단 기준을 제공하는 것이다.
2 관찰된 행동 차이 — Deep Routing 실험
2.1 실험 조건
공정한 비교를 위해 다음이 통제된 환경을 상정한다.
| 변수 | 값 | 설명 |
|---|---|---|
| 모델 | Claude Sonnet 4.6 | 양쪽 CLI 모두 동일 백엔드 |
| 시스템 프롬프트 | 동일 CLAUDE.md | 프로젝트 단위로 공유 |
| Task | 동일 | 블로그 포스트 작성 등 deep routing task |
| 워크스페이스 | 동일 | 같은 파일 구조, 같은 가이드 파일들 |
변하는 것은 하네스 하나뿐. 이 조건에서 행동 차이가 관찰된다면, 그 원인은 모델이나 프롬프트가 아니라 하네스 설계 자체이다.
2.2 Task 시나리오 — 다단계 라우팅이 필요한 작성 태스크
사용자의 블로그 프로젝트에서 /write 슬래시 커맨드 처리는 다음과 같은 4~5 단계 routing을 요구한다.
사용자 요청 /write
↓
Phase 0: 필수 가이드 파일 로드 (4개)
1. guides/AGENT_GUIDE_CORE.md — 항상-온 규칙
2. AGENT_GUIDE.md — 슬래시 커맨드 라우팅
3. guides/write-post.md — 스킬 가이드
4. docs/blog/posts/{cat}/GUIDE.md — 카테고리 가이드
↓
Phase 1: info-search 3-Layer 병렬 탐색
↓
Phase 2: write-post.md 의 Step 1~6 순차 실행
↓
Phase 3: Self-Check 6 항목 체크리스트 출력
↓
Phase 4: publish.md 로드 → git add → commit → push각 Phase 내부에 다시 Step 세부 지시가 있다. 전체적으로 지시 depth 가 4~5 단계, 준수해야 할 세부 규칙이 수십 개.
2.3 관찰된 차이
Claude Code 에서:
- Phase 0 의 4개 파일을 Read 는 하지만, 각 파일의 세부 Step 을 응답에 명시적으로 출력하지 않음
- Self-Check 6 항목을 내부적으로만 점검 하고 출력 생략
absolute rule 5개중 일부를 암묵적으로 건너뜀 (예:## 1. 개요같은 수동 번호가 들어가는 경우)- 긴 태스크의 후반부로 갈수록 초반에 읽은 가이드의 세부 내용을 잊어버림 — 같은 세션 내에서 이미 주어진 규칙과 모순되는 행동 발생
Copilot CLI 에서:
- Phase 0 의 파일을 Read 하고, 각 가이드의 Step 을 응답에 그대로 반영
- Self-Check 체크리스트를 항목별로 명시적 출력
- 수동 번호 금지·이모지 금지 같은 규칙을 태스크 후반까지 지속적으로 준수
- 응답이 전반적으로 길고 verbose — 사용자가 “짧게” 요구하지 않는 한 단계마다 명시
2.4 사용자의 실증 관찰
CLAUDE.md 자체에 다음과 같은 문구가 있다:
“Claude Code 는 규칙을 자체 요약·압축하거나, 단계를 건너뛰는 경향이 있다.”
이 문장 자체가 누적된 관찰의 산물. 같은 프로젝트·같은 규칙을 Copilot CLI 에 적용하면 이런 방어 문구가 불필요하다는 것이 역설적 증거이다.
3 원인 후보 — 가설 전개의 역사
이 차이의 원인은 단순하지 않다. 실험 과정에서 가설이 단계적으로 정교화됐다.
3.1 가설 1: 모델 차이 (기각)
첫 번째 추측은 “Claude 는 요약을 잘하도록 학습됐고, GPT 는 체크리스트를 따르도록 학습됐다” 였다. 이것이 맞았다면 모델 선택으로 해결됐을 것이다.
기각 이유: 실제로는 양쪽 CLI 모두 Claude Sonnet 4.6 을 사용. 모델이 동일하므로 학습 편향 차이는 이 비교에 적용되지 않는다.
3.2 가설 2: 시스템 프롬프트 차이 (기각)
두 번째 추측은 “Copilot CLI 가 더 엄격한 지시 준수 프롬프트를 내부적으로 주입한다” 였다.
부분 기각: 시스템 프롬프트 내용의 차이는 존재한다. 그러나 CLAUDE.md 라는 사용자 프로젝트 규칙은 양쪽에 동일하게 전달된다. 근본 차이는 “어떻게 프롬프트를 주입하느냐”보다 “주입된 프롬프트를 얼마나 오래·얼마나 충실하게 유지하느냐” 에 있다.
3.3 가설 3: 하네스 설계 차이 (채택)
남은 유일한 변수는 CLI 도구의 하네스(harness) 설계 — 즉 모델과 사용자 사이의 미들웨어가 컨텍스트·도구·응답을 어떻게 관리하는가.
이 가설은 문서화된 증거와 시스템 프롬프트에 박힌 자기 설명으로 확인할 수 있다.
4 하네스 차이 5대 축
4.1 축 1: 자동 압축 (Auto-compaction)
4.1.1 Claude Code 의 정책 — 적극적 자동 압축
Claude Code 시스템 프롬프트에 자체 명시:
“The system will automatically compress prior messages in your conversation as it approaches context limits. This means your conversation with the user is not limited by the context window.”
작동 방식:
- 시스템이 컨텍스트 한계의 일정 임계값 도달 시 자동 판단
- 이전 대화(tool result, 중간 메시지, 사용자 입력 일부)를 요약·압축
- 모델 입장에서는 통제권 밖의 일
결과:
- 긴 대화가 가능해짐 (사용자 입장에서 이득)
- 그러나 Phase 0 에서 읽은 가이드 파일의 세부 내용이 손실될 수 있음 → Phase 4 시점에 “읽었다” 는 메타 정보만 남고 실제 규칙은 사라짐
4.1.2 Copilot CLI 의 정책 — 사용자 명시 호출만
Copilot CLI 에는 /compact 명령이 존재한다. 사용자가 명시적으로 호출할 때만 압축이 일어난다.
작동 방식:
- 컨텍스트가 차올라도 시스템이 자동으로 요약하지 않음
- 사용자가 “지금 압축해” 라고 지시해야 압축
- 압축 전까지는 원문 그대로 유지
결과:
- 깊은 routing 태스크 후반부에도 초반에 로드한 가이드 원문이 남아있음
- 대신 긴 대화에서 응답이 느려지고 토큰 비용 증가
4.1.3 설계 철학의 차이
| 축 | Claude Code | Copilot CLI |
|---|---|---|
| 우선순위 | 컨텍스트 효율성 | 지시 충실성 |
| 긴 대화 | 자동 대응 | 사용자 관리 필요 |
| 원문 보존 | 임계값 초과 시 손실 가능 | 명시적 호출 전까지 보존 |
| 심층 routing 신뢰도 | 낮음 | 높음 |
4.2 축 2: Tool Result 수명 (Lifecycle)
4.2.1 Claude Code 의 정책 — 임시 버퍼 취급
Claude Code 시스템 프롬프트의 결정적 문구:
“When working with tool results, write down any important information you might need later in your response, as the original tool result may be cleared later.”
번역: “Tool result 는 나중에 clear 될 수 있으니, 필요한 정보는 모델이 직접 응답 텍스트 안에 메모해야 한다.”
이것은 사실상 하네스의 자백이다. Tool result 가 영속적이지 않음을 인정하고, 그 책임을 모델에게 전가한다.
실무 영향:
- Phase 0 에서
Read도구로 가이드 4개를 로드해도, Phase 2~4 도달 시점엔 그 파일 내용이 이미 clear 되어 있을 수 있음 - 모델은 자신의 응답에 가이드 내용을 미리 베껴두는 방어 행동이 필요
- 이 방어가 제대로 되지 않으면 “읽었다는 사실만 기억하고 규칙은 잊음” 현상 발생
4.2.2 Copilot CLI 의 정책 — 컨텍스트 한계까지 보존
Copilot CLI 에는 유사한 경고 문구가 없다. Tool result 는 컨텍스트 한계 직전까지 활성 상태로 유지된다.
실무 영향:
- Phase 0 에서 읽은 GUIDE.md 가 Phase 4 Self-Check 시점에도 그대로 참조 가능
- 모델이 규칙을 “기억” 할 필요 없이 파일 내용을 실시간 참조하며 검증
- 응답이 장황해질 수 있지만, 규칙 누락은 거의 발생하지 않음
4.2.3 수명 정책 비교
┌─────────────────┬────────────────────────────┬─────────────────────────┐
│ 시점 │ Claude Code │ Copilot CLI │
├─────────────────┼────────────────────────────┼─────────────────────────┤
│ Tool 실행 직후 │ 전체 내용 사용 가능 │ 전체 내용 사용 가능 │
├─────────────────┼────────────────────────────┼─────────────────────────┤
│ 몇 턴 후 │ 요약 or clear 가능 │ 원문 유지 │
├─────────────────┼────────────────────────────┼─────────────────────────┤
│ 컨텍스트 70% │ 자동 압축 시작 │ 여전히 원문 │
├─────────────────┼────────────────────────────┼─────────────────────────┤
│ 컨텍스트 90% │ 적극적 압축 → 메모 의존 │ 사용자 /compact 요청 필요 │
├─────────────────┼────────────────────────────┼─────────────────────────┤
│ 컨텍스트 100% │ 자동 처리 │ 에러 or 강제 압축 │
└─────────────────┴────────────────────────────┴─────────────────────────┘4.3 축 3: 응답 길이 제약
4.3.1 Claude Code 의 정책 — 시스템 레벨 강제
시스템 프롬프트 말미에 명시:
“Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
번역: “Tool call 사이 텍스트는 25 단어 이하, 최종 응답은 100 단어 이하.”
이것은 사용자의 명시적 요청 없이도 시스템이 강제하는 제약. 토큰 효율성과 응답 속도를 위한 선택이다.
긍정적 영향: 간결한 응답, 빠른 피드백, 낮은 토큰 비용.
부정적 영향: 사용자가 다음과 같이 요구해도 시스템 제약과 충돌한다.
CLAUDE.md:
"각 Step 시작 시 어떤 단계를 수행하는지 사용자에게 보이는 텍스트로 명시한다.
Self-Check 6 항목을 체크리스트 형태로 반드시 출력한다."Self-Check 만 해도 6 줄. 각 Step 명시까지 더하면 tool call 사이 텍스트가 25 단어를 한참 넘는다. 구조적 모순 상황. 모델은 두 규칙 사이에서 절충하는데, 실무적으로는 시스템 제약이 이기는 경우가 많다.
4.3.2 Copilot CLI 의 정책 — 강제 제약 없음
Copilot CLI 의 공개 문서에는 이런 강제 길이 제약이 없다. 모델이 사용자 지시에 따라 자유롭게 응답 길이를 조정할 수 있다.
실무 영향:
- 사용자가 “단계마다 명시해” 라고 하면 그대로 이행
- 응답이 장황할 수 있지만, 명시적 출력 의무는 완전히 지켜짐
4.3.3 길이 제약이 지시 충실성과 충돌하는 이유
많은 프로젝트 규칙이 verbose 한 출력을 요구한다:
- Self-Check 체크리스트 출력
- Step 번호와 요약의 명시적 출력
- 분할 판단 결과 표 출력
- 의사결정 근거 명시
이런 요구는 본질적으로 “모델의 내부 과정을 외부화” 하는 것. 길이 제약이 있으면 이런 외부화가 체계적으로 억제된다. 사용자의 규칙이 강할수록 이 충돌이 심해진다.
4.4 축 4: Skill / Instruction 로딩
4.4.1 Claude Code 의 정책 — Eager 메타데이터 + Lazy 본문
관찰된 사실 (시스템 프롬프트 분석):
- 세션 시작 시 모든 skill 의 메타데이터(이름 + 설명) 가 system-reminder 로 주입됨 (30+ 개 skill 동시 주입)
- Skill 본문은
Skilltool 호출 시에만 로드됨 (lazy) - 호출된 skill 의 본문은 별도 시스템 프롬프트 블록으로 컨텍스트에 주입됨
부작용 — Routing depth 증폭:
Skill A 호출
↓ (시스템 프롬프트에 A 본문 주입)
Skill A 가 Skill B 참조
↓ (B 본문 추가 주입)
Skill B 가 Skill C 참조
↓ (C 본문 추가 주입)각 단계가 컨텍스트를 가속적으로 채우며, 이것이 다시 auto-compaction 을 앞당긴다. 악순환: 깊은 routing → 빠른 컨텍스트 소모 → 이른 압축 → 규칙 손실.
4.4.2 Copilot CLI 의 정책 — 명시적 파일 Read
Copilot CLI 는 skill/instruction 파일을 파일 시스템에서 필요할 때 Read tool 로 직접 가져온다. 미리 주입하지 않는다.
장점 1 — 추적 가능성:
각 Read 가 명시적 tool call 로 실행 로그에 남음. “어떤 파일을 언제 읽었는가” 가 모델 응답의 일부로 기록된다. “읽었다는 사실” 이 메타데이터로 압축되는 게 아니라, 실제 tool call 이력이 남는다.
장점 2 — 컨텍스트 보전:
읽지 않은 파일은 컨텍스트를 차지하지 않음. 필요한 것만 그때그때 로드하므로 routing depth 가 깊어져도 컨텍스트가 일시에 폭발하지 않는다.
단점:
- 모든 가이드 파일을 명시적 Read 해야 하므로 응답이 장황
- 캐싱 효율이 떨어질 수 있음 (같은 파일을 여러 번 읽을 가능성)
4.4.3 두 정책의 대비
| 항목 | Claude Code | Copilot CLI |
|---|---|---|
| 메타데이터 로딩 | Eager (세션 시작 시) | Lazy (필요 시 ls/find) |
| 본문 로딩 | Lazy (Skill tool 호출) | Lazy (Read tool 호출) |
| 로딩 인터페이스 | 전용 Skill tool |
범용 Read tool |
| 컨텍스트 효과 | 호출 시 별도 블록 주입 | 일반 파일 읽기와 동일 |
| 추적성 | Skill 호출 log | 명시적 Read call |
| Depth 증폭 | 심함 (각 skill 이 subskill 호출 시 누적) | 덜함 (파일 읽기로 단일화) |
4.5 축 5: System Instruction Protected Zone
4.5.1 Claude Code — 보호 여부 불확실
Claude Code 내부의 protected zone 존재 여부는 비공개. 관찰 가능한 것:
- CLAUDE.md 내용은 세션 시작 시 시스템 프롬프트로 주입 됨
- 여러 압축 사이클 후에도 CLAUDE.md 규칙이 살아있는지는 장기 세션에서만 확인 가능
- 사용자의 관찰 — “Phase 0 가이드 로드 지시를 건너뛴다” — 은 두 가지 가능성을 시사:
- CLAUDE.md 자체가 완전히 protect 되지 않음
- Protect 되어도 응답 길이 제약 + tool result 압축 때문에 실행 단계에서 누락
4.5.2 Copilot CLI — Protected Zone 추정
Copilot CLI 는 AGENT_GUIDE.md, CLAUDE.md, .github/copilot-instructions.md 같은 custom instruction 파일들을 컨텍스트의 “protected zone” 에 배치하는 것으로 추정된다 (공개 문서 + 관찰 기반 추론).
의미:
- Tool result 는 압축될 수 있어도 규칙 파일은 살아있음
/compact실행 시에도 custom instruction 은 압축 대상이 아님- 장기 태스크에서도 초기 규칙이 원문 그대로 유지
4.5.3 Protected Zone 의 필요성
비유: 운영체제의 보호 모드(protected mode) 메모리 와 비슷한 개념.
- 사용자 프로세스(tool result, 중간 대화) 는 스와핑·압축 대상
- 커널 공간 (시스템 규칙, 사용자 custom instruction) 은 보호
장기 자율 에이전트 (예: PR 작성, 이슈 처리) 는 태스크 시작 시점의 지시를 끝까지 정확히 이행 해야 한다. 중간에 지시가 증발하면 에이전트가 엉뚱한 결과물을 생성. 그래서 구조적 지시 보존이 필수. Copilot CLI 가 원래 GitHub Copilot coding agent 하네스 기반이라는 사실이 이 설계 선택을 뒷받침한다.
5 설계 철학의 근본 차이 — 출발점의 잔재
5.1 Claude Code 의 출발점 — 대화형 어시스턴트
Claude Code 는 초기에 대화형 코딩 어시스턴트로 포지셔닝됐다. 사용자가 질문을 던지고 모델이 답하는 short-term 상호작용이 기본 가정.
이 가정이 낳은 선택:
- 대화가 길어지면 자동 압축해서 흐름 유지 — 대화형 UX 에 맞음
- Tool result 는 즉시 소비되고 잊혀도 됨 — 다음 대화 턴이 주인공
- 짧은 응답이 대화 리듬에 맞음 — 채팅처럼 주고받기
- Skill 본문을 필요 시 주입해서 기능 확장 — 모듈식 성장
5.2 Copilot CLI 의 출발점 — 장기 자율 에이전트
Copilot CLI 는 공식 문서에서 “GitHub Copilot coding agent 와 동일한 agentic harness 기반” 이라고 명시한다. 이 하네스는 원래 자율적으로 PR 을 작성하고, 이슈를 처리하고, 코드베이스 전체를 탐색하는 장기 태스크를 위해 설계됐다.
이 가정이 낳은 선택:
- 태스크 시작 시점의 지시를 끝까지 보존 — 중간 손실이 치명적
- Tool result 원문 유지 — 장시간 탐색 후 초기 발견을 재참조
- 응답 길이 제약 없음 — 자율 작업 로그는 verbose 해야 추적 가능
- Custom instruction protected zone — 태스크 범위 이탈 방지
- 사용자 명시 호출로만 압축 — 자동 처리가 오히려 신뢰성 저하
5.3 근본 Trade-off
┌──────────────────────────────┬─────────────────────────────────┐
│ Claude Code │ Copilot CLI │
├──────────────────────────────┼─────────────────────────────────┤
│ 컨텍스트 효율성 우선 │ 지시 충실성 우선 │
│ 짧은 상호작용에 최적 │ 장기 태스크에 최적 │
│ 자동화된 컨텍스트 관리 │ 명시적 컨텍스트 관리 │
│ 모델이 많은 책임 │ 하네스가 많은 책임 │
│ 토큰 비용 낮음 │ 토큰 비용 높음 │
│ Deep routing 에 취약 │ Deep routing 에 강함 │
└──────────────────────────────┴─────────────────────────────────┘이것은 우열이 아니라 trade-off. 각각이 최적화한 영역이 있다.
6 5대 축 요약 표
| 설계 축 | Claude Code | Copilot CLI | 심층 Routing 영향 |
|---|---|---|---|
| 자동 압축 | 공격적 (시스템 판단) | 사용자 명시 호출만 | Copilot CLI 유리 |
| Tool result 수명 | 임시 버퍼, clear 가능 | 한계 전까지 보존 | Copilot CLI 유리 |
| 시스템 instruction 보호 | 불확실 | Protected zone 추정 | Copilot CLI 유리 |
| 응답 길이 제약 | 25/100 단어 강제 | 없거나 약함 | Copilot CLI 유리 |
| Skill 로딩 | Eager 메타 + Lazy 본문 | 명시적 Read | Copilot CLI 유리 |
| 출발점 | 대화형 어시스턴트 | 장기 자율 에이전트 | — |
편향 경계: 위 표가 “5:0 Copilot CLI 승” 처럼 보이지만, 이것은 “심층 routing + 복잡한 custom instruction” 이라는 특정 시나리오에서의 평가이다. 다른 시나리오에서는 결과가 뒤집힌다 (다음 섹션).
7 Task 유형별 적재적소 가이드
두 도구가 어느 task 에서 어느 쪽이 유리한가를 체계적으로 정리한다.
7.1 Task 분류 축
| 축 1 | 축 2 |
|---|---|
| Routing Depth — 지시의 중첩 깊이 | Context Duration — task 의 시간 규모 |
| 얕음 (1~2단계) ↔︎ 깊음 (4+단계) | 짧음 (몇 분) ↔︎ 김 (수 시간+) |
| 축 3 | 축 4 |
|---|---|
| Instruction Strictness — 규칙 엄격성 | Output Verbosity — 응답 길이 요구 |
| 느슨 ↔︎ 엄격 | 간결 ↔︎ 상세 |
7.2 Claude Code 가 적합한 Task
7.2.1 A. 짧은 turn 단위 반복 작업
특징: 단발 코드 수정, 빠른 디버깅, 1~2파일 편집.
- 축 1 (Depth): 얕음 (단순 Q&A)
- 축 2 (Duration): 짧음 (몇 분~몇 십 분)
- 축 3 (Strictness): 느슨
- 축 4 (Verbosity): 간결
예시:
- “이 함수 이름을 snake_case 로 바꿔”
- “테스트 추가해”
- “이 에러 메시지가 뭘 의미해?”
Claude Code 가 유리한 이유: 압축이 일어나기 전에 작업이 끝나므로 단점이 발현되지 않음. 응답 길이 제약이 오히려 빠른 결과 회수에 유리.
7.2.2 B. 탐색·연구형 질의 (Subagent 활용)
특징: 코드베이스 이해, 라이브러리 사용법 파악, 개념 설명.
- 예: “이 코드베이스는 어떻게 동작하나?”
- 예: “pytorch 의
torch.einsum어떻게 쓰지?” - 예: “이 아키텍처의 핵심 모듈들 간 관계?”
Claude Code 가 유리한 이유:
- Subagent 시스템 (Explore, general-purpose) 이 성숙해 병렬 탐색·요약에 강점
- 1M 컨텍스트 (Opus 4.6) 로 대규모 코드 읽기 가능
- 짧은 응답으로 대화 리듬 유지
7.2.3 C. 대화형 페어 프로그래밍
특징: 사용자와 빠르게 주고받으며 점진적으로 설계.
- 축 1 (Depth): 얕음
- 축 2 (Duration): 중간 (수십 분 대화)
- 축 3 (Strictness): 자유
- 축 4 (Verbosity): 간결 (채팅 리듬)
Claude Code 가 유리한 이유:
- 짧은 응답 + 빠른 응답성 = 대화 리듬에 최적
- “한 발씩 나가며 확인” 스타일에 맞춤
- Auto-compaction 으로 긴 대화도 끊김 없이 진행
7.2.4 D. Hooks 기반 자동화 워크플로
특징: 파일 저장·커밋·특정 이벤트에 자동 실행되는 셸 명령 설정.
- 예: 파일 저장 시 자동 lint
- 예: 커밋 후 자동 푸시
- 예: PreToolUse/PostToolUse 세밀한 이벤트 후크
Claude Code 가 유리한 이유:
settings.jsonhooks 시스템 이 성숙, 사용자 정의 셸 명령을 이벤트 기반으로 실행- Copilot CLI 의 hook 지원은 상대적으로 미성숙 (GitHub Actions 쪽으로 자동화를 밀어내는 경향)
7.2.5 E. 메모리 누적 기반 장기 협업
특징: 사용자 선호·프로젝트 맥락을 세션 간 보존 해 적응형 응답.
- 예: 사용자의 코딩 스타일 학습 및 일관된 적용
- 예: 프로젝트의 암묵적 컨벤션 기억
Claude Code 가 유리한 이유:
- Auto memory 시스템 (
~/.claude/projects/*/memory/) 이 명시적으로 설계 - MEMORY.md 인덱스 자동 로드
- 세션 간 축적되는 사용자 프로파일·피드백·프로젝트 맥락
7.2.6 F. 한 번에 여러 독립 작업 분기
특징: 병렬로 여러 탐색·작업을 동시에 진행.
- 예: “A 를 조사하면서 B 를 빌드하고 C 를 테스트”
- 예: 여러 Agent 가 동시에 다른 분기의 작업 수행
Claude Code 가 유리한 이유:
- 멀티 Agent 병렬 호출 지원
- Background task 지원이 명확
- Explore·Plan 등 subagent 병렬 투입 가능
7.2.7 G. 실험적 프로토타이핑
특징: 일회성 실험, 엄격한 규칙 없음.
- 예: Jupyter notebook 탐색
- 예: PoC 수준 코드
Claude Code 가 유리한 이유: 빠른 응답, 낮은 비용, 규칙 엄격성이 낮아 하네스 차이가 중요하지 않음.
7.3 Copilot CLI 가 적합한 Task
7.3.1 A. 심층 Routing 을 요구하는 다단계 규칙 엄격 준수
특징: CLAUDE.md / AGENT_GUIDE / Skill / Category GUIDE 의 4~5 단계 라우팅, 각 Step 출력 명시.
- 예: 블로그 포스트 자동 작성 (Phase 0~4 + 7단계 구조)
- 예: 엄격한 프로젝트 컨벤션이 있는 기업 코드베이스
Copilot CLI 가 유리한 이유:
- 압축이 자동으로 일어나지 않아 규칙 본문이 끝까지 살아있음
- 응답 길이 제약 약해서 Self-Check 출력 의무 이행 가능
- Instruction protected zone 으로 규칙 손실 없음
7.3.2 B. 장기 자율 실행 (수십 분 이상)
특징: 사용자 개입 없이 수 시간~수일 실행되는 task.
- 예: 큰 리팩토링 (수십 파일 일괄)
- 예: 전체 마이그레이션
- 예: 자동 PR 작성 → 테스트 → 커밋
Copilot CLI 가 유리한 이유:
- 원래 GitHub coding agent 하네스 기반 — PR 자동 생성 같은 장기 태스크용 설계
- Tool result 가 보존되어 후반부에서도 초반 정보 참조 가능
- Instruction 충실성으로 task 범위 이탈 방지
7.3.3 C. GitHub 네이티브 워크플로
특징: PR·Issue·Actions 등 GitHub 인프라와 직접 통합 필요.
- 예: PR 자동 생성·리뷰·머지
- 예: Issue 처리
- 예: Actions 트리거 및 연동
Copilot CLI 가 유리한 이유:
- GitHub 인프라와 네이티브 API 직접 통합
ghCLI 호출이 아니라 GitHub MCP 서버 내장 도구 사용github-mcp-server-*계열 도구로 PR/Issue/Actions 를 도구 호출 수준에서 제어
7.3.4 D. 규칙·가이드라인 누락이 치명적인 작업
특징: 컴플라이언스, 보안, 팀 컨벤션 엄격 준수 요구.
- 예: 컴플라이언스 코드 (금융·의료·보안 규제)
- 예: 보안 감사 코드
- 예: 대기업 팀 환경의 코딩 컨벤션 준수
Copilot CLI 가 유리한 이유:
.github/copilot-instructions.md가 protected zone 에서 보존- “지침을 잊는 일” 이 적음
- 태스크 초반부터 후반까지 같은 규칙 세트 참조
7.3.5 E. 명시적 추적성·감사 가능성이 필요한 작업
특징: 어떤 파일을 언제 읽고 무슨 결정을 내렸는지 로그가 중요한 경우.
- 예: 배포 스크립트 작성 (어떤 설정 파일을 참조했는지 기록)
- 예: 규제 준수 보고서
- 예: 사후 포렌식 가능한 변경 이력
Copilot CLI 가 유리한 이유:
- 모든 가이드를 Read tool 로 명시적 호출 → 도구 호출 로그가 곧 감사 추적
- Tool result 보존으로 사후 검증에서 초기 증거 재참조
- “읽었다” 가 메타데이터 압축이 아니라 실제 이력으로 남음
7.3.6 F. Fleet (병렬 에이전트) 워크플로
특징: 여러 에이전트를 동시에 다른 브랜치·태스크 에 배치.
- 예: 브랜치별 실험을 병렬 실행
- 예: 여러 이슈를 에이전트별로 분담 처리
Copilot CLI 가 유리한 이유:
/fleet기능 이 이 시나리오에 특화- 각 에이전트가 독립된 컨텍스트로 장기 실행
- GitHub 인프라와 결합해 결과를 PR 단위로 통합
7.4 결정 매트릭스
Routing Depth
얕음 ←→ 깊음
짧음 ┌──────────┬──────────┐
│ Claude │ 둘 중 선호 │
│ Code │ (context │
Context │ (채팅) │ 따라) │
Duration ├──────────┼──────────┤
│ Claude │ Copilot │
김 │ Code │ CLI │
│ (단순작업)│(자율에이전트)│
└──────────┴──────────┘실무 판단 순서:
- Routing depth 가 4+ 단계인가? → Yes: Copilot CLI
- 엄격한 custom instruction 이 있는가? → Yes: Copilot CLI
- Verbose output 이 필수인가? → Yes: Copilot CLI
- 위 셋 모두 아님 → Claude Code (비용·속도 우위)
8 하네스별 취약 태스크 — 역관점 분석
적합 태스크의 반대편도 명시적으로 정리할 필요가 있다. 각 하네스의 약점이 치명적으로 드러나는 태스크 를 피하는 것이 도구 선택의 또 다른 축이다.
8.1 Claude Code 가 취약한 태스크
8.1.1 ① 깊은 routing 다단계 규칙 준수
- 증상: Phase 0 → 1 → 2 → 3 → 4 같은 4~5 단계 routing 에서 중간 Step 누락, “읽었다고 주장하지만 실행 안 함” 패턴
- 원인: Auto-compaction 이 중간 단계 tool result 를 요약·제거 + 응답 길이 제약(25/100 단어) 이 Step 별 명시 출력을 억제
8.1.2 ② 장시간 자율 실행 (수십 분~시간 단위)
- 증상: 후반부에서 초반 지시·맥락을 잃거나, 잘못된 가정으로 분기
- 원인: 압축이 누적되며 정보 손실. Tool result 가 “may be cleared” 라 후반에서 초반 파일 내용 재참조 불가
8.1.3 ③ 대규모 일괄 변경 (수십 파일 동시 수정)
- 증상: 중간에 패턴이 흐트러지거나, 일부 파일에서 다른 컨벤션 적용
- 원인: 컨텍스트 압박이 빠르게 와서 초반에 본 패턴을 후반에서 잊음
8.1.4 ④ Verbose 출력 의무가 있는 작업
- 증상: Self-Check 체크리스트 출력, 단계별 명시 보고 같은 의무를 생략하거나 한 줄로 뭉갬
- 원인: 시스템 레벨 길이 제약이 사용자 지시와 충돌. 모델이 “최종 응답 100 단어 이하”를 우선시
8.1.5 ⑤ 명시적 추적성·감사가 필요한 작업
- 증상: “어떤 파일을 언제 읽었는지” 로그가 압축으로 사라짐. “읽음” 메타만 남고 본문 증발
- 원인: Tool result 비영속성. 컴플라이언스·보안 감사 시 재현성 부족
8.1.6 ⑥ 큰 출력물 생성 (긴 문서, 대규모 코드)
- 증상: 중간에 잘리거나, 분할 생성 시 후반부가 전반부와 불일치
- 원인: 길이 제약 + 컨텍스트 압축 이중 영향
8.1.7 ⑦ Skill 을 깊게 중첩 호출하는 워크플로
- 증상: Skill A → Skill B → Skill C 순 호출 시 후반 Skill 에서 초반 Skill 지시 누락
- 원인: Skill 호출마다 시스템 프롬프트 블록이 누적되며 압축 가속
8.2 Copilot CLI 가 취약한 태스크
8.2.1 ① 매우 긴 세션 (수천 turn, 며칠짜리 대화)
- 증상: 자동 압축이 없으므로 컨텍스트가 한계까지 차면 응답이 느려지거나 중단
- 원인: 보존 우선 설계의 대가. 사용자가
/compact를 명시 호출해야 해서 망각하면 누적
8.2.2 ② 빠른 turn 단위 반복 (대화 리듬이 빠른 페어 프로그래밍)
- 증상: 응답이 길고 verbose 해 빠른 주고받기가 둔함. “한 줄 답이면 충분한데” 단락으로 응답
- 원인: 길이 제약이 약해 모델이 본능적으로 길게 설명. 짧은 의사소통 비효율
8.2.3 ③ 가벼운 단발 작업
- 증상: 작은 수정에도 가이드를 모두 읽고 단계별 보고 → 오버킬
- 원인: 충실성 우선 설계가 단순 작업에서 비용·시간 낭비
8.2.4 ④ 동적 메모리·세션 간 적응형 협업
- 증상: 사용자 선호 누적, 과거 대화 참조 같은 장기 기억 활용이 약함
- 원인: Claude Code 의 auto memory 처럼 명시적으로 설계된 세션 간 메모리 시스템이 상대적으로 미성숙
8.2.5 ⑤ 빠른 탐색·요약형 질의
- 증상: 대규모 코드베이스를 빠르게 훑는 작업에서 지연. 모든 Read 를 명시 호출하므로 병렬화 이득이 약함
- 원인: Lazy load 철학의 trade-off. Claude Code 의 Subagent 병렬 탐색이 더 빠름
8.2.6 ⑥ Hook 기반 이벤트 자동화
- 증상: PreToolUse/PostToolUse 같은 세밀한 이벤트 hook 설계 시 제약
- 원인: Claude Code 의 hooks 시스템 (
settings.json기반) 이 더 성숙. Copilot CLI 는 GitHub Actions 쪽으로 자동화를 밀어내는 경향
8.2.7 ⑦ 비용 민감 작업
- 증상: 컨텍스트 보존 우선 → 토큰 사용량 누적 → API 비용 증가
- 원인: 압축을 안 하므로 매 turn 전체 컨텍스트 재처리. Claude Code 의 압축은 비용 절감 측면에서 이점
8.2.8 ⑧ 빠른 프로토타이핑·실험
- 증상: 가이드·규칙을 모두 따르려는 경향이 빠른 시도·폐기 사이클을 둔화
- 원인: “충실성 우선” 설계가 실험적 작업에서 마찰
8.3 공통 취약점 — 둘 다 약한 영역
두 하네스 모두 잘하지 못하는 작업도 있다. 이 영역은 도구 선택으로 해결되지 않으며, 다른 접근(인간 개입·전용 도구)이 필요하다.
8.3.1 ① 진짜로 결정론적 출력이 필요한 작업
동일 입력 → 동일 출력 보장은 LLM 본질상 불가. 두 하네스 모두 한계. 대안: 스냅샷 테스트·seed 고정·외부 결정론적 도구 병용.
8.3.2 ② 외부 상태 의존 작업의 사전 검증
DB 마이그레이션, 분산 시스템 동기화 등 부작용이 큰 작업에서 사전 검증 한계. 대안: Dry-run 모드·스테이징 환경·인간 승인 게이트.
8.3.3 ③ 비문서화된 폐쇄 시스템 분석
학습 데이터에 없는 사내 독점 코드·툴은 둘 다 추측에 의존. 대안: 사내 지식 베이스를 MCP 서버로 노출하거나 RAG 파이프라인 구축.
8.3.4 ④ 실시간 인터랙티브 디버깅
gdb·lldb 세션 실시간 조작 같은 stateful 인터랙티브 작업은 둘 다 부적합. 대안: 디버거는 사람이 직접 조작, LLM 은 로그 해석·가설 생성에 보조.
8.4 두 약점의 본질 — 반대 방향의 설계 Trade-off
- Claude Code 의 약점은 본질적으로 “잊음” — 압축·길이 제약·tool result 비영속성이 만드는 망각.
- Copilot CLI 의 약점은 본질적으로 “무거움” — 보존 우선이 만드는 비용·지연·오버킬.
두 약점은 반대 방향의 설계 trade-off 이다. 한쪽 해결이 다른 쪽 약점을 만든다. 그래서 어느 하나로 모든 태스크를 해결하는 것은 불가능하며, 태스크 단위 분담이 합리적 전략이다.
8.5 피해야 할 도구 — 역관점 매핑
“어느 도구를 쓸 것인가” 와 별개로, “어느 도구를 피해야 하는가” 의 관점도 유용하다.
| 작업 | 피해야 할 도구 | 이유 |
|---|---|---|
| 블로그 포스트 작성 (Phase 0~4 + 7단계 구조) | Claude Code 회피 | 다단계 routing 누락 위험 |
| 카테고리 전체 retrofit (수십 포스트 일괄) | Claude Code 회피 | 대규모 일괄 변경 약점 |
| 장기 audit 전체 카테고리 감사 | Claude Code 회피 | 장시간 실행 + 추적성 |
| Self-Check 출력 의무 워크플로 | Claude Code 회피 | 길이 제약과 충돌 |
| GitHub PR 자동 생성·관리 | Claude Code 회피 | 네이티브 통합 부재 |
| 컴플라이언스·보안 감사 | Claude Code 회피 | Tool result 비영속으로 추적성 부족 |
| 단일 포스트 빠른 형식 교정 | Copilot CLI 회피 | 오버킬, 느림 |
| 메모리 갱신·MEMORY.md 인덱스 정리 | Copilot CLI 회피 | Claude 의 auto memory 가 더 적합 |
/audit 단발 실행 |
Copilot CLI 회피 | 빠른 탐색 작업 |
| 빠른 대화형 질문·페어링 | Copilot CLI 회피 | 응답 verbose, 둔함 |
| Hook 기반 자동화 설정 | Copilot CLI 회피 | Hooks 생태계 미성숙 |
| 병렬 Subagent 탐색 | Copilot CLI 회피 | Lazy load 의 탐색 지연 |
실무 규칙: 태스크가 위 표의 한 행에 해당하면 해당 도구를 적극적으로 피한다. 적합 태스크 판단보다 부적합 태스크 회피가 더 안전한 의사결정일 때가 많다.
9 혼합 사용 전략 (Hybrid Workflow)
두 도구를 배타적으로 쓸 필요는 없다. Task 단계별로 다르게 쓰는 전략이 실무에서 유용하다.
9.1 전략 1: 탐색은 Claude Code, 작성은 Copilot CLI
시나리오: “블로그 포스트 쓰기”
1단계 (Claude Code): 주제 탐색, 아이디어 발산
- "이 주제에 대해 어떤 관점이 가능할까?"
- "핵심 개념 3가지를 정리해줘"
- 대화형, 짧은 응답 OK
2단계 (Copilot CLI): 실제 포스트 작성
- /write 슬래시 커맨드 실행
- Phase 0~4 엄격 준수
- Self-Check 체크리스트 출력이 분할은 각 단계의 성격에 도구를 맞춘다. 탐색 단계에서는 Claude Code 의 속도·비용 이점이 크고, 작성 단계에서는 Copilot CLI 의 충실성이 결정적이다.
9.2 전략 2: 프로토타입은 Claude Code, 프로덕션은 Copilot CLI
시나리오: “신규 기능 개발”
1단계 (Claude Code): 빠른 프로토타입
- PoC 코드 작성
- 실험적 아이디어 검증
- 대화형 디버깅
2단계 (Copilot CLI): 프로덕션화
- 프로젝트 컨벤션 엄수 (lint rule, 테스트 커버리지)
- 문서화 표준 준수
- PR 작성 및 리뷰9.3 전략 3: 검토는 Claude Code, 실행은 Copilot CLI
시나리오: “대규모 리팩토링”
1단계 (Claude Code): 변경 범위 파악
- "이 인터페이스를 바꾸면 어디가 영향받지?"
- 빠른 영향도 분석
2단계 (Copilot CLI): 실제 변경 실행
- 각 파일 수정
- 테스트 실행
- 단계별 커밋9.4 전략 4: 기록 없는 작업 Claude Code, 기록이 필요한 작업 Copilot CLI
기준: “이 작업의 로그가 나중에 감사 대상인가?”
| 답 | 선택 |
|---|---|
| No (개인 탐색·학습) | Claude Code |
| Yes (팀 공유·규제 준수·생산) | Copilot CLI |
10 단일 축 결정의 함정 — “GitHub 쓰니까 Copilot CLI” 는 왜 틀리는가
실무에서 도구 선택을 하나의 관찰 가능한 변수에 환원하려는 유혹이 강하다. 가장 흔한 휴리스틱이 “우리 팀이 GitHub 을 쓰니까 Copilot CLI 가 맞다” 이다. 이 결정은 편리하지만 두 관점을 혼동하는 데서 오는 오판이다.
10.1 두 관점을 분리해야 한다
하나의 프로젝트를 놓고 “어느 하네스가 맞는가” 를 물을 때, 실제로는 두 개의 독립된 질문이 겹쳐 있다.
- Q1. 이 앱을 개발·유지보수할 때 어느 하네스를 쓸 것인가 (개발자 관점)
- Q2. 이 앱이 프로덕션 엔진으로 subprocess 호출하는 하네스는 어느 쪽인가 (아키텍처 관점)
두 질문의 답이 반대 방향으로 나올 수 있다. 이를 구분하지 못하면 “GitHub = Copilot” 같은 단축 결정이 나온다.
10.2 “GitHub 사용” 은 약한 신호이다
Copilot CLI 의 GitHub 네이티브 통합이 빛을 발하는 구간은:
- PR 을 자동 생성하고 인라인 리뷰 코멘트까지 달아야 할 때
- Fleet 로 브랜치별 병렬 에이전트를 돌릴 때
- Issue 를 에이전트 단위로 분담 처리할 때
반면 평범한 git push·git pull·gh pr create 수준의 GitHub 사용은 gh CLI 하나로 충분 하다. 이 경우 하네스 선택은 GitHub 축과 무관하게 다른 4축 (Routing depth, Context duration, Instruction strictness, Output verbosity) 으로 결정된다.
즉 “GitHub 사용 여부” 는 도구 선택의 5축 중 하나 (네이티브 워크플로) 일 뿐이며, 이 축이 단독으로 결정권을 가지려면 고급 GitHub 워크플로 의존도가 실제로 높아야 한다.
10.3 개발 vs 프로덕션 엔진 — 결론이 반대가 되는 전형적 사례
예시 시나리오 — “Azure DevOps 작업 항목을 받아 코드 수정·PR 생성까지 자동화하는 사내 FastAPI 웹앱” 을 생각한다.
| 관점 | Task 특성 | 적합 하네스 |
|---|---|---|
| 개발 (FastAPI 중간 규모 웹앱 유지보수) | 단발 수정·빠른 반복·Hook 자동화·세션 간 메모리 | Claude Code |
| 프로덕션 엔진 (subprocess 로 호출) | 장기 자율 실행·규칙 엄격 준수·PR 자동 생성·추적성 | Copilot CLI 검토 |
한 프로젝트 안에서도 행위의 층위에 따라 하네스 선택이 달라진다. 개발자가 편한 도구와 시스템이 호출할 엔진은 다른 trade-off 집합에 직면한다.
10.4 전환 전 체크리스트 — 성급한 엔진 교체의 비용
프로덕션 엔진이 이론적으로 Copilot CLI 에 적합해 보여도 바로 전환하지 말아야 할 이유가 있다.
| 항목 | 질문 |
|---|---|
| 비용 | 토큰 보존 → per-task 비용 얼마나 증가하는가 |
| 통합 | claude CLI 와 copilot CLI 의 명령어 구조 차이로 subprocess 인터페이스 재작성 부담이 얼마인가 |
| 메모리 | Claude Code auto memory 에 의존하는 Knowledge Base 가 있다면 이전 설계 비용은 |
| 리스크 | 이미 돌아가는 프로덕션 시스템의 검증 손실 위험 |
권장 절차:
- 현재 엔진 유지 + 소량 작업 항목으로 A/B 테스트
- 품질·비용·지연 비교 후 실제 실패 사례가 장시간 맥락 손실에서 오는지 검증
- 맥락 손실이 빈번하고 사업적으로 치명적 이면 전환, 아니면 유지
- 중간 해법: 두 엔진 병렬 운영 — 버그 수정은 Claude Code, 기능 구현은 Copilot CLI 같이 태스크 성격별 분담
10.5 일반화
단일 축 결정의 오류 패턴은 GitHub 축에만 국한되지 않는다. “우리는 X 를 쓰니까 Y 도구” 형태의 모든 추론이 같은 함정에 걸린다. 도구 선택은 5축 × 2 관점의 매트릭스에서 이루어져야 한다. 축 하나만 보면 반대 관점의 요구사항이 구조적으로 무시된다.
11 한계와 불확실성
이 분석은 관찰과 합리적 추론에 기반한다. 확실한 것과 불확실한 것을 구분한다.
11.1 확실한 것 (강한 증거)
- Claude Code 의 auto-compaction — 시스템 프롬프트에 명시적 문구 존재
- Tool result clear 가능성 — 시스템 프롬프트에 명시적 경고 존재
- 응답 길이 제약 25/100 단어 — 시스템 프롬프트에 명시적 수치 존재
- 관찰된 행동 차이 — 동일 모델·동일 프롬프트에서 재현 가능한 차이
11.2 추정 (증거 기반 추론)
- Copilot CLI 의 protected zone — 공개 문서 + 관찰, 직접 확인 불가
- Copilot CLI 의 압축 정책 —
/compact명령 존재로부터 역추론 - Copilot CLI 의 skill 로딩 방식 — 사용자 관찰 신뢰
11.3 불확실 (추가 검증 필요)
- 구체적 압축 알고리즘 — Claude Code 의 압축이 어떤 priority 로 작동하는지 비공개
- Copilot CLI 내부 하네스 상세 — Anthropic 외부의 inspection 한계
- 버전별 변화 — 두 도구 모두 빠르게 진화 중, 이 분석은 2025 말 시점 의 스냅샷
- 모델 벤더 정책 변화 — Copilot 이 다른 모델로 전환할 경우 비교 조건 변경
11.4 해석의 주의
이 글의 분석은 “깊은 routing + 엄격한 custom instruction” 이라는 특정 시나리오에 국한된다. 다른 시나리오 (예: 단순 대화, 짧은 작업, 비용 민감성) 에서는 Claude Code 가 명확히 유리하다.
“어느 쪽이 낫다” 가 아니라 “어떤 용도에 어느 쪽이 맞다” 가 정확한 프레이밍이다.
12 대안 도구의 맥락
다른 AI 코딩 에이전트들과의 관계도 짚고 간다.
| 도구 | 카테고리 | Claude Code/Copilot CLI 와의 관계 |
|---|---|---|
| Aider | 오픈소스 에이전트 | Git 커밋 기반 롤백 — 파괴적 수정 방어 측면에서 보완 |
| OpenDevin | 오픈소스 에이전트 | 자율 에이전트 오픈소스 대안 |
| Cursor | IDE 통합 | 에디터 내 에이전트 — 터미널 CLI 와 보완 |
| Amazon Q Developer CLI | 상용 CLI (구 Fig) | 셸 명령 중심, 일부 에이전트 기능 |
| Warp | 지능형 터미널 | 명령 제안 중심, 에이전트 약함 |
중요한 확인: 2023 년 이전 자료에서 자주 언급되던 Fig 는 2023 년 Amazon 에 인수된 후 Amazon Q Developer CLI 로 통합·재출시됐다. 현재 “Fig” 라는 독립 제품을 대안으로 추천하는 건 부정확하다.
13 실무 체크리스트
13.1 프로젝트 시작 시 질문
두 도구 중 어느 것을 기본값으로 쓸지 결정할 때 점검:
| 질문 | Yes → Copilot CLI | No → Claude Code |
|---|---|---|
| CLAUDE.md 가 200줄 이상인가? | ✓ | |
| Skill 시스템을 적극 사용하는가? | ✓ | |
| 팀 컨벤션 준수가 비즈니스 크리티컬인가? | ✓ | |
| 각 작업의 감사 로그가 필요한가? | ✓ | |
| 장기 자율 태스크(PR 자동화 등)를 돌리는가? | ✓ | |
| 응답 속도가 비용보다 중요한가? | ✓ | |
| 1회성 탐색이 많은가? | ✓ | |
| 프로토타입 단계인가? | ✓ |
3개 이상 ✓ 한쪽 이면 그 쪽을 기본값으로. 혼합 사용도 권장.
13.2 세션 중 전환 신호
한 세션에서 전환을 고려할 신호:
Claude Code → Copilot CLI 로 전환: - 같은 규칙이 반복적으로 무시됨 - Self-Check 가 생략됨 - 응답이 규칙보다 짧음 - Task 가 예상보다 길어짐
Copilot CLI → Claude Code 로 전환: - 응답이 불필요하게 장황 - 단순 질문에 과도한 검증 단계 - 빠른 반복이 필요한 실험 단계
14 사용자의 자기 관찰 인용
이 글의 핵심 관찰은 사용자가 직접 수행한 통제 실험 에서 왔다.
“내가 시스템 프롬프트를 스킬 기반으로 복잡하게 만들면 일련의 지시 routing depth 가 4~5 단계로 깊어지면 클로드 코드는 컨텍스트 압축 기반이기 때문에 문맥을 과하게 압축하여 세부 지시들을 아예 건너뛰거나 읽었어도 실행하지 않는 현상들이 두드러져 반면 copilot cli 는 왠만하면 모든 걸 세세하게 읽고 하나씩 수 많은 규칙들을 단계별로 수행하는 경향이 있어.”
“copilot cli 와 클로드 코드 모두 claude sonnet 4.6 으로 같은 시스템 프롬프트로 실험을 했기 때문에 두 차이점은 오직 cli tools 과 실행 설계 방식의 차이 뿐이야.”
이것이 본 글의 출발점. 모델·프롬프트 변수가 통제된 관찰에서 나온 차이는 전적으로 하네스 설계에 귀속된다는 논리적 결론이다.
Claude 자신의 인정:
이 대화에 참여한 Claude Code 가 스스로 인정한 부분 (원 대화 인용):
“인정한다. 깊은 routing + 다단계 규칙이라는 조건에서는:
- Claude Code: 압축 → 단계 누락 → ‘읽었다고 주장하지만 실행 안 함’ 패턴
- Copilot CLI: 압축 보수적 → 단계 보존 → ‘세세하게 하나씩 이행’ 패턴
이 차이는 하네스 정책(컨텍스트 관리 방식)의 효과다. 단순 모델 비교로는 드러나지 않는 실무적 격차다.”
모델 스스로가 자신의 약점을 인정한 메타 증거이다.
15 결론
15.1 한 문장 요약
같은 Claude Sonnet 4.6 을 써도 Claude Code 는 컨텍스트 효율성에, Copilot CLI 는 지시 충실성에 최적화된 하네스이며, 이 trade-off 의 차이가 task 성격에 따른 적합성을 결정한다.
15.2 약점의 본질 — 반대 방향의 Trade-off
두 도구의 약점은 동전의 양면이다.
- Claude Code 의 약점 = “잊음”: 압축·길이 제약·tool result 비영속성이 만드는 망각
- Copilot CLI 의 약점 = “무거움”: 보존 우선이 만드는 비용·지연·오버킬
한쪽 약점을 해결하려는 설계가 다른 쪽 약점을 만든다. 이것이 어느 하나를 기본값으로 선택하는 것이 근본적으로 틀린 이유이며, 태스크별 분담이 유일한 합리적 전략이라는 결론의 근거이다.
15.3 핵심 메시지 3가지
- “같은 모델 = 같은 성능” 은 환상이다. 하네스가 행동의 절반을 결정한다.
- Task 의 성격이 도구 선택을 주도해야 한다. 기본값으로 한쪽만 쓰는 것은 비효율.
- 편향 없는 비교는 “어느 쪽이 낫다” 가 아니라 “어느 쪽이 어떤 용도에 맞다” 이다.
15.4 실무 액션 아이템
15.5 장기 전망
두 하네스는 수렴 중이다. Claude Code 는 지시 충실성을 강화하고, Copilot CLI 는 효율성을 개선하고 있다. 이 글의 5대 축 비교는 2025 말 스냅샷이며, 6개월~1년 단위로 재평가가 필요.
그러나 출발점의 잔재는 오래 남는다. 대화형에서 시작한 하네스와 장기 자율 에이전트에서 시작한 하네스는 설계 DNA 가 다르며, 이 차이는 근본적으로 해소되기 어려울 수 있다.
16 관련 주제
선행 지식
- Claude Code 의 Long Context 대응 전략
- GitHub Copilot CLI SW Tool 명세와 Claude Code 대조 분석
- Claude Code Custom Tools 와 Agent 연결
- Skill 기반 Agent 패턴
아키텍처 심화
- System Prompt Types 와 Layered Routing
- Attention Dilution 과 2-Pass Workflow
- LLM 지시 준수 메커니즘
- System Prompt Dynamic Injection Architecture
- Skill Routing Scalability and Limits
실무 적용
관련 도구
17 참고문헌
17.1 공식 문서
- Anthropic. (2025). Claude Code Documentation. https://docs.claude.com/claude-code
- GitHub. (2025). GitHub Copilot CLI Documentation. https://docs.github.com/copilot/github-copilot-in-the-cli
- GitHub. (2025). GitHub Copilot coding agent. https://docs.github.com/copilot/using-github-copilot/using-copilot-coding-agent
17.2 하네스 설계 관련 연구
- Yao, S. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629.
- Park, J. S. et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. UIST.
- Hong, S. et al. (2023). MetaGPT: Meta Programming for Multi-Agent Collaborative Framework. arXiv:2308.00352.
17.3 벤치마크
- Jimenez, C. et al. (2023). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770.
- Liu, X. et al. (2024). AgentBench: Evaluating LLMs as Agents. ICLR.
17.4 컨텍스트 관리 기법
- Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560.
- Xu, P. et al. (2024). Retrieval meets Long Context Large Language Models. ICLR.
17.5 경쟁·대안 도구
- Aider-AI. (2024). Aider: AI pair programming in your terminal. https://aider.chat
- OpenDevin. (2024). OpenDevin: An Open Platform for AI Software Developers. https://github.com/OpenDevin/OpenDevin
- Cursor. (2024). Cursor: The AI Code Editor. https://cursor.sh
- Amazon. (2024). Amazon Q Developer CLI (formerly Fig). https://aws.amazon.com/q/developer
17.6 역사적 맥락
- Fig → Amazon 인수 발표 (2023). https://github.com/withfig/autocomplete
- GitHub Copilot CLI 에이전트 모드 출시 (2025).
- Anthropic Claude Code 출시 (2024).