온보딩 화면을 단계별로 재설계해 첫 진입 경험 개선

온보딩 화면을 다시 정리했다. 처음 사용자가 앱을 열었을 때 겪게 되는 첫 몇 초의 경험을 좀 더 단계적이고 의도 있게 만들려는 작업이었다.

왜 온보딩부터 손을 대었나

팀 내 논의에서 나온 결론은 단순했다. 아무리 좋은 서비스도 초기 유입이 산으로 이어지면 다음 단계로 못 간다는 거였다. 특히 우리 서비스처럼 사용자가 먼저 "나는 뭘 원하는가"를 정의해야 하는 형태라면, 그 선택의 순간을 얼마나 명확하고 유도적으로 제시하느냐가 중요했다. 스플래시, 카테고리 선택, 난이도 표시—이 세 가지는 사용자를 태우고 가는 순서라고 봤다.

스플래시 · 타입 선택 · 난이도 UI

스플래시는 순수히 시간 버는 화면이 아니었다. 우리가 필요했던 건:

• 초기 로드 중에 필수 데이터를 미리 fetch할 수 있는 시간 (사용자 저장 선호도, 캐싱)
• 인지적 진입점 (앱이 반응하고 있다는 피드백)
• 이 앱이 뭔지에 대한 30초짜리 브리핑

그다음 타입/카테고리 선택이 이어진다. 여기서 우리가 놓쳤던 부분이 있었는데, 사용자가 처음부터 "모든 것"을 보고 싶어 하지는 않다는 거였다. 오히려 범주를 먼저 정하게 하면:

• 필터링된 초기 경험으로 시각적 과부하 감소
• 사용자의 명시적 의도 포착 (어떤 사람이 어떤 걸 원하는지)
• 다음 화면에서 추천/정렬 로직을 개인화할 수 있는 신호 확보

난이도 UI는 src/app/globals.css에 ★ 별점 기호로 구현했다. 이건 단순해 보이지만 중요한 신호다. 처음 온 사용자가 "이건 쉬운 걸까, 어려운 걸까?"를 한눈에 파악할 수 있어야 한다.

파일 구조와 책임 분리

page.tsx와 layout.tsx를 나눈 이유도 생각해볼 만하다. 초기 온보딩은 단선적 흐름(splash → 선택 → 결과)이지만, 그 후로는 사용자가 언제든 돌아오고 재선택할 수 있어야 하기 때문이다. 레이아웃에서 공통 헤더/풋터/네비를 고정하고, page에서만 현재 상태를 관리하는 식으로.

팀 의사결정: 왜 이 순서인가

신입이 이 작업을 맡았을 때 첫 질문이 "왜 스플래시가 필요해요?"였다. 정당한 질문이었다. 그래서 팀에서 몇 가지를 정했다:

• 스플래시 없이 바로 선택지를 보여주면, 초기 렌더링 중 "로딩이 겹친다" (사용자 입장에서 답답함)
• 선택지 없이 바로 그리드를 보여주면, 새 사용자가 "나는 뭘 골라야 하지?"에서 머뭇거린다
• 난이도 없이는 선택의 기준이 불명확하다

즉, 각 요소가 사용자 인지 부담을 단계적으로 낮추는 스텝이었다.

회고: 다음에 생각해볼 것

이 작업을 마치고 느낀 점 몇 가지:

1. 선택지 개수 균형 — 카테고리가 너무 많으면 선택 자체가 부하다. 초기 온보딩은 3~5개 정도가 적당한 이유를 알았다.

2. 상태 관리의 경계 — 스플래시에서 뭘 미리 fetch할지, 언제 캐시할지가 명확하지 않으면 나중에 "왜 안 됐지?"가 쌓인다. 처음부터 책임을 정하는 게 중요했다.

3. 테스트 관점 — 온보딩은 "전체 사용자의 첫 터치"라서, 한 곳의 버그도 크다. 모바일·데스크톱, 느린 네트워크, 캐시 미스 등 여러 시나리오를 처음부터 체크리스트로 만들어 두길 잘했다.

온보딩이 얼마나 좋은지는 며칠 뒤 분석 대시보드에서 "다음 화면 진입률"로 본다. 지금은 이 변경이 그 수치를 올릴 거라는 기대와 약간의 불안 사이를 오간다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.