메모이제이션은 도미노 같은 존재다

코치님이 말씀해주신 "메모이제이션을 한 번 적용하기 시작하면 연달아 적용해야 한다"는 말이 정말 와닿았다. React.memo를 컴포넌트에 적용하면, 그 컴포넌트로 전달되는 props들도 모두 메모이제이션해야 한다는 뜻이다.

const ParentComponent = () => {
  // 이 데이터가 변하지 않으면 재계산하지 않음
  const expensiveData = useMemo(() => {
    return heavyCalculation();
  }, [dependency]);

  // 이 함수도 매번 새로 만들어지지 않도록 메모이제이션
  const handleClick = useCallback(() => {
    doSomething();
  }, []);

  return <MemoizedChild data={expensiveData} onClick={handleClick} />;
};

처음에는 왜 이렇게 복잡하게 해야 하나 싶었는데, 직접 해보니 이해가 됐다. 하나의 컴포넌트를 최적화하려면 그와 연결된 모든 부분을 함께 고려해야 한다는 것이다.

useReducer의 숨겨진 장점

복잡한 상태 관리에서 useReducer를 사용해보니 예상치 못한 장점을 발견했다. 바로 테스트하기가 훨씬 쉽다는 점이다. reducer 함수는 순수 함수라서 입력만 주면 항상 같은 결과가 나온다. 각각의 액션에 대해서도 독립적으로 테스트할 수 있어서 디버깅할 때도 편했다.

상태가 3-4개 이상 연결되어 있을 때는 useState보다 useReducer가 훨씬 관리하기 편한 것 같다. 특히 여러 필드가 동시에 업데이트되어야 하는 경우에는 더욱 그렇다.

깨달은 점

추측하지 말고 측정하라

성능 최적화의 첫 번째 원칙은 '측정'이라는 것을 뼈저리게 느꼈다. 내 생각에 느려 보이는 부분과 실제로 느린 부분이 다를 수 있다는 걸 여러 번 경험했다.

React DevTools의 Profiler를 사용해서 실제 렌더링 시간을 측정하고, Performance API로 함수 실행 시간을 체크하면서 정확한 데이터를 바탕으로 최적화 방향을 정할 수 있었다. "이 부분이 문제인 것 같다"가 아니라 "이 부분이 17ms 걸리므로 최적화가 필요하다"고 말할 수 있게 됐다.

Context API는 양날의 검

ScheduleContext를 만들면서 전역 상태 관리의 딜레마를 직접 체험했다. Context를 사용하면 props drilling 문제는 해결되지만, 그 Context를 사용하는 컴포넌트가 많아질수록 상태가 바뀔 때마다 더 많은 컴포넌트가 리렌더링된다.

코치님이 말씀하신 것처럼 Context API는 디자인 시스템이나 특정 컴포넌트 트리 안에서 데이터를 공유할 때 유용하다. 하지만 진짜 "전역" 상태로 사용할 때는 신중하게 생각해야 한다는 걸 깨달았다.

사용자 관점에서 생각하기

성능 최적화를 하면서 자꾸 개발자 관점에서만 생각하고 있다는 걸 깨달았다. "렌더링이 몇 ms 줄어들었다"보다는 "사용자가 버튼을 눌렀을 때 얼마나 빨리 반응하는가"가 더 중요하다.

API 호출이 실패했을 때도 "콘솔에 에러가 찍혔으니까 됐다"가 아니라 "사용자에게 어떤 메시지를 보여줄까", "다시 시도할 수 있게 해줄까"를 고민해야 한다는 걸 느꼈다.

아쉬운 점

타입스크립트를 제대로 활용하지 못했다

TypeScript를 사용했으면서도 그 장점을 충분히 살리지 못했다. Lecture 타입을 여러 파일에 중복으로 정의한다거나, 유니온 타입이나 타입 가드를 적극적으로 활용하지 못했다.

런타임에서 발생할 수 있는 오류들을 컴파일 타임에 잡을 수 있는 기회를 많이 놓쳤다는 생각이 든다. 타입 시스템을 단순히 '변수의 타입을 명시하는 것' 정도로만 생각했던 것 같다.

에러 상황을 너무 간단하게 생각했다

API 호출이 실패했을 때나 예외 상황이 발생했을 때, 개발자 입장에서만 생각했다. 콘솔에 에러 로그만 남기고 끝내는 게 아니라, 사용자에게 의미 있는 피드백을 주거나 복구할 수 있는 방법을 제시했어야 한다.

"네트워크 오류가 발생했습니다"보다는 "잠시 후 다시 시도해주세요" 같은 구체적이고 행동 가능한 메시지를 보여줬으면 더 좋았을 것 같다.

다음 목표

접근성도 함께 고려하는 개발자가 되고 싶다

성능과 접근성을 모두 고려할 수 있는 개발자가 되고 싶다. 빠르기만 한 웹사이트가 아니라, 모든 사람이 편하게 사용할 수 있으면서도 빠른 웹사이트를 만들고 싶다.

팀 전체의 성능 문화를 만들어보고 싶다

나 혼자만 성능을 신경 쓰는 게 아니라, 팀 전체가 성능을 고려하며 개발할 수 있는 문화를 만들어보고 싶다. 성능 예산을 정하고, 코드 리뷰할 때도 성능 관점을 포함하고, CI/CD에서 성능 회귀를 자동으로 감지하는 시스템을 만들어보고 싶다.

이번 프로젝트는 단순히 기능을 만드는 것을 넘어서 '좋은 소프트웨어란 무엇인가'에 대해 고민해볼 수 있는 시간이었다. 빠른 것도 중요하지만, 모든 사용자가 접근할 수 있고, 안정적이며, 지속 가능한 소프트웨어를 만드는 것이 진짜 목표라는 걸 깨달았다.

아직 갈 길이 멀지만, 이런 고민을 할 수 있게 된 것만으로도 큰 성장이라고 생각한다.

[SSR, SSG, CSR 이해하기]

SSR (Server-Side Rendering)

정의: 서버에서 HTML을 미리 생성하여 클라이언트에 전달하는 렌더링 방식

특징:

• 서버에서 완전한 HTML을 생성하여 전송
• 초기 로딩 속도가 빠름 (FCP 개선)
• SEO에 유리
• 서버 부하가 높음

언제 사용하는가:

• SEO가 중요한 페이지 (블로그, 뉴스, 상품 페이지)
• 초기 로딩 속도가 중요한 경우
• 소셜 미디어 공유 시 메타데이터가 필요한 경우

구현 예시:

// packages/vanilla/server.js
app.use("*all", async (req, res) => {
  const rendered = await render(url, req.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>`,
    );
  res.status(200).set({ "Content-Type": "text/html" }).send(html);
});

SSG (Static Site Generation)

정의: 빌드 타임에 미리 정적 HTML 파일들을 생성하는 렌더링 방식

특징:

• 빌드 시점에 모든 페이지를 미리 생성
• CDN 캐싱에 최적화
• 서버 부하가 거의 없음
• 동적 데이터 업데이트가 어려움

언제 사용하는가:

• 콘텐츠가 자주 변경되지 않는 사이트 (블로그, 문서, 랜딩 페이지)
• 대량의 페이지가 필요한 경우
• 최고의 성능이 필요한 경우

구현 예시:

// packages/vanilla/static-site-generate.js
const { products } = await getProducts();
generateStaticSite("/", {});
generateStaticSite("/404", {});
for (let i = 0; i < products.length; i++) {
  generateStaticSite(`/product/${products[i].productId}`, {});
}

Hydration

정의: 서버에서 렌더링된 정적 HTML을 클라이언트에서 인터랙티브하게 만드는 과정

왜 사용하는가:

• 서버 렌더링의 SEO/성능 이점 + 클라이언트의 인터랙티브 기능 결합
• 초기 로딩 후 JavaScript가 로드되어 이벤트 핸들러 등록
• 사용자 경험 향상

효과:

• 초기 로딩 속도 개선: 서버에서 완성된 HTML을 받아 즉시 표시
• SEO 최적화: 검색 엔진이 완전한 HTML을 크롤링 가능
• 사용자 경험 향상: 로딩 후 즉시 인터랙션 가능
• 메타데이터 지원: 소셜 공유 시 올바른 미리보기 표시

구현 예시:

// 서버에서 초기 데이터 주입
window.__INITIAL_DATA__ = ${JSON.stringify(rendered.initialData || {})};

// 클라이언트에서 상태 복원
if (window.__INITIAL_DATA__) {
  productStore.setState(window.__INITIAL_DATA__);
}

React SSR/SSG 직접 구현해보며 느낀 점들

Next.js 없이 React SSR/SSG를 처음부터 만들어보는 프로젝트를 진행했다. 처음에는 "그냥 renderToString 쓰면 끝이겠지?"라고 생각했는데, 막상 구현해보니 생각보다 복잡하고 고려할 것들이 너무 많았다. 이번 회고를 통해 내가 배운 것들과 아직 부족한 부분들을 정리해보려고 한다.

TMI) 처음에 어떻게 구현해보지?? 했을 때 지훈님이 SSR 구현은 PHP 랑 똑같다고 보면 된다구 하셨다. SSG도 첨에 겁먹었는데, 해보니 너무 별거 없었다. (오히려 더 쉬웠음!)

🤔 처음 마주친 문제들

서버에 window가 없다!

가장 기본적인 실수였는데, 클라이언트에서 잘 되던 코드를 서버에서 실행하니까 window is not defined 에러가 계속 났다. 당연히 서버에는 브라우저가 없으니까 window 객체가 없는건데, 이거에 대한 분기처리를 계속 넣어줬다.

// 이런 식으로 환경을 체크해야 했다
if (typeof window !== 'undefined') {
  // 브라우저에서만 실행되는 코드
  window.addEventListener('scroll', handleScroll);
} else {
  // 서버에서만 실행되는 코드
  console.log('서버에서 렌더링 중...');
}

나는 이 경험을 통해 Universal JavaScript라는게 단순히 같은 코드를 공유하는 게 아니라, 환경에 따라 다르게 동작해야 한다는 걸 깨달았다.

📚 새롭게 배운 개념들

ssrLoadModule을 왜 사용하는가?

ssrLoadModule은 Vite가 제공하는 편리한 기능으로, 서버에서 클라이언트용 코드를 실행할 수 있게 해주는 변환 과정을 자동화해준다. 없으면 SSR 구현이 훨씬 복잡해진다.

// 이렇게 하면 안 된다.
import { render } from './src/main-server.js'; // ❌ 에러 발생

if (!prod) {
  // 개발 환경: Vite가 실시간으로 변환
  render = (await vite.ssrLoadModule("/src/main-server.js")).render;
} else {
  // 프로덕션 환경: 미리 빌드된 파일 사용
  render = (await import("./dist/react-ssr/main-server.js")).render;
}

// packages/react/server.js에서
const { mswServer } = await vite.ssrLoadModule("./src/mocks/node.ts");
const render = (await vite.ssrLoadModule("/src/main-server.js")).render;

SSR과 SSG의 명확한 차이점

이론적으로는 알고 있었지만, 직접 구현해보니 차이가 확실히 느껴졌다.

SSR (Server-Side Rendering): 사용자가 페이지를 요청할 때마다 서버에서 HTML을 만든다. 실시간 데이터를 반영할 수 있지만, 매번 서버에서 계산해야 해서 느리고 서버에 부담이 된다.

SSG (Static Site Generation): 빌드할 때 미리 모든 HTML을 만들어둔다.

// static-site-generate.js에서 구현한 SSG
const { products } = await getProducts();
generateStaticSite("/", {});
generateStaticSite("/404", {});

// 모든 상품 페이지를 빌드 시점에 미리 생성
for (let i = 0; i < products.length; i++) {
  generateStaticSite(`/product/${products[i].productId}`, {});
}

나는 이 코드를 작성하면서 SSG의 강력함을 느꼈다. 상품이 1000개든 10000개든 빌드만 한 번 하면 CDN에서 초고속으로 서빙할 수 있으니까.

하지만 단점도 명확했다. 상품 정보가 바뀌면 전체를 다시 빌드해야 한다는 점이었다. 나는 이때 언제 SSR을 쓰고 언제 SSG를 써야 하는지 감이 잡혔다.

데이터 하이드레이션(Hydration)이 왜 필요한가?

처음에는 하이드레이션이 뭔지 몰랐다. 서버에서 HTML을 만들었으니 그걸로 끝 아닌가? 라고 생각했다.

그런데 문제가 있었다. 서버에서 만든 HTML은 "정적인 문서"일 뿐이다. 버튼을 클릭해도 반응이 없고, 상태 변화도 없다. React의 인터랙티브한 기능들이 전혀 동작하지 않더라.

그래서 하이드레이션이 필요했다. 서버에서 렌더링한 HTML에 JavaScript를 "주입"해서 살아있는 React 앱으로 만드는 과정이었다.

// 서버에서 데이터를 클라이언트로 전달
window.__INITIAL_DATA__ = ${JSON.stringify(rendered.initialData || {})};

나는 이 과정에서 가장 중요한 것이 서버와 클라이언트의 상태를 정확히 일치시키는 것이라는 걸 배웠다. 조금이라도 다르면 React가 "어? 이거 뭔가 다른데?"라고 생각해서 전체 DOM을 다시 그리더라.

이때 FOUC(Flash of Unstyled Content) 라는 용어도 알게 되었다. 페이지가 로드될 때 스타일이 깜빡이는 현상인데, 하이드레이션을 제대로 하지 않으면 이런 문제가 생긴다.

🏗️ 아키텍처 설계하면서 배운 것들

하이브리드 라우팅의 필요성

처음에는 "모든 페이지를 SSR로 하면 되겠지"라고 생각했다. 하지만 실제로는 그렇지 않았다.

• 메인 페이지: 자주 변하니까 SSR
• 상품 페이지: 잘 안 변하니까 SSG
• 관리자 페이지: 인증이 필요하니까 CSR

나는 페이지의 특성에 따라 렌더링 방식을 다르게 선택해야 한다는 걸 깨달았다.

라우터 아키텍처의 진화

프로젝트를 진행하면서 라우터 구조를 여러 번 리팩토링했다.

처음에는 클라이언트용 라우터만 있었는데, SSR을 구현하면서 서버용 라우터가 따로 필요하다는 걸 알게 되었다. 서버에서는 브라우저의 History API를 사용할 수 없으니까.

그래서 serverRouter.js를 따로 만들었다. 202줄이나 되는 긴 코드였는데, 서버 환경에서의 라우팅 로직이 생각보다 복잡하더라.

// 서버와 클라이언트에서 다른 라우터 로직
if (typeof window === 'undefined') {
  // 서버용 라우터 사용
  router = new ServerRouter(routes);
} else {
  // 클라이언트용 라우터 사용  
  router = new ClientRouter(routes);
}

나는 이 과정에서 Universal Router 패턴의 중요성을 배웠다. 가능한 한 같은 로직을 공유하되, 환경별로 다른 부분은 깔끔하게 분리하는 것이 핵심이었다.

😅 힘들었던 부분들

React renderToString의 한계

가장 당황스러웠던 부분이었다. renderToString이 동기 함수라는 점 때문에 컴포넌트 안에서 비동기 데이터를 가져올 수 없었다.

// 이런 코드는 동작하지 않는다
function ProductPage() {
  const [product, setProduct] = useState(null);

  useEffect(() => {
    // renderToString에서는 useEffect가 실행되지 않음!
    fetchProduct().then(setProduct);
  }, []);

  return <div>{product?.name}</div>;
}

그래서 서버에서 미리 데이터를 준비한 후 컴포넌트에 props로 전달하는 방식을 사용해야 했다.

// 서버에서 미리 데이터 준비
const data = await fetchProductData();

// props로 전달
const html = renderToString(
  <ProductProvider productStore={createProductStore(data)}>
    <App />
  </ProductProvider>
);

나는 이때 Next.js의 getServerSideProps나 getStaticProps가 왜 필요한지 완벽하게 이해했다.

Hydration 에러와의 전쟁

서버에서 렌더링한 HTML과 클라이언트에서 렌더링한 결과가 조금만 달라도 React가 화를 내더라.

특히 이런 코드가 문제였다:

// 서버와 클라이언트에서 다른 결과
function CurrentTime() {
  const [time, setTime] = useState(new Date().toString());
  return <div>{time}</div>;
}

서버에서 렌더링할 때의 시간과 클라이언트에서 하이드레이션할 때의 시간이 달라서 에러가 났다.

해결책은 조건부 렌더링이었다:

// 클라이언트에서만 시간 표시
function CurrentTime() {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    setMounted(true);
  }, []);

  if (!mounted) return <div>Loading...</div>;

  return <div>{new Date().toString()}</div>;
}

나는 이 경험을 통해 하이드레이션의 엄격함을 깨달았다. 서버와 클라이언트의 결과가 정확히 일치해야 한다는 것이다.

🚀 성능 최적화에서 느낀 점들

빌드 시간 최적화

빌드 시간 최적화 상품이 많아질수록 SSG 빌드 시간이 기하급수적으로 늘어났다. 처음에는 이런 식으로 순차 처리를 했다:

// Before: 순차 처리 (엄청 느림)
await generateStaticSite("/404.html");
await generateStaticSite("/");

const { getProducts } = await vite.ssrLoadModule("./src/api/productApi.ts");
const { products } = await getProducts();

// 상품 하나씩 순차적으로 처리
for (const product of products) {
  await generateStaticSite(`/product/${product.productId}/`);
}

상품이 100개면 100번의 순차 작업이니까 정말 오래 걸렸다. 한 페이지 생성에 0.5초씩 걸린다면 100개는 50초나 걸리는 거였다. 그래서 병렬 처리로 바꿨다:

// After: 병렬 처리 (훨씬 빠름)
await generateStaticSite("/404.html");
await generateStaticSite("/");

const { getProducts } = await vite.ssrLoadModule("./src/api/productApi.ts");
const { products } = await getProducts();

// 모든 상품 페이지를 동시에 생성
await Promise.all(
  products.map(async ({ productId }) => 
    await generateStaticSite(`/product/${productId}/`)
  )
);

나는 이 과정에서 성능 최적화는 trade-off의 연속이라는 걸 배웠다.

🎬 마무리하며

Next.js나 다른 프레임워크를 사용하면 이런 복잡함들을 숨겨준다. 하지만 직접 구현해보니 왜 그런 기능들이 필요한지 몸소 체험할 수 있었다.

특히 이런 것들을 깨달았다:

• 환경별 분기 처리가 Universal JavaScript의 핵심이다
• 서버와 클라이언트의 상태 동기화가 생각보다 까다롭다
• 성능 최적화는 측정 가능한 지표로 검증해야 한다

이번 경험을 통해 나는 프레임워크의 편의성에만 의존하지 않고, 내부 동작 원리를 이해하는 개발자가 되고 싶다는 생각이 들었다.

앞으로는 이번에 배운 내용을 바탕으로 회사 프로젝트에서 더 나은 성능 최적화를 해보고 싶다. 그리고 언젠가는 나만의 작은 프레임워크도 만들어보고 싶다는 욕심이 생겼다. 🚀

TMI) 항상 나를 포기하지 않고 도와주는 팀원분들에게 감사하다. 8주차부터 지쳐가지고 과제를 놓을까 했었는데 8주차에는 휘린님이 직접 버그 봐주시면서 도와주셨고, 9주차에는 지훈님이 과제 시작 전 SSR 강의를 2시간 넘게 해주셨다. 덕분에 9주차에선 과제 내용을 이해 하고 내가 다른 사람들에게 다시 알려주면서 뿌듯함과 자신감이 많이 붙었다. 8주차는 지치고 힘들었다면, 9주차부터는 다시 활력이 생겨 재밌게 과제를 진행했다. (물론 CI 통과가 안되서 밤새느라 너무 힘들었다.. 빈 커밋하면 해결된다했는데... 정확한 문제점을 몰라서 나는 테스트 코드에 타임아웃을 줘서 통과를 시켰다.)

감사하게도 우수과제까지 받았다. vV

SPA(Single Page Application) 시대를 연 대표적인 방식입니다. 처음에는 빈 HTML만 내려주고, 브라우저가 큰 JS 번들을 받아와 DOM을 생성합니다.

✅ 장점: 페이지 이동이 빠르고 동적인 UX 구현에 강함 ❌ 단점: 초기 로딩 속도가 느리고 SEO에 약함

CSR 보완 기술

CSR의 한계를 보완하기 위해 등장한 기법들입니다.

Code Splitting / Tree Shaking → JS 번들을 쪼개고 불필요한 코드 제거

Pre-rendering → 특정 페이지는 HTML을 미리 만들어 SEO 보완

하지만 이 방식만으로는 SEO와 초기 로딩 문제를 완전히 해결할 수 없었습니다.

SSR (서버 사이드 렌더링)

서버에서 HTML을 만들어 보내주는 방식입니다. 첫 화면을 빠르게 보여주고 SEO에도 강점이 있습니다.

✅ 장점: 초기 로딩 빠름, SEO 최적화 가능 ❌ 단점: 페이지 이동 시 새로고침, 서버 부하 증가

SSG (정적 사이트 생성)

빌드 시점에 HTML을 미리 생성해두는 방식입니다. CDN에 올려두면 아주 빠릅니다.

✅ 장점: 속도, SEO 모두 강력 / 서버 부하 없음 ❌ 단점: 데이터가 자주 바뀌는 페이지에는 부적합

그런데 문제는…

SSR이나 SSG를 쓰면 완성된 HTML을 처음부터 내려주니까, CSR의 단점(빈 화면, SEO 문제)을 극복할 수 있습니다. 하지만 여기서 새로운 문제가 생깁니다.

HTML은 보이는데, 이벤트가 안 먹힌다?

SSR/SSG로 렌더링된 페이지는 단순히 정적인 HTML일 뿐입니다. 클릭 이벤트, 상태 관리, 동적 UI 같은 JS 로직은 아직 살아있지 않음 → 이걸 연결해주는 과정이 필요합니다.

Hydration: 왜 필요할까?

여기서 등장한 개념이 Hydration(하이드레이션)입니다.

SSR/SSG로 미리 만든 HTML을 브라우저가 받아옴

이후 JS 번들을 다운로드 → 기존 HTML에 이벤트 핸들러와 상태를 주입

이렇게 해서 화면이 정적 HTML → 동적인 SPA로 변신

즉, Hydration은 HTML과 JS를 “결합”하는 과정이라고 이해하면 쉽습니다.

✅ Hydration의 장점

• SSR/SSG의 장점(빠른 초기 로딩, SEO)을 유지

• CSR의 장점(인터랙티브 UI)도 살릴 수 있음

❌ 한계

• Hydration 과정에서 JS 번들을 전부 다시 실행하기 때문에, 규모가 커질수록 느려짐

그래서 최근에는 Partial Hydration, Streaming, Islands Architecture 같은 개선 기법들이 연구되고 있음

언제 어떤 방식을 써야 할까?

CSR → 대시보드, 내부 툴 (SEO 중요하지 않음, 사용자 상호작용 많음)

SSR → 뉴스, 쇼핑몰 (빠른 초기 로딩 + SEO 필요)

SSG → 블로그, 문서 사이트 (변경이 적고, 빠른 서비스가 핵심)

SSR/SSG + Hydration → 대부분의 현대 웹앱 (SEO + UX + 동적 UI 모두 필요)

CSR, SSR, SSG and ISR 시각화 비교

정리

CSR은 SPA 시대를 열었지만 초기 로딩과 SEO에 약했다.

이를 보완하기 위해 SSR/SSG가 등장했다.

하지만 SSR/SSG만으로는 동적인 UI가 안 되기 때문에, Hydration이 필요해졌다.

요즘은 Next.js, Nuxt.js 같은 프레임워크에서 CSR + SSR/SSG + Hydration을 조합해 상황에 맞게 쓰는 것이 일반적임

참고 사이트

렌더링 삼형제 CSR, SSR, SSG 이해하기

SSR을 사용할 수 밖에 없는 이유 (Feat. CSR과의 차이)

CSR, SSG, ISR, SSR

이번에 캘린더 애플리케이션을 구현하면서 TDD(Test-Driven Development)를 처음 제대로 경험해봤다. 그동안 테스트는 '개발이 끝난 후에 하는 것'이라고 생각했는데, 이번 과제를 통해 테스트가 단순히 버그를 찾는 도구가 아니라 설계를 개선하는 방법론이라는 것을 깨달았다.

팀과 함께한 테스트 전략 선택 과정

각자의 관점, 다른 전략들

프로젝트 시작 전, 팀원들과 함께 어떤 테스트 전략을 사용할지 논의했다. 처음에는 각자 다른 접근법을 제안했다.

• 김유현: 작은 규모의 애플리케이션이니까 단위 테스트 중심의 '테스트 피라미드' 전략
• 한아름: 사용자 시나리오 플로우가 중요하니까 통합 테스트 중심의 '테스트 트로피' 전략
• 신희원: 요구사항이 자주 변경되는 환경에서는 통합 테스트가 더 안정적이라고 생각해서 '테스트 트로피' 전략

합의 과정에서의 깨달음

토론 과정에서 흥미로웠던 점은, 같은 애플리케이션을 보면서도 각자 다른 관점으로 접근했다는 것이다. 나는 처음에 '작은 규모 = 단위 테스트'라는 단순한 공식을 생각했는데, 다른 팀원들의 의견을 들으면서 애플리케이션의 특성을 더 깊이 생각하게 되었다.

결국 테스트 트로피 전략으로 합의했는데, 그 이유는:

1. 사용자 중심적 사고: 캘린더 앱은 복잡한 알고리즘보다는 '일정 생성→수정→삭제' 같은 사용자 플로우가 핵심
2. 변경에 대한 대응력: 요구사항이 자주 바뀌는 환경에서 통합 테스트가 더 안정적
3. 실제 가치 검증: 단위 테스트로는 놓칠 수 있는 컴포넌트 간 상호작용을 검증

이 합의 과정에서 배운 것은, 테스트 전략은 정답이 있는 게 아니라 프로젝트의 맥락에 따라 달라진다는 점이었다.

실제 TDD 적용 경험

Red-Green-Refactor의 실제 체험

이론으로만 알고 있던 TDD 사이클을 실제로 경험해보니, 생각보다 어려웠다. 특히 '빨간불'을 보는 것에 익숙해지는 게 쉽지 않았다.

// 먼저 실패하는 테스트부터 작성
test('종료일을 지정하지 않았을 때 반복 시작일이 10월 30일 이후이면 시작 날짜에 대한 일정 하나만 생성', () => {
  // Given: 10월 30일 이후 시작 날짜
  // When: 반복 일정 생성
  // Then: 하나의 일정만 생성되어야 함
});

처음에는 "이런 것도 테스트해야 하나?"라는 생각이 들었는데, 막상 구현하면서 이런 엣지 케이스들이 실제로 버그를 만들어낸다는 것을 깨달았다.

설계를 개선하는 테스트

가장 놀라웠던 점은 테스트가 설계를 더 좋게 만든다는 것이었다. 테스트하기 어려운 코드는 보통 결합도가 높거나 책임이 명확하지 않은 코드였다. 테스트를 먼저 작성하니까 자연스럽게 다음과 같은 질문들을 하게 되었다:

• "이 함수는 정확히 무엇을 책임져야 하는가?"
• "이 컴포넌트의 의존성을 어떻게 줄일 수 있을까?"
• "사용자 관점에서 이 기능은 어떻게 동작해야 하는가?"

기술적 도전과 해결 과정

MSW로 현실적인 테스트 환경 구축

백엔드 없이 테스트하는 방법이 처음에는 막막했다. MSW(Mock Service Worker)를 도입하면서 실제 API와 유사한 환경을 구축할 수 있었다.

// handlers.ts에서 반복 일정 API 모킹
export const handlers = [
  http.post('/api/events/repeat', ({ request }) => {
    // 실제 API 응답과 동일한 구조로 모킹
  })
];

이 과정에서 모킹의 철학에 대해 많이 고민했다. 너무 현실과 다르면 테스트의 의미가 없고, 너무 복잡하면 유지보수가 어려워지니까.

비동기 로직과 상태 변화 테스트

React의 비동기 상태 변화를 테스트하는 것이 가장 어려웠다. waitFor, act 같은 유틸리티들을 사용하면서 비동기 테스트의 어려움을 체감했다.

test('반복 생성된 일정들과 이미 존재하는 일정이 겹칠 때 경고 표시', async () => {
  // 비동기 상태 변화를 기다려야 하는 복잡함
  await waitFor(() => {
    expect(screen.getByText(/일정이 겹칩니다/)).toBeInTheDocument();
  });
});

특히 타임아웃 이슈로 몇 번 고생했는데, 이는 근본적인 성능 문제일 수도 있고 내 컴퓨터 환경의 문제일 수도 있었다. 결국 임시방편으로 timeout 값을 늘렸지만, 실무에서는 이런 식으로 해결하면 안 되겠다는 생각이 들었다.

아쉬웠던 점들 🎯

E2E 테스트 미경험의 아쉬움

이번 과제에서 가장 아쉬웠던 점은 E2E 테스트를 경험하지 못한 것이다. 단위 테스트와 통합 테스트에만 집중하다 보니, 실제 사용자가 경험하는 전체 플로우를 검증하는 E2E 테스트를 놓쳤다.

특히 캘린더 애플리케이션 같은 경우, 사용자가 "일정 생성 → 캘린더에서 확인 → 수정 → 삭제"하는 전체 여정을 테스트하는 것이 정말 중요한데, 이 부분을 놓친 게 아쉽다.

심화과제 평가에서도 이 부분이 지적되었는데, 이론적으로만 알고 있던 E2E 테스트의 중요성을 실제로 느끼게 되었다. Cypress나 Playwright 같은 도구를 사용해서 실제 브라우저 환경에서의 테스트를 경험해보지 못한 것이 정말 아쉽다.

시각적 회귀 테스트의 부재

또한 UI 컴포넌트의 시각적 변화를 감지하는 시각적 회귀 테스트도 고려하지 못했다. 캘린더 UI는 시각적 요소가 중요한데, 코드 변경으로 인한 UI 깨짐을 자동으로 감지하는 테스트가 있었다면 더 완전한 테스트 전략이 되었을 텐데.

테스트 성능 최적화

앞서 언급한 timeout 이슈도 근본적으로 해결하지 못한 아쉬움이 있다. 테스트가 느리면 개발자 경험이 나빠지고, 결국 TDD 사이클 자체가 지연되니까. 실무에서는 이런 성능 문제를 어떻게 해결하는지 더 알아보고 싶다.

실무 관점에서의 고민들

회사에서 TDD가 현실적일까?

코치님의 답변을 들으면서 현실을 알게 되었다. 대부분의 회사에서 완전한 TDD 도입은 쉽지 않다는 것, 특히 프론트엔드에서는 더욱 어렵다는 것을 알게 되었다.

하지만 그렇다고 해서 TDD를 배운 것이 의미 없다고 생각하지는 않는다. 설계를 개선하는 사고방식을 배웠고, 이는 TDD를 완전히 적용하지 않더라도 코드 품질을 높이는 데 도움이 될 것 같다.

팀원과의 협업에서 테스트

실무에서 혼자 개발하는 경우가 많은 프론트엔드지만, 테스트 코드가 있으면 코드 리뷰나 인수인계 과정에서 의도를 파악하기 쉬워진다는 점을 깨달았다. 특히 복잡한 비즈니스 로직의 경우, 테스트 코드가 일종의 명세서 역할을 한다는 것을 체감했다.

배운 것들과 앞으로의 계획

핵심 인사이트

1. TDD는 테스트 도구가 아니라 설계 방법론이다
2. 테스트 전략은 프로젝트 맥락에 따라 달라져야 한다
3. 실패하는 테스트를 보는 것에 익숙해져야 한다
4. 테스트하기 어려운 코드는 보통 설계에 문제가 있다

앞으로 더 학습하고 싶은 것들

1. E2E 테스트: Cypress, Playwright 등을 활용한 사용자 시나리오 테스트
2. 시각적 회귀 테스트: Storybook이나 Chromatic을 활용한 UI 테스트
3. 성능 테스트: 테스트 실행 시간 최적화 방법들
4. 실무 적용: 레거시 프로젝트에 점진적으로 테스트 도입하는 전략

마무리하며

첫 TDD 경험이었지만, 많은 것을 배우고 느낄 수 있었다. 특히 팀원들과 함께 테스트 전략을 논의하고 합의하는 과정에서, 혼자서는 생각하지 못했을 관점들을 배울 수 있어서 좋았다.

아직 E2E 테스트나 시각적 회귀 테스트 같은 부분들이 아쉽지만, 이것들은 앞으로의 학습 목표로 삼고 계속 공부해나가려고 한다.

무엇보다 "테스트는 개발을 더 즐겁게 만든다"는 것을 깨달았다. 안전하게 리팩토링할 수 있다는 자신감, 요구사항 변경에 대한 두려움 감소 등... 이런 것들이 개발자의 삶을 더 나아지게 만든다고 생각한다.

다음에는 E2E 테스트까지 포함한 완전한 테스트 전략을 구현해보고 싶다!

1. 테스트 환경 구성에 대한 고민과 이해

이번 과제를 진행하면서 "왜 이런 설정들이 필요한가?"라는 근본적인 질문부터 시작했다.

Mock에 대한 고민과 깨달음 처음에는 "왜 실제 함수를 쓰지 않고 가짜를 만드는거지?"라는 의문이 들었다. 하지만 실제로 사용해보니:

• toastFn: 실제 토스트를 표시하면 테스트 환경에서 UI가 복잡해지고, 정작 확인하고 싶은 건 "호출되었는지"이지 "실제 토스트가 보이는지"가 아니라는걸 깨달았다
• enqueueSnackbarFn: 함수 호출을 추적하고 기록하는 것만으로도 충분히 기능을 검증할 수 있다는 점
• notistack mock: 실제 라이브러리 의존성 없이도 테스트가 가능하다는 것이 얼마나 큰 장점인지 체감했다

Provider 사용에 대한 의문과 해답 통합 테스트에서 ChakraProvider로 컴포넌트를 감싸는 부분을 보고 "이게 정말 의미가 있을까?"라고 의문을 가졌다. 하지만 실제로는:

• ThemeProvider, SnackbarProvider, CssBaseline 등이 단순한 스타일링이 아니라 컴포넌트의 핵심 기능 작동에 필요하다는걸 알게 되었다
• Provider 없이는 렌더링은 되지만 기능이 제대로 작동하지 않을 수 있다는 점이 충격적이었다
• "겉보기에는 괜찮아 보이지만 실제로는 망가진 상태"를 방지하는 중요한 역할을 한다는걸 깨달았다

handlersUtils 활용에서 느낀 효율성 각 이벤트 생성/수정/삭제를 위한 mock API 설정을 보면서 "이미 짜여져 있는 함수를 가져다 쓰는거였지만 미디움에서 편리하게 사용했다"고 생각했다. 실제 API 호출은 너무 많은 리소스를 사용한다고 생각이 들었고, 가짜 서버와 데이터를 만들어 사용하는 것이 얼마나 효율적인지 몸소 체험할 수 있었다.

시간 고정에 대한 이해 vi.setSystemTime을 보고 "왜 이 시간을 설정해주는 걸까?"라는 궁금증에서 시작했다. 고정된 시간 설정이 날짜/시간 의존 로직의 예측 가능성과 재현성을 보장한다는걸 이해하고 나니, 테스트의 안정성이 얼마나 중요한지 깨달았다.

2. 비동기 테스트에서 겪은 시행착오와 이해

act와 waitFor를 처음 접했을 때 "언제 뭘 써야 하는거지?"라는 혼란이 컸다.

초기 고민들

• "act와 waitFor이 둘 다 비동기 처리를 하는 것 같은데 차이점이 뭐지?"
• "언제는 act를 쓰고 언제는 waitFor을 써야 하는거야?"
• "타이머 관련 테스트에서 실제로 시간이 흘러야 하나, 아니면 즉시 처리할 수 있나?"

실제 경험을 통한 깨달음

• act는 동기/비동기 모두 사용 가능하며, React의 상태 업데이트를 즉시 처리한다는걸 체험했다
• waitFor은 항상 비동기이며, 실제 시간이 흘러야 하는 상황에서 사용한다는걸 이해했다

// 동기 act - "이거 정말 즉시 처리되나?" 의심하며 사용했는데 실제로 즉시 처리됨!
act(() => {
   vi.advanceTimersByTime(1000);
});

// waitFor - "정말 2초를 기다려야 하나?" 걱정했는데 필요한 경우였음
await waitFor(() => {
    expect(screen.getByText('1초 지남')).toBeInTheDocument();
}, { timeout: 2000 });

3. 데이터 로딩 방식에 대한 고민과 선택

두 가지 데이터 로딩 방식을 보고 "어떤게 더 좋은 방법일까?"라는 고민이 들었다.

1번 방법에 대한 의문

await act(async () => {
    await new Promise((resolve) => setTimeout(resolve, 0));
});

"이게 왜 작동하는거지? setTimeout을 0으로 설정하는게 무슨 의미가 있을까?"라는 의문에서 시작했다.

2번 방법의 명확성

await act(async () => {
    await result.current.fetchEvents();
});

"이게 더 직관적이고 명확한 것 같은데, 2번 방법을 택한게 맞을까?"라고 고민했다.

코치님 피드백을 통한 이해

• 1번은 "다음 이벤트 루프로 넘어가며 pending Promise들을 기다리는" 해킹 기법이라는걸 알게 되었다
• 2번이 의도가 더 명확하고 일반적으로 선호된다는 확신을 얻을 수 있었다
• "뭔가 비동기적으로 실행될 것 같은데 정확히 언제 실행될지 모를 때" 1번을 사용한다는 기준을 이해했다

깨달은 점

1. AI에 대한 의존도 조절의 중요성

몇 시간 동안 MUI Icons 모킹 문제로 삽질했던 경험이 가장 큰 깨달음을 줬다. AI에게 계속 에러를 고쳐달라고 했지만, 답이 수렴되지 않고 오히려 더 복잡해지기만 했다.

결국 직접 구글링해서 찾은 해결책은 단순했다:

// 기존
import { LocationCity } from "@mui/icons-material";
// 수정
import LocationCity from "@mui/icons-material/LocationCity";

코치님의 팁처럼, AI를 사용했을 때 답이 수렴되지 않는다면 AI가 방향성을 제대로 짚지 못한 징조로 받아들이고, 직접 문제 해결에 나서야 한다는 것을 체감했다.

2. 의미있는 테스트의 기준

코치님의 피드백을 통해 테스트 코드 작성의 기준을 명확히 할 수 있었다:

1. 기획 관점에서의 요구사항: 기획서에 해당하는 요구사항이 있다면 뻔해 보여도 테스트해야 함
2. 실제 발생 가능성: 사용자로 인해 실제로 발생할 수 있는 상황인가?
3. 사용자 영향도: 이 테스트가 실패하면 사용자에게 문제가 되는가?

경계값 테스트의 경우, 달력 Form을 사용한다면 큰 문제가 없을 수 있지만, 코드로 입력하는 엑셀 같은 환경이라면 반드시 검증해야 한다는 관점이 인상적이었다.

3. 통합 테스트의 재미

처음엔 막막했던 통합 테스트가 오히려 단위 테스트보다 재미있었다. 상태를 기반으로 기획서와 코딩을 맞춰가는 과정에서 전체적인 플로우를 이해할 수 있었고, 실제 사용자 관점에서 기능을 검증하는 느낌이 들었다.

4. Git 명령어의 위험성

git reset --hard HEAD~1 명령어로 커밋하지 않은 파일들이 모두 날아간 경험... 정말 뼈아픈 교훈이었다. 스테이징에 올려두지 않은 것이 화근이었지만, 덕분에 git 명령어의 위험성과 중요성을 체감할 수 있었다.

아쉬운 점과 다음 목표

아쉬운 점

1. Hard 레벨 도전 실패: Git 실수로 인해 Hard 레벨을 완주하지 못한 것이 아쉽다
2. AI 의존도: 초기에 AI에만 의존하려 했던 점, 직접 문제 해결을 시도하지 않았던 점
3. 기본기 부족: MUI Import 방식 같은 기본적인 부분에서 막혔던 점

다음 목표

1. 문제 해결 프로세스 개선: AI 사용 시 답이 수렴되지 않으면 즉시 직접 조사로 전환
2. Git 사용 숙련도 향상: 위험한 명령어 사용 전 충분한 확인, 정기적인 커밋 습관화
3. 테스트 설계 능력 향상: 요구사항 기반의 의미있는 테스트 케이스 설계 능력 기르기
4. Hard 레벨 재도전: 다음 기회에는 반드시 Hard 레벨까지 완주하기

마무리

이번 과제는 단순히 테스트 코드 작성법을 배우는 것을 넘어서, 문제 해결 접근법, 도구 사용의 균형, 그리고 실패로부터 배우는 것의 중요성을 깨닫게 해준 의미있는 경험이었다.

"내가 웃는게 웃는게 아니야.. ㅠ"라고 해주신 코치님의 따뜻한 피드백처럼, 실패와 삽질의 경험도 결국 성장의 밑거름이 된다는 것을 느꼈다. 테스트 코드에 대한 심리적 장벽은 확실히 허물어졌고, 다음 과제에서는 더 체계적이고 효율적인 접근을 해보고 싶다.

과제의 핵심취지

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

• 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
• Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
• FSD(Feature-Sliced Design)에 대한 이해
• FSD를 통한 관심사의 분리에 대한 이해
• 단일책임과 역할이란 무엇인가?
• 관심사를 하나만 가지고 있는가?
• 어디에 무엇을 넣어야 하는가?
• TanstackQuery의 사용법에 대한 이해
• TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
• 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

배운 내용 정리 📚

FSD 아키텍쳐

FSD가 생각보다 어렵지 않았다

처음 FSD 폴더 구조를 봤을 때는 정말 복잡해 보였다.entities, features, widgets 같은 용어들이 생소했고, 파일을 이렇게까지 세분화해서 나눠야 하나 싶었다. 하지만 실제로 적용해보니 생각이 완전히 바뀌었다. 가장 인상 깊었던 건 "엔티티는 정보, 피처는 행동"이라는 개념이었다. 댓글 기능을 예로 들면:

// entities/comment/model/types.ts - 댓글이 "무엇"인지 정의
export interface Comment {
  id: number
  content: string
  author: string
}

// features/comment/add-comment/hooks.ts - 댓글을 "어떻게" 추가하는지
export const useAddComment = () => {
  return useMutation({
    mutationFn: (commentData) => CommentAPI.createComment(commentData)
  })
}

// widgets/comment-list/CommentList.tsx - 댓글을 "어떻게" 보여줄지
export const CommentList = () => {
  return <div>{/* 댓글 목록 UI */}</div>
}

이제는 댓글 관련 수정이 필요하면 features/comment 폴더만 들여다보면 된다.

Tanstack Query

TanStack Query의 간결함에 놀랐다 useState와 useEffect로 API 상태를 관리하던 기존 방식이 얼마나 번거로웠는지 새삼 깨달았다.

// 기존에 이렇게 복잡하게 작성하던 걸...
const [posts, setPosts] = useState([])
const [loading, setLoading] = useState(false)
const [error, setError] = useState(null)

useEffect(() => {
  setLoading(true)
  fetch('/api/posts')
    .then(res => res.json())
    .then(data => setPosts(data))
    .catch(err => setError(err))
    .finally(() => setLoading(false))
}, [])

// 이렇게 간단하게!
const { data: posts, isLoading, error } = useQuery({
  queryKey: ['posts'],
  queryFn: () => fetch('/api/posts').then(res => res.json())
})

특히 낙관적 업데이트가 진짜 게임 체인저였다. 사용자가 댓글을 작성하면 서버 응답을 기다리지 않고 바로 화면에 표시되니까 체감 속도가 확실히 빨라졌다. queryClient.setQueryData로 캐시를 직접 조작할 수 있다는 점도 신기했다.

Zustand 상태 관리

Zustand로 다이얼로그 지옥에서 탈출 이번 과제에서 가장 공들인 부분이 바로 다이얼로그 상태 관리였다. 처음에는 각 컴포넌트마다 useState로 다이얼로그를 열고 닫았는데, 이게 진짜 문제였다. 게시물 추가 다이얼로그와 댓글 추가 다이얼로그가 동시에 열리거나, 하나를 닫았는데 다른 곳에서는 여전히 열려있다고 인식하는 상황이 발생했다.

// 해결책: 모든 다이얼로그 상태를 중앙에서 관리
export const useDialogStore = create<DialogState>((set) => ({
  showAddDialog: false,
  showEditDialog: false,
  showAddCommentDialog: false,
  // ... 6개 다이얼로그 상태

  openAddDialog: () => set({ showAddDialog: true }),
  closeAddDialog: () => set({ showAddDialog: false }),

  // 핵심: 모든 다이얼로그를 한 번에 닫는 함수
  closeAllDialogs: () => set({
    showAddDialog: false,
    showEditDialog: false,
    showAddCommentDialog: false,
    // ... 모든 상태 초기화
  }),
}))

이제 다이얼로그 관련 버그는 거의 사라졌고, 상태 동기화 문제도 해결됐다.

깨달은 점 💡

1. 구조가 복잡해 보이는 이유는 따로 있었다 피드백을 받고 나서 깨달은 건, 내가 FSD 구조를 완전히 지키지 못했기 때문에 더 복잡해 보였다는 것이다. 예를 들어, features에서 entities의 API를 직접 호출하고 있었다:

   // 내가 작성한 코드
   import CommentAPI from "../../../entities/comment/api/CommentAPI"
   export const useDeleteCommentFeature = () => {
   const deleteCommentMutation = useMutation({
    mutationFn: (id: number) => CommentAPI.deleteComment(id),
   })
   }

   이렇게 하니까 HTTP 클라이언트를 바꾸려면 entities의 API 파일뿐만 아니라 features에서 직접 호출하는 파일들도 모두 수정해야 한다. 피드백에 따르면 현재 구조에서는 약 8-15개 파일을 추가로 수정해야 하지만, 올바른 구조라면 entities의 API 파일 6-8개만 수정하면 된다고 한다. 올바른 방식은 이런 거였다:

   // entities에서 훅을 제공하고
   export const useDeleteComment = () => useMutation({ 
   mutationFn: (id) => CommentAPI.deleteComment(id) 
   })
   

// features에서는 그 훅을 사용 import { useDeleteComment } from "../../../entities/comment" export const useDeleteCommentFeature = () => { const deleteCommentMutation = useDeleteComment() // 비즈니스 로직만 여기서 처리 }

2. Props Drilling 완전 제거가 생각보다 어렵다
Zustand로 다이얼로그 상태는 깔끔하게 분리했지만, 댓글 데이터와 관련된 함수들은 여전히 props로 전달하는 부분이 남아있다. 어떤 상태는 전역으로 관리하고, 어떤 상태는 로컬로 두어야 하는지에 대한 명확한 기준이 부족했던 것 같다.
특히 댓글 입력 폼이나 선택된 댓글 같은 단기간의 UI 상태까지 전역으로 관리할 필요는 없다는 걸 배웠다. 이런 건 컴포넌트 내부에서 `useState`로 관리하는 게 더 적절하다.

3. 일관성이 정말 중요하다
피드백에서 지적받은 건 내 코드에 일관성이 부족하다는 점이었다. 쿼리 키를 어떤 곳에서는 상수로 쓰고, 어떤 곳에서는 문자열 리터럴로 직접 써버렸다. 훅 네이밍도 제각각이었고, 파일 위치 규칙도 혼재되어 있었다.
이런 작은 불일치들이 쌓이면 나중에 팀으로 작업할 때 큰 문제가 될 수 있겠다는 생각이 들었다. 특히 새로운 팀원이 합류했을 때 혼란스러워할 것 같다.

## 아쉬운 점과 다음 목표 🎯
### 아쉬운 점

1. 계층 경계를 제대로 지키지 못했다
가장 아쉬운 부분은 FSD의 핵심 규칙인 계층 경계를 완전히 지키지 못했다는 것이다. features에서 entities의 내부 구현에 직접 접근하는 코드들이 여러 곳에 있었다. 이 때문에 변경의 영향 범위가 넓어지고, 모듈 간의 결합도가 높아졌다.

2. 쿼리 키 관리가 엉성했다
TanStack Query를 사용하면서 쿼리 키 관리를 체계적으로 하지 못했다. 어떤 곳에서는 QUERY_KEYS.POSTS를 쓰고, 어떤 곳에서는 ['comments', postId]처럼 직접 배열을 작성했다. 피드백에서 제안받은 중앙화된 쿼리 키 팩토리가 정말 필요하겠다는 생각이 든다:
```typescript
export const queryKeys = {
  posts: () => ['posts'] as const,
  postsList: (params) => [...queryKeys.posts(), params] as const,
  comments: (postId) => ['comments', postId] as const,
}

3. 낙관적 업데이트 구현이 불완전했다 현재는 queryClient.setQueryData로 캐시를 직접 조작하는 방식을 사용하고 있는데, 실패했을 때 롤백 처리가 제대로 되지 않는다. onMutate/onError/onSettled 패턴을 사용해서 더 안전하게 구현했어야 했다.

4. 다이얼로그 상태 구조의 확장성 부족 6개의 다이얼로그를 각각 boolean 변수로 관리하는 방식은 새로운 다이얼로그를 추가할 때마다 store를 수정해야 한다. 피드백에서 제안받은 키/맵 기반 구조가 훨씬 확장성이 좋아 보인다:

   // 현재 방식
   interface DialogState { 
   showAddDialog: boolean
   showEditDialog: boolean
   // 새 다이얼로그마다 여기에 추가해야 함
   }
   

// 개선된 방식 interface DialogState { dialogs: Record<string, boolean> open: (key: string) => void close: (key: string) => void }

```

다음 목표

즉시 해결하고 싶은 것들

바렐(index.ts) 파일 도입: entities, features 폴더마다 public API를 명확하게 노출하는 index.ts 파일을 만들어야겠다. 이렇게 하면 내부 구현과 외부 인터페이스를 확실하게 분리할 수 있다. 쿼리 키 중앙화: shared/api/queryKeys.ts 파일을 만들어서 모든 쿼리 키를 한 곳에서 관리하고 싶다. 이렇게 하면 키 변경이나 캐시 무효화 로직을 훨씬 쉽게 관리할 수 있을 것 같다. features → entities 의존성 정리: 현재 features에서 직접 API를 호출하는 부분들을 모두 찾아서 entities의 public 훅을 사용하도록 수정하겠다.

한 달 안에 달성하고 싶은 것들

낙관적 업데이트 패턴 표준화: onMutate/onError/onSettled 패턴으로 모든 mutation을 표준화하고, 실패 시 안전한 롤백이 가능하도록 구현하고 싶다. ESLint 규칙으로 아키텍처 보호: import/no-restricted-paths 같은 규칙을 도입해서 계층 위반을 CI에서 자동으로 잡아낼 수 있게 하고 싶다. 현대적인 React 패턴 도입: Suspense와 ErrorBoundary를 도입해서 선언적인 로딩/에러 처리를 구현해보고 싶다.

장기적으로 도전해보고 싶은 것들 앞으로 더 큰 프로젝트를 할 때는 모노레포 구조로 도메인별 패키지를 분리하는 것도 고려해보고 싶다. 그리고 완전한 Props Drilling 제거를 위한 상태 분리 정책도 명확하게 정립하고 싶다. 무엇보다 테스트를 제대로 도입해보고 싶다. 이번에는 기능 구현에만 집중했는데, 다음에는 테스트하기 쉬운 구조로 설계하는 것부터 시작해야겠다.

마무리하며

이번 과제를 통해 단순히 기능이 돌아가는 코드를 넘어서, 유지보수하기 쉽고 확장 가능한 구조에 대해 깊이 생각해볼 수 있었다. 특히 피드백을 통해 내가 놓치고 있던 부분들을 구체적으로 알 수 있어서 정말 값진 시간이었다. 아직 부족한 점이 많지만, 이제는 "왜 이런 구조가 좋은가?"에 대한 나름의 기준이 생겼다. 변경의 영향 범위를 최소화하고, 일관된 패턴으로 개발 생산성을 높이는 것. 이게 바로 좋은 아키텍처의 핵심이라는 걸 배웠다. 앞으로도 이런 구조적 사고를 계속 발전시켜서, 혼자서만 잘 돌아가는 코드가 아니라 팀과 함께 성장할 수 있는 코드를 작성하는 개발자가 되고 싶다.

과제의 핵심취지

• React의 hook 이해하기
• 함수형 프로그래밍에 대한 이해
• 액션과 순수함수의 분리

배운 내용 정리 📚

이번 주차는 React Hook에 대해 깊이 있게 학습하고, 함수형 프로그래밍의 핵심 개념들을 실제 코드로 구현해보는 시간이었다. 특히 상태 관리와 컴포넌트 설계에서 많은 고민과 배움이 있었다.

주요 학습 포인트

상태 추상화와 Hook 설계

• Jotai atoms에서 커스텀 hooks로의 전환
• 컴포넌트와 훅의 계층 분리
• 재사용 가능한 훅 인터페이스 설계

도메인 기반 모듈화

• Product, Cart, Coupon 도메인별 폴더 구조
• 높은 응집도, 낮은 결합도를 위한 컴포넌트 분리
• UI와 도메인 로직의 책임 분리

전역 상태 관리

• localStorage와 React State 동기화 패턴 구현
• Notification API 설계와 상태 관리
• 테스트 격리를 위한 Jotai Provider 활용

어려웠던 점 🤯

1. 커스텀 훅 상태 공유 실수

Props drilling을 피하려다가 큰 함정에 빠졌다. 하위 컴포넌트에서 같은 커스텀 훅을 다시 호출하면 상태가 공유될 거라 생각했는데, 완전히 독립적인 상태가 생성되었다.

function ParentComponent() {
  const { addNotification } = useNotification();

  addNotification('성공');
  return (
    <div>
      <ChildComponent />  {/* props로 전달하지 않음 */}
    </div>
  );
}

function ChildComponent() {
  const { addNotification } = useNotification(); // 같은 훅을 다시 선언
  // 하지만 Parent의 상태와는 완전히 분리됨!
}

이 실수를 2번이나 반복하면서 깨달았다: 커스텀 훅은 로직 재사용을 위한 도구이지, 상태를 공유하는 것이 아니다. 각 호출마다 새로운 상태 인스턴스가 생성된다는 React Hook의 기본 원칙을 체감했다.

2. localStorage와 React State 동기화 딜레마

두 개의 독립적인 상태 저장소를 동기화하는 과정에서 많은 고민이 있었다:

• React state: 컴포넌트 생명주기에 따라 생성/소멸
• localStorage: 브라우저 세션을 넘어 영구 지속

처음 접근한 방식은 useEffect를 통한 단방향 동기화였다:

const [value, setValue] = useState(() => {
  const saved = localStorage.getItem(key);
  return saved ? JSON.parse(saved) : initialValue;
});

useEffect(() => {
  localStorage.setItem(key, JSON.stringify(value));
}, [value, key]);

하지만 이 방법은 상태 업데이트 시점에서 일관성 문제가 발생했다. 팀원들과의 코드 공유를 통해 Single Source of Truth 패턴을 적용한 해결책을 찾을 수 있었다:

const setValue = (value: T | ((val: T) => T)) => {
  setStoredValue((prev) => {
    const newValue =
      typeof value === "function" ? (value as (val: T) => T)(prev) : value;

    if (
      newValue === undefined ||
      (Array.isArray(newValue) && newValue.length === 0)
    ) {
      localStorage.removeItem(key);
    } else {
      localStorage.setItem(key, JSON.stringify(newValue));
    }

    return newValue;
  });
};

핵심 차이점은 실행 시점이었다:

• 이전: React state 업데이트 → 렌더링 → useEffect 실행
• 개선: localStorage 저장 → React state 업데이트 (동기)

깨달은 점 💡

학습의 본질 되돌아보기

4주차에 바이브코딩을 하면서 큰 현타가 왔었다. AI에게 의존하면서 테스트 통과만을 목표로 하다 보니, "내가 뭘 하고 있는 거지?"라는 생각이 들었다. 교육의 진짜 목적은 스스로 배워가는 것인데, 언제부터 테스트 통과가 최우선이 되었을까?

5주차에서는 다시 초심으로 돌아가 AI 도움을 최소화하고, 팀원들과의 코드 리뷰와 페어코딩을 통해 하나씩 부딪혀가며 배웠다. 처음엔 내 질문이 상대방의 시간을 빼앗는다고 생각했지만, 오히려 서로 설명하고 토론하면서 win-win 관계가 형성되었다.

컴포넌트 설계에 대한 고민

이번 과제에서 가장 신경 쓴 부분은 컴포넌트 분리였다:

• UI와 Hooks의 분리
• 도메인별 컴포넌트 구조 (Product, Cart, Coupon)
• 낮은 결합도, 높은 응집도를 지키기 위한 설계

"더 세세하게 나누는 게 좋을까? (ProductImg, ProductDiscount, ProductPrice 등) 아니면 큼직하게 나누는 게 좋을까? (ProductCard < ProductList)"라는 고민이 계속 있었다. 결국 재사용성과 유지보수성을 기준으로 판단해야 한다는 걸 배웠다.

Hook의 진정한 의미

커스텀 훅을 직접 설계하면서 깨달은 것:

• 훅은 단순한 로직 재사용 도구가 아니라, 상태와 부수효과를 캡슐화하는 강력한 추상화 도구
• 훅의 public API 설계가 전체 애플리케이션의 결합도를 좌우함
• 전역 상태의 '소유자'를 명확히 하는 것의 중요성

아쉬운 점과 다음 목표 🎯

원래 목표는 몰랐던 부분을 천천히 학습하며 과제를 진행하는 것이었다. 그러나 진도가 늦어지면서 제출일이 다가올수록 테스트 통과에만 집중하게 되었다.

다른 사람의 PR을 참고하거나 AI를 활용하면서 스스로 고민할 기회가 줄어든 점이 아쉬웠다.

더 많은 시간을 투자하여 온전히 내 힘으로 과제를 진행했다면 더 깊은 배움과 성장이 있었을 것이다. 클린코드 과제에서는 특히 이런 아쉬움이 크게 남았다.

다음에는 반드시 스스로 생각하며 내 힘으로만 과제를 완성하는 것을 목표로 한다. 그렇게 해야 진정으로 내 것이 될 수 있다.

이번 주는 비록 완벽하지 않았지만, 팀원들과 함께 학습하는 즐거움을 다시 느낄 수 있었다. 다음 주차에서도 더 많은 페어코딩과 협업을 통해 성장하고 싶다!

클린코드 원칙과 리액트 컴포넌트 리팩토링

회사에서 업무를 하면서 항상 내가 짠 코드에 대해 생각을 했다. 더 가독성 있게 짤 수는 없을까? 성능을 더 높일 수 있는 코드를 작성할 수 있지 않을까? 내 코드에 대해 리뷰를 받을 수 있는 환경도 아니었고, 더 좋은 코드가 있을 거 같은데... 생각하면서도 AI한테 물어봐도 만족할 수 있는 답을 받아보지 못했다.

그래서 클린코드와 리팩토링에 대한 주제가 나에게 너무 큰 기대가 되었다. 하지만 결과는 큰 실망만 한 채로 끝났다... 왜냐고? 완전히 바이브코딩으로 진행했기 때문에.

바이브코딩으로 진행해서 문제였다라기 보다는, 과제 테스트 통과를 위해 바이브코딩을 하면서 배워나간점이 없다고 생각이 들어 큰 실망을 했다. 테스트 통과에 급급해 기능이 제대로 동작하는지, AI가 짜준 코드가 정말 맞는건지, 가독성이 정말로 좋은지 확인도 안한채 넘어갔기 때문이다.

이런 실패(?) 과정 덕분에 나는 다음주차 과제를 AI에 너무 의존하지 말고, 도움만 받는 정도로 사용해야겠다. 라는 생각을 가지게 되었고 "앞으로 더 잘할 수 있다" 라고 생각하며 스스로를 토닥였다. (더 잘하면 되지!)

배운 내용 정리 📚

클린코드 핵심 원칙

🧐 리팩토링의 목적

리팩토링의 목적 = 유지보수!

1. 이슈해결을 하기 위해서 코드를 이해하고 투자하는 시간을 줄이기 위해서 하는것
2. 코드를 수정했을때 문제가 없음을 보장하는 시간을 줄이기 위해서 하는것

처음에는 작동하는 코드를 굳이 바꿀 필요가 있을까 의문이 들었다. 하지만 몇 번의 수정과 기능 추가를 거치면서, ‘작동하는 코드’와 ‘좋은 코드’는 다르다는 사실을 깨달았다.

회사에서 MVC 패턴을 이용한 프로젝트를 진행한 적이 있었는데, 기존 구조가 MVC 원칙에 맞지 않아 전반적인 리팩토링을 진행했다. Model, View, Controller의 역할을 다시 정의하고 각 기능을 해당 계층에 맞게 분리했다. Model에는 데이터 구조와 비즈니스 로직을, View에는 화면 렌더링과 UI 표현을, Controller에는 두 계층을 연결하는 역할만 맡겨 불필요하게 로직이 섞이지 않도록 했다.

이렇게 구조를 재정리하니 각 부분이 자신의 역할만 수행하도록 단순화되어 코드 이해도가 높아지고, 재사용성이 향상되었다. 특히, 중복된 기능을 공통 모듈로 묶어 여러 Controller나 View에서 재활용할 수 있도록 하면서 기능 변경 시 수정 범위를 최소화하고 버그 발생 가능성도 줄일 수 있었다.

위 같은 경험을 통해 리팩토링은 단순한 코드 정리가 아니라, 유지보수와 확장을 고려한 구조적 개선 작업이라는 점을 깊이 느꼈다. 앞으로는 코드를 처음 작성할 때부터 ‘미래의 나’와 ‘이 코드를 읽을 다른 사람’을 생각하며, 이해하기 쉬운 구조를 잡는 습관을 들이고자 한다.

ESLint

ESLint는 JavaScript 코드의 품질을 향상시키는 강력한 정적 코드 분석 도구 코드 스타일 문제, 잠재적 버그, 안티 패턴 등을 식별하고 수정할 수 있다.

Prettier

Prettier는 코드 포맷터로, 일관된 코드 스타일을 자동으로 적용 들여쓰기, 줄 바꿈, 공백 등의 스타일 문제를 자동으로 해결해준다.

어려웠던 점 🤯

AI를 잘 사용하는 법... *AI한테 어떻게 잘 질문해야 내가 원하는 것만 쏙쏙 뽑아낼 수 있을까? * 바이브코딩을 하면서도 정말 어려웠다. 기존의 코드는 최대한 많이 건들지 않으며 필요한 부분만 쏙쏙 바꾸고 싶었는데, AI가 맘대로 UI도 바꿔버리고 기능 테스트시 버그도 만들고...

이번에 심지어 Cursor 도 결제했는데 (다행히 무료체험이 있어서 공짜였음) 최대한 작은 단계별로 진행하면서 나를 이해시켜줘. 라고 질문을 하니까 토큰은 최대한으로 잡아먹으면서 스텝별로 나를 이해시켜주는게 아니라 AI 혼자 진행하고 있었다. (답답쓰) -> 결국 토큰 5시간만에 다 써버린;;;

깨달은 점 💡

다른 사람들은 AI를 어떻게 사용하고 있을까?에 대해 팀 회의를 하였다.

정리 된 내용!

1. 롤플레잉 (구원자 스타일) a. 내가 굉장히 위험한 상황에 처해있다는 것을 어필한다…. 뒤에서 누가 총을 겨누고 있다던지…. 뭐 그런거 다들 알잖슴~~
2. git diff 커밋A 커밋B 명령어 때린 뒤에 변경점에 대해서 문서화 > PR 또는 기업 과제 작성 시 활용 (비서 스타일)
3. 코딩스타일을 지침서에 넣는다 (가이드 스타일)
4. 구현한 코드 프로세스 도식화 (가이드 스타일)
5. AI에게 공부한 내용을 먹이고 간단한 퀴즈를 내달라고 합니다. (선생님 스타일)

다른 사람들 내용에서 또 좋다고 생각한 방법

1. 요구 사항 상세하게 설명하기 a. AI가 알아듣기 좋은 형태로 요청하기 (커서룰, mdc파일, MCP 활용 등)
2. 한 번에 큰 단위로 요청하지 말고 나누어 요청하기
3. 목적에 따라 모델 바꿔가면서 요청하기
4. GPT와 제미나이 병행 사용, 같은 질문 반복 비교하며 "AI끼리 싸움 붙임"
5. 하기 전에 AI 로 구현사항 정리 + 컨벤션 작성 > 그후에 입력

다들 다양하게 AI를 활용하고 있었기에 배울 게 많았다. 이후 나도 롤플레잉 적용하면서 진행하구 있다. 나는 리액트 초보고(인턴이고) 너는 리액트 고수(시니어)야. ~~에 대해서 자세하고 쉽게 설명해주고 나를 이해시켜줘.

일단, 나는 타입스크립트를 써본 적이 없어서 문법 자체들이 너무 생소했다. 그리고 리액트 훅에 대해서도 useRef, useState 등 만 써봤지.. 메모이제이션 관련해서 왜 사용하고, 어떻게 동작하는지도 몰랐다. . . . . 회고 마저 쓸게요,,,, 일단 링크만 올리기...

useSyncExternalStore는 React 18에서 도입된 외부 저장소(state)의 변화를 React 컴포넌트에서 정확하고 일관성 있게 구독하기 위해 만든 훅이다.

핵심 목적

외부 상태와 React 렌더링 사이의 시점을 정확히 동기화해서, 버그 없이 일관된 UI를 만들 수 있도록 해주기 위함.

Redux, Zustand, 전역 event 기반 store 등에서 사용할 수 있다.

🧨 왜 useSyncExternalStore가 필요했는가?

⚠️ 기존 방식의 문제: useEffect + useState

기존에는 외부 상태(store)를 React 컴포넌트에서 사용하려면 이런 방식으로 처리했다.

const [value, setValue] = useState(store.getValue());

useEffect(() => {
  const unsubscribe = store.subscribe(() => {
    setValue(store.getValue());
  });
  return unsubscribe;
}, []);

겉보기에는 잘 동작하는 것 같지만... React 18에서는 렌더 도중 외부 상태가 바뀔 경우, 렌더링이 취소되거나 다시 시작될 수 있는데, 이 과정에서 useEffect는 렌더 이후 동작하기 때문에 중간 상태 오류가 발생할 수 있다.

😱 실제 문제점들

1. 렌더 시점과 구독 시점의 불일치

useEffect는 렌더링 이후에 실행됨.

하지만 외부 상태는 그 전에 바뀌었을 수도 있음.

그럼 render → subscribe → value 변경 순이 되면, 초기 렌더에서 잘못된 값이 표시될 수 있음.

즉, 렌더링 시점에 스냅샷을 잡지 못해서 UI가 이전 값을 보여주거나 깜빡임이 생김.

2. Concurrent Mode에서의 부작용

React 18 이후, Concurrent Rendering이 활성화됨에 따라 다음 문제가 중요해졌다.

Concurrent Rendering이란 ? React가 여러 개의 UI 작업을 병렬로 처리하고, 사용자 경험에 더 좋은 작업을 먼저 렌더링할 수 있도록 만든 렌더링 방식

• React는 여러 번의 렌더를 미리 예약하고 나중에 커밋함.

• 그런데 그 사이에 외부 상태가 바뀌면, 예상과 다른 값이 렌더에 반영될 수 있음.

즉, 렌더링 도중 외부 값이 바뀌었는지 React가 알 수 없어 버그가 생김.

🛠️ 그래서 만들어진 useSyncExternalStore 이러한 문제를 해결하기 위해 useSyncExternalStore를 도입했다.

📌 정리하면

useSyncExternalStore는 외부 상태를 React 렌더링 흐름 안에서 일관되고 안전하게 사용하는 유일한 방법이다. 이는 React가 Concurrent Rendering과 SSR(Server Side Rendering)을 완전히 지원하게 된 중요한 기반 중 하나이다.

🔍 기본 사용법

const state = useSyncExternalStore(subscribe, getSnapshot);

📘 파라미터 설명

🚀 useSyncExternalStore 사용법: 4가지 실전 패턴 정리

다음은 실무에서 자주 사용되는 4가지 유형의 사용법입니다. ** React 공식 문서 참고

1️⃣ 외부 Store 구독 (예: Redux, Zustand 등)

✅ 목적 외부 상태 관리 라이브러리(Redux, Zustand 등)의 변경 사항을 안전하게 구독하기.

🧩 사용법

import { useSyncExternalStore } from 'react';
import { todosStore } from './todoStore.js';

function TodosApp() {
  const todos = useSyncExternalStore(todosStore.subscribe, todosStore.getSnapshot);
  // ...
}

store에 있는 데이터의 snapshot을 반환합니다. 두 개의 함수를 인수로 전달해야 합니다.

subscribe 함수는 store에 구독하고 구독을 취소하는 함수를 반환해야 합니다. getSnapshot 함수 함수는 store에서 데이터의 스냅샷을 읽어야 합니다.

💡snapshot : 지금 이 순간의 외부 상태값

React는 이 함수를 사용해 컴포넌트를 store에 구독한 상태로 유지하고 변경 사항이 있을 때 리렌더링합니다.

2️⃣ 브라우저 API 구독 (예: window, location 등)

✅ 목적 window, matchMedia, geolocation 등의 브라우저 상태를 추적하고 반응형 UI 구성

🧩 사용법

import { useSyncExternalStore } from 'react';

function ChatIndicator() {
  const isOnline = useSyncExternalStore(subscribe, getSnapshot);
  // ...
}

getSnapshot 함수를 구현하려면 브라우저 API에서 현재 값을 읽습니다.

function getSnapshot() {
  return navigator.onLine;
}

subscribe 함수를 구현

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

3️⃣ Custom Hook으로 로직 추출하기

✅ 목적 공통 로직을 재사용 가능한 Hook으로 분리해서 여러 컴포넌트에서 활용하기

🧩 사용법 이 custom useOnlineStatus Hook은 네트워크가 온라인 상태인지 여부를 추적

useOnlineStatus.js

import { useSyncExternalStore } from 'react';

export function useOnlineStatus() {
  const isOnline = useSyncExternalStore(subscribe, getSnapshot);
  return isOnline;
}

function getSnapshot() {
  return navigator.onLine;
}

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

app.js

import { useOnlineStatus } from './useOnlineStatus.js';

function StatusBar() {
  const isOnline = useOnlineStatus();
  return <h1>{isOnline ? '✅ Online' : '❌ Disconnected'}</h1>;
}

function SaveButton() {
  const isOnline = useOnlineStatus();

  function handleSaveClick() {
    console.log('✅ Progress saved');
  }

  return (
    <button disabled={!isOnline} onClick={handleSaveClick}>
      {isOnline ? 'Save progress' : 'Reconnecting...'}
    </button>
  );
}

export default function App() {
  return (
    <>
      <SaveButton />
      <StatusBar />
    </>
  );
}

📌 이처럼 커스텀 훅으로 추출하면 테스트와 유지보수가 쉬워진다.

4️⃣ 서버 렌더링(SSR) 지원 추가

✅ 목적 서버 렌더링 시 window, document 접근 오류 방지 및 초기 값 제공

🌐 예: useWindowWidth에 SSR 대응 추가

function useWindowWidth() {
  const subscribe = (callback: () => void) => {
    window.addEventListener("resize", callback);
    return () => window.removeEventListener("resize", callback);
  };

  const getSnapshot = () => window.innerWidth;

  const getServerSnapshot = () => 1024; // SSR 시 기본값

  return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);
}

☑️ getServerSnapshot은 선택적 인자지만, SSR 환경에서는 필수! 💡 이 패턴은 Next.js, Remix 등 SSR 프레임워크를 사용할 때 매우 유용!

📖 실제 연동 예제 모음

✅ 1. Zustand와 useSyncExternalStore 연동하기

Zustand는 자체적으로 subscribe, getState 메서드를 제공하기 때문에 쉽게 연동 가능하다.

// 📁 store.ts
import { createStore } from 'zustand/vanilla';

export const counterStore = createStore(() => ({
  count: 0,
  increase: () => counterStore.setState((s) => ({ count: s.count + 1 })),
}));

// 📁 useCounter.ts
import { useSyncExternalStore } from "react";
import { counterStore } from "./store";

export function useCounter() {
  return useSyncExternalStore(
    counterStore.subscribe,
    counterStore.getState
  );
}

// 📁 Counter.tsx
import { useCounter } from "./useCounter";

export default function Counter() {
  const { count, increase } = useCounter();
  return (
    <div>
      <p>🧮 Count: {count}</p>
      <button onClick={increase}>+ 증가</button>
    </div>
  );
}

🧠 zustand/vanilla는 훅을 직접 만들고 싶을 때 사용한다. React 전용 useStore 훅을 안 쓰고 useSyncExternalStore로 직접 구현하는 예제

✅ 2. Redux와 useSyncExternalStore 연동하기

Redux도 store.subscribe와 store.getState를 그대로 활용 가능하다.

// 📁 store.ts
import { legacy_createStore } from "redux";

const initialState = { count: 0 };

function reducer(state = initialState, action: any) {
  switch (action.type) {
    case "INCREMENT":
      return { count: state.count + 1 };
    default:
      return state;
  }
}

export const store = legacy_createStore(reducer);

// 📁 useReduxSelector.ts
import { useSyncExternalStore } from "react";
import { store } from "./store";

export function useReduxSelector<T>(selector: (state: any) => T): T {
  return useSyncExternalStore(
    store.subscribe,
    () => selector(store.getState())
  );
}

// 📁 Counter.tsx
import { store } from "./store";
import { useReduxSelector } from "./useReduxSelector";

export default function Counter() {
  const count = useReduxSelector((state) => state.count);

  return (
    <div>
      <p>🧮 Redux Count: {count}</p>
      <button onClick={() => store.dispatch({ type: "INCREMENT" })}>+ 증가</button>
    </div>
  );
}

📌 이 방식은 React-Redux의 useSelector를 직접 대체하거나, 고도화된 커스텀 훅으로 활용할 수 있다.

✅ 3. 브라우저 API (예: matchMedia) 구독 예제

미디어 쿼리를 반응형으로 다루고 싶을 때 활용합니다.

// 📁 useMediaQuery.ts
export function useMediaQuery(query: string): boolean {
  const subscribe = (callback: () => void) => {
    const media = window.matchMedia(query);
    media.addEventListener("change", callback);
    return () => media.removeEventListener("change", callback);
  };

  const getSnapshot = () => window.matchMedia(query).matches;
  const getServerSnapshot = () => false; // SSR 대비

  return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);
}

// 📁 Component.tsx
import { useMediaQuery } from "./useMediaQuery";

export default function ResponsiveBox() {
  const isMobile = useMediaQuery("(max-width: 768px)");

  return <div>{isMobile ? "📱 모바일 화면" : "🖥️ 데스크탑 화면"}</div>;
}

💡 기존 useEffect + useState 방식보다 훨씬 간결하고, SSR에서도 안전하게 작동한다.

✅ 4. 서버 렌더링(SSR) 대응 예제 (with Next.js)

// 📁 useWindowWidth.ts
export function useWindowWidth(): number {
  const getSnapshot = () => window.innerWidth;
  const getServerSnapshot = () => 1024; // 서버 기본값 (예: 데스크탑)

  const subscribe = (callback: () => void) => {
    window.addEventListener("resize", callback);
    return () => window.removeEventListener("resize", callback);
  };

  return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);
}

// 📁 Home.tsx (Next.js page)
import { useWindowWidth } from "./useWindowWidth";

export default function Home() {
  const width = useWindowWidth();

  return (
    <main>
      <h1>현재 창 너비: {width}px</h1>
    </main>
  );
}

✅ Next.js 같은 SSR 환경에서는 반드시 getServerSnapshot을 넣어야 window 에러 없이 렌더링된다.

📖 참고문서

React 공식 문서

https://ko.react.dev/reference/react/useSyncExternalStore#subscribing-to-a-browser-api

티어링 이슈 알아보기 & 외부 상태 관리 라이브러리 구현 예시

https://ted-projects.com/react-use-sync-external-store

useSyncExternalStore 훅 보기 전에 먼저 알면 좋은 개념들

https://velog.io/@yeonoey/useSyncExternalStore%EB%9D%BC%EB%8A%94-%ED%9B%85%EC%9D%84-%EC%95%84%EC%8B%9C%EB%82%98%EC%9A%94#usesyncexternalstore

하늘님이 작성해주신 useSyncExternalStore 포스트 인데, 설명이 이해하기 쉽게 잘 되어있다.

https://velog.io/@eveneul/React.js-useSyncExternalStore%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Zustand%EC%97%90%EC%84%9C-useSyncExternalStore%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EC%8B%9D#-zustand-%EC%A0%84%EC%B2%B4-%ED%94%8C%EB%A1%9C%EC%9A%B0

1️⃣ VirtualDOM?

Virtual DOM은 실제 DOM과 똑같은 구조를 가진 메모리 상의 가상 트리다. 주로 React, Vue 등의 프레임워크에서 사용되며, 실제 DOM을 직접 조작하는 대신 Virtual DOM을 이용해 성능을 향상시킨다.

🔍 실제 DOM과 Virtual DOM 비교

2️⃣ CreateVNode

• 평탄화(flattening) 해주는 이유 중첩된 배열을 단일 배열로 펼쳐서 다루기 쉽게 만들기 위해서

아래 코드를 보면

안에 자식 노드가 있다. map은 배열을 반환하고

<div>
   <div>hello</div>
   Array.map((name) => { <div>${name}</div> });
</div>
----
위와 같은 코드
<div>
   <div>hello</div>
   <button>name1</button>
   <button>name2</button>
</div>
---
[{ type: div , props: '', children: 'hello'}, [{.type: button, props: '', children: name1 }, { .type: button, props: '', children: name2  }]]

3️⃣ NormalizeVNode

정규화를 해주는 이유 : 객체/배열 구조 데이터를 평탄하고 효율적으로 구성하는 것

// 정규화 전 (비정규화 상태)
// company 정보가 사용자마다 중복되어 있다. 이렇게 되면 수정 시 모든 곳을 찾아서 바꿔야 한다.
const users = [
  {
    id: 1,
    name: "Alice",
    company: { id: 100, name: "OpenAI" }
  },
  {
    id: 2,
    name: "Bob",
    company: { id: 100, name: "OpenAI" }
  }
];

// 회사 정보가 한 곳에만 있어서 변경, 추적이 쉽고 실수도 줄어든다.
const users = {
  1: { id: 1, name: "Alice", companyId: 100 },
  2: { id: 2, name: "Bob", companyId: 100 }
};

const companies = {
  100: { id: 100, name: "OpenAI" }
};

4️⃣ Diffing 알고리즘

🔍 1. Diffing 알고리즘이란?

간단히 말하면:

이전 상태(Old State)와 새로운 상태(New State)를 비교해서, "무엇이 변경되었는지(diff)"를 계산하는 알고리즘이다.

UI에서는 일반적으로 Virtual DOM을 비교할 때 사용되며, React, Vue 등 대부분의 모던 프론트엔드 프레임워크에서 핵심 역할을 한다.

🔧 2. 왜 사용하는가?

✅ 문제 브라우저의 DOM 조작은 느립니다.

상태가 바뀔 때마다 전체 DOM을 다시 렌더링하면 성능 저하가 크다.

✅ 해결 방법: Diffing 바뀐 부분만 찾아서(=diff)

해당 부분만 최소한의 DOM 조작으로 업데이트함

즉, 최적화된 UI 업데이트 방식 🧠 핵심 요약 | 항목 | 내용 | |-----------------|----------------------------------------------------------------------| | 무엇인가? | 두 구조 간 차이점을 찾아내는 알고리즘 | | 왜 필요한가? | 성능 최적화를 위해 (전체 DOM 대신 변경된 부분만 업데이트) | | 어디서 쓰나? | Virtual DOM 기반 UI 라이브러리 (React, Vue 등) | | 이점은? | 빠른 렌더링, 부드러운 사용자 경험 |

5️⃣ Map , WeakMap

eventManager

• 이벤트 위임 Map, eventMap JavaScript에서 키-값 쌍을 저장하는 자료구조지만, 사용 목적과 내부 동작 방식에 큰 차이

  📊 Map vs WeakMap 차이 요약

💡 왜 WeakMap을 쓰는가? 메모리 누수 방지 (가비지 컬렉션) DOM 요소가 삭제되면 WeakMap의 키(= 요소)에 대한 참조도 사라짐 그러면 JavaScript 엔진이 해당 entry를 자동으로 메모리에서 제거함

const el = document.createElement("div");
addEvent(el, "click", handler);
document.body.removeChild(el); // el DOM에서 제거됨

만약 Map을 사용했다면 eventMap이 el을 계속 참조 → 메모리 누수 발생 하지만 WeakMap은 el이 참조되지 않으면 자동으로 해당 데이터 제거됨

참고링크 : https://devocean.sk.com/blog/techBoardDetail.do?ID=165601

1️⃣ SPA 구조 설계, 생각보다 훨씬 복잡했다

이번 과제에서는 SPA(Single Page Application) 구조를 설계하는 과정에서 많은 어려움을 겪었다. 특히 SPA의 전반적인 구조를 어떻게 구성해야 할지에 대한 감이 전혀 잡히지 않았다.

2️⃣ 라우터 구현

라우팅 시스템을 직접 구현해야 했기 때문에 라우터에 대한 개념이 부족하여 초반에 한참 헤맸다.

3️⃣ 부족한 개념들

더불어 옵저버 패턴, 컴포넌트의 생애주기, 상태 관리와 같은 프론트엔드 개발의 핵심 개념들에 대한 이해도 부족해서, 전체적인 흐름을 설계하고 구현하는 데 특히 어려움을 느꼈다.

이러한 개념들이 제대로 정립되지 않다 보니, 상태가 변경될 때 화면을 어떻게 렌더링해야 하는지, 어떤 구조로 코드를 나누고 흐름을 설계해야 하는지 명확하지 않아 어려움을 크게 느꼈다.

문제를 해결하기 위해 노력한 점

1️⃣ 처음에는 혼자 문제를 해결하기 위해 관련 개념을 찾아보았다.

하지만 개념을 이해하고 코드에 적용하려고 해도 정확한 이해가 부족했는지 제대로 활용하지 못했고, 시간이 점점 흘러갔다. 그래서 다른 사람이 작성한 코드를 찾아보고 어떻게 구현했는지 자세히 살펴본 뒤, 그 내용을 참고하여 내 코드에 적용하려고 노력했다.

2️⃣ 물음표 살인마가 되어, 다른 사람들에게 질문하기

타인의 코드가 이해되지 않을 때는 직접 코드를 작성한 사람 또는 다른 사람들에게 코드의 흐름 및 설명을 요청했고, 모르는 개념이 나오면 질문하며 개념에 대한 이해를 높이기 위해 노력했다.

문제를 어떻게 해결했는가?

1️⃣ SPA 구조 설계 : 폴더 구조만이라도 잡기

SPA 구조 설계에서 가장 먼저 폴더 구조부터 명확하게 정의하는 작업을 진행했다. UI 컴포넌트를 어떻게 효율적으로 분리할지 고민하며, 컴포넌트 기반 아키텍처 원칙에 따라 폴더와 파일을 체계적으로 나누어 전체 프로젝트의 뼈대를 구성했다. [참고문서] (https://velog.io/@teo/folder-structure#%EA%B7%B8%EB%A6%AC%EA%B3%A0-%ED%8E%98%EC%9D%B4%EC%A7%80-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8%EC%9D%98-%EB%8F%85%EB%A6%BD)

2️⃣ 라우터 구현 : URL을 직접 변경해주고, 변경된 URL에 따라 화면을 재렌더링하는 방식을 사용

옵저버 패턴 등 복잡한 상태 관리에 대한 이해가 부족해 이를 도입하지 못했고, 대신 이벤트 핸들러에서 상태가 변경될 때마다 수동으로 렌더링을 실행하는 방식으로 문제를 해결했다.

과제를 통해 알게 된 개념

1. 옵저버 패턴

옵저버 패턴(observer pattern)은 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴 여기서 주체란 객체의 상태 변화를 보고 있는 관찰자이며, 옵저버들이란 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 ‘추가 변화 사항’이 생기는 객체들을 의미한다.

🧠 주요 개념 요약 Observable: 상태를 가지고 있고, 상태 변경 시 구독자에게 알림을 보냄

Observer: 상태가 변경되면 알림을 받고 동작하는 쪽

subscribe(): 구독자 등록

notify(): 구독자들에게 알림 전송

예시 코드

// Subject (관찰 대상)
class Observable {
  constructor() {
    this.observers = []; // 구독자 리스트
    this.state = null;
  }

  // 구독자 추가
  subscribe(observer) {
    this.observers.push(observer);
  }

  // 구독자 제거
  unsubscribe(observer) {
    this.observers = this.observers.filter(obs => obs !== observer);
  }

  // 상태 변경 및 알림
  setState(newState) {
    this.state = newState;
    this.notify();
  }

  // 구독자들에게 알림 전송
  notify() {
    this.observers.forEach(observer => observer.update(this.state));
  }
}

과제에서 사용한 예시

• src/utils/createObserver.js

  export const createObserver = () => {
  const observers = new Set();
  
  const subscribe = (callback) => {
    observers.add(callback);
  };
  
  const unsubscribe = (callback) => {
    observers.delete(callback);
  };
  
  const notify = (...args) => {
    observers.forEach((callback) => callback(...args));
  };
  
  return { subscribe, unsubscribe, notify };
  };

• src/utils/createState.js

  import { createObserver } from "./createObserver.js";
  

export function createState(initialState) { let state = { ...initialState }; const observer = createObserver();

const subscribe = (callback) => { observer.subscribe(callback); return () => observer.unsubscribe(callback); };

const setState = (newState) => { const prevState = { ...state }; state = { ...state, ...newState };

observer.notify(state, prevState);

};

const getState = () => ({ ...state });

return { subscribe, setState, getState, }; }

```

목표 달성 & 과제 후 느낀 점

기존 목표 : 기본 과제 통과 (기본 기능 모두 구현하기) 변경 목표 : 기본 과제에서 최대한 많은 기능을 구현하기 (통과 여부 신경 X)

느낀점

이번 과제를 하면서 가장 크게 느낀 점은, 혼자 고민하기보다 함께 문제를 해결해 나가는 과정 속에서 많은 도움을 받을 수 있었고, 그만큼 배움도 더 깊어졌다는 것이다.

이번 과제에는 심화 과제도 있었지만, 개념이 제대로 잡히지 않았던 나는 우선 기본 과제부터 완성하자는 마음으로 시작했다. 하지만 과제를 처음 시작할 때는 막막함이 컸고, 혼자 해결해보려다 보니 약 이틀 동안 거의 진행이 되지 않았다. ‘기본 과제조차 나 혼자 끝낼 수 있을까?’ 하는 걱정이 들기도 했다.

그래도 포기하지 않고 하나씩 해결해보기로 마음먹고, 다른 사람들에게 기능 구현에 필요한 개념이나 방법을 질문하면서 차근차근 과제를 진행해 나갔다. 진행 속도는 느렸지만, 그 과정에서 단순히 문제를 해결하는 것보다도 이전에 잘 몰랐던 개념들을 이해해가며 기능을 구현하는 경험 자체가 더 중요하다는 것을 느꼈다. 무작정 구현하기보다는, 개념을 정확히 이해하고 직접 적용해보는 과정이 훨씬 의미 있었다.

과제 제출일이 다가왔을 때는 "하나라도 더 구현해보자"는 마음으로 최대한 마무리를 지었다. 비록 모든 기능을 완성하지는 못했지만, 하나의 기능을 제대로 구현하기 위해 그 동작 원리를 이해하고 직접 개발해보는 과정 자체가 큰 배움의 시간이 되었다.

다음 목표 설정

• 시간 분배를 잘 하자!
• 과제에서 필요한 개념을 선수학습하자!
• 2주차 과제는 무조건 통과를 목표로 잡기!