Clerk 인증과 프로젝트 라우트 뼈대를 먼저 세운 이유

이번 주 2일 차, UI 뼈대를 올리는 작업을 했다. Clerk 인증 페이지 두 개 붙이고, 프로젝트 관련 라우트 구조를 잡아두는 것까지.

왜 이 순서였나

처음 빌더 계열 웹 앱을 설계할 때 항상 고민이 되는 게 "인증 먼저냐, 핵심 도메인 UI 먼저냐"다. 나는 보통 인증을 먼저 붙이는 쪽을 택한다. 이유는 단순한데, 이후에 붙이는 모든 페이지가 인증 컨텍스트를 전제로 짜여야 하기 때문이다. 나중에 끼워 맞추면 라우팅 가드, 리다이렉트 로직, 세션 상태에 따른 분기가 전부 후처리 패치가 돼버린다.

그래서 Week 2 Day 2 시점에 builder UI skeleton과 Clerk sign-in/up 페이지를 같이 올린 거다. 뼈대와 인증을 동시에 세팅해서 이후 작업이 "이미 인증이 깔린 환경 위에서" 진행되도록.

변경된 파일들의 역할

Clerk의 [[...sign-in]] 패턴은 catch-all 슬러그로, Clerk이 내부적으로 OTP, OAuth 콜백, MFA 같은 여러 인증 스텝을 단일 경로 아래서 처리할 수 있게 해준다. 직접 폼을 짜는 게 아니라 이 구조를 잡아두는 것만으로 인증 플로우 전체가 따라온다는 게 Clerk의 편의 포인트다.

// sign-in/[[...sign-in]]/page.tsx 기본 구조
import { SignIn } from "@clerk/nextjs";

export default function SignInPage() {
  return (
    <main>
      <SignIn />
    </main>
  );
}

짧지만 이 한 장이 OAuth, 이메일 로그인, 에러 처리까지 다 커버한다. 직접 짜면 최소 수백 줄 나올 로직이 이 파일 하나로 정리된다.

프로젝트 라우트 구조를 이 시점에 잡는 이유

projects/page.tsx, projects/[projectId]/page.tsx, new-project-button.tsx 세 파일은 아직 실제 데이터 페칭이나 비즈니스 로직이 없는 skeleton 상태다. 그럼에도 이 시점에 파일과 라우트를 만들어두는 이유가 있다.

• 팀원이 생기거나 병렬 작업을 할 때 "어느 파일에 뭘 짜면 되는지" 좌표가 생김
• 마케팅 랜딩((marketing)/page.tsx)과 앱 내부 라우트(projects/)의 레이아웃 분리를 Next.js route group으로 명시해두는 것 자체가 의도를 드러내는 행위
• 나중에 미들웨어에서 인증 보호 경로를 정의할 때 경로 패턴이 이미 확정돼 있어야 오작동이 없음

skeleton이라도 파일이 존재하는 것과 없는 것은 다르다. 이후에 feature를 붙일 때 "빈 파일에 살을 붙이는 작업"이 "새 파일을 만들고 라우팅을 고려하는 작업"보다 훨씬 가볍다.

회고

솔직히 Day 2 작업치고는 퍼즐 조각들을 놓는 것에 가까워서 완성된 게 눈에 잘 안 보인다. 그런데 팀 리딩 관점에서 보면 이런 "보이지 않는 세팅" 작업이 나중에 병목을 만드냐 아니냐를 가른다. 인증이 없는 상태에서 UI 컴포넌트를 먼저 올리면 반드시 "로그인 붙이면서 리팩터" 타임이 생긴다. 지금 이틀 치 작업에서 그 부채를 미리 태운 셈이다.

마케팅 페이지와 앱 내부를 route group으로 분리한 것도 나중에 레이아웃이나 메타데이터 전략이 달라질 때 건드릴 범위를 최소화하려는 의도였다. 아직 skeleton이지만, 방향은 잡혔다.

다음은 실제 프로젝트 생성 로직과 builder 캔버스 영역을 붙이는 작업으로 이어질 것 같다.

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

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

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