보안

AI 생성 코드 저작권과 개발 증적 관리: 회사 자산으로 활용하려면?

2026.10.29

“개발자는 AI가 짜준 코드를 그대로 커밋했다. 그런데 이 코드, 정말 회사 것이 맞을까?”

1. AI 코딩 시대의 코드 자산 관리: 기업이 확인해야 할 권리와 책임

■ AI가 초안을 쓰고 개발자가 다듬는 개발 방식

생성형 AI 기반 코딩 도구가 개발 현장의 기본 도구로 자리 잡았다. 개발자가 자연어로 요구사항을 입력하면 AI가 프로젝트의 기본 구조를 만들고 함수나 모듈 단위의 코드를 작성한다. 개발자는 이를 수정·검토해 저장소에 커밋한다. 최근에는 AI 에이전트가 여러 파일을 한꺼번에 고치고 테스트까지 실행하는 방식도 빠르게 확산되고 있다. 프로젝트의 뼈대부터 세부 코드까지 AI가 먼저 작성하는 일은 더 이상 낯설지 않다.

■ 흔들리는 ‘개발자가 직접 작성한 코드’라는 전제

지금까지 기업의 코드 자산 관리는 ‘소속 개발자가 업무상 직접 작성한 코드’라는 전제 위에서 이루어졌다. 작성자가 분명하니 권리 귀속도, 문제가 생겼을 때의 책임 소재도 비교적 명확했다. 그러나 AI가 생성한 코드가 섞이면서 이 전제가 약해졌다. 어느 부분을 사람이 쓰고 어느 부분을 AI가 썼는지, AI가 학습 데이터 속 기존 코드를 거의 그대로 재현한 것은 아닌지, 그 코드를 누가 확인하고 반영했는지가 불분명해진다. 개발 속도는 빨라졌지만, 권리와 책임을 판단할 근거는 오히려 흐려진 셈이다.

■ 기업이 확인할 세 가지 코드 권리 쟁점

그래서 질문을 바꿔야 한다. ‘AI가 만든 코드의 주인은 누구인가’라는 질문은 법적으로도 아직 정리되지 않은 부분이 많고, 개별 기업이 당장 답을 내기도 어렵다. 실무에서 더 중요한 질문은 ‘기업이 이 코드를 자산으로 활용하려면 무엇을 확인하고 무엇을 남겨야 하는가’이다. 이 질문은 다시 보호 가능성, 회사 귀속, 타인의 권리 침해라는 세 가지 쟁점으로 나뉜다.

2. AI 생성 코드의 권리 판단: 저작권 보호·회사 귀속·타인 권리 침해 3가지 쟁점

세 쟁점은 서로 연결되어 있지만 판단 기준은 각각 다르다. ‘보호받을 수 있는가 → 회사 소유로 인정되는가 → 타인의 권리를 침해하지 않는가’의 순서로 나누어 살펴봐야 혼동을 줄일 수 있다. 하나의 쟁점에서 문제가 없다고 해서 나머지 쟁점까지 해결되는 것은 아니다.

■ 쟁점 ① 보호받을 수 있는가: 저작권 보호 가능성

우리 저작권법은 저작물을 ‘인간의 사상 또는 감정을 표현한 창작물’로 정의한다. 따라서 사람의 창작적 기여 없이 AI가 자동으로 만들어 낸 결과물 자체는 저작물로 인정받기 어렵다. 문화체육관광부와 한국저작권위원회가 2025년 6월 발간한 「생성형 인공지능 활용 저작물의 저작권 등록 안내서」도 저작권 등록의 요건을 인간의 창작적 기여로 보고, 보호 범위 역시 그 기여가 있는 부분에 한정된다고 설명한다. 안내서는 AI 산출물에 수정·증감 등 추가 작업을 한 부분에 창작성이 있는 경우나, 산출물의 선택·배열·구성에 창작성이 있는 경우를 인간의 창작적 기여의 예로 들었다. 반면 프롬프트 입력만으로는 창작적 기여가 인정될 가능성이 낮다고 보았다.

미국도 같은 방향이다. 미국 저작권청은 2025년 1월 발표한 「저작권과 인공지능」 보고서 제2부(저작권 보호 가능성)에서 인간 저작자 요건을 재확인했다. AI가 단독으로 생성한 작품의 저작권 등록을 다툰 Thaler v. Perlmutter 사건에서도 연방항소법원이 2025년 3월 저작권청의 등록 거부를 유지했고, 연방대법원은 2026년 3월 2일 상고를 받아들이지 않았다.

이를 코드에 적용하면 시사점이 분명하다. 코드는 기능적 성격이 강해 원래부터 창작성이 인정되는 폭이 좁다. AI가 제안한 코드를 그대로 쓰거나 변수명 몇 개만 바꾼 경우라면 보호받기 어렵다. 반대로 개발자가 전체 구조를 설계하고 AI 결과물을 선택·배열·재작성했다면 그 기여 부분은 보호될 여지가 있다. 다만 ‘개발자가 검토했다’거나 ‘일부를 수정했다’는 사실만으로 저작권이 확보되는 것은 아니다. 결국 사람이 무엇을, 어느 정도 기여했는지를 나중에 구체적으로 설명할 수 있느냐가 관건이다.

■ 쟁점 ② 회사 소유로 인정되는가: 회사에 대한 권리 귀속

코드가 저작권 보호 대상이 될 수 있는지와 그 권리가 회사에 귀속되는지는 별개의 문제다. 보호 대상이 되는 부분이라도 회사 귀속 여부는 회사의 기획 아래 업무 종사자가 업무상 작성했는지, 계약·근무규칙에 다른 정함이 있는지 등을 따져 판단한다. 특히 외주 개발자, 프리랜서, 협력사가 AI 도구로 작성한 코드는 계약에서 권리 귀속을 명확히 정하지 않으면 회사에 귀속되지 않을 수 있다.

AI 도구의 이용약관도 확인 대상이다. 상당수 상용 도구는 산출물에 대한 권리를 이용자에게 귀속시키거나 서비스 제공자가 권리를 주장하지 않는다고 정한다. 그러나 약관은 제공자와 이용자 사이의 권리 관계를 정하는 것이며, 그 약정만으로 산출물의 저작물성이나 제3자 권리의 부존재가 보장되지는 않는다. 또한 개발자가 회사가 허용하지 않은 개인 계정이나 무료 요금제로 업무 코드를 생성했다면 적용 약관과 입력 데이터 처리 조건이 달라질 수 있다. 한편 보호 대상이 아닌 부분은 회사가 보유하고 있더라도 저작권으로 배타적 권리를 주장하기 어렵다. 이런 영역은 영업비밀 관리 등 다른 보호 수단을 함께 고려해야 한다.

■ 쟁점 ③ 타인의 권리를 침해하지 않는가: 제3자 권리 침해

우리 회사에 저작권이 인정되는지와 관계없이 타인의 권리를 침해할 가능성은 별도로 존재한다. AI 모델은 공개 저장소의 방대한 코드를 학습했기 때문에 기존 코드를 거의 그대로 재현할 수 있다. 기존 코드가 포함되면 해당 라이선스의 종류와 결합·수정·배포 방식에 따라 소스코드 공개 의무나 라이선스 위반 분쟁으로 번질 수 있다.

관련 소송도 진행 중이다. 공개 저장소에 코드를 올린 개발자들은 GitHub Copilot이 라이선스와 저작권 고지 없이 자신들의 코드를 재현한다며 GitHub, Microsoft, OpenAI를 상대로 소송을 제기했다(Doe v. GitHub). 미국 제9연방순회항소법원은 2026년 9월 16일, 디지털밀레니엄저작권법(DMCA)상 저작권관리정보 제거 청구를 기각한 1심 판단을 유지했다. AI 도구가 기존 코드 사본에서 고지를 지운 것이 아니라 새로운 코드를 생성했다고 본 것이다. 다만 이 판결은 특정 청구의 범위를 좁힌 것이며, 출력된 코드가 저작권 침해에 해당하는지는 판단한 것은 아니다. 무엇보다 도구 제공자를 상대로 한 소송 결과와 별개로, AI가 생성한 코드를 제품에 넣어 배포하는 기업은 스스로 라이선스 준수 책임을 진다.

[표 1] AI 생성 코드 권리 판단의 3가지 쟁점

3. AI 생성 코드의 개발 증적 관리: 생성부터 배포까지 무엇을 남길 것인가

앞의 세 쟁점은 모두 사실관계 확인을 전제로 한다. 사람이 무엇을 기여했는지, 누가 어떤 조건에서 작성했는지, 라이선스 문제를 확인했는지는 기록이 없으면 사후에 재구성하기 어렵다. 여기서 핵심은 ‘개발자가 검토했는가’라는 단순한 사실이 아니라, 생성·수정·검토·배포의 과정을 신뢰할 수 있는 기록으로 남길 수 있는가이다. 기록이 권리를 만들어 주지는 않는다. 다만 권리와 책임을 판단하는 재료가 된다.

■ AI 생성 코드의 개발·검토·배포 5단계

권리와 책임을 판단하려면 AI 생성 → 개발자 수정·검토 → 라이선스 확인 → 보안 검토 → 커밋·배포로 이어지는 과정 전체를 확인할 수 있어야 한다. 각 단계에서 남길 기록과 그 기록이 어떤 판단에 쓰이는지는 다음과 같다.

[그림 1] AI 생성 코드의 생성·수정·검토·배포 흐름

[표 2] 단계별 개발 증적 항목

■ 개발 증적을 커밋·릴리스와 연결하는 방법

기록이 메신저, 이슈 트래커, 개인 PC에 흩어져 있으면 증적으로서의 가치가 떨어진다. 기록은 최종 코드, 즉 특정 커밋과 릴리스 버전을 기준으로 연결되어야 한다. 예를 들어 커밋 메시지에 AI 사용 여부와 도구를 표시하고, 코드 리뷰 요청(PR)에 AI 생성 원본과 수정 내역을 첨부하며, CI 파이프라인에서 라이선스·보안 검사 결과를 자동 저장하는 방식이다. 릴리스 시점에는 이 기록들을 하나로 묶고 최종 코드의 해시값을 함께 기재해, 어떤 기록이 어떤 코드에 대한 것인지 명확히 연결한다.

■ 개발 증적이 필요한 코드 분쟁·고객 감사·기술 실사

다음은 기록 유무가 권리와 책임 판단에 영향을 주는 대표적인 상황을 가정한 사례다.

사례 A. 핵심 모듈 유출 분쟁 — 퇴사한 개발자가 경쟁사에서 유사한 모듈을 내놓았다. 회사가 저작권 침해를 주장하려면 해당 모듈에서 사람이 창작적으로 기여한 부분을 특정해야 한다. AI 생성 원본과 개발자 수정 내역이 남아 있다면 기여 범위를 구체적으로 설명할 수 있다. 반면 AI 사용 여부조차 기록이 없다면 상대방이 ‘AI가 생성한 부분이라 보호 대상이 아니다’라고 반박할 때 대응할 근거가 부족하다. 물론 기록이 있다고 보호가 보장되는 것은 아니다. 판단에 필요한 재료가 생길 뿐이다.

사례 B. 고객사 공급 코드의 라이선스 문제 제기 — 고객사에 공급한 솔루션에서 카피레프트 라이선스 코드와 유사한 부분이 발견됐다는 지적을 받았다. 공급 시점의 라이선스 검사, 조치, 배포 기록이 있다면 회사가 확인 절차를 거쳤다는 점을 설명하고 영향 범위를 신속하게 특정할 수 있다. 기록이 없다면 전체 코드를 다시 조사해야 하고, 그동안 고객 신뢰와 계약상 책임 문제가 동시에 커진다.

사례 C. 투자·인수 실사와 고객 감사 — 기술 실사나 고객사 보안 감사에서 AI 생성 코드 관리 정책과 근거 기록을 요구받는 경우가 늘고 있다. 정책 문서만 있고 실제 기록이 없다면 관리 체계를 입증하기 어렵다.

4. 개발 증적의 무결성과 시점확인: Magic TSA AR 활용

■ 개발 증적의 시점·무결성을 확인해야 하는 이유

기록을 남기는 것만으로는 충분하지 않다. 기록이 사후에 변경될 수 있다면 실제 분쟁, 감사, 권리 판단 과정에서 증적의 신뢰성은 크게 낮아진다. Git 이력도 관리자 권한이 있으면 재작성할 수 있고, 로그 파일이나 문서는 얼마든지 수정할 수 있다. 분쟁이 생기면 상대방은 기록의 내용보다 먼저 ‘그 기록이 나중에 만들어졌거나 수정된 것 아니냐’를 문제 삼는다. 따라서 기록이 언제 존재했는지, 그리고 그 이후 바뀌지 않았는지를 객관적으로 보여 줄 수 있어야 한다.

■ 중요 코드의 증적 패키지 구성

모든 커밋에 같은 수준의 관리를 적용할 필요는 없다. 중요도가 높은 코드는 릴리스나 배포 단위로 AI 생성 결과, 개발자 수정 내역, 라이선스·보안 검토 결과, 커밋·배포 기록을 하나의 ‘증적 패키지’로 묶고, 이를 PDF 형식의 증적 보고서로 만들어 보존하는 방식이 현실적이다. 기존 개발 도구를 유지하면서 증적 수집·PDF 보고서 생성·보관 절차를 연계하는 방안을 검토할 수 있다. 실제 연동 범위와 추가 개발 여부는 환경에 따라 설계해야 하며, PDF 보고서는 감사·분쟁 시 사람이 바로 읽고 확인하는 자료로 활용할 수 있다.

다만 PDF는 코드를 사람이 읽기 쉽게 옮긴 사본이다. 보고서만으로는 그것이 실제 저장소의 어떤 코드에 대한 기록인지가 드러나지 않는다. 따라서 증적 보고서에는 코드와의 연결 고리가 되는 다음 정보를 함께 담아야 한다.

첫째, 대상 저장소·브랜치·커밋 ID·릴리스 버전 등 코드 식별 정보다. 둘째, 변경된 각 소스 파일의 해시값 또는 릴리스 소스 아카이브 전체의 해시값이다. 실제 배포 결과까지 연결하려면 빌드 식별자·결과물 해시·배포 기록도 함께 남긴다. 셋째, AI 생성 원본과 개발자 수정본을 비교한 수정 내역이다. 넷째, 수정자, 검토 의견, 라이선스·보안 검토 결과, 반영을 결정한 개발자와 판단 근거, 배포 일시 등 사람의 관여 기록이다.

이렇게 만든 증적 보고서에 시점확인을 적용하면 두 단계로 검증할 수 있다. 먼저 타임스탬프로 보고서가 특정 시점에 그 내용 그대로 존재했고 이후 변경되지 않았음을 확인한다. 이어서 보존해 둔 저장소의 실제 소스 파일 해시를 다시 계산해 보고서에 기재된 값과 대조하면, 보고서와 코드가 같은 대상이라는 점까지 확인할 수 있다. 이 대조를 위해 원본 저장소나 소스 아카이브는 별도로 보존해야 한다.

■ Magic TSA AR의 시점·무결성 검증과 한계

드림시큐리티의 Magic TSA AR은 타임스탬프 토큰을 이용해 전자문서의 위·변조 여부를 검증하는 전자문서 진본확인 솔루션이다. 정부전자문서진본확인센터(GTSA)나 인증기관의 시점확인 시스템과 연계해 타임스탬프 발급을 요청하고, 발급받은 토큰을 PDF 문서에 삽입한다. 검증 단계에서는 문서에서 추출한 토큰의 해시값과 현재 문서의 해시값을 비교하고, 토큰의 전자서명과 TSA 인증서 유효성까지 확인해 문서의 위·변조 여부를 판별한다.

개발 증적 관리에 적용하면 흐름은 다음과 같다. 배포 시점에 앞서 설명한 PDF 증적 보고서를 생성하고, Magic TSA AR로 타임스탬프를 적용해 보관한다. 이후 분쟁·감사·실사 과정에서는 타임스탬프 발급 시점에 보고서의 보호 대상 내용이 존재했다는 근거와 검증 시 그 내용의 무결성을 확인할 수 있다. 실제 배포 시점과의 관계는 배포 기록을 연결해 확인한다.

이후 분쟁·감사·실사 과정에서는 타임스탬프 발급 시점에 보고서의 보호 대상 내용이 존재했다는 근거와 검증 시 그 내용의 무결성을 확인할 수 있다. 실제 배포 시점과의 관계는 배포 기록을 연결해 확인한다. 장기 보관이 필요하면 전자서명 장기검증 솔루션(Magic LTVS)과 연계해 인증서 경로·폐지 상태·타임스탬프 등 검증자료를 적시에 수집·보존하고, 장기검증 정책에 따라 갱신한다.

다만 역할의 범위를 정확히 이해해야 한다. TSA AR은 저작권자가 누구인지, 기록 내용이 사실인지, 검토가 실제로 충실히 이루어졌는지를 직접 보장하는 기술이 아니다. 이 기술이 제공하는 것은 권리와 책임을 판단하는 데 필요한 기록이 특정 시점에 존재했다는 근거와, 이후 변경되지 않았다는 무결성의 근거다. 따라서 기록을 자동 수집하고, 권한 분리·접근기록·백업·변경 제한 보관으로 개발자의 임의 변경·삭제를 제한하는 체계와 함께 운영해야 효과가 커진다.

[표 3] 개발 증적 관리에서 TSA AR의 역할 범위

5. 기업의 AI 생성 코드 관리 체크리스트: 권리·라이선스·검토 기록 점검

지금까지 살펴본 내용을 기업이 바로 점검할 수 있는 항목으로 정리하면 다음과 같다. 모든 코드에 한꺼번에 적용하기보다 핵심 IP, 상용 제품, 고객사 공급 코드처럼 중요도가 높은 코드부터 단계적으로 적용하는 것이 현실적이다.

[표 4] AI 생성 코드 관리 체크리스트

■ AI 생성 코드 관리의 세 가지 원칙

첫째, 세 가지 쟁점을 섞지 않는다. 보호받을 수 있는지, 회사 소유로 인정되는지, 타인의 권리를 침해하지 않는지는 각각 다른 기준으로 판단해야 한다. 둘째, 사람의 관여를 ‘했다’는 사실이 아니라 ‘무엇을 했는지’로 남긴다. 무엇을 수정하고, 무엇을 검토했으며, 누가 무엇을 근거로 반영을 결정했는지가 기록되어야 판단 재료가 된다. 셋째, 기록은 최종 코드와 연결하고, 중요한 기록에는 무결성과 시점 근거를 더한다. 나중에 바뀔 수 있는 기록은 결정적인 순간에 힘을 잃는다.

■ 결론: 권리 검토와 개발 증적 관리의 병행

AI는 코드를 빠르게 만들어 주지만, 그 코드가 회사의 자산이라는 근거까지 만들어 주지는 않는다. AI가 만든 코드를 기업의 자산으로 활용하려면, AI 생성 결과에 사람이 어떻게 관여해 무엇을 수정·검토하고 반영했는지에 대한 신뢰할 수 있는 기록도 함께 관리해야 한다. 코드의 권리와 라이선스 조건을 확인하고, 그 판단을 뒷받침할 개발 기록의 신뢰성을 함께 확보하는 것이 AI 코딩 시대의 코드 자산 관리 원칙이다.

6. 참고자료

[4] U.S. Copyright Office, “Copyright and Artificial Intelligence, Part 2: Copyrightability”, 2025. 1.

[5] Thaler v. Perlmutter (D.C. Cir. 2025. 3. 18.); 미국 연방대법원 상고 불허(No. 25-449, 2026. 3. 2.), SCOTUSblog, https://www.scotusblog.com/cases/thaler-v-perlmutter/

[6] Doe v. GitHub, Inc., No. 24-7700 (9th Cir. 2026. 9. 16.), https://cdn.ca9.uscourts.gov/datastore/opinions/2026/09/16/24-7700.pdf

[7] Haynes Boone, “AI Legal News – Ninth Circuit Rejects DMCA Section 1202(b) Theory Against Copilot Output in Doe v. GitHub”, 2026. 9. 18.

[8] 드림시큐리티, Magic TSA AR 전자문서 진본확인 솔루션, https://www.dreamsecurity.com/product/document/tsa-ar

[9] 드림시큐리티, Magic TSA 시점확인 솔루션, https://www.dreamsecurity.com/product/pki/tsa

[10] 드림시큐리티, Magic LTVS 전자서명 장기검증 솔루션, https://www.dreamsecurity.com/product/pki/ltvs

[11] IETF, RFC 3161 “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)”, 2001.