Notion Workers 동기화: 되는 것과 안 되는 것

Notion Workers는 Notion이 직접 호스팅하고 실행해 주는 작은 TypeScript 프로그램이에요. 그중 동기화 기능은 외부 서비스의 데이터를 정해진 주기로 Notion 데이터베이스에 가져와요.

이 동기화는 Notion 쪽으로 들어오는 단방향이에요. 동기화가 소유한 열은 전부 읽기 전용이 되기 때문에 할 일의 제목이나 마감일을 Notion에서 바꿀 수 없어요.

Workers는 Business 또는 Enterprise 플랜이 있어야 하고, 2026년 10월 15일부터는 실행 단위로 Notion 크레딧을 써요.

Notion Workers란 무엇인가요?

Worker는 직접 작성하는 TypeScript 파일 하나예요. Notion의 ntn 명령줄 도구로 배포하면 Notion 인프라 위에서 실행돼요. 서버를 준비할 일은 없어요.

Worker마다 기능을 등록해요. 종류는 세 가지예요. 외부 레코드를 Notion 데이터베이스로 주기적으로 가져오는 syncs, Notion의 Custom Agents가 호출하는 tools, 다른 서비스의 이벤트를 받는 webhooks예요.

흔히 말하는 "동기화"에 해당하는 건 이 중 첫 번째뿐이에요.

Notion은 도움말 센터에서 선을 직접 긋고 있어요. 자동화는 Notion에 내장돼 있고 누구나 설정하도록 만들어진 기능이고, Workers는 커스텀 코드를 실행하려는 개발자를 위한 기능이라고 적어 뒀어요.

Workers는 베타이고, 그 안의 webhooks는 한 단계 더 앞인 알파예요.

노션 API로 직접 만드는 것과 무엇이 다른가요?

Workers는 Notion 개발자 플랫폼의 한 조각이에요. 같은 플랫폼 안에 CLI, MCP, API, SDK가 함께 있어요.

공개 API로 같은 일을 하려면 코드를 돌릴 실행 환경과 스케줄러를 직접 마련해야 하지만, Workers는 그 두 가지를 Notion이 맡아요.

대신 조건이 하나 붙어요. 동기화 기능으로 가져온 속성은 Notion에서 손댈 수 없어요. API로 직접 쓴 스크립트에는 이런 잠금이 없어요. 데이터베이스는 평범한 데이터베이스로 남고, 원하는 시점에 쓰기만 하면 되니까요.

그래서 선택은 맞바꿈이에요. 호스팅과 스케줄을 넘기는 대가로 편집 권한을 내주거나, 편집 권한을 지키는 대신 호스팅, 스케줄, 재시도, 속도 제한을 전부 직접 떠안거나예요.

Notion Workers와 2sync 한눈에 비교

Worker가 동기화한 열은 Notion에서 읽기 전용이에요

대부분의 작업 흐름은 이 제약 하나에서 갈려요. Notion 동기화 문서는 Worker 동기화에 대해 분명하게 적어 뒀어요. 동기화된 열은 읽기 전용이고, 동기화 스키마에 선언된 속성은 수동으로 편집할 수 없어요.

행 제목과 아이콘도 같은 방식으로 잠기고, 행을 직접 추가하거나 삭제하는 것도 안 돼요. 쓰기는 동기화만 해요.

스키마 밖에 따로 만든 열은 계속 편집할 수 있어요. 동기화된 데이터 옆에 나만의 상태 속성을 두는 건 가능해요. 동기화된 필드 자체가 내 것이 아닐 뿐이에요.

Todoist Worker를 떠올려 보면 쉬워요. 할 일이 Notion으로 깔끔하게 들어와요. 그런데 Notion에서 마감일을 하루 미루려고 하면 Notion이 막아요. 바꾸려면 Todoist로 가서 바꾸고 다음 실행을 기다려야 해요.

아무도 편집하지 않는 대시보드라면 이건 올바른 동작이고 오히려 기능이에요. Notion이 원본과 어긋날 수 없다는 보장이니까요. 하지만 Notion이 실제로 일하는 자리라면, 두 앱을 연결한 이유 자체가 사라져요.

동기화 API에는 양방향 옵션이 아예 없어요. 변경 사항을 바깥으로 내보내는 Notion의 답은 webhook 기능으로 만든 두 번째 Worker를 Notion 자동화로 트리거하는 방식이에요.

그 역방향 경로는 직접 짜야 하고, 루프 방지와 충돌 규칙, 삭제 감지도 함께 따라와요.

쓸 수 있는 조건과 실제로 드는 비용

Workers는 Business와 Enterprise 플랜에서만 쓸 수 있어요. Notion Business는 멤버당 월 $20이에요. 무료 플랜이나 Plus 플랜 워크스페이스는 구성원이 아무리 코드를 잘 써도 Workers를 쓸 수 없어요.

기본값은 워크스페이스 소유자만 쓸 수 있게 돼 있어요. 팀 워크스페이스라면 누가 배포하기 전에 관리자가 먼저 권한을 열어 줘야 해요.

계산해 볼 만한 쪽은 과금이에요. Notion의 무료 베타는 2026년 10월 14일까지의 Worker 실행을 덮어요.

2026년 10월 15일부터는 Notion 크레딧이 빠져나가요. 크레딧은 개당 $0.01이고, Notion은 Worker 실행 한 번을 약 $0.0023으로 잡고 있어요. 예약된 동기화가 한 번 돌 때마다 실행 1회예요.

동기화가 가질 수 있는 가장 짧은 주기는 5분이에요. 이 주기면 동기화 하나가 30일 기준 한 달에 8,640번 실행돼요.

출처: Notion Workers 요금 안내, Notion 요금제, 둘 다 2026년 9월 15일 확인. 2sync 수치는 요금제 문서 기준이에요.

계산 방식은 Notion이 공개한 그대로예요. Notion은 15분 주기 Salesforce 동기화를 월 2,880회 실행에 $6.62로 예시를 들어 뒀고, 위 표는 같은 산식이에요.

주의할 점이 두 가지 있고 둘 다 같은 방향을 가리켜요. Notion은 Worker가 하는 일의 양에 따라 실행당 크레딧이 달라진다고 밝혔어요. $0.0023은 하한이지 상한이 아니에요.

그리고 비용이 예상보다 크게 나올 때 Notion이 내놓는 해결책은 실행 주기를 늘리라는 거예요. 비용과 신선도는 설계상 서로를 깎아요.

실행당 단가는 실제로 무엇에 돈을 내고 있는지도 가려요. 상류에서 아무것도 바뀌지 않아도 실행은 과금돼요.

일주일에 새 일정이 세 개 생기는 캘린더도 5분 주기에서는 한 달에 8,640번 동기화하고, 그 전부가 과금 대상이에요.

계량기는 일이 아니라 폴링을 따라가요. 한산한 데이터베이스와 바쁜 데이터베이스의 비용이 똑같은 이유예요.

표가 보여 주지 못하는 게 하나 더 있어요. Workers는 5분보다 빠르게 돌 수 없어요.

2sync Premium과 Pro의 3분, 2분 주기는 어떤 금액을 내도 Workers에서는 선택지가 아니에요. 새 동기화의 기본 주기는 30분이에요.

Google과 Microsoft 앱은 직접 등록해야 해요

Workers는 제공자 로그인을 대신 처리해 주지 않아요. 사용자 인증이 필요한 API라면 Notion 문서는 OAuth 기능을 등록하고 자격 증명을 직접 넣으라고 안내해요.

Google 캘린더, Gmail, Google Tasks라면 자기 Google Cloud 프로젝트와 자기 OAuth 앱이 필요하다는 뜻이에요.

그러면 Google의 규칙이 Notion이 아니라 그 앱을 만든 사람에게 적용돼요. 규칙은 빡빡해요.

• 인증받지 않은 앱은 평생 100명이 상한이에요. Google의 상한은 프로젝트의 전체 수명에 적용되고 초기화하거나 바꿀 수 없어요. 사용자는 들어오는 길에 미인증 앱 경고를 봐요.
• 테스트 모드는 7일마다 토큰이 만료돼요. Testing 상태로 둔 프로젝트는 테스트 사용자 100명까지고, 동의한 지 7일이 지나면 새로 고침 토큰까지 만료돼요. 이렇게 만든 동기화는 매주 한 번씩 멈춰요.
• Gmail은 해마다 보안 평가를 받아야 해요. gmail.readonly를 포함한 모든 Gmail 스코프는 제한 스코프로 분류돼요. 서버를 통해 제한 데이터를 읽는 앱은 CASA 프레임워크에 따라 보안 평가를 통과하고 최소 12개월마다 다시 받아야 해요. 심사만으로도 몇 주가 걸릴 수 있어요.

2sync는 이 앱들을 직접 운영해요. 인증을 마친 Google과 Microsoft 애플리케이션을 저희 이름으로 굴리고, 보안 문서에 적힌 좁은 범위의 스코프만 요청해요.

Gmail이나 Google 캘린더를 연결하는 일이 프로젝트가 아니라 로그인 한 번으로 끝나는 이유예요.

클라이언트마다 설정해 주는 컨설턴트라면 차이가 특히 커요. 한쪽은 클라이언트 계정 100개에서 끝나고 해마다 감사를 받아야 해요. 다른 쪽은 버튼이에요.

이미 쓰고 있는 데이터베이스에 Worker를 붙일 때

동기화는 attached 선언과 명령줄 바인딩으로 기존 데이터베이스에 붙일 수 있어요. 같은 문서에 있는 Notion의 경고는 그대로 옮길 만해요.

데이터베이스를 붙이면 행을 포함한 실제 데이터베이스의 통제권이 Worker에게 넘어가고, 동기화가 기존 행을 덮어쓰거나 삭제해 데이터 손실이 생길 수 있어요.

조금 아래에 함정이 하나 더 있어요. Worker를 삭제하거나 코드에서 데이터베이스 선언을 지우고 다시 배포해도 데이터베이스는 풀려나지 않아요. 잠긴 채 고아 상태로 남고, 해결책은 먼저 실행할 줄 알아야 하는 detach 명령이에요.

replace 모드에는 또 다른 특성이 있어요. 한 주기 동안 보지 못한 행을 지우기 때문에, 중간에 오류가 난 동기화는 설계상 아무것도 지우지 않아요. 다음 정상 실행 전까지 데이터베이스에는 오래된 행이 남아요.

숨겨 둔 내용은 하나도 없어요. 문서에 분명히 적혀 있고, 그건 Notion이 잘한 부분이에요. 동시에 Worker를 배포한 사람이 그대로 떠안게 되는 장애 시나리오 목록이기도 해요.

2sync는 데이터베이스를 넘겨받지 않아요. 매핑한 속성만 쓰고 나머지 열은 그대로 두며, Notion에서 행을 직접 추가하고 수정하고 삭제할 수 있어요.

직접 만들고 계속 돌봐야 하는 것들

Worker가 주는 건 실행 환경과 스케줄이에요. 동기화 도구가 하는 나머지 일은 직접 써야 해요.

• 속도 제한. Notion은 값을 직접 정하는 pacer를 제공해요. 예를 들어 초당 요청 10회처럼요. 손대는 API마다 숫자를 스스로 정해야 하고, 잘못 잡으면 제공자가 요청을 막아요. 2sync의 재시도 처리는 Notion, Google, Microsoft, Todoist 전반에서 지수 백오프와 가변 배치 크기를 쓰고, 이걸 설정하는 사람은 아무도 없어요.
• 충돌 규칙. 실행 사이에 같은 레코드가 양쪽에서 바뀌면 무엇이 이길지 정해야 해요. 2sync는 충돌을 항목이 아니라 필드 단위로 해결해요. Notion에서 바꾼 제목과 Google 캘린더에서 바꾼 날짜가 둘 다 살아남아요.
• 삭제 감지. 레코드가 안 보이는 게 삭제인지 실패한 요청인지 판단하는 일이 깔끔한 데이터베이스와 텅 빈 데이터베이스를 갈라요. 2sync의 안전 한도는 동기화 항목의 절반 이상이 지워지기 전에, 그리고 중복이 생기기 전에 동기화를 멈춰요.
• 워크스페이스 실행 한도. Notion은 동기화 실행을 워크스페이스 전체 기준 시간당 600회로 제한하고, 그 안의 모든 Worker가 이 한도를 나눠 써요. 5분 주기 동기화 10개면 시간당 120회를 쓰니까, 바쁜 워크스페이스는 천장을 염두에 두고 설계해야 해요.

특별한 일은 하나도 없어요. 누군가 이미 만들어 둔 뒤에 보면 동기화 엔진이 하는 일 그 자체예요.

그다음에는 어떤 연동에나 따라붙는 평범한 유지보수가 남아요. 제공자 API가 바뀌고 스키마가 흔들려요.

동기화 데이터베이스에 필드 하나를 더하려면 스키마 블록을 고치고, 매핑을 고치고, 다시 배포하고, 동기화 상태를 초기화하고, 재실행을 걸어야 해요.

Worker가 정답인 경우

Workers는 어떤 동기화 서비스도 다루지 않는 일을 정말 잘해요. 그 일이 무엇인지 정확히 말해 둘 필요가 있어요.

Business 플랜을 쓰고, TypeScript를 쓰고, Salesforce나 Zendesk, Stripe, Jira 또는 사내 데이터베이스를 Notion 안에 읽기 전용으로 미러링하고 싶다면 Worker는 바로 그 목적으로 만들어졌어요.

데이터가 Notion 인프라 밖으로 나갈 일이 없고, 읽기 전용 잠금이 미러와 원본의 일치를 보장하고, 그 결과를 에이전트가 읽을 수 있어요.

JSON API는 있는데 아무 벤더도 커넥터를 만들지 않은 시스템도 마찬가지예요.

Worker로 얻는 건 도달 범위예요. Worker는 코드로 접근할 수 있는 것이면 무엇이든 동기화하고, 이건 어떤 동기화 제품이 지원하는 범위보다 훨씬 넓어요.

염두에 둔 시스템이 캘린더와 할 일이 아니라 데이터베이스 쪽이라면 저희와는 다른 카테고리이고, 2sync와 Whalesync 비교에 각자의 자리를 정리해 뒀어요.

여기서 빠지는 건 사람이 같은 레코드를 양쪽에서 편집하는 경우예요. 그건 다른 문제이고 읽기 전용 열로는 풀 수 없어요. Notion에서 할 일에 체크하고 Google Tasks도 같이 완료되기를 기대하는 게 그 일상적인 버전이에요.

2sync는 같은 문제를 어떻게 푸나요

2sync는 Notion을 Google 캘린더, Todoist, Google Tasks, Outlook 캘린더, Gmail, Outlook 메일, Google 연락처, Outlook 연락처와 양방향으로 연결해요.

변경 사항은 양쪽 방향으로 알아서 흐르고, Notion 속성은 그 과정에서 계속 편집할 수 있어요.

방향은 자동화 단위가 아니라 필드 단위로 정해요. 한 레코드 안에 양방향 필드와 한쪽으로만 흐르는 필드를 나란히 둘 수 있어요. 주최자나 생성 일시는 제공자 쪽에 고정해 두고, 제목과 날짜는 Notion에서 편집 가능하게 열어 두는 식이에요.

이 선택은 생각보다 중요해요. 활성 사용자의 79% 가까이가 양방향만 쓰고 있어요. 그때그때 열려 있는 앱에서 일하기 때문이에요. 읽기 전용 미러는 이 사람들 중 누구에게도 맞지 않아요.

Notion 데이터베이스를 만들 줄 아는 사람이면 누구나 설정할 수 있어요. 설정은 브라우저에서 하고 5분쯤 걸려요. 제공자를 연결하고, Notion 데이터베이스를 고르고, 속성을 매핑하고, 필요하면 필터를 걸어요.

설치할 것도 배포할 것도 없어서 API가 바뀔 때 손봐야 할 코드도 없어요.

202개국 127,000개 계정에서 250만 건이 넘는 항목을 동기화했어요.

요금은 멤버당이 아니라 계정당이고, 모든 플랜에 모든 연동이 들어 있어요. 설정하기 전에 방향이 어떻게 동작하는지 먼저 보고 싶다면 양방향과 단방향 동기화 문서에 정리돼 있어요.

어느 쪽이 내 작업 흐름에 맞을까요

편집이 어디서 일어나는지부터 거꾸로 따라가면 돼요.

• Notion에서는 읽기만 해요. 데이터가 아무도 커넥터를 만들지 않은 시스템에서 온다면, Business 플랜이고 TypeScript를 쓸 사람이 있을 때 Worker를 만드세요.
• 양쪽 앱에서 편집해요. 그럼 양방향 동기화 도구가 필요해요. 주변에 무엇을 덧붙이든 Worker는 Notion에서 한 편집을 되돌려 보내지 못해요. 2sync는 변경 사항을 필드 단위로 양쪽 방향에 써요.
• 무료 플랜이나 Plus 플랜을 쓰고 있어요. Workers는 아예 선택지가 아니에요. 2sync는 모든 Notion 플랜에서 작동해요. 무료 플랜도 포함이에요.
• 연속적인 일치가 아니라 한 번의 동작이 필요해요. 행이 바뀔 때 Slack에 알리는 식이라면 자동화 플랫폼의 일이에요. Notion용 Zapier 대안에서 현실적인 선택지를 비교했고, 2sync와 Zapier 비교도 나란히 볼 수 있어요.
• 코드를 쓰지 않고 캘린더, 할 일, 메일을 Notion에 두고 싶어요. Google 캘린더, Outlook 캘린더, Todoist, Gmail부터 시작하세요.

두 방식이 한 워크스페이스에 같이 있어도 문제없어요. CRM을 미러링하는 Worker와 캘린더를 동기화하는 2sync는 서로 다른 문제를 풀어요.

결론

Notion Workers는 개발자용 기능이고, Notion도 그렇게 말해요. 코드로 접근할 수 있는 모든 API까지 Notion의 범위를 넓혀 주고, 서버 없이 그렇게 해요.

하지 않는 일은 양방향 동기화예요. Worker가 동기화한 열은 읽기 전용이고, 동기화는 Notion 안쪽으로만 쓰지 바깥으로는 쓰지 않아요.

우회로는 직접 만들고 관리하는 두 번째 Worker예요.

여기에 Business 플랜 요건과 2026년 10월 15일부터 적용되는 크레딧, Google의 상한이 따라붙는 자체 OAuth 앱까지 더하면, 좁은 목적에 맞춰진 강력한 도구라는 그림이 나와요.

데이터를 Notion에서 읽기만 하면 된다면 그 목적이 내 것일 수 있어요. 두 앱에서 모두 일한다면 수정이 양쪽으로 오가야 해요.

FAQ