오픈소스란 무엇인가요?

소스 코드를 공개하고 라이선스 조건에 따라 사용, 수정, 재배포를 허용하는 소프트웨어입니다.

Git과 GitHub는 무엇이 다른가요?

Git은 분산 버전 관리 도구이며 GitHub는 Git 저장소를 호스팅하고 협업 기능을 제공하는 서비스입니다.

GitHub는 어떻게 수익을 내나요?

기업과 팀을 위한 유료 구독, 개발 도구와 추가 사용량 등으로 수익을 얻습니다.

오픈소스란 무엇이며, GitHub는 어떻게 성장하고 수익을 내나요?

작성·검토 쉬었음.com발행 2026년 9월 11일

오픈소스는 단순히 소스 코드를 공개하는 것이 아니라, 다른 사람이 정해진 라이선스에 따라 소프트웨어를 사용하고 분석하며 수정하고 재배포할 수 있도록 권리를 부여하는 방식입니다. GitHub는 이러한 공동 개발을 저장소, 버전 관리, 코드 검토, 자동화라는 하나의 작업 흐름으로 연결해 성장한 상업 플랫폼입니다.

GitHub의 핵심 사업 모델은 공개 오픈소스 프로젝트를 직접 판매하는 것이 아닙니다. 무료 사용자를 대규모로 모은 뒤 기업이 필요로 하는 비공개 협업, 접근 통제, 보안, 규정 준수, 자동화, 클라우드 개발 환경, 인공지능 기능에 요금을 부과합니다.

오픈소스란 정확히 무엇인가요?

오픈소스 이니셔티브(Open Source Initiative·OSI)의 정의에 따르면 오픈소스 라이선스는 자유로운 재배포를 허용하고, 소스 코드를 제공하며, 수정 및 파생 저작물의 배포를 허용해야 합니다. 특정 개인이나 집단, 사용 분야를 차별해서도 안 됩니다. 따라서 “비영리 목적으로만 사용 가능”하거나 “경쟁 제품에는 사용할 수 없음”과 같은 제한이 붙으면 소스가 공개되어 있더라도 일반적인 의미의 오픈소스로 인정되기 어렵습니다. OSI의 Open Source Definition

이 차이는 GitHub의 공개 저장소에서 특히 중요합니다. 저장소를 누구나 볼 수 있게 공개했더라도 오픈소스 라이선스가 없다면 기본 저작권법이 적용됩니다. 다른 사람은 GitHub 서비스 안에서 저장소를 열람하거나 포크할 수는 있지만, 코드를 자유롭게 복제·수정·배포할 권리까지 자동으로 얻는 것은 아닙니다. GitHub도 진정한 오픈소스 프로젝트가 되려면 이용 권한을 명시한 라이선스가 필요하다고 설명합니다. GitHub의 저장소 라이선스 안내

따라서 다음 세 문장은 서로 다른 뜻입니다.

“코드를 볼 수 있다”는 것은 소스 공개 여부에 관한 설명입니다.
“무료로 사용할 수 있다”는 것은 가격에 관한 설명입니다.
“오픈소스다”라는 말은 라이선스가 부여하는 권리에 관한 설명입니다.

무료 소프트웨어가 반드시 오픈소스인 것은 아니며, 오픈소스 소프트웨어를 판매하는 것도 가능합니다.

오픈소스 운동은 어떤 배경에서 등장했나요?

소프트웨어 코드를 공유하고 함께 개선하는 관행은 초기 컴퓨터 연구 공동체부터 존재했습니다. 그러나 소프트웨어가 독립적인 상업 제품으로 발전하고 저작권과 사용권이 강화되면서, 이용자가 소프트웨어를 연구하고 고칠 수 있어야 한다는 문제의식도 함께 커졌습니다.

1980년대에는 Richard Stallman이 GNU 프로젝트와 자유 소프트웨어 운동을 전개했습니다. 자유 소프트웨어에서 ‘자유’는 가격이 아니라 프로그램을 실행하고, 연구하고, 수정하고, 원본이나 수정본을 재배포할 수 있는 이용자의 자유를 뜻합니다. GNU의 자유 소프트웨어 정의

‘오픈소스’라는 명칭은 1998년 Netscape가 브라우저 소스 공개 계획을 발표한 직후 열린 전략 회의에서 만들어졌습니다. 같은 해 Eric Raymond와 Bruce Perens 등이 OSI를 설립했고, Debian 자유 소프트웨어 지침을 바탕으로 Open Source Definition을 정리했습니다. 목표는 공동 개발 방식의 실용적 장점을 기업과 대중에게 더 명확하게 설명하는 것이었습니다. OSI 역사

자유 소프트웨어와 오픈소스는 허용하는 라이선스의 범위가 대부분 겹치지만 강조점은 다릅니다.

구분	자유 소프트웨어	오픈소스
중심 질문	이용자의 자유가 보장되는가	공개 협업과 재사용이 가능한가
주요 관점	윤리적·사회적 권리	개발 방법과 실용적 효과
‘Free’의 의미	무료가 아니라 자유	가격보다 라이선스와 개발 방식
실제 소프트웨어 범위	오픈소스와 대부분 겹침	자유 소프트웨어와 대부분 겹침

이 차이는 어느 한쪽이 항상 더 우수하다는 뜻이 아닙니다. 같은 프로그램을 두고도 한쪽은 이용자의 권리를, 다른 쪽은 투명한 개발과 분산 협업의 효율을 중심으로 설명할 수 있다는 뜻입니다.

오픈소스 개발은 어떻게 작동하나요?

오픈소스는 “누구나 마음대로 코드를 바꾸는 상태”가 아닙니다. 참여는 열려 있을 수 있지만, 공식 버전에 무엇을 반영할지는 프로젝트의 관리자와 정해진 절차가 결정합니다.

일반적인 개발 과정은 다음과 같습니다.

관리자가 소스 코드와 라이선스, 사용법, 기여 규칙을 공개합니다.
이용자는 저장소를 복제하거나 포크해 독립적인 작업 공간을 만듭니다.
버그 수정이나 기능 개발을 별도의 브랜치에서 진행합니다.
변경 내역과 이유를 담은 풀 리퀘스트(Pull Request)를 제출합니다.
관리자가 코드, 테스트 결과, 설계 방향, 보안 영향을 검토합니다.
기준을 통과한 변경만 공식 저장소에 병합합니다.
새 버전을 배포하고 이후 발견된 문제를 다시 추적합니다.

여기에는 역할의 차이가 존재합니다. 사용자는 소프트웨어를 이용하고 문제를 보고합니다. 기여자는 코드나 문서를 제출합니다. 관리자는 검토와 릴리스를 담당합니다. 프로젝트 운영위원회나 재단이 상표, 예산, 의사결정 규칙까지 관리하기도 합니다.

즉, 오픈소스의 ‘열림’은 의사결정권이 전혀 없다는 뜻이 아닙니다. 참여할 기회와 코드를 활용할 권리는 개방하되, 공식 프로젝트에는 품질을 유지하기 위한 통제 구조가 존재합니다.

오픈소스 라이선스에는 어떤 차이가 있나요?

오픈소스 라이선스는 크게 허용적 라이선스와 카피레프트 라이선스로 나눠 이해할 수 있습니다.

허용적 라이선스

MIT, BSD, Apache License 2.0 등이 대표적입니다. 저작권 고지나 라이선스 문구 유지 같은 조건을 지키면 수정한 코드를 독점 소프트웨어에 포함하는 것도 대체로 허용합니다.

기업이 상용 제품에 쉽게 통합할 수 있다는 장점이 있지만, 개선된 코드가 반드시 원래 공동체로 돌아온다는 보장은 없습니다. Apache License 2.0은 명시적인 특허 관련 조항도 포함하고 있어 MIT 라이선스와 법적 조건이 완전히 같지는 않습니다.

카피레프트 라이선스

GNU General Public License(GPL) 등이 대표적입니다. 코드를 수정해 배포하거나 해당 코드와 결합한 파생 저작물을 배포할 때 동일한 라이선스로 소스를 제공하도록 요구할 수 있습니다.

카피레프트는 상업적 사용을 금지하는 제도가 아닙니다. 상업적으로 판매할 수 있지만, 라이선스가 정한 범위의 소스 공개 의무를 따라야 한다는 의미입니다. LGPL, AGPL처럼 라이브러리 결합이나 네트워크 서비스에 관한 조건을 다르게 설계한 변형도 있습니다.

라이선스를 고를 때는 “유명한 프로젝트가 사용한다”는 이유만으로 결정해서는 안 됩니다. 파생 저작물의 공개 범위, 특허 조항, 네트워크 서비스 제공, 다른 라이선스와의 호환성 등을 검토해야 합니다.

오픈소스와 Git, GitHub의 차이는 무엇인가요?

세 개념은 자주 함께 등장하지만 서로 다른 층위에 있습니다.

오픈소스는 소프트웨어 이용 권한과 공동 개발 방식을 설명하는 개념입니다.
Git은 파일 변경 이력을 분산해서 관리하는 오픈소스 버전 관리 프로그램입니다.
GitHub는 Git 저장소를 인터넷에서 호스팅하면서 코드 검토, 이슈 관리, 자동화, 보안 및 협업 기능을 제공하는 상업 서비스입니다.

Git은 2005년 Linux 커널 개발 공동체와 독점 분산 버전 관리 도구 BitKeeper의 관계가 종료된 뒤 만들어졌습니다. Linux처럼 규모가 큰 프로젝트에서 속도, 분산 작업, 수많은 병렬 브랜치를 처리할 수 있는 도구가 필요했기 때문입니다. Git 공식 역사

Git을 사용하면 중앙 서버에 항상 접속하지 않아도 전체 변경 이력을 가진 저장소를 각 개발자가 보유할 수 있습니다. 그러나 명령어 기반 Git만으로는 “누가 어떤 변경을 제안했고, 왜 필요한지, 누가 검토하며, 언제 병합할지”를 관리하기가 불편했습니다. GitHub는 바로 이 협업 과정을 웹 인터페이스로 정리했습니다.

GitHub 없이도 Git을 사용할 수 있고, GitLab이나 Bitbucket 또는 자체 서버에서 저장소를 운영할 수도 있습니다. 반대로 GitHub에는 오픈소스뿐 아니라 기업의 비공개 코드와 라이선스가 없는 공개 코드도 존재합니다. GitHub와 오픈소스는 동일어가 아닙니다.

GitHub는 어떻게 탄생했나요?

GitHub는 Tom Preston-Werner, Chris Wanstrath, PJ Hyett를 중심으로 개발됐으며 2008년 공개 서비스를 시작했습니다. 초기 팀에는 Git 전문가이자 이후 『Pro Git』 저자로 알려진 Scott Chacon도 합류했습니다.

GitHub 내부 저장소의 첫 커밋은 2007년 10월에 만들어졌고, 서비스는 2008년 4월 공개됐습니다. 출범 1년 무렵 GitHub는 외부 투자를 전혀 받지 않은 상태에서 4명의 정규 직원과 2만 개가 넘는 공개 저장소를 보유하고 있었습니다. GitHub의 첫해 기록

GitHub가 해결하려던 문제는 단순한 파일 보관이 아니었습니다. 분산된 Git 저장소 사이에서 어떤 변화가 발생했는지 시각화하고, 다른 개발자의 작업을 발견하며, 변경 제안을 쉽게 검토할 수 있는 협업 환경을 만드는 것이었습니다. 2008년 GitHub가 공개한 네트워크 그래프도 여러 사용자의 브랜치와 커밋 관계를 한 화면에 보여주려는 시도였습니다. 초기 Network Graph 소개

이 접근은 훗날 ‘소셜 코딩’이라고 불렸습니다. 개발자의 프로필, 활동 기록, 팔로우, 포크, 스타, 이슈, 풀 리퀘스트가 코드 저장소와 결합하면서 개발 과정 자체가 검색하고 관찰할 수 있는 네트워크가 됐습니다.

GitHub는 왜 빠르게 성장했나요?

GitHub의 성장은 Git 저장 공간을 무료로 제공했기 때문만으로 설명되지 않습니다. 기술적 시기, 사용자 경험, 네트워크 효과, 기업용 사업 모델이 함께 작동했습니다.

Git의 복잡한 협업 과정을 웹에서 이해할 수 있게 만들었습니다

브랜치, 커밋, 병합은 Git의 강력한 기능이지만 초보자가 명령어만으로 이해하기는 쉽지 않습니다. GitHub는 코드 차이, 토론, 검토 결과, 테스트 상태를 풀 리퀘스트 화면에 모았습니다.

개발자는 이메일로 패치 파일을 돌리는 대신 링크 하나로 변경 내용을 공유할 수 있게 됐습니다. 프로젝트 관리자는 코드와 논의 과정이 함께 기록되므로 검토 비용을 줄일 수 있었습니다.

공개 저장소가 개발자 네트워크를 만들었습니다

한 프로젝트가 GitHub에 들어오면 그 프로젝트의 사용자와 기여자도 계정을 만들 가능성이 커집니다. 사용자는 다시 다른 프로젝트를 만들거나 기존 프로젝트에 참여합니다.

저장소가 많아질수록 개발자는 코드를 찾기 위해 GitHub를 방문하고, 개발자가 많아질수록 프로젝트 관리자는 기여자를 얻기 위해 GitHub를 선택하게 됩니다. 이것이 양면 네트워크 효과입니다.

공개 활동 기록은 개발자의 포트폴리오 역할도 했습니다. 기업은 지원자의 실제 코드와 협업 경험을 확인할 수 있었고, 개발자는 취업이나 평판 형성을 위해 활동을 축적할 동기를 얻었습니다.

오픈소스와 기업용 제품을 동시에 키웠습니다

GitHub는 공개 오픈소스 저장소의 진입 장벽을 낮추는 한편, 비공개 저장소에는 초기부터 요금을 부과했습니다. 2011년에는 기업 내부 서버에서 운영할 수 있는 GitHub Enterprise를 출시해 인증, 백업, 팀 관리 같은 기업 요구를 수용했습니다. GitHub Enterprise 출시 기록

이 구조 덕분에 개인 개발자는 오픈소스 프로젝트에서 GitHub 사용법을 익히고, 회사에 들어가서는 같은 작업 방식의 기업용 버전을 사용할 수 있었습니다. 개인에게 별도의 영업을 하지 않아도 개발자가 조직 안으로 제품을 가져가는 상향식 도입이 가능해진 것입니다.

GitHub는 외부 투자 없이도 유료 서비스로 수익성과 성장을 확보했다고 밝혔으며, 2012년에 처음으로 외부 투자를 유치했습니다. GitHub의 2012년 투자 발표

무료 범위를 넓혀 경쟁 서비스로 이동할 이유를 줄였습니다

2019년 GitHub는 무료 개인 계정에 비공개 저장소를 제공하기 시작했습니다. 2020년에는 무료 비공개 저장소의 협업자 제한까지 없애고 핵심 팀 기능을 무료화했습니다. 기업에 필요한 고급 권한 관리, 보안, 지원 기능은 유료 영역으로 남겼습니다. GitHub Free 확대 발표

무료 사용 범위를 넓히면 단기적으로 일부 구독 매출을 포기해야 합니다. 그러나 더 많은 개인과 소규모 팀을 플랫폼에 묶어 두고, 조직이 성장했을 때 Team·Enterprise·보안·AI 제품으로 전환할 기회를 확보할 수 있습니다.

Microsoft 인수는 GitHub의 성장에 어떤 영향을 주었나요?

Microsoft는 2018년 GitHub를 75억 달러 상당의 Microsoft 주식으로 인수하기로 합의했습니다. 당시 GitHub가 발표한 이용자 규모는 2,800만 명 이상이었습니다. Microsoft는 GitHub가 독립적인 운영과 개발자 중심의 성격을 유지할 것이라고 밝혔습니다. Microsoft의 GitHub 인수 발표

이 인수에는 양쪽의 전략적 필요가 맞물려 있었습니다. GitHub는 세계적인 클라우드 인프라와 기업 영업망, 보안 및 규정 준수 역량을 활용할 수 있었습니다. Microsoft는 Windows와 독점 소프트웨어 중심 기업이라는 과거 이미지를 넘어, 운영체제나 프로그래밍 언어에 관계없이 개발자와 접점을 확보할 수 있었습니다. Azure, Visual Studio, VS Code와 GitHub를 연결할 기회도 생겼습니다.

인수 이후 GitHub는 저장소 호스팅을 넘어 개발 생명주기 전반을 다루는 플랫폼으로 확장했습니다. GitHub Actions는 빌드·테스트·배포를 자동화하고, Codespaces는 클라우드 개발 환경을 제공합니다. Advanced Security 계열은 코드와 의존성, 비밀정보를 검사하며, Copilot은 AI 기반 코드 작성과 검토 기능을 제공합니다.

Microsoft는 2022년 10월 GitHub의 연간 반복 매출(ARR)이 10억 달러에 도달했고 이용자가 인수 당시보다 3배 늘어난 9,000만 명 이상이라고 발표했습니다. Microsoft FY2023 1분기 실적 발표

GitHub는 2023년 1억 명, 2025년 1억 8,000만 명 이상의 개발자가 플랫폼을 사용한다고 발표했습니다. 2025년에는 전체 프로젝트가 6억 3,000만 개에 이르렀고, 전체 기여의 약 81.5%가 비공개 저장소에서 발생했다고 집계했습니다. 이는 GitHub가 오픈소스 공간인 동시에 대규모 기업 개발 인프라가 됐다는 점을 보여줍니다. GitHub Octoverse 2025

다만 이 수치는 GitHub가 자체 기준으로 집계한 플랫폼 지표입니다. 등록 개발자 수를 월간 활성 사용자 수나 유료 고객 수와 동일하게 해석해서는 안 됩니다. Microsoft도 GitHub의 최신 매출과 영업이익을 매년 독립 사업부 형태로 상세 공시하지 않으므로, 2022년의 ARR 10억 달러는 현재 매출액이 아니라 당시 공개된 대표적인 규모 지표로 봐야 합니다.

GitHub는 구체적으로 어디에서 돈을 버나요?

GitHub의 수익 구조는 “무료 공개 플랫폼으로 사용자를 확보하고, 조직 운영에 필요한 통제와 생산성에 과금하는 프리미엄 모델”로 요약할 수 있습니다.

수익원	주요 구매자	고객이 비용을 지불하는 이유	과금 방식
Team·Enterprise 구독	개발팀과 기업	권한 관리, 정책, 감사, 규정 준수, 지원	사용자 좌석 기준 구독
Copilot	개인·조직·기업	AI 코드 작성, 질의, 검토, 에이전트 기능	사용자 구독과 일부 사용량
보안 제품	보안 요구가 큰 조직	취약점, 비밀정보, 공급망 위험 탐지	라이선스 또는 활성 사용자 기준
Actions	자동화 사용 조직	빌드·테스트·배포 실행	포함량 초과 시 사용량
Codespaces	개발 환경을 표준화하는 조직	클라우드 컴퓨팅과 저장 공간	컴퓨팅 시간·저장량
Packages·Git LFS	대용량 파일·패키지 사용자	저장·전송 인프라	포함량 초과 시 사용량
Marketplace	외부 앱 개발사와 구매자	앱 검색, 설치, 결제 통합	거래 수수료

사용자 좌석 기반 구독

무료 플랜은 개인과 작은 팀이 핵심 저장소 기능을 사용할 수 있게 합니다. Team 플랜은 고급 협업 기능을, Enterprise 플랜은 보안, 규정 준수, 중앙 관리 및 배포 선택권을 제공합니다.

2026년 9월 확인 기준 공식 가격표에는 Team이 사용자당 월 4달러, Enterprise가 사용자당 월 21달러부터로 제시되어 있습니다. 계약 기간, 지역, 세금, 대규모 계약 조건에 따라 실제 금액은 달라질 수 있습니다. GitHub 공식 가격표

좌석 과금은 기업의 인원이 늘수록 반복 매출이 함께 증가한다는 장점이 있습니다. 한번 코드와 업무 절차가 플랫폼에 정착하면 이전 비용도 커지므로 계약 유지 가능성이 높아집니다.

AI 제품 구독과 사용량 과금

GitHub Copilot은 개인용과 조직용 유료 플랜을 갖고 있습니다. 기업은 사용자별 좌석을 구매하고, 플랜에 포함된 AI 사용량을 초과하면 추가 사용량 비용이 발생할 수 있습니다. 따라서 Copilot은 전통적인 소프트웨어 구독과 AI 연산량 과금이 결합된 구조로 발전하고 있습니다. GitHub Copilot 조직 청구 안내

Copilot은 GitHub에 새로운 수익원을 추가했을 뿐 아니라 저장소, 이슈, 풀 리퀘스트, 코드 검토라는 기존 작업 흐름 안에서 AI를 소비하게 만듭니다. 별도의 AI 도구를 판매하는 것보다 기존 플랫폼 고객에게 추가 제품을 교차 판매하기 쉬운 구조입니다.

보안과 규정 준수 제품

대기업은 코드를 저장하는 기능만으로 비용을 지불하지 않습니다. 계정 통제, 감사 로그, 싱글 사인온, 비밀정보 탐지, 코드 취약점 분석, 공급망 관리, 규제 대응이 필요합니다.

오픈소스 의존성이 많아질수록 취약한 패키지나 유출된 인증정보를 지속적으로 검사해야 합니다. 무료 생태계의 확대가 역설적으로 기업용 보안 제품의 필요도 키우는 셈입니다.

컴퓨팅·저장·자동화 사용량

GitHub Actions, Codespaces, Packages 같은 서비스는 일정 사용량을 플랜에 포함하고 초과분에 비용을 부과합니다. 기업 청구서에는 Enterprise 라이선스뿐 아니라 Actions나 Codespaces의 초과 사용량, Copilot과 보안 제품 같은 추가 라이선스가 함께 포함될 수 있습니다. GitHub Enterprise 청구 구조

이 모델은 개발 활동이 많아질수록 GitHub의 매출도 증가할 수 있게 합니다. 반면 GitHub도 실행 서버, 저장 장치, 네트워크, AI 모델 비용을 부담하므로 사용량 매출 전체가 이익이 되는 것은 아닙니다.

Marketplace 거래 수수료

외부 개발사는 GitHub Marketplace에서 유료 앱을 판매할 수 있습니다. GitHub는 결제와 구독 관리를 제공하고 거래액 일부를 운영 비용 명목으로 보유합니다. 공식 문서상 2021년 이후 앱 거래에 적용되는 보유 비율은 5%입니다. GitHub Marketplace 판매 대금 안내

Marketplace의 직접 수수료뿐 아니라 외부 도구가 GitHub를 중심으로 작동하게 만든다는 점도 중요합니다. 앱이 많아지면 GitHub를 떠날 때 교체해야 하는 개발 도구가 늘어나 플랫폼의 유지력이 강해집니다.

무료 오픈소스는 왜 GitHub에 경제적 가치가 있나요?

무료 공개 저장소는 GitHub 입장에서 단순한 비용 항목이 아니라 사용자 획득과 생태계 형성을 담당하는 핵심 자산입니다.

첫째, 오픈소스 프로젝트가 새로운 사용자를 불러옵니다. 특정 라이브러리를 사용하거나 문제를 신고하거나 패치를 제출하려는 개발자는 GitHub 계정을 만들게 됩니다. GitHub는 이 사용자를 광고비를 들여 확보하지 않아도 됩니다.

둘째, 오픈소스 활동이 GitHub 사용법을 사실상의 업계 표준으로 만듭니다. 개발자는 학교나 개인 프로젝트에서 포크, 이슈, 풀 리퀘스트를 익힌 뒤 회사에서도 같은 방식을 선호합니다.

셋째, 공개 생태계와 비공개 기업 개발은 서로 의존합니다. 기업의 비공개 제품도 수많은 공개 라이브러리와 도구를 사용합니다. GitHub의 2025년 자료에서 기여 활동 대부분은 비공개 저장소에서 발생했지만 저장소 수로는 공개 프로젝트가 다수를 차지했습니다. 무료 공개 생태계가 유료 기업 업무의 기반을 제공하는 구조입니다.

넷째, 공개 프로젝트가 활발할수록 보안과 자동화 수요도 증가합니다. 의존성 업데이트, 악성 패키지 탐지, 라이선스 관리, 대규모 테스트와 배포가 필요해지기 때문입니다.

따라서 GitHub의 무료 오픈소스 지원은 자선 활동과 상업 활동 중 하나만으로 설명하기 어렵습니다. 개발자 공동체에 실제 가치를 제공하는 동시에 유료 기업 시장으로 이어지는 장기적인 유통 전략입니다.

오픈소스 기업은 일반적으로 어떻게 수익을 내나요?

GitHub의 사업 모델은 오픈소스를 활용한 여러 수익 모델 중 하나입니다. 오픈소스 기업은 복제 가능한 코드 자체보다 운영의 편의성, 책임, 보안, 전문성에 가격을 붙이는 경우가 많습니다.

지원과 컨설팅: 소프트웨어는 무료로 제공하고 설치, 장애 대응, 교육, 장기 지원에 비용을 부과합니다.
관리형 클라우드: 직접 설치할 수 있는 오픈소스와 별도로 운영을 대신하는 SaaS를 판매합니다.
오픈 코어: 핵심 기능은 공개하고 기업용 관리·보안·분석 기능은 독점 라이선스로 제공합니다.
이중 라이선스: 같은 코드에 오픈소스 라이선스와 상용 라이선스를 함께 제공해 이용자가 조건에 맞게 선택하게 합니다.
호스팅과 사용량: 저장, 네트워크, 컴퓨팅, 자동화 실행량에 따라 비용을 부과합니다.
후원과 기부: 개인, 기업, 재단이 관리자나 프로젝트 운영을 지원합니다.
인증과 교육: 공식 교육, 시험, 기술 인증 또는 파트너 프로그램으로 수익을 얻습니다.

이러한 모델이 성립하는 이유는 소프트웨어 비용이 라이선스 가격에만 있지 않기 때문입니다. 기업은 설치 시간, 장애 위험, 보안 사고, 업데이트, 규제 대응, 전문 인력 부족까지 포함한 총소유비용을 고려합니다. 코드를 무료로 받을 수 있어도 안정적인 운영 책임에는 기꺼이 비용을 지불할 수 있습니다.

오픈소스와 GitHub에는 어떤 한계가 있나요?

오픈소스는 참여자가 많다고 자동으로 안전하고 지속 가능한 소프트웨어가 되는 방식이 아닙니다.

유지보수 부담이 소수에게 집중될 수 있습니다

널리 쓰이는 라이브러리도 실제 검토와 배포는 몇 명의 관리자에게 의존할 수 있습니다. 이용자가 늘면 문제 보고와 보안 대응 부담은 커지지만, 관리자의 보상은 함께 증가하지 않을 수 있습니다.

공개 검토는 품질을 보장하지 않습니다

소스가 공개돼 있다는 사실과 누군가가 충분히 검토했다는 사실은 다릅니다. 취약점, 악성 기여, 탈취된 관리자 계정, 오염된 의존성 같은 공급망 위험이 존재합니다.

라이선스 의무를 놓칠 수 있습니다

플랫폼 집중은 새로운 의존성을 만듭니다

Git은 분산형이므로 저장소를 다른 서버로 옮길 수 있습니다. 그러나 이슈, 풀 리퀘스트 토론, Actions 워크플로, 접근 정책, Marketplace 앱, 보안 기록까지 완전히 이전하는 일은 훨씬 어렵습니다.

GitHub가 편리할수록 개발 공동체가 한 기업의 가격, 정책, 장애 대응 및 기능 변경에 의존할 가능성도 커집니다. 코드를 로컬에 복제하고, 릴리스와 문서를 백업하며, 특정 플랫폼 기능에 대한 의존도를 파악할 필요가 있습니다.

흔히 발생하는 오해는 무엇인가요?

“GitHub에 공개했으니 오픈소스다”

라이선스가 없다면 일반적인 오픈소스 이용 권한이 생기지 않습니다. 공개 범위와 라이선스는 별개의 설정입니다.

“오픈소스는 모두 무료다”

복제 비용이 없을 수는 있지만 운영, 지원, 클라우드, 교육, 보안 기능에는 비용이 발생할 수 있습니다. 오픈소스 라이선스는 유료 판매를 금지하지 않습니다.

“누구나 공식 코드를 마음대로 바꿀 수 있다”

누구나 자신의 복사본을 수정할 수 있는 권리와 공식 프로젝트에 변경을 반영할 권한은 다릅니다. 공식 반영 여부는 관리자와 거버넌스 규칙이 결정합니다.

“GitHub 자체가 오픈소스다”

GitHub는 오픈소스 프로젝트를 대규모로 호스팅하고 여러 오픈소스 도구를 공개하지만, GitHub 서비스 전체가 하나의 오픈소스 제품인 것은 아닙니다. GitHub는 Microsoft가 소유한 상업 플랫폼입니다.

“GitHub의 사용자가 많으니 대부분 유료 사용자다”

GitHub가 발표하는 개발자 수에는 무료 계정도 포함됩니다. 전체 등록 개발자, 활성 개발자, 기업 고객, 유료 좌석은 서로 다른 지표입니다.

“Microsoft가 GitHub를 무료로 운영한다”

무료 저장소가 넓게 제공되지만 기업용 좌석, AI, 보안, 자동화, 컴퓨팅, 저장 및 Marketplace에서 수익이 발생합니다. 무료 사용자는 유료 고객으로 전환될 가능성과 네트워크 가치를 제공합니다.

오픈소스 프로젝트는 어떻게 평가해야 하나요?

오픈소스를 실제 프로젝트에 도입하려면 별 개수나 GitHub 순위만 보지 말고 다음 항목을 함께 확인해야 합니다.

LICENSE 파일과 사용하려는 방식의 법적 호환성
최근 릴리스와 보안 업데이트 주기
핵심 관리자 수와 특정 개인에 대한 의존도
이슈와 풀 리퀘스트의 검토 속도
테스트, 자동화, 취약점 신고 절차의 존재
문서와 업그레이드 안내의 완성도
직접 운영할 때 필요한 인력과 비용
GitHub 또는 특정 클라우드 서비스에 대한 종속성
프로젝트 중단 시 사용할 수 있는 대안과 이전 가능성

GitHub를 업무 플랫폼으로 선택할 때도 같은 원칙이 적용됩니다. 무료 가격만 비교하기보다 필요한 권한 관리, 감사, 보안, 자동화 실행량, AI 사용량, 데이터 위치, 장애 대응, 이전 비용을 합쳐 평가해야 합니다.

오픈소스와 GitHub의 관계를 어떻게 이해해야 하나요?

오픈소스는 소프트웨어를 함께 사용하고 개선할 수 있도록 권리를 배분하는 규칙입니다. Git은 그 변경 이력을 분산해서 관리하는 도구이고, GitHub는 Git 기반 협업을 대규모로 중개하는 플랫폼입니다.

GitHub는 오픈소스를 발명하지 않았습니다. 대신 오픈소스 공동체에 필요했던 발견, 복제, 토론, 검토, 병합 과정을 하나의 웹 작업 흐름으로 단순화했습니다. 공개 프로젝트가 개발자 네트워크를 만들었고, 그 네트워크가 기업의 비공개 개발까지 GitHub로 끌어들였습니다.

그 결과 GitHub는 공개 코드에 입장료를 부과하기보다 기업이 규모 있게 협업할 때 필요한 통제, 보안, 자동화, 컴퓨팅과 AI에 비용을 부과하는 구조를 구축했습니다. “공개된 것은 무료이고 비공개인 것은 유료”라는 초기 모델에서 출발했지만, 현재는 “기본 협업은 무료이고 조직적 복잡성을 해결하는 기능은 유료”인 개발 플랫폼 사업으로 확장됐다고 정리할 수 있습니다.