AI 하네스(Harness) vs. 모델(Model): 모두가 놓치고 있는 진짜 AI 경쟁의 본질
원본 영상: YouTube - Nate B. Jones (2026.3.7, Seattle)
원문 뉴스레터: https://natesnewsletter.substack.com
목차
- 들어가며: 우리가 AI를 비교하는 방식의 근본적 오류
- 하네스란 무엇인가: 모델과의 차이
- 아무도 하네스를 비교하지 않는 이유
- 같은 모델, 두 배의 성능 차이: 이것이 증명하는 것
- Anthropic이 Claude Code의 하네스를 구축한 방법
- OpenAI가 Codex의 하네스를 구축한 방법
- 다섯 가지 핵심 분기점: 하네스가 갈라지는 지점들
- 7-1. 실행 철학: Bash vs. 전용 도구
- 7-2. 상태와 메모리: 지식은 어디에 사는가
- 7-3. 컨텍스트 관리
- 7-4. 도구 통합
- 7-5. 멀티에이전트 조율
- 하네스 락인: 아무도 가격에 반영하지 않는 비용
- 엔지니어와 엔지니어링 리더에게 주는 시사점
- 비기술 임원들이 지금 당장 이해해야 하는 이유
- 결론: 하네스 결정은 전략적 약속이다
1. 들어가며
2026년 현재, AI 코딩 도구를 둘러싼 경쟁이 격화되고 있다. 언론과 개발자 커뮤니티의 관심은 온통 “어떤 모델이 더 스마트한가”에 집중되어 있다. Claude가 더 나은가, GPT-5가 더 나은가, Gemini가 어디까지 따라잡았는가. 벤치마크 점수가 공개될 때마다 소셜 미디어는 달아오르고, 개발자들은 자신이 선호하는 모델을 열정적으로 옹호한다.
그런데 시애틀 기반 AI 전략 분석가 Nate B. Jones는 2026년 3월, 이 모든 논의가 근본적으로 잘못된 질문을 하고 있다고 주장한다. 그의 핵심 테제는 간단하지만 충격적이다. 모델은 AI의 두뇌(brain in a jar)에 불과하고, 진짜 중요한 것은 그 두뇌를 둘러싼 몸체, 즉 하네스(harness)다.
이 문서는 그의 영상과 분석을 바탕으로, AI 하네스가 무엇인지, 왜 중요한지, 그리고 Claude Code와 OpenAI Codex가 어떻게 근본적으로 다른 철학을 구현하고 있는지를 상세히 서술한다.
2. 하네스란 무엇인가
“하네스(harness)”라는 단어는 원래 말에 채우는 마구(馬具)를 뜻한다. 아무리 강한 말도 마구 없이는 쓸모 없는 것처럼, 아무리 뛰어난 AI 모델도 그것을 실제 작업에 연결하는 구조 없이는 가치를 발휘하지 못한다는 의미에서 이 단어가 쓰인다.
구체적으로, AI 하네스란 모델을 제외한 나머지 모든 것이다. 다음과 같은 질문들에 대한 답이 하네스를 정의한다.
실행 환경의 문제: AI가 실제로 작업을 수행하는 곳은 어디인가? 사용자의 로컬 컴퓨터인가, 아니면 원격 클라우드 서버의 격리된 컨테이너인가? 이 차이는 단순한 기술적 구현 문제가 아니라, AI가 무엇에 접근할 수 있고 무엇에 접근할 수 없는지를 결정하는 근본적인 아키텍처 선택이다.
메모리와 지속성의 문제: 오늘 AI와 함께 작업한 내용이 내일도 유지되는가? 랩톱을 닫았다가 다시 열었을 때, AI는 어제의 맥락을 기억하고 있는가, 아니면 완전히 새로운 대화를 시작하는가? AI 에이전트는 기본적으로 각 세션이 끝나면 메모리가 초기화되는 특성을 가지고 있는데, 하네스는 이 문제를 어떻게 해결하는가.
도구 접근성의 문제: AI가 프로젝트 관리 도구(Jira, Asana), 디자인 파일(Figma), 테스트 시스템, 코드 저장소(GitHub), 슬랙 등 외부 도구에 접근할 수 있는가? 접근할 수 있다면 어떤 방식으로, 어느 범위까지 가능한가?
병렬 작업의 문제: 여러 작업을 동시에 처리해야 할 때, AI는 팀처럼 협력하며 조율하는가, 아니면 각각 독립된 방에서 서로 소통 없이 작업하는가?
이 모든 것들, 즉 실행 환경, 메모리 관리, 도구 통합, 멀티에이전트 조율 방식이 바로 하네스다. 그리고 Nate의 주장에 따르면, 하네스는 모델보다 훨씬 더 중요하다. 왜냐하면 모델은 다음 토큰을 얼마나 잘 예측하는지를 결정하지만, 하네스는 그 예측 능력이 실제 업무 성과로 얼마나 잘 전환되는지를 결정하기 때문이다.
3. 아무도 하네스를 비교하지 않는 이유
이 개념이 중요하다면, 왜 지금까지 이에 대한 논의가 없었을까? Nate는 몇 가지 이유를 제시한다.
첫째, 테스트하기 어렵기 때문이다. 모델 성능은 벤치마크로 측정하기 비교적 쉽다. HumanEval, MMLU, GSM8K 같은 표준화된 테스트가 있고, 이 점수를 비교하면 된다. 반면 하네스의 성능은 실제 장기 프로젝트에서 팀이 어떻게 일하는지를 봐야 하는데, 이는 통제된 실험으로 측정하기 매우 어렵다.
둘째, 설명하기 어렵기 때문이다. “Claude가 GPT-5보다 코드를 잘 짠다”는 문장은 이해하기 쉽다. 하지만 “Claude Code는 Unix 프리미티브를 조합하는 방식으로 컨텍스트 윈도우를 절약하는 반면, Codex는 격리된 클라우드 컨테이너에서 앱 서버 레이어를 통해 도구를 노출한다”는 설명은 훨씬 복잡하다.
셋째, 총체적 경험을 모델의 공으로 돌리기 쉽기 때문이다. 사용자가 Claude Code를 쓰면서 좋은 결과를 얻으면, 그것이 Claude 모델 덕분인지 Claude Code 하네스 덕분인지 구분하기 어렵다. 자연스럽게 모든 공이 “두뇌”인 모델에게 돌아간다.
그러나 이 맹점은 모든 하네스가 대략 비슷하다면 그다지 심각하지 않다. 문제는, 하네스들이 서로 매우 빠르게, 그리고 의도적으로 분기하고 있다는 것이다. Claude Code와 Codex는 단순히 서로 다른 맛의 같은 것이 아니다. 이들은 인간과 AI가 어떻게 협력해야 하는가에 대한 근본적으로 다른 아이디어를 구현하고 있다.
4. 같은 모델, 두 배의 성능 차이
이론적 주장을 넘어서, 이것이 실제로 중요하다는 것을 보여주는 강력한 데이터가 있다.
2026년 1월, AI Engineer Summit에서 Anthropic은 CORE 벤치마크 결과를 발표했다. CORE 벤치마크는 AI 에이전트의 능력을 측정하는 방식으로, 출판된 과학적 결과를 AI가 재현(reproduce)할 수 있는지를 테스트한다. 이는 단순한 코드 작성 능력이 아니라, 복잡한 다단계 추론과 도구 활용 능력을 종합적으로 평가한다.
결과는 충격적이었다. 완전히 동일한 Claude 모델 — 동일한 가중치, 동일한 훈련 데이터 — 이 두 가지 다른 하네스에서 실행되었을 때 다음과 같은 점수를 보였다.
- Claude Code 하네스 내에서 실행: 78%
- SmolAgents 하네스 내에서 실행: 42%
SmolAgents는 다른 스타트업이 구축한 별도의 하네스다. 동일한 두뇌, 다른 몸체. 그리고 성능 차이는 거의 두 배에 달한다.
이것은 프롬프트 엔지니어링의 미세한 차이로 설명될 수 있는 수준이 아니다. 이것은 구조적인 차이다. 하네스가 컨텍스트를 어떻게 관리하는지, 세션 간에 상태를 어떻게 전달하는지, 도구를 어떻게 연결하는지, 결과를 어떻게 검증하는지 — 이 모든 것이 합쳐져서 36%포인트의 성능 차이를 만들어낸다.
이 숫자는 매우 중요한 함의를 가진다. 하네스는 모델의 지능 위에 얹는 최적화 레이어가 아니라, 모델의 지능이 실제 유용한 작업으로 전환되는 비율을 결정하는 성능 곱셈기(performance multiplier)다.
5. Anthropic의 Claude Code 하네스
Anthropic의 엔지니어링 팀은 자신들의 하네스가 해결하고자 한 문제를 매우 생생하게 표현했다. 그들은 이것을 “교대 근무 엔지니어 문제(shift worker problem)”라고 불렀다.
상상해보라. 소프트웨어 프로젝트가 교대 근무로 일하는 엔지니어들로 운영되고 있다. 각 새로운 엔지니어는 이전 교대에서 무슨 일이 있었는지 전혀 기억하지 못한 채 출근한다. 이것이 바로 AI 에이전트가 여러 컨텍스트 윈도우에 걸쳐 작업할 때 발생하는 일이다. 모델은 똑똑하지만, 각 세션은 완전히 빈 페이지에서 시작한다.
Anthropic의 해결책은 단순한 프롬프팅 이상의 구조적 해결책이었다. Claude Code의 하네스는 두 부분으로 구성된 패턴을 사용한다.
초기화 에이전트 (Initializer Agent)
모든 새 프로젝트의 시작에 먼저 실행되는 에이전트다. 이 에이전트는 다음과 같은 구조화된 아티팩트들을 생성한다.
- 구조화된 기능 목록: 프로젝트에서 구현해야 할 모든 기능을 JSON 형식으로 정리. (마크다운이 아닌 JSON을 선택한 이유가 흥미롭다 — Anthropic의 연구에 따르면 모델이 구조화된 데이터 형식을 태스크 목록으로 사용할 때 손상시킬 가능성이 더 낮다.)
- 초기화 스크립트: 다음 에이전트가 환경을 올바르게 설정할 수 있는 스크립트
- 진행 로그 (progress log):
claude-progress.txt와 같은 파일로, 무엇이 완료되었고 무엇이 남아있는지 기록 - 클린 커밋 (clean commit): 깔끔한 초기 상태의 git 커밋
코딩 에이전트 (Coding Agent)
이후 모든 세션에서 실행되는 에이전트다. 이 에이전트는 매우 일관된 루틴을 따른다.
- 진행 로그 읽기
- git 히스토리 확인
- 기본 테스트 실행 (아무것도 깨져있지 않음을 확인)
- 다음 기능 하나를 선택
- 그 기능 하나만 구현하기 시작
“Bash is all you need” 철학
Claude Code 하네스의 핵심 설계 철학은 “bash만 있으면 충분하다(Bash is all you need)” 다. 수십 개의 전용 도구를 구축하는 대신, 에이전트는 grep, git, npm과 같은 조합 가능한 Unix 프리미티브를 활용하고 이것들을 파이프로 연결해서 즉석에서 매우 유용한 도구를 만든다.
이 접근법의 핵심 이점은 토큰 효율성이다. ML6 팀의 분석에 따르면, GitHub MCP 서버의 38개 도구는 도구 설명만으로도 15,000 토큰을 소비한다. 반면 GitHub CLI는 훨씬 적은 토큰으로 동일한 기능을 수행한다. 컨텍스트 윈도우는 비싼 자원이고, Claude Code는 이를 최대한 아끼도록 설계되었다.
또한 이 방식은 인간 엔지니어가 가진 것과 동일한 접근권을 에이전트에게 준다. 에이전트는 실제 터미널에서, 실제 셸에서, 실제 환경 변수와 SSH 키를 가지고 작업한다.
강제된 점진주의
Claude Code 하네스의 또 다른 핵심 설계 선택은 점진주의의 강제(forced incrementalism) 다. 혼자 두면 모델은 모든 것을 한 번에 구축하려는 경향이 있다. Anthropic은 이것을 “one-shotting”이라고 부른다. 문제는 컨텍스트 윈도우 중간에서 소진되어, 다음 세션이 절반만 완성된 작업을 추측해야 하는 상황이 발생한다는 것이다.
하네스는 태스크 목록을 단일 JSON으로 구조화하고, 에이전트가 세션당 정확히 하나의 기능에만 집중하도록 프롬프팅함으로써 이를 방지한다.
Puppeteer를 통한 검증
Claude Code 하네스는 검증도 강제한다. 에이전트는 Puppeteer MCP 서버 같은 브라우저 자동화 도구를 사용해서 인간이 하는 방식으로 기능을 엔드투엔드 테스트한다. 이를 통해 단위 테스트가 놓치는 버그를 잡아낸다.
트레이드오프: 신뢰 경계
이 아키텍처의 트레이드오프는 명확하다. 신뢰 경계가 당신의 전체 워크스테이션이다. Claude Code에 당신의 컴퓨터 전체에 대한 접근 권한을 부여해야 한다. 이것은 강력하지만, 그만큼 위험하기도 하다.
6. OpenAI의 Codex 하네스
OpenAI의 엔지니어링 팀은 완전히 다른 출발점에서 완전히 다른 아키텍처에 도달했다. 그들의 하네스 구축 경험은 실제 내부 프로젝트에서 나왔다.
100만 줄 프로젝트 실험
OpenAI는 Codex 에이전트만을 사용해서 5개월에 걸쳐 100만 줄짜리 내부 제품을 구축했다. 수동으로 작성된 코드는 한 줄도 없었다. 약 1,500개의 풀 리퀘스트가 생성되었고, 초기에는 단 3명의 엔지니어만이 이 프로세스를 주도했다.
그들의 중심 통찰은 예상과 거의 반대였다. 초기 진행이 예상보다 느렸던 이유는 Codex가 코드를 작성하지 못해서가 아니었다. 환경이 충분히 명세화되지 않았기 때문이었다. 에이전트에게는 높은 수준의 목표를 향해 진행하기 위한 구조, 도구, 피드백 메커니즘이 부족했다.
저장소를 모든 것의 시스템으로
OpenAI의 대응은 저장소(repository)를 모든 것의 시스템으로 만드는 것이었다. 아키텍처 결정, 정렬 스레드, 제품 원칙 — 모든 것이 저장소에 살게 되었다. 저장소에 없는 것은 에이전트에게 존재하지 않는 것과 같다. 에이전트가 격리된 샌드박스에서 작동하기 때문에, 저장소 외부의 것에 접근할 방법이 없다.
점진적 공개 시스템
처음에 OpenAI는 하나의 큰 agents.md 파일 접근 방식을 시도했다. 모든 규칙과 지침을 하나의 마크다운 파일에 넣는 것이다. 이것은 즉각 실패했다. 모든 것이 중요로 표시되면 실질적으로 아무것도 중요하지 않게 된다. 파일은 금방 “규칙의 무덤”이 되어버렸다.
대신 OpenAI는 점진적 공개 시스템(progressive disclosure system) 을 구축했다. 에이전트가 탐색할 수 있는 집중된 교차 링크 문서들로 이루어진 시스템이다. 정보는 계층적으로 구조화되어 있어, 에이전트가 필요에 따라 점점 더 깊은 문서로 들어갈 수 있다.
격리된 클라우드 컨테이너
Codex 하네스의 핵심 아키텍처 선택은 격리(isolation) 다. 각 태스크는 독립된 클라우드 컨테이너에서 실행된다. 코드는 해당 컨테이너에 복제(clone)된다. 인터넷 접근은 기본적으로 비활성화되어 있다. 에이전트는 독립적으로 작업하고, 작업이 완료되면 결과를 제출한다.
이것은 Claude Code의 “책상 옆 협력자” 모델과 대비되는 “클린룸의 계약업체” 모델이다.
검증 도구의 차이
Codex는 런타임에 Chrome DevTools 프로토콜을 직접 에이전트에 연결했다. 이를 통해 에이전트는 DOM 스냅샷, 스크린샷, 네비게이션 기능에 접근할 수 있어 실제로 애플리케이션을 구동하면서 UI 버그를 재현하고 수정 사항을 검증할 수 있다.
또한 모든 Codex 에이전트는 자체적인 임시 관측 가능성(observability) 스택을 가진다. Victoria 로그와 Victoria 메트릭스가 Git 워크트리별로 스핀업되고, 작업이 완료되면 사라진다. 이를 통해 에이전트가 세션 내에서 로그와 메트릭을 직접 조회할 수 있다. 예를 들어 “서비스 시작 시간을 800밀리초 미만으로 만들어라”라는 프롬프트가 실제로 측정 가능한 수락 기준이 된다. 측정할 수 없다면 개선할 수 없기 때문이다.
린터 기반 아키텍처 강제
OpenAI는 엄격한 계층형 아키텍처를 강제하고, 유효한 의존성 방향과 제한된 허용 간선(edges)을 검증하며, Codex 자신이 작성한 린터로 이 모든 것을 체크한다. 린터 오류 메시지는 수정 지침으로도 활용되어, 에이전트가 아키텍처 규칙을 위반하면 오류 메시지가 어떻게 수정해야 하는지도 알려준다.
AI 슬롭 문제와 자가 경찰 저장소
OpenAI는 에이전트 생성 코드에서 독특한 엔트로피 문제를 발견했다. Codex는 저장소에 존재하는 패턴들을 복제하는데, 여기에는 불균일하거나 최적화되지 않은 패턴도 포함된다. 이는 필연적으로 드리프트(drift) 로 이어진다. 초기에 그들은 매주 금요일마다 “AI 슬롭(AI slop)”이라고 부르는 것을 수동으로 정리하는 데 시간을 보냈지만, 이는 확장되지 않았다.
더 확장 가능한 해결책으로, 그들은 저장소에 황금 원칙(golden principles)을 인코딩하고 자동화된 정리 프로세스를 구축했다. 백그라운드 Codex 태스크들이 편차를 스캔하고 타겟된 리팩토링 PR을 열도록 했다. 이를 통해 저장소가 결국 스스로를 경찰하는(police itself) 시스템이 되었다.
7. 다섯 가지 핵심 분기점
Nate는 두 하네스가 분기하는 다섯 가지 핵심 차원을 제시한다. 이것들은 단순한 기능 차이가 아니라, 각 회사가 AI와 인간이 어떻게 협력해야 하는지에 대해 가진 근본적으로 다른 철학의 표현이다.
7-1. 실행 철학: Bash vs. 전용 도구
Anthropic의 접근법은 “Bash is all you need”다. 전용 도구 대신 Unix 프리미티브(grep, git, npm, curl 등)를 조합한다. 하나의 bash 라인이 데이터베이스 쿼리, 결과 필터링, 파일 쓰기를 모두 처리할 수 있다. 이것은 세 개의 별도 도구를 구현하는 것보다 훨씬 적은 토큰을 사용하고 훨씬 더 유연하다.
OpenAI의 접근법은 전용 도구를 직접 구축하는 것이다. Chrome DevTools 프로토콜 직접 통합, 전용 관측 가능성 스택 등이 이에 해당한다. 에이전트는 제어된 환경에서 이 도구들을 RPC 엔드포인트로 호출한다.
핵심 차이는 트레이드오프다. Claude Code는 에이전트에게 당신의 손을 준다 — 실제 환경에 대한 완전한 접근, 조합 가능한 강력함, 그리고 그것이 함의하는 것만큼 위험한. Codex는 통제된 환경에서 맞춤형 손을 구축한다 — 기본적으로 더 안전하지만 당신이 이미 사용하는 도구에 덜 접근할 수 있다.
7-2. 상태와 메모리: 지식은 어디에 사는가
Anthropic의 접근법: 하네스가 에이전트를 기억하게 만든다. claude-progress.txt 같은 진행 파일과 JSON 기능 목록이 에이전트의 기관 메모리(institutional memory)가 된다. claude.md 파일에 투자하는 개발자들은 복리(compounding) 자산을 구축하게 된다. 더 많은 컨텍스트가 축적될수록, 이후의 모든 Claude 세션이 더 잘 작동한다.
OpenAI의 접근법: 하네스가 코드베이스를 기억하게 만든다. 에이전트가 샌드박스에서 작동하기 때문에, 저장소에 없는 것은 존재하지 않는다. 아키텍처 결정, 버그 원칙 등 모든 것이 저장소에 문서화된다.
두 접근법 모두 작동할 수 있지만, 어느 것도 다른 것으로 깔끔하게 이전되지 않는다. claude.md 파일에 팀이 투자한 모든 것은 저장소를 바라보도록 훈련된 Codex에게는 그다지 도움이 되지 않는다. 반대도 마찬가지다.
7-3. 컨텍스트 관리
두 회사 모두 컨텍스트에 대해 동일한 교훈을 배웠다. 더 많다고 더 좋은 것이 아니다 — 큐레이션되지 않으면.
Claude Code의 접근법: 도구와 스킬을 파일 시스템에 파일로 저장한다. 로컬 컴퓨터에 접근할 수 있기 때문에 에이전트는 필요할 때만 스킬을 검색한다. 도구 검색 도구가 에이전트가 사용 가능한 기능을 의미론적으로 검색할 수 있게 해준다. 실제 도구 정의는 에이전트가 사용하기로 결정했을 때만 읽힌다. 또한 Claude Code는 자동으로 오래된 컨텍스트를 요약하고(컨텍스트 압축), 서브에이전트를 생성해서 각자 자신의 컨텍스트 윈도우를 가지도록 한다.
Codex의 접근법: 각 태스크가 격리된 샌드박스에서 실행되기 때문에 태스크들이 컨텍스트 공간을 놓고 경쟁하지 않는다. 더 많은 격리 = 더 적은 오염. 단, 각 태스크에서 독립적으로 컨텍스트를 소비한다.
이것이 시사하는 바는 명확하다. Claude Code는 하나의 태스크가 코드베이스에 대한 깊은 이해를 필요로 할 때 더 낫다. Codex는 독립적인 태스크들을 병렬로 실행하고 중앙 컨텍스트 윈도우를 오염시키지 않으면서 토큰을 소비하고 싶을 때 더 낫다.
7-4. 도구 통합
두 하네스 모두 MCP(Model Context Protocol)를 지원한다. MCP는 Anthropic이 만든 AI 에이전트를 외부 도구에 연결하는 개방형 표준으로, OpenAI, Google, Microsoft, 그리고 이제는 Linux 재단에서 관리하는 광범위한 표준이 되었다.
그러나 표준은 같아도 통합 철학은 매우 다르다.
Anthropic은 스킬(skills)을 도입했다. 스킬은 파일 시스템에 저장된 마크다운 파일과 스크립트다. 에이전트는 스킬의 짧은 이름과 설명(약 50-100 토큰)만 볼 뿐, 수천 토큰에 달할 수 있는 전체 지침은 볼 수 없다. 에이전트가 특정 스킬을 사용하기로 결정할 때만 전체 스킬 정의를 읽는다. 이것은 하네스 설계로서의 컨텍스트 관리다 — 도구 통합 레이어가 의도적으로 토큰에 인색하도록 설계되었다.
OpenAI의 Codex 앱 서버는 스택 옆에서 실행되는 양방향 JSON RPC 하네스다. git, 테스트 러너, Chrome DevTools, 앱 로그, 메트릭을 RPC 엔드포인트로 노출한다. 에이전트는 이 도구들을 프로그래밍 방식으로 호출한다. 통합은 깊지만, 아키텍처는 에이전트가 클라우드의 서버 매개 환경에서 작업한다고 가정한다.
이 차이는 실제 문제로 이어진다. Composio의 테스팅 팀은 Codex가 Figma와 Jira MCP와 함께 작동하게 하기 위해 커스텀 프록시 어댑터를 구축해야 했다. 엔터프라이즈 도구 체인에 AI 코딩 에이전트를 통합할 때 — 에이전트가 Jira에서 읽고, GitHub에 푸시하고, Slack을 업데이트해야 할 때 — 프로토콜 아래의 구현 깊이가 프로토콜 자체만큼이나 중요하다.
7-5. 멀티에이전트 조율
Claude Code의 접근법: 에이전트 팀이 공유 태스크 목록과 의존성 추적을 통해 각각 전용 컨텍스트 윈도우를 가진 여러 서브에이전트를 생성한다. 하나의 서브에이전트가 API를 구축하는 동안 다른 것은 프론트엔드를, 세 번째는 테스트를 작성하며, 이들은 서로 메시지를 주고받을 수 있다. 탐색 서브도구는 매우 빠르고 저렴한 Haiku 모델을 사용해서 대량의 코드를 처리하고 그 결과를 Opus에 돌려준다. 이것은 조율된 협력 모델이다. 코디네이터가 워크플로우를 관리하고 인간이 전략적 감독자로서 루프 안에 있도록 설계되어 있다.
Codex의 접근법: 각 태스크가 독립된 샌드박스에서 실행된다. 조율은 코드베이스 자체를 통해, 일반적으로 git 브랜치 병합을 통해 이루어진다. OpenAI의 실험적 서브에이전트 지원이 향상되고 있지만, Calvin French Owen(Codex 웹 제품 출시를 도왔고 현재 두 도구를 광범위하게 사용하는 개발자)은 병렬성이 Claude Code가 위임을 처리하는 방식에 비해 아직 완전하지 않다고 언급한다.
트레이드오프는 명확하다. Codex의 격리 모델은 자율 운영에서 근본적으로 훨씬 더 안전하다. 에이전트들은 서로를 방해할 수 없고, 서로의 상태에 접근할 수 없으며, 연쇄 실패가 발생할 수 없다.
8. 하네스 락인
지금까지의 논의는 주로 기술적인 것이었다. 이제 이것이 전략적 문제로 어떻게 전환되는지를 살펴보자.
하네스 락인이 실제로 어떻게 복리로 쌓이는지 보여주는 좋은 예시가 있다. Codex 웹 제품 출시를 도왔고 현재 두 도구를 광범위하게 사용하는 Calvin French Owen의 스킬 진화 이야기다.
그는 처음에 단순히 /commit 스킬을 추가했다 — 모델에게 일관된 방식으로 커밋하고 푸시하라고 지시하는 것. 그런 다음 별도의 워크트리에서 작업하는 에이전트들이 필요해지자 /worktree를 추가했다. 그런 다음 항상 먼저 계획한다는 것을 알아차리고, 시작하고 싶을 때를 위해 /implement를 추가했다. 그런 다음 implement 호출을 연쇄하기 시작했다. 결국 구현을 더 쉽게 하기 위해 implement all을 추가했다.
그는 자신만의 환경을 구축하고 있었다. 적어도 여섯 개의 워크플로우 자동화 레이어가 있었고, 각각은 이전 것 위에 구축되었다. 각각은 Claude Code의 하네스 아키텍처 — 스킬 시스템, 컨텍스트 포크, 서브에이전트 모델 — 에 특화되어 있었다.
다른 하네스로 이동하는 것은 단순히 새 명령어를 배우는 것이 아니었다. 동일한 추상화를 지원하지 않을 수도 있는 아키텍처에서 전체 복리 자동화 체인을 처음부터 재구축하는 것을 의미했다.
이제 그 작은 도전을 팀의 모든 엔지니어에게 곱해보라. 그들이 만지는 모든 프로젝트에, 그들이 축적한 모든 마크다운 파일에, 그들이 배포한 모든 MCP 커넥터에. 이것이 사람들이 모델에 대해 이야기할 때 가격에 반영하지 않는 락인이다.
이 상황은 2010년대 초 클라우드 전쟁과 유사하다. 2010년, AWS와 Azure가 둘 다 가상 머신과 오브젝트 스토리지를 제공했기 때문에 기본적으로 같다고 말할 수도 있었다. 기술적으로는 맞는 말이었겠지만 전략적으로는 틀린 말이었다. AWS Lambda가 애플리케이션 설계를 Azure Functions와 다르게 어떻게 재형성할지 이해했던 조직들은 올바른 결정을 내릴 수 있었다.
지금 우리는 AI 코딩 도구의 2010년에 있다. 모델들은 벤치마크에서 비슷해 보인다. 아키텍처들은 2년 후, 2028년에 무엇이 가능한지를 결정할 방향으로 분리되고 분기하고 있다. 그리고 조달 결정은 벤치마크 점수를 보거나 모델이 전부라고 생각하는 사람들에 의해 이루어지고 있다.
조직들은 이러한 도구들을 중심으로 워크플로우를 구축하고 있다. 구독권을 채택하는 것이 아니라, 특정 에이전트 아키텍처를 중심으로 기관 지식, 프로세스 문서화, 검증 프로토콜을 구축하고 있다. 그리고 이 모든 것이 선택한 하네스 주위에 축적되어 매달 가치를 얻는다. 하네스를 전환하면 팀이 새 모델을 배우는 것이 아니다 — 전체 프로세스가 0으로 재설정된다.
9. 엔지니어와 리더를 위한 시사점
개발자 개인에게
코드를 생업으로 하는 개발자라면, 하나의 도구만 선택하는 시대는 끝나가고 있다. 오늘 가장 많은 가치를 추출하는 개발자들은 두 플랫폼 모두를 사용하고 태스크에 따라 작업을 라우팅하고 있다.
Calvin French Owen은 자신의 실용적인 워크플로우를 다음과 같이 설명한다. 그는 계획, 터미널 조율, 코드베이스의 작동 방식 설명에는 Claude Code를 사용한다. Opus는 서브에이전트를 동시에 스핀업하고, 탐색을 매우 빠른 Haiku 인스턴스에 위임하며, Calvin의 말에 따르면 개발자가 언급하지 않은 것들을 제안하는 데 더 창의적이다. 실제 코드를 위해서는 Codex를 사용한다. Calvin에 따르면 Codex 코드가 버그가 더 적다. 그래서 그는 Claude Code로 시작하고 열어두다가, 구현할 준비가 되면 Codex로 전환한다. 때때로 Codex가 Claude의 작업을 검토하게 하면 Claude가 놓친 실수를 잡아낸다.
Calvin은 이것들을 상호 교환 가능한 도구로 보지 않는다. 대신, 그는 이것들을 다른 종류의 투자를 보상하는 보완적 아키텍처로 본다.
핵심 역량은 어느 도구를 사용하느냐가 아니라, 어떤 하네스의 성향이 오늘 하는 작업의 종류와 일치하는지 아는 것이다. 그것이 이 영상에서 이 상세한 내용을 다루는 이유다.
엔지니어링 팀 리더에게
지금 당장 내려야 할 결정은 어떤 도구를 표준화할 것인가가 아니다. 어떤 아키텍처 철학을 중심으로 팀을 조직할 것인가다. 그리고 하이브리드 워크플로우를 구축할 것이라면, 그 경계를 어떻게 지능적으로 처리할 것인가.
이것은 조달 문제가 아니라 프로세스 설계 문제다. 다음과 같은 질문들이 벤더 비교 차트에는 없지만, 엔지니어링 리더의 머릿속에 있어야 한다.
- 팀이 지금 태스크 라우팅을 어떻게 처리하는가?
- 하나의 에이전트를 사용해서 다른 에이전트의 작업을 검토하게 하는가?
claude.md파일에 투자하고 있는가?- Claude Code의 완전 접근 로컬 실행 vs. Codex의 샌드박스 격리의 보안 함의를 어떻게 처리하는가?
하네스의 진화 속도에 주목하라
“Emergent Minds”의 1년 회고는 Claude Code의 진화를 실시간으로 문서화한 가장 상세한 실무자 계정 중 하나다. 저자는 지난 1년에 걸쳐 도구의 다섯 가지 뚜렷한 시대를 설명하며, 각각이 이전 접근 방식을 구식으로 보이게 만들었다. roadmap.md나 ultrathink나 scratchpad 같은 커뮤니티 해결책들이 시간이 지남에 따라 Claude Code의 네이티브 하네스 기능으로 체계적으로 흡수되었다.
그의 메타 관찰은 주목할 만하다. “CLI 도구 레이어는 해자(moat)가 없다. 모든 좋은 패턴은 제품으로 흡수된다.” 하네스는 빠르게 진화하고 있고, 모든 면에서 그렇다. 질문은 어떤 하네스가 오늘 더 나은가가 아니다. 어떤 하네스의 진화 궤적이 팀이 향하는 곳과 일치하는가다.
10. 비기술 임원들을 위한 시사점
비기술 시니어 리더이고 이러한 도구들에 대한 예산 결정을 내리고 있다면, 이것을 이해해야 한다. 팀이 렌치(wrench)를 사달라고 요청하는 것이 아니다. 그들은 작업대(workbench) — 하나 또는 두 개 — 와 인간과 AI 에이전트의 관계를 조직하는 방식을 요청하고 있다. 그리고 이것은 비즈니스 전반의 속도, 보안 태세, 고용 능력, 앞으로 몇 년간의 전환 비용을 형성할 것이다.
올바른 질문은 어떤 도구가 가장 저렴한가가 될 수 없다. 어떤 아키텍처 철학이 팀의 작업 방식과 일치하는가, 그리고 마음을 바꾸는 데 얼마나 드는가여야 한다. 두 번째 질문에 대한 답은 일반적으로 “많이”이며, 매 분기마다 올라간다. 왜냐하면 매 분기마다 팀이 선택한 아키텍처를 중심으로 더 많은 인프라를 구축하기 때문이다.
하네스의 “누출” 효과
이것이 코딩 도구에만 해당하는 이야기가 아니라는 점도 중요하다. Anthropic의 Co-work는 기본적으로 Claude Code를 비코딩 지식 업무용으로 재포장한 것이다. Claude Code가 Co-work의 기반이다. 동일한 하네스 철학 — 계획, 서브에이전트를 통한 순차적 태스크 실행, 구조화된 진행 추적 — 이 지식 업무에 적용된다. 이것이 2026년 하반기로 들어가면서 마케팅, 제품, 고객 성공 업무로 누출되고 있다.
비기술적 직원들이 사용하는 AI 도구들도 결국 이러한 하네스 아키텍처 위에 구축될 것이다. 엔지니어링 리더들이 지금 내리는 하네스 결정이 나머지 우리 모두가 2026년 하반기의 세상을 경험하는 방식을 형성할 것이다.
11. 결론
모든 사람이 “어떤 모델이 최고인가?”라고 묻고 있다. 이 질문은 2022년이나 2023년의 질문이고, 유효 기간이 매우 짧다. 모델들은 계속 개선된다. 어떤 모델이 특정 출시에서 얻는 이점은 일시적이다.
그 아래에 있는 진짜 질문은 충분히 제기되지 않고 있다. 우리는 AI 분야에서 가장 중요한 두 회사가 인간과 AI 에이전트가 어떻게 함께 일해야 하는지에 대해 진정으로 다른 베팅을 하는 것을 목격하고 있다. 그리고 그들은 그것을 너무나 강하게 믿어서, 특정 하네스 내에서 작동하도록 모델을 훈련시키고 있다.
| 차원 | Claude Code (Anthropic) | Codex (OpenAI) |
|---|---|---|
| 실행 환경 | 로컬 환경 (bash 기반) | 격리된 클라우드 컨테이너 |
| 메모리 | 에이전트가 기억 (progress file, claude.md) | 코드베이스가 기억 (repo-as-truth) |
| 도구 통합 | Unix 프리미티브 + MCP | 전용 RPC 도구 + MCP |
| 컨텍스트 관리 | 서브에이전트 + 컨텍스트 압축 | 태스크 격리 |
| 멀티에이전트 | 조율된 협력 | 격리된 병렬 |
| 신뢰 경계 | 전체 워크스테이션 | 샌드박스 컨테이너 |
| 이상적 시나리오 | 깊은 코드베이스 이해 필요 | 독립적 병렬 태스크 |
하네스 결정을 전략적 약속으로 대우해야 한다. 그것은 실제로 전략적 약속이기 때문이다. 그리고 하네스를 파헤쳐 이해하는 쉬운 방법을 택하지 않으면, 우리 모두는 하네스 락인을 어려운 방법으로 발견하게 될 것이다.
부록: 핵심 개념 용어집
| 용어 | 설명 |
|---|---|
| 하네스 (Harness) | AI 모델을 실제 작업에 연결하는 모든 구조적 요소의 총칭. 실행 환경, 메모리 관리, 도구 통합, 멀티에이전트 조율 방식 등 포함 |
| 컨텍스트 윈도우 (Context Window) | AI 모델이 한 번에 처리할 수 있는 정보의 양. 이 안에 들어있는 내용이 AI의 “단기 기억”을 구성함 |
| 서브에이전트 (Sub-agent) | 메인 에이전트가 특정 태스크를 위해 생성한 보조 에이전트 |
| MCP (Model Context Protocol) | Anthropic이 만든 AI 에이전트와 외부 도구를 연결하는 개방형 표준. 현재 Linux 재단이 관리 |
| 점진적 공개 (Progressive Disclosure) | 에이전트가 필요에 따라 더 깊은 수준의 정보에 접근할 수 있도록 계층적으로 구조화된 문서 시스템 |
| 하네스 락인 (Harness Lock-in) | 특정 하네스 아키텍처를 중심으로 축적된 워크플로우, 자동화, 문서 등이 다른 도구로 전환을 어렵게 만드는 현상 |
| CORE 벤치마크 | AI 에이전트의 능력을 측정하는 벤치마크. 출판된 과학적 결과를 AI가 재현할 수 있는지를 테스트 |
| One-shotting | AI가 모든 것을 한 번에 구축하려는 경향. 컨텍스트 윈도우 소진으로 이어질 수 있음 |
| AI 슬롭 (AI Slop) | 에이전트 생성 코드에서 발생하는 불균일하거나 최적화되지 않은 패턴들의 누적 |
| Co-work | Anthropic이 Claude Code를 기반으로 만든 비코딩 지식 업무용 AI 도구 |
이 문서는 Nate B. Jones의 YouTube 영상 및 Substack 뉴스레터 내용을 기반으로 작성되었습니다.
원본: https://www.youtube.com/watch?v=09sFAO7pklo
작성일: 2026-03-07