n8n vs Make vs 직접 코드 — LLM 워크플로 자동화, 어디부터 코드로 내려가는 게 맞나요
1인 개발로 자동화 여러 개 굴리는데 도구 선택이 계속 고민됩니다.
지금 상황:
- 단순한 거(RSS → 요약 → Slack)는 Make로 5분이면 만듦
- 근데 분기/재시도/상태 관리 들어가는 순간 노코드가 스파게티 됨. Make에서 Router 안에 Router 들어가기 시작하면 답 없음
- 그렇다고 전부 코드로 짜자니 OAuth 토큰 갱신 같은 단순 연동까지 직접 관리하는 게 부담
n8n 셀프호스팅도 보는 중인데, 어느 선까지 노코드로 가고 어느 지점부터 코드로 내려가는 게 맞을까요. "이런 신호 보이면 코드로 내려가라" 같은 경험 기반 기준이 있으면 알려주세요.
답변 3개
- 채택된 답변
저도 똑같은 길 걸었는데, 제가 쓰는 기준은 한 줄로 **"이 로직에 상태가 끼나"**입니다. 상태(state) 안 끼면 노코드, 끼는 순간 코드로 내립니다.
노코드(Make/n8n)에 그냥 두는 게 맞는 거:
- 본질이 "A 데이터를 B로 옮기기"인 연동. OAuth 토큰 갱신, 페이지네이션, rate limit 같은 거 도구가 알아서 처리해주는 게 진짜 큽니다. 이거 직접 짜면 토큰 만료 핸들링하다 하루 날아감
- 분기 2~3개 이하의 얕은 흐름
- 비개발자도 들여다봐야 하는 운영 자동화
코드로 내려가야 하는 신호는 명확하게 옵니다:
- 멱등성/재개가 필요해지는 순간. "이미 처리한 건 또 처리하면 안 됨", "중간에 죽으면 그 지점부터 재개" 이런 요구 생기면 노코드는 바로 한계. Make Data Store에 처리한 id 박아두는 식으로 버티다가 결국 코드로 옮겼습니다
- 분기/루프가 3중 넘게 깊어질 때. 노드가 화면에서 스파게티 되면 그게 신호예요. 이 시점엔
if/for코드가 훨씬 읽기 쉬움 - 테스트가 필요할 때. 결제/정산처럼 머니패스 걸린 로직은 단위테스트 필수인데 노코드는 사실상 테스트 불가
- diff 리뷰가 필요할 때. 블루프린트 JSON은 diff가 사람이 못 읽음
제 실전 절충안은 그냥 하이브리드입니다. 트리거랑 귀찮은 연동(인증 부분)은 Make/n8n에 맡기고, 진짜 비즈니스 로직은 webhook으로 받는 작은 함수(저는 Cloudflare Workers 씀, Lambda도 됨)로 넘김. 노코드는 배선, 코드는 두뇌. 이렇게 쪼개니까 양쪽 장점만 가져옵니다. 케바케지만 1인 운영엔 이게 제일 안정적이었어요.
멱등성 얘기 나온 김에 하나. 노코드에서 "멱등성 키 잡으면 됨"이 말처럼 쉽지 않은 게, 키를 어디서 잡느냐가 진짜 함정임.
예전에 Make에서 RSS → 요약 → Notion 적재 돌렸는데, 중복 방지를 "이미 Notion에 같은 URL 있나 Search"로 처리했었음. 멀쩡히 도는 줄 알았는데 어느 날 같은 글이 3번 들어와 있더라고요. 원인이 두 갠데 — (1) 피드가 1분 안에 두 번 트리거되면 둘 다 Search 시점엔 아직 "없음"이라 둘 다 insert (전형적인 read-check-write race), (2) 소스가 트래킹 파라미터 붙여서 같은 글 URL을 살짝 다르게 내보냄. 그래서 URL 기준 dedup이 그냥 뚫림.
결국 키를 파이프라인 초입에서 정규화해서 잡아야 함. RSS면
guid(없으면 URL을 querystring 떼고 normalize)로 해시 떠서, Notion 적재 전에 DB나 Make Data Store에 그 해시 unique로 박고 → 이미 있으면 거기서 중단. Search-then-insert가 아니라 "insert가 실패하면 중복"이 되게 unique constraint에 일을 맡기는 거.케바케지만 내 경험상 노코드에서 race까지 막으려고 하면 그 시점이 보통 코드로 내려갈 신호였음. 작은 워커 하나에 unique 인덱스 두고 거기로 webhook 쏘는 게 Make 안에서 분기로 dedup 흉내내는 것보다 훨씬 안전했어요.
셀프호스팅 관점에서 한마디. n8n 셀프호스팅 "무료"는 살짝 함정입니다. 컨테이너 띄워놔야 하고 업데이트/백업/모니터링이 다 본인 책임으로 옵니다.
특히 트리거가 폴링이나 WebSocket 기반이면, 프로세스가 죽었는데 대시보드엔 멀쩡해 보이는 상황이 옵니다. 저는 워커가 OOM으로 조용히 떨어졌는데 UI는 active라고 떠 있어서 이틀치 실행이 통째로 누락된 적 있어요. 그 뒤로 "매시간 핑 안 오면 알림" 식 외부 헬스체크 꼭 겁니다.
1인이고 자동화 개수 아직 적으면 그냥 관리형(Make)으로 시작하다가, 실행량 많아져서 ops 과금 부담되는 시점에 셀프호스팅 넘어가는 게 맞다고 봅니다. 처음부터 인프라 관리에 시간 쓰는 건 본말전도예요.