GPT-6 Luna 기반 에이전트 10개 vs Opus 5.5 하나: 실제로 더 많이 배포하는 구성은?

리뷰어 수는 정해져 있고, 2026-09-22 이후로는 모델 가격표가 더 이상 당신 대신 결정해 주지도 않습니다. GPT-6 Luna는 백만 입력 토큰당 $0.10, 백만 출력 토큰당 $0.50이고 API id는 gpt-6-luna입니다. Claude Opus 5.5는 $4와 $20이며 API id는 claude-opus-5-5입니다. 이건 요금계 양쪽에서 40배 차이이며, 두 벤더가 공개한 정가를 바탕으로 우리가 계산한 수치입니다. 그리고 이것은 한때 이론에 불과했던 질문을 매주 반복되는 스케줄 결정으로 바꿔 놓습니다. 같은 돈이라면, 값싼 에이전트 열 개를 돌릴 것인가, 비싼 에이전트 하나를 돌릴 것인가?

이 두 구성은 서로 대체재가 아닙니다. 이 둘을 가르는 것은 모델 품질이 아니며, 그 차이는 실행 시작이 아니라 끝에서 드러납니다. 각 구성이 사람 앞에 남기는 작업량이 서로 다르기 때문입니다.

이 질문을 현실로 만드는 산수

OpenAI는 점수 옆에 작업당 비용을 함께 공개하는데, 이는 가격표보다 훨씬 유용합니다. DeepSWE 1.1에서 최대 추론 노력(max reasoning effort)의 Luna는 66.6%를 기록했고, OpenAI는 이를 중간 노력(medium effort)의 Claude Opus 5, Fable 5와 비슷한 수준이라고 설명합니다. 작업당 비용은 Opus 5보다 93%, Fable 5보다 96% 낮습니다.

첫 번째 수치를 거꾸로 계산하면 Opus 5 작업 하나가 대략 Luna 작업 열네 개에 해당합니다. 따라서 같은 하네스에서 Luna를 열 번 돌리는 비용은 Opus 5를 한 번 돌리는 비용의 약 10분의 7입니다. 이 곱셈은 OpenAI가 밝힌 93%를 근거로 우리가 계산한 것입니다.

Anthropic은 Opus 5.5가 Opus 5보다 실행 비용이 40% 저렴하다고 말합니다. 이를 적용하면 비율은 대략 9대 1 수준으로 떨어집니다. 이 수치는 서로 다른 하네스에서 측정된 두 벤더의 데이터를 이어 붙인 것이므로, 하나의 확정된 숫자라기보다 방향성으로 받아들이는 게 좋습니다. 어느 쪽으로 계산하든, 값싼 시도 열 번과 비싼 시도 한 번의 비용이 이제 거의 비슷해졌습니다.

이 표와 함께 두 가지 주의 사항을 기억해야 합니다. OpenAI의 헤드라인은 Sol과 Luna가 각각 GPT-5.6 프로모션 가격보다 50% 저렴하다는 것인데, "프로모션"은 OpenAI 스스로 쓴 표현입니다. 즉 비교 대상이 정가가 아니라 할인된 요금입니다. 그리고 두 출시 글이 서로 직접 비교한 것도 아닙니다. 두 벤더 모두 같은 날 AutomationBench 점수를 보고했지만, 하네스 버전과 노력 수준이 서로 다릅니다. 이 두 퍼센트를 한 행에 나란히 놓으면 두 연구소 중 어느 곳도 수행하지 않은 비교가 됩니다. 위의 작업당 비용 비율이 유효한 이유는 그것이 단일 벤더의 자체 측정 안에서 나온 것이기 때문입니다.

하나의 선택처럼 보이는 세 가지 구성

"에이전트 열 개 아니면 하나"는 사실 세 가지 배치이며, 각각 리뷰 단계에서 다르게 작동합니다.

가운데 행이 바로 이번 가격 인하가 실제로 열어준 것이며, 대부분의 팀이 건너뛰는 방식입니다. 같은 작업을 열 번 실행하고 타입체크, 테스트, 빌드를 통과한 시도를 채택하는 전략은 시도 하나에 실제 비용이 들지 않게 되면서 비로소 감당 가능해졌습니다. 벤치마크 통과율이 2/3에 가까울 때 시도 하나가 실패할 확률은 1/3입니다. 시도들이 서로 독립적으로 실패한다면 열 번 시도가 모두 실패하는 일은 거의 없을 것입니다. 하지만 시도들은 독립적으로 실패하지 않습니다. 요구 사항이 모호하거나 픽스처가 빠진 작업은 모든 시도를 똑같은 방식으로 무력화합니다. 팬아웃이 사주는 건 보장이 아니라 변동성입니다.

첫 번째 행이 대부분의 팀이 실제로 손을 뻗는 방식이며, 바로 비싼 쪽입니다. 달러 때문이 아닙니다. 작업 10개에 에이전트 열 개를 붙이면 diff가 열 개 나오고, 그 하나하나를 사람이 읽고, 에이전트가 무엇을 선택했는지 이해하고, 병합에 대한 책임을 져야 합니다. 이 비용은 2026-09-22에 떨어지지 않았고, 어떤 모델 출시도 이 비용에는 손대지 못합니다. 우리는 병렬 에이전트 작업에서 사람의 리뷰가 병목인 이유와 사람의 근무일 하루가 감당할 수 있는 에이전트 근무일 수에 대해 글을 쓴 적이 있습니다. 그곳의 산수는 토큰이 싸졌다고 달라지지 않습니다.

Luna 위의 에이전트 열 개는 산출량이 열 배가 아닙니다. 도착하는 작업량이 열 배입니다. 값싼 모델은 시도를 사줄 뿐입니다. 리뷰 역량을 사주지는 않으며, 청구서라는 숫자 하나만 지켜보고 있으면 이 둘을 혼동하기 쉽습니다.

이전 가능한 지표는 수용된 변경당 비용이다

수용된 변경당 비용은 사람이 실제로 읽고 수용한 diff 하나마다 팀이 추론에 지출하는 금액입니다. 이는 출시된 작업과 연결되는 유일한 에이전트 비용 지표입니다. 아무도 리뷰하지 않은 시도는 아무것도 출시하지 못했기 때문입니다.

이 정의는 세 가지 구성을 즉시 분류합니다. 작업 하나에 대한 팬아웃은 시도 열 개를 리뷰 결정 하나에 나눠 담으므로, 값싼 시도가 수용된 변경당 비용을 정비례해서 낮춥니다. 작업 열 개에 걸친 확장은 시도 하나를 리뷰 결정 하나에 열 번 나눠 담으므로, 값싼 시도가 추론 비용 항목은 낮추지만 리뷰 항목은 그대로 유지되어 제약 조건이 됩니다. 비싼 에이전트 하나에 대한 깊이는 리뷰어 앞에 놓인 단일 시도가 병합할 가치가 있는 시도일 확률을 높여 줍니다.

실무에서만 드러나는 두 번째 효과도 있습니다. 값싼 시도 열 번과 비싼 시도 한 번은 작업하는 느낌이 다릅니다. Artificial Analysis는 이 모델들의 최대 추론 변형에서 첫 토큰까지 Luna는 124.23초, Sol은 102.15초를 측정했습니다. 이는 특히 최대 변형에 대한 서드파티 수치이므로, 이를 전제로 계획을 세우기 전에 확인해 보는 게 좋습니다. 각각 2분 동안 아무 말 없이 있다가 글자를 하나 내놓는 에이전트 열 개는 빠른 파이프라인이 아닙니다. 한꺼번에 멈춘 것처럼 보이는 실행 열 개이며, 이는 모델 문제가 아니라 상태 표시 문제입니다.

판단 기준 두 가지

기계가 결정할 때는 값싼 에이전트 열 개를 사용하세요. 즉, 사람 없이 실행되는 실질적인 수용 신호가 작업에 있어야 합니다. 오늘은 실패하지만 통과해야 하는 테스트, 타입체크, 빌드, 린트 규칙, 재현 스크립트가 여기에 해당합니다. 트리아지, 라벨링, 테스트 스캐폴딩, 기계적 리팩터링도 자격이 됩니다. "제대로 됐는가"가 의견이 아니라 명령어로 판정되는 변경도 마찬가지입니다.

사람이 결정할 때는 비싼 에이전트 하나를 사용하세요. 변경을 수용하려면 코드를 읽고 판단을 내려야 한다면, 추가 시도는 도움이 되지 않고 읽을 거리만 배로 늘립니다. 장기 작업도 마찬가지입니다. Anthropic은 Opus 5.5가 18시간 이상 작업을 유지한다고 밝히는데, 오후 내내 하나의 목표를 붙잡고 가는 실행 하나가 같은 불완전한 이해에서 매번 다시 시작하는 실행 열 개보다 가치 있습니다.

수용 신호 작성을 피하려고 팬아웃을 쓰지 마세요. 자동 판정기 없이 그럴듯한 diff 열 개가 나오는 것은 diff 하나보다 나쁩니다. 그럴듯한 diff 열 개 중에서 고르는 일은 하나를 리뷰하는 것보다 더 어려운 작업이며, 바로 당신이 보호하려던 사람에게 떨어지는 일이기 때문입니다.

확장 구성이 상위 계층에 요구하는 것

에이전트 열 개를 동시에 돌리는 것은 비용 문제이기 전에 조정 문제입니다. 필요한 요소들은 이미 알려져 있습니다. 각 실행을 자체 워크트리에서 돌려서 두 에이전트가 같은 파일을 편집하는 일이 사고가 되지 않게 하고, 작업마다 담당자를 하나씩 두어 소유권이 모호해지지 않게 하고, 실행 중과 대기 중과 실패를 구분하는 상태를 두는 것입니다.

에이전트는 작업이 어떻게 처리되어야 하는지를 정의합니다. 컴퓨터는 호스트와 로컬 리소스를 제공합니다. 런타임은 세션을 수행합니다. 작업은 공유 기록으로 남습니다. 열 개의 실행이 한 시간 안에 서로 끝날 때, 마지막 부분이 바로 그 한 시간이 열 개의 터미널을 뒤지는 수색 작업이 되지 않게 막아 줍니다.

끝난 Luna 실행은 사적인 세션 로그가 아니라 자신의 작업에 다음과 같은 것을 반환해야 합니다.

SH-312  웹훅 디스패처에 백오프를 곁들인 재시도 추가
Runtime   gpt-6-luna (팬아웃, 8회 시도, 3회 스위트 통과)
Selected  6번 시도, 통과 집합 중 가장 작은 diff
Evidence  타입체크 정상, 214개 테스트 통과, 빌드 정상, 커버리지 +0.4%
Known limit  429 경로에 대한 테스트 없음, 디스패처가 아직 멱등하지 않음
Status    리뷰 대기 중, 사람 확인 필요

중요한 부분은 선택 라인입니다. 무엇이 결정했는지 알려주므로, 리뷰어는 자신이 기계의 선택을 확인하는 것인지 아니면 직접 선택하는 것인지 알 수 있습니다. 선택 기록이 없는 시도 열 개는 하나의 작업인 척하는 열 배의 작업입니다.

결론

스위트가 결정하고 백로그가 충분히 넓어 에이전트를 계속 바쁘게 유지할 수 있다면 값싼 에이전트 열 개가 더 많이 출시합니다. 수용 결정이 사람의 몫이거나, 작업 기간이 길거나, 자동 신호가 약하다면 비싼 에이전트 하나가 더 많이 출시합니다. 대부분의 팀은 선호가 아니라 작업 유형에 따라 라우팅된 두 방식을 모두 원할 것입니다. 이것이 작업별로 모델을 에이전트 역할에 맞추기에서 주장하는 내용입니다.

어느 구성도 마지막 단계를 바꾸지는 않습니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수용합니다. 모델 가격은 하루 만에 40배 움직였지만, 팀이 책임 있게 수용할 수 있는 변경의 수는 전혀 움직이지 않았습니다.

이미 여러 에이전트를 운영하고 있다면, Sharkly는 어떤 런타임이 diff를 만들어냈든 상관없이 요청부터 릴리스까지 컨텍스트, 진행 상황, 블로커, 결과, 사람의 리뷰를 한곳에서 볼 수 있게 해줍니다.