이 교육 자료는 기업 내 개발자가 오픈소스를 올바르고 안전하게 활용하기 위한 실무 지식을 다룹니다. 라이선스 컴플라이언스, 오픈소스 기여, 공개, SBOM을 포함한 공급망 보안을 다룹니다. 각 PART는 독립적으로 학습할 수 있으며, 전체를 순서대로 따라가면 오픈소스 활동의 전체 흐름을 이해할 수 있습니다.

오픈소스는 이미 기업 소프트웨어 개발의 핵심 인프라입니다. 단순히 사용하는 것에 그치지 않고 기여하고 공개하는 기업이 늘어나고 있습니다. 이 교육은 오픈소스를 올바르고 안전하게 활용하기 위한 실무 지식을 다룹니다.

네 가지 주제는 서로 독립적으로 학습할 수도 있고, 순서대로 따라가면 오픈소스 활동의 전체 흐름을 이해할 수 있습니다. 각 파트는 기업의 법적 리스크 최소화와 생태계 기여 극대화를 목표로 합니다.

OSPO는 오픈소스 활동에서 발생하는 저작권·라이선스·보안 문제를 사전에 방지하는 역할을 합니다. 규모에 따라 전담 조직이 없더라도 법무팀 또는 보안팀과 협력하는 유사 체계를 갖추는 것이 중요합니다. 모호한 판단이 필요한 경우에는 언제나 OSPO 또는 법무팀에 먼저 문의하는 습관이 중요합니다.

이 파트에서는 외부 오픈소스 소프트웨어를 제품·서비스에 활용할 때 알아야 할 라이선스 지식과 컴플라이언스 프로세스를 다룹니다.

가장 흔한 오해는 "GitHub에 공개된 코드는 자유롭게 써도 된다"는 것입니다. 이는 사실이 아닙니다. 라이선스가 없는 코드는 저작권자의 독점 상태이므로, 반드시 명시된 라이선스를 확인해야 합니다. 라이선스 위반은 단순한 규정 위반을 넘어 제품 출시 중단, 법적 소송으로 이어질 수 있습니다.

수년 전에 커뮤니티 활동이 멈춘 오픈소스는 보안 패치를 기대할 수 없어 위험합니다. 특히 라이선스는 도입 후에 발견하면 이미 제품 설계 변경이 어려워지므로 반드시 선택 단계에서 확인해야 합니다. 이 5가지 항목 중 하나라도 문제가 있다면 도입을 재고하거나 대안을 탐색하는 것이 좋습니다.

저작권과 특허권의 차이를 이해하면 오픈소스 라이선스의 법적 의미를 훨씬 명확히 파악할 수 있습니다. 특히 Apache-2.0처럼 명시적 특허 허여 조항이 있는 라이선스가 왜 기업 친화적인지 이해하는 데 중요한 배경 지식입니다. 구성원이 회사 저작물을 무단으로 오픈소스에 기여하면 저작권 침해 이슈가 발생하므로 반드시 승인 절차를 따라야 합니다.

오픈소스 라이선스는 '공짜 소프트웨어'가 아닙니다. 금전적 대가 대신 고지, 소스코드 공개 등의 의무를 이행해야 합니다. 라이선스 종류마다 요구하는 의무가 다르므로 각각의 특성을 파악하는 것이 중요합니다. 라이선스가 명시되지 않은 코드는 저작권자가 모든 권리를 보유하는 독점 상태이므로 사용 자체가 불가능합니다.

의무사항의 핵심은 '얼마나 많은 코드를 공개해야 하는가'입니다. Permissive 라이선스는 고지문 하나로 해결되지만, GPL은 결합된 자사 코드까지 공개해야 하므로 설계 단계부터 주의가 필요합니다. 의무 강도 스펙트럼을 기억하면 라이선스 선택과 사용 판단에 도움이 됩니다.

많은 팀이 사내에서 사용하는 오픈소스에 대해 불필요하게 걱정합니다. 의무는 외부 배포 시에 발생하므로 사내 도구·테스트 환경은 자유롭게 활용할 수 있습니다. 단, SaaS 형태로 외부 사용자에게 서비스하는 경우는 반드시 확인이 필요하며, 특히 AGPL은 네트워크 서비스도 '배포'로 간주합니다. 경계가 모호한 경우에는 항상 법무팀 또는 OSPO에 문의하는 것이 안전합니다.

대규모 프로젝트에서 수백 개 의존성을 수동으로 확인하는 것은 현실적으로 불가능합니다. Syft나 Trivy 같은 자동화 도구를 CI/CD 파이프라인에 통합하여 라이선스 확인을 자동화하는 것을 권장합니다. 2025년 Trivy 공급망 공격 사례처럼 도구 자체의 보안도 주의해야 합니다.

Permissive 라이선스는 기업 입장에서 가장 다루기 쉬운 유형입니다. 제품의 About 페이지나 별도 고지 파일에 저작권과 라이선스 내용을 포함하면 의무를 충족할 수 있습니다. Apache-2.0은 특허 관련 분쟁을 예방하는 조항이 포함되어 있어 특히 기업 환경에서 권장됩니다.

LGPL 라이브러리를 Static Link로 포함하면 자사 코드도 공개해야 하지만, Dynamic Link 방식으로 분리하면 LGPL 라이브러리 부분만 공개하면 됩니다. 임베디드 제품 개발 시에는 GPL-3.0/LGPL-3.0 사용에 특히 주의가 필요합니다. MPL-2.0은 파일 단위 Copyleft라서 수정한 파일만 공개하면 되어 상용 소프트웨어 친화적입니다.

GPL은 설계 단계부터 오픈소스와 자사 코드의 경계를 명확히 해야 합니다. AGPL은 클라우드 시대에 더욱 위험한 라이선스입니다. 바이너리를 배포하지 않더라도 네트워크 서비스 제공만으로 소스코드 공개 의무가 발생하기 때문입니다. AGPL 소프트웨어는 사전에 법무팀 또는 OSPO와 반드시 협의해야 합니다.

MongoDB의 SSPL이나 Elastic의 Elastic-2.0은 소스코드가 공개되어 있어 오픈소스처럼 보이지만, 상업적 SaaS 서비스 제공에 강력한 제한을 가합니다. AI 모델 라이선스는 군사·감시 등 특정 용도를 명시적으로 금지하는 새로운 유형이므로 AI 서비스 개발 시 반드시 확인해야 합니다. Llama 2는 MAU 7억 명 초과 시 Meta와 별도 협의가 필요하며, 경쟁 LLM 학습에 사용이 금지됩니다.

이 표는 현장에서 빠르게 참조할 수 있는 기준입니다. 경계가 모호한 경우에는 절대 독단적으로 판단하지 말고 반드시 사전 검토를 거쳐야 합니다. 특히 AGPL과 Source Available 라이선스는 사전 지식 없이 사용했다가 큰 피해를 입는 사례가 많습니다.

컴플라이언스는 배포 직전이 아닌 개발 초기 단계부터 관리해야 합니다. 뒤늦게 라이선스 문제를 발견하면 설계 변경까지 이어질 수 있습니다. 모바일 앱은 About 페이지를 활용하는 것이 일반적인 고지 방법입니다.

취약점 점검은 도입 시 1회로 끝나지 않습니다. 오픈소스 사용 중에도 새로운 CVE가 발표되므로 지속적인 모니터링 체계를 갖추는 것이 중요합니다. 패치가 불가능한 경우에는 실제 서비스에 영향이 없는 이유를 소명서로 문서화해야 합니다. Dependabot을 활성화하면 GitHub 저장소에서 자동으로 취약한 의존성을 감지하고 업데이트 PR을 생성해 줍니다.

PART 1에서 배운 내용을 10개 원칙으로 요약했습니다. 모든 내용을 외울 필요는 없지만, 경계가 모호할 때 혼자 판단하지 말고 반드시 전문가에게 문의하는 습관이 가장 중요합니다. 라이선스 정책은 프로젝트마다 다를 수 있으므로 조직의 정책 문서를 항상 최신 상태로 유지하는 것도 중요합니다.

이 파트에서는 외부 오픈소스 프로젝트에 기여하는 방법과 기업 내 승인 절차, 좋은 기여자가 되기 위한 원칙을 다룹니다.

많은 기업이 기여는 '좋은 일'이라고 생각하지만 실제로는 비즈니스 관점에서 매우 합리적인 투자입니다. 패치를 기여하지 않으면 새 버전이 나올 때마다 같은 작업을 반복해야 하고, 이 비용은 시간이 지날수록 기하급수적으로 늘어납니다. 기여는 의무가 아닌 기업의 지속가능한 오픈소스 활용을 위한 전략입니다.

오픈소스 커뮤니티는 초보자의 실수에 비교적 관대하여 안전하게 실력을 키울 수 있는 공간입니다. 기여 이력은 GitHub에 영구적으로 남아 이력서보다 강력한 포트폴리오가 됩니다. 첫 기여를 망설이고 있다면, 오타 수정이나 문서 번역처럼 작은 것부터 시작하는 것을 권장합니다.

개발자가 아니어도 기여할 수 있습니다. 번역, 문서 개선, 버그 리포트만으로도 프로젝트에 큰 도움이 됩니다. 특히 첫 기여라면 간단한 오류 수정이나 문서 번역으로 시작하는 것이 좋습니다. 코드 기여보다 문서와 테스트 기여가 더 환영받는 프로젝트도 많습니다.

역할 구조를 이해하면 기여 시 누구에게 어떤 방식으로 접근해야 할지 알 수 있습니다. 처음에는 기여자로 시작해 커밋 이력이 쌓이면 커미터, 메인테이너로 성장하는 경로를 밟습니다. 사용자 역할도 프로젝트 성공에 필수적이며, 좋은 버그 리포트 하나가 많은 사람에게 도움이 됩니다.

CONTRIBUTING 파일은 프로젝트마다 요구사항이 다르므로 반드시 먼저 읽어야 합니다. 코딩 스타일, 커밋 메시지 형식, 테스트 요구사항 등을 미리 파악해야 리뷰 사이클을 줄일 수 있습니다. CODE OF CONDUCT가 없는 프로젝트는 커뮤니티 문화가 불건전할 가능성이 있으므로 기여 전 주의가 필요합니다.

기여할 프로젝트 선택은 기여 결과에 큰 영향을 미칩니다. 관리되지 않는 프로젝트에 공들인 기여를 보내도 아무 응답을 못 받을 수 있습니다. 체크리스트를 통해 사전에 프로젝트의 건강도를 확인하면 시간과 노력을 효율적으로 투자할 수 있습니다.

새 프로젝트에 참여할 때는 항상 관찰 기간을 갖는 것이 좋습니다. 커뮤니티 문화를 이해한 후 기여하면 수락 가능성이 훨씬 높아집니다. 아이디어 단계에서 커뮤니티와 먼저 논의하면 방향이 맞지 않는 기여를 사전에 방지할 수 있습니다. 작고 빠른 기여 여러 개가 크고 완벽한 기여 하나보다 커뮤니티에서 더 환영받는 경우가 많습니다.

기여 Rule은 기업의 지식재산을 보호하기 위한 최소한의 안전장치입니다. 특히 CLA 서명 시 저작권 양도 조항이 있는지 꼭 확인해야 합니다. 한 번 OSPO 승인을 받은 프로젝트는 이후 동일 프로젝트에 대한 기여는 개인 재량으로 진행할 수 있습니다.

Linux Kernel, Git 등 많은 프로젝트가 DCO를 채택하고 있습니다. CLA는 프로젝트의 라이선스 변경 유연성을 높이지만, 기업 구성원이 서명하기 전에 반드시 저작권 양도 조항 여부를 확인해야 합니다. CLA Assistant 같은 도구를 활용하면 GitHub PR 단계에서 자동으로 CLA 서명을 관리할 수 있습니다.

절차가 복잡해 보이지만, 한 번 OSPO 승인을 받은 프로젝트는 이후 같은 프로젝트에 대한 기여는 간소화됩니다. 10라인 이하의 간단한 코드 수정이나 Stack Overflow 답변은 별도 승인 없이 기여 가능합니다. 기여 전 프로젝트의 CONTRIBUTING 파일을 반드시 읽어 프로젝트별 요구사항을 확인해야 합니다.

Pull Request는 작업이 완전히 끝나지 않아도 WIP로 일찍 오픈하여 방향이 맞는지 사전에 확인하는 것이 좋습니다. 거절을 두려워하지 말고, 거절 이유를 분석해 다음 기여의 품질을 높이는 기회로 활용하세요. 이전에 같은 이슈가 이미 논의된 경우가 많으므로 이슈 검색을 먼저 하는 것이 중요합니다.

오픈소스 커뮤니티는 전 세계 다양한 문화권 사람들이 모입니다. 상대방의 글은 항상 좋은 의도라고 가정하고 품위 있게 소통하는 것이 장기적인 관계 형성에 중요합니다. 공개 채널에서의 소통은 같은 문제를 겪는 다른 사람들에게도 도움이 됩니다. 메인테이너들은 매우 바쁘므로 간결하고 명확한 요청이 빠른 응답을 받는 데 도움이 됩니다.

PART 2에서 배운 핵심은 기여가 기술적 행위인 동시에 사회적 행위라는 점입니다. 좋은 코드를 작성하는 것만큼이나 커뮤니티와 잘 소통하는 것이 기여 성공의 핵심입니다. 한 번의 기여로 끝내지 말고, 꾸준히 기여하면서 신뢰를 쌓아가는 것이 중요합니다.

이 파트에서는 기업 내부 소프트웨어를 오픈소스로 공개하는 방법과 절차, 공개 후 커뮤니티 운영 방법을 다룹니다.

존 내쉬의 협력 게임 이론처럼, 오픈소스는 모든 참가자가 협력함으로써 투자 이상의 수익을 창출하는 구조입니다. Google이 Angular를 오픈소스로 공개한 것처럼, 내부 도구를 공개하면 외부 생태계가 만들어 주는 가치가 훨씬 더 클 수 있습니다. 기업 명성 향상으로 우수한 개발자가 '이 도구를 만든 회사에서 일하고 싶다'는 동기로 지원하게 됩니다.

매력없는 코드를 반복해서 공개하면 나중에 좋은 코드를 공개해도 개발자들이 관심을 갖지 않습니다. 공개는 시작이 아닌 장기적인 커밋이므로, 충분한 준비 없이 공개하는 것은 오히려 역효과입니다. "공개하지 않는 것이 낫다"는 결론도 충분히 유효한 의사결정입니다.

공개 Rule은 기업의 지식재산을 보호하는 동시에 오픈소스 커뮤니티의 신뢰를 유지하기 위한 기준입니다. 완벽한 코드가 아니어도 공개할 수 있지만, 최소한 제품에 실제로 사용하는 수준의 품질은 갖춰야 합니다. git history에 민감한 정보가 포함되어 있는지도 반드시 확인해야 합니다.

11단계의 절차처럼 보이지만 핵심은 '코드 정리·라이선스 결정·문서화·커뮤니티 운영' 4가지입니다. 특히 공개 후 커뮤니티 관리가 지속되지 않으면 프로젝트는 금방 사라지게 됩니다. OSPO의 지원을 적극 활용하면 절차를 훨씬 효율적으로 진행할 수 있습니다.

Apache-2.0은 특허 허여 조항 덕분에 기여자와 사용자 모두를 특허 분쟁에서 보호합니다. MIT는 더 간단하지만 특허 관련 조항이 없어 기업 소프트웨어에는 Apache-2.0이 더 안전한 선택입니다. 커뮤니티 표준이 있는 경우에는 그 표준을 따르는 것이 외부 기여자 유입에 유리합니다.

공개 전 코드 정리에서 가장 많이 실수하는 부분은 내부 주석에 사내 정보가 남아 있는 경우입니다. git history까지 포함해 민감 정보가 없는지 꼼꼼히 확인해야 하며, git-secrets나 truffleHog 같은 도구를 활용할 수 있습니다. 취약점이 있는 의존성을 포함한 채로 공개하면 커뮤니티 신뢰를 잃게 됩니다.

SPDX Tag 방식은 기계가 자동으로 파싱할 수 있어 라이선스 분석 도구와의 호환성이 높습니다. 새 파일을 생성할 때마다 자동으로 헤더를 추가하는 훅(hook)을 개발 환경에 설정해두면 편리합니다. 저작권 연도는 파일 최초 작성 연도를 사용하며, 수정 연도를 추가하는 것도 권장됩니다.

이름 선택은 단순해 보이지만 나중에 바꾸기 매우 어렵습니다. 특히 상표권 침해는 나중에 법적 분쟁으로 이어질 수 있으므로, 공개 전에 반드시 상표권 검색을 해야 합니다. 도메인과 SNS 계정도 미리 확보하지 않으면 나중에 다른 사람이 선점할 수 있습니다.

문서화는 커뮤니티 진입 장벽을 낮추는 가장 중요한 요소입니다. README가 빈약하면 외부 개발자는 프로젝트를 이해하지 못하고 떠나버립니다. Good First Issue 라벨을 활용하면 초보 기여자의 진입을 도울 수 있습니다.

오픈소스 공개 후 가장 많이 실패하는 이유는 커뮤니티 관리 리소스 부족입니다. PR이 몇 달째 리뷰 없이 방치되면 기여자들이 떠나고 프로젝트는 죽어버립니다. 공개 직후 6개월이 커뮤니티 형성의 황금 기간이므로 이 시기에 집중적으로 투자하는 것이 중요합니다.

오픈소스 공개는 준비 없이 서두르지 말고, 리소스와 의지가 충분할 때 공개하는 것이 커뮤니티와 기업 모두에 좋은 결과를 가져옵니다. 4가지 요소 중 하나라도 부족하면 공개를 미루거나, 부족한 부분을 먼저 해결하는 것이 낫습니다.

이 파트에서는 소프트웨어 공급망 공격의 개념과 사례, SBOM의 정의와 활용, 공급망 보안 규제 동향을 다룹니다.

공급망 공격은 직접 공격이 아닌 우회 공격입니다. 개발자가 매일 사용하는 라이브러리나 빌드 도구를 오염시키는 방식으로, 보안이 철저한 기업도 방어하기 어렵습니다. 이 때문에 사용하는 모든 소프트웨어 구성요소를 파악하고 관리하는 것이 필수입니다.

Log4Shell 사태는 SBOM의 중요성을 전 세계에 알린 결정적 사건입니다. SBOM이 있었다면 영향받는 시스템을 즉시 파악할 수 있었지만, 대부분의 기업이 어디에 Log4j가 쓰이는지조차 몰라 수개월간 혼란이 지속됐습니다. 2025년 Trivy 공격은 CI/CD에서 사용하는 도구 자체도 공급망 공격의 대상이 됨을 보여주었습니다.

소프트웨어 의존성 그래프는 점점 복잡해지고 있습니다. 내가 직접 쓰는 라이브러리만이 아니라, 그 라이브러리가 의존하는 라이브러리까지 파악해야 합니다. SBOM은 이 복잡한 의존성을 투명하게 문서화하는 도구입니다. 3대 관리 중 하나라도 소홀히 하면 공급망 보안의 약한 고리가 됩니다.

SolarWinds 사태 이후 미국은 국가 안보 차원에서 공급망 보안을 강제화하기 시작했습니다. EU도 CRA를 통해 디지털 제품의 전체 생명주기 보안을 법제화했습니다. 현재 권고 수준인 한국도 법제화 방향으로 움직이고 있으므로 선제적 대응이 필요합니다.

이 세 가지 원칙은 공급망의 투명성을 확보하고 알려진 취약점으로부터 고객을 보호하기 위한 최소한의 기준입니다. 패치가 불가능한 취약점은 왜 실제 서비스에 영향이 없는지 소명서를 통해 증명해야 합니다. 공급사 입장에서는 계약 전부터 SBOM 생성 체계를 갖추는 것이 중요합니다.

SBOM을 식재료 목록에 비유하면 이해하기 쉽습니다. 음식에 어떤 재료가 들어갔는지 모르면 알레르기 대응도 안전 점검도 할 수 없습니다. 소프트웨어도 마찬가지로 구성요소를 모르면 취약점 발생 시 즉각 대응이 불가능합니다. Log4Shell 사태가 SBOM의 필요성을 전 세계에 각인시킨 사건이었습니다.

전이적 의존성이 중요한 이유는 Log4Shell처럼 개발자가 직접 사용하지 않은 라이브러리에서 취약점이 발생하는 경우가 많기 때문입니다. 직접 의존성만 포함된 SBOM은 절반의 정보만 담고 있어 실질적인 보안 분석이 어렵습니다. npm install, mvn package 등 빌드 명령어 실행 후에 SBOM을 생성해야 전이적 의존성이 정확히 포함됩니다.

SBOM이 없었다면 Log4Shell 사태 때 각 팀이 모든 서버를 수동으로 전수 조사해야 했을 것입니다. SBOM이 있으면 취약한 버전의 Log4j가 포함된 서비스 목록을 즉시 뽑아내어 우선순위를 정해 대응할 수 있습니다. SBOM은 보안뿐만 아니라 라이선스 관리, 기술 부채 파악, 규제 준수 등 다양한 목적으로 활용됩니다.

두 표준은 상호 변환 도구가 제공되므로 하나를 선택해도 필요 시 다른 형식으로 변환할 수 있습니다. 내부 DevSecOps 파이프라인에는 CycloneDX가 보안 도구와의 통합이 더 용이합니다. 라이선스 감사가 주목적이라면 SPDX가 더 상세한 파일 레벨 정보를 제공합니다.

도구마다 전이적 의존성 지원 방식이 다릅니다. Syft로 Docker 이미지를 스캔하면 OS 패키지와 앱 라이브러리를 모두 포함한 가장 완전한 SBOM을 생성할 수 있습니다. 소스코드 분석은 빌드 전 상태에서는 전이적 의존성이 누락되므로 패키지 설치 후 실행해야 합니다. SKT SBOM Scanner는 Docker 기반으로 별도 언어 설치 없이 사용 가능한 편의 도구입니다.

가장 흔한 반려 사유는 전이적 의존성 누락과 PURL 미기재입니다. 제출 전 온라인 CycloneDX Validator로 형식 검증을 먼저 수행하면 반려를 방지할 수 있습니다. 처음 제출하는 경우 담당자에게 사전 문의하면 시행착오를 줄일 수 있습니다.

오픈소스는 현대 소프트웨어 개발의 핵심 인프라입니다. 올바르게 사용하고, 기여하고, 공개하며, 공급망을 안전하게 관리하는 것이 기업과 개발자 모두의 지속가능한 성장을 이끕니다. 모르는 것이 있다면 혼자 판단하지 말고, 항상 법무팀 또는 OSPO에 먼저 문의하는 습관을 갖추세요.

이 자료들은 교육 내용을 심화 학습하거나 실무에서 기준 문서로 활용할 수 있습니다. OpenChain은 기업 오픈소스 컴플라이언스 체계를 인증받는 국제 표준으로, ISO 인증을 준비하는 기업에게 특히 중요합니다.

이 표는 현장에서 빠르게 참조할 수 있는 요약본입니다. 실제 업무에서는 경계가 모호한 사례가 많으므로, 이 표는 최초 판단 기준으로만 활용하고 모호한 경우에는 반드시 전문가에게 문의하세요.

세 가지 활동(기여·공개·SBOM)의 핵심 공통점은 '혼자 결정하지 않는다'는 것입니다. 기업의 지식재산과 법적 리스크가 걸린 문제이므로, 내부 승인 체계와 OSPO 지원을 적극 활용하세요. 오픈소스 활동은 올바른 프로세스를 따를 때 기업과 개발자 모두에게 최대의 가치를 만들어냅니다.