링크를 타고 처음 온 사람에게는 아무것도 없다
첫만남은 대부분 링크로 시작돼요. 누군가의 QR을 찍거나, 게임 방 링크를 받거나요. 그런데 링크를 타고 온 사람은 3초 전에 처음 온 사람이에요. 세션도, 닉네임도, 이 앱이 어떻게 생겼는지도 아직 없어요. 앱 안에 있는 사람에게는 완벽한 오류 메시지가, 막 도착한 사람에게는 아무 설명도 되지 못했어요. 이 “첫 도착”을 고친 기록이에요.
“이 프로필은 찾을 수 없어”
8월 20일, QR을 찍으면 분명히 있는 프로필이 “이 프로필은 찾을 수 없어”로 뜨는 문제가 있었어요. 새로고침하면 보였고요. 실제 사이트에서 재 보니, 익명 가입 요청과 프로필 요청이 1밀리초 차이로 나가고 있었어요. 프로필은 로그인한 사람만 읽을 수 있게 막혀 있는데, 가입이 끝나기 전에 프로필 요청이 도착하니 오류 대신 “빈 결과”가 돌아왔고, 그 빈 결과가 캐시에 남았어요.
QR 화면은 정의상 늘 세션이 없는 사람이 열어요. 그러니 이건 드문 경우가 아니라 QR의 전부였어요. 이제 프로필 요청은 세션이 생긴 뒤에만 나가고, 그 전까지는 로딩으로 보여요. 공유받은 방 링크에도 같은 구멍이 있어서 함께 고쳤어요.
인앱 브라우저라는 함정
카카오톡이나 인스타그램 안에서 링크를 열면, 그 앱 안의 작은 브라우저(WebView)가 열려요. 여기서 만들어진 세션은 오래 살아남지 못할 수 있어요. 그래서 첫만남은 인앱 브라우저를 감지하면 아무것도 불러오지 않고 “Safari나 Chrome으로 열어 달라”는 안내만 보여 줘요. 세션을 만들기 전에 확인하는 게 핵심이었어요.
그런데 감지할 앱 목록이 여섯 개뿐이라, 스냅챗은 그냥 통과했어요. “지금 다른 앱에 들어 있다”를 알려 주는 웹 표준은 없어요. 그래서 감지를 세 단계로 나눴어요.
- 앱이 브라우저 정보(User-Agent)에 스스로 이름을 남긴 경우. 틀릴 일이 없어서 확실한 것으로 쳐요.
- 안드로이드의 WebView 표시. 이것도 확실해요.
- 아이폰에서 Safari라는 이름 없이 열린 경우. 실제로 인앱일 가능성이 높지만 멀쩡한 브라우저일 수도 있어요.
확실한 경우만 막고, 세 번째는 앱을 열어 주면서 “계속하기”를 누를 수 있는 안내를 띄워요. 추측으로 사람을 막지 않도록요.
서명된 토큰은 살아 있는 계정이 아니다
9월 11일에는 한 번 와 봤던 브라우저만 자기소개 탭이 안 열리는 문제를 찾았어요. 새 브라우저에서는 잘 됐고요. 브라우저에 남아 있던 로그인 토큰은 서명이 유효했지만, 그 토큰이 가리키는 계정은 이미 지워진 뒤였어요. 토큰을 저장소에서 읽기만 하는 확인은 “세션 있음”이라고 답했고, 그 뒤의 모든 요청은 실패했어요. 사이트 데이터를 지우는 것 말고는 방법이 없었죠.
이제 세션을 네 가지로 구분해요. 프로필이 있으면 정상, 서버도 모르는 계정이면 ‘유령’이라 조용히 새로 발급, 계정은 있는데 프로필만 없으면 기록을 잃지 않도록 고치지 않고 알리기, 확인 자체가 실패하면 정상으로 간주하기. 네트워크가 불안정할 때 멀쩡한 계정을 지우지 않으려고요.
도착한 사람에게 먼저 보여 주기
게임 방 링크도 비슷했어요. 링크를 열면 빈 6자리 코드 칸과 숨은 자동 입장이 있었고, 방에 대해 처음 알게 되는 건 입장에 실패했을 때의 오류였어요. 이제는 코드로 방을 미리 보여 주는 기능이 있어서, 들어가기 전에 어떤 방인지 먼저 보여요. 판이 진행 중이면 오류가 아니라 “끝나면 자동으로 들어갈게”라며 기다렸다가 들어가요.
지도 방 링크는 브라우저가 위치 권한을 받기 전까지 아무것도 안 그리고 있었어요. 위치 권한 창은 허용·거절 말고도 “그냥 닫기”라는 세 번째 결과가 있고, 그때는 아무 응답도 오지 않아요. 지금은 방 정보는 위치 없이 먼저 보여 주고, 12초가 지나도 위치가 없으면 그에 맞는 안내를 해요.
정리하면
- 링크로 들어온 사람은 늘 “세션 없음”에서 시작해요. 이걸 예외가 아니라 기본 경로로 다뤄야 해요.
- 추측에 기반한 차단은 하지 않기. 확실할 때만 막아요.
- 저장된 토큰이 있다는 것과 그 계정이 살아 있다는 건 다른 이야기예요.