Number 1Jul 2026

Claude Opus 4.8은 GitHub Copilot 안에서도, Claude Code 안에서도 돈다. 모델 버전은 같지만 하네스와 런타임이 다르다. 코드를 쓰는 UX 디자이너 입장에서 하네스가 실제로 무엇을 바꾸는지, 언제 어느 쪽이 맞는지 살펴본다.

Devon Kim 같은 모델, 다른 하네스

같은 모델, 다른 하네스


조건

  • 같은 모델 버전: Claude Opus 4.8
  • Copilot GA: 2026년 5월 28일
  • 행동 = 모델 + 하네스 + 런타임
  • 공통점: 둘 다 PR을 열 수 있고, MCP와 연결된다
가정Claude Opus 4.8같은 모델 버전 — 양쪽 모두 같다고 가정GitHub CopilotClaude Code플랫폼이 더 많이 정한다내가 더 많이 정한다컨텍스트런타임확장성프로그래밍 가능성IDE / GitHub가 고름컨텍스트 자동 선택내가 조정어떤 파일을, 어떤 순서로GitHub가 한도 설정예산 · 재시도 · MCP 도구*내가 한도 설정런타임 한도 + 정책AGENTS.md지시CLAUDE.md + hooks지시 + skill + 관문고정 화면 둘agent mode / cloud agent프로그래밍 가능한 파이프라인hook→subagent→skill→QA공통: 둘 다 PR을 연다 · 둘 다 MCP와 연결 · 둘 다 지시 파일을 읽는다* Copilot 클라우드 에이전트 — MCP 도구만, 2026년 1월 기준
그림 1모델은 같고, 차이는 통제권에 있다. 플랫폼이 정하느냐, 내가 정하느냐

차이를 만드는 건 모델이 아니다

같은 디자이너가 같은 작업(검증이 붙은 로그인 화면 만들기)을 같은 모델 버전으로 한다고 해 보자. 양쪽 모두 Opus 4.8이 돈다. 그러면 둘은 똑같이 행동해야 할 것 같다. 그렇지 않다. 이유는 모델 안이 아니라 모델 바깥에 있다.

가장 큰 차이는 능력이 아니라 통제권이다. 두 제품 모두 같은 모델을 돌리지만, Copilot에서는 오케스트레이션 결정을 GitHub가 더 많이 내리고, Claude Code에서는 그 결정을 내가 직접 더 많이 프로그래밍할 수 있다. 컨텍스트, 런타임, hook, skill, 서브에이전트까지, 아래 내용은 모두 이 차이에서 나온다.

이 비교는 두 제품이 같은 기반 모델 버전을 돌린다는 가정에서 출발한다. 그 가정 아래에서 주된 차이는 모델 자체가 아니라 모델을 둘러싼 하네스에서 온다. 한쪽은 4.8, 다른 쪽은 이전 릴리스처럼 버전이 한 번이라도 갈리면, 하네스 때문인지 모델 때문인지 구분할 수 없어서 비교가 의미를 잃는다. 그러니 버전을 고정해 두고 읽어 나가자.

이렇게 정리하면 편하다

행동 = 모델 + 시스템 프롬프트 + 컨텍스트 + 도구 정책 + 런타임. 가중치는 이 합의 한 항일 뿐이다. 시스템 프롬프트, 어떤 컨텍스트가 로드되는지, 어떤 도구가 허용되는지, 출력 상한이 얼마인지, 재시도를 어떻게 처리하는지에 따라 가중치가 똑같아도 행동이 달라진다.

변하지 않는 것

모델 버전. Copilot으로 쓰든 Claude Code로 쓰든 Opus 4.8은 Opus 4.8이다.

변하는 것

합의 나머지 전부다. 컨텍스트를 조립하고 도구 사용을 중개하는 하네스, 그리고 예산·출력 상한·재시도를 관리하는 런타임. 기반 모델은 같아도 런타임에서의 행동은 다르다. 이 페이지의 나머지 부분에서는 버전을 고정한 채 이 변수들을 하나씩 살펴본다.

GitHub Copilot: 에디터와 클라우드 안의 모델

GitHub Copilot

Copilot은 개발자가 이미 일하는 곳에 모델을 둔다. 두 가지 환경에서 도는데, 성격이 꽤 달라서 나눠 보는 게 낫다.

  1. 01Agent mode — 에디터 안에서 동기적으로 돈다. 워크스페이스를 읽고, 여러 파일에 걸친 수정을 제안하고, 내가 지켜보며 방향을 잡는 동안 작업한다. 옆자리 동료 같은 존재다. 다만 이건 위치를 말하는 것이지 할 수 있는 일의 한계가 아니다. 에이전트는 터미널, 브라우저, MCP 도구도 다룰 수 있고, 에디터 밖의 일도 점점 더 많이 한다.
  2. 02Coding agent — 클라우드에서 비동기적으로 돈다. 이슈를 넘기면 백그라운드에서 작업하고, 리뷰할 pull request를 연다.

런타임은 누가 쥐나

GitHub가 쥔다. 요청·컨텍스트 예산, 지연 시간 예산, 출력 토큰 상한, 도구 재시도 정책을 플랫폼 쪽에서 정한다. 2026년 1월 기준으로 클라우드 coding agent는 MCP 도구에만 연결되고, resource나 prompt는 쓸 수 없다. 런타임의 틀은 대부분 이미 정해진 채로 주어진다.

컨텍스트는 어떻게 고르나

상당 부분 자동으로 고른다. 모델이 무엇을 어떤 순서로 볼지 IDE와 GitHub가 많이 정해 준다. 그래서 설정이 가볍고, GitHub 워크플로를 벗어날 일이 없다.

모델은 똑같은 Opus 4.8이다. 2026년 5월 28일 유료 티어(Pro+, Business, Enterprise)에서 Copilot GA가 됐다. Copilot이 주는 건 에디터와 pull request 흐름에 자연스럽게 녹아든 모델이고, 런타임과 컨텍스트 결정은 대부분 플랫폼이 대신 내린다.

요청 하나Opus 4.8GitHub CopilotClaude CodeAgent mode에디터 안, 동기Subagents + hooks내가 조합Cloud agent비동기 화면Skills + MCP내가 확장Pull request리뷰 & 커밋끝은 같고, 과정이 다르다
그림 2

Claude Code: 프로그래밍할 수 있는 하네스 안의 모델

Claude Code

Claude Code는 같은 모델 버전을 프로그래밍할 수 있는 하네스로 감싼다. Copilot과의 진짜 차이는 기능 목록이 아니라 통제권이다. 모델이 무엇을 어떤 순서로 읽을지, 그중 무엇을 서브에이전트나 MCP 서버에 넘길지를 내가 더 많이 정한다. README나 바뀐 파일처럼 뻔한 건 여전히 알아서 읽으니 완전히 수동은 아니다. 직접 운전대를 잡을 일이 더 많을 뿐이다.

확장 계층을 정확히 정리하면

  1. 01CLAUDE.md — 메모리가 아니라 지속되는 프로젝트 지시다. 매 세션 시작 때 컨텍스트에 로드되므로 "항상 테스트를 쓴다" 같은 상시 규칙이 매번 적용된다. 하지만 어제 API 이름을 바꾼 일을 기억하지는 않는다. 지난 일을 기억하는 건 이 파일이 아니라 별도의 auto-memory 기능이다.
  2. 02서브에이전트 — 독립된 두뇌가 아니라, 격리된 컨텍스트를 이용한 오케스트레이션이다. 별도의 LLM이나 프로세스가 아니다. 하네스가 세션 안에서 격리된 컨텍스트 창을 띄워 일을 맡기고 결과를 모은다. 같은 모델을 여러 번 부르는 것이다. 이 사이트는 이런 역할 여섯 개로 짜여 있다.
  3. 03Hook — 라이프사이클 이벤트에서 자동으로 실행되고, 확인 가능한 것을 강제한다. "변경 후" 같은 이벤트에서 돌면서 테스트 통과, 토큰 감사, 린트처럼 기계가 검증할 수 있는 규칙을 강제한다. 레이아웃이 실제로 말이 되는지 같은 주관적인 품질은 판단하지 못한다. 그래서 강제할 수 있게 되는 규칙도 있지만, 디자인 규칙에는 여전히 사람이 필요하다.
  4. 04Skill — progressive disclosure로 필요할 때 로드된다. 모델은 재사용할 수 있는 지시 묶음을 관련이 있을 때 불러오고, 아니면 빼 둔다.
  5. 05MCP — 지금 Copilot이 지원하는 것보다 넓은 클라이언트 범위. Copilot의 클라우드 에이전트는 도구에만 연결되지만, Claude Code는 resource를 포함해 프로토콜을 더 넓게 쓴다. MCP가 발전하면서 정확한 범위는 계속 바뀌니, "완전하다"가 아니라 "더 넓다"고 말하는 게 정확하다.

런타임은 누가 쥐나

내가 쥔다. Copilot에서는 GitHub에 맡기는 부분이다. 출력 상한, 재시도와 권한 정책, 얼마나 병렬로 돌릴지. 두 하네스 모두 런타임이 있지만, 여기서는 플랫폼이 아니라 내가 정한다. 기능이 더 많아서가 아니라 이 부분 때문에 달라진다.

그래서 할 수 있는 것

파이프라인을 조립하고 단계 사이에 통제권을 넘길 수 있다. Task → Hook → Subagent → MCP → Skill → Hook → QA → Commit. 그리고 각 단계를 내 규칙에 맞게 다듬는다.

설정이 더 무거운 건 분명하다. 그 무게는 오케스트레이션의 비용이고, 일이 실제로 오케스트레이션을 필요로 할 때만 값을 한다.

선택: 모델은 같고, 하네스는 일에 맞게

양쪽 모두 Opus 4.8을 돌리고, 둘 다 pull request를 열 수 있고, 둘 다 MCP와 연결된다. 이건 두 제품을 가르는 기준이 아니라 공통점이다. 진짜 질문은 오케스트레이션 결정을 누가 내리느냐다. 플랫폼인가, 나인가.

Copilot이 맞을 때: 에디터 안에서 바로 고치고 싶을 때, 유료 티어에서 이슈를 PR로 자동화하고 싶을 때, 아니면 이미 쓰고 있는 GitHub 워크플로 안에 모델이 자연스럽게 들어와 있기를 원할 때. 런타임과 컨텍스트 결정은 대부분 플랫폼이 맡는다.

Claude Code가 맞을 때: 하네스를 직접 프로그래밍하고 싶을 때. 모델이 무엇을 어떤 순서로 읽을지 고르고, 일을 서브에이전트와 MCP 서버로 나눠 보내고, 확인 가능한 규칙을 hook으로 강제하고 싶을 때. 그리고 그만큼 늘어나는 설정 비용을 감당할 수 있을 때.

솔직하게 말하면

승자는 없다. 둘은 서로 다른 질문에 답하고, 코드를 쓰는 사람 대부분은 결국 둘 다 쓰게 된다. 이 비교 전체에 걸리는 단서가 하나 있다. 두 제품이 한 번이라도 다른 모델 버전을 돌리면, 하네스 효과와 모델 효과를 분리할 수 없으니 더 이상 하네스 비교가 아니다.

작은 사례 하나를 덧붙이면, 이 포트폴리오도 Claude Code 하네스 안에서 만들었다. 서브에이전트 여섯, 상시 지시를 담은 CLAUDE.md, 변경할 때마다 QA를 강제하는 hook. 지금 읽고 있는 이 페이지가 곧 하네스로 만든 결과물이다.


출처