# Cal.com, AI 보안 위협으로 오픈소스에서 클로즈드 소스로 전환

> Clean Markdown view of GeekNews topic #28603. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28603](https://news.hada.io/topic?id=28603)
- GeekNews Markdown: [https://news.hada.io/topic/28603.md](https://news.hada.io/topic/28603.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-17T03:33:42+09:00
- Updated: 2026-04-17T03:33:42+09:00
- Original source: [cal.com](https://cal.com/blog/cal-com-goes-closed-source-why)
- Points: 2
- Comments: 1

## Topic Body

- 5년간 오픈소스로 운영되던 Cal.com이 **AI 기반 보안 위협 증가**로 인해 **클로즈드 소스 전환**을 결정
- AI가 코드베이스를 자동 분석해 취약점을 찾는 시대가 도래하며, **공개 코드가 공격자에게 직접적인 단서**가 되는 상황 발생
- 회사는 **고객 데이터 보호**를 위해 오픈소스 유지와 보안 위험 사이에서 후자를 선택
- 오픈소스 정신을 이어가기 위해 **Cal.diy 프로젝트를 MIT 라이선스로 공개**, 커뮤니티용 자체 호스팅 버전 제공
- AI가 기존 보안 체계를 압도하는 속도로 발전함에 따라, Cal.com은 **보안 안정화 후 오픈소스 복귀 의지**를 밝힘

---

### Cal.com의 오픈소스 종료 결정과 AI 보안 위협
- **Cal.com**은 5년간 오픈소스로 운영해왔으나, **AI 기반 보안 위협**의 급증으로 인해 **클로즈드 소스(Closed Source)** 로 전환 결정
  - 고객 데이터 보호를 최우선으로 두며, 오픈소스 유지가 더 이상 안전하지 않다고 판단
  - “쉬운 선택이 아니었다”고 밝힘
- 과거에는 애플리케이션 취약점을 악용하려면 숙련된 해커의 시간과 노력이 필요했으나, **AI가 코드베이스를 자동으로 스캔해 취약점을 찾는 시대**로 변화
  - 오픈소스 코드는 공격자에게 “금고 설계도를 제공하는 것과 같다”고 표현
  - AI 보안 스타트업들이 이 기능을 상용화하면서, 각기 다른 취약점을 탐지해 **신뢰할 수 있는 단일 보안 기준을 세우기 어려운 상황**이 됨
- Cal.com은 두 가지 선택지 중 하나를 택해야 했다고 밝힘
  - 오픈소스를 유지하며 고객 데이터 위험을 감수하거나,
  - 클로즈드 소스로 전환해 위험을 줄이는 방향
  - 완벽한 해결책은 아니지만, **사용자 보호를 위한 불가피한 결정**으로 판단
- 오픈소스 정신을 이어가기 위해 **Cal.diy**라는 별도 프로젝트를 **MIT 라이선스**로 공개
  - Cal.diy는 개발자와 취미 사용자에게 개방된 버전으로, **자체 호스팅 가능한 커뮤니티 중심 버전**
  - 본 서비스 코드베이스는 인증 및 데이터 처리 시스템 등 핵심 구조가 크게 변경되어 **Cal.diy와 기술적으로 분리된 상태**
- AI가 보안 환경을 빠르게 변화시키고 있으며, **AI가 BSD 커널의 27년 된 취약점을 몇 시간 만에 찾아내고 익스플로잇을 생성한 사례**도 언급
  - 이러한 속도와 정밀도는 기존 보안 대응 체계를 압도
  - Cal.com은 고객과 애플리케이션, 민감 데이터를 보호하기 위해 가능한 모든 조치를 취하고 있으며,
    **보안 환경이 안정되면 다시 오픈소스로 돌아가고 싶다는 의지**를 표명

### 향후 방향과 메시지
- 현재는 **보안 리스크 완화와 사용자 보호**가 최우선 과제
- 오픈소스 커뮤니티와의 관계는 Cal.diy를 통해 유지
- 장기적으로는 **보안 환경의 진화에 따라 오픈소스 복귀 가능성**을 열어둠
- 이번 결정은 **AI 시대의 보안 현실**이 소프트웨어 배포 모델에 직접적인 영향을 미치고 있음을 보여주는 사례

## Comments



### Comment 55627

- Author: neo
- Created: 2026-04-17T03:33:43+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47780456) 
- Drew Breunig이 어제 올린 [글](https://www.dbreunig.com/2026/04/14/cybersecurity-is-proof-o...)에서 정반대 결론을 냈음  
  이제 보안 취약점은 **토큰을 써서 찾을 수 있는 자원**이 되었기 때문에, 오히려 오픈소스가 더 가치 있음  
  오픈소스는 여러 프로젝트가 **감사 비용을 공유**할 수 있지만, 클로즈드소스는 모든 취약점을 혼자 찾아야 함  
  - 그 글을 [여기](https://news.ycombinator.com/item?id=47769089)에 다시 올렸음. 제목은 *Cybersecurity looks like proof of work now*  
  - 실제 이유는 AI가 제품을 **저작권 세탁(copyright-wash)** 하는 걸 막기 위한 것 같음. 보안을 핑계로 삼는 느낌임  
  - 이 결론이 더 설득력 있게 들림. Mythos가 등장한 지 몇 주밖에 안 됐는데, 이렇게 빠르게 원칙을 바꾸는 건 이상함. 아마 **비즈니스적 이유**가 있었고, 지금은 대중에게 팔기 좋은 명분을 찾은 것 같음  
  - 경제적으로도 타당한 결론임. 결국 토큰 비용을 감당할 만큼의 가치를 창출하거나, 취약점 발견의 경제적 이익을 줄여야 함  
    배포 범위를 줄이거나 시스템 권한을 낮추는 방식으로 가능함.  
    앞으로는 **‘오픈 스펙 + 모델 기반 코드 생성’** 형태로 진화할 것 같음. 보안과 거버넌스는 모델 레이어에서 이뤄질 전망임  
  - “시스템을 강화하려면 공격자가 쓰는 토큰보다 더 많이 써야 한다”는 말은 이상함. 안정된 소프트웨어라면 공격 표면이 줄어들고, Mythos는 새로운 취약점을 **생산하지 않음**. 방어자에게 토큰 면에서 이점이 있어야 함  

- Thunderbird 프로젝트 책임자임. 우리의 일정 관리 도구 **Thunderbird Appointment**는 항상 오픈소스로 유지될 것임  
  [GitHub 저장소](https://github.com/thunderbird/appointment)에서 함께 만들어보자고 초대함. Cal.com을 대체할 수 있도록 도와줄 예정임  
  - README나 로그인 전 화면에 **스크린샷**을 추가하면 좋겠음. 도구는 좋아 보이는데, 호스팅 버전 가격이 궁금함  
  - 하지만 오래된 리눅스 노트북에서는 Thunderbird가 너무 무거움. **저사양 사용자**도 고려해줬으면 함. 인터넷을 감당 가능한 수준으로 유지해달라는 요청임  
  - 사이트에 들어가서 이메일을 입력하니 대기자 명단으로 보내고, 결국 이메일을 차단했음. **사용자 경험이 별로**였음  
  - “우리와 함께 만들어보자”는 말에 농담으로, “그럼 **예약(appointment)** 이 필요한가요?”라고 함  
  - 좋은 대안으로 보인다는 긍정적 반응도 있었음  

- LLM이 코드 취약점을 그렇게 잘 찾는다면, 릴리스 전에 **자체 LLM 펜테스트**를 돌리면 되는 것 아님?  
  Linus의 법칙([링크](https://en.wikipedia.org/wiki/Linus%27s_law))이 이제야 현실이 된 느낌임  
  - 하지만 릴리스 후에는 공격자가 무한한 시간과 점점 더 똑똑해지는 LLM으로 코드를 분석할 수 있음.  
    방어하려면 공격자가 할 모든 일을 **매 릴리스마다 미리 수행**해야 함  
  - LLM이 발전하면서 FOSS 유지보수는 **시간과 인력 비용**이 급증함.  
    AI가 만든 저품질 이슈나 PR이 늘어나서 오픈소스를 유지할 유인이 줄어듦.  
    상업 제품이 FOSS 코어를 기반으로 할 때 이런 전환이 더 많아질 듯함  
  - 클로즈드소스에서는 LLM을 내부적으로 활용해 보안을 강화할 수 있음.  
    하지만 외부에 **공격 기회를 열어두지 않기** 위해 닫는 것도 이해됨  
  - 커밋이 잦은 환경에서는 매번 전체 코드베이스를 LLM으로 스캔해야 해서 **비용이 폭증**함.  
    GitHub 같은 곳도 이미 정적 분석 비용이 높음  
  - 결국 **단순한 코드**를 작성하고, 컴파일러 수준에서도 LLM 보안 테스트를 하는 게 좋다는 의견임  

- 이번 결정은 **보안보다 비즈니스적 판단**으로 보임.  
  AI 덕분에 셀프호스팅이 쉬워져서, 오픈소스 프로젝트의 유료 호스팅 수익이 줄고 있음  
  - 사람들은 LLM을 이용해 “프로 기능”을 직접 구현하거나 확장 포인트를 찾아냄. 보안은 **겉치레**에 불과함  
  - AI를 탓하는 건 핑계임. 이미 AI는 코드에서 학습했음. **유전 알고리즘 + 퍼징**을 결합하면 인간보다 훨씬 빠르게 학습함  
  - 요즘은 뭐든 AI 탓으로 돌림. 인력 감축도, 제품 단종도, 소스코드 폐쇄도 전부 AI 때문이라는 식임  
  - [Google Workspace의 예약 도구](https://workspace.google.com/resources/appointment-schedulin...)처럼 제품이 이미 **상품화(commoditized)** 되고 있음  
  - 결국 “팔아넘긴 사람(sellout)”이라는 비판도 나옴  

- 잠재 고객으로서 Cal.com의 결정에 실망했음.  
  오픈소스는 **투명한 SSDLC** 덕분에 신뢰를 얻을 수 있지만, 클로즈드소스는 벤더를 믿을 수밖에 없음  
  Drew Breunig의 주장에는 동의하지 않음. 버그 수는 유한하고, 충분히 강력한 모델이 주기적으로 코드를 스캔하면 **남은 취약점 확률이 급감**함  

- “AI가 오픈소스 코드를 스캔할 수 있다면?” → 그럼 그냥 **버그를 고치면 됨**.  
  이 논리는 전혀 설득력이 없음  

- “AI가 코드에 접근하니까 닫겠다”는 건 **핑계에 불과함**  
  - 실제 이유는 AI나 보안이 아니라, **클론 프로젝트**가 너무 많아 수익이 줄었기 때문임  

- 이런 결정은 결국 **보안 은폐(Security through obscurity)** 로 보임.  
  언제부터 그게 옳은 모델이 되었는지 의문임  
  - 은폐는 주된 방어 수단이 아니라 **보조적 억제 수단**일 때만 유효함  
  - 공격 표면을 줄이는 건 은폐가 아니라 **공격 벡터 최소화** 전략임  
  - 그래도 “은폐 없는 보안”보다는 낫다는 의견도 있음  
  - 공동창업자라는 사람이 “이웃집 16살짜리가 15분, 100달러면 해킹 가능하다”고 말함  
  - 왜 “보안을 은폐로 하지 말자”는 개념이 생겼는지 잊은 듯함.  
    과거 세대가 바보라서가 아니라, **겉보기엔 좋아 보여도 실패한 접근법**이었기 때문임  

- “우리는 오픈소스를 믿었다”는 Cal.com의 말은 공허함.  
  진심이었다면 이런 **무의미한 변명**은 하지 않았을 것임  

- 이건 **AI 이전에도 할 수 있었던 변명**임.  
  핵심 제품이 충분히 차별화되지 못해 수익을 지키려는 시도로 보임.  
  결국 **매출 보호용 조치**일 뿐임