앱 런처 아이콘을 전 해상도와 Android adaptive까지 한 번에

앱 런처 아이콘을 전 플랫폼 해상도 + Android adaptive 아이콘까지 한 번에 적용했다.

왜 이 타이밍에 아이콘을 붙였나

앱 개발 초반엔 기본 Flutter 아이콘 그대로 두고 기능 구현에 집중하는 게 일반적이다. 그런데 어느 시점부터는 그 기본 아이콘이 슬슬 눈에 걸리기 시작한다. 내부 테스트 빌드를 팀원들 폰에 깔아두면 홈 화면에서 Flutter 기본 로고가 떡하니 박혀 있고, 외부에 데모를 보여줄 때도 첫인상이 영 아쉽다. 이번 커밋은 그 타이밍을 더 이상 미루지 않기로 한 결정이었다.

아이콘 컨셉은 "성경+빛"으로 잡았다. 앱의 정체성을 아이콘 하나로 표현하는 작업이기 때문에 디자인 방향을 먼저 정리하고 들어갔다.

변경 파일로 보는 작업 범위

파일 목록만 봐도 꽤 촘촘하게 챙겼다는 게 보인다. 각 density 폴더에 foreground 이미지를 다 넣고, 거기에 anydpi-v26 XML까지 추가했으니 Android 구버전(API 25 이하)부터 최신 Android까지 전부 커버되는 구조다.

Adaptive Icon을 제대로 챙겨야 하는 이유

mipmap-anydpi-v26/ic_launcher.xml 이 파일이 이번 작업에서 가장 핵심이다. Android 8.0(API 26)부터 도입된 adaptive icon은 foreground 레이어와 background 레이어를 분리해서, 런처마다 다른 마스크 모양(원형, 둥근 사각형, 스쿼클 등)에 맞게 아이콘을 잘라준다.

<!-- mipmap-anydpi-v26/ic_launcher.xml 구조 예시 -->
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@color/ic_launcher_background"/>
    <foreground android:drawable="@drawable/ic_launcher_foreground"/>
</adaptive-icon>

이걸 제대로 안 챙기면 삼성 One UI 런처에서는 원형으로 잘리고, Pixel 런처에서는 스쿼클로 잘리는 등 기기마다 아이콘 모양이 제각각으로 보인다. 심한 경우엔 중요한 디자인 요소가 마스크에 잘려 나가버린다. foreground 이미지를 만들 때 safe zone(전체 영역의 약 66%)을 반드시 고려해야 하는 이유가 여기 있다.

여러 해상도를 직접 손으로 넣는 방식

Flutter 생태계에서는 flutter_launcher_icons 패키지를 쓰면 소스 이미지 하나로 모든 density 파일을 자동 생성해주는 게 일반적이다. 그런데 이번엔 각 해상도별 파일을 직접 넣는 방식을 택했다. 자동화 툴이 adaptive icon XML 커스터마이징까지 완전히 맡기기 애매하거나, foreground/background 레이어를 세밀하게 제어하고 싶을 때 이 방식이 더 직관적이다.

물론 trade-off는 있다. 소스 이미지가 바뀔 때마다 density별 파일을 다시 export해서 수동으로 교체해야 한다. 팀 규모가 커지거나 아이콘 변경이 잦아지면 자동화로 전환하는 게 맞다. 지금 단계에서는 이 정도 관리 비용이 충분히 감당 가능하다고 판단했다.

아이콘 하나 붙이는 작업이지만, density 대응 + adaptive 대응을 제대로 하려면 생각보다 신경 쓸 포인트가 많다. 특히 Android adaptive icon의 safe zone 개념은 한 번쯤 직접 기기에서 확인해보지 않으면 나중에 QA 단계에서 "아이콘이 잘려요" 이슈로 돌아오기 쉽다. 이번에 꼼꼼하게 챙겨서 다행이다.

끝.

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

• 안드로이드개발책 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

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