모바일 앱 개발 UXUI 디자인 해상도 그리드 완벽정리
Figma로 시작하는 모바일 앱 해상도·그리드 한 번에 이해하기
안녕하세요~~3년 차 UXUI 디자이너 비니예요!!! ㅎㅎ
오늘은 한 번쯤은 제대로 정리해두면 평생 써먹는다고 느꼈던 주제,
모바일 앱 해상도랑 그리드 이야기를 해보려고 해요!
앱 디자인을 막 시작하면 375, 390, dp, pt, @2x, @3x
이런 표현들이 한꺼번에 튀어나오면서 머리가 멍해질 때 많지 않나요...
저도 첫 앱 프로젝트 때는 일단 화면부터 만들어놓고
나중에 해상도랑 그리드를 다시 맞추느라 이중 작업을 정말 많이 했어요 ㅠㅠ
그래서 오늘은
모바일 앱 디자인에서 해상도와 그리드가 왜 이렇게 중요한지
헷갈리는 해상도 개념을 어떻게 정리해야 하는지
실제 작업할 때 어디까지 체크하면 되는지
이 세 가지를 신입 UXUI 디자이너도 알 수 있게 정리해보려고 해요! :)
모바일 앱 해상도와 그리드, 무엇인가요?
해상도와 그리드가 중요한 이유는
같은 화면이라도 기기마다 크기도 다르고 비율도 다르기 때문에,
처음에 기준을 안 잡아두면 어떤 폰에서는 괜찮은데 어떤 폰에서는 깨지고,
어떤 화면은 여백이 널뛰기하고...ㅋㅋ 이런 일이 너무 쉽게 생기거든요 ㅠㅠ
해상도는 화면이 얼마나 촘촘하게 구성되는지에 대한 기준이고,
그리드는 그 화면 안에서 요소들을 얼마나 규칙적으로 배치할지에 대한 기준이에요.
이 두 가지를 초반에 잘 잡아두면
기기가 달라져도 레이아웃 느낌이 비슷하게 유지되고,
화면이 늘어나도 톤앤매너가 잘 이어져요.
개발자랑 이야기할 때도
"이건 왜 여기서 3px 떠 있죠...?" 같은 불필요한 질문이 줄어들어요.
모바일 앱 해상도 개념 정리
해상도 공부가 괜히 어렵게 느껴지는 이유는,
한 번에 여러 개념이 섞여서 등장하기 때문인 것 같아요.
저는 디자인 작업을 하면서 이걸 딱 세 가지로 나눠서 생각하고 있어요!
디바이스 해상도
디바이스 해상도는 아이폰 스펙 표에 적혀 있는 1170×2532 같은 숫자인데요!
이건 실제 물리적인 픽셀 개수라서 기기마다 전부 다르고, 숫자도 꽤 커요.
이런 값은 어떤 기기가 더 촘촘한지,
이미지가 얼마나 선명하게 나오는지 같은 걸 이해할 때 참고용으로 보면 되고요,
실제 UI 프레임을 이 숫자 그대로 만드는 경우는 거의 없어요~
그래서 저는 디바이스 해상도는 "기기 스펙용 숫자" 정도로 가볍게만 보고,
레이아웃 설계할 때는 논리 해상도 쪽을 더 신경 쓰는 편이에요!!
논리 해상도와 pt·dp
실제 디자인 작업에서 더 중요한 건 논리 해상도, 그리고 pt·dp 같은 단위예요.
iOS에서는 pt(point)
Android에서는 dp(density-independent pixel)
이 단위를 기준으로 레이아웃을 잡아요~
예를 들어 요즘 많이 쓰이는 아이폰 12, 13, 14, 16e 같은 기종은
논리 해상도가 390×844 pt라서, 실제 픽셀은 훨씬 크지만
디자이너가 다루는 단위는 390×844처럼 상대적으로 단순한 숫자예요!
우리가 버튼 높이를 48, 56 이런 숫자로 정할 때,
사실은 pt나 dp 기준으로 레이아웃을 잡고 있다고 보면 돼요~ :)
결국 레이아웃을 설계할 때는 디바이스 해상도보다
논리 해상도와 pt/dp를 중심으로 생각하는 편이 훨씬 실용적이었어요.
출처: 리메인커리어배율(@2x, @3x)
그렇다면 @2x, @3x는 뭘까 싶은데요.
배율은 같은 논리 사이즈의 아이콘이나 일러스트를
고해상도 화면에서도 선명하게 보이게 하기 위한 개념이에요.
예를 들어 논리적으로는 24×24짜리 아이콘을 쓴다고 했을 때,
이미지는 @2x일 경우 48×48, @3x일 경우 72×72처럼
실제 픽셀에서 더 큰 사이즈로 준비해요.
이렇게 해두면 레티나처럼 픽셀이 촘촘한 화면에서도
계단이 덜 보이고 선명하게 렌더링돼요!
정리하면
레이아웃은 pt/dp 기준으로 설계
아이콘이나 일러스트 같은 비트맵 이미지는 @2x, @3x 배율에 맞춰서 익스포트
해상도 공부가 헷갈렸던 이유가
"픽셀 숫자, pt, 배율"이 한 번에 섞여 있었기 때문인데,
이렇게 역할을 나눠서 보고 나니까 훨씬 덜 복잡하죠?
Figma에서 잡는 모바일 앱 기준 프레임
개념을 이해했다고 해도, 막상 Figma에서
"그럼 프레임은 몇 × 몇으로 만들지...?"
이 부분이 가장 중요하겠죠!
저도 처음엔 아이폰 기종별로 프레임을 다 만들어놓고 시작했다가,
유지가 안 돼서 결국 대표 프레임 하나만 남기는 식으로 정리했어요...!
요즘은 iOS와 Android를 이렇게 나눠서 잡고 있어요~
iOS 기준 프레임
iOS 쪽에서는 390×844 pt가 꽤 많이 쓰여요.
이 값은 아이폰 12, 13, 14, 16e 등
여러 세대의 6.1인치급 아이폰이 공통으로 사용하는 논리 해상도라서,
대표 프레임으로 잡기에 무난해요!ㅎㅎ
중요한 건 아이폰 기종별로 5~6개 프레임을 따로 만드는 게 아니라,
대표 논리 해상도 하나를 기준으로
상단 상태바와 하단 홈 인디케이터를 고려해서 세이프존을 정리
나머지는 오토 레이아웃과 그리드로 대응하는 방식
이렇게 해두면 나중에 개발자와 이야기할 때도
"디자인은 390×844 기준으로 작업했어요"
라고 한 줄로 설명할 수 있어서 훨씬 편했어요.
예전처럼 기종마다 프레임을 따로 만들어 쓰는 방식은,
유지보수 비용만 괜히 올라가는 느낌이었어요...! ㅠㅠ
Android 기준 프레임
Android는 기기 종류가 워낙 다양해서,
하나의 기기 해상도를 기준으로 삼기보다
가장 많이 쓰이는 뷰포트를 기준으로 잡는 게 더 현실적인 방법이에요!
최근 통계를 보면 모바일 화면 비율 중
360×800이 전 세계적으로 점유율이 가장 높은 편이고,
그 외에도 360×780, 412×915 같은 해상도들이 주로 쓰이고 있어요~ :)
그래서 저는 Android 쪽은
360×800 기준 프레임 하나
세로 길이가 더 긴 기기는 리스트가 늘어나도록
더 짧은 기기는 스크롤이 생기도록
이런 식으로 대응하고 있어요!
Figma에서는 프레임을 360×800으로 잡고,
오토 레이아웃으로 상하 여백과 리스트 영역이
자연스럽게 늘어났다 줄어들도록 구성해두면,
실제 기기에서 확인했을 때도 꽤 안정적으로 나오더라고요~ㅎㅎㅎ
결국 iOS든 Android든
대표가 될 기준 프레임을 하나 정해두고
그 위에서 세이프존과 그리드를 세팅하는 것만으로도
입문자 기준에서는 충분히 탄탄한 시작점이 될 수 있다고 생각해요!
모바일 앱 그리드 설계 기본
그리드는 해상도 안에 어떻게 내용을 정리해서 채워 넣을지에 대한 규칙인데요.
저는 보통
여백과 컴포넌트는 4 또는 8 단위
전체 레이아웃은 컬럼 그리드 기준
이 두 툭에 따라 그리드를 생각하고 있어요!
8pt·4pt 베이스 그리드
많은 팀이 8pt 그리드를 기본으로 사용하고 있어요.
예를 들면
버튼 높이 48, 56
카드 안쪽 패딩 16, 24
이런 값들이 전부 8의 배수로 정리되는 식이에요.
이렇게 맞춰두면 디자인하다가 숫자를 고를 때 16, 20, 24, 28처럼
애매한 값들이 섞이는 일을 줄일 수 있어서,
나중에 전체를 봤을 때 여백 리듬이 훨씬 안정적으로 느껴져요ㅎㅎ
조금 더 섬세하게 표현하고 싶은 부분이 있을 때는
4 단위를 섞어서 쓰기도 해요.
예를 들어 아이콘과 텍스트 간 간격을 4, 12처럼 조정하는 식이에요.
중요한 건, 어떤 기준을 쓰든 팀 내에서
"우리는 8단위를 기본으로 쓴다"
정도만 합의해도 레이아웃에 훨씬 안정감이 생겨요~
컬럼 그리드 설정
모바일에서는 4컬럼이나 6컬럼 그리드를 많이 활용해요.
4컬럼은 카드형 리스트나 메인 배너 레이아웃에 쓰기 좋고
6컬럼은 조금 더 세밀한 정렬이 필요할 때 활용하기 좋아요.
Figma에서는 모바일 프레임에 4컬럼 그리드를 깔고,
좌우 마진을 16, 컬럼 간 거터를 8 정도로 맞춰두면,
카드 폭을 정할 때도 '컬럼 두 칸짜리 카드', '전체 폭 카드'처럼 설명하기 쉬워져요.
그리고 나중에 반응형 웹이나 태블릿으로 확장할 때도
컬럼 기준이 이미 정리돼 있어서,
구조를 옮기는 작업이 훨씬 수월해지겠죠?!
세이프 에어리어와 시스템 영역
요즘 기기들은 상단 노치나 하단 홈 인디케이터가 있는 경우가 많아서,
실제 콘텐츠가 들어갈 수 있는 영역을 항상 의식해야 해요. ㅎㅎ
상단에는 상태바와 앱바 높이를 고려해 여유 있게 잡고,
하단에는 탭바나 홈 인디케이터에 눌리지 않도록
버튼과 주요 액션을 살짝 위로 올려 배치하는 식으로요!
디자인만 보고 있을 때는 이 차이가 잘 안 느껴질 수도 있는데,
실제 디바이스에서 손으로 눌러보면
"이 버튼 너무 아래라서 불안하다"
같은 느낌이 들어요.(다들 경험 있으시죠?)
그래서 저는 요즘은 아예 세이프 에어리어까지 포함해서 그리드를 생각하려고 하고 있어요!
출처: 디자인베이스모바일 앱 해상도·그리드 체크리스트
지금까지 정리한 해상도와 그리드를
제대로 확인할 수 있는 체크리스트를 알려드릴게요!
1) 이번 프로젝트의 기준 프레임이 정해져 있는지
iOS 기준 프레임 1개(예: 390×844)
Android 기준 프레임 1개(예: 360×800)
이렇게 대표 프레임을 먼저 정해두고 시작하는 게 좋아요.
중간에 프레임 사이즈를 계속 바꾸면,
컴포넌트도 다 같이 틀어져서 리팩터링하는 데 시간이 정말 많이 들어가더라구요 ㅠㅠ
2) 베이스 그리드 숫자를 팀과 합의했는지
8pt 그리드를 기본으로 쓸지
4pt를 어디까지 허용할지
이 정도만 디자이너끼리, 그리고 개발자와도 공유해두면,
픽셀 퍼펙트로 맞추지 않더라도 전체적인 리듬이 잘 유지돼요.
"이 프로젝트는 여백이 대부분 8 단위로 움직인다"는 정도만 기억해도
새 화면 만들 때 훨씬 수월하겠죠?
3) 컬럼 그리드를 어떻게 활용할지 정리했는지
예를 들어
메인 화면은 4컬럼 기준
2열 카드 레이아웃은 컬럼 네 개 중 두 칸씩 사용
풀브리드스 배너는 전체 컬럼 사용
이런 식으로 규칙을 미리 정해두면, 새 화면을 만들 때도
기존 구조에 자연스럽게 편입되는 느낌이 나요. ㅎㅎ
눈대중으로 맞추느라 시간을 더 쓰지 않아도 되는 것 또한 장점이구요!
4) 로딩·빈 상태·에러 상태 화면까지 포함했는지
해상도와 그리드를 아무리 잘 잡아도,
실제 데이터가 없을 때나 네트워크가 끊겼을 때
화면이 준비돼 있지 않으면 전체 경험이 갑자기 허술해 보여요...ㅜㅜ
그래서 저는 리스트 화면을 만들 때 항상
정상 데이터가 있는 상태
데이터가 0개인 상태
로딩 중인 상태
에러가 난 상태
이 네 가지 상황을 가정하고 레이아웃이 깨지지 않는지 확인하려고 해요.
특히 빈 상태와 에러 상태에서 텍스트 길이와 버튼 위치가
이상하게 느껴지지 않는지 꼭 한 번씩 체크해보는 편이에요! :)
5) 긴 텍스트와 긴 닉네임을 가정해봤는지
실제 운영을 해보면 생각보다 긴 텍스트가 정말 많이 들어와요.
닉네임이 지나치게 긴 사용자
한 줄에 들어가기 애매한 버튼 레이블
설명이 길어지는 안내 문구
이런 것들이에요.
그래서 저는 디자인 단계에서 임의로 긴 텍스트를 넣어보면서,
줄바꿈이나 말줄임이 어떤 식으로 처리되는지 미리 확인해두고 있어요.
이걸 안 해두면, 나중에 QA에서 무너지는 경우가 많더라구요 ㅠㅠ
6) 실제 디바이스에서 한 번이라도 확인해봤는지
마지막으로, 가능하다면 실제 디바이스에서 한 번은 꼭 확인해봐야 해요!
Figma 미리보기만 보고 있으면 크기 감이 좀 왜곡될 때가 있거든요...ㅜ
아이폰 한 기기, 안드로이드 한 기기 정도만 준비해서
텍스트가 너무 작게 느껴지지 않는지
버튼 터치 영역이 손가락으로 누르기 편한지
상하단 여백이 답답하거나 허전하지 않은지
이 정도만 체크해도, 전체 완성도가 확 올라갈 거예요ㅎㅎ
저도 이 과정을 한 번 거쳐본 프로젝트와 아닌 프로젝트의 차이를 꽤 크게 느꼈어요.
혼자 구조 설계가 막막할 때
여기까지가 해상도와 그리드를 처음 세팅할 때,
제가 신입 시절에 미리 알았으면 좋았겠다 싶었던 내용들이에요.
디바이스 해상도 숫자에만 매달리기보다 pt/dp와 배율의 역할을 구분해서 이해
iOS, Android 각각 대표 프레임을 하나씩
8pt 그리드, 컬럼 그리드, 세이프 에어리어를 초반에 규칙으로
앱 디자인 과정이 훨씬 수월해져요~ ㅎㅎ
다만 해상도와 그리드를 포함한 전체 구조 설계는,
사실 디자이너 혼자만의 문제가 아니라 기획, 개발, 운영까지
같이 엮여 있는 일이라서,
프로젝트 초반에 이걸 혼자서 끝까지 설계하고 끌고 가는 건
생각보다 에너지가 많이 들더라구요.
저도 외주 프로젝트를 여러 번 하면서,
턴키 구조로 일하는 개발사와 협업할 때
구조적인 부분에서 도움을 정말 많이 받았어요!
그중에서 제가 실제로 협업하면서 구조를 꼼꼼하게 본다고 느꼈던 팀이
웹에이전시 똑똑한개발자였어요!
똑개팀은 디자인을 받아 개발만 진행해주지 않고
어떤 해상도를 기준으로 개발할지
반응형이나 태블릿까지 어디까지를 범위로 볼지
그리드와 디자인 시스템을 코드에서 어떻게 재사용 가능한 구조로 만들지
이런 것들을 초반 기획 단계에서부터 같이 정리해주시더라고요~
제가 Figma에서 8pt 그리드와 컬럼 기반으로 UI를 짜면,
똑똑한개발자 쪽에서 디자인 토큰과 컴포넌트 구조를 코드 기준으로 다시 정리해주면서
"이 정도 규칙이면 화면이 두 배로 늘어나도 톤이 크게 흔들리지 않는다"
와 같은 방식으로 기준을 한번 더 잡아주셨어요! :)
덕분에 저는 화면 단위로만 고민하던 시각에서 조금 벗어나서,
해상도와 그리드까지 포함된 서비스 전체 구조를 보는 연습을 할 수 있었어요.
그래서 모바일 앱이나 SaaS 서비스를 준비하는 팀이라면,
해상도와 그리드까지 혼자 설계하기 막막할 때,
기획·디자인·개발을 한 흐름으로 보는 파트너와
구조를 같이 점검해보는 선택을 추천해 드려요!
요즘 날씨가 갑자기 확 추워져서 손도 너무 시리고...
어깨도 더 웅크리게 되는 것 같아요.
모두들 감기 조심하시구요!
끝까지 읽어주셔서 감사합니다~
오늘도 궁금하신 부분이 해결되셨으면 좋겠어요 ㅎㅎ
공감도 부탁드려요 ~ ><
