<p><font>공개SW 왜 도입을 안하는가, 불만은 무엇인가?</font></p><div><font>[데브멘토 동영상]</font><font>양재영 LG CNS 부장</font></div><div> </div><div><font>Free Software 개념은 1984년, Open Source Software 개념은 1998년 등장</font></div><div><font>정의: 소스코드를 공개한 상태로 실행프로그램을 제공하는 소프트웨어로 소스코드를 누구나 자유롭게 사용, 개작, 재배포할 수 있도록 허용한 소프트웨어</font></div><div><font>개발방법론</font></div>

1. IT서비스업체에서의 공개SW
• 개요
• 시장동향
• 주요제품
• 라이선스
• Q&A
LG CNS 양재영 부장
2010. 7. 3

2. 개요 - 역사
Free Software라는 개념은 1984년, Open Source Software라는 개념은 1998년에 등장하였음
Free Software Movement Open Source Software
• 1984년 리차드 스톨만(Richard Stallman)이 • 1998년 에릭 레이몬드(Eric Raymond)가 리눅스 개발
GNU 프로젝트라는 공개프로젝트를 시작하면서 시작 방식의 성공을 분석하여 “The Cathedral and The Bazaar”
발표
• 리눅스와 함께 자유소프트웨어 운동도 발젂
• 이념적 측면보다는 개발방식에 초점을 맞춘 접근
• 소프트웨어 자체는 항상 윤리적, 도덕적, 사회적으로
타당해야함을 강조 • 공개소프트웨어 개발자에게도 경제적인 보상을 제공할
수 있어야 한다는 실용적 측면을 강조
• 사용자에게 사용상의 여러가지 자유가 있어야 함을 강조
• 자유소프트웨어는 원칙에 입각한 소스코드의 자유로운
1. 어떤 목적으로도 프로그램을 가동시킬수 있는 자유
사용을 강조하는데 반해 사회적 실용성과 경제성에
2. 필요에 맞게 소프트웨어를 수정할 자유 중심을 두고 소스코드의 공개를 강조
3. 무료 또는 유료로 복사본을 재배포할 수 있는 자유
4. 젂체 공동체가 혜택을 볼 수 있도록 프로그램의
수정본을 배포할 수 있는 자유
1

3. 개요 - 정의
소스코드를 공개한 상태로 실행프로그램을 제공하는 소프트웨어로서, 소스코드를 누구나 자유롭게
사용·개작·재배포할 수 있도록 허용한 소프트웨어
OSD (Open Source Definition) by OSI (Open Source Initiative)
1. Free Redistribution: 자유로운 재배포
2. Source Code Open: 소스코드 공개
3. Derived Works: 개작의 허용
4. Integrity of The Author's Source Code: 저작자의 소스코드 원형유지
5. No Discrimination Against Persons or Groups: 개인/단체 차별 금지
6. No Discrimination Against Fields of Endeavor: 사용 분야 제한 금지
7. Distribution of License: 오픈소스 라이선스에 의한 권리는 해당 SW를 재배포 받는 모든 사람에게 그대로 유지되어야 함
8. License Must Not Be Specific to a Product: 특정제품에만 사용하도록 제한하면 안됨
9. License Must Not Restrict Other Software: 다른 SW를 같이 사용하지 못하도록 제한하면 안됨
10. License Must Be Technology-Neutral: 특정 기술이나 특정 인터페이스에만 국한되어 사용되도록 하면 안됨
2

4. 개요 - 개발방법롞
• 에릭 레이몬드의 „성당과 시장‟이란 글을 보면 프로세스를 개발하고 테스트한 결과가 자세히
성당과 시장
기록되어 있음
• 에릭은 기존 소프트웨어 개발 방법롞(성당 모델)의 거의 모든 규칙을 위반하는 이러한 새로운
방법롞(시장 모델)의 출현에 놀랐음
• 성당 개발 스타일과의 근본적인 차이 중 하나는 빈번한 릴리즈
싞속하고 빈번한
제품 출시 • 시장 스타일에서는 여러 사람을 통한 검토가 가능하도록 자주 릴리즈
• 싞속하고 지속적인 릴리즈 사이클을 통해 개발팀은 빠르게 결함을 발견할 수 있고, 개발
과정에서 이를 수정
• 매일 개발자들은 초기 릴리즈 버젂을 사용해보고 테스트를 통해 결과를 보내줌
• 이런 공헌은 젂통적 개발 방식보다 더 짧은 시갂 안에 더 높은 품질을 보유할 수 있게 하는
이유가 됨
• 대부분의 기업들은 프로젝트의 완성 여부보다 시장이나 비즈니스 압력 같은 외부 요인들에
준비되었을때 생산함 의해 결정된 일정에 맞춰(내부 사용이든, 판매용이든) 소프트웨어를 릴리즈 함
• 하지만 오픈소스 프로젝트는 보통 메인테이너가 준비되었다고 판단할 때 릴리즈함
• 비즈니스 수행 입장에서는 오픈소스 프로젝트들이 고정된 맵이 없기 때문에 불편하다고
하기도 함
• 하지만 이것을 수용한 사람들은 더 높은 소프트웨어 품질, 더 적은 횟수의 패치, 더 나은
시스템 아키텍처 등으로 인한 혜택을 얻기 시작함
3

5. 개요 - 개발방법롞
• 개발 프로세스는 라이센스에 관한 것이 아니지만, 라이센스는 그 프로세스가 운영되는 기본
라이선스
조건을 제공하여, 상호 협력적인 개발이 수행될 수 있는 기초가 됨
• GPL이나 LGPL처럼 상호 호혜성 조건(reciprocity requirement)을 가지는 라이센스를 따르는
소프트웨어들은 수정이나 변경사항들이 커뮤니티로 귀속됨
• 제안 사항들의 수용여부, 패치 적용, 결함 모니터링, 필요한 경우 다른 프로젝트들과
메인테이너 협력여부 등을 결정
• 어떤 프로젝트를 짂행하던 개발자가 그 프로젝트에 흥미를 잃게 되면(혹은 더 이상 그
프로젝트를 위해 헌싞할 시갂이 없을 때), 다른 메인테이너를 찾아 개발 과정을 이관
• 보통 그 프로젝트에 공헌이 큰 사람이 새로운 메인테이너가 됨
• 프로젝트를 설립한 위원회가 메인테이너가 된 사례도 있고, 기업 주도의 프로젝트의
경우에는 기업 내부의 직원이 메인테이너가 되는 경우가 많음
• 커뮤니티내 모든 개발자들은 공통의 개발도구와 잘 설계된 하부구조를 기반으로 작업
도구
• CVS – 가장 많이 사용하는 소스 관리도구, 하지만 리눅스 커널 개발시에는 사용되지 않고
패치를 통해 소스가 관리됨
• Bugzilla – 가장 많이 사용하는 버그트래킹 도구
• Savannah, SourceForge – 오픈소스와 자유 소프트웨어를 위한 인프라와 저장 공갂 제공
4

6. 개요 - 설문조사
Q. 장점은 ?
(출처: Forrester, 2005)
5

7. 개요 - 설문조사
Q. 걱정되는 점은 ?
(출처: Forrester, 2005)
6

8. 개요 - 설문조사
Q. 왜 도입 안해요 ?
(출처: Forrester, 2005)
7

9. 개요 - 설문조사
Q. 불만스러운 점은 ?
(출처: Forrester, 2005)
8

10. 개요 - 설문조사
Q. 소스코드를 보시나요 ?
(출처: Forrester, 2005)
9

11. 개요 - 설문조사
Q. 공개SW에 대한 정책은 ?
10