이슈 URL 하나로 PR까지, 에이전트 두 대의 분업

깃허브 이슈 주소 하나를 던지면 구현부터 검증, 리뷰, 수정, 재검증을 거쳐 사람이 확인할 풀 리퀘스트(PR)까지 만들어 놓고 멈추는 자동화 절차가 공개됐다. 개발자 시게오카 다다시가 7월 23일 자신의 블로그에 정리한 omh-issue-loop 스킬로, 허미스 에이전트(Hermes Agent)용 커스터마이징 모음인 oh-my-hermes에 추가됐다. 이 루프는 머지도, 이슈 종료도 하지 않는다.

무슨 일인가 / 배경

저자는 앞서 클로드 코드(Claude Code)와 코덱스(Codex)에게 같은 PR을 각각 독립적으로 리뷰시키는 스킬을 만들었다. 그것이 이미 만들어진 PR 뒤쪽을 자동화한 것이라면, 이번에는 상류로 거슬러 올라가 이슈에서 PR이 태어나기까지를 통째로 묶었다.

구성은 의외로 단출하다. 절차를 서술한 SKILL.md 한 장, 표시 이름과 기본 프롬프트를 담은 설정 파일 하나, 그리고 커밋 서명 사전점검과 워크플로 순서도를 적은 참조 문서 둘이 전부다. 이전 스킬과 달리 파이썬 스크립트가 한 줄도 없다. 저자는 이를 방향 전환이 아니라 문제의 모양이 달라서라고 설명한다. 다중 모델 리뷰는 분기가 없는 직선 작업이라 결정론적 스크립트가 맞았지만, 이슈 구현 루프는 검증 명령이 저장소마다 다르고 다음 행동이 리뷰 결과에 달렸으며 애초에 수렴할지조차 미리 알 수 없다. 그래서 판단은 에이전트에게 남기고, 대신 금지 사항과 한계를 정밀하게 적는 쪽을 택했다.

핵심 짚어보기

SKILL.md는 할 일이 아니라 하지 말 것으로 시작한다. 오케스트레이터는 워크플로만 지휘하고, 작업 트리에서 코드를 쓰고 고치는 일은 코덱스 CLI에, 독립 리뷰와 동작 검증은 클로드 코드 CLI에 위임한다. 반대로 깃 이력·원격·PR·이슈·CI·리뷰 조작은 오케스트레이터가 독점한다.

이 분리에는 두 가지 이유가 있다. 첫째, 자기가 쓴 코드를 자기가 리뷰하면 의미가 없다. 같은 모델이 같은 세션에서 자기 변경분을 보면 앞선 판단을 추인할 뿐이다. 코덱스가 쓰고 클로드 코드가 본다는 식으로 계보를 갈라야 리뷰가 비로소 새로운 정보가 된다. 둘째, 오케스트레이터가 코드를 만지는 순간 상태 추적이 무너진다. "코덱스가 거의 다 했으니 이 부분만 내가 고치자"를 한 번 허용하면 누가 무엇을 썼는지에 대한 기록이 사라지고, PR이 증거로 들고 갈 데이터도 함께 무너진다.

더 흥미로운 대목은 공개 이후 추가된 반대 방향의 규칙이다. 코덱스에게 이슈 주소만 건네면 그것을 '끝까지 배달하라'는 과제로 읽는다. 실제로 코덱스는 구현을 마친 뒤 커밋하고, 푸시하고, PR을 열고, 리뷰 준비 상태로 바꾸고, CI 완료까지 지켜봤다. 오케스트레이터의 리뷰 관문이 하나도 돌기 전이었다. 저자는 이를 코덱스의 잘못으로 보지 않는다. 어디까지가 네 일인지를 적어두지 않은 쪽의 문제였다는 것이다. 그래서 워커는 부모가 넘긴 이슈 스냅샷과 저장소 지침만 읽고, 이슈 범위의 파일만 고치고, 관련 로컬 검증만 돌린 뒤 보고한다. 변경분은 커밋하지 않은 채로 남기고, 워커는 살아 있는 이슈 데이터를 직접 조회하지 않는다.

여기서 나오는 문장이 이 글의 핵심이다. 워커가 주변 워크플로를 보고 경계를 알아서 추론하리라 기대하지 말라. 오케스트레이터의 SKILL.md에 아무리 정성껏 적어둬도, 별도 프로세스로 뜬 코덱스는 그 파일을 읽지 않는다. 워커에게 건네는 프롬프트에 없는 내용은 워커에게는 존재하지 않는다.

1인기업 실전 적용 포인트

• 작성자와 검토자의 모델을 물리적으로 다르게 하라. 콘텐츠든 코드든, 초안을 쓴 세션에 검수를 맡기면 자기 확인에 그친다. 초안은 A 도구, 검수는 새 세션의 B 도구로 넘기는 것만으로 지적 건수가 달라진다.
• 금지 문장을 프롬프트 맨 앞에 넣어라. "~해줘"보다 "커밋하지 마라, 발행하지 마라, 범위를 넓히지 마라"가 사고를 더 많이 막는다. 자동화 프롬프트마다 금지 3줄을 상수로 두고 재사용하면 된다.
• 발행·결제·머지 권한은 한 곳에만 두라. 하위 작업자는 초안 파일까지만 만들고, 실제 게시나 송금은 사람이 승인하는 단일 지점에서 처리한다. 이 저장소 기준으로는 초안 생성과 발행 스크립트를 분리해두는 방식이 여기에 해당한다.
• 컨텍스트는 링크가 아니라 스냅샷으로 넘겨라. 하위 에이전트에게 URL만 주면 제멋대로 더 읽는다. 부모가 한 번 조회한 결과를 JSON으로 떠서 그대로 붙여주면 매번 같은 입력이 보장된다.

전망 / 주의점

이 방식의 비용은 명확하다. 모델 두 종을 별도 CLI로 돌리므로 토큰과 시간이 곱절로 든다. 수렴하지 않는 이슈에서는 수정과 재검증이 반복되며 비용만 쌓일 수도 있다. 그럼에도 이 사례가 시사하는 바는 도구 조합이 아니라 설계 원칙 쪽이다. 에이전트를 여러 대 쓰는 시대의 문서는 무엇을 하라는 지시서가 아니라 누가 무엇까지 할 수 있는지를 못 박는 권한 명세서에 가까워진다. 저자 본인도 실제로 매일 이 루프를 쓰면서 드러난 구멍을 메워왔다고 밝혔으니, 그대로 복제하기보다 자기 저장소의 검증 명령에 맞춰 다시 쓰는 편이 낫다.

출처: CodeNote (https://codenote.net/en/posts/issue-to-pr-autonomous-loop-hermes-agent-skill/)