오픈소스

왜 배우는가: 오픈소스는 클라우드·AI·빅데이터 등 현대 SW 인프라의 기반이라 실무에서 라이선스와 공급망 관리가 필수다. 기술사 시험에서도 개념·특징·현황·시사점을 묻는 문제로 반복 출제된다.

출제 이력: 제124회 4교시 2번, 제89회 2교시 2번

1. 한 줄 정의와 핵심 키워드

오픈소스(OSS)는 소스코드를 공개하고 오픈소스 라이선스에 따라 누구나 사용·수정·재배포할 수 있는 소프트웨어다.

답안 첫 줄에는 위 정의를 쓴다. 정의 뒤에 자유로운 재배포와 소스코드 공개를 함께 적으면 감점을 줄일 수 있다.

핵심 키워드는 다음과 같다.

• 오픈소스(Open Source Software, OSS)
• 오픈소스 라이선스
• 카피레프트(Copyleft)
• 퍼미시브 라이선스(Permissive License)
• OSI(Open Source Initiative)
• 벤더 락인(Vendor Lock-in)
• SBOM(Software Bill of Materials)

2. 개념 풀이

쉽게 말하면 오픈소스는 "소스코드를 열어 두고 여럿이 함께 고쳐 쓰는 소프트웨어"다. 누구나 코드를 보고 기능을 추가하거나 버그를 고칠 수 있다.

정식 정의는 소스코드가 공개되고, 그 이용 조건이 오픈소스 라이선스로 정해진 소프트웨어다. 자유 소프트웨어가 자유라는 가치를 강조하는 말이라면, 오픈소스는 소스의 공개 형태 자체를 중시하는 말이다.

이 정의의 기준은 OSI(Open Source Initiative)가 정한 오픈소스 정의(OSD)다. OSI의 승인을 받은 라이선스가 대중적인 오픈소스 라이선스로 인정된다. 오픈소스는 대부분 무료로 쓸 수 있지만, 무료라는 것이 오픈소스의 본질은 아니다.

핵심 용어를 이해하는 데 필요한 구분은 다음과 같다.

카피레프트(Copyleft)는 파생 저작물도 같은 라이선스로 공개하도록 요구하는 방식이다. GPL 계열이 대표적이다.

퍼미시브 라이선스(Permissive License)는 재배포 시 저작권 표기 정도만 요구하고 파생물의 공개 의무가 약한 방식이다. MIT, BSD, Apache 계열이 여기에 속한다.

벤더 락인(Vendor Lock-in)은 특정 공급자에게 종속되어 전환이 어려운 상태를 말한다. 오픈소스는 이를 완화하는 수단으로 평가된다.

라이선스 의무를 지키지 않으면 저작권법 위반이나 계약 위반으로 소송을 당할 수 있다. 따라서 오픈소스는 "무료"보다 "조건부 자유"로 이해해야 한다.

3. 등장 배경과 필요성

소프트웨어가 상용 독점 방식으로만 유통되던 시기에는 사용자가 공급자에게 종속되는 문제가 컸다. 인터넷이 확산되면서 개발자들이 협업으로 코드를 공유하는 방식이 늘었고, 이 흐름을 법적으로 정리할 필요가 생겼다.

오픈소스 소프트웨어 운동은 저작권, 라이선스, 소비자 문제를 명확히 하기 위해 일어났다. "오픈 소스"라는 용어는 인터넷의 성장과 함께 대중화되었다.

필요성은 세 가지로 정리된다. 첫째, 개발 비용과 시간을 줄이는 경제성이다. 둘째, 특정 벤더에 의존하지 않는 탈종속성이다. 셋째, 많은 개발자가 코드를 검증하는 집단지성에 따른 품질 확보다. 특히 OSI 승인 라이선스 기준이 있어 라이선스 체계의 신뢰성이 확보되었다.

오픈소스는 독점 소프트웨어와 마찬가지로 저작권의 보호를 받는다. 다만 저작권자가 이용자에게 조건부로 권리를 허락하는 방식이 다르다. 이 점이 독점 소프트웨어와 가장 큰 차이다.

4. 구성요소·원리·절차

오픈소스 소프트웨어(OSS)는 소스코드 공개를 중심으로 여러 구성요소가 맞물려 돌아간다. 공개된 코드를 누구나 읽고 쓰는 것이 출발점이며, 그 위에 라이선스·커뮤니티·기여 절차가 얹힌다. 답안에서는 이 네 축을 표로 나눠 설명하는 것이 정리가 빠르다.

표 해설: 소스코드와 라이선스는 법적·기술적 기반이고, 커뮤니티와 거버넌스는 지속성을 결정한다. 라이선스가 없으면 공개 코드도 이용 조건이 불분명해지므로 두 축은 함께 설계된다.

핵심 원리는 세 가지다. 첫째, 소스 공개로 투명성이 확보되어 누구나 결함을 찾을 수 있다. 둘째, 수천 명의 독립 개발자가 버그를 테스트·수정하는 집단지성 효과가 나온다. 셋째, 라이선스가 2차 저작물의 재배포 조건을 정하므로 상용화와 공개 의무가 공존한다. 이 원리는 소스 공개와 협업 검증이 오픈소스 품질의 근거다라는 한 줄로 요약된다.

기여 절차는 다음과 같다.

• 프로젝트의 소스코드와 라이선스 조건을 확인한다.
• 저장소를 포크(Fork)하거나 복제하여 로컬에서 수정한다.
• 수정 내용을 풀 리퀘스트(Pull Request)로 제출한다.
• 커뮤니티 리뷰와 자동 테스트를 거쳐 메인 저장소에 병합한다.
• 재배포 시 라이선스 고지와 소스 공개 의무를 이행한다.

재배포 단계에서 빠지기 쉬운 것이 라이선스 고지다. 이 절차를 빠뜨리면 저작권 침해 소송으로 이어질 수 있다.

수식으로 보면 기여 효과는 개발자 수와 검증 주기로 설명할 수 있다. 결함 발견 기대치는 참여자가 많을수록 커진다는 점을 답안에 한 문장으로 쓴다.

$E_{\text{검증}} \propto N_{\text{검토자}} \cdot f_{\text{릴리스}}$

여기서 N_{\text{검토자}}는 검토에 참여하는 개발자 수(명), f_{\text{릴리스}}는 릴리스 빈도(회/년)다. 비례식은 정량 모델이 아니라 정성적 관계를 보이는 표현이므로 수치 계산에는 쓰지 않는다.

5. 관련 법령·기준·표준

오픈소스는 국내 법령보다 라이선스 계약이 직접 적용된다. 소프트웨어는 저작권법의 보호 대상이며, 오픈소스 저작권자는 라이선스로 이용 허락을 준다. 따라서 답안에서 법령은 저작권법과 소프트웨어 진흥 관련 제도를 큰 틀로 쓰고, 세부 조건은 라이선스 원문으로 돌린다.

대표 라이선스의 조건을 정리하면 다음과 같다.

표 해설: 카피레프트는 공개 범위가 넓고, 퍼미시브는 상용 이용 자유도가 높다. 기업이 내부 제품에 넣을 때는 두 계열의 의무 차이가 가장 중요한 판단 기준이다.

OSI(Open Source Initiative)는 오픈소스 정의(OSD)를 바탕으로 라이선스를 승인한다. 승인된 라이선스는 재배포 자유와 소스 접근성을 보장하는 것으로 본다. 개인 목적의 비상업 재배포만 허용하는 라이선스는 오픈소스 라이선스로 보지 않는다는 점도 답안에 쓸 만하다.

준수하지 않으면 저작권법 위반 또는 계약 위반으로 소송을 당할 수 있다. 패소 시 배포 중단과 손해배상 책임이 따른다. 이 위험을 줄이는 수단이 SBOM(Software Bill of Materials) 작성과 오픈소스 취약점 관리다.

국제 기준에서는 SPDX(Software Package Data Exchange)가 라이선스 식별자 표기의 공통 형식으로 쓰인다. 번호와 세부 버전이 불확실하면 이름만 쓴다.

GPL 계열: 파생 저작물 동일 조건 공개 와 Apache 2.0: 특허권 명시 를 구분해 기억한다. 기준 수치로 외울 것은 라이선스 조건이므로 수치형 기준값은 없다.

6. 유형과 비교

오픈소스 라이선스는 파생물에 대한 공개 의무에 따라 카피레프트형과 퍼미시브형으로 나뉜다. 이 차이가 기업의 상용 제품 결합 가능성을 좌우한다.