AI 에이전트가 스스로 서비스에 가입하는 방법

이메일을 받을 수 없는 AI 에이전트는 가입 양식을 완료할 수 없습니다. 이러한 단 한 가지의 제약 사항은 거대한 자율 워크플로우(autonomous workflows)의 범주를 조용히 배제하고 있습니다. 데이터 소스에 대한 개발자 계정이 필요한 리서치 에이전트(research agent), 매 테스트 실행 시마다 SaaS에 등록해야 하는 QA 에이전트, 마켓플레이스에서 구매자 프로필이 필요한 구매 에이전트 등이 그 예입니다. 이들 모두는 "확인 이메일을 보냈습니다"라는 단계에서 멈추게 됩니다.

장애물은 결코 양식(form)이 아니었습니다. 헤드리스 브라우저(Headless browsers)는 양식을 충분히 잘 채웁니다. 진짜 장애물은 전통적으로 확인 이메일이 사람의 편지함으로 전달된다는 점이며, 이는 사람이 개입하지 않기로 되어 있었던 루프(loop)에 다시 사람을 끌어들입니다.

Agent Accounts는 해당 의존성을 제거합니다. 에이전트는 자체 호스팅되는 메일함(해당 기능은 베타 버전임)을 할당받고, 해당 주소로 가입하며, 웹훅(webhook)을 통해 확인 이메일을 포착하여 스스로 온보딩(onboarding)을 완료합니다. 다음은 쿡북(cookbook) 레시피를 요약한 전체 흐름입니다.

세 가지 설정 단계가 필요합니다. 첫째, 메일함을 생성합니다. 하나의 CLI 명령어를 사용하거나, API를 호출하고 싶다면 `

셋째, 에이전트의 주소를 사용하여 대상 서비스의 가입 양식을 제출합니다. 서비스가 API를 제공한다면 직접적인 API 호출을, 제공하지 않는다면 Playwright/Puppeteer 단계를, 엔드포인트가 단순하다면 일반적인 fetch POST를 사용합니다:

await fetch("https://saas-you-care-about.example.com/signup", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
...

인증 이메일 포착하기

이 부분은 과거에는 사람이 직접 수행해야 했던 작업입니다. 이제는 세 가지 필터와 정규 표현식 (regex)을 사용하는 웹훅 핸들러 (webhook handler)가 담당합니다:

app.post("/webhooks/signup", async (req, res) => {
  res.status(200).end();

...

다단계 확인, 캡차 (captcha), 또는 OAuth 리다이렉트 (redirect)가 필요한 경우에는 마지막 fetch를 링크를 따라가는 헤드리스 브라우저 (headless browser)로 교체하십시오. 만약 서비스가 링크 대신 코드를 보낸다면 파싱 (parsing) 형태는 동일합니다. OTP 추출 레시피에서 해당 변형 사례를 다루고 있습니다.

코드에 나타나지 않는 판단의 영역

이 레시피의 "알아야 할 사항 (things to know)" 섹션이야말로 진정한 엔지니어링이 이루어지는 곳입니다:

도착한 첫 번째 메시지를 신뢰하지 마십시오. 많은 서비스가 인증 이메일이 오기
전에 "환영합니다" 이메일을 보냅니다. 위의 핸들러는 아무것도 클릭하기 전에 발신자
및 예상되는 URL 패턴을 모두 확인합니다. 이 두 가지 검사를 모두 유지하십시오.

메일함을 철저히 잠그십시오. 예상되는 from.domain 값들의 허용 목록 (allow-list)을 작성하고, 그 외의 모든 것에 대해 차단 (block) 규칙을 결합하십시오. 에이전트의 주소가 유출되더라도, 메일함이 스팸 자석이 되어 자동화 시스템에 쓰레기 데이터를 공급하는 대신 깨끗한 상태를 유지할 수 있습니다.

웹훅 서명 (webhook signatures)을 검증하십시오. 위의 핸들러는 간결함을 위해 req.body를 신뢰하지만, 프로덕션 (production) 환경에서는 동작하기 전에 모든 POST 요청에 대해 X-Nylas-Signature 헤더를 확인해야 합니다. 가입 에이전트는 웹훅이 알려주는 정보에 따라 동작하며, 검증되지 않은 웹훅 엔드포인트는 귀하의 자동화 시스템으로 들어오는 인증되지 않은 진입점이 됩니다.

재사용하거나 태워버리거나 — 신중하게 선택하세요. 하나의 계정으로 여러 번의 가입 프로세스를 수행할 수 있으며, 또는 실행할 때마다 새로운 계정을 프로비저닝(provision)하고 완료 후 삭제할 수도 있습니다. 실행마다 계정을 새로 생성하는 방식을 택한다면, 정리(teardown) 작업은 성공 경로(happy path)와 실패 경로(failure path) 모두에 포함되어야 합니다.

nylas agent account delete signup-agent@agents.yourdomain.com --yes

또는 API를 통해 간단히 DELETE /v3/grants/<AGENT_GRANT_ID>를 호출할 수도 있습니다. 권한(grant)이 곧 계정이므로, 하나를 삭제하면 다른 하나도 삭제됩니다. 비활성 권한이 쌓이게 되는데, "나중에 정리하면 되겠지"라는 생각은 모든 팀이 결국 400개의 미정리 권한을 떠안게 되는 지름길입니다.

할당량(quota)을 파악하세요. 무료 플랜 계정은 계정당 하루 최대 200개의 메시지를 보낼 수 있으며, 인바운드(inbound)는 관대하지만 무한하지는 않습니다. 대규모 테스트 매트릭스(test matrix)를 구성한다면 하나의 계정을 재사용하기보다 여러 권한(grants)에 분산시키는 것이 좋습니다.

서비스 약관을 준수하세요. 프로그래밍 방식의 가입(Programmatic signup)은 자체 테스트 및 퍼스트 파티(first-party) 통합 용도로는 괜찮습니다. 제3자(third parties) 서비스를 스크래핑(scraping)하는 것은 차원이 다른 문제입니다. 플랫폼 내에서 이를 강제하는 장치는 없지만, 귀하의 법무 팀은 이를 문제 삼을 것입니다.

이 패턴이 가입보다 더 중요한 이유

이메일 인증 단계는 일반적인 역량의 한 사례일 뿐입니다: 에이전트는 다른 시스템이 무언가를 보낼 수 있는 지속 가능하고 주소 지정 가능한(addressable) 정체성을 갖게 됩니다. 영수증, 비밀번호 재설정, 내보내기 준비 완료 알림, "보고서가 첨부되었습니다" 이메일 등 — 서비스가 이메일을 통해 전달하는 모든 것은 에이전트가 조치할 수 있는 대상이 됩니다. 에이전트가 사람과 동일한 방식으로 연락을 받을 수 있기 때문입니다.

일부 서비스는 가입 후에도 후속 확인, "프로필을 완성하세요"라는 독려, 결제 통지 등을 계속 보냅니다. 동일한 웹훅 핸들러(webhook handler)는 에이전트가 각 메시지를 읽고, 결정하고, 등록 시 사용했던 동일한 주소로 응답하는 완전한 답장 루프(reply loop)로 확장됩니다.

엔드 투 엔드 (end-to-end) 루프 — 프로비저닝 (provision), 등록 (register), 검증 (verify), 실행 (act) — 는 DNS 설정이 필요 없는 테스트용 *.nylas.email 도메인을 대상으로 실행되므로, 이 실험에 드는 비용은 웹훅 (webhook) 엔드포인트 하나와 오후 시간 정도뿐입니다. 오늘날 여러분의 팀이 수동으로 가입하는 서비스 중 하나(스테이징 SaaS, 내부 도구, 샌드박스 API 등)를 골라 정확히 그 가입 과정을 자동화해 보세요. 어떤 수동 검증 단계를 가장 먼저 없애고 싶으신가요?