첫 질문이 틀렸을 때
상담에서 가장 자주 받는 첫 질문이 이겁니다.
"저희 n8n 쓸까요, Dify 쓸까요?"
이 질문에 바로 답하면 대체로 후회합니다.
도구부터 고르면 반드시 후회한다
AX를 시작한다고 하면 첫 질문이 대개 이렇게 나옵니다. "우리 n8n 쓸까요, Dify 쓸까요?"
순서가 뒤집힌 질문입니다. 앞선 글에서 다룬 업무 지도를 그리기 전에 도구를 정하면, 도구가 할 수 있는 일에 맞춰 업무를 왜곡하게 됩니다. 채팅 인터페이스가 편한 도구를 골랐다는 이유로, 원래 배치로 돌아야 할 일을 사람이 매번 채팅으로 시키게 되는 식입니다.
그래도 언젠가는 골라야 합니다. 이 글은 그 시점에 무엇을 기준으로 볼지에 대한 것입니다.
세 도구가 각각 잘하는 것
2026년 현재 오픈소스 진영에서 실질적인 선택지는 셋으로 좁혀집니다. GitHub 스타 수는 인기의 지표일 뿐 품질의 지표는 아니지만, 생태계 크기와 문제 해결 자료의 양을 가늠하는 데는 쓸모가 있습니다.
표가 넓으면 좌우로 스크롤하여 확인하세요.
| 도구 | 규모 | 중심에 둔 문제 |
|---|---|---|
| n8n | 18만+ 스타, 7년차 | 워크플로 오케스트레이션 |
| Dify | 10만+ 스타 | LLM 애플리케이션 운영(LLMOps) |
| Flowise | 5만+ 스타 | LangChain 시각화, 멀티 에이전트 |
숫자보다 중요한 건 각자가 풀려고 만들어진 문제가 다르다는 점입니다.
n8n — 연결과 흐름 제어가 어려울 때
n8n은 오케스트레이션 도구입니다. 재시도, 분기, 스케줄, 실행 로그가 일급 시민입니다. AI는 그 흐름 안의 한 노드일 뿐입니다.
외부 시스템 연동이 많고, 정해진 시각에 돌아야 하고, 실패했을 때의 처리가 복잡한 업무라면 n8n이 맞습니다. 앞 글에서 다룬 핸드오프 설계 — 조건에 걸리면 사람에게 넘기고, 응답이 없으면 에스컬레이션하고, 결과를 다시 받아오는 — 를 그대로 그림으로 옮길 수 있는 도구가 이쪽입니다.
Dify — 지식 기반 응답이 중심일 때
Dify는 도구라기보다 제품에 가깝습니다. 프롬프트 관리, 데이터셋, 평가, 로그, 사용량 추적이 한 화면 안에 들어 있습니다.
사내 문서를 근거로 답하는 창구를 만드는 일이 핵심이라면 Dify가 빠릅니다. 관리 화면이 갖춰져 있어서 비개발 담당자가 프롬프트와 데이터셋을 직접 손볼 수 있다는 점이 실무에서 특히 큽니다. 앞 글에서 말한 "담당자가 스스로 고칠 수 있는가"라는 정착 조건을 도구 차원에서 충족시켜 줍니다.
Flowise — 에이전트 구조 자체를 다뤄야 할 때
Flowise는 LangChain을 시각적으로 감싸며 자리를 잡았고, 2.0부터 멀티 에이전트 오케스트레이션과 LangGraph 시각 편집기를 갖췄습니다.
여러 에이전트가 서로 넘겨가며 일하는 구조를 설계하고 실험해야 할 때 유용합니다. 다만 이 단계까지 필요한 조직은 생각보다 적습니다. 대부분의 첫 AX 과제는 에이전트 여러 개가 아니라 잘 정의된 흐름 하나로 해결됩니다.
무엇을 보고 고르나
도구 비교표를 아무리 봐도 결정이 안 되는 이유는, 비교표가 기능을 나열할 뿐 우리 조건을 묻지 않기 때문입니다. 실제로 결정을 가르는 건 이 네 가지입니다.
1. 이 업무의 어려운 부분이 무엇인가
연결과 순서가 어려우면 오케스트레이션 도구, 답변 품질이 어려우면 LLMOps 도구입니다. 이걸 거꾸로 고르면 쉬운 쪽은 편해지고 어려운 쪽은 그대로 남습니다.
2. 누가 유지보수하는가
개발자가 상주하지 않는다면, 코드로 내려가야만 고칠 수 있는 구조는 6개월 뒤 방치됩니다. 비개발 담당자가 조건 하나를 바꿀 수 있는지를 도입 전에 반드시 시험해 보세요.
3. 데이터가 어디까지 나가도 되는가
셋 다 자체 호스팅이 가능합니다. 그러나 가능하다는 것과 운영할 수 있다는 것은 다릅니다. 이 주제는 뒤에서 따로 다룹니다.
4. 실패했을 때 알 수 있는가
조용히 멈춘 자동화는 잘못된 결과보다 위험합니다. 실행 로그와 알림이 기본으로 갖춰져 있는지 확인하세요.
실무에서 가장 흔한 조합
셋 중 하나를 고르는 문제로 접근하지 않아도 됩니다. 실제로 자주 자리 잡는 형태는 역할 분담입니다.
- 바깥 흐름은 n8n — 트리거, 스케줄, 외부 시스템 연동, 재시도, 핸드오프
- 안쪽 판단은 Dify 또는 직접 호출 — 문서 기반 응답, 분류, 요약
이렇게 나누면 각 도구를 자기가 잘하는 자리에 두게 되고, 나중에 안쪽 모델이나 도구를 교체할 때 바깥 흐름을 건드리지 않아도 됩니다.
도구는 업무 지도가 그려진 다음에 고르는 것입니다.
순서가 바뀌면 도구가 잘하는 일을 찾게 되고, 조직에 중요한 일은 뒤로 밀립니다. 그리고 그렇게 만든 자동화는 대개 쓰이지 않습니다.
세 도구 중 무엇을 고르든, 그 선택보다 무엇을 자동화할지 정한 근거가 결과를 더 크게 갈랐습니다.
