자동차 공장에서 고장 발생하면? 대부분 사전 조치 행해
소프트웨어의 보안 구멍, 패치로 막을 생각하면 경제적으로 손해

[보안뉴스 문가용 기자] 기업의 임원들에게 있어 ‘소프트웨어 개발’이란 무엇일까? ‘제품 생산’이나 다름없다. 마치 현대기아자동차에게 자동차처럼, 할리데이비슨의 오토바이처럼 말이다. 그런데 자동차 조립 공정에서 100대에 10대꼴로 이상 현상이 발생한다면 어떨까? 아마 이 현상은 즉각 발견되어 상부로 보고되어질 것이다. 그러면 여기에 적당한 인원이 투입되어 이상 현상을 조사하고, 이미 결함을 가진 채 조립이 끝난 제품들에 대한 수리나 폐기 작업을 시작될 것이다. 이런 사후 조치들은 전부 돈이 들어가는 일이지만, 자동차 제조업체가 이 돈을 아끼지는 않을 것이며 평소 조립 공정을 멈추는 일도 없을 것이다.


그러면서 한 편으로는 이상 현상에 대한 근원을 파헤치는 게 당연하다. 공정의 어떤 부분에 문제가 생겨 결함이 발생하는 건지 파악해 해당되는 곳의 기계의 설정을 손보거나 아예 기계자체를 바꿔야 할 수도 있다. 결함의 종류에 따라 사후 조치보다 돈이 더 들 수도 있고, 심지어 생산을 잠시 중단해야 할 수도 있지만 장기적으로 봤을 땐 이렇게 문제의 근원을 없애는 편이 안정적이며 경제적으로도 나은 판단일 때가 많다. 기업 임원들은 100대에 10대 꼴로 결함을 고쳐나가는 게 더 싼지, 공정을 중단하고도 근원을 고쳐버리는 게 더 싼지 계산해보고 결정을 내릴 것이다. (대부분은 후자를 택한다.)

이야기를 다시 소프트웨어 개발로 돌려보자. 소프트웨어 개발 공정 중에 보안을 도입시킨다는 건 임원진들에게 있어 여태까지 해왔던 자동차 조립 공정을 멈추고 새로운 공정을 들여온다는 것이다. 즉 초반 투자 비용이 꽤나 굵직하다는 것이다. 물론 장기적으로 봤을 때 메우지 못할 비용은 아닌 게 대부분이지만, 이는 임원진들이 계산기 두드려가며 판단할 일이다.

그런데 그 계산이 그리 간단하지만은 않다. 왜냐하면 도입한다는 보안 방책에도 여러 가지 종류가 있기 때문이다. 이를 크게 두 가지로 나눌 수 있는데 하나는 처음부터 결함이 나오지 않도록 하는 것이고, 다른 하나는 제품화 된 이후에 고치는 것이다. 시큐어 코딩이나 자동화 코드 점검을 통한 단계별 버그 탐지는 전자에 해당한다. 모든 개발이 완료된 후나 심지어 출시 이후 패치를 개발하는 건 후자에 해당한다. 침투 테스트 역시 후자다.

임원들의 언어인 ‘경제학적’으로 봤을 때 이 두 가지 중 어떤 것이 타당한 선택일까? 당연히 미리 방지하는 것이다. 패치 개발과 배포는 그 자체로 또 다른 소프트웨어 개발의 시작이다. 상품을 처음부터 기획하고 만들어내고 시장에 무료로 뿌려야 하는 것이다. 인력이 투입되고 시간이 투입되며 생산 인프라를 소모시켜야 한다. 이걸 소프트웨어 하나 나올 때마다 반복한다면, 그때 그때 들어가는 돈이 눈에 보이지 않을지라도 누적되는 부담이 결코 적다고 할 수 없다. 소프트웨어 개발 공정에서 보안이 이르게 투입될수록 총 비용이 절감된다는 게 업계 중론이기도 하다. 자동차 공장에서도 위와 같은 경우 공정 자체를 손보지 결함이 생긴 제품을 그때 그때 고쳐야겠다고 계획하지는 않는 것이 보통이다.

그러나 아무리 사전에 보안을 철저히 한다고 한들 100% 완벽하고 버그 없는 소프트웨어란 역사상 존재했던 적이 없다. 어느 정도의 사후 처리가 필수라는 것이다. 웹과 모바일 애플리케이션에 있어 가장 인기가 높은 ‘사후 처리’ 방법 중 하나에 침투 테스트라는 것이 있다. 웹과 모바일 애플리케이션의 개발이 완료된 이후에 시도되는 것으로, 소비자가 직접 다룰 서비스나 제품에 대한 실질적인 품질 검사라고 볼 수 있다. 자체적으로 시도할 수도 있지만 전문가를 외부에서 초빙해 실시하는 경우가 많고, 그렇기에 꽤나 값이 나가는 과정이다. 이는 마치 자동차 공장에서 막 조립이 끝났지만 결함이 발견돼, 버릴 수는 없고 해서 인력을 추가로 투입해 수리하는 것과 비슷하다.

최근 대형 건강보험 업체에서 소프트웨어 보안과 관련된 ‘소요 시간’ 실험을 한 적이 있다. 보안 점검을 개발 과정 중간 중간에 도입시키는 것과, 기존처럼 개발을 하고 나중에 침투 테스트를 해보는 것을 비교해보는 것이 목적이었다. 해당 실험에 응한 건강보험 업체는 이미 2013년에 보안을 공정 중간 단계에 도입시킨 바 있다. 그러므로 이 실험은 2013년 이전 공정과 이후 공정의 소요 시간을 비교해본 것이기도 하다. 실험 결과 2013년 이전의 공정에 드는 시간이 훨씬 더 오래 걸렸을 뿐만 아니라 제품들의 질도 현저히 떨어졌다. 위험한 리스크들이 여럿 발견된 것이다. 한 번 완료된 제품에 대해 다시 한 번 수정 작업이 들어가지 않아도 된다는 게 가장 큰 시간 절약의 요인이었다.

이 실험을 하면서 발견한 또 다른 중요한 점은 해당 업체의 실제 생산성이 올라갔다는 것이다. 개발자들이 ‘패치 작업 어차피 또 해야 할 것’이라고 여기는 것과 ‘이 작업을 여기서 마무리 짓고 새 작업을 시작할 수 있다’는 마음가짐이 큰 영향을 미친 것으로 분석됐다. 마무리를 지을 수 있다는 것과 그렇지 않다는 것에 실무자들의 ‘사기’가 좌지우지 된다는 건 숫자로만 나와 있지 않지, 모두가 아는 사실이기도 하다.

자동차뿐만 아니라 생산업에 종사하는 사장님들은 대부분 ‘고장률이 어찌됐든 일단 만들어내고 나중에 다 고치면 되지’라고 마음먹지 않는다. 그런데 유독 소프트웨어 쪽에서만 이런 생각들이 보인다. 소프트웨어에 있어 보안 구멍은 결국 고장이나 다름없다. 고장 요인을 되도록 처음부터 없애고자 하는 게 생산업체의 보편적인 접근법이라면, 이는 소프트웨어 개발 관련 종사자들이 배워야 할 태도다. 물리적이지 않은 가상의 제품이니 뒤늦게 고칠 수 있다는 게 장점이라고 생각한다면, 사용자들이 패치를 지금처럼 잘 하지 않는 상태에서 이는 큰 착각이다. 게다가 미리 고쳐두는 게 경제적이기도 하다.

글 : 짐 루스(Jim Routh)
[국제부 문가용 기자(globoan@boannews.com)]

Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>