배포 전 점검은 남의 기기에서 한 번 열어 봐야 끝난다

이 서비스를 끝까지 써 본 사람은 아직 한 명뿐이다

배포 날짜가 며칠 안 남았다. 기능은 다 붙었고, 디자인 확인도 끝났고, 서버에도 올라가 있다. 남은 건 여는 일뿐인 것 같다. 그런데 이 서비스를 첫 화면부터 마지막까지 실제로 통과해 본 사람은 아직 만든 사람 한 명뿐이다.

만든 사람은 자기가 낸 길로만 다닌다. 가입 폼에 넣는 값도 늘 쓰던 그 값이고, 결제 화면까지 가는 경로도 자기가 짠 순서 그대로다. 그 길은 이미 수십 번 지나갔으니 막힐 리가 없다. 문제는 첫 사용자가 그 길로 오지 않는다는 것이다. 검색 결과에서 상세 페이지로 바로 들어오고, 가입하다 말고 창을 닫았다가 한 시간 뒤에 다시 열고, 결제 도중에 뒤로가기를 누른다.

그래서 배포 전 점검은 항목을 몇 개 확인했느냐가 아니라 누가 어느 길로 지나가 봤느냐의 문제에 가깝다. 목록을 길게 만드는 것보다 목록에 없던 길을 한 번 걸어 보는 쪽이 걸리는 게 많다.

한 줄로 이어서 걸어 본다

화면을 하나씩 따로 확인하면 화면은 다 멀쩡한데 서비스는 안 되는 상태가 나온다. 사용자가 실제로 하는 일은 화면 하나가 아니라 들어와서 목적을 이루기까지의 한 줄이기 때문이다. 그 줄을 끊지 않고 통째로 지나가 본다. 가입하고, 인증 메일을 받고, 로그인하고, 물건을 담고, 결제하고, 내역을 확인하는 데까지.

여기서 걸리는 건 대개 성공한 다음이 아니라 실패한 다음이다. 카드가 거절됐을 때, 인증 메일이 안 왔을 때, 결제 도중에 뒤로가기를 눌렀을 때, 같은 버튼을 연달아 두 번 눌렀을 때. 잘 되는 경우는 만들면서 수십 번 봤지만 실패 경로는 한 번도 안 지나간 채로 배포되는 일이 흔하다. 주문이 두 건 들어가거나 결제는 됐는데 주문이 없는 상태가 여기서 나온다.

계정도 새로 만들어 본다. 개발하면서 쓰던 계정에는 권한과 데이터가 이미 쌓여 있어서 빈 화면을 본 적이 없다. 오늘 처음 가입한 사람에게 무엇이 보이는지는 새 계정으로만 확인된다.

밖으로 나가는 것은 도착해야 확인된다

화면에 전송되었다는 문구가 뜨는 것과 그 메일이 상대 받은편지함에 있는 것은 다른 일이다. 문의 폼, 가입 인증, 비밀번호 재설정, 주문 확인, 알림. 이건 실제 주소로 보내서 실제로 열어 보기 전에는 확인이 안 된다.

개발 중에는 테스트용 발송 도구로 확인하고 넘어가는 경우가 많은데, 그 도구는 메일을 바깥으로 내보내지 않는다. 실제 발송으로 바뀌는 순간 발신 도메인 인증이 걸린다. 주요 메일 서비스가 발송 도메인에 SPF, DKIM, DMARC 설정을 요구하는 쪽으로 정리된 지 몇 해 됐고, 이 설정이 없으면 메일이 스팸함으로 가거나 아예 거부된다. 도메인 설정은 개발이 아니라 도메인 관리 쪽 일이라, 누가 하기로 했는지 정해 두지 않으면 열고 나서야 발견된다.

받는 쪽도 한 번은 확인한다. 문의 폼이 보내는 메일이 담당자 스팸함에 쌓이고 있으면, 폼은 정상인데 문의만 없는 상태가 된다.

새 기기, 느린 회선, 로그인하지 않은 창

만든 사람의 환경은 늘 최신이고, 화면은 크고, 회선은 빠르고, 브라우저에는 이미 로그인이 되어 있다. 이 네 가지가 전부 다른 상태를 한 번은 만들어 본다. 몇 년 된 실제 휴대폰으로 열어 보고, 로그인하지 않은 창으로 첫 화면부터 들어와 보고, 회선이 느릴 때 화면이 어떤 순서로 그려지는지 본다. 이미지가 무거운 사이트는 이 조건에서 처음 문제가 드러난다.

공개 설정도 여기서 같이 본다. 개발 중에는 검색엔진이 긁어가지 못하게 막아 두는데, 그 설정이 그대로 배포되면 사이트는 멀쩡히 열리는데 검색에는 잡히지 않는다. 반대로 테스트용 주소가 열려 있어 같은 내용이 두 군데 떠 있는 경우도 있다. 둘 다 화면만 봐서는 안 보이고, 열고 몇 주 뒤에 검색이 왜 안 되냐는 질문으로 돌아온다.

되돌릴 수 있는 상태인가

점검을 아무리 해도 열고 나서 나오는 게 있다. 그래서 마지막 질문은 무엇을 확인했느냐가 아니라 잘못됐을 때 돌아갈 데가 있느냐다. 직전 버전으로 되돌리는 방법을 아는 사람이 있는지, 그 작업이 몇 분 안에 끝나는지, 데이터베이스를 건드린 변경이라면 백업이 언제 것인지.

되돌리기 어려운 작업은 따로 표시해 둔다. 화면이나 코드는 되돌리면 그만이지만 사용자 데이터를 옮기거나 지운 작업, 이미 나간 메일, 이미 승인된 결제는 되돌아가지 않는다. 이런 것들을 여는 날 한꺼번에 몰아 두지 않는 것도 점검의 일부다.

여는 시각도 결정이다. 금요일 저녁에 열면 문제가 생겨도 볼 사람이 없다. 오류를 알려 주는 장치는 열기 전에 켜 둔다. 사용자가 전화로 알려 주기 전에 이쪽이 먼저 아는 상태인지 아닌지에서 첫날의 차이가 난다.

안 된다는 말은 아직 점검 결과가 아니다

받은 제보가 결제가 안 된다는 한 줄이면 고치는 쪽은 처음부터 다시 재현해야 한다. 무엇을 어떤 순서로 눌렀는지, 어느 기기와 어느 브라우저인지, 어떤 계정으로 언제 그랬는지, 화면에 무엇이 떴는지. 이 네 가지가 붙어 있으면 대개 그 자리에서 원인이 좁혀지고, 없으면 재현하는 데만 하루가 간다. 화면을 찍어 두는 것이 가장 빠르다.

점검하는 쪽과 고치는 쪽이 다른 사람이면 이 기록 방식을 미리 맞춰 둔다. 열기 직전 며칠은 발견이 몰리는 때라, 정리되지 않은 제보가 쌓이면 고칠 시간이 그걸 읽는 데 쓰인다.

처음 보는 사람 역할은 저희가 맡습니다

위플의 배포 전 품질 점검은 만든 쪽이 한 번도 안 가 본 길을 대신 걸어 보는 일입니다. 무너지면 안 되는 흐름을 실제 브라우저가 따라 하는 자동 테스트로 만들고, 브라우저와 화면 크기 조합을 바꿔 가며 돌리고, 빈 값이나 느린 회선, 중복 클릭처럼 실사용에서 터지는 조건을 일부러 넣어 봅니다. 저장소 접근 권한은 필요 없고 열리는 주소와 테스트 계정이면 됩니다. 무엇을 맡는지와 값이 어떤 단위로 매겨지는지는 가격 안내에 적어 두었습니다. 개발이 아직 안 끝난 시점에 부르셔도 되고, 그 편이 고칠 시간이 남습니다. 발견한 것은 재현 절차와 화면 기록, 심각도까지 붙여 정리해 드리니 그대로 개발자에게 넘기시면 됩니다.