Claude Code가 작성한 코드의 소유자는 누구인가?

4 hours ago 1

(legallayer.substack.com)

AI 보조 코드의 저작권은 인간의 의미 있는 창작 기여가 있는지에 달려 있으며, AI가 주로 만들고 인간이 거의 손대지 않은 결과물은 보호를 받지 못할 수 있음
핵심 판단 기준은 meaningful human authorship이며, 목표만 지시하는 수준보다 아키텍처를 정하고 결과를 걸러내고 코드를 다시 구성하는 창작 결정이 더 중요하게 작용함
코드의 저작권 성립 여부와 별개로, work-for-hire doctrine이나 넓은 IP 양도 조항이 있으면 회사 시간·장비·프로젝트·회사 라이선스 도구로 만든 AI 보조 코드도 회사 소유로 돌아갈 가능성이 큼
소유권이 있더라도 오픈소스 라이선스 오염은 별도 문제이며, 특히 GPL 계열 코드를 실질적으로 그대로 복제한 출력물은 라이선스 위반으로 이어질 수 있음
지금 비교적 분명한 축은 인간 저작성 부재 시 비보호, 고용계약에 따른 권리 귀속, GPL 축어적 복제의 위험이며, 실제 실무에서는 법원 판단보다 기록 보존과 라이선스 스캔이 더 먼저 중요해짐

저작권 기준과 미해결 구간

저작권 보호는 인간이 만든 저작물에만 적용되며, AI가 주로 생성하고 인간의 의미 있는 창작 기여가 없는 결과물은 현행 기준에서 보호 대상이 아닐 수 있음
Thaler 사건 이후에도 대법원이 본안을 판단한 것은 아니며, DC Circuit 판결은 유지됐지만 AI 보조 코딩 결과물에 그대로 적용된 직접 판례는 아직 없음
법원이 직접 다루지 않은 핵심 구간은 AI 보조 작업물에서 인간 개입이 얼마나 있어야 하는지임
- 순수 AI 생성 그림처럼 인간 개입이 0인 경우와 달리, 코드는 인간이 일부 방향을 정하고 승인하는 경우가 많아 경계가 더 흐려짐
- 코드 분야에는 아직 인간 저작성 원칙을 AI 코딩 출력물에 직접 적용한 판결이 없음
AI가 만든 코드를 거의 수정 없이 받아들였다면 누구도 저작권을 주장하지 못할 가능성이 있으며, 경쟁사가 그대로 복제해도 대응 수단이 약해질 수 있음
판단 기준의 핵심은 meaningful human authorship이며, 목표만 적어 주는 것보다 구조를 정하고 결과를 걸러내고 설계를 다시 짜는 창작 판단이 중요하게 다뤄짐

인간 저작성 입증 방식

의미 있는 인간 기여는 비율이나 수정 횟수로 딱 잘라 계산되지 않으며, 인간이 실제로 창작 결정을 내렸는지가 중요함
- 아키텍처 선택
  - 초안 중 무엇을 거절할지 결정해야 함
  - 특정 설계에 맞게 결과를 재구성해야 함
  - "API용 rate limiting 모듈을 만들어라" 같은 짧은 지시 뒤에 도구가 여러 파일을 만들고 반복 수정한 경우, 인간의 기여가 법정에서 충분한지에 대한 명확한 결론은 아직 없음
  - 상당히 방향을 바꿔가며 손본 모듈은 인간 저작성을 인정받을 가능성이 더 크지만, 그대로 수용한 코드는 반대 방향으로 해석될 수 있음
  - Allen v. Perlmutter는 600개가 넘는 프롬프트와 Photoshop 편집이 있었어도 AI가 만든 기본 요소는 등록이 거절된 사건으로, 인간 개입의 충분성을 가르는 중요한 분기점으로 남아 있음
  - Zarya of the Dawn에서는 인간이 쓴 텍스트만 등록되고 Midjourney가 만든 이미지는 제외됐으며, 이 원칙은 AI 보조 코드베이스에서도 인간이 직접 만든 요소를 분리 보호하는 방향과 맞닿아 있음
  - 설계 문서는 근거가 됨
  - 커밋 메시지에 남긴 설계 판단도 근거가 됨
  - ADR도 근거가 됨
  - 의도적으로 방향을 바꾼 흔적이 담긴 프롬프트 로그도 도움이 됨
  - 보호 가능한 부분을 넓히려면 무엇을 직접 결정했고 어떻게 바꿨는지 기록해 두는 편이 유리함

고용계약이 먼저 가르는 소유권

코드가 저작권 보호 대상인지 따지기 전에, 그 권리가 애초에 누구에게 귀속되는지부터 확인해야 함
일반적인 고용계약은 업무 범위 안에서 만든 산출물을 회사 소유로 돌리며, 이는 work-for-hire doctrine으로 설명됨
회사 업무 시간, 회사 프로젝트, 회사 장비, 회사가 제공한 AI 코딩 도구를 써서 만든 결과물은 수동 작성 코드와 AI 보조 코드 모두 회사 소유로 처리될 가능성이 큼
실제 계약서는 보통 기본 법리보다 더 넓게 써 두며, 다음 문구가 있으면 AI 보조 코드까지 포괄할 가능성이 큼
- 회사 장비나 자원을 사용해 만든 작업물도 포함될 수 있음
- 고용 기간 중 만든 발명이나 개발물도 포함될 수 있음
- 회사가 라이선스한 도구의 도움으로 만든 소프트웨어도 포함될 수 있음
특히 company-licensed tools 문구는 개인 프로젝트까지 번질 수 있음
- 회사가 Claude Code, Cursor, Copilot를 팀용으로 도입했고
- 같은 도구를 개인 시간의 사이드 프로젝트에도 썼다면
- 넓은 IP 양도 조항 아래서 회사가 권리를 주장할 여지가 생김
회사 코드가 IDE 안에서 열려 있었고 AI가 이를 볼 수 있었다는 이유만으로 출력물이 회사 IP의 파생저작물이 된다는 주장은 법적으로 그대로 성립한다고 보기 어렵다고 적혀 있음
다만 계약 문구가 넓으면, AI가 실제로 무엇을 했는지와 별개로 겉보기 주장 가능성은 생길 수 있음
사이드 프로젝트를 분리하려면 개인 계정, 개인 장비, 개인이 비용을 내는 도구로 워크플로를 완전히 나누는 편이 안전함

오픈소스 라이선스 오염 위험

AI가 만든 코드를 소유하더라도, 그 코드가 보이지 않는 오픈소스 라이선스 의무를 끌고 왔을 가능성은 별도 문제임
AI 코딩 도구는 공개 코드, 그중에서도 GPL, LGPL 같은 copyleft 라이선스 코드를 포함한 대규모 데이터로 학습됨
copyleft 라이선스는 해당 코드의 파생저작물 배포 시 동일 라이선스 공개 의무를 따라오게 만듦
- GPL 코드의 파생물이라면 자신의 소스도 같은 라이선스로 공개해야 함
- 라이선스를 몰랐다는 사정은 방어가 되지 않음
법적 위험의 기준은 기능 유사성이 아니라 실질적이고 상당한 축어적 복제에 있음
- GPL 코드처럼 동작하는 결과물과
- GPL 코드를 거의 그대로 재현한 결과물은 다른 문제임
위험은 축어적 복제 쪽에 몰려 있지만, 현재 코드베이스가 어느 쪽인지 스캔 없이는 알기 어려움
2026년 초 chardet community dispute에서는 Claude로 chardet를 다시 작성해 MIT 라이선스로 재배포한 일이 있었고, 이를 clean room 구현으로 볼 수 있는지를 두고 충돌이 있었음
- 이 사안은 법원 소송이 아니라 커뮤니티 분쟁이었고, 법적으로 결론이 난 것은 아님
- 다만 GPL 계열 코드를 그대로 복제하면 라이선스 위반이 된다는 점 자체는 이미 확립돼 있음
아직 확정되지 않은 부분은 AI 출력이 학습 데이터 패턴을 재현했을 때 그것을 축어적 복제로 볼 수 있는지임
기업 인수합병 자문 현장에서는 이 위험을 실제 이슈로 보고 있으며, AI 코드베이스 라이선스 스캔이 실사 항목으로 들어가고 있음
Doe v GitHub는 Copilot가 라이선스된 코드를 출처 없이 재현하는지를 다투고 있으며, 2026년 4월 기준 Ninth Circuit에서 계속 진행 중임
- 1심은 대부분의 청구를 기각했지만 항소는 살아 있음
- 소송 결과와 무관하게 GitHub는 duplicate detection filters를 추가했고 업계 실무도 바뀌고 있음

실무적으로 바로 할 일

라이선스 스캔 실행
- AI 보조 코드베이스에는 오픈소스 라이선스 스캔을 먼저 돌리는 편이 중요함
- FOSSA — 엔터프라이즈에서 널리 쓰이는 종합형 도구
- Snyk Open Source — GitHub 연동이 좋아 개발팀 워크플로에 맞기 쉬움
- Black Duck — M&A 실사에서 표준적으로 쓰이는 편임
- 이런 도구들은 코드베이스를 스캔해 알려진 오픈소스 라이브러리와의 일치 여부와 연결된 라이선스를 찾아줌
인간 창작 기여 기록
- 의미 있는 인간 저작성을 입증하는 자료는 평소 엔지니어링 과정에서도 이미 만들어지지만, 의도적으로 보존해야 효력이 커짐
- 커밋 메시지는 AI가 생성한 결과 자체보다 무엇을 왜 바꿨는지를 남겨야 함
  - "Restructured Claude’s module architecture, rejected initial state management approach, rewrote error handling from scratch" 같은 기록은 근거가 됨
  - "Add rate limiting module" 같은 기록만 남으면 인간 기여를 드러내기 어려움
- Claude Code와 Cursor의 상호작용 기록도 내보내기나 스크린샷으로 보관해 두는 편이 좋음
- 생성 코드보다 먼저 작성된 설계 문서, ADR, 메모는 사람이 구조를 먼저 정했다는 흔적으로 쓰일 수 있음
고용계약 IP 조항 확인
- 계약서에서 intellectual property, IP assignment, work product 항목을 직접 확인해야 함
- "근무 시간 중 만든 작업물"은 "회사 자원을 사용해 만든 작업물"보다 좁음
- "회사 사업과 관련된 것"은 "모든 소프트웨어 개발"보다 좁음
- company-licensed tools 문구는 개인 프로젝트에도 AI 도구 사용 흔적을 연결할 수 있음
- 독립 프로젝트를 하려면
  - 시작 전에 서면 carveout을 협의해야 함
  - 완전히 개인 장비, 개인 시간, 개인 도구로 분리해야 함
  - 회사 주장 가능성을 감수하고 진행해야 할 수도 있음
Anthropic 약관 유형 확인
- 상업용 출시에 앞서 anthropic.com/legal을 확인하고 consumer terms와 commercial terms 차이를 봐야 함
- free / Pro는 출력물 권리를 사용자에게 넘기지만, IP indemnification 범위가 더 좁음
- API / enterprise는 출력물 권리 양도와 함께, 승인된 사용과 출력물로 인한 저작권 침해 주장에 대해 방어 범위를 더 넓게 둠
- 다만 이런 면책도 코드베이스 내부의 GPL 오염 문제까지 대신 해결해 주지는 않음
- 그 부분은 라이선스 스캔과 내부 거버넌스로 직접 관리해야 함

지금 확정된 것과 아직 열려 있는 것

아직 법원이 명확히 가르지 않은 축은 두 가지임
- agentic 워크플로에서 얼마나 많은 인간 지시와 수정이 있어야 충분한 저작성이 되는지
- AI 출력이 학습 데이터 패턴을 재현했을 때 그것이 축어적 복제로 평가되는지
가까운 시일 안에 이런 쟁점이 대규모 소송으로 번질지는 순수한 추측 영역으로 남아 있음
실제로 이 불확실성이 가장 빨리 현실 문제가 되는 곳은 법정보다 M&A 실사와 기관 투자 심사임
인수자와 투자자는 이미 거래 종결 조건으로 이런 질문을 던지고 있으며, 지금 당장 그런 상황이 아니더라도 기록과 스캔을 미리 갖춰 두는 편이 유리함