다른 언어：繁體中文｜日本語｜English

2026년 9월 22일, Notion Mail의 Inbox가 공식적으로 서비스를 종료합니다. 공지만 보면 수명이 짧았던 또 하나의 Email Client가 사라지는 일로 이해하기 쉽습니다. 하지만 메일 분류, 자주 쓰는 답장, Email-to-Task, 프로젝트 프로세스까지 Notion Mail에 넣어 둔 사용자에게 실제로 옮겨야 하는 것은 처음부터 메일만이 아니었습니다. Email 자체는 대부분 Gmail에 남아 있습니다. 문제는 지난 1년여 동안 조금씩 자리 잡은 분류 규칙, Snippets, Custom Views, 알림, 그리고 메일을 다른 워크플로와 연결하는 방식입니다.

9월 1일에는 r/Notion에 이 상황을 잘 보여 주는 질문이 올라왔습니다. 글쓴이는 정말 아쉬운 기능이 AI 자동 메일 작성이 아니라, Email을 클릭 한 번으로 Notion Task Database에 보내는 흐름과 이미 설정해 둔 Snippets라고 분명히 밝혔습니다. 지금은 무료이면서 Web-based인 대체 도구를 찾고 있지만 완전히 같은 조합을 찾기 어렵다고 합니다. 이 사례는 단순히 “어떤 Email App이 Notion Mail과 가장 비슷한가”라고 묻는 것보다 문제를 더 잘 설명합니다. 사라지는 것은 메일 수신 기능이 아니라 이미 일상 업무에 자리 잡은 일련의 작업 방식이기 때문입니다.

Notion이 밝힌 종료 이유도 명확합니다. Notion Agents가 할 수 있는 일이 늘면서 정리, 답장, Inbox 관리를 Agent에게 직접 맡기는 사람이 점점 많아졌습니다. 현재 Notion Mail 사용자의 절반 이상이 Inbox를 전혀 열지 않고도 메일을 처리할 수 있기 때문에, 회사는 “Agents가 Inbox를 관리하게 하는” 방향에 자원을 집중하기로 했습니다.

그렇다고 기존 Inbox의 가치가 사라졌다는 뜻은 아니며, 이 수치만으로 나머지 절반의 사용자가 모두 Notion Mail에 크게 의존한다고 추론할 수도 없습니다. Notion은 전체 활성 사용자 수, 유지율, 매출을 공개하지 않았으므로 현재로서는 제품 실패인지, 자원 배분 문제인지, 단순한 전략 전환인지 판단할 수 없습니다. 확실한 점은 Notion이 Email을 독립적인 조작 화면에서 Agent가 검색하고 분류하고 초안을 만들며 작업을 실행할 수 있는 업무 소스로 다시 배치하고 있다는 사실입니다.

Notion Mail은 언제 종료될까? Skiff부터 Notion Mail까지 전체 타임라인

정식 출시부터 종료까지 약 17개월, 18개월이 아니다

Notion과 Email을 둘러싼 이 역사는 2024년 2월 9일부터 살펴볼 수 있습니다. 당시 Notion은 개인정보 보호 중심의 커뮤니케이션·협업 서비스 Skiff를 인수했습니다. 이후 Skiff Mail, Pages, Drive, Calendar는 2024년 8월에 서비스를 종료했고, 일부 사용자의 Mail Forwarding은 2025년 2월까지 이어졌습니다.

2024년 10월 24일, Notion은 Make with Notion 행사에서 Notion Mail Preview를 처음 공개했으며 당시에는 여전히 coming soon으로 표시되어 있었습니다. 전면 출시는 2025년 4월 15일이었고, AI Auto Labels, Custom Views, Snippets, Notion Calendar 예약 발송, AI Email Drafting을 주요 기능으로 내세웠습니다.

2026년 6월 25일, Notion은 Notion Mail Inbox 종료를 발표하고 Notion Mail에만 존재하는 데이터를 사용자가 내보낼 수 있도록 했습니다. 9월 21일이 마지막 저장 기한이며, 9월 22일에는 Web, Desktop, iOS 버전이 모두 서비스를 중단합니다. 2025년 4월 정식 GA부터 종료까지는 약 17개월이고, 2024년 10월 Preview부터 계산하면 23개월에 가까우므로 기존의 “18개월 제품 수명”이라는 표현은 정확하지 않습니다.

Notion은 왜 Mail을 종료할까? 공식이 밝힌 실제 이유는 AI Agent

절반이 넘는 사용자가 Inbox를 열지 않고 메일을 처리한다

Notion은 종료 공지에서 중요한 이용 행태 데이터를 공개했습니다. 현재 Notion Mail 사용자의 절반 이상이 Inbox를 열지 않고 Email을 관리할 수 있습니다. 공식이 제시한 상황에는 어떤 메일을 확인해야 하는지 Agent가 정리하고, 메시지에 답장하며, 받은편지함을 깔끔하게 유지하는 일이 포함됩니다. 이에 따라 회사는 독립적인 Mail Inbox를 계속 유지하는 대신 Agents에 방향을 집중할 예정입니다.

이는 Notion이 2026년 상반기에 보여 준 제품 방향과도 이어집니다. 5월 13일 Developer Platform을 출시했을 때 Notion은 팀들이 이미 100만 개가 넘는 Custom Agents를 만들어 Slack Q&A, 주간 보고서, 업무 분류 등에 사용하고 있다고 밝혔습니다. 이후 Workers, External Agents와 기타 개발 기능을 내놓으며 Agent가 더 많은 외부 시스템과 사용자 지정 로직에 접근할 수 있도록 하려 했습니다.

하지만 시기가 맞물린다고 해서 “Developer Platform을 출시했으니 Mail 종료가 필연적이었다”는 뜻은 아닙니다. Notion은 그런 내부 의사결정 과정을 공개하지 않았습니다. 더 정확한 해석은 두 발표가 같은 제품 방향을 보여 준다는 것입니다. Notion은 Agent가 데이터를 직접 읽고 업무를 실행하는 능력을 강화하고 있으며, 이런 방향에서는 사람이 계속 Inbox에 머물며 Email을 정리해야 하는 기존 인터페이스의 중요성이 낮아졌습니다.

Notion Mail 종료 후에도 남는 데이터는?

받은 Email과 보낸 Email 자체는 사라지지 않는다

Notion Mail은 계속 Gmail과 양방향으로 동기화해 왔으므로 이미 받은 Email과 보낸 Email은 원래 Gmail에 존재합니다. 9월 22일 Notion Mail이 종료된 뒤에도 이 메일들은 기존 Gmail Inbox에 남습니다. 과거 메일을 보존하기 위해 별도로 전체 Mail Export를 할 필요는 없습니다.

또한 이미 Notion Page에 넣은 Mail Blocks는 Mail App이 종료되어도 사라지지 않습니다. Gmail AI Connector도 계속 작동하므로 Notion AI가 Gmail을 검색하거나 Draft Reply를 돕는 데 사용할 수 있습니다. Gmail 연결을 통한 Agent Mail Tools 역시 Notion Mail Inbox 종료의 영향을 받지 않습니다.

놓치기 쉬운 예외는 Synced Notion Mail Database Views입니다. 현재 Notion에 동기화된 Email Records와 기존 Filtered Views는 남지만, 9월 22일 이후에는 새로운 Email이 더 이상 동기화되지 않습니다. 따라서 View 자체는 사라지지 않지만 데이터는 종료 당일 상태에 머물고 더 이상 업데이트되지 않습니다.

9월 21일까지 별도로 저장해야 하는 Notion Mail 데이터는?

Drafts, Scheduled Emails, Snippets, Auto Label Instructions는 Notion Mail에만 존재한다

공식은 9월 21일까지 처리해야 할 데이터 네 가지를 제시했습니다. Drafts는 Gmail로 이전해야 하고 Scheduled Emails도 마찬가지로 Gmail로 옮겨야 합니다. Snippets의 텍스트 내용은 내보내고 Auto Label Instructions도 별도로 저장해야 합니다. 이 데이터가 9월 22일에도 Notion Mail에만 남아 있다면 종료 후 영구 삭제됩니다.

여기서 “예약 시간이 모두 완전하게 자동 이전되므로 Gmail에서 확인만 하면 된다”고 단정해서는 안 됩니다. 공식이 보장한 것은 Migrate scheduled emails to Gmail 기능을 제공한다는 점뿐이며, 모든 예약 상태, 시간 설정, 특수 조건이 그대로 이전된다고 설명하지는 않았습니다. 이전을 마친 뒤 Gmail의 Scheduled Folder를 다시 확인하는 편이 안전하지만 이는 사용상의 권장 사항이지 공식 보장은 아닙니다.

내보내도 옮길 수 없는 Notion Mail 설정은?

Custom Views, Snippet 첨부 파일, Email Reminders는 따로 처리해야 한다

Notion은 다른 Email App으로 직접 옮길 수 없는 데이터 세 가지를 명확히 밝혔습니다. 첫 번째는 Custom Views와 Sorting을 포함한 Inbox 정리 방식입니다. 두 번째는 Snippets에 첨부된 파일로, 이 첨부 파일은 Snippet Text와 함께 자동으로 내보내지지 않으므로 Notion Mail → Settings → Snippets에서 개별적으로 내려받아야 합니다. 세 번째는 Email에 설정한 Reminders이며 현재 Gmail로 이전할 수 없습니다.

이 세 가지 정보는 Notion Mail 종료 후 “다른 App이 그대로 이어받게” 만들기 가장 어려운 부분이기도 합니다. Email 자체에는 표준 프로토콜이 있고 Gmail이 기반 데이터로 존재하지만, View를 어떻게 배치하는지, 언제 알림을 보내는지, 어떤 답장 템플릿에 어떤 첨부 파일을 넣는지는 원래 Notion Mail만의 Product Logic입니다.

따라서 실제로 저장해야 하는 것은 데이터뿐만 아니라 로직입니다. Custom View를 Export할 수 없다면 Filters, Sorts, Groups, 사용 목적을 글로 기록할 수 있습니다. 아직 유효한 Email Reminder는 Calendar나 Task System에 다시 만들 수 있습니다. Snippet Attachment는 종료 전에 내려받아 Snippet Text만 남는 일이 없도록 해야 합니다.

커뮤니티에서 Notion Mail과 완전히 같은 대안을 찾기 어려운 이유는?

부족한 것은 Email Client가 아니라 이미 하나로 묶인 업무 방식이다

9월 1일 r/Notion에 올라온 질문은 문제를 매우 분명하게 설명합니다. 글쓴이가 실제로 의존한 것은 One-click Email-to-Task와 고정 수신자 및 초기 문구가 이미 포함된 Snippets였습니다. AI Drafting은 오히려 부가 기능에 불과했습니다.

6월에 종료 소식이 처음 발표됐을 때 다른 토론에서도 Snippets, Email-to-Notion Task, Ticketing Workflow가 특별히 언급됐고, Email을 Project, Client, Task, Meeting 같은 Notion Context와 직접 연결하고 싶다는 요구도 나왔습니다.

따라서 “무료이고 Web-based이며 Gmail을 받을 수 있는 도구”를 찾는 일은 쉽습니다. 어려운 점은 같은 제품에서 Email Client, Task Bridge, Snippet Library, Custom Views, Notion Database Workflow를 모두 동시에 다시 만드는 것입니다. 사실 각각 다른 문제지만 과거에는 우연히 Notion Mail의 한 화면에 함께 묶여 있었습니다.

Notion Mail 종료 후 Custom Agent가 Auto Labels를 바로 대체할 수 있을까?

비슷한 작업은 가능하지만 기존 규칙이 자동으로 옮겨지지는 않는다

공식 FAQ가 제시한 방법은 먼저 Auto Label Instructions를 Notion Page에 저장하고, 9월 22일 이후 Gmail Access 권한이 있는 Custom Agent를 만든 뒤 해당 Instructions에 따라 비슷한 Labeling Workflow를 실행하게 하는 것입니다. Auto Label Logic을 이어 갈 수 있다는 뜻이지만, 기존 Rule을 클릭 한 번으로 Import해 Agent로 완전히 옮기는 방식은 아닙니다.

현재 Custom Agent의 Mail Connection은 Search, Archive, Star, Delete, Labels 생성·삭제, Unsubscribe, Block Sender를 지원하며 Email을 Draft하고 Send할 수도 있습니다. 기능 면에서는 상당수 Inbox Automation을 다시 만들 수 있습니다.

하지만 이 방법에는 두 가지 제약이 있습니다. 현재 Custom Agents를 사용하려면 Business 또는 Enterprise Plan이 필요하고, 실행할 때마다 Notion Credits를 사용합니다. 읽는 콘텐츠가 많고 실행하는 작업이 많거나 Trigger가 빈번할수록 Credits 사용량도 늘어납니다.

따라서 “Agent로 전환”하는 방법이 모든 Notion Mail 사용자에게 부담 없는 이전 경로는 아닙니다. Free 또는 Plus 사용자가 무료로 쓰던 Mail의 Views, Snippets, 분류 기능을 재현하기 위해 Business로 업그레이드하고 Agent Credits까지 부담한다면 비용 구조는 완전히 달라집니다.

이미 Notion Email Agent를 사용 중이라면 9월 22일 이후에도 작동할까?

Gmail 연결 기반 Agent Mail Tools는 남는다

공식 설명에 따르면 이미 Notion Agents로 Email을 처리하고 있거나 Gmail 또는 Outlook을 Notion Workflow에 연결한 경우, Notion Mail Inbox가 종료된다고 해서 모두 중단되지는 않습니다. Gmail AI Connector, 기존 Mail Blocks, Gmail 연결을 통한 Agent Mail Tools는 계속 사용할 수 있습니다.

여기서 주의해야 할 것은 데이터 소스입니다. 실제로 종료되는 것은 Notion Mail Inbox App이지 Notion의 전체 Email Capability가 아닙니다. 앞으로 Email은 계속 열어 두어야 하는 독립 App이라기보다 Agent와 Notion AI가 사용하는 Connected Source에 더 가까워집니다.

규제 산업은 9월 22일만 기억하면 안 된다. HIPAA 공식 전환 기한은 더 빨랐다

Notion은 Regulated Environment의 경우 일반적인 Shutdown Date보다 먼저 이전을 마쳐야 할 수 있다고 특별히 안내했습니다. 조직이 Notion Mail의 HIPAA Coverage에 의존한다면 공식 계획상 기한은 2026년 6월 30일까지 Transition을 완료하는 것이었습니다. 현재는 9월이므로 이 날짜는 이미 지났습니다.

따라서 의료 또는 명확한 Compliance Requirement가 있는 팀은 9월 21일을 유일한 Deadline으로 생각해서는 안 됩니다. 아직 Notion Mail을 사용 중인 조직은 App이 실제로 종료되기 전날까지 기다리지 말고 내부 Admin, IT, Compliance Team이 기존 데이터와 워크플로를 어떻게 처리했는지 직접 확인해야 합니다.

Notion Mail 종료 전, 9월 21일까지 해 둘 일은?

새 App을 고르기보다 데이터를 먼저 지켜야 한다

대체 도구를 고르기 전에 확실히 사라지는 내용을 처리해야 합니다. Drafts와 Scheduled Emails를 Gmail로 옮기고, Snippets와 Auto Label Instructions를 내보내며, Snippet Attachments를 수동으로 내려받고, 아직 유효한 Email Reminders를 Calendar 또는 Task System에 다시 기록해야 합니다. Custom Views 자체를 옮길 수 없더라도 각 View의 Filters, Sorting, 용도, 매일 사용하는 방법을 적어 둘 수 있습니다.

워크플로가 Synced Notion Mail Database에 의존한다면 9월 22일이라는 경계도 명확히 표시해야 합니다. 기존 데이터는 볼 수 있지만 새로운 Email은 더 이상 들어오지 않기 때문입니다. 별도의 동기화 흐름을 추가하지 않으면 Database가 사라지는 대신 작업 공간은 겉보기에 정상인 상태로 남아 있다가 며칠 뒤 새로운 메일이 전혀 들어오지 않았다는 사실을 발견하기 쉽습니다.

경로 1: Notion에 남아 Gmail Connector와 Custom Agent로 흐름 재구축

이 경로는 이미 Business／Enterprise를 사용하며 Email을 최종적으로 Notion Projects, Tasks 또는 다른 Database에 넣어야 하는 팀에 적합합니다. 기존 Auto Label Instructions를 Notion에 저장한 뒤 Agent Instructions로 바꿀 수 있고, Mail Connection을 통해 Agent가 Search, Manage Labels, Archive, Draft, Send를 실행하도록 할 수 있습니다.

장점은 Email과 다른 Notion Context가 계속 같은 업무 환경에 남고 공식이 이 제품군에 계속 투자하고 있다는 점입니다. 단점은 Custom Agent가 무료 대체재가 아니며 Triggers, Instructions, Tools & Access를 다시 설계하고 Credits도 관리해야 한다는 점입니다.

또한 Inbox를 직접 정리하던 사용자는 현실적인 차이도 받아들여야 합니다. Agent는 “규칙”을 다시 만들 수 있지만 기존의 시각적 인터페이스를 자동으로 재현하지는 않습니다. Custom Views와 Sorting, Mail을 열면 분류가 끝난 작업 공간을 바로 볼 수 있었던 경험은 사라지는 제품 경험입니다.

경로 2: Gmail로 돌아가 Email과 Notion 워크플로 분리

주요 요구가 Email의 안정적인 송수신, Labels, Search, 간단한 Filters라면 Gmail로 바로 돌아가는 것이 이전 비용이 가장 낮습니다. 과거 Email은 원래 Gmail에 있으므로 Mailbox Migration을 다시 할 필요가 없습니다.

기존 Auto Label Instructions는 Gmail Filters를 다시 만드는 사양으로 사용할 수 있고, 자주 쓰는 답장도 실제 요구에 따라 Gmail Templates로 다시 만들거나 별도의 텍스트 조각으로 저장할 수 있습니다. 다만 어느 쪽도 한 번에 이전되는 것은 아니며, Notion Mail의 AI Label Instructions를 Gmail의 조건형 Filter로 하나씩 그대로 바꿀 수 있다고 보장할 수 없습니다.

이 경로에서 가장 큰 공백은 Email-to-Notion Workflow입니다. Gmail 자체는 클릭 한 번으로 Task로 바꾸거나 Database에 기록하거나 다른 Notion 관계를 만드는 기능을 자동으로 되살려 주지 않습니다. 이것이 원래 가장 중요한 기능이었다면 Notion Worker, Automation, Agent 또는 다른 Integration을 추가로 연결해야 합니다.

경로 3: 타사 Email Client로 이동하되 실제로 보완할 계층부터 확인

핵심 요구가 Custom Inbox Views, Keyboard Workflow, Snippets 또는 빠른 Triage라면 다른 Email Client로 옮기는 것은 합리적입니다. 그러나 제품 Feature List보다 더 중요한 것은 Notion Mail에서 실제로 수행하던 행동을 먼저 적어 보는 일입니다.

예를 들어 Email 자체는 Gmail에 남겨 두고 다른 Client는 화면 표시만 맡길 수 있습니다. Snippets는 다른 Text Expansion Tool로 관리하고 Email-to-Task는 Automation에 맡길 수 있습니다. Notion Mail처럼 모든 것이 한 화면에 있지는 않더라도 각 계층을 따로 교체할 수 있으므로, 다음에 서비스 하나가 종료되더라도 전체 시스템을 다시 옮길 필요가 없습니다.

타사 Client를 평가할 때는 데이터가 여전히 Gmail／IMAP을 Source of Truth로 사용하는지, Rules와 Templates를 Export할 수 있는지, 서비스 종료 후 기본 Gmail로 돌아갈 수 있는지, 권한 범위가 실제 필요 이상으로 넓지 않은지를 특히 확인할 수 있습니다.

가장 남겨야 할 것은 Notion Mail 설정이 아니라 워크플로 사양

이번 Notion Mail 종료에서 가장 까다로운 문제는 Email이 사라지는 것이 아닙니다. 메일 자체는 원래 Gmail에 남아 있습니다. 실제로 옮기기 어려운 것은 “어떤 종류의 메일을 먼저 볼지”, “어떤 발신자를 어느 Project로 보낼지”, “어떤 상황에 어느 답장을 사용할지”, “어떤 내용을 받았을 때 Task를 만들지”처럼 표준 형식이 없는 정보입니다. 이런 규칙이 특정 제품의 설정 화면에만 존재하면 제품이 종료될 때 기억에 의존해 다시 조립할 수밖에 없습니다.

더 현실적인 방법은 중요한 Workflow를 문서 사양으로 남기는 것입니다. 복잡한 SOP를 작성할 필요는 없으며 Input, 분류 조건, 필요한 Action, 마지막 저장 위치를 이해할 수 있으면 됩니다. 이후 Gmail Filter, Custom Agent, Worker, 다른 Email Client 중 무엇으로 옮기든 이 문서를 재구축에 사용할 수 있습니다.

Notion Mail 종료를 “모든 인터페이스 중심 제품이 Agent에 의해 대체될 것”이라고 확대할 필요도 없습니다. 현재 증거로 확인되는 것은 Notion 자체가 Email Workflow를 Agent 쪽으로 옮기고 있고, Notion Mail 사용자의 절반 이상이 Inbox를 열지 않는 방식을 채택했다는 점뿐입니다. 다른 제품도 같은 길을 갈지는 각각의 이용 행태와 비즈니스 모델에 따라 달라집니다.

다만 한 가지는 이미 분명합니다. 도구는 종료될 수 있지만 업무 습관은 자동으로 이사하지 않습니다. 따라서 9월 22일 전에 가장 보존할 가치가 있는 것은 몇 개의 Drafts와 Snippets뿐만 아니라 매일 실제로 사용한다는 사실이 검증된 규칙입니다. 다음 도구의 형태는 나중에 선택하더라도 적어도 기존 업무가 어떻게 돌아갔는지 처음부터 다시 떠올릴 필요는 없습니다.

자주 묻는 질문

SUPPORT FENGNIII

喜歡這篇文章嗎？

如果這篇內容對你有幫助，可以透過小額贊助支持本站持續整理更多日文、韓文、旅行與數位工具內容。

小額支持本站

付款將由藍新金流安全處理