1992년 Macintosh Human Interface Guidelines의 아이콘 원칙을 바탕으로, macOS Tahoe가 메뉴 전반에 아이콘을 무차별적으로 추가하며 일관성·가독성·의미 전달 측면에서 어떤 문제를 만들었는지 분석한다.
저는 1992년의 Macintosh Human Interface Guidelines를 여기에서 읽고 있었는데, 이런 멋진 삽화를 발견했습니다:
설명도 함께 있었죠:
시간을 훌쩍 넘겨 2025년. Apple은 macOS Tahoe를 출시합니다. 가장 큰 볼거리요? 모든 메뉴 항목에 불쾌하고, 산만하고, 읽기 어렵고, 지저분하고, 복잡하고, 헷갈리고, 짜증나는 아이콘(그들의 표현이지 제 표현이 아닙니다!)을 추가한 것:
Sequoia → Tahoe
나쁩니다. 그런데 정확히 뭐가 왜 나쁠까요? 파고들어 봅시다!
주의: 스크린샷은 macOS 26.1과 26.2가 섞여 있으며, 시스템에 기본으로 설치되어 있는 Apple 기본 앱에서만 가져왔습니다. 어떤 시스템 설정도 변경하지 않았습니다.
아이콘의 주된 기능은, 사용자가 찾는 것을 더 빠르게 찾도록 돕는 것입니다.
직관에 반할 수 있지만, 모든 것에 아이콘을 붙이는 건 정확히 반대 방향으로 가는 일입니다. 눈에 띄려면 ‘달라야’ 합니다. 하지만 모든 것에 아이콘이 있으면, 아무것도 눈에 띄지 않습니다.
색도 마찬가지입니다. 흑백 아이콘은 깔끔해 보이지만, 더 빨리 찾는 데는 도움이 되지 않습니다!
Microsoft는 예전엔 이걸 알고 있었습니다:
오른쪽 변형에서 Save나 Share를 얼마나 더 빨리 찾을 수 있는지 보세요:
더 깔끔해 보이기도 합니다. 덜 복잡하죠.
색을 넣은 버전은 더 낫습니다(텍스트와 아이콘이 더 명확히 분리되고, 더 빨리 찾게 됨):
이게 보기 좋지 않다는 건 압니다. 저도 싫습니다. 이런 아이콘은 다루기 어렵습니다. 색이 예쁘게 보이도록 실제로 ‘색을 전제로’ 디자인해야 하거든요. 하지만 원칙은 그대로입니다. 사용하기는 훨씬 쉽습니다.
아이콘이 제대로 작동하려면, _일관적_이어야 합니다. 무엇을 찾아야 하는지 학습할 수 있어야 하죠.
예를 들어, “Cut” 명령을 보고 옆에 
가 있다면, 저는 “오케이”라고 생각합니다. 다음에 “Cut”을 찾을 때는, 를 먼저 찾는 방식으로 시간을 절약할 수 있겠죠.
Tahoe는 이 측면에서 어떤가요? “New”의 50가지 그레이 톤을 보여드리죠:
상황의 황당함이 더 잘 드러나도록, 전부 한데 모아봤습니다.
물론 일부는 다른 작업이니 다른 아이콘이 있을 수 있습니다. 스마트 폴더 만들기와 저널 엔트리 만들기가 다르다는 건 알겠어요. 하지만 이건요?
또는 이건:
또는 이건:
변명할 여지가 없습니다.
Open도 마찬가지입니다:
Save:
네. 그중 하나는 체크마크입니다. 심지어 화살표 방향조차 합의하지 못했죠!
Close:
Find(어떤 때는 Search, 어떤 때는 Filter라고 불림):
Delete(Cut-Copy-Paste-Delete로 유명한 그 Delete):
창 최소화.
이건 어떤 희귀하고 특이한 작업이 아닙니다. OS의 기본이고, 기초이며, 근간입니다. 모든 앱에 있고, 항상 같은 위치에 있습니다. 다르게 보이면 안 됩니다!
아이콘은 툴바에서도 쓰입니다. 개념적으로 툴바의 작업은 메뉴를 통해 호출하는 작업과 동일하며, 따라서 같은 아이콘을 써야 합니다. 구현하기 가장 쉬운 경우죠. 같은 앱 안에서, 종종 같은 화면에 있는데. 일관성을 지키는 게 그렇게 어렵나요?
Preview:
Photos: 동일한 
와 
불일치, 하지만 반대로 되어 있음 ¯_(ツ)_/¯
Maps와 다른 앱들은 줌에 종종 서로 다른 기호를 씁니다:
또 하나의 중대한 죄는, 서로 다른 동작에 동일한 아이콘을 쓰는 것입니다. 상상해 보세요: 저는 
가 “New”를 뜻한다고 배웠습니다:
그다음 앱을 열었는데 를 봅니다. “좋아,” 저는 생각합니다. “이미 의미를 알고 있어”:
낚였죠!
이제 
는 빠른 미리보기(quick look)를 의미한다고 생각하겠죠:
가끔은 그렇습니다. 그런데 또 어떤 경우에는 가 “완료된 항목 보기(Show completed)”를 뜻합니다:
어떤 때는 
가 “Import”:
어떤 때는 가 “Updates”:
일관성과 마찬가지로, 아이콘 재사용은 앱 간에서만 일어나지 않습니다. 가끔 툴바에서 
를 봅니다:
그런 다음 같은 앱 의 메뉴로 가면 가 다른 의미입니다:
가끔은 같은 메뉴에서 동일한 아이콘이 맞닥뜨리기도 합니다.
가끔은 서로 옆에.
가끔은 동일한 아이콘을 한 줄로 기관총처럼 늘어놓습니다:
이건 누구에게도 도움이 되지 않습니다. 아이콘이 전부 같다면 어떤 사용자도 더 빨리 메뉴 항목을 찾지 못하고, 기능을 더 잘 이해하지도 못합니다.
지금까지 아이콘 재사용의 최악 사례는 Photos 앱입니다:
각 메뉴 항목에 고유한 아이콘을 고르라는 임무를 받은 사람이 그냥 아이디어가 바닥난 느낌입니다.
이해는 갑니다.
아이콘을 볼 때 우리는 보통 약간의 구현 차이는 허용합니다. 예를 들어, 기술적으로는 다른 이 도로 표지들이 같은 의미임을 이해할 수 있는 것처럼요:
아이콘도 마찬가지입니다. 한 곳에서는 상자 밖으로 나가는 화살표를 그리고, 다른 곳에서도 상자와 화살표를 조금 다른 각도나 다른 선 두께로 그리거나, 하나는 채우고 하나는 비워도, 우리는 같은 의미라고 이해합니다.
예를 들어, 가 
와 다른 의미여야 한다고요? 제발요!
또는 폰트 크기만 살짝 다른 두 개의 A:
연필은 “Rename”인데 조금 더 두꺼운 연필은 “Highlight”?
대각선이 다른 화살표?
3개의 점이 공간의 ⅔를 차지하는 것 vs 공간을 다 차지하는 것. 진심인가요?
점이 약간 더 진한 것?
종이 한 장이 모서리가 접혔는지, 안에 줄이 있는지에 따라 의미가 바뀌는 것?
하지만 최종 보스는 화살표입니다. 전부 다 다릅니다:
사용자가 원의 찌그러진 정도, 시작점이 위에서 오른쪽인지 아래에서 오른쪽인지, 화살표 끝이 얼마나 뻗는지 같은 것을 알아차리는 전문가가 되어야 한다는 얘기죠.
제가 그런 걸 신경 쓰나요? 솔직히 아니요. Apple이 이런 차이를 일관되게 적용했다면, 어쩌면 시도는 해봤을지도 모릅니다. 하지만 Apple은 어떤 곳에서는 와 
를 같은 의미로 취급하면서, 다른 곳에서는 이런 미세한 디테일을 알아차리길 기대한다?
죄송하지만, 저는 당신을 신뢰할 수 없습니다. 지금까지 본 모든 것 이후로는요.
아이콘은 멀리서도 쉽게 알아볼 수 있어야 합니다. 모든 아이콘 디자이너가 알죠. 작은 디테일은 금물입니다. 미적 목적이라면 가끔 넣을 수는 있지만, 그 디테일에 의존 하면 안 됩니다.
그런데 Tahoe 메뉴의 아이콘은 아주 작습니다. 대부분은 12×12 픽셀 정사각형 안에 들어갑니다(레티나 때문에 실제 해상도는 24×24). 그리고 많은 아이콘이 정사각형이 아니라서, 한 변은 보통 12보다 더 작습니다.
작업할 공간이 정말 좁습니다! Windows 95도 16×16 아이콘을 썼습니다. 당시 전형적인 DPI를 72로 잡으면 물리적 크기는 0.22인치(5.6mm)입니다. 최신 MacBook Pro의 254 DPI에서 Tahoe의 24×24 아이콘은 0.09인치(2.4mm)입니다. 물론 24가 16보다 크지만, 실제로는 아이콘 면적이 4배나 작습니다!
72 DPI에서 16×16(왼쪽)과 254 DPI에서 24×24(오른쪽)의 물리 크기 비교 시뮬레이션
그래서 이걸 보면:
저는 힘듭니다. 서로 다르다는 건 알겠는데, 무엇을 그렸는지는 확실히 힘들어요.
20배 확대해도 여전히 엉망입니다:
또 여기. 서로 다른 아이콘이 3개입니다:
여기서 플러스 기호와 반짝임(sparkle)을 구분하라는 건가요?
어떤 선은 다른 선보다 반 픽셀만큼 더 두껍고, 그게 핵심이라는 듯합니다:
이건 화살표인가요?
붓인가요?
보세요, 아주 작은 카메라.
20배 확대하면 거의 보일 듯한, 더 작은 뷰파인더까지 달려 있습니다:
또 여기. 박스가 있고, 그 안에 원이 있고, 그 안에 총 높이 2픽셀짜리 아주 작은 i 글자가 있습니다:
안 보이나요?
저는 안 보입니다. 그래도 있긴 있어요...
그리고 이건 창입니다! 신호등도 있어요! 정말 귀엽네요:
기억하세요: 이건 레티나 픽셀, 즉 실제 픽셀의 ¼입니다. 스티브 잡스 본인이 이건 보이지 않는다고 주장했죠.
It turns out there’s a magic number right around 300 pixels per inch, that when you hold something around to 10 to 12 inches away from your eyes, is the limit of the human retina to differentiate the pixels.
그런데도 Tahoe 아이콘은 사용자가 그걸 볼 수 있기를 전제로 합니다.
이렇게 공간이 적을 때는, 모든 픽셀이 중요합니다. 좋은 아이콘을 만들 수는 있지만, 픽셀을 아주 신중하게 선택해야 합니다.
Tahoe 아이콘에서 Apple은 전통적인 비트맵 대신 벡터 폰트를 사용하기로 했습니다. Apple 입장에서는 리소스 절약이죠. 한 번 그리면 어디서나 사용. 어떤 크기든, 어떤 디스플레이 해상도든, 어떤 폰트 폭이든.
하지만 단점이 있습니다. 폰트는 수직 위치 잡기가 어렵고, 크기가 픽셀과 직접 매핑되지 않으며, 선 두께도 픽셀 그리드에 1:1로 맞지 않죠. 그래서 어디서든 동작하긴 하지만, 어디서든 흐릿하고 평범해 보입니다:
Tahoe 아이콘(왼쪽)과 픽셀 그리드에 맞춘 버전(오른쪽).
픽셀을 더 많이 주면 확실히 더 나아집니다.
iPad OS 26 vs macOS 26
혹은 그래픽을 더 단순하게 만들면요. 하지만 작은 디테일과 작은 아이콘 크기의 조합은 치명적입니다. 그래서 Apple이 380+ DPI의 MacBook을 내놓기 전까지는, 아쉽지만 픽셀 그리드를 여전히 신경 써야 합니다.
아이콘은 또 다른 기능을 할 수도 있습니다. 사용자가 명령의 의미를 이해하도록 돕는 것이죠.
예를 들어, 맥락(창 이동)을 알면 이 아이콘들은 말보다 더 빠르게 상황을 설명합니다:
하지만 이게 작동하려면, 사용자가 아이콘에 그려진 것이 무엇인지 이해해야 합니다. 명확한 컴퓨터 동작으로 연결되는 친숙한 물체(예: 휴지통 → 삭제), 널리 쓰이는 상징, 또는 이해하기 쉬운 다이어그램이어야 하죠. HIG:
초보적인 실수는 대상 물체를 잘못 표현하는 것입니다. 예를 들어, 선택(selection)은 이렇게 생겼습니다:
하지만 아이콘은 이렇게 생겼죠:
솔직히 저는 이 글을 일주일 동안 쓰고 있는데도, 왜 저렇게 생겼는지 전혀 감이 없습니다. 저렇게 생긴 건 있긴 한데, Freeform/Preview에서 텍스트 블록입니다:
SF Symbols에서는 character.textbox라고 부릅니다:
왜 그게 “Select all”의 은유가 되었을까요? 제가 보기엔 실수라는 게 가장 그럴듯합니다.
다른 곳에서는 iOS의 텍스트 선택을 은유로 씁니다. 맥에서요!
어떤 개념은 명백하거나 잘 확립된 은유가 있습니다. 그런 경우 그걸 쓰지 않는 건 실수입니다. 예를 들어 북마크: 
. 그런데 Apple은 어째서인지 책(book)으로 갔습니다:
가끔은 이미 존재하는 UI 요소를 아이콘으로 쓸 수도 있습니다. 다만 사용자를 혼란스럽게 하지는 마세요. 직사각형 안의 점들은 권한(permissions)이 아니라 비밀번호 입력처럼 보입니다:
여기 아이콘은 “Check”라고 말하는데 동작은 “Uncheck”입니다.
끔찍한 실수죠. 아이콘이 도움은커녕, 적극적으로 사용자를 헷갈리게 합니다.
또 하나의 유혹은 2단계 아이콘을 만드는 것입니다. 어떤 물체 + 표시자 조합. 예를 들어 체크박스와 X로 “체크박스 삭제(Delete checkbox)”를 뜻한다든지:
또는 사용자와 체크마크로 “사용자 확인(Check the user)” 같은:
불행히도 이런 구성은 대개 잘 작동하지 않습니다. 사용자는 당신이 제공한 블록을 조합해 문장을 만들지 않아요. 이런 퍼즐을 풀고 싶어 하지도 않습니다.
은유를 찾는 건 어렵습니다. 명사(nouns)는 동사(verbs)보다 쉽고, 메뉴 항목은 대부분 동사입니다. Open은 어떻게 생겼나요? 오른쪽 위를 가리키는 화살표처럼? 왜죠?
저는 “Open”에 Apple이 놓친 명확한 은유가 있다고 말하려는 게 아닙니다. 그런 건 없습니다. 하지만 그게 핵심입니다. 좋은 은유를 찾을 수 없다면, 나쁘고 혼란스럽고 의미 없는 아이콘을 쓰느니 아이콘을 안 쓰는 게 낫습니다.
저는 은유 품질을 시험하는 게임을 좋아합니다. 레이블을 지우고 의미를 맞혀보는 거죠. 한 번 해보세요:
충분히 열심히 생각하면 모든 동작에 좋은 아이콘이 존재한다고 믿는 건 망상입니다. 그런 건 없습니다. 시작부터 진 싸움입니다. 돈을 아무리 쓰든 “경영 판단”을 하든 바뀌지 않습니다. 문제는 100% 자업자득입니다.
그렇다고 해도, 공정하게 말하자면 Apple이 은유를 잘 고를 때는 정말 잘 고릅니다:
혼란스러운 은유의 특수한 경우는, 서로 정반대인 동작에 서로 다른 은유를 쓰는 것입니다. 예: Undo/Redo, Open/Close, Left/Right.
좋은 경우는 아이콘이 같은 은유를 공유하는 것입니다:
왜냐하면 시간과 인지 자원을 절약해주니까요. 하나 배우면, 하나는 공짜로 얻습니다.
그래서 관련 동작에 일반적인 은유를 쓰지 않는 건 실수입니다:
또는 여기:
또 다른 실수는, 대칭이 없는 곳에 대칭을 만들어버리는 것입니다. “Back”과 “See all”?
Tahoe의 어떤 메뉴들은 두 가지 실수를 모두 저지릅니다. 예: Show/Hide 사이에 대칭이 없고, completed/subtasks 사이에는 가짜 대칭이 있음:
Import가 Export로 미러링되는 대신 Share로 미러링됨:
다시 HIG:
HIG 저자들은 아이콘의 일부로 텍스트를 포함하는 것에 반대하고 있습니다. 그래서 이런 것:
또는 이런 것:
은 1992년이라면 통과하지 못했겠죠.
저도 동의합니다. 하지만 Tahoe는 더 심각한 문제가 있습니다. 텍스트로만 이루어진 아이콘들 말이죠. 예를 들어 이런 것:
“문자 그대로 읽으면 안 되는 은유적/추상적 아이콘 텍스트”가 어디까지고, 어디서부터 실제 텍스트인지 불분명합니다. 같은 폰트, 같은 색을 쓰는데 제가 어떻게 구분하죠? 아이콘은 그저 방해가 됩니다. A...Complete? AaFont? 이게 무슨 뜻이죠?
와 
정도는 어쩌면 이해할 수 있습니다. 점들이 무언가를 나타내려는 것 같으니까요. 
에 이르게 된 사고 흐름도 상상해볼 수는 있습니다. 하지만 
? 장식도 없고, 효과도 없고, 그냥 Abc입니다. 정말요?
텍스트 변환을 아이콘으로 설명하는 건 더 좋은 아이디어처럼 보일 수 있습니다.
예를 들어 이걸 보거나:
또는 이걸 보거나:
또는 이걸 보면:
아이콘만 보고도 텍스트에 무슨 일이 일어날지 이해할 수 있을 것 같습니다. 아이콘이 동작을 그려 주는 거죠.
그리고 BIU는 워드 프로세싱에서 잘 확립된 관습이니, 장점만 있지 않을까요?
그렇지만은 않습니다. 문제는 동일합니다. 텍스트 아이콘은 아이콘처럼 보이지 않고 텍스트처럼 보입니다. 게다가 이런 아이콘은 과도합니다. 첫 글자를 가져다 반복하는 게 무슨 의미가 있죠? “Bold”는 이미 B로 시작하고, 글자도 똑같이 잘 읽히는데, 왜 두 번 쓰나요? 다시 보세요:
단축키로도 한 번 더 반복됩니다...
이 메뉴를 더 잘 디자인하는 방법이 있습니다:
Apple은 최소 33년 전부터 이걸 알고 있었습니다.
운영체제는 당연히 자신의 목적을 위해 몇몇 시각 요소를 사용합니다. 창 컨트롤, 리사이즈 핸들, 커서, 단축키 등. 이런 걸 아이콘에 쓰는 건 실수입니다.
불행히도 Apple도 이 함정에 빠졌습니다. 화살표를 재사용했죠.
키 단축키:
HIG에는 생략부호(ellipsis)만을 다루는 섹션이 따로 있고, 메뉴의 다른 곳에서 쓰는 것이 얼마나 위험한지 설명합니다.
그리고 Tahoe에도 정확히 그 문제가 있습니다.
아이콘이 없으면, 메뉴를 위에서 아래로 스캔하면서 첫 글자만 읽어도 됩니다. 전부 정렬되어 있으니까요:
macOS Sequoia
하지만 Tahoe에서는 어떤 메뉴 항목은 아이콘이 있고 어떤 것은 없으며, 정렬도 다릅니다:
어떤 항목은 체크마크 그리고 아이콘이 함께 있을 수 있고, 둘 중 하나만 있을 수도 있고, 둘 다 없을 수도 있으니 이런 상황이 생깁니다:
으...
이 메뉴는 독자 카테고리를 받을 자격이 있습니다:
서로 다른 동작에 같은 아이콘. 명백한 은유는 빠짐. 첫 번째를 두 번째와 세 번째보다 약간 작게 만드는 기이함까지. 축하합니다! 올인원입니다.
저는 HIG를 많이 언급했는데, 아마 이런 의문이 들 수 있습니다. 1992년의 인터페이스 매뉴얼이 오늘날에도 유효한가? 컴퓨터가 너무 많이 변해서 완전히 새로운 원칙, 디자인, 관용구가 적용되는 게 아닌가?
맞기도 하고 아니기도 합니다. 물론 흑백 디스플레이에 아이콘을 적응시키는 법 같은 조언은 구식입니다. 하지만 원칙은—좋은 원칙인 한—여전히 적용됩니다. 왜냐하면 컴퓨터가 어떻게 동작하는지가 아니라, 인간이 어떻게 동작하는지에 기반하기 때문입니다.
인간은 매년 새 버전을 출시하지 않습니다. 기억력이 두 배로 늘지 않습니다. 시력이 더 좋아지지도 않습니다. 주의력은 예나 지금이나 같은 방식으로 작동합니다. 시각적 인지, 운동 기술—이 모든 것은 1992년과 정확히 같습니다.
그러니 네, 칩-뇌 직결 인터페이스가 나오기 전까지는 HIG는 계속 유효할 겁니다.
제 생각에 Apple은 불가능한 과제를 스스로 떠안았습니다. 모든 메뉴 항목에 아이콘을 붙이는 것 말입니다. 그런 걸 해낼 만큼 좋은 은유가 충분하지 않습니다.
게다가 설령 충분했다 하더라도, 전제 자체가 의심스럽습니다. 모든 것에 아이콘이 있다고 해서 사용자가 더 빨리 찾는다는 보장은 없으니까요.
그리고 설령 전제가 탄탄했다 해도, “목표가 그러하니 최선을 다했다”고 말하고 싶습니다. 하지만 그것도 사실이 아닙니다. 은유를 일관되게 적용하는 데도, 아이콘 자체를 디자인하는 데도 형편없었거든요.
이 글이, Apple이 한 OS 릴리스에 모조리 모아 놓은 아이콘 디자인의 흔한 실수들을 피하는 데 도움이 되길 바랍니다. 저는 컴퓨터를 사랑하고, 인터페이스를 사랑하고, 시각 커뮤니케이션을 사랑합니다. 30년 전에 이미 접근 가능했던 훌륭한 지식이 오늘날 완전히 무시되거나 버려지는 걸 보면 마음이 아픕니다.
좋은 소식도 있습니다. 이제 Apple보다 더 잘 디자인하는 건 그렇게 어렵지 않아요! 건배합시다. 새해 복 많이 받으세요!
SF Symbols에서 가져옴: 전화로 누군가를 부르는 스마일리 얼굴
이 글을 검토하는 과정에서 Jim Nielsen의 글을 알게 되었는데, 제가 말한 것과 상당히 비슷한 지점을 많이 짚고 있습니다. 제 추론 뒤에도 어떤 공통된 진실이 있다는 신호로 받아들이고 있습니다.
또 참고: Safari → File 메뉴는 26.0 이후 더 나빠졌습니다. 예전에는 아이콘이 4개뿐이었는데, 지금은 18개입니다!
초안 읽어준 Kevin, Ryan, Nicki에게 감사드립니다.
2026년 1월 5일·Hacker NewsRedditLobsters에서 토론
안녕하세요!
저는 Niki입니다. 여기서 프로그래밍과 UI 디자인에 대해 씁니다. 구독하기
저는 Clojure 전반을 컨설팅합니다: 웹, 백엔드, Datomic, DataScript, 성능 등. 제 Github를 확인하고 연락주세요: niki@tonsky.me
