「전용 도구를 도입하지 않고, AI에게 전부 보여주면 되지 않을까?」

Claude Code나 Codex를 사용하여 여러 task를 진행하면, 동일한 repository에 여러 개의 open PR이 나열됩니다.

여기서 다음과 같이 생각하는 것은 자연스럽습니다.

merge 전에 Claude나 Codex에게 open PR을 전부 읽게 하여, 충돌할 것 같은 PR과 병합 순서를 답변하게 하면 된다. 전용 GitHub App까지 필요할까?

단 한 번만 상황을 확인하는 것이라면, 이 방법으로 충분할 때가 있습니다. AI는 PR 목록, diff, CI 결과, comment를 읽고 주의해야 할 조합을 정리할 수 있습니다.

문제는 그 답변을 지속적인 운용 상태로서 사용하기 시작했을 때입니다.

이 기사에서는 자체 AI에게 매번 질문하는 것과, GitHub 상에서 유지하는 PR 교통정리의 차이를 정리합니다.

현재의 coding agent는 병렬 task나 pull request를 전제로 GitHub에 연결되어 있습니다.

• OpenAI Codex는 multi-agent workflow와 병렬 작업을 안내하고 있습니다.
• GitHub의 coding agents는 task를 받아 pull request 상에서 작업할 수 있습니다.
• Claude Code GitHub Actions도 issue나 PR을 기점으로 변경 사항과 pull request를 다룰 수 있습니다.

코드를 작성하는 agent가 늘어날수록, "누가 쓸 수 있는가"보다 "서로 다른 작업 context를 어떻게 합류시킬 것인가"가 문제가 됩니다.

자체 AI로 충분한 상황이 있다

다음과 같은 운용 방식이라면, merge 전에 AI에게 질문하는 방법은 합리적입니다.

• open PR이 적음
• 병렬 task가 가끔만 발생함
• merge 판단을 하는 사람이 한 명으로 고정되어 있음
• 상황이 바뀔 때마다 수동으로 다시 물어볼 수 있음
• check, ACK, 감사 이력과의 연결이 불필요함

예를 들어, merge 직전에 다음과 같이 의뢰합니다.

현재 open 상태인 모든 PR과 최신 head를 확인해 주세요.
동일한 작업 영역을 향하는 PR, 먼저 merge해야 하는 PR,
rebase 또는 대기가 필요한 PR을 나열해 주세요.
...

이러한 사용법이라면, AI는 우수한 현장의 조사원이 됩니다.

여기서 중요한 것은 얻은 답변이 틀렸는지 여부가 아닙니다. 정답이라 하더라도, 전제가 된 GitHub의 상태가 움직이면 답변은 낡은 것이 된다는 점입니다.

AI의 답변에는 보이지 않는 유효 시간이 있다

10시에 AI에게 모든 PR을 읽게 하여 다음과 같은 답변을 얻었다고 가정해 봅시다.

PR #42를 먼저 merge하고, PR #47은 그 후에 rebase한다.

하지만 그 이후에 다음과 같은 변화가 일어납니다.

• 10:04 — PR #47에 새로운 commit이 push됨
• 10:08 — 다른 PR #51이 main으로 merge됨
• 10:12 — PR #42의 담당 agent가 10시의 답변을 전제로 작업을 계속함

10시의 답변은 10시에 존재했던 open PR의 집합과, 각각의 head에 대해 내린 것입니다. 10:12의 GitHub에 대한 답이 아닙니다.

텍스트로는 남아 있어도, 다음 사항을 확인하지 않으면 현재도 유효한지 판단할 수 없습니다.

• 어떤 open PR 집합을 보았는가
• 각 PR의 어떤 head SHA를 보았는가
• main의 어느 시점을 보았는가
• 답변 후에 push, merge, close, reopen이 일어났는가
• ACK 후 대상 간의 관계가 변하지 않았는가

즉, AI에게 한 번 물어보는 것은 가능합니다. 하지만 그 답변을 현재의 운용 규칙으로 삼으려면, **신선도와 실효(expiration)**를 별도로 관리해야 합니다.

자체 AI로 지속 운용하려고 하면 필요한 것이 늘어난다

매번 질문하는 것을 Veripsa 수준의 지속 운용에 가깝게 만들려면, 적어도 다음과 같은 메커니즘이 필요합니다.

• PR 생성, push, merge, close, head 업데이트를 감지함
• 그 시점의 open PR과 exact head를 취득함
• 관계와 병합 순서를 재평가함
• 오래된 답변을 현재의 판단으로 사용하지 않게 함
• 모든 agent와 인간에게 동일한 결과를 보여줌
• 누가 특정 warning을 확인했는지 기록함
• 필요한 repository에서는 required check에 연결함
• Claude, Codex, Copilot 중 무엇이 작업하더라도 동일한 운용 규칙을 사용함
• webhook 실패나 분석 부족을 암묵적인 'Clear' 상태로 두지 않음

이 단계에 이르면 필요한 것은 프롬프트의 궁리만이 아닙니다.

GitHub 이벤트를 받고, 현재 상태를 재계산하여, 공유 영역으로 배포하고, 오래된 판단을 실효시키는 운용 시스템입니다.

LLM은 그 시스템의 일부로 사용될 수 있습니다. 하지만 LLM을 호출하는 것 자체와, 공유된 현재 위치를 유지하는 것은 별개의 작업입니다.

차이는 AI의 똑똑함이 아니라, 판단을 어디에 두느냐에 있습니다

자체 AI에 대한 질문 결과는 통상적으로 해당 세션(session)에 국한됩니다.

• Claude가 본 PR 집합과 Codex가 본 PR 집합이 다름
• 같은 AI라도 질문한 시점에 따라 답변이 달라짐
• 인간은 오래된 채팅(chat)을 보고 있음
• 에이전트(agent)는 다른 브랜치(branch)에서 작업하며, 다른 답변을 알지 못함
• 어떤 답변이 현재의 헤드(head)에 대응하는지 알 수 없음

이 문제를 '더 똑똑한 모델'로 해결하려 해도, 공유 영역이 없다면 각 세션은 서로 다른 현재 위치를 갖게 됩니다.

PR 운용에서는 판단의 위치를 GitHub 쪽으로 옮기는 것이 다루기 쉬워집니다.

• PR 체크(check)에 현재의 트래픽 상태(traffic state)를 둠
• 필요한 때에만 PR 코멘트(comment)에 관계와 다음 액션(action)을 작성함
• 판단을 정확한 헤드(exact head)에 결합함
• 상태가 변하면 재평가함
• 인간의 승인(ACK)을 특정 경고 스냅샷(warning snapshot)에 결합함
• 에이전트에게도 동일한 체크(check)/코멘트(comment)를 읽게 함

이렇게 하면 모델의 대화 이력이 아니라, 리포지토리(repository)의 공유 영역이 현재 위치가 됩니다.

일회성 AI 조사와 지속적인 공유 상태 비교

이 표의 왼쪽이 나쁘다는 뜻은 아닙니다. 왼쪽은 일회성 조사로서 가볍고 유연합니다.

오른쪽이 필요해지는 시점은, 답변을 여러 작업자가 지속적으로 참조하고 리포지토리(repository)의 상태 변화에 추종시키고 싶을 때입니다.

무엇을 선택할 것인가

자체 AI 질문이 적합한 경우

• 동시에 움직이는 PR이 1~2개 정도일 때
• 머지(merge) 전에 담당자가 전체를 재검토할 수 있을 때
• 상황 변화가 적고, 재질문 부담이 작을 때
• 여러 에이전트(agent)에게 동일한 판단을 배포할 필요가 없을 때
• GitHub상의 체크(check)나 승인(ACK)으로 연결하지 않을 때

공통 교통정리 레이어가 적합한 경우

• Claude, Codex, Copilot 등을 병렬로 구동할 때
• 오픈된 PR(open PR)이 항상 여러 개 있을 때
• 각 에이전트(agent)의 세션(session)과 브랜치(branch)가 분리되어 있을 때
• 푸시(push) 후에도 PR들 사이의 관계가 변할 때
• 누가 대기할지, 어떤 순서로 랜딩(land)할지를 공유하고 싶을 때
• 권고(advisory)에서 필수 체크(required check)로 단계적으로 연결하고 싶을 때
• 오래된 판단이나 오래된 승인(ACK)을 현재의 판단으로 사용하고 싶지 않을 때

경계는 "AI를 사용하느냐"가 아닙니다.

일회성 조사로 끝낼 것인가, 현재의 상태를 여러 작업 컨텍스트(context)에서 계속 공유할 것인가입니다.

물론, 직접 만들 수도 있습니다

여기서 말하고자 하는 것은 "자체 AI로는 구현할 수 없다"는 뜻이 아닙니다.

GitHub API와 웹훅(webhook)을 사용하여 현재의 PR 집합을 가져오고, AI 또는 독자적인 로직으로 평가하여 체크 런(check run)으로 다시 쓰는 메커니즘은 직접 구축할 수 있습니다.

다만, 그 시점에 만들고 있는 것은 단발적인 AI 프롬프트(prompt)가 아니라, 다음을 포함하는 GitHub 통합(integration)입니다.

• 설치(installation) 및 리포지토리(repository)별 권한 관리
• 웹훅(webhook)의 수신, 재전송, 중복 처리
• 현재 헤드(current head)와 오래된 결과의 구별
• 체크(check)/코멘트(comment)의 업데이트
• 재시도(retry) 및 장애 시의 알 수 없음(Unknown) 처리
• 승인(ACK) 및 감사 기록
• 지속적인 유지보수

선택지는 "AI로 할 수 있느냐, 전용 도구로만 할 수 있느냐"가 아닙니다.

일회성 조사를 직접 돌릴 것인가, 지속적인 조정 시스템(coordination system)을 직접 구축·운영할 것인가, 아니면 기존의 GitHub App으로 사용할 것인가입니다.

Veripsa Core가 담당하는 범위

Veripsa Core는 오픈된 풀 리퀘스트(open pull requests)들 사이의 관계와 착지 순서를 GitHub 상에 두는, 머지 전 PR 트래픽 제어(pre-merge PR traffic control)를 위한 GitHub App입니다.

GitHub 체크(checks)와, 관계를 설명해야 할 때의 PR 코멘트(comment)를 통해 다음을 공유합니다.

• 다른 진행 중인 작업(in-flight work)이 무엇을 바꾸고 있는지
• 왜 현재의 PR과 관계가 있는지
• 머지(merge) 전에 다음에 어떻게 움직여야 하는지
• 판단을 위한 정보가 부족하여 알 수 없음(Unknown) 상태인지

가치는 두 개의 PR을 단 한 번 비교하는 것에 있지 않습니다. PR 생성, push, merge, close, ACK, head 업데이트에 맞춰 동일한 repository 내의 coordination state(조정 상태)를 다시 구축하는 것입니다.

초기 상태는 advisory(권고)입니다. 운영 방식에 적합하다고 판단한 repository에서는 GitHub 측의 ruleset이나 branch protection을 사용하여 required check(필수 체크)로 연결할 수 있습니다.

요약

merge 전에 Claude나 Codex에게 모든 PR을 읽게 하는 방법은 가벼운 일회성 조사로서 사용할 수 있습니다.

하지만 그 답변을 여러 agent와 사람이 계속해서 사용한다면, 다른 문제가 시작됩니다.

• 언제 GitHub를 확인한 답변인가
• head가 변경된 후에도 유효한가
• 누가 현재의 판단을 보고 있는가
• 오래된 답변과 ACK를 어떻게 무효화할 것인가
• 모든 agent에게 어떻게 동일한 상태를 배포할 것인가

단 한 번의 답변을 얻기 위해 필요한 것은 AI입니다.

공유된 현재 위치를 유지하기 위해 필요한 것은 event-driven(이벤트 기반) coordination layer(조정 계층)입니다.

자체 AI를 해당 용도로 확장해 나가면, 최종적으로는 GitHub 이벤트, 상태의 재평가, 공유 check, 무효화, ACK, 감사를 갖춘 작은 운영 시스템이 됩니다.

실제 GitHub 상에서 비교해 보려면 공개 sandbox의 두 PR을 통해 확인할 수 있습니다.

Discussion