노션에 AI를 붙이면 어디까지 가능할까?

URL: https://www.youtube.com/watch?v=WVqOpMIXwyQ 날짜: 2026-09-12 채널: Chester Roh

---

📌 핵심 질문 / 이 노션 자동화의 핵심 논점

==Notion Workers는 TypeScript 한 파일만으로 외부 데이터를 정기적으로 가져오고, 그 데이터를 읽는 커스텀 도구를 Notion AI 에이전트에 연결한다.== 별도 서버·cron·스케줄러·접착 코드(glue code) 없이 YouTube 채널의 영상 통계는 매시간 갱신되고, 댓글은 필요할 때 실시간으로 조회되어 다음 영상 아이디어를 뒷받침한다.

• Notion API는 수년 전부터 페이지를 읽고 쓰는 기능을 제공했지만, 실용적인 동기화에는 서버·cron·rate limiting·retry·중복 방지 상태 관리·호스팅이 추가로 필요했다.
• Workers는 작은 TypeScript 프로그램을 Notion이 호스팅하고 실행·예약·감시하는 새로운 실행 단위이며, rate limiting·인증·스케줄링·upsert·로그까지 플랫폼 기능으로 제공한다.
• Custom agent는 데이터베이스를 성과 대시보드로 읽고, 직접 작성해 배포한 get video comments 도구를 호출하여 수치와 시청자 반응을 함께 근거로 삼는다.

Notion은 더 이상 정보를 넣어두는 수동 문서함에 머물지 않는다. API 하나를 호출할 수 있으면 정기 동기화로 페이지화할 수 있고, 작성할 수 있는 함수라면 에이전트가 호출할 수 있다. 그 결과 분석 결과와 자동화의 출력이 터미널 로그가 아니라 팀이 이미 메모와 함께 일하는 페이지에 남는다.

1. “새 직원”으로 소개된 AI와 Notion의 변화

YouTube 채널의 반복 업무를 담당하는 AI 직원이 Notion 안에 자리 잡으면서 이야기의 출발점이 만들어진다.

1.1. 잠들지 않는 YouTube 채널 분석가

1. AI 직원을 고용했다는 도입

   1. 사람이 아닌 에이전트: 전날 밤 YouTube 채널을 위해 새 직원을 고용했지만 인간이 아니라 AI agent다.
   2. 업로드 이력 추적: 에이전트는 지금까지 만든 모든 영상을 추적한다.
   3. 매시간 갱신되는 수치: 각 영상의 views, likes, comments를 한 시간마다 새로 읽는다.

2. 사람보다 채널 숫자를 잘 아는 직원

   1. 분석 범위: 채널 운영자가 직접 기억하는 것보다 에이전트가 채널 수치를 더 잘 알고 있다.
   2. 다음 행동 제안: 에이전트는 단순히 과거 데이터를 보여주는 데서 멈추지 않고 다음에 만들 영상을 알려준다.
   3. 농담 섞인 인격화: 잠을 자지 않는 직원이 가장 예상하지 못한 사무실, 즉 Notion 안에 살고 있다는 표현으로 자동화의 지속성을 강조한다.

1.2. 실제 화면과 핵심 시연

1. Notion 안에 놓인 채널 대시보드

   1. 한눈에 보이는 행: 채널의 모든 영상이 행으로 들어가고 views, likes, comments가 표시된다.
   2. 자동 갱신: 화면의 수치는 사용자가 CSV를 import하거나 수동으로 새로 고치지 않아도 한 시간마다 갱신된다.
   3. 음악과 함께 전환되는 소개: [음악] 전환 뒤 Notion 화면과 에이전트가 등장하며, 터미널 중심의 일반적인 agent demo와 다른 “사무실” 비유가 이어진다.

2. “다음 영상은 무엇이어야 하는가?”라는 질문

   1. 질문 입력: 에이전트에게 “What should my next video be?”라고 묻는다.
   2. 세 가지 근거: 에이전트는 통계 데이터를 읽고, 직접 만든 도구를 호출하며, 댓글에서 시청자가 요청한 내용을 읽는다.
   3. 최종 답변: 수치와 댓글을 함께 처리한 뒤 다음 영상에 대한 답을 내놓는다.

3. 따라 할 수 있는 범위

   1. 구성 요소: 동기화(sync), 에이전트가 부르는 도구(tool), 최종 custom agent를 모두 만든다.
   2. 구현 규모: TypeScript 파일 한 개와 zero infrastructure가 기준이다.
   3. 일반화된 데이터 원천: 같은 패턴을 은행 계좌 데이터, fitness tracker, production database에도 적용할 수 있다.

2. 기존 Notion API와 Workers가 없애는 인프라

Notion의 변화는 새로운 데이터 접근 API가 아니라, 이미 가능했던 API 사용을 실제로 운영할 수 있게 만든 실행 환경에 있다.

2.1. API는 있었지만 동기화는 어려웠다

1. 수년간 존재한 기본 기능

   1. 페이지 읽기: Notion API로 페이지를 읽는 것은 오래전부터 가능했다.
   2. 페이지 쓰기: 페이지를 생성하거나 내용을 쓰는 것도 가능했다.
   3. 기술적 가능성과 실제 사용의 간극: 따라서 Notion으로 데이터를 끌어오는 것 자체는 늘 가능했지만 실제로 동기화를 구축한 사람은 거의 없었다.

2. 한 번의 API 호출로 끝나지 않는 real sync

   1. 실행 기반: 지속적으로 실행할 server가 필요했다.
   2. 예약: 정해진 주기로 시작할 cron job 또는 별도 schedule service가 필요했다.
   3. 외부 API 보호: rate limiting handling으로 YouTube 같은 API에 요청을 몰아보내지 않아야 했다.
   4. 실패 복구: 일시적 오류를 다룰 retries가 필요했다.
   5. 중복 방지: 이미 가져온 항목을 다시 import하지 않도록 state tracking이 필요했다.
   6. 연결 코드와 호스팅: 각 시스템을 이어 붙이는 glue code가 계속 늘어났고, 그 모든 것을 만든 뒤에도 직접 호스팅해야 했다.

2.2. Workers라는 새로운 primitive

1. Worker의 정체

   1. 작은 프로그램: Worker는 작성자가 직접 쓰는 작은 TypeScript 프로그램이다.
   2. 한 번의 배포: 명령어 하나로 작성한 프로그램을 deploy한다.
   3. Notion의 운영 책임: Notion이 worker를 호스팅하고, 실행하고, schedule하고, 상태를 지켜본다.

2. 플랫폼 기능으로 이동한 반복 작업

   1. 요청 제어: rate limiting이 플랫폼 기능이 된다.
   2. 보안과 실행: auth와 scheduling이 플랫폼에 내장된다.
   3. 데이터 반영과 관찰: upserts와 logs도 플랫폼이 맡는다.
   4. 핵심 효과: 예전에는 작성자의 문제였던 동기화의 지루한 운영 요소가 이제 Worker의 기능이 된다.

2.3. Custom agent의 기존 한계와 Workers의 해법

1. 빠르게 늘어난 no-code 에이전트

   1. 출시 시점: Notion은 custom agents를 몇 달 전에 출시했다.
   2. 사용 규모: 사람들은 이미 100만 개가 넘는 에이전트를 만들었다.
   3. 접근성: 코드를 작성하지 않고 클릭으로 만들 수 있다는 점이 강점이다.

2. 기존 도구에 묶인 손

   1. 사용 가능한 도구의 제한: 에이전트는 이미 존재하는 도구만 사용할 수 있었다.
   2. 기본 connector 사례: Slack, Figma, Linear 같은 Notion built-in connector가 대표적이었다.
   3. 개인 로직의 장벽: 내부 admin panel, 특이한 legacy system, 개인 project, 회사 backend에 접근하려면 사용자가 직접 HTTP server를 호스팅해야 했다.
   4. 반복되는 농담: 필요한 것은 또 하나의 “server”였고, [음악]과 함께 그 장벽이 과장되듯 강조된다.

3. Worker가 연결하는 새 경로

   1. 도구 작성: 필요한 로직을 plain TypeScript로 직접 작성한다.
   2. 배포 위치: 코드를 Notion 서버에 deploy한다.
   3. 에이전트 연결: 배포한 함수를 agent에 곧바로 넘긴다.
   4. 한 문장으로 정리한 pitch: 어떤 데이터든 Notion으로 넣고, 어떤 도구든 agent가 쓰게 한다.

3. YouTube 대시보드와 실시간 댓글 도구의 아키텍처

데이터를 미리 적재하는 sync와 필요할 때 최신 댓글을 조회하는 tool이 서로 다른 역할을 맡지만, 두 기능은 같은 Worker 파일 안에서 함께 운영된다.

3.1. 데이터가 들어오는 경로: 매시간 동기화

1. 정기 실행 흐름

   1. Worker 기상: 매시간 Notion 내부의 Worker가 깨어난다.
   2. YouTube API 호출: Worker가 YouTube API를 호출해 채널 영상을 가져온다.
   3. 데이터베이스 채움: 영상과 통계를 Notion database에 채운다.
   4. 역할 이름: 이 경로가 sync다.

2. 에이전트가 나가는 경로

   1. 신선한 댓글 요청: 에이전트가 최신 comment가 필요할 때 별도의 도구를 부른다.
   2. live 조회: 도구 코드가 YouTube를 실시간으로 호출한다.
   3. Notion 내부 실행: 코드는 노트북에 있지 않고 agent 옆 Notion 안에 deploy되어 있다.
   4. 역할 이름: 이 경로가 tool이다.

3. 운영 결과

   1. 단일 소스 파일: sync와 tool 모두 같은 TypeScript 파일에 있다.
   2. 노트북 독립성: 노트북이 꺼져 있어도 dashboard는 계속 갱신된다.
   3. 구조의 요지: “데이터를 먼저 저장하고 분석하는 경로”와 “질문 순간에 최신 상태를 읽는 경로”를 나누어 오래된 댓글을 불필요하게 전부 저장하지 않는다.

3.2. NTN CLI와 Worker 프로젝트

1. Workspace 연결

   1. 새 CLI: Notion은 NTN이라는 brand-new CLI를 제공한다.
   2. 최초 로그인: NTN login으로 terminal을 workspace에 한 번 연결한다.
   3. 프로젝트 생성: NTN workers new가 TypeScript Worker project를 scaffold한다.

2. 한 파일 중심 구조

   1. 실질적인 핵심 파일: scaffold된 전체 project에서 중요한 파일은 index.ts 하나다.
   2. 등록 가능한 capability: 한 Worker에 sync와 tool을 등록할 수 있고, 원하면 webhook도 등록할 수 있다.
   3. AI 친화적 scaffold: scaffold에는 AI prompts와 skills가 기본으로 들어 있다.
   4. 설계 방향: 문서는 coding agent가 이 코드를 대신 작성할 것을 사실상 전제로 하지만, 모든 줄을 직접 읽어 작동 원리를 파악하는 방식으로 진행한다.

4. TypeScript로 선언하는 database와 sync

데이터베이스의 구조와 실행 방식이 코드에 선언되고, Notion은 그 선언을 실제 표와 페이지로 바꾼다.

4.1. 코드가 곧 데이터베이스 스키마다

1. 화면 클릭 대신 선언

   1. 직접 생성하지 않기: Notion 화면을 열어 new database를 클릭하지 않는다.
   2. TypeScript 선언: database를 TypeScript object로 기술한다.
   3. 자동 구축: Notion이 선언을 읽고 실제 database를 만든다.

2. Property와 사람이 읽는 컬럼명

   1. 컬럼 변환: object 안의 각 property가 실제 database column 하나가 된다.
   2. 표시명 보존: Video ID처럼 공백과 대문자가 있는 이름을 쓴다.
   3. 이름의 의미: 이 값들은 JavaScript variable name이 아니라 사람이 읽을 column header 문자열이다.

3. Unique row를 정하는 key property

   1. 유일성 선언: key property가 어느 column이 row를 unique하게 만드는지 Notion에 알려준다.
   2. 기존 ID: sync가 이미 존재하는 video ID를 보내면 해당 row를 update한다.
   3. 새 ID: 존재하지 않는 video ID를 보내면 새 row를 create한다.
   4. 매시간 실행의 안전성: 이 한 줄 덕분에 수백 개 영상을 매시간 갱신해도 수백 개의 duplicate row가 생기지 않는다.

4.2. Schema 함수와 실제 컬럼 타입

1. 타입을 연결하는 함수

   1. schema.title: database에 정확히 하나만 존재하는 title column을 만든다.
   2. schema.number: 숫자 값을 저장하는 number column을 만든다.
   3. schema.date: 날짜를 저장하는 date column을 만든다.
   4. schema.url: 클릭할 수 있는 URL column을 만든다.

2. 추상 설정이 아닌 구체적 타입

   1. 스키마의 역할: schema 함수는 Notion에 어떤 column type이 필요한지 표현한다.
   2. 결과: TypeScript object는 추상적인 config가 아니라 실제 database type을 구성하는 columns의 선언이다.

4.3. worker.that.sync로 실행을 선언하다

1. 동기화 등록

   1. 이름과 등록: worker.that.sync가 Worker에 sync를 등록하고 이름을 부여한다.
   2. 대상 연결: videos라는 변수로 1단계에서 선언한 database에 연결한다.
   3. 소유권 모드: mode: "replace"는 이 sync가 해당 table을 소유한다는 뜻이다.

2. 한 문자열로 대체되는 예약 시스템

   1. 주기 선언: schedule: "every hour"로 매시간 실행을 지정한다.
   2. 인프라 제거: 이 한 문자열이 별도의 crontab과 schedule service 설정 전체를 대체한다.
   3. 실행 함수: execute 함수 안에서 외부 데이터를 fetch한다.

3. 외부 데이터 호출

   1. 일반 TypeScript 코드: execute는 YouTube를 호출하고 영상 목록과 통계를 가져온다.
   2. Notion 비종속 부분: fetch 자체는 아직 Notion 고유 API가 아닌 평범한 데이터 수집 코드다.
   3. 유일한 추가 관심사: 외부 API를 보호하기 위해 limiter를 함께 사용한다.

5. Pacer, upsert, pagination으로 대량 동기화 안정성 확보

Workers의 핵심은 데이터를 쓰는 API 호출을 늘리는 것이 아니라, 실행 제어와 결과 선언을 플랫폼에 맡기는 방식에 있다.

5.1. Worker.that.pacer와 초당 5회 제한

1. Pacer 선언

   1. 또 하나의 primitive: Worker.that.pacer는 database와 마찬가지로 Notion이 제공하는 primitive다.
   2. 이름과 제한: pacer에 이름과 rate limit을 지정한다.
   3. 설정값: 사용한 설정은 최대 초당 5 requests다.

2. Schedule과 rate limit의 다른 역할

   1. schedule: sync가 얼마나 자주 시작할지만 결정한다.
   2. 실행 중 폭주: 한 번 시작한 함수가 빠르게 많은 요청을 발사하면 YouTube가 요청을 거부할 수 있다.
   3. 호출 전 대기: 각 요청 전에 limiter를 기다리며, 너무 빠르면 해당 줄이 코드 실행을 안전한 시점까지 멈춘다.
   4. 선언적 운영: 직접 rate-limit 로직을 구현하지 않고 제한값만 선언하면 Notion이 집행한다.
   5. 적용 가치: 엄격한 API에서 대량 데이터를 동기화할 때 유용하다.

5.2. 직접 write하지 않고 변경 목록을 반환하다

1. Notion 쓰기 API가 없는 execute

   1. 직접 호출 부재: 함수 안에는 Notion에 직접 쓰는 insert, update, Notion API call이 없다.
   2. 변경 기술: 코드가 해야 할 변화만 기술한다.
   3. 반환값: 변경 목록(list of changes)을 return한다.

2. 각 change의 구성

   1. upsert: 각 change는 upsert이며, 기존 데이터면 갱신하고 없으면 만든다.
   2. key: key는 database의 primary key인 video ID다.
   3. properties: 왼쪽에 column name, 오른쪽에 value를 둔다.
   4. builder 함수: builder 함수가 값을 올바른 Notion data type의 cell로 채운다.
   5. 역할 분리: schema는 column을 설명하고 builder는 cell을 채운다.
   6. 플랫폼 반영: 반환된 object를 Notion이 받아 database를 업데이트한다.

5.3. 한 row가 곧 page가 되는 모델

1. 페이지 속성을 활용한 썸네일

   1. row의 실체: Notion database의 모든 row는 동시에 하나의 page다.
   2. cover 설정: 각 page의 cover를 해당 영상 thumbnail로 지정한다.
   3. 시각적 결과: 데이터 표가 단순 숫자 목록을 넘어 영상 카드 모음으로 변한다.

2. 50개 단위 pagination

   1. 데이터 규모: 채널에 수백 개의 영상이 있다.
   2. 한 번의 한도: 한 번의 run은 50개를 fetch한다.
   3. 다음 상태 반환: 아직 남은 데이터가 있으면 hasMore: true와 다음 페이지 token이 담긴 next state를 반환한다.
   4. 반복 실행: Notion이 이를 보고 함수를 즉시 다시 호출하고, 필요한 만큼 반복한다.
   5. 종료 조건: 각 실행은 다음 page token을 state parameter로 넘기며, hasMore가 false가 될 때 끝난다.

3. Pacer가 필요한 규모

   1. 극단적 예시: 1,000 pages라면 Notion이 가능한 한 빠르게 1,000 calls를 만들 수 있다.
   2. 차단 방지: Pacer가 YouTube의 blocking을 막는 완충 장치가 된다.
   3. 설계 결론: pagination은 데이터 양을 처리하고 pacer는 요청 속도를 처리한다.

5.4. API key와 preview 배포

1. 환경 변수 전달

   1. 로컬 보관: YouTube API key는 local .env 파일에 둔다.
   2. 로컬 실행: 로컬 코드가 .env에서 key를 읽는다.
   3. 배포 환경: 배포된 Worker도 같은 key가 필요하다.
   4. 전달 명령: NTN workers .env push가 local .env를 deployed Worker로 보낸다.
   5. runtime 주입: Notion이 값을 저장하고 runtime에 주입한다.

2. 쓰기 전 preview

   1. 명령어: --preview flag로 sync를 실행한다.
   2. 안전한 확인: 실제로 쓰지 않고 무엇을 기록할지 보여준다.
   3. 검증 결과: 영상 목록과 숫자가 upsert 형태로 표시되며, 올바른지 확인한 뒤 배포한다.

3. 배포와 첫 결과

   1. 명령어: NTN workers deploy가 코드를 bundle하고 upload한 뒤 실행을 시작한다.
   2. 데이터베이스 결과: Notion을 열면 지금까지 만든 모든 영상이 row로 나타난다.
   3. Gallery view: gallery view로 바꾸면 각 card에 영상 thumbnail이 cover로 표시된다.
   4. 숫자 결합: 각 cover 아래에 live numbers가 놓인다.
   5. 운영 약속: server·cron·glue code 없이 TypeScript 파일 하나와 deploy command 하나로 구성되고, 한 시간이 지나면 자동으로 다시 갱신된다.

6. 댓글을 읽는 custom tool과 AI 분석가

통계 대시보드는 무슨 일이 일어나는지 보여주지만 왜 그런지는 말해주지 못한다. 사람들이 무엇을 좋아했고 무엇을 헷갈려 했으며 무엇을 계속 요청하는지는 댓글에 있으므로, 수천 개의 댓글을 전부 저장하는 대신 필요할 때 읽는 tool을 만든다.

6.1. 댓글 전체를 저장하지 않는 이유

1. 대시보드의 한계

   1. 관찰 가능한 것: 대시보드는 조회수 같은 현상을 보여준다.
   2. 빠진 이유: 숫자가 변한 원인은 대시보드만으로 알 수 없다.
   3. 댓글의 정보: 시청자가 좋아한 부분, 혼란스러워한 부분, 반복 요청한 주제가 댓글에 담긴다.

2. Tool에 맡긴 최신성

   1. 규모 문제: 댓글은 수천 개라 database에 모두 sync하고 싶지 않다.
   2. 필요한 방식: 댓글은 미리 적재하는 데이터가 아니라 질문이 생기는 순간 live로 가져오는 데이터로 취급한다.
   3. 위치: tool은 sync 바로 아래, 같은 index.ts와 같은 Worker에 들어간다.

6.2. worker.tool의 계약과 실행

1. 에이전트가 판단하는 설명

   1. 등록 함수: worker.tool이 agent가 호출할 수 있는 함수를 등록한다.
   2. description: description은 AI가 호출 여부를 결정할 때 읽는 instruction이다.
   3. 입력 정의: 각 input description이 해당 field에 무엇을 넣어야 하는지 agent에 알려준다.

2. read-only 안전장치

   1. 힌트: read only hint를 지정한다.
   2. 의미: 이 tool은 데이터를 읽기만 하고 side effect가 없다는 뜻이다.
   3. 권한 흐름: 따라서 agent는 매번 사용자의 permission을 다시 묻지 않고 기본적으로 자유롭게 호출할 수 있다.

3. 평범한 실행 함수와 구조화된 반환

   1. 호출: execution function은 YouTube API를 호출해 comments를 가져온다.
   2. 구조화된 JSON: 결과를 긴 텍스트 벽이 아니라 structured JSON으로 반환한다.
   3. 필드: 각 댓글에 author, text, likes를 담는다.
   4. 에이전트 추론: agent는 결과를 그냥 읽기만 하는 것이 아니라 그 결과를 놓고 reasoning하므로, 구조화된 입력이 더 똑똑한 판단을 돕는다.

6.3. 로컬 테스트와 재배포

1. 도구 단독 확인

   1. 테스트 입력: Cloudflare video의 video ID를 넣어 로컬에서 tool을 실행한다.
   2. 관찰 결과: terminal에 실제 YouTube comments가 출력된다.
   3. 판정: 가짜 fixture가 아니라 실시간 댓글이 반환되므로 함수가 동작함을 확인한다.

2. 변경 사항 배포

   1. 재배포: tool 추가 뒤 Worker를 다시 deploy한다.
   2. CLI 안내: CLI가 변경된 항목을 알려준다.
   3. 변경 내역: 기존 sync 하나와 새 tool 하나가 배포 대상에 표시된다.

7. Channel Analyst 에이전트의 최종 의사결정

Notion custom agent가 database와 Worker tool에 접근 권한을 받아, 수치의 이상 징후와 실제 댓글을 결합해 다음 콘텐츠를 제안한다.

7.1. 클릭으로 만드는 에이전트와 지시문

1. 에이전트 생성

   1. 제품 기능: Custom agents는 Notion 제품이므로 누구나 만들 수 있다.
   2. 생성 방식: 코드를 작성하지 않고 클릭으로 새 agent를 만든다.
   3. 이름: 에이전트 이름을 channel analyst로 지정한다.

2. 운영 지시문

   1. 역할: “You analyze my YouTube channel.”이라는 역할을 준다.
   2. 수치 원천: 성과 데이터를 확인할 때 YouTube dashboard database를 사용하게 한다.
   3. 댓글 원천: 시청자가 무엇을 말하는지 알아야 할 때 get video comments tool을 호출하게 한다.
   4. 근거 규칙: 결론은 항상 numbers로 뒷받침하게 한다.

3. Connections 메뉴 권한

   1. database 권한: dashboard database에 접근하게 한다.
   2. Worker 권한: 방금 배포한 Worker tool에도 접근하게 한다.
   3. 연결 방식: 두 권한 모두 connections menu에서 agent에 직접 부여한다.

7.2. “다음 영상은 무엇이어야 하는가?”의 처리 순서

1. 첫 번째 판단: 대시보드 조회

   1. 질문: 에이전트에게 다시 “What should my next video be?”라고 묻는다.
   2. 검색: 에이전트가 dashboard를 query한다.
   3. 정렬: 조회수 기준으로 영상들을 sort한다.
   4. 비교: 최근 영상 중 예상보다 잘 나오는 over-performing 영상을 찾는다.

2. 두 번째 판단: 댓글 도구 호출

   1. 추가 근거 필요: 숫자만으로는 왜 반응이 좋은지 알 수 없으므로 get video comments tool을 호출한다.
   2. Notion 내부 실행: TypeScript가 노트북이 아니라 Notion의 AI 실행 환경 안에서 실제로 돌아간다.
   3. 내용 분석: tool이 댓글을 가져오고 agent가 댓글을 읽는다.

3. 최종 답변의 성격

   1. 아이디어: 다음 영상 ideas를 제시한다.
   2. 수치 근거: dashboard의 성과 numbers를 근거로 붙인다.
   3. 목소리 근거: 실제 comments를 함께 근거로 붙인다.
   4. 판단 구조: 조회수가 높은 영상을 기계적으로 복제하는 것이 아니라, 최근 성과의 이상 징후를 찾고 그 이유를 댓글에서 확인해 다음 주제로 연결한다.

8. Notion을 프로그래밍 가능한 업무 공간으로 보는 확장

8.1. “넣어두는 곳”에서 “위에 구축하는 곳”으로

1. 제품 정체성의 변화

   1. 이전 모델: 오랫동안 Notion은 정보를 넣어두는 장소였다.
   2. 새 모델: 이제는 그 위에 애플리케이션 로직을 build할 수 있는 장소가 된다.
   3. 핵심 전환: Notion이 programmable해졌다는 한 문장이 Workers와 agents의 의미를 압축한다.

2. 터미널에서 페이지로 이동한 결과

   1. 기존 출력: terminal에 흘러가는 agent 결과는 작업이 끝나면 사라지기 쉽다.
   2. 새 출력: 분석 결과가 메모 옆의 page에 남는다.
   3. 팀의 맥락: 팀이 이미 업무하는 공간에 데이터·판단·기록이 함께 놓인다.

8.2. 같은 패턴의 구체적 적용 예

1. 고객 이탈 감지

   1. 데이터 입력: Stripe payments를 Notion으로 sync한다.
   2. 에이전트 질문: agent에게 곧 churn할 고객이 누구인지 묻는다.
   3. 결합 효과: 결제 추세와 고객 정보를 페이지에서 함께 살필 수 있다.

2. 개발 이슈 처리

   1. 데이터 입력: GitHub issues를 Notion으로 sync한다.
   2. 도구 권한: agent에 이슈를 close하는 tool을 준다.
   3. 행동 범위: 단순 요약을 넘어 외부 시스템을 조작하는 함수까지 연결할 수 있다.

3. 개인 데이터 관리

   1. 건강·재무: gym data와 bank data를 가져올 수 있다.
   2. 취향·학습: reading list도 정기적으로 가져올 수 있다.
   3. 일반 규칙: 호출할 API 하나가 있으면 schedule에 맞춰 Notion으로 pull할 수 있고, 작성할 수 있는 function은 agent가 호출할 수 있다.

8.3. 다음 단계인 Notion Agent SDK

1. 현재 상태

   1. 알파 기능: Notion Agent SDK는 alpha 단계다.
   2. 접근 제한: waitlist 뒤에 있어 지금 바로 모두가 사용할 수 있는 공개 기능은 아니다.
   3. 현재 위치: 지금 만든 agent는 Notion 안에서 산다.

2. SDK가 뒤집는 방향

   1. 호출 주체의 변화: SDK는 외부의 own app이 API를 통해 Notion agent를 호출하는 방향으로 바꾼다.
   2. 배치 장소: 방금 만든 YouTube agent가 개인 website에 나타날 수 있다.
   3. 터미널 활용: 같은 agent를 terminal에서도 호출할 수 있다.
   4. 의미: Notion 내부 업무 공간에서 시작한 agent가 독립 애플리케이션의 기능으로 확장된다.

8.4. 마무리 요청과 후원 고지

1. 시청자에게 던진 질문

   1. 제품 변화에 대한 의견: Notion이 programmable해지는 것에 대해 댓글로 생각을 남겨 달라고 요청한다.
   2. 개발자 플랫폼 체험: description의 링크를 눌러 developer platform을 시도해 달라고 안내한다.

2. 후원과 인사

   1. 후원 고지: Notion이 이 콘텐츠를 sponsor했다는 사실을 밝힌다.
   2. 끝인사: 다음 콘텐츠에서 다시 만나자는 인사와 “Bye-bye”로 끝난다.

주요 발언 모음

“I hired a new employee for my YouTube channel last night. Not a human, an AI agent.”

“Notion became programmable.”

“One file, TypeScript, and zero infrastructure.”

“I don't write the logic. I declare the limit and Notion enforces it.”

“Schema describes the columns, builder fills the cells.”

“Every row in Notion database is also a page.”

“Because agents don't just read results, they reason over them. You give them structure, and they get smarter.”

“For years, Notion was a place you put things into. Now, it's a place you can build on.”

핵심 데이터 & 수치

• 1개 파일: index.ts 하나에 database 선언, sync, tool 같은 capability를 함께 등록한다.
• 0개 인프라: 직접 운영하는 server, cron job, schedule service, 별도 호스팅이 필요 없다는 구성을 제시한다.
• 100만 개 이상: 출시 몇 달 만에 사람들이 만든 Notion custom agent 수가 1 million을 넘었다.
• 1시간: YouTube sync schedule은 every hour이며, 배포 뒤 한 시간이 지나면 자동 갱신된다.
• 초당 최대 5 requests: Worker.that.pacer의 rate limit 설정값이다.
• 50개: 한 번의 sync run이 가져오는 영상 수다.
• 1,000 calls: 1,000 pages를 처리하면 Notion이 최대한 빠르게 1,000번 호출할 수 있다는 규모 예시다.
• 수백 개: YouTube 채널에 이미 존재하는 영상 수를 설명하는 규모다.
• 수천 개: 전부 database에 넣지 않고 tool로 필요할 때 읽기로 한 댓글 규모다.
• 몇 달 전: Notion custom agents가 출시된 시점에 대한 상대적 설명이다.
• Alpha + waitlist: Notion Agent SDK는 아직 alpha이고 waitlist 뒤에 있다.

결론 및 시사점

1. 동기화와 추론을 분리하라

   1. 자주 변하지만 요약·정렬에 필요한 영상 통계는 매시간 database에 sync한다.
   2. 양이 많고 최신성이 중요하며 전부 저장할 필요가 없는 댓글은 read-only tool로 실시간 조회한다.

2. 운영 코드를 플랫폼 primitive로 치환하라

   1. schedule, pacer, key, upsert, next state를 선언하면 반복 실행·속도 제한·중복 방지·pagination을 직접 조립하는 부담이 줄어든다.
   2. --preview로 실제 쓰기 전에 변경을 확인하고 NTN workers deploy로 배포하는 짧은 흐름을 유지한다.

3. 에이전트에는 구조화된 도구 결과를 제공하라

   1. 댓글을 author, text, likes로 반환하면 agent가 자연어 벽보다 관계와 수치를 더 잘 비교할 수 있다.
   2. description, input 설명, read only hint가 호출 판단과 권한 흐름을 결정하므로 도구의 계약을 명확히 작성해야 한다.

4. 숫자와 사람의 목소리를 함께 근거로 삼아라

   1. 조회수 정렬은 어떤 영상이 over-performing인지 찾게 한다.
   2. 댓글 조회는 그 성과가 왜 나왔는지 확인하게 한다.
   3. 두 근거를 결합하면 다음 콘텐츠 선택이 단순 인기 복제가 아니라 데이터와 실제 요구를 반영한 의사결정이 된다.

5. Notion을 업무용 실행 공간으로 확장하라

   1. Stripe·GitHub·gym·bank·reading list처럼 API가 있는 데이터를 정기적으로 페이지화한다.
   2. 에이전트가 이슈 종료, 이탈 고객 식별 같은 맞춤 함수를 호출하게 한다.
   3. 결과가 터미널에 사라지지 않고 기존 노트와 팀 업무 옆에 남으므로 지식과 자동화의 맥락이 연결된다.

6. 외부 앱으로의 확장을 지켜보라

   1. Agent SDK가 waitlist를 벗어나면 Notion 안에서 만든 에이전트를 website·terminal 같은 own app으로 호출할 수 있다.
   2. Workers가 “Notion으로 가져오기”를 열었다면 SDK는 “Notion 에이전트를 바깥에서 부르기”를 열어 양방향 확장의 기반을 만든다.