닉네임 먼저 받을까, 꾸미기 먼저 보여줄까: 온보딩 순서의 고민

2026년 2월 7일

나만의 깃허브 리드미를 꾸미고 싶었습니다. 잔디 그래프를 그냥 두기엔 아쉬웠고, 뭔가 시각적으로 개성 있는 걸 붙이고 싶었습니다.

그렇게 깃스타일이 시작됐는데, 정작 첫 번째로 막힌 건 기술이 아니라 “사용자에게 무엇을 먼저 보여줄 것인가” 라는 순서 문제였습니다.

1. 문제 상황

깃스타일은 깃허브 잔디(contribution graph)를 꽃, 머리카락 같은 시각적 테마로 변환해서 리드미에 붙일 수 있는 이미지를 생성해주는 서비스다.

사용자가 완성까지 거쳐야 하는 단계는 크게 두 가지였다.

꾸미기 설정: 테마 선택(꽃 / 머리카락), 세부 옵션(꽃 종류·색상, 머리카락 색상)
깃허브 닉네임 입력: 잔디 데이터를 불러올 GitHub username

두 가지를 어떤 순서로 배치할지 결정해야 했다.

2. 내가 처음 한 생각

처음 떠오른 구조는 닉네임을 먼저 받는 것이었다.

이유는 단순했다.

“닉네임이 없으면 데이터도 없고, 미리보기도 없으니 꾸미기부터 해봤자 의미가 없지 않나?”
회원가입 플로우처럼 신원 확인 → 설정의 순서가 더 자연스러운 것 아닌가?

그래서 처음엔 이런 흐름을 떠올렸다.

[GitHub 닉네임 입력] → [테마 선택] → [세부꾸미기] → [결과 생성]

논리적으로는 말이 됐다. 그런데 뭔가 어색했다.

3. 실제로 해 본 선택

관점을 바꿔서 이렇게 질문해봤다.

“깃스타일에 오는 사람은 왜 오는 걸까?”

리드미를 꾸미는 걸 좋아하는 사람들이다. 깃허브 프로필 꾸미기, 뱃지 수집, 테마 커스터마이징에 관심 있는 사람들. 이 사람들에게 서비스의 첫인상은 “내가 어떻게 꾸밀 수 있는지” 여야 했다.

닉네임을 먼저 받는 구조는 사실 서비스 입장의 편의였다. 반면 꾸미기를 먼저 보여주면, 사용자는 도착하자마자 “어, 이런 게 되네?” 하는 경험을 먼저 한다.

그래서 순서를 바꿨다.

[테마 선택] → [세부 꾸미기] → [GitHub 닉네임 입력] → [결과 생성]

코드에서도 이 순서가 그대로 반영됐다. FlowerContent 컴포넌트를 보면, Customize 섹션이 GitHub Username 섹션보다 먼저 렌더링된다.

// components/features/theme/flower/FlowerContent
.tsx
return (
  <div className="space-y-10">
    <div>
      <SectionLabel>Customize</SectionLabel>
{/* 꾸미기 먼저 */}
      <FlowerSelector ... />
    </div>

    <div>
      <SectionLabel>GitHub
Username</SectionLabel>  {/* 닉네임 나중에 */}
      <UserNameInput ... />
    </div>
  </div>
);

닉네임 없이도 꾸미기 옵션을 자유롭게 선택할 수 있고, 마음에 드는 조합을 찾은 뒤에 닉네임을 입력하면 Generate가 활성화되는 구조다.

4. 결과

꾸미기 설정을 먼저 두는 구조가 더 자연스러웠다.

닉네임 입력창이 먼저 보이면 사용자는 “이게 뭔지 모르는데 일단 내 정보를 넣어야 하나?”라는 막막함을 먼저 느낄 수 있다. 반면 꾸미기 옵션이 먼저 보이면, 서비스가 무엇을 할 수 있는지를 직접 탐색하면서 자연스럽게 흥미를 갖고 마지막에 닉네임을 입력하게 된다.

서비스의 핵심 가치인 “꾸밀 수 있다” 를 첫 화면에서 바로 경험하게 되는 구조였다.

그리고 나의 이런 가설이 맞는지 확인하는 장치로, PostHog를 도입하여 사용자 행동을 추적하고 있다. 우선 나는 위와 같은 사고로 꾸미기 설정 이후 닉네임 입력이 서비스 사용 흐름에 더 도움이 된다고 판단했다. 그리고 이런 판단이 맞는지는 유저의 행동 데이터를 통해 옳고 그름을 판단할 수 있을 거라고 본다.