소스보다 먼저 나온 API — Android 17 QPR1과 「오픈소스 안드로이드」의 시차

API 표면은 공개됐는데 그 구현은 석 달 뒤에 나온다면, 그 플랫폼은 여전히 오픈소스인가, 아니면 「나중에 공개되는 소스」를 가진 독점 플랫폼인가?

도입

2026년 9월 16일, GrapheneOS 프로젝트가 자사 Mastodon 계정에 짧은 글을 올렸다. Android 17 QPR1이 안드로이드 허니콤(3.x) 이후 처음으로, Android Open Source Project(AOSP)에 릴리스하지 않은 채 앱 개발자용 새 API를 추가한 릴리스라는 내용이었다. 새 API는 현재 Pixel OS 전용이며 다른 안드로이드 OEM에는 제공되지 않는다고 했다. 근거로는 Google 개발자 사이트의 API 차이 보고서(API 레벨 37에서 37.1로의 변경)를 링크했다.

이 글은 9월 18일(UTC) 해커뉴스에 「Android 17 is the first since 3.x to add new APIs without releasing to the AOSP」라는 제목으로 올라와 1,180점을 받았다. 한국 시간으로는 9월 19일 새벽이다.

제목만 보면 「Google이 API를 Pixel 전용으로 잠갔다」로 읽힌다. 하지만 GrapheneOS 스레드를 끝까지 읽으면 이야기의 모양이 다르다. 문제는 특정 API가 영구히 Pixel 전용이라는 것이 아니라, 안드로이드의 릴리스 리듬 자체가 「Pixel이 먼저, 나머지는 분기 뒤에」로 재편됐고 그 시차 안에 이제 API와 보안 패치까지 들어가기 시작했다는 것이다. 이 글은 그 시차가 누구에게 어떤 비용으로 떨어지는지를 정리한다.

무엇이 실제로 바뀌었나

먼저 사실관계를 출처별로 분리해 두자.

Google의 공식 입장은 source.android.com의 사이트 업데이트 페이지에 있다. 해당 페이지는 2026년부터 트렁크 안정 개발 모델에 맞추고 생태계의 플랫폼 안정성을 확보하기 위해 AOSP에 소스 코드를 Q2와 Q4에 공개한다고 적고 있다. 빌드와 기여에는 android-latest-release 매니페스트를 쓰라고 안내하며, 이 매니페스트는 현재 android17-release 브랜치를 가리킨다. 즉 연 2회 공개는 숨겨진 정책이 아니라 공표된 정책이다.

GrapheneOS의 설명은 여기에 구체적인 결과를 덧붙인다. 한 답글에서 그들은 이 API들이 「표준 안드로이드 API」이며 2026년 12월 Android 17 QPR2를 통해 AOSP와 다른 OEM에도 제공될 것이라고 밝혔다. 지금 Pixel 전용인 이유는 Android 16 이후 QPR1과 QPR3 릴리스가 Pixel 전용이 됐기 때문이고, 이번이 그 체제에서 처음으로 QPR1 또는 QPR3에 API가 추가된 경우라는 것이다.

API 차이 보고서 자체를 열어 보면 규모가 보인다. 추가된 패키지는 android.hardware.hid 하나이고, ACCESS_HID 권한이 새로 생겼다. 변경된 패키지에는 android.hardware.input, android.health.connect.datatypes, android.media, android.os, android.provider, android.telecom, android.widget.photopicker 등이 있다. 새 클래스로는 입력 장치 사용자 정의 계열(CustomizationTrigger, KeyCustomizationTrigger, ButtonCustomizationTrigger, AppCustomizationAction 등), EmbeddedPhotoPickerUiCustomizationParams, MediaStore.DeletedFiles 등이 보이고, Health Connect에는 AlcoholConsumptionRecord가 추가됐다. 보고서의 생성 일시는 2026년 6월 29일로 표시돼 있다. 9월 15일 정식 릴리스보다 두 달 반 앞서 API 표면은 이미 확정돼 있었다는 뜻으로 읽을 수 있다.

해커뉴스에서 @jauntywundrkind는 이 API가 HID라는 점에 주목했다(직접 인용은 아니고, 코멘트의 요지를 요약). USB HID 사양에는 충전기와 배터리 상태, 각종 센서 등 활용되지 않는 기능이 많아 안드로이드의 HID 지원 확대는 반길 일이지만, 다른 이들과 함께 만들었으면 좋았겠다는 취지였다. 같은 이용자는 별도 코멘트에서 이것이 Pixel용인지, 크롬북을 위해 급히 넣은 것인지 궁금하다고도 했다.

요약하면 이렇다. API 수는 많지 않고 영구 독점도 아니다. 그러나 「API 문서와 SDK는 공개, 구현 소스는 비공개」인 기간이 공식적으로 생겼다. 허니콤 시절 소스 비공개가 예외적 사건이었다면, 이번에는 그것이 달력에 적힌 정례 일정이라는 점이 다르다.

시차의 비용은 누가 내는가

커스텀 ROM: 「포팅은 끝났는데 낼 수 없다」

GrapheneOS 스레드에서 가장 구체적인 부분은 자신들의 작업 사정이다. 그들은 9월 15일 정식 출시 전에 이미 Android 17 QPR1로 코드를 포팅했지만 아직 공개 권한이 없다고 썼다. 그래서 당분간은 Pixel 펌웨어, 커널 드라이버, 유저스페이스 드라이버, HAL을 QPR1에서 Android 17로 백포트하는 작업을 하고 있다고 한다. 앞으로 가는 대신 뒤로 옮겨 심는 셈이다.

GPL 문제도 언급됐다. GrapheneOS는 Google이 또다시 몇 주 동안 GPL 소스 요청에 응하지 않았다고 주장하며, 9월 1일 요청한 CD1A.260905.001.A1 소스를 9월 16일에야 받았다고 적었다. 커널 빌드 ID가 17 QPR1 Beta 9와 같아 커널 쪽은 이미 갖고 있었다는 단서도 달았다. 이 부분은 GrapheneOS 측의 주장이며 Google의 반론은 이번에 확인한 자료에 없다.

그들의 결론은 역설적이다. Pixel은 이제 다른 많은 기기보다 지원하기가 훨씬 어려워졌고, Pixel의 몇 안 되는 장점 중 하나가 단점으로 바뀌었다는 것이다. 업데이트와 보안 기능 때문에 여전히 가장 적합하지만, 프라이버시와 보안 작업에 써야 할 시간을 잡아먹는다고 했다. 반면 협력 중인 Motorola 기기는 공식 펌웨어와 드라이버 코드를 받게 되므로 이런 문제가 없을 것이라고 밝혔다. 「구글 순정 하드웨어가 탈구글 OS의 최적 기반」이라는 오랜 공식이 흔들린다는 신호다.

LineageOS 같은 다른 AOSP 기반 프로젝트에 대해서는 이번 자료에 직접 언급이 없다. 다만 GrapheneOS는 비Google OEM과 AOSP 기반 프로젝트가 연간 릴리스와 QPR2 릴리스를 출시할 수 있고 보안 백포트도 있다고 정리했으며, 몇 달의 지연 없이 패치를 내려면 보안 프리뷰 접근권이 필요한데 자신들은 Motorola 협력 이전부터 다른 OEM을 통해 이를 갖고 있었다고 했다. 이 문장을 뒤집어 읽으면, 그런 접근권이 없는 프로젝트는 지연을 그대로 감수한다는 뜻이 된다.

보안 패치: 진짜 쟁점은 API가 아니다

해커뉴스에서 가장 많은 공감을 얻은 분석은 @bri3d의 것이었다(직접 인용은 아니고, 코멘트의 요지를 요약). 구조를 정리하면 Google은 반기마다 「진짜」 소스 업데이트를 OEM과 대중에게 내고, Pixel에는 문서와 SDK를 포함한 업데이트를 네 번 낸다. 이번에 Pixel 전용 업데이트에 새 API가 들어갔다. 하지만 Pixel의 시장 점유율이 작아서 앱 개발자가 이 API에 의존할 가능성은 낮고, 결과적으로 Pixel이 한 분기 뒤 일반 기기에 올 기능의 베타 테스트 장비가 될 뿐이라는 시각이다. 그는 오히려 헤드라인이 더 깊은 문제를 묻어 버렸다고 지적했다. 분기별 Pixel 릴리스에 월간 백포트에 없는 보안 수정이 들어 있다면, Pixel 릴리스를 패치 디핑해서 익스플로잇을 역산할 수 있으므로 매우 나쁜 일이라는 것이다.

GrapheneOS 스레드에는 실제로 그 주장이 있다. 2026년 9월 Pixel 업데이트 게시판에는 비Pixel 기기도 쓰는 표준 안드로이드 플랫폼 구성요소에 대한 추가 패치가 있는데, 이것이 9월 안드로이드 보안 게시판이나 프리뷰 패치로는 제공되지 않았다고 한다. 다른 OEM은 12월 QPR2를 통해서야 받게 되고, GrapheneOS는 코드를 역공학해서 먼저 내보낼 수 있다고 했다. 한 Mastodon 이용자가 AI 기반의 빠른 역공학 시대에 보안 수정을 내는 것이 곧 위협 행위자에게 취약점을 공개하는 것 아니냐고 묻자, GrapheneOS는 그렇다고 답하며 수개월 숨기는 것으로는 거의 숨겨지지 않는데 보안 프리뷰 체계가 무엇을 달성하려는지 의문이라고 했다.

이 지점이 이번 사건의 핵심이다. 바이너리는 이미 수많은 Pixel에 배포돼 있다. 공격자에게 바이너리 diff는 충분한 정보다. 그런데 방어자 쪽, 즉 다른 OEM과 커스텀 ROM은 소스를 받지 못해 같은 diff를 공식 경로로 반영할 수 없다. 소스 공개를 늦추는 것이 공격자에게는 거의 장벽이 되지 않고 방어자에게만 장벽이 되는 비대칭이다. GrapheneOS가 Google 법무팀이 Pixel에 신기능과 보안 패치의 몇 달 조기 접근권을 주고 있다는 사실을 알고 있는지 궁금하다고 쓴 것도, 이 구조가 OEM 파트너와의 관계에서 경쟁상 문제가 될 수 있다는 문제 제기다.

다만 반론도 있다. 해커뉴스에서 @mdwrigh2는 주요 OEM은 아주 짧은 지연으로 내부 소스에 접근할 수 있으며, OEM이 중간 릴리스를 내지 않는 것은 Google이 소스를 막아서가 아니라 스스로 선택한 것이라고 반박했다(직접 인용은 아니고, 코멘트의 요지를 요약). 이 말이 맞다면 「OEM에게서 숨긴다」는 프레임은 과장이고, 실제로 배제되는 것은 계약 관계 밖의 AOSP 이용자, 즉 커스텀 ROM과 소규모 제조사와 연구자다. 이번에 확인한 자료로는 어느 쪽이 정확한지 판정할 수 없다. 다만 두 주장 모두에서 공통으로 손해를 보는 집단이 「계약 없는 오픈소스 이용자」라는 점은 일치한다.

앱 개발자: 실질 영향은 작지만 신호는 크다

앱 개발자 입장에서 HID나 입력 장치 사용자 정의 API가 석 달 일찍 Pixel에만 있다는 것은 실무상 큰 일이 아니다. @bri3d의 지적처럼 Pixel만을 위해 기능을 만드는 개발자는 드물다. @vkaku는 많은 개발자가 Android 16 API 수준에서만 개발할 것이라고 내다봤는데(직접 인용은 아니고, 코멘트의 요지를 요약), 이것은 과장일 수 있어도 방향은 맞다. 대부분의 앱은 원래 최소 SDK를 몇 년 뒤에 둔다.

신호로서의 의미는 다르다. 「API 레벨」이 이제 「모든 안드로이드 기기가 언젠가 받는 계약」에서 「Pixel에 먼저 오는 기능 목록」으로 성격이 바뀌고 있다. 해커뉴스의 @soleil-colza는 「Pixel = AOSP의 레퍼런스 구현」이라는 관계가 침식되기 시작한 것 같다고 짧게 적었다(직접 인용은 아니고, 코멘트의 요지를 요약). 레퍼런스 구현이 소스보다 앞서 나가면, 레퍼런스는 더 이상 소스를 참조하지 않는다.

전망과 시사점

단기적으로는 12월이 분기점이다. GrapheneOS 설명대로라면 Android 17 QPR2와 함께 이번 API와 보안 수정이 AOSP에 공개된다. 그때까지 커스텀 ROM은 백포트와 역공학으로 버티게 되고, 이는 인력이 적은 프로젝트일수록 무거운 짐이다. 해커뉴스의 @charcircuit은 AI 에이전트가 변경 사항을 알아내고 역공학하는 데 도움이 되지만, 최종 결과는 바뀌지 않으면서 생태계에 비효율만 더한다고 적었다(직접 인용은 아니고, 코멘트의 요지를 요약). 역공학이 가능하다는 것은 피해 최소화이지 정당화가 아니다.

중기적으로는 「오픈소스 안드로이드」의 정의가 바뀐다. 지금까지의 계약은 「릴리스되면 소스가 따라온다」였다. 새 계약은 「연 2회, Google이 정한 시점에 스냅숏이 나온다」다. 이 둘 사이의 차이는 라이선스 조문으로는 드러나지 않는다. Apache 2.0 코드는 공개되는 순간 여전히 자유롭다. 바뀌는 것은 시간 축이다. 오픈소스의 가치 중 상당 부분은 「지금 실행 중인 코드를 지금 읽을 수 있다」는 데서 나오는데, 그 「지금」이 최대 반년까지 벌어질 수 있게 됐다.

해커뉴스의 @natterangell은 안드로이드가 macOS와 Darwin의 길을 가고 있다고 봤다(직접 인용은 아니고, 코멘트의 요지를 요약). AOSP는 계속 무료로 기반에 남지만, 언젠가 사용자 경험의 핵심이 되는 비자유 요소가 등장해 대등한 대안이 불가능해지고, AOSP는 코드베이스 이상의 의미를 잃으며 서서히 썩어 간다는 시나리오다. 이번 일이 그 시나리오의 증거라고 단정하기는 이르다. API는 결국 공개된다. 그러나 「결국 공개된다」와 「동시에 공개된다」 사이의 간극이 정책으로 고정됐다는 점은, 그 시나리오로 가는 길이 포장되기 시작했다는 뜻으로는 읽을 수 있다.

규제 측면에서는 @jauntywundrkind가 EU 디지털시장법(DMA)이 Google에 일부 API, 특히 AI 어시스턴트 관련 API의 상호운용을 요구하고 있으며 대부분의 기한이 2027년 8월 1일이라고 언급했다(직접 인용은 아니고, 코멘트의 요지를 요약). 이번 Pixel 선행 API가 DMA의 관심 범위에 들어갈지는 확인한 자료로 판단할 수 없다.

실무적 시사점은 세 가지로 정리된다. 첫째, 커스텀 ROM 사용자는 이제 「Pixel이면 안전하다」는 가정을 재검토해야 한다. GrapheneOS조차 비Pixel 기기 지원이 더 쉬워질 것이라고 말한다. 둘째, 보안 담당자는 Pixel 업데이트 게시판을 「Pixel 전용 정보」가 아니라 「다른 안드로이드 기기에 아직 오지 않은 수정 목록」으로 읽어야 한다. 셋째, 앱 개발자에게 API 레벨 37.1 같은 소수점 레벨은 「Pixel 선행 레벨」로 취급하고, 기능 분기는 API 레벨이 아니라 실제 기능 존재 여부로 하는 편이 안전하다.

결론

이번 사건의 표면은 HID 패키지 하나와 몇 개의 클래스다. 그 정도라면 1,180점의 반응은 과해 보인다. 하지만 사람들이 반응한 것은 API의 양이 아니라 순서다. API 문서가 나오고, 바이너리가 Pixel에 배포되고, 소스는 석 달 뒤에 나온다. 이 순서는 오픈소스 프로젝트의 순서가 아니라, 소스 공개 일정을 가진 독점 제품의 순서다.

Google의 공식 설명은 「플랫폼 안정성」이다. 그것도 일리가 있다. 그러나 안정성을 위한 지연이 보안 수정에까지 적용되고, 그 수정이 이미 배포된 바이너리에서 diff로 드러날 수 있다면, 지연은 안정성이 아니라 정보 비대칭을 만든다. 공격자는 바이너리를 읽고, 방어자는 소스를 기다린다.

그렇다면 질문은 이것이다. 안드로이드가 「오픈소스」라고 말할 때, 우리는 라이선스를 말하는가, 아니면 지금 내 손 안에서 돌고 있는 코드를 읽을 권리를 말하는가. 12월 QPR2 공개가 예정대로 이뤄지는지, 그리고 그 사이 Pixel 전용 보안 수정이 얼마나 쌓이는지가 그 답의 첫 데이터가 될 것이다.

(10월 14일 추기: 해커뉴스에 「AOSP 소스 공개가 너무 늦어 개발자가 라이브러리를 디스어셈블해서 버그를 보고한다」는 글이 509점으로 올라왔다. 링크된 Android NDK 이슈 #2260에서 보고자는 2026년 9월 Android 17 빌드(CP3A.260905.009)의 bionic wcscspn()/wcspbrk()가 U+0100 이상의 문자를 잘못 일치로 처리하는 회귀를 발견했는데, 공개된 android-17.0.0_r1(6월) 소스는 올바른 구현이라 출시 라이브러리를 디스어셈블해 원인을 추적했다. Google 측 bionic 담당자는 문제를 인정하면서 소스를 보면 될 텐데 공개 릴리스가 너무 오래돼 해당 변경이 없다는 취지로 답했다. 소스와 실행 코드의 시차가 실제 디버깅 비용으로 나타난 구체적 사례다.)

출처: