제4부 · Codex로 직접 만들기

월요일 아침 주간 회의에서 누리상사 경영지원팀 오세린 차장은 제3부의 방법으로 만든 비품 신청 페이지를 화면에 띄웠습니다. 한 달 동안 신청이 백 건 넘게 들어왔고, 메일로 받은 신청을 엑셀에 옮겨 적던 일은 사라졌습니다. 발표가 끝나자 팀장이 한 가지를 물었습니다. "이거 Claude가 만들고 Claude가 확인한 거죠? 다른 눈으로 본 적은 있어요?" 오 차장은 바로 답하지 못했습니다.

30단계에서 우리는 "다 됐다"는 말을 그대로 믿지 않는 법을 익혔습니다. 바뀐 파일을 묻고, 배포된 주소를 직접 열고, 테스트를 되돌려 시험했습니다. 그래도 남는 빈틈이 있습니다. 만든 쪽과 검토한 쪽이 같은 에이전트라면 같은 가정 안에서 보게 됩니다. 29단계의 서브에이전트가 그 빈틈을 조금 줄였다면, 이번 부에서는 아예 다른 회사가 만든 에이전트를 옆에 둡니다. OpenAI의 Codex입니다. 훈련 방식과 습관이 다른 에이전트는 놓치는 곳도 다를 가능성이 큽니다. 회사가 이미 ChatGPT 요금제를 쓰고 있다면 새로 도입할 것도 많지 않고, 한쪽 도구가 멈추거나 사용량 한도에 걸린 날에도 일을 이어 갈 수 있습니다.

Codex는 터미널에서 쓰는 CLI, ChatGPT 데스크톱 앱 안의 Codex, 웹(chatgpt.com/codex)의 클라우드 작업, GitHub의 코드 리뷰까지 여러 곳에서 씁니다. 겉모습은 달라도 제3부에서 익힌 원리는 그대로 통합니다. 규칙은 파일에 적고, 큰일은 계획부터 받고, 작업 전후로 커밋하고, 끝났다는 보고는 직접 확인합니다. 이름이 바뀌는 곳이 몇 군데 있을 뿐입니다. CLAUDE.md는 AGENTS.md가 되고, 허락 요청은 승인 방식과 샌드박스라는 두 층으로 나뉩니다.

이 부는 다음 순서로 진행합니다. 31~34단계에서 Codex를 설치하고 규칙과 권한을 정한 뒤, 코딩 없는 파일 정리로 손을 풉니다. 35~38단계에서는 Codex만의 쓰임새로 넓혀 갑니다. 여러 작업을 클라우드에서 나란히 돌리고, GitHub의 PR 리뷰를 맡기고, 설정과 스킬과 MCP로 범위를 넓히고, 마지막으로 Claude Code와 Codex를 한 저장소에서 함께 씁니다. 39단계에서는 제3부와 제4부에서 만든 도구를 배포된 주소로 발표하며 제2편을 마무리합니다.

미리 밝혀 둡니다. Codex의 명령, 화면 구성, 요금제 범위, 모델 이름은 몇 주 사이에도 바뀝니다. 이 책에 적은 모델 이름과 가격은 집필 시점(2026년 9월) 기준이고, 명령과 메뉴 이름은 길잡이로만 받아들여 주십시오. 실제 절차는 공식 문서(learn.chatgpt.com/docs)에서 확인하시기 바랍니다.

제4부를 마치며

아홉 단계를 지나는 동안 오세린 차장은 에이전트 하나에 기대던 사람에서, 두 에이전트에게 일을 나눠 주고 서로 검토하게 하는 사람이 됐습니다. 새로 배운 명령은 많았지만 원리는 제3부와 같았습니다. 규칙은 파일에 적고, 큰일은 계획부터 받고, 작업 전후로 커밋하고, 끝났다는 보고는 배포된 주소에서 직접 확인합니다. 달라진 것은 확인의 겹이 하나 늘었다는 점입니다. 만든 쪽이 아닌 다른 에이전트가 PR을 읽고, 사람은 그 지적을 화면에서 재현해 받아들일지 정합니다.

두 도구를 함께 쓰면 편해지는 만큼 관리할 것도 늘어납니다. 규칙 파일이 둘이 되고, 구독이 둘이 되고, 사용량 한도도 따로 봐야 합니다. 그래서 이 부의 마지막 습관은 기록입니다. 어느 일을 어디에 맡겼는지, 교차 검토가 무엇을 잡아냈는지, 어느 쪽 한도에 먼저 닿았는지를 한 달만 적어 보면, 다음 달에 무엇을 바꿀지가 보입니다. 아래 항목을 하나씩 확인해 보십시오.

• ☐ codex --version이 버전 번호를 돌려주고, codex login status로 ChatGPT 계정 로그인을 확인했습니다.
• ☐ 내 도구의 저장소 맨 위에 AGENTS.md가 있고, CLAUDE.md와 같은 문장의 공통 규칙이 들어 있습니다.
• ☐ 승인 방식과 샌드박스를 내 작업에 맞게 골랐고, 전부 허용 설정은 쓰지 않았습니다.
• ☐ 코딩 없는 파일 정리 한 건을 Codex로 처리하고, 건수와 원본 보존을 직접 확인했습니다.
• ☐ 클라우드 환경을 만들어 인터넷을 Off로 둔 채 두 작업을 나란히 돌리고, 결과를 PR로 받아 합쳤습니다.
• ☐ 내 저장소에 Codex 코드 리뷰를 켜고, 지적마다 받아들임·보류·반박 가운데 하나를 골라 이유를 남겼습니다.
• ☐ config.toml의 주요 설정을 읽을 수 있고, codex exec로 읽기 전용 점검 하나를 돌려 봤습니다.
• ☐ 한쪽이 만든 변경을 다른 쪽이 고치지 않고 검토만 하게 하는 교차 검토를 끝까지 해 봤습니다.
• ☐ 제2편 결과물을 배포된 주소로 발표하고, 주소·저장소·두 규칙 파일·핵심 프롬프트·교차 검토 기록을 함께 넘겼습니다.

이 부의 과제

과제 이름. 제3부에서 만든 사내 도구를 Codex로 한 단계 넓히고, 두 에이전트의 교차 검토를 거쳐 배포합니다.

할 일. 1. 제3부 도구의 저장소에 AGENTS.md를 만들고, CLAUDE.md와 같은 문장의 공통 규칙 섹션과 ## Code Review Rules 섹션을 넣습니다. 2. 새 기능이나 개선 두 가지를 정해, 서로 겹치는 파일이 없게 나눈 뒤 Codex(Local, Worktree, Cloud 가운데 하나 이상)에게 맡깁니다. 3. 결과를 PR로 올리고 @codex review로 리뷰를 받습니다. 지적마다 판단과 이유를 PR 댓글로 남깁니다. 4. 같은 PR을 Claude Code에게 고치지 말고 검토만 하게 해서, 두 검토 결과를 비교합니다. 5. 받아들인 지적만 고치고 합친 뒤, 배포된 주소를 휴대폰으로 열어 가장 중요한 동작을 확인합니다. 6. codex exec로 읽기 전용 점검 하나를 만들어 한 번 돌리고, 결과 파일을 남깁니다.

제출물. 1. 배포된 주소 하나. 본줄 기준의 본 주소여야 합니다. 2. GitHub 저장소 주소. 비공개로 두고, 평가자에게 읽기 권한을 줍니다. 3. 저장소 맨 위의 AGENTS.md와 CLAUDE.md. 공통 규칙 섹션이 같은 문장이어야 합니다. 4. Codex 리뷰를 받은 PR 주소 하나. 지적마다 판단과 이유가 댓글로 남아 있어야 합니다. 5. 교차 검토 비교표. Codex 리뷰와 Claude Code 검토가 각각 무엇을 지적했는지, 겹친 것과 한쪽만 잡은 것, 사람이 어떻게 판단했는지를 적습니다. 6. codex exec 점검 명령과 그 결과 파일. 7. 한 쪽짜리 메모. 어떤 일을 어느 에이전트에 맡기기로 했는지와 그 이유, 한 달 동안 기록할 항목(한도에 닿은 날, 교차 검토가 잡아낸 문제)을 적습니다.

완료 기준. - 평가자가 자기 휴대폰으로 주소를 열고, 새로 넣은 기능을 도움 없이 끝까지 써 봅니다. - PR의 리뷰 지적 가운데 판단이 적히지 않은 것이 하나도 없습니다. - 교차 검토 비교표에 한쪽 에이전트만 잡아낸 항목이 하나 이상 있거나, 없었다면 없었다고 적혀 있습니다. - 평가자가 AGENTS.md와 CLAUDE.md의 공통 규칙을 나란히 놓았을 때 글자까지 같습니다. - codex exec 점검을 돌린 뒤 git status에 바뀐 파일이 없습니다. - 저장소, 커밋 기록, PR 댓글, 클라우드 환경 설정 어디에도 인증키·비밀번호·실제 고객 정보가 없습니다.

여기까지 왔다면 에이전트 하나에게 맡기고 확인하는 법에서 한 걸음 나아가, 두 에이전트에게 일을 나누고 서로 검토하게 하는 법을 손에 익힌 셈입니다. 39단계의 발표로 제2편도 마무리했습니다. 다음 제3편의 제5부에서는 일하는 곳을 폴더 밖으로 넓힙니다. 로그인해야 들어가는 사이트를 돌며 조사하고 입력하는 일을 브라우저 안의 AI에게 맡기고, 44단계에서는 브라우저 밖의 앱까지 맡깁니다. 대상이 파일에서 화면으로 바뀌어도 여기서 익힌 원칙, 즉 읽기 전용에서 시작하고 만든 쪽과 보는 쪽을 나누고 판단은 사람이 한다는 원칙은 그대로 따라갑니다. 뒤에서 자동화(74~76단계)와 에이전트 평가(94단계)를 다룰 때도 다시 쓰입니다.