macOS 26 Tahoe가 배포됐을 때, 가장 먼저 눈에 띈 변화 중 하나는 메뉴 바의 모든 항목 옆에 붙은 아이콘들이었다. 처음엔 '더 시각적으로 풍부해졌다'고 느낄 수도 있었다. 하지만 실제로 마주한 것은 앱마다 제각각인 아이콘 스타일, 의미를 파악하기 어려운 심벌들, 그리고 전체적인 시각 노이즈였다. Nikita 'Tonsky' Prokopov가 문서화한 것처럼, 같은 메뉴 항목에 Apple 앱마다 완전히 다른 아이콘이 붙어 있었다. 일관성 없는 디자인 결정이 OS 전반에 조용히 퍼져 있었던 것이다.
그리고 macOS 27 Golden Gate에서 그 아이콘들은 사라졌다. Apple은 Human Interface Guidelines도 함께 업데이트했다. 핵심 메시지는 명확하다. "아이콘은 아껴서, 목적 있게 써라. 메뉴 항목을 명확히 나타내는 아이콘을 찾을 수 없다면 아이콘을 표시하지 마라." Daring Fireball 등 커뮤니티에서는 이 변화를 단순한 롤백이 아니라, Apple 소프트웨어 디자인 팀의 방향 전환 신호로 읽고 있다.
이 사건이 흥미로운 이유는 단순히 '아이콘이 생겼다가 없어진 이야기'가 아니기 때문이다. 여기엔 디자인 결정이 코드 레벨로 번역되는 과정에서 무슨 일이 벌어지는지에 대한 중요한 교훈이 담겨 있다. Brent Simmons의 오픈소스 코드를 활용해 서드파티 개발자들이 직접 기본 동작을 비활성화해야 했다는 사실이 그 증거다. 플랫폼이 잘못된 디자인 결정을 디폴트로 강제하면, 개발자들은 그것을 우회하는 코드를 직접 작성해야 한다. 나쁜 디자인 결정 하나가 생태계 전체의 기술 부채가 되는 순간이다.
'디자인 언어를 코드로 번역하기'라는 개념을 떠올려보면 이 문제는 더 구조적으로 보인다. 디자인 언어는 제품 전체에 일관되게 흐르는 시각적 규칙이다. --color-primary: #1976d2 같은 토큰이 그 출발점이고, 컴포넌트는 그 토큰을 소비한다. 중요한 것은 이 흐름이 단방향이라는 점이다. 디자인 언어 → 디자인 토큰 → 컴포넌트 → 사용자 화면. 이 파이프라인의 상위에서 잘못된 결정이 내려지면, 하위 모든 레이어가 오염된다.
Tahoe의 메뉴 아이콘 문제가 바로 그랬다. "모든 메뉴 항목에 아이콘을 붙인다"는 결정은 디자인 원칙 레벨에서 내려졌고, 그것이 플랫폼 API의 디폴트 동작으로 번역됐다. 개별 컴포넌트나 앱 수준에서 저항할 수 있는 구조가 아니었다. .button { background-color: #1976d2; } 처럼 하드코딩된 값이 의미를 잃듯, '모든 메뉴에 아이콘'이라는 규칙은 '왜 이 항목에 아이콘이 필요한가'라는 본질적 질문을 지워버렸다. 의미 없는 값이 시스템 전체에 퍼진 셈이다.
반면 올바른 디자인 토큰 전략은 정반대로 작동한다. Primitive Token이 실제 값을 보유하고, Semantic Token이 그 값에 역할과 의미를 부여한다. --color-primary: var(--blue-500)은 단순히 색상을 지정하는 게 아니라 '이것이 브랜드의 주요 색상'이라는 의도를 코드로 표현한다. 컴포넌트는 그 의미를 소비하는 것이지 값을 직접 다루지 않는다. 이 구조 덕분에 디자인 언어가 바뀌어도 토큰만 수정하면 시스템 전체가 일관되게 반응한다. Tahoe가 실패한 지점이 바로 여기다. 아이콘 사용에 대한 '의미 기반 규칙' 없이 '전부 켜기'라는 기계적 결정을 내린 것이다.
디자인-개발 협업 관점에서 이번 사례는 또 다른 질문을 던진다. 그 결정이 제안 단계를 어떻게 통과했는가. 커뮤니티의 반응처럼, 이런 아이디어가 검토 프로세스를 통과했다는 사실 자체가 문제다. 디자인 시스템 엔지니어의 역할이 중요해지는 것도 이 지점이다. 디자이너가 정의한 규칙을 색상·간격·타이포그래피·레이아웃으로 분석하고, 그것이 토큰과 컴포넌트와 가이드로 올바르게 번역되는지 검증하는 것. 좋은 디자인 결정이 코드로 정확히 구현되도록, 그리고 나쁜 결정이 시스템에 박히기 전에 걸러지도록 하는 것이 그 역할의 핵심이다.
Apple이 HIG를 업데이트하고 아이콘을 되돌린 것은 반가운 신호다. 하지만 더 주목할 만한 것은 그 속도다. 메이저 OS 릴리즈 사이클 안에서 디자인 원칙 레벨의 결정이 번복됐다. 일반적인 기업에서 시스템 레벨의 디자인 결정을 되돌리는 것은 훨씬 더 오랜 시간이 걸린다. 이는 거꾸로, 디자인 언어를 코드로 번역하는 초기 단계에서 잘못된 결정을 잡아내는 것이 얼마나 중요한지를 보여준다. 나중에 고치는 비용은 처음부터 제대로 만드는 비용과 비교할 수 없다.
결국 디자인 시스템은 단순히 스타일 가이드나 컴포넌트 라이브러리가 아니다. 그것은 조직이 내린 디자인 결정의 총합이 코드 형태로 구현된 것이다. 그 결정들이 얼마나 의미 있고, 일관되고, 검증된 것인지가 시스템의 품질을 결정한다. Tahoe의 메뉴 아이콘 사태는 그 원칙을 OS 스케일에서 확인시켜 준 케이스 스터디다. 디자인 결정이 코드가 되는 순간, 그것은 단순한 시각적 선택이 아니라 시스템 전체의 일관성과 유지보수 비용을 결정하는 아키텍처 선택이 된다.