노션 AI 에이전트는 매일 반복되는 스탠드업 미팅 준비, 진행 상황 보고, 코드 리뷰 요약 같은 엔지니어링 잡무를 사람 대신 처리하는 자율 워크플로우 도구입니다. Notion AI 리드 Ryan Nystrom이 공개한 사내 사례를 기반으로 보면, 매일 아침 자동 생성되는 "Standup Pre-read"부터 Notion 댓글에서 @Codex 한 줄로 20분 만에 PR이 만들어지는 시스템까지 구축할 수 있습니다.
이 가이드는 영상에서 공개된 Notion 내부 워크플로우를 한국 팀이 따라 만들 수 있도록 단계별로 정리한 자료입니다.
준비물
Notion Business 또는 Enterprise 플랜 (Custom Agents 사용 가능)
OpenAI Codex 또는 Claude Code 계정
Slack, GitHub 워크스페이스 (연동 대상)
음성 입력용 Whisper 또는 macOS/iOS 받아쓰기
(선택) Honeycomb 등 옵저버빌리티 도구의 MCP 서버
Step 1: 매일 아침 "Standup Pre-read" 에이전트 만들기
가장 먼저 만들 워크플로우는 매일 정해진 시간에 팀의 어제 활동을 한 페이지로 요약해주는 에이전트입니다. Ryan은 이 자동화의 핵심을 "high-frequency, high-quality meetings beat lower-frequency standups"라고 표현했습니다. 회의를 자주 하더라도 사전 자료가 잘 준비되어 있으면 회의 자체는 짧고 밀도 있게 끝낼 수 있다는 의미입니다.
설정 방법은 다음과 같습니다.
Notion에서 Settings → AI → Custom Agents → Create new agent 진입
트리거를 "Schedule"로 설정하고 매일 오전 8시로 지정
데이터 소스로 Slack 채널, GitHub 저장소, 어제 회의록 페이지를 연결
프롬프트에 "어제 활동을 팀별로 묶고, 막힌 이슈는 ⚠️로 표시해" 같은 형식 지시 추가
Notion의 CEO와 CPO도 동일한 방식으로 매일 오전 8시에 각 부서의 주요 프로젝트 진행 상황을 자동 요약 받는 에이전트를 운영하고 있습니다. 회의 준비 시간이 줄어드는 것을 단순한 효율 향상이 아니라 번아웃 보호 메커니즘으로 본다는 점이 인상적인 대목입니다.
Step 2: Whisper로 아이디어 받아쓰기 → 스펙 자동 변환
다음은 머릿속 아이디어를 실행 가능한 스펙(Spec)으로 바꾸는 단계입니다. Ryan이 강조하는 "Spec-First" 개발 방식은 다음 흐름으로 작동합니다.
Whisper(또는 macOS 받아쓰기)로 아이디어를 음성 입력
Codex 또는 Claude Code에게 "다음 음성 메모를 우리 팀 스펙 템플릿 형식으로 정리해" 요청
출력된 스펙을 저장소의
specs/폴더에 커밋에이전트가 해당 스펙을 읽고 자율적으로 구현·검증
Ryan은 이 스펙을 단순한 PRD가 아닌 "기능이 실제로 어떻게 동작하는지에 대한 버전 관리(changelog: version control for how a feature actually works)"로 정의합니다. 즉 코드보다 스펙이 먼저고, 코드는 스펙의 결과물이라는 관점입니다.
이 흐름은 GitHub Spec-Kit(2026년 5월 기준 93,000+ stars)을 비롯해 Kiro, BMAD-METHOD 등 SDD(Spec-Driven Development) 도구 생태계 전체와 맞닿아 있습니다. Notion만의 독특한 워크플로우가 아니라, AI 코딩 시대의 새로운 표준이 자리 잡고 있다는 신호로 볼 수 있습니다.
Step 3: "Boxy" 시스템 — Notion 댓글에서 PR 생성하기
Notion 내부에는 "Boxy"라는 백그라운드 에이전트가 가동되고 있습니다. 동작 방식은 단순합니다.
엔지니어가 Notion 페이지나 코멘트에서
@Codex를 멘션하며 작업 지시Boxy는 내부 VM에서 Codex를 호출해 작업 수행
20분 내에 전체 PR + 스크린샷이 자동으로 생성되어 GitHub에 업로드
따라 만들려면 다음 구성이 필요합니다.
자체 호스팅 가능한 컨테이너(또는 GitHub Actions Self-hosted Runner)에 Codex CLI 설치
Notion 웹훅을 받아 Codex CLI를 트리거하는 중간 서버 작성 (Cloudflare Workers, Vercel Functions 등)
작업 결과를 GitHub PR로 자동 푸시하는 로직 추가
PR 생성 후 Notion 페이지에 결과 링크와 스크린샷을 다시 코멘트로 남기는 콜백
자체 시스템 구축이 부담된다면, 1단계로 Notion Custom Agent에 GitHub MCP를 연결해 "이 페이지의 요구사항을 GitHub Issue로 만들어"부터 시작하는 것을 추천합니다.
Step 4: Project Afterburner — CI 속도 4배 줄이기
AI 에이전트가 코드를 쓰기 시작하면 병목은 더 이상 사람이 아니라 CI 속도가 됩니다. Ryan이 진행 중인 "Project Afterburner"의 목표는 기존 CI 시간을 1/4로 단축하는 것이며, 그는 이를 "fast CI is absolutely critical in the age of AI coding agents"라고 표현했습니다.
이유는 명확합니다. 에이전트가 1분에 1개씩 PR을 만들어내도 CI가 30분이면 피드백 루프가 무너집니다. 즉시 적용할 수 있는 액션은 다음과 같습니다.
테스트 병렬화 (CircleCI Parallelism, GitHub Actions Matrix 등)
변경된 파일만 테스트하는 "affected tests" 도구 도입 (Nx, Turborepo, pytest-testmon)
도커 이미지 캐싱 최적화
E2E 테스트는 PR 머지 후 별도 파이프라인으로 분리
Step 5: 에이전트 코드 리뷰 — "Old World vs New World"
Ryan은 코드 리뷰 패러다임 자체가 바뀌고 있다고 말합니다. 사람이 쓴 코드를 검토하는 방식과 AI 에이전트가 쓴 코드를 검토하는 방식은 다릅니다.
새로운 리뷰 방식의 핵심 기법은 "에이전트에게 푸시백 하에서 자신의 추론을 방어하도록 프롬프트하는 것"입니다. 단순히 코드만 보지 말고, "왜 이 구현을 선택했는가? 다른 대안은 검토했는가? 엣지 케이스는?" 같은 질문을 에이전트에게 다시 던져 답을 얻어내야 합니다.
또한 Ryan은 엔지니어링 매니저와 시니어 임원도 계속 코드를 작성해야 한다고 강조합니다. 현재 그는 6~7명 팀을 매니징하면서도 본인이 직접 코드를 씁니다. AI 도구를 평가하고 적용하려면 직접 써봐야 한다는 일관된 메시지입니다.
결과
Notion 엔지니어링 팀에 이 워크플로우가 자리 잡으면서 다음과 같은 변화가 관찰되었습니다.
매일 아침 회의 준비 시간이 거의 0분으로 단축
모든 엔지니어의 작업이 균등하게 표면화 (특정 인원의 보고력에 의존하지 않음)
댓글 한 줄로 PR이 생성되면서 작은 개선 작업의 진입 장벽이 사라짐
스펙이 코드보다 앞서면서 "왜 이렇게 만들었지?" 류의 사후 논의가 줄어듦
⚠️ 주의할 점
Custom Agents는 Business/Enterprise 전용입니다. Plus 플랜에서는 Notion Agent(요청 기반)만 가능합니다.
MCP 연결 정보는 민감 정보입니다. GitHub Token, Slack Bot Token이 Notion 워크스페이스에 저장되므로 권한 관리가 필수입니다.
에이전트 출력은 검증이 필요합니다. 스탠드업 요약이 잘못된 정보를 사실로 단언할 수 있으므로 초기에는 사람이 검수하는 단계를 두는 것을 권장합니다.
Codex 자율 PR 생성은 비용이 큽니다. 한 PR당 수만 토큰이 소비되므로 사용량 모니터링이 필수입니다.
자주 묻는 질문
노션 AI 에이전트는 무료인가요?
기본 Notion Agent는 모든 Notion 사용자가 사용할 수 있습니다. 하지만 본 가이드의 핵심인 Custom Agents는 Business/Enterprise 플랜 전용이며, Notion 크레딧 시스템에 따라 사용량이 차감됩니다.
Codex 없이 Claude Code로도 같은 워크플로우가 가능한가요?
가능합니다. Notion이 새로 도입한 MCP(Model Context Protocol)를 통해 Claude Code 같은 외부 AI 도구도 워크스페이스에 직접 접근할 수 있습니다. Whisper 입력 → Claude Code 스펙 변환 → Notion MCP 연결 흐름으로 동일하게 구현 가능합니다.
한국 팀에서 가장 먼저 도입할 워크플로우는 무엇인가요?
Step 1의 "Standup Pre-read" 에이전트입니다. 가장 적은 리스크로 가장 큰 효과를 볼 수 있고, 팀이 AI 에이전트의 출력 품질을 검증하는 학습 단계 역할도 겸할 수 있습니다.
Spec-Driven Development가 기존 Waterfall과 다른 점은 무엇인가요?
핵심 차이는 스펙이 "실행 가능한 산출물"이라는 점입니다. Waterfall의 명세서는 사람이 읽고 사람이 구현하지만, SDD의 스펙은 AI 에이전트가 직접 읽고 구현·검증합니다. 또한 스펙은 코드와 함께 버전 관리되어 끊임없이 갱신됩니다.