개발 함정 #1: ICO 파일이 멀쩡해 보여도 — BMP 프레임을 뜯어보기 전까지는
2026-06-03
이 이야기는 스토어 인증에 대한 악몽이 아니다. 그보다는 더 조용한 함정이다 — 순전히 호기심에 빠져든, 그런 종류의 이야기다.
수년 동안 나는 .ico 파일을 가장 게으른 방식으로 만들어 왔다: 256×256 PNG를 아무 온라인 변환기에 집어넣고 결과물을 받아 쓰는 식이었다. 항상 탐색기에서 제대로 보였으니, 한 번도 의심한 적이 없었다.
그러던 어느 날, ICO 언팩 도구를 만들면서 다른 제품의 ICO 파일을 테스트하다가 지저분한 것을 발견했다.
무엇을 발견했나
ICO 파일은 일종의 컨테이너다. 여러 크기(16×16, 32×32, 48×48, 64×64, 128×128, 256×256)의 이미지를 담을 수 있어서, Windows가 각 상황 — 작업 표시줄, 제목 표시줄, Alt+Tab, 파일 탐색기 — 에 맞는 크기를 골라 사용할 수 있다.
내 ICO 파일의 모든 프레임은 겉보기엔 멀쩡했다. 하지만 자세히 들여다보니:
- 256×256 프레임 (PNG로 저장) — 완벽했다. 알파 채널도 정상, 경계도 부드럽고, 아티팩트도 없었다.
- 그 외 작은 BMP 프레임들 — 투명도가 완전히 망가져 있었다. 알파 채널이 아예 없거나 쓰레기 데이터가 들어 있었다. 반투명 픽셀은 단색 덩어리로 변하고, 이상한 색상 후광이 생겼다.
작은 프레임들은 90년대 크로마키 작업을 방불케 하는 모습이었다.
온라인 변환기가 왜 이렇게 망가뜨리는가
대부분의 무료 PNG-to-ICO 변환기는 이렇게 동작한다:
- 256×256 PNG를 입력받아 필요한 각 크기(16, 32, 48 등)로 축소한다
- 256×256 프레임은 PNG로 저장한다
- 작은 프레임들은 32비트 BMP로 저장한다
하지만 ICO 파일 내부의 BMP 포맷은 특수하다. 화려한 BITMAPV5HEADER를 사용하지 않고, 표준 40바이트 BITMAPINFOHEADER를 사용하며 biBitCount를 32로 설정한다. 각 픽셀의 4번째 바이트가 알파 채널이다. 그리고 여기가 핵심: 컬러 픽셀 데이터(XOR mask) 이후에는 레거시 호환성을 위한 1비트 모노크롬 투명 마스크(AND mask)가 반드시 있어야 한다. 또한 헤더의 biHeight는 이 AND mask를 고려하여 실제 이미지 높이의 2배로 설정해야 한다.
많은 온라인 변환기가 바로 여기서 실패한다:
- 32비트 컬러를 선언해놓고 모든 픽셀의 알파 바이트(4번째 바이트)를
0x00(완전 투명) 또는 무작위 쓰레기 데이터로 채운다 - 생성한 AND mask가 알파 채널 데이터와 완전히 동기화되지 않는다
그 결과: 디렉토리 항목은 올바르고, 크기도 맞고, 탐색기도 불평하지 않아서 유효해 보이지만 — Windows가 작은 프레임을 렌더링하려고 하면 GDI blending이 폭주한다. 원인 모를 후광, 실제로는 투명하지 않은 투명 픽셀, 기타 렌더링 아티팩트가 발생한다.
왜 때가 늦을 때까지 눈치채지 못하는가
Windows 탐색기와 대부분의 앱은 256×256 PNG 프레임을 우선 사용한다. 그 프레임은 멀쩡하므로 아이콘은 모든 일반 보기에서 흠잡을 데 없어 보인다 — 큰 아이콘, 속성 대화상자, 작업 표시줄 미리보기까지.
문제의 BMP 프레임은 Windows가 특정 작은 크기로 내려서 표시해야 할 때 비로소 드러난다. 예를 들어:
| 컨텍스트 | 사용 크기 | 사용 프레임 |
|---|---|---|
| 파일 탐색기 (큰 아이콘) | 256×256 | PNG ✓ |
| 파일 탐색기 (중간/작은 아이콘) | 48×48 | BMP ✗ |
| 제목 표시줄 / 작은 아이콘 | 16×16 | BMP ✗ |
| Alt+Tab 전환기 | 32×32 | BMP ✗ |
즉, 앱 아이콘은 바탕화면에서 완벽해 보여도 제목 표시줄이나 작업 전환기에서는 알 수 없는 "후광"이나 망가진 투명도가 나타날 수 있다. 대부분은 Windows 렌더링 문제로 치부한다. 아니다 — ICO 파일 자체의 문제다.
ICO 파일 확인 방법
ICO 파일의 모든 프레임을 나열해주는 무료 도구는 많다. 다음을 확인하자:
- 프레임 포맷: 256px 프레임은
PNG로 표시되어야 한다. 작은 프레임들은BMP로 표시된다. 모든 프레임에 PNG를 사용하는 것은 ICO 사양상 기술적으로 유효하지만, 구형 Windows 버전에서 호환성 문제가 발생할 수 있다. PNG(256px) + BMP(더 작은 크기)의 조합이 가장 안전한 선택이다. - BMP 비트 심도: 진정한 알파 채널 지원(반투명 블렌딩)을 위해서는
32 BPP여야 한다.24 BPP로 나온다면 픽셀 단위 알파 데이터가 손실된 것이다. ICO의 레거시 1비트 AND mask로 기본적인 "모두 투명이거나 모두 불투명" 배경 클리핑에 폴백할 수는 있지만, 안티앨리어싱된 경계, 반투명 그라데이션, 그림자는 모두 깨지고, 보기 흉한 고체 아티팩트나 굵은 검은 테두리로 변하게 된다. - 시각적 검사: 각 프레임을 개별적으로 열어보자. 작은 프레임은 부드러운 알파가 적용되어야 하며, 들쭉날쭉한 경계나 단색 배경이 보여서는 안 된다.
해결 방법
방법 1: 제대로 된 아이콘 편집기 사용 및 변환기 테스트
원본 PNG를 가져와서 BMP 알파 채널을 올바르게 처리하는 적절한 편집기로 새 ICO를 만든다. 온라인이든 오프라인이든, 어떤 변환기를 신뢰하기 전에 테스트를 실행하자: 반투명 영역(부드러운 그림자, 그라데이션 등)이 포함된 PNG로 ICO를 생성해보고 모든 프레임을 검사한다. BMP 프레임에서 알파가 깨진 게 하나라도 발견되면 그 변환기는 사용해선 안 된다.
방법 2: PNG-only ICO (가능한 경우)
일부 최신 도구는 256×256뿐만 아니라 모든 프레임에 PNG 압축을 사용하는 ICO 파일을 지원한다. 이렇게 하면 BMP 알파 문제를 완전히 피할 수 있다. 다만, 모든 Windows 버전이나 애플리케이션에서 이 방식을 지원하지는 않으므로 — 적용 전에 반드시 테스트해야 한다.
핵심 요점
- 탐색기에서 ICO가 멀쩡해 보인다고 해서 실제로 멀쩡한 것은 아니다
- 256×256 PNG 프레임은 대체로 올바르지만, 그보다 작은 모든 BMP 프레임은 망가져 있을 수 있다
- 망가진 BMP 알파는 대부분의 보기에서는 눈에 띄지 않지만, 제목 표시줄, Alt+Tab, 작은 아이콘 컨텍스트에서 문제를 일으킨다
- 온라인 변환기에 의존하기 전에 반투명 PNG로 먼저 테스트해보자
- 배포하는 모든 아이콘은 제대로 된 아이콘 편집기를 사용하자 — 5분이면 충분하다
이 글은 개발 함정 시리즈의 일부입니다.