Cal.com이 상용 코드베이스를 비공개로 전환하고, 대신 MIT 라이선스의 커뮤니티 에디션인 Cal.diy를 공개했다. 핵심 스케줄링 엔진은 남겼지만 팀, 조직, 워크플로, SSO/SAML, 인사이트 같은 상용·엔터프라이즈 기능은 빠졌다.12
이 변화가 지금 중요한 이유는 단순히 "오픈소스 Calendly 대안이 하나 생겼다"가 아니기 때문이다. 이제 선택지는 더 분명해졌다. SaaS 벤더 의존을 감수할지, 아니면 일정 예약 인프라의 운영 복잡성을 직접 떠안을지다. Cal.diy는 기능 비교표보다 운영 모델로 평가해야 맞다.
Cal.diy를 볼 때 먼저 물어야 할 것: 비용 절감인가, 당직 추가인가
공식 문서와 저장소는 꽤 직설적이다. Cal.diy는 "use at your own risk"이며, "개인용·비프로덕션 용도"를 강하게 권장한다.13 이 표현은 마케팅 겸손이 아니라 책임 경계선에 가깝다.
확인된 사실부터 보자. Cal.diy는 완전한 MIT 라이선스이고, 라이선스 키 없이 동작하며, API v2, 웹훅, 결제 이벤트, 여러 캘린더 연동, 화상회의 연동까지 포함한다.12 반면 팀 이벤트, 조직 관리, 라우팅 폼, 워크플로 자동화, 인사이트, SAML SSO 같은 기능은 빠졌다.24
이게 뜻하는 바는 분명하다. 개인 사용자나 개발자에게는 "충분히 쓸 만한 self-hosted 예약 시스템"일 수 있다. 하지만 여러 담당자가 라운드로빈으로 미팅을 받고, 조직 단위 정책과 인증을 묶고, 분석과 자동화를 써야 하는 팀에게는 애초에 다른 제품이다.
그래서 비교 기준도 바뀌어야 한다.
호스티드 Cal.com이나 Calendly는 벤더 리스크를 산다. 대신 가동률, 업그레이드, 메일 발송, 캘린더 동기화 장애 대응을 외주화한다.
Cal.diy는 통제권을 산다. 대신 장애 원인 분석과 복구 책임도 함께 산다.
가벼운 사내 예약 워크플로를 직접 만드는 선택은 기능은 적지만, 오히려 운영 표면적이 더 작을 수도 있다.
혼자 쓰거나, 내부 실험용이거나, 데이터 위치 통제가 정말 중요한 소규모 기술팀이라면 Cal.diy는 검토할 만하다. 반대로 "예약 링크 하나면 된다"는 비개발 조직이라면, 저렴해 보여도 실제로는 가장 비싼 선택이 될 수 있다.
숨은 비용은 서버비가 아니라 신뢰성의 세부 항목에 있다
설치 요건만 보면 과해 보이지 않는다. Node.js 18+, PostgreSQL 13+, Yarn, 그리고 배포는 AWS·GCP·Vercel·Railway·Render 등 여러 경로를 지원한다.13 겉으로는 "Next.js 앱 하나 띄우는 일"처럼 보인다.
하지만 예약 시스템의 어려움은 앱 구동이 아니라 주변부 신뢰성에 있다.
예를 들어 인증은 단순 로그인 화면 문제가 아니다. NEXTAUTH_SECRET, 암호화 키, OAuth 설정, 앱별 자격 증명 관리가 필요하다.13 이메일은 더 까다롭다. 예약 확인·변경·취소 메일이 스팸함으로 가거나 지연되면 제품은 "작동"해도 비즈니스는 실패한다. 캘린더 동기화도 마찬가지다. 최근 Cal.com 쪽 릴리스 노트만 봐도 구글 캘린더 rate limit 대응, CalDAV 중복 초대, 시간대 엣지케이스 같은 문제가 계속 다뤄진다.5 Cal.diy가 같은 계열 코드를 가졌다는 점은 장점이지만, self-host 환경에서 이런 문제를 누가 감시하고 복구하느냐는 별도 질문이다.
여기서 반론도 가능하다. "어차피 SaaS도 장애 난다." 맞다. 다만 차이는 장애의 존재가 아니라 장애의 소유권이다. 호스티드 서비스 장애는 공급자 SLA와 지원 체계의 문제다. self-host 장애는 곧 내 팀의 야간 업무가 된다.
특히 공식 문서가 상업용·엔터프라이즈 용도는 Cal.com을 쓰라고 선을 긋는 점은 중요하다.23 이는 Cal.diy가 나쁘다는 뜻이 아니라, 운영 보증이 없는 커뮤니티판이라는 뜻이다. 도입 판단에서 가장 먼저 읽어야 할 문장이다.
도입하고 싶다면, 30일 파일럿으로 "기능"보다 "실패 모드"를 검증해야 한다
Cal.diy를 진지하게 보려면 바로 전환하지 말고 작은 파일럿부터 해야 한다.
첫 1주는 내부 사용자 1~2명만 붙여서 기본 예약, 취소, 재예약, 시간대 처리, 캘린더 block 동작을 본다. 둘째 주에는 실제 외부 예약 링크를 열어보고, 메일 전달률과 중복 예약 여부를 확인한다. 셋째 주에는 구글·아웃룩·CalDAV처럼 실제 쓸 연동만 골라 실패 케이스를 본다. 넷째 주에는 업그레이드, DB 백업/복구, 비밀키 교체, cron 작업 누락 같은 운영 절차를 점검한다. Cal.diy 문서가 업그레이드, DB 마이그레이션, cron job 설정을 별도 항목으로 두는 이유가 여기에 있다.3
성공 기준도 기능 체크리스트가 아니라 운영 기준으로 잡는 편이 낫다.
예약이 "대부분 된다"가 아니라,
문제 발생 시 30분 안에 원인을 찾을 수 있는가.
업데이트 후 롤백 경로가 있는가.
캘린더/메일 실패를 로그로 감지할 수 있는가.
누가 이 시스템의 관리자이며, 휴가 중에는 누가 책임지는가.
이 질문에 답이 없으면, Cal.diy는 아직 제품이 아니라 주말 프로젝트에 가깝다.
결국 Cal.diy를 신경 써야 하는 사람은 "오픈소스라서 좋아 보인다"는 팀이 아니다. 벤더 종속보다 인프라 책임을 더 잘 다룰 수 있는 팀, 혹은 그 책임을 감수할 만큼 통제권이 중요한 팀이다. 나머지에게 중요한 판단 기준은 간단하다. 예약 시스템에서 내가 피하고 싶은 위험이 수수료인지, 아니면 운영 당직인지부터 먼저 정하는 것이다.
참고
1GitHub - calcom/cal.diy: Scheduling infrastructure for absolutely everyone. · GitHub
2Cal.diy Self-Hosting Documentation
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.