PetV3 에이전트 공장 1: 호기심으로 시작해 운영을 배우기까지
PetV3 자동화 시스템 시리즈 1/4
처음부터 ‘에이전트 공장’을 만들겠다는 거창한 계획이 있었던 것은 아니다. 쓸 수 있는 구독과 토큰이 있었고, 커뮤니티에서는 여러 AI를 연결해 작업시키는 실험이 계속 보였다. 관련 기능이 존재한다는 사실은 알고 있었지만, 남의 사례를 보는 것과 내 환경에서 실제로 굴리는 것은 다른 문제였다. 정말 되는지 직접 확인해 보고 싶었다.
그래서 시작했다. 방법론이 있어서가 아니라 호기심이 있어서였다.
익숙한 배경에서 새로운 운영을 배웠다
나는 이 프로젝트 전까지 Rust와 MCP를 사용해 본 적이 없었고, 프롬프트와 대화로 다중 에이전트 시스템을 설계하고 운영한 경험도 없었다. 다만 소프트웨어 개발 배경이 있었고, 클러스터링과 분산 시스템 같은 개념에는 익숙했다. 새로 배워야 했던 것은 그 개념을 실제 에이전트 운영의 절차와 내부 메커니즘에 적용하는 방법이었다. Git 역시 익숙한 범위는 커밋하고 병합하는 정도였고, 여러 worktree를 작업 공간처럼 운용하는 방식은 새로 배워야 했다.
그 개념들을 실제 운영 방식으로 옮기는 방법은 AI와 대화하면서 배웠다. 설명을 듣고, 프롬프트로 시도하고, 실제 결과가 예상과 다르면 다시 물었다. 어떤 선택이 맞는지 처음부터 알고 지시한 것이 아니라, 대화와 실험을 반복하면서 선택 기준을 만들어 갔다. 때로는 내가 너무 긴 길을 골랐고, 한 번에 해결하려고 프롬프트를 과도하게 길게 쓰기도 했다.
AI는 방향이 잡힌 뒤의 구현을 빠르게 맡을 수 있었다. 그렇다고 내가 프롬프트만 던지고 결과를 기다린 것은 아니다. 무엇을 먼저 할지 정하고, 범위를 제한하고, 결과를 직접 확인하고, 다음 시도를 선택하는 일은 계속 내 몫이었다. 구현 속도와 판단의 책임은 같은 것이 아니었다.
운영 방식은 작업하면서 생겼다
처음부터 완성된 운영 철학을 들고 시작하지는 않았다. 다만 실제로 에이전트를 돌려 보니 “프로세스가 끝났다”와 “작업이 끝났다”는 전혀 다른 말이라는 사실이 반복해서 드러났다.
에이전트가 실패했다면 실패한 상태가 보여야 했다. 검토가 필요하면 검토 대기 상태로 남아야 했고, 다시 시도할 일이라면 완료 목록으로 사라져서는 안 됐다. 보고서가 성공이라고 말해도 실제 결과가 다르면 완료로 받아들일 수 없었다. 이런 기준은 처음부터 정리돼 있던 규칙이 아니라, 실패를 보고 다시 지시하는 과정에서 점차 분명해졌다.
내 역할도 그 과정에서 구체화됐다. 나는 계획을 세우고, 제약을 선택하고, 어떤 검증이 필요한지 정했다. 결과가 기준을 충족하지 못하면 다시 작업하도록 했고, 멈춰야 할 때는 어디까지 보존해야 하는지도 결정했다. AI가 많은 코드를 구현했지만, 무엇을 받아들이고 무엇을 다시 보낼지에 대한 책임까지 대신해 주지는 않았다.
익숙한 협업 방식을 에이전트 작업에 붙여 봤다
큰 조직이 티켓으로 일을 나누고, 작업 공간을 분리하고, pull request에서 검토한 뒤 병합하며 큰 프로젝트를 조율한다는 것은 이미 알고 있었다. PetV3에서 궁금했던 것은 그 익숙한 협업 방식을 개인 프로젝트의 실제 AI 에이전트 작업에도 붙여서 운영할 수 있느냐는 점이었다.
branch와 worktree는 에이전트별 작업 공간을 분리하고 진행 중인 변경을 보존했다. pull request와 병합 과정은 완성됐다고 보고된 변경을 바로 섞는 대신, 안전하게 검토한 뒤 프로젝트로 가져오기 위한 경계가 됐다. ledger에는 누가 어떤 파일을 맡았는지 남길 수 있었고, checkpoint와 인계 자료는 다른 대화나 다른 제공자가 이어갈 단서를 만들었다.
다만 이 패턴을 프롬프트로 움직이는 여러 에이전트에 연결해 정식으로 운영해 본 경험은 없었다. worktree와 pull request가 있다고 자동으로 안전해지는 것도 아니었다. 비동기로 움직이는 에이전트들이 같은 파일이나 오래된 기준을 붙잡을 수 있었기 때문에, 실제로 작업을 나누고 충돌 가능성을 확인하고 중단과 재배치를 반복하면서 적용 방법을 배웠다.
불완전했지만 실제로 운영됐다
실험은 문서나 화면 시안에서 끝나지 않았다. 작업을 에이전트들에게 나누고, 대시보드에서 상태를 확인하고, 중단 시점의 작업을 보존한 뒤 다시 이어가는 흐름이 실제로 작동했다. Codex와 Claude 세션의 활동을 가깝게 확인할 수 있는 표시를 요청했고, 진행 상태를 한곳에서 보려는 대시보드도 만들었다.
안전하게 멈추는 일도 중요한 기능이 됐다. 사용량 상한에 도달했을 때 새 작업을 시작하지 않게 하고, 끝나지 않은 변경을 억지로 커밋하거나 지우지 않은 채 보존하도록 했다. worktree와 ledger 상태를 확인하고, 다음 대화나 다른 제공자가 재개할 수 있는 맥락을 남기는 방식도 실제 인계에 사용했다.
그렇다고 이 시스템이 완성됐다는 뜻은 아니다. 대시보드의 일부 동작은 일관되지 않았고, 에이전트를 수정하거나 조정하려던 기능은 기대대로 움직이지 않았다. 같은 지시도 모델이 매번 동일하게 따르지 않았으며, 손으로 사용해 보다가 실패한 시도도 있었다. 결과를 얻기 위해 프롬프트를 고치고 방향을 다시 잡는 일이 반복됐다. 때로는 이 정도로 계속 설명하고 판단해야 한다면 내가 상당 부분을 직접 하는 것과 무엇이 다른가 싶기도 했다.
문제가 생겼을 때 원인을 항상 분리해 낼 수도 없었다. ChatGPT나 모델의 동작 때문인지, 클라우드 환경의 제약인지, 아니면 과제 자체가 어려웠던 것인지 명확하지 않은 경우가 있었다. 그래서 PetV3를 완성된 자율 관제 시스템이라고 부를 수는 없다.
하지만 실패한 실험이라고 부르는 것도 정확하지 않다. 작업 분배, 상태 확인, 안전 정지, 미완성 작업 보존, 다른 세션과 제공자로의 인계와 재개가 작동했다. 표준화되지 않았고 사람의 개입이 많이 필요했지만, 호기심으로 시작한 구상이 실제 운영 가능한 형태까지 간 것은 분명했다.
로컬 Git 기록상, 8월 29일 오후 첫 스캐폴드와 오버레이 데모부터 9월 1일 저녁 안전정지 checkpoint까지는 약 76시간, 사흘 남짓이었다. 그 사이 데모가 실제로 움직이고, 프로젝트에 쓸 수 있는 구조가 쌓이고, 그 흐름을 따라 다음 개발이 이어지는 모습을 볼 수 있었다. 뼈대와 파이프라인, 눈에 보이는 진전이 내가 사람만으로 개발할 때 예상하던 호흡보다 훨씬 빠르게 실체를 갖췄다. 이것이 완전한 자율성이나 완성도를 증명하지는 않지만, 실제 프로젝트가 손에 잡히는 형태가 되는 속도 자체가 달라졌다는 감각은 분명했다. 과장 없이, ‘AI 시대가 정말 도착하고 있구나’라는 생각이 들었다.
이 기록을 남기는 이유
이 기록에서 내가 남기고 싶은 것은 AI와 함께 실제 프로젝트를 운영하는 법을 배운 과정이다. Rust, MCP, 프롬프트 기반 다중 에이전트 운영은 새로운 영역이었지만, 기존 소프트웨어·분산 시스템 관점을 출발점으로 대화와 반복 실험을 통해 적용 방법을 익혔다.
AI는 상당한 구현을 빠르게 진행했지만, 나는 그 결과를 그대로 받아들이지 않았다. 범위와 제약을 정하고, 다음에 무엇을 시도할지 선택하고, 검토 기준을 유지하고, 실패를 재검토와 재시도의 대상으로 남기고, 언제 멈출지를 결정했다. 불완전한 시스템을 실제로 운영하면서 AI가 맡을 구현과 사람이 맡을 판단의 경계를 배웠다.
대형 추론 모델이 방향을 받은 뒤 만들어 내는 작업량은 여전히 놀라웠다. 동시에 그 결과를 어디까지 믿고, 언제 멈추고, 무엇을 다시 확인할지는 사람이 정해야 했다. PetV3의 첫 번째 결론은 성공이나 실패 중 하나가 아니라 그 둘 사이에 있다. 실제로 작동했고, 많이 배웠으며, 아직 완성되지 않았다.
기록 방법: 이 글은 당시 대화를 모두 옮긴 완전한 전사가 아니다. 내 설명을 중심으로, 확인 가능한 PetV3 관련 Codex와 Claude 작업 기록을 대조해 재구성했다.
다음 글에서는 이 실험의 작업장이 된 worktree, 파일 ledger, 중앙 착지 과정을 다룬다.