“AI는 다음과 같은 어색한 질문을 던집니다. ‘방이 얼마나 깨끗한가요?’”
AI 도구는 개발자들이 기존 소프트웨어의 기능을 재현하는 데 도움을 줄 수 있습니다. 하지만 대안을 만드는 것과 타인의 작품을 복제하는 것 사이에는 중요한 차이가 있습니다.
한 개발자가 최근 포토샵을 대체할 수 있는 ‘분위기 기반’ 소프트웨어에 2만 명의 사용자를 유치했다고 주장한 것은 흥미로운 의문을 제기한다. 만약 AI가 누군가가 경쟁 제품을 개발하는 데 도움을 줄 수 있다면, 원본 소프트웨어 소유자는 이에 대해 불만을 제기할 근거가 있을까?
본능적인 반응으로는, 이미 출시된 제품을 재현하는 행위가 해당 제품의 저작권을 침해할 것이라고 생각할 수 있습니다. 어쨌든 원개발자는 그 제품을 개발하는 데 수년을 투자했을 테니까요. 하지만 저작권은 소프트웨어 기업에 해당 제품의 기능에 대한 독점권을 부여하지는 않습니다. 기능의 복제와 그 기능의 표현 방식의 복제를 구분하는 문제는 AI 코딩 도구가 등장하기 훨씬 전부터 법정에서 다뤄져 왔습니다.
결과는 같지만, 사용하는 소프트웨어는 다릅니다
사진 편집 프로그램을 예로 들어 보겠습니다. 개발자는 사용자가 이미지를 자르고, 색상을 조정하며, 레이어를 다룰 수 있기를 원할 수 있습니다. 이러한 요구사항은 기능을 설명하는 것입니다. 이를 구현하기 위해 작성된 코드는 또 다른 것입니다.
이러한 구분은 소프트웨어 저작권의 핵심입니다. 소스 코드와 객체 코드는 보호받을 수 있지만, 프로그램의 기초가 되는 아이디어와 원리 자체는 보호받지 못합니다. 따라서 경쟁 프로그램이 단순히 동일한 입력을 받아들이거나 동일한 결과를 산출한다고 해서 반드시 저작권을 침해하는 것은 아닙니다.
영국 법원은 Navitaire v easyJet [2004] EWHC 1725 (Ch) 사건에서 이 문제를 다뤘다. 기존 시스템의 소스 코드에 접근할 수 없는 상태에서, 기존 시스템과 매우 유사하게 작동하도록 대체 항공권 예약 시스템이 의도적으로 개발되었다. 법원은 해당 시스템의 기능적 동작을 재현한 것이 저작권을 침해했다는 주된 주장을 기각했다. 그러나 중요한 점은, 그래픽 화면 및 아이콘과 관련된 일부 주장은 인정되었다는 것이다. 기능성과 그래픽 디자인은 서로 다른 판단이 필요했던 것이다.
대안 소프트웨어를 개발하는 사람이라면 누구에게나 이는 유용한 출발점이 됩니다. 즉, 제품의 기능을 재현하는 것과 사용자가 보는 모든 것을 재현할 권한을 갖는 것은 별개의 문제입니다.
클린룸 구축이 다른 점이란 무엇일까요?
클린룸 프로세스는 이러한 구분을 명확히 유지하도록 설계되었습니다. 일반적으로 한 팀은 기존 소프트웨어를 분석하여 그 기능적 동작을 설명하는 사양서를 작성합니다. 원본 코드를 본 적이 없는 별도의 팀은 해당 사양서를 바탕으로 새로운 구현 코드를 작성합니다. 이 프로세스의 기록은 독립적인 개발을 입증하는 데 도움이 됩니다.
이는 원작의 저작권을 소멸시키는 방법이 아닙니다. 또한 ‘클린룸’이 유리한 결과를 보장하는 법적 용어인 것도 아닙니다. 그 가치는 새로운 제품이 저작권으로 보호받는 표현이 아니라, 보호 대상이 아닌 기능을 재현하고 있음을 입증하는 데 있습니다.
AI는 다소 어색한 질문을 던집니다. 방이 얼마나 깨끗한가요?
빈 저장소에서 시작한다고 해서 반드시 이 질문에 대한 답이 되는 것은 아닙니다. 코딩 도구에 제공된 자료는 물론, 도구가 검색해 온 모든 원본 자료도 중요합니다. 또한 모델이 훈련 과정에서 관련 코드를 접했는지 여부에 대한 의문도 제기될 수 있습니다. 이러한 의문들이 저작권 침해를 입증하는 것은 아니지만, “AI가 처음부터 직접 작성했다”는 단순한 주장이 처음 보기에 비해 그리 확신할 만한 것이 아니라는 점을 시사합니다.
따라서 개발자들은 AI에게 기능 사양을 구현하도록 요청하는 것과 기존 코드베이스를 재작성하도록 요청하는 것을 구분해야 합니다. 이 두 가지 작업은 서로 바꿔서 사용할 수 있는 것으로 간주되어서는 안 됩니다.
유럽 법
가장 관련성이 높은 판결 중 하나는 ‘SAS Institute 대 World Programming’ 사건( C‑406/10)이다. 해당 경쟁 소프트웨어는 원본 시스템과 동일한 언어로 작성된 프로그램을 실행하고 동일한 출력을 생성하도록 설계되었다. 개발자는 원본 제품을 연구했으나, 원본 소스 코드에 접근하거나 이를 복사했다는 정황은 전혀 없었다.
C-406/10 사건에서 유럽연합 사법재판소는 프로그램의 기능성, 프로그래밍 언어 및 관련 데이터 파일 형식이 소프트웨어 지침에 따라 컴퓨터 프로그램의 저작권으로 보호되는 표현의 형태에 해당하지 않는다고 판시했다. 이러한 구분을 통해 최초 개발자에게 기초가 되는 아이디어에 대한 배타적 통제권을 부여하지 않으면서도 호환 가능한 소프트웨어를 개발할 수 있는 여지가 확보되었다.
이후 영국 항소심인 SAS Institute v World Programming [2013] EWCA Civ 1482 사건에서, 법원은 기능적 재구현을 인정하는 원심을 유지했다. 그러나 매뉴얼 간의 복사와 관련된 제한적인 침해 인정은 여전히 남아 있었다. 문서를 통해 제품을 이해하는 것과, 해당 문서에서 보호받는 표현을 복제하는 것은 별개의 문제이다.
사진 편집 프로그램의 경우, 이는 유용한 비유가 됩니다. 기존 파일 형식을 지원하기 위해 독립적인 코드를 작성하는 것이 반드시 원본 프로그램을 복사하는 것과 같은 것은 아닙니다. 그러나 그렇다고 해서 해당 형식과 관련된 코드, 문서 또는 기타 보호 대상 자료를 단순히 가져다 쓸 수 있다는 의미는 아닙니다.
API에 관한 논쟁에서 구글이 이기지 않았나요?
미국 법원에서 오랫동안 이어져 온 구글과 오라클 간의 분쟁은, 애플리케이션 프로그래밍 인터페이스(API)가 저작권으로 보호받을 수 없다는 점을 확립한 사례로 종종 회자된다. 하지만 미국 대법원이 최종적으로 내린 판결은 그런 내용이 아니었다.
API를 통해 프로그래머는 기본 구현 코드를 직접 작성하지 않고도 함수를 호출할 수 있습니다. 안드로이드를 개발할 때 구글은 자체 구현 코드를 작성했지만, 자바 플랫폼에서 약 11,500줄에 달하는 선언 코드와 관련 조직 구조를 그대로 가져와 프로그래머들이 익숙한 명령어를 사용할 수 있도록 했습니다.
하급심에서 상반된 판결이 나온 끝에, 대법원은 2021년 4월 ‘구글 대 오라클’ 사건에서 해당 복제가 공정 이용에 해당한다고 판결했다( 여기서 요약됨). 결정적으로, 대법원은 해당 자료가 저작권 보호 대상인지 여부를 판단하기보다는, 사건 판결을 내리기 위한 목적으로 저작권 보호가 존재한다고 가정했다.
따라서 이 판결이 API를 누구나 자유롭게 복제할 수 있다고 규정한 것은 아니다. 또한 이 판결에서 제시된 미국의 공정사용 논리를, 소프트웨어 저작권의 범위를 다룬 ‘SAS Institute 대 World Programming’ 사건에서 프로그램 연구를 허용한 유럽의 접근 방식과 혼동해서는 안 된다. 두 사건 모두 호환성 및 재구현을 뒷받침하고 있지만, 그 법적 근거는 서로 다르다.
새로운 법안만으로는 이 문제를 해결할 수 없다
개발자는 원본 코드를 복사하지는 않으면서도 그 인터페이스를 매우 유사하게 재현할 수도 있다. 이는 또 다른 문제를 야기한다.
‘Bezpečnostní softwarová asociace’ 사건( C‑393/09)에서 유럽사법재판소는 그래픽 사용자 인터페이스가 소프트웨어 지침에 따라 컴퓨터 프로그램의 표현으로서 보호받지 않는다고 판시했다. 그럼에도 불구하고, 인터페이스가 저작자 자신의 지적 창작물인 경우, 그 자체로 저작권 보호 대상이 될 수 있다. 순전히 기술적 기능에 의해서만 결정된 구성 요소는 이러한 독창성 요건을 충족하지 못한다.
AI 기반 사진 편집기에 적용할 때, 중요한 구분점은 익숙한 편집 기능을 제공하는 것과 원본 그래픽이나 기타 보호 대상인 인터페이스 표현을 재현하는 것 사이의 차이입니다. 코딩 도구에 이미지를 바탕으로 화면을 재현하도록 요청하는 행위는, 그 결과로 생성된 코드가 새로운 것이라고 해서 단순히 안전하다고 가정해서는 안 됩니다. 이것이 바로 인터페이스를 이를 구현하는 프로그램과 별도로 취급할 때 도출되는 실질적인 함의입니다.
개발자와 소프트웨어 기업들은 어떻게 해야 할까요?
개발자분들께는 구현을 진행하기 전에 필요한 기능을 먼저 정의할 것을 권장합니다. 사양, 프롬프트, 사용된 원자료 등을 기록으로 남겨두고, 생성된 코드와 시각적 자산을 별도로 검토하시기 바랍니다. “AI가 생성함”이나 “처음부터 작성함”과 같은 설명에만 의존하는 것보다, 문서화된 개발 과정이 훨씬 더 유용합니다.
이미 자리를 잡은 소프트웨어 기업의 경우, 이러한 사례들은 저작권에만 의존하는 것의 한계를 여실히 보여준다. 저작권은 가치 있는 코드, 그래픽, 문서를 보호할 수는 있지만, 경쟁사가 동일한 기능을 독자적으로 구현하는 것을 반드시 막아주는 것은 아니다. 특허, 영업비밀, 계약상 제한 사항 등을 포함한 다른 권리와 의무에 대해서는 별도로 고려해야 한다.
바이브 코딩 분야의 최근 발전은 이러한 논의를 촉발하는 계기가 되어야 한다.
핵심적인 질문은 여전히 익숙한 것입니다. 개발자가 동일한 결과를 도출하는 또 다른 방법을 창안한 것인지, 아니면 타인의 저작권으로 보호받는 저작물을 복제한 것인지입니다. AI가 소프트웨어가 만들어지는 방식을 바꿀 수는 있겠지만, “AI가 작성했다”는 사실은 그 질문에 대한 답을 대신할 수는 없습니다.
경쟁 제품이나 호환 가능한 소프트웨어 제품을 개발 중이시거나, 타사의 제품이 귀사의 제품을 모방하고 있다고 우려되신다면, 평소 상담하시는 Barker Brettell 담당 변호사에게 연락하여 지적재산권 관련 문제를 상의하시기 바랍니다.
