<B0F8B0B35357B0A1C0CCB5E C1A4BAB8C5EBBDC5BACE292E687770>

Transcription

1 공개소프트웨어 가이드 A Guide to Open Source Software 정보통신부

2 공개소프트웨어 가이드 요 약 문 1. 제 목 "공개소프트웨어 가이드" 발간 2. 발간의 목적 및 필요성 본 가이드의 목적은 공개소프트웨어 대한 이해를 높이고 공개소프트 웨어에 대한 우려와 현실을 객관적으로 분석하여 공개소프트웨어 도 입시 필요한 검토사항 및 위험요소 분석, 관리방안 등을 수립하는데 도움을 주기 위함이다. 3. 주 요 내용 제1장 "서론"에서는 공개소프트웨어의 이해를 높이기 위한 부분으 로써 공개소프트웨어의 정의, 역사, 그리고 비공개소프트웨어와의 비 교분석을 다루고 있으며 또한 현재 국내 공개소프트웨어 비즈니스 모 델에 대한 소개와 관련업체들에 대해 다루고 있다. 1950년대부터 본 격적으로 시작된 소프트웨어는 그 당시의 여러 가지 의미와 개념들이 지금과는 사뭇 다른 모습을 하고 있다는 것을 알게 된다. 공개소프트웨어에 대한 정확하고 객관적인 정의와 소프트웨어 산업 적인 측면의 의미를 이끌어 내기 위하여 공개소프트웨어를 역사적인 관점으로 정리하였다. 그리고 공개소프트웨어 또는 자유소프트웨어 그리고 비공개소프트웨어, 독점소프트웨어, 사유소프트웨어 등 혼란스 러운 여러가지 용어들에 대하여 설명하고 이를 간략하게 정리하였다. - i -

3 공개소프트웨어 가이드 또한 비공개소프트웨어와의 차이점을 비교분석하고 분석결과를 간 략하게 도표로 정리하였으며 공개소프트웨어를 보다 객관적으로 이해 하는데 도움이 되도록 하였으며, 공개소프트웨어 기반의 비즈니스모 델을 소개하고 국내 공개소프트웨어 관련 산업에 대해 간략하게 분류 하고 소개하였다. 제2장에서는 공개소프트웨어에 대한 불필요한 오해들에 대하여 사 실과 진실을 객관성 있게 전달하고 있으며 크게는 공개소프트웨어의 비용에 대한 부분, 기술지원 및 가용성 부분, 소프트웨어 신뢰도 부분 그리고 완성도 및 수명의 4가지 부분으로 나누어서 오해에 대한 진실 을 정확하게 전달하고 있다. 공개소프트웨어의 라이센스 비용에 대해서는 주로 도입 시 발생하 는 라이센스 비용과 총소유비용(TCO)에 대해 잘못 이해할 수 있는 부분을 설명하였다. 특히 "자유소프트웨어"라는 용어의 "자유"라는 단 어에서 비롯되는 여러 가지 불필요한 오해들(경제적인 무비용(free)이 라는 의미와 자유롭다는 의미의 자유 등에 대한 오해들)에 대하여 보 다 정확한 의미전달을 하고 있다. 또한 공개소프트웨어의 사상(자본 주의와 공산주의)적인 오해에 대해서도 간략하고 분명하게 진실을 이 야기하고 있다. 그리고 공개소프트웨어의 기술지원 및 가용성 부분의 불필요한 오 해들에 대해서도 진실을 전달하고 있으며 특히 기술지원부분에서 무 조건적으로 신뢰하지 않는다는 것은 그 만큼 공개소프트웨어에 대해 정확히 인지하지 못하였다는 것을 의미하며 인지하지 못한 만큼 또한 오해하고 있었다는 것을 의미한다. - ii -

4 공개소프트웨어 가이드 제3장 "공개소프트웨어 도입유형 및 절차"에서는 3가지 도입유형 (직접선택, 간접공급, 내부개발)을 설명하였으며 특히 현실적으로 가 장 일반적이고 보편적인 도입방법인 간접공급에 대해서 특징, 장점, 단점 등을 깊이 있게 설명하고 있다. 그리고 일반적인 정보화사업 추진절차에 준하는 시스템 및 소프트 웨어 도입절차에 따른 표준화, 객관화를 위한 검토사항들을 설명하고 있다. 특히 소프트웨어 도입 시에 제안요청서상의 특정 운영체제 명 시, 특정 스펙명시, 특정 조건을 제시하는 등의 비표준, 불공정 소지 가 있는 부분에 대하여 객관성과 공정성 유지 방안을 제시하, 공공기 관의 정보시스템 구축시 필요한 고려사항과 실제 공개소프트웨어 기 반으로 시스템 적용에 필요한 권고사항을 설명하였다. 또한 공개소프트웨어를 도입하기로 결정하였을 경우에 어떠한 부분 을 고려해야하는가에 대한 "공개소프트웨어 도입 시 고려사항"들을 현실적인 부분을 고려하여 10여 가지 부분으로 나누어 자세히 설명한 다. 제4장 "위험분석 및 관리"편에서는 공개소프트웨어 도입에 따르는 위험요소 분석과 관리방법들을 다루고 있으며 "경쟁 유효성", "보증문 제", "소스코드 가용성"이라는 3가지 부분의 위험요소를 분석하고 이 를 관리하는 방안을 제시하였다. 경쟁 유효성 부분에서는 공급업체의 신뢰성과 경쟁력 확보여부, 공개소프트웨어 자체의 경쟁력 확보여부, 기능성 및 사용 편의성 등에 대한 경쟁력 확보여부, 비용절감의 경쟁 력 확보 여부 등을 주로 다루었다. - iii -

5 공개소프트웨어 가이드 그리고 보증문제는 라이센스와 법적인 문제까지 결부될 수 있는 매 우 민감한 사안으로써 보증의 결여에 따른 도입기관의 대처문제, 도 입하는 공개소프트웨어의 라이센스 문제 등에 대해서도 상세히 설명 하였다. 그리고 도입 시 소스코드를 확보해야하는 것은 물론 소스코드의 확 보와 함께 수정 및 재사용, 재배포 권한 문제등도 함께 검토되어야 한다. 도입하는 공개소프트웨어의 소스코드를 확보하지 못하였거나 수정권한을 얻지 못하였거나 재사용권한을 확보하지 못하였을 때에는 패치 및 업그레이드를 하지 못하는 상황이 발생 가능하다. 결국 이로 인하여 확장성, 영속성, 안정성 등이 보장되지 않을 수도 있다. 그리고 위험 관리방법과 위험 완화방법을 "도입 유형별 위험평가", "기술로드맵 평가", 위험완화를 위한 검토사항"으로 나누어 설명하였 다. 특히 직접선택 방법에서는 직원들의 개발능력이 검토되어야하며 프로젝트 수행경력과 능력이 있는 내부직원이 확보되어야 한다. 반면 간접공급방법에서는 공급업체의 신뢰성과 라이센스 문제를 고려하여 야 한다. 정부부처 등 공공기관은 간접공급 방식으로 도입하는 것이 가장 안정적인 공개소프트웨어 도입방식이며 이 때 비용이 발생하는 점을 고려해야 하며 이때, 공급업체의 기술지원 능력과 서비스 능력 도 함께 고려되어야 한다. 그리고 위험요소에 따른 위험완화를 위한 검토사항들이 있으며 이 들에 대하여 본문에서는 10 여가지의 검토사항들을 제시하고 있으며 공개소프트웨어를 도입하기로 하였다면 최소한 10 여가지의 검토사항 들은 기본 점검을 해야 한다. - iv -

6 공개소프트웨어 가이드 제5장에서는 공개소프트웨어의 법률문제를 다루었다. 공개소프트 웨어와 관련된 법률문제는 주로 라이센스로부터 발생하는 것이기 때 문에 GPL, LGPL, BSD License, MPL등 몇 가지 주요 라이센스에 대하여 알아두어야 한다. 그리고 이들 라이센스가 적용되었을 때에 발생하는 여러가지 법적인 문제들에 대해서도 설명하였으며 도입 후 재배포에 따른 유형별 법적문제들을 설명하고 있다. 공개소프트웨어의 라이센스 종류가 지나치게 많아지고 있다는 점을 사용자들은 매우 혼란스러워하며 또한 이에 대한 위험요소를 가중시 킨다고 불평하기도 한다. 하지만 라이센스의 수적 증가는 현실적인 요구에 의한 것으로써 공개소프트웨어가 활성화 될수록 이 요구는 더 욱 많아질 것이다. 이에 대한 OSI가 관리하고 있는 라이센스 리스트 에 추가되는 것을 현재로서는 막을 방법이 없다. 이보다 더한 위험요소는 법적문제 발생에 따른 GPL의 해석과 적용 범위의 문제이다. 즉, 계약의 성립여부와 그 계약의 유효성, 저작권과 계약의 관계, 준거법과 재판관할, 그리고 저작인격권, 전송권 등에 대 하여 해석과 적용범위를 명확히 해야 할 필요가 있다. 그리고 보증문 제에 따른 법적문제도 흔히 발생하는 것으로 도입 시에 주의해야 할 사항이다. 그리고 공개소프트웨어를 도입하고 이를 수정하여 확장적용하고 타 기관에 재배포하는 각각의 시나리오에 따른 법적문제도 검토되어야 한다. - v -

7 공개소프트웨어 가이드 4. 기 대 효 과 및 활 용 공개소프트웨어 도입과 활용은 점점 늘어가고 있다. 반면 도입기관 에서는 공개소프트웨어의 정확한 이해가 부족할 뿐 아니라 공개소프 트웨어의 도입방법과 그에 따르는 위험요소, 그리고 완화방법, 뿐만 아니라 공개소프트웨어의 라이센스 문제와 그에 따른 법적인 문제들 파악하고 싶어도 이에 대한 전문 안내서가 부족한 실정이다. 따라서 이 에 대 한 필요성이 제기되어 왔었다. 본 안내서는 이러한 요구환경 을 배경으로 제작되었으며 객관적인 시각을 통해 바라본 공개소프트 웨어의 진실들을 있는 그대로 전달하고자 노력하였다. 본 안내서는 기관들의 공개소프트웨어 도입에 따른 사전 지식과 도 입 후에 필요한 관리지식뿐 아니라 법적인 문제 발생 예방과 문제발 생시 대처능력을 확보하고 무엇보다 공개소프트웨어의 도입결정에 따 른 유용한 안내서 역할을 충실히 할 것으로 기대한다. - vi -

8 공개소프트웨어 가이드 <제목 차 례> 1장. 서 론 1 1. 공개소프트웨어의 이해 3 가. 공개소프트웨어의 기원과 역사 3 나. 공개소프트웨어 정의 7 다. 비공개소프트웨어와의 비교 8 2. 공개소프트웨어 산업 개관 13 가. 공개소프트웨어 비즈니스 모델 13 나. 공개소프트웨어 산업 현황 14 2장. 공개소프트웨어에 대한 오해와 진실 비용 문제 기술지원 및 가용성 공개소프트웨어의 신뢰도 완성도 및 수명 34 3장. 공개소프트웨어 도입유형 및 절차 도입유형 39 가. 직접선택 42 나. 간접공급 45 다. 내부개발 48 라. 종합비교 도입절차 적용시스템 57 가. 시스템 유형 57 - vii -

9 공개소프트웨어 가이드 나. 시나리오별 도입 방법 59 다. 적용 가능분야 고려사항 64 4장. 위험분석 및 관리 위험요소 분석 72 가. 경쟁 유효성 72 나. 보증문제 74 다. 소스코드의 가용성 위험관리 및 완화방법 80 가. 도입유형별 위험평가 80 나. 기술로드맵 평가 86 다. 위험완화를 위한 검토사항 89 5장. 법률문제 라이센스 유형 95 가. GPL 95 나. LGPL 98 다. MPL 98 라. BSD License 법적문제 100 가. 라이센스의 위험성 평가 101 나. GPL의 해석과 적용범위 103 다. 계약의 성립여부 및 유효성 105 라. 저작권과 계약의 관계 105 마. 특허 106 바. 상표 viii -

10 공개소프트웨어 가이드 사. 보증 책임의 범위 107 아. GPL로의 소스코드 공개방법 사용유형별 법적문제 검토 108 참 고 문 헌 113 부록1. 신뢰성이 높은 공개소프트웨어 121 부록2. 비공개 소프트웨어 대 공개소프트웨어 안내 129 부록3. 공개소프트웨어 리소스 140 부록4. GNU 일반 공중 사용 허가서(2판) ix -

11 공개소프트웨어 가이드 <표 차 례> <표 1> 비공개소프트웨어와 공개소프트웨어 비교 11 <표 2> 공개소프트웨어와 상용소프트웨어 비교 12 <표 3> 공개소프트웨어 도입 절차 44 <표 4> 직접선택방식 도입 전 체크리스트 45 <표 5> 공개SW도입방식에 따른 비교 52 <표 6> 공개SW도입을 위한 주요 검토 사항 53 <표 7> 비표준, 특정기술 조건 예 54 - x -

12 공개소프트웨어 가이드 <그 림 차 례> <그림 1> 공개소프트웨어 간접공급 유형 46 <그림 2> 웹기반 정보시스템 구조 59 <그림 3> 웹서버 운영체제 공개SW 도입 60 <그림 4> 웹서버, 웹 어플리케이션 서버 운영체제 공개SW 도입 61 <그림 5> 3계층 서버 운영체제 공개SW 도입 62 - xi -

13 1장. 서론 1장. 서 론 - 1 -

14 BLANK - 2 -

15 1장. 서론 1. 공개소프트웨어의 이해 가. 공 개 소 프 트 웨 어 기 원 과 역 사 공개소프트웨어는(Open Source Software) 1984년 자유소프트웨어 (Free Software)운동으로부터 분화하여 현재에 이르렀으며 1), 2000년 이후 전 세계의 정부기관과 민간단체에서는 공개소프트웨어의 효율성 과 발전성에 대하여 확고한 의지를 가지고 정책추진과 사업화를 시도 하고 있다. 국내에서도 2002년부터 공개소프트웨어 정책추진을 위한 본격적인 사업을 착수하여 현재 그 성과를 보이고 있다. 자유소프트웨어 운동(Free Software Movement)은 1984년 리차드 스톨만(Richard Stallman)이 GNU 2) 라는 공개프로젝트를 시작하면서 부터 시작되었으며 리눅스와 함께 자유소프트웨어 운동도 발전하였는 데, 이 과정에서 "자유(Free)"라는 용어에 대한 실용주의적 관점에서 의 비판이 이루어지고 공개소프트웨어 운동(Open Source Software Movement)이 시작되었다. 자유소프트웨어 운동 진영은 소프트웨어 자체는 항상 윤리적, 도덕 적, 사회적으로 타당해야함을 강조하면서 소프트웨어 사용자들에게 이를 바탕으로 한 사용상의 여러 가지 자유 3) 가 주어져 있음을 또한 강조하고 있다 4). 1) 자유소프트웨어와 공개소프트웨어는 그 역사를 함께 해오고 있으며 같은 개념으로 보는 견해도 있다. ( 참조) 2) GNU는 "Gnu is not Unix"의 재귀적 표현임 3) 여기서 자유는 첫째, 어떤 목적으로도 프로그램을 가동시킬 수 있는 자유 둘째, 필요에 맞 게 소프트웨어를 수정할 자유, 셋째, 무료 또는 유로로 복사본을 재배포할 수 있는 자유 넷째, 전체 공동체가 혜택을 볼 수 있도록 프로그램의 수정본을 배포할 수 있는 자유를 의미한다

16 공개소프트웨어 가이드 그리고 공개소프트웨어 운동 진영은 이념적 측면보다는 개발방식에 초점을 맞춘 접근을 취하고 공개소프트웨어 개발자에게도 경제적인 보상을 제공할 수 있어야 한다는 실용적 측면을 강조한다. 자유소프트웨어는 원칙에 입각한 소스코드의 자유로운 사용이라는 측면을 공개소프트웨어는 사회적 실용성과 경제성에 중심을 두고 소 스코드의 공개라는 측면을 강조한다고 할 수 있다. 공개소프트웨어가 정부의 정책에 반영되기 시작하고 일반인들에게 알려지기 시작한 것은 불과 몇 년 전 부터이다. 공개소프트웨어가 현 재에 이르기까지 어떻게 진화해 왔는가를 살펴보려면 먼저 그 역사를 살펴보아야한다. 공개소프트웨어에 관련된 주요한 사건들을 년대별로 간략하게 정리하였다. o 년 대 1950년대는 컴퓨터 프로그램의 초기 사용시기로써 모든 프로그램은 공개적으로 개발되고 또한 소스코드도 공개되었다. 즉, 여기서 중요 한 것은 컴퓨터 프로그램의 역사는 공개적으로 개발되기 시작하였고 또한 개발된 소스코드는 공개되었다는 점이다. 이러한 초기 인식이 약 10년 정도 계속되었으나 1950년대 후반부터는 컴퓨터 프로그램이 일부이기는 하지만 판매되기 시작하였다. o 년 대 판매되기 시작한 컴퓨터 프로그램이 1960년대 후반에 와서는 소프 트웨어라는 상품으로 포장되어 정식으로 판매되는 상품으로 인식되기 4) Richard Stallman, Why "Free Software" is better than "Open Source", <

17 1장. 서론 시작하였다. 그리고 이때부터 소프트웨어는 개발한 회사의 일급비밀 이 되어 소스코드를 공개하지 않게 되었다. 하지만 이때에도 UNIX를 포함한 공개소프트웨어는 소스코드가 계속 공개되고 있었다. 즉, 1960 년대 중 후반기에는 공개소프트웨어와 비공개소프트웨어가 공유한 시 기라고 볼 수 있다. o 년 대 1970년대도 UNIX 소스코드는 많은 대학에서 자유로이 사용하고 수정하고 할 수 있었다. UNIX에서 사용될 수 있는 많은 공개소프트 웨어들도 자유로이 수정되고 사용되었다. o 년 대 1980년대에 들어서면서 상용UNIX가 대두되기 시작하여 UNIX에 대한 소유권을 가지고 있었던 AT&T는 수수료를 높이고 그 배포를 제한하게 되었다. 이로써 UNIX 소스코드의 수정본을 공유해왔던 많 은 사용자들이 소프트웨어를 수정하는 것을 불가능하게 되었으며, 대 학에서도 UNIX에 라이센스를 적용하기 시작하였다. 즉, 1980년도부터 공개소프트웨어의 개념이 희박해지면서 독점소프트웨어가 본격적으로 출현하여 소프트웨어를 완전히 제품화하여 유통하고 판매한 시기라고 할 수 있다. 공개 및 공유되어 왔던 소프트웨어 소스코드가 완전히 상품화, 사 유화, 제품화되어 기업의 수익을 위한 상품화된 것에 회의를 느낀 MIT의 리차드 스톨만(Richard Stallman)은 "소프트웨어는 공유되어 야 한다."라는 소신을 가지고 그 뜻을 펼치기 위하여 1984년도에 GNU라는 프로젝트를 시작하였다. 자유소프트웨어를 보호하고 자유소프트웨어 운동을 본격적으로 촉 - 5 -

18 공개소프트웨어 가이드 진하기 위하여 리차드 스톨만은 1985년에 자유 소프트웨어재단, 즉, FSF(Free Software Foundation)을 설립하였다. 자유소프트웨어 운동 이란 모든 소프트웨어를 누구든지 자유로이 사용할 수 있고, 필요에 따라 변경을 할 수 있으며, 변경된 소프트웨어를 자유로이 배포할 수 있게 하기 위함이 목적이며 이를 위해서는 소프트웨어의 소스코드 공 개가 필수적이라는 것이다. 그리고 이를 실현하기 위하여 GPL이라 는 자유소프트웨어 라이센스를 만들었다. o 년 대 1991년에 핀란드의 대학생인 리누스 토발즈가 80386칩에 최적화된 LINUX라는 시스템 커널을 개발하였다. 그리고 이 소스에 GPL라이센 스를 부여하여 GNU프로젝트에 의해 개발될 수 있도록 공개하였다. 이때부터 LINUX 커널은 전 세계의 수많은 개발자들과 함께 GNU프 로젝트 하에서 이미 개발되었던 많은 프로그램 및 유틸리티들과 결합 되었으며 매우 안정적인 운영체제로 놀라울 정도로 빠른 발전을 하게 되었다. 5) GNU 프로젝트의 많은 유틸리티들과 합쳐져, GNU/Linux운영체제 가 탄생하게 되었으며 드디어 1996년도에 리눅스 커널 2.0이 발표되 면서 Linux 운영체제는 완전한 운영체제로 인정을 받게 되었다. 한편 자유소프트웨어 운동 내부에서 이상주의적이고 도덕적인 스톨 만의 입장에 대해서 실용주의적 관점에서 비판이 이루어지기 시작하 였다. 에릭 레이몬드(Eric Raymond)는 리눅스를 개발하는 방식이 왜 성공적인 결과를 낳았는지를 분석하고 그 결과를 발표하였다. 6) 5 ) 리누스 토발즈는 운영체제의 일부분인 Linux커널의 개발을 시작한 선도개발자이며, 리누스 토 발즈가 개발을 시작한 커널에 수많은 GNU프로젝트와 다른 프로젝트들의 결과물들이 합 해져서 결국 완성된 하나의 Linux운영체제가 개발된 것이다. 6) 리누스 토발즈가 리눅스를 만들었다는 사실보다 불완전한 소프트웨어를 자주 빠르게 발 표하여 수 많은 사람들이 버그를 수정하는 리눅스 개발 모델 을 만든 것에 큰 의미를 부 여한다.(Eric S. Raymond, The Cathedral and The Bazaar 참조) - 6 -

19 1장. 서론 1998년 넷스케이프사가 레이몬드의 논리를 수용하여 넷스케이프 커뮤티케이터 의 소스코드를 공개한다고 발표하였다. 레이몬드와 그의 주장에 동의하는 사람들은 공개소프트웨어 운동을 관리하기 위해 Open Source Initiative라는 조직을 결성하고 자유소프트웨어의 이념 적 측면보다는 그것이 개발되는 방식에 초점을 맞추는 실용적 접근을 취하는 이들은 자유소프트웨어는 산업계는 물론이고 개발자에게도 경 제적인 보상을 제공할 수 있어야 한다고 주장하였다. 나. 공 개 소 프 트 웨 어 정 의 공개소프트웨어(Open Source Software)란 소스코드 7) 를 공개한 상 태로 실행프로그램을 제공하는 소프트웨어로서, 소스코드를 누구나 자유롭게 사용 개작 재배포할 수 있도록 허용한 소프트웨어이다. 공개소프트웨어는 누구라도 소스코드를 읽을 수 있고 사용자가 능 력이 있다면 각종 버그의 수정은 물론이고 그것을 개작하여 기능을 추가할 수 있으며, 누구나 소프트웨어 개발에 참여할 수 있다. 따라서 공개소프트웨어는 소스코드에 접근할 수 있는 권리, 프로그램을 복제 하여 배포할 수 있는 권리, 프로그램을 개선할 수 있는 권리를 개발 자에게 보장한다. 이러한 공개소프트웨어는 소스코드에 대한 접근성이 보장되므로 시 스템간의 호환성을 확보할 수 있을 뿐 아니라 사용자의 요구에 부합 하는 일관성과 함께 일치성을 보장받을 수 있다. 7) 소스코드는 사람이 읽을 수 있는 형식의 프로그램 코드를 말하며 실행코드 또는 바이너 리 코드는 컴퓨터가 인식하고 실행할 수 있는 형식의 코드를 의미한다

20 공개소프트웨어 가이드 OSI(Open Source Initiative)에서 정의하는 공개소프트웨어 조건은 8) 자유배포(Free Redistribution), 소스코드 공개(Source Code Open), 2 차적 저작물(Derived Works), 소스코드 수정제한(Integrity of The Author's Source Code), 개인이나 단체에 대한 차별 금지(No Discrimination Against Persons or Groups), 사용분야에 대한 제한 금지(No Discrimination Against Fields of Endeavor) 등 10개 항목이 있다. 다. 비 공 개 소 프 트 웨 어 와 비 교 1) 비공개SW와 비교 앞서 공개소프트웨어에 대한 역사와 정의에 대하여 알아보았다. 이 제 공개소프트웨어에 대한 현실적인 활용가치와 기능성 등을 확인하 기 위하여 비공개소프트웨어와 공개소프트웨어를 차이점을 살펴보면 다음과 같다. 9) 첫째, 가장 대표적인 차이점으로서 비용면에서의 차이점이다. 비공개소프트웨어는 라이센스 비용이 발생하는 반면 공개소프트웨 어는 라이센스 비용은 발생하지 않으나, 기술지원이나 서비스에 대한 수수료는 발생한다. 또한 비공개소프트웨어는 시스템에 대한 초기 적 용비용이 높지만 공개소프트웨어는 초기 적용비용이 매우 낮다는 점 8 ) 자세한 내용은 및 한국소프트웨어진흥원, 오픈소스소프트웨어연구보고서, 2002 참조 9) 공개소프트웨어는 소스코드의 공개, 개작, 재배포가 자유로운 소프트웨어를 의미하는 것이 며, 비공개소프트웨어는 이러한 권리가 제한된 소프트웨어를 의미한다. 공개소프트웨어를 상용소프트웨어와 반대되는 개념의 소프트웨어로 이해하는 경우가 있으나, 이는 공개소프 트웨어를 무료 소프트웨어로 잘 못 이해하고 있기 때문에 생긴 오해이다. 공개소프트웨어 도 유료 즉 상용으로 배포할 수 있다

21 1장. 서론 이다. 둘째, 성능면에서의 차이점이다. 비공개소프트웨어의 경우 전문가가 직접 설치 및 최적화 설정을 하 기 때문에 규모가 큰 시스템 환경에서 널리 사용되어 왔다. 공개소프 트웨어의 경우 최적화가 이루어지지 않은 경우가 많으나, 공개소프트 웨어의 경우에도 전문가를 통해 최적화하여 설치한다면 비공개소프트 웨어의 경우와 같이 규모가 큰 시스템 환경에서 사용될 수 있을 정도 의 성능을 보여준다. 또한 버전이 올라가면서 점차적으로 우수한 성 능을 보여주기도 한다. 대표적으로 공개소프트웨어 운영체제인 리눅 스의 경우 커널 2.6.X 이상에서는 중대형 시스템에서 안정적 성능을 나타내고 있으며 이러한 추세는 앞으로 더욱 활발해 질 것으로 예상 된다. 셋째, 보안면에서의 차이점이다. 비공개소프트웨어는 프로토콜의 호환이 어려워 인증체계가 취약하 며 폐쇄적인 운영으로 인해 공개되지 않는 약점이 존재할 수 있다. 반면 공개소프트웨어는 개발 시부터 공개되어 이미 많은 취약점이 개 선 및 해결되었으며 안정된 상태에서 운영되고 있다. 넷째, 기술적인 면에서의 차이점이다. 비공개소프트웨어는 프로젝트의 연속성 및 재사용성이 낮은 반면 공개소프트웨어는 소스코드의 공개로 인하여 언제든 재사용이 가능하 기 때문에 프로젝트의 영속성이 보장되며 유지보수 및 업그레이드 비 용이 낮다. 다섯째, 확장성에 대한 차이점이다. 비공개소프트웨어는 높은 적용비용과 제한된 시스템 운영환경으로 - 9 -

22 공개소프트웨어 가이드 인하여 확장성이 완벽하게 보장되는 것은 아니다. 하지만 공개소프트 웨어는 소스가 공개되어 있기 때문에 시스템의 확장성이 확실히 보장 된다는 장점이 있다. 여섯째, 공급권에 대한 차이점이다. 비공개소프트웨어의 생산업체는 하나이므로 독점 및 단일공급 된다. 단, 유통회사는 여러 개 존재할 수 있지만, 원 공급 업체는 하나이다. 반면 공개소프트웨어는 동일한 솔루션에 대하여 다수 업체들로 부터 공급이 가능하기 때문에 사용자의 공급업체 선택권이 넓은 편이다. 일곱째, 저작권에 대한 차이점이다. 비공개소프트웨어는 일반 라이센스를 채택하고 있는 반면 공개소프 트웨어는 거의 대부분 GPL 라이센스, BSD 라이센스, MPL 라이센스 등을 원하는 대로 적용할 수 있다. 여덟째, 경쟁력에 대한 차이점이다. 비공개소프트웨어는 핵심 소프트웨어에 대한 개발능력 및 저작권을 이미 보유하고 있는 소프트웨어 선진국에 유리한 소프트웨어이다. 반 면 공개소프트웨어는 소프트웨어의 핵심기술 공유할 수 있는 기회가 있기 때문에 신흥 소프트웨어 개발국에 유리하다. 비공개소프트웨어와 공개소프트웨어의 차이점을 요약하면 다음 표 와 같다

23 1장. 서론 <표 1> 비공개소프트웨어와 공개소프트웨어 비교 구 분 비공개소프트웨어 공개소프트웨어 비용분석. 적용비용이 높음. 유지비용및 시스템 개선비용이 높음. 소수의 관리자에 대한 관리비용 높음. 라이센스에 대한 비용발생. 적용비용이 낮음. 유지비용이 낮고 기능 확장에 대 한 추가비용이 낮음. 관리비용이 낮음. 서비스에 대한 비용발생 성능분석. 규모가 큰 시스템 환경에서 비교적. 다양한 환경에 최적화된 설정으로 높은 성능 높은 성능. 고가의 장비로 인한 고성능. 높은 안정성 및 비용효율이 높음. 전체적으로 공개SW와 비슷한 성능. 폐쇄적인 운영으로 인한 공개되지. 개발시부터 공개되어 이미 많은 않은 시스템 취약점 보유 취약점이 해결된 안전화 상태 보 안 성. 최근에 다수의 취약점 발견으로. 공개키 기반의 인증 매카니즘 구 보안 위협 노출 현을 위한 통합패키지존재. 프로토콜 호환이 어려워 인증체계. 다양한 암호화 알고리즘 및 키 관 취약 리에 대한 기능 제공 기 술 성. 재사용성 없음. 재사용성 높음. 유지보수,업그레이드용이. 독점폐해방지 저 작 권. 일반라이센스. GPL라이센스. 독과점에 의한 가격결정우려. BSD라이센스등 확 장 성. 서버의 가용성 측면에서 클러스터링. 효율적인 클러스터링 구현가능 비효율성. 소프트웨어간의 적용비용이 거의. 소프트웨어간의 호환성이 보장되나 들지 않고 낮은 수준에서의 기능 높은 적용비용과 제한된 시스템 추가 가능 운영환경 경 쟁 력. 소프트웨어선진국에 유리. 공동개발상식에 따른 기술공유 효과 우수(교육효과 우수). 신흥 소프트웨어 개발국에 적합 공 급 권. 개발업체로 부터 단일공급. 다수 업체로 부터 공급가능 2) 상용SW와 비교 공개소프트웨어는 종종 비상용 소프트웨어 로 간주되나 이는 공개 소프트웨어가 자유로운 재배포가 가능하다는 것에 대한 오해에서 비 롯된 것이다. 정부 및 업계에서 사용하는 대부분의 공개소프트웨어는

24 공개소프트웨어 가이드 상용이라는 상업적 조건에서 사용이 가능하다. 공개소프트웨어는 영리 목적의 기업으로부터 공급받을 수 있으며, 공개소프트웨어를 제공하는 기업은 라이센스 비용을 지불하지 않으나 서비스에 대한 비용을 청구하는 모델을 통해 공개소프트웨어 제품을 제공하고 있다. 공개소프트웨어와 상용소프트웨어의 차이점은 다음 표와 같이 간단 히 정리할 수 있다. <표 2> 공개소프트웨어와 상용소프트웨어 비교 구분 공개SW 상용SW 소스코드 접근성 가능 불가 도입 비용 유료 또는 무료 유료 다수 개발자(기업) 단일 개발기업 개발 및 공급자 다수 공급자 다수 공급자 수익모델 서비스 중심 라이센스료 중심 3) 기타 소프트웨어와 비교 10) 공개소프트웨어와 혼동하고 있는 소프트웨어 유형으로는 프리웨어 (Freeware), 쉐어웨어(Shareware), 애드웨어(Adware) 등이 있다. 이 들 소프트웨어와 공개소프트웨어의 유사점은 무료로 사용할 수 있다 는 점이고 가장 큰 차이점은 이들 소프트웨어는 소스코드가 공개되지 않는다는 점이다. 각 각의 특징을 살펴보면 다음과 같다. 프리웨어는 라이센스 비용없이 무료로 배포되는 소프트웨어로 최종 10) 지식자료 참조( ci d=4 665 )

25 1장. 서론 사용자가 대금을 지불할 필요는 없으나 영리를 목적으로 배포할 수 없는 소프트웨어로서 국내에서는 흔히 공개판이라 부르기도 한다. 프 리웨어는 이용하는데는 제한이 없지만 배포는 제작자의 의도에 따라 야 한다. 대표적인 프리웨어로는 Winzip, RealAudio 등이 있다. 쉐어웨어는 대개 판매를 목적으로 제작되지만 일단 사용해 보고 마 음에 들면 구입할 수 있도록 하는 프로그램으로 국내에서는 평가판이 라 부르기도 한다. 일정 시험기간 동안 무료로 사용한 뒤 해당기간이 지나 계속적 사용을 원할 때는 사용자 등록을 하고 비용을 지불해야 하며 통상 개인에 한정해 자격이 주어지는 것이 보통이다. 가계부 등 주로 가정용에서 사용하는 소프트웨어들이 있다. 애드웨어는 프로그램을 기능이나 날짜상의 제한없이 무료로 사용하 는 대신 해당 소프트웨어로 작업하는 동안 광고창을 통해 계속적으로 새로운 광고가 노출되도록 한 새로운 마케팅 기법으로 등장한 소프트 웨어이다. 대표적인 소프트웨어로는 제트오디어이다. 2. 공개소프트웨어 산업 개관 가. 공 개 소 프 트 웨 어 비 즈 니 스 모 델 공공기관 등 IT 수요자들이 공개소프트웨어를 무료 소프트웨어로 잘못 이해하고 있어 공개소프트웨어 도입 시 비용을 청구하는 것을 문제시 하는 경우가 많다. 그러나 공개소프트웨어 제공업체가 청구하 는 비용은 라이센스 비용이 아니라 기술지원 서비스 비용이다. 이 서 비스 비용은 제공업체가 공개소프트웨어와 관련된 정보의 바다 11) 에서

26 공개소프트웨어 가이드 필요로 하는 적절한 정보를 선별하여 공급하고, 기능 업그레이드, 버 그 개선 등 도입 이후 발생할 수 있는 다양한 기술적 문제에 대한 해 결에 필요한 서비스를 제공하기 때문에 청구되는 것이다. 공개소프트웨어는 사업 중점을 어디에 두느냐에 따라 패키지형, 솔 루션형, 서비스형으로 구분할 수 있다. 첫째, 패키지형 비즈니스 모델은 패키지의 개발과 판매에 주력하는 것으로 리눅스가 대표적인 성공사례라 할 수 있다. 둘째, 솔루션형 비즈니스 모델은 패키지를 개발, 판매와 함께 AS등 에 주력하는 것으로, 소스 코드의 공개로 제품 자체의 차별화 요소가 없는 상황에서 현실적인 모델이다. 솔루션 형의 특징은 마케팅에서 공개소프트웨어 커뮤니티를 활용할 수 있고, 제품이 박스 형태로 제 공되기 때문에 판매가 용이하며, 서비스에서 수익이 발생한다. snot가 대표적인 성공사례이며 국내 대부분의 리눅스 기업들의 수익모델이다. 셋째, 서비스형 비즈니스 모델은 패키지 개발을 커뮤니티에 의존하 고 우수한 공개소프트웨어 전문인력을 기반으로 공개소프트웨어의 기 술검증, 제품 설치, 교육, AS 등을 주력 사업으로 하고 있으며, LinuxCare가 대표적인 사례이다. 나. 공 개 소 프 트 웨 어 산 업 동 향 공개소프트웨어 플랫폼이 IT산업의 주류로 진입함에 따라 대규모의 소프트웨어 개발기업(ISV;Independent Software Vender)과 하드웨어 11) 공개소프트웨어는 주로 자발적 공헌자 그룹인 커뮤니티에 의해 개발되고 있기 때문에 개발 및 사용과 관련된 정보 교류를 커뮤니티 사이트를 통해서 이루어지고 있다

27 1장. 서론 개발기업(IHV;Independent Hardware Vender)들이 공개소프트웨어 운영체제에서 실행되는 기업형 어플리케이션이나 시스템 기술 개발을 강화하는 추세에 있다. 또한 주요 아웃소싱 솔루션 제공기업들도 서 비스 지원을 확장하여 일반적인 공개소프트웨어 플랫폼을 포괄하도록 하고 있다. 공개소프트웨어 업계는 규모로 볼 때 대규모의 다국적 기업과 중규 모 개발업체, 전문유통 및 기술지원 서비스 전문 소규모 기업으로 분 류할 수 있고, 사업형태로 볼 때 순수 공개소프트웨어 개발기업, 공개 소프트웨어 기반 패키지 개발기업, 공개소프트웨어 기반 SI 및 솔루션 개발기업, 공개소프트웨어 기반 기술지원 및 서비스 기업, 공개소프트 웨어기반 하드웨어 개발 기업 등 5가지 유형으로 분류할 수 있다. 1) 기 업 규 모 에 따 른 분 류 o 다 국 적 기 업 등 대 기 업 공개소프트웨어 산업에서 하나의 큰 축을 이루고 있는 그룹은 대규 모의 다국적 기업 및 국내 대기업이다. 공개소프트웨어를 기반으로 한 사업을 추진하고 있는 대형 하드웨어 벤더는 IBM, HP, Sun, 삼성 전자 등이 있으며, 소프트웨어 벤더는 Oracle 12) 이 대표적이다. 이들 대형 기업들은 공개소프트웨어 개발에 직접 참여, 공개소프트웨어 커 뮤니티 발전을 지원, 리눅스 등 공개소프트웨어 운영체제상에서 운용 가능한 다양한 소프트웨어 및 하드웨어 개발 등을 통해서 공개소프트 12) Oracle은 공개소프트웨어 제품을 개발하고 있지은 않으나, 리눅스 등 공개소프트웨어 운 영체제에서 운용가능한 소프트웨어를 개발하고, 리눅스 등 공개소프트웨어 발전을 지원 한다는 의미에서 공개소프트웨어 업계로 분류한다. Oracle 이외에도 리눅스 등 공개소프 트웨어 운영체제에서 운용가능한 소프트웨어 및 하드웨어 개발업체를 공개소프트웨어 업계로 분류한다

28 공개소프트웨어 가이드 웨어 발전에 참여하고 있다. o 중 소 규 모 개 발 기 업 공개소프트웨어 산업의 또 다른 축을 형성하고 있는 그룹은 국내 중규모 개발 기업들이다. 이들은 국내기간 기업들로써 중간 규모의 하드웨어 및 소프트웨어 개발업체들이며 주로 공개소프트웨어기반 패 키지 및 솔루션을 공급 하고 있다. 13) 또한 이들 기업들은 정부기관이 나 주요 수요업체들의 요구조건을 수용하고 처리하는데 많은 경험을 보유하고 있으며 때로는 패키지형태의 제품을 개발공급하기도 하기도 한다. 공개소프트웨어 산업에서 이들은 광범위한 수준의 전문지식을 보유하고 있으며 자체적으로 기능성을 추가한 보다 진보한 공개소프 트웨어 솔루션 및 패키지 제품을 개발공급하기도 한다. 예를 들면 컨 텐츠 관리시스템, 업무지능 소프트웨어, 업무처리 어플리케이션 또는 부문별 그룹웨어 서버, 방화벽, 무선네트워크 환경의 게이트웨이 등을 공급하고 있다. o 전 문 유 통 및 기 술 지 원 서 비 스 제공 업 체 공개소프트웨어 산업의 또 하나의 축을 형성하고 있는 그룹은 소규 모 개발 기업들이다. 이들은 주로 공개소프트웨어 산업의 틈새시장이 나 특수한 기술시장에서 두각을 나타내고 있다. 공개소프트웨어 산업 에서 기술 클러스터를 형성하고 있으며 중규모 개발업체와 긴밀한 관 계를 형성하고 있다. 개발이 아닌 분야에서 또 다른 축을 형성하고 있는 그룹은 공개소프트웨어 제품의 전문유통과 기술지원 및 서비스 13) 공개소프트웨어기반 패키지 및 솔루션이라 함은 리눅스 등 공개소프트웨어 운영체제 상 에서 운용가능한 패키지 및 솔루션을 의미하며, 공개소프트웨어 기반 SI, 서비스, 하드웨 어 개발 등도 같은 의미이다

29 1장. 서론 를 주 업무로 하는 기술지원 및 서비스 기업들이다. 이들 기업체들은 주로 대규모 개발업체 및 중소규모 업체들의 인기 제품들을 유통하며 이에 따르는 기술 지원 사업을 전개하고 있다. 따라서 이들은 대규모 및 중소규모 개발업체들과 매우 밀접한 관계를 형성하고 있으며 상호 보완적인 파트너쉽 관계를 형성하고 있다. 2) 사 업 유 형 에 따 른 분 류 1990년대 후반부터 리눅스 배포판 기업체들을 선두로 하여 국내에 서도 공개소프트웨어를 기반으로 하는 기업들이 나타나게 되었다. 국 내에서 공개소프트웨어를 기반으로 사업을 하고 있는 기업체는 현재 에는 약 150여개 정도로 파악되고 있다. 14) o 공 개 소 프 트 웨 어 개 발 기 업 리눅스 등 공개소프트웨어를 개발 및 유통하는 업체로 국내 기업으 로는 리눅스원, 아이겟리눅스, 와우리눅스, 한글과컴퓨터 등이 있고, 외국 기업으로는 레드햇, 수세 등이 있다. 1990년대 후반 벤처 및 닷컴 붐 당시에는 리눅스 배포판 개발 및 유통 기업이 200여개에 달했으나, 현재는 리눅스 전문 개발 기업과 유통 및 기술지원 전문 기업으로 분리 발전하고 있다. 우리나라의 경우 리눅스 이외에 공개소프트웨어 개발 사업에 적극 적으로 참여하는 기업은 아직 거의 없다. 14) 국내에서 공개소프트웨어를 기반으로 하는 사업을 하는 150여개 업체들의 상세정보를 확인하려면 2005 공개SW 기업과 제품정보 가이드(한국소프트웨어진흥원, 2005) 을 참고할 수 있다. 또한, 공개SW 기업체의 기업정보와 제품정보를 DB화하여 help.oss.or.kr에서 제공하고 있다

30 공개소프트웨어 가이드 o 공 개 소 프 트 웨 어 기 반 패 키 지 개 발 기 업 리눅스 등 공개소프트웨어 운영체제 상에서 운용 가능한 패키지 소 프트웨어를 개발하는 기업으로써 대표적인 국내 기업으로는 삼성 SDS, 티맥스소프트, 핸디소프트, 케이컴스 등을 들 수 있고, 외국 기 업으로는 오라클, 아도비 등을 들 수 있다. 리눅스 확산의 가장 큰 장애요인으로 작용하고 있는 것이 우수한 어플리케이션이 없다는 인식이나, 대부분의 패키지 개발 기업들이 리 눅스에서 운용 가능하도록 개발하고 있으며, 리눅스에 대한 지원을 강화하고 있다. o 공 개 소 프 트 웨 어 기 반 S I & 솔 루 션 개 발 기 업 삼성SDS, POSDATA, SKC&C, LGCNS 등 대형 SI 기업, 리눅스 코리아, 엔티씨코리아 시스템 등 중소 SI기업 등 대부분의 국내 SI 기업들이 리눅스를 기반으로 한 시스템 구축업체로 분류할 수 있다. 또한, 이니텍, 쓰리알소프트, 사이버다임 등 국내 중견 소프트웨어 개발 기업들도 리눅스 등 공개소프트웨어기반의 솔루션을 개발하고 있다. 리눅스 확산의 가장 큰 장애요인으로 작용하고 있는 것이 훌륭한 어 플리케이션이 없다는 인식이나, 대부분의 솔루션 개발 기업들이 리눅스 에서 운용 가능하도록 개발하고, 리눅스에 대한 지원을 강화하고 있어 리눅스 도입에 따른 어플리케이션 선택의 제약은 없다고 할 수 있다. o 공 개 소 프 트 웨 어 기 반 기 술 지 원 & 서 비 스 기 업 공개소프트웨어 시장 확산에 중요한 사업 분야가 공개소프트웨어 기반의 기술지원 및 서비스 분야로 공개소프트웨어 기반으로 구축된

31 1장. 서론 시스템에 대한 기술지원과 교육을 담당함으로써 사용자의 불안감을 해소해 주는 역할을 하는 사업 분야라 할 수 있다. 국내외적으로 이러한 업종에 속한 기업들은 삼성SDS, 한국IBM, 한국 HP 등의 대기업 및 다국적기업과 리눅스코리아, ITBridge 등의 특화 기술지원, 서비스, 교육을 담당하는 지역단위의 기술지원업체가 있다. 리눅스 교육 분야에서는 수퍼유저코리아, 지역기술지원으로 애니아 이티 등이 대표적이다. o 공 개 소 프 트 웨 어 기 반 하 드 웨 어 개 발 업 체 리눅스 등 공개소프트웨어 운용체제가 운용가능한 x86 계열의 하드 웨어를 개발 및 생산하는 업체로 국내 기업으로는 삼성전자, 유니와 이드 등이 있으며, 외국 기업은 IBM, HP, Dell, Sun 등이 대표적인 업체이다

32 BLANK

33 2장. 공개소프트웨어에 대한 오해와 진실 2장. 공개소프트웨어에 대한 오해와 진실

34 BLANK

35 2장. 공개소프트웨어에 대한 오해와 진실 1. 비용 문제 첫째, 공개소프트웨어를 도입하면 도입 이후의 운영비용이 너무 높 다는 인식이 있다. 공개소프트웨어를 이용하면 라이센스 비용 절감을 시작으로 하여 전반적인 도입비용, 그리고 더 크게는 TCO(총소유비용) 15) 를 낮출 수 있다. IDC가 2002년에 발표한 인텔기반의 리눅스와 RISC기반의 유닉스 서버 간 TCO분석에 따르면 16) 모든 면에서 공개SW의 TCO가 더 낮 게 나타났다고 보고하고 있으며, 미국의 시장조사업체인 로버트프랜 시스 그룹이 웹서버를 운영하는 전 세계 2천여개 업체들을 대상으로 조사한 결과 3년간 리눅스기반의 웹서버를 운영 했을때 윈도우를 사 용 했을 때 보다 39%정도 TCO가 낮은 것으로 나타났다 17). 이 조사 에 따르면 하루 10만건의 히트수를 처리하는 것을 기준으로 볼때 3년 간 웹서버운용에 솔라리스 기반시스템은 56만2천불, 윈도우기반은 19 만1천불, 리눅스는 7만4천불의 TCO가 소요되는 것으로 나타났다. 둘째, 공개소프트웨어는 초기비용보다 시스템 증설 및 유지, 그리고 업그레이드 비용이 더 많이 발생한다는 오해가 있다. 15) TCO(Total Cost Ownership)란 총소유비용을 정보시스템 구축에 필요한 하드웨어, 소프 트웨어 등 초기 도입비용 뿐만 아니라 유지관리비용, 교육비용 등 정보시스템 구축과 운 영에 필요한 모든 비용을 포괄하는 비용을 의미한다. 16) Al Gillen, Dan Kusnetzky, and Scott McLarnon, The Role of Linux in Reducing the Cost of Enterprise Computing, IDC White Paper, ) Total Cost of Ownership for Linux in the Enterprise, Robert Frances Group,

36 공개소프트웨어 안내서 먼저, 독점소프트웨어는 일반적으로 개인당 라이센스(또는 cpu당 라이센스)로 판매 된다. 따라서 현재 시스템을 증설하기 위하여 서버 의 숫자가 증가한다면 독점소프트웨어 솔루션 도입비용은 계속 상승 하게 된다. 즉, 현재 시스템이 더 많은 클라이언트를 위해 서비스를 해야 한다면 추가되는 클라이언트의 숫자에 비례하여 라이센스 비용 을 추가 지불해야 한다는 것을 의미한다. 하지만 공개소프트웨어에서는 시스템이 증설된다 하더라도 하드웨 어 구매 비용 외에는 추가 라이센스 비용은 발생하지 아니한다. 공개 소프트웨어는 처음부터 라이센스료를 지불하는 것이 아니라 서비스에 대한 비용을 지불하는 것이므로 클라이언트 수가 늘어나는 만큼 얼마 든지 복사하여 사용할 수 있다는 것을 의미한다. 따라서 공개소프트 웨어에 있어서 시스템 증설에 따른 추가 라이센스 비용은 존재하지 않는다. 단, 시스템증설에 따르는 기술지원료는 발생할 수 있지만 이 는 독점소프트웨어도 마찬가지일 뿐 아니라 기술지원 업체 또한 얼마 든지 선택하여 조건에 맞는 가격에 서비스를 받을 수 있다. 셋째, 공개소프트웨어는 설치시간, 유지비용, 교육비 측면에서 비공 개 소프트웨어 구매비용과 별 차이가 없다. 이는 TCO(총소유비용)에 대한 것으로써 공개소프트웨어의 대표적 인 장점이라고 할 수 있는 비용 절감에 대한 오해이다. 공개소프트 웨어의 대표적인 장점인 라이센스 구매비용이 없다는 것은 공개소프 트웨어를 도입하여 적용하려고 하는 기업이나 공공기관에게는 비공개 소프트웨어에 비하여 절대적인 비용절감을 가져다주게 된다. 공개소프트웨어는 설치시간, 유지보수비용, 교육비용 등에서 비공개 소프트웨어 보다 비용이 많이 들거나 설치가 복잡하다고 일괄적으로 말할 수 없다. 또한 기술지원 서비스 전문업체로부터 다양한 서비스

37 2장. 공개소프트웨어에 대한 오해와 진실 를 받을 수 있으며 필요한 경우 민간 커뮤니티로부터 무상으로 기술 지원을 받을 수도 있다. 교육비용은 어떤 소프트웨어에서건 처음 접하면 반드시 필요한 것 이며 공개소프트웨어라고 해서 더 많이 들거나 작게 드는 비용이 아 니다. 단지, 도입한 공개소프트웨어 개발자 커뮤니티 18) 가 성숙해지기 이전이라면 그 공개소프트웨어는 버그가 존재할 수 있고, 완성도가 떨어질 수 있으므로 이는 도입단계에서 고려해야 할 문제이다. 이 또 한 비공개 소프트웨어도 출시 초기에는 수많은 버그를 갖고 있기 때 문에 공개소프트웨어만의 문제는 결코 아닐 것이다. 또한, 기존의 시스템을 비공개소프트웨어로 운용하고 있었기 때문 에 발생하는 비용이지, 공개소프트웨어를 도입하기 때문에 발생하는 비용은 아니다. 이미 공개소프트웨어를 사용하고 있는 상황에서 비공 개소프트웨어를 도입하는 경우라면 더 높은 교육비용을 지불하여야 할 것이다. 이러한 여러 가지 상황을 고려해 볼 때에 비공개 소프트웨어를 도 입하는 것에 비하여 공개소프트웨어를 도입할 경우 보다 비용절감이 가능하다. 19 ) 2. 기술지원 및 가용성 리눅스를 중심으로 한 공개소프트웨어 기술지원 전문 기업으로는 18 ) <부록4> 오픈 소스 소프트웨어 리소스 참고 19) 2005년 7월 기획예산처에서 정보화예산혁신을 위해 추진했던 2006년 정보화사업 중 공 개소프트웨어 도입 사업 비용효과분석 결과 초기 도입비용이 평균 약 20% 절감되었다 고 발표하였다

38 공개소프트웨어 안내서 한글과컴퓨터, 리눅스데이터시스템, 리눅스원, 와우리눅스, 리눅스코리 아, 아이겟리눅스, 수퍼유저코리아, 모아시스, 앤티씨큐브, 애니아이티, 케이씨크 등이 있으며 이들 기업은 기업간 파트너쉽을 통하여 전국적 기술지원 조직을 갖추고 있다. 또한 한국소프트웨어진흥원(KIPA) 내에 설치되어 있는 "공개소프 트웨어 기술지원센터"에서 공공기관을 대상으로 공개소프트웨어에 대 한 기술지원 서비스가 이루어지고 있다. 기술지원 및 가용성에 대한 편견과 오해를 알아보기에 앞서 수요자 들이 공개소프트웨어 사용을 꺼리는 이유 몇 가지 살펴보면 첫째, 익 숙함에 길들여져 있기 때문에 익숙하지 않은 것에 대해서는 시도하지 않으려고 하는 성향, 둘째, 타인들이 그냥 불안하다고 평하기 때문에 정확한 정보가 없는 상황에서 막연하게 불안해하는 성향, 셋째, 다른 사람들이 많이 사용하지 않기 때문에 뭔가 문제가 있다고 생각하는 편견 등이다. 공개소프트웨어의 기술지원과 관련된 일반적인 오해와 편견들에 대 하여 객관적인 평가를 하면 다음과 같다. 첫째, 공개소프트웨어 기술지원 업체가 없다. 공개소프트웨어에 대한 기술지원을 받고 싶으나 지원업체를 찾기가 어렵다고 호소하나 대표적인 공개소프트웨어인 리눅스의 경우 배포판 업체뿐만이 아닌 다국적 하드웨어 벤더는 물론 국내 주요 SI업체들로 부터 기술지원을 직접 받을 수 있다. 또한 공개소프트웨어의 커뮤니 티 공동체에 문의하면 무료로 지원을 받을 수도 있을 것이다. 이같은 공동체의 지원 외에도 리눅스의 경우는 유명 하드웨어 업체나 소프트

39 2장. 공개소프트웨어에 대한 오해와 진실 웨어업체에서도 자사 제품에 대해 공식적으로 리눅스 지원 서비스를 제공하고 있다. 과거 리눅스 기술지원은 주로 중소 벤쳐기업이 제공했지만 2004년 하반기 이후 이 같은 기술지원의 주체는 SI업체중심 체제로 빠르게 전환되고 있다. 현재 삼성SDS, 포스데이타 등의 주요 SI업체들이 리 눅스 전담팀을 강화 하는 등 리눅스 기술지원을 위한 만반의 준비를 하고 있다. 또한 한국소프트웨어진흥원에서는 "공개SW기술지원센터" 를 통해 리눅스 또는 공개소프트웨어로 기존 IT인프라를 전환하는 기 관을 대상으로 기술지원서비스제공을 하고 있다 20 ). 둘째, 공개소프트웨어에 비해 독점소프트웨어의 기술지원이 우수하다. 공개소프트웨어에 대한 기술지원을 받는 방법은 기술지원 전문기업 과 계약체결을 통해 서비스를 받거나, 자발적 민간 커뮤니티로부터 기술지원을 받는 것이다. 사용자는 이들 가운데 선택할 수 있는 권리 가 있으며 개인 역량에 따라서 선택할 수 있다. 독점소프트웨어 기술 지원에 대해서는 공급업체의 역량에 달려있다고 할 수 있다. 즉, 기술 지원에 많은 투자를 하여 체계적인 기술지원시스템을 갖추고 있다면 당연히 공개소프트웨어의 기술지원보다는 좋은 평가를 받을 수 있들 것이나, 그렇지 않다면 좋은 평가를 얻지 못한다. 따라서 이것은 공개 소프트웨어의 기술지원이 훨씬 더 나은가? 아니면 독점소프트웨어의 기술지원이 더 나은가? 라는 이분법적인 접근은 바람직하지 않다. 즉, 개별 소프트웨어와 지원업체의 역량문제일 뿐이다. 20) 공개SW기술지원센터는 주요 공개소프트웨어 관련업체의 전문 연구원이 상근직으로 근 무하며 공개소프트웨어 기반의 운영체제 배포판과 솔루션에 대한 테스트 및 검증, 하드 웨어와 소프트웨어간의 인증, 다양한 기술지원 및 컨설팅 서비스 등을 제공하고 있으며, 매년 6대 광역시를 중심으로 지역기술지원 세미나를 통하여 지방 공공기관에 공개소프 트웨어에 대한 소개 및 리눅스 등 공개소프트웨어 사용기관에 대한 기술지원 서비스를 실시하고 있다

40 공개소프트웨어 안내서 다음으로 공개소프트웨어의 가용성과 관련된 일반적인 오해와 편견 들에 대하여 객관적인 평가를 하면 다음과 같다. 첫째, 리눅스 등 공개소프트웨어는 사용이 어렵다. 공개소프트웨어이든 비공개 소프트웨어이든 소프트웨어를 처음 도 입하였을 때부터 적응할 때가지는 어렵다는 것은 공통된 것이다. 기 존의 시스템 운영자들이 유닉스나 윈도즈에 익숙해져 있기 때문에 사 용이 어렵다고 인식하는 것에 불과하다. 리눅스는 유닉스와 명령어체 계가 대부분 동일하기 때문에 기존의 유닉스 환경에 익숙한 운영자라 면 리눅스 환경에 적응하는데 큰 어려움이 없다. 둘째, 리눅스는 주로 웹서버로만 사용된다. 리눅스는 이미 핵심 업무용 서버로도 활발히 도입되고 있다 21). 또 한 서버 외에도 임베디드 분야에서 눈부신 활약을 하고 있다. 리눅스 는 단순한 서버용 운영체제가 아니다. 리눅스는 서버용 운영체제는 물론이고 데스크탑, 그리고 소비자 가전 및 휴대폰 등의 임베디드 운 영체제로도 널리 활용되고 있다. 셋째, 리눅스는 데스크탑 운영체제로 사용은 시기상조다. 리눅스를 데스크탑 운영체제로 사용이 윈도즈에 비하여 편의성이 떨어지고, 인터넷 사용에 현실적으로 제약이 있든 것은 사실이다. 이 러한 데스크탑 운영체제로 사용 제약요인은 크게 인터넷 뱅킹 문제, 홈페이지 접근성 제약 문제로 요약할 수 있다. 인터넷뱅킹과 같은 인터넷상에서의 금융거래를 리눅스 기반 웹 브 21 ) 리눅스 도입 성공사례는 한국소프트웨어진흥원 발간 공개소프트웨어 도입 성공사례집(2004, 2005) 참고

41 2장. 공개소프트웨어에 대한 오해와 진실 라우저(Mozilla등)에서는 아직 완벽하지 못한 것이 사실이나, 이런 문 제는 리눅스용 공인인증서를 개발하고 운영체제에 제약을 받지 않는 128비트, SSL 22) 보안체제가 구축되면 손쉽게 해결될 사안이라고 전 문가들은 말한다. 23) 리눅스와 모질라 브라우저를 사용하여 인터넷뱅킹이 가능토록 하는 것이 기술적으로 불가능한 것은 아니다. 국내보안업계는 리눅스 기반 인터넷 뱅킹을 위한 기술적 기반은 이미 마련됐다고 한다. 관련업계 에 의하면 당장 모든 시스템을 바꾸지 않고도 ActiveX와 유사한 리 눅스용 기술을 사용자에게 제공, 리눅스. 맥등 다양한 플랫폼에서 인 터넷 뱅킹 서비스를 제공할 수 있으나, 은행업계에서 소수 사용자들 을 위해 이를 도입할 의지를 보이지 않고 있다고 한다. 24) 즉, 리눅스에서 아직까지 해결되지 못한 부분이 인터넷뱅킹문제라 고 할 수 있지만 이것은 기술적인 문제가 아니라 산업 환경적인 요인 에 기인하는 것으로 보아야 한다. 즉, 리눅스를 사용하는 사용자층이 많아지면 은행업계측에서도 자연스럽게 이를 수용하고 투자를 하게 될 것이기 때문이다. 또 다른 제약요인은 리눅스 데스크탑에서 인터넷 서핑과 검색에 제 22) Secure Sockets Layer는 네트웍 내에서 메시지전송의 안전을 관리하기 위한 프로그램 계층이다. 23) 국내에서 독자적으로 암호화 알고리즘을 개발한 것은 미국지역 외에서 사용되는 익스플 로러가 지원할 수 있는 알고리즘 성능이 56비트로 제한됐기 때문으로 문제는 개발된 SEED를 익스플로러에서 구현하기 위해서는 ActiveX라는 MS윈도우의 고유기능을 별도 로 사용해야 한다는 것이다. 2000년 이후 미국 외에서도 익스플로러를 비롯한 각종 웹 브라우즈에서 128비트암호화 기능사용이 가능해졌지만 국내 은행은 여전히 ActiveX에 기반을 둔 서비스를 제공하고 있다. 24) 정보통신부 우정사업본부에서는 한국소프트웨어진흥원이 추진하는 공개소프트웨어 시범 사업에 참여하여 리눅스 사용자가 인터넷뱅킹이 가능하도록 하는 우체국 인터넷뱅킹 시 스템을 2006년 초에 서비스를 제공할 예정이다

42 공개소프트웨어 안내서 약이 있다는 것이다. 리눅스 및 모질라 등 리눅스용 웹브라우저에서 웹서핑이 제약되는 이유는 리눅스나 모질라의 기술적 제약으로 인한 것이 아니라, 국내 공공기관 홈페이지나 포탈사이트 등이 W3C 등 국제 표준을 준수하여 웹을 개발하고 있지 않기 때문에 발생하는 산업환경 적 요인이지, 공개소프트웨어가 갖는 기술적 한계가 아니라는 점이다. 그러나, 리눅스의 대표적인 웹브라우즈인 Mozilla Firefox 1.1에서는 비표준 문법을 사용하는 수많은 국내 웹사이트들도 문제없이 서핑할 수 있도록 개선하였다. 아직까지 데스크탑용으로는 MS Windows보다 리눅스가 다소 불편 한 것은 사실이다. 즉, MS Windows는 사용자의 편리성에 맞추어 오 랜 기간 동안 지속적으로 투자되고 개발되어 왔기 때문이기도 하지만 우리가 MS Windows의 GUI환경에 매우 익숙해져 있다는 점이 더욱 큰 이유일 것이다. 하지만, 현재 전 세계적으로 리눅스를 데스크탑용 으로 사용하기 위한 많은 노력과 시도들이 이루어지고 있다. 리눅스를 데스트탑 운영체제로 사용하고 있는 대표적인 해외 사례 로는 IBM, 노벨, 싱가폴 국방부, 뮌헨시 등이 있으며, 국내는 동북아 시대위원회, 한국소프트웨어진흥원 등이 있다. 3. 공개소프트웨어의 신뢰도 공개소프트웨어 제품에 대하여 자주하는 질문들 가운데 하나는 과 연 공개소프트웨어 품질이 우수한가라는 것인데, 이러한 의문이 제기 되는 이유는 소스가 공개되어 있고 라이센스 비용 없이 사용할 수 있 는 공개소프트웨어 속성 때문이라고 할 수 있다

43 2장. 공개소프트웨어에 대한 오해와 진실 독점소프트웨어 업계와 마찬가지로 공개소프트웨어도 매우 다양한 소프트웨어를 사용할 수 있다. 정확한 통계가 나와 있지는 않지만 공 개소프트웨어로 등록된 소프트웨어는 대략 6~7만개정도가 되는 것으 로 알려져 있다. 이들에 대한 품질과 신뢰도를 측정한다는 것은 매우 어려운 일이나 많은 공개소프트웨어들이 실제 업무에 적용되고 있다 는 것은 신뢰도를 입증받고 있는 것으로 해석할 수 있다. 하지만 아 직 성숙되지 않은 공개소프트웨어들에 대해서는 그 품질과 안정성을 보장할 수는 없을 것이다. 이번 절에서는 공개소프트웨어의 신뢰도에 대한 여러 가지 오해와 진실을 살펴보면 다음과 같다. 첫째, 공개소프트웨어는 보안에 취약하다. 공개소프트웨어는 소스가 공개되어 있기 때문에 해커에 의한 해킹 공격을 받을 위험이 많는 견해가 있다. 하지만, 현재의 첨단 보안은 소스의 공개여부와 상관관계가 없는 것으로 보고하고 있다. 현재 인 터넷에서 사용하는 RSA 25) 보안 프로그램들은 알고리즘부터 소스까지 모두 알려져 있다. 즉, RSA보안 프로그램들의 소스가 공개되어 있다 고 해서 RSA알고리즘을 따르는 인터넷 보안체계가 취약한 것은 결 코 아니다. 뿐만 아니라 최근 발표되는 자료들에 따르면 공개소프트웨어인 리 눅스가 타 플랫폼보다 네트워크 보안이 우수한 것으로 나타나고 있 다. 2005년 7월 SANS 26) 가 발표한 보고서에 따르면 20개의 인터넷 25) RSA는 1977년에 Ron Rivest, Adi Shamir와 Leonard Adleman에 의해 개발된 알고리즘 을 사용하는 인터넷 암호화 및 인증 시스템이다. RSA 알고리즘은 가장 보편적으로 사용 되는 암호화 및 인증 알고리즘으로서, 넷스케이프와 마이크로소프트 웹브라우저 기능의 일부로 포함된다 26) SANS(SysAdmin, Audit, Network, Security)는 1989년에 설립된 보안 전문 연구소로써 정보 보안 트레이닝과 인증 분야에서 큰 영향력을 발휘하고 있다. SANS는 분기별로 리 눅스, 유닉스 및 윈도우, 매킨토시와 같은 다양한 플랫폼상의 보안 취약점을 분석하는 보고서를 발표하고 있으며, 보안 전문가들과 네트워크 사용자들에게서 가장 신뢰할 수

44 공개소프트웨어 안내서 보안 취약점들 가운데 단 2개의 가벼운 취약점만이 리눅스 플랫폼 사 용에 영향을 주는 것으로 나타났다. 27) 또한 가트너는 제로데이 어택(Zero-day Attack) 28 ) 시대라는 점을 기 준으로 볼때 리눅스의 보안성이 높은 것으로 보고하고 있다 29). 사실 보안성은 기업 및 기관에서 운영하는 IT인프라의 안정성 및 신뢰성과 직결되는 문제이다. 즉, 사내 인프라의 보안수준이 낮다면 기업이나 기관은 비지니스 연속성(Business Continuity)을 보장할 수 없을 뿐만 아니라 예기치 못한 장애로 막대한 피해까지 입을 수 있다. 이 같은 관점에서 볼 때 리눅스는 공개소프트웨어만이 제공하는 보안 메카니 즘을 통해 안정적인 서비스를 보장한다고 볼 수 있다. 리눅스의 보안 성이 얼마나 뛰어난지에 대한 대표적인 사례로는 미국 국가안전보장 국(NSA;National Security Agency)에서 학계, 업계의 보안 전문가들 의 참여를 통해 추진하고 있는 Security-Enhanced Linux 프로젝트가 있다. Security-Enhanced Linux는 운영체제 관련 가장 진보된 보안 프로젝트 중 하나로 평가받고 있으며 이 같은 프로젝트에 리눅스가 선택된 배경은 공개소프트웨어의 주요 특징 중 하나인 투명성 (Transparency)때문이다. 소스를 제공하지 않는 비공개 소프트웨어의 경우 보안 결점이나 버그들이 곳곳에 있어도 이를 공급자가 인지하고 개선안을 마련하기 전까지 알 수 없으나 공개소프트웨어는 소스 코드 분석을 직접 해볼 수 있어 사용자의 능동적인 대처가 가능하며, 공개 소프트웨어 지원업체 및 관련 커뮤니티를 통해 보안결점이나 버그들 있는 보고서라는 평을 받고 있다. 27) ZDNet Korea 인용 28) Zero-day란 보안취약점이 발견되고 이를 해결하기까지 걸리는 시간을 의미하며, Zero-day Attack이란 보안 취약점이 발견되었을 때 그 문제의 존재 자체가 널리 공표 되기도 전에 해당 취약점을 악용하여 이루어지는 보안 공격. 공격의 신속성을 의미하는 것이다. 29) John Pescatore, Open Source Security-SYMPOSIUM ITXPO 2004, Gartner,

45 2장. 공개소프트웨어에 대한 오해와 진실 에 대한 개선이 빠르게 일어나 각종 보안 침해 사고를 최소화 할 수 있다. 즉 소스가 폐쇄된 독점소프트웨어의 경우 보안상의 문제 발생 시 해당 업체의 대응을 기다리는 방법밖에 없지만 공개소프트웨어의 경우 보안 취약성과 같은 결함 발견 시 여러 업체 및 공동체의 공동 대응으로 짧은 시간 내에 패치 또는 업그레이드가 이루어지기 때문에 보안성이 높다고 할 수 있다. 둘째, 공개소프트웨어를 사용하면 바이러스에 감염이 잘 된다. 오히려 소스가 공개되어 있기 때문에 오히려 바이러스 침입에 신속히 대응할 수 있다. 따라서 일반 사용자가 아무리 악의적인 프로그램을 실행해도 시스템에 큰 영향을 주지 못해 바이러스 감염이 매우 적다. 셋째, 공개소프트웨어를 핵심 정보화 프로젝트에 도입하는 것은 매 우 위험하다. 리눅스는 단순한 파일, 프린트 서버의 영역을 벗어나 DBMS, 보안 등의 핵심 분야로 도입사례가 확대되고 있다. 2004년 10월 포레스터 리서치가 미국 140개 대기업을 대상으로 조사한 결과에 따르면 조사 대상 업체의 53%가 자사의 주요 핵심 업무용 소프트웨어 운영환경으 로 리눅스를 활용하고 있으며, 새로운 업무용 소프트웨어 도입에 있 어 리눅스를 선택할 의사 또한 52%에 달하는 것으로 나타났다 30 ). 신 뢰하기 어려운 운영체제라면 이렇게 다양한 분야에서 활용되지 못했 을 것이다. 최근 초대형 정부 핵심 정보화 프로젝트인 NEIS에 리눅 스가 채택되어 구축 중에 있다는 것만 보아도 핵심 정보화 프로젝트 에 리눅스가 매우 활발히 이용되고 있음을 잘 알 수 있다. 넷째, 리눅스가 유닉스에 비해 성능이 떨어진다. 30) Brad Day, Laura Koretzle, Linux Crosses Into Mission-Critical Apps, Gartner,

46 공개소프트웨어 안내서 TPC-C( SPECfp( 등에서 제공하는 각종 벤치마크 결과를 보면 리눅스는 유닉스와 윈도우에 비해 높은 성능을 나타냄을 쉽게 알 수 있다 31). 이들 데이터를 종합해 보면 리 눅스는 윈도우는 물론이고 유닉스보다도 대체적으로 높은 수준의 성 능을 보이고 있음을 알 수 있다. 예를 들어 HP가 발표한 자료에 따 르면 아이테니엄2를 장착한 4웨이머신인 HP rx5670의 경우 TPC-C 벤치마크 결과 리눅스를 사용할 때가 가장 높은 결과를 보이고 있으 며, 각종 SPEC벤치마크 결과역시 HP-UX에 비해 리눅스가 높은 수 치를 보이고 있다. 4. 완성도 및 수명 대부분의 공개소프트웨어 프로젝트에 사용되는 공동제작 모델은 사 용이 증가함에 따라서 완성도와 신뢰도가 향상되는 피드백 기반의 개 발 모델과 관련이 있다. 제품 수명주기 초기 단계에서, 공개소프트웨 어 어플리케이션은 독점소프트웨어의 배포 버전보다 강력하지 못하며 신뢰도가 떨어질 수 있다. 다수의 공개소프트웨어 개발 공동체는 조기 배포, 빈번한 배포(release early, release often)'라는 배포 철학을 따 르고 있다. 이러한 제품의 초기 버전들은 일반적으로 제한적인 채택 을 의도한 것이므로, 기관들은 중요한 기능을 위해 초기 배포버전을 도입은 주의해야 한다. 하지만 적절하게 설계되고 관리된다면, 공개소프트웨어 어플리케이 션은 눈에 띄게 급속도로 발전될 수 있다. 시장 요구를 충족시키는 공개소프트웨어 프로젝트는 추가적인 개발자, 개발업체, 초기 채택 기 술자들을 발생시키는 경향이 있는데 이러한 안정적인 프로젝트 관리 31) 이들 사이트에서는 주요 시스템 업체별 제품의 각종 벤치마크 결과를 확인할 수 있다

47 2장. 공개소프트웨어에 대한 오해와 진실 및 개발 속도가 빠르게 확산되고 있는 소프트웨어가 리눅스이다. 리눅스는 개발자의 확대 및 사용자 증대에 따라 문서화, 웹사이트, 메일링 리스트 지원 및 토론 포럼 등이 활발히 전개되어 소프트웨어 완성도가 성숙단계에 진입한 것으로 인정받고 있는 대표적인 공개소 프트웨어이다. 대부분의 공개소프트웨어 개별분야마다 일반적으로 하나 이상의 경 쟁업체들이 존재한다. 이는 특히, 다른 생태계 또는 영역으로 구분이 가능한 분야에서 나타날 수 있다. 컴퓨터 운영체제가 가장 적절한 예 이다. 이러한 운영 체제의 사용은 다른 공개소프트웨어 프로젝트가 특정용도(이동 장치, 데스크탑 시스템, 서버) 또는 특정 기술 모델(분 산 컴퓨팅, 그리드 컴퓨팅, 단일 서버)을 목표로 하여 동시에 성공을 거둘 수 있을 정도로 다양하다. 공개소프트웨어는 비공개 소프트웨어에 비해 안정성이 떨어진다는 견해가 있으나, 포스코, 현대기아자동차 등 리눅스를 도입한 대기업들 은 모두 리눅스의 '안정성'을 주요 도입 배경으로 꼽고 있다. 리눅스 는 특히 운영체제 수준에서 제공하는 안정성이 뛰어난 것으로 평가받 고 있다. 기업이나 공공기관에서 시스템의 안정성은 곧 서비스의 신 뢰성과 직결되는 문제이다. 리눅스의 경우 유닉스에 버금갈 뿐만 아 니라 윈도우에 비해서는 탁월한 안정성을 자랑한다. 32) 그리고 공개소프트웨어의 또 다른 안정성에 대한 의문은 공개소프 트웨어를 도입하면 기존의 소프트웨어와 시스템을 모두 바꿔야 한다 고 생각하는 경향이 있다. 32) 공개소프트웨어 도입사례는 한국소프트웨어진흥원 발행 공개소프트웨어 도입 성공사례집 참고

48 공개소프트웨어 안내서 주요 소프트웨어 개발업체들은 새로운 소프트웨어 개발 시 가장 먼 저 포팅 해야 할 대상으로 유닉스가 아닌 리눅스를 선택하고 있다. 주요 유닉스 벤더들의 최근 유닉스 버전들은 리눅스에서 운용되는 소 프트웨어를 운용 하는데 있어 포팅 이슈가 거의 없어졌다. 오히려 리 눅스용으로 포팅된 것이 역으로 최신 유닉스 플랫폼으로 이식되기도 한다. 이는 지난 3~4년간 기존 소프트웨어 기업들이 제품 개발 시 목표 플랫폼으로 유닉스를 지원했던 경향이 이제는 리눅스가 최우선 포팅 대상으로 변화하고 있기 때문이다

49 3장. 공개소프트웨어 도입유형 및 절차 3장. 공개소프트웨어 도 입유형 및 절차

50 BLANK

51 3장. 공개소프트웨어 도입유형 및 절차 1. 도입유형 공개소프트웨어를 도입하는 방법에는 크게 3가지 방법이 있다. 첫 째 기관이 직접 선택하여 도입하는 직접선택, 둘째 민간기업 등 외부 의 추천에 의한 간접공급, 셋째 기관내부에서 공개소프트웨어를 개발 및 수정하는 내부개발 등이다. 이들 3가지 도입방법들에 대한 자세한 설명을 하기에 앞서 공개소 프트웨어를 도입함으로써 얻을 수 있는 기대효과와 장점은 어떤 것들 이 있는가를 살펴보면 다음과 같다. 첫째, 소프트웨어의 유지관리의 지속성(영속성)을 보장 받는다. 원공급자가 폐업하여 사라지거나 지원을 중단하더라도 공개된 소스 를 보유하고 있으므로 기관은 해당코드를 새로운 공급자에게 양도함 으로써 정보시스템 유지관리의 지속성(영속성)을 보장받는다. 둘째, 소프트웨어 도입 및 정보시스템 구축비용을 절감할 수 있다. 독점소프트웨어는 라이센스 수수료와 함께 서비스 및 기술지원 비 용을 발생시키지만 공개소프트웨어는 라이센스 수수료에 대한 비용 대신에 서비스 및 기술지원비용만을 발생시킨다. 따라서 공개소프트 웨어를 도입하면 도입비용을 현저하게 낮춘다. 또한, 유지보수 측면으 로 보면 공개소프트웨어는 소스코드에 바로 접근하여 수정할 수 있는 권한이 확보되므로 유지보수 및 업그레이드에 투여되는 예산을 줄일 수 있다. 셋째, 높은 호환성을 보장받는다

52 공개소프트웨어 안내서 공개소프트웨어는 다양한 형태의 소스코드를 배포하고 있으므로 상 대적으로 많은 플랫폼에 이식가능하며 또한 이와 같은 플랫폼 독립성 (호환성)은 수요자에게 하드웨어 선택의 폭을 넓혀준다. 넷째, 패치와 업그레이드 주기 및 속도가 빠르다. 공개소프트웨어는 소스코드가 공개되어 있고 많은 개발자들이 함께 공동 작업을 하고 있으므로 보안취약성등과 같은 결함을 발견한 후 몇 시간 또는 몇 일내에 재빨리 패치 및 업그레이드가 이루어지므로 보다 안전하게 시스템을 운영할 수 있다. 다섯째, 독점소프트웨어를 공급하는 업체로 부터의 구속을 탈피할 수 있다. 공개소프트웨어는 동일한 제품에 대해서도 공급자가 다수업체가 될 수 있기 때문에 공급자의 불합리성에 보다 적극적으로 대처할 수 있 으며 또한 독점소프트웨어에 대한 구속을 회피할 수도 있다. 즉, 독점 소프트웨어의 경우에는 선택의 여지없이 사용해야 만하는 불합리성이 존재할 수 있지만 공개소프트웨어는 공급업체와 제품이 다수이기 때 문에 이와 같은 구속은 존재하지 않는다. 여섯째, 소스코드의 수정 및 확장권한을 확보할 수 있다. 독점소프트웨어는 컴파일된 실행파일 즉, 이진파일형태로 제공되기 때문에 소스코드를 수정하거나 확장을 위한 변경작업을 할 수가 없으 나, 공개소프트웨어는 소스코드가 공개되어 있기 때문에 현재 시스템 에 적용되어 있는 소프트웨어의 수정과 추가 확장을 위한 변경작업이 얼마든지 가능하다. 일곱째, 공공부문의 정보시스템 통합이 용이하다

53 3장. 공개소프트웨어 도입유형 및 절차 정부 및 공공부문의 정보시스템 구축 시에 핵심모듈을 공개소프트 웨어로 구축할 경우 공공부문의 개방표준화가 용이하게 되어 정보화 예산을 절감하고 호환성 및 이식성을 확보하여 공공부문 전체의 정보 시스템 통합을 촉진시킬 수 있다. 여덟째, 수요자 권리를 확보할 수 있다. 공개소프트웨어 도입 확대는 소프트웨어산업이 공급자 위주의 시장 으로부터 소프트웨어 수요자(사용자, 정부) 위주의 시장으로 전환하는 데 중대한 역할을 할 수 있다. 독점소프트웨어 업체들이 그들의 소프 트웨어를 공급하면서 독점지위를 유지하기 위하여 소스코드가 아닌 실행파일 형태로 제공하고 있다. 하지만 이것은 지극히 공급자 위주 의 관점이며 소프트웨어를 구매하는 수요자의 입장에서는 소프트웨어 구매와 함께 소스코드를 요구할 수도 있다고 볼 수 있다. 단순히 소 스코드만을 요구하는 것이 아니라 공급업체가 없어지거나 사라지더라 도 도입한 시스템의 유지보수와 패치 및 업그레이드 등을 보장받으려 면 소스코드가 공개되어 있지 아니하고서는 불가능한 일이기 때문이 다. 따라서 소비자들이 이러한 유지보수, 패치, 업그레이드 등을 보장 받으려면 독점소프트웨어로는 그 한계가 있기 때문에 공개소프트웨어 를 사용하여 그 권한을 보장받을 수 있는 것이다. 공개소프트웨어는 수요자 측면에서의 이러한 장점과 함께 국가산업 적 측면에서는 소프트웨어 개발 원천기술을 확보함으로써 지식기반경 제 핵심 산업인 소프트웨어산업의 경쟁력을 강화시키고, 최신기술의 공개, 개발자 커뮤니티 등을 통한 기술교육에 의하여 국내 소프트웨 어제품의 선진제품과의 기술격차를 줄일 수 있으며, 빠른 신제품 개 발 등 시장에 즉시 대응이 용이하며 개발의욕 고취를 통한 양질의 핵 심소프트웨어 인력양성이 가능하다는 장점이 있다

54 공개소프트웨어 안내서 직접선택, 간접공급 내부개발 도입방법 이외에도 다양한 방법들이 존재할 수 있지만 공개소프트웨어를 도입하는 거의 모든 경우는 대부 분 이 세 가지 범주 내에 속하기 때문에 이번 절에서는 이들 3가지 방법에 대해서 설명한다. 가. 직 접 선 택 직접선택("내부조달"이라고도 함)이란 공개소프트웨어 리소스 사이 트에서 사용자가 특정 공개소프트웨어를 직접 다운로드하여 활용하는 것을 의미한다. 물론 다운로드 행위자체가 기관 내부의 직원에 의해 수행되며 기관 내부에서 공개소프트웨어 관련 정보가 어느 정도 확보 되어 있어야 가능한 방법이다. 이 방법은 비용발생이 거의 없다는 장 점이 있는 반면 위험부담이 크다는 단점이 있다. 특정 공개소프트웨어를 직접 다운로드 한다는 것은 독점소프트웨어 를 공급업체로 부터 구매하는 것에 비한다면 기술검증에 대한 책임을 스스로 부담한다는 단점이 있다. 즉, 다운로드하는 소프트웨어 내에 트로이목마와 같은 바이러스 코드가 들어있다거나 키로거 (key-logger)와 같은 악성 소프트웨어에 의한 감염을 포함한 소프트 웨어가 될 수 있기 때문이다. 그러나 세계적으로 사용빈도가 높은 공 개소프트웨어를 공식 사이트로부터 다운로드받는다면 이러한 부담을 제거할 수 있으며, MD5 33) 등의 무결성 체크를 선행하는 경우 대부분 해결이 가능하다. 33) 암호화 알고리즘인 해쉬 함수의 일종으로 미국표준은 SHA-1(Secure Hash Algorithm) 이며, 산업계에서는 MD2, MD5 등을 주로 사용한다

55 3장. 공개소프트웨어 도입유형 및 절차 그리고 또 다른 문제점은 다운로드한 공개소프트웨어의 보상과 보 증이 보장되지 않는다는 것이다. 즉, 공개소프트웨어 솔루션을 기관내 부에서 직접 선택하여 도입하려고하는 경우에는 소프트웨어의 보증과 보상을 보장받지 못하므로 이에 대한 위험감소 대책을 고려해야만 한 다. 기관에서 공개소프트웨어 도입시 각 분야에서 신뢰도가 높은 소 프트웨어는 < 부록1 >을 참고할 수 있다. 34) 이러한 위험에 대한 대책으로는 지역 내에 기술지원이 가능한 개발 업체가 하나이상 존재하는 공개소프트웨어를 선택하는 것이다. 이와 같은 대책을 마련해 둔다면 공개소프트웨어를 도입한 기관이 직접 해 결하지 못하는 기술적 문제에 대해 안정성을 보장 받을 수 있다. 즉, 도입기관의 시스템 운영자는 대부분 매일의 주기적이고 반복적 인 업무는 수행할 수 있다 하더라도 기술지원업체를 미리 확인하고 점검해 두는 것은 2중 3중의 안전장치를 가지는 것이며 시스템 가용 성을 더욱 높이게 되어 위험요소를 감소시킬 수 있다. 직접선택 방법 으로 공개소프트웨어를 도입할 경우 다음의 절차를 따를 것을 권고한다. 34 ) <부록 1> 신뢰성이 높은 공개소프트웨어와 <부록 2> 공개소프트웨어와 비공개소프트웨어 안내 참고

56 공개소프트웨어 안내서 <표 3> 공개소프트웨어 도입 절차 직접선택 워크플로우 1 단계 공개소프트웨어 솔루션 조사 35) 2 단계 유력한 공개소프트웨어 솔루션 선택 3 단계 솔루션의 목적에 맞는 적합성과 비용적 가치 검토 4 단계 솔루션의 품질과 보안성 분석 5 단계 예비 프로젝트 수행 6 단계 예비 프로젝트 결과를 통하여 기본적 수준의 예측사항 검토 7 단계 프로젝트 수행 계획 수립 8 단계 프로젝트 수행 특정 공개소프트웨어 제품이 기관의 요구조건을 충족시킬 경우 도 입에 앞서 해당 기관에서 보다 상세한 검토를 수행하기로 결정하기로 하였다면 다음과 같은 체크리스트를 작성하고 평가과정을 거치도록 해야 한다. <표 4> 직접선택방식 도입 전 체크리스트 1 기관에서 사용되는 운영체제 플랫폼에서 해당 공개소프트웨어가 실행되는가? 2 해당 공개소프트웨어가 기존의 운영체제 플랫폼에 대해 획득, 시험, 배치해야 하는 추가적인 시스템 구성요소, 라이브러리 또는 모듈을 필요로 하는가? 3 해당 공개소프트웨어의 설치 절차가 이해하기 쉽고 명확하게 정의되어 있는가? 4 도입기관이 목적에 대한 적합성 여부를 결정할 수 있도록 공개소프트웨어를 설치, 배치, 시험할 수 있는 내부 전문지식을 갖추고 있는가? 5 해당 공개소프트웨어의 설치 및 제거 절차가 명확하게 정의되어 있는가? 35) 다양한 공개소프트웨어 프로젝트 정보는 <부록 3> 공개소프트웨어 리소스 참조

57 3장. 공개소프트웨어 도입유형 및 절차 나. 간접 공 급 간접공급("외부조달"이라고도 함)이란 공개소프트웨어를 업체로 부 터 공급받는 것을 의미한다. 즉, 공개소프트웨어 공급 전문기업으로부 터 특정 공개소프트웨어를 공급받는 것으로 기술지원과 서비스 비용 이 발생한다. 비용이 발생하는 대신 직접선택 방법에 비해 위험부담 을 줄일 수 있는 안전한 방법이라고 할 수 있다. 간접공급 방식으로 공개소프트웨어를 도입하였다면 라이센스에 관 련된 법적인 위험요소에 대한 책임은 원칙적으로 공급업체에 있다. 하지만 이 경우에도 공급업체와의 계약서 내용에 따라서 법적인 책임 소재가 달라질 수 있으므로 이 부분에 대한 확인을 반드시 해야 한 다. 즉, 기관은 기술적인 위험요소와 변경관리 위험요소를 감소시키기 위한 적절한 실사조사를 수행해야 한다. 즉, 기관이 공개소프트웨어 솔루션을 위해 간접공급 방식을 선택한 경우, 해당 업체 즉, 공급업체 가 모든 기술 지원에 있어 책임을 져야하며 기관은 공급업체가 해당 공개소프트웨어에 대한 적절한 위험경감 절차를 수행함을 확인해야한 다는 의미이다. 다음은 간접공급 방식의 몇 가지 공급유형을 나타낸 것이다

58 공개소프트웨어 안내서 <그림 1> 공개소프트웨어 간접공급 유형 이 외의 사항은 비공개소프트웨어를 도입할 때와 고려사항 및 절차 가 유사하다. 예를 들어 기관이 네트워크 및 시스템에 도입된 소프트 웨어 보안표준에 대한 정책을 이미 보유하고 있을 경우에 개발업체는 위험분석의 일환으로 그러한 정책을 반드시 준수해야 한다. 또한 모 든 절차가 끝난 후 검수작업 시에도 보안 표준과의 일치성 여부를 확 인하도록 해야 하며 계약서 내에 이러한 모든 절차들이 포함되어 있 어야한다. 또한, 기관은 개발업체에게 모든 소프트웨어 구성요소에 대한 공급 을 확인해야 하며 소프트웨어 출처와 라이센스 계약, 그리고 위험평 가 문서를 확인해야 한다. 그리고 비공개소프트웨어를 도입할 때와 마찬가지로 도입된 공개소프트웨어의 전체적인 통합문제를 분석하고 이를 파악하여 반드시 문서화해야 하며 개발업체의 수행능력을 확인 할 수 있도록 자체평가를 수행할 수도 있다

59 3장. 공개소프트웨어 도입유형 및 절차 비공개소프트웨어를 업체로부터 도입할 때와 마찬가지로 간접공급 방법은 개발업체의 적격성, 확장성, 소프트웨어의 성숙도 등에 관련된 분석이 선행되어야 하며 이러한 문제는 소규모 개발업체와 거래할 때 특히 신중히 검토되어야 한다. 따라서 앞서 설명한 바와 같이 잠재적 인 위험요소를 줄이기 위하여 개발업체에 대한 적절한 실사조사 및 평가는 반드시 이루어져야하며 또한 평가 결과에 따른 조치가 이루어 져야 한다. 다음은 이러한 평가에 반드시 포함되어야 할 내용들이다. 재정적 보장 및 안정성 위험관리의 적격성 내부 관리의 평가 업무 지속성 계획의 검토 일반적인 기능 개요 서비스 전달 및 관리 기타 기관의 특성에 맞는 평가요소 실제로 기관들은 공개소프트웨어 제품을 직접선택(내부조달)을 하 기 위한 기술적인 능력을 갖추지 못한 경우가 대부분이므로 외부의 서비스 제공업체를 통해 공개소프트웨어 솔루션을 도입 받는 간접공 급(외부조달)방법을 선택하는 것이 바람직하다. 그리고 잘 알려져 있고 인기 있는 대부분의 공개소프트웨어 제품들 은 상용 솔루션 제공업체들을 통해 공급이 가능하다. 하지만, 외부의 어떤 업체를 통해 공급받더라도 공개소프트웨어와 비공개 소프트웨어 (독점소프트웨어)의 공급에는 차이점이 있다. 즉, 기관이 외부 서비스 업체를 통해 공개소프트웨어 솔루션 또는 제품을 공급받는 경우 일반 적으로 관련 공개소프트웨어는 무료로 제공받고 이에 대한 서비스를 구입한다. 이것은 라이센스를 구입하고 부가가치 서비스로 지원을 제

60 공개소프트웨어 안내서 공받는 비공개 소프트웨어(사유소프트웨어)의 경우와 차이가 있다. 그리고 기관이 외부 공급업체를 선택하기에 앞서 후보 업체들에 대 한 실사로서 재정 상황, 안정성, 기술 능력 등을 평가해야 한다. 이러 한 평가 작업들은 커뮤니티의 지원이 사라질 수 있는 위험한 제품선 택에 대하여 위험을 줄여준다. 그리고 도입 후 어느 시점에 외부 공 급업체가 사라지더라도 다른 공급업체에게서 지원을 계속 받을 수 있 는 안정성과 유연성을 제공해 준다. 다. 내부 개 발 내부개발이란 기관내부에서 직접 개발하는 방법을 의미하며 공개되 어 있는 수많은 공개소프트웨어들 가운데 도입하고자 하는 용도에 가 장 적합한 공개소프트웨어를 선택하고 다운로드하여 기관내부의 개발 자들에 의해 수정 개발하는 것을 의미한다. 아무것도 없는 상태에서 처음부터 개발하는 것이 아니라 공개되어 있는 수많은 공개소프트웨 어들 가운데 도입하고자 하는 용도에 가장 적합한 공개소프트웨어를 선택하고 다운로드하여 기관내부의 개발자들에 의해 수정 개발하는 것을 의미하는 것이다. 기관내부 개발 방법으로 공개소프트웨어를 도입할 때에 고려해야 할 사항들을 간단히 정리해 보면 다음과 같다. 1 가장 적합한 공개소프트웨어 선택기준 마련 2 다운로드한 공개소프트웨어의 안정성 검토 3 적용되는 라이센스 정책마련 4 가장 적합한 개발방법론 마련 5 개발 직원의 개발능력 검토

61 3장. 공개소프트웨어 도입유형 및 절차 6 사용직원의 사용법 교육 안 마련 7 개발소프트웨어의 문서화 작업 8 개발된 공개소프트웨어의 안정성과 영속성 대책 마련 9 기타 특정업무의 종속되는 대책 마련 등 다음은 실제 내부 개발을 추진한 경우 필요한시에 단계별 개발절차 이다. o 서 비 스 의 정 의 및 적용업 무 분 석 가장 먼저 해야 할 작업이 어떤 업무에 적용하기 위하여 공개소프 트웨어를 도입할 것인가를 정의해야하는 작업이다. 즉, 이러한 작업을 "서비스 정의"작업이라고 할 수 있으며 웹기반으로 개발할 것인지 아 니면 기관내부 솔루션으로 사용하기위한 개발인지 아니면 유관기관과 의 정보공유 및 협동 네트워크를 위한 개발인지를 정확하게 구분하고 이를 정의해야 한다. o 기 반 기 술 정 의 다음 단계는 개발기술에 대한 분석과 정의이며, 공개소프트웨어의 개발에 필요한 기반기술들을 간단히 정리하면 다음과 같다. 1 운영체제, 웹서버, DBMS, 사용 언어 등에 대한 기반기술 분석 및 정의 2 공용 framework 개발 및 업무 서비스 요구 분석 및 설계 기술 3 분산 DB 구축 설계 및 관리 기술 4 그룹웨어의 확장 및 공유 수준 지정에 의한 access 범위 설정 기술

62 공개소프트웨어 안내서 5 유관 기관 간 정보 DB 표준화 (XML 기반) 이와 같이 관련 기반기술들이 정의가 되어 있어야 하며 개발 직원 에 대한 교육과도 연계되어야 할 항목이다. o 적용 업 무 에 대 한 분 석 개발하려는 공개소프트웨어가 적용될 업무에 대한 기본적인 분석이 이루어 져야한다. 즉, 공개소프트웨어를 직접 개발하기 이전에 다음과 같은 사항들이 이미 검토되어야 한다. 1 활용성 : 개발 이후의 당기관 또는 유관기관에서의 활용성 2 수요의 규모 : 개발한 공개소프트웨어의 수요정도에 대한 검토 3 재활용성 : 개발한 공개소프트웨어가 타 업무에 재활용 가능 여부 4 표준성 및 표준의 준수여부 o 개 발기 간 및 투 입 인 력 분 석 공개소프트웨어를 직접 개발하기 위해서는 개발기간과 투입인력에 대한 분석과 정의가 이루어져야 한다. 개발기간에 대한 정의는 다음 을 고려하여 작성하도록 한다. 1 5단계 개발기간 분석 : 요구분석기간, 분석기간, 개발기간, 수정 및 검토기간, 적용 및 안정화기간에 대한 분석 및 각 기간별 위 험관리 대책 마련(개발기간의 준수여부에 따라 기간초과에 따르 는 위험관리)

63 3장. 공개소프트웨어 도입유형 및 절차 2 개발인력에 대한 대책 기반 기술(주로 Language)에 가장 적합한 기술인력 활용 개발경험이 있는 내부 개발 직원 활용 개발책임자(PM)을 선정하여 프로젝트로 진행 개발 분야에 따라 외부 개발 직원을 투입대책 마련 개발자 교육 대책 마련 o 개 발한 공 개 소 프 트 웨 어 의 사 후 관 리 문 제 내부개발에 의해 개발 완료된 공개소프트웨어는 일회성 프로젝트로 끝나지 않도록 사후관리가 이루어져야 한다. 사후관리에는 개발 직원 에 대한 사후관리를 포함한다. 사후관리는 개발한 공개소프트웨어를 관리대장에 등록하여 지속적 인 관리가 이루어지도록 한고, 개발 시에 사용한 기술을 종합 정리하 여 이를 문서화하고 36), 개발한 공개소프트웨어의 설치문서, 사용법문 서, 업그레이드 문서 등을 표준화하여 작성한다. 지금까지 설명한 내부개발 방법을 설명하였다. 기관 내부에 공개소 프트웨어 개발자를 확보하기 어려울 뿐만 아니라 프로젝트 진행을 위 한 관리자 확보가 어렵기 때문에 현실적으로 내부개발 방법으로 개발 하는 경우는 거의 없다. 개발자나 프로젝트 실무자를 확보하고 있다 하더라도 실제 진행을 위해서는 보직변경 및 장기간 동일업무 종사여 건등과 같은 조직내부적인 환경이 갖추어져야 할 것이다. 결론적으로 내부개발의 방법으로 프로젝트를 진행하기란 현실적인 어려움들이 존 재하는 것이 사실이고 이러한 현실적인 어려움을 극복하고 프로젝트 36) 문서화를 할 경우에 업그레이드 및 패치 방법 및 적용 방법 등에 대한 문서를 포함시 켜야 한다

64 공개소프트웨어 안내서 를 진행한다 하더라도 개발 및 프로젝트 노하우의 축적이 지속되기란 더욱 어려운 실정이다. 라. 종 합 비 교 지금까지 설명한 직접선택, 간접공급, 내부개발 3가지 방법에 대한 장단점을 종합비교하면 다음 표와 같다. 공공기관에서 3가지 방법 중 하나를 선택하여 공개소프트웨어를 도입할 수는 있지만 국내 공개소 프트웨어 업계의 현실과 기관의 현실을 고려할 때에 가장 현실성이 고, 일반적으로 사용할 수 있는 방법은 간접공급 방식이다. <표 5> 공개SW 도입방식에 따른 비교 직접선택 간접공급 내부개발 내용 장점 단점 소프트웨어를 직접 다운 로드 하여 사용목적에 소프트웨어를 외부업체로 내부의 개발자들에 의해 맞게 활용하는 것 부터 공급받는 것을 의미 수정 개발 비용발생이 거의 없다 소프트웨어의 보상과 보 증이 보장되지 않으므로 위험부담이 크다 직접선택 방법보다는 위 험부담을 줄일 수 있는 개발 및 프로젝트 노하 안전한 방법 우의 축적 기술지원과 서비스 비용 을 지불해야하기 때문에 비용적인 부담발생 개발자 확보 어려움 프로젝트 실무자 확보 어려움 보직변경 및 장기간 동 일업무 종사여건 등 조 직내부적인 기반환경필요 주의 사항 지역 내에 기술지원이 가능한 개발업체가 하나 이상 존재하는 공개소프 트웨어를 선택함으로써 도입기관의 안정성확보 개발업체에게 모든 소프 트웨어 구성요소에 대한 완전한 감사를 수행하도 록 하여 소프트웨어의 출 처와 라이센스계약, 그리 고 위험평가 문서를 확인 개발업체의 수행을 확인 할 수 있도록 자체평가를 수행 개발기간과 투입인력에 대한 세심한 분석과 정 의가 필요 기간별 위험관리대책 필 요 개발인력 준비방안 필요 개발한 소프트웨어의 사 후관리대책 필요

65 3장. 공개소프트웨어 도입유형 및 절차 2. 도입절차 정부기관 및 공공부문에서 시스템을 도입하거나 소프트웨어를 도입 하는 일반적인 절차는 다음 표와 같다. 각 단계에서 공개소프트웨어 도입을 위한 주요 검토사항은 다음과 같다. <표 6> 공개SW 도입을 위한 주요 검토 사항 단 계 ( 절 차 ) 내 용 ㅇ 과제 발굴(대부분 사업 전년도), 예산편성 사업계획서 작성 ㅇ 사업 타당성, 적정성 검토 ㅇ 사업 추진계획서 작성(최종 사업계획서 작성) ㅇ 제안요청서 작성 제안요청서 작성 (객관성 및 타당성 검토가 절실히 요구되는 단계) ㅇ 입찰공고 사업공고 및 제안서 접수 ㅇ 제안설명회 ㅇ 사업제안서 접수 ㅇ 제안서평가(평가위원회) 제안서평가 및 선정 ㅇ 원가분석 ㅇ 기술협상 및 가격협상 계약체결 ㅇ 최종계약체결 사업수행 결과보고 ㅇ 사업수행(계약체결일로 부터 사업 진행) ㅇ 진도보고(착수, 주간, 중간보고 등) ㅇ 완료보고 ㅇ 최종 결과보고서 평가(검수) o 사 업 계 획 서 작 성 단 계 추진 과제를 발굴하여 사업 타당성과 적정성을 검토한 후 사업계획 서를 작성한다. 주관기관은 사업계획 수립 시 비공개소프트웨어와 함 께 공개소프트웨어 도입을 고려하되, 시스템 개발 시 개방 표준(Open Standard) 37) 을 지원하고 개방형 플랫폼(Open Platform) 38) 과 상호 호 환성을 가지는 제품을 우선 고려해야 한다. 37) 개방 표준이란 ISO, W3C 등 국제기구나 단체에서 수용한 기술표준을 의미한다. 38) 개방형 플랫폼이란 개방표준에 부합하는 소프트웨어, 하드웨어를 의미한다

66 공개소프트웨어 안내서 o 제안 요청 서 작 성 단 계 사업자 선정을 위한 제안요청서(RFP, Request For Proposal)를 작 성한다. 제안요청서는 사업 프로젝트 수행에 있어서 매우 중요한 역 할을 하는 만큼 제안요청서 작성 시 비표준 조건과 특정기술 등의 제 약을 두지 않도록 매우 주의해야하는 단계이다. 즉, 고의, 부주의 또 는 업무관습 등으로 인하여 주관기관에서 제안요청서 작성 시 운영체 제와 하드웨어 플랫폼 등과 같이 매우 중요한 부분의 요구사항에서 특정 기업 제품 또는 기술표준만 제안 가능한 기술요건을 명시할 경 우 불공정경쟁을 초래할 수 있으므로, 다음 표를 참고하여 비 표준적 이거나 특정 기술조건을 명시하지 않도록 주의하여야 한다. <표 7> 비표준 특정기술 조건 예 구 분 요구조건 특정기술조건 예 공통 특정업체 특정제품만 가능한 사양. PCI Slot 48개 한정. 특정 locking 명시 하드웨어 (Server) 주변기기 운영체제(OS) WAS 웹서버 (WebServer) DBMS 어플리케이션 특정 운영체제 아키텍처기반의 CPU를 명시 특정 제품만 가능한 성능, 품질등 의 인증요구 특정 운영체제만 지원하는 주변기 기 채택 특정 운영체제만 지원하는 소프트 웨어 개발언어 및 기술사용 특정 운영체제를 명시 특정 개발 툴에 종속된 개발환경 요구 특정 운영체제상에서만 운용이 가 능한 제품 채택 특정 웹어플리케이션 개발 언어의 사용요구 특정 운영체제상에서만 운영이 가 능한 제품 채택 특정업체에 기술 종속적이며 사용 자의 선택권을 제한하는 소프트웨 어 지정. RISC, SPARC. 특정업체 인증 tpmc요청. Windows XP 전용 스캐너. ActiveX, ASP, WMV로 개발. UNIX 플랫폼지원. Windows 플랫폼지원. 특정 세션관리 기법제시. IIS 도입. ASP 사용 개발. 특정 Locking 기법 제시. Windows Media Player

67 3장. 공개소프트웨어 도입유형 및 절차 그리고 제안요청서 작성 시에 기관은 시스템 계층별 독립성을 확보 하기 위하여 제안요청서상의 도입대상 장비 내역 및 구성요건 작성 시 다음 사항을 요구할 필요가 있다. 첫째, 특정 하드웨어에 종속된 특정 운영체제를 선택할 수밖에 없 는 상황을 초래하지 않도록 하기 위하여 하드웨어와 운영체제를 별도 의 항목으로 명시하고, 별도의 비용으로 계상한다. 둘째, 특정 운영체제에 종속된 특정 응용 소프트웨어를 선택해야만 하는 상황을 초래하지 않도록 하기 위하여 응용 소프트웨어와 운영체 제를 별도의 항목으로 명시하고, 별도의비용으로 계상한다. 그리고 포털사이트 구축 사업 또는 웹 기반의 서비스 구축 사업을 진행할 경우 주관 기관은 제안요청서 작성 시 국민의 "정보 접근권 보장"을 위하여 "다양한 컴퓨팅 환경에서 접근 가능하도록 국제표준 을 준수하는 제품도입 및 개발"에 대한 항목을 명시하도록 한다 39). 그리고 BPR/ISP 40) 사업의 제안요청서 작성 시에는 공개소프트웨어 적용 가능성 분석을 포함시킴으로써 사업 초기단계부터 공개소프트웨 어기반의 시스템 구축 가능성을 검토함으로써 시스템의 상호운용성을 확보할 필요가 있다. 마지막으로 공개소프트웨어를 제안하는 사업자는 사업완료 이후 ' 39) 사용자의는 운영체제(Windows, Linux등), 웹 브라우저(Internet Explorer, Mozilla, FireFox, Safari등)등에 관계없이 누구나 시스템에 접근 가능하도록 해야 함을 의미한다. 40) 업무프로세스 재설계-Business Process Reengineering / 정보 전략계획-Information Strategy Planning

68 공개소프트웨어 안내서 공개소프트웨어 유지보수 방안 제시'에 대한 항목을 반드시 명시하도 록 함으로써 공개소프트웨어에 대한 기술지원 및 유지보수 서비스를 보장 받아야 한다. o 제안 서 ( 제안 업 체 ) 평 가 및 선 정 단 계 일반적으로 사용하는 제안서 평가항목은 다음과 같다. 1 유사분야에서의 사업수행 경험 2 개발대상 업무의 이해도 3 개발전략 4 기능 및 성능 5 개발방법론 6 기타 주관기관의 평가항목 각 항목별 세부 평가요소들은 주관기관의 사업추진 방향에 따라서 다소 달라질 수 있다. 특히, 소프트웨어 평가 시 동등 성능일 경우 공 개소프트웨어를 제안한 업체를 우선 고려할 경우 정보화예산을 절감 할 수 있는 장점이 있다. o 사 업 수 행 및 결 과 보 고 단 계 공개소프트웨어를 적용하여 시스템을 구축하였을 경우 제공하는 소 프트웨어의 소스코드를 확보하여야 한다. 특히, 제안업체에서 소스코 드를 일부 수정하였을 경우에는 수정부분에 대한 문서화와 필요한 경 우 해당 소프트웨어 개발 커뮤니티에 정보를 제공함으로써 공개소프 트웨어 발전에 기여할 필요가 있다

69 3장. 공개소프트웨어 도입유형 및 절차 3. 적용시스템 전자정부 등 공공 정보시스템 구현시 목표로 하는 시스템을 서비스 측면으로 보면 크게 정책결정 시스템, 거래 처리 시스템, 지식정보 시 스템 등 세 가지 유형으로 구분할 수 있다. 다음에서는 정보시스템 구축 유형별 고려사항과 공개소프트웨어 기반의 정보시스템 구축시 필요한 시나리오별 구현방법을 소개한다. 가. 시 스 템 유 형 4 1) o 정 책 결 정 시 스 템 정책 결정 시스템은 어떤 하나의 안건에 대해 다수의 의견을 모아 이를 정책에 반영하고 스로인해 원만하고 활발한 정책 적용 및 이에 영향을 받는 구성원들의 참여를 이끌어 내는 것을 목표로 한다. 따라 서 정책 결정 시스템에서 제공하는 서비스는 구성원들의 참여를 이끌 어내기 위한 것과 공정하게 의견을 반영하는 것, 그리고 결정된 안건 이 구성원들의 의견을 받아들여 투명하게 수행되고 있다는 것을 보여 주는 데에 목적을 둔다. 따라서 아래와 같은 세부 서비스를 정의할 수 있다. 첫째, 구성원들의 참여도 향상 서비스로써 구성원들의 참여도를 증 가시키기 위해서는 언제 어디서나 구성원들이 자신의 의사를 전자정 부 시스템에 반영할 수 있는 인터페이스가 갖추어져야 한다. 전자정 41) 정태염 외, 효율적 전자정부구현을 위한 기반기술 도입 정책연구, 한국소프트웨어진흥원, 2003 참조

70 공개소프트웨어 안내서 부에서는 웹 기반의 의견 수렴 도구를 구축하여 사용자들의 접근이 쉽고 수많은 접속자들로부터의 의견을 반영할 수 있도록 공개된 웹서 버를 통한 서비스를 제공해야 한다. 세부적인 서비스로는 선거나 토 론을 위한 온라인 선거 서비스, 온라인 토론방 외에도 각종 건의사항 을 빠르게 반영할 수 있도록 온라인 건의사항 수렴서비스 등이 존재 할 수 있다. 둘째, 의견 반영 서비스로써 구성원들의 참여도가 향상되어 인터넷 을 통한 구성원들의 의견을 수렴하면 이를 실제 정책에 적용하고 평 가하는 과정에 대해 구성원들에게 신뢰감을 심어줄 수 있는 서비스가 제공되어야 한다. 이러한 서비스의 세부 내역으로는 정책을 적용하고 이를 수행하는 관리자나 혹은 관련 단체에서 보다 빠르게 의견을 모 니터링 할 수 있는 서비스와 필요 없는 정보를 줄일 수 있는 필터링 서비스, 의견 분석을 위한 자료수집과 수집된 자료를 일련의 지표로 삼을 수 있는 자동 데이터 분석 서비스가 있다. 셋째, 정책 집행 서비스로써 사용자들의 요구에 부합하고자 정책이 집행되는 모든 과정을 투명하게 사용자에게 제공할 수 있고 신속한 처리과정을 위해 관련 부서간의 유기적인 협력 체제 및 인터페이스를 갖추어야 한다. o 거 래 처 리 시 스 템 거래처리의 관점에서 보면 전자정부는 네트워크를 통하여 G2G, G2B, G2C, C2G, B2B, B2C 등의 거래를 제공할 수 있어야 하며 이를 위해서 범용적이고 향상된 보안대책이 필요하다

71 3장. 공개소프트웨어 도입유형 및 절차 o 지 식 정 보 시 스 템 공공부문과 민간부문에 대한 서비스를 위해 다양한 데이터가 사용된 다. 이 데이터들은 종류도 다양할뿐더러 그 양이 너무 방대해 파일관 리 위주의 일반적인 데이터 관리로써는 원할한 정보의 공유가 힘들 다. 더구나 효율성 면에 대한 고려도 필요하기 때문에 이 데이터를 이용한 지식 정보 베이스를 구축해야 할 필요성이 있 다. 나. 시 나 리 오 별 도 입 방 법 웹 기반의 업무환경은 Web Tier, Business Logic Tier, Data Tier 의 3계층으로 구성되며 각 각의 계층은 웹브라우저/웹서버, 웹 어플리 케이션 서버, 데이터베이스 서버의 순서로 처리된다. Presentation Layer Internet 방화벽 L4 switch WEB Tier Business Logic Tier 방화벽 웹서버 SW O S WAS SW O S Data Tier DBMS SW OS Storage <그림 2> 웹기반 정보시스템 구조 웹 기반의 전자정부 등 공공 정보시스템을 공개소프트웨어기반으로

72 공개소프트웨어 안내서 도입시 다양한 시나리오를 적용할 수 있는데, 그 가운데 대표적인 세 가지 시나리오별 예시하면 다음과 같다. o 시 나 리 오 1 : 웹 서 버 운 영 체 제 공 개 소 프 트 웨 어 도 입 기존 3계층으로 구성된 환경에서 웹 서버 운영체제를 공개SW로 대 체하는 경우로써, 공개SW의 안정성 및 성능에 대해 PoC(Proof of Concept)를 실시하고자 하는 경우 적합하다. 웹 서버에 공개소프트웨어 를 도입하는 경우는 단순히 서버만을 교체하는 수준의 작업이 요구되 므로 전환이 용이하다는 장점이 있다. 웹서버 소프트웨어는 공개소프트 웨어(Apache, Tomcat 등)와 비공개소프트웨어(WebtoB, SunOne 등)와 모두 적용할 수 있다. Internet 방화벽 L4 switch WEB Server 방화벽 웹서버SW 공개SW(LINUX) WAS WAS SW O S DB Server DBMS SW O S Storage <그림 3> 웹서버 운영체제 공개SW 도입 o 시 나 리 오 2 : 웹 서 버 및 웹 어 플 리 케 이 션 서 버 운 영 체 제 공 개 소 프 트 웨 어 도 입

73 3장. 공개소프트웨어 도입유형 및 절차 기존의 3계층으로 구성된 환경에서 웹서버, 웹 어플리케이션 서버 운영 체제를 공개SW로 도입하는 경우로써, 비용절감 효과를 원하며, 비교적 안전하게 공개SW를 도입하고자 하는 경우에 적합하다. 어플리케이션 서버의 경우 J2EE 표준준수로 비교적 추가 작업이 적고, 비용절감효과 크다. WAS는 공개소프트웨어(JBoss, Tomcat, JOnAS 등) 또는 비공개 소프트웨어(JEUS, Weblogic, WebShpere 등) 모두 적용 가능하다. Internet 방화벽 L4 switch WEB Server WAS 방화벽 웹서버 SW 공개SW(LINUX) WAS SW 공개SW(LINUX) DB Server DBMS SW O S Storage <그림 4> 웹서버, 웹 어플리케이션 서버 운영체제 공개SW 도입 o 시 나 리 오 3 : 적극 적 공 개 S W 도 입 기존의 3계층으로 구성된 환경 전체 운영체제에 공개SW를 도입하는 경우로써, 신규로 구축되는 사이트에 가장 적합하고, 비용절감 효과가 가장 크다. DBMS는 공개소프트웨어(MySQL, PostgreSQL 등) 또는 비공개소프트웨어(UniSQL, Oracle 등) 모두 적용가능하다

74 공개소프트웨어 안내서 Internet 방화벽 L4 switch WEB Server WAS 방화벽 웹서버 SW 공개SW(LINUX) WAS SW 공개SW(LINUX) DB Server DBMS SW 공개SW(LINUX) Storage <그림 5> 3계층 서버 운영체제 공개SW 도입 다. 적용 가 능 분 야 대표적인 공개소프트웨어인 리눅스는 웹서버, 메일서버 등 인프라서 버와 1way ~ 4way 엔트리급 서버에서는 이미 기술적 안정성을 입증 받고 있으며, 리눅스 커널 2.6 출시 이후 DB서버, AP서버 등 기관 핵심 업무와 8 way 이상의 엔터프라이즈급 서버 운영체제로 폭넓게 활용되 고 있는 추세이며, 특히 리눅스가 일반적으로 선택되고 있는 환경은 다 음과 같다. 1 네트워크 인프라 : 도메인 네임 서버 (DNS), IP 주소 할당 (DHCP), 웹 서비스, 어플리케이션 서비스, 프록시 서버, 디렉토 리 패킷 쉐이핑 및 통신 최적화를 위한 소프트웨어 포함 2 데이터베이스 서버 : 탁월한 오픈 소스 데이터베이스 서버로는 MySQL, PostgreSQL, MaxDB Firebird SQL(이전에는 Interbase),

75 3장. 공개소프트웨어 도입유형 및 절차 Ingres(이전에는 Adabas)가 있으며, 다수의 비공개 데이터베이스 서버도 리눅스에서 이용 가능 3 보안 시스템: 방화벽, 침입 탐지 및 분석, 허니포트(honeypots), IPSEC 및 기타 가상 사설망(VPN) 시스템, 패킷스니핑 (packet-sniffing) 및 분석, 바이러스 백신 소프트웨어 및 스팸 방지 필터링 포함 4 인터넷 및 인트라넷 출판: 웹 서버, 컨텐츠 관리 시스템(CMS) 플랫폼 및 워크플로우 관리 도구 포함 5 문서 관리: 자동 전자 문서 캡처 시스템, 개정 관리 시스템, 데 이터 캡처 기술, 문서보관 시스템 포함 6 이메일 및 통신: 이메일, 일반 그룹웨어(그룹 캘린더 관리, 주소 록 공유, 알리미 서비스, 공유 폴더) 및 인스턴트 메시지 교환 서버를 위한 다수의 솔루션 포함 7 어플리케이션 서버: Java, PHP, Perl, Python 및 ZOPE 스크립트 툴, (Java 및) Java 2 Enterprise Edition(J2EE) 서버(예: JBoss), dotgnu.net 공개소프트웨어 어플리케이션 서버에 기반한 광 범위하게 사용되고 있는 웹 어플리케이션 서버 포함. 또한, 현재 다수의 비공개 어플리케이션 서버가 리눅스에서 이용 가능 8 파일 및 프린트 서버: Unix NFS, Microsoft SMB/CIFS 및 Novell Netware NCP와 같은 대부분의 주요 파일 공유 프로토 콜을 포함하는 툴

76 공개소프트웨어 안내서 9 저장: 몇몇 네트워크에 부착된 저장 장치들은 주로 공개소프트 웨어 플랫폼에 구축되어 있음 10 제한된 기능의 워크스테이션: 기본 웹, 이메일, 터미널 액세스 그리고 통화 센터, 키오스크 및 이와 유사한 용도를 위한 사무 실 생산성 관련 기능을 제공하는 고정 용도의 워크스테이션 11 고성능 컴퓨텅: 여기에는 다수의 마이크로프로세서 (수직 평가), 다수의 저비용 시스템(수평 평가) 및 기타 유형의 수퍼컴퓨터에 기반한 클러스터를 장착한 단일 영상 시스템 포함 12 고성능 기술 워크스테이션: 과학적 분석, 계량, 모델링, 3D 컴퓨 터로 생성된 이미지 (CGI) 및 비디오 처리 기능과 같은 컴퓨터 의 처리 기능을 강화한 어플리케이션용 멀티 프로세서, 64-비트 및 대용량 메모리 시스템 4. 고려사항 공개소프트웨어를 도입 방법, 절차 그리고 적용 가능한 시스템에 대하여 살펴보았으며, 공개소프트웨어를 도입할 경우 다양한 요구사 항들이 도출되는 것을 확인했다. 따라서 이번 절에서는 공개소프트웨 어를 도입함에 있어서 고려해야 할 사항들을 검토하면 다음과 같다. 첫째, 도입하고자 하는 공개소프트웨어에 대한 라이센스를 정확하 게 확인하고 이해해야 한다

77 3장. 공개소프트웨어 도입유형 및 절차 공개소프트웨어로서 완전한 권리를 획득하기로 하였다면 해당 공개 소프트웨어는 소스코드를 모두 공개하고 해당권리를 사용자에게 양도 해야한다. 하지만 대형 프로젝트 등에서는 공급자가 모든 소스에 대 한 권리가 없는 경우가 많으므로 소스의 일부는 비공개소프트웨어거 나 타인의 저작권에 속하는 기술로 개발된 부분일 수 있으므로, 이러 한 부문의 검토도 간과하지 말아야 한다. 둘째, 시스템 호환성 확보를 위해 개방표준을 지원하는 제품을 우 선적으로 고려한다. 정보시스템을 설계할 때에는 유연한 상호호환성 확보를 위해 개방 표준을 지원하는 제품을 우선적으로 고려해야 한다. 모든 사람들이 읽어야 하는 자료를 웹을 통하여 제공할 경우에는 가능한 모든 정보 통신 환경 사용자가 접근 가능하도록 제공하여야 한다. 셋째, 도입하는 공개소프트웨어에 대한 기술지원 및 유지보수에 대 하여 고려해야 한다. 만약 간접공급 방식으로 공개소프트웨어를 도입하기로 결정하였 다면 사용자지침서, 온라인 튜토리얼, 교육훈련, 헬프 데스크 및 유지 보수가 원활해야하며 또한 여러 플랫폼이나 사용 환경에 맞추어 맞추 어 버전관리가 잘 이루어질 수 있는지 확인해야 한다. 직접선택 방식 으로 공개소프트웨어를 도입한다면 위 사항에 대한 구체적인 대안이 마련되어야 한다. 넷째, 사업의 취지에 가장 적합한 솔루션인가를 깊이 있게 고려해 보아야한다. 제도적 또는 절차적 공정성을 확보하여 독점소프트웨어와 공개소프 트웨어의 장단점을 고려하여 가장 적합한 솔루션을 선택해야 한다