AI And Code Ownership: Who Is Responsible For Generated Code?
Imagine your AI assistant just produced 200 lines of code. Legally, you may not own a single line of...
개요 #
AI 어시스턴트가 방금 200줄짜리 코드를 뽑아냈다고 하자. 법적으로 그 코드의 저작권은 당신 것이 아닐 수 있다. 그런데 그 코드가 배포된 뒤 터지는 버그의 책임은 여전히 당신에게 있다. 이 두 문장 사이의 간극이 요즘 개발 현장이 놓치고 있는 지점이다.
코드를 만든 도구는 소송 대상이 될 수 없다. 모델에게 책임을 물을 수도 없다. 벤더 계약서는 이미, 대부분의 개발자가 읽지 않는 문구로, 책임이 아래로 흘러 Tab 키를 누른 사람에게 도달한다고 못 박아 두었다.
흥미로운 건 이 간극이 존재한다는 사실이 아니라, 엔지니어링 조직 대부분이 이 간극을 없는 것처럼 다룬다는 점이다. 지난 2년간 생산성은 실컷 자축했지만, 그 속도가 저작권 분쟁이나 컴플라이언스 감사, 운영 장애와 부딪혔을 때 무엇을 해야 하는지는 훨씬 덜 고민했다. 법원이 실제로 무엇을 판단했는지, 당신이 쓰는 툴의 약관이 실제로 무엇을 말하는지, 법적 절벽이 어디에 있는지, 그리고 AI를 금지하지도 무시하지도 않으면서 제정신인 팀이 이 문제를 어떻게 다루는지 하나씩 뜯어보자.
아무도 서명하지 않은 인수인계 #
소프트웨어 소유권은 원래 답이 정해진 질문이었다. 당신이 코드를 짰고, 고용주가 그 대가를 지불했고, 고용 계약이 저작권을 회사로 넘겼고, 회사가 원하는 라이선스로 배포했다. 세 당사자(당신, 고용주, 사용자)의 경계선은 깔끔했다. 뭔가 망가지면 사용자가 회사에 항의하고, 회사가 커밋 기록을 들여다보고, 누군가 1:1 미팅에서 조용한 대화를 나눴다.
AI 어시스턴트는 이 그림에 네 번째 당사자를 슬쩍 끼워 넣는다. 그런데 이 당사자의 계약서는 나머지 셋과 전혀 닮지 않았다. 모델은 당신의 고용 계약에 서명하지 않았다. 벤더는 당신의 릴리스 프로세스에 속하지 않는다. 벤더의 EULA는 고용 계약이 아니라 면책 조항의 형태를 하고 있다. 당신은 제안을 받고, 제안을 취하고, 그와 함께 딸려오는 모든 것도 함께 떠안는다. 버그, 라이선스 의무, 보안 구멍, 그리고 훗날 어떤 규제 당국이 "이 제안이 어떻게 나왔는지" 들여다볼지 모를 위험까지.
이 인수인계는 조용히 일어난다. IDE 어딘가에 "이 자동완성에 대한 법적 책임을 수락합니다" 라는 체크박스가 뜨지 않는다. 그냥 Tab을 누를 뿐이다. 인터페이스 자체가 자동완성처럼 느껴지도록 설계됐고, 개발자 대부분은 자동완성의 심상을 그대로 적용한다. 에디터가 타이핑을 도와줄 뿐, 코드는 여전히 내 것이고, 코드베이스에 대한 내 소유권은 변하지 않았다는 심상. 이 심상은 어떤 질문을 던지느냐에 따라 거의 맞기도 하고, 거의 완전히 틀리기도 한다.
법원은 실제로 무엇을 판단했나 #
지금 미국의 법적 지형 한가운데에는 두 가지가 놓여 있고, 개발자들은 이 둘을 들을 때마다 놀란다.
첫째, 미국에서 저작권 보호는 인간 저작자를 요구한다. 새로운 규칙이 아니다. 2018년 원숭이가 자기 셀카에 저작권을 주장할 수 없다고 판단했던 바로 그 규칙이다. 이 규칙은 인간의 실질적 개입 없이 AI가 생성한 이미지를 둘러싼 Thaler 대 Perlmutter 사건에서 다시 한번 시험대에 올랐다. 2025년 3월, D.C. 연방항소법원은 하급심 판결을 확정했다. 1976년 저작권법은 "모든 보호 대상 저작물이 최초 단계에서 인간에 의해 저작될 것"을 요구한다는 것이다. 인간 저작자가 없으면 저작권도 없다. 그 결과물은 퍼블릭 도메인에 놓인다.
둘째, 개발자가 실제로 발 딛고 사는 지점이다. 미국 저작권청은 2024년과 2025년 초에 걸쳐, 인간이 개입한 AI 보조 작업의 경계선을 그으려 했다. 2025년 1월, 저작권청은 인간이 "충분한 표현적 요소"를 기여했을 때만 AI 결과물이 저작권 보호 대상이 된다는 가이드라인을 냈다. 프롬프트만으로는, 아무리 정교하고 반복적인 프롬프트라도 부족하다. 보고서에 인용된 한 의견은 개발자들이 예상보다 더 뜨끔하게 받아들인 비유를 꺼냈다. 반복적인 프롬프팅은 룰렛을 돌리는 것과 같다는 것이다. 인간이 선택은 했지만, 저작자로 인정될 만큼 충분히 구체적으로 결과물의 표현적 요소를 통제하지는 못했다.
이 비유가 그 주변의 표현보다 더 중요하다. 저작권 관점에서 "Tab으로 수락" 은 룰렛을 돌리는 행위다. 반면 "Tab으로 수락한 뒤 네 줄을 고쳐 쓰고, 함수를 재구성하고, 가드 절을 추가하고, 이미 설계해 둔 클래스에 통합하는 것" 은 다른 종류의 행위다. 여기서부터 인간의 기여가 저작권청이 찾는 표현적 통제에 가까워지기 시작한다.
실무적 여파는 이렇다. AI 툴에서 거의 손대지 않고 나온 코드는, 지난주 시니어 엔지니어가 직접 짠 코드처럼 회사의 자산이 아닐 수 있다. 훔친 것은 아니지만, 회사가 통상적인 권리 행사 수단을 갖출 만큼 저작권을 확보한 것도 아니다. 회사는 그 코드를 베낀 사람을 상대로 소송할 수 없다. 방어 가능한 자산으로 주장할 수도 없다. 배포하고 출시하고 수정할 수는 있지만, 그 코드를 둘러싼 법적 해자는 회사가 생각하는 것보다 얕다.
국경을 넘으면 그림이 달라진다. 영국은 1988년 저작권·디자인·특허법 제9조 3항을 1980년대 후반부터 두고 있는데, 이 조항은 "컴퓨터 생성 저작물"을 명시적으로 다루며 저작권을 "저작물 창작에 필요한 조치를 취한 자"에게 부여한다. 인도도 비슷한 접근을 따른다. EU는 뒤에서 다시 다룰 AI법을 통해 더 야심 찬 재정의를 진행 중이다. 요점은 지금 단일한 전 지구적 정답이 없다는 것이다. 같은 주에 같은 모델로 짠 코드라도, 런던 사무실에서 나온 코드가 샌프란시스코에서 나온 코드보다 더 명확한 소유권 이야기를 가질 수 있다.
당신이 쓰는 툴의 약관은 실제로 무엇을 말하나 #
GitHub Copilot 제품별 약관에서 대부분의 무게를 짊어지는 문장, 그러면서도 AI 도입 회의에서 아무도 인용하지 않는 문장은 이것이다.
"귀하는 코드에 대한 모든 책임을 보유합니다. 여기에는 귀하가 코드에 포함하거나 코드 개발을 위해 참조한 제안(Suggestions)이 포함됩니다."
이 문장은 두 가지 일을 동시에 한다. 하나는 당신에게 무언가를 건넨다. GitHub는 제안의 소유권을 주장하지 않는다고 밝히므로, 그 제안이 당신의 코드베이스에 대한 경쟁적 권리 주장으로 등장하지 않는다. 다른 하나는 또 다른 것을 건넨다. 그 제안에 딸려오는 모든 법적 위험이다. 학습 데이터에서 비롯된 오픈소스 라이선스 의무. 비슷한 코드를 짠 다른 개발자의 저작권 주장. 제안 자체에 담긴 결함. 벤더 약관은 결과물 사용에 제3자 라이선스가 필요한지 판단하고 그 라이선스를 준수할 책임이 당신에게 있다고 명시한다.
GitHub 고객 계약서를 개발자가 README를 읽듯 — 설치 방법만 훑어보며 — 읽으면 이 문장을 놓친다. 변호사가 읽듯 읽으면, 이 문장이 문서 전체다.
이런 형태는 Copilot만의 것이 아니다. 거의 모든 AI 코딩 어시스턴트 약관에 같은 패턴이 나타난다. 벤더는 결과물의 소유권을 부인하고, 고객은 결과물에 대한 책임을 수락한다. 같은 패턴이 반복되는 이유는, 그게 벤더가 사업을 굴릴 수 있는 유일한 형태이기 때문이다. 반대의 경우를 상상해 보자. 벤더가 모든 제안이 라이선스 의무에서 깨끗하고, 버그가 없고, 저작권 이의로부터 자유롭다고 보증하는 경우다. GitHub의 전체 공개 코드로 학습한 모델을 두고 벤더가 그런 약속을 할 수는 없다. 그래서 계약은 위험을 유일하게 평가할 수 있는 당사자에게 떠넘긴다. 코드를 머지하는 사람이다.
모델은 당신 코드베이스의 라이선스 조건을 읽지 못한다. 벤더는 당신 업계가 어떤 규제 당국에 답해야 하는지 모른다. IDE는 당신이 작업 중인 프로젝트가 취미 사이트인지 결제 처리 시스템인지 모른다. 책임을 고정할 수 있는 유일한 곳은 머지 버튼이 있는 자리다.
온보딩에서 아무도 말해주지 않는 면책의 구멍 #
여기서 계약은 불편해지고, 대부분의 엔지니어링 조직도가 이 지점에 사각지대를 갖는다.
GitHub는 제안에 대한 IP 면책을 제공한다. 단, Business나 Enterprise 플랜을 쓸 때만이다. Copilot이 누군가의 코드 조각을 재현해 저작권 침해로 소송을 당하면, Microsoft가 나서서 당신을 방어하고 고객 저작권 서약(Customer Copyright Commitment)에 따라 배상한다. 업계 전반이 같은 패턴이다. 주요 AI 코딩 툴 대부분이 엔터프라이즈 등급에서 어떤 형태로든 면책을 제공한다.
Individual 플랜을 쓰면 이 중 아무것도 적용되지 않는다. 같은 모델, 같은 제안, 같은 위험 표면에 법적 방어막은 0이다. 훗날 어떤 법원이 Copilot이 당신에게 제안한 조각이 누군가의 GPL 라이선스 코드를 실질적으로 재현한 것이라고 판단하면, 문제를 떠안는 건 개인인 당신이다.
이게 변호사 사무실 밖에서도 중요한 이유가 있다. 상당수의 상용 소프트웨어가 여전히, 엔지니어들이 개인 Copilot 구독을 쓰는 팀에서 배포된다. 회사가 아직 표준화하지 않았거나, 누군가 회사가 엔터프라이즈 등급을 도입하기 반년 전에 가입했거나, 개인 계정 설정이 더 마음에 들어서다. 그 엔지니어가 만든 코드는 회사 코드베이스로 흘러 들어가는데, 회사가 엔터프라이즈 비용을 내고 있으니 당연히 확보했다고 여기는 면책은, 실제로는 개인 구독을 통해 나온 제안을 커버하지 못한다.
엔지니어링 리더가 이걸 감사하는 경우는 거의 없다. 구매팀은 엔터프라이즈 계약이 전부를 커버한다고 생각한다. 개발자는 계약이 어떤 구독에서 나온 제안인지에 선을 긋는다는 걸 모른다. CISO는 소송이 떨어져야만 알게 된다.
깔끔한 책임 이야기를 만들려면 모든 IDE, 모든 개발자 장비, 모든 공유 환경이 면책 등급에서 돌아가야 한다. "우리는 엔터프라이즈를 샀다" 는 "우리 저장소에 닿는 모든 제안이 엔터프라이즈에서 나왔다" 와 같은 말이 아니다.
65-렉심 필터와 그것이 잡지 못하는 것 #
GitHub 안전 문서를 읽으면 중복 탐지 필터(duplicate detection filter)라는 기능이 나온다. 이 필터는 제안을 GitHub의 공개 코드와 대조해, 제안이 약 65렉심(대략 150자, 밀도 높은 코드 한두 문단 길이) 이상의 코드 구간을 포함하고 공개 코드와 충분히 가깝게 일치하면 그 제안을 억제한다. 관리자는 엔터프라이즈 수준에서 이 필터를 켤 수 있고, 웬만한 도입 가이드라인은 이걸 켜 두라고 말한다.
이 필터는 팀이 Copilot 라이선스 위험을 이야기할 때 가장 자주 인용되는 완화책이다. 동시에 "기능이 존재한다" 와 "기능이 문제를 해결한다" 사이의 간극을 보여주는 좋은 예이기도 하다.
65렉심이라는 임계값은 자의적이지 않다. 재현율(recall)과 유용성 사이의 절충이다. 공개 코드와 세 토큰만 일치해도 억제하는 필터라면 거의 모든 Copilot 제안을 억제하게 된다. 세 토큰짜리 시퀀스는 거의 모든 오픈소스 프로젝트에 등장하기 때문이다. 그래서 임계값은 그보다 훨씬 위, 우연한 유사가 아니라 의도적 유사일 가능성이 높은 구간에 놓인다. 합리적인 설계다. 대가는, 그 임계값 아래의 모든 것은 필터 없이 흘러간다는 점이다.
GPL 라이선스 저장소의 조각과 정확히 일치하는 30렉심짜리 함수 본문이 당신 코드베이스에 안착해도 필터는 보지 못한다. 50렉심짜리 관용구, 흔한 알고리즘 구현, 파서 조각, 직렬화 헬퍼가 수십 개 저장소와 동일한 채로 선을 넘지 않고 안착할 수 있다. 필터는 전부를 잡는다고 주장하지 않는다. 저작권 주장을 뒷받침할 가능성이 가장 큰 장문의 근접 중복을 잡는다고 주장할 뿐이다. 단문 코드는 법 자체가 "실질적으로 유사하다"의 의미를 아직 정하지 못한 회색 지대에 산다.
여기서 당신은 완벽한 판단이 아니라 방어 가능한 판단을 내리게 된다. 필터는 도움이 된다. 완전한 해법으로 취급하는 건 도움이 안 된다. 받은편지함의 스팸 필터처럼 다루는 게 맞다. 유용하고, 종종 조용히 정확하지만, 모르는 사람이 보낸 첨부파일을 열지 않는 습관을 대체하지는 못한다.
규제 당국은 누가 썼는지에 관심이 없다 #
미국의 저작권 논의는 소유권에 초점을 맞춘다. 유럽의 규제 논의는 결과에 대한 책임에 초점을 맞추고, 그 프레이밍은 결이 확실히 다르다.
세 건의 EU 법안이 일부 실무자들이 "컴플라이언스 삼위일체(Compliance Trinity)"라 부르는 것으로 수렴하고 있다. AI법(AI Act), 사이버복원력법(CRA), 제조물책임지침(PLD)이다. 각각은 다른 각도에서 AI에 접근한다. AI법은 위험 등급에 따라 AI 시스템을 규제하고, CRA는 연결된 제품에 사이버보안 의무를 부과하며, PLD는 소프트웨어를 포함한 결함 제품에 책임을 붙인다. 셋 다 공통 전제를 공유한다. 규제 당국은 당신 코드를 인간이 썼는지, AI 툴이 썼는지, 외주가 썼는지, 훈련된 흰족제비 몇 마리가 썼는지 신경 쓰지 않는다. 시장에 도달하는 제품에 관심이 있을 뿐이다.
2026년 8월 2일이 개발자 대부분이 듣게 될 이정표다. AI법의 실질적 의무 상당수가 발효되는 날로, AI 생성 콘텐츠에 대한 투명성 요건과 능동적 집행 권한이 포함된다. 평범한 개발 보조 목적의 AI 사용은 그 자체만으로 시스템을 고위험 범주로 끌어들이지는 않지만, 근로자 평가나 핵심 구성요소 생성 같은 데 쓰이는 AI는 얼마든지 그럴 수 있다. 분류는 그 시스템이 세상에서 무엇을 하느냐에 달려 있지, 어떤 툴이 코드를 쓰도록 도왔느냐에 달려 있지 않다.
이게 함의하는 더 어려운 변화는 문화적인 것이다. AI 어시스턴트 이전에는 신중하게 짰는가라는 질문과 제품이 안전한가라는 질문이 대략 같은 것을 가리켰다. 코드를 짠 사람이 그 코드에 책임지는 사람이기도 했으니까. AI 어시스턴트가 끼면 두 질문이 어긋날 수 있다. diff를 검토한 모두가 꼼꼼히 봤다고 맹세하더라도 제품은 안전하지 않을 수 있다. 규제 당국은 "AI가 제안했다"를 "외주가 짰다"만큼도 설명으로 받아주지 않는다. 당신이 배포했으면, 당신 책임이다.
받아들이고 나면 깔끔한 프레이밍이다. 불편함은 AI 툴이 일종의 분산된 책임을 딸려 온다는, 즉 모델을 학습시킨 벤더가 책임을 나눠 진다는 절반쯤 형성된 기대에서 온다. 벤더는 그러지 않는다. 계약상 명시적으로 그러지 않는다. 규제 당국도 그런 종류의 공유 책임을 발명하기를 정중히 사양했다.
아무도 경고하지 않는 문화적 문제 #
법 조문 바깥에는 계약과 아무 상관 없이 엔지니어링 팀 내부의 책임 의식을 조용히 갉아먹는 더 부드러운 패턴이 있다.
AI 보조 개발을 연구하는 이들은 시니어 엔지니어 대부분이 이미 체감하는 무언가를 기록하기 시작했다. AI 어시스턴트에서 나온 코드는 사람이 직접 친 코드보다 덜 꼼꼼히 리뷰되는 경향이 있다는 것이다. 리뷰어는 그 코드에 시간을 덜 쓴다. 지적을 덜 한다. 컴파일되고 그럴듯해 보이는 함수를 그냥 통과시킬 확률이 높다. 일부는 피로 때문이다. 타이핑이라는, 산출량을 조여주던 제약이 사라진 지금, 리뷰할 코드가 그 어느 때보다 많아졌으니까. 일부는 암묵적 신뢰 때문이다. 모델은 살아 있는 어떤 리뷰어보다 많은 코드를 읽었으니 그 결과물에 무의식적 권위가 살짝 얹힌다. 일부는 그저 인터페이스 설계 때문이다. 수락이 기본값이고 거절이 마찰인 구조다.
문제는 이 반응들 각각이 그 자체로 비합리적이라는 게 아니다. 이것들이 덜 책임지는 방향으로 겹쳐 쌓인다는 것이다. diff는 두 배로 길어지고, 리뷰는 절반으로 소홀해지고, 평소라면 방어적 null 체크에 날카로운 질문을 던졌을 사람이 다음 세 개의 제안을 스크롤하느라 바쁘다. 머지되는 코드 한 줄당 인간의 주의 단위가 떨어지고, 그와 함께 모델이 저지른 줄도 몰랐던 버그나 라이선스 문제, 미묘한 인가 실수를 잡아낼 확률도 떨어진다.
이건 AI 툴에 반대하는 논거가 아니다. 대부분의 팀이 아직 대시보드에 그리지 않은 빠진 한 줄이다. 코드를 더 많이 만들고 있다면, 그에 비례해 더 꼼꼼히 리뷰하고 있는가, 아니면 물량에 떠밀려 리뷰를 느슨하게 하고 있는가? 아무도 이 질문을 소리 내어 하지 않는다. 속도를 늦출 테니까. 그리고 위에서 다룬 어떤 규제 틀도 그 답으로부터 당신을 구해주지 않는다.
작동하는 책임 모델은 어떻게 생겼나 #
이 문제 중 어느 것도 슬랙 공지 하나로 풀리지 않는다. 정책 문서로도 풀리지 않는다. 그 정책이 코드가 저장소에 안착하는 방식을 실제로 바꾸지 않는 한. 이 문제를 잘 다루는 팀은 네 가지 평범한 일을 하는데, 하나도 기발하지 않다.
등급 소유권을 지루하게 만든다. AI 어시스턴트를 쓰는 모든 개발자, 모든 공유 환경, 모든 CI 러너가 면책 등급에 있다. 회사 업무에 개인 구독으로 빠져나갈 뒷문은 없다. 대부분의 간극을 한 번에 닫는, 구매 수준의 지루한 결정이다.
중복 필터링을 기본값으로, 검증 가능하게 켠다. 필터는 관리 콘솔에서 켜져 있고, SSO 강제처럼 주기적 보안 점검의 일부다. 어느 화요일에 누가 켰을지도 모르는 설정이 아니라, 감사되는 통제 장치다.
AI 생성 코드를 코드 리뷰에서 서드파티 의존성처럼 다룬다. 모델에서 나온 새 코드는, 2014년에 시니어 엔지니어가 Stack Overflow 답변을 복사·붙여넣기한 것을 다루듯 다뤄진다. 묻는다. 이게 뭘 하는지 이해하는가, 이게 어떤 라이선스 형태에서 왔는지 아는가, 모델이 옆에서 가리켜주지 않아도 여기에 내 이름을 걸 수 있는가? 그 질문이 윤리적·법적 장치 전체를, 리뷰어가 실제로 내면화할 수 있는 한 문장으로 압축한 것이다.
책임자의 이름을 붙인다. 모든 PR에는 그 안의 코드에 책임지는 사람이 있다. 모델이 아니다. 벤더가 아니다. "팀"도 아니다. 이름이 있는 한 사람, 코드가 망가지면 전화를 받을 사람이다. AI 비중이 높은 PR에서 그 사람이 누구인지 기억하기 어려운 툴링이라면, 그건 고칠 가치가 있는 프로세스 문제다. 위의 모든 틀이 결국 끝에 이름이 있어야만 작동하기 때문이다.
참고 이 중 어느 것도 법무팀이나 컴플라이언스 담당자를 필요로 하지 않는다. 앞의 세 단계는 관리 콘솔 설정과 리뷰 체크리스트 한 문장이다. 네 번째는 좋은 팀이 사람이 짠 코드에 이미 갖고 있는 문화적 규범이다. AI가 새로 들여온 단 하나는, 물량이 늘었으니 이 중 어느 것도 건너뛸 수 없다는 사실이다.
전체를 붙드는 한 문장 #
이 글에서 하나만 기억한다면 이걸로 하자. 모든 AI 제안은, 인터넷의 모든 오픈소스 프로젝트를 읽었고, 당신이 인터뷰할 방법이 전혀 없으며, 당신의 계약이 명시적으로 책임 사슬 바깥에 놓아둔 익명의 서드파티가 보낸 기여다.
이건 AI 어시스턴트 사용을 멈출 이유가 아니다. 속도를 늦출 이유조차 아니다. 이건 그 관계의 실제 형태이고, 소프트웨어 엔지니어링의 마찰이 이 형태로 계속 되돌아오는 건 그 형태가 저절로 녹아 사라지지 않기 때문이다. 법원이 이쪽으로 수렴하고 있다. 벤더는 이미 이 형태를 중심으로 계약을 지었다. 규제 당국은 곧 이걸 집행할 참이다.
굳이 좋은 소식을 꼽자면, 답은 애초에 모델 안에 있던 적이 없다는 것이다. 답은 이미 가장 지루하고 가장 엄격해야 했던 워크플로의 그 부분, 인간이 diff를 보고 머지할지 결정하는 부분에 있다. 그 부분이 지금보다 더 중요했던 적은 없다. 그리고 소유권 문제 전체를 다루기 위해 당신 팀이 할 수 있는 가장 값싼 일은, 제안이 분당 두 번씩 쏟아지기 시작하기 전과 똑같은 정성으로 그 부분이 여전히 일어나도록 만드는 것이다.
머지 커밋을 쓴 건 당신이다. 그건 당신 것이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.