2026 AI 코딩 에이전트 지형도 — 하네스, Claude Code, Codex 한눈에
2026년 초 기준으로 "AI로 코딩한다"는 말의 의미가 완전히 바뀌었다. 2년 전만 해도 그것은 에디터 안에서 회색 글씨로 뜨는 자동완성을 탭으로 받아들이는 행위였다. 지금은 터미널에 작업을 던져두면 에이전트가 파일을 읽고, 테스트를 돌리고, 실패를 보고 스스로 고치고, PR을 올리는 것을 의미한다. 사람은 리뷰어이자 방향을 정하는 사람으로 물러난다.
이 글은 그 지형도를 한눈에 정리하는 허브(pillar) 글이다. 큰 흐름 — 자동완성에서 에이전트로, 그리고 다시 "하네스(harness) 시대"로의 이동 — 을 짚고, 왜 2026년의 진짜 승부처가 모델 자체가 아니라 모델을 감싼 스캐폴딩인지 설명한 뒤, Claude Code와 Codex를 한 장의 표로 비교한다. 각 주제의 깊은 이야기는 시리즈의 네 편에서 따로 다룬다.
진화의 네 단계: 자동완성에서 하네스까지
지난 몇 년의 흐름을 한 축으로 압축하면 이렇게 된다. 각 단계는 앞 단계를 대체한다기보다 감싸 안으면서 사람의 개입 지점을 위로 끌어올린다.
| 시대 | 대표 형태 | 상호작용 단위 | 사람의 역할 | 병목 |
|---|---|---|---|---|
| 자동완성 | 인라인 서제스천 | 토큰·줄 | 매 줄 승인 | 문맥이 현재 파일에 한정 |
| 챗 | 대화형 어시스턴트 | 스니펫·함수 | 복붙과 통합 | 코드베이스를 모름 |
| 에이전트 | 터미널·CLI 에이전트 | 작업(task) | 목표 제시·리뷰 | 도구·권한·문맥 관리 |
| 하네스 | 스캐폴딩 + 모델 | 워크플로 | 시스템 설계 | 하네스 설계 역량 |
자동완성 시대의 단위는 토큰이었다. 챗 시대에는 스니펫으로 커졌지만, 어시스턴트가 내 코드베이스를 통째로 알지 못한다는 근본 한계가 있었다. 에이전트 시대에 들어서면서 단위는 "작업"이 되었다 — "이 버그 고쳐줘"라고 하면 에이전트가 스스로 파일을 뒤지고 실행한다. 그리고 2026년, 우리는 그다음 단계에 서 있다. 모델의 성능 차이가 좁혀지면서, 같은 모델을 쓰더라도 그것을 어떻게 감싸느냐 — 어떤 도구를 주고, 어떤 문맥을 어떻게 넣고, 어디서 사람을 끼우느냐 — 가 결과를 가른다.
왜 하네스가 2026년의 결정적 지렛대인가
"하네스"는 모델 주위를 둘러싼 모든 스캐폴딩을 가리킨다. 시스템 프롬프트와 규칙 파일, 코드베이스를 탐색하는 도구, 외부 시스템을 연결하는 MCP 서버, 반복 작업을 캡슐화한 스킬, 특정 시점에 개입하는 훅, 그리고 큰 문제를 쪼개 병렬로 처리하는 서브에이전트까지 모두 포함된다.
왜 이것이 모델 자체보다 중요해졌을까.
- 모델은 상향 평준화되었다. 프론티어 모델들의 코딩 능력 격차가 좁아졌다. 순수 추론력만으로 승부가 나지 않는다.
- 실패의 대부분은 문맥에서 온다. 에이전트가 틀리는 이유는 대체로 "몰라서"다 — 관련 파일을 못 찾았거나, 규칙을 안 봤거나, 잘못된 가정을 했거나. 이건 더 똑똑한 모델이 아니라 더 나은 문맥 공급으로 푼다.
- 레버리지는 반복에서 나온다. 잘 설계한 스킬 하나, 잘 짜인 서브에이전트 구성 하나가 팀 전체의 생산성을 곱한다. 이건 순전히 하네스 설계의 산물이다.
바꿔 말하면, 2026년에 "AI 코딩을 잘한다"는 것은 프롬프트를 잘 쓴다는 뜻이 아니라 에이전트가 성공할 수밖에 없는 환경을 설계한다는 뜻이다. 이 관점의 전환이 이 시리즈 전체를 관통하는 주제다.
Claude Code vs Codex — 한눈에 보기
2026년 초 기준으로 시장의 양대 축은 Anthropic의 Claude Code와 OpenAI의 Codex다. 둘 다 터미널 우선 에이전트에서 출발해 클라우드·IDE로 확장하는 궤적을 그리지만, 강조점이 다르다.
| 항목 | Claude Code | Codex |
|---|---|---|
| 출발점 | 터미널 CLI 에이전트 | 터미널 CLI 에이전트 |
| 확장성의 핵심 | 서브에이전트·스킬·MCP·훅 | CLI ↔ 클라우드 태스크 위임 |
| 확장 철학 | 조합 가능한 스캐폴딩 | 로컬-클라우드 연속성 |
| 규칙 파일 | CLAUDE.md | AGENTS.md |
| 강점 | 세밀한 하네스 커스터마이즈 | 대규모 병렬·비동기 작업 |
| 잘 맞는 사람 | 워크플로를 직접 설계하는 팀 | 작업을 던져두고 결과를 받는 흐름 |
표는 어디까지나 2026년 초 시점의 스냅숏이다. 두 도구 모두 몇 주 단위로 기능이 바뀌므로, 세부 스펙은 각 공식 문서로 확인하는 편이 안전하다. 큰 그림에서 기억할 것은 하나다 — 둘 다 "모델 + 하네스" 조합이고, 실제 체감은 당신이 그 하네스를 얼마나 잘 다루느냐에 달려 있다.
이 시리즈의 네 편, 한 문단씩
하네스 엔지니어링. 모델을 넘어 스캐폴딩을 설계한다는 것이 구체적으로 무엇인지 다룬다. 규칙 파일, 도구, 문맥 관리, 개입 지점을 하나의 시스템으로 엮는 사고방식을 정리한다. 나머지 세 편을 읽기 전 개념적 토대가 되는 글이다.
Claude Code 동향. 서브에이전트, 스킬, MCP, 훅이라는 네 축으로 Claude Code의 확장 모델을 뜯어본다. 각 축이 무엇을 해결하고 어떻게 조합되는지, 그리고 이 조합 가능성이 왜 하네스 설계의 좋은 예시인지 살핀다.
OpenAI Codex 동향. CLI 에이전트에서 시작해 클라우드로 작업을 위임하는 흐름까지, Codex의 진화를 따라간다. 로컬과 클라우드를 오가는 연속적 워크플로가 어떤 작업 방식을 가능하게 하는지에 초점을 맞춘다.
Claude Code $200 vs Codex $200. 실전 선택 가이드다. 월 20만원대 상위 구독을 어느 쪽에 쓸지, 어떤 작업 성향과 팀 구성에서 어느 도구가 더 값을 하는지 실용적 기준으로 비교한다. (가격은 시점에 따라 바뀌므로 구독 시점의 공식 안내를 확인하자.)
어떻게 고를까
정답은 없지만, 방향을 잡는 세 가지 질문은 있다.
- 직접 설계할 것인가, 위임할 것인가. 워크플로를 세밀하게 조립하고 싶다면 조합 가능한 스캐폴딩 쪽이, 작업을 던져두고 결과만 받고 싶다면 클라우드 위임 연속성 쪽이 손에 붙는다.
- 문맥 관리에 얼마나 투자할 수 있나. 어느 도구든 규칙 파일과 문맥 설계에 들인 시간만큼 돌려준다. 하네스에 투자할 여력이 곧 도구의 상한을 결정한다.
- 팀이냐 개인이냐. 스킬·서브에이전트 같은 재사용 자산은 팀 규모에서 레버리지가 커진다. 혼자라면 학습 곡선이 낮은 쪽부터 시작해도 좋다.
결국 도구 선택보다 중요한 것은 하네스를 다루는 역량이다. 모델은 상향 평준화되고 있고, 남는 차이는 그 위에 무엇을 얹느냐에서 나온다. 이 시리즈의 나머지 글들이 바로 그 "무엇"에 대한 이야기다.
이 시리즈의 다른 글
- AI 하네스 엔지니어링 — 모델을 넘어 스캐폴딩을 설계하기 — 왜 모델보다 스캐폴딩이 승부처인가. 시리즈의 개념적 토대.
- Claude Code 동향 — 서브에이전트·스킬·MCP·훅 — 네 개의 확장 축으로 보는 Claude Code의 조합 가능성.
- OpenAI Codex 동향 — CLI에서 클라우드 에이전트까지 — 로컬 CLI에서 클라우드 위임으로 이어지는 Codex의 진화.
- Claude Code $200 vs Codex $200 — 어느 쪽에 월 20만원을 쓸까 — 상위 구독 실전 선택 가이드.