노티온, 작업 공간을 AI 에이전트 중심의 허브로 전환

Notion이 새롭게 공개한 개발자 플랫폼은 워크스페이스를 단순 문서 협업 도구에서 AI 에이전트 허브로 확장하는 구조적 변화다. 핵심은 MCP(Model Context Protocol) 기반의 커넥터 모델과 유사하게, 외부 LLM 에이전트(Claude, ChatGPT 등)가 Notion 데이터베이스와 페이지에 직접 읽기/쓰기 권한을 가지고 접근할 수 있도록 표준화된 인터페이스를 제공한다는 점이다. 개발자는 커스텀 코드 블록과 Webhook을 통해 외부 데이터 소스(Slack, GitHub, Linear, 사내 API 등)를 Notion 객체와 양방향으로 연결할 수 있으며, 에이전트는 페이지 컨텐츠를 컨텍스트로 받아 작업을 수행한 뒤 결과를 다시 워크스페이스에 기록한다. 기존 Notion API가 단순 CRUD 중심이었다면, 새 플랫폼은 에이전트의 도구 호출(tool calling)과 권한 위임(OAuth scope 세분화)을 전제로 설계되었다는 점에서 차이가 있다.

엔지니어 관점에서 이 변화는 사내 위키와 작업 관리가 곧 AI 에이전트의 1차 실행 환경이 된다는 의미다. 예를 들어 PR 리뷰 요약을 Notion 페이지에 자동 적재하거나, 회의록을 기반으로 Jira/Linear 티켓을 자동 생성하는 워크플로우를 별도 백엔드 구축 없이 Notion 내부에서 오케스트레이션할 수 있다. 특히 RAG 파이프라인을 직접 구현하던 팀이라면, 회사 문서가 이미 Notion에 있다는 점에서 벡터DB 구축·동기화 비용을 크게 줄일 수 있다. 다만 에이전트가 워크스페이스 전체에 접근하는 만큼, 권한 모델과 감사 로그(audit log) 설계가 새로운 보안 표면이 된다는 점은 주의해야 한다.

개발자가 당장 점검해야 할 사항은 세 가지다. 첫째, 사내 Notion 워크스페이스의 권한 구조와 민감 페이지(인사, 재무, 인증 키 포함 문서)를 분리해 에이전트가 접근 가능한 범위를 명확히 정의해야 한다. 둘째, 기존에 Notion API + 별도 봇으로 구현했던 자동화는 새 커스텀 코드/커넥터 방식으로 마이그레이션할 때 운영 비용과 락인(lock-in) 트레이드오프를 평가해야 한다. 셋째, Notion이 사실상 에이전트 런타임으로 진화하면서 경쟁사(Atlassian Rovo, Linear AI, Coda 등)와의 통합 전략을 재검토할 시점이며, 자체 MCP 서버를 구축해 Notion·Slack·내부 시스템을 동일한 프로토콜로 연결하는 방안도 함께 고려할 만하다.