동료로서의 에이전트: 정체성, 책임감, 그리고 이메일

신입 사원은 첫날 이메일 주소를 받습니다. 반면 대부분의 AI 에이전트는 빌려온 OAuth 토큰과 작업 목록을 받습니다. 이 차이는 겉보기에만 달라 보일 수 있습니다. 하지만 그렇지 않습니다. 이 차이는 무언가 잘못되었을 때 누가 책임을 지는지 조용히 결정합니다.

동료 테스트 (The coworker test)

지속적인 작업(지원 분류, 일정 예약, 아웃리치 등)을 수행하는 모든 에이전트에 대해 제가 유용하다고 생각하는 필터가 하나 있습니다. "당신은 이 에이전트를 온보딩(onboarding)한 방식 그대로 인간 계약자를 온보딩하겠습니까?"

직원 한 명의 로그인 정보를 공유하나요? 본인만의 주소가 없어서 그들이 보내는 모든 메시지가 다른 사람으로부터 온 것처럼 보이나요? 캘린더가 없어서 그들이 예약하는 모든 회의가 빌려온 캘린더에 기록되나요? 당신은 그런 방식으로 팀을 운영하지 않을 것입니다. 왜냐하면 조직 구조가 존재하기 위해 제공하는 핵심 요소인 "누가 이것을 했으며, 그들에게 어떻게 연락할 수 있는가?"에 대한 안정적인 답변을 잃게 되기 때문입니다.

소프트웨어 에이전트가 이러한 표준에서 제외되어 온 이유는 주로 그들에게 실제 정체성을 부여하는 것이 어려웠기 때문입니다. 이제는 더 이상 그렇지 않습니다.

주소, 캘린더, 그리고 기록 (An address, a calendar, a paper trail)

현재 베타 버전인 Agent Accounts는 소프트웨어에 동료와 같은 대우를 적용합니다. 에이전트는 메일을 보내고 받을 수 있는 실제 name@company.com 메일함을 갖게 되며, 6개의 시스템 폴더(inbox, sent, drafts, trash, junk, archive)가 자동으로 프로비저닝(provisioned)되고, 표준 iCalendar을 통해 이벤트를 호스팅하고 초대에 응답(RSVP)할 수 있는 기본 캘린더를 갖게 됩니다. 이와 상호작용하는 누구에게나, 이 계정은 사람이 운영하는 계정과 구별할 수 없습니다.

문서에서는 이를 동료를 정의하는 방식과 동일하게 설명합니다: "연락 가능하고(reachable), 지속적이며(persistent), 자체적인 상호작용에 대해 책임을 집니다(accountable)." 연락 가능함 — 누구든지 그것이 소프트웨어인지 알 필요도 신경 쓸 필요도 없이 scheduling@yourcompany.com으로 이메일을 보낼 수 있습니다. 지속성 — 메일함과 그 전체 기록은 단일 배포(deployment), 모델 교체(model swap), 또는 재작성(rewrite)보다 더 오래 지속됩니다. 책임감 — 에이전트가 보낸 모든 메시지는 자체 보낸 편지함(sent folder)에 보관되어 있으며, 다른 누구도 아닌 에이전트 본인의 것으로 귀속됩니다.

기계적으로 보면, 이 계정은 또 다른 권한 부여(grant)일 뿐입니다. 하나의 grant_id가 기존의 Messages, Drafts, Threads, Folders, Calendars, Events, 그리고 Webhooks 엔드포인트 전반에 걸쳐 작동합니다. 에이전트는 사람이 연결된 계정과 동일한 API를 사용하며, 이것이 바로 핵심입니다.

비인간 동료를 온보딩(Onboarding)하는 것은 단 한 번의 API 호출로 이루어집니다. 다른 제공업체(provider)에 사용되는 것과 동일한 Bring Your Own Authentication 엔드포인트를 사용하며, `

구체적인 예를 들어보겠습니다. support@yourcompany.com 에이전트 계정(Agent Account)은 모든 인바운드(inbound) 지원 이메일을 전달된 사본이 아닌 실제 수신본으로 직접 받습니다. 계정에 연결된 규칙(Rules)은 모델이 단 하나의 토큰도 소비하기 전, SMTP 단계에서 알려진 스팸 도메인을 차단합니다. 송장(Invoices)은 재무 폴더로 자동 라우팅(auto-route)됩니다. VIP 발신자는 즉각적인 주의가 필요한 대상으로 표시됩니다. LLM은 일반적인 질문에 대한 답장을 초안(draft)하며, 민감한 질문은 웹훅(webhook) 흐름을 통해 사람이 승인할 수 있도록 대기열(queue)에 쌓입니다.

이 파이프라인의 모든 요소는 사람을 온보딩(onboarding)할 때 익숙한 것들과 매칭됩니다: 책상(메일함), 상시 지침(규칙), 위험한 사항에 대한 관리자의 승인(승인 대기열). 차이점은 상시 지침이 기억이 아닌 인프라(infrastructure)에 의해 강제되며, 문서 기록(paper trail)이 자동으로 생성된다는 점입니다.

모델은 조직도(org charts)가 확장되는 방식과 동일하게 확장됩니다. 멀티 테넌트(multi-tenant) 제품은 고객당 하나의 에이전트 계정을 프로비저닝(provision)할 수 있으며, 각 계정은 고객 고유의 인증된 도메인 — scheduling@customer-a.com, scheduling@customer-b.com — 을 가지며, 각기 다른 정책, 발송 할당량(send quota), 발신자 평판(sender reputation)을 갖습니다. 이 모든 것은 동일한 코드 경로를 가진 하나의 Nylas 애플리케이션 내에서 실행됩니다. 이는 백 개의 서로 다른 정체성을 가진 백 명의 동료와 하나의 급여 시스템이 존재하는 것과 같습니다.

은유가 깨지는 지점

이제 솔직한 이야기를 해보겠습니다. 에이전트는 동료가 아니며, 이들을 동일하게 취급하는 것이 바로 사고가 발생하는 방식입니다. 사람은 점진적으로 신뢰를 쌓고 모호함 속에서 판단력을 발휘하지만, 에이전트는 첫날부터 명시적이고 기계적으로 강제되는 제한 사항이 필요합니다. 왜냐하면 재시도 루프(retry loop)에 빠진 LLM은 "이것은 좀 이상해 보인다"라는 개념이 없기 때문입니다.

따라서 구현 방식은 이 은유를 뒤집습니다. 동료는 성과 검토(performance review)를 받지만, 에이전트는 정책 객체(policy object)를 부여받습니다. 발송 할당량(무료 플랜은 계정당 하루 200개 메시지 기본 설정), 스팸 탐지, 그리고 모델이 확인하기도 전에 정크 메일을 차단하는 인바운드 규칙 — 이 모든 것은 에이전트 자체의 자율성에 맡기는 대신 계정 자체에 부착됩니다.

에이전트의 메모리(memory)조차 개인적인 특성이 아닌 정책 결정(policy decision)의 영역입니다. 무료 플랜은 받은 편지함의 메일을 30일 동안, 스팸은 7일 동안 보관하며, 보관 기간은 할당량(quotas)을 설정하는 것과 동일한 정책 객체(policy object)를 통해 구성할 수 있습니다. 동료는 자신이 선택한 것을 기억하지만, 에이전트는 당신이 설정한 그대로를 기억합니다.

오프보딩(Offboarding) 또한 이 비유를 깨뜨립니다. 인간은 인수인계와 작별 케이크와 함께 점진적으로 떠납니다. 에이전트는 즉각적이고 완전히 해체되어야 합니다. 권한(grant)을 삭제하면 정체성(identity)도 사라집니다. 동료라는 프레임워크는 정체성과 책임(accountability)을 다룹니다. 이것은 결코 고용에 관한 문제가 아니었습니다.

첫 번째 비인간(non-human) 온보딩하기

퀵스타트(quickstart)를 이용하면 API 키로부터 5분 이내에 작동하는 송수신 메일함을 구축할 수 있는데, 이는 대부분의 기업이 노트북을 지급하는 속도보다 빠릅니다. 이미 운영 중인 에이전트—심지어 리스크가 낮은 에이전트라도—를 위해 계정을 프로비저닝(provision)하고, 그 출력물에 이름이 붙었을 때 무엇이 변하는지 주의 깊게 살펴보십시오. 제 경험상 감사(audit) 관련 대화는 짧아지고, "잠깐, 누가 이걸 보냈지?"라는 대화는 완전히 사라집니다.

당신의 에이전트는 자신만의 정체성을 가지고 있습니까, 아니면 여전히 당신의 정체성을 빌려 쓰고 있습니까?