요즘 앱은 왜 다 똑같이 생겼을까 — '관용적 디자인'을 되찾자는 목소리

어디서든 본 듯한 그 UI

최근에 새로운 앱이나 웹 서비스를 써보면서 "어? 이거 어디서 본 것 같은데"라는 느낌을 받은 적 없나요? 둥근 모서리의 카드 레이아웃, 좌측 사이드바, 상단의 미니멀한 내비게이션, 비슷비슷한 색감. 소프트웨어 디자인이 점점 획일화되고 있다는 문제의식을 담은 에세이가 나와서 이야기를 풀어보려 해요. 핵심 주장은 "관용적 디자인(Idiomatic Design)"을 되살려야 한다는 건데요, 이게 뭔지 같이 살펴볼게요.

관용적 디자인이란?

프로그래밍에서 "관용적(idiomatic)"이라는 말을 쓸 때가 있잖아요. "Pythonic한 코드", "Go답게 작성된 코드" 같은 표현처럼, 해당 언어나 플랫폼의 철학과 관습에 맞게 자연스럽게 작성된 걸 의미하죠. 디자인에서도 마찬가지예요. 관용적 디자인이란, 그 플랫폼이나 도구가 원래 의도한 방식대로 UI를 설계하는 것을 뜻해요.

예를 들어, macOS 앱이라면 macOS의 디자인 언어를 따르고, Windows 앱이라면 Windows의 관습을 따르는 거예요. 과거에는 이게 당연했어요. Mac 앱은 Mac답게 생겼고, Windows 앱은 Windows답게 생겼거든요. 사용자가 새 앱을 설치해도 "이 버튼은 여기 있겠지", "설정은 이 메뉴에 있겠지"라고 직감적으로 알 수 있었어요. 그 플랫폼의 "문법"을 앱들이 공유하고 있었으니까요.

왜 사라졌나?

이 에세이가 지적하는 건, Electron 기반 앱과 웹 기술의 확산이 이 흐름을 바꿨다는 거예요. Electron이 뭐냐면, 웹 기술(HTML, CSS, JavaScript)로 데스크톱 앱을 만들 수 있게 해주는 프레임워크인데요, Slack, VS Code, Discord, Notion 같은 앱들이 전부 이걸로 만들어져 있어요.

문제는 이 앱들이 macOS에서 돌아가든 Windows에서 돌아가든 리눅스에서 돌아가든 똑같이 생겼다는 거예요. 플랫폼 고유의 디자인 언어를 따르지 않고, 자체적인 UI를 가져가니까요. 개발 효율성 면에서는 합리적인 선택이에요. 하나의 코드베이스로 모든 플랫폼을 커버할 수 있으니까요. 하지만 사용자 경험 측면에서는 "이 앱이 내 OS의 일부"라는 느낌이 사라지죠.

여기에 더해, 디자인 시스템의 표준화도 영향을 줬어요. Tailwind CSS, Material Design, shadcn/ui 같은 도구들이 보편화되면서, 새로운 프로젝트를 시작할 때 기본 컴포넌트를 가져다 쓰는 게 너무 쉬워졌거든요. 덕분에 개발 속도는 빨라졌지만, 결과물의 외형이 수렴하는 현상이 생긴 거예요.

그래서 뭘 되찾자는 건가요?

에세이의 주장은 단순히 "옛날로 돌아가자"가 아니에요. 핵심은, 디자인이 그 소프트웨어의 목적과 맥락을 반영해야 한다는 거예요. 코드 에디터는 코드 에디터답게, 음악 앱은 음악 앱답게, 금융 앱은 금융 앱답게 각자의 도메인에 맞는 인터페이스가 있어야 한다는 거죠.

구체적으로는, 네이티브 UI 컴포넌트를 적극적으로 활용하자는 주장이 있어요. macOS의 NSToolbar, Windows의 WinUI 같은 플랫폼 네이티브 요소들은 OS 업데이트에 따라 자동으로 개선되고, 접근성(accessibility)도 기본 탑재되어 있거든요. 또한 해당 앱이 속한 도메인의 관습도 존중해야 해요. 예를 들어, 영상 편집 도구라면 타임라인 UI라는 오랜 관습이 있는데, 이걸 무시하고 "혁신적인" UI를 만들면 기존 사용자가 혼란스러워하잖아요.

한국 개발자에게 주는 시사점

이 논의는 한국 개발 현장에서도 꽤 와닿는 부분이 있어요. 한국은 특히 빠른 개발 속도가 중시되다 보니, 디자인 시스템이나 UI 라이브러리를 그대로 가져다 쓰는 경우가 많거든요. 스타트업에서 MVP를 빠르게 찍어야 할 때 shadcn/ui나 Ant Design을 기본으로 쓰는 건 합리적인 선택이에요.

하지만 서비스가 성장하면서 "우리 서비스만의 정체성"이 필요해지는 시점이 반드시 와요. 토스가 자체 디자인 시스템 TDS를 만들고, 카카오가 자체 디자인 언어를 정립한 것처럼요. 결국 관용적 디자인의 핵심은 "누구를 위한 인터페이스인가"를 끊임없이 질문하는 것이에요.

프론트엔드 개발자라면 이런 관점도 가져볼 만해요. 컴포넌트 라이브러리를 쓸 때 기본 스타일을 그대로 두지 말고, 우리 서비스의 사용자가 기대하는 인터랙션이 뭔지 고민해보는 거예요. 같은 모달 창이라도 이커머스에서의 모달과 개발 도구에서의 모달은 다른 맥락을 가지니까요.

네이티브 앱 개발을 한다면 더 직접적이에요. SwiftUI나 Jetpack Compose 같은 플랫폼 네이티브 프레임워크를 쓸 때, 플랫폼의 디자인 가이드라인을 진지하게 읽어보세요. Apple의 Human Interface Guidelines나 Google의 Material Design 문서는 단순한 스타일 가이드가 아니라, 수년간의 사용자 연구가 녹아있는 결과물이거든요.