나는 Device Life의 전체 사용자 흐름을 설계하기 위해 React Router 기반의 라우팅 시스템을 가장 먼저 구현하였다. 서비스의 전체 페이지 경로를 정의하고 사용자의 인증 상태에 따라 접근 가능한 페이지를 제어하는 라우팅 기능이다.
처음에 라우팅을 잡을 때 우리팀의 유저구분 때문에 아주 고민이 많이 되었다. 우리 서비스는 PM님께서 온보딩을 꼭 모든 유저가 경험하고 넘어가길 원하셨던 만큼 온보딩 유무 API가 따로 존재하였고, 라우팅 설정을 할 때 로그인 유무뿐만이 아니라 이 온보딩 유무까지 고려해서 라우트 구조를 잡아야했다.
우선 가장 큰 구분은 당연히도 인증 유무였기에 라우트를 Public과 Private으로 분리를 하고 Private에 AuthGuard를 통해 가드를 두었다. 그 다음은 온보딩 완료 유무에 따라 페이지를 나누어야 했는데 온보딩의 경우 회원가입 이후 일어나기 때문에 로그인이 된 유저라고 볼 수 있다. 따라서 Private 라우트 안에서 온보딩 유무에 따라 다시 가드를 통해 나누었던 것 같다.
또한 우리팀은 특이?하게 팀원 중 한분께서 경로를 상수화하자는 의견을 주셔서 처음에는 굳이 그렇게 해야 하나 싶었지만 개발이 진행되면서 이렇게 상수로 만들어놓으니 덕분에 명확하고 오타없이 편리하게 사용했던 것 같다.
온보딩 마지막 페이지인 ‘온보딩 완료 페이지’를 어느 가드에 둘지가 애매했다… 처음에는 당연하게도 온보딩이 완료된 페이지이기에 OnboardingCompleteGuard 아래에 두었다가 온보딩이 미완료인 상태로 진입하기에 가드에 의해 온보딩 시작으로 튕겼다. 그렇다고 온보딩이 아직 미완료된 OnboardingOnlyGuard에 두자니 온보딩이 완료되는 페이지가 들어가기에 적합하지 않았다.
우선 온보딩 완료 페이지 자체가 어떤 식으로 온보딩 완료를 처리하는 지를 먼저 살폈다. 이 페이지에 들어가게 되면 api호출을 통해 온보딩 완료를 확정하게 된다. 그러나 그 전에 상위에 걸린 가드가 먼저 판단을 내리게 된다. 결과적으로 이 페이지는 온보딩 미완료에서 완료가 되는 전환 페이지의 역할을 해야 하는데 그 전에 가드가 존재하면 선제적으로 리다이렉트를 하기에 흐름이 꼬이게 되는 것이었다.
중요한 것은 이 페이지가 온보딩 완료와 미완료가 둘 다 존재할 수 있는 전환페이지였기에 어떠한 가드에 두는것도 적합하지 않다는 것이었다. 대신 앞에서 로그인 여부를 따진다면 비로그인 유저는 접근가능하면 안되기에 AuthGuard 아래에 단독 라우트로 배치를 하였다. 그러나 이렇게 되면 로그인과 온보딩을 모두 진행한 유저가 억지로 접근할 수 있고 필요없는 온보딩 완료 api를 한번 더 호출할 수 있기에 라우트가 아닌 페이지 레벨에서 이미 온보딩이 완료된 유저는 기기추천 페이지로 리다이렉트하게 처리를 하였다.
이번에 이 애매한 상태의 전환페이지를 처리하면서 가드는 “권한/정책을 강제”하는 데 강하지만, 상태가 막 전환되는 구간(transition) 에서는 오히려 흐름을 깨기 쉽다는 것을 알게 되었다. 다음에 만약 이런 페이지를 처리할 일이 또 생긴다면 그때는 확실하게 가드 블록 밖으로 빼서 전환을 마무리할 안전지대를 만들어서 빠르게 처리할 수 있지 않을까 싶다..!
이번엔 로그인 + 온보딩까지 한 유저의 처리를 페이지 단위에서 하였는데 이렇게 정책이 두 군데에 흩어져있는거보단 미리 접근 정책은 라우팅에서, “중복 호출 방지/예외 처리”는 페이지에서 맡게 역할을 분리하도록 약속을 하고 진행을 해서 통일성 있게 진행하면 더 좋지 않았을까 하는 아쉬움이 남는다.