채팅에서 백로그로의 변화
3개월 전, 제 작업 관리는 그저 채팅창 하나였습니다. 탭을 닫으면 계획도 사라졌습니다.
오늘은 Postgres 백로그입니다. Claude Code, Codex, Grok이라는 세 가지 서로 다른 AI 에이전트가 여기서 작업을 가져옵니다. 에이전트들은 작업에 기여 정보를 기록하고 git 히스토리에 맞춰 작업을 완료합니다.
프로젝트 관리 시스템을 구축하려고 시작한 것은 아니었습니다. 그저 계속해서 벽에 부딪혔을 뿐입니다. 문제를 하나 해결할 때마다 새로운 문제가 나타났습니다.
제 업무량은 상당합니다. 저는 Nexus라는 개인 데이터 플랫폼을 운영하고 있습니다. 약 100개의 저장소를 관리합니다. 한 번은 35일 동안 557,000줄의 코드를 배포하기도 했습니다. 그 정도의 양은 제가 시도했던 모든 계획 수립 방식을 무너뜨렸습니다.
제 시스템이 진화한 과정은 다음과 같습니다:
Phase 1: Conversational Planning 계획은 채팅 기록 속에 머물렀습니다. 생각을 소리 내어 말하다가 좋은 아이디어가 떠오르면 바로 구축을 시작하곤 했습니다.
- 문제점: 채팅이 끝나면 계획이 증발해 버렸습니다. 우선순위를 정하거나 다른 사람에게 전달할 수도 없었습니다.
Phase 2: Per-Repo TODO Files 모든 저장소에 TODO.md 파일을 사용하기 시작했습니다. 단순한 체크리스트 사용을 중단하고, 대신 작은 사양(spec)을 작성했습니다. 각 항목에는 다음 내용이 포함되었습니다:
- 상태 및 날짜.
- 트리거 (이 작업이 왜 긴급해졌는지).
- 미리 결정된 단계 (계획).
- 알려진 리스크.
- 문제점: 100개의 저장소를 관리하다 보니 전체적인 관점을 가질 수 없었습니다. 해야 할 모든 일을 한곳에서 볼 수 없었습니다.
Phase 3: The Operator Backlog (OB) 작업을 Postgres 데이터베이스로 옮겼습니다. 이를 통해 전역 큐(global queue)가 생성되었습니다. 승인 게이트(approval gate)를 추가했습니다. 제가 검토한 후에만 작업이 실제로 반영됩니다. 이는 AI가 백로그에 쓰레기 데이터를 쌓는 것을 방지합니다. 상태 레인(status lanes)을 사용했습니다:
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- 문제점: 제가 병목 지점이 되었습니다. 레인을 충분히 빠르게 비워낼 수 없었습니다.
Phase 4: Multi-Agent Execution 이제 백로그는 여러 AI 에이전트가 공유하는 큐입니다.
- 에이전트들은 동일한 작업에 중복으로 작업하지 않도록 리스(lease)를 사용합니다.
- 누가 무엇을 했는지 알 수 있도록 기여 정보(attribution)를 기록합니다.
- 작업을 인계할 수 있습니다. 한 에이전트가 어떤 작업이 불가능하다는 것을 발견하면 선행 작업(prerequisite)을 등록할 수 있고, 그러면 두 번째 에이전트가 그 선행 작업을 수행한 뒤 원래 작업을 완료할 수 있습니다.
교훈은 간단합니다: 성공하기 위해 반드시 4단계가 필요한 것은 아닙니다.
만약 하나만 가져간다면, 2단계 형식을 가져가십시오. 상태, 트리거, 미리 결정된 단계, 그리고 리스크를 포함하여 작업을 작성하십시오. 비용은 전혀 들지 않지만, 모든 것을 바꿔 놓을 것입니다.
가장 중요한 규칙은 이것입니다: 항상 사실을 바탕으로 계획하십시오. 추측이나 요약본을 바탕으로 계획을 세우지 마십시오. 오래된 데이터를 바탕으로 세운 완벽한 계획은 계획이 아예 없는 것만큼이나 빠르게 실패할 것입니다.
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi