멀티 플랫폼 (1) — 익숙한 두 개, 처음인 하나
iOS와 Android는 만들어봤다. 크롬 익스텐션은 처음이었고, 앱과 전혀 다른 물건이었다.
최종 구성은 이렇다. 기획자의 언어로 풀면:
- 앱(iOS + Android) : React Native라는 기술로 한 벌의 코드에서 두 플랫폼 앱을 만든다. 첫 프롬프트에서 "RN으로"라고 했던 그것.
- 웹 : 서비스 소개 페이지와, 내 기록을 브라우저에서 볼 수 있는 뷰어.
- 크롬 익스텐션 : 웹서핑 중 마음에 드는 글을 클릭 한 번으로 채록에 "담기".
- 서버 : 로그인, 데이터 동기화, 결제 등급 관리, 이미지 처리를 맡는 클라우드(Firebase).
네 개를 나란히 적어놓으면 균등해 보이지만, 나에게는 무게가 전혀 달랐다. iOS와 Android 앱은 전에도 만들어서 스토어에 올려본 적이 있다. 앱이 어떤 리듬으로 만들어지고 심사에서 무엇이 문제가 되는지, 사용자가 어디서 이탈하는지에 대한 감각이 몸에 남아 있었다. 웹도 마찬가지다. 그런데 크롬 익스텐션은 이번이 처음이었다.
처음 만드는 물건 앞에서 기획자가 하는 일
익스텐션을 처음 붙이면서 가장 먼저 깨진 건 "앱을 작게 만든 것"이라는 내 짐작이었다. 익스텐션은 작은 앱이 아니라 다른 종류의 물건이었다.
나란히 놓고 보면 이렇게 다르다.
- 주의 : 앱은 사용자가 들어와서 내 화면만 본다 / 익스텐션은 사용자가 다른 일을 하는 중이다
- 지면 : 앱은 화면 전체가 내 것 / 익스텐션은 구석의 아이콘 하나와 잠깐 뜨는 작은 창
- 설명할 기회 : 앱은 온보딩이 있다 / 익스텐션은 없다. 설명하려 들면 방해가 되고, 안 하면 뭘 하는 물건인지 모른다
- 머무는 시간 : 앱은 몇 분 / 익스텐션은 몇 초
기사를 읽다가, 문서를 보다가, 잠깐 손을 뻗어 버튼을 누른다. 그게 익스텐션이 가진 전부다.
그래서 익스텐션의 기획은 "담기"라는 동작 하나로 좁혔다. 지금 보고 있는 페이지를 채록에 넘기는 것, 그리고 넘어갔다는 사실을 1초 안에 알려주는 것. 그게 전부다. 요약 결과를 보여주지도 않고, 폴더를 고르게 하지도 않는다. 정리는 어차피 채록이가 할 일이고, 사용자는 다시 읽던 글로 돌아가야 하니까. 앱에서라면 "이왕 들어온 김에"라고 붙였을 기능들을 익스텐션에서는 전부 덜어냈다.
처음이라 모르는 것도 많았다. 익스텐션이 웹페이지를 읽으려면 사용자에게 권한을 받아야 하는데, 이 권한이라는 게 앱의 권한과 성격이 다르다. 앱에서 카메라 권한을 요청하면 사용자는 "사진 찍는 앱이니까"라고 납득한다. 익스텐션이 "당신이 보는 모든 페이지를 읽겠다"고 하면 문장만 봐서는 꽤 무섭다. 실제로 하는 일은 사용자가 버튼을 눌렀을 때 그 페이지 하나를 가져오는 것뿐인데도 그렇다. 기술적으로 어떻게 최소화할지는 AI 팀원에게 맡겼지만, 그 권한 문구를 사용자가 어떻게 읽을지를 걱정하는 건 내 몫이었다.
배포 방식도 달랐다. 앱은 스토어에 올리고 심사를 받는다는 걸 알고 있었지만, 익스텐션은 심사의 리듬도 다르고 배포 후 사용자에게 업데이트가 도달하는 방식도 달랐다. 익숙한 줄 알았던 절차를 처음부터 다시 배우는 기분이었다. 20년 동안 앱을 만들어왔다고 해서 브라우저 위의 물건까지 아는 건 아니었다.
OTA — 밤에 고치면 아침에 반영되는 마법
혼자서 네 표면을 굴릴 수 있었던 비결 중 하나는 OTA 업데이트라는 구조다. Over-The-Air, 즉 무선 업데이트. 보통 앱을 고치면 애플과 구글의 심사를 다시 받아야 하는데(며칠씩 걸린다), 앱의 "속살"에 해당하는 부분은 심사 없이 바로 내려보낼 수 있는 통로가 있다. 밤에 버그를 고치면 아침에 내 폰에 반영돼 있는 마법.
이 구조가 1인 팀에게 주는 건 속도가 아니라 용기다. 고치는 데 사흘이 걸리면 어지간한 어색함은 그냥 두게 된다. 몇 시간이면 반영된다는 걸 알면 "이 문구 좀 이상한데"라는 생각이 들었을 때 바로 손을 댄다. 열흘 동안 다듬어진 디테일의 절반쯤은 이 통로 덕분에 살아남았다.
물론 공짜는 아니다. 앱의 "뼈대"(네이티브)를 바꾸면 반드시 정식 빌드와 심사를 거쳐야 하는데, 뼈대가 다른 옛 버전 앱에 새 속살을 내려보내면 앱이 아예 켜지지 않는 대참사가 날 수 있다. 우리 팀은 이걸 규칙으로 막았다 — "뼈대를 만졌으면 버전을 올린다", "새 부품은 있는지 먼저 확인하고 조심스럽게 불러온다" 같은 규칙들이 하네스 문서에 박혀 있고, AI는 매 세션 그걸 읽고 일한다. 실제로 이 규칙이 없던 초기에 개발용 앱이 켜지자마자 죽는 사고를 겪었고, 그 밤의 교훈이 문서의 한 줄이 됐다.
여기까지가 "네 개의 표면을 어떻게 만들었나"에 대한 이야기다. 그런데 진짜 어려운 건 만드는 게 아니라, 이 넷이 같은 것을 보게 만드는 일이었다. 그 이야기는 다음 편에서.