보안 공지처럼 보였지만, 개발자들이 읽어낸 문장은 전혀 달랐다. 2026년 4월 14일 Cal.com이 “이제 폐쇄형으로 전환한다”고 발표하자 Hacker News에서 11시간 만에 226포인트와 166개 댓글이 붙었고, selfhosted 커뮤니티에서는 거의 동시에 “AI 보안을 핑계로 오픈소스를 접는다”는 반발이 퍼졌다. 내 판단은 단순하다. 이번 사건은 취약점 공포보다 신뢰 계약이 어디서 깨졌는지를 보여준 사건에 더 가깝다.
더 흥미로운 건 발표 다음 날 나온 후속 기술 문서였다. Cal.com은 공개 저장소를 calcom/cal.diy로 넘기고, 상업 기능과 엔터프라이즈 기능을 대거 떼어낸 구조를 상세히 공개했다. 그러니 질문도 분명해진다. 정말 AI 보안이 오픈소스를 닫게 만든 걸까, 아니면 AI 보안이라는 언어가 사업 모델 재편을 설명하는 가장 편한 명분이 된 걸까.
왜 오늘 Calcom 논란이 크게 터졌나
화제성은 점수보다 감정에서 먼저 폭발했다
이번 주 개발자 커뮤니티에서 가장 강한 반응은 새 모델 성능표가 아니라 오픈소스 약속이 뒤집히는 장면에 붙었다. 같은 시각 HN 상단에는 EFF의 구글 데이터 글이 더 높은 트래픽을 가져갔지만, 개발자 실무 맥락으로 좁히면 Cal.com 이야기가 훨씬 직접적이었다. 코드 공개와 셀프호스팅을 내세우던 SaaS가 하루아침에 폐쇄 전환을 선언했기 때문이다.
특히 이 사안은 한 군데에서만 뜬 것이 아니다. 공식 블로그가 이유를 올렸고, HN에서는 “이건 보안보다 비즈니스 결정 아니냐”는 반응이 상단을 차지했고, selfhosted 커뮤니티에서는 커뮤니티 기여를 받아 성장한 제품이 뒤늦게 문을 닫는 전형적 패턴이라는 비판이 쏟아졌다. 검색량보다 체감도가 높아질 수밖에 없는 구조다.
내가 이 주제를 1순위로 본 이유도 여기 있다. 최근 100점 AI 벤치마크가 속임수인 이유에서 다뤘던 것처럼, 요즘 개발자들은 “AI가 위험하다”는 문장 자체보다 그 문장이 어디에 쓰이는지에 더 민감하다. 벤치마크를 팔 때도, 보안 공포를 말할 때도, 결국 실무자는 그 언어가 제품 전략을 가리는 포장인지 먼저 본다.
화제성 점수로 보면 왜 이 주제가 앞섰나
아래는 이번 실행에서 비교한 후보를 간단히 수치로 정리한 것이다. 점수는 실시간성 30, 논란도 25, 노출 20, 개발자 체감도 15, SEO 잠재력 10 기준으로 잡았다.
| 후보 | 카테고리 | 총점 | 메모 |
|---|---|---|---|
| Cal.com 폐쇄 전환 | security | 87 | 공식 발표와 커뮤니티 반발이 동시에 붙었다 |
| BOJ 서비스 종료 | others | 78 | 한국 개발자 체감도는 매우 높지만 글로벌 확산은 약했다 |
| Gemini Mac 앱 출시 | ai | 61 | 노출은 있었지만 논란과 실무성이 약했다 |
이 표가 중요한 이유는 단순 조회수 싸움이 아니기 때문이다. HN 전체 화제성만 보면 더 큰 이야기들이 있었지만, 개발자 블로그에서 오래 남는 검색 의도는 “왜 닫았나”, “무엇이 빠졌나”, “내가 쓰는 오픈소스도 이렇게 바뀔 수 있나” 같은 질문 쪽에 훨씬 가깝다. SEO 잠재력까지 포함하면 Cal.com 건이 앞설 수밖에 없었다.
Cal.diy로 남은 것과 사라진 것
공개 저장소는 살아남았지만 제품의 중심은 빠졌다
Cal.com이 다음 날 공개한 기술 문서는 생각보다 솔직했다. 생산 코드 저장소는 비공개로 옮기고, 공개 저장소는 calcom/cal.diy라는 새 이름으로 남겼다. 여기에는 스케줄링 엔진, 예약 흐름, 앱스토어 프레임워크, API v2 같은 기반은 남겨두되, 돈이 되는 팀 기능과 운영 기능은 대거 덜어냈다.
| 빠진 영역 | 실제 예시 | 실무에서 달라지는 점 |
|---|---|---|
| 조직과 팀 기능 | 멀티 테넌시, 팀 예약, 권한 관리 | 회사용 캘린더 SaaS로 쓰기 어려워진다 |
| 워크플로와 라우팅 | 리마인더, 후속 액션, 라우팅 폼 | 영업 운영 자동화의 핵심이 빠진다 |
| 엔터프라이즈 계층 | SSO, 인사이트, 감사 로그, 임퍼스네이션 | 기업 보안과 운영 가시성이 약해진다 |
그래서 “오픈소스 버전은 계속 남는다”는 말은 절반만 맞다. 코드는 남았지만, 사용자가 Cal.com을 선택하던 상업적 이유의 큰 덩어리가 빠졌다. 이건 취미용 셀프호스트와 기업용 제품 사이에 명확한 선을 다시 그은 결정이다.
라이선스 변경은 더 역설적이다
기술 문서에서 더 눈에 띄는 부분은 라이선스다. Cal.diy는 AGPL 3.0에서 MIT로 바뀌었다. 즉 공개 저장소는 더 느슨한 라이선스를 갖게 됐지만, 정작 핵심 제품은 더 닫혔다. 표면적으로 보면 커뮤니티 친화적 조치처럼 보이지만, 실제로는 공개 버전을 최대한 가볍고 재사용 가능하게 풀어놓고, 비즈니스 가치는 비공개 제품에 집중시키는 구조다.
내 해석을 분명히 적어두면 이건 보안 강화보다 제품 분리 전략에 가깝다. MIT로 푼 Cal.diy는 다른 팀이 훨씬 쉽게 포크하고 다시 제품화할 수 있다. 그러니 이번 전환은 “오픈소스를 포기한다”보다 “오픈소스가 담당할 역할을 더 작은 범위로 재설계한다”는 쪽이 정확하다.
AI 보안 논리가 왜 설득보다 반발을 키웠나
공격자가 토큰을 더 쓰면 끝이라는 설명은 너무 편하다
공식 글에서 Cal.com은 AI가 공개 코드베이스를 체계적으로 스캔해 취약점을 찾는 시대가 왔고, 고객 데이터를 지키기 위해 닫을 수밖에 없었다고 설명했다. 여기까지는 이해할 수 있다. 문제는 그 다음이다. 이 설명은 “그래서 공개 저장소를 닫아야 한다”로 곧장 점프한다.
바로 이 점에서 반론이 강하게 붙었다. Drew Breunig는 Cybersecurity Looks Like Proof of Work Now에서 오히려 반대 결론을 내렸다. 공격이 토큰 예산 싸움이 된 시대일수록, 많은 조직이 함께 감사 예산을 쓸 수 있는 오픈소스가 더 중요해질 수 있다는 논리다. HN 상단 댓글도 거의 같은 방향이었다. 공격자는 한 군데만 뚫으면 되지만, 닫힌 코드라고 해서 AI 기반 탐색이 사라지는 건 아니라는 것이다.
내 생각에도 여기서 결정적인 건 보안 그 자체보다 검증 가능성이다. 닫힌 코드는 겉보기에 안전해 보이지만, 외부 검토와 재현이 줄어들면 커뮤니티는 “정말 더 안전해졌는지”를 확인할 방법을 잃는다. 결국 사용자가 받아들이는 메시지는 “보안을 위해 닫았다”보다 “보안을 이유로 통제권을 회수했다”에 더 가까워진다.
신뢰 비용은 취약점 비용보다 오래 남는다
이번 반발이 유독 거셌던 이유는 저장소 숫자 때문이다. calcom/cal.diy는 지금도 4만 개가 넘는 스타와 1만 개가 넘는 포크를 가진 거대한 공개 자산이다. 이런 규모의 프로젝트가 방향을 바꾸면, 문제는 단순히 앞으로의 라이선스가 아니다. 과거에 기여했던 사람과 셀프호스트를 선택했던 팀이 무엇을 약속받았다고 느꼈는지가 함께 흔들린다.
그래서 이번 사건은 보안 논쟁인 동시에 커뮤니티 회계의 문제다. 공개 기여, 공개 브랜딩, 공개 배포로 쌓은 신뢰를 어느 시점부터 사유화 제품으로 전환할 수 있는가. 그 선을 한번 넘으면, 다음에 비슷한 구조의 스타트업이 “우리는 다르다”고 말할 때 개발자들은 훨씬 덜 믿게 된다.
지금 팀이 바로 점검해야 할 것
셀프호스트 의존도를 숫자로 먼저 확인하자
이 사건을 남의 일처럼 보기 어려운 이유는 의외로 간단하다. 많은 팀이 오픈소스 SaaS를 “일단 공개돼 있으니 안전한 선택” 정도로 생각하고 도입하기 때문이다. 하지만 실제 운영에서 중요한 건 공개 여부가 아니라, 내가 의존하는 기능이 어디까지 공개 범위에 남는지다. 팀 예약, SSO, 감사 로그, 워크플로 엔진 같은 요소가 빠지면 셀프호스트 가능성도 순식간에 달라진다.
아래 명령은 공개 저장소가 지금 어떤 상태인지 빠르게 확인하는 가장 싼 점검 루틴이다.
curl -s https://api.github.com/repos/calcom/cal.diy | python3 - <<'PY'
import json, sys
repo = json.load(sys.stdin)
print("repo:", repo["full_name"])
print("private:", repo["private"])
print("license:", repo["license"]["spdx_id"])
print("stars:", repo["stargazers_count"])
print("forks:", repo["forks_count"])
print("updated:", repo["pushed_at"])
PY
이 명령은 저장소가 실제로 공개 상태인지, 라이선스가 무엇인지, 유지보수 신호가 살아 있는지를 한 번에 보여준다. 여기에 사내 문서 한 줄만 더 붙이면 된다. 우리 서비스가 이 저장소에서 어떤 기능까지 기대하고 있는지, 그리고 그 기능이 공개 버전에 남아 있는지다.
폐쇄 전환 공지는 기능표보다 먼저 읽어야 한다
실무에서 더 중요한 건 블로그 공지문보다 제거 목록이다. 이번에도 공식 설명은 “보안”이 전면에 있었지만, 실제 제품 영향은 워크플로, 팀 관리, API 경계, 엔터프라이즈 관리 기능 삭제에서 발생했다. 그러니 다음에 비슷한 발표를 보면 가장 먼저 볼 것은 감정적인 이유 설명이 아니라 diff와 기능 제거 범위다.
결국 이번 사건이 남긴 진짜 질문은 이것이다. AI가 오픈소스를 죽이느냐가 아니다. 오픈소스로 신뢰를 모은 SaaS가 어느 시점부터 그 신뢰를 유료 통제권으로 되돌리는가, 그리고 우리는 그 신호를 얼마나 빨리 읽어낼 수 있는가. 다음 폐쇄 전환 공지가 올라왔을 때 먼저 봐야 할 건 보안이라는 단어가 아니라, 무엇이 빠졌고 누가 그 비용을 떠안게 되는지다.