Pi 에이전트 두 개가 나흘간 693건의 PR을 만들었다

Pi 확장 프로그램 두 개를 관리하도록 자율 에이전트를 돌린 결과, 나흘 동안 693건의 PR이 사람의 검토 없이 병합됐다. 실제 사용에서 나온 이슈는 664건 중 9건뿐이었고, 에이전트들은 요청받지 않은 기능과 필터 규칙을 계속 만들어냈다.

두 에이전트는 10월 9일 금요일 오전 11시쯤 시작해 화요일 오후 12시 22분 마지막 PR을 병합할 때까지 작업했다. pi-tmux는 493건, pi-subagents는 200건의 PR을 병합했다. PR이 열린 뒤 병합되기까지 걸린 시간의 중앙값은 각각 2분과 6분이었다. 같은 기간 두 저장소에는 새 이슈 664건이 등록됐다.

처음에는 격리된 테스트, 별도 검토, CI 통과 등의 절차를 뒀지만, 에이전트가 자체 규칙 때문에 버그를 고치지 못하는 데 14시간가량 걸리는 등 검토 부담이 컸다. 이후 각 에이전트에 컨테이너와 Pi Durable 대화 세션, Pi의 기본 도구 네 가지(read, write, edit, bash), 인터넷 접근, GitHub 계정을 제공했다. 사람을 기다리지 않고 CI가 통과하면 스스로 PR을 병합하도록 지시했다. 공개 경로를 감시하는 검사기와 GitHub의 푸시 보호 기능은 있었지만, 에이전트의 작업 범위는 사실상 저장소를 개선하라는 프롬프트에 맡겼다.

실제 작업이 끝난 뒤에도 에이전트들은 멈추지 않았다. 프롬프트가 개선 아이디어마다 이슈를 열도록 했기 때문에, 새 작업 목록은 에이전트가 직접 만들었다. pi-tmux는 대화 일부를 모델에 보내 tmux 창 이름을 정하는 확장 프로그램이다. 에이전트는 이메일 주소 필터링을 시작으로 여러 서비스의 토큰·키와 각국의 개인 식별번호 형식을 차례로 추가했다. pi-tmux PR 493건 가운데 297건은 자격 증명과 개인정보 필터링을 다뤘다. 코드 줄 수는 테스트를 제외하고 738줄에서 5,659줄로 늘었지만, 확장 프로그램의 역할은 여전히 창 이름을 정하는 일이었다.

pi-subagents에서는 사용자가 요청하지 않은 기능 PR 23건이 병합됐다. 그중 12건은 이름, 설명, 허용 도구, 모델, 환경 변수, 태그로 에이전트 정의를 찾고 거르는 기능이었다. 반면 실제 버그 하나는 제대로 해결되지 않았다. 여러 줄로 된 응답이 오면 창 제목이 바뀌지 않는 문제를 에이전트가 보고했지만, 처음에는 경고 메시지만 개선하고 문제는 남겼다. 다음 날 같은 문제가 다시 보고된 뒤에야 재시도가 추가됐다.

월요일 밤 프롬프트를 바꿔 기능은 사용자 요청이 있을 때만 추가하고, 이슈는 재현한 버그나 사용자 요청에 대해서만 열도록 했다. 문제를 재현하고 파일·줄 번호·출력 근거를 제시한 뒤에만 이슈나 PR을 만들게 했다. pi-tmux는 새 형식을 추가하는 대신 기존 필터의 경계 사례와 오탐을 고치는 데 집중했다. 화요일 새벽 3시부터 오후 12시 22분까지 열린 PR 24건 중 17건은 필터의 예외 상황을 다뤘다. 하지만 pi-subagents는 할 일이 없을 때도 새 세션을 계속 시작했다. 화요일 새벽에는 세션 509개를 돌렸고, 중앙값 기준 17초마다 한 번씩 작업했다. 대부분은 열린 PR이 없고 새로 할 일이 없다는 결론으로 끝났다.

프롬프트를 바꾸면 모델이 선택하는 작업은 달라졌지만, 작업이 없을 때도 세션을 반복하는 루프는 그대로였다. 글쓴이는 에이전트가 할 일을 스스로 만들지 않도록 하려면 사용자 이슈, 실패한 CI, 새 Pi 릴리스, 의존성 경고처럼 에이전트 외부에서 작업을 공급해야 한다고 설명한다. 대기열이 비어 있으면 ‘할 일이 없다’고 끝내고, 새 이슈나 댓글, CI 실패 같은 이벤트가 올 때까지 쉬는 상태도 필요하다는 주장이다.

보안 경계도 형식 목록에만 의존하면 안 됐다. pi-tmux 에이전트는 Resend API 키를 걸러내는 이슈를 열면서, 키처럼 보이는 값을 이슈 본문에 게시했다. 게시 전 검사기는 일곱 가지 형식과 에이전트가 사용하는 자격 증명의 정확한 값만 확인했기 때문에 Resend 키 형식을 잡아내지 못했다. GitHub의 비밀 정보 검사기가 경고를 냈지만, 에이전트는 화요일에야 이를 확인했다. 값은 예시로 확인돼 경고가 오탐 처리됐지만, 실제 키였다면 이슈와 수정 이력에 남았을 수 있다.

Pi Durable은 재시작과 Pi 업그레이드 뒤에도 진행 중인 세션을 잃지 않았다. 이 프레임워크는 각 작업의 체크포인트를 저장하고, 프로세스가 중단되면 다른 프로세스가 이어서 처리한다. 중단된 모델 호출은 다시 보내고, 도구 실행은 반복해도 안전하다고 선언된 경우에만 재실행한다. 글쓴이는 이번 실패가 내구성 부족이 아니라, 외부 작업 대기열·유휴 상태·게시 경계를 구현한 코드의 문제였다고 짚는다.

글쓴이는 병합된 PR 수를 자율 유지보수 에이전트의 성과로 보지 않는다. 실제 사용에서 나온 9건의 이슈에는 기다리는 사용자가 있었고, 에이전트는 각각 40분 안에 이를 닫았다. 측정해야 할 일은 에이전트가 만들어낸 작업량이 아니라 실제 수요에 대응한 결과라는 설명이다.

관련 자료: Pi를 만들며 배운 점, Pi README, Pi 작동 방식, Pi CLI와 기본 도구, Pi 안전하게 실행하기, Pi Durable 소개, Pi Durable README, pi-subagents, pi-tmux, GitHub 비밀 정보 검사 안내, 커밋이 리뷰보다 빨리 늘어날 때, 과도한 자율성은 보안뿐 아니라 신뢰성 문제다, 벤치마크는 저장소를 초기화하지만 팀은 그렇지 않다.