Show HN: Agent.email – curl로 가입하고 인간 OTP로 인증

출처: Hacker News

소개

안녕하세요, HN 여러분! 저희는 AgentMail의 Haakam, Michael, Adi입니다 – ycs25 기업이죠. 우리는 AI 에이전트에게 전용 이메일 인박스를 제공합니다. 최근에 Agent.Email이라는 실험을 진행했는데, 이는 인간이 아니라 AI 에이전트를 위해 특별히 설계된 회원가입 흐름입니다.

이 아이디어는 시드 론칭 후 받은 피드백에서 나왔습니다. 에이전트는 인간 인증 정보 없이 에이전트를 위한 제품에 가입할 수 없다는 점이 아이러니하면서도 제한적이었습니다. 이는 AgentMail이 내세우는 더 큰 주장과 일맥상통합니다. 인터넷은 인간을 위해 설계되었고, 기본적으로 기계를 배제하도록 되어 있습니다. 전통적인 회원가입 흐름은 브라우저, 페이지를 읽는 사람, 그리고 확인 링크를 클릭하는 사람을 전제로 합니다. 에이전트가 이를 할 수 없다면, 인터넷의 일등 사용자로서 인정받기 어렵습니다.

Agent.Email 작동 방식

1. 에이전트가 인박스를 요청 – 에이전트는 curl을 통해 AgentMail에 연락합니다.
2. 응답 형식 – 요청이 브라우저에서 온 경우 HTML을 반환하고, 그 외에는 Markdown을 반환합니다.
3. 회원가입 요청 – 에이전트는 인간 이메일 주소를 파라미터로 제공하며 회원가입 엔드포인트를 호출합니다.
4. 제한된 인박스 – 에이전트는 자격 증명이 포함된 인박스를 받지만, 기능에 제한이 있습니다.
5. 인간 OTP 검증 – 에이전트는 인간에게 일회용 비밀번호(OTP)를 요청하는 이메일을 보냅니다. 인간이 코드를 회신하면 에이전트가 “클레임”되고 제한이 해제됩니다.

클레임되기 전까지 에이전트는 자신의 인간에게만 이메일을 보낼 수 있으며, 다른 사람에게는 보낼 수 없습니다(하루 최대 10통). 회원가입 엔드포인트는 IP 기준으로 강력히 속도 제한됩니다.

현재 매핑

• 1:1 – 각 에이전트는 하나의 인간과 연결됩니다.
• 향후 작업 – 여러 에이전트를 동시에 운영하는 경우가 이미 흔하기 때문에, 다대일 매핑을 지원할 계획입니다.

디자인 고찰

Agent.Email을 구축하면서 인간 중심이었던 AgentMail의 가정을 다시 살펴볼 수 있었습니다:

• CLI 출력 – 에이전트가 파싱하기 쉽도록 단일 열 형식에 일관된 구분자를 사용하도록 변경했습니다.
• 메시지 ID – 에이전트가 긴 ID에서 허구의 완성을 만들어내는 현상이 있었기에 ID를 짧게 줄였습니다.

커뮤니티를 위한 열린 질문

• “클레임될 때까지 제한”이라는 신뢰 모델이 적절한가요?
• 에이전트 자체 가입이 실제 서비스에서 유용할까요, 아니면 주로 신기성에 불과할까요? 현재가 신기성이라면, 실제로 유용하게 만들려면 무엇이 필요할까요?
• 에이전트 온보딩은 기본적으로 인간 승인을 요구해야 할까요, 아니면 일부 에이전트는 완전 자동으로 프로비저닝될 수 있어야 할까요?
• 안전한 회원가입을 위해 추가로 할 수 있는 조치는 무엇이 있을까요?

---

Comments URL: (Points: 20, Comments: 9)