공개소프트웨어

  • 공개소프트웨어
HOME > 공개소프트웨어
공개소프트웨어| 오픈소스 소프트웨어에 대한 기본 지식들을 제공합니다.
 
공개소프트웨어 도입시 위험요소 분석
조회 : 1,305  


공개소프트웨어 도입시 위험요소 분석

 

 

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

 

가. 경쟁 유효성

  공개소프트웨어 도입시에는 여러가지 위험요소들이 존재한다. 이번 장에서는 이런 공개소프트웨어의 위험요소들에 대하여 몇가지 분류로 나누어서 살펴보고자 한다. 즉, 공개소프트웨어의 경쟁 유효성에 대한 위험분석과 기술 및 유지보수, 그리고 소스자체에 대한 보증문제등에 대한 위험분석, 그리고 소스코드의 가용성에 대한 위험분석등을 살펴볼 것이다.

  공개소프트웨어를 도입함에 있어 존재하는 위험요소들과 공개소프트웨어를 도입하기를 망설이게 되는 여러가지 도입 저해요소들과는 다소 상관관계가 존재한다. 먼저 본 가이드의 앞부분에서 다루었던 도입 저해요인들 가운데 경쟁 유효성에 관한 위험요소에 관련된 항목들을 간단히 정리해 보면 다음과 같다.

- 공급업체의 신뢰성과 경쟁력 확보 여부
- 도입하는 공개소프트웨어 자체의 경쟁력 확보 여부
- 기능성 및 사용편의성등에 대한 경쟁력 확보여부
- 비용절감의 경쟁력 확보 여부등

  첫번째로 공급업체가 자체적인 경쟁력뿐아니라 대외적인 경쟁력을 확보하였는가의 여부에 따라서 위험요소가 존재한다.

  이 부분은 공급업체의 신뢰성이 우선 바탕이 되어야하며 신뢰성을 기본으로하여 두가지의 경쟁 유효성을 검증해야 한다. 첫번째는 공급업체 스스로가 내부와 외부의 경쟁력을 확보하고 있는가에 대한 것이다. 두번째는 공급되는 특정 공개소프트웨어를 기술지원할 수 있는 업체들이 다수 존재하여 이들 업체들이 상호 경쟁력 확보를 하고 있으며 도입기관에서 기술지원 요청을 할 수 있는 다수 기업체가 존재하는가에 대한 것이다. 즉, 두번째는 공급받는 공개소프트웨어에 대한 영속성 확보를 위한 위험요소 감소가 그 목적이라고 할 수 있다.

  두번째로 도입하는 공개소프트웨어 자체의 경쟁력에 대한 부분이다.

  공개소프트웨어뿐 아니라 어떤 소프트웨어이든 도입되기 위해서는 동일 분야의 타 제품보다 확실한 경쟁력이 확보되어야 한다. 즉, 이 문제는 도입하려고 하는 공개소프트웨어 자체의 경쟁력이 있는가에 대한 것이다. 만약 도입한 이후에 보다 나은 소프트웨어를 찾게 된다면 도입자체를 재검토해야하는 심각한 문제가 발생하게 된다. 따라서 이러한 위험요소를 줄이기 위하여 공개소프트웨어 자체에 대한 경쟁력확보 여부를 반드시 확인해야 한다.

  세번째는 도입하는 공개소프트웨어의 사용자측면의 UI(User Interface)와 기능적인 경쟁력이 있는가에 대한 것이다. 즉, 이것은 도입되는 공개소프트웨어에 사용상의 편리성과 기능상의 우수성에 대한 경쟁력을 확보하고 있는가에 대한 것으로써 아무리 훌륭한 소프트웨어라 하더라도 사용이 불편하고 기능적인 면이 만족스럽지 못하다면 장기적인 활용을 확신하기가 어렵기 때문이다. 따라서 이러한 위험요소를 줄이기 위하여 도입단계에서 UI측면과 기능적인 면을 면밀히 검토해야 한다는 것이다.

  네번째는 공개소프트웨어 도입욕구의 가장 대표적인 매력이라고 할 수 있는 비용절감에 대한 경쟁력 확보이다. 공개소프트웨어를 비용절감 없이 도입한다는 것은 누가 보아도 명분이 없을 것이다. 즉, 공개소프트웨어의 도입 이유는 매우 많다. 비용절감뿐아니라 확장성, 영속성등 여러가지가 존재한다. 만약 공개소프트웨어를 도입하였는데 타소프트웨어 보다 비용(전체적인 TCO측면)이 더 많이 든다면 공개소프트웨어 도입자체를 재고해야하는 상황이 발생한다. 따라서 그 어떤 경쟁력보다도 비용 경쟁력을 확보해야 한다.

  그리고 기존 시스템에 공개소프트웨어를 도입할 때에는 인적 기술력과 업체의 기술지원 경쟁력을 확보해야 할 것이다. 즉, 기존 정보시스템, 기존 소프트웨어와의 호환성 및 기능의 제약등 기술적 제약 요건을 분석해야 한다. 즉, 기존 시스템에 공개소프트웨어를 도입함으로 발생하는 문제점(H/W와의 낮은 호환성, S/W의 성능 저하 등)을 해결할 만한 인력이 부족할 수도 있다. 그리고 공개소프트웨어를 제공하는 기업체들이 제품의 성실한 제작, 적극적인 기술지원과 교육을 통해 해결해 나간다면 크게 문제가 되지 않을 것이다. 즉, 공개소프트웨어 수요자는 기술지원과 책임소재가 분명한 업체를 선택할 것은 너무나도 자명하기 때문이다.

 

나. 보증문제

  공개소프트웨어와 독점공급되는 상용소프트웨어는 보증문제에 있어서도 큰 차이점이 있다. 독점공급되는 상용소프트웨어는 구매시에 보증문제가 이미 언급되어 있고 계약서에도 대부분 명시되어 있다. 하지만 공개소프트웨어는 보증에 대해서 다소 분명하지 못한 점이 있다.  이를 확실히 알아보기 위하여 GPL의 제12항과 제13항을 확인해 보기로 하자.

12.

본 라이센스에 의한 프로그램은 무상으로 양도되므로 관련법이 허용하는 한도 내에서 어떠한 형태의 보증도 제공하지 않는다. , 프로그램의 저작권자와 제3의 배포자에 의해서 공동 또는 개별적으로 특정한 목적에 대한 프로그램의 적합성여부를 검증하기 위한 경우나 상업적 판매에 따른 별도의 보증이 제공된다는 사항이 서면으로 명시되어 있는 경우는 예외로 한다. 그러나 이러한 경우에도 해당 프로그램 자체가 갖고있는 근원적인 보증의 결여를 제한할 수는 없다. 프로그램과 프로그램의 실행에 따라 발생할 수 있는 위험은 모두 피양도자에게 인수되며 이에 따른 보수 및 복구를 위한 제반경비 또한 모두 피양도자가 부담한다.

 

13.

저작권자나 제3의 배포자가 프로그램의 손상 가능성을 사전에 알고 있었다 하더라도 발생된 손실이 관련 법규에 의해서 보호되고 있거나 저작권자나 프로그램 자체에 대한 보증을 제공하지 않는다는 전제로 프로그램과 개작된 프로그램을 함께 또는 개별적으로 공급한 배포자가 서면으로 별도의 보증을 설정한 경우가 아니라면 프로그램의 사용이나 사용상의 미숙으로 인해서 발생된 손실은 모두 피양도자의 책임이다. 발생된 손실의 일반성이나 특수성뿐만아니라 원인의 우발성 및 필연성도 고려되지 않는다.

  위의 내용을 보면 알수 있듯이 GPL라이센스로 제공되는 모든 공개소프트웨어의 문제발생에 대한 책임은 원칙적으로는 수요자에게 있다는 것을 알 수 있다. 물론 공개소프트웨어를 도입하는 기업과 수요자 사이에 보증에 대한 별도의 계약관계가 있다면 보증에 대한 문제가 어느정도 해결 될 수는 있을 것이다. 하지만 GPL에서는 공급자와 수요자 사이에 보증에 대한 별도의 계약을 하였다하더라도 근원적인 보증의 결여를 제한할 수는 없다고 명시하고 있다.

  그렇다면 공개소프트웨어를 도입하려는 수요자의 입장에서는 다음과 같은 의문점을 가지게 된다.

  많은 장점이 있다고는 하지만 공급자가 확실히 보증하지 않는 공개소프트웨어를 어떻게 믿고 도입해야 하는가?

  공개소프트웨어의 보증에 대한 문제의 출발점은 여기서 부터 출발한다. 즉, 이번 절에서는 공개소프트웨어를 도입하면서 어떻게 하면 보증의 결여에 대한 대책을 세우고 안정되고 영속성있는 공개소프트웨어를 도입할 것인가에 대하여 살펴볼 것이다.

  이러한 공개소프트웨어의 보증의 결여에 대한 근본적인 원인은 공개소프트웨어가 공급자의 소유가 아닌 프로젝트의 산출물이기 때문이다. 물론 많은 이유가 존재하겠지만 공동의 프로젝트에 의하여 공동개발된 소프트웨어이기 때문이며 이는 결코 보증의 결여에 대한 문제가 단점으로만 작용하고 있는 것은 아니다. 즉, 많은 개발자들에 의해 자발적인 공동개발 산물이라는 것은 문제발생시에 빠른 보완능력을 그 자체로서 가지고 있기 때문이다.

  따라서 공개소프트웨어의 보증의 결여에 대한 문제해결의 실마리 또한 여기서 출발한다.

- 공동프로젝트의 산출물인 A라는 공개소프트웨어가 있다.
- 그리고 B라는 공개소프트웨어 공급업체가 있다.
- 그리고 C라는 공개소프트웨어를 도입하려는 공공기관이 있다고 가정해 보자.

공공기관C는 공개소프트웨어를 도입하기로 최종 결론을 내리고 공개소프트웨어 공급업체 B와 계약하여 A라는 공개소프트웨어를 GPL라이센스를 적용하여 공급받기로 하였다.

자, 여기서 B와 C의 계약서 작성시에 보증문제에 대하여 공공기관C가 주의해야 할 것이 있다. 공개소프트웨어 A의 근원적인 문제에 대해서는 보증을 받을 수 없지만 공개소프트웨어 A를 공동개발하는 프로젝트내에서 근원적인 문제가 해결되어 패치버전이 나온다면 B는 즉시 이를 적용하여 도입한 공개소프트웨어를 개선해야한다는 내용을 반드시 계약서에 삽입해 두어야 한다.

  즉, 이는 근원적인 문제를 원천적으로 해결해야한다는 조건이 아니라 근원적인 문제에 대한 해결이 이루어 졌다면 공급업체에서 도입한 공개소프트웨어에 이를 즉시 적용하여 개선해야 한다는 의미이다. 바로 이것이 공개소프트웨어를 도입할 때에 공공기관C가 가장 우선적으로 검토해야 할 보증문제의 기본적인 해결책이다.

  자, 그럼 이제 공개소프트웨어의 보증에 대한 문제를 다른 측면에서 살펴보도록 하자.

  앞서 살펴본 특정 공급업체로부터 공급받았을 경우에 보증의 문제가 발생하지만 업체로 부터 공급받지 아니하고 공개소프트웨어를 도입하기 위하여 무료다운로드를 제공하는 사이트에서 직접 다운로드를 하였을 경우에도 다운로드한 소프트웨어의 보상과 보증은 전혀 이루어 지지 않는다. 따라서 이에 대한 위험요소의 대책도 세워야 한다.

  즉, 특정한 사이트에서 다운로드를 받은 공개소프트웨어에 대한 가장 기본적인 대책은 배포처 사이트의 주소뿐아니라 다운로드한 공개소프트웨어에 대한 상세정보를 확보해야 한다. 즉, 공개소프트웨어의 프로젝트 진행자 또는 개발자, 또는 개발 배포회사에 대한 가장 기본적인 정보를 의미한다.  이렇게 확인해 두어야만 배포사이트의 주소가 바뀌거나 프로젝트 진행자가 바뀌거나 또는 개발자, 배포회사가 사라지더라도 최소한의 문제해결 실마리는 얻을 수 있기 때문이다. 이것은 무료 다운로드한 공개소프트웨어의 위험요소를 줄이기 위한 최소한의 조치인 것이다.

  그리고 보증의 문제에 대한 도입기관의 또 다른 대책으로는 지역내에 가능한 많은 공개소프트웨어 지원업체를 알아두어야 한다는 것이다. 공개소프트웨어를 공급한 업체가 사라지거나 또는 기술지원을 중단하더라도 지속적인 보증과 지원을 받을 수 있는 가능성이 높아지기 때문이다. 이것은 도입기관에서 자체적으로 개발하여 도입하는 경우에도 해당된다. 즉, 기관내부에서 공개소프트웨어를 자체 커스터마이징하여 도입하는 경우에도 외부의 지원업체를 많이 알아 두는 것이 안정성과 영속성을 높이기 때문이다.

  이와 같이 보증에 대한 여러가지 안정장치들은 공개소프트웨어가 핵심적인 업무에 도입되는 경우에 가장 큰 효과를 얻을 수 있다.

  지금까지 설명한 공개소프트웨어의 보증의 결여에 대한 위험요소를 감소시키려면 공개소프트웨어의 도입시 기본적인 조건이 충족되어야 한다. 이는 보증의 결여에 대한 대책이 아니라 지금까지 설명한 보증결여에 대한 대책 수립을 위한 전제조건이다.

  먼저, 도입하는 공개소프트웨어의 라이센스가 명확해야 한다. 물론 거의 대부분 GPL로 도입이 되겠지만 공개소프트웨어에 적용되는 라이센스의 종류가  많기 때문이며 이들은 필요에 의해 수정되거나 새로 만들어진 것이므로 GPL과는 다른 부분들이 존재한다. 따라서 도입하는 공개소프트웨어에 적용되어 있는 라이센스와 그 내용을 꼼꼼이 확인해 보아야 한다.

  하지만, 어떤 라이센스를 적용하든 도입하는 공개소프트웨어에 대한 완전한 권리를 획득하기 위해서는 소스코드의 확보와 수정권한 그리고 수정 후 이를 재사용하고 확장할 수 있는 권한을 모두 획득해야 한다. 이는 공개소프트웨어의 보증문제를 해결하기 위한 가장 기본적인 조건이다. 물론 당연한 것이기는 하지만 만약 이 조건이 만족되지 않는다면 공개소프트웨어의 도입자체부터 재검토해야하며 도입된다 하더라도 보증문제는 전혀 보장되지 않는다고 보아야 한다. 따라서 소스코드에 대한 권리는 반드시 확인해 보아야 한다.

  그리고 보증문제에 대하여 한가지 더 확인해 두어야 할 것은 도입하는 공개소프트웨어에 대한 기술문서, 사용자지침서, 온라인 튜토리얼, 교육훈련등에 대한 확보이다. 이절의 앞부분에서 말씀드렸듯이 공개소프트웨어의 보증에 대한 보장은 1차적으로 공급업체에서 이루어져야하겠지만 불가피하게 보증문제가 발생하였을 경우에는 기술문서등과 같은 문서들이 확보되어 있어야만 해결이 가능하기 때문이다.

 

다. 소스코드의 가용성

  공개소프트웨어를 도입함에 있어 발생할 수 있는 위험요소들 가운데 경쟁유효성과 보증문제에 대한 위험요소들에 대하여 살펴보았다. 이번에는 공개소프트웨어의 소스코드에 대한 위험요소들이 어떤것들이 있는가에 대하여 살펴보자. 즉, 이번 절에서는 소스코드의 가장 핵심적인 요구조건인 가용성에 대하여 살펴볼 것이다. 첫번째 소스코드 자체의 확보여부, 소스코드의 수정 및 수정후의 재사용, 확장성 보장등과 함께 소스코드 자체로서 경쟁력을 가지고 있는지 그리고 향후 확장성을 보장할 수 있도록 코딩되어 있는지, 소스코드의 수정시에 어떤 개발자라도 수정작업이 용이하도록 보장되는지, 그리고 여러 루틴들이 상호 유기적으로 표준화되어 코딩되었는가를 검토해 보아야하며 이러한 부분들이 보장이 되어야만 소스코드 자체의 경쟁력과 가용성을 보장받을 수 있다.

- 소스코드의 확보
- 소스코드의 수정 가능성 확보
- 수정한 소스코드의 재사용, 확장성, 재배포 가능성 확보
- 확장 / 수정 용이성
- 소스코드의 표준화

  공개소프트웨어로 도입하는 소프트웨어의 소스코드는 많은 측면에서 보장되어야 한다. 만약 독점 공급되는 상용소프트웨어라면 소스코드 자체를 확보하기가 거의 어렵기 때문에 이러한 점들을 고려할 필요가 없겠지만 공개소프트웨어는 소스코드가 소프트웨어를 공급받을 때에 소스코드를 함께 공급받기 때문에 이에 대한 가용성 문제를 검토해 두어야 한다. 이는 소스코드의 재사용에 관련된 가용성 확보를 위해 필수적인 것이다.

  먼저 여러차례 언급하였던 소스코드 자체를 확보해 두어야한다는 점이다. 만약 소스코드를 확보하지 못했다면 이후의 모든 사항들이 모두 가능하지 못하므로 소스코드 가용성의 전제조건이라고 할 수 있다. 다행스럽게도 GPL을 포함한 대부분의 공개소프트웨어 라이센스에는 소스코드를 공개해야 한다는 조건이 있으므로 간단한 확인만으로도 소스코드 확보는 어렵지 않다.

  두번째, 소스코드 확보여부 뿐아니라 확보된 소스코드를 수정할 수 있는 권한이 있는가를 반드시 확인해야 한다. 물론 앞서 언급한 대부분의 공개소프트웨어 라이센스에는 수정권한이 있다고 명시되어 있다. 하지만 공개소프트웨어를 공급받을 당시에 또는 직접 다운로드를 할 당시에 소스코드 자체의 확보여부와 함께 수정권한의 여부를 확인하기 바란다.

  세번째, 소스코드에 대한 재사용, 확장성, 재배포 권한여부를 확인해야 한다. 즉, 소스코드를 확보할 수 있고 소스코드를 수정할 수 있는 권한과 함께 수정한 소스코드를 다시 재사용할 수 있는 권한 즉, 시스템확장에 재사용할 수 있는 권한, 그리고 다시 이를 재배포할 수 있는 권한이 있는가를 확인해야 한다.

  앞에서 언급한 3가지 조건이 소스코드 가용성의 전제조건이다. 즉, 소스코드의 확보, 수정권한, 재사용권한이 소스코드의 가용성에 대한 기본조건이 된다는 의미이다.

  결론적으로 소스코드의 가용성에 대한 위험요소를 줄이기 위해서는 도입시 이 3가지가 전제되어야 한다는 것을 알 수 있다.

  그리고 다음으로는 소스코드의 확장 및 수정의 용이성 또한 가용성에 포함이 된다. 즉, 소스코드를 수정 및 재사용할 수 있는 권한뿐아니라 수정 및 확장의 용이성이 검토되어야하며 이 또한 소스코드의 가용성을 높이는 조건이 된다.

  그리고 소스코드의 확장 및 수정이 용이하려면 소스코드가 표준화되어 있어야한다. 이 또한 소스코드의 가용성을 높이는 것으로써 표준화되어 있는 소스코드는 가독율이 좋으며 개발자가 달라지더라도 수정이 용이해지기 때문이며 또한 소스코드를 확장하기에 매우 유용하기 때문이다. 따라서 소스코드의 표준화는 가용성을 높이는데 매우 큰 역할을 한다.


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


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

 
박성수
파파
헐렁고수