System Architect이자 전문 해커라면, 각 시스템의 구조와 작동원리를 파악하는 게 설계의 기초이다. Notion은 협업과 GUI를 선호하는 대중이 사용하는 SaaS이며, 최근 Notion AI라는 기능을 덧붙여 최신 상용 LLM들에 대한 AI Wrapper를 Web Interface에서 제공한다. 2026년 초 기준 이미지 생성 기능까지 추가되었다.
나는 유명한 SaaS의 기능 변화를 모니터링하기 위해 Notion도 유료 플랜을 구독하고 있다. 이 글의 목적은 세 가지다.
- Notion AI는 어디까지 써먹을 수 있는가?
- Notion 내부 자동화(Automations)와 Notion API는 각각 무엇이 장점이고 한계는 어디까지인가?
- 이 세 가지 기술적 축은 실제 비즈니스에 대입할 때 구체적으로 어떤 상황에 적합한가?
결론부터 말하면: Notion은 저장소이자 UI이지 실행 환경이 아니다. 이 구조적 원칙을 이해하면, 세 축의 능력과 한계가 자연스럽게 도출된다.
1. Notion AI: 기능 범위와 한계
1-1. Notion AI가 할 수 있는 것
Notion AI는 OpenAI(GPT), Anthropic(Claude), Google(Gemini) 등 복수의 상용 LLM을 라우터 방식으로 통합 제공한다. 사용자는 단일 구독료로 여러 모델에 접근할 수 있으며, Web UI에서 작업별로 모델을 선택할 수 있다.
| 기능 | 설명 | 비고 |
|---|---|---|
| Agent (개인 AI 에이전트) | 멀티스텝 작업 수행: 페이지 생성/편집, DB 구축/수정, 워크스페이스 검색 | 2026년 기준 가장 핵심 기능 |
| Enterprise Search | 워크스페이스 + 연결된 앱(Slack, Google Drive, GitHub 등) 통합 검색 | AI Connector 설정 필요 |
| Research Mode | 워크스페이스·연결 도구·웹에서 심층 조사 후 보고서 생성 | 긴 리서치 문서 초안에 적합 |
| AI Meeting Notes | 회의 녹음 → 자동 전사(transcription) → 요약 → 액션 아이템 추출 | Notion 내 직접 녹음 |
| AI Writing (인라인) | 페이지 내에서 글쓰기 보조, 편집, 톤 조절, 번역 | AI 블록으로 커스텀 출력 가능 |
| Database Autofill | DB 속성을 AI로 자동 채우기 (요약, 분류, 키워드 추출 등) | 수식(Formula) 자동 생성 포함 |
| 이미지 생성 | 텍스트 프롬프트 → 이미지 생성 | 2026년 초 추가 |
| PDF/이미지 분석 | 업로드한 파일의 내용 분석 및 질의응답 |
1-2. Notion AI의 구조적 한계
핵심 제약: Notion AI는 "사용자가 Web UI에서 대화하는" 인터랙티브 모델이다.
| 한계 항목 | 상세 |
|---|---|
| 외부 API 호출 불가 | Notion AI를 외부 스크립트·서버에서 프로그래밍 방식으로 실행시키는 공식 엔드포인트가 없음 |
| 모델 고정 지정 비공식 | Web UI에서는 작업별 모델 선택이 가능하나, 자동화 파이프라인에서 model=claude로 고정하는 API 파라미터가 없음. "항상 Claude로 돌린다"는 품질 제어 변수를 시스템적으로 고정 불가 |
| 인바운드 트리거 부재 | 외부 → Notion으로 "에이전트 실행을 깨우는" 트리거가 1급 기능으로 제공되지 않음 |
| 실행 컨텍스트 제한 | Notion AI는 Notion 워크스페이스 내의 데이터만 컨텍스트로 사용. 외부 DB나 실시간 API 데이터를 직접 참조 불가 |
| 배치 처리 한계 | 대량의 페이지를 일괄 AI 처리하는 공식 배치 API 없음. Autofill은 DB 속성 단위로만 동작 |
2. Notion 내부 자동화 (Automations): 구조와 한계
2-1. 자동화가 할 수 있는 것
Notion의 자동화는 DB 이벤트 기반의 트리거-액션 모델이다.
트리거 (언제 실행되는가):
- 페이지가 데이터베이스에 추가될 때
- 속성 값이 변경될 때 (Status, Select, Date 등)
- 버튼 클릭 시
액션 (무엇을 실행하는가):
- 페이지 속성 수정 (Assign, Status 변경 등)
- 새 페이지 생성
- Slack/이메일 알림 전송
- Webhook 전송 (외부 URL로 HTTP POST)
- AI Autofill 트리거 (수식 기반 자동화 포함)
2-2. Webhook: Notion → 외부 방향
Webhook은 Notion이 외부 런타임을 trigger하는 유일한 공식 경로다.
가능한 것:
- Button 또는 DB 자동화에서 특정 URL로 HTTP POST 요청 전송
- DB 페이지의 속성(properties) 값을 payload에 담아 외부 endpoint로 전송
- Zapier, Make 같은 자동화 플랫폼의 trigger 용도로 활용
- 커스텀 헤더에 Bearer token 등 인증 정보 설정 가능
제한사항:
- POST만 지원 (GET, PUT, DELETE 등 불가)
- 페이지 콘텐츠(body)는 전송 불가 — DB 속성만 전송 가능
- 자동화당 최대 5개 webhook
- 워크스페이스 레벨 webhook 미지원
- 헤더에 넣은 인증 값이 Notion UI에서 평문 노출 (설정 화면 접근 가능자에게)
2-3. 내부 자동화의 구조적 한계
| 한계 항목 | 상세 |
|---|---|
| 이벤트 범위 | DB 속성 변경에만 반응. 페이지 본문(content) 변경은 트리거 불가 |
| 조건 분기 없음 | if-else, 반복(loop), 에러 핸들링 같은 제어 흐름 구조 미지원 |
| 외부 데이터 수신 불가 | 외부 → Notion 방향의 webhook 수신(인바운드) 기능 없음 |
| 코드 실행 불가 | 커스텀 스크립트, 함수 실행 환경 없음 |
| 스케줄링 제한 | cron 기반 정기 실행 없음. 이벤트 기반만 지원 |
3. Notion API: 외부 통합의 원리와 한계
3-1. 핵심 원리
Notion API는 "외부 런타임이 Notion을 읽고 쓰는" 클라이언트-서버 구조이다.
flowchart LR
A["외부 런타임\n(서버, GAS, n8n, 스크립트)"] -->|"HTTP Request\n(Create/Read/Update/Delete)"| B["Notion API\n(REST Endpoint)"]
B -->|"JSON Response"| A
B <-->|"데이터 저장/조회"| C["Notion DB/Pages\n(데이터 저장소)"]
- Notion은 서버(데이터 저장소) 역할
- API 호출 주체는 항상 외부 (서버, GAS, n8n, Python 스크립트 등)
- "Notion이 능동적으로 뭔가를 실행"하는 구조가 아님
3-2. Notion API로 가능한 것
- DB 페이지 생성/수정/조회/삭제 (CRUD)
- DB 스키마 조회 및 필터/정렬 쿼리
- 페이지 콘텐츠(블록) 읽기/쓰기
- 사용자 정보 조회
- 검색 (워크스페이스 내)
- 외부 API(FRED, KOSIS 등) 데이터를 가져와 Notion DB에 적재
- Notion을 Headless CMS, 데이터 저장소로 활용
3-3. Notion API의 한계
| 한계 항목 | 상세 |
|---|---|
| Notion AI 접근 불가 | API로 Notion AI(LLM)를 호출하는 엔드포인트 없음. AI 기능은 Web UI 전용 |
| Rate Limit | 초당 3 요청 제한 (대량 데이터 파이프라인에 병목) |
| 블록 깊이 제한 | 중첩 블록 조회 시 depth 제한 → 재귀 호출 필요 |
| 이미지 URL 만료 | Notion의 이미지 URL은 임시 서명(signed URL) → 시간 경과 시 만료. Headless CMS 사용 시 빌드 타임에 로컬 다운로드 필수 |
| 실시간 이벤트 스트림 없음 | 변경 사항을 실시간으로 수신하는 WebSocket/SSE 미지원. 폴링(polling) 방식만 가능 |
| 인바운드 트리거 없음 | Notion이 외부 변경을 감지해 API를 자동 호출하는 구조 없음. 스케줄링은 외부 책임 |
3-4. Secret Manager/환경변수: 핵심 질문
Notion 내에서 Secret을 안전하게 보관하는 것은 원칙적으로 불가능하다.
| 항목 | Notion 현실 |
|---|---|
| 환경변수 | 없음. Notion은 코드 실행 런타임이 아님 |
| Secret Manager | 없음. 모든 값은 "페이지/속성"으로만 저장 |
| API 키 저장 시 | 페이지 텍스트나 커스텀 헤더 값으로 들어가면 열람 권한 있는 모든 사람에게 노출 |
| 코드 실행 | Notion 내부에서 임의 스크립트 실행 불가 |
→ Secret, 스케줄, 실행 로직은 반드시 외부 런타임의 책임 영역이다.
4. 3축 비교 분석
4-1. 기능 비교 매트릭스
| 비교 축 | Notion AI | Notion 내부 자동화 | Notion API (외부 통합) |
|---|---|---|---|
| 실행 주체 | 사용자 (Web UI에서 대화) | Notion 내부 이벤트 엔진 | 외부 런타임 (서버/스크립트) |
| 트리거 | 사용자의 수동 요청 | DB 속성 변경, 버튼 클릭 | 외부 스케줄러 (cron, GAS trigger 등) |
| LLM 사용 | ✅ 내장 (GPT, Claude, Gemini) | ⚠️ Autofill에서 제한적 | ❌ 직접 불가. 외부에서 별도 LLM 호출 후 결과를 API로 적재 |
| 모델 고정 지정 | ⚠️ UI에서 선택 가능하나 자동화 고정 불가 | ❌ | ✅ 외부 LLM API에서 직접 지정 가능 |
| 코드 실행 | ❌ | ❌ | ✅ 외부 런타임에서 자유 |
| 데이터 접근 | 워크스페이스 내 + 연결 앱 | 해당 DB 속성만 | API 권한 범위 내 전체 (블록 포함) |
| 외부 데이터 통합 | ⚠️ AI Connector로 제한적 검색 | ❌ (Webhook으로 외부 trigger만 가능) | ✅ 외부 API 데이터 수집 → Notion 적재 자유 |
| Secret 관리 | ❌ | ⚠️ 헤더에 평문 노출 | ✅ 외부 런타임의 환경변수/Secret Manager |
| 스케줄링 | ❌ | ❌ (이벤트 기반만) | ✅ 외부 cron/trigger |
| 복잡 로직 | ⚠️ 대화 내에서 가능하나 재현성 낮음 | ❌ 조건 분기 미지원 | ✅ 완전한 프로그래밍 가능 |
| 학습 곡선 | 낮음 (자연어 대화) | 낮음 (GUI 설정) | 높음 (API 개발 필요) |
| 비용 | Notion 유료 플랜 포함 | Notion 유료 플랜 포함 | Notion 유료 플랜 + 외부 인프라 비용 |
4-2. 구조적 원칙 다이어그램
flowchart TB
subgraph Notion["Notion (SaaS)"]
direction TB
UI["Web UI"]
AI["Notion AI\n(LLM Router)"]
Auto["Automations\n(Event → Action)"]
DB["Database / Pages\n(데이터 저장소)"]
WH["Webhook\n(POST only)"]
UI <--> AI
UI <--> Auto
Auto --> WH
AI <--> DB
Auto <--> DB
end
subgraph External["외부 런타임"]
direction TB
Code["코드 실행\n(Python, GAS, n8n)"]
LLM["외부 LLM API\n(Claude, GPT, Gemini)"]
Secret["Secret Manager\n(환경변수, Vault)"]
Sched["스케줄러\n(cron, trigger)"]
end
Code -->|"Notion API\n(CRUD)"| DB
WH -->|"HTTP POST\n(속성만)"| Code
LLM --> Code
Secret --> Code
Sched --> Code
핵심: Notion은 저장소이자 UI이다. 실행 환경이 아니다. Secret, 스케줄, 로직, LLM 호출의 품질 제어는 모두 외부 런타임의 책임이다.
5. 비즈니스 시나리오별 적합 기술 매핑
5-1. Notion AI가 최적인 시나리오
| 시나리오 | 구체적 상황 | 근거 |
|---|---|---|
| 1인 콘텐츠 크리에이터 | 블로그 초안, 뉴스레터 작성, 톤 조절, 번역 | 별도 LLM 구독 없이 GPT/Claude/Gemini를 교차 사용. 문서 맥락을 아는 AI가 더 정확 |
| 소규모 팀 회의 관리 | 회의 녹음 → 자동 전사 → 요약 → 액션 아이템 추출 → DB 관리 | AI Meeting Notes가 올인원으로 처리. 외부 Otter.ai 등 불필요 |
| 워크스페이스 지식 검색 | "지난달 Q3 로드맵에서 뭐가 바뀌었지?" 같은 자연어 질의 | Enterprise Search + AI Connector로 Slack/Drive까지 통합 검색 |
| 리서치 보고서 초안 | 시장 조사, 경쟁사 분석 문서 드래프트 | Research Mode로 워크스페이스+웹 데이터를 종합한 장문 보고서 생성 |
| DB 속성 자동 분류 | 고객 문의 DB에서 카테고리, 긴급도, 요약을 AI로 자동 채우기 | Autofill로 수동 분류 작업 제거 |
적합 조건: 사람이 Notion Web UI 안에서 작업하며, 반복 자동화보다 일회성 지적 노동 보조가 주 목적인 경우.
5-2. Notion 내부 자동화가 최적인 시나리오
| 시나리오 | 구체적 상황 | 근거 |
|---|---|---|
| 프로젝트 상태 알림 | Status가 "완료"로 바뀌면 Slack 채널에 자동 알림 | 트리거(속성 변경) → 액션(Slack 알림)의 단순 구조 |
| 담당자 자동 배정 | 새 작업이 DB에 추가되면 팀별 담당자를 자동 할당 | 규칙 기반 속성 수정. 코드 불필요 |
| 외부 서비스 trigger | 고객 주문 상태가 바뀌면 Webhook으로 Zapier/Make/n8n에 신호 전송 | Notion → 외부 방향의 이벤트 전파. 속성 값만 전달해도 충분한 경우 |
| 수식 기반 자동 갱신 | 날짜 속성과 현재 시간을 비교해 "마감 임박" 상태로 자동 전환 | Formula + Automation 조합 |
적합 조건: 트리거와 액션이 단순·선형적이고, Notion DB 속성 변경만으로 충분한 경우. 조건 분기, 반복, 에러 핸들링이 필요하면 API로 이동.
5-3. Notion API (외부 통합)가 최적인 시나리오
| 시나리오 | 구체적 상황 | 근거 |
|---|---|---|
| 외부 데이터 정기 적재 | FRED/KOSIS API에서 거시경제 지표를 매일 수집해 Notion DB에 자동 저장 | 외부 스케줄러(GAS trigger, cron) + API CRUD |
| Headless CMS 퍼블리싱 | Notion에 글을 쓰면 Astro/Next.js SSR로 웹사이트에 자동 반영 | Notion API로 콘텐츠 조회 → 빌드 파이프라인 (이미지 URL 만료 대응 필수) |
| LLM 품질 제어 파이프라인 | 외부에서 Claude API를 모델 고정 지정으로 호출 → 결과를 Notion DB에 적재 | "항상 Claude 3.5 Sonnet으로" 같은 품질 변수를 시스템적으로 고정 가능 |
| 복합 자동화 워크플로우 | 고객 문의 접수 → 감성 분석 → 우선순위 분류 → 담당자 배정 → Slack 알림 | 조건 분기, 에러 핸들링, 복수 API 호출이 필요. n8n/Make에서 오케스트레이션 |
| 대량 데이터 마이그레이션 | 기존 시스템(Airtable, Google Sheets)에서 Notion DB로 수천 건 일괄 이관 | 스크립트로 배치 처리. Rate limit(3req/s) 고려한 throttling 필요 |
| 양방향 동기화 | Notion DB ↔ 외부 CRM 간 고객 데이터 실시간 동기화 | 폴링 + 변경 감지 로직. 실시간 WebSocket 미지원이므로 near-realtime 수준 |
적합 조건: Secret 관리, 스케줄링, 복잡한 로직, LLM 모델 고정, 외부 데이터 통합 등 Notion 외부의 제어가 필요한 경우.
5-4. 의사결정 플로우차트
flowchart TD
Start["Notion 관련 자동화가 필요하다"] --> Q1{"사람이 Web UI에서\n직접 작업하는가?"}
Q1 -->|"Yes"| Q2{"AI의 지적 노동 보조가\n핵심인가?"}
Q2 -->|"Yes"| A1["✅ Notion AI"]
Q2 -->|"No"| Q3{"DB 속성 변경 → 단순 액션\n구조인가?"}
Q3 -->|"Yes"| A2["✅ Notion 내부 자동화"]
Q3 -->|"No"| A3["✅ Notion API + 외부 런타임"]
Q1 -->|"No"| Q4{"외부 시스템이 Notion을\n읽거나 써야 하는가?"}
Q4 -->|"Yes"| A3
Q4 -->|"No"| Q5{"Notion 내부 이벤트가\n외부를 trigger해야 하는가?"}
Q5 -->|"Yes"| A4["✅ 내부 자동화 Webhook\n+ 외부 런타임"]
Q5 -->|"No"| A5["Notion이 적합한\n도구가 아닐 수 있음"]
6. 핵심 질문: 외부에서 특정 LLM을 고정 지정해 Notion 내부에서 실행 가능한가?
결론: 불가능하다. (2026년 3월 기준)
"Notion AI를 외부(로컬 서버 등)에서 API로 호출해 Notion 내부에서 실행시키되, Web UI처럼 Claude를 고정 지정"이라는 요구는 현재 공식 지원 형태로 보기 어렵다.
핵심 병목 2가지:
- 인바운드 트리거 부재 — 외부 → Notion으로 "에이전트 실행을 깨우는" 트리거가 1급 기능으로 제공되지 않음. Notion의 자동화는 Notion 내부 이벤트(페이지 생성/업데이트, 속성 변경 등) 중심으로 동작한다. "외부 시스템이 Notion 쪽 에이전트를 직접 깨워서 실행"하는 구조가 열려 있지 않다.
- 모델 고정 지정 비공식 — Web UI에서는 작업별 모델 선택 경험이 있더라도, 이를 "외부 호출 + 자동 실행 파이프라인"에서 동일하게 재현할 수 있는 형태(예: API 파라미터로
model=claude고정)는 공식 기능으로 제공되지 않는다.
대안 아키텍처:
flowchart LR
Trigger["외부 트리거\n(cron, webhook)"] --> Runtime["외부 런타임\n(Python, n8n, GAS)"]
Runtime --> LLM["Claude API\n(model=claude-3.5-sonnet)"]
LLM --> Runtime
Runtime -->|"Notion API\n(페이지 생성/수정)"| Notion["Notion DB/Pages"]
외부에서 Claude API를 직접 호출하고, 그 결과를 Notion API로 적재하는 구조. LLM 모델 고정, Secret 관리, 스케줄링 모두 외부 런타임에서 해결한다. Notion은 결과물의 저장소이자 표시 UI 역할만 담당한다.
7. 설계 원칙 요약
Notion = 저장소 + UI. 실행 환경이 아니다.
| 책임 영역 | Notion의 역할 | 외부 런타임의 역할 |
|---|---|---|
| 데이터 저장 | ✅ DB + Pages | API로 CRUD |
| UI/표시 | ✅ Web UI, 공유, 협업 | Headless CMS로 활용 가능 |
| AI 보조 (인터랙티브) | ✅ Notion AI (Web UI 전용) | — |
| 코드 실행 | ❌ | ✅ Python, Node, GAS 등 |
| Secret 보관 | ❌ | ✅ 환경변수, Vault, Secret Manager |
| 스케줄링 | ❌ (이벤트 기반 자동화만) | ✅ cron, GAS trigger, Cloudflare Workers |
| LLM 품질 제어 | ❌ (모델 고정 불가) | ✅ API 파라미터로 모델/온도/토큰 고정 |
| 복잡 로직 | ❌ | ✅ 조건 분기, 루프, 에러 핸들링 |
이 구조적 원칙을 인지하면, Notion을 과대평가하지도 과소평가하지도 않는 정확한 설계 판단이 가능해진다. Notion은 대중이 사용하기에 합리적인 가격의 AI + 협업 + 저장 도구이며, 그 경계를 넘는 자동화는 외부 런타임과의 조합으로 해결하는 것이 올바른 아키텍처다.