소프트웨어를 새로 구매해 설치한다는 것까지도 요즘은 하나의 리스크로서 작용할 수 있다. 그러므로 효과적이고 안전한 소프트웨어 설치를 위한 전략도 필요하다. 뭘 그렇게까지 하냐고 할 수 있는데, 요즘처럼 각 기능과 패치가 빠르게 배포되는 때에는 어쩔 수 없다.
[보안뉴스 문정후 기자] 패키지 형태로 소프트웨어가 판매되던 시절, 벤더들은 모든 새로운 기능을 한꺼번에 모아서 단일 제품으로 만든 뒤 시장에 내보냈다. 하지만 최근 애자일(Agile)이라는 방법론을 도입하고 있거나 이미 도입한 많은 소프트웨어 개발사들은 조금 다른 방식을 취한다. 소프트웨어를 출시하고 나서 새로운 기능이나 패치를 가능한 꾸준하게, 멈추지 않고 내보내는 것이다.
이 두 가지 방법에는 각각의 장점과 단점이 있다. 그렇기 때문에 뭐가 더 옳다고 말할 수는 없다. 다만 상황에 따라, 혹은 소프트웨어의 종류에 따라 적합한 것을 찾을 필요는 있다. 소프트웨어의 적절한 개발과 배포 전략을 수립하기 위한 베스트 프랙티스가 있으니, 이 자리에서 소개하고자 한다.
목표 설정을 간과하지 말라
표현을 안 해서 그렇지 IT 전문가 치고 새로운 소프트웨어 설치 작업이 잘 되기를 바라지 않는 사람은 없다. 하지만 소프트웨어 설치라는 것을 중요한 작업으로 지정하고, 이를 위해 목표 설정까지 꼼꼼하게 하는 IT 전문가들은 단 한 번도 보지 못했다. 필자도 마찬가지다. 보통은 각자 사용할 사람들에게 알아서 설치하라고 하거나, IT 담당자들이 장비를 가져가 대신 해주는 것으로 끝이었다.
하지만 우리가 생각하는 것보다 새 소프트웨어 설치라는 작업은 문제의 소지를 많이 가지고 있는 작업이다. 잘못 된다면 업무가 제대로 진행되지 않으며, 그것이 컴퓨터 한 대에서 끝나지 않고 부서 전체나 심지어 회사 전체의 문제로까지 번질 가능성이 높다. 설치 자체는 잘 된 것처럼 보이더라도 실제 새 소프트웨어에 익숙해지는 데에 생각보다 심각한 문제가 생겨 이전으로 롤백해야 하는 상황이 있을 수도 있다.
소프트웨어를 설치할 때 중단되는 업무량은 최소화 해야 하고, 기업 전체의 IT 시스템에 나쁜 영향이 전달되어서는 안 된다. 또한 설치 후에는 즉시 생산성을 발휘해 아무리 못해도 이전 수준을 유지할 수 있어야 한다. 되도록 더 높은 생산성을 발휘할 수 있도록 하는 데에까지 목표를 잡고, 유지 비용 절감 등의 추가 가치까지도 가져가는 게 바람직하다. 다운타임도 없어야 하고, 새 소프트웨어를 통해 제공되는 새 기능들까지도 최대한 활용할 수 있어야 한다.
제조사가 제공한 매뉴얼부터 읽으라
소프트웨어 제조사들은 새로운 제품이나 패치가 출시될 때마다 매뉴얼과 릴리스 노트를 같이 배포한다. 물론 사용자들이 즐겨 읽는 그런 출판물은 아니다. 어려운 전문 용어가 가득하고 문법도 엉망일 때가 많기 때문이다. 새로운 장비나 소프트웨어를 구매한 사람들 대부분이 매뉴얼을 패키지와 같이 버리고 차라리 스스로 알아보는 쪽을 택하는 데에는 이유가 있다.
하지만 우리가 릴리스 노트를 무시하고 매뉴얼을 버릴 때, 우리는 실제로 어떤 일을 하고 있는 걸까? 소프트웨어로 인해 벌어질 수 있는 온갖 안 좋은 일들이 일어나지 않을 것이고, 일어나더라도 충분히 해결될 수 있을 거라는 근거 없는 희망에 PC나 네트워크의 안전을 걸고 있는 것이다. 보안을 일종의 도박으로 몰락시키고 있는 것이다.
일반 사용자들이라면 그럴 수 있다. 하지만 IT 담당자나 보안 담당자라면 일반 사용자보다 조금 더 나은 접근법을 취할 수 있어야 한다. 그것은 매뉴얼과 릴리스 노트를 읽고 내용을 파악해 일반 사용자들이 반드시 알아야 할 내용을 추려서 알리는 것이다. 내용이 너무 어렵고 읽기에 불친절할 수 있고, 그렇기 때문에 담당자 자신들도 이해하지 못할 수 있다. 그럴 때는 개발사에 연락해 궁금한 것을 해결해야 한다.
이렇게 했을 때 최종 사용자들도 새 소프트웨어 대해 보다 잘 이해한 채로 사용을 시작할 수 있지만, 무엇보다 IT와 보안 담당자들이 소프트웨어를 낱낱이 알게 된다. 소프트웨어를 알아야 해당 소프트웨어가 다른 소프트웨어나 네트워크 요소들과 어떻게 작용하는지도 유추하고 확인하여 파악할 수 있게 된다.
테스트가 생명이다
주요 데이터베이스나 ERP 시스템에서 배포되는 새 소프트웨어들은 사용자들의 시스템과 애플리케이션의 다양한 요소들에 영향을 주는 기능들을 포함하고 있을 때가 많다. 주요 OS들도 마찬가지다. 우리가 생각하는 것보다 훨씬 깊숙한 곳에까지 손을 뻗치는 소프트웨어나 기능들이 개발사들에서 만들어져 사용자들에게 전달된다.
그렇기 때문에 가끔씩 주요 OS나 시스템 소프트웨어들을 업데이트 했는데 장비가 작동을 멈추는 일이 발생한다. 중요한 요소들과 관련이 있는 소프트웨어를 설치할 때 실험 없이 설치부터 하고 보는 것은 우리가 생각하는 것보다 위험할 수 있다. 새로운 소프트웨어나 패치를 안전하게 설치해서 시험 운영해 볼 수 있는 환경을 마련하는 것이 중요하다.
생산 및 업무 환경을 똑같이 흉내 낸 실험 환경을 조성하고, 그곳에서부터 새로운 요소들을 추가해보도록 하자. 그런 후 생산 및 업무 환경이 어떤 식으로 영향을 받는지, 업무 프로세스에 어떤 문제가 발생하는지, 데이터 프라이버시나 보안에 침해 여지가 생기는지 등 잘못 될 수 있는 모든 것들에 대한 가능성을 염두에 두고 관찰하자. 안전성과 안정성이 100% 확인되기 전까지는 실제 환경에 절대로 설치하면 안 된다.
그럼에도 잘못될 경우를 대비하자
소프트웨어나 업데이트를 그 때 그 때 배포한다는 것의 가장 큰 장점은 사용자가 최신 기능의 가치를 기다리지 않고 누릴 수 있게 된다는 것이다. 원하는 소프트웨어나 추가 기능이 추가될 때까지 손꼽아 기다리는 것이 아니라 개발사가 개발을 마치는대로 즉각 이용할 수 있다. 하지만 뭐든지 서두르다보면 부작용이 생기는 법이다. 이런 배포 기법의 단점은 불충분한 실험 시간 때문에 설치 시 오류가 보다 잦게 발생한다는 것이다. 그래서 프로그램 설치에서의 전략이 강조되는 것이다.
여러 가지 전략이 있겠지만 그 중 빠져서는 안 될 것 하나는 뭔가 예상 외의 이상 현상이 발생됐을 경우를 위한 대책이다. 아무리 실제 환경과 똑같은 곳에서 실험을 진행하고, 여러 번의 꼼꼼한 검사 과정을 거쳐도 어쩌다 하나씩 예상하기 힘든 일이 벌어질 수 있다. 그렇게 됐을 때 최대한 빠르게 신기술을 도입하기 이전 과정으로 시스템들을 되돌릴 수 있어야 하나. 한 마디로 최대한 빠르게 롤백할 수 있어야 한다는 뜻이다.
소프트웨어 벤더사와 대화하라
패키지 단위로 소프트웨어를 판매하는 회사가 아니라 지속적으로 소프트웨어를 배포하는 전략을 가진 회사와 계약을 맺기 전이라면 먼저 회사의 성공 사례와 관련된 이야기를 들어보는 것을 추천한다. 당연하지만 실패 사례도 가능하다면 듣는 편이 좋다. ‘당신들의 제품을 사용했을 때 고객들이 실질적으로 어떤 도움을 얻었고, 그것이 어느 정도의 매출 성장을 이루는 데 도움이 됐는가?’라고 단도직입적으로 물어보는 게 좋다. ‘새로 설치하다가 충돌을 일으키거나 호환이 안 돼서 문제가 됐던 적은 없는가?’도 필요한 질문이다. 그 외에 사용자들이 새 기능을 익히는 데 얼마나 시간이 걸리는지 등도 좋은 참고가 된다.
사실 완전히 처음 시장에 등장한 스타트업이 아니라면 대부분 소프트웨어 벤더사들은 사용자 기업들 사이에서 이런 저런 평판을 가지고 있다. 이 때 최악의 평판을 가진 회사들은 과감히 후보 명단에서 삭제하는 것을 추천한다. 하지만 여러 가지 이유로 악평을 가진 기업과 계약을 맺어야만 하는 경우라면 어떻게 해야 할까? 그럴 때는 해당 기업과 여러 문제가 발생했을 때를 대비해 책임을 지는 것과 관련된 계약서를 작성해야 한다. 일방적으로 불리한 계약서를 들이밀면 서명할 회사가 없으니, 이런 계약서 작성에 있어서도 상대 회사와의 꼼꼼한 대화가 필요하다.
글 : 메리 섀클릿(Mary E. Shacklett), 회장, Transworld Data
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 패키지 형태로 소프트웨어가 판매되던 시절, 벤더들은 모든 새로운 기능을 한꺼번에 모아서 단일 제품으로 만든 뒤 시장에 내보냈다. 하지만 최근 애자일(Agile)이라는 방법론을 도입하고 있거나 이미 도입한 많은 소프트웨어 개발사들은 조금 다른 방식을 취한다. 소프트웨어를 출시하고 나서 새로운 기능이나 패치를 가능한 꾸준하게, 멈추지 않고 내보내는 것이다.
[이미지 = gettyimagesbank]
이 두 가지 방법에는 각각의 장점과 단점이 있다. 그렇기 때문에 뭐가 더 옳다고 말할 수는 없다. 다만 상황에 따라, 혹은 소프트웨어의 종류에 따라 적합한 것을 찾을 필요는 있다. 소프트웨어의 적절한 개발과 배포 전략을 수립하기 위한 베스트 프랙티스가 있으니, 이 자리에서 소개하고자 한다.
목표 설정을 간과하지 말라
표현을 안 해서 그렇지 IT 전문가 치고 새로운 소프트웨어 설치 작업이 잘 되기를 바라지 않는 사람은 없다. 하지만 소프트웨어 설치라는 것을 중요한 작업으로 지정하고, 이를 위해 목표 설정까지 꼼꼼하게 하는 IT 전문가들은 단 한 번도 보지 못했다. 필자도 마찬가지다. 보통은 각자 사용할 사람들에게 알아서 설치하라고 하거나, IT 담당자들이 장비를 가져가 대신 해주는 것으로 끝이었다.
하지만 우리가 생각하는 것보다 새 소프트웨어 설치라는 작업은 문제의 소지를 많이 가지고 있는 작업이다. 잘못 된다면 업무가 제대로 진행되지 않으며, 그것이 컴퓨터 한 대에서 끝나지 않고 부서 전체나 심지어 회사 전체의 문제로까지 번질 가능성이 높다. 설치 자체는 잘 된 것처럼 보이더라도 실제 새 소프트웨어에 익숙해지는 데에 생각보다 심각한 문제가 생겨 이전으로 롤백해야 하는 상황이 있을 수도 있다.
소프트웨어를 설치할 때 중단되는 업무량은 최소화 해야 하고, 기업 전체의 IT 시스템에 나쁜 영향이 전달되어서는 안 된다. 또한 설치 후에는 즉시 생산성을 발휘해 아무리 못해도 이전 수준을 유지할 수 있어야 한다. 되도록 더 높은 생산성을 발휘할 수 있도록 하는 데에까지 목표를 잡고, 유지 비용 절감 등의 추가 가치까지도 가져가는 게 바람직하다. 다운타임도 없어야 하고, 새 소프트웨어를 통해 제공되는 새 기능들까지도 최대한 활용할 수 있어야 한다.
제조사가 제공한 매뉴얼부터 읽으라
소프트웨어 제조사들은 새로운 제품이나 패치가 출시될 때마다 매뉴얼과 릴리스 노트를 같이 배포한다. 물론 사용자들이 즐겨 읽는 그런 출판물은 아니다. 어려운 전문 용어가 가득하고 문법도 엉망일 때가 많기 때문이다. 새로운 장비나 소프트웨어를 구매한 사람들 대부분이 매뉴얼을 패키지와 같이 버리고 차라리 스스로 알아보는 쪽을 택하는 데에는 이유가 있다.
하지만 우리가 릴리스 노트를 무시하고 매뉴얼을 버릴 때, 우리는 실제로 어떤 일을 하고 있는 걸까? 소프트웨어로 인해 벌어질 수 있는 온갖 안 좋은 일들이 일어나지 않을 것이고, 일어나더라도 충분히 해결될 수 있을 거라는 근거 없는 희망에 PC나 네트워크의 안전을 걸고 있는 것이다. 보안을 일종의 도박으로 몰락시키고 있는 것이다.
일반 사용자들이라면 그럴 수 있다. 하지만 IT 담당자나 보안 담당자라면 일반 사용자보다 조금 더 나은 접근법을 취할 수 있어야 한다. 그것은 매뉴얼과 릴리스 노트를 읽고 내용을 파악해 일반 사용자들이 반드시 알아야 할 내용을 추려서 알리는 것이다. 내용이 너무 어렵고 읽기에 불친절할 수 있고, 그렇기 때문에 담당자 자신들도 이해하지 못할 수 있다. 그럴 때는 개발사에 연락해 궁금한 것을 해결해야 한다.
이렇게 했을 때 최종 사용자들도 새 소프트웨어 대해 보다 잘 이해한 채로 사용을 시작할 수 있지만, 무엇보다 IT와 보안 담당자들이 소프트웨어를 낱낱이 알게 된다. 소프트웨어를 알아야 해당 소프트웨어가 다른 소프트웨어나 네트워크 요소들과 어떻게 작용하는지도 유추하고 확인하여 파악할 수 있게 된다.
테스트가 생명이다
주요 데이터베이스나 ERP 시스템에서 배포되는 새 소프트웨어들은 사용자들의 시스템과 애플리케이션의 다양한 요소들에 영향을 주는 기능들을 포함하고 있을 때가 많다. 주요 OS들도 마찬가지다. 우리가 생각하는 것보다 훨씬 깊숙한 곳에까지 손을 뻗치는 소프트웨어나 기능들이 개발사들에서 만들어져 사용자들에게 전달된다.
그렇기 때문에 가끔씩 주요 OS나 시스템 소프트웨어들을 업데이트 했는데 장비가 작동을 멈추는 일이 발생한다. 중요한 요소들과 관련이 있는 소프트웨어를 설치할 때 실험 없이 설치부터 하고 보는 것은 우리가 생각하는 것보다 위험할 수 있다. 새로운 소프트웨어나 패치를 안전하게 설치해서 시험 운영해 볼 수 있는 환경을 마련하는 것이 중요하다.
생산 및 업무 환경을 똑같이 흉내 낸 실험 환경을 조성하고, 그곳에서부터 새로운 요소들을 추가해보도록 하자. 그런 후 생산 및 업무 환경이 어떤 식으로 영향을 받는지, 업무 프로세스에 어떤 문제가 발생하는지, 데이터 프라이버시나 보안에 침해 여지가 생기는지 등 잘못 될 수 있는 모든 것들에 대한 가능성을 염두에 두고 관찰하자. 안전성과 안정성이 100% 확인되기 전까지는 실제 환경에 절대로 설치하면 안 된다.
그럼에도 잘못될 경우를 대비하자
소프트웨어나 업데이트를 그 때 그 때 배포한다는 것의 가장 큰 장점은 사용자가 최신 기능의 가치를 기다리지 않고 누릴 수 있게 된다는 것이다. 원하는 소프트웨어나 추가 기능이 추가될 때까지 손꼽아 기다리는 것이 아니라 개발사가 개발을 마치는대로 즉각 이용할 수 있다. 하지만 뭐든지 서두르다보면 부작용이 생기는 법이다. 이런 배포 기법의 단점은 불충분한 실험 시간 때문에 설치 시 오류가 보다 잦게 발생한다는 것이다. 그래서 프로그램 설치에서의 전략이 강조되는 것이다.
여러 가지 전략이 있겠지만 그 중 빠져서는 안 될 것 하나는 뭔가 예상 외의 이상 현상이 발생됐을 경우를 위한 대책이다. 아무리 실제 환경과 똑같은 곳에서 실험을 진행하고, 여러 번의 꼼꼼한 검사 과정을 거쳐도 어쩌다 하나씩 예상하기 힘든 일이 벌어질 수 있다. 그렇게 됐을 때 최대한 빠르게 신기술을 도입하기 이전 과정으로 시스템들을 되돌릴 수 있어야 하나. 한 마디로 최대한 빠르게 롤백할 수 있어야 한다는 뜻이다.
소프트웨어 벤더사와 대화하라
패키지 단위로 소프트웨어를 판매하는 회사가 아니라 지속적으로 소프트웨어를 배포하는 전략을 가진 회사와 계약을 맺기 전이라면 먼저 회사의 성공 사례와 관련된 이야기를 들어보는 것을 추천한다. 당연하지만 실패 사례도 가능하다면 듣는 편이 좋다. ‘당신들의 제품을 사용했을 때 고객들이 실질적으로 어떤 도움을 얻었고, 그것이 어느 정도의 매출 성장을 이루는 데 도움이 됐는가?’라고 단도직입적으로 물어보는 게 좋다. ‘새로 설치하다가 충돌을 일으키거나 호환이 안 돼서 문제가 됐던 적은 없는가?’도 필요한 질문이다. 그 외에 사용자들이 새 기능을 익히는 데 얼마나 시간이 걸리는지 등도 좋은 참고가 된다.
사실 완전히 처음 시장에 등장한 스타트업이 아니라면 대부분 소프트웨어 벤더사들은 사용자 기업들 사이에서 이런 저런 평판을 가지고 있다. 이 때 최악의 평판을 가진 회사들은 과감히 후보 명단에서 삭제하는 것을 추천한다. 하지만 여러 가지 이유로 악평을 가진 기업과 계약을 맺어야만 하는 경우라면 어떻게 해야 할까? 그럴 때는 해당 기업과 여러 문제가 발생했을 때를 대비해 책임을 지는 것과 관련된 계약서를 작성해야 한다. 일방적으로 불리한 계약서를 들이밀면 서명할 회사가 없으니, 이런 계약서 작성에 있어서도 상대 회사와의 꼼꼼한 대화가 필요하다.
글 : 메리 섀클릿(Mary E. Shacklett), 회장, Transworld Data
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-02] 
