目錄
정상적으로 작동하던 Notion AI MCP 워크플로가 8월 말 갑자기 첫 번째 Tool Call에서 멈췄습니다. 화면에는 어떤 도구의 operation type이 지난 관리자 승인 이후 바뀌었으므로 계속하려면 관리자 승인을 다시 받아야 한다고 표시됐습니다. 더 곤란한 점은 문제를 겪은 여러 워크스페이스에서 오류 메시지가 말하는 재승인 화면을 아예 찾을 수 없었다는 것입니다. MCP를 완전히 제거하고 다시 연결해도 실패한 사례도 있었습니다.
처음에는 Notion이 새로운 MCP 권한 거버넌스 체계를 내놓았는데 프런트엔드 화면이 아직 따라오지 못한 것처럼 보였습니다. 그러나 이후 정보는 그렇게 해석할 수 없음을 보여줬습니다. Notion은 8월 30일 일부 Notion AI MCP Tool Calls가 실패하고 있다고 공식 인정했고, 엔지니어링 팀이 대응한 뒤 같은 날 저녁 정상화됐다고 발표했습니다. 전체 장애는 약 6시간 36분 지속됐습니다. 8월 29일 r/Notion 토론에서도 같은 현상을 볼 수 있습니다. Connections와 Tool List는 모두 정상인데 실제 실행에서만 operation type 오류가 뜬 사람도 있었고, 같은 MCP가 Agent에서는 실행되지만 Notion AI에서는 실패한 경우도 있었습니다.
따라서 이번 사건 자체는 사용자가 갑자기 관리자 승인 한 번을 빠뜨린 것이 아니라 플랫폼 쪽 MCP 실행 장애에 가깝습니다. 그렇다고 오류 메시지에 참고 가치가 전혀 없는 것은 아닙니다. Notion은 실제로 외부 도구를 읽기, 쓰기, 실행 위험에 따라 더 세밀하게 통제하는 방향으로 가고 있습니다. 정확히 구분해야 할 것은 두 가지입니다. 이번 오류가 왜 발생했는지에 대해서는 공개된 기술 RCA가 없습니다. 반면 Notion이 MCP와 Agent 권한 통제를 늘리고 있다는 사실은 공식 제품 문서로 확인할 수 있습니다.
이 글의 정보는 2026년 8월 31일 기준이며, Notion MCP, Custom Agents, Connections 관리 화면은 버전 업데이트에 따라 달라질 수 있습니다.
Notion AI의 “operation type이 변경됐다” 오류에서는 무슨 일이 있었을까?
8월 29일부터 같은 신고가 잇따랐고, 8월 30일 Notion이 MCP Tool Call 이상을 공식 인정
8월 29일 r/Notion에는 원래 정상적으로 쓰던 Notion AI의 MCP Connections가 갑자기 모두 실행되지 않는다는 사용자 신고가 연이어 올라왔습니다. 오류는 모두 도구의 operation type이 지난 Admin Approval 이후 바뀌어 관리자가 다시 승인해야 한다는 내용이었습니다. 한 사례는 whoami를 직접 지목했고, 다른 사용자는 모든 MCP Tool에서 같은 문제가 발생했으며 Connection을 삭제하고 다시 추가해도 나아지지 않았다고 했습니다.
8월 30일 Notion Status는 일부 Notion AI MCP Tool Calls가 실패하고 있다는 공식 장애 공지를 올렸습니다. 엔지니어링 팀이 문제를 확인해 대응했고, 같은 날 22시 49분 복구를 발표했습니다. 이 시간선은 중요합니다. 사용자가 본 “관리자가 다시 승인해야 한다”는 메시지가 반드시 관리자의 설정 누락을 뜻하지 않기 때문입니다. 적어도 이 대규모 사례는 모든 사용자가 각자 Approval Button을 찾아 해결한 것이 아니라 Notion이 플랫폼에서 복구했습니다.
따라서 같은 메시지를 만났을 때 첫 행동은 전체 자동화를 즉시 재구축하는 것이 아니어야 합니다. 먼저 Notion Status와 커뮤니티에 같은 시간대의 대량 신고가 있는지 확인해야 합니다. 서로 무관한 여러 MCP Server가 동시에 실패하고 Authentication과 Tool Discovery는 정상이라면, 문제를 하나의 Connection 탓으로 먼저 돌리는 것은 적절하지 않습니다.
operation type은 정확히 무엇일까? MCP의 Read／Write 필드와 바로 같은 것으로 볼 수 없다
MCP에는 도구 동작 표지가 있지만 Notion은 이 오류가 어느 필드에 대응하는지 공개하지 않았다
MCP Tool Definition에는 도구 이름, 설명, Input Schema 외에 annotations를 넣을 수 있습니다. 여기에는 readOnlyHint, destructiveHint, idempotentHint, openWorldHint가 포함됩니다. 이 정보는 MCP Client에 어떤 Tool이 읽기 전용인지, 데이터를 수정·파괴할 수 있는지, 외부 세계와 접촉하는지 알려줄 수 있습니다.
하지만 MCP 사양 자체가 Annotation은 Hint이지 안전 보장이 아니라고 강조합니다. Client도 신뢰할 수 없는 Server의 설명을 무조건 믿어서는 안 됩니다. 더 중요한 것은 Notion의 공개 문서에 오류 메시지의 operation type이 readOnlyHint와 같다는 설명이 없다는 점입니다. Tool Annotation, Input Schema 또는 다른 Tool Definition의 어떤 변경이 반드시 재승인을 유발하는지도 문서화되어 있지 않습니다.
따라서 원고의 “서버가 Read에서 Write로 바뀌면 기존 Approval이 무효화된다”는 설명은 위험을 이해하는 예로는 쓸 수 있지만, 이번 사고에서 확인된 기술 원인이라고 쓸 수는 없습니다. whoami가 차단됐다는 사실도 Notion이 선언 변경 여부만 비교했다는 증거가 아닙니다. 장애 기간에 False Blocking이 대량으로 발생했고, Notion도 결국 플랫폼에서 복구했기 때문입니다.
Notion은 실제로 MCP 도구를 Read와 Write로 나누고, Write를 기본적으로 더 엄격하게 관리한다
Custom Agent의 MCP Tools를 하나씩 통제할 수 있다
이번 장애로 operation type의 내부 구현을 증명할 수는 없지만, 현재 Notion Custom Agents에는 MCP Tool Risk가 사용자가 볼 수 있는 설정으로 구현되어 있습니다. Custom Agent의 Settings → Tools & Access를 열고 MCP Connection을 펼치면 Server가 제공하는 Tools를 확인하고 하나씩 켜거나 끌 수 있습니다.
Notion은 이를 Read Tools와 Write Tools로 나눕니다. Search, Fetch, List, View처럼 주로 정보를 가져오는 도구는 Read입니다. Create, Update, Delete, Send, Post 등 외부 데이터를 바꾸는 도구는 Write입니다. Read Tool은 자동 실행으로 설정할 수 있지만 Write Tool은 기본적으로 사용자 확인이 필요합니다. Agent가 사람의 확인 없이 외부 시스템 데이터를 바로 수정하거나 삭제하지 못하게 하기 위해서입니다.
이것이 현재 공식 문서로 뒷받침되는 “Operation Risk Control”입니다. Tool이 데이터를 바꿀 수 있는지에 따라 Human Confirmation 필요 여부가 달라진다는 개념은 오류 메시지와 분명 가깝습니다. 그러나 여기서 더 나아가 “8월 29일 사고는 Notion이 모든 Tool의 Operation Type 변경을 찾아내 제대로 전부 막은 것”이라고 할 수는 없습니다.
Read Tool과 Write Tool은 왜 나눠야 할까?
AI Agent와 고정 자동화의 가장 큰 차이는 모델이 스스로 Tool Call을 선택할 수 있다는 점
기존 Automation은 보통 Form을 받으면 Database Record를 만든 뒤 Email을 보내는 식으로 흐름이 미리 고정됩니다. 배포 전에 각 단계가 무엇을 할지 이미 압니다. Agent는 다릅니다. 사용자는 목표를 제시하고, 모델은 당시 Context에 따라 Search, Fetch, Create, Update, Send 등의 Tools를 스스로 선택할 수 있습니다.
Agent에게 Search와 Fetch만 있다면 판단이 틀려도 주된 위험은 잘못된 데이터를 읽거나, 엉뚱한 Context를 가져오거나, 사용하면 안 되는 정보를 답변에 넣는 데 머무는 경우가 많습니다. 같은 Agent가 Update, Delete, Send, Post 같은 Tool까지 가지면 오류가 정식 Database 수정, Email 발송, 데이터 삭제 같은 외부 Side Effect로 곧장 이어질 수 있습니다.
이것이 Notion이 Prompt Injection 보안 문서에서 최소 권한을 반복해서 요구하는 이유입니다. 공식 권고는 Sensitive Workflow에 정말 필요한 Page, Database, Tool만 제공하고, 외부 Tool이 쓸 필요가 없으면 Read-only를 유지하며, Read-only가 아닌 Tool에는 Human Confirmation을 남기라는 것입니다. AI가 더 많은 일을 할수록 보안 통제도 “이 Connection을 연결할 수 있는가”에서 “이 Tool을 자동 실행할 수 있는가”까지 세분화돼야 합니다.
Notion MCP의 OAuth 권한은 얼마나 넓을까?
Hosted Notion MCP는 기본적으로 로그인 사용자의 해당 Workspace 권한을 따른다
Hosted MCP에 대한 Notion의 공식 설명은 분명합니다. MCP Tools는 로그인한 사용자가 원래 가진 Notion Permissions로 작동하며, AI Tool은 연결된 Workspace에서 그 사용자가 원래 접근할 수 있는 내용을 읽고 쓸 수 있습니다. 이는 기존 Notion API Integration에서 흔한 Page-level Sharing 방식과 크게 다릅니다. Hosted MCP는 User-based OAuth이며 Claude, Cursor, ChatGPT 같은 AI Client가 현재 사용자 신분으로 Notion을 다루게 하는 것이 주된 목적입니다.
따라서 “Hosted Notion MCP를 연결한다”는 것을 Agent에 작은 Database 하나만 열어 주는 일로 이해해서는 안 됩니다. OAuth 사용자가 Projects, Clients, Meeting Notes와 다른 Private Pages에 접근할 수 있다면, Notion MCP에 연결한 AI Client도 원칙적으로 같은 권한 범위에서 작업할 수 있습니다.
정말 좁은 데이터 경계가 필요한 Workflow에서 Prompt에 “다른 페이지를 보지 마라”라고 한 줄 쓰는 것만으로 부족한 이유도 여기에 있습니다. 고정 프로그램이 특정 데이터베이스 몇 개만 처리해야 한다면 기존 Notion API Integration이 명확한 Page／Database Access Boundary를 만들기 더 쉬울 수 있습니다. Hosted MCP를 쓴다면 로그인 신분 자체의 권한도 위험 평가에 넣어야 합니다.
Enterprise MCP Governance는 AI App과 Client를 관리하며, 이번 오류의 개별 Tool Approval과는 다르다
Enterprise는 Approved AI Apps 목록을 만들 수 있다
현재 Notion Enterprise는 Settings → Connections에서 어떤 외부 AI App과 MCP Client가 워크스페이스에 연결할 수 있는지 관리합니다. 관리자는 모드를 Approved List로 바꾸고 Claude, Cursor, ChatGPT 또는 기타 MCP 지원 Client를 명시적으로 허용할 수 있습니다. 승인받지 않은 도구는 과거 Token을 받은 적이 있어도 Notion이 이후 Call을 차단합니다.
관리자는 Disconnect All Users로 기존 Notion MCP Connections를 모두 무효화할 수도 있습니다. 이후 사용자는 다시 Authentication을 해야 하며 현재 승인된 AI App을 통해서만 재연결할 수 있습니다. 기업이 Okta 같은 지원 Identity Provider를 사용하면 관리자가 Enterprise-managed Connection을 만들어 구성원별 OAuth 절차를 줄일 수 있습니다.
이 기능은 “어떤 AI App이 Notion MCP에 연결할 수 있는가”를 다룹니다. Custom Agent의 Tools & Access는 “특정 Agent가 어느 MCP Tools를 쓸 수 있으며 실행할 때 확인이 필요한가”를 다룹니다. 두 층을 모두 Approval이라고 부르기 때문에 섞기 쉽지만 같은 기능이 아닙니다.
현재 공식 공개 문서에는 “Tool Operation Type이 바뀌면 여기에서 단일 Tool을 다시 Approve하라”라고 적힌 Enterprise 페이지가 없습니다. 따라서 8월 말 오류 메시지가 관리자에게 Module Settings에서 재승인하라고 했더라도, 기존 Enterprise Connections 문서로 공식 문서에 없는 작업 절차를 만들어 낼 수는 없습니다.
Custom MCP Server에는 또 다른 권한 체계가 있다
Business와 Enterprise는 Custom Agent를 사용자 지정 MCP에 연결할 수 있지만 먼저 Admin이 설치 허용 여부를 결정한다
Notion Custom Agents는 미리 통합된 MCP Connections뿐 아니라 사용자 지정 Hosted MCP Server에도 연결할 수 있습니다. Custom MCP를 사용하려면 Workspace Admin이 먼저 Custom MCP Servers를 허용해야 하며, 이후 구성원이 자유롭게 Connection을 설치할지 또는 Approved Connections 목록에서만 고를지 결정할 수 있습니다.
실제로 Connection을 만들면 각 Custom Agent가 자기 MCP Connection을 가지며, 처음 Authentication을 실행한 사용자의 외부 서비스 Credentials를 사용합니다. Connection은 Agent 사이에서 자동 공유되지 않습니다. Agent A가 Figma에 로그인했다고 Agent B가 같은 Connection을 자동으로 받는 것은 아닙니다.
놓치기 쉬운 권한 효과도 하나 있습니다. 어떤 사용자가 Custom Agent에 충분한 권한을 가지면 본인이 외부 서비스에 따로 로그인하지 않았어도 Agent를 통해 이미 연결된 MCP Tools를 사용할 수 있습니다. 따라서 MCP Connection의 Authentication 신분, Agent를 누가 쓸 수 있는지, Tool 자체가 무엇을 할 수 있는지라는 세 층을 함께 봐야 합니다.
8월 말 사고는 왜 거버넌스 체계 업데이트로 오해받았을까?
오류 메시지가 실제로 조작할 수 있는 정책처럼 너무 구체적이었다
사용자가 본 문장은 매우 구체적이었습니다. Tool의 operation type이 바뀌었고 Admin이 다시 승인해야 한다는 내용입니다. 문제는 화면에 대응하는 재승인 메뉴가 없고 재Authentication도 반드시 효과가 있는 것은 아니었다는 점입니다. 이런 메시지는 시스템이 과거보다 엄격해졌을 뿐이라고 오해하게 만들기 쉽지만, 실제로 당시에는 위험 변경이 없었던 Tool Call까지 함께 차단될 수 있었습니다.
이후 시간선이 상황을 더 명확히 했습니다. Notion은 “MCP Governance 업데이트 안내”를 발표한 것이 아니라 Status 시스템에 Incident를 만들었습니다. 제목도 일부 Notion AI MCP Tool Calls가 실패하고 있다고 직접 적었고, Engineering Team이 처리한 뒤 복구했습니다. 따라서 이번 일을 서비스 장애로 규정하는 것이 가장 합리적입니다.
그렇지만 이 사고는 평소 보이지 않는 보안층을 뜻밖에 드러냈습니다. Notion AI의 Tool Runtime은 “Server가 Tool을 제시하면 모델이 원하는 순간 바로 실행”하는 구조만은 아닌 것이 분명합니다. Client, Connection, Tool Risk, Confirmation 사이에 추가 Policy Check가 적어도 하나 더 존재하며, 이번에는 그중 한 층이 잘못 작동해 합법적인 Tool Call도 막은 것으로 보입니다.
Hosted Notion MCP가 기존 Local MCP Server를 대체하고 있을까?
Remote 버전이 공식 주력이며 이전 Open-source Server는 적극적인 유지보수가 중단됐다
Notion이 처음 내놓은 것은 직접 내려받아 배포할 수 있는 notion-mcp-server였습니다. 기존 Notion API Endpoint를 MCP Tools 묶음으로 바꾸는 방식이었습니다. 이후 Notion은 직접 Hosted하는 Remote MCP Server를 내놓고 OAuth 연결을 채택했습니다. Tool Interface도 API를 일대일로 감싼 것에 그치지 않고 Agent에 적합한 Search, Fetch, Create Pages, Update Page 등의 작업으로 따로 설계됐습니다.
현재 공식 GitHub Repository는 팀이 Remote Notion MCP만 적극 지원하며, 기존 Local Server는 앞으로 Sunset될 수 있고 Repository의 Issues와 Pull Requests도 적극 처리하지 않는다고 명시합니다. 공식 Developer Docs도 Local Server를 Last Resort로 분류하며, Headless Workflow가 Bearer Token을 꼭 써야 하지만 User OAuth를 마칠 수 없는 경우에만 사용 이유가 남을 수 있다고 설명합니다.
Hosted Server의 또 다른 차이는 Notion이 업데이트를 통제한다는 점입니다. 사용자가 각자 npm Package를 갱신하지 않아도 Notion이 Server가 제공하는 Tool, Descriptions, 내부 구현을 직접 바꿀 수 있습니다. Notion-flavored Markdown도 Agent가 페이지를 읽고 쓸 때 깊게 중첩된 Block JSON을 반복 처리하지 않게 해, 일반 작업을 더 적은 Tool Calls와 Tokens로 끝낼 수 있습니다.
그러나 이 장점은 Tool Surface가 서비스 쪽에서 계속 진화한다는 뜻이기도 합니다. 8월 말 사고가 실제 Hosted Tool Definition Change로 발생했는지는 공식 RCA가 없으므로 확인된 원인이라고 쓸 수 없습니다. 다만 Hosted Model이 Tool 업데이트 속도를 높이고, 이 Tools에 의존하는 워크플로가 서비스 상태와 Schema Change를 외부 의존성으로 관리할 필요가 더 커졌다고는 말할 수 있습니다.
Notion MCP에서 갑자기 operation type 오류가 날 때 어떻게 점검할까?
첫 단계는 Notion Status 확인이며 Connection 전체를 먼저 해체하지 않는다
Tool List가 남아 있고 Authentication도 정상인데 모든 Tool Call에서 같은 Policy／Approval Error가 갑자기 뜬다면, 먼저 Notion Status에서 Notion AI, MCP 또는 Connections 장애가 있는지 확인합니다. 8월 30일 사례가 전형적이었고 당시 재연결은 모든 사례를 해결하지 못했으며 결국 Notion의 플랫폼 복구가 필요했습니다.
두 번째는 모든 Tool이 실패하는지, 특정 Connection 또는 특정 Tool만 실패하는지 확인
Custom MCP Server 하나만 실패하고 다른 MCP는 정상이라면 Server Authentication, Tool Definition 또는 Credential 문제일 가능성이 큽니다. Search, Fetch, Whoami처럼 무관한 Tool이 함께 실패하고 다른 Server에서도 같은 메시지가 뜬다면 하나의 Tool 동작이 정말 갑자기 변한 상황일 가능성은 낮습니다.
서비스가 정상화된 뒤 Authentication을 다시 진행
Notion 공식 MCP Troubleshooting은 Authentication 문제가 있을 때 Disconnect／Clear Authentication 후 OAuth를 다시 완료하라고 안내합니다. 이 단계는 Status가 정상인데 문제가 하나의 Connection에만 남아 있을 때 적합합니다. 플랫폼 장애 중 Connection을 계속 재구축하라는 뜻은 아닙니다.
Custom Agent라면 Tools & Access를 직접 확인
Custom Agent는 Settings → Tools & Access에서 MCP Server가 제공하는 Tools, 현재 Enabled된 항목, 각 Tool이 Run Automatically, Always Ask, Always Allow 중 무엇인지 볼 수 있습니다. 실제로 데이터를 쓰고 삭제하고 보내는 Tool은 확신이 없을 때 확인 단계를 남기는 편이, 완전 무인화를 위해 모두 Always Allow로 만드는 것보다 훨씬 안전합니다.
실제 쓰기 워크플로에는 복구 지점을 남긴다
정식 데이터베이스 업데이트, 외부 메시지 발송, 삭제를 하는 Workflow에서 Agent의 쓰기를 모두 금지할 필요는 없습니다. 하지만 Write Tool에 Human Confirmation을 유지하거나, Agent를 지정 Database로 제한하거나, 대량 수정을 먼저 Draft／Suggested Edits로 만든 뒤 확인 후 적용하는 등 오류를 발견하고 복구할 수 있는 설계는 필요합니다.
8월 28일 Notion은 Agent가 먼저 줄 단위 수정안을 제시하고 사람이 하나씩 승인할 수 있는 Suggest Edits를 추가했습니다. 품질 통제가 필요한 문서형 Workflow에서는 Agent가 직접 전부 고친 뒤 Audit Log로 오류를 찾는 것보다 이런 설계가 보통 더 쉽게 통제됩니다.
직접 개발한 MCP Server의 Tool Definition은 어떻게 바꾸는 편이 안전할까?
Breaking Change는 명확히 버전 관리하는 편이 좋지만 Client의 재확인을 영원히 막는다고 보장할 수는 없다
MCP Tool Name은 Client가 Tool을 알아보는 중요한 식별자입니다. 기존 Tool이 단순 조회에서 외부 데이터를 수정하는 기능으로 바뀌었는데도 똑같은 이름과 설명을 계속 사용하면 기존 Prompt, Agent Policy, Approval Assumption이 모두 실제와 어긋나기 쉽습니다. 따라서 사용자 지정 Server에 명확한 Behavioral Breaking Change가 있다면 새 Tool Name을 만들거나, 적어도 Version, Description, Annotation을 함께 조정해 호출 측이 다시 평가할 기회를 주는 방식을 고려할 수 있습니다.
하지만 이를 “이름만 바꾸면 Notion의 operation type Error를 다시 만나지 않는다”라고 포장할 수는 없습니다. Notion은 내부 Approval Cache 규칙을 공개하지 않았으므로 Tool Name, Schema, Annotation 가운데 어느 변경이 재확인을 요구하는지 의존할 수 있는 공식 계약은 없습니다.
확실한 것은 MCP 사양이 readOnlyHint, destructiveHint, idempotentHint, openWorldHint 같은 동작 설명을 제공하며 Server Author가 이를 올바르게 채워야 한다는 점입니다. Client는 여전히 이를 Hint로 보고 Server의 자기 선언만으로 실제 보안 경계를 만들어서는 안 됩니다.
Notion MCP와 Notion API는 무엇이 다를까?
MCP는 AI가 도구를 스스로 고르는 데 적합하고, API는 고정적이고 예측 가능한 프로그램 흐름에 적합하다
Notion MCP의 핵심 장점은 Agent-friendly하다는 점입니다. AI Client는 먼저 Tools를 Discover하고 자연어 요구에 따라 Search, Fetch, Create Pages, Update Page 작업을 스스로 조합할 수 있습니다. Remote MCP는 Notion-flavored Markdown과 Notion AI Semantic Search도 이용해, 대량 페이지 작업을 Block JSON으로 직접 처리하는 것보다 LLM에 더 적합합니다.
Notion API는 결정론적인 Backend Workflow에 더 적합합니다. 프로그램이 명확한 Endpoint를 직접 호출하고 Authentication, 입출력, 오류 처리를 개발자가 통제할 수 있습니다. File Upload API처럼 MCP에 아직 없는 기능도 쓸 수 있습니다. Remote Notion MCP는 User-based OAuth를 사용하며 현재 Bearer Token을 지원하지 않아 사람이 전혀 없는 Headless Automation에 꼭 맞는 것은 아닙니다. 고정된 Server-to-server 워크플로라면 여전히 API Integration을 평가해야 합니다.
따라서 둘 중 하나가 다른 하나를 대체하는 관계는 아닙니다. 요구가 “AI가 Context에 따라 스스로 자료를 찾고 다음 동작을 판단한다”라면 MCP가 자연스럽습니다. 요구가 “매일 아침 8시에 A Database의 세 필드를 B에 동기화한다”라면 기존 API나 Worker가 보통 더 테스트하기 쉽고, Agent Decision을 흐름에 넣을 필요도 적습니다.
이번 사고에서 실제로 바꿔야 하는 것은 모든 Write Tool을 없애는 일이 아니다
8월 말의 operation type Error는 결국 Notion AI MCP 서비스 장애로 확인됐습니다. 개인 워크스페이스에서 Approval Button 하나를 누르지 않은 일이 아니며, 영향을 받은 모든 MCP Server가 같은 날 Tool 동작을 실제로 바꿨다는 증거도 없습니다. 이 부분을 잘못 쓰면 뒤이어 “Notion이 MCP 전체를 재승인제로 바꾸고 있다”는 추론도 모두 빗나갑니다.
그러나 오류 메시지가 진짜처럼 들린 것은 현재 Notion의 제품 방향과 관련됩니다. Enterprise에는 AI App Allowlist가 있고 Custom Agents는 Tool별 Read／Write와 Confirmation을 설정할 수 있으며, Prompt Injection 문서는 Least Privilege와 Human Confirmation을 핵심 방어선으로 반복해서 제시합니다. AI Agent가 실제로 데이터를 바꿀 수 있게 되면서 Tool Permission이 세분화되는 흐름은 이미 일어나고 있습니다. 다만 이번 Incident가 그 추세의 공식 발표였던 것은 아닙니다.
Notion Automation이나 MCP 워크플로에 의존하는 사람에게 다음 준비는 이 Error Message를 외우는 것이 아닙니다. 어느 Workflow가 Read만 하는지, 어느 것이 Write하는지, 어느 것에 사람이 반드시 있어야 하는지, 어느 것이 하나의 MCP Service Failure 때문에 완전히 멈춰서는 안 되는지 나누는 일입니다. 이렇게 하면 다음 플랫폼 업데이트나 서비스 장애에서 공급자 복구를 기다려야 하는지, 자기 Connection을 고쳐야 하는지 판단할 수 있습니다.
자주 묻는 질문
반드시 그런 것은 아닙니다. 2026년 8월 29~30일 이 메시지가 대량으로 나타났을 때 Notion은 일부 Notion AI MCP Tool Calls의 장애를 공식 확인하고 플랫폼에서 복구했습니다. 따라서 당시 사례는 “관리자 미승인”으로 설명할 수 없습니다. 이후 한 워크스페이스에서 같은 메시지가 다시 보인다면 먼저 Status와 Connection 상태를 확인한 뒤 실제 설정 변경이 있었는지 판단해야 합니다.
그렇지 않습니다. 일반적인 Authentication 문제에는 Disconnect 후 OAuth를 다시 하는 방식이 Notion 공식 Troubleshooting에 포함되지만, 8월 말 장애 때는 Connection을 완전히 삭제하고 다시 만들어도 실패했다는 신고가 있었습니다. 플랫폼 Incident가 아직 복구되지 않았다면 반복적인 재인증으로 Server-side Error를 해결하기 어렵습니다.
현재 공식 문서에는 이번 오류 메시지와 완전히 대응하는 “단일 Tool Operation Type Re-approval” 절차가 없습니다. Enterprise에는 AI App／MCP Client Approved List가 있고 Custom Agent는 Tool별 활성화와 Confirmation을 관리할 수 있지만, 둘 다 오류가 언급한 Module Re-approval 화면이라고 직접 볼 수는 없습니다.
연결된 Workspace 안에서 Hosted Notion MCP는 사용자 자신의 Notion Access로 작동하며, 공식 설명도 MCP Tools가 사용자가 원래 접근할 수 있는 내용에 접근한다고 말합니다. 기본적으로 몇 개 Page만 여는 저권한 Integration이 아닙니다. 더 작은 데이터 경계가 필요하면 Authentication을 별도로 설계하거나 고정 Page Scope에 더 적합한 Integration 구조를 사용해야 합니다.
Read Tool은 Search, Fetch, List, View처럼 주로 정보를 가져옵니다. Write Tool은 Create, Update, Delete, Send, Post처럼 외부 시스템을 바꿉니다. Notion은 기본적으로 Write Tool 실행 전에 확인을 요구하며, Read Tool은 위험을 감수할 수 있을 때 자동 실행으로 설정하기 더 적합합니다.
일반적인 사용 사례라면 Hosted Notion MCP를 우선하는 편이 좋습니다. 공식은 Remote Server를 적극 유지하는 버전으로 두고, 기존 Open-source notion-mcp-server는 적극적인 유지보수를 중단했으며 향후 종료할 수도 있다고 밝혔습니다. 다만 Remote MCP는 User OAuth에 의존하고 Bearer Token을 지원하지 않습니다. 완전 무인 Headless Workflow에 Token-based Authentication이 필요하면 Notion API 또는 직접 관리하는 다른 통합을 검토할 수 있습니다.
AI가 자연어에 따라 스스로 검색·읽기하고 다음 Tool Call을 결정해야 한다면 MCP가 더 적합합니다. 고정 일정, 데이터 동기화, 정밀한 권한, File Upload 같은 결정론적 흐름은 Notion API가 보통 더 통제하기 쉽습니다. 두 방식을 함께 쓸 수 있으며 모든 Automation을 Agent Workflow로 바꿀 필요는 없습니다.