들어가며
안녕하세요. Open Source Program Office TF입니다. Linux 재단에서는 오픈소스 관리의 표준 규격을 만드는 OpenChain 프로젝트를 운영하고 있습니다. 저희는 약 2년 동안 OpenChain 프로젝트에서 정한 규격을 LINE에 적용하는 대형 프로젝트를 진행해 왔는데요. 그 결과 오픈소스 관리의 국제 표준인 ISO/IEC 5230 준수 인증을 받았습니다.
이번 글에서는 먼저 OpenChain 프로젝트가 무엇인지 소개하고, OpenChain 규격을 LINE에 적용하기 위해 어떤 노력을 해왔는지 말씀드리겠습니다. 또한 OpenChain 규격을 적용하는 것이 회사와 개발자 관점에서 어떤 의의가 있는지도 살펴보려고 합니다. LINE의 경험을 공유하는 이 글이 개발자 분들께는 오픈소스 관리의 중요성을 환기하는 계기가, 오픈소스 관리 업무를 하고 계신 분들께는 업무에 참고할 수 있는 자료가 될 수 있다면 좋겠습니다.
OpenChain 프로젝트란
기업에서 소프트웨어를 개발할 때 오로지 기업 스스로의 힘으로만 오롯이 개발하는 경우는 드뭅니다. 오픈소스를 활용하기도 하고, 외주 용역을 활용하거나 상용 소프트웨어를 구입하기도 합니다. 이때 각 경우 역시 독자적이지 않은 경우가 많아서 하나의 제품을 개발할 때는 여러 경로로 여러 코드가 유입됩니다. 이는 개발을 마치고 제품을 배포할 때에도 마찬가지입니다. 고객에게 직접 소프트웨어를 납품하는 경우보다는 다른 곳을 경유해서, 그것도 아주 복잡한 경로를 경유해서 제품을 전달하는 경우가 많습니다. 이렇게 소프트웨어를 개발하고 납품하는 과정 전체를 '소프트웨어 공급망'이라고 일컫습니다.
OpenChain 프로젝트는 '오픈소스 관리의 표준을 정의해 복잡한 소프트웨어 공급망 속에서 기업들이 효과적으로 오픈소스를 관리하도록 만들자'는 목표를 가지고 있습니다.
그럼 먼저 OpenChain 프로젝트의 규격을 소개하고, 이를 적용하면 기업과 각 구성원이 어떤 효과를 얻을 수 있는지 살펴보겠습니다.
규격 소개
OpenChain 프로젝트는 오픈소스 컴플라이언스를 위한 핵심 요구 사항을 정의하고 이를 준수하기 위한 가이드라인을 제공하고 있습니다. OpenChain 규격은 기업의 규모나 업종에 상관 없이 모든 기업에 적용할 수 있도록 설계됐고, 현재 3.0 버전까지 배포됐는데요. LINE에서는 프로젝트 진행 당시 가장 최신 버전이었던 2.1 버전을 기준으로 규격을 적용했습니다.
2.1 버전의 규격에서는 기업들이 반드시 수행해야 할 6가지 핵심 요구 사항을 다음과 같이 정의하고 있습니다.
- 오픈소스 관리 프로그램 설립
- 정책과 정책의 적용 범위, 참여자의 책임과 역할을 명확히 정의할 것
- 본 정책과 정책의 목표 및 준수하지 않았을 때의 영향 등을 모든 참여자가 인지할 수 있도록 게시할 것
- 라이선스 의무를 검토하고 식별하는 등의 의사 결정 프로그램을 구성할 것
- 관련 업무 정의 및 지원
- 외부에서 오픈소스와 관련해 문의했을 때 효과적으로 대응할 수 있는 프로세스를 구성할 것
- 오픈소스 프로그램이 원활하게 작동할 수 있도록 충분한 리소스를 제공할 것
- 법률 자문 등 이슈 대응에 필요한 프로세스를 구축할 것
- 오픈소스 콘텐츠 리뷰 및 승인
- 제공된 소프트웨어를 구성하는 각 오픈소스 구성 요소와 식별된 라이선스를 포함하는 BOM(Bill of Material)을 생성하고 관리하기 위한 프로세스를 구축할 것
- 오픈소스 책임자는 일반적인 오픈소스 사용 사례를 관리하고 주요 라이선스의 요구 사항과 주의 사항을 정리해 회사 내에 공유할 것
- 컴플라이언스 산출물 생성 및 전달
- 식별된 오픈소스 라이선스에서 요구하는 의무 사항을 준수해 컴플라이언스 산출물(오픈소스 고지문, 공개할 소스 코드 패키지)을 생성, 보관 및 전달할 것
- 오픈소스 커뮤니티 참여에 대한 이해
- 오픈소스 프로젝트에 기여하는 정책과 프로세스를 문서화할 것
- 규격 요구 사항 준수
- OpenChain 규격에서 요구하는 모든 요구 사항을 충족하고, 기업에 OpenChain을 준수하는 프로그램이 있다고 선언할 것
오픈소스 거버넌스를 처음 시작하는 기업도 OpenChain 규격의 요구 사항을 하나씩 따라가다 보면 수준 높은 관리 프로세스를 구축할 수 있습니다.
LINE에서 특별히 더 신경 쓴 부분
위 규격을 적용할 때 LINE이라는 조직의 특성에 맞게 특별히 더 신경 쓴 부분이 있습니다. 하나씩 살펴보겠습니다.
OpenChain 규격과 기존 LINE 정책 비교 파악
LINE은 OpenChain 프로그램을 시작하는 단계에서 이미 그동안의 경험과 외부 커뮤니티를 통해 학습한 내용을 바탕으로 오픈소스 정책을 수립해 운용하고 있는 상황이었습니다. 이에 LINE에서는 OpenChain 프로그램을 시작하기에 앞서 해당 프로젝트에서 요구하는 규격이 무엇인지를 파악하고 마일스톤을 정리하는 작업을 진행했으며, 마일스톤을 정리하면서 구체적으로 다음 항목들을 고민하고 정리했습니다.
- 규격에 빗대어 봤을 때 이미 잘하고 있던 것은 무엇인지
- 규격에 빗대어 봤을 때 미흡한 부분은 무엇인지
- 어떤 것들을 새롭게 마련해야 하는지
- 타 부서와 협의해야 할 부분이 있는지
사내 전파 방법 확립
OpenChain 규격에서는 정책을 잘 만드는 것뿐 아니라 잘 만든 정책과 프로세스를 임직원이 쉽게 접근할 수 있는 곳에 배치하고 교육을 통해 충분히 설명했는지 또한 중요한 요소로 다룹니다. 아무리 정교하게 만든 정책이더라도 개발자가 인지하지 못하면 효과를 제대로 발휘할 수 없기 때문입니다. 이 부분은 평소에 오픈소스 관리 업무를 진행하면서 항상 고민하고 노력하던 부분이었고, 개편한 정책을 효율적으로 알릴 방법을 고민하면서 다시 한번 생각해 봤습니다.
저희는 개발자가 오픈소스 정책의 존재를 언제든지 잘 인지할 수 있도록 공통 개발 거버넌스 규정에 추가했습니다. 이에 따라 배포 과정에서만 확인하던 오픈소스 정책이 개발 과정에서 필수로 확인해야 하는 절차가 됐는데요. 이런 변화가 기존 개발 작업에 큰 영향을 미치지 않도록 자주 등장하는 대표적인 오픈소스 라이선스를 분류해 설명한 문서를 개발자가 스스로 쉽고 빠르게 판단할 수 있게 제공하고 있습니다. 물론 여러 사내 채널로 오픈소스 정책 개편 소식을 지속적으로 알리며 개편 내용을 전달하는 작업도 꾸준히 진행하고 있습니다.
OSRB(Open Source Review Board) 구성
OpenChain 프로그램을 진행하면서 가장 어려웠던 과제 중 하나가 OSRB를 구성하는 것이었습니다. 오픈소스 관리 업무의 기본이 자체 개발한 프로그램의 오픈소스 컴플라이언스인데요. LINE에서는 Open Source Program Office에서 그 외에도 오픈소스 활동을 더욱 활성화하기 위한 오픈소스 공개, 기여, 이벤트 등의 다양한 업무를 함께 담당하고 있었기에 유관 부서들과의 협업이 꼭 필요했습니다. 이에 각 팀의 본래 업무와 그동안의 협력 이력을 참고해 다음과 같이 OSRB를 구성했습니다.
- Open Source Program Office: 오픈소스 관련 업무 일체를 전담하며 다른 OSRB와 협력 시 중추 역할
- 법무 팀: 오픈소스 라이선스 혹은 관련 계약의 법무 검토 지원
- 특허 팀: 특허 라이선스 관련 검토 지원
- 보안 팀: 오픈소스 보안 취약점 관리를 위한 업무 협조
- CTO Office: 전사 개발 조직에서 오픈소스 관련 프로세스를 충실히 이행할 수 있도록 업무 협조
- Developer Relations 팀: 사내/외를 대상으로 하는 오픈소스 관련 기술 컨텐츠 제작을 위한 업무 협조
이미 기존에도 각 부서들과 협업하고 있었지만 이를 정책 문서에 명문화하고 실무 담당자를 지정하는 것은 또 다른 부담이었을 텐데요. 다행히 모든 팀이 프로젝트 취지에 공감하며 흔쾌히 담당자를 지정하고 필요한 책임과 역량을 정의해 주셨습니다.
참고로 OpenChain 규격 예시에는 OSRB에 CTO Office와 Developer Realations 팀이 포함돼 있지 않은데요. LINE에서는 이슈가 발생했을 때 다양한 개발 조직과 빠르게 커뮤니케이션해서 신속히 상황을 파악하고 대응하기 위해 CTO Office를 포함했고, 오픈소스를 주제로 다양한 컨텐츠나 이벤트를 기획할 때 오픈소스 라이선스 이슈를 확인하거나 오픈소스의 매력을 더욱 돋보이게 만들 수 있는 저희만의 시각을 더해 효과를 극대화하고자 Developer Realations 팀을 포함했습니다.
교육 정책 수립
오픈소스 정책 교육을 실시하고 평가 결과를 보관하는 것 또한 OpenChain의 규격입니다. 교육은 사내 개발자 대상 교육과 OSRB 구성원 대상 교육으로 나눠 진행했습니다.
개발자 교육은 LINE 그룹의 모든 개발자를 대상으로 진행했습니다. 처음으로 전 개발자를 대상으로 진행하는 오픈소스 필수 교육이었는데요. 많은 사람들이 시간을 내서 이수하는 만큼 효과적으로 내용을 전달하기 위해 어떻게 구성할지, 어떤 부분을 강조하거나 덜어낼지 많이 고민해서 교육 자료에는 개발자가 반드시 알아둬야 할 내용만 추려 넣었습니다. 이 교육의 가장 큰 목적은 전체 내용을 숙지하는 것이 아니라 오픈소스와 관련해 궁금한 점이 있을 때 어떤 문서를 보고 어떤 프로세스를 따라야 할지, 어디로 문의하면 되는지 기억할 수 있게 만드는 것이었기에 여기에 집중해 교육을 구성했습니다.
평가 또한 걱정이 많았습니다. 누구도 시험을 좋아하지 않기 때문인데요. 개발자들이 자주 묻는 질문을 퀴즈로 만들어 그 내용을 한 번 더 읽어보도록 유도했고, 정책 중에서 특히 강조하고 싶은 내용은 퀴즈 난이도를 조금 더 높게 설정해 평가했습니다.
OpenChain 표준 적용의 의의
이와 같이 OpenChain 표준을 적용한 것이 어떤 의의가 있는지 회사 입장과 개발자 입장에서 각각 살펴보겠습니다.
회사 입장에서의 OpenChain 표준 적용 의의
국제 수준에서 오픈소스 거버넌스 체계의 우수성 검증
기업 관점에서 오픈소스 컴플라이언스 영역은 구멍이 발생하면 대형 이슈로 발발하지만 평소에는 오픈소스를 잘 관리하고 있는지, 컴플라이언스 측면에서 믿어도 되는지 확인하기 쉽지 않은 영역입니다. 이때 OpenChain 인증을 획득하면 오픈소스 라이선스를 잘 준수하고 있고, 법/기술/조직 측면에서 끊임없이 노력하며 오픈소스 컴플라이언스 체계를 빈틈없이 잘 구축해 놓았다는 것을 대내외로 증명할 수 있습니다. 이를 통해 제 3자와의 협력 및 파트너십을 구축할 때 회사의 오픈소스 관리 능력과 컴플라이언스 측면을 강조해 신뢰를 얻을 수 있습니다.
내부 프로세스의 일관성 유지
OpenChain 규격에서는 컴플라이언스 결과물뿐 아니라 결과물을 만드는 과정에도 일관된 기준이 있어야 한다고 강조합니다. 특정 항목을 판단하는 기준이 명확해야 하며, 판단 과정 또한 모두 프로세스로 정의돼 있어야 한다는 의미인데요. 예를 들면 다음과 같습니다.
- 기존 가이드: 오픈소스 라이선스 고지문을 작성하고 개발 팀에 전달합니다.
- OpenChain 규격을 적용해 개선한 가이드: 오픈소스 라이선스 고지문은 어떤 포맷으로 작성하며, 작성 과정은 다음 프로세스를 따릅니다.
OpenChain 규격에서는 이와 같이 실무진들이 자칫 같은 상황에서 다른 선택을 하지 않도록 실무 과정 하나 하나를 모두 문서로 정의해 놓습니다. 이를 통해 회사는 오픈소스 관리나 라이선스 추적, 문서화, 교육 등의 내부 프로세스를 누가 담당하든 일관성 있게 운영할 수 있으며, 사람의 실수 때문에 리스크가 발생하는 확률을 현저히 낮출 수 있습니다.
신속하고 효율적인 이슈 대응
OpenChain 규격에 따라 OSRB라는 이슈 대응 협의체를 구성해서 각 구성원이 어떤 책임을 갖고 어떤 프로세스에 따라 협력할지 정의해 놓으면, 리스크 발생 시 빠르고 효율적으로 대응할 수 있는 체계가 갖춰집니다.
개발자 입장에서의 OpenChain 표준 적용 의의
개발에 더욱 집중할 수 있는 환경 조성
OpenChain 규격에 따라 개발자는 오픈소스 교육을 이수해 오픈소스에 대한 기본 지식을 익힐 수 있습니다. 교육을 받은 개발자는 기본적인 사례에 대해서는 회사에서 어떤 판단을 할지 짐작하거나 스스로 문서를 찾아보고 확인할 수 있으며, 그렇지 못한 경우에도 Open Source Program Office를 통해 오픈소스 컴플라이언스관련 도움을 받을 수 있다는 것을 알게 됩니다. 따라서 OpenChain 규격을 따르는 회사 방침을 믿고 오픈소스 관련 걱정을 내려 놓고 개발에 더욱 집중할 수 있습니다.
오픈소스에 관한 기본 지식과 역량 습득
이번에 OpenChain 프로젝트 인증 과정을 진행하면서 개발자 분들이 직/간접적으로 참여하며 회사의 오픈소스 정책과 프로세스를 익히고 이를 통해 개발 과정에서부터 오픈소스 라이선스를 인지하고 개발에 임하는 경우가 많아지는 것을 알 수 있었습니다. 개발 완료 후 오픈소스 컴플라이언스 위반 케이스가 발견되면 이를 수정하는 비용이 굉장히 클 수 있는데요. 오픈소스에 대한 기본 지식을 갖추고 개발에 임하면 사전에 오픈소스 컴플라이언스 리스크를 피할 수 있어서 더욱 효율적으로 개발을 진행하게 됩니다.
마치며
요약하면, LINE은 OpenChain 프로젝트를 통해 오픈소스 거버넌스 체계를 더욱 탄탄히 다졌고, 이를 통해 내/외부의 신뢰를 얻을 수 있게 됐습니다. 또한 오픈소스 이슈 발생 확률을 현저히 낮추고, 이슈가 발생해도 보다 효율적으로 철저히 대응할 수 있게 됐습니다.
Open Source Program Office에서는 LINE이 이번 OpenChain 프로젝트를 통해 오픈소스 컴플라이언스를 철저히 수행하면서 개발자 생태계에도 잘 녹아드는 기업으로 인식되고자 했습니다. OpenChain 규격은 그동안 일부 비정형적이었던 LINE의 오픈소스 거버넌스에 지침이 됐고, 내부 체계를 더욱 철저하게 보완하는 계기가 됐습니다.
처음 OpenChain 인증을 받기 위해 규격을 검토했을 때에는 생각보다 요구 사항이 많아서 막막하게 느껴지기도 했는데요. 소수의 인원이 기존 업무와 병행하면서 진행해야 했기에 거의 2년이라는 시간이 소요됐지만, 인증을 받는 과정에서 어디에 내놓아도 자랑스러울 만큼 오픈소스 관련 정책과 프로세스가 많이 개선된 것 같아 굉장히 뿌듯하고, 큰 보람을 느낍니다.