많은 돈이 걸린 오라클과 구글의 소송전이 미국 대법원의 최종 결정이라는 마지막 라운드만 남겨두고 있다. 이 소송전의 여러 대상 가운데 하나는 API가 저작권 보호 대상이 될 수 있는지 여부다.
 

이 소송전에는 순수한 도용 의혹 등 여러 미묘한 사안들이 걸려있다. 하지만 프로그래머와 변호사에게 수익과 직결된 논쟁거리를 제공하는 사안은 API의 개념과 API가 저작권 보호 대상이 될 수 있는지 여부다.

이런 논쟁의 한쪽에는 코드를 만들 때 걱정해야 할 법률적 문제가 하나 더 늘어나는 것은 아닌지 궁금해하고 고민하는 프로그래머가 있다. 이들은 “더 많은 변호사와 더 많이 논의해야 할 이유가 생기는 것은 아닐까?” 궁금해하고 고민한다.

다른 한쪽에 있는 사람들도 프로그래머들이다. 우수한 API를 만들기 위해 많은 시간을 투자했으며, 그 결과물을 통제하면서 노력을 보상받기 원하는 프로그래머다. 변호사들의 경우, 프로그래머들의 창조물에 대한 정당성을 입증받아 라이선싱 수수료를 획득하는 기회와 관련된 사안이다.

그 동안, 여러 단계에서 법정에 따라 때론 구글에 유리한, 때론 오라클에 유리한 판결이 내려졌다. 가장 최근에는 연방 순회 항소 법원(Court of Appeals for the Federal Circuit)이 “법의 관점에서 구글의 자바 API 패키지 사용 방식은 공정하지 않다"는 판결을 내렸으며, 손해에 대해 평가하는 프로세스를 시작했다. 이 사건에 대한 최종적인 법적 결정이 내려질 수도 있었던 대법원 심리는 애초 3월 24일로 예정되어 있었다. 그러나 영원하지 않을 수도 있다. ‘영원’이란 너무 긴 시간이기 때문이다(해당 대법원 심리는 코로나19 사태로 인해 무기한 연기된 상황이다. 편집자 주).
 
안드로이드 플랫폼용 자바 개발에 초점을 맞추고 있는 프로그래머와 변호사들이 구글과 오라클 소송전의 세부 내용에 큰 관심을 갖겠지만, ‘저작물성(Copyrightability)’에 대한 더 큰 질문은 거의 매일 많은 API를 호출해 사용하는 거의 대부분의 프로그래머들에게 영향을 미친다. 가장 낮은 수준에서 코드를 다루는 소수 코더를 제외하면, 거의 대부분의 프로그래머가 매일 API를 다룬다.

API가 저작권 보호 대상이 되어야 할까? 프로그래머는 다른 프로그래머에 대해 얼마나 많은 권한을 행사해야 할까? 프로그래머에게 자신이 만든 API에 대한 권한을 주는 것에 찬성해야 하는 이유, 반대해야 하는 이유들을 정리해봤다.

찬성: 프로그래머가 API를 만들었다
저작권에 대한 법은 아주 명확하다. 프로그래머가 코드를 썼다면, 이 프로그래머는 자신이 만든 결과물에 대한 저작권을 소유한다. 프로그래머는 이 저작권을 상업적으로 거래할지, 아니면 오픈소스 프로젝트에 기증할지 여부를 선택할 수 있다. 이런 선택은 전적으로 프로그래머의 몫이다.

API가 스탠드얼론 코드가 아닐 수도 있지만, 이 경우에도 여전히 해당 프로그래머가 노력한 결과물이다. 프로그래머는 자신의 컴퓨터 결과물과 보상을 공유할 가장 좋은 방법, 가장 적절한 방법에 대해 많은 창의적인 결정을 내릴 것이다. 개발자는 많은 미팅과 코드 검토 과정을 인내했을 것이다. 그렇다면 저작권이라는 형태로 노력을 인정받을 자격이 있다.

반대: API는 기능이다
API는 기능이고, 저작권 법은 단순한 기능적 표현물은 보호하지 않는다. 커피를 권하는 항공기 승무원에게 ‘예’라고 대답했다고 해서, 이것이 ‘예’라는 말을 만든 고대 인류의 저작권을 침해하거나 도용하는 행위는 아니다. 할 수 있는 유일한 방법으로 대답을 한 것에 불과하기 때문이다.

자동차 제조업체가 스티어링 휠과 페달 위치에 대한 저작권을 취득한 상황을 상상해보자. 자동차 제조업체는 핀(Fin)과 페인트 색상을 만들 독창적인 방법을 무수히 많이 갖고 있다. 그렇다면 조정 방법에 대한 학습 없이는 차량을 빌리거나, 빌려주는 것을 불가능하게 만들어야 할까? 법이 기능적 표현을 통제하는 저작권을 허용하지 않는 타당한 이유와 근거들이 있다. API는 코드 결과물이 아니다. 코드를 움직이게 만드는 기능적인 버튼 모음에 불과하다.

찬성: 기능도 진화한다
필자가 새로 구입한 자동차는 반 자율주행 자동차다. 고속도로에서는 페달을 사용할 필요가 없다. 스티어링 휠의 스위치 몇 개를 이용, 속도와 간격을 조정한다. 그러면 컴퓨터가 나머지를 알아서 한다.

자동차 산업이 몇 십년 동안 기준처럼 채택된 스티어링 휠과 페달 위치를 그대로 고수하고 있다고 해서, 이를 바꾸거나 개선할 여지가 전혀 없다는 의미는 아니다. 자동차 회사들은 조이 스틱과 레버, 기타 다른 조정 및 제어 방법에 대해 연구를 하고 있다.

코더는 자신만의 스타일로 동일한 기본 작업을 여러 수많은 방식으로 표현할 수 있다. 프로그래밍 수업을 할 때 ‘복제’를 한 것을 금방 알아차릴 수 있다. 프로그래머 별로 질문에 답을 하는 방식이 다르기 때문이다. 가장 간단한 문제도 동일한 결과물을 달성할 수 있는 수많은 해법이 존재한다. API가 아주 큰 코드 블록에 대한 기능적 관문에 불과할 수도 있지만, 우리는 여기에 내제된 창의적 결정에 대해 보상을 해야 한다.

반대: 단 한 가지 방식만이 존재할 수도 있다
때론 무언가를 하는 방식이 단 한 가지에 불과한 경우도 있다. 그리고 저작권 법은 이런 경우를 예외로 한다. ‘합체의 원칙(Doctrine of Merger)’은 다른 선택지가 없을 때 저작권 규제에서 제한된 탈출구를 제공한다. 이는 아이디어를 표현할 방법이 소수에 불과하다면, 아이디어를 다른 가용한 소수 옵션과 합체하는 것이다. 법은 아이디어 자체가 아닌 아이디어의 표현물을 복제하는 것을 금지하기 때문에, 모든 사람들이 이 합체라는 개념을 사용할 수 있어야 한다. 코드 블록을 복제하기 원하는 사람들은 API 또한 복제하기 원할 것이다.

찬성: API는 과거 어느 때보다 코드에 가까워졌다
API가 큰 결과물의 맨 위에 올려진 ‘무엇’에 불과했던 시절이 있었다. 선디 아이스크림의 맨 위에 올려진 체리와 같은 존재였다는 의미다. 수면 위로 드러난 빙산의 일각에 불과했다는 이야기다. 그렇지만 더 이상은 아니다.

자동화와 영리한 개발자들 덕분에, API 아래 코드 가운데 상당수가 ‘반복 사용 어구’가 되는 경우가 많다. 대부분의 노력이 API를 만드는데 투입되는 반면, 나머지는 서버리스 시스템과 프레임워크, CMS 도구, 스마트 데이터베이스의 조합으로 채워지는 경우가 점점 더 많아지고 있다.

개발자의 입력 형식, 워크플로우, 상태 변환(State transition) 및 응답에 대한 아키텍처 측면 선택이 가장 큰 결정이 되는 경우가 많다. 큰 코드 블록 가운데 상당 부분은 라이브러리와 자동 생성된 기능의 조합이다. 진짜 창의적인 부분이 있을 수 있지만, API를 창조한 노력을 무시하는 것은 실수다.

반대: 명칭(표제, 제목)은 저작권 대상이 될 수 없다
저작권 법은 엄격하게 규제를 하면 일이 불가능해지는 경우가 있다는 점을 인정한다. 작가는 책이나 영화의 제목으로 사용할 짧고 강렬한 문구를 찾는데 많은 시간을 투자한다. 하지만 이런 짧고 강렬한 문구는 한정되어 있다. 이런 이유로 법원은 아주 오래 전, 제목이나 명칭은 저작권 보호 대상이 될 수 없다는 결정을 내렸다.

예를 들어, ‘나이트 쉬프트(Night Shift)’라는 제목의 책은 19종, ‘윈터스 테일(Winter’s Tale)이라는 제목의 책은 3종이 존재한다. 모두 각기 다른 작가가 쓴 책이다.

기능에는 명칭이 있다. 이런 명칭은 제목처럼 한정되어 있다. 예를 들어, ‘인쇄’나 ‘데이터 검색’을 표현하는 방법은 몇 가지에 불과하다. 모든 프로그래머가 기능에 새로운 명칭을 붙이는 것은 프로그래밍 언어가 처음 등장한 1970년대에나 가능했을 것이다. 그러나 이후 많은 기능이 등장했다.

찬성: API는 명칭 이상이다
API를 쓰는데 투입되는 노력 중에서 기능 호출에 대한 명칭을 선택하는 것이 가장 쉬운 일일 것이다. 코드 리뷰를 하는 사람들은 프로그래머가 ‘재기’나 ‘유머’ 능력을 발휘하려 들면 화를 낼 것이다. 그래서 대부분 프로그래머는 절대 통과 못할 ‘말 장난’이나 ‘농담’ 같은 명칭들을 알고 있고, 이런 것들을 버린다.

진짜 노력이 투입되는 부분은 데이터 구조, 형식, 기타 API 호출에 이용할 수 있는 옵션들이다. 이런 부분들이 결정되고 나면, 명칭은 저절로 결정된다.

반대: 공정 이용 원칙은 제한적 복제를 보호한다
API는 큰 코드 블록의 작은 일부에 불과하다. 저작권 법은 오래 전부터 ‘공정 이용(Fair use)’ 원칙 아래 제한적인 복제를 장려했다. 학생, 언론인, 작가들이 저작권 침해로 소송 당하는 것을 걱정하지 않으면서, 축약된 형태로 자신의 저작물에 복제 방식으로 인용을 하는 것에 적용되는 원칙과 동일한 원칙이다.

찬성: 상업적 경쟁은 공정 이용 원칙의 대상이 아니다
공정 이용에 해당되는 것들에 대한 질문은 수십 년 동안 법정에서 다뤄진 질문이었다. 일반적으로 공정 이용 원칙은 저작권 침해에 대한 걱정 없이 책과 음악, 이미지와 관련된 일을 하는 것에 도움을 주는데 목적이 있다. 새 저자가 인사이트나 관점을 추가해 사회 전반의 이해를 넓힌다는 측면에서, 학술 논문이나 신문 기사 등에 일부 문구를 인용하는 것이 장려되는 것이다.

또한 디지털 저작물의 백업 복제본에도 공정 이용 원칙에 따른 예외가 적용된다.

그러나 이러한 공정 이용의 범위는 원 저작물의 판매에 타격을 주는 정도를 기준으로 제한된다. 원 저작물과 상업적으로 경쟁을 하기 위해, 또는 시장에서 원 저작물을 대체하기 위해 API를 복제하는 경우, 법은 이를 허용하지 않는다.

반대: 오픈 API는 자유에 대한 것이다
API는 오픈소스의 ‘친척’이다. 둘 모두 ‘연결’과 ‘통합’을 위해 만들어졌다. 개발자는 다른 사람이 사용할 수 있도록 API를 만든다. 다른 사람들이 승인 없이 API를 복제하도록 허용, 더 건강한 경쟁 환경을 만들 수 있다. 동일한 API로 서로 경쟁을 하는 코드 블록을 만들도록 허용하면 혁신이 촉진될 것이다.

개발자는 자신의 API를 잠그는데 시간을 소비해서는 안 된다. API 이면의 코드를 향상시키는데 시간을 투자해야 한다.

찬성: 오픈소스는 저작권을 좋아한다
인터넷에는 ‘오픈’에 대한 정의가 아주 많다. 일부는 무정부 상태에 가깝지만, 가장 성공적으로 성과를 거둔 것은 오픈소스 팀이다. 이 오픈소스 팀은 대부분이 생각하는 것보다 더 많이 법에 의지를 하는 경우가 많다. 주요 오픈소스 라이선스 모두가 저작권 법의 도움을 받는다. 저작권 법이 약화되면, 오픈소스 라이선스도 약화될 것이다.

반대: API를 저작권으로 보호하면 인터넷이 파괴될 것이다
인터넷은 협력에 의지한다. 이런 협력이 방해를 받을 경우, 혁신이 어려워질 것이다. API에 또 다른 ‘법 계층’을 추가할 경우, 모두 코딩을 멈추고, 권리와 권한을 놓고 다투기 시작할 것이다. 그러면 일이 되지 않는다. 모두 서로를 고소하면서 서비스가 정지될 것이다.

찬성: 법으로 API 저작권을 허용했었다
오라클이 가장 최근의 소송에서 승소를 한 이후, 대법원 판결이 있기까지 이 판결이 유효하다. 그런데 그 동안 인터넷이 그 기능을 멈춘 적이 없었다. API가 문제를 초래한 적이 없다. 계속 유지가 되었다.

중요한 문제가 아님: API 저작권 여부는 중요한 문제가 아니다
향후 대법원의 판결은 구글과 오라클 주주에게 분명히 영향을 미칠 것이다. 또 로스쿨에 앞으로 수십 년 동안 토론을 할 새로운 자료를 제공할 것이다. 그러나 대부분 프로그래머는 그 영향을 느끼지 못할 것이다. API를 만든 사람 중 대부분은 사람들이 자신의 API를 사용하는 것을 원하기 때문이다. 수익 목적에서 인터페이스를 만들 수는 있다. 공유할 정보가 있을 수도 있다. 그러나 대부분 API는 코드에 대한 제약 없이 광범위하게 이용할 수 있도록 만들어져 있다.

그러나 아주 순수하고 개방적이지 못한 상황에서는 대법원 판결이 중요한 역할을 할 것이다. 따라서, 다른 코드 블록을 사용하고, 이를 바탕으로 뭔가 중요한 것을 만들 계획이라면 자신의 동기에 대해 생각을 하고, 라이선스에 대해 조사를 할 필요가 있다.

법이 인정하는 공정 이용의 토대 중 하나인 교육과 기여에 목적이 있는가? 아니면 (이용하려는 코드를 만든)다른 사람에게 수익을 떼어주지 않으려는 목적인가?

다른 사람의 이해에 반하는 일을 하는 경우라면, 욕심을 부리는 경우라면, 법이 이를 알아서 처벌할 확률이 높다. 좋은 소식은 대부분 API 저작자는 자신의 API가 사용되기 원하며, 대부분 프로그래머는 API 저작자의 기대 사항을 지켜 장기적이면서 상호 호혜적인 관계를 구축하기 원한다는 것이다. editor@itworld.co.kr