AI 에이전트들이 협업하기 시작할 때: 아무도 말하지 않는 세 가지 과제

지난 2년 동안 AI 에이전트의 궤적은 매우 명확했습니다. 단일 목적의 도구에서 개인 비서로 진화해 왔습니다. 누구나 자신만의 에이전트를 실행하고, 작업을 입력하며, 결과를 돌려받습니다. 이는 개인의 생산성 측면에서는 잘 작동합니다.

그러면 모든 팀이 결국 던지게 되는 질문이 생깁니다. 이 에이전트들이 서로 협업할 수 있을까?

답은 '예'입니다. 하지만 그 과정에서 마주치는 문제들은 여러분이 예상했던 것과는 거의 다릅니다. 그것은 모델의 능력(model capabilities)이나 프롬프트 엔지니어링 (prompt engineering)에 관한 것이 아닙니다. 그것은 통신(communication), 문맥(context), 그리고 조정(coordination)에 관한 문제입니다. 이는 분산 시스템 (distributed systems) 엔지니어들이 수십 년 동안 해결해 온 것과 동일한 범주의 문제들이며, 이제 새로운 형태로 나타나고 있습니다.

다음은 AI 에이전트와 인간이 동일한 통신 공간을 공유하는 오픈 소스 워크플레이스 플랫폼인 Octo에 에이전트 협업 기능을 구축하기 시작했을 때 저희를 당혹스럽게 했던 세 가지 과제입니다.

과제 1: 문맥 가시성 경계 (Context Visibility Boundaries)

에이전트를 개인적으로 사용할 때는 문맥 관리 (context management)가 간단합니다. 에이전트가 어떤 정보를 볼지 직접 결정하며, 그 출력값은 사용자에게 돌아옵니다. 경계가 명확합니다. 단지 사용자의 작업 공간일 뿐이니까요.

하지만 팀 환경에서는 그 경계가 해체됩니다.

저희가 처음 맞닥뜨린 문제 중 하나는 놀라울 정도로 단순했습니다. 여러 채널에 걸친 논의를 요약하는 에이전트를 운영하고 있었습니다. 테스트 도중, 이 에이전트가 제품(product) 채널의 로드맵 논의 내용을 엔지니어링 계획 스레드로 가져오기 시작했습니다. 민감한 정보가 외부로 유출된 것은 아니었지만, 우리의 문맥 경계가 얼마나 불분명한지를 즉각적으로 드러냈습니다.

전통적인 소프트웨어는 API 게이트웨이 (API gateways), 데이터 권한 (data permissions), 그리고 마이크로서비스 경계 (microservice boundaries)를 통해 이를 처리합니다. 하지만 에이전트의 문맥은 단순히 구조화된 데이터가 아닙니다. 여기에는 대화 기록 (conversation history), 추론 체인 (reasoning chains), 그리고 중간 상태 (intermediate states)가 포함됩니다. 작업 수행 중 에이전트의 사고 과정은 가치 있는 문맥이지만, 팀의 경계를 넘어서는 안 되는 정보를 포함하고 있을 수도 있습니다.

필요한 것은 세밀한 문맥 가시성 제어 (fine-grained context visibility control)입니다. "모두에게 공개"하거나 "모두에게 차단"하는 것이 아니라, 당면한 작업, 역할 및 시나리오에 따라 어떤 문맥을 공유할 수 있는지 결정하는 동적인 규칙이 필요합니다.

이 지점에서 인스턴트 메시징 (instant messaging) 아키텍처가 놀라울 정도로 유용하다는 사실이 드러납니다. 채널 (channels)은 자연스러운 문맥 경계 역할을 합니다. 멤버들은 자신이 속한 채널의 메시지만 볼 수 있습니다. 에이전트가 채널에 참여하면 자연스럽게 해당 경계를 상속받습니다. 에이전트는 문맥으로서 채널의 메시지 기록에 접근할 수 있지만, 다른 채널은 볼 수 없습니다. 이는 문맥 관리 시스템을 처음부터 구축하는 것보다 더 성숙한 방식이며, 팀이 이미 업무를 조직하는 방식과 깔끔하게 매칭됩니다.

과제 2: 권한의 교차 및 충돌 (Permission Intersections and Conflicts)

개인 에이전트의 권한은 간단합니다. 사용자가 허가하는 것은 무엇이든 에이전트가 수행할 수 있습니다.

팀 문맥에서는 권한이 다대다 (many-to-many) 관계가 됩니다. 단일 에이전트가 여러 사람을 보조하고, 여러 프로젝트에 참여하며, 서로 다른 채널에서 다양한 역할을 수행할 수 있습니다. 각 차원은 고유한 권한 요구 사항을 가지며, 이들은 서로 충돌할 수 있습니다.

구체적인 예시는 다음과 같습니다. 코드 리뷰 에이전트가 두 개의 프로젝트 채널에 참여하고 있습니다. 프로젝트 A의 코드베이스는 팀 B에게 보이지 않지만, 에이전트는 두 프로젝트를 모두 지원하는 동안 두 코드베이스 모두에 접근할 수 있습니다. 만약 에이전트가 프로젝트 B의 코드를 리뷰하는 동안 프로젝트 A의 구현 패턴을 참조한다면, 이를 정보 유출이라고 볼 수 있을까요?

상황은 인간-에이전트 협업 (human-agent collaboration)에서 더욱 복잡해집니다. 인간과 에이전트가 동일한 채널에서 작업할 때, 인간은 에이전트의 모든 출력을 볼 수 있습니다. 하지만 에이전트의 출력은 에이전트가 접근할 수 있는 다른 문맥의 정보를 활용할 수 있습니다. 에이전트가 응답을 생성할 때 현재 채널에서 보이는 정보만을 사용하도록 어떻게 보장할 수 있을까요?

분산 시스템(Distributed systems)은 권한 설계(permission design)를 위한 성숙한 솔루션인 RBAC (role-based access control, 역할 기반 액세스 제어), ABAC (attribute-based access control, 속성 기반 액세스 제어) 및 그 변형들을 이미 갖추고 있습니다. 에이전트 시스템은 이러한 접근 방식들을 차용할 수 있지만, 에이전트 특유의 특성에 맞게 조정할 필요가 있습니다. 에이전트는 단순히 명령을 수동적으로 실행하는 것이 아니라, 추론(reasoning)하고, 콘텐츠를 생성하며, 주도적인 결정을 내립니다. 따라서 권한 제어는 단순히 입력(input)과 출력(output)뿐만 아니라 생성 과정 자체를 포괄해야 합니다.

Octo에서는 각 채널이 자체적인 ACL (access control list, 액세스 제어 목록)을 갖는 조직 인식형 RBAC 모델을 채택했습니다. 에이전트의 신원(identity)과 권한은 인간 구성원과 함께 관리됩니다. 채널 내의 모든 에이전트 입력과 출력은 감사(auditable)가 가능하며, 권한 경계는 인스턴턴트 메시징(IM) 시스템이 수십 년간 정교화해 온 채널 메커니즘을 통해 자연스럽게 표현됩니다.

과제 3: 집단적 경험의 축적 및 재사용

개인용 에이전트는 과거의 상호작용으로부터 학습하여 사용자의 선호도와 작업 패턴을 점진적으로 이해할 수 있습니다. 이러한 학습은 개별적입니다. 즉, 경험이 단일 에이전트의 문맥(context)에 축적됩니다.

팀 환경에서는 경험의 차원이 달라집니다. 이제는 단순히 개별 에이전트의 경험에 관한 것이 아니라, 멀티 에이전트 협업(multi-agent collaboration)을 통해 생성되는 집단적 경험에 관한 것입니다. 즉, 어떤 협업 패턴이 효율적인지, 어떤 작업 분해(task decomposition) 방식이 문제를 일으키는 경향이 있는지, 인간의 개입이 어디에서 가장 빈번하게 발생하는지 등이 포함됩니다. 만약 이러한 정보를 포착하고 재사용할 수 있다면, 팀의 전반적인 협업 효율성을 의미 있게 향상시킬 수 있을 것입니다.

하지만 집단적 경험은 몇 가지 과제에 직면해 있습니다.

첫째, 소유권(ownership) 문제입니다. 한 에이전트가 협업 작업 중에 무언가를 학습했을 때, 다른 에이전트들도 이에 접근할 수 있어야 할까요? 만약 그렇다면, 에이전트가 다른 사람의 경험을 자신의 시나리오에 잘못 적용하는 '문맥 오염 (context pollution)'이 발생할 수 있지 않을까요?

둘째, 적시성 (timeliness) 문제가 있습니다. 팀 협업 패턴은 프로젝트 단계, 팀 구조, 비즈니스 목표에 따라 변화합니다. 3개월 전에 유효했던 패턴이 지금은 무의미할 수도 있습니다. 캡처된 경험에는 업데이트 및 폐기 (deprecation) 메커니즘이 필요합니다.

다음으로는 간과하기 쉬운 품질 평가 (quality assessment)가 있습니다. 모든 과거의 상호작용이 가치 있는 경험을 산출하는 것은 아닙니다. 어떤 것은 특수한 사례일 수 있고, 다른 것들은 결함이 있는 판단을 포함하고 있을 수도 있습니다. 품질을 유지하면서 경험을 캡처하려면 평가 프레임워크 (evaluation framework)가 필요합니다.

IM (Instant Messaging) 시스템의 메시지 기록, 그룹 문서, 고정된 메시지(pinned messages)는 경험 캡처를 위해 설계된 것은 아니지만, 실제로는 이 역할을 수행할 수 있습니다. 핵심적인 대화 결론은 고정할 수 있고, 중요한 의사결정 과정은 그룹 문서로 아카이브 (archive)할 수 있으며, 에이전트는 작업을 수행할 때 이러한 구조화된 산출물 (artifacts)을 참조용으로 검색할 수 있습니다. 이 방식은 벡터 데이터베이스 (vector databases)나 지식 그래프 (knowledge graphs)보다 가벼우며, 인간과 에이전트가 함께 이해하고 유지 관리하기에도 더 쉽습니다.

왜 여기서 IM 아키텍처가 중요한가

문맥 가시성 (context visibility), 권한 교차 (permission intersections), 집단적 경험 (collective experience)이라는 이 세 가지 과제는 모두 하나의 더 깊은 통찰을 가리킵니다. 즉, 에이전트 협업은 단순히 여러 에이전트를 연결하는 것만이 아니라는 점입니다. 이는 완전한 협업 인프라 (collaboration infrastructure)를 필요로 합니다.

해당 인프라는 통신, 문맥, 권한, 상태 동기화 (state synchronization), 그리고 경험 축적을 처리해야 합니다. 이러한 문제들은 전통적인 소프트웨어 엔지니어링에서 성숙한 솔루션들을 가지고 있지만, 자율적 추론 (autonomous reasoning), 콘텐츠 생성, 그리고 주도적인 의사결정 (proactive decision-making)을 수행하는 에이전트 시스템은 그 복잡성을 한 단계 더 높입니다.

IM (Instant Messaging) 아키텍처는 이러한 시나리오에 놀라울 정도로 적합한 모습을 보여줍니다. 수십 년 동안 IM 시스템은 다자간 실시간 통신 (multi-party real-time communication), 컨텍스트 관리 (context management), 권한 제어 (permission control), 그리고 상태 동기화 (state synchronization) 문제를 해결하며 성숙한 아키텍처 패턴과 엔지니어링 관행을 축적해 왔습니다. 이러한 기능들을 에이전트 협업 (agent collaboration)으로 이전하는 것은 처음부터 새로운 시스템을 구축하는 것보다 더 신뢰할 수 있는 방법입니다.

이러한 관찰을 바탕으로 우리는 IM 기반 위에 Octo를 구축했습니다. 에이전트들이 채널에 직접 참여하며, 동일한 대화 인터페이스 내에서 인간과 협업합니다. 이 프로젝트는 Apache 2.0 라이선스를 사용하며, Mininglamp-OSS GitHub 조직 산하에 9개의 핵심 리포지토리 (repositories)를 보유하고 있습니다. 또한 Go 백엔드, WuKongIM, MySQL, Redis, 그리고 MinIO 스택 위에서 실행됩니다. 모든 데이터를 귀하의 자체 서버에 보관하는 100% 프라이빗 배포 (private deployment)를 지원합니다.

더 큰 그림 (The Bigger Picture)

AI 에이전트를 개인용 도구에서 팀 인프라 (team infrastructure)로 이동시키는 것은 에이전트가 할 수 있는 일을 확장하지만, 동시에 도전 과제의 성격 또한 변화시킵니다. 더 나은 모델만으로는 통신, 컨텍스트, 그리고 조정 (coordination) 문제를 해결할 수 없습니다. 이러한 문제들은 성숙한 협업 인프라를 필요로 합니다.

개인 비서에서 팀 협업자로의 전환은 AI 에이전트 분야에서 다음으로 중요한 전환점이 될 수 있습니다. 이러한 전환이 일어날 때, 단순히 더 많은 에이전트를 쌓아 올리는 대신 이러한 아키텍처적 과제들을 조기에 고민하는 팀들이 실제로 실무에서 작동하는 시스템을 구축하게 될 것입니다.

만약 여러분이 멀티 에이전트 시스템 (multi-agent systems)을 연구 중이거나 에이전트 협업 인프라에 관심이 있다면, 여러분이 직면한 도전 과제들에 대해 듣고 싶습니다. Octo 프로젝트는 오픈 소스이며, GitHub에서의 기여와 토론을 환영합니다.