# 관용적 디자인을 되살리자

> Clean Markdown view of GeekNews topic #28462. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28462](https://news.hada.io/topic?id=28462)
- GeekNews Markdown: [https://news.hada.io/topic/28462.md](https://news.hada.io/topic/28462.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-13T09:56:08+09:00
- Updated: 2026-04-13T09:56:08+09:00
- Original source: [essays.johnloeber.com](https://essays.johnloeber.com/p/4-bring-back-idiomatic-design)
- Points: 1
- Comments: 1

## Topic Body

- 사용자에게 즉각적으로 이해되는 **디자인 관용구**는 학습 부담을 줄이고 일관된 상호작용을 가능하게 함
- 과거 **데스크톱 소프트웨어 시대**에는 운영체제와 가이드라인 덕분에 메뉴 구조와 단축키 등 인터페이스가 통일되어 있었음
- 반면 **브라우저 기반 소프트웨어 시대**에는 프레임워크와 커스텀 구현 확산으로 인터페이스의 **일관성이 붕괴**됨
- **Apple**과 **Substack**은 제한된 커스터마이징과 통일된 디자인 시스템으로 **현대적 관용구의 성공 사례**를 보여줌
- 제품 설계자는 기존 관용구를 따르고, **명확성과 일관성**을 우선시해 웹 전반의 **표준화된 사용자 경험**으로 나아가야 함

---

### 디자인 관용구
- **체크박스**는 사용자가 별도의 학습 없이 즉시 이해할 수 있는 대표적 **디자인 관용구**로 제시됨
  - 로그인 유지 여부를 묻는 질문에 다양한 입력 방식이 가능하지만, 실제로는 항상 체크박스가 사용됨
  - 이는 사용자와 개발자 모두에게 익숙한 **표준화된 상호작용 패턴**으로 작동

### 균질한 인터페이스
- 인터페이스는 사용자가 시스템과 상호작용하는 수단이며, **생각할 필요가 적을수록 좋은 인터페이스**로 평가됨
  - 예를 들어, Command+C 단축키로 복사하는 기능은 어디서나 동일하게 작동해야 함
- 그러나 현재의 웹 소프트웨어 환경에서는 **인터페이스의 일관성이 사라짐**
  - 날짜 선택, 카드 번호 입력 등 기본 기능조차 사이트마다 다르게 구현되어 있음
  - 단축키와 상호작용 방식이 앱마다 달라 사용자는 매번 “어디서 무엇을 눌러야 하는가”를 다시 학습해야 하는 상황

### 데스크톱 소프트웨어 시대
- **Windows 95~7 시기**의 데스크톱 소프트웨어는 **높은 인터페이스 일관성**을 유지
  - “File, Edit, View” 메뉴 구조가 모든 프로그램에서 동일하게 존재
  - 메뉴 항목의 밑줄은 **키보드 단축키**를 의미하며, ALT+F, N 등으로 조작 가능
  - 하단의 **상태 표시줄(status bar)** 은 현재 상태(페이지, 단어 수, 모드 등)를 명확히 표시
  - **텍스트 기반 메뉴** 중심으로, 아이콘은 명확한 의미를 가질 때만 사용
- 이러한 관용구는 Microsoft Word뿐 아니라 **Windows 전체 생태계**에 걸쳐 통일되어 있었음
  - Windows XP의 로그아웃 화면에서도 모든 버튼이 명확히 버튼임을 시각적으로 표현하고, 단축키가 표시됨
- 이러한 일관성은 **운영체제와 GUI 라이브러리의 제약** 덕분에 가능했으며, Microsoft는 수백 페이지의 **디자인 가이드라인**을 배포해 개발자들이 이를 따르도록 유도

### 브라우저 소프트웨어 시대
- 현재의 웹 애플리케이션 시대는 **이질적 인터페이스**의 시대로 묘사됨
  - Figma와 Linear 같은 우수한 웹앱조차 **공통 아이콘이나 단축키가 없음**
  - 각 앱이 독자적으로 잘 설계되었지만, **서로 다른 상호작용 패턴**을 가짐
  - 동일 회사 내에서도 Gmail, GSuite, Google Docs의 경험이 서로 다름
  - 결과적으로 사용자는 **생산적 흐름(flow)** 대신 **조작 위치를 탐색하는 시간**을 보내게 됨
- ## 모바일 전환의 영향
  - **터치스크린 등장**으로 마우스·키보드 중심의 디자인 패턴이 재발명됨
  - 모바일과 데스크톱을 동시에 지원해야 하는 상황에서 **중간 형태의 불완전한 UI**가 확산
  - 예: 모바일용 햄버거 메뉴가 데스크톱에서도 그대로 사용되는 사례
  - **모듈형 컴포넌트 재사용 문화**가 잘못된 패턴을 복제하며 품질 저하를 초래
  - 10년 이상 누적된 결과로 **UI/UX 품질의 세대적 침식** 발생
- ## HTML을 넘어선 관용구의 부족
  - 초기 웹에서는 **파란색 밑줄 링크** 등 명확한 관용구가 존재했으나, 현재는 사이트마다 스타일이 제각각
  - HTML/CSS 표준은 엄격하지만, 실제로는 대부분 **React·TypeScript 기반 빌드 시스템**을 사용
  - 결과적으로 **표준 HTML 요소 대신 커스텀 구현**이 난무하며 접근성 문제까지 초래
  - 예: `&lt;a&gt;` 대신 `onclick`이 달린 `&lt;span&gt;` 사용으로 스크린리더 기능이 깨짐
  - Figma처럼 **WebAssembly 기반**으로 HTML을 완전히 벗어난 앱도 존재
  - 브라우저의 **뒤로가기 버튼, 단축키 등 기본 기능**이 무시되며, 새로운 인간-컴퓨터 상호작용 패러다임이 재구성됨
  - 프런트엔드 개발이 **속도와 가능성 중심**으로 발전하면서, **일관된 관용구 정착이 어려움**
  - 수많은 프레임워크와 상호작용 형식이 존재해 **단일 표준 확립이 구조적으로 어려운 환경**

### 관용적 디자인의 성공 사례
- **Apple**은 현대에 **강력한 디자인 관용구를 유지하는 대표 사례**로 꼽힘
  - 폰트, 버튼, 색상 등 전반적 디자인 시스템이 통일되어 있으며, **iOS 전반의 일관된 상호작용 경험**을 제공
  - 이러한 일관성이 “**it just works**”라는 신뢰감을 형성
- **Substack** 또한 제한된 커스터마이징과 **미리 정해진 미학적 기본값**을 통해 안정된 사용자 경험을 제공
  - Apple과 Substack의 디자인 원칙은 성공을 통해 **업계 표준으로 확산**, 결국 **새로운 관용구로 자리잡음**

### 제품 설계자가 따라야 할 원칙
- 제품 개발자는 가능한 한 **기존 디자인 관용구를 따르는 것**이 사용성과 호환성을 높이는 길로 제시됨
  - HTML/CSS의 기본 관용구를 준수: 링크는 밑줄·색상·포인터 커서·`&lt;a&gt;` 태그로 구현
  - 기본 HTML 요소를 **JavaScript로 재구현하지 말 것**, 예: React Button 대신 `&lt;button&gt;` 사용
  - 브라우저 관용구 준수: **뒤로가기 버튼 작동**, **URL 복사 시 동일 인터페이스 접근**, **CTRL+클릭 시 새 탭 열기**
  - 일반 관용구에서 벗어날 경우, **조직 내부적으로라도 일관된 규칙**을 유지
  - **텍스트 우선, 아이콘 최소화**, 아이콘은 보편적으로 이해 가능한 경우에만 사용
  - 시각적 요소는 **명확함이 미적 아름다움보다 우선**
  - 판단이 어려울 경우, **우수한 웹사이트 사례**와 **과거의 인터페이스 디자인 서적**을 참고
- 궁극적으로는 모든 웹의 **날짜 선택기나 카드 입력 폼이 동일하게 작동하는 미래**를 지향하며,
  **수십 년의 반복과 개선 끝에 최적의 관용구로 수렴하는 웹 환경**을 목표로 제시됨

## Comments



### Comment 55175

- Author: neo
- Created: 2026-04-13T09:56:09+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47738827) 
- 어떤 앱에서는 Enter가 입력 전송이고 Ctrl+Enter가 줄바꿈임 (예: Slack), 또 어떤 곳은 반대임 (예: GitHub)  
  이런 **일관성 부족**이 사용자 입장에서는 꽤 혼란스러움. “관용적 디자인을 되살리자”는 말이 있지만, 정작 공통된 관용이 부족한 게 문제임  
  - 예전에는 Return과 Enter가 다른 키였음. Return은 줄바꿈, Enter는 입력 전송용이었음.  
    지금은 키가 하나로 합쳐져서, 일반적으로 **멀티라인 입력창**에서는 Enter가 줄바꿈, Ctrl+Enter가 전송임.  
    반면 채팅앱은 단문 입력이 많아서 반대로 동작함. 좋은 앱은 이걸 설정으로 바꿀 수 있게 함  
  - Teams는 두 가지 모드가 있음. 기본은 Enter로 전송, Shift+Enter로 줄바꿈인데, 서식 도구를 열면 반대로 바뀜.  
    어떤 조합이 줄바꿈인지 표시해주긴 하지만 여전히 헷갈림  
  - Slack은 더 복잡함. Markdown을 켜면 Shift+Enter가 줄바꿈인데, 코드 블록(```) 안에서는 Enter가 줄바꿈, Shift+Enter가 전송임.  
    의도는 이해하지만 **사용성**은 엉망임  
  - 이상적인 해결책은 Ctrl+Enter는 항상 전송, Shift+Enter는 항상 줄바꿈, Enter는 상황에 따라 기본값을 따르는 식이 좋을 듯함  
  - 나도 Shift+Enter가 줄바꿈이라고 생각했는데, 이처럼 **파편화된 UX**가 문제임을 보여줌  

- 요즘 소프트웨어는 예전처럼 **사려 깊은 설계자**가 만드는 게 아님.  
  대신 급히 승진한 PM이나 Product 담당자가 주도하고, 수익을 위한 **다크 패턴**까지 장려되는 현실임  
  - 모바일 엔지니어로서, 이해관계자에게 “그냥 아이디어대로 만들면 안 된다”고 말하면 멍한 표정을 많이 봄.  
    UX 일관성과 정보 구조(IA)의 중요성을 강조해야 함. **디자이너도 문제 해결자**임을 잊지 말아야 함  
  - 이런 비판은 너무 단편적임. 실제로 온라인 폼 하나 만드는 것도 지옥임.  
    예를 들어 신용카드 폼을 만들 때 복사/붙여넣기 허용 여부, 구형 브라우저 지원, 접근성과 보안의 균형 등 수많은 변수가 있음.  
    참고로 [Steve Yegge의 플랫폼 글](https://gist.github.com/chitchcock/1281611)도 이런 복잡성을 잘 설명함  
  - 2010년대에는 숙련된 UX 디자이너들이 빠지고, 인쇄나 그래픽 출신의 **비전문 디자이너**가 대거 들어오면서 품질이 떨어졌음  
  - 물론 나쁜 인센티브와 급한 일정도 있지만, 단순히 무능이나 악의로만 보긴 어려움. **시스템 자체가 변했음**  
  - 지금도 PM이 전체 아키텍처와 릴리스 로드맵까지 직접 설계하려 드는 걸 보면, 이 말이 틀리지 않다고 느낌  

- 시스템 프레임워크가 **관용적 UI**를 만들어주는 기반이었음.  
  Win32, AppKit, UIKit은 세세한 부분까지 다뤄서 개발자가 자연스럽게 일관된 UX를 따르게 했음.  
  반면 웹은 그런 게 없어서 전부 직접 구현해야 하고, 결과적으로 **반쯤 완성된 UI**가 많음  
  - 하지만 글쓴이는 웹의 불일치를 잘못 짚었음. “데스크톱 시대”는 사실상 **Windows 시대**였고, Win32가 기본이었기에 다들 그걸 따랐던 것뿐임.  
    웹은 처음부터 문서 중심이라 표준적 접근이 없었고, 나중에 Bootstrap 같은 게 등장하며 일시적 표준이 생겼음  
  - HTML과 CSS가 있었지만, 요즘은 WebAssembly 등으로 우회함.  
    사실 **날짜 선택기나 카드 입력**은 기본 HTML 컨트롤을 써야 함.  
    그러면 브라우저가 OS 수준의 보안과 편의성을 제공할 수 있음 (예: Safari는 Apple Wallet, Android는 Google Pay 연동)  
  - OS의 일관된 동작에 익숙한 개발자는 자연히 그 환경을 모방하려 함.  
    하지만 웹과 모바일은 완전히 다른 **상자형 환경**이라 이런 일관성이 깨졌음.  
    예를 들어 데스크톱의 오른쪽 클릭을 모바일의 **롱프레스**로 통일할 기회가 있었지만, 일관되게 추진되지 않음  
  - 웹의 근본 문제는 여전히 **문서 중심 패러다임**에 머물러 있다는 점임.  
    앱 UI를 만들려면 문서 UI 위에 덧씌워야 해서 충돌이 생김.  
    브라우저가 이를 완화하긴 했지만 근본 개선은 아님  
  - 참고로 AppKit에서도 버튼 높이 변경은 가능함. 단지 명확하지 않을 뿐임  

- 날짜 선택기는 정말 **UX 악몽**임.  
  사용자가 직접 날짜를 입력하려 하면 막고, 억지로 클릭하게 만드는 경우가 많음.  
  실수 입력만 잡아주면 되는데, 굳이 불편하게 만듦  
  - 생일 입력하려고 수십 년치 달력을 넘기다 보면 인생의 **무상함**을 느끼게 됨  
  - 모바일의 시간 선택기도 제각각임. 스크롤 한 번에 12:00에서 11:50으로 가기도 하고 안 가기도 함.  
    **아날로그 시계형 선택기**가 더 직관적이라 이런 게 표준이 되면 좋겠음  
  - 날짜 형식도 문제임. 03/04/2026이 3월 4일인지 4월 3일인지 헷갈림.  
    국제 사용자라면 **YYYY-MM-DD** 형식이 안전함  
  - 생일 입력할 때 미래 일정용과 같은 **날짜 선택기**를 쓰는 사이트는 최악임.  
    50년 전으로 스크롤하게 만들고 나이만 실감나게 함  
  - 생일 입력할 때마다 스크롤로 나이를 체감하게 만드는 건 고문 같음  

- 요즘 **UX 품질 하락**이 심함, 특히 은행 웹사이트에서 두드러짐.  
  스크롤바 숨기기, 낭비된 여백, 플랫 버튼, 혼란스러운 아이콘 등으로 예전 데스크톱 UI보다 훨씬 불편해짐  
  - 스크롤바를 숨기는 건 정말 이해 안 됨. 단지 “보기 좋게” 하려는 미적 이유로 보임  
  - **Material UI**가 여러 산업에 악영향을 줬다고 느낌.  
    GCP나 Google 도구들은 불필요하게 복잡하고, 상자 없는 입력창 등으로 UX를 망쳤음.  
    다행히 요즘은 이런 스타일이 구식으로 여겨지고 있음  

- 예전 Mac에서 온 개념 중 하나는, 버튼 텍스트 끝에 **줄임표(…)** 가 있으면 추가 입력이 필요하다는 뜻임.  
  반면 줄임표가 없는 버튼은 클릭 즉시 동작이 완료됨  

- “아이콘보다 단어를 선호하라”는 말에 공감함.  
  대부분의 사람은 **단어 인식 속도**가 아이콘보다 빠름  
  - 물론 실제 사물을 그린 아이콘은 괜찮지만, 요즘은 너무 **추상적이고 선형적인 아이콘**이 많음.  
    텍스트 설명이 없으면 마치 러시안 룰렛처럼 클릭해야 의미를 알 수 있음  
  - HN의 “unvote/undown”처럼 접두사가 같아 헷갈리는 경우도 있음. 클릭할 때마다 다시 확인하게 됨  
  - 아이콘이 작거나 위치가 자주 바뀌면 단어가 더 낫지만, 고정된 환경에서는 아이콘이 더 빠를 수도 있음  

- 최근 **CSS**라는 신기술을 발견했는데, 선언적으로 레이아웃을 정의하고 DOM 기반으로 계층적 스타일을 적용할 수 있음.  
  클라이언트와 서버 부하를 줄이고, 스타일시트를 공유하거나 사용자 맞춤 테마도 쉽게 만들 수 있음.  
  “no-framework” UI 패러다임이라 부르고 싶음  
  [예시 이미지](https://i.imgur.com/OEMPJA8.png)  
  - 써봤는데 완전 악몽이었음. 어떤 스타일이 어디에 적용되는지 알 수 없고, DOM 구조가 바뀌면 스타일이 엉망이 됨.  
    게다가 “클라이언트 부하 최소화”는 **신화**에 불과함. 실제로 더 느림  
  - 이 아이디어는 [vanilla-js](http://vanilla-js.com/) 프레임워크 팀에 제안해보면 좋겠음  

- 우리가 잃어버린 공통 기능들:  
  **Undo/Redo**, 도움말(F1), 마우스 오버 힌트, 단축키 커스터마이징, 메인 메뉴, 파일/디렉터리, ESC로 닫기, 드래그앤드롭 등  
  한때 혁신적이던 기능들이 이제는 모바일과 웹에서 거의 사라졌음  

- 많은 문제는 **시각 디자이너가 제품 설계로 넘어온 결과**임.  
  디자인 직군의 역할 혼동이 여전히 해결되지 않았고, 사실 “디자이너”가 필요 없는 프로젝트에도 너무 많이 투입되는 게 현실임
