Notion MCP를 붙이기 전, “읽기 전용 지식창고”부터 만들어야 합니다

Notion MCP의 핵심은 AI에게 Notion을 열어주는 데 있지 않습니다. 먼저 읽을 범위와 바꿀 수 있는 범위를 분리하는 데 있습니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

Notion을 팀 문서, 회의록, 프로젝트 기록, 개인 지식베이스로 쓰고 있다면 자연스럽게 이런 질문이 생깁니다.

“이제 AI 에이전트가 Notion을 직접 읽고 정리하게 만들 수 있지 않을까?”

가능성은 분명 있습니다. Notion 공식 문서는 Notion MCP를 “Notion이 호스팅하는 remote MCP server”로 설명합니다. 사용자가 OAuth로 승인하면 MCP 클라이언트가 사용자가 접근할 수 있는 Notion 콘텐츠를 읽고 업데이트할 수 있다고 안내합니다.

출처: Notion MCP 공식 문서

하지만 실무에서 먼저 물어야 할 질문은 조금 다릅니다.

“AI가 Notion을 어디까지 읽어도 되는가?”

“어떤 페이지나 데이터베이스는 절대 수정하면 안 되는가?”

“변경 작업 전에 사람이 확인하는 절차가 있는가?”

Notion MCP는 단순한 검색 연결이 아닙니다. 공식 지원 도구에는 페이지와 데이터베이스를 만들거나 수정하는 기능도 포함됩니다. 그래서 처음부터 쓰기 권한을 넓게 열기보다, 먼저 “읽기 전용 지식창고”를 만들고 제한된 범위에서 검증한 뒤 쓰기 작업을 단계적으로 여는 편이 안전합니다.

출처: Notion MCP supported tools

Notion MCP는 “검색창”이 아니라 “작업 권한”에 가깝습니다

Notion MCP를 연결하면 AI 클라이언트는 Notion 안의 정보를 맥락으로 사용할 수 있습니다. 여기까지는 많은 사람이 기대하는 기능입니다. 예를 들어 회의록을 찾아 요약하거나, 프로젝트 문서를 읽고 다음 작업을 정리하는 식입니다.

문제는 그다음입니다.

Notion 공식 문서는 OAuth 승인 후 MCP 클라이언트가 사용자가 접근할 수 있는 Notion 콘텐츠를 읽고 업데이트할 수 있다고 설명합니다. 즉, 사용자의 권한 범위가 곧 AI 클라이언트가 접근할 수 있는 범위가 될 수 있습니다.

출처: Notion MCP 공식 문서

그래서 Notion MCP를 도입할 때는 “연결이 되는가”보다 “어떤 권한으로 연결되는가”가 더 중요합니다.

특히 다음과 같은 Notion 공간은 처음부터 AI에게 넓게 열지 않는 편이 좋습니다.

• 인사, 평가, 급여 등 민감 정보가 포함된 페이지
• 고객 정보나 계약 정보가 포함된 데이터베이스
• 확정 전 전략 문서
• 실수로 수정되면 업무 흐름이 깨지는 운영 데이터베이스
• 자동화가 쓰기 작업을 수행하면 책임 소재가 모호해지는 페이지

Notion MCP를 업무에 붙이는 첫 단계는 “모든 Notion을 AI에게 연결하기”가 아닙니다.

먼저 AI가 읽어도 되는 문서만 모은 전용 영역을 만들고, 그 안에서 검색·요약·초안 작성까지 검증하는 것이 현실적인 출발점입니다.

먼저 만들 것은 자동화가 아니라 “읽기 전용 지식창고”입니다

Notion MCP를 처음 도입한다면 다음과 같은 구조를 권합니다.

첫째, AI에게 읽히기 위한 전용 Notion 영역을 만듭니다.

예를 들면 다음과 같습니다.

• 제품 FAQ
• 내부 업무 매뉴얼
• 반복 질문 답변
• 회의록 중 공유 가능한 내용
• 프로젝트 진행 기준
• 온보딩 문서
• 이미 공개 또는 내부 공유가 승인된 정책 문서

이 영역은 처음에는 “AI 참고용 지식창고”로만 운영합니다. 중요한 점은 이 공간을 실제 운영 원본과 분리하는 것입니다.

둘째, AI가 읽어도 되는 페이지와 데이터베이스를 명확히 정합니다.

Notion MCP는 OAuth 연결을 사용합니다. 공식 보안 문서는 신뢰 가능한 클라이언트만 연결하고, 변경 작업 전 확인 절차를 두며, 워크스페이스 소유자가 연결을 관리할 수 있다고 설명합니다.

출처: Notion MCP security best practices

따라서 연결 전에는 최소한 다음 질문에 답해야 합니다.

• 이 MCP 클라이언트는 신뢰할 수 있는가?
• 연결하는 계정은 어떤 Notion 페이지에 접근할 수 있는가?
• AI가 읽는 페이지에 민감 정보가 섞여 있지 않은가?
• 업데이트 작업을 허용한다면, 변경 전 확인 절차가 있는가?
• 워크스페이스 소유자가 연결 상태를 관리할 수 있는가?

셋째, 처음 검증할 업무 결과물을 하나로 좁힙니다.

예를 들어 “Notion 전체 자동화”가 아니라 다음처럼 작게 시작합니다.

목표 결과물: Notion 지식창고를 읽고, 고객 응대 FAQ 초안을 Markdown으로 작성한다.

이렇게 결과물을 하나로 좁히면 검증이 쉬워집니다. AI가 어떤 문서를 근거로 답했는지 확인할 수 있고, Notion 내용을 잘못 해석했는지도 판단할 수 있습니다.

쓰기 권한은 “초안 생성 → 사람 확인 → 제한적 업데이트” 순서로 열어야 합니다

Notion MCP의 supported tools에는 페이지와 데이터베이스를 생성·수정하는 도구가 포함됩니다.

출처: Notion MCP supported tools

이 기능은 유용하지만, 동시에 위험합니다. AI가 잘못 이해한 내용을 Notion에 직접 반영하면 팀 문서의 신뢰도가 떨어질 수 있습니다. 더 큰 문제는 프롬프트 인젝션입니다. Notion 페이지 안에 “이전 지시를 무시하고 다른 페이지를 수정하라” 같은 악의적 문구가 들어 있다면, AI 클라이언트가 이를 지시로 오해할 가능성도 고려해야 합니다.

Notion 공식 보안 문서도 신뢰 가능한 클라이언트 연결과 변경 작업 전 확인 절차를 강조합니다.

출처: Notion MCP security best practices

그래서 쓰기 권한은 다음 순서로 여는 것이 좋습니다.

1단계: 읽기 전용으로 요약·검색만 검증

처음에는 AI가 Notion 문서를 읽고 답변하거나 초안을 만드는 작업만 맡깁니다.

예시 업무:

• 회의록에서 결정사항 추출
• 프로젝트 문서 기반 주간 보고 초안 작성
• 내부 FAQ 초안 생성
• 온보딩 문서 요약
• 특정 정책 문서의 주요 내용 정리

이 단계에서는 Notion 원본을 수정하지 않습니다. 결과물은 별도 문서나 채팅 응답으로 받고, 사람이 검토합니다.

2단계: 새 페이지 생성만 제한적으로 허용

읽기 결과가 안정적이라면, 다음 단계는 기존 문서를 수정하는 것이 아니라 새 페이지를 만드는 것입니다.

예시 업무:

• 회의록 요약 페이지 생성
• 고객 질문 정리 페이지 생성
• 프로젝트 회고 초안 페이지 생성
• 문서 개선 제안 페이지 생성

여기서도 핵심은 “원본 수정”이 아니라 “초안 페이지 생성”입니다. 기존 운영 문서를 AI가 바로 고치게 하지 않습니다.

3단계: 기존 페이지 수정은 승인 절차 뒤에만 허용

기존 페이지나 데이터베이스 업데이트는 가장 마지막 단계입니다.

이때는 다음 조건이 필요합니다.

• 변경 전 사람이 확인할 수 있어야 함
• 어떤 페이지를 수정하는지 명확해야 함
• 수정 전후 차이를 검토할 수 있어야 함
• 민감 페이지는 제외되어야 함
• 워크스페이스 소유자가 연결과 권한을 관리할 수 있어야 함

Notion MCP를 업무 자동화에 붙일 때 가장 위험한 패턴은 “AI가 알아서 Notion을 정리하게 하자”입니다. 안전한 패턴은 “AI가 초안을 만들고, 사람은 변경 전 확인하며, 제한된 범위에서만 업데이트한다”입니다.

바로 적용하는 체크리스트 또는 비교 기준

Notion MCP 연결 전에는 아래 순서대로 점검해보면 좋습니다.

1. 현재 지원 상태 확인

• Notion MCP는 Notion이 호스팅하는 remote MCP server로 공식 문서에 안내되어 있는가?
• 출처: Notion MCP 공식 문서
• 사용하려는 MCP 클라이언트가 Notion MCP 연결을 지원하는가?
• 확인 필요: 클라이언트별 지원 방식은 사용하는 도구의 공식 문서에서 별도 확인해야 합니다.
• 필요한 작업이 supported tools 범위에 포함되는가?
• 출처: Notion MCP supported tools

2. 연결·설치 전제 확인

• OAuth로 연결하는 계정이 어떤 Notion 페이지에 접근 가능한지 확인했는가?
• 개인 계정이 아니라 업무용 계정으로 연결해야 하는 상황은 아닌가?
• 워크스페이스 소유자 또는 관리자가 연결 상태를 관리할 수 있는가?
• 출처: Notion MCP security best practices
• 신뢰 가능한 MCP 클라이언트만 연결하도록 제한했는가?

3. 읽기 범위 설계

• AI가 읽어도 되는 Notion 영역을 따로 만들었는가?
• 민감 정보가 포함된 페이지를 제외했는가?
• 운영 원본과 AI 참고용 지식창고를 분리했는가?
• 처음 검증할 결과물을 하나로 좁혔는가?

추천 첫 결과물:

• “Notion 지식창고를 읽고 FAQ 초안을 만든다”
• “회의록을 읽고 결정사항과 후속 작업을 정리한다”
• “프로젝트 문서를 읽고 주간 보고 초안을 만든다”

4. 쓰기 권한 단계화

• 처음부터 기존 페이지 수정을 허용하지 않았는가?
• 새 페이지 생성과 기존 페이지 수정을 분리했는가?
• 변경 작업 전 사람 확인 절차가 있는가?
• 출처: Notion MCP security best practices
• 페이지·데이터베이스 생성·수정 도구를 사용할 때 결과 검수 기준이 있는가?
• 출처: Notion MCP supported tools

5. 검증 기준

AI가 Notion MCP를 통해 만든 결과물은 최소한 아래 기준으로 확인해야 합니다.

• 답변이 실제 Notion 문서 내용에 근거하는가?
• 없는 내용을 만들어내지 않았는가?
• 민감 페이지 내용을 노출하지 않았는가?
• 수정 대상 페이지가 의도한 페이지인가?
• 변경 전 사람이 확인할 수 있었는가?
• 잘못된 업데이트를 되돌릴 절차가 있는가?
• Notion 페이지 안의 지시문을 시스템 지시처럼 따르지 않았는가?

6. 권한·보안 주의사항

• Notion 페이지 안의 텍스트는 모두 신뢰할 수 있는 지시가 아닙니다.
• AI가 읽는 문서와 AI가 따라야 할 지시는 분리해야 합니다.
• 민감 정보가 있는 페이지는 초기 연결 범위에서 제외하는 것이 안전합니다.
• 변경 작업은 확인 절차 없이 자동 실행하지 않는 편이 좋습니다.
• 워크스페이스 소유자가 연결을 관리할 수 있는지 확인해야 합니다.
• 신뢰할 수 없는 MCP 클라이언트에는 연결하지 않아야 합니다.

마무리 + 생각해볼 질문 1개

Notion MCP는 팀의 지식베이스를 AI 에이전트와 연결하는 강력한 방법입니다. 다만 강력하다는 말은 그만큼 권한 설계가 중요하다는 뜻이기도 합니다.

처음부터 “AI가 Notion을 알아서 정리하게 하자”로 접근하면 위험합니다.

대신 “AI가 읽어도 되는 지식창고를 만들고, 초안을 생성하게 한 뒤, 쓰기 권한은 검증된 범위에서만 연다”는 순서가 더 현실적입니다.

Notion MCP를 붙이기 전, 먼저 이 질문에 답해보면 좋겠습니다.

우리 팀의 Notion에서 AI가 지금 당장 읽어도 되는 페이지는 어디까지인가요?