Agent Hub를 만든 이유: Claude·Codex·Cursor가 함께 토론하고 작업하는 로컬 사무실

TL;DR

• Agent Hub Radio는 Claude Code·Codex CLI·Cursor Agent를 한 채널에 연결하고, 토론과 작업 과정을 함께 보는 로컬 에이전트 허브다.
• 여러 에이전트를 사용하면서 생기는 의견 전달, 맥락 인계, 결과 확인 과정을 한곳에 모으고 싶어서 만들었다.
• 먼저 각자의 의견을 독립적으로 받고, 필요한 쟁점을 토론한다. 최종안은 작성자를 제외한 동료가 검토한다. 선택지만 비교하고 싶을 때는 독립 비밀 투표를 쓴다.
• 계획 → 구현 → 검토를 역할별로 맡기고, 원본과 분리한 작업 사본에서 결과물을 만든다. 패치·ZIP·보고서를 확인하고 후속 작업이나 원본 반영으로 이어갈 수 있다.
• 사무실 화면에서는 에이전트의 상태를 공간과 캐릭터로 볼 수 있다. 현재 0.3.0 Alpha, Windows 중심으로 검증한 개인 오픈소스 프로젝트다.

들어가며

최근 블로그에서 멀티 에이전트 통신 수단을 비교하고, 에이전트의 완료 보고를 교차 검수하는 문제를 정리했다. 에이전트를 여러 개 쓰다 보니, 각각의 답변만큼이나 답변 사이를 연결하는 과정이 중요해졌다.

한쪽에서 설계 의견을 받고, 다른 쪽에 구현을 맡기고, 다시 다른 에이전트에게 검토를 요청한다. 그 과정에서 누군가는 앞선 대화를 정리해서 전달해야 한다. 어떤 조건에 동의했는지, 검토 의견이 실제 수정에 반영됐는지, 지금 보고 있는 결과가 어느 작업의 결과인지도 챙겨야 한다.

이 흐름을 한 화면에서 다루고 싶었다. 그렇게 만들고 있는 것이 Agent Hub Radio다. 이 글에서는 편하게 Agent Hub라고 부르겠다.

이 글은 2026년 9월 18일의 로컬 0.3.0 Alpha 구현을 기준으로 작성했다. 모든 캡처는 해당 UI에 소개용 예시 데이터를 넣어 촬영했다. 대화와 작업 결과는 실제 모델 실행 기록이나 성능 측정 결과가 아니다.

왜 만들었나: 에이전트 사이의 연결을 계속 사람이 맡고 있었다

여러 에이전트를 쓰는 이유는 같은 문제를 다른 관점에서 살펴보고 싶기 때문이다. 설계의 빈틈을 찾아보거나, 구현을 다른 시각으로 검토하거나, 두 가지 대안의 장단점을 비교할 수 있다.

그런데 창을 여러 개 띄우는 것만으로는 이런 흐름이 완성되지 않는다. A가 낸 의견을 B에게 전달하고, B가 지적한 조건을 다시 A에게 알려줘야 한다. 마지막 답변을 읽을 때는 누가 어떤 맥락을 알고 답했는지도 확인해야 한다.

Agent Hub에서 줄이고 싶었던 번거로움은 다음과 같다.

이런 문제를 풀려면 메시지를 주고받는 기능과 작업의 시작·검토·종료를 관리하는 기능이 함께 있어야 했다. 이전에 살펴본 실시간 채널과 워크플로의 장점을 실제로 쓰는 화면 안에서 연결해 보고 싶었다.

Agent Hub는 무엇을 연결하나

Agent Hub는 로컬에서 실행되는 웹 UI와 Python 서버다. 설치하고 로그인해 둔 Claude Code, Codex CLI, Cursor Agent를 호출하고, 채널 메시지 연결에는 Coral을 사용한다. 자체적으로 새로운 모델을 학습시키거나 제공하는 서비스는 아니다.

사용자는 채널을 만들고, 참여할 에이전트를 선택하고, 요청을 보낸다. Hub는 필요한 단계에 맞춰 CLI를 실행하고 결과와 상태를 저장한다. 화면에서는 대화, 사무실, 작업 탭을 오가며 이를 확인한다.

Claude는 계획, Codex는 구현, Cursor는 검토처럼 배정할 수 있지만 고정된 역할은 아니다. 작업에 맞춰 사용자가 정한다. 이 글의 화면에 나오는 배정도 사용 예시다.

1. 한 채널에서 대화하고, 필요한 에이전트만 참여시키기

기본 화면은 채널형 메신저에 가깝다. 왼쪽에서 채널을 고르고, 오른쪽에서 대화와 작업을 확인한다. 에이전트별 필터와 대화 검색이 있고, 코드 블록과 표를 포함한 Markdown을 표시한다.

첫 요청에서 멘션한 에이전트가 해당 토론의 참여자가 된다. 매번 연결된 에이전트를 전부 부를 필요는 없다. 두 명의 의견이면 충분한 질문에는 두 명만 참여시킬 수 있다.

같은 토론이 진행 중일 때 보내는 추가 메시지는 기존 팀에 대한 추가 지침으로 취급한다. 참여자를 바꿔 별개의 검토를 하고 싶다면 다른 채널에서 시작한다. 한 채널에서 서로 다른 요청과 팀 구성이 뒤섞이는 일을 줄이기 위한 규칙이다.

상단에서는 에이전트별 다음 호출 모델을 지정할 수 있다. 빈칸이면 해당 CLI의 기본값을 사용한다. Hub에서 지정한 모델은 다음 호출에 적용되며, 이미 실행 중인 호출의 모델이 중간에 바뀌지는 않는다.

실제 응답은 설치된 CLI와 로그인한 계정으로 실행한다. 화면에서 모델을 선택했다고 그 계정의 사용 권한이나 한도까지 바뀌는 것은 아니다.

2. 독립 의견부터 동료 검토까지: 토론에 순서 만들기

같은 질문을 세 에이전트에게 던지고 답을 세 개 받는 것에서 한 단계 더 나아가고 싶었다. 각자의 관점을 보존하면서도, 마지막에는 실제로 비교하고 검토한 결과를 남기는 흐름이다.

현재의 토론은 대략 다음 순서로 진행된다.

사용자 요청과 참여자 확정
        ↓
각자 독립 의견 준비
        ↓
전원 제출 후 의견 동시 공개
        ↓
쟁점 확인 → 필요한 상대에게 질문·답변
        ↓
통합안 작성
        ↓
작성자를 제외한 동료가 같은 최종안을 검토
        ↓
완료 / 수정 후 재검토 / 미해결 쟁점을 남기고 보류

먼저 각자 생각하고, 그다음에 비교하기

독립 의견 준비 단계에서는 다른 참여자의 답변과 질문을 전달하지 않는다. 전원이 의견을 제출하면 함께 공개한다. 먼저 나온 답을 보고 나머지가 비슷한 방향으로 정리하는 영향을 줄이려는 설계다.

이는 Hub가 전달하는 입력을 분리한다는 뜻이다. 모델들이 서로 완전히 다른 학습 배경을 갖는다거나, 같은 오류를 내지 않는다는 뜻은 아니다. 서로 비슷한 모델이 같은 잘못된 전제를 선택할 가능성은 여전히 있다.

한 명이 독립 의견 제출에 실패하면 그 사실을 남기고 보류한다. 누락된 의견을 있는 것처럼 채워 넣거나 전원 검토가 끝났다고 표시하지 않는다.

필요한 쟁점만 다시 묻기

의견을 모은 뒤에는 대표가 실제로 다른 주장과 남은 질문을 비교한다. 추가 확인이 필요한 상대에게 질문하고, 질문받은 에이전트가 응답한다. 모든 사람이 매 단계마다 반드시 한 번씩 더 말하도록 만들지는 않았다.

토론이 길다는 이유만으로 결과가 더 좋아지는 것은 아니기 때문이다. 기본 의견은 주장, 근거, 우려를 간결하게 작성하도록 안내한다. 반대할 이유가 없는데 억지로 반대 의견을 만드는 것도 요구하지 않는다.

작성자는 자기 최종안을 승인하지 않기

현재 새 토론에서는 해당 버전의 최종안 작성자를 검토 승인 대상에서 제외한다. 나머지 참여자 모두가 동일한 최종안을 검토하고 승인해야 완료된다. 반대가 있으면 조사와 수정을 거쳐 다시 검토한다.

예를 들어 Claude가 통합안을 작성했다면 Codex와 Cursor가 그 안을 검토한다. 마지막 메시지에 적힌 “승인”이라는 단어만 읽고 성공으로 취급하는 대신, Hub가 실제 작성자와 검토 기록을 구분해 표시한다.

한 명만 참여한 경우에는 단독 작성 결과로 표시한다. 다른 사람이 검토하지 않았는데 교차 검토나 합의라고 부르지 않는다.

추가 질문이나 수정이 없는 3인 기본 경로는 독립 의견 3회 + 쟁점 확인 1회 + 통합안 1회 + 동료 검토 2회, 총 7회 호출로 구성된다. 이는 현재 단계 구성에 따른 호출 수이며, 실제 시간이나 비용을 보장하는 수치는 아니다. 질문, 수정, 형식 복구가 필요하면 호출이 늘어난다.

합의에 도달하지 못했을 때는 미확정 초안과 남은 이견을 보여준다. 사용자에게 필요한 것이 때로는 “모두 동의했다”는 문장보다 “이 부분에서 아직 의견이 갈린다”는 정보일 수 있기 때문이다.

3. 독립 비밀 투표: 같은 자료로 각자의 선택 보기

토론까지 열 필요 없이 대안에 대한 판단을 비교하고 싶은 경우도 있다. 이를 위해 독립 비밀 투표를 따로 만들었다.

지문과 2~4개의 선택지를 입력하고 참여자와 마감 시간을 정한다. 각 에이전트는 새 CLI 호출에서 같은 자료를 받고, 한 번의 선택과 근거·우려를 제출한다. 판단하기 어렵다면 기권할 수 있다.

이때 기존 채널 대화나 다른 에이전트의 응답을 자동으로 전달하지 않는다. 따라서 판단에 필요한 조건을 투표 지문에 넣어야 한다. “아까 이야기한 대로 골라줘”라고만 쓰면 공통 자료가 충분하지 않다.

모든 참여자의 처리가 끝나거나 마감 시간이 되면 표를 함께 공개한다. 미응답, 실패, 기권을 구분하고, 동률이면 공동 최다 득표로 표시한다. 유효표가 없다면 승자를 만들어 내지 않는다.

예를 들어 다크 모드 출시 방식을 다음과 같이 물을 수 있다.

공통 조건
- 기존 사용자의 화면 설정을 유지해야 한다.
- 접근성 문제를 먼저 확인해야 한다.
- 사용자 피드백을 받아 수정할 여지가 필요하다.

A. 소규모 사용자에게 먼저 공개
B. 전체 사용자에게 동시에 공개

선택과 핵심 근거, 가장 우려되는 점을 알려줘.

내가 보고 싶은 것은 A와 B의 표수뿐 아니라 선택의 이유다. 같은 A를 골랐더라도 한 에이전트는 접근성을, 다른 에이전트는 롤백 범위를 중요하게 봤을 수 있다. 그 차이를 후속 검토의 재료로 쓸 수 있다.

투표실 화면에서는 공개 전 각자의 작업석에 있다가, 공개 후 선택한 구역으로 이동한다. 같은 선택을 한 에이전트끼리 모이고, 캐릭터를 눌러 근거를 확인할 수 있다.

이 기능의 “비밀”은 앱에서 다른 참여자의 선택을 미리 제공하지 않고 함께 공개한다는 뜻이다. 암호화된 선거 시스템은 아니다. 또한 다수 득표가 정답이거나 실행 승인인 것도 아니다. 결과를 작업 입력으로 가져온 뒤 최종 지시는 사용자가 정한다.

4. 역할 분담 작업: 이야기한 내용을 실제 결과물로 만들기

토론이 끝난 뒤에는 실제 파일을 바꾸는 단계가 남는다. 이 연결을 위해 역할 분담 작업을 넣었다.

작업 목표, 로컬 Git 저장소, 계획·구현·검토 담당자를 지정한다. 작업 유형은 자동 또는 조사·분석, 기능 개발, 수정·개선, 문서 정리로 정할 수 있다. 조사·분석은 읽기 전용으로 진행한다.

같은 에이전트를 여러 역할에 지정하거나 한 역할에 여러 명을 배정할 수도 있다. 여러 담당자는 지정한 순서로 실행한다. 같은 파일을 여러 에이전트가 동시에 편집하는 방식은 아니다.

원본과 작업 사본을 분리하기

첫 실행은 미커밋 변경이 없는 Git 저장소를 대상으로 한다. 원본의 HEAD를 별도 사본으로 복제하고 그 안에서 작업한다. 원본과 Git 객체를 공유하지 않으며 사본의 origin 연결도 제거한다.

이렇게 하면 생성된 변경을 원본에 반영하기 전에 검토할 수 있다. 다만 작업 사본은 모든 도구의 접근을 차단하는 OS 수준의 보안 격리는 아니다. 실제 실행 권한은 각 CLI와 운영체제의 정책에 따른다.

검토 완료와 테스트 통과를 구분하기

검증 명령은 선택 사항이다. 명령을 지정하면 Hub가 사본에서 실행하고 종료 코드와 출력을 기록한다. 이후 검토 담당자가 파일과 실행 기록을 확인한다.

명령을 넣지 않았다면 테스트 미실행이라고 표시한다. 문서를 검토한 작업이나 테스트 환경을 준비하지 않은 작업을 테스트 통과로 보이게 만들고 싶지 않았다.

검증 명령이 통과했더라도 담당자의 검토가 남아 있으면 완료가 아니다. 반대로 담당자가 검토를 마쳤더라도 명령을 실행하지 않았다면 그 사실을 그대로 남긴다. 검토 대상 파일이 바뀌었는지도 파일 지문으로 확인한다.

구체적인 수정 요청이 나오면 구현 단계로 돌아갈 수 있다. 재시도 횟수는 정해 둔 범위에서 제한하고, 권한이나 실행 환경 문제를 무작정 같은 호출로 반복하지 않도록 보류 상태를 둔다.

원본 반영은 결과를 확인한 다음에

완료된 작업에서는 패치, 변경 파일 ZIP, 보고서를 받을 수 있다. 후속 작업을 기존 사본에서 이어가거나 원본 반영 · 커밋 · push 화면으로 이동할 수도 있다.

원본 반영 화면에서는 대상 저장소와 브랜치, 변경 파일과 diff, push 주소를 확인한다. 기본 실행 범위는 원본 반영과 스테이징이며, 커밋과 push는 따로 선택한다. 원본의 기준 커밋이나 변경 상태가 맞지 않으면 임의로 덮어쓰거나 병합하지 않는다.

사본에서의 작업 완료, 원본 반영, 커밋, 원격 push를 각각 확인할 수 있게 나누었다. 에이전트가 파일을 만들었다는 사실과 그 파일을 실제 프로젝트에 반영했다는 사실은 별도로 추적할 필요가 있다.

5. 사무실 화면: 지금 어느 단계인지 공간으로 보기

이 프로젝트에서 시각적으로 가장 눈에 띄는 부분은 사무실이다. 공용 연구실, 토론실, 조율실, 검토실과 휴식 공간을 두고 작업 단계에 맞춰 에이전트가 이동하도록 했다.

독립 의견을 준비하는지, 쟁점을 토론하는지, 최종안을 작성하거나 검토하는지를 화면의 위치로 읽는다. 여러 채널을 다루면서 현재 상태를 빠르게 살펴보는 데 쓰려는 UI다.

맵은 직접 드래그하거나 확대·축소할 수 있다. 전체 맵, 방 선택, 미니맵과 에이전트 따라가기를 지원한다. 화면을 넓게 보고 싶으면 전체화면으로 전환하면 된다.

공개된 새 발언은 캐릭터 위 말풍선으로 잠시 보여주고, 작은 팀 대화창에서도 읽을 수 있다. 긴 내용은 대화 탭에서 확인한다. 아직 공개되지 않은 독립 의견이나 투표 선택은 사무실에서도 미리 보여주지 않는다.

캐릭터를 선택하면 상세 내용을 보거나 해당 에이전트에게 질문·작업을 요청하는 흐름으로 이동할 수 있다. 단독 작업은 한 명의 구현과 자체 검토이며, 여러 에이전트의 독립 교차 검토와 구분한다.

사무실의 이동과 말풍선 표시는 Hub가 가진 상태와 공개 메시지를 시각화한 것이다. 이 화면을 켜 놓는 것만으로 추가 모델 호출을 만들지 않는다. 에이전트의 비공개 추론이나 다른 프로그램에서 진행 중인 모든 작업을 보여주는 기능도 아니다.

6. 끝난 작업을 다음 대화와 연결하기

한 번의 실행이 끝난 뒤에도 대화는 계속된다. 결과를 설명해 달라고 할 수도 있고, 빠진 문서를 보완하거나 다른 조건으로 다시 검토할 수도 있다.

같은 채널에서 새 토론을 시작하면 최근 종료된 역할 작업의 목표, 상태, 테스트 여부, 인계 기록, 변경 파일과 결과물 경로를 참고 자료로 전달한다. 특정 과거 작업은 이 작업에 대해 대화하기로 지정할 수 있다.

완료 작업의 후속 작업 요청은 기존 작업 사본을 이어 쓴다. 앞선 결과물을 보존하면서 후속 실행의 요청과 검토 기록을 별도로 남기고, 후속 패치는 최초 기준 커밋 대비 누적 변경을 담는다.

반대 방향도 연결된다. 토론의 합의안이나 투표 결과에서 작업 준비를 누르면 참고 내용을 작업 요청 창으로 가져온다. 그 내용을 바탕으로 목표와 담당자를 확인한 뒤 실행한다.

다만 진행 중인 역할 작업에 일반 채팅으로 보낸 메시지는 작업 조건을 실시간으로 변경하지 않는다. 그 메시지는 대화 기록에 남는다. 실행 도중 요구사항을 바꾸려면 작업을 중지하고 새 요청으로 시작해야 한다.

7. 다시 찾아볼 수 있도록 기록 남기기

대화가 조금만 쌓여도 “어디까지 했지?”가 새로운 문제가 된다. 그래서 결과물 생성과 함께 기록을 다시 읽는 기능도 넣었다.

채널 요약의 기본값은 요청과 합의 결과, 작업 기록을 기준으로 표시한다. 일반 대화 전체를 별도의 모델이 읽고 추론한 요약은 아니다. 필요한 내용은 직접 편집해 저장할 수 있다.

토론 Markdown 저장은 채널에 저장된 기록을 문서로 내보낸다. 이때 별도 모델 호출을 하지 않고, 아직 비공개인 독립 의견은 내보내지 않는다.

실행 기록의 토큰 정보도 CLI가 실제로 보고한 항목만 사용한다. 제공되지 않은 값을 추정해 채우거나 금액·절감률로 환산하지 않는다. 여러 에이전트가 겹쳐 실행되면 각자의 실행 시간 합계와 사용자가 기다린 전체 시간은 다를 수 있다.

실제로는 이렇게 써볼 수 있다

다크 모드를 추가하는 작은 개선을 예로 들면 전체 흐름은 다음과 같다. 아래는 사용 시나리오이며 실제 실행 성과를 소개하는 사례는 아니다.

1. 채널을 만든다. 설정 화면 개선이라는 주제로 참여할 에이전트를 정한다.
2. 먼저 검토를 요청한다. 시스템 테마를 따를지, 사용자가 수동 전환할지, 기존 설정은 어떻게 유지할지 질문한다.
3. 독립 의견과 쟁점을 읽는다. 구현 범위, 접근성, 저장 방식에 대한 관점을 비교한다.
4. 필요하면 별도 투표를 한다. 소규모 공개와 전체 공개처럼 선택지가 분명한 문제를 같은 자료로 비교한다.
5. 확정한 방향으로 작업을 준비한다. 합의안을 가져오고 대상 저장소, 역할, 검증 명령을 지정한다.
6. 사본에서 구현과 검토를 진행한다. 작업 카드와 사무실에서 상태를 보고 결과 파일과 로그를 확인한다.
7. 후속 질문이나 수정을 요청한다. “키보드 조작은 어떻게 처리했나?”, “사용법 문서도 추가해 줘”처럼 이어간다.
8. 검토한 변경을 원본에 반영한다. diff를 확인하고 필요한 Git 작업 범위를 선택한다.

모든 작업에 이 단계를 전부 사용할 필요는 없다. 작은 질문에는 한 명의 읽기 전용 질의로 충분할 수 있다. 대안을 비교할 때는 투표를, 실제 파일을 바꿀 때는 역할 작업을 고르면 된다.

내부 구조는 어떻게 되어 있나

허브 본체는 Python 표준 라이브러리 기반 로컬 서버와 SQLite로 구성했다. 화면은 HTML·CSS·JavaScript, 사무실 맵은 SVG를 사용한다. 현재 패키지의 Python 런타임 외부 의존성 목록은 비어 있다. 실제 에이전트 연결에는 별도의 CLI와 Coral 실행 환경이 필요하다.

브라우저 / Windows 데스크톱 앱 창
                ↕
Agent Hub 로컬 서버
    ├─ SQLite: 채널 기록, 토론 단계, 작업 상태
    ├─ 실행 조율: 토론 / 투표 / 역할 작업
    │       └─ Claude Code / Codex CLI / Cursor Agent
    ├─ Coral 연결: 채널 메시지와 최종 결과
    └─ 데이터 폴더: 작업 사본, 실행 로그, 결과물

Coral은 메시지를 연결하고, Hub는 내부 토론 단계와 수신함, 검토 상태를 관리한다. 상세 내부 토론의 기준 기록은 Hub의 로컬 DB에 남는다. 다른 기기의 내부 수신함까지 동기화하는 구조는 아니다.

공식 coral-server.jar를 사용하며 AgentRadio 애플리케이션을 별도로 설치할 필요는 없다. 다만 Coral 서버와 Java, 에이전트별 CLI 설치와 로그인은 준비해야 한다.

실행 중 도착하는 메시지는 기본적으로 다음 CLI 호출에서 전달한다. Claude와 Codex에는 일부 도구 완료 경계에서 메시지를 전달하는 실험적 옵션도 있지만 기본값은 꺼짐이며, Codex에는 별도 훅 신뢰 등록이 필요하다. 모든 CLI에서 똑같이 동작하는 상시 실시간 대화 기능으로 소개할 단계는 아니다.

이런 연결 방식은 MCP·ACP·Coral과 0-turn 통신을 살펴본 글의 관심사와도 이어진다. 현재 Hub에서는 실제 지원 범위와 수신 확인 기록을 구분해 두는 데 집중했다.

설치하고 화면부터 둘러보기

Python 3.11 이상이 필요하다. Windows에서 소스로 실행하려면 다음과 같이 설치한다.

git clone https://github.com/kdkrkwhr/agent-hub.git
cd agent-hub
python -m venv .venv
.venv\Scripts\python -m pip install -e .
.venv\Scripts\agent-hub --desktop

macOS·Linux의 실행 방법도 저장소 README에 있다. 현재 직접 검증은 Windows를 중심으로 진행했다.

첫 화면에서 데모로 둘러보기를 고르면 계정 연결이나 모델 호출 없이 UI를 확인할 수 있다. 기본 주소는 http://127.0.0.1:8768이다. Windows의 --desktop은 별도 Edge 앱 창을 사용하며, 첫 데스크톱 실행 때 데이터 저장 폴더를 선택한다.

실제 에이전트를 연결하려면 사용할 CLI를 설치하고 로그인한 다음 Coral 설치 가이드에 따라 서버와 연결 정보를 준비한다. Hub에서 연결을 확인하고 허브 자동 응답을 켠 뒤 새 요청을 보내면 된다.

자동 응답은 기본적으로 꺼져 있다. 실제 실행은 연결한 서비스의 사용량을 소비한다. “로컬 허브”라는 말은 화면과 상태 저장을 로컬에서 관리한다는 뜻이며, 모델 추론까지 전부 로컬에서 수행한다는 뜻은 아니다.

현재 버전에서 알고 써야 하는 점

아직 0.3.0 Alpha다. 토론과 작업을 연결하는 기능은 구현했지만, 여러 에이전트를 붙였다는 이유만으로 정확도나 생산성 향상을 주장하고 싶지는 않다.

특히 결과를 볼 때 다음 구분은 유지하려고 한다.

CLI 시작 시간과 모델 응답 시간이 누적되므로 여러 단계의 토론은 한 번의 질문보다 오래 걸릴 수 있다. 네트워크, 로그인, 권한, 응답 형식 등의 문제로 보류될 수도 있다. 실행 중 재시작한 작업을 무조건 자동으로 다시 돌리는 방식은 사용하지 않는다.

또한 서버는 루프백 전용 로컬 도구다. 인터넷에 공개하는 다중 사용자 서비스로 설계하지 않았다. Windows 앱 창을 닫아도 서버는 유지되므로 실행 터미널에서 Ctrl+C로 종료한다. 작업 사본과 로그·결과물도 자동으로 정리하지 않아 사용하면서 저장 공간을 관리해야 한다.

현재의 가치는 같은 요청을 누가 어떻게 읽었고, 어떤 의견과 검토를 거쳐 어느 파일이 만들어졌는지를 더 쉽게 확인할 수 있다는 데 있다. 결과의 품질은 실제 작업과 검증을 통해 계속 확인해야 한다.

만들면서 계속 보고 싶은 것

Agent Hub에서 이어가고 싶은 흐름은 질문 → 독립 의견 → 쟁점 확인 → 동료 검토 → 구현 → 결과 확인 → 다음 요청이다.

사용자는 필요한 지점에서 조건을 정하고, 갈린 의견을 읽고, 만들어진 변경을 확인한다. Hub는 그 사이의 전달과 기록을 맡는다. 사무실 화면은 이 과정이 지금 어디쯤 와 있는지 조금 더 쉽게 볼 수 있도록 붙인 표현이다.

앞으로도 기능의 개수보다 이 흐름을 실제로 따라갈 수 있는지 보고 싶다. 보류 이유가 이해되는지, 검토한 결과를 다시 찾기 쉬운지, 다음 작업에 필요한 맥락이 남아 있는지가 중요하다. 직접 쓰면서 그 부분을 계속 다듬어 보려고 한다.

소스는 GitHub의 Agent Hub 저장소에 공개했다. MIT 라이선스이며 Coral·Claude·Codex·Cursor의 공식 제품은 아니다. 관심이 있다면 데모 화면부터 둘러볼 수 있다.

관련 글과 구현 문서

• 멀티 에이전트 통신 수단 비교
• 에이전트 완료 보고와 교차 검수
• MCP·ACP·Coral과 0-turn 에이전트 통신
• Agent Hub README
• 사용 가이드 · 토론 · 투표 · 역할 분담 작업