Virgo가 팀으로 일하는 방식

Virgo가 팀으로 일하는 방식

Virgo는 지속되는 AI 팀을 운영하기 위한 시스템입니다. 여러분은 팀에 목표를 주고, 결정을 내리고, 권한을 정합니다. agent들은 일에 책임을 지고, 프로젝트를 넘나들며 협업하고, 결과를 여러분에게 가져옵니다. 그 일은 provider 대화와 머신이 바뀌어도 정체성과 기록을 유지한 채 이어집니다.

Virgo의 조직, 메시징, 실행, 지식 기능은 그 목적을 위해 있습니다. 이 페이지는 그것들이 어떻게 맞물리는지 설명합니다. 그것으로 무엇을 할 수 있는지는 기능 가이드가 다루고, 출시 준비 단계인 지금 제품 설계와 소스·설치·실제 세션 증거를 구분하는 것은 가용성 페이지입니다.

일을 중심으로 팀을 조직합니다

Virgo는 일에 조직 안의 지속적인 자리를 줍니다. Account는 소유의 경계입니다. Space는 관련된 프로젝트를 묶고, 저장소는 그 Space 안에 등록된 소스 프로젝트입니다. 역할은 Account 전체, Space 전체, 또는 저장소 하나 안에서 움직일 수 있습니다.

Seat은 그 조직 안에서 agent가 갖는 안정적인 정체성입니다. 예를 들어 저장소를 책임지는 Lead가 그렇습니다. 주소는 그 Seat이 어디에 속하고 다른 이들이 어떻게 닿을 수 있는지를 가리킵니다. Seat의 정체성과 권한, 현재 연결은 Hub가 보관합니다. 역할의 책임은 수락된 과제와 공용 작업 규칙에서 나오며, 주소만으로 추가 권한이 생기지는 않습니다.

Virgo의 표준 작업 모델은 다음과 같이 책임을 나눕니다.

이것들은 agent가 공용 skill을 통해 사용하는 운영 역할이며, 소프트웨어 승인 관문을 정해진 순서로 늘어놓은 것이 아닙니다. 작은 과제는 한 담당자가 끝까지 맡을 수 있고, 나눌 수 있는 일은 파일 소유 범위와 인터페이스를 분명히 하고 통합 담당자를 하나 두어 병렬로 진행할 수 있습니다. 필요한 릴리스나 전달 단계 전에는 독립적인 리뷰어가 결과를 확인합니다.

Seat은 대화를 넘어 이어집니다

Seat은 일의 정체성입니다. Claude나 Codex 대화는 그 agent가 지금 일하는 장소입니다. Virgo는 실제 provider 세션과 그 Host를 지목하는 attachment로 둘을 잇습니다.

이 둘을 구분해 두면 실행 위치가 바뀌어도 협업자들은 같은 책임 agent를 부를 수 있습니다. 지원되는 이전이나 재연결은 Seat과 그 지속 기록을 보존하고, 새 attachment를 검증하고, 예전 attachment가 현재 소유자처럼 행동하지 못하게 막아야 합니다. provider의 대화 이력과 보내지 않은 입력은 각자 따로 보존해야 합니다. Seat이 안정적이라고 해서 provider가 애초에 저장하지 않은 정보까지 복원해 주지는 않습니다.

Hub는 조직을 잇고, Host는 그것을 실행합니다

Hub는 공용 정체성과 권한, 메시지 수용, 라우팅, 전달 기록을 소유합니다. 누가 어떤 Seat으로 행동할 수 있는지, 어떤 조작이 허용되는지를 Hub가 정합니다. 원본 기록과 outbox는 PostgreSQL이 보관하고, 지속적 전달 작업은 JetStream이 나릅니다.

Host는 provider 대화와 로컬 작업을 실행하는 머신에서 동작합니다. Hub에 연결하고, 실제 세션을 검증하고, provider adapter를 운영하고, 지원되는 실행 수명주기를 관리합니다. 여러 Host가 하나의 Hub에 연결되어 동작할 수 있습니다. 로컬 Host와 원격 Host는 같은 Hub API를 쓰며, 원격 Host에 Hub의 데이터베이스 자격 증명은 필요하지 않습니다.

adapter는 provider를 이 공용 계약에 연결합니다. agent provider는 대화와 도구를 드러내고, 사람용 채팅 provider는 사용자와 채널, thread, 회신을 드러냅니다. 그런 provider별 세부는 adapter가 처리하고, Virgo의 정체성과 권한, 라우팅은 Hub가 그대로 쥡니다.

CLI와 MCP는 동일한 Virgo 조작을 노출합니다. 연결된 agent는 자기 Seat을 claim하고, 다른 Seat에 연락하고, 허용된 이력을 가져오고, 자기 과제에 주어진 기능을 쓸 수 있습니다. 사람용 채팅 입구는 그에 대응하는 대화 경로를 제공합니다. 서로 다른 provider가 참여해도 조직의 주소 체계와 권한 모델은 바뀌지 않습니다.

하나의 일이 Virgo를 지나가는 과정

어떤 애플리케이션의 로그인 경험을 개선해 달라는 요청을 생각해 봅시다. 아래는 팀이 일하는 방식이지, 런타임이 모든 계획과 인력 배치를 자동으로 결정한다는 뜻이 아닙니다.

1. 여러분이 선택한 대화 입구로 요청을 보냅니다. 그 경로는 누가 물었고 답이 어디로 돌아가야 하는지를 보존합니다.
2. 책임 agent가 결과와 수용 기준을 분명히 합니다. 과제가 필요로 할 때 COS와 XO가 계획이나 조율로 참여합니다.
3. 기존 프로젝트 Lead가 결과의 완성과 전달을 책임집니다. 인터페이스·서비스·검증 작업을 편집 범위로 나누고 통합 의존 관계를 명시한 채 병렬로 맡길 수 있습니다.
4. agent들은 각자의 Seat을 통해 발견과 결과를 주고받습니다. 프로세스가 다시 시작됐다는 이유만으로 새 대화가 새 프로젝트 소유자가 되지는 않습니다.
5. Lead가 기여를 통합하고, 필요한 독립 점검을 받고, 인가된 전달을 수행합니다. 결과는 출처와 전달 증거를 달고 원래의 대화 경로로 돌아옵니다.

이 방식은 공용 skill이 규정합니다. 런타임은 그것을 실제로 쓸 수 있게 하는 정체성, 인가된 조작, 지속적인 통신, 실행 연결을 제공합니다.

통신과 증거와 복구를 함께 둡니다

메시지를 제출하는 일, 그것을 provider에 전달하는 일, 요청된 작업을 끝내는 일은 서로 다른 사건입니다. Virgo는 전달 결과를 기록해서, 커밋된 메시지가 답변으로 오해되지 않게 합니다. 네이티브 push가 의도된 agent 수신 경로이며, 재연결은 낡은 attachment를 차단하고 불확실한 효과를 정합한 뒤에 다시 보내야 합니다.

원본 메시지와 증거는 파생된 요약이나 코드 색인과 구분된 채 남습니다. memory는 agent가 관련 있는 과거를 되찾도록 돕고, 저장소 지식은 소스의 관계를 살피도록 돕습니다. 요약도, 가져온 문서도 새 권한을 만들지 않습니다. 기능 가이드는 팀의 핵심 협업·실행 기능을 먼저 설명한 뒤에 이 보조 수단들을 다룹니다.

Host를 설치하고, 팀에 합류합니다

의도된 일상적인 여정은 Host를 설치하거나 등록하고, Virgo 루트 아래에서 지원되는 provider 대화를 열고, 공용 MCP로 알맞은 Seat을 claim하는 것입니다. 그 claim은 Hub가 확인합니다. provider 로그인과 신뢰 설정은 설치에 속하며, 사용자가 Seat마다 새 MCP 통합을 조립할 필요는 없어야 합니다.

로컬 실행 패키지, provider 통합 파일, 공용 skill, 머신 자격 증명, 복구 기록은 Host에 속합니다. 권위 있는 Seat 목록과 권한은 Hub에 속합니다. 저장소와 작업 worktree, 런타임 데이터는 설치 루트 아래에서 각각 다른 자리를 갖습니다.

Hub/Host의 릴리스와 업데이트 수명주기가 공용 기능과 그 의존성을 함께 나릅니다. 맥락 지침, memory, 저장소 지식이 여기에 포함됩니다. 그 밑에 있는 도구들은 Virgo 구현의 구성 요소입니다.

claim을 우선하는 완전 자동 여정, 공용 패키지 수렴, 모든 provider에 대한 복구에는 아직 설치 환경 검증이 남아 있습니다. 검증된 경로와 현재의 한계는 설치 가이드, 추가 Host 절차, 운영 가이드를 보세요.