Cal.com 오픈소스 클로즈드소스 전환, 내 서비스 어떻게 되나

오픈소스 스케줄링 툴 Cal.com이 라이선스 구조를 바꾸고 있어요. 무료로 자유롭게 쓸 수 있었던 코드가 상업적 제약을 받게 된다면, 지금 Cal.com 기반으로 서비스를 돌리는 팀들은 뭘 해야 할까요? 이 글은 그 질문에 답해요.

핵심 요약

• Cal.com은 AGPLv3 기반 오픈소스에서 상업적 사용에 제약이 있는 혼합 라이선스 구조로 전환 중이에요.
• 자체 호스팅(self-hosted)으로 상업적 서비스를 운영 중인 팀은 유료 라이선스 계약이 필요해질 수 있어요.
• 대안 도구(Calendso 포크, Rallly, Cal.com 클라우드)로의 마이그레이션 비용은 팀 규모에 따라 수십만 원에서 수백만 원 수준으로 추정돼요.
• 라이선스 전환은 Cal.com만의 문제가 아니에요. HashiCorp, Elasticsearch 사례처럼 오픈소스 기업의 수익화 압박이 2026년에도 계속되고 있거든요.

Cal.com이 왜 라이선스를 바꾸고 있나

배경부터 볼게요. Cal.com은 Peer Richelsen과 Bailey Pumfleet이 만든 오픈소스 스케줄링 플랫폼이에요. Calendly의 오픈소스 대안으로 주목받았고, GitHub 스타가 수만 개에 달할 만큼 개발자 커뮤니티에서 인기를 끌었죠.

그런데 오픈소스 기업에게는 공통된 딜레마가 있어요. 코드는 공개했는데, 그걸 써서 돈 버는 건 다른 사람이고 자기들은 클라우드 운영비만 내는 상황이요. Cal.com은 2022년 이후 여러 차례 VC 펀딩을 유치했지만, 지속가능한 수익 모델 없이는 투자자 기대에 부응하기 어렵거든요.

라이선스 전환의 핵심은 이거예요. AGPLv3는 “내 코드를 쓰면 너도 코드를 공개해"라는 조건이에요. 그런데 Cal.com은 Enterprise Edition 기능들에 별도 상업적 라이선스를 적용하기 시작했어요. 이른바 오픈 코어(Open Core) 모델이죠. HashiCorp가 Terraform을 BSL로 전환한 것, Elastic이 Apache 2.0에서 SSPL로 바꾼 것과 같은 맥락이에요.

2026년 현재, 이 흐름이 단순한 정책 변경이 아니라 오픈소스 생태계 전체의 구조 변화를 반영하고 있어요. 그래서 “우리 서비스는 어떻게 되나"를 묻는 팀들이 늘고 있는 거예요.

실제로 뭐가 달라지나: 세 가지 시나리오

자체 호스팅 중인 팀: 가장 민감하게 봐야 해요

자체 서버에 Cal.com을 올려서 쓰는 팀이라면, 현재 버전의 라이선스부터 확인해야 해요.

• 코어 기능(AGPLv3): 개인 프로젝트나 코드 공개가 가능한 서비스라면 계속 무료로 쓸 수 있어요.
• Enterprise 기능: 팀 관리, 워크플로 자동화, 일부 통합 기능은 유료 라이선스 대상으로 분류되고 있어요.

문제는 “Enterprise 기능"의 경계가 버전마다 달라진다는 거예요. 오늘 무료였던 기능이 다음 릴리즈에서 유료 티어로 이동할 수 있어요. Git 히스토리를 보면서 각 기능의 라이선스 헤더를 직접 확인하는 게 현실적인 방법이에요.

SaaS로 Cal.com을 임베드한 팀: AGPL의 함정

Cal.com을 자기 SaaS 제품에 넣어서 최종 사용자에게 제공하고 있다면, AGPLv3의 네트워크 사용 조항이 적용돼요. Cal.com 코드를 쓴 서비스를 외부에 제공하면 자기 코드도 공개해야 할 수 있어요. 부담스러운 팀이라면 Enterprise 라이선스를 사는 게 합법적으로 코드를 닫는 유일한 방법이에요.

Cal.com Cloud 사용자: 직접 영향 없음

cal.com에서 직접 계정을 만들어 쓰는 경우라면 라이선스 변화는 크게 관계없어요. 다만 SaaS 요금제 가격이 오를 가능성은 열려 있어요.

대안 비교: 지금 마이그레이션할 가치가 있나?

결국 “갈아탈까?“라는 질문에 다다르게 되죠.

어떤 선택이 맞을까요?

팀 규모가 작고 단순 미팅 예약만 필요하다면 Rallly가 가장 깔끔한 선택이에요. MIT 라이선스라 법적 리스크가 없거든요. 다만 Cal.com 수준의 워크플로 자동화나 라운드로빈 배정 같은 기능은 없어요.

기존 Cal.com 투자(커스텀 개발, UI 수정 등)를 버리기 아깝다면, 라이선스 변경 이전의 Cal.com 포크를 유지하는 것도 단기 옵션이에요. 단, 보안 패치를 직접 백포트해야 하는 부담이 생겨요.

상업적 안정성이 최우선이라면, 역설적으로 Calendly처럼 처음부터 상업적 SaaS를 쓰는 게 법적 불확실성을 없애는 방법이에요.

지금 당장 뭘 해야 하나: 팀 유형별 체크리스트

자체 호스팅 + 내부 사용 팀:

• 현재 사용 버전의 LICENSE 파일과 각 기능 파일 헤더 확인
• Enterprise 기능 사용 여부 감사(audit)
• 6개월 이내 라이선스 재검토 일정 잡기

자체 호스팅 + 외부 서비스 제공 팀:

• 법무팀 또는 외부 변호사와 AGPL 적용 범위 검토 (이건 진짜 해야 해요)
• Cal.com Enterprise 라이선스 견적 받아보기
• 대안 스택으로의 마이그레이션 비용 추정 (엔지니어 시간 포함)

Cal.com Cloud 사용 팀:

• 가격 인상 공지 구독
• 데이터 내보내기(export) 기능 테스트해두기 — 나중에 갑자기 가격 오르면 이게 필요해요

앞으로 주시할 신호:

• Cal.com GitHub 레포지토리의 라이선스 파일 변경 커밋
• Cal.com 공식 블로그의 가격 정책 업데이트
• 오픈소스 커뮤니티(Hacker News, 관련 Discord)의 포크 동향

결론: Cal.com만의 문제가 아닌 이유

Cal.com의 라이선스 변화를 한 회사의 정책 변경으로만 보면 놓치는 게 있어요.

2023년 HashiCorp의 BSL 전환, 2024년 Redis의 라이선스 변경에 이어, 2026년에도 오픈소스 기업들의 수익화 압박은 계속되고 있어요. 기업들이 오픈소스 기반 스택의 리스크를 재평가하고 있다는 뜻이에요.

앞으로 6~12개월 안에 볼 것들:

• Cal.com Enterprise 가격의 공식 발표
• 커뮤니티 포크의 성숙도 (유지보수 인력 확보 여부)
• 유사한 라이선스 전환을 고려하는 다른 오픈소스 스케줄링 도구들의 동향

지금 당장 코드 한 줄 고치지 않아도 돼요. 하지만 라이선스 파일 하나는 오늘 열어보세요. 거기서 이미 답이 써 있을 수도 있거든요.

이 글에서 다룬 Cal.com 라이선스 정보는 2026년 4월 기준 공개된 정보를 바탕으로 합니다. 상업적 라이선스 적용 범위는 사용 케이스에 따라 다를 수 있어요. 법적 판단이 필요한 경우 전문 변호사와 상담을 권해요.

참고자료

1. Open Agents : Vercel의 자율 에이전트 SDK
2. 오케스트로 클라우드, ‘2026년 서비스형 소프트웨어(SaaS) 전환 컨설팅 지원사업’ 공급기업으로 선정 < IT < 기사본문 - 데일리시큐
3. Cal.com: Funding, Team & Investors

Photo by NASA on Unsplash