안드로이드 보안 강화 프로젝트로 알려진 그래핀OS(GrapheneOS)가 구글의 소스코드 공개 방식을 강하게 비판하고 나섰다. 그래핀OS 측 설명에 따르면, 구글은 특정 소스코드에 대해 기존처럼 Git 저장소에 태그를 푸시해 공개하던 방식을 폐지하고, 이용자가 구글 폼(Google Forms)으로 요청을 넣은 뒤 구글 드라이브를 통해 코드를 내려받도록 절차를 바꿨다. 그래핀OS는 이 방식이 "완전히 터무니없다"고 평가하면서, 요청 처리 속도도 점점 느려지고 있으며 결과적으로 GPLv2 라이선스를 명백히 위반하고 있다고 주장했다.
왜 소스 배포 방식이 문제가 되는가
이 문제를 이해하려면 안드로이드 생태계가 어떻게 굴러가는지부터 짚어야 한다. 안드로이드의 상당 부분은 오픈소스 프로젝트(AOSP)로 공개되지만, 커널을 비롯한 일부 구성요소는 GPLv2 같은 카피레프트 라이선스를 따른다. GPLv2의 핵심은 바이너리를 배포하는 주체가 그에 대응하는 소스코드를 함께, 또는 요청 시 접근 가능한 형태로 제공해야 한다는 점이다. 여기서 중요한 것은 단순히 소스를 어딘가에 올려두는 것을 넘어, 받는 쪽이 실제로 쓸 수 있는 방식으로 제공되어야 한다는 조건이다.
Git 태그 방식과 폼·드라이브 방식의 차이는 실무자 입장에서 결코 사소하지 않다. Git 태그로 특정 릴리스 시점의 소스가 저장소에 찍히면, 누구나 버전 히스토리와 함께 코드를 즉시 클론하고 이전 상태와 비교하며 자동화된 파이프라인에 연결할 수 있다. 반면 폼으로 요청하고 드라이브 링크를 기다리는 구조는 사람이 개입해야 하고, 버전 관리 이력이 끊기며, 대량·반복 요청에 부적합하다. 그래핀OS처럼 상위 코드베이스를 지속적으로 추적하며 자체 빌드를 유지해야 하는 프로젝트에는 이 마찰이 곧바로 개발 지연으로 이어진다.
라이선스 위반 주장의 무게
그래핀OS가 GPLv2 위반을 언급한 대목은 단순한 불만 이상의 의미가 있다. GPLv2는 소스코드 접근이 지나치게 번거롭거나 지연되면 라이선스가 요구하는 "대응 소스 제공" 의무를 충족하지 못하는 것으로 해석될 여지가 있다. 즉 코드를 아예 감추지 않았더라도, 요청 처리가 느리고 절차가 복잡하다면 사실상 제때 소스를 제공하지 않은 것과 다르지 않다는 논리다. 다만 이는 현재까지 그래핀OS 측의 주장이며, 구글의 공식 입장이나 어떤 소스코드가 구체적으로 영향을 받는지, 처리 지연이 어느 정도인지에 대한 수치는 제시되지 않았다.
실무자가 주목해야 할 지점
이 사안은 안드로이드 기반 제품이나 커스텀 롬, 임베디드 기기를 다루는 국내 개발팀에도 시사점이 있다. 상용 기기를 출하하려면 여기에 포함된 GPL 계열 구성요소의 소스를 확보해 컴플라이언스를 맞춰야 하는데, 그 원천이 되는 구글의 공개 절차가 불안정해지면 하위 사업자의 의무 이행도 함께 흔들린다. 자동화된 소스 미러링이나 정기적인 업스트림 동기화에 의존하던 팀이라면, 사람이 개입해야 하는 폼·드라이브 방식은 파이프라인 재설계를 강제할 수 있다. 확보한 소스의 버전 대응 관계를 스스로 기록하고 증빙하는 체계도 더 중요해진다.
동시에 이 정보의 한계도 분명히 인식할 필요가 있다. 원문은 그래핀OS라는 특정 프로젝트가 소셜 미디어에 올린 짧은 문제 제기이며, 대상 코드의 범위, 변경 시점, 구글의 의도 같은 세부 사항은 담겨 있지 않다. 오픈소스 라이선스 준수 여부는 최종적으로 법적 판단과 구체적 사실관계에 달린 문제이므로, 현 단계에서는 "위반이 확정됐다"기보다 "신뢰받는 프로젝트가 위반 가능성을 공개적으로 제기했다"는 수준으로 받아들이는 것이 정확하다.
결국 이번 사안의 본질은 대형 플랫폼 기업이 오픈소스 의무를 이행하는 '방식'이 이용자 편의와 얼마나 직결되는지를 다시 보여준다는 데 있다. 코드를 공개하느냐 마느냐만이 아니라, 얼마나 접근 가능하고 지속 가능한 형태로 제공하느냐가 카피레프트 정신의 실질을 좌우한다. 안드로이드 코드베이스에 의존하는 국내 개발 조직이라면 구글의 소스 공개 채널 변화를 예의주시하고, 공급망 컴플라이언스 관점에서 대체 확보 경로와 기록 체계를 미리 점검해 둘 필요가 있다.