나는 4년 동안 모든 프로젝트에 대량으로 whitespace를 적용했다. UI density에 대해 내가 잘못 알았던 점.

발행: (2026년 2월 6일 오전 01:11 GMT+9)
6 min read
원문: Dev.to

Source: Dev.to

I mass applied whitespace to every project for 4 years. Here's what I got wrong about UI density.의 표지 이미지

수년간 나는 기본적으로 이렇게 생각했다: 의심스러울 땐 패딩을 추가한다. 더 많은 여백 = 깔끔한 UI = 더 나은 UX. 그것이 규칙이었다.

그런 다음 나는 제품 매니저가 내가 디자인한 대시보드를 사용하는 모습을 보았다. 그녀는 한 화면에 보여야 할 그림을 만들기 위해 아름답게 간격을 둔 카드 네 화면을 스크롤했다. 그녀는 그 여백에 만족하지 못했다. 오히려 짜증이 났다.

그 순간 내 사고 모델에 무언가가 깨졌다. 나는 왜 업계가 희박한 레이아웃을 기본으로 삼는지와 그 직관이 실제로 어디서 실패하는지를 파헤치기 시작했다.

단순화 함정

우리는 “보기에 단순함”과 “사용 가능함”을 동일시한다. 모바일‑우선 사고는 이를 더욱 악화시켰다. 375 px 화면용으로 만든 레이아웃을 1440 px 모니터에 표시하면 텅 빈 느낌이 든다. 내용이 흩어지고 사용자는 끝없이 스크롤한다. “깨끗한” 인터페이스가 실제로는 같은 정보를 전달하는 데 더 많은 시간과 노력을 요구한다.

가장 큰 고통을 겪는 사용자는? 파워 유저들이다. 데이터를 스캔하는 금융 분석가, 티켓을 분류하는 지원 담당자, PR을 검토하는 개발자. 이들은 손잡이를 원하지 않는다. 밀도가 필요하다.

밀도를 설명하는 세 가지 인지 원리

1. 힉 법칙

선택지가 많아질수록 의사결정 시간은 로그 형태로 증가한다. 하지만 해결책은 “선택지를 줄이는 것”이 아니라 구조화된 선택지이다. 사이드바에 50개의 링크가 있으면 느리다. 같은 50개의 링크를 6개의 라벨이 붙은 카테고리로 묶으면 빠르다. 순수한 개수보다 인지적 조직이 더 중요하다.

2. 핏츠 법칙

대상은 클수록, 가까울수록 빠르게 클릭한다. 밀집된 인터페이스에서는 긴장이 실재한다: 요소가 많을수록 대상이 작아진다. 해결책은 자주 사용하는 요소를 크게, 가깝게 배치하는 것이다. 드물게 쓰는 동작은 2차 인터랙션 뒤에 숨긴다. Linear가 이를 훌륭히 구현한다.

3. 인지 부하 이론

정신적 노력에는 세 종류가 있다: 내재적(작업 자체), 외재적(나쁜 디자인에서 오는 혼란), 생성적(생산적인 패턴 인식). 좋은 밀도는 외재적 부하를 최소화하고 생성적 부하를 최대화한다. 나쁜 밀도는 그 반대를 만든다.

대부분이 놓치는 요소: 속도 그 자체가 밀도다

200 ms에 로드되는 인터페이스는 동일한 콘텐츠라도 3 초에 로드되는 인터페이스보다 근본적으로 더 밀집되어 있다. 왜냐하면 밀도는 공간만을 의미하지 않는다. 시간도 포함한다. 사용자가 시간 단위당 접근할 수 있는 정보량이 화면에 들어가는 양만큼 중요하다.

지연 1초마다 주의가 분산된다. 차트 로딩을 기다리는 사용자는 구축 중이던 정신 모델을 잃는다. 차트가 드디어 렌더링되면 다시 방향을 잡아야 한다. 실질적인 밀도가 떨어진다.

낙관적 렌더링(서버 확인 전에 UI 업데이트), 프리패칭, 예측 로딩—이 모든 것이 성능 기법으로 가장한 밀도 기법이다.

자신의 인터페이스를 위한 빠른 테스트

각 화면에 대해 세 가지 질문을 해보라:

  • 현재 사용자의 작업과 관련된 가시 요소가 모두 있나요?
  • 사용자가 가장 중요한 요소를 2 초 안에 식별할 수 있나요?
  • 어떤 요소를 제거하면 추가 클릭이나 탐색 단계가 필요해지나요?

세 질문 모두에 부합하지 않는 요소는 장식일 뿐이다. 제거하라.

이 글은 Ruixen UI의 Understanding UI density and designing for real‑world usage 를 참고하고 각색한 것이다.

Back to Blog

관련 글

더 보기 »

소프트웨어 현지화의 어려운 부분

Localization은 드물게 단순히 번역에 그치지 않는다. 하나 이상의 언어를 지원하게 되면, 모든 UI 변경에 추가적인 주의가 필요하다. 번역가들은 컨텍스트가 필요하고, placeholders는…