7일 / 30 PR / 70 Issue

5월 19일부터 25일까지의 7일간, 제가 개인용으로 개발하고 있는 워크 매니지먼트(Work Management) 앱에 대해 30개의 PR이 머지(Merge)되었고, 70건의 Issue가 기표·처리되었으며, 130건의 커밋(Commit)이 쌓였습니다.

개발 중인 것은 Next.js + Prisma + SQLite로 구성된, 아이디어·태스크·워크(작업 실적)를 일원 관리하기 위한 앱입니다. 요구 사양은 A4 용지로 10페이지 정도 분량이 있으며, 직접 구현한다면 2~3개월은 걸릴 것으로 예상했던 것입니다.

이 중 제가 직접 손을 움직인 작업은 다음 3가지뿐이었습니다.

• 요구 사양서(docs/requirements.md) 작성 및 최종 승인 - 예상치 못한 동작에 대한 개입
• 수동 E2E 테스트 후 Codex를 통한 히어링(Hearing) 및 Issue 트리아지(Triage)

구현, PR 리뷰, 머지 판단, 테스트 코드 수정은 Claude Code와 Codex라는 두 가지 AI 에이전트(Agent)가 분업하여 처리했습니다.

제가 코드에 전혀 손대지 않고 7일 동안 이 정도의 아웃풋을 낼 수 있었다는 점에서, 이번에 제가 구축한 반자동 개발 메커니즘이 어느 정도 실용에 견딜 수 있는 수준임을 증명할 수 있었다고 생각합니다.

이 기사에서는 제가 7일 동안 실천한 내용과 운용을 통해 얻은 배움·깨달음을 정리해 두겠습니다.

두 에이전트에게 "분업시키기"

이 앱 개발에서 가장 먼저 결정한 것은 **기능 개발과 리뷰를 Claude Code와 Codex로 분업시키기 위한 개발 워크플로우(Workflow)**였습니다.

구체적으로는 다음과 같은 역할 분담을 했습니다.

두 모델 모두 베이스 모델(Base Model) 능력이 충분히 높기 때문에, 원리적으로는 어느 한쪽에 모든 공정을 맡길 수도 있습니다. 그럼에도 굳이 나누어 놓은 이유는, 자신이 작성한 코드를 스스로 리뷰하면 제대로 된 리뷰가 되지 않는다는, 인간의 팀 개발에서 흔히 알려진 제약이 AI 에이전트에게도 적용된다고 생각했기 때문입니다.

구현과 상세화·리뷰에서는 요구되는 사고의 방향이 서로 반대입니다.

구현은 "정해진 사양을 최단 거리로 코드에 녹여내는" 프로세스이며, 상세화·리뷰는 "정해진 것으로 생각한 사양을 의심하고 누락을 찾는" 프로세스입니다.

같은 모델에게 두 가지를 모두 맡기면 관점이 섞이게 됩니다.

구현한 사고의 연장선상에서 리뷰를 하면, 당연하게도 "구현 시에 놓쳤던 것"도 같은 이유로 놓치게 됩니다.

이는 구조적인 문제이며, 모델 성능을 높여도 해소되지 않을 것이라고 생각했습니다.

그래서 프롬프트(Prompt)와 운용 규칙을 분리함으로써, 두 가지 "역할"을 가진 별개의 에이전트로 동작하도록 설계했습니다.

모델의 성능이 같더라도 역할을 명시적으로 나눔으로써 관점을 분리할 수 있다. 반자동 개발에서의 품질 확보의 근간을 여기에 두었습니다.

4시간 사이클 × 6회 / 일의 발화 구조

실제 워크플로우는 다음과 같은 루프로 구성되어 있습니다.

이 루프는 4시간 사이클 × 하루 6회(구현 배치만 5회)로 발화합니다.

포인트는 배치(Batch)마다 발화 시각을 1시간씩 늦추고 있다는 점입니다.

• 00:00 / 04:00 / 08:00 / 12:00 / 16:00 / 20:00: Codex Issue 상세화 배치
• 01:00 / 05:00 / 09:00 / 13:00 / 17:00 / 21:00: Codex PR 리뷰 배치
• 02:00 / 06:00 / 10:00 / 14:00 / 18:00 / 22:00: Claude Code PR 수정 배치
• 03:00 / 07:00 / 11:00 / 15:00 / 19:00: Claude Code Issue 구현 배치
• 23:00: Claude Code E2E 스모크(Smoke) 실행 배치 (하루 1회)

상세화 → 리뷰 → 수정 → 구현 순으로 1시간씩 늦추고 있기 때문에, 동일 사이클 내에서 전 단계의 출력이 다음 단계의 인풋(Input)이 되는 구조로 되어 있습니다. 다음 사이클을 기다리지 않고 처리가 흘러가는, 이른바 파이프라인(Pipeline)화입니다.

참고로, 첫 시험 운용은 각 배치를 하루 1회부터 시작했습니다.

이틀 정도 가동하여 정체나 폭주가 일어나지 않는 것을 확인한 시점에서, 3일째부터 단번에 하루 6회까지 증강했습니다. "안정적이라고 판단한 시점에 빈도를 단번에 올린다"는 것은, 나중에 되돌아봤을 때 가장 효과적이었던 의사결정 중 하나였습니다.

설계의 핵심이 된 4가지 판단

이 워크플로우를 성립시키기 위해 특히 중요했던 설계 판단이 4가지 있습니다.

라벨에 상태를 집약한다

Issue / PR의 상태 관리를 6개의 라벨로만 집약했습니다.

각 배치(Batch)는 "해당 라벨이 붙어 있는가"만을 보고 자신의 작업을 판단합니다.

에이전트끼리는 직접 통신하지 않고, GitHub의 라벨을 공유 메모리(Shared Memory)로 사용하여 상태를 동기화하는 구조입니다. 이를 통해 배치 간의 의존 관계가 사라지고, 각 배치가 독립적이고 안전하게 동작할 수 있게 되었습니다.

1 PR에 3 Issue를 집약한다

Claude Code의 구현 배치는 ready-for-cc-implementation 라벨이 붙은 Issue에서 최대 3건을 골라, 동일한 브랜치 및 동일한 PR에 모아서 구현합니다.

3건을 별도의 브랜치와 별도의 PR로 병렬 진행하면, 동일한 파일을 건드렸을 때 충돌이 발생하기 쉽고, Claude Code끼리 이를 해결하기 위한 추가 비용이 발생합니다.

동일한 브랜치에 3건분의 커밋(Commit)을 쌓으면 PR 간의 충돌은 애초에 발생하지 않습니다. 머지(Merge) 방식을 merge commit으로 고정하여 squash / rebase를 무효화함으로써, 리뷰 단위는 "PR", 이력 단위는 "커밋"으로 분리했습니다. 즉, PR에서 올 오어 나싱(All or Nothing) 판정을 내리면서도, 나중에 git log를 통해 Issue 유래의 커밋을 추적할 수 있는 구조로 만들었습니다.

참고로 3건이라는 숫자는 테스트용으로 보수적으로 설정한 것일 뿐, 토큰 소비량이나 처리 시간을 고려했을 때 한 번에 10건 정도는 처리할 수 있을 것 같았습니다.

본문을 불변으로 유지하고, 코멘트로 추가한다

Codex의 상세화 결과나 리뷰 결과는 Issue / PR의 본문에 쓰지 않습니다. 모두 코멘트(Comment)로 추가하며, 서두에 ## [Codex 상세화 (2026-05-22)]와 같은 마커(Marker) 행을 둡니다. Claude Code는 이 마커를 통해 최신 Codex 코멘트를 기계적으로 검색합니다.

본문(처음에 작성한 요구 사양)은 불변인 상태로 유지하고, 에이전트 간의 상호작용은 시계열적인 코멘트 이력으로 쌓여갑니다. 그렇게 함으로써 나중에 제가 Issue / PR을 다시 읽었을 때, 구현 및 수정 완료까지의 흐름을 추적할 수 있도록 했습니다.

신규 Issue 생성은 원칙적으로 금지한다

에이전트 측에서의 신규 Issue 생성은 원칙적으로 금지했습니다.

구현 중에 발견한 과제나 개선안은 모두 해당 PR의 description 또는 코멘트로 남기며, Issue화 여부는 제가 판단합니다.

이유는 자동 에이전트가 신규 Issue를 무조건적으로 계속 생성하게 되면, 완료 판정(Issue / PR 잔여 건수 0)이 무너져 루프(Loop)가 수렴하지 않게 되기 때문입니다.

이는 사소한 규칙처럼 보일 수 있지만, 워크플로우 전체의 수렴성을 담보하는 근간입니다.

"발견"을 Issue로 내뱉는 권리를 인간에게 남겨둠으로써, 에이전트가 자율적으로 동작하고 있음에도 완료 판정이 성립하는 폐쇄 루프(Closed Loop)가 성립되었습니다.

"사용하며 키운다"를 포함한 2가지 특례

신규 Issue 생성 금지 규칙에는 2가지 특례를 두고 있습니다.

그리고 이 특례야말로 워크플로우를 실용적인 영역으로 끌어올렸습니다.

특례 1: E2E 스모크 테스트 실패 시 자동 생성

매일 23:00 JST에 Claude Code가 pnpm e2e로 주요 동선의 스모크 테스트(Smoke Test)를 실행합니다.

실패를 감지한 경우에는 템플릿에 따라 Issue를 자동으로 생성하고, 그대로 통상적인 상세화 → 구현 루프에 태워 수정합니다.

이는 "매일의 자동 회귀(Regression) 감지 → 수정 → 재감지" 사이클을 돌리기 위한 메커니즘입니다.

아침에 GitHub을 확인하면 밤사이에 E2E가 실패해 있고, 그것을 기점으로 새로운 Issue와 PR이 쌓여 있는 운영 방식이 성립되었습니다.

특례 2: 히어링(Hearing) 기반의 Issue 생성

또 하나는 사용자 히어링 기반의 생성 플로우입니다. 흐름은 다음과 같습니다.

• 제가 수동으로 앱을 조작하며, 조작감을 Codex에 수시로 피드백한다.
• Codex가 그것을 docs/user-hearings/YYYY-MM-DD-*.md

에 히어링 시트 (Hearing Sheet)로 저장한다 - 내가 "이 시트로부터 Issue를 생성해줘"라고 Claude Code에 명시적으로 지시한다

• Claude Code가 시트에서 명시적 발언과 추측된 인사이트(Insight)를 모두 추출하여,
  [Hearing] ...

제목을 Issue로 하여 기표(Issue Creation)한다.

이 흐름으로 기표된 Issue는, 총 70개의 Issue 중 40개, 전체의 절반 이상을 차지하게 되었습니다.

요구 사양서를 기점으로 Claude Code가 기표할 것이라는 당초의 예상은 빗나갔고, 실제 사용 기반의 피드백이 워크플로 (Workflow)의 주요 공급원이 되었습니다.

사양서는 "만들기 전"의 상상으로 작성된 것입니다. 실제로 작동하는 것을 만져보면, 상상하지 못했던 위화감이나 개선 요청이 반드시 발견됩니다.

이 차이분을 적절히 받아들이는 것이 프로덕트 개발에 있어서 가치의 원천이다라는, 그 자체로는 진부한 주장이 반자동 개발의 운용 과정 속에서 다시금 부각되었습니다.

7일간의 운용을 통해 알게 된 것

7일간의 운용을 통해 나에게 남은 업무는 다음 3가지로 집약되었습니다.

• 사양 책정 (Specification Definition): 무엇을 만들 것인가, 왜 만드는가, 우선순위를 어떻게 둘 것인가를 결정한다
• 예외 대응 (Exception Handling): 에이전트 (Agent)가 예상치 못한 움직임을 보일 때 개입한다
• 사용자 히어링 (User Hearing): 사용 편의성에 관한 히어링을 받고, 개선 Issue를 기표 및 트리아지 (Triage)한다

구현, 코드 리뷰 (Code Review), 테스트 코드 수정, 머지 (Merge) 판단, 브랜치 (Branch) 정리는 모두 에이전트 측에 넘길 수 있었습니다. 반자동 개발이 실용에 견딜 수 있는 수준이 되었다는 감각은 이 사실로부터 얻은 것입니다.

예상 밖이었던 점은, 요구 사양서를 기점으로 기표한 Issue가 아니라, 실제 사용 기반의 히어링에서 태어난 Issue가 전체의 주류를 차지했다는 것입니다. 직접 움직여보지 않으면 나오지 않는 위화감이 예상보다 훨씬 많이 워크플로의 공급원이 되었습니다.

사양 책정과 트리아지는 책상 위에서 완결되는 업무가 아니라, 실제로 작동하는 것을 만져본 상태에서 수행해야 하는 업무라는 것을 운용 과정에서 다시 한번 확인할 수 있었습니다.

참고로, 본 기사에서 다룬 설계 판단 각각의 근거(레이블 (Label) 설계의 상세, 사이클 발화 순서의 의도, 코멘트 추가 방식의 운용 등)는 별도 기사인 『Claude Code와 Codex의 반자동 개발 워크플로 설계 상세』에 재현용 레퍼런스 (Reference)로 정리해 두었습니다.

구조 구축 과정에서 겪었던 예상치 못한 함정(GitHub Free 플랜의 제약, gh CLI로의 통일, worktree 모드의 브랜치 명명 등)은 또 다른 별도 기사인 『Claude Code와 Codex의 반자동 개발에서 빠졌던 6가지 함정』에 집약했습니다.

동일한 구조를 재현하고 싶은 분은 본 기사와 함께 참조해 주시기 바랍니다.

Discussion