‘CS 버그’ 사태, SW개발업계 ‘남의 일 아냐’

[애플경제 전윤미 기자] 지난 주 발생한 크라우드스트라이크(CrowdStrike, CS)의 버그 사태(CS 버그)에 대비, 과학기술정보통신부, 인터넷진흥원 등 국내 보안당국도 긴급 대응 지침을 내리기도 했다. 이번 ‘CS 버그’ 사태는 최종 사용자들의 보안의식의 중요성을 다시금 부각시킨 컷이다. 그러나 더욱 중요한 사실은 이번에 문제가 된 불량 보안 패치처럼 모든 SW개발업계의 제품도 이같은 실수나 사고의 위험에 노출되어 있다는 점이다.

보안패치에 스며든 ‘버그’ 놓치고 배포

이에 지구상의 모든 SW개발자들은 SW를 출시하기 전에 이를 철저히 점검하고, 베타 버전을 실행해야 한다는 충고가 잇따른다. 이번에 ‘CS 버그’ 사태를 일으킨 CS사는 그런 점에서 가장 기본적인 ‘ABC’조차 실천하지 않았다는 비난을 사고 있다. 보안 패치를 업그레이드하면서 미처 악성코드가 그 속에 스며든 사실을 못찾아내고, 그냥 배포해버림으로써 대재앙을 야기한 것이다. 특히 MS사와 제휴관계인 만큼, MS 윈도우와 애저 클라우드를 이용한 전 세계 IT부문과 산업을 마비시키다시피했다.

아직 어떻게 CS의 보안패치에 그런 버그가 스며들었고, 배포 과정은 어떠했는지 등은 알려지지 않고 있다. 그러나 전문가들은 “개발과 배포를 서두르다보면, 흔히 생길 수 있는 문제”라는데엔 의견을 같이한다. 역시 SW개발과 배포 전문인 ‘랜치 다클리사’의 CEO인 댄 로저는 “이번처럼 (버그가) 고객들의 운영 체제 커널 수준에 스며들면, 웹 응용 프로그램보다 수정하기가 더 어렵다”면서 “그럼에도 불구하고 배포 속도가 느릴수록 문제를 훨씬 더 빨리 잡아낼 수 있다”고 기술매체 ‘엔가젯’에 밝혔다.

또 다른 전문가들은 “‘CS 버그’ 사태와 같은 일은 잠재적으로 모든 SW회사, 심지어 뛰어난 SW릴리스 관행을 갖춘 회사에서도 일어날 수 있다”고 한다. 이번 사태의 전말이 아직 정확히 알려져있진 않지만, 버그가 묻어있는 코드가 어떻게 (배포 경로의) 틈새로 빠져나갔는가는 충분히 짐작할 수 있다는 얘기다.

‘표준 소프트웨어 릴리스 위생’이 중요

흔히 SW개발업계엔 악성코드가 묻은 SW를 배포하기 전에 철저하게 테스트하는 프로세스가 있긴 하다. 그러나 엔지니어링 팀이나, 대규모 엔지니어링 그룹의 경우에는 그런 절차를 생략할 수도 있다. 특히 “(빈번하게 반복하는) 사소한 SW업데이트에서 흔히 성가신 ‘데브옵스 테스트 라인’을 건너뛸 때 이같은 사고가 발생할 수 있다.”는 것이다.

특히 수많은 팀과 부서로 나뉘어진 대규모 조직이나 대기업에서 그럴 확률이 높다. 각 부서와 팀마다 서로 다른 관행을 최종 제품에 적용하는 경우가 많다. 그래서 ‘표준화’가 되어있지 않을 경우 잘못된 코드가 빠져나갈 ‘구멍’이 생기는 것이다.

전문가들은 이런 일을 방지하기 위해, 무엇보다 ‘표준 소프트웨어 릴리스 위생’을 실천할 것을 강조한다. 즉, 배포 전 테스트 다음에도 표준화된 제어 방식으로 배포하는 것이다.

우선 소프트웨어의 점진적 출시가 중요하다. 이번 CS사는 수시로 업데이트를 반복하며, 신속하게 패치를 출품하는데에만 주력했다. 또 모든 SW사용자에게 변경 사항을 한꺼번에 전달하지 말고, 소규모 하위 집합마다 사소한 변경 사항을 릴리스하는게 안전하다. 이를 통해 출시 범위를 확장하기 전에 어떤 일이 발생하는지 확인할 수도 있는 것이다.

만약 출시 직전에 베타 버전이나 소규모 대상에 대해 배포한 결과 문제가 발생하면, 즉시 이를 리콜할 수 있다. 즉, “문제가 있는 기능을 삭제하고, 그로 인해 업데이트 기능이 작동하지 않는 경우 아예 이전 버전으로 되돌릴 수 있다.”는 얘기다.

이에 업계에선 이른바 ‘카나리아 배포’를 권장하기도 한다. 일산화탄소 누출 여부를 테스트하기 위해 카나리아를 탄광에 보내는 관례에서 따온 이름이다. 일단 테스트 출시나 베타 버전에 문제가 없을 경우, 서두르지 않고 점진적인 출시로 미연의 사고를 방지하는 것이다.

또한 테스트 과정에선 괜찮아 보일 수 있지만, 나중에 문제가 발견될 수도 있다. 따라서 “‘랩 테스트’에서 놓친 사항을 포착하려면 양질의 데브옵스 테스트와, 정밀하게 제어된 배포 방식을 결합해야 한다.”는 주문이다.

출시 속도와 검증 사이의 ‘균형’ 필요

앞서 ‘랜치 다클리사’의 CEO인 댄 로저 등 전문가들은 가장 중요한 SW 테스팅 방법을 점검할 때 ‘플랫폼’, ‘사람’ 등을 살펴봐야 한다는 주문이다.

이에 따르면 총체적인 프로세스가 함께 원활하게 작동해야 한다는 얘기다. 즉 훌륭한 소프트웨어 플랫폼을 바탕으로, 뛰어난 능력을 갖춘 개발자가 있어야 한다. 이에 더해 사전 정의된 워크플로우와 거버넌스가 결합될 때 비로소 완벽한 SW테스팅이 가증하다는 얘기다.

그렇다고 출시 시기를 마냥 늦추거나, 개발 속도를 지나치게 낮추는 것도 문제가 있다는 지적이다. 기업용 엔터프라이즈AI 등을 개발하는 국내 S사 관계자는 “큰 조직에서 개별 엔지니어나 팀이 검증 라인을 회피하지 않도록 하는게 중요하다”면서 “그러기 위해선 개발자 등 모든 직원들에게 동일한 (테스팅 등) 접근 방식을 요구하되, 팀의 속도를 늦추지 않는 방식이 되어야 한다”고 강조했다.

다시 말해 있을 수 있는 사고를 막느라고, 경직된 시스템을 유지하는 것도 바람직하지 않다는 뜻이다. “소프트웨어 업데이트나 변경에 대해 너무 걱정을 한 나머지 테스트 주기가 매우 길어지고 결국 소프트웨어 혁신을 방해해선 안 된다”는 것이다. 그래서 “보안과 거버넌스, 출시 속도 사이의 균헝점을 찾되, 그러기 위해선 더욱 철저한 테스팅이 보장되어야 한다”는 조언이다.