AOSP 소스 공개 지연에 따른 개발자들의 라이브러리 역어셈블링 현상 분석
요약
EU의 사이버 복원력법(Cyber Resilience Act) 등 규제 환경 변화가 AOSP 소스 공개 지연 및 제한적인 업데이트 배포로 이어지고 있습니다. 이로 인해 개발자들은 라이브러리 역어셈블링 등의 우회적 방법을 사용하고 있으며, 이는 제조사들이 규제를 악용하거나 해석을 곡해하는 전술로 분석됩니다.
핵심 포인트
- EU 규제(CRA)가 보안 패치 배포에 대한 압박으로 작용함.
- Google의 AOSP 공개 지연은 경쟁사 대비 Pixel 기기에 이점을 주려는 의도로 보임.
- 개발자들은 소스 코드 부재 시 라이브러리 역어셈블링 등의 우회적 방법을 사용하고 있음.
- 장기적으로는 공격 표면을 줄이는 방향으로 소프트웨어 개발이 수렴할 전망.
증명할 수는 없지만, 최근 EU 규제가 역효과를 낸 것이 원인의 일부라고 봄. 정확히 어떤 규제인지는 기억나지 않지만, 일정 기간 기기 업데이트를 보장하고 각 업데이트를 모든 기기에 짧은 기한 안에 제공하도록 하는 규정이 있음. 고급 기기는 바로 업데이트되고 저가 기기는 몇 달씩 기다리는 일을 막으려는 취지임.
그런데 오픈소스 관련 문구 때문에 소스 코드 공개가 업데이트 최초 출시로 간주되어 기한이 시작되는 것으로 알고 있음. Google이 협력사, 특히 Samsung에 AOSP 기반 업데이트를 완성할 시간을 더 주려고 공개를 늦추는 것 같음.
Apple이나 Google 같은 대기업이 유럽 사용자를 통해 규제 당국을 압박하려고 이런 전술을 의도적으로 써도 놀랍지 않을 듯함. Siri AI가 대표적인 예임. 복잡한 사안이지만, 이들이 그런 수를 쓰지 않을 거라고 믿지는 않음.
내가 이해하기로는 대부분의 제조사가 QPR1이나 QPR3을 출시하는 것도 허용되지 않음. 허용되더라도 Samsung 외에 가능한 제조사가 있을지는 의문임. 다른 제조사보다 Pixel에 이점을 주려는 의도도 엿보임.
사실이라면 관할 규제 기관에 알려야 함. 이런 해석은 적어도 법의 취지에 명백히 어긋나므로, 당국이 잘못된 해석이며 의도적인 공개 지연은 허용되지 않는다고 명확히 하거나 법을 개정해 더 분명히 금지해야 함.
어느 쪽이든 사실이라면 기존 규제를 의도적으로 악용하거나 곡해하는 것으로 보임.
흥미로운 가설인데, 규정에서 휴대폰 출시와 OS 출시를 구분하는지 궁금함. 기한은 OS 공개가 아니라 해당 모델이 판매될 때부터 시작할 것 같음. 그렇지 않다면 Google도 Pixel 업데이트를 미뤄야 할 듯함.
사이버 복원력법(Cyber Resilience Act, Regulation (EU) 2024/2847) 임. 보안 패치가 공개되면 제조사는 이를 업데이트로 즉시, 즉 ‘부당한 지체 없이’ 배포하지 않을 경우 벌금을 부과받음.
여러 제조사가 오픈소스 공개를 줄인 것도 이 규제 때문이라고 봄. 법무 부서가 CVE 모니터링과 보고 의무를 더 작은 묶음으로 나눠 처리하려 하기 때문임.
문자 하나에 단순 비교 반복문이라니, 맞는 접근임. 글에서는 약간 Claude 특유의 문체도 느껴짐.
AI가 소프트웨어의 소스를 ‘열어 주는’ 일은 지금까지 본 AI 활용 중 가장 좋은 축에 속함.
코드가 없는 상황이니 여기서는 충분히 타당한 접근이라고 봄. 소스가 있었다면 훨씬 쉽게 찾았을 것 같음.
이런 일이 발전을 늦출 수도 있음. 쉽게 복제할 수 있다면 오픈소스 커뮤니티 외에 누가 새 기능을 개발하겠는가?
Google의 새 모토는 ‘가능한 한 사악해져라’인 것 같음. 사용자의 자유를 존중하는 Android 대안이 필요함.
이 부분에서는 Google이 Apple보다 나음. Google 기기는 대부분 부트로더 잠금을 해제할 수 있음. 지원이 종료된 내 Chromebook과 Nexus 태블릿에도 Linux를 설치해 다시 쓸 수 있음.
오래된 Pixel도 소스 코드가 공개되어 있어 Ubuntu, PureOS 등 Linux 휴대폰 배포판을 이식하는 데 필요한 노력의 문제임. 반면 Apple은 iOS 소스나 드라이버를 공개하지 않고 부트로더 잠금 해제와 다른 OS 설치도 막아, 지원 종료된 내 기기 대부분을 사실상 쓸모없게 만듦.
Google의 현재 방향이 무척 불만스럽지만, 대안을 억압하는 Apple의 수준과는 아직 큰 차이가 있음.
NDK 문제라면 소스 코드가 있어도 별 도움이 되지 않을 것 같음. 투입 자원을 보면 업무 시간의 20%만 쓰는 부업 프로젝트처럼 취급되는 듯함. Android 2.1 이후 진척을 보면 전담 인력이 2명도 안 될 것 같음.
현재 흐름과 비용 구조 변화를 보면 AOSP 같은 프로젝트는 이점보다 단점이 커질 것 같음. 수백 개의 의존성을 가져와 개발 수고를 덜어주는 것보다 소프트웨어 자재 명세서(SBOM)에 포함되는 구성 요소, 나아가 공격 표면을 줄이는 편이 훨씬 유리해질 것임.
소프트웨어에서도 조만간 수직 통합이 진행될 것으로 봄.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기