코드는 빨리 나오는데 PR은 리뷰를 기다립니다. 구현 속도가 높아지면 완료가 빨라질 수도 있지만 검토자가 처리할 수 있는 양을 넘으면 대기열이 커질 수도 있습니다. 코딩 에이전트를 도입할 때 생성량과 완료량을 구분해야 하는 이유입니다.

GitHub의 11월 6일 가이드는 Plan·Build·Verify·Observe로 작업을 묶습니다. 제품 활용 가이드이며 이 글은 생산성 실험으로 취급하지 않습니다. 11월 9일 원문을 확인했습니다.

계획 문서는 구현의 입력 계약이다

GitHub는 요구사항을 이슈와 수용 기준으로 만들고 복잡한 작업의 계획을 검토한 뒤 구현에 넘기는 흐름을 제안합니다. 여기서 중요한 산출물은 긴 프롬프트가 아니라 완료를 판정할 수 있는 조건입니다. “로그인 개선”보다 “만료된 세션은 재로그인으로 이동하고 기존 화면의 입력은 정해진 정책에 따라 처리한다”가 검토 가능합니다.

작업을 작게 나눠도 의존성이 숨으면 병렬 구현의 통합 비용이 커집니다. API 계약, 스키마 변경, 배포 순서처럼 여러 작업이 공유하는 결정을 먼저 고정해야 합니다. 이는 가이드의 단계 구성을 실제 팀 운영에 적용한 해석입니다.

PR 생성 속도와 리뷰 처리량 사이

다음은 제품의 내부 아키텍처가 아닌 운영상 대기열의 개념 도식입니다.

수용 기준 → 변경 구현 → 검증 증거 → 리뷰 결정 → 배포 관측
                           ↑                  │
                           └── 발견한 실패 ───┘

리뷰 가능한 증거에는 테스트 결과뿐 아니라 변경 범위, 실패 시 영향, 되돌리는 방법이 포함됩니다. 작은 PR이라도 여러 개를 동시에 열어 리뷰 대기만 늘리면 팀의 완료 시간은 줄지 않습니다. 이 글은 대기열 원리를 적용한 분석이며 GitHub가 해당 팀에서 측정한 효과가 아닙니다.

단계 남겨야 할 증거 사람의 판단
Plan 수용 기준과 제외 범위 해결할 문제와 위험
Build 변경 diff와 실행 조건 의도하지 않은 범위 확장
Verify 테스트 결과와 실패 분석 남은 위험의 수용 여부
Observe 배포 버전과 증상·로그 복구와 후속 작업 우선순위

실패를 다음 작업의 입력으로 바꾼다

실무에서는 PR을 연 시간, 첫 리뷰 시간, 병합 시간, 롤백·재작업 여부를 기록해 도입 전후를 비교할 수 있습니다. 작업 난이도와 팀 구성이 달라지면 단순 전후 평균으로 인과관계를 말할 수 없습니다. 리뷰 대기 시간이 길어졌다면 모델을 더 빠르게 바꾸기 전에 동시 작업 수와 증거의 품질을 점검하세요.

운영 문제 분석에 에이전트를 사용하더라도 로그 열람과 복구 명령 실행은 권한이 다릅니다. 관측 정보에 민감한 데이터가 들어갈 수 있고 외부 입력은 잘못된 지시를 포함할 수 있습니다. 읽기 권한과 변경 권한을 분리하고 복구에는 명시된 책임자를 두는 것이 이 글의 제안입니다.

단계가 있다는 사실만으로 품질이 보장되지는 않는다

테스트 통과는 수용 기준이 충분한지 답하지 못합니다. 자동 리뷰는 요구사항의 누락을 놓칠 수 있습니다. 운영 대시보드도 측정하지 않은 실패를 보여주지 않습니다. 각 단계가 다음 판단에 필요한 증거를 남길 때만 순환 구조가 작동합니다.

체크포인트와 관측 상태의 차이처럼 저장된 사실과 사람이 받은 정보가 다를 수도 있습니다. 팀이 지금 할 일은 모든 기능의 자동화가 아니라, 한 작업에서 계획·검증·운영 피드백 중 어느 증거가 사라지는지 찾는 것입니다. 완료량을 높이려면 가장 빠른 단계보다 기다리는 단계를 먼저 설계해야 합니다. 별도 코드 실행이나 팀 생산성 측정은 수행하지 않았습니다.