Claude Code에 ‘ultracode’라는 모드가 생겼습니다. 슬라이더를 low → medium → high → xhigh까지 올린 그 너머, 보라색 영역에 적힌 한 칸입니다. 설명에는 “xhigh + workflows”라고만 적혀 있습니다.
여기서 가장 흔한 오해를 먼저 풀겠습니다 — ultracode는 ‘더 똑똑한 모델’이 아닙니다. 같은 Opus, 같은 xhigh 추론에 여러 에이전트가 나눠 일하는 오케스트레이션을 얹은 것뿐입니다. 그렇다면 질문은 하나로 좁혀집니다 — “일을 나눠 시키면, 결과가 정말 좋아지는가?”
Claude Code 사용 분석 시리즈 — 추측이 아니라 실측으로 답합니다. 제 실제 업무 4종을 솔로(xhigh) vs ultracode로 똑같이 시키고, 블라인드로 채점하고, 시간·토큰까지 잰 기록입니다.
① ultracode는 만능 업그레이드가 아니라 작업류 전용 도구였습니다. 분석·사실 검증 작업에선 결정적으로 좋아졌고(이사회 보고서 +1.4, 법령 사실형 +1.3 / 10점 만점), 창의·도메인 작업(워크숍 교재)에선 오히려 −0.8 나빠졌습니다.
② 값은 공짜가 아닙니다 — ultracode는 솔로 대비 비용 약 4~8배, 시간 약 2~6배. 게다가 출력 토큰이 많다고 품질이 좋아지지도 않았습니다(토큰 7.2배 쓰고 품질은 +0.4뿐인 경우도).
③ 그래서 저는 “오류가 있으면 치명적인” 분석·규제 작업엔 ultracode, 창의·도메인 보이스 작업엔 xhigh 솔로로 결정했고, 이 규칙을 제 운영 하네스에 코드로 박았습니다. 끝에 업무별 비즈니스 판단표를 붙였습니다.
“더 비싼 모드 = 더 좋은 결과”라는 직관을, 실측으로 검증했습니다
“effort를 한 칸 더 올리면, 정말 결과물이 그만큼 좋아질까? 아니면 그냥 더 느리고 더 비싸지기만 할까?”
— AI 에이전트에 일을 맡기는 사람이라면 매번 망설이는 지점
AI 도구의 ‘effort(노력 강도)’를 올린다는 건, 사람으로 치면 “더 오래 고민하고, 검토를 한 번 더 하라”는 주문입니다. 직관적으로는 항상 더 좋을 것 같습니다. 그런데 ultracode는 결이 조금 다릅니다. 추론을 더 짜내는 게 아니라, 일을 여러 에이전트에게 쪼개 나눠 주고(계획→분담 작성→검증→통합) 그 결과를 합치는 방식입니다.
effort 슬라이더(low·medium·high·xhigh·max)는 한 명의 에이전트가 한 번에 얼마나 깊이 추론하나를 조절합니다. ultracode는 그 위에 ‘workflows’ — 멀티에이전트 오케스트레이션 로직 한 층을 더 얹습니다. 모델(Opus)은 그대로 두고, 일하는 구조에 다음 단계가 추가됩니다.
- 작업 분해(Plan) — 큰 일을 하위 작업으로 쪼개는 계획 단계
- 병렬 분담(Fan-out·Pipeline) — 여러 서브에이전트가 각 부분을 동시에 처리
- 적대적 검증(Critic) — 독립된 검증 에이전트가 결과를 반박·교차 대조
- 종합(Synthesis) — 검증을 반영해 하나의 산출물로 통합
- 완전성 루프 — 미흡하면 빠진 부분을 다시 채움
→ 즉 effort가 ‘한 명이 얼마나 깊이 생각하나’라면, ultracode는 거기에 ‘여러 명이 어떻게 나눠서 서로 검증하나‘를 더한 것입니다.
나눠서 일하면 사람 팀이 그렇듯 교차 검증의 이득이 생깁니다. 하지만 동시에 분업의 비용(소통 손실·관점 충돌·통합 잡음)도 따라옵니다. 그래서 “좋아진다/나빠진다”는 머리로 단정할 수 없고, 실제로 시켜 보고 재 보는 수밖에 없습니다. 그래서 쟀습니다.
- 공정하게 쟀는가 — 변수를 오케스트레이션 하나로 묶은 실험 설계
- 벤치 전 내 추측 vs 실제 결과 — 어디서 맞고 어디서 빗나갔나
- 품질·시간·토큰비용 — 좋아진 만큼 얼마를 더 냈나
- 그래서 언제 무엇을 쓰나 — 업무별 비즈니스 판단표 + 필자의 결정
변수는 ‘오케스트레이션’ 하나로 묶었습니다 — 그래야 공정합니다
벤치마크가 거짓말을 하는 가장 흔한 이유는 변수가 여러 개 섞여서입니다. 그래서 모델·규칙·프롬프트를 전부 고정하고, 딱 하나 — 일을 혼자 하느냐 나눠 하느냐 — 만 바꿨습니다.
한 명이 끝까지
에이전트 1명이 한 번에 산출물을 작성합니다. 별도 검증자가 없고, 스스로 점검해 혼자 책임집니다.
여럿이 나눠서
계획 → 병렬 작성 → 적대적 검증(critic) → 통합의 분업입니다. 한 작업에 평균 7~8명의 에이전트가 투입됩니다.
두 방식 모두 같은 Opus·같은 xhigh·같은 규칙·같은 프롬프트를 받습니다. 그리고 결과물은 어느 쪽이 솔로/ultracode인지 모르는 블라인드 심판 2명이 6개 항목(사실 근거·깊이·구조·도메인 적합·환각 안전·완성도)으로 채점했습니다. 제시 순서도 작업마다 바꿔 위치 편향을 막았습니다.
업무는 제가 실제로 가장 많이 하는 네 가지를 골랐습니다.
- 발표 슬라이드 작성 — 워크숍·강의 발표 슬라이드 (창의·도메인 보이스)
- C-Level 전략 보고서 — 이사회·경영진 전략 보고 한 섹션 (분석·종합)
- 생소 도메인 사실형 — 화학물질관리법 점검 체크리스트 (생소·규제, 환각 검증)
- Sillok 하네스 관리 — 내부 컨설턴트 하네스(Sillok) 거버넌스 제안서 (메타·자기참조)
저는 이렇게 예측했습니다 — 그리고 한 곳에서 보기 좋게 빗나갔습니다
실험 전, 제 예측은 분명했습니다. “분석(C-Level 전략 보고서)과 사실 검증(생소 도메인)에선 ultracode가 크게 앞설 것이다. 발표 슬라이드는 박빙일 것이고, Sillok 하네스 관리는 혼재할 것이다.” 멀티에이전트의 교차 검증이 사실·논리 작업에 유리하다는 건 거의 상식이니까요.
셋은 맞혔지만 발표 슬라이드에서 보기 좋게 틀렸습니다. “박빙”일 거라던 예측과 달리, ultracode는 솔로에게 0.8점이나 졌습니다. 더 많은 에이전트가 더 오래, 더 비싸게 일했는데 결과가 더 나빴던 겁니다. 이 한 칸이 이 글에서 가장 중요한 발견입니다 — 왜 그랬는지는 Part 5에서 풀겠습니다.
품질은 ‘유형에 따라’ 극과 극으로 갈렸습니다
블라인드 심판 2명의 채점 결과입니다(6차원 평균, 10점 만점). 한 표로 보면 패턴이 분명합니다.
“평균을 내면 +0.55입니다. 그런데 이 평균은 거짓말입니다. 발표 슬라이드의 −0.8과 C-Level 보고서의 +1.4를 한데 평균 내는 건 의미가 없습니다. 반드시 유형별로 읽어야 합니다.”
차원별로 뜯어보면 더 선명합니다. ultracode가 일관되게 이긴 곳은 깊이(+1.5)·완성도(+1.0)·환각 안전(사실형 한정) 세 곳뿐이고, 구조와 도메인 적합도는 사실상 동률이었습니다. 즉 “일을 나눈다고 글의 구조나 현장 감각이 좋아지진 않습니다.” 그건 프롬프트와 규칙의 몫이지, 에이전트 수의 몫이 아니었습니다.
좋아진 만큼, 얼마를 더 냈는가 — 4~8배입니다
품질만 보면 절반의 그림입니다. 나머지 절반은 비용입니다. 각 에이전트의 실행 기록(타임스탬프·토큰 사용량)을 직접 파싱해 쟀습니다.
합계로 보면, 4개 작업을 솔로로는 4개 에이전트·출력 약 6만 토큰·약 $51에 끝냈고, ultracode로는 30개 에이전트·출력 약 25만 토큰·약 $283이 들었습니다. 대략 5.6배의 비용입니다.
- 비용($)은 상한 추정입니다. Opus 단가 가정에 전 구간 캐시 비용을 합산한 값이라, 실제 청구보다 다소 높게 잡힙니다. 그래서 절대 금액보다 ‘배수’와 ‘출력 토큰’이 더 믿을 신호입니다.
- 시간은 부풀려져 있습니다. 4개 작업을 동시에 돌려 에이전트들이 자리를 두고 줄을 섰습니다(특히 C-Level 보고서 29분). 작업 하나만 단독으로 돌리면 ultracode 시간은 이보다 짧습니다. 반면 토큰·비용은 줄서기와 무관하므로 그대로 신뢰해도 됩니다.
여기서 반(反)직관적인 사실 하나 — 출력 토큰이 많다고 품질이 좋아지지 않았습니다. Sillok 하네스 관리는 솔로의 7.2배 토큰을 뽑고도 품질은 +0.4뿐이었고, 발표 슬라이드는 4.6배 토큰을 쓰고도 −0.8로 더 나빴습니다. “많이 생성 = 잘함”은 환상입니다.
발표 슬라이드가 진 진짜 이유 — 검증자가 ‘정답’을 ‘오답’으로 고쳤습니다
가장 충격적인 장면은 발표 슬라이드 작성에서 나왔습니다. ultracode의 검증 에이전트(critic)가, 솔로가 정확히 써 둔 핵심 용어를 “교정”이라며 틀린 값으로 바꿔 문서 전체에 퍼뜨렸습니다.
손해보험 워크숍 교재에서 PI는 정본 시스템 프롬프트상 ‘Process Innovation(프로세스 혁신 — 자동화 전에 업무를 없애거나 줄이기)’입니다. 솔로 에이전트는 이를 정확히 썼습니다.
그런데 ultracode의 critic은 “PI는 개인정보(Personal Information)로 통일하라”며 틀린 정의로 바꾸고, 슬라이드 배지·표·각주 네 곳에 전파했습니다. 정확했던 90%가 신뢰를 떠받치는 사이, 검증자가 새 오류를 ‘주입’한 겁니다.
여기서 교훈이 뒤집힙니다. 환각 안전은 “검토를 더 한다”가 아니라 “검토자가 옳은 출처를 보느냐”에 달려 있었습니다. 검증자가 정본(SSoT)을 오독하면, 오히려 맞는 값을 틀린 값으로 오염시킵니다. 창의·도메인 글처럼 ‘하나의 일관된 목소리’와 ‘현장 정본 용어’가 생명인 작업에서, 여러 에이전트의 분업은 득보다 실이 컸습니다.
반대로 생소 도메인 사실형(법령 체크리스트)에선 같은 분업이 최고의 무기였습니다. 분리된 검증자가 법령·고시 번호를 1차 출처로 일일이 대조해, 솔로라면 그럴듯하게 지어냈을 법한 조항 번호의 날조를 잡아냈습니다. 같은 도구가, 작업의 성격에 따라 약이 되고 독이 된 것입니다.
ultracode(멀티에이전트)는 여러 출처를 교차검증하고 날조를 사냥해야 하는 작업에서 값을 합니다. 현장 감각으로 하나를 일관되게 짓는 작업에서는, 분업이 오히려 손해입니다.
그래서 언제 ultracode, 언제 xhigh인가 — 업무별 결정표
품질 Δ와 비용 배수를 한 표에 놓으면, 의사결정이 단순해집니다. 핵심 질문은 “이 작업은 오류가 있으면 치명적인가, 그리고 정답이 외부 출처에 있는가?” 하나입니다.
- 정답이 외부 출처(문서·데이터·법령)에 있고, 오류가 있으면 치명적인가? → ultracode (분석·규제·사실형)
- 하나의 목소리·현장 감각·정본 용어가 생명인가? → xhigh 솔로 (창의·교재·도메인 글)
- 둘 다 애매한가? → 솔로로 시작하고, 중대한 교차검증이 필요할 때만 올린다.
저는 이 규칙을 ‘기억’이 아니라 ‘시스템’에 박았습니다
좋은 교훈도 매번 떠올려야 하면 휘발됩니다. 그래서 저는 이 판단을 제 운영 하네스의 라우팅 로직에 규칙으로 심었습니다. 작업 유형을 창의(generative)냐 분석(analytic)이냐로 가르고, 창의 작업은 자동으로 단일 작성자(솔로)로 고정해 멀티에이전트 검증을 막고, 분석·규제·사실형은 멀티에이전트로 승격하도록 했습니다. 회귀 테스트까지 통과시켜 두었으니, 다음부터는 제가 잊어도 시스템이 같은 기준으로 판단합니다.
정리하면, ultracode는 ‘항상 켜는 고급 모드’가 아니라 ‘특정 작업에만 꺼내는 정밀 공구’입니다. 비싸고 강력하지만, 잘못된 자리에 쓰면 멀쩡한 결과를 망칩니다. 도구의 등급을 올리기 전에 “이 일은 검증으로 좋아지는 일인가, 일관성으로 좋아지는 일인가”를 먼저 물어보시길 권합니다.
같은 모델, 다른 일하기 방식 — 선택은 ‘작업의 성격’이 정한다
이번 벤치마크의 한 줄 결론은 이것입니다 — “더 많이 일을 나눈다고 더 좋아지지 않는다. 좋아지는 일에만 나눠라.” 분석과 사실 검증에는 멀티에이전트의 교차검증이 약이 되고, 창의와 도메인 보이스에는 단일 작성자의 일관성이 이깁니다. 그리고 그 결정은 지갑(4~8배 비용)과도 직결됩니다.
※ 본 글의 수치는 필자 환경에서의 단일 실측치이며, 작업·프롬프트·모델 버전에 따라 달라질 수 있습니다. 비용($)은 단가 가정에 기반한 상한 추정입니다. 핵심은 절대값이 아니라 ‘유형에 따라 방향이 갈린다’는 패턴입니다.
ultracode
xhigh
멀티에이전트
에이전트 워크플로우
AI 비용
벤치마크
Agentic PM