▲

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

 (cal.com)
2P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 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 시대의 보안 현실이 소프트웨어 배포 모델에 직접적인 영향을 미치고 있음을 보여주는 사례

함께 보면 좋은 글 β

▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • Drew Breunig이 어제 올린 글에서 정반대 결론을 냈음
    이제 보안 취약점은 토큰을 써서 찾을 수 있는 자원이 되었기 때문에, 오히려 오픈소스가 더 가치 있음
    오픈소스는 여러 프로젝트가 감사 비용을 공유할 수 있지만, 클로즈드소스는 모든 취약점을 혼자 찾아야 함

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

  • Thunderbird 프로젝트 책임자임. 우리의 일정 관리 도구 Thunderbird Appointment는 항상 오픈소스로 유지될 것임
    GitHub 저장소에서 함께 만들어보자고 초대함. Cal.com을 대체할 수 있도록 도와줄 예정임

    • README나 로그인 전 화면에 스크린샷을 추가하면 좋겠음. 도구는 좋아 보이는데, 호스팅 버전 가격이 궁금함
    • 하지만 오래된 리눅스 노트북에서는 Thunderbird가 너무 무거움. 저사양 사용자도 고려해줬으면 함. 인터넷을 감당 가능한 수준으로 유지해달라는 요청임
    • 사이트에 들어가서 이메일을 입력하니 대기자 명단으로 보내고, 결국 이메일을 차단했음. 사용자 경험이 별로였음
    • “우리와 함께 만들어보자”는 말에 농담으로, “그럼 예약(appointment) 이 필요한가요?”라고 함
    • 좋은 대안으로 보인다는 긍정적 반응도 있었음

  • LLM이 코드 취약점을 그렇게 잘 찾는다면, 릴리스 전에 자체 LLM 펜테스트를 돌리면 되는 것 아님?
    Linus의 법칙(링크)이 이제야 현실이 된 느낌임

    • 하지만 릴리스 후에는 공격자가 무한한 시간과 점점 더 똑똑해지는 LLM으로 코드를 분석할 수 있음.
      방어하려면 공격자가 할 모든 일을 매 릴리스마다 미리 수행해야 함
    • LLM이 발전하면서 FOSS 유지보수는 시간과 인력 비용이 급증함.
      AI가 만든 저품질 이슈나 PR이 늘어나서 오픈소스를 유지할 유인이 줄어듦.
      상업 제품이 FOSS 코어를 기반으로 할 때 이런 전환이 더 많아질 듯함
    • 클로즈드소스에서는 LLM을 내부적으로 활용해 보안을 강화할 수 있음.
      하지만 외부에 공격 기회를 열어두지 않기 위해 닫는 것도 이해됨
    • 커밋이 잦은 환경에서는 매번 전체 코드베이스를 LLM으로 스캔해야 해서 비용이 폭증함.
      GitHub 같은 곳도 이미 정적 분석 비용이 높음
    • 결국 단순한 코드를 작성하고, 컴파일러 수준에서도 LLM 보안 테스트를 하는 게 좋다는 의견임

  • 이번 결정은 보안보다 비즈니스적 판단으로 보임.
    AI 덕분에 셀프호스팅이 쉬워져서, 오픈소스 프로젝트의 유료 호스팅 수익이 줄고 있음

    • 사람들은 LLM을 이용해 “프로 기능”을 직접 구현하거나 확장 포인트를 찾아냄. 보안은 겉치레에 불과함
    • AI를 탓하는 건 핑계임. 이미 AI는 코드에서 학습했음. 유전 알고리즘 + 퍼징을 결합하면 인간보다 훨씬 빠르게 학습함
    • 요즘은 뭐든 AI 탓으로 돌림. 인력 감축도, 제품 단종도, 소스코드 폐쇄도 전부 AI 때문이라는 식임
    • Google Workspace의 예약 도구처럼 제품이 이미 상품화(commoditized) 되고 있음
    • 결국 “팔아넘긴 사람(sellout)”이라는 비판도 나옴

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

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

  • “AI가 코드에 접근하니까 닫겠다”는 건 핑계에 불과함

    • 실제 이유는 AI나 보안이 아니라, 클론 프로젝트가 너무 많아 수익이 줄었기 때문임

  • 이런 결정은 결국 보안 은폐(Security through obscurity) 로 보임.
    언제부터 그게 옳은 모델이 되었는지 의문임

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

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

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

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.