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처럼 전 세계가 쓰지만 예산이 부족한 언어가 그 예시임