mir.pe (일반/어두운 화면)
최근 수정 시각 : 2024-06-22 22:53:50

오픈 소스

오픈 라이선스에서 넘어옴
🌐 소프트웨어 관련 정보
{{{#!wiki style="margin: 0px -10px -5px"
{{{#!folding [ 펼치기ㆍ접기 ]
{{{#!wiki style="margin:-5px -2px -12px"
<colbgcolor=#64C3FA> 소프트웨어
<colcolor=#000,#fff> 기능에 따른 구분 시스템 소프트웨어(플랫폼)
응용 소프트웨어
유틸리티
펌웨어
권한에 따른 구분 사유 소프트웨어 프리웨어, 셰어웨어, 애드웨어
오픈 소스, 자유 소프트웨어
직업 프로그래머( 개발자), 분석가, QA, DB Admin, 디자이너
목록 소프트웨어/목록
}}}}}}}}}||

1. 개요2. 오픈 소스 소프트웨어
2.1. 장점2.2. 단점
2.2.1. 유지보수의 불리함2.2.2. 외적인 불안정성2.2.3. 무단승차2.2.4. 저작권 관련 문제
3. 오픈 소스 소프트웨어 라이선스
3.1. 주요 라이선스
4. 소프트웨어 목록
4.1. 운영 체제
4.1.1. 데스크톱 환경4.1.2. 클라우드, 가상화 관련
4.2. DBMS4.3. 인공지능, 빅데이터4.4. 자연어 처리4.5. 개발 및 텍스트 에디터4.6. 수학( 수치해석), 그래프4.7. 네트워크 관련4.8. 보안 관련4.9. 게임 관련4.10. 그래픽 관련4.11. 콘텐츠 매니지먼트( CMS) 관련4.12. 문서 관련4.13. 멀티미디어 소프트웨어4.14. 파일 관련4.15. 블록체인 관련4.16. 기타
5. 오픈 소스 하드웨어6. 오픈 소스 데이터7. 오픈 소스 커뮤니티
7.1. 오픈 소스 커뮤니티 사이트의 기능들
7.1.1. Documentation
7.2. 오픈 소스 커뮤니티의 구성원
7.2.1. Leader
7.3. 오픈 소스 활동
7.3.1. 패치7.3.2. 코드 리뷰7.3.3. 문서화7.3.4. 기부
8. 관련 문서9. 관련 링크

1. 개요

Open Source / FOSS(Free and Open-Source Software)[1]

어떤 소프트웨어 프로그램을 개발하는 과정에 필요한 소스 코드나 설계도를 누구나 접근해서 열람할 수 있도록 공개하는 것. 보통 소스가 공개된 소프트웨어를 '오픈 소스 소프트웨어'라고 하고, 소프트웨어 말고도 개발 과정이나 설계도가 공개되는 경우 하드웨어에도 오픈 소스 모델을 적용할 수 있으며, 글꼴과 같은 데이터에도 오픈 소스 개발 모델이 적용되는 경우가 있다. 오픈 소스를 채택했다고 해서 무료 프로그램일 필요는 없다. 재판매가 허용된다.

오픈 소스 코드를 활용하여 이를 2차 창작하는 것을 허용하는 경우가 대부분이다. 즉, 클로즈드 소스 소프트웨어에 오픈소스 코드의 이용도 허용되고, 조건 없이 상업적 용도로까지 사용할 수 있게 하는 경우가 많다. MIT, BSD, Apache가 이에 해당된다.

2. 오픈 소스 소프트웨어

소스 코드가 공개(open)된 소프트웨어이다. 대부분의 오픈 소스 소프트웨어는 무료로 사용 가능하기 때문에 프리웨어(freeware)와 헷갈리는 경우가 많지만, 프리웨어는 무료로 사용할 수 있는 프로그램이고, 오픈 소스는 소스 코드가 공개된 프로그램이기 때문에 엄연히 다른 개념이다(예를 들어, 오픈 소스 소프트웨어를 돈 받고 파는 경우도 있다). 자유 소프트웨어(free software)와 비슷하지만, 오픈 소스 소프트웨어가 자유 소프트웨어보다 조금 더 상위의 개념이다. 오픈 소스는 일반적인 소프트웨어 개발 프로세스와는 다른 특징을 가지며 개발 조건상 소프트웨어 공학 프로세스를 따르기 힘든 경우가 발생한다. 이렇게 되면 개발하려 하는 소프트웨어를 해석하는데 필요한 산출물의 부재가 발생해 소프트웨어의 품질로 영향을 준다.

일반 사용자 입장에서는 프리웨어나 오픈 소스 소프트웨어나 단순히 공짜로 사용할 수 있다는 점에서는 비슷할 수 있지만, 소스 코드를 보고 이해할 수 있고, 수정할 수 있는 개발자 입장에서는 크게 다르다. 예를 들어, 상용 또는 프리웨어 프로그램을 사용하는 사람들은 버그를 발견했다 하더라도 소스 코드를 모르니 수정할 수 없고, 사용자가 새로운 아이디어가 떠올랐다 해도 그것을 곧바로 프로그램에 적용할 수도 없다. 비교적 간단한 프로그램은 리버스 엔지니어링으로 어셈블리어 수준에서 뜯어고칠 수는 있으나 소스 코드가 공개된 것보다 몇백 배는 어렵기도 하고, 저작권 같은 문제가 얽히고설키기에 하려는 사람은 거의 없다고 보면 된다.

하지만 사용자가 프로그래밍 언어를 아는 경우 소스가 공개되어 있다면 본인이 직접 소프트웨어의 문제를 수정하거나 개선을 할 수 있게 되는 것이다. 또한, 개발하던 프리웨어가 개인적인 사정이나 회사의 사정에 따라 개발이 중지되면 그대로 사장되는 경우가 종종 있는데, 오픈 소스 소프트웨어는 코드가 공개되어 있기 때문에 다른 개발자/개발사에서 이를 이어받아서 새로이 개선해 나가면서 개발하는 것이 된다. 그래서 개발자와 사용자가 일치하는 개발 툴 및 시스템, 네트워크 분야에는 웬만한 클로즈드 소스 상용 소프트웨어는 명함도 못 내밀 정도로 고품질의 오픈 소스 소프트웨어가 넘쳐난다. 그러나 그러지 않는 분야에선 말 그대로 취미 수준에 머물러 있는 경우도 많다.

소스코드가 공개되어 있고, 이를 마음껏 개조해 클로즈드 소스 소프트웨어에 사용할 수 있다는 점에서 필요한 방향으로 최적화가 용이하기 때문에 소프트웨어 개발에 주로 이용된다. GPL이 하락하고 MIT, BS, Apache 진영의 소스코드가 뜨고 있는 이유이다.

스페인 카탈루냐 바르셀로나 시에서는 모든 소프트웨어를 우분투 리눅스 등 자유 소프트웨어로 바꾸기로 결정하였다. 윈도우가 없는 도시를 꿈꾼다: 스페인 바르셀로나의 자유소프트웨어 전면화 프로젝트 (2018-01-31). 독일에서도 윈도우즈를 리눅스로 대 전환하고 있다.

2.1. 장점

라이센스에 따라서 다르지만 기본적으로 오픈 소스는 소프트웨어 개발에 사용된 대부분의 코드가 공개되어 있기 때문에 코드를 유지보수하는 측면에서 유리한 편이다. 클로즈드 소스 프로젝트는 개발 당사자가 아닌이상 유지보수를 하려면 소스 코드를 전부 리버스 엔지니어링으로 분석해서 역설계 하지 않는이상 불가능한데다가 난이도가 상당히 높지만[2] 오픈소스 프로젝트들의 경우 소스 코드 자체가 공개되어 있는 만큼 공개된 소스코드를 바탕으로 더 손쉽게 유지보수가 가능하며 코드에 숨겨진 문제점을 발견하기도 쉽고 반대로 코드가 전부 공개된 만큼 외부에서 보안 취약점등의 문제점을 심어놓기도 힘들다.

또한 공개된 소스코드를 바탕으로 해당 프로젝트를 개선을 기여하거나 아예 자체적으로 개선한 별개의 프로젝트를 만드는 등 유저들이 소프트웨어를 발전시키는 것에 있어 자유로운 접근이 가능하며 그만큼 프로젝트에 생기는 문제 또한 빠르게 찾아내거나 개선하려는 시도를 할수 있고 극단적인 경우로는 RHEL 사태처럼 클로즈드 소스로 전환해도 이전까지 공개된 코드를 바탕으로 어떻게든 명맥을 이어 나갈수 있는 등 질긴 생명력을 보여준다.

또한 영리성 프로젝트가 아닌경우[3] 해당 프로젝트를 사용해서 발생한 수익등을 나눠줄 필요가 없는 만큼 개발이나 소프트웨어 구매비용에 들어가는 비용을 크게 절감이 가능해 높은 수익성을 확보할 수 있다.

소프트웨어의 연구나 개발 목적에 있어서 자유로운 기여나 빠른 기여가 가능한 만큼 오픈소스 프로젝트들은 빠른 연구결과를 얻거나 이를 공유해서 학문적 성취를 얻기 쉬우며 자료가 전부 공개되어 있는 만큼 외부에서 이 연구 결과를 적용해 제품화 하는것 또한 자유로운 편이다.

마지막으로 오픈소스 기여자 대부분이 영리를 목적으로 하는게 아니라. 학문적인 이유이거나 재미를 위해서 기여하는 경우가 많아 프로젝트 규모 대비 인건비가 되게 적게 들어간다. 따라서 2020년대 유명 소프트웨어 기업 대다수는 자사 프로젝트를 오픈소스로 전환해 인건비를 획기적으로 절감하는 효과를 톡톡히 보기도 했으며 추가적으로 기여자들을 눈여겨 보다가 스카웃 하는 등 여러가지로 활용하기 쉬운 편이다.

2.2. 단점

2.2.1. 유지보수의 불리함

윗 문단에서는 오픈소스가 유지보수에 유리하다고 설명했지만 사실 반만 맞는 사실인데 근본적으로 모든 자료가 공개되어있어 수정이 편하다고 해도 정작 이를 유지보수할 사람이 없다면 아무런 의미가 없기 때문이다.

대다수의 오픈소스 프로젝트는 운영 주체가 불분명하거나 특정 개인이 관리하는 경우가 많아 생각보다 유지보수에 있어 취약한 편이다 이에 대한 xkcd의 풍자화 현대적인 소프트웨어들은 유지보수에만 상당한 인력이 요구된다는 점 때문에 이런 프로젝트들은 제대로된 유지보수를 받지 못하는 경우가 많으며 따라서 정기적인 업데이트가 아니라 비정기적인 패치등만 이루어지거나 긴급한 조치가 필요한 문제가 발생했을때도 바로 조치가 힘든 경우가 많으며 갱신 자체도 길면 몃년에 걸쳐 하는 등 제대로 된 운영이라고는 보기 힘든 케이스가 많다.

이런 문제 때문에 레드햇이 관리하는 RHEL처럼 거대한 주체가 관리하는 프로젝트를 선호하는 케이스도 있지만 이것도 만능이 아니다. 이런 유지보수 주체가 확실히 존재하고 규모가 큰 프로젝트는 유지보수에 있어 가장 유리하긴 하지만 결과적으로는 프로젝트가 그 유지보수하는 주체에 끌려다니게 되며 최악의 경우에는 RHEL의 소스코드 공개제한 사태처럼 기존에 오픈소스였던 프로젝트를 클로즈드 소스로 전환하거나 하는 식으로 사용자를 대놓고 엿먹이려는 시도도 한다.

또한 유지보수 주체가 불분명하다는 점은 문제 발생시 책임소재가 불분명하다는 문제도 있으며 오픈소스 프로젝트를 사용해도 그 프로젝트가 비영리성으로 운영되거나 유지보수 주체를 찾을수 없다면 책임을 물을수 없어 대놓고 막 운영하는 케이스도 있는데 아래의 Colors.js 사태가 대표적인 예시로 해당 프로젝트를 고의로 테러해서 기업에 손실을 가한 marak은 깃허브 계정이 일시 정지 당한 것 말고는 아무런 처벌을 받지 않았다.

그럼 많은 유저들이 참여하는 프로젝트면 되는것 아니냐는 의견이 나올수도 있지만 이것또한 만능이 아닌게 다량의 유저가 참가하는 프로젝트는 그 다량의 유저들이 기여하는 코드들 때문에 문제가 발생한다. 유저들이 임의로 기여하는 코드들은 제대로 정리가 안되어 다른 유저들이 작성한 코드들과 충돌해 문제를 발생시킬 가능성이 높으며 유저들이 계속해서 수정하는 코드들 때문에 기능구현이 제대로 안되거나 기능이 수시로 변경되거나 하는 경우가 많아 어떤 유저가 이에 대해서 문서화를 해도 다음버전에서 달라져 문서화 자체가 제대로 되지 않는 경우가 많고 오히려 개인이 운영하는 프로젝트가 개발에 참고할 문서정리가 훨씬 잘되어있는 경우가 많다. 이런 문제 때문에 엄청난 수의 유저가 참가하는 오픈소스 프로젝트들은 단순한 베타빌드 말고도 나이틀리 빌드등 사전 테스트 빌드만 2~5종류씩 가지고 있는 정신나간 모습을 보여주며 이런 베타테스트 빌드를 다 거치는 과정 때문에 업데이트가 상용 프로젝트들 보다 느린경우가 많다.

이 때문에 신속한 문제해결과 안정적인 유지보수가 필요한 데이터베이스, ERP, 게임 엔진, 개발 소프트웨어 등의 기업 수요가 방대한 소프트웨어들이 오픈소스나 자체 시스템이 아닌 검증된 상용 소프트웨어를 쓰는 경향이 있으며 이런 경향 덕분에 욕을 한바가지 먹는 회사가 욕을 먹음에도 불구하고 검증된 서비스를 바탕으로 높은 점유율을 차지하고 있다.

2.2.2. 외적인 불안정성

개발에 참여하는 주체가 많다는 점 때문에 개발하는 유저들 간의 파벌이나 기여가 가장 많은 유저에게 휘둘리는 문제 등이 발생하는 오픈 소스 프로젝트들도 자주 나오며 이러한 프로젝트는 또 포크되어서 다른 프로젝트가 되어버리고 거기서 비슷한 문제가 발생하면 또 포크되어서 다른 프로젝트가 되는 파편화 문제 또한 자주 볼 수 있다.[4]

이러한 문제점이 2024년에 다시 주목되었다. 리눅스 및 다른 유닉스 계열 운영체제에서 쓰이는 xz 압축 유틸리티에서 백도어가 발견된 것이다. 공격자는 xz 프로젝트에 수년동안 기여했는데, 이 과정에서 다른 이름으로 관리자에게 관리자를 자신으로 바꿔야한다고 정서적 공격을 하며 요구를 했다. 그러면서 공격자는 프로젝트에 기여를 하며 신뢰를 얻었고, 결국에는 관리자로부터 프로젝트를 이어 받았다. 프로젝트를 이어받은 후 테스트용 파일이라며 원격 제어나 키로깅을 할 수 있는 백도어를 심는 대참사가 발생했다. CVE-2024-3094 백도어 요약글 공격 과정 요약글

2.2.3. 무단승차


오픈소스는 사용자가 소스코드를 기여함으로써 발전하는것을 목표로 하지만 사실 대부분은 기여에 흥미를 가지고 있지 않고 공개된 소스코드를 가지고 공짜로 돈벌 생각만 가지고 쓰기 때문에 실제로 사용하는 인원 대비 개발에 참여하는 인원의 비중은 매우 적으며 따라서 개발에 참여하는 사람들이 보는 이익에 비해 사용자들이 더 큰 편익을 보고있다.

특히 수익을 창출하는 기업들이 이점과 관련되어 문제가 많은데 구글이나 MS등 대기업들은 기존에 자사가 운영하던 프로젝트를 오픈소스화 하는 모습을 많이 보여주는데 이는 자사의 이미지 개선을 위한 목적이 크지만[5] 근본적으로는 자발적인 기여자들이 무상으로 기여하는것을 노리고 유지보수 비용을 절감하기 위한 목적이며 실제로 자사 사업에서 큰 돈을 벌어주는 핵심 분야는 클로즈드 소스로 유지하면서 덜 중요한 프로젝트만 오픈소스로 공개하는 식으로 운영한다. [6][7]

이에 항의하기 위해 벌인 사건 중 하나가 Colors.js 사건[8] 등이다.

2.2.4. 저작권 관련 문제

코드가 공개되어 있고 사용을 추적하거나 불법사용을 막을 방법이 없는 점 때문에 오픈소스 프로젝트 대다수들은 사용자 라이센스와 무방하게 불법적으로 사용되고 있는 경우가 많으며[9] 이를 적발해 내는것도 난해한지라 저작권을 무시한 불법 사용이 꽤 많다.

3. 오픈 소스 소프트웨어 라이선스

다양한 오픈 소스 라이선스를 정리한 표 : #
2015년 이후 GPL 진영의 점유율이 하락하고 있고 MIT, Apache, BSD가 상승하고 있는것이 특징이다.
파일:top 10 oss license 2021.jpg
2021년 점유율 현황. 출처:statista

2017년 오픈 소스 라이선스 시장 점유율 현황 링크1, 2022년 오픈 소스 라이선스 시장 점유율 현황 링크2

오픈 소스 라이선스 중에서 MIT, BSD, Apache 등의 허용적 라이선스의 소스코드를 활용하여 2차 저작물 어플리케이션 소프트웨어를 만들어 재배포시 소스코드 공개 배포 필요가 없다.

과거와 달리 MS 사도 오픈 소스를 채택할 수밖에 없는 상황이다. .NET과 차크라코어[10]를 공개 개발로 전환한 덕에 프로그램 개발과 회사 이미지 개선에 도움이 꽤나 크게 되었다고 한다. 이후에 C#을 완전 오픈 소스로 풀거나, [11] Windows 10 우분투 기반 리눅스 서브시스템( WSL)과 Bash 셸을 탑재하는 등 오픈 소스를 적극적으로 활용하는 모습을 보이고 있다.[12]

가끔 오픈 소스 프로젝트로 하드웨어 디바이스를 제어하기 위한 라이브러리를 만들거나 차트(그래프) UI 컴포넌트 등을 만드는 팀들을 볼 수 있다. 이런 프로젝트 그룹이 만들어 놓은 결과물을 쓰면 비싼 라이브러리를 쓰지 않아도 된다는 장점이 있으나... 가끔 중요한 API를 껍데기만 만들고 방치하는 경우도 종종 만난다.

GPL 규약은 리눅스 커널 스테이지에 적용되고 있다. 라이브러리 등에 적용하기 위해 완화시킨 것이 LGPL 라이선스이다. 동적링크 사용시 소스코드를 공개의무가 없고 정적 링크 시에도 오브젝트 코드만 요청시 배포된다. 소스 재공개를 아예 하지 않아도 되거나, 파생저작물 조항이 없는 MIT/Apache 라이선스 등도 있다. 위의 통계 자료에서 보이듯 최근에는 GPL을 기피하고 MIT 허가서를 사용하는 빈도가 급증하였다. 그리고 라이선스 없이 저작권 자체를 아예 포기해 버린 경우는 퍼블릭 도메인(Public Domain)이라고 한다. 본질적으로 퍼블릭 도메인과 같지만 이런 법적 문제에 넌덜머리가 난 한 데비안 개발자는 니 X대로 해라라는 뜻의 WTFPL을 배포했다.

유명한 소프트웨어 회사들과 소프트웨어 재단 등에서는 각자의 개발 철학에 맞는 소프트웨어 라이선스를 배포한다. 마이크로소프트, 애플, IBM 등의 회사도 각자의 오픈 소프트웨어 라이선스를 가지고 있다. 다만, 뼈대는 기존 라이선스에서 따오는 경우가 대부분이고 GPL보다는 MIT 허가서, 아파치 라이선스를 참고하는 경우가 많다.

3.1. 주요 라이선스

4. 소프트웨어 목록

4.1. 운영 체제

4.1.1. 데스크톱 환경

4.1.2. 클라우드, 가상화 관련

4.2. DBMS

4.3. 인공지능, 빅데이터

4.4. 자연어 처리

4.5. 개발 및 텍스트 에디터

4.6. 수학( 수치해석), 그래프

4.7. 네트워크 관련

4.8. 보안 관련

4.9. 게임 관련

보통 인기를 끌었다고 생각되는 게임들은 리메이크를 하거나 재구현을 통해 오픈 소스화하여 현재에 맞게 구성되는 경우가 많다. 그리고 에뮬레이터는 특히나 오픈 소스를 찾아보기 쉽다. 아무래도 개발자가 개발자이다 보니 에뮬레이터 만드는 게 수월한 모양. 또한 게임 엔진 중에도 오픈 소스로 공개되어 있는 경우가 있다. ( 문서 참조) 아래에 후술된 게임 외에도 다양한 게임이 오픈 소스로 제작되었다. 더 많은 목록은 이곳을 참고할 것.
그 밖에 언리얼 엔진 4 이후와 크라이엔진 5 이후의 게임 엔진도 오픈 소스로 공개되어 있지만 그 대신 일정 수익 이상이 창출되면 로열티를 개발사에게 지급해야 하는 조항에 동의해야 열람할 수 있는 경우도 있다.

4.10. 그래픽 관련

4.11. 콘텐츠 매니지먼트( CMS) 관련

4.12. 문서 관련

4.13. 멀티미디어 소프트웨어

4.14. 파일 관련

4.15. 블록체인 관련

4.16. 기타

5. 오픈 소스 하드웨어

하드웨어 역시 오픈 소스가 가능하다. 오픈 소스 하드웨어는 대개 그것을 설계한 회사나 단체 등에서 직접 제품을 생산·판매하지만, 설계도를 오픈 소스로 공개해서 다른 사람들이 똑같은 물건을 제작하거나 변형을 가해서 제작할 수 있게 허용하는 식이다. 해당 프로젝트로는 Arduino RISC-V등이 있다.

3D 프린터의 확산으로 오픈 소스 하드웨어 제작이 용이해지고 있다. 아예 3D 프린터 자체도 오픈 소스로 공개한 경우들이 존재하고. 그런데 3D 프린터 붐에 편승하여 미국 총기 소유가 합법인 나라에서 오픈 소스 총(...)을 만드는 경우도 있어서 거센 논란이 일기도 한다[20].

오픈 소스 완제품 하드웨어를 전문적으로 만드는 주체는 라즈베리 파이 재단, Pine 64 등이 있으며 오픈 소스 제품을 전문적으로 유통하는 회사는 스파크펀 일렉트로닉스, 에이다프루트 인더스트리즈, Seeed 스튜디오 등이 있다.

6. 오픈 소스 데이터

7. 오픈 소스 커뮤니티

오픈 소스 기술을 개발하는 사람들의 모임이다. 물론, 오픈 소스의 범주도 포괄적이고, 특정 기업을 중심으로 운영되거나 소프트웨어 이외의 것들에 대해서는 오픈 소스라 할지라도 개발 방법론에서 차이가 있을 수 있지만, 대체로 이와 비슷한 구조를 따른다.

오픈 소스 소프트웨어의 개발은 프로젝트마다 존재하는 소스 코드 저장소를 중심으로 이루어진다. 수많은 사람들이 소스 코드를 동시 다발적으로 수정하는 것을 관리해야 하기 때문에, SVN이나 Git 같은 버전 컨트롤 시스템을 중심으로 하여 소스 코드가 관리되며, GitHub같은 호스팅 사이트에 올려져 전세계 모두가 실시간으로 확인할 수 있다.

7.1. 오픈 소스 커뮤니티 사이트의 기능들

7.1.1. Documentation

오픈 소스로 개발된 소프트웨어들도 일반 사용자나 파생된 소프트웨어를 개발하는 프로그래머들에게는 블랙박스처럼 활용되어야 할 때가 많기 때문에, 사유 소프트웨어만큼은 아닐지라도 문서화 과정이 중요하다.

보통 위키사이트나, 문서 사이트를 하나씩 개설해 문서나 번역을 관리하는 편이다.

활발하게 개발되는 오픈 소스 기술들은 전공 서적같은 것으로는 따라갈 수 없을 만큼 빠른 속도로 업데이트가 이루어지기 때문에, 프로그래밍 입문자라거나, 인터넷을 못 쓰게 하는 곳에서 공부하는 것이 아니라면 시중에 나와 있는 책들을 구하기 보단 웬만하면 공식 문서를 읽어 보는 것이 좋다.

7.2. 오픈 소스 커뮤니티의 구성원

7.2.1. Leader

프로젝트를 처음 개설하거나 이전 리더로부터 권한을 위임받은 경우 가지게 된다. 리더의 경우 커미터 권한을 관리하거나 주기적으로 큰 버전을 Release하는 역할을 맡는다.

보통 대부분의 오픈 소스 프로젝트의 리더는 Benevolent dictator for life(줄여서 BDFL)의 경우가 많다.

왜냐하면 완전한 민주주의 마냥 모든 것을 동의를 구해서 하기에는, 애초에 투표율이나 의견 개시율 자체가 부족한 경우가 있을 수 있고(이런 경우 리더가 개인 프로젝트를 진행하듯 개발이 진행된다), 그 외에도 다수에게 의사결정을 맡길 때 발생하는 문제가 소프트웨어 개발 방법론과 맞지 않은 경우가 많기 때문이다.

개인이 어떤 작은 프로젝트라도 Github같은 곳에 공개해 놓고, 오픈 소스 라이센스를 명시해 놓으면 그 오픈 소스 프로젝트의 리더가 될 수 있다. 다만 인기 있는 오픈 소스 프로젝트가 되기 위해서는, 다른 개발자들의 이목을 끌기 위해 아이디어가 독창적이거나 완성도 높은 프로젝트를 만들어야 하고, 이를 위해 부단히 노력해야 할 뿐이다.

7.3. 오픈 소스 활동

오픈 소스 프로젝트는 자발적 기여자들에 의해 유지되어 왔다. 오픈 소스 기여 활동은 취미를 넘어서 코딩덕후로서의 포트폴리오 작성이라는 동기부여가 된다. 급여가 없는 대신, 학벌, 평점 등의 진입장벽도 없다.

취업 준비를 해야 하는 입장이라면 신입사원이 되기 위한 업계 진입 장벽 극복이 큰 벽으로 다가오는 편이고, 인턴 같은 기회조차 관련 전공자나 고스펙자들로 인해 힘든 경우라면 대안이 될 수 있다. 게다가 근래 들어서는 실리콘밸리나 국내 IT관련 기업들의 채용 공고에도 오픈 소스 관련 기여 이력을 명시하는 경우가 있고, 그렇지 않더라도 회사의 업무 내용에 포함된 프레임워크 중 자신이 커미터로 활동하는 프로젝트가 있다면 취업에 유리해질 수 있다. 이는 경력직까지도 유효할 수 있다. 일반적인 소프트웨어 개발은 물론, 컴퓨터에 기반한 과학 연구 프로젝트들도 오픈 소스로 공개되는 경우가 많기 때문에, 관련 분야 대학원 진학에도 도움이 될 수 있다. 리눅스 커널의 경우 이 '자발적 기여자'들 역시도 FANG을 비롯한 세계적 IT 대기업들에 의해 상당수 이루어지고 있으므로 해외취업을 고민중이라면 도전해볼 가치가 크다. 인공지능의 경우에도 회사든 대학원이든 논문 구현 경험이 중요하다. 2018년에는 이런 인공지능 오픈 소스 활동으로 인해 26세의 군필 학부 졸업생이 연봉 3억에 미국에 취업한 적도 있었다.

7.3.1. 패치

디버깅, 리팩토링, 신기능 개발 등 코딩을 직접 하는 기여 활동을 의미한다. 오픈 소스 기여 활동 중 가장 보편적이면서도 난이도가 높은 편이기도 하다. 유명한 프로젝트들은 최소 수십만 줄 이상의 코드를 가지고 있고, 프로그래밍 언어마다 존재하는 고급 기법들을 활용하고, 기반한 다양한 외부 라이브러리까지 활용해야 하므로, 막 프로그래밍 언어 기본 서적만 읽고 도전하기에는 막막할 수 있다. 코딩 테스트 준비를 비롯해 알고리즘, 자료구조를 충실히 공부한 다음에 시도하는 것이 바람직하다.

시도하려면 이슈 트래커를 둘러 보고 쉬운 이슈라고 마킹된 것들을 중심으로 도전하는 게 좋다.

7.3.2. 코드 리뷰

자세한 것은 코드 리뷰에.

작성한 코드에 버그가 있는 경우나, 혹은 로드맵에 맞지 않은 경우 Merging이 거절되고 수정 요청을 할 수 있다. 대부분 전체적인 코드 베이스에 대해서 감이 있는 리더나 커미터들이 리뷰를 많이 하는 편이지만, 원칙적으로는 어느 이용자든 패치를 지지하거나 개선 사항을 제시할 수 있다. 결국 설득의 과정이기 때문이다.

7.3.3. 문서화

문서에 나온 오타 수정이나, 새로운 기능에 대한 문서 작성, 튜토리얼 작성, 번역 등의 활동을 포함한다. 패치보다는 훨씬 쉬운 기여 방법이다. 다만 문서 작성이라고 해도 마크다운이나 웹 프레임워크 등을 활용해야 하는 등, 코딩은 여전히 필요한 경우가 많다.

7.3.4. 기부

리눅스 같은 일부 대형 프로젝트는 워낙 많이 활용되어 사회적인 영향력이 있기 때문에, 단순 덕질에서 벗어나 재단을 만들어 기여자들에게 보상을 하거나, 사용자들에게 기술 지원을 하는 경우가 있다. 일부 오픈 소스 기술들은 대기업들이 가진 기술에 필적하기 때문에 사회간접자본에 대한 투자를 한다는 의미로 오픈 소스 프로젝트에 지원을 하는 기업들이 있다.

구글의 GSoC 같은 것이 대표적이다.

다만, 기업인이 아니라 취업준비생이라면 단순히 돈만 내면 되는 기부자가 되기 보다는 위의 기술적인 기여들을 중심으로 해야 할 것이다.

8. 관련 문서

9. 관련 링크



[1] 여기서 'Free'는 공짜가 아니라 자유의 의미다. 한국에서는 자유와 무료라는 단어가 다르지만 영단어 Free는 두 의미를 모두 내포하고 있으므로 자유라는 뜻으로 사용된다. [2] 물론 롤러코스터 타이쿤 등 이를 성공시킨 사례가 없는것은 아니다. [3] 중요한 사실중 하나로 오픈 소스=무료가 절대로 아니다. 이는 본 문서가 "자유 소프트웨어"와 "공개 소프트웨어" 의 차이를 구분하지 않고 있기 때문에 그런것으로 문서 제목인 오픈 소스는 "공개 소프트웨어"를 의미하고 흔히 생각하는 무료 소프트웨어 는 " 프리웨어"나 " 자유 소프트웨어"를 의미한다. 자세한건 해당 항목 참조. [4] 이 파벌 문제로 유명한 프로젝트 중 하나가 Cataclysm : Dark Days Ahead로 이 경우에는 친목질이 개발에 큰 영향을 주었다. [5] 실제로 MS가 차크라코어를 오픈소스화 하면서 한 인터뷰에서는 노골적으로 그 이유가 크다는 사실을 언급하고 넘어간다 [6] 구글을 예시로 하면 구글의 AI관련 프레임워크인 텐서플로는 오픈소스이나 이중 TPU와 관련된 내용은 전부 클로즈드 소스로 운영된다. [7] 닷넷을 오픈소스로 공개한 MS같은 사례도 있지 않냐는 반응도 있지만 이경우는 RHEL처럼 MS가 주도권을 쥐고있는 케이스로 .NET6에서 핫리로드를 제거하려고 시도한것처럼 MS가 이익을 볼수있게 조작하려고 하는 시도가 적발되어 막힌것처럼 결과적으로 MS가 유리한 방향으로 의도되고 있다. [8] 포춘 500 등에 등재된 대기업들이 자기의 프로젝트를 아무런 기여 없이 무상으로 쓰고 있다고 자기가 만든 Colors.js라는 프로젝트에 무한루프를 발생시키는 로직을 짜 넣어서 해당 프로젝트를 쓰는 기업에 셀프 DoS 공격을 가하게 만든 사건. 여담이지만 Colors를 만든 사람은 Faker.js라는 유명 프로젝트 또한 만든 유저인데 이 사람은 Faker.js도 같은 이유로 셀프 반달리즘을 해 놓아서 (이쪽은 아예 롤백도 못하게 리포지토리를 통째로 날려버렸다) 결국 깃허브 계정이 정지되었다. [9] 특히 GPL을 사용하는 프로젝트들은 이를 이용한 소프트웨어들또한 GPL로 공개되어야 하나 프로젝트 사용을 숨기고 클로즈드 소스로 운영해버리는 경우가 많다. [10] 인터넷 익스플로러 11 및 Microsoft Edge의 자바스크립트 엔진 [11] 그리고 C#은 Java를 잡아먹은 오라클이 Java에 대한 권리를 주장하며 사사건건 시비를 걸어오는 걸 막고자 MS에서 공격적으로 진행한 푸시의 일환이다. 이 정책도 상당한 효과를 거둬서 지금은 윈도우에 사실상 묶여있는 언어임에도 점유율 5위를 달성하는 성과를 세웠다. [12] MS가 이처럼 태세 전환을 한 이유는 갈수록 시스템이 복잡해지면서 모든 영역을 MS에서 일일이 다 관여하기 힘들어졌기 때문이다. 이 오픈 소스 환영 정책의 결과로 MS는 커널이나 보안패치를 포함한 운영체제의 핵심부 개발에만 역량을 집중할 수 있게 되어 메이저 업데이트 제공속도가 상당히 빨라졌다. [13] 정확하게는 AOSP가 오픈 소스 이며 이걸 기반으로 구글의 요구사항을 탑재 후 구글의 승인을 받은 운영체제만이 정식으로 안드로이드 상표를 쓸 수 있다. 이렇게 승인된 정식 안드로이드에는 소스코드가 공개 안 된 기능들이 몇 종류 탑재되어있다. [14] MATLAB의 대체 도구로 활용 가능 [15] MATLAB의 대체 도구로 활용 가능 [16] Berkeley Internet Name Domain의 약자 [17] 그런데 방식은 어도비 애프터 이펙트와 비슷하다. [18] 토탈 커맨더와 닮은 파일 관리자다. [19] 위에 있는 7-Zip과 같은 오픈 소스 압축 프로그램이다. [20] 한국에서는 설계도를 유포하거나 실제 제작하는 것만으로도 법에 저촉된다.

분류