이제 더 많은 개발자들이 여러 AI 도구를 동시에 실행하고 있습니다. 코딩을 위한 Claude, 문서 작성을 위한 GPT, 데이터 분석을 위한 특화된 에이전트 등이 그것입니다. 각각의 도구는 자신의 역할을 수행하며 생산적으로 보입니다.

하지만 이러한 방식의 병렬 처리는 단순히 일손을 늘리는 것일 뿐, 진정한 협업은 아닙니다. 의존성이 있는 작업을 여러 에이전트가 처리하도록 시도하는 순간, 복잡성은 완전히 다른 차원으로 급증합니다.

누가 무엇을 보는가

에이전트들이 동시에 작동할 때 가장 먼저 떠오르는 질문은 '누가 무엇을 보는가'입니다. 두 에이전트가 제안서의 전반부와 후반부를 작성할 때, 서로의 진행 상황을 볼 필요가 있을까요, 아니면 서로 보지 못한 채 작업하고 사람이 결과물을 합치게 해야 할까요? 만약 서로 볼 수 없다면, 어떻게 스타일의 일관성을 유지하고 중복을 피할 수 있을까요? 만약 서로 볼 수 있다면, 에이전트 A가 B의 결과물을 읽고 다른 방향으로 끌려가는 간섭 현상은 어떻게 처리해야 할까요?

보편적인 정답은 없으며, 전적으로 작업의 성격에 달려 있습니다. 브레인스토밍 (Brainstorming)은 에이전트들이 서로의 아이디어를 보고 이를 바탕으로 발전시켜 나가는 과정이 필요하지만, 파이프라인 (Pipeline) 작업은 상류 (Upstream)의 출력물만 필요하며 그 외의 것은 노이즈일 뿐입니다. 필요한 것은 다양한 작업 모드에 맞춰 서로 다른 정보 토폴로지 (Information topologies)를 가진 설정 가능한 가시성 제어 (Visibility control)입니다. 대부분의 기존 프레임워크는 이러한 추상화 (Abstraction)를 구축하지 않았기 때문에, 개발자들은 프롬프트 (Prompt)를 통해 이를 임시방편으로 해결하고 있습니다.

단계 간 결과물 전달하기

작업이 여러 단계에 걸쳐 있을 때, 결과물을 전달하는 과정은 까다로워집니다. 에이전트 A가 코드를 작성하고, 에이전트 B가 이를 검토하며, B가 문제를 발견하여 A에게 다시 보내면, A가 이를 수정하여 B에게 재제출하고, B가 승인하여 C에게 문서화를 위해 전달하는 식입니다. 이러한 흐름에는 작업이 어느 단계에 있는지, 현재 버전은 누가 보유하고 있는지, 누가 입력을 기다리고 있는지를 추적하는 명확한 상태 머신 (State machine)이 필요합니다.

전통적인 워크플로 엔진 (Workflow engines)은 상태 변화가 느린, 즉 한 단계가 몇 시간 또는 며칠이 걸릴 수 있는 인간의 작업을 처리합니다. 에이전트는 훨씬 더 빠르게 실행되어 몇 분 만에 수십 단계를 수행하며, 상태 변화가 인간의 워크플로보다 훨씬 더 빈번하게 발생합니다. 또한 에이전트가 병렬로 작동할 때 경합 조건 (Race conditions)이 발생할 수 있습니다. 예를 들어, 두 에이전트가 동시에 동일한 문서를 편집하거나, 동일한 오래된 정보 (Stale information)를 바탕으로 결정을 내려 모순된 결과를 생성하는 경우입니다. 그리고 전통적인 워크플로에서는 모든 노드에 인간의 확인 절차가 있습니다. 만약 에이전트가 승인 확인 (Acceptance checks) 없이 결과물을 단순히 다운스트림 (Downstream)으로 전달하기만 한다면, 저품질의 출력이 흘러 들어가고 오류가 체인을 따라 증폭됩니다.

누락된 오케스트레이션 계층 (The Missing Orchestration Layer)

대부분의 멀티 에이전트 프레임워크 (Multi-agent frameworks)는 여러 에이전트를 시작하는 문제는 해결했지만, 이들이 어떻게 협력하게 만들지에 대해서는 해결하지 못했습니다. 여러 에이전트가 동시에 실행될 때, 이들은 공유 폴더, 메시지 큐 (Message queues), 또는 직접적인 대화를 통해 어떻게 조정할까요? 실제로 개발자들은 에이전트 간의 상호작용을 관리하기 위해 많은 글루 코드 (Glue code)를 작성하지만, 표준화된 것은 없으며 모든 코드를 새로운 시나리오마다 다시 작성해야 합니다. 디버깅은 훨씬 더 어렵습니다. 여러 에이전트가 예상치 못한 출력을 생성할 때, 각 에이전트의 내부 추론 (Internal reasoning)은 불투명하고 상호작용 로그가 사방에 흩어져 있기 때문에 어느 단계에서 잘못되었는지 정확히 찾아내기가 어렵습니다.

오케스트레이션 계층은 다양한 협업 모드를 정의해야 합니다. 에이전트들이 주제에 대해 토론하고 인간이 최종 결정을 내리는 방식은 라운드테이블 모드 (Roundtable mode)입니다. 한 에이전트가 작업을 수행하고 다음 에이전트에게 검토를 넘기며, 거절 시 재작업이 이루어지는 방식은 크리틱 모드 (Critic mode)입니다. 큰 작업을 병렬로 실행되는 하위 작업 (Subtasks)으로 나누고 나중에 병합하는 방식은 스플릿 모드 (Split mode)입니다. 각 모드는 서로 다른 정보 흐름, 권한 경계, 그리고 승인 메커니즘을 가집니다. 하나의 기본 동작만으로는 이 모든 것을 커버할 수 없습니다.

Octo는 프레임워크 수준에서 여섯 가지 오케스트레이션 (Orchestration) 모드를 제공합니다: Solo (독립 실행), Roundtable (그룹 토론), Critic (검토 워크플로우), Pipeline (순차적 인계), Split (작업 분할), 그리고 Swarm (집단 지성). 각 모드는 고유한 가시성 규칙과 상태 전이 (State transition) 메커니즘을 가집니다. 개발자는 모든 시나리오에 대해 협업 로직을 하드코딩하는 대신, 작업에 적합한 모드를 선택하기만 하면 됩니다. 이를 통해 오케스트레이션은 단순한 글루 코드 (Glue code)에서 설정 가능한 인프라로 변모합니다.

정체성 및 권한 경계 (Identity and Permission Boundaries)

각 에이전트는 명확한 정체성 (Identity) 및 역량 경계를 가져야 합니다. 코드 리뷰를 위해 구성된 에이전트가 제품 요구사항을 수정해서는 안 되며, 데이터 분석 에이전트가 운영 데이터베이스 (Production database)에 접근할 권한을 가져서도 안 됩니다. 멀티 에이전트 환경에서의 권한 관리는 전통적인 IAM (Identity and Access Management)보다 훨씬 더 복잡합니다. 전통적인 시스템은 명확한 역할-권한 매핑을 가진 비교적 정적인 사용자 정체성을 가집니다. 반면 에이전트의 정체성은 작업 컨텍스트 (Task context)에 따라 변할 수 있습니다. 동일한 에이전트가 프로젝트 A에서는 실행자 (Executor) 역할을 하고, 프로젝트 B에서는 검토자 (Reviewer) 역할을 수행할 수 있으며, 권한은 시나리오를 따라가야 합니다.

에이전트가 팀원의 대리인으로서 행동할 때, 해당 인원의 권한 범위를 상속받아야 할까요, 아니면 독립적인 권한 모델을 가져야 할까요? 아직 업계의 합의된 결론은 없지만, 반드시 해결해야 할 과제입니다. Octo의 접근 방식은 에이전트를 제작자의 디지털 워크포스 (Digital workforce) 확장판으로 취급합니다. 에이전트는 권한을 상속받고 작업 완수를 위한 취향(Taste preferences)을 반영하며, 정체성과 역량 경계는 AgentCard를 통해 명확하게 표시됩니다.

직접 시도해보기 (Try It Out)

몇 개의 에이전트를 구동하는 것은 쉽습니다. 하지만 이들이 신뢰할 수 있게 협력하고 추적 가능한 결과를 생성하도록 만드는 데에는 많은 인프라가 필요합니다. 정보 흐름, 권한, 상태 관리, 수락 검사 (Acceptance checks), 추적 가능성 (Traceability) 등 각 차원마다 세심한 설계가 필요합니다.

Octo는 이제 GitHub에서 서버, 웹/데스크톱 클라이언트, iOS, Android 및 CLI 코드베이스를 포함하여 Apache 2.0 라이선스 하에 완전히 오픈 소스로 공개되었습니다. 만약 멀티 에이전트 협업 (multi-agent collaboration)을 위한 엔지니어링 경로를 탐색하고 있다면, 코드를 가져와 직접 시도해 보세요. 배포 문서(Deployment docs)는 octo-deployment 리포지토리에 있으며, 바로 사용할 수 있는 K8s 배포 매니페스트 (K8s deployment manifests)가 준비되어 있습니다. 커뮤니티는 이제 막 시작 단계입니다. 만약 이 방향이 가치 있다고 생각된다면, 스타 (star)를 눌러주세요. 여러분의 초기 피드백은 제품이 나아갈 방향을 직접적으로 결정할 것입니다.