바이브코딩으로 다 만드는데, 아직도 n8n을 쓰는 이유

요즘 커서나 클로드 코드 켜놓고 “이런 거 만들어줘” 한 줄 던지면 30분 만에 돌아가는 게 나온다.
사이트 긁어서 시트에 넣고 메일 쏘는 스크립트? 이제 진짜 뚝딱이다.
그러다 보면 자연스럽게 이런 생각이 든다.

그럼 n8n은 이제 뭐 하러 쓰지?

나도 요즘 그 생각을 많이 했다. 노드 드래그하는 시간에 코드 짜는 게 빠른데 굳이 캔버스를 켜야 하나 싶었다.

근데 나만의 고민이 아니었다. 레딧 n8n 커뮤니티에도 똑같은 글이 올라왔다. 반년을 열심히 썼는데 이제 가치를 모르겠다는 내용으로, 추천 175에 비추천 114, 댓글은 100개가 넘었다. 이게 흥미로운 지점이다. 답이 명확했으면 이렇게까지 갈리지 않았을 테니까.

• 바이브코딩 : 자연어 지시로 AI가 코드를 생성하게 하는 개발 방식
• 결정론적 워크플로우 : 같은 입력에 항상 같은 동작을 보장하는 실행 흐름

“n8n 필요없다”는 말, 질문 자체가 틀렸다

스레드에서 설득력 있던 답변들은 하나같이 같은 지점을 짚었다. 질문이 “n8n이냐 클로드 코드냐”로 잘못 잡혀 있다는 것이다.

둘은 경쟁 관계가 아니라는 것이 핵심이다. 하나는 만드는 도구고, 하나는 굴리는 도구다.
그래서 판단 기준도 “어느 쪽이 더 좋냐”가 아니라 재현성, 관측성, 비용, 인수인계 네 축으로 봐야 한다.
아래에서 하나씩 뜯어보자.

왜 결정론(deterministic)이 아직 중요한가?

댓글에서 제일 자주 나온 단어가 deterministic, 결정론적이라는 말이었다.
LLM이 끼지 않은 n8n 플로우는 돌릴 때마다 똑같은 일을 한다.
반면 에이전트에게 작업 전체를 맡기면 스키마가 살짝 바뀌거나 입력이 이상하게 들어왔을 때 무슨 짓을 할지 알 수 없다.

예를 들어보자.
매일 아침 CRM 리드 5,000건을 ERP에 동기화하고, 재고를 갱신하고, 슬랙에 인보이스를 올린다.
이 흐름 전체를 에이전트에게 맡길 이유가 없다.

리드 메모 요약처럼 판단이 필요한 한 지점에서만 모델을 부르고, 나머지는 그냥 실행되면 된다.

여기에 어떤 사람이 붙인 단서가 정확했다.
결정론적인 건 플로우의 로직이지, 플로우가 돌아가는 환경이 아니라는 것이다.
필드를 조용히 바꾸는 API, 레이트 리밋, 순서가 뒤바뀐 페이지네이션, 두 번 들어오는 웹훅.
결국 재현성은 가장 불안정한 의존성만큼만 보장된다.

구성	재현성	디버깅 난이도
LLM 없는 n8n 플로우	환경 변수 한도 내에서 보장	낮음
판단 지점만 LLM	해당 노드만 비결정적	중간
에이전트에 전체 위임	구조적으로 보장 불가	높음

중간에 LLM을 하나 끼우는 순간 “대체로 재현 가능”이 “구조적으로 재현 불가능”으로 바뀐다.
성격이 아예 다른 문제가 된다.

새벽 3시에 터졌을 때, 무엇을 볼 수 있나?

자동화 장애 고치는 일로 먹고산다는 사람의 답변이 이 스레드에서 제일 좋은 평가를 받았다.
핵심은 한 문장이었다. 새벽 3시에 뭔가 터졌을 때 내가 무엇을 볼 수 있느냐는 것이다.

• n8n : 노드별 입력과 출력이 남는다. 어느 노드에서 어떤 페이로드가 실패했는지 10초면 확인된다.
• AI가 짜준 스크립트 : 내가 로깅을 심어둔 만큼만 보인다. 그리고 대부분은 안 심는다.

토큰 저장, OAuth 갱신, 백오프를 곁들인 재시도도 마찬가지다. 클로드 코드에 시키면 기꺼이 짜준다. 문제는 그 코드의 소유권이 그 순간부터 영원히 나에게 있다는 것이다. 토큰 만료는 새벽 3시에 내가 처리해야 하는 일이 된다.

실무에서 제일 아픈 실패 유형도 언급됐다.
아무것도 출력하지 않으면서 성공으로 끝나는 실행이다.
n8n에서는 실행 기록에 빈 출력이 그대로 박혀 있다. 커스텀 스크립트에서는 관측 가능성을 미리 만들어두지 않는 한, 이런 실패가 아예 눈에 띄지 않는다.

토큰 비용은 어디서 갈리나?

이벤트마다 에이전트를 깨우는 크론은 토큰 소모를 예측할 수 없다. n8n은 판단이 필요한 단계에서만 모델 값을 내고, 나머지 구간은 토큰 없이 돈다. 그리고 그 나머지 구간이 훨씬 넓다.

대량 반복 작업에서는 비용뿐 아니라 품질도 갈린다. 어느 마케터의 사례가 인상적이었다. 카피 1,000페이지를 한 번에 시켰을 때는 결과가 무너졌는데, n8n 워크플로로 한 건씩 나눠 호출했더니 훨씬 나은 결과가 나왔다는 것이다.
컨텍스트를 잘게 쪼개주는 오케스트레이터가 있느냐 없느냐의 차이다.

나 말고 다른 사람이 운영할 수 있는가?

의외로 실무에서는 이 항목이 제일 크다.

터미널을 한 번도 열어본 적 없는 클라이언트가 실행 기록을 보고 “이게 실패했구나”까지 스스로 파악한다.
자격 증명도 클라이언트 계정에 있으니, 관계가 끝나면 비밀번호 하나 바꾸는 걸로 정리된다.
스크립트 뭉치로 넘기면? 1년 전에 일이 끝난 회사의 토큰을 내가 아직 들고 있는 상황이 된다.

시각적 플로우는 그 자체로 문서 노릇도 한다. 의료 쪽에서 일한다는 사람은 워크플로를 화면에 띄워놓고 단계별로 설명할 수 있다는 점을 신뢰의 근거로 들었다. MSP에서 워크플로 130개 넘게 운영한다는 사람의 정리도 좋았다. 핵심은 특정 노드가 아니라, 원래 서로 연결될 생각이 없었던 도구 여섯 개를 하나의 흐름으로 엮어준다는 데 있다는 것이다.

그럼 n8n을 접어야 할 때는 언제인가?

비추천이 114개나 달린 데는 이유가 있다. 반대 의견도 근거가 약하지 않았다.

1. 기술의 이식성 — 캔버스 개발에 익숙해지면 캔버스 개발을 잘하게 될 뿐이다. OpenAI 캔버스도 Flowise도 접혔고, 몇 년을 n8n에 투자했다가 지금 코드를 처음부터 다시 배운다는 사람의 이야기는 뼈아팠다.
2. 락인 — n8n 방식으로 한번 엮으면 그 캔버스에 계속 묶인다. 대안이 없던 시절이라면 감수할 만했지만, 지금은 Trigger.dev, Hookdeck, Temporal, Dagu 같은 코드 기반 선택지가 있다.
3. 성능 한계 — n8n으로 프로토타입 만들고 운영은 파이썬으로 옮긴다는 답변이 여럿이었다. 데이터 볼륨이 커지면 버거워하는 구간이 실제로 있다.
4. 비용은 방향이 반대일 수도 — n8n을 끊고 VPS에 직접 구성해서 월 144달러를 아꼈다는 사례도 있었다.
5. 라이선스 — 클라이언트 워크플로를 내 VPS에 호스팅하는 건 n8n의 Sustainable Use License 위반이라는 지적이 나왔다. 대행 사업을 생각한다면 반드시 원문을 확인하고 넘어가자.

덧붙이자면 이 스레드 전반에 “이 댓글 AI가 쓴 거 아니냐”는 반응이 계속 달렸다.
요즘 커뮤니티 토론을 읽을 때 기본으로 적용할 할인율 정도로 생각하면 되겠다.

나는 이 둘을 어떻게 나눠 썼나

직접 굴려본 얘기를 해야 공평하겠다.
이 블로그를 블로거에서 워드프레스로 옮길 때 두 번 크게 신세를 졌다.

첫째, 이전 과정에서 사라진 글을 Wayback Machine에서 긁어와 복원했다.
둘째, 글 80여 편에 메타 디스크립션과 내부 링크를 자동으로 붙였다.

둘 다 n8n 워크플로였다.

여기서 역할이 정확히 갈린다. 워크플로를 설계하고 막힌 데를 뚫는 일은 클로드와 했다.
노드 배치, 표현식 문법, 실패 조건 처리 같은 건 물어보는 게 빨랐다.
하지만 그걸 81번 반복해 돌리면서 몇 번째가 어디서 실패했는지 확인하는 일은 n8n이 했다.
중간에 몇 건은 원문 구조가 달라서 빈 출력으로 끝났는데, 실행 기록에 그대로 남아 있어서 그 건만 골라 다시 돌렸다.

이걸 스크립트 한 덩어리로 짰다면 어땠을까. 아마 어디서 몇 건이 조용히 실패했는지 모른 채 넘어갔을 것이다.
반대로 노드를 전부 손으로 깔았다면 설계에만 며칠 썼을 거고.

어디에 무엇을 둘까: 판단 기준표

이런 성격의 일이면	어디에
매일·매시간 반복되고 트리거가 정해져 있다	n8n
여러 SaaS의 토큰과 OAuth를 계속 물고 있어야 한다	n8n
실패했을 때 누군가에게 보여줘야 한다	n8n
나 말고 다른 사람이 운영하거나 수정해야 한다	n8n
한 번 쓰고 버리는 탐색적 작업이다	클로드 코드
로직이 복잡하고 테스트가 필요하다	코드
데이터 볼륨이 크고 성능이 관건이다	코드
판단이 필요한 단계다	어느 쪽이든, 그 단계에만 LLM

마무리: 만드는 도구와 굴리는 도구

한 줄로 줄이면 이렇다.

클로드 코드가 만들고, n8n이 굴린다.

바이브코딩이 강력해질수록 “만드는 비용”은 계속 싸진다. 그래서 판단 기준도 옮겨간다.
이제 물어볼 건 “이거 만들 수 있나”가 아니라 “이거 6개월 뒤에 누가 고치나”다.