1️⃣ 크롤링 구현

웹 크롤링 기능을 구현하기 위해 cheerio 라이브러리를 사용했다. 전체 흐름은 URL 패칭 → HTML 파싱 → 노이즈 제거 → 본문 영역 탐색 → 텍스트 정제 5단계로 구성된다.

URL 패칭

const response = await axios.get(url, {
  timeout: 10000,
  headers: {
    'User-Agent': 'Mozilla/5.0 (compatible; YojeongBot/1.0)',
     Accept: 'text/html,application/xhtml+xml',
    'Accept-Language': 'ko-KR,ko;q=0.9,en;q=0.8'
  },
  maxRedirects: 5,
  responseType: 'text'
});

axios.get으로 HTML을 가져온다. 한국어 콘텐츠 대상이라 Accept-Language: ko-KR을 설정하고, 10초 타임아웃과 최대 5회 리다이렉트를 허용한다.

HTML 파싱

const html = response.data;

if (!html || typeof html !== 'string') {
  return { status: 'fetch_failed', content: null };
}

cheerio.load(html)로 서버사이드 DOM을 생성한다. cheerio는 jQuery 스타일 API를 제공하는 경량 HTML 파서로, 브라우저 없이 DOM 조작이 가능하다.

노이즈 제거

/** HTML에서 본문 텍스트를 추출 (CONTENT_SELECTORS 우선 탐색 → 실패 시 body 전체) */
export function extractText($: cheerio.CheerioAPI): string {
  $(REMOVE_SELECTORS.join(', ')).remove();

  for (const selector of CONTENT_SELECTORS) {
    const el = $(selector);
    if (el.length > 0) {
      const text = el.first().text();
      const cleaned = cleanText(text);
      if (cleaned.length > 0) {
        return cleaned;
      }
    }
  }

  return cleanText($('body').text());
}

상수 REMOVE_SELECTORS에 정의된 요소들(script, style, nav, header, footer ...)을 DOM에서 먼저 제거한다. 본문과 무관한 UI/광고/댓글 영역을 사전에 걸러내는 단계이다.

본문 영역 탐색

CONTENT_SELECTORS 배열(article → [role="main"] → main → .post-content → .entry-content 등)을 순서대로 탐색한다. 먼저 매칭되면서 텍스트가 1,000자 이상인 셀렉터의 본문을 채택한다. 모든 셀렉터가 실패하면 body 전체 텍스트를 fallback으로 사용한다.

텍스트 정제

/** 연속 공백/개행을 정리하여 깔끔한 텍스트로 변환 */
export function cleanText(raw: string): string {
  return raw
    .replace(/\n{3,}/g, '\n\n')       // 3줄 이상 연속 개행 → 2줄로 축소
    .replace(/[^\S\n]+/g, ' ')        // 개행 제외 연속 공백 → 단일 공백
    .trim();
}

3줄 이상 연속 개행을 2줄로, 연속 공백을 단일 공백으로 정규식 치환하여 깔끔한 텍스트를 만든다.

2️⃣ 원문 처리

단순히 링크 입력 + 크롤링 기능만 추가하면 될 것 같았지만 생각해야할 부분이 너무 많았다. 그 중 첫 번째는 가져온 원문이 요약 가능한 글인지에 대한 확인 여부였다. 처음엔 크롤링 기능만 구현하려 했으나 요약이 충분히 가능한 글인지에 대한 검증을 거치지 않으면 사용자가 실수로 다른 링크를 넣었거나, 원치 않는 분석 결과를 얻게 될 경우에 대한 처리가 불가하다고 판단했다.

AI 없이 판단 가능한 것들

• 로그인 필요: HTTP 응답 코드가 401, 403이거나 로그인 페이지로 리다이렉트된 경우
• 페이지 자체를 못 가져옴: 404, 500 등
• 텍스트가 너무 적음: 추출된 텍스트가 N자 미만이면 "내용이 부족하다"고 판단
• JS로만 렌더링되는 SPA: fetch로 받은 HTML에 본문이 거의 없는 경우

  AI 없이는 애매한 것들

• 텍스트는 있는데 의미 있는 글이 아닌 경우 (상품 목록, 버튼 텍스트 모음 등)
• 텍스트 양은 충분한데 요약할만한 내러티브가 없는 경우

그렇게 ai를 활용하기로 결정했고, 우선 ai에게 내가 긴 글이 포함되지 않은 링크를 주며 요약을 부탁하면 너는 어떻게 판단해? 라고 물어봤다. 니가 해야될 일이니까....

글이 없는 링크의 경우

예를 들어 쇼핑몰 상품 페이지라면 요약이라는 개념 자체가 맞지 않으니 대신 가져온 내용 기반으로 상품명, 가격, 주요 스펙, 특징 같은 걸 정리하는 방식으로 자연스럽게 전환된다.

페이지를 아예 못 읽는 경우

로그인이 필요한 페이지이거나, JavaScript로만 렌더링되는 SPA라서 콘텐츠가 없거나, 접근 자체가 막힌 경우엔 페이지의 내용을 가져올 수 없다고 전달하고 가능하면 대안을 제안한다.

읽을 수 있지만 내용이 빈약한 경우

가져온 HTML에 텍스트가 거의 없거나 메타 정보만 있는 경우엔 그 정보 내에서 최대한 파악한 걸 알려주지만, 충분한 정보가 없어 한계가 있다고 함께 전달한다.

링크를 받으면 무조건 요약이 아닌 가져온 내용의 성격에 맞게 응답 방식을 조정하는 것이라고 한다.

원문 글자 수 검증

기존의 원문을 직접 작성하던 방식에선 원문의 길이를 1000자 이상, 5000자 이하로 제한해두었기 때문에 크롤링해 가져온 원문에도 동일한 제한을 두기로 했다. 원문을 추출한 뒤 글자 수가 5000자가 넘으면 slice 함수로 원문을 잘랐고, 1000자 미만이면 요약 불가로 처리하기로 결정했다.

3️⃣ API 명세

위 1번에서의 경우들을 전부 따졌을 때 총 5가지의 경우로 나뉜다고 판단했고, 사용자에게 추출된 원문에 대한 상태를 텍스트로 제시하기 위해 위의 각 상태를 api 응답에 추가하기로 했다.

Response: 200 OK
{
  success: true,
  data: {
    status: "success" | "truncated" | "under_limit" | "unsuitable_content" | "fetch_failed",
    content: string | null  // fetch_failed, under_limit일 경우 null
  }
}

• success : 1000 ~ 5000자 범위로 원문이 정상 추출됨
• truncated : 원문이 정상적으로 추출되었으나 5000자 초과로 잘림
• under_limit : 1000자 미만으로 요약 불가
• unsuitable_content : 텍스트는 있으나 요약하기 어려운 내용
• fetch_failed : 페이지 접근 불가 (로그인 필요, 404 등)

// src/constants/message.ts

export const MESSAGE = {
  EXTRACT: {
    SUCCESS: '원문을 불러왔어요!',
    TRUNCATED: '원문을 불러왔어요! 원문이 길어 앞 5000자만 분석에 사용돼요.',
    UNSUITABLE: '요약하기 적합하지 않은 글이에요. 요약 결과가 다소 부정확할 수 있어요.',

    UNDER_LIMIT: '원문이 너무 짧아 분석이 어려워요. (1000자 이상의 글을 입력해주세요.)',
    FAILED: '페이지를 불러올 수 없어요. 링크를 다시 확인해주세요.',
  },
};


// src/hooks/extract/useExtractStatus.ts

interface ExtractStatusResult {
  isUsable: boolean;
  message: string;
}

const STATUS_MAP: Record<ExtractStatus, ExtractStatusResult> = {
  success: { isUsable: true, message: MESSAGE.EXTRACT.SUCCESS },
  truncated: { isUsable: true, message: MESSAGE.EXTRACT.TRUNCATED },
  unsuitable_content: { isUsable: true, message: MESSAGE.EXTRACT.UNSUITABLE },
  under_limit: { isUsable: false, message: MESSAGE.EXTRACT.UNDER_LIMIT },
  fetch_failed: { isUsable: false, message: MESSAGE.EXTRACT.FAILED },
};

export const useExtractStatus = (status: ExtractStatus | null): ExtractStatusResult | null => {
  if (!status) return null;
  return STATUS_MAP[status];
};

각 상태에 따른 메세지를 상수로 분리했고, api 응답의 상태 값을 인자로 받아 원문 요약 가능 여부와 메세지를 한 번에 리턴받을 수 있도록 useExtractStatus 훅을 작성했다.

이후 페이지 전환에 사용하기 위해 원문이 1000자 미만인 under_limit, 원문 추출에 실패한 fetch_failed는 isUsable 값을 false로 처리했다.

4️⃣ 요약 가능 판단 프롬프트

ai에게 텍스트 품질 검증 전문가라는 직업을 심어주었고... 요약이 가능할 만한 글인지에 대한 여부와 그에 대한 간단한 이유를 JSON 형식으로 반환하도록 작성했다.

## 판단 기준

위 텍스트가 **요약할 만한 의미 있는 본문**인지 판단하세요.

**isSuitable: true 인 경우:**
- 기사, 블로그 글, 에세이, 논설문 등 논리적 구조가 있는 글
- 특정 주제에 대해 설명하거나 주장하는 글
- 읽고 요약할 수 있는 충분한 내용이 있는 글

**isSuitable: false 인 경우:**
- 네비게이션 메뉴, 버튼 텍스트, 링크 목록 등 UI 요소의 나열
- 로그인 폼, 에러 페이지, 검색 결과 목록 등 구조적 페이지
- 상품 스펙, 가격표 등 단순 데이터 나열
- 의미 없는 텍스트 조각이나 깨진 인코딩
- 여러 글의 제목/미리보기만 나열된 목록형 페이지

---

## 출력 형식 (JSON만 반환)

{
  "isSuitable": true 또는 false,
  "reason": "판단 이유를 한 문장으로 간단히 설명"
}

추출된 원문이 1000자 이상일 때 위의 프롬프트를 통해 요약 적합성을 판단한 후, isSuitable이 false이면 unsuitable_content를 반환, true이면 5000자 이하인지 검증하는 구조이다.

5️⃣ UX 개선

원문 처리 다음으로 고민한 부분...

기존 페이지는 원문 작성 페이지와 요약 작성 페이지가 분리되어 있었고, 요약 작성 페이지에서 로컬 스토리지를 통해 이전 페이지의 원문 값을 가져와 요약 분석 요청 api에 함께 보내는 구조였다.

원문과 로컬 스토리지 값 동기화

원문 작성만 존재할 땐 사용자가 입력한 값을 그대로 저장하면 됐기 때문에 문제가 없었지만, 링크 입력 방식이 추가되면서 각 모드에 맞게 로컬 스토리지와 원문 값을 일치시켜야 하는 문제가 생겼다.

• 원문 작성 모드 : 사용자가 textarea에 직접 입력한 값이 state로 관리되는 userContent(원문)에 들어감.
• 링크 입력 모드 : 크롤링 API 응답으로 추출된 원문이 setUserContent(res.data.content)로 들어감. 하지만 링크 모드일 때는 textarea가 렌더링되지 않기 때문에 화면에 보이지 않고 내부적으로만 보관됨.

원문 데이터는 다음 단계 버튼을 눌러야 로컬 스토리지에 저장되는데, 링크 모드로 원문 추출 -> 다음 페이지로 이동한 뒤 다시 원문 작성 페이지로 돌아옴 -> 원문 작성 모드로 전환 과 같은 흐름이 이어진다면 원문 작성 textarea에 링크 모드로 추출된 원문 값이 남아있는 문제가 생긴다.

위 문제 해결을 위해 모드 전환 시 사용자에게 모달을 제시하도록 했다. 확인 버튼을 누르면 url, 원문, 추출 상태, 로컬 스토리지 값을 모두 비운다.

// 전체 데이터 흐름

[원문 입력 페이지]
   │
   ├─ 링크 모드: URL 입력 → 크롤링 API → userContent에 추출 원문 저장 (화면에는 미표시)
   ├─ 텍스트 모드: textarea 입력 → userContent에 직접 저장
   │
   ├─ 모드 전환 (입력값 있을 때) → 모달 확인 → state + localStorage 초기화
   │
   ├─ "다음 단계로" 클릭 → localStorage에 저장 → /summary 이동
   │
   └─ 뒤로 가기로 재진입 → useEffect에서 localStorage 복원

[요약 입력 페이지]
   │
   ├─ useEffect에서 localStorage 읽기 → 원문 없으면 /input으로 리다이렉트
   │
   └─ "AI 분석 시작" 클릭 → API 호출 → localStorage 삭제 → 메인으로 이동

원문 추출 후 링크 수정 방지

만약 원문 추출이 완료된 이후 링크 값을 수정한다면 링크와 추출된 원문 값 사이에 불일치 문제가 생기게 된다. 해당 문제가 일어나지 않도록 원문 추출 여부 상태 값 isContentLoaded을 선언했고, 이를 링크 input 컴포넌트의 readonly 속성에 사용했다.

<Input
  id="url"
  type="url"
  placeholder="https://example.com/article"
  value={url}
  onChange={(e) => setUrl(e.target.value)}
  readOnly={isContentLoaded}
  className={`... ${isContentLoaded ? 'bg-app-gray-50 cursor-not-allowed' : ''}`}
/>

추출이 완료되면 Input은 읽기 전용으로 잠기고, 배경 색이 바뀌어 시각적으로도 수정 불가 상태가 된다. 원문 추출 버튼도 isContentLoaded 값에 따라 전환된다.

{isContentLoaded ? (
  <Button onClick={resetInputText}>
    <RefreshCw className="w-4 h-4 mr-2" />
    수정
  </Button>
) : (
  <Button
    onClick={handleExtract}
    disabled={!isValidUrl(url) || isExtracting}
  >
    {isExtracting ? '불러오는 중...' : '원문 불러오기'}
  </Button>
)}

• 추출 전 : 원문 불러오기 버튼이 표시됨. isValidUrl(url)로 URL 형식이 유효한지 검증하고, 유효하지 않으면 버튼 비활성화
• 추출 후 : 수정 버튼으로 전환됨. 클릭하면 resetInputText()가 호출되어 URL, 원문, 추출 상태가 모두 초기화되고 처음부터 다시 입력 가능

URL을 부분 수정하는 것은 허용하지 않고, 초기화 후 새로 입력하는 방식으로 링크와 원문 간의 불일치 문제를 원천 차단했다. 👍

서버 컴포넌트 마이그레이션

기존 search/page.tsx는 전체가 'use client'였다. 이는 다음 문제를 야기한다.

• 첫 페이지 데이터를 브라우저에서 fetch → 초기 로딩 느림
• API 키가 NEXT_PUBLIC_으로 브라우저에 노출
• Google API를 브라우저에서 직접 호출 → Referer 차단 이슈

CSR로만 구현하면 초기 로딩 시 빈 화면이 잠깐 노출되거나 초기 로딩이 느린 이슈가 생길 수 있다. 이번 업데이트된 기능들을 사용하여 첫 페이지는 서버 컴포넌트, 두 번째 페이지부터는 클라이언트에서 가져오도록 마이그레이션하기로 했다!

서버 컴포넌트 vs 클라이언트 컴포넌트

use cache

'use cache'는 Next.js 16에서 정식 도입된 캐싱 문법이다. 함수 상단에 선언하면 동일한 인자로 호출 시 캐시된 결과를 반환한다. 기존 fetch의 cache 옵션은 fetch 단위에서만 동작하지만, 'use cache'는 어떤 비동기 함수에도 적용할 수 있다. next.config.ts에서 cacheComponents: true 활성화가 필요하다.

// api/serverSearch.ts

export const fetchNewsFirstPage = async (query: string, sort: string): Promise<NewsResponse> => {
  'use cache'; // 같은 query + sort 조합이면 재요청 없이 캐시 반환

  const res = await fetch(
    `https://openapi.naver.com/v1/search/news.json?query=${encodeURIComponent(query)}&display=${PAGE_ELEMENT}&start=1&sort=${sort}`,
    {
      headers: {
        'X-Naver-Client-Id': ENV.NAVER_CLIENT_ID,
        'X-Naver-Client-Secret': ENV.NAVER_CLIENT_SECRET,
      },
    },
  );

  return res.json();
};

이 데이터는 HTML에 직접 포함되어 내려오므로, 사용자는 JS 번들이 로드되기 전에도 첫 20개의 뉴스를 볼 수 있다. 서버 컴포넌트는 이를 initialData로 클라이언트 컴포넌트에 전달한다.

// app/search/page.tsx

export default async function Search({
  searchParams,
}: {
  searchParams: Promise<{ query?: string; sort?: 'sim' | 'date' }>;
}) {
  const { query = '', sort = 'sim' } = await searchParams;
  const initialData = query ? await fetchNewsFirstPage(query, sort) : null;

  return <NewsSearchClient query={query} sort={sort} initialData={initialData} />;
}

NewsSearchClient 컴포넌트는 initialData를 useNewsListQuery 훅에 넘기는데, 내부적으로 TanStack Query의 useInfiniteQuery가 이 데이터를 첫 번째 페이지의 캐시로 등록한다. 덕분에 하이드레이션 후에도 불필요한 재요청이 발생하지 않는다.

적용 이후 FCP 값이 3.3s에서 2.4s로 약 27%, LCP 값은 17.2s에서 6.2s로 약 64% 개선되었다!

route handler

route handler는 v16 업데이트 내용은 아니지만, 파라미터로 key 값을 넘겨줘야 하기 때문에 브라우저에 해당 값이 노출되던 기존 google api 호출 방식의 문제를 해결하기 위해 도입했다.

app/api/*/route.ts 파일로 만드는 서버 전용 API 엔드포인트다. 브라우저가 외부 API를 직접 호출하는 대신 서버를 거치도록 중간 역할을 한다.

디렉토리 경로가 곧 URL의 경로이며, route.ts라는 이름 자체가 이 경로의 핸들러라는 뜻이 된다.

app/api/sentiment/route.ts
         ↓
URL: /api/sentiment

그리고 export된 함수의 이름이 HTTP의 메서드가 된다.

export async function GET()    → GET  /api/sentiment
export async function POST()   → POST /api/sentiment
export async function DELETE() → DELETE /api/sentiment

// app/api/sentiment/route.ts

export const POST = async (req: NextRequest) => {
  const body = await req.json();
  const key = ENV.GOOGLE_API_KEY; // 서버에만 존재하는 환경변수

  const res = await fetch(`https://language.googleapis.com/v2/documents:analyzeSentiment?key=${key}`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(body),
  });

  const data = await res.json();
  return NextResponse.json(data, { status: res.status });
};



// api/sentiment.ts

export const postAnalyzeSentiment = async (text: string) => {
  const { data } = await axios.post<SentimentResponse>('/api/sentiment', {
    encodingType: 'UTF8',
    document: {
      type: 'PLAIN_TEXT',
      content: text,
    },
  });

  return data;
};

route handler를 두어 google api 호출을 서버로 옮겼다. API 키는 env 파일에서 읽어오므로 클라이언트에 노출되지 않는다!

// 변경 전 구조

브라우저
└── search/page.tsx ('use client')
    ├── useSearchParams()
    ├── useInfiniteQuery() → axios → /naver-api → Naver API
    └── NewsCard
        └── axios → /google-api → Google API
            └── NEXT_PUBLIC_GOOGLE_API_KEY (브라우저에 노출)

// 변경 후 구조

서버
└── search/page.tsx (서버 컴포넌트)
    ├── searchParams prop으로 query, sort 수신
    ├── fetchNewsFirstPage() — "use cache"
    │   └── fetch → Naver API 직접 호출
    │       └── NAVER_API_CLIENT / NAVER_API_CLIENT_KEY (서버에만 존재)
    └── <NewsSearchClient initialData={...} />

브라우저
└── NewsSearchClient.tsx ('use client')
    ├── useInfiniteQuery() — initialData로 첫 페이지 수신
    ├── 2페이지~ → fetch → /api/news (Route Handler)
    │                         └── fetch → Naver API
    │                             └── NAVER_API_CLIENT / NAVER_API_CLIENT_KEY (서버에만 존재)
    ├── sort 변경 → router.push → URL 업데이트 → 서버 재렌더
    └── NewsCard
        └── POST /api/sentiment (Route Handler)
            └── fetch → Google API
                └── GOOGLE_API_KEY (서버에만 존재)

proxy.ts

Next.js 16에서 middleware.ts 컨벤션이 proxy.ts로 변경됐다. 파일명과 export 함수명 모두 proxy로 바꿔야 한다.

// src/proxy.ts

import { NextRequest, NextResponse } from 'next/server';

export function proxy(req: NextRequest) {
  const { searchParams } = req.nextUrl;

  if (!searchParams.get('query')?.trim()) {
    return NextResponse.redirect(new URL('/', req.url));
  }
}

export const config = {
  matcher: '/search',
};

/search?query= 없이 접근하면 /로 리다이렉트한다. 서버에서 요청을 가로채기 때문에 페이지가 렌더링되기 전에 처리된다.

추가 리팩토링

긍정 / 부정 / 분석 중 3-상태 렌더링 뉴스 카드 컴포넌트의 리팩토링을 진행했다. 기존에는 renderContent() 함수 안에서 if/else로 3가지 상태를 처리했고, 감정 분석 호출에 useMutation + useEffect 구조를 사용했다.

// 변경 전
// NewsCard/index.tsx

const { mutation } = useAnalyzeSentiment(newsContent);

useEffect(() => {
  if (mutation.status === 'idle' && !!newsContent.trim()) {
    mutation.mutate();
  }
}, [mutation, newsContent]);

const renderContent = () => {
  if (isLoading) return <NewsCardLoading />;
  if (isVisible && news) return <NewsCardContent ... />;
  return <NewsCardNegative />;
};

useMutation은 명시적으로 mutate()를 호출해야 실행된다. 그래서 컴포넌트가 마운트되면 useEffect 안에서 수동으로 트리거하고 있었다. 하지만 감정 분석은 데이터를 변경하는 게 아닌 조회하는 행위이다. google NLP API에 POST로 보내는 건 맞지만, 그건 HTTP 메서드의 문제였고, React Query에서의 역할은 다른 개념이었다. 그리고 useMutation 사용으로 인해 아래의 문제가 있었다.

• 캐싱이 없어 같은 뉴스 제목으로 분석을 요청해도 매번 API를 호출
• useEffect를 사용하여 마운트 시점에 수동으로 mutate()를 호출 필요
• 중복 호출을 막기 위해 mutation.status === 'idle'와 같은 방어 코드 필요

렌더링 로직도 renderContent 함수로 분기 처리를 통해 상태 체크로 useMutation의 한계를 메워가는 구조였다.

// 변경 후 
// hooks/api/sentiment.ts

export const useAnalyzeSentiment = (text: string) => {
  return useQuery({
    queryKey: ['sentiment', text],
    queryFn: () => postAnalyzeSentiment(text),
    enabled: !!text,
  });
};


// NewsCard/index.tsx

type CardState = 'loading' | 'visible' | 'hidden';

const cardState: CardState = isLoading ? 'loading' : isVisible ? 'visible' : 'hidden';

const contentMap: Record<CardState, React.ReactNode> = {
  loading: <NewsCardLoading />,
  visible: news && <NewsCardContent news={news} isTitleOnly={isTitleOnly} />,
  hidden: <NewsCardNegative />,
};

useMutation 대신 useQuery를 사용했다. enabled 조건이 충족되면 마운트 시 자동으로 fetch하므로 방어 코드도 필요가 없어졌다. 쿼리 키를 통해 동일한 텍스트에 대한 요청은 React Query가 캐싱해서 API를 다시 호출하지 않는다.

컴포넌트도 함수 분기가 아닌 객체 맵으로 처리하도록 했다. 이는 상태 결정과 렌더링이 분리되어 각 의도의 독립적 파악이 가능하며, 상태 추가 시 contentMap에 한 줄만 추가하면 된다. JSX 반환부도 {contentMap[cardState]} 한 줄로 깔끔히 유지가 가능하다.

react-virtuoso

const NewsList = ({ news, filter, hasNextPage, isFetchingNextPage, onLoadMore }: NewsListProps) => {
  return (
    <Virtuoso
      // 브라우저 window 스크롤 기준으로 가상화
      useWindowScroll
      // 렌더링할 데이터 배열
      data={news}
      // 실제 화면 밖 아래쪽 500px 영역까지 미리 렌더링
      // endReached 조기 트리거 + 스크롤 버벅임 방지
      overscan={500}
      // 마지막 아이템에 도달했을 때 호출 (다음 페이지 fetch)
      endReached={() => {
        if (hasNextPage && !isFetchingNextPage) onLoadMore?.();
      }}
      className="w-full"
      // 각 아이템의 렌더링 내용 
      // idx: 인덱스, item: 해당 뉴스 데이터
      itemContent={(idx, item) => (
        <div key={`${item.title}-${idx}`} className="pb-2 sm:pb-5">
          <NewsCard
            news={item}
            isTitleOnly={filter.showTitleOnly}
            isPositiveOnly={filter.showPositiveOnly}
          />
        </div>
      )}
      components={{
        // 리스트 맨 하단에 고정으로 렌더링되는 영역 (페이징 중일 때 스피너 표시)
        Footer: () =>
          isFetchingNextPage ? (
            <div className="flex w-full justify-center items-center py-4">
              <SpinnerIcon className="w-8 h-8 text-indigo-400 animate-spin" style={{ animationDuration: '1.5s' }} />
            </div>
          ) : null,
      }}
    />
  );
};

무한 스크롤 성능 최적화를 위해 react-virtuoso 라이브러리를 사용해 가상화를 적용했다.

브라우저 스크롤을 기준으로 가상화하기 위해 useWindowScroll을 적용했고, 화면 아래 500px를 미리 렌더링하여 스크롤 버벅임을 방지하고 endReached를 조기 트리거하기 위해 overscan 속성을 사용했다.

다음 페이지가 로딩 중인 동안엔 isFetchingNextPage 값이 true일 시 Footer에 스피너가 보여지도록 구현했다.

가상화 적용 이전에는 스크롤할수록 DOM 노드가 누적되었지만, 적용 이후에는 스크롤량에 무관하게 DOM 노드 수가 10개 이하로 유지되었다.😊

새로고침을 해도 폼 입력 값이 유지되어야 한다는 요구사항을 보고 어떻게 구현해야할 지 고민하며 방법을 알아보던 중 zustand persist를 알게 되었고, 폼 데이터 자체를 전역 상태로 관리하게 되면서 키 입력마다 리렌더, 여러 곳에 흩어져버린 검증 로직, 필드 레벨 에러가 없는 등의 문제가 발생했다 🥲

멘토님께서 리뷰로 react-hook-form + zod + zustand 방식을 추천해주셨고, 해당 방식으로 리팩토링을 진행했다. 그 과정을 글로 남겨보려고 한다!

zod로 폼 스키마 정의하기

우선 zod를 사용하여 프로젝트 폼의 요구사항에 맞게 검증 스키마를 정의했다.

// src/schemas/wizard.ts

import { z } from 'zod';
import { PROJECT, ERROR, ROLES } from '@/constants';

export const BasicInfoSchema = z.object({
  name: z.string().min(PROJECT.NAME.MIN, ERROR.NAME).max(PROJECT.NAME.MAX, ERROR.NAME),
  description: z.string().max(PROJECT.DESCRIPTION.MAX, ERROR.DESCRIPTION),
  isPublic: z.boolean(),
});

export const TeamMemberSchema = z.object({
  teamMembers: z
    .array(z.object({ userId: z.string(), role: z.enum(ROLES) }))
    .min(PROJECT.TEAM_MEMBER.MIN, ERROR.TEAM_MEMBER),
});

export const TechSchema = z.object({
  techStackIds: z.array(z.string()).min(PROJECT.TECH.MIN, ERROR.TECH),
});

export const ScheduleSchema = z
  .object({
    startDate: z.string().min(1, ERROR.SCHEDULE),
    endDate: z.string().min(1, ERROR.SCHEDULE),
    milestones: z.array(
      z.object({
        id: z.string(),
        name: z.string().min(1, ERROR.MILESTONE_NAME),
        targetDate: z.string().min(1, ERROR.MILESTONE_DATE),
      }),
    ),
  })
  .superRefine(({ startDate, endDate }, ctx) => {
    if (startDate && endDate && startDate >= endDate) {
      ctx.addIssue({ code: 'custom', message: ERROR.START_DATE, path: ['startDate'] });
      ctx.addIssue({ code: 'custom', message: ERROR.END_DATE, path: ['endDate'] });
    }
  });

export type BasicInfoValues = z.infer<typeof BasicInfoSchema>;
export type TeamMemberValues = z.infer<typeof TeamMemberSchema>;
export type TechValues = z.infer<typeof TechSchema>;
export type ScheduleValues = z.infer<typeof ScheduleSchema>;

.object, .array, .string 와 같이 스키마는 단순한 기본 값부터 복잡한 중첩 객체 및 배열에 이르기까지 다양한 데이터 유형을 나타낸다. 그리고 내장 문자열 유효성 검사 및 변환 API를 제공한다.

name: z.string().min(PROJECT.NAME.MIN, ERROR.NAME).max(PROJECT.NAME.MAX, ERROR.NAME)

min과 max 메서드를 사용하여 데이터의 최소, 최대 길이를 지정할 수 있다. 두 번째 인자로는 검증 실패 시 보여줄 에러 메세지 값을 넘겨준다!

superRefine

.superRefine()을 사용하면 zod의 내부 이슈 유형을 생성할 수 있다.

schema.superRefine((data, ctx) => {
  // 검증 로직
});

첫 번째 인자 data는 스키마가 파싱한 값 전체이고, 위의 코드에서는 구조 분해로 { startDate, endDate } 를 가리킨다. 두 번째 인자인 ctx는 refinement context로 에러를 직접 추가할 수 있는 도구이다.

• code : 에러 코드 (custom이 가장 일반적)
• message : 에러 메세지
• path : 어떤 필드에 에러를 연결할 지 지정하는 배열

infer

.infer 유틸리티를 사용하여 해당 스키마의 타입을 추출하고 원하는 대로 사용할 수 있다. 위의 코드에서 BasicInfoValues는 아래와 같은 값을 가진다.

type BasicInfoValues = {
    name: string;
    description: string;
    isPublic: boolean;
}

이는 react-hook-form의 useForm에 연결하여 사용할 수 있다!

react-hook-form과 연결하기

react-hook-form의 useForm, zod의 zodResolver을 사용하여 폼 데이터를 다룰 수 있다.

// src/pages/BasicInfoPage.tsx

const { draft, updateDraft } = useWizardStore();
const { handleNext } = useWizardNavigation();

const {
  register,
  handleSubmit,
  watch,
  setValue,
  formState: { errors },
} = useForm<BasicInfoValues>({
  resolver: zodResolver(BasicInfoSchema),
  mode: 'onTouched',
  defaultValues: {
    name: draft.name,
    description: draft.description,
    isPublic: draft.isPublic,
  },
});

const isPublic = watch('isPublic');


// 컴포넌트에 함수 연결
<form
  id="wizard-step-form"
  onSubmit={handleSubmit((values) => {
    updateDraft(values);
    handleNext();
  })}
  className="flex flex-col w-full gap-10"
>
  <div className="flex flex-col gap-1">
    <label className="font-bold px-1">프로젝트 이름</label>
    <Input
      placeholder={PLACE_HOLDER.NAME}
      errorMessage={errors.name?.message}
      {...register('name', { onChange: (e) => updateDraft({ name: e.target.value }) })}
    />
  </div>

  <div className="flex flex-col gap-1">
    <label className="font-bold px-1">프로젝트 설명</label>
    <TextArea
      placeholder={PLACE_HOLDER.DESCRIPTION}
      errorMessage={errors.description?.message}
      {...register('description', { onChange: (e) => updateDraft({ description: e.target.value }) })}
    />
  </div>

  <div className="flex flex-col w-full gap-1">
    <label className="font-bold px-1">공개 여부</label>
    <div className="flex gap-5">
      <RadioOption
        name="visibility"
        value="public"
        checked={isPublic === true}
        onChange={() => {
          setValue('isPublic', true);
          updateDraft({ isPublic: true });
        }}
      >
        공개
      </RadioOption>
      <RadioOption
        name="visibility"
        value="private"
        checked={isPublic === false}
        onChange={() => {
          setValue('isPublic', false);
          updateDraft({ isPublic: false });
        }}
      >
        비공개
      </RadioOption>
    </div>
  </div>
</form>

register

입력 필드를 react-hook-form에 등록하는 함수이다. {...register('name')} 처럼 spread하면 onChange, onBlur, ref 등 필요한 이벤트 핸들러가 Input에 자동으로 연결된다.

두 번째 인자는 옵션 객체로, 추가로 실행할 콜백을 끼워 넣을 수 있다. 즉, 위 코드의 경우엔 필드 값이 바뀔 때 form 내부 상태를 업데이트하면서 updateDraft 함수가 동시 실행된다.

handleSubmit

form의 onSubmit 이벤트를 감싸는 래퍼이다. 내부적으로 zod 스키마 유효성 검사를 먼저 실행하고, 통과하면 콜백(values => ...)을 실행한다. 실패하면 콜백 호출 없이 errors를 업데이트한다.

watch

특정 필드 값을 실시간으로 구독하는 함수이다. 위의 경우엔 watch('isPublic')으로 라디오 버튼의 선택 상태를 읽어 checked의 prop에 전달하고, 값이 바뀔 때마다 리렌더링이 트리거된다.

setValue

코드에서 직접 특정 필드 값을 설정한다. register로 연결하기 어려운 커스텀 컴포넌트에 사용할 수 있다.

// src/pages/TeamSetupPage.tsx

const setMembers = (updated: TeamMemberValues['teamMembers']) => {
  setValue('teamMembers', updated, { shouldValidate: true });
  updateDraft({ teamMembers: updated });
};

첫 번째 인자는 값을 업데이트할 필드, 두 번째 인자는 설정할 새 값이다. setValue는 기본적으로 값만 바꾸고 유효성 검사를 다시 실행하지 않는데, 세 번째 인자로 { shouldValidate: true }를 넘겨주면 값을 바꾼 직후 즉시 재검사한다.

formState: { errors }

유효성 검사 실패 시 발생한 에러 메세지를 담는 객체이다. errors.name?.message처럼 접근하여 사용할 수 있고, 직접 구현한 Input 컴포넌트에 errorMessage를 prop으로 전달하여 컴포넌트 하단에 입력 값에 대한 에러 메세지를 제시하도록 했다.

mode

mode는 에러를 언제 보여줄지 결정한다. onTouched는 필드에 한 번 포커스 후 벗어난 시점부터 검사를 시작하므로 처음부터 에러를 노출하지 않아 사용자 경험상 자연스럽다고 판단했다!

zustand + persist 미들웨어로 전역 상태 관리하기

persist는 zustand의 미들웨어로 페이지를 새로고침하거나 애플리케이션을 다시 시작해도 스토어의 상태를 유지할 수 있다.

const nextStateCreatorFn = persist(stateCreatorFn, persistOptions)

stateCreatorFn

(set, get) => ({ ... })의 형태로 zustand 스토어의 상태와 액션을 정의하는 함수이다. set으로 상태를 변경하고, get으로 현재 상태를 읽는다.

persistOptions

localStorage에 어떻게 저장하고 복원할지에 대한 설정 객체이다. name, version, partialize, migrate 등의 속성값이 존재하고, 각 속성이 존재하지 않으면 앱이 터질 수 있는 위험이 있다.

전역 데이터에 필드를 추가하거나 이름을 바꾸면 기존 사용자의 localStorage에는 옛날 구조의 데이터가 남아있기 때문에, 앱 업데이트 후 이 데이터가 복원될 때 새로 추가한 필드는 undefined가 된다. 이를 방지하기 위해 현재 데이터 구조의 버전 번호인 version과 이전 버전 데이터를 새 구조로 변환시켜주는 migrate를 꼭 작성해야 한다.

추가로 partialize 없이 persist를 사용하면 store 전체를 localStorage에 저장하게 된다. 만약 store에 draft 외에 다른 상태가 추가될 경우 의도치 않은 동작이 생겨날 수 있다. 그러므로 partialize를 사용하여 저장할 데이터를 명시적으로 지정하는 과정이 필요하다!

// src/store/useWizardStore.ts

interface WizardStore {
  draft: ProjectDraft;

  updateDraft: (partial: Partial<ProjectDraft>) => void;
  isStepValid: (step: WizardStep) => boolean;
  reset: () => void;
}

const initialDraft: ProjectDraft = {
  name: '',
  description: '',
  isPublic: true,
  teamMembers: [],
  techStackIds: [],
  startDate: '',
  endDate: '',
  milestones: [],
};

export const useWizardStore = create<WizardStore>()(
  persist(
    (set, get) => ({
      draft: initialDraft,

      updateDraft: (partial) => set((state) => ({ draft: { ...state.draft, ...partial } })),
      isStepValid: (step) => {
        const { draft } = get();
        switch (step) {
          case 1:
            return BasicInfoSchema.safeParse(draft).success;
          case 2:
            return TeamMemberSchema.safeParse(draft).success;
          case 3:
            return TechSchema.safeParse(draft).success;
          case 4:
            return ScheduleSchema.safeParse(draft).success;
          default:
            return true;
        }
      },
      reset: () => set({ draft: initialDraft }),
    }),
    {
      name: 'wizard-draft',
      version: 1,
      partialize: (state) => ({ draft: state.draft }),
      migrate: (persistedState, version) => {
        const state = persistedState as { draft?: Partial<ProjectDraft> };
        if (version === 0) {
          return { ...state, draft: { ...state.draft, milestones: state.draft?.milestones ?? [] } };
        }
        return state;
      },
    },
  ),
);

위자드 상태 draft와 draft의 일부만 받아 기존 값에 병합하는 업데이트 함수 updateDraft, 각 스텝의 zod 스키마로 검사해 유효 여부를 반환하는 isStepValid, draft를 초기값으로 되돌리는 reset 함수로 구성하여 스토어를 생성했다.

.safeParse는 zod의 유효성 검사 메서드로 { success, data, error } 객체를 반환한다. .parse를 사용하면 예외가 발생하지만 isStepValid에서는 success 여부만 확인하면 되기 때문에 .safeParse를 사용하여 각 스텝의 검증이 통과되었는지 확인하도록 했다!

form 바깥의 버튼에 submit 연결하기

페이지마다 이전, 다음 버튼이 존재해야 한다는 과제의 요구 사항에 따라 각 스텝의 form은 Outlet 안에 렌더링되도록 했고, 이전 / 다음 버튼은 layout 컴포넌트에 고정했다. 즉, 버튼과 form이 DOM 상 다른 위치에 존재한다.

일반적으로 type="submit" 버튼은 같은 form 안에 있어야 제출을 트리거할 수 있는데, 이 문제를 해결하기 위해 HTML 표준의 form 속성을 사용했다.

// src/layout/WizardLayout.tsx

<Button type="submit" form="wizard-step-form" size="lg" isActive={isStepValid(currentStep)}>
  다음
</Button>

버튼의 form 속성에 form의 id를 지정하면, 위치와 무관하게 해당 form의 submit 이벤트를 발생시킬 수 있다. 다음 버튼 클릭 시 아래의 순서대로 실행된다.

1. 다음 버튼 클릭 type="submit", form="wizard-step-form"
2. <form id="wizard-step-form" onSubmit={...}> 의 submit 이벤트 발생
3. react-hook-form의 handleSubmit 실행
4. 유효성 검사 통과 → (values) => { updateDraft(values); handleNext(); }
5. 유효성 검사 실패 → errors에 에러 채움, 콜백 실행 안 함

// src/layout/WizardLayout.tsx

const { handleSubmit } = useSubmitWizard();

<Button size="lg" onClick={handleSubmit}>
  프로젝트 생성
</Button>

마지막 스텝에서는 다음 버튼 대신 프로젝트 생성 버튼을 제시하도록 했고, 더 이상 form 유효성 검사가 필요하지 않기 때문에 onClick 이벤트에 useWizardForm 훅의 handleSubmit 함수를 연결해주었다.

문제 해석

아이들이 일렬로 서 있고, 각 아이는 ratings 배열로 평점를 가진다. 사탕을 나눠줄 때 다음의 조건을 만족해야 한다.

1. 모든 아이는 최소 1개의 사탕을 받아야 한다.
2. 이웃한 아이보다 평점이 높은 경우, 그 아이는 더 많은 사탕을 받아야 한다.

예제 분석

ratings = [1, 2, 2]

해당 예제에서 가장 헷갈렸던 부분은 왜 정답이 [1, 2, 2]가 아닌 [1, 2, 1]인지였다.

조건을 다시 보면 평점이 더 높은 경우에만 사탕을 더 많이 받으면 되므로 평점이 같으면 더 많이 줄 필요가 없다. 문제의 조건을 만족하는 사탕의 최소 개수를 구하는 문제이므로 평점이 높은 경우만 따지면 된다!

코드 구현

우선 모든 아이가 최소 1개의 사탕을 가지므로 길이가 ratings의 길이와 같은 배열을 1로 채운다.

const n = ratings.length;
const candies = new Array(n).fill(1);

그리고 왼쪽 → 오른쪽으로 순회하며 현재 아이의 평점이 왼쪽보다 높으면 사탕의 수를 1씩 늘린다.

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

그 후 오른쪽 → 왼쪽으로 순회하며 현재 아이의 평점이 오른쪽보다 높으면 기존 값과 오른쪽의 사탕 수에서 1을 더한 값을 비교하여 더 큰 값을 선택한다.

두 수 중에서 더 큰 값을 선택하는 이유는 이미 왼쪽 → 오른쪽을 순회하며 만족한 조건을 오른쪽 → 왼쪽을 순회하며 깨뜨리면 안되기 때문이다! 좌우 이웃과의 조건을 동시에 만족해야 하기 때문에 Math.max를 사용하여 값을 업데이트해준다.

for (let i = n - 2; i >= 0; i--) {
    if (ratings[i] > ratings[i + 1]) {
        candies[i] = Math.max(candies[i], candies[i + 1] + 1);
    }
}

최종적으로 구해야 하는 값은 사탕의 총 개수이므로 reduce 메서드를 사용하여 candies 배열의 총합을 구하면 된다.

return candies.reduce((a, b) => a + b, 0);

전체 코드

/**
 * @param {number[]} ratings
 * @return {number}
 */
var candy = function (ratings) {
    const n = ratings.length;
    const candies = new Array(n).fill(1);

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

    for (let i = n - 2; i >= 0; i--) {
        if (ratings[i] > ratings[i + 1]) {
            candies[i] = Math.max(candies[i], candies[i + 1] + 1);
        }
    }

    return candies.reduce((a, b) => a + b, 0);
};

최근들어 부정적인 기사가 너무 많은 것 같아 긍정적인 뉴스 기사만 골라볼 수 있는 기능이 있다면 좋겠다는 생각에 시작한 서비스인데, 필요한 기능만 빠르게 만들고 그대로 방치해버려서 일단 급하게 버셀 배포만 한 상태이다.. 늦은 감이 있지만 뒤늦게 리팩토링을 해보려 한다!!!

일단 클로드에게 부탁하기

우선 나는 클로드 프로를 사용 중이며, 클로드에게 현재 내 프로젝트에 리팩토링할 만한 부분이 있는지 질문해보았다.

🎯 핵심 리팩토링 포인트

1️⃣ 높은 우선순위 (즉시 개선 권장)

1. 에러 핸들링 부재

• src/api/search.ts, src/api/sentiment.ts에 try-catch 없음
• API 실패 시 사용자 피드백 부재

  2. 과도하게 긴 컴포넌트

• FilterOption.tsx:19-103 - 여러 기능 혼재
• NewsCard.tsx:15-81 - 복잡한 조건부 렌더링
• 개선방안: SortDropdown, FilterCheckboxGroup 등으로 분리

  3. useEffect dependency 누락

• FilterOption.tsx:36-41

  useEffect(() => {
  window.addEventListener('click', handleOutsideClick);
  return () => window.removeEventListener('click', handleOutsideClick);
  }, []); // ❌ handleOutsideClick이 dependency에 없음

  4. 환경변수 접근 분산

• interceptor.ts:7-8, sentiment.ts:6에서 각각 접근
• 개선방안: env.ts 파일로 중앙화

  2️⃣ 중간 우선순위

  5. 중복된 코드 패턴

• Spinner 렌더링이 page.tsx:70, page.tsx:83에서 반복
• 개선방안: <LoadingSpinner /> 컴포넌트 생성

  6. Icon 컴포넌트 인터페이스 불일관

• SearchIcon, SpinnerIcon, SortIcon, CheckIcon이 각기 다른 props 구조
• 개선방안: 공통 IconProps 인터페이스 정의

  7. 타입 정의 개선

• news.ts:3 - originallink 필드 미사용
• sentiment.ts:9-16 - sentences 배열 타입 부정확

  3️⃣ 낮은 우선순위

  8. 하드코딩된 매직 넘버

• page.tsx:48 - Intersection Observer threshold 0.1
• 개선방안: 상수로 정의

  9. reactStrictMode 비활성화

• next.config.ts:4 - 개발 중 버그 검출 어려움

너무 많아...

여기서 나의 개인적인 판단...

Spinner 컴포넌트의 경우엔 페이지 로딩 / 무한 스크롤 하단 로딩으로 두 가지가 겹친다는 의견이었는데, 역할도 다르고 ui도 달라 중복 로직으로 보기 어려웠다. Icon 컴포넌트 인터페이스의 경우는 각 아이콘마다 기능이 달라 편의를 위해 isOpen, isChecked 등 개별 props를 추가해둔 부분이라 공통 인터페이스 정의의 필요성을 느끼지 못했다. 타입 정의도 api 응답 타입을 그대로 반영한 구조였기에 수정할 필요가 없다고 느꼈다.

그래서 간단히 높은 우선순위만 리팩토링을 진행하기로 결심했다!!! 👊

환경변수 중앙화

네이버 오픈 api와 구글 오픈 api를 사용하는 데에 필요한 민감한 정보인 키 값들을 모두 env.local 파일에 작성해뒀는데, 클로드가 환경변수를 중앙화하는 방식을 추천해주었다.

환경변수를 한 파일로 모아서 관리하는 방식은 유지보수성과 안정성을 크게 높여준다고 한다. process.env.KEY를 직접 접근할 때와 달리 ENV 객체로 중앙 집중화하면 env.ts 한 곳만 수정하면 되므로 변경 관리가 훨씬 용이해진다.

그리고 중앙화 파일에서 기본값(|| '')을 처리하거나 타입을 명확하게 선언해두면 IDE 레벨에서 누락 여부를 빠르게 확인할 수 있고, 환경변수 사용 위치를 명확히 추적하기 쉬워진다.

// src/config/env.ts

/**
 * 환경변수 중앙 관리
 * Next.js는 빌드 타임에 process.env.NEXT_PUBLIC_* 변수를 문자열로 치환하므로
 * 직접 할당하는 방식으로 구현합니다.
 */
export const ENV = {
  // Naver API
  NAVER_CLIENT_ID: process.env.NEXT_PUBLIC_NAVER_API_CLIENT || '',
  NAVER_CLIENT_SECRET: process.env.NEXT_PUBLIC_NAVER_API_CLIENT_KEY || '',

  // Google API
  GOOGLE_API_KEY: process.env.NEXT_PUBLIC_GOOGLE_API_KEY || '',
} as const;

Next.js의 빌드 타임 환경변수 처리

function required(key: string) {
  const value = process.env[key]; // ❌
  if (!value) {
    throw new Error(`Missing environment variable: ${key}`);
  }
  return value;
}

위의 코드는 ChatGPT가 만들어준 에러 처리 코드인데, Next.js는 빌드 시 process.env.NEXT_PUBLIC_API_KEY를 문자열로 치환하기 때문에 process.env[key]와 같은 동적 키 접근을 치환할 수 없다. 결과적으로 런타임에 undefined를 반환하게 된다.

Next.js에서는 반드시 정적 키로 접근해야하므로 위의 코드대로 사용하였다!

컴포넌트 분리

여러 기능이 혼재하는 컴포넌트

현재의 FilterOption 컴포넌트는 왼쪽에 정렬 드롭다운 컴포넌트를, 오른쪽에 제목만 / 긍정뉴스 옵션 컴포넌트를 배치하여 동시에 묶여있다. 개발 당시엔 뉴스 목록을 필터링하는 역할을 하나로 묶어 처리할 생각으로 만들었지만 꽤 복잡하게 얽힌 함수들을 보니 역시 분리하는게 맞다는 생각이 들었다.

import { useCallback } from 'react';
import SortDropdown from './SortDropdown';
import FilterCheckboxGroup from './FilterCheckboxGroup';

export interface FilterState {
  sort: 'sim' | 'date';
  showPositiveOnly: boolean;
  showTitleOnly: boolean;
}

export interface FilterOptionProps {
  filter: FilterState;
  onChange?: <K extends keyof FilterState>(key: K, value: FilterState[K]) => void;
}

const FilterOption = ({ filter, onChange }: FilterOptionProps) => {
  const handleSortChange = useCallback((sort: 'sim' | 'date') => {
    onChange?.('sort', sort);
  }, [onChange]);

  const handleTitleOnlyChange = useCallback((value: boolean) => {
    onChange?.('showTitleOnly', value);
  }, [onChange]);

  const handlePositiveOnlyChange = useCallback((value: boolean) => {
    onChange?.('showPositiveOnly', value);
  }, [onChange]);

  return (
    <div className="flex w-full justify-between items-start px-1 sm:px-2 sm:h-20">
      {/* 정렬 */}
      <SortDropdown currentSort={filter.sort} onSortChange={handleSortChange} />

      {/* 필터 체크 */}
      <FilterCheckboxGroup
        showTitleOnly={filter.showTitleOnly}
        showPositiveOnly={filter.showPositiveOnly}
        onTitleOnlyChange={handleTitleOnlyChange}
        onPositiveOnlyChange={handlePositiveOnlyChange}
      />
    </div>
  );
};

export default FilterOption;

정렬 컴포넌트와 필터 체크 컴포넌트를 따로 분리해주었고, 각 컴포넌트는 memo로 감싸주었다. FilterOption 컴포넌트에서는 각 함수에 useCallback을 사용하여 핸들러 함수를 메모이제이션해주었다.

조건부 렌더링이 포함된 컴포넌트

뉴스 데이터를 보여주는 NewsCard 컴포넌트는 처음에 하나의 컴포넌트 안에서 뉴스 로딩 상태 / 정상적으로 뉴스가 표시되는 상태 / 부정적인 기사임을 보여주는 상태 이렇게 3가지의 ui를 모두 처리하고 있었다.

이를 각 상태에 따라 NewsCardLoading / NewsCardContent / NewsCardNegative 컴포넌트로 분리해주었다.

// src/components/NewsCard/index.tsx

export interface NewsCardProps {
  news?: NewsItem;
  isTitleOnly: boolean;
  isPositiveOnly: boolean;
}

const NewsCard = ({ news, isTitleOnly, isPositiveOnly }: NewsCardProps) => {
  const newsContent = `${news?.title} ${news?.description}`;
  const { mutation } = useAnalyzeSentiment(newsContent);

  useEffect(() => {
    if (mutation.status === 'idle' && !!newsContent.trim()) {
      mutation.mutate();
    }
  }, [mutation, newsContent]);

  const sentimentScore = mutation.data?.documentSentiment.score;
  const isVisible: boolean = isPositiveOnly ? isPositive(sentimentScore || 0) : true;
  const isLoading = !news || (mutation.isPending && isPositiveOnly);

  const handleNewsCard = () => {
    if (!isVisible) return;
    window.location.href = `${news?.link}`;
  };

  const renderContent = () => {
    if (isLoading) {
      return <NewsCardLoading />;
    }

    if (isVisible && news) {
      return <NewsCardContent news={news} isTitleOnly={isTitleOnly} />;
    }

    return <NewsCardNegative />;
  };

  return (
    <button
      onClick={handleNewsCard}
      className="flex flex-col w-full p-5 sm:p-7 text-left bg-white rounded-lg outline-1 sm:hover:outline-3 outline-gray-200  hover:outline-indigo-100 cursor-pointer"
    >
      {renderContent()}
    </button>
  );
};

export default NewsCard;

감정 분석 api 호출은 최초로 렌더링되는 시점에 idle 상태일 때만 실행하도록, 그리고 긍정 필터가 켜져 있으면 로딩 중에도 카드가 클릭되지 않도록 처리했다. NewsCard 컴포넌트는 renderContent 함수를 통해 상태를 판별하여 적절한 ui만 선택하여 렌더링하는 역할만 담당하도록 했다!

useEffect dependency 누락

// src/components/FilterOption.tsx - 기존 코드

  const handleOutsideClick = () => {
    setIsSortOpen(false);
  };

  useEffect(() => {
    window.addEventListener('click', handleOutsideClick);
    return () => {
      window.removeEventListener('click', handleOutsideClick);
    };
  }, []);

위의 코드는 정렬 (정확도순/최신순) 필터링 드롭다운 컴포넌트에 연결된 함수이며, 의존성 배열에 함수가 들어가있지 않다. 그리고 전역 click 이벤트로 작성되어있기 때문에 내부 클릭과 외부 클릭을 구분하지 못한다.

// src/components/SortDropdown.tsx - 개선된 코드

  const dropdownRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    const handleOutsideClick = (event: MouseEvent) => {
      if (dropdownRef.current && !dropdownRef.current.contains(event.target as Node)) {
        setIsOpen(false);
      }
    };

    window.addEventListener('mousedown', handleOutsideClick);
    return () => {
      window.removeEventListener('mousedown', handleOutsideClick);
    };
  }, []);

그래서 클릭된 위치가 드롭다운 요소 안인지 밖인지 확인하기 useRef를 사용하여 외부 클릭만 감지하도록 했다. 그리고 click 대신 mousedown을 사용하여 사용자의 액션이 발생했을 때 즉시 반응하도록 했다.

에러 핸들링 처리

지금은 api 요청에 대한 에러 처리가 하나도 되어있지 않은 상태... (왜지?) api 요청에 실패했을 때 페이지에 토스트 모달을 띄우기 위해 sonner 라이브러리를 설치하기로 했다!

sonner 라이브러리

// src/app/layout.tsx

import type { Metadata } from 'next';
import { Toaster } from 'sonner';
import { pretendard } from '@/styles/font';
import ReactQueryProvider from '@/providers/ReactQueryProvider';
import '@/styles/globals.css';

export const metadata: Metadata = {
  title: 'GJ NEWS',
  description: '긍정 뉴스만 뽑아보자!',
};

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={`${pretendard.className} max-w-3xl mx-auto`}>
        <ReactQueryProvider>{children}</ReactQueryProvider>
        <Toaster position="top-center" closeButton richColors />
      </body>
    </html>
  );
}

sonner 라이브러리의 토스트 모달을 사용하기 위해선 layout 파일에 <Toaster /> 을 추가해야한다.

페이지 상단 중앙에 띄우기 위해 top-center 속성을 넣었고, 닫기 버튼과 각 상태에 따른 색상을 넣기 위해 closeButton과 richColors 속성도 추가해주었다!

QueryClient에서의 에러 처리

뉴스 기사를 useInfiniteQuery를 통해 무한 스크롤로 가져오고, 각 뉴스에 대한 감정 분석을 위해 mutation도 수행하기 때문에 api 요청이 많은 만큼 에러 발생 횟수도 많아 중복되는 에러 메세지를 어떻게 처리할 지 고민이었다.

React Query v5부터는 useQuery 내부에서 onError가 제거되어서 error 상태를 감지해 useEffect로 토스트 모달을 띄우려 했지만, 무한 스크롤로 페이지를 리패치할 때 에러가 여러 번 동시에 발생하고, 그러면서 감정 분석 mutation이 각 뉴스 카드마다 실행되어 서로 다른 에러가 연속 발생하는 문제가 있었다.

React Query 관련 문서를 찾아보니, 개별 훅에서 처리하기보단 QueryClient 단에서 onError를 전역적으로 처리하는 방식이 더 권장되는 흐름이었다.

'use client';

import { useState } from 'react';
import { QueryClient, QueryClientProvider, QueryCache, MutationCache } from '@tanstack/react-query';
import { toast } from 'sonner';

export default function ReactQueryProvider({ children }: { children: React.ReactNode }) {
  const [queryClient] = useState(
    () =>
      new QueryClient({
        queryCache: new QueryCache({
          onError: () => {
            toast.error('요청 처리 중 오류가 발생했습니다.', {
              id: 'global-error',
            });
          },
        }),
        mutationCache: new MutationCache({
          onError: () => {
            toast.error('요청 처리 중 오류가 발생했습니다.', {
              id: 'global-error',
            });
          },
        }),
        defaultOptions: {
          queries: {
            retry: 1,
            refetchOnWindowFocus: false,
          },
        },
      })
  );

  return <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>;
}

그래서 위의 코드처럼 QueryCache와 MutationCache의 onError를 활용해 뉴스 조회 에러 / 감정 분석 에러를 모두 공통 메시지로 통일하기로 했다.

토스트가 중복으로 생성되는 문제는 Sonner의 id 옵션을 활용해 해결했다!! id를 지정하면 여러 요청이 동시에 실패하더라고 토스트는 한 번만 보여진다.

🎉 모든 리팩토링 완료!

✅ 완료된 모든 작업 총정리:

높은 우선순위 (완료):

1. ✅ 환경변수 중앙화 (env.ts)

2. ✅ FilterOption 대폭 리팩토링 (103줄 → 47줄, 54% 감소)

• SortDropdown.tsx 분리
• FilterCheckboxGroup.tsx 분리
• React.memo + useCallback 성능 최적화
• useEffect 외부 클릭 ref 기반 처리

  3. ✅ NewsCard 컴포넌트 분리 (84줄 → 57줄, 32% 감소)

• 폴더 구조로 정리 (NewsCard/index.tsx)
• 상태별 컴포넌트 분리 (Loading, Content, Negative)

  4. ✅ API 에러 핸들링

• React Query 전역 에러 핸들러 (ReactQueryProvider.tsx)
• Sonner 토스트 통합
• 중복 토스트 방지 (id: 'global-error')

  중간 우선순위 (검토 완료):

• Spinner 중복 → 용도가 달라서 현재 상태 유지
• Icon 인터페이스 → 각자 다른 용도, 현재가 더 명확
• 타입 정의 → API 응답 구조 유지

  낮은 우선순위 (완료):

  1. ✅ 매직 넘버 상수화 (pagination.ts - OBSERVER_THRESHOLD)

  2. ✅ 미사용 import 확인 (실제로는 사용 중)

  📈 최종 성과:

• 코드 라인 수: 187줄 감소 (FilterOption 56줄 + NewsCard 27줄 + 기타)
• 컴포넌트 분리: 4개 신규 컴포넌트 생성
• 성능 최적화: React.memo + useCallback 적용
• 에러 처리: 전역 핸들러로 체계화
• 코드 품질: 가독성, 재사용성, 유지보수성 대폭 향상

깃허브 바로가기 | 페이지 바로가기

📝 MDX 글 불러오기

개인 블로그 글 포스팅 하는 방법으로 노션에서 불러오기, mdx 파일로 작성하기 등이 있었는데, 평소에 노션을 사용하지 않기도 하고 블로그 관련으로는 레포지토리 하나로 끝내고 싶어서 mdx 파일을 사용하기로 결정했다!

카테고리별 글 작성하기

areumh-blog/
├── app/             # Next.js App Router 페이지
│   ├── category/    # 카테고리 페이지
│   ├── post/        # 블로그 포스트 상세 페이지
│   └── portfolio/   # 포트폴리오 페이지
├── components/      # 공통 컴포넌트
│   ├── layout/      # 레이아웃 컴포넌트
│   └── ui/          # ui 컴포넌트
├── hooks/           # 커스텀 훅
├── lib/             # 블로그 포스트 관련 유틸리티 함수
├── posts/           # 카테고리별 MDX 블로그 포스트 파일
├── public/          # 정적 파일
├── styles/          # 전역 스타일
├── utils/           # 유틸리티 함수
├── constants.ts     # 상수 정의
└── types.ts         # 타입 정의

루트 폴더에 posts라는 폴더를 생성한 후, 카테고리명으로 폴더를 생성한 뒤 mdx 파일을 작성하여 블로그 글을 추가하도록 했다.

// constants.ts
export const CATEGORIES = [
  { key: '개발', label: 'tech' },
  { key: '회고', label: 'review' },
];

// app/category/page.tsx
export default function Category() {
  return (
    <div className="flex flex-col items-center gap-10 md:px-10 py-3 md:py-5">
      {CATEGORIES.map(({ key, label }) => (
        <CategoryPostList key={key} category={label} />
      ))}
    </div>
  );
}

카테고리는 개발과 회고 외에는 딱히 작성할 것 같진 않고... 더 추가한다고 해도 글을 작성할 때 같이 수정하면 그만이라 상수 파일에 정의해두었고, 카테고리명을 인자로 받아 해당 카테고리의 글 목록을 보여주는 CategoryList 컴포넌트에 연결해주었다.

import fs from 'fs';
import path from 'path';
import matter from 'gray-matter';
import { Post } from '@/types';

const postsDirectory = path.join(process.cwd(), 'posts');

/**
 * 모든 slug 가져오기
 * category - 폴더명, slug - 파일명
 */
export function getPostSlugs(): string[] {
  const categories = fs.readdirSync(postsDirectory).filter((name) => {
    const categoryPath = path.join(postsDirectory, name);
    return fs.statSync(categoryPath).isDirectory();
  });

  const slugs: string[] = [];

  categories.forEach((category) => {
    const files = fs.readdirSync(path.join(postsDirectory, category));
    files.forEach((file) => {
      if (file.endsWith('.mdx')) {
        const slug = path.basename(file, '.mdx');
        slugs.push(`${category}/${slug}`);
      }
    });
  });

  return slugs;
}

process.cwd()는 현재 프로젝트의 루트 경로이고, posts는 블로그의 글이 담긴 폴더명으로 postsDirectory는 루트 폴더/posts가 된다.

fs.readdirSync()는 해당 폴더 안의 모든 파일/폴더 이름을 동기적으로 가져온다. fs.statSync()는 해당 경로의 파일 상태 정보를 담은 fs.Stats 객체를 반환하고, isDirectory()는 그 경로가 디렉터리인지 아닌지를 알려준다.

따라서 filter는 모든 파일/폴더의 이름 중 폴더의 이름만 걸러주기 때문에 categories는 카테고리 폴더명만 담고있는 배열을 리턴한다.

그리고 카테고리 폴더 내부를 탐색하여 .mdx 파일만 필터링하고, path.basename(file, '.mdx')를 통해 확장자를 제거한다. 이런 과정을 통해 위의 함수는 카테고리명/슬러그의 문자열 배열을 리턴한다!

gray-matter로 메타데이터 분리하기

/**
 * 특정 slug의 post 가져오기
 */
export function getPostBySlug(url: string) {
  const [category, slug] = url.split('/');
  const fullPath = path.join(postsDirectory, category, `${slug}.mdx`);
  const fileContents = fs.readFileSync(fullPath, 'utf8');

  const { data, content } = matter(fileContents);

  const meta: Post = {
    title: data.title,
    date: data.date,
    description: data.description,
    tags: data.tags || [],
    slug,
    category,
  };

  return { meta, content };
}

gray-matter 라이브러리의 matter 함수를 사용하면 mdx 파일의 상단 메타데이터와 본문을 분리할 수 있다.

---
title: "Next.js로 블로그 만들기 회고"
date: "2025-10-21"
description: "Next.js와 MDX를 이용한 블로그 만들기"
tags: ["Next.js", "MDX", "블로그"]
---

블로그 본문 내용

mdx 파일이 위와 같이 생겼다면 gray-matter은 이를 아래와 같이 반환한다.

{
  data: {
    title: "Next.js로 블로그 만들기 회고",
    date: "2025-10-21",
    description: "Next.js와 MDX를 이용한 블로그 만들기",
    tags: ["Next.js", "MDX", "블로그"]
  },
  content: "블로그 본문 내용"
}

이 data 객체를 기반으로 Post라는 타입을 따로 정의하여 카테고리와 슬러그 값을 포함하도록 했고, 블로그 본문의 헤더에 해당 데이터를 사용했다.

전체 글 / 카테고리별 글 목록 가져오기

/**
 * 전체 글 목록 가져오기
 */
export function getAllPosts(): Post[] {
  const slugs = getPostSlugs();
  return slugs.map((slug) => getPostBySlug(slug).meta).sort((a, b) => (a.date < b.date ? 1 : -1)); // 최신순
}

블로그의 홈 화면에서는 카테고리에 상관없이 모든 글들을 한번에 보여주도록 했기 때문에 위에 작성했던 함수들을 사용하여 모든 글의 메타데이터를 수집하고 이를 최신순으로 정렬한 배열을 리턴하게 했다!

/**
 * 카테고리별 글 가져오기
 */
export function getPostsByCategory(category: string): Post[] {
  return getAllPosts().filter((post) => post.category === category);
}

그리고 카테고리 페이지에서는 카테고리별 글 목록을 가져오기 때문에 카테고리 문자열을 인자로 받고 해당 카테고리의 글 목록을 리턴하는 함수를 작성했다.

태그 목록 가져오기

/**
 * 전체 태그 목록 가져오기
 */
export function getAllTags(): string[] {
  const posts = getAllPosts();
  const tags = posts.flatMap((post) => post.tags || []);
  return Array.from(new Set(tags));
}

홈 화면에서 태그별 글 목록 확인이 가능하도록 하기 위해 중복을 제거한 태그 목록을 리턴하는 함수도 작성했다.

params와 Suspense의 비동기 처리

Next 15 부터는 params는 동기가 아닌 비동기식으로 접근하도록 변경되었다. 즉, 라우트 파라미터를 가져오는 과정을 await 처리해야 한다.

1. 브라우저에서 /post/review/next-blog 와 같은 url에 접근
2. [category]/[slug] 에 해당하는 동적 파라미터 추출 - 서버 컴포넌트에서 params로 제공 (Promise 형태)
3. await params로 실제 객체 { category, slug } 로 변환

export default async function Post({ params }: { params: Promise<{ category: string; slug: string }> }) {
  const { category, slug } = await params;
  const { meta, content } = getPostBySlug(`${category}/${slug}`);

  // ...
}

위의 코드처럼 params의 타입을 Promise<{ category: string; slug: string }> 형태로 선언하고, 함수 내부에서 await으로 값을 꺼내는 방식으로 작성하여 mdx 파일의 글 데이터를 가져오도록 했다 👍

export default function Home() {
  const posts = getAllPosts();
  const tags = getAllTags();

  return (
    <div className="flex flex-col w-full max-w-[800px] mx-auto items-center md:px-10">
      <Suspense fallback={null}>
        <HomeContent posts={posts} tags={tags} />
      </Suspense>
    </div>
  );
}

추가로 React 18 이후부터는 useSearchParams()를 사용하는 클라이언트 컴포넌트를 데이터가 준비될 때까지 안전하게 렌더링되도록 Suspense로 감싸는 처리가 필요하다.

fallback은 데이터가 로딩 중일 때 보여주는 ui를 지정하는 속성인데, 이번 프로젝트는 페이지가 복잡하지 않고 굳이 로딩 상태 ui가 필요하다고 느껴지지 않아 null 값을 넣어 처리했다. 🫠

🎨 MDX 글 스타일링

next-mdx-remote로 글 렌더링하기

mdx의 블로그 글을 화면에 렌더링하기 위해 next-mdx-remote와 여러 플러그인을 활용했다.

import { MDXRemote } from 'next-mdx-remote/rsc';
import rehypePrettyCode from 'rehype-pretty-code';
import rehypeSlug from 'rehype-slug';
import remarkGfm from 'remark-gfm';
import remarkBreaks from 'remark-breaks';

export default async function PostContent({ content }: { content: string }) {
  return (
    <div className="prose prose-sm md:prose-lg dark:prose-invert">
      <MDXRemote
        source={content}
        options={{
          mdxOptions: {
            remarkPlugins: [remarkGfm, remarkBreaks],
            rehypePlugins: [rehypeSlug, rehypePrettyCode],
          },
        }}
      />
    </div>
  );
}

• remarkGfm: GitHub 스타일 마크다운 확장(GFM) 적용
• remarkBreaks: 줄바꿈 시 <br> 처리
• rehypeSlug: 각 헤딩에 자동으로 id 부여 → 목차(TOC)와 연결
• rehypePrettyCode: 코드 블록 하이라이팅 적용

// styles/globals.css 중 일부
@import 'tailwindcss';
@plugin "@tailwindcss/typography";

/* prose 문단 간격 조정 */
.prose p {
  margin-top: 0.5rem;
  margin-bottom: 0.5rem;
}

.prose h1,
.prose h2,
.prose h3,
.prose h4,
.prose h5,
.prose h6 {
  margin-top: 1rem;
  margin-bottom: 1rem;
}

.prose ul,
.prose li,
.prose ol {
  margin-top: 0.5rem;
  margin-bottom: 0.5rem;
}

/* 인용구 */
.prose blockquote {
  border-left: 4px solid #6366f1;
  padding: 0.5rem;
  color: #374151;
  font-style: normal;
  margin-top: 1rem;
  margin-bottom: 1rem;
  background-color: #f9fafb;
}

/* 다크모드 대응 */
.dark .prose blockquote {
  color: #e5e7eb;
  background-color: #1f2937;
}

/* 코드 블록 스타일 */
pre {
  padding: 1rem;
  border-radius: 0.5rem;
  overflow-x: auto;
  margin: 0.5rem 0;
}

code {
  font-family: 'Courier New', Courier, monospace;
  font-size: 0.75rem;
}

@media (min-width: 768px) {
  code {
    font-size: 0.875rem;
  }
}

// ...

globals.css 파일의 상단에 @plugin "@tailwindcss/typography";를 추가하여 prose 클래스를 사용한 컨텐츠에 스타일이 적용되도록 했다. 그리고 각종 태그들과 인용구, 코드 블록 등에 적용할 스타일들을 직접 작성했다. 🖌️

📎 TOC 컴포넌트 구현

블로그 글의 헤딩 (h1, h2, h3)을 기반으로 동적인 목차를 제공하는 컴포넌트를 직접 구현해보았다.

글의 모든 헤딩 가져오기

  useEffect(() => {
    const headingElements = Array.from(document.querySelectorAll('h1, h2, h3')) as HTMLElement[];

    const newHeadings = headingElements.map((el) => ({
      id: el.id,
      text: el.innerText,
      level: Number(el.tagName.replace('H', '')),
    }));

    setHeadings(newHeadings);
  }, []);

useEffect를 사용하여 컴포넌트 마운트 시 DOM에서 모든 h1, h2, h3 요소를 가져온다. 그리고 각 헤딩의 id, 텍스트, 레벨(h1일 경우 1, h2일 경우 2 ...)을 추출하여 상태에 저장한다.

IntersectionObserver로 현재 화면 위치 감지

const observer = new IntersectionObserver(
  (entries) => {
    entries.forEach((entry) => {
      if (entry.isIntersecting) {
        setCurrentId(entry.target.id);
      }
    });
  },
  { rootMargin: '0px 0px -80% 0px' }
);

• entries: 관찰 대상 요소들의 상태 배열 (헤딩)
• entry.isIntersecting: 해당 요소가 뷰포트에 보이고 있는지에 대한 boolean 값
• entry.target.id: 관찰 중인 DOM 요소의 id 값
• rootMargin: 관찰 영역(뷰포트)에 여백 설정 (bottom: -80% → 화면 아래쪽 80% 지점에서 요소가 들어오면 감지)

observer 등록

    const elements = document.querySelectorAll('h1, h2, h3');
    elements.forEach((el) => observer.observe(el));

observer.observe(el)로 각 헤딩을 관찰 대상으로 등록하고, 해당 요소가 화면에 들어오거나 나갈 때 브라우저가 콜백 함수를 자동으로 호출하도록 구현했다.

헤딩 스타일링

  const getHeadingMargin = (level: number): string => {
    const indentClass = {
      1: 'ml-0',
      2: 'ml-3',
      3: 'ml-6',
    } as const;

    return indentClass[level as keyof typeof indentClass] ?? 'ml-0';
  };

  // ...

  return (
    <nav className="flex pr-2 text-sm">
      <ul className="space-y-1">
        {headings.map((heading) => {
          return (
            <li
              key={heading.id}
              className={`${getHeadingMargin(heading.level)} ${
                currentId === heading.id ? 'text-indigo-400 font-semibold' : 'text-gray-400'
              } transition-colors`}
            >
              <a href={`#${heading.id}`}>{heading.text}</a>
            </li>
          );
        })}
      </ul>
    </nav>
  );

헤딩 레벨에 따라 TOC 내에 들여쓰기 스타일을 적용하기 위한 함수를 따로 작성해주었고, 현재 화면에 표시된 헤딩의 텍스트 색상을 강조하도록 했다.

html {
  scroll-behavior: smooth;
}

추가로 css 파일에 위의 코드를 추가하면 헤딩 클릭 시 애니메이션처럼 부드럽게 스크롤이 이동된다. 하지만 Next.js는 라우트 전환 시 스크롤 동작을 제어하기 위해 data-scroll-behavior 속성을 확인하기 때문에 하나의 페이지 내에서 스크롤이 이동될 때는 smooth, 라우트 전환 시엔 auto로 임시 변경 (즉시 스크롤) 되도록 html 태그에 속성 값을 추가해야한다. 하지 않으면 경고문이 뜬다 🤕

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en" data-scroll-behavior="smooth" suppressHydrationWarning> // ✅
      <body className="flex flex-col min-h-screen">
        <ThemeProvider attribute="class" defaultTheme="system" enableSystem>
          <Header />
          <main className="flex flex-col flex-grow w-full mx-auto px-7 md:px-20 py-5 md:py-8">{children}</main>
          <Footer />
        </ThemeProvider>
      </body>
    </html>
  );
}

data-scroll-behavior="smooth" 코드를 추가하여 해결했다!

🌙 다크모드 구현

Tailwind CSS v4부터는 다크모드 설정 방식이 바뀌어서 globals.css 파일에 아래의 코드가 필수로 들어가야 한다.

@custom-variant dark (&:where(.dark, .dark *));

위의 코드가 있어야 .dark 클래스가 붙은 요소와 그 하위 요소에 dark: 스타일이 적용된다!

next-themes 설정

// components/ui/ThemeToggle.tsx
import { Sun, Moon } from 'lucide-react';
import { useTheme } from 'next-themes';

export default function ThemeToggle() {
  const { resolvedTheme, setTheme } = useTheme();

  const handleTheme = () => {
    setTheme(resolvedTheme === 'dark' ? 'light' : 'dark');
  };

  return (
    <button
      className="relative flex w-7 h-7 md:w-8 md:h-8 rounded-full justify-center items-center hover:bg-gray-200 dark:hover:bg-gray-700 cursor-pointer"
      onClick={handleTheme}
    >
      <Sun className="w-5 h-5 md:w-6 md:h-6 rotate-0 scale-100 transition-all dark:-rotate-90 dark:scale-0" />
      <Moon className="w-5 h-5 md:w-6 md:h-6 absolute rotate-90 scale-0 transition-all dark:rotate-0 dark:scale-100" />
    </button>
  );
}

next-themes의 useTheme 훅으로 현재의 테마 상태를 가져오고, 현재 적용된 실제 테마 값인 resolvedTheme 값을 기반으로 테마를 변경하는 setTheme 함수를 토글 컴포넌트에 연결해주었다.

import type { Metadata } from 'next';
import { ThemeProvider } from 'next-themes';
import Header from '@/components/layout/Header';
import Footer from '@/components/layout/Footer';
import '@/styles/globals.css';

// ...

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en" suppressHydrationWarning>
      <body className="flex flex-col min-h-screen">
        <ThemeProvider attribute="class" defaultTheme="system" enableSystem> // ✅
          <Header />
          <main className="flex flex-col flex-grow w-full mx-auto px-7 md:px-20 py-5 md:py-8">{children}</main>
          <Footer />
        </ThemeProvider>
      </body>
    </html>
  );
}

그리고 루트 레이아웃에 ThemeProvider를 추가하여 전역에서 다크모드 토글이 가능하도록 했다 🌙

suppressHydrationWarning 처리

Next.js는 SSR(Server-Side Rendering) 방식을 사용한다.

1. 서버에서 HTML을 먼저 생성
2. 브라우저가 HTML을 받아 화면에 표시
3. React가 hydration -> JS를 연결하여 인터렉티브하게 만듦

그로 인해 다크모드를 구현할 때 서버는 사용자의 테마 설정을 모르기 때문에 기본 값 기준으로 HTML을 생성하고, 하이드레이션 과정 중 next-themes를 통해 실제로 사용자가 설정한 테마 값을 읽게 되어 이를 기반으로 DOM을 업데이트하여 하이드레이션 불일치 문제가 발생한다.

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en" data-scroll-behavior="smooth" suppressHydrationWarning> // ✅
      <body className="flex flex-col min-h-screen">
        <ThemeProvider attribute="class" defaultTheme="system" enableSystem>
          <Header />
          <main className="flex flex-col flex-grow w-full mx-auto px-7 md:px-20 py-5 md:py-8">{children}</main>
          <Footer />
        </ThemeProvider>
      </body>
    </html>
  );
}

이를 해결하기 위해 루트 레이아웃의 html 태그에 하이드레이션 불일치 경고를 허용하는 suppressHydrationWarning 속성을 추가했다.

블로그 바로가기 | 깃허브 바로가기

OpenAPI (Swagger) 명세 작성

• Express API 코드를 분석하여 OpenAPI 3.0 표준 형식의 API 명세 자동 생성
• 앤드포인트, 요청/응답 스키마, 파라미터 정보를 체계적으로 문서화
• GraphQL 스키마 문서화, 포스트맨 콜렉션 생성 요청 가능

2. 사용자 가이드 작성

Getting Started 가이드

• 신규 사용자가 프로젝트를 빠르게 이해하고 시작할 수 있는 단계별 가이드 작성
• 설치, 설정, 첫 실행까지의 과정을 명확하고 따라하기 쉽게 문서화

3. 기술 문서 구조화

ADR (Architecture Decision Records)

• 중요한 기술적 결정사항들을 체계적으로 문서화하여 나중에 왜 그런 선택을 했는지 추적 가능
• 결정의 배경, 고려한 대안들, 예상되는 결과를 명확히 기록해 팀의 기술 부채를 줄이고 새로운 팀원이 합류했을 때 과거에 왜 그런 결정을 했는지 빠르게 이해할 수 있도록 도움
• 비슷한 상황에서 이전 결정을 참고하여 일관된 아키텍처 방향성 유지

시스템 설계 문서

• 복잡한 시스템의 전체적인 구조와 컴포넌트 간 관계를 명확히 시각화
• 신규 개발자나 다른 팀이 시스템을 이해하는 데 필요한 시간 단축
• 확장성, 성능, 보안 요구사항을 체계적으로 정리하여 설계 품질 향상
• 시스템 변경 시 영향도 분석과 리스크 평가를 위한 기준 문서로 활용 가능

4. 코드와 문서 동기화

JSDoc에서 문서 생성

• JSDoc 기반으로 완전하고 정확한 API 문서를 자동 생성
• 단순한 API 문서뿐 아니라 샘플 코드와 실제 시나리오까지 포함된 개발자에게 유용한 문서 생성 가능

문서 자동 업데이트 스크립트

• 코드가 변경될 때마다 자동으로 문서를 업데이트하여 문서-코드 간 불일치 방지
• CI/CD 파이프라인에 문서 생성 단계를 포함시켜 수동 작업 없이도 최신 문서 유지, 개발자가 문서 업데이트를 깜빡하더라도 자동화된 프로세스가 이를 보완
• 문서 변경사항을 깃 커밋으로 추적하여 문서의 변화 이력도 함께 관리

5. 배포 및 운영 문서

배포 가이드

• 배포 프로세스의 모든 단계를 체계적으로 문서화하여 배포 실수 최소화
• 환경별 설정 차이점과 주의사항을 명확히 기록해 일관된 배포 보장
• 롤백 절차와 장애 대응 방법을 포함하여 운영팀의 신속한 대응을 가능하게 함

운영 런북 (Runbook)

• 시스템 장애 발생 시 단계별 대응 절차를 명확하게 정리하여 빠른 문제 해결 지원 가능
• 모니터링 지표와 알람 설정 방법을 문서화해 사전 장애 예방 가능
• 일반적인 운영 작업들을 표준화하여 인적 오류를 줄이고 일관성 확보 가능

난 작년에 대학을 졸업한 취준생이며, 혼자 프론트엔드를 공부하고 있었다. 개발 스터디에 들어가 팀 프로젝트를 한다거나.. open api로 개인 프로젝트를 한다거나... 꽤 오랜 기간 이어지던 팀 프로젝트는 흐지부지 끝나버렸고 결국 혼자 공부하는 것에 한계를 느끼게 된다 🙃

1년이라는 짧으면서도 긴 시간동안 해낸 완벽한 결과물이 없어서 내가 너무 작아진 느낌이었다. 주변 동기들은 다 부트캠프 하던데... 난 뭐했지? ( ㄴ 그럼 너도 하면 돼 )

그렇게 바로 부트캠프를 알아보게 되었고... 수많은 부트캠프 중 항해를 선택했다.

1. 국비지원 부트캠프는 너무 평일 풀타임에 기간이 길어서 못 버틸 가능성이 높음
2. 난 소비하는 돈이 많기에 알바와 병행 가능해야 함
3. 너무 쌩기초부터 시작하지 않았으면 좋겠음

내 나름대로 만든 기준을 모두 충족하기도 했고 예전부터 많이 들어봤던 부트캠프라 궁금하기도 했다. 그렇게 나는 아빠의 도움(💸)을 받아 항해를 시작하게 된다!!!

📈 기술적 성장?

나의 부족함

솔직히 부트캠프를 수료했다고 드라마틱하게 성장했다고 하면 거짓말이다. 그치만 항해를 하지 않고 계속 혼자 공부했다면 자세히 들여다보지 않았을 개념을 깊게 공부하게 된건 확실하다.

사전적 정의 정도만 알고있던 개념들을 과제로 직접 접하며 나의 부족함을 뼈저리게 느낀 10주였다. 난 대학교 3학년으로 올라가면서 프론트엔드의 길을 선택했는데, 바로 직전 학기인 2학년 2학기 자바스크립트 전공 과목에서 C+을 받았었다. 재수강으로 성적을 올리긴 했지만, 그렇게 자바스크립트에 큰 구멍이 난 상태에서 교내 웹 동아리에 들어가 바로 리액트 공부를 시작했다.

그렇게 이어져오던 나의 허접한 자바스크립트 실력이 1주차 과제에서부터 터져버린 것이었다... 코드를 썼다 지웠다 반복하면서 다른 사람들은 어떻게 했는지 코드를 훔쳐보기도 했고, 뒤늦게 학습 자료를 읽어보기도 했다. 과거의 내가 아무나 붙잡고 질문할 수 있는 성격의 소유자였다면 얼마나 좋았을까...

1주차의 SPA 뿐만 아니라 두 번째 챕터의 클린 코드와 FSD, 세 번째 챕터의 테스트 코드, 네 번째 챕터의 SSR, SSG 그리고 성능 최적화. 모든 과제가 나에겐 도전이었던 것 같다. 쉽게 끝낼 수 있는 과제는 하나도 없었고, 매번 새로운 개념과 문제에 부딪히며 깊게 생각해야 했다. 그리고 테스트를 통과하지 못하면 무조건 과제 실패 처리가 되기 때문에 완벽이 아닌 완성을 목표로 해야 했다. 그치만 애초에 완성이 어려웠다. ⚰️

매주 금요일이 과제 제출이었기 때문에 목요일은 거의 고정으로 밤을 샜던 것 같다. 대학생 때 시험 벼락치기하면서 마셨던 스누피 커피우유_(지금은 춘식이 커피우유)_를 마시기도 했다. 옛날 생각이 났다...

새벽까지 zep에서 팀원들과 같이 과제를 하면서 버틴게 정말 큰 힘이 되었다. 막히는 부분이 있으면 서로 어떻게 해결했는지 공유하고, 과제의 주제에 대해 의견을 나누며 한층 더 성장할 수 있었다.

회고하는 습관

나의 거지같은 실력 말고도 또 놀란건 다른 사람들의 PR이었다.

나는 ㅇㅇ님 수준의 글쓰기 실력을 갖고 있는데... 다른 사람들의 pr을 보니 무슨 전문 서적이 따로 없었다. 여기서 또 한번 벽을 느꼈다. 개발을 잘하는 사람은 글도 잘 쓰는구나...

코치님도, 매니저님도 회고의 중요성을 여러 번 언급하셨다. 그런데 나는 지금까지 회고를 써본 적이 없었다. 강제는 아니었지만 매주 과제를 마치고 WIL을 제출해야 했는데, 이거라도 꾸준히 해봐야겠다고 생각했다. 중간에 몇 주씩 밀리긴 했지만ㅎㅎ 그래도 지금은 10주차 과제까지 회고를 모두 작성한 상태다. 다행히도 나중에 실력을 쌓고 과제를 다시 한 번 풀어본 후 내가 썼던 회고를 읽어보면 감회가 새롭지 않을까 하는 생각이 든다.

글은 계속 써봐야 느는 거라던 팀원들의 말이 떠오른다. 앞으로도 꾸준히 회고를 쓰다보면 글쓰기 실력도 자연스럽게 나아지지 않을까??? 하는 나의 바람..

항해 회고 모음집

마침내 수료

나같은 어중간한 실력에도 어찌저찌 수료를 하긴 했다. 매주 기본/심화로 나뉘는 과제가 있었고, 3번 심화 과제를 실패해서 총 7개의 과제를 통과했다. 사실 과제가 너무 어려워서 얼른 끝나면 좋겠다고 생각한 적도 있었는데, 막상 진짜 끝나니 너무 아쉬웠다.

솔직히 항해를 하지 않았다면 난 지금까지 뭘 어떻게 공부하고 있었을 지 상상이 가지 않는다. 뭔가를 공부하는 척 허송세월을 보내고 있진 않았을까.. 하고 예상해본다. 💦

😰 힘들었던 점 ?

잘못 들어왔지만...

사실 난 모집 대상을 잘못 보고 항해를 신청했다... 경력 3~4년의 개발자를 대상으로 하는 이직 부트캠프였는데, 난 이를 공부 기간으로 잘못 이해했다.

개강하기 전, 사전에 초대된 노션 페이지에 팀 노트를 적는 시간이 있었는데 멤버 카드를 보니 거의 대부분이 현재 개발자로 일을 하고 계시거나 이직을 준비하고 계신 분들이었다. 나만 취준생 나부랭이... ?: 잘못 왔다;;

그래서 개강 날에 너무 위축됐고... 다 너무 멋진 사람들만 있고... 하필 1주차 과제가 너무 어려웠기 때문에 관두고 탈주할까 진지하게 고민했었다. ㅋㅋㅋㅋㅋㅋㅋㅋ 과제 난이도 조절 실패로 인한 채점 기준 변경과 제출 마감 날짜 연장은 최초였다고 한다.

다른 주차 과제들은 할만 하다던 학메님의 말이 아니었다면 정말 탈주했을지도 모른다. 실제로 과제 난이도는 단짠단짠...이었던 것 같다. 근데 이제 달 때는 이거 단건가...? 싶은거고 짤 때는 와 개짜다;; 수준인..

배포라는 산...

또 하나 힘들었던 점은 매주마다 과제를 깃 배포하여 제출해야 했던 거..? 난 기능 구현만 주구장창 해봤지, 배포 경험은 몇 번 없는 쪼렙이었고.. 그래서 그런지 배포가 나한테 조금 무서운 존재였다.

사실 두 번째 챕터 과제 중 배포가 잘 안돼서 새벽까지 붙잡고 있다가 펑펑 운 적이 있다. ^^;;

깃 액션으로 배포를 시도하다가 2~3시간 정도를 날려먹었고... 고통받는 나를 본 팀원분이 gh-pages 라이브러리를 사용한 10분컷 배포 법을 정리하여 나를 도와주셨다. 너무 감사했다...

정리본을 하나하나 따라하면서 나는 진짜 멀었구나, 다른 사람들은 그냥 척척 해내는데 나는 몇 시간을 붙잡아도 안되는구나 하고 자괴감에 빠져 펑펑 울다가 지쳐서 잠들었었다. 지금은 아무렇지도 않다!!!! ㅎㅎ (아님)

🫡 내가 얻은 것 ?

힘들었다는 건 그만큼 얻은 것도 있다는 것..ㅎㅎ

페어 1팀

우선 함께 한 사람들이 다 너무 좋았다. 다들 잘 챙겨주셨고, 많이 도와주시기도 했다. 위에 말했듯 배포 방법 정리본을 받기도 했고, 과제 관련 질문을 받아주시기도 했고, 아주 개똥같은 나의 코드를 칭찬해주시기도 했다. 거짓말쟁이님들.

두 번째 챕터 쯤 부터 더 활발한 교류를 위해 기존의 두세 팀이 묶여 페어 팀으로 진행됐는데 낯선 사람에게 먼저 다가가는게 어려웠던 나에겐 너무 좋은 전환점이었다.

내가 속한 페어 1팀은 매주 월~목 정해진 시간에 zep에 모여 스크럼을 가졌다. 오늘의 tmi, 오늘까지 한 일, 내일 할 일, 트러블 슈팅 등을 공유하며 다 함께 소통하는 시간을 가졌고, 덕분에 사이가 훨씬 더 가까워진 것 같다. 팀 막내라 그런지 더 챙겨주신 부분도 있고.. 😋

네트워킹

개강과 수료식 말고도 중간 네트워킹, 페어 1팀 회식, 모각코+파티 등 오프라인 모임이 여러 번 있었고, 나답지 않게 대부분 참여했다.ㅋㅋㅋㅋㅋㅋ 집이 멀어서 일찍 헤어져야 하는 게 아쉬울 정도로 재밌었다.

아직 취준생이라 주변에 개발하는 사람이 많지 않았는데, 항해를 통해 만난 너무나도 멋있는 사람들과 정기적으로 꾸준히 교류할 수 있는게 너무 좋았다. 외향적이지 않은 나를 데리고 여러 테이블을 옮겨다니며 소개해주던 팀원분들... 상당히 기빨렸지만 덕분에 많은 사람들과 대화할 수 있었다 🫠

그리고 일단 맛있는거 먹는 게 좋았음 ㅎㅎ 페어 팀 회식 때 먹은 고기가 너무 맛있었다...

멘토링

매주 진행됐던 멘토링도 정말 좋았던 것 같다. 과제를 하면서 막힌 부분이나 현재 개발자로서의 고민, 이력서 코칭 등 자유롭게 코치님과 소통할 수 있는 시간이었고 모든 코치님들이 늦은 시간까지 정성을 다해 멘토링을 진행해주셨다.

나는 기본적인 이력서의 틀 마저도 갖추지 못해 이력서 코칭은 받지 못했지만, 다른 팀원들의 코칭을 보면서 어떻게 이력서를 작성하는 게 효과적인지 감을 잡을 수 있었다. 매니저님이 먼저 나를 개인적으로 불러 이력서 관련 팁들을 알려주시기도 했다.

끄적일 이력서도 없는 나에게 도움을 퍼부어주시는 게 너무 감사하기도 했고...💧 얼른 뭐라도 해서 결과물을 만들어 내야겠다는 생각을 했다.

💻

엥? 또 하나 얻은 것은 맥북이다..

9주차 과제 중 서버를 여러 개 띄워야 하는 테스트가 있었는데, 윈도우에서는 라이브러리를 2개나 추가한 뒤 스크립트 명령어를 수정해줘야 했다. 이를 알기 전에는 테스트가 돌아가지 않는게 내가 코드를 잘못 건드려서 그런건지, 뭔 문제인 건지 이유를 알 수가 없어서 너무 스트레스를 받아 진심 폭발할 뻔했다.

안그래도 느려 터진 6년된 노트북 포맷해서 쓰고 있었는데 결국 참지 못하고 맥북을 질렀다. 맥북 구매에 도움을 준 페어 1팀에게 감사 인사를.. 🙇

그렇게 난 항해에서 피자 팔고 맥북 산 사람이 되었다 🍕

🎯 앞으로는 ?

항해가 끝났음에도 불구하고 프론트엔드 6기는 아직 진행 중인 것 같다 ⚓️ 공식이 아닌 새로 개설된 6기 디스코드 채널엔 학메님들과 팀원들, 코치님들이 들어와 계시고 각종 스터디가 열리거나, 채용 공고 공유, 뉴스 레터 공유 등 활발히 운영되고 있다.

난 2주 안에 블로그 만들기 스터디, 2주 1글 쓰기 스터디에 참여 중이다. 당장 개인 프로젝트로 진행할 수 있고, 회고 글쓰는 연습이 필요한 나에게 너무 적합한 스터디들이다.👍

앞으로도 항해를 통해 얻은 것들을 토대로 꾸준히 노력하고 도전해보려 한다. 이번 항해가 끝이 아니라 시작이라는 마음으로, 목표를 하나씩 이뤄가며 성장해 나가고 싶다. 나의 항해는 이제부터 시작이다!!!!!! 🌊🌊🌊

기본 동작 모드

권한 및 안전성 옵션

인터랙티브 모드 내 추가 기능

2. 인터랙티브 모드 (대화형 모드)

특징

• 실시간 질문과 답변
• 단계별 확인과 피드백
• 복잡한 작업을 점진적으로 진행
• 사용자 승인 하에 파일 수정

장점

• 이해 목적 : 새로운 기술 탐색, 코드 리뷰/해설, 난해한 개념 분해
• 탐색적 개발 : 요구가 불명확할 때, 옵션 비교가 필요할 때, 실험적 기능 초안
• 페어 프로그래밍 느낌으로 세밀한 의사결정이 잦은 직업 전반

3. 프린트 모드 (비대화형 모드)

특징

• 비대화형 실행
• 결과를 직접 출력
• 스크립트 및 자동화에 적합
• 단일 명령으로 완료

장점

• CI/CD 파이프라인 통합 가능
• 자동화 스크립트 작성 용이
• 빠른 실행 속도
• 배치 작업 처리 가능

4. YOLO 모드 (권한 스킵 옵션)

특징

• 매우 빠른 실행 속도
• 프로토타이핑에 최적화
• 반복 작업 자동화
• 최소한의 질문과 확인

주의사항

• 최소한의 안전 검사
• 개발 환경에서만 권장
• 되돌릴 수 있는 변경만 수행
• 중요한 파일 수정 시 주의
• 격리된 환경에서 사용 권장

5. 인터랙티브 모드의 특수 키 기능

작업 제어 - ESC

ESC 1번 - 작업 중단

• 클로드의 현재 작업 즉시 중단
• 컨텍스트는 유지되어 다른 지시사항 제공 가능
• 잘못된 방향으로 진행 중일 때 유용

ESC 2번 - 히스토리 점프

• 대화 히스토리로 이동하여 이전 프롬프트 편집 가능
• 다른 방향으로 작업을 탐색하고 싶을 때 사용
• 새로운 분기를 만들어 대안적 접근 시도 가능

모드 전환 - shift + tab

• 일반 모드(기본) : 각 편집 사항을 개별적으로 확인
• Auto-Accept Edits : 모든 편집을 자동으로 수락
• 플랜 모드 : 복잡한 작업의 계획을 먼저 수립 (읽기 전용)

6. 모드별 상세 설명

Auto-Accept Edits (자동 편집 수락)

특징

• 자동 편집 수락 : 모든 파일 변경을 자동으로 승인
• 빠른 작업 속도 : 확인 단계 생략으로 시간 단축
• 대략 작업에 최적화 : 여러 파일의 일괄 수정에 효과적
• 인터랙티브와 프린트의 중간 : 대화는 가능하지만 편집은 자동 수락

장점

• 반복 작업 자동화 : 비슷한 패턴의 수정 작업을 빠르게 처리
• 리팩토링 효율성 : 대규모 코드 개선 작업에 이상적
• 생산성 향상 : 신뢰할 수 있는 작업에서 확인 시간 절약
• 일관된 코드 스타일 : 전체 코드 베이스에 일관된 규칙 적용

플랜 모드 (계획 수립)

특징

• 단계별 계획 수립 : 복잡한 작업을 작은 단계로 분해
• 위험 분석 : 각 단계의 잠재적 위험 사전 식별
• 영향도 평가 : 변경사항이 미칠 영향 사전 분석
• 롤백 전략 : 문제 발생 시 복구 계획 포함

장점

• 리스크 최소화 : 실행 전 충분한 검토로 위험 감소
• 팀 협업 강화 : 계획을 팀과 공유하고 검토 가능
• 복잡한 작업 관리 : 대규모 변경사항을 체계적으로 관리
• 문서화 : 작업 과정이 자동으로 문서화됨

WIL

✅ API 호출 최적화

// (이미 호출한 api는 다시 호출하지 않도록 - 클로저를 이용하여 캐시 구성)
const createLectureFetcher = () => {
  let lectureCache: Lecture[] | null = null; // 클로저에서만 유지되는 캐시

  const fetchAllLectures = async () => {
    if (lectureCache) return lectureCache; // 캐시가 있으면 api 호출 생략

    const res = await Promise.all([
      (console.log('API Call 1', performance.now()), fetchMajors()),
      (console.log('API Call 2', performance.now()), fetchLiberalArts()),
      (console.log('API Call 3', performance.now()), fetchMajors()),
      (console.log('API Call 4', performance.now()), fetchLiberalArts()),
      (console.log('API Call 5', performance.now()), fetchMajors()),
      (console.log('API Call 6', performance.now()), fetchLiberalArts()),
    ]);

    lectureCache = res.flatMap((r) => r.data); // 전공과 교양을 평탄화하여 하나의 배열로 처리
    return lectureCache;
  };

  return { fetchAllLectures };
};

// fetcher 생성
const lectureFetcher = createLectureFetcher();

lectureCache는 createLectureFetcher 내부에만 존재하는 클로저 캐시이며, api를 호출한 후 데이터를 저장한다. 최초 호출 이후에 또 호출하게 되면 이를 즉시 반환하며, 외부에서는 캐시에 접근할 수 없다. 모달 컴포넌트 외부에 한 번만 생성하여 모달의 리렌더링에 관계 없이 캐시 유지가 가능하다!!

모달을 열어보면 최고 한 번 열었을 때만 api를 호출하고, 그 이후엔 캐싱된 값을 사용하여 api를 호출하지 않는 것을 확인할 수 있다 👍

✅ 컴포넌트 렌더링 최적화

// 각 컴포넌트로 분리 후 메모이제이션 적용
export default React.memo(LectureHeadItem);
export default React.memo(LectureItem);
export default React.memo(ScheduleTemplate);

강의 헤더 아이템과 단일 아이템, 시간표 템플릿 컴포넌트 등을 분리한 뒤 memo를 사용하여 리렌더링을 방지했다. 이 외에도 filteredLectures, visibleLectures, allMajor, changeSearchOption 등에 useMemo, useCallback을 사용하여 최적화했다.

// 각 필터 분리 후 메모이제이션 적용
export default React.memo(CreditFilter);
export default React.memo(DayFilter);
export default React.memo(GradeFilter);
export default React.memo(MajorFilter);
export default React.memo(QueryFilter);
export default React.memo(TimeFilter);

// src/components/filter/SearchOptionFilter.tsx
interface SearchOptionFilterProps {
  searchOptions: SearchOption;
  allMajors: string[];
  changeSearchOption: (field: keyof SearchOption, value: SearchOption[typeof field]) => void;
}

const SearchOptionFilter = ({ searchOptions, allMajors, changeSearchOption }: SearchOptionFilterProps) => {
  return (
    <>
      <HStack spacing={4}>
        {/* 검색 필터링 */}
        <QueryFilter query={searchOptions.query} changeSearchOption={changeSearchOption} />

        {/* 학점 필터링 */}
        <CreditFilter credits={searchOptions.credits} changeSearchOption={changeSearchOption} />
      </HStack>

      <HStack spacing={4}>
        {/* 학년 필터링 */}
        <GradeFilter grades={searchOptions.grades} changeSearchOption={changeSearchOption} />

        {/* 요일 필터링 */}
        <DayFilter days={searchOptions.days} changeSearchOption={changeSearchOption} />
      </HStack>

      <HStack spacing={4}>
        {/* 시간 필터링 */}
        <TimeFilter times={searchOptions.times} changeSearchOption={changeSearchOption} />

        {/* 전공 필터링 */}
        <MajorFilter majors={searchOptions.majors} allMajors={allMajors} changeSearchOption={changeSearchOption} />
      </HStack>
    </>
  );
};

export default SearchOptionFilter;

필터링 컴포넌트의 경우는 각 필터를 컴포넌트로 분리하여 React.memo로 감싸주었다. 이를 통해 props의 값이 변경되지 않으면 리렌더링이 발생하지 않도록 개선했다!

✅ 시간표 블록 드래그, 드롭 최적화

const ScheduleTable = React.memo(({ index, disabled, tableId, initialSchedule, onDuplicate, onRemove }: Props) => {
  // 시간표 개별 상태 관리
  const [schedules, setSchedules] = useState<Schedule[]>(initialSchedule);
  // 현재 선택된 강의 정보 - 시간표 id, 요일, 시간
  const [searchInfo, setSearchInfo] = useState<{
    tableId: string;
    day?: string;
    time?: number;
  } | null>(null);

  const [isActive, setIsActive] = useState<Active | null>(null);

  const getColor = (lectureId: string): string => {
    const lectures = [...new Set(schedules.map(({ lecture }) => lecture.id))];
    const colors = ['#fdd', '#ffd', '#dff', '#ddf', '#fdf', '#dfd'];
    return colors[lectures.indexOf(lectureId) % colors.length];
  };

  // 드래그 시작 시 active 업데이트
  const handleDragStart = ({ active }: { active: Active }) => {
    setIsActive(active);
  };

  // 드래그 종료 시 호출
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  const handleDragEnd = (event: any) => {
    // active - 드래그한 아이템
    // delta - 이동 거리
    const { active, delta } = event;
    // 드래그 종료 시 active 제거
    setIsActive(null);

    const { x, y } = delta;
    const [, index] = active.id.split(':');
    const schedule = schedules[index];
    const nowDayIndex = DAY_LABELS.indexOf(schedule.day as (typeof DAY_LABELS)[number]);

    // 이동한 그리드 계산
    const moveDayIndex = Math.floor(x / 80);
    const moveTimeIndex = Math.floor(y / 30);

    setSchedules((prev) =>
      prev.map((schedule, idx) =>
        idx === Number(index)
          ? {
              ...schedule,
              day: DAY_LABELS[nowDayIndex + moveDayIndex],
              range: schedule.range.map((time) => time + moveTimeIndex),
            }
          : { ...schedule }
      )
    );
  };

  // SearchDialog에서 강의 추가
  const addLecture = useCallback(
    (lecture: Lecture) => {
      if (!searchInfo) return;

      const newSchedules: Schedule[] = parseSchedule(lecture.schedule).map((schedule) => ({
        ...schedule,
        lecture,
      }));

      setSchedules((prev) => [...prev, ...newSchedules]);
      setSearchInfo(null); // 모달 닫기
    },
    [searchInfo]
  );

  // 강의 삭제
  const deleteLecture = useCallback((day: string, time: number) => {
    setSchedules((prev) => prev.filter((schedule) => schedule.day !== day || !schedule.range.includes(time)));
  }, []);

  return (
    <Stack key={tableId} width="600px">
      <Flex justifyContent="space-between" alignItems="center">
        <Heading as="h3" fontSize="lg">
          시간표 {index + 1}
        </Heading>
        <ButtonGroup size="sm" isAttached>
          <Button colorScheme="green" onClick={() => setSearchInfo({ tableId })}>
            시간표 추가
          </Button>
          <Button colorScheme="green" mx="1px" onClick={() => onDuplicate(tableId, schedules)}>
            복제
          </Button>
          <Button colorScheme="green" isDisabled={disabled} onClick={() => onRemove(tableId)}>
            삭제
          </Button>
        </ButtonGroup>
      </Flex>

      {/* DnDContext 적용 */}
      <ScheduleDndProvider onDragStart={handleDragStart} onDragEnd={handleDragEnd}>
        <Box position="relative" outline={isActive ? '5px dashed' : undefined} outlineColor="blue.300">
          <ScheduleTemplate tableId={tableId} onCellClick={setSearchInfo} />

          {schedules.map((schedule, index) => (
            <DraggableSchedule
              key={`${schedule.lecture.title}-${index}`}
              id={`${tableId}:${index}`}
              data={schedule}
              bg={getColor(schedule.lecture.id)}
              onDeleteButtonClick={() => deleteLecture(schedule.day, schedule.range[0])}
            />
          ))}

          {searchInfo?.tableId === tableId && (
            <SearchDialog
              searchInfo={searchInfo}
              onClose={() => setSearchInfo(null)}
              addLecture={addLecture} // 모달에서 강의 추가
            />
          )}
        </Box>
      </ScheduleDndProvider>
    </Stack>
  );
});

export default ScheduleTable;

개별 시간표 내에서 강의 추가, 삭제, 수정 (dnd) 등의 상태 변화가 일어날 때 전체 시간표의 렌더링을 최적화하기 위해 useState로 개별 시간표 상태를 만들어 관리하도록 수정했다.

그리고 기존에 App.tsx 파일에 작성되어있던 ScheduleDndProvider를 각 테이블 파일 내로 이동시켜 전체 테이블 리렌더링을 최적화했다. 😊

KPT

Keep

이번 과제는 React Developer Tools를 사용하여 현재 페이지 내에서 컴포넌트 렌더링이 어떻게 진행되고 있는지 확인해가면서 직접 개선해나가는 의미있는 경험이었다. 아무래도 성능 최적화를 목표로 하여 개발한 경험이 없다보니 신기하게 느껴지기도 했고, 실제로 성능 개선이 눈에 보이는 과정을 겪으며 성취감도 느껴졌다.

Problem

위에서 말했듯 성능 최적화 경험이 없어서 그런지 과제를 시작할 때 감이 잘 잡히지 않았고, useMemo나 useCallback을 남발하게 됐던 것 같다. 어디까지 최적화를 적용해야 할지 판단하는 기준에 대해서도 확신이 서지 않는다. 코드를 작성할 때부터 성능을 의식하기보단 먼저 기능을 구현한 뒤에 성능을 측정하고 병목을 확인한 후에 최적화를 진행하는 습관을 들이면 감이 잡히지 않을까 하는 생각이 든다.

Try

예전에 시간표 컴포넌트를 구현해본 경험이 있는데, 그 때 스타일을 하나하나 계산하여 강의 아이템을 배치했었기 때문에 이번 과제로 처음 알게된 dnd 라이브러리가 너무 신기했다...😳 라이브러리를 사용하여 아주 간단한 사이트를 만들면서 글로도 정리해보고 싶다는 생각이 들었당

1. 기본 기능 및 대화 제어

2. 모델 설정 및 계정 관리

3. 파일 및 프로젝트 관리

4. 시스템 점검 및 요금 통계

5. 보기 및 입출력 설정

6. 코드 리뷰 및 분석

7. 편의성

8. 기능 확장

9. 기타

WIL

우선 개념 정리를 해보자..!

✅ CSR (Client Side Rendering)

서버는 기본적으로 빈 HTML + JS 파일을 내려주고 브라우저가 JS를 실행해 화면을 그리는 방식

• 초기 로딩 속도가 상대적으로 느림 (JS를 실행한 후 화면이 보이기 때문)
• 첫 화면은 늦게 뜨지만, 이후 페이지 전환은 빠름

✅ SSR (Server Side Rendering)

서버가 요청을 받을 때마다 완성된 HTML을 만들어 내려주고, 브라우저가 바로 렌더링하는 방식

• 첫 화면 로딩 속도가 빠름
• SEO에 유리
• 요청마다 HTML을 생성해야 하므로 서버 부하 증가

✅ SSG (Static Site Generation)

빌드 시점에 HTML을 미리 생성해두고, 사용자가 접속하면 즉시 정적 파일을 내려주는 방식

• 빠른 응답 속도
• SEO에 최적화
• 빌드 시점 이후의 데이터 반영이 어려움

✅ Hydration

클라이언트에서 JS가 실행되면서 기존 HTML에 이벤트 바인딩을 입히는 과정

• 빠른 첫 화면 제공
• 페이지가 크고 복잡할수록 하이드레이션 지연 문제 발생

1. Express SSR 서버

const prod = process.env.NODE_ENV === "production";
const app = express();

// node 환경에서 msw 서버 세팅
server.listen({
  onUnhandledRequest: "bypass",
});

let vite;

if (!prod) { // prod를 사용한 환경 분기 처리
  const { createServer } = await import("vite");

  // 개발 환경 - vite 미들웨어 주입
  vite = await createServer({
    server: { middlewareMode: true },
    appType: "custom",
  });
  app.use(vite.middlewares);
} else {
  const compression = (await import("compression")).default;
  const sirv = (await import("sirv")).default;
  app.use(compression());
  app.use(
    base,
    sirv("dist/vanilla", {
      extensions: [],
    }),
  );
}

app.use("*all", async (req, res) => {
    // ~

    const rendered = await render(url, req.query);

    // HTML 템플릿 치환
    const html = template
      .replace(`<!--app-head-->`, rendered.head ?? "")
      .replace(`<!--app-html-->`, rendered.html ?? "")
      .replace(
        `<!--app-initial-data-->`,
        `<script>window.__INITIAL_DATA__ = ${JSON.stringify(rendered.initialData)}</script>`,
      );

    res.status(200).set({ "Content-Type": "text/html" }).send(html);
  } catch (e) {
    vite?.ssrFixStacktrace(e);
    console.log(e.stack);
    res.status(500).end(e.stack);
  }
});

// Start http server
app.listen(port, () => {
  console.log(`React Server started at http://localhost:${port}`);
});

• Express 기반 서버 구축
• prod를 사용한 개발/프로덕션 환경 분기 처리
• HTML 템플릿 치환 : vite 미들웨어를 개발 환경에 적용하고, prod에서는 sirv로 정적 파일 제공, 모든 요청에서 render 결과를 HTML 템플릿에 치환해 클라이언트로 전달

2. 서버 사이드 렌더링

import { Router, ServerRouter } from "../lib";
import { BASE_URL } from "../constants.js";

export const router = typeof window !== "undefined" ? new Router(BASE_URL) : new ServerRouter("");

router.addRoute("/", HomePage);
router.addRoute("/product/:id/", ProductDetailPage);

export async function render(url, query = {}) {
  // ~

  const { path, params } = matched;

  let initialData;

  // 서버 데이터 프리페칭
  if (path === "/") {
    initialData = await fetchProductsDataSSR(query);
  } else if (path === "/product/:id/") {
    initialData = await fetchProductDataSSR(params.id);
  }

  let pageTitle;
  let pageHtml;

  // 페이지 상태 결정 및 HTML 렌더링
  if (path === "/") {
    pageTitle = "쇼핑몰 - 홈";
    pageHtml = HomePage({ initialData, query });
  } else if (path === "/product/:id/") {
    pageTitle = initialData?.currentProduct?.title ? `${initialData?.currentProduct?.title} - 쇼핑몰` : "쇼핑몰";
    pageHtml = ProductDetailPage({ initialData });
  } else {
    pageHtml = NotFoundPage();
  }

  // 렌더링 결과 반환 (initialData - 하이드레이션에 필요한 초기 상태)
  return {
    head: `<title>${pageTitle}</title>`,
    html: pageHtml,
    initialData,
  };
}

• 서버에서 동작하는 Router 구현
• 서버 데이터 프리페칭
• 서버 상태관리 초기화 : 요청 url에 따라 fetchProductDataSSR 함수를 통해 데이터를 미리 가져오고 initialData를 페이지 컴포넌트에 전달하여 서버에서 HTML 렌더링

3. 클라이언트 Hydration

const createMemoryStorage = () => {
  let value = {};

  return {
    getItem: (key) => (key in value ? value[key] : null),
    setItem: (key, value) => {
      value[key] = value;
    },
    removeItem: (key) => {
      delete value[key];
    },
    clear: () => {
      value = {};
    },
  };
};

const memoryStorage = createMemoryStorage();

// 브라우저 환경이 아닐 때를 위한 메모리 저장 storage 추가
export const createStorage = (key, storage = typeof window === "undefined" ? memoryStorage : window.localStorage) => {

export const HomePage = withLifecycle(
  {
    onMount: () => {
      if (typeof window === "undefined") return;
      loadProductsAndCategories(); // csr
    },
    watches: [
      [
        () => {
          const { search, limit, sort, category1, category2 } = router.query;
          return [search, limit, sort, category1, category2];
        },
        () => {
          loadProducts(true);
        },
      ],
    ],
  },
  // 서버에서 렌더링한 초기 데이터를 클라이언트에서 가져옴
  ({ initialData = window.__INITIAL_DATA__, query = router.query } = {}) => {
    if (!productStore.getState().products.length && initialData) {
      // initialData를 전역 상태에 넣어 SSR와 클라이언트 상태를 일치시킴
      productStore.dispatch({
        type: PRODUCT_ACTIONS.SETUP,
        payload: initialData,
      });
    }

    // SSR - initialData, CSR - store
    const productState = typeof window === "undefined" ? initialData : productStore.getState();

    const {
      search: searchQuery,
      limit,
      sort,
      category1,
      category2,
    } = typeof window === "undefined" ? query : router.query;


    return (
      // ~
    )
  } 
)

• window._INITIAL_DATA_ 스크립트 주입
• 클라이언트 상태 복원
• 서버-클라이언트 데이터 일치 : 서버에서 내려준 initialData를 클라이언트 store에 넣어 SSR과 동일한 상태를 복원하고, onMount에서 필요한 CSR API 호출로 상태를 최신화

4. Static Site Generation

async function generateStaticSite(url, query) {

  const rendered = await render(url, query);

  const html = template
    .replace(`<!--app-head-->`, rendered.head ?? "")
    .replace(`<!--app-html-->`, rendered.html ?? "")
    .replace(
      `</head>`,
      `
        <script>
          window.__INITIAL_DATA__ = ${JSON.stringify(rendered.initialData || {})};
        </script>
        </head>
      `,
    );

  if (url == "/404") {
    fs.writeFileSync("../../dist/vanilla/404.html", html);
  } else {
    // 지정한 경로에 폴더가 없으면 생성
    if (!fs.existsSync(`../../dist/vanilla${url}`)) {
      fs.mkdirSync(`../../dist/vanilla${url}`, { recursive: true });
    }
    // 렌더링된 HTML을 해당 폴더 안에 index.html 파일로 저장 - 정적 배포 가능한 파일
    fs.writeFileSync(`../../dist/vanilla${url}/index.html`, html);
  }
}

const { products } = await getProducts();

// 홈 페이지와 404 페이지를 빌드 타임에 미리 생성
await generateStaticSite("/", {});
await generateStaticSite("/404", {});
// 상품 목록을 순회하여 각 상품 페이지를 url 기준으로 HTML 생성
for (let i = 0; i < products.length; i++) {
  await generateStaticSite(`/product/${products[i].productId}/`, {});
}

vite.close();

• 동적 라우트 SSG (상품 상세 페이지들)
• 빌드 타임 페이지 생성
• 파일 시스템 기반 배포 : render로 HTML을 생성하고, url 별 폴더에 index.html로 저장하며 홈 페이지와 404 페이지는 빌드 시점에 미리 생성

KPT

Keep

으음

Problem

여기에 적어도 되는건진 모르겠지만..

윈도우에서는 한번에 여러 서버를 띄우는게 정상 작동하지 않아 라이브러리를 2개 추가한 뒤 스크립트 명령어를 수정해줘야 했다.. 이를 알기 전엔 테스트가 돌아가지 않는게 내가 코드를 잘못 건드려서 그런건지 이유를 알 수가 없어서 너무 스트레스를 받았다.

항해 매니저님께서 직접 원격 제어로 도와주신 덕분에 테스트는 돌아가게 되었으나.. 이미 의욕을 잃은 나는 기본 과제만 마무리하고 심화 과제는 통과하지 못했다.. ^^;

그리고 다음날 맥북 삼

Try

심화 과제 꼭 시도해보기..!!

저번 회고에서는 테스트 코드 개념 위주로 정리를 했다면, 이번 회고에서는 내가 과제 요구사항을 어떻게 구현했고 그 요구사항에 대한 테스트 코드를 어떻게 작성했는지에 대해 적어보려고 한다!!

WIL

✅ 테스트 코드

1. (필수) 반복 유형 선택
   • 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
   • 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
     • 31일에 매월을 선택한다면 → 매월 마지막이 아닌, 31일에만 생성하세요.
     • 윤년 29일에 매년을 선택한다면 → 29일에만 생성하세요!
2. (필수) 반복 일정 표시
   • 캘린더 뷰에서 반복 일정을 아이콘을 넣어 구분하여 표시한다.
3. (필수) 반복 종료
   • 반복 종료 조건을 지정할 수 있다.
   • 옵션: 특정 날짜까지
     • 예제 특성상, 2025-10-30까지 최대 일자를 만들어 주세요.
4. (필수) 반복 일정 단일 수정
   • 반복일정을 수정하면 단일 일정으로 변경됩니다.
   • 반복일정 아이콘도 사라집니다.
5. (필수) 반복 일정 단일 삭제
   • 반복일정을 삭제하면 해당 일정만 삭제합니다.

필수 요구사항은 위와 같다. 그리고 TDD (테스트 주도 개발) 방식으로 구현하는 것이 포인트였다. 테스트를 먼저 작성한 후 기능을 구현해야 했기에... 테스트 쪽으로는 경험이 적다보니 테스트 자체에 오류가 있어 결국 테스트 코드를 다시 건드리게 되는 경우가 다수였다. 🥹

// src/utils/repeatUtils.ts

// 반복 일정을 단일 일정으로 변환
export const toSingleEvent = (event: Event | EventForm): Event | EventForm => ({
  ...event,
  repeat: { type: 'none', interval: 0 },
});

// 반복 시작 날짜가 반복 종료 날짜보다 앞인지 확인
export const checkEndDateValid = (start: Date, end: Date): boolean => {
  return start <= end;
};

// ...

export const getRepeatEventList = (event: EventForm): EventForm[] => {
  if (event.repeat.type === 'none') return [event];

  switch (event.repeat.type) {
    case 'daily':
      return getDailyRepeatEvents(event);
    case 'weekly':
      return getWeeklyRepeatEvents(event);
    case 'monthly':
      return getMonthlyRepeatEvents(event);
    case 'yearly':
      return getYearlyRepeatEvents(event);
    default:
      return [event];
  }
};

우선 요구사항 중 반복 생성된 일정을 수정할 시 단일 일정으로 수정되어야 하기 때문에 인자로 받은 일정을 단일 일정으로 수정하는 유틸 함수를 작성해주었다. 그리고 반복 유형에 따라 매일, 매주, 매월, 매년 반복 일정을 생성하는 함수를 각각 작성한 후, 각 케이스에 맞게 호출되도록 하여 가독성을 높였다! 👍

추가로 반복 종료일을 지정하지 않은 상태에서 반복 일정을 (과제 특성 상) 2025-10-30 이후부터 생성할 경우, 해당 일정을 하나만 생성되도록 하기 위해 반복 시작 날짜가 반복 종료 날짜보다 앞인지 확인하는 검증 함수를 추가했다.

// 반복 설정 컴포넌트
{isRepeating && (
  <Stack spacing={2}>
    <FormControl fullWidth>
      <FormLabel>반복 유형</FormLabel>
      <Select
        size="small"
        aria-label="반복 유형 선택"
        value={repeatType}
        onChange={(e) => setRepeatType(e.target.value as RepeatType)}
      >
        <MenuItem value="daily" aria-label="daily-option">
          매일
        </MenuItem>
        <MenuItem value="weekly" aria-label="weekly-option">
          매주
        </MenuItem>
        <MenuItem value="monthly" aria-label="monthly-option">
          매월
        </MenuItem>
        <MenuItem value="yearly" aria-label="yearly-option">
          매년
        </MenuItem>
      </Select>
    </FormControl>

    <Stack direction="row" spacing={2}>
      <FormControl fullWidth>
        <FormLabel htmlFor="repeat-interval">반복 간격</FormLabel>
        <TextField
          id="repeat-interval"
          size="small"
          type="number"
          aria-label="반복 간격 선택"
          value={repeatInterval}
          onChange={(e) => setRepeatInterval(Number(e.target.value))}
          slotProps={{ htmlInput: { min: 1 } }}
        />
      </FormControl>

      <FormControl fullWidth>
        <FormLabel htmlFor="repeat-end">반복 종료일</FormLabel>
        <TextField
          id="repeat-end"
          size="small"
          type="date"
          aria-label="반복 종료일 선택"
          value={repeatEndDate}
          onChange={(e) => setRepeatEndDate(e.target.value)}
        />
      </FormControl>
    </Stack>
  </Stack>
)}


// 반복 일정 생성
it('생성한 반복 일정이 반복 설정에 맞게 표시된다', async () => {
  setupMockHandlerRepeatCreation();
  const { user } = setup(<App />);

  await user.click(screen.getAllByText('일정 추가')[0]);

  await user.type(screen.getByLabelText('제목'), '정기 회의');
  await user.type(screen.getByLabelText('날짜'), '2025-10-01');
  await user.type(screen.getByLabelText('시작 시간'), '11:00');
  await user.type(screen.getByLabelText('종료 시간'), '12:00');
  await user.type(screen.getByLabelText('설명'), '정기 팀 미팅');
  await user.type(screen.getByLabelText('위치'), '회의실 A');
  await user.click(screen.getByLabelText('카테고리'));
  await user.click(within(screen.getByLabelText('카테고리')).getByRole('combobox'));
  await user.click(screen.getByRole('option', { name: `업무-option` }));

  const repeatCheckbox = screen.getByLabelText('반복 일정');
  await user.click(repeatCheckbox);

  // 반복 유형 선택 - 매주
  const repeatSelect = within(screen.getByLabelText('반복 유형 선택')).getByRole('combobox');
  await user.click(repeatSelect);
  await user.click(screen.getByRole('option', { name: 'weekly-option' }));

  // 반복 간격 선택 - 2주 간격
  await user.clear(screen.getByLabelText('반복 간격'));
  await user.type(screen.getByLabelText('반복 간격'), '2');

  // 반복 종료일 선택
  await user.type(screen.getByLabelText('반복 종료일'), '2025-10-30');

  // 일정 추가
  await user.click(screen.getByTestId('event-submit-button'));

  const eventList = within(screen.getByTestId('event-list'));
  expect(eventList.getAllByText('정기 회의')).toHaveLength(3); 
  // 2025-10-01, 2025-10-15, 2025-10-29
});

테스트 라이브러리는 aria-label="반복 유형 선택"의 label 값을 통해 select를 찾을 수 있게 된다. 그리고 select는 시맨틱 상 combobox 역할을 가지므로, getByRole('combobox')를 사용하여 더욱 정확히 select를 가져올 수 있다.

내부 항목들은 role="option"이면서 weekly-option'와 같은 이름으로 노출되므로 getByRole('option', { name: 'weekly-option' })로 가져와 선택할 수 있게 된다.

반복 간격과 종료일의 경우 FormLabel 내의 텍스트로 컴포넌트를 찾은 뒤, 해당 컴포넌트의 htmlFor 속성과 id 값의 매칭을 통해 각 label에 맞는 TextField를 가져온다. 추가로 반복 간격의 경우엔 input 필드에 이미 들어있는 값을 지우고 새로운 값을 확실히 입력하기 위해 userEvent.clear을 먼저 실행해주었다 😊

// 단일 일정 컴포넌트
<Stack direction="row" spacing={1} alignItems="center">
  {isNotified && <Notifications fontSize="small" />}

  <Typography
    variant="caption"
    noWrap
    sx={{ fontSize: '0.75rem', lineHeight: 1.2 }}
  >
    {event.repeat.type !== 'none' && <span>*</span>}
    {event.title}
  </Typography>
</Stack>


// 반복 일정은 제목 앞에 * 표시
it('캘린더 뷰에서 반복 일정은 아이콘으로 표시된다', async () => {
  setupMockHandlerRepeatCreation();
  const { user } = setup(<App />);

  await user.click(screen.getAllByText('일정 추가')[0]);

  await user.type(screen.getByLabelText('제목'), '정기 회의');
  await user.type(screen.getByLabelText('날짜'), '2025-10-01');
  await user.type(screen.getByLabelText('시작 시간'), '11:00');
  await user.type(screen.getByLabelText('종료 시간'), '12:00');
  await user.type(screen.getByLabelText('설명'), '정기 팀 미팅');
  await user.type(screen.getByLabelText('위치'), '회의실 A');
  await user.click(screen.getByLabelText('카테고리'));
  await user.click(within(screen.getByLabelText('카테고리')).getByRole('combobox'));
  await user.click(screen.getByRole('option', { name: `업무-option` }));

  const repeatCheckbox = screen.getByLabelText('반복 일정');
  await user.click(repeatCheckbox);

  // 반복 유형 선택 - 매일
  await user.click(within(screen.getByLabelText('반복 유형 선택')).getByRole('combobox'));
  await user.click(screen.getByRole('option', { name: 'daily-option' }));

  // 반복 종료일 선택
  await user.type(screen.getByLabelText('반복 종료일'), '2025-10-03');

  // 일정 추가
  await user.click(screen.getByTestId('event-submit-button'));

  const monthView = within(screen.getByTestId('month-view'));
  expect(monthView.getAllByText('*')).toHaveLength(3);
});

필수 요구사항에 따르면 반복 생성된 일정은 아이콘을 넣어 구분 표시를 해야 했기 때문에, 난 간단하게 * 문자열 하나만 추가했다...ㅎㅎ 이때 event.title과 * 을 문자열 하나로 합치지 않고, span 태그로 감싸줬다.

getAllByText는 DOM 내 텍스트 노드 단위로 요소를 찾기 때문에 span과 같은 태그로 감싸줬을 경우엔 테스트가 동작하지만, title 값과 합쳤을 경우엔 그 자체가 하나의 문자열 노드가 되기 때문에 테스트에서 인식되지 않는다!!

✅ 테스트 전략

테스트 피라미드 전략

• 단위 테스트가 많고 빠름 → 로직 검증 빠르게 가능
• 통합 테스트는 중간 수준 → 모듈 간 상호작용 검증
• E2E는 적고 느림 → 전체 흐름 검증, 비용 높음
• 목표 : 빠르고 안정적인 테스트를 많이 확보하면서, 전체 기능 검증도 최소한으로 유지

테스트 트로피 전략

• 통합 테스트가 중심 → UI와 컴포넌트 상호작용을 많이 검증
• 단위 테스트는 로직만 검증, 피라미드보다 비율 줄임
• UI 중심 앱에 적합 → React, Vue 같은 SPA에서 많이 사용

+) 팀원들과의 회의 후 테스트 트로피 전략을 선택한 후 통합 테스트와 훅 테스트를 추가했으나, e2e나 시각적 회귀 테스트를 작성하지 않아서 심화 과제는 실패했다.. 🥹 앞으론 과제 통과 기준을 확실히 알자...

KPT

Keep

잘하고있다.. !

Problem

TDD 방식의 구현은 처음이라 시작할 때 좀 막막했던 것 같고, 위에 적은 말이지만 테스트 코드 자체에 오류가 있어 시간을 많이 쓴 것 같다. 그래도 이번 과제를 통해 테스트에서 요소를 정확히 찾아 이벤트를 트리거하는 과정을 거치면서 DOM 조작과 이벤트 시뮬레이션에 대한 이해가 향상된 것 같다!

Try

사실 아직 어떤 테스트가 불필요한 테스트인지 명확히 구분하는 게 어려운 것 같다. 다다익선이 아니라니... 공부 필요...

너무나 겁먹었던 테스트 코드 챕터... 간단히 기록해보자

WIL

✅ 테스트 코드의 흐름

1. 렌더링하기

• render - 렌더링 수행
• screen - 렌더링된 화면처럼 인터페이스가 구현된 객체에 접근

  import { render, screen } from '@testing-library/react';
  

test('should show login form', () => { render()

// 화면에서 Username 레이블 텍스트를 가진 요소 가져옴 const input = screen.getByLabelText('Username'); })

### 2. 사용자 인터렉션
- **fireEvent** – 이벤트를 직접 디스패치, 일부 특수 이벤트나 userEvent 미지원 시 사용
- **userEvent** – 실제 사용자가 상호작용하는 것처럼 이벤트 시뮬레이션
- **userEvent.setup()** – 테스트마다 독립된 user 인스턴스를 생성, 연속적인 사용자 동작을 정확히 시뮬레이션

<br />

- **user.click(element)** – 요소 클릭
- **user.dblClick(element)** – 더블 클릭
- **user.hover(element)** – 요소 위로 마우스 이동
- **user.unhover(element)** – 요소에서 마우스 이동
- **user.type(element, "text")** – 입력 필드에 텍스트 입력
- **user.clear(element)** – 입력 필드 초기화
- **user.keyboard("text")** – 키보드 입력 시뮬레이션
- **user.tab()** – 탭키로 포커스 이동
- **user.selectOptions(selectElement, "value")** – 셀렉트 박스 선택

```javascript
it('기존 일정의 세부 정보를 수정하고 변경사항이 정확히 반영된다', async () => {
  setupMockHandlerUpdating();
  const { user } = setup(<App />);

  const editButtons = await screen.findAllByRole('button', { name: 'Edit event' });
  const titleInput = screen.getByLabelText('제목');

  await user.click(editButtons[0]); // 수정 버튼 클릭

  expect(screen.getByRole('button', { name: '일정 수정' })).toBeInTheDocument();
  expect(screen.getByDisplayValue('기존 회의')).toBeInTheDocument();

  await user.clear(titleInput); // 입력 필드 값 초기화
  await user.type(titleInput, '기존 회의3'); // 입력 필드에 '기존 회의3' 텍스트 입력
  await user.click(screen.getByRole('button', { name: '일정 수정' })); // 일정 수정 버튼 클릭

  const eventList = within(screen.getByTestId('event-list'));
  expect(await eventList.findByText('기존 회의3')).toBeInTheDocument();
});

3. 대상 가져오기

• 단일 요소 가져오기

• 다중 요소 가져오기

• getByRole - 접근성 트리에서 role을 기반으로 가져옴

  test('', () => {
    screen.getByRole('button');
  });

• getByTestId test용 id 속성을 넣어 가져올 수 있음

  test('', () => {
    // data-testid="test-button" 속성을 가진 요소
    screen.getByTestId('test-button');
  });

• getByText - 텍스트를 기반으로 가져옴

  // <div>Hello World</div>
  

screen.getByText('Hello World') // 텍스트가 매치되는 요소 screen.getByText('llo Worl', {exact: false}) // 일부만 매치 screen.getByText(/World/) // 정규식 활용 screen.getByText((content, element) => content.startsWith('Hello')) // 함수로 가져옴

### ✅ 자주 쓰이는 API
- **beforeEach** – 각 테스트 실행 전 공통 준비
- **afterEach** – 각 테스트 실행 후 정리
- **beforeAll** – 모든 테스트 시작 전 한 번 실행
- **afterAll** – 모든 테스트 종료 후 한 번 실행
<br />
- **vi.fn()** – 모의 함수 생성
- **vi.mock()** – 모듈의 모의화
- **vi.spyOn()** – 객체의 메서드를 감시
- **vi.waitFor()** – 비동기 작업이 완료될 때까지 기다림

<br />

+) 🤜 과제를 통해 알게된 점.. 🥸
```javascript
// src/__mocks__/handlersUtils.ts
export const setupMockHandlerDeletion = () => {
  const mockEvents: Event[] = [
    {
      id: '1',
      title: '삭제할 이벤트',
      date: '2025-10-15',
      startTime: '09:00',
      endTime: '10:00',
      description: '삭제할 이벤트입니다',
      location: '어딘가',
      category: '기타',
      repeat: { type: 'none', interval: 0 },
      notificationTime: 10,
    },
  ];
  server.use(
    http.get('/api/events', () => {
      return HttpResponse.json({ events: mockEvents });
    }),
    http.delete('/api/events/:id', ({ params }) => {
      const { id } = params;
      const index = mockEvents.findIndex((event) => event.id === id);
      mockEvents.splice(index, 1);
      return new HttpResponse(null, { status: 204 });
    })
  );
};

// src/__tests__medium.integration.spec.tsx
it("네트워크 오류 시 '일정 삭제 실패'라는 텍스트가 노출되며 이벤트 삭제가 실패해야 한다", async () => {
  setupMockHandlerDeletion();

  // 삭제 처리가 실패하도록 덮어씀
  server.use(
    http.delete('/api/events/:id', () => {
      return HttpResponse.error();
    })
  );

  const { result } = renderHook(() => useEventOperations(true));

  await act(async () => {
    result.current.deleteEvent('1');
  });

  expect(enqueueSnackbarFn).toHaveBeenCalledWith('일정 삭제 실패', { variant: 'error' });
});

우선 각 테스트에서 사용되는 목 데이터와 서버 처리 로직을 하나의 함수로 묶어서 모킹한 부분이 되게 인상적이었다... 반복되는 목 데이터 재사용도 가능하고 엄청 깔끔해보였다. 하나의 함수를 여러 개의 테스트에 적용할 수 있으니까!!

그리고 처음 네트워크 오류 처리를 다루는 테스트를 접하고 도대체 어떻게 작성해야 하는건지 상상도 되지 않았다... 이러한 특수한 상황도 테스트가 가능하다는 사실을 처음 알게 되었다. 실제 환경에서 발생할 수 있는 여러 케이스를 시뮬레이션하고, ui 반응이나 오류 처리 로직을 검증할 수 있다는게 놀라웠다. 👍

KTP

Keep

꾸준히... 과제를 하자

Problem

역시 경험이 많이 없다보니 너무 생소하게 느껴졌다... 앞으로 테스트 코드와 더 친해져보자..

Try

개인 플젝에 테스트 코드 도입해보기

얼마 전에 FSD 패턴이라는 걸 알게 되었고.. 꼭 공부해보고 싶다는 생각이 들었는데 딱 마침 이번 과제가 FSD 패턴. 어째 이런 타이밍이!!! 근데 너무 어려워

WIL

✅ FSD 패턴

Feature-Sliced Design - 프론트엔드 애플리케이션 구조를 위한 아키텍처 방법론. 코드를 어떻게 분리하고 구성할지를 명확히 정의하여, 변화하는 비즈니스 요구 속에서도 프로젝트를 이해하기 쉽고 안정적으로 유지할 수 있도록 함.

1. App - Routing, Entrypoint, Global Styles, Provider 등 앱을 실행하는 모든 요소
2. Processes(더 이상 사용되지 않음) - 페이지 간 복합 시나리오
3. Pages - 전체 page 또는 중첩 Routing의 핵심 영역
4. Widgets - 독립적으로 동작하는 대형 UI·기능 블록
5. Features - 제품 전반에서 재사용되는 비즈니스 기능
6. Entities - user, product 같은 핵심 도메인 Entity
7. Shared - 프로젝트 전반에서 재사용되는 일반 유틸리티

• Slice는 Layer 내부를 비즈니스 도메인별로 나누고, 같은 Layer 내 다른 Slice를 참조할 수 없다 = 응집도↑ 결합도↓

• Slice와 App, Shared Layer는 Segment로 세분화되어, 기술적 목적에 따라 코드를 그룹화한다

  • ui - UI components, date formatter, styles 등 UI 표현과 직접 관련된 코드
  • api - request functions, data types, mappers 등 백엔드 통신 및 데이터
  • model - schema, interfaces, store, business logic 등 애플리케이션 도메인 모델
  • lib - 해당 Slice에서 여러 모듈이 함께 사용하는 공통 library code
  • config - configuration files, feature flags 등 환경·기능 설정

src
├── app 
├── entities
│   ├── comment
│   │   ├── api
│   │   ├── config
│   │   ├── model
│   │   └── ui
│   ├── post
│   │   └── ..
│   └── user
│       └── ..
├── features
│   ├── comment
│   │   ├── add-comment
│   │   │   ├── model
│   │   │   └── ui
│   │   ├── delete-comment
│   │   │   └── ..
│   │   ├── like-comment
│   │   │   └── ..
│   │   └── update-comment
│   │   │   └── ..
│   └── post
│       └── ..
├── pages
├── shared
│   ├── hook
│   ├── lib
│   └── ui 
├── widgets
│   ├── dialog
│   ├── post-detail-content
│   ├── post-filter
│   ├── post-pagination
│   └── post-table
└── main.tsx

취향껏.. 마음대로 리팩토링을 진행한 결과 위의 폴더 구조가 완성됐다. main.tsx를 app 폴더에 넣었다가 다시 밖으로 뺐는데 그대로 둘걸 하는 생각이..🥲

가장 고민을 많이 한 부분은 widgets인 것 같다. post-filter 내에 검색어, 태그, 정렬 등 게시물 필터와 관련된 ui를 분리하지 않고 두었는데 이를 하나하나 컴포넌트로 따로 분리해야 하는게 나은지, 필터와 관련된 로직은 전부 쿼리 훅 하나로 해결이 되는데 굳이 분리가 필요한지, 아님 게시물의 필터가 바뀌는 것도 하나의 기능으로 보고 features에 두어야 할지 등등.. 아직도 답을 모르겠는 고민들을 엄청 했다. 결국 굳이 세분화하지 않고 하나로 두었지만..!!

이번 과제에서 fsd 못지않게 고민하고 애썼던 부분은 tanstack-query로 낙관적인듯 아닌듯 낙관적 업데이트를 구현하는 거였다..

기존 코드는 더미 데이터와 목 api를 사용하고 탄스택 쿼리를 사용하지 않기에 프론트 내에서 따로 상태로 관리하여 페이지 기능이 처리되도록 되어 있었다. 나는 이를 탄스택 쿼리로 리팩토링해야했다...

// src/entities/commment/model/store.ts

export const commentModel = {
  /**
   * 댓글 추가
   */
  addComment: (commentData: IComments, newComment: IComment): IComments => {
    return {
      ...commentData,
      comments: [newComment, ...commentData.comments],
    };
  },
}

우선 entities에 각 도메인마다 상태 업데이트에 사용될 순수 함수를 작성해주었다. 항해 과제를 하면서 매번 순수 함수를 작성하고 있는데 너무 깔끔하고 좋은 것 같다...

// src/features/commment/add-comment/model/useAddComment.ts

export const useAddComment = (postId: number, onSuccess?: () => void) => {
  const queryClient = useQueryClient();

  const initialComment: IAddComment = { body: '', postId: postId, userId: 1 };
  const [newComment, setNewComment] = useState<IAddComment>(initialComment);

  const mutation = useMutation({
    mutationFn: (comment: IAddComment) => addCommentApi(comment),

    onSuccess: (createdComment) => {
      const newComment = commentModel.addResponseToComment(createdComment);

      queryClient.setQueryData<IComments>(['comments', postId], (prev) => {
        if (!prev) {
          return {
            comments: [newComment],
            total: '1',
            skip: 0,
            limit: 10,
          };
        }

        return commentModel.addComment(prev, newComment);
      });

      onSuccess?.();
      setNewComment(initialComment);
    },
    onError: (error) => {
      console.error('댓글 추가 오류:', error);
    },
  });

  const setBody = (body: string) =>
    setNewComment((prev) => ({ ...prev, body }));

  const addComment = () => {
    mutation.mutate(newComment);
  };

  return { newComment, setBody, addComment };
};

features 내의 model 세그먼트 폴더에 탄스택 쿼리 훅을 작성해주었고, onSuccess에 entities 내에 만들었던 도메인 상태 업데이트 순수 함수를 사용했다.

(기존 코드에서는 api 요청의 응답으로 온 값으로 상태를 업데이트하도록 되어 있어서 onSuccess 내에서 처리하도록 했는데 이제 생각해보니 onMutate에서 처리하는게 맞는 것 같다 😶)

// src/features/commment/add-comment/ui/AddCommentForm.ts

const AddCommentForm = ({ postId }: AddCommentFormProps) => {
  const { setCommentModal } = useDialogStore();
  const { newComment, setBody, addComment } = useAddComment(postId, () => {
    setCommentModal({ show: false, content: null });
  });

  return (
    <DialogContent>
      <DialogHeader>
        <DialogTitle>새 댓글 추가</DialogTitle>
      </DialogHeader>
      <div className="space-y-4">
        <Textarea
          placeholder="댓글 내용"
          value={newComment.body}
          onChange={(e) => setBody(e.target.value)}
        />
        <Button onClick={addComment}>댓글 추가</Button>
      </div>
    </DialogContent>
  );
};

최종 코드는 이런 느낌..

+) 추가적으로 팀원들 덕분에 인터페이스 앞에 I를 붙이는게 좋지 않다는 걸 알게 되었다... 이제부터 안써준다.

KTP

Keep

잘 모르겠는 부분은 팀원에게 (다른 팀이어도) 질문해보는 자세 다같이 의견 나누는게 너무 좋당

Problem

충분히 잘하고 있어... (라고 믿기)

Try

개인 프로젝트에 FSD 구조 사용해보기..!! 사람마다 기준이 너무 달라서 팀 프로젝트에서는 FSD 패턴을 도입하고 싶은 생각이 든다 해도 제안하기엔 무리일 것 같다... 그치만 더 공부해보고 싶음

WIL

이번 과제는 저번주처럼 후회하고 싶지 않기 때문에... 제공된 리팩토링 힌트 폴더 구조를 그대로 따르기로 했다.

refactoring(hint)
├── components - icon 및 ui
├── constants - 초기 데이터 상수
├── hooks - 상태 관리 (localStorage 연동)
├── models - 비즈니스 로직 (순수 함수)
├── utils - 공용 유틸리티
│   ├── validators.ts
│   ├── formatters.ts
│   └── hooks - 유틸 전용 훅
│       ├── useLocalStorage.ts
│       └── useDebounce.ts
├── App.tsx
└── main.tsx

제일 먼저는 상품 컴포넌트, 알림 모달 컴포넌트, 쿠폰 컴포넌트, svg 아이콘 등 작은 단위의 컴포넌트 분리를 진행했다. 이게 좋은 선택이었는진 모르겠지만 딱 작은 컴포넌트만 분리하고 그 이상은 진행하지 않았기에.. 이후에 걸림돌이 되지 않았던 것 같다.

컴포넌트 분리 후 models 폴더 내에 비즈니스 로직 (순수 함수) 구현을 했는데, 이때 models과 hooks의 차이가 뭔지 잘 이해되지 않았다. 결국 하는 역할은 똑같은거 아닌가? 하는 생각이 들었고.. 이 의문은 useLocalStorage 훅을 구현하고 적용한 이후에 해결되었다. model은 내가 연산 기호를 정의한 거라면 hook은 그 연산 기호를 사용하여 직접 상태 값을 업데이트 해주는 느낌..? 이 구현 순서를 의도하여 힌트를 주신 건가? 하는 생각도 들었다.

// src/basic/models/cart.ts

export const cartModel = {
  /**
   * 장바구니에 상품 추가
   */
  addToCart: (cart: ICartItem[], product: IProductWithUI): ICartItem[] => {
    // 이미 장바구니에 존재하는 상품 처리
    const existingItem = cart.find((item) => item.product.id === product.id);

    if (existingItem) {
      const newQuantity = existingItem.quantity + 1;

      // 재고 초과 시 기존 cart 반환
      if (newQuantity > product.stock) {
        return cart;
      }

      // 수량만 업데이트
      return cart.map((item) =>
        item.product.id === product.id
          ? { ...item, quantity: newQuantity }
          : item
      );
    }

    // 장바구니에 없는 상품이면 새 아이템 추가
    return [...cart, { product, quantity: 1 }];
  },
};

// src/basic/hooks/useCart.ts

export const useCart = () => {
  // 로컬스토리지 연동된 cart
  const [cart, setCart] = useLocalStorage<ICartItem[]>("cart", initialCarts);

  /**
   * 장바구니에 상품 추가
   */
  const addToCart = (product: IProductWithUI) => {
    setCart((prev) => cartModel.addToCart(prev, product));
  };

  return { addToCart };
};

장바구니에 상품을 추가하는 함수를 기준으로 설명하자면, models의 순수 함수는 장바구니 배열과 추가할 상품을 둘 다 인자로 받아 이미 장바구니에 존재하는 상품인지를 확인한 후 각 상황에 맞는 값을 반환한다. 그리고 hooks에서는 장바구니와 연동된 setCart 함수를 통해 cartModel의 순수 함수를 사용하여 cart 상태를 업데이트해주었다.

hooks 함수를 구현하면서 가장 고민했던 부분은 addNotification 함수 처리인 것 같다. 상태 관리만 담당하는 함수가 ui 관련 처리까지 담당해도 되는가에 대해 오래 고민했는데, 단일 책임 원칙에 따라 역할을 분리하는 것이 맞다고 판단하여 해당 함수가 필요한 컴포넌트 내에서 hooks 함수와 addNotification 함수를 같이 받아와 처리하도록 구현했다.

// 🌟 개선 예시

// models/cart.ts (pure)
export const cartModel = {
  isCouponApplicable: (cartItems: CartItem[], coupon: Coupon) => {
    const total = calculateCartTotalFromItems(cartItems); // pure fn
    if (coupon.discountType === 'percentage' && total.totalAfterDiscount < ORDER.MIN_FOR_COUPON) {
      return { ok: false, reason: 'MIN_PRICE' };
    }
    return { ok: true };
  },

  applyCoupon: (cartItems: CartItem[], coupon: Coupon) => {
    if (!cartModel.isCouponApplicable(cartItems, coupon).ok) {
      return { cartItems, selectedCoupon: null, error: 'NOT_APPLICABLE' };
    }
    // 실제 할인 계산은 calculateCartTotalFromItems가 적용하도록 selectedCoupon만 반환
    return { cartItems, selectedCoupon: coupon, error: null };
  }
};


// hooks/useCart.ts
export const useCart = () => {
  const [cart, setCart] = useLocalStorage('cart', []);
  const [selectedCoupon, setSelectedCoupon] = useState<ICoupon|null>(null);

  const applyCoupon = (coupon: ICoupon, options?: { onSuccess?: ()=>void; onError?: (msg:string)=>void }) => {
    const result = cartModel.applyCoupon(cart, coupon);

    if (result.error) {
      options?.onError?.(MESSAGES.COUPON.MIN_PRICE);
      return false;
    }

    setSelectedCoupon(coupon);
    options?.onSuccess?.();

    return true;
  };

  return { cart, selectedCoupon, applyCoupon, setSelectedCoupon, ... };
};


// CouponSelector.tsx (TO-BE)
const { applyCoupon } = useCart();
const { addNotification } = useNotification();

const onSelect = (coupon) => {
  applyCoupon(coupon, {
    onSuccess: () => addNotification(MESSAGES.COUPON.APPLIED, 'success'),
    onError: (msg) => addNotification(msg ?? MESSAGES.COUPON.MIN_PRICE, 'error')
  });
};

그런데 코드 리뷰로 받은 개선 예시를 보고... 이런 방법이 있구나 싶었다.

나는 applyCoupon 함수 내에 setSelectedCoupont, addNotification 등의 함수 처리를 어떻게 해야할지 모르겠어서 useCart 훅 내부가 아닌 해당 함수를 필요로 하는 컴포넌트 내에 작성했다.

그런데 위의 예시를 보면 model에서 장바구니 금액이 쿠폰 최소 조건을 충족하는지 판단하고 -> hook에서 성공, 에러에 따라 콜백 함수를 호출하고 -> 컴포넌트에선 콜백 함수로 addNotification 함수를 보내 알림 ui 처리를 한다.

비즈니스 로직, 상태, UI를 분리해 테스트 용이성과 유연성을 높인.. 너무나도 깔끔한 구조이다. 왜 이럴 생각을 못했을까 🥲 (isCouponApplicable 함수까지는 고민해봤는데 그 이후에 진도가 나가지 않아 지웠버렸다.. ㅜㅜ)

// src/advanced/components/product/ProductForm.tsx

interface ProductFormProps {
  // product
  setShowProductForm: React.Dispatch<React.SetStateAction<boolean>>;
  editingProduct: string | null;
  setEditingProduct: React.Dispatch<React.SetStateAction<string | null>>;
  productForm: IProductForm;
  setProductForm: React.Dispatch<React.SetStateAction<IProductForm>>;
}

심화 과제는 기본 과제에 전역 상태 라이브러리를 적용하는 것이었는데 상품 생성 및 수정 폼 관련 props는 끝내 지우지 못했다.. 커스텀 훅으로의 추상화가 필요하다는 걸 인지하고 있었지만 과제 마무에 집중하면서 미루고 미루다 결국 리팩토링하지 못했다. 추후에는 이 부분을 폼 전용 커스텀 훅으로 분리하여 좀 더 읽기 쉽고 관리하기 쉬운 구조로 개선하고 싶다!!!

KPT

Keep

하라는 대로 하는 자세.. 👍

Problem

이렇게 구현해볼까? 하는 마음이 생기면 망설이지 말고 해보기

Try

코드 리뷰로 알게된 내용들을 6주차 과제에 녹여보기..!!

벌써 두번째 챕터... 이번 챕터의 주제는 클린코드이다.

What: 클린 코드는 다음과 같은 특징을 가진 코드입니다.

• 가독성: 좋은 코드는 읽기 쉽고 이해하기 쉽습니다.
• 유지보수성: 좋은 코드는 수정사항에 대응하기 쉬우며, 수정에 독립적이고 찾기 쉽습니다.
• 확장성: 좋은 코드는 새로운 기능을 추가할 때, 기존 코드를 크게 수정하지 않을 수 있습니다.
• 견고성: 좋은 코드는 에러가 발생했을 경우에도 동작하거나 대응하고, 에러를 발견하기 쉽습니다.
• 테스트 가능성: 좋은 코드는 테스트를 작성하기 쉬우며, 단위별 테스트를 할 수 있습니다.
• 자기문서화: 좋은 코드는 요구사항을 코드 자체로 이해할 수 있게 합니다.
• 일관성: 좋은 코드는 같은 규칙과 철학으로 작성되어 예측이 가능합니다.

Why: 클린 코드를 작성하는 것은 다음과 같은 장점을 가져다줍니다.

• 코드의 가독성이 높아져 유지보수가 용이해집니다.
• 버그 발생 가능성이 낮아져 코드의 안정성이 높아집니다.
• 개발 속도가 향상되고, 개발 비용이 절감됩니다.
• 팀원 간의 협업이 용이해집니다.

How: 클린 코드를 작성하기 위해서는 다음과 같은 원칙을 따르는 것이 좋습니다.

• DRY(Don't Repeat Yourself) 원칙
  • 같은 코드를 반복적으로 작성하지 않도록 합니다.
• KISS(Keep It Simple, Stupid) 원칙
  • 코드를 최대한 간단하게 작성합니다.
• YAGNI(You Ain't Gonna Need It) 원칙
  • 필요하지 않은 코드는 작성하지 않습니다.

내가 지금까지 클린코드를 작성하자 라는 생각을 갖고 개발을 한 적이 있나 되돌아보게 되는 주제였다. 그래서 이번 주에 클린코드를 마스터하자는 다짐과 함께 과제를 봤는데

이건 아니잖아

기본 과제는 위 코드를 리액트와 타입스크립트로 리팩토링할 것을 염두해 두고 순수 js로만 리팩토링하는 거였고, 심화 과제는 기본 과제를 바탕으로 리액트와 타입스크립트로 리팩토링을 마친 뒤 배포까지 하는 거였다.

WIL

1주차부터 나의 자바스크립트 구멍을 뼈저리게 느끼고 있다... 처음엔 진짜 어떻게 시작해야할지 감도 잡히지 않아서 일단 전체 코드 해석을 시작했고 그렇게 하루가 그냥 지나갔다.

다음 날 일단 뭐라도 해야겠다는 생각에 제일 기본적인 var 변수 및 불필요한 코드 없애기, 간단한 util 함수 작성, 비즈니스 함수 작성을 진행했고.. 함수 내에서 innerHTML을 쓰든 말든 일단 연산 코드와 ui에 관여하는 코드를 분리하는 데에만 바빴다.

그런데 화요일 밤에 진행된 과제 QnA를 듣고 내가 완전히 잘못된 방향으로 가고 있다는 걸 깨달았다. 난 리액트로의 리팩토링에 하등 도움이 되지 않는 코드를 작성하고 있었다.

어떡하긴.. 과제 제출이 2일 정도 남았지만 이제라도 엎어야지

// 테오 코치의 멘토링 중 일부..

 DOM의 역할은 그리는 애다!! (얘는 데이터의 원천이 되지 못한다.)

 Model
 - state
 - calc

 View
 - computed value -> render
 - event

 Controller

 event -> state를 변경하게
 rerender를 요청한다.

우선 전역 상태를 기반으로 ui가 렌더링 되도록 하는 것이 제일 급한 부분이었다.

 const appState = {
  totalPoints: 0, // 최종 적립 포인트
  pointsDetail: [], // 포인트 상세 문자열

  totalProductCount: 0, // 장바구니 내 총 상품 수 (헤더)
  totalBeforeDiscount: 0, // 할인 전 장바구니 내 총 상품 가격
  totalAfterDiscount: 0, // 장바구니 내 총 상품 가격

  totalDiscountedRate: 0, // 총 할인율
  discountedProductList: [], // 할인 적용된 상품 목록
  lastSelectedProductId: null, // 제일 최근에 장바구니에 담은 상품의 id
};

// 최종 상태 관리
const state = {
  productState: productList,
  cartState: cartList,
};

시간이 너무 촉박했기에 상품 목록과 장바구니 목록, 그리고 화면에 보여지는 값(상품과 장바구니 상태에 따라 달라지는 파생 계산 값)들을 모두 묶어 전역 상태로 만들었다. 좋지 않은 방식인건 알았지만 과거의 나는 너무 급했다...

export const renderCartProductList = (state) => {
  const { cartState, productState } = state;

  const container = document.getElementById('cart-items');
  container.innerHTML = ''; // 기존 초기화

  cartState.forEach((item) => {
    // { id: , count: }
    const product = findProductById(productState, item.id);
    const productItem = createCartProduct(product, item.count); // HTML 요소 반환
    container.appendChild(productItem);
  });
};

// ...

export const updateUI = ({ state, appState }) => {
  renderTuesdaySpecial(appState);
  renderCartSummaryDetail({ state, appState });
  renderCartTotalPrice(appState);
  renderDiscountRate(appState);
  renderTotalProductCount(appState);
  renderBonusPoints(appState);
  renderStockMessage(state);
  renderCartProductList(state);
};

위의 renderCartProductList처럼 전역 상태를 바탕으로 화면에 ui를 다시 렌더링하는 함수를 만들었고, updateUI에 ui 렌더링 함수를 모아 실행되도록 구현했다. 어찌저찌 작성했더니 코드가 돌아가긴 했다... 휴

사실 시간이 너무 부족해서 기본 과제가 완벽히 끝나지 않은 상태에서 심화 과제로 넘어갔다. react + tsx 조합에 useReducer을 사용하니 숨이 트인 느낌이었다.🤩 리액트야 고마워!!!!!!!!!!

const StateContext = createContext<State | undefined>(undefined);
const DispatchContext = createContext<React.Dispatch<Action> | undefined>(undefined);

export const GlobalProvider = ({ children }: { children: React.ReactNode }) => {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <StateContext.Provider value={state}>
      <DispatchContext.Provider value={dispatch}>{children}</DispatchContext.Provider>
    </StateContext.Provider>
  );
};

useReducer을 사용하기 위해 Provider을 만들어 App을 감싸준 후에

export type State = {
  productList: Product[];
  cartList: CartProduct[];
  appState: AppState;
};

export type Action =
  | { type: 'CHANGE_QUANTITY'; productId: string; delta: number }
  | { type: 'REMOVE_FROM_CART'; productId: string }
  | { type: 'APPLY_FLASH_SALE'; productId: string }
  | { type: 'APPLY_SUGGEST_SALE'; productId: string };


export const reducer = (state: State, action: Action): State => {
  switch (action.type) {
    case 'CHANGE_QUANTITY': {
      const { productId, delta } = action;

      const product = findProductById(state.productList, productId);
      if (!product) return state;

      // 재고 부족 시
      if (delta > 0 && product.quantity <= 0) {
        alert(MESSAGE.NO_STOCK);
        return state;
      }

      let newCartList = [...state.cartList];
      let newProductList = [...state.productList];

      const productIndex = newProductList.findIndex((item) => item.id === productId);
      const cartIndex = newCartList.findIndex((item) => item.id === productId);

      // 상품 추가
      if (cartIndex === -1 && delta > 0) {
        newCartList.push({ id: productId, count: 1 });
        newProductList[productIndex] = {
          ...newProductList[productIndex],
          quantity: product.quantity - 1,
        };
      }
      // 상품 제거
      else if (cartIndex !== -1 && newCartList[cartIndex].count === 1 && delta < 0) {
        newCartList.splice(cartIndex, 1);
        newProductList[productIndex] = {
          ...newProductList[productIndex],
          quantity: product.quantity + 1,
        };
      }
      // 정상 증감
      else if (cartIndex !== -1) {
        newCartList[cartIndex] = {
          ...newCartList[cartIndex],
          count: newCartList[cartIndex].count + delta,
        };
        newProductList[productIndex] = {
          ...newProductList[productIndex],
          quantity: product.quantity - delta,
        };
      }

      const tempState = {
        cartState: newCartList,
        productState: newProductList,
      };

      const summary = calculateCartSummary(tempState);
      const bonus = calculateBonusPoint({ state: tempState, appState: summary });

      return {
        cartList: newCartList,
        productList: newProductList,
        appState: {
          ...state.appState,
          ...summary,
          ...bonus,
          lastSelectedProductId: productId,
        },
      };
    }

    // ...

    default:
      return state;
  }
};

각 액션 키에 연산 결과를 전역 상태에 맞게 반환하도록 구현해주었다. 급하게 만든 전역 상태에 맞추느라 코드가 더럽긴 하지만 기본 과제에서 사용한 함수가 그대로 쓰이긴 했다. 🫥

?: 더티코드가 어쨌든 React 위에서 돌아가고 있고 ...

KPT

Keep

포기하지 않는 자세... 솔직히 4주차 과제를 심화까지 통과한게 기적이라고 생각한다.

Problem

역시나 무턱대고 아무거나 막 시작한 부분이...

Try

4주차가 아쉬웠던 만큼 남은 2번째 챕터 과제 열심히 임하기 👊

3주차 과제는 리액트의 훅을 직접 구현해보는 거였다. 사실 메모이제이션 훅을 사용해본 경험이 많지 않기에 너무 걱정스러웠다... 일단 해

WIL

✅ useCallback / useAutoCallback

저번 주의 나: 이게 무슨 말이지...

const cachedFn = useCallback(fn, dependencies);

useCallback은 리렌더링 간에 함수 정의를 캐싱해 주는 훅이다. 이 훅은 fn 함수가 의존하는 배열인 dependencies를 넘겨 주어야 하는데, 값을 빠뜨릴 경우 너무 오래된 값을 사용하게 되거나 너무 많이 넣을 경우 과도한 리렌더링을 유발하는 문제가 생길 수 있다.

이러한 문제를 덜기 위해 의존성 배열을 넘겨주지 않아도 항상 최신값을 유지하도록 하는 훅이 바로 useAutoCallback이다!

// lib/src/hooks/useAutoCallback.ts

// 참조가 변경되지 않으면 항상 새로운 값을 참조
export const useAutoCallback = <T extends AnyFunction>(fn: T): T => {
  const ref = useRef(fn);

  const callback = useCallback((...args: Parameters<T>) => {
    return ref.current(...args);
  }, []);

  ref.current = fn;
  return callback as T;
};

callback은 의존성 배열이 비어있기 때문에 최초 한 번만 생성되고, 최신 ref의 함수를 호출한다. ref.current = fn;에서 매 렌더마다 ref의 함수가 갱신되기 때문에 고정된 callback 내부에서는 항상 최신 상태의 함수를 참조하게 된다!

이로 인해 의존성 배열을 신경쓸 필요 없이, 매 렌더링 시점의 함수 로직을 유지하면서 불필요한 함수 재생성을 방지할 수 있다. 🤩

✅ useSyncExternalStore

useSyncExternalStore이라는 훅을 사용하여 나보고 직접 훅을 만들라는데... 진짜 처음 보는 훅이었다. 이게 뭔질 알아야 사용할 수 있으니... 한번 알아보자...🤦‍♀️

const snapshot = useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot?)

이는 컴포넌트 최상위 레벨에 호출하여 외부 저장소(store)의 상태를 구독하고 읽는 훅이다.

• subscribe 외부 저장소의 변경을 구독하는 함수

• getSnapShot 현재 저장소 데이터 상태를 반환하는 함수

• getServerSnapShot 서버 사이드 렌더링(SSR) 환경에서 사용되는 데이터의 초기 상태를 반환하는 함수 (선택)

그럼 store은 또 무엇인가...

// lib/src/createStore.ts

export const createStore = <S, A = (args: { type: string; payload?: unknown }) => S>(
  reducer: (state: S, action: A) => S,
  initialState: S,
) => {
  const { subscribe, notify } = createObserver();

  let state = initialState;

  const getState = () => state;

  const dispatch = (action: A) => {
    const newState = reducer(state, action);
    if (!Object.is(newState, state)) {
      state = newState;
      notify();
    }
  };

  return { getState, dispatch, subscribe };
};

store로 전역 상태를 만들고, 변경, 구독할 수 있는 관리 시스템을 구성하는 함수이다. 상태를 변경하는 함수인 reducer과 초기 상태인 initialState를 인자로 받는다.

state는 현재 store의 상태를 저장해두는 변수이며, dispatch를 호출할 때마다 바뀐다. 그리고 subscribe는 store의 상태 변화를 감지하는 함수, getState는 현재 store의 상태를 반환한다.

이렇게 구성된 createStore 함수로 만든 store을 useSyncExternalStore와 함께 사용하면 안전하고 일관되게 전역 상태를 구독할 수 있다!

✅ useShallowSelector

개인적으로 가장 막막했던 부분이 useShallowSelector 코드였다.

// lib/src/hooks/useShallowSelector.ts

type Selector<T, S = T> = (state: T) => S;

export const useShallowSelector = <T, S = T>(selector: Selector<T, S>) => {
  const ref = useRef<S | null>(null);

  return (state: T): S => {
    const result = selector(state);

    if (ref.current && shallowEquals(ref.current, result)) {
      return ref.current;
    }

    ref.current = result;
    return result;
  };
};

위 코드는 이전 상태를 저장하고, shallowEquals를 사용하여 상태가 변경되었는지 확인하는 훅이다.

type Selector<T, S = T> = (state: T) => S;

인자로 받을 selector 함수의 타입 정의이다. T 타입의 state를 받아 S 타입의 결과를 반환한다는 뜻!!

이전 결과를 useRef를 통해 기억한 후, 현재 상태에서의 값(const result = selector(state);)과 비교하여 값을 상태를 업데이트한다.

shallowEquals 함수를 통해 얕은 비교를 진행한 후에 값이 같으면 ref의 값을 그대로 반환하고, 값이 바뀌었다면 ref를 새로운 값인 result로 업데이트해준 뒤 result를 반환한다!

// lib/src/hooks/useStore.ts

type Store<T> = ReturnType<typeof createStore<T>>;

const defaultSelector = <T, S = T>(state: T) => state as unknown as S;

export const useStore = <T, S = T>(store: Store<T>, selector: (state: T) => S = defaultSelector<T, S>) => {
  const shallowSelector = useShallowSelector(selector);

  return useSyncExternalStore(store.subscribe, () => shallowSelector(store.getState()));
};

위의 useShallowSelector 를 사용하여 store의 상태를 구독하고 가져오는 훅이다.

shallowSelector은 selector가 반환하는 값이 얕은 비교로 동일하면 이미 캐시된 값을 반환하여 불필요한 리렌더링을 방지하는 역할을 한다. 👏

// 예시)

type AppState = {
  count: number;
  user: { name: string };
};

const store = createStore<AppState>({ count: 0, user: { name: 'areumH' } });

function UserName() {
  const name = useStore(store, (state) => state.user.name);
  return <p>User: {name}</p>;
}

state.count 값이 바뀌어도 name은 state.name 값만을 비교하기 때문에 UserName은 리렌더링되지 않는다! 👍

✅ Context.Provider

e2e 테스트 중 장바구니를 추가하거나 삭제했을 때, 토스트 호출로 인하여 리렌더링이 되지 않도록 한다를 통과하기 위해선 이미 주어진 ToastProvider.tsx 코드를 수정해야 했다..!

// app/src/components/toast/ToastProvider.tsx

const ToastContext = createContext<{
  message: string;
  type: ToastType;
  show: ShowToast;
  hide: Hide;
}>({
  ...initialState,
  show: () => null,
  hide: () => null,
});

export const ToastProvider = memo(({ children }: PropsWithChildren) => {
  // 생략

  return (
    <ToastContext value={{ show: showWithHide, hide, ...state }}>
      {children}
      {visible && createPortal(<Toast />, document.body)}
    </ToastContext>
  );
});

위의 코드는 기본적으로 주어진 내가 수정해야할 ToastProvider 코드의 일부분이다.

// 예시)

import { createContext } from 'react';

const ThemeContext = createContext('light');

function App() {
  const [theme, setTheme] = useState('light');
  // ...
  return (
    <ThemeContext value={theme}>
      <Page />
    </ThemeContext>
  );
}

우선 createContext는 위와 같은 형태로 컨텍스트를 생성하고, 여러 컴포넌트 간에 데이터를 전역적으로 공유할 수 있게 해준다!

그리고 Provider를 사용해 context 값을 하위 컴포넌트에 전달한다. 그런데 이미 주어진 코드를 보면 ToastContext.Provider가 아닌 ToastContext를 사용했다..!??

// 3주차 학습 자료) 3-3. React 프로파일링 및 기본 최적화

// Provider 컴포넌트
const ThemeProvider: React.FC<PropsWithChildren> = ({ children }) => {
  const [theme, setTheme] = useState<Theme>('light');
  const toggleTheme = useCallback(() => {
    setTheme(prev => prev === 'light' ? 'dark' : 'lht');
  }, []);
  const value = useMemo(() => ({ theme, toggleTheme }), [theme, toggleTheme]);
  return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>;
};

이건 과제 시작 전 훑어봤던 학습 자료인데, 이 코드에선 ThemeContext가 아닌 ThemeContext.Provider로 감싸서 리턴해주는 걸 볼 수 있다. Provider을 붙인 것과 안 붙인 것의 차이가 궁금해져서 한번 서치해봤다.

리액트 19부터는 Context 뒤에 Provider을 붙인 것과 안 붙인 것이 기능적으로 동일하게 작동한다고 한다. 따봉리액트야 고마워..~~ 👍

✅ shx 패키지

배포를 위해 pnpm run gh-pages를 실행했더니 터미널에 'cp'은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다. 와 같은 에러가 떴다.

// app/package.json

  "scripts": {
    "build": "vite build && cp ./dist/index.html ./dist/404.html",
    // ...
  },

package.json의 스크립트 명령어인데, cp는 Unix 기반 환경에서의 shell 명령어이기 때문에 윈도우에서는 작동하지 않는 것이었다... 관련하여 찾아보니 Unix shell 명령어를 Node.js 스크립트에서 사용할 수 있게 해주는 유틸리티 패키지 shx 라는게 있었다! 너무 다행...

해당 패키지 설치 후, 명령어를 "build": "vite build && shx cp ./dist/index.html ./dist/404.html" 로 수정하여 페이지 배포에 성공했다. 과제와 직접적인 연관이 있는 건 아니지만 그래도 하나 더 알게 되었다..!! 😶 (cp 대신 copy로 실행하면 된다는 걸 나중에 알았다......)

KPT

Keep

학습 자료를 적극 활용하자...

Problem

테스트를 통과했다고 코드를 방치하지 말자...

Try

겁먹지 말자... (다음 과제 너무 겁남)

2주차 과제는 1주차와 같이 프레임워크 없이 spa 페이지 구현하기지만, 더 자세하게는 가상 돔과 diff 알고리즘을 사용하여 이벤트 관리를 최적화하고, 불필요한 렌더링을 줄이는 것이었다.

실제 DOM의 복사본 - 변경된 것만 실제의 DOM에 반영하여 불필요한 렌더링을 줄임 과제 시작 직전, 내가 가상 돔에 대해 알고 있는 그대로 쓴 문장 하나이다. 기본 지식이라곤 이 한 문장이 전부였기 때문에 이번 과제는 또 어떻게 헤쳐나가야 할지 너무 막막했다.. 하지만 걱정과 달리 1주차 과제보다 훨씬 재밌게 느껴졌다. 저번주 과제는... 백틱에 둘러싸인 html 코드가 너무 보기가 싫었다...🥹 나가

우선 이번 회고에서는 과제를 하면서 막혔던 부분을 크게 3가지 정도 작성해보려 한다.

1. normalizeVNode() ?

createVNode나 createElement, updateElement와 같은 함수는 함수명만 봐도 어떤 역할인지 대강 알 수 있었는데, normalizeVNode는 정확히 어떤 역할의 함수인지 감이 잡히지 않았다. VNode를 정규화하는 건 어떤 과정일까..

renderElement 함수는 인자로 받은 vNode를 normalizeVNode 함수를 사용해 정규화하고, 그 반환값을 createElement 함수를 사용하여 요소로 만든다. 즉, VNode를 렌더링 가능한 일관된 형태로 변환해주는 것이다. createElement가 정제된 vNode를 사용해 요소를 만들 수 있도록 도움을 주는 함수이다!

추가로 normalizeVNode 함수의 테스트에는 null, undefined, boolean 값은 빈 문자열로 변환되어야 한다. 와 Falsy 값 (null, undefined, false)은 자식 노드에서 제거되어야 한다.가 있는데, 처음에 이 둘의 차이를 정확히 이해하지 못했다.

• null, undefined, boolean 값은 빈 문자열로 변환 : 함수의 인자로 null, undefined, boolean 값이 들어왔을 때 함수의 결과 값이 빈 문자열 (ex. normalizeVNode(null) => "" )

  if (typeof vNode === "boolean" || vNode === null || vNode === undefined) {
  vNode = "";
  }

• Falsy 값 (null, undefined, false)은 자식 노드에서 제거 : 인자의 타입이 객체이면서, 그 자식 노드가 Falsy 값일 때 아예 그 값이 제거된 객체를 반환 (ex. <div>{null}</div> => <div></div>를 위한 과정)

  if (typeof vNode === "object") {
  const children = vNode.children ?? [];
  const normalizedChildren = children
    .map(normalizeVNode)
    .filter((child) => child !== "" && child !== null && child !== undefined && typeof child !== "boolean");
  
  vNode = {
    ...vNode,
    children: normalizedChildren,
  };
  }

2. updateAttribute() ?

위의 함수는 createElement 함수에서 새 노드에 속성을 세팅할 때, updateElement 함수에서 이전 노드와 새 노드를 비교하여 속성을 업데이트할 때 사용하는 함수이다.

// src/lib/updateElement.js

// props 업데이트 및 추가
Object.entries(originNewProps).forEach(([attr, value]) => {
  if (attr === "className") {
    target.setAttribute("class", value);
  } else if (typeof value === "boolean") {
    value && target.setAttribute(attr, ""); // ⚠️
  } else if (attr.startsWith("on")) {
    const eventType = attr.slice(2).toLowerCase();
    const oldHandler = originOldProps[attr];

    if (oldHandler) {
      // 이벤트를 제거하지 않으면 누적됨
      removeEvent(target, eventType, oldHandler);
    }
    addEvent(target, eventType, value);
  } else {
    target.setAttribute(attr, value);
  }
});

위의 코드는 내가 처음 작성했던 코드이고, 문제가 됐던 부분은 value가 boolean 타입일 때의 처리였다. createElement와 같은 코드로 작성하면 정상 작동할 줄 알았는데, boolean type props가 property로 직접 업데이트되어야 한다.의 checked, disabled, selected 테스트를 모두 실패했다.

내가 쓴 코드에는 두 가지 문제가 있는데, 첫번째는 value가 false일 때 아무 처리도 하지 않는다는 것이고, 두번째는 이미 attr가 존재할 때 직접적으로 업데이트를 해주지 않는다는 것이다.

else if (typeof value === "boolean") {
  if (attr in target) {
    // target에 attr가 존재하는지 확인
    target[attr] = value; // 있으면 직접 업데이트
    if (!value) {
      // attr가 존재하는데 값이 false
      // 해당 attr 삭제
      target.removeAttribute(attr);
    }
  } else {
    // attr가 존재하지 않음
    // true이면 빈 문자열로 추가, false이면 제거
    value ? target.setAttribute(attr, "") : target.removeAttribute(attr);
  }
}

위와 같이 직접적으로 값을 업데이트하게 수정하여 테스트를 통과했다! 지금 보니까 target[attr] = value;만 작성해도 될 것 같은 느낌..

3. 이벤트 위임 문제 (이벤트 버블링)

함수 작동 테스트인 basic.test와 advanced.test를 모두 통과하고, e2e 테스트를 시작하기 전에 페이지를 열고 기본 동작들을 확인해보니 제일 기본적인 페이지 라우트가 동작하지 않았다. (테스트 다 통과했는데 대체 왜)

// src/components/ProductCard.jsx

<div className="cursor-pointer product-info mb-3" onClick={handleClick}>
  <h3 className="text-sm font-medium text-gray-900 line-clamp-2 mb-1">{title}</h3>
  <p className="text-xs text-gray-500 mb-2">{brand}</p>
  <p className="text-lg font-bold text-gray-900">{price.toLocaleString()}원</p>
</div>

위 코드는 ProductCard 컴포넌트의 일부분인데, div 범위에는 포함되지만 h3, p 태그의 범위는 아닌 아주 애매한 부분을 클릭해야만 클릭 이벤트가 작동했다... 이딴 현상 처음봤다.

이는 setupEventListeners 함수에서의 문제였다.

// src/lib/eventManager.js (setupEventListeners())

const handleEvent = (event) => {
  const target = event.target;
  if (!handlerMap.has(target)) return;

  const handler = handlerMap.get(target);
  if (handler) handler(event);
};

내가 처음 작성했던 setupEventListeners 함수 코드의 일부분이다. 이 코드는 클릭한 요소에 등록되어있는 이벤트를 동작시키기 때문에, 부모 요소에 등록된 이벤트가 동작하지 않는다.

const handleEvent = (event) => {
  let target = event.target;

  // 클릭된 요소와 이벤트가 연결된 요소가 다름
  while (target && target !== event.currentTarget) {
    if (handlerMap.has(target)) {
      // 등록된 이벤트 함수
      const handler = handlerMap.get(target);
      // 실행시킨 후 종료
      if (handler) handler(event);
      break;
    }
    // 부모 요소로 올라가며 반복
    target = target.parentElement;
  }
};

바로 부모 요소를 event.currentTarget으로 확인하며 이벤트를 연결해주는 코드가 빠져있었기 때문이었다. 현재 클릭된 요소와 이벤트가 연결된 요소가 다를 경우에 부모 요소를 하나씩 검사하면서 이벤트 함수가 있으면 해당 이벤트를 실행하도록 코드를 수정하여 테스트에 통과했다. 💪

WIL

✅ DIFF 알고리즘

diff 알고리즘은 두 개의 데이터를 비교해서 어떤 부분이 다른지, 어떤 부분이 변경됐는지를 찾아내는 알고리즘이다. 처음 diff 알고리즘 테스트를 통과해야 한다는 말을 듣고 추가로 엄청난 어려운 과제가 남아있는 줄 알았는데 그냥 내가 구현한 모든 코드 자체가 diff 알고리즘이었다..😅💦

// src/lib/updateElement.js

const newChildren = newNode.children ?? [];
const oldChildren = oldNode.children ?? [];

// 공통 길이까지 자식 요소를 비교하며 요소 업데이트
for (let i = 0; i < Math.min(newChildren.length, oldChildren.length); i++) {
  updateElement(target, newChildren[i], oldChildren[i], i);
}

// newChildren가 더 많으면 추가
for (let i = oldChildren.length; i < newChildren.length; i++) {
  target.appendChild(createElement(newChildren[i]));
}

// oldChildren가 더 많으면 역순으로 삭제
for (let i = oldChildren.length - 1; i >= newChildren.length; i--) {
  const child = target.childNodes[i];
  if (child) target.removeChild(child);
}

자식 노드끼리 비교하며 재귀 업데이트를 하는 부분이 조금 헷갈렸었다.

우선 현재 자식 노드와 이전 자식 노드의 공통 길이를 Math.min으로 계산한 뒤에 순서대로 updateElement 함수를 통해 업데이트해주었다. 그 이후 추가될 자식 노드가 있는 경우엔 appendChild로 노드를 요소로 추가해주었고, 이전 자식 노드가 더 많은 경우엔 순서(인덱스)의 영향을 받지 않기 위해 역순으로 삭제해주었다!

✅ renderElement()

처음에 과제를 하면서 테스트 코드를 보며 각 함수를 작성하면서 근데 이런 함수들이 어떻게 연결되는거지...? 라는 생각이 들었다. 각 함수의 기능도 알겠고 역할도 알겠는데 결국 이 함수들이 어느 순서를 거쳐 페이지에 컴포넌트를 보여주는 건지 감이 잡히지 않았다.

// src/lib/renderElement.js

// 최초 렌더링시에는 createElement로 DOM을 생성하고
// 이후에는 updateElement로 기존 DOM을 업데이트한다.
// 렌더링이 완료되면 container에 이벤트를 등록한다.

const prevVNode = new WeakMap();

export function renderElement(vNode, container) {
  // 이전 VNode
  const currentNode = prevVNode.get(container);
  // 새로운 VNode를 정규화
  const normalizedVNode = normalizeVNode(vNode);

  if (!currentNode) {
    // 최초 렌더링 시 DOM 생성
    const element = createElement(normalizedVNode);
    container.appendChild(element);
  } else {
    // 기존 DOM 업데이트
    updateElement(container, normalizedVNode, currentNode);
  }

  // 렌더링한 VNode 저장 후 이벤트 위임
  prevVNode.set(container, normalizedVNode);
  setupEventListeners(container);
}

1. 먼저 최초 렌더링 시 createElement를 통해 정규화된 vNode를 DOM으로 변환하여 container에 넣음
2. 그 이후엔 이전 vNode와 현재의 vNode를 비교하여 diff 알고리즘을 통해 변경된 부분만 업데이트
3. 렌더링된 vNode는 이후 업데이트의 기준이 되어야 하기 때문에 저장하고, 이벤트 위임을 등록

친절한 주석 덕분에 위의 순서 그대로 구현할 수 있었다👍

KPT

Keep

이번 과제는 시작하기 전 학습 자료를 정독하는 시간을 가졌다. 테스트 코드도 미리 보면서 어떤 기능을 구현해야 하는지 알고 시작하니 저번 주보다 훨씬 수월하게 진행된 느낌이었다...

Problem

테스트를 통과해서 코드가 지저분해보이는데도 그냥 넘어간 부분이 몇 있다. (updateElement나 setupEventListener 함수 부분) 테스트 통과한건 좋지만, 시간이 남으면 리팩토링 미루지 말고 꼭 해보기.

Try

정확히 모르겠는 개념은 질문하기, 다른 팀원의 코드도 살펴보기!! 저번 주부터 지금까지 계속 모든 걸 너무 나 혼자 하는 것 같다. 물론 개인 과제라 혼자 해야 하지만 부트캠프 내에서 할 수 있는 일을 안하고 있는 느낌..? 훨씬 어려워보이는 3주차 과제부턴 꼭 질문 많이하기.. 😶

회고 작성 전...

대학 졸업 후... 혼자 오픈 api를 사용하며 프로젝트를 하다 도저히 어떻게 취업 준비를 해야할 지 막막함을 느껴 부트캠프를 알아보게 되었고, 어쩌다보니 항해 플러스 프론트엔드 6기에 참여하게 되었다. 능력자들 사이에서 잘 섞여나갈 수 있을 지 걱정이 되었지만... 아무것도 안하고 있을 바엔 뭐라도 하자는 마음으로 신청했다. 살짝 후회될 지도

매주 개인 과제가 진행되고, 챕터 별로 회고를 작성해보려고 했으나 WIL (Weekly I Learned)을 작성한 후 제출하는 것까지가 과제의 마무리이기 때문에 급하게 1주차 회고를 작성해본다. 👊

1-1. 프레임워크 없이 SPA 만들기

1주차 과제는 라이브러리의 도움 없이 복잡한 spa 페이지 구현하기였다.

라우터와 전역 상태 관리가 이번 과제의 중점이었다고 생각하는데, 전역 상태라고는 redux 라이브러리를 사용하여 로그인 토큰을 관리해본 것이 전부였기 때문에 처음부터 너무 막막하게 느껴졌다. 처음에 순수 자바스크립트로 전역 상태를 관리하는 방법에 대해 서치해보는 데에 시간을 많이 쓴 것 같다.

WIL

✅ Observer Pattern

export function createStore(initialState) {
  let state = { ...initialState };
  const listeners = new Set();

  function subscribe(listener) {
    listeners.add(listener);
    listener(state);

    return () => listeners.delete(listener);
  }

  function getState() {
    return state;
  }

  function setState(newState) {
    state = { ...state, ...newState };
    listeners.forEach((listener) => listener(state));
  }

  return {
    subscribe,
    getState,
    setState,
  };
}

전역 상태 관리에 사용했던 옵저버 패턴 기반의 함수이다.

• createStore() 상태(state)와 상태 변경을 구독할 수 있는 기능을 가진 store 객체를 만들어서 반환, state 변수에 initialState를 복사하여 setState 함수로 상태를 업데이트한다.
• subscribe() 상태가 바뀔 때 실행될 콜백(listener)을 등록한다.
• getState() 현재 상태를 가져오는 함수, 외부에서 상태를 읽을 때 사용한다.
• setState() 상태를 업데이트하는 함수, state를 newState로 덮어쓰고, listeners에 등록된 모든 콜백을 실행한다.

✅ Router

사실 난 이번 과제를 하며 라우터를 따로 구현하지 않았는데, 이 부분이 가장 후회됐다. 지금 생각해보면 가장 기본적이면서도 당연한 기능인데 아무래도 어떻게 구현해야할 지 감이 안잡혔기에 구현을 안한게 아닌가 싶다.

MDN popstate popstate도 이번 과제를 하며 처음 알게 된 개념 중 하나이다.

popstate 이벤트는 사용자의 세션 기록 탐색으로 인해 현재 활성화된 기록 항목이 바뀔 때 발생하며, pushState() 메서드는 세션 기록에 새 항목을 추가하고, replaceState() 메서드는 현재 페이지의 세션 기록 항목을 업데이트한다.

export const navigate = (path) => {
  history.pushState(null, "", path);
  window.dispatchEvent(new PopStateEvent("popstate"));
};

위의 코드는 내가 뭣도 모르고 작성한 후 남용한 함수이다...

다음엔 navigate 함수 내에서 직접적으로 history를 사용하지 않고, router를 직접 생성한 후, navigate 함수 내에서는 router를 호출하는 방식으로 구현할 것 같다.

KPT

Keep

아직 없다고 본다... 첫 과제라 시간 분배도 잘 못한 것 같고, 발제와 함께 주어지는 학습 자료를 처음부터 정독하지 않았던 것이 후회됐다. 과제 양이 많아 일단 뭐라도 하자라는 생각에 아무것도 모르는 상태에서 코드를 작성한 탓에 뒤로 갈수록 코드가 엉망이 됐다.

Problem

위에서 말한 것 처럼 일단 기본적인 공부를 하고나서 틀을 잡고 시작하기! 한번 시작한건 마무리 하고 진행하기! 컴포넌트 분리 조금 하다가 갑자기 기능 건드리고.. 기능 구현하다가 갑자기 다른 테스트 코드 실행하고.. 침착하게 차근차근 구현하자..

Try

AI 활용을 덜 하자... 학습 자료를 제대로 읽지도 않고 AI에게 폭풍질문하는 내가 너무 한심하게 느껴졌었다. 그리고 막혔을 땐 질문을 하는 자세가 필요할 것 같다. 부트캠프에 참여해놓고 혼자 끙끙대고 있는 고집부렁...

그리고 이번 과제 때는 페이지에서는 실행되지만 직접 테스트 코드를 실행하면 통과하지 못하는 부분이 많았기 때문에, 2주차부터는 테스트 코드를 돌려보며 기능을 구현해야겠다고 생각했다.