모바일 개발자

서비스가 브라우저 안에만 있던 시절에는 개발자를 화면 쪽과 서버 쪽으로만 갈라도 충분했습니다. 스마트폰이 퍼지면서 같은 서비스를 아이폰과 안드로이드에서도 쓰게 해 달라는 요구가 들어왔는데, 이 일은 브라우저 화면을 만들던 방식으로는 되지 않았습니다.

가장 크게 어긋난 것은 내보내는 방식입니다. 웹은 고친 코드를 서버에 올리면 그다음 접속부터 모두가 새 화면을 봅니다. 앱은 애플과 구글의 스토어에 완성본을 올려 심사를 통과해야 하고, 통과한 뒤에도 사용자가 각자 업데이트를 받아야 바뀝니다.

이 차이가 실제로 드러나는 장면은 이렇습니다. "결제 버튼이 안 눌려요" 라는 제보가 들어온 날, 웹은 30분 만에 고쳐 올렸는데 앱은 고친 빌드가 심사를 기다리느라 이튿날 오후에야 나갔습니다. 그러고도 업데이트를 미룬 사용자 30퍼센트는 한동안 고장 난 화면을 그대로 봤습니다.

그래서 기기에 설치돼 돌아가는 프로그램의 제약을 처음부터 알고 설계하는 사람이 필요해졌습니다. 심사 일정, 옛 버전과 새 버전이 함께 도는 상황, 배터리, 카메라와 위치 같은 권한이 전부 여기에 걸립니다.

하루의 절반 이상은 디자인 시안을 앱 화면으로 옮기고 그 화면이 서버에서 받아 온 값을 제대로 띄우는지 실제 기기에서 확인하는 데 씁니다. 나머지는 내보내는 일과 내보낸 뒤를 보는 일입니다.

1. 화면 구현 — 시안을 iOS 와 안드로이드 각각의 코드로 옮깁니다. 두 운영체제는 기본 부품이 달라 같은 화면도 두 번 만듭니다. 목록을 당겨 새로고침하는 동작 하나도 구현이 다릅니다.
2. 서버 연동 — API로 서버에 값을 요청하고 받은 결과를 화면에 붙입니다. API 는 프로그램끼리 무엇을 어떤 모양으로 주고받을지 미리 맞춰 둔 창구입니다. 앱에는 조건이 하나 더 붙습니다. 지하철에서 신호가 끊기는 상황이 늘 있어서, 실패했을 때 무엇을 보여 주고 언제 다시 시도할지를 화면마다 정해 둬야 합니다.
3. 기기 차이 대응 — 화면이 작은 구형 기기와 접히는 기기가 같은 앱을 씁니다. 운영체제 버전도 섞여 있어서, 새 기능이 최신 버전에서만 되면 옛 버전에 보여 줄 대체 화면을 함께 만듭니다.
4. 심사 제출과 배포 — 완성본을 만들어 스토어에 올리고 심사를 받습니다. 통과한 뒤에도 한 번에 다 풀지 않고 사용자 1퍼센트에게 먼저 열어 오류가 늘지 않는지 본 다음 넓힙니다. 릴리스 시점을 개발팀이 혼자 정하지 못하는 자리입니다.
5. 출시 뒤 확인 — 앱이 갑자기 꺼지는 비율을 봅니다. 1천 번 실행에 한 번 아래를 정상으로 잡고, 새 버전을 낸 다음 날 이 값이 0.1퍼센트에서 0.6퍼센트로 뛰면 원인을 찾아 다음 버전에 고칩니다.

앱 하나가 나가는 동안 다섯 자리와 붙습니다. 대부분은 앱 특유의 제약을 상대에게 알려 주는 대화입니다.

1. 프로덕트 디자이너 — 시안을 받습니다. 두 운영체제가 다르게 다루는 부분을 여기서 정리합니다. 뒤로 가기를 화면 왼쪽 위 버튼으로 할지 기기 버튼에 맡길지 같은 것입니다.
2. 백엔드 개발자 — 주고받을 값의 모양을 맞춥니다. 서버는 배포하면 바로 바뀌지만 앱은 옛 버전이 몇 달씩 남아서, 서버가 그 버전들까지 받아 줘야 한다는 점을 매번 확인합니다.
3. 프로덕트 매니저 — 일정과 범위를 맞춥니다. 심사에 걸리는 시간이 일정표에 들어가 있는지, 이번 버전에 못 들어간 기능을 언제 내보낼지를 여기서 정합니다.
4. QA 엔지니어 — 내보내기 전에 함께 확인합니다. 앱은 되돌리기가 어려워 웹보다 확인 범위가 넓고, 기기와 운영체제 조합을 몇 가지 정해 두고 돌립니다.
5. 그로스 마케터 — 스토어 설명과 앱 푸시를 함께 다룹니다. 푸시는 앱이 기기에 직접 띄우는 알림인데, 사용자가 권한을 거부하면 아예 못 보내서 언제 권한을 묻는지가 마케팅 성과까지 흔듭니다.

"이 화면 안드로이드에서는 키보드가 올라오면 저장 버튼이 가려져요."

한쪽 운영체제에서만 나는 문제라 시안을 그대로 쓰기 어렵다는 뜻입니다.

"심사에 하루 이틀 걸리니까 목요일까지는 빌드 주셔야 다음 주에 나가요."

앱은 내보내는 날짜를 개발팀이 혼자 정하지 못한다는 말입니다.

"이건 서버에서 내려 주는 값으로 바꿔 두면 앱 업데이트 없이도 고칠 수 있어요."

화면에 박아 두는 대신 서버가 정하게 해서, 나중에 심사를 다시 기다리지 않으려는 제안입니다.

페이지덱이 문서 공유 기능을 앱에 넣던 분기에 태오가 가장 많이 한 말이 세 번째 문장이었습니다. 공유 링크의 만료 기간을 7일로 할지 30일로 할지가 안 정해졌는데, 이 값을 앱 안에 적어 두면 바꿀 때마다 새 버전을 내고 심사를 기다려야 합니다. 태오는 값을 서버에서 받아 오게 만들었고, 두 달 뒤 지현이 기간을 14일로 바꾸자고 했을 때 앱은 손대지 않았습니다.

반대 경우도 있었습니다. 민서가 공유 화면의 버튼 배치를 바꾼 것은 화면 자체라 앱 업데이트 말고는 방법이 없었고, 태오가 다음 정기 배포에 묶어 내보냈습니다.

웹 화면을 만들 줄 알면 앱도 만든다고 여기는 경우가 가장 흔합니다. 둘 다 사용자가 보는 화면을 다루니 같은 일로 보이고 쓰는 개념도 겹칩니다. 그런데 앱에는 웹에 없는 조건이 셋 붙습니다. 심사를 거쳐야 하고, 옛 버전이 계속 돌아가고, 배터리와 저장 공간을 다른 앱과 나눠 쓴다는 점입니다. 이 셋을 모르고 만들면 심사에서 반려되거나 켜 두기만 해도 배터리가 빠르게 닳는 앱이 나옵니다. 프론트엔드 개발자와 하는 일의 성격이 가깝다는 말은 맞지만 그대로 갈아 끼울 수 있다는 뜻은 아닙니다.

새 버전을 내보내면 모든 사용자가 그 버전을 쓴다고 생각하는 것도 잦은 오해입니다. 웹이 그렇게 동작하니 앱도 같을 것 같지만, 앱은 사용자가 업데이트를 받아야 바뀌고 자동 업데이트를 꺼 둔 사람도 많습니다. 새 버전이 나간 지 한 달이 지나도 이전 버전을 쓰는 사람이 20퍼센트쯤 남는 일이 흔합니다. 이걸 잊고 서버를 새 앱에만 맞춰 고치면 업데이트를 미룬 사용자의 화면이 어느 날 빈 목록으로 바뀝니다. 그래서 서버는 옛 버전의 요청도 한동안 받아 주고, 너무 오래된 버전은 앱을 열 때 업데이트 안내 화면으로 막습니다.