오픈소스 공개하기

• 1: SK텔레콤 오픈소스 공개 Rule
• 2: SK텔레콤 오픈소스 공개 절차
• 2.1: 오픈소스 프로젝트 이름 결정
• 2.2: 파일 내 저작권 및 라이선스 표시
• 2.3: 코드 정화 체크리스트
• 2.4: 라이선스 선택
• 3: 오픈소스 공개 배경 지식
• 3.1: 오픈소스 공개의 혜택

1 - SK텔레콤 오픈소스 공개 Rule

SK텔레콤은 내부 소프트웨어를 오픈소스로 공개하는 것을 장려합니다. 다만 지식재산을 보호하고 의도치 않은 저작권 침해를 막기 위해 지켜야 할 규칙이 있습니다.

승인 받기

고용 기간에 만든 저작물의 저작권은 고용주가 소유합니다. 구성원이 임의로 공개하면 저작권 침해 이슈가 생길 수 있으므로, 공개 절차에 따라 리뷰 요청과 승인을 받으세요.

공개할 권리가 있는 코드

작성하지 않은 코드는 공개할 권리가 없습니다. 모든 코드의 출처를 확인하고, 법적 문제 소지가 있는 코드는 제거하세요.

지식 재산 노출 주의

민감한 정보나 특허 등 기업의 지식재산이 노출되는 코드와 문서는 공개하지 마세요.

코드 품질

가독성과 성숙도가 갖춰져야 합니다. 수준 이하의 코드는 커뮤니티의 신뢰를 잃게 합니다.

유용한 코드

실제 제품이나 서비스에 쓰는 코드를 공개하세요. 커뮤니티에서 이미 해결한 문제를 다루는 코드라면, 새로 공개하기보다 기존 프로젝트에 기여하는 편이 낫습니다.

리소스 확보

공개와 운영에는 초기 개발자, 외부 기여를 리뷰할 개발자, 법무와 마케팅 지원, 인프라 예산이 필요합니다. 공개 전에 확보 계획을 세우세요.

회사 이메일 사용

개인 이메일이 아니라 SK텔레콤 이메일로 커뮤니티와 소통하세요.

2 - SK텔레콤 오픈소스 공개 절차

공개 절차는 네 묶음으로 진행합니다. 먼저 승인을 받고(A), 코드를 준비하고(B), 프로젝트를 갖춘 뒤(C), 공개하고 운영합니다(D).

A. 공개 승인

소속 조직 내부 승인

소프트웨어를 공개하려면 소속 조직의 담당 임원이나 리더에게 승인을 받습니다.

검토 요청

내부 승인을 받은 후 OSRB(opensource@sktelecom.com)에 검토를 요청합니다. 아래 체크리스트를 모두 채워 요청하세요.

• 현재 소스 코드 Repository 링크
• 공개 예정 저장소 링크
• 적용할 오픈소스 라이선스
• 공개로 기대하는 비즈니스 가치
• SK텔레콤 구성원이 작성하지 않은 코드 설명
• 개발팀 담당 임원 승인 여부
• 코드가 쓰인 제품이나 서비스
• 공개 후 지원할 인력 지정 여부
• 공개 준비 완료 여부
• 공개 홍보 방법(블로그, 콘퍼런스 등)
• 관련 특허 여부
• 보안취약점 검토와 보완 여부
• 수출 통제 분류(ECCN) 확인 여부

처리 예상 소요는 검토 범위에 따라 다릅니다.

B. 공개 준비

라이선스 결정

SK텔레콤은 기본적으로 Apache-2.0을 적용합니다. 커뮤니티 관례 라이선스가 있거나 GPL 라이브러리에 종속된 경우 등은 다른 라이선스를 적용할 수 있습니다. 선택 기준은 라이선스 선택을 참고하세요.

3rd party 코드 분리

SK텔레콤이 재배포할 권리가 있는지 확인하고, 외부 라이브러리는 third_party 디렉토리로 분리해 각 디렉토리에 LICENSE 파일을 둡니다.

[Root Directory]
|-- SKT source code
|-- ...
`-- third_party
    |-- [external library A]
    |   |-- LICENSE
    |   `-- ...
    `-- [external library B]
        |-- LICENSE
        `-- ...

저작권과 라이선스 표기

모든 소스 파일에 저작권과 라이선스를 표기합니다. 형식은 REUSE 표준을 따릅니다. 자세한 방법은 저작권 표시를 참고하세요. 프로젝트 루트에는 LICENSE 파일을 포함합니다. Apache-2.0은 공식 사본을, 그 외 라이선스는 SPDX License List에서 받습니다.

코드 정화

공개 전에 주석에 남은 작성자 이름과 이메일, 내부 정보(파일 경로, 호스트, IP), 자격증명 같은 시크릿을 제거합니다. 점검 항목과 자동화 방법은 코드 정화 체크리스트를 따릅니다.

라이선스 점검과 보안 점검 요청

고지나 소스 공개 의무가 있는 라이선스, 재배포 권리가 없는 3rd party 코드, 라이선스 충돌 여부를 점검합니다. 보안취약점이 있는 오픈소스가 포함됐는지도 확인합니다. 점검은 OSRB에 요청합니다.

수출 통제 분류(ECCN) 확인

암호 기능 등 수출 통제 대상 기술이 포함될 수 있으므로, 공개 전에 수출 통제 분류를 확인합니다. 한국 기업은 대외무역법상 전략물자 판정이 1차 기준이며, 미국산 기술이 포함되면 미국 수출관리규정(EAR)의 ECCN도 함께 확인합니다. 분류와 검토가 필요하면 OSRB를 통해 담당 부서의 확인을 받으세요.

C. 프로젝트 셋업

이름 결정

기억하기 쉽고 프로젝트를 알리는 이름을 정합니다. 상표권 충돌 확인을 포함한 기준은 이름 결정을 참고하세요.

저장소와 인프라

GitHub 또는 GitLab Repository를 권장합니다. SK텔레콤 GitHub 조직(https://github.com/sktelecom)에 멤버 등록이 필요하면 OSRB에 요청합니다. 다음을 갖춥니다.

• 이슈 트래커
• 테스트 자동화: Unit Test, Integration Test, End-to-End Test
• CI/CD: 빌드와 배포까지 포함한 지속적 자동화와 모니터링
• 웹사이트: 사용자 가이드와 홍보용. GitHub Pages 활용을 권장합니다
• 커뮤니케이션 채널: 회사 기밀은 공개 채널에서 논의하지 않습니다

거버넌스와 CODE_OF_CONDUCT

참여 인원의 역할을 명확히 구분합니다. 참가자의 행동 규칙을 정의한 CODE_OF_CONDUCT를 둡니다. 차별 금지, 안전한 활동 보장, 위반 시 신고 방법을 포함합니다. 행동강령은 사실상 표준인 Contributor Covenant를 채택하고, 신고 연락처와 집행 절차를 함께 정합니다.

기여자 라이선스 정책(CLA/DCO) 결정

외부 기여를 받을 계획이라면 기여자 라이선스 정책을 정합니다. 기여물의 저작권과 라이선스 권리를 명확히 하기 위해 CLA(Contributor License Agreement)나 DCO(Developer Certificate of Origin) 중 하나를 채택합니다. DCO는 커밋에 Signed-off-by로 출처와 기여 권리를 증명하는 경량 방식이고, CLA는 별도 약정서로 권한을 정리하는 방식입니다. 저작권 양도를 요구하는 CLA는 회사 정책상 제약이 있으므로, 선택과 운영은 기여 Rule의 CLA 설명과 일관되게 정합니다.

취약점 제보 처리(SECURITY.md)

공개 프로젝트는 외부에서 보안취약점 제보를 받습니다. 제보 경로와 대응 절차를 SECURITY.md에 정의합니다.

# Security Policy

## Reporting a Vulnerability
취약점은 공개 이슈로 올리지 말고 <보안 제보 연락처>로 비공개로 알려 주세요.
접수 후 <대응 기준일> 안에 회신합니다.

## Supported Versions
보안 수정을 제공하는 버전 범위를 적습니다.

GitHub 저장소는 비공개 취약점 제보(Private Vulnerability Reporting)를 켜서 제보 창구로 활용할 수 있습니다. 제보 접수와 회신 기준 시간, 조율된 공개(coordinated disclosure)의 원칙, 수정 후 CVE 발번과 보안 권고(advisory) 게시 절차를 함께 정합니다.

문서화

다음 문서를 갖춥니다.

• README: 무엇을 하는 프로젝트인지, 왜 유용한지, 어떻게 시작하는지, 도움을 어디서 받는지
• 개발 가이드: 빌드 방법, 테스트, 코딩 컨벤션, CI/CD, 릴리스
• CONTRIBUTING: 버그 리포트와 기능 제안 방법, 개발 환경 설정, 원하는 기여 유형, 비전과 로드맵, 관리자 연락처

D. 공개와 운영

공개 전 최종 확인

• 모든 코드와 문서가 Repository에 있는지 확인합니다
• 인프라가 실행 중이고 안전하며 확장 가능한지 확인합니다
• 개발자가 커뮤니케이션 채널에 참여할 수 있는지 확인합니다

공개

https://github.com/sktelecom 에 Public으로 공개합니다.

공개는 되돌리기 어렵습니다. 한 번 공개된 코드는 외부에서 복제되거나 보관될 수 있으므로, 공개 전 점검을 모두 마쳤는지 다시 확인하세요.

마케팅과 커뮤니티 활성화

관련 커뮤니티의 메일링 리스트나 포럼에 알리고, 기술 블로그와 소셜 미디어, 콘퍼런스로 홍보합니다. 프로젝트의 성공은 참여 인원과 기여의 양으로 가늠됩니다. 커뮤니티 구축에는 지속적인 노력이 필요합니다.

공개 후 생명주기 운영

공개로 끝이 아닙니다. 다음을 지속합니다.

• 정기 건강도 점검: 이슈와 PR 응답, 릴리스 주기 유지
• 보안과 버그 수정 지속: 제보된 취약점 대응
• 종료와 아카이빙(EOL): 더 이상 유지하지 않을 때는 상태를 명확히 알리고 저장소를 아카이브합니다

2.1 - 오픈소스 프로젝트 이름 결정

기억하기 쉽고 프로젝트를 알리는 이름

기억하기 쉽고, 프로젝트가 무엇을 하는지 알릴 수 있는 이름을 고릅니다. 기존 프로젝트명을 접두사로 활용할 수도 있습니다(예: node-fetch). 다양한 언어권 사용자가 이해하기 쉬운지 고려합니다.

SK텔레콤 브랜드 사용 회피

회사 공식 제품이 아니라면 SK텔레콤 브랜드 사용을 피합니다. “T-” 형태의 이름도 꼭 필요한 경우가 아니면 쓰지 않습니다.

중복 이름 회피

같은 생태계의 기존 프로젝트명과 중복되는지 확인합니다. 도메인과 SNS 계정의 가용성도 미리 살핍니다.

타사 브랜드 미사용

타사 브랜드를 제품명처럼 쓰지 않습니다. 예를 들어 “Java Test Library"보다 “Test Library for Java” 형식이 바람직합니다.

상표권 침해 방지

KIPRIS나 WIPO Global Brand Database에서 상표권 충돌을 확인합니다. 필요하면 IPR팀의 검토를 받습니다.

2.2 - 파일 내 저작권 및 라이선스 표시

저작권은 저작물을 만들 때 자동으로 생깁니다. 다른 사용자가 쓰게 하려면 라이선스를 부여해야 합니다. 대부분의 오픈소스 라이선스가 저작권 표시를 요구하므로, SK텔레콤이 공개하는 모든 소스 파일에 저작권 표시와 라이선스 고지를 포함합니다. 표기는 REUSE 표준을 따릅니다.

저작권 표시

소스 파일 상단 헤더에 다음을 포함합니다.

SPDX-FileCopyrightText: Copyright {연도} SK TELECOM CO., LTD.

• {연도}는 최초 작성 연도를 적습니다.
• 연락처나 웹사이트를 덧붙일 수 있습니다(선택). 이 형식은 기여 Rule의 저작권 표기와 동일합니다.

라이선스 고지

SPDX License List에서 라이선스 Identifier를 확인해 파일 상단에 표시합니다.

SPDX-License-Identifier: Apache-2.0

이 형식은 기여 Rule의 저작권 표기와 동일합니다.

자동화 도구

파일이 많을 때는 도구로 일괄 적용합니다. REUSE 표준의 SPDX 태그(SPDX-FileCopyrightText, SPDX-License-Identifier)를 생성하려면 REUSE 도구의 reuse annotate를 사용합니다.

$ reuse annotate --copyright "SK TELECOM CO., LTD." --license Apache-2.0 [filename]

addlicense는 기본적으로 라이선스 헤더 본문을 넣습니다. SPDX 단문 형식이 필요하면 -s 옵션을 사용합니다.

$ addlicense -s -c "SK TELECOM CO., LTD." -l apache [filename]

Java 파일에 일괄 적용하는 예시입니다.

$ find . -type f -name \*.java -exec addlicense -s -c "SK TELECOM CO., LTD." -l apache {} \;

2.3 - 코드 정화 체크리스트

공개 전에 코드와 커밋 이력에서 민감정보를 제거합니다. 아래 항목을 점검하세요.

점검 목록

• 주석에 남은 작성자 이름과 이메일 제거
• 내부 정보 제거: 파일 경로, 호스트 이름, IP 주소
• 시크릿 제거: 비밀번호, 토큰, API 키, 인증서
• 내부 URL이나 사내 시스템 참조 제거
• 시크릿 스캐닝 도구로 자동 점검 완료
• 커밋 이력에 남은 민감정보 제거 완료

시크릿 스캐닝

수작업만으로는 빠뜨리기 쉽습니다. gitleaks 같은 시크릿 스캐닝 도구로 자동 점검을 수행하고, 가능하면 공개 전 파이프라인에 포함하세요.

$ gitleaks detect --source . --redact

커밋 이력 정화

민감정보가 한 번이라도 커밋됐다면, 현재 파일에서 지워도 이력에는 남습니다. git filter-repo로 이력에서 제거합니다.

$ git filter-repo --invert-paths --path secrets.env

이력 재작성은 모든 커밋 해시를 바꾸므로 기존 클론과 협업 이력에 영향을 줍니다. 공개용으로 새로 만든 저장소에서만 수행하는 것이 안전합니다.

점검에 쓸 검색 예시

특정 키워드가 남아 있는지 빠르게 훑을 때 씁니다.

$ grep -rIn -e "password" -e "token" -e "BEGIN PRIVATE KEY" .

2.4 - 라이선스 선택

기본값은 Apache-2.0

SK텔레콤은 기본적으로 Apache-2.0을 적용합니다. 특허 조항을 포함한 permissive 라이선스로, 기업이 공개하는 프로젝트에 무난합니다.

다른 라이선스를 고려하는 경우

• 해당 생태계에서 주로 쓰는 라이선스가 있는 경우. 커뮤니티 관례를 따르면 채택이 쉬워집니다.
• GPL 등 copyleft 라이브러리에 종속된 경우. 의존성의 의무를 따라야 할 수 있습니다.

permissive와 copyleft의 차이

• permissive(예: Apache-2.0, MIT, BSD)는 고지 의무 정도만 요구하고 파생물의 라이선스를 강제하지 않습니다.
• copyleft(예: GPL, LGPL, MPL)는 파생물이나 결합물에 같은 조건의 공개 의무를 요구할 수 있습니다. 의무의 범위는 라이선스마다 다릅니다.

의존성 호환성 확인

선택한 라이선스가 의존성의 라이선스와 충돌하지 않는지 확인합니다. 예를 들어 강한 copyleft 의존성이 있으면 permissive로 공개하기 어려울 수 있습니다. 라이선스별 의무는 가이드의 [사용하기] 라이선스 의무사항 섹션을 참고하고, 판단이 어려우면 OSRB에 검토를 요청하세요.

참고

• choosealicense.com
• SPDX License List

3 - 오픈소스 공개 배경 지식

이 묶음은 “왜"에 답하는 학습 자료입니다. 실제로 무엇을 해야 하는지를 다루는 행동 페이지(공개 Rule, 공개 절차)와 분리해 두었습니다.

포함 페이지

• 오픈소스 공개의 혜택: 공개가 기업에 주는 이점

3.1 - 오픈소스 공개의 혜택

기업이 소프트웨어를 오픈소스로 공개하는 데에는 다음과 같은 목적이 있습니다.

경제적 이득

오픈소스는 자선 행위가 아닙니다. 기업이 소프트웨어를 공개하거나 기여할 때는 더 높은 투자수익을 기대합니다. 협력은 제로섬 게임이 아니며, 모두가 협력함으로써 투자한 것보다 더 높은 수익을 낼 수 있습니다.

예를 들어 구글은 내부에서 쓰던 Angular를 공개했고, 개발자들이 이를 활용해 많은 확장 도구를 만들었습니다. 구글은 다시 그 생태계의 이득을 누렸습니다.

표준 채택

공개하면 사실상의 표준으로 채택될 가능성이 커집니다. 표준이 되면 외부 기여자가 늘고 생태계가 더 빠르게 진화합니다. GNU와 Linux가 그 예입니다. Linux는 이제 서버와 네트워크 장비, 임베디드 기기에서 사실상의 표준입니다.

생태계 성장

공개하면 다른 사람들이 채택해 자신의 프로그램을 만들고, 그 프로젝트의 성공에 함께 투자합니다. WordPress는 플러그인과 테마 API를 공개해 커뮤니티가 다양한 기능을 제공하는 생태계를 만들었습니다. 구글이 공개한 V8 엔진은 JavaScript 성능을 크게 끌어올려 웹과 Node.js 생태계 전반을 키웠습니다.

우수한 개발자 채용

채용이 주된 목적은 아니지만, 내부에서 널리 쓰이는 소프트웨어를 공개하면 외부 개발자도 그 도구에 익숙해집니다. 기업은 이미 도구를 잘 아는 기여자 중에서 인력을 선택할 수 있고, 교육 부담이 줄어듭니다. 이런 활동으로 커뮤니티에서 명성이 높아지면 인재를 확보하기도 쉬워집니다.