On this page
저는 Blosharper나 rig-c와 규모가 큰 프로젝트에 Claude Code, Codex, Antigravity를 동시에 사용하고 있습니다. 각 에이전트에게 일을 하나씩 주는 것은 어렵지 않습니다. 어려운 쪽은 이들의 작업을 서로 맞추는 일입니다.
여러 세션이 동시에 움직이면 누가 어떤 변경을 맡았는지, 어떤 작업이 먼저 끝나야 하는지, 다음 작업은 언제 시작해도 되는지를 누군가는 알고 있어야 합니다. 이 정보가 공유되지 않으면 필요한 작업도 문제가 될 수 있습니다. 다른 세션이 이미 수정 중인 영역에 또 다른 에이전트가 합리적인 이유를 가지고 손을 대는 식입니다.
실제로 병렬로 진행하던 작업을 멈추고 프로젝트의 조정 절차로 되돌린 적도 있습니다. 이 일을 겪으면서 문제가 분명해졌습니다. 에이전트를 연결하는 것만으로는 충분하지 않았습니다. 함께 판단하고 움직이기 위한 규칙도 필요했습니다.
AgentBridge는 서로 분리된 도구의 에이전트 세션 사이에 통신 경로를 제공합니다. 저는 그 위에 HQ라고 부르는 조정 세션을 두고 운영 방식을 만들어 가고 있습니다.
팀의 구조와 역할
저는 비서 에이전트를 대화 창구로 두고, 프로젝트별 HQ에 작업 조정을 맡기고 있습니다. 이슈 단위의 조정은 타워가, 조사와 구현은 워커(작업을 위임받아 수행하는 서브 에이전트)가 맡습니다. 이 역할을 모든 프로젝트에 같은 계층으로 배치할 필요는 없습니다. 작업 규모와 복잡도에 따라 HQ가 워커에 직접 맡기거나 타워를 통해 나눠 맡길 수 있습니다.
함께 쓰는 도구와 역할
이 글에서는 도구와 역할을 중심으로 운영 구조를 설명합니다. 함께 일하는 에이전트들의 소개와 가족 이미지는 함께 일하는 AI 에이전트 스쿼드에 따로 정리했습니다.
실행 도구로는 OpenAI Codex, Google Antigravity, Anthropic Claude Code를 사용합니다. 비서·HQ·타워·워커는 제품 이름이나 고정된 직무가 아니라, 작업을 맡길 때 구분하는 역할입니다.
아래 그림은 역할과 위임·보고 경로를 정리한 개념도입니다. 타워는 선택적으로 두는 계층이며, 워커의 수나 재위임 범위, 직접 실행과 리뷰·머지 권한은 각 프로젝트의 하네스에서 정합니다. 하네스는 에이전트의 실행과 위임을 제어하는 규칙입니다. AgentBridge는 지원하는 세션 사이의 통신을 담당하며 별도의 관리 계층은 아닙니다.
비서·HQ·타워·워커의 역할과 책임
비서 에이전트는 여러 프로젝트의 현황과 외부 정보를 모아 사람이 판단할 일을 정리합니다. 자료 조사와 행정 업무를 돕고, 개인·회사 일정이나 이메일·슬랙에서 놓치기 쉬운 메시지도 챙깁니다. 프로젝트 내부의 세부 작업은 HQ에 연결하고, 제품 방향과 영향이 큰 결정은 사람에게 가져옵니다.
HQ는 프로젝트 전체의 우선순위와 로드맵, 작업 배정과 의존성을 관리합니다. 이슈끼리 범위가 겹치거나 방향이 충돌하면 조정하고, 올라온 계획과 결과를 검토해 다음 작업으로 연결합니다. 작업을 타워에 맡길 수도 있고 워커에 직접 맡길 수도 있습니다. 직접 맡긴 작업은 HQ가 결과 검토까지 책임집니다.
타워는 맡은 이슈 하나의 해결 과정을 관장합니다. 목표와 현재 상태를 대조해 계획을 세우고, 필요한 일을 워커에게 나눠 맡긴 뒤 돌아온 결과를 독립적으로 리뷰합니다. 부족한 결과는 수정하도록 돌려보내고, 이슈 내부에서 해결할 수 없는 판단이나 다른 이슈에 영향을 주는 문제는 HQ에 올립니다. 구현에 매몰되어 전체 진행을 놓치지 않도록 조정과 리뷰에 집중하는 역할입니다.
워커는 배정된 범위 안에서 조사·구현·검증을 수행합니다. 결과뿐 아니라 확인한 근거, 테스트 내용, 남은 문제도 함께 보고합니다. 지시가 실제 상태와 맞지 않으면 근거를 들어 이의를 제기하고, 맡은 범위를 넘어서는 결정은 배정한 타워나 HQ에 확인합니다. 재위임이나 커밋·배포 같은 실행 권한은 작업을 맡길 때 정한 범위를 따릅니다.
어느 도구가 어느 역할을 맡을지, 타워를 둘지, 워커를 몇 개 띄울지는 응용의 영역입니다. 중요한 것은 계층 수보다 작업의 책임자, 판단 가능한 범위, 결과를 검토할 주체가 분명한가입니다. 역할을 합쳐 운영하더라도 그 책임까지 사라지는 것은 아닙니다.
작업의 배정과 검증
여러 세션이 동시에 일하려면 누가 일을 배정하고, 어디까지 판단하며, 결과는 누가 확인하는지가 분명해야 합니다. 저는 프로젝트 전체의 조정과 이슈 내부의 실행을 나누고, 작업 중 발견한 문제가 다시 계획에 반영되도록 운영하고 있습니다.
통신과 결정 권한의 분리
AgentBridge는 세션을 연결하고, HQ는 작업을 조정합니다.
메시지를 전달하는 도구가 있다고 해서 수신한 에이전트가 그 내용대로 행동해도 되는지까지 결정되는 것은 아닙니다. 그 판단은 운영 규칙의 영역입니다.
작업을 배정할 때는 목표와 범위뿐 아니라 판단 권한과 보고 대상도 함께 정합니다. 타워가 맡은 이슈는 타워가 실행을 조정하고 HQ에 결과를 보고하며, HQ가 직접 배정한 작업은 HQ가 계획과 결과를 검토합니다. 구현·리뷰·머지 권한을 어디에 둘지는 별도로 명시해야 합니다. 커밋을 마쳤다는 보고가 곧 머지 승인을 뜻하지는 않습니다.
필요하다면 세션끼리 참고용 상태 알림을 전달할 수도 있습니다. 다만 알림을 받았다는 이유로 새로운 일을 시작하거나 기존 계획을 바꾸지는 않습니다. 이슈 내부의 워커 배정과 재작업은 타워가 조정하고, 다른 이슈에 영향을 주는 결정은 HQ를 거칩니다.
프로젝트 차원의 의사결정은 HQ를 중심으로 모이고, 이슈 내부에서는 타워가 같은 조정 역할을 합니다. 그렇다고 모든 참고용 메시지까지 상위 조정자와의 대화로 바꿔야 한다는 뜻은 아닙니다. 중요한 경계는 누가 어느 범위의 작업을 지시하고 방향을 바꿀 수 있느냐에 있습니다.
작업자의 검증과 이의 제기
HQ가 전체 상황을 본다고 해서 항상 옳은 것은 아닙니다.
실제 코드를 확인한 작업자는 지시가 이미 사라진 API를 전제로 한다거나, 기존 구현과 충돌한다거나, 다른 세션이 맡은 작업 범위를 건드린다는 사실을 발견할 수 있습니다. 이때 지시를 그대로 수행하면 조정 구조를 둔 의미가 줄어듭니다.
작업자는 무엇을 발견했는지 근거와 함께 설명하고, 필요하면 지시에 반박해야 합니다. 타워가 있는 구성에서는 타워가 그 정보를 검토해 이슈 내부의 계획을 고치고, 다른 이슈와 충돌하는 문제는 HQ로 올립니다. HQ가 직접 배정한 작업은 HQ에 이의를 제기합니다.
중앙 조정자는 실제 작업에 가장 가까이 있는 세션의 피드백을 받아야 합니다. 그렇지 않으면 같은 실수를 여러 작업자에게 배포하는 창구가 될 뿐입니다.
이슈의 배정부터 결과 보고까지
타워를 두는 경우의 작업 흐름은 다음처럼 구성할 수 있습니다. HQ가 워커에 직접 맡길 때는 이슈 내부의 조정과 결과 검토도 HQ가 담당합니다. 실제 워커 수와 위임 방식은 각 하네스에 맞춥니다.
- HQ가 타워에 이슈를 배정합니다. 목표, 대상 저장소, 작업 범위, 기대하는 결과를 전달합니다.
- 타워가 계획을 세우고 워커를 배정합니다. 지시를 실제 상태와 대조하고, 필요한 조사·구현·검증 작업을 나눕니다.
- HQ가 프로젝트 차원의 조정 문제를 해결합니다. 선행 작업, 이슈 간 담당 범위의 충돌, 방향 변경을 정리합니다.
- 워커가 구현하고 검증합니다. 배정된 작업 공간이나 워크트리에서 변경을 만들고, 해당 변경에 필요한 테스트와 검사를 수행합니다.
- 해결되지 않은 판단은 상위로 올립니다. 이슈 내부의 문제는 타워가 조정하고, 프로젝트 차원의 문제는 HQ로, 제 판단이 필요한 결정은 저에게 돌아옵니다.
- 타워가 결과를 리뷰하고 보고합니다. 워커가 가져온 결과를 검토해 잘못되거나 부족한 부분은 수정하도록 돌려보냅니다. 검토를 마친 뒤 무엇을 바꿨고 검증했는지, 남은 문제는 무엇인지 HQ에 보고합니다.
- HQ가 결과를 다음 이슈에 연결합니다. 이어서 진행할 수 있는 일과 추가 검토가 필요한 일을 구분합니다.
이것은 역할과 책임의 구분이지, 모든 변경마다 일곱 번 멈춰 승인을 받는 절차는 아닙니다. 단순한 작업은 빠르게 흘러가고, 요구사항이 충돌하면 다시 계획 단계로 돌아갈 수 있습니다.
계획 보고와 실행 사이의 경계도 명확해야 합니다. 작업자가 침묵을 승인으로 해석해야 하는 상황은 피하는 편이 좋습니다. 승인이 필요한 작업은 그렇게 명시하고, 이미 실행까지 맡긴 작업에는 불필요한 대기 단계를 추가하지 않는 것입니다.
독립된 워크트리는 개발 중인 변경을 분리하는 데 도움이 됩니다. 하지만 서로 양립할 수 없는 설계 판단까지 해결하거나, 병합의 안전성을 보장해 주지는 않습니다. 작업 조정은 여전히 필요합니다.
실제 운영 환경
제가 진행하는 일 중 rig-c와 블로샤퍼만 해도 GitHub 저장소가 26개입니다. 여기에 차기 게임을 비롯한 다른 프로젝트도 함께 진행하고 있습니다. 저는 여전히 월급을 받는 직장인입니다. 회사 일도 해야 하니, 개인 프로젝트의 모든 세션을 직접 붙잡고 있을 수는 없습니다. 에이전트들과 역할을 나누고 작업을 연결하면서, 혼자서도 이 범위를 다룰 수 있게 되었습니다.
직장과 여러 프로젝트의 병행
손수 코딩하지 않은 지도 거의 1년이 되어갑니다. 제가 맡기는 구현 작업에서 체감하는 에이전트의 코딩 능력은 이미 사람을 뛰어넘었습니다. 그래서 요즘은 코드를 얼마나 잘 작성하느냐보다, 여러 에이전트가 할 일을 어떻게 정하고 이어주느냐에 더 많은 시간을 씁니다.
여러 개발팀을 동시에 이끄는 CTO가 된 기분입니다. 여러 프로젝트에서 올라오는 보고를 읽고, 방향을 정하고, 다음 일을 배정하며 하루를 보냅니다.
현재의 구독 구성
독자들이 실제로 무엇을 얼마나 쓰는지 궁금해할 것 같아, 현재 구성을 적어둡니다.
- Claude Ultra 계정 2개와 Max 계정 2개 (총 4개)
- ChatGPT Pro 500 계정 1개
- Google AI Ultra 30TB 1개
비서로는 ChatGPT의 dot을 사용합니다. 공식 안내에서는 GPT-6 Astra 기반으로 소개하고 있습니다. 제 환경에서는 MCP로 외부 도구를 연결해 쓰면서 별도의 API 토큰 요금을 내지 않고 있습니다. dot과의 대화는 ChatGPT 사용량 한도에 산입되지 않습니다. 다만 Work·Codex로 위임된 작업은 각 사용량 한도를 소모하므로, 이 방식으로 사용할 때는 해당 작업으로 위임되지 않도록 주의합니다.
제 목표는 주어진 주간 사용량을 남김없이 활용하는 것입니다. 여러 구독을 병행하는 만큼 어느 도구에 일이 몰려 있고, 어느 쪽에 사용량이 남았는지도 운영의 일부가 됩니다.
토큰을 배분하는 방식
프로젝트 HQ는 주로 Claude에 맡깁니다. HQ에도 코드 리뷰, 자료 조사, 프로젝트 운영에 쓸 여력이 필요해서 직접 코딩은 많이 시키지 않습니다. 구현은 작업의 규모에 따라 HQ가 워커에 직접 맡기거나 타워를 거쳐 맡깁니다. 직접 실행 예외도 각 프로젝트의 규칙을 따릅니다.
요즘은 사용량 리셋이 자주 돌아오는 Codex부터 사용합니다. 10월 31일부터는 남은 사용량이 약 2%가 되면 새 작업을 Antigravity에 배정하고, 마지막 2%는 코드 리뷰용으로 남겨 둡니다. 이미 진행 중인 작업과 리뷰에서 요청된 수정은 마무리합니다. 제 사용 환경에서는 Antigravity 쪽에서 활용할 수 있는 양이 가장 많습니다.
최근에는 Argon이 코딩 작업에 적합하다고 느끼고 있습니다. 한 달 정도 사용하면서 큰 사고를 겪지 않았습니다. 반면 Flash는 제 코딩 작업에 쓰지 않습니다. 제 경험에서는 리뷰와 수정이 계속 오가면서 토큰이 오히려 더 들었습니다. 모델 선택은 첫 구현이 빨리 나오는지만 보고 결정하기 어렵습니다.
이 순서는 지금 제가 쓰는 구독과 작업에서 맞춰온 방식입니다. 사용량과 모델의 특성이 달라지면 배분도 다시 바꿀 생각입니다.
운영 방식의 변화
목표는 의미 있는 사건을 중심으로 작업을 연결하는 것입니다. 작업이 끝났거나, 기다리던 의존성이 준비됐거나, 혼자 해결하기 어려운 문제가 생겼을 때 다음 판단으로 이어지게 합니다.
결과가 다음 작업으로 이어지게 하기
제가 세션마다 결과를 복사해서 전달하는 대신, 결과를 받은 조정자가 다음 행동을 결정하도록 만드는 것입니다. 타워가 있는 경로에서는 타워가 워커의 결과를 검토해 HQ에 보고하고, HQ 직속 작업은 HQ가 직접 검토해 다음 이슈로 연결합니다.
물론 메시지 전달과 작업 완료는 다릅니다. 요청이 도착해도 작업은 실패할 수 있습니다. 결과를 보고하기 전에 세션이 멈출 수도 있습니다. 안정적으로 운영하려면 요청을 보냈다는 사실뿐 아니라 실제 결과를 확인해야 합니다.
컨텍스트도 마찬가지입니다. 재시작된 세션은 기존 지시를 복구하는 것에 더해 현재 상태를 다시 확인해야 할 수 있습니다. 이전에 무엇을 하라고 했는지만으로는 그동안 실제로 어떤 일이 일어났는지 알 수 없기 때문입니다.
서로를 깨우며 이어지는 작업
이 구성에서 제가 가장 크게 느끼는 장점은 에이전트들이 서로를 깨운다는 것입니다. HQ와 직접 배정받은 워커가, 타워를 둔 구성에서는 HQ와 타워가 작업 지시, 질의응답, 완료 보고를 주고받으며 서로를 깨웁니다. 타워와 워커 사이에서도 질문과 답변, 결과 보고와 재작업 지시가 이어집니다. 타워가 검토한 결과가 HQ에 돌아오면 다음 이슈로 연결됩니다. 제가 매번 돌아다니며 계속하라고 말할 필요가 줄어듭니다.
로드맵과 이슈가 정리되어 있으면 이 흐름이 꽤 오래 이어집니다. 체감상으로는 깃허브의 이슈 목록이 마를 때까지 달리는 것 같습니다. 물론 막힌 판단이나 사용량 제한이 생기면 사람이 다시 개입해야 합니다. 그래도 작업 하나가 끝난 뒤 다음 지시를 기다리며 멈춰 있는 시간이 줄어든 차이는 큽니다.
GitHub 활동량 비교
9월에는 AgentBridge와 HQ 없이 데스크톱 세 개를 열어놓고 제가 직접 에이전트들을 조정했습니다. 여러 에이전트를 쓰는 일 자체는 이미 하고 있었던 셈입니다. 10월에는 그 조정 작업을 AgentBridge와 HQ 중심으로 옮겼습니다.
제 GitHub 프로필의 최근 1년 기여 수는 약 2만 7천 건입니다. 9월은 이미 수동으로 여러 에이전트를 조정하던 시기이므로, 그보다 앞선 8월과 10월을 비교했습니다. 2026년 10월 31일 오전 1시 6분(KST)에 확인한 공개 기여 달력에서, GitHub 날짜 기준으로 아직 진행 중이던 10월 30일을 제외하고 같은 29일을 집계했습니다.
기간 | Contributions |
2026년 8월 1~29일 | 3,195 |
2026년 10월 1~29일 | 9,627 |
10월의 활동은 같은 기간의 8월보다 약 3.01배, 201.3% 늘었습니다. AgentBridge를 본격적으로 적용한 뒤 작업이 훨씬 많이 돌아간다는 제 체감과도 맞습니다. 다만 이 수치는 커밋뿐 아니라 PR과 이슈 등도 포함하는 활동 지표입니다. 작업 종류나 프로젝트 상황까지 같게 맞춘 비교는 아니므로, 생산성이나 품질이 세 배가 됐다거나 증가분이 전부 AgentBridge 덕분이라고 단정할 수는 없습니다.
사람의 역할과 남은 과제
일상적인 작업 조정에 쓰는 주의력을 줄이고 싶습니다. 동시에 프로젝트를 어떤 방향으로 만들 것인지는 계속 직접 결정하고 싶습니다.
사람이 계속 맡는 일
HQ와 타워는 각자의 범위에서 이런 결정을 모아 주는 역할을 합니다. 워커는 배정된 범위 안에서 구현의 세부 사항을 처리하고, 제품 방향이나 해석이 갈리는 선택, 영향이 큰 변경은 저에게 가져올 수 있습니다.
현재의 한계
한계도 남아 있습니다. HQ 자체가 병목이 될 수 있습니다. 여러 모델이 같은 요구사항을 함께 오해할 수도 있습니다. 컨텍스트가 사라지거나 세션이 실패할 수 있고, 사용량 제한 때문에 계획이 중단되기도 합니다. 결정을 중앙에 모은다고 이런 문제가 사라지지는 않습니다. 다만 어디서 확인하고 해결해야 하는지가 더 분명해집니다.
제게 멀티 에이전트 오케스트레이션은 이런 경계를 명확히 해 나가는 과정입니다. 유능한 에이전트를 하나 더 투입했을 때, 그 에이전트가 무엇을 해야 하는지, 누가 그 결정을 바꿀 수 있는지, 결과를 다른 세션은 어떻게 알게 되는지가 정리되어 있어야 합니다.
AgentBridge는 세션들이 소통할 수 있는 길을 만듭니다. 그 위의 운영 규칙이 에이전트들을 한 팀으로 움직이게 합니다.
달라지는 일의 문화
이렇게 일하다 보니 일의 문화가 달라지고 있다는 생각을 합니다. 앞으로 인간에게는 프로젝트를 어떤 방향으로 이끌지 결정하는 능력과, 여러 AI 에이전트를 함께 운영하는 능력이 더욱 중요해질 것 같습니다.
에이전트 한 명을 잘 쓰는 데서 더 나아가, 여러 에이전트가 각자의 일을 하고 결과를 이어가도록 만드는 연습이 필요하다고 봅니다. 저는 지금 세 프로젝트를 동시에 운영하며 그 방법을 익히고 있습니다. 지금 세 프로젝트가 동시에 돌아가고 있다는 것이 제 나름의 실험 결과입니다.