오픈 소스 커뮤니티의 삶과 시대

콘텐츠

• 오픈 소스 커뮤니티의 뿌리
• 대성당과 바자회
• 공유지의 비극
• 오픈 소스 거버넌스 및 의사 결정
• 상용 기업 및 오픈 소스 커뮤니티
• IT 업계에서 오픈소스의 중요성

오픈 소스 커뮤니티의 뿌리

오픈소스 커뮤니티에 대한 공식적인 정의부터 시작하겠습니다. 에 따르면 브라이언 프로핏(Brian Proffitt)의 TechRadar:

오픈 소스 커뮤니티는 일반적으로 소프트웨어와 같은 프로젝트에 기여하는 사람들의 반조직적인 모임입니다. 이러한 커뮤니티는 공통의 관심사를 가진 사람들이 모여 공동으로 무언가를 만들고, 커뮤니티 내부 또는 외부의 모든 사람과 공유할 수 있습니다. 그리고 거의 대부분의 경우 오픈 소스 프로젝트는 분산된 커뮤니티의 결과물입니다.

최초의 오픈소스 커뮤니티가 어디에서 시작되었는지 정확히 파악하기는 어렵습니다. 소프트웨어에 기여하려는 자발적인 노력은 컴퓨터 연구가 처음 시작된 이래로 계속되어 왔을 것이지만, 오픈소스 개발의 역사에서 몇 가지 실마리를 찾을 수 있습니다.

예 리차드 M. 스톨만(Richard M. Stallman), 예를 들어. 오픈 소스 협업의 첫 번째 사례 중 하나는 프린터 용지 걸림으로 인해 인쇄 대기열이 발생할 때 연구원들에게 알림을 받을 수 있는 방법을 찾아야 할 필요성에서 비롯되었다고 합니다.

연구원들은 필요한 코드를 작성했고 작동했지만, 액세스 권한이 없는 비공개 소스 코드가 포함된 새 프린터가 배송되면서 프린터 잼으로 인해 원점으로 돌아갔습니다.

이것이 씨앗이 되어 시간이 지남에 따라 스톨만은 폐쇄적인 라이선스를 가진 독점 소프트웨어가 발전을 가로막는 사례를 더 많이 발견했습니다. 그는 결심했습니다. GNU 프로젝트 를 시작하기로 결정했으며, 이는 부분적으로는 GNU 일반 공중 사용 허가서(GPL) 덕분에 여전히 오픈 소스 소프트웨어의 중요한 초석이 되고 있습니다.

스톨먼의 이야기는 커뮤니티 운동으로서 오픈소스가 발전하기 시작한 첫 걸음 중 하나입니다. 이 이야기는 소스 코드에 대한 통찰력, 제어 및 민주주의에 대한 필요성이 어떻게 커뮤니티 형성에 영감을 주었는지를 보여줍니다. 스톨만의 목표는 완전한 운영 체제를 만드는 것이었지만, 이를 실현하는 것은 성장하는 오픈 소스 커뮤니티의 다른 구성원들의 몫이었습니다.

또 다른 중요한 순간은 1991년 라이너스 토발즈가 개인 프로젝트로 시작한 Linux의 등장입니다. Linux의 역사에 대한 훌륭한 기사가 위키피디아에 있습니다.에 Linux의 역사에 대한 훌륭한 기사가 있지만, 간단히 말하자면 Linus는 GNU C 컴파일러를 사용하는 등 다른 커뮤니티 구성원들의 노력을 바탕으로 Linux Kernel을 개발했습니다.

Linux 기반 운영 체제가 전 세계의 중요한 워크로드를 구동함에 따라 Linux 프로젝트가 얼마나 성공적이었는지 우리 모두 잘 알고 있습니다. Linux는 여전히 무료이며 수백만 줄의 코드가 포함된 릴리스를 통해 자원 봉사자들로 구성된 오픈 소스 커뮤니티의 지원을 받고 있습니다.

두 가지 사례는 오픈 소스 커뮤니티의 두 가지 초석을 보여줍니다. 첫째, 소프트웨어는 누구나 더 큰 것을 향해 기여하고 구축할 수 있도록 자유롭고 개방적이어야 합니다.

또한 개인이 시도하거나 상용 소프트웨어 개발의 제한적인 범위 내에서 시도할 때보다 더 큰 것을 성취할 수 있는 커뮤니티의 힘을 가리킵니다.

대성당과 바자회

공동의 목적을 위해 모이는 커뮤니티는 오랜 역사를 가지고 있습니다. 이러한 유형의 배열을 살펴보는 한 가지 방법은 실천 커뮤니티 (CoP)라는 개념을 통해 이러한 유형의 배열을 살펴볼 수 있습니다.

CoP는 사람들이 모여 비슷한 목표를 향해 함께 일하는 조직화된 그룹입니다. CoP는 계획된 활동으로 의도적으로 형성될 수도 있고, 사람들이 공통의 목표가 있다는 것을 깨닫고 협력하기로 결정하면서 자연스럽게 발전할 수도 있습니다. 이러한 그룹은 정보와 기술을 공유할 뿐만 아니라 업무량을 공유하여 노력이 중복되지 않도록 합니다.

이 모든 것이 자발적이지만 다소 혼란스러울 수 있습니다. 직관적으로는 보다 신중하게 계획된 소프트웨어 개발 접근 방식이 더 성공적일 것이라고 생각할 수 있지만, 오히려 오픈소스의 개방적이고 덜 체계화된 접근 방식이 놀라운 결과를 가져오고 있다는 강력한 징후가 있습니다.

에릭 스티븐 레이몬드가 그의 책에서 암시한 내용입니다, 대성당과 바자. 저자는 소프트웨어를 작성하는 두 가지 모델을 지적했습니다. 첫째, 개발 중에는 소스 코드에 액세스할 수 있고 릴리스 후에 소스 코드를 사용할 수 있더라도 개발 프로세스에 기여하는 제한된 그룹의 사람들만 소스 코드에 액세스할 수 있는 대성당 모델입니다. 대성당 모델은 상업적 환경에서 소프트웨어를 구축하는 것과 유사하게 계획되고 통제됩니다.

하지만 두 번째 모델인 바자회도 있습니다. 바자회는 훨씬 더 혼란스러운 모델로, 릴리스가 자주 발행되고 개발 프로세스가 누구나 참여할 수 있는 개방형입니다. 기본적으로 모든 사람이 볼 수 있는 인터넷에서 개발이 이루어집니다. 이러한 혼란스러운 방식에도 불구하고 개방성이 있다는 것은 통제만 제대로 이루어진다면 바자 모델이 더 빠르게 결과를 도출할 수 있다는 것을 의미합니다.

예를 들어, 레이몬드는 많은 사람이 코드를 살펴볼 때 버그 검토가 훨씬 쉬워지는 반면, 대성당 모델에서는 버그를 찾는 과정이 훨씬 더 어렵다고 지적했습니다.

공유지의 비극

커뮤니티의 노력을 통한 오픈소스 소프트웨어 개발은 여러 면에서 대규모 프로젝트에서도 유능하고 품질 좋은 코드를 생산할 수 있는 훌륭한 방법입니다. 하지만 인생에서 항상 그렇듯이 이 접근 방식에는 장단점이 있습니다.

지난 섹션에서 지적했듯이, 코드를 생성하는 바자 방식은 올바른 컨트롤이 있는 경우에만 작동합니다. 이러한 컨트롤이 필요한 이유는 무엇일까요? 두 번째 비유인 공유지의 비극을 생각해보면 알 수 있습니다.

경제학에서 잘 알려진 개념인 공유지의 비극은 사람들이 항상 공동의 이익을 위해 행동하는 것은 아니며, 오히려 자기 이익에 따라 행동함으로써 공동체의 공동선에 반하는 행동을 하는 경우가 많다는 사실을 지적합니다. 오픈소스 커뮤니티에서도 이런 일이 발생할 수 있습니다.

오픈소스 소프트웨어의 가장 큰 장점 중 하나는 누구나 오픈소스 코드에 코드를 추가, 커스터마이징 또는 변경하는 등 기여할 수 있다는 점입니다. 하지만 개인이 오픈소스 프로젝트의 공익을 고려하지 않고 자신의 개인적 의제를 추진하면 오픈소스 프로젝트에 문제가 발생할 수 있습니다.

이러한 이기심에는 금전적 이익도 포함되지만, 프로젝트가 더 넓은 오픈소스 커뮤니티에 도움이 되지 않는 방향으로 흘러가는 것을 의미할 수도 있습니다. 또는 커뮤니티 차원에서는 가치가 있더라도 개인 차원에서는 관심이 거의 없기 때문에 프로젝트가 사라지기도 합니다.

따라서 '군중의 지혜'는 엄청난 이점을 가져다주기도 하지만, 오픈소스 커뮤니티의 개별 구성원이 때로는 걸림돌로 작용할 수도 있습니다.

오픈 소스 거버넌스 및 의사 결정

오픈소스 소프트웨어 프로젝트의 선의를 최대한 활용하려면, 대의를 위해 개인의 행동을 관리할 수 있는 견고한 거버넌스 및 의사결정 체제가 마련되어야 합니다.

오픈소스 커뮤니티에서 리더십을 발휘하는 전략에는 여러 가지가 있습니다. 완전히 민주적인 방식도 있지만, 반면에 리누스 토발즈는 Linux의 '자비로운 독재자'로서 매우 성공적으로 활동해 왔습니다.

오픈소스 프로젝트는 모두 다르며, 채택되는 거버넌스 구조는 프로젝트의 성격, 기여하는 그룹의 형태와 규모, 그리고 프로젝트의 전반적인 목표에 따라 결정됩니다.

오픈소스 커뮤니티의 리더가 고려해야 할 사항에는 의사 결정 구조, 새로운 메인테이너를 추가하는 방법에 대한 고정된 프로세스, 프로젝트의 목표에 맞는 빌드 시스템 결정 등이 있습니다.

오픈 소스 라이선스(예: GNU GPL 또는 MIT 라이선스)를 포함한 지적 재산권도 중요합니다. 인터넷 도메인의 소유권도 결정해야 하며, 모든 상표도 공정한 방식으로 처리해야 합니다.

고려해야 할 한 가지 중요한 측면은 프로젝트에 대한 통제력이 얼마나 엄격한지입니다. 에릭 레이먼드가 바자회 비유를 통해 말했듯이, 상대적으로 통제력이 부족하다는 점이 오픈소스 모델을 성공으로 이끈 원동력입니다. 하지만 아무런 통제가 없다면 오픈소스 개발은 공유지의 비극에 빠질 위험에 처할 수 있습니다.

상용 기업 및 오픈 소스 커뮤니티

오픈소스 이니셔티브는 놀라운 성과를 거둘 수 있으며, 이는 곧 상업적 벤더의 관심을 끌 수 있습니다. 예를 들어 IBM이 Red Hat을 340억 달러에 인수한 것과 Microsoft가 GitHub에 75억 달러를 투자한 것을 생각하면 그 규모가 엄청날 수 있습니다.

상용 소프트웨어 회사가 엔터프라이즈급 수준의 지원을 제공해야만 오픈소스 프로젝트가 진정으로 임계치에 도달하고 엔터프라이즈에 보급될 수 있다는 주장도 제기될 수 있습니다. 결국 엔터프라이즈 환경에서 일하는 전문 개발자가 오픈 소스 솔루션을 워크로드에 통합하려면 엔터프라이즈급 지원이 있어야 합니다.

어느 쪽이든 오픈소스 커뮤니티는 상업적 공급업체와 복잡하고 때로는 시험적인 관계를 맺고 있으며, 이는 커뮤니티 구성원 덕분에 무료로 제공되는 기여와 상업적으로 운영되는 조직의 영리 동기가 분명하게 대조되는 점을 고려할 때 이해할 수 있습니다.

그럼에도 불구하고 오픈소스의 특권과 상업적 요구 사항을 성공적으로 결합한 몇 가지 모델이 있습니다. 프로젝트에 대한 노골적인 후원을 수반할 수도 있지만, 영리 기업은 자금 지원, 장비 기부, 직원들의 시간 기부 등을 통해 오픈 소스 이니셔티브를 지원할 수 있으며, 예를 들어 직원들이 오픈 소스 코드 작업을 할 수 있는 시간을 제공할 수도 있습니다.

약간의 상업적 투자만으로도 오픈소스 커뮤니티의 노력을 크게 강화할 수 있습니다. 결과적으로 조직은 요구 사항에 맞는 우수한 성능의 오픈 소스 코드를 배포할 수 있습니다. 물론 여기서 중요한 것은 오픈소스 거버넌스입니다. 강력한 독립적인 방향성이 없으면 상업적인 목표가 오픈소스 프로젝트의 목표를 쉽게 무시할 수 있습니다.

IT 업계에서 오픈소스의 중요성

정보 기술은 과학이며, 이 세 가지 특성이 혁신을 촉진하기 때문에 과학은 개방성, 실험, 협업의 혜택을 지속적으로 받습니다. 결과적으로 오픈 소스 커뮤니티가 정보 기술 산업에 도움이 되는 이유를 쉽게 알 수 있습니다.

이러한 혁신은 오픈소스 개발에 의해 주도되며 일반적으로 엔터프라이즈 소프트웨어 솔루션에 적용됩니다. 예를 들어, Linux Kernel은 애플리케이션 서버의 대부분을 구동하며, OpenSSL은 대부분의 HTTPS 지원 웹 서버에 대한 보안 통신을 지원합니다.

올바른 거버넌스를 갖춘 오픈소스 프로젝트는 전 세계에 있는 전문 개발자들의 집단적 두뇌를 합리적으로 조율하여 혁신을 주도할 수 있는 놀라운 능력을 가지고 있습니다. 상업적 지원은 동기 부여의 격차를 해소하여 프로세스에 윤활유를 공급할 수 있습니다.

오픈 소스 소프트웨어는 종종 상용 솔루션에 대한 더 나은 대안으로 작용하며, 경우에 따라서는 오픈 소스 코드가 매우 우수하여 사실상 유일한 합리적인 솔루션이 되기도 합니다.

오픈소스 커뮤니티가 지금과 같은 규모로 성장하지 않았다면 기술 발전 속도가 어떻게 되었을지 정확히 예측하기는 어렵지만, 오픈소스 모델이 기술 발전 속도를 가속화했으며 앞으로도 계속 그럴 것이라고 말하는 것은 무리가 아닐 것입니다.