191. OSS 라이선스 컴플라이언스 (OSS License Compliance)

핵심 인사이트

본질: OSS (Open Source Software) 라이선스 컴플라이언스는 오픈소스 사용 시 해당 라이선스 조건을 준수하는 법적 의무로, GPL (GNU General Public License)의 '전염성(Copyleft)'이 핵심 리스크다.

가치: 라이선스 위반은 소송·강제 소스 공개·제품 판매 중단 위험을 수반하므로, SBOM (Software Bill of Materials) 관리가 공급망 보안과 법적 보호의 핵심 수단이다.

판단 포인트: 기술사 답안에서는 "Copyleft 강도 분류(강·약·약한 약) → 라이선스 충돌 매트릭스 → SBOM 도입 효과 → 상용화 전략"을 체계적으로 다루면 고득점이다.

Ⅰ. 개요 및 필요성

현대 소프트웨어의 80~90%는 하나 이상의 오픈소스 컴포넌트를 포함한다. Linux 커널, Apache HTTP Server, OpenSSL 등 핵심 인프라도 오픈소스다. 이러한 광범위한 오픈소스 활용은 생산성을 높이지만, 동시에 라이선스 의무 미준수 시 법적·재무적 위험을 초래한다.

GPL 라이선스의 '카피레프트(Copyleft)' 조항은 GPL 코드와 결합된 전체 소프트웨어에 동일한 GPL 라이선스를 적용하도록 강제한다. 이를 GPL 전염성이라 부르며, 상용 제품에 GPL 컴포넌트를 잘못 포함시키면 전체 소스코드를 공개해야 하는 의무가 발생한다. 이는 핵심 지식재산권(IP, Intellectual Property) 보호에 심각한 위협이다.

2021년 미국 바이든 행정부의 '사이버보안 행정명령' 이후 SBOM (Software Bill of Materials) 제출이 연방 소프트웨어 조달 요건으로 의무화되었고, 한국도 공공 소프트웨어 조달에 SBOM 도입을 추진 중이다. SBOM은 소프트웨어의 구성요소 목록으로, 공급망 보안(Supply Chain Security)과 라이선스 컴플라이언스를 동시에 지원한다.

📢 섹션 요약 비유: GPL 라이선스는 마치 '이 레시피를 쓰면 당신 레시피도 공개해야 해'라는 요리책 규정 같다 — 상업적 셰프라면 그 레시피는 피해야 한다.

Ⅱ. 아키텍처 및 핵심 원리

OSS 라이선스 컴플라이언스 관리 체계

┌─────────────────────────────────────────────────────────────────┐
│           OSS 라이선스 컴플라이언스 관리 파이프라인              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  [소스코드 / 패키지 도입]                                        │
│          │                                                       │
│          ▼                                                       │
│  ┌─────────────────────┐    ┌──────────────────────────┐        │
│  │  OSS 스캐닝 도구    │───▶│  라이선스 식별 & 분류    │        │
│  │  (FOSSA, Black Duck │    │  Copyleft 강도 평가      │        │
│  │   ScanCode Toolkit) │    └──────────┬───────────────┘        │
│  └─────────────────────┘              │                         │
│                                       ▼                         │
│                       ┌──────────────────────────────┐         │
│                       │  라이선스 충돌 검사           │         │
│                       │  (GPL ↔ Apache 충돌 탐지)    │         │
│                       └──────────┬───────────────────┘         │
│                                  │                              │
│                    ┌─────────────┴──────────────┐              │
│                    ▼                             ▼              │
│           ┌──────────────┐            ┌──────────────────┐     │
│           │  충돌 없음   │            │  충돌/고위험     │     │
│           │  SBOM 생성   │            │  대체 컴포넌트   │     │
│           │  & 배포 승인 │            │  탐색 또는 듀얼  │     │
│           └──────────────┘            │  라이선스 협상   │     │
│                                       └──────────────────┘     │
└─────────────────────────────────────────────────────────────────┘

OSS 라이선스 유형별 비교

라이선스	유형	카피레프트 강도	상용화 조건	대표 소프트웨어
GPL v2/v3	강한 Copyleft	강	파생 전체 소스 공개 필수	Linux, GCC
LGPL (Lesser GPL)	약한 Copyleft	약	라이브러리 링크 허용, 수정 시 공개	glibc, Qt
AGPL (Affero GPL)	강한 Copyleft+	강	네트워크 서비스도 공개 의무	MongoDB (구), Nextcloud
Apache 2.0	허용적 (Permissive)	없음	저작권 표시, 특허 명시	Android, Spring Framework
MIT	허용적 (Permissive)	없음	저작권 표시만	jQuery, React
BSD 2/3-Clause	허용적 (Permissive)	없음	저작권·면책 조항 표시	FreeBSD, OpenBSD

SBOM (Software Bill of Materials) 필수 요소

SBOM은 소프트웨어를 구성하는 모든 컴포넌트, 버전, 라이선스 정보를 기계가 읽을 수 있는 형식으로 기록한 명세서다. NTIA (National Telecommunications and Information Administration) 권고 기준으로는 공급업체명, 컴포넌트명, 버전, 고유 식별자(PURL, Package URL), 의존성 관계, 작성자, 타임스탬프가 최소 필수 요소다. 표준 형식으로는 SPDX (Software Package Data Exchange), CycloneDX, SWID가 사용된다.

📢 섹션 요약 비유: SBOM은 음식 재료 성분표와 같다 — 알레르기(라이선스 위반) 가능 성분을 미리 확인하고 안전하게 먹을 수 있다.

Ⅲ. 비교 및 연결

구분	GPL (Copyleft)	MIT/Apache (Permissive)
기본 철학	오픈소스의 자유를 유지·확산	최대한 자유로운 사용 허용
소스 공개 의무	파생 저작물 전체 공개 필수	없음 (저작권 표시만)
상용 제품 포함	전략적 리스크 高	자유롭게 포함 가능
특허 조항	GPL v3에 특허 조항 포함	Apache 2.0에 특허 허여 조항 포함
라이선스 호환성	GPL ↔ Apache 2.0 충돌 발생	대부분의 라이선스와 호환
재배포 조건	동일 라이선스 유지 필수	라이선스 변경 가능

라이선스 충돌(License Conflict) 주요 사례

GPL v2와 Apache 2.0은 특허 조항 차이로 인해 직접 결합 시 충돌이 발생한다. 해결책으로는 ① GPL v3로 업그레이드, ② Apache 2.0 컴포넌트 대체, ③ 듀얼 라이선싱(Dual Licensing) 협상이 있다. GPL v2와 GPL v3도 호환되지 않으므로 동일 프로젝트에 혼용 시 주의해야 한다.

📢 섹션 요약 비유: 라이선스 충돌은 서로 다른 회원제 클럽 두 곳의 규칙이 충돌해서 동시에 두 클럽을 이용할 수 없는 상황과 같다.

Ⅳ. 실무 적용 및 기술사 판단

엔터프라이즈 OSS 컴플라이언스 프로그램 구축
① Policy 수립: 허용/금지/조건부 사용 가능한 라이선스 목록을 정책으로 명문화한다.
② Tool 도입: FOSSA, Black Duck, ScanCode Toolkit 등 자동화 스캐닝 도구를 CI/CD 파이프라인에 통합하여 신규 의존성 추가 시 자동 검사한다.
③ SBOM 생성·관리: 빌드 단계마다 SPDX 또는 CycloneDX 형식의 SBOM을 자동 생성하고 버전 관리한다.
④ 교육·거버넌스: 개발자 대상 OSS 라이선스 교육을 연 1회 이상 실시하고, 법무팀·개발팀·보안팀 합동 OSS 위원회를 운영한다.
⑤ 취약점 연계: CVE (Common Vulnerabilities and Exposures) 데이터베이스와 연계하여 사용 중인 OSS 컴포넌트의 알려진 취약점을 모니터링한다.

기술사 답안 포인트
GPL 전염성 문제를 설명할 때 "링크 방식(정적/동적)"과 "결합 강도"에 따라 GPL 적용 범위가 달라진다는 점을 언급하고, LGPL의 동적 링크 예외 조항을 활용한 상용화 전략을 제시하면 심층적인 답안이 된다.

📢 섹션 요약 비유: OSS 컴플라이언스 프로그램은 대형 마트의 원산지 표시 관리 시스템과 같다 — 모든 식품 성분을 추적해서 법적 의무를 자동으로 충족시킨다.

Ⅴ. 기대효과 및 결론

체계적인 OSS 라이선스 컴플라이언스 프로그램은 법적 분쟁 예방, IP 보호, 공급망 투명성 확보의 세 가지 효과를 동시에 달성한다. SBOM 의무화 트렌드는 소프트웨어 공급망 전체의 투명성을 높여 Log4Shell과 같은 오픈소스 기반 공급망 공격에 대한 대응력을 강화한다.

미래 방향으로는 AI/ML 모델에서 사용된 학습 데이터의 라이선스 컴플라이언스 문제가 새로운 과제로 떠오르고 있다. 오픈소스 AI 모델(LLaMA, Mistral 등)의 사용 조건도 전통적 소프트웨어 라이선스와 다른 특수 조항을 포함하는 경우가 많아 전문적 검토가 필요하다.

📢 섹션 요약 비유: OSS 컴플라이언스는 자동차 안전 검사와 같다 — 귀찮지만 정기적으로 받지 않으면 사고가 나거나 운행 정지 처분을 받게 된다.

📌 관련 개념 맵

개념	설명	연관 키워드
Copyleft (카피레프트)	오픈소스의 자유를 파생 저작물에도 강제하는 원칙	GPL, AGPL, LGPL
SBOM	소프트웨어 구성요소 명세서	SPDX, CycloneDX, 공급망 보안
GPL 전염성	GPL 코드 결합 시 전체에 GPL 의무 적용	Copyleft, 소스 공개 의무
Permissive License	사용·배포·수정에 거의 제한 없는 허용적 라이선스	MIT, Apache 2.0, BSD
CVE	오픈소스 컴포넌트의 알려진 취약점 식별자	NVD, 취약점 관리, 패치

👶 어린이를 위한 3줄 비유 설명

GPL 라이선스는 '이 장난감 설계도를 쓰면 네 장난감 설계도도 공개해야 해'라는 규칙이에요.
MIT 라이선스는 '자유롭게 써도 되는데, 누가 만들었는지만 알려줘'라고 하는 친절한 라이선스예요.
SBOM은 장난감에 들어간 모든 부품 목록표처럼, 소프트웨어에 어떤 오픈소스가 들었는지 정확히 기록한 것이에요.