AI가 짠 코드, 저작권은 누구 것인가? — 에이전시가 반드시 알아야 할 3가지 리스크 (id.news.hada.io)
목차(5)
한줄 요약
AI 보조 코딩 결과물의 저작권은 '계약'과 '인간의 창작 기여도'에 따라 갈린다.
본문
AI 코딩 도구로 개발한 소프트웨어의 저작권 귀속 문제는 IT 개발 에이전시에게 더 이상 먼 나라 이야기가 아니다. Cursor, GitHub Copilot, Claude Code 같은 도구가 개발 현장에 빠르게 침투하면서, "이 코드는 누구 것인가"라는 질문이 납품 계약, 지식재산권 조항, 심지어 인수합병 실사 과정에서 실제 분쟁 소지로 떠오르고 있다.
에이전시 입장에서는 세 가지 축을 반드시 짚어야 한다. 저작권이 성립하는지, 계약상 누가 권리를 가져가는지, 그리고 오픈소스 라이선스 오염 리스크가 있는지다.
AI가 짠 코드, 저작권 자체가 없을 수도 있다
저작권은 인간의 창작 행위를 전제로 한다. AI가 대부분을 생성하고 개발자가 거의 손을 대지 않은 코드는 법적으로 저작권의 보호 대상이 되지 않을 수 있다. 현행 저작권 체계에서 핵심 기준은 '의미 있는 인간의 창작적 기여(meaningful human authorship)'다.
단순히 프롬프트를 입력하고 결과물을 그대로 수락하는 행위는 창작적 기여로 보기 어렵다. 반면 아키텍처 구조를 직접 설계하고, AI가 생성한 여러 결과물 중 특정 방향을 선택하고, 상당 부분을 재구성하는 행위는 인간의 창작 개입으로 인정받을 가능성이 높다.
에이전시 관점에서 이 문제는 단순한 법률 이슈가 아니다. 만약 납품 코드에 저작권이 성립하지 않는다면, 클라이언트가 해당 코드를 복제하거나 경쟁사가 유사 코드를 사용해도 법적으로 대응하기 어려울 수 있다. 반대로 에이전시가 자사 레거시 코드나 프레임워크를 AI 결과물과 혼용한 경우, 권리 귀속 경계가 모호해질 수도 있다.
계약서가 모든 걸 결정한다
저작권 성립 여부와 별개로, 실무에서 더 즉각적인 영향을 미치는 것은 계약 조항이다. 외주 개발 계약에는 대부분 결과물(work product)의 IP 귀속 조항이 포함된다. 이 조항의 범위가 넓으면, AI 도구가 생성한 코드도 자동으로 클라이언트 소유로 귀속될 수 있다.
특히 주의해야 할 표현이 있다. "프로젝트 수행 중 생성된 모든 결과물", "회사가 제공하거나 라이선스한 도구를 사용해 만든 산출물" 같은 문구는 AI 보조 코드를 폭넓게 포괄한다. 에이전시가 자체 구독으로 쓰는 AI 도구라도, 클라이언트가 해당 도구의 비용을 간접 부담하거나 라이선스를 제공한 형태라면 권리 귀속이 복잡해진다.
반대로 에이전시 입장에서도 체크할 포인트가 있다. 자사 소속 개발자가 에이전시의 AI 툴 구독 계정을 개인 프로젝트에 사용하면, 해당 결과물이 에이전시 소유로 해석될 여지가 생긴다. 계약서에 "회사 라이선스 도구 사용 시 결과물은 회사에 귀속된다"는 문구가 있다면 특히 그렇다.
실무 대응책은 간단하다. 납품 전 계약서의 IP 조항을 정확히 읽고, 에이전시 자체 IP나 공통 프레임워크는 명시적으로 carveout 처리해야 한다. 내부 개발자에게는 업무용 도구와 개인 프로젝트용 도구를 철저히 분리하도록 안내하는 것이 좋다.
오픈소스 라이선스 오염, 납품 후에 터진다
AI 코딩 도구는 방대한 공개 코드베이스를 학습 데이터로 사용한다. 이 중에는 GPL, LGPL 같은 카피레프트 라이선스가 적용된 코드도 포함된다. 카피레프트 라이선스의 핵심 의무는 하나다. 해당 코드의 파생 저작물을 배포할 때 동일한 조건으로 소스코드를 공개해야 한다는 것이다.
AI가 학습 데이터에서 특정 코드 패턴을 거의 그대로 재현하는 경우, 이론적으로는 라이선스 오염 문제가 발생할 수 있다. 현시점에서 법원이 이 경계를 어떻게 그을지 아직 확정되지 않았지만, '기능이 유사한 것'과 '코드를 실질적으로 복제한 것'은 다르게 취급된다는 점은 분명하다.
에이전시 입장에서 이 리스크가 가장 크게 터지는 시점은 클라이언트의 후속 투자 유치나 인수합병 실사 단계다. 잠재 투자자나 인수자는 코드베이스 내 오픈소스 라이선스 컴플라이언스를 실사 항목으로 요구하기 시작했다. 이때 라이선스 스캔 이력이 없으면 거래 자체가 지연되거나 무산될 수 있다.
FOSSA, Black Duck, Snyk Open Source 같은 라이선스 스캔 도구를 CI/CD 파이프라인에 통합하거나, 최소한 납품 전 점검 루틴에 포함시키는 것이 현실적인 대응이다.
자주 묻는 질문
Q.에이전시가 AI 도구를 써서 납품한 코드, 클라이언트에게 저작권이 넘어가나요?
계약서의 IP 귀속 조항에 따라 다르다. 대부분의 외주 계약은 납품 결과물의 권리를 클라이언트에게 이전하는 구조로 되어 있어서, AI 생성 코드도 포함될 가능성이 높다. 다만 에이전시가 자체 개발한 공통 프레임워크나 모듈은 계약에 명시적으로 carveout 조항을 넣어 권리를 유보하는 것이 필요하다. AI 보조 코드라는 이유만으로 저작권 귀속이 달라지지는 않는다.
Q.AI가 생성한 코드에 오픈소스 라이선스 오염이 있으면 에이전시 책임인가요?
납품 후 발생한 라이선스 위반은 계약 조건과 귀책 조항에 따라 책임이 달라진다. 다만 에이전시가 납품 전 라이선스 스캔을 수행하지 않았고, 이로 인해 클라이언트가 손해를 입었다면 책임 분쟁의 여지가 생긴다. 예방 차원에서 납품 프로세스에 오픈소스 라이선스 점검을 포함시키고, 이를 계약서에도 명시해두는 것이 에이전시를 보호하는 방법이다.
Q.개발자가 회사 AI 구독 계정으로 개인 프로젝트를 작업하면 어떻게 되나요?
회사와의 고용 계약이나 IP 귀속 조항이 넓게 작성되어 있을 경우, 회사가 라이선스한 도구를 사용해 만든 결과물은 회사 소유로 해석될 여지가 있다. 에이전시 대표나 HR 담당자라면 내부 정책으로 업무용 도구와 개인 용도를 명확히 분리하도록 안내해야 한다. 개발자 본인도 개인 프로젝트는 개인 계정과 개인 기기로 분리하는 것이 가장 안전하다.
관련 아티클
관련 사례
이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.
