에이전트 계정(Agent Account)을 사용하지 말아야 할 때

영업 사원들을 위한 모닝 브리핑 어시스턴트를 구축하는 팀을 상상해 보세요. 기획안은 이렇습니다: 매일 오전 8시, 에이전트가 각 영업 사원의 편지함을 요약하고 계약이 끊길 위험이 있는 건들을 표시합니다. 그들은 에이전트에게 전용 메일함을 할당하고, 웹훅(webhooks)을 연결하여 배포했습니다. 하지만 모든 브리핑은 빈 상태로 돌아옵니다. 당연한 결과입니다. 영업 사원들의 이메일은 에이전트의 메일함에 도착하지 않았습니다. 애초에 도착할 리가 없었습니다. 에이전트에게 필요했던 것은 _인간의 편지함에 대한 접근 권한(access to a human's inbox)_이었지, 자신만의 고유한 신원(identity)이 아니었습니다.

가상의 시나리오이지만, 실제로 이런 일이 발생했을 것이라고 확신합니다. 새로운 프리미티브(primitives)는 과도한 사용을 유도하며, 현재 에이전트 메일함이 주목받는 시기입니다. 그래서 여기 조금은 인기 없는 글을 올립니다: 언제 에이전트 계정을 사용하지 말아야 하는지에 대하여.

결정을 내리는 질문

에이전트가 자기 자신으로서(as itself) 행동하고 있습니까, 아니면 사람을 대신하여(on behalf of a person) 행동하고 있습니까? 이것이 결정적인 갈림길입니다. 현재 베타 버전인 Agent Account — 에이전트가 엔드 투 엔드로 소유하는 호스팅된 메일함 — 는 첫 번째 경우를 위한 것입니다. 실제 개인의 Gmail 또는 Outlook에 대한 OAuth 권한 부여는 두 번째 경우를 위한 것이며, 문서에서도 이를 명확히 밝히고 있습니다.

에이전트가 인간의 신원을 사용해야 할 때

위에서 언급한 브리핑 봇의 경우입니다. 당신이 보낼 답장을 초안 작성해 주는 어시스턴트. 메시지가 반드시 사람의 주소에서 발송되어야 하고, 답장이 그 사람의 편지함으로 들어와야 하는 모든 경우 — 왜냐하면 상대방은 대화가 그곳에서 이루어질 것이라고 기대하기 때문입니다.

이 경우, 인간의 계정을 연결하고 에이전트가 이를 운영하도록 합니다. share-your-email 가이드는 에이전트가 구조화된 JSON 출력을 통해 연결된 편지함을 제어하는 CLI 버전을 보여줍니다:

nylas email list --unread --limit 10 --json
nylas email send --to "alice@example.com" \
  --subject "Re: Server outage" \
...

메시지는 사용자의 개인 주소로 발송되며, 답장은 사용자의 편지함으로 돌아옵니다. 문서에서 스케치한 분류 루프(triage loop)는 전적으로 이 모델을 기반으로 작동합니다: 읽지 않은 메시지 목록화, 중요한 메시지 전체 읽기, LLM을 이용한 분류, 긴급한 메시지에 대한 답장, 나머지는 읽음 처리. 검색 또한 제공업체의 네이티브 구문(Gmail 검색 연산자, Microsoft KQL 등)으로 실행되므로, from:billing@stripe.com 또는 has:attachment subject:invoice와 같은 쿼리는 사용자가 직접 입력하는 것과 정확히 동일하게 작동합니다.

만약 당신의 에이전트 스택이 Model Context Protocol (MCP)을 지원한다면, nylas mcp install을 통해 동일한 작업들을 입력된 도구(typed tools)로 등록할 수 있으며, 다양한 변형을 다루는 85개 이상의 CLI 가이드가 준비되어 있습니다. 이 중 그 어떤 것도 에이전트 ID(agent identity)를 포함하지 않으며, 포함해서도 안 됩니다.

유용한 징후: 만약 당신의 명세서(spec) 어디에서든 "~를 대신하여 (on behalf of)"라는 문구가 나타난다면, 당신에게 필요한 것은 에이전트 사서함이 아니라 연결된 권한 부여(connected grant)일 가능성이 높습니다.

대량 마케팅이 마케팅 도구에 머물러야 하는 이유

수치가 이를 증명합니다. 무료 플랜의 발송 할당량은 계정당 하루 200개의 메시지입니다. 이는 방송 채널이 아닌, 실제 대화를 나누는 에이전트에게 맞춰진 규모입니다. 트랜잭션 제공업체(transactional providers)에서 벗어나는 마이그레이션 가이드조차 이들을 완전히 교체할 필요는 없다고 말합니다. 영수증 및 마케팅을 위한 대량 발송 파이프라인(blast pipe)은 유지하되, 답장에 유의미한 신호(signal)가 담기는 곳에만 에이전트 사서함을 사용하십시오.

회색 지대: 하나의 제품, 두 개의 갈래

대부분의 실제 제품은 결국 두 가지 방식이 모두 필요하게 되며, 그 사이의 경계는 의도적으로 구분할 가치가 있습니다.

고객 지원 제품을 예로 들어보겠습니다. 상담원의 편지함 내부에서 답장 초안을 작성하는 어시스턴트 — 상담원의 스레드를 읽고, 상담원 자신의 이름으로 보낼 응답을 제안하는 기능 — 는 명백히 연결된 권한 부여(connected-grant) 영역입니다. 하지만 동일한 제품의 support@yourcompany.com 주소, 즉 모든 인바운드 티켓을 직접 수신하고 사람이 확인하기 전에 분류 규칙을 실행하는 주소는 어떨까요? 그것은 에이전트 계정(Agent Account)입니다. 왜냐하면 그 주소에 대해서는 그 어떤 인간의 편지함도 단일 진실 공급원(source of truth)이 될 수 없기 때문입니다.

고객 지원 전화에 사용되는 음성 에이전트(voice agent)를 예로 들어보겠습니다. 상담원이 요청하는 즉시 에이전트가 비밀번호 재설정 안내나 회의 요약본(meeting recap)을 보낼 때, 에이전트는 자신의 voice-agent@yourcompany.com 주소로 발송합니다. 그리고 답장 또한 동일한 계정으로 돌아오므로, 전체 대화는 에이전트가 소유한 하나의 편지함 내의 단일 스레드(thread)가 됩니다. 이것이 에이전트가 자기 자신으로서 행동하는 방식입니다. 만약 요약본이 영업 담당자(account executive)의 주소로 발송되어야 한다면, 이는 다시 연결된 권한(connected grant) 방식으로 돌아가게 됩니다.

다행인 점은 두 방식을 모두 선택하는 것이 아키텍처 측면의 비용(architecture tax)을 발생시키지 않는다는 것입니다. 에이전트 계정(Agent Account)은 내부적으로 동일한 grant_id 계약, 동일한 Messages, Threads, Webhooks 엔드포인트를 사용하는 또 다른 권한(grant)일 뿐입니다. 따라서 하나의 코드베이스가 두 가지 분기(fork)를 동일한 코드 경로로 실행하며, 필요한 시점에 권한의 provider 필드("nylas")를 기준으로 분기 처리하면 됩니다.

실제로 적절한 선택인 경우

대칭성을 위해, 적합한 사례들을 살펴보겠습니다: OAuth를 수행할 인간이 없는, 앱이 완전히 소유한 시스템 편지함(support@, scheduling@); 테스트 실행 시마다 프로비저닝(provisioned)되고 종료 후 삭제되는 휘발성 편지함(ephemeral inboxes); 각기 고유한 할당량(quota)과 평판(reputation)을 가진 멀티 테넌트(multi-tenant) 제품의 고객별 ID; 그리고 자기 자신의 스레드와 캘린더에서 자기 자신으로서 답장을 받고 그에 따라 행동해야 하는 모든 에이전트입니다.

이 네 가지 사례를 관통하는 패턴은 다음과 같습니다: 신원(identity)이 소프트웨어에 속해 있고, 대화가 양방향이며, 인간의 편지함이 단일 진실 공급원(source of truth)이 아니라는 점입니다.

30초 의사결정 체크리스트

무엇인가를 프로비저닝하기 전에 세 가지 질문을 던져보세요:

메시지에 적힌 이름이 누구의 것인가? 사람의 이름이라면 → 연결된 권한(connected grant). 시스템의 이름이라면 → 에이전트 편지함(agent mailbox).
답장이 어디로 도착해야 하는가? 인간의 편지함이라면 → 연결된 권한(connected grant). 에이전트 자신의 스레드라면 → 에이전트 편지함(agent mailbox).
대화인가, 아니면 방송(broadcast)인가? 대규모 방송이라면 → 마케팅/트랜잭션 도구(marketing/transactional tooling). 대화라면 → 에이전트 편지함(agent mailbox).

새로운 기본 요소(primitives)가 등장할수록 정직한 계산이 더욱 중요해집니다. 실패 모드는 에이전트 편지함이 작동하지 않는 것이 아니라, 아키텍처 설계 오류를 한 달 동안 숨길 수 있을 만큼 '충분히 잘 작동하는 것'이기 때문입니다.

현재 진행 중인 에이전트 프로젝트를 위의 세 가지 질문에 대입해 보십시오. 만약 세 질문 모두에서 "에이전트 편지함 (agent mailbox)"이라는 결론에 도달한다면, 개요 (overview)가 시작점이 되어야 할 곳입니다. 그리고 만약 이미 잘못된 포크 (fork) 버전을 출시했다가 살아남아 이를 리팩터링 (refactor)한 경험이 있다면, 저는 진심으로 그 이야기를 듣고 싶습니다.