▲

F-Droid 빌드 서버가 구형 CPU로 인해 최신 Android 앱 빌드 불가 문제

 (news.ycombinator.com)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • F-Droid 빌드 서버가 구형 CPU로 인해 최신 Android 앱을 빌드하지 못하는 상황 발생
  • ARM, x86-64 등 최신 모바일 앱에서 요구하는 고급 명령어 집합을 지원하지 못함
  • 서버의 업그레이드 및 교체가 필요하지만, 비용 및 인프라의 한계 존재
  • 개발자들은 F-Droid의 지속 가능성과 기술적 최신성에 대해 우려 표명
  • 대안으로 클라우드 기반 빌드 및 서버 자원 기부 논의 진행 중임

개요

  • F-Droid는 Android 오픈소스 앱의 비공식 스토어로, 직접 소스 코드를 빌드해 앱을 배포하는 구조임
  • 최근 빌드 서버가 최신 Android 앱에서 요구하는 CPU 명령어 집합을 지원하지 못해, 더 이상 일부 앱 빌드 제공이 불가해짐

빌드 서버의 기술적 한계

  • 앱 빌드에 필요한 새로운 ARM 및 x86-64 명령어를 구형 CPU가 지원하지 못함
  • 이러한 제한으로 인해, 성능 최적화가 된 현대 앱이나 최신 라이브러리 적용 앱을 빌드 파일로 제공할 수 없는 문제 발생
  • Python, Kotlin 같은 최신 언어 및 Gradle 등 최신 빌드 툴도 자주 최신 CPU 환경을 요구함

커뮤니티 내 우려와 논의

  • 개발자와 이용자들은 F-Droid의 지속적인 앱 품질 저하 및 빌드 실패 보고에 대해 우려를 표명
  • 인프라 업그레이드가 필요하나, 재정적 한계와 서버 관리 인력 부족 문제 부각

대안 및 해결 방안 모색

  • 클라우드 환경에서 빌드 서버 운영, 혹은 커뮤니티 차원의 서버 자원 기부 등 다양한 방안 논의
  • F-Droid 팀은 외부 지원과 새로운 하드웨어 확보를 통해 문제 해결 의지를 밝힘

결론

  • F-Droid의 가치와 오픈소스 생태계 지원 의의는 여전히 높음
  • 다만, 현대 앱 트렌드에 맞는 인프라적 혁신과 유지관리 노력이 필수임
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 이 말은 그들의 서버가 정말 오래된 것임을 의미함, x86-64-v2를 지원하지 않는 수준이며, 거의 Intel Core 2 Duo 시절의 서버를 떠올릴 수 있음
    Red Hat Enterprise Linux 9의 x86-64-v2 마이크로아키텍처 레벨에 대해 정리된 글을 참고 바람
    Epyc 컨슈머 CPU로 바꾼다면 서버 성능이 훨씬 빨라질 것 같음
    실제로 기부를 요청하려 했는데, 이미 $80,000이 남아있었음
    연간 예산이 $17,000임을 감안하면, 2~3천 달러로 최신 Zen4 또는 Zen5 matx 컨슈머 Epyc 서버를 구매해도 예산 안에 들어감
    만약 정말로 노후된 서버가 여러 대라면 Zen5 서버 한 대로 몇 대는 교체할 수 있고, 전력과 공간도 훨씬 절약될 것임
    F-Droid의 예산 상태도 참고함
    Librapay 기부금은 아직 포함이 안 된 듯함
    Librapay 기부 관련 링크

    • 반드시 서버가 오래된 것만은 아님, 우리 가상화 플랫폼의 경험을 보면 외부 공급업체의 VM을 업그레이드한 후 CPU에서 x86_64v2 + AES를 지원하게 노출해 주었음에도 일부 서비스가 실행되지 않았음
      최소 요구 사항은 "Pentium과 Celeron"이었으니 충분하다 생각했음
      근데 실제로는 서비스 중 하나가 v3 또는 v4 CPU에서만 지원되는 명령어를 사용해서 동작을 멈췄음
      노출 CPU 셋팅을 바꾸자 정상적으로 돌아왔음
      그래서 서버 자체가 실제로는 성능이 되지만 설정 오류거나, 혹은 바이너리가 명시한 것보다 높은 사양을 요구하거나, 기타 다른 이슈일 수도 있음
    • $2~3천 달러로는 사실 하위급 Threadripper 순정 CPU 가격에 불과하며, 이 돈으로 Epyc 서버 전체를 구입할 수 없을 것임
    • 어쩌면 서버가 Coreboot나 Libreboot로 부트되고 있을 가능성도 있음
    • 지금 시점에 리눅스가 이 정도로 오래된 하드웨어를 공식 지원하고 있는지도 의문임
      cmpxchg16b 명령어는 그렇게 오래되지 않은 인스트럭션이고, 현재는 필수 사양으로 여겨지고 있음
    • 남은 돈이 얼마 없다고 해도 기부를 여전히 권하고 싶음
      자원봉사자들이 시스템 유지를 위해 쓰는 시간과 노력에 비하면 £80,000은 정말 적은 금액임
      인프라 현대화가 필요하다고는 들었지만, 큰 투자가 필요한 부분임
      기금이 더 여유로웠다면 아마도 더 자신감 있게 투자할 수 있었을 것이라 생각함
      서버 업그레이드 외에도 해결해야 할 과제가 많음

  • 지금 상황이 꽤 걱정됨
    FDroid는 현재 구글을 제외하고 가장 규모가 큰 안드로이드 앱스토어이기 때문에 더욱 필요하다고 생각함
    혹시 이 문제를 해결할 계획이 있는지, 혹시 FDroid가 언제 서버를 업그레이드할지, 혹은 구글이 이 의무 요구사항을 철회할 가능성이 있는지 궁금함 (마지막 경우는 가능성이 적다고 봄)

    • FDroid는 자원봉사자가 운영하는 커뮤니티 프로젝트임을 감안하면 걱정은 이해하지만, 특히 EU 국가들이 오픈소스 소프트웨어로 이동 중이기 때문에 F-Droid 같은 프로젝트에 공적 자금 지원이 있었으면 좋겠음
    • f-droid가 중요하다면, 최신 빌드 서버 구입을 위해 직접 기부하는 것도 필요함
    • 구글이 요구사항을 철회할 가능성에 대해서는, 2021년에도 비슷한 문제가 있었고, 당시에는 Gradle Plugin 4.1.0이 SSSE3 명령어를 요구해서 이슈가 발생한 적이 있었음
      해당 이슈는 Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9에서 수정되었음
      실제 티켓 기록도 남아있음
    • FDroid가 구글 제외 최대 안드로이드 스토어라는 것에 회의감이 있음
      개인적으로 톱10에도 못 들 것이라고 생각함
    • "구글 빌드 툴은 소스빌드는 안되고, 최적화를 따로 해서 바이너리로 나왔으니까"라는 설명을 듣고, 서버를 업그레이드하는 게 맞다는 결론에 동의하지 않음

  • 왜 aapt2를 타겟에 맞게 다시 빌드하지 않는지 궁금함
    소스는 구할 수 있음
    aapt2 소스 위치

    • AOSP를 실제로 빌드해본 적이 있는지 묻고 싶음
      바이너리가 정말 많이 들어있고, 몇몇 바이너리를 소스로 다시 빌드하려 했는데, 빌드 시스템이 너무 심하게 망가져서 바로 포기했음
    • 도커에서 QEMU CPU 에뮬레이션을 쓰는 게 aapt2를 일일이 다시 컴파일하는 것보다 훨씬 유지보수에 용이함
      앞으로 나오는 바이너리마다 다시 패치할 필요 없이 자동으로 바이너리 업데이트를 대응할 수 있음

  • Streaming SIMD Extensions(SSSE3) 위키 문서를 공유함
    내 오래된 데스크톱도 이 명령어를 지원했고, 10년 가까이 사용했었음
    그런데도 소스 코드에서 비어셈블리(비어셈)를 사용하는 백업 패스조차 제공하지 않은 것이 놀라움

    • "비어셈으로도 백업 패스가 없다는 게 이상하다"는 질문에, 아마도 수작업 어셈블리 코드 문제는 아닐 것 같음
      컴파일러가 x86_64-v2로 지정해 컴파일했을 가능성이 큼
      RHEL 9도 이런 옵션으로 빌드했고, RHEL 10에서는 x86_64-v3로 올라가면서 AVX도 지원하게 됨
    • 이슈를 살펴보니 빌더는 Opteron G3 (K10) 계열로 보임
      AMD 10h 위키 링크
    • 백업 패스를 제공하지 않는 문제는 테스트 하드웨어 부족 때문임
      현실적으로 이걸 테스트할 수 있는 하드웨어가 없고, 다 오래되고 느린 기기뿐임
    • 구형 데스크탑을 기증해주면 FDroid에서 좋아할 것 같음

  • 완전히 이해가지는 않음
    gradle과 aapt2가 오픈소스인데, buildroot나 openwrt처럼 직접 컴파일해서 툴체인을 만들면 더 예측 가능한 결과가 나오기 때문임
    f-droid도 마찬가지로 전체 툴체인을 직접 소스로부터 빌드하면 지원하지 않는 인스트럭션을 가진 바이너리 gradle이나 aapt2를 쓸 필요가 없어짐

    • 실제로는 구글이 제공하는 SDK 바이너리를 아직도 쓸 수밖에 없음
    • 이 방식이 타당하다고 생각하지만, gradle은 자체적으로 프리빌트 Java 라이브러리 등 의존성을 다운로드하여 사용함
      이 중에는 네이티브 바이너리가 포함된 것도 있고, buildroot나 리눅스 배포판처럼 각 라이브러리가 어떻게 빌드되는지에 대한 메타데이터가 없음
      또 gradle 생태계 라이브러리마다 빌드 과정이 모두 다르기에(표준화 안 됨), 전체를 직접 소스로부터 재구성하는 것은 상당히 번거롭고 까다로운 작업임

  • 구글이 upstream에서 이 문제를 이미 수정했다는 이야기도 있음
    이슈 링크 참고
    얼마나 빨리 해결될지 확신할 순 없지만, 이슈 쓰레드는 직접적으로 수정됐다는 근거는 없더라도 다소 안심이 됨

    • 실제로는 아직 수정된 상태가 아님
      위 링크 스레드에서는 오타("mas fixed"→"was fixed") 정정을 이번 이슈가 해결됐다고 착각한 상황임
      해결된 것은 몇 년 전의 유사한 과거 이슈임
      구글 이슈 트래커 참고
    • 아직까지도 이 근본 문제가 개발자들에게 잘 안 알려졌음

  • sse4.1이 2011년에 도입된 명령어임을 생각하면 이런 구형 서버가 아직 운영 중인 게 의아함
    최신 CPU라면 같은 일을 전력 소모의 일부만으로 처리할 수 있을 텐데, 경제적으로도 낡은 하드웨어를 계속 쓰는 게 이해되지 않음
    혹시 빌드 서버의 대수나 사양에 대해 아는 사람 있는지 궁금함

    • 최신 CPU를 쓰면 같은 일을 전기세의 일부만으로 할 수 있으니 빨리 업그레이드해야 한다는 의견에, 연간 8,760시간 중 500W급 CPU가 1년 내내 풀로 돌아가도 전기세가 $550임
      절반으로 줄여도 새 컴퓨터 값의 10%밖에 안 되니, 비용 회수까지 10년이 걸림
      업그레이드는 자본지출이지만, 전기세는 운영비라는 점도 있음
      미국 전기값 근거 자료
    • sse4.1은 Intel Penryn이 2007년 11월에 처음 도입했고, AMD는 Bulldozer(2011년 중반)까지 지원하지 않았음
      Bulldozer에 추가된 다양한 명령어(AVX, FMA 등)가 있지만 기존 Opteron이 실제로는 Bulldozer보다 빠른 경우가 많아서, Epyc(2017년 중반) 나오기 전까지는 업그레이드 유인이 적었음
      다양한 패키지에서 sse4.1 이상이 적용되는 시점이 되는 이유는, 오래된 CPU에서는 조건 분기 등 SIMD 병렬 처리 시 오버헤드가 높기 때문임
    • 실제 답은 "open firmware(오픈 펌웨어)와 ME/PSP가 없는 듀얼 소켓 AMD 보드(예: KGPE-D16)를 쓸 수 있기 때문"일 수도 있음
    • 서버 쪽은 잘 모르겠지만, 실제 구형 하드웨어는 데스크톱 영역에서는 자주 볼 수 있음
      2000년대 구형 PC로 무난한 작업(웹 브라우징 등)은 충분했으나, 세월이 흘러 프로그램들이 새 인스트럭션을 요구하게 되며 점차 쓸모없어졌음
      심지어 파이어폭스조차 새 명령어셋을 요구하게 되어, 결국 멀쩡히 작동하는 데스크탑을 버릴 수밖에 없었던 경험이 있음
    • 구형 CPU를 쓰는 이유가 Canoeboot, GNU Boot 같은 자유 펌웨어 때문일 거라 생각함
      하지만 KGPE-D16 보드에는 SSE4.2 지원 CPU도 장착할 수 있는데, 정확한 이유는 잘 모르겠음

  • 구글의 새로운 aapt2 바이너리(AGP 8.12.0) 얘기를 하며, F-Droid는 빌드 환경 보호·격리에 엄청 신경을 쓰는 프로젝트인데, 왜 오히려 upstream 바이너리를 받아다 쓰지, 소스부터 빌드하지 않는지 의외임

    • 관련해서, 비교적 최근까지도 안드로이드 SDK의 자유 소프트웨어 빌드가 최신 상태로 제공되는 게 없음
      안드로이드 앱을 만들려면 기본적으로 구글의 비자유(Non-free) 바이너리에 의존하게 됨
      관련 포럼 글 참고

  • 참고자료 링크 정리
    F-Droid admin issue
    Catima 앱 이슈
    MBCompass 이슈

    • Catima 스레드를 보면 FDroid 커뮤니티에서 일하기가 굉장히 어렵다는 인상이 강하게 남음
      한 멤버가 이렇게 말함: "F-Droid에서 늘 그렇지만, 우리의 목소리는 항상 외면당함. 해결책을 논의해서 F-Droid를 개선할 수 있다는 희망이 있었다면 그렇게 많던 시간과 에너지를 들이고도 좌절해서 떠나지 않았을 것임"

  • F-Droid 서버가 정말 낡았다는 의견임
    전혀 다른 아키텍처에서 x86_64를 에뮬레이션해도 오히려 성능향상이 될 수준임
    오히려 OSS(오픈소스)적 논리를 들 필요도 없을 정도임
    만약 폐쇄 펌웨어에 신경쓰지 않는다면, 더 저렴하면서도 최신의 x86 서버 옵션도 많음

    • "서버가 정말 낡았다"는 말을 들으면 왠지 유머를 기대하게 됨
      대중문화 덕에 "서버가 너무 낡아서 벤자민 프랭클린과 유치원 짝꿍이었다" 같은 농담이 떠오름
답변달기