AI 코딩 에이전트(AI Coding Agent)를 사용할 때, 품질을 높이는 방법은 "좋은 모델을 선택하는 것"만이 아닙니다. 오히려 실무에서는 언제 멈출 것인가, 어느 단계에서 다른 관점을 투입할 것인가가 더 효과적입니다.

최근의 Claude Code나 Codex에는 /plan, /review, /advisor, subagent, auto mode / auto review 등 품질을 높이기 위한 메커니나즘이 늘어나고 있습니다. 다만 이름이 비슷하더라도 역할은 상당히 다릅니다.

이 기사에서는 Plan · Advisor · Review를 "품질 향상을 위한 개입 방법"으로 정리합니다. 그 후, Claude Code와 Codex에서는 어떤 기능이 대응하고, 어떤 부분은 대응하지 않는지 살펴보겠습니다. 내용은 2026-06-07 시점의 공식 문서를 확인하며 작성되었습니다.

먼저 결론부터

팀, 프로젝트, 규모에 따라 다를 수 있지만, 품질을 높이기 위한 활용법은 다음과 같다고 생각합니다.

Claude Code와 Codex의 차이는 이 4가지를 어떻게 제공하느냐에서 나타납니다. Claude Code는 /advisor나 /review 등이 있어, 동일한 세션에서 작업하면서 중간에 개입하기 쉽습니다. Codex는 /plan, /review, subagent, /fork를 조합하여 작업을 분해함으로써 품질을 높이는 형태가 됩니다.

품질을 높이는 수법은 "언제 멈추는가"로 나눈다

plan, review, advisor는 모두 품질을 높이기 위한 메커니즘이지만, 효과가 나타나는 타이밍이 다릅니다.

이 4가지는 대체 관계가 아닙니다. 오히려 역할이 다릅니다.

**Plan은 "만들기 전의 품질"**입니다. 아직 코드를 작성하지 않은 단계에서, 어디를 건드릴지, 무엇을 망가뜨릴 것 같은지, 어떻게 확인할지를 결정합니다. 사양이 모호할수록 효과적입니다.

**Advisor는 "만드는 도중의 품질"**입니다. 구현 중에 판단이 불확실해진 타이밍에 다른 관점을 투입합니다. Claude Code의 /advisor가 이 위치에 해당합니다. Codex에는 동등한 내장 /advisor가 없기 때문에, subagent나 /fork를 통해 수동으로 advisor 역할을 만듭니다.

**Review는 "만든 후의 품질"**입니다. 구현자와는 다른 눈으로 차이(diff)를 확인합니다. AI 에이전트에게 구현을 시켰을 경우, 동일한 대화의 연장선상에서 "문제없습니다"라고 말하게 하기보다는, 리뷰용 커맨드나 별도의 subagent에게 보여주는 것이 적합합니다.

**Auto review / auto mode는 "실행 경계의 품질"**입니다. 이것은 코드의 좋고 나쁨을 보는 것이 아닙니다. 위험한 커맨드나 권한을 넘나드는 조작을 실행 직전에 멈추기 위한 메커니즘입니다.

저는 품질을 높이고 싶을 때 다음 순서로 사용하고 있습니다.

1. Plan: 먼저 구현 계획을 세운다
2. Advisor: 불확실한 판단만 중간에 상담한다
3. Review: 구현 후에 차이(diff)를 확인한다
...

모두를 매번 사용할 필요는 없습니다. 작은 수정이라면 review만으로 충분합니다. 큰 변경, 설계 판단을 포함하는 변경, 외부 서비스나 인증을 건드리는 변경에서는 plan과 review를 나누는 것이 안정적입니다.

/plan은 양쪽 모두에 있다

먼저 헷갈리는 것이 /plan입니다. Claude Code에도 Codex에도 있습니다.

Claude Code의 커맨드 목록에서는 /plan [description]은 "plan mode에 진입하는" 커맨드로 설명되어 있습니다. 큰 변경 전에 /plan을 사용하여 구현 전에 방침을 내놓게 하는 방식입니다.

Codex의 CLI에서도 /plan은 plan mode로 전환하는 커맨드입니다. 복잡하고, 모호하며, 설명하기 어려운 태스크에서는 구현 전에 계획을 세우게 합니다.

같은 /plan이라도 저는 조금 나누어 사용하고 있다고 생각합니다만, 프로젝트에 따라 다를 수 있습니다.

Claude Code의 /plan

/plan 인증 관련 설계를 재검토해줘. 구현은 아직 하지 마.

이미 대화를 나누며 작업하던 중, "여기서 크게 수정하기 전에 일단 멈추기" 위해 사용합니다. 처음에 "구현은 아직 하지 마"라고 명시합니다.

Codex의 /plan

/plan 이 리포지토리의 결제 처리를 조사해서 이행 계획을 세워줘. 아직 파일은 변경하지 마.

Codex에서는 처음부터 계획 모드 (plan mode)로 시작하는 경우가 많습니다. 조사, 질문, 변경 범위, 검증 방법을 먼저 수행하게 한 뒤 구현에 들어갑니다. 변경 사항이 클수록 초기 계획이 효과적입니다.

/agent와 /agents는 다르다

이 부분도 이름이 비슷합니다.

Codex CLI의 /agent는 생성(spawn)된 서브 에이전트 (subagent)의 스레드로 전환하기 위한 명령어입니다. 서브 에이전트가 작동 중일 때, 해당 스레드를 확인하거나 다음 지시를 내릴 수 있습니다.

Codex의 서브 에이전트는 공식 문서상에서 "명시적으로 요청했을 때만 생성(spawn)한다"라고 설명되어 있습니다. 예를 들어 다음과 같이 요청합니다.

이 PR을 3가지 관점에서 리뷰해줘.
보안, 테스트 부족, 유지보수성에 대해 각각 별도의 subagent를 세워서 조사해.
모든 결과가 모이면 파일 참조를 포함해서 요약해줘.

이 방식은 리뷰에 적합합니다. 조사 로그나 테스트 로그를 메인 대화에 흘려보내지 않고, 각 서브 에이전트가 확인하게 한 뒤 마지막에 요약만 받을 수 있습니다.

반면 Claude Code는 /agents입니다. 이것은 서브 에이전트 관리 화면을 여는 명령어입니다. Claude Code의 문서에 따르면, 서브 에이전트는 각각 독립된 컨텍스트 윈도우 (context window), 커스텀 프롬프트 (custom prompt), 도구 권한 (tool permissions), 독립된 권한 (independent permissions)을 갖는다고 설명되어 있습니다.

Claude Code에는 내장된 서브 에이전트 (built-in subagents)로서 Explore, Plan, general-purpose 등이 있으며, Claude가 필요에 따라 위임합니다. 예를 들어 계획 모드 (plan mode) 중의 조사에서는 Plan subagent가 사용됩니다.

이 차이는 꽤 큽니다.

Claude Code는 "알아서 잘 분담해줘"라는 방식에 가깝습니다. Codex는 "이 관점별로 나누어서 마지막에 통합해줘"라고 명시하는 것이 더 강력합니다.

/advisor에 해당하는 것은 Codex에 없다

Claude Code에는 /advisor가 있습니다. 배경에는 Anthropic의 Advisor tool이 있으며, 빠른 실행 모델 (executor model)이 더 강력한 어드바이저 모델 (advisor model)에게 도중에 상담하는 구조입니다. Anthropic의 API 문서에 따르면, advisor는 전체 대화 (full conversation)를 읽고 계획이나 궤도 수정을 반환하며, 그 후 executor가 작업을 계속한다고 설명되어 있습니다.

이러한 의미에서의 /advisor는 Codex에 없습니다. Codex의 공식 문서와 현재 매뉴얼 (manual)을 확인한 범위 내에서는 /advisor라는 슬래시 명령어 (slash command)를 찾을 수 없었습니다.

유사한 용도는 있지만, 역할이 다릅니다.

Codex에서 /advisor와 같은 일을 하고 싶다면, 수동으로 'advisor 역할'을 설정하는 것이 현실적입니다.

현재 구현 방침을 advisor 역할의 subagent에게 리뷰하게 해줘.
advisor는 파일을 편집하지 말고, 설계 리스크·간과한 점·테스트 부족 사항만 지적해줘.
그 결과를 읽은 다음에 구현을 진행해.

또는, 현재 대화에서 분기하여 다른 안을 검토하고 싶다면 /fork가 유사합니다.

/fork 현재 계획을 비판적으로 리뷰해줘. 구현은 하지 말고, 대안과 리스크만 알려줘.

단, 이것은 Claude Code의 /advisor와 동일하지는 않습니다. Claude의 Advisor tool은 executor가 작업 중에 강력한 advisor model을 호출하는 설계입니다. Codex의 경우에는 /plan으로 먼저 생각하게 하거나, /review로 나중에 확인하거나, subagent 또는 /fork로 옆에서 의견을 구하는 방식의 조합이 됩니다.

/review와 auto_review의 차이

Claude Code에는 /review가 있습니다. 공식 명령어 목록에서는 /review [PR]이 현재 세션 내에서 pull request를 로컬 리뷰하는 명령어라고 설명되어 있습니다. 이와 관련하여 /code-review, /security-review, /ultrareview도 있습니다.

반면, Claude Code에서 /auto_review라는 슬래시 명령어 (slash command)는 찾아볼 수 없습니다. 유사한 이름으로는 auto mode가 있지만, 이는 리뷰 명령어가 아닙니다. Claude Code의 auto mode는 권한 프롬프트 (permission prompt)를 줄이기 위한 실행 모드로, 각 tool call을 classifier model에 통과시켜 위험해 보이는 조작을 차단하는 메커니즘입니다.

Codex의 auto_review 역시 일반적인 코드 리뷰나 advisor와는 별개의 것입니다. Codex에서는 approvals_reviewer = "auto_review"와 같이 설정하면, 승인이 필요한 조작을 사용자가 아닌 reviewer agent에게 보여주는 구성이 됩니다. 이는 "이 설계로 괜찮은지 상담하는" 기능이 아니라, sandbox boundary에서의 승인 리뷰입니다.

정리하면 다음과 같습니다.

즉, Claude Code에 /review는 있습니다. /auto_review

없습니다. Claude Code에서 유사한 것은 auto mode이며, Codex에서 유사한 것은 approvals_reviewer = "auto_review"입니다. 다만, 둘 다 /advisor의 대체재는 아닙니다.

CLAUDE.md와 AGENTS.md 지시 파일

Claude Code는 CLAUDE.md를 읽습니다. 프로젝트의 규칙, 빌드 명령어, 자주 발생하는 주의사항을 적는 곳입니다. CLAUDE.md는 세션 시작 시에 읽힙니다.

Codex는 AGENTS.md를 읽습니다. 글로벌, 프로젝트, 서브 디렉토리별 지시 사항을 계층적으로 읽으며, 가까운 위치의 지시 사항일수록 우선순위가 높습니다.

두 가지를 모두 사용한다면, 동일한 내용을 이중으로 관리하지 않는 것이 편합니다. Claude Code 문서에서는 이미 AGENTS.md가 있는 리포지토리(Repository)의 경우, CLAUDE.md에서 import 하는 방법이 소개되어 있습니다.

@AGENTS.md
## Claude Code
UI를 변경할 때는 먼저 스크린샷으로 확인한다.

이렇게 하면 공통 규칙은 AGENTS.md에 두고, Claude Code에만 필요한 보충 설명을 CLAUDE.md에 작성할 수 있습니다.

Claude Code가 적합한 작업

Claude Code는 동일한 흐름 속에서 계속해서 손을 움직이며 수행하는 작업에 적합합니다.

예를 들어 프론트엔드 조정 작업입니다. 처음에 계획을 세우게 하고, 구현하고, 실행하고, 화면을 보고, 다시 수정하는 과정입니다. 이 루프(Loop)에서는 Claude Code를 사용하는 것이 더 자연스럽습니다.

이 화면의 레이아웃을 재검토하고 싶어.
먼저 변경 방침만 제시해줘. 코드는 아직 건드리지 마.

방침이 괜찮다면 그대로 진행합니다.

그 방침대로 구현해줘.
끝나면 로컬에서 실행해서 표시 오류가 없는지 확인해줘.

Claude Code에는 /run이나 /verify와 같은 번들 기능(Bundled skills)이 있어, 실행 중인 앱을 확인하는 방향의 기능이 늘어나고 있습니다. UI, 디버깅(Debugging), 테스트 수정처럼 대화하며 상태를 확인하며 진행하는 작업에서 궁합이 좋습니다.

다만, 의욕이 앞서 바로 구현에 들어가는 경우가 있습니다. 규모가 큰 변경을 할 때는 처음에 다음과 같이 제어해야 합니다.

먼저 조사와 계획만 세워줘.
파일 편집, 명령어 실행, 의존성(Dependency) 추가는 아직 하지 마.

Claude Code에는 "먼저 계획을 확정한 뒤에 구현한다"라고 명시하는 것이 재작업(Backtrack)을 줄이는 방법입니다.

Codex가 적합한 작업

Codex는 작업을 분해한 뒤에 진행할 때 사용하기 쉽습니다.

특히 다음과 같은 상황에 적합합니다.

• 영향 범위가 넓은 변경
• 기존 코드 조사
• 보안 및 설계 리뷰(Review)
• 테스트 방침을 포함한 구현 계획
• 여러 관점을 병렬로 보고 싶은 작업

첫 번째 프롬프트(Prompt)는 구현 요청이 아니라 조사 요청으로 합니다.

/plan
이 리포지토리의 인증 처리를 조사해서 세션 관리를 변경할 계획을 세워줘.
다음 내용을 포함해줘.
...

계획을 확인한 뒤, 필요하다면 서브에이전트(Subagent)로 나눕니다.

이 계획을 바탕으로 3개의 서브에이전트가 병렬로 조사해줘.
1. 기존 인증 플로우
2. 테스트 부족 사항
...

Codex의 서브에이전트는 명시적으로 요청해야 하므로, 분담 내용을 작성하는 것이 안정적입니다. 반대로 말하면, "멋대로 확장되는" 느낌이 적어 리뷰나 조사 시 다루기 쉽습니다.

활용 사례 비교

신기능 만들기

저는 우선 Codex로 계획을 세우는 것이 좋다고 생각하지만, 프로젝트 규모에 따라 다를 수 있습니다.

/plan 알림 설정 화면을 추가하고 싶어.
기존 설정 화면, API, 상태 관리(State management)를 조사해서 구현 계획을 세워줘.
아직 편집은 하지 마.

계획이 확정되면 구현은 Claude Code로 진행해도 좋습니다. 특히 화면이 있는 경우에는 구현 후의 외관 확인이 필요하기 때문입니다.

이 계획에 따라 알림 설정 화면을 구현해줘.
기존 UI 컴포넌트를 우선적으로 사용해줘.
완료 후에 실행해서 표시를 확인해줘.

기존 코드 리뷰하기

리뷰는 Codex에 맡깁니다.

이 브랜치(Branch)를 리뷰해줘.
서브에이전트를 3개 세워서 정확성, 보안, 테스트 부족 사항을 각각 따로 봐줘.
마지막에 중요도 순으로 정리해줘.

리뷰는 관점을 나누기 쉬워 병렬화의 이점을 얻을 수 있습니다. 대량의 로그나 탐색 결과가 메인 대화에 섞이지 않는 것도 장점입니다.

원인 불명의 버그를 추적하기

이는 상황에 따라 다릅니다.

로그가 많고, 영향 범위가 넓으며, 가설이 여러 개라면 Codex로 조사를 분리합니다.

실패하는 테스트의 원인을 조사해줘.
subagent를 2개 사용해서, 한쪽은 최근의 차이점(diff)을, 다른 한쪽은 관련 있는 기존 구현을 봐줘.
수정은 아직 하지 마.

반면, 재현 절차가 있고 수동으로 여러 번 실행하며 수정한다면 Claude Code가 진행하기 더 수월합니다.

이 테스트를 재현하고 원인을 조사해줘.
수정안을 제시한 다음 구현해줘.
구현 후에 동일한 테스트를 다시 한번 실행해줘.

규칙을 준수하게 만들기

공통 규칙은 AGENTS.md에 모읍니다.

# AGENTS.md
## 작업 규칙
- 구현 전에 변경 대상 파일을 나열한다
...

Claude Code도 사용한다면 CLAUDE.md에서 import 합니다.

@AGENTS.md
## Claude Code 전용
- 큰 변경 사항에서는 `/plan`부터 시작한다
...

이렇게 하면 Codex와 Claude Code 모두에게 동일한 기본 방침을 읽게 할 수 있습니다.

하나만 선택할 필요는 없다

"Claude Code와 Codex 중 어느 것이 더 우월한가"가 아니라, 작업의 단계(phase)에 따라 나누는 것이 더 실용적입니다.

저의 실무 경험상, 다음과 같이 진행하는 것이 좋다고 생각합니다.

1. Codex: /plan으로 조사와 구현 계획을 세운다
2. Codex: 필요하다면 subagent로 관점별 리뷰를 수행한다
3. Claude Code: 구현과 로컬 확인을 진행한다
...

물론 전부 Claude Code로 해도 되고, 전부 Codex로 해도 괜찮습니다. 다만, 변경 사항이 클수록 "계획", "구현", "확인", "리뷰"를 하나의 대화에 너무 많이 담으면 문맥(context)이 무거워지는 경향이 있을 수 있습니다.

Claude Code는 대화하며 만들어가는 작업에 적합하다고 생각합니다. Codex는 작업을 분해하여 안전하게 맡기는 작업에 적합하다고 생각합니다. 이러한 전제로 구분해서 사용하면 /plan이나 /agent의 의미도 더 명확해질 것입니다.

Discussion