노션 워커스를 만들고 바로 웹훅으로 전환한 이유 (실전 경험기)

생기부 자동화 워커를 직접 만들어봤습니다. 크레딧 소모, CLI 제약 등 한계를 느끼고 Vercel 서버리스로 전환한 과정과 이유를 공유합니다.

1000쌤

Mar 29, 2026

📌

노션 워커스를 직접 만들어봤는데, 바로 다른 방법으로 갈아탔습니다.

학생 생활기록부 초안을 자동 생성하는 워커를 구축한 실전 경험기입니다. 워커스의 구조적 한계를 체감하고, Vercel 서버리스 함수로 전환한 과정과 이유를 공유합니다.

이 글에서 배울 내용 ⏳ 읽기 7분

생기부 자동화 워커를 만든 과정과 만난 문제들

노션 워커스의 실질적인 장단점

웹훅(서버리스) 방식으로 전환한 이유

두 방식의 구체적인 비교

만들려고 했던 것

현직 교사로서 가장 반복적이고 시간이 많이 드는 업무가 교과세특(과목별 세부능력 및 특기사항) 작성입니다. 학생 30~120명의 활동 기록을 바탕으로 생활기록부 문장을 하나하나 써야 합니다.

자동화 아이디어는 간단했습니다.

노션 폼으로 학생 활동 내용을 수집 (누가기록 DB)

에이전트에게 "생기부 작성해줘"라고 말하면

워커가 DB를 읽고 → Claude API로 초안 생성 → 결과를 DB에 기록

에이전트는 트리거 역할만 하고, 실제 작업은 워커 스크립트가 전부 처리하는 구조입니다.

워커스로 만들면서 겪은 문제들

결론부터 말하면, 코드 작성보다 환경 설정에서 삽질을 훨씬 많이 했습니다.

ntn CLI가 Windows를 지원하지 않는다

코드를 전부 작성하고 타입 체크까지 통과한 뒤에야 npm i -g ntn에서 플랫폼 에러를 만났습니다. macOS와 Linux만 지원합니다.

WSL(Windows Subsystem for Linux)을 설치하고, Ubuntu를 세팅하고, Node.js를 깔고, 프로젝트를 복사하고... 환경 구성에만 1시간 이상 소요됐습니다.

워커 삭제 시 환경변수가 함께 사라진다

워커 이름을 바꾸려면 삭제 후 재생성해야 합니다. 그런데 워커를 삭제하면 ntn workers env set으로 등록한 환경변수(API 키 등)가 모두 삭제됩니다. 재등록하지 않으면 인증 에러가 발생합니다.

크레딧 소모가 예상보다 크다

에이전트가 사고(thinking)를 한 턴 수행할 때마다 1크레딧이 소진됩니다. 워커 호출 시 에이전트가 요청 해석 → 파라미터 추출 → 도구 호출 등 여러 턴에 걸쳐 사고하기 때문에, 실제로는 1회 작업에 5~6크레딧이 소모되는 경우가 많습니다. 워커가 30명을 처리하든 120명을 처리하든 에이전트 크레딧은 동일하지만, "가볍게 트리거만 하면 1~2크레딧 아닐까"라고 예상했던 것과는 큰 차이였습니다.

크레딧을 아끼려면 에이전트 지침을 최대한 심플하게 구성해 사고 턴 수를 줄이는 것이 핵심입니다. 지침을 극도로 단순화하면 2크레딧/회까지 낮출 수 있으며, 이것이 현재 확인된 최저 비용입니다. 1,000크레딧에 10달러이며, 2크레딧/회 기준 500회 호출이 가능합니다.

워커스의 장단점 정리

장점	단점
자연어로 트리거 가능	에이전트 크레딧 소모 (회당 최소 2크레딧)
파라미터를 AI가 자동 매핑	ntn CLI Windows 미지원
노션 SDK가 인증을 자동 처리	알파 상태, breaking change 가능
배포가 단순 (`ntn workers deploy`)	환경변수 관리가 취약

서버리스로 전환한 이유

워커스의 구조를 이해하고 나니, 한 가지 의문이 들었습니다.

스크립트를 직접 만들 줄 아는데, 왜 에이전트를 거쳐야 하지?

커스텀 에이전트로 워커를 호출하는 방식의 핵심 장점은 유연한 트리거와 자연어 기반 파라미터 매핑입니다. "30반 학생들 생기부 써줘", "이번엔 2반으로 해줘"처럼 매번 다른 조건을 자연어로 전달할 수 있다는 거죠.

그런데 실제 자동화 운영 방식을 생각해보면, 파라미터를 그때그때 바꾸는 게 아니라 발동 조건을 엄격하게 고정하는 경우가 많습니다. 생기부 워커도 마찬가지였습니다. "생기부 초안이 비어있는 모든 학생 대상”으로 고정해두면 파라미터 매핑이 필요 없습니다. 이 경우 에이전트의 자연어 해석 기능은 사실상 필요가 없습니다.

그렇다면 굳이 돈 내고 커스텀 에이전트+워커를 쓸 필요가 없다는 생각이 들었습니다. 노션 AI 크레딧은 월 최소 1,000크레딧 단위로 충전되며, 이는 약 15,000원의 고정 지출을 의미합니다. 지침을 극도로 단순화해 호출당 2크레딧까지 낮춰도, 단순 트리거 목적으로 매달 15,000원을 내는 구조는 비효율적입니다. 같은 로직을 Vercel 서버리스 함수로 배포하면 크레딧 비용은 0입니다.

📝

참고 (2026년 3월 기준): 노션 공식 헬프센터에 따르면 커스텀 에이전트는 2026년 5월 4일까지 무료 베타 기간입니다. 크레딧 과금은 5월 4일부터 시작되며, 이 글의 비용 계산은 과금 시작 이후를 기준으로 합니다.

전환 과정

놀라울 정도로 간단했습니다. 변경한 건 딱 두 가지입니다.

1. 워커 SDK 의존성 제거


// Before (워커)
execute: async (input, { notion }) => { ... }

// After (서버리스)
import { Client } from "@notionhq/client";
const notion = new Client({ auth: process.env.NOTION_TOKEN });

2. HTTP 엔드포인트 추가

Vercel의 api/ 폴더에 함수를 배치하면 자동으로 URL이 생성됩니다. 인증은 Bearer 토큰으로 처리합니다.

비즈니스 로직(DB 쿼리, Claude API 호출, 결과 기록)은 한 줄도 바꾸지 않았습니다.

서버리스 방식의 장단점

장점	단점
노션 AI 크레딧 0	자연어 트리거 불가 (URL 직접 호출)
Windows에서 바로 배포	Notion Integration 토큰 직접 관리
Vercel/Cloudflare 등 안정적 인프라	파라미터를 직접 지정해야 함
트리거 자유도 (Slack, 브라우저, 단축어 등)	초기 설정이 약간 더 복잡

두 방식 비교

항목	노션 워커스	Vercel 서버리스
트리거	"생기부 작성해줘" (자연어)	URL 호출 (POST/GET)
크레딧	~6/회	0
배포 도구	ntn CLI (Linux only)	Vercel CLI (전 플랫폼)
인프라 안정성	알파	프로덕션
Notion API 인증	자동	직접 관리
코드 차이	1줄 (notion client 생성)	동일

그래서 워커스는 쓸모없나?

아닙니다. 쓸모가 다릅니다.

워커스가 유리한 경우:

자연어 파라미터가 필요한 경우: 실행 조건이 매번 달라져서 유저 프롬프트로 파라미터를 그때그때 전달해야 하는 경우. "30반 학생들로 해줘", "이번엔 2반"처럼 입력값을 자연어로 유연하게 바꿔야 할 때.

에이전트 지침을 유연하게 관리해야 하는 경우: 스크립트 실행 전 에이전트가 수행하는 전처리 동작 자체를 자주 조정해야 하는 경우. 코드 배포 없이 에이전트 지침만 수정해서 동작을 바꿀 수 있다는 점이 장점.

이미 크레딧을 충전 중인 경우: 조직 내에서 커스텀 에이전트를 적극 도입 중이라 어차피 크레딧을 충전하고 있다면, 워커스를 추가로 얹는 비용은 사실상 0.

서버리스가 유리한 경우: 실행 조건이 비교적 고정되어 있고, 크레딧 비용을 따로 내고 싶지 않은 경우. 코드를 직접 작성할 수 있고 트리거 방식도 직접 설계할 수 있다면 서버리스가 훨씬 경제적입니다.

그런데 여기서 한 가지 의문이 생깁니다.

"코드를 직접 짜야 한다면, 그냥 Make나 n8n 같은 노코드 자동화 쓰는 게 더 편하지 않나?"

블록 연결 몇 번으로 노션 DB를 읽고, API를 호출하고, 결과를 기록할 수 있습니다. 심지어 코드 한 줄 없이도요. 서버리스 함수를 직접 작성하는 것과 어떤 차이가 있을까요? 다음 편에서 이 질문에 답합니다.

💡

다음 편에서는 Make, n8n 같은 노코드 자동화 도구와 바이브코딩(Claude Code 등)을 이용한 자동화를 비교합니다. 코딩 없이 자동화하는 것과, AI에게 코딩을 시켜서 자동화하는 것의 차이를 다룹니다.

노션 워커스(Notion Workers) — 커스텀 에이전트에 코드를 심는 방법