Notion Workers, 에이전트 워크스페이스의 런타임 전쟁

AI 요약

• 무슨 일: Notion이 Workers, External Agents API, Agent SDK, ntn CLI를 묶은 Developer Platform을 공개했습니다.
  • 공식 발표일은 2026년 5월 13일이며, Notion은 이미 100만 개 이상의 Custom Agents가 만들어졌다고 밝혔습니다.
• 의미: Notion은 문서 앱에서 AI 에이전트가 데이터, 코드, 외부 도구를 함께 다루는 워크스페이스 런타임으로 이동합니다.
• 실무 영향: 팀은 사내 API, CRM, 지원 시스템, 코딩 에이전트를 Notion 안으로 끌어오되, credits와 권한 모델까지 같이 설계해야 합니다.
  • Workers는 2026년 8월까지 무료 베타이고, 2026년 8월 11일부터 Notion credits로 실행됩니다.

Notion이 2026년 5월 13일 Developer Platform을 공개했습니다. 발표 문장만 보면 평범한 개발자 플랫폼처럼 보입니다. 하지만 안쪽을 보면 방향이 더 선명합니다. Notion은 이제 문서와 데이터베이스를 담는 앱이 아니라, AI 에이전트가 읽고, 판단하고, 코드를 실행하고, 외부 에이전트와 함께 일하는 작업 런타임이 되려 합니다.

핵심 부품은 네 가지입니다. 첫째, Notion Workers는 Notion이 호스팅하는 커스텀 코드 실행 환경입니다. 둘째, External Agents API는 Claude Code, Cursor, Codex, Decagon 같은 외부 에이전트를 Notion 안의 작업 참여자로 들여오는 통로입니다. 셋째, Agent SDK는 외부 시스템에서 Notion Custom Agents를 프로그래밍 방식으로 트리거하는 경로입니다. 넷째, ntn CLI는 사람 개발자와 코딩 에이전트가 같은 명령줄에서 Notion을 읽고 쓰고 Workers를 배포하게 하는 인터페이스입니다.

이 발표가 중요한 이유는 Notion이 "AI 기능을 붙인 문서 앱"을 넘어섰기 때문입니다. AI 에이전트가 실무에서 막히는 지점은 대개 모델 성능 하나가 아닙니다. 필요한 데이터가 여러 SaaS와 내부 시스템에 흩어져 있고, 어떤 작업은 LLM이 매번 추론하게 두기보다 결정적 코드로 처리해야 하며, 외부 코딩 에이전트가 만든 결과를 팀이 승인하고 추적할 장소도 필요합니다. Notion은 이 세 가지 병목을 자기 워크스페이스 안에서 해결하겠다고 선언했습니다.

100만 Custom Agents 다음 문제

Notion은 발표에서 지금까지 고객들이 100만 개 이상의 Custom Agents를 만들었다고 밝혔습니다. 숫자만 보면 Custom Agents 자체는 이미 빠르게 확산된 셈입니다. 그러나 바로 그 확산이 다음 병목을 드러냈습니다. 에이전트를 만드는 일보다, 그 에이전트가 믿을 만한 데이터와 결정적 액션에 닿게 하는 일이 더 어려워졌습니다.

Notion의 설명은 꽤 현실적입니다. 팀의 업무는 Notion 안에만 있지 않습니다. 고객 정보는 Salesforce에 있고, 지원 티켓은 Zendesk에 있고, 운영 데이터는 Postgres에 있고, 제품 이슈는 GitHub나 Linear에 있습니다. 문서와 회의록이 Notion에 있어도 에이전트가 이 외부 맥락을 읽지 못하면 "그럴듯한 업무 도우미"에 머뭅니다. 반대로 외부 데이터와 코드 실행을 붙이면 Notion은 단순한 기록 장소가 아니라 업무 자동화의 상태판이 됩니다.

그래서 이번 발표의 중심에는 Workers가 있습니다. Workers는 Notion의 hosted runtime for custom code입니다. 개발자가 로직을 작성해 Notion의 보안 샌드박스에 배포하면, 그 코드가 database sync, custom agent tool, webhook trigger를 구동합니다. Notion은 "서버를 프로비저닝하거나 컨테이너를 구성할 필요가 없다"고 설명합니다. 사내에서 Lambda, Cloudflare Workers, Zapier, Make, n8n, cron script로 흩어져 있던 작은 자동화들이 Notion 문맥으로 들어올 수 있다는 뜻입니다.

물론 이것은 기존 서버리스와 완전히 같은 제품은 아닙니다. Notion Workers의 강점은 범용 컴퓨트가 아니라 Notion 데이터와 Notion 에이전트에 붙어 있다는 점입니다. 예를 들어 지원 티켓을 Notion database로 동기화하고, Custom Agent가 그 데이터를 읽어 초안을 만들고, 외부 코딩 에이전트가 수정 작업을 맡고, 팀원이 같은 페이지에서 승인하는 흐름을 상상할 수 있습니다. 이때 Workers는 "계산 자원"보다 "워크스페이스 안의 결정적 도구"에 가깝습니다.

MCP만으로 부족한 일을 코드로 고정한다

이번 발표에서 특히 흥미로운 대목은 Notion이 MCP를 부정하지 않는다는 점입니다. 오히려 Notion은 Custom Agents가 built-in tools와 MCP를 통해 제3자 기능에 연결될 수 있다고 설명합니다. 다만 MCP가 넓은 연결성을 제공하더라도, 모든 워크플로우가 LLM-mediated tool call에 맡겨질 필요는 없다고 봅니다.

실무에서는 이 구분이 중요합니다. 고객 등급을 계산하거나, 데이터 필드를 정규화하거나, 승인 조건을 검증하거나, 특정 API 호출 순서를 지켜야 하는 작업은 "모델이 매번 잘 추론하기"보다 "코드가 항상 같은 방식으로 실행되기"가 더 낫습니다. Notion은 Workers 기반 agent tools가 deterministic하고 token-efficient하다고 강조합니다. 표현은 제품 마케팅에 가깝지만, 문제의식은 맞습니다. 에이전트 시스템에서 결정성은 비용과 신뢰성의 문제입니다.

예를 들어 영업팀의 Custom Agent가 "이번 주 갱신 위험 고객을 정리해줘"라는 요청을 받는다고 해보겠습니다. LLM이 CRM API를 직접 뒤져 모든 조건을 매번 해석하는 대신, Worker가 Salesforce와 Notion database를 동기화하고, 갱신일과 사용량 변화와 지원 티켓 상태를 계산한 다음, 에이전트는 그 결과를 요약하고 다음 액션을 제안할 수 있습니다. 이렇게 역할을 나누면 LLM은 언어와 판단에 집중하고, 코드는 반복 가능한 계산을 맡습니다.

이 구조는 AI 에이전트 플랫폼 경쟁의 방향과도 맞닿아 있습니다. 2025년과 2026년 초반의 에이전트 논의는 "어떤 모델이 더 잘 계획하고 도구를 부르는가"에 집중했습니다. 이제는 "그 도구가 어디에서 실행되고, 어떤 권한으로, 어떤 비용 단위로, 누가 승인했는가"가 더 중요해지고 있습니다. Notion Workers는 이 질문에 Notion식 답을 내놓은 것입니다.

외부 에이전트가 Notion 안으로 들어온다

External Agents API는 이번 발표의 더 큰 전략을 보여줍니다. Notion은 외부 에이전트를 Notion 안의 네이티브 워크스페이스 참여자로 다루려 합니다. 공식 발표는 Claude Code, Cursor, Codex, Decagon을 파트너 에이전트 예시로 들었습니다. 팀이 이미 쓰는 코딩 에이전트나 지원 에이전트를 Notion에서 직접 채팅하고, 일을 배정하고, 진행 상황을 추적하게 하겠다는 구상입니다.

이 대목은 GitHub, Slack, Teams, Cursor 같은 도구들과 겹칩니다. GitHub는 코드와 PR을 중심으로 에이전트 세션을 모으고, Slack과 Teams는 대화와 조직 커뮤니케이션을 중심으로 에이전트를 배치합니다. Notion은 문서, 데이터베이스, 프로젝트 상태, 회의록, 지식베이스를 중심에 둡니다. 같은 "에이전트 허브"라도 기준점이 다릅니다.

개발팀 입장에서는 이 차이가 큽니다. 코딩 에이전트는 코드를 고칠 수 있지만, 어떤 요구사항이 최신인지, 고객 맥락이 어디에 있는지, 승인권자가 누구인지는 보통 코드 저장소 밖에 있습니다. Notion이 그 맥락을 쥐고 있다면, Codex나 Cursor 같은 에이전트를 Notion 작업 단위에 연결하는 일은 자연스러운 확장입니다. 단순히 "코딩 에이전트를 Notion에서 부른다"가 아니라, 제품 스펙, 고객 피드백, 작업 상태, 승인 기록을 한곳에서 엮는 쪽에 가깝습니다.

하지만 이것은 동시에 플랫폼 잠금의 시작이기도 합니다. External Agents API가 private beta인 동안에는 어떤 에이전트가 어떤 권한과 표현 방식으로 들어올지 제한적일 수밖에 없습니다. Notion이 "모든 에이전트가 들어오는 공유 캔버스"가 되려면 API 표면, 인증 모델, 감사 로그, 실패 복구, 비용 추적이 충분히 열려 있어야 합니다. 그렇지 않으면 외부 에이전트 연결은 파트너 로고가 붙은 데모에 머물 수 있습니다.

CLI는 사람과 코딩 에이전트의 공용 인터페이스다

ntn CLI도 가볍게 볼 수 없습니다. Notion Help Center는 ntn을 개발자와 AI coding assistants가 클릭 없이 Notion을 읽고 업데이트하게 하는 command-line interface라고 설명합니다. CLI는 모든 플랜에서 무료로 사용할 수 있지만, Workers 배포와 관리는 Business 또는 Enterprise 플랜이 필요합니다.

왜 CLI가 중요할까요. 코딩 에이전트는 대개 터미널을 잘 다룹니다. 사람이 브라우저에서 페이지를 찾아 복사해 주지 않아도, 에이전트가 ntn을 통해 스펙 문서를 읽고, 작업 페이지를 업데이트하고, Worker를 배포할 수 있다면 Notion은 에이전트용 API 표면을 갖게 됩니다. Notion의 표현대로 "사람과 에이전트가 같은 인터페이스"를 쓰는 셈입니다.

이 흐름은 최근 AI 개발 도구 시장의 공통 패턴입니다. IDE 안에만 있던 코딩 도구가 CLI로 나오고, CLI는 다시 GitHub Actions나 백그라운드 에이전트로 확장됩니다. Notion의 CLI는 반대 방향에서 같은 문제를 풉니다. 문서와 업무 데이터가 있는 곳에 CLI를 붙여, 코딩 에이전트가 워크스페이스 맥락을 가져가게 합니다. 결국 코딩 에이전트 경쟁은 "어느 IDE에서 더 좋은 자동완성을 하느냐"가 아니라 "어느 업무 시스템까지 안전하게 들어가느냐"로 이동하고 있습니다.

비용 모델은 벌써 따라붙었다

Notion Developer Platform의 밝은 부분만 보면, 작은 팀도 Notion 안에 가벼운 자동화 런타임을 만들 수 있어 보입니다. 그러나 비용 모델은 이미 발표 안에 들어와 있습니다. Notion은 Workers가 Custom Agents와 같은 credit system을 사용하며, 2026년 8월까지 무료라고 설명합니다. Notion release note는 더 구체적으로 2026년 8월 11일부터 Workers가 Notion credits로 실행된다고 적습니다.

이 말은 두 가지를 뜻합니다. 첫째, Notion은 에이전트와 자동화를 같은 경제 단위로 묶고 있습니다. Custom Agent가 생각하는 비용과 Worker가 실행되는 비용이 모두 Notion credits로 관리되면, 팀은 "문서 앱 구독료"가 아니라 "워크스페이스 자동화 사용량"을 예산 항목으로 봐야 합니다. 둘째, Notion 안에서 자동화를 많이 만들수록 비용 관측성이 중요해집니다. 어떤 Worker가 얼마나 자주 돌고, 어떤 에이전트가 어떤 도구를 호출하며, 실패한 실행이 credits를 얼마나 태우는지 추적해야 합니다.

이는 Anthropic의 Agent SDK credits, GitHub Copilot의 agent usage metrics, enterprise AI gateway 제품들과 같은 방향입니다. AI 에이전트는 더 이상 무제한 채팅창의 부가 기능이 아닙니다. 실행되고, 실패하고, 재시도하고, 외부 시스템을 읽고 쓰는 소프트웨어입니다. 소프트웨어가 되면 비용, 권한, 감사, 운영이 붙습니다. Notion의 발표는 그 현실을 문서 앱의 언어로 번역한 사례입니다.

거버넌스가 제품 기능이 되는 순간

Notion은 Developer Platform의 거버넌스를 "day one"부터 넣었다고 강조합니다. 공식 발표에서 언급된 요소는 auth, permissions, sandbox, progressive trust, visibility입니다. Workers는 isolated environment에서 실행되고, 모든 agent work는 팀이 협업하는 같은 workspace에 보이며, 처음에는 human review를 두고 신뢰가 쌓이면 autonomy를 넓히는 방식을 제안합니다.

이 부분은 단순한 보안 체크박스가 아닙니다. AI 에이전트가 실제 업무 시스템을 건드리기 시작하면, 팀이 가장 먼저 묻는 질문은 "무엇을 할 수 있나"가 아니라 "어디까지 하게 둘 수 있나"입니다. 고객 데이터를 읽을 수 있는가, 가격을 바꿀 수 있는가, 지원 티켓을 닫을 수 있는가, PR 병합 후 Notion task를 자동 완료할 수 있는가. 이 질문은 제품 경험의 일부입니다.

Notion이 유리한 지점도 여기 있습니다. Notion은 이미 팀의 문서, 프로젝트, 승인 코멘트, 데이터베이스가 모이는 장소입니다. 에이전트의 실행 기록과 승인 상태가 같은 공간에 보이면, 별도 관제 도구를 보지 않는 비개발자도 흐름을 이해하기 쉽습니다. 반대로 Notion이 불리한 지점도 같습니다. 워크스페이스가 너무 많은 의미를 갖게 되면, 잘못된 권한 설정 하나가 문서 노출을 넘어 자동화 실행 리스크로 이어질 수 있습니다.

Notion은 Zapier와 GitHub 사이의 어딘가를 노린다

이번 발표를 기존 자동화 도구와 비교하면 위치가 보입니다. Zapier, Make, n8n은 앱과 앱 사이의 이벤트와 액션을 연결하는 데 강합니다. Cloudflare Workers, AWS Lambda 같은 서버리스는 개발자에게 범용 실행 환경을 줍니다. GitHub와 Cursor는 코드 작업과 개발자 흐름에 깊습니다. Notion은 이 셋을 모두 정면으로 대체하기보다, "업무 지식과 에이전트 협업이 모이는 워크스페이스"라는 자기 위치에서 런타임을 붙입니다.

그래서 Notion Workers가 가장 잘 맞는 사용처는 완전한 백엔드가 아닐 가능성이 큽니다. 오히려 Notion database를 중심으로 외부 데이터를 주기적으로 동기화하거나, Custom Agent에게 결정적 도구를 붙이거나, PR merge, CRM update, support ticket change 같은 이벤트를 Notion 작업 상태로 반영하는 흐름이 먼저 떠오릅니다. 팀의 지식과 상태가 이미 Notion에 있다면, 작은 자동화 코드를 Notion 근처에 두는 것이 편합니다.

다만 개발자 플랫폼으로서의 신뢰는 아직 검증이 필요합니다. Workers의 런타임 제약, 로컬 개발 경험, 배포 이력, 롤백, 관측성, 비밀 관리, 에러 처리, 테스트 전략은 공식 발표만으로 충분히 판단하기 어렵습니다. Notion이 "코딩 에이전트가 작성한 Worker를 빠르게 배포한다"고 말할수록, 실제 운영에서는 코드 리뷰와 권한 승인, 테스트 환경, 실패 시 복구가 더 중요해집니다.

개발자가 지금 봐야 할 질문

개발자와 AI 팀이 지금 확인할 지점은 명확합니다. 첫째, Notion 안에 들어오면 가치가 커지는 데이터가 무엇인지 봐야 합니다. CRM 전체를 복사하는 것이 아니라, 에이전트가 작업을 판단하는 데 필요한 필드와 상태만 동기화하는 식의 설계가 필요합니다. 둘째, LLM에게 맡길 일과 Worker로 고정할 일을 나눠야 합니다. 요약, 분류, 초안 작성은 에이전트에 맞고, 검증, 변환, 외부 API 액션은 코드에 맞을 수 있습니다.

셋째, 외부 에이전트를 Notion에 연결할 때 작업 단위와 승인 단위를 분리해야 합니다. Codex가 버그 수정을 제안하고, Cursor가 리팩터링을 수행하고, Decagon이 지원 티켓을 요약하더라도, 최종 승인과 기록은 팀의 권한 체계 안에 남아야 합니다. 넷째, credits를 운영 지표로 봐야 합니다. 베타 기간에는 비용이 가려지지만, 2026년 8월 이후에는 자동화 설계가 곧 비용 설계가 됩니다.

Notion의 이번 발표는 완성된 답이라기보다 방향 전환에 가깝습니다. AI 에이전트가 늘어나면서 팀은 더 많은 채팅창을 원하지 않습니다. 에이전트가 실제 업무 맥락을 이해하고, 필요한 데이터를 읽고, 반복 작업은 코드로 처리하고, 사람이 승인해야 할 순간에는 같은 작업 공간으로 돌아오기를 원합니다. Notion은 그 작업 공간을 차지하려 합니다.

결론적으로, Notion Developer Platform은 "문서 앱에 개발자 기능이 추가됐다"보다 큰 사건입니다. AI 에이전트 시대의 워크스페이스가 어떤 모양이어야 하는지에 대한 Notion의 제안입니다. 모델은 점점 비슷한 도구 호출 능력을 갖게 되고, MCP는 연결 표준으로 퍼지고 있습니다. 다음 차이는 에이전트가 어디에서 일하고, 어떤 데이터에 닿고, 어떤 코드가 결정성을 보장하며, 누가 그 작업을 승인하고 기억하는가에서 납니다. Notion Workers는 그 경쟁이 이제 워크스페이스 런타임으로 옮겨가고 있음을 보여줍니다.