배포가 끝났고 서버도 응답하고 있었어요. 그런데 사용자가 입력하는 사이트 주소에서는 브라우저 경고가 나왔어요. 만드는 쪽에서 확인한 성공과 사용자가 마주한 결과가 달랐어요. 서비스가 실행되고 있다는 사실만으로 사용자가 정상적으로 들어올 수 있다고 말할 수 없었어요.
뒤이어 관제 화면에서도 비슷한 간극이 드러났어요. 화면은 열리는데 전체 목록 대신 일부 문제 상태만 보였어요. 데이터를 읽는 일은 계속되고 있었지만 읽은 결과를 화면에 전달하는 단계가 멈춰 있었어요. 두 사건은 같은 장애가 아니었지만, 확인 기준을 어디에 두어야 하는지는 함께 보여 줬어요.
사용자가 이용하는 주소에서 확인했어요
첫 접속 문제에서는 앱이 실행되는 주소와 공식 사이트 주소를 구분했어요. 다른 주소에서 정상 응답을 받았다고 사용자가 입력하는 주소도 안전하게 열린다는 보장은 없었어요. 공식 주소의 연결 상태를 직접 확인하니 그 주소를 위한 접속 준비가 빠져 있었어요.
앱 화면을 다시 만드는 대신 공식 주소로 들어오는 연결을 바로잡았어요. 그다음에는 배포 뒤 확인도 사용자가 실제 이용하는 주소에서 하도록 기준을 맞췄어요. 작업 결과를 서버 안에서만 보고 끝내지 않고 바깥 입구까지 이어서 확인하는 방식으로 바뀌었어요.
이 단계에서는 공개 첫 화면과 로그인 화면, 로그인하지 않은 접근이 차단되는 상태까지 확인했어요. 열린다고 해서 보호된 화면까지 모두 공개되어도 된다는 뜻은 아니었어요. 들어갈 수 있어야 하는 입구와 인증이 필요한 화면의 경계를 함께 지켰어요.
첫 사건에서는 공식 입구가 사용 가능하다는 증거가 필요했고, 다음 사건에서는 그 입구를 통해 자료가 실제로 전달됐다는 증거가 필요했어요. 같은 접속 문제라는 이름으로 둘을 묶으면 브라우저가 열리는 확인만으로 자료 공급까지 정상이라고 판단할 수 있어요.
점검의 성공 표시도 대상과 함께 읽어야 했어요. 자동 확인이 정상이어도 실제 사용하는 경로가 다른 대상을 보고 있다면 사용자는 실패를 겪어요. 실행이 성공했다는 사실과 무엇을 확인한 실행인지가 같이 있어야 현재 상태를 설명할 수 있었어요.
이 차이는 화면 안내를 읽는 데도 중요했어요. 일부 상태만 표시한다는 안내는 제한된 결과를 알려 줄 수 있지만 어디서 전달이 끊겼는지까지 확정하지는 못해요. 안내를 원인 설명으로 받아들이기 전에 자료가 지나간 각 단계를 대조했어요.
목록이 줄어든 이유도 화면 밖에서 찾았어요
이후 전체 목록이 사라진 사건은 원본 데이터가 없어졌다는 증거부터 찾는 방식으로 시작하지 않았어요. 원본을 읽었는지, 읽은 상태가 저장됐는지, 그 결과를 화면 쪽으로 보냈는지를 나눠 확인했어요. 문제는 마지막 전달에서 나타났어요.
이 전달은 이미 공식 사용 기준에서 벗어난 옛 주소를 이용하고 있었어요. 그 주소의 연결 유효성이 끝나면서 최신 전체 목록이 화면까지 도달하지 않았어요. 자동 점검이 성공했다는 기록도 있었지만, 그 점검은 실제로 문제가 난 주소를 대상으로 한 것이 아니었어요. 성공 표시가 다른 대상을 설명하고 있었던 거예요.
유효한 공식 주소로 전달 경로를 맞춘 뒤 전체 목록을 다시 발행했어요. 전달 성공 응답과 전체 상태가 들어간 결과를 확인했어요. 이로써 일부 문제 목록에만 의존하던 상태를 벗어날 근거가 생겼어요.
그렇다고 다른 데이터 유입 문제까지 함께 해결됐다고 묶지는 않았어요. 전체 목록 전달이 복구된 것과 원본 이미지가 지속적으로 잘 들어오는지는 별개의 확인이었어요. 화면이 풍부해졌다는 이유로 원천의 누락 상태를 정상으로 바꾸면 안 됐어요.
이 두 사건 뒤에는 확인 질문이 달라졌어요. 서버가 켜져 있느냐보다 사용자가 쓰는 입구가 열리느냐, 데이터가 있느냐보다 그 데이터가 사용자가 보는 화면까지 도달하느냐를 물어야 했어요. 시스템 안의 성공이 사용자 경험으로 이어지는 마지막 구간을 놓치지 않는 일이었어요.
