Google의 소스 공개가 Git 태그에서 Drive 신청제로 바뀌었어요
Google의 소스 공개가 Git 태그에서 Drive 신청제로 바뀌었어요
Google이 일부 Android 관련 소스 코드를 공개하는 방식을 바꿨어요. 예전처럼 서명된 Git 태그를 바로 받는 대신, Google Forms로 신청한 뒤 Google Drive의 압축 파일 접근 권한을 기다려야 해요. GrapheneOS는 몇 시간이던 대기 시간이 최근 수 주까지 늘었다고 밝혔어요. 1
이 변화는 다운로드 경로 하나가 달라진 정도로 끝나지 않아요. Android 빌드 도구와 여러 개발 작업은 Git 저장소 구조와 리비전을 전제로 움직여요. 같은 소스가 압축 파일에 들어 있어도 이력과 태그가 사라지면 비교, 포팅, 테스트에 손이 더 가요.
핵심 요약
| 구분 | 핵심 | 왜 볼 만한가요 |
| 공개 방식 | Git 태그 대신 양식 신청과 Drive 권한 부여를 거쳐요 | 자동화하기 쉬운 공개 절차가 사람의 승인 대기열로 바뀌었어요 |
| 개발 흐름 | 압축 파일에는 같은 소스가 있지만 Git 저장소 구조가 없어요 | Android 도구가 쓰는 리비전 정보와 변경 이력을 바로 활용하기 어려워요 |
| 라이선스 | GrapheneOS는 GPLv2 위반이라고 주장해요 | 제공 형식과 수 주의 지연이 합리적인 소스 제공인지가 쟁점이에요 |
| 기기 지원 | 지연의 영향은 당분간 Pixel 지원에 집중돼요 | GrapheneOS는 Motorola용 릴리스를 별도로 준비하고 자체 Git 호스팅도 검토해요 |
1. 소스는 같아도 개발자가 받는 형태는 달라졌어요
GrapheneOS가 공개한 설명에 따르면 Google은 일부 소스의 릴리스 태그를 Git에 게시하지 않아요. 필요한 개발자는 양식을 제출하고, 담당자가 특정 Drive 파일의 권한을 열어 줄 때까지 기다려야 해요. 초기에는 보통 몇 시간 안에 접근할 수 있었지만 최근에는 답변이 수 주 걸리는 사례가 생겼다고 해요. 2
Google Drive에서 받는 tarball에는 기존 Git 배포와 같은 소스가 담겨 있다고 해요. 문제는 소스를 둘러싼 구조예요. Google은 Drive 방식으로 옮기기 전부터 릴리스 태그를 게시할 때 전체 이력을 단일 커밋으로 합치기 시작했어요. 압축 파일만 받으면 어떤 변경이 이전 릴리스에서 들어왔는지 Git 도구로 곧바로 추적하기 어려워요.
Android 개발 환경은 여러 저장소와 Git 리비전을 폭넓게 사용해요. 빌드 시스템도 리비전 정보를 읽어요. Google이 메타데이터 파일을 함께 제공해 대체 경로를 마련했지만, 기존 저장소를 가져와 태그를 비교하던 흐름보다 단계가 늘어나요. 배포물의 내용이 같다는 사실과 수정하기 편한 소스 형태인지는 따로 봐야 해요.
GrapheneOS는 정식 버전이 나오기 전에 Beta 릴리스마다 포팅과 테스트를 진행해요. 새 파일이 생길 때마다 권한을 다시 요청하면 GrapheneOS 개발자뿐 아니라 요청을 처리하는 Google 직원도 같은 수동 작업을 반복해요. 폴더 단위 권한이나 자동 승인만 적용해도 대기 과정을 줄일 수 있지만, 현재 공개된 절차에는 그런 자동화가 보이지 않아요.
GPLv2 위반 여부는 주장과 반론을 나눠 봐야 해요
GrapheneOS는 수 주의 지연과 tarball 제공 방식이 GPLv2를 어긴다고 주장해요. GPLv2는 완전한 기계 판독 가능 소스 코드를 소프트웨어 교환에 통상 쓰는 매체로 제공하도록 요구해요. GrapheneOS는 Git을 전제로 개발하는 프로젝트에서 신청형 Drive 파일이 수정에 알맞은 제공 방식이 아니라고 봐요. 2
반론도 있어요. GPLv2 본문에는 소스 제공을 며칠 안에 마쳐야 한다는 구체적인 시한이 없어요. GrapheneOS는 법률상 의무에는 합리적인 이행 기간이 따라오며, Google의 규모와 기술 역량을 고려하면 수 주의 수동 지연을 정당화하기 어렵다고 맞서요. 공개된 자료만으로 법적 위반을 확정할 수는 없어요. 지금 확인되는 사실은 GrapheneOS가 위반을 주장하고 있고, 제공 기한이 명시되지 않았다는 반론이 함께 나온다는 점이에요.
Pixel과 Motorola의 대응 경로가 갈려요
GrapheneOS는 이번 지연이 주로 Pixel 지원에 영향을 준다고 설명해요. Beta 소스를 늦게 받으면 새 Android 버전에 맞춘 포팅과 사전 테스트 일정도 밀릴 수 있어요. 사용자가 보안 업데이트를 받는 시점까지 실제로 얼마나 늦어지는지는 릴리스별 처리 속도를 더 지켜봐야 해요.
Motorola 기기는 다른 경로를 준비하고 있어요. GrapheneOS는 주요 Android 릴리스에 맞춰 전체 AOSP Git 저장소를 직접 호스팅하는 방안을 검토해요. GitHub 같은 소셜 코딩 플랫폼 없이 일반 Git 저장소를 운영하고, 외부 변경 제안이 필요하면 Gerrit을 자체 운영할 수 있다고 밝혔어요. 첫 지원 기기는 2027년 출시를 목표로 하며 초기 제품은 플래그십급으로 계획돼 있어요. 1
왜 중요한가요
오픈소스 공개는 파일을 내려받을 수 있는지만으로 평가하기 어려워요. 개발팀은 변경 이력을 비교하고, 특정 리비전을 재현하고, 자동 빌드와 테스트를 연결해야 해요. Git 태그가 Drive의 압축 파일과 수동 승인으로 바뀌면 같은 코드도 검토와 통합에 드는 시간이 늘어요. 특히 Beta 릴리스마다 대응하는 프로젝트에는 반복 비용이 쌓여요. 2
Google이 앞으로 권한 부여를 자동화하거나 서명된 태그 공개를 되살리는지가 실무적인 확인 지점이에요. GPLv2 논쟁은 법적 판단이 나오기 전까지 단정하기 어려워요. 개발자 입장에서는 소스의 존재뿐 아니라 배포 형식, 접근 시간, 리비전 재현 가능성을 함께 확인할 필요가 있어요.
이번 사례는 대형 플랫폼의 공개 절차가 주변 프로젝트 일정에 어떤 영향을 주는지 보여 줘요. GrapheneOS가 자체 AOSP 저장소를 운영하면 Google의 수동 승인 대기에서는 벗어날 수 있어요. 대신 저장소 동기화, 저장 공간, 코드 검토 시스템을 직접 관리해야 해요. 공개 방식이 불편해진 비용이 결국 독립 프로젝트의 인프라 운영 부담으로 넘어가는 셈이에요.