개발자 도구의 기기 모드에서는 완벽했다. 아이폰 프리셋을 골라 화면을 넘겨봐도 아무 문제가 없었다. 그런데 실제 아이폰을 손에 쥐고 열자마자, 첫 화면이 주소창에 잘리고 버튼 하나가 안 눌렸다. 내 컴퓨터에서는 멀쩡한데 실제 기기에서는 깨지는, 개발자를 가장 미치게 하는 그 상황이었다. 그날 나는 개발자 도구를 너무 믿었다는 걸 인정했다.
반응형은 만드는 것만큼이나 확인하는 게 어렵다. 화면 크기, 입력 방식, 브라우저, 사용자 설정이 모두 제각각인데, 이 모든 조합을 다 만들어보고 하나하나 확인하는 건 불가능에 가깝다. 그래서 테스트에도 전략이 필요하다. 이번 편은 반응형을 어떤 순서로, 어떤 도구로 점검하고, 문제가 생겼을 때 어떻게 범인을 찾는지에 대한 이야기다.
1. 개발자 도구는 출발점일 뿐
가장 먼저 손이 가는 건 브라우저 개발자 도구의 기기 모드다. 화면을 휴대폰 크기로 줄여 보여주고, 유명한 기기들의 프리셋도 갖췄다. 빠르게 이것저것 바꿔보며 반복하기에 이만한 게 없다. 나도 작업의 대부분은 여기서 한다.
문제는 이걸 최종 확인으로 착각할 때 생긴다. 기기 모드는 화면 크기를 흉내 낼 뿐, 실제 기기의 여러 특성을 그대로 재현하지 못한다. 주소창이 접히고 펼쳐지는 동작, 손가락 터치의 부정확함, 실제 기기의 처리 속도, 폰트가 렌더되는 미묘한 차이 같은 건 흉내로 다 안 잡힌다. 나는 기기 모드에서 통과한 화면이 실기기에서 깨지는 걸 여러 번 겪고, 이건 시작이지 끝이 아니라는 걸 배웠다.
기기 모드를 쓸 때 내가 바꾼 습관이 하나 있다. 유명한 기기 프리셋만 하나씩 눌러보는 대신, 화면 폭을 손으로 잡고 아주 좁은 데서 아주 넓은 데까지 천천히 죽 늘려보는 것이다. 프리셋은 특정 폭의 스냅숏만 보여주지만, 진짜 문제는 프리셋과 프리셋 사이의 어중간한 폭에서 튀어나온다. 나는 이 연속적인 훑기로, 특정 폭에서만 배치가 무너지는 지점을 여럿 잡아냈다. 정해진 몇 개 폭만 확인하면 그 틈에 숨은 결함을 놓친다.
개발자 도구에는 화면 크기 말고도 유용한 손이 많다. 사용자의 취향 설정을 흉내 내는 기능으로 어두운 화면이나 움직임 최소화 설정을 켜볼 수 있고, 느린 네트워크를 흉내 내 폰트와 이미지가 늦게 올 때 화면이 어떻게 보이는지도 확인할 수 있다. 나는 광랜에서만 확인하다 놓친 로딩 중의 어색함을, 이 느린 네트워크 흉내로 여러 번 잡았다.
기기 모드에는 화면 배율을 조절하는 숨은 함정도 있다. 좁은 폭을 흉내 내려고 도구가 화면을 축소해 보여줄 때가 있는데, 이 축소 상태를 못 보고 실제보다 작게 판단하기 쉽다. 나는 배율이 백 퍼센트인지를 늘 확인하고, 흉내 낸 폭의 숫자를 곧이곧대로 믿기보다 그 숫자가 실제 어떤 기기에 해당하는지를 함께 떠올린다. 도구가 보여주는 화면과 진짜 기기의 화면 사이에는 늘 미묘한 틈이 있다.
2. 실기기를 이길 도구는 없다
결국 마지막 확인은 실제 기기여야 한다. 나는 이 사실을 인정하기까지 오래 걸렸다. 실기기로 확인하는 건 번거롭고, 기기를 여러 대 갖추기도 부담스러웠기 때문이다. 하지만 실기기에서만 드러나는 문제가 너무 많았다.
주소창이 실제로 접히고 펼쳐지는 동작은 실기기에서만 제대로 겪을 수 있다. 파인 화면의 안전 영역도, 손가락으로 버튼을 눌렀을 때의 정확도도, 실제로 만져봐야 안다. 나는 화면을 다 만들면 반드시 내 휴대폰으로 열어, 위아래로 넘겨보고 이곳저곳을 손끝으로 눌러본다. 마우스로는 결코 안 드러나던 문제들이 손끝 앞에서 금세 표가 난다.
실기기에서만 느껴지는 감각도 있다. 스크롤이 손끝을 얼마나 부드럽게 따라오는지, 버튼을 눌렀을 때 반응이 즉각적인지, 무거운 효과가 버벅이지는 않는지 같은 건 큰 컴퓨터 화면에서는 실감이 안 난다. 나는 실기기로 화면을 한참 만져보며, 눈으로는 멀쩡해도 손끝에 거슬리는 구석이 없는지 살핀다. 화면은 보는 것이기 이전에 만지는 것이라, 그 촉감은 만져봐야만 안다.
실기기의 화면을 컴퓨터에 연결해 들여다보는 방법도 있다. 컴퓨터와 휴대폰을 연결하면, 휴대폰 화면에서 벌어지는 일을 컴퓨터의 개발자 도구로 열어볼 수 있다. 실기기에서 실제로 어떤 요소가 넘치는지, 어떤 값이 적용됐는지를 큰 화면에서 살필 수 있어, 실기기의 진짜 동작과 개발자 도구의 편리함을 함께 누린다. 나는 실기기에서 이상한 게 보이면 이렇게 연결해 원인을 파고든다.
기기를 다 갖출 수 없으니, 여러 기기를 원격으로 빌려 확인하는 서비스도 쓴다. 손에 없는 기종이나 낯선 브라우저에서 어떻게 보이는지를, 그 기기를 사지 않고도 확인할 수 있다. 특히 내가 가진 것과 다른 계열의 기기에서만 나는 문제를 잡을 때 요긴하다. 다만 이런 서비스도 실제로 손에 쥔 감각까지 주지는 못해서, 나는 적어도 가장 대표적인 기기 한둘은 실물로 확인하는 걸 원칙으로 둔다.
계열이 다른 기기를 챙기는 건 생각보다 중요하다. 내가 쓰는 계열의 휴대폰에서만 확인하면, 다른 계열 브라우저에서만 나는 문제를 통째로 놓친다. 같은 웹 표준이라도 브라우저마다 해석에 미묘한 차이가 있어서, 한쪽에서 멀쩡한 화면이 다른 쪽에서 어긋나는 일이 드물지 않다. 나는 서로 다른 두 계열의 기기를 나란히 두고 같은 화면을 열어보는 습관을 들였고, 이 비교에서 한쪽만 확인했다면 못 봤을 차이를 여러 번 발견했다.
오래된 기기도 잊지 말아야 한다. 최신 기기만 확인하면, 몇 해 지난 휴대폰을 아직 쓰는 사람의 화면을 놓친다. 이런 기기는 처리 속도가 느려 무거운 효과가 버벅이고, 최신 표준을 아직 못 읽기도 한다. 나는 새 기능을 쓸 때 그것이 널리 자리 잡았는지를 확인하고, 못 읽는 환경을 위한 대비를 함께 둔다. 내 손안의 최신 기기가 세상의 전부는 아니다.
3. 눈에 안 보이는 것들을 점검하기
화면이 예쁘게 접히는 것만 보면 놓치는 게 많다. 반응형 점검에는 눈에 잘 안 띄는 항목들이 있고, 나는 이것들을 목록으로 만들어 매번 훑는다.
첫째는 글자 확대다. 시력이 약한 사용자는 브라우저나 시스템에서 글자를 크게 키워 쓴다. 나는 글자를 두 배로 키운 상태에서 화면이 여전히 멀쩡한지 확인한다. 이때 글자만 커지고 상자는 그대로라 글자가 넘치거나 잘리는 곳이 자주 드러난다. 앞서 유동 폰트에서 뷰포트 단위만 쓰면 확대가 안 된다던 그 함정도, 바로 이 확대 점검에서 걸린다.
둘째는 키보드다. 마우스나 손가락 없이 키보드의 이동 키만으로 화면의 모든 곳에 닿을 수 있는지, 지금 어디에 초점이 있는지가 또렷이 보이는지를 확인한다. 나는 마우스에 익숙해서 이걸 자주 잊었는데, 키보드로만 화면을 훑어보면 초점이 엉뚱한 순서로 튀거나 어떤 요소에 아예 닿지 못하는 문제가 드러난다. 특히 앞서 다룬 메뉴 패널이나 모달에서 이 점검이 중요하다. 손가락으로만 확인한 화면은, 손가락 없이 쓰는 사람 앞에서 반쪽짜리가 되기 쉽다.
여기에 하나 더, 나는 콘텐츠가 짧을 때와 길 때를 모두 확인한다. 화면을 만들 때는 보통 적당한 양의 예시 글로 채우는데, 실제로는 제목이 한 줄일 때도 있고 다섯 줄일 때도 있다. 글이 거의 없는 텅 빈 상태에서 레이아웃이 허전하게 무너지지 않는지, 글이 예상보다 훨씬 길 때 넘치거나 다른 요소를 밀어내지 않는지를 함께 본다. 딱 맞게 채운 예시 화면만 보면, 극단적인 길이에서 벌어지는 사고를 배포하고 나서야 알게 된다.
셋째는 사용자 취향 설정이다. 어두운 화면을 켰을 때 글자가 배경에 묻히지 않는지, 움직임 최소화를 켰을 때 큰 효과가 제대로 잦아드는지를 확인한다. 나는 어두운 화면만 켜보고 넘어갔다가, 정작 그 화면에서 특정 글자가 안 읽힐 만큼 흐린 걸 뒤늦게 발견한 적이 있다. 설정을 존중한다는 건 그 설정을 켠 상태를 실제로 확인한다는 뜻이다.
넷째는 느린 연결이다. 나는 광랜에 익숙해서 모든 게 즉시 뜨는 세상에 살지만, 사용자는 신호가 약한 곳에서 접속하기도 한다. 느린 연결을 흉내 낸 상태에서 화면이 로딩되는 과정을 지켜보면, 이미지가 늦게 와 화면이 들썩이거나 폰트가 늦게 와 글자가 출렁이는 문제가 눈에 들어온다. 다 로딩된 완성 화면만 보면 이 과정의 어색함을 영영 모른다.
4. 반복은 기계에 맡긴다
이 점검들을 화면 하나 고칠 때마다 손으로 다 하는 건 지친다. 그래서 나는 반복되는 확인의 일부를 기계에 맡긴다.
가장 요긴한 건 여러 화면 크기에서 자동으로 화면을 찍어 비교하는 방식이다. 화면을 바꿀 때마다 여러 폭에서 화면을 자동으로 찍어두고, 다음번에 찍은 것과 비교해 달라진 부분을 표시하게 한다. 내가 의도한 변화면 넘어가고, 의도치 않게 다른 화면이 틀어졌으면 그 차이가 곧바로 드러난다. 나는 한 곳을 고쳤다가 엉뚱한 다른 화면이 깨지는 사고를 이 방식으로 여러 번 미리 막았다. 사람의 눈은 방금 고친 그 자리만 뚫어져라 보느라, 반대편 구석이 함께 틀어진 걸 놓치기 마련이다.
가로 스크롤을 자동으로 잡아내는 검사도 걸어둔다. 여러 화면 폭에서 문서의 실제 폭이 화면 폭을 넘는지를 기계가 재게 하면, 사람이 눈으로 놓친 미세한 넘침도 숫자로 딱 걸린다. 앞 편에서 다룬 그 가로 흔들림을, 배포 전에 기계가 먼저 잡아주는 것이다. 나는 이 검사 하나로 가로 스크롤이 슬그머니 되살아나는 걸 여러 번 막았다.
다만 기계에 다 맡길 수는 없다. 화면이 예쁜지, 손끝에 편한지, 글이 잘 읽히는지 같은 건 결국 사람이 봐야 안다. 기계는 달라진 부분과 넘치는 부분을 성실히 일러주지만, 그게 좋은 변화인지 나쁜 변화인지는 판단하지 못한다. 나는 기계에게 지루한 반복 감시를 맡기고, 사람은 판단이 필요한 곳에 집중하는 식으로 역할을 나눈다.
디버깅에도 순서가 있다. 문제가 보이면 나는 먼저 어느 폭에서, 어느 기기에서, 어떤 설정에서 벌어지는지를 좁힌다. 모든 곳에서 나는 문제인지 특정 조건에서만 나는 문제인지를 가르면, 원인의 범위가 확 줄어든다. 그다음 앞서 이야기한 빨간 테두리나 요소 하나씩 지우기 같은 방법으로 범인을 특정한다. 재현 조건을 못 좁힌 채 이것저것 고치면, 고쳤는지 아닌지조차 확인할 수 없다.
재현이 안 되는 문제가 가장 골치 아프다. 어떤 사용자는 화면이 깨진다는데 내 손에서는 멀쩡할 때, 나는 그 사용자의 조건을 최대한 캐묻는다. 어떤 기기인지, 브라우저 글자를 키웠는지, 어두운 화면을 켰는지, 화면을 가로로 뒀는지. 이 조건들을 하나씩 맞춰가다 보면 어느 순간 내 화면에서도 그 문제가 재현된다. 재현만 되면 절반은 잡은 셈이다. 재현하지 못한 문제를 고쳤다고 말하는 건, 잡지도 않은 범인을 가뒀다고 우기는 것과 같다.
고친 뒤에 그 조건을 점검 목록에 추가하는 것도 잊지 않는다. 한번 데인 조건은 다음에 또 데기 쉽다. 나는 새로 발견한 함정을 만날 때마다 그걸 점검 목록에 적어두고, 다음 화면을 만들 때 그 항목까지 함께 훑는다. 이렇게 목록이 쌓이면, 같은 곳에서 두 번 넘어지는 일이 줄어든다. 실패는 기록해두지 않으면 반복되고, 기록해두면 자산이 된다.
테스트를 두고 내가 얻은 결론은 단순하다. 내 컴퓨터에서 잘 되는 건 아무것도 증명하지 못한다는 것이다. 나는 이제 다 됐다고 말하기 전에, 실기기로 열고, 글자를 키우고, 키보드로 훑고, 느린 연결을 흉내 내본다. 이 몇 분의 수고가, 배포한 뒤에 낯선 기기에서 깨졌다는 문의를 받는 며칠의 곤혹을 막는다. 다음 편에서는 이 시리즈를 마무리하며, 반응형을 하다 누구나 한 번은 빠지는 함정들을 한자리에 모아본다.