Dantami Repo Sync의 SynoCommunity 등록 신청과 자동 빌드 통과 기록
GitHub와 NAS의 Gitea 저장소를 함께 쓰다 보니 두 곳의 변경 사항을 맞춰 주는 도구가 필요했다. 그렇게 시작한 Dantami Repo Sync를 Synology 패키지로 만들었고, 이번에는 SynoCommunity 패키지 저장소에 등록하기 위한 작업을 진행했다.
2026년 10월 4일 기준, 등록용 Pull Request를 제출하고 자동 검사와 빌드까지 통과한 상태다. 아직 패키지 센터 배포가 승인된 것은 아니다. 이 글에서는 수동 설치용 SPK를 배포한 뒤, SynoCommunity 등록 신청까지 어떤 준비가 필요했는지 정리한다.
저장소 두 개의 변경 사항을 맞추는 일에서 시작
처음 요구 사항은 단순했다. GitHub와 NAS에서 운영하는 Gitea 중 어느 쪽에서 작업하든, 다른 쪽 저장소에도 변경 사항을 반영하고 싶었다.
하지만 매번 터미널을 열고 명령어를 찾아 입력하는 방식은 원하지 않았다. 저장소를 화면에서 연결하고, 현재 상태를 확인하고, 필요하면 동기화를 실행할 수 있는 앱이 필요했다.
그래서 Dantami Repo Sync는 여러 GitHub·Gitea 저장소 쌍을 등록하고 관리하는 웹 UI 형태로 만들었다. NAS에 설치한 뒤 브라우저에서 사용하며, 자체 계정으로 로그인하고 한국어와 영어를 전환할 수 있다.
동기화 기준도 주의해서 정했다. 커밋 시각만 보고 더 최근인 쪽을 덮어쓰면 양쪽에서 따로 진행한 작업을 잃을 수 있다. 이 앱은 Git 이력을 기준으로 안전하게 반영할 수 있는 변경만 처리한다. 강제 푸시, 갈라진 이력의 자동 병합, 삭제 전파는 하지 않는다.
공개 배포를 준비하며 손본 부분
직접 쓰기 위한 앱을 다른 사람도 설치할 수 있게 만들려면 기본값부터 다시 봐야 했다. 개인 서버 주소나 특정 저장소가 미리 등록되어 있으면 안 된다. 설치한 사람이 자신의 서버와 저장소를 연결하도록 바꿨다.
저장소를 추가하는 기능만으로는 관리가 끝나지 않는다. 등록한 연결을 제거하거나 일시 정지하고, 현재 어떤 작업이 진행 중인지 확인할 수 있어야 한다. 로그인과 계정 관리도 앱 자체에서 처리하도록 했다.
배포 이력도 유지해야 했다. 새 버전이 나왔다고 이전 릴리즈를 없애면 어떤 버전에서 문제가 생겼는지 비교하기 어려워진다. 지금은 버전별 릴리즈와 설치 파일을 누적해서 남기고 있다.
v1.6.2: 재시작 후 자동 동기화 수정
최근 수정에서는 서비스 재시작 직후의 자동 동기화 흐름을 고쳤다. 이전에는 시작하면서 저장소를 비교한 뒤 변경 사항을 발견해도 다음 동기화 주기까지 기다렸다. 주기가 60분이면 화면에 '반영 대기'가 보여도 한동안 그대로 남는 식이었다.
현재는 자동 동기화가 켜진 연결에 대해 시작 시 비교를 마친 뒤, 안전하게 반영할 변경이 있으면 곧바로 동기화한다. 이후에는 설정한 주기로 돌아간다.
SynoCommunity 등록을 위해 빌드 방법을 제출
목표는 사용자가 SPK 파일을 직접 찾아 내려받는 과정을 줄이고, SynoCommunity 패키지 소스를 통해 설치할 수 있게 하는 것이다.
이를 위해 SynoCommunity의 패키지 빌드 저장소인 spksrc에 앱을 만드는 방법과 설치 구성을 추가했다. 완성된 바이너리만 전달하는 대신, 지정한 소스 버전에서 패키지를 다시 만들 수 있도록 준비하는 작업이다.
이번 제출에서는 크게 두 부분을 구성했다:
- cross/dantami-repo-sync: 소스 다운로드, 체크섬, Go 빌드 설정, 필요한 패치
- spk/dantami-repo-sync: 패키지 정보, 아이콘, 서비스 실행 스크립트, 설치·업데이트 안내 화면과 문서
spksrc/
├── cross/
│ └── dantami-repo-sync/
│ ├── Makefile # 소스 다운로드, 체크섬, Go 빌드
│ └── patches/ # 필요 패치
└── spk/
└── dantami-repo-sync/
├── Makefile # 패키지 정보
├── INFO # 패키지 메타데이터
├── icon.png # 패키지 아이콘
├── scripts/ # 설치·업데이트 스크립트
└── conf/ # 안내 화면, 라이선스지원 범위는 DSM 7.1 이상, x64로 제한했다. 실제 확인하지 않은 ARM 등 다른 아키텍처까지 지원한다고 표시하지 않았다.
패키지 전용 사용자로 서비스를 실행하고, DSM의 CGI 진입점을 통해 앱 화면에 접근하도록 구성했다. 내부 통신은 전용 Unix 소켓을 사용하며 별도 TCP 수신 포트를 추가하지 않는다.
수동 설치판과 커뮤니티 패키지는 구분
기존 수동 설치판의 패키지 식별자는 DantamiRepoSync다. 이번 spksrc 제출에서는 패키지 명명 방식에 맞춰 dantami-repo-sync를 사용했다.
앱 이름이 같더라도 DSM이 설치된 패키지를 구분하는 식별자가 다르다. 따라서 이번 커뮤니티 패키지를 기존 수동 설치판의 자동 업그레이드로 취급할 수 없다. 별도 설치 방식이며, 기존 계정이나 설정을 자동으로 가져오지 않는다.
Draft PR 제출부터 자동 검사 통과까지
등록 요청은 SynoCommunity spksrc PR 7537로 제출했다. 처음에는 Draft 상태로 열었다. 공식 PR 가이드에서도 Draft로 시작하고 CI가 통과한 뒤 리뷰 준비 상태로 전환하도록 안내한다.
제출 직후에는 GitHub Actions가 운영진의 실행 승인을 기다렸다. 이후 실행 승인이 해소됐고, 코드 형식 검사인 Lint와 Build 워크플로가 모두 성공했다. 빌드 결과에는 x64·DSM 7.1용 패키지 아티팩트도 생성됐다.
여러 아키텍처 이름의 작업이 성공으로 표시되더라도 그 모든 환경을 지원한다는 뜻은 아니다. 이번에 안내하는 지원 범위는 계속 x64·DSM 7.1 이상이다.
지금 완료된 것과 남아 있는 것
현재 완료된 것은 소스 공개, 수동 설치판 v1.6.2 배포, SynoCommunity용 패키지 구성, Draft PR 제출, 그리고 자동 검사와 빌드 통과까지다.
이제 커뮤니티 패키지를 실제 NAS에 설치했을 때의 동작을 확인해야 한다. 신규 설치와 업데이트, 재부팅 후 서비스 시작, DSM에서의 앱 실행과 로그인, 동기화 기능을 검증해야 한다. 운영진의 패키지 구성 검토와 반영 절차도 남아 있다.
따라서 현재 상태를 'SynoCommunity 등록 완료'라고 소개할 수는 없다. 정확히는 '등록 신청 후 자동 빌드까지 통과한 상태'다.
같은 과정을 준비한다면 먼저 지원 범위를 좁혀 실제로 빌드되는 패키지를 만들고, 테스트한 것과 아직 확인하지 못한 것을 분명히 기록하는 것이 도움이 된다.