[중급] Notion을 데이터베이스로 착각하면 당신의 자동화 시스템이 멈춘다

결론부터 말한다. Notion은 데이터베이스가 아니다.

이 사실을 인정하지 않고 Make(구 Integromat) 시나리오를 짜면, 반드시 시스템이 터진다. 지난주에 새로 맡은 클라이언트 파이프라인이 딱 이 꼴이었다. 겉은 멀쩡한데 속은 썩어 문드러진 구조. 원인을 파악하는 데만 꼬박 반나절이 걸렸다.

Notion은 자유도가 높은 ‘블록 에디터’에 데이터베이스 ‘기능’을 얹은 서비스다. 이걸 MySQL 같은 정통 데이터베이스처럼 다루는 건, 예쁘게 디자인된 캠핑카로 F1 레이싱에 출전하는 것과 같다. 겉모습은 그럴싸하지만, 코너링 한 번에 전복된다는 말이다.

엔지니어링 관점에서, Notion과 Make를 연동할 때 직장인 열에 아홉은 똑같은 실수를 반복한다. 시간과 비용을 태우기 전에 반드시 짚고 넘어가야 할 5가지 치명적인 오류를 기록해 둔다.

실무에서 가장 많이 터지는 5가지 삽질 유형

1. ‘데이터베이스’와 ‘페이지’의 개념 혼동

“아니, 데이터베이스 ID를 넣었는데 왜 페이지를 못 찾죠?”

이 질문, 정말 지겹게 받는다. Notion의 모든 구성 요소는 ‘블록’이다. 데이터베이스도 블록이고, 그 안의 각 행(Row)인 페이지도 블록이다. 둘은 주소 체계가 완전히 다르다.

• 데이터베이스 ID: 데이터를 담는 ‘건물’의 주소.
• 페이지 ID: 건물 안의 특정 ‘호수’ 주소.

Make에서 ‘Create a Database Page’ 모듈을 쓰려면 ‘데이터베이스 ID’를 넣어야 하고, ‘Update a Page’ 모듈을 쓰려면 당연히 ‘페이지 ID’를 넣어야 한다. 이걸 헷갈려서 데이터베이스 ID 칸에 페이지 ID를 넣고 시나리오가 왜 안 도냐고 묻는 경우가 태반이다. 기본 중의 기본인데, 여기서 막히면 다음 단계는 없다.

2. API ‘호출 제한(Rate Limit)’ 무시

Notion API는 공짜 무제한 뷔페가 아니다. 1초에 평균 3번의 요청만 처리하도록 설계되어 있다. 이걸 ‘Rate Limit’이라 부른다.

이걸 무시하고 Make에서 수백 개의 Notion 페이지를 한 번에 업데이트하는 시나리오를 돌리면 어떻게 될까? Notion 서버는 “이놈 봐라?” 하면서 연결을 일시적으로 끊어버린다. 그럼 Make 시나리오는 빨간불을 띄우며 멈춘다. 이건 마치 ATM에서 1초에 10번씩 카드를 넣었다 뺐다 하면서 돈을 인출하려는 행위와 같다. 당연히 기계는 카드를 먹어버리고 경고를 띄운다.

해결책: Make 시나리오 중간에 ‘Sleep’ 모듈을 넣어라. 루프(Loop)를 돌릴 때마다 1~2초씩 의도적으로 쉬어가는 시간을 주는 거다. 시스템에 과부하를 주지 않는 기본 매너이자, 내 시나리오를 안정적으로 지키는 핵심 테크닉이다.

3. 비효율의 극치, ‘Search Objects’ 모듈 남발

Make에서 Notion의 특정 데이터를 찾을 때 ‘Search Objects’ 모듈을 가장 먼저 떠올린다. 이게 가장 직관적이니까. 하지만 이건 최악의 선택이다. 이 모듈은 당신의 Make 크레딧을 가장 빠르게 소진시키는 주범이다.

상황: ‘처리중’ 상태인 모든 페이지를 찾아서 ‘완료’로 바꾸고 싶다.

초보자: ‘Search Objects’ 모듈로 ‘상태’가 ‘처리중’인 것을 검색 → 찾은 모든 페이지를 대상으로 Loop → ‘Update a Page’ 모듈로 상태 변경

파이프마스터: ‘Watch Database Items’ 트리거를 사용한다. 이 트리거는 ‘새로 생성’되거나 ‘업데이트’된 항목만 감지한다. 처음 한 번만 전체를 읽고, 그 후로는 변경분만 체크하니 불필요한 API 호출과 크레딧 낭비가 없다. 필터링은 Make 내부의 ‘Filter’ 기능으로 처리하는 게 100배는 효율적이다.

4. 지저분한 데이터베이스 속성(Properties) 설계

Garbage in, garbage out. 쓰레기를 넣으면 쓰레기가 나온다. 자동화의 기본 원칙이다.

Notion 데이터베이스 속성을 아무 생각 없이 ‘Text’ 타입으로만 덕지덕지 채워놓는 경우가 많다. 자동화 관점에서 이건 재앙이다. 예를 들어, 진행 상태를 ‘Text’ 속성에 ‘처리중’, ‘처리 중’, ‘진행중’ 이런 식으로 제멋대로 입력하면 Make에서 어떤 기준으로 필터링할 건가?

상태는 ‘Status’나 ‘Select’ 속성을, 담당자는 ‘Person’ 속성을, 카테고리는 ‘Multi-select’ 속성을 쓰는 식으로 처음부터 구조를 명확하게 짜야 한다. 이건 요리하기 전에 재료부터 깔끔하게 다듬어 놓는 것과 같다. 재료 손질이 엉망이면, 백종원이 와도 맛있는 요리를 만들 수 없다.

5. 업데이트 트리거의 함정

Make의 ‘Watch Database Items’ 트리거는 ‘업데이트’를 감지할 수 있어 매우 유용하다. 하지만 이걸 잘못 쓰면 무한 루프의 늪에 빠진다.

상황: Notion 페이지에 ‘수정일시’ 속성을 만들고, 페이지가 수정될 때마다 Make가 현재 시간을 자동으로 기록하게 만들고 싶다.

함정: 시나리오가 실행되어 ‘수정일시’를 업데이트하는 행위 자체가 또 다른 ‘업데이트’를 유발한다. 그럼 시나리오는 자기가 만든 업데이트를 감지해서 또 실행되고, 또 업데이트하고… 무한 반복에 빠지면서 당신의 크레딧은 순식간에 0이 된다.

해결책: 트리거 설정에서 ‘Watch for’ 옵션을 특정 속성(Property)에만 한정하거나, 시나리오 초입에 필터를 걸어 특정 조건(예: ‘자동화 완료’ 체크박스가 비어있을 때만 실행)을 만족할 때만 뒤 단계가 진행되도록 파이프를 제어해야 한다. 자동화 시스템에 ‘브레이크’를 다는 작업이다.

결론: 도구를 이해하고 시스템을 설계하라

Notion과 Make는 분명 강력한 조합이다. 하지만 각 도구의 본질과 한계를 명확히 이해하지 못하면, 모래 위에 성을 쌓는 격이다. 보여주기식 자동화가 아니라 진짜 내 일을 대신해 줄 시스템을 원한다면, 겉핥기식 기능 공부는 당장 멈춰야 한다.

이런 복잡한 파이프라인 설계도를 초등학생 버전으로 쉽게 풀어낸 실전 세팅 가이드와 템플릿은, 현재 비공개로 빌드업 중인 [파이프마스터 클럽] 네이버 카페에만 독점 공개할 예정이다. 조만간 초기 멤버 100명을 모집할 계획이니, 내 블로그(pipemaster-lab.com)를 주시하길 바란다. 혼자서 헤매는 시간, 거기서 끝내주겠다.

PipeMaster-Lab 운영정책 및 제보 안내