에이전트 추가 전 디자인 디스커버리, 아이덴티티, 메시지 설계

두 번째 에이전트를 추가하는 것은 모델 문제가 되기 전에 커뮤니케이션 디자인 문제입니다. 새로운 에이전트는 발견 가능해야 하고(findable), 안정적인 아이덴티티를 가져야 하며, 이미 실행 중인 다른 에이전트들과 메시지 형식을 공유해야 합니다. 이 세 가지가 부족하면, 저는 분할 자체가 일반적인 방식으로 실패할 것이라고 예상합니다: 잘못된 피어(peer)가 호출되거나, 스킬 목록을 확인할 수 없거나, 두 프레임워크가 재구성할 수 없는 흔적을 남기게 됩니다.

Giovanna Carofiglio, Cisco의 Outshift 소속 디스팅귀시드 엔지니어(Distinguished Engineer)이자 시니어 디렉터(Senior Director)인 그녀는 이 레이어에서 오픈으로 작업하고 있습니다. 그녀는 Chain of Thought에서 AGNTCY Collective에 대해 설명했는데, 이는 Cisco, LangChain 및 다른 회사들이 2025년 3월에 시작한 오픈 소스 노력입니다. 이를 통해 서로 다른 프레임워크로 구축되고 원격 배포된 에이전트들도 여전히 협업할 수 있습니다. 저는 그녀의 상호 운용성(interoperability) 질문들을 게이트로 사용할 것입니다. 만약 종이나 문서 위에서 디스커버리, 아이덴티티, 메시지 형식을 채울 수 없다면, 작업을 하나의 에이전트에만 유지하세요.

에이전트들은 어떻게 서로를 찾을까요?

Carofiglio는 일반적인 작업자보다는 주제 전문가(subject matter experts)에 더 가까운 전문화된 에이전트를 예상합니다: 즉, 도메인, 특정 태스크 또는 도구와의 연결고리입니다. 이러한 에이전트들은 호출자가 그들을 검색할 수 있을 때만 구성됩니다. 그녀가 막 출시했다고 말한 이 컬렉티브의 디스커버리 서비스는 스킬(skills), 퍼블리셔(publisher), 주어진 도구와의 호환성, 그리고 평판에 따라 검색합니다.

추가할 수 있는 모든 에이전트에 대해 이 네 가지 필드를 작성하세요. 만약 유일한 주소가 설정 파일 내의 URL이라면, 당신은 의존성을 고정시킨 것입니다(pinned a dependency). 당신은 디스커버리를 설계하지 않은 것입니다.

그녀는 또한 에이전트를 찾는 것과 그것을 자신의 프로세스로 복사하는 것을 분리합니다. 일단 위치가 파악되면, 에이전트는 실행되는 곳에 머무르면서 서비스로 호출될 수 있습니다. 이것이 그녀가 설명하는 일반적인 경우이므로, 디스커버리는 단지 하나의 리포지토리 내부뿐만 아니라 네트워크 전반에서 작동해야 합니다.

이 에이전트는 누구이며, 누가 그 뒤에 서 있을까요?

검색 결과는 무엇을 찾았는지 알 수 없다면 쓸모가 없습니다. 해당 커뮤니티(collective)는 에이전트 아이덴티티 구성 요소와 에이전트를 설명하는 스키마를 공개했습니다. Carofiglio는 이 목표를 사이버 보안 데이터의 공통 언어가 된 Open Cybersecurity Schema Framework (OCSF)에 비유합니다. 그녀는 에이전트를 정의하는 첫 번째 버전을 원하는데, 그 정의 자체가 여전히 논쟁하기 쉽기 때문입니다. 그녀가 원하는 속성들은 구체적입니다: 고유한 아이덴티티, 에이전트와 그 데이터의 명확한 출처(provenance), 그리고 동일한 기록이 검색, 평가, 해당 스킬에 대한 평판을 지원하도록 명시된 역량(skills)들입니다. 작업(Tasks) 역시 에이전트뿐만 아니라 식별자가 필요합니다.

저는 자신이 누가 발행했는지, 그리고 어떤 역량을 주장하는지 말할 수 없는 동료는 거부할 것입니다. 이것은 디렉터리 문제일 뿐만 아니라 AI 정렬 (AI alignment) 문제입니다. 정렬(Alignment)이란 행동이 의도한 목표와 제약 조건에 부합하는지 여부를 말합니다. 배포된 에이전트 하나에 대해, 그것이 취할 수 있는 행동들, 응답을 어떻게 평가할 것인지, 그리고 사람이 결정을 검토해야 하는 시점을 작성해야 합니다. 가드레일(Guardrails)과 평가는 이러한 행동을 테스트하고 제약하는 데 도움이 됩니다. 하지만 이것들 자체가 정렬 문제를 해결해 주지는 못합니다. 자신이 부족한 역량을 광고하거나, 사용자가 식별하지 않은 작업을 수행하는 두 번째 에이전트는 에이전트 사이의 공백에서 동일한 계약을 위반하게 만듭니다.

어떤 프로토콜이 무엇을 말할 수 있게 허용되는가?

Carofiglio의 프로토콜 조언은 제가 팀에게 할 말과 일치합니다. 일반적인 프로토콜에 있어서, 몇 가지 시도가 보통 같은 작업을 추구하다가 몇 개가 참조 표준(reference)이 됩니다. 그녀는 지금도 그런 일이 일어나고 있다고 보고 있으며, 커뮤니티의 계획은 이미 존재하는 프로토콜 개발자들을 지원하는 동시에, 각 프로토콜이 수행하는 작업에 대해 명확하게 밝히는 것입니다.

MCP는 에이전트-대-도구(agent-to-tool) 상호작용을 위한 것입니다. 도구가 원격이고 에이전트에 내장되어 있지 않을 때 중요합니다. 그녀는 MCP가 더 간단하기 때문에 더 일찍 확산될 것으로 예상합니다: 에이전트는 도구를 호출하고, 도구들은 MCP 서버 뒤에서 API와 같은 표면(surface)을 제공할 수 있습니다.

에이전트 간 통신은 더 어렵습니다. ACP는 콜렉티브가 LangChain과 함께 에이전트 프로토콜의 확장으로 작업한 프로토콜입니다. A2A는 Google에서 최근 제안한 것이며, 그녀는 다른 것도 있다고 언급합니다. 지금 단 하나의 승자를 선언하는 것은 추측일 뿐입니다. 오늘 기록할 수 있는 규칙은 다음과 같습니다: 도구 트래픽은 하나의 명명된 프로토콜을 사용하고, 피어 트래픽은 또 다른 것을 사용하며, 낮은 계층의 전송(transport)은 여러 개의 피어 프로토콜을 담을 수 있어야 합니다.

그들의 전송 설계는 Slim이며, 그 대화 직전에 발표되었습니다. 이는 그룹 기반이고, 낮은 지연 시간(low latency)이며, 안전하도록 의도되었으며, 그녀에 따르면 포인트 간 연결보다는 데이터 중심적일 것입니다. 그녀가 이러한 형태를 원하는 이유는 자연어 질문이 종종 여러 가지 기술을 가진 여러 에이전트들을 모아 그 출력을 결합하기 때문입니다. 단일의 포인트-투-포인트 링크는 이를 충족하지 못하며, 낮은 지연 시간이 없으면 이 패턴은 사용 불가능하다고 그녀는 말합니다. 보안 역시 같은 설계에 속해야 합니다: 즉, 처음부터 안전하고, 기업 내부에서 제로 트러스트(zero trust) 하에서도 유지되는 연결이어야 합니다.

전송 계층 위에는 디버깅해야 하는 메시지들이 하나의 스키마를 필요로 합니다. 콜렉티브는 에이전트가 측정될 수 있도록 OpenTelemetry를 확장하고 있으며, 이를 통해 에이전트들이 일반 애플리케이션 내에 배포되고 다양한 프레임워크에서 올 때 발생하는 메트릭(metrics), 이벤트(events), 로그(logs), 트레이스(traces) 등을 서로 연결할 수 있게 합니다. 그녀는 그 스키마용 SDK가 녹화 이틀 전에 출시되었다고 말했습니다. 이러한 공유된 형태야말로 데이터가 어떻게 전달되었는지 또는 어떤 도구가 호출되었는지를 프레임워크 전반에 걸쳐 볼 수 있게 해줍니다.

게이트웨이에 대한 작은 개요이며, 프로토콜도 아니고 콜렉티브가 배포하는 것도 아닙니다:

# 스케치일 뿐입니다. 런타임이나 공급업체 SDK가 아닌 사전 분할 확인(pre-split check)입니다.
def interoperability_gaps(spec: dict) -> list[str]:
gaps = []
...

그룹의 크기가 커지면 무엇을 추가해야 할까요?

몇몇 에이전트는 허술한 계약을 숨길 수 있지만, 에이전트 스웜(agent swarm)은 그렇지 못합니다. AMD의 Anush Elangovan은 스웜을 단일 에이전트 시스템에서 단계적으로 발전하는 과정으로 설명하며, 수십 또는 수백 개의 에이전트가 협력하게 되면 그 역동성은 개별 행위자라기보다는 무리(pack)에 가깝다고 말합니다. 제 결론은 다중 에이전트 시스템이 자체적인 정렬(alignment) 및 보안 작업을 필요로 한다는 것입니다.

Carofiglio는 세 가지 엔지니어링 요구사항에서 같은 압박을 받고 있습니다. 연결성(Connectivity)은 확장되어야 하므로, Slim은 데이터 중심(data-centric)으로 계획되었습니다. 보안(Security) 역시 확장되어야 하며, 이는 아이덴티티(identity)에서 시작하여 기업 내부의 에이전트에 대한 제로 트러스트(zero trust)를 포함한 안전한 연결성까지 이어집니다. 관찰 가능성(Observability)과 평가(evaluation) 또한 이 두 가지와 함께 확장되어야 합니다. 그녀는 다중 에이전트 시스템이 실제로 어떻게 작동하는지를 포착하는 몇 가지 지표를 원하는데, 긴 목록은 읽는 사람을 혼란스럽게 하기 때문입니다. 그녀는 평가가 개발 과정 내에 자리 잡을 만큼 충분히 저렴하기를 바랍니다. 그렇지 않으면 모델 및 데이터셋 생성이라는 길고 복잡한 작업으로 변질될 수 있기 때문입니다. 그녀가 가장 관심을 갖는 변화는 능동적 평가(active evaluation)입니다. 즉, 실행 결과를 점수화하고, 얼마나 많은 개선이 가능한지 정량화하며, 애플리케이션을 구성하는 사람이나 운영하는 기업에게 지연 시간과 비용(평가 비용 포함)에 대한 변경 사항을 추천해 주는 것입니다.

오케스트레이션 패턴(Patterns for orchestration)과 그들이 추가하는 오버헤드는 나중에 읽어볼 목록입니다. 저는 이 시트가 채워진 후에야 다중 에이전트 시스템 최고 사례에서 수집된 에피소도로 시작할 것입니다.

체크리스트

• 모든 새로운 에이전트에 대해 스킬, 발행자(publisher), 도구 호환성 및 평판 신호(reputation signal)를 나열하여 호출자가 검색할 수 있게 합니다.
• 모든 에이전트와 그 데이터에 고유 ID 및 출처(provenance)를 부여하고, 모든 작업에도 ID를 부여합니다.
• 프로토콜 이름을 지정합니다: 도구 측의 MCP와 ACP 또는 A2A와 같은 명시적인 에이전트 간 선택을 합니다.
• 단순한 에이전트 쌍을 넘어, 그룹 계획, 저지연(low-latency) 보안 전송 및 실행을 재구성할 수 있는 공유 텔레메트리 스키마를 마련합니다.
• 허용되는 동작(allowed actions), 평가(evaluation), 인간 검토 지점(human review point), 그리고 지연 시간(latency)과 토큰 예산(token budget)을 작성합니다. 빈 줄은 작업이 하나의 에이전트에 머무름을 의미합니다.

이 주제에 대한 더 많은 내용과 관련 에피소드는 Chain of Thought에서 확인할 수 있습니다. 이 내용은 본 에피소드를 참고했습니다.

에피소드 스크립트를 기반으로 AI의 도움을 받아 초안 작성됨.