AI 보조와 저작권 표기

LLM 기반 코드 보조가 일상화되며 "AI 가 도왔다는 것을 어떻게 표기할 것인가" 가 팀마다 다른 결정으로 갈라졌습니다. 이 글은 관련 사실 (소송 · OSS 라이선스 입장 · 커밋 트레일러 관습) 을 객관적으로 정리합니다.

1. AI 표기에 대한 이야기

GitHub Copilot 의 공개 (2021 년 6월 기술 미리보기, 2022 년 6월 일반 공개) 이후 AI 보조가 작성한 코드의 저작권 · 라이선스 위치에 대한 토론이 본격화. 핵심 쟁점:

1. 학습 데이터의 라이선스 준수 여부 — 모델이 GPL 같은 카피레프트 코드로 학습되어 비공개 코드 생성 시 라이선스 의무를 우회하는가.
2. 결과물의 저작권 — AI 가 생성한 결과물에 누가 권리를 가지는가, 또는 권리가 발생하는가.
3. 표기 의무 — AI 보조 사용을 외부에 알릴 의무가 있는가.

2. 소송과 정책 사례

DOE 1 v. GitHub (2022 ~) — 2022 년 11 월 미국 캘리포니아 북부지방법원에 GitHub · OpenAI · Microsoft 를 상대로 집단소송이 제기 (원고 다수가 익명, 대표 변호사 Matthew Butterick 등). 쟁점은 Copilot 이 학습 데이터의 OSS 라이선스 (GPL 등) 의 귀속 · 조건을 위반했는지. 법원은 일부 청구를 기각하고 일부를 진행시키는 등 단계적 결정. 2024 년 시점에도 잔여 청구가 일부 살아 있는 상태. 최종 판단은 변동될 수 있음.

미국 저작권청 (USCO) — 2023 년 3월 가이드라인 Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence 를 발표. 사람의 창작적 기여만이 저작권 대상이며, AI 만으로 생성된 부분은 저작권 보호 대상이 아니라는 입장. 등록 시 AI 부분의 표시를 권고. 한국 · EU 등 다른 관할은 입장이 다소 다르고 변동 중.

FSF · OSI:

• FSF (Free Software Foundation) 는 Copilot 가 GPL 의무를 우회할 우려를 공식 발표한 적이 있음 (2021 년 펀딩 콜 · 2022 년 입장문).
• OSI (Open Source Initiative) 는 Open Source AI Definition 1.0 을 2024 년 10 월에 발표하며 "오픈소스 AI" 의 기준을 정리. 데이터 · 코드 · 가중치의 개방 범위를 명시.

이 두 단체는 AI 보조의 사용 자체를 금지하지 않습니다. 입장은 라이선스 준수와 데이터 투명성의 강조에 가까움.

3. 표기의 관습

git 커밋 메시지의 trailer (Co-authored-by: · Signed-off-by: 등) 는 git 자체에 정의된 형식 (RFC 822 풍 헤더). GitHub 의 Co-authored-by 트레일러는 PR 페이지에서 공동 작성자로 표시.

AI 보조 사용을 표기하는 한 방식으로 다음과 같은 트레일러가 등장:

Co-Authored-By: Claude <noreply@anthropic.com>

이는 사실상의 관습일 뿐 표준은 아닙니다. 일부 도구 (Claude Code 기본 설정) 가 자동 추가하기도 하고, 팀 정책으로 끄는 곳도 있음.

4. 표기를 하지 않는 정책

다른 입장에서는 다음을 근거로 표기를 두지 않음:

• AI 는 IDE 자동완성 · 검색 엔진과 같은 보조 도구이며, 표기 대상이 아니라는 시각.
• 최종 결과물의 책임은 어차피 커밋한 사람에게 있다는 시각.
• 외부 노출 시 마케팅적 함의 (긍정 / 부정) 가 의도치 않게 따라붙는다는 시각.

표기를 하는 정책의 근거:

• 학습 데이터 · 모델 출력 가능성에 대한 투명성.
• 라이선스 분쟁 시 추적 가능성.
• 사회적 합의 형성에 기여한다는 시각.

어느 쪽이 옳은지에 대한 합의는 아직 없습니다. 팀이 어떤 입장을 채택하든 그 이유와 일관성이 더 중요하다는 평이 흔합니다.

5. 책임의 위치

기술적 · 법적 토론과 별개로, 실무에서 자주 강조되는 점:

• 검토 책임은 사람 — AI 가 제안한 코드라도 PR 을 보낸 사람의 검토 책임은 그대로.
• 외부 라이브러리 인용 — AI 가 제안한 코드가 특정 OSS 의 일부와 거의 일치하면 라이선스 의무가 그대로 따라온다는 견해.
• 시크릿 · 내부 코드 — 외부 API 를 사용하는 코드 보조는 입력 텍스트가 외부로 흘러나감. 시크릿 · 기밀 코드는 그 흐름에 들어가지 않도록 정책이 필요.

6. 팀 정책의 스펙트럼

입장	표기	사용
적극 표기	모든 AI 보조 커밋에 트레일러	자유롭게 사용
묵시적 사용	표기하지 않음	자유롭게 사용
제한적 사용	표기하지 않음	시크릿 / 특정 영역 금지
외부 도구 차단	—	사내 모델만 허용

회사 정책 · 고객 계약 · 규제 (금융 · 의료) 에 따라 적합한 입장이 달라집니다.

7. 자주 걸리는 자리

한 PR 안에서 어떤 부분이 AI 보조이고 어떤 부분이 사람이 적은 것인지 사후에 구분하기 어려움 — 표기를 한다면 일관된 규칙으로.

AI 가 제안한 라이선스 헤더 · SPDX 식별자가 잘못되어 있는 경우 — 라이선스는 도구 결정이 아니라 사람 결정.

"AI 가 제안했으니 책임이 없다" 는 변명은 어디서도 성립하지 않음 — 결과물의 책임은 PR 작성자에게.

정책이 자주 바뀌면 사람들이 무시하기 시작 — 입장을 정한 뒤에는 일정 기간 유지하고, 변경 시 이유를 명시.

하고픈 말

AI 보조의 표기 정책은 사회적 합의가 아직 형성 중인 자리. 표기 / 비표기 둘 다 일관된 이유가 있을 때 정당. 어느 쪽이든 검토 책임은 사람 · 시크릿은 외부에 안 흘림 · 라이선스는 사람 결정 셋은 모든 정책의 공통 기반입니다.

Next

• feature-flag-skeptic
• naming-readability

DOE 1 v. GitHub 소송 추적 · U.S. Copyright Office AI 가이드라인 · OSI Open Source AI Definition 1.0 · FSF Statements on Copilot · git commit-trailers · Conventional Commits · SPDX License List · GitHub About AI in code review 를 참고합니다.