인박스 제로(Inbox Zero), 하지만 그 편지함의 주인은 로봇입니다

오전 8:30: 커피가 내려지는 동안 인박스 제로(Inbox Zero) 루프를 시작합니다. 오전 8:35: 어제의 읽지 않은 메시지 50개가 네 개의 버킷(bucket)으로 분류되고, 중요한 메시지에는 답장 초안이 작성되며, 불필요한 노이즈는 보관 처리(archive)됩니다. 당신은 몇 번의 키 입력만으로 이 모든 과정을 승인합니다. 남은 하루 동안, 편지함에는 오직 새로운 메일만 담기게 됩니다.

이것이 이메일 에이전트(agent)가 유지할 수 있는 일상적인 리듬이며, '일상적'이라는 점이 바로 핵심입니다. 인박스 제로를 한 번 달성하는 것은 어렵지 않았습니다. 문제는 그것을 유지하는 것이며, 그 이유는 유지 관리가 지루하기 때문입니다. 지루하고 반복적인 분류 작업이야말로 에이전트가 존재하는 바로 그 이유입니다. 그리고 해당 편지함이 로봇 자신의 것이라면 상황은 더욱 흥미로워집니다.

루프: 네 개의 버킷, 5분

관리 가능한 수준의 읽지 않은 메시지 묶음을 가져옵니다. 50개가 가장 적당합니다. 20개 미만이면 설정 오버헤드(overhead)가 낭비되고, 50개를 초과하면 LLM 컨텍스트 예산(context budget)을 초과하며 승인 검토 과정이 길어집니다:

nylas email list --unread --limit 50 --json

각 메시지를 다음 네 가지 버킷 중 하나로 분류합니다:

버킷	회신 기한
긴급 (Urgent)	몇 시간 이내 — 고객 문제, 매니저 요청
조치 필요 (Action required)	오늘 중 — 회의 후속 조치, 검토
보관 (Archive)	즉시 — 마케팅, 자동 알림

에이전트는 요약 테이블을 보여주며, 당신은 다른 어떤 일이 일어나기 전에 이를 감사(audit)합니다. 이 단계에서 잘못 분류된 '조치 필요(Action)' 항목은 놓쳐버린 약속이 되는 대신 올바른 초안이 됩니다. 그 후 에이전트는 긴급(Urgent) 및 조치 필요(Action) 항목에 대한 답장 초안을 작성하고, 당신은 각 항목을 승인, 수정 또는 건너뜁니다. 승인된 초안은 발송되고, 보관(Archive) 항목은 보관 처리됩니다.

한 가지 타협할 수 없는 규칙이 있습니다: 에이전트는 명시적인 승인 없이 절대 메일을 보내지 않습니다. 에이전트는 초안을 작성하고, 인간이 발송합니다. 초안이 명백히 괜찮아 보일 때조차, 그 클릭 한 번이 "AI가 작성함"과 "도움을 받아 내가 작성함"의 차이를 만듭니다.

처음 실행할 때는 오분류가 발생할 수 있습니다. 수정 사항을 에이전트 프롬프트(prompt)에 상시 규칙으로 인코딩하면, 매 회차마다 속도가 빨라집니다:

# Inbox-zero rules
always_fyi:
  - "from: sales@*"
...

만약 채팅 세션 대신 스크립트(script)로 이를 구동하고 싶다면, 전체 루프는 불과 12줄 정도의 오케스트레이션(orchestration)으로 구성됩니다:

unread = fetch_unread(limit=50)
buckets = classify_all(unread)              # 4개 버킷 분류
print_summary_table(buckets)
...

대화형 수정 및 승인 단계는 이것을 크론(cron) 기반의 분류 봇(triage bot)과 구분 짓는 핵심 요소입니다. 버킷 모델은 동일하지만, 신뢰 계약(trust contract)이 다릅니다. 일부 팀은 나중에 팀원을 자동으로 참조(CC)하는 다섯 번째 "위임(delegate)" 버킷을 추가하기도 합니다. 이는 4개 버킷 버전이 완전히 자리 잡은 후에 진행해야 하며, 그 전에는 하지 마십시오.

이제 로봇에게 전용 편지함을 부여하세요

이 루프를 사람의 편지함에 실행하면 어시스턴트(assistant)를 만든 것이 됩니다. 하지만 에이전트가 직접 "소유"한 편지함에 실행하면 더 자율적인 무언가를 만든 것이 됩니다. 즉, 빌려온 영역이 아니라 에이전트의 작업 공간으로서 기능하는 support@ 또는 triage@ 주소를 갖게 되는 것입니다.

이것이 바로 Agent Accounts가 제공하는 기능입니다. API 호출을 통해 생성되는 호스팅된 편지함(현재 베타 버전)으로, 각 편지함은 실제 주소와 표준 Messages, Threads, Folders, Drafts 엔드포인트와 함께 작동하는 grant_id를 가집니다. 모든 편지함은 inbox, sent, drafts, trash, junk, archive라는 6개의 시스템 폴더와 함께 생성되며, 여러분의 버킷 분류 체계에 필요한 맞춤형 폴더를 이와 함께 생성할 수 있습니다. (시스템 폴더 이름은 예약되어 있습니다.)

폴더 위생(hygiene)은 더 이상 인간에 대한 예의가 아니라 에이전트의 상태(state)가 됩니다. inbox는 작업 대기열(work queue)이고, archive는 처리가 완료되어 조치가 필요 없는 상태이며, 맞춤형 escalations 폴더는 인간에게 업무를 넘기는 인계 지점(handoff point)이 됩니다. 편지함 구조 자체가 곧 상태 머신(state machine)인 것입니다.

쉬운 분류 작업은 에이전트 아래로 밀어내세요

대여된 편지함(borrowed-inbox) 버전은 따라올 수 없는 효율성이 여기에 있습니다. 에이전트 소유의 편지함에서는 rules가 message.created 웹훅(webhook)이 발생하기도 전인 SMTP 계층에서 실행됩니다. 수신 메일은 도착 시 정책 검사(policy checks)를 거칩니다. block은 SMTP 단계에서 거부하고, mark_as_spam은 junk로 라우팅하며, assign_to_folder는 폴더에 분류합니다. 또한 규칙 평가 결과는 감사를 위해 로그로 기록됩니다.

설계를 결정짓는 수치들

설계 시 고려할 만한 몇 가지 편지함 관련 사실들입니다:

발신 할당량 (Send quota): 무료 플랜의 경우 계정당 하루 200개의 메시지(유료 플랜은 기본적으로 일일 제한 없음)가 가능하며, 정책을 통해 계정별로 더 엄격한 할당량을 설정할 수 있습니다. 제한을 초과한 발신은 API 호출 시 에러를 반환하므로, 발신 래퍼(send wrapper)는 무작정 재시도하기보다 에러를 예상하고 이를 표출해야 합니다. 주로 아카이브(archive)와 초안(draft) 작성을 수행하는 분류 에이전트(triage agent)에게는 넉넉한 수치이지만, 대화가 많은 에이전트에게는 절제를 강제하는 요소가 됩니다.
아웃바운드 크기 (Outbound size): 메시지당 40 MB이지만, 수신 측 서버는 통상적으로 약 25 MB를 제한합니다.
웹훅 절단 (Webhook truncation): 본문이 약 1 MB를 초과하면 본문이 생략된 message.created.truncated 형태로 도착합니다. 분류하기 전에 항상 전체 메시지를 가져오십시오.
백로그 (Backlogs): 읽지 않은 메시지가 800개부터 시작하나요? 한 번의 영웅적인 세션으로 처리하려 하지 말고, 50개씩 나누어 루프를 여러 번 실행하십시오.

그리고 초안(drafts)에 대해서는 특별히 언급할 가치가 있습니다. 전체 CRUD는 /v3/grants/{grant_id}/drafts에서 이루어지며, 기존 초안을 발신하는 것은 일반적인 발신과 정확히 동일하게 동작합니다. 이것이 승인 게이트(approval gate)를 깔끔하게 만드는 기본 단위(primitive)입니다. 즉, 에이전트의 출력물은 되돌릴 수 없는 발신이 아니라, 검토 가능한 초안 객체가 됩니다.

구축 전 두 가지 질문

서버 측 규칙(server-side rules)이 LLM을 완전히 대체할 수 있을까요? Archive 버킷의 경우, 대부분 그렇습니다. 알려진 발신자와 자동 알림은 결정론적(deterministic)이기 때문입니다. 하지만 '긴급(Urgent)' 대 '조치 필요(Action)'의 구분은 불가능합니다.

건너뛴 초안(drafts)은 어떻게 되나요? 초안은 큐(queue)에 그대로 남아 있습니다. 초안은 drafts 폴더 내에서 완전한 CRUD(Create, Read, Update, Delete)가 가능한 실제 객체이기 때문에, "세션 종료 시 재방문"하는 것은 기억력 테스트가 아니라 리스트 호출(list call)의 문제입니다. 결정을 미룬다고 해서 아무것도 유실되지 않습니다.

하나의 메일함부터 시작하기

대화형 흐름(interactive flow)은 inbox-zero recipe에 기술되어 있으며, 폴더, 생명주기(lifecycle), 전달 가능성 신호(deliverability signals)와 같은 메일함 메커니즘은 how mailboxes work에서 확인할 수 있습니다.

내일 아침에 이렇게 시도해 보세요: 읽지 않은 메시지 50개를 대상으로 4개 버킷 루프(four-bucket loop)를 한 번 실행하고 시간을 측정해 보십시오. 만약 이것이 평소의 분류(triage) 속도보다 빠르다면, 그다음 질문이 흥미로워집니다. 귀하의 팀이 공유하는 메일함 중 어느 곳이 로봇의 메일함이 될 자격이 가장 먼저 있을까요?