Hacker News 2026.04.16 27

Cal.com, 오픈소스에서 클로즈드소스로 전환 — 왜 이런 결정을 했을까?

무슨 일이 있었나요?

오픈소스 일정 관리 플랫폼으로 유명한 Cal.com이 클로즈드소스로 전환한다고 공식 발표했어요. Cal.com은 Calendly의 오픈소스 대안으로 주목받아 온 프로젝트인데요, 개발자들 사이에서 "오픈소스라서 선택했다"는 이유가 꽤 컸던 서비스예요. 그런 프로젝트가 소스 코드를 비공개로 돌린다니, 꽤 큰 뉴스가 아닐 수 없어요.

이 소식이 왜 중요하냐면, Cal.com만의 이야기가 아니라 최근 오픈소스 생태계 전반에서 벌어지고 있는 흐름의 연장선이기 때문이에요. "오픈소스로 시작해서 사용자를 모으고, 비즈니스가 커지면 라이선스를 바꾼다" — 이 패턴이 이제 하나의 공식처럼 자리잡고 있거든요.

왜 클로즈드소스로 가는 걸까?

Cal.com 측이 밝힌 이유를 살펴보면, 결국 핵심은 지속 가능한 비즈니스 모델 문제예요. 오픈소스 프로젝트를 운영하는 회사들이 늘 마주치는 딜레마가 있는데요 — 코드를 공개하면 커뮤니티가 성장하고 제품이 좋아지지만, 동시에 대형 클라우드 회사들이 그 코드를 가져다가 자체 서비스로 만들어 돈을 벌 수 있다는 거예요.

이게 뭐냐면, 쉽게 비유하자면 여러분이 맛있는 레시피를 공개했더니 대형 프랜차이즈가 그 레시피로 가게를 차리고 돈을 버는 상황이에요. 레시피를 만든 사람한테는 아무런 대가도 돌아오지 않는 거죠. Cal.com도 비슷한 고민을 하다가, 결국 핵심 코드를 보호하는 쪽으로 방향을 틀었어요.

실제로 Cal.com의 셀프 호스팅 사용자 중 상당수가 유료 플랜 없이 무료로 운영하고 있었다고 해요. 오픈소스는 무료라는 인식이 강하다 보니, 회사 입장에서는 매출로 이어지지 않는 사용자가 늘어나는 아이러니한 상황이 계속된 거예요. 직원 급여를 내고, 서버를 운영하고, 새로운 기능을 개발하려면 결국 수익이 필요한데, 그 수익 구조가 오픈소스 모델에서는 쉽지 않았던 거죠.

오픈소스 라이선스 변경, 이제 트렌드인가?

사실 이런 움직임은 Cal.com이 처음이 아니에요. 최근 몇 년간 비슷한 사례가 꽤 많이 있었거든요.

가장 대표적인 게 HashiCorp의 사례예요. Terraform, Vault 등으로 유명한 HashiCorp가 2023년에 오픈소스 라이선스(MPL)에서 BSL(Business Source License)로 전환했는데요, 이 결정이 커뮤니티에서 엄청난 반발을 불러왔어요. 결국 커뮤니티가 Terraform을 포크해서 OpenTofu라는 별도 프로젝트를 만들었을 정도였죠.

Redis도 마찬가지예요. Redis Labs는 일부 모듈의 라이선스를 변경했고, 이에 반발한 커뮤니티에서 Valkey라는 포크가 탄생했어요. MongoDB는 SSPL이라는 새로운 라이선스를 만들어서 클라우드 서비스 제공자들이 MongoDB를 서비스로 제공하기 어렵게 만들었고요. Elasticsearch 역시 라이선스를 변경하면서 AWS가 OpenSearch라는 포크를 만드는 계기가 됐어요.

이런 흐름을 보면, 오픈소스와 상업적 지속가능성 사이의 긴장감이 업계 전반에 걸쳐 있다는 걸 알 수 있어요. Cal.com의 결정은 이 긴장이 중소 규모의 SaaS 프로젝트에까지 확산되고 있다는 신호로 볼 수 있어요.

개발자 커뮤니티의 반응

이번 결정에 대한 반응은 갈리는 편이에요. 한쪽에서는 "회사가 살아남아야 프로젝트도 유지된다"며 현실적인 선택을 이해하는 시각이 있어요. 스타트업이 오픈소스만으로 수익을 내기가 얼마나 어려운지 아는 사람들은 공감하는 분위기예요.

반대편에서는 "오픈소스라서 믿고 선택한 건데 사다리 걷어찬 거 아니냐"는 비판도 있어요. 특히 기업 환경에서 Cal.com을 셀프 호스팅으로 도입한 경우, 앞으로 업데이트를 받을 수 없게 될 수도 있으니까요. 이건 단순히 감정의 문제가 아니라 실제 마이그레이션 비용이 발생하는 실무적 문제이기도 해요.

또 하나 주목할 점은, Cal.com의 기존 코드는 이미 공개되어 있기 때문에 누군가 포크해서 별도의 오픈소스 프로젝트로 발전시킬 가능성이 있다는 거예요. HashiCorp → OpenTofu, Redis → Valkey처럼요.

한국 개발자에게 주는 시사점

이 사건은 몇 가지 실무적인 교훈을 줘요.

첫째, 오픈소스 의존성 관리에 대해 다시 생각해봐야 해요. 우리가 프로젝트에 쓰는 오픈소스 도구가 언제든 라이선스를 변경할 수 있다는 걸 인지하고, 핵심 인프라에 오픈소스를 도입할 때는 라이선스 변경 리스크도 고려해야 해요.

둘째, 오픈소스 비즈니스 모델의 현실을 이해하는 게 중요해요. 오픈소스를 활용한 사이드 프로젝트나 스타트업을 꿈꾸는 분들이라면, 어떻게 수익을 만들 것인지를 처음부터 설계해야 해요. Open Core 모델, 클라우드 호스팅, 엔터프라이즈 기능 분리 등 다양한 전략이 있지만, 어느 것도 쉽지 않다는 걸 Cal.com이 다시 한번 보여주고 있어요.

셋째, Cal.com의 대안을 찾는 분들이라면, 현재 남아 있는 기존 오픈소스 버전을 기반으로 한 커뮤니티 포크 프로젝트가 나올 수 있으니 지켜볼 만해요.