TL;DR

각 회사의 AI 에이전트 CLI를 "어느 것이 최강인가"로 선택하는 것을 그만두고, 역할 분담으로 사용하기로 했다.

이 도표도 Codex에 위임하여 생성한 것 (이유는 후술)

왜 "최강의 한 자루"가 아니라 역할 분담인가

2026년 7월 현재, 주요 4사의 에이전트 CLI는 모두 "일단 무엇이든 할 수 있다". 코드도 쓸 수 있고, 검색도 할 수 있으며, 이미지도 만들 수 있다. 그렇기에 "전부 ○○로 하면 된다"라는 결론으로 흐르기 쉽지만, 실제로 4개를 병행 운용해 보면 특기 분야의 차이는 명확하다.

포인트는 범용 성능의 차이가 아니라 그 에이전트만이 할 수 있는 것 (독점 능력)과 성격의 차이로 분담을 결정하는 것이다.

각 에이전트의 특성 (검증 완료)

이하의 사실관계는 후술할 데모에서 Antigravity CLI에 소스 URL을 포함하여 검증시킨 결과이다 (6개 항목 중 5개는 ◎ 확인, 1개는 △ 부분적 확인).

뇌: Claude Code (Claude Fable 5)

Anthropic의 Mythos 클래스 모델 (일반 제공 버전 중 최상위). 거의 모든 벤치마크에서 SOTA, 1M 토큰 컨텍스트를 보유하고 있다. 장시간의 자율 실행과 서브 에이전트 지휘가 설계상의 강화점이며, 즉 "사령탑"은 제조사의 설계 의도대로 사용하는 방법이다.

주의할 점은 "지시를 따르지 않는 것"이 아니라 **"재량이 강하다"**는 것이다. 방치해 두면 요청하지 않은 리팩터링 (Refactoring)이나 정리까지 해버린다. 다만 짧은 지시 하나에 쉽게 방향을 틀기도 한다 (공식 프롬프팅 가이드에도 명시되어 있다).

손: Codex CLI (GPT-5.5)

OpenAI 최초의 "agentic-first"로 재학습된 모델. Terminal-Bench 2.0에서 82.7%의 SOTA를 기록했으며, 1,000회 이상의 연속 툴 호출 (Tool Calling) 데모 실적이 있다. 지시에 대한 충실도가 높아, 정해진 사양을 대량으로 처리해야 하는 구현 단계에 적합하다.

약점은 액티브 컨텍스트(Active Context)가 약 100K 토큰을 넘어가면 충실도가 떨어진다는 점이다. 긴 작업은 태스크를 분할해서 전달하는 것이 요령이다.

검색·그라운딩 (Grounding): Antigravity CLI (Gemini)

2026년 5월에 Gemini CLI를 대체한 Google의 Go 언어 제작 에이전트 CLI. Google 검색 그라운딩이라는 타사가 구조적으로 가질 수 없는 능력이 있어, "소스 URL이 포함된 사실 검증"을 던지기에 적합하다.

X 검색·속도 영역: Grok CLI

실시간 X 검색은 4사 중 유일한 독점 능력이다. 개발자의 생생한 목소리나 버즈(Buzz)의 온도를 파악하려면 이것이 유일한 선택지다. 게다가 생성 속도가 빨라, 이미지는 장당 5초 미만, 동영상 (Imagine Video 1.5 Fast)은 6초 720p를 약 25초 만에 생성한다.

이미지 생성만은 "서열"이 아니라 "용도 매트릭스"

3개사가 이미지 생성을 지원하고 있지만, 벤치마크를 해보면 일률적인 품질 서열로 나타나지 않았다. 축에 따라 승자가 바뀐다.

데모: 이 기사의 제작 로그

본 기사의 제작은 역할 분담을 그대로 실행하는 데모로서 진행되었다. 사령탑인 Claude Code 상에서 다른 3사의 CLI를 헤드리스 (Headless) 상태로 함수처럼 호출한다.

Claude Code (사령탑)
├─ grok -p "X 상의 4개 에이전트 CLI의 평판을 조사..." → 병렬 실행
├─ agy -p "이하의 사실관계를 소스 URL과 함께 검증..." → 병렬 실행
...

Grok이 수집해 온 X 상의 생생한 목소리

grok -p 명령 하나로, 단 몇 분 만에 2026년 6~7월 X 상의 개발자 포스트를 횡단 조사한 리포트가 돌아왔다. 요지는:

「어느 것이 가장 뛰어난가」보다 역할 분담이 상식화되어 있다. 가장 많이 인용되는 것은 「브레인스토밍·계획 = Claude Code, 구현 = Codex, 품질 보증 = 서로의 설계를 적대적 리뷰」라는 이분법적 템플릿("Claude = PM, Codex = Engineer"라는 표현도 정형화됨)이다. 나아가 7월에는 「실시간 조사와 일상적인 코딩 = Grok, 계획과 프론트엔드 = Fable 5, 난도 높은 구현 = Codex」라는 4역 세분화 워크플로우 게시물이 80만 뷰 이상을 기록했다. 본 기사의 분담 방식과 거의 동일한 형태이며, 독자적으로 같은 결론에 수렴하는 사람이 상당히 많은 것으로 보인다.

각 CLI(Command Line Interface)에 대한 불만의 공통 축도 흥미롭다. **전환 이유는 능력 차이보다 「이용 한도·속도·신뢰성」**이다. Claude는 "똑똑하지만 느리고 한도가 빨리 소진됨", Codex는 "실행력은 있지만 한도와 속도가 문제", Antigravity는 "빠르지만 깊이가 부족함 + 6/18 Gemini CLI 이전 쇼크", Grok은 "가장 빠르지만 지성이 거침" —— 각 사의 약점에 대한 평가가 그대로 역할 분담의 경계선이 되고 있다.

덧붙여 Grok에 대해서는 데이터 거버넌스(Data Governance)상의 지적(리포지토리 업로드 의혹)이 X(구 트위터) 상에서 확산되었던 점도 언급해 둔다. 진위 여부는 본 기사에서 검증하지 못했으나, 위임 대상에게 무엇을 넘길지는 분담 설계와는 별개의 축으로 생각해야 한다는 교훈을 준다.

Antigravity의 사실 검증 결과

기사 중의 주요 팩트 6개 항목을 Google 검색 그라운딩(Grounding)을 통해 검증하게 했다. 결과는 5개 항목이 ◎(확인), 1개 항목이 △였다.

△의 지적 내용이 정확하다는 점이 포인트로, 단순한 사실 확인을 넘어 주장의 정밀도 부족까지 잡아낸다. 그라운딩(Grounding) 역할로서 충분히 제 역할을 다했다. 반면, 부수적으로 조사하게 한 요금제 정보에는 실재 여부가 의심스러운 도구 이름이 섞여 있었다. 검색으로 확인 가능한 사실은 강력하지만, 지엽적인 정보는 역시 뇌(Brain) 측에서의 검증이 필요하다.

Codex의 도해 생성

서두의 역할 분담도는 Codex의 결과물이다. 3가지 태스크 중 가장 시간은 오래 걸렸지만(약 5분, Grok은 2분 미만), 동작이 용도 매트릭스의 주장을 그대로 실연해 주었다.

• 「일본어 라벨·색상 지정·1200×630」이라는 사양 엄수형 의뢰를 확산 모델(Diffusion Model)이 아닌 PIL을 이용한 코드 드로잉(Code Drawing)으로 자율적으로 전환함 - 폰트는 지시대로 Hiragino Kaku Gothic을 명시적으로 로드하여 일본어 글자 깨짐(Mojibake) 제로
• 생성 후 스스로 이미지를 다시 표시하여 가독성을 셀프 체크한 뒤 완료 보고

확산 모델 계열(Antigravity/Grok)에 이 도해를 맡기면 노드 수나 라벨 문자열이 프롬프트대로 되지 않는 경우가 많다. "문자·도표·사양 엄수는 Codex"라는 근거가 바로 이것이다.

번외편: 쇼츠 영상도 같은 분담으로 제작했다

이 기사의 홍보용으로 YouTube 쇼츠 버전(36초·세로형 1080×1920)도 동일한 역할 분담으로 제작했다.

제작 파이프라인은 다음과 같다.

Claude (사령탑)
├─ 콘티(5컷·36초)와 대본을 작성
├─ Grok에게 배경 소재를 위임
...

역할 분담의 관점에서 짚어두고 싶은 배움이 세 가지 있었다.

• 영상 생성도 Grok의 영역이다. 1개당 생성 시간은 25초 전후이며, 5개의 세로형 클립이 몇 분 만에 준비된다. 이번에는 정지 영상을 키 프레임(Keyframe)으로 하여 영상화했기에, 정지 영상 버전과 그림체의 연속성도 유지할 수 있었다.
• 문자는 영상 AI에게 그리게 하지 않는다. 자막(Telop)은 전부 PIL로 입혔다. 이미지 생성의 용도 매트릭스(문자·사양 엄수는 코드 드로잉)는 영상에서도 동일했다.
• 위임 대상 도구가 실패하더라도 에이전트 스스로 회피하는 경우가 있다. Grok Build의 내장 영상 도구는 이쪽의 환경 설정(Zero Data Retention) 때문에 실패했지만, /imagine-video로 의뢰하자 Grok 에이전트가 xAI의 API를 직접 호출하여 생성을 완수했다. "도구의 실패 = 능력의 한계"가 아니라는 점은 헤드리스 위임(Headless Delegation) 시 기억해 두어야 할 동작이다.

나레이션이 포함된 36초 완성본까지 사람이 한 일은 지시와 최종 확인뿐이었다. 소요된 실제 시간은 소재 생성 포함 약 30분 정도였다.

운용의 3원칙

병행 운용 속에서 정착된 원칙은 이것이다.

• 미니멈 위임 (Minimum Delegation) — 오케스트레이션 (Orchestration)의 주축은 항상 하나(뇌)로 고정하고, 타사 CLI는 "그 AI만이 할 수 있는 능력이 필요할 때만" 함수처럼 호출한다. 상주 세션이나 tmux 오케스트라를 구성하지 않는다. 관리 비용이 이득을 갉아먹기 때문이다.
• 컨텍스트는 전달되지 않는다는 전제 — 헤드리스 (Headless) 호출에서는 대화의 문맥이 전달되지 않는다. 지시문에 필요한 문맥을 모두 포함시키고, 결과만 받는다.
• 위임 결과는 맹신하지 않는다 — 이미지는 육안으로 확인하고, 정보는 요지의 타당성을 뇌(Brain) 측에서 검증한 뒤에 사용한다. 실제로 이번 데모에서도 Antigravity의 요금 조사에는 실존 여부가 의심스러운 도구 이름이 섞여 있었고, Grok의 조사에는 진위가 확인되지 않은 논란이 포함되어 있었다. 둘 다 뇌 측에서 걸러낸 뒤에 채택하고 있다.

요약

• 에이전트는 "최강의 하나"가 아니라 독점적 능력과 성격에 따라 분담한다.
  • 뇌 = Claude (재량이 강함 = 사령탑 적합), 손 = Codex (충실함 = 구현 적합), 검색 = Antigravity (그라운딩 (Grounding)), 속도·X = Grok
• 이미지 생성은 서열이 아니라 용도 매트릭스(Matrix)로 선택한다. 영상 생성은 Grok
• 분담 운용은 "미니멈 위임·문맥은 직접 채우기·결과는 검증"이라는 3원칙을 따른다.

이 분담 방식은 2026년 7월 시점의 것이다. 각사의 업데이트에 따라 세력도는 금방 변하므로, 정기적으로 벤치마크를 다시 수행하여 재검토하는 것을 추천한다.

Discussion