픽셀을 재라, 추측하지 말고

앱 아이콘 하나를 올리면서 이상한 걱정이 생겼다. 내가 이미 둥글게 만들었는데, 운영체제가 또 한 번 둥글려서 이중으로 둥글어지는 거 아닐까. 그 걱정이 사실인지 아닌지 알 수 있는 방법은 딱 하나였다. 재보는 것.

더치페이 앱 아이콘을 새로 만들었다. 기존 아이콘이 영 허술해 보여서 이번에 제대로 손을 보기로 했고, ChatGPT로 시안을 뽑아 맘에 드는 걸 골랐다. 딥네이비 배경에 카드와 동전을 배치한 꽤 그럴싸한 디자인이었다.

그런데 PNG 파일을 flutter_launcher_icons로 iOS와 Android 전 사이즈에 적용하기 직전, 걱정이 하나 생겼다. 내가 받은 마스터 PNG에 모서리 라운딩이 이미 들어가 있었다. 배경이 완전한 사각형이 아니라, 모서리가 살짝 깎여 있었던 것이다.

여기서 문제가 된다고 생각한 건 iOS의 동작 방식이었다.

iOS는 아이콘을 한 번 더 자른다

iOS는 앱 아이콘을 표시할 때 마스크를 덧씌운다. 네 귀퉁이를 둥글게 잘라내는 것인데, 그 비율이 전체 너비의 약 22%에 달한다. 상당히 큰 면적이다.

내 아이콘은 이미 모서리가 둥글었다. 그 위에 iOS 마스크가 또 한 번 둥글게 자른다면, 모서리가 두 번 가공되는 셈이다. 디자이너들이 “이중 라운딩”이라고 부르는 현상이다. 첫 번째 라운딩이 그대로 드러나서 아이콘 가장자리가 어색하게 보이거나, 심하면 의도하지 않은 검은 귀퉁이가 iOS 마스크 경계 바로 안쪽에 남는다.

걱정은 타당했다. 하지만 그 걱정이 실제로 문제가 되는지는 별개의 질문이었다.

픽셀을 직접 재다

PNG를 열고 모서리를 들여다봤다. 정확히는, 라운딩이 시작되는 지점이 전체 이미지 크기의 몇 퍼센트 지점인지를 쟀다.

결과는 5%였다.

아이콘의 총 너비가 1024픽셀이라면, 라운딩이 시작되는 건 가장자리에서 51픽셀쯤 들어온 지점이다. iOS 마스크는 그보다 훨씬 안쪽인 약 22% — 225픽셀 지점 — 에서 잘라낸다. 즉 내 라운딩이 존재하는 5% 영역 전체가 iOS 마스크의 절삭 범위 안에 들어간다. iOS가 잘라낼 부분에만 라운딩이 있었던 것이다.

이중 라운딩은 일어나지 않는다. 걱정은 사실이 아니었다.

추측은 두 가지 방향으로 틀린다

이 상황을 돌이켜 보면 흥미롭다. 내가 픽셀을 재지 않았다면 두 가지 방향으로 틀릴 수 있었다.

첫째, 이중 라운딩이 문제가 된다고 잘못 판단해서 멀쩡한 아이콘을 뜯어고치는 쪽. 추가 작업이 생기고, 오히려 이미지가 나빠질 수도 있다. 둘째, 이중 라운딩이 문제가 안 된다고 잘못 낙관해서 이상한 아이콘을 그냥 올리는 쪽. 심사에서 아이콘이 걸리거나, 유저들이 어색함을 느낄 수 있다.

추측은 어느 방향으로든 비용이 붙는다. 과잉 대응의 비용이든, 방치의 비용이든.

측정은 그 비용을 거의 0으로 만든다. 픽셀 수를 세는 데 걸리는 시간은 5분이 채 안 됐고, 그 5분이 잘못된 결정 두 가지를 모두 막아줬다.

다듬기는 했다, 하지만 이유가 달랐다

픽셀을 재고 나서 아이콘을 그대로 올리진 않았다. 모서리를 다듬기로 결정했다. 하지만 이유가 달라졌다.

이중 라운딩 걱정 때문이 아니라, 순수하게 더 보기 좋게 만들기 위해서였다. 모서리의 순흑 끝부분을 주변 네이비 색상으로 방사형으로 확장해, 아이콘이 어느 배경 위에 놓여도 깔끔하게 보이도록 했다. 측정이 걱정을 지워주고 나서야, 비로소 진짜 개선에 집중할 수 있었다.

걱정이 있을 때는 걱정을 다루느라 에너지가 묶인다. 걱정이 사실인지 아닌지를 확인하고 나면, 그 에너지가 풀린다.

같은 날의 다른 사례

비슷한 일이 같은 날 또 있었다. 헤드리스 환경 — 화면이 없는 서버 — 에서 게임 로직이 제대로 동작하는지 확인해야 했다. “아마 될 거야” 로 넘어가는 대신, 군중 카운트가 게이트를 통과할 때 실제로 바뀌는지를 로그로 찍었다.

출력은 이랬다.

[selftest] start crowd=10
[gate] 10 x2 -> 20
[gate] 20 +5 -> 25
[selftest] end crowd=25 (expect 25)

게임을 실행해서 눈으로 볼 수 없는 상황이었다. 하지만 숫자가 기대대로 바뀌는 걸 찍어두면, “동작한다”는 말이 추측에서 사실이 된다.

아이콘 픽셀이든 게임 로직이든, 방법은 같았다. 확인할 수 있는 걸 실제로 확인한다.

측정이 설계보다 앞서는 경우

흔히 설계를 먼저 하고 검증은 나중에 한다고 생각한다. 그런데 이날의 경험은 순서가 바뀔 때도 있다는 걸 보여줬다.

걱정이 생기면 그 걱정이 사실인지 아닌지를 먼저 재는 게 옳다. 재고 나서야, 어떻게 대응할지를 설계할 수 있다. 이중 라운딩이 실제 문제라면 대응 방법은 여러 가지였을 것이다. 하지만 측정 결과 문제가 없다면, 대응 설계 자체가 필요 없어진다.

추측 위에서 설계를 시작하면, 존재하지 않는 문제를 해결하는 작업이 생겨난다. 그 작업은 코드가 될 수도 있고, 수정된 이미지가 될 수도 있고, 쓴 문서가 될 수도 있다. 하지만 전부 처음부터 불필요했던 것들이다.

한 줄

추측이 맞는지 틀린지를 확인하는 가장 빠른 방법은 재보는 것이다.

이 글은 더치페이 앱 아이콘 적용 과정에서 겪은 이중 라운딩 검증 에피소드를 바탕으로 썼습니다.

— 강대종