--- title: "AI 에이전트를 위한 SMTP? ASMTP가 제안하는 비동기 메일박스 프로토콜" published: 2026-05-18T23:50:58.000Z canonical: https://jeff.news/article/2930 --- # AI 에이전트를 위한 SMTP? ASMTP가 제안하는 비동기 메일박스 프로토콜 ASMTP는 AI 에이전트끼리 RPC처럼 즉시 호출하지 않고, 서버에 보관되는 메일박스를 통해 비동기로 메시지를 주고받게 하자는 작은 오픈 스펙이다. 헤더만 먼저 푸시하고 본문은 필요할 때 가져오게 만들어 토큰 비용을 줄이는 게 핵심 설계다. - ASMTP는 ‘AI 에이전트용 메일’이라는 아이디어에서 출발한 작은 오픈 프로토콜임 - 정식 이름은 Agent Simple Mail Transfer Protocol - 에이전트마다 서버에 보관되는 메일박스를 갖고, 보내는 쪽은 수신자 메일박스에 envelope를 넣음 - 받는 쪽은 자기 메일박스를 읽기만 하면 되고, 네트워크가 전달과 보관을 맡음 - 핵심 관점이 재밌음 — 에이전트는 서비스가 아니라 계약자라는 것 - 일반 서비스는 포트를 열고 RPC 요청에 즉시 응답해야 의미가 있음 - ASMTP의 에이전트는 주소를 가진 작업자에 가깝고, 일이 메일박스에 쌓였다가 다음에 깨어났을 때 처리됨 - 멀티 에이전트 시스템에서 “상대 에이전트가 지금 온라인인가?” 문제를 프로토콜 차원에서 덜어내려는 설계임 ```mermaid sequenceDiagram participant 송신자 as 송신 에이전트 participant 운영자 as ASMTP 운영자 participant 메일박스 as 수신자 메일박스 participant 수신자 as 수신 에이전트 송신자->>운영자: POST /messages 로 envelope 전송 운영자->>메일박스: envelope 영구 저장 운영자-->>송신자: 202 stored 반환 운영자->>수신자: 헤더만 푸시 수신자->>운영자: GET /messages/{id} 운영자-->>수신자: 전체 envelope 반환 ``` - 양쪽이 모두 온라인이면 흐름은 단순함 - 송신자가 `POST /messages`로 envelope를 보내면 operator가 durable storage에 저장하고 `202`를 돌려줌 - 수신자의 WebSocket에는 본문이 아니라 헤더만 담긴 push frame이 감 - 수신자는 그 헤더를 보고 진짜 열어볼 메시지만 REST로 가져옴 - 수신자가 오프라인이어도 메시지는 날아가지 않음 - 수신자의 harness가 닫혀 있으면 envelope는 durable mailbox에 그대로 남음 - 나중에 수신자가 persisted cursor로 다시 subscribe하면 operator가 놓친 헤더를 replay함 - timeout으로 실패 처리하거나, 송신자가 재시도 루프를 직접 짤 필요가 줄어듦 > [!IMPORTANT] > ASMTP의 제일 실용적인 포인트는 본문을 바로 먹이지 않는다는 것임. push frame은 보통 약 80토큰이고, 본문은 500~5,000토큰 이상이라 토큰 비용 차이가 크게 벌어짐. - 이 프로토콜이 밀고 있는 키워드는 context economy임 - 헤더는 본문 비용의 1~4% 수준이라고 설명함 - 에이전트가 84개의 unread envelope를 깨자마자 받는 상황을 예로 들면, 헤더만 보면 약 6,700토큰으로 한 번에 triage 가능함 - 본문을 전부 먹이면 80,000토큰 이상이 들어갈 수 있으니, 모델 컨텍스트를 쓸데없이 태우는 셈임 - 저장소 구성도 프로토콜 제안치고 꽤 실전형임 - `WHITEPAPER.md`가 normative specification 역할을 함 - `schemas/`에는 JSON Schema 2020-12 기반 wire format이 들어 있음 - `examples/local-operator`에는 Python/FastAPI reference operator가 있음 - `tests/conformance`에는 operator 구현체에 꽂아볼 수 있는 51개 black-box test가 포함됨 - 이건 “에이전트끼리 이메일 보내면 재밌겠다” 수준보다는, 에이전트 런타임의 실패 모드를 꽤 의식한 설계에 가까움 - 오프라인 수신자, durable delivery, cursor replay, 헤더 우선 triage가 전부 같은 문제를 향함 - 에이전트가 많아질수록 동기 RPC보다 비동기 메일박스 모델이 운영하기 편한 구간이 생길 수 있음 --- ## 기술 맥락 - ASMTP가 RPC 대신 메일박스 모델을 고른 이유는 에이전트가 항상 살아 있는 서버가 아닐 수 있기 때문이에요. 작업을 처리할 때만 깨어나는 harness라면, 열린 포트와 즉시 응답을 전제로 한 설계가 자연스럽지 않거든요. - 헤더와 본문을 분리한 것도 토큰 비용 때문에 중요해요. 에이전트는 unread 메시지가 많을 때 모든 본문을 컨텍스트에 넣으면 바로 비용과 품질 문제가 생겨요. 그래서 약 80토큰짜리 헤더로 먼저 분류하고, 필요한 본문만 가져오게 한 거예요. - durable mailbox와 cursor replay는 장애 처리 관점에서 핵심이에요. 수신자가 몇 시간 꺼져 있어도 메시지는 보관되고, 다시 접속하면 마지막 cursor 이후 헤더를 재생할 수 있어요. 이러면 송신자 쪽 재시도 로직과 타임아웃 설계가 훨씬 단순해져요. - JSON Schema와 conformance test를 같이 둔 건 프로토콜을 실제 구현 대상으로 본다는 신호예요. 에이전트 통신은 구현체가 여러 개로 갈라질 가능성이 높아서, wire format과 51개 black-box test 같은 합의 장치가 없으면 금방 호환성이 깨지거든요. ## 핵심 포인트 - 각 에이전트는 서버에 보관되는 메일박스를 갖고, 메시지는 durable envelope로 저장됨 - 수신자가 오프라인이어도 메시지는 사라지지 않고, 다음 접속 때 cursor 기준으로 헤더가 replay됨 - 푸시 프레임은 약 80토큰이고 본문은 500~5,000토큰 이상이라 triage 비용 차이가 큼 - 저장소에는 명세, JSON Schema 2020-12, Python/FastAPI 예제 operator, 51개 conformance test가 포함됨 ## 인사이트 에이전트를 ‘항상 떠 있는 서비스’가 아니라 ‘주소를 가진 계약자’로 본다는 관점이 꽤 실용적이다. 멀티 에이전트 시스템에서 진짜 병목은 똑똑한 응답보다 컨텍스트 비용과 비동기 실패 처리일 때가 많아서, 이런 메일박스형 설계는 볼 만하다.