오픈소스 공개하기

• 1: SK텔레콤 오픈소스 공개 Rule
• 2: SK텔레콤 오픈소스 공개 절차
• 2.1: 오픈소스 프로젝트 이름 결정
• 2.2: 파일 내 저작권 및 라이선스 표시
• 2.3: 민감정보 제거 체크리스트
• 2.4: 라이선스 선택
• 3: 오픈소스 공개 배경 지식
• 3.1: 오픈소스 공개의 혜택
• 4: AI 모델 공개하기
• 4.1: AI 모델 공개 전 체크리스트
• 4.2: 모델 카드 작성
• 4.3: AI SBOM과 규제 대응

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 생태계 전반을 키웠습니다.

우수한 개발자 채용

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

4 - AI 모델 공개하기

AI 모델을 공개하는 일은 소스 코드를 공개하는 일과 절차가 대부분 같습니다. 조직 승인을 받고, 공개할 권리를 확인하고, 민감정보를 걸러내고, 공개 후 지원 인력을 정합니다. 이 공통 절차는 공개 절차와 공개 Rule을 그대로 따르시면 됩니다.

이 페이지는 모델이라서 달라지는 부분만 다룹니다.

코드 공개와 무엇이 다른가

가장 자주 걸리는 곳은 학습 데이터셋입니다. 모델 라이선스를 정리했더라도 학습에 쓴 데이터셋의 라이선스가 재배포나 상업적 이용을 제한하는 경우가 있습니다. 둘은 별개로 확인하셔야 합니다.

한 장 요약

1. 소속 조직 내부 승인을 받고 OSRB(사내 오픈소스 검토 조직)에 검토를 요청합니다(공개 절차의 A 단계).
2. 모델과 학습 데이터셋의 라이선스를 각각 확인합니다. 여기서 걸리면 나머지 준비가 무의미해지므로 일찍 확인하시는 편이 좋습니다.
3. 공개 전 체크리스트로 빠진 항목을 점검합니다. 동시에, 모델 카드를 작성합니다. 공개 후 가장 많이 읽히는 문서입니다.
4. 규제 대응을 위해 AI SBOM을 생성하여 문서화 상태를 확인합니다.
5. 저장소를 공개하고 운영합니다(공개 절차의 D 단계).

공개 절차의 D 단계는 소스 코드를 GitHub에 올리는 경우를 기준으로 쓰여 있습니다. 모델은 개인 계정이 아니라 소속 모델 개발 조직의 Hugging Face 계정에 올리고, 나머지 운영 사항은 같습니다. 계정 접근 권한이 필요하면 조직 담당자에게 요청하세요.

공개 전에 스스로 점검하려면

공개 전 체크리스트의 권리와 데이터 항목을 먼저 확인하세요. 비공개 저장소라도 외부 서비스에 올리는 것이라, 공개할 수 없는 데이터가 섞인 채 올리면 되돌리기 어렵습니다.

그다음에는 비공개 상태에서 스스로 점검할 수 있습니다. 모델을 비공개 저장소에 올리고, 본인의 Hugging Face 토큰(HF_TOKEN)으로 SBOM 생성 도구 BomLens를 돌리면 빠진 항목과 채우는 방법이 정리되어 나옵니다. 그 결과로 모델 카드를 미리 보강해 두면, OSRB 검토에 필요한 문서를 갖춰 검토가 수월해집니다. BomLens 실행 명령과 토큰 준비, 결과 읽는 법은 AI SBOM에 있습니다.

관련 문서

• 공개 절차 — 승인부터 운영까지 공통 절차
• 공개 Rule — 공개 전 지켜야 할 기준
• 민감정보 제거 체크리스트 — 코드와 커밋 이력 정리
• AI Model 라이선스 — RAIL, Llama 등 모델 라이선스 해설

문의

AI 모델 공개 관련 문의와 검토 요청은 OSRB(opensource@sktelecom.com)로 연락하세요.

4.1 - AI 모델 공개 전 체크리스트

이 체크리스트와 모델 카드 작성은 순서대로가 아니라 함께 진행하는 것입니다. 모델 카드를 쓰기 시작할 때 이 목록을 한 번 훑어보시면 좋습니다. 공개 직전에야 발견하면 학습을 다시 해야 하는 항목이 섞여 있기 때문입니다.

1. 공개할 권리

가장 먼저 확인할 항목입니다. 여기서 걸리면 나머지 준비가 무의미해집니다.

• 베이스 모델을 파인튜닝했다면, 그 모델의 라이선스가 파생 모델 배포를 허용하는가?
• 베이스 모델 라이선스가 파생 모델에 요구하는 조건을 확인했는가? (이름 표기, 라이선스 승계, 사용 제한 조항의 하위 전달 등)
• 학습에 쓴 데이터셋의 라이선스가 학습 결과물의 배포를 허용하는가?
• 외부에서 구매하거나 계약으로 받은 데이터가 섞여 있다면, 계약상 공개가 가능한가?
• 모델이나 학습 방법에 관련된 특허 출원이 있는가?

2. 라이선스 결정

• 모델 가중치에 적용할 라이선스를 정했는가?
• 베이스 모델이 특정 라이선스를 강제한다면 그것을 따랐는가?
• 용도 제한이 필요하다면 그 근거를 정리했는가? (RAIL 계열 라이선스 등)
• 학습 데이터셋을 함께 공개한다면 데이터셋 라이선스를 별도로 정했는가?
• 모델 카드의 license 항목에 정확한 식별자를 적었는가?

라이선스별 특성은 AI Model 라이선스와 Llama 2 가이드, RAIL 가이드를 참고하세요.

3. 데이터와 민감정보

• 학습 데이터에 개인정보가 포함되어 있는지 확인했는가?
• 포함되어 있다면 개인정보 담당 부서의 확인을 받았는가?
• 학습 데이터에 타인의 저작물이 포함되어 있는지 확인했는가?
• 사내 문서나 고객 데이터가 학습에 쓰이지 않았는가?
• 모델이 학습 데이터를 그대로 출력할 위험을 검토했는가?
• 학습에 쓴 콘텐츠의 요약을 공개할 준비를 했는가? (EU 인공지능법 제53조, 집행위원회 템플릿으로 작성)
• 저작권 관련 정책을 정리했는가? (텍스트·데이터 마이닝 거부 표시 존중 등)
• 저장소에 올릴 파일에 API 키, 내부 서버 주소, 계정 정보가 없는가? (민감정보 제거 체크리스트 참고)

4. 모델 카드

작성 방법은 모델 카드를 참고하세요.

• 모델 카드의 일곱 항목을 모두 채웠는가? (모델 설명, 의도한 용도, 용도 밖 사용, 한계와 편향, 학습 데이터, 평가, 연락처)
• 베이스 모델이 있다면 base_model 항목에 밝혔는가?

5. 파일과 식별자

• 공개할 가중치 파일 목록이 의도한 것과 일치하는가? (실험용 체크포인트가 섞이지 않았는지)
• 각 가중치 파일의 해시(SHA-256)를 확보했는가?
• 모델 이름이 사내 명명 기준과 상표 검토를 통과했는가? (프로젝트 이름 결정 참고)
• 버전 표기 방식을 정했는가?

6. 공개 승인과 이후

• 소속 조직 담당 임원이나 리더의 승인을 받았는가?
• OSRB 검토를 요청했는가? (공개 절차의 A 단계)
• 공개 후 문의에 답할 담당자를 지정했는가?
• 취약점이나 오용 신고를 받을 경로를 정했는가?
• 모델을 내리거나 수정해야 할 상황의 판단 기준을 정했는가?

자동으로 점검하기

위 항목 중 모델 카드와 라이선스, 데이터셋 관련 부분은 도구로 확인할 수 있습니다. BomLens에 모델 id를 주면 모델 카드를 읽어 빠진 항목과 채우는 방법을 정리해 줍니다. 왜 필요한지와 실행 방법은 AI SBOM에 있습니다.

도구가 확인하는 것은 모델 카드와 저장소 정보에 드러난 범위까지입니다. 학습 데이터에 개인정보가 섞였는지, 계약상 공개가 가능한지 같은 판단은 사람이 해야 합니다.

관련 문서

• AI 모델 공개하기 — 전체 절차
• 모델 카드 — 작성 방법
• AI SBOM — 규제 대응 문서화

문의

판단이 어려운 항목은 OSRB(opensource@sktelecom.com)로 문의하세요.

4.2 - 모델 카드 작성

모델 카드는 별도 양식의 문서가 아닙니다. 모델 저장소에 두는 README.md 파일이 그대로 모델 카드가 됩니다. 파일 맨 위 YAML 부분이 기계가 읽는 메타데이터이고, 그 아래 마크다운 본문이 사람이 읽는 설명입니다.

공개 후 사용자가 가장 먼저 읽는 문서이고, 규제 대응 문서화의 출발점이기도 합니다. 여기에 적히지 않은 내용은 도구로도 확인할 수 없습니다.

파일 구조

---
license: apache-2.0
language:
  - ko
  - en
base_model: Qwen/Qwen2.5-7B
datasets:
  - HuggingFaceFW/fineweb
pipeline_tag: text-generation
library_name: transformers
---

# 모델 이름

모델 설명, 용도, 한계, 평가 결과를 적습니다.

메타데이터 항목

YAML 부분은 검색과 필터에 쓰이고, AI SBOM을 만들 때 기계가 읽는 부분이기도 합니다. 아래 네 항목이 특히 중요합니다.

표준 라이선스가 아니라면 license: other로 두고 이름과 링크를 함께 적습니다.

license: other
license_name: 라이선스 이름
license_link: https://example.com/license

학습 데이터셋을 공개하지 않는 경우에도 datasets 항목은 가능한 범위에서 밝히시기 바랍니다. 공개할 수 없는 사정이 있다면 본문에 그 사실과 이유를 적는 편이 아무것도 쓰지 않는 것보다 낫습니다.

본문에 담을 내용

Hugging Face가 제공하는 모델 카드 템플릿을 출발점으로 삼으시면 됩니다. 그중 다음 항목은 규제 문서화와 직접 연결되므로 비워 두지 않는 편이 좋습니다.

모델 설명

무엇을 하는 모델인지, 어떤 구조인지, 파라미터 규모는 어느 정도인지 적습니다.

의도한 용도

어떤 상황에서 쓰라고 만든 모델인지 적습니다. EU 인공지능법이 요구하는 기술 문서에서 시스템의 목적을 밝히는 부분과 대응합니다.

용도 밖 사용

쓰지 말아야 할 범위를 적습니다. 의료 진단이나 신용 평가처럼 잘못 쓰였을 때 피해가 큰 영역을 구체적으로 밝히는 편이 좋습니다.

한계와 편향

알고 있는 성능 한계와 편향을 적습니다. 검증하지 않은 영역이 있다면 검증하지 않았다고 쓰면 됩니다. 알려진 문제를 숨기는 것보다 밝히는 쪽이 안전합니다.

학습 데이터

어떤 데이터로 학습했는지, 전처리와 필터링을 어떻게 했는지 적습니다. 개인정보나 저작물을 걸러낸 방법이 있다면 함께 적습니다.

평가

어떤 기준으로 무엇을 측정했고 결과가 어땠는지 적습니다. 평가 데이터셋과 지표를 함께 밝힙니다.

연락처

문의와 신고를 어디로 보내면 되는지 적습니다. 공개 후 답할 담당자가 정해져 있어야 합니다.

작성 순서

모델 카드를 마지막에 몰아서 쓰면 학습 시점의 정보를 되짚어야 해서 부정확해집니다. 학습을 시작할 때 데이터 출처와 전처리 내용을 기록해 두시면 훨씬 수월합니다.

1. 학습 전에 데이터셋 목록과 출처, 라이선스를 기록합니다.
2. 학습 중에 하이퍼파라미터와 평가 결과를 기록합니다.
3. 공개 준비 단계에서 이를 모델 카드로 옮기고 용도와 한계를 씁니다.
4. 공개 전 체크리스트로 빠진 항목을 확인합니다.

관련 문서

• 공개 전 체크리스트 — 모델 카드 항목 점검
• AI SBOM — 모델 카드에서 만들어지는 문서
• Model Cards — Hugging Face 공식 문서

문의

작성 중 판단이 어려운 부분은 OSRB(opensource@sktelecom.com)로 문의하세요.

4.3 - AI SBOM과 규제 대응

AI SBOM은 모델과 학습 데이터셋, 그 출처와 라이선스를 기계가 읽을 수 있게 정리한 명세입니다.

• SBOM이 소프트웨어의 구성요소 목록이라면, AI SBOM은 모델 가중치와 학습 데이터처럼 일반 SBOM이 다루지 않는 항목까지 포함합니다.
• 모델 카드에 적힌 내용에서 만들어지므로, 모델 카드가 부실하면 AI SBOM에도 빈 항목이 그만큼 늘어납니다.

왜 만드는가

두 가지 쓰임이 있습니다.

1. 공개하는 쪽에서는 문서화가 얼마나 갖춰졌는지 확인하는 자기 점검 수단입니다. 무엇이 비어 있는지 목록으로 보이므로 공개 전에 메울 수 있습니다.
2. 공개한 뒤에는 다른 팀이나 조직이 이 모델을 도입할 때 검토 근거가 됩니다. 코드에 SBOM을 요구하듯 AI 모델에도 같은 문서를 요구하는 곳이 늘고 있습니다.

주요 규제

• 범용 모델을 공개하는 쪽에 걸리는 것은 제53조입니다. 기술 문서, 저작권 정책, 학습 콘텐츠 요약 공개를 요구하며 이미 적용 중입니다.
• 베이스 모델을 파인튜닝한 정도라면 의무 주체가 아닐 수 있습니다. 집행위원회 가이드라인은 추가 학습에 쓴 연산량이 원본의 3분의 1을 넘는지를 판단 기준으로 제시합니다.
• 가중치와 구조를 오픈소스 라이선스로 공개하면 기술 문서 의무는 면제되지만, 저작권 정책과 학습 콘텐츠 요약 공개는 남습니다. 요약은 집행위원회가 제공하는 템플릿으로 작성합니다.
• 제11조와 부속서 IV는 모델이 아니라 그 모델이 들어간 고위험 시스템에 걸리는 의무입니다.
• 국내 인공지능 기본법은 세부 문서화 요구가 시행령에 있어 EU만큼 구체적이지 않습니다. 특히 제32조(안전성)는 시행령이 정하는 연산량 임계치 이상으로 학습한 시스템에만 적용되므로, 해당 항목이 걸린다고 해서 곧바로 의무 대상이 되는 것은 아닙니다.

G7 최소 요구사항

2026년 5월 G7 국가들의 사이버보안 기관이 “Software Bill of Materials for AI — Minimum Elements"를 공동 발행했습니다. 독일 BSI와 이탈리아 ACN이 작업을 주관했고, AI 시스템의 명세가 갖춰야 할 최소 요소 50개를 일곱 묶음으로 정의합니다. 법적 구속력이 있는 규정이 아니라 권고입니다.

• 50개 중 13개는 자동으로 확인할 방법이 없습니다. 의도한 적용 분야나 학습 데이터의 민감도처럼 모델 카드의 어떤 필드로도 증명되지 않는 항목이라, 사람이 판단해서 채워야 합니다.
• BomLens 보고서는 이 50개를 51개 검사로 보여줍니다. 모델 공개성을 따로 떼어 보기 때문입니다.
• EU 인공지능법이 요구하는 기술 문서에는 G7 묶음 중 시스템 속성, 모델, 데이터셋 속성이 대응합니다. 이 대응 관계는 BomLens가 정리한 해석입니다.
• 권고이지만 요구하는 항목이 앞의 규제가 요구하는 기술 문서와 상당 부분 겹칩니다. G7 쪽을 채워 두면 규제 대응에 필요한 문서도 함께 갖춰집니다.

AI SBOM 생성 방법

SK텔레콤이 공개한 오픈소스인 BomLens에 모델 id를 주면 모델 카드를 읽어 CycloneDX(SBOM 표준 형식) 형식의 AI SBOM을 만들고, G7 요소 충족도와 규제 대응 관계를 함께 정리합니다. (모델 가중치 파일 전체를 내려받지 않고 모델 카드와 저장소 정보를 조회)

• 설치와 실행 방법, 보고서를 읽는 방법은 BomLens AI 모델 가이드에 있습니다.
• Docker 엔진이 필요하고, AI 모델 스캔용 이미지(약 3.5GB)를 처음 한 번 내려받습니다.
• 아래 명령은 BomLens를 설치한 상태에서 실행하는 예시입니다.

./scripts/scan-sbom.sh --project my-llm --version 1.0.0 \
  --model "my-org/my-llm" --generate-only

비공개 저장소는 읽기 권한이 있는 토큰이 필요합니다.

• Hugging Face 계정 설정의 Access Tokens에서 read 권한 토큰을 만듭니다. 세분화(fine-grained) 토큰이라면 해당 저장소 읽기를 따로 허용해야 합니다.
• 토큰을 HF_TOKEN으로 넘기는 방법과 게이트 저장소 조건은 비공개 모델과 게이트 모델에 있습니다.

결과로 다음이 나옵니다.

• 모델과 데이터셋을 담은 AI SBOM
• 요소별 충족 여부와, 비어 있는 항목을 채우는 방법
• EU 인공지능법과 국내 인공지능 기본법 대응 관계 정리
• 라이선스 검토가 필요한 항목 표시

결과 확인

전체 판정이 통과로 나와도 G7 항목이 다 채워졌다는 뜻은 아닙니다. 통과와 실패는 SBOM이 갖춰야 할 필수 형식 항목에서 갈리고, G7 요소는 모두 권고라 판정을 좌우하지 않습니다. 그래서 채워진 수와 비어 있는 수를 따로 보셔야 합니다.

• 비어 있는 항목은 두 종류로 나뉩니다. 모델 카드에 쓰면 채워지는 것과, 사람이 판단해야 하는 것입니다. 앞의 것부터 메우시면 됩니다.
• 보고서가 실제로 어떤 모습인지는 예시로 미리 볼 수 있습니다. 예시 모델을 스캔해 나온 적합성 보고서를 브라우저에서 그대로 열어 볼 수 있습니다. 묶음별 충족 현황과 검토 대상 라이선스가 맨 위에, 항목별 판정이 그 아래에 나옵니다.

관련 문서

• 모델 카드 — AI SBOM의 재료
• 공개 전 체크리스트 — 공개 전 점검 항목
• SBOM이란 — SBOM 일반
• BomLens AI 모델 가이드 — 설치와 실행, 보고서 읽는 법
• BomLens — SBOM 생성 도구 소개

참고 자료

• Software Bill of Materials for AI — Minimum Elements (G7, 2026-05)
• Regulation (EU) 2024/1689 (AI Act)
• EU 인공지능법 이행 일정 (집행위원회)
• 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법

문의

AI SBOM 생성과 해석에 관한 문의는 OSRB(opensource@sktelecom.com)로 연락하세요.