저는 반년 동안 저만의 Claude Tag 버전을 구축해 왔으며, 현재 여러 팀이 이를 매일 사용하고 있습니다. 제가 배운 점들을 공유합니다.

Anthropic은 팀이 Slack에서 Claude와 협업할 수 있는 새로운 방식인 Claude Tag를 막 출시했습니다.

발표된 장점 목록의 첫 번째 항목은 다음과 같습니다:

@claude는 멀티플레이어(multiplayer)입니다. 주어진 Slack 채널 내에서, 모든 사람과 상호작용하는 하나의 Claude가 존재합니다.

저희는 반년 전 Corgi에서 자체적인 버전을 개발했으며, 그 이후로 매일 이를 사용하고 반복 개선(iteration)해 왔습니다.

저희의 일부 고객, 친구, 가족들은 이미 몇 달 동안 그들의 회사 내부에서 멀티플레이어 AI 팀원으로서 이를 사용해 왔으며, 저희는 그들의 피드백과 필요에 따라 기능을 개선해 왔습니다.

제가 이 일을 한 지 꽤 되었고, 시행착오를 통해 몇 가지를 배웠기에, 문제점, 사용 사례(use cases) 및 기술에 대한 제 생각을 공유하고자 합니다.

파트 1: 이유.

Corgi에서 저희는 기업들이 AI 도입을 가속화할 수 있도록 돕고 있습니다.

"미래는 이미 여기에 와 있다. 단지 균등하게 분포되어 있지 않을 뿐이다." — William Gibson

저희는 AI 네이티브(AI-native) 스타트업들조차 미래가 균등하게 분포되어 있지 않다는 점을 발견했습니다. 일반적으로 기술 창업자(technical founder)와 기술진은 뼛속까지 AI에 몰입(AI-pilled)되어, 루프(loops)를 오케스트레이션하고 Claude를 통해 업무 생활 전체를 운영하는 반면, 마케팅, 영업, 운영, 재무 등의 다른 팀들은 여전히 AI를 더 나은 검색 엔진이나 대필 작가(ghostwriter) 사이의 무언가로 사용하며 뒤처져 있는 경우가 많습니다.

회사 전체의 역량을 끌어올려야 할 동기는 명확합니다. AI를 활용하는 팀들이 더 많은 업무를 더 빠르게 처리하고 있기 때문입니다.

이러한 기업들은 종종 전담 enablement (역량 강화) 워크숍을 통해 AI 도입 격차를 줄이려 시도합니다. 이는 괜찮은 방법이지만, 본질적으로는 일회성 노력에 불과합니다. 운이 좋다면 사람들에게 영감을 주고 멘탈 모델 (mental models)과 도구들을 더 잘 갖추게 해줄 수는 있겠지만, 오래된 습관은 쉽게 바뀌지 않습니다. 기업의 DNA에 AI-native (AI 네이티브) 문화와 워크플로 (workflows)를 심기 위해서는, 회사의 업무 방식에 매우 정통한 누군가로부터 지속적이고 의도적인 hands-on (실무 중심) 협업이 필요합니다.

다시 말해, 이 기업들에게 필요한 것은 과외 (tutoring)가 아니라 도제 제도 (apprenticeship)입니다.

하지만 스타트업은 매우 혹독합니다. 집중력과 시간은 가장 희소한 자원입니다. 도제 제도는 이 두 가지를 모두 소모하며, 이것이 일부 창업자들이 주니어 개발자를 명시적으로 채용하지 않는 이유입니다. 하지만 지금은 AI에 있어서 거의 모든 사람이 주니어입니다. 90년대에 웹에 관해서 거의 모든 사람이 주니어였던 것과 마찬가지입니다. 세상에 AI 전문가가 아직 충분하지 않고, 기술과 그 응용 분야가 빠르게 움직이고 있기 때문에 단순히 전문가만을 독점적으로 채용할 수는 없습니다.

각 개인이 자신만의 에이전트 (agent)를 사용할 때는 지식 공유가 내장되어 있지 않습니다. 노력이 필요하죠. 그렇다면 여러 사람이 동일한 에이전트와 대화한다면 어떨까요?

Shopify는 이를 이해했습니다. 그들은 River를 만들었습니다:

"한 가지 제약 사항: River는 공개된 상태에서만 작동합니다. 다이렉트 메시지(DM)는 없습니다." — River에 관한 Shopify Engineering의 블로그 포스트에 따르면, 대화는 기본적으로 모든 직원에게 공개됩니다.

AI 기술을 갖춘 직원들이 공개된 환경에서 에이전트와 상호작용하게 하면, 지식 전수(knowledge transfer)를 공짜로 얻을 수 있습니다. 다른 사람들이 보고 배울 수 있기 때문입니다. 하지만 도제 제도의 근본적인 측면은 _hands-on (실무 중심) 참여_이므로, 단순히 수동적으로 지켜보는 것이 아니라 사람들이 능동적으로 상호작용할 수 있도록 해야 합니다.

"제 채널에는 스레드에 반응하고, 색채와 맥락을 더하며, 바통을 이어받고, 리뷰를 돕고, 제가 얼마나 녹슬었는지 상기시켜 주며, 무엇보다 지켜보는 것만으로 배우는 사람들이 100명 넘게 있습니다." — Tobi Lütke (Shopify CEO) X에서

따라서 하나의 에이전트와 여러 사람이 함께하는 방식은 이를 공동으로 사용하는 사람들 사이의 지식 공유 문제를 해결합니다.

하지만 에이전트 간(agent-to-agent)의 관계는 어떨까요? 싱글 플레이어 에이전트(Single-player agents)는 기본적으로 다른 에이전트와 맥락(context)을 공유하지 않습니다. 각 에이전트는 동일한 사항을 반복해서 파악하며, 팀 내의 다른 누군가가 이미 해결한 문제에 대해 불필요하게 시간과 토큰(tokens)을 소모합니다. 적절한 맥락이 손에 닿지 않는 곳에 있는 것입니다.

이 문제는 실제 git 리포지토리(repo), obsidian, LLM-wiki 또는 전용 Notion 팀스페이스와 같은 내부 맥락 저장소(internal context repositories)를 통해 부분적으로 해결되지만, 이러한 방식은 생성자와 소비자 모두가 정보를 밀어넣고(push) 가져오는(pull) 데 의도적인 노력을 기울여야 합니다.

또 다른 가능한 해결책은 에이전트들이 서로 직접 통신하게 하는 것이지만, 이는 추가적인 지연 시간(latency)과 토큰 비용을 발생시킵니다. 무엇이 필요한지 파악하고, 적절한 맥락을 찾아 요청자에게 전달하기까지 여러 번의 에이전트 턴(agent turns)이 필요하기 때문입니다.

하지만 멀티플레이어 에이전트(multiplayer agents)를 사용하면, 공유된 팀 맥락이 시간이 지남에 따라 한 곳에 자연스럽게 축적됩니다. 누가 무엇을 소유하고 있는지, 누가 승인하는지, 기록 시스템(systems of record)이 어디에 있고 내부적으로 어떻게 구조화되어 있는지, 그리고 이 모든 것이 "이곳에서 업무가 수행되는 방식"이라는 큰 그림 속에서 어떻게 하나로 합쳐지는지 같은 정보들이 말이죠.

단순하게 말하자면, 싱글 플레이어 에이전트는 다른 에이전트 및 인간과의 맥락 공유에 있어 본질적인 비용이 발생합니다. 반면 멀티플레이어 에이전트는 이를 무료로 얻습니다.

따라서 가속화된 AI 도입의 필요성은 멀티플레이어 에이전트에 의해 더 잘 충족됩니다. 그렇다면 단순히 이득을 보는 수준을 넘어, 멀티플레이어 에이전트를 반드시 필요로 하는 다른 요구사항에는 무엇이 있을까요?

우리의 논지는 그렇다, 즉 그러한 요구사항들이 존재하며, 그 핵심 이유는 바로 **조정 (Coordination)**에 있다는 것입니다. 조직은 협업을 필요로 합니다. 조직은 여러 엔티티(사람, 소프트웨어, 그리고 이제는 에이전트) 사이에서 정보를 전달하고 의사결정을 내리는 시스템입니다.

구체적인 사례를 살펴보면, 팀 간의 인수인계 (hand-offs)를 생각해 볼 수 있습니다. 마케팅 팀의 리드 (lead)는 영업 팀의 잠재 고객 (prospect)이 되고, 고객 성공 (CS) 팀이 육성해야 할 고객 계정 (account)이 되며, 다시 제품 및 R&D 팀으로 피드백되어 R&D에서 제품으로, 다시 영업 및 마케팅으로 전달되는 결과물을 생성하고, 이는 다시 외부 세계와 소통해야 합니다. 기업 내부의 고객 생애 주기 (customer lifecycle)는 조정과 동기화 (synchronization)의 문제입니다.

우리는 회사를 그래프 (graph)로 모델링할 수 있습니다. 인간은 노드 (nodes)이고, 정보의 흐름은 엣지 (edges)입니다. 싱글 플레이어 에이전트 (Single-player agents)는 단일 인간 노드에 연결된 리프 노드 (leaf nodes)입니다. 인간은 다른 많은 노드와 연결된 허브 (hubs)입니다.

새로운 직원이 채용될 때마다 그와 함께 일하는 모든 사람에게 엣지가 추가되므로, 엣지는 노드보다 더 빠르게 증가합니다. 정보의 흐름은 그래프 순회 (graph traversal)입니다. 이는 정보가 더 긴 경로를 통해 이동해야 하므로, 회사가 성장함에 따라 조정 비용도 함께 증가함을 의미합니다.

성장하는 조직의 복잡성을 관리하는 데 따르는 고통은 잘 알려져 있습니다. 정보가 회사의 조직도 (org chart)를 가로질러 이동해야 할 때, 다음과 같은 여러 가지 방식으로 실패할 수 있으며 각각 나쁜 결과를 초래합니다.

• 누락 (Dropped, 엣지 유실): 반복되는 질문, 중복된 작업.
• 지연 (Slow, 정체되거나 긴 경로): 인수인계 차단, 프로젝트 일정 지연.
• 손실 (Lossy, 긴 경로로 인해 각 홉 (hop)마다 세부 사항이 탈락): 오해, 낭비되는 반복 작업.
• 오경로 (Misrouted, 명확한 담당자가 없거나 잘못된 담당자): 최적화되지 않은 의사결정, 데이터 유출, 중요한 사항의 간과.

영업(Sales) 및 마케팅(Marketing) 팀이 #product-questions 채널에서 똑같은 질문을 반복해서 던지고(dropped edge, 누락된 연결), 제품 팀의 가용성 문제로 인해 진행이 막히며(slow path, 느린 경로), 제품 팀 또한 R&D 팀의 답변을 기다리느라 막혀 있는 상황을 상상해 보십시오. 이 과정에서 제품 팀은 R&D의 답변을 오해할 수 있으며(lossy path, 손실 경로), 결과적으로 원래 질문을 했던 고객에게 잘못된 답변을 전달하게 됩니다.

모두가 자신의 직업 생활에서 이와 유사한 경험을 해본 적이 있을 것입니다. 대부분의 사람들은 이를 "비즈니스를 수행하는 데 따르는 비용"으로 치부합니다. 하지만 반드시 그래야만 할까요? 우리가 더 잘할 수는 없을까요?

"Block에서 우리는 조직이 반드시 인간을 조정 메커니즘(coordination mechanism)으로 하는 계층적 구조로 조직되어야 한다는 가설에 의문을 제기하고 있습니다. 대신, 우리는 계층 구조가 수행하는 역할을 대체하고자 합니다." — Jack Dorsey (Block CEO), "From Hierarchy to Intelligence"에서

싱글 플레이어 에이전트(Single-player agents)는 자신이 연결된 인간 노드(human node)의 처리량(throughput)을 크게 증폭시킵니다. 이들은 다른 노드에 정보를 전달할 수는 있지만, 다른 이들이 직접 연결할 수 있는 허브(hub)가 될 수는 없습니다.

만약 에이전트가 그렇게 할 수 있다면, 완전히 **새로운 범주(new class)**의 유스케이스(use case)가 가능해집니다. 바로 대규모의 복잡한 기업을 조정(coordination)하는 것입니다. 계층 구조는 줄어들고, 노드 간의 처리량은 높아지며, 결과물의 전달 속도는 빨라집니다.

그렇다면 왜 에이전트는 멀티플레이어(multiplayer)가 될 수 없는 걸까요? 더 정확히 말하면, 안전하게 그렇게 할 수 없기 때문입니다. 그 이유는 싱글 플레이어 에이전트가 주변 권한(ambient authority)을 가지고 있기 때문입니다. 즉, 에이전트는 사용자의 신원(identity)과 권한(permissions)을 상속받으므로, 그 사용자가 할 수 있는 모든 일을 수행할 수 있습니다.

따라서 문제는 다른 사람들이 동일한 에이전트에게 직접 지시를 내리도록 허용하는 것입니다. 당신이 자신의 Claude를 다른 사람에게 건네주지 않는 이유는, 그것이 본질적으로 상대방이 당신처럼 행동하게 만들고 당신의 신원과 권한으로 어떤 도구(tool)든 호출할 수 있게 하기 때문입니다. 이는 전형적인 혼동된 대리인 문제(confused deputy problem)입니다.

팀 간, 심지어 조직의 경계를 넘어 협업하기 위해서는 슬랙(Slack) 채널, 이메일 스레드(email thread), 또는 WhatsApp 그룹과 같이 동일한 인터페이스(surface)에서 여러 사람을 지원할 수 있는 에이전트가 필요합니다. 단순히 싱글플레이어 에이전트(single-player agent)를 개선하는 것만으로는 그 단계에 도달할 수 없습니다.

따라서 에이전트가 멀티플레이어(multiplayer)가 되기 위해서는, 여러 사람이 사용하더라도 _안전(safe)_하도록 만들어야 합니다.

방법론에 대해서는 파트 2에서 심도 있게 다루며 구체적인 예시를 제공하겠습니다!