멀티 플랫폼 (2) — 네 곳이 같은 기록을 보게 만들기

표면을 네 개 만드는 건 결국 만드는 양의 문제다. 시간이 걸릴 뿐 방법은 안다. 이번 프로젝트에서 내가 가장 오래 붙들고 고민한 건 그게 아니라 "이 넷이 같은 기록을 보게 하려면 무엇을 정해야 하는가" 였다.

사용자 입장에서는 너무 당연한 요구다. 지하철에서 폰으로 링크를 담았으면, 회사 브라우저에서 열었을 때 거기 있어야 한다. 익스텐션으로 담은 글이 앱 라이브러리에 없으면 그건 고장이다. 사용자는 "지금 어느 표면에서 저장했더라"를 기억할 의무가 없다.

문제는 이 당연한 요구를 만족시키려면 당연하지 않은 결정을 여러 개 내려야 한다는 것이다. 밤마다 붙들고 있던 질문은 결국 네 개였다.

• 원본 : 진짜 기록은 폰에 있나, 서버에 있나
• 오프라인 : 인터넷이 없을 때 저장은 어떻게 되나
• 충돌 : 같은 기록을 두 곳에서 고치면 무엇이 이기나
• 로그인 : 계정을 언제 요구하나

하나씩 적어둔다.

첫 번째 질문 — 진짜 기록은 어디에 있는가

가장 먼저 정해야 했던 건 "원본이 어디 있느냐"였다. 폰 안인가, 서버인가.

처음 프롬프트에서 나는 프라이버시를 이유로 "가능하면 폰 안에서 처리"를 적었다. 그 생각은 지금도 유효하다. 그런데 폰 안에만 두면 브라우저에서 볼 수 없고, 익스텐션이 담은 글이 앱으로 갈 방법도 없다. 반대로 전부 서버에 두면 연동은 쉬워지지만 "내 생각이 남의 서버에 있다"는 찜찜함이 남는다.

결론은 역할을 갈라놓는 것이었다. 처리는 가능한 한 기기 안에서, 보관과 연결은 서버에서.

• 기기가 하는 일 : 요약, 제목 달기 — 내용을 들여다봐야 하는 작업 (이 이야기는 다음 편에서 자세히)
• 서버가 하는 일 : 보관, 그리고 네 표면이 같은 것을 보게 잇는 일

이렇게 갈라놓고 나니 "어디까지가 내 폰의 일이고 어디부터가 서버의 일인가"라는 질문에 매번 같은 답을 할 수 있게 됐다.

그리고 원칙을 하나 세웠다. 의견이 갈리면 서버가 이긴다. 폰에 있는 것과 서버에 있는 것이 다를 때 무엇을 믿을지 미리 정해두지 않으면, 나중에 화면마다 다른 판단을 하게 된다. 이건 나중에 결제에서도 똑같이 반복된 원칙이다.

두 번째 질문 — 인터넷이 없을 때는

기록 앱에서 제일 나쁜 경험은 "지금 저장 안 됩니다"라는 말이다. 생각은 스쳐 지나가는데 앱이 네트워크를 기다리고 있으면, 사용자는 다음부터 이 앱을 안 연다. 지하철 터널에서도 던질 수 있어야 한다.

그래서 저장은 일단 받아두고 나중에 올리는 쪽으로 잡았다. 사용자가 무언가를 던지면 앱은 즉시 "받았다"고 답하고, 연결이 돌아왔을 때 조용히 서버로 보낸다. 사용자가 기다리는 화면은 없다.

여기서 기획 결정이 하나 필요했다. 아직 서버에 못 올라간 기록을 화면에서 어떻게 보여줄 것인가. 흔한 방법은 작은 구름 아이콘이나 "동기화 대기 중" 배지를 붙이는 것이다. 그런데 그건 사용자에게 "아직 안전하지 않다"는 불안을 매번 상기시킨다. 우리 브랜드 규칙에는 남은 횟수 같은 숫자를 보여주지 않는다는 "사일런트 미터링"이 있는데, 같은 정신을 여기에도 적용했다. 잘 되고 있을 때는 아무 말도 하지 않는다. 정말 문제가 생겼을 때만 말한다.

세 번째 질문 — 같은 기록을 두 곳에서 고치면

이게 제일 오래 고민한 지점이다. 폰에서 어떤 기록의 제목을 고치고, 비슷한 시각에 웹에서 같은 기록을 지웠다면 무엇이 맞는가. 정답이 없는 문제다. 소프트웨어 세계에서는 이 문제를 푸는 정교한 방법들이 있지만, 1인 팀이 열흘 안에 그걸 제대로 만들 수는 없다.

그래서 나는 문제를 푸는 대신 문제가 잘 생기지 않게 설계하는 쪽을 택했다. 채록은 사용자가 여러 곳에서 같은 문서를 동시에 편집하는 앱이 아니다. 대부분의 쓰임은 "한 곳에서 던지고, 다른 곳에서 읽는다"이다. 그렇다면 충돌이 날 수 있는 표면을 애초에 줄이면 된다. 익스텐션은 담기만 하고 편집하지 않는다. 웹 뷰어는 읽기 중심이다. 본격적인 편집은 앱에서 한다. 이렇게 각 표면의 역할을 좁혀 놓으니, 충돌 가능성 자체가 크게 줄었다.

기획자로서 이 결정이 마음에 든다. 기술적으로 어려운 문제를 만나면 대개 두 가지 길이 있다. 그 문제를 정면으로 푸는 길과, 제품의 정의를 조금 바꿔서 그 문제를 만나지 않는 길. 후자를 고를 수 있는 건 제품을 정의하는 사람뿐이다. 개발팀에 요구사항을 넘긴 뒤에는 못 하는 선택이다.

네 번째 질문 — 로그인이 없으면 아무것도 안 되는가

연동을 하려면 "이게 누구 기록인지" 알아야 하고, 그러려면 로그인이 필요하다. 그런데 앱을 처음 켠 사람에게 로그인부터 요구하면 상당수가 거기서 나간다. 무엇을 해주는 앱인지 아직 보지도 못했는데 계정부터 만들라니.

여기서도 균형을 잡아야 했다. 결론은 먼저 써보게 하고, 여러 표면을 함께 쓰고 싶어질 때 로그인을 권하는 순서다.

• 로그인 전 : 앱 안에서 담고 요약하는 것까지 다 된다
• 로그인 후 : 담은 것이 다른 표면에서도 보인다

로그인은 "기능을 잠그는 문"이 아니라 "여러 곳을 잇는 다리"다. 그 문장이 온보딩 카피에 그대로 반영됐다. 같은 기능을 어떤 이유로 설명하느냐에 따라 사용자가 느끼는 게 완전히 달라진다.

그리고 8월 4일, 작업 방식이 바뀐 날

전환점이 하나 있었다. 그때까지 프로젝트는 내 노트북 안에만 있었는데(로컬 저장소), 이날 코드를 GitHub라는 클라우드 저장소로 올렸다. 이게 왜 전환점이냐면 — 이때부터 출퇴근길에도 일을 시킬 수 있게 됐다. 지하철에서 휴대폰으로 클라우드의 AI 팀원에게 "어젯밤 그 버그, 원인 찾아서 고쳐놔"라고 지시하면, 회사에 도착할 때쯤 작업 결과가 올라와 있다. 퇴근길에 검토하고, 집에 가서 내 폰으로 확인한다. 사무실 없는 팀의 출근길 스탠드업 미팅이랄까.

돌아보면 웃긴 대칭이다. 나는 사용자의 기록이 네 표면에서 이어지게 만드느라 열흘을 고민했는데, 정작 내 작업이 노트북과 지하철에서 이어지게 만든 건 그날 저녁의 결정 하나였다. 연동이 필요했던 건 사용자만이 아니었다.