Number 1Jul 2026
Claude Opus 4.8은 GitHub Copilot 안에서도, Claude Code 안에서도 돈다. 모델 버전은 같지만 하네스와 런타임이 다르다. 코드를 쓰는 UX 디자이너 입장에서 하네스가 실제로 무엇을 바꾸는지, 언제 어느 쪽이 맞는지 살펴본다.
Devon Kim 같은 모델, 다른 하네스
같은 디자이너가 같은 작업(검증이 붙은 로그인 화면 만들기)을 같은 모델 버전으로 한다고 해 보자. 양쪽 모두 Opus 4.8이 돈다. 그러면 둘은 똑같이 행동해야 할 것 같다. 그렇지 않다. 이유는 모델 안이 아니라 모델 바깥에 있다.
가장 큰 차이는 능력이 아니라 통제권이다. 두 제품 모두 같은 모델을 돌리지만, Copilot에서는 오케스트레이션 결정을 GitHub가 더 많이 내리고, Claude Code에서는 그 결정을 내가 직접 더 많이 프로그래밍할 수 있다. 컨텍스트, 런타임, hook, skill, 서브에이전트까지, 아래 내용은 모두 이 차이에서 나온다.
이 비교는 두 제품이 같은 기반 모델 버전을 돌린다는 가정에서 출발한다. 그 가정 아래에서 주된 차이는 모델 자체가 아니라 모델을 둘러싼 하네스에서 온다. 한쪽은 4.8, 다른 쪽은 이전 릴리스처럼 버전이 한 번이라도 갈리면, 하네스 때문인지 모델 때문인지 구분할 수 없어서 비교가 의미를 잃는다. 그러니 버전을 고정해 두고 읽어 나가자.
이렇게 정리하면 편하다
행동 = 모델 + 시스템 프롬프트 + 컨텍스트 + 도구 정책 + 런타임. 가중치는 이 합의 한 항일 뿐이다. 시스템 프롬프트, 어떤 컨텍스트가 로드되는지, 어떤 도구가 허용되는지, 출력 상한이 얼마인지, 재시도를 어떻게 처리하는지에 따라 가중치가 똑같아도 행동이 달라진다.
변하지 않는 것
모델 버전. Copilot으로 쓰든 Claude Code로 쓰든 Opus 4.8은 Opus 4.8이다.
변하는 것
합의 나머지 전부다. 컨텍스트를 조립하고 도구 사용을 중개하는 하네스, 그리고 예산·출력 상한·재시도를 관리하는 런타임. 기반 모델은 같아도 런타임에서의 행동은 다르다. 이 페이지의 나머지 부분에서는 버전을 고정한 채 이 변수들을 하나씩 살펴본다.
Copilot은 개발자가 이미 일하는 곳에 모델을 둔다. 두 가지 환경에서 도는데, 성격이 꽤 달라서 나눠 보는 게 낫다.
런타임은 누가 쥐나
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 흐름에 자연스럽게 녹아든 모델이고, 런타임과 컨텍스트 결정은 대부분 플랫폼이 대신 내린다.
Claude Code는 같은 모델 버전을 프로그래밍할 수 있는 하네스로 감싼다. Copilot과의 진짜 차이는 기능 목록이 아니라 통제권이다. 모델이 무엇을 어떤 순서로 읽을지, 그중 무엇을 서브에이전트나 MCP 서버에 넘길지를 내가 더 많이 정한다. README나 바뀐 파일처럼 뻔한 건 여전히 알아서 읽으니 완전히 수동은 아니다. 직접 운전대를 잡을 일이 더 많을 뿐이다.
확장 계층을 정확히 정리하면
런타임은 누가 쥐나
내가 쥔다. 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. 지금 읽고 있는 이 페이지가 곧 하네스로 만든 결과물이다.