AI에게 코드를 작성하게 하는 것. 이제는 당연한 일이 되었죠.

솔직히 말씀드리겠습니다. 우리는 AI가 내놓은 코드에 대해 대략 두 가지를 확인합니다. 하나는 "제대로 작동하는가". 다른 하나는 의식이 높은 현장이라면 "안전한가 (취약점은 없는가)". 여기까지는 테스트를 작성하거나 리뷰를 하는 등 점차 하나의 문화로 자리 잡았습니다.

하지만, 세 번째 질문이 통째로 빠져 있는 것 같다는 느낌이 듭니다.

그것은 바로 "이 코드, '라이선스적으로' 회사에서 사용해도 되는 거야?" 라는 질문입니다.

생각해 보세요. AI가 제안해 준 그 20줄이, 사실은 세계 어딘가에 있는 GPL 라이선스 리포지토리의 구현을 거의 그대로 가져온 것이라면? 그 코드를 당신의 프로덕트에 넣어서 고객에게 납품하거나 유상 SaaS로 판매하는 순간, "이 프로덕트 전체의 소스 코드를 공개해 주세요"라는 의무가 나중에 들이닥칠지도 모릅니다. 게다가 원래의 라이선스 표시(누가 작성했는지, 어떤 라이선스인지)는 AI의 출력물에서 깔끔하게 떨어져 나가 있어 아무도 눈치채지 못합니다.

무서운 점은, "작동"하고 "안전"하더라도 이 문제가 발생한다는 것입니다. 테스트는 모두 그린(Green). 취약점 스캔도 클린(Clean). 그럼에도 유래(이력)가 아웃(Out)이라면 사용해서는 안 됩니다. 검증하는 "축" 자체가 애초에 다르기 때문입니다.

이 기사는 그 세 번째 축 ―― "사용해도 되는가 (라이선스)"를 의지나 육안이 아닌 "시스템"으로 검증하기 위한 실전 가이드입니다. 무료 도구부터 시작할 수 있는 4단계 파이프라인을 CI에 통합하는 단계까지 안내합니다.

이 기사의 범위 (미리 선을 그어 두겠습니다)

• 이것은 "작동하지만 위험한 코드 (SQL 인젝션이나 XSS 등의 취약점)"에 관한 이야기가 아닙니다. 그것은 별도의 검증 축이며, 이전에 작성했습니다.
• 이것은 "AI가 존재하지 않는 패키지 이름을 지어내는 것 (패키지 환각·slopsquatting)"에 관한 이야기도 아닙니다. 그것도 별개의 문제입니다.
• 이 기사가 다루는 것은 "실재하는 OSS의 코드가 라이선스 표시 없이 당신의 코드 속으로 조용히 섞여 들어가는" 이력과 라이선스의 문제입니다.

먼저 "왜 그런 일이 일어나는가?"를 구조적으로 이해해 둡시다. 이 부분이 납득되지 않으면 대책이 단순한 "부적"이 되어버리기 때문입니다.

이유는 간단합니다. 대규모 언어 모델 (LLM)은 대량의 공개 소스 코드를 학습하여 만들어졌기 때문입니다. GitHub를 비롯한 전 세계의 OSS가 학습 데이터에 포함되어 있습니다. 그중에는 자유롭게 사용할 수 있는 관대한 라이선스의 코드도 있지만, GPL이나 AGPL 같은 "카피레프트 (Copyleft)" ―― 즉 "이것을 사용한다면 당신의 코드도 동일한 조건으로 공개해 주세요"라는 강력한 조건이 붙은 코드도 당연히 많이 있습니다.

AI는 학습한 패턴을 재구성하여 출력합니다. 대부분의 경우 오리지널에 가까운 "새로운" 코드이지만, 때때로 학습 원본 코드와 "striking similarity (현저한 유사성)"을 가진 단편을 내뱉을 때가 있습니다. 이 "striking similarity"는 법률 용어로, "우연히 이 정도로 비슷할 수는 없다 = 실질적 복제로 간주할 수 있다"라는 수준의 유사성을 가리킵니다.

게다가 질이 나쁜 것은, AI의 출력물에서는 원본 코드의 "라이선스 표시"나 "저작자명"이 사라져 있다는 점입니다. 이 저작권 표시·저자명·라이선스 조항 등의 정보를 전문 용어로 **CMI (Copyright Management Information / 저작권 관리 정보)**라고 부릅니다. 사람이 보통 복사해서 붙여넣는다면 아직 헤더 코멘트에 // Copyright ...가 남아 있어 알아챌 수 있지만, AI는 내부 로직만을 재구성하기 때문에 CMI가 깔끔하게 떨어져 나갑니다. 이 현상은 "license laundering (라이선스 론더링)"
―― 라이선스 세탁이라고 불리기도 합니다. 소소하지만 꽤 본질을 꿰뚫는 표현이라고 생각합니다.

"그런 일은 좀처럼 일어나지 않겠지"라고 생각하실지도 모릅니다. 여기서는 선동하지 않고 정확하게 살펴보겠습니다.

LiCoEval이라는 연구 (arXiv:2408.02487)가 14종류의 LLM을 평가하고 있습니다. 그곳에서의 보고가 이해하기 쉬우므로 인용하겠습니다.

• 가장 우수한 모델이라 하더라도, 생성된 코드의 **0.88%~2.01%**가 기존 OSS 구현과 "striking similarity(현저한 유사성)"를 보였다. - 그리고, 대부분의 LLM은 해당 유사 코드에 대해 올바른 라이선스 정보를 신고하지 못했다. 특히 Copyleft 라이선스에서 두드러졌다.

이 수치를 어떻게 받아들여야 할까요? "겨우 12%인가"라고 읽을 수도 있고, "50100번 중 한 번은 지뢰를 밟을 수 있다"라고 읽을 수도 있습니다. 저는 후자로 파악해야 한다고 생각합니다. 왜냐하면 이것은 **전형적인 "저확률 × 고영향"의 비대칭 리스크 (asymmetric risk)**이기 때문입니다. 대부분은 무해합니다. 하지만 단 한 번이라도 Copyleft 코드를 제품에 포함시켰고 그것이 표면화된다면, 그 영향은 "제품 전체의 소스 코드 공개"나 "거래처와의 계약 문제"까지 단번에 치솟을 수 있습니다. 빈도는 낮더라도 기대값 측면에서는 무시할 수 없는 것이죠.

참고로 업계의 분위기도 말씀드리겠습니다. GitHub Copilot을 둘러싸고 OSS 개발자들이 제기한 소송(Doe v. GitHub, 2022년 11월 제기)이 계속되고 있습니다. 많은 청구 사항이 2024년까지 기각되었으나, **"AI의 출력물에서 CMI를 제거하는 것이 DMCA (Digital Millennium Copyright Act, 디지털 밀레니엄 저작권법) §1202(b) 위반에 해당하는가"**라는 논점이 남아, 2026년 2월에 미국 연방 제9순회 항소법원에서 구두 변론이 진행되었습니다. 이 글을 쓰는 시점에서는 아직 판결이 나오지 않았습니다 (필자는 법률 전문가가 아니므로, 여기서는 "분쟁 중이며 결론이 나지 않았다"는 현재 상황만을 전달합니다. 판결을 예측하지는 않습니다).

중요한 것은 판결의 향방 그 자체보다, **"라이선스 표시나 이력(provenance)을 유지하는 것이 그만큼 무겁게 다뤄지는 논점이라는 것"**을 인지하는 것입니다. 그렇기에 우리 같은 구현 측면에서는 "AI가 지워버리는 이력을 우리만의 메커니즘으로 되찾아오겠다"는 자세가 필요한 것입니다.

여기서 잠시, 전문 용어들을 쉽게 정리해 두겠습니다. AI 코드의 라이선스 문제는 요컨대 **"빌려온 것일지도 모르는 코드를, 몰래 자신의 것처럼 사용하고 있지는 않은가"**의 문제입니다. 이 비유로 모든 것이 연결됩니다.

라이선스 (License)… 코드라는 대여품에 따라오는 "대여 규칙". 돌려줄 필요는 없지만, 사용 방식에 조건이 붙습니다. -
Permissive (허용적) 라이선스 (MIT / Apache-2.0 / BSD 등) … "저작권 표시만 남겨준다면 나머지는 자유. 상업적 이용도 OK, 수정도 OK"라는 느슨한 대여 조건. 기본적으로 아군입니다. -
Copyleft (카피레프트) 라이선스 (GPL / AGPL / LGPL 등) … "사용해도 좋지만, 이것을 포함하는 '당신의 결과물'도 동일한 조건으로 공개하라"는 강력한 조건이 붙은 대여. 이것이 섞이면 제품 전체에 조건이 "전염"될 수 있다는 점이 무서운 포인트입니다. 흔히 "감염"이라고 비유됩니다. -
CMI (Copyright Management Information, 저작권 관리 정보)… 대여품에 붙은 "소유자의 이름표". 저작자명, 저작권 표시, 라이선스 조항 등. AI는 이를 제거하기 쉽습니다. -
SPDX… 라이선스에 세계 공통의 "모델 번호"를 붙인 식별자. MIT, GPL-3.0-only, Apache-2.0처럼 기계가 읽을 수 있는 형태로 작성할 수 있습니다. -
SCA (Software Composition Analysis, 소프트웨어 구성 분석)… "당신의 제품에 어디 누구의 빌려온 물건이 몇 개 들어있는가"를 조사하는 작업 및 도구. -
스니펫 대조 (Snippet scanning)… 빌려온 목록(의존 패키지)뿐만 아니라, "소스 코드의 파편 그 자체"가 기지의 OSS와 일치하는지를 대조하는 한 단계 더 깊은 검사. AI 코드 대책에서는 이 부분이 핵심입니다. -
SBOM (Software Bill of Materials)… "소프트웨어 부품표(성분표)". 무엇이, 어떤 버전으로, 어떤 라이선스로 포함되어 있는지 나타낸 목록. 식품의 원재료 표시와 같습니다. 표준 포맷으로는 CycloneDX (OWASP 유래)나 SPDX가 있습니다.

이 지도만 머릿속에 있다면, 앞으로 나올 명령어들이 "아, 이름표를 확인하고 있구나", "성분표를 만들고 있구나"라고 읽힐 것입니다.

실제로 손을 움직이기 전에 역할 분담을 고정합니다. 이 부분을 처음에 정해두지 않으면, "도구가 초록불(Pass)이니까 출하 OK"와 같은 판단의 전가가 발생합니다. 라이선스는 최종적으로 "사업적 판단"이므로, 기계에게 결정을 맡겨서는 안 되는 영역이 있습니다.

암기법은 평소와 같습니다. 「What(무엇을 허용할 것인가)과 Why(왜)는 인간, How(어떻게 탐지할 것인가)는 AI·도구」 입니다. 탐지는 기계가 빠르고 정확합니다. 하지만 「이 리스크를 짊어지고 출하할 것인가」는 인간만이 결정할 수 있습니다.

여기서부터 본론입니다. AI 코드의 라이선스를 "시스템"으로 보호하는 4단계 파이프라인을 구축합니다. 갑자기 전부 다 하려고 하면 부담스러우니, 위에서부터 순서대로, 할 수 있는 곳부터 시작해도 괜찮습니다. 우선 1단계만이라도 오늘 바로 도입해 보세요.

먼저 발밑부터 시작합니다. AI가 pip install이나 npm install을 제안할 때마다, 해당 의존성 패키지의 라이선스가 「우리 회사에서 허용하는 것인가」를 기계적으로 체크합니다. 이는 기존의 무료 도구로 한 번에 해결할 수 있습니다.

Node.js (license-checker) 예시:

# 의존성 라이선스 목록 출력
npx license-checker --summary
# 허용 리스트 이외의 것이 섞여 있다면 실패 처리 (CI에서 사용 가능)
...

Python (pip-licenses) 예시:

pip install pip-licenses
# 라이선스별로 목록화
pip-licenses --format=markdown --order=license
...

포인트는 「허용 리스트 (allowlist) 방식」으로 만드는 것입니다. 「이것은 안 됨」을 나열하는 금지 리스트 방식이라면, 모르는 라이선스가 빠져나갈 수 있습니다. 「이것들만 OK, 그 외에는 전부 멈추고 인간이 확인한다」는 방식이 압도적으로 안전합니다. 이는 이전에 보안 관련 기사에서 썼던 「default deny (모르면 일단 차단)」와 같은 발상입니다.

1단계는 「선언된 의존성」만 볼 수 있습니다. 하지만 AI가 삽입하는 코드는 의존성 패키지가 아니라, 당신의 소스에 직접 복사된 단편(fragment) 입니다. 이를 잡아내려면 소스 레벨 스캔 (source-level scan) 이 필요합니다. 무료이면서 정석적인 도구는 ScanCode Toolkit (AboutCode 프로젝트)입니다. 라이선스, 저작권, 코드의 출처를 소스에서 직접 탐지해 줍니다.

# 설치 (pip로 설치 가능)
pip install scancode-toolkit
# src/ 하위를 스캔하여 라이선스, 저작권, URL을 탐지하고 JSON으로 출력
...

ScanCode는 SPDX 형식의 식별자로 결과를 반환하므로, gpl-3.0이나 agpl-3.0 같은 카피레프트가 탐지되면 그 부분을 인간이 정밀 조사하는 운영 방식으로 연결할 수 있습니다. 「AI가 작성했을 터인 파일에서 왜인지 GPL의 흔적이 나타났다」 —— 이것을 볼 수 있는 것만으로도 사고율이 확연히 낮아집니다.

보충: ScanCode와 같은 OSS 도구는 「라이선스 텍스트나 기지 패턴(known pattern)의 대조」가 주 전장입니다. 더 깊이 들어가서 "전 세계의 OSS 스니펫 데이터베이스와 단편 단위로 대조"하는 단계까지 가고 싶다면, Black Duck, FOSSA, FossID와 같은 상용 스니펫 대조 도구가 강점을 가진 영역입니다. 우선은 무료인 ScanCode로 토대를 만들고, 규모가 커지면 상용 단계를 추가하는 순서가 좋다고 생각합니다.

탐지가 되었다면, 다음은 「우리 프로덕트에는 이러한 성분이 들어 있습니다」를 목록화한 부품 명세서 (SBOM)를 남기는 것입니다. 이는 감사, 납품, 취약점 대응에서도 유용하게 쓰이는, 말하자면 "성분 표시 라벨"입니다. OWASP의 CycloneDX가 가볍고, 라이선스 정보도 SPDX로 가질 수 있습니다.

# 예: Node.js 프로젝트의 SBOM를 CycloneDX 형식으로 생성
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
# 예: Python 프로젝트의 SBOM를 생성
...

생성된 SBOM에는 각 컴포넌트의 licenses 필드가 포함되므로, 이곳을 기계적으로 스캔하면 "금지된 라이선스가 성분에 포함되어 있지 않은지"를 후속 게이트(Gate)에서 판정할 수 있습니다. 부품 명세서(BOM)는 미래의 자신(또는 감사 담당자)에게 남기는 인수인계서인 셈입니다. "이 릴리스 시점에 무엇이 들어 있었는지"를 나중에 증명할 수 있습니다. 이것이 있으면 막상 문의가 들어왔을 때 당황하지 않고 대처할 수 있습니다.

마지막으로, ①~③을 사람의 선의에 의존하지 않고 파이프라인을 통해 강제합니다. GitHub Actions를 사용하여 풀 리퀘스트(Pull Request)가 생성될 때마다 실행하는 예시입니다. 여기서의 설계 사상은 "결정적으로 문제가 되는 것(기존에 알려진 금지 라이선스)은 block으로 중단시킨다. 그레이 존(미지/판정 불능)은 warning으로 처리하여 사람에게 넘긴다" 입니다. 전부 block으로 설정하면 현장 업무가 돌아가지 않으므로, 강도의 차이를 둡니다.

# .github/workflows/license-gate.yml
name: license-gate
on:
...

판정 스크립트는 다음과 같은 형태입니다. 금지(Copyleft)는 즉시 실패 처리하고, 미지 라이선스는 경고를 띄워 사람의 눈으로 확인하게 합니다.

# scripts/check_license_policy.py
import json
import sys
...

이로써 "AI가 작성한 코드에 GPL의 흔적이 섞인 채 몰래 머지(Merge)되는" 사고를 시스템으로서 막을 수 있습니다. 사람이 실수하더라도 파이프라인은 잠든 사이에도 작동합니다. 이 지점이 바로 "의지"와 "시스템"의 결정적인 차이입니다.

결과물을 검사하는 것뿐만 아니라, "애초에 너무 유사한 코드가 나오지 않게 하거나, 나왔을 때 바로 알아챌 수 있는" 입구에서의 장치도 있습니다. 양론을 솔직하게 소개하겠습니다.

예를 들어 **GitHub Copilot에는 "Suggestions matching public code(복제 탐지 필터)"**라는 설정이 있습니다. 이는 AI의 제안 코드와 주변의 **약 150자(대략 65개 렉심(Lexeme) 이상)**를 GitHub상의 공개 코드 인덱스와 대조하여, 일치하거나 유사한 것이 발견되면 **차단(Block 모드)**하거나, **일치하는 공개 리포지토리와 그 라이선스를 표시(Allow 모드 + code referencing)**하는 기능입니다. 조직 단위로 Block 설정을 해두면

다음 스캔 결과와 SBOM을 바탕으로, 경영진과 법무팀도 읽을 수 있는
「OSS 라이선스 컴플라이언스 (OSS License Compliance) 보고서」 초안을 작성해 주세요.
- 검출된 라이선스 내역 (permissive / copyleft / 미확인 건수)
...```

세 가지 공통점은, **AI에게 「조사하게 하고・나열하게 하고・초안을 쓰게 하되」, 「결정하게 하지 않는다」** 는 자세입니다. 판단의 주어는 마지막까지 인간에게 두는 것입니다.

시스템을 도입하더라도 운영을 잘못하면 의미가 없어집니다. 이 부분은 별도로 정리해 두겠습니다.

-
**카피레프트 (Copyleft) 혼입은 「저확률×고영향」. 빈도로 방심하지 말 것.** GPL/AGPL의 파편이 단 하나라도 들어가는 순간, 최악의 경우 제품 전체의 소스 코드 공개 의무로 파급될 수 있습니다. "1~2%니까 괜찮겠지"가 아니라 "걸리면 치명적이다"라는 마음가짐으로 대비해야 합니다. 반대로, permissive (MIT/Apache)는 표시 의무만 지키면 위험하지 않으므로, 과도하게 두려워하여 개발이 중단되는 것도 피하고 싶습니다. **위험의 농도를 구분하여 경계하는 것**이 정답입니다. -
**AI의 라이선스 신고를 최종 판정에 사용하지 말 것.** 앞서 언급했듯이, 연구상 많은 모델이 올바른 라이선스를 신고하지 못합니다. AI의 "이것은 MIT라고 생각합니다"는 편리한 포스트잇일 뿐, 증거가 아닙니다. **반드시 ScanCode 등의 결정적인 스캔을 통해 사실 관계를 확인 (Back-check)** 하십시오. -
**사내 코드나 비밀을 외부 스캔 SaaS에 무단으로 업로드하지 말 것.** 라이선스 스캔을 클라우드 서비스에 던지는 것은 곧 "자사의 비공개 소스를 외부로 내보내는" 행위이기도 합니다. **AI나 SaaS에 전달하는 것 = 외부로 나가는 것**입니다. 계약 및 데이터 취급 방침을 확인하고, 기밀성이 높은 코드는 로컬에서 완결되는 툴 (ScanCode는 로컬 실행이 가능합니다)을 선택하십시오. 이 부분은 이전부터 여러 번 강조해 온 철칙입니다. -
**비가역적인 행위 (출하·납품·OSS 공개)는 반드시 인간의 승인 게이트 (Approval Gate)를 거칠 것.** CI의 라이선스 게이트는 "문지기"이지 "최종 결재권자"가 아닙니다. 회색 영역(Gray area)이 남은 채로 기계의 초록색 신호만 믿고 세상에 내보내지 마십시오. **세상에 내보낸 코드는 되돌릴 수 없습니다.** 되돌릴 수 없기에, 인간이 마지막으로 고개를 끄덕인 후에 진행해야 합니다.

| 걸림돌 | 발생하는 현상 | 대책 |
|---|---|---|
| 금지 리스트 방식 사용 | 모르는 라이선스가 빠져나감 | 허가 리스트 (default deny) 방식으로 전환 |
| ... | |
-
**카피레프트의 파편이 제품 코어에 깊숙이 박혀 있는 경우**… 그 자리에서 판단하지 말고, 코드 재작성·대체 라이브러리 검토·법무 상담으로 전환하십시오. -
**툴이 「판단 불능」을 대량으로 반환하는 경우**… 스캔 설정이나 대상 범위를 재검토하십시오. 통과시키기 위해 기준을 느슨하게 만들어서는 안 됩니다. -
**유래를 전혀 추적할 수 없는 코드가 섞여 있는 경우**… 출하를 중단하고, 해당 부분을 클린룸 (Clean room)에서 재작성하는 판단을 포함하여 검토하십시오.

지금까지 AI 코드의 「사용 가능 여부 (라이선스)」를 시스템으로 보호하는 방법에 대해 이야기했습니다. 마지막으로, 조금은 마음을 편히 먹고 들어주세요.

제가 이 이야기를 중요하게 생각하는 이유는, 이것이 **「과거의 자신을 탓하지 않는 기술」** 이기 때문입니다.

반년 후, 감사나 거래처로부터 "이 코드, 출처가 확실합니까?"라는 질문을 받았을 때. SBOM도 스캔 로그도 아무것도 없다면, 당시의 자신을 자책하며 새파랗게 질린 얼굴로 조사에 며칠을 허비하게 될 것입니다. 하지만 오늘 CI에 라이선스 게이트를 하나 심어두었다면, 그때의 미래의 당신은 부품 명세서(BOM) 한 장을 내밀며 "네, 확인 완료되었습니다"라고 태연하게 대답할 수 있습니다.

이것은, **「내일의 내가 '고마워요'라고 말하게 만드는 준비」** 인 셈입니다. 누군가를 비난하기 위한 체크가 아니라, 미래의 자신과 함께 일하는 동료를 지키기 위한 배려입니다. 30초에서 몇 분의 스캔이 바로 그런 장치가 되어줍니다.

그리고 이렇게 쌓아 올린 「안전하고 당당하게 출하할 수 있는 상태」는 사라지지 않는 자산이 됩니다. 동작하는 코드는 순식간에 가치를 잃을 수도 있지만, **"유래가 깨끗하고 언제든 증명할 수 있다"는 신뢰**는 당신의 프로덕트의 토대로서 계속 쌓여갈 것입니다. 코드 그 자체뿐만 아니라, 그것을 안심하고 세상에 내보낼 수 있는 시스템을 포함하여 하나의 자산 (Capital)이라고 생각합니다.

오늘의 첫걸음은 단 하나면 충분합니다. **당신의 리포지토리에서 `license-checker`나 `pip-licenses`를 한 번 실행해 보고, 허가 리스트를 작성해 보세요.** 그것만으로도 제3의 축으로 들어서는 입구에 설 수 있습니다.

함께 AI와 기분 좋게, 그리고 당당하게 만들어 나갑시다.

생성형 AI 활용 엔지니어 & 세 아이의 아빠. AI × 개발의 실전 지식을 매일 발신하고 있습니다 → X: @akira_papa_AI

- LiCoEval: 코드 생성 시 라이선스 준수 여부를 평가하는 LLM (arXiv:2408.02487) https://arxiv.org/abs/2408.02487 ／ 벤치마크 https://github.com/osslab-pku/LiCoEval
- GitHub Copilot 소송(Doe v. GitHub) 사례 업데이트 https://githubcopilotlitigation.com/case-updates.html ／ 쟁점 해설 https://www.bakerlaw.com/the-copilot-litigation/
- GitHub Docs: GitHub Copilot 제안과 일치하는 공개 코드 찾기 (복제 감지 필터) https://docs.github.com/copilot/using-github-copilot/finding-public-code-that-matches-github-copilot-suggestions
- ScanCode Toolkit (AboutCode) https://github.com/aboutcode-org/scancode-toolkit
- CycloneDX (OWASP SBOM 표준 / Tool Center) https://cyclonedx.org/
- FOSSA: 스니펫 스캐닝 설명 https://fossa.com/blog/snippet-scanning-explained/

(참고: 본 기사의 코드는 설명을 위한 최소 예시입니다. `license-checker`

/ `pip-licenses`

/ `scancode`

/ GitHub Actions의 각 명령어 및 옵션은 공식 문서를 기반으로 작성되었으나, 실행 여부는 사용 환경 및 버전을 통해 확인해 주십시오. Python 판별 스크립트는 로직의 초안이며, 실제 데이터에서의 작동 여부는 개인이 확인해야 합니다. 즉, 동작 미확인 초안으로 간주해 주십시오. 법적 판단에 대해서는 반드시 소속 조직의 법무팀 또는 전문가와 상담하시기 바랍니다. 필자는 법률 전문가가 아닙니다.)