우리는 지난 2년 동안 종단간 암호화 (end-to-end encryption)를 지원하는 개인정보 보호 중심의 이메일 제공업체인 Atomic Mail을 구축하는 데 시간을 보냈습니다. 그 과정에서 AI 에이전트들이 인간이 이메일을 통해 하는 것과 동일하게 사람들과 대화하고 서로 소통할 수 있는 방법이 필요할 것이라는 점이 명확해졌습니다. 그래서 우리는 이메일 인프라를 그 문제에 집중시켰습니다. 이것이 우리가 무엇을, 왜 구축했는지, 그리고 그 과정에서 무엇이 문제였는지에 대한 이야기입니다.

왜 이메일인가, 그리고 왜 에이전트에게는 다른 방식의 가입이 필요한가

이메일은 HTTP보다 오래되었으며 수십 년간의 레거시 (legacy) 짐을 안고 있지만, 동시에 지금까지 발명된 가장 강력한 통신 계층 중 하나이기도 합니다. 탈중앙화 (decentralization)가 프로토콜 자체에 내장되어 있기 때문입니다.

에이전트에게 실제로 다른 점은 전송 프로토콜 (wire protocol)이 아닙니다. 그 주변의 모든 것입니다. 인간은 전화번호나 CAPTCHA를 통해 가입하고 웹메일 UI에서 하나의 편지함을 선택합니다. 에이전트는 이 중 어느 것도 할 수 없으며, 하나의 편지함을 원하는 것도 아닙니다. 에이전트는 인간이 확인 링크를 클릭할 필요 없이, 작업에 필요한 만큼 많은 편지함을 생성하고 삭제하기를 원합니다. 따라서 가입, 인증 (auth), 그리고 API는 그에 맞춰 재구축되어야 했습니다:

• CAPTCHA 대신 작업 증명 (Proof-of-work)
• 로그인 세션 대신 수명이 짧은 권한 토큰 (capability tokens)
• 맞춤형 REST 래퍼 (bespoke REST wrapper) 대신 JMAP을 유일한 인터페이스로 사용

스택 (The Stack)

이는 핵심 경로에 제3자 API가 없는 자체 개발 마이크로서비스 (microservices) 세트입니다. 자체 IMAP/JMAP 코어, MTA, 스팸 방지 계층, 메시지 큐, 블롭 스토리지 (blob storage), 계정 데이터베이스, 그리고 DNS 캐싱이 포함되며, 모두 자체 호스팅되며 자체 인증 및 프록시 계층으로 결합되어 있습니다. 우리는 몇몇 서로 다른 제공업체에 분산되어 있으며, 직접 워밍업(warm up)하는 자체 IP 풀을 보유하고 있습니다.

여기서 정확한 구성 요소와 버전을 명시하지 않는 것은 의도적인 것입니다. 공개적이고 정밀한 스택 목록은 알려진 CVE를 탐색하는 누구에게나 준비된 타겟 목록이 되기 때문입니다. 비슷한 것을 구축하고 계신다면 댓글을 통해 특정 부분에 대해 더 자세히 논의할 용의가 있습니다.

맞춤형 REST API 대신 JMAP을 사용하는 이유

네 가지 이유가 있습니다. 첫째, 에이전트가 이미 작동하는 API-first 방식에 부합합니다. 둘째, 학습 데이터에 잘 나타나 있어 대부분의 모델이 우리의 문서를 읽지 않고도 즉시 JMAP을 작성할 수 있습니다. 셋째, 표준이기 때문에 이메일 API가 어떤 모습이어야 하는지 이미 깊이 고민해 온 사람들의 수년간의 연구 결과를 재사용할 수 있습니다. 마지막으로, 우리를 기반으로 구축하는 누구에게나 통합 리스크를 줄여줍니다. 즉, 그들은 원할 때 언제든 우리를 다른 JMAP 호환 벤더로 교체할 수 있다는 것을 알고 있습니다. 맞춤형 REST API로는 결코 얻을 수 없는 이점입니다.

가입 시 작업 증명 (Proof-of-Work)을 사용하는 이유

목표는 완전한 자율성이었습니다. 즉, 우리는 봇 팜 (Bot farm)으로부터 보호받으면서도, 에이전트는 인간의 개입 없이 (zero human in the loop) 편지함을 등록하고 통신을 시작할 수 있어야 했습니다. 작업 증명 (PoW, scrypt)은 이 두 가지를 동시에 실현합니다. 이는 공격자가 병렬로 실행할 수 있는 계정 수를 제한하며, 오작동하는 계정을 빠르게 정지시키는 내부 평판 시스템 (Reputation system)과 결합됩니다. 어느 하나만으로는 제대로 작동하지 않지만, 함께라면 효과적입니다.

계층형 JWT 체인을 사용하는 이유

챌린지 (Challenge) → 세션 (Session) → 권한 (Capability) 순으로 이어집니다. 이를 통해 모든 요청을 승인하고 원래 발신자까지 추적할 수 있는 동시에, 새로운 PoW 챌린지를 발행해야 하는 빈도와 반응 속도 사이의 균형을 맞출 수 있습니다 (권한 토큰 (Capability tokens)의 수명은 2분입니다).

실패했던 세 가지 사례와 피해야 할 점

가장 어려웠던 부분은 코드가 아니라 아키텍처 (Architecture)였습니다. 이메일은 RFC가 제대로 설명하지 못하는 SMTP 예외 사례가 항상 존재할 정도로 역사가 오래되었습니다. 따라서 무엇을 구축하든 충분히 검증된 (Battle-tested) 것이어야 합니다. 하지만 검증되었다는 것은 대개 오래되었다는 것을 의미하며, 우리는 봇이 인간보다 훨씬 더 자주 메시지를 보내고 (스팸을 받는) 봇 시대의 처리량 (Throughput)에 대응할 수 있을 만큼 현대적인 것이 필요했습니다.

1. Kafka는 큰 메시지를 선호하지 않습니다
이메일은 크기가 클 수 있습니다 (우리의 제한은 10MB입니다). 반면 Kafka는 페이로드 (Payload)가 약 100KB 미만이어야 합니다. 그래서 우리는 모든 메시지를 분할했습니다. 가벼운 헤더 (Header)는 Kafka로 보내고, 풍부한 본문 (Body)은 S3 (우리의 페이로드 크기와 액세스 패턴에 더 최적화된 SeaweedFS)로 보낸 뒤, 컨슈머 (Consumer)가 반대편에서 이를 다시 재조립합니다.

2. JS Kafka 컨슈머(consumers)는 당신을 조용히 배신할 것입니다
kafkajs는 더 이상 제대로 유지보수되지 않고 있으며, 모두가 각자 제각각의 포크(fork) 버전을 사용하고 있습니다. 저희의 경우 클러스터에서 무작위로 연결이 끊기는 현상이 발생했는데, 에러도, 로그도, 아무것도 남지 않았습니다. 만약 이 방식을 사용한다면, 첫날부터 컨슈머(consumer)에 명시적인 에러 핸들링 (error handling) 및 재시도 로직 (retry logic)을 추가하세요.

3. 무엇인가를 워밍업(warmup)하기 전에 IP 평판(IP reputation)을 확인하세요
이론적으로 IP 워밍업 (IP warmup)은 간단해 보입니다. 하지만 실제로는 서비스 제공업체가 이미 스팸 남용 디렉토리에 등록된 주소를 할당할 수 있으며, 특히 초기 단계에서 오염된 IP는 사실상 복구가 불가능합니다. 나쁜 평판과 싸우는 것보다 새로운 서브넷 (subnet)을 구매하거나 제공업체를 옮기는 것이 더 저렴합니다.

현재 우리의 상태

현재 오픈 알파 (open alpha) 단계입니다:

• 활성화된 계정 약 1,000개 (가입 후 최소 1회 이상의 발신 또는 수신 완료), 하루 10~30개씩 증가 중
• 평균 편지함 발신 및 수신 횟수는 각각 약 2통
• X(구 트위터)에 올린 출시 포스트가 25만 회 이상의 조회수를 기록하며 첫날 약 600명의 사용자를 유치
• Product Hunt에서 '오늘의 제품 (Product of the Day)' 2위 기록
• 첫 번째 오픈 소스 기여: 수신 메일을 Telegram으로 전달하는 Docker 기반의 편지함 감시 도구 (inbox watcher)

통합(integrations) 측면에서는, 개인용 에이전트 (personal agents)를 위해 AgentSkill과 stdio MCP 서버를 모두 제공하므로, Hermes나 Claude에서 Atomic Mail을 동일하게 잘 사용할 수 있습니다.

MCP

{
  "mcpServers": {
    "atomicmail": {
...

Agent Skill

# Register
npx --package=@atomicmail/agent-skill atomicmail register --username "myagent"

...

직접 에이전트를 구축 중이거나 JS/Python 이외의 환경에서 작업 중이라면, 기존의 어떤 JMAP 클라이언트와 scrypt PoW 인증을 사용하더라도 API에 직접 접근할 수 있습니다. 워크플로 (workflows)를 위해 커스텀 노드 (custom nodes)를 통해 Dify와 통합하였으며, 더 많은 통합이 예정되어 있습니다.

사람들이 즐거워하는 디테일 중 하나는 저희 사이트가 두 가지 버전을 제공한다는 점입니다. 사람은 그래픽 기반의 랜딩 페이지를 보게 되지만, 브라우저가 없는 것(에이전트 또는 단순 curl)은 에이전트가 편지함을 설정하고 실행하는 데 필요한 지침이 포함된 훨씬 더 심층적인 텍스트 버전을 받게 됩니다. 말 그대로 에이전트에게 atomicmail.ai를 읽고 당신을 위한 편지함을 설정하라고 명령할 수 있습니다.

솔직한 장단점

모든 것을 자체 구축하고 MIT 라이선스 스타일을 따르는 스택의 장점은 다음과 같습니다. 인프라 비용이 거의 들지 않고, 제3자의 변덕으로부터 독립적이며, 우리가 원할 때 언제든 기능을 조정하거나 추가할 수 있습니다. PoW (Proof of Work)는 개인용 에이전트에게 가장 쉬운 진입점을 제공합니다. 즉, 완전히 자율적이며 원하는 만큼 많은 편지함을 가질 수 있습니다.

단점은 다음과 같습니다: PoW는 클라이언트 측 연산 (client-side computation)을 요구하며, 이로 인해 우리의 통합 범위 (integration surface)가 축소됩니다. PoW 환경에서는 원격 MCP (Model Context Protocol)가 의미가 없으며, ChatGPT에는 통합할 수 없습니다. ChatGPT의 통합은 그들의 하드웨어에서 실행되는데, 그들이 (당연하게도) 그곳에서 우리의 PoW를 실행해주지 않을 것이기 때문입니다. 우리의 아키텍처는 개인용 AI 에이전트에 강력하게 최적화되어 있으며, 다른 형태의 사용 방식에는 취약합니다. 이는 우리가 의도적으로 수용한 실제적인 트레이드오프 (tradeoff)입니다.

솔직하게 밝혀둘 점이 하나 더 있습니다: 에이전트용 편지함은 우리의 일반적인 Atomic Mail 제품과 달리 아직 종단간 암호화 (end-to-end encryption)를 지원하지 않습니다. 이는 로드맵에 포함되어 있으며, 현재 출시된 상태는 아닙니다.

향후 계획

• 더 많은 통합, 이상적으로는 네이티브 (native) 통합
• 커스텀 도메인: 개발자들이 Atomic Mail Agentic을 기반으로 자신만의 브랜드 제품을 구축할 수 있도록 지원
• 에이전트 편지함을 위한 종단간 암호화 (end-to-end encryption)
• 안전 기능: 안티 프롬프트 인젝션 (anti-prompt-injection) 메커니즘, 에이전트를 위한 읽기 전용 모드

이제 AMA (Ask Me Anything) 시간입니다. 우리는 이 모든 것에 대해 진심으로 이야기 나누고 싶습니다. AI 에이전트를 위해 무언가를 만들고 있거나 처음부터 ESP (Email Service Provider)를 구축하고 있는 누구에게든 기꺼이 조언을 드릴 용의가 있으며, 솔직한 피드백이나 우리가 잘못했다고 생각하는 부분에 대한 의견을 듣는 것도 매우 환영합니다. 질문하기 전에 직접 확인해보고 싶으시다면:
atomicmail.io/agents
https://github.com/Atomic-Mail/atomic-mail-agentic