나는 오랫동안 데스크톱 화면부터 만들고 나서 좁은 화면을 나중에 끼워 맞췄다. 넓은 화면이 눈에 익고 다루기 편했기 때문이다. 그런데 그렇게 만든 페이지는 좁은 화면에서 늘 어딘가 어색했고, 좁은 화면을 손보다 보면 넓은 화면이 다시 틀어졌다. 순서가 잘못되었다는 걸 인정하기까지 꽤 오래 걸렸다.
이번 편은 그 순서를 뒤집는 모바일 퍼스트에 관한 것이다. 왜 좁은 화면부터 시작해야 하는지, min-width와 max-width가 실제로 어떻게 다른지, 그리고 두 방식을 섞으면 왜 곤란한지를 내 경험으로 풀어본다. 순서 하나를 바꿨을 뿐인데 코드가 눈에 띄게 깔끔해진 이야기다.
1. 좁은 화면을 기본으로 삼는다는 것
모바일 퍼스트는 말 그대로 좁은 화면을 기본 스타일로 삼는 방식이다. 아무 조건 없이 적히는 기본 규칙을 모바일에 맞춰 짜고, 화면이 넓어질 때 규칙을 하나씩 더해가는 것이다. 처음에는 왜 굳이 작은 화면부터냐고 의아했지만, 직접 해보고 나서 생각이 완전히 바뀌었다.
좁은 화면은 공간이 부족해서 무엇이 정말 중요한지 먼저 골라내야 한다. 이 강제된 선택이 오히려 콘텐츠의 우선순위를 또렷하게 해준다. 데스크톱부터 그리면 온갖 요소를 다 욱여넣게 되는데, 모바일부터 그리면 핵심만 남긴 뒤 여유가 생길 때 곁가지를 더하게 된다.
이 순서는 사고의 방향과도 맞닿아 있다. 넓은 공간에서 무엇을 뺄지 고민하는 것보다, 좁은 공간에 무엇을 넣을지 고민하는 편이 훨씬 건강한 결정을 낳는다. 빼는 결정은 아깝고 미루기 쉽지만, 더하는 결정은 신중해지기 때문이다.
기본 스타일이 모바일에 맞춰져 있으면 대부분의 콘텐츠는 한 줄로 쌓인다. 세로로 흐르는 이 기본형은 어떤 화면에서도 최소한 읽을 수는 있는 안전한 상태다. 나는 이 안전한 바닥을 먼저 깔아두는 것이 모바일 퍼스트의 핵심 이점이라고 생각한다.
그 위에 넓은 화면 규칙을 얹으면 배치가 점점 풍성해진다. 한 줄이 두 칸이 되고, 두 칸이 세 칸이 되며, 여백이 넉넉해진다. 바닥이 튼튼하니 위로 쌓는 과정이 불안하지 않다. 나는 이 점층적인 확장이 반응형을 만드는 가장 자연스러운 흐름이라고 느낀다.
물론 모바일 퍼스트가 모바일만 챙기라는 뜻은 아니다. 출발점을 좁은 화면으로 잡되, 넓은 화면에서도 배치가 시원하게 살아나도록 끝까지 다듬어야 한다. 나는 두 화면을 나란히 열어두고 오가면서 어느 쪽도 홀대받지 않게 균형을 맞춘다.
2. min-width가 자연스러운 이유
모바일 퍼스트는 min-width 조건과 짝을 이룬다. 이 조건은 화면 폭이 특정 크기 이상일 때만 규칙을 적용하라는 뜻이다. 기본 스타일을 모바일에 두고, 폭이 넓어질 때마다 이 조건으로 규칙을 하나씩 얹는 것이 자연스러운 흐름이다.
이 방식의 장점은 스타일이 위에서 아래로 쌓인다는 점이다. 기본 규칙이 먼저 있고, 그 아래로 더 넓은 화면 규칙이 차례로 더해진다. 각 규칙이 이전 규칙을 덮는 것이 아니라 보태는 구조라서, 코드를 읽을 때 흐름이 눈에 그려진다.
예를 들어 메뉴를 생각해보자. 기본으로 세로로 쌓아두고, 태블릿 폭 이상에서 가로로 바꾸며, 데스크톱 폭 이상에서 간격을 넉넉히 벌린다. min-width를 두 번 얹는 것만으로 세 단계의 배치가 완성되고, 각 단계가 명확히 구분된다.
이렇게 짜면 각 조건이 담당하는 폭이 겹치지 않고 이어진다. 좁은 구간은 기본 규칙이, 그보다 넓은 구간은 첫 조건이, 가장 넓은 구간은 두 번째 조건이 맡는다. 나는 이 깔끔한 계층 덕분에 나중에 특정 구간을 손볼 때 어디를 고쳐야 할지 바로 안다.
성능 면에서도 이 방식이 유리하다. 저사양 휴대폰은 넓은 화면 조건이 발동하지 않으니 그 규칙을 계산할 필요가 없다. 정작 자원이 부족한 기기가 자기에게 필요한 기본 규칙만 처리하면 되는 것이다. 가장 약한 기기를 배려하는 방향이 결과적으로 모두에게 이롭다.
나는 이 자연스러움을 겪고 나서 min-width를 기본 도구로 삼았다. 규칙이 보태지는 구조는 사고의 흐름과도 맞고, 코드의 흐름과도 맞는다. 무언가를 되돌리지 않고 계속 앞으로 쌓아가는 이 느낌이 나는 좋다.
3. max-width 방식의 부담
반대 방향인 max-width는 화면 폭이 특정 크기 이하일 때 규칙을 적용한다. 데스크톱을 기본으로 두고 좁은 화면에서 규칙을 덮어쓰는 방식인데, 언뜻 보면 넓은 화면부터 다루니 익숙하고 편해 보인다. 나도 오래 이 방식에 머물렀다.
문제는 되돌리는 코드가 잔뜩 생긴다는 점이다. 데스크톱 기준으로 가로로 펼쳐둔 것을 좁은 화면에서 다시 세로로 바꾸고, 넓게 벌려둔 간격을 다시 좁히고, 보여둔 요소를 다시 숨긴다. 기본으로 해둔 것을 하나하나 취소하는 코드가 쌓이는 것이다.
이 취소 코드는 관리가 어렵다. 어떤 규칙이 어디서 켜지고 어디서 다시 꺼지는지 추적하기가 번거롭고, 조금만 복잡해져도 어디서 무엇이 꼬였는지 알기 힘들어진다. 나는 이 방식으로 짠 오래된 페이지를 고칠 때마다 미로에 들어선 기분이었다.
또한 저사양 기기가 불필요한 스타일까지 파싱한다. 데스크톱 규칙이 기본으로 깔려 있으니, 좁은 화면 기기도 그 규칙을 일단 읽은 뒤 다시 좁은 화면 규칙으로 덮는다. 필요 없는 계산을 한 번 더 시키는 셈이라 효율이 떨어진다.
그렇다고 max-width가 언제나 나쁜 것은 아니다. 이미 데스크톱 중심으로 만들어진 오래된 코드에 부분적으로 손을 댈 때는 이 방식이 현실적일 수 있다. 나는 새로 짜는 페이지에는 min-width를 쓰되, 옛 코드를 보수할 때는 상황에 맞게 유연하게 판단한다.
다만 새 프로젝트를 시작한다면 나는 주저 없이 모바일 퍼스트를 택한다. 취소 코드가 쌓이는 부담을 처음부터 지지 않는 편이 훨씬 낫기 때문이다. 방향을 한 번 잘 잡아두면 프로젝트가 커질수록 그 이득이 복리처럼 불어난다.
4. 두 방식을 섞으면 생기는 혼란
가장 피해야 할 것은 min-width와 max-width를 아무 계획 없이 섞는 것이다. 한 곳에서는 넓은 화면부터 쌓고 다른 곳에서는 좁은 화면부터 덮으면, 규칙들이 서로 엇갈리며 예측하기 어려운 상태가 된다. 나는 이렇게 뒤섞인 코드를 물려받아 며칠을 고생한 적이 있다.
혼란의 핵심은 우선순위 충돌이다. 방향이 다른 조건들이 같은 요소를 두고 다투면, 어느 규칙이 최종적으로 이길지 한눈에 파악되지 않는다. 특이도와 소스 순서가 얽히면서, 화면 폭을 조금 바꿀 때마다 예상 밖의 규칙이 튀어나온다.
디버깅도 지옥이 된다. 특정 폭에서 배치가 이상할 때, 어느 조건이 범인인지 찾으려면 방향이 뒤섞인 규칙들을 하나하나 헤집어야 한다. 나는 이런 상황에서 개발자 도구로 규칙 하나씩 꺼보며 범인을 찾았는데, 방향만 통일했어도 겪지 않을 수고였다.
그래서 나는 프로젝트 안에서 방향을 하나로 통일한다는 원칙을 세웠다. 모바일 퍼스트를 택했으면 처음부터 끝까지 min-width로만 쌓는 것이다. 이 일관성 하나만 지켜도 코드가 훨씬 예측 가능해지고, 나중에 남이 봐도 흐름을 금방 이해한다.
일관성은 협업에서 특히 빛난다. 여러 사람이 같은 방향으로 규칙을 쌓으면, 새로 합류한 사람도 기존 흐름을 따라가기만 하면 된다. 반대로 방향이 뒤섞여 있으면 각자 자기 방식대로 규칙을 더하다가 충돌이 눈덩이처럼 불어난다.
나는 이 원칙을 팀의 약속으로 문서에 적어두기도 한다. 개인의 취향이 아니라 프로젝트의 규칙으로 못 박아두면, 시간이 지나도 방향이 흐트러지지 않는다. 작은 규칙 하나가 코드베이스 전체의 건강을 지키는 셈이다.
5. 모바일 퍼스트를 몸에 익히기
모바일 퍼스트는 기법이라기보다 습관에 가깝다. 나는 새 컴포넌트를 만들 때 개발자 도구의 화면을 일부러 좁게 줄여두고 시작한다. 좁은 화면을 먼저 눈앞에 두면 자연스럽게 좁은 화면 기준으로 사고하게 되기 때문이다.
디자인 시안을 받을 때도 나는 모바일 시안부터 본다. 데스크톱 시안을 먼저 보면 넓은 배치가 머릿속에 각인되어, 좁은 화면을 그것의 축소판으로만 여기게 된다. 반대로 모바일 시안부터 보면 핵심이 무엇인지 먼저 파악하고 넓은 화면을 확장으로 다루게 된다.
기본 스타일을 짤 때는 어떤 조건도 붙이지 않는다는 규칙을 지킨다. 조건 없이 적히는 규칙이 곧 모바일 기본이 되도록, 좁은 화면에 필요한 모든 것을 이 무조건 영역에 넣는다. 그리고 넓은 화면 규칙은 반드시 min-width 조건 안에만 둔다.
넓은 화면 규칙을 더할 때는 되돌리지 않는다는 원칙을 되새긴다. 기본으로 세로였던 것을 가로로 바꾸는 것은 괜찮지만, 기본에서 이미 정한 것을 취소하는 규칙이 자꾸 나온다면 애초에 기본 설계가 잘못된 신호다. 나는 그럴 때 기본으로 돌아가 다시 짠다.
이 습관이 몸에 배면 반응형 작업이 한결 가벼워진다. 매 편에서 좁은 화면을 먼저 떠올리는 이 태도는 사실 시리즈 전체를 관통한다. 뷰포트, 브레이크포인트, 격자, 이미지, 타이포까지 모두 좁은 화면을 출발점으로 삼는 흐름 위에 놓이기 때문이다.
정리하면 모바일 퍼스트는 좁은 화면을 기본으로 삼아 min-width로 넓은 화면 규칙을 얹는 방식이며, 취소 코드를 줄이고 성능과 우선순위 관리에서 유리하다. 두 방향을 섞으면 우선순위 충돌과 디버깅 지옥이 오니 방향을 하나로 통일해야 한다. 다음 편에서는 이 위에 세울 유연한 격자를 본격적으로 다룬다.