지난 10년의 대부분 동안, 오픈 소스 기업들은 두 가지 방식으로 수익을 창출했습니다.

첫 번째는 셀프 호스팅(self-hosting)을 하는 기업에 판매하는 것이었습니다. 프로젝트 자체는 오픈되어 있지만, SSO, RBAC, 감사 로그(audit logs), 세밀한 정책(fine-grained policy), 때로는 고가용성(HA)과 같은 운영 및 컴플라이언스(compliance) 기능은 상용 라이선스 뒤에 숨겨져 있습니다. 두 번째는 소프트웨어는 원하지만 운영 부담은 원하지 않는 팀들을 위한 매니지드 서비스(managed service)였습니다.

저는 두 번째 기둥이 오픈 소스가 되어야 할 강력한 이유가 결코 아니었으며, 첫 번째 기둥이 이제 우리 대부분이 계획하지 않았던 방향으로부터 압박을 받고 있다고 주장하고 싶습니다.

매니지드 서비스 정당화는 언제나 빈약했다

제품이 좋고 합리적인 무료 티어(free tier)를 제공한다면, 라이선스와 상관없이 "직접 운영하고 싶지 않다"는 고객은 나타나기 마련입니다. 아무도 소스 코드가 GitHub에 있다는 이유만으로 호스팅된 데이터베이스를 선택하지 않습니다. 그들은 그것이 잘 작동하고 가격이 예측 가능하기 때문에 선택합니다.

실제로 오픈 소스를 필요로 했던 고객은 대규모 기업(large enterprise)이었습니다. 그들은 소스 코드에 대한 접근 권한과 셀프 호스팅 경로 없이는 조달(procurement) 논의를 시작하지 않았습니다. 엑시트 리스크(Exit risk), 감사 요구 사항, 에어갭(air-gapped) 환경, 그리고 코드를 읽는 보안 팀 때문이었습니다. 그것이 오픈 소스가 열어준 구매자였으며, 그 구매자는 해당 엔터프라이즈 티어를 직접 작성하고 소유하는 것이 비용이 많이 들기 때문에 보통 엔터프라이즈 티어에 기꺼이 비용을 지불했습니다.

마지막 구절이 바로 변화한 부분입니다.

AI가 실제로 변화시키는 것

우리가 제한(gated)했던 기능들은 SSO, RBAC (역할 기반 액세스 제어), 감사 로깅 (audit logging), 커스텀 보존 정책 (custom retention policies)처럼 결코 어려운 것들이 아니었습니다. 이는 참고 구현체 (reference implementations)가 풍부하여 이미 잘 알려진 작업들이지만, 여전히 엔지니어 팀이 직접 수작업으로 구축해야 했습니다. 이는 종종 몇 달간의 계획, 반복 작업, 그리고 오픈 코어 (open core)의 변화를 끊임없이 따라가는 과정을 의미했습니다.

현재의 코드 생성 (code generation) 기술을 활용하면, 역량 있는 플랫폼 팀은 허용적 라이선스 (permissively licensed)가 적용된 코어를 가져와 자신들의 ID 제공자 (identity provider), 자신들의 정책 모델 (policy model), 자신들의 컴플라이언스 보고 (compliance reporting) 방식에 맞춰 해당 기능들을 직접 구축할 수 있습니다. 주변 코드의 대부분이 오픈 소스이기 때문에, 모델이 인터페이스를 추측하는 것이 아니라 실제 인터페이스를 바탕으로 작업하므로 생성된 결과물은 준수한 수준이 되는 경향이 있습니다. 배포와 모니터링은 어차피 자체 호스팅 (self-hosting)을 하고 있었기에 이미 수행하던 작업이었습니다. 저는 navflow.ai를 구축하면서 이 중 모니터링 측면이 실시간으로 개선되는 것을 지켜보고 있습니다. 아직 완성되지는 않았지만, 그 방향성은 명확합니다.

따라서 기능의 번들 (bundle)로서의 엔터프라이즈 티어 (enterprise tier)는 과거보다 더 약해진 울타리가 되었습니다.

누군가는 여전히 이를 책임져야 한다

AI가 아직 건드리지 못한 단 한 가지는 결과에 대해 누가 책임을 지느냐 하는 것입니다.

코드를 작성하는 비용은 저렴해졌습니다. 하지만 그것을 소유(owning)하는 비용은 그렇지 않습니다. 내부 인증 레이어 (internal auth layer)를 생성하는 사람이 누구든, 그 결과에 대해 여전히 승인해야 하고, 모든 업스트림 (upstream) 업그레이드 과정에서 이를 유지해야 하며, 좋지 않은 시간에 장애가 발생했을 때 호출(paged)을 받아야 하고, 감사관 (auditor) 앞에서 이를 설명해야 합니다. AI는 온콜 로타 (on-call rota, 당직 명단)에 없으며, (아직까지는) 컴플라이언스 보고서에도 포함되지 않습니다. 소프트웨어가 수행하는 역할에 대해 인간이 책임을 지는 한, 내부 포크 (internal fork)는 일시적인 작업이 아닌 영구적인 약속이며, 지원되는 버전을 구매하여 그 책임을 타인에게 넘기는 것은 여전히 합리적인 방식입니다.

그렇다고 해서 침식 현상이 사라지는 것은 아닙니다. 다만 속도가 느려질 뿐이며, 이는 살아남는 울타리가 코드로 만들어진 것이 아니라 지속적인 책임감으로 만들어진 것이 될 것임을 의미합니다.

배포는 이동하고 있으며, 오픈 소스에 유리한 방향으로 이동하고 있다

오픈 소스로 남아야 한다는 논거 중 하나가 약해지는 동안, 또 다른 논거는 강화되고 있습니다.

도구의 발견과 채택(adoption)에서 점점 더 큰 비중을 차지하는 부분은 더 이상 검색이나 랜딩 페이지를 통해 이루어지지 않습니다. 그것은 코딩 에이전트(coding agent) 내부에서 일어납니다. 누군가가 자신이 무엇을 만들고 있는지 설명하면, 모델이 스택(stack)을 제안하고 통합(integration) 코드를 작성합니다. 만약 당신의 소스(source), 문서(docs), 그리고 API 표면(API surface)이 공개되어 있다면, 모델은 당신을 추천할 수 있고 실제로 컴파일되는 코드를 당신의 API를 대상으로 작성할 수 있습니다. 만약 당신이 폐쇄적이라면, 당신은 해당 경로에서 대체로 보이지 않게 되며, 모델이 당신의 마케팅 사이트에서 기억해내는 정보만을 얻게 될 뿐입니다.

이는 에이전트를 인간과 대등하게 설계해야 할 하나의 사용자 계층(user class)으로 만든다는 것을 의미합니다. 구체적으로는, 에이전트를 위한 퀵스타트 가이드(quickstart guides), 증상보다는 해결 방법을 설명하는 에러 메시지(error messages), 선형적 읽기(linear read)가 아닌 검색(retrieval)을 위해 구조화된 문서, 그리고 당신이 상업적 판매(vendored)를 원하는 부분에 대한 허용적인 라이선스(permissive licensing)를 의미합니다. 왜냐하면 에이전트는 어떤 식으로든 당신의 퀵스타트를 누군가의 저장소(repo)에 붙여넣을 것이기 때문입니다.

이것이 오픈 코어(open core)에 가해지는 압박을 상쇄한다고 생각하지는 않습니다. 하지만 이것은 해답이 폐쇄적으로 변하는 것이 아니라는 점을 시사합니다. 해답은 경계선이 놓이는 위치를 바꾸는 것입니다.

명백한 조치는 라이선스 변경입니다. 하지만 여기서는 효과가 없을 것이라 생각합니다.

이러한 종류의 압박에 대한 업계의 표준적인 대응은 라이선스를 변경하는 것이었습니다. BSL, SSPL, 그리고 이와 유사한 소스 가용(source-available) 약관들이 있으며, 때로는 일정 기간이 지난 후 다시 오픈 라이선스로 전환하는 방식을 취하기도 합니다.

이 방식은 제가 제안하려는 것보다 확실한 장점을 가집니다. 바로 하나의 코드베이스(codebase)를 유지한다는 점입니다. 유지 관리해야 할 두 번째 빌드도 없고, 기능 드리프트(feature drift)도 없으며, 별도의 테스트 매트릭스(test matrix)도 필요 없습니다. 이것은 결코 작은 문제가 아니며, 그 어떤 대안이라도 다른 측면에서 이 장점을 능가해야 합니다.

하지만 이 방식은 제가 설명한 문제를 해결하지 못합니다. 이러한 라이선스들은 클라우드 제공업체가 프로젝트를 서비스 형태로 재판매하는 것을 막기 위해 설계되었습니다. 이들은 일반적으로 최종 사용자의 내부 운영(production) 사용은 허용합니다. 따라서 라이선스 변경은 기업이 에이전트를 사용하여 자체적인 엔터프라이즈 티어(enterprise tier)를 구축하는 문제에 대해서는 아무런 조치도 취하지 못합니다. 왜냐하면 라이선스가 제한하려 했던 대상은 애초에 그것이 아니었기 때문입니다.

그것이 실제로 초래하는 결과는 첫 번째 기둥을 잃게 된다는 것입니다. 수많은 기업이 소스 가용(source-available) 약관에 대해 포괄적인 조달 규정을 가지고 있습니다. 당신은 기반(foundation)과 배포 패키징(distro packaging)을 잃고, 기본적 신뢰의 일부를 잃게 됩니다. 또한 라이선스 변경 이후의 패턴은 이미 잘 확립되어 있습니다. 새로운 약관을 싫어하는 당사자들이 지원하는 포크(fork)가 나타나며, 이제 당신은 당신 자신의 프로젝트의 역사와 경쟁하게 됩니다.

즉, 오픈 소스가 당신에게 제공해주던 것들을 대가로 지불하게 되지만, 실제로 침식되고 있는 대상에 대해서는 방어하지 못합니다.

Comparison table of three ways to draw the commercial boundary in an open source product

대신 내가 선을 긋는 지점

내가 나누고자 하는 경계는 소프트웨어를 실행하는 것과 소프트웨어 플릿(fleet)을 운영하는 것 사이입니다.

오픈 프로젝트는 하나의 완전한 프로덕션급(production-grade) 배포판입니다. 소프트웨어가 가진 모든 기능은 오픈 에디션에서도 온전한 성능으로 제공되어야 합니다. 분산형을 대신하는 인메모리 큐(in-memory queue)나 인위적인 제한(artificial ceilings) 같은 것은 없어야 합니다. 이는 원칙 이상의 문제입니다. 만약 오픈 에디션이 약화된 빌드라면, 잠재 고객이 로컬에서 검증한 그 어떤 것도 프로덕션 환경을 예측할 수 없게 됩니다. 그리고 데이터 인프라(data infrastructure)에서 흥미로운 실패 사례들은 바로 단일 노드 개발 빌드에서는 발생할 수 없는 것들입니다. 기능이 제한된 에디션은 신뢰를 얻지 못합니다. 기업은 여전히 오픈 프로젝트를 가져가서 프로덕션에서 실행할 수 있어야 하며, 저에게 비용을 지불하지 않을 수도 있어야 합니다. 그것이 계약이며, 그것은 실질적이어야 합니다.

상용 제품(Commercial product)은 그 위에 위치하여 시스템이 '무엇을 하는가'가 아니라 시스템이 '어떻게 실행되는가'를 처리하는 별도의 시스템입니다. 이는 클러스터 전반에 걸친 배포(deployments), 조정된 업그레이드 및 롤백(rollbacks), 장애 조치 감독(failover supervision), 테넌시(tenancy) 및 쿼터 관리(quota management), 정책 집행(policy enforcement), 비용 제어(cost controls), 그리고 단일 인스턴스가 아닌 전체 클러스터에 대한 관측성(observability)을 운영합니다. 이는 폐쇄적이며 상업적 라이선스가 적용되며, 고객은 자신의 인프라 내부에서 이를 실행합니다. 셀프 호스팅(Self-hosting)이 엔드 투 엔드(end to end)로 유지되는데, 이것이 바로 엔터프라이즈 구매자가 실제로 요구하는 사항입니다.

누군가 대신 말하게 두기보다, 차라리 제가 명백한 반론을 먼저 제기하겠습니다. '폐쇄적인 컨트롤 플레인(control plane)은 그저 더 세련된 어휘를 사용한 기능 제한(feature gating) 아닌가?'라는 질문 말입니다. 차이점은 구매를 거절한 고객에게 어떤 일이 일어나는가에 있습니다. 기능 제한(feature gating) 방식에서는 의도적으로 불완전한 제품을 받게 되며, 그 결핍을 느끼도록 설계되어 있습니다. 반면 여기서는 제품 전체를 받게 되고 그것은 정상적으로 작동합니다. 고객이 얻지 못하는 것은 여러 팀에 걸쳐 수년간 수많은 인스턴스를 실행할 때 비로소 유효해지는 계층(layer)일 뿐입니다. 그 계층은 제가 제품에서 제거한 조각이 아닙니다. 그것은 별개의 제품이며, 재생산 가능한 기능(capability)이 아니라 운영 레버리지(operational leverage)에서 가치가 발생하는 제품입니다.

이것이 바로 제가 앞서 설명한 압박에 더 잘 견딜 수 있는 이유이기도 합니다. 엔터프라이즈 기업은 SSO 통합을 오후 한나절 만에 만들어낼 수 있습니다. 하지만 부분적 장애(partial failures), 버전 불일치(version skew), 롤백 경로(rollback paths) 전반에 걸쳐 올바른 상태를 유지하는 무언가를 구축하고, 이전 섹션에서 언급했듯이 이를 영원히 소유하는 것은 차원이 다른 문제입니다. 그리고 라이선스 조항과 달리, 이 경계는 법적인 경계가 아닌 제품의 경계입니다.

비용은 실재합니다. 당신은 두 시스템 사이의 안정적인 계약(contract)을 유지하며 두 개의 시스템을 관리하고 있으며, 그 계약은 당신이 함부로 깨뜨릴 수 없는 호환성 표면(compatibility surface)이 됩니다. 오픈 엔진(open engine)은 그 자체의 가치만으로도 선택될 수 있을 만큼 충분히 훌륭해야 하며, 그렇지 않으면 이 모든 것을 가능하게 만드는 커뮤니티는 다른 곳으로 떠나버릴 것입니다. 또한, 5년 전보다 개방성에 대해 얻을 수 있는 인정은 줄어들 것입니다. 왜냐하면 많은 사람들이 "폐쇄형 컨트롤 플레인 (closed control plane)"이라는 문구를 읽는 순간 거기서 멈춰버릴 것이기 때문입니다.

이것이 어떻게 결론지어질지는 모르겠습니다

저는 이 모든 것을 예측으로서 확신하지는 않습니다. 소프트웨어를 구축하는 경제학은 그 위에 구축된 비즈니스 모델보다 더 빠르게 움직이고 있으며, 제가 여기에 쓴 내용의 대부분은 제가 가장 확신하는 부분들을 포함하여 1년 뒤에는 다르게 보일 수도 있는 상황에 대한 해석입니다.

제가 상당히 확신하는 것은 더 작은 주장입니다. 즉, 기능을 제한하는 것(gating capabilities)은 예전보다 약해진 전략이며, 운영을 제한하는 것(gating operations)은 더 강력한 전략이라는 점입니다. 나머지는 논쟁할 가치가 있으며, 저는 조용히 틀리기보다는 공개적으로 논쟁하는 편을 택하겠습니다.

그동안 저는 계속해서 만들어 나갈 것입니다. navflow는 오픈 소스입니다: https://github.com/glassflow/navflow