Muse Wonder vs Claude Opus 5.5: 장기 작업은 어떤 에이전트에게 맡겨야 할까?

Muse Wonder와 Claude Opus 5.5의 가격은 입력 토큰 100만 개당 4달러, 출력 토큰 100만 개당 20달러로 동일합니다. 따라서 Crew 차원에서 둘 중 하나를 선택하는 문제는 예산의 문제가 아니라 라우팅 규칙의 문제입니다. Meta의 모델 카드에 따르면 장기 코딩 작업을 측정하는 벤치마크(SWE-Marathon, 53.1 대 46.3)에서는 Wonder가 앞서고, 터미널 작업(59.6 대 52.0), 일반 지능(독립 인덱스 기준 58 대 52), 지식(46 대 25)에서는 Opus가 앞섭니다. 이 네 가지 수치는 서로 다른 두 Agent의 특성을 명확히 보여주며, 이 기준에 맞춰 작업을 라우팅하는 보드가 기본 모델 하나만 고집하는 보드보다 두 모델 모두를 훨씬 더 잘 활용할 수 있습니다.

이 글에서는 이 수치들을 구체적인 작업 배정 기준으로 전환해 봅니다. 어떤 Task를 Muse Wonder Agent에 맡기고 어떤 Task를 Opus 5.5에 남겨두어야 하는지, 각 모델이 코드 리뷰 대기열에 어떤 영향을 미치는지, 그리고 일주일 후 이 규칙이 잘 작동하는지 어떻게 판단할 수 있는지 살펴봅니다. Meta 레인 설정 방법은 Sharkly에서 Muse Wonder 에이전트를 실행하는 방법에서 확인할 수 있습니다.

라우팅에 중요한 핵심 지표

이 표는 두 모델의 프로필로 읽을 수 있습니다. Wonder는 끈기 있고 출력이 간결하여 작업당 비용이 저렴하지만 기억력(지식 회상)이 약하며, 비디오와 오디오 입력을 지원합니다. 반면 Opus는 종합적인 지능이 더 뛰어나고 셸 환경에 강하며 아는 것이 많지만 작업당 비용이 더 듭니다. 어느 한쪽이 일방적으로 우월한 것이 아니라, 적합한 Task가 서로 다를 뿐입니다.

Muse Wonder Agent에 적합한 Task

공통점은 장애물이 많은 장기 작업이라는 점입니다. Meta는 다양한 대안을 시도하고 난관을 헤쳐 나가는 이른바 ‘액티브 포커스(Active Focus)’를 발휘하도록 이 모델을 훈련시켰으며, SWE-Marathon은 바로 이를 측정하기 위해 고안된 벤치마크입니다.

• 테스트 통과 상태(그린)를 유지해야 하는 다중 파일 리팩터링. 단계가 많고 각 단계를 검증할 수 있으며, 실패 시 두 번째, 세 번째 대안적 접근이 필요한 작업입니다.
• 의존성 및 프레임워크 마이그레이션. 업그레이드, 오류 발생, 수정, 반복으로 이어지는 전형적인 장기 작업으로, 11번째 단계에서도 포기하지 않는 모델의 끈기가 요구됩니다.
• 불안정한(flaky) 테스트 스위트에 대한 수정 및 검증 루프. 자신이 만든 버그와 테스트 스위트 자체의 문제를 구분해야 하는 작업입니다.
• 비디오 또는 오디오 입력이 필요한 Task. 버그 화면 녹화 영상이나 요구사항이 담긴 통화 녹음 파일 등은 Opus 5.5에서 처리할 수 없습니다.

실행 과정에서 스스로 검증할 수 있도록 완료 조건(인수 기준)을 명확히 작성하세요. Wonder는 Task에 “packages/api의 모든 테스트를 통과하고 변경 로그에 항목을 추가할 것”과 같이 명시되어 있을 때 최고의 역량을 발휘하며, ‘완료’의 의미를 스스로 정의해야 할 때 가장 취약합니다.

Opus 5.5에 맡겨야 하는 Task

• 터미널 비중이 높은 작업. 인프라 스크립트, 배포 파이프라인 등 에이전트가 셸 환경에서 주로 작업해야 하는 모든 영역입니다. Terminal-Bench에서 7.5점 차이는 결코 작지 않은 격차입니다.
• 배경지식이 중요한 모든 작업. Omniscience 점수가 46점 대 25점이라는 것은 Wonder가 사실 정보를 놓칠 확률이 두 배나 높다는 뜻입니다. 접해보지 않은 라이브러리 API, 난해한 에러 코드, 전문 도메인 지식에 대해 Wonder가 문서를 검색하거나 추측해야 하는 반면, Opus는 기억을 바탕으로 바로 답변할 수 있습니다.
• 리뷰어 역할. 다른 Agent의 diff를 읽고 올바른지 판단하는 Agent는 보유한 모델 중 가장 지능이 뛰어난 모델이어야 합니다. 종합 지수 기준으로 그 자리에 맞는 모델은 Opus이며, 혼합 모델 Crew 패턴에서도 이미 고비용 모델을 해당 역할에 배치하고 있습니다.
• 짧고 명확한 단기 Task. DeepSWE에서는 두 모델의 점수가 비슷하지만, 일반 지능에서는 Opus가 앞섭니다. 10분 내로 끝나는 작업이라면 Wonder의 끈기라는 장점이 발휘될 기회조차 없습니다.

각 모델이 리뷰 대기열에 미치는 영향

라우팅 방식은 리뷰어 앞에 놓이는 작업물의 성격을 바꾸며, 이것이 바로 실질적인 비용으로 이어집니다.

Wonder가 장기 Task를 수행하면 더 많은 시도, 더 많은 롤백, 더 많은 커밋 등 더 긴 실행 경로가 생성됩니다. 이는 모델이 제 역할을 다하고 있음을 의미하지만, 동시에 diff만으로는 전체 맥락을 파악할 수 없다는 뜻이기도 합니다. 리뷰어에게는 실행 로그가 필요하며, 따라서 Agent 지침에 시도한 내용을 지속적으로 기록하도록 명시해야 합니다. ‘사람의 리뷰가 병목이다’라는 원칙이 더욱 강력하게 적용됩니다. 끈기 있는 모델일수록 Task당 검토해야 할 분량이 줄어드는 것이 아니라 오히려 늘어나기 때문입니다.

Wonder의 지식 부족은 잘못된 세부 정보를 확신을 갖고 제시하는 형태로 나타납니다. 존재하지 않는 플래그를 사용하거나 두 버전 전에 이름이 바뀐 메서드를 호출하는 식입니다. 동급 모델 대비 환각률은 낮은 편이지만(Artificial Analysis 측정 기준 27%), 27%가 0%는 아닙니다. 따라서 확실하지 않은 내용은 리포지토리에서 직접 확인하고, 확인하지 못한 경우 이를 명시하도록 Agent에 지시해야 하며, 리뷰어는 바로 그 부분을 중점적으로 교차 검증해야 합니다.

동일한 Task에서 Opus는 더 짧고 명확한 경로를 생성하는 경향이 있으며, 작업당 비용은 더 높게 나옵니다. 대신 실행당 리뷰 부담은 적습니다. 그러나 장애물이 많은 장기 Task의 경우 Opus는 도중에 멈춰 설 가능성이 높아 다른 형태의 부담을 대기열에 넘겨줍니다. 바로 절반만 완료되어 범위 재조정이 필요한 Task입니다.

세 가지 실제 Task 라우팅 예시

구체적인 예시를 보면 작업 배정 시 규칙을 훨씬 쉽게 적용할 수 있습니다.

“전체 서비스에 걸쳐 ORM을 v5에서 v7으로 업그레이드하고 모든 통합 테스트를 통과시킬 것.” Wonder를 추천합니다. 수십 개의 단계, 각 단계마다 새로운 방식으로 실패하는 테스트 스위트, 명확한 완료 기준이 있기 때문입니다. 모델의 끈기가 큰 자산이 되며, 실행 중에 인수 조건을 자체적으로 검증할 수 있습니다.

“새로운 스테이징 환경을 위한 Terraform 코드를 작성하고 적용(apply)할 것.” Opus를 추천합니다. 셸 작업 비중이 높고 인프라 특화 지식이 필요하며, 실행 결과에 따른 영향력이 큰 작업입니다. Terminal-Bench 결과로 보아 Opus가 적합하며, 영향 범위(blast radius)를 고려할 때 어떤 모델을 쓰든 apply 전에 멈춰 서서 사용자에게 확인을 요청해야 합니다.

“결제 웹훅이 이중으로 발생하는 원인을 설명하고 해결책을 제시할 것.” 설명 단계에서는 결제 서비스 제공업체의 재시도 메커니즘을 정확히 파악해야 하는 기억(지식 회상) 작업이므로 Opus가 적합합니다. 제안된 해결책이 테스트를 수반하는 다중 파일 수정 작업으로 이어진다면, 그 후속 Task는 Wonder에 넘길 수 있습니다.

패턴은 명확합니다. 명확한 종착점이 정의된 Task에는 Wonder를, 사전 지식이 핵심인 Task에는 Opus를 배정하는 것입니다. 두 가지 성격이 모두 필요하다면 Task를 분할하세요. Sharkly는 레인당 에이전트 하나씩 작업을 분할하고, 사람의 기억에 의존하는 대신 보드에 인수인계 내역을 명확히 기록할 수 있도록 설계되었습니다.

두 모델을 함께 운영하고 결과 분석하기

일주일 동안 보드에 이 규칙을 적용해 보고 실제 Task 결과를 통해 검증해 보세요.

1. Muse Wonder Agent를 새로 생성하고 기존 Opus 5.5 Agent도 유지합니다. Sharkly는 모델 ID를 별도로 표시하지 않으므로, 두 Agent 모두 보고서 상단에 모델 ID를 명시하도록 지침을 설정합니다.
2. 개인적 선호가 아니라 위의 규칙에 따라 작업을 배정합니다. 장애물이 많은 장기 작업은 Wonder에, 터미널 및 지식 중심 작업은 Opus에, 리뷰는 Opus에 맡깁니다.
3. 일주일 후 각 Agent가 완료한 Task를 취합하여 세 가지를 확인합니다. 결과 대신 질문을 되가져온 횟수, 재실행이 필요했던 횟수, 각 Agent가 유발한 리뷰 코멘트 수입니다.

Wonder가 처리한 장기 작업이 더 적은 재실행으로 끝나고, Opus의 터미널 작업이 더 적은 수정으로 완료된다면 이 라우팅 규칙이 맞게 작동하는 것입니다. 반대로 Wonder의 작업이 재실행 감소로 절약한 시간보다 더 많은 리뷰 코멘트를 유발한다면 Wonder에 맡기는 작업 범위를 좁히세요. 표의 수치는 벤치마크 평균일 뿐이며, 여러분의 실제 Task가 가장 중요한 시험대입니다.

이 중 어떤 비용도 Sharkly 청구서에 추가되지 않습니다. 모델 사용량은 컴퓨터에 구성된 Meta 및 Anthropic API 키를 통해 직접 청구되며, 정가 기준 가격이 동일하므로 유일한 비용 차이는 각 실행의 usage 블록에 기록되는 양뿐입니다.

이번 달에 모델이 바뀌었습니다. 하지만 요청부터 릴리스에 이르기까지 컨텍스트, 진행 상황, 장애물, 결과, 사람의 리뷰는 그대로 투명하게 관리됩니다. worktree를 사용해 수동으로 구축할 수도 있고, Sharkly를 통해 전체 워크플로를 관리할 수도 있습니다.