Personal Page Builder

문제 배경
랜딩 페이지에서 CTA의 목적지를 결정하기 위해 세션 조회를 함께 수행하면, 로그인 여부와 관계없이 모든 사용자에게 불필요한 인증 요청이 발생했다. 이로 인해 랜딩 페이지를 정적으로 최적화하기 어렵고, 초기 렌더링 성능 측면에서도 비효율이 있었다.

접근 방식
랜딩 페이지는 마케팅 메시지와 CTA만 제공하는 정적 화면으로 유지하고, 사용자 상태 판별 책임은 별도의 Route Handler 엔드포인트로 분리했다. 사용자가 CTA를 클릭하면 서버 진입점에서 세션 존재 여부를 확인한 뒤 목적지를 결정하도록 흐름을 설계했다.
또한 랜딩에서 발생하던 불필요한 인증 관련 선행 요청을 줄이기 위해 Next.js 기본 prefetch를 비활성화하고, 실제 진입 가능성이 높아지는 hover 시점에만 수동 prefetch가 일어나도록 조정했다. (포스팅)

성과
사용자 상태 분기를 일관된 서버 진입점에서 처리하면서도 랜딩 페이지는 정적 렌더링의 이점을 유지할 수 있었다. 그 결과 배포 환경 기준 FCP를 모바일 7.3%, 데스크톱 3.6% 개선했다.

문제 배경
하나의 계정에 여러 로그인 수단이 연결될 수 있는 구조에서, 기존 로그인 화면은 이메일 입력 직후 비밀번호 입력으로 이어지는 고정된 흐름을 사용하고 있었다. 이 때문에 소셜 로그인 전용 사용자는 자신의 로그인 수단을 잊었을 경우 반복적으로 로그인에 실패함을 개발 과정에서 발견했다. 이는 배포 환경에서 사용자 이탈로 이어질 수 있는 치명적인 문제라고 판단했다.

접근 방식
로그인 화면을 고정된 단계형 폼으로 두지 않고, 로그인 수단을 판별하는 Route Handler 엔드포인트를 설계했다.
사용자가 이메일을 입력하면 해당 계정에 연결된 로그인 방식을 먼저 확인하고, 소셜 계정인 경우 비밀번호 입력 단계로 보내지 않고 적절한 로그인 방식으로 바로 연결되도록 구성했다.
여러 로그인 방법이 연결된 경우에는 우선순위 기준을 정의해 일관되게 처리했고, 자동 진행이 어려운 경우에도 사용자를 다른 단계로 강제로 이동시키기보다 현재 화면에서 오류 원인을 바로 이해할 수 있도록 설계했다. (포스팅)

성과
사용자가 계정의 로그인 수단을 잊었더라도 올바른 로그인 흐름으로 자연스럽게 진입할 수 있도록 개선했다.