위임형 코덱스, 협업형 클로드코드 - 실전에서 갈리는 지점

코딩 에이전트를 고를 때 이제는 어느 모델이 똑똑한지보다 어떤 방식으로 일을 맡기는지가 더 크게 갈린다. 클코단에서는 코덱스와 클로드코드가 왜 거절 빈도와 리서치 도구 궁합까지 다르게 움직이는지를 놓고 이야기가 오갔다. 두 도구의 설계 차이를 웹에서 확인된 사실과 맞춰 짚어본다.

위임형 코덱스, 협업형 클로드코드 - 설계부터 다르다

OpenAI가 코덱스에 넣은 /goal 명령은 목표만 던지면 에이전트가 스스로 계획을 세우고 실행하고 결과를 점검하는 자율 루프다. 막힐 때까지 몇 시간이고 혼자 돌아간다. 실행 환경도 다르다. 코덱스 클라우드 작업은 격리된 컨테이너에서 실행된다. 사람이 지켜보지 않아도 되는 가상의 신입 개발자에 가까운 방식이다.

클로드코드는 반대편에 서 있다. 로컬 터미널에서 실제 파일시스템에 접근해 실행된다. 계획 모드로 작업 범위를 먼저 합의한 뒤 진행하는 페어프로그래밍 구조를 택했다. 코덱스가 TOML로 에이전트를 명시적으로 정의하고 동시 실행 수를 사람이 못박는 쪽이라면, 클로드코드는 에이전트끼리 판단해서 작업을 나눠 갖는 쪽에 가깝다는 게 여러 비교 분석의 공통된 설명이다.

방에서 나온 정리도 이 구도와 겹친다. 코덱스는 골(작업지시)만 던지면 알아서 처리하는 아키텍처, 클로드는 동료처럼 함께 일하는 방향이라는 구분이다. 한 개발자 설문에서는 여러 AI 도구를 병행하는 흐름이 나타났다. 한 도구로 통일하기보다 작업 성격에 맞춰 골라 쓰는 사람이 이미 적지 않다는 뜻이다.

코덱스가 유독 자주 거절하는 이유

코덱스가 정책상 거절을 자주 한다는 방의 인상에는 근거가 있다. 코딩 에이전트 안전성을 다룬 한 벤치마크 연구에서는 o3-high를 백엔드로 쓴 코덱스 CLI의 안전 거절률이 14.1%, o4-mini 백엔드일 때는 11.2%로 측정됐다. 해당 연구에서는 사이버공격 과제에서 코덱스의 안전 거절이 관찰됐다.

이 수치는 지금 코덱스 기본 모델인 GPT-5.6 이전 세대 기준이라 최신 체감 거절률과 정확히 겹치지는 않는다.

그래도 방향성은 방에서 나온 경험과 맞아떨어진다. 애매한 요청 앞에서 코덱스가 유독 자주 멈춘다는 방의 인상은 앞선 벤치마크에서 관찰된 거절 사례와 맞닿아 있다.

스킬 맥락을 통째로 다시 읽는 비용

거절만큼 자주 나오는 불만이 맥락 관리 비용이다. 코덱스는 설치된 스킬의 메타데이터에 컨텍스트 윈도우의 2%만 예산으로 고정 배정해뒀다. 스킬을 여러 개 깔면 이 한도를 넘겨 설명이 잘려나가는 경고가 뜬다는 이슈가 코덱스 깃허브에 여러 건 올라와 있다. GPT-5.6 전환 과정에서는 기본 컨텍스트 윈도우 자체도 37만2000토큰에서 27만2000토큰으로 줄었는데, 정보월드 보도에 따르면 개발자들 사이에서 세션이 작업보다 압축(컴팩션)에 더 많은 시간을 쓴다는 불만이 나왔다.

스킬 관련 맥락이 나올 때마다 전문을 다시 읽어서 비효율적이라는 방의 지적도 이 구조와 무관하지 않다. 추가하거나 수정한 스킬을 앱에서 다시 읽히려면 재시작이 필요하다는 이슈도 코덱스 깃허브에 올라와 있어, 스킬 갱신이 매끄럽지 않다는 지적이 있다.

클로드코드도 이 문제에서 완전히 자유롭지는 않다. 서브에이전트는 부모 세션이 이미 읽어둔 파일이나 대화를 물려받지 못한다. 위임받은 작업을 처음부터 다시 탐색하는 경우가 흔하다는 지적이 나온다. 다만 이쪽은 스킬 전체를 되풀이해서 읽는 구조라기보다 서브에이전트 단위의 맥락 단절에 더 가깝다.

리서치 도구가 모델을 가려 타는 이유

방에서 쓰는 리서치 도구가 클로드에 최적화돼 있어 코덱스에 얹으면 품질이 보장되지 않는다는 이야기도 나왔다. 이 현상 자체는 딥리서치형 MCP 도구 전반에서 낯설지 않다. 이 딥리서치 명령은 여러 서브에이전트를 동시에 띄워 각자 조사하고 서로 결과를 대조한 뒤 하나의 보고서로 합치는 구조인데, 검색을 언제 끝낼지와 어떤 결과를 신뢰할지 판단하는 몫을 에이전트 자신에게 맡긴다.

이런 판단은 모델마다 도구 호출 습관과 지시 해석 방식이 다르다. 한 모델에 맞춰 짠 오케스트레이션과 프롬프트가 다른 모델로 옮겨가면 그대로 재현되지 않는 일이 흔하다. 특정 벤더 최적화 도구를 다른 모델 위에 얹었을 때 성능이 흔들리는 문제는 리서치 도구만의 이야기가 아니다. 다만 여러 단계를 스스로 판단해서 이어가야 하는 작업일수록 이 격차가 크게 드러난다.

키미·딥식 조합이 통한다는 경험, 근거는 있나

반대로 키미·딥식 최신 모델에 리서치 도구를 얹으면 검색 결과를 잘 긁어온다는 방의 경험담은 두 모델의 최근 스펙과 방향이 맞아떨어진다. 문샷AI가 4월에 낸 키미 K2.6은 1조 파라미터 MoE 모델로, 토큰당 320억 파라미터를 활성화하고 최대 300개 서브에이전트를 4000단계까지 조율하는 에이전트 스웜 구조를 갖췄다. 6월에 나온 코딩 특화 버전 K2.7 Code는 컨텍스트 윈도우를 25만6000토큰까지 늘리면서 사고 토큰 사용량은 K2.6보다 30%가량 줄였다.

딥식도 8월 13일 정식 출시한 V4-Pro에서 100만 토큰 컨텍스트 윈도우와 토큰 단위 압축·희소 어텐션 기술을 적용했다. V4-Pro의 출력 가격도 100만 토큰당 1.98~3.96달러로 클로드 오퍼스 4.8의 25달러보다 낮다. 긴 컨텍스트와 낮은 비용이 맞물리면 검색 결과를 많이 끌어와도 부담이 작다는 뜻이다. 리서치처럼 여러 차례 검색하고 종합하는 작업에서 체감 품질이 올라갈 만한 조건은 갖춰져 있는 셈이다.

2026년 코딩 에이전트 생태계에서는 도구 하나로 다 해결하기보다 여러 모델을 조합해 쓰는 흐름이 나타난다. 개인 개발자나 소규모 팀 입장에서는 코덱스 플러스 20달러와 클로드 프로 20달러를 합쳐 쓰는 조합이 클로드 맥스 100달러 하나보다 낫다는 계산도 커뮤니티에서 돈다.

클로드에는 리서치 도구를 얹고 키미·딥식에는 검색 위주 작업을 맡기는 방의 역할 분담은 이런 흐름과 같은 방향을 가리킨다. 다음 관전 포인트는 코덱스가 스킬 재로딩과 컨텍스트 예산 문제를 얼마나 고치느냐다. 그 격차가 좁혀지지 않는 한, 위임이냐 협업이냐는 선택은 당분간 어떤 작업에 어떤 도구를 붙이느냐는 조합 문제로 남을 것이다.