보안성 검토는 최소한의 면죄부라는 한 참가자의 말

오늘 낮, 공공AX 네트워크 대화창에 질문 하나가 올라왔다. 직접 만든 프로그램이나 운영 중인 사이트에 대해 보안성 검토를 따로 받아 본 사람이 있느냐는 물음이었다. 질문한 참가자는 보안 문제로 한동안 골치가 아팠고, 보안성 검토가 어디까지나 최소한의 장치처럼 느껴져 방 안의 조언을 구한다고 밝혔다.

첫 답은 점검 항목을 짚는 쪽이었다. 한 참가자는 코드에 대해 악성코드 검사, 소스코드 보안약점(SAST) 점검, 오픈소스 라이선스와 취약점(SCA) 점검이 필요해 보인다고 적었다. 다른 참가자는 지금까지는 외부 업체와 함께 한 것만 했지만, 바이브 코딩으로 만든 도구도 단순한 도구를 넘어 서비스로 내놓게 되면 보안성 검토를 받을 생각이라고 말했다. 이 참가자의 계획에서는 직접 만든 도구도 서비스가 되는 순간 검토 대상이 된다.

이 흐름에서 바이브 코딩 계획을 말했던 바로 그 참가자가 «면죄부»라는 말을 꺼냈다.

최소한의 면죄부 느낌이죠.. ㅠㅠ 보안성검토는 서류로만 하는 거라..

같은 참가자는 실제 해킹을 막으려면 소스코드 점검과 서버·웹 취약점 점검까지 해야 한다고 덧붙였다. 서류 검토가 통과 표시를 주더라도 그것이 곧 안전하다는 뜻은 아니라는 주장이다. 같은 참가자는 개인정보나 내부 정보가 들어 있지 않아도 공공 시스템이 뚫리면 크게 알려지기 쉽고, 서비스를 올린 자리에 따라 다른 시스템으로 피해가 번질 수 있어 검토가 필요하다고 설명했다.

화제는 곧 현장의 조건으로 옮겨 갔다. 또 다른 참가자는 개발을 하면 보안성 검토와 소스코드 검증을 거쳐 서비스해야 하지만 예산과 인력이 모두 모자라 서비스부터 시작하게 되는 경우가 있다고 말했다. 한 참가자는 기본 점검만 해도 곳곳에서 취약점이 나와 점검하는 쪽도 곤란할 것이라고 했다.

근데 뭔가 점검이라고 해도 거진 기본점검만 들어가도 여기저기 취약점 속출이라 ㅋㅋㅋㅋ

책임을 어디에 두느냐에 대한 이야기도 나왔다. 한 참가자는 보안 솔루션을 문의했다가 들은 조언을 전했다.

그냥 기관에서는 구매해서 쓰고, 사고 발생하면 업체로 책임소재 돌리는게 편하고 최고다 라고 하셔서

전한 참가자는 곧 그것이 사고 이후의 이야기이며, 어떻게 막을지보다 유출은 어차피 난다는 인식이 요즘 당연해진 것이냐고 되물었다. 앞서 기본 점검 이야기를 했던 참가자는 기능이 많아질수록 기술적으로 일일이 막기는 어렵다며, 대응이 빠르고 성실한 업체를 고르는 쪽이 공공 부문에서는 현실적인 대안일 수 있다고 의견을 냈다. 같은 참가자는 이어 각 팀의 자체 점검 보고와 실상이 다른 경우가 많고, 예산 사정상 전부 뒤집기는 어렵다고 말했다. 점검을 받더라도 취약점을 하나씩만 고치고 계속 쓰게 된다는 아쉬움도 나왔다.

논의 후반에는 이런 말도 나왔다.

공격이 방어보다 더 유리한 판이라고 들었던 것 같습니다. 그냥 빨리 빨리 고치는게 최선인듯요

기사의 풀이를 덧붙이면, 이날 토론은 보안성 검토를 하느냐 마느냐보다 검토가 무엇을 보증하느냐에 가까웠다고 보인다. 서류 심사는 절차를 밟았다는 기록을 남기지만, 코드와 서버의 실제 약점을 찾는 작업은 예산과 인력이 따로 있어야 한다는 것이 참가자들 말의 공통 줄기다. 직접 만든 서비스가 늘어나는 환경에서 이 간극은 더 자주 드러날 가능성이 있다. 다만 이는 대화에 나온 주장들을 묶어 읽은 것이며, 기관별 실제 검토 방식이나 사고 사례를 확인한 내용은 아니다.