B Builder로그
Builderlog ·미니앱 출시기 11 ·2026.07.08 ·2 분 읽기

자동화 도구 고르기 전에, 저는 이 질문을 먼저 해요

#자동화#n8n#Make#노코드#사이드프로젝트

편의점 1+1 행사 앱 만들면서 자동화 워크플로 세 개를 짰어요. 근데 나중에 보니까 그 중 하나는 애초에 안 만들었어야 했고, 하나는 그냥 크론탭 한 줄이면 됐더라고요. n8n이냐 Make냐 고민하기 한참 전에 물었어야 할 게 따로 있었어요.

도구 비교표가 먼저가 아니더라고요

자동화 얘기 나오면 대부분 스레드가 n8n vs Make vs Zapier 삼파전으로 흘러요. 저도 처음엔 그쪽부터 뒤졌어요. 근데 어느 순간 깨달은 게 있어요. 도구 선택은 사실 제일 마지막 질문이라는 거.

먼저 해야 할 질문은 이거예요. “이 작업, 지금 얼마나 자주 하고 있어요?”

앱 신규 가입자 알림을 Slack으로 받고 싶었어요. 폼나 보이잖아요. 근데 따지고 보니까 하루 가입자가 많아야 열 명이었고, 저는 그 알림을 보고 뭔가를 하지도 않았어요. 그냥 쌓아뒀죠. 자동화가 아니라 알림 쓰레기통을 만든 거예요.

자동화 뒤에 내가 실제로 뭔가를 하는지를 먼저 그려봐야 해요.

반복 횟수 × 손이 닿는 시간 계산해 봤어요

두 번째 질문은 “자동화 안 하면 얼마짜리 일이에요?” 예요.

행사 데이터를 편의점 별로 파싱해서 DB에 넣는 건 주 2회, 한 번에 20분쯤 걸렸어요. 월 160분. n8n 셋업에 반나절, 디버깅에 또 반나절 썼는데 이건 명백히 남는 장사였어요. 그래서 짰고, 지금도 잘 돌아가요.

반대로 사용자 문의 분류 자동화는 달랐어요. 월 문의가 스무 건도 안 됐거든요. 프롬프트 설계하고, 분류 틀 잡고, 엣지케이스 테스트하는 데 쓴 시간이 6개월치 수동 분류보다 길었어요. 지금은 그냥 손으로 해요.

'시간 절약'이라고 믿었던 자동화가 사실 시간 소비였던 적이 한두 번이 아니에요.

자동화가 맞더라도, 도구가 과한 경우가 있어요

이건 좀 민망한 얘긴데요. 특정 시간에 DB 집계해서 파일로 떨어뜨리는 거, n8n으로 짰어요. 노드 네 개짜리 워크플로. 근데 그거 결국 리눅스 크론탭 한 줄 + 파이썬 스크립트로 옮겼어요. n8n 컨테이너 유지 비용이랑 가끔 뜨는 웹훅 오류 디버깅이 더 피곤했거든요.

Make나 n8n이 빛나는 건 외부 서비스 여러 개가 얽혀있을 때예요. 트리거가 구글 시트고, 중간에 API 호출 있고, 끝에 슬랙 메시지 보내는 그런 류. 그게 아니라면 진짜로 더 단순한 도구가 맞을 때가 많더라고요.

n8n을 쓸 이유보다 안 써도 되는 이유를 먼저 찾게 됐어요.

제가 지금 쓰는 체크리스트

자동화 하나 만들기 전에 저는 이것만 물어봐요.

  1. 이 작업, 월에 몇 번? → 열 번 미만이면 일단 의심
  2. 자동화 결과로 내가 뭘 할 거야? → 대답 못 하면 패스
  3. 외부 서비스 연동이 있어? → 없으면 스크립트로 먼저 고려
  4. 실패하면 어떻게 알 수 있어? → 모니터링 없는 자동화는 시한폭탄

도구 선택은 3번에서 ‘있다’고 나왔을 때 시작해요. 그때 가서 n8n이냐 Make냐 따져도 늦지 않더라고요.

한 줄로 정리하면

자동화 도구 고르기 전에 '이걸 왜, 얼마나 자주, 자동화한 뒤 뭘 할 건지'를 먼저 따지는 게 삽질을 줄여줬어요.

다음 편에서는 실제로 n8n을 선택했을 때, 워크플로 설계에서 제일 먼저 무너지는 지점을 얘기해볼게요.