Claude × Codex를 깨우는 궁극의 에이전트 설계 [최신 버전]

"더 구체적인 지시를 해주세요"라는 말을 들어도, 그 '구체적인 부분'부터 도움을 받고 싶습니다.

만들고 싶은 것은 있는데, AI 에게 물어보기 위한 사전 조사 단계에서 손이 멈춰버립니다. 이건 손해 보는 기분이죠.

예를 들어, 사례를 등록하고 마감일이 다가오는 순서로 정렬할 수 있는 앱을 원한다고 가정해 봅시다. 여기까지는 말할 수 있습니다. 하지만 데이터 저장 방식이나 버그 확인 방법을 묻는 순간, 갑자기 조사해야 할 양이 폭증합니다.

조사하다 보면 "이번엔 이 기능 없어도 괜찮지 않을까?"라며 원래 넣고 싶었던 기능을 하나둘 빼기 시작합니다. 만들기 어려워서가 아니라, 문제가 생겼을 때 스스로 감당할 수 있는 범위 안에 모든 것을 두고 싶기 때문입니다.

사실 질문하기 전에 자잘한 지시까지 전부 준비하고 싶지는 않습니다. 제가 놓친 부분을 알아서 짚어주길 바랍니다. 두 가지 옵션 중 어떤 걸 선택할지 명확하게 물어봐 주고, 그 결정에 따라 작업을 진행해 준다면 정말 큰 도움이 될 겁니다.

이 글에서 구성하는 개발 팀은 Claude Code 와 Codex 를 활용해 바로 그런 요구에 더 가까이 다가가기 위해 설계되었습니다.

• Claude Code: 요청의 창구 역할. 필요한 확인 사항과 업무 분담을 정리합니다.
• Codex: 구현과 검수를 담당합니다.

사례 관리 앱이라면 화면을 만드는 것 외에도 검증용 태스크를 함께 준비합니다. 빈 칸으로 등록하면 어떻게 될까요? 새로고침 후에도 기록이 남아 있을까요? 버그가 고쳐지지 않는다면 시도했던 수정 내용과 남은 증상을 요약해서 다른 에이전트에게 넘겨야 합니다.

사람이 하는 일은 중간중간 필요한 판단을 내리고, 마지막에 실제 동작을 확인하는 것입니다. 이를 원활하게 하려면 사양, 변경 사항, 검증 결과가 제대로 내 손으로 돌아오는 구조를 만들어야 합니다. 연결 방법부터 작업 인수인계, 중단 조건까지 단계별로 구축해 보겠습니다.

Claude 를 열어둔 채 Codex 에 작업 할당하기

이전 답변을 다른 AI 에 붙여넣지 않고도 Claude Code 에서 Codex 로 요청을 전달하는 방법이 있습니다. 바로 OpenAI 가 공개한 "Claude Code 용 Codex 플러그인"입니다.

공식 문서에 따르면 다음과 같은 용도를 지원합니다.

• 현재 변경 사항을 점검하는 리뷰

• 조사나 수정 작업 위임

• 대화 흐름 넘기기

이 글에서는 2026 년 10 월 16 일에 확인한 공식 문서를 바탕으로, 로컬 환경의 Claude Code 에서 이를 사용하는 절차를 다룹니다.

사전 준비 사항

• Claude Code 를 사용할 수 있는 환경

• Git

• Node.js (공식 요구 사항: 18.18 이상)

• Codex 인증이 완료된 ChatGPT 계정 또는 OpenAI API 키

플러그인은 로컬의 Codex 를 호출합니다. 연결했다고 해서 Codex 가 Claude 의 사용량 쿼터로 실행되는 것은 아니며, Codex 사용량은 Codex 자체의 쿼터를 소모합니다.

또한 이 설정은 로컬 파일을 다루지만, AI 추론이 반드시 PC 내부에서만 완료되는 것은 아닙니다. 기밀 정보가 없는 연습용 폴더부터 시작하세요.

플러그인 설치

Claude Code 입력창에서 아래 명령어를 위에서부터 순서대로 하나씩 실행합니다. 이는 일반 터미널에 붙여넣는 명령어가 아니라, Claude Code 내에서 플러그인을 추가하는 조작입니다.

1/plugin marketplace add openai/codex-plugin-cc
2/plugin install codex@openai-codex
3/reload-plugins
4/codex:setup

마지막 /codex:setup 을 통해 Codex 설치 및 인증 상태를 확인할 수 있습니다. Codex 를 찾을 수 없고 npm 이 사용 가능한 경우 설치 안내가 표시되니, 내용을 확인하고 그에 따라 진행하세요.

인증되지 않은 상태라면 터미널에서 codex login 을 실행하고 안내에 따르세요.

Windows 에서는 Claude 를 실행하는 환경과 Codex 를 설치한 환경이 분리되어 있지 않은지 확인하세요. "찾을 수 없다"는 메시지가 나온다고 해서 무작정 재설치를 반복하지 마세요.

먼저 리뷰부터 시도하기

코드를 수정하지 않는 리뷰부터 시작합니다. Git 으로 관리되는 연습용 프로젝트에서 작은 변경 사항을 준비한 뒤 다음을 실행하세요.

1/codex:review --background

• 진행 상황 확인: /codex:status

• 완료된 결과 확인: /codex:result

여러 요청이 동시에 활성화된 경우, 결과가 섞이지 않도록 표시된 Job ID 를 지정하세요.

작업 분할에는 Amazon 의 공개 샘플이 유용합니다

역할 분담의 참고 자료로는 Amazon 의 클라우드 사업부인 AWS 가 공개한 개발 샘플을 살펴보세요. GitHub 의 aws-samples 에 관련 리포지토리가 두 개 있습니다.

• sample-codex-agent-team (Codex 용)

• sample-claude-code-agent-team (Claude Code 용)

Codex 버전에는 6 개의 역할이 있습니다.

등록 화면을 어떻게 만들지 결정하는 것과 확장성, 유지보수 비용 등을 고려하는 것은 서로 다른 일입니다. 기능 구현과 운영 관련 상담을 분리하면 특정 에이전트에게 던지는 질문이 훨씬 구체적이 됩니다.

가벼운 리뷰는 위험한 변경 사항을 대충 처리하라는 의미가 아닙니다. 문서 편집이나 기계적인 치환처럼 위험도가 낮은 작업에 매번 무거운 검수를 거치지 않기 위한 분할 방식입니다.

두 샘플은 작업 인수인계 방식이 다릅니다.

• Claude Code 버전: 에이전트가 공유된 작업 목록에서 태스크를 가져옴 (실험적 에이전트 팀 기능 사용, 추가 설정 필요)

• Codex 버전: 책임 파일이 분할된 작업 계획에 따라 진행

이 둘은 별개의 샘플입니다. 둘 다 설치한다고 해서 자동으로 하나의 팀으로 합쳐지지 않습니다.

또한 Codex 버전에는 아직 공개되지 않은 연결 설정을 전제로 한 모델 지정이 포함되어 있습니다. 샘플 자체에서도 모든 계정에 그대로 적용되지는 않는다고 명시되어 있습니다. 회사의 핵심 프로젝트에 통째로 복사하기보다는, 역할 분할 로직만 차용하여 자신이 사용할 수 있는 환경에 맞게 조정하세요.

이 글에서는 Claude Code 가 인터페이스 역할을 하며 제한된 구현 및 검수 작업을 Codex 에 전달하는 작은 구조부터 시작합니다.

참고: 이는 공개 샘플을 참고한 독자적인 운영 예시입니다. AWS 가 Claude 와 Codex 의 통합을 보장하는 제품도 아니고, 동작을 측정한 보고서도 아닙니다.

구축 전에 "저장 가능"의 의미를 맞추기

만들고 싶은 것을 상세히 설명할 수 없을 때는 즉시 구현을 시작하지 마세요. 먼저 Claude 에게 확인 항목을 정리하도록 시키세요. 기술 용어를 모두 알 필요는 없습니다. 내가 답할 수 있는 질문 형태로 바꿔달라고 하면 됩니다.

개인용 사례 관리 앱을 만들고 싶어. 먼저 필요한 사양을 정리하고, 결정이 필요한 사항을 한 번에 하나씩 질문해 줘. 기술적인 선택지에 대해서는 사용자에게 미치는 영향과 추천 이유를 간단히 설명해 줘. 내가 승인하기 전까지는 구현을 시작하지 마.

예를 들어 저장 방식의 경우, 같은 브라우저에만 기록이 남으면 충분한가요, 아니면 스마트폰과 PC 간 공유를 원하나요? 이 둘은 완전히 다른 메커니즘을 요구합니다. 아무 말 없이 하나를 선택해 버리면 나중에 재작업이 발생합니다.

이번 연습에서는 범위를 좁혀보겠습니다.

• 범위 포함(In Scope): 같은 PC/브라우저에서 사용, 새로고침 후에도 기록 유지

• 범위 제외(Out of Scope): 멀티 디바이스 동기화, 로그인, 외부 공개, 고객의 실제 데이터

완료 기준은 "사용하기 편함"이 아니라 동작 결과로 정의합니다.

• 사례를 등록할 수 있다

• 마감일순으로 정렬된다

• 상태를 변경할 수 있다

• 빈 상태로 등록하면 사유가 표시된다

• 새로고침 후에도 내용이 유지된다

사양과 작업 요청을 파일로 저장하기

결정된 내용은 모두가 참조하는 사양서로 docs/spec.md 에 저장하세요. 여기서 언급한 파일명은 예시일 뿐이며, 모든 AI 에 자동으로 배포되지 않으므로 요청할 때마다 "이걸 읽어"라고 지정해야 합니다.

결정된 사양, 완료 기준, 범위 외 기능을 docs/spec.md 에 저장해 줘. 미결정 사항을 확정된 것처럼 적지 마. 구현을 중단해야 하는 항목과 임시 설정으로 진행할 항목을 구분해 줘.

다음으로 구현자를 위한 작업 요청을 docs/tasks.md 에 요약합니다. 단순히 작업 이름만 적어선 부족합니다. 읽어야 할 자료, 수정 가능한 파일, 수정 불가 영역, 검증 방법, 예상 산출물을 포함하세요.

사양을 구현 가능한 단위로 쪼개줘. 담당 파일, 선행 작업, 검증 방법을 docs/tasks.md 에 작성해 줘. UI 와 저장소 로직 간 공유 항목은 미리 정해둬. 두 에이전트가 동시에 같은 파일을 수정하도록 계획하지 마.

두 AI 에게 동일한 사양 보여주기

지속적인 지시 사항은 Claude 용 CLAUDE.md, Codex 용 AGENTS.md 에 작성할 수 있습니다. 이는 문서화된 메커니즘입니다. 하지만 한쪽 파일이 다른 쪽에서도 동일하게 작동한다고 가정하지 마세요. 두 AI 모두 같은 사양 파일을 참조하도록 하세요.

지시 사항은 짧게 유지합니다.

• 사양 파일 위치

• 요청 외 변경 금지

사양을 복제해 두면 한쪽이 구버전으로 남을 위험이 있습니다. 이렇게 하면 이를 방지할 수 있습니다.

병렬 작업 전 워크스페이스 분리하기

여러 AI 가 동시에 일하면 빨라 보이지만, 서로 다른 정책으로 같은 파일을 덮어쓰면 결국 사람이 정리해야 할 일만 늘어납니다.

초기 병렬 작업에서는 "UI 빌더"와 "테스트 기획자"를 짝지어 보세요. 형식이 확정되기 전에 UI 와 저장소를 따로 구현하면 불일치 문제가 증가합니다.

Git Worktree 로 폴더 분리하기

이럴 때 Git worktree 가 유용합니다. 같은 프로젝트에 대해 서로 다른 변경 사항을 가진 별도의 작업 폴더를 허용하는 Git 공식 기능입니다.

생성 전에 사양과 기본 코드가 Git 에 커밋되어 있는지 확인하세요. 커밋되지 않은 초안 파일은 새 위치로 넘어가지 않을 수 있습니다. 브랜치명과 대상 폴더가 사용 중이지 않은지도 확인합니다.

1git worktree add -b feature/ui ../case-app-ui
2git worktree add -b feature/storage ../case-app-storage
3git worktree list

세 가지 주의 사항이 있습니다.

1. 폴더를 만든다고 AI 워크스페이스가 바뀌진 않습니다. 각 디렉터리에서 별도 세션을 열고, 시작 전 위치와 브랜치를 확인하세요.

1. 플러그인은 호출자의 환경을 사용합니다. Claude/Codex 를 연결했다고 자동 격리되지 않습니다. 처음에는 "위치당 에디터 하나" 원칙을 지키세요.

1. Worktree 는 주로 파일을 격리합니다. 공유 데이터베이스나 포트는 충돌을 일으킵니다. 테스트용 저장소/포트를 분리하거나 실행 순서를 조절하세요.

Codex 의 동시 작업 제한하기

Codex 에서 서브 에이전트를 늘리려면 동시 스레드 수를 제한해야 합니다. 서브 에이전트는 상위 AI 로부터 제한된 작업만 받습니다. .codex/config.toml 의 현재 설정은 다음과 같습니다.

1[agents]
2enabled = true
3max_concurrent_threads_per_session = 2

• 항목을 중복해서 적지 마세요

• 신뢰할 수 있는 프로젝트에서만 사용하세요 (프로젝트 설정은 신뢰된 컨텍스트에서만 로드됨)

• 이 제한은 "해당 세션에서 메인 에이전트를 제외한 동시 스레드 수"에 적용되며, Claude 나 세션 전체의 총합이 아닙니다.

AWS 샘플의 14 개 스레드는 그들의 선택일 뿐입니다. 필수 규칙이 아닙니다. 샘플의 max_threads 는 레거시 별칭이니 현재 명칭을 사용하세요.

매번 구현자에게 처음부터 설명하지 않기

Codex 에서는 .codex/agents 안의 TOML 파일로 커스텀 에이전트를 정의합니다. 필요한 조건을 담아 task-builder.toml 을 만드세요.

1name = "task-builder"
2description = "확정된 사양에서 할당된 범위만 구현"
3developer_instructions = """
4먼저 docs/spec.md 와 docs/tasks.md 를 읽어.
5할당된 범위만 구현하고, 사양 변경이 필요하면 멈추고 보고해.
6다른 에이전트의 변경 사항을 되돌리거나, 비밀 정보를 읽거나, 외부에 공개하지 마.
7변경된 파일, 실행한 테스트, 결과, 미확인 항목을 반환해.
8"""

여기에 모델명을 고정하지 마세요. 기본값은 상위 설정을 상속합니다. 공개 샘플의 모델은 여러분의 계약에서 사용 불가할 수 있으며, 없는 이름을 하드코딩하면 역할 설명조차 읽기 전에 시작이 중단됩니다.

파일을 배치한 후 새 Codex 세션에서 인식 여부를 확인하고 작은 작업을 위임하세요. Claude 에서 요청할 때는 Codex 의 task-builder 를 사용하도록 지정합니다.

Codex 에게 docs/tasks.md 중 저장소 로직만 task-builder 에 위임하도록 요청해 줘. 시작 전 에이전트 인식 여부와 실제 폴더를 확인해. 사용할 수 없다면 조용히 방식을 바꾸지 말고 보고해.

참고: "수정하지 마"라고 적는 것과 쓰기 권한을 제거하는 것은 다릅니다. 공식 문서에 따르면 Codex 하위 에이전트는 상위 권한(샌드박스 설정)을 상속합니다. 역할 이름이 "reviewer" 라고 해서 안전한 읽기 전용 환경이 만들어지진 않습니다.

수정이 반복되면 에이전트 교체하기

AI 가 "원인을 찾았다"고 했는데 같은 동작이 또 실패한다면, 서둘러 다음 수정으로 넘어가지 말고 무엇이 바뀌었고 무엇이 안 바뀌었는지 기록하세요. 그래야 넘기기 쉽습니다.

공식 플러그인에는 조사나 수정을 Codex 에 위임하는 rescue 항목이 있습니다. 이름과 달리 버그뿐만 아니라 범위가 정해진 작업 전반에 사용됩니다.

조사는 읽기 전용임을 명시하기

원인 분석만 할 때는 쓰기가 없음을 명확히 밝히세요. 내부 절차상 별도로 지정하지 않으면 rescue 는 기본적으로 쓰기 가능 상태가 됩니다. 조사와 수정은 확실히 구분하세요.

1/codex:rescue --fresh 새로고침 시 등록 내용이 사라지는 이유를 읽기 전용으로 조사해. docs/spec.md 와 코드를 비교해. 재현 단계, 근거 기반 원인, 필요한 확인 사항을 반환해. 파일은 수정하지 마.

--fresh 는 새 요청을 시작하고, --resume 은 이전 요청을 이어갑니다 (생략 시 프롬프트 표시). 이어갈 때도 권한을 지정하세요. 수정으로 넘어간다면 범위를 정의합니다.

1/codex:rescue --resume 확인된 원인을 바탕으로 최소한의 변경만으로 저장소 로직만 수정해. UI 나 사양은 바꾸지 마. 수정 전 실패하는 테스트와 수정 후 결과를 보여줘.

Transfer 로 대화 전체 넘기기

• 작업만 전달 → rescue

• 대화 흐름을 Codex 로 이동 → transfer

1/codex:transfer

공식 문서에 따르면, 현재 Claude Code 대화를 이어서 진행하는 Codex 스레드를 생성하고 재개 명령어를 표시합니다. 지원되지 않는다면 Codex 를 업데이트하세요.

대화를 넘기는 것 ≠ PC 상태를 넘기는 것. 저장되지 않은 변경 사항, 인증 정보, 실행 중인 앱은 이동하지 않습니다. 도착지에서 파일과 상태를 다시 확인하세요.

"완료" 후에는 다른 AI 로 검증하기

구현자가 테스트하는 것도 도움이 되지만, 사양을 잘못 이해했다면 통과한 테스트가 원하는 동작과 일치하지 않을 수 있습니다.

검수자에게는 구현자의 설명이 아니라 사람이 확인한 사양과 실제 변경 사항을 주세요. "완벽하게 고쳤다"는 평가를 공유하지 말고, 독립적으로 준수 여부를 확인하게 하세요.

docs/spec.md 와 실제 변경 사항을 독립적으로 비교해 줘. 충족되지 않은 완료 기준을 근거와 함께 찾아내. 구현자의 자가 평가를 당연하게 받아들이지 마. 재현 가능한 문제, 잠재적 우려 사항, 미검증 항목을 구분해. 지금은 수정하지 마.

반대편을 짝지어 주세요.

• Claude 가 구현 → 별도 검수로 Codex 일반 리뷰 추가

• Codex 가 구현 → Claude 에게 검수 요청, 필요시 새 Codex 리뷰 추가

일반 리뷰 vs 적대적 리뷰

일반 리뷰는 /codex:review 로 호출합니다. 브랜치를 main 과 비교합니다.

1/codex:review --base main

main 브랜치가 없다면 실제 베이스 브랜치를 사용하세요. 리뷰 중에는 변경 사항을 건드리지 마세요.

참고: 일반 리뷰는 "저장소만 확인해" 같은 자유 텍스트 집중 지시를 받지 않습니다. 공식 사양상 우선순위 지시가 금지되어 있습니다. 설계 가정이나 특정 리스크에 도전하려면 adversarial-review 를 사용하세요.

1/codex:adversarial-review --background 저장 실패가 성공으로 표시되는지, 두 탭에서 동시에 편집하면 기록이 유실되는지 확인하고 현재 설계 가정을 검증해.

이는 말투가 험악하다는 뜻이 아니라, 선택한 접근법과 가정에 의문을 제기한다는 의미입니다. 두 리뷰 모두 문제를 식별할 뿐 코드를 수정하지는 않습니다. 결과를 확인한 뒤 수정 작업은 별도로 위임하세요.

발견 사항을 적용 가능한 완료 기준, 사용자 영향, 검증 방법과 함께 정리해. 사양 변경이 필요한 문제는 자동 수정하지 말고, 사람에게 옵션과 차이점을 제시해.

초기에는 리뷰 게이트 건너뛰기

자동화 옵션으로 "리뷰 게이트"가 있습니다. Claude 가 응답을 마칠 때마다 Codex 리뷰를 삽입하는 기능으로, /codex:setup --enable-review-gate 로 활성화합니다.

주의: 공식 문서에서는 Claude 와 Codex 사이에서 긴 수정 루프가 돌며 쿼터를 빠르게 소모할 위험이 있다고 경고합니다.

처음에는 수동 리뷰로 시작해 발견 사항을 파악하세요. 자리를 비울 때는 비활성화합니다. /codex:setup --disable-review-gate 로 중지하고 대기 중인 요청을 확인하세요.

성공한 요청은 다음 작업을 위해 보존하기

긴 지시문을 매번 다시 붙여넣지 말고, 성공한 워크플로를 저장하세요. Skills 기능을 사용하면 작업 절차를 파일로 저장해 재사용할 수 있습니다.

Anthropic 문서에 따르면 .claude/skills 에 절차를 배치합니다. team-brief 폴더를 만들고, 위임 전 확인 사항을 담은 SKILL.md 를 작성하세요.

1---
2name: team-brief
3description: 사양에서 범위와 검증 항목 정리
4disable-model-invocation: true
5---
6docs/spec.md 와 docs/tasks.md 를 읽고, 현재 변경 사항만 대상으로 삼아.
7범위, 금지된 변경, 선행 조건, 완료 기준, 검증을 정리해.
8에이전트용 요청 텍스트를 작성하되, 미결정 항목은 사람 확인용으로 남겨둬.
9이 절차에서 코드를 변경하거나 외부에 공개하거나 Codex 를 실행하지 마.

Claude Code 에서 호출:

1/team-brief 마감일순 정렬을 추가하고 싶어

이는 표준 기능이 아닌 커스텀 명령어입니다. disable-model-invocation: true 를 설정하면 사람이 타이밍을 결정합니다. Claude 가 자동으로 시작하지 않습니다. 이 절차는 AI 실행이나 검사를 강제하지 않으니, 처음에는 "준비 과정만 재사용"하는 방식으로 시도해 보세요.

큰 작업을 위한 Dynamic workflows

더 큰 범위의 작업에는 여러 에이전트를 스크립팅할 수 있는 Claude Code 의 Dynamic workflows (2026 년 5 월 발표) 가 있습니다. 유료 플랜/API 에서 사용 가능합니다.

• 일반 채팅: 매번 Claude 가 다음 작업을 선택

• Dynamic workflows: 분기와 결과 수집을 스크립트로 작성하여 재실행 가능

예: 여러 화면에 걸쳐 저장 실패, 입력 검사, 레이아웃 깨짐을 각각 조사하고 결과를 교차 검증합니다. 작은 앱에서 대규모 에이전트를 띄우지 말고, 동일한 검사를 광범위하게 적용할 때 고려하세요.

화면을 분할해 조사하고 별도 에이전트로 발견 사항을 검증하는 Dynamic workflow 를 만들어 줘. 먼저 대상, 에이전트 수, 종료 조건을 제시해. 코드 변경은 하지 말고, 승인 후 작은 범위로 실행해.

팁:

• Pro 플랜에서 /config 로 활성화

• /workflows 로 진행 상황/사용량을 모니터링하며 언제든 중지 가능

• /config 에서 규모(small 등)를 선택. 공식 문서에서는 이를 엄격한 제한이 아닌 추정치로 봅니다. 에이전트 수가 보장된다고 생각하지 마세요.

이는 Claude 측 에이전트를 실행하는 것이며, Codex 가 자동으로 합류하지는 않습니다. 먼저 Claude 내부 조사/검증에 사용하고, Codex 위임은 별도 단계로 취급하세요.

사례 관리 앱 엔드 투 엔드 실행하기

컴포넌트를 하나의 앱 빌드로 연결해 봅시다. 아래는 설명을 위한 개발 예시이며 완성된 경험 보고가 아니니, 여러분의 환경에서 직접 검증하세요.

구축 목표

• 필드: 사례명, 마감일, 상태, 메모

• 상태: 미시작 / 진행 중 / 완료

• 사례명으로 검색

• 미완료 사례를 마감일순으로 정렬해 표시

초기 요청

Claude 에게 전달합니다. 기존 핵심 프로젝트가 아닌 새 연습용 폴더를 대상으로 하세요.

연습용 폴더에 개인 사례 관리 앱을 만들어 줘. 먼저 환경과 사양을 확인해. 이름, 마감일, 상태, 메모에 대한 등록/편집/검색/정렬/유지 기능을 포함해. 로그인, 동기화, 외부 공개는 제외야.

저장소 후보는 localStorage 입니다. 멀티 디바이스 동기화나 백업은 되지 않으며, 브라우저 데이터를 지우면 기록도 삭제됩니다. 중요한 실전 정보는 넣지 마세요.

기본 구축 및 공유 부분 정의

단일 에이전트가 기본 구조를 만듭니다. 앱이 실행되고 빈 화면이 표시되는지 확인하세요. 필요시 워크스페이스를 분리하기 전에 사양과 기본 코드를 Git 에 커밋합니다.

• UI 에이전트에게 줄 것: 표시 필드, 액션 매핑

• Storage 에이전트에게 줄 것: 레코드 형식, 읽기/추가/갱신 방법, 실패 처리

어느 쪽도 임의로 필드명을 지어내게 하지 마세요. 상태 필드가 status 라면 둘 다 이를 사용해야 합니다. 편하다고 한쪽만 state 로 바꾸지 말고, 공유되는 변경 사항은 다시 Claude 로 보내 조율하세요.

Codex 에 구현 요청

쓰기 가능한 위치와 함께 필수 증거 산출물을 지정하세요.

1/codex:rescue --fresh docs/spec.md 와 docs/tasks.md 를 읽어. 할당된 저장소 로직과 테스트만 구현해. 변경된 파일, 명령어, 테스트 결과, 미확인 항목을 반환해. 사양 변경이나 다른 에이전트 수정이 필요하면 멈추고 보고해.

그동안 Claude 는 옆에서 같은 파일을 수정하지 않습니다. 완료 확인이나 테스트 데이터 준비에 집중하고, 결과가 돌아온 뒤 다음 단계를 결정하세요.

검증 데이터 준비

• 어제 마감, "미시작"

• 오늘 마감, "진행 중"

• 다음 주 마감, "완료"

• 마감일이 같은 여러 사례

• 긴 사례명

이를 통해 구체적인 정렬 및 표시 확인이 가능해집니다.

상세 규칙은 사양서에 문서화하세요.

• 정렬: 마감일이 같을 때는 등록 순서

• 빈 필드: 이름/마감일은 필수, 메모는 선택. 누락된 필드는 표시

• 날짜: 날짜 전환 기준 시각 정의. 시간대/시간 처리 문제로 날짜가 밀리면 겉보기엔 깔끔해도 앱을 쓸 수 없게 됩니다.

규칙을 미리 정해두면 구현 후 검증 기준이 흔들리지 않습니다.

통합 및 테스트

구현이 준비되면 Claude 에게 변경 목록과 테스트 결과를 읽히고 통합을 확인시킵니다. worktree 를 사용했다면 변경 사항을 단일 검증 브랜치로 모으세요. 개별 통과한 테스트도 통합 후 다시 실행합니다.

UI 자동화에는 Playwright 를 사용합니다. 최신 가이드에서는 AI 에이전트용 CLI/Skills 도 제공하며, MCP 만이 유일한 방법은 아닙니다.

"AI 의 브라우저 제어 메커니즘"과 "재현 가능한 테스트"를 분리하세요. 등록부터 새로고침까지 반복 실행 가능한 흐름에는 Playwright Test 를 사용합니다.

등록, 빈 값 거부, 검색, 상태 변경, 마감일 정렬, 데이터 유지를 검증하는 Playwright Tests 를 작성해. 실행 설정과 테스트 데이터를 분리해. 테스트를 통과하려고 앱 동작이나 완료 기준을 바꾸지 마.

새 연습 프로젝트 설정:

1npm init playwright@latest

이미 설치되어 있다면 추가하기 전 기존 실행/테스트 설정을 확인하세요.

브라우저가 설치되어 있고 앱 실행 설정이 완료되었는지 확인한 뒤 실행합니다.

1npx playwright test
2npx playwright show-report

핵심: 테스트가 하나도 발견되지 않았거나 전부 건너뛴 상태를 "통과"로 취급하지 마세요.

실패 시 원인을 격리하세요. 저장소 버그인가요, 아니면 존재하지 않는 버튼을 찾는 테스트인가요? 초록불을 만들기 위해 테스트를 지우지 말고, 원래 사양에 맞춰 무엇을 수정할지 결정하세요.

최종 인간 검증

화면은 직접 눈으로 확인하세요. 숨겨진 텍스트가 있나요? 마감일이 가까운 사례를 찾기 쉬운가요? 테스트 통과 리포트가 UX 를 보장하진 않습니다.

긴 로그 대신 Claude 로부터 네 가지 항목을 받으세요.

• 실행 방법

• 검증된 동작

• 남은 제약 사항

• 다음 수정 후보

직접 하나를 등록하고 새로고침해 유지되는지 확인하세요. 그 후 완료 처리합니다.

끝없는 수정은 어디서 멈출 것인가

팀 규모가 커질수록 끝을 정의해야 합니다. 같은 버그를 맴도는 건가요, 아니면 연쇄적인 문제를 해결하는 건가요? 상태가 불분명하면 추가 지시를 내리기 어렵습니다.

중단 기준 설정

"문제당 최대 2 회 수정"을 지침으로 삼아 보세요. 공식 권장 사항은 아니지만, 막혔을 때 판단을 사람에게 돌려주기 위한 운영 규칙입니다.

같은 버그가 두 번 시도해도 고쳐지지 않으면 추가 변경을 멈춰. 시도한 조치, 변경된 내용, 남은 증상, 필요한 결정을 요약해. 관련 없는 기능으로 확장하지 마.

지시만으로는 중단을 보장할 수 없습니다. 사용량을 모니터링하고, 불필요한 백그라운드 요청은 /codex:cancel 로 취소하세요. 에이전트가 실제로 멈췄는지 확인해야 합니다.

비용은 별도로 추적하기

ChatGPT 인증 Codex 쿼터와 API 키 요금제는 다릅니다. 병렬 에이전트는 추론 및 도구 리소스를 소모합니다.

단순한 텍스트 수정을 두 AI 나 대규모 리뷰를 거쳐 처리하지 마세요.

다음과 같이 분류해 보세요.

• 혼자 완료할 수 있는 작업

• 두 번째 관점이 필요한 작업

• 독립적으로 병렬 처리 가능한 작업

노력과 쿼터 배분을 결정하는 데 도움이 됩니다.

오래된 모델 사양 주의

옛날 모델 지정은 실패의 원인입니다. OpenAI 업데이트: ChatGPT 인증 Codex 의 GPT-5.5 지원이 2026 년 10 월 15 일(JST) 에 종료되었습니다. API 키 인증에는 영향이 없습니다.

오래된 사양/역할 파일을 현재 사용 가능한 모델로 업데이트하세요. 단순히 이름만 바꾸지 말고, 선택 가능한 모델과 허용되는 추론 설정을 확인하세요.

권한 및 훅(Hook) 확인

Claude 의 권한이 항상 Codex 로 전파되지는 않습니다. 양쪽 모두 실행 권한을 확인하세요. 프로덕션 자격 증명 없이 연습하세요. 삭제, 외부 공개, 결제 발생 작업은 별도 승인을 요구합니다.

사용하기 전에 공개 샘플의 훅(hook)을 반드시 확인하세요. 훅은 정해진 시점에 자동 실행됩니다. 단순히 편리해 보이는 추가 기능이 아니라, 실제로 어떤 코드가 돌아가는지 파악해야 합니다.

"빠르게 만들었다"는 기준 측정하기

생성 시간만 비교하지 마세요.

• 다시 설명한 횟수

• 연동 및 수정에 걸린 시간

• 완료 기준 대비 남아있는 결함

이 요소들을 함께 고려해야 다음에도 같은 업무 분할 방식이 통할지 판단할 수 있습니다.

작은 주간 도구부터 시작하기

비개발자는 스스로 정확성을 판단할 수 있는 영역에서 가장 쉽게 성과를 냅니다.

• 문의 내역 추적

• 주문 마감일 확인

• 정렬 순서가 일관된 CSV 포맷팅

말로 설명할 수 있는 유스케이스부터 시작하세요.

마감일이 가까운 건을 먼저 띄울까요? 완료된 건은 제외할까요? 누락된 입력값이 있으면 알림을 줄까요? 이런 일상적인 요구사항이 곧 AI 의 완성도 기준이 됩니다.

코딩을 완벽히 마스터할 필요는 없습니다. 조건을 바탕으로 프로토타입을 만들고, 써보고, 고치면 됩니다. 단, 고객 데이터 시스템이나 대국민 서비스는 프로토타입 성공 여부와 무관하게 전문가의 검증이 필요합니다.

초기에는 이 정도 팀 구성이면 충분합니다.

1. Claude 가 요구사항을 정리하고

1. Codex 가 하나의 작업을 실행하며

1. 다른 관점에서 반환된 결과를 검증합니다.

유용했던 프롬프트와 검증 방법은 저장해 두어, 다음 앱을 만들 때 처음부터 다시 설명하는 수고를 덜어주세요.

읽어주셔서 감사합니다.

LINE 오픈채팅 "Niku 의 AI 스피드 전략"에서 무료 8 종 세트를 배포 중입니다.

• Codex/Claude Code 입문 가이드

• 복사/붙여넣기용 명령어 모음

• 퀵 레퍼런스 표

• 미니 앱 50 개

• 이미지 프롬프트 50 개

• yomiyasu 설치 방법

• 제목 생성기

• X 수익화 흐름 및 예상 수익

여기서 받아가세요 👇 https://x.gd/VtPmw