Claude & Codex #5 Codex Review Harness로 PR 코드 리뷰하기

이전 글에서는 GitHub Issue에서 작업 범위를 정하고, Worktree에서 Claude Code가 기능을 구현한 뒤 Local Verification과 GitHub Actions까지 연결했다.

flowchart LR
    A("GitHub Issue"):::github
    B("Claude Code"):::agent
    C("Implementation")
    D("Local Verification")
    E("Pull Request"):::github
    F("GitHub Actions"):::github
    G(["CI Passed"]):::success

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G

여기까지 오면 Build, Test, Lint 같은 자동 검증은 끝난다.
하지만 CI가 통과했다는 사실만으로 바로 Merge할 수 있는 것은 아니다. Issue의 의도를 제대로 구현했는지, Architecture Boundary를 깨뜨리지는 않았는지, Test에서 놓친 Regression 가능성은 없는지 다시 코드를 읽는 Code Review가 남아 있다.

Codex를 Reviewer로 추가해서 코드 리뷰를 진행할 생각이다. 먼저 GitHub에서 바로 사용할 수 있는 Codex Code Review를 적용해보고, 이후 Review Context와 실행 순서, Human Gate까지 직접 통제하는 Review Harness로 확장할 생각이다.

CI를 통과해도 Code Review는 필수적으로 해야한다.

CI와 Code Review는 같은 검사를 반복하는 단계가 아니다.
예를 들어 ktlintCheck는 Kotlin Style 위반을 찾을 수 있지만, Provider 전용 DTO가 Backend Contract로 노출되면서 Architecture Boundary를 깨뜨렸는지는 판단하지 못한다. 작성된 Test가 모두 통과하더라도 Test Case 자체가 빠져 있다면 그 경로는 검증되지 않는다.

검증	잘하는 것	별도로 확인할 것
Build / Test / Lint	Compile, 작성된 Test, 정적 규칙	누락된 Case, 설계 의도, Architecture
Code Review	Diff와 주변 코드의 관계	영향 범위, Regression, Contract 변화
Human	Issue Scope와 리뷰 사항 판단	수정 여부, 최종 Merge

OpenAI도 Formatting이나 Lint처럼 결정적으로 판별할 수 있는 검사는 CI에 맡기고, Repository의 동작이나 Data Boundary처럼 코드를 읽어야 하는 기준은 Code Review Rule로 관리하도록 안내한다. OpenAI Codex — Review GitHub pull requests with Codex 이번 Workflow에서는 CI가 자동 검증한 변경을 Codex가 다시 읽고, 최종 판단은 개발자가 판단한다.

개발 구현 Agent와 코드 리뷰하는 Agent를 나눈다

Claude Code는 Issue 분석부터 구현, Local Verification까지 한 작업의 흐름을 계속 보고 있다. 이 Context는 구현에는 유리하지만, Review에서는 처음 세운 전제와 판단을 이미 받아들인 상태라는 점이 영향을 줄 수 있다.

Self Review를 하지 않는다는 뜻은 아니다. 구현 직후 Diff를 확인하고 Test를 실행하는 과정은 그대로 유지한다. 다만 완성된 변경을 다른 관점에서 한 번 더 보기 위해 Implementer와 Reviewer를 분리한다.

주체	역할	Workflow
Codex	구현과 분리된 Code Review	문제 후보를 리뷰 사항으로 제시
개발자	리뷰 사항 검토 및 수정 여부 결정	이번 PR에서 처리할 항목을 판단
Claude Code	구현, 수정, Test / Build / Lint	승인된 리뷰 사항을 수정하고 재검증
GitHub PR	변경, Review, 의사결정 기록	리뷰 사항과 수정 결과를 PR에 남김
GitHub Actions	반복 가능한 자동 검증	Build / Test / Lint 결과를 검증

리뷰 사항을 찾는 일과 수정 여부를 결정하는 일을 분리하는 것이 이번 Workflow의 출발점이다.

가장 간단한 방법은 GitHub Codex Review다

GitHub Repository에 Codex Code Review를 연결하면 Pull Request에서 바로 Review를 요청할 수 있다.

@codex review

Codex는 Pull Request Diff와 Repository 지침을 읽고 GitHub에 Review를 게시한다. Automatic Review를 활성화하면 PR마다 직접 Comment를 남기지 않아도 자동으로 Review할 수 있다. OpenAI Codex — GitHub Pull Request Review

Pull Request에서 @codex review를 호출한다.

설정이 간단하고 결과가 GitHub에 바로 남는다는 점이 편하다. 개인 프로젝트에서 보조 Reviewer를 빠르게 붙이거나 별도 Review Workflow가 필요하지 않다면 이 방식만으로도 충분히 실용적이다.

직접 적용한 PR에서도 다시 확인할 가치가 있는 리뷰 사항이 나왔다.

GitHub Codex가 Pull Request에 남긴 Code Review 결과

GitHub Codex Review도 AGENTS.md의 Review Rule을 사용할 수 있다. Repository 전체 규칙은 루트에, 특정 Module의 규칙은 해당 코드와 가까운 AGENTS.md에 두는 방식이다. OpenAI Codex — AGENTS.md

여기까지가 GitHub에서 바로 사용하는 Codex Review다.

내가 원하는 Review 흐름은 개발자 검토가 먼저다

@codex review가 부족해서 다른 방법을 찾은 것은 아니다. 이번 프로젝트에서는 리뷰 사항이 GitHub에 올라가기 전에 개발자가 먼저 판단하는 흐름을 만들고 싶었다.

통제할 부분	원하는 방식
Context	PR, Issue, Root / Module AGENTS.md, 실제 Diff
Review Target	마지막 Commit이 아닌 base ... HEAD
리뷰 사항 게시	Codex 결과를 바로 GitHub에 올리지 않음
개발자 검토	사람이 먼저 FIX, OUT_OF_SCOPE 등을 판단
수정	승인된 리뷰 사항만 Claude Code가 수정

GitHub Codex Review가:

Codex Review
→ GitHub PR Review
→ 개발자 판단

이라면, 내가 원하는 구조는 다음과 같다.

Codex Review
→ 개발자 판단
→ 선택 리뷰 사항만 GitHub PR Review

예를 들어 Codex가 세 가지 리뷰 사항을 냈더라도:

F-001 → OUT_OF_SCOPE
F-002 → FIX
F-003 → FIX

처럼 Issue Scope에 따라 처리 여부는 달라질 수 있다.
AI는 문제 후보를 찾고, 개발자가 이번 PR에서 처리할 리뷰 사항을 고른다. 이 흐름을 반복 가능하게 묶은 것이 이번 Review Harness다.

모노레포에서는 Workflow와 Review Rule을 분리한다

현재 프로젝트는 android/와 backend/가 같은 Repository에 있지만 책임과 기술 스택은 다르다.
그래서 Review Workflow는 루트에서 공유하고, Review Rule은 적용되는 코드 가까이에 둔다.

repository/
├─ AGENTS.md
├─ CLAUDE.md
├─ .codex/
│  └─ config.toml
├─ .agents/
│  └─ skills/
│     └─ pr-review/
│        └─ SKILL.md
├─ android/
│  ├─ AGENTS.md
│  └─ ...
├─ backend/
│  ├─ AGENTS.md
│  └─ ...
└─ infra/

구성	역할
루트 AGENTS.md	공통 Architecture / Security / Contract Rule
android/AGENTS.md	Android 전용 Review Rule
backend/AGENTS.md	Backend 전용 Review Rule
.agents/skills/pr-review/SKILL.md	공통 Review Workflow
.codex/config.toml	Codex 프로젝트 기본 설정
개발자	리뷰 의견 검토
gh + GitHub Review API	선택 리뷰 사항 게시
Claude Code	승인 리뷰 사항 수정

Android와 Backend에서 달라지는 것은 무엇을 지적할 것인가이지 어떤 순서로 Review할 것인가가 아니다. 그래서 Skill을 Module마다 복제하지 않고 루트에 하나만 둔다.

Codex 설정과 Review Rule을 Repository에 둔다

Codex의 프로젝트 기본 설정은 루트 .codex/config.toml에 둔다. Native /review에서 별도의 Review Model을 사용하고 싶다면 review_model, Reasoning 수준은 model_reasoning_effort로 관리할 수 있다.

review_model = "<supported-review-model>"
model_reasoning_effort = "medium"

OpenAI Codex — Configuration

현재는 Android와 Backend가 같은 Reviewer 설정을 사용하므로 루트 설정 하나면 충분하다. Codex 로그인 정보, GitHub Token, OAuth Token, API Key 같은 Credential은 Repository에 Commit하지 않는다.

Review Rule은 AGENTS.md 계층으로 나눈다

별도의 review-policy.md 하나에 모든 규칙을 몰아넣지 않는다. AGENTS.md가 이미 Architecture와 개발 규칙의 단일 기준 역할을 하기 때문이다. 루트에는 두 Module이 함께 지켜야 할 Boundary를 둔다.

## Code Review Rules

When reviewing changes, prioritize:
1. Architecture boundary violations
2. Functional regressions
3. API contract changes
4. Security exposure
5. Missing tests for changed behavior

Do not report formatting or style issues already enforced by CI.
Respect the linked Issue's Scope and Out of Scope.

### Architecture boundaries
- Android owns Provider authentication and authorization.
- Android communicates directly with Provider APIs.
- Backend manages provider-independent metadata.
- Provider credentials or tokens must not be stored in Backend unless explicitly approved.
- Provider SDK or Provider-specific DTOs must not leak across module boundaries.

Module별 규칙은 필요한 부분만 해당 AGENTS.md에 둔다.

backend/AGENTS.md	android/AGENTS.md
외부 I/O는 DB Transaction 밖에서 수행	Provider 인증과 권한은 Android 책임
File / FileLocation 책임 분리	Provider API는 StorageClient 뒤로 캡슐화
이름만으로 File 병합 금지	Provider DTO가 공통 UI / Domain으로 누출되지 않음
Persistence 변경 시 통합 Test 확인	Room Metadata Cache와 Offline 조회 유지
Provider 타입을 Backend Contract에 노출하지 않음	Backend에는 Provider-independent Metadata만 전달

이렇게 하면 같은 Architecture Rule을 Skill과 별도 Policy 파일에 다시 복사하지 않아도 된다. 별도 Policy 파일은 Rule이 너무 길어져 예시와 세부 설명을 분리할 필요가 생길 때만 추가하면 된다.

반복되는 Review 절차는 루트 Skill로 만든다

pr-review Skill은 Architecture Rule을 다시 적는 파일이 아니다.
어떤 Context를 읽고, 어떤 순서로 Review하고, 어디에서 대기할지를 정의한다.

.agents/
└─ skills/
   └─ pr-review/
      └─ SKILL.md

모노레포에서는 Repository 루트에서 Review를 시작했을 때 하위 Module의 AGENTS.md가 항상 자동 적용된다고 가정하지 않는다. 그래서 Skill이 PR 변경 경로를 먼저 확인하고 적용할 Module Rule을 명시적으로 읽도록 만든다.

---
name: pr-review
description: Review a GitHub Pull Request using Codex, present findings for human triage, and publish only explicitly accepted findings to the PR.
---

# PR Review
1. Read the Pull Request, linked Issue, base branch, head commit, and diff.
2. Identify which modules changed.
3. Always read the root AGENTS.md.
4. For backend/** changes, also read backend/AGENTS.md.
5. For android/** changes, also read android/AGENTS.md.
6. Review base...HEAD without modifying source code.
7. Return stable finding IDs such as F-001, F-002, ...
8. STOP and wait for Human Triage.
9. Publish only explicitly selected findings.
10. Before publishing, verify that the PR HEAD still matches the reviewed commit.

Do not use CLAUDE.md as Codex review policy unless explicitly instructed.
Do not use APPROVE or REQUEST_CHANGES automatically.

핵심은 두 가지다.
PR 변경 Module에 맞는 Rule을 읽고, 리뷰 사항을 만든 뒤 반드시 멈춘다. CLAUDE.md는 Claude Code 전용 동작에 사용하고, 두 Agent가 함께 알아야 할 Architecture Rule은 AGENTS.md에 둔다.

Repository의 pr-review Skill이 Codex에서 인식된 상태

이제 Review Workflow도 Repository와 함께 관리한다.

리뷰 기준과 개발 규칙을 문서와 Repository에 남겨두면, 담당자가 바뀌어도 기존 팀이 유지해 온 개발 기준과 리뷰 수준을 이어갈 수 있다.

실제 PR에서 Review Harness를 실행한다

설정이 끝났으면 실제 PR에 적용한다. 이번에는 Backend 변경이 포함된 PR을 대상으로 실행했다.

Review Target은 base ... HEAD다

PR에 Commit이 여러 개 있더라도 마지막 Commit 하나만 보지 않는다. Base Branch에서 현재 HEAD까지의 최종 Diff가 Review 대상이다.

Base          → backend
Head          → feat/backend/metadata-ingestion
Review Target → backend ... HEAD

Review 당시 HEAD SHA도 함께 기록한다.

Review #1 → 1a2b3c4
Claude Fix
Review #2 → 5d6e7f8

GitHub Inline Review는 Diff의 Line과 연결되므로 게시하기 전에는 Review 당시 SHA와 현재 PR HEAD가 같은지도 다시 확인한다. GitHub Docs — Pull Request Review Comments

GitHub 연결은 Codex에서 사용한다

이번 구현에서는 GitHub 게시를 위해 별도의 API Key나 gh 호출 절차를 Skill에 넣지 않는다. Codex에 연결된 GitHub 기능을 그대로 사용한다. Skill에는 어떤 PR을 읽고 어떤 Finding을 게시할지만 정의하고, 인증 정보는 Repository에 저장하지 않는다. Review 전에 Codex가 해당 Repository와 Pull Request에 접근할 수 있는지만 확인하면 된다.

$pr-review로 Review를 시작한다

Skill이 인식된 상태라면 요청은 짧다.

$pr-review PR #7 리뷰해줘

이 요청으로 PR, Issue, Base / HEAD, Diff와 적용할 AGENTS.md를 모은 뒤 Review를 시작한다.

pr-review Skill을 호출해 PR Context와 적용할 프로젝트 규칙을 확인한다.

이번 PR은 Backend 변경이므로 루트 AGENTS.md와 backend/AGENTS.md가 Review Context에 들어간다. Android 변경이 함께 있다면 android/AGENTS.md도 추가한다.

리뷰를 구조화하고 여기서 멈춘다

Review 결과는 F-001, F-002처럼 안정적인 ID로 정리한다.

PR Context와 Module Rule을 적용해 리뷰 사항을 구조화한 결과

여기서 코드를 수정하지도 않고 GitHub에 게시하지도 않는다.

이번 실행에서는 기존 GitHub Codex Review에서 보였던 Android consumer 관련 리뷰 사항이 나오지 않았다. 같은 코드라도 Issue Scope와 Backend Rule을 함께 넣으면서 Review의 초점이 달라진 것이다. 다만 이것을 두 방식의 일반적인 성능 차이라고 보기는 어렵고, 이번 PR에서 Context와 Review Rule을 다르게 적용한 결과로 보는 편이 정확하다.

개발자 검토 후 선택한 리뷰만 GitHub에 올린다

리뷰 사항이 나왔다고 전부 수정하지 않는다. 개발자가 Issue Scope와 Architecture를 다시 보고 처리 상태를 정한다.

flowchart LR
    A("Codex"):::agent
    B(["개발자 검토"]):::human
    C("선택된 리뷰 사항")
    D("GitHub PR Review"):::github

    A --> B
    B --> C
    C --> D

상태	의미
FIX	현재 PR에서 수정
OUT_OF_SCOPE	유효하지만 현재 Issue 범위 밖
FALSE_POSITIVE	Reviewer의 잘못된 판단
DISCUSSION	추가 판단이 필요한 항목

처리할 리뷰 사항을 정했다면 다음처럼 요청한다.

개발자 검토가 끝난 뒤 선택한 리뷰 사항만 GitHub에 게시하도록 요청한다.

GitHub 게시에는 Codex의 GitHub 연결을 사용한다

GitHub Pull Request Review는 REST API로 직접 만들 수 있지만, 이번 Review Harness에서는 Review 게시 로직을 별도 Script나 Service로 구현하지 않았다. 대신 Codex에 GitHub를 연결하고, 개발자 검토를 통해 선택된 코드 리뷰의 게시까지 같은 Codex Workflow 안에서 처리한다.

flowchart TD
    A("Local Codex Review"):::agent
    B("리뷰 사항 생성")
    C(["개발자 검토"]):::human
    D("게시할 리뷰 사항 선택")
    E("Codex GitHub Integration"):::agent
    F("GitHub PR Review"):::github

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

이번 Workflow에서는 Codex가 APPROVE나 REQUEST_CHANGES를 자동으로 결정하지 않고 COMMENT로 게시한다. 최종 승인과 Merge 여부는 개발자가 판단한다.

Human이 선택한 Finding이 Codex의 GitHub 연결을 통해 PR Inline Review로 등록된 결과

GitHub Review를 연결하는 방법은 하나만 있는 것은 아니다

이번 프로젝트에서는 Codex의 GitHub 연결을 사용했지만, Review를 GitHub에 연결하는 방법은 어디까지 직접 제어하고 자동화할 것인지에 따라 달라진다.

방식	구조	적합한 경우
Codex GitHub Integration	Codex → GitHub PR Review	개발자가 Codex에서 Review하고 Human Triage 후 선택한 Finding을 바로 게시할 때
GitHub REST API / gh api	Script 또는 Service → GitHub API	Review Payload, 인증, 재시도, 게시 정책을 직접 제어해야 할 때
Codex GitHub Action	Pull Request Event → GitHub Actions → Codex	PR 생성·수정 시 Review 실행 자체를 자동화할 때
MCP	Codex → MCP Tool → External System	GitHub뿐 아니라 Issue Tracker나 사내 Tool까지 같은 Tool Interface로 연결할 때
Codex App Server	Application → Codex	자체 UI나 제품 안에 Codex Review 경험을 통합할 때

GitHub REST API를 직접 사용하는 경우

Review 게시를 별도 프로그램에서 직접 제어해야 한다면 GitHub Pull Request Review API를 사용할 수 있다. gh api는 같은 GitHub API를 CLI에서 호출하는 방법이다.

flowchart LR
    A("Review Service")
    B("GitHub REST API"):::github
    C("Pull Request Review")

    A --> B
    B --> C

이 방식에서는 commit_id, path, line, side 같은 Review Payload부터 인증, 실패 처리와 Retry까지 직접 관리할 수 있다. 여러 Repository의 Review 게시를 하나의 내부 Service에서 운영하거나, 별도의 승인 시스템을 거쳐야 한다면 이런 구조가 더 적합하다.

{
  "commit_id": "1a2b3c4",
  "event": "COMMENT",
  "comments": [
    {
      "path": "backend/src/main/...",
      "line": 28,
      "side": "RIGHT",
      "body": "[F-002] size=null validation 문제"
    }
  ]
}

Pull Request Event에서 자동 Review하려면 GitHub Action을 사용한다

개발자가 Local Codex에서 Review를 시작하는 대신 Pull Request 생성이나 업데이트를 Trigger로 Codex를 자동 실행하고 싶다면 Codex GitHub Action을 사용할 수 있다.

flowchart LR
    A("Pull Request Event")
    B("GitHub Actions"):::github
    C("Codex"):::agent
    D("Review Result")

    A --> B
    B --> C
    C --> D

OpenAI의 openai/codex-action은 GitHub Actions Workflow에서 Codex를 실행할 수 있도록 제공된다. CI에서 반복 가능한 Review Job을 운영하려는 경우 Local Review Harness와 다른 선택지가 된다. OpenAI Codex — GitHub Action

여러 외부 Tool을 연결하려면 MCP를 사용할 수 있다

GitHub 하나의 Review 게시보다 더 넓게, Codex가 Issue Tracker나 문서 시스템, 사내 Tool까지 호출해야 한다면 MCP를 Integration Layer로 둘 수 있다.

flowchart LR
    A("Codex"):::agent
    B("MCP")
    C("GitHub"):::github
    D("Issue Tracker")
    E("Internal Tool")

    A --> B
    B --> C
    B --> D
    B --> E

Codex는 프로젝트의 .codex/config.toml에도 MCP Server를 구성할 수 있다. 다만 이번 프로젝트처럼 GitHub PR Review 게시만 필요하다면 별도의 MCP Server를 추가하지 않고 Codex의 GitHub 연결을 사용한다. OpenAI Codex — MCP

자체 UI에 Codex를 통합하려면 App Server를 사용할 수 있다

사람이 Codex UI를 직접 사용하는 것이 아니라 자체 Application 안에 Codex의 대화, 승인, Review 경험을 통합해야 한다면 Codex App Server를 사용할 수 있다. OpenAI Codex — App Server

flowchart LR
    A("Application")
    B("Codex App Server")
    C("Codex Review"):::agent

    A --> B
    B --> C

현재 Review Harness에서는 Codex Review → Human Triage → Codex GitHub Integration → GitHub PR Review까지만 연결한다. 다른 방식은 Review 실행이나 게시를 별도 시스템에서 자동화·통제해야 할 때 선택할 수 있다.

이제 GitHub에는 Codex가 처음 찾은 모든 후보가 아니라 현재 PR에서 처리하기로 결정한 Finding만 남는다.

Local Review Harness와 GitHub Codex Review를 비교했다

같은 Claude Code 구현 결과를 두 방식으로 Review해봤다.

Local Review Harness에서 프로젝트 Context를 적용한 Review 결과

같은 변경에 대한 GitHub Codex Review 결과

둘 다 같은 변경을 보지만 Review가 만들어지는 과정은 다르다.

GitHub Codex Review	Local Review Harness
@codex review로 GitHub에서 실행	$pr-review로 Local Codex에서 실행
Finding이 GitHub에 바로 게시	Finding을 Local에서 먼저 구조화
게시 후 Human 판단	Human Triage 후 선택 Finding만 게시
설정이 간단함	PR / Issue / Module Rule과 Gate를 직접 통제

Local Review Harness가 Backend Module Rule과 Issue Scope에 더 맞춰진 리뷰 결과를 내는 모습을 확인했다. 반면 GitHub Codex Review는 별도 Harness 구성 없이 바로 사용할 수 있다는 장점이 있다.

어느 쪽이 항상 더 좋은 Reviewer라는 결론보다는, 같은 Codex라도 어떤 Context와 Workflow 안에서 실행하느냐에 따라 결과와 운영 방식이 달라질 수 있다는 점이 더 중요했다.

/review는 Reviewer이고 Skill은 Workflow다

Codex에는 Base Branch와의 Diff, 특정 Commit, Commit되지 않은 변경 등을 대상으로 동작하는 Native /review가 있다. OpenAI Codex — Code Review 이번 Harness에서 $pr-review를 Entry Point로 두는 이유는 /review 자체를 대체하기 위해서가 아니다.

/review → Codex의 Native Reviewer

flowchart LR
    C("pr-review Skill")
    D("PR Context 수집")
    E("Module Rule 선택")
    F("Review 실행"):::agent
    G("Finding 구조화")
    H(["Human Gate"]):::human
    I("GitHub 게시"):::github

    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I

즉 Reviewer를 새로 만드는 것이 아니라 Codex Review 앞뒤에 프로젝트 Context와 운영 절차를 붙인다.

Claude Code는 게시된 Review만 수정한다

개발자 검토와 GitHub 게시가 끝나면 다시 Claude Code로 돌아간다.

flowchart LR
    A("Claude Code"):::agent
    B("Implementation")
    C("Codex Review"):::agent
    E(["개발자 검토"]):::human
    G("Claude Code"):::agent

    A --> B
    B --> C
    C --> E
    E --> G

GitHub PR에는 Human이 채택한 Finding만 남아 있으므로 다음처럼 요청하면 된다.

PR #7 리뷰 반영해줘.

Claude용 규칙도 이 경계만 명확하게 둔다.

## Reviewed PR Fix

When fixing a reviewed PR:

1. Read the linked Issue and PR description.
2. Read unresolved GitHub Review comments.
3. Only address accepted review findings.
4. Respect Issue Out of Scope.
5. Run module Local Verification.

수정이 끝나면 Local Verification과 GitHub Actions를 다시 통과시킨다. 최신 HEAD는 다시 Codex로 Review한다. Review #1과 Review #2는 서로 다른 HEAD를 대상으로 한다. 기존 Finding이 해결됐는지뿐 아니라 수정 과정에서 새로운 Regression이 생기지 않았는지도 다시 확인한다.

claude code 코드리뷰 개선

최종 Review Harness 구조

전체 Workflow는 다음과 같다.

flowchart TD
    A("GitHub Issue"):::github
    B("Claude Code<br/>구현 · 로컬 검증"):::agent
    C("Pull Request"):::github
    D("GitHub Actions"):::github
    E("Codex Review"):::agent
    F(["개발자 검토"]):::human
    G("GitHub PR Review"):::github
    H("Claude Code Fix"):::agent
    I(["Merge"]):::success

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F -->|"수정 필요"| G
    G --> H
    H --> D
    F -->|"승인"| I

구현과 Review를 하나의 흐름으로 연결했다

이번 글에서는 Claude Code가 구현하고, Codex가 Review하며, 개발자가 Finding을 판단하는 흐름을 Repository와 GitHub PR에 연결했다.

Review 기준은 Root와 Module의 AGENTS.md에 나누고, Codex 설정은 .codex/config.toml, 반복되는 Review 절차는 Root pr-review Skill에 둔다.
Codex가 찾은 Finding은 바로 GitHub에 게시하지 않고 개발자가 먼저 검토한 뒤, 선택한 항목만 PR Review로 남긴다. 이후 수정은 다시 Claude Code가 맡고 Verification과 Re-review를 반복한다.

Claude Code
→ Implementation
→ CI
→ Codex Review
→ Human Triage
→ GitHub PR Review
→ Claude Code Fix
→ Verification
→ Re-review

이렇게 구현, Review, 판단, 수정의 책임을 분리하면서도 하나의 Pull Request 안에서 계속 이어지는 개발 흐름을 만들었다.

지금까지는 Agent에게 어떤 Context를 제공하고, 구현과 Review를 어떻게 연결할 것인지를 중심으로 다뤘다. 다음 글에서는 범위를 개발 과정 전체로 넓혀 Context, Workspace, Tool, Permission, Verification, CI, Feedback, Human Gate를 어떻게 하나의 실행 환경으로 구성하는지 Harness Engineering 관점에서 정리한다.

참고 문서

• OpenAI Codex — GitHub Pull Request Review
• OpenAI Codex — Code Review
• OpenAI Codex — Configuration Reference
• OpenAI Codex — Customization
• OpenAI Codex — AGENTS.md
• OpenAI — Custom code review rules for Codex