최근에 오픈소스 앱 하나를 외부 플랫폼에 등록하는 과정을 밟고 있다.
말이 좋아 ‘등록’이지, 생각보다 여러 절차가 필요했다.
오픈소스 플랫폼에 배포할땐, GitHub Releases
개발한 앱 파일을 tar.gz로 묶고, 그 파일에 서명을 붙이고, CSR을 만들어 인증서를 요청하고…
이런 것들을 겪다 보니 중간에 "이 tar.gz 파일을 어디에 올릴 거냐"라는 문제가 생겼다.
그때 등장한 게 GitHub Releases.
처음엔 단순히 GitHub에 파일을 업로드할 수 있는 경로 중 하나 정도로만 알았는데, 생각보다 더 공식적인 ‘배포 채널’로 취급된다는 걸 알게 됐다.
(생각해보면 여기 블로그에 다수 공유했던 오픈소스 기반 유틸리티들도 모두 github release로 배포하고 있었고, 거기서 제공하는 파일들은 자연스럽게 오피셜한 앱으로 생각하고 받았었다.
오늘은 그 구조를 간단히 정리해보았다.
2. GitHub Releases: 단순 URL 제공이 아니라, ‘공식 릴리즈’ 취급된다.
GitHub Releases란?
- GitHub 저장소에서 소스코드 외에 배포 파일(binary, tar.gz 등)을 공개하는 공간
- 보통 특정 태그(tag)에 맞춰서 공개됨 (예:
v1.0.0) - 파일이 업로드되면
https://github.com/<owner>/<repo>/releases/download/<tag>/<file>형태의 정식 다운로드 URL이 생성됨
Releases · microsoft/PowerToys
Windows system utilities to maximize productivity. Contribute to microsoft/PowerToys development by creating an account on GitHub.
github.com
이게 중요한 이유는,
이 URL이 “안정적인 공식 배포 링크”로 간주된다는 점이다.
다른 웹페이지, 스토어, 플랫폼 등에서 앱을 받아갈 때 이 URL을 쓰면 신뢰할 수 있는 링크임을 따로 증명할 필요가 없어지게 되는 것이다.
그럼 그냥 파일 업로드랑 뭐가 다른걸까?
GitHub에는 파일을 올릴 수 있는 방법이 몇 가지 있다.
| 방법 | 특징 |
| 그냥 코드 커밋에 포함 | 릴리즈와 무관, 소스코드에 종속 |
| Wiki나 README에 링크 | 구조상 배포 파일로 적절하지 않음 |
| GitHub Releases | 버전 관리 + URL 고정 + API 대응 → 배포 전용 |
즉, Releases는 단순한 업로드가 아니라, 버전별 배포 이력을 남기는 공식 공간이다.
CI/CD 파이프라인과 연동(Git Action)하면 자동으로 릴리즈를 만들고 파일을 업로드하는 것도 가능하다.
개인 프로젝트라면 github release가 옵션일 수 있지만, 제 경우엔 오픈소스 플랫폼에 포함될 앱을 개발해 제공하는 입장이기 때문에 옵션이 아니다..
3. 그러면 GitHub Releases를 안 쓰면? 어떤 방법으로 보통 올릴까?
모든 오픈소스 플랫폼이 GitHub Releases를 요구하진 않는다.
자체 웹 UI에 tar.gz 파일을 업로드하고 URL을 복사해서 붙여넣는 방식도 가능하다.
예를 들어:
- WebDAV 서버를 써서 파일을 올릴 수도 있고
- 회사 내부 배포 페이지를 만들어서 배포할 수도 있다
- Dropbox, AWS S3도 가능하긴 하다 (다만 신뢰 문제 발생 가능)
하지만 문제는 "신뢰성과 지속성"이다.
- Dropbox 링크는 나중에 깨질 수도 있고,
- WebDAV는 인증이 필요하거나 TLS 미지원 등 문제가 생길 수 있다.
- 릴리즈가 깔끔하게 정리되지 않으면 유지보수 측면에서 좋지 않다.
그래서 결국엔 가장 무난한 선택이 GitHub Releases가 되는 것 같다.
대체로 사람들이 보고 신뢰하는 건 공식 깃헙 저장소 + 버전 태그 + 다운로드 링크다.
그러다보니 많은 오픈소스 플랫폼에서 배포 파일에 대한 URL을 github release를 표준처럼 사용하고 있는 것 같다.
4. 한번 더 정리, 왜 GitHub Releases를 쓰는가.
| 이유 | 설명 | |
| 1 | 공식 URL 제공 | 정적인 URL이 생성돼서 공유가 쉬움 |
| 2 | 버전 관리 | 릴리즈마다 어떤 변경이 있었는지 기록 가능 |
| 3 | 배포 용도에 특화 | README랑 별개로 파일 배포가 깔끔 |
| 4 | 자동화 가능 | GitHub Actions 등으로 자동 배포 가능 |
| 5 | 신뢰성 | GitHub 플랫폼이 주는 신뢰 (타사 링크보다 나음) |
5. 마무리
처음엔 그냥 파일을 어디 올리고 공유해야하나 싶고, github release가 뭔가 싶었는데
지금 생각해보면 GitHub Releases는 단순 업로드 공간이 아니라, 정식 릴리즈를 관리하기 위한 ‘배포 구조의 일부’였다.
특히 인증서 기반으로 앱을 등록하거나, 외부 플랫폼과 연동하려는 경우엔
“공식 릴리즈 URL”이 있다는 게 엄청나게 중요하게 작용한다.
배포 자동화까지 붙이면 더더욱.
다음엔 GitHub Actions로 tar.gz 생성부터 릴리즈 업로드까지 자동화하는 것도 정리해봐야겠다.
추천 포스팅
[바로가기] 의지력으로 극복 못했던 집중력 문제의 진짜 원인
의지력으로 극복 못했던 집중력 문제의 진짜 원인
개발자로 살다 보면 분명히 코드를 작성하려고 검색을 시작했는데, 정신을 차려보니 갑자기 연예 뉴스나 유튜브 영상을 보고 있는 자신을 발견할 때가 있다. 분명 "이제 일해야지!" 하고 결심했
timotimo.tistory.com
[바로가기] 바쁘게 일한 것 같은데 한 게 없는 이유? 생산적 미루기의 함정
바쁘게 일한 것 같은데 한 게 없는 이유? 생산적 미루기의 함정
일을 미루지 않고 계속 바빴던 것 같은데, 정작 해야하는 일은 진척이 없고 정작 마감은 코앞이다. 분명히 바빴는데 왜 한게 없는 걸까? 재택근무가 익숙해지고 나서부터 생긴 가장 큰 문
timotimo.tistory.com
[바로가기] "왜 이렇게 피곤하지?" 하루를 갉아먹는 숨은 에너지 도둑
"왜 이렇게 피곤하지?" 하루를 갉아먹는 숨은 에너지 도둑
"해야 할 일은 많은데 왜 이렇게 피곤하지?"출근해서 앉아있기만 했는데도 퇴근할 때면 녹초가 되는 날이 있다. 생각해 보면 몸을 크게 움직인 것도 아니고, 특별히 어려운 일을 한 것도 아니다.
timotimo.tistory.com
글이 도움이 되셨다면 "잘 읽었습니다" 댓글 한 줄 남겨주시면 감사드리겠습니다.
다음에도 비슷한 제 포스팅을 보시려면 이 블로그를 구독해주세요!
'블로그 > 개발일지 TIL' 카테고리의 다른 글
| openssl, tar.gz 인증서 기반 배포 시 꼭 알아야 할 명령어들 (1) | 2025.03.23 |
|---|---|
| OpenSSL로 CSR, 비밀키, 인증서까지 생성하는 방법 (0) | 2025.03.23 |
| Webpack clean 옵션으로 인한 bundle 삭제 문제 해결하기 (0) | 2025.02.25 |
| [Spring] 요청 파라미터에서 값 가져오는 4가지 방법소개 (1) | 2024.10.16 |
| 간단한 레디스 명령어 정리 (GET, SET, 대표 자료형), CAP 이론, 레디스 책 추천 (0) | 2023.08.18 |
최근댓글