Claude & Codex #4 Claude Code로 Issue부터 PR까지 개발하기

이전 글에서는 AGENTS.md와 CLAUDE.md를 이용해 Claude Code와 Codex가 프로젝트를 어떤 기준으로 이해해야 하는지 정리했다. 이번에는 그 기준 위에서 하나의 기능을 개발한다.
GitHub Issue에서 이번 작업의 목표와 범위를 정하고, Worktree로 작업 공간을 분리한 뒤 Claude Code가 분석부터 구현과 Local Verification까지 진행한다. 변경이 Pull Request로 올라가면 GitHub Actions가 Build, Test, Lint를 다시 검증한다.

CI/CD Pipeline 자체를 어떻게 구축하는지는 별도 글에서 다룬다. 이번 글의 범위는 Issue 작성부터 Claude Code 구현, Local Verification, Pull Request, GitHub Actions 검증까지다.

프로젝트 기준과 이번 작업의 범위를 나눈다

AGENTS.md와 CLAUDE.md에는 여러 작업에서 계속 유지되어야 할 프로젝트 기준이 들어 있다. Android와 Backend의 책임이 어디에서 나뉘는지, 어떤 Architecture를 유지해야 하는지, Agent가 임의로 변경하면 안 되는 것은 무엇인지 같은 내용이다.

반면 기능 하나를 개발할 때 필요한 정보는 작업마다 달라진다. 이번에 무엇을 만들 것인지, 어디까지 수정할 것인지, 어떤 상태가 되면 완료로 볼 것인지는 현재 작업에 대한 Context다.

구분	답해야 하는 질문	관리 위치
Project Context	이 프로젝트에서는 어떤 기준으로 개발하는가?	`AGENTS.md`, `CLAUDE.md`
Task Context	이번 작업에서는 무엇을 만들고 어디까지 수정하는가?	GitHub Issue
Current State	지금 코드는 어떻게 구현되어 있는가?	Repository

하나가 다른 하나로 바뀌는 것이 아니다. Claude Code는 세 정보를 함께 보고 이번 작업을 판단한다.

Project Context
AGENTS.md / CLAUDE.md
        +
Task Context
GitHub Issue
        +
Current State
Repository
        ↓
Claude Code

그래서 이번 Workflow에서는 기능 개발의 시작점을 GitHub Issue로 잡았다.

GitHub도 Issue를 아이디어와 작업을 추적하는 기능으로 제공하며, Issue Template과 Issue Form을 이용해 필요한 정보를 일정한 형식으로 받을 수 있도록 지원한다. GitHub Docs — Issue and Pull Request Templates

이번에 진행할 Provider 독립 Metadata 수신 API도 기능 이름만 적어두지 않고 Claude Code가 구현 전에 확인해야 할 내용을 Issue 안에서 나눠 작성했다.

Provider 독립 Metadata 수신 API GitHub Issue

GitHub Issue

GitHub가 특정 Issue 형식을 강제하는 것은 아니다. 이번 프로젝트에서는 개발에 필요한 정보를 다음 다섯 항목으로 나눴다.

항목	역할	확인할 질문
`Goal`	작업이 끝났을 때 만들어져야 할 결과	무엇을 해결하려는가?
`Scope`	이번 변경에서 구현할 범위	어디까지 수정할 것인가?
`Acceptance Criteria`	완료 여부를 확인할 조건	어떤 결과가 나오면 완료인가?
`Architecture Constraints`	구현 중 넘지 말아야 할 설계 경계	어떤 방식으로 구현하면 안 되는가?
`Out of Scope`	의도적으로 제외할 범위	이번에는 무엇을 하지 않는가?

등록된 Provider 독립 Metadata 수신 API Issue

[Backend] Provider 독립 Metadata 수신 API Issue

Goal과 Scope는 방향과 구현 범위를 나눈다

먼저 Goal에는 구현 방법보다 이번 작업이 끝났을 때 만들어져야 할 결과를 적었다.

Android가 외부 Storage Provider에서 조회한 파일 Metadata를
Provider에 종속되지 않은 형태로 Backend에 전달하고 저장할 수 있게 한다.

Backend는 전달받은 Metadata를
기존 File / FileLocation Domain에 반영한다.

여기에는 어떤 Controller나 Service를 추가할지 적지 않았다. Repository의 현재 구조를 분석한 결과에 따라 구현 방법은 달라질 수 있기 때문이다.

반면 Scope에서는 Goal을 달성하기 위해 이번 변경에서 다룰 범위를 구체화했다.

## Scope

- Provider 독립 Metadata Request DTO 정의
- StorageSource 기준 Metadata 수신 API 구현
- Request DTO를 기존 공통 Metadata Model로 변환
- 기존 File / FileLocation Persistence 로직 재사용
- 신규 파일 생성 및 기존 파일 Metadata 갱신
- StorageSource의 마지막 동기화 시각 갱신
- 정상 / 중복 / StorageSource 미존재 경로 테스트

Goal이 어디까지 가야 하는지를 정한다면 Scope는 그 결과를 만들기 위해 이번 변경에서 어디까지 손댈지를 정한다.
이 구분을 해두면 Claude Code가 Repository를 읽다가 관련 코드를 발견했다는 이유만으로 작업을 계속 넓히는 것을 막기 쉽다.

Google의 Code Review 가이드도 하나의 변경을 가능한 한 작고 독립적인 단위로 유지하고, 서로 다른 목적의 변경이나 큰 Refactoring을 한 번에 섞지 않는 것을 권장한다. Google Engineering Practices — Small CLs

이번 Issue가 Metadata 수신 API 구현이라면 관련 Service 전체를 다시 설계하거나 Android UI까지 함께 수정하지 않는 식으로 같은 기준을 적용했다.

Acceptance Criteria는 구현 목록이 아니라 결과를 확인한다

Scope와 Acceptance Criteria는 가장 쉽게 섞이는 부분이다.

예를 들어:

- MetadataService 구현
- Controller 추가
- Repository Method 추가

는 Scope에는 들어갈 수 있다.

하지만 이 내용을 그대로 Acceptance Criteria로 사용하면 코드를 추가했다는 사실만 알 수 있다. 실제 요청이 정상적으로 처리되는지, 같은 파일이 다시 들어왔을 때 중복 데이터가 생기지 않는지는 확인할 수 없다.

그래서 완료 조건은 동작 결과를 기준으로 작성했다.

## Acceptance Criteria

- Android가 전달한 Metadata가 File / FileLocation에 저장된다.
- 동일한 `(storageSourceId, externalId)`를 다시 전달해도 중복 FileLocation이 생성되지 않는다.
- 기존 Metadata가 다시 전달되면 파일명, MIME Type, Size, Path, 수정 시각이 갱신된다.
- 존재하지 않는 StorageSource 요청은 명확한 오류 응답을 반환한다.
- 기존 Backend Test가 모두 통과한다.
- `build`, `test`, `ktlintCheck`가 통과한다.

Scope와 Acceptance Criteria의 차이는 다음처럼 볼 수 있다.

구분	예시	판단 기준
Scope	API 추가, Persistence 연동, Test 작성	필요한 구현이 포함됐는가?
Acceptance Criteria	중복 저장이 발생하지 않음, 잘못된 요청이 실패함	결과가 요구사항을 만족하는가?

Acceptance Criteria 자체도 AI 개발을 위해 새로 만든 개념은 아니다. Atlassian은 User Story의 완료 여부를 확인할 수 있는 조건으로 Acceptance Criteria를 설명한다. Atlassian — User Stories and Acceptance Criteria

이렇게 나누면 Claude Code는 Scope를 보고 수정 범위를 판단하고, 구현이 끝난 뒤에는 Acceptance Criteria를 다시 보며 요구사항을 만족했는지 확인할 수 있다.

Architecture Constraints와 Out of Scope는 구현 방향을 제한한다

기능이 정상적으로 동작한다고 현재 프로젝트에 맞는 구현이라는 뜻은 아니다.

Metadata 저장과 Test가 모두 정상이어도 Backend가 Google Drive SDK에 직접 의존하도록 구현됐다면 앞서 정한 Android와 Backend의 책임 경계는 깨진다.

그래서 Issue에는 이번 변경에서 특히 영향을 받을 수 있는 Architecture Boundary를 따로 표시했다.

## Architecture Constraints

- Provider 인증과 Provider API 호출은 Android 책임으로 본다.
- Backend는 Provider SDK나 Provider 전용 응답 모델에 의존하지 않는다.
- 기존 File / FileLocation Domain과 Persistence 구조를 우선 재사용한다.
- `(storageSourceId, externalId)`를 반복 동기화의 유일성 기준으로 사용한다.
- 불필요한 DB Schema 변경을 하지 않는다.
- DB 변경이 필요하다면 구현 전에 이유와 Migration 계획을 먼저 제시한다.
- 외부 I/O와 DB Transaction 책임을 섞지 않는다.

여기서 Architecture Constraints는 AGENTS.md와 별개의 Architecture 원본을 만드는 항목이 아니다.

구분	역할
AGENTS.md	여러 작업에서 계속 유지되는 Project Rule의 Source of Truth
Architecture Constraints	그중 이번 변경에서 특히 영향을 받는 경계를 다시 확인
Acceptance Criteria	구현 결과가 요구사항을 만족하는지 확인
Out of Scope	이번 변경에서 아예 다루지 않을 영역

즉 Issue에 Project Rule 전체를 복사하는 것이 아니라 이번 변경에서 실수하기 쉬운 경계만 작업 조건으로 드러낸다.

더 엄격하게 중복을 줄이고 싶다면 공통 Rule은 직접 반복하지 않고 다음처럼 AGENTS.md를 참조할 수도 있다.

## Architecture Constraints

- Follow the Provider boundary defined in `AGENTS.md`.
- Reuse the existing File / FileLocation persistence structure.
- Do not introduce a DB schema change unless its necessity is reported first.

Out of Scope는 그보다 더 직접적으로 이번 작업에서 하지 않을 일을 정한다. 구현 도중 기존 구조의 문제나 추가 개선점을 발견하더라도 현재 Goal과 직접 관계없다면 별도 작업으로 남긴다.

Architecture Constraints
→ 결과를 만드는 과정에서 넘지 말아야 할 경계

Out of Scope
→ 이번 작업에서 다루지 않을 범위

여기까지 정하면 Project Context와 Task Context의 역할이 분리된다. 이제 해야 할 일은 이번 작업을 다른 변경과 섞이지 않는 공간으로 옮기는 것이다.

Issue를 Branch와 Worktree로 작업 공간에 분리한다

이번 Issue는 Backend 기능이므로 backend Branch를 기준으로 Feature Branch를 만들었다.

git switch backend
git pull origin backend

Branch가 변경 이력을 분리한다면 Worktree는 작업 Directory까지 분리한다.
메인 Repository를 그대로 유지하면서 Feature Branch 전용 Directory에서 Claude Code를 실행할 수 있고, 다른 Branch의 작업과 파일 상태가 뒤섞이는 것도 막을 수 있다.

Feature Branch를 별도의 Worktree에 연결한다.

git worktree add -b feat/backend/metadata-ingestion `
    D:\dev\project-worktrees\backend-metadata-ingestion `
    backend

생성 결과는 git worktree list로 확인했다.

git worktree list

Git Worktree 생성 결과

Feature Branch와 Worktree 생성 확인

생성한 Worktree로 이동한 뒤 현재 Branch도 다시 확인한다.

cd D:\dev\project-worktrees\backend-metadata-ingestion

git branch --show-current
git status

Worktree의 Feature Branch 확인

Worktree에서 현재 Feature Branch 확인

이제 Claude Code는 메인 작업 Directory가 아니라 이 Worktree 안에서 실행한다.

Claude Code는 구현보다 분석부터 시킨다

작업 공간이 준비되면 바로 코드를 작성하게 할 수도 있다.

하지만 이번 작업처럼 기존 Domain과 Persistence 구조를 재사용해야 하고 Architecture 제약도 있는 변경에서는 현재 구조를 제대로 이해했는지 먼저 확인하는 편이 안전하다.

Anthropic의 Claude Code Best Practices도 복잡한 작업에서는 Explore → Plan → Implement → Commit으로 조사와 계획을 구현에서 분리하는 Workflow를 제시한다. 범위가 명확한 작은 수정까지 항상 Plan 단계를 거칠 필요는 없지만, 여러 파일이 바뀌거나 구현 방향을 먼저 판단해야 하는 작업에서는 유용하다. Claude Code Docs — Best Practices

이번 작업에서는 먼저 Explore와 Plan을 진행한다.

GitHub Issue를 Claude Code가 읽을 수 있게 준비한다

아래 Prompt에서는 단순히 GitHub Issue #6이라고 참조한다.

이 예제에서는 GitHub CLI인 gh가 설치되고 인증된 상태를 전제로 한다. Anthropic도 GitHub처럼 외부 서비스를 다룰 때 CLI Tool을 활용하는 방식을 권장하며, Claude Code는 gh를 이용해 Issue나 Pull Request를 조회할 수 있다.

먼저 연결 상태를 확인할 수 있다.

gh auth status
gh issue view 6

gh를 사용하지 않는 환경이라면 Issue URL이나 본문을 Prompt에 직접 전달해도 된다.

그다음 Claude Code에는 구현보다 Issue와 현재 Repository를 기준으로 작업 범위를 분석하는 것부터 요청했다.

GitHub Issue #6을 기준으로 작업해줘.

먼저 구현하지 말고 다음 순서로 진행해줘.

1. 루트 AGENTS.md와 CLAUDE.md를 읽는다.
2. backend 관련 AGENTS.md와 docs를 확인한다.
3. Issue #6의 Goal, Scope, Acceptance Criteria, Architecture Constraints, Out of Scope를 분석한다.
4. 현재 Backend의 StorageSource, File, FileLocation, Metadata Sync 관련 코드를 확인한다.
5. 기존 구조에서 재사용할 부분과 수정이 필요한 부분을 정리한다.
6. 예상 수정 파일과 새로 추가할 파일을 제시한다.
7. DB Schema 변경이 필요한지 판단한다.
8. Test 전략을 제시한다.

아직 코드는 수정하지 말고,
현재 구조 분석과 구현 계획만 먼저 보여줘.

특히 Issue #6의 Scope 밖으로 작업을 확장하지 마.

세세한 구현 방법까지 지정하지는 않았다.

확인하려는 것은 Claude Code가 Issue를 제대로 읽었는지, 기존 코드를 어디까지 재사용할 수 있는지, 불필요한 Schema 변경이나 Scope 밖의 수정이 계획에 들어가 있지는 않은지다.

Claude Code의 Issue 분석

Claude Code가 Issue의 조건을 가져오는지 확인

분석 결과에서는 Issue에 적어둔 Goal과 Scope, Architecture Constraints를 현재 코드와 비교해 구현 방향을 정리했다.

Claude Code의 구현 계획

현재 코드 구조를 기준으로 정리한 구현 계획

사람이 확인할 항목도 미리 정해두면 판단하기 쉽다.

확인 항목	보는 이유
Issue 이해	해결해야 할 문제를 잘못 해석하지 않았는지 확인
수정 파일	Scope 밖의 영역까지 건드리지 않는지 확인
기존 코드 재사용	같은 책임을 중복 구현하지 않는지 확인
새 Class / 계층	구조를 불필요하게 늘리지 않는지 확인
DB Schema	예상하지 않은 Migration이 필요한지 확인
Test 계획	Acceptance Criteria를 검증할 수 있는지 확인

계획이 틀렸다면 아직 코드가 바뀌기 전이기 때문에 방향만 다시 잡으면 된다. 구현이 끝난 뒤 책임 경계가 잘못됐다는 사실을 발견하는 것보다 수정 비용도 작다.

계획을 확인한 뒤 구현을 맡긴다

분석 결과가 Issue의 Scope와 Architecture Constraints에 맞는 것을 확인한 뒤 구현을 진행시켰다.

다만 구현해줘 한마디로 끝내지는 않았다. 분석 과정에서 드러난 위험 중 이번 구현에서 특히 주의해야 할 조건만 다시 짚었다.

분석 및 구현 계획 확인했어. 제안한 방향으로 구현 진행해줘.

다만 다음 원칙을 지켜줘.

1. 기존 StorageFileMetadata와 MetadataSyncPersistenceService를 최대한 재사용하고,
   동일한 영속 로직을 새로 중복 구현하지 마.

2. MetadataIngestionResponseDto와 테스트 구성은
   기존 Backend API/Test Convention을 먼저 확인한 뒤 결정해줘.
   단순히 계층이나 파일 수를 늘리기 위한 구조는 추가하지 마.

3. 기존 GoogleDriveProvider / Pull Sync 구조는 현재 Architecture와 충돌하더라도
   이번 Issue #6에서는 수정하지 마.
   별도 정리가 필요한 사항으로만 남겨둬.

4. DB Schema는 현재 분석대로 변경하지 않는 것을 기본으로 하고,
   구현 중 Schema 변경이 필요해지면 먼저 이유를 보고하고 진행을 멈춰줘.

5. Issue #6의 Out of Scope 밖으로 작업을 확장하지 마.

구현 완료 후에는 다음 내용을 정리해서 보고해줘.

- 변경/추가 파일
- 주요 설계 판단
- Acceptance Criteria별 검증 결과
- test 실행 결과
- build 실행 결과
- ktlintCheck 실행 결과

AGENTS.md의 내용을 다시 전부 복사하지 않은 이유도 같다.

프로젝트 전체 규칙은 이미 Project Context에 있고, 구현 요청에는 현재 분석에서 확인한 위험과 이번 작업에서 특히 주의할 조건만 남긴다.

이제 Claude Code는 정해진 경계 안에서 구현하고, 완료 여부는 Acceptance Criteria와 검증 명령으로 확인한다.

코드 작성이 아니라 Local Verification까지 구현 단계로 본다

Claude Code가 파일을 수정했다고 구현이 끝난 것으로 보지는 않았다.

Anthropic의 Best Practices도 Claude가 자신의 작업을 검증할 수 있도록 Test, Build, Linter처럼 명확한 Pass/Fail Signal을 제공하는 것을 권장한다. 검증 수단이 있으면 Claude는 결과를 읽고 실패 원인을 수정한 뒤 다시 확인할 수 있다.

개발자가 같은 Test를 바로 다시 반복하는 것이 목적은 아니다. Claude Code가 구현 과정에서 기본 오류를 수정하고 Local Verification까지 마친 뒤, 사람은 자동 검증이 잡지 못하는 Scope와 설계 차이를 확인한다.

최종 테스트 결과

구현 후 Claude Code가 실행한 Local Verification 결과

그래서 Local Verification 다음 단계는 같은 Test를 한 번 더 실행하는 것이 아니라 Diff Review다.

Test가 통과해도 Diff는 따로 봐야 한다

Build와 Test가 성공했다는 사실은 코드가 Issue의 범위 안에서만 바뀌었다는 뜻이 아니다.

다음과 같은 변경은 자동 검증을 통과하고도 남을 수 있다.

Issue와 관계없는 파일 수정
요청하지 않은 Refactoring
불필요한 Dependency 추가
예상하지 않은 Configuration 변경
Scope 밖의 Domain 변경

그래서 Commit 전에 실제 Diff를 확인한다.

Issue Scope
    ↓
Git Diff
    ↓
의도한 변경만 들어갔는가?

이 단계에서는 코드를 처음부터 다시 검토하거나 같은 Test를 반복하지 않는다.

Claude Code가 요청하지 않은 변경까지 함께 만들지는 않았는지, 분석 단계에서 확인한 계획과 실제 Diff가 일치하는지를 본다.

Google의 Code Review 가이드가 작은 변경을 권장하는 이유도 여기에 연결된다. 변경이 작을수록 Reviewer가 영향 범위를 이해하기 쉽고, 문제가 생겼을 때 되돌리기도 수월하다. Google Engineering Practices — Small CLs

코드 변경 사항 확인

Local Verification 이후 Diff 확인

이 지점에서 구현 단계의 역할은 거의 끝난다. 남은 것은 확인된 변경을 Repository의 공식 검토 단위인 Pull Request로 넘기는 일이다.

Pull Request에는 Diff뿐 아니라 변경의 맥락도 넘긴다

Local Verification과 Diff 확인이 끝나면 Commit하고 Remote에 Push한 뒤 Pull Request를 만든다.
PR부터는 Worktree에서 진행한 구현 결과를 기준 Branch에 반영해도 되는지 검토하는 단계로 넘어간다.

Google의 Code Review 가이드에서도 Change Description에는 최소한 무엇을 변경했고 왜 변경했는지가 드러나야 한다고 설명한다. Google Engineering Practices — Good CL Descriptions

이번 Workflow에서는 여기에 Verification과 Review Point를 더했다. 기존 Architecture의 문제를 발견했지만 현재 Issue에서는 의도적으로 건드리지 않은 부분이 있다면 Out of Scope에도 남긴다.

PR 항목	Reviewer에게 전달하는 정보
`Summary`	무엇을 변경했는가
`Reason`	왜 이 변경이 필요한가
`Verification`	어떤 검증을 통과했는가
`Review Point`	특히 확인해야 할 부분은 무엇인가
`Out of Scope`	의도적으로 다루지 않은 범위는 무엇인가

Verification은 PR을 만들면서 Test를 다시 실행한다는 뜻이 아니다. 앞 단계에서 Claude Code가 수행한 Local Verification 결과를 Reviewer가 확인할 수 있도록 기록한다.

Issue도 PR과 연결한다.

Closes #6

GitHub에서는 Closes, Fixes, Resolves 같은 Keyword를 이용해 PR과 Issue를 연결할 수 있으며, 조건을 만족하면 Merge 시 연결된 Issue를 자동으로 닫을 수 있다. GitHub Docs — Linking a Pull Request to an Issue

Pull Request 작성 결과

Issue와 Local Verification 결과를 포함해 작성한 Pull Request

Pull Request가 올라오면 CI 환경에서 다시 검증한다

로컬에서 Test와 Build, Lint를 통과했더라도 Pull Request가 생성되면 GitHub Actions가 Repository에 올라온 변경을 CI 환경에서 다시 검증한다.

둘의 역할은 비슷해 보여도 실행되는 위치와 목적이 다르다.

검증	실행 시점	목적
Claude Local Verification	구현 직후, Worktree	명백한 오류를 PR 전에 수정
GitHub Actions	Push 이후, Pull Request	PR 변경을 CI 환경에서 독립적으로 검증

여기서 CI가 항상 Local에서 확인한 동일한 Commit SHA만 실행한다고 단정할 수는 없다.

GitHub Actions의 pull_request Event에서 기본 actions/checkout을 사용하면 PR Head 자체가 아니라 Base Branch와 PR 변경을 합친 Merge Ref를 Checkout해 검증할 수 있다. 반대로 Workflow에서 github.event.pull_request.head.sha를 지정하면 PR Head를 직접 검증할 수도 있다.

그래서 이 글에서는 이를 단순히 “같은 Commit을 다시 검증한다” 고 표현하지 않고, “PR에 올라온 변경을 CI 환경에서 다시 검증한다” 고 구분한다. GitHub도 CI에서 Repository 변경을 Build하고 Test한 뒤 결과를 Pull Request에 표시하는 흐름을 공식 문서에서 설명한다. GitHub Docs — Continuous Integration

이번 Backend 작업에서 확인할 것은 PR에 필요한 Check가 실행되고 통과했는지다.

하나라도 실패하면 같은 Feature Branch에서 수정하고 다시 Push한다. 새로운 Issue나 Branch를 만드는 것이 아니라 현재 Pull Request 안에서 변경을 보완하고, 갱신된 변경을 GitHub Actions가 다시 검증하도록 한다.

Pull Request 자동 검증 결과

Pull Request에서 확인한 GitHub Actions Check 결과

이제 Codex Review로 넘길 준비가 끝났다

이번 흐름에서 Claude Code의 역할은 코드를 생성하는 데서 끝나지 않았다.

Issue와 Repository를 읽고 구현 방향을 먼저 정리한 뒤 사람이 Scope와 Architecture를 확인했다. 그다음 Claude Code가 코드를 수정하고 Test, Build, Lint를 실행해 기본 오류를 정리했다. 사람은 Diff에서 작업 범위와 예상하지 않은 설계 변경을 확인하고, Pull Request가 올라간 뒤에는 GitHub Actions가 CI 환경에서 변경을 다시 검증했다.

단계	주체	다음 단계로 넘어가기 전에 확인한 것
Issue 작성	Human	Goal, Scope, Acceptance Criteria, Architecture Constraints
Worktree 생성	Human / Git	기준 Branch와 작업 Directory
분석·계획	Claude Code	영향 범위, 재사용할 코드, Schema 변경 여부, Test 계획
구현	Claude Code	Issue Scope와 Architecture Constraints
Local Verification	Claude Code	Test, Build, Lint
Diff Review	Human	Scope 밖 변경, 예상하지 않은 설계 변경
Pull Request	Human	변경 이유, 검증 결과, Review Point, Out of Scope
CI	GitHub Actions	Pull Request 변경의 자동 검증 결과

이 Workflow의 중심은 Claude Code가 얼마나 많은 코드를 자율적으로 작성했느냐가 아니다. 각 단계에서 무엇을 확인하고, 어떤 조건을 통과해야 다음 단계로 넘길 것인지 정해두는 데 있다.

GitHub Actions
Checks 통과
      ↓
Codex
Independent Code Review

Claude Code의 구현 결과는 이제 Build, Test, Lint까지 통과한 Pull Request가 됐다.

다음 글에서는 이 변경을 Codex가 Independent Review하는 과정으로 넘어간다. CI에서 이미 확인한 문제를 다시 보는 것이 아니라, Issue와 Project Context, Pull Request Diff를 기준으로 Architecture, Regression, Security, Test 누락처럼 코드의 맥락을 읽어야 판단할 수 있는 문제를 어떻게 검토하는지 정리한다.