이번 프로젝트는 거창한 아이디어에서 시작한 게 아니었다. 이유는 꽤 단순했다. React Native를 제대로 익혀보고 싶었다.

문서만 읽거나 예제를 따라치는 방식은 금방 한계가 왔다. 내 기준에서는 작은 기능 몇 개를 찍어보는 것보다, 하나의 제품을 처음부터 끝까지 만들어보는 게 훨씬 빨리 배우는 방법이었다.

그래서 이번에는 한 번 만들고 끝나는 연습용 프로젝트보다, 만든 뒤에도 계속 붙잡고 개선해나갈 수 있는 주제를 먼저 고르기로 했다.

아이디어는 어떻게 정했는가

주제를 고를 때 기준은 세 가지였다.

1. 내가 실제로 자주 겪는 문제인가
2. 다른 사람도 어느 정도 공감할 수 있는 문제인가
3. 기능을 조금씩 확장해나가기 쉬운가

이 기준으로 고민하다가 결국 잡은 주제가 “미루는 습관을 줄여주는 리마인드 앱” 이었다.

처음에는 흔하게 Todo 앱부터 떠올렸다. 그런데 생각해보면 문제는 늘 기록이 아니었다. 할 일을 적는 것 자체는 어렵지 않은데, 정작 힘든 건 그걸 시작하게 만드는 순간이었다.

그래서 이 앱도 단순히 할 일을 적고 체크하는 방향보다는, 행동을 유도하는 쪽으로 기능을 붙여보자는 생각이 들었다.

예를 들면 이런 식이다.

• 일정 시간 동안 시작하지 않으면 푸시로 리마인드 보내기
• 오늘 계획이 비어 있으면 AI가 가볍게 시작 제안해주기
• 미룬 횟수, 실제 시작 시간, 완료율 같은 패턴 기록하기
• 집중 시간과 휴식 루틴을 자연스럽게 이어주기

물론 만들다 보면 규모가 커질 수 있다는 부담도 있었다. 그래도 이번 프로젝트는 결과물 하나보다, 그걸 만드는 과정에서 뭘 배우느냐가 더 중요했다. 그래서 애초에 작게 닫기보다는, 나중에 기능을 넓혀가기 쉬운 구조로 시작하는 쪽을 택했다.

기술 스택은 왜 이렇게 잡았는가

이번 프로젝트는 하나의 앱만 만드는 식이 아니라, web-ui + api + mobile 형태의 모노레포로 구성했다.

여기서 중요한 건 기술을 많이 써보는 데 있지 않았다. 오히려 개발 속도는 챙기고, 새로 익힐 부분은 따로 가져가기 위해 역할을 나눈 쪽에 가까웠다.

1) Web UI: 익숙한 조합으로 속도부터 챙기기

• React 19 + TypeScript
• Vite
• TanStack Query
• Zustand
• React Router
• Tailwind CSS + DaisyUI
• dnd-kit
• Tiptap

웹은 기능 실험도 많고, UI를 계속 바꾸게 되는 영역이다. 이런 구간에서 새로운 스택까지 한꺼번에 들이밀면 전체 흐름이 쉽게 꼬인다. 그래서 웹은 의도적으로 익숙한 조합으로 가져갔다.

각 선택 이유도 꽤 분명했다.

• React + TypeScript: 구조를 바꾸거나 리팩터링할 때 대응하기 편하다.
• Tailwind: 반복되는 UI를 빠르게 만들 수 있다.
• TanStack Query + Zustand: 서버 상태와 클라이언트 상태를 나눠서 관리하기 좋다.
• Vite: 초기 세팅과 반복 개발 속도가 빠르다.

정리하면, 웹은 이번 프로젝트에서 새로운 걸 실험하는 공간이라기보다 빠르게 만들고 계속 수정할 수 있는 기반으로 두고 싶었다.

2) API: GraphQL로 설계를 제대로 해보기

• Fastify
• Apollo Server + GraphQL
• Prisma
• MongoDB
• Zod

기존에는 Next.js 기반으로 빠르게 붙이는 방식이 익숙했다. 그 방식도 장점이 분명했고 실제로 생산성도 좋았다.

그런데 이번에는 웹과 모바일을 분리해서 가져가는 만큼, API도 그냥 붙이는 수준이 아니라 데이터 구조를 한 번 제대로 설계해보고 싶었다.

그래서 GraphQL을 선택했다.

이유는 꽤 단순했다.

• 화면마다 필요한 데이터 조합을 더 명확하게 가져갈 수 있고
• 스키마 중심으로 계약을 관리하기 편하고
• 모노레포 안에서 웹과 모바일이 같은 API 기준을 공유하기 좋았다

물론 초반 속도만 놓고 보면 REST보다 더디게 느껴질 수 있다. 그래도 웹 쪽에서 익숙한 스택으로 속도를 확보한 만큼, 그 여유를 API 설계 쪽 학습에 써보는 게 이번 프로젝트 목적과 더 잘 맞았다.

3) Mobile: 하이브리드로 React Native를 실전에서 익히기

• Expo + React Native
• Expo Router
• React Native WebView
• Skia / Haptics 등 Expo 생태계

모바일은 이번 프로젝트에서 직접 부딪혀보면서 React Native 감각을 익히는 영역이었다.

처음부터 완전 네이티브로 끝까지 가는 방법도 있겠지만, 그렇게 시작하면 초반 진입장벽이 생각보다 높고, 금방 지치기 쉽다. 그래서 이번에는 하이브리드 방식으로 접근했다. 빨리 만들어보면서 필요한 감각은 놓치지 않는 쪽이 더 현실적이라고 봤다.

각 선택도 그런 기준에서 나온 거였다.

• WebView: 기존 웹 자산을 재활용해서 초기 구현 속도를 챙길 수 있다.
• RN 화면: 네이티브 인터랙션과 디바이스 동작을 직접 다뤄볼 수 있다.
• Expo 생태계: 복잡한 네이티브 설정 부담을 줄이고 개발 흐름을 유지하기 좋다.

결국 모바일은 무리해서 처음부터 모든 걸 네이티브로 하려 하기보다, 배포 가능한 형태를 빠르게 만들면서 React Native를 몸으로 익혀보는 방식으로 가져갔다.

화면 개발은 “바이브 코딩”으로 풀었다

이번 화면 작업에서는 Codex나 Claude 같은 에이전트를 꽤 적극적으로 붙여서 작업했다. 처음엔 반신반의했는데, 실제로 써보니 생각보다 훨씬 유용했다. 특히 개발 속도를 계속 끌고 가는 데 도움이 컸다.

코덱스에는 먼저 레포지토리를 읽게 한 다음, 대략 이런 식으로 작업을 맡겼다.

• 먼저 화면 전체 흐름부터 잡기
• 헤더, 버튼, 카드 같은 공통 UI 먼저 분리하기
• 디테일한 스타일은 한 번에 끝내지 않고 여러 번 나눠 다듬기

이 방식이 좋았던 건, 막혔을 때 처음부터 다시 짜지 않아도 된다는 점이었다. 이미 있는 코드 위에서 바로 수정하고, 비교하고, 다시 밀어붙일 수 있었다. 혼자서 처음부터 전부 새로 짜는 것보다 훨씬 리듬이 끊기지 않았다.

대신 분명하게 느낀 것도 있었다. 요청이 애매하면 결과도 애매하게 나온다.

그래서 구현 디테일을 길게 늘어놓기보다는, 내가 원하는 방향을 먼저 분명하게 전달하려고 했다.

• “헤더는 정보량을 조금 줄이고 더 단정하게”
• “핵심 액션은 첫 화면에서 바로 보이게”
• “반복되는 부분은 공통 컴포넌트로 빼기”
• “디자인이 애매하면 참고 이미지를 같이 보여주기”

이렇게 해보니까 에이전트가 모든 걸 대신해주는 느낌이라기보다는, 내가 판단한 방향을 훨씬 빠르게 화면으로 옮겨주는 도구에 가까웠다.

결과물도 꽤 인상적이었다. 무조건 완벽하게 나온다기보다는, 방향만 잘 잡아주면 생각보다 훨씬 빠르게 쓸 만한 형태를 만들어준다는 쪽이 더 정확했다.

물론 코드를 뜯어보면 손볼 부분도 많았다. 군데군데 덕지덕지 붙은 흔적도 있었고, 그대로 두면 아쉬운 부분도 분명했다. 그래도 내가 원하는 걸 빠르게 시도해보고, 바로 수정하면서 다음 단계로 넘어갈 수 있다는 점은 꽤 강력했다.

마무리

이번 프로젝트는 단순히 앱 하나를 만드는 작업이라기보다, 어떻게 배우고, 어떻게 만들고, 어떤 도구를 어디까지 활용할지를 같이 익혀가는 과정에 가까웠다.

주제를 정할 때는 실제로 오래 붙잡고 갈 수 있는 문제를 골랐고, 기술 스택은 속도와 학습 포인트를 나눠서 가져갔다. 웹에서는 빠르게 만들 수 있는 기반을 챙기고, API에서는 설계를 더 신경 써봤고, 모바일에서는 React Native를 실전으로 익혀보는 데 집중했다.

그리고 화면 작업에서는 에이전트 도구를 적극적으로 써보면서, 이런 도구가 개발을 대신해주는 존재라기보다 결정과 수정 속도를 올려주는 협업 도구에 가깝다는 것도 체감했다.

처음엔 React Native를 공부해보자는 마음으로 시작한 프로젝트였지만, 돌아보면 그보다 더 많은 걸 배웠다. 하이브리드 구조를 어떻게 가져갈지, 학습을 제품 개발 안에 어떻게 녹일지, 그리고 AI 도구를 실제 작업 흐름 안에서 어떻게 써야 하는지까지 같이 확인할 수 있었다.

정글동선 만큼 전체적인 흐름의 최적화도 중요하다..

지난번에 GPT한테 블로그 보강 ToDo를 정리해달라고 했고,
SEO 작업을 먼저 마무리한 뒤 이번엔 성능 개선 단계로 넘어왔다.

이번 목표는 명확했다.
성능 최적화를 통해, 배포된 웹페이지가 이전보다 더 빠르게 뜨도록 만드는 것

GPT가 준 최적화 리스트

• 이미지 최적화
• Provider 범위 최소화
• dynamic import 기반 코드 스플리팅

최적화가 중요하다는 건 원래 알고 있었다.
그래서 API 호출 줄이기, memo/useCallback 같은 기본적인 최적화는 이미 적용해둔 상태였고,
그때까진 “이 정도면 최적화는 꽤 해둔 편 아닌가?”라고 생각했다.

근데 이번에 성능을 본격적으로 점검하면서 느낀 건,
그건 어디까지나 컴포넌트 단위/코드 단위 최적화였고,
페이지 진입부터 렌더링까지 이어지는 전체 흐름 최적화는 거의 못 보고 있었다는 점이었다.

예를 들면,

• 초기 진입에서 꼭 필요하지 않은 코드가 같이 로드되는 문제
• 전역 provider 범위가 넓어서 모든 페이지가 공통 비용을 먹는 문제
• 화면에서 안 쓰는 데이터까지 API로 받아오는 문제
• 페이지 전용 컴포넌트가 공용 번들에 섞여 들어가는 문제

이런 건 useCallback 하나 추가한다고 해결되는 문제가 아니었다.
코드 한 줄 단위의 최적화보다, 로딩 경로 자체를 어떻게 설계했는지가 더 크게 영향을 줬다.

그래서 이번엔 관점을 조금 바꿨다.
“함수 재생성 줄이기” 같은 미시적인 최적화보다,
어떤 코드가 언제 로드되고, 어떤 데이터가 언제 필요한지를 먼저 보는 쪽으로.

결국 최적화는 작은 코드 테크닉만으로 끝나는 게 아니라,
페이지 구조, provider 범위, 데이터 흐름까지 함께 봐야 하고,
실제 사용자 체감은 그쪽에서 더 크게 갈린다는 걸 이번에 확실히 느꼈다.

무엇을 최적화 했는가?

이미지 최적화

next에서 제공해주는 Image컴포넌트를 쓰면 손쉽게 최적화를 할수있다.

next/image는 일반 img보다 이미지 로딩을 자동으로 최적화해주는 Next.js 내장 컴포넌트 핵심은 “필요한 이미지부터, 필요한 크기로, 필요한 시점에” 로드하게 만드는 것.

주로 사용한 기능은 아래와 같다.

• priority 해당 이미지를 “초기 렌더 핵심 리소스”로 취급해서 미리 적극적으로 로드 LCP 후보(첫 화면 대표 이미지)에는 유리할 수 있음 근데 남발하면 초기 네트워크 경쟁이 커져서 오히려 느려짐

• loading="lazy" 뷰포트 근처에 왔을 때 로드 첫 화면에 당장 안 보이는 이미지면 초기 로딩 부담을 줄임

• decoding="async" 이미지 디코딩을 렌더링 메인 흐름을 덜 막는 방식으로 처리 화면 표시를 덜 방해하게 도움

next/image의 priority를 무분별하게 쓰지 않고, 비핵심 이미지는 lazy/async로 전환해서 초기 렌더 구간의 네트워크 경쟁과 디코딩 부담을 줄였다.

Provider 범위 최소화 + 구조 정리

이번 최적화에서 가장 구조적으로 의미 있었던 부분은 provider 정리였다.
예전에는 “전역에서 한 번에 감싸는 방식”에 가까워서 관리가 편하긴 했지만,
책임 경계가 흐려지고 페이지가 늘어날수록 비용과 복잡도가 같이 커지는 구조였다.

그래서 이번에는 provider를 기능 기준으로 다시 쪼개서,
“어디서 무엇을 책임지는지”가 보이도록 정리했다.

UI 책임 분리 (UIProvider / PopupHost)

기존에는 팝업 처리 로직이 한 덩어리로 엮여 있어서
모달/토스트 동작 흐름을 추적하기가 어려웠다.

이번에 다음처럼 역할을 분리했다.

• UIProvider: UI 제어 함수(openModal/openToast) 제공
• ModalHost: 모달 렌더링 전담
• ToastHost: 토스트 렌더링 전담
• PopupContainer: host 조합/마운트 지점 관리

이렇게 분리하면서,
“상태를 누가 만들고 / 누가 보여주고 / 누가 정리하는지” 경계가 명확해졌다.

모달 라이프사이클 정리 (열기/응답/정리)

모달은 단순히 띄우는 것보다,
응답(resolve)과 cleanup 타이밍이 더 중요했다.

이번에 모달 관리 책임을 다음처럼 정리했다.

• 모달 결과값(resolve) 처리 경로 통일
• route 변경 시 열려 있던 모달 정리(cleanup) 분리
• write 모달 같은 비동기 흐름에서도 토스트/모달 충돌 줄이기

결과적으로 “모달이 닫혔는데 상태가 남는 문제” 같은
경계성 버그 가능성을 낮췄다.

Session Provider 범위 축소

//몽땅 떄려박고 사용하던방식

export function MyProvider({ children }: { children: React.ReactNode }) {
  const queryClient = getQueryClient();

  return (
    <ReduxProvider store={store()}>
      <ThemeProvider attribute="class">
        <QueryClientProvider client={queryClient}>
          <UIProvider>
            <ReactQueryStreamedHydration>{children}</ReactQueryStreamedHydration>
            <Suspense fallback={null}>
              <PopupContainer />
            </Suspense>
            {process.env.NODE_ENV === "development" ? (
              <ReactQueryDevtools initialIsOpen={false} buttonPosition="bottom-right" />
            ) : null}
          </UIProvider>
        </QueryClientProvider>
      </ThemeProvider>
    </ReduxProvider>
  );
}

// components/providers/sessionBoundary.tsx (After 신규 추가)
//따로 빼서 인가가 필요한 페이지에서만 사용
"use client";

import { SessionProvider } from "next-auth/react";

export default function SessionBoundary({
  children,
}: {
  children: React.ReactNode;
}) {
  return <SessionProvider>{children}</SessionProvider>;
}
/

기존에는 세션 provider를 넓은 범위에서 공통 적용하던 구조였고,
이번에는 필요한 라우트 중심으로 범위를 좁히는 방식으로 조정했다. 지금은 프로젝트가 작지아서 효과를 체감할 순 없지만 플젝이 좀더 커지면 좀더 효과적이라는 생각과 이런 방식으로도 정리 할수 있구나라는 생각이 들었다.

결과적으로 달라진 점

이 작업은 단순히 provider 개수를 줄인 게 아니라,
책임을 세분화해서 구조를 읽기 쉬운 형태로 바꾼 게 핵심이었다.

정리 이후 기준으로 보면,

• 모달/토스트/UI 컨텍스트 책임이 분리되어 추적이 쉬워졌고
• route 전환 시 정리 타이밍이 명확해졌고
• 인증 스코프가 페이지 단위로 구분되면서 유지보수 난이도가 내려갔다

이번 provider 정리는 “성능 최적화 + 구조 가독성 + 유지보수성”을 같이 가져간 작업이었다.

페이지 코드 스플리팅

스플리팅이란 뭘까?

write

write 페이지는 초기 진입 부담이 큰 편이라 우선순위로 분리했다.
dynamic import로 무거운 영역을 초기 렌더 경로에서 빼고, 필요한 시점에만 로드되도록 조정했다.

추가로 로딩 UI도 같이 손봤다.
처음에는 스켈레톤을 넣었지만 write 특성상 오히려 흐름이 끊겨 보여서,
최종적으로는 “로딩이 끝나면 opacity animation을 사용해 화면이 자연스럽게 나타나는 방식”으로 바꿨다.
즉, 단순히 분할만 한 게 아니라 렌더링 전환 방식까지 같이 정리한 셈이다.

실측 결과:

• /write First Load JS: 167kB → 151kB
• 약 9.6% 감소

comments

comments는 페이지 전용 컴포넌트를 페이지 스코프로 이동하고,
부가 기능(captcha 등)은 필요한 시점에만 로드되도록 분리했다.

결과:

• 초기 로드 기준 번들 부담이 대략 5~9% 수준으로 줄어드는 방향으로 확인됨
• 공통 번들 오염이 줄어 진입 흐름이 단순해짐

profile

profile도 전용 코드 스코프를 분리해서
전역 번들에 불필요하게 실리던 의존성을 줄였다.

결과:

• 초기 로드 기준 번들 부담이 대략 5~9% 수준으로 줄어드는 방향으로 확인됨
• profile 관련 코드가 필요한 시점에 로드되도록 정리됨

post (commonPost 컬렉션 영역)

post 상세는 코드 분할뿐 아니라 데이터 응답도 같이 다이어트했다.
컬렉션 목록에서 화면에 실제로 쓰는 값 중심으로 응답을 정리해서
불필요한 데이터 전송량을 줄였다.

결과:

• 페이지 전환/영역 표시 시 체감 지연 완화
• 초기 로드 기준으로도 5~9% 내외 개선 구간으로 확인

Lighthouse 결과

배포 환경 기준 before/after를 여러 번 비교했을 때,
Performance 점수는 평균 +4점 상승했다.
(예: 78 → 82)

Lighthouse는 측정 환경에 따라 편차가 있어서
단일 측정값보다 평균 비교 기준으로 판단했다.

정리

이번 작업은 “새 기능 추가”보다
초기 로드 비용 줄이기 + 전역 구조 경량화에 집중한 작업이었다.

핵심 결과를 요약하면:

• write 번들 감소: 167kB → 151kB (약 9.6% 감소)
• Lighthouse 평균: +4점
• provider/캐시/응답 구조 정리로 체감 로딩 안정성 개선

확실히 렌더링 속도가 조금 더 빨라졌고, 오랜만에 집 청소를 한 것처럼 상쾌한 느낌도 든다. 개발도 재밌지만, 이렇게 세세하게 구조를 정리해보는 과정도 꽤 재밌는 것 같다.

React와 Next.js로 사이드 프로젝트를 여러 번 만들었다. 기능을 구현하고, 페이지를 만들고, 필요한 라이브러리를 붙이는 데에는 이제 어느 정도 익숙해졌다.

그런데 익숙하게 쓴다는 것과 정확히 이해하고 있다는 것은 다른 문제였다. 예를 들어 state가 왜 이렇게 반영되는지, memo는 언제 의미가 있는지,** key는 왜 중요한지** 같은 질문을 받으면 어렴풋이 설명은 할 수 있어도, 명확하게 말하긴 애매하다는 생각이 들었다.

그래서 이번 글은 React를 새로 배우는 글이라기보다, 이미 쓰고 있는 개념들을 예제를 통해 다시 확인해보는 글에 가깝다. 자주 쓰지만 막상 제대로 설명하려면 헷갈리는 기본기들을 하나씩 다시 살펴보려고 한다.

리액트, 이것이 궁금했었다

React를 쓰다 보면 state를 바꾸면 화면이 바뀌고, 리스트를 렌더링할 때는 key를 넣고, 필요하면 memo나 useCallback으로 최적화를 한다. 그런데 막상 한 번 멈춰서 생각해보면, React는 이런 일을 도대체 어떻게 처리하고 있는 걸까?

React는 변경이 생길 때마다 화면 전체를 무작정 다시 그리는 대신, 컴포넌트를 다시 실행해 새로운 UI를 계산하고, 이전 결과와 비교한 뒤 실제로 달라진 부분만 DOM에 반영한다.

즉, React는 “다시 계산”과 “실제 반영”을 분리해서 다루고, 이 구조 덕분에 선언적인 방식으로 UI를 작성하면서도 비교적 효율적으로 화면을 업데이트할 수 있다.

이번 글에서는 간단한 예제를 통해 이런 동작을 하나씩 확인해보려고 한다.

예제로 살펴보기

1. useState

개념

useState는 단순히 값을 저장하는 도구처럼 보이지만, 실제로는 그보다 조금 다르게 이해하는 편이 좋다.

중요한 건 useState가 현재 렌더에서 사용할 상태값을 제공하고, setter 함수는 그 값을 즉시 바꾸는 것이 아니라 다음 렌더링을 예약한다는 점이다.

즉, count 같은 state 값은 “지금 이 순간 바로 바뀌는 변수”라기보다,
이번 렌더에서 React가 보여주기로 한 값에 가깝다.

이 관점이 중요한 이유는 useState를 쓰면서 자주 헷갈리는 지점들이 대부분 여기서 시작되기 때문이다.
왜 같은 setState를 여러 번 호출했는데 기대한 값이 나오지 않는지,
왜 비동기 함수 안에서는 예전 값을 보고 있는 것처럼 보이는지 같은 문제들이 대표적이다.

결국 useState를 이해할 때 핵심은
state는 즉시 변경되는 값이 아니라, 렌더마다 고정된 스냅샷처럼 동작한다는 점이다.

예제: 같은 setState인데 왜 결과가 다를까

const wrongIncrease = () => {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
};

const correctIncrease = () => {
  setCount((prev) => prev + 1);
  setCount((prev) => prev + 1);
  setCount((prev) => prev + 1);

wrongIncrease를 실행하면 count가 3 증가할 것 같지만, 실제로는 기대와 다르게 동작한다.
반면 correctIncrease는 의도한 대로 3이 증가한다.

그 이유는 현재 렌더에서의 count 값은 하나로 고정되어 있기 때문이다.
즉, setCount(count + 1)를 세 번 호출해도 각각이 서로 다른 값을 기준으로 계산하는 것이 아니라,
같은 count 값을 기준으로 세 번 요청하는 것에 가깝다.

반면 함수형 업데이트는 이전 상태를 순서대로 전달받아 계산한다.
그래서 여러 번 호출해도 앞선 업데이트 결과를 이어서 반영할 수 있다.

state는 즉시 바뀌는 변수가 아니라, 렌더마다 고정된 값을 기준으로 읽힌다.

예제: 왜 비동기 안에서는 예전 state를 보게 될까

//이 이벤트를 붙인 버튼을 클릭하고 setCount로 값을 변경했을때 count는 어떻게 보일까?
const onHandleClick  = () => {
  setTimeout(() => {
    console.log(count);
  }, 1000);
};

이 코드는 1초 뒤에 count를 출력하는 것처럼 보인다. 하지만 타이머가 실행되기 전에 state가 바뀌더라도, 항상 최신 count가 출력되는 것은 아니다.

그 이유는 setTimeout 안의 콜백이 만들어질 당시의 count 값을 기준으로 동작하기 때문이다. 즉, 나중에 실행되는 코드라고 해서 항상 최신 state를 참조하는 것은 아니다.

이 예제를 통해 알 수 있는 것은, 비동기 로직 안에서의 state는 “실행되는 시점”보다 “함수가 만들어진 시점” 의 영향을 크게 받는다는 점이다.

state는 항상 최신값을 읽는 것이 아니라, 함수가 만들어진 시점의 값을 기준으로 동작할 수 있다.

2. useCallback

개념

useCallback은 함수를 실행하는 Hook이 아니라,
렌더링 사이에서 함수 참조를 유지하는 Hook이다.

컴포넌트는 렌더링될 때마다 다시 실행되므로,
내부에서 선언한 함수도 매번 새로 만들어진다.

보통은 문제없지만,
memo로 감싼 자식에게 함수를 props로 넘기거나
useEffect 의존성에 함수를 넣는 경우에는
함수가 새로 만들어졌다는 사실 자체가 불필요한 동작을 만들 수 있다.

즉, useCallback의 핵심은
함수 내용을 바꾸는 것이 아니라
같은 함수 참조를 재사용하게 만드는 것이다.

예제: 왜 자식이 다시 렌더링될까

const Child = memo(function Child({ onClick }) {
  console.log("Child render");
  return <button onClick={onClick}>클릭</button>;
});

export default function Parent() {
  const [theme, setTheme] = useState(false);

  const handleClick = useCallback(() => {
    console.log("click");
  }, []);

  return (
    <>
      <button onClick={() => setTheme((prev) => !prev)}>theme toggle</button>
      <Child onClick={handleClick} />
    </>
  );
}

Child는 memo로 감싸져 있어도,
부모가 다시 렌더링될 때마다 함수가 새로 만들어지면
props가 바뀐 것으로 판단해 다시 렌더링될 수 있다.

이때 useCallback을 쓰면
의존성이 바뀌지 않는 동안 같은 함수 참조를 유지할 수 있다.

useCallback은 자식 렌더링을 막는 도구라기보다, props 비교가 의미 있게 동작하도록 만드는 도구에 가깝다.

예제: useCallback을 써도 예전 값을 볼 수 있는 이유

const handleClick = useCallback(() => {
  console.log(count);
}, []);

이 코드는 함수 참조는 유지되지만,
처음 렌더에서 만들어진 count 값을 계속 바라보게 된다.

즉, useCallback은 함수를 고정할 뿐
그 안의 값을 자동으로 최신으로 바꿔주지는 않는다.

const handleClick = useCallback(() => {
  console.log(count);
}, [count]);

이렇게 해야 count가 바뀔 때 최신 값을 기준으로 새 함수가 만들어진다.

useCallback은 참조를 고정할 뿐, 내부 값까지 최신으로 보장하지는 않는다.

useCallback은 함수를 저장하는 Hook이 아니라,
함수 참조를 안정적으로 유지하는 Hook이다.

그래서 모든 함수에 쓰는 것이 아니라,
참조가 바뀌는 것이 실제 문제를 만드는 상황에서만 의미가 있다.

3. React.memo

개념

React.memo는 컴포넌트의 props가 이전과 같다면
부모가 다시 렌더링되어도 자식의 렌더링을 건너뛸 수 있게 해주는 기능이다.

React에서는 부모가 다시 렌더링되면 자식 컴포넌트도 함께 다시 실행되는 것이 기본 동작이다.
이때 자식이 받는 props가 이전과 동일하고, 다시 렌더링할 이유가 없다면
React.memo를 통해 그 렌더링을 생략할 수 있다.

다만 중요한 점은 React.memo가 모든 렌더링을 막아주는 것이 아니라, 어디까지나 props 비교 기준으로 불필요한 렌더링을 줄이는 도구라는 점이다.

즉, React.memo의 핵심은
컴포넌트를 “고정”하는 것이 아니라
같은 props라면 다시 실행하지 않도록 최적화하는 것에 가깝다.

예제: 부모가 다시 렌더링되면 자식도 항상 다시 실행될까

import { memo, useState } from "react";

const Child = memo(function Child({ value }) {
  console.log("Child render");
  return <div>value: {value}</div>;
});

export default function Parent() {
  const [count, setCount] = useState(0);
  const [theme, setTheme] = useState(false);

  return (
    <div>
      <button onClick={() => setCount((prev) => prev + 1)}>count 증가</button>
      <button onClick={() => setTheme((prev) => !prev)}>theme 변경</button>

      <Child value={count} />
    </div>
  );
}

이 예제에서 Parent가 다시 렌더링되는 상황은 두 가지다.

• count가 바뀔 때
• theme가 바뀔 때

여기서 Child는 value라는 props를 받고 있고,
React.memo로 감싸져 있다.

따라서 count가 바뀌면 value도 함께 바뀌므로 Child는 다시 렌더링된다.
반면 theme만 바뀌고 value가 그대로라면, Child는 다시 렌더링되지 않는다.

즉, React.memo는 부모 렌더링 자체를 막는 것이 아니라,
자식이 받는 props가 같을 때 자식 렌더링을 생략하게 해주는 것이다.

React.memo는 “부모가 렌더링되면 자식도 무조건 다시 렌더링된다”는 기본 흐름 위에서, props가 같을 경우 그 자식 렌더링을 건너뛸 수 있게 해준다.

예제: 그런데 함수 props를 넘기면 왜 다시 렌더링될까

import { memo, useState } from "react";

const Child = memo(function Child({ onClick }) {
  console.log("Child render");
  return <button onClick={onClick}>클릭</button>;
});

export default function Parent() {
  const [theme, setTheme] = useState(false);

  const handleClick = () => {
    console.log("click");
  };

  return (
    <>
      <button onClick={() => setTheme((prev) => !prev)}>theme toggle</button>
      <Child onClick={handleClick} />
    </>
  );
}

이 경우 Child는 memo로 감싸져 있어도,
부모가 다시 렌더링될 때마다 다시 렌더링될 수 있다.

그 이유는 handleClick 함수가 매 렌더링마다 새로 만들어지기 때문이다.
즉, 코드 모양은 같아 보여도 React 입장에서는
이전 props와 이번 props가 같은 값이 아니라 새로운 함수 참조로 보이게 된다.

그래서 React.memo는 함수 props 앞에서는 기대만큼 동작하지 않을 수 있고,
이때 useCallback이 함께 등장한다.

const handleClick = useCallback(() => {
  console.log("click");
}, []);

이렇게 하면 의존성이 바뀌지 않는 동안 같은 함수 참조를 유지할 수 있으므로,
React.memo의 props 비교도 비로소 의미 있게 동작하게 된다.

React.memo는 props가 같을 때만 동작한다.
그리고 함수 props의 “같음”을 유지하고 싶을 때 useCallback이 필요해진다.

React.memo는 렌더링을 막는 마법 같은 기능이 아니라,
같은 props에 대해 같은 결과를 그리는 컴포넌트의 불필요한 재실행을 줄이는 도구다.

그래서 모든 컴포넌트에 무조건 붙이기보다,
부모 렌더링이 자주 일어나고 props 변화가 제한적인 컴포넌트에서 더 의미가 있다.

그리고 함수 props를 함께 다루는 순간
React.memo만으로는 부족할 수 있으며,
그때 useCallback이 왜 필요한지도 자연스럽게 연결된다.

4. key

개념

key는 단순히 경고를 없애기 위한 값이 아니라,
React가 요소를 어떤 기준으로 구분할지 알려주는 식별자다.

React는 이전 렌더와 다음 렌더를 비교할 때
key를 보고 같은 컴포넌트인지, 새로운 컴포넌트인지 판단한다.

단순하게 key가 같으면 같은 대상으로 보고 state를 유지할 수 있고, key가 다르면 다른 대상으로 보고 새로 만든다

즉 key는 React에게 “이 요소가 이전 것과 같은 대상인지”를 알려주는 기준이다.

예제 1: key가 바뀌면 왜 state가 초기화될까

function ProfileForm({ user }) {
  const [input, setInput] = useState("");

  return <input value={input} onChange={(e) => setInput(e.target.value)} />;
}

<ProfileForm key={user} user={user} />

이 경우 user가 바뀌면 key도 바뀐다.
그러면 React는 기존 컴포넌트를 재사용하지 않고 새 컴포넌트로 다시 만든다.
그래서 내부 state도 초기화된다.

key가 바뀌면 React는 업데이트가 아니라 새 컴포넌트로 취급한다.

예제 2: 왜 index를 key로 쓰면 문제가 될 수 있을까

{items.map((item, index) => (
  <input key={index} defaultValue={item.text} />
))}

index는 순서를 나타내는 값이라서,
중간 삽입이나 정렬 변경이 생기면 같은 항목이어도 key가 달라질 수 있고,
반대로 다른 항목인데도 같은 자리로 잘못 대응될 수 있다.

그 결과 입력값, 체크 상태 같은 것이 엉뚱하게 남을 수 있다.

그래서 가능하면 이렇게 데이터 자체를 대표하는 값을 써야 한다.

{items.map((item) => (
  <input key={item.id} defaultValue={item.text} />
))}

key는 순서가 아니라, 각 항목의 정체성을 나타내는 값이어야 한다.

key는 리스트 문법이 아니라
React가 컴포넌트의 정체성을 판단하는 기준이다.

그래서 key를 어떻게 주느냐에 따라
state가 유지될 수도 있고, 초기화될 수도 있다.

마무리

이번에 정리한 예제들은 단순한 개념 설명이라기보다, 내가 사이드 프로젝트를 진행하면서 실제로 여러 번 부딪혔던 문제들에 가깝다.

state가 예상과 다르게 동작해 화면이 꼬인 적도 있었고, memo나 useCallback을 적절히 쓰지 않아 불필요한 렌더링으로 화면이 무거워진 적도 있었다. key 역시 단순히 리스트에 넣는 값 정도로 생각했었는데, 드래그 앤 드롭처럼 요소의 순서와 위치가 자주 바뀌는 상황에서는 생각보다 훨씬 중요한 기준이라는 걸 직접 겪으며 알게 됐다.

평소에는 익숙하게 쓰던 개념들이었지만, 이렇게 예제를 통해 하나씩 다시 정리해보니 “그냥 쓰는 것”과 “이해하고 쓰는 것”의 차이가 조금은 선명해진 느낌이다.

앞으로도 React를 사용할 때 새로운 기능만 빠르게 붙이기보다, 이런 기본 동작들을 함께 떠올리면서 더 안정적으로 코드를 작성해보려고 한다.

*내가만든 예제코드 * https://github.com/MyeongwuKim/ReactExample

사이드 프로젝트 끝났는데 이제 진짜 뭐하지.. 진짜 할게없다..

사이드프로젝트 블로그를 어느 정도 완성하고 나니까, 새로운 일을 벌리는것보단, 이제는 “여기서 뭘 더 보강하고 싶은데..” 라는 생각이 들었다.

혼자 정해보려다가 반쯤 장난으로 GPT한테 한번 물어봤는데, 생각보다 리스트를 꽤 잘 뽑아줘서 놀랐다. 그냥 가볍게 물어본 거였는데 기능 추가, SEO, 성능 개선 쪽으로 나눠서 제법 그럴듯한 ToDo를 정리해줬다.

특히 막연하게 “뭔가 더 해야 할 것 같은데...” 정도로만 생각하고 있던 부분들이, 실제로 손댈 수 있는 작업 목록으로 바뀌니까 프로젝트를 다시 보는 느낌도 조금 달라졌다.

GPT가 정리해준 블로그 보강 ToDo

GPT가 뽑아준 Todo는 이렇다.

SEO

• Open Graph / Twitter 메타데이터 적용
• canonical 설정
• post 상세 페이지 article 타입 적용 검토
• robots / sitemap 최종 점검
• 구조화 데이터(JSON-LD)
• not-found / 404 메타 처리

성능 개선

• 이미지 최적화
• 폰트 최적화
• 불필요한 클라이언트 컴포넌트 줄이기
• Provider 범위 최소화
• revalidate / 캐싱 전략 정리
• dynamic import 등 코드 스플리팅

꽤나 그럴싸하게 뽑아줬다 ㅋㅋ;

하나도 신경 쓰지 않았던 SEO

GPT에게 물어보기전엔 구글 검색 노출이 알아서 되는줄 알았다.

멍청하게도 블로그를 만들 때 SEO는 거의 신경 쓰지 않았다. 당시에는 일단 페이지가 잘 나오고, 글 목록이 보이고, 상세 페이지가 정상적으로 동작하면 그걸로 충분하다고 생각했다. 웹페이지는 그냥 잘 만들어서 문제없이 보이기만 하면 되는 줄 알았다.

그러다 GPT에게 블로그를 더 보강하려면 어떤 작업을 하면 좋을지 물어보는 과정에서, SEO가 생각보다 중요한 영역이라는 걸 알게 됐다. 검색엔진 최적화라는 말은 막연히 어렵게 느껴졌지만, 실제로는 title, description, Open Graph처럼 기본적이지만 중요한 설정들이 많았다.

특히 블로그처럼 글이 중심이 되는 프로젝트는 검색 유입도 중요하고, 링크를 공유했을 때 어떤 제목과 설명, 이미지가 보이는지도 꽤 중요했다. 그전까지는 그저 페이지를 만드는 데만 집중했다면, 이번에는 페이지를 더 제대로 보여주기 위한 작업도 필요하다는 걸 느꼈다.

무엇보다 나는 배포만 하면 검색엔진에 자동으로 잘 노출되는 줄 알았다. 하지만 실제로는 검색엔진이 페이지를 이해할 수 있도록 메타데이터를 정리해야 했고, 구글에 내 사이트가 더 잘 수집될 수 있도록 색인이나 사이트맵 같은 부분도 함께 챙겨야 한다는 걸 뒤늦게 알게 됐다.

익숙한 분야는 아니었지만, 그래서 이번 보강 작업에서는 SEO를 먼저 정리해보기로 했다.

무엇을 수정했는가?

구글 색인 등록

Google Search Console을 통해 색인 등록 작업을 진행했다. 위에 내용처럼 배포만 하면 검색 결과에도 자연스럽게 노출되는 줄 알았지만, 실제로는 사이트를 등록하고 사이트맵을 제출하는 등 검색엔진이 페이지를 수집할 수 있도록 따로 설정해줘야 했다.

이 작업을 하면서 블로그는 단순히 화면을 잘 만드는 것에서 끝나는 게 아니라, 검색엔진이 이해할 수 있도록 구조와 정보를 함께 정리해야 한다는 점을 알게 됐다. SEO를 막연하게 어렵게만 생각했는데, 직접 적용해보니 기본적인 설정과 색인 등록만으로도 블로그를 훨씬 더 제대로 운영하는 느낌이 들었다. 나름 재미있었다 ㅋㅋ;

메타데이터

기존에도 일부 메타데이터는 적용되어 있었지만, 이번에는 홈 화면과 포스트 상세 페이지를 기준으로 조금 더 보강하는 방향으로 정리했다.

우선 홈 화면에는 Open Graph와 Twitter 메타데이터를 추가했다.
링크를 공유했을 때 제목, 설명, 이미지가 조금 더 의도한 형태로 보이도록 하기 위한 작업이었다.

또한 공유 시 사용할 OG 이미지 도 따로 제작해 연결했다.
기존에는 이런 부분까지는 전혀 신경 쓰지 않았는데, 막상 적용해보니 블로그의 인상이나 완성도에 생각보다 큰 영향을 주는 요소라는 걸 체감했다.

*포스트 상세 페이지 * 쪽도 generateMetadata를 기준으로 메타데이터를 다시 살펴봤다.
글 제목과 설명, 썸네일이 각 포스트에 맞게 반영되도록 정리했고, 이후에는 canonical, article 타입 같은 메타데이터도 조금 더 보강할 수 있도록 방향을 잡아두었다.

이렇게 함으로써 기대하는 점

(Open Graph 메타데이터 결과물, 이제 구글에도 노출이 잘된다! 별것 아니지만 괜스레 뿌듯함..)

가장 큰 변화는 블로그가 외부에서 보여지는 방식이 조금 더 정돈된다는 점이다.
이전에는 페이지가 잘 렌더링되고 글이 잘 보이는 것에만 집중했다면, 이제는 검색엔진이나 링크 공유 환경에서도 페이지가 조금 더 의도한 방식대로 보일 수 있게 됐다.

특히 Open Graph 메타데이터와 OG 이미지를 적용하면서, 링크를 공유했을 때 제목과 설명, 이미지가 함께 정리되어 보인다는 점이 인상적이었다. 블로그처럼 글이 중심이 되는 프로젝트에서는 이런 요소도 생각보다 중요하다고 느꼈다.

검색엔진 최적화 자체를 단번에 체감하기는 어렵겠지만, 적어도 title, description, Open Graph처럼 기본이 되는 요소들을 하나씩 정리해두는 건 이후를 위해서도 의미 있는 작업이라고 생각했다.

무엇보다 좋았던 점은, 새로운 기능을 하나 더 만드는 것과는 또 다른 방식으로 프로젝트를 다듬고 있다는 느낌을 받았다는 점이다.
만드는 단계에서 끝나는 것이 아니라, 완성한 뒤에도 보완하고 정리하는 과정이 결국 프로젝트의 완성도를 높여준다는 걸 이번 작업을 통해 다시 느꼈다.

오늘 작업을 마무리하며 느낀점

GPT 넌 정말 최고야

1편에서 다루고 싶었던 내용을 적다 보니 생각보다 글이 길어져, 이어서 2편을 작성하게 되었다. 이번 편 역시 같은 흐름으로, 블로그를 개발하면서 사용했던 기술과 직접 해결했던 문제들을 중심으로 정리해보려고 한다.

어떻게 이미지를 업로드할 것인가?

Cloudflare Images는 단순한 객체 스토리지가 아니라, 업로드 요청에 대해 일회성 업로드 URL을 발급해주는 구조를 가지고 있다.

그래서 이미지를 서버로 먼저 보낸 뒤 다시 Cloudflare로 전달하는 방식이 아니라, 클라이언트가 Cloudflare에 직접 업로드를 수행하는 구조로 만들었다.

이 방식의 장점은 분명했다.

• 서버가 이미지 파일을 직접 다루지 않아 리소스 부담이 적다
• 업로드 속도가 빠르다
• 확장성 측면에서도 유리하다

즉, Next.js는 업로드 URL을 발급하는 역할만 담당하고, 실제 이미지 데이터의 흐름은 Cloudflare에 위임하는 방식이다.

1. 업로드 URL 요청하기

클라이언트가 이 API를 호출하면 Cloudflare에 Direct Upload 요청을 보내고, Cloudflare는 업로드 URL과 함께 이미지 업로드 토큰을 발급해준다. 이후 클라이언트는 해당 URL로 파일을 전송하고, Cloudflare가 이미지를 직접 저장하게 된다.

//api/upload/route.ts
export const POST = async (req: NextRequest) => {
  try {
    const fetchUrl = `https://api.cloudflare.com/client/v4/accounts/${process.env.CF_ACCOUNT}/images/v1/direct_upload`;
    const response = await (
      await fetch(fetchUrl, {
        method: req.method,
        headers: {
          "Content-Type": "application/json",
          Authorization: `Bearer ${process.env.CF_TOKEN}`,
        },
      })
    ).json();
    return NextResponse.json({
      ok: true,
      ...response.result,
    });
  } catch {
    return NextResponse.json({
      ok: false,
      error: "이미지 서버와 통신중 오류가 발생하였습니다.",
    });
  }
};

2. 발급받은 URL로 직접 업로드하기

이미지 업로드 과정은 다음과 같은 흐름으로 구성했다.

• 먼저 URL.createObjectURL(file)로 blob URL을 생성해 사용자가 즉시 이미지를 미리 볼 수 있도록 한다.
• 그와 동시에 백그라운드에서 Cloudflare 업로드 요청을 보낸다.
• 업로드가 완료되면 응답으로 받은 imageId를 기준으로 에디터 내부의 임시 이미지를 실제 이미지 URL로 치환한다.
• 이 imageId는 이후 관리 목적으로 DB에도 함께 저장한다.

아래는 해당 기능을 구현한 코드 일부이다.

// 이미지 업로드 이벤트
const onUploadImgEvt = useCallback(async (file: File) => {
  if (!editorView) return;
  editorView?.focus();

  // 📌 1단계: blob URL로 임시 이미지 표시
  const imgURL = URL.createObjectURL(file);
  const placeholder = `![업로드중](${imgURL})`;
  editorView.dispatch(editorView.state.update(editorView.state.replaceSelection(placeholder)));

  try {
    // 📌 2단계: 업로드 URL 발급 요청
    const { uploadURL } = await (await fetch(`/api/upload`, { method: "POST" })).json();

    const form = new FormData();
    form.append("file", file, `${process.env.NODE_ENV}_simpleblog_${timeStamp()}`);

    // 📌 3단계: Cloudflare에 직접 업로드
    const {
      result: { id },
    } = await (await fetch(uploadURL, { method: "POST", body: form })).json();

    // 📌 4단계: Cloudflare URL로 치환
    const deliveryURL = getDeliveryDomain(id, "public");
    const cursor = new SearchCursor(editorView.state.doc, placeholder);
    cursor.next();
    editorView.dispatch({
      changes: { from: cursor.value.from, to: cursor.value.to, insert: `![](${deliveryURL})` },
    });

    // DB 저장
    imageMutate.mutate({ imageId: id });

  } catch {
    openToast(true, "이미지 업로드중 실패하였습니다", 1);
  }
}, [editorView]);

3. 이미지 정리?

이미지를 업로드한 뒤 글을 삭제하면, 이미지 파일은 저장소에 그대로 남게 된다. 이런 파일들을 방치하면 계속 쌓이기만 하고 비용만 발생하는, 이른바 고아 이미지(Orphan Image)가 생기게 된다.

운영을 고려하면 이 문제는 반드시 자동으로 관리할 필요가 있었다.

그래서 이미지와 게시글의 관계를 Prisma에서 다음과 같이 설정했다.

• Post가 삭제될 경우 → 연결된 Image 레코드도 자동 삭제 (onDelete: Cascade)
• Image가 삭제될 경우 → Cloudflare Image 삭제 API도 함께 호출

하지만 여기서 또 다른 문제가 있었다.

이미지와 게시글의 관계를 DB 차원에서 잘 관리하더라도, 실제 이미지를 삭제하는 작업은 Cloudflare API 요청으로 수행된다. 그렇다면 해당 요청이 실패하면 어떻게 될까?

• 임시글을 삭제했는데 API 에러가 발생한 경우
• 에디터에서 이미지를 교체했는데 이전 이미지 삭제가 누락된 경우
• 예기치 못한 네트워크 장애로 API 호출이 실패한 경우

이런 경우 DB에서는 이미지 정보가 사라졌더라도, Cloudflare 저장소에는 파일이 그대로 남게 된다. 즉, 또 다른 형태의 고아 이미지가 생기는 셈이다.

다행히도 Vercel의 Cron Job을 활용하면, 이런 고아 이미지를 주기적으로 정리할 수 있었다.

정리 흐름은 다음과 같다.

1. DB에서 사용 중인 모든 imageId 목록을 수집
2. Cloudflare 저장소에 있는 이미지 목록과 비교
3. 일정 시간 이상 DB에 존재하지 않는 imageId를 탐색
4. 해당 이미지를 Cloudflare API로 삭제 요청

즉, 정리 스케줄러를 통해 미처 지워지지 못한 고아 이미지도 시간이 지나면 자동으로 정리되도록 만들었다.

인증과 인가는 어떻게?

1. 인증

처음에는 NextAuth의 Credentials Provider를 사용해 DB에 사용자 정보를 저장하고, 직접 로그인 기능을 구현하는 방식도 고려했다.

하지만 회원 정보와 비밀번호를 직접 관리해야 한다는 점이 생각보다 부담으로 느껴졌다. 개인 프로젝트에서는 인증 시스템 자체를 깊게 구현하는 것보다 핵심 기능 개발에 더 집중하는 편이 낫다고 판단했고, 그 결과 카카오 OAuth 로그인을 선택하게 됐다.

비밀번호 저장과 검증 로직을 직접 다루지 않아도 된다는 점에서 훨씬 간편했고, 이미 검증된 인증 흐름을 활용할 수 있다는 점에서도 만족스러웠다. 결과적으로 개인 프로젝트에서는 인증 기능을 직접 구현하는 것보다, 검증된 방식을 활용해 빠르게 적용하는 쪽이 더 잘 맞는 선택이었다.

추가로 signIn 콜백을 활용해 특정 계정만 로그인할 수 있도록 제한하면서, 개인 프로젝트에 맞는 최소한의 접근 제어도 함께 적용했다.

//next-option
callbacks: {
  jwt: ({ token, user }) => {
    return { ...token, ...user };
  },
  signIn: async (params) => {
    const { email } = params.user;

    if (isDemo) {
      // 데모 모드에서는 누구나 허용
      return true;
    }
    if (email === "내 카카오톡 아이디") {
      return true;
    }

    return false;
  },
},

2. 인가

인가는 로그인한 사용자가 어디까지 접근할 수 있는지를 구분하는 방식으로 구현했다.

블로그 특성상 방문자와 로그인한 사용자가 완전히 같은 화면을 볼 필요는 없었고, 특히 수정이나 삭제 같은 기능은 관리자만 사용할 수 있어야 했다. 이를 위해 NextAuth에서 제공하는 useSession을 활용해 현재 로그인 상태를 확인하고, 세션 정보가 존재할 때만 특정 UI가 노출되도록 처리했다.

방문자는 게시글을 조회하는 기능만 사용할 수 있고, 로그인한 경우에는 수정 및 삭제 같은 관리 기능까지 접근할 수 있도록 분기했다. 복잡한 권한 체계를 두기보다는, 개인 프로젝트에 맞게 인증 여부를 기준으로 필요한 기능만 구분하는 방식이 더 적절하다고 판단했다.

//예시
const { data: session } = useSession();

{session && (
  <div>
    <button>수정</button>
    <button>삭제</button>
  </div>
)}

3. API 보호

인가 처리를 단순히 화면 분기에만 맡기지는 않았다. 수정이나 삭제 버튼을 숨기더라도, 사용자가 직접 API를 호출하는 방식으로 요청을 보낼 수 있기 때문이다.

그래서 Next.js에서 제공하는 middleware를 활용해 인증이 필요한 페이지와 API 요청을 함께 보호했다. getToken을 통해 현재 요청에 토큰이 존재하는지 확인하고, 토큰이 없는 경우에는 보호된 페이지 접근을 로그인 페이지로 리다이렉트하도록 처리했다.

또한 인증되지 않은 상태에서 들어오는 POST, DELETE 요청은 일부 예외 API를 제외하고 차단해, 데이터 변경이 발생하는 요청 자체를 제한했다.

이를 통해 단순히 화면에서 기능을 숨기는 수준을 넘어, 실제 요청 단계에서도 인증되지 않은 접근을 막을 수 있었다. 개인 프로젝트에서는 모든 요청에 복잡한 권한 체계를 두기보다, 꼭 필요한 페이지와 API만 선별적으로 보호하는 방식이 더 적절하다고 느꼈다.

//middleware.ts
import { getToken } from "next-auth/jwt";
import { NextRequest, NextResponse } from "next/server";

export async function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;
  const token = await getToken({ req: request, secret: process.env.SECRET });

  const protectedPages = ["/write", "/setting", "/temp"];

  if (protectedPages.some((page) => pathname.startsWith(page)) && !token) {
    return NextResponse.redirect(new URL("/auth/signin", request.url));
  }

  if (
    !token &&
    (request.method === "POST" || request.method === "DELETE") &&
    !pathname.startsWith("/api/auth") &&
    !(request.method === "POST" && pathname.startsWith("/api/comments")) &&
    !(
      request.method === "POST" &&
      pathname.startsWith("/api/post/") &&
      pathname.endsWith("/view")
    )
  ) {
    return NextResponse.json(
      { error: "API 접근 권한이 없습니다." },
      { status: 401 }
    );
  }

  return NextResponse.next();
}

export const config = {
  matcher: [
    "/api/:path*",
    "/((?!_next/static|_next/image|favicon.ico|auth/signin).*)",
  ],
};

변경된 테일윈드?

1. v3에서 v4 달라진 점

처음에 언급했던 것처럼 스타일링에는 Tailwind CSS를 사용했다. 다만 작업하면서 조금 헷갈렸던 부분은 v3에서 v4로 넘어오며 설정 방식이 꽤 많이 달라졌다는 점이었다.

2. 신경 쓴 점

이전 프로젝트에서는 테마를 명확하게 정의하지 않은 채 스타일을 그때그때 작성하는 경우가 많았다. 그 과정에서 자주 사용하던 값조차 다시 찾게 되거나, 비슷한 색상과 스타일이 조금씩 다르게 반복되는 일도 있었다. 결과적으로 전체적인 UI 일관성도 아쉬움이 남았다.

이번 프로젝트에서는 이런 문제를 줄이기 위해 @theme를 중심으로 폰트, 컬러, 브레이크포인트 등을 미리 정리해두고 사용하는 방식으로 바꿨다. 특히 라이트 모드와 다크 모드에서 반복적으로 사용되는 값들을 공통 변수로 관리하면서, 스타일을 조금 더 체계적으로 다룰 수 있도록 신경 썼다.

완벽하다고 보기는 어렵지만, 이전보다 훨씬 명확한 기준 안에서 스타일을 작성할 수 있었다는 점에서 의미가 있었다.

@theme {
  --font-sans: var(--font-pretendard), system-ui, sans-serif;
  --color-background1: #fff;
  --color-text1: #212529;
  --breakpoint-sm: 768px;
}

.dark {
  --color-background1: #1e1e1e;
  --color-text1: #ececec;
}

배운것과 까다로웠던 것

[!NOTE] 이번 프로젝트를 진행하면서 페이지 라우팅 구조나 렌더링 방식도 고민이 많았지만, 가장 시간을 많이 쓴 부분은 여러 화면에서 공통으로 사용하는 Provider와 공통 컴포넌트를 설계하는 일이었다.

이전 프로젝트에서는 필요한 기능을 그때그때 붙이는 식으로 작업하는 경우가 많았다. 하지만 이번에는 페이지 수가 늘어나고 여러 화면에서 반복적으로 사용하는 기능도 많아지면서, 처음부터 구조를 조금 더 신경 써야겠다는 생각이 들었다. 특히 공통적으로 사용되는 UI와 데이터 처리 로직을 어떻게 정리할지가 꽤 중요한 고민이었다.

1. 공통적으로 사용되는 기능을 어떻게 분리할지

프로젝트를 만들면서 가장 먼저 든 생각은, 여러 화면에서 반복적으로 사용되는 공통 UI와 데이터 처리 패턴이 생각보다 많다는 점이었다. 페이지마다 비슷한 구조를 각각 구현하기보다, 자주 쓰이는 기능은 미리 분리해두는 편이 이후 유지보수나 확장에 더 유리하다.

자주 쓰이는 패턴 예시는 다음과 같았다.

이렇게 나누어두니 페이지 컴포넌트는 화면 자체에 더 집중할 수 있었고, 공통 기능은 별도의 레이어에서 일관되게 관리할 수 있어 전체 구조도 훨씬 명확해졌다.

2. 가장 어려웠던 부분은 범용적으로 동작하는 타입 설계였다

타입스크립트는 타입을 좁혀 실수를 방지해주지만, 그만큼 까다로운 부분도 있다. 공통 구조를 만드는 과정에서 가장 어려웠던 부분은 단순히 기능을 동작하게 만드는 것이 아니라, 여러 화면에서 문제없이 재사용할 수 있도록 타입을 맞추는 작업이었다.

예를 들어 모달은 종류마다 필요한 props가 달랐고, 무한 스크롤도 게시글, 댓글, 임시글, 컬렉션처럼 서로 다른 데이터를 공통된 방식으로 처리해야 했다.

// 인피니트 스크롤 컴포넌트 타입 예시
type DataType = "post" | "temp" | "comments" | "relatedPosts" | "collections";

이처럼 데이터 종류를 나누고, 각 타입에 맞는 fetcher와 렌더링 방식을 연결하는 과정이 생각보다 까다로웠다. 한 화면에서만 쓰는 코드였다면 훨씬 단순하게 만들 수 있었겠지만, 공통 구조는 어디서든 안정적으로 동작해야 했기 때문에 초반 설계에 시간을 많이 쓸 수밖에 없었다.

구현보다 설계가 더 어려웠던 이유는 “지금 한 번만 동작하면 되는 코드”가 아니라 “앞으로도 계속 재사용될 코드”를 만들어야 했기 때문이다.

3. 전역 UI는 편하게 쓰는 대신 내부 구조는 더 신경 써야 했다

UIProvider와 PopupContainer를 중심으로 한 전역 UI 구조는 토스트와 모달을 어디서든 공통된 방식으로 사용할 수 있도록 하기 위해 만든 구조였다. 사용하는 쪽에서는 비교적 간단하게 호출할 수 있지만, 내부에서는 모달 종류별 분기, Promise 기반 제어, 라우트 변경 시 정리 같은 부분까지 고려해야 했다.

즉, 바깥에서 보기에는 편한 구조일수록 안쪽 설계는 오히려 더 꼼꼼해야 한다는 점을 많이 느꼈다.

openModal<T extends ModalType>(
  type: T,
  props: ModalPropsMap[T]
): Promise<unknown>

이런 식으로 타입을 연결해두지 않으면, 나중에 모달 종류가 늘어날수록 사용하는 쪽도 불안정해질 수 있었다. 처음에는 꽤 번거로웠지만, 한 번 구조를 잡고 나니 이후에는 공통된 방식으로 계속 확장할 수 있다는 점이 확실한 장점이었다.

4. 처리 구조를 공통화해두니 이후 작업이 훨씬 편했다

게시글 목록, 관련 글, 댓글, 임시글처럼 비슷한 패턴이 반복될 가능성이 높았기 때문에, 이를 하나의 공통 인피니트 스크롤 컴포넌트로 정리해두는 편이 더 낫다고 판단했다.

그 결과 이후에는 새로운 리스트 화면이 생겨도 기존 구조 안에서 타입과 렌더링, 페칭만 추가하면 되었고, 비슷한 로직을 매번 새로 작성하는 부담도 줄일 수 있었다.

결과적으로 초반에는 설계와 타입 정리에 시간이 꽤 많이 들었지만, 프로젝트를 업데이트할수록 그 선택이 훨씬 효율적이었다고 느꼈다. 실제로 새로운 기능을 붙이거나 화면을 확장할 때 훨씬 빠르게 대응할 수 있었기 때문이다.

5. Provider를 역할에 맞게 나눠 사용하니 편리했다.

이번 프로젝트에서는 Provider를 전역용과 페이지 내부용으로 나눠 사용했다. 토스트나 모달처럼 여러 화면에서 공통으로 쓰는 기능은 전역 Provider로, write 페이지처럼 내부 상태와 데이터 처리가 많은 부분은 별도 Provider로 분리했다.

이렇게 나누니 상태의 범위가 명확해졌고, 공통 기능과 페이지 전용 로직도 덜 섞이게 됐다. 특히 관련 상태와 함수를 한곳에 모아둘 수 있어서, 구현과 수정이 훨씬 수월했다.

6. API를 다루면서 느낀것이 많다

이번 프로젝트에서는 API를 직접 다루는 과정도 꽤 까다로웠다. 프론트엔드에 비해 API 설계는 익숙하지 않았기 때문에, 데이터 형식이나 에러 응답 형식을 맞추는 부분에서 시행착오가 많았다.

특히 화면에서는 응답 형태를 기준으로 데이터를 보여주고 오류를 처리해야 하기 때문에, API마다 반환 형식이 다르면 사용하는 쪽도 함께 복잡해질 수밖에 없었다. 이번 작업을 하면서 성공 응답과 에러 응답을 어느 정도 공통된 형태로 맞춰두는 것이 생각보다 중요하다는 점을 배웠다.

다음에 비슷한 풀스택 사이드 프로젝트를 하게 된다면, 기능 구현에 앞서 API 규격부터 조금 더 명확하게 설계하는 쪽으로 진행하고 싶다.

마무리하며

이번 포스팅은 프로젝트를 다시 돌아보는 기록에 가까웠다. 만들면서 바로 정리한 것이 아니다 보니, 중간중간 빠뜨린 부분도 있었고 기억이 흐릿한 부분도 있었다.

그래도 글을 쓰면서 내가 어떤 부분을 고민했고, 어디에 시간을 많이 쏟았는지를 다시 확인할 수 있었다. 막연하게 지나갔던 작업들도 정리해보니 분명한 이유와 흐름이 있었고, 그 과정에서 새롭게 알게 된 점도 적지 않았다.

완벽하게 정리된 글은 아닐 수 있지만, 이번 포스팅을 통해 프로젝트를 한 번 더 돌아보고 스스로를 점검해볼 수 있었다는 점에서 충분히 의미가 있었다.

알고리즘 문제를 풀다 보면 처음엔 DP나 이분탐색처럼 뭔가 거창한 로직이 필요할 것 같았는데, 의외로 지금 당장 가장 좋은 선택을 하는 것만으로 풀리는 문제들도 꽤 많았다. 이런 유형이 바로 그리디(Greedy) 이다.

처음에는 나도 그리디를 보면 좀 애매했다. 이게 진짜 맞는 선택인가? 지금 최선이 나중에도 최선이 맞나? 이런 생각 때문에 오히려 어렵게 느껴졌다.

이번 글에서는 코딩 테스트에서 자주 등장하는 그리디 패턴이 어떤 느낌인지, 그리고 어떤 문제에서 떠올려야 하는지를 예시와 함께 정리해보려고 한다.

그리디란?

정말 단순하다. 그리디는 상남자처럼 매 순간 가장 좋아 보이는 선택을 하는 방식이다.

즉,

지금 당장 이득이 가장 큰 선택을 하고 그 선택을 계속 이어가며 최종 답을 만드는 방식

핵심은 매 선택이 미래까지 포함해서도 문제를 깨지 않아야 한다는 점이다. 그래서 모든 문제를 그리디로 풀 수 있는 건 아니고, 지금의 최선이 전체 최선으로 이어지는 구조 가 있어야 한다.

왜 그리디가 어려운가?

그리디는 구현 자체는 단순한 경우가 많다. 근데 어려운 건 구현이 아니라 이 문제를 그리디로 봐도 되는지 판단하는 것이다.

예를 들어,

• 당장 가장 커 보이는 값을 고른다
• 당장 가장 빨리 끝나는 걸 고른다
• 당장 가장 작은 비용을 선택

이런 선택이 항상 정답이 되는 건 아니다.

그래서 그리디 문제는 보통 왜 이 선택이 맞는가? 를 한 번 납득해야 한다.

예제로 살펴보기

이번에도 LeetCode 예제로 정리해보려고 한다. 그리디는 문제를 많이 볼수록 아 이런느낌인가? 하고 감이 오는 것 같다.

Assign Cookies (Easy)

문제) 아이들의 만족도와 쿠키 크기가 주어질 때, 최대 몇 명의 아이를 만족시킬 수 있는지 구하라.

예를 들어 아이의 만족도: [1,2,3] 쿠키 크기: [1,1]

라면, 만족도 1인 아이만 만족시킬 수 있으니 정답은 1 이다.

// 가장 작은 아이부터, 줄 수 있는 가장 작은 쿠키를 준다.
var findContentChildren = function(g, s) {
    g.sort((a, b) => a - b);
    s.sort((a, b) => a - b);

    let i = 0; // child
    let j = 0; // cookie

    while (i < g.length && j < s.length) {
        if (s[j] >= g[i]) {
            i++;
        }
        j++;
    }

    return i;
};

이 문제는 그리디의 대표적인 느낌이 잘 보인다. 가장 만족도가 작은 아이부터 처리하고, 그 아이를 만족시킬 수 있는 가장 작은 쿠키를 주는 게 핵심이다.

처음엔 큰 쿠키를 먼저 쓰면 안 되나? 싶었는데, 그러면 작은 아이한테 큰 쿠키를 낭비할 수 있어서 오히려 손해였다.

즉, 작은 요구는 작은 자원으로 해결하는 게 이득 이다.

Best Time to Buy and Sell Stock II (Medium)

문제) 주식 가격이 주어질 때, 여러 번 거래할 수 있다면 얻을 수 있는 최대 이익을 구하라.

// 오를 때마다 그 차익을 모두 더하면 된다.
var maxProfit = function(prices) {
    let profit = 0;

    for (let i = 1; i < prices.length; i++) {
        if (prices[i] > prices[i - 1]) {
            profit += prices[i] - prices[i - 1];
        }
    }

    return profit;
};

이 문제도 처음 보면 언제 사고 언제 팔아야 최대지? 하면서 어렵게 생각하게 된다.

근데 잘 보면 1 -> 3 -> 5 처럼 계속 오르는 구간은 결국 5 - 1 이익과 (3 - 1) + (5 - 3) 이익이 같다.

그래서 오르는 구간의 이익을 전부 더해도 최종 최대 이익과 같다.

이 문제를 풀면서 느낀 건, 그리디는 가끔 문제를 쪼개서 생각하면 갑자기 쉬워진다는 점이다. 한 번의 완벽한 거래를 찾으려 하지 말고, 그냥 지금 오르면 먹는다 라고 보면 된다.

Jump Game (Medium)

문제) 배열의 각 원소는 현재 위치에서 점프할 수 있는 최대 거리일 때, 마지막 인덱스까지 도달 가능한지 판단하라.

// 지금까지 도달 가능한 가장 먼 위치만 관리
var canJump = function(nums) {
    let farthest = 0;

    for (let i = 0; i < nums.length; i++) {
        if (i > farthest) return false;
        farthest = Math.max(farthest, i + nums[i]);
    }

    return true;
};

이 문제는 처음에 나도 DFS나 DP 느낌으로 생각할 수 있을 것 같았는데, 막상 핵심은 단순했다.

현재 위치까지 올 수 있다면, 여기서 갈 수 있는 가장 먼 위치를 계속 갱신하면 된다.

즉,

• 지금 인덱스가 이미 도달 불가능한 위치면 실패
• 아니면 i + nums[i] 로 갈 수 있는 범위를 계속 늘린다

이 문제를 보고 나서 그리디의 느낌이 조금 더 명확해졌다. 모든 경로를 다 볼 필요 없이, 지금까지 만들 수 있는 최선의 범위 만 추적하면 되는 경우가 있다.

그리디 문제를 언제 떠올려야 하는가?

다음과 같은 느낌이 보이면 그리디를 의심해볼 수 있다.

• 최대한 많은 개수
• 최소 횟수 / 최소 비용
• 지금 선택이 이후 선택에 영향을 주는 구조
• 정렬 후 앞에서부터 처리
• 현재 상태에서 가장 이득인 선택

특히 이런 문제들이 많다.

• 회의실 배정
• 구간 선택
• 주유소 / 점프 / 배정 문제
• 동전 문제(일부 조건에서만)
• 정렬 후 순서대로 결정하는 문제

그리디 문제를 많이 풀다 보면 정렬 + 순차 처리 조합이 진짜 자주 나온다는 걸 느끼게 된다.

그리디의 핵심은?

내가 느낀 그리디의 핵심은 이거였다.

지금 당장 최선처럼 보이는 선택을 해도, 나중에 후회하지 않는가?

이걸 확인할 수 있으면 그리디고, 그걸 확신할 수 없으면 보통 DP나 다른 접근을 봐야 한다.

그래서 그리디는 막연히 대충 좋아 보이는 거 고르는 것 이 아니라, 근거 있게 포기하고, 근거 있게 선택하는 방식 에 가깝다.

마무리

그리디는 처음엔 쉬워 보이는데 오히려 그래서 더 헷갈렸다. 구현은 짧은데, 왜 이게 정답이지? 를 설명하려고 하면 막히는 경우가 많았다.

특히 나 같은 경우는 문제를 보면 괜히 복잡하게 생각하는 습관이 있어서, 그리디 문제도 처음엔 DP처럼 보려고 했던 적이 많았다. 근데 몇 문제 풀어보니 정렬하고, 지금 가능한 최선의 선택을 쌓아간다 이 흐름이 보이기 시작했다.

아직도 낯선 문제를 보면 바로 그리디라고 확신하긴 어렵지만, 적어도 이제는 이거 혹시 정렬하고 앞에서부터 처리하는 문제 아닌가? 정도는 먼저 떠올려보게 된 것 같다.

역시 알고리즘은 많이 틀려보고, 왜 틀렸는지 정리하면서 익숙해지는 게 제일 중요한 것 같다. 많이 풀어봤어도 아직도 많이 어렵다 ㅋㅋ;

알고리즘 문제를 풀다 보면 스택(Stack) 을 사용하는 문제를 정말 자주 접하게 된다. 처음에는 “괄호 검사할 때 쓰는 자료구조” 정도로만 생각했는데, 문제를 많이 풀어보니 스택은 훨씬 더 다양한 방식으로 등장했다. 이번 글에서는 코딩 테스트에서 자주 등장하는 스택 패턴을 실제 문제 예시와 함께 정리해보려고 한다.

스택이란?

1. 기본 개념

스택은 LIFO (Last In, First Out) 구조이다.

• push → 맨 위에 추가
• pop → 맨 위에서 제거
• top → 맨 위 값 확인

가장 최근에 들어온 값부터 처리한다는 점이 핵심이다.

2. 왜 스택을 쓰는가?

스택은 단순히 “저장하는 용도”가 아니라,

이전 값들과 현재 값을 빠르게 비교하고 정리하는 도구 로 사용된다.

특히 이런 상황에서 자주 쓰인다.

• 현재 값이 이전 값보다 크거나 작은 경우
• 어떤 조건이 깨질 때까지 이전 값들을 정리해야 하는 경우
• 다시 돌아올 수 있는 값인지 판단해야 하는 경우

예제로 살펴보기

프로그래머스도 좋지만 LeetCode가 굉장히 문제은행? 같은 느낌으로 난이도별로 나열이 잘 되어있었기에 LeetCode 예제로 스택을 살펴보려고한다.

Valid Parentheses(Easy)

문제) 괄호 문자열이 올바른지 판단하라. ()[]{} → true (] → false

// 가장 최근에 열린 괄호부터 닫혀야 한다 → LIFO 구조
var isValid = function(s) {
    let stack = [];
    let map = {
        ')': '(',
        '}': '{',
        ']': '['
    };

    for (let char of s) {
        if (char === '(' || char === '{' || char === '[') {
            stack.push(char);
        } else {
            if (stack.length === 0) return false;
            let top = stack.pop();
            if (top !== map[char]) return false;
        }
    }

    return stack.length === 0;
};

이 문제는 진짜 쉬웠다.

Daily Temperatures(Midium)

문제) 각 날짜마다 더 따뜻해지는 날까지 며칠 걸리는지 구하라.

입력: [73,74,75,71,69,72,76,73] 출력: [1,1,4,2,1,1,0,0]

//각 인덱스는 push 1번, pop 1번 → O(N)
//“다음 큰 값” 유형의 대표 문제
var dailyTemperatures = function(temperatures) {
    let stack = [];
    let answer = new Array(temperatures.length).fill(0);

    for (let i = 0; i < temperatures.length; i++) {

        while (
            stack.length &&
            temperatures[stack[stack.length - 1]] < temperatures[i]
        ) {
            let prevIndex = stack.pop();
            answer[prevIndex] = i - prevIndex;
        }

        stack.push(i);
    }

    return answer;
};

아.. 이문제는 푸는데 생각보다 꽤 걸렸다. 멍청하게도 Index를 Stack에 저장해서 쓴다는 아이디어를 생각하지 못했다. 30분넘게 끙끙거리다 GPT한테 힌트를 얻으니 금방 풀렸던 문제였다.

Remove Duplicate Letters(Midium)

문제) 중복 문자를 제거하면서 사전순으로 가장 작은 문자열 만들기.

//더 작은 문자가 나오면 이전 문자를 제거할지 판단
//단, 그 문자가 나중에 다시 등장해야 제거 가능

var removeDuplicateLetters = function(s) {
    let stack = [];
    let seen = new Set();
    let lastIndex = {};

    // 각 문자의 마지막 등장 위치 저장
    for (let i = 0; i < s.length; i++) {
        lastIndex[s[i]] = i;
    }

    for (let i = 0; i < s.length; i++) {
        let char = s[i];

        if (seen.has(char)) continue;

        while (
            stack.length &&
            stack[stack.length - 1] > char &&
            lastIndex[stack[stack.length - 1]] > i
        ) {
            seen.delete(stack.pop());
        }

        stack.push(char);
        seen.add(char);
    }

    return stack.join('');
};

처음에 풀 땐 stack.indexOf(char)로 이미 들어간 문자인지 확인하고, substr로 잘라내는 방식을 반복했다. 이렇게 하니 정답은 통과했지만 런타임이 좋지 않았다. GPT에게 물어보니 Set이나 Map을 활용해 인덱스를 O(1)로 체크하면 성능을 개선할 수 있다고 했고, 실제로 33ms 정도 나오던 코드가 11ms 수준으로 줄어들었다.

스택 문제를 언제 떠올려야 하는가?

다음과 같은 문장이 보이면 스택을 의심해볼 수 있다:

• 다음에 더 큰 값
• 이전 값과 비교”
• 조건이 깨질 때까지 제거”
• 사전순으로 가장 작은 결과”
• 중복 제거”

특히 “다음 큰 값”, “이전 작은 값” 이런 표현이 나오면 거의 스택 문제다. 스택 문제의 핵심은 단순하다. 지금 상태를 더 좋게 만들기 위해, 이전 상태를 정리한다 그래서 대부분 O(N)으로 해결된다.

마무리

스택이 가장 쉽고 자신있었던 파트였는데 살짝 문제를 꼬아버리면 어렵게 느껴졌다. 특히 인덱스를 저장해서 사용하는 방법 이런 아이디어 요소들이 부족했던 것 같다. 아직 완벽하진 않지만, 이런 패턴들을 하나씩 정리해가면서 점점 더 빠르게 문제를 인식할 수 있게 되는 것 같다. 앞으로도 자주 틀리고, 또 정리하면서 익숙해져보려고 한다. 솔직히 한글이 제일 어렵다.. 책 좀 읽자

Umami는 오픈소스로 제공되는 웹 분석(Analytics) 도구다. 웹사이트에 방문자 수, 페이지 조회 수, 유입 경로 같은 기본적인 트래픽 데이터를 수집해서 대시보드 형태로 보여준다.

상용 분석 서비스들과 달리 구조가 단순하고 가벼워서, 복잡한 마케팅 분석보다는 “내 사이트에 사람이 얼마나 오는지” 같은 기본 지표를 확인하는 데 잘 어울린다. 또한 개인정보 수집을 최소화하는 방향으로 설계되어 있어서, 개인 프로젝트나 작은 사이트에 부담 없이 붙이기 좋다는 점도 특징이다

Why Umami?

내 블로그에 DB 테이블을 따로 만들어 방문자 수를 집계할 수도 있었지만, 숫자만 쌓이는 방식보다는 직관적으로 얼마나 사람들이 들어오는지 한눈에 보고 싶었다.

여러 분석 도구들이 있었지만, 내가 중요하게 본 기준은 딱 두 가지였다. 무료일 것, 그리고 설정이 복잡하지 않을 것.

처음에는 Google Analytics도 함께 고려했다. 워낙 널리 쓰이는 서비스라 기능도 강력하고 참고할 자료도 많아서 좋아 보였다.

하지만 막상 적용하려고 보니 설정 과정이 생각보다 복잡하게 느껴졌다. 계정 구조나 속성 설정, 추적 코드 방식도 여러 단계로 나뉘어 있어서 가볍게 시작하기엔 조금 부담이 있었다. “일단 방문자 수만 확인하고 싶다”는 내 목적에 비해 기능이 너무 많다는 느낌도 들었다.

그래서 방향을 바꿔, 더 단순하고 바로 사용할 수 있는 도구를 찾게 됐고, 그때 선택한 게 Umami였다.

Umami의 효능..

Umami는 기능이 많은 분석 도구는 아니지만, 개인 프로젝트에서 쓰기엔 딱 필요한 것들만 갖추고 있다.

주요 기능

기본 트래픽 분석

• 페이지뷰(Pageviews) — 각 페이지의 조회 수 통계
• 유니크 방문자(Visitors) — 중복 제거된 방문 수 확인
• 이탈률(Bounce Rate)
• 평균 세션 시간(Session Duration)
• 유입 경로(Referrers) — 어디서 트래픽이 들어왔는지 확인
• 기기 / 브라우저 / 운영체제 / 국가 등 방문 환경 정보 확인 가능

커스텀 이벤트 추적 (Events)

Umami는 기본 pageview 외에도 사용자 정의 이벤트를 기록할 수 있다.

HTML 속성 기반 이벤트

<button data-umami-event="signup_click">Sign up</button>

JavaScript 기반 이벤트

if (window.umami) {
  window.umami.track('post_view', {
    postId
  });
}

커스텀 이벤트는 대시보드에서 이벤트별로 집계/조회 가능하며,
이벤트 속성(Properties)도 함께 확인할 수 있다.

자동 추적 vs 수동 추적

• 기본 설정에서는 페이지 방문 시 자동으로 pageview가 수집됨
• data-auto-track="false" 옵션을 사용하면 자동 수집을 끄고
  원하는 시점에만 이벤트를 보내는 수동 트래킹 방식 사용 가능

실시간 & 인터페이스

• 실시간 방문 현황(Realtime) 확인 가능
• 복잡하지 않은 직관적인 대시보드 UI 제공

기타 특징

• 경량 추적 스크립트 — 사이트 성능에 부담이 적음
• 다중 사이트 지원 — 하나의 Umami 인스턴스로 여러 사이트 분석 가능
• 프라이버시 친화적 설계 — 개인정보 최소 수집, 쿠키 없이 동작

사용법

https://cloud.umami.is/login (Umami 사이트) 사용법은 무지무지 간단하다. 영알못인 나도 그냥 슉슉샥샥?으로 끝내버릴수 있었다.

1. 위에 링크를 타고 들어가서 Sign Up 을 하고 이메일 인증을 통해 계정을 만들어준다

2. 그리고 이런식으로 단순하게 Add Website 버튼을 클릭하여 간단하게 폼을 입력해주고 save버튼을 클릭하여 사이트를 추가하면 된다

3. 만들어진 아이템을 클릭하여 우측상단에 Edit버튼을 클릭해준다. 그리고 WebSite ID를 복사해준다

4. 아래 코드처럼 사용하고자하는 프로젝트에 넣어준다 (아래는 Next.js환경)

//next.js
<Script
 src="https://cloud.umami.is/script.js"
      data-website-id={process.env.NEXT_PUBLIC_UMAMI_WEBSITE_ID}
      strategy="afterInteractive" />

5. 끝 이제 마음껏 확인해보면 된다

결과물

위에 이미지처럼 통계를 확인할수 있다.

기본 스크립트만 사용할 경우, 사용자가 어떤 페이지를 방문하든 모두 자동으로 페이지뷰로 집계된다. 전체적인 방문자 수를 보는것도 좋지만 “어떤 글이 실제로 조회됐는지”를 알고 싶었다.

그래서 Umami의 Events 기능을 활용해 글 조회 시점에만 직접 이벤트를 보내도록 처리했다. 글 페이지가 렌더링된 뒤에 아래와 같이 커스텀 이벤트를 호출하는 방식이다.

if (window.umami) {
  window.umami.track("post_view", {
    postId,
    slug: postData?.data.slug,
  });
}

이렇게 하면 단순한 페이지 진입이 아니라, 실제로 특정 게시글이 열렸을 때만 위에 두번째 이미지처럼 post_view 이벤트가 기록된다. 또한 postId와 slug 같은 정보를 함께 넘겨서, 어떤 글이 얼마나 조회됐는지까지 구분해서 확인할 수 있도록 했다.

덕분에 단순 트래픽 수치가 아니라, 콘텐츠 단위의 조회 데이터를 볼 수 있게 되었고 어떤 글이 관심을 받는지도 파악할 수 있었다.

마무리

처음에는 다른 블로그들처럼 그냥 따라 붙여본 느낌이었는데, 막상 적용하고 나니 생각보다 자주 들여다보게 된다. 숫자가 많고 적고를 떠나서, 누군가 실제로 글을 읽고 갔다는 흔적이 남는다는 게 은근한 동기부여가 됐다. 작은 기능이지만 프로젝트에 생동감을 더해준 요소였던 것 같다.

사이드 프로젝트로 블로그를 만들던중에 태그 자동완성 기능이 있었는데, 태그 자동완성을 붙이다보니 타이핑할 때마다 쿼리가 너무 많이 날라가 문제가 생겼다.

1. 기존 문제

컴포넌트인 TagInput은 컨트롤드 인풋이고, 입력이 바뀔 때마다 useQuery가 실행된다.

// 태그입력 자동완성 쿼리
const { data: tagData, isLoading } = useQuery<
  QueryResponse<{ body: string }[]>
>({
  queryKey: ["tag", input],
  queryFn: async () => {
    const q = input.trim();
    if (q.length < 2) return { data: [] };

    const res = await fetch(
      `/api/tag/search?q=${encodeURIComponent(q)}`
    );
    return res.json();
  },
  enabled: input.trim().length >= 2,
});

문제점

• input은 매 키 입력마다 즉시 변경
• useQuery는 queryKey가 바뀌면 바로 실행
• 결과적으로 타이핑 속도 = API 호출 속도, 비효율적

2. useDeferredValue 사용하여 해결

//useDeferredValue 훅 사용
const deferredInput = useDeferredValue(input);

const { data: tagData, isLoading } = useQuery<
  QueryResponse<{ body: string }[]>
>({
  queryKey: ["tag", deferredInput],
  queryFn: async () => {
    const q = deferredInput.trim();
    if (q.length < 2) return { data: [] };

    const res = await fetch(
      `/api/tag/search?q=${encodeURIComponent(q)}`
    );
    return res.json();
  },
  enabled: deferredInput.trim().length >= 2,
});

달라진 점

• input은 그대로 즉시 업데이트
• 쿼리는 조금 늦은 값 기준으로만 실행
• 중간 입력 단계들이 자연스럽게 스킵됨

결과적으로 “입력 UX”와 “네트워크 요청”이 분리 되었다.

useDeferredValue?

위에 코드처럼 useDeferredValue를 사용하여 해결하였는데, 어떻게 해결이 된것일까?

useDeferredValue는 값을 즉시 바꾸는 훅이 아니고, 이미 변경된 값을 조금 늦게 소비할 수 있게 해주는 훅에 가깝다. 사용할땐 값을 래핑해서 사용한다.

const deferredInput = useDeferredValue(input);

이 코드는 input을 지연시키는 게 아니라, input의 느린 버전(slower copy)을 하나 더 만들어 준다.

그래서 동작 방식은 이렇다. input은 타이핑과 동시에 바로 업데이트되고 deferredInput은 React가 판단한 여유 있는 시점에 따라온다. 이 덕분에 입력 UX는 그대로 유지하면서 무거운 렌더링이나 네트워크 요청만 늦출 수 있다.

자동완성 예제에서는 input은 즉시 화면에 반영하고, 쿼리는 deferredInput 기준으로만 실행하도록 분리하면서 타이핑 속도와 API 호출을 같은 타이밍으로 처리하지 않게 만들었다.

즉, useDeferredValue는 “이 값은 지금 당장 쓰지 않아도 된다”고 React에게 알려주는 역할을 한다.

useTransition?

useDeferredValue로 문제는 어느 정도 해결됐지만, React 18 관련 글들을 찾아보다 보니 비슷한 역할을 하는 훅이 하나 더 눈에 들어왔다. 바로 useTransition이다.

1.useTransition은 어떤 훅인가?

useTransition 사용법

const [isPending, startTransition] = useTransition();

그리고 상태를 감싸서 사용한다.

startTransition(() => {
  setState(nextState);
});

이 훅의 핵심은 이 상태 업데이트는 우선순위가 낮으니 당장 처리 하지마 이다 즉, useDeferredValue처럼 값을 하나 더 만들어서 쓰는 게 아니라, 업데이트 자체를 React에게 “천천히 처리해도 된다”고 알려주는 방식이다

const [input, setInput] = useState("");
const [keyword, setKeyword] = useState("");

const [isPending, startTransition] = useTransition();

<input
  value={input}
  onChange={(e) => {
    const value = e.target.value;

    // 입력값은 즉시 반영
    setInput(value);

    // 자동완성 기준 값은 낮은 우선순위로 업데이트
    startTransition(() => {
      setKeyword(value);
    });
  }}
/>

쿼리는 키워드로 실행

useQuery({
  queryKey: ["tag", keyword],
  queryFn: () => fetchTag(keyword),
  enabled: keyword.trim().length >= 2,
});

정리하자면

• input은 타이핑 즉시 반응
• 자동완성 기준 값은 천천히 따라옴
• 쿼리는 keyword가 바뀔 때만 실행

useDeferredValue vs useTransition 비교

결론 둘 다 “지연”은 맞지만,

• useDeferredValue 값은 이미 바뀌었고, 그 값을 쓰는 렌더링만 늦춘다.
• useTransition 상태를 바꾸는 업데이트 자체를 낮은 우선순위로 늦춘다.

최근 Vercel에 배포해 둔 웹사이트를 업데이트하던 중, 대시보드에서 다음과 같은 경고 메시지를 확인했다.

Error: Vulnerable version of Next.js detected, please update immediately Learn More: https://vercel.link/CVE-2025-66478

이 메시지는 단순한 업데이트 권장 안내가 아니라, 특정 보안 취약점(CVE)과 직접적으로 연결된 경고였다.

Vercel은 해당 프로젝트에서 사용 중인 Next.js 버전에 보안 문제가 존재함을 감지했고, 이를 즉시 업데이트해야 하는 Critical 수준의 이슈로 분류했다.

무슨 일이 있었던 걸까?

문제가 된 대상

이번 경고는 CVE-2025-66478로 식별되는
Next.js 관련 보안 취약점과 연관되어 있다.

공식 안내에 따르면,
이 취약점은 Next.js의 App Router 환경에서 동작하는 기능과 관련되어 있으며,
일부 경우 Server Components(RSC) 와 연관된 동작이 영향을 받을 수 있는 것으로 알려졌다.

Server Components는 Next.js App Router의 핵심 기능으로,

• 서버에서만 실행되는 코드 작성
• 데이터베이스 접근
• 내부 API 호출
• 서버 환경에서만 접근 가능한 값 처리

등을 가능하게 하여, 서버 전용 로직이 클라이언트로 전달되지 않도록 설계된 구조를 가진다.

CVE-2025-66478 요약 (확인된 사실 기준)

• 취약점 식별자: CVE-2025-66478
• 위험도: Critical (Vercel 기준)
• 영향 대상: 특정 버전의 Next.js
• 조치 방법: 보안 패치가 포함된 버전으로 업데이트 필요

세부적인 공격 조건이나 내부 동작 방식은
공식 보안 공지를 통해 요약 형태로 안내되었으며,
Vercel은 해당 취약점이 실제 배포 환경에서 문제가 될 수 있다고 판단해 대시보드 경고를 표시했다.

이번 Vercel 경고 메시지는 단순한 권고 수준의 알림이 아니라,

• CVE가 공식적으로 할당된 보안 취약점이며
• Vercel 기준 Critical로 분류되었고
• 영향을 받는 Next.js 버전을 사용하는 경우
• 즉시 업데이트가 권장되는 이슈

임을 알리는 안내였다. 따라서 해당 경고를 확인했다면, 추가 분석 여부와 관계없이
보안 패치가 포함된 Next.js 버전으로 업데이트하는 것이 필수적이다.

React 공식 발표로 확인된 사실 정리

React 팀은 공식 블로그를 통해
React Server Components(RSC)와 관련된 치명적인 보안 취약점이 발견되었음을 공개했다.

공식 공지:
https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

해당 취약점은 CVE-2025-55182로 등록되었으며,
보안 등급은 CVSS 10.0 (Critical) 으로 평가되었다.

React 팀은 이 이슈에 대해 즉각적인 조치가 필요한 보안 취약점임을 명확히 밝혔다.

React는 어떻게 문제를 인식했는가

React 공식 설명에 따르면,
문제는 React Server Components 요청을 처리하는 과정에서 확인되었다.

React Server Components는 서버에서 컴포넌트를 실행한 뒤,
그 결과를 직렬화된 형태로 클라이언트에 전달한다.

React 팀은 이 과정에서 다음과 같은 위험 가능성을 확인했다고 설명한다.

• 클라이언트로부터 전달되는 Server Components 요청 데이터가
• 악의적으로 조작될 경우
• 서버에서 처리되는 실행 흐름에 영향을 줄 수 있는 가능성

서버가 처리하는 일부 입력 데이터가 충분히 검증되지 않은 상태로 역직렬화되고 있었다는 점이 이번 취약점의 핵심 원인으로 지목되었다.

React는 공식 공지를 통해 이와 같은 입력 처리 방식이 서버 실행 환경에서는 허용되어서는 안 되는 보안 위험이라고 설명했다.

React가 공식적으로 밝힌 위험성

React 팀은 이 취약점으로 인해
다음과 같은 보안 문제가 발생할 수 있음을 공식적으로 언급했다.

• 인증 없이 서버로 조작된 요청을 전송할 수 있음
• React Server Components 처리 로직이 이를 정상 요청으로 처리할 수 있음
• 서버 내부에서 의도하지 않은 코드 경로가 실행될 가능성 존재
• 그 결과 Remote Code Execution(RCE) 로 이어질 수 있음

React는 이 취약점이 다음과 같은 특징을 가진다고 명시했다.

• 개발자의 설정 실수나 커스텀 코드가 없어도 발생할 수 있음
• React Server Components를 서버에서 사용하는 경우 영향을 받을 수 있음

특정 프레임워크나 특정 구현 방식의 문제가 아니라,
Server Components를 서버에서 실행하는 구조 자체가 가지는 보안 취약점이라는 점을 공식적으로 인정한 것이다.

React 팀은 이 문제를 어떻게 해결했는가

React 팀은 이 문제를 단순한 핫픽스로 처리하지 않고,
Server Components 처리 방식 자체를 보수적으로 수정하는 방향으로 대응했다. 공식 공지에서 언급된 주요 대응 방향은 다음과 같다.

1. Server Components 요청 검증 강화

• 서버에서 처리되는 Server Components 요청 payload에 대해 더 엄격한 구조 검증을 수행
• 예상되지 않은 형태의 데이터가 포함된 요청은 처리하지 않도록 변경
• 클라이언트로부터 전달되는 데이터를 기본적으로 신뢰하지 않는 방식으로 수정

2. 위험한 역직렬화 및 실행 경로 제한

• 역직렬화 과정에서 서버 내부 객체나 실행 가능한 참조에 접근할 수 있었던 경로를 제한
• 서버에서 실행 가능한 코드 경로를 명시적으로 축소
• 외부 입력이 서버 실행 흐름에 영향을 줄 수 있는 가능성을 차단

3. 보안 릴리즈 배포 및 업데이트 권고

React 팀은 위 수정 사항을 포함한
보안 릴리즈(Security Release) 를 배포하고,

• React Server Components를 사용하는 모든 프로젝트에 대해
• 즉각적인 버전 업데이트를 강하게 권고했다.

또한, 초기 패치 이후에도 연관된 추가 취약점(서비스 거부, 정보 노출 가능성 등)이 확인되었으며,
이에 대해서도 React 팀은 공식적으로 추가 보안 패치를 배포했다.

요약

React 공식 발표를 기준으로 정리하면 다음과 같다.

• 이번 이슈는 React Server Components와 관련된 공식 보안 취약점이다
• 서버 컴포넌트 요청 처리 과정에서 입력 검증이 충분하지 않았던 구조적 문제가 원인이었다
• 이로 인해 인증 없이 Remote Code Execution(RCE) 이 발생할 가능성이 존재했다
• React 팀은 처리 모델 자체를 수정하는 방식으로 대응했다
• 현재는 보안 패치가 반영된 버전으로의 업데이트가 필수적인 상태다

이번 사례는 React Server Components가 제공하는 편의성과 함께
서버 보안에 대한 책임 역시 개발자와 프레임워크가 함께 가져가야 한다는 점을 명확하게 보여준 사건이라고 볼 수 있다.

그래서 나는?

이번 이슈를 확인한 뒤,
가장 먼저 한 일은 Vercel에서 권고한 대로 React와 Next.js를 최신 버전으로 업데이트하는 것이었다.

내가 운영 중이던 프로젝트는 외부 입력을 직접 처리하는 서버 로직이 거의 없었고 인증, 결제와 같은 민감한 기능도 포함되어 있지 않았기 때문에

실제 취약점이 악용될 가능성은 높지 않은 상태였다.
업데이트 이후에도 로그나 동작에서 특이사항은 발견되지 않았다.

이번 이슈를 통해 느낀 점

이번 React 보안 이슈를 통해 분명하게 느낀 점은 하나였다.

Server Components는 UI 코드가 아니라
서버 코드라는 인식이 필요하다는 것

React Server Components는 분명 강력하다.
서버에서 바로 데이터를 다룰 수 있고,
클라이언트 번들 크기를 줄일 수 있다는 점은 큰 장점이다.

하지만 이번 사례를 통해 깨달은 것은:

• 서버에서 실행되는 로직은 결국 백엔드 코드와 동일한 보안 기준이 필요하다는 점
• 프레임워크가 제공하는 편의성에만 의존하면
  입력 처리나 실행 경로에 대한 경계가 느슨해질 수 있다는 점
• 특히 민감한 로직일수록
  Server Components 안에 무심코 넣는 것은 위험할 수 있다는 점이었다

마무리

이번 이슈는 “React에 보안 문제가 있었다”로 끝낼 일이 아니라, Server Components라는 새로운 실행 모델이개발자에게 어떤 책임을 요구하는지를 다시 생각하게 만든 사건이었다.

앞으로도 Server Components를 사용할 생각이지만,
민감한 로직일수록 더 보수적으로 설계하고, 프레임워크의 안전함을 당연하게 가정하지는 않으려 한다.

이번 React 보안 이슈는 그 기준을 다시 세우게 만든 계기였다.

알고리즘 문제를 풀다 보면 슬라이딩 윈도우(Sliding Window) 라는 표현을 정말 자주 접하게 된다. 특히 연속된 구간을 다루는 문제에서 압도적으로 자주 등장하는 핵심 테크닉이며, 실제 코딩 테스트에서도 빈출되는 알고리즘이다.

이번 글에서는 슬라이딩 윈도우의 기본 개념부터, 어떤 상황에서 활용되는지, 그리고 대표적인 문제 패턴까지 코드 예시와 함께 정리해보려고 한다.

슬라이딩 윈도우란?

1. 개념

슬라이딩 윈도우(Sliding Window)는 말 그대로** 창문(window)을** 좌우로 밀면서(slide) 탐색하는 기법이다.

보통 아래 두 가지 경우에 사용된다

• 부분 배열의 길이가 고정된 경우 (Fixed Window)

• 조건을 만족하는 가장 긴(혹은 가장 짧은) 구간을 찾아야 하는 경우 (Dynamic Window)

핵심 아이디어는 간단하다:

전체 배열을 매번 새로 계산하지 않고, 윈도우의 양 끝을 조절하며 “증가된 부분만 더하고, 빠진 부분만 빼서” 효율적으로 계산한다.

이 방식으로 많은 문제를 O(N) 으로 해결할 수 있다.

2. 왜 슬라이딩 윈도우를 쓰는가?

• 나이브 방식 각 구간을 매번 일일이 계산 → O(N²)

• 슬라이딩 윈도우 앞/뒤 포인터만 이동 → O(N) 중복된 계산을 줄임 즉, 구간 문제의 시간 복잡도를 한 단계 확 줄여주는 기술이다.

예제로 살펴보기

1. 고정 길이 윈도우 (Fixed Window)

문제) “길이가 k인 subarray 중 가장 큰 합을 구하라.”

윈도우 크기가 고정되어 있으므로 오른쪽 값 추가,왼쪽 값 제거 만 반복하면 된다.

function maxSum(nums, k) {
  // 1. 먼저 길이가 k인 초기 윈도우의 합을 만든다.
  let sum = 0;
  for (let i = 0; i < k; i++) sum += nums[i];

  // 초기 윈도우의 합이 현재까지의 최대값
  let answer = sum;

  // 2. 윈도우를 오른쪽으로 한 칸씩 밀면서(update) 합을 갱신한다.
  for (let i = k; i < nums.length; i++) {
    sum += nums[i];        // 새로 들어온 값 추가
    sum -= nums[i - k];    // 왼쪽에서 빠져나가는 값 제거

    // 각 단계에서 최대 합을 갱신
    answer = Math.max(answer, sum);
  }

  // 3. 길이 k인 모든 연속 구간 중 최댓값 반환
  return answer;
}

2. 가변 길이 윈도우 (Dynamic Window)

문제) “합이 target 이하가 되는 가장 긴 subarray 길이를 구하라.”

윈도우 길이가 조건에 따라 늘었다 줄었다 하며 탐색한다.

function longestSubarray(nums, target) {
  let left = 0;      // 윈도우의 시작 포인터
  let sum = 0;       // 현재 윈도우의 합
  let answer = 0;    // 조건을 만족하는 가장 긴 구간 길이

  // right 포인터를 오른쪽으로 확장하며 윈도우를 키운다.
  for (let right = 0; right < nums.length; right++) {
    sum += nums[right];  // 새로 포함된 값 더하기

    // 현재 합이 target을 초과하면 조건을 만족할 때까지 left를 이동(윈도우 축소)
    while (sum > target) {
      sum -= nums[left];  // 빠져나가는 값 제거
      left++;             // 윈도우 시작점 이동
    }

    // 여기 도달했을 때 sum <= target을 만족하는 상태
    // 현재 윈도우 크기(right - left + 1)를 기준으로 최대 길이 갱신
    answer = Math.max(answer, right - left + 1);
  }

  return answer;
}

3. 빈도 기반 슬라이딩 윈도우

문제) “문자열 s에서 모든 문자가 최소 k번 등장하는 가장 긴 구간”

문자열 문제에서 자주 등장한다. 이 경우에는 윈도우 내부의 frequency map , count distinct number 등을 관리하며 이동한다.

function countValidSubstrings(s, k) {
  let left = 0;          // 윈도우 시작 포인터
  let count = 0;         // 조건을 만족하는 substring 개수
  let freq = new Map();  // 윈도우 내부에서 문자 등장 횟수를 저장하는 Map

  // right 포인터를 확장하며 윈도우를 키움
  for (let right = 0; right < s.length; right++) {
    // 새로 들어온 문자 빈도 증가
    freq.set(s[right], (freq.get(s[right]) || 0) + 1);

    // 윈도우 내에서 서로 다른 문자 수가 k를 초과하면 조건 만족할 때까지 축소
    while (freq.size > k) {
      freq.set(s[left], freq.get(s[left]) - 1);  // 빠지는 문자 count 감소

      // 0이 되면 Map에서 제거 → distinct 문자 수 감소
      if (freq.get(s[left]) === 0) freq.delete(s[left]);

      left++;  // 윈도우 축소
    }

    // 현재 right 기준으로 가능한 모든 유효한 substring 개수를 더함
    // (left ~ right 구간 전체가 조건을 만족하기 때문)
    count += right - left + 1;
  }

  return count;
}

슬라이딩 윈도우를 언제 떠올려야 하는가?

다음 문구가 보이면 슬라이딩 윈도우 문제일 확률이 높다 (특히 연속이면서 ‘효율적으로’ 계산해야 한다 → 바로 이 기법이 떠올라야 함)

• “연속된 구간”

• “부분 배열(subarray)”

• “길이가 l ~ r”

• “최대/최소 합”

• “조건을 만족하는 가장 긴 문자열”

• “0과 1의 개수 제한”

슬라이딩 윈도우의 본질은 “중복 계산을 피하고, 진짜로 변하는 부분만 업데이트한다” 라는 발상이다.

마무리

슬라이딩 윈도우는 실제 코딩 테스트에서도 나 역시 여러 번 마주쳤던 알고리즘이다. 솔직히 많이 틀리기도 했고, 그래서 LeetCode 문제들을 풀면서 개념을 다시 차근차근 정리해보게 되었다.

아직 알고리즘은 어렵고 답답하게 느껴질 때가 많지만, 꾸준히 풀다 보면 분명 나아질 거라 믿는다. 그 과정의 일부로 이렇게 정리하며 포스팅하는 습관도 계속 이어가 보려고 한다.

1. 이유

처음에는 블로그 자체에 큰 관심이 없었고, 회사 일과 사이드 프로젝트를 함께 진행하는 것도 솔직히 꽤 귀찮게 느껴졌다. 그러다 이직 준비를 하면서 여러 채용 공고를 살펴보니, 잘 정리된 기술 블로그가 생각보다 큰 가산점으로 작용한다는 걸 깨닫게 되었고 그때부터 본격적으로 블로그를 시작해보기로 했다.

처음에는 검증된 플랫폼인 Velog에 글을 쓰는 것도 충분히 괜찮은 선택이라고 생각했다. 하지만 React와 Next.js를 제대로 공부해보고 싶은 마음이 있었고, 어차피 시작할 거라면 내가 직접 사용하는 블로그를 하나 만들어보는 것도 의미 있을 것 같아 결국 개인 블로그를 직접 개발하게 되었다.

2. Why Next, React??

사실 Next.js랑 React를 선택한 건 엄청 깊은 이유가 있어서라기보단, 예전에 이 둘로 사이드 프로젝트를 두 번 정도 만들어본 적이 있어서였다. 완전히 새로운 기술을 파기엔 귀찮고, 그렇다고 아무 의미 없이 Velog에만 글을 쓰기엔 좀 아쉬웠다. 그래서 “익숙한 거 한 번 더 잘 만들어볼까?” 하는 느낌으로 자연스럽게 손이 갔다.

마침 React Query나 TypeScript도 다시 감을 잡고 싶었고, 최근에 App Router나 서버 컴포넌트 구조도 많이 바뀌어서 “이번엔 제대로 써보자”라는 생각도 있었다.

Next는 라우팅부터 렌더링 방식까지 알아서 챙겨주는 게 많아서 편했고, React는 어차피 프론트엔드를 하면 계속 마주칠 친구라 다시 한 번 제대로 다뤄보는 게 나쁘지 않겠다는 마음이었다.

결론은 익숙해서 좋았고, 다시 배우기에도 좋았고, 실제로 만들어두면 써먹을 데가 많아서 자연스럽게 React + Next.js 조합으로 가게 되었다.

어떻게 만들것인가?

시작할 때 마음만큼은 링에 오르기 전의 복서처럼 뜨거웠다. 그런데 막상 퇴근하고 컴퓨터 앞에 앉으니 갑자기 갑갑해지기 시작했다. 그 흔한 npx create-next-app@latest 한 줄 치는 것도 괜히 귀찮아지고, 본격적으로 코드를 쓰려니 의욕이 묘하게 사라졌다.

그래서 처음부터 코딩을 밀어붙이기보다는, 일단 참고할 만한 블로그 디자인을 찾아보는 쪽으로 방향을 틀었다. “어떤 느낌으로 만들지” 감을 잡는 게 먼저일 것 같았다.

1. UI/UX

참고 할만한 화면 리스트

• 티스토리 → 구글링할 때 가장 자주 보던 블로그 플랫폼이고, Inpa님 블로그도 예전부터 참고해왔어서 “이 느낌으로 갈까?”라는 생각이 들었다. 근데 내가 원하는 무난하면서 깔끔한 디자인과는 조금 다른 느낌이라 최종적으로는 보류했다.

• 내가 창작해서 해보기 → 예전에 Next 13 버전으로 블로그를 만든 적이 있었는데, 그때는 여기저기서 디자인을 가져와 섞어보고 내 스타일대로 꾸며보겠다고 욕심을 부리다가 결국 완전히 난잡해져서 망해버린 경험이 있다. 그 기억이 떠오르다 보니 이번에는 과감하게 “내가 꾸미기”는 보류하기로 했다.

• 차라리 검증된 디자인을 그대로 참고해서 만드는 게 훨씬 안전하다. (그냥 카피하는게 게 최고…)*

• velog → 사실 디자인은 거의 Velog로 확정해두고 있었다. 하루 정도 이것저것 찾아보며 비교해봤지만, 결국 다시 Velog로 마음이 기울었다. 다크모드를 기본으로 지원하고, 전체적으로 깔끔하고 심플한 분위기가 딱 내 취향이었다. 물론 전부 그대로 가져오는 건 재미도 없고 의미도 없으니,

• Velog 느낌을 기본으로 하되 필요한 부분만 적당히 가져오는* 정도로 방향을 잡았다.

완성된 화면

적당히 참고하려 했지만, 결과적으로는 꽤 많이 비슷해졌다. Velog 메인 화면을 모티브로 게시글 리스트 페이지를 구현했고, 프로필 카드와 설정 화면은 Velog의 프로필 UI를 참고해 제작했다. Post 상세 페이지는 전체적인 구성은 유지하되, 일기장 형식으로 사용할 예정이라 댓글 기능은 제외했고 대신 별도로 방명록 페이지를 만들었다.

2. SKill

UI/UX는 방향은 정리했다. 그렇다면 이제 이걸 무슨 기술로, 어떤 구조로 만들지 선택할 차례였다. 앞서 간단히 언급했듯이 프론트엔드는** React + Next.js** 조합으로 진행하기로 했는데, 여기서 한 번 더 차근차근 정리해보려고 한다.

프론트엔드

• Next.js (App Router, Server Components) → SSR/SSG/ISR을 유연하게 활용할 수 있어 SEO와 초기 렌더링에서 이점이 있다.

• React → 컴포넌트 기반 UI 구성에 익숙하고, 재사용성과 확장성이 뛰어나다.

• React Query → 서버 상태 관리에 최적화되어 있고, 캐싱/Prefetch 등으로 UX를 크게 개선해 준다.

• TypeScript → 타입 안정성을 통해 런타임 오류를 줄이고, 유지보수성을 확보할 수 있다.

• Tailwind.css → 빠른 스타일링과 일관된 디자인 시스템 구축에 유리해, 컴포넌트 단위 개발 생산성을 크게 높여주었다.

백엔드 & 인프라

프론트엔드 방향을 정했다면, 이제 이걸 어디에 어떻게 저장하고, 어디서 어떻게 띄울지도 고민해야 했다.
새로운 기술로 하는것도 괜찮지만 빠른 배포를 위해 자주 사용했던 Prisma + MongoDB + Vercel 조합으로 가기로 했다.

• Prisma → JS/TS 환경에서 쓰기 좋은 ORM이라, 스키마 기반으로 데이터 구조를 정의하기 편했다.
  타입 지원도 잘 되어 있어서, TypeScript와 함께 쓸 때 개발 경험이 꽤 좋았다.

• MongoDB Atlas → 블로그 정도 규모에서는 복잡한 트랜잭션이 많이 필요하지 않아서,
  문서 기반으로 빠르게 개발할 수 있는 MongoDB를 선택했다.
  Atlas를 쓰면 인프라를 직접 관리할 필요 없이 바로 클라우드에서 연결해 쓸 수 있다는 점도 컸다. (그리고 무료플랜이 있다.)

• Vercel → Next.js와 가장 궁합이 잘 맞는 배포 플랫폼이라, 별 고민 없이 선택했다.
  Git에 푸시하면 자동으로 빌드/배포가 돌아가고,
  프리뷰 환경도 쉽게 만들어져서 사이드 프로젝트에 특히 잘 맞았다.

데이터는 어떻게?

UI도 정했고, 어떤 기술을 사용할지도 결정했다. 이제 남은 건 무엇을 저장하고 어떻게 다룰 것인지였다.

블로그의 핵심 데이터는 당연히 글(Post) 이다. 그리고 글과 함께 이미지(Image) 를 관리해야 했고, 글을 태그(Tag) 로 분류할 수 있도록 구조를 잡을 필요가 있었다.

또한 이 블로그는 개인 블로그이기 때문에 게시글 작성자 정보는 단일 프로필(Profile) 로 관리하고, 방문자들이 댓글을 남길 방명록(Comment) 기능을 따로 두기로 했다.

결국 이 네 가지 모델을 중심으로 전체 데이터 구조를 설계하게 되었다.

1. Post — 글 데이터

블로그의 핵심. 제목/내용 외에도 썸네일, 미리보기, 임시저장 여부, slug URL 등을 포함했다.

model Post {
  id        String   @id @default(auto()) @map("_id") @db.ObjectId
  title     String
  content   String
  preview   String?
  thumbnail String?
  slug      String   @unique
  tagIds    String[] @db.ObjectId
  tag       Tag[]    @relation(fields: [tagIds], references: [id])
  isTemp    Boolean  @default(false)
  images    Image[]
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

• slug를 unique로 설정해 SEO 및 라우팅 최적화
• isTemp 필드로 임시저장 기능 지원 (발행하지 않은 상태)
• 태그와 N:M 관계

2. Image — 게시글 이미지

이미지 관리 로직을 유연하게 가져가기 위해 Post 모델에서 분리해 Image 모델로 따로 관리했다. 외부 이미지 저장소 연동을 고려했고, 글 삭제 시 이미지 정리 흐름을 명확히 할 필요가 있었다. 또한 썸네일과 일반 이미지를 구분해 다룰 수 있도록 별도 엔티티 구성으로 확장성을 확보했다.

model Image {
  id        String   @id @default(auto()) @map("_id") @db.ObjectId
  imageId   String   @unique //클라우드 플레어 이미지 Id
  postId    String?  @db.ObjectId
  post      Post?    @relation(fields: [postId], references: [id], onDelete: Cascade)
  isThumb   Boolean  @default(false) //썸네일용 플래그
  createdAt DateTime @default(now())
}

• onDelete: Cascade를 통해 글 삭제 시 이미지도 자동 정리

3. Tag — 탐색 & 분류를 위한 구조

태그는 게시글의 탐색성을 높여주는 요소라 별도의 엔티티로 두고 Post와 N:M 관계로 구성했다.

model Tag {
  id        String   @id @default(auto()) @map("_id") @db.ObjectId
  body      String   @unique
  isTemp    Boolean  @default(false)
  posts     Post[]   @relation(fields: [postIds], references: [id])
  postIds   String[] @db.ObjectId
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

• 아직 발행되지 않은 임시 태그는 isTemp 로 구분 → 임시 글 단계의 태그는 실제로 사용될지 불확실하다. 그런데 이를 바로 저장해버리면 태그 목록 조회 시 사용되지 않는 태그까지 함께 불러오는 문제가 생긴다. 이를 방지하기 위해 isTemp 플래그를 도입해 임시 태그를 분리 관리하도록 했다.

4. Profile — 블로거 프로필

혼자만 쓰는 구조라 복잡하게 모델링 하지 않았고 SNS 링크나 자기소개를 담아 포트폴리오 역할도 고려했다

model Profile {
  id         String  @id @default(auto()) @map("_id") @db.ObjectId
  title      String
  content    String
  introduce  String
  profileImg String?
  github     String?
  notion     String?
  instagram  String?
}

5. Comment — 댓글 대신 방명록

블로그 콘셉트가 일기장이기 때문에 게시글 자체의 댓글은 제거하고, 대신 별도 페이지에서 방명록을 작성하도록 했다.

model Comment {
  id        String   @id @default(auto()) @map("_id") @db.ObjectId
  name      String
  content   String
  isMe      Boolean  @default(false)
  createdAt DateTime @default(now())
}

• isMe 플래그를 통한 작성자 방문자 구문

6. 모델링 요약

Post (N) ─── (N) Tag Post (1) ─── (N) Image Comment ─── Independent Profile ─── Independent

라우팅 구조는 어떻게?

데이터 모델까지 준비되었으니, 이제 이 데이터를 어떤 페이지에서 어떻게 보여줄지 고민할 단계였다.

Next.js를 사용하면서 가장 먼저 부딪힌 고민은 바로 렌더링(SSR · SSG · ISR) 선택이었다. 페이지 성격에 따라 최적의 방식을 찾기 위해, 코드를 여러 번 고치고 되돌리며 시행착오를 겪게 되었다.

1. 구조

app/
 ├─ api/                     // Route Handlers (서버 API)
 ├─ auth/                    // 인증 관련 페이지 (요구 시 사용)
 ├─ comments/                // 방명록 페이지(댓글 기능)
 ├─ hooks/                   // 클라이언트 커스텀 훅
 ├─ lib/                     // 서버 유틸 및 DB 접근 로직
 ├─ post/                    // 게시글 상세 페이지
 │   └─ [slug]/
 │       └─ page.tsx
 ├─ profile/                 // 소개 페이지
 │   └─ page.tsx
 ├─ setting/                 // 설정 페이지
 │   └─ page.tsx
 ├─ temp/                    // 임시글 관련 라우트
 ├─ write/                   // 글 작성 페이지
 │   └─ page.tsx
 ├─ fonts.ts                 // 폰트 설정
 ├─ globals.css              // 전역 스타일
 ├─ layout.tsx               // 공통 레이아웃
 ├─ not-found.tsx            // 404 페이지
 └─ page.tsx                 // 메인 페이지 (게시글 리스트)

2. 각 구조의 고민과 해결

1. / — 게시글 리스트

메인 페이지를 SSR로 구현했을 때는 글 작성/삭제 후 새로고침하면 SSR에서 내려온 옛날 데이터가 캐시를 덮어버리는 문제가 있었다. 그리고 메인 페이지는 트래픽이 많을 수 있는 영역이라 매 요청마다 서버 렌더링과 DB 쿼리를 수행하는 것도 비효율적이었다.

그래서 SSR을 제거하고, 클라이언트 캐싱 기반 + 서버 revalidateTag("posts") 조합으로 전환했다. 이 구조를 통해 비용을 줄이면서도, 글이 변경되는 시점에만 정확하게 최신 데이터가 반영되도록 만들 수 있었다.

2. /post/[slug] — 게시글 상세

상세 페이지는 slug 기반 라우팅을 선택했다.
Velog에서도 사용되는 방식으로,

/post/안녕-하세요
/post/react-query-정복하기

처럼 제목을 URL에 녹여내는 패턴이다.

이 방식은 단순히 보기 좋기만 한 것이 아니라,
다음과 같은 실질적인 장점이 있었다.

• SEO 최적화 → URL 자체가 콘텐츠 키워드를 포함 검색 엔진이 페이지를 독립 문서로 잘 인식

• 사용자 경험 향상 (UX) → 주소만 봐도 어떤 글인지 직관적으로 파악 공유 및 링크 접근에 유리

• 고유 식별자 역할 → DB에서 slug는 unique 별도의 ID 없이 직접적인 접근 가능

상세 페이지는 검색 유입이 중요한 페이지이기 때문에, SEO에 유리한 SSR 방식으로 렌더링하도록 결정했다. slug 기반으로 데이터를 서버에서 바로 가져올 수 있어 정확한 콘텐츠를 안정적으로 제공할 수 있다는 점도 장점이었다.

3. /setting — 설정 페이지

초기에는 SSR(prefetch + Hydration)로 구현했지만,
invalidate와 함께 사용하니 새로고침 시 UI 깜빡임이 발생했고
force-dynamic 때문에 매번 서버 요청이 반복되는 비효율이 있었다.

설정 페이지는 SEO가 필요 없는 관리자 전용 페이지이기 때문에
SSR을 제거하고 CSR + React Query invalidate 방식으로 전환했다.

4. /comments — 방명록(댓글)

방명록은 사용자 간 실시간 상호작용이 중요한 기능이 아니기 때문에 최신 데이터를 빠르게 반영할 필요성이 크지 않았다.

그래서 staleTime을 30초로 설정하여, 짧은 시간 내에서 불필요한 refetch를 방지하고 간단한 캐싱으로 성능을 안정적으로 유지하도록 했다.

소통 기능이라기보다 그냥 간단히 메시지를 남기는 용도에 가깝기 때문에 “적당한 최신성 + 효율적인 동작”을 선택했다.

5. /post/temp — 임시글 리스트

이 화면 또한 SSR을 통해 staletime을 10분? 정도 줬으나 임시글은 작성 중 수시로 바뀌기 때문에 stale time을 0으로 두어 것보다 항상 서버 기준으로 최신 데이터 조회가 안정적이었다.

또한 /write 페이지에서 임시 저장할 때마다 setQueryData로 temp 리스트를 직접 업데이트해야 해서 케이스가 많아지는 것도 번거로웠다.

나름 두 달 가까이 야금야금 시간을 갈아 넣었던 사이드 프로젝트였는데, 글로 정리해보니 의외로 단순하게만 보인다. 그래도 이렇게 하나하나 짚어보다 보니 당시에 머리 싸매고 고민했던 기억들이 다시 떠오르면서 “아, 그래도 꽤 열심히 했네” 싶었다.

아직 다 쓰지도 못했는데 내용이 생각보다 너무 길어져서 이쯤에서 한 번 끊고, 나머지는 Part 2에서 이어가려고 한다.

지금까지 여러 사이드 프로젝트를 진행했지만, Jest는 한 번도 제대로 사용해본 적이 없다. 처음에는 Jest 자체를 잘 몰랐고, 또 프로젝트가 어느 정도 완성된 상태에서 테스트 환경을 뒤늦게 도입하기가 너무 번거롭게 느껴졌기 때문이다. 하지만 채용 공고나 다양한 오픈소스 프로젝트를 보다 보면 Jest는 사실상 기본 도구처럼 자리 잡고 있다는 생각이 든다. 그래서 이번 포스팅을 통해 Jest를 체계적으로 학습해보려고 한다.

Jest란?

Jest는 자바스크립트 테스트 프레임워크로, React를 비롯해 대부분의 JavaScript/TypeScript 프로젝트에서 사용 가능한 범용 테스트 도구다. 메타(구 페이스북)에서 개발했으며, 설정이 간단하고 사용하기 쉬운 API를 제공한다는 점에서 프론트엔드 생태계의 사실상 표준으로 자리 잡고 있다.

1. Jest의 주요 특징

• Zero-Config 지향 별도의 복잡한 설정 없이 바로 테스트를 작성하고 실행할 수 있다.

• 빠른 실행 속도 테스트를 병렬로 실행하여 큰 프로젝트에서도 효율적이다.

• 강력한 Mocking 지원 네트워크 요청, 타이머, 모듈 등을 간단하게 mock 처리할 수 있어 독립적인 테스트 작성이 가능하다.

• 스냅샷 테스트 제공 UI 변경 여부를 자동으로 감지해 예상치 못한 변화를 빠르게 확인할 수 있다.

• TypeScript 지원 ts-jest 같은 도구를 통해 TypeScript 환경에서도 자연스럽게 사용할 수 있다.

2. 한 줄로 정리하면?

Jest는 코드가 예상대로 동작하는지 검증하고, 프로젝트의 품질을 유지해주는 테스트 도구다.

Jest 세팅하기

TypeScript + React 환경 기준으로 Jest를 세팅하는 과정을 정리해본다.

1. 필요한 패키지 설치하기

먼저 jest와 타입스크립트 환경에서 동작하기 위한 도구들을 설치한다.

npm install --save-dev jest ts-jest @types/jest

React 컴포넌트 테스트도 할 예정이라면 아래도 함께 설치한다

npm install --save-dev @testing-library/react @testing-library/jest-dom

2. Jest 설정 파일 생성하기

아래의 명령어로 자동으로 설정 파일을 생성할 수도 있다.

npx ts-jest config:init

그러면 아래와 유사한 jest.config.js 파일이 생성된다

/** @type {import('ts-jest').JestConfigWithTsJest} */
module.exports = {
  preset: "ts-jest",
  testEnvironment: "jsdom",
  moduleNameMapper: {
    "^@/(.*)$": "<rootDir>/$1",
  },
  setupFilesAfterEnv: ["<rootDir>/jest.setup.ts"],
};

설명:

• preset: TypeScript 파일을 변환하기 위해 ts-jest 사용

• testEnvironment: React 테스트를 위한 jsdom 환경

• moduleNameMapper: 절대경로(@/components/...)를 Jest에서도 인식하도록

• setupFilesAfterEnv: 테스트 실행 전에 공통 설정 로드

React UI를 테스트 하기위해선 setup파일을 아래와 같이 설정한다

//setupTests.ts
import { server } from "./mocks/server";
import "whatwg-fetch"; 
import "@testing-library/jest-dom"; // React UI 테스트 

// 모든 테스트 시작 전에 서버를 켜기
beforeAll(() => server.listen());

// 각 테스트 끝난 뒤 핸들러 리셋 (다른 테스트에 영향 방지)
afterEach(() => server.resetHandlers());

// 모든 테스트 끝나면 서버 닫기
afterAll(() => server.close());

import "@testing-library/jest-dom" 이걸 통해 다음과 같은 matcher를 사용할 수 있다:

• toBeInTheDocument()
• toHaveTextContent()
• toBeVisible()

간단한 테스트 작성해보기

1. 함수 테스트

아래와 같이 간단한 덧셈함수를 작성한다

//test/sum.ts
export function sum(a: number, b: number) {
  return a + b;
}

그리고 테스트 케이스를 작성후 npx jest test/sum 을 해보면

//test/sum.test.ts
import { sum } from "./sum";

describe("덧셈 테스트", () => {
  test("1 + 2 = 3 이어야 한다", () => {
    expect(sum(1, 2)).toBe(3);
  });

  test("3 + 3 = 6 이어야 한다", () => {
    expect(sum(3, 3)).toBe(6);
  });
});

이렇게 성공적으로 테스트가 완료된걸 확인할수 있다.

2. 리액트 컴포넌트 테스트

이번엔 리액트 컴포넌트 UI를 테스트해보자

// src/components/hello.tsx
export default function Hello() {
  return <div>Hello World</div>;
}

똑같이 테스트 케이스를 작성, npx jest components/hello 실행

// src/components/Hello.test.tsx
import { render, screen } from "@testing-library/react";
import Hello from "./hello";

test("Hello 컴포넌트가 정상 렌더링된다", () => {
  render(<Hello />);
  expect(screen.getByText("Hello World")).toBeInTheDocument();
});

컴포넌트 UI 테스트도 성공적으로 되는걸 확인할수있다.

API를 끼얹어서 테스트 해보기(MSW)

단순히 컴포넌트 UI만 테스트하면 뭔가 실용성도 떨어지고 재미도 없다. 그래서 실제 서비스처럼 API가 개입된 흐름을 테스트해보고 싶어지는데, 문제는 테스트 환경에서는 진짜 서버를 부를 수 없다는 점이다.

이럴 때 필요한 게 바로 MSW(Mock Service Worker)다. MSW는 네트워크 요청을 가짜로 만들어주는 도구로, 백엔드가 없어도 fetch나 axios 요청에 원하는 응답을 돌려줄 수 있다.

API가 끼어있는 컴포넌트 테스트를 현실적으로 만들려면 MSW가 필수다.

1. MSW(v1) 설치

MSW는 반드시 v1을 사용해야 Jest와 안정적으로 호환된다.

설치 시 명시적으로 v1 설치:

npm i -D msw@1

2. 핸들러 정의하기 (src/mocks/handlers.ts)

API 요청을 어떻게 가짜 응답할지 작성하는 곳이다. 원하면 여러 개의 API를 여기에서 등록할 수 있다.

import { rest } from "msw";

export const handlers = [
  rest.get("https://example.com/api/user", (req, res, ctx) => {
    return res(
      ctx.status(200),
      ctx.json({
        name: "김철수",
      })
    );
  }),
];

3. 서버 객체 생성 (src/mocks/server.ts)

테스트 시작 시 서버 켜고, 테스트 종료 후 서버 끄기.

import { server } from "./mocks/server";
import "whatwg-fetch"; // fetch polyfill
import "@testing-library/jest-dom";

// 테스트 시작 전: 서버 ON
beforeAll(() => server.listen());

// 각 테스트 후: 핸들러 리셋
afterEach(() => server.resetHandlers());

// 전체 테스트 끝나면 서버 OFF
afterAll(() => server.close());

여기까지 작성하면 기본적인 설정은 끝이다 테스트 케이스를 작성해보자

4. 컴포넌트 + API

위에서 작성했던것과 마찬가지로 컴포넌트를 만들어준다.

//components/primaryButton.tsx
import React, { useState } from "react";

export function PrimaryButton() {
  const [user, setUser] = useState<{ name: string } | null>(null);

  async function handleClick() {
    const res = await fetch("https://example.com/api/user");
    const data = await res.json();
    setUser(data);
  }

  return (
    <div>
      <button onClick={handleClick}>유저 불러오기</button>
      {user && <p data-testid="username">{user.name}</p>}
    </div>
  );
}

테스트 케이스 작성, npx jest components/primaryButton 실행

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { PrimaryButton } from "./primaryButton";

test("버튼 클릭 시 유저 이름이 표시된다", async () => {
  render(<PrimaryButton />);

  // 버튼 클릭
  await userEvent.click(screen.getByText("유저 불러오기"));

  // Mock 응답 결과가 렌더링되는지 확인
  const username = await screen.findByTestId("username");
  expect(username).toHaveTextContent(/^김철수$/);
});

성공적으로 pass가 되는걸 확인할수 있다.

버튼을 클릭하면 실제 API 주소로 fetch를 보내지만, 테스트 환경에서는 이 요청이 인터넷으로 나가지 않는다. 대신 MSW 가 네트워크 요청을 가로채서 우리가 정의한 가짜 응답을 대신 돌려준다. 테스트 환경에서는 Service Worker(혹은 Node 환경용 인터셉터)가 fetch 호출을 중간에서 받아주고, 매칭되는 핸들러가 있으면 그 응답을 반환한다.

즉, 컴포넌트는 진짜 API를 호출한다고 생각하지만 실제로는 MSW가 해당 URL을 intercept → mock response를 반환하는 구조다.

이 원리 덕분에 서버 없이도 “API 포함 UI 흐름”을 완전히 재현하며 테스트할 수 있다.

마무리하며..

Jest를 활용한 기본적인 테스트 케이스 작성부터 MSW 를 이용한 API mocking까지 간단히 살펴보았다. 아직은 겉핥기식으로 경험해본 수준이지만, 이 정도 흐름만 이해해도 앞으로 더 복잡한 컴포넌트나 비동기 로직을 테스트하는 데 큰 도움이 될 것이다. 이제 실제 프로젝트에 적용해보면서 테스트 커버리지도 넓히고, 다양한 상황을 시뮬레이션하는 더 견고한 테스트 환경을 만들어볼 계획이다.

전편에선 컨버터를 만들기 위한 세팅작업을 하다가 끝이났다. 크롬익스텐션 환경이 처음이기에 생각보다 오래걸렸고 예상치 못한 문제들이 많았다. UI적으로 짜잘한 수정도 있었지만(드래그,팝업 위치 업데이트 등) 이번글에선 엘리먼트의 css를 테일윈드로 변환하는 과정을 글로 정리하려고 한다

과정

1. 어떻게 변환 시킬것인가?

깊이 고민하진 않았다. 어차피 GPT(라고 쓰고 바이브코딩이라 부른다)에게 물어보면 되겠지 싶었다. 그런데 막상 물어보니, 생각보다 간단한 문제는 아니었다.

생각했던 과정

• getComputedStyle을 통해 엘리먼트의 css를 가져온다
• GPT가 테일윈드로 1:1변환 시키는방법을 알아서 찾는다(?)
• 변환시킨 문자열을 편하게 볼수있게 UI를 꾸며준다
• 완성(??)

단순하게 “DOM에서 스타일만 읽어와서 Tailwind로 변환하면 되잖아?”였지만,
막상 구현해보니 곳곳에서 예상치 못한 문제들이 튀어나왔다.

2. 문제와 해결

문제1

getComputedStyle이 너무많다..

getComputedStyle은 엘리먼트에 적용된 모든 스타일을 반환한다. 즉, 상속된 값, 브라우저 기본 스타일, 의미 없는 0px 값까지 전부 나온다. 처음엔 이걸 그대로 변환했는데 결과가 끔찍했다. 의미없는 css의 양이 너무 많았기에 핵심만 남기고 나머지는 전부 버려야 했다.

block w-[auto] h-[auto] color-[rgb(0_0_0)] margin-[0px] padding-[0px] border-[none] ...

해결방법

<div>, <button> 등 동일 태그의 기본값(getComputedStyle(document.createElement(tag)))과 비교 실제로 “차이 나는” 속성만 남기고, allowedProps 배열로 필요한 속성만 필터링하였다.

const allowedProps = [
  "display", "color", "background-color",
  "width", "height",
  "margin-top", "margin-right", "margin-bottom", "margin-left",
  "padding-top", "padding-right", "padding-bottom", "padding-left",
  "font-size", "font-weight",
  "box-shadow", "border-radius", "border-width", "border-color"
];

문제2

Tailwind 변환의 까다로움

getComputedStyle로 가져온 CSS를 그대로 Tailwind로 바꾸는 건 생각보다 간단하지 않았다. 우선 브라우저가 반환하는 스타일 값은 너무 다양하고, Tailwind의 설정값(theme.spacing, fontSize, borderRadius 등)과 완벽히 일치하지 않기 때문이다. 실제 테일윈드처럼 깔끔하게 변환시킬순 없었고 어느정도는 타협해서 변환시키기로 했다.

해결방법

우선 Tailwind 설정을 전부 JSON 형태로 덤프(tailwind.json) 떠서 하나의 매핑 기준 데이터셋으로 만들었다. 이 파일에는 "4px" → "p-1", "1rem" → "text-base" 같은 식으로 Tailwind 클래스와 실제 CSS 값이 모두 담겨 있다.

변환 과정은 단순했다. 우선 각 CSS 속성값을 숫자로 변환해서 tailwind.json 안에서 가장 가까운 값(근사값) 을 찾고, 일치하는 키가 있으면 그걸 Tailwind 클래스로 매핑했다. 예를 들어 font-size: 15.9px → text-base, margin-top: 32px → mt-8 식으로 변환된다. 근사값조차 없을 경우엔 [prop:value] 형태로 fallback 처리했다.

하지만 색상(color, background-color) 계열은 예외였다. CSS에는 rgb(), hsl(), oklab(), color(display-p3 ...) 같은 다양한 포맷이 섞여 있어서 Tailwind의 팔레트(red-500, blue-600)과 정확히 맞출 수가 없었다. 그래서 색상은 아예 매칭을 포기하고, 그냥 [background-color:#e90000], [color:rgb(233_0_0)] 같은 브라켓 형식으로 그대로 변환했다.

결과만 정리하자면,

색상은 완벽 매칭 불가능 → [prop:value] 형식으로 처리 나머지 속성은 Tailwind JSON 기준으로 근사 매칭 → 없으면 [prop:value] fallback

많은 노가다가 들어가고 완벽하진 않지만 만족스럽게 해결이 되었다.

3. 결과물

Tailwind 변환 로직은 모두 완성됐다. 이제 남은 건 단순히 그 결과를 UI로 보여주는 일뿐이었다. 변환에 사용된 함수들은 따로 useConverter 훅으로 분리해 관리했고, content 스크립트에서 사용자가 변환된 결과를 바로 확인할 수 있도록 렌더링했다.

상단에는 변환된 Tailwind 문자열 전체를 한눈에 볼 수 있도록 표시하고, 원하는 경우 쉽게 복사할 수 있는 기능을 추가했다. 하단에는 변환된 클래스들을 Typography, Color, Box Model, Layout, Effects, Other 여섯 가지 카테고리로 구분해, 각 항목을 버튼 컴포넌트 형태로 렌더링했다. 각 버튼을 클릭하면 해당 클래스를 즉시 클립보드로 복사할 수 있도록 구현했다.

마치며

만드는 과정은 꽤 재미있었다. 비록 완벽하진 않지만, 처음부터 그걸 목표로 한 건 아니었다. “완벽함보다는 도전” — 그 마음으로 시작했고, 지금은 일단 시도했다는 사실만으로도 충분히 의미가 있었다. 앞으로는 조금씩 다듬고, 천천히 리팩토링해가면 된다.

크롬익스텐션 만들어보기(1) 챕터를 시작하기전에 프로젝트를 이미 어느정도 구성해둔 상태였다. 1~2일 마다 진행과정과 어려움을 쓰려고했는데 현생에 치이고 너무 게으른 관계로 게속 미루다 미루다.. 이제서야 내용을 정리하려한다.

과정

챕터1에서 작성한 내용처럼 엘리먼트의 css를 완벽하진 않지만 TailwindCss로 변환하는것을 목표로 시작했다. 엄청 간단할거라고 생각하고 무작정 진행했는데 생각보다 쉽지많은 않았고 vite 설정에서 많이 꼬이기도 했다.

1. 엘리먼트 찾기

생각보다 단순한 아이디어에서 시작됐다. 개발자라면 익숙한 크롬 개발자도구(F12) 의 커서 모양 아이콘(검사할 페이지 요소 선택) 기능 — 마우스로 페이지의 요소를 직접 클릭해 구조를 확인할 수 있는 그 기능에서 착안했다. 이 원리를 응용해, 익스텐션 내부에서도 비슷하게 요소를 클릭해 확인할 수 있는 기능을 구현했다.

//content/inspector.ts
import { logger } from "../hooks/useUtils";

let overlay: HTMLDivElement | null = null;
let label: HTMLDivElement | null = null;
let blocker: HTMLDivElement | null = null;

export function removeInspectorInfo() {
   overlay?.remove();
   overlay = null;
   label?.remove();
   label = null;
}

export function initInspector(setTarget: (el: HTMLElement) => void) {
   logger("initInspector (main doc)");

   if (blocker) return;

   function stopInspector() {
      blocker?.remove();
      blocker = null;

      document.removeEventListener("mousemove", handleMove, true);
      document.removeEventListener("click", handleClick, true);
      document.removeEventListener("keydown", handleKeyDown, true);
      logger("[inspector] stopped");
   }

   function handleKeyDown(e: KeyboardEvent) {
      if (e.key === "Escape") stopInspector();
   }

   function handleClick(e: MouseEvent) {
      e.preventDefault();
      e.stopPropagation();

      if (overlay) overlay.style.backgroundColor = "transparent";
      const el = document
         .elementsFromPoint(e.clientX, e.clientY)
         .find((n) => n !== blocker && n !== overlay && n !== label) as HTMLElement | undefined;

      if (el) {
         setTarget(el);
      }

      stopInspector();
   }

   function handleMove(e: MouseEvent) {
      const el = document
         .elementsFromPoint(e.clientX, e.clientY)
         .find((n) => n !== blocker && n !== overlay && n !== label) as HTMLElement | undefined;
      if (!el) return;
      const rect = el.getBoundingClientRect();
      showOverlay(rect, el);
   }
   function showOverlay(rect: DOMRect, el: HTMLElement) {
      if (!overlay) {
         overlay = document.createElement("div");
         Object.assign(overlay.style, {
            position: "absolute",
            zIndex: "999999",
            pointerEvents: "none",
            border: "2px solid magenta",
            background: "rgba(255,0,255,0.1)",
         });
         document.body.appendChild(overlay);
      }
      Object.assign(overlay.style, {
         top: `${rect.top + window.scrollY}px`,
         left: `${rect.left + window.scrollX}px`,
         width: `${rect.width}px`,
         height: `${rect.height}px`,
      });

      if (!label) {
         label = document.createElement("div");
         Object.assign(label.style, {
            position: "absolute",
            zIndex: "1000000",
            fontFamily: "monospace",
            fontSize: "14px",
            color: "#fff",
            background: "rgba(0,0,0,0.8)",
            padding: "2px 5px",
            borderRadius: "3px",
            whiteSpace: "nowrap", // 긴 텍스트 한 줄로
         });
         document.body.appendChild(label);
      }

      const tag = el.tagName.toLowerCase();
      const siblings = el.parentElement
         ? Array.from(el.parentElement.children).filter((child) => child.tagName === el.tagName)
         : [];
      const index = siblings.indexOf(el);
      const id = el.id ? `#${el.id}` : `#${index}`;
      const classes = el.classList.length ? "." + Array.from(el.classList).join(".") : "";

      label.textContent = `${tag}${id}${classes}`;

      // ✅ label 높이 계산해서 그만큼 위로 올림
      const labelHeight = label.offsetHeight || 20;
      const top = rect.top + window.scrollY - labelHeight - 8; // 8px 여백

      Object.assign(label.style, {
         top: `${Math.max(top, 0)}px`, // 화면 위로 벗어나지 않게 보정
         left: `${rect.left + window.scrollX}px`,
      });
   }

   blocker = document.createElement("div");
   Object.assign(blocker.style, {
      position: "fixed",
      top: "0",
      left: "0",
      width: "100vw",
      height: "100vh",
      background: "transparent",
      cursor: "crosshair",
      zIndex: "999998",
   });
   document.body.appendChild(blocker);

   document.addEventListener("mousemove", handleMove, true);
   document.addEventListener("click", handleClick, true);
   document.addEventListener("keydown", handleKeyDown, true);

   logger("[inspector] started");
}

위 코드처럼 단순히 인스펙터가 시작됐을때 오버레이,라벨 등 엘리먼트를 만들어 사용하고 있는 웹페이지에 append하면 끝이였다. 보라색 영역은 선택한 엘리먼트의 영역이고 그 위의 라벨은 태그이름을 나열하였다.(사실 개발자도구의 인스펙터와 거의 똑같다)

2. Converter 팝업 띄우기

생각보다 빨리 여기서 난처한 상황이 나왔는데 어느때와 같이 UI를 테일윈드로 진행하려했으나 적용이 되질 않았다. 왜지? 분명히 크롬익스텐션에 등록해서 사용했던 팝업은 적용이 됐었는데..?

Content Script에서 Tailwind가 적용되지 않았던 이유

처음에는 Tailwind를 이용해 content script 쪽 UI를 만들고 싶었다. 하지만 빌드 후 실제 확장 프로그램을 실행해보니, 외부 웹페이지에 삽입되는 content script에서는 Tailwind가 전혀 적용되지 않았다.

처음엔 단순히 CSS 경로 문제라고 생각했지만, 실제 원인은 content script의 실행 환경 때문이었다.

Chrome 확장 프로그램의 popup이나 options 페이지는 chrome-extension:// 내부에서 실행되기 때문에 Tailwind CSS가 일반적인 방식(import "./global.css")으로 잘 작동한다. 하지만 content script는 외부 웹페이지의 DOM에 삽입되는 코드라서 확장 내부의 CSS 리소스를 직접 불러올 수 없다. 결과적으로 Tailwind 스타일이 적용되지 않았다.

Vite 설정을 통한 해결

이 문제를 해결하기 위해 Vite의 ?inline 옵션을 사용했다. Tailwind로 빌드된 CSS를 별도의 파일로 링크하는 대신, 빌드 시점에 CSS 내용을 문자열로 변환하여 JS 번들에 포함시키는 방식이다.

먼저, vite.config.ts에서 다음과 같이 빌드 구조를 설정했다.

//vite.config.js
 root: "src",
      publicDir: "../public",
      build: {
         outDir: "../dist",
         emptyOutDir: true,
         rollupOptions: {
            input: {
               popup: resolve(__dirname, "src/popup/index.html"),
               options: resolve(__dirname, "src/options/index.html"),
               background: resolve(__dirname, "src/background.ts"),
            },
            output: {
               entryFileNames: (chunkInfo) => {
                  if (chunkInfo.name === "background") return "background.js";
                  if (chunkInfo.name === "popup") return "popup/popup.js";
                  if (chunkInfo.name === "options") return "options/options.js";
                  return "assets/[name]-[hash].js";
               },
               chunkFileNames: "assets/[name]-[hash].js",
               assetFileNames: "assets/[name]-[hash][extname]",
            },
         },
      }

이 설정을 통해 Tailwind가 처리된 CSS(global.css)가 빌드 시 자동으로 dist/assets/ 폴더에 생성된다.

그리고 content script에서 다음처럼 import 했다:

//content/index.js
import tailwindCss from "../global.css?inline";

const style = document.createElement("style");
style.textContent = tailwindCss;
document.head.appendChild(style);

그리고 확인해보면?

이렇게 깔끔하게 적용이 된걸 확인할수 있다.

또다른 문제

“한 문제를 해결했다고 안심할 때쯤, 또 다른 문제가 그 틈을 비집고 들어온다.”

그렇다. 나름 잘되어가고있다고 자신만만할 즈음 또 다른 문제가 나왔다.. 어느때처럼 쇼핑을 하던와중 웹사이트가 이상하다는걸 느꼈다.

응? 아이콘 위치가 이상한데? 익스텐션을 삭제해볼까? (제발..)

왜 또다른 문제가 나오는것이냐.. 나 너무 힘들어..

//tailwind.config.js
module.exports = {
  prefix: "ex-tw-",
  corePlugins: { preflight: false },
};

GPT를 통해 해결책을 들었으나, 이렇게 설정한다고 결과는 달라지지 않았다. 그럼 어떻게 해야할까?

또 다시 해결

방법은 생각보다 간단했다. 웹페이지에 직접 Tailwind를 삽입할 필요가 없었다. 대신 iframe 을 하나 만들어 완전히 격리된 환경에서 사용하는 방식으로 해결할 수 있었다.

//content/index.js
function createInspectorIframe() {
   const iframe = document.createElement("iframe");
   iframe.id = "tw-inspector-iframe";

   Object.assign(iframe.style, {
      position: "fixed",
      inset: "0",
      zIndex: "2147483647",
      border: "none",
      width: "100vw",
      height: "100vh",
      display: "none",
      pointerEvents: "none",
   });
   document.body.appendChild(iframe);

   const iframeDoc = iframe.contentDocument!;
   iframeDoc.open();
   iframeDoc.write("<!DOCTYPE html><html><head></head><body></body></html>");
   iframeDoc.close();

   // Tailwind 주입
   const styleEl = iframeDoc.createElement("style");
   styleEl.textContent = tailwindCss;
   iframeDoc.head.appendChild(styleEl);

   injectFonts(iframeDoc);

   const resetEl = iframeDoc.createElement("style");
   resetEl.textContent = `
    html, body {
      margin: 0; padding: 0;
      background: transparent;
      overflow: hidden;
      width: 100%; height: 100%;
    }
    * { box-sizing: border-box; }
  `;
   iframeDoc.head.appendChild(resetEl);

   const mountEl = iframeDoc.createElement("div");
   iframeDoc.body.appendChild(mountEl);

   return { iframe, iframeDoc, mountEl };
}

끝으로..

쉐도우 DOM이니 뭐니 여러 가지 방법을 시도해봤지만, 결국 이 방식이 가장 깔끔했다. 빠르게 후딱 끝내려던 토이 프로젝트였는데, 생각보다 진전이 더뎠다. (찍먹하려다 실패) 예기치 못한 문제들이 계속 발생했고, 이렇게 글로 정리해보니 짧아 보이지만 실제로는 꽤 많은 시간이 걸렸다. 그래도 결국 해결됐으니 해피엔딩! 이제 다음 챕터에서는 Converter 완성 과정을 정리해보려 한다. ㄱㄱ

1. 동기

• 사이드 프로젝트를 여러 개 진행하다 보니 항상 Tailwind CSS를 사용하게 되었다. 많이 쓰다 보니 손에 익기도 했고 더 잘 활용하고 싶어서 프로젝트마다 도입했는데, 문제는 CSS 자체보다 UI 작업이었다.
• 디자인 지식이 전무하다 보니 다른 사이트 UI를 참고하게 되었고, 그 과정에서 매번 개발자 도구 → 요소 선택 → CSS 확인 절차를 반복하는 게 너무 번거로웠다.
• 이 불편함을 해결하기 위해, 크롬 확장 프로그램을 직접 만들어보기로 했다.

  2. 목표

• 앞으로도 계속 Tailwind CSS를 사용할 것 같아, 나 자신이 편하게 쓰고 다른 사람도 활용할 수 있도록 크롬 익스텐션 출시를 목표로 개발하기로 했다.
• 일단 자그마한 기능만 개발해서 출시하고 계속해서 기능을 추가하는것으로 목적을 두었다.

  3. 다루는 범위

• Vite + React 환경 설정
• manifest.json 기본 구성
• 간단한 기능을 만들어 크롬에 등록하고 동작 여부 확인

프로젝트 구조와 설명

tailwind-extension ├── eslint.config.js ├── package-lock.json ├── package.json ├── postcss.config.cjs ├── public │ ├── icon.png │ └── manifest.json ├── src │ ├── background.ts │ ├── content │ │ ├── index.tsx │ │ └── inspector.ts │ ├── index.css │ ├── options │ │ ├── Options.tsx │ │ ├── index.html │ │ └── index.tsx │ ├── popup │ │ ├── Popup.tsx │ │ ├── index.html │ │ └── index.tsx │ └── vite-env.d.ts ├── tailwind.config.js ├── tsconfig.app.json ├── tsconfig.json ├── tsconfig.node.json ├── vite.config.ts └── vite.content.config.ts

기본 파일 구조와 역할

간단한 기능을 만들고 직접 확인해보려면
먼저 프로젝트의 파일 구조를 이해하는 것이 중요하다.

아래는 기본적인 크롬 익스텐션 구조이며,
각 폴더와 파일이 어떤 역할을 하는지 간단히 살펴보자.

manifest.json

확장의 모든 정보를 담은 설정 파일. name, version, permissions, entry scripts 등 확장의 동작에 필요한 정보를 정의한다.

vite.config.ts

Vite를 이용한 번들러 설정 파일. 크롬 익스텐션은 여러 진입점(popup, content, background 등)을 가지므로
multi-entry 빌드 설정이 필요하다.

background

항상 실행되는 서비스 워커(Service Worker) 폴더.
알림, 메시지 통신, 이벤트 처리 등 백그라운드 로직을 담당한다.

content

사용자가 보고 있는 웹페이지에 직접 삽입되는 코드. DOM 조작이나 UI 변경 등 화면 상의 인터랙션 처리를 담당한다.

말 그대로 “내용물”이며, 사용자의 화면에 무언가를 보여주고 싶을 때 이 부분을 수정한다.

popup

브라우저 상단 확장 아이콘을 클릭했을 때 나타나는 팝업 UI.

크롬 우측 상단에 있는 익스텐션 아이콘을 클릭했을 때 열리는 작은 창을 구성한다.

options

확장 프로그램의 설정 페이지. 사용자가 직접 환경을 바꾸거나 옵션을 저장할 수 있는 페이지를 담당한다.

빌드 및 결과물 확인

이제 기본적인 설정이 모두 끝났다면,
npm run build 명령어로 빌드를 진행해보자.

dist/ ├── assets/ │ ├── index-C8iq0p5x.js │ └── index-EhWt2fYy.css ├── background.js ├── content.css ├── content.js ├── icon.png ├── manifest.json ├── options/ │ ├── index.html │ └── options.js └── popup/ ├── index.html └── popup.js

이런 식으로 vite.config.js 의 설정을 기반으로
익스텐션에 등록할 빌드 파일들이 자동으로 생성된다.

하지만 여기서 가장 중요한 점은,
빌드 후에 manifest.json 설정이 제대로 되어 있는지 꼭 확인해야 한다는 것이다.

크롬은 익스텐션을 로드할 때
manifest.json을 기준으로 각 스크립트와 리소스를 불러오기 때문에,
이 설정이 잘못되어 있으면 익스텐션이 정상적으로 동작하지 않는다.

(직접 겪어봤는데… manifest 설정이 꼬이면
아무 반응이 없는 익스텐션 아이콘만 덩그러니 남는다 )

js // manifest.json 설정예시 { "manifest_version": 3, "name": "Tailwind Chrome Extension", "version": "1.0.0", "description": "TailwindCSS 기반 React 크롬 확장 프로그램", "action": { "default_popup": "popup/index.html" }, "options_page": "options/index.html", "background": { "service_worker": "background.js", "type": "module" }, "content_scripts": [ { "matches": ["http:///", "https:///"], "js": ["content.js"], "css": ["content.css"] } ], "permissions": ["contextMenus", "storage", "activeTab", "scripting"], "icons": { "16": "icon.png", "48": "icon.png", "128": "icon.png" } }

크롬 익스텐션 등록하기

번들러 설정과 manifest.json 구성이 모두 끝났다면,
이제 내가 만든 크롬 익스텐션을 직접 확인해보자.

1. 크롬 확장 페이지로 이동

주소창에 chrome://extensions 입력을 한다

2. dist 폴더 등록하기

상단의 ‘압축해제된 확장 프로그램 로드’ 버튼을 클릭하고,
빌드 결과물로 생성된 dist 폴더를 선택하면 된다.

이렇게 하면 우리가 익숙하게 알고 있는 형태로
확장 프로그램이 크롬에 등록된다

참고

여기서는 과정을 간단히 요약했지만, 자세한 내용은 Chrome 공식 문서에서 더 친절하게 확인할 수 있다.

✅ 정리

이번글에선

• 설정
• 빌드
• 크롬 등록

까지의 기본적인 흐름을 다루었다.

다음 챕터에서는 Tailwind 변환 로직과 이를 사용자에게 시각적으로 보여주는 UI 구성을 중심으로 포스팅을 할 예정이다

React Query와 Next.js를 기반으로 블로그 프로젝트를 진행하며 이제 마무리 단계에 들어섰다.
최근에는 SEO 최적화 과정에서 조금 더 효율적으로 데이터 패칭을 활용할 수 있는 방법을 고민하다가, ISR(Incremental Static Regeneration)을 도입하기로 했다.

ISR은 정적 페이지를 생성한 뒤, 설정한 주기마다 자동으로 새 데이터로 갱신해주는 기능이다. (GPT)

그래서 자주 변경되지 않는 페이지를 대상으로 ISR을 적용해보기로 했다.

TroubleShooting

잘 모르고 사용했던 부분

처음엔 이렇게 코드를 작성했다:

export async function fetchProfile() {
  const url = `/api/profile`;

  const res = await fetch(url, {
    next: { revalidate: 600 },
  });

  return res.json();
}

페이지는 SSR로 해두었고 fetch에서 revalidate: 600을 주면, 해당 페이지에서 쓰이는 React Query가 invalidate를 해도 600초 동안은 동일한 데이터를 주는 줄 알았다.

하지만 실제로는 그렇지 않았고 ISR 이해를 잘 못했던것 같다.

알게된 점

• revalidate 옵션은 Next.js 서버에서 실행될 때만 캐싱이 적용된다.

• 클라이언트에서 fetch를 호출하면 단순 브라우저 fetch → 항상 네트워크 요청.
• 따라서 React Query에서 invalidate를 호출하면 무조건 API를 다시 치고 최신 DB 데이터를 가져오게 된다.

즉, 클라이언트 캐시(React Query)와 서버 캐시(ISR)는 별개라는 걸 알게 되었다.

ISR은 어떻게 적용할까? 실제로 ISR을 적용하려면 두 가지 방법이 있다.

// ✅ 페이지 단위 ISR
export const revalidate = 300;

export default async function Profile() {
  const profile = await prisma.profile.findFirst({});
  return <ProfileItem profile={profile} />;
}

// ✅ 페이지 단위 ISR
export default async function Profile() {
  const res = await fetch(`${process.env.NEXTAUTH_URL}/api/profile`, {
    next: { revalidate: 300 },
  });
  const profile = await res.json();
  return <ProfileItem profile={profile} />;
}

직접 사용해보기

npm run build 후 결과를 보면, export const revalidate = 300을 적용했을 때 5m 이라는 문구가 표시되며 페이지가 5분 주기로 캐싱되는 걸 확인할 수 있었다. 그리고 muate 하고 새로고침을 눌렀을때 화면이 변하지 않는다는것을 두눈으로 직접 확인할수 있었다.

그렇다면 화면에는 어떻게 업데이트된 내용을 반영할 수 있을까? 방법은 의외로 간단했다. next/cache에서 제공하는 기능을 활용하면 된다. API 내부에서 revalidatePath("/profile")를 호출하면, 마치 React Query의 InvalidateQueries처럼 캐시가 무효화되고 새로운 데이터로 갱신되는 것을 확인할 수 있었다.

Next.js에서 제공하는 revalidatePath는 서버 캐시에 저장된 페이지를 강제로 무효화(재검증)하는 함수다.
ISR을 적용한 페이지는 보통 revalidate로 설정한 주기마다 새로운 데이터를 가져오지만, revalidatePath를 사용하면 주기와 상관없이 즉시 최신 데이터로 갱신할 수 있다. 예를 들어, /profile 페이지가 export const revalidate = 300; 으로 설정되어 있다면 기본적으로는 300초(5분)마다 새로운 데이터를 패칭한다. 하지만 사용자가 프로필을 수정하는 API를 호출할 때, 다음과 같이 revalidatePath 를 실행하면 300초를 기다리지 않아도 즉시 새로운 데이터로 갱신된다.

Conclusion

돌아보니 너무 복잡하게 생각했던 것 같다. 이번 과정을 통해 React Query가 정말 잘 만든 라이브러리라는 걸 다시 한번 느꼈다. 웬만한 상황은 클라이언트 단에서 충분히 해결할 수 있기 때문이다.

또한 캐싱을 다룰 때는 클라이언트 레이어와 서버 레이어의 의미를 명확히 구분하고, 상황에 맞게 사용하는 것이 중요하다는 것도 깨달았다.

마지막으로 ISR을 적절히 활용하면서 Lighthouse 점수도 80점대까지 끌어올릴 수 있었다는 점에서, 성능 최적화 측면에서도 큰 효과를 얻을 수 있었다.

사이드 프로젝트 진행하다가 발생한 문제는 아니고 문득 GPT에게 이것저것 질문을 하던중 usememo, usecallback, React.memo를 이용한 렌더링 최적화 주제가 나왔었다. 아차 싶었다.. 내가 데이터를 받아서 컴포넌트를 뿌려줄때 해당 컴포넌트에 그런 처리를 해줬던가? 사이드 프로젝트에서 제일 많이 쓰이는 컴포넌트를 확인해봤다.

const TagItem = (props: AnyTagItemProps) => {
  return (
    <>
      <Badge
        theme={{
          root: {
            color: {
              gray: "bg-gray-100 text-gray-800 hover:bg-gray-200 dark:bg-gray-700 dark:text-gray-300 dark:hover:bg-gray-600",
              cyan: "bg-cyan-100 text-cyan-800 hover:bg-cyan-200 dark:bg-cyan-200 dark:text-cyan-900 dark:hover:bg-cyan-300",
            },
          },
        }}
        color={
          props.mode == "check" ? (props.isChecked ? "cyan" : "gray") : "cyan"
        }
        size="md"
      >
        <button className="cursor-pointer" onClick={props.clickEvt}>
          {props.text}
        </button>
      </Badge>
    </>
  );
};

export default TagItem;

그런거 안되어있네.. React Developer Tools 을 사용하여 확인해보자. TagItem 컴포넌트는 PostFilter의 자식으로 사용 중인데, 부모에서 내려주는 checked props 값이 바뀔 때마다 모든 TagItem이 함께 리렌더링되는 문제가 있었다. 그럼 어떻게 해야 할까?

TroubleShooting

처음에 말했던 내용처럼 React.memo를 사용하여 TagItem을

export default memo(TagItem, (prev, next) => {
  if (prev.mode !== next.mode) return false;
  if (prev.mode === "check" && next.mode === "check") {
    if (prev.isChecked !== next.isChecked) return false;
  }
  if (prev.text !== next.text) return false;
  if (prev.id !== next.id) return false;
  if (prev.body !== next.body) return false; // body 비교 추가
  if (prev.clickEvt !== next.clickEvt) return false;
  if (prev.clickValueType !== next.clickValueType) return false;
  return true;
});

이렇게 감싸주었고 clickEvt 함수 prop이라 부모 컴포넌트에서 해당 함수를 useCallback 처리를 해서 전달해주었다. 그랬더니 짜잔 TagItem을 라디오 버튼처럼 쓰고 있었는데, 생각해보니 체크가 바뀔 때 필요한 건 새로 선택된 애랑 기존에 선택 해제되는 애, 딱 두 개뿐이었다. 굳이 전부 리렌더링될 필요가 없었고, 체크된 거랑 해제된 거만 바꿔주면 충분했고 위 이미저처럼 만족스럽게 바뀌었다.

그럼 memo는 뭐길래 컴퍼넌트를 감싸주면 리렌더링이 방지되는 것일까? GPT에게 물어보자.

React.memo는 컴포넌트가 받은 props를 얕게(shallow) 비교해서 값이 안 바뀌면 이전 렌더링 결과를 그대로 재사용한다. 그래서 실제로 바뀐 props가 있을 때만 리렌더링이 일어난다.

그럼 useCallback은 왜쓰는걸까?

부모가 리렌더링되면, 그 안에서 새로 정의된 함수는 매번 새로운 참조(주소)를 갖게되고 이 함수를 자식 컴포넌트에 props로 넘기면, 자식 입장에서는 "props가 바뀌었다"고 판단해서 불필요하게 리렌더링될 수 있음. useCallback으로 감싸면 함수 참조를 메모이제이션해서, deps가 변하지 않는 이상 같은 함수 객체를 계속 쓰게 된다.

Conclusion

부끄럽지만 내 사이드 프로젝트에서는 React.memo, useCallback, useMemo를 제대로 활용하지 못했었다. 예전에 설명과 예제를 흘려보듯 본 적은 있었지만 크게 와닿지는 않았었다. 그런데 이번 프로젝트에서 직접 적용해보면서, 이게 얼마나 중요한 부분이고 또 리액트에서 리렌더링 최적화를 얼마나 세심하게 신경 써야 하는지 뼈저리게 느끼게 되었다.

지난번에 이어 사이드 프로젝트를 진행하던 중 한 가지 놓치고 있던 부분이 있었다. 바로 useInfiniteQuery를 사용해 무한 스크롤을 구현할 때, API로부터 데이터를 받아오지 못했을 경우 어떻게 처리해야 하는가라는 점이다.

무한 스크롤은 기본적으로 사용자가 스크롤을 내릴 때마다 새로운 페이지를 불러와 이어 붙이는 방식이다. 그런데 네트워크 오류나 서버 문제로 인해 다음 데이터를 가져오지 못한다면, UI가 멈추거나 빈 화면이 보이는 경험을 주어서는 안 된다. (GPT에게 물어보니 그렇다한다 ㅋㅋ;)

일단 피드를 불러오는 API응답값을 이렇게 바꿨다

  if(pageNumber) throw new Error('error!!')
  return NextResponse.json({
      ok: true,
      data: postData,
      totalCount,
    });
  } catch (e: any) {
    return NextResponse.json({ ok: false, error: e.message }, { status: 500 });
  } finally {
  }

그리고 상황을 얼추 맞추기위해서 다음 데이터를 불러올때 throw를 주었다. 위처럼 데이터를 2번 요청했을때 에러가 났다는걸 볼수 있었다. 이제 클릭하면 실패한 부분을 다시 fetch 하겠지? 엥 ? 클릭했는데 아무런 반응이 없는것이였다.. 이게 뭐지 싶어 동작하는 부분의 코드를 찍어봤는데 lastPage를 체크해주는 코드에서 ok가 false라서 undefined가 나고 막혀서 더이상 fetch를 진행하지 않는것이였다. 그럼 어떡하지? GPT한테 물어봤는데 nextFetch만 하면된단다(...)

TroubleShooting

GPT한테 답을 얻을수 없어서 이걸 refetch를 해야하나? 그렇게 하긴 싫은데..라고 생각하며 끙끙 거리고있을때 lastPage를 어떻게 하면 다시 그대로 fetch할수 있지 않을까 하고 GPT를 달달 볶던중 키워드를 얻고 해당 정보를 얻을수 있었다. 그렇다면 setQueryData를 사용해 실패한 데이터를 지운다면 lastPage가 바뀌지않을까? 그래서 버튼의 이벤트를 fetchNextPage 대신 이런식으로 이렇게 바꿔주었고 두근거리는 마음으로 버튼을 다시 클릭하자 이런식으로 실패한 page=1이 재요청 되는걸 확인할수 있었다.

Conclusion

간단하게만 생각했는데 막상 해보니 생각보다 까다로웠다. API로부터 데이터를 받아 화면에 뿌려주는 것까지는 비교적 단순하고 예상도 가능했지만, 내가 직접 API를 짜는 데 서툴기도 하고, 상황에 따라 발생하는 오류를 어떻게 처리해 사용자와 개발자 모두에게 자연스럽게 보여줄지가 정말 어렵게 느껴졌다. 지금 시도하고 있는 방식이 정답인지는 잘 모르겠지만, 일단 해야 할 일이 많으니 다음 단계로 나아가 보려고 한다.