agents-baton 만들게 된 계기와 아이디어: [agents-baton]codex agent간 협업 보조 프로그램(간접 하네스)
바톤 깃헙agents-baton

개요

필요에 의해서 구현했기 때문에 그냥 내가 사용하는 프로젝트에 tools/ 같은 폴더를 만들고 거기에 git clone 한뒤에 에이전트에게 읽고 사용하라고 해서 사용해도 별 지장 없이 사용을 할 수 있습니다. 하지만, 오픈 소스 프로젝트 + 사이드 프로젝트 + 회사에서 업무할 때도 필요한 뭐 그런 상황이다 보니, 그래도 좀 관리가 되어야 하지 않는가 싶어서 평소에 안하던 배포를 시도해 보게 되었다.

pipx 를 통해서 깃헙에서 설치를 할 수 있게 하였지만, 해당 버전은 dev 버전으로 테스트 중이라 문제가 아직 많이 있을 수 있다. 현재 진행된 바로는 바톤을 설치하고나서 프로젝트의 루트 폴더에서 baton init 를 실행하면 바톤을 관리하는 공간이 생긴다.

트러블 슈팅

git branch

그리고 지금 또 다른 사이드 프로젝트에 적용해서 사용을 해본 결과.. 역시 많은 문제들을 사전에 발견 할 수 있었다. 일단 설계할 때, 같은 작업공간 내에서 각각의 독립적인 에이전트들간 중간 소통의 창구 역할을 하는게 바톤인데, 설계 단계에서 깃 환경을 고려하지 않았었다. 즉, 같은 작업공간에 같은 깃 브랜치로 가정을 하고 진행을 했었다.

이는 깃 브랜치로 인해 문서 및 결과물 동기화에 문제가 생길까봐 동일한 dev 계열의 브랜치에서 작업한다고 전제를 했었기 때문에다. 근데 이제는 이 숙제를 해결해야 한다.

그리고 코덱스틑 초기 .git 이 존재한 상태에서 프로젝트 기획을 정리하고 프로젝트를 시작하려고 하면, main, 을 두고 codex/planner, codex/core, .... 이런식으로 자신들의 작업공간을 별도로 나누려고 한다. 그래서 개발 버전에는 baton 에 commit hash 나 태그를 함께 기록하도록 하였다. 그래서 다른 branch 에 문서가 나 파일이 있더라도 바톤을 보고 읽는 것은 가능하다.

진짜 문제는 CR(Change-Reqeusts/) 관리 문제인데, 현재 결정한 정책은 미승인 CR 의 경우 .gitignore 에 해당하는 공간에 공통으로 사용하다가 승인 된 문서만 planner 가 있는 branch 로 경로를 이동시키는 방안으로 변경을 하고 있다.

버전 관리

기존 main 브랜치에 있는 tools/ 에 받아서 사용하는 방식의 경우와 달리. pipx 로 설치하고 관리를 하면서 실행이 가능해지면서 전역적으로 실행이 가능해졌다. 다행인 것은 실행될때는 각자의 프로세스를 만드는 구조이기 때문에 서로 다른 프로젝트에서 바톤을 동시에 실행을 해도 별 문제가 안된다. 문제는 버전 업이 진행될 경우인데, 결국은 프로젝트에 있는 로컬 DB어떻게 마이그래이션을 할 것인가가 주요 문제가 되었다.

그래서 앞으로 버전 관리를 하기 위한 로컬DB에 관련 정보를 기록해야 하고, 앞으로 개발은 되도록 하위 호환을 하는 방향으로 개발이 진행될 것 같다. 이는 pipx 로 설치될 때 전역으로 영향을 주기 때문이다. 따라서 wait(혹은 shift) 상태일 때는 버전 업이 되지 않도록 막아야 한다.

여담

쉽게 금방 끝날 줄 알았는데, 생각보다 고려할게 많아 졌다. 개발 방향은 되도록 단순화, 하위호환, 쉬운 사용법 이 3가지를 기준으로 진행하려 한다.