Notion AI 에이전트 허브의 워크플로와 거버넌스 구조

페이지와 데이터베이스 옆에 에이전트를 놓다

Notion이 공개한 개발자 플랫폼은 외부 에이전트 연동과 멀티스텝 자동화 워크플로를 생산성 도구 안으로 끌어들인다. Custom Agents 출시 이후 고객이 직접 구축한 에이전트가 100만 개를 넘어섰다는 점도 이 전략의 수용 범위를 보여준다.

아키텍처의 출발점은 에이전트를 단순한 외부 연동이 아니라 워크스페이스의 일급 객체로 취급하는 데 있다. 페이지·데이터베이스·블록으로 구성된 기존 데이터 모델과 같은 추상화 계층에서 에이전트를 정의한다. 등록 단위인 에이전트 매니페스트에는 에이전트 ID, 이름, 설명, 권한 범위, 트리거 조건, 실행 환경 명세가 담긴다.

등록 인터페이스는 REST API와 SDK로 나뉜다. REST에서는 POST /api/v1/agents로 매니페스트를 제출하며, SDK는 Python·TypeScript·Go를 지원한다. 등록을 마친 에이전트는 워크스페이스의 에이전트 디렉토리에 표시되고, 멤버는 승인 절차를 거쳐 이를 활성화한다.

⤢✕

등록 이후에는 표준 API가 워크스페이스 데이터에 접근하는 경계를 만든다. 에이전트는 notion.pages.read(pageId)·notion.databases.query(dbId, filter)·notion.blocks.children.list(blockId)로 내용을 읽고, notion.pages.update·notion.blocks.append로 페이지와 블록을 변경한다. 각 호출은 해당 에이전트에 부여된 권한 범위 안에서만 허용된다.

컨텍스트를 읽고 실행 시점을 결정하는 방식

에이전트가 사용할 수 있는 컨텍스트 접근 방식은 명시적 접근, 검색 기반 접근, 구독 기반 접근으로 구분된다. 명시적 접근에서는 페이지 ID나 데이터베이스 ID를 직접 지정한다. 검색 기반 접근은 쿼리와 관련된 콘텐츠를 실행 시점에 찾는다. 구독 기반 접근은 특정 페이지나 데이터베이스의 변경 이벤트를 받아 후속 동작을 시작한다.

트리거는 에이전트 매니페스트에 선언한다. 데이터베이스 행의 생성·수정·삭제, 페이지 게시, 댓글 추가, 멘션, 크론 표현식을 이용한 스케줄 실행을 조건으로 사용할 수 있다. 여러 조건이 필요하면 AND·OR 연산자로 묶어 복합 규칙을 만든다.

이 구조에서 중요한 점은 데이터 접근 범위와 실행 조건이 에이전트 코드 바깥의 매니페스트에도 드러난다는 것이다. 관리자는 에이전트가 무엇을 읽고 어떤 사건에 반응하는지 활성화 전에 검토할 수 있다.

샌드박스에서 이어지는 멀티스텝 작업

각 실행 인스턴스는 독립된 프로세스 공간을 사용하는 샌드박스에서 동작한다. 다른 에이전트의 실행 상태와 분리되며, 기본 30초·최대 10분의 실행 타임아웃과 메모리 제한을 적용한다. 한 에이전트의 오작동이 워크스페이스 전체로 번지지 않도록 실행 경계를 두는 설계다.

멀티스텝 워크플로에서는 여러 Notion 액션과 외부 서비스 호출을 순서대로 실행하거나 조건에 따라 분기한다. 개발자는 이 흐름을 에이전트 코드에 직접 구현할 수 있다. 비개발자는 Notion 워크플로 빌더에서 액션을 드래그앤드롭으로 배치하고 조건 분기를 설정해 같은 종류의 흐름을 구성한다.

권한은 콘텐츠·액션·통합 범위로 나뉜다

100만 개의 커스텀 에이전트가 한 플랫폼에서 움직이는 환경에서는 에이전트마다 접근 경계를 세밀하게 분리해야 한다. Notion은 범위 기반 접근 제어를 적용해 권한을 콘텐츠, 액션, 통합 차원으로 정의한다.

콘텐츠 범위는 접근할 수 있는 팀스페이스·데이터베이스·페이지를 지정한다. 액션 범위는 읽기 전용, 읽기-쓰기, 삭제처럼 허용할 작업을 제한한다. 통합 범위에는 외부 서비스와 통신할 때 사용할 수 있는 연동 목록이 들어간다.

⤢✕

에이전트는 최소 권한 원칙에 따라 실제 작업에 필요한 범위만 요청하도록 권고된다. 플랫폼은 에이전트의 API 호출 패턴을 분석해 보유 권한이 과도한 대상을 찾고, 관리자에게 범위 축소를 권고한다.

자동 실행을 멈추는 감사와 승인 장치

모든 API 호출과 데이터 변경은 불변 감사 로그에 남는다. 로그 저장 공간은 워크스페이스별로 분리되며, 엔터프라이즈 플랜에서는 외부 SIEM 시스템으로 로그를 스트리밍할 수 있다.

고영향 액션에는 사용자 승인 게이트를 둘 수 있다. 개발자가 매니페스트에서 특정 액션을 approval_required: true로 표시하면, 실행 직전에 지정된 승인자에게 Notion 알림과 이메일이 발송된다. 승인자는 실제 수행될 내용을 확인하고 승인하거나 거부한다. 일정 시간 안에 응답하지 않으면 기본적으로 거부 처리된다.

공유 범위도 권한 체계의 일부다. Private 에이전트는 특정 워크스페이스 안에서만 사용한다. Organization 에이전트는 같은 Notion 조직에 속한 모든 워크스페이스에 배포할 수 있으며, Public 에이전트는 마켓플레이스를 통해 모든 Notion 사용자가 설치할 수 있다.

공개 등록에는 보안 심사가 따른다. 정적 코드 분석, 권한 범위의 적정성 검토, 개인정보 처리 방침 준수 여부가 심사 대상이다. 등록된 에이전트는 설치 수·사용자 평가·신뢰도 점수에 따라 순위가 정해지고, Notion이 직접 검증한 항목에는 공식 인증 배지가 붙는다.

100만 개가 보여주는 롱테일 자동화 수요

Custom Agents 출시 이후 구축된 에이전트 수는 100만 개에 도달했다. Notion이 이미 수천만 명의 활성 사용자와 수백만 개의 기업 워크스페이스를 확보한 플랫폼이라는 점이 초기 생태계 확장의 기반이 됐다.

규모만큼 눈에 띄는 부분은 용도의 분산이다. 회의록 정리, 프로젝트 상태 보고서 생성, 고객 피드백 분류, 인사 온보딩 체크리스트 자동화처럼 서로 다른 업무에서 커스텀 에이전트가 만들어지고 있다. 하나의 범용 솔루션으로는 다루기 어려운 롱테일 자동화 요구를 사용자가 직접 구현하는 구조다.

⤢✕

Zapier·Make와 갈리는 지점

Zapier와 Make(구 Integromat)는 미리 정한 이벤트-액션 규칙을 따라 결정론적으로 작업한다. 간단하고 결과를 예측하기 쉬운 자동화에는 잘 맞지만, 입력 내용을 해석해 다음 행동을 달리해야 하는 흐름에는 제약이 있다.

LLM을 기반으로 동작하는 Notion 에이전트는 이벤트의 내용과 워크스페이스 컨텍스트를 함께 보고 액션을 조정한다. 고객 문의 이메일 수신을 예로 들면, Zapier는 사전에 설정한 템플릿으로 응답 메일을 보낸다. Notion 에이전트는 이메일 내용을 분석해 문의 유형을 판단하고, 담당자 지정·우선순위 설정·맞춤형 응답 초안 생성을 이어서 수행한다.

반면 서드파티 연동 폭에서는 Zapier와 Make가 앞선다. 이들 도구는 수천 개의 앱 커넥터를 제공한다. Notion은 Zapier·Make 연동 커넥터를 공식 지원해 기존 자동화 인프라를 에이전트 워크플로 안에서 사용할 수 있도록 한다.

엔터프라이즈 지식 흐름을 자동화하다

Notion 에이전트 허브가 큰 가치를 만들 수 있는 영역은 엔터프라이즈 지식 관리다. 대규모 조직에서는 지식을 생산한 뒤 분류하고 연결하며 갱신하고 검색하는 과정이 수작업 병목으로 남아 있다.

회의가 끝나면 에이전트가 회의록을 구조화해 프로젝트 데이터베이스에 연결하고, 관련 문서를 백링크로 추가한 뒤 후속 태스크까지 생성할 수 있다. 신규 직원 온보딩에서는 입사일을 트리거로 개인화된 온보딩 페이지를 만들고 관련 문서와 팀 정보를 동적으로 선별한다.

이 접근은 반복 작업의 제거에만 머물지 않는다. Notion의 구조화된 데이터 모델에 에이전트의 언어 이해 능력을 결합하면 지식의 분류·연결·갱신까지 자동화 범위에 들어온다. 세분화된 권한, 감사 추적, 사용자 승인 게이트는 이 흐름을 100만 개 규모의 생태계에서 운영하기 위한 기반이다. 컨텍스트 인식은 기존 워크플로 자동화 도구와 구분되는 지점이며, 엔터프라이즈 지식 관리 자동화 수요는 에이전트 생태계의 장기 성장을 뒷받침하는 시장 인력이 될 것이다.