Notion은 원래 분류가 쉬운 도구였습니다. 문서, 위키, 회의록, 간단한 데이터베이스, 프로젝트 페이지. 팀마다 쓰는 방식은 달랐지만 대체로 “업무 내용을 모아두는 공간”이라는 설명이면 충분했습니다.

이제는 그 설명만으로는 조금 부족합니다.

Notion은 Developer Platform, API, Custom Agents, MCP integrations, External Agents, Workers, CLI 같은 방향으로 움직이고 있습니다. 여기서 중요한 건 Notion이 갑자기 Zapier나 Make를 대체한다는 이야기가 아닙니다. 더 중요한 건 Notion 안에 이미 AI 에이전트가 필요로 하는 재료가 많다는 점입니다. 페이지, 데이터베이스, 의사결정 기록, 담당자, 상태값, 회의 맥락, 지난번에 왜 그렇게 결정했는지에 대한 흔적들입니다.

그래서 “Notion을 AI 업무 운영체제로 쓰면 되겠네”라는 생각이 나올 수 있습니다. 저는 그 말이 조금 위험하다고 판단합니다. 업무 공간은 AI가 들어왔다고 좋아지는 게 아닙니다. 다음 사람이 봤을 때 무엇이 바뀌었고, 왜 바뀌었고, 누가 받아들였고, 다음 행동이 무엇인지 알 수 있어야 좋아집니다.

그 기준으로 보면 Notion은 AI 에이전트 허브가 될 수도 있고, 그냥 정리되지 않은 업무 더미가 될 수도 있습니다.

이 글 뒤에 있던 워크스페이스 질문

먼저 본 건 기능표가 아니라 실제 일이 어디서 막히는지였습니다. Notion을 AI 에이전트 업무 허브로 둘 때 기록, 권한, MCP 연결, 확인 지점, 멈춰야 할 신호를 운영 단위로 가르는 기준입니다. 실행보다 기록을 먼저 둡니다. 결국 남는 기준은 결과물을 다음 사람이 다시 해체하지 않고 이어받을 수 있느냐였습니다.

샘플로 삼은 Notion 데이터베이스

제가 놓고 본 업무는 이렇습니다. Slack 요청이 Notion 작업, Google Sheets 상태 행, 후속 메모로 이어지는 업무. 먼저 자료가 어디서 들어오고, 누가 확인하고, 결과가 어디에 남는지부터 적었습니다. Notion, Notion AI, Notion API, MCP, External Agents, Workers는 그 흐름을 덜 흔들리게 만들 때만 의미가 있었습니다.

에이전트 허브라고 부르기 전에 본 것

확인한 것제가 본 기준실패 신호
입력 자료AI가 그대로 써도 될 만큼 자료가 분명한가빠진 맥락을 질문하지 않고 추측합니다
사람 검토승인, 수정, 반려가 몇 분 안에 가능한가검토자가 처음부터 다시 읽습니다
다음 전달문서, 표, 티켓, 업무 흐름으로 바로 넘길 수 있는가다음 사람이 형식이나 의미를 다시 맞춥니다
반복성다른 자료를 넣어도 같은 방식으로 굴러가는가첫 번은 괜찮고 두 번째부터 흔들립니다

업무를 보이게 만든 검토 필드

증거확인한 것왜 중요했나
입력Slack 요청이 Notion 작업, Google Sheets 상태 행, 후속 메모로 이어지는 업무.일은 도구 이름이 아니라 들어오는 자료에서 시작합니다
검토 지점누가 확인하고 무엇을 반려할 수 있는지 봤습니다검토자가 없으면 자동화처럼 보일 뿐입니다
실패 메모Slack은 살아 있는데 Notion과 Sheets가 서로 어긋나서 무엇이 최신인지 알 수 없는 상황.안 된 실행을 하나 남겨야 범위를 줄일 수 있습니다

워크스페이스가 어긋난 지점

문제는 첫 답변보다 그다음이었습니다. 답변을 받은 뒤 실제로 넘기려는 순간에 일이 다시 늘어났습니다. 이 주제에서 자주 보인 실패는 이렇습니다. Slack은 살아 있는데 Notion과 Sheets가 서로 어긋나서 무엇이 최신인지 알 수 없는 상황. 그래서 저는 보기 좋은 초안을 업무 준비 완료로 보지 않습니다.

Notion에 더 많은 권한을 주기 전 내 기준

저라면 먼저 Slack 메시지, Notion 작업, Sheets 행, 담당자 메모를 남깁니다. 그 자료가 사람 검토를 통과하는지 확인한 뒤에야 도구를 고릅니다. 몇 분 안에 확인할 수 없는 결과라면 모델을 바꾸기 전에 자동화 범위부터 줄이는 편이 낫습니다.

Notion에 다음 단계를 맡기기 전 체크

  • AI가 받는 입력 자료를 한 줄로 적습니다.
  • 결과를 승인하거나 반려할 사람을 정합니다.
  • 출력물이 다음에 어디로 가야 하는지 정합니다.
  • 잘 된 예시만 두지 말고 실패한 예시도 하나 남깁니다.
  • 생성은 빨라졌는데 검토 시간이 그대로라면 효과가 없습니다.
  • 다음 사람이 계속 다시 만들고 있다면 그 자동화는 멈춥니다.

확인한 자료

변할 수 있는 사실은 공식 문서, 제품 페이지, 바뀔 가능성이 있는 주장에 대한 출처 메모를 기준으로 확인했습니다. 가격, 모델 접근, 플랫폼 기능은 자주 바뀌기 때문에 의견과 근거를 분리해서 봐야 합니다.

제가 먼저 잡을 기준

저라면 Notion을 AI가 업무를 실행하는 중앙 엔진으로 두지 않습니다. 대신 AI가 관여한 업무의 기록판으로 둡니다.

역할을 이렇게 나눕니다.

Notion에 남길 것AI가 준비할 것사람이 결정할 것
원본 페이지, 프로젝트 맥락, 데이터베이스 행, 의사결정 메모요약, 빠진 필드, 초안, 라우팅 제안승인, 최종 문구, 예외 처리, 되돌리기 어려운 변경

조심스러운 설계처럼 보이지만, 실무에서는 이 정도가 오히려 오래 갑니다.

AI 에이전트가 Notion 데이터베이스를 읽고 다음 행동을 제안한다면, 저는 해당 페이지에 네 가지가 꼭 보여야 한다고 생각합니다. 어떤 근거를 읽었는지, 무엇을 바꾸려 하는지, 누가 승인해야 하는지, 틀렸을 때 어떻게 되돌릴지. 이 네 가지가 없으면 자동화가 아니라 검토 부담을 다른 사람 책상 위로 옮긴 것에 가깝습니다.

Notion이 일반 자동화 도구와 다른 자리

Zapier, Make, n8n 같은 도구는 시스템 사이의 이벤트를 옮기는 데 강합니다. 어떤 행이 바뀌면 웹훅을 보내고, 메시지를 띄우고, 티켓을 만들고, 담당자를 지정합니다. 이건 분명 중요합니다.

Notion의 위치는 조금 다릅니다. Notion은 팀이 자기 일을 설명하는 장소가 되기 쉽습니다. 제품 요구사항, 릴리즈 노트, 계정 플랜, 리서치 메모, 회의록, 채용 계획, 운영 체크리스트, 협력사 평가, 예산 메모 같은 것들이 쌓입니다. 이런 자료는 깔끔한 이벤트 스트림이 아닙니다. 반쯤 구조화된 업무 맥락입니다.

AI 에이전트는 이런 맥락을 필요로 합니다. 단순 트리거와 필드 매핑만으로는 부족합니다. 왜 이 업무가 생겼는지, 지난달에 어떤 규칙을 합의했는지, 어떤 예외를 허용했는지, 다시 열면 안 되는 결정이 무엇인지 알아야 합니다.

그래서 Notion이 흥미롭습니다. “문서 안에 AI가 들어간다”보다 “문서, 데이터베이스, 의사결정 흐름이 가까운 곳에서 에이전트가 움직인다”는 점이 더 중요합니다.

실제로 Notion에 넣을 것

제가 실무에 붙인다면 멋진 에이전트부터 만들지 않을 겁니다. 먼저 AI 작업을 검토 가능한 형태로 만드는 기록부터 잡겠습니다.

첫 번째는 업무 접수 데이터베이스입니다. 거대한 프로세스 관리표가 아니라 작은 표면 충분합니다.

필드필요한 이유
요청 내용사람이 읽을 수 있는 실제 업무
출처Slack, 이메일, 회의록, 폼, 외부 문서
담당자승인하거나 반려할 수 있는 사람
AI 역할읽기 전용, 초안, 분류, 갱신, 에스컬레이션
검토 상태신규, 초안, 승인, 반려, 보류
근거 링크AI가 참고한 페이지, 파일, 메시지
예외 사유일반 흐름으로 처리하지 못한 이유
다음 행동다음에 움직일 사람 또는 시스템

이런 필드는 멋이 없습니다. 그런데 실무 자동화는 멋없는 필드가 버팁니다. 나중에 문제가 생겼을 때 “왜 이렇게 됐지?”를 추적할 수 있기 때문입니다.

두 번째는 의사결정 페이지 템플릿입니다. 모든 결정 페이지는 최소한 세 질문에 답해야 합니다.

  1. 무엇이 바뀌었나?
  2. 어떤 근거를 썼나?
  3. 누가 받아들였나?

세 번째는 에이전트 운영 규칙 페이지입니다. 에이전트가 승인 없이 해도 되는 일, 초안까지만 가능한 일, 절대 바꾸면 안 되는 일을 써둬야 합니다. 이 페이지가 없으면 첫 사고 이후 사람들은 기억을 가지고 싸우게 됩니다.

Notion에 맡기지 않을 것

저는 시간 제한이 강한 실행 업무를 Notion 안에만 두지 않습니다. 고객 환불, 장애 대응, 인보이스 지급, 컴플라이언스 응답, 계정 권한 변경 같은 일은 원래 시스템이 따로 있어야 합니다. Notion은 그 근거와 인수인계를 남기는 곳으로 두는 편이 낫습니다.

또 Notion을 두 번째 CRM, 두 번째 티켓 시스템, 두 번째 재무 시스템으로 만드는 것도 조심해야 합니다. 초반에는 유연해 보입니다. 그런데 석 달 지나면 동기화와 책임 소재가 일이 됩니다.

기준은 단순합니다. 이미 공식 시스템이 있는 업무라면 Notion은 설명과 운영 관점을 맡아야 합니다. 조용히 경쟁 시스템이 되면 안 됩니다.

현장 판단

저는 Notion을 고를 때와 미룰 때를 먼저 나눕니다. 업무 맥락이 흩어져 있고, 사람이 최종 판단해야 하며, 근거 링크를 남겨야 한다면 Notion은 좋은 후보입니다. 반대로 초 단위 처리, 결제 실행, 권한 변경, 장애 대응처럼 결과가 바로 외부에 영향을 주는 일이라면 Notion을 기본 실행 경로로 선택하지 말아야 합니다.

운영에 넣는다면 처음에는 읽기 전용으로 둡니다. 그 다음 초안 작성, 그 다음 낮은 위험의 상태값 변경 순서로 갑니다. 처음부터 “AI가 알아서 업데이트한다”로 가면 대개 사람이 나중에 다 뒤집어엎습니다. Notion을 선택하는 이유는 실행 속도보다 판단 흔적을 남기는 데 있어야 합니다.

처음 배포할 에이전트 흐름

저라면 주간 프로젝트 리뷰부터 시작합니다.

에이전트가 프로젝트 데이터베이스와 관련 페이지를 읽습니다. 일정이나 예산을 직접 바꾸지는 않습니다. 대신 리뷰용 페이지를 준비합니다.

  • 담당자가 비어 있는 프로젝트
  • AI가 수정했지만 사람이 승인하지 않은 페이지
  • 30일 넘게 업데이트되지 않았는데 아직 현재 업무에 영향을 주는 결정
  • 다음 행동 없이 막힌 항목
  • 고객, 협력사, 비용, 법무 이슈가 언급된 항목

그리고 짧은 리뷰 페이지 초안을 만듭니다. 담당자가 읽고 고치고 받아들인 다음 다음 행동을 지정합니다.

이 흐름은 화려하지 않습니다. 그게 장점입니다. AI에게 유용한 맥락을 주되 판단은 사람이 잡고 있습니다. 에이전트가 프로젝트를 잘못 이해했을 때도 어떤 페이지를 근거로 삼았는지 확인할 수 있습니다.

몇 주 동안 안정적으로 돈다면 그때 낮은 위험의 쓰기 권한을 하나 엽니다. 예를 들면 담당자가 비어 있을 때 검토 상태를 “담당자 필요”로 바꾸는 정도입니다. 이 경우에도 변경 기록은 남겨야 합니다.

MCP와 외부 에이전트가 의미 있는 지점

MCP는 에이전트가 도구와 데이터에 접근하는 방식을 표준화하려는 흐름입니다. Notion의 MCP와 Custom Agents 방향이 중요한 이유도 여기에 있습니다. Notion이 “AI가 요약해주는 문서함”에서 “다른 에이전트가 업무 맥락을 읽고 갱신할 수 있는 작업 표면”으로 바뀔 수 있기 때문입니다.

이건 분명 변화입니다. 다른 환경의 에이전트가 Notion의 맥락을 가져오고, 페이지를 만들고, 데이터베이스 항목을 갱신하고, Notion을 지속적인 업무 기록으로 쓸 수 있습니다.

다만 운영 문제는 사라지지 않습니다. 오히려 더 중요해집니다.

  • 어떤 페이지를 읽을 수 있나?
  • 어떤 데이터베이스를 갱신할 수 있나?
  • 어떤 필드는 초안까지만 허용할 것인가?
  • 어떤 변경에는 사람 이름이 붙어야 하나?
  • 업무 시간이 아닐 때 막아야 할 행동은 무엇인가?
  • 원본 페이지와 데이터베이스 필드가 충돌하면 어느 쪽을 우선할 것인가?

출시 소식보다 이런 질문이 재미없을 수 있습니다. 하지만 여기서 실패하면 자동화가 아니라 조용한 혼란이 됩니다.

2주짜리 도입안

팀에 Notion을 AI 에이전트 허브로 넣자고 제안해야 한다면, 저는 2주만 좁게 테스트하자고 할 겁니다.

첫 주는 읽기 전용입니다. 에이전트는 선택한 프로젝트 페이지와 하나의 데이터베이스만 읽습니다. 리뷰 페이지 초안은 만들 수 있지만 데이터베이스 필드는 바꾸지 못합니다. 팀은 초안이 리뷰 시간을 줄였는지, 근거 링크가 충분했는지, 사람이 다시 전부 확인해야 했는지 확인합니다.

둘째 주는 제한된 쓰기 권한을 하나만 엽니다. 예를 들어 “검토 상태”나 “담당자 누락” 같은 낮은 위험의 필드입니다. 일정, 예산, 고객 약속, 권한, 공개 문서는 바꾸지 않습니다. 모든 쓰기에는 페이지 안에 흔적이 남아야 합니다.

성공 기준은 “요약이 그럴듯하다”가 아닙니다. 그건 너무 쉽습니다. 제가 볼 지표는 이쪽입니다.

  • 리뷰 시간이 실제로 줄었는가?
  • 담당자 누락을 잡아냈는가?
  • 큰 수정 없이 받아들인 초안이 몇 개인가?
  • 반려된 제안은 몇 개인가?
  • 담당자가 결국 원본을 전부 다시 열어봤는가?

마지막 숫자가 높으면 아직 준비가 안 된 겁니다. 모델은 좋아 보여도 업무 설계가 약한 상태입니다.

실패 기준

다음 신호가 보이면 범위를 줄이거나 중단합니다.

신호보통 의미하는 것
검토자가 모든 원본을 다시 열어본다AI 결과를 아직 믿을 수 없다
AI 페이지가 쌓이는데 담당자가 없다문서는 늘었지만 결정은 늘지 않았다
어떤 필드를 AI가 바꿨는지 모른다감사 가능성이 약하다
끝난 결정을 계속 다시 연다원본 우선순위가 불분명하다
Notion이 다른 시스템을 복제한다숨은 운영 시스템이 생기고 있다

이런 문제는 크게 터지지 않을 때가 많습니다. 그래서 더 위험합니다. 나쁜 Notion 에이전트 구조는 사고를 내기보다, 그럴듯한 페이지를 계속 만들고 아무도 믿지 않는 상태로 굳어집니다.

제 판단

Notion은 AI 에이전트 허브가 될 수 있습니다. 다만 마법 같은 실행 버튼이 아니라 업무 기록판으로 판단할 때 가능성이 큽니다.

처음부터 자율 실행을 맡길 필요는 없습니다. 맥락을 모으고, 초안을 만들고, 근거 링크를 붙이고, 다음 담당자에게 넘기는 것부터 시작하는 편이 낫습니다. AI가 더 많은 일을 하게 만들기 전에, 사람이 더 적은 시간으로 검토할 수 있게 만들어야 합니다.

이미 담당자, 출처, 상태값, 의사결정 페이지, 검토 규칙이 잡힌 Notion 공간이라면 에이전트가 속도를 높일 수 있습니다. 반대로 반쯤 작성된 페이지가 쌓인 공간이라면 에이전트는 정리가 아니라 빠른 복제를 할 가능성이 큽니다.

제 기준은 이렇습니다. 오래 남겨야 하는 맥락은 Notion에 둡니다. 실행은 원래 시스템에 둡니다. AI는 다음 행동을 준비하게 합니다. 그리고 그 행동을 사람이 받아들이기 전까지는 자동화가 권한을 얻었다고 생각하지 않습니다.

자주 묻는 질문

Notion이 Zapier, Make, n8n을 대체할 수 있나요?

그렇게 보지는 않습니다. 트리거, 조건 분기, 재시도, 시스템 간 실행은 자동화 플랫폼이 여전히 필요합니다. Notion은 그 실행 주변의 맥락, 결정, 인수인계 기록으로 쓰는 편이 더 맞습니다.

AI 에이전트가 Notion 데이터베이스를 수정해도 될까요?

처음부터는 권하지 않습니다. 읽기 전용과 초안 작성으로 시작하고, 신뢰가 쌓이면 낮은 위험의 필드 하나부터 열어야 합니다. 변경 기록은 반드시 남겨야 합니다.

MCP가 꼭 필요한가요?

항상 필요한 건 아닙니다. Notion API만으로도 페이지를 만들고 데이터베이스를 조회할 수 있습니다. MCP는 외부 에이전트가 Notion과 다른 도구를 더 일관된 방식으로 연결해야 할 때 의미가 커집니다.

가장 먼저 해볼 만한 실험은 무엇인가요?

프로젝트 데이터베이스 하나를 고릅니다. 에이전트가 담당자 누락, 오래된 결정, 막힌 항목, 근거 링크를 모아 주간 리뷰 페이지 초안을 만들게 합니다. 리뷰 시간이 줄고 위험이 숨지 않는다면 다음 단계로 갈 수 있습니다.

업무 흐름

이 글이 속한 업무 흐름

지금 읽는 글이 어떤 업무 흐름에 연결되는지 확인하고, 관련 글로 이어서 볼 수 있습니다.

도구 스택 선택 팀의 운영 성숙도에 맞는 스택을 고릅니다.

자동화 플랫폼, 앱 빌더, 에이전트 빌더, 회계 도구, 범용 AI 어시스턴트는 운영 부담까지 같이 따져야 합니다.

관련 주제 보기
잘 맞는 경우
간단한 도구 구매, 내부 워크플로우 구축, 더 큰 플랫폼 도입 사이에서 결정해야 하는 팀
맞지 않을 수 있는 경우
판단 기준보다 단계별 설정 방법이 먼저 필요한 경우에는 다른 실행형 글이 더 적합합니다.
관련 글

참고한 공개 자료

본문의 보도 사실, 공식 문서, 정책 배경, 제품 정보, 바뀔 수 있는 주장을 확인할 때 참고한 공개 자료입니다.

다음 단계

읽은 내용을 운영 체크리스트로 옮겨보세요.

먼저 리소스 경로에서 업무 flow를 점검하고, 현재 프로세스와 인계 지점을 확인한 뒤 도구를 비교하세요.

워크플로우 업데이트 제보