직접 부딪혀보고 정리한 자동화 용어들

RENE insight – Make를 이용하여 노션 일정을 구글 캘린더로 자동 연동한 기록

(앞선 Make 시나리오 글에 이어서.)

A: 노션에서 구글 캘린더 연동한 거 봤다. 어떻게 한 거냐?
R: 어…….

Make 작업을 마치고 친구에게 설명을 하려고 생각해보니, 한 번도 들어본 적 없는 용어들이 머리 위를 스쳐 지나갔다. Claude는 친절히 설명해줬지만, 이해와 외움은 다른 일이다. 다음 시나리오를 만들 때, 그리고 친구에게 설명할 때를 위해 정리해둔다. 일반인 시점에서, 직접 부딪힌 만큼만.

자동화의 최소 단위_ 트리거·액션·연동

자동화는 결국 한 문장으로 줄어든다. “이런 일이 생기면 → 이런 일을 한다.”

트리거(Trigger): 자동화를 깨우는 신호. “이런 일이 생기면”의 그 일.
액션(Action): 트리거에 반응해 실행되는 작업. “이런 일을 한다”의 그 일.
연동(Integration): 트리거와 액션이 서로 다른 도구 사이에서 일어나는 것. 노션에 일정이 추가되면 → 구글 캘린더에 생성된다. 이 화살표를 가능하게 하는 것.

자동화가 어려워 보이는 건 용어 때문이지 구조 때문은 아니다. 알람이 울리면 일어나고, 비가 오면 우산을 챙기는 것도 트리거-액션이니까.

종 아이콘의 트리거 박스에서 톱니바퀴 아이콘의 액션 박스로 화살표가 이어지는 업무자동화 기본 구조 도식, 일정이 추가되면 캘린더에 생성한다는 예시

도구 사이의 통역사_ API

API는 자동화의 시작점이라 다시 짚는다. 노션과 구글 캘린더는 서로 다른 회사가 만든 프로그램이라, 서로의 언어를 모른다. 대신 약속된 형식으로 데이터를 주고받는다. 이 약속이 API(Application Programming Interface)다.

비유하면 통역사다. Make가 통역사이고, 노션과 구글 캘린더는 각자의 언어로 말을 건넨다. API 키를 입력한 순간이 통역 채널이 열리는 순간이었다. “이 사람(Make)이 너(노션)에게 말 걸 권한이 있다”는 인증서를 발급하는 셈이다.

노션과 구글 캘린더 사이에서 Make가 API 통역사 역할을 하는 자동화 연동 구조 도식, 양방향 화살표로 데이터 교환을 표현

시나리오 안의 부품들_ 모듈·매핑·라우터

Make 캔버스를 처음 봤을 때, 도형과 선이 정신없이 얽혀 있었다. 아이콘은 익숙한데 문구와 선의 정체가 궁금했다.

모듈(Module) / 노드(Node): 시나리오 안의 박스 하나하나. Make는 “모듈”, n8n은 “노드”라 부른다. 같은 개념, 다른 이름. 각 박스는 “노션 DB에서 항목 가져오기” 같은 작업 하나를 담는다.
매핑(Mapping): 한 모듈의 출력을 다음 모듈의 어느 칸에 넣을지 짝짓는 일. 노션의 “할 일 이름”을 구글 캘린더 “Event Name”에 연결한다. 엑셀에서 셀 참조하듯이.
라우터(Router): 분기점. 조건에 따라 흐름을 둘 이상으로 나눈다. “기존 ID면 업데이트, 새 ID면 생성”이 라우터의 일이다.

Notion DB 모듈에서 ID 확인 라우터를 거쳐 신규는 생성, 기존은 업데이트로 분기되는 Make 시나리오의 모듈·매핑·라우터 구조 도식

트리거가 일하는 두 방식_ 폴링·웹훅

지난 글 마지막의 “크레딧이 왜 이렇게 빨리 녹지?”에 대한 답이 여기 있다.

폴링(Polling): 자동화 도구가 일정 간격으로 “변한 거 있어?”라고 묻는다. Make 무료는 최소 15분, 유료(Core 이상)는 1분까지.
웹훅(Webhook): 반대로 원본 도구가 변화가 생기면 “변했어!”라고 알려준다. 즉시 반응.

비유하면 폴링은 우체통을 15분마다 확인하러 가는 것, 웹훅은 우편물이 오면 알림이 울리는 것.

좌측 폴링은 Make가 15분마다 Notion에 반복해 묻는 구조, 우측 웹훅은 Notion이 변화 발생 시 즉시 알려주는 구조를 비교한 도식

이게 비용과 직결된다. 폴링은 변화가 없어도 매 체크 자체가 1크레딧을 먹는다. 1분 폴링이면 하루 1,440번, 한 달 약 43,000번. 시나리오는 한 번도 안 돌았는데 크레딧만 사라지는 상황이 가능하다. 내가 만든 시나리오도 폴링 방식이라, 노션에 변화가 없어도 15분마다 묻고 있는 셈이다.

그래서 뭘 자동화할 수 있나

용어를 익히니 어떤 문장을 쓸 수 있는지 보인다. 폭이 생각보다 넓다.

일정·정보 동기화: 노션 ↔ 구글 캘린더, 노션 변경 → 슬랙 알림
구글 폼 응답 정리: 응답이 들어오면 → 스프레드시트 정리·슬랙 알림·이메일 회신
콘텐츠 자동 발행: 블로그 글이 올라가면 → SNS 여러 채널 동시 공유
영수증·문서 정리: 메일 첨부 영수증 → 드라이브 저장·시트 기록
회의록 정리: 녹취 → 요약 → 노션 등록

대부분 “정보가 한 곳에서 다른 곳으로 옮겨가는 일”이다. 반복적이고, 규칙이 뚜렷하다.

자동화 워크플로가 트리거에서 액션과 API, 모듈, 매핑을 거쳐 완료되는 과정을 보여주는 개념도

마무리 — 자동화가 어울리는 일의 경계

정리하고 나니 자동화가 잘 맞는 일과 그렇지 않은 일의 경계가 보인다.

자동화는 반복되고 결과가 명확한 일에 잘 맞는다. 영수증을 시트에 옮기고, 일정을 양쪽 캘린더에 두고, 폼 응답을 정리하는 일. 패턴이 분명하고 검증 가능하다.

반대로 맥락이 필요한 일엔 빈자리가 크다. 회의록 요약은 잘 한다. 그런데 회의 중 누군가 잠시 말을 멈춘 그 침묵, 깊은 생각에 대화가 끊긴 그 결까지는 담기지 않는다. 비언어적 맥락은 자동화에 잘 안 잡힌다.

자동화는 효율을 위한 도구일 뿐, 모든 걸 자동화한다고 효율이 오르진 않는다. 무엇을 맡기고 무엇을 직접 들고 갈지, 그 선을 어디에 그을지가 결국 사용자의 몫인 듯하다.

업무자동화. 직접 부딪혀보고 정리한 핵심용어 설명