오픈소스는 죽지 않았다

• Cal.com이 AI 기반 취약점 탐지 위협을 이유로 핵심 코드를 비공개로 전환하며, “투명성이 곧 노출” 이 되는 시대를 언급함
• Strix는 자율형 AI 보안 에이전트를 개발하는 오픈소스 프로젝트로, Cal.com과 협력해 책임 있는 취약점 공개 절차를 진행함
• Strix는 코드 비공개가 AI 보안 위협의 해결책이 아니며, 오히려 선의의 검토 기회를 차단한다고 지적함
• AI 공격은 코드 접근 없이도 블랙박스 방식으로 침투 가능하며, 비공개 전략은 자동화된 공격에 취약함
• 진정한 해법은 AI 방어를 개발 프로세스에 통합하고, 지속적 자동 검증을 통해 오픈소스의 투명성과 협력을 유지하는 것임

---

Cal.com의 코드 비공개 전환과 오픈소스 보안 논쟁

• Cal.com이 핵심 코드베이스를 오픈소스에서 비공개로 전환한다고 발표
  • CEO Bailey Pumfleet은 AI가 대규모로 취약점을 자동 탐지해 “투명성이 곧 노출” 이 되는 시대가 되었다고 언급
  • AI가 코드 스캔과 익스플로잇을 거의 ‘제로 비용’ 으로 수행할 수 있게 되었다는 점을 이유로 제시
• Strix는 자율형 AI 보안 에이전트를 개발하는 오픈소스 프로젝트로, 최근 24k GitHub 스타를 돌파
  • 하루 150억 개 이상의 LLM 토큰을 처리하며 소프트웨어 취약점을 탐지
  • Cal.com과 협력해 Strix를 이용한 책임 있는 취약점 공개 절차를 진행했으며, 아직 패치되지 않은 버그의 세부 내용은 공개하지 않음
  • Cal.com의 결정이 사용자 보호 의지에서 비롯된 것임을 인정
• 그러나 Strix는 “코드를 닫는 것은 AI 기반 보안 위협의 해결책이 아니다”라고 강조
  • AI가 보안을 근본적으로 바꿨다는 점에는 동의하지만, 오픈소스 포기에는 반대 입장

블랙박스 AI는 비공개 코드에도 침투 가능

• 소스코드를 닫으면 공격자가 코드를 읽지 못할 것이라는 가정은 현대 AI 공격 모델에는 해당되지 않음
  • 과거 정적 분석 도구에는 유효했지만, 자율형 AI 에이전트는 코드 접근 없이도 공격 수행 가능
• Strix 같은 도구는 블랙박스·그레이박스 테스트에 특화
  • 실제 엔드포인트와 상호작용하며 브라우저 상태 조작, 네트워크 트래픽 분석, 비즈니스 로직 취약점 탐지 수행
• 코드 비공개는 선의의 개발자들의 검토 기회를 차단할 뿐, 공격자에게 노출된 API·웹훅 등 공격면은 그대로 남음

‘보안 은폐’ 전략은 자동화 공격에 취약

• 비공개 코드는 내부 보안팀과 주기적 수동 침투 테스트에 의존
  • 그러나 공격자는 무한히 작동하는 AI 봇으로 24시간 취약점을 탐색
• 이는 내부 인력이 외부 AI 공격보다 더 빠르게 결함을 찾을 수 있다는 가정에 기반하지만, 현실적으로 불가능
• 과거에도 ‘보안을 위한 은폐(Security through obscurity)’ 는 실패해왔으며, AI 시대에는 그 실패 속도가 기하급수적으로 빨라질 것

진짜 해법: AI로 AI를 방어

• 소프트웨어 개발 속도가 인간 보안 검토 속도를 초월한 것은 사실
  • 그러나 해법은 코드를 숨기는 것이 아니라 AI 방어를 개발 프로세스에 통합하는 것
• AI 기반 지속 검증(continuous validation) 이 필요
  • 개발자가 Pull Request를 열면 AI가 즉시 공격 시도
  • 인프라 변경 시 AI가 자동으로 공격면 검증
• CI/CD 파이프라인 내에서 보안 테스트가 자동화되어야 하며, 공격 자동화보다 더 나은 내부 자동화로 대응해야 함

오픈소스는 여전히 유효

• “많은 사람의 눈이 버그를 얕게 만든다”는 전통적 원칙은 약화될 수 있으나, 오픈소스 자체는 죽지 않음
• Strix는 투명성이 강점을 만든다는 신념으로 오픈소스를 유지
  • 차세대 보안 도구는 공격 도구만큼 접근 가능하고 개방적이어야 함
• 코드를 숨긴다고 AI 해커를 막을 수는 없지만, 개발자에게 자율형 보안 에이전트를 제공하면 방어 가능성 높아짐
• Strix는 AI 기반 지속 보안 테스트를 무료로 체험할 수 있도록 제공

[GN⁺]

Hacker News 의견들

• 나는 오픈소스 프로젝트를 운영 중인데, 최근 몇 달 사이 보안 취약점 리포트가 폭증했음
  대부분은 사소한 케이스였지만, 진짜 문제도 있었고 모두 수정했음
  폐쇄형 소프트웨어는 이런 리포트를 받지 않겠지만, AI로 악용될 위험이 있음
  그래서 이 글의 메시지에 전적으로 공감함

  • 폐쇄형이라 해도 내부에서는 AI 스캐너를 돌릴 수 있지 않음?
    외부에만 닫혀 있을 뿐, 내부 개발자에게는 닫혀 있지 않음
  • 자동화된 리포 스캐너로부터는 리포트가 안 오겠지만, 버그 바운티 프로그램은 여전히 많은 리포트를 만들어냄
    다만 AI 도구가 등장하면서 초보자들이 AI가 만들어낸 허상 리포트를 제출하는 문제도 생김
    폐쇄형 기업도 자발적으로 보안 감사를 수행해야 함
  • 공격자 입장에서는 AI를 이용해 오픈소스 저장소를 공격하는 게 훨씬 이득임
    Cal.com이 폐쇄형으로 전환한 건 이해되지만, 결국 Strix의 마케팅처럼 보임
    오픈소스 기업은 계속 공개 상태를 유지할수록 손해가 커짐
  • 나도 오픈소스 프로젝트에 야간 자동 침투 테스트를 설정했음
    이런 리포트를 주기적으로 공개하면 보안 신뢰도를 증명할 수 있을 것 같음
    다만 기존 프로젝트에는 중간·경미 수준의 이슈가 쌓여 있어 해결에 시간이 걸릴 듯함
  • 우리 회사는 내부적으로 AI 스캐너와 수동 침투 테스트를 병행함
    즉, 코드 비공개 상태에서 AI 취약점 탐지와 다층 방어를 동시에 활용 중임

• CEO가 말한 “AI가 대규모로 취약점을 자동 탐지한다”는 이유는 핑계처럼 들림
  실제 이유는 오픈소스로는 지속 가능한 비즈니스 모델을 만들기 어렵기 때문일 것 같음

  • 동의함. 수익성 확보를 위해 폐쇄형으로 전환하는 건 이해하지만, 보안 핑계는 솔직하지 못함
  • 우리는 5년간 오픈소스로 300% 성장률을 유지하며 수익을 냈음
    폐쇄형 전환은 오히려 비즈니스에 불리하지만, 고객 데이터 보호가 더 중요하다고 판단했음
  • 요즘은 뭐든 AI 탓으로 돌리는 경향이 있음
    인력 감축이든, 라이선스 변경이든 “AI 때문”이라는 핑계가 편리함
  • 이제는 오픈소스 코드를 직접 쓰지 않고 필요한 부분만 발췌해 재구성하는 게 너무 쉬움
    npmjs 같은 곳이 곧 참고용 사이트로 변할지도 모름
  • ‘cal.diy’를 남기고 기업용은 닫는 건 전형적인 오픈코어 전략임
    AI 스캐너 탓으로 돌리는 건 단지 PR용 포장에 불과함

• 이 글은 정말 콘텐츠 마케팅의 교과서 같음

  1. 자극적인 제목으로 관심을 끌고
  2. Cal.com의 입장을 공감하며 독자의 호감을 얻고
  3. 문제에 대한 진지한 해법을 제시하면서
  4. 결국 자사 제품 홍보로 자연스럽게 연결됨
     진심과 마케팅이 절묘하게 섞인 사례임
  • 나도 그렇게 읽었음. 작성한 회사가 AI 취약점 스캐닝 서비스를 판매하는 곳이라 결국 가입 유도용임
    실제로 Strix가 Cal.com 코드를 스캔했지만, 많은 취약점을 놓쳤음
    어떤 플랫폼도 완벽하지 않으며, AI 스캐너만으로는 충분하지 않음
  • 이 글이 이렇게 많이 추천받은 게 아쉬움. 내용 밀도가 댓글 하나 분량임
  • 개인적으로 AI를 쓰지 않음. 지금 시점에서 AI 열풍에 올라타는 게 마케팅적으로 쉬울 뿐, 진정한 가치가 있는지는 의문임

• “Security through obscurity(은폐를 통한 보안)”은 단독으로 쓰일 때만 문제가 됨
  공격자에게 비용을 높이는 억제층으로는 유효한 전략임
  결국 보안은 어느 쪽이 더 많은 자원을 투입하느냐의 싸움임
  AI가 인간보다 효율적일 뿐, 오픈 대 폐쇄의 본질적 계산식은 변하지 않음

• Cal.com이 정말 보안을 걱정하는 건지, 아니면 오픈소스 SaaS의 어려움을 덮기 위한 핑계인지 궁금함
  이 논리는 이미 수십 년 전에도 틀린 것으로 판명된 주장임

• 나는 “은폐 보안”이 진짜 이유라고 믿지 않음
  단지 오픈소스를 닫으면 수익을 더 낼 수 있다고 생각했을 뿐임

  • 맞음. 그들의 제품이니 마음대로 할 수 있음
    오픈소스의 추한 면 중 하나는, 사람들이 무료 노동을 당연하게 여기는 태도임
    수년간 공짜로 일해준 개발자에게 감사하기보다, 계속 무료로 일하지 않는다고 화를 냄
    정작 본인들은 급여 없이 일하지 않으면서 말임

• 글을 보면 Cal.com이 레드팀 봇으로 취약점 테스트를 받았던 것 같음
  버그가 너무 빨리 발견되자 CEO가 수정 비용에 부담을 느끼고 코드를 닫았을 가능성이 있음
  사실상 “Cal.com 코드에 취약점이 많다”는 공개 선언처럼 보임

  • 혹은 스캐너가 거짓 양성(false positive) 을 너무 많이 내서 문제였을 수도 있음
    이를 조정하면 진짜 취약점을 놓치게 되고, 결국 검증 비용이 커짐
    오픈소스는 이런 리포트가 공개되어 평판 손상이 생기지만, 폐쇄형은 그렇지 않음
    그래서 폐쇄형으로 전환했을 가능성도 있음

• 진짜 위험은 취약점 탐지가 아니라, LLM이 오픈소스 프로젝트를 다른 언어로 재작성해 라이선스를 우회하는 능력임

  • 폐쇄형 프로젝트에도 이론상 같은 일이 가능하지만, 제한이 많음
  • 실제로 이런 일이 자주 일어남. AI가 코드를 거의 그대로 재생성해 복제본 프로젝트를 만드는 식임
    법적으로는 애매함. 사람이 공부 후 새로 작성하면 괜찮지만, AI가 하면 사실상 복잡한 복붙임
    이런 경우 라이선스가 어떻게 적용될지 불분명함
  • 많은 오픈소스 라이선스는 포크와 재판매를 허용함
    코드 공개만으로는 비즈니스가 성립하지 않으며, 운영 역량이 더 중요함

• “보안 테스트는 CI/CD 파이프라인에 자동화되어야 한다”는 주장에는 동의함
  하지만 그게 오픈소스의 필요성을 증명하지는 않음

• 오픈소스의 균형은 이미 오래전에 깨졌음
  기업들이 오픈소스 코드를 이용해 유료 제품을 만들면서도 기여하지 않는 구조가 오래전부터 존재했음
  PHP처럼 전 세계가 쓰지만 예산이 부족한 언어가 그 예시임