4년간 브랜드 사이트를 만들며 생긴 나만의 반응형 기준
퍼블리싱 일을 시작하고 얼마 지나지 않아 알게 된 게 하나 있다.
프로젝트마다 달랐지만, 모바일 시안 없이 PC 시안만 전달되는 경우가 꽤 있었다.
PC 시안 한 장을 받고 나면
모바일에서는 이걸 어떻게 보여줘야 하는지 내가 정해야 하는 경우가 꽤 많았다.
처음에는 원래 퍼블리셔가 이렇게 하는 건가 싶었다.
일단 만들었다.
그런데 만들다 보니 매번 비슷한 데서 막혔다.
표는 모바일에서 깨지고,
서브 메뉴는 자리가 부족하고,
슬라이드는 PC에서는 예쁜데 모바일에서는 그대로 줄일 수가 없었다.
그래서 어느 순간부터는 시안을 받자마자 코드를 치기보다
먼저 화면을 줄였을 때 어떤 부분이 문제가 될지를 생각하게 됐다.
4년 동안 브랜드 사이트를 만들고 운영하면서
그렇게 자연스럽게 생긴 기준들이 있다.
물론 이게 정답이라는 건 아니다.
프로젝트마다 디자인도 다르고, 콘텐츠도 다르고, 일정도 다르다.
그냥 모바일 시안이 없을 때 나는 어떤 기준으로 판단하고 작업했는지 정리해보려고 한다.
1. PC / 태블릿 / 모바일 3단계만으로는 부족했다
처음 반응형을 배울 때는 보통
PC → 태블릿 → 모바일
정도로 화면을 나누는 경우가 많았다.
나도 처음에는 그렇게 작업했다.
그런데 실제 사이트를 만들다 보니 화면이 그렇게 예쁘게 세 구간으로 나뉘지는 않았다.
PC에서는 멀쩡하던 메뉴가 1100px쯤에서 갑자기 줄바꿈되고,
태블릿에서는 괜찮던 콘텐츠가 700px 전후에서 애매하게 깨지는 식이었다.
프로젝트를 계속 하다 보니 자연스럽게 체크하는 화면 폭도 늘어났다.
내가 작업하면서 자주 확인했던 구간은 대략
1920 → 1240 → 1080 → 960 → 720 → 640 → 480 → 360 전후
정도였다.
그렇다고 이 숫자마다 전부 미디어쿼리를 만든다는 뜻은 아니다.
오히려 작업을 오래 할수록
정해진 디바이스 사이즈보다 콘텐츠가 실제로 깨지는 지점을 브레이크포인트로 잡는 게 중요하다는 쪽으로 생각이 바뀌었다.
예를 들어 1080px에서 메뉴가 깨진다면 거기가 기준이 되고,
760px까지 카드 세 개가 잘 유지된다면 굳이 768px이라는 이유만으로 레이아웃을 바꿀 필요는 없다.
내가 개인적으로 많이 신경 썼던 구간은 960px 전후였다.
프로젝트에 따라 다르지만 이쯤부터 PC 레이아웃을 그대로 유지하기 어려운 경우가 많았다.
그래서 넓은 화면에서는 max-width를 둔 컨테이너 안에서 비교적 명확한 사이즈를 사용하고,
화면이 줄어들수록 %, rem, clamp(), min(), max() 같은 유동적인 값을 섞어 사용했다.
예전에는 화면마다 값을 하나씩 맞추려고 했다.
그런데 브레이크포인트를 아무리 많이 만들어도
그 사이에 존재하는 모든 화면을 하나씩 대응할 수는 없다.
그래서 어느 순간부터는
“모든 화면을 고정시키자”보다 “중간 화면에서도 자연스럽게 흐르게 만들자”
쪽으로 생각이 바뀌었다.
2. 표는 항상 나를 괴롭혔다
브랜드 사이트를 만들면서 모바일에서 가장 자주 문제를 일으켰던 것 중 하나가 표였다.
특히 호텔이나 리조트 사이트에 들어가는 객실 요금표나 이용 안내 표.
PC에서는 멀쩡한데
컬럼이 조금만 많아져도 모바일에서는 금방 답이 없어졌다.
그럴 때 가장 먼저 보는 건
이게 정말 표여야 하는 데이터인가?
였다.
행과 열의 관계가 중요한 요금표나 비교표라면 <table>을 유지하는 게 맞다.
그런 경우에는 모바일에서 억지로 모든 컬럼을 좁히기보다
overflow-x: auto;를 사용해서 가로 스크롤이 가능하도록 만드는 방법을 많이 사용했다.
화려한 방법은 아니지만
정보 관계를 유지하면서 가장 안전하게 대응할 수 있다.
반대로 실제로는 단순한
항목명 + 설명
객실명 + 가격 + 옵션
같은 반복 구조라면 꼭 <table>일 필요는 없었다.
이런 경우에는 데이터 성격에 따라
ul / li,
dl / dt / dd
같은 마크업을 사용하고 CSS Grid나 Flex를 적용하면
PC에서는 표처럼 보여주고 모바일에서는 세로형 카드나 리스트 형태로 바꾸기가 훨씬 쉬웠다.
중요한 건
반응형을 위해 무조건 div로 만드는 것이 아니라, 데이터 의미는 유지하면서 화면 변화에 대응하기 쉬운 구조를 선택하는 것이었다.
시간이 충분하다면 모바일 레이아웃까지 고려해서 처음부터 구조를 잡는 게 가장 좋다.
그런데 실무에서는 항상 일정이 같이 따라온다.
좋은 방법을 알고 있는 것과
지금 일정 안에서 그 방법을 사용할 수 있는지는 또 다른 문제였다.
급하면 <table>에 가로 스크롤을 적용하고,
구조 변경이 필요한 영역이라면 처음부터 모바일까지 고려해서 마크업을 잡는다.
몇 번 표 때문에 HTML 구조 전체를 다시 뜯어본 뒤부터는
복잡한 표를 보면 모바일부터 한 번 생각하게 됐다.
나중에 수정 요청이 들어왔을 때 그 차이가 꽤 컸다.
표 때문에 마크업을 처음부터 다시 만드는 날은 별로 평온하지 않기 때문이다.
3. 서브 메뉴는 공간보다 사용 방식을 먼저 봤다
상세 페이지가 많은 사이트를 만들다 보면
메인 GNB 말고도 콘텐츠 상단에 서브 메뉴가 한 번 더 들어가는 경우가 있다.
PC에서는 가로로 쭉 나열하면 된다.
그런데 모바일에서는 메뉴가 네다섯 개만 넘어가도 금방 공간이 부족해진다.
처음에는 이것도 어떻게 처리해야 하나 고민했다.
그러다 사수가 모바일에서 서브 메뉴를 드롭다운 형태로 바꾸는 걸 봤다.
“아, 이렇게 하면 되는구나.”
그 뒤부터 비슷한 구조가 나오면
모바일에서는 자연스럽게 몇 가지 패턴을 먼저 떠올리게 됐다.
메뉴가 적으면 그대로 유지하고,
가로 흐름을 유지하는 게 중요하면 스크롤 가능한 탭 형태로 만들고,
메뉴가 많거나 현재 위치를 선택하는 성격이 강하면 드롭다운 형태로 바꾼다.
예전에는 단순히
“자리가 부족하니까 셀렉트로 바꾼다.”
정도로 생각했다면,
지금은
“이 메뉴를 모바일에서 사용자가 어떻게 이동하는 게 가장 자연스러운가?”
를 먼저 생각하는 편이다.
돌이켜보면 이런 경험이 꽤 중요했다.
시안이 없을 때는 결국
내가 알고 있는 UI 패턴 안에서 선택해야 하기 때문이다.
패턴을 많이 알고 있으면
같은 디자인을 봐도 선택지가 많아진다.
퍼블리싱을 오래 할수록 단순한 코딩 속도보다
이런 판단 속도가 빨라지는 것도 경력의 일부라는 생각이 든다.
4. 슬라이드는 가능하면 모바일 시안을 먼저 확인한다
개인적으로 가장 까다로운 영역 중 하나는 슬라이드였다.
PC에서는 정말 예쁘다.
한 화면에 카드 세 개가 보이고,
가운데 콘텐츠가 강조되고,
양옆 콘텐츠가 살짝 보이는 식의 디자인도 많다.
그런데 모바일로 줄이는 순간
PC 구조 자체가 성립하지 않는 경우가 있다.
물론 어떻게든 만들 수는 있다.
Swiper의 breakpoints 옵션을 사용해서 화면별 설정을 바꾸고,
slidesPerView, spaceBetween, centeredSlides 같은 값을 각각 설정할 수도 있다.
필요하다면 CSS와 JavaScript를 더 추가해서 완전히 다른 동작으로 만드는 것도 가능하다.
그런데 구현할 수 있다는 것과 그렇게 구현하는 게 좋은 선택인 것은 별개였다.
화면마다 동작이 너무 달라지면 코드 복잡도가 올라가고,
운영이나 수정 요청이 들어왔을 때 확인해야 할 조건도 같이 늘어난다.
그래서 요즘은 슬라이드가 중요한 디자인 요소로 들어가 있으면
코드를 치기 전에 먼저 확인하는 편이다.
“이 슬라이드는 모바일에서는 어떤 형태로 노출되나요?”
PC처럼 여러 개가 보여야 하는지,
한 개씩 넘기는 형태인지,
슬라이드가 아니라 세로 리스트로 바뀌는지.
이걸 먼저 확인하면 구현 방향 자체가 달라진다.
미리 질문 한 번 하는 게
나중에 JavaScript 조건문을 계속 추가하는 것보다 훨씬 싸다.
5. 언제 물어보고, 언제 그냥 만들까
PC 시안을 받으면 바로 마크업을 시작하지 않고
한 번 화면을 줄여본다고 생각한다.
그러다 보면 크게 두 가지로 나뉜다.
내가 정해도 되는 것
공통적인 UI 패턴 안에서 해결할 수 있는 영역이다.
카드가 4개에서 2개, 1개로 줄어드는 구조나
콘텐츠 박스의 여백,
이미지와 텍스트의 배치처럼
사이트 전체의 규칙 안에서 자연스럽게 결정할 수 있는 부분은
굳이 하나씩 물어보지 않는 편이다.
실제로 이런 것까지 전부 물어보면 높은 확률로 돌아오는 답은 비슷했다.
“알아서 잘 부탁드립니다.”
그래서 기존 사이트의 UI 패턴과
전체적인 디자인 분위기를 보고 결정한다.
반드시 확인해야 하는 것
반대로 단순한 레이아웃 문제가 아니라
사용 방식이나 기획 의도 자체가 바뀌는 영역은 확인하는 편이다.
예를 들면
- 애니메이션의 의도가 시안만으로 명확하지 않을 때
- 모바일에서 기존 콘텐츠 구조를 유지하기 어려울 때
- 메뉴나 기능을 바꾸면 사용자 동선까지 달라질 때
- PC와 모바일 중 무엇을 우선해야 하는지 판단하기 어려울 때
- 구현 방법에 따라 운영 방식이나 콘텐츠 등록 방식까지 달라질 때
이런 경우다.
그리고 질문하는 방식도 조금씩 달라졌다.
예전에는
“이 디자인은 모바일에서 안 됩니다.”
라고 말했다면,
지금은
“모바일에서는 이 구조를 유지하기 어려워서 보통 이런 형태로 변경하는데, 이렇게 진행해도 될까요?”
라고 말하는 편이다.
혹은 가능하면 선택지도 같이 전달한다.
“모바일에서는 가로 스크롤 방식과 드롭다운 방식이 가능한데, 현재 구조에서는 드롭다운이 더 자연스러워 보입니다.”
결과적으로 전달하는 내용은 비슷하다.
그런데 첫 번째는 문제를 전달하는 말이고,
두 번째는 문제와 함께 해결 방법을 전달하는 말이다.
실무에서는 이 차이가 꽤 컸다.
6. 결국 아는 만큼 보인다
Swiper 페이지네이션을 커스텀해야 했던 적이 있다.
원하는 모양이 나오지 않아서
이벤트를 하나씩 걸어가면서 직접 구현했다.
어찌어찌 원하는 대로 동작하게 만들었고
나름 뿌듯했다.
그리고 나중에 알았다.
그걸 위한 옵션이 원래 있었다.
...
그날 이후 공식 문서를 조금 더 열심히 보게 됐다.
그때 느낀 건 단순히 Swiper 옵션 하나를 몰랐다는 게 아니었다.
제일 무서운 건
내가 무엇을 모르는지도 모르는 상태였다.
기능을 모르면 직접 만들 수 있다.
실제로 직접 구현해야 하는 상황도 있다.
그런데 라이브러리에서 이미 지원하고 있는 기능을 모르고
몇 시간을 써서 똑같은 기능을 다시 만들고 있다면 이야기가 조금 다르다.
Swiper뿐 아니라 다른 라이브러리도 마찬가지였다.
그래서 요즘은 새로운 기능을 구현하기 전에
일단 공식 문서와 API부터 한 번 확인하는 편이다.
breakpoints,
pagination,
navigation,
watchOverflow,
autoHeight
같이 이미 제공되는 옵션으로 해결할 수 있는지 먼저 본다.
예전에는
“어떻게 만들지?”
부터 생각했다면,
지금은
“이미 있는 기능인가?”
부터 확인하게 됐다.
물론 그래도 새로운 옵션은 계속 나온다.
7. 반응형은 결국 CSS 문제가 아니라 우선순위 문제였다
처음에는 반응형이라고 하면 미디어쿼리를 떠올렸다.
화면이 줄어들면
@media (max-width: ...)를 하나 더 쓰는 문제라고 생각했다.
그런데 사이트를 계속 만들다 보니
실제로 더 어려운 건 CSS가 아니었다.
화면이 작아졌을 때
무엇을 먼저 보여줄지,
무엇을 줄일지,
무엇을 숨길지,
무엇을 다른 UI로 바꿀지
결정하는 일이 더 어려웠다.
PC에서는 넓은 화면 덕분에
콘텐츠를 한 번에 보여줄 수 있다.
모바일에서는 공간이 부족하다.
결국 반응형은 화면을 줄이는 작업이라기보다
콘텐츠의 우선순위를 다시 정하는 작업에 가까웠다.
그래서 모바일 시안이 없을수록
퍼블리셔가 레이아웃뿐 아니라 콘텐츠 구조까지 이해하고 있어야 했다.
이 부분은 코드를 많이 친다고 자동으로 생기는 능력은 아니었다.
사이트를 많이 만들어보고,
디자이너와 이야기해보고,
수정 요청을 받아보고,
내가 만든 구조를 나중에 다시 유지보수하면서 조금씩 쌓였다.
마지막으로
요즘 웹은 내가 처음 퍼블리싱을 시작했을 때와 조금 달라졌다.
PC 화면보다 모바일 경험을 먼저 고민하는 서비스도 많아졌고,
CSS 자체도 예전보다 훨씬 유연해졌다.
clamp(), CSS Grid, aspect-ratio 같은 기능 덕분에
예전처럼 브레이크포인트를 계속 추가하지 않아도 해결할 수 있는 영역도 많아졌다.
몇 년 뒤에는 지금 우리가 만드는 웹사이트의 형태도
또 많이 달라져 있을 것 같다.
그런데도 크게 달라지지 않을 것 같은 기준이 있다.
시안이 없을 때 무엇을 기준으로 결정할지.
어디까지 내가 정하고,
어디부터 디자이너나 기획자에게 물어볼지.
가장 이상적인 방법과
지금 일정 안에서 가능한 방법 사이에서 무엇을 선택할지.
그리고 지금 보고 있는 문제가
CSS로 해결해야 하는 문제인지,
마크업을 바꿔야 하는 문제인지,
아니면 애초에 UI 방향을 다시 결정해야 하는 문제인지 판단하는 것.
결국 퍼블리셔가 계속 해야 하는 건
이런 판단이 아닐까 싶다.
4년 동안 브랜드 사이트를 만들었지만
아직도 모르는 게 많다.
Swiper 옵션 하나에도 모르는 기능이 계속 나오는데
웹 전체를 다 안다고 생각하는 게 오히려 이상할지도 모르겠다.
그래서 지금도 PC 시안을 받으면
바로 코드를 치기 전에 일단 한 번 화면부터 줄여본다.
“이거 모바일에서는 어떻게 되지?”
아마 반응형 작업을 하는 동안은
계속 하게 될 질문인 것 같다.
