핵심 요약
AI 요약
기사 목차 펼치기 / 접기
가벼운 코딩 모델이 혼자 끝낼 수 있는 작업에 상위 계획 모델을 붙이면 속도가 오히려 떨어질까. 제미나이(Gemini) 4 하이드로젠과 계획·실행 자동 분업 모드인 오케스트레이터(Orchestrator)를 안티그래비티(Antigravity) CLI에서 맞붙여 본 결과, 분업은 하이드로젠 단독보다 두 배 이상 느렸다. 테스트 피드백까지 허용한 추가 실험에서 두 조건 모두 주어진 테스트를 통과했지만, 완료 시간 중앙값은 하이드로젠 단독 134.6초, 아르곤판 오케스트레이터 323.9초로 벌어졌다.
11월 14일 진행한 1차 파일 수정 실험 12회에 이어 모델이 직접 테스트를 돌리며 코드를 고친 추가 실험 6회까지 모두 18회를 비교했다. 분업의 속도 평가는 비교 기준에 따라 엇갈렸다. 상위 모델인 아르곤 단독(중앙값 401.7초)과 견주면 분업이 빨랐지만, 하이드로젠 단독보다는 시간이 더 걸렸고 분업만의 추가 정답 이득도 관측되지 않았다.
하이드로젠의 가격과 이전 설정에 이어, 이번에는 혼자 풀 수 있는 과제에도 계획 담당 모델을 더 얹어야 하는지 테스트 권한 장벽과 5개 파일 작업 큐 실험을 통해 확인했다.
카본 기준의 구글 발표와 이번 아르곤 비교 실험
구글(Google)은 공식 모델 발표에서 오케스트레이터가 카본에 가까운 성능을 내면서 Terminal-Bench 4.0 기준 평균 할당량을 24% 덜 쓰고, 19% 빠르다고 밝혔다. 회사가 제시한 벤치마크 결과로, 계획은 카본이 맡고 실행은 하이드로젠이 맡는 조합을 카본 단독과 비교한 수치다. 오케스트레이터는 하나의 대화 안에서 큰 계획 모델이 작업 설계와 중간 점검을 맡고, 가벼운 실행 모델인 하이드로젠이 실제 파일 수정과 테스트를 처리하는 자동 분업 모드다.
실험 계정에서 선택할 수 있었던 분업은 아르곤판으로, 비교 조건은 아르곤 high, 하이드로젠 high, 아르곤판 오케스트레이터 세 가지다. 공식 모델 문서에서도 아르곤판은 계획 담당을 아르곤, 실행 담당을 하이드로젠으로 나눈다. 하이드로젠 단독은 무료와 구글 AI 플러스(Plus)를 포함한 전 요금제에서 쓸 수 있고 기본 추론 단계인 high 외에 최고 단계인 xhigh까지 조절할 수 있지만, 아르곤판 오케스트레이터는 유료 구글 AI 프로(Pro)와 울트라(Ultra) 요금제에서 제공되며 고정 설정으로 동작해 추론 깊이(–effort)를 따로 바꾸지 못한다. 카본판의 수치를 재현하거나 반박하는 실험이 아니므로 비교 기준을 하이드로젠 단독으로 옮겼다.
실험은 윈도우(Windows)와 파이썬(Python) 3.13, 안티그래비티 CLI 1.5.8에서 실행했다. API를 직접 호출하지 않고 CLI의 비대화 실행과 구조화 출력으로 도구 실행 및 종료 상태를 남겼다. 비대화 실행(Headless mode)은 사람이 터미널 앞에서 매번 승인 버튼을 누르지 않고 명령줄 한 줄로 프롬프트를 넘겨 JSON 이벤트 로그와 종료 상태만 회수하는 무인 실행 방식이다.
테스트 권한 장벽과 첫 12회 파일 수정 실험
처음에는 파일 수정을 허용해도 테스트 명령이 거절되는 무인 실행의 권한 문제에 막혀 준비 실행들은 비교에서 제외했다. 첫 본 실험은 파일만 고치게 하고, 종료 뒤 별도 평가기로 검사하는 조건으로 고정했다.
구간 병합 과제에서는 겹치는 정수 구간과 경계를 합치면서 입력 원본을 보존해야 했다. 금액 집계는 소수 금액과 환불을 통화별로 합산하고, 중복 거래와 충돌을 구별하는 과제다. 명령줄의 잘못된 입력 처리까지 각각 8개와 10개 테스트 메서드로 검사했으며 일부는 여러 입력을 확인한다. 결함이 있는 초기 코드는 실패하고, 정상 예시는 통과하는지 먼저 확인했으며 모델에는 외부 테스트와 정상 예시를 주지 않았다.
각 과제를 세 조건에서 두 번씩 실행하되 매번 새 폴더와 대화에 같은 초기 코드와 지시를 전달했다. 첫 묶음은 아르곤·하이드로젠·분업 순서로, 두 번째는 역순으로 돌렸고 실행은 병렬로 겹치지 않았다. 세 모델에 파일 수정만 허용하고 명령 실행과 자체 테스트를 금지했으므로, 모델이 검사 결과를 먼저 본 뒤 추가 수정을 할 기회는 이 단계에 없었다.
| 과제 | 조건 | 1회 CLI 시간 | 2회 CLI 시간 | 외부 테스트 통과 | 정상 종료 |
|---|---|---|---|---|---|
| 구간 병합 | 아르곤 high | 58.0초 | 52.9초 | 2/2 | 2/2 |
| 구간 병합 | 하이드로젠 high | 28.3초 | 35.7초 | 2/2 | 2/2 |
| 구간 병합 | 분업(아르곤) | 62.3초 | 71.9초 | 2/2 | 2/2 |
| 금액 집계 | 아르곤 high | 171.8초·중단 | 170.0초·중단 | 2/2 | 0/2 |
| 금액 집계 | 하이드로젠 high | 74.8초 | 65.8초 | 2/2 | 2/2 |
| 금액 집계 | 분업(아르곤) | 137.0초 | 173.0초 | 2/2 | 2/2 |
12개 결과물은 모두 외부 테스트를 통과했고 하이드로젠은 각 과제의 두 실행 모두 가장 빨랐다. 아르곤은 금액 집계에서 정답 코드를 남겼지만, 180초 응답 제한에 걸려 두 번 모두 오류로 종료해 코드가 맞았다고 정상 완료로 세지는 않았다.
“정답 코드와 작업 완료는 서로 다른 판정이다.”
다섯 파일 작업 큐로 넓힌 테스트 피드백 재검증
첫 실험에는 코드를 고친 모델이 테스트 실패를 읽고 다시 수정하는 과정이 빠졌고, 분업의 계획·실행 역할을 보기에도 과제가 작았다. 추가 실험에서는 파일 간 연결과 테스트 피드백을 함께 넣었다.
먼저 공식 권한 문서에 따라 윈도우(Windows) 테스트 명령 전체와 맞는 정규식 허용 규칙을 세션에 적용하고 전역 설정은 그대로 뒀다. 작은 진단 과제에서 python -m unittest -v 실행과 테스트 1개 통과를 확인했다.
본 과제는 검증·저장·실행·조회·명령줄 처리를 다섯 파일로 나눈 로컬 작업 큐다. 같은 ID와 내용의 재등록은 한 번으로 처리하고 내용이 충돌하면 오류를 내야 했으며, 예약 시각이 된 작업만 정해진 순서로 실행하도록 했다. 실행 순서는 예약 시각과 ID로 정하고 실패 때 시도 횟수를 올리며, 최대 횟수에 도달한 작업은 실패 상태로 남기는 조건도 계약에 들어 있다.
실패한 작업은 한도까지 재시도하되 한 번의 호출에서 같은 작업을 즉시 반복하면 안 됐고, 완료한 작업은 재실행하지 않으며 상태와 결과는 재시작 뒤에도 남아야 했다. 손상된 저장 파일을 조용히 덮어쓰거나 오류를 정상 출력으로 내보내는지도 검사했다.
공개 테스트 11개와 외부 테스트 13개 메서드를 미리 고정하고 초기 코드의 실패와 정상 예시의 통과도 재확인했다. 모델은 공개 테스트를 실행해 코드를 재수정할 수 있었지만 외부 테스트와 정답 예시, 중간 평가 결과는 전달하지 않았으며 세 조건을 두 번씩 모두 6회 실행하고 초기 파일과 지시의 동일성은 해시로 대조했다.
새 대화·새 폴더와 정순·역순 실행을 유지하고 작업 제한은 10분, 프로세스 회수 여유는 별도 1분으로 늘렸다. 실시간 대기와 외부 서비스 호출은 제외하고 정수 시각을 입력하는 방식으로 예약·재시도 조건을 맞췄으며, 동시에 여러 실행자가 파일을 쓰는 상황은 과제에 넣지 않았다. 테스트 명령 진단은 본 비교 6회에서 제외했고, 모든 비교 실행은 프로세스 회수를 포함해 10분 안에 끝나 제한 뒤 코드가 바뀌는 사례도 없었다.
여섯 실행 모두 통과, 분업보다 빠른 하이드로젠 단독
여섯 실행 모두 수정 전 실패와 수정 후 통과가 로그에 남았으며, 아르곤 첫 실행에서는 공개 테스트 11개 중 10개가 실패했으나 코드를 고친 뒤 통과하고 한 차례 더 검사해 다시 통과했다. 이 실행은 테스트를 세 번, 나머지 다섯 실행은 두 번씩 돌렸다.
종료 후 평가기가 공개·외부 테스트를 다시 실행한 결과 여섯 결과물 모두 통과했으며 CLI도 정상 종료했다. 공개 테스트와 계약 등 보호 파일도 보존됐으며, 모델의 답변에서 테스트했다는 말만 읽고 성공으로 처리하지 않고 실행 이벤트의 명령 출력과 종료 코드를 함께 대조했다.
| 조건 | 1회 CLI 시간 | 2회 CLI 시간 | 중앙값 | 정상 종료·테스트 통과 |
|---|---|---|---|---|
| 아르곤 high | 450.3초 | 353.0초 | 401.7초 | 2/2 |
| 하이드로젠 high | 128.8초 | 140.5초 | 134.6초 | 2/2 |
| 분업(아르곤) | 306.9초 | 341.0초 | 323.9초 | 2/2 |
하이드로젠은 두 번 모두 분업보다 빨랐으며 중앙값으로 보면 약 2분 15초와 5분 24초의 차이다. 같은 판정에 도달하는 데 분업이 시간을 더 썼고, 테스트 피드백을 허용해도 추가 정답 이득은 나타나지 않았다.
하이드로젠 단독과 분업의 선택 기준 및 실험 한계
분업의 이점도 관측됐다. 추가 실험에서 분업은 두 번 모두 아르곤 단독보다 빨랐으며 아르곤 중앙값은 약 6분 42초였다. 계획 모델을 혼자 쓰던 사람과 하이드로젠을 혼자 쓰던 사람이 얻는 이득은 다르다. 구글도 모델 선택 가이드에서 별도 계획이 필요 없는 명확한 일상 작업에는 하이드로젠 단독을 안내한다.
이번 과제들은 요구사항과 판정 기준을 먼저 써 둬서 어느 방향으로 구현할지부터 찾아야 하는 저장소와는 조건이 다르다. 분업을 일상 개발에 권하는 회사 설명 전체를 이 결과로 부정할 수는 없으며, 단순히 파일 수를 늘린 과제에서 같은 결과가 나왔다고 해서 계획과 실행 사이의 조율이 잦은 긴 작업에서도 이 순서가 유지된다고 말할 수는 없다.
조건당 두 번씩 실행한 데다 서버 지연이나 캐시 영향을 분리하지 못했다. 단독 모델의 high 설정과 분업의 제품 고정 설정을 비교했으므로 추론량까지 같게 맞춘 실험도 아니며, 두 실험은 과제·권한·시간 제한이 달라 전체 평균으로 합치지 않았다.
시간 차이를 곧바로 요금 차이로 바꾸지도 않았다. CLI는 토큰 사용량을 보고하지만 입력·사고·캐시 필드를 임의로 더하면 중복될 수 있고, 실제 구독 한도 소모와 청구액을 확인하지 못해 API 단가를 곱해 분업이 비싸다고 단정할 근거도 없다. 이번에 확인한 것은 주어진 테스트의 통과와 관측 시간이다.
더 어려운 경계는 남았다. 대부분의 실행은 초기 실패를 읽고 수정한 뒤 곧바로 테스트를 통과했기 때문에, 계획 담당과 실행 담당 사이의 실제 인계나 실패 뒤 재계획이 얼마나 기여했는지는 분리하지 못했다. 설계 방향 자체가 틀렸을 때 계획 모델이 일을 얼마나 되돌려 놓는지는 이번 로그에 답이 없다.
