2024-07-10: ‘준비물 챙겼어?’ 이야기 (6) - 방구석에 놔둔 개발 노트

💭 근심, 관심 그리고 싹고칠 결심

지난 글로부터 시간이 좀 지났다.

그 사이에 면접도 있고 해서 준비하느라 잠시 놓고 있던 것도 있고, 각각 작업한 과정에 대한 블로깅을 하자는 의미에서 따로 집중한 시간도 있어서 종합적인 내용을 다루는 이 글을 이제서야 쓰게 됐다.

이전 글에서는 마이그레이션에 대한 고민을 깊게 드러냈었다. 그에 따른 시간적 비용과 뒤따라오는 문제들을 이야기했었는데 고민 끝에 현재까지 작업한 사항들을 스탑하고 마이그레이션을 본격적으로 진행하기로 했다.

그런데 마이그레이션을 하면서 여태까지 작업한 내용들이 또 마음에 들지 않았고, 결국 마이그레이션과 리팩토링을 같이 진행하다보니 시간이 오래 걸렸다. (사실상 새로운 프로젝트라는 느낌인데…)

아무튼 현재는 완료가 되었으며 주로 작업한 내용들은 아래와 같다.

Vite + React에서 Next.js로의 마이그레이션
Next.js로 마이그레이션에 따른 폴더 구조 변경
styled-components를 지우고, tailwind CSS로 마이그레이션
만능 컴포넌트로 다 넣던 형태를 없애고, 합성 컴포넌트 패턴으로 폼과 모달 등을 활용
커스텀 훅 로직 적용 사항의 변경
API 로직을 class로 분리 및 통합

각 진행 과정 및 고민은 별도의 포스팅으로 남겼다. 궁금한 사람들은 위의 진행 사항들을 누르면 내용을 볼 수 있으니 참고하길 바란다.

이번 글에서는 마이그레이션을 하면서 못 다한 이야기들, 그리고 마이그레이션 전후 비교 등을 다뤄보고자 한다.

🏗️ Next.js로 넘어온 이유, 그리고 시행착오?

Next.js로 넘어오게 된 이유로는 두 가지가 있다.

첫 번째는 프로젝트 특징 상 metadata가 잘 반영되어야만 했다. 그래서 자연스럽게 SEO를 활용할 수 있는 Next.js가 필요했다. 사실 이게 가장 큰 이유다.

두 번째는 UI 만을 그려내는 정적 컴포넌트를 잘 활용해서 성능 등을 최적화 해보고 싶었다. 이런 부분에서는 클라이언트 컴포넌트와 분리할 수 있는 Next.js가 적합하다고 생각했다.

Next.js로 마이그레이션을 진행했을 때에는 현재 버전인 Next.js 14.2.4로 마이그레이션을 진행했다.

그러나 마이그레이션을 거의 다 마칠 즈음에 프로젝트를 빌드해보고 성능 테스트를 하는 과정에서 초기 페이지 로드 중에 layout.tsx이 받아지지 않는 문제가 발생했다.

내가 잘못 설정한 건가 싶기도 한데, 비슷한 이슈를 가진 사람이 한 달 전에 레딧에서 글을 올려 이에 관한 논의가 진행된 것을 볼 수 있었다.

(hatena 측에서 reddit 링크를 연결하려니 Bad Request가 발생하고 있다. 내용이 궁금한 사람들에겐 번거롭겠지만 아래의 링크를 드래그해서 보길 바란다.) www.reddit.com/r/nextjs/comments/1ayw24l/uncaught_syntaxerror_invalid_or_unexpected_token

댓글 중에는 .next 폴더의 캐쉬나, node_module 폴더를 지우고 새로 다시 설치해보라, turbo modules를 이용해보라는 등의 내용이 있어 똑같이 시도해봤지만 결과는 변하지 않았다.

결국 제시된 다른 방법으로서, 13.5.4가 안정적이니 다운그레이드할 것을 권장하는 내용에 따라 현재 프로젝트는 13.5.4로 고정해서 진행했다.

(※ 글을 쓴 이후에 다시 자료를 찾아보니 template 파일을 이용하면 해결이 될 거라는 내용을 발견했는데… 이에 대해서는 추후에 버전업 시도 후 도전해봐야겠다.)

Getting error whein i run and open my app first time after reload it automatically fix the error im using NEXT.js 13 · vercel next.js · Discussion #59119

아무튼, 결과적으로 위의 이슈가 좀 있었긴 했지만 13.5.4 버전에서 마이그레이션을 완료했으며, 현재 구현된 데까지의 문제 사항은 없다.

https://github.com/DrunkenNeoguri/project-elements

❓ 전역 상태 관리에 대한 여전한 고민

처음 프로젝트를 시작할 당시에는 필요한 것들은 ‘Jotai를 통해 전역 상태 관리를 처리해서 프로젝트를 진행하자’고 생각했다.

그러나 개발이 진행이 되고 구현 사항이 많아지면서 ‘겨우 이런 거 때문에 전역 상태 관리를 써야하나?’라는 의문이 들었다.

현재 프로젝트에서 전역으로 사용되고 있는 건 firebase auth의 유저 정보를 받아오는 것 밖에 없다.

처음에는 이걸 Jotai를 통해 Provider를 묶어서 활용하려고 했었는데…

쓰면 쓸 수록 Provider로 묶어 해당 범위 안에서만 쓰게 할 거라면 ‘굳이 Jotai를 쓸 필요가 있는가?’, ‘Context API로 해도 충분하지 않을까?’ 라고 스스로에게 물음표가 자꾸 던져졌다.

"use client";
import { ReactNode, createContext, useEffect, useState } from "react";
import { firebaseAuth } from "../utils/util-firebase";
import { User, onAuthStateChanged } from "firebase/auth";
import { usePathname, useRouter } from "next/navigation";

type AuthContextType = User | null;

export const AuthContext = createContext<AuthContextType>(null);

export default function AuthProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<AuthContextType>(null);
  const router = useRouter();
  const pathname = usePathname();

  useEffect(() => {
    onAuthStateChanged(firebaseAuth, (user) => {
      if (user) {
        return setUser(user);
      } else {
        setUser(null);

        return new Error("Authorization token is expired.");
      }
    });
  }, [router, pathname]);

  return <AuthContext.Provider value={user}>{children}</AuthContext.Provider>;
}

그러다보니 계속된 질문의 끝엔 ‘현재의 프로젝트에서 전역 상태 관리 라이브러리가 과연 필요한가?’라는 포괄적인 질문으로 오게 됐고, 결론을 내려 전역 상태 관리의 필요성이 정말로 필요하다고 느껴질 때까지 전역 상태 관리를 사용하지 않기로 했다.

그리고 기존의 Jotai를 AuthProvider에서 걷어내고 그 자리를 Context API를 쓰기로 했다.

여기까지 스스로에게 자꾸 질문을 던지게 되면서, 한편으로 ‘전역 상태 관리가 언제 필요하고, 어떤 라이브러리를 써야하는지 나는 이해하고 있는 걸까?’라는 생각도 좀 들었는데…

그렇진 않은 거 같아서 언젠가 짚고 가자는 생각으로 추후에 포스트를 써 볼 예정이다.

🎆 정말 많은 것을 고친 결과, 좋아졌을까? (2024-07-12 수정 [1])

마이그레이션이니, 스타일링 변경이니, 리펙토링이니 이번 작업에는 정말 많은 것들을 했다.

그런 만큼 당연히 그 결과가 궁금해지는 것이 당연한 법.

메인 페이지 만을 기준으로 변경 전/후의 프로젝트를 빌드 후 실행하여 Lighthouse로 지표를 내봤고 아래와 같은 결과가 나왔다.

좌측은 기존 프로젝트인 Vite+React, 우측은 현재 프로젝트인 Next.js의 Lighthouse 결과.

Lighthouse를 이용해본 것은 이번이 처음이었는데 신선한 경험이었다. 다양한 지표를 통해서 내 프로젝트에서 어떤 장점과 단점이 있는지를 알 수 있었다.

아, 깜빡할 뻔 했는데 지표를 분석한다는 건 두 프로젝트가 동일한 상황에 놓여져야 한다고 생각한다. 이번 마이그레이션을 진행하면서 SSR에서 몇 가지 기능의 변화나 디자인의 변경점 등이 생겼는데, 비교를 위해서는 구버전인 CSR에서도 동일한 디자인과 기능을 맞춰야 한다고 생각했다. 위의 지표는 두 프로젝트의 디자인과 기능을 최대한 가깝게 만든 후에 나온 지표이다.

결과적으로는 FCP는 시간이 단축됐고 LCP도 좋은 지표를 보여줘서 만족스럽긴 하지만... 메인 페이지만 놓고 보기엔 그렇다는 거고, 다른 페이지들도 점차 이런 식으로 분석해가면서 수정할 필요가 있다. 다행히 이번을 통해서 문제점을 파악하는 법을 알게 됐으니 우선은 런칭을 목표로 하고, 추후에 다시금 확인해보도록 하자.

[1] 사실, 비교하기 전에 마이그레이션 후 Lighthouse를 분석해봤는데 FCP와 LCP에 관해 생각한 만큼의 결과가 나오지 않았다. 글 작성 이후, 이 부분을 분석하고 개선하는 시간을 가졌고, 그 결과가 위의 이미지이다. 어떻게 개선했는지 등에 관한 내용은 향후 Lighthouse에 대한 글과 함께 포스트로 올리겠다.