글로벌 1위가 Notion을 쓰는 진짜 이유: AI 오케스트레이션 실전 구현

📺 원본 영상: 아직도 페이지 정리만 하세요? 글로벌 1위가 노션을 쓰는 진짜 이유 (AI 오케스트레이션)
🎙️ 채널: 빌더 조쉬 Builder Josh
👤 게스트: 노션다운 이현석
📅 정리 일자: 2026-02-09
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.

개요

Notion은 단순한 문서 정리 도구가 아니다. Claude Code나 Cursor에서 볼 수 있는 AI 오케스트레이션(Orchestration) 개념을 Notion에 구현하면, Notion이 “동료”처럼 일하는 진정한 업무 파트너로 거듭날 수 있다. 본 강연에서는 노션다운의 이현석님이 실제로 구축한 Notion AI 오케스트레이션 시스템을 공개한다. Thread(스레드) 댓글 자동 응답, 월간 성과 리포트 자동 생성 등 실전 사례를 통해, Notion에서 스킬(Skill)을 정의하고 프로토콜(Protocol)에 따라 워크플로우를 실행하는 전체 구조를 상세히 살펴본다.

AI 오케스트레이션이란 무엇인가

멀티 에이전트 개념의 Notion 적용

AI 오케스트레이션은 여러 “부하 직원(Sub-agent)“을 두고 동시에 일을 처리하게 하는 멀티 에이전트 시스템을 의미한다. Claude Code나 최근의 Cursor에서는 이미 이러한 개념이 적용되고 있다. 강연자는 이 개념을 Notion에 그대로 이식했다. Notion은 사용자가 직접 정의해야 하는 프로그램이기 때문에, 오케스트레이션의 역할과 동작 방식을 명확히 설계할 수 있다는 장점이 있다.

강연자는 오케스트레이션을 “그냥 제 동료”라고 표현했다. 상하 관계의 부하 직원이 아니라, 동등한 파트너십 관계에서 함께 일하는 PD 역할을 담당하는 AI인 것이다. Notion에는 아직 공식 에이전트(Agent) 기능이 없지만, 2025년 3월 초에 오픈될 예정이라는 공식 요청 문서가 공개되었다. 강연자는 이 공식 에이전트 출시를 대비해 미리 오케스트레이션 체계를 구축해 놓았다.

큐시트(Cue Sheet) 중심 설계 철학

오케스트레이션 시스템의 핵심은 “큐시트(Cue Sheet)“다. 공연 기획이나 방송 제작에서 사용하는 큐시트는 전체 흐름, 순서, 역할, 지침을 담은 기획 문서다. Notion 오케스트레이션도 마찬가지로, 어떤 프로토콜을 사용할지, 어떤 스킬을 쓸지, 실행을 어떻게 할지, 예상 결과물이 무엇인지를 명시한 큐시트를 먼저 생성한다. 디렉터(사용자)가 큐시트를 승인하면, 오케스트레이터(Notion AI)가 실행하여 최종 산출물(Document)을 만들어낸다.

이러한 설계 방식은 Claude Code의 “플랜 모드(Plan Mode)“와 유사하다. 실제로 강연에서 큐시트가 저장되는 데이터베이스 이름이 “Plan”이라는 점이 언급되었는데, 이는 우연이 아니라 멀티 에이전트 설계의 공통된 패턴이다.

5계층 아키텍처: Instruction → Rulebook → Agent → Protocol → Toolkit

Notion 오케스트레이션은 다섯 개의 계층으로 구성된다. 각 계층은 상위에서 하위로 참조되며, 최하위 계층인 Toolkit이 실제 작업을 수행한다.

1계층: Instruction (지침)

Instruction은 Notion에서 제공하는 “개인화 지침” 기능이다. Claude Code로 비유하면 claude.md 파일과 같은 역할을 한다. 전체 Notion 워크스페이스에 딱 하나만 존재하며, 모든 스킬 실행 시 무조건 참조된다. 강연자는 지침이 너무 길어지면 AI가 중간 부분을 건너뛰는 문제를 막기 위해, 지침의 세부 내용을 다음 계층인 Rulebook으로 분리했다.

2계층: Rulebook (헌법)

Rulebook은 Notion 에이전트가 무조건 예외 없이 지켜야 하는 규칙을 담은 “헌법”이다. 지침이 전체적인 방향성을 제시한다면, Rulebook은 구체적인 행동 규칙을 명시한다. 강연자는 다음과 같은 Rulebook 문서들을 공개했다.

Entry Point: 어떤 요청이 들어왔을 때 어떤 스킬로 라우팅할지 판단하는 문서. 레벨(Level) 개념을 도입하여 작업의 복잡도를 분류한다.
시스템 설정 규칙: Notion 페이지 생성 시 네이밍 규칙, 순차 로드 규칙 등 기본 규칙.
자가 점검(Self-Check): AI가 작업을 진행하면서 스스로 체크리스트를 확인하도록 강제하는 규칙. “올바른 문서를 로드했는지”, “사용자 요청을 정확히 파악했는지”, “레벨 문서를 확인했는지” 등을 체크하고, 누락 시 다시 반복(루프)하도록 설계되어 있다.

Rulebook은 무조건 다 참조된다. 100% 참조를 보장하기 위해, Entry Point에서 모든 내용을 읽고 자가 점검을 수행하도록 설계되어 있다. 이는 컨텍스트 관리를 위한 분할 전략이기도 하다.

3계층: Agent (에이전트)

Agent 계층은 아직 Notion에 공식 기능으로 존재하지 않는다. Notion Agent는 2025년 3월 초에 출시될 예정이다. Agent는 **페르소나(Persona)**를 담당한다. 예를 들어 “너는 전문 디자이너야”, “너는 경제 애널리스트야” 같은 역할을 부여하는 것이다. 또한 Notion Agent에는 트리거(Trigger) 기능이 있어, 페이지가 실행되었을 때 또는 특정 시간에 자동으로 실행되도록 설정할 수 있다.

강연자는 현재 Agent 계층 대신 오케스트레이션 문서 내에 전문 페르소나를 정의해 두었다. 공식 Agent 기능이 출시되면, 이 부분을 별도 계층으로 분리할 계획이다.

4계층: Protocol (프로토콜)

Protocol은 워크플로우(Workflow) 그 자체다. 업무를 어떻게 제어할지, 어떤 순서로 진행할지를 정의한다. 강연자는 다섯 가지 워크플로우 패턴을 제시했다.

워크플로우	설명	비유
Linear	순차 실행. Skill → Skill → Skill 형태로 단순하게 진행	직렬 방식
Multiplex	병렬 실행. 여러 작업을 동시에 분산하여 처리	병렬 방식
Harmony	집계 방식. 여러 결과를 모아 다수결, 가중투표, 만장일치 등으로 판단	합의 방식
Organizational	계층 위임. 상위 에이전트가 하위 에이전트에게 작업을 위임	조직도 방식
Refine	반복 개선. 결과가 만족스러울 때까지 계속 재실행	루프 방식

이 다섯 가지 패턴은 Claude Code나 기타 멀티 에이전트 시스템에서도 동일하게 사용되는 보편적인 설계 방식이다. Notion 오케스트레이터는 사용자의 요청을 분석하여 적합한 워크플로우를 자동으로 선택한다.

5계층: Toolkit (액션, 스킬, 템플릿)

Toolkit은 실제 작업을 수행하는 최하위 계층이다. 세 가지 구성 요소가 있다.

Action: Protocol을 더 잘게 쪼갠 것. Protocol이 너무 길어져 AI가 읽지 못하는 문제를 방지하기 위해 분리했다.
Skill: 직접 실행 가능한 도구. 예를 들어 “Thread 댓글 작성 스킬”, “월간 리포트 생성 스킬” 등이 있다.
Template: 최종 산출물의 양식. 예를 들어 “기획서 템플릿”, “리포트 템플릿” 등이 있다.

스킬과 템플릿은 독립적으로 관리되며, 여러 스킬에서 하나의 템플릿을 공유할 수 있다. 강연자는 Notion의 관계형(Relational) 데이터베이스 기능을 활용하여 스킬, 템플릿, 프로토콜을 서로 연결(멘션)했다. 이렇게 하면 AI가 관계형 구조를 읽고 전체 흐름을 훑어 최종 산출물을 낼 수 있다.

실전 사례 1: Thread 댓글 자동 응답 시스템

문제 정의: 댓글 답변의 고통

강연자는 Thread(스레드)에서 콘텐츠를 운영하면서 댓글에 대댓글을 다는 것이 매우 고통스러운 작업임을 깨달았다. 글을 쓰는 것은 괜찮지만, 수십 개의 댓글에 일일이 답변을 달다 보면 손이 아프고 시간도 많이 소요된다. 특히 중견 크리에이터의 경우, 하나의 글에 50개 이상의 댓글이 달리기도 한다.

단순히 AI 도구로 댓글을 생성하면 “AI스러운” 댓글이 남는다는 문제가 있다. 강연자는 이 문제를 해결하기 위해, 맥락(Context)을 파악하고 톤 앤 매너(Tone & Manner)를 판단하는 댓글 자동 응답 시스템을 구축했다.

Thread 인사이트 데이터베이스 구조

강연자는 Thread API와 Make(메이크) 자동화를 연동하여, 매일 Thread의 모든 데이터를 Notion으로 가져온다. 다음과 같은 데이터베이스가 구축되어 있다.

Thread 데이터베이스: 각 게시물의 텍스트, 이미지/영상 여부, 포스팅 일시, 조회수, 좋아요, 댓글 수, 인용, 공유 수 등을 기록.
Reply(댓글) 데이터베이스: Thread 데이터베이스와 관계형으로 연결되어, 각 게시물에 달린 댓글을 모두 저장. 댓글 작성자(사용자)도 함께 기록.
ER(Engagement Rate): 좋아요 수와 댓글 수를 더한 값을 조회수로 나눈 참여율.
팔로워 통계: 성별(Gender Breakdown), 연령대(Age Breakdown) 등 팔로워의 인구통계학적 정보를 매일 업데이트.
Daily Report: 일별 조회수, 좋아요, 인용 등의 증감을 기록.

이 모든 데이터는 자동화(Make)로 처리되며, 100% 정확해야 하기 때문에 AI가 아닌 자동화 스크립트가 담당한다.

댓글 대댓글 생성 스킬의 동작 원리

강연자가 실제로 사용 중인 “Thread 댓글 대댓글 생성 스킬”의 동작 과정은 다음과 같다.

1. 프롬프트 입력

사용자가 Notion AI를 실행하고 다음과 같은 프롬프트를 입력한다.

1. 첫 번째 지침을 참조해
2. 아래 Thread 댓글에 대한 대댓글을 작성해
[댓글 내용 복사 붙여넣기]

“첫 번째 지침을 참조해”라는 문구를 명시적으로 넣는 이유는, AI가 가끔 지침을 참조하지 않는 경우가 있기 때문이다. 계속 사용하다 보면 참조율이 높아지지만, 초기에는 이렇게 강제하는 것이 안전하다.

2. Entry Point 참조 및 스킬 로드

오케스트레이터가 Entry Point 문서를 읽고, “Thread 댓글 대댓글 생성” 스킬을 로드한다. 레벨을 분석하여 레벨 1(단순 작업)로 판단하고, 워크플로우는 Linear(순차 실행)로 선택한다.

3. 트리거 매핑 및 병렬 탐색

스킬은 Reply 데이터베이스에 접근하여 강연자가 작성한 댓글 패턴을 학습한다. 리미트 50개까지 자신의 댓글을 읽어 톤 앤 매너를 파악한다. 그런 다음, 원글에 댓글을 단 사용자들을 병렬(Multiplex) 방식으로 검색한다. 각 사용자가 얼마나 많은 댓글을 달았는지, 어떤 관계인지를 파악하기 위함이다.

예를 들어, 강연에서 언급된 예시는 다음과 같다.

사용자 A: 댓글 2회 → 일반 구독자, 첫 상호작용
사용자 B: 댓글 4회 → 적극 지지자
사용자 C: 댓글 28회 → 친한 동료(강연자가 유일하게 반말하는 사용자)

이렇게 맥락을 파악한 후, 각 댓글에 대해 다섯 가지 버전의 대댓글을 생성한다.

4. 다섯 가지 대댓글 버전 생성

각 댓글마다 다음 다섯 가지 스타일의 대댓글이 자동 생성된다.

짧고 캐주얼(Short & Casual): 간단한 인사나 공감 표현
본격적(Formal): 정중하고 진지한 응답
위트 있는(Witty): 유머를 섞은 응답
감사 및 격려(Gratitude & Encouragement): 고마움과 응원의 메시지
질문 유도(Question Prompting): 추가 질문을 던져 대화를 이어가는 형태

강연자는 이 중 하나를 선택하거나, 내용을 참고하여 수정한 후 실제 댓글로 달 수 있다. 댓글이 많이 달렸을 때 하나의 스타일만 제공하면 선택지가 좁기 때문에, 다섯 가지를 제공하여 유연성을 높인 것이다.

5. 자가 점검 및 재실행

스킬 실행 중 자가 점검 단계가 있다. “원글 댓글을 파악했는지”, “패턴 학습을 완료했는지” 등을 체크하고, X(실패) 표시가 나오면 다시 루프를 돌린다. 강연 중 실제로 패턴 학습이 실패하여 재실행되는 과정이 보였다.

스킬 문서의 구조

강연자가 생성한 “Thread 댓글 대댓글 생성 스킬” 문서는 다음과 같은 구조를 가진다.

개요(Overview): 이 스킬이 무엇을 하는지 한 줄 설명
TL;DR: 핵심 요약
입력(Input): 어떤 데이터를 입력받는지 명시
출력(Output): 어떤 결과물을 생성하는지 명시
패턴(Pattern): 다섯 가지 스타일 정의
실행 프로세스(Execution Process): 단계별 처리 방법
- 자신의 글: 리미트 50개까지 커리(Query)로 읽기
- 대댓글: 전부 읽기(리미트 100개)
- 사용자 분류: 일반 구독자(1~2회), 적극 지지자(3회 이상), 친한 동료(특정 사용자)
자가 점검(Self-Check): 체크리스트
관련 문서(Related Documents): 이 스킬이 참조하는 다른 문서들을 멘션
변경 로그(Change Log): 버전별 수정 내역

특히 변경 로그에는 초기에 세 문장으로 생성했다가 다섯 문장으로 늘린 것, 초기에 Linear 워크플로우를 사용했다가 Multiplex로 변경한 것 등이 기록되어 있다. 초기에는 커리 리미트가 100개였는데, 특정 사용자가 90개 이상의 댓글을 달면 다른 사용자의 댓글이 7개밖에 검색되지 않는 문제가 발생했다. 이를 해결하기 위해 병렬 방식으로 변경했다는 내용도 포함되어 있다.

실제 결과물

강연 중 실시간으로 생성된 대댓글은 매우 자연스럽고, “내가 직접 썼을 법한” 느낌이었다. 강연자는 “이거를 읽다 보면 나라도 이렇게 달았는데? 라는 생각이 든다”고 말했다. 이는 단순히 AI가 문장을 생성하는 것이 아니라, 강연자의 과거 댓글 패턴을 학습하고 상대방과의 관계를 파악하여 맞춤형으로 생성했기 때문이다.

실전 사례 2: 월간 리포트 자동 생성

월간 리포트 생성 프로세스

강연자는 Thread 월간 성과를 분석하는 리포트도 자동으로 생성한다. 예를 들어 “2026년 1월 리포트”는 다음과 같은 내용을 담고 있다.

해당 월에 작성한 글 중 조회수가 가장 높은 글
좋아요가 가장 많은 글
ER(Engagement Rate)이 가장 높은 글
어떤 성과를 냈는지 요약
향후 개선 방향 제안

과거에는 Make(메이크)에서 모듈을 설정하고 프롬프트를 작성하여 자동화로 처리했다. 하지만 이제는 Notion 오케스트레이션으로 바뀌었다. 강연자는 단순히 “1월 분석을 해줘”라고 요청하면, 오케스트레이터가 Thread 데이터베이스와 Reply 데이터베이스의 관계형을 파악하고 데이터를 읽어 리포트를 자동 생성한다.

스킬 생성 스킬: 메타 프로그래밍

강연에서 가장 흥미로운 부분은 “스킬을 만드는 스킷”이 존재한다는 점이다. 강연자는 실시간으로 “Thread 월간 분석 리포트 스킬”을 새로 만드는 과정을 시연했다.

1. 프롬프트 입력

1. 지침을 참조해
2. Thread 월간 분석 리포트 스킬을 만들어
3. Thread 데이터베이스를 참조하게 해

2. 자가 점검 및 Entry Point 확인

오케스트레이터는 Entry Point를 읽고, 이 작업이 **레벨 2(문서 작성)**에 해당한다고 판단한다. 레벨 2 작업은 “지침을 만드는 작업”이므로, “문서 작성” 스킬을 로드한다.

3. 기존 스킬 확인

오케스트레이터는 이미 “월간 리포트 스킬”이 존재하는지 확인한다. 만약 존재한다면, 다음 옵션을 제시한다.

기존 스킬 사용
기존 스킬 수정
새 스킬 생성

강연자는 “새 스킬 생성”을 선택했다.

4. 큐시트 생성 및 승인

오케스트레이터는 다음과 같은 큐시트를 생성한다.

Q1: 스킬 차별화 포인트 정의
Q2: 스킬 문서 작성
Q3: 템플릿 분리 여부 판단
Q4: Entry Point 등록

강연자는 “매 큐마다 확인”을 선택했다. 원래는 “확인 없음”을 선택하여 AI가 혼자 다 만들게 하지만, 시연을 위해 단계별로 확인했다.

5. Q1: 스킬 차별화 포인트

오케스트레이터는 기존 월간 리포트 스킬과의 차이점을 정의했다. 기존 스킬은 Thread 글만 분석했지만, 새 스킬은 Reply 데이터베이스까지 참조하여 강연자가 쓴 댓글까지 함께 분석한다.

6. Q2: 스킬 문서 작성

오케스트레이터는 “스킬 문서 작성” 스킬을 참조하여, 스킬 문서의 구조를 생성한다. 여기에는 다음이 포함된다.

성과 분석 (조회수, 좋아요, ER 높은 글 추출)
Reply까지 포함한 전체 인게이지먼트 분석
분석 흐름을 보여주는 순서도(Flowchart)

강연자는 “순서도까지 그려준다”며 놀라워했다. 실제로 생성된 스킬 문서에는 “어떤 순서로 분석할지”를 시각화한 다이어그램이 포함되어 있었다.

7. Q3: 템플릿 분리

오케스트레이터는 템플릿이 복잡하면 별도 페이지로 분리하고, 간단하면 스킬 문서 안에 포함시킨다. 이번 경우 템플릿이 복잡하다고 판단하여 별도로 “월간 리포트 템플릿” 페이지를 생성했다. 생성된 템플릿은 자동으로 스킬 문서의 “관련 툴킷” 관계형 필드에 연결(멘션)된다.

8. Q4: Entry Point 등록

마지막으로, 새로 생성한 스킬을 Entry Point 문서에 등록하여, 이후 “월간 리포트 만들어줘” 같은 요청이 들어오면 자동으로 라우팅되도록 한다.

스킬 생성 스킬의 지침

강연자는 “스킬 문서 작성” 스킬의 내용도 공개했다. 이 스킬은 다음과 같은 규칙을 포함한다.

Heading 규칙: Heading 1은 사용하지 않고, Heading 2는 무조건 노란색, Heading 3는 무조건 파란색으로 설정.
디자인 지침: Notion 페이지의 일관된 디자인을 유지하기 위한 스타일 가이드.
문서 작성 지침: 스킬 문서에 반드시 포함해야 할 섹션(개요, 입력, 출력, 실행 프로세스, 자가 점검, 관련 문서, 변경 로그 등).
템플릿 분리 규칙: 템플릿이 복잡하면 별도 페이지로 분리하고, 간단하면 스킬 문서 안에 포함.

이 모든 것이 스킬 문서 작성 스킬 안에 정의되어 있다. 즉, 메타 프로그래밍 수준의 자동화가 이루어진 것이다.

기술적 구현: 관계형 데이터베이스와 멘션(Mention)

Notion의 관계형 기능 활용

Notion은 본질적으로 관계형 서비스다. 페이지와 페이지, 데이터베이스와 데이터베이스를 관계형(Relation)으로 연결할 수 있다. 과거에는 이 관계형 구조가 사용자의 머릿속에만 존재했고, 문서화도 수동으로 해야 했다. 하지만 Notion AI가 도입되면서, AI가 관계형 구조를 읽고 전체 흐름을 파악하여 자동으로 산출물을 낼 수 있게 되었다.

강연자는 모든 문서 안에 관련 문서를 멘션(@)으로 연결해 두었다. 예를 들어, “Thread 댓글 대댓글 생성 스킬” 문서는 다음과 같은 멘션을 포함한다.

@Entry Point
@Rulebook
@Thread 데이터베이스
@Reply 데이터베이스
@스킬 문서 작성 스킬
@큐시트 생성 스킬

이렇게 하면 AI가 문서를 읽을 때 자동으로 관련 문서를 찾아 참조할 수 있다. 강연자는 “이게 초기 설계자만 쓸 수 있는 구조가 되어 버렸다”며, “고두화(고도화)“되어 나중에 다른 사람이 이해하기 어려울 수 있다고 우려했다. 이를 해결하기 위해 2월 말 웨비나에서 전체 구조를 공개하고 무료로 배포할 예정이다.

컨텍스트 관리 전략

AI가 긴 문서를 읽을 때 중간 부분을 건너뛰는 문제(Context Window 한계)를 해결하기 위해, 강연자는 문서를 계층적으로 분리했다.

Instruction: 전체 방향성 (짧게 유지)
Rulebook: 세부 규칙 (여러 문서로 분리)
Protocol: 워크플로우 (상위 개념만 기술)
Action: Protocol을 더 잘게 쪼갠 것 (구체적 단계)
Skill: 실행 가능한 단위 (독립적으로 관리)
Template: 산출물 양식 (재사용 가능)

이렇게 하면 AI는 필요한 부분만 선택적으로 읽을 수 있다. Entry Point에서 적합한 스킬을 라우팅하고, 해당 스킬이 참조하는 문서만 읽으면 되므로, 전체 컨텍스트를 한 번에 로드할 필요가 없다.

디렉터와 오케스트레이터: 파트너십 관계

역할 분담

Notion 오케스트레이션에서는 두 가지 역할이 존재한다.

역할	담당자	역할
Director(디렉터)	사람(사용자)	총감독. 요청을 전달하고, 큐시트를 승인/거부하며, 최종 결과물을 인수한다.
Orchestrator(오케스트레이터)	Notion AI	PD 역할. 지침, Rulebook, Protocol, Toolkit을 참조하여 큐시트를 설계하고, 승인 후 실행한다.

강연자는 이 둘을 동등한 파트너십 관계로 정의했다. 상하 관계의 부하 직원이 아니라, 함께 일하는 동료인 것이다. 디렉터가 “이렇게 해줘”라고 요청하면, 오케스트레이터는 “이렇게 하면 어때요?”라는 큐시트를 제안한다. 디렉터가 승인하면 실행하고, 거부하면 다시 큐시트를 수정한다.

큐시트 승인 프로세스

큐시트 승인 방식은 두 가지가 있다.

확인 없음: 오케스트레이터가 큐시트를 만들고 바로 실행. 사용자는 최종 결과물만 받음.
매 큐마다 확인: 각 단계(Q1, Q2, Q3, …)마다 사용자가 승인해야 다음 단계로 진행.

강연자는 평소에는 “확인 없음”으로 사용하지만, 시연을 위해 “매 큐마다 확인”을 선택하여 과정을 보여주었다. 이는 Claude Code의 자율 모드(Autonomous Mode)와 스텝 바이 스텝 모드(Step-by-step Mode)의 차이와 유사하다.

갭(Gap) 발생 시 대응

작업 중 “스킬이 없네?”라는 갭이 발생할 수 있다. 이때 오케스트레이터는 해당 스킬을 즉시 만든 다음, 다시 올라가서 디렉터의 허락을 받고, 새로 만든 스킬을 로드하여 계속 진행한다. 이는 멀티 에이전트 시스템에서 “동적 스킬 생성(Dynamic Skill Generation)” 패턴에 해당한다.

조직도의 변화: 1명이 전체 조직을 운영하다

소름 돋는 깨달음

강연자는 오케스트레이션 구조를 그리다가 “소름 돋는 깨달음”을 얻었다고 말했다. 전통적인 조직도는 다음과 같다.

대표
 ├── 이사
 │    ├── 부장
 │    │    ├── 과장
 │    │    │    ├── 대리
 │    │    │    │    └── 직원

그런데 Notion 오케스트레이션에서는 대표 자리에 사람이 딱 한 명(강연자 본인)만 있고, 나머지는 모두 AI와 자동화로 채워진다. 이사, 부장, 과장, 대리, 직원 역할을 각각 Rulebook, Agent, Protocol, Action, Skill이 담당하는 것이다.

강연자는 “이거를 보고 진짜 많이 변하고 있구나라는 생각이 들었다”고 말했다. 호스트인 빌더 조쉬도 “Claude Code 콘텐츠를 찍으면서 똑같은 느낌을 받았다”며 공감했다.

품질 검수와 감리(Inspector)

멀티 에이전트 시스템에서는 처음에는 잘 작동하다가, 점차 할루시네이션(Hallucination)이 발생하여 서로 소통이 안 되는 경우가 생긴다. 이를 방지하기 위해 품질 검수 장치가 필요하다. Claude Code에서는 “후크(Hook)” 개념이 도입되었는데, 서브 에이전트 간 작업이 제대로 넘어갔는지, 알림이 잘 되고 있는지, 완료가 제대로 되었는지를 확인한다.

Notion 오케스트레이션에서는 자가 점검(Self-Check) 단계가 이 역할을 담당한다. 각 스킬 실행 중 체크리스트를 확인하고, 실패 시 다시 루프를 돌리는 방식이다. 강연자는 이를 “감리”라고 표현했으며, 향후 업데이트에서 더 강화할 계획이라고 밝혔다.

노다의 방주(Noah’s Ark): 커뮤니티와 공개 계획

노다의 방주란?

노다의 방주는 강연자가 운영하는 프리미엄 멤버십 커뮤니티다. 매년 3월과 9월에 모집하며, 2월에 사전 모집이 시작된다. 이 커뮤니티는 단순히 Notion 사용법을 알려주는 것이 아니라, “치트키”를 제공한다. 즉, 사업을 어떻게 시스템으로 설계할지, Notion과 Make를 어떻게 연동하여 자동화할지를 가르친다.

강연자는 “변하지 않는 것에 집중해야 한다”는 철학을 강조했다. 과거에는 Notion의 근본적인 부분—데이터베이스 설계, 스키마 디자인, 순서도 작성 등—만 다루었다. 하지만 Notion AI와 오케스트레이션의 등장으로, 이제는 일하는 방식 자체가 재편될 수 있다고 본다. 노다의 방주 3기에서는 Notion AI, Agent, Orchestrator 등 새로운 커리큘럼이 추가될 예정이다.

2월 말 웨비나: 무료 공개

강연자는 2월 말에 웨비나를 진행하여, 오늘 강연에서 보여준 오케스트레이션 체계를 무료로 공개할 예정이다. 이 시스템은 원래 미리(장미리)님이 처음 만들었고, 강연자가 테스트하면서 부족한 부분(주약, 프로토콜)을 추가하여 디벨롭(Develop)시킨 것이다. 2월 말 웨비나에서는 최신 버전을 배포할 계획이다.

호스트인 빌더 조쉬는 “무료예요?”라며 놀라워했고, 강연자는 “네, 무료입니다”라고 답했다. 빌더 조쉬는 “여러분도 이거 한번 써보셔서, 내가 이 엄청나게 많은 일을 할 수 있는 걸? 이런 생각을 꼭 경험해 보셨으면 좋겠다”고 말했다.

핵심 인사이트: Notion이 진짜 비서가 되는 순간

단순한 도구에서 동료로

Notion은 오랫동안 “문서 정리 도구”, “프로젝트 관리 도구”로 인식되어 왔다. 하지만 강연자가 보여준 오케스트레이션 시스템은 Notion을 **“동료”**로 격상시킨다. 사용자가 요청하면, Notion AI는 지침을 읽고, Rulebook을 확인하고, 적합한 Protocol을 선택하고, Skill을 로드하여 작업을 수행한다. 심지어 필요한 스킬이 없으면 스스로 만들어낸다.

이는 더 이상 “도구를 사용하는” 수준이 아니라, “동료와 협업하는” 수준이다. 디렉터(사용자)는 방향만 제시하고, 오케스트레이터(Notion AI)가 구체적인 실행 계획을 짜고 실행한다. 큐시트 승인 과정은 마치 PD가 기획서를 올리고 총감독이 승인하는 방송 제작 과정과 흡사하다.

크리에이터와 기업에게 주는 의미

강연 중 호스트는 “소위 말하는 중견 크리에이터에게 정말 필요한 부분”이라고 평가했다. 댓글이 하루에 50개씩 달리는 크리에이터에게, 단순히 AI가 생성한 “AI스러운” 댓글이 아니라, 맥락을 파악하고 톤 앤 매너를 맞춘 댓글을 자동 생성해 준다는 것은 엄청난 생산성 향상이다.

기업 입장에서도 마찬가지다. 월간 리포트를 자동 생성하고, 댓글 응답을 자동화하고, 필요한 스킬을 스스로 만들어내는 시스템은 사장님들이 좋아할 만한 자동화다. 강연자는 “시스템이 있다면 꿈꿀 수 있는 여유가 생긴다”고 말했다. 병목을 시스템에 위임하고, 사람은 더 창의적인 일에 집중할 수 있다는 것이다.

멀티 에이전트 설계의 보편성

강연을 통해 드러난 또 하나의 인사이트는, 멀티 에이전트 설계 방식이 플랫폼을 가리지 않는다는 점이다. Claude Code, Cursor, Notion 모두 다음과 같은 공통 패턴을 공유한다.

계층적 구조: Instruction → Rulebook → Agent → Protocol → Skill
워크플로우 패턴: Linear, Multiplex, Harmony, Organizational, Refine
큐시트(Plan) 생성: 실행 전 계획 수립 및 승인
자가 점검: 품질 검수를 위한 체크리스트
메타 프로그래밍: 스킬을 만드는 스킬

강연자는 “클로드 코드랑 너무 똑같다”, “비슷하고 닮았다”는 말을 여러 번 들었다. 실제로 큐시트를 저장하는 데이터베이스 이름이 “Plan”이라는 점, Entry Point가 라우팅 역할을 한다는 점, 다섯 가지 워크플로우 패턴 등은 Claude Code의 설계 철학과 일치한다.

변하는 것과 변하지 않는 것

강연자는 “빨리 변하는 시기에는 변하지 않는 것에 집중해야 한다”고 말했다. Notion의 근본적인 기능—데이터베이스, 관계형, 순서도—은 변하지 않는다. 하지만 AI가 도입되면서, 이 근본적인 기능들이 새로운 방식으로 조합될 수 있게 되었다.

강연자가 구축한 시스템은 Notion의 기본 기능(관계형, 멘션, 데이터베이스)과 Notion AI의 언어 이해 능력을 결합한 결과물이다. 새로운 기술(AI)이 기존 인프라(Notion)와 만나 완전히 새로운 가치를 만들어낸 사례다.

마무리: “엄청나게 많은 일을 할 수 있는” 미래

강연의 마지막 부분에서 호스트는 “여러분도 이거 한번 써보셔서, 내가 이 엄청나게 많은 일을 할 수 있는 걸? 이런 생각을 꼭 경험해 보셨으면 좋겠다”고 말했다. 이는 단순히 도구를 홍보하는 말이 아니라, 일하는 방식의 근본적인 변화를 체험해 보라는 권유다.

강연자가 보여준 시스템에서 가장 인상적인 부분은, “스킬을 만드는 스킬”이 존재한다는 점이다. 사용자가 새로운 작업을 요청하면, 시스템은 기존 스킬을 확인하고, 없으면 즉시 만들어낸다. 이는 더 이상 사용자가 “도구를 학습”할 필요가 없다는 뜻이다. 도구가 사용자에게 맞춰 스스로 진화하는 것이다.

Notion 공식 에이전트가 출시되면, 이 시스템은 더욱 강력해질 것이다. 트리거 기능이 추가되어 특정 시간에 자동으로 리포트를 생성하거나, 페이지가 업데이트될 때마다 자동으로 댓글을 분석하는 등의 작업이 가능해진다. 강연자는 “그때 다시 불러주시면 오겠습니다”라고 말했는데, 그때가 되면 또 한 번의 혁신이 일어날 것으로 기대된다.

📚 출처 및 참고

구분	내용
원본 영상	아직도 페이지 정리만 하세요? 글로벌 1위가 노션을 쓰는 진짜 이유 (AI 오케스트레이션)
채널	빌더 조쉬 Builder Josh
게스트	노션다운 이현석
리포트 작성	2026-02-09
작성 방식	YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용과 시연 화면은 원본 영상을 참조해 주세요.

Hermes Bot Mode 출시! AI 직원끼리 협업 더 쉬워졌습니다

DarkGarden

Topics

Sections

아직도 페이지 정리만 하세요? 글로벌 1위가 노션을 쓰는 진짜 이유 (AI 오케스트레이션)