lyla-bae 님의 블로그

서버 vs 클라이언트 혼재된 개념 정리

lyla-bae — Fri, 3 Apr 2026 22:35:48 +0900

요 4주동안 프로젝트 현직 멘토님과 주1회 멘토링을 진행하면서 Next 관련 공부했던 내용들을 정리해보았다

기본기가 너무 부족한거같다 공부좀 하자 ^^

SSR / CSR vs 서버 컴포넌트 / 클라이언트 컴포넌트 부터 일단 헷갈림

~~SSR = 서버컴포넌트~~
~~CSR = 클라이언트컴포넌트~~

~~라고 이해하고 있었던 나....(진짜 공부 안한거 티남) 너무 부끄러웠다~~

앞에 동일하게 서버/클라이언트라고 들어가니까 개념이 혼재된듯하다

SSR / CSR 이란 → Redering 시점을 말하는것이다.

SSR: 서버에서 HTML 만들어서 보냄 (언제 그리냐)
CSR: 브라우저에서 JS로 그림

그럼

서버 컴포넌트(RSC) / 클라이언트 컴포넌트(RCC)는? → 실행되는 위치

서버컴포: 서버에서 실행됨
클라컴포: 브라우저에서 실행됨

SSR vs CSR 차이

결론적으로 말하면 사전렌더링 방식에서 차이가 드러난다

SSR

서버단에서 렌더링이 빠르게 진행됨. 때문에 FCP 시간을 단축가능한 장점이 있다.
그러나 무언가 인터렉션할수있는 상태는 아니기때문에 그상태로 JS번들 > Hydration을 기다려야하는 단점이 있다.

CSR

클라이언트단에서 렌더링이 진행된다. 빈 HTML 파일을 가장먼저 불러오고 JS번들을 기다려야한다는 단점이 있지만,
Hydration 이후에는 바로 사용자 인터렉션 가능하다는 장점

그럼 Hydration은 또 뭐고

사전렌더링 이후 인터렉션 되지않는 목마른 JS번들이 빈 HTML에게 물을 뿌려주는것과 같은..! 즉 인터렉션되게 만들어주는 과정을 말한다

~~SSR이면 바로 인터랙션 가능하다?~~
~~CSR만 인터랙션 가능하다?~~

No.... SSR도 처음엔 인터랙션 안된다. 반드시 Hydration 이후에 되는것이다

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

~~서버컴포 = 그냥 SSR용~~
~~클라컴포 = 그냥 CSR용~~

가 아니다.... 컴포넌트는 내부코드의 역할기준에 따라 나뉘게된다

그래서 언제 뭘 써야하는데

서버 컴포넌트

데이터 fetching
인증 처리
초반에 빠르게 UI 구성
JS 번들에 포함 안됨

→ 로직 + 데이터 + 초기 렌더링에 유리

클라이언트 컴포넌트

상태 관리 (useState)
이벤트 (onClick)
애니메이션

→ 사용자와 상호작용을 해야하는 인터랙션 담당

Next에서는 기본적으로 서버컴포를 쓰는것을 권장. 그래야 JS번들 용량을 줄일수 있기 때문이다

but 상호작용 필요한 페이지들은 클라컴포를 써야한다

이정도 적어두면 이제 정말 헷갈릴일은 없겠지...? ^^.....제발

스와이프 탭으로 UX까지 배우는 캐러셀 유랑기

lyla-bae — Thu, 26 Mar 2026 10:28:35 +0900

오랜만에 돌아온 블로그,, 요즘 근황은 또 다른 팀플을 하고있느라 정신이 없다

문제 해결을 해갈때마다 블로그에 꼭 회고해야지라고 마음속으로 다짐했지만 실제로 행동하기까진 쉽지 않은것같다

오늘이야말로 꼭 써야겠단 다짐으로..! 트러블슈팅을 해보자 레츠고

스와이프되는 카테고리 탭을 구현해야한다

디자인시안

이번 팀플에서 본격적으로 게시판 CRUD 개발을 맡게되었는데

이런 스와이프 되는 모양의 카테고리 탭을 만들어야 하는 상황이었다.

처음에는 이 스와이프 동작을 라이브러리 없이 직접 구현할지 고민했다.

문제가 되는 영역이 이 컴포넌트 하나뿐이었기 때문에, JS 이벤트로 가볍게 처리하는 방식도 충분히 가능해 보였다.

그래서 실제로 직접 구현을 1차 시도해봤다.

<div
  className="tab-wrap flex gap-2 overflow-x-auto mt-5 ml-6 [scrollbar-width:none] [-ms-overflow-style:none] [&::-webkit-scrollbar]:hidden"
  onWheel={(event) => {
    event.currentTarget.scrollLeft += event.deltaY;
  }}
>

스크롤 y는 숨기고 x축만 허용했고 pc에서는 가로스크롤이 보기싫어서 머리를 굴리다가
onWheel 이벤트로 마우스휠을 굴리면 옆으로 굴러가는 방식이었다.

UT결과는 불편함

하지만 유저들에게 테스트를 해보니 휠로 넘기는게 꽤 불편하다는 피드백을 받았다 ㅠ

꼭 스와이프되어야만 하는 상황이 된것이다. 어쩔수없이 라이브러리 도입을 알아보았다.

캐러셀 라이브러리를 검토하기 시작했다. 후보는 아래 3가지!

shadcn 내장 캐러셀
slick
swiper.js

이미 프로젝트에서 shadcn을 사용하고 있었기 때문에 내장 캐러셀을 그대로 쓰는 것도 고려했다.

그러던 중 shadcn 캐러셀이 Embla 기반으로 동작한다는 걸 알게 됐다

Embla 을 선택한 이유

이번 작업에서 필요한기능은 단순했다. 드래그기반 스와이프와 접근성

그렇기에 최대한 가벼우면서도 기본적인 캐러셀 기능을 하는 라이브러리가 필요했다.

npm trends 조사결과

조사해보니 shadcn이 대중화되서인지 embla가 압도적었다.

그렇지만 shadcn 캐러셀 컴포넌트를 굳이 설치해서까지는 필요없었다고 판단.

어짜피 shadcn을 썼어도 Embla 의존성은 설치했어야했기때문에

shadcn은 쓰지않고 Embla 하나만으로 구현이 충분했다

사용법은 다른라이브러리와 비슷하게 useEmblaCarousel 전용훅을 이용했고, 각 속성값을 이용해 간단하게 구현가능!

디테일한건 공식문서에서 확인~

https://www.embla-carousel.com/

Home

An API designed with flexibility and extensibility in mind.

www.embla-carousel.com

그리고 내가 선택한 탭 index를 useMemo에 저장시켜 탭을 선택한후에 자연스럽게 애니메이션되면서 활성화될수있도록

useEffect와 scrollTo를 활용했다.

그런데 또 문제발견 - touch action

코드래빗의 리뷰

PR올리고 코드리뷰 받았더니 touch action이란것을 추가하라고 한다.

그런게 있는지도 몰랐는데 알아보니 모바일에서 x 스크롤과 y스크롤 제스처가 혼용되는것을 방지하는 속성이라고 하더라

<div ref={emblaRef} className="overflow-hidden [touch-action:pan-y_pinch-zoom]">

바깥 래퍼에 테일윈드 유틸로 부랴부랴 넣어서 해결완..

완성결과

이렇게 세로로 스크롤될일도 걱정도 막고 스무스한 너낌으로 스와이프되는 탭을 만들수있었다..!

또하나 새롭게 알게된 사실...! 접근성에는 모양도 중요하다는 것!!

처음에는 “포커스가 잡히기만 하면 충분하다”고 생각했는데,

실제로는 포커스의 ‘모양’도 사용자 경험에 큰 영향을 준다는 것이었다.

버튼에 적용된 border-radius와

포커스 스타일이 어긋날 경우, 사용자가 인터랙션 대상의 범위를 직관적으로 인지하기 어려웠다.

그래서 포커스가 단순히 보이기만 하는 것이 아니라,

컴포넌트의 형태와 일관되게 인식되도록 border-radius를 함께 조정했다.

마무리

단순 라이브러리 캐러셀이라고 생각했지만 실제로는 사용성, 접근성, UX까지 챙기느라 생각보다 쉽지않았던 과정이었다

역시 직접 부딪혀보는것만 해도 배울게 정말 많다는것을 깨달은거같다. 팀플 쵝오

프로젝트 주제와 관련된 UX 논문 찾기

lyla-bae — Sat, 14 Mar 2026 10:21:25 +0900

24년 11월 10월에 진행한 스터디 주제는 UX 관련 논문 찾기였다.

프로젝트를 진행할 때 논문을 참고하는 습관을 들이면 좋은데, 각 팀의 프로젝트 주제와 관련된 논문을 찾아보시거나, UX 관련 논문을 찾아보자. 보통 논문을 볼 땐 abstract과 가장 뒤의 결론에 모든게 나와 있긴 하지만 첨부한 논문과 같이 사례 분석을 한 논문은 이론 배경에서 많은 지식을 얻을 수 있다. 논문 결과를 간단히 정리해도 좋고, 인상 깊거나 새롭게 알게 된 내용만 발췌해도 좋다.

추천 키워드: 사용자 경험 UX, User experience, 데이터 UX, UX 방법론, UI 디자인
국내 무료 논문 사이트 RISS: https://www.riss.kr/index.do
논문 중 KCI 등재된 논문은 인정받은 논문이므로 질이 좋음

내가 찾았던 논문은 이용자들이 지속적인 운동을 도울 수 있도록 긍정적인 영향을 주는 방법에 관해
연구결과를 분석했다.

이 논문은 이용자들이 지속적인 운동을 도울수 있는 방법을 찾고 그 결과로 앱서비스로 만들어 연구결과까지 상세히 작성되어 있었다.

특히 인상깊었던 서비스컨셉 중 하나로 사용자가

헬스장에 출입하면서 바코드를 통해 출석한 데이터로 운동하고 있다는 것을 아바타 화하여 보여준다.

가상의 헬스장을 구성하여 사용자의 아바타와 사용자가 팔로우하는 사용자들의 아바타들이 운동하고 있는 모습을 시각화하고 사용자가 가상의 헬스장을 두 손가락으로 확대, 축소하여 아바타들이 열심히 운동하는 모습을 볼 수 있다. 그리고 팔로워가 운동하게 되면 사용자에게 알람이 가게 되는데, 팔로워들의 아바타들이 운동하는 모습을 통해 사용자의 운동 욕구를 불러일으킬수 있는 효과가 있었다는 결과가..

먼 미래(?)에 메타버스 또는 가상현실세계로 풀어나갈수 있는 좋은 컨셉인것 같아 좋은 아이디어가 되지않을까 생각이 들었다.

그리고 프로토타입까지 만들어 UT까지 진행되었는데 라이트모드보다 다크모드 선호도가 높았다는 테스트결과가 나왔고

이유는 눈의 피로도와 앱서비스의 기능이 더 전문성이 느껴졌다고 한다.

정리해보면 이 논문에서는

다른 이용자들이 현재 운동하고 있다는 것을 보여주는 것이 motivation을 만듦
다크모드가 좋음

에 힌트를 얻어 기다려짐을 만드는데 큰 도움이 되었다.

(아쉽게도 현재 논문링크는 없어진상태 )

자신이 행하는 일은 엄격하게, 남의 것을 받아들일땐 너그럽게,

lyla-bae — Mon, 23 Feb 2026 09:55:06 +0900

다른 곳으로부터 받는 정보는 최대한 많은 변수에 대비해야하고,
상대에게 전달해야할 피드백은 분명하고 명백하게 전달해야한다

포스텔의 법칙을 간단하게 요약해 보았다.

자신이 행하는 일은 엄격하게

이용자에게 언제나 안정성과 접근성을 보장해야 한다

ex) 반응형 웹디자인은 다양한 기기의 크기나 유형에 맞게 웹사이트가 유동적으로 반응하고 이용자에게 제공되는것을 알수있습니다

남의 것을 받아들일땐 너그럽게

이용자의 입력은 무조건 수용해야 한다

ex) 회원가입 폼을 구성할때 중복된 정보를 요청하고있지 않은지 확인하고, 꼭 필요한 폼만 채울수있도록 구성해야 이용자의 피로를 줄일수있습니다

참고링크

https://m.blog.naver.com/moongteagray/222302964051

[UX/UI의 10가지 심리학 법칙] 5장. Postel’s Law 포스텔의 법칙

자신이 행하는 일은 엄격하게, 남의 것을 받아들일 때는 너그럽게 Be conservative in what you do be lib...

blog.naver.com

Lighthouse로 만난 접근성 이슈 하나씩 뽀개기

lyla-bae — Fri, 20 Feb 2026 17:11:42 +0900

이미지를 누르면 기다려짐 github로 이동합니다 (틈새홍보)

드디어 끝이보이는 기다려짐...! ~~(그러나 끝나지않은...)~~

요즘은 리팩토링, 최적화 등 마무리작업을 진행중이다.

나는 접근성과 SEO을 개선하기 위해 Lighthouse를 요 몇일사이 열심히 돌려보았고

그 과정에서 만난 여러가지 이슈들을 오늘 소개해보고 나의 문제해결 과정을 정리해보고자 한다!

접근성 구조와 Landmark

이젠 시맨틱하게 마크업을 해야한다는것은 너무 잘알고있다.

그런데 Landmark라는 개념은 초면이였다. 그래서 또 찾아보았다.

페이지의 주요 영역을 시맨틱태그 or Aria role로 구분해
스크린단위가 영역단위로 탐색할수있게 해주는 것을 의미한다.

주요 랜드마크 종류는 HTML 태그로 이렇게 표현한다.

<header> ⭐️⭐️⭐️ 페이지 상단 헤더
<nav> ⭐️⭐️⭐️ 내비게이션 메뉴
<main> ⭐️⭐️⭐️ 주요 콘텐츠 영역
<aside> 사이드바
<footer> ⭐️⭐️ 하단 푸터
<section>, <article> 콘텐츠 구역

⭐️⭐️⭐️는 필수급이니 빠트리지않고 적어주는것이 좋다

더 자세하게 알고싶다면 아래 아티클을 참고 해보시라요

https://velog.io/@sejinkim/HTML-랜드마크-역할을-사용하여-접근성-향상시키기

[번역] HTML 랜드마크 역할을 사용하여 접근성 향상시키기

웹 접근성을 향상시키기 위한 HTML 랜드마크 규칙(ARIA landmark roles)에 대해 설명합니다.

velog.io

브랜드컬러도 좋지만 4.5:1 명암비는 한번쯤은 고려해보자

기다려짐은 초반 기획부터 헬스케어 서비스이기 때문에 사용자의 건강을 고려한단 의미로 다크모드만 제공되고 있다

거기서 디자인 아이덴티티를 더해 열정(붉은계열) + 운동기구,쇠느낌(네이비)를 브랜드컬러로 결정하게 되었는데

디자인 의사결정을 혼자서 하다보니 접근성에 맞는지도 확인하지 않고 작업을 했던것이였다.

기다려짐의 홈화면 비교

위 화면은 서비스 홈화면인데 하단 오렌지색상 버튼이 WCAG가 정한 4.5:1 명암비에 맞지않아

부랴부랴 버튼색상을 화이트로 다 바꿔야하는 번거로운 작업이 일어났다

프론트는 물론 피그마나 랜딩페이지, 하다못해 리드미에 들어간 이미지들도 모두 바꿔야하는...ㅠ

뭐 그런 수고스러움은 그렇다 치더라도 명암비에 맞추고나니
확실히 눈이 좀 더 편안해진것같은 느낌적인 느낌(?)이 들기도 한다

덕분에 명암비를 쉽게 맞출수있는 피그마 플러그인 Stark도 알게되었고

만약 명암비에 맞지않는다하더라도 비슷한 색상을 추천해주는 사이트도 알게되어 북마크 해두었다.

아래에 해당사이트들 링크걸어두었으니 필요한사람은 줍줍 해가라능

https://www.getstark.co/

Stark: The suite of integrated accessibility tools for your product design and development team

The suite of integrated accessibility tools for your product design and development team • Making the world’s products accessible.

www.getstark.co

https://app.contrast-finder.org/?lang=ko

Contrast Finder, 웹 접근성 기준(WCAG)에 적합하도록 명암이 충분히 대비되는 색의 조합 검색

Contrast-Finder는 웹 접근성 기준(WCAG)에 적합하도록 명암이 충분히 대비되는 색의 조합을 찾아줍니다. 그래서 색의 명암비와 관련된 웹 접근성(a11y) 테스트를 충족시키는 데 도움을 드립니다. Contras

app.contrast-finder.org

모바일에서 아이콘과 폰트 최소사이즈 정도는 숙지하자

접근성이슈는 아니지만 pc에서 모바일화면을 작업할때는 체감되지않던 아이콘,폰트들이
실제 디바이스에서 실행해보면 사이즈가 많이 작다는것을 알게되었다.
이럴땐 그냥 사람들이 많이 이용하고 잘운영되고 있는 사이트들을 벤치마킹 하는것이 짱인거같다.

⭐️그리고 반드시 디바이스에서 디버깅 해보아야한다⭐️

또한 아이콘은 터치영역까지 고려해서 작업해야한다는점..! (최소 48px) 이건 WCAG에서 권고하는 부분이다!

영원히 해결하지 못할것같았던 MUI Modal의 Focus 접근성 이슈

사건의 전말은 이렇다. 어느날 어느 페이지의 모달 디버깅을 하던 도중 아래와 같은 콘솔에러를 만났다

Blocked aria-hidden on an element because its descendant retained focus.
Element with focus: <button>
Ancestor with aria-hidden: <div#root>

MUI Modal은 열릴 때 배경 콘텐츠를 비활성화하기 위해 #root에 aria-hidden="true"를 자동으로 붙인다.
문제는 버튼을 클릭하면 그 버튼에 포커스가 생기는데, 모달이 열리면서 aria-hidden이 적용되는 시점에
포커스된 버튼이 아직 #root 안에 남아 있다는 거다.

버튼 클릭 → 버튼에 포커스 생성 → 모달 열림 → #root에 aria-hidden 적용 →
포커스된 버튼이 aria-hidden 영역 안에 남아있음 → 에러

UI는 멀쩡하게 동작하지만 스크린리더 기준으로는 포커스 탐색이 깨진 상태였던것...

이거 하나를 해결하기 위해 온갖 방법(구글링,gpt,claude 등) 다 동원해봐도 계속 해결되지않아
접근성 모든이슈를 포기하고 있다가 요몇일 다시 해야겠단 생각이 들어
claude와 함께 다시 머리를 맡대어 문제해결을 드디어 해버렸다...!

<button
onClick={(e) => {
  e.currentTarget.blur(); // 포커스 제거
  setTimeout(() => {
    setIsOpenDialog(true);  // 모달 오픈
  }, 0);
}}
>
  삭제
</button>

모달을 열기전에 버튼 포커스를 blur()로 포커스를 명시적으로 제거시키면 되는 간단한 문제였던것이다

또한 간헐적으로 이슈가 일어나고 있어서 setTimeout으로 모달오픈을 타이밍을 맞추어

다음 task로 미루면 안정적으로 문제 해결을 할수 있었다. (고마워 클로드 )

마무리

처음에는 Lighthouse 접근성 점수가 70점대가 나온 게 이제는 90점대가 나온다..!

접근성 이슈들을 하나씩 해결해 나가다 보니, 단순히 점수를 맞추는 작업이 아니라
사용자가 어떤 흐름으로 화면을 탐색하고, 어디에서 멈추고,
어떻게 인터랙션하는지를 확인하는 과정에 가깝다는 생각이 들었다.

랜드마크 구조, 명암비, 터치 영역, 포커스 흐름까지 결국은 모두 UIUX를 안정적으로 만들기 위한 요소들이었다.

이번 작업을 통해 접근성은 UI를 구현하면서 자연스럽게 함께 고려해야 하는 기준이라는 것을 조금은 체감하게 된 것 같다.

미들웨어, 알고나니 다 설명된다!

lyla-bae — Tue, 3 Feb 2026 16:18:15 +0900

오랜만에 디깅미션이 돌아왔다!

이정환 Next강의를 이미 완강했었기때문에 수업을 잘이해하지않을까 생각했는데

미들웨어는 설명이없어서(있었는데 기억을 못하는걸수도;;)

~~나의 영원한 친구~~ 클로드와 지피티와 함께 미들웨어에 대해 공부하는 시간을 가졌다

미들웨어는

건물입구의 경비원 같은 존재라 생각하면 된다. 페이지 보여주기 전에 한번 거르는 관문인것이다

// middleware.ts
import { NextResponse } from 'next/server'

export function middleware(request) {
  const token = request.cookies.get('token')

  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  return NextResponse.next()
}

export const config = {
  matcher: ['/dashboard/:path*']
}

사용자가 /dashboard 접속하면 미들웨어가 로그인여부를 따진다

안했으면 /login으로 보내고 했으면 그대로 통과시켜주는 것이다

예시처럼 로그인 여부체크나 특정 페이지 접근제한. 국가별 리다이렉트 등의 상황에서 자주 쓰인다고 한다

미들웨어 초보들은 들으라

export function middleware() {
  console.log('실행')
} //큰일난다!

export const config = {
  matcher: ['/dashboard/:path*']
} //matcher로 쓸곳만 명시하자

matcher 안쓰면 이 콘솔메시지가 페이지, 이미지, css, api, 심지어 favicon까지 전부거쳐 실행될것이다

당연히 성능저하가 된다

matcher: '/:path*'//모든경로 다포함

export const config = {
  matcher: [
    '/((?!login|signup|api|_next|favicon.ico).*)' //login, signup, api, 정적 파일 빼고 전부
  ]
}

matcher에 모든경로를 포함해서 체크하면 리다이렉트된 페이지가 또다시 미들웨어를 타기때문에 무한루프가 된다

그러니 꼭 필요한 경로에서만 쓰도록 명시해야한다.

하나더 말하자면 미들웨어는 서버에서 실행된다.

localStorage.getItem('user') // 응안됨.

때문에 localStorage같은 브라우저 api들은 먹히지 않는다.

사용할수 있는것은 쿠키,헤더,url 정보이니 명심하라~!!!!!!!

middleware의 보안이슈

RSC 취약점이 발견되엇다

작년 12월 React Server Components의 취약점때문에 보안 공격이슈가 있어

많은이들의 react,next 프로젝트가 코인 채굴기로 변질되어있었다라는 후기를 꽤나 볼수있었다.

이후 next16이 나오면서 middleware.ts는 proxy.ts로 바꾸라고 권장하고 있다.

단순히 파일명 변경이 아니라 proxy에서는 전달만하고 인증처리는 서버컴포넌트에서 안전하게 인증하라는 뜻이다!

(쓰는 방법은 아래에서 알려드림)

아직까진 middleware라고 적어도 동작은 하지만 언제 또 없어질지 모르니 걍 proxy로 쓰도록하자

마이그레이션하는 방법은 공식문서 참고 ㄱㄱ

https://nextjs.org/docs/messages/middleware-to-proxy

Renaming Middleware to Proxy

Using App Router Features available in /app

nextjs.org

https://www.dailysecu.com/news/articleView.html?idxno=203063

[긴급] React·Next.js RSC서 인증 없는 원격 코드 실행 취약점…“패치 미적용 시 즉각 침해 가능” -

리액트 서버 컴포넌트(React Server Components, RSC)에서 인증 없이 원격 코드 실행이 가능한 중대한 보안 취약점이 공개됐다. 전 세계 웹 애

www.dailysecu.com

그래서 결론은 2단계 인증패턴을 쓰면 좋다!

// middleware or proxy
export function middleware(request) {
  const token = request.cookies.get('token')

  if (!token) {
    return NextResponse.redirect('/login')
  }
}

먼저 미들웨어에서 토큰 존재만 체크한뒤

// app/dashboard/page.tsx
import { cookies } from 'next/headers'
import { redirect } from 'next/navigation'

export default async function Page() {
  const token = (await cookies()).get('token')
  if (!token) redirect('/login')

  const session = await db.session.findUnique({
    where: { token: token.value }
  })

  if (!session) redirect('/login')

  return <>대시보드</>
}

서버컴포넌트에서 DB까지 확인하면 그때가서 진짜 인증하는 구조로 쓰는것이 안전하겠다.

대충 이런짤로 마무리 (미들웨어 이해완했다는 뜻)

Page Router에서 App Router로, 왜 바뀌었을까?

lyla-bae — Wed, 28 Jan 2026 14:51:30 +0900

CSR vs SSR

Router 차이를 설명하기 전에 먼저 SSR의 등장부터 이해할 필요가 있다.

CSR는 초기접속이 느리고 SEO가 불리하다는 치명적인 단점이 있었는데

SSR의 사전렌더링으로 CSR의 단점들을 해결할수 있다.

아래는 SSR의 사전렌더링 과정을 한눈에 볼수있어서 가져왔다.

CSR은 빈껍데기를 화면에 먼저 렌더링시켜버리는 반면 SSR은 서버에서 미리 렌더링시켜 유저에게 뿌리기때문에

FCP(First Contentful Paint) : 사용자가 페이지 접속후 첫콘테츠를 만나는 시간을 나타내는 지표 가 굉장히 유리해지게된다.

출처 - 이정환님의 Next.js 강의

Next12까지 page Router로 SSR을 도입하면서 데이터 패칭과 렌더링을 분리했는데 이 방법도 곧 한계를 보이고만다.

페이지 전체가 SSR되면서 굉장히 비효율적이며,

모든 컴포넌트가 클라이언트 기준이 되고, 레이아웃이 계속 재렌더링된다는 문제가 잇었던것이다.

그래서 이문제를 또다시 해결하기위해 Next13 버전부터 app Router가 도입이 되었고

현재기준 Next16까지 지금까지도 많은 풀스택 기능들을 쓸수있게 업데이트 되고 있다!

뭐든 공식문서가 짱이니 Next가 궁금한 사람이라면 한번씩 들러보길 츄라이츄라이

https://nextjs.org/docs

Next.js Docs | Next.js

Welcome to the Next.js Documentation.

nextjs.org

이제부터 본격 Page Router와 App Router 차이를 본격 비교해보자!

라우팅 방식 차이

페이지라우터보다 앱라우터가 러닝커브가 높다곤 하지만 솔직히 라우팅 개념 자체가 어려운편이 아니라서

그냥 한번쓱보면 다들 이해가 갈것이다 (나도 이해했는데말야 ^^)

Page Router

pages/
 └─ index.tsx        → /
 └─ about.tsx        → /about
 └─ posts/[id].tsx   → /posts/1

pages 폴더 기준
파일 = 라우트
구조가 직관적이라 배우기 쉬움

App Router

app/
 └─ page.tsx         → /
 └─ about/page.tsx   → /about
 └─ posts/[id]/page.tsx → /posts/1

폴더 기반 라우팅
page.tsx, layout.tsx 역할이 분리됨
처음엔 낯설지만 구조화가 잘 됨

레이아웃 처리 방식

Page Router

공통 레이아웃을 바깥 _app.tsx에서 직접 감싸야 함
페이지 이동 시 레이아웃도 다시 렌더링

App Router

app/
 └─ layout.tsx
 └─ page.tsx

layout.tsx로 중첩 레이아웃 가능
페이지 이동 시 레이아웃 유지
대시보드, 탭 구조에 매우 유리

페이지단위로 끊어서 레이아웃을 커스텀할수있기에 이건 App Router가 압승인거같다

데이터 패칭 방식

Page Router

export async function getServerSideProps() {
  return { props: {} }
}

getServerSideProps
getStaticProps
getStaticPaths

요런 전용 API로 비동기처리를 해야해서 기본적으로 암기해야할것들이 좀 있는 반면

App Router

const data = await fetch(url, { cache: 'no-store' })

컴포넌트에서 직접 fetch
기본이 Server Component
캐싱 전략을 옵션으로 제어

무려 비동기처리를 컴포넌트 내에서 실행시킬수있으며 캐싱도 옵션으로 온오프가 가능하다..!!

Server / Client 컴포넌트 차이

Page Router

모든 컴포넌트가 기본적으로 Client
SSR은 “페이지 단위”

App Router

'use client'

기본은 Server Component
Client 필요할 때만 위 코드를 상단에 적어주면 끝 (대박)

필요할때만 클라이언트 컴포넌트를 쓸수있기때문에 JS번들 용량도 줄이고 성능도 올릴수있다.

마무리

따라서 빠르게 만들어야 하는 소규모 프로젝트는 러닝커브가 낮은 Page Router도 충분하지만..

성능이 중요한 프로젝트에선 App Router를 적극 권장한다.

앞으로는 Next도 App Router를 중심으로 지원업뎃이 될것이기때문에 이왕이면 최신스택을 고르는게 좋겠다!

쉬워도 이렇게 쉬울수없는 Zustand

lyla-bae — Mon, 19 Jan 2026 14:59:21 +0900

store와 create만 기억하면 됨

https://zustand-demo.pmnd.rs/

Zustand

zustand-demo.pmnd.rs

Zustand는 크기가 작아서 가볍고 빠르며 확장성이 좋은 전역 상태 관리 라이브러리다.
이름부터 뭔가 특이한데, 독일어로 상태라는 뜻이라고 한다. 발음은 쭈스탄트 정도로 읽으면 된다

import { create } from 'zustand'
export const use이름Store = create((set, get) => { //set은 상태 업데이트할 때, get은 현재 상태 가져올 때 씀
  return {
    상태: 초깃값,
    액션: 함수
  }
})

Zustand에서는 create라는 함수로 store를 만든다. 그리고 이 store를 기반으로 동작한다.

Store가 뭐냐면, 간단히 말해서 애플리케이션의 상태를 저장하는 중앙 데이터 저장소라고 보면 된다.
쇼핑몰로 치면 창고 같은 개념이랄까. 필요한 물건들을 한곳에 모아두고 필요할 때 꺼내 쓰는 거지.

그래서 Zustand 쓸 때는 무조건 create 함수로 store 생성하는 것부터 시작한다고 보면 된다.

참고자료

https://yunicornlab.tistory.com/100

zustand가 뭐야 어떻게 써

1. Zustand란?크기가 작아서 가볍고 빠르며 확장성이 좋은 전역 상태 관리 라이브러리다. Zustand는 독일어로 "상태"라는 뜻이다. (독일어다보니 발음은 쭈스탄트 정도로 읽으면 된다.)zustand는 store를

yunicornlab.tistory.com

진짜 강점은 미들웨어

기본 사용법은 공식 문서나 다른 블로그에도 많으니까 생략하고, Zustand의 진짜 강점인 미들웨어에 대해 얘기해보려고 한다.

미들웨어는 store에 추가 기능을 끼워넣을 수 있는 방법이다.
Redux를 써봤다면 Redux 미들웨어랑 비슷한 개념이라고 보면 되는데, Zustand는 이게 훨씬 간단하고 직관적이다.

주요 미들웨어 종류

Zustand에서 제공하는 주요 미들웨어들을 간단히 소개하면 이렇다.

combine
: 여러 개의 store를 합쳐서 하나로 만들어준다. 상태를 모듈별로 나눠서 관리하다가 나중에 합칠 때 쓴다.
immer

: 불변성 관리를 편하게 해준다. 복잡한 객체나 배열 상태를 업데이트할 때 spread 연산자 남발 안 해도 되고, 그냥 일반 객체 다루듯이 코드 짜면 된다.

subscribeWithSelector

: 특정 상태 값만 선택적으로 구독할 수 있게 해준다. 전체 store가 아니라 필요한 부분만 감시하고 싶을 때 유용하다.

persist

: 상태를 로컬스토리지나 세션스토리지에 자동으로 저장해준다. 새로고침해도 상태가 유지되어야 할 때 쓰면 딱이다. 로그인 정보나 사용자 설정 같은 거 저장할 때 많이 쓴다.

devtools

: Redux DevTools를 연동해준다. 크롬 확장 프로그램으로 상태 변화를 추적하고 디버깅할 수 있어서 개발할 때 엄청 편하다.

미들웨어 사용 문법 짱쉬움

미들웨어를 쓸 때는 괄호를 중첩해서 감싸는 방식으로 적용한다. 안쪽에서 바깥쪽으로 감싸진다고 생각하면 된다.

주스탠드가 러닝커브가 낮은걸로 유명하지만 쉬워도 이렇게 쉬울수가 없다

import { create } from 'zustand';
import { devtools, persist } from 'zustand/middleware';
import { immer } from 'zustand/middleware/immer';

const useStore = create(
  devtools(
    persist(
      immer((set) => ({
        count: 0,
        user: { name: '', age: 0 },
        increase: () => set((state) => { state.count += 1 }),
        setUser: (name, age) => set((state) => {
          state.user.name = name;
          state.user.age = age;
        }),
      })),
      { name: 'my-store' }
    )
  )
);

이 코드를 보면 immer가 제일 안쪽에 있고, persist로 감싸고, 다시 devtools로 감싼 구조다.
실행 순서로 보면 immer가 먼저 적용되고, 그 다음 persist, 마지막으로 devtools가 적용된다고 보면 된다.

persist 같은 경우는 두 번째 인자로 옵션 객체를 받는데, 여기서 name은 로컬스토리지에 저장될 키 이름이다.

마무리

Zustand의 미들웨어는 복잡한 설정 없이 괄호 몇 개로 강력한 기능들을 추가할 수 있다는 게 진짜 장점이다.

Redux처럼 복잡한 보일러플레이트를 만날 필요도 없고, 그냥 필요한 미들웨어 import해서 감싸주기만 하면 된다.

처음엔 괄호 중첩이 좀 헷갈릴 수 있는데, 몇 번 써보면 금방 익숙해진다. 안에서 바깥으로 감싼다는 것만 기억하면 된다.

더 나은 UX를 위해 개발자가 할수있는 방법은?

lyla-bae — Wed, 14 Jan 2026 16:06:24 +0900

“Make waiting times tolerable.
Provide feedback during delays.

도널드 노먼의 UX 원칙 중 하나는 모든 행동에는 적절한 피드백이 뒤따라야 한다는 것이다.

UX에서 중요한 것은 기다림을 없애는 것이 아니라, 기다림을 경험하게 만드는 방식이다.

디자인을 공부할때 UX는 기획자와 디자이너만의 영역이라 생각했는데
생각해보면 개발자도 충분히 기여할수있는 방법이 많다 (보고있나 개발자여)

그 방법 중 하나가 바로 성능최적화이다

그래서 개발자에 있어서 아주~~~~!!!! 중요한 역량이다

리액트에서 성능최적화를 하는 방법도 아주아주 많지만 가장 많이 쓰는 방법 두가지를 디깅해보았다!

코드스플리팅

하나의 거대한 JS 번들을 여러 조각으로 나누고, 필요한 코드만 로드하는 전략을 말한다.

React와 같은 SPA 구조 라이브러리/프레임워크에서는

보통 모든 페이지와 기능을 하나의 번들로 묶어 초기 로딩 시점에 한 번에 내려받는다.
이 방식은 구현은 단순하지만, 사용자가 아직 사용하지도 않을 코드까지 함께 다운하게 만든다.

React.lazy 와 Suspense 함께쓰기

import { lazy, Suspense } from 'react'

const ChartPage = lazy(() => import('./ChartPage'))

function App() {
  return (
    <Suspense fallback={<Loading />}>
      <ChartPage />
    </Suspense>
  )
}

ChartPage는 당장 필요한 코드가 아니기 때문에 lazy로 초기 번들에 포함되지 않게 만들었다.

그리고 렌더링 시점에 JS 파일을 네트워크로 가져오는 동안 Suspense로 fallback (대체 UI)로 상태를 전달한다

여기서의 성능을 최적화는 lazy 뿐이지만 노먼 선생님이 말한대로 기다리는 동안 아무 피드백이 없으면 사용자는 답답해질것이다

그래서 UX개선과 lazy의 비동기 처리를 위해 Suspense를 함께 쓰는 전략을 고르는것이다.

만약 라우트를 쓴다면 라우트 단위로 스플리팅하기

const Home = lazy(() => import('./pages/Home'))
const Detail = lazy(() => import('./pages/Detail'))

요렇게 lazy를 통해 페이지 단위로 import 시켜주면 초기로딩 비용도 줄이고
사용자도 한번에 한페이지만 사용할수있으니 일석이조!

메모제이션 쓰는 방법도 아주 좋다!

지난번 메모제이션에 대해 포스팅한 것이 있기때문에 이번에는 간단히 설명해보자면

리액트에선 state props가 바뀌면 컴포넌트가 리렌더링 되기때문에

이과정에서 state가 바뀌지않았는데 비용이 큰 계산이 로직에 의해 매번 실행된다거나 과한 props drilling이 있다면

React.memo, useMemo, useCallback 같은 메모제이션을 쓰는 것도 좋은 전략중 하나가 된다

요것에 대한 설명은 지난날 포스팅을 참고하도록...

2025.12.29 - [REACT] - Virtual DOM부터 Memoization까지

Virtual DOM부터 Memoization까지

기나긴 2주간의 방학이 끝나고 다시 수업이 재개되었다.. 그리고 오랜만의 디깅타임~!!!오늘은 가상돔과 메모이제이션으로 최적화할 수 있는 방법들을 두루 배웠다.역시나 면접 단골 질문으로

lyla-bae.tistory.com

메모제이션 실습 문제로 마무리!

실전 같이 성능 최적화하기 try-first

React.memo, useMemo, useCallback을 조합해서 최적화하는 고급 실습입니다.

실무에서 자주 맞닥뜨리는 패턴이고, 특히 리스트 & 자식 컴포넌트가 있을 때 성능 최적화가 중요해요.

현재 우리가 개발 중인 프로젝트에서 게시글 리스트를 렌더링하는 부모 컴포넌트가 있고

각 게시글(자식 컴포넌트)은 props에 따라 무거운 연산을 하거나 버튼 클릭 이벤트를 가지고 있는 상태입니다.

// PostItem.tsx
const PostItem = ({ title, content, onClick }) => {
  console.log(`  Rendering: ${title}`);

  // 무거운 연산 (예시)
  const wordCount = content
    .split(" ")
    .reduce((acc, word) => acc + word.length, 0);

  return (
    <div style={{ border: "1px solid gray", marginBottom: "10px" }}>
      <h4>{title}</h4>
      <p>{content}</p>
      <p>
        <b>Word Count:</b> {wordCount}
      </p>
      <button onClick={onClick}>Like</button>
    </div>
  );
};

// App.tsx
import { useState } from "react";

const DUMMY_POSTS = [
  { id: 1, title: "First Post", content: "This is the first post content." },
  {
    id: 2,
    title: "Second Post",
    content: "Another post with more words to count.",
  },
  { id: 3, title: "Third Post", content: "Short one." },
];

export default function App() {
  const [likes, setLikes] = useState(0);
  const [dummy, setDummy] = useState(false);

  return (
    <div>
      <h2>Total Likes: {likes}</h2>
      <button onClick={() => setDummy(!dummy)}>Re-render Parent</button>

      {DUMMY_POSTS.map((post) => (
        <PostItem
          key={post.id}
          title={post.title}
          content={post.content}
          onClick={() => setLikes(likes + 1)}
        />
      ))}
    </div>
  );
}

위 코드를 실행시켜보면 모든 버튼을 누르면 모든 자식 컴포넌트들이 리렌더링됩니다.

이 예제에서 뭐가 문제인지, 그 문제를 어떻게 해결할 수 있을 지 수정해보세요.

결과

풀이

// PostItem.jsx
import { memo, useMemo } from "react";

export const PostItem = memo(({ title, content, onClick }) => {
  // props 비교해 메모제이션
  console.log(`  Rendering: ${title}`);

  // 무거운 연산이 반복되므로 useMemo로 content,title이 바뀔때만 다시계산
  const wordCount = useMemo(() => {
    return content.split(" ").reduce((acc, word) => acc + word.length, 0);
  }, [content, title]);

  return (
    <div style={{ border: "1px solid gray", marginBottom: "10px" }}>
      <h4>{title}</h4>
      <p>{content}</p>
      <p>
        <b>Word Count:</b> {wordCount}
      </p>
      <button onClick={onClick}>Like</button>
    </div>
  );
});

자식 컴포넌트부터 문제를 살펴보면

1. PostItem 컴포넌트의 props들부터 불필요하게 리렌더링 되고 있었다.

따라서 React.memo로 props를 비교해 메모제이션 시켜주고

2. wordCount 란 무거운 연산 또한 content와 title이 바뀔때만 다시 계산되도록

useMemo로 메모제이션 시켜주었다.

// App.tsx
import { useCallback, useState } from "react";
import { PostItem } from "./PostItem";
const DUMMY_POSTS = [
  { id: 1, title: "First Post", content: "This is the first post content." },
  {
    id: 2,
    title: "Second Post",
    content: "Another post with more words to count.",
  },
  { id: 3, title: "Third Post", content: "Short one." },
];

export default function App() {
  const [likes, setLikes] = useState(0);
  const [dummy, setDummy] = useState(false);

  //매번 실행하던 함수를 useCallback 빈배열(의존성배열)로 한번만 생성할수있게
  const handleLike = useCallback(() => {
    setLikes((prev) => prev + 1);
  }, []);

  return (
    <div>
      <h2>Total Likes: {likes}</h2>
      <button onClick={() => setDummy(!dummy)}>Re-render Parent</button>

      {DUMMY_POSTS.map((post) => (
        <PostItem
          key={post.id}
          title={post.title}
          content={post.content}
          onClick={handleLike}
        />
      ))}
    </div>
  );
}

3. 버튼의 이벤트 핸들러도 이전코드엔 App 컴포넌트가 실행될때마다 내용이 같아도 매번 생성되기 때문에

요거또한 useCallback의 의존성배열을 활용해서 클릭할때 딱 한번만 생성될수 있게 만들어주면 끝!

테스트를 먼저하고 개발을 한다고...? TDD와 Jest

lyla-bae — Tue, 13 Jan 2026 16:12:49 +0900

오랜만에 돌아온 아티클 미션!

TDD와 Jest에 대해 배우는 시간이였다.

TDD란?

테스트를 먼저 작성 후 그 테스트를 통과하도록 개발을 하는 개발 프로세스를 말한다.

일단 개념은 이해했지만, 실제로 코드를 짜기 전 테스트를 먼저 떠올리는 게 쉽지 않았다.

정말 TDD를 하는 회사가 있을까?

진짜 궁금해서 당장 사람인,잡코리아에 들어가 JD를 찾아보았다.

필수스펙은 아니지만 생각보다 테스트를 요구하는 회사들이 좀 있어보였다

정말 개발 쉽지않구나,,아직은 테스트를 먼저 설계하는 게 익숙하지 않아서 어렵게 느껴졌다.

어쩌겠는가 필요하다면 해야지. 모르면 배우면 된다!

https://youtu.be/W-fyyAHAqSU?si=DDKTGgBUBDXcwhto

진짜 TDD가 필요한건지 궁금해서 보았는데 한번씩 시청해보시길

TDD의 종류

피라미드 구조로 정리해보면 아래와 같다.

1. Unit Test : 단위테스트 (Jest)

함수나 컴포넌트 하나만 독립적으로 테스트 해보는것으로 가장 많이 쓰고 가장 공수가 덜드는 테스트라 볼수있다

2. Integration Test : 통합테스트

여러 컴포넌트가 함께 잘 동작하는지 테스트한다. Jest + React Testing Library로 가능하다

3. E2E Test (End to End):

전체 사용자 플로우를 테스트한다. 실제 사용자처럼 브라우저에서 클릭하고 입력하는 UI Test도 포함되어있는 테스트이다.

첨에 UI Test를 보고 내가 아는 그 UT(Usability Test : 사용성 테스트)인가 했는데 전혀 다른개념이다!

여기서의 UI Test는 테스트를 자동화시켜 기능이 제대로 작동하는지에 목적을 둔다

Usability Test가 기획/디자이너들 포폴에 쓴다면 개발자 포폴에 쓰는 테스트는 UI Test가 적절하다고 볼수있겠따,,

~~(이것도 모르고 나는 지난 사이드프로젝트때 Usability Test를 하자고 고집피웠다,, 결론적으론 못했지만)~~

물론 둘다 보여주면 아주좋겠지만 개발자 포폴이니까 ^^,,,!!

출처 : https://velog.io/@nueob/%ED%85%8C%EC%8A%A4%ED%8A%B8%ED%94%BC%EB%9D%BC%EB%AF%B8%EB%93%9C%EB%9E%80

그래서 Jest가 뭔데..?

설명이 좀 늦었지만 Jest란 자바스크립트 환경에서 테스트를 할수있는 테스트 프레임워크이다

프레임워크이기 때문에 당연 node 설치가 필요하다능

출처 : https://velog.io/@bami/Javascript-%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-Jest

(자스기준) 테스트 프레임워크도 종류가 몇있는거 같은데 현재로선 Jest가 가장 점유율이 높고

그외 Jasmine, mocha, (강사님 피셜) Vitest 등 다양한 프레임워크들이 나오는거같다

Jest는 기술적으로 특별해서라기보다는, 프론트엔드 생태계에서 사실상 표준처럼 사용되고 있어 자연스럽게 선택되는 도구라고 느꼈다

그리고 리액트 컴포넌트를 테스트하기위해 Testing Library 같은것도 존재한다,,

실제 사용자 관점에서 컴포넌트를 다루기 쉽게 도와주는 도구이기 때문에 npm 설치를 알아서 잘 하도록 하자

어쨋든 Jest도 프레임워크이기 때문에 그리고 당연히 문법이 따로 존재한다

다양한 기능, 그리고 다양한 메소드들이 있다 ^^...(wow)

expect(실제값).toBe(예상값);

Jest의 기본문법인데 저 예상값앞에 쓰는 메소드들을 Matcher라고 한다

Jest를 사용하려면 Matcher에 대한 이해가 꼭 필요하다!

대략 많이쓰는 것만 정리해보면

JavaScript Top3

1. toBe()
- === 비교

- 숫자, 문자열, boolean 같은 Primitive(원시,기본형)한 것만 비교

* toEqual와 혼돈 주의

2. toEqual()
- 객체, 배열 같은 참조 타입 비교
- 내용이 같은지 체크

3. toBeNull() / toBeUndefined() / toBeTruthy() / toBeFalsy()
null, undefined, 참/거짓 체크

React Top3

1. toBeInTheDocument()
DOM에 요소가 존재하는지 확인

2. toHaveTextContent()
요소의 텍스트 내용 확인

3. toHaveValue()
input, textarea의 값 확인

...정도가 있겠다. 당장은 못외우겠지만 일단 그렇다

내가 설명하기엔 너무 많아서 더 잘되어있는 아래 아티클을 참고해보자

https://think0wise.tistory.com/100

Jest - Matcher란?

여러분들은 Jest로 테스트 코드를 작성할 때 다양한 Matcher를 사용하고 계시나요? 오늘은 Jest에서 테스트 코드를 작성할 때 자주 사용하는 Matcher에 대해서 알아보겠습니다. 1. toBe( value ) 기본형을

think0wise.tistory.com

오늘의 뇌용량은 이만 가득찼기때문에 오늘 실습문제를 푸는걸로 급마무리 하겠다.

오늘의 실습문제

문제 1. 입력 필드와 제출 (NameForm 컴포넌트)

요구사항
- 사용자가 이름을 입력하고 제출하면, 화면에 “안녕하세요, [이름]님!” 이 표시된다.
- 초기에는 아무 텍스트도 보이지 않는다.

//NameForm.jsx
import React from "react";
export default function NameForm() {
  const [name, setName] = React.useState("");
  const [greeting, setGreeting] = React.useState("");

  const handleSubmit = (e) => {
    e.preventDefault();
    setGreeting(`안녕하세요, ${name}님!`);
  };

  return (
    <div>
      <form onSubmit={handleSubmit}>
        <input
          type="text"
          value={name}
          onChange={(e) => setName(e.target.value)}
          placeholder="이름을 입력하세요"
        />
        <button type="submit">제출</button>
      </form>
      {greeting && <p>{greeting}</p>}
    </div>
  );
}

테스트 요구사항
- 초기에는 인사말이 보이지 않는다
- 이름을 입력하고 제출 시 인사말이 표시된다
- hint) toBeNull, toBeInTheDocument

// NameForm.test.jsx
import React from "react";
import { render, screen, fireEvent } from "@testing-library/react";
import NameForm from "./NameForm";

test("초기에는 인사말이 보이지 않는다", () => {
  render(<NameForm />);

  expect(screen.queryByText(/안녕하세요,/)).toBeNull();
});

test("이름을 입력하고 제출 시 인사말이 표시된다", () => {
  render(<NameForm />);
  const input = screen.getByPlaceholderText("이름을 입력하세요");
  fireEvent.change(input, { target: { value: "철수" } });
  fireEvent.click(screen.getByText("제출"));

  expect(screen.getByText("안녕하세요, 철수님!")).toBeInTheDocument();
});

문제2. 조건부 렌더링 리스트 (TodoList 컴포넌트)

요구사항
- 할 일 목록을 보여준다.
- 초기 할 일 2개를 렌더링한다.
  - 초기 할 일 : ["React 공부하기", "테스트 배우기"]
- “할 일 추가” 버튼을 누르면 새 할 일이 추가된다.
  - 새 할 일 : 새 할 일 ${prev.length + 1}

// TodoList.jsx
import React from "react";
export default function TodoList() {
  const [todos, setTodos] = React.useState(["React 공부하기", "테스트 배우기"]);

  const addTodo = () => {
    setTodos((prev) => [...prev, `새 할 일 ${prev.length + 1}`]);
  };

  return (
    <div>
      <ul>
        {todos.map((todo, index) => (
          <li key={index}>{todo}</li>
        ))}
      </ul>
      <button onClick={addTodo}>할 일 추가</button>
    </div>
  );
}

테스트 요구사항
- 초기 할 일이 2개 표시된다
- 할 일 추가 버튼을 누르면 새 항목이 추가된다
- hint) toHaveTextContent, toBeInTheDocument

// TodoList.test.jsx
import React from "react";
import { render, screen, fireEvent } from "@testing-library/react";
import TodoList from "./TodoList";

test("초기 할 일이 2개 표시된다", () => {
  render(<TodoList />);

  expect(screen.getByText("React 공부하기")).toBeInTheDocument();
  expect(screen.getByText("테스트 배우기")).toBeInTheDocument();
});

test("할 일 추가 버튼을 누르면 새 항목이 추가된다", () => {
  render(<TodoList />);
  const button = screen.getByText("할 일 추가");

  fireEvent.click(button);

  expect(screen.getByText("새 할 일 3")).toBeInTheDocument();
});

참고자료

https://velog.io/@skyu_dev/Jest-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-JS%EC%9D%98-%EA%B8%B0%EB%8A%A5-%EC%A0%90%EA%B2%80%ED%95%98%EA%B8%B0#21-%EC%9C%A0%EC%9A%A9%ED%95%9C-matchers

[Jest] 테스트 코드로 JS 의 기능 및 로직 점검하기

Jest를 사용해서 JavaScript 코드를 테스트하고 버그를 줄여보자

velog.io

https://velog.io/@nueob/%ED%85%8C%EC%8A%A4%ED%8A%B8%ED%94%BC%EB%9D%BC%EB%AF%B8%EB%93%9C%EB%9E%80

테스트피라미드란 ?

(https://velog.velcdn.com/images/nueob/post/81558da3-f7f8-4e37-9ac2-a8f906aaa00f/image.png)unit Testing대상: 단일 기능 혹은 작은 단위의 함수/객체 등가벼운 비용으로 새로운 기능

velog.io

https://velog.io/@bami/Javascript-%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-Jest

[Javascript] 테스트 프레임워크 Jest

오늘은 자바스크립트의 또 다른 테스트 프레임 워크인 Jest를 소개해보려고 합니다. 예전에 Jasmine을 소개해드렸었는데요. 사용법이 거의 비슷합니다. 그 이유는 Meta에서 Jasmine을 기반으로 Jest 프

velog.io

lyla-bae 님의 블로그

서버 vs 클라이언트 혼재된 개념 정리

SSR / CSR vs 서버 컴포넌트 / 클라이언트 컴포넌트 부터 일단 헷갈림

SSR vs CSR 차이

그럼 Hydration은 또 뭐고

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

그래서 언제 뭘 써야하는데

스와이프 탭으로 UX까지 배우는 캐러셀 유랑기

스와이프되는 카테고리 탭을 구현해야한다

그래서 실제로 직접 구현을 1차 시도해봤다.

UT결과는 불편함

Embla 을 선택한 이유

그런데 또 문제발견 - touch action

또하나 새롭게 알게된 사실...! 접근성에는 모양도 중요하다는 것!!

마무리

프로젝트 주제와 관련된 UX 논문 찾기

내가 찾았던 논문은 이용자들이 지속적인 운동을 도울 수 있도록 긍정적인 영향을 주는 방법에 관해 연구결과를 분석했다.

자신이 행하는 일은 엄격하게, 남의 것을 받아들일땐 너그럽게,

다른 곳으로부터 받는 정보는 최대한 많은 변수에 대비해야하고, 상대에게 전달해야할 피드백은 분명하고 명백하게 전달해야한다

자신이 행하는 일은 엄격하게

남의 것을 받아들일땐 너그럽게

Lighthouse로 만난 접근성 이슈 하나씩 뽀개기

접근성 구조와 Landmark

브랜드컬러도 좋지만 4.5:1 명암비는 한번쯤은 고려해보자

모바일에서 아이콘과 폰트 최소사이즈 정도는 숙지하자

영원히 해결하지 못할것같았던 MUI Modal의 Focus 접근성 이슈

마무리

미들웨어, 알고나니 다 설명된다!

미들웨어는

미들웨어 초보들은 들으라

하나더 말하자면 미들웨어는 서버에서 실행된다.

middleware의 보안이슈

RSC 취약점이 발견되엇다

그래서 결론은 2단계 인증패턴을 쓰면 좋다!

Page Router에서 App Router로, 왜 바뀌었을까?

CSR vs SSR

라우팅 방식 차이

Page Router

App Router

레이아웃 처리 방식

Page Router

App Router

데이터 패칭 방식

Page Router

App Router

Server / Client 컴포넌트 차이

Page Router

App Router

마무리

쉬워도 이렇게 쉬울수없는 Zustand

store와 create만 기억하면 됨

진짜 강점은 미들웨어

주요 미들웨어 종류

미들웨어 사용 문법 짱쉬움

마무리

더 나은 UX를 위해 개발자가 할수있는 방법은?

코드스플리팅

React.lazy 와 Suspense 함께쓰기

만약 라우트를 쓴다면 라우트 단위로 스플리팅하기

메모제이션 쓰는 방법도 아주 좋다!

메모제이션 실습 문제로 마무리!

실전 같이 성능 최적화하기 try-first

결과

풀이

테스트를 먼저하고 개발을 한다고...? TDD와 Jest

TDD란?

TDD의 종류

그래서 Jest가 뭔데..?

어쨋든 Jest도 프레임워크이기 때문에 그리고 당연히 문법이 따로 존재한다

JavaScript Top3

React Top3

오늘의 실습문제

내가 찾았던 논문은 이용자들이 지속적인 운동을 도울 수 있도록 긍정적인 영향을 주는 방법에 관해
연구결과를 분석했다.

다른 곳으로부터 받는 정보는 최대한 많은 변수에 대비해야하고,
상대에게 전달해야할 피드백은 분명하고 명백하게 전달해야한다