'사용자가 취소함'이 0.2초 만에 돌아왔습니다

로그인 실패 계측을 28일치 전수로 훑었습니다. "사용자가 로그인을 취소했다"고 기록된 사유가 수백 건이었습니다.

그 라벨을 믿지 않고, 탭에서 결과까지 걸린 시간을 같이 재봤습니다.

당신의 실패 로그에 적힌 사유는, 무엇을 근거로 그렇게 적혀 있습니까?

0.2초는 사람의 시간이 아닙니다

성공한 로그인은 플랫폼과 무관하게 중앙값 7.8초였습니다 — 시트가 뜨고, 계정을 고르고, 승인하는 데 사람이 실제로 쓰는 시간입니다.

한쪽 플랫폼의 "취소"는 중앙값이 0.2초였습니다.

사람이 시트를 열고 닫는 데 0.2초는 물리적으로 불가능합니다. 시트가 뜬 적이 없다는 뜻입니다.

다른 플랫폼의 "취소"는 중앙값 6.5초입니다 — 이건 진짜 취소입니다. 같은 이름의 사유가 두 플랫폼에서 서로 다른 현상을 가리키고 있었습니다.

폴백이 빈 창을 만들고 있었습니다

원인은 인증 창을 띄울 때 붙일 화면(앵커)을 고르는 한 줄이었습니다.

.first(where: { $0.isKeyWindow }) ?? ASPresentationAnchor()

이 폴백은 "앵커 없음"을 뜻하지 않습니다. 어느 화면에도 연결되지 않은 빈 창을 새로 만들어 넘깁니다.

인증 시스템은 그 빈 창에 아무것도 띄우지 못하고 즉시 "취소됨"으로 끝냅니다. 호출부는 그걸 그대로 "사용자가 취소함"으로 기록합니다.

시스템 오류가 사용자의 취소로 위장되고 있었습니다.

여기서 선택이 갈립니다

이 데이터는 설치의 절반이 로그인 화면에서 사라졌던 조사와 같은 데이터입니다. 앞글은 서버가 익명 접근을 허용하던 구조 문제였고, 이번 글은 같은 데이터에서 나온 다른 메커니즘입니다.

28일 동안 로그인 실패자 97명 중 51명은 재시도해서 성공했고, 46명은 영구적으로 이탈했습니다. 그중 앱을 한 번이라도 써본 사람은 단 3명뿐이었습니다. 나머지 43명은 첫 화면조차 못 넘겨봤습니다. 그 기간 신규 유입 대비 17%가 문 앞에서 사라진 셈입니다.

당신이라면 "취소 318건"을 보고 무엇을 하겠습니까 — 로그인 UI 문구를 고치겠습니까, 사유 라벨을 의심하겠습니까?

문구를 고쳤다면 318건은 그대로 남았을 겁니다. 취소한 사람이 없었으니까요.

흥미로운 부수 발견

로그인 수단을 하나만 시도한 사람보다, 두 개를 번갈아 시도한 사람의 성공률이 더 낮았습니다 — 탭 2.2회에 성공 69%, 탭 17.5회에 성공 23%.

대안을 몰라서 못 들어간 게 아닙니다. 시도한 수단이 전부 안 열렸다는 뜻입니다. "선택지를 늘리자"는 처방이 여기서는 정확히 반대 방향입니다.

자가진단

• 실패 사유 라벨 옆에 경과 시간이 있습니까? 없으면 라벨의 진위를 확인할 방법이 없습니다.
• 같은 사유 코드가 플랫폼별로 같은 현상을 가리킨다고 가정하고 있지 않습니까?
• 폴백이 "없음"이 아니라 빈 객체를 만들어 넘기고 있지 않습니까?

솔직한 부분

• 사유 코드 중 하나는 경과 시간이 0.0초였는데, 이건 이번에 고친 앵커 문제와 다른 경로입니다. 특정 로그인 수단은 자체적으로 화면을 띄워서 이 앵커 로직을 아예 안 거칩니다. 기기 쪽 설정 문제일 가능성이 높지만 원인을 확정하지 못했습니다.
• 계측 자체에 구멍이 있었습니다. "로그인 수단을 눌렀다"에는 어떤 수단인지 기록되는데, "로그인 실패"에는 그 정보가 빠져 있었습니다. 수백 건의 실패가 어떤 수단에서 났는지 끝내 못 갈랐습니다. 이번에 계측을 보강했지만 과거 데이터는 되돌릴 수 없습니다.
• 다른 플랫폼 쪽 90초 지연은 인증 시스템 자체의 타임아웃 상한이라, 이번엔 고치지 않았습니다.

당신 실패 로그에서 사유 하나를 골라, 그 사유의 경과 시간 중앙값을 내보세요. 사람이 쓸 수 없는 시간이면 라벨이 거짓말입니다.