Gemini CLI를 처음 옆에 두면 자꾸 이런 생각이 든다.
이미 Codex도 있고 Claude Code도 있는데, 또 하나를 켜야 하나?
터미널이 무슨 AI 개발 도구 뷔페도 아니고.
근데 2026년 4월 기준 공식 문서를 놓고 보면 Gemini CLI는 그냥 “세 번째 코딩 에이전트”가 아니다.
역할을 잘 주면 꽤 분명한 자리가 있다.
Google Gemini CLI 공식 GitHub는 Gemini CLI를 터미널 안에서 Gemini를 직접 쓰는 오픈소스 AI agent라고 설명한다.
동시에 Gemini 3 모델의 1M token context window, Google Search grounding, 파일 작업, shell command, web fetching, MCP support를 핵심 장점으로 내세운다.
OpenAI Codex 문서는 다른 쪽을 강조한다.
Codex는 AGENTS.md, MCP, skills, automations, review, sandbox, session controls를 통해 팀 동료처럼 설정해서 쓰는 쪽에 가깝다.
그리고 Codex usage limit를 오래 쓰려면 prompt 크기, AGENTS.md, MCP 서버 수, 모델 선택을 줄이라는 기준도 공식 문서에 나온다.
Claude Code 문서는 또 다르다.
Claude Code subagents는 별도 context window, tool access, system prompt로 작업을 분리한다.
새 Claude Code 문서는 subagent별 MCP 서버 scope, 권한 모드, hooks, agent-based verifier까지 꽤 세밀하게 다룬다.
그래서 결론은 이렇다.
셋을 같은 일에 동시에 시키면 피곤하다.
하지만 셋을 서로 다른 층으로 나누면 꽤 강하다.
Gemini CLI는 넓게 읽고, Codex는 작업을 정리해 실행하고, Claude Code는 로컬 repo 안에서 깊게 고치고 검수하는 식이다.
이 글은 “Gemini CLI가 제일 좋다” 같은 랭킹 글이 아니다.
그런 글은 보통 읽는 순간 신나고, 다음날 실제 repo 앞에서 다시 멍해진다.
여기서는 TECHTAEK식으로 바로 쓸 수 있는 역할분리표를 만든다.
먼저 결론
Gemini CLI는 넓은 context와 검색·문서·MCP 탐색이 필요한 앞단에 두는 게 좋다.
Codex는 작업 단위 정리, 구현, 리뷰, AGENTS.md 기반 운영, 사용량 예산 관리에 둔다.
Claude Code는 로컬 repo에서 오래 이어지는 수정 루프, subagent, hooks, 권한 제어, 파일 단위 검수에 둔다.
이렇게 나누면 세 도구가 덜 싸운다.
사람도 회의에서 역할 안 나누면 서로 말 겹치는데, AI 에이전트라고 다르겠나.
역할 없이 세 개를 켜면 결과는 대체로 이렇다.
Gemini CLI가 큰 문서를 읽는다.
Codex도 같은 문서를 또 읽는다.
Claude Code도 같은 파일을 또 훑는다.
그리고 사용자는 “분명 자동화하려고 했는데 왜 내가 PM이 됐지?”라는 표정이 된다.
역할분리는 멋있는 아키텍처 놀이가 아니다.
토큰과 시간과 검수 피로를 줄이는 실무 기술이다.
세 도구의 기본 성격
공식 문서 기준으로 세 도구의 중심축을 먼저 나눠보면 이렇다.
| 도구 | 공식 문서에서 강하게 보이는 축 | 내가 맡기는 자리 |
|---|---|---|
| Gemini CLI | 1M token context, Google Search grounding, built-in tools, MCP, terminal-first | 넓은 자료 흡입, 문서 조사, 대안 탐색 |
| Codex | AGENTS.md, MCP, skills, automations, review, sandbox, session controls | 작업 계획, 구현, 리뷰, 사용량 예산 관리 |
| Claude Code | subagents, hooks, MCP scope, permission mode, local loop | 로컬 repo 수술, hooks 검수, 세밀한 권한 분리 |
이 표에서 중요한 건 “가능한 일”이 아니라 “맡기면 덜 피곤한 일”이다.
셋 다 코드를 읽을 수 있다.
셋 다 명령을 실행할 수 있다.
셋 다 MCP를 붙일 수 있다.
그래서 더 헷갈린다.
기능 목록만 보면 전부 비슷해 보인다.
하지만 운영 포인트는 다르다.
Gemini CLI는 넓은 context와 Google 생태계 연결을 앞세운다.
Codex는 작업 단위를 받아 구현하고 검증하고 리뷰하는 teammate 쪽 문서가 촘촘하다.
Claude Code는 로컬 터미널 안에서 subagent, hooks, permission을 엮는 운영감이 강하다.
이 차이를 못 잡으면 도구가 늘어날수록 생산성이 늘지 않고 의사결정만 늘어난다.
그럼 AI 도구를 샀는데 사람이 더 바빠지는 마법이 벌어진다.
마법이라기보단 그냥 세팅 미스다.
Gemini CLI가 맡기 좋은 일
Gemini CLI는 큰 자료를 먹이고 넓게 훑는 앞단에 두기 좋다.
Google Gemini CLI 공식 GitHub는 1M token context window와 Google Search grounding, 파일 작업, shell command, web fetching, MCP support를 장점으로 내세운다.
이 조합은 “내 repo의 특정 줄을 고쳐줘”보다 “관련 문서와 이슈와 파일을 넓게 읽고 후보를 줄여줘”에 먼저 어울린다.
예를 들면 이런 일이다.
| 상황 | Gemini CLI에 맡길 일 | 산출물 |
|---|---|---|
| 새 도구 조사 | 공식 문서, GitHub README, release note 훑기 | 기능 요약과 리스크 목록 |
| 큰 repo 구조 파악 | 디렉터리, 설정, 문서, 테스트 위치 찾기 | 변경 후보 파일 지도 |
| 외부 문서 비교 | Google docs, GitHub issue, API 문서 대조 | 근거 링크 포함 비교표 |
| MCP 탐색 | 어떤 MCP 서버와 도구가 필요한지 실험 | 필요한 서버와 제외할 서버 목록 |
| 대안 검수 | Codex나 Claude Code 결과를 다른 모델 관점에서 읽기 | 빠진 조건, 위험한 가정, 추가 테스트 |
Gemini CLI를 여기 두면 좋은 이유는 간단하다.
넓게 읽는 작업은 메인 구현 세션을 지저분하게 만든다.
문서 원문, GitHub issue, 긴 로그, 예외 사례가 한 번 들어오면 메인 세션의 context가 금방 뚱뚱해진다.
그리고 뚱뚱한 세션은 점점 느려지고, 가끔은 방금 정한 핵심 조건도 희미하게 잡는다.
Gemini CLI를 자료 흡입 계층으로 두면, 메인 구현 세션에는 요약과 판단만 넘길 수 있다.
즉 Gemini CLI의 산출물은 코드 diff가 아니라 handoff packet이면 좋다.
Codex가 맡기 좋은 일
Codex는 작업 단위를 받아 실제로 진행하고, 리뷰하고, 다시 고치는 teammate 역할에 잘 맞는다.
OpenAI Codex best practices 문서는 Codex를 일회성 챗봇보다 시간이 지나며 설정하고 개선하는 teammate처럼 다루라고 설명한다.
또 좋은 기본 프롬프트 요소로 목표, context, constraints, done when을 제안한다.
이건 역할분리에서 아주 중요하다.
Gemini CLI가 넓게 모은 자료를 그대로 Codex에 다 붙여넣으면 다시 context가 비대해진다.
대신 Codex에는 아래 네 가지만 넘긴다.
| 항목 | 내용 |
|---|---|
| Goal | 이번 변경의 목표 |
| Context | 꼭 필요한 파일, 문서, 이전 결정 |
| Constraints | 금지사항, 스타일, 보안, 성능 조건 |
| Done when | 테스트, 검수, 발행, 배포 등 완료 기준 |
OpenAI Codex pricing 문서는 usage limit를 오래 쓰려면 prompt 크기를 통제하고, AGENTS.md를 줄이고, MCP 서버 수를 제한하고, routine task는 작은 모델로 전환하라고 안내한다.
그래서 Codex는 “많이 읽는 곳”이 아니라 “정리된 일감을 처리하는 곳”으로 두는 편이 낫다.
Codex에 맡기기 좋은 일은 이렇다.
| 상황 | Codex에 맡길 일 | 이유 |
|---|---|---|
| 구현 시작 | 변경 계획 세우고 파일 수정 | repo 규칙과 테스트 루프를 함께 다루기 좋음 |
| PR 전 검수 | diff review, regression risk 찾기 | /review와 review 문서 흐름에 잘 맞음 |
| 반복 작업 | skill이나 automation으로 포장 | 반복 가능한 작업을 절차화하기 좋음 |
| 사용량 관리 | MCP, AGENTS.md, 모델 선택 줄이기 | 공식 문서가 usage budget 기준을 명확히 제시 |
| 긴 작업 관리 | /compact, /status, session controls |
context 비대를 운영적으로 다루기 좋음 |
Codex를 제대로 쓰려면 “다 알아서 해줘”보다 “여기까지가 일감이고, 여기까지 되면 끝”이 좋다.
AI한테도 퇴근 기준은 필요하다.
퇴근 기준 없는 작업은 사람도 산으로 가고 모델도 산으로 간다.
산은 주말에 가자.
Claude Code가 맡기 좋은 일
Claude Code는 로컬 repo 안에서 오래 이어지는 수정 루프와 권한 분리에 강하다.
Claude Code subagents 문서는 subagent가 별도 context window, 목적, 도구 권한, system prompt를 가진다고 설명한다.
새 문서에서는 subagent별 mcpServers, tools, disallowedTools, permissionMode, skills까지 꽤 구체적으로 나눈다.
특히 중요한 건 MCP server를 subagent에만 scope할 수 있다는 점이다.
메인 대화에는 MCP tool description을 계속 얹지 않고, 특정 subagent가 시작될 때만 붙였다가 끝나면 분리하는 방식이 가능하다.
이건 context hygiene 측면에서 꽤 크다.
Claude Code hooks 문서도 운영 포인트가 분명하다.
PreToolUse, PostToolUse, Stop, SubagentStop, TaskCompleted 같은 이벤트에 command, HTTP, MCP tool, prompt, agent hook을 붙일 수 있다.
agent hook은 파일이나 테스트 결과를 실제로 읽어야 하는 검증에 쓸 수 있다.
그러니 Claude Code는 아래 일에 잘 맞는다.
| 상황 | Claude Code에 맡길 일 | 이유 |
|---|---|---|
| 로컬 수술 | 특정 파일군의 세밀한 수정 | terminal loop와 permission mode가 자연스러움 |
| 격리 조사 | subagent로 로그·테스트·문서 읽기 | 긴 출력이 메인 context를 덜 오염시킴 |
| 권한 제한 | Read/Grep만 허용하는 연구 agent | 실수로 쓰기 작업을 막기 좋음 |
| MCP 분리 | browser/test MCP를 특정 subagent에만 연결 | 메인 context 비용을 줄이기 좋음 |
| 자동 검수 | Stop hook, PostToolUse hook, agent verifier | 완료 기준을 자동으로 확인하기 좋음 |
Claude Code는 “메인 구현자가 계속 붙잡고 고치는 느낌”이 강하다.
그래서 완전히 모르는 자료를 처음부터 끝까지 먹이는 것보다, 이미 정리된 작업을 로컬에서 깊게 다듬는 쪽이 편하다.
내 기준으로 Claude Code는 작업대다.
Gemini CLI는 넓은 책상 위 자료 조사 담당이고, Codex는 PM 겸 구현 리뷰어에 가깝다.
Claude Code는 손에 공구 들고 repo 안에서 직접 만지는 쪽이다.
역할분리표
바로 쓸 수 있게 표로 줄이면 이렇다.
| 작업 단계 | Gemini CLI | Codex | Claude Code |
|---|---|---|---|
| 아이디어 조사 | 공식 문서·GitHub·뉴스 넓게 스캔 | 조사 결과를 작업 단위로 재정리 | 필요 없음 |
| repo 이해 | 큰 파일 지도와 후보 영역 찾기 | 필요한 파일만 다시 읽고 계획화 | 특정 디렉터리 깊게 확인 |
| 구현 | 되도록 맡기지 않음, 대안 제안 정도 | 메인 구현 또는 패치 생성 | 로컬 세밀 수정, 리팩터링 |
| 테스트 | 테스트 전략 후보 제안 | 테스트 실행과 실패 수정 | hooks/subagent로 실패 로그 격리 |
| 검수 | 다른 모델 관점의 반론 | diff review, regression check | Stop hook, agent verifier |
| MCP | 필요한 MCP 후보 탐색 | 꼭 필요한 MCP만 활성화 | subagent별 MCP scope |
| context 관리 | 긴 자료를 요약해서 넘김 | AGENTS.md/MCP/prompt 경량화 | subagent로 긴 출력 격리 |
| 반복화 | 조사 템플릿 후보 | skill/automation으로 포장 | hooks와 agent 파일로 고정 |
여기서 핵심은 구현을 셋이 동시에 하지 않는 것이다.
한 파일을 세 도구가 동시에 고치면 검수자는 사람이 된다.
그 순간 자동화는 끝나고 중재가 시작된다.
그래서 구현 owner는 하나만 잡아야 한다.
나머지는 조사, 대안, 리뷰, 테스트로 돌린다.
handoff packet 템플릿
Gemini CLI에서 Codex나 Claude Code로 넘길 때는 아래 형식이 좋다.
## Goal
- 이번 작업의 최종 목표:
## Relevant Files
- 꼭 봐야 할 파일:
- 건드리면 안 되는 파일:
## Findings
- 공식 문서 근거:
- repo에서 확인한 패턴:
- 모호한 점:
## Constraints
- 스타일:
- 보안:
- 성능:
- 호환성:
## Suggested Plan
1. 먼저 할 일
2. 다음 할 일
3. 검수할 일
## Done When
- 테스트:
- 리뷰:
- 배포/발행:
이 정도면 충분하다.
중요한 건 원문 전체를 넘기지 않는 것이다.
Gemini CLI가 1M context를 쓸 수 있다고 해서 Codex나 Claude Code의 메인 세션까지 똑같이 살찌울 필요는 없다.
큰 냄비에 끓였다고 밥그릇까지 냄비로 먹진 않잖아.
요약해서 넘겨야 한다.
MCP는 세 도구에서 같은 의미가 아니다
MCP는 셋 다에서 나오지만 운영 의미가 조금씩 다르다.
Gemini CLI configuration 문서는 mcpServers로 MCP 서버를 연결하고, 각 서버의 tool을 mcp_서버명_도구명 형태의 FQN으로 구분한다고 설명한다.
또 includeTools, excludeTools, --allowed-mcp-server-names, --allowed-tools, approval mode 같은 제한 옵션이 있다.
Codex 문서는 MCP를 외부 context가 repo 밖에 있을 때 연결하는 표준으로 설명한다.
하지만 pricing 문서에서는 MCP를 많이 붙이면 메시지에 더 많은 context가 들어가고 limit를 더 쓴다고 분명히 경고한다.
Claude Code는 더 세밀하다.
subagent에만 MCP 서버를 inline으로 붙여서 메인 대화에는 도구 설명이 들어오지 않게 할 수 있다.
그래서 MCP 운영 기준은 이렇게 잡는 게 좋다.
| 목적 | 추천 위치 | 이유 |
|---|---|---|
| 새 MCP가 필요한지 실험 | Gemini CLI | 넓게 시도하고 후보를 좁히기 좋음 |
| 실제 구현에 필요한 외부 context | Codex | 작업 단위에 필요한 서버만 켜기 |
| 브라우저·테스트 같은 heavy tool | Claude Code subagent | 메인 context를 깨끗하게 유지하기 좋음 |
| 항상 필요한 팀 도구 | Codex 또는 Claude Code 설정 | 반복 workflow라면 durable config로 고정 |
| 가끔 쓰는 도구 | 세션별 enable | 기본 context를 무겁게 만들지 않음 |
MCP는 “연결하면 똑똑해지는 플러그인”이 맞다.
하지만 동시에 “연결하면 기본 짐이 늘어나는 플러그인”이기도 하다.
도구 목록이 늘면 모델은 그 도구들을 고려해야 한다.
설명도 읽어야 한다.
잘못된 도구를 고르지 않게 신경도 써야 한다.
그래서 MCP는 많이 붙이는 게 아니라 필요한 순간에 붙이는 쪽이 낫다.
1M context를 과신하면 생기는 문제
Gemini CLI의 1M token context window는 분명 매력적이다.
큰 문서와 큰 repo를 한 번에 읽을 수 있다는 건 실제로 강한 장점이다.
하지만 큰 context는 자동으로 좋은 판단을 보장하지 않는다.
오히려 자료가 너무 많으면 모델이 “모든 것을 조금씩 아는 상태”가 된다.
실무에서 필요한 건 모든 걸 읽은 모델보다, 지금 변경에 필요한 핵심을 정확히 들고 있는 모델일 때가 많다.
그래서 1M context의 좋은 사용법은 “최종 답을 길게 만들기”가 아니다.
좋은 사용법은 “넓게 읽고 짧게 줄이기”다.
| 나쁜 사용 | 좋은 사용 |
|---|---|
| 전체 문서를 그대로 구현 세션에 전달 | 핵심 조건과 링크만 handoff |
| 긴 로그 전체를 메인 thread에 붙임 | 실패 원인과 재현 명령만 요약 |
| GitHub issue 20개를 그대로 복붙 | 공통 원인과 예외 케이스만 정리 |
| 세 도구가 같은 자료를 반복 조사 | Gemini CLI가 조사하고 Codex/Claude가 실행 |
큰 context는 흡입용이다.
메인 구현 context는 소화용이다.
소화 안 된 자료를 계속 밀어 넣으면 모델도 배부르다.
그리고 배부른 모델은 가끔 졸린 답을 한다.
실제 워크플로 예시
예를 들어 새 오픈소스 라이브러리를 도입한다고 해보자.
Gemini CLI에는 이렇게 맡긴다.
공식 README, docs, issue, release note를 훑고
우리 repo에 도입할 때 필요한 조건과 위험을 20줄로 줄여줘.
반드시 source URL을 붙이고, 구현 세션에 넘길 handoff packet으로 정리해줘.
Gemini CLI의 결과가 오면 Codex에 넘긴다.
아래 handoff packet 기준으로 우리 repo에 최소 변경으로 적용해줘.
불확실한 부분은 가정으로 표시하고,
완료 기준은 테스트 통과와 diff review까지야.
Codex가 구현하면 Claude Code나 Codex review에 검수를 시킨다.
이 diff를 regression 관점으로 검토해줘.
특히 보안, backward compatibility, 설정 누락, test gap만 봐줘.
새 구현은 하지 말고 finding만 반환해줘.
Claude Code를 쓰는 repo라면 subagent를 read-only로 제한해 실패 로그만 읽게 할 수도 있다.
Use a read-only test-log subagent.
Run the failing test, read only the relevant output,
and return the smallest suspected cause.
Do not edit files.
이 구조의 핵심은 단순하다.
조사와 구현과 검수를 한 세션에 다 넣지 않는다.
자료를 많이 읽는 모델과 파일을 고치는 모델과 결과를 의심하는 모델을 나눈다.
이게 세 도구를 같이 쓸 때 제일 덜 피곤한 방식이다.
언제 Gemini CLI를 켜지 말아야 하나
Gemini CLI가 좋은 도구여도 매번 켤 필요는 없다.
아래 상황이면 굳이 켜지 않아도 된다.
| 상황 | 이유 |
|---|---|
| 바꿀 파일이 이미 명확함 | 넓은 조사 비용이 낭비 |
| 공식 문서가 필요 없음 | 외부 context 장점이 작음 |
| 변경이 10줄 안쪽 | handoff 비용이 더 큼 |
| 기존 테스트가 바로 실패 원인을 말함 | 먼저 실패 로그를 보면 됨 |
| repo 규칙이 이미 AGENTS.md에 잘 정리됨 | Codex나 Claude Code가 바로 처리 가능 |
Gemini CLI는 큰 망원경처럼 쓰면 좋다.
하지만 책상 위 나사 하나 조일 때 망원경 들고 오면 이상하다.
작은 작업은 작은 루프로 끝내자.
언제 Codex를 메인으로 두나
Codex를 메인으로 둘 때는 조건이 있다.
작업 목표가 비교적 명확하고, 완료 기준을 적을 수 있고, 검수 루프까지 맡기고 싶을 때다.
특히 AGENTS.md가 잘 정리된 repo라면 Codex가 팀 규칙을 따라가기가 좋다.
OpenAI 문서도 AGENTS.md를 durable guidance로 설명한다.
다만 너무 긴 AGENTS.md는 usage limit와 품질 양쪽에서 부담이 될 수 있다.
그래서 Codex 메인 작업 전에는 아래를 확인한다.
| 체크 | 질문 |
|---|---|
| Goal | 이번에 진짜 바꿀 것은 한 문장으로 말할 수 있나 |
| Scope | 건드릴 파일 범위가 좁혀졌나 |
| Rules | AGENTS.md가 필요한 규칙만 담고 있나 |
| MCP | 지금 작업에 꼭 필요한 MCP만 켜져 있나 |
| Done | 테스트나 리뷰 완료 기준이 있나 |
이 다섯 개가 있으면 Codex는 꽤 편하다.
없으면 Codex가 알아서 길을 찾긴 하는데, 그 길이 사용자가 원한 길인지 나중에 확인해야 한다.
확인해야 할 게 늘면 자동화 이득이 줄어든다.
언제 Claude Code를 메인으로 두나
Claude Code는 repo 안에서 길게 붙잡고 가는 작업에 좋다.
예를 들어 여러 파일을 건드리지만, 외부 자료보다 로컬 context가 중요한 작업이다.
또 hooks나 permission mode를 붙여 작업 완료 조건을 자동으로 확인하고 싶을 때도 좋다.
Claude Code subagent 문서는 main conversation과 subagent를 나누는 기준도 제시한다.
빠르고 타깃이 좁은 변경, 자주 왕복해야 하는 작업, 여러 단계가 같은 context를 공유해야 하는 작업은 main conversation이 낫다.
반대로 긴 출력, 테스트 로그, 문서 fetch, 대량 파일 분석은 subagent로 격리하기 좋다.
이 기준은 Codex나 Gemini CLI를 쓸 때도 그대로 쓸 수 있다.
도구가 달라도 context 오염 문제는 비슷하다.
Claude Code를 메인으로 두는 기준은 이렇다.
| 조건 | 이유 |
|---|---|
| 로컬 repo 수정이 중심 | 터미널 루프가 자연스러움 |
| 권한 제어가 중요 | tool allowlist/denylist와 permissionMode가 유용 |
| hooks로 완료를 막고 싶음 | Stop/PostToolUse/agent hook을 붙이기 좋음 |
| subagent별 MCP가 필요 | 메인 context를 가볍게 유지 가능 |
| 조사보다 수술이 중요 | 실제 파일 수정에 집중하기 좋음 |
검수 역할은 반드시 분리하자
AI 에이전트가 만든 결과를 같은 에이전트가 “괜찮다”고 말하는 건 참고는 되지만 충분하진 않다.
특히 같은 context에서 같은 가정을 공유하고 있으면, 실수도 공유한다.
그래서 검수 역할은 가능한 한 분리한다.
| 만든 쪽 | 검수 쪽 | 검수 포인트 |
|---|---|---|
| Codex | Claude Code subagent | 로컬 파일, 테스트, 권한 |
| Claude Code | Codex review | diff risk, regression, PR 관점 |
| Gemini CLI 조사 | Codex | handoff가 실행 가능한지 |
| Codex 구현 | Gemini CLI | 공식 문서 해석이 빠졌는지 |
검수 prompt는 짧을수록 좋다.
“전체적으로 봐줘”는 너무 넓다.
대신 이렇게 준다.
새 구현은 하지 말고 finding만 줘.
보안, 회귀, 테스트 누락, 문서 근거 불일치만 봐.
확실하지 않으면 assumption으로 표시해.
이렇게 하면 검수자가 갑자기 구현자로 변신하는 일을 줄일 수 있다.
AI 에이전트는 친절해서, 자꾸 도와주려고 한다.
그래서 “도와주지 말고 의심만 해”라고 말해줘야 할 때가 있다.
묘하게 인간 조직 같다.
TECHTAEK 운영 기준
내 기준으로 TECHTAEK 작업에 세 도구를 놓으면 이렇게 쓴다.
| 작업 | 1순위 | 2순위 | 이유 |
|---|---|---|---|
| 새 AI 도구 글감 수집 | Gemini CLI | Codex | 공식 문서와 GitHub를 넓게 읽기 |
| 글 구조 잡기 | Codex | Gemini CLI | goal, context, done when으로 압축 |
| 로컬 글 작성 | Codex | Claude Code | 블로그 규칙과 preflight 처리 |
| 기술 검수 | Gemini CLI | Codex | 공식 문서 누락 확인 |
| 파일·스크립트 수정 | Claude Code or Codex | 없음 | owner를 하나로 고정 |
| 발행 전 QC | Codex | Claude Code | diff, preflight, publish contract |
블로그 작업도 결국 소프트웨어 작업과 비슷하다.
자료 조사, 본문 작성, 검수, 발행, 후속 링크가 있다.
이걸 한 세션에 다 몰아넣으면 context가 금방 찬다.
그래서 조사 결과는 짧게 남기고, 본문에는 공식 근거와 운영 판단만 남긴다.
관련 글
이미 TECHTAEK에서 Gemini CLI subagents 자체는 따로 다뤘다.
Gemini CLI subagents는 언제 쓰고 언제 위험한가 2026는 context 분리, usage limit, 편집 충돌에 초점을 맞춘 글이다.
Codex 사용량 쪽은 Codex에서 MCP 서버를 줄이면 진짜 사용량이 오래 갈까 2026를 보면 된다.
Claude Code subagents 쪽은 Claude Code subagents는 언제 켜고 언제 메인 세션으로 끝내야 할까 2026에서 context bloat와 병렬작업 기준을 정리했다.
이번 글은 그 셋을 한 워크플로 안에 놓는 연결 글이다.
FAQ
Q1. Gemini CLI가 1M context면 Codex나 Claude Code가 필요 없나?
아니다.
1M context는 넓게 읽는 데 강한 장점이지, 모든 작업의 최종 실행자를 의미하진 않는다.
작은 변경, 테스트 수정, repo 규칙 준수, PR review, hooks 검수는 Codex나 Claude Code가 더 자연스러운 경우가 많다.
Q2. 셋 중 하나만 써야 한다면 무엇을 고르면 되나?
작업 대부분이 로컬 repo 수정이면 Codex나 Claude Code 중 하나를 메인으로 고르는 게 편하다.
외부 문서와 큰 자료를 많이 읽는 날에는 Gemini CLI가 앞단에서 빛난다.
하나만 고르는 문제보다, 오늘 작업의 병목이 조사인지 구현인지 검수인지 먼저 보는 게 낫다.
Q3. MCP는 세 도구에 모두 똑같이 붙이면 되나?
아니다.
Codex 문서는 MCP가 context와 usage limit를 더 쓴다고 안내한다.
Gemini CLI와 Claude Code도 MCP 도구 설명과 권한이 작업 context에 영향을 준다.
항상 켜는 MCP는 최소화하고, heavy MCP는 가능하면 특정 세션이나 subagent에만 붙이는 편이 좋다.
Q4. Gemini CLI는 구현에 쓰면 안 되나?
쓸 수 있다.
다만 세 도구를 함께 쓰는 운영에서는 Gemini CLI를 넓은 조사와 대안 검수에 두는 편이 역할이 덜 겹친다.
이미 Gemini CLI 하나로만 일하는 환경이라면 구현까지 맡겨도 된다.
이 글의 기준은 “Codex·Claude Code 옆에 둘 때”의 분업 기준이다.
Q5. Claude Code subagent와 Codex subagent는 같은 개념인가?
큰 방향은 비슷하지만 제품별 구현과 운영 단위가 다르다.
Claude Code 문서는 subagent별 tool access, MCP scope, permission mode, hooks 연동을 아주 구체적으로 설명한다.
Codex 문서는 subagent workflow와 session controls, review, AGENTS.md, MCP usage budget이 더 중심에 보인다.
그래서 이름이 비슷해도 같은 설정을 복붙하면 안 된다.
Q6. 실제로 가장 먼저 바꿀 습관은 뭐냐?
조사 결과를 통째로 구현 세션에 넣지 않는 것이다.
Gemini CLI든 브라우저든 검색이든, 자료 흡입 단계가 끝나면 handoff packet으로 줄여서 넘겨라.
이 습관 하나만 잡아도 Codex와 Claude Code의 context bloat가 꽤 줄어든다.
공식 출처/참고 자료
- Google Gemini CLI GitHub, google-gemini/gemini-cli, Gemini CLI의 1M token context window, built-in tools, MCP support, terminal-first 설명.
- Google Gemini CLI docs, Configuration reference,
mcpServers,includeTools,excludeTools,--allowed-mcp-server-names, approval mode 기준. - Google Gemini CLI docs, Commands reference,
/mcp,/memory,/stats,/tools명령 기준. - OpenAI Developers, Codex best practices, Codex를 teammate처럼 설정하고
AGENTS.md, MCP, skills, automations, review를 쓰는 기준. - OpenAI Developers, Codex pricing – usage limits tips, prompt size,
AGENTS.md, MCP server, smaller model 사용량 절약 기준. - Claude Code Docs, Create custom subagents, subagent context, tools, MCP scope, permission mode, main conversation과 subagent 선택 기준.
- Claude Code Docs, Hooks reference, PreToolUse, PostToolUse, Stop, SubagentStop, prompt hook, agent hook 기준.
마무리
Gemini CLI를 Codex와 Claude Code 옆에 둘 때 핵심은 “하나 더 켠다”가 아니다.
역할을 바꾸는 것이다.
Gemini CLI는 넓게 읽고 줄인다.
Codex는 정리된 작업을 실행하고 리뷰한다.
Claude Code는 로컬 repo 안에서 깊게 고치고 권한과 hooks로 검수한다.
이렇게 나누면 세 도구가 서로를 방해하지 않는다.
반대로 역할 없이 세 개를 전부 켜면, 사용자는 어느새 에이전트 관리자 역할을 하게 된다.
그것도 나쁘진 않지만, 원래 목표는 내 일이 줄어드는 거였다.
AI 도구도 팀처럼 굴려야 한다.
좋은 팀은 사람이 많아서 좋은 게 아니라, 누가 뭘 맡는지 선명해서 좋다.
Gemini CLI, Codex, Claude Code도 똑같다.
넓게 읽는 애, 실행하는 애, 의심하는 애.
이 셋만 나눠도 2026년 AI 개발 워크플로는 훨씬 덜 정신없어진다.