제가 아직 Muse Wonder에 대한 실습 보고서를 본 적이 없어서 하나 작성해 봅니다. 저는 동일한 코딩 작업을 동일한 프롬프트 파일로 두 에이전트에게 순차적으로, 같은 기계와 같은 저장소(repo)에서 수행했습니다. 각 실행 전에 스냅샷으로부터 코드를 복원했기 때문에 둘 다 동일한 파일 상태에서 시작했습니다. 별도의 검토자(Claude)가 결과물을 줄 단위로 확인했습니다. 저는 이들의 자체 보고서를 신뢰하지 않았습니다.
설정: Muse Codex Model muse-wonder-1.0 deepseek-v4.1-flash 노력 수준(Effort): 높음 (model_reasoning_effort = "high") Harness Muse Code CLI 1.4.14 (Meta) Codex CLI 0.165.0, 사용자 정의 제공자(local proxy → OpenCode Go) 모드: exec (headless), 이후 TUI 인터랙티브 TUI Sandbox / 승인 샌드박스에서 재개됨, --approval-mode on-request, LLM 승인 심사관은 workspace-write에 대해, approvals on-request with auto review, Contributor mode (Meta trains on your data)는 이번 실행에서는 비활성화(off), 해당 없음(n/a)
계획: Muse Code "High Usage" 구독, 토큰당 결제
작업 내용: 이것은 프로덕션 TypeScript 프로젝트의 실제 기능입니다. Cloudflare Worker와 Node 컨테이너가 결합된 형태입니다. 중간 규모이며, 약 19개의 파일이 수정되고 ~330줄의 프로덕션 코드가 포함되어 있습니다.
LLM 카피라이팅 프롬프트의 새로운 버전입니다. 캡션 라인 3개 외에도, LLM은 이제 8초짜리 제품 리얼(Product Reel)을 위한 애니메이션(카드, 텍스트, 카메라, 하이라이트 및 전환 이름)도 선택하며, 이는 폐쇄된 목록 내에서만 이루어집니다.
코드 측 검증: 알 수 없는 이름은 null로 처리되고, 제품이 하나만 있는 그룹 카드는 null로 처리되며, 누락된 필드가 작업을 거부하는 경우는 없습니다. 이러한 선택 사항들을 파이프라인을 통해 렌더 컨테이너까지 전달합니다. 컨테이너의 비디오 경로를 ffmpeg 장면 파이프라인에서 이미 존재하고 승인된 Remotion 구성(composition)으로 교체해야 합니다. 테스트 먼저, 타입 체크(typecheck), 전체 스위트(full suite), Docker 빌드, 그리고 이미지 내에 샘플 제품을 실제로 렌더링하는 과정까지 포함합니다. 증명 과정 중 유료 AI 호출은 없었습니다.
결과: Muse Wonder, DeepSeek V4.1 Flash (Codex) 벽 시간(Wall time): 47분, 29분. 실제 작동 시간(Time actually working): 약 24분, 29분. 인간 개입(Human interventions): 1 ("the stall" 참조), 0.
Typecheck: 깨끗함(clean), 깨끗함(clean). 전체 테스트 스위트(Full test suite): 1728/1728, 1726/1726. 새 테스트(New tests): 10 (1 파일), 8 (3 파일). 코딩 전 기록된 "빨간색"(Red) 테스트 실행: 단지 import 오류만 있음. 예: 7개 실패, 모두 "behavior missing". 변이 테스트(Mutation testing) (40 샘플링된 돌연변이): 7개 제거됨(killed), 6개 제거됨(killed).
Docker 내부 렌더링(Render inside Docker): 16.2초, 16.1초. 출력 비디오: 정확함; 승인된 참조와 동일해 보임. 정확함; 승인된 참조와 동일해 보임. 허용 파일 내에 머무름: 예, 예. 화면상에서 둘 다 동등하게 좋았음. 두 비디오 모두 정확하며, 저는 둘 다 승인했습니다.
코드 품질 (차이가 난 부분):
Muse Wonder: 테스트가 포착하지 못한 두 가지 실제 버그. 중복 작업(Double work). 비디오를 위해 제품을 자르기 위해 기존의 약 50줄짜리 함수인 커버 이미지 배경 제거 기능을 복사하여 사용했고, 둘 다 유지했습니다. 결과: 첫 번째 제품이 비디오당 두 번 배경 제거 과정을 거칩니다. 임대 GPU에서 실행되는 저희 설정에서는 비용이 두 배가 됩니다. 테스트는 가짜 의존성(fake dependencies)을 사용하기 때문에 통과합니다. 시드(seed) 무시. 사양서에는 LLM이 선택지를 제공하지 않을 때 애니메이션은 "job id로 시딩되어 무작위로" 선택된다고 명시되어 있습니다. Muse는 시드를 전달하지 않았기 때문에, 제목 + 상점 이름으로 대체 시딩(fallback seeds)합니다. 동일한 제목을 가진 두 작업은 동일한 "무작위" 애니메이션을 얻습니다. 이름을 폐쇄 목록에 두 번 하드코딩했습니다. 한 번은 프롬프트(prompt)에서, 다른 한 번은 검증기(validator)에서, 따라서 둘이 달라질 수 있습니다.
좋았던 점: 재시도 시 LLM으로 돌아가는 오류 메시지를 설명적으로 유지했고 (허용된 키 목록을 나열함), 요청대로 오디오 트랙을 이전과 정확하게 유지했습니다.
DeepSeek V4.1 Flash (Codex): 더 깔끔한 구조, 세 가지 작은 개선점. 기존 함수를 단일 루프(single loop)로 리팩토링했습니다. 각 제품은 한 번만 잘리고, 커버는 첫 번째 자른 것을 재사용합니다. 중복이 없습니다. 사양서에 명시된 대로 job id를 시드(seed)로 전달했습니다.
이름 목록의 유일한 출처는 검증기(validator)가 프롬프트 모듈에서 가져옵니다. 이전 버전에서도 여전히 존재했던 데드 코드 경로를 제거했습니다.
발견된 문제점(Slips)들은 짧은 후속 작업에서 수정되었습니다 (DeepSeek/Codex 재차: 15분 소요, 세 가지 모두 수정되었고 검토자에게 확인받았으며, 빨간색 테스트 실행 기록이 먼저 남겨짐): LLM의 재시도 메시지를 모호하게 만들었습니다("키가 형식 밖에 있음"이라고만 하고 키 목록은 제시하지 않음). 호출자가 개수(count)를 전달하지 않았을 때 기본값으로 "1 product"를 설정했습니다. 오늘 발동되지는 않았지만 불안정합니다. 무음 오디오 트랙을 44.1 kHz에서 48 kHz로 변경하고 -shortest로 전환했습니다.
작업은 "오늘과 동일하게"라고 했습니다. 저의 평가는 가시적인 결과 면에서는 동등합니다. 하지만 코드는 DeepSeek/Codex 쪽이 더 좋습니다. 그 문제점들은 미관상의 것이지만, Muse의 버그는 비용을 발생시키고 동작을 변경하기 때문입니다.
토큰 및 비용 (Tokens and cost)
- Muse Wonder (세션 종료 시 Muse의 /usage 패널에서 확인): 입력 26,714,096개 중 캐시된 것 25,521,699개, 출력 101,452개, 총 26,815,548개. 턴(Turns) 136회, 서브에이전트(Subagents) 없음, 옵저버(Observers) 92개 완료 (1,880,147 토큰). 5시간 창 사용량 74% (시작 시 0%에서), 주간 할당량 사용률 24% (시작 시 0%에서).
- DeepSeek V4.1 Flash via OpenCode Go (제공자 대시보드에서, 실행 창만): 요청 180회, 입력(캐시 미사용) 1.3M, 캐시 읽기 35.0M, 캐시 쓰기 — 출력 208.7k. 비용 US$ 0.86.
중요한 수치는 다음과 같습니다: 중간 규모의 작업 하나가 Muse의 5시간 창 사용량의 74%와 거의 1/4에 달하는 주간 할당량을 소모했습니다. 이 속도로는 약 5시간마다 이런 작업을 한 번, 그리고 일주일에 약 네 번 수행할 수 있습니다. DeepSeek은 창 사용량 제한 없이, 같은 작업을 1달러 미만으로 처리했습니다.
유휴 대기(idle stall) 시간은 기다리기만 하고 생성하지 않았기 때문에 Muse의 할당량에 거의 영향을 미치지 않았습니다. 기여자 모드(Contributor mode)는 꺼져 있었습니다. 서드파티 출처에 따르면, 이를 켜면 Meta가 사용자의 데이터를 학습하는 대가로 더 많은 사용량을 제공한다고 합니다. 다음에는 더 작은 작업으로 이것을 측정해 보겠습니다.
대기(저의 실수이지만 알아둘 가치가 있음): Docker Desktop이 꺼져 있었습니다. 헤드리스 실행 모드(headless exec mode)에서 Muse가 스스로 Docker를 시작하려고 시도했습니다.
해당 명령어는 샌드박스(sandbox) 외부였기 때문에 승인이 필요했고, LLM 승인 심사관(LLM approval judge)이 이를 해결하지 못했습니다. Muse는 터미널에 아무 출력도 없이 약 23분 동안 조용히 있었습니다. 저는 그것을 중단시키고, Docker를 시작한 다음, 대화형 TUI(Terminal User Interface)에서 muse resume --last를 실행했습니다. 그것은 멈췄던 지점부터 계속 진행하여 약 8분 만에 끝났습니다. 교훈: Muse가 승인 프롬프트(approval prompts)를 보고하거나 답변할 수 없다면, 장기 작업을 위해 Muse를 헤드리스(headless, exec) 모드로 실행하지 마십시오. exec 모드에서는 종료될 때까지 창에 아무것도 표시되지 않습니다.
결론적으로 Muse Wonder는 작동하는 코드를 빠르게 작성하고, 범위에 대한 지침을 따르며, 화면의 결과도 정확했습니다. 하지만 "보기에 괜찮고 테스트를 통과"했지만 오류가 있었던 두 가지 실수를 했습니다: 중복 작업 수행, 그리고 사양(spec) 세부 사항 무시입니다. 실제 한계는 할당량이며, 기여자 모드(contributor mode)를 끄고 중간 규모의 작업을 하나 처리하는 데 5시간 창의 74%가 소요되었습니다.
Codex CLI의 DeepSeek V4.1 Flash는 약 5분의 추가 작업 시간이 필요했지만, 도움 없이 완료되었고, 더 나은 구조와 더 나은 TDD(Test-Driven Development) 규율을 가졌으며, 작은 실수만 했고, 비용은 US$ 0.86이었습니다. 일상적인 구현 작업을 위해서는 Codex를 통한 DeepSeek에 머무를 생각입니다. Muse는 두 번째 의견으로 남겨두고, 기여자 모드를 켜서 다시 테스트할 것입니다. 설정에 대한 질문에는 기꺼이 답변하겠습니다. 제출자: /u/Richidm [링크] [댓글]