노션 자동화가 자꾸 꼬인다면
상태 이름부터 줄여보세요

먼저 자동화 없이 일주일 써봅니다

콘텐츠 아이디어를 기록하는 데이터베이스라면 제목, 담당자, 상태, 발행 예정일만 둡니다. 상태는 ‘아이디어–작성 중–검토–발행’ 네 개면 충분합니다. 일주일 동안 사람이 상태를 바꿔보면 실제로 알림이 필요한 순간이 보입니다.

처음부터 속성을 열다섯 개 만들면 빈 값이 많아지고 조건도 길어집니다. 자동화가 실패했을 때 원인이 데이터인지 설정인지 구분하기 어려워집니다. 사용하지 않은 속성은 나중에 추가하는 편이 낫습니다.

공식 도움말은 트리거와 작업을 따로 설명합니다

Notion 공식 도움말의 목차를 보면 자동화 조건과 작업, 오류가 별도 항목으로 나뉩니다. 화면에서 ‘자동화 만들기’ 버튼만 따라가기 전에 어떤 변화가 시작점이고, 그 뒤 무엇을 바꿀지 문장으로 적어야 하는 이유입니다.

첫 자동화는 ‘검토로 바뀌면 담당자에게 알림’이면 충분합니다

트리거는 상태가 ‘검토’로 변경될 때, 작업은 담당자에게 알림 보내기로 둡니다. 테스트 항목을 하나 만들고 상태를 아이디어에서 검토로 바로 바꿔봅니다. 알림이 오면 끝이 아니라 누가 알림을 받았는지, 같은 상태를 다시 선택했을 때 또 오는지까지 봐야 합니다.

발행 상태가 되면 날짜를 자동 입력하는 규칙도 만들 수 있습니다. 여기서 ‘발행 예정일’을 덮어쓸지 ‘실제 발행일’을 새로 기록할지 정해야 합니다. 같은 날짜 속성을 재사용하면 계획이 얼마나 미뤄졌는지 나중에 알 수 없습니다.

자동화가 자기 자신을 다시 부르는지 확인합니다

자동화 A가 상태를 바꾸고, 상태 변경을 본 자동화 B가 다시 A의 조건을 만드는 구조가 생길 수 있습니다. 설정 화면에서는 각각 정상으로 보이지만 항목 기록에는 같은 변경이 반복됩니다. 자동화가 수정하는 속성과 트리거로 감시하는 속성을 분리하면 이런 순환을 줄일 수 있습니다.

작동하지 않을 때는 권한도 봅니다. 연결된 사용자나 통합이 해당 데이터베이스에 접근할 수 있는지, 담당자 속성이 실제 사람 유형인지, 날짜가 비어 있지 않은지 확인합니다. 상태 이름 끝에 숨어 있는 공백처럼 눈에 잘 안 보이는 차이도 조건을 빗나가게 합니다.

외부 도구를 붙일 때는 고유값이 필요합니다

n8n이나 Zapier로 폼 응답을 노션에 넣으면 같은 응답이 재시도 과정에서 두 번 생성될 수 있습니다. 폼 응답 ID나 원본 URL처럼 중복을 판별할 속성을 하나 둡니다. 제목만으로 중복을 판단하면 같은 주제의 다른 작업까지 합쳐질 수 있습니다.

외부 연동에는 제목·원본 링크·상태처럼 필요한 필드만 먼저 보냅니다. 연결이 안정된 뒤 담당자와 날짜를 추가하세요. 모든 속성을 한 번에 매핑하면 하나의 필드 형식이 바뀌었을 때 전체 흐름이 멈춥니다.

일주일 뒤에 지울 자동화도 정합니다

알림을 받았지만 아무 행동도 하지 않은 규칙은 소음일 가능성이 큽니다. 실행 횟수, 누락, 사람이 다시 고친 횟수를 기록하고 도움이 없던 규칙은 끕니다. 자동화가 많다는 사실은 업무가 잘 정리됐다는 증거가 아닙니다.

규칙 이름에는 결과보다 조건을 적는 편이 찾기 쉽습니다. ‘콘텐츠 알림’보다는 ‘상태가 검토이고 담당자가 있을 때 알림’처럼 쓰면, 몇 달 뒤 자동화 목록을 열었을 때 어떤 조건이 겹치는지 바로 보입니다. 수정 날짜와 담당자도 페이지 상단에 짧게 남겨두면 퇴사나 업무 이동 뒤에 방치될 가능성이 줄어듭니다.