앱 아이콘 불일치 수정하고 빌드 설정 현행화

여러 개의 변형(variant)으로 배포되는 안드로이드 앱을 관리하다 보니, 각 변형마다 일관되지 않은 설정들이 쌓이기 시작했다. SDK 버전 타겟팅, 런처 아이콘, 스토어 메타데이터—이런 것들이 하나하나는 작아 보이지만, 모여서는 사용자에게 혼란을 주고 스토어 심사 시 까다로운 항목들이 된다. 이번엔 그 불일치들을 정리한 작업이다.

다중 변형 관리의 첫 번째 교훈

사내 서비스인 이 앱은 운영 정책에 따라 여러 페이스(face)로 나뉘어 배포된다. Apex, Azure, Carbon, Crimson—각각은 별도의 앱으로 스토어에 등록되지만, 핵심 비즈니스 로직과 UI 프레임워크는 공유한다. 이런 구조는 유지보수 효율과 일관된 품질을 보장하는 데 좋지만, 한 가지 비용이 있다: 각 변형이 자기 자신의 설정을 제대로 유지해야 한다는 것.

처음엔 페이스별로 build.gradle.kts를 각각 관리하면서 "이 정도는 큰 작업 아니지"라고 생각했다. 그런데 시간이 지나면서, 한 페이스에서 SDK 타겟팅을 업그레이드하고 나머지는 깜빡하거나, 한 페이스의 아이콘 리소스가 구식 해상도(xxxhdpi)로 남아있거나, 스크린샷 메타데이터가 흩어지곤 했다. 특히 구글 플레이 스토어 정책이 점점 엄격해지면서 이런 "작은 불일치"들이 심사 거부 사유가 되기 시작했다.

이번 작업의 구체적 내용

가장 주의깊은 변경은 런처 아이콘 리소스 업데이트였다. 사용자가 홈 화면에서 처음 마주치는 게 앱 아이콘인데, 각 페이스마다 다른 디자인 시스템을 따르다 보니 해상도나 패딩이 다르게 제공되고 있었다. 특히 xxxhdpi(가장 고해상도)는 최신 고급 기기들을 대상으로 하는 것인데, 옛날 리소스 그대로 두면 흐릿해 보인다. 스토어 심사자들도 주로 고급 기기에서 테스트하니까, 이런 세세한 부분이 느낌을 좌우한다.

스크린샷 저장이라는 항목도 흥미로운데, 앱 스토어에 올리는 스크린샷들(앱 소개 이미지)을 버전 관리 대상으로 넣기로 결정한 것 같다. 이건 CI/CD 파이프라인이나 스토어 자동 배포 도구와 연계할 때 유용하다. 스크린샷이 코드와 함께 커밋되면, 메이저 업데이트 때 누가 어떤 스크린샷으로 배포했는지 추적 가능하고, 실수로 옛 스크린샷을 업로드하는 일도 막을 수 있다.

왜 이게 "chore"일까

이런 작업들은 사용자 기능을 직접 추가하거나 버그를 고치는 것도 아니고, 성능을 개선하는 것도 아니다. 그럼에도 필수다. 특히 팀 입장에서 생각해 보면:

• 스토어 심사 안정성: 정책을 따르지 않으면 출시 지연
• 일관성의 빚: 지금 해결 안 하면 나중에 더 복잡해짐
• 온보딩 경험: 새 팀원이 여러 변형을 다룰 때, 일관된 구조가 있으면 실수가 줄어듦

다만 내가 하면서 느낀 점은, 이런 작업들이 자동화될 여지가 크다는 것이다. 예를 들어:
- SDK 타겟팅은 gradle 플러그인으로 여러 모듈에 일괄 적용 가능
- 런처 아이콘은 빌드 단계에서 자동으로 리사이징/검증
- 스크린샷 메타데이터는 깃훅으로 커밋 시 확인

지금은 수동이지만, 다음 프로젝트나 팀 규모가 커질 땐 이런 chore를 걸러내는 도구 만들어 두면 좋을 것 같다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.