Codex와 Claude Code, AI 개발 에이전트의 진짜 경쟁

비교의 출발점: 더 좋은 도구가 아니라 더 나은 운영 방식

Codex와 Claude Code를 비교할 때 가장 쉬운 길은 기능표를 만드는 것이다. 어느 쪽이 터미널에서 잘 도는지, 어느 쪽이 긴 문맥을 더 잘 다루는지, 어느 쪽이 리팩터링을 더 안정적으로 하는지 나열할 수 있다. 그러나 실무자가 지금 던져야 할 질문은 조금 다르다. “무엇이 더 좋은가”보다 “어떤 작업 흐름에 어떤 권한으로 넣을 것인가”가 더 중요하다.

AI 코딩 도구의 초기 경쟁은 자동완성, 코드 생성, 테스트 코드 초안 작성에 가까웠다. 지금의 AI 개발 에이전트는 더 넓다. 코드베이스를 읽고, 파일을 고치고, 명령어를 실행하고, 테스트를 돌리고, 외부 개발 도구와 연결된다. Claude Code 공식 문서는 Claude Code를 코드베이스를 읽고, 파일을 편집하고, 명령어를 실행하며, 개발 도구와 통합되는 에이전트형 코딩 도구로 설명한다. Codex CLI 공식 문서도 Codex가 선택한 디렉터리에서 코드를 읽고, 바꾸고, 실행할 수 있는 로컬 터미널용 코딩 에이전트라고 설명한다. 출처: Overview – Claude Code Docs, Codex CLI – OpenAI Developers

이 변화는 단순한 편의 기능 확대가 아니다. 개발 조직의 책임 구조를 흔든다. 에이전트가 파일을 고치고 명령어를 실행할 수 있다면, 그 순간부터 이 도구는 “코드 제안기”가 아니라 제한된 실행 권한을 가진 작업자다. 작업자에게는 업무 범위, 승인선, 로그, 검수 기준, 실패 시 되돌릴 절차가 필요하다. AI 개발 에이전트 경쟁의 본질은 여기서 시작된다.

Codex와 Claude Code는 무엇을 다르게 상상하는가

두 도구 모두 에이전트형 개발을 지향하지만, 사용자가 체감하는 중심축은 다소 다르다. Claude Code는 터미널에서 시작해 IDE, 데스크톱 앱, 브라우저로 확장되는 에이전트형 코딩 도구로 설명된다. 공식 문서의 기능 지형을 보면 설정, 권한, MCP, 훅, 하위 에이전트, SDK가 중요한 축이다. 즉 개발자가 이미 쓰는 작업 환경 안에서 “에이전트에게 무엇을 허용하고, 언제 개입하고, 어떤 도구와 연결할 것인가”를 구성하는 방향성이 강하다. 출처: Overview – Claude Code Docs, Claude Code settings, Hooks reference

Codex는 “어디서나 쓰는 하나의 코딩 에이전트”에 가깝게 확장되고 있다. Codex 공식 문서는 Codex를 CLI, IDE 확장, 앱, GitHub 코드 리뷰, 클라우드 작업 흐름과 연결되는 제품군으로 설명한다. Codex 앱은 여러 Codex 스레드를 병렬로 다루는 데스크톱 경험과 worktree, 자동화, Git 기능을 강조한다. Codex의 GitHub 통합 문서는 저장소별 AGENTS.md 지침을 코드 리뷰에도 적용할 수 있음을 전제한다. 출처: Codex | OpenAI Developers, Codex app – OpenAI Developers, Codex code review in GitHub

이 차이를 “Claude Code는 구현, Codex는 리뷰”처럼 단순화하면 곤란하다. 실제로 두 도구 모두 구현·수정·검토 흐름에 들어갈 수 있다. 더 정확한 구분은 운영 모델이다. Claude Code는 개발자의 로컬 작업 맥락에서 권한·훅·하위 에이전트·MCP를 엮는 방식이 눈에 띈다. Codex는 로컬 CLI와 IDE뿐 아니라 앱, 클라우드, GitHub 리뷰, AGENTS.md, sandbox와 approval 정책을 통해 조직 단위 지침과 검토 흐름으로 퍼지는 모양새다. 어떤 쪽이 낫다는 결론보다, 어느 단계에 어떤 책임을 맡길지 설계하는 것이 중요하다.

경쟁 축 1: 코드 생성 능력에서 실행 범위로

AI 개발 에이전트의 첫 번째 경쟁 축은 실행 범위다. 코드 블록을 제안하는 도구와 저장소 전체를 읽고 여러 파일을 수정하며 테스트를 실행하는 에이전트는 전혀 다른 위험 등급에 속한다. 전자는 틀린 코드를 사람이 복사하지 않으면 영향이 제한된다. 후자는 잘못된 파일 삭제, 과도한 리팩터링, 환경변수 노출, 외부 API 호출, 의존성 변경 같은 위험을 만들 수 있다.

그래서 실행 범위는 기능이 아니라 통제 대상이다. 실무에서는 다음 다섯 가지 권한을 분리해야 한다.

Codex 문서에서 sandbox와 approvals는 이 구분을 공식적으로 다루는 핵심 개념이다. sandbox는 기술적 경계를 정하고, approval policy는 경계를 넘기 전에 언제 멈춰 사용자 승인을 요구할지 정한다. Codex는 기본적으로 네트워크 접근을 꺼둔 상태로 동작한다고 설명되며, 로컬에서는 보통 현재 작업 공간으로 접근을 제한하는 운영체제 기반 sandbox와 approval 정책을 함께 사용한다. 출처: Sandbox – Codex, Agent approvals & security – Codex

Claude Code에서도 권한은 핵심이다. 설정 문서는 전역·프로젝트 단위 설정과 환경변수를 설명하고, 하위 에이전트 문서는 특정 하위 에이전트 또는 Agent 도구 자체를 권한 거부 목록으로 막을 수 있음을 보여준다. 훅 문서는 특정 생명주기 이벤트에서 셸 명령, HTTP 엔드포인트, LLM 프롬프트를 실행할 수 있다고 설명한다. 권한과 훅이 결합되면 에이전트 실행 전후에 조직의 검증 절차를 붙일 수 있지만, 반대로 잘못 구성하면 자동 승인과 자동 실행이 위험을 키울 수도 있다. 출처: Claude Code settings, Create custom subagents, Hooks reference

실무적 결론은 명확하다. “에이전트가 어디까지 할 수 있는가”보다 “어디까지 혼자 하게 둘 것인가”가 먼저다. 초안 작성과 테스트 실행은 넓게 허용할 수 있다. 의존성 대규모 변경, 데이터베이스 마이그레이션, 인증·결제·권한 코드 수정, 배포 트리거는 별도 승인선이 필요하다.

경쟁 축 2: 프롬프트가 아니라 PRD가 생산성을 결정한다

AI 개발 에이전트 도입에서 가장 과소평가되는 요소는 프롬프트 문장력이 아니라 요구사항 품질이다. “로그인 기능 만들어줘”는 에이전트에게 너무 넓고 위험한 지시다. “기존 인증 모듈을 유지한 채, 비밀번호 재설정 요청 화면에 이메일 형식 검증과 성공 안내 문구를 추가하고, API 계약은 바꾸지 않으며, 단위 테스트와 접근성 점검을 포함한다”는 지시는 훨씬 낫다. 차이는 모델이 아니라 작업 정의다.

PRD 기반 워크플로우는 이 문제를 해결하는 실무 장치다. 여기서 PRD는 거창한 제품 문서가 아니라 에이전트가 실행 가능한 수준으로 정리된 요구사항 계약서다. 좋은 PRD에는 목적, 사용자, 범위, 제외 범위, 입력·출력, 기존 시스템 제약, 완료 조건, 테스트 기준, 롤백 기준이 들어간다. 참고 소스의 PRD-프롬프트 워크플로우 글도 AI 생성 프로토타입과 실제 배포 사이의 간극을 줄이려면 PRD를 에이전트 프롬프트와 연결하고 품질 게이트를 강제해야 한다고 설명한다. 출처: 바이브 코딩 넘어 실서비스로, 유지보수 가능한 AI 코드 구현을 위한 PRD-프롬프트 워크플로우

실무 흐름은 다음처럼 잡는 것이 좋다.

PRD 작성
→ 기능 범위와 제외 범위 확정
→ 수직 슬라이스 단위로 작업 분해
→ 에이전트별 작업 배정
→ 구현 전 계획 검토
→ 코드 수정
→ 린트·타입체크·테스트
→ 코드 리뷰·보안 검토
→ 스테이징 검증
→ 배포 판단

여기서 수직 슬라이스가 중요하다. AI에게 “관리자 페이지 전체 개편”을 맡기면 레이아웃, API, 인증, 권한, 상태 관리, 테스트가 한꺼번에 얽힌다. 대신 “관리자 사용자 목록에 정렬 가능한 상태 컬럼 추가”, “비활성 계정 필터 추가”, “권한 없는 사용자의 접근 차단 테스트 추가”처럼 나누면 변경 범위가 작고 검증이 가능해진다. 참고 소스의 3단계 PRD-프롬프트 워크플로우도 범위 확정, 수직 슬라이싱, 컴파일 게이트를 핵심 단계로 제시한다. 출처: 바이브 코딩의 한계 극복, 프로덕션 배포를 위한 3단계 PRD-프롬프트 워크플로우

Codex의 AGENTS.md도 이 관점에서 중요하다. AGENTS.md는 저장소별 지침을 Codex에 제공하는 장치로, 베스트 프랙티스 문서는 저장소 구조, 실행 방법, 빌드·테스트·린트 명령, 엔지니어링 관례, PR 기대사항, 제약, 완료 정의와 검증 방법을 담으라고 권한다. 이것은 단순한 “개발자 취향 파일”이 아니라 PRD와 품질 게이트를 에이전트가 반복적으로 따르게 만드는 운영 문서다. 출처: Custom instructions with AGENTS.md – Codex, Best practices – Codex

경쟁 축 3: 품질 게이트가 없는 에이전트는 빠른 위험이다

AI가 만든 코드는 종종 “그럴듯하게 동작하는 코드”와 “유지보수 가능한 코드” 사이에 걸쳐 있다. 화면은 뜨지만 예외 처리가 빠져 있을 수 있다. 테스트는 통과하지만 실제 권한 경계가 무너졌을 수 있다. 타입 오류는 없지만 도메인 모델을 훼손했을 수 있다. 따라서 AI 개발 에이전트 도입의 핵심은 생성 속도를 높이는 것이 아니라 검증 비용을 통제하는 것이다.

품질 게이트는 최소한 다음 층으로 나눠야 한다.

Codex의 GitHub 코드 리뷰 통합은 AI 에이전트가 구현뿐 아니라 변경 검토 단계에도 배치될 수 있음을 보여준다. 공식 문서는 Codex cloud가 설정된 저장소에서 코드 리뷰를 켜고, 저장소별 AGENTS.md를 리뷰 지침으로 활용할 수 있음을 설명한다. Codex Security 문서는 연결된 GitHub 저장소에 대한 보안 스캔, PR 또는 브랜치 병합 전 변경 검토, 승인된 취약점 수정 같은 사용 사례를 제시한다. 출처: Codex code review in GitHub, Codex Security

Claude Code의 훅은 품질 게이트를 개발자 로컬 흐름에 붙이는 데 유용한 구조다. 예를 들어 에이전트가 파일을 수정한 뒤 테스트 명령을 실행하게 하거나, 특정 도구 호출 전에 승인을 요구하거나, 작업 완료 직후 변경 요약을 생성하게 할 수 있다. 공식 훅 문서는 Claude Code 생명주기의 특정 지점에 사용자 정의 셸 명령, HTTP 엔드포인트, LLM 프롬프트를 연결할 수 있다고 설명한다. 다만 자동 승인 훅은 생산성을 높이는 동시에 위험도 높인다. 특히 권한·배포·비밀정보 관련 작업에는 자동 승인을 피하는 편이 낫다. 출처: Hooks reference, Automate actions with hooks

품질 게이트의 기준은 “AI라서 더 엄격해야 한다”가 아니라 “AI는 변경 속도를 높이므로 검증 자동화도 같이 높아져야 한다”다. 사람 개발자가 하루에 한 파일을 바꿀 때와 에이전트가 한 번에 열 파일을 바꿀 때 리뷰 부담은 다르다. 조직은 AI 사용량을 늘리기 전에 테스트 피라미드, 코드 소유권, PR 크기 제한, 보안 스캔, 릴리스 체크리스트를 먼저 정비해야 한다.

Codex와 Claude Code를 업무 흐름별로 나눠 쓰는 법

실무 비교는 기능표보다 작업 유형별 적합성을 보는 편이 낫다. 아래 표는 특정 도구의 우열이 아니라 운영 관점의 배치 기준이다.

Claude Code의 Agent SDK 문서는 built-in tools, hooks, subagents, MCP, permissions, sessions 같은 기능을 SDK에서 사용할 수 있다고 설명한다. 이는 팀이 Claude Code를 단순 대화형 도구가 아니라 내부 개발 워크플로우의 구성 요소로 다룰 수 있음을 시사한다. Codex도 MCP를 CLI와 IDE 확장에서 지원하고, Agent Skills로 작업별 지침·리소스·스크립트를 묶어 반복 가능한 워크플로우를 만들 수 있다고 설명한다. 출처: Agent SDK overview – Claude Code Docs, Model Context Protocol – Codex, Agent Skills – Codex

따라서 한 조직 안에서 두 도구를 배타적으로 고를 필요는 없다. 예를 들어 Claude Code를 로컬 구현과 실험, 긴 코드베이스 탐색에 쓰고, Codex를 GitHub 리뷰와 별도 검토 스레드, 저장소 규칙 기반 반복 작업에 쓸 수 있다. 반대로 Codex CLI를 주 구현 에이전트로 쓰고 Claude Code를 하위 에이전트·훅 기반 검증 흐름에 배치할 수도 있다. 중요한 것은 “도구별 고정 역할”이 아니라 “작업별 책임 경계”다.

멀티 에이전트 조합: 한 명의 만능 작업자보다 역할 분리

AI 개발 에이전트가 강해질수록 한 에이전트에게 모든 일을 맡기고 싶어진다. 요구사항 읽기, 설계, 구현, 테스트, 리뷰, 문서화, 배포까지 한 번에 처리하면 이상적으로 보인다. 그러나 실무에서는 역할 분리가 더 안전하다. 같은 에이전트가 만든 코드를 같은 에이전트가 리뷰하면 자기 확신이 강화될 수 있다. 구현 관점의 최적화와 보안 관점의 검토는 다른 질문을 던져야 한다.

현실적인 멀티 에이전트 구성은 다음 정도면 충분하다.

• 기획 에이전트: PRD를 작업 단위로 쪼개고 완료 조건을 만든다.
• 구현 에이전트: 제한된 파일 범위에서 코드를 수정한다.
• 테스트 에이전트: 실패 재현, 테스트 추가, 회귀 테스트 범위를 제안한다.
• 리뷰 에이전트: 변경 범위, 설계 훼손, 보안 위험을 찾는다.
• 문서화 에이전트: 변경 사항을 운영 문서, 릴리스 노트, 마이그레이션 안내로 정리한다.

Claude Code의 custom subagents와 Codex의 Agent Skills는 이런 역할 분리를 뒷받침하는 방향의 기능으로 볼 수 있다. Claude Code 문서는 하위 에이전트별 설정과 권한 차단을 다루고, Codex 문서는 스킬이 작업별 지침·리소스·선택적 스크립트를 묶어 Codex가 워크플로우를 안정적으로 따르게 한다고 설명한다. 출처: Create custom subagents – Claude Code Docs, Agent Skills – Codex

다만 멀티 에이전트는 마법이 아니다. 역할을 나누면 조율 비용이 생긴다. 각 에이전트의 입력과 출력 형식을 정하지 않으면 같은 문제를 반복 분석하거나 서로의 변경을 덮어쓸 수 있다. 실무에서는 다음 규칙이 필요하다.

• 하나의 작업에는 하나의 소유 파일 범위를 준다.
• 구현 에이전트와 리뷰 에이전트의 기준을 다르게 둔다.
• 에이전트 간 전달물은 PRD, 변경 요약, 테스트 결과, 남은 위험 목록으로 표준화한다.
• 최종 병합과 배포 판단은 사람 또는 명시된 승인 흐름이 맡는다.

OpenAI 개발자 커뮤니티의 Codex와 Claude Code 설정 동기화, Codex를 Claude Code 워크플로우에 붙이는 플러그인, 이벤트 기반 에이전트 통신 요청 같은 논의는 사용자들이 이미 여러 에이전트와 도구를 조합하려는 방향으로 움직이고 있음을 시사한다. 다만 커뮤니티 글은 공식 제품 보장이라기보다 현장 요구를 보여주는 보조 자료로 읽는 것이 맞다. 출처: Introducing Codex Plugin for Claude Code, Sync Codex and Claude Code configs: skills, agents, MCP, permissions, Event-Driven Agent Communication for Codex

MCP는 연결 능력보다 권한 경계가 중요하다

MCP는 AI 개발 에이전트 경쟁에서 중요한 연결 표준으로 자리 잡고 있다. Claude Code 문서는 MCP가 외부 도구와 데이터 소스에 Claude Code를 연결해 이슈 추적기나 모니터링 대시보드 같은 정보를 복사해 붙여넣는 대신 직접 읽고 행동할 수 있게 한다고 설명한다. Codex 문서도 MCP가 모델을 도구와 맥락에 연결하며, Codex가 서드파티 문서나 브라우저·Figma 같은 개발 도구와 상호작용하는 데 쓰일 수 있다고 설명한다. 출처: Connect Claude Code to tools via MCP, Model Context Protocol – Codex

MCP의 실무 가치는 크다. 에이전트가 Jira 이슈, GitHub PR, 디자인 파일, 운영 로그, 문서 저장소, 브라우저 상태를 한 흐름에서 참조할 수 있으면 개발자의 복사·요약·전달 비용이 줄어든다. 문제는 연결되는 순간 권한 표면이 넓어진다는 점이다. 읽기만 필요한 MCP 서버에 쓰기 권한을 주면, 에이전트가 의도치 않게 이슈를 닫거나 문서를 바꾸거나 운영 데이터를 변경할 수 있다.

따라서 MCP 설계의 첫 원칙은 “연결”이 아니라 “최소 권한”이다. 이슈 추적기는 처음에는 읽기 전용으로 연결한다. 문서 도구는 초안 작성과 댓글 수준부터 시작한다. 브라우저 자동화는 로컬 개발 서버 검증에 한정한다. 운영 모니터링은 읽기 전용으로 두고, 인시던트 상태 변경은 사람 승인을 요구한다. 보안상 민감한 환경에서는 토큰, 비밀키, 고객 데이터, 프로덕션 데이터베이스 접근을 에이전트에게 직접 주지 않는 것이 기본이다.

InfoQ의 MCP 터널, Azure API Management의 MCP 관련 기능 보도는 기업 환경에서 MCP와 내부 시스템 연결, 콘텐츠 안전, 게이트웨이 통제가 중요한 주제로 부상하고 있음을 보여준다. 이런 보도는 특정 구현을 그대로 채택하라는 의미가 아니라, AI 에이전트가 내부 시스템과 연결될수록 네트워크·권한·감사·콘텐츠 안전 계층이 중요해진다는 신호로 읽어야 한다. 출처: 앤스로픽, 기업 내부 시스템 보안 연동 강화한 MCP 터널 공개, 마이크로소프트 애저 API 관리, 통합 모델 API 및 MCP 콘텐츠 안전 기능 출시

비개발자와 PM에게: 바이브코딩은 시작점일 뿐이다

PM, 기획자, 1인 창작자에게 AI 개발 에이전트는 강력한 진입로다. 화면을 만들고, 데이터 모델을 잡고, 간단한 API를 붙이는 속도는 과거보다 빨라졌다. 그러나 “동작하는 데모”와 “운영 가능한 서비스” 사이에는 여전히 큰 간극이 있다. 인증, 권한, 입력 검증, 데이터 백업, 장애 대응, 결제, 로그, 개인정보, 배포 환경, 유지보수는 프롬프트 한 줄로 사라지지 않는다.

비개발자가 놓치기 쉬운 위험은 세 가지다. 첫째, 생성된 코드의 구조를 이해하지 못한 채 기능만 추가하다가 어느 순간 수정 비용이 급격히 커진다. 둘째, 테스트가 없어서 작은 변경이 기존 기능을 깨도 바로 알 수 없다. 셋째, 배포·보안·개인정보 책임 경계를 과소평가한다. 참고 보도에서도 AI 시대의 개발 방식이 변해도 좋은 소프트웨어의 핵심은 품질과 유지보수 역량이라는 메시지가 강조된다. 출처: 전주정보문화산업진흥원, AI 코딩 시대 ‘테스트 가능한 코드’ 품질기술교육 운영

비개발자에게 권할 수 있는 현실적 기준은 다음이다.

• 첫 프롬프트 전에 PRD를 쓴다.
• 한 번에 하나의 사용자 흐름만 만든다.
• 로그인, 결제, 권한, 개인정보는 검증 가능한 전문가 리뷰를 받는다.
• 배포 전 최소한 빌드, 타입체크, 기본 테스트, 보안 점검을 통과시킨다.
• AI가 만든 코드의 변경 이유와 파일 목록을 기록한다.

결국 비개발자에게도 핵심 메시지는 같다. 단발성 프롬프트를 잘 쓰는 것보다 입력·모델·도구·체크포인트·인간 검토 단계를 갖춘 검증 가능한 작업 흐름을 만드는 것이 중요하다. 즉 “AI에게 시키는 법”보다 “검증 가능한 작업 흐름을 만드는 법”이 먼저다.

개발 조직의 도입 전략: 파일 하나보다 운영 규칙 하나

AI 개발 에이전트를 조직에 도입하려면 도구 선택보다 운영 규칙이 먼저다. 다음 순서가 현실적이다.

1. 작업 등급을 나눈다

모든 개발 작업을 같은 위험으로 보면 안 된다. 문서 수정, 테스트 보강, UI 문구 변경, 내부 도구 개선은 낮은 위험에 속한다. 인증·인가, 결제, 데이터 삭제, 마이그레이션, 배포 파이프라인, 보안 설정은 높은 위험에 속한다. 낮은 위험 작업은 에이전트 자율 범위를 넓힐 수 있지만, 높은 위험 작업은 계획 검토와 사람 승인을 기본으로 둔다.

2. 저장소 지침을 만든다

Codex를 쓴다면 AGENTS.md에 저장소 구조, 실행 명령, 테스트 명령, 금지 작업, 완료 조건을 적는다. Claude Code를 쓴다면 프로젝트 설정, 권한, 훅, 하위 에이전트 구성을 저장소 정책과 맞춘다. 두 도구를 함께 쓴다면 공통 규칙을 별도 문서로 두고 각 도구의 설정 파일에 반영한다. Codex의 config 문서는 사용자 수준 `~/.codex/config.toml`과 저장소 내 `.codex/config.toml` 같은 계층을 설명한다. 출처: Config basics – Codex, Configuration Reference – Codex

3. PRD와 품질 게이트를 묶는다

PRD는 요구사항 문서에서 끝나면 안 된다. 각 요구사항은 테스트 기준과 연결되어야 한다. 예를 들어 “관리자는 비활성 계정을 볼 수 있다”는 요구사항은 “비관리자는 접근할 수 없다”, “필터 상태가 URL에 보존된다”, “기존 페이지네이션이 깨지지 않는다” 같은 검증 항목으로 이어져야 한다. 에이전트에게는 이 검증 항목을 그대로 작업 완료 조건으로 준다.

4. 에이전트 결과물을 PR로만 받는다

에이전트가 직접 주 브랜치에 반영하게 두지 않는다. 작업 브랜치와 PR을 기본 단위로 둔다. PR에는 변경 요약, 테스트 결과, 위험 항목, 남은 검토 질문이 포함되어야 한다. Codex GitHub 리뷰나 Claude Code 기반 리뷰 에이전트는 보조 검토자로 붙일 수 있지만, 최종 승인은 코드 소유자 또는 정해진 승인 흐름이 맡아야 한다.

5. 성공 지표를 속도만으로 보지 않는다

AI 도입 효과를 “개발 시간이 얼마나 줄었는가”로만 보면 잘못된 최적화가 생긴다. 더 중요한 지표는 PR 크기, 리뷰 재작업률, 회귀 버그, 테스트 추가율, 장애 발생률, 보안 이슈, 문서 최신성이다. 국내 보도에서 특정 AI 코딩 솔루션의 비용 절감 효과가 언급되지만, 실무 조직은 이런 생산성 지표를 코드 품질·보안·유지보수 지표와 함께 봐야 한다. 출처: 유라클 AI 코딩 솔루션 ‘아테나’, 실증 거쳐 20% 비용절감 확인

실사용 시나리오 4가지

시나리오 1: 기존 서비스의 작은 기능 추가

상황: 운영 중인 웹서비스에 관리자 필터 하나를 추가한다.

입력: PRD에는 사용자 역할, 변경할 화면, API 변경 없음, 테스트 기준, 접근성 요구사항을 적는다.

실행 흐름: 구현 에이전트가 제한된 파일 범위에서 UI와 상태 관리를 수정한다. 테스트 에이전트가 기존 필터와 페이지네이션 회귀 테스트를 추가한다. 리뷰 에이전트가 무관한 파일 변경과 권한 누락을 확인한다.

출력: 작은 PR 하나, 테스트 결과, 변경 요약, 남은 위험 목록.

주의점: 에이전트가 “기회에 맞춰” 전체 테이블 컴포넌트를 리팩터링하려 하면 중단한다. 범위 밖 개선은 별도 이슈로 분리한다.

시나리오 2: 레거시 모듈 리팩터링

상황: 오래된 결제 보조 모듈의 중복 코드를 줄이고 테스트를 추가한다.

입력: PRD가 아니라 리팩터링 설계 메모를 먼저 만든다. 외부 동작 불변, 공개 API 유지, 테스트 우선, 성능 변화 없음 같은 제약을 둔다.

실행 흐름: 탐색 에이전트가 의존 관계와 호출 경로를 요약한다. 구현 에이전트는 작은 단위로 중복 제거를 한다. 테스트 에이전트는 기존 동작 고정 테스트를 먼저 만든다. 보안·도메인 리뷰는 사람이 한다.

출력: 단계별 PR 여러 개.

주의점: 결제·인증·권한 코드는 AI가 제안한 추상화가 예쁘더라도 도메인 의미를 훼손할 수 있다. 자동 병합 금지.

시나리오 3: 비개발자의 프로토타입을 실서비스 후보로 전환

상황: PM이 AI 도구로 만든 내부 도구를 팀이 실제로 쓰고 싶어 한다.

입력: 현재 기능 목록, 사용자, 데이터 종류, 보안 요구사항, 배포 환경, 유지보수 담당자를 정리한다.

실행 흐름: 에이전트가 코드 구조를 분석하고 위험 목록을 만든다. 개발자는 인증, 데이터 저장, 예외 처리, 테스트 가능성을 기준으로 재구성 범위를 정한다. 이후 기능 추가보다 테스트·배포·로그·권한부터 붙인다.

출력: 프로덕션 전환 계획, 우선순위별 리팩터링 PR, 최소 품질 게이트.

주의점: “이미 돌아간다”는 이유로 바로 배포하지 않는다. AI 생성 프로토타입은 요구사항 검증 도구이지 운영 품질 보증서가 아니다.

시나리오 4: 조직 차원의 에이전트 표준화

상황: 여러 팀이 Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI를 각자 쓰고 있다.

입력: 공통 보안 기준, 허용 도구 목록, 저장소별 지침 템플릿, PR 체크리스트, 금지 명령, 비밀정보 처리 기준.

실행 흐름: 플랫폼 팀이 표준 AGENTS.md와 Claude Code 설정 예시를 제공한다. 보안 팀은 MCP와 외부 도구 권한 기준을 만든다. 각 팀은 저장소 특성에 맞게 테스트 명령과 완료 조건을 추가한다.

출력: 에이전트 사용 가이드, 저장소 템플릿, 리뷰 체크리스트, 예외 승인 절차.

주의점: 중앙 통제가 너무 강하면 현장 생산성이 떨어진다. 공통 기준은 보안·품질·감사에 집중하고, 팀별 구현 방식은 여지를 둔다.

향후 전망: 개발자는 코드 작성자에서 에이전트 운영자로 확장된다

AI 개발 에이전트의 확산은 개발자 대체론보다 개발 방식의 재배치에 가깝다. 반복적인 코드 초안, 테스트 보강, 문서 정리, 변경 요약은 더 많이 자동화될 수 있다. 하지만 요구사항을 정확히 정의하고, 시스템 경계를 이해하고, 품질 기준을 세우고, 위험한 변경을 판단하고, 장애 책임을 지는 일은 더 중요해진다.

앞으로 경쟁력 있는 개발자는 프롬프트를 잘 쓰는 사람에 그치지 않을 가능성이 크다. 좋은 PRD를 만들고, 작업을 검증 가능한 단위로 나누고, 에이전트에게 줄 권한을 설계하고, 테스트 가능한 구조를 만들고, AI가 만든 결과물을 리뷰할 수 있는 사람이 더 중요해진다. 개발 리더는 AI 도구 예산보다 품질 게이트와 운영 정책을 먼저 봐야 한다. DevOps와 플랫폼 팀은 에이전트가 실행할 수 있는 명령, 접근할 수 있는 환경, 남겨야 할 로그를 설계해야 한다. QA와 보안 담당자는 에이전트 생성 코드의 위험 패턴을 검출하는 자동화와 리뷰 기준을 세워야 한다.

Codex와 Claude Code의 경쟁은 결국 “모델 대 모델”을 넘어 “운영 체계 대 운영 체계”로 갈 가능성이 크다. 어떤 에이전트가 더 많은 파일을 고치느냐보다, 어떤 에이전트가 조직의 요구사항·권한·검증·배포 흐름에 덜 위험하게 들어오느냐가 중요해진다. 도구를 고르는 질문도 바뀐다. “이 에이전트가 코드를 잘 짜는가”에서 “이 에이전트가 우리 팀의 완료 정의, 테스트 기준, 보안 정책, 리뷰 문화 안에서 반복 가능하게 일할 수 있는가”로.

결론은 단순하다. Codex와 Claude Code는 둘 다 강력한 AI 개발 에이전트다. 하지만 실무에서 승패를 가르는 것은 도구 자체가 아니라 운영 방식이다. PRD가 부실하면 뛰어난 에이전트도 엉뚱한 방향으로 빠르게 달린다. 권한 설계가 없으면 자동화는 위험해진다. 품질 게이트가 없으면 빠른 구현은 빠른 부채가 된다. 반대로 요구사항, 권한, 테스트, 리뷰, 보안, 배포 기준이 정리된 조직에서는 AI 개발 에이전트가 실제 개발 속도와 품질을 함께 끌어올릴 수 있다.

참고 출처

공식 문서

• Codex | OpenAI Developers
• Codex CLI – OpenAI Developers
• Codex app – OpenAI Developers
• Custom instructions with AGENTS.md – Codex
• Best practices – Codex
• Sandbox – Codex
• Agent approvals & security – Codex
• Model Context Protocol – Codex
• Agent Skills – Codex
• Codex code review in GitHub
• Codex Security
• Overview – Claude Code Docs
• Claude Code settings
• Connect Claude Code to tools via MCP
• Hooks reference
• Automate actions with hooks
• Create custom subagents – Claude Code Docs
• Agent SDK overview – Claude Code Docs

보조 해설·보도 자료

• 바이브 코딩 넘어 실서비스로, 유지보수 가능한 AI 코드 구현을 위한 PRD-프롬프트 워크플로우
• 바이브 코딩의 한계 극복, 프로덕션 배포를 위한 3단계 PRD-프롬프트 워크플로우
• 전주정보문화산업진흥원, AI 코딩 시대 ‘테스트 가능한 코드’ 품질기술교육 운영
• 유라클 AI 코딩 솔루션 ‘아테나’, 실증 거쳐 20% 비용절감 확인
• 앤스로픽, 기업 내부 시스템 보안 연동 강화한 MCP 터널 공개
• 마이크로소프트 애저 API 관리, 통합 모델 API 및 MCP 콘텐츠 안전 기능 출시