🔥딱 8일간! 인프런x토스x허먼밀러 역대급 혜택

지금 바로 쿠폰 받기👉

[인프런 워밍업 클럽 3기] 풀스택 스터디 1주차 미션 회고 발자국

[인프런 워밍업 클럽 3기] 풀스택 스터디 1주차 미션 회고 발자국

LC-02s 5개월 전

학습 내용 요약

인프런 워밍업 클럽 3기 풀스택 스터디 1주차에는 해당 강의에서 사용될 라이브러리 및 프레임워크에 대한 소개와 사용법 위주로 다루었습니다. 인프런에서 발자국을 작성할 때 강의를 보지 않고도 강의 내용을 파악할 수 있을 만큼 자세한 내용을 작성하는 건 지양해 달라고 가이드한 만큼 강의에 대한 필기는 최소화 하고 회고 위주로 적어보겠습니다. 강의의 목적인 Next.js와 Supabase를 사용해서 서비스를 만들어보는 것에 집중하여 스타일링이나 기타 상태관리 라이브러리에 대한 내용은 작성하지 않았습니다.

 

Next.js 간단 정리

  1. Next.js란?

    1. 개인이 풀스택 개발을 하기에 최적화 된 웹 프레임워크

    2. 서버사이드 렌더링이 큰 특징이며, React와 비슷한 문법으로 더 현대적인 웹 서비스를 구현할 수 있음

    3. 서버에서부터 HTML을 최적화해서 웹으로 내려주기 때문에 SEO에 도움이 됨

    4. 자체적으로 API 구축이 가능하기 때문에 사이즈가 크지않은 개인 프로젝트 정도의 규모라면 별도로 서버구축을 할 필요 없이 Next.js만으로 서버 구축까지 전부 가능함

  2. Server Actions

    1. 서버에서 실행되는 비동기 함수 생성 기능

    2. "use server" 지시어를 파일 최상단에 선언하면 해당 파일 내 모든 함수가 Server Action으로 간주됨

    3. 서버 및 클라이언트 컴포넌트에서 호출 가능

    4. 주로 폼 제출 및 데이터 변경(뮤테이션)에 사용

    5. 내부적으로 POST 요청을 사용하며, 인자 및 반환값은 React에서 직렬화 가능해야 함

 

Supabase 간단 정리

  1. Supabase 란?

    1. PostgreSQL 기반의 오픈소스 백엔드 서비스로, 개발자들이 손쉽게 데이터베이스, 인증, 스토리지, 서버리스 함수 등을 활용할 수 있도록 지원하는 플랫폼

    2. 상용 서비스인 Firebase의 대안으로 자주 언급됨

  2. Supabase 장점

    1. 오픈소스 프로젝트 (자체 서버 구축 가능)

    2. PostgreSQL 기반 (관계형 DB 장점을 살릴 수 있다)

    3. Firebase 대비 저렴

    4. 다양한 연동 방식 지원 (+ GraphQL, API, SDK, DB Connection)

  3. Supabase 단점

    1. 아직 성숙하지 않은 커뮤니티 기반

    2. 비교적 적은 기능들, 적은 서비스 연동 지원

    3. 부족한 문서화, 한글 문서 부족

    4. Firebase보다 높은 러닝커브

 

 

Todo List 미션 회고

풀스택 스터디 1주차 미션은 강의에서 진행하는 Next.js와 Supabase를 활용한 Todo List 앱에 기능을 더 추가해보는 것이었습니다. 진행했던 미션은 해당 링크에서 보실 수 있습니다.

 

미션 수행 내용

아래는 제가 수행한 미션에 대한 내용과 함께 고민했던 점과 아쉬웠던 점을 정리해보았습니다.

 

기능 명세

  • 할 일 목록 조회 기능

    • 키워드 검색 기능

  • 할 일 수정 기능

    • 내용 변경 기능

    • 완료 여부 변경 기능

  • 할 일 삭제 기능


정리해보면 위의 기능을 Next.js와 Supabase를 활용하여 구현하는 것이었습니다. 강의에서는 Material Tailwind 라이브러리를 사용했지만 저는 기존에 즐겨썼었던 TailWindCSS와 최근 관심가지게된 Mantine 라이브러리를 사용하여 UI를 구축하였고, 4주차 모두 동일한 환경으로 진행되는 것 같아 Turbo Repo와 pnpm workspace를 활용한 모노레포 환경을 구축해두고 프리셋을 관리하였습니다. 상세한 내용은 아래에 정리해두었습니다.

 

사용 기술

  • 프레임워크: Next.js v15, React v19

  • 데이터베이스: Supabase

  • 서버 상태관리: Tanstack Query v5

  • 클라이언트 상태관리: Zustand v5

  • 스타일 프레임워크: TailWindCSS v3, Mantine v7

  • 모노레포: Turbo Repo

  • 패키지 매니저: pnpm

 

강의에서는 TypeScript를 사용했지만 별도의 인터페이스를 작성하지는 않았는데, 저의 최근 관심사가 환경(라이브러리) 변화에 유연한 도메인 로직 작성하기여서 저는 아래와 같이 별도로 인터페이스를 작성 후 서버 액션을 사용하는 로직을 인터페이스에 맞추어 작성해 보았습니다.

 

export interface Todo {
  id: number
  title: string
  createdAt: string
  updatedAt: string
  completed: boolean
  completedAt: string | null
}
export interface GetTodoListParams {
  query?: string
}

export interface GetTodoList {
  (params: GetTodoListParams): Promise<Todo[]>
}
export type CreateTodoParams = Pick<Todo, 'title'>

export interface CreateTodo {
  (params: CreateTodoParams): Promise<void>
}
export type UpdateTodoParams = Pick<Todo, 'id' | 'title' | 'completed'>

export interface UpdateTodo {
  (params: UpdateTodoParams): Promise<void>
}
export type DeleteTodoParams = Pick<Todo, 'id'>

export interface DeleteTodo {
  (params: DeleteTodoParams): Promise<void>
}

 

기존에는 서버 액션에 대한 이해가 부족했어서 항상 Next.js를 사용하며 Route Handler로 별도의 API를 만들어서 작업했었는데 별도의 API 엔드포인트를 관리하지 않고 서버 액션으로 모두 구축해볼 수 있었습니다. 이번에는 강의에서 진행한 것과 같이 GET 요청에도 서버 액션을 사용했었는데 개인적으로 관련 내용에 대한 고민을 조금 했었습니다.

 

Next.js의 공식 문서에서는 일반적으로 서버 액션을 데이터 변경(뮤테이션) 로직에만 사용하는 것으로 소개되었기도 했고, 기본적으로 POST 메서드를 사용한다고 했었는데, 이렇게 GET, PUT, DELETE 메서드를 사용해야하는 로직도 모두 POST로 통합해도 되는가라는 의문이 하나 있었고, GET 요청에도 서버 액션을 사용하니 생긴 문제인데 Next.js에서의 캐싱 전략을 어떻게 사용할 수 있을까에 대한 의문이 있었습니다.

 

강사님께서 제시하는 생산성 높은 풀스택 개발 방법론은 Supabase로 백엔드 필요 기능을 쉽고 빠르게 구축하고 Next.js의 서버 액션을 활용하여 별도의 API를 관리하는 절차를 건너뛰는 것이라고 이해했습니다. 저도 1인 풀스택 개발에 뜻이 있는 입장에서 되게 괜찮은 방법론이라 생각했는데, 해당 의문은 이로인해 근본적으로 서버 액션이라는 기술의 활용 범위를 넓힘으로 인해 발생했다고 생각합니다.

 

첫 번째 의문은 Next.js의 특수성으로 미루어 보아 문제가 없다고 결론지었습니다. 서버 액션이라는 개념 자체가 일반적으로 REST API를 설계하는데 사용되는 개념이 아니기도 하고, 애초에 엔드포인트 자체도 루트 경로로 받기 때문에 의미가 없는 것이죠. 프레임워크가 관리해주기 때문에 메서드와 엔드포인트로 작업 단위를 표현하지 않아도 괜찮다고 생각했습니다.

 

두 번째는 의문이라기 보다는 문제였죠. 저는 해당 문제를 해결하기 위해 Tanstack Query를 사용했습니다만 근본적인 해결은 아니었습니다. HydrationBoundary 와 prefetchQuery를 활용하여 SSR과 서버 컴포넌트 환경을 통합하였고, useQuery 훅과 Query Key Factor 방식을 사용하여 캐싱 전략 관리를 시도했는데, 다 만들고 보니 이건 클라이언트에 해당하는 캐싱 전략이었어요. 서버 쪽에서는 적절한 캐싱 전략이 없었습니다. 해당 문제는 공식 문서를 찾아보니 라우트 세그먼트의 설정을 상속받아 maxDuration 같은 설정을 따른다고 안내되고 있었습니다. 적용해보지는 못했지만 page.tsx에서 결정할 수 있는 것 같아 아마 다음 미션에서 기회가 된다면 사용해볼 예정입니다.

 

벌써 다음 미션이 기대되네요. 긴글 읽어주셔서 감사합니다. ☺

댓글을 작성해보세요.

채널톡 아이콘