AI는 코드를 더 빨리 만들고 잠재적 버그를 찾아내는 데 도움을 줍니다. 하지만 코드 변경이나 보안 제보가 들어온 뒤에는 여전히 사람이 내용을 확인해야 합니다. 제출물은 늘어도 검토 속도가 따라가지 못하면 유지관리자의 일이 병목이 될 수 있습니다. OpenSSL의 제보 증가와 리눅스 재단 설문은 이런 엇갈림을 보여줍니다.
1
21
OpenSSL, 보안 제보는 늘었지만 모두 취약점은 아니다
OpenSSL은 인터넷 통신을 보호하는 데 쓰이는 소프트웨어입니다. 따라서 이 프로젝트의 보안과 유지관리 역량은 OpenSSL을 사용하는 여러 서비스에도 중요합니다.
1
5
OpenSSL 재단의 맷 캐스웰 사무총장은 프라하에서 열린 프로젝트 연례 콘퍼런스에서, 2026년 5월부터 7월까지 OpenSSL이 받은 보안 제보와 문의가 월평균 71건이었다고 밝혔습니다. 전년 같은 기간의 월평균 9건과 비교하면 크게 늘어난 수치입니다. 8월에는 문의가 108건에 달했습니다.
1
다만 이는 접수된 제보와 문의 건수이지, 확인된 취약점 수가 아닙니다. 지난 1년간 접수된 취약점 제보는 약 500건이었지만, 실제 공개된 취약점으로 이어진 것은 63건이었습니다. 중복 제보나 경미한 결함, 보안 권고를 낼 만한 문제가 아닌 사례도 많았습니다. AI 도구로 발견된 취약점도 대부분 심각한 결함보다는 낮은 위험도의 문제였습니다. 그래도 제보 하나하나를 살피는 데는 사람의 시간이 듭니다.
1
3
검토 부담은 OpenSSL만의 문제가 아닙니다. 콘퍼런스에서 Bouncy Castle과 cryptlib의 유지관리자들도 살펴봐야 할 제보가 늘었다고 전했습니다. Bouncy Castle의 메건 우즈는 AI가 작성한 암호화 코드의 위험성을 경고하며, 생성된 코드를 신중하게 다뤄야 한다는 점을 강조했습니다.
2
3
AI는 보안 작업을 도울 수 있지만, 판단을 대신하진 못한다
OpenSSL 최고기술책임자에 따르면 AI 도구는 코드 검토, 접수된 취약점 조사, 테스트 작성 같은 작업에 도움을 줄 수 있습니다.
3 이런 도구가 유지관리자의 일을 지원할 수는 있지만, 의심스러운 부분을 실제 취약점으로 확정하거나 사람의 판단을 불필요하게 만드는 것은 아닙니다.
1
3
문제를 찾아내는 것과 사실인지 확인하는 것은 서로 다른 단계입니다. 도구가 수상한 코드 경로나 그럴듯한 제보를 찾아내더라도, 유지관리자는 실제로 중요한 문제인지, 어떤 조치가 필요한지 판단해야 합니다. 보도에 따르면 취약점 조사부터 패치 개발, 보안 권고 발표까지 6~8주가 걸릴 수 있습니다.
3
풀 리퀘스트도 늘었다…검토 부담은 함께 커져
Red Hat이 후원한 리눅스 재단 연구 설문은 생성형 AI가 오픈소스 개발에 미치는 영향을 보여줍니다. All Things Open에서 발표된 이 설문에서 유지관리자들은 들어오는 풀 리퀘스트 가운데 25%를 저품질 ‘AI 슬롭’으로 평가했습니다. 대형 프로젝트에서는 그 비율이 31%로 올라갔습니다. 설문에는 오픈소스 기여자와 유지관리자 234명이 참여했습니다.
20
21
동시에 프로젝트 유지관리자의 59%는 기여가 늘었다고 답했습니다. 제출물이 많아지면 유용한 작업과 새로운 기여자를 만날 가능성도 커집니다. 하지만 제출물에 문제가 있을 경우 이를 찾아내고 설명하는 검토 업무도 늘어날 수 있습니다.
21
이 수치는 모든 오픈소스 프로젝트의 풀 리퀘스트를 전수 집계한 결과가 아니라 설문 응답에 기반한 추정치입니다. 그래도 한 가지 현실적인 과제를 짚어줍니다. AI가 기여물을 만드는 수고를 줄여도, 그 기여물이 병합할 준비가 됐는지 판단하는 데 드는 수고까지 줄어드는 것은 아닙니다.
20
21
제출이 늘면 접수 절차도 영향을 받는다
구글의 사례는 보안 제보가 급증했을 때 접수 프로그램이 어떤 영향을 받을 수 있는지 보여줍니다. 구글은 자동화된 제출이 크게 늘었고 그중 대부분이 유효하지 않다며, 10월 1일부터 오픈소스 소프트웨어 취약점 보상 프로그램(OSS VRP)의 제품 취약점 신규 접수를 중단했습니다. 구글은 2027년 1분기에 업데이트를 제공하겠다고 밝혔습니다. 이번 중단은 해당 프로그램의 제품 취약점 제보에 한정되며, 구글의 모든 취약점 보상 프로그램이 멈춘 것은 아닙니다.
18
오픈소스 프로젝트에 필요한 대응은 한 가지로 정해져 있지 않습니다. 다만 이번 사례들은 기여 요건을 명확히 하고, 필요할 때 재현 가능한 근거와 테스트를 요청하며, 자동화 도구는 사람의 검토를 건너뛰는 수단이 아니라 초기 분류를 돕는 용도로 쓰는 방안을 시사합니다. 이는 보도에서 확인된 사실이라기보다 그 내용을 바탕으로 한 실무적 시사점입니다.
1
18
21
AI는 코드 작성과 잠재적 결함 발견을 빠르게 할 수 있습니다. 하지만 믿을 수 있는 소프트웨어를 만들려면, 도착한 결과를 확인할 유지관리자의 시간과 지원도 함께 필요합니다.