체험판 신청 퍼널 개선기

제품마다 따로 흩어져 있던 체험판 신청 흐름을 하나로 통합하는 작업을 맡았다. 처음엔 "신청 → 인증 → 가입 → 시작"이라는 직선 흐름이라 단순해 보였지만, 막상 들여다보니 사용자의 상태에 따라 경로가 여러 갈래로 갈라졌다. 이 글은 그 경우의 수를 어떻게 다뤘는지에 대한 기록이다.

배경

기존 체험판의 문제점

기존에는 체험판 신청이 제품별로 별도로 존재했다. 그러다 보니 같은 회사 제품인데도 신청 화면과 절차가 제각각이어서 일관된 사용자 경험을 주지 못했고, 흐름이 통일되어 있지 않으니 유저가 어느 단계에서 이탈하는지 추적하기도 어려웠다. 게다가 단계가 많아 중간에 포기하는 사용자도 적지 않았다.

이번 개선으로 만들고자 한 가치

목표는 세 가지였다. 통일된 UI로 어떤 제품에서 들어와도 동일한 경험을 제공하고, 체험판 진행 정도를 관리자 페이지에 기록해 사용자 행동을 추적 가능하게 만들며, 전체 흐름 자체를 단순화하는 것이다.

마주한 문제

진입 경로마다 달라지는 흐름

가장 먼저 부딪힌 건 "하나의 흐름"이 아니라는 사실이었다. 사용자가 어떤 상태로 들어오느냐에 따라 거쳐야 할 단계가 달라졌다.

• 신청 폼 → 이메일 인증 → 회원가입 → 시작
• 신청 폼 → 로그인 → 시작
• 신청 폼 → 시작

계정 상태에 따른 분기

여기에 더해, 신청에 사용한 계정과 실제 사용할 계정의 관계, 로그인 여부 등이 얽히면서 분기가 곱셈으로 불어났다.

• 신청 계정 ≠ 사용 계정 → 로그아웃 후 다시 진행 필요
• 현재 로그인된 계정으로 신청 → 추가 절차 없이 바로 시작
• 비로그인 상태 + 이미 가입된 계정 → 로그인 필요
• 비회원의 신청 → 회원가입 필요

이렇게 진입 경로와 계정 상태가 조합되면서, 단순한 직선이 아니라 여러 시작점과 분기를 가진 그래프가 되어버렸다. 이른바 경로 폭발이다. 이 폭발을 어떻게 다룰지가 이번 설계의 핵심 과제였다.

핵심 설계 결정

결정 1 : 컴포넌트 전환 대신 페이지 분리

처음에는 하나의 페이지 안에서 컴포넌트만 갈아 끼우는 방식을 고려했다. 이 방식은 비즈니스 로직과 단계 이동을 한곳에서 관리하기 편하고, 상태가 유지되므로 앞 단계에서 입력한 정보를 뒤 단계에서 그대로 활용할 수 있다는 장점이 있다.

그럼에도 페이지로 분리하기로 한 데에는 이유가 있었다.

• 이메일 인증 과정에서 페이지 이탈이 발생한다. 인증 메일의 링크를 누르면 새로운 경로로 진입하게 되는데, 같은 페이지 상태를 그대로 유지한 채 이어가기는 어렵다. 인증 후 돌아오는 지점이 특정 URL(딥링크)이어야 하고, 그 URL 자체가 "지금 어느 단계인지"를 의미해야 했다.
• 회원가입과 로그인은 다른 도메인에서 이루어진다. 도메인을 넘나드는 순간 클라이언트 상태를 유지하기가 까다로워진다.

어차피 물리적인 페이지 이동이 발생하고, 각 단계가 명확히 구분된 URL을 갖는 편이 자연스러웠다. 그래서 URL을 단계의 단일 진실 공급원으로 삼고, 각 단계를 독립된 페이지(라우트)로 분리했다.

결정 2 : 검증 페이지 중심의 중앙 집중형 라우팅

페이지로 분리하자 이번엔 예외 처리가 쏟아졌다. 각 경우로 각 페이지에 직접 진입했을 때 어떻게 처리할지, 사용자 상태에 따라 단계가 줄거나 늘어나는 상황에 어떻게 유동적으로 대응할지를 페이지마다 핸들러에서 판단하려니 로직이 급격히 복잡해졌다. 페이지가 서로의 다음 행선지를 알아야 하는 구조가 되면서 분기가 사방으로 흩어진 것이다.

그래서 방향을 뒤집었다. 각 페이지는 자기 역할만 충실히 수행하고, 끝나면 무조건 검증 페이지로 보낸다. 검증 페이지는 사용자의 현재 상태를 판단해 적절한 단계로 리다이렉트한다. 모든 길이 한 점으로 모이는 구조다.

덕분에 하나의 로직만 보면 전체 플로우를 파악하고 관리할 수 있게 되었다. 중간에 새 단계가 추가되더라도, 그 단계를 만들고 완료 시 검증 페이지로 보내도록 한 뒤, 검증 페이지에서 "그 단계를 마치고 왔을 때 어디로 보낼지"만 정의하면 된다. 최소한의 수정으로 단계 추가가 가능해졌다.

결정 3 : 에러 처리도 중앙으로

다양한 상황을 다루다 보니 에러도 다양하게 발생했다. 허용되지 않은 국가에서의 신청, 유효하지 않은 접근, 이미 신청한 체험판, 그리고 알 수 없는 에러까지.

처음에는 각 에러를 감지해 저마다 다른 페이지로 보내는 방식으로 구현했다. 하지만 앞서 라우팅을 중앙화한 경험에서 착안해 같은 철학을 에러에도 적용했다. 모든 상황에서 에러를 던지고, 프레임워크(Next.js)가 제공하는 에러 처리 경계를 활용해 에러 코드를 기준으로 적절한 뷰를 렌더링하도록 한 것이다. 라우팅을 한곳에 모았듯, 에러 분기도 코드 기반으로 한곳에 수렴시켰다.

한계

설계가 깔끔해진 만큼 트레이드오프도 분명했다. 잘된 점만큼 남은 숙제도 기록해 둔다.

무상태 검증으로 인한 중복 요청

페이지 이동을 독립적으로 바라보다 보니, 검증 페이지는 무상태 RESTful API처럼 진입할 때마다 처음부터 모든 것을 다시 검증한다. 로그인 여부, 신청한 사람과 동일한 계정인지, 유효한 국가인지 등을 단계를 지날 때마다 반복 요청하게 되어 중복이 발생한다. 단순하고 멱등하다는 장점의 이면이다.

검증 페이지의 책임 비대화

중앙화의 장점은 동시에 위험이기도 하다. 단계가 늘어날수록 모든 분기 조건이 검증 페이지 한 곳에 쌓이면서, 자칫 모든 것을 떠안는 거대 단일 책임으로 비대해질 수 있다.

회고

혼자 해내며 얻은 설계에 대한 자신감

기능 구현을 넘어 전체 구조를 밑바닥부터 혼자 설계하고 만들어 나가는 과정이 즐거웠다. 업무량은 버거웠지만, 복잡하던 유저 플로우가 유기적으로 연결되는 모습을 보며 설계에 대한 자신감을 얻었다.

기능 출시와 함께 유저 행동을 추적할 관리자 페이지까지 만든 것도 뜻깊었다. 우리가 만든 기능이 어떤 가치를 만드는지 데이터로 증명할 수 있게 되었다.

완벽주의와 현실 사이의 고민

제한된 일정 탓에 품질과 타협 사이에서 고민이 많았다. 예외 케이스를 꼼꼼히 따지는 편인데, 비즈니스 우선순위에 밀려 다수인 비회원 플로우만 최적화하고 기존 회원 플로우는 개선 여지를 남긴 채 출시해야 했던 점이 아쉽다.

AI 시대, 개발자에게 진짜 중요한 역량

가장 잘했다고 생각하는 건 코드를 치기 전에 전체 흐름 설계에 시간을 충분히 쓴 것이다. 무작정 구현부터 시작했다면 수많은 분기에 갇혀 길을 잃었을 것이다. 효율적인 구조를 빠르게 떠올리지 못해 기술 블로그와 디자인 패턴 자료를 뒤지며 고생한 만큼, 평소에 패턴과 아키텍처를 익혀 두는 일이 얼마나 중요한지도 느꼈다.

AI로 세부 구현의 생산성은 이미 크게 올랐다. 그렇다면 차별점은 코드를 빨리 치는 능력이 아니라 맥락을 읽고 구조를 잡는 설계 능력에 있다고 본다. 이번 작업은 그 방향을 분명히 해 준 터닝포인트였다.