공개소프트웨어

  • 공개소프트웨어
HOME > 공개소프트웨어
공개소프트웨어| 오픈소스 소프트웨어에 대한 기본 지식들을 제공합니다.
 
공개소프트웨어 도입유형형 위험평가
조회 : 1,261  


공개소프트웨어 도입유형형 위험평가

 

 

글쓴이 : 리눅스포탈(www.superuser.co.kr) 박성수(papa@superuser.co.kr)

공개소프트웨어를 도입하는 방법에는 크게 3가지가 있다. 도입하려고 하는 공개소프트웨어를 기관에서 직접 선택하는 직접선택 방법이 있고, 외부의 공개소프트웨어 개발업체로부터 도입하는 간접공급 방법이 있으며 나머지 하나는 기관내부에서 공개소프트웨어를 직접개발하여 도입하는 내부개발 방법이 그것이다.

  이번 절에서는 이 3가지 도입유형에 따른 도입시의 위험요소에 대하여 알아보도록 할 것이다. 참고로 위험요소에 따른 위험요소 완화방법과 대책에 대해서는 다음절에서 다루고 있으므로 확인하기 바란다.


ㅇ 직접선택 방법에 따른 위험 평가

  공개소프트웨어를 기관에서 직접 다운로드하여 도입하고자 하는 경우에는  비교적 많은 위험요소가 내재되어 있다. 물론 공개소프트웨어를 다운로드를 하는 것은 기관 내부의 직원에 의해 수행될 것이다.

  가장 먼저 주의해야 할 사항은 다운로드한 공개소프트웨어가 정말 깨끗하고 믿을 수 있는 좋은 소프트웨어인가를 확인하기 전까지는 매우 불안한 요소를 내포하고 있을 가능성이 있기 때문이다. 이 말의 의미는 다운로드한 공개소프트웨어내에 트로이목마와 같은 바이러스 코드나 또는 키로거(key-logger)와 같은 악성 소프트웨어에 의한 감염된 소스등과 같은 악의적인 목적을 가진 소스코드가 내포되어 있을 가능성이 존재하기 때문이다.

  그리고 앞 절에서도 살펴보았던 문제이지만 직접 다운로드한 소프트웨어에 대해서는 보상과 보증이 명확하지 않고 보장되지 않는다는 점이다. 즉, 공개소프트웨어 솔루션을 기관내부에서 직접선택하여 도입하려고하는 경우에는 소프트웨어의 보증과 보상을 보장받지 못하는 위험요소가 존재한다.

  또 다른 위험요소는 공개소프트웨어의 배포정보에 대한 부분이다. 즉, 공개소프트웨어를 지속적으로 업그레이드해서 배포해야한다는 의무적인 사항은 그 어디에도 존재하지 않는다. 따라서 오늘 다운로드한 공개소프트웨어가 내일은 배포되지 않을 수도 있고 또한 어떠한 공지사항 없이 배포위치가 바뀔 수 있기 때문이다. 따라서 공개소프트웨어를 직접 다운로드하여 도입하는 기관에서는 배포처나 개발프로젝트에 대한 위험요소 감소대책을 확보해야한다.

  그리고 어떤 공개소프트웨어에도 존재할 수 있는 공통적인 위험요소로는 기술지원에 대한 위험요소이다. 특히 공개소프트웨어를 직접 다운로드하여 도입한 기관에서는 자체 기술지원시스템을 확보하고 있거나 또는 위부 지원업체에 대한 다양한 정보를 확보하고 있어야 한다. 어쨌든 직접 다운로드하여 도입하는 공개소프트웨어에 대해서는 더욱 적극적이고 명확한 기술지원에 대한 위험요소 감소대책을 확보해야 한다.


ㅇ 간접공급 방법에 따른 위험 평가

  이번에는 간접공급 방법으로 도입하는 공개소프트웨어에 대한 위험요소들에 대해서 알아보자. 먼저 간접공급에 의한 공개소프트웨어 도입이란 무엇을 의미하는 것인가? 앞장에서 설명드렸듯이 공공기관에서 공개소프트웨어를 외부업체를 통해 공급하는 것을 의미하는 것으로서 공공기관에서 직접선택하는 앞의 방법보다는 위험요소가 다소 감소될 수 있는 방법이다. 즉, 외부업체를 선택하여 선택한 업체에서 공개소프트웨어를 공급하는 것으로 기술지원과 서비스 비용을 지불해야하기 때문에 비용적인 부담이 있기는 하지만 위험요소를 줄일 수 있다는 장점이 있다. 하지만 이 경우에도 공개소프트웨어의 도입에 따른 위험요소들이 존재하므로 이러한 위험요소들에 대하여 알아보자.

  먼저, 간접공급 방식에 의한 공개소프트웨어 도입은 라인센스에 대한 위험요소가 발생 할 수 있다.

  따라서 공급기업체에서 공급하는 공개소프트웨어에 적용되어 있는 라이센스가 어떤것인가를 명확하게 확인해야 한다. 누차 말해왔듯이 공개소프트웨어에 적용되어 있는 라이센스는 여러가지 종류가 있다. 이들은 필요에 의하여 그 환경과 요구사항에 맞도록 만들어진 것들이며 많은 부분에서 그 내용을 달리하는 경우가 있다. 따라서 도입하는 간접방식으로 공급되는 공개소프트웨어 공급계약서내에는 라이센스에 대한 명확한 언급이 있어야만 한다. 물론 도입기관의 담당자는 그 라이센스의 내용에 대하여 명확하게 숙지해야 한다.

  그리고 외부 업체에서 공급하는 간접공급방식에서의 또 다른 위험요소로는 하자보증에 대한 부분이다.

  1차적으로는 공급한 업체는 하자보증에 대한 지원을 해야하며 또한 책임을 져야하지만 공개소프트웨어의 GPL라이센스가 적용된다면 근원적인 문제점에 대해서는 공급업체에서 보증에 대한 책임을 회피할 수 있다는 위험요소가 발생한다. 따라서 공개소프트웨어를 도입하는 기관 담당자는 보증에 대한 위험요소에 대한 대비책을 세워두어야 한다. 이는 다음 절에서 상세히 다루고 있으므로 참고 바란다.

그리고 간접방식으로 공급되는 공개소프트웨어에 대한 위험요소에는 일반적인 공급계약방식에서 발생할 수 있는 거의 모든 위험요소가 고려되어야 한다.

즉, 공급업체의 적격성에 대한 위험성 평가, 시스템의 확장성 가능여부에 대한 위험요소 평가, 소스코드의 성숙도 및 신뢰도에 대한 위험요소 평가등이 모두 고려되어야 한다.

  마지막으로 간접방식에서는 외부 공급업체의 기술지원 능력에 대한 위험요소가 존재한다. 즉, 공급업체의 기술지원 능력에 대한 객관적인 검증없이 공개소프트웨어를 도입하였다면 도입 이후의 기술지원 문제가 발생할 수 있다는 점을 명심해야 한다. 아울러 공급업체의 파산등으로 기술지원을 받지 못하는 사태가 발생할 수 있으므로 동일 솔루션의 기술지원업체에 대한 정보를 확보해 두는 것도 공급업체에 대한 위험요소를 줄이는 방법이 되기도 한다.

 

ㅇ 내부개발 방법에 따른 위험평가

  마지막으로 공개소프트웨어를 기관내부의 직접적인 개발에 의한 위험요소에 대하여 알아보자. 공개소프트웨어를 도입하기 위한 내부개발 방법은 이미 개발되어 있는 공개소프트웨어들 가운데 도입용도에 가장 적합한 공개소프트웨어를 선택하여 이를 가져와서 기관 내부 개발자가 직접 개발하는 것을 의미한다.

  따라서 이러한 내부개발 방법에는 몇가지 위험요소를 내포하고 있으며 위험요소들을 분석함으로써 개발 소프트웨어의 안정성과 영속성을 보장할 수 있다. 다음은 내부 개발방법에 따른 위험요소 리스트이다.

- 다운로드한 공개소프트웨어의 안정성 검토
- 개발된 공개소프트웨어의 라이센스 문제
- 개발된 공개소프트웨어의 안정성과 영속성 문제
- 내부 개발자의 개발능력 문제
- 개발후 문서화 작업문제등

  앞절에서 이미 설명하였듯이 기관 내부에서 공개소프트웨어를 개발하기 위해서는 이미 배포되어 있는 공개소프트웨어들 가운데 가장 적합한 공개소프트웨어를 우선 선택하는 작업을 해야한다. 이때 발생할 수 있는 위험요소는 선택하는 공개소프트웨어의 안정성과 적합성을 검토해야 한다. 즉, 다운로드하는 공개소프트웨어 소스내부에 악의적인 코드가 들어있지 않는가를 확인해야하며 또한 개발하고자 하는 소프트웨어의 목적에 가장 적합한 소프트웨어인가를 검토하는 작업을 해야한다. 만약 이 과정에서 잘못 선택되어진다면 돌이킬 수 없는 과오를 남기게 된다. 특히 공공기관의 업무에 적용하기 위한 소프트웨어이기에 공공정보 유출과 같은 극단적인 위험요소가 존재한다 .

  다음은 다운로드하는 공개소프트웨어에 적용되어 있는 라인센스, 그리고 개발완료 후에 적용할 라이센스 문제를 검토해야 한다. 개발 전에 공개된 공개소프트웨어를 다운로드할 때에 소스확보가 가능한지, 소스수정이 가능한지, 그리고 소스 수정후에 업무에 적용가능한지, 유관기관에 이를 재배포할 수 있는 재배포 권한이 있는가에 대한 면밀한 검토가 도입 전에 이루어져야만 한다. 만약 이에 대한 정확한 검토작업없이 추진하였다면 개발완료되었을 때에 업무적용 및 활용, 배포에 심각한 문제가 발생할 수 있다는 위험요소를 가지고 있으므로 주의해야 한다.

  다음은 개발된 공개소프트웨어의 안정성과 영속성에 대한 문제이다. 바로 앞에서 언급한 라이센스 문제와 일부분 결부되는 문제이지만, 소프트웨어의 안정성문제는 소스코드의 성숙도측면에서 고려되어야 한다. 그리고 소프트웨어의 영속성 문제는 시스템증설이나 향후 업그레이드시에 재활용 및 재사용이 가능한가라는 확장측면에서 고려되어야 할 문제이다. 따라서 소프트웨어의 안정성부분에 따르는 위험요소와 향후 확장 및 증설측면에서의 영속성에 따르는 위험요소도 고려되어야 한다.

  다음으로 개발에 투입될 내부 개발자의 개발능력에 대한 사전 검토와 검증작업이다. 앞서 언급하였듯이 실제 개발직원은 기관내부 직원이 될 수도 있겠지만 특정 부분에 대해서는 외부 개발자를 프로젝트 기간동안에 투입하는 것도 좋은 방법이 될 수 있으므로 이를 고려사항에 넣도록 한다. 하지만 내부 개발자이든 외부에서 영입한 개발자이든 개발자에 대한 개발능력에 대한 검증이 이루어져야 한다. 소프트웨어 개발은 누가 어떠한 방법으로 개발하느냐에 따라서 실행속도와 소스코드의 완성도 및 성숙도에 매우 큰 차이가 발생한다. 따라서 프로젝트에 가장 적합한 개발자를 투입하는 것을 최종 목표로하되 프로젝트 관리자(PM : Project Manager)의 적합성도 함께 고려되어야 한다.

  그리고 개발완료된 이후에 개발된 공개소프트웨어에 대한 문서화 작업을  해야한다. 문서화 작업은 크게 두가지로 나누어서 이루어져야하는데 첫번째는 소스코드에 대한 문서화 작업, 두번째는 소프트웨어 사용에 대한 문서화 작업이 그것이다. 첫번째 소스코드에 대한 문서화 작업은 소스코드의 재사용, 업그레이드 및 패치, 향후증설작업등을 위하여 소스코드에 대한 자세한 설명과 함께 수정방법등에 대한 문서를 의미한다. 이 문서화 작업은 처음개발했던 개발자를 위해서이기도 하지만 다른 개발자가 보았을 때에 도움이 되도록 작성되어야 한다. 두번째 사용법에 대한 문서화 작업으로써 이는 개발완료 이후에 업무에 적용하여 사용자들이 이를 원활하게 사용할 수 있도록 사용법문서등을 의미하는 것이다. 즉, 설치문서, 사용법문서등을 의미한다. 이와같은 문서화 작업이 제대로 이루어져 한다. 왜냐하면 개발된 소프트웨어의 확장성과 활용성에 따르는 위험요소가 발생할 수도 있기 때문이다.


[원글링크] : https://www.linux.co.kr/home2/board/subbs/board.php?bo_table=lecture&wr_id=1013


이 글을 트위터로 보내기 이 글을 페이스북으로 보내기 이 글을 미투데이로 보내기

 
박성수
파파
헐렁고수