이제 모두가 AI 에이전트를 가지고 있지만, 여전히 서로 대화할 수는 없다

에이전트 골드러시가 한창입니다. 모든 주요 기술 기업들이 에이전트를 출시했습니다. 스타트업들은 수백 개의 에이전트를 구축하고 있습니다. LangChain, CrewAI, AutoGen과 같은 오픈 소스 프레임워크(Open-source frameworks) 덕분에 웹을 탐색하거나, 코드를 작성하거나, 캘린더를 관리할 수 있는 에이전트를 만드는 것이 매우 쉬워졌습니다.

하지만, 당신의 코딩 에이전트에게 스케줄링 에이전트에게 작업을 넘기라고 요청하면, 에이전트는 당신을 멍하니 바라볼 뿐입니다. 서로 다른 벤더(Vendor)의 에이전트 두 개가 프로젝트를 조율하게 하려면, 커스텀 글루 코드(Glue code), 취약한 API 래퍼(API wrappers), 그리고 수많은 기도만이 필요합니다.

우리는 수천 개의 에이전트를 가지고 있습니다. 하지만 에이전트 사회는 전무합니다.

섬 문제 (The Island Problem)

오늘날 에이전트가 어떻게 작동하는지 생각해 보십시오. 각 에이전트는 인지(Perceive) → 사고(Think) → 행동(Act)이라는 독립된 루프(Loop)로 구성됩니다. 이들은 도구 호출(Tool calls) — 즉, API 엔드포인트(API endpoints), 브라우저 자동화(Browser automation), 파일 시스템 액세스(File system access) — 를 통해 외부 세계와 연결됩니다. 에이전트가 다른 시스템으로부터 정보가 필요할 때, 에이전트는 API를 호출합니다. 행동을 트리거해야 할 때, 또 다른 API를 호출합니다.

이 방식은 에이전트와 서비스 간의 통신(Agent-to-service communication)에는 잘 작동합니다. 하지만 에이전트와 에이전트 간의 통신(Agent-to-agent)은 어떨까요? 그것은 근본적으로 다른 문제입니다.

두 사람이 협업할 때, 그들은 단순히 API 호출을 주고받는 것이 아닙니다. 그들은 맥락(Context)을 공유합니다. 서로의 이해를 바탕으로 지식을 쌓아갑니다. 협상하고, 위임하며, 검증합니다. 그들은 누가 무엇을 볼 수 있고 누구에게 도움을 요청할 수 있는지를 결정하는 사회적 구조 — 팀, 조직, 계층 구조 — 안에서 작동합니다.

현재의 에이전트들은 이러한 인프라를 전혀 갖추고 있지 않습니다. 그들은 HTTP 브리지(HTTP bridges)로 연결된 섬들과 같습니다.

API 통합이 충분하지 않은 이유

당신에게 연구 에이전트(Research agent)와 글쓰기 에이전트(Writing agent)가 있다고 가정해 봅시다. 연구 에이전트는 관련 논문을 찾고, 핵심 결과물을 추출하며, 지식 베이스(Knowledge base)를 구축합니다. 글쓰기 에이전트는 브리프(Briefs)를 받아 초안을 작성합니다.

단순한 접근 방식: 글쓰기 에이전트가 연구 에이전트의 API를 호출하여 결과물이 담긴 JSON 블롭(JSON blob)을 받아온 뒤, 그것을 바탕으로 작업을 수행하는 것입니다.

여기서 문제가 발생하는 지점은 다음과 같습니다:

문맥 손실 (Context loss). 리서치 에이전트(research agent)는 이 논문들이 서로 어떻게 연관되어 있는지, 어떤 주장이 논쟁적인지, 어떤 출처가 가장 신뢰할 수 있는지에 대한 내부 표현(internal representation)을 구축하는 데 30분을 소비했습니다. 하지만 그중 어떤 것도 평면적인 API 응답(flat API response)을 통해서는 전달되지 않습니다. 라이팅 에이전트(writing agent)는 데이터는 받지만, 이해(understanding)는 받지 못합니다.

공유 메모리 부재 (No shared memory). 만약 라이팅 에이전트가 특정 관점이 효과적이지 않다는 것을 발견하고 방향을 전환(pivot)하더라도, 리서치 에이전트는 이를 통해 배우지 못합니다. 다음번에 리서치 에이전트는 똑같은 권장 사항을 내놓을 것입니다. 피드백 루프(feedback loop)도, 축적된 공유 지식도 없습니다.

권한 인식 불능 (Permission blindness). 조직 내에서 서로 다른 에이전트들은 서로 다른 보안 도메인(security domains)을 처리합니다. 귀하의 HR 에이전트는 급여 데이터를 알고 있고, 분석(analytics) 에이전트는 고객 행동을 알고 있습니다. 이들이 인력 계획(workforce planning) 작업을 위해 협업해야 할 때, 각자가 무엇을 볼 수 있는지 누가 결정할까요? 현재로서는 '전부 아니면 전무(all or nothing)' 방식입니다. 전체 API 접근 권한을 갖거나, 아니면 아예 접근할 수 없거나 둘 중 하나입니다.

위임 의미론 부재 (No delegation semantics). "헤이 리서치 에이전트, 섹션 3에 대해 더 깊이 조사해줘"라는 말은 API 호출(API call)이 아닙니다. 이는 암시된 문맥(context), 우선순위(priority), 그리고 기대되는 형식(expected format)을 포함하는 대화적 행위(conversational act)입니다. 현재의 도구 호출(tool-call) 인터페이스는 이를 자연스럽게 표현할 수 없습니다.

우리가 실제로 필요로 하는 것: 소셜 레이어 (A Social Layer)

인간의 협업은 일대일(point-to-point) API 호출을 통해 이루어지지 않습니다. 협업은 공유 워크스페이스(shared workspaces), 조직 계층 구조(organizational hierarchies), 커뮤니케이션 규범(communication norms), 그리고 지식 공유지(knowledge commons)와 같은 사회적 인프라를 통해 작동합니다.

에이전트들에게도 똑같은 것이 필요합니다. 단순한 연결성(connectivity)뿐만 아니라, 그룹을 형성하고, 적절한 접근 제어(access control)와 함께 문맥을 공유하며, 집단 지식을 구축하고, 협업이 요구하는 풍부함으로 소통할 수 있는 방법인 '소셜 레이어(social layer)'가 필요합니다.

이것은 새로운 API 게이트웨이(API gateway)를 만드는 것이 아닙니다. 에이전트들이 서로 어떻게 관계를 맺는지에 대한 프로토콜 수준(protocol-level)의 재사고입니다.

이러한 레이어에는 다음과 같은 요소들이 필요합니다:

조직 수준의 메모리 (Organization-Level Memory)

동일한 조직 내의 에이전트(Agents)들은 공유된 메모리(shared memories)에 접근할 수 있어야 합니다. 이는 단순한 데이터베이스가 아니라, 권한 기반의 접근 제어(permission-based access control)를 통해 에이전트 간에 흐르는 맥락적 지식(contextual knowledge)을 의미합니다. 예를 들어, 고객 지원 에이전트(customer support agent)가 특정 고객이 Slack보다 이메일을 선호한다는 사실을 학습하면, 별도의 명시적인 동기화 작업(sync job)을 작성하지 않아도 계정 관리 에이전트(account management agent)가 이 사실을 알고 있어야 합니다.

이는 메모리가 단순히 저장되는 것이 아니라, 권한 범위 내에서 공유된다는 것을 의미합니다. 고객, 프로젝트, 또는 도메인 개념에 대한 에이전트의 이해는 다른 권한을 가진 에이전트들이 활용할 수 있는 조직적 지식(organizational knowledge)이 됩니다.

텍스트가 아닌 구조화된 지식 (Structured Knowledge, Not Just Text)

에이전트들이 마크다운(markdown)을 주고받는 것은 단순한 인수인계(handoffs)에는 괜찮습니다. 하지만 진정한 협업에는 구조화된 이해(structured understanding)가 필요합니다. 법률 에이전트(legal agent)가 계약서에서 컴플라이언스 리스크(compliance risk)를 발견했을 때, 프로젝트 관리 에이전트(project management agent)는 단순히 "리스크가 있다"는 사실뿐만 아니라, 어떤 엔티티(entity)가 영향을 받는지, 심각도는 어느 정도인지, 프로젝트 일정과 어떻게 연관되는지, 그리고 어떤 선례(precedents)가 존재하는지를 이해해야 합니다.

이는 지식 그래프(knowledge graph)를 지향합니다. 즉, 에이전트들이 공동으로 읽고, 쓰고, 추론(reason)할 수 있는 구조화된 온톨로지(ontology)입니다. 이는 자연어(natural language)를 대체하는 것이 아니라 보완하는 것입니다. 즉, 정밀한 조정(precise coordination)을 가능하게 하는 기계 판독 가능한 기질(machine-readable substrate) 역할을 합니다.

협업 공간 (Collaboration Spaces)

에이전트들에게는 프로젝트 채널(project channels)에 상응하는 것이 필요합니다. 즉, 공유된 상태(shared state), 정의된 역할(defined roles), 그리고 명확한 경계(boundaries)를 가진 상태에서 에이전트의 하위 집합이 특정 목표를 위해 함께 작업하는 경계가 지정된 컨텍스트(bounded contexts)가 필요합니다.

개방형 사무실에서 소리를 지르는 것과 특정 이니셔티브를 위해 전용 워룸(war room)을 갖는 것의 차이라고 생각하면 됩니다. 협업 공간은 에이전트에게 집중력, 프라이버시 경계, 그리고 당면한 과제에 범위가 지정된(scoped) 공유 맥락을 제공합니다.

신원 및 신뢰 (Identity and Trust)

이 모든 것이 작동하려면 에이전트에게 검증 가능한 신원(verifiable identity)이 필요합니다. 단순히 "이 요청이 IP 10.0.0.5에서 왔다"가 아니라, "이것은 재무 팀의 예산 에이전트이며, 조달 에이전트로부터 지출 데이터를 요청할 권한이 있다"라는 식의 신원이 필요합니다. 신원은 신뢰를 가능하게 하고, 신뢰는 위임(delegation)을 가능하게 하며, 위임은 진정한 협업을 가능하게 합니다.

아키텍처 역전 (The Architecture Inversion)

오늘날 대부분의 통합(integration) 방식에는 흥미로운 점이 하나 있습니다. 바로 에이전트가 외부로 연결된다는 것입니다. 당신의 에이전트는 Slack용 플러그인, GitHub용 플러그인, CRM용 플러그인을 가지고 있습니다. 새로운 플랫폼이 추가될 때마다 구축하고 유지 관리해야 할 새로운 통합 방식이 생겨납니다.

만약 이것을 역전시킨다면 어떨까요? 에이전트가 플랫폼에 접근하는 대신, 플랫폼이 표준화된 게이트웨이 어댑터(gateway adapters)를 통해 에이전트 네트워크로 내부 연결되는 방식입니다. 에이전트 네트워크가 중심이 되고, 플랫폼은 주변 장치(peripherals)가 되는 것입니다.

이는 미묘하지만 중요한 차이입니다. 현재 모델에서 에이전트는 자신이 사용하는 모든 서비스의 클라이언트(client)입니다. 역전된 모델에서는 에이전트 네트워크가 중추(backbone)가 되고, 서비스들이 그곳에 플러그인(plug in)됩니다. 이는 다음을 의미합니다:

• 새로운 플랫폼을 추가할 때 모든 에이전트를 변경할 필요가 없습니다.
• 에이전트들은 어떤 플랫폼에 연결되어 있든 네트워크를 통해 통신합니다.
• 플랫폼이 아닌 프로토콜(protocol)이 정보의 흐름을 정의합니다.

이는 성형 토폴로지(star topology, 에이전트가 중심이고 플랫폼이 바퀴살인 형태)와 망형 토폴로지(mesh topology, 에이전트가 네트워크를 형성하고 플랫폼이 접속 지점이 되는 형태)의 차이와 같습니다.

3계층 컨텍스트 문제 (The Three-Layer Context Problem)

이 모든 과정의 이면에는 표현(representation)의 과제가 숨어 있습니다. 서로 다른 소비자들은 각기 다른 형식의 컨텍스트(context)를 필요로 합니다:

AI 에이전트는 구조화된 텍스트 — 마크다운(markdown), 명확한 계층 구조, 명시적인 메타데이터(metadata) — 와 함께 작동할 때 가장 효율적입니다. 이들은 파싱(parse)하기 쉽고, 추론(reason)할 수 있으며, 변환(transform)하기 용이한 컨텍스트가 필요합니다.

인간은 시각적 어포던스(visual affordances) — 캔버스(canvases), 보드(boards), 타임라인(timelines), 다이어그램(diagrams) — 가 필요합니다. 이들은 공간적 추론(spatial reasoning)과 패턴 인식(pattern recognition)을 활용할 수 있는 방식으로 제시된 컨텍스트를 필요로 합니다.

**기계 협업 (Machine collaboration)**에는 지식 그래프 (knowledge graphs), 타입화된 관계 (typed relationships), 쿼리가 가능한 온톨로지 (queryable ontologies)와 같은 공식적인 구조가 필요합니다. 대규모로 협업하는 기계들은 자연어 (natural language)가 제공할 수 없는 정밀함을 필요로 합니다.

진정한 에이전트 협업 레이어는 이 세 가지를 동시에 지원해야 합니다. 동일한 기저 컨텍스트 (underlying context)를 세 가지 상호 보완적인 형태로 표현하는 것입니다. 즉, AI 소비를 위한 마크다운 (markdown), 인간의 감독을 위한 시각적 캔버스 (visual canvas), 그리고 기계 간 정밀도를 위한 지식 그래프 (knowledge graph)가 그것입니다.

이는 단순히 있으면 좋은 기능이 아닙니다. 인간이 읽을 수 있는 레이어 (human-readable layer)가 없다면, 조직은 에이전트 협업을 감사하거나 조종할 수 없습니다. 기계가 읽을 수 있는 레이어 (machine-readable layer)가 없다면, 에이전트들은 복잡한 작업이 요구하는 정밀도로 협력할 수 없습니다. AI 친화적인 레이어 (AI-friendly layer)가 없다 없다면, 이러한 에이전트들을 구동하는 LLM (Large Language Models)은 공유된 컨텍스트를 효율적으로 처리할 수 없습니다.

누가 혜택을 보는가?

사용자를 대신하여 로컬에서 실행되고 데스크톱 애플리케이션과 상호작용하는 Mano-P와 같은 GUI 자동화 에이전트를 생각해 보십시오. 현재 이 에이전트는 고립되어 작동합니다. 버튼을 클릭하고 양식을 채울 수는 있지만, 보고서를 작성하기 전에 리서치 에이전트 (research agent)에게 컨텍스트를 요청하거나, 작업 시퀀스를 완료했을 때 프로젝트 관리 에이전트 (project management agent)에게 알림을 보낼 수는 없습니다.

여기에 소셜 레이어 (social layer)를 부여하면, 갑자기 이 에이전트는 팀의 일원이 됩니다. 행동하기 전에 지식 에이전트 (knowledge agents)로부터 정보를 요청할 수 있고, 행동한 후에는 조정 에이전트 (coordination agents)에게 결과를 보고할 수 있으며, 조직의 우선순위가 바뀔 때 업데이트된 지침을 받을 수 있습니다. 고립된 도구가 협업하는 참여자가 되는 것입니다.

이러한 패턴은 에이전트가 작동하는 모든 곳에 적용됩니다. 테스트를 QA 에이전트 (QA agents)에게 위임할 수 있는 코딩 에이전트 (coding agents), 전문 도메인 에이전트 (specialized domain agents)에게 에스컬레이션할 수 있는 고객 서비스 에이전트 (customer service agents), 스크래핑 에이전트 (scraping agents)에게 추가 수집을 요청할 수 있는 데이터 분석 에이전트 (data analysis agents) 등이 그 예입니다.

미결 과제 (The Open Question)

우리는 Mininglamp에서 이 문제를 해결하기 위해 노력해 왔습니다. 우리가 Octo (Open ConText Orchestration)라고 부르는 접근 방식은 AI 에이전트(AI agents)를 위한 사회적 및 통신 계층(social and communication layer)을 구축하려는 시도입니다. 이는 선택적인 SaaS 모드를 포함한 완전한 오픈 소스(open-source)로 제공되는데, 그 이유는 이 인프라가 독점적인 해자(proprietary moat)가 아닌 공유된 표준(shared standard)이 되어야 한다고 믿기 때문입니다.

Octo를 이끄는 핵심 통찰은 에이전트 간의 협업(agent collaboration)이 단순히 기술적인 문제가 아니라 근본적으로 사회적인 문제라는 점입니다. 에이전트가 서로를 발견하고, 신뢰를 구축하며, 컨텍스트(context)를 공유하고, 행동을 조정(coordinate action)하는 방식에 대한 프로토콜(protocols)은 컴퓨터가 패킷(packets)을 교환할 수 있게 하는 프로토콜만큼이나 세심하게 설계되어야 합니다.

우리는 아직 초기 단계에 있습니다. 산업 전체가 초기 단계입니다. 하지만 "무언가를 할 수 있는 에이전트"와 "함께 일할 수 있는 에이전트" 사이의 간극이 병목 현상(bottleneck)이 되고 있습니다. 개별 에이전트의 능력은 빠르게 향상되고 있습니다. 하지만 이러한 능력들을 협업 워크플로(collaborative workflows)로 구성하는 능력은 이제 겨우 시작 단계에 불과합니다.

만약 여러분이 이 문제를 고민하고 있거나, 혹은 이 문제에 직면해 있다면, 프로젝트는 github.com/Mininglamp-OSS에서 확인할 수 있습니다. 우리는 이 프로젝트를 고립된 상태에서 만들기보다 커뮤니티와 함께 만들어 나가고 싶습니다. 프로젝트의 취지를 생각하면, 그렇지 않는 것이 오히려 아이러니할 것입니다.