당신이 아마 사용하지 않을 코딩 에이전트 설정: 코드를 전혀 작성하지 않는 하나의 비싼 모델

대부분의 사람들은 코딩 에이전트를 같은 방식으로 사용합니다. 즉, 하나의 모델을 사용하고, 하나의 채팅 세션을 열어놓고 그것이 타이핑하는 것을 지켜보는 식입니다. 만약 그 모델이 좋다면 비용이 많이 들고, 저렴하다면 결국 직접 감시해야 합니다.

저는 그런 방식을 멈췄습니다. 현재 저는 여러 프로젝트를 동시에 진행하고 있는데, 이 설정에서 가장 비싼 모델은 코드를 단 한 줄도 작성하지 않습니다.

아마 이것이 여러분에게는 새로운 방식일 수 있습니다. 아니면 이미 1년 동안 그렇게 해왔을 수도 있습니다. 만약 그렇다면, 어떻게 다르게 하고 있는지 듣고 싶습니다 (끝 부분 참고).

세 가지 역할, 각자 맡은 임무

전략가(Strategist). 프로젝트당 하나의 Claude Code 세션을 높은 추론 노력으로 사용합니다. 5분마다 (/loop 5m) 오케스트레이터가 무엇을 하고 있는지 확인합니다: 무엇을 선택했는지, 무엇을 배포했는지, 무엇이 막혔는지 등을 파악합니다. 전략가는 코드를 작성하지 않습니다. 작업이 올바른 방향으로 진행되고 있는지 여부를 결정할 뿐입니다.

오케스트레이터(Orchestrator) (Orchestro Minimal). 백로그를 관리하고, 다음 항목을 선택하며, 실행자에게 전달하고, 발생한 일을 기록합니다.

실행자(Executor) (Muse). 저렴한 구독 기반의 코딩 에이전트입니다. 실제 작업을 수행합니다: 브랜치 생성 → 변경 사항 적용 → 테스트 → PR 제출 → 검증이 녹색 신호일 경우에만 병합 → 변경 사항이 라이브 상태인지 확인.

   전략가 (프로젝트)          전략가 (프레임워크)
   Claude, 5분마다           오케스트레이터를 유지 관리
        │   프레임워크 문제 ──────────▲
...

작동하게 만드는 규칙: 두 가지 종류의 문제

전략가가 무언가 잘못된 것을 발견했을 때, 첫 번째 질문은 '이것은 누구의 문제인가?'입니다.

• 프로젝트 문제 (버그, 우선순위 오류, 백로그 누락 항목): 전략가는 백로그를 직접 수정합니다. 실행자가 다음 라운드에서 이를 처리합니다.
• 프레임워크 문제 (오케스트레이터가 잘못된 항목을 선택하거나, 막히거나, 작업을 완료하지 못하는 경우): 전략가는 임시방편으로 해결하려 하지 않습니다. 오직 오케스트레이터를 유지 관리하는 것이 유일한 임무인 다른 세션에 이를 보고합니다. 그 세션이 핵심 문제를 수정하고 모든 프로젝트에 새로운 버전을 배포합니다.

실제 사례를 하나 소개합니다. 10월 14일자 내용입니다. 제 블로그의 콘텐츠 파이프라인을 지켜보던 Strategist가, 우리가 더 가벼운 orchestrator로 전환한 이후 하루 동안 아무것도 검증되지 않았다는 것을 알아차렸습니다. 작업은 배포되었지만(shipping), orchestrator는 '배송됨(delivered)'만 기록할 뿐 '검증됨(verified)'을 기록하지 않아 verifier가 이를 볼 수 없었습니다. 이것은 블로그의 문제가 아니라 프레임워크의 문제입니다. 로컬 임시방편으로 처리된 것이 아니라, 프레임워크 세션으로 넘어갔어야 했습니다.

모든 프로젝트는 결국 프레임워크를 테스트하게 되고, 프레임워크에 대한 모든 수정은 모든 프로젝트에 도움이 됩니다. 저는 orchestrator의 개선 사항을 미리 계획하지 않습니다. 실제 프로젝트들이 그것들을 찾아냅니다.

모델 혼합 사용 이유: 비용과 복구력

orchestrator는 어떤 모델이 실행하든 신경 쓰지 않습니다. 프로젝트가 자체 실행기(Claude, Codex, Grok 또는 Muse 지원)를 선언합니다. 이는 저에게 두 가지 이점을 제공합니다:

• 비용. 생각하는 것은 비싸고, 타이핑은 저렴합니다. 비용이 많이 드는 모델은 5분마다 상태(state)를 읽어오고, 저렴한 모델이 긴 실행을 담당합니다. 모두 CLI 구독 형태로 작동하며, 토큰당 지불 방식의 API 호출이 아니므로, 새로운 수정 사항에 추가 비용이 들지 않습니다. 제 전체 비용은 단순히 [X €/월 구독료] ÷ 월별 검증 완료 횟수입니다.
• 복구력. 한 제공업체의 할당량(quota)이 소진되어도 작업이 중단되지 않습니다 (이번 주에는 Codex였습니다). 해당 항목은 증거와 함께 백로그에 남아 있고, 다른 실행기가 이를 가져가 처리할 수 있습니다.

현재까지의 수치, 좋지 않은 데이터 포함

• 블로그 콘텐츠 파이프라인 (10월 3일~10월 14일): 독립 검증기(independent verifier)는 총 95개의 판결을 내렸습니다. 87개 통과, 7개 실패, 1개 결론 보류.
• orchestrator 자체 저장소 (동일 기간): 63번의 병합(merges) 및 0건 독립 검증 통과 (8개 실패, 13개 결론 보류).
• 10월 13일에 더 가벼운 orchestrator로 전환한 후: Strategist가 문제를 발견하기 전까지 첫날 블로그에는 검증 기록이 0건이었습니다 (위의 버그).

제가 계속 배우는 교훈은 이것입니다. _병합됨(merged)_과 _검증됨(verified)_은 다릅니다. 병합된 것만 계산하는 설정은 보기 좋게 꾸며져 있지만, 사실과는 다를 수 있습니다.

여전히 작동하지 않는 부분

Executors는 실제로 작업을 수행하지 않았는데도 '완료'라고 말합니다. 그래서 Strategist는 메시지가 아닌 상태(state)를 읽습니다.

• Strategist가 5분마다 확인하는 것은 대부분 조용한 시스템을 확인하는 것입니다. [검증된 수정당 체크 횟수, 측정 결과.]
• 동일한 장치에서 두 개의 무거운 빌드가 서로 충돌합니다. 오늘날 공유 잠금(shared lock)이 이를 직렬화하고 있는데, 이는 디자인이라기보다는 임시방편입니다.

저는 이것이 완전히 새로운 것은 아니라는 것을 압니다

Planner/executor 분리, 슈퍼바이저 에이전트(supervisor agents), 모델 캐스케이드(model cascades)는 존재합니다. 제가 다른 곳에서 보지 못한 것은 이 조합입니다: 고정된 주기의 저렴한 슈퍼바이저가 문제를 owner (프로젝트 vs. 프레임워크)에 의해 라우팅하고, 실제 프로젝트의 문제로 인해 오케스트레이터(orchestrator)를 개선하는 별도의 세션입니다.

만약 여러분이 이미 이런 방식으로 작업하거나, 다른 방법으로 같은 문제를 해결했다면, 저에게 알려주세요. 특히 다음 사항들에 대해요:

• 여러분의 슈퍼바이저는 얼마나 자주 확인하며, 실제로 무엇을 살펴봅니까?
• 프로젝트 문제와 도구(tooling) 문제가 무엇인지 어떻게 결정합니까?
• 머지(merge)당 비용이 아니라, 검증된 변경 1회당 실제 비용은 얼마입니까?

최고의 답변들로 이 게시물을 업데이트하겠습니다.

오케스트레이터는 Orchestro입니다. 매우 작은 비공개 베타 버전이며, 주로 제 자신의 프로젝트에서 사용됩니다. 여러분도 사용해보고 싶다면: orchestro.org.