머티리얼 디자인
Material Design
도구
구글이 안드로이드를 중심으로 내놓은 디자인 체계로, 화면 부품의 모양과 색과 간격을 규칙과 코드로 함께 정해 둔 묶음입니다.
등장 배경
2014년 이전의 안드로이드 앱은 생김새가 제각각이었습니다. 어떤 앱은 뒤로 가기 버튼을 왼쪽 위에 두고 어떤 앱은 아래에 뒀습니다. 메뉴를 여는 방법도 앱마다 달랐습니다. 아이폰용으로 먼저 만든 화면을 그대로 옮긴 앱이 많아서, 안드로이드 기기인데 아이폰처럼 보이는 앱과 그렇지 않은 앱이 한 화면에 섞여 있었습니다.
사용자 쪽에서 보면 앱을 열 때마다 조작법을 새로 배워야 했습니다. 한 앱에서 익힌 동작이 다음 앱에서 통하지 않으니, 처음 몇 분을 어디를 눌러야 하는지 찾는 데 썼습니다.
만드는 쪽도 비용을 치렀습니다. 시안 리뷰에서 버튼을 어디 둘지를 두고 의견이 갈리면 근거가 없어 목소리가 큰 쪽으로 결정됐고, 같은 회사 앱인데 화면마다 여백이 다르게 잡히는 일이 흔했습니다. 정할 것이 너무 많고 정하는 기준이 없었던 셈입니다.
머티리얼 디자인은 여기에 답을 미리 써 둔 문서입니다. 출발점은 화면 요소를 종이 조각으로 보는 발상이었습니다. 종이가 겹치면 그림자가 생기니, 그림자의 깊이로 무엇이 위에 있는지를 나타냅니다. 떠 있는 카드와 그 위를 덮는 창이 한눈에 구분되는 것은 이 규칙 덕분입니다.
해결하는 문제
화면을 그릴 때 정해야 할 것의 상당수를 미리 정해 줍니다. 크게 네 가지입니다.
- 위치와 동작의 기본값. 주 동작 버튼은 오른쪽 아래에 동그랗게 띄우고, 저장 완료 같은 짧은 안내는 화면 아래에서 잠깐 올라왔다 사라지는 막대로 보여 줍니다. 어디에 둘지를 매번 논의하지 않아도 됩니다.
- 값의 단위. 색과 글자 크기와 간격에 이름이 붙어 있습니다. 여백을 16으로 할지 20으로 할지 고르는 대신 정해진 단계에서 고릅니다. 이 방식이 디자인 토큰의 형태로 코드에도 그대로 전달됩니다. 디자인 토큰은 색이나 간격 같은 값에 이름을 붙여 디자인과 코드가 같은 값을 쓰게 하는 단위입니다.
- 만드는 시간. 문서만 있는 게 아니라 버튼·입력창·목록 같은 UI 컴포넌트가 코드로 함께 제공됩니다. 누른 자리에서 물결이 번지는 반응 같은 것을 직접 짜지 않아도 됩니다.
- 기본적인 접근성. 누를 수 있는 영역의 최소 크기나 글자와 배경의 밝기 차이가 이미 규칙에 들어 있어, 그대로 쓰면 최소선은 지켜집니다.
사용자 쪽 효과가 더 큽니다. 처음 여는 앱인데도 어디를 눌러야 할지 짐작이 가는 상태가 됩니다. 모바일 앱에서 이 차이는 첫 화면에서 이탈하느냐 아니냐로 바로 나타납니다.
안드로이드용으로 시작했지만 웹에서도 쓸 수 있게 열려 있어서, 안드로이드 앱이 아닌 제품이 이 체계를 그대로 가져다 쓰는 경우도 많습니다. 디자이너가 없는 초기 팀이 화면을 빨리 세우는 방법으로 이 선택을 자주 합니다.
대안
플랫폼이 준 체계를 쓰는 것 말고 세 가지 선택지가 있습니다.
- 자체 디자인 시스템을 만듭니다. 회사가 색·간격·부품을 직접 정해 디자인 시스템으로 묶습니다. 브랜드가 그대로 드러나고 원하는 대로 바꿀 수 있지만, 만들고 관리할 사람이 계속 필요합니다. 구성원 마흔 명 규모에서 이걸 처음부터 만들면 디자이너 한 명분의 시간이 통째로 들어갑니다.
- 플랫폼 체계를 뼈대로 쓰고 색과 서체만 갈아입힙니다. 가장 흔한 절충안입니다. 배치와 동작은 규칙을 따르고 브랜드 색만 얹는 식이라, 사용자는 익숙하게 쓰면서도 우리 제품처럼 보입니다.
- 크로스 플랫폼 도구가 주는 기본 부품을 씁니다. 한 번 만들어 두 운영체제에 내는 도구들은 자체 부품을 함께 줍니다. 만드는 속도가 가장 빠르지만 양쪽 어디의 관행과도 미묘하게 어긋나는 화면이 나오기 쉽습니다.
무엇을 고르든 컴포넌트 라이브러리로 한곳에 모아 둡니다. 컴포넌트 라이브러리는 화면을 이루는 부품을 모아 둔 모음입니다. 규칙을 문서로만 두면 화면마다 조금씩 어긋나기 시작합니다.
실무 용례
"이건 머티리얼 기준으로는 하단 시트로 띄우는 게 맞아요."
배치를 두고 의견이 갈릴 때 문서를 근거로 삼는 말입니다.
"안드로이드는 머티리얼로 가고 iOS 는 애플 쪽 규범을 따를게요."
두 플랫폼에 각각 그 플랫폼의 관행대로 내겠다는 뜻입니다.
"기본 색을 그대로 쓰면 저희 앱처럼 안 보여요. 토큰만 갈아 끼웁시다."
체계의 구조는 유지하고 색 값만 브랜드 것으로 바꾸자는 제안입니다.
페이지덱이 안드로이드 앱을 처음 낼 때 민서가 화면을 그렸습니다. 처음에는 웹 화면을 그대로 줄여 옮겼는데, 사용 테스트에서 참가자 다섯 명 중 셋이 문서 목록에서 새 문서를 어떻게 만드는지 찾지 못했습니다. 웹에서 쓰던 오른쪽 위 작은 버튼을 그대로 뒀기 때문입니다. 규칙대로 오른쪽 아래 떠 있는 버튼으로 옮기자 같은 테스트에서 다섯 명이 모두 찾았습니다. 민서가 바꾼 것은 버튼 하나의 위치뿐이고, 그 위치를 사용자가 이미 다른 앱에서 배워 온 것입니다.
흔한 오해
구글 앱처럼 보이게 만드는 규칙이라고 여기는 경우가 많습니다. 기본 색과 기본 서체를 그대로 쓴 화면이 실제로 구글 앱과 닮아 보이니 그렇게 읽힙니다. 하지만 이 체계에서 바꾸라고 열어 둔 부분과 지키라고 둔 부분은 따로 있습니다. 색·서체·모서리 둥글기는 갈아 끼우라고 만든 자리이고, 지키라는 쪽은 배치와 동작입니다. 겉모습까지 그대로 쓰면 브랜드가 사라진 채로 익숙함만 남고, 반대로 배치와 동작까지 우리 식으로 바꾸면 익숙함이 사라지면서 사용자가 헤맵니다.
문서를 처음부터 끝까지 읽어야 한다고 생각하는 것도 오해입니다. 분량이 많아 시작할 엄두가 안 난다는 이야기가 자주 나옵니다. 실제 쓰임은 사전에 가깝습니다. 화면을 그리기 전에 그 기능에 해당하는 장만 찾아 읽고, 시안 리뷰에서 근거로 인용하고, 운영체제가 새 버전을 낼 때 바뀐 항목만 훑습니다. 통독을 목표로 잡으면 대개 한 번도 펴 보지 않게 됩니다. 필요한 장 하나를 5분 읽는 습관이 전체를 훑는 계획보다 오래갑니다.
자주 헷갈리는 용어
| 용어 | 누가 만들었는가 | 머티리얼 디자인과의 차이 |
|---|---|---|
| 휴먼 인터페이스 가이드라인 | 애플 | 같은 기능이 다른 모양으로 갈립니다. 삭제 확인 창을 애플 쪽은 화면 아래에서 밀어 올리고 머티리얼은 가운데에 띄웁니다. 또 애플 문서는 앱 장터 심사의 근거가 되어 일부 항목이 사실상 통과 조건인 반면, 머티리얼은 권고에 가깝습니다 |
같이 보면 좋은 페이지
- 플랫폼 가이드라인
이런 문서가 왜 플랫폼마다 따로 있는지 먼저 봅니다
- 휴먼 인터페이스 가이드라인
같은 자리를 애플이 어떻게 풀었는지 나란히 놓고 봅니다
마지막 업데이트 2026-09-16