“소스는 공개, 경쟁은 금지”
n8n은 워크플로 자동화 플랫폼입니다. 트리거 → 조건 분기 → API 호출 → 데이터 변환을 시각적으로 설계할 수 있습니다. Zapier나 Make(Integromat)와 비슷하지만, 결정적 차이가 있습니다: 소스 코드가 공개되어 있습니다.
하지만 n8n은 “오픈소스”라고 부르지 않습니다. 스스로를 Fair-code라고 부릅니다.
| 구분 | MIT / Apache | Fair-code (n8n) | Proprietary |
|---|---|---|---|
| 소스 코드 열람 | ✅ | ✅ | ❌ |
| 수정 및 자체 사용 | ✅ | ✅ | ❌ |
| 상업적 사용 (사내) | ✅ | ✅ | 라이선스 필요 |
| 재판매 / 호스팅 서비스 | ✅ | ❌ | ❌ |
| Fork하여 경쟁 제품 | ✅ | ❌ | ❌ |
| OSI 인증 오픈소스 | ✅ | ❌ | ❌ |
핵심은 **“사내에서 쓰는 건 무료, 가져다 팔면 안 됨”**입니다.
n8n은 왜 MIT를 선택하지 않았나
AWS 문제
MIT 라이선스의 가장 큰 리스크는 클라우드 공급자가 코드를 가져다 관리형 서비스로 판매하는 것입니다.
graph LR
A["오픈소스 회사가\n코드 개발"] --> B["MIT로 공개"]
B --> C["AWS/Azure/GCP가\nManaged Service로 출시"]
C --> D["원작자보다 큰 규모로\n같은 제품 판매"]
D --> E["원작자의 매출 감소"]
style C fill:#ffebee,stroke:#f44336
style D fill:#ffebee,stroke:#f44336
style E fill:#ffebee,stroke:#f44336이것은 이론이 아닙니다. 실제로 발생한 사례:
| 회사 | 제품 | AWS 대응 | 결과 |
|---|---|---|---|
| Elastic | Elasticsearch | Amazon OpenSearch Service | Elastic이 라이선스 변경 (Apache → SSPL) |
| MongoDB | MongoDB | Amazon DocumentDB | MongoDB가 라이선스 변경 (AGPL → SSPL) |
| Redis | Redis | Amazon ElastiCache | Redis가 라이선스 변경 (BSD → RSAL) |
AWS가 오픈소스를 포크하여 관리형 서비스를 만들면, 원작자는 자신의 코드로 만든 경쟁 서비스와 싸워야 합니다. AWS의 인프라, 영업력, 기존 고객 기반과 경쟁하는 것은 사실상 불가능합니다.
n8n은 이 문제를 처음부터 피했습니다. MIT가 아니라 Fair-code로 시작함으로써, “n8n을 가져다 Managed n8n을 파는” 시나리오를 라이선스 레벨에서 차단했습니다.
Sustainable Use License
n8n이 사용하는 라이선스는 Sustainable Use License입니다. 핵심 조항:
“You may use the software for your own internal business purposes. You may NOT provide the software to third parties as a hosted or managed service.”
번역하면: 자기 회사 안에서 쓰는 건 OK, 남에게 호스팅 서비스로 파는 건 NO.
이것은 사용자 대부분에게는 완전 무료입니다:
- 회사 내부 자동화 → ✅ 무료
- 개인 프로젝트 → ✅ 무료
- 커뮤니티 기여 → ✅ 가능
- n8n 기반 SaaS를 만들어 판매 → ❌ 별도 계약 필요
라이선스 변경 히스토리: Elastic, MongoDB, HashiCorp
n8n처럼 처음부터 Fair-code인 경우는 드뭅니다. 대부분은 MIT/Apache/AGPL로 시작한 뒤, AWS 문제를 겪고 나서 라이선스를 변경합니다. 이 변경 과정에서 커뮤니티와 심각한 갈등이 발생합니다.
Elastic → SSPL → 다시 AGPL
| 시점 | 라이선스 | 이유 |
|---|---|---|
| ~2018 | Apache 2.0 | 오픈소스 표준 |
| 2021.01 | SSPL + Elastic License | AWS OpenSearch 대응 |
| 2024.08 | AGPL 추가 선택지 | 커뮤니티 반발 완화 |
전개 과정:
- AWS가 Elasticsearch를 fork하여 Amazon OpenSearch Service를 출시
- Elastic이 Apache 2.0 → SSPL(Server Side Public License)로 변경
- SSPL: “이 소프트웨어를 서비스로 제공하려면, 전체 서비스 스택의 소스를 공개하라” — 사실상 클라우드 재판매 차단
- 커뮤니티 반발: “오픈소스가 아니게 됐다”
- AWS가 OpenSearch를 독립 프로젝트로 계속 유지
- 2024년 Elastic이 AGPL을 추가 선택지로 제공하여 타협
graph TB
A["Apache 2.0\n(완전 오픈)"] -->|"AWS 포크"| B["SSPL\n(서비스 제공 시 전체 공개)"]
B -->|"커뮤니티 반발"| C["AGPL 추가\n(타협)"]
D["커뮤니티 신뢰"] -->|"SSPL 전환으로"| E["신뢰 훼손"]
E -->|"AGPL 추가로"| F["부분 회복"]
style B fill:#ffebee,stroke:#f44336
style E fill:#ffebee,stroke:#f44336MongoDB → SSPL
| 시점 | 라이선스 | 이유 |
|---|---|---|
| ~2018 | AGPL v3 | 카피레프트 (서비스 제공 시 소스 공개) |
| 2018.10 | SSPL | AWS DocumentDB 대응 강화 |
MongoDB는 AGPL에서 한 단계 더 나가 SSPL을 만들었습니다. AGPL은 “이 소프트웨어를 수정하면 소스를 공개하라”였지만, SSPL은 “이 소프트웨어를 서비스로 제공하면, 서비스 스택 전체의 소스를 공개하라”입니다.
AWS는 MongoDB를 직접 사용하는 대신, API 호환 서비스인 DocumentDB를 자체 개발했습니다. 결과적으로 SSPL이 “포크 방어”는 했지만, “클론 방어”까지는 하지 못했습니다.
HashiCorp → BSL
| 시점 | 라이선스 | 이유 |
|---|---|---|
| ~2023 | MPL 2.0 | Mozilla Public License |
| 2023.08 | BSL 1.1 | 클라우드 재판매 방어 |
HashiCorp(Terraform, Vault, Consul)는 2023년 BSL(Business Source License)로 전환했습니다. BSL의 핵심:
- 소스 코드: 공개 (읽기, 수정 가능)
- 비상업적 사용: 무료
- 경쟁 서비스 제공: ❌ 금지
- 4년 후 자동 전환: BSL → Apache 2.0 (시간이 지나면 완전 오픈소스가 됨)
HashiCorp의 BSL 전환에 대한 커뮤니티 반응으로 OpenTofu(Terraform의 오픈소스 포크)가 탄생했습니다. Linux Foundation이 호스팅하며, MPL 2.0 라이선스를 유지합니다.
라이선스 스펙트럼 정리
graph LR
subgraph OPEN["오픈소스 (OSI 인증)"]
MIT["MIT\n(완전 자유)"]
APACHE["Apache 2.0\n(특허 보호)"]
AGPL["AGPL\n(서비스 수정 공개)"]
end
subgraph SOURCE["Source Available (소스 공개, OSI 미인증)"]
BSL["BSL\n(경쟁 서비스 금지,\n4년 후 오픈)"]
SSPL["SSPL\n(서비스 스택\n전체 공개 요구)"]
FAIR["Fair-code\n(재판매 금지)"]
ELASTIC["Elastic License\n(경쟁 서비스 금지)"]
end
subgraph CLOSED["Proprietary"]
PROP["소스 비공개\n(라이선스 구매)"]
end
MIT --> APACHE --> AGPL --> BSL --> SSPL --> PROP
style OPEN fill:#e8f5e9,stroke:#4caf50
style SOURCE fill:#fff3e0,stroke:#ff9800
style CLOSED fill:#ffebee,stroke:#f44336| 라이선스 | 사내 사용 | 수정 | 재판매/호스팅 | 포크 경쟁 | 대표 |
|---|---|---|---|---|---|
| MIT | ✅ | ✅ | ✅ | ✅ | LangChain, MMU |
| Apache 2.0 | ✅ | ✅ | ✅ | ✅ | HuggingFace, Qdrant |
| AGPL v3 | ✅ | ✅ (공개) | ✅ (공개) | ✅ (공개) | Grafana, Minio |
| BSL 1.1 | ✅ | ✅ | ❌ (4년 후 OK) | ❌ (4년 후 OK) | HashiCorp, MariaDB |
| SSPL | ✅ | ✅ | ❌ | ❌ | MongoDB, Elastic |
| Fair-code | ✅ | ✅ | ❌ | ❌ | n8n |
| Elastic License | ✅ | ✅ | ❌ | ❌ | Elastic (현재) |
Sentry(BSL 라이선스)와 PostHog(MIT + 유료 클라우드)도 유사한 패턴을 따르고 있어, Fair-code 개념이 단일 실험이 아닌 업계 트렌드임을 보여줍니다.
n8n의 사업 성과
Fair-code 전략이 실제로 작동하고 있는지 숫자로 확인합니다.
| 지표 | 수치 |
|---|---|
| ARR | $50M+ (2025 기준, 추정치 — 비상장사 공식 발표 없음) |
| GitHub Stars | 55K+ |
| 셀프호스트 인스턴스 | 수만 개 (Docker pulls 기반 추정) |
| Cloud 사용자 | 수천 조직 (추정) |
| 투자 | Series B, ~$30M+ |
| 팀 규모 | ~100명+ |
| 통합 (Integrations) | 400+ 서비스 |
가격 구조
| 플랜 | 월 비용 | 실행 수 | 특징 |
|---|---|---|---|
| Community (셀프호스트) | $0 | 무제한 | Fair-code 라이선스 |
| Starter | $20/월 | 2,500 | Cloud 호스팅 |
| Pro | $50/월 | 10,000 | 고급 기능 |
| Enterprise | 커스텀 | 무제한 | SSO, 감사 로그, SLA |
n8n의 $50M+ ARR(추정)은 Fair-code 모델의 검증입니다. MIT였다면 AWS가 “Amazon Workflow Automation (powered by n8n)“을 출시했을 가능성이 높습니다. Fair-code는 이 시나리오를 처음부터 막았습니다.
n8n 모델의 장단점
장점
- AWS 방어: 라이선스 레벨에서 재판매를 차단하므로, “나중에 라이선스 변경”하는 드라마가 불필요
- 셀프호스트 자유: 사내 사용은 완전 무료 → 채택 장벽 최소화
- 커뮤니티 유지: 소스가 공개되어 있으므로 기여, 버그 리포트, 플러그인 개발 가능
- 법적 명확성: 조건이 단순 — “자기가 쓰면 OK, 남에게 팔면 NO”
단점
- OSI 미인증: “오픈소스”라고 부를 수 없음 → 일부 개발자/조직의 거부감
- 커뮤니티 규모 제한: MIT 프로젝트보다 기여자가 적을 수 있음 (재판매 불가라 기업 기여 동기 감소)
- 포크 불가: 커뮤니티가 불만이 있어도 OpenTofu 같은 대안을 만들 수 없음
- 법적 회색 지대: “사내 사용”과 “서비스 제공”의 경계가 모호한 경우가 있음. n8n의 라이선스 FAQ에 따르면, 고객을 위해 설치해주고 관리비를 받는 것은 허용되지만, n8n 자체를 SaaS처럼 제3자에게 서비스로 판매하는 것은 금지됩니다
1인 빌더에게 시사하는 점
라이선스 선택은 사업 모델 선택이다
라이선스를 “법적 부속물”로 보면 안 됩니다. 라이선스가 사업 모델의 가능 범위를 결정합니다.
| 사업 모델 | MIT | Fair-code |
|---|---|---|
| CLI 무료 + 유료 콘텐츠 | ✅ | ✅ |
| OSS → 관리형 SaaS | ✅ (AWS 리스크) | ✅ (방어됨) |
| 커뮤니티 → 엔터프라이즈 | ✅ (기여 활발) | △ (기여 제한적) |
| 포크 방어 | ❌ | ✅ |
MMU가 MIT를 택한 이유 (재확인)
MMU는 MIT를 택했습니다. n8n의 Fair-code가 더 방어적인데도 MIT를 택한 이유:
- 규모: MMU는 CLI 체크리스트. AWS가 “Managed Checklist Service”를 만들 가능성은 0에 가까움
- 채택 우선: 1인 프로젝트의 첫 번째 과제는 “쓰는 사람을 만드는 것”. MIT가 채택 마찰을 최소화
- 수익원 분리: MMU의 수익은 코드(CLI)가 아니라 콘텐츠(Playbook Pack). 코드를 포크해도 콘텐츠는 포크할 수 없음
- 커뮤니티 기여: 534개 항목을 혼자 유지하기 어려움. MIT가 기여 동기를 극대화
Fair-code는 “내 코드가 내 경쟁자를 만들 수 있을 때” 합리적입니다. MMU는 코드가 아니라 콘텐츠로 수익을 만들기 때문에, 코드 포크는 위협이 아닙니다.
정리
| 핵심 | 내용 |
|---|---|
| Fair-code란 | 소스 공개 + 재판매 금지. OSI 미인증이므로 “오픈소스”는 아님 |
| n8n이 선택한 이유 | AWS 방어를 처음부터 해결하기 위해 |
| 라이선스 변경 드라마 | Elastic, MongoDB, HashiCorp 모두 사후 변경 → 커뮤니티 갈등 |
| 검증 | n8n $50M+ ARR(추정) — Fair-code도 대규모 사업 가능 |
| 1인 적용 | 코드 자체가 경쟁 위협이면 Fair-code, 콘텐츠가 수익원이면 MIT가 합리적 |
이 글로 OSS 사업화 분석 시리즈(G4a~G4d)를 마칩니다. 다음 글에서는 이 분석들을 바탕으로 라이선스 선택 실전 가이드 — MIT vs Apache vs Fair-code vs 추가조건, 규모별 판단 프레임 — 을 정리합니다.
Related Posts
오픈소스 라이선스 선택 가이드 — MIT vs Apache vs Fair-code vs 추가조건
MIT, Apache 2.0, BSL 등 오픈소스 라이선스별 특징을 비교하고, 프로젝트 규모와 수익 모델에 따른 선택 프레임워크 및 MMU의 MIT 채택 사례 분석
AI 검색 엔진 비교: ChatGPT Search, Perplexity, AI Overviews
ChatGPT Search, Perplexity, Google AI Overviews 3개 엔진의 정확도·속도·비용 비교. 쿼리 유형별 최적 엔진 추천 포함.
GEO의 정의와 SEO와의 구조적 차이
GEO(Generative Engine Optimization)의 정의와 기존 SEO와의 6가지 구조적 차이(노출 방식, 측정 지표, 콘텐츠 전략 등)를 상세 분석. AI 검색 엔진이 링크 클릭이 아닌 합성된 답변을 제공하는 환경에서 브랜드 가시성을 확보하기 위한 새로운 최적화 프레임워크 제안.