Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 17. 02:21

이메일은 보편적인 에이전트 프로토콜이다

요약

이메일(SMTP)이 가진 연합(Federation) 특성이 AI 에이전트 간의 상호운용성 문제를 해결할 수 있는 보편적 프로토콜임을 설명합니다. 이메일의 주소 지정, 비동기 전달, 대화 상태 유지 기능이 에이전트 프레임워크의 핵심 요구사항과 일치함을 강조합니다.

핵심 포인트

  • 이메일은 이미 검증된 글로벌 연합 계층(Federation layer)임
  • 에이전트 간의 콜드 스타트 및 상호운용성 문제를 해결할 대안
  • 비동기 전달 및 대화 상태 유지를 위한 최적의 구조 제공
  • Agent Accounts를 통한 실제 이메일 기반 에이전트 계정 활용 가능성

서로 다른 조직이 소유하고, 서로 다른 스택(stack)을 실행하며, 사전 협의 없이도 메시지를 교환할 수 있는 프로토콜은 무엇일까요? 그리고 대부분의 현직 개발자들이 태어나기 전부터 이를 안정적으로 수행해 온 것은 무엇일까요?

현재 초안이 작성되고 있는 그 어떤 에이전트 간 프로토콜(agent-to-agent protocols)도 아닙니다. 바로 이메일(email)입니다. 업계가 AI 에이전트를 위한 메시지 엔벨로프(message envelopes)에 대해 논쟁하는 동안, SMTP는 이미 연합(federated)되어 있고, 어디에나 배포되어 있으며, 이미 지루할 정도로 안정적으로 자리 잡고 있습니다.

연합(Federation)은 어려운 부분이며, 이미 완료되었다

모든 새로운 에이전트 상호운용성(agent-interop) 프로토콜은 동일한 콜드 스타트(cold-start) 문제에 직면합니다. 즉, 양측 모두가 이를 채택해야만 작동한다는 점입니다. 당신의 에이전트는 프로토콜 X를 사용하고, 벤더의 에이전트는 프로토콜 Y를 사용하며, 고객의 에이전트는 아직 아무것도 사용하지 않습니다. 그래서 당신은 어댑터(adapters), 레지스트리(registries), 기능 협상(capability negotiation) 등 인프라를 구축하게 됩니다. 이메일은 이미 수십 년 전에 글로벌 주소 공간(global address space)과 MX 레코드(MX records)를 통해 이 문제를 해결했습니다.

메일박스(mailbox)를 가진 에이전트는 오늘날 지구상의 어떤 인간이나 다른 에이전트에게도 메시지를 보낼 수 있습니다. 상대방 쪽에 SDK가 있을 필요도 없고, 공유된 플랫폼이 있을 필요도 없으며, 표준화 기구(standards body)가 프레이밍 전쟁(framing wars)을 종결하기를 기다릴 필요도 없습니다. 이것은 향수가 아니라, 우리가 가진 유일하게 보편적으로 배포된 연합 계층(federation layer)입니다.

메일박스가 에이전트에게 제공하는 것

이 논의는 당신의 에이전트가 실제로 주소를 소유하기 전까지는 이론에 머물러 있습니다. Agent Accounts가 제공하는 것이 바로 그것입니다. 이는 현재 베타 버전으로, API를 통해 완전히 생성된 호스팅 메일박스입니다. 각각은 실제 name@company.com 주소이며, 이를 상호작용하는 모든 대상에게 인간이 운영하는 계정과 구별할 수 없을 정도로 메시지를 보내고 받습니다. 사람과 다른 에이전트들은 이 주소와 직접 통신합니다.

프로토콜의 기능들은 에이전트 프레임워크(agent frameworks)들이 계속해서 재발명하려고 시도하는 요소들과 깔끔하게 매칭됩니다:

  • ID 및 주소 지정 (Identity and addressing) — 당신이 제어하는 도메인 상의 이메일 주소 그 자체입니다.
  • 비동기 전달 (Asynchronous delivery) — 설계 단계부터 스토어 앤 포워드 (store-and-forward) 방식입니다. 상대방 에이전트가 온라인 상태일 필요가 없습니다.
  • 대화 상태 (Conversation state) — 스레딩 (threading)이 교환 내용을 자동으로 그룹화하므로, 두 에이전트 간의 다회차 협상 (multi-turn negotiation)은 양측 모두가 다시 재생할 수 있는 내구성이 있고 순서가 보장된 기록을 가집니다.
  • 이벤트 기반 수신 (Event-driven receipt) — 수신된 메일은 message.created 웹훅 (webhook)을 발생시키므로, 에이전트는 메시지를 확인하기 위해 폴링 (polling)하는 대신 메시지에 반응합니다.
  • 교차 시스템 스케줄링 (Cross-system scheduling) — 계정의 캘린더는 표준 iCalendar를 사용하므로, 에이전트의 초대장은 주요 캘린더 클라이언트를 사용하는 인간에게는 네이티브하게 표시되며, ICS를 파싱하는 다른 에이전트에게도 동일하게 전달됩니다.

두 에이전트, 두 회사, 제로 코디네이션 (zero coordination)

다음은 프로토콜 설계자들이 RFC를 작성 중인 시나리오이며, 현재 40년 된 기반 시설 위에서 실제로 작동하고 있는 모습입니다. 당신의 스케줄링 에이전트가 scheduling@yourcompany.com을 소유하고 있다고 가정해 봅시다. 메시지가 도착합니다: "다음 주에 30분 정도 시간 괜찮을까요?" 이 메시지는 사람으로부터 왔을 수도 있고, 상대방 측의 비서 에이전트로부터 왔을 수도 있습니다. 당신의 에이전트는 이를 구분할 수 없으며 — 이것이 핵심입니다 — 구분할 필요도 없습니다.

message.created 웹훅은 전달 후 몇 초 이내에 발생합니다. LLM이 요청을 파싱하면, 에이전트는 자신의 캘린더를 확인하여 가용성을 체크하고, 스레드 형태의 답장으로 가능한 시간대를 제안합니다. 시간대가 확정되면 이벤트를 생성하고 표준 ICS를 통해 초대를 보냅니다. 상대방이 사람이라면, 초대는 Google Calendar나 Outlook에서 네이티브하게 표시되며 사용자는 '수락'을 클릭합니다. 상대방이 에이전트라면, ICS를 파싱하여 프로그래밍 방식으로 RSVP(참석 회신)를 보냅니다. ID 지정, 전송, 스레딩, 캘린더 핸드셰이크 (handshake)에 이르는 전체 협상 과정은 양측이 합의하거나, 설치하거나, 버전을 맞출 필요가 없는 인프라 위에서 실행됩니다.

이제 동일한 트릭을 테넌트 (tenant) 전체로 확장해 보겠습니다. 하나의 Nylas 애플리케이션은 무제한의 등록된 도메인에 걸쳐 에이전트 계정 (Agent Accounts)을 관리할 수 있으므로, 멀티 테넌트 (multi-tenant) 제품은 모든 고객에게 고객 자신의 도메인에서 작동하는 에이전트를 제공합니다. 조직 간 연합 (Cross-organization federation)은 로드맵 상의 항목이 아닙니다. 그것은 기본값입니다.

트래픽 또한 관찰 가능합니다

잠시 멈춰서 살펴볼 만한 세부 사항이 하나 있습니다. 모든 것이 일반적인 이메일이기 때문에, 상호작용 그래프 (interaction graph)를 일반적인 도구로 분석할 수 있다는 점입니다. communication-patterns 레시피는 네 가지 가중치 신호 — 빈도 40%, 최신성 25%, 호혜성 20%, 공유된 회의 15% — 를 통해 관계를 0~100점으로 점수화합니다. 동일한 분석을 에이전트 트래픽에 적용하면 에이전트 간의 대화 (agent-to-agent chatter)에 대한 관찰 가능성 (observability)을 무료로 얻을 수 있습니다. 맞춤형 바이너리 프로토콜 (bespoke binary protocol)에서 이를 구현하려고 시도해 보십시오.

반론: 이메일은 끔찍한 RPC이다

모두 사실이므로 명확하게 말하겠습니다. 이메일에는 타입화된 스키마 (typed schemas)가 없습니다. 즉, 귀하의 에이전트는 protobuf가 아니라 자연어 (natural language)나 관례를 파싱합니다. 지연 시간 (latency)은 밀리초 (milliseconds) 단위가 아니라 초 (seconds) 단위입니다. 처리량 (throughput) 또한 제한적입니다. 무료 플랜은 에이전트 계정당 하루 200개의 메시지로 제한하는데, 이는 조직 간의 협상에는 관대한 수치이지만 RPC 형태의 작업에는 터무니없는 수치입니다. 또한 스레딩 (threading) 외에는 내장된 요청/응답 상관관계 (request/response correlation)가 없습니다.

스팸은 맞춤형 프로토콜이 지불하지 않는 세금입니다. 개방된 주소 공간 (open address space)에서는 귀하가 결코 보기를 원치 않는 발신자를 포함하여 누구나 귀하의 에이전트에게 메시지를 보낼 수 있습니다. 완화 조치는 메일함 계층 (mailbox layer)에서 이루어집니다. 규칙 (rules)이 발신자 필드와 일치하면 block, mark_as_spam, 또는 assign_to_folder와 같은 작업을 실행하며, in_list 연산자를 통해 도메인, TLD 또는 주소의 타입화된 컬렉션인 허용/차단 목록 (allow/block lists)을 참조할 수 있습니다. block 규칙은 에이전트가 토큰을 소비하기 전인 SMTP 단계에서 메일을 거부합니다. 이는 실제 작업이긴 하지만, 프로토콜 설계가 아닌 설정 (configuration)의 영역입니다.

그러니 아니요, 조직 내부의 에이전트 군집 (agent swarm)을 SMTP 위에서 실행하지 마세요. 당신이 소유한 두 개의 에이전트가 하나의 클러스터 내에서 초당 50번씩 협업한다고요? 상식적인 사람이라면 큐 (queue)나 RPC를 사용하세요.

이메일은 다른 경계에서 승리합니다. 즉, 조직 간, 벤더 간, 그리고 엔드포인트(endpoint)나 스케줄을 제어할 수 없는 무질서한 외부 세계와 에이전트 사이의 경계에서 말이죠. 바로 그 지점이 화려한 프로토콜들이 가장 취약한 곳입니다. 왜냐하면 그곳이 채택 (adoption)이 가장 중요하면서도 가장 적게 이루어지는 곳이기 때문입니다.

실용적인 전략

한쪽 편을 들 필요는 없습니다. 내부적으로 어떤 프로토콜에 베팅하든, 외부를 향하는 에이전트에게도 메일함 (mailbox)을 부여하세요. 그것은 이번 10년 동안 인간이든 기계든 모든 상대방과 작동이 보장되는 유일한 인터페이스입니다. 인바운드 웹훅 (inbound webhook)을 등록하는 것은 단 한 번의 호출로 가능합니다:

curl --request POST \
  --url "https://api.us.nylas.com/v3/webhooks" \
  --header "Authorization: Bearer <NYLAS_API_KEY>" \
...

그 지점부터 에이전트는 이메일을 보낼 수 있는 모든 것, 즉 모든 것에 의해 도달 가능해집니다.

저의 실제 예측은 이렇습니다. 5년 후, 여러 에이전트 프로토콜이 폐쇄된 생태계 (walled gardens) 내부에서 의미 있는 채택을 이루겠지만, 그들 사이의 이음새는 여전히 이메일 주소일 것입니다. 제가 틀렸나요? 대신 어떤 프로토콜에 베팅하시겠는지 말씀해 주세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0