[Android] 안드로이드 오픈소스 라이선스 고지 화면 구성 및 릴리스 체크리스트
안드로이드 앱 개발하다 보면 Retrofit, OkHttp, Glide, Gson, 코루틴 같은 오픈소스 라이브러리를 거의 숨 쉬듯 쓰게 됩니다. 저의 경우도 기능 구현에만 매몰되다 보면, 오픈소스 라이선스 고지 작업은 맨 뒤로 미뤄두는 귀찮은 부가 작업처럼 느껴지곤 했습니다.
하지만 앱을 구글 플레이 스토어에 배포하거나 외주 프로젝트를 납품할 계획이 있다면, 라이선스 관리는 처음부터 따로 정리를 해두는 편이 정신 건강에 좋습니다. 오픈소스가 무료라곤 하지만, 라이선스 조건까지 없는 것은 아니기 때문입니다.
출시 직전에 급하게 챙기다가 누락되거나 꼬여서 고생하는 경우가 많습니다. 제가 앱을 운영하면서 정리한 라이선스 화면의 필요성과 관리 기준을 공유합니다. 자꾸 까먹어서 기록해 두는 목적도 있습니다.
오픈소스 라이선스 화면이 필요한 이유
네트워크 통신, 이미지 로딩, 비동기 처리 등 기본 기능을 구현할 때 외부 라이브러리는 필수입니다. 다만 아무 조건 없이 가져다 써도 된다는 뜻은 아닙니다. 라이선스 종류에 따라 저작권 고지나 원문 포함 같은 의무 조건이 붙습니다.
저의 경우 아래 4가지 관점에서 라이선스 화면을 꼭 챙깁니다.
- 투명성: 앱에서 사용한 외부 기술을 사용자에게 명확히 안내합니다.
- 법적 조건 충족: 라이선스에서 요구하는 저작권 및 원문 고지 의무를 지킵니다.
- 유지보수: 라이버러리를 업데이트하거나 바꿀 때 누락 여부를 확인하기 좋습니다.
- 검수 기준: 앱 심사나 마켓 제출 전 최종 검수 리스트로 활용합니다.
운영 관점에서는 나중에 배포 직전에 부랴부랴 만드는 것보다, 초기 세팅 때 앱 정보 화면 한구석에 자리를 미리 만들어두는 것이 훨씬 안정적입니다.
앱 정보 화면과 라이선스 화면은 분리하는 것이 상책
간혹 귀찮아서 앱 정보 화면 하나에 라이선스 문구까지 통째로 넣는 경우가 있습니다. 하지만 라이브러리가 조금만 늘어나도 앱 버전, 고객센터, 개인정보 처리방침과 뒤섞여 화면이 지저분해지고 무거워집니다.
그래서 보통 앱 정보 화면에서는 버튼 하나만 두고, 상세 목록은 별도 화면으로 분리하는 구조를 씁니다.
화면별 역할 구성 정보
| 앱 정보 화면 | 앱의 기본 정보 안내 | 앱 버전, 문의, 정책 링크, 오픈소스 라이선스 진입 버튼 | 라이선스 원문을 다 넣어서 화면을 무겁게 만들지 말 것 |
| 오픈소스 목록 | 사용 라이브러리 목록 제공 | 라이브러리명, 저작권, 라이선스 종류 | 실제로 사용하지 않는 라이브러리는 넣지 말 것 |
| 라이선스 상세 | 라이선스 원문 확인 | 라이선스 전문, 라이브러리 출처 | 라이선스 문구를 임의로 수정하지 말 것 |
처음 시작할 때는 단순한 리스트 뷰 하나로 시작해도 충분합니다. 중요한 것은 사용자가 앱 안에서 라이선스 고지를 명확히 찾아 들어갈 수 있느냐입니다.
라이선스 목록에 들어가야 하는 필수 항목
이름만 띡 적어놓는 구조는 피해야 합니다. 최소한 나중에 검수하거나 문제가 생겼을 때 추적이 가능한 기준 정보는 남겨두어야 합니다.
| 라이브러리명 | 앱에서 사용하는 오픈소스 이름 | OkHttp, Retrofit, Glide |
| 라이선스 종류 | 해당 라이브러리의 라이선스 타입 | Apache License 2.0, MIT License |
| 저작권 고지 | 라이선스에서 요구하는 저작권 문구 | Copyright (c) 2026 ... |
| 출처 / 프로젝트명 | 공식 저장소나 프로젝트 식별 정보 | 공식 GitHub 주소 또는 프로젝트명 |
| 라이선스 원문 | 라이선스 전문 또는 확인 문서 | 원문 텍스트 전체 |
라이브러리 업데이트 때 자꾸 놓치는 단골 실수
라이선스 화면은 한 번 만들고 끝나는 정적 페이지가 아닙니다. 코드가 바뀌고 빌드 세팅이 바뀔 때 함께 갱신되어야 합니다. 운영하다 보면 꼭 이런 데서 구멍이 납니다.
- 새 라이브러리 추가하고 라이선스 목록에는 안 넣는 경우
- 안 쓰는 라이브러리를 지웠는데 라이선스 화면에는 계속 남아있는 경우
- 버전 업그레이드하면서 라이선스 정책이 바뀌었는데 확인 안 하는 경우
- 특히 주의: 테스트용(Debug) 라이브러리를 운영(Release) 앱 목록에 잘못 포함하는 경우
- 텍스트가 너무 길다고 라이선스 원문을 임의로 요약하거나 수정하는 경우
자주 안 보는 화면이라 놓치기 쉽습니다. 그래서 저는 배포 체크리스트에 '오픈소스 고지 확인'을 무조건 넣어둡니다.
간단한 Android 화면 데이터 구조 예시
화면을 그릴 때 사용할 기본적인 데이터 클래스 예시입니다. 결국 일반적인 리스트 컴포넌트 구현과 다를 바 없습니다.
data class OpenSourceLicenseItem(
val name: String,
val licenseName: String,
val copyright: String,
val licenseText: String
)
주의할 점: UI 레이아웃을 예쁘게 짜는 것보다 데이터의 정확도가 중요합니다. 원문 텍스트가 너무 길면 줄이려고 하지 말고, 스크롤 뷰를 적용하거나 별도 팝업/상세 페이지로 빼서 원문 그대로 노출해 줘야 합니다.
수동 관리 vs 자동 생성 방식 비교
이걸 일일이 텍스트 파일로 치고 있을지, 플러그인을 쓸지 고민이 되실 겁니다. 프로젝트 상황에 맞게 선택하시면 됩니다.
| 수동 작성 | 구조가 단순하고 원하는 UI로 커스텀하기 매우 쉽다. | 라이브러리 가감 시 누락이 생기기 쉽다. | 라이브러리 수가 몇 개 안 되는 소규모 앱 |
| 자동 생성 도구 사용 | Gradle 플러그인 등으로 빌드 시점에 자동 파싱하므로 누락이 없다. | 결과물 검수가 한 번 더 필요하고, UI 커스텀에 제약이 있다. | 라이브러리가 많거나 업데이트가 잦은 대형 프로젝트 |
| 혼합 방식 | 자동 생성된 플러그인 결과물을 기반으로 앱 UI 템플릿에 맞게 가공한다. | 관리 규칙을 초기에 잘 정하지 않으면 데이터가 꼬인다. | 팀 단위 프로젝트 및 지속 운영 중인 서비스 |
라이선스 문구를 임의로 손대지 마세요
간혹 화면 가독성을 높이겠다고 라이선스 본문을 요약하거나 바꾸는 분들이 있습니다. 이건 법적 고지 의무를 위반하는 위험한 행동입니다.
- 원문은 무조건 공식 문서나 저장소 기준으로 확인해서 통으로 넣습니다.
- 저작권 문구(Copyright) 역시 임의 삭제 금지입니다.
- 잘 모른다고 대충 '이거겠지' 하고 라이선스 종류를 추측해서 쓰면 안 됩니다.
- 회사 내부나 비공개 라이브러리 코드가 오픈소스 목록 예시에 노출되지 않도록 패키지 필터링을 신경 써야 합니다.
출시 전 최종 테스트 체크리스트
배포하기 직전에 QA 단계에서 아래 항목은 한 번씩 꼭 눌러보고 확인하시는 것을 권장합니다.
- [ ] 앱 정보 화면에서 오픈소스 라이선스 메뉴로 정상 진입하는가?
- [ ] 이번 버전에 새로 추가되거나 삭제된 라이브러리가 목록에 잘 반영되었는가?
- [ ] 라이선스 원문과 저작권 문구가 잘림 없이 스크롤로 모두 표시되는가?
- [ ] 디버그 전용 라이브러리(leakcanary 등)가 운영 배포판 목록에 노출되고 있지 않은가?
- [ ] 플레이 스토어 제출 전 개인정보 처리방침 링크와 함께 라이선스 화면 작동 여부를 확인했는가?
마무리
안드로이드 앱 만들 때 기능 구현이나 UI 디자인에 비해 오픈소스 라이선스 화면은 우선순위가 뒤로 밀리기 마련입니다. 하지만 엄연히 법적 고지 의무가 있는 영역이고, 나중에 스토어 심사나 저작권 이슈로 태클 걸리면 귀찮아지는 부분이기도 합니다.
규모가 작은 앱이라도 초반에 앱 설정이나 정보 화면을 만들 때 미리 파이프라인을 구축해 두거나 체크리스트에 올려두는 편이 나중에 공수를 줄이는 지름길입니다.
참고 자료
- Android Developers, Play Console and app publishing documentation
- Google Open Source, Licenses documentation
- Apache License 2.0 공식 문서
- MIT License 공식 문서