저는 한동안 Notion을 그냥 ‘예쁜 메모장’으로만 썼습니다. 트레이딩 일지 적고, 아이디어 모아두고, 체크리스트 만들고. 그런데 어느 시점부터 이 Notion DB가 제 자동화 파이프라인의 중심축이 됐습니다. Make.com이 신호를 받아 Notion에 데이터를 쌓고, Claude API가 그 데이터를 읽어 글을 쓰고, WordPress로 자동 발행되는 구조가 지금 이 글도 만들어내고 있습니다. 처음엔 그냥 편리함 때문에 시작했는데, 실제로 구축하다 보니 Notion DB의 필드 구조 설계가 전체 자동화의 품질을 결정한다는 걸 몸으로 배웠습니다.
Notion DB를 자동화에 연결하기 전에 반드시 설계해야 할 것
처음 Make.com과 Notion을 연동했을 때 저는 가장 흔한 실수를 했습니다. 일단 DB를 만들고, 나중에 필드를 추가하면 되겠지 싶었던 거죠. 결과는 엉망이었습니다. 텍스트 필드에 날짜가 들어가고, Select 필드가 중간에 Multi-select로 바뀌면서 Make.com 시나리오가 두 번 깨졌습니다. Notion DB 자동화에서 필드 타입은 한 번 정하면 바꾸기 어렵습니다. 정확히는 바꿀 수는 있지만, 연동된 API 시나리오가 즉시 오류를 냅니다. 제가 지금 쓰는 기준은 이렇습니다. 자동으로 입력될 필드는 반드시 Title, Rich Text, Select, Date, Number, URL 중 하나로만 설계합니다. Formula나 Rollup은 읽기 전용으로만 쓰고, Make.com이 쓰는 필드에는 절대 넣지 않습니다. 특히 Select 필드의 옵션값은 Make.com 시나리오에서 하드코딩되는 경우가 많아서, 옵션을 나중에 추가하면 기존 시나리오가 매핑을 못 찾아 silent fail이 납니다. 알림도 없이 그냥 빈 값으로 저장됩니다. 이걸 모르면 며칠치 데이터가 조용히 증발합니다. 제 해결책은 설계 단계에서 Make.com에서 보낼 모든 값의 후보를 미리 Notion Select 옵션에 등록해두는 겁니다. 나중에 추가할 것 같으면 처음부터 Multi-select로 설계하거나, Text 필드로 두고 시나리오에서 제어합니다.
Make.com 웹훅 + Notion API 연동의 실제 트리거 구조
제가 현재 운영 중인 구조를 구체적으로 말하면, TradingView 알림 → Make.com 웹훅 수신 → Jesse 전략 파라미터 조회 → Notion DB에 신호 로그 기록 → 조건 분기 → Claude API 호출 → WordPress 발행 순입니다. 이 흐름에서 Notion DB는 단순 저장소가 아니라 상태 관리자 역할을 합니다. 예를 들어 오늘 이미 BTC 포지션 신호가 기록됐으면 중복 발행을 막는 조건 체크를 Notion DB의 Date 필드와 Status Select 필드로 합니다. Make.com에서 Notion Search Database 모듈을 쓰면 필터를 걸어 오늘 날짜 + Status가 ‘Published’인 레코드가 있는지 확인할 수 있습니다. 있으면 시나리오를 중단하고, 없으면 다음 단계로 넘깁니다. 이게 생각보다 강력한 중복 방지 로직입니다. 별도 DB 없이 Notion만으로 처리됩니다. 주의할 점은 Notion API의 rate limit입니다. 공식 문서 기준 초당 3요청입니다. Make.com 시나리오가 짧은 간격으로 여러 Notion 모듈을 호출하면 429 오류가 납니다. 저는 Make.com의 Sleep 모듈을 Notion 모듈 사이에 1~2초씩 넣어서 해결했습니다. 느려 보이지만 자동화니까 상관없습니다.
Notion DB를 콘텐츠 파이프라인의 중심으로 쓰는 실전 설계
제 WordPress 블로그 자동 발행 파이프라인에서 Notion DB는 콘텐츠 큐 역할을 합니다. 발행 예정 글의 주제, 날짜, 섹션 아이디어, 상태값(Draft / Ready / Published)을 Notion DB에 모아두고, Make.com이 매주 토요일 특정 시간에 Status가 ‘Ready’인 레코드를 가져와 Claude API로 본문을 생성하고 WordPress에 올린 뒤 Status를 ‘Published’로 업데이트합니다. 이 구조의 핵심은 Notion DB가 단방향 저장소가 아니라 Make.com이 읽고 다시 쓰는 양방향 허브라는 점입니다. Notion Update Page 모듈로 상태를 바꾸는 것만으로도 전체 파이프라인의 흐름 제어가 됩니다. 실제로 제가 겪은 가장 유용한 패턴은 Notion DB에 ‘Retry’ 상태를 하나 더 만든 겁니다. Claude API가 실패하거나 WordPress 발행이 안 됐을 때 Status를 ‘Retry’로 바꾸고, Make.com 에러 핸들러가 Slack으로 알림을 보냅니다. 다음 트리거 때 Retry 상태 레코드를 먼저 처리하는 우선순위 로직을 추가했더니, 수동 개입 없이 상당수가 자동으로 재처리됩니다. 완벽하진 않지만 새벽에 자면서 시스템이 스스로 복구하는 걸 보면 꽤 뿌듯합니다.
💬 운영자 한마디
저는 Notion을 도구로 보지 않고 지금은 시스템의 ‘상태 저장소’로 봅니다. 어떤 자동화 시스템이든 상태를 어딘가에 저장해야 하는데, Notion은 그걸 시각적으로 확인할 수 있어서 디버깅이 훨씬 쉽습니다. 터미널만 보는 것보다 Notion DB 뷰를 열어서 Status 컬럼이 어떻게 변하는지 눈으로 보는 게 훨씬 빠르게 문제를 잡아줬습니다.
— J_River · autoprofit 운영자
✅ 이번 주 체크리스트
- Notion DB 필드 타입을 Make.com 연동 전에 확정하고 중간에 바꾸지 않기
- Select 필드의 모든 옵션값을 시나리오 하드코딩 전에 미리 Notion에 등록하기
- Make.com에서 Notion 모듈 연속 호출 시 Sleep 모듈로 1~2초 간격 삽입하기
- Status 필드에 ‘Retry’ 옵션 추가하고 에러 핸들러와 연결하기
- Notion Search Database 모듈로 중복 실행 방지 로직 구현하기
- Formula·Rollup 필드는 읽기 전용으로만 쓰고 Make.com이 쓰는 필드와 분리하기
- Notion DB 뷰를 갤러리 또는 보드로 설정해 Status 변화를 실시간으로 모니터링하기
Notion DB는 제대로 설계하면 별도 백엔드 없이도 꽤 복잡한 자동화 상태를 관리할 수 있습니다. 다음 주에는 이 구조에 Claude API를 더 깊이 붙이는 프롬프트 관리 방법을 정리해볼 예정입니다.
※ 본 콘텐츠는 운영자 개인의 경험과 연구를 바탕으로 한 정보 제공 목적이며, 특정 종목에 대한 투자 권유나 매매 시그널이 아닙니다. 암호화폐 및 자동매매는 원금 손실 가능성이 있는 고위험 활동이며, 모든 투자 판단과 그 결과에 대한 책임은 투자자 본인에게 있습니다.