1. 생산성 향상의 단계적 발전과 병목 현상의 발견
저자는 처음부터 AI를 완벽하게 활용한 것이 아니라, CLAUDE.md 파일에 도메인 지식과 코딩 표준을 기록하고 반복 가능한 워크플로우를 위한 커스텀 스킬을 구축하며 점진적으로 숙련도를 높였습니다. 하지만 관리하는 프로젝트가 늘어나고 litestream-ruby 젬 포크 유지보수, 블로그 운영 등 업무가 복잡해지자 새로운 문제에 직면했습니다. AI가 개별 프로젝트 내부의 코드 작성은 도와주었지만, 여러 프로젝트 사이를 오가는 ‘컨텍스트 스위칭’과 수동적인 지시 과정이 개발자 개인의 인지적 한계(병목)로 작용하기 시작한 것입니다. 이러한 인지적 부하는 단순히 코드를 빨리 짜는 것만으로는 해결할 수 없는 문제였습니다.
2. 자동화된 위임: 오케스트레이션 시스템 구축
이 병목을 해결하기 위해 저자는 Fly.io VPS에서 작동하는 boswell-backoffice 시스템을 구축했습니다. 이 시스템은 n8n을 통해 GitHub 웹훅(이슈 레이블링, 댓글 등)을 감지하고, Dagu를 사용하여 전체 파이프라인(작업 공간 설정, 에이전트 실행, 커밋, 완료 댓글 작성)을 오케스트레이션합니다. 실제 구현 작업은 Claude Code 에이전트가 담당합니다. 이 시스템의 핵심은 ‘GitHub 이슈’를 작업 지시서(Work Order)로 전환한 것입니다. agent-spec 레이블이 지정되면 에이전트가 모호한 설명을 상세 구현 명세로 확장하고, agent-implement 레이블이 지정되면 해당 명세를 바탕으로 실제 코드 작성, 테스트 실행, PR 오픈까지 자동으로 수행합니다. 개발자는 터미널에서 직접 명령을 내리는 대신 프로젝트 관리 도구를 통해 고수준의 지시를 내리게 됩니다.
3. 실전 사례: Litestream 및 다중 코드베이스 관리
이 시스템의 위력은 복합적인 기술 부채 해결 과정에서 증명되었습니다. boswell-app의 SQLite 데이터 용량 문제로 인해 litestream-ruby 젬의 업그레이드가 필요한 상황이 발생했습니다. 저자는 이슈에 명세만 작성하여 에이전트에게 위임했고, 에이전트는 독립적으로 litestream-ruby 젬을 포크하여 바이너리 버전을 업그레이드하고 CI와 문서를 업데이트했습니다. 이어서 메인 앱인 boswell-app에서 Gemfile을 업데이트하고 Dockerfile 설정을 4차례의 시도 끝에 수정하여 테스트를 통과시켰습니다. 개발자가 직접 소스 코드를 읽고 수동으로 컨텍스트를 전환하며 디버깅해야 했던 작업을 에이전트가 스스로 조율하며 해결한 것입니다. 이는 서로 다른 도메인(Gem 개발과 Rails 앱 배포)을 동시에 다루는 인지적 고통을 획기적으로 줄여주었습니다.
4. 신뢰 구축과 상호 리뷰 루프의 중요성
저자는 에이전트의 작업 품질을 보장하기 위해 두 개의 에이전트가 서로의 결과물을 검토하는 ‘쓰기/리뷰 루프’를 도입했습니다. 모든 에이전트는 CLAUDE.md에 정의된 표준을 공유하며, 리뷰어 에이전트의 피드백을 반영하여 최종 결과물의 완성도를 높입니다. 이러한 과정은 개발자가 최종 승인(Merge) 전에 기술 부채가 쌓이는 것을 방지하며, 반복적인 디버깅 과정을 자동화합니다. 저자는 에이전트의 작업을 지켜보며 신뢰를 쌓았고, 이제는 중간 과정보다는 최종 결과물만 검토하는 방식으로 전환했습니다. 이 과정에서 발견되는 부족한 점은 다시 CLAUDE.md나 규칙 세트에 반영되어 시스템 전체의 지능을 높이는 선순환 구조를 만듭니다. 결국 100배의 생산성은 도구 자체가 아니라 이러한 운영 체계에서 나옵니다.