앱 안에서 업무 화면을 제공할 때는 로그인한 고객만 생각하기 쉽습니다.

업무 버튼을 누르면 WebView를 열고 바로 업무 화면을 보여주면 된다고 생각했습니다. 하지만 같은 주소가 외부 링크나 다른 화면을 통해 전달될 수 있다면 비로그인 상태의 진입도 함께 고려해야 했습니다.

로그인이 필요한 화면이라고 해서 비로그인 고객을 오류 화면이나 빈 화면에 머물게 할 수는 없었습니다.

URL을 나누는 방법부터 생각했습니다

처음에는 로그인 사용자용 주소와 비로그인 사용자용 주소를 따로 두는 방식을 생각할 수 있었습니다.

구현은 명확해 보이지만 링크를 만드는 쪽에서 사용자의 로그인 상태를 알아야 합니다. 로그인 상태가 바뀌면 어느 주소로 돌아가야 하는지도 별도로 관리해야 합니다.

같은 업무를 설명하는 페이지와 실제 업무 페이지가 서로 다른 진입 경로를 가지면 공유 링크와 앱 화면 이동 규칙도 복잡해질 수 있습니다.

중요한 것은 Endpoint를 나누는 것이 아니라 하나의 진입 경로 안에서 사용자의 상태에 맞는 다음 화면을 자연스럽게 결정하는 일이었습니다.

같은 URL에서 첫 화면을 결정했습니다

이번 프로젝트에서는 업무별 진입 URL을 하나로 유지하는 방향을 검토했습니다.

로그인한 사용자는 별도의 안내를 반복해서 보지 않고 바로 업무 화면으로 이동합니다. 이미 서비스 이용 의도가 분명한 고객에게 불필요한 단계를 추가하지 않기 위해서입니다.

비로그인 사용자는 업무의 목적과 이용 조건을 설명하는 화면을 먼저 봅니다. 여기에서 로그인을 선택하면 앱의 로그인 기능을 호출하고, 성공한 뒤 원래 진입했던 업무로 돌아옵니다.

설명 화면은 단순히 로그인 버튼을 보여주는 곳이 아닙니다. 사용자가 어떤 업무에 들어가려 했는지 이해하고, 로그인 이후 무엇을 할 수 있는지 알려주는 진입 화면에 가깝습니다.

로그인 후 복귀 정보가 필요했습니다

로그인 호출 자체보다 더 고민이 필요했던 부분은 로그인 이후였습니다.

로그인이 끝난 뒤 WebView를 새로 열지, 기존 화면을 갱신할지, 사용자가 처음 요청했던 업무와 파라미터를 어떻게 이어갈지 기준이 필요했습니다.

복귀 정보는 클라이언트 화면 상태에만 의존하지 않도록 범위를 제한하고, 허용된 업무 경로인지 확인해야 합니다. 로그인 과정이 길어지거나 사용자가 취소했을 때의 동작도 함께 정해야 했습니다.

이번 구조에서는 로그인 성공, 취소, 실패를 구분하고 성공한 경우에만 원래 업무 진입을 다시 판단하도록 했습니다. 로그인 전 화면이 업무 처리 상태를 임의로 이어가지 않도록 하는 것이 중요했습니다.

인증과 고객 경험은 같은 흐름이었습니다

로그인 여부를 확인하는 일은 보안 처리처럼 보이지만 고객이 경험하는 화면 흐름과도 맞닿아 있었습니다.

인증이 필요하다는 이유로 사용자의 목적을 끊어버리면 다시 메뉴를 찾아야 합니다. 반대로 편리한 복귀만 생각해 검증되지 않은 경로를 그대로 이어주면 안전한 흐름이라고 보기 어렵습니다.

하나의 URL을 유지한 이유는 구조를 단순하게 만들기 위해서만은 아니었습니다.

고객이 어떤 상태로 들어오더라도 자신이 하려던 일을 이해하고, 필요한 인증을 거쳐 자연스럽게 이어갈 수 있게 하는 것. 로그인 분기는 인증과 사용자 경험을 하나의 흐름으로 보는 데서 시작했습니다.