n8n vs 직접 코드: 우리가 선택하는 기준
n8n 같은 노코드 자동화 도구와 직접 코드 중 무엇을 선택해야 할까요? Plan AI가 프로젝트마다 둘 사이를 결정하는 5가지 기준을 공유합니다.
자동화 프로젝트를 시작할 때 매번 마주치는 질문이 있습니다. 'n8n이나 Zapier 같은 도구로 할까, 아니면 처음부터 코드로 짤까?'
양쪽 모두 강력한 진영이 있습니다. 노코드 진영은 '5분이면 끝나는 걸 왜 한 달씩 코딩하냐'고 하고, 코드 진영은 '결국 복잡해지면 직접 짠 게 답이다'라고 합니다. 둘 다 부분적으로 맞고, 둘 다 부분적으로 틀립니다.
Plan AI는 매 프로젝트마다 5가지 질문을 거쳐서 결정합니다. 정답이 정해진 영역이 아니라, 트레이드오프를 명시적으로 따지는 영역입니다.
1. 이 자동화가 1년 후에도 같은 모양일까?
가장 먼저 묻는 질문입니다.
자동화 로직이 안정적이고 거의 안 바뀌는 종류라면 — 예를 들어 '매일 아침 9시에 어제 매출 데이터를 슬랙에 올린다' — n8n으로 30분이면 됩니다. 직접 코드로 짜는 건 시간 낭비입니다.
반대로 로직이 계속 변할 종류라면 — '고객 행동 패턴에 따라 다른 메시지를 보낸다, 패턴은 매달 갱신된다' — 노코드로 시작하면 3개월 후에 후회합니다. 노코드 워크플로는 분기·반복·예외 처리가 많아질수록 빠르게 사람이 못 읽는 그림이 됩니다.
기준: 변화의 속도가 빠르면 코드, 느리면 노코드.
2. 누가 이걸 유지보수할 것인가?
기술적으로 더 깨끗한 답이 항상 정답은 아닙니다. 누가 이 시스템을 관리할 것인가가 더 중요합니다.
클라이언트 회사에 개발자가 없다면, 아무리 코드로 짜는 게 우아해도 그 시스템은 인계 직후부터 죽기 시작합니다. 작은 수정 하나도 외주를 불러야 하면 클라이언트는 결국 시스템을 안 쓰게 됩니다.
이런 경우에는 의도적으로 n8n이나 Zapier를 선택합니다. '기술적으로 덜 좋지만, 클라이언트가 직접 손볼 수 있는 형태'가 장기적으로는 더 좋은 시스템입니다.
기준: 클라이언트에 개발 인력이 없으면 노코드 우선, 있으면 코드 우선.
3. LLM이 핵심에 들어가는가?
LLM이 단순히 '텍스트 한 번 생성'하는 정도라면 n8n의 OpenAI 노드로 충분합니다.
하지만 LLM이 도구를 사용해야 하는 에이전트, 여러 단계를 거치는 추론, 구조화된 출력 + 검증 + 재시도가 필요한 시스템이라면 노코드는 빠르게 한계에 부딪힙니다. 프롬프트 한 줄을 바꾸기 위해 노드 5개를 우회해야 하는 상황이 옵니다.
LLM이 시스템의 핵심이라면 코드로 가는 게 결국 빠릅니다. 처음 1~2주가 더 걸리지만, 그 다음 변경 한 번이 1시간이냐 1일이냐의 차이가 됩니다.
기준: LLM이 부수적이면 노코드, 핵심이면 코드.
4. 데이터가 민감한가?
보안과 컴플라이언스를 따지는 회사라면 — 의료, 금융, 공공기관 — n8n SaaS나 Zapier 같은 외부 호스팅 도구는 시작부터 탈락하는 경우가 많습니다. 데이터가 외부 서버를 거치는 것 자체가 안 됩니다.
이때 선택지는 두 가지입니다. n8n을 자체 서버에 셀프 호스팅하거나, 처음부터 직접 코드로 짜는 것. 셀프 호스팅도 결국 운영 인력이 필요하기 때문에, 운영 부담이 있다면 차라리 직접 코드로 짜고 클라이언트의 기존 인프라에 배포하는 게 깔끔합니다.
기준: 외부 호스팅 가능하면 노코드, 불가능하면 셀프 호스팅 또는 코드.
5. 14일 안에 끝낼 수 있는가?
Plan AI의 진입 상품은 14일 PoC입니다. 그래서 마지막 질문은 늘 이것입니다 — '이 결정이 14일 안에 끝나는가?'
코드로 짜면 더 우아하지만 14일이 빠듯한 PoC라면, 일부러 노코드로 빠르게 검증하고 본 프로젝트에서 코드로 다시 짜는 길을 선택합니다. PoC의 목적은 우아한 코드가 아니라 ROI를 증명하는 것입니다. 14일 안에 숫자를 못 보여주면 본 프로젝트는 없습니다.
반대로 본 프로젝트는 거의 항상 코드로 갑니다. 노코드로 시작했더라도 본 프로젝트에서는 코드로 다시 짭니다. 이건 노코드에 대한 비판이 아니라 각 도구가 잘하는 자리가 다르기 때문입니다.
기준: PoC는 노코드 우선, 본 프로젝트는 코드 우선.
정리
5가지 질문을 표로 정리하면 이렇습니다.
| 질문 | 노코드 쪽 | 코드 쪽 |
|---|---|---|
| 변화 속도 | 느리다 | 빠르다 |
| 유지보수 주체 | 비개발자 | 개발자 |
| LLM 비중 | 부수적 | 핵심 |
| 데이터 민감도 | 낮다 | 높다 |
| 14일 PoC 여부 | PoC | 본 프로젝트 |
5개 질문 중 3개 이상이 같은 쪽이면 그쪽으로 갑니다. 3:2로 갈리면 보통 유지보수 주체 항목이 결정타가 됩니다. 결국 시스템은 만든 사람이 아니라 쓸 사람의 것이기 때문입니다.
자동화 도구 선택에 정답은 없습니다. 하지만 명시적인 기준 없이 선택하면 거의 항상 후회합니다. 다음 자동화 프로젝트를 시작하기 전에 위 5개 질문을 한 번 적어보세요. 답이 안 나오는 항목이 있다면, 그 항목이 아직 결정 못 한 진짜 이유일 가능성이 높습니다.