코딩 에이전트를 작업자(Worker)와 조언자(Advisor)로 분리한 후, Codex vs Claude 논쟁은 더 이상 의미가 없어졌다

나는 코딩 에이전트(coding-agent) 모델 논쟁이 마치 칼싸움과 같다고 생각하곤 했다.

모델 하나를 선택한다. 헌신한다. 그리고 제대로 된 것을 골랐기를 바란다.

많은 사람들이 여전히 codex vs claude를 그런 방식으로 정의한다. 하나의 세션, 하나의 모델, 하나의 가격대.

OpenClaw 토론과 ClawCodex 문서를 살펴본 후, 나는 그러한 프레임워크가 구식이라고 생각하게 되었다.

더 유용한 질문은 다음과 같다:

어떤 모델이 작업의 어느 부분을 수행해야 하는가?

코딩 에이전트를 그런 방식으로 생각하기 시작하자, 아키텍처(architecture)가 훨씬 단순해졌다:

저렴한 작업자(worker) 모델이 반복적인 저장소(repo) 작업을 수행하게 한다.
위험한 분기점(forks)에서만 더 강력한 조언자(advisor) 모델을 호출한다.
라우팅(routing)을 인간의 기억이 아닌 인프라(infrastructure)에 맡긴다.

지나고 보니 당연한 소리처럼 들린다. 또한 훨씬 저렴하게 들리기도 한다.

ClawCodex는 이 패턴이 Claude Opus를 전체 세션 동안 실행하는 것보다 약 6배 더 저렴할 수 있다고 주장한다. 정확한 수치가 6배인지, 3배인지, 혹은 10배인지는 제공업체의 가격 책정과 라우팅에 따라 달라진다. 핵심은 동일하다: 대부분의 코딩 에이전트 토큰(tokens)은 고도의 추론(reasoning)이 아닌 지루한 작업에 소비된다는 점이다.

에이전트 세션의 대부분은 그저 값비싼 삽질 작업일 뿐이다

전형적인 코딩 루프(coding loop)는 화려하지 않다.

보통 다음과 같다:

파일 읽기
코드 검사
코드 패치(patch)
테스트 실행
스택 트레이스(stack trace) 읽기
다시 패치
테스트 재실행
버그가 항복하거나 당신이 항복할 때까지 반복

이것은 내가 프리미엄 모델에 돈을 쓰고 싶은 영역이 아니다.

그곳은 작업자 모델(worker-model)의 영역이다.

ClawCodex는 /advisor 모드를 통해 이를 명시적으로 보여준다:

/advisor anthropic:claude-opus-4-7

아이디어는 간단하다:

저렴한 모델이 실행 루프(execution loop)를 처리한다.
판단이 중요할 때만 더 강력한 모델에게 자문을 구한다.

이는 당신의 에이전트가 20분 동안 파일을 열고 pytest를 재실행하는 것을 지켜보기 위해 Claude Opus 비용을 지불하는 것보다 훨씬 나은 분리 방식이다.

이 분리가 실무에서 타당한 이유

작업자(worker)는 다음을 수행해야 한다:

파일 읽기
코드 수정
테스트 루프
명령 실행
grep/검색
점진적 수정(incremental fixes)

조언자(advisor)는 다음을 수행해야 한다:

아키텍처 결정 (architecture decisions)
마이그레이션 안전성 점검 (migration safety checks)
근본 원인 검토 (root-cause review)
최종 코드 리뷰 (final code review)
“우리가 올바른 문제를 해결하고 있는가?”에 대한 점검

이러한 분리는 시니어 엔지니어들이 실제로 일하는 방식과 일치합니다.

팀에서 가장 비용이 많이 드는 인원에게 테스트 출력 결과를 계속 새로고침하며 앉아 있으라고 요구하지 않습니다. 대신 구현이 잘못된 방향으로 흐르려 할 때 개입해 달라고 요청합니다.

가격 차이는 무시할 수 없을 만큼 큽니다

ClawCodex의 문서는 예시 가격을 다음과 같이 나열합니다:

모델	현재 가장 적합한 역할
Claude Haiku 4.5	파일 읽기, 편집 및 테스트 루프를 위한 저비용 작업자(worker); ClawCodex 기준 1M 토큰당 입력 $1 / 출력 $5
...

라우팅(routing)이 완벽하지 않더라도, 그 격차가 충분히 크기 때문에 역할 기반의 모델 선택을 통해 실제로 상당한 비용을 절감할 수 있습니다.

만약 CI(지속적 통합), 내부 도구 또는 자동화 환경에서 하루 종일 에이전트를 실행하고 있다면, 이러한 절감 효과는 매우 빠르게 이론을 넘어 실질적인 이득이 됩니다.

중요한 변화: 작업자(worker)가 반드시 Claude일 필요는 없다

이 부분은 더 많은 팀이 진지하게 받아들여야 한다고 생각합니다.

작업자(worker)와 조언자(advisor)를 분리하고 나면, 작업자가 반드시 동일한 제공업체(provider)의 모델일 필요는 없습니다.

세션은 다음과 같은 모습이 될 수 있습니다:

worker: deepseek/deepseek-v4-pro
advisor: anthropic:claude-opus-4-7

이것은 단순히 Anthropic을 이용한 트릭이 아닙니다. 이것은 라우팅 패턴(routing pattern)입니다.

라우팅 패턴을 갖추게 되면, 모델 선택을 종교적 신념처럼 다루는 대신 비용, 지연 시간(latency) 또는 신뢰성에 따라 제공업체를 교체할 수 있습니다.

조언자(advisor)는 짧고 명확해야 합니다

이 부분은 사람들이 생각하는 것보다 더 중요합니다.

잘못된 조언자 설정은 두 모델이 너무 많은 대화를 나누는 상황으로 변질됩니다.

이는 비용이 많이 들 뿐만 아니라 컨텍스트(context)를 오염시킵니다.

조언자는 매 턴마다 작업자의 전체 계획을 다시 진술해서는 안 됩니다. 대신 빠른 리뷰를 수행하는 스태프 엔지니어(staff engineer)처럼 행동해야 합니다:

이 마이그레이션 경로는 안전하지 않음
근본 원인이 아닌 증상만을 수정하고 있음
지금 리팩터링(refactoring)하는 대신 패치(patch)를 격리할 것
이 테스트가 통과되었다고 해서 버그가 수정되었다는 증거는 아님

그것이 바로 프리미엄 모델(premium model)을 사용하는 고가치 활용법입니다.

만약 당신의 조언자(advisor)가 단순히 긴 요약본을 작성하는 두 번째 인턴 수준에 불과하다면, 당신은 아주 적은 이득을 위해 토큰(tokens)을 낭비하고 있는 것입니다.

내가 실제로 구축할 방식

만약 내가 오늘날 팀을 위한 코딩 에이전트(coding agents)를 설정한다면, 다음과 같은 패턴을 사용할 것입니다:

1. 실행 루프(execution loop)를 위한 작업자(Worker) 모델

저장소 탐색(repo exploration), 편집(edits), 명령(commands), 그리고 테스트(tests)에는 더 저렴한 모델을 사용하십시오.

2. 위험한 결정을 위한 조언자(Advisor) 모델

다음과 같은 경우에만 비용이 많이 드는 모델을 호출하십시오:

에이전트가 아키텍처(architecture)를 변경하려 할 때
수정 사항이 마이그레이션(migrations)이나 데이터 무결성(data integrity)에 영향을 미칠 때
실패 모드(failure mode)가 기이할 때
작업자(worker)가 계속해서 같은 동작을 반복할 때
머지(merge) 전 최종 검토(final review)를 원할 때

3. 라우팅(routing) 및 페일오버(failover)를 위한 게이트웨이(Gateway)

모델 라우팅을 인프라스트럭처(infrastructure)에 배치하십시오.

이는 OpenClaw나 LiteLLM 같은 도구를 사용하여 다음과 같은 사항을 결정하는 계층으로 사용하는 것을 의미합니다:

어떤 제공자(provider)가 요청을 받을 것인가
어떤 모델이 작업자(worker)인가
어떤 모델이 조언자(advisor)인가
재시도(retry) 또는 폴백(fallback) 시 어떤 일이 발생하는가

이는 모든 개발자에게 세션 도중에 수동으로 모델을 전환하도록 요청하는 것보다 훨씬 더 나은 방식입니다.

예시: 클라이언트를 단순하게 유지하기

이 패턴이 실용적인 이유 중 하나는 전체 스택(stack)을 다시 작성할 필요가 없기 때문입니다.

만약 당신의 툴링(tooling)이 이미 OpenAI API 형태를 지원한다면, 게이트웨이가 하단의 대부분의 복잡성을 숨겨줄 수 있습니다.

많은 팀이 놓치는 부분이 바로 이 지점입니다.

기존의 SDK 흐름을 유지하면서 라우팅 계층에서 경제성(economics)을 변경할 수 있습니다.

예를 들어, 앱 코드는 다음과 같이 평범하게 유지될 수 있습니다:

import OpenAI from "openai";

const client = new OpenAI({
...

그러면 게이트웨이가 오늘날 coding-agent-worker가 실제로 무엇을 의미하는지 결정할 수 있습니다.

정상적인 루프에서는 저렴한 모델로 라우팅하고, 정책상 필요하다고 판단될 때만 더 강력한 조언자(advisor)로 에스컬레이션(escalates)할 수 있습니다.

이것이 바로 OpenAI 호환 인프라스트럭처(OpenAI-compatible infrastructure)가 중요한 이유입니다.

이것은 Standard Compute가 매우 잘 들어맞는 지점이기도 합니다

만약 당신이 작업자/조언자(worker/advisor) 패턴을 실험하고 있다면, 토큰당 과금(per-token billing) 방식은 금방 번거로워질 것입니다.

어떤 아키텍처(Architecture)가 효과적인지 배우기도 전에 모든 호출(Call)을 최적화하기 시작하게 됩니다.

그것이 제가 에이전트 팀에게 정액제 인프라(Flat-rate infrastructure)가 과소평가되어 있다고 생각하는 이유 중 하나입니다.

Standard Compute를 사용하면 이미 사용 중인 OpenAI 호환 클라이언트(OpenAI-compatible client)를 그대로 유지하면서도, 추가적인 테스트 루프(Test loop) 하나하나를 과금 이벤트로 취급하지 않을 수 있습니다. 이를 통해 다음과 같은 환경에서 지속적으로 실행되는 에이전트를 구축하기가 훨씬 쉬워집니다:

n8n
Make
Zapier
OpenClaw
커스텀 내부 에이전트 프레임워크 (custom internal agent frameworks)

실질적인 이점은 명확합니다. 누군가가 토큰 소비량을 매의 눈으로 감시하지 않아도, 공격적으로 라우팅(Routing)하고, 필요할 때 재시도(Retry)하며, 에이전트가 실제 작업을 수행하도록 내버려 둘 수 있습니다.

특히 작업자/조언자(Worker/advisor) 설정의 경우, 이는 매우 중요합니다.

이 아키텍처의 핵심은 저렴한 작업자(Worker)가 리스크가 낮은 수많은 반복 작업(Iteration)을 자유롭게 수행할 수 있어야 한다는 것이기 때문입니다. 만약 팀이 여전히 토큰 하나하나에 스트레스를 받고 있다면, 루프(Loop)를 충분히 활용하지 못하고 모든 호출을 과도하게 고민하게 될 것입니다.

월정액 요금제(Flat monthly pricing)는 인간의 채팅보다 에이전트에게 훨씬 더 적합합니다.

라우팅 설정 예시 (Example routing config)

제가 백엔드에서 구현하고 싶은 설정 방식은 다음과 같습니다:

models:
  coding-agent-worker:
    provider: standardcompute
...

정확한 구문(Syntax)은 게이트웨이(Gateway)에 따라 다르겠지만, 핵심은 아키텍처에 있습니다.

애플리케이션은 역할을 요청해야 합니다.

인프라는 모델을 결정해야 합니다.

주의할 점 (The catches are real)

이 패턴은 훌륭하지만, 마법은 아닙니다.

라우팅 오버헤드 (Routing overhead)가 존재함

조언자(Advisor)가 너무 자주 호출되면 지연 시간(Latency)이 쌓이게 됩니다.

작업자-조언자 시스템은 조언자가 절제되어 사용될 때만 작동합니다.

만약 몇 분마다 조언자에게 에스컬레이션(Escalate)을 한다면, 당신은 깔끔한 아키텍처를 만든 것이 아니라 위원회(Committee)를 만든 것입니다.

비용 대시보드가 오해를 불러일으킬 수 있음

표시되는 가격은 실제 제공업체 경로가 아닌, 종종 정가(List prices)를 기준으로 합니다.

게이트웨이, 애그리게이터(Aggregators) 또는 클라우드 제공업체를 통해 라우팅하는 경우, 실제 청구 금액은 다를 수 있습니다.

따라서 단순히 보기 좋은 상태 출력값(Status output)이 아니라 실제 지출액을 측정하십시오.

저렴한 작업자도 여전히 틀릴 수 있음

작은 잘못된 수정을 자신 있게 수행하는 저비용 모델은, 만약 수 시간을 낭비하게 만든다면 결코 저렴한 것이 아닙니다.

따라서 여전히 평가(Evals), 가드레일(Guardrails), 그리고 합리적인 에스컬레이션(Escalation) 규칙이 필요합니다.

이것은 아키텍처 결정(Architecture decision)의 문제이지, 공짜 점심이 아닙니다.

이 패턴은 "최고의 모델 하나를 선택하라"는 방식보다 더 성숙하게 느껴집니다

작업자(Worker)/조언자(Advisor) 분리 방식에서 제가 좋아하는 점은 이 방식이 정직하게 느껴진다는 것입니다.

이 방식은 다음 두 가지를 인정합니다:

모든 토큰(Token)에 프리미엄 추론(Reasoning)이 필요한 것은 아니다
어떤 결정에는 반드시 프리미엄 추론이 필요하다

이는 마치 하나의 모델이 코딩 세션 전체를 독점해야 하는 것처럼 Codex vs Claude를 두고 영원히 논쟁하는 것보다 더 나은 멘탈 모델(Mental model)입니다.

저는 미래가 단 하나의 완벽한 코딩 모델로 이루어질 것이라고 생각하지 않습니다.

제가 생각하는 미래는 다음과 같습니다:

저렴한 실행 (Cheap execution)
값비싼 판단 (Expensive judgment)
인프라에 의해 처리되는 라우팅 (Routing)
그 위에 구축된 OpenAI 호환 클라이언트 (OpenAI-compatible clients)
밑바탕이 되는 예측 가능한 비용 (Predictable cost)

에이전트가 데모(Demo) 단계를 넘어 프로덕션(Production)으로 이동함에 따라, 마지막 부분이 더욱 중요해집니다.

왜냐하면 일단 당신의 코딩 에이전트가 하루 종일 작동하기 시작하면, 진짜 적은 단순히 잘못된 출력값(Bad output)만이 아니기 때문입니다.

그것은 잘못된 출력값 여기에 예측 불가능한 비용이 더해진 것입니다.

그렇기에 이제 더 나은 질문은 다음과 같아야 한다고 생각합니다:

Codex인가 Claude인가? 가 아니라,

어떤 모델이 나의 작업자(Worker)이고, 어떤 모델이 나의 조언자(Advisor)이며, 에이전트가 실행될 때마다 토큰 계산(Token math)을 신경 쓰지 않아도 되도록 나의 인프라가 설정되어 있는가? 입니다.

만약 당신이 OpenClaw, LiteLLM, 또는 자체적인 OpenAI 호환 스택(OpenAI-compatible stack)을 사용하여 코딩 에이전트를 구축하고 있다면, 이것이 바로 답을 찾을 가치가 있는 질문입니다.