보안을 여러 시뮬레이션을 거쳐 세심하게 강화했다고 확신했던 서버. 하지만 AI 기반 보안 점검 도구로 한 번 검사받은 뒤 그 확신이 흔들렸다.
한 개발자가 온라인 커뮤니티에 올린 글에 따르면, 믿고 의존했던 도구가 '기대보다 훨씬 제한적인' 검사를 하고 있었다는 것으로 보인다. "충격적"이라는 표현까지 붙는다. 그럼 뭐가 문제였을까.
도구의 작동 원리에서 답을 찾을 수 있다. 이 AI 도구는 코드베이스 전체를 일괄 분석하는 방식이 아니라, 최근에 변경된 커밋들만 선별해서 리뷰하는 구조로 설계되어 있다는 것. 프로젝트의 가장 최신 변경 사항만 검사 대상으로 삼는다는 뜻인 것으로 보인다. 당연히 그 범위 밖의 코드는 검사에서 빠진다. 글쓴이는 "최근 커밋 내용에 있는 문제가 아니면 못 찾는 것 같다"고 지적한다.
이 한계가 왜 심각한 문제가 되는지는, 개발 프로젝트의 구조를 생각해보면 명확해진다.
소프트웨어는 선형 진화물이 아니라 누적의 역사다. 몇 개월 전, 혹은 몇 년 전에 작성된 코드와 설정 파일들이 운영 중인 서버 속에 그대로 살아있다. 최근 몇 주간 보안 강화 작업을 열심히 했더라도, 그 이전의 레거시 코드나 초기 설정 단계의 설정 파일들은 건드리지 않았을 가능성이 크다. 보안 패치나 개선은 '최근 변경'에만 반영되기 쉽기 때문인 것으로 보인다. 커밋 기반 검사 도구는 이 점을 간과한다. '이 부분은 최근에 수정하지 않았으니, 이전처럼 안전할 것'이라는 암묵적 가정을 하고 넘어간다. 하지만 현실은 그렇지 않을 수 있다. 오래된 코드 속에는 오래된 취약점이 묻혀있을 수 있기 때문인 것으로 보인다.
이 경험을 마주친 개발자들 사이에서는 어떤 교훈이 나올까.
우선 도구에 대한 맹목적 신뢰는 위험하다는 깨달음인 것으로 보인다. AI 기반 보안 검사 도구를 사용하더라도, 그것만으로 충분하다고 믿으면 안 된다는 뜻인 것으로 보인다. 커밋 기반 도구의 편의성은 분명하지만, 그 편의성이 곧 완전성을 의미하지는 않는다.
대신 복합적인 접근이 필요해 보인다. 커밋 기반 도구와 함께 전체 코드베이스를 정적 분석하는 별도의 도구를 병행하거나, 주기적으로 코드 전수를 감사하는 프로세스를 추가로 운영하는 식인 것으로 보인다. 또한 보안 도구를 선택할 때도 사전 조사가 필수다. 그 도구가 정확히 어떤 범위까지 커버하는지, 어떤 한계를 가지고 있는지를 미리 명확히 파악하는 것이 검사 자체만큼 중요할 수 있다는 뜻인 것으로 보인다.
결국 보안은 단일 도구나 일회성 검사로 달성되는 것이 아니라는 점을 이 사례는 시사한다. 한 가지 방식만으로는 모든 취약점을 잡을 수 없다. 커밋 기반 도구의 편의성과 속도를 누리면서도, 그 한계를 정확히 이해하고 다른 방식의 검사로 틈새를 메우는 균형 감각이 현업 개발자에게 필요해 보인다.
📌 원문 발췌
나름 신중하게 여러 시뮬레이션을 하면서 보안 강화를 한 서버인데 충격적이군요. 이게 코드 전체를 리뷰해주는 게 아니라 최근 커밋들을 기반으로 리뷰해주는 거라 최근 커밋 내용에 있는 문제가 아니면 못 찾는 것 같습니다.
원본 출처: 클리앙 모두의공원