1P by GN⁺ | ★ favorite | 댓글 2개
  • 공식 syncthing-android 앱이 은퇴하며, GitHub와 F-Droid의 마지막 릴리스는 2024년 12월 Syncthing 버전과 함께 제공될 예정임
  • 중단 배경에는 Google Play 배포가 “어렵거나 불가능한 수준”이 된 상황과 활성 유지보수 부재가 함께 있음
  • Play Store 릴리스 차단만이 원인은 아니며, 앱을 되살리거나 계속 유지하려면 누군가가 장기 유지보수를 맡아야 함
  • Android에서 Syncthing 자체가 사라지는 것은 아니어서 기존 앱 사용, Syncthing Fork, Termux 기반 실행 같은 대안이 논의됨
  • 마지막 공식 앱은 한동안 동작할 가능성이 있지만, 새 Syncthing 버전이 필요한 사용자는 설정을 내보내 Fork로 옮기는 전환을 고려해야 함

공식 syncthing-android 앱 종료

  • 공식 syncthing-android 앱은 은퇴가 결정됐으며, 마지막 GitHub 및 F-Droid 릴리스는 2024년 12월 Syncthing 버전과 함께 이뤄질 예정임
  • 종료 배경은 두 가지가 겹친 결과임
    • Google이 Play 배포를 “어렵거나 불가능한 수준”으로 만들었다는 점
    • 앱에 대한 활성 유지보수가 없다는 점
  • 앱은 오랫동안 의미 있는 개발이 없었고, Play 릴리스도 어려워지면서 지속적인 유지보수에 투입할 이점과 동기가 줄어듦
  • 앱 기여자들에게 감사 인사가 전해졌고, 여러 사용자도 유지보수에 대한 감사와 아쉬움을 표함

Play Store 배포 문제와 유지보수 한계

  • 커뮤니티에서는 Play Store 정책이 합법적인 고급 권한 앱에는 불리하게 작동한다는 반응이 나옴
    • 고급 권한이 필요한 앱은 Store에 올리기 어려워짐
    • 사용자 데이터를 수집하거나 스파이웨어에 가까운 앱은 별다른 제재 없이 남아 있다는 비판도 있음
  • F-Droid에서 몇 릴리스 더 유지하며 전환 안내나 문서를 제공할 수 있느냐는 제안도 나옴
  • 프로젝트 측은 일반 배포 채널에서 릴리스를 하지 못하는 점이 추가적인 의욕 저하 요인일 뿐, 유일한 원인은 아니라고 선을 그음
  • 앱의 부활이나 지속은 누군가가 장기적인 노력을 투입해야 가능하며, 앱은 오랫동안 “life support” 상태였음

Android에서 Syncthing을 계속 쓰는 방법

  • 이번 결정은 오랫동안 거의 휴면 상태였던 공식 Android 앱의 중단에 한정됨
  • Android에서 Syncthing 자체를 사용할 수 없게 되는 것은 아니며, 다른 사람이 Android용 Syncthing 앱을 계속 배포할 수 있음
  • Android가 점점 iOS와 비슷한 방향으로 가면서 어려워질 수 있다는 우려가 있지만, 최근에도 iOS용 새 오픈소스 Syncthing 앱이 만들어졌다는 점이 언급됨
  • 공식 발표자는 본인도 Android에서 Syncthing을 쓰는 사용자라며, Android에서도 오랫동안 사용 가능하기를 개인적으로 바람

논의된 대안: Fork와 Termux

  • 직접적인 대안으로 Catfriend1/syncthing-android가 언급됨
  • 기존 공식 앱의 마지막 버전은 더 이상 업데이트되지 않지만, 한동안 계속 잘 동작할 가능성이 있음
  • 더 최신 Syncthing 버전이 필요하면 Syncthing Fork로 전환할 수 있음
    • 공식 앱 설정에서 현재 구성을 내보낼 수 있음
    • Fork로 가져올 수 있음
    • Syncthing 관점에서는 두 앱이 서로 호환됨
  • Termux에서 Syncthing을 실행하는 방식도 대안으로 논의됨
    • 파일을 내보내거나 복사하고 설정을 일부 조정하면 동작함
    • 휴대폰을 계속 깨워두고 싶지 않다면 수동으로 시작·중지해야 하는 점이 단점임
    • Android 설정에서 Termux 앱의 배터리 최적화를 켜두면 Android doze 모드에서 강제로 sleep 상태가 될 수 있다는 의견도 나옴
  • Web GUI는 로컬 브라우저에서 http://127.0.0.1:8384로 접근할 수 있으며, 기존 Syncthing 앱을 쓸 때도 가능한 방식임

Termux + Tasker 구성 예시

  • 한 사용자는 Syncthing + Tasker + Termux 조합이 동작하는 대안이라고 확인함
  • 설치 구성은 다음과 같음
    • Play Store에서 Tasker 설치
    • F-Droid에서 Termux 및 termux:tasker 설치
  • 추가 권한은 다음과 같음
    • Tasker: additional → run commands in termux environment
    • Termux: Appear on top
  • Termux에서 Syncthing 설치 명령은 다음과 같음
termux-setup-storage
apt install syncthing
  • ~/.termux/tasker/start-syncthing-for-5minutes.sh 파일을 만들고, 5분 동안 Syncthing을 실행하도록 설정함
#!/usr/bin/bash

timeout -s KILL 5m syncthing
  • Tasker에서는 00:00부터 23:59까지 매 1시간마다 Plugin→Termux:Tasker로 해당 스크립트를 실행하도록 설정함
    • start-syncthing-for-5minutes.sh
    • terminal session: X
  • GUI에서 Start browser 옵션을 끄면 시작할 때 브라우저가 자동으로 뜨지 않음
  • 기존 Android 앱에서 설정을 내보낸 뒤 ~/.local/state/syncthing에 복사하면 새 설치 대신 기존 구성을 이어갈 수 있음
    • 이후 config.xml에서 GUI 접근용 username/password를 삭제하고, 필요하면 새로 설정할 수 있음

댓글과 토론

Hacker News 의견들
  • Google과의 논의에서는 아무 성과가 없었음. 권한을 받기 위해 Google이 요구한 변경 사항이 모호해서, 어떻게 대응해야 할지 알아내기도 힘들고 뭘 해도 성공할지 불분명했음
    이후에도 Play에 남기 위해 개발자 인증, 대상 API 수준 같은 별개 작업이 더 생겼고, 결국 이 게임을 계속할 동기와 시간이 더는 없다는 걸 깨달았다고 함

    • Google이 보안 이슈에 대해 “파일 API를 쓰기 싫은데 코드 작성이 어려워서”라는 변명을 받아들였을 것 같지는 않음. “SAF API를 쓰기 싫으니 모든 사용자 데이터, 사진 등에 접근하게 해달라”는 식으로 어떤 논의가 가능했을지도 모르겠음
      회사에서 PR 코멘트를 고치는 대신 자기 방식이 더 낫다며 폭발하는 사람과 비슷해 보임. Apple도 ObjC/Swift API를 쓰기 어렵다는 이유만으로 임의 디렉터리에 쓰게 해주지는 않음
  • 예전에 Dropbox에서 2010년대에 Android를 전문적으로 개발했고, 구형 Android 파일시스템 API도 어느 정도 알고 있었지만, 의식적으로 개발자 경험/백엔드 쪽으로 옮기고 Android를 떠났음. 예전 Android 동료들도 대부분 비슷했음
    앱을 계속 동작하게 하려면 끝없이 통과해야 하는 절차와 API 변경이 너무 고통스러웠음. 2014년에 “보안” Storage Access Framework가 새로 나왔을 때, 파일 이름에 "../../"만 넘기면 아무 앱의 비공개 디렉터리에 쓸 수 있는 사소한 디렉터리 순회 취약점을 발견했음. SAF를 이해하려고 AOSP 소스를 훑다가 바로 눈에 띌 정도였음
    Android는 오랫동안 앱 폴더에 전역 실행 비트도 부여해서, 악성 앱이 다른 앱 파일에 이름으로 하드 링크를 만들고 이를 다시 그 앱에 넘겨 파일 내용에 접근하는 혼동된 대리자 공격도 가능했음
    Android가 보안을 강화해온 건 반갑지만, 너무 느슨한 기반 위에 만들어졌고 수많은 앱이 그 기반을 사용하거나 남용해왔기 때문에, 잠금이 강화될수록 계속되는 대형 호환성 깨짐에 적응해야 하는 개발자들이 생태계를 떠나게 될 것 같음
    [0] Bug 18512473 fixed in https://android.googlesource.com/platform/frameworks/base/+/...
    [1] Proof of concept video: https://www.dropbox.com/s/8dpd8visrttqbfo/poc.mp4?dl=0

    • 네이티브 모바일 플랫폼의 지속 유지보수 비용이 너무 높은 게 문제임. 밑바탕이 계속 바뀌는 플랫폼 위에서 누가 개발하고 싶겠나 싶음
      webOS의 비전이 그리워짐. 14년 전 webOS 구현 자체가 그립다는 뜻은 아님
  • 활발히 관리되는 Android용 Syncthing 포크가 있고 별도 지표일 뿐이지만 별도 1.3K개를 받았음
    [1] https://github.com/Catfriend1/syncthing-android

    • 알아두면 좋지만, README에는 이렇게 되어 있음: “Google Play Developer Account를 닫을 계획입니다. 이 앱 게시를 돕기 위해 최신 gplay 릴리스 파일을 받고 싶다면 연락 주세요”
    • 그 포크를 꽤 오래 써왔음. Syncthing을 시작했을 때는 Syncthing-Fork를 쓰는 게 통념처럼 보였는데, 이유는 기억나지 않음
    • 이상하게도 지금 Play에서는 둘 다 찾을 수 없음. Play를 통해 설치한 원본으로 보이는 앱은 아직 기기에 있음
    • 다른 앱의 설정을 내보내 이 포크로 가져왔더니 동작하는 듯함. 설정도 다 살아 있고 동기화도 되는 것 같음. 개발자들에게 박수를 보냄
    • 맞음, 그걸 쓰고 있음. 몇 년째 아주 만족함
  • 원래 스레드를 보면 작성자가 Google Play에 게시하는 게 매우 어렵다고 말함
    “이유는 Google이 Play 게시를 어렵거나 불가능한 수준으로 만들고 있기 때문”이라고 하는데, 여기서 무슨 일이 벌어지는지 더 설명해줄 수 있나?
    [1]: https://forum.syncthing.net/t/discontinuing-syncthing-androi...

    • 이 경우에는 작성자가 앱 샌드박스 밖 데이터에 접근하는 방식으로 몇 년 전부터 의무화된 Storage Access Framework API를 쓰고 싶어 하지 않았음
      이 API는 Java 전용이고 Syncthing 핵심부는 Java로 작성되지 않았기 때문에, 파일을 읽고 쓸 때 Android를 호출하려면 JNI 연결 코드를 작성해야 했을 것임. SAF는 각 파일에 URI를 부여하고 폴더 구조를 계속 질의해야 해서, 일반 파일처럼 경로를 이어 붙일 수 없으므로 꽤 번거롭기도 함
      작성자는 그 작업을 원하지 않았고 모든 파일, 사진, 문서에 직접 접근하게 계속 허용해달라고 Google을 설득하려 했지만 Google은 거절했음. 여기서의 “어려움”은 지침을 따르지 않으면 Play에 게시하기가 정말 어렵다는 뜻으로 보임. App Store와 마찬가지임
    • 이 개발자의 구체적인 문제는 모르지만, Android 개발자로서 겪은 Google Play 문제는 말할 수 있음. Google Play는 앱 권한에 점점 더 엄격해지고 있고, 권한 승인 기준은 매우 불투명
      내 앱도 한 마이너 릴리스에서는 권한 승인을 받았다가, 다음 주에는 앱에 사소한 변경만 있었는데도 거절되곤 함. Google Play 지원팀에 문의하면 답변은 늘 모호하고, 정형화되어 있으며, 반복적임. 앱 업데이트가 승인될지 전혀 알 수 없어서 무언가를 개발하기에 끔찍한 방식임
    • 업무로 앱을 몇 개 만들어봤는데, 가장 적절한 비유는 정부 규제임. 스토어 요구사항, API, 규칙이 여러 곳에 흩어진 49쪽짜리 문서에 지나치게 자세히 적혀 있고, 내부 사정을 모르면 안정적으로 구현할 방법이 없음
      결국 이런 구조는 소규모, 저예산, 시간이 부족한 개발자만 벌주고 대형 업체 중심으로 통합을 유도함. 큰 업체는 어느 정도 영향력을 행사할 수 있고, 기본 신뢰도도 있으며, 터무니없고 때로는 부담스러운 요구사항을 구현할 예산과 시간이 있음. 결과적으로 시장 지위를 굳히고 앞으로 수십 년간 Play Store를 떠받칠 끈끈한 참여자를 만들려는 것처럼 보임
  • 이걸로 휴대폰에 KeePass 데이터베이스를 넣고 있었는데 난감함. 같은 처지인 사람이 있나?

    • KeePass2Android는 SFTP와 함께 쓰면 기능이 조금 더 좋아짐. 예를 들어 충돌이 생겼을 때 변경 사항을 병합할 수 있음
      SFTP로 한 기계에 접속하고, 그 기계에서 나머지 기기들과 Syncthing을 돌리는 방식을 추천함
    • syncthing-fork가 지난 몇 년 동안 내게는 눈에 띄게 더 잘 동작했음: https://f-droid.org/en/packages/com.github.catfriend1.syncth...
    • Resilio Sync도 꽤 괜찮지만 독점 소프트웨어임
    • 결국에는 KeepassDX가 Syncthing 기능을 자체적으로 통합해야 할 것 같음
    • KeePass와 Joplin 모두 영향받음
  • Syncthing을 쓸 줄 알고 원할 정도의 사용자라면, APK 출처로 F-Droid에 의존하는 것도 충분히 가능하지 않을까 싶음. 그걸 배포 채널로 삼는 것만으로는 부족한가?

    • 앞으로 몇 달 안에 사람들이 F-Droid 기반 “syncthing-fork”로 옮기거나 다른 동기화 도구로 이동하면서 확인될 듯함
  • 모바일 컴퓨팅이 너무 싫음

    • 이 상황이 너무 나빠서 Pocket PC 시절의 Win32 개발 경험이 그리울 정도임
  • APK를 Turbo Pascal 플로피들과 함께 안전한 곳에 보관해둘 예정임. Android용 Syncthing은 내 악보 컬렉션 관리에 필수였음

  • 현재 Syncthing Android 앱이 앞으로 얼마나 오래 계속 동작할지 아는 사람이 있나?