당신의 AI 어시스턴트가 방금 200줄의 코드를 생성했다고 상상해 보십시오. 법적으로 당신은 그 코드의 단 한 줄도 소유하지 못할 수도 있지만, 법적으로는 그 코드가 배포하는 모든 버그에 대해 여전히 책임을 져야 합니다. 여기 이 두 문장 사이의 간극이 있으며, 이것이 당신이 내일 머지(merge)할 코드에 무엇을 의미하는지 설명합니다.

그것이 바로 이 주제 전체가 존재하는 간극입니다. 코드를 생성한 도구는 고소될 수 없습니다. 모델은 책임을 질 수 없습니다. 벤더(vendor)의 계약서에는 대부분의 개발자가 읽지 않는 언어로, 책임이 (Tab) 키를 누른 인간에게로 흘러간다는 점이 이미 명확하게 명시되어 있습니다.

흥미로운 점은 이러한 간극이 존재한다는 사실이 아닙니다. 엔지니어링 분야의 거의 누구도 이를 그에 걸맞게 다루지 않는다는 점입니다. 우리는 지난 2년 동안 생산성을 축하하는 데 시간을 보냈으며, 그 속도가 저작권 주장, 컴플라이언스 감사(compliance audit), 또는 운영 장애(production incident)와 마주했을 때 어떻게 해야 할지를 파악하는 데는 훨씬 적은 시간을 할애했습니다. 하나씩 파헤쳐 봅시다. 법원이 실제로 무엇이라고 말했는지, 당신의 도구 계약서가 실제로 무엇이라고 말하는지, 법적 절벽은 어디에 있는지, 그리고 제정신인 엔지니어링 팀이 AI를 금지하거나 질문이 존재하지 않는 척하지 않고 이 모든 상황을 어떻게 다루는지 말입니다.

아무도 서명하지 않은 인수인계

소프트웨어 소유권은 과거에 해결된 문제였습니다. 당신이 코드를 작성하면, 고용주가 그 코드를 작성하도록 비용을 지불하고, 고용 계약에 따라 저작권(copyright)이 그들에게 할당되며, 회사는 그들이 선호하는 라이선스에 따라 이를 배포했습니다. 세 당사자(당신, 고용주, 사용자)와 그들 사이의 경계는 명확했습니다. 무언가 고장 나면 사용자는 회사에 불만을 제기하고, 회사는 커밋 히스토리(commit history)를 확인하며, 누군가는 일대일 면담을 통해 조용히 주의를 듣게 되었습니다.

AI 어시스턴트(AI assistants)는 그 그림 속에 제4의 당사자를 슬며시 끼워 넣으며, 이 당사자와의 계약은 다른 계약들과는 전혀 다른 모습을 띱니다. 모델은 귀하의 고용 계약(employment agreement)에 서명하지 않았습니다. 벤더(vendor)는 귀하의 릴리스 프로세스(release process)의 일부가 아닙니다. 그들의 최종 사용자 라이선스 계약(EULA)은 채용 계약의 형태가 아니라, 면책 조항(disclaimer)의 형태를 띠고 있습니다. 귀하는 제안을 받고, 그 제안을 유지하며, 그 제안에 부수되는 모든 것들—버그(bugs), 라이선스 의무(license obligations), 보안 취약점(security holes), 그리고 향후 규제 기관이 그 제안이 어떻게 생성되었는지 조사하기로 결정할 그 무엇이든—도 함께 떠안게 됩니다.

이러한 인계(handoff)는 조용히 이루어집니다. 귀하의 IDE에는 _"이 완성된 코드에 대한 법적 책임을 수락합니다."_라고 적힌 체크박스가 없습니다. 그저 Tab 키를 누를 뿐입니다. 인터페이스는 자동 완성(autocomplete)처럼 느껴지도록 설계되었으며, 대부분의 개발자는 자동 완성에 대한 멘탈 모델(mental model)을 그대로 확장하여 적용합니다. 즉, 에디터가 내가 더 빠르게 타이핑하도록 도와주고 있으며, 코드는 여전히 나의 것이고, 코드베이스에 대한 나의 소유권은 변함없다고 생각하는 것입니다. 그 멘탈 모델은 어떤 질문을 던지느냐에 따라 거의 맞을 수도 있고, 거의 완전히 틀릴 수도 있습니다.

법원이 실제로 판결한 내용

현재 미국의 법적 상황의 핵심에는 두 가지 요소가 자리 잡고 있으며, 개발자들은 이 두 가지를 들으면 모두 놀라곤 합니다.

첫 번째는, 미국에서 저작권 보호(copyright protection)를 받으려면 인간 저자(human author)가 필요하다는 점입니다. 이는 새로운 규칙이 아닙니다. 2018년에 원숭이가 자신의 셀카에 대해 저작권을 주장할 수 없다고 판결했던 것과 동일한 규칙이지만, 유의미한 인간의 입력 없이 AI 시스템에 의해 생성된 이미지에 관한 사건인 _Thaler v. Perlmutter_를 통해 새롭게 스트레스 테스트(stress-tested)를 거쳤습니다. 2025년 3월, D.C. 연방 항소법원(D.C. Circuit)은 하급심의 판결을 확정했습니다. 1976년 저작권법(Copyright Act of 1976)은 "모든 적격 저작물이 일차적으로 인간에 의해 저술될 것을 요구한다"는 것입니다. 인간 저자가 없다면 저작권도 없습니다. 결과물은 퍼블릭 도메인(public domain)에 속하게 됩니다.

두 번째는 개발자들이 실제로 마주하는 영역입니다. 미국 저작권청(U.S. Copyright Office)은 2024년과 2025년 초에 걸쳐 인간이 개입하는 AI 보조 작업(AI-assisted work)에 대한 경계선을 긋기 위해 노력했습니다. 2025년 1월, 저작권청은 AI 출력물이 인간이 "충분한 표현적 요소(sufficient expressive elements)"를 기여했을 때만 저작권 보호 대상이 될 수 있다는 지침을 발표했습니다. 프롬프팅(Prompting)만으로는, 그것이 아무리 정교하고 반복적인 프롬프팅이라 할지라도 충분하지 않습니다. 저작권청 보고서에 인용된 한 의견은 개발자들에게 예상보다 더 큰 충격을 준 비유를 사용했습니다. 반복적인 프롬프팅은 마치 룰렛 휠을 돌리는 것과 같다는 것입니다. 인간이 선택은 했지만, 저자로 간주될 만큼의 구체성을 가지고 출력물의 표현적 요소를 제어하지는 못했다는 의미입니다.

이 비유는 주변의 문구보다 더 중요합니다. "Tab to accept(탭하여 수락)"는 저작권 관점에서 보면 휠을 돌리는 것과 같습니다. 반면 "Tab to accept한 후, 네 줄을 다시 쓰고, 함수를 재구성하며, 가드 절(guard clause)을 추가하고, 이미 설계된 클래스에 통합하라"는 것은 다른 문제입니다. 바로 그 지점에서 인간의 기여가 저작권청이 요구하는 수준의 표현적 제어(expressive control)가 되기 시작합니다.

실질적인 여파는 다음과 같습니다. AI 도구에서 거의 수정 없이 나온 코드는, 지난주 시니어 엔지니어가 작성한 코드와 같은 방식으로 귀사의 자산이 되지 못할 수도 있습니다. 그것이 "도난"당한 것은 아니지만, 고용주가 통상적인 법적 집행 옵션을 가질 수 있는 방식으로 저작권 보호를 받을 수도 없습니다. 그들은 코드를 복제한 누군가를 고소할 수 없습니다. 방어 가능한 자산이라고 주장할 수도 없습니다. 코드를 게시하고, 배포하고, 수정할 수는 있지만, 그 주변을 둘러싼 법적 해자(legal moat)는 그들이 생각하는 것보다 훨씬 얇습니다.

국경을 넘어서는 순간 상황은 달라집니다. 영국은 1980년대 후반부터 1988년 저작권, 디자인 및 특허법(Copyright, Designs and Patents Act 1988)의 제9조 제3항을 법전에 두고 있으며, 이는 "컴퓨터 생성 저작물 (computer-generated works)"을 명시적으로 다루며 저작자를 "저작물 생성에 필요한 준비를 수행한 사람"으로 지정하고 있습니다. 인도 또한 유사한 접근 방식을 따릅니다. EU는 AI 법(AI Act)을 통해 더욱 야심 찬 재구성을 진행 중이며, 이에 대해서는 나중에 다시 다루겠습니다. 핵심은 이겁니다. 현재로서는 단일한 글로벌 해답이 존재하지 않는다는 것입니다. 여러분의 팀이 런던 사무실에서 작성한 코드는, 동일한 주에 동일한 모델을 사용하여 샌프란시스코에서 작성된 동일한 코드보다 소유권 관계가 더 명확할 수 있습니다.

여러분의 도구의 계약서가 실제로 말하는 것

다음은 GitHub의 Copilot 제품 특정 약관(Copilot Product Specific Terms)에서 가장 중요한 역할을 하는 문장이자, AI 도입 회의에서 아무도 인용하지 않는 문장입니다:

"귀하는 귀하의 코드에 포함된 제안(Suggestions) 또는 귀하의 코드를 개발하기 위해 참조한 제안을 포함하여, 귀하의 코드에 대한 모든 책임을 집니다."

이 문장은 두 가지 일을 동시에 수행합니다. 하나는 여러분에게 무언가를 넘겨주는 것입니다. GitHub은 제안(Suggestions)에 대한 소유권을 주장하지 않는다고 밝히고 있으므로, 이는 여러분의 코드베이스에 대한 경쟁적인 권리 주장으로 나타나지 않습니다. 그리고 다른 하나는 여러분에게 또 다른 것을 넘겨주는 것입니다. 바로 그 제안과 함께 따라오는 모든 법적 리스크입니다. 학습 데이터로부터 발생하는 오픈 소스 라이선스(Open-source license) 의무, 코드가 유사해 보이는 다른 개발자들로부터의 저작권(Copyright) 주장, 제안 자체의 결함 등이 이에 해당합니다. 벤더(Vendor)의 약관은 출력물의 사용이 제3자 라이선스를 필요로 하는지 여부를 결정하고 해당 라이선스를 준수할 책임이 귀하에게 있음을 명시하고 있습니다.

만약 여러분이 개발자들이 README 파일을 읽듯이 설치 지침만을 훑어보며 GitHub의 고객 계약서(Customer Agreement)를 읽는다면, 이 문장을 놓치게 될 것입니다. 하지만 변호사가 읽는 방식으로 읽는다면, 그 문장이 바로 문서 전체가 됩니다.

이러한 형태는 Copilot만의 고유한 것이 아닙니다. 거의 모든 AI 코딩 어시스턴트 (AI coding assistant)의 약관에서도 동일한 패턴이 나타납니다: 공급업체는 출력물 (outputs)에 대한 소유권을 부인하고, 고객은 출력물에 대한 책임을 수용합니다. 이 패턴이 동일한 이유는 그것이 공급업체가 운영될 수 있게 하는 유일한 형태이기 때문입니다. 공급업체가 모든 제안이 라이선스 의무 (license obligations)로부터 깨끗하고, 버그가 없으며, 저작권 분쟁으로부터 안전하다고 보증하는 대안을 상상해 보십시오. GitHub의 전체 공개 코퍼스 (public corpus)로 학습된 모델에 대해 그들은 그런 약속을 할 수 없습니다. 따라서 계약은 위험을 합리적으로 평가할 수 있는 유일한 당사자, 즉 코드를 병합 (merge)하는 사람에게 떠넘깁니다.

모델은 귀하의 코드베이스 (codebase) 라이선스 약관을 읽을 수 없습니다. 공급업체는 귀하의 산업이 어떤 규제 기관의 통제를 받는지 알지 못합니다. IDE는 귀하가 작업 중인 프로젝트가 취미용 사이트인지 결제 처리기 (payments processor)인지 알지 못합니다. 책임을 고정할 수 있는 유일한 장소는 병합 (merge) 버튼이 있는 곳뿐입니다.

온보딩(Onboarding) 과정에서 아무도 언급하지 않는 면책 (Indemnification)의 공백

여기서 계약은 불편해지며, 대부분의 엔지니어링 조직도 (engineering org charts)가 사각지대를 갖게 되는 지점이 나타납니다.

GitHub는 비즈니스 (Business) 또는 엔터프라이즈 (Enterprise) 플랜을 사용하는 경우, 제안에 대한 지식재산권 (IP) 면책 (indemnification)을 제공합니다. 만약 Copilot이 누군가의 코드 스니펫 (snippet)을 재현했다는 이유로 저작권 침해 소송을 당한다면, Microsoft는 자사의 고객 저작권 약속 (Customer Copyright Commitment)에 따라 귀하를 방어하고 손해 배상금을 지급하기 위해 개입할 것입니다. 업계 전반에 걸쳐 동일한 패턴이 유지됩니다: 대부분의 주요 AI 코딩 도구들은 엔터프라이즈 계층에서 어떤 형태로든 면책을 제공합니다.

만약 귀하가 개인 (Individual) 플랜을 사용 중이라면, 이 중 어느 것도 적용되지 않습니다. 귀하는 동일한 모델, 동일한 제안, 동일한 위험 노출 범위 (risk surface)를 갖게 되지만, 법적 보호는 전혀 받지 못합니다. 만약 법원이 Copilot이 귀하에게 제안한 스니펫이 타인의 GPL 라이선스 코드를 실질적으로 재현한 것이라고 최종 판결한다면, 개인적으로 문제를 겪게 되는 사람은 바로 귀하입니다.

이 문제가 변호사 사무실 너머의 영역까지 중요한 이유는 다음과 같습니다. 많은 전문 소프트웨어가 엔지니어들이 개인용 Copilot 구독을 사용하는 팀에 의해 여전히 출시되고 있기 때문입니다. 이는 회사가 아직 표준화를 완료하지 않았거나, 회사가 엔터프라이즈 (Enterprise) 티어를 도입하기 6개월 전에 누군가 이미 가입했거나, 혹은 개인 계정의 설정이 더 마음에 들기 때문일 수 있습니다. 해당 엔지니어들이 생성하는 코드는 회사의 코드베이스 (codebase)로 흘러 들어가지만, 회사가 엔터프라이즈를 결제하고 있기 때문에 당연히 보장받을 것이라고 믿는 면책 (indemnification) 권한은 개인 구독을 통해 생성된 제안 (suggestions)에 대해서는 실제로 적용되지 않습니다.

엔지니어링 리더들은 이를 거의 검토하지 않습니다. 구매 팀은 엔터프라이즈 계약이 모든 것을 커버한다고 생각합니다. 개발자들은 계약이 _어떤 구독에서 제안이 생성되었는지_에 따라 선을 긋는다는 사실을 알지 못합니다. CISO (정보보호최고책임자)는 소송이 제기되어야만 이 사실을 알게 됩니다.

명확한 책임 소재를 확립하려면 모든 IDE (통합 개발 환경), 모든 개발자 기기, 그리고 모든 공유 환경이 면책이 적용되는 티어에서 실행되어야 합니다. _"우리는 엔터프라이즈를 구매했다"_라는 말은 _"우리 저장소(repo)에 닿는 모든 제안이 엔터프라이즈로부터 나왔다"_라는 말과 동일하지 않습니다.

65-Lexeme 필터와 그것이 잡아내지 못하는 것

GitHub의 안전 관련 문서를 읽어보면 중복 탐지 필터 (duplicate detection filter)라고 불리는 기능을 발견할 수 있습니다. 이 필터는 제안 내용을 GitHub의 공개 코드와 대조하며, 만약 제안에 약 65개의 어휘 (lexemes) 이상(대략 150자, 밀도 높은 코드 한두 단락 정도의 길이)을 포함하는 코드 세그먼트가 있고 이것이 공개 코드와 충분히 유사하게 일치한다면, 해당 제안은 억제됩니다. 관리자는 엔터프라이즈 수준에서 이 필터를 활성화할 수 있으며, 대부분의 합리적인 도입 가이드라인은 이를 켜두라고 권고합니다.

이 필터는 팀들이 Copilot 라이선스 위험에 대해 논의할 때 가장 많이 인용되는 단일 완화 조치입니다. 또한 이는 _"기능이 존재한다"_와 "그 기능이 문제를 해결한다" 사이의 간극을 보여주는 아주 좋은 사례이기도 합니다.

65-lexeme(어휘) 임계값은 임의로 정해진 것이 아닙니다. 이는 재현율 (Recall)과 유용성 사이의 절충안입니다. 공개된 코드와 일치하는 모든 3-token (3-토큰) 매치를 차단하는 필터를 적용한다면, Copilot의 거의 모든 제안을 차단하게 될 것입니다. 왜냐하면 3-token 시퀀스는 거의 모든 오픈 소스 프로젝트에서 나타나기 때문입니다. 따라서 이 임계값은 우연히 유사한 것이 아니라 의도적으로 유사할 가능성이 높은 범위 내에서 그보다 훨씬 높게 설정되어 있습니다. 합리적인 설계입니다. 그 대가로 임계값 _미만_의 모든 것은 필터링 없이 통과됩니다.

GPL 라이선스가 적용된 저장소의 코드 조각과 정확히 일치하는 30-lexeme 함수 본문이 여러분의 코드베이스에 포함될 수 있으며, 필터는 이를 전혀 감지하지 못합니다. 50-lexeme 규모의 관용구 (Idiom), 일반적인 알고리즘 구현, 파서 (Parser) 파편, 직렬화 (Serialization) 헬퍼 등은 기준선을 넘지 않고도 수십 개의 저장소와 동일하게 포함될 수 있습니다. 이 필터는 모든 것을 잡아내겠다고 주장하는 것이 아닙니다. 저작권 침해 주장을 뒷받침할 가능성이 가장 높은 긴 형태의 유사 코드 (Near-duplicates)를 잡아내겠다고 주장하는 것입니다. 짧은 형태의 것들은 법 자체가 "실질적 유사성 (Substantially similar)"이 무엇을 의미하는지 결정하지 못한 회색 지대에 존재합니다.

이 지점은 완벽한 결정을 내리는 것이 아니라 방어 가능한 결정을 내려야 하는 부분입니다. 필터는 도움이 됩니다. 하지만 이를 완전한 해결책으로 취급해서는 안 됩니다. 받은 편지함의 스팸 필터처럼 취급하십시오. 유용하고 종종 조용히 정확하게 작동하지만, 낯선 사람으로부터 온 첨부 파일을 열지 말아야 한다는 원칙을 대신할 수는 없습니다.

규제 기관은 누가 작성했는지에 관심이 없다

미국의 저작권 논의는 _소유권 (Ownership)_에 집중합니다. 반면 유럽의 규제 논의는 _결과에 대한 책임 (Responsibility for outcomes)_에 집중하며, 그 프레임워크는 진정으로 다릅니다.