AI 워크플로 빌더 5종, 하나는 지난달 닫혔습니다

글쓴이김성진·발행일2026년 9월 10일

코드를 많이 안 쓰고 AI 기능을 붙이고 싶을 때 고르는 도구가 있습니다.

화면에서 블록을 끌어다 선으로 잇고, 그 사이에 “이 문서를 읽어라”, “이 모델한테 물어봐라”, “결과를 슬랙에 보내라”를 넣는 방식입니다. AI 워크플로 빌더라고 부릅니다. Dify, n8n, Langflow, Flowise, Coze 스튜디오가 대표적입니다.

그런데 이 다섯 중 하나는 지난달에 문을 닫았습니다. 깃허브 별이 5만 5천 개 넘게 달린 도구인데도 그랬습니다.

이 글은 두 사람을 위한 것입니다. 하나는 지금 이 중 하나를 고르려고 탭을 여러 개 열어 둔 사람. 다른 하나는 이미 하나를 골라 회사 서버에 올려 뒀는데, 그걸로 고객에게 서비스를 팔아도 되는지 확인해 본 적 없는 사람입니다.

앞쪽에 “지금 살아 있나”와 “내 사업에 써도 되나”를 두고, 뒤쪽에 요금표를 뒀습니다. 요금보다 라이선스가 먼저인 이유는 본문에서 보실 겁니다. 수치와 조항은 전부 각 프로젝트의 공식 문서·라이선스 원문·깃허브 API에서 2026년 9월 10일에 직접 읽은 것만 적습니다.

별 5만 5천 개짜리가 지난달 문을 닫았습니다

Flowise부터 봐야 합니다. 나머지를 비교하는 기준이 여기서 나오기 때문입니다.

flowiseai.com에 접속하면 페이지 맨 위에 이 문장이 걸려 있습니다.

“We’re sunsetting Flowise.”

공지에 적힌 일정은 세 개입니다.

깃허브 API로 직접 확인한 현재 상태도 같습니다. archived: true, 마지막 코드 반영(push)은 **2026년 8월 13일 12시 38분(UTC)**입니다. 별은 55,448개, 포크는 24,989개입니다.

아카이브가 무슨 뜻인지 반 문장으로 풀면 이렇습니다. 저장소가 읽기 전용으로 잠깁니다. 새 이슈도, 새 풀 리퀘스트도 받지 않습니다. 코드는 그대로 볼 수 있고 내려받을 수 있지만, 누가 고쳐 주지는 않습니다.

접는 쪽이 밝힌 이유가 카테고리 전체를 겨눕니다

여기서 중요한 건 날짜가 아니라 이유입니다. 공지 원문입니다.

개발자들이 클로드 코드(Claude Code)나 OpenClaw 같은 새 코딩 에이전트에 점점 더 의존하고 있다. “rigid workflow low code approach quickly hits the limit when it comes to complexity” (경직된 워크플로 로우코드 방식은 복잡도 앞에서 금방 한계에 부딪힌다)

이건 “우리 회사가 어려워서 접는다”가 아닙니다. 이 방식 자체가 한계에 부딪혔다는 자기 진단입니다. 그리고 그 진단을 내린 쪽이 이 카테고리에서 별을 다섯 번째로 많이 받은 프로젝트입니다.

그래서 이 글의 비교 축이 “어느 게 더 예쁜가”가 될 수 없습니다. **“어느 게 3년 뒤에도 있을 것 같은가”**가 먼저입니다.

다만 공지가 남긴 문장 하나는 짚고 갑니다.

“Flowise source code will still remain on Github and the Apache 2.0 licensed code is yours to keep building on.” (소스는 깃허브에 남고, Apache 2.0으로 공개된 코드는 계속 쌓아 올려도 되는 여러분 것이다)

팀은 포크해서 각자 유지보수하거나 커뮤니티 주도 대안을 만들라고 권했습니다. 코드는 죽지 않았고, 유지보수 담당자가 사라진 것입니다. 이 구분이 뒤에서 다시 나옵니다.

남은 넷은 지금 살아 있나 — 깃허브에서 직접 확인한 것

“활발한가”를 감으로 말하지 않으려고 깃허브 API로 같은 항목을 네 곳에서 뽑았습니다. 2026년 9월 10일 기준입니다.

읽는 법을 두 가지만 붙이겠습니다.

하나, 위 셋은 어제도 코드가 들어갔습니다. n8n·Dify·Langflow 셋 다 마지막 반영이 2026년 9월 9일입니다. 이건 “관리되고 있다”의 가장 값싼 증거입니다.

둘, Coze 스튜디오는 아카이브는 아니지만 6주째 조용합니다. 마지막 반영이 7월 29일입니다. 아카이브된 것과는 다릅니다 — 이슈도 받고 PR도 받습니다. 하지만 다섯 중 커뮤니티가 가장 작고(별 21,569개), 반영 간격이 가장 깁니다. 이 두 사실을 같이 놓고 판단하시면 됩니다.

포크 수도 재미있습니다. Flowise는 별 대비 포크 비율이 가장 높습니다(55,448 대 24,989). 아카이브 공지가 포크를 권했다는 사실과 겹쳐 읽으면 자연스럽습니다.

“오픈소스”라고 적혀 있어도 뜻이 다섯 가지입니다

여기가 이 글에서 가장 실용적인 부분입니다.

다섯 개 모두 소스가 공개돼 있고 자체 서버에 올릴 수 있습니다. 그래서 대부분 “오픈소스니까 공짜로 마음대로 쓰면 되겠지”로 넘어갑니다. 그런데 라이선스 원문을 열면 다섯이 서로 다릅니다. 깃허브가 표준 라이선스로 인식한 것은 다섯 중 둘뿐입니다.

NOASSERTION은 “라이선스 파일은 있는데 표준 형태가 아니라 자동 판별이 안 된다”는 표시입니다. 즉 사람이 읽어야 하는 라이선스라는 뜻이고, 대개 조건이 붙어 있다는 신호입니다. 아래에서 하나씩 원문을 읽겠습니다.

n8n — 내부 업무용이면 되고, 팔면 안 됩니다

n8n의 라이선스 이름은 Sustainable Use License 1.0입니다. 만든 쪽은 이걸 “fair-code”라고 부릅니다. 저장소 설명에도 그렇게 적혀 있습니다.

제한 조항 원문입니다.

“You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.” (자기 회사의 내부 업무 목적 또는 비상업·개인 용도로만 사용하거나 수정할 수 있다. 소프트웨어를 배포하거나 남에게 제공하려면 비상업 목적으로 무상이어야 한다.)

이 두 문장을 실무 언어로 번역하면 이렇습니다.

• 우리 회사 업무 자동화에 쓴다 → 됩니다. 사원 수 제한도 없습니다.
• 우리 회사 서버에 올려 놓고 고객사에게 계정을 판다 → 안 됩니다.
• 우리 제품 안에 넣어서 기능으로 판매한다 → 안 됩니다.
• 친구에게 무료로 세팅해 준다 → 비상업이면 됩니다.

조항이 하나 더 있습니다. 파일명에 .ee.가 들어가거나 디렉터리명이 .ee인 소스는 Sustainable Use License 대상이 아닙니다. 그 파일들을 쓰려면 별도의 n8n 엔터프라이즈 라이선스가 필요합니다. 그리고 master가 아닌 브랜치의 내용물은 아예 라이선스가 없습니다.

n8n은 별 203,850개로 다섯 중 가장 큽니다. 통합 연동이 400개가 넘는다고 저장소 설명에 적혀 있습니다. 그런데 그 규모를 보고 “제일 안전한 선택”이라고 판단하면 팔 때 걸립니다. 규모와 라이선스는 별개 축입니다.

Dify — 워크스페이스를 여러 개 열면 상용 계약이 필요합니다

Dify는 “수정된 Apache License 2.0”이라고 라이선스 파일 첫 줄에 스스로 밝힙니다. 추가 조건이 둘입니다.

① 멀티테넌트 서비스 금지. 원문입니다.

“Multi-tenant service: Unless explicitly authorized by Dify in writing, you may not use the Dify source code to operate a multi-tenant environment.” (Dify가 서면으로 명시 승인하지 않는 한, Dify 소스코드로 멀티테넌트 환경을 운영할 수 없다.)

친절하게도 테넌트가 뭔지 라이선스 안에서 정의해 줍니다. **“Dify 맥락에서 테넌트 하나는 워크스페이스 하나에 대응한다”**입니다. 워크스페이스는 테넌트마다 데이터와 설정을 분리해 주는 영역입니다.

즉 고객사마다 워크스페이스를 하나씩 열어 주는 형태의 서비스는 상용 라이선스를 사야 합니다. 이게 SaaS를 만들려는 팀에게는 결정적인 조항입니다.

② 로고·저작권 표기 제거 금지. 원문입니다.

“you may not remove or modify the LOGO or copyright information in the Dify console or applications.”

여기도 범위를 정의해 줍니다. 여기서 말하는 프론트엔드는 소스로 돌릴 때의 web/ 디렉터리 전체, 도커로 돌릴 때의 web 이미지입니다. 그리고 이 제한은 프론트엔드를 쓰지 않는 사용에는 적용되지 않습니다. API만 백엔드로 갖다 쓰는 형태라면 로고 조항은 걸리지 않는다는 뜻입니다.

반대로 말하면 이렇습니다. Dify 화면을 그대로 우리 서비스인 척 흰 라벨로 파는 것은 두 조항 모두에 걸립니다.

Langflow — 라이선스는 가장 자유롭고, 매니지드는 사라졌습니다

Langflow는 MIT입니다. 다섯 중 조건이 가장 적습니다. 저작권 표시만 남기면 상업적으로 팔아도, 고쳐도, 우리 제품에 넣어도 됩니다. 별 154,505개에 어제도 코드가 들어갔습니다.

여기까지만 보면 가장 무난한 선택입니다. 그런데 운영 쪽에 사건이 하나 있었습니다.

DataStax가 운영하던 매니지드 Langflow(Astra 안의 DataStax Langflow)가 2026년 4월 9일 제거됐습니다. 공식 문서에 남은 안내 원문입니다.

“Removed DataStax Langflow from Astra. As an alternative, you can use Langflow OSS.” (Astra에서 DataStax Langflow를 제거했다. 대안으로 Langflow OSS를 사용할 수 있다.)

질문이 있으면 IBM 지원으로 문의하라고 적혀 있습니다. DataStax는 IBM에 인수됐고, 관리형 경로를 정리하면서 사용자를 오픈소스 자체 호스팅으로 돌려보낸 것입니다.

이게 실무에서 뜻하는 바는 분명합니다. Langflow를 고르면 서버 운영은 우리 몫입니다. 라이선스가 자유로운 것과 누가 서버를 봐 주느냐는 다른 문제입니다. 이 지점은 로컬 LLM 실행 도구를 비교했을 때와 성격이 같습니다 — 공짜인 도구일수록 운영 인건비가 진짜 값입니다.

Coze 스튜디오 — 조건이 가장 단순하고, 커뮤니티가 가장 작습니다

Coze 스튜디오는 Apache-2.0입니다. 깃허브가 표준 라이선스로 바로 인식한 두 개 중 하나입니다. 추가 조항 없이 상업 사용이 됩니다.

문제는 규모입니다. 별 21,569개, 포크 3,115개로 다섯 중 가장 작습니다. n8n의 10분의 1 수준입니다. 그리고 마지막 코드 반영이 2026년 7월 29일로, 이 글을 쓰는 시점에 6주가 넘었습니다.

여기서 판단이 갈립니다.

• 아카이브된 것과는 다릅니다. 이슈도 PR도 열려 있습니다. 6주 공백은 릴리스 주기가 긴 프로젝트에서 흔한 일이기도 합니다.
• 그렇지만 문제가 생겼을 때 검색해서 나오는 한국어 사례의 양은 별·포크 수에 비례합니다. 막혔을 때 혼자 풀 자신이 없다면 이 숫자를 무시하기 어렵습니다.

Flowise — 코드는 남지만 유지보수는 내 몫입니다

Flowise의 라이선스 구조도 정리해 둡니다. 포크해서 쓰려는 분에게는 이게 실질적인 정보입니다.

• packages/server/src/enterprise 디렉터리 아래 내용과 IdentityManager.ts처럼 명시적 저작권 표기가 붙은 파일은 상용 라이선스 대상입니다.
• 그 밖의 내용은 Apache 2.0입니다.

그러니까 “Flowise는 Apache 2.0”이라는 한 줄 요약은 절반만 맞습니다. 엔터프라이즈 디렉터리를 그대로 들고 가면 상용 조항에 걸립니다.

그리고 아카이브 뒤에 남는 현실적인 부담이 셋입니다.

1. 보안 패치가 안 옵니다. 의존성에 취약점이 뜨면 직접 올려야 합니다.
2. 새 모델·새 API가 안 붙습니다. 노드가 추가되지 않으니 새로 나온 모델은 직접 붙여야 합니다.
3. npm 패키지에 deprecated 표시가 붙어 있습니다. 설치할 때마다 경고가 뜨고, 사내 보안 정책이 그런 패키지를 막는 곳도 있습니다.

결론은 하나입니다. 신규 프로젝트에 Flowise를 고르지 마세요. 이미 운영 중이라면 당장 꺼야 하는 건 아니지만, 마이그레이션 계획을 세울 시점입니다.

클라우드로 갈 때 붙는 값 — 세 곳의 요금표

자체 호스팅이 부담스러워 관리형 클라우드를 쓸 경우의 값입니다. 각 공식 요금 페이지에서 2026년 9월 10일에 읽었습니다.

Dify 클라우드

무료 구간에는 트리거 이벤트 3,000회, 로그 보관 30일, API 호출 월 5,000회 한도가 붙습니다. Professional부터 로그가 무제한이고 API 요청 한도가 사라집니다. 트리거 이벤트는 Professional 월 2만 회, Team은 무제한입니다.

n8n 클라우드 (연간 결제 기준)

월 결제로 바꾸면 Starter가 약 €24, Pro가 약 €60입니다. 무료 체험은 실행 1,000회, 동시 5개, 실행 타임아웃 180초, 팀 프로젝트 1개입니다.

Flowise 클라우드 (닫히는 중이지만 기록으로 남깁니다)

Free $0(플로우 2개·월 예측 100회·5MB) / Starter $35(플로우 무제한·월 1만 회·1GB) / Pro $65(월 5만 회·10GB·워크스페이스 무제한, 5인 초과 시 인당 $15). 서니셋 공지에 기존 클라우드 고객의 데이터와 계정을 어떻게 처리하는지는 적혀 있지 않습니다.

Langflow와 Coze 스튜디오의 관리형 요금은 이 글을 쓰는 시점에 공개 요금 페이지에서 확인하지 못했습니다. 확인 못 한 숫자는 적지 않겠습니다.

n8n의 ‘실행 1회’가 정확히 무엇인가

n8n 요금표를 볼 때 가장 많이 착각하는 지점이라 따로 뺐습니다. 공식 설명 원문입니다.

“a single run of your entire workflow. It doesn’t matter how many steps are in the workflow or how much data it processes. It’s still a single execution.” (워크플로 전체의 한 번 실행. 단계가 몇 개든, 데이터를 얼마나 처리하든 상관없다. 그래도 실행 1회다.)

이게 왜 중요하냐면, 경쟁 도구들이 단계(스텝) 단위로 세는 경우가 많기 때문입니다. 20단계짜리 워크플로를 하루 100번 돌린다고 해 봅시다.

• 스텝 과금이면 하루 2,000단계, 한 달 6만 단계입니다.
• n8n 기준이면 하루 100회, 한 달 3,000회입니다. Starter(월 2,500회)로는 살짝 모자라고 Pro(월 1만 회)면 남습니다.

같은 작업량인데 세는 단위가 달라 20배 차이가 납니다. 워크플로를 잘게 쪼개지 않고 하나로 크게 묶는 게 n8n에서는 유리하다는 뜻이기도 합니다.

Dify의 ‘메시지 크레딧’과 지식 문서 칸

Dify 쪽도 단위를 짚어야 합니다.

메시지 크레딧은 대화 한 번 주고받는 단위로 소모됩니다. Sandbox의 200은 월 한도가 아니라 총량입니다. 즉 무료 구간은 체험용이지 운영용이 아닙니다. 200번 대화하면 끝입니다.

지식 문서 수가 조용히 걸리는 칸입니다. Sandbox 50개, Professional 500개, Team 1,000개입니다. 사내 문서를 넣어 질문에 답하게 만드는 용도(RAG)라면 이 숫자가 먼저 찹니다. 사규·매뉴얼·회의록을 넣기 시작하면 500개는 금방입니다.

저장 용량은 그다음입니다. Professional 5GB, Team 20GB인데, 텍스트 문서 위주면 용량보다 문서 개수 제한에 먼저 부딪힙니다. PDF에 이미지가 많다면 반대가 됩니다.

문서를 어떻게 쪼개 넣느냐에 따라 같은 자료가 문서 30개도 되고 300개도 됩니다. 그 설계는 임베딩 API를 비교했을 때 정리한 청크 전략과 같은 계산입니다.

다섯 곳이 자기를 뭐라고 소개하는지 읽으면 성격이 갈립니다

같은 카테고리로 묶이지만 지향점이 다릅니다. 그게 가장 짧게 드러나는 곳이 깃허브 저장소 한 줄 설명입니다. 원문 그대로 옮기고 뜻을 붙이겠습니다.

n8n

“Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations.”

첫 단어가 **“Fair-code”**입니다. 오픈소스라고 안 씁니다. 정직한 표기입니다. 그리고 자기 정체성을 “AI 도구”가 아니라 **“워크플로 자동화 플랫폼(AI 기능 내장)“**으로 잡습니다. 뿌리가 업무 자동화 쪽이고 AI가 나중에 붙었다는 뜻이며, 연동 400개 이상이라는 숫자가 그 뿌리에서 나옵니다. 슬랙·노션·구글시트를 잇는 일이 절반 이상이라면 이쪽이 맞습니다.

Dify

“Build Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.”

키워드가 RAG 파이프라인과 협업 워크스페이스입니다. RAG는 내 문서를 검색해 그 내용으로 답하게 만드는 방식입니다. 앞서 요금표에서 ‘지식 문서 수’가 등급마다 따로 적혀 있던 이유가 여기 있습니다. 문서 기반 사내 챗봇이 목적이면 이쪽이 정면으로 겨냥한 용도입니다. 그리고 “cloud, VPC, or self-hosted”를 나란히 적은 것은 기업 보안 요구를 의식한 문구입니다.

Langflow

“Langflow is a powerful tool for building and deploying AI-powered agents and workflows.”

가장 담백하고, 그래서 가장 넓습니다. 공식 사이트는 여기에 MCP 서버를 만드는 도구라는 설명을 더합니다. MCP(Model Context Protocol)는 AI 도구가 외부 기능과 자료에 붙는 표준 통로입니다. 즉 Langflow는 “완성품 앱”보다 다른 AI가 가져다 쓸 부품을 만드는 쪽에 무게가 있습니다. MIT 라이선스와 이 지향이 잘 맞습니다 — 부품은 자유롭게 쓸 수 있어야 부품입니다.

Coze 스튜디오

“An AI agent development platform with all-in-one visual tools, simplifying agent creation, debugging, and deployment like never before.”

**“디버깅”**이 한 줄 설명에 들어간 유일한 곳입니다. 만드는 것뿐 아니라 왜 이상하게 답하는지 들여다보는 화면에 힘을 줬다는 뜻입니다. 실제로 에이전트를 붙여 보면 시간을 가장 많이 잡아먹는 게 이 부분입니다.

Flowise

“Build AI Agents, Visually”

네 단어입니다. 가장 단순했고, 결국 그 단순함의 한계를 스스로 사유로 적고 닫았습니다.

요금을 내 단위로 바꿔 보면

요금표 숫자는 월 단위라 감이 잘 안 옵니다. 하루로 나눠 보겠습니다.

n8n 실행 횟수

5분마다 도는 워크플로 하나는 하루 288회, 한 달이면 약 8,640회입니다. 그 하나만으로 Starter(2,500)를 세 배 넘게 넘기고 Pro(10,000)에 거의 찹니다. “워크플로 몇 개냐”가 아니라 “얼마나 자주 도느냐”가 요금제를 정한다는 뜻입니다.

여기서 앞의 실행 정의가 다시 유효합니다. 단계가 몇 개든 1회로 세니, 자주 도는 워크플로는 쪼개지 말고 하나로 묶는 게 유리합니다.

Dify 메시지 크레딧

Professional은 연 $590이니 월로 치면 약 $49입니다. 하루 166번 대화면 사내 인원 20명이 하루 8번씩 물어보는 규모입니다. 부서 하나 정도가 쓰기에 맞고, 전사로 열면 금방 찹니다.

Team은 월로 치면 약 $132에 하루 333회입니다. 크레딧은 2배인데 값은 2.7배라는 점은 짚어 둘 만합니다. Team 등급의 값은 크레딧이 아니라 팀원 50명·앱 200개·지식 문서 1,000개 쪽에 붙어 있습니다. 인원이 늘어 올리는 등급이지 사용량이 늘어 올리는 등급이 아닙니다.

자체 호스팅과 비교하면

n8n Pro가 연간 결제로 €50/월, Dify Professional이 약 $49/월입니다. 자체 호스팅은 이 값이 0이 되고 대신 서버 값과 사람 시간이 듭니다. 작은 인스턴스 하나가 월 $10~20 선이니 금액만 보면 자체 호스팅이 싸 보입니다. 그런데 업그레이드·백업·장애 대응이 담당자 일이 됩니다.

기준을 하나 드리면 이렇습니다. 월 한 시간 이상 이 서버를 들여다볼 사람이 정해져 있지 않다면, 그냥 클라우드를 쓰는 편이 쌉니다. 담당자가 없는 자체 호스팅은 결국 몇 달 뒤 아무도 못 건드리는 낡은 컨테이너가 됩니다.

워크플로 빌더를 고르기 전에 5분이면 끝나는 확인 절차

이 글에서 쓴 확인 방법은 전부 5분 안에 직접 해 볼 수 있습니다. 어떤 도구를 고르든 같은 순서로 보시면 됩니다.

① 살아 있는지 본다. 저장소 주소 뒤에 아무것도 붙이지 말고 그냥 열어 보세요. 아카이브면 상단에 “This repository has been archived” 배너가 뜹니다. 마지막 커밋 날짜도 첫 화면에 있습니다. 한 달 넘게 조용하면 이유를 찾아보는 게 맞습니다.

② 라이선스 파일을 직접 연다. 저장소 오른쪽에 표시된 라이선스 이름만 보지 마세요. 이번 다섯 곳 중 셋이 NOASSERTION이었고, 그 셋 모두 조건이 붙어 있었습니다. LICENSE 파일을 열어 “Limitations”, “additional conditions”, “commercial” 세 단어를 찾아보면 대개 10초 안에 나옵니다.

③ 두 단어를 검색한다. 라이선스 본문에서 multi-tenant와 internal business를 찾아보세요. 이 둘이 있으면 팔 때 걸리는 라이선스입니다. Dify에는 앞의 것이, n8n에는 뒤의 것이 있었습니다.

④ 요금 페이지에서 단위를 확인한다. 값보다 단위가 먼저입니다. “실행”인지 “단계”인지, “월 한도”인지 “총량”인지. Dify Sandbox의 200크레딧이 총량이라는 사실은 요금표 숫자만 봐서는 안 보입니다.

⑤ 회사 이름으로 최근 3개월 뉴스를 본다. Flowise 서니셋도, DataStax Langflow 제거도 요금표에는 적혀 있지 않았습니다. 공지 페이지와 문서 변경 이력에만 있었습니다.

워크플로 빌더는 한 번 올려 두면 사내 자동화가 그 위에 쌓이는 도구라, 이 다섯 단계를 안 거치고 고르면 몇 달 뒤 **“이미 만들어 놨는데 팔 수가 없다”**나 “이미 올려놨는데 고칠 사람이 없다” 중 하나를 만나게 됩니다. 둘 다 되돌리는 값이 처음 고르는 값보다 훨씬 큽니다.

세 가지 상황별로 답이 다릅니다

여기까지 읽고 “그래서 뭘 골라야 하나”가 남으셨을 겁니다. 상황별로 갈립니다.

① 우리 회사 내부 업무 자동화만 할 것이다

→ n8n. 라이선스 제한이 “내부 업무 목적”을 정확히 허용하고, 연동이 400개가 넘고, 커뮤니티가 압도적으로 큽니다. 막히면 검색해서 나옵니다. 자체 호스팅이면 실행 횟수 제한도 없습니다.

② 우리 제품에 넣어 고객에게 팔 것이다

→ Langflow(MIT) 또는 Coze 스튜디오(Apache 2.0). 이 둘만 조건 없이 상업 제공이 됩니다. n8n은 라이선스가 막고, Dify는 워크스페이스를 고객별로 여는 순간 상용 계약이 필요합니다.

둘 중에서는 Langflow를 먼저 보시는 게 맞습니다. 별이 7배 많고 어제도 코드가 들어갔습니다. 단, 관리형 경로가 없어 서버 운영을 직접 해야 합니다.

③ 사내 문서로 답하는 AI를 빨리 세우고 싶다

→ Dify 클라우드. 지식 문서 관리와 앱 배포가 한 화면에 붙어 있어 가장 빨리 뜹니다. 팔 게 아니라 사내에서 쓸 거라면 라이선스 조항 둘 다 걸리지 않습니다. 다만 무료 200크레딧은 총량이라 바로 Professional(연 $590)을 봐야 합니다.

에이전트를 코드로 직접 짜는 쪽과 저울질 중이라면 에이전트 프레임워크 비교 쪽도 같이 보시는 게 좋습니다. Flowise가 접으며 남긴 진단이 바로 그 갈림길이었습니다.

결론 — 팔 거면 둘, 내부용이면 넷

한 줄로 줄이면 이렇습니다.

“오픈소스”는 라이선스 이름이 아니라 마케팅 문구입니다. 다섯 개 전부 소스가 공개돼 있지만, 그중 조건 없이 상업 제공이 되는 건 Langflow와 Coze 스튜디오 둘뿐입니다. 가장 크고 가장 유명한 n8n이 오히려 가장 강하게 막습니다.

그리고 Flowise가 남긴 문장을 한 번 더 놓겠습니다. 경직된 로우코드 방식이 복잡도 앞에서 금방 한계에 부딪힌다는 자기 진단이었습니다. 이 카테고리를 고를 때는 “우리 워크플로가 얼마나 복잡해질 것인가”를 먼저 재야 한다는 뜻으로 읽는 게 맞습니다. 단순한 자동화라면 이 도구들이 지금도 가장 빠른 길이고, 분기와 예외가 계속 늘어나는 일이라면 결국 코드로 옮겨 가게 됩니다.

확인된 것과 확인되지 않은 것

공식 문서·라이선스 원문·깃허브 API로 확인한 것

• Flowise 서니셋 일정 3건(2026년 7월 29일 개발 중단 · 8월 10일 아카이브 · 8월 31일 코어 팀 상주 종료)과 사유 원문
• 깃허브 API 실측 별·포크·마지막 반영일·아카이브 여부 5건 (2026년 9월 10일 조회)
• n8n Sustainable Use License 1.0 제한 조항 원문, .ee 예외, master 외 브랜치 미라이선스
• Dify 수정 Apache 2.0의 멀티테넌트 조항과 로고 조항 원문, 테넌트·프론트엔드 정의
• Langflow MIT, DataStax Langflow의 2026년 4월 9일 Astra 제거 공지 원문
• Coze 스튜디오 Apache-2.0
• Dify·n8n·Flowise 공식 클라우드 요금표

확인되지 않은 것

• Langflow·Coze 스튜디오의 관리형 클라우드 요금. 공개 요금 페이지를 확인하지 못했습니다.
• Flowise 기존 클라우드 고객의 데이터·계정 처리 방침. 서니셋 공지에 언급이 없습니다.
• Coze 스튜디오의 6주 공백이 정상 주기인지 여부. 릴리스 정책이 공개돼 있지 않아 숫자만 적었습니다.
• 각 도구의 성능·처리량 비교. 이 글은 라이선스와 요금 축입니다. 같은 워크플로를 다섯 곳에서 돌려 측정한 값은 여기 없습니다.