웹 페이지의 모바일 대응 방식에 대한 선호 순위

개인적인 순위다.

m. 같은 서브도메인을 붙이기

가장 좋아하지 않는 방식이다. URL이 달라지기 때문에 다른 데에 링크하면 일반 데스크탑으로 보는 사람도 모바일 버전을 굉장히 큰 화면에 부풀려서 이상하게 봐야 한다. 우리나라의 대부분 사이트와 Twitter 등이 이런 방식을 쓴다.

무대응

서브도메인 붙이느니 그냥 대응 안해주는 게 편하다. 어차피 요즘 전화기는 해상도가 높아서 지원 안해도 그렇게까지 불편하진 않다. 우리나라 대부분 사이트가 이 방식을 쓰지만 그런 사이트는 대부분 웹 표준도 안 지킨다는 게 함정. GitHub도 무대응인데 그렇게 불편하지는 않다.

User-Agent 헤더 보고 다른 HTML 내려주기

애드혹 내용 협상이라고 할만한데, User-Agent를 보고 서버에서 모드를 나누는 것은 대부분 좋은 아이디어는 아니다. 명시적 합의가 아니기 때문에 미래에 대응할 수 없기 때문이다. (이 때문에 Android용 Firefox를 쓰면 데스크탑 버전으로 보이는 경우가 있다. 왜 그러겠는가?) Tumblr가 이런 방식을 쓴다. 이 페이지를 모바일에서 들어가보면 아예 다른 마크업으로 서빙되는 것을 볼 수 있다.

link[media] 속성 통해서 다른 스타일시트 선택하기

흔히 미디어 쿼리라고 하는 방식인데 아래서 언급하는 반응적 디자인이라는 패러다임이 나오기 전까지 제일 괜찮은 선택이었다. 물론 반응적 디자인을 적용하려고 해도 이 방식을 함께 사용해야 한다.

반응적 디자인 (responsive design)

웹 디자인을 잘 모르는 사람들한테도 널리 퍼진 개념. 미디어 쿼리 스펙에 브라우저의 해상도 등을 쿼리해서 조건적으로 스타일을 적용할 수 있는 기능이 있는데, 해당 스펙을 적극적으로 활용하여 주어진 공간에 적절하게 적응하자는 게 아이디어의 핵심이다. 근데 이 방식은 생각보다 잘 구현하기가 어렵다. 왜냐하면 포토샵 같은 정적인 시안으로 표현하려고 하면 시안의 경우의 수가 지원하려는 해상도의 종류(보통 ‘버킷’이라고 묶는 것 같다)와 페이지의 수의 곱으로 늘어나기 때문이다. 그래서 편의상 몇개의 시안만 대표적으로 만들게 되면 실제로 만들 때는 다 구멍이 나서 어색하게 된다. 즉, 공수가 많이 든다. Trello 같은 최신의 해외 사이트들이 대체로 이 방식을 쓴다.

이 방식을 우아한 퇴행(graceful degradation)의 기술적 지원으로 잘못 이해하면 특정 해상도에서 일부 기능에 접근할 수 없게 되는 식으로 만들어지기 십상이고 실제로 그런 사이트들이 종종 있기 때문에 최근에는 이 방식에 대한 거부감도 생겨나고 있는 듯하다. 가령 스마트폰으로 들어가면 일부 기능이 안되서 데스크탑 사이트를 강제로 열고 싶은데 미디어 쿼리를 쓰면 그런건 힘들기 때문에 (다행히 Android용 Chrome 같은 경우에는 데스크탑 브라우저로 속이는 기능이 버젓이 존재해서 우회 가능하긴 하지만) 사람들이 짜증을 내는 것이다. 그런 일이 없도록 잘 만들어야 하는데 이래서 반응적 디자인이 구현하기 어렵다는 것이다.