[Prologue]
(앞선 Make 시나리오 글에 이어서…)
A: 노션에서 구글 캘린더 연동 시킨 거 봤다. 어떻게 한 거냐?
R: 어.......
Make 작업을 마치고 돌아보니, 한 번도 들어본 적 없는 용어들이 머리 위를 지나갔다. 클로드는 친절히 설명해 줬지만, 이해와 외움은 다른 일이다. 다음에 다른 시나리오를 만들 때, 그리고 친구에게 설명할 때를 위해 정리해두려 한다. 비개발자 시점에서, 직접 부딪힌 만큼만.
[자동화의 최소 단위]_트리거·액션·연동
자동화는 결국 한 문장으로 줄여지는 듯하다.
"이런 일이 생기면 → 이런 일을 한다."
- 트리거(Trigger): 자동화를 깨우는 신호. "이런 일이 생기면"의 그 일.
- 액션(Action): 트리거에 반응해 실행되는 작업. "이런 일을 한다"의 그 일.
- 연동(Integration): 트리거와 액션이 서로 다른 도구 사이에서 일어나는 것. 노션에서 일정이 추가되면 → 구글 캘린더에 생성된다. 이 화살표를 가능하게 하는 것.
자동화가 어려워 보이는 건 용어 때문이지, 구조 때문은 아닌 듯하다. 알람이 울리면 일어나고, 비가 오면 우산을 챙기는 것도 트리거-액션의 구조니까.
[도구 사이의 통역사]_API
지난 글에서 잠깐 정의는 적었지만, API는 자동화의 시작점이라 다시 짚고 넘어가야 할 듯하다.
노션과 구글 캘린더는 서로 다른 회사가 만든 다른 프로그램이다. 둘은 서로의 언어를 모르고, 손짓발짓도 못 알아듣는다. 서로 무슨 단어를 말하는지, 어느 위치를 가리키고 있는지 말이다. 대신 약속된 형식으로 데이터를 주고받는다. 이 약속된 형식이 API(Application Programming Interface)다. 비유하자면, 도구마다 다른 언어를 쓰는데 그 사이에 통역사를 두는 셈. Make가 통역사이고, 노션과 구글 캘린더는 각자의 언어로 말을 건넨다. API 키를 입력했던 그 순간이, 통역 채널이 열리는 순간이었던 듯하다. "이 사람(Make)이 너(노션)에게 말을 걸 권한이 있어"라는 인증서를 발급해 주는 것이다.
[시나리오 안의 부품들]_모듈·매핑·라우터
Make의 캔버스 예시를 처음 봤을 때, 도형과 선이 정신없이 얽혀 있었다. 아이콘은 익숙한데 문구와 선, 옵션의 정체는 궁금했다.
- 모듈(Module) / 노드(Node): 시나리오 안의 박스 하나하나. Make는 "모듈"이라 부르고, n8n은 "노드"라 부른다. 같은 개념인데 도구마다 이름이 다르다. 각 박스는 하나의 작업을 담는다. "노션 DB에서 항목 가져오기" 같은.
- 매핑(Mapping): 한 모듈의 출력 데이터를 다음 모듈의 어느 칸에 넣을지 짝지어주는 일. 노션의 "할 일 이름"을 구글 캘린더의 "Event Name"에 연결한다. 엑셀에서 셀 참조하듯이.
- 라우터(Router): 분기점. 조건에 따라 흐름을 둘 이상으로 나눈다. "기존 ID면 업데이트, 새 ID면 생성"이 라우터의 일이다.
[트리거가 일하는 두 가지 방식]_웹훅·폴링·폴링 간격
여기가 Make 글 마지막의 "크레딧이 왜 이렇게 빨리 녹지?"에 대한 답인 듯하다.
트리거가 작동하는 방식은 크게 두 가지다.
- 폴링(Polling): 자동화 도구가 일정 간격으로 원본 도구에게 "변한 거 있어?"라고 묻는다. Make 무료 플랜은 최소 15분 간격, 유료 플랜(Core 이상)은 1분까지 가능하다. (2026.05월 기준)
- 웹훅(Webhook): 반대로 원본 도구가 변화가 생기면 자동화 도구에게 "변했어!"라고 알려준다. 즉시 반응(Instant Trigger).
비유하자면, 폴링은 우체통을 15분마다 확인하러 가는 것이고, 웹훅은 우편물이 오면 알림이 울리는 것.
이 부분은 Make나 Zapier에서 비용과 직결된다. 폴링은 변화가 없어도 매 체크 자체가 1 크레딧을 소모한다. 업데이트의 신속함이 필요하다면 1분마다 폴링해야 한다. 1분 폴링이면 하루 1,440번, 한 달이면 약 43,000번. 시나리오는 한 번도 안 돌았는데 크레딧만 사라지는 상황이 가능하다.
내가 make에서 작성했던 시나리오는 폴링 방식이다. 그래서 노션 일정에 변화가 없어도 15분마다 Make는 노션에게 묻고 있는 셈. 의뢰주와 상의하여 폴링 간격을 조정해 봐야 할 듯하다. 아니면 유료 구독을 재촉해서 내 경험의 자양분으로 치환해도 좋을 듯.
[그래서, 뭘 자동화할 수 있나]_사례별
용어를 익혔으니 어떤 문장을 쓸 수 있는지 보자. 이 도구들로 가능한 자동화는 생각보다 폭이 넓다.
- 일정·정보 동기화: 노션 ↔ 구글 - 캘린더 일정연동, 노션 ↔슬랙 - 노션 변경사항 슬랙 알림, 슬랙에서 노션DB로 아카이빙.
- 구글 폼 응답 정리: 구글 폼에 응답이 들어오면 → 스프레드시트 정리, 슬랙 알림, 이메일 회신.
- 콘텐츠 자동 발행: 블로그 글이 올라가면 → SNS 여러 채널에 동시 공유.
- 영수증 처리·문서 정리: 메일에 첨부된 영수증 자동으로 → 드라이브 저장, 시트에 항목별 기록.
- 회의록 정리: 회의록 녹취 → 녹취록 작성 및 요약 → 노션 등록
- 알림 라우팅: 이메일 키워드 감지 → 중요한 건 슬랙으로, 그 외는 정리만.
대부분 "정보가 한 곳에서 다른 곳으로 옮겨가는 일"이다. 그리고 반복적이고, 규칙이 뚜렷하다.
[마무리]
여기까지 정리하고 나니, 자동화가 잘 어울리는 일과 그렇지 않은 일의 경계가 보이는 듯하다.
자동화는 반복되고, 결과가 명확한 일에 잘 맞는다. 영수증을 시트에 옮기는 일, 일정을 양쪽 캘린더에 동시에 두는 일, 폼 응답을 정리하는 일. 패턴이 분명하고, 결과를 검증할 수 있다.
반대로, 맥락이 필요한 일에는 자동화의 빈자리가 크다. 회의록 요약은 잘 한다. 그런데 회의 중간에 심각하게 고민했던 순간, 누군가 잠시 말을 멈춘 그 침묵, 깊은 생각이 필요해서 대화가 끊어진 그 결까지는 요약에 담기지 않는다. 비언어적 맥락은 자동화에 잘 안 잡히는 듯하다.
자동화는 효율을 위한 도구일 뿐, 모든 일을 자동화한다고 효율이 올라가는 건 아닌 듯하다. 무엇을 맡기고 무엇을 직접 들고 갈지, 그 선을 어디에 그을지가 결국 사용자의 몫인 것 같다.
※ 본문 도식 4장은 클로드에게 프롬프트를 받고 GPT에서 생성함. 세부수정을 통해 퀄리티를 높이고 싶었지만, 테스트 목적이었기 때문에 패스. 한글은 프롬프트 입력한 대로 깨짐 없이 깔끔하게 잘 나온 듯.