co-cherry

@Transactional과 DB 인덱스로 Spring Boot 애플리케이션 성능 최적화하기

co-cherry — Fri, 15 May 2026 17:15:19 +0900

@Transactional

트랜잭션(Transaction)

데이터베이스의 상태를 변화시키는 하나의 논리적인 작업 단위를 구성하는 연산들의 집합

여러 개의 DB 작업을 하나의 단위로 묶고 분할할 수 없음 (원자성)

→ 전부 성공 또는 전부 실패만 가능

트랜잭션의 핵심 기능: ACID

Atomicity (원자성) All or Nothing 전부 성공하거나 전부 실패
Consistency(일관성) 트랜잭션 실행 전후로 데이터베이스가 일관된 상태를 유지
Isolation(격리성) 동시에 실행되는 트랜잭션들이 서로 영향을 주지 않음
Durability(지속성) 커밋된 트랜잭션은 영구적으로 저장됨

왜 트랜잭션이 필요할까?

트랜잭션은 데이터의 정합성을 보장한다.

여기서, 정합성이란 데이터가 모순 없이 일치하는 상태를 의미한다.

트랜잭션이 있으면,

모두 성공 → 정합성 유지
하나라도 실패 → 모두 롤백 → 정합성 유지

@Transactional

Spring Framework가 제공하는 선언적 트랜잭션 관리 어노테이션

Spring에게 이 메서드를 트랜잭션으로 실행해달라고 알려 주는 표시

Spring이 자동으로 트랜잭션을 실행하고 종료함

개발자가 직접 begin, commit, rollback을 안 써도 됨

*IOException, SQLException 같은 CheckedException에서는 자동 롤백되지 않음

@Transactional(readOnly = true)

@Transactional의 옵션 중 하나로 읽기 전용 트랜잭션을 만들 때 사용한다.

조회만 하는 경우, 이 옵션을 통해 자원을 절약하고 불필요한 업데이트를 방지할 수 있다.

나의 프로젝트에도 이와 같이 게시글 상세 조회에서 적용한 것을 볼 수 있다.

@Transactional(readOnly = true)
    public PostDetailResponseDto getPost(Long postId) {
        Post post = postRepository.findById(postId)
                .orElseThrow(() -> new GeneralException(PostErrorCode.POST_NOT_FOUND));

        return new PostDetailResponseDto(
                post.getId(),
                post.getTitle(),
                post.getContent(),
                post.getUser().getNickname(),
                post.getCreatedAt()
        );
    }

@Transactional을 이용해 회원 탈퇴를 구현해보자.

회원 탈퇴 시, User의 Comment와 Post, 마지막으로 User 자체를 삭제하는 방향으로 구현할 예정이다. (Hard delete)

먼저 CommentRepository와 PostRepository에 삭제 메서드를 작성한다.

void deleteAllByUserId(Long userId);

그리고 서비스에 삭제 로직을 작성한다.

이때 @Transactional 처리를 꼭 해야 작업이 하나의 단위로 처리된다.

@Transactional
    public void withdraw(Long userId) {
        User user = userRepository.findById(userId)
                .orElseThrow(() -> new GeneralException(UserErrorCode.USER_NOT_FOUND));

        commentRepository.deleteAllByUserId(userId);
        postRepository.deleteAllByUserId(userId);
        userRepository.delete(user);
    }

현재 DB 구조를 보면 Comment는 Post와 Users를 Post는 Users를 참조하고 있는데,

users 테이블
  └── post 테이블 (user_id → users.user_id 참조)
        └── comment 테이블 (post_id → post.post_id, user_id → users.user_id 참조)

여기서 만약 User를 먼저 삭제하면 FK 제약 위반이 발생한다.

따라서, 참조당하는 쪽은 참조하는 쪽이 없어진 다음에야 삭제가 가능하다.

또는 CasecadeType.ALL 옵션을 사용하면 JPA가 알아서 자식부터 삭제하지만 지금 같은 경우에는 순서를 꼭 지켜야 한다.

마지막으로, 컨트롤러에 엔트포인트를 추가하면 된다.

@Operation(summary = "회원 탈퇴", description = "유저의 댓글, 게시글, 계정을 모두 삭제합니다.")
@DeleteMapping("/{userId}")
public ApiResponse<Void> withdraw(@PathVariable Long userId) {
    userService.withdraw(userId);
    return ApiResponse.onSuccess(GeneralSuccessCode.OK, null);
}

테스트를 위해 게시글과 댓글을 작성했다.

그리고 회원 탈퇴를 한 후,

다시 아까 작성한 게시글을 조회하면 게시글을 찾을 수 없게 된다.

회원 탈퇴와 동시에 게시글, 댓글이 트랜잭션으로 모두 삭제되었기 때문이다.

Index

데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료 구조

MySQL은 기본적으로 B-Tree 구조의 인덱스를 사용한다.

인덱스 구조 (created_at 컬럼 기준):

                   [2024-03-15]
                   /          \
          [2024-02-15]      [2024-04-15]
          /        \        /          \
    [2024-01-15] [2024-02-28] [2024-03-31] [2024-05-15]
         ↓          ↓           ↓            ↓
      실제 행     실제 행      실제 행       실제 행

인덱스가 없으면 테이블 전체를 순서대로 훑는 Full Scan(O(n))을 하지만,

인덱스가 있으면 B-Tree를 탐색하는 Index Scan(O(log n))으로 편해진다.

Index를 사용하면 좋은 경우

WHERE절에 자주 사용되는 컬럼
ORDER BY절에 자주 사용되는 컬럼
JOIN 조건으로 사용되는 컬럼
카디널리티가 높은 컬럼

Index의 장/단점

조회 속도 대폭 향상
ORDER BY, GROUP BY 성능 개선
MIN/MAX 최적화

추가 저장 공간 필요
INSERT/UPDATE/DELETE 성능 저하
인덱스 유지 비용 발생

인덱스를 직접 적용해보기 위해 Post 엔티티를 다음과 같이 수정했다.

@Table(name = "post", indexes = {
        @Index(name = "idx_post_created_at", columnList = "created_at")
})

이 인덱스를 사용하면 목록 조회 시 정렬 속도와 날짜 범위 필터 속도도 향상된다.

테스트를 위해 explain(쿼리 성능 분석을 위한 도구)을 사용하려고 했지만, 데이터가 적은 탓에 인덱스가 있음에도 불구하고 옵티마이저가 자동으로 Full Scan을 선택했다.

rows가 적으면 인덱스를 타는 비용이 오히려 Full Scan보다 더 들 수 있어 옵티마이저가 자동으로 선택한 것이다.

데이터를 더욱 확보한 뒤에 정확한 비교를 다시 해보아야겠다!

테스트 전략

co-cherry — Mon, 11 May 2026 20:20:26 +0900

"You should write tests if you value your time.
Much better to catch a bug locally from the tests
than getting a call at 2:00 in the morning and fix it then."

— Kent C. Dodds

버그는 발견이 늦을수록 비용이 기하급수적으로 증가한다.

설계 단계 대비 프로덕션에서는 최대 100배, CrowdStrike처럼 한 줄이 80억 달러로 이어질 수도 있다.

테스트는 "만일의 보험"이 아니라 개발 속도를 높이는 투자다.

Viest + React Testing Library + MSW로 프론트엔드 테스트 전략을 완성하는 법을 알아보자.

테스트가 왜 필요할까?

테스트가 없는 코드는 단순히 "버그가 있을 수 있는 코드"가 아니라 변경할 수 없는 코드다.

기도하는 배포

우아한 형제들 기술 블로그에 나온 표현이다.

테스트 코드 없이 레거시 코드를 고치면 다음과 같은 과정을 거친다.

소스 분석하고
변경하고
수동으로 기능 확인하고
배포하고
기도한다

왜? 내가 건드린 게 어디를 망가뜨렸을지 모르니까...

상황	테스트가 없을 때	테스트가 있을 때
새 기능 추가	"이거 건드리면 뭐가 깨질까?" 전전긍긍	CI가 깨지면 바로 알림
리팩토링	무서워서 못 함 → 기술부채 누적	자유롭게 구조 개선
라이브러리 업데이트	수동 회귀 테스트 → 결국 안 함	npm update, npm test 면 끝
신규 팀원 온보딩	코드 동작을 추측만 가능	테스트 = 실행 가능한 문서

단위 테스트 VS 통합 테스트

테스트란?

프로그램이 요구사항에 맞춰 제대로 동작하는지 검증하는 행위

테스트는 범위에 따라 단위 테스트 → 통합 테스트 → E2E 테스트로 구분한다.

단일 테스트(Unit Test)

소프트웨어의 가장 작은 단위(함수, 메소드, 컴포넌트)가 의도대로 작동하는지 검증

개별 모듈의 기능 요구사항을 만족하는지 확인한다.

작은 부분만 테스트하므로 빠르게 실행
개발 초기 단계에서 버그 발견 및 수정에 효과적
레이어 단위 또는 특정 클래스 단위로 테스트

보통 프론트엔드에서는 Jest, React Testing Library 를, 백엔드에서는 JUnit을 사용한다.

통합 테스트(Integration Test)

여러 단위/컴포넌트 간의 상호작용을 테스트

개별 단위가 시스템 전체에서도 올바르게 동작하는지 확인한다.

외부 라이브러리, 데이터베이스 등 개발자가 변경할 수 없는 부분까지 포함
독립된 2개 이상의 모듈이 함께 동작할 때 테스트
모듈 간 연결에서 발생하는 에러 검증
단위 테스트보다 실행 시간이 길고 복잡함

효과적인 테스트 작성 방법

AAA 패턴 (Arrange-Act-Assert)

모든 테스트를 준비, 실행, 검증 세 부분으로 나누는 구조

단순하고 균일한 구조로 일관성을 확보할 수 있다.

준비(Arrange) 테스트 대상의 초기 상태 설정
실행(Act) 사용자 상호작용 또는 함수 호출 실행
확인(Assert) 기대한 결과가 나왔는지 검증

Given-When-Then 패턴

Given 준비 구절에 해당
When 실행 구절에 해당
Then 검증 구절에 해당

기능적으로는 AAA와 동일하나, 비개발자에게 더 읽기 쉬운 표현

BDD(Behavior-Driven Development) 스타일에서 주로 사용

언제 어떤 테스트를 사용할까?

테스팅 피라미드 (Mike Cohn)

단위 테스트 > 통합 테스트 > E2E 테스트 순으로 많이 작성
테스트 커버리지 최대화 + 시간/리소스 최소화
낮은 단계일수록 아이디어와 구현 간극이 짧아 안정화 필요

테스팅 트로피/다이아몬드 (Guillermo Rauch)

통합 테스트에 가장 큰 비중
통합 테스트 > 단위 테스트 > E2E 테스트 순
정적 테스트의 추가로 에러 사전 발견

vitest 와 React Testing Library 실습해보기

https://white-blank.tistory.com/186

vitest + React Testing Library 사용하여 테스트 케이스 만들기

해당 글에서는 vitest 와 React Testing Library 를 이용하여 테스트 케이스를 만드는 방법을 소개합니다.vitest 는 실행속도와 vite 와 통합이 간편하며, RTL 은 리액트 컴포넌트를 테스트 하기 위한 도구

white-blank.tistory.com

↑ 위 블로그 과정을 보고 따라 해보았다.

먼저 필요한 라이브러리를 설치한다.

pnpm add -D vitest jsdom @testing-library/react @testing-library/user-event @testing-library/jest-dom

그리고 vite.config.ts 를 수정한다.

globals: true 테스트 파일에서 전역 함수를 import 없이 사용할 수 있게 설정
environment: 'jsdom' 테스트 환경을 JSDOM(Node.js 환경에서 브라우저와 유사한 DOM 환경을 시뮬레이션)으로 설정
setupFiles: './src/setupTests.ts' 테스트 실행 전, 실행될 설정 파일의 경로 지정

/// <reference types="vitest" />
// https://vite.dev/config/
export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './src/setupTests.ts',
  },
})

그 다음, 위에서 설정한 setup 파일을 해당 경로에 생성한다.

import '@testing-library/jest-dom'

tsconfig.app.json 에서 types 배열에 vitest/globals와 @testing-library/jest-dom을 추가해

TypeScript가 전역 API를 인식하게 한다.

{
  "compilerOptions": {
    "types": ["vite/client", "vitest/globals", "@testing-library/jest-dom"]
  }
}

마지막으로, package.json 에 스크립트를 추가하면 설정은 완료된다.

{
  "scripts": {
    "test": "vitest",
    "test:run": "vitest run"
  }
}

테스트 파일을 작성해야 하는데 나의 경우는 MovieCard 파일에 대한 테스트를 작성했다.

파일명은 컴포넌트명.test.tsx 의 규칙으로 생성하며 컴포넌트 파일 옆에 두는 것이 일반적이다.

import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import MovieCard from './MovieCard'
import type { Movie } from '../model/types'

const baseMovie: Movie = {
  id: 1,
  title: '인터스텔라',
  overview: '우주 탐험 영화',
  poster_path: '/poster.jpg',
  release_date: '2014-11-06',
  vote_average: 8.6,
  popularity: 100,
  adult: false,
  original_language: 'en',
  original_title: 'Interstellar',
}

describe('MovieCard', () => {
  it('영화 제목이 렌더링된다', () => {
    render(<MovieCard movie={baseMovie} onClick={() => {}} />)
    expect(screen.getByText('인터스텔라')).toBeInTheDocument()
  })

  it('포스터 이미지가 렌더링된다', () => {
    render(<MovieCard movie={baseMovie} onClick={() => {}} />)
    const img = screen.getByAltText('인터스텔라')
    expect(img).toBeInTheDocument()
  })

  it('poster_path가 없으면 No Image 텍스트가 보인다', () => {
    render(<MovieCard movie={{ ...baseMovie, poster_path: null }} onClick={() => {}} />)
    expect(screen.getByText('No Image')).toBeInTheDocument()
  })

  it('adult가 true이면 19 배지가 보인다', () => {
    render(<MovieCard movie={{ ...baseMovie, adult: true }} onClick={() => {}} />)
    expect(screen.getByText('19')).toBeInTheDocument()
  })

  it('adult가 false이면 19 배지가 없다', () => {
    render(<MovieCard movie={baseMovie} onClick={() => {}} />)
    expect(screen.queryByText('19')).not.toBeInTheDocument()
  })

  it('카드 클릭 시 movie.id를 인자로 onClick이 호출된다', async () => {
    const handleClick = vi.fn()
    render(<MovieCard movie={baseMovie} onClick={handleClick} />)
    await userEvent.click(screen.getByText('인터스텔라'))
    expect(handleClick).toHaveBeenCalledWith(1)
  })

  it('예매하기 버튼이 렌더링된다', () => {
    render(<MovieCard movie={baseMovie} onClick={() => {}} />)
    expect(screen.getByRole('button', { name: '예매하기' })).toBeInTheDocument()
  })
})

pnpm test로 테스트를 실행하면 아래와 같이 테스트 결과가 나온다.

MSW(Mock Service Worker)를 활용한 API Mocking

https://mswjs.io/docs/quick-start

Quick start

Get MSW up and running in under five minutes.

mswjs.io

API Mocking

실제 백엔드 서버 없이 가짜 API 응답을 만들어내는 것

요청이 가기 전에 중간에서 가로채서 미리 만든 가짜 데이터를 응답으로 돌려준다.

백엔드가 아직 없을 때 프론트 먼저 개발 가능
테스트 할 때 실제 서버에 의존하지 않아도 됨
에러 상황, 로딩 상황 등을 마음대로 재현 가능

MSW(Mock Service Worker)

서비스 워커 기술을 활용하여 네트워크 레벨에서 API 요청을 가로채고 모킹할 수 있는 라이브러리

쉽게 말해, 실제 네트워크가 이루어지는 것처럼 프론트엔드의 응답값을 주는 라이브러리이다. (가짜 API 생성)

별도 Mocking 서버를 구축할 필요 없음
프레임워크과 라이브러리에 종속되지 않음
브라우저, Node.js 등 다양한 환경 지원
기존 코드 수정 없이 사용 가능

세팅해보기

1. MSW 설치

pnpm add -D msw

2. Service Worker 파일 생성하기

public/mockServiceWorker.js가 생성되고 package.json에 msw.workerDirectory 항목이 자동으로 추가된다.

npx msw init public/ --save

3. 가짜 데이터 파일 작성하기

src/mocks/data/ 위치에 가짜 데이터 파일을 생성한다.

실제 API가 반환값과 같은 형태의 데이터를 타입에 맞게 작성해야 한다.

나의 경우, 영화 데이터를 넣었다.

import type { Movie, MovieListResponse, MovieDetail } from '@/entities/movie/model/types'

export const mockMovies: Movie[] = [
  {
    id: 1,
    title: '인터스텔라',
    overview: '우주를 배경으로 한 SF 영화',
    poster_path: '/poster1.jpg',
    release_date: '2014-11-06',
    vote_average: 8.6,
    popularity: 100,
    adult: false,
    original_language: 'en',
    original_title: 'Interstellar',
  },
  {
    id: 2,
    title: '기생충',
    overview: '계층 간의 갈등을 다룬 한국 영화',
    poster_path: '/poster2.jpg',
    release_date: '2019-05-30',
    vote_average: 8.5,
    popularity: 90,
    adult: false,
    original_language: 'ko',
    original_title: '기생충',
  },
]

export const mockMovieListResponse: MovieListResponse = {
  page: 1,
  results: mockMovies,
  total_pages: 1,
  total_results: 2,
}

export const mockMovieDetail: MovieDetail = {
  ...mockMovies[0],
  genres: [{ id: 878, name: 'SF' }],
  runtime: 169,
  tagline: '우주의 끝에서 답을 찾다',
  status: 'Released',
  vote_count: 30000,
  backdrop_path: '/backdrop1.jpg',
}

4. 핸들러 파일 작성하기

어떤 URL로 요청이 오면 어떤 데이터를 응답할지 규칙을 정의한다.

import { http, HttpResponse } from 'msw'
import { mockMovieListResponse, mockMovieDetail } from './data/movies'

const BASE = 'https://api.themoviedb.org/3'

export const handlers = [
  http.get(`${BASE}/movie/popular`, () => {
    return HttpResponse.json(mockMovieListResponse)
  }),

  http.get(`${BASE}/movie/now_playing`, () => {
    return HttpResponse.json(mockMovieListResponse)
  }),

  http.get(`${BASE}/movie/top_rated`, () => {
    return HttpResponse.json(mockMovieListResponse)
  }),

  http.get(`${BASE}/movie/upcoming`, () => {
    return HttpResponse.json(mockMovieListResponse)
  }),

  http.get(`${BASE}/movie/:movieId`, () => {
    return HttpResponse.json(mockMovieDetail)
  }),
]

5. 브라우저용 설정 파일 생성하기

브라우저는 테스트와 달리, Service Worker를 사용한다.

[React 앱] → fetch 요청 → [Service Worker가 가로챔] → 가짜 응답 반환 의 순서로 실행된다.

import { setupWorker } from 'msw/browser'
import { handlers } from './handlers'

export const worker = setupWorker(...handlers)

6. 테스트용 설정 파일 생성하기

테스트 환경(Vitest)은 브라우저가 아닌 Node.js에서 실행된다.

Node.js에는 Service Worker가 없으므로 MSW가 대신 http 모듈을 가로채는 방식으로 작동된다.

[테스트 코드] → fetch 요청 → [MSW Node 서버가 가로챔] → 가짜 응답 반환 의 순서로 실행된다

import { setupServer } from 'msw/node'
import { handlers } from './handlers'

export const server = setupServer(...handlers)

7. 테스트 환경에 MSW 연결하기

이전에 설정한 setup 파일에 추가적으로 설정한다.

beforeAll(() => server.listen()) 테스트 시작 전 서버 켜기
afterEach(() => server.resetHandlers()) 각 테스트 후 핸들러 초기화
afterAll(() => server.close()) 테스트 끝나면 서버 끄기

import '@testing-library/jest-dom'
import { server } from './mocks/server'

beforeAll(() => server.listen())
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

8. 앱 진입점에 MSW 연결하기

main.tsx 에서 개발 환경에서만 MSW가 켜지도록 enableMocking()으로 감싼다.

onUnhandledRequest: 'bypass' mock 등록 안 한 요청은 실제 서버로 그냥 통과시킨다.

async function enableMocking() {
  if (import.meta.env.DEV) {
    const { worker } = await import('./mocks/browser')
    return worker.start({ onUnhandledRequest: 'bypass' })
  }
}

enableMocking().then(() => {
  createRoot(document.getElementById('root')!).render(...)
})

pnpm dev 를 통해 실행하면, 이렇게 설정한 가짜 데이터가 응답으로 나오는 것을 볼 수 있다.

https://techblog.woowahan.com/2613/

테스트 코드 없이 레거시 코드를 다 감수하시겠습니까? | 우아한형제들 기술블로그

부서 이동을 하다 2018년 말미, 결제/정산 파트에서 주문중계 파트로 부서 이동하게 되었습니다. 인사 발령을 받고 나서 팀 이동을 하게 되면 누구나 직면하게 되는 상황이 발생하는데요. 그것은

techblog.woowahan.com

https://velog.io/@leeseonseonje/%EB%8B%A8%EC%9C%84%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B5%AC%EC%A1%B0

단위 테스트 AAA 패턴

AAA 패턴 AAA 패턴은 각 테스트를 준비(arrange), 실행(act), 검증(assert)이라는 세부분으로 나눌 수 있다. 모든 테스트가 단순하고 균일한 구조를 갖는데 도움이 된다. (일관성) 테스트를 쉽게 읽고, 이

velog.io

https://velog.io/@antisdun/%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8%EC%99%80-%ED%86%B5%ED%95%A9-%ED%85%8C%EC%8A%A4%ED%8A%B8

단위 테스트와 통합 테스트

단위 테스트 단위 테스트는 소프트웨어 개발 과정에서 가장 작은 단위의 코드, 예를 들어 각 컴포넌트 혹은 함수가 기대한 대로 작동하며 그 기능 요구사하을 만족시키는지 검증하는 것이다. 프

velog.io

https://velog.io/@xeropise1/%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%9E%80-%EB%8B%A8%EC%9C%84%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%86%B5%ED%95%A9%ED%85%8C%EC%8A%A4%ED%8A%B8-E2E%ED%85%8C%EC%8A%A4%ED%8A%B8

테스트란? (단위테스트, 통합테스트, E2E테스트)

테스트란 소프트웨어의 관점에서 정의하면프로그램을 실행하는 경우에 요구 사항에 맞춰 동작하는지 검증하는 행위 라고 할 수 있다.테스트에는 다양한 종류가 있는데, 보통 범위에 따라서 단

velog.io

https://velog.io/@sujeong_dev/MSWMock-Service-Worker%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-API-mocking

MSW(Mock Service Worker)를 이용한 API mocking

프론트 개발을 하던 와중에 API 개발속도와 맞지 않아 동시에 개발이 진행되게 되어 /public경로에 실제 API response의 json key-value값을 맞춰서 mock data를 만들어 mocking하는 식으로 UI를 만들었다. 그러

velog.io

https://tech.ktcloud.com/entry/MSW%EB%A1%9C-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EA%B0%9C%EC%84%A0%ED%95%98%EA%B8%B0-API-Mocking

MSW로 프론트엔드 개발 프로세스 개선하기 : API Mocking

[kt cloud 플랫폼Innovation팀 송재희 님] MSW로 프론트엔드 개발 프로세스 개선하기 : API Mocking 프론트엔드 개발자라면, 종종 백엔드 API가 준비되기 전까지 대기해야 하는 상황을 경험해 보셨을 겁니

tech.ktcloud.com

게시글 목록 API 구현하기 (페이징 · 검색, N+1)

co-cherry — Thu, 7 May 2026 01:28:26 +0900

페이징

게시글 목록 조회 API를 구현하면 이와 같은 형태로 작성하게 된다.

List<Post> posts = postRepository.findAll();

로컬에서 데이터 10개 정도로 테스트할 때는 문제 없이 잘 동작하지만, 게시글이 10,000개 정도 있다고 가정해보자.

이 API를 호출하는 순간,

데이터베이스는 10,000개의 행을 읽어서 메모리에 올린다
애플리케이션은 10,000개의 Post 객체를 생성한다
네트워크를 통해 수 MB의 JSON 데이터가 전송된다
프론트엔드는 10,000개의 게시글을 한꺼번에 렌더링하려 시도한다

우리의 서버 메모리는 낭비되고 응답은 느려지며 멈춘 듯한 화면을 보게 될 것이다.

이 문제에 대한 해결책이 Paging이다.

'한번에 모든 데이터를 보여 줄 필요가 없다면 필요한 만큼만 잘라서 보여주자' 가 핵심 아이디어이다.

Spring Data JPA 페이징의 구현

Spring Data JPA에 페이징 기능이 내장되어 있으므로 이를 이용하면 된다.

먼저, 페이징 정보를 담은 DTO를 생성한다.

응답 시, 표시할 게시글들의 데이터 목록들을 List로 묶고 Page<T> 에서 제공하는 페이지 메타 정보들도 함께 리턴한다.

@Getter
@AllArgsConstructor
public class PostListResponseDto {
    private List<PostDetailResponseDto> posts; // 페이지 데이터 목록

    private Integer currentPage; // 현재 페이지 번호 (0부터 시작)
    private Integer totalPages; // 전체 페이지 수
    private Long totalElements; // 전체 데이터 수
    private Integer listSize; // 이번 페이지에 실제 담긴 데이터 수
    private Boolean isFirst; // 첫번째 페이지 여부
    private Boolean isLast; // 마지막 페이지 여부
    private Boolean hasNext; // 다음 페이지 존재 여부
    private Boolean hasPrevious; // 이전 페이지 존재 여부

    public static PostListResponseDto from(Page<Post> page) {
        List<PostDetailResponseDto> posts =  page.getContent().stream()
                .map(post -> new PostDetailResponseDto(
                        post.getId(),
                        post.getTitle(),
                        post.getContent(),
                        post.getUser().getNickname(),
                        post.getCreatedAt()
                )).toList();

        return new PostListResponseDto(
                posts,
                page.getNumber(),           // currentPage
                page.getTotalPages(),        // totalPages
                page.getTotalElements(),     // totalElements
                page.getNumberOfElements(), // listSize
                page.isFirst(),             // isFirst
                page.isLast(),              // isLast
                page.hasNext(),             // hasNext
                page.hasPrevious()          // hasPrevious
        );
    }
}

Page<T>

Spring Data JPA가 제공하는 페이징 결과를 담는 컨테이너 객체

제공하는 메서드 (Count 쿼리 결과)

메서드	반환 타입	설명
getTotalElements()	long	조건에 맞는 전체 데이터 수
getTotalPages()	int	전체 페이지 수

제공하는 메서드 (이번 페이지의 정보)

메서드	반환 타입	설명
getContent()	List<T>	이번 페이지의 실제 데이터 목록
getNumber()	int	현재 페이지 번호 (0부터 시작)
getSize()	int	요청한 페이지의 크기
getNumberOfElements()	int	이번 페이지에 실제로 담긴 데이터 수
hasContent()	boolean	데이터가 하나라도 있는가
isFirst()	boolean	첫번째 페이지인가
isLast()	boolean	마지막 페이지인가
hasNext()	boolean	다음 페이지가 존재하는가
hasPrevious()	boolean	이전 페이지가 존재하는가
getSort()	Sort	적용된 정렬 정보

Q. getSize() 와 getNumberOfElements() 의 차이는?

getSize()는 요청한 페이지 크기이고, getNumberOfElements()는 실제로 담긴 데이터 수다.

전체 데이터가 27개이고 size=10일 때,

마지막 페이지(page=2)는 요청한 크기는 10이지만, 실제로 남은 데이터가 7개이므로 두 값이 달라진다.

page=0 → getSize()=10, getNumberOfElements()=10
page=1 → getSize()=10, getNumberOfElements()=10
page=2 → getSize()=10, getNumberOfElements()=7  ← 마지막 페이지

그 다음, Service 로직을 작성한다.

@Transactional(readOnly = true)
    public PostListResponseDto getPosts(int page, int size, String sortBy) {
        Pageable pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, sortBy));
        Page<Post> postPage = postRepository.findAll(pageable);
        return PostListResponseDto.from(postPage);
    }

Pageable

페이지 요청 정보를 담는 인터페이스, PageRequest.of()로 구현체를 만들어 사용

'몇 번째 페이지(page), 몇 개씩(size), 어떤 순서로(sort)'를 묶어서 Repository에 넘겨 주는 역할

page 몇 번째 페이지(0부터 시작)
size 한 페이지에 몇 개
Sort.by(DESC | ASC, sortBy) 정렬 조건 객체 생성, sortBy는 정렬의 기준이 될 컬럼명

pageable 조건에 맞게 DB에서 조회를 해 Spring Data JPA가 LIMIT, OFFSET, ORDER BY SQL을 자동으로 생성 후 결과를 DTO로 변환해 리턴한다.

마지막으로 Controller를 작성한다.

size와 sortBy를 외부에서 받아오므로 값이 없을 것을 대비해 defaultValue를 설정했다.

@Operation(summary = "게시글 목록 조회", description = "페이징/정렬을 지원합니다.")
    @GetMapping("/lists")
    public ApiResponse<PostListResponseDto> getPosts(
            @RequestParam(defaultValue = "0") int page,
            @RequestParam(defaultValue = "10") int size,
            @RequestParam(defaultValue = "createdAt") String sortBy
    ) {
        return ApiResponse.onSuccess(GeneralSuccessCode.OK, postService.getPosts(page, size, sortBy));
    }

코드를 실행해보면 이와 같은 응답을 받아볼 수 있다.

동적 검색 조건 처리(Keyword, 날짜 범위)

동적 쿼리

실행 시점에 조건에 따라 WHERE 절이 동적으로 구성되는 쿼리

구현 방법

방식	장점	단점
JPQL	간단한 쿼리에 적합	문자열 기반, 컴파일 체크 불가
Specification	표준 JPA 스펙	코드 가독성 떨어짐
QueryDSL	타입 안전, 직관적	초기 설정 필요

이번에는 JPQL과 QueryDSL로 구현하고 비교해보겠다.

JPQL(Java Persistence Query Language)

SQL을 추상화한 객체 지향 쿼리 언어

테이블이 아닌 엔티티 객체를 대상으로 쿼리 작성
SQL과 문법이 유사하나 DB 독립적

-- SQL (테이블 기준)
SELECT * FROM post WHERE title LIKE '%Spring%'

-- JPQL (엔티티 기준)
SELECT p FROM Post p WHERE p.title LIKE '%Spring%'

JPQL을 통해 구현하기 위해 PostRepository에 아래와 같이 searchPosts 메서드를 작성하자.

@Query 직접 쿼리를 작성할 때 사용하는 어노테이션
value 실제 데이터를 가져오는 쿼리, SQL 대신 JPQL으로 사용
- :keyword 파라미터 바인딩 자리 표시자, @Param("keyword")로 연결된 실제 값이 런타임에 삽입
countQuery page 반환 시, 전체 데이터 수를 구하기 위한 별도 쿼리

public interface PostRepository extends JpaRepository<Post, Long> {
    @Query(
            value = "SELECT p FROM Post p JOIN FETCH p.user " +
                    "WHERE (:keyword IS NULL OR p.title LIKE %:keyword% OR p.content LIKE %:keyword%) " +
                    "AND (:startDate IS NULL OR p.createdAt >= :startDate) " +
                    "AND (:endDate IS NULL OR p.createdAt <= :endDate)",
            countQuery = "SELECT COUNT(p) FROM Post p " +
                    "WHERE (:keyword IS NULL OR p.title LIKE %:keyword% OR p.content LIKE %:keyword%) " +
                    "AND (:startDate IS NULL OR p.createdAt >= :startDate) " +
                    "AND (:endDate IS NULL OR p.createdAt <= :endDate)"
    )
    Page<Post> searchPosts(
            @Param("keyword") String keyword,
            @Param("startDate") LocalDateTime startDate,
            @Param("endDate") LocalDateTime endDate,
            Pageable pageable
    );
}

다음, 위에서 작성한 서비스를 keyword와 date 파라미터를 추가해 검색 조건을 추가하자.

이전에는 findAll()로 전체 조회하던 것을 keyword, date 조건을 추가해 searchPosts 메서드를 이용해 조회하는 것을 볼 수 있다.

@Transactional(readOnly = true)
    public PostListResponseDto getPosts(int page, int size, String sortBy,
                                        String keyword,
                                        LocalDateTime startDate, LocalDateTime endDate) {
        Pageable pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, sortBy));
        Page<Post> postPage = postRepository.searchPosts(keyword, startDate, endDate, pageable);
        return PostListResponseDto.from(postPage);
    }

마지막으로 컨트롤러에도 똑같이 조건을 넣어 수정한다.

@Operation(summary = "게시글 목록 조회", description = "페이징/정렬을 지원합니다.")
    @GetMapping("/lists")
    public ApiResponse<PostListResponseDto> getPosts(
            @RequestParam(defaultValue = "0") int page,
            @RequestParam(defaultValue = "10") int size,
            @RequestParam(defaultValue = "createdAt") String sortBy,
            @RequestParam(required = false) String keyword,
            @RequestParam(required = false) LocalDateTime startDate,
            @RequestParam(required = false) LocalDateTime endDate
    ) {
        return ApiResponse.onSuccess(GeneralSuccessCode.OK,
                postService.getPosts(page, size, sortBy, keyword, startDate, endDate));
    }

테스트를 해보면, 먼저 조건 없이 조회해보자. 전체 글이 조회되는 것을 볼 수 있다.

그 다음, "동적" 이라는 키워드를 넣고 조회해보자.

Curl 부분에 keyword=%EB%8F%99%EC%A0%81 가 추가된 것을 볼 수 있다.

마지막으로, 4월 만을 기준으로 조회해보자.

Curl 부분에 startDate=2026-04-01T00%3A00%3A00&endDate=2026-05-01T00%3A00%3A00 이 추가된 것을 볼 수 있다.

QueryDSL

타입 안전한(Type-Safe) 쿼리 빌더

Java 코드로 쿼리를 작성해 컴파일 시점에 오류를 검출한다.
Q 클래스 엔티티를 표현하는 Java 클래스(쿼리용), 엔티티 meta 모델을 자동 생성

먼저, QueryDSL을 사용하려면 의존성을 추가해줘야 한다.

나의 경우, Spring Boot 3.5.11 버전을 사용하므로 이에 맞는 의존성을 추가했다. 자신의 버전에 유의해서 사용하자.

의존성 추가 후, 빌드하면 아래와 같이 Q 클래스가 생긴 것을 볼 수 있다.

그 다음, QueryslConfig 파일을 생성해 아래와 같이 작성한다.

@Configuration
public class QueryDslConfig {
    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

EntityManager

JPA와 DB가 소통할 때 사용하는 핵심 객체

JPAQueryFactory

EntityManager를 받아 QueryDSL 문법으로 쿼리를 만들고 실행할 수 있게 해주는 객체

// JPAQueryFactory 없이 (JPQL 방식)
@Query("SELECT p FROM Post p WHERE p.title LIKE %:keyword%")

// JPAQueryFactory 있으면 (QueryDSL 방식)
queryFactory
    .selectFrom(post)
    .where(post.title.contains(keyword))
    .fetch();

그 다음, PostRepositoryCustom 인터페이스를 생성해 QueryDSL 구현 코드를 생성한다.

기존 CRUD는 JpaRepsitory에서, 복잡한 QueryDSL 쿼리는 PostRepositoryCustom에서 하도록 분리하기 위해 따로 선언한다.

public interface PostRepositoryCustom {

    Page<Post> searchPostsQueryDsl(
            String keyword,
            LocalDateTime startDate,
            LocalDateTime endDate,
            Pageable pageable
    );
}

PostRepository에 PostRepositoryCustom 인터페이스 상속을 추가한다. (다중 상속 가능)

public interface PostRepository extends JpaRepository<Post, Long>, PostRepositoryCustom {

그 다음, 인터페이스의 구현체인 PostRepositoryImpl을 작성한다.

goe(Greater Or Equal) >=, QueryDSL의 비교 메서드
loe(Less Or Equal) <=, QueryDSL의 비교 메서드
contains QueryDSL의 문자열 검색 메서드

@RequiredArgsConstructor
public class PostRepositoryImpl implements PostRepositoryCustom {

    private final JPAQueryFactory queryFactory;
    private final QPost post = QPost.post;

    @Override
    public Page<Post> searchPostsQueryDsl(String keyword, LocalDateTime startDate,
                                          LocalDateTime endDate, Pageable pageable) {
        BooleanBuilder builder = new BooleanBuilder();

        if (keyword != null) {
            builder.and(post.title.contains(keyword)
                    .or(post.content.contains(keyword)));
        }
        if (startDate != null) {
            builder.and(post.createdAt.goe(startDate));
        }
        if (endDate != null) {
            builder.and(post.createdAt.loe(endDate));
        }

        List<Post> posts = queryFactory
                .selectFrom(post)
                .join(post.user).fetchJoin()
                .where(builder)
                .orderBy(post.createdAt.desc())
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .fetch();

        Long total = queryFactory
                .select(post.count())
                .from(post)
                .where(builder)
                .fetchOne();

        return new PageImpl<>(posts, pageable, total);
    }
}

BooleanBuilder

조건을 동적으로 조합하는 객체

if 문으로 조건이 있을 때만 .and() 로 추가

쿼리 조립 부분

SQL을 문자열로 쓰지 않고 메서드 체이닝으로 조립하는 것이 QueryDSL의 핵심적인 특징이다.

queryFactory
    .selectFrom(post)       // SELECT * FROM post
    .join(post.user).fetchJoin()  // JOIN FETCH (N+1 방지)
    .where(builder)         // 동적 조건 적용
    .orderBy(post.createdAt.desc())  // ORDER BY
    .offset(pageable.getOffset())    // 몇 번째부터
    .limit(pageable.getPageSize())   // 몇 개까지
    .fetch();               // 실행 후 List로 반환

최종적으로 목록, 페이지 정보, 전체 수를 합쳐 Page<Post>로 만들어 반환한다.

마지막으로 서비스와 컨트롤러에 searchPostsQueryDsl을 사용하는 방식으로 메서드와 엔드 포인트를 추가한다.

@Transactional(readOnly = true)
public PostListResponseDto getPostsQueryDsl(int page, int size, String sortBy,
                                            String keyword,
                                            LocalDateTime startDate, LocalDateTime endDate) {
    Pageable pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, sortBy));
    Page<Post> postPage = postRepository.searchPostsQueryDsl(keyword, startDate, endDate, pageable);
    return PostListResponseDto.from(postPage);
}

@GetMapping("/lists/querydsl")
public ApiResponse<PostListResponseDto> getPostsQueryDsl(
        @RequestParam(defaultValue = "0") int page,
        @RequestParam(defaultValue = "10") int size,
        @RequestParam(defaultValue = "createdAt") String sortBy,
        @RequestParam(required = false) String keyword,
        @RequestParam(required = false) LocalDateTime startDate,
        @RequestParam(required = false) LocalDateTime endDate
) {
    return ApiResponse.onSuccess(GeneralSuccessCode.OK,
            postService.getPostsQueryDsl(page, size, sortBy, keyword, startDate, endDate));
}

전체 조회부터 테스트 해보자.

그 다음, "동적" 이라는 키워드를 넣고 조회해보자.

Curl 부분에 keyword=%EB%8F%99%EC%A0%81 가 추가된 것을 볼 수 있다.

마지막으로, 4월 만을 기준으로 조회해보자.

Curl 부분에 startDate=2026-04-01T00%3A00%3A00&endDate=2026-05-01T00%3A00%3A00 이 추가된 것을 볼 수 있다.

얼핏 보면 이전과 같아 보이지만, Curl 부분을 보면 이전 API가 아닌 querydsl API임을 볼 수 있다.

JPQL VS QueryDSL

검색 조건 처리 (JPQL) - 조건을 문자열로 작성

@Query(
    value = "SELECT p FROM Post p JOIN FETCH p.user " +
            "WHERE (:keyword IS NULL OR p.title LIKE %:keyword% OR p.content LIKE %:keyword%) " +
            "AND (:startDate IS NULL OR p.createdAt >= :startDate) " +
            "AND (:endDate IS NULL OR p.createdAt <= :endDate)",
    countQuery = "SELECT COUNT(p) FROM Post p " +
            "WHERE (:keyword IS NULL OR p.title LIKE %:keyword% OR p.content LIKE %:keyword%) " +
            "AND (:startDate IS NULL OR p.createdAt >= :startDate) " +
            "AND (:endDate IS NULL OR p.createdAt <= :endDate)"
)
Page<Post> searchPosts(@Param("keyword") String keyword, ...);

검색 조건 처리 (QueryDSL) - 조건을 코드로 조합

BooleanBuilder builder = new BooleanBuilder();

if (keyword != null) {
    builder.and(post.title.contains(keyword)
            .or(post.content.contains(keyword)));
}
if (startDate != null) {
    builder.and(post.createdAt.goe(startDate));
}
if (endDate != null) {
    builder.and(post.createdAt.loe(endDate));
}

List<Post> posts = queryFactory
        .selectFrom(post)
        .join(post.user).fetchJoin()
        .where(builder)
        .orderBy(post.createdAt.desc())
        .offset(pageable.getOffset())
        .limit(pageable.getPageSize())
        .fetch();

Long total = queryFactory
        .select(post.count())
        .from(post)
        .where(builder)
        .fetchOne();

return new PageImpl<>(posts, pageable, total);

	JPQL	QueryDSL
작성 방식	문자열로 작성	자바 코드로 작성
오타 발견 시점	실행해야 알 수 있음	IDE가 바로 알려줌
동적 조건 처리	:param IS NULL 트릭 사용	if문으로 자연스럽게 추가/제거
가독성	조건이 늘수록 문자열이 길어짐	조건이 늘어도 코드가 깔끔함
초기 설정	별도 설정 없음	의존성, Q클래스, 빈 등록 필요
적합한 상황	조건이 단순한 경우	조건이 많고 복잡한 경우

N + 1 문제

1번의 쿼리로 N개의 데이터를 조회했을 때, 각 데이터에 연관된 데이터를 가져오기 위해 추가로 N번의 쿼리가 실행되는 문제

만약, 게시글 100개를 조회하면 총 101번의 쿼리가 실행된다.

발생 원인

JPA의 기본 Fetch 전략이 LAZY(지연 로딩)이기 때문이다.

LAZY 로딩은 처음에는 연관 객체를 가져오지 않다가, 실제로 접근하는 순간 DB에 쿼리를 날린다.

*그렇다고 해서 EAGER 을 사용하더라도 똑같이 N+1이 발생한다. "언제" 쿼리를 날리느냐의 차이일 뿐...

@ManyToOne(fetch = FetchType.LAZY)
private User user;

내가 작성한 코드 중에 작성자의 닉네임을 가져오는 코드가 있는데 이를 보면 N+1의 문제가 발생함을 알 수 있다.

postRepository.findAll() → SELECT * FROM post 로 Post 전체 조회 (1)
.map(post -> post.getUser() → 각 Post마다 SELECT * FROM users WHERE user_id=? 조회 (N)
.getNickname())

postRepository.findAll()      
    .stream()
    .map(post -> post.getUser() 
                .getNickname())

해결 방안

1. Fetch Join (outer join fetching)

SQL의 JOIN을 사용해 연관 데이터를 처음부터 한 번에 가져오는 방법

N+1이 발생하는 이유는 post를 먼저 가져오고, user를 나중에 개별 조회하기 때문이다.

따라서, Fetch Join은 처음부터 post와 user를 JOIN해서 한 번의 쿼리로 가져오기 때문에 추가 쿼리가 발생하지 않는다.

SELECT * FROM post 
JOIN users ON users.user_id = post.user_id

@Query("SELECT p FROM Post p JOIN FETCH p.user")
List<Post> findAllWithUser();

2. Batch Fetching

연관 데이터를 개별 쿼리가 아닌 IN절로 묶어 한 번에 가져오는 방법

기존에는 user를 한 명씩 개별 조회했다면, Batch Fetching은 필요한 user의 id를 모아서 IN절로 한 번에 조회한다.

SELECT * FROM users WHERE user_id IN (1, 2, 3, ...)

batch_fetch_size: 100은 한 번에 최대 100개의 id를 IN절에 묶어 조회한다는 의미이다.

데이터가 250개라면 100개씩 나눠 총 3번에 걸쳐 실행된다.

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100

3. Subselect Fetching

연관 데이터를 서브 쿼리로 한 번에 가져오는 방법

IN절에 직접 id를 넣는 대신, 처음 실행한 쿼리를 서브 쿼리로 재사용한다.

처음 post를 조회한 쿼리를 서브 쿼리로 재활용해 관련된 user를 한 번에 가져오기 때문에 추가 쿼리가 1번만 발생한다.

SELECT * FROM post
SELECT * FROM users 
WHERE user_id IN (SELECT user_id FROM post)

엔티티에 직접 SUBSELECT를 설정한다.

size 제한 없이 전체를 한 번에 처리하지만, 서브 쿼리가 복잡할수록 성능이 떨어질 수 있다는 단점이 있다.

@ManyToOne
@Fetch(FetchMode.SUBSELECT)
private User user;

https://itconquest.tistory.com/entry/Spring-Boot-%ED%8E%98%EC%9D%B4%EC%A7%95-%EA%B8%B0%EB%8A%A5-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0

[Spring Boot] 페이징 기능 구현하기

페이징 구현하기스프링 부트에서 페이징(Paging)을 구현하는 방법은 Spring Data JPA의 Pageable과 Page 인터페이스를 활용하는 것이다. Page 인터페이스를 사용하면 페이징 정보를 쉽게 가져올 수 있다. g

itconquest.tistory.com

https://velog.io/@joonghyun/Springboot-QueryDSL%EC%9D%98-%EC%9D%B4%ED%95%B4%EC%99%80-QueryDSL%EB%A1%9C-%EB%8F%99%EC%A0%81%EC%BF%BC%EB%A6%AC-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0

[Springboot] QueryDSL의 이해와 동적쿼리 적용

Spring Data JPA의 가장 큰 장점은 간편함입니다. 기본적인 CRUD 메서드, 쿼리 메서드를 사용해서 엔티티의 필드와 연관된 데이터를 쉽게 가져올 수 있습니다. >기본적인 CRUD 메서드는 굳이 Repository에

velog.io

https://ksh-coding.tistory.com/146#0.%20%EB%93%A4%EC%96%B4%EA%B0%80%EA%B8%B0%20%EC%A0%84-1

[JPA] JPA N+1 문제 및 근본적인 원인에 대한 개인적인 고찰

0. 들어가기 전JPA를 사용하면서 발생하는 N+1 문제는 널리 알려져 있고, JPA를 사용하다보면 제법 자주 만나게 됩니다.그래서 N+1 문제를 다룬 블로그나 다른 레퍼런스들이 상당히 많습니다.저 또

ksh-coding.tistory.com

[SWEA] 26504. MST 만들기

co-cherry — Wed, 6 May 2026 15:44:41 +0900

https://swexpertacademy.com/main/code/problem/problemDetail.do?contestProbId=AZz7FPpqAUnHBIRj&categoryId=AZz7FPpqAUnHBIRj&categoryType=CODE&problemTitle=&orderBy=FIRST_REG_DATETIME&selectCodeLang=ALL&select-1=&pageSize=10&pageIndex=1

SW Expert Academy

SW 프로그래밍 역량 강화에 도움이 되는 다양한 학습 컨텐츠를 확인하세요!

swexpertacademy.com

T = int(input())

for _ in range(T):
    N = int(input())
    costs = list(map(int, input().split()))
    
    costs.sort()
    
    min_mst = sum(costs[:N-1])
    
    max_mst = 0
    for i in range(N-1):
        index = (i * (i + 1)) // 2
        max_mst += costs[index]
    
    print(min_mst, max_mst)

MST(Minimum Spanning Tree, 최소 신장 트리)

Spanning Tree(신장 트리)

그래프의 모든 정점을 포함하면서, 사이클이 없는 부분 그래프

간선의 수 = 정점의 수 - 1

MST(Minimum Spanning Tree, 최소 신장 트리)

가능한 모든 신장 트리 중에서 간선 가중치의 합이 최소인 트리

최소 비용

가중치를 오름차순으로 정렬 후, 간선의 개수인 n-1 개만큼 선택하면 된다.

Star 구조로 배치한다고 생각하면 쉽다.

최대 비용

정점을 추가할 때마다 이전 정점들 사이 간선에 작은 가중치를 배치해 사이클로 건너뛰게 만든다.

말이 어려운데, 그림으로 표현해보면,

3개의 노드가 2개의 간선으로 연결된 상황에서 4번째 노드를 추가하려 할 때, 최소 비용처럼 계산하지 않고

그림과 같이 최대한 사이클을 형성해 작은 가중치들을 제거하는 것이 목표이다.

만약, 노드의 개수가 4개가 아닌 5개라고 가정한다면, 아래와 같은 모양이 나타날 것이다.

그림과 같이 정점을 순차적으로 추가하면서 이전 정점들 사이에 작은 가중치를 배치하고 사이클을 형성해 건너뛰게 만드는 것이다.

지금까지의 간선 패턴을 보면 정점을 하나씩 추가할 때마다 이와 같은 패턴을 보이는데,

i=0 (1번째 간선): 
  - 사용 가능한 간선 범위: 0개
  - 인덱스 = 0

i=1 (2번째 간선):
  - 사용 가능한 간선 범위: 0~1 (2개)
  - 인덱스 = 1

i=2 (3번째 간선):
  - 사용 가능한 간선 범위: 0~3 (4개)
  - 하지만 0,1은 이미 썼고, 2는 사이클
  - 인덱스 = 3

i=3 (4번째 간선):
  - 사용 가능한 간선 범위: 0~6 (7개)
  - 하지만 0,1,3은 이미 썼고, 2,4,5는 사이클
  - 인덱스 = 6

이를 공식화하면 index = i * (i + 1) // 2 로 나타낼 수 있다.

따라서, i가 증가할 때마다 해당 인덱스 값을 더해주면 된다.

문제 풀이로 아래 블로그의 도움을 많이 받았다. ↓

https://positecoding.tistory.com/127

SWEA 26504. MST 만들기

N개의 노드에 대해서 방향성 없는 완전 그래프에서 N(N-1)/2개의 간선의 가중치만 주어질 때 MST의 최소 비용과 최대비용을 구하는 문제이다. 최소 비용은 노드들을 연결할 때 가중치가 작은 간선

positecoding.tistory.com

[SWEA] 372. 가능한 시험 점수

co-cherry — Wed, 6 May 2026 01:14:13 +0900

https://swexpertacademy.com/main/code/problem/problemDetail.do?contestProbId=AWHPkqBqAEsDFAUn

SW Expert Academy

SW 프로그래밍 역량 강화에 도움이 되는 다양한 학습 컨텐츠를 확인하세요!

swexpertacademy.com

T = int(input())

for test_case in range(1, T + 1):
    n = int(input()) 
    scores = list(map(int, input().split()))  
    
    possible = {0} 
    
    for score in scores: 
        new_scores = set()
        
        for prev_score in possible:
        	new_scores.add(prev_score + score)
            
        possible = possible | new_scores
        
    print(f"#{test_case} {len(possible)}")

이 문제는 DP(동적 프로그래밍)로 해결할 수 있다.

DP[k]를 "k개 문제로 만들 수 있는 점수 집합"이라고 정의하면,

DP[k+1]은 다음 두 가지 경우를 합친 것이다:

DP[k+1] = DP[k] ∪ {p + score[k+1] | p ∈ DP[k]}

1) (k+1)번째 문제를 틀린 경우 → DP[k] 그대로
2) (k+1)번째 문제를 맞춘 경우 → DP[k]의 각 점수에 배점을 더함

같은 점수를 여러 방법으로 만들 수 있으므로, 중복을 자동으로 제거하는 SET 자료구조를 사용했다.

폴더 구조와 아키텍처: 프로젝트 구조 개선

co-cherry — Sun, 3 May 2026 22:48:40 +0900

나의 프로젝트 구조

React 프로젝트를 처음 시작할 때, 파일 구조 같은 건 신경 쓰지 않았다.

기능 구현에만 중점을 두고, '일단 되게 만들자'가 목표였으니까.

하지만 프로젝트가 커지면서 기존 파일들조차 찾기 힘들어지는 경우가 많았고,

기능을 한번 추가하려고 하면 components, hooks, utils, api 폴더를 전부 뒤져야 했다.

관련 파일이 여러 폴더에 흩어져 있으니 수정할 때마다 탐색기를 끝없이 스크롤 했다.

팀 프로젝트를 해보면서 팀원마다 각자 본인만의 기준으로 파일을 배치해 팀원들의 코드를 찾기 힘들 때도 많았다.

파일을 빨리 찾거나 추가할 수 있으며, 누가 보더라도 직관적으로 이해되는 프로젝트 구조를 만들 수 있을까?

FSD(Feature-Sliced Design) Architecture

프론트엔드 애플리케이션을 구조화하는 아키텍처 방법론

애플리케이션을 기능 단위로 묶어 프로젝트를 더 이해하기 쉽고 구조적으로 만들어, 규모가 커져도 유지보수가 쉽다.

src/
├── features/
│   ├── send-message/    // 메시지 보내기 기능만
│   ├── edit-message/    // 메시지 수정 기능만
│   └── user-search/     // 사용자 검색 기능만
├── entities/
│   ├── message/         // 메시지 엔티티
│   └── user/            // 유저 엔티티
└── shared/
    └── ui/              // 공통 UI

FSD의 3가지 핵심 구조

FSD는 Layers(레이어) → Slices(슬라이스) → Segments(세그먼트) 3단계로 구성된다.

프로젝트 형태로 보면 이와 같다.

  features (레이어)
    send-message (슬라이스)
      ui (세그먼트)
      └── MessageInput.tsx
      model (세그먼트)
      └── useSendMessage.ts
      api (세그먼트)
      └── sendMessageApi.ts

Layers: 표준화된 7개 계층

현재 processes 레이어가 사용되지 않으므로 6개의 레이어만이 사용된다.

레이어	역할	예시
app	앱 실행에 필요한 전역 설정	라우터, 프로바이더, 전역 스타일
pages	라우트 페이지	HomePage, ArticlePage
widgets	페이지를 구성하는 큰 UI 블록	Header, Sidebar, Footer
features	사용자가 할 수 있는 행동/기능	좋아요 누르기, 댓글 작성, 로그인
entities	비즈니스 엔티티	User, Post, Comment, Message
shared	재사용 가능한 공통 코드	UI 컴포넌트, utils, API 클라이언트

Slices: 기능 단위 분리

각 레이어 안에서 기능/도메인 별로 나눈 폴더

features/              // 레이어
├── send-message/      // 슬라이스 1
├── edit-message/      // 슬라이스 2
└── delete-message/    // 슬라이스 3

entities/              // 레이어
├── user/              // 슬라이스 1
├── message/           // 슬라이스 2
└── chatroom/          // 슬라이스 3

슬라이스 이름은 자유롭게 선택 가능
같은 레이어의 슬라이스끼리 서로 참조 불가

Segments: 기술적 분류

슬라이스 안에서 코드의 목적별로 나눈 폴더

세그먼트	용도	예시
ui/	React 컴포넌트, 스타일	MessageInput.tsx, Button.module.css
model/	상태 관리, 비즈니스 로직, 타입	useMessageStore.ts, types.ts
api/	서버 통신 함수	fetchMessages.ts, sendMessage.ts
lib/	슬라이스 내부 헬퍼 함수	formatDate.ts, validate.ts
config/	설정, 상수	constants.ts, endpoints.ts

features/send-message/
├── ui/
│   └── MessageInput.tsx       // 메시지 입력 컴포넌트
├── model/
│   ├── useSendMessage.ts      // 메시지 전송 로직
│   └── types.ts               // 타입 정의
├── api/
│   └── sendMessageApi.ts      // API 호출
└── index.ts                   // Public API

의존성 방향 규칙(단방향 의존성): 각 레이어는 자기보다 아래에 있는 레이어만 참조(import) 할 수 있다.

하위 레이어는 재사용 가능하게 독립적으로 유지
순환 참조(Circular Dependency) 방지

app
 ↓ (참조 가능)
pages
 ↓
widgets
 ↓
features
 ↓
entities
 ↓
shared

Public API 패턴: index.ts 의 역할

각 모듈에 외부에 공개할 인터페이스를 명시적으로 정의하는 패턴

외부에서 모듈을 사용할 때는 내부 경로를 직접 참조하지 않고 Public API를 통해서만 접근한다.

FSD에서는 일반적으로 각 슬라이스나 세그먼트의 최상위에 index.ts 파일을 두어 이 역할을 수행한다.

*index.ts는 폴더의 대표 파일로 폴더 import 시, 자동으로 불러와지므로 index.ts에서 export 한 것만 외부에서 사용 가능

features/
├── send-message/
│   ├── ui/MessageInput.tsx
│   ├── model/useSendMessage.ts
│   ├── lib/validate.ts
│   └── index.ts              // 슬라이스 레벨
└── edit-message/
    ├── ui/EditModal.tsx
    └── index.ts              // 슬라이스 레벨

// features/send-message/index.ts
export { MessageInput } from './ui/MessageInput';
export { useSendMessage } from './model/useSendMessage';
export type { SendMessageParams } from './model/types';

JS/TS에서는 폴더를 import하면 자동으로 그 폴더의 index.ts를 찾아서 실행하므로, 사용할 때는 아래와 같이 적어주면 된다.

import { MessageInput, useSendMessage } from '@/features/send-message';

만약, 슬라이스가 없는 shared나 app 레이어는 각 세그먼트마다 index.ts를 두는 방식을 사용한다.

장점

내부 구조 자유롭게 변경 가능
외부에서 뭘 써야 하는지(공개할 것만) 설정 가능
번들 사이즈 최적화

실제 프로젝트에 적용해보기

현재 React 스터디 과제로 진행 중인 프로젝트에 FSD를 적용해보면서, 실제로 어떻게 달라지는지 확인해보려 한다.

변경 전

적용 전, 그냥 page 따로, hook 따로 api 따로 대충 비슷한 기능을 하는 애들끼리 묶어서 만든 구조이다.

파일이 적어서 찾기 쉽지만 파일이 늘어나고 프로젝트 구조가 커진다면 원하는 파일 찾는 데만 한 세월이 걸릴 것이다.

변경 후

src/
├── main.tsx
├── assets/
│
├── app/
│   ├── providers/index.tsx        (QueryClient, ErrorBoundary)
│   ├── store/index.ts             (Redux store 조립)
│   ├── router/index.tsx           (라우트 정의)
│   └── styles/index.css
│
├── pages/
│   ├── main/
│   ├── redux-demo/
│   ├── zustand-demo/
│   ├── context-api-demo/
│   └── tanstack-query-demo/
│
├── features/
│   ├── todo-manager/
│   ├── product-filter/
│   ├── settings-panel/
│   └── movie-browser/
│       ├── model/
│       │   ├── movieKeys.ts
│       │   ├── useGetMovies.ts
│       │   ├── useGetInfiniteMovies.ts
│       │   └── useGetMovieDetail.ts
│       └── ui/
│           ├── MovieDetailModal.tsx
│           └── ModalSkeleton.tsx   
│
├── entities/
│   └── movie/
│       ├── api/
│       │   └── moviesApi.ts       
│       ├── model/
│       │   └── types.ts            ← 실제 타입 정의
│       ├── ui/
│       │   └── MovieCard.tsx
│       └── index.ts
│
└── shared/
    ├── api/
    │   ├── instance.ts             ← HTTP 인프라만
    │   ├── errors.ts
    │   └── index.ts
    └── ui/
        └── ModalError/

변경 전과 후 비교를 간단히 설명해보자면,

1. main.tsx가 얇아졌다

변경 전, main.tsx에는 QueryClient 생성, GlobalError 컴포넌트, ErrorBoundary 설정이 모두 뭉쳐 있었다.

변경 후, main.tsx는 진입점 역할만 하고, 이런 전역 설정들은 app/ 레이어로 분리해 역할을 명확하게 나눴다.

2. Redux store 조립이 app 레이어로 이동했다

변경 전, src/store/store.ts가 todoSlice를 직접 가져와서 store를 구성했다.

변경 후, Redux store는 전체 앱에 영향을 주는 전역 설정이므로 app/ 레이어로 옮겼다.

slice 로직은 각 feature 슬라이스에 두고, store는 feature들의 reducer를 가져와 조립만 한다.

// app/store/index.ts
import { todoReducer } from '@/features/todo-manager'

export const store = configureStore({
  reducer: { todo: todoReducer },
})

3. 관련 코드가 한 곳에 모였다

변경 전에는 영화 기능 하나를 수정하려면 이 모든 폴더들을 모두 뒤져야 했다.

src/components/MovieDetailModal.tsx
src/hooks/queries/useGetInfiniteMovies.ts
src/hooks/queries/movieKeys.ts
src/api/movies.ts
src/types/movie.ts

변경 후에는 features/movie-browser/ 한 곳에서 시작하면 된다.

기능을 수정하거나 삭제할 때, 어느 파일을 봐야 하는지 고민할 필요가 없다.

src/features/movie-browser/
├── model/
│   ├── movieKeys.ts
│   ├── useGetMovies.ts
│   ├── useGetInfiniteMovies.ts
│   └── useGetMovieDetail.ts
└── ui/
    └── MovieDetailModal.tsx
    └── ModalSkeleton.tsx

4. index.ts가 문지기 역할을 한다 (Public API)

변경 전에는 내부 경로를 직접 참조해 파일 이동 시 모든 import가 깨지는 문제가 발생했다.

import { useGetMovieDetail } from '../hooks/queries/useGetMovieDetail'
import MovieCard from '../components/MovieCard'

변경 후에는 외부에서는 항상 index.ts를 통해서만 접근한다.

내부 구조를 아무리 바꿔도 index.ts의 export만 유지하면 외부 코드는 전혀 영향받지 않는다.

import { MovieDetailModal, useInfiniteNowPlayingMovies } from '@/features/movie-browser'
import { MovieCard } from '@/entities/movie'

+) shared/api/ 에는 인프라만 둔다

shared는 가장 아래 레이어이므로 다른 레이어를 참조할 수 없다.

따라서 shared/api/에는 HTTP 요청의 기반이 되는 인프라 코드만 둔다.

// shared/api/instance.ts
export const tmdbFetch = (endpoint: string) =>
  fetch(`${BASE_URL}${endpoint}`, { headers })

export const handleResponse = async (res: Response) => { ... }

영화 API 함수와 타입은 영화 도메인 코드이므로 entities/movie/가 담당한다.

entities가 shared를 참조하는 방향은 허용된 방향이므로 규칙을 지키면서 자연스럽게 분리할 수 있다.

// entities/movie/api/moviesApi.ts
import { tmdbFetch, handleResponse } from '@/shared/api/instance'

https://feature-sliced.design/docs/get-started/overview#incremental-adoption

Overview | Feature-Sliced Design

Feature-Sliced Design (FSD) is an architectural methodology for scaffolding front-end applications. Simply put, it's a compilation of rules and conventions on organizing code. The main purpose of this methodology is to make the project more understandable

feature-sliced.design

https://velog.io/@clydehan/FSDFeature-Sliced-Design-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C

FSD(Feature-Sliced Design) 완벽 가이드

프론트엔드 뜨거운 감자, FSD: 이 글만 읽으면 완벽하게 이해 할 수 있음.

velog.io

회원가입 및 로그인 구현

co-cherry — Tue, 28 Apr 2026 20:09:29 +0900

Spring Security

Spring 기반 애플리케이션에 인증(Authentication)과 인가(Authorization)기능을 제공하는 프레임워크

인증(Authentication) 사용자가 누구인지 확인하는 과정 (로그인 폼, OAuth2, JWT, LDAP 등 다양한 방식 지원)
인가(Authorization) 인증된 사용자가 어떤 리소스에 접근할 수 있는지 제어, URL 기반, 메서드 기반으로 권한 설정 가능
보안 공격 방어 CSRF, XSS, Session, Fixation 등 일반적인 보안 취약점을 기본으로 방어

FilterChain

HTTP 요청이 Controller에 도달하기 전 통과해야 하는 보안 필터들의 묶음

요청이 Controller에 도달하기 전에 인증/인가/예외 처리가 전부 완료된 상태로 넘어오게 한다.

SecurityContextPersistenceFilter
요청이 들어올 때 이전 인증 정보를 복원하고 요청이 끝날 때 다시 저장하는 필터
세션 기반에선 중요하나 JWT 방식에선 거의 사용하지 않음
UsernamePasswordAuthenticationFilter
로그인 요청일 때만 동작
username / password를 꺼내서 인증을 시도하고 성공하면 SecurityContext에 저장
AnonymousAuthenticationFilter
앞 필터들에서 인증이 안 됐을 때 ROLE_ANONYMOUS를 부여
Authentication이 null이 되는 것을 방지하기 위해 존재
ExceptionTranslationFilter
아래 필터에서 던진 예외를 잡아 HTTP 응답으로 변환
AuthenticationException → 401
AccessDeniedException → 403
FilterSecurityInterceptor
AccessDecisionManager에게 권한 판단을 넘기고 통과하면 Controller로, 실패하면 예외를 위로 던져 ExceptionTranslationFilter가 처리

인증(Authentication) 흐름

AuthenticationFilter (UsernamePasswordAuthenticationFilter)

HTTP 요청이 Controller에 도달하기 전에 가로채는 보안 필터

(Spring Security가 자동으로 등록하므로 직접 만들 필요 없음)

요청에서 username / password 추출
미인증 token을 생성해 AuthenticationManager에 넘김
인증 성공 후에는 SecurityContextHolder에 결과 저장

UsernamePasswordAuthenticationToken

사용자 인증 정보를 담는 객체 (Authentication 인터페이스의 구현체)

로그인 요청이 들어오면 UsernamePasswordAuthenticationFilter가 해당 요청을 받아 username과 password 이용해 토큰 생성

인증 전: username + password (authenticated = false)
인증 후: UserDetails + 권한 목록 (authenticated = true, password는 null 처리)

생성된 토큰은 AuthenticationManager에게 전달되어 인증 진행

AuthenticationManager

인증 처리를 총괄하는 인터페이스

직접 인증하지 않고 적절한 Provider에게 위임만 함

Token을 받아 지원 가능한 AuthenticationProvider를 찾아 인증(Authentication)을 넘김

AuthenticationProvider

실제 인증 로직이 실행되는 곳

UserDetailsService로 유저를 조회하고, PasswordEncoder로 비밀번호를 검증

DB에서 찾은 유저와 입력값을 비교해 일치하면 인증된 Token을, 불일치하면 BadCredentialsException을 던짐

PasswordEncoder

비밀번호를 암호화하고 검증하는 인터페이스

회원가입 시, 비밀번호를 암호화해 DB에 저장
로그인 시, 입력값과 DB 암호화값을 비교

UserDetailsService

DB에서 유저를 조회하는 인터페이스 (개발자가 직접 구현)

username을 받아 DB에서 유저를 찾고 UserDetails 객체로 반환, 없으면 UsernameNotFoundException

UserDetails

Spring Security가 인식하는 유저 정보 객체, DB의 User 엔티티를 Security용으로 감싸는 래퍼 역할

비밀번호, 권한 목록, 계정 상태(잠김/만료 등)을 Security에 제공
Provider가 이 객체를 기반으로 인증 Token 생성

SecurityContextHolder

인증된 유저 정보를 SecurityContext에 저장 및 관리하는 저장소

로그인이 완료되면 SecurityContext에 Authentication이 보관됨

인증 완료 후, 어디서든 현재 로그인한 유저 정보를 꺼낼 수 있게 해줌
스레드별로 독립적으로 관리되어 다른 사용자의 정보와 섞이지 않음

https://ittrue.tistory.com/287

[Spring Security] 스프링 시큐리티 인증 처리 흐름

스프링 시큐리티의 인증 처리 흐름 스프링 시큐리티에서는 스프링 시큐리티 필터 체인을 통해 보안을 위한 특정 작업을 처리한다. 다음은 사용자가 로그인 인증을 위한 요청을 할 경우, 스프링

ittrue.tistory.com

https://dev-coco.tistory.com/174

Spring Security의 구조(Architecture) 및 처리 과정 알아보기

시작하기 앞서 스프링 시큐리티에서 어플리케이션 보안을 구성하는 두 가지 영역에 대해 간단히 알아보자.인증(Authentication)과 인가(Authorization)대부분의 시스템에서는 회원을 관리하고 있고, 그

dev-coco.tistory.com

인가(Authorization) 흐름

FilterSecurityInterceptor

FilterChain의 가장 마지막에 위치하는 필터

실제 리소스(Controller)에 접근하기 직전에 권한 검사를 시작하는 인가의 진입점

SecurityContextHolder에서 현재 유저의 Authentication을 꺼냄
SecurityMetadataSource에서 해당 URL에 필요한 권한(ConfigAttribute)를 조회
이 두 정보를 AccessDecisionManager에게 넘겨 판단을 위임

SecurityMetadataSource

각 URL(리소스)에 접근하기 위해 필요한 권한 정보를 보관하는 저장소

FilterSecurityInterceptor가 "이 URL에 필요한 권한이 뭐야?"라고 물으면 ConfigAttribute 목록으로 응답
SecurityConfig에서 설정한 규칙이 여기에 저장

AccessDecisionManager

인가 판단을 총괄하는 인터페이스

직접 판단하지 않고 여러 AccessDecisionVoter에게 위임해 결과를 총합

Authentication(사용자 권한)과 ConfigAttribute(필요 권한)을 받아 Voter들에게 투표 시킴
투표 결과를 취합해 최종 허용/거부 결정, 거부 시 AccessDeniedException 발생

AccessDecisionVoter

실제 권한 비교를 수행하는 투표자

사용자 권한과 필요 권한을 직접 비교해 허용/거부/기권 중 하나를 반환

ExceptionTranslationFilter

FilterSecurityInterceptor에서 발생한 Security 예외를 잡아 적절한 HTTP 응답으로 변환하는 필터

로그인이 안 된 상태의 접근은 AuthenticationEntryPoint로 넘겨 401 반환
권한 부족은 AccessDeniedHandler로 넘겨 403 반환

Security Config 설정

Spring Security가 제공하는 보안 기능들을 어떻게 적용할지 설정하는 클래스

이 URL은 누구나 접근 가능
이 URL은 로그인한 사람만 접근 가능
이 URL은 관리자만 접근 가능

이처럼 필터 체인과 보안 정책을 설정하는 곳이 바로 Security Config이다.

@EnableWebSecurity Spring Security 설정 활성화
@Configuration 이 클래스가 Spring 설정 클래스임을 선언, 내부 @Bean 메서드들이 Spring 컨테이너에 등록됨
allowUris 배열 인증 없이 접근을 허용할 URL 목록들
- /** 은 하위 경로를 모두 포함하는 와일드카드
- 나중에 허용 URL을 추가할 때 이 배열만 수정하면 되므로 유지보수에 용이

package com.example.umcspringbootstudy.global.config;

import jakarta.servlet.http.HttpServletResponse;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.http.SessionCreationPolicy;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.web.SecurityFilterChain;

@EnableWebSecurity
@Configuration
public class SecurityConfig {

    private final String[] allowUris = {
            "/swagger-ui/**",
            "/v3/api-docs/**",
            "/users/signup",
            "/users/login",
    };

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                .csrf(csrf -> csrf.disable())
                .sessionManagement(session ->
                        session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                )
                .authorizeHttpRequests(requests -> requests
                        .requestMatchers(allowUris).permitAll()
                        .requestMatchers("/admin/**").hasRole("ADMIN")
                        .anyRequest().authenticated()
                )
                .exceptionHandling(exception -> exception
                        .authenticationEntryPoint((request, response, authException) ->
                                response.sendError(HttpServletResponse.SC_UNAUTHORIZED))
                        .accessDeniedHandler((request, response, accessDeniedException) ->
                                response.sendError(HttpServletResponse.SC_FORBIDDEN))
                );

        return http.build();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

securityFilterChain HTTP 요청에 대한 보안 규칙을 정의하는 핵심 빈

csrf(csrf -> csrf.disable())
CSRF은 악성 사이트가 로그인된 사용자의 권한을 도용하는 공격(JWT 기반 REST API에선 불필요하므로 비활성화)
.sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
sessionManagement()는 서버의 세션 생성 방식 설정
SessionCreationPolicy.STATELESS 서버가 세션을 생성하지 않도록 함
*JWT 방식은 토큰 자체에 인증 정보가 담겨 있으므로 서버가 세션을 유지할 필요 없음
.authorizeHttpRequests(requests -> requests
들어오는 HTTP 요청들에 대해 어떤 접근 권한이 필요한지 규칙 설정, 위에서부터 순서대로 매칭(순서 중요)

.requestMatchers(allowUris).permitAll()
requestMatchers()은 규칙을 적용할 URL 패턴 지정
permitAll()은 해당 URL에 인증 없이 누구나 접근 가능하도록 허용
→ allowUris 배열의 경로들은 누구나 접근 가능하도록 설정됨
.requestMatchers("/admin/**").hasRole("ADMIN")
/admin/ 으로 시작하는 모든 경로는 ADMIN 역할을 가진 사용자만 접근 가능
hasRole()은 내부적으로 ROLE_ADMIN이라는 권한명을 찾음
*hasRole 메서드 사용 시, DB에 ROLE_ 접두사가 붙어 있어야 함
.anyRequest().authenticated()
anyRequest()는 위에서 지정하지 않은 나머지 모든 요청을 의미
authenticated()는 해당 요청에 로그인(인증)을 요구

.exceptionHandling(exception -> exception
인증/인가 과정에서 발생하는 예외 상황을 처리하는 설정
- .authenticationEntryPoint((request, response, authException) ->
  response.sendError(HttpServletResponse.SC_UNAUTHORIZED))
  authenticationEntryPoint는 인증이 필요할 때, 인증 정보가 없으면 동작
  쉽게 말해, 로그인 안 된 상태로 접근 시 401 Unauthorized 에러를 반환
- .accessDeniedHandler((request, response, accessDeniedException) ->
  response.sendError(HttpServletResponse.SC_FORBIDDEN))
  accessDeniedHandler는 인증은 됐지만 권한이 부족할 때 동작
  쉽게 말해, 일반 유저가 /admin에 접근 시 403 Forbidden 에러를 반환
public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }
PasswordEncoder는 비밀번호를 암호화하는 인터페이스
BcryptPasswordEncoder는 BCrypt 해시 알고리즘을 사용하며 Spring Security에서 표준으로 사용
DB에 비밀번호 저장 시, 평문 대신 암호화된 값을 저장하기 위해 사용

최종적으로 위에서 설정한 모든 규칙을 적용해 SecurityFilterChain 객체를 생성하고 반환한다.

이 객체가 실제로 모든 요청을 가로채는 필터 체인으로 동작한다.

https://spring.io/projects/spring-security#overview

Spring Security

Spring Security is a powerful and highly customizable authentication and access-control framework. It is the de-facto standard for securing Spring-based applications. Spring Security is a framework that focuses on providing both authentication and authoriz

spring.io

ROLE

사용자 권한 등급을 나타내는 Enum

ROLE을 사용해 사용자 간 접근 제어 가능

User 엔티티에 저장
회원가입 시, ROLE_USER(일반 회원)으로 고정
SecurityConfig에서 접근 제어
반드시 ROLE_ 접두사 필수: hasRole("ADMIN") 사용 시, 내부적으로 ROLE_ADMIN을 찾는 것임

public enum Role {
    ROLE_ADMIN, ROLE_USER
}

회원가입 구현 (w. 비밀번호 암호화 저장)

먼저, 위 설정에서 회원가입 endpoint를 전체 접근 허용하고 passwordEncoder를 Bean으로 등록해야 한다.

DTO

회원가입 시 필요한 DTO를 먼저 설정했다.

User 도메인에 로그인과 회원가입 등 여러 DTO를 하나의 파일 안에 작성하기 위해 Record 타입으로 작성했다.

public class UserRequestDTO {

    public record SignUpDTO(
            @NotBlank
            String nickname,
            @NotBlank
            @Email
            String email,
            @NotBlank
            String password,
            Gender gender,
            String phoneNumber
    ) {}
}

public class UserResponseDTO {

    public record SignUpDTO(
            Long id,
            String nickname,
            String email
    ) {}
}

*record java 14에서 추가된 불변 데이터 클래스

생성자, getter, equals, hashCode, toString 을 자동으로 만들어줌

Repository

회원가입 시, 이미 가입된 이메일은 재가입이 불가하므로 이메일 중복 체크하는 쿼리를 Repository에 구현한다.

public interface UserRepository extends JpaRepository<User, Long> {
    boolean existsByEmail(String email);
}

이때, Spring Data JPA는 Repository 인터페이스에 메서드 이름을 *특정 규칙으로 작성하면 쿼리를 자동으로 생성하는 것을 이용

동사 + By + 필드명 + (조건)

findBy → SELECT (조회)
existsBy → SELECT EXISTS (존재 여부)
countBy → SELECT COUNT (개수)
deleteBy → DELETE (삭제)

Service

1. 앞에서 생성한 existsByEmail 쿼리를 이용해 중복 체크를 한다.

DB에 이미 같은 이메일이 있으면 409 에러를 반환하고 종료한다.

2. 클라이언트가 보낸 평문 비밀번호를 BCrypt로 해시화한다. DB에는 해시화된 값이 저장된다.

passwordEncoder.encode() 평문 비밀번호를 BCrypt 알고리즘으로 해시화
- 단방향 해시: 암호화는 가능하나 복호화는 불가능
- 솔트(Salt) 자동 추가: 같은 비밀번호도 매번 다른 해시값 반환

3. DTO에서 받은 값 + 암호화된 비밀번호 + Role로 User 엔티티를 만들고 DB에 저장한다.

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;

    @Transactional
    public UserResponseDTO.SignUpDTO signup(UserRequestDTO.SignUpDTO dto) {

        if (userRepository.existsByEmail(dto.email())) {
            throw new GeneralException(UserErrorCode.USER_ALREADY_EXISTS);
        }

        String encodedPassword = passwordEncoder.encode(dto.password());

        User user = User.builder()
                .nickname(dto.nickname())
                .email(dto.email())
                .password(encodedPassword)
                .role(Role.ROLE_USER)
                .gender(dto.gender())
                .phoneNumber(dto.phoneNumber())
                .build();

        User savedUser = userRepository.save(user);

        return new UserResponseDTO.SignUpDTO(
                savedUser.getId(),
                savedUser.getNickname(),
                savedUser.getEmail()
        );
    }
}

Controller

POST로 /users/signup 경로로 회원가입 요청을 받는다.

@Tag(name = "유저 API", description = "회원가입/로그인 관련 API")
@RestController
@RequiredArgsConstructor
@RequestMapping("/users")
public class UserController {

    private final UserService userService;

    @Operation(summary = "회원가입", description = "이메일, 비밀번호, 닉네임으로 회원가입합니다.")
    @PostMapping("/signup")
    public ApiResponse<UserResponseDTO.SignUpDTO> signup(@Valid @RequestBody UserRequestDTO.SignUpDTO dto) {
        return ApiResponse.onSuccess(GeneralSuccessCode.CREATED, userService.signup(dto));
    }
}

테스트

테스트로 tom의 정보를 입력해 회원가입을 수행했다.

DTO대로 id, nickname, email만이 반환된 것을 볼 수 있다.

intelliJ 내부에서 확인하면 비밀번호가 해시된 값으로 나오는 것을 확인할 수 있다.

또한, ROLE 또한 ROLE_USER로 제대로 나오는 모습을 볼 수 있다.

세션 기반 vs 토큰 기반 인증 비교

세션 기반(Stateful)

서버가 세션 저장소(메모리/Redis)에 사용자 정보를 직접 보관하고, 클라이언트는 세션 ID만 쿠키로 갖고 있는 상태

클라이언트                    서버
   |-- POST /login ----------->|
   |<-- Set-Cookie: JSESSIONID |  ← 세션 ID 발급, 서버 메모리에 저장
   |                           |
   |-- GET /api (Cookie) ----->|
   |                           |  ← 세션 ID로 서버에서 사용자 조회
   |<-- 200 OK ----------------|

토큰 기반(Stateless)

서버는 토큰을 저장하지 않고, 토큰의 서명(Signature)만 검증, 사용자 정보는 토큰 내부(Payload)에 담겨 있는 상태

클라이언트                    서버
   |-- POST /login ----------->|
   |<-- JWT Token -------------|  ← 토큰 발급, 서버는 저장 안 함
   |                           |
   |-- GET /api                |
   |   Authorization: Bearer <token>
   |                           |  ← 토큰 자체를 검증 (서명 확인)
   |<-- 200 OK ----------------|

구분	세션 기반	토큰 기반(JWT)
서버 상태	Stateful(세션 저장 필요)	Stateless(저장 불필요)
확장성	서버 여러 대일 때 세션 공유 문제	어느 서버든 토큰만 검증하면 됨
보안 제어	서버에서 즉시 세션 무효화 가능	토큰 만료 전까지 강제 차단 어려움
로그아웃	서버에서 세션 삭제로 완전 로그아웃	클라이언트 토큰 삭제 필요
서버 부하	요청마다 세션 저장소 조회	저장소 조회 없이 서명만 검증
모바일/분리 구조	쿠키 기반이라 네이티브 앱에서 불편	Header 방식이라 어느 클라이언트든 호환
구현 복잡도	상대적으로 단순	Refresh Token 등 추가 고려 필요

우리 프로젝트는 Spring Boot REST API + 프론트 분리구조이므로 JWT 방식이 더 적합하므로 로그인 구현 시, JWT를 활용해보려고 한다.

JWT 발급과 로그인 구현

로그인 과정은 위에서 언급했던 인증(Authentication)의 흐름을 다시 살펴봐야 한다.

인증 과정에서 Spring Security는 "어떻게 유저를 찾을지" 모른다.

우리는 email 기반으로 users 테이블을 조회하고, Role enum으로 권한을 관리하기 때문에,

UserDetails와 UserDetailsService를 우리 도메인에 맞게 직접 작성해야 한다.

UserDetails

이메일, 비밀번호, 권한 등 유저 정보를 담는 객체

DB의 User 엔티티를 Spring Security가 이해할 수 있게 변환

Spring Security의 표준 인터페이스인 UserDetails를 CustomUserDetails로 구현했다.

@RequiredArgsConstructor
public class CustomUserDetails implements UserDetails {
    private final User user;

    public Long getUserId() {
        return user.getId();
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return List.of(new SimpleGrantedAuthority(user.getRole().toString()));
    }

    @Override
    public String getPassword() {
        return user.getPassword();
    }

    @Override
    public String getUsername() {
        return user.getEmail();
    }
}

getAuthorities 권한을 List 형태로 반환 (ADMIN 또는 USER)
getPassword 비밀번호 반환
getUsername 아이디(또는 이메일) 반환
getUserId 컨트롤러에서 @AuthenticationPrincipal CustomUserDetails로 꺼낼 때 userId를 바로 꺼내기 위해 별도 추가

UserDetailsService

DB에 쿼리해서 유저 정보를 찾아오는 서비스

loadUserByUsername(email) 메서드로 이메일 기반 조회 (Username == email)

로그인 요청(email + password)
→ loadUserByUsername(email) 메서드 spring이 자동 호출
→ DB에서 User 조회
CustomUserDetails로 감싸서 반환
Spring이 입력된 password와 DB password 비교

@Service
@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {
    private final UserRepository userRepository;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        User user = userRepository.findByEmail(username)
                .orElseThrow(() -> new UserException(UserErrorCode.USER_NOT_FOUND));
        return new CustomUserDetails(user);
    }
}

JWT 기반 인증 흐름

1. 로그인 시(토큰 발급)

POST /users/login 요청을 보냄
→ UserService.login()
→ 비밀번호 검증
→ JwtUtil.generateToken() 을 통해 토큰 생성
→ 클라이언트에게 accessToken 반환

2. 로그인 후 API 요청 시(토큰 검증)

GET /posts/1 요청을 보냄
Authorization: Bearer eyJhGC...
→ JwtAuthFilter가 요청을 가로채 토큰 검증
→ SecurityContext에 인증 정보 저장
→ Controller 실행

JwtUtil 토큰 생성/검증/데이터 추출하는 도구

JWT 토큰은 그냥 문자열이 아닌 서명(Signature)이 포함된 구조체

이 토큰을 직접 만들고, 검증하고, 안에서 데이터를 꺼내는 작업이 복잡하기 때문에 JwtUtil 하나에 모아두는 것

generateToken(userId) 토큰 생성
validateToken(token) 토큰 유효성 검증
getUserIdFromToken(token) 토큰에서 userId 추출

JwtAuthFilter 모든 요청을 감시하는 문지기

로그인 이후, GET 과 같은 요청이 오면 Spring Security는 이 사람이 누구인지 검증이 필요

그러나, JWT는 서버가 저장하지 않으므로 매 요청마다 토큰을 꺼내 검증하고, 인증 정보를 SecurityContext에 직접 넣어야 함

Authorization: Bearer <token> 헤더에서 토큰 추출
JwtUtil.validateToken() 으로 검증
유효하면 JwtUtil.getUserIdFromToken()으로 userId 추출
DB에서 User를 조회해 CustomDetails 생성
SecurityContextHolder에 인증 정보 저장

따라서, 토큰 기반 인증 구현 시, JwtUtil과 JwtAuthFilter 가 필요하다는 것을 생각하고 로그인 과정을 구현해보겠다.

먼저, build.gradle과 application.yml에 JWT 관련 설정을 넣어준다.

application.yml 에 넣는 시크릿 키는 환경 변수 처리를 하여 다음과 같이 설정했다.

    implementation 'io.jsonwebtoken:jjwt-api:0.12.3'
    implementation 'io.jsonwebtoken:jjwt-impl:0.12.3'
    implementation 'io.jsonwebtoken:jjwt-jackson:0.12.3'
    // implementation 'org.springframework.boot:spring-boot-configuration-processor'

jwt:
  token:
    secretKey: ${JWT_SECRET}
    expiration:
      access: 14400000

그리고 JwtUtil부터 작성해보자.

@Component
public class JwtUtil {

    private final SecretKey secretKey;
    private final Duration accessExpiration;

    // application.yml의 jwt 값을 생성자에서 주입받음
    public JwtUtil(
            @Value("${jwt.token.secretKey}") String secret,
            @Value("${jwt.token.expiration.access}") Long accessExpiration
    ) {
        // 문자열 시크릿 키 → HMAC-SHA 알고리즘용 SecretKey 객체로 변환
        this.secretKey = Keys.hmacShaKeyFor(secret.getBytes(StandardCharsets.UTF_8));
        // 밀리초 숫자 → Duration 타입으로 변환 (14400000ms = 4시간)
        this.accessExpiration = Duration.ofMillis(accessExpiration);
    }

    /**
     * Access Token 발급
     * 로그인 성공 시 UserService에서 호출
     */
    public String createAccessToken(CustomUserDetails user) {
        return createToken(user, accessExpiration);
    }

    /**
     * 토큰에서 이메일 추출
     * JwtAuthFilter에서 토큰 → 이메일 → DB 조회 순서로 사용
     */
    public String getEmail(String token) {
        try {
            return getClaims(token).getPayload().getSubject();
        } catch (JwtException e) {
            return null;
        }
    }

    /**
     * 토큰 유효성 검증
     * JwtAuthFilter에서 토큰 처리 전 가장 먼저 호출
     */
    public boolean isValid(String token) {
        try {
            getClaims(token);
            return true;
        } catch (JwtException e) {
            return false;
        }
    }

    // 토큰 생성 내부 로직
    private String createToken(CustomUserDetails user, Duration expiration) {
        Instant now = Instant.now();

        // 권한 목록 → 콤마 구분 문자열 변환 (예: "ROLE_USER")
        String authorities = user.getAuthorities().stream()
                .map(GrantedAuthority::getAuthority)
                .collect(Collectors.joining(","));

        return Jwts.builder()
                .subject(user.getUsername())                 // 이메일을 subject로 저장
                .claim("role", authorities)                  // 권한 정보 저장
                .issuedAt(Date.from(now))                    // 발급 시간
                .expiration(Date.from(now.plus(expiration))) // 만료 시간
                .signWith(secretKey)                         // 서명 (위변조 방지)
                .compact();                                  // 최종 토큰 문자열 반환
    }

    // 토큰 파싱 + 서명 검증
    // 서명이 잘못됐거나 만료되면 JwtException 발생
    // clockSkewSeconds(60): 서버 간 시간 오차 1분까지 허용
    private Jws<Claims> getClaims(String token) throws JwtException {
        return Jwts.parser()
                .verifyWith(secretKey)
                .clockSkewSeconds(60)
                .build()
                .parseSignedClaims(token);
    }
}

1. 생성자 - 시크릿 키와 만료 시간 준비

public JwtUtil(
        @Value("${jwt.token.secretKey}") String secret,
        @Value("${jwt.token.expiration.access}") Long accessExpiration
) {
    this.secretKey = Keys.hmacShaKeyFor(secret.getBytes(StandardCharsets.UTF_8));
    this.accessExpiration = Duration.ofMillis(accessExpiration);
}

Keys.hmacShaKeyFor() 문자열로 저장해둔 시크릿 키를 암호화 전용 객체(SecretKey)로 변환

2. createToken() - 토큰 조립

private String createToken(CustomUserDetails user, Duration expiration) {
    Instant now = Instant.now();

    String authorities = user.getAuthorities().stream()
            .map(GrantedAuthority::getAuthority)
            .collect(Collectors.joining(","));

    return Jwts.builder()
            .subject(user.getUsername())                 // "test@gmail.com"
            .claim("role", authorities)                  // "ROLE_USER"
            .issuedAt(Date.from(now))                    // 지금 시각
            .expiration(Date.from(now.plus(expiration))) // 지금 + 4시간
            .signWith(secretKey)                         // 서명
            .compact();                                  // 문자열로 변환
}

stream().map().collect() getAuthorities가 반환하는 [GrantedAuthority("ROLE_USER")]과 같은 리스트를 문자열로 변환

3. getClaims() - 토큰 파싱 + 서명 검증

private Jws<Claims> getClaims(String token) throws JwtException {
    return Jwts.parser()
            .verifyWith(secretKey)    // 이 키로 서명 검증
            .clockSkewSeconds(60)     // 시간 오차 1분 허용
            .build()
            .parseSignedClaims(token);
}

parseSignedClaims(token)
- 토큰을 Header / Payload / Signature 세 부분으로 분리
- secretKey로 Signature 검증 → 위변조 여부 확인
- exp(만료시간) 확인 → 만료됐으면 JwtException 발생
- 이상 없으면 Payload(Claims) 반환

4. getEmail() 과 isValid()

둘 다 getClaims()를 호출하지만 예외를 직접 던지지 않고, null / false로 변환해서 반환

public String getEmail(String token) {
    try {
        return getClaims(token).getPayload().getSubject(); // subject = 이메일
    } catch (JwtException e) {
        return null; // 잘못된 토큰이면 null 반환
    }
}

public boolean isValid(String token) {
    try {
        getClaims(token);
        return true;
    } catch (JwtException e) {
        return false; // 잘못된 토큰이면 false 반환
    }
}

로그인 시에는 createAccessToken() → createToken() → 토큰 문자열 반환의 과정을 거치고,

이후 요청 시에는 isValid() → getClaims() → 서명/만료 검증 → getEmail() → getClaims.getSubject() → 이메일 추출(후 DB에서 User 조회)의 과정을 거친다.

Q. 왜 토큰만으로 끝내지 않고 다시 DB를 조회할까?

유저가 탈퇴했으나 토큰이 유효하거나, 유저 권한이 변경되었는데 토큰에 적용이 되지 않은 경우, 계정이 정지되었으나 토큰이 유효한 경우 등이 발생할 수 있다.

이때, DB를 다시 조회하면 토큰 발급 시점이 아닌 항상 최신 상태의 유저 정보를 가져올 수 있다.

이 다음 JwtAuthFilter 를 작성해보자.

// OncePerRequestFilter: 하나의 요청에 딱 한 번만 실행되는 필터
@Component
@RequiredArgsConstructor
public class JwtAuthFilter extends OncePerRequestFilter {

    private final JwtUtil jwtUtil;
    private final CustomUserDetailsService customUserDetailsService;

    @Override
    protected void doFilterInternal(
            @NonNull HttpServletRequest request,
            @NonNull HttpServletResponse response,
            @NonNull FilterChain filterChain
    ) throws ServletException, IOException {

        // [1] Authorization 헤더에서 토큰 가져오기
        String token = request.getHeader("Authorization");

        // [2] 토큰이 없거나 "Bearer "로 시작하지 않으면 인증 없이 다음 필터로 넘김
        //     (로그인, 회원가입 등 인증이 필요 없는 요청은 여기서 통과)
        if (token == null || !token.startsWith("Bearer ")) {
            filterChain.doFilter(request, response);
            return;
        }

        // [3] "Bearer " 제거 후 순수 토큰 값만 추출
        //     "Bearer eyJhbGc..." → "eyJhbGc..."
        token = token.substring(7);

        // [4] 토큰 유효성 검증 (서명 확인 + 만료 여부)
        if (jwtUtil.isValid(token)) {
            // [5] 토큰에서 이메일 추출 후 DB 조회
            String email = jwtUtil.getEmail(token);
            UserDetails user = customUserDetailsService.loadUserByUsername(email);

            // [6] 인증 객체 생성
            //     파라미터: (principal, credentials, authorities)
            //     credentials(비밀번호)는 이미 인증된 상태이므로 null
            Authentication auth = new UsernamePasswordAuthenticationToken(
                    user,
                    null,
                    user.getAuthorities()
            );

            // [7] SecurityContext에 인증 정보 저장
            //     이후 컨트롤러에서 @AuthenticationPrincipal로 꺼낼 수 있음
            SecurityContextHolder.getContext().setAuthentication(auth);
        }

        // [8] 다음 필터로 넘김 (필수 — 없으면 요청이 여기서 멈춤)
        filterChain.doFilter(request, response);
    }
}

1. 요청에서 Authorization 헤더 꺼내기

String token = request.getHeader("Authorization");

2. 토큰이 없거나 Bearer가 아니면 그냥 통과

원래 요청을 request, 응답할 객체를 response에 넣음

로그인, 회원가입처럼 인증이 필요 없는 요청은 여기서 바로 다음으로 넘김

if (token == null || !token.startsWith("Bearer ")) {
    filterChain.doFilter(request, response);
    return;
}

3. "Bearer " 제거 후 순수 토큰만 추출

"Bearer eyJhbGc..." → "eyJhbGc..."

token = token.substring(7);

4. 토큰 유효성 검증

JWT 토큰의 정보를 읽고 서명이 올바른지, 만료되지 않았는지 확인 (JwtUtil 사용)

유효하지 않으면 블록 자체를 건너뜀

if (jwtUtil.isValid(token)) { ... }

5. 토큰에서 이메일 추출 → DB에서 유저 조회

JWT 토큰에서 사용자 정보를 추출 (JwtUtil 사용)

String email = jwtUtil.getEmail(token);
UserDetails user = customUserDetailsService.loadUserByUsername(email);

6. 인증 객체 생성

UsernamePasswordAuthenticationToken(user: 인증된 유저 객체, null: 비밀번호, authorities: 권한 목록)
- 비밀번호가 null인 것은 토큰으로 이미 증명이 되었으므로 불필요

Authentication auth = new UsernamePasswordAuthenticationToken(
        user, null, user.getAuthorities()
);

7. SecurityContext에 저장

SecurityContextHolder.getContext().setAuthentication(auth);

8. 다음 필터로 넘김

filterChain.doFilter(request, response);

그 후, 로그인을 구현하기 위해 DTO와 Controller를 다음과 같이 작성했다.

public record LoginDTO(
            @NotBlank
            String email,
            @NotBlank
            String password
    ){}

@Builder
    public record LoginDTO(
            Long memberId,
            String accessToken
    ){}

@PostMapping("/login")
    public ApiResponse<UserResponseDTO.LoginDTO> login(@Valid @RequestBody UserRequestDTO.LoginDTO dto){
        return ApiResponse.onSuccess(GeneralSuccessCode.OK, userService.login(dto));
    }

서비스는 다음과 같은 과정을 거친다.

이메일로 유저 조회
입력된 비밀번호와 DB의 암호화된 비밀번호 비교
User 엔티티를 CustomUserDetails로 감쌈
accessToken 발급

public UserResponseDTO.LoginDTO login(UserRequestDTO.@Valid LoginDTO dto) {
        // [1] 이메일로 유저 조회 (없으면 예외)
        User user = userRepository.findByEmail(dto.email())
                .orElseThrow(() -> new GeneralException(UserErrorCode.USER_NOT_FOUND));

        // [2] 입력한 비밀번호와 DB의 암호화된 비밀번호 비교
        if (!passwordEncoder.matches(dto.password(), user.getPassword())) {
            throw new GeneralException(UserErrorCode.INVALID_PASSWORD);
        }

        // [3] CustomUserDetails로 감싸기
        CustomUserDetails userDetails = new CustomUserDetails(user);
        
        // [4] accessToken 발급 
        String accessToken = jwtUtil.createAccessToken(userDetails);

        return UserResponseDTO.LoginDTO.builder()
                .memberId(user.getId())
                .accessToken(accessToken)
                .build();
    }

passwordEncoder.matches() 비밀번호는 DB에 암호화되어 저장되어 있어 단순 비교가 불가능하므로 .matches()로 비교

마지막으로, 위에서 설정한 Security Config 설정을 일부 수정해야 한다.

1. 폼 로그인 화면 비활성화

Spring Security는 기본적으로 /login 경로에 폼 로그인 화면을 제공

JWT 방식에서는 오히려 충돌의 가능성이 있으므로 비활성화

.formLogin(AbstractHttpConfigurer::disable)

2. JwtAuthFilter를 Spring Security 필터 체인에 등록

기본 인증 필터가 실행되기 전에 JWT 검증을 먼저 처리해야 하므로 UsernamePasswordAuthenticationFilter 앞에 넣음

.addFilterBefore(jwtAuthFilter(), UsernamePasswordAuthenticationFilter.class)

3. jwtAuthFilter() Bean

JwtAuthFilter 객체를 Spring Bean으로 만들어 등록하는 메서드

jwtAuthFilter()를 호출하면 new JwtAuthFilter(jwtUtil, customUserDetailService)로 객체를 만들어서 반환

@Bean
public JwtAuthFilter jwtAuthFilter() {
    return new JwtAuthFilter(jwtUtil, customUserDetailsService);
}

정상적으로 처리되었는지 확인하기 위해 회원가입 후 로그인을 해보았다.

위 사진처럼 로그인 시, accessToken을 얻을 수 있는데, 이 토큰을 Swagger 우측 상단에 있는 authorize 버튼에 등록하면 된다.

테스트를 위해 이전에 작성한 Ping API를 실행해보았다.

인증 전

인증 전에는 401 인증이 필요하다는 에러가 발생한다.

인증 후

인증 후에는 요청이 정상적으로 처리되는 것을 볼 수 있다.

(추가) AuthenticationEntryPoint와 JWT 인증 예외 처리 통일

Spring security는 인증 실패 시, 아래와 같은 형식으로 응답한다.

하지만, 프로젝트의 나머지 API 에러 응답은 전부 아래처럼 통일된 형식을 사용하고 있다.

이를 일관성을 통일하기 위해 AuthenticationEntryPoint를 직접 구현해 응답을 통일해보았다.

*AuthenticationEntryPoint

인증되지 않은 요청이 보호된 리소스에 접근했을 때, Spring Security가 호출하는 핸들러

commence() 메서드 하나만 구현하면 되며, 이 안에서 응답을 직접 작성하는 형태

case 1: 토큰이 없을 때

클라이언트: Authorization 헤더 없이 요청
JWTAuthFilter: 헤더가 null이므로 인증 처리 없이 다음 필터로 통과
Spring Security: SecurityContext에 인증 정보가 없음을 감지 후, AuthenticationEntryPointImpl.commece() 호출

case 2: 토큰이 있지만 유효하지 않을 때(만료, 위조 등)

클라이언트: 만료되거나 위조된 토큰으로 요청
JWTAuthFilter: 토큰 파싱 시도 → JwtException 발생
JWTAuthFilter: JwtException을 BadCredentialsException으로 변환해 throw
ExceptionTranslationFilter: AuthenticationException 감지해 AuthenticationEntryPointImpl.commece() 호출

두 케이스 모두 최종 응답은 AuthenticationEntryPointImpl 에서 처리되며,

토큰 없음/토큰이 유효하지 않음 모두 동일한 형식의 401 응답을 반환하게 된다.

Trouble Shooting

문제 상황

JWT 로그인을 구현한 뒤 Swagger에서 테스트하려고 했는데, 토큰을 입력할 수 있는 Authorize 버튼이 보이지 않음

예상 원인 1

Spring Boot는 기본적으로 MVC 관련 설정을 자동으로 해줌

@EnableWebMvc 를 붙이면 그 자동 설정이 비활성화되는데 Swagger 또한 그 자동 설정에 의존함

예상 원인 2

SecurityScheme은 Swagger에게 "이 API는 JWT Bearer 인증을 사용한다"고 알려 주는 설정

SecurityRequirement는 "모든 API에 그 인증을 적용한다"고 지시하는 설정

이 두 개가 다 없었음

결과

예상 원인을 모두 수정 후, 서버를 재시작하여 확인하니 정상적으로 Swagger 에서 Authorize 버튼이 활성화됨

로그인으로 발급받은 토큰 입력 시, 이후 모든 API 요청에 자동으로 Authorization: Bearer {token} 헤더가 붙게 됨

에러 핸들링과 안전성

co-cherry — Sun, 26 Apr 2026 16:32:46 +0900

API 에러 분류

HTTP 상태 코드 (HTTP Status Code)

HTTP 요청의 성공/실패 여부를 서버에서 알려주는 코드

API 호출 시, HTTP Status Code로 API 처리 결과를 받고 HTTP Response Body로 응답 값을 받음

정상 호출: 200 반환, 각 API 별 지정된 포맷의 결과값을 받음
비정상 호출: 400/500 반환, 각 API 서버별 에러 코드와 에러 메세지 값을 받음

2XX 성공 상태 코드

200 OK 가장 일반적인 성공 응답, GET/PUT/PATCH 요청 성공, 응답 본문에 데이터가 포함
201 Created 리소스 생성 성공(POST), Location 헤더에 생성된 리소스 URL 포함
202 Accepted 요청 접수됨(처리는 아직 완료 아님), 비동기 작업에서 사용
204 No Content 성공했으나 응답할 본문이 없음, DELETE 성공 또는 PUT 업데이트 성공

4XX 클라이언트 에러 : 예측 가능 에러 (Expected)

개발자가 미리 예상하고 대비할 수 있는 에러

개발자가 구체적인 안내 가능, 프론트에서 사전 검증으로 예방 가능

400 Bad Request 잘못된 요청(문법 오류, 필수값 누락 등)
401 Unauthorized 인증 안 됨(로그인 필요), 토큰 없음, 토큰 만료, 잘못된 비밀번호
403 Forbidden 인증은 됐으나 권한이 없음
404 Not Found 리소스가 존재하지 않음
409 Conflict 리소스 상태 충돌
422 Unprocessable Entity 요청 형식은 맞으나 비즈니스 로직 검증 실패
429 Too Many Requests Rate Limit 초과(요청이 너무 많음)

5XX 서버 에러 : 예측 불가능 에러 (Unexpected)

런타임에 갑자기 발생해 미리 대비하기 어려운 에러

일반적인 안내만 가능, 자동 재시도 필요, 프론트에서 예방 불가능

500 Internal Server Error 가장 일반적인 서버 에러, 서버에서 예상치 못한 오류 발생
502 Bad Gateway 게이트웨이/프록시 서버가 잘못된 응답 받음
503 Service Unavailable 서버가 일시적으로 요청 처리 불가
504 Gateway Timeout 게이트웨이 서버가 서버 응답을 시간 내 못 받음

이처럼 예측 가능한 에러는 구체적인 안내를 통해 해결하고 예측 불가능한 에러는 일반적 메세지를 표시 후, 재시도를 유도한다.

export function handleApiError(error: AxiosError) {
  // 1. 예측 가능 에러
  if (error.response?.status === 401) {
    clearAuth();
    router.push('/login');
    return;
  }
  
  if (error.response?.status === 422) {
    showValidationErrors(error.response.data.errors);
    return;
  }
  
  // 2. 예측 불가능 에러
  if (error.response?.status >= 500) {
    Sentry.captureException(error);
    showToast('서버 오류가 발생했습니다. 잠시 후 다시 시도해주세요');
    return;
  }
}

https://sanghaklee.tistory.com/61

REST API 관점에서 바라보는 HTTP 상태 코드(HTTP status code)

REST API 관점에서 바라보는 HTTP 상태 코드(HTTP status code) TOC Introduction HTTP 와 REST HTTP Status Code 2XX Success 4.1. 200 OK 4.2. 201 Created 4.3. 202 Accepted 4.4. 204 No Content 4XX Client errors 5.1. 400 Bad Request 5.2. 401 Unauthori

sanghaklee.tistory.com

https://naver.github.io/naver-openapi-guide/errorcode.html

네이버 오픈 API 에러 코드 목록

네이버 오픈 API 에러 코드 목록 API를 호출하면 HTTP Status Code로 API 처리 결과를 받고 HTTP Response Body로 응답 값을 받습니다. 응답 값은 OpenAPI에 따라 XML또는 JSON형식이 될 수 있습니다. 따라서 API 응

naver.github.io

ErrorBoundary 설계 패턴

Error Boundary

React 컴포넌트 트리에서 발생한 JavaScript 에러를 포착하는 컴포넌트

에러 발생 시, 대체 UI(Fallback UI)를 보여주기 위한 컴포넌트

1. 직접 구현 (Class Component)

ErrorBoundary 클래스를 직접 구현하는 방법

getDerivedStateFromError() 에러가 발생한 후, UI 렌더링에 사용(Fallback UI 렌더링용)
componentDidCatch() commit 단계에서 호출, 에러 정보 기록에 사용

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // 다음 렌더링에서 폴백 UI를 보여주도록 상태 업데이트
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // 에러 로깅 (Sentry 등)
    console.error('Error caught:', error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return <h1>문제가 발생했습니다.</h1>;
    }

    return this.props.children;
  }
}

구현 후, 컴포넌트를 감싸는 방식으로 애플리케이션에서 에러 바운더리 사용 가능

MyComponent나 하위 컴포넌트 중 어떤 컴포넌트가 렌더링 중 에러를 발생시킨다면, 에러 바운더리가 이를 잡아내 기록한 뒤 대체 UI를 렌더링한다.

<ErrorBoundary>
  <MyComponent />
</ErrorBoundary>

2. react-error-boundary 라이브러리 사용

https://www.npmjs.com/package/react-error-boundary?activeTab=readme

제공하는 라이브러리를 사용하는 방법

pnpm install react-error-boundary

라이브러리를 사용하면 별도의 클래스 생성 없이, import를 통해 라이브러리를 호출해 에러 발생 시, fallback UI를 호출할 수 있다.

import { ErrorBoundary } from 'react-error-boundary';

<ErrorBoundary fallback={<div>에러가 발생했습니다</div>}>
  <MyComponent />
</ErrorBoundary>

라이브러리에서는 추가적으로 아래와 같은 기능이 있다.

resetErrorBoundary() 사용 예시

FallbackComponent 에러 UI 정의(error, resetErrorBoundary 자동 전달)
- resetErrorBoundary() 호출 시, 에러 상태 초기화 및 자식 컴포넌트 재 렌더링(다시 시도의 역할)
onReset 다시 시도 클릭 시, 캐시/상태 초기화
onError 에러 발생 시, Sentry 같은 모니터링 도구에 자동 전송
resetKeys 배열 안 값 변경되면 에러 상태 자동 리셋

import { ErrorBoundary } from 'react-error-boundary';

// 1. FallbackComponent: 에러 UI
function ErrorFallback({ error, resetErrorBoundary }) {
  return (
    <div>
      <h2>문제가 발생했습니다</h2>
      <p>{error.message}</p>
      <button onClick={resetErrorBoundary}>다시 시도</button>
    </div>
  );
}

function App() {
  const [userId, setUserId] = useState(1);
  
  return (
    <ErrorBoundary
      // 1. FallbackComponent: 에러 발생 시 보여줄 컴포넌트
      FallbackComponent={ErrorFallback}
      
      // 2. onReset: 리셋 버튼 클릭 시 실행할 추가 로직
      onReset={() => {
        queryClient.clear(); // 캐시 초기화
      }}
      
      // 3. onError: 에러 발생 시 로깅 (Sentry 전송)
      onError={(error, errorInfo) => {
        Sentry.captureException(error);
      }}
      
      // 4. resetKeys: userId 변경 시 에러 자동 리셋
      resetKeys={[userId]}
    >
      <UserProfile userId={userId} />
    </ErrorBoundary>
  );
}

https://velog.io/@wjdals189/React%EC%9D%98-Error-Boundary-%EA%B7%B8%EB%A6%AC%EA%B3%A0-react-error-boundary-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC

React의 Error Boundary 그리고 react-error-boundary 라이브러리

Error Boundary란 무엇이고 어디서 어떻게 쓰여지는지 궁금해서 찾아보며 이해하는 글에러 경계는 컴포넌트 트리가 깨지는 대신 자식 컴포넌트 트리에서 에러를 잡아내고, 이러한 에러의 로그를 남

velog.io

Error Boundary가 잡을 수 있는 에러와 없는 에러

잡을 수 있는 에러

렌더링 중 발생한 에러
생명주기 메서드 내 에러
하위 컴포넌트의 constructor 에러

잡을 수 없는 에러

이벤트 핸들러 (onClick, onChange 등)
비동기 코드 (setTimeout, Promise, async/await)
서버 사이드 렌더링
Error Boundary 자체에서 발생한 에러

https://wikidocs.net/197630

04) 에러 바운더리와 컴포넌트 에러 처리

[TOC] ## React에서의 에러 바운더리 소개 어떤 애플리케이션에서든 에러를 우아하게 처리하는 것은 원활한 사용자 경험을 제공하기 위해 중요합니다. React는 컴포넌…

wikidocs.net

https://velog.io/@coddingyun/Error-Boundary%EC%97%90%EB%9F%AC-%EB%B0%94%EC%9A%B4%EB%8D%94%EB%A6%AC%EB%A1%9C-%EC%9A%B0%EC%95%84%ED%95%98%EA%B2%8C-%EC%97%90%EB%9F%AC-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0

Error Boundary(에러 바운더리)로 우아하게 에러 처리하기

\*\*공식 문서(https://react-ko.dev/reference/react/Component> 기본적으로 애플리케이션이 렌더링 도중 에러를 발생시키면 React는 화면에서 해당 UI를 제거합니다. 이를 방지하기 위해 UI의 일부를 에러 경계(

velog.io

선언적 vs 명령적 처리 전략 비교

명령적 에러 처리(Imperative)

에러 처리 과정을 단계별로 명시하는 방식

어떻게(How) 처리할지 직접 작성

특정 조건별로 다른 처리 가능
코드가 길고 복잡하며 에러 처리 로직이 비즈니스 로직과 섞여 재사용성이 낮음

// 1. 이벤트 핸들러 (Error Boundary가 못 잡음)
const handleSubmit = async () => {
  try {
    await submitForm();
  } catch (error) {
    showToast('제출 실패');
  }
};

// 2. 조건별 다른 처리가 필요할 때
try {
  await fetchData();
} catch (error) {
  if (error.code === 'AUTH_ERROR') {
    router.push('/login');
  } else if (error.code === 'NETWORK_ERROR') {
    showOfflineMode();
  }
}

선언적 에러 처리(Declarative)

에러 발생 시 무엇을(What) 보여줄지만 선언

처리 과정은 프레임워크/라이브러리가 담당

코드가 간결하고 읽기 쉽고 에러 처리 로직이 분리되어 재사용성이 높음
세밀한 제어가 어렵고 ErrorBoundary가 못잡는 에러 존재

// 1. 렌더링 중 에러
<ErrorBoundary FallbackComponent={ErrorUI}>
  <MyComponent />
</ErrorBoundary>

// 2. 비동기 데이터 로딩
<ErrorBoundary>
  <Suspense fallback={<Loading />}>
    <UserData />
  </Suspense>
</ErrorBoundary>

구분	명령적 처리	선언적 처리
방식	try-catch, if-else, 상태 관리	Error Boundary, Suspense
에러 처리 위치	컴포넌트 내부	컴포넌트 외부
코드 길이	길고 복잡함	짧고 간결함
가독성	비즈니스 로직과 섞임	분리되어 깔끔
재사용성	낮음 (매번 작성해야 함)	높음 (한 번만 설정)
제어 수준	세밀한 제어 가능	제한적
사용 예	이벤트 핸들러, 특수한 경우	렌더링 에러, 비동기 데이터

따라서, 렌더링은 선언적 에러 처리를 이벤트는 명령적 에러 처리를 하는 것이 좋다.

https://velog.io/@seyoung8239/Imperative-vs-Declarative-Programming

Imperative vs Declarative Programming

프로그래머스에서 과제형 테스트를 연습하다 다음과 같은 요구사항을 만났다."가급적 컴포넌트 형태로 추상화 하세요."해설에서는 이 요구사항이 DOM에 접근하는 부분을 최소화하고, 명령형 프

velog.io

https://tech.kakaopay.com/post/react-query-2/#:~:text=Error%20Boundary%EB%8A%94%20React%20Component%20%EB%82%B4%EB%B6%80%EC%97%90%EC%84%9C%20%EC%97%90%EB%9F%AC%EA%B0%80%20%EB%B0%9C%EC%83%9D%ED%95%9C,%EB%8C%80%EC%8B%A0%20%EB%AF%B8%EB%A6%AC%20%EC%A0%95%EC%9D%98%ED%95%B4%20%EB%91%94%20Fallback%20UI%EB%A5%BC%20%ED%99%94%EB%A9%B4%EC%97%90

React Query와 함께 Concurrent UI Pattern을 도입하는 방법 | 카카오페이 기술 블로그

카카오페이에서 React Query를 활용하여 Concurrent UI Pattern을 도입한 사례에 대해 소개합니다. 이 글은 연작 중 2편에 해당합니다. 1편: 카카오페이 프론트엔드 개발자들이 React Query를 선택한 이유, 2

tech.kakaopay.com

useMemo, useCallback을 활용한 상세 페이지 구현하기 (w. TMDB)

co-cherry — Sun, 12 Apr 2026 01:06:22 +0900

이전에 구현한 무한 스크롤 영화 페이지에 상세 페이지 모달을 제작해보았다.

이번 시간에는 아래 항목들을 학습해보려고 한다.

바운더리 패턴
useMemo / useCallback
React Devtools

Suspense / Error Boundary 패턴

Loading / Error UI를 상위 컴포넌트로 올려서 한 곳에서 처리하는 관심사 분리 패턴

Suspense 로딩 중에 보여 줄 대체 UI로, 자식 컴포넌트들이 로딩을 완료할 때까지 fallback 표시
Error Boundary Error를 catch 하는 컴포넌트로 에러 발생 시, fallback 표시

*fallback 로딩/에러 중 보여 줄 대체 UI

throw Promise  →  Suspense가 catch  →  fallback(로딩UI) 표시
throw Error    →  ErrorBoundary가 catch  →  fallback(에러UI) 표시

<ErrorBoundary fallback={<ErrorUI />}>       ← 에러 처리 담당
  <Suspense fallback={<Spinner />}>          ← 로딩 처리 담당
    <PostList />                             ← 데이터만 신경씀
  </Suspense>
</ErrorBoundary>

이 방식을 사용하면, 여러 컴포넌트가 모두 준비될 때까지 하나의 fallback으로 기다렸다가 한 번에 렌더링하게 된다.

상세 페이지 작성을 위해 이전 Movie 인터페이스를 확장해 MovieDetail 타입을 작성한다.

export interface Genre {
    id: number;
    name: string;
}

export interface MovieDetail extends Movie {
    genres: Genre[];
    runtime: number;
    tagline: string;
    status: string;
    vote_count: number;
    backdrop_path: string | null;
}

상세 데이터는 리스트가 아닌 MovieDetail 객체를 반환받으므로 /movie/{movieId} 경로로 데이터를 fetch 받는다.

export const getMovieDetail = async (movieId: number): Promise<MovieDetail> => {
    const res = await fetch(
        `${BASE_URL}/movie/${movieId}?language=ko-KR`,
        { headers }
    )
    if (!res.ok) throw new Error('Failed to fetch movie detail')
    return res.json()
}

Suspense를 이용하기 위해 기존에 사용하던 useQuery 대신 useSuspenseQuery를 이용한다.

useSuspenseQuery는 useQuery의 Suspense 버전으로 상태를 직접 반환하지 않고 throw로 위임한다.

같은 queryKey면 재요청 없이 저장된 데이터 반환
진행 중이면 Promise throw → 가장 가까운 <Suspense> 가 받아 fallback 실행
실패하면 Error throw → 가장 가까운 <ErrorBoundary> 가 받아 fallback 실행

export const useGetMovieDetail = (movieId: number) =>
  useSuspenseQuery({
    queryKey: movieKeys.detail(movieId),
    queryFn: () => getMovieDetail(movieId),
    staleTime: 1000 * 60 * 5,
  })

모달 상세 페이지 구현 후, fallback으로 사용할 skeletonUI를 아래와 같은 형태로 컴포넌트를 생성한다.

function MovieDetailModal({ movieId, onClose }: Props) {
  return (
    <div className="fixed inset-0 z-50 flex items-center justify-center bg-black/60 backdrop-blur-sm"
      onClick={onClose}>
      <div className="bg-white rounded-2xl shadow-2xl w-full max-w-2xl mx-4 overflow-hidden relative"
        onClick={(e) => e.stopPropagation()}>
        <button
          onClick={onClose}
          className="absolute top-3 right-3 z-20 w-8 h-8 flex items-center justify-center rounded-full bg-black/40 text-white hover:bg-black/60 transition-colors cursor-pointer">
          <svg xmlns="http://www.w3.org/2000/svg" className="w-4 h-4" fill="none" viewBox="0 0 24 24" stroke="currentColor">
            <path strokeLinecap="round" strokeLinejoin="round" strokeWidth={2} d="M6 18L18 6M6 6l12 12" />
          </svg>
        </button>

        <ErrorBoundary fallback={<ModalError />}>
          <Suspense fallback={<ModalSkeleton />}>
            <MovieDetailContent movieId={movieId} />
          </Suspense>
        </ErrorBoundary>
      </div>
    </div>
  )
}

Suspense와 Error Boundary는 Content 영역을 대체함으로 모달 창과 닫기 버튼 밑에 구성한다.

로딩 중 → ModalSkeleton 렌더링
에러 시 → ModalError 렌더링
성공 시 → Content 렌더

결과

useMemo / useCallback

위까지 구현했더니 모달을 열고 닫을 때마다 TanstackQuery가 전체 리렌더 되는 문제가 발생한다.

이를 해결하기 위해 useMemo와 useCallback에 대해 배워보자.

useMemo

함수의 결과 값을 메모이제이션하여 비용이 많이 드는 계산을 최적화할 때 사용

const value = useMemo(() => {
  return calculate();
}, [item]);

의존성 배열 안의 값이 업데이트 될 때만 콜백 함수를 다시 호출해 메모리에 저장된 값을 업데이트
의존성이 변경되지 않으면 이전에 계산한 값을 그대로 재사용

useMemo는 외부 상태에 의존하지 않는 순수한 계산에만 사용하는 것이 원칙

useCallback

함수를 메모이제이션하여 필요할 때만 생성하도록 하는 훅

useMemo가 값의 계산 결과를 캐싱하는 것과 달리, useCallback은 함수 자체를 캐싱한다.

함수는 객체이므로 리렌더링 될 때마다 새로 만들어지면 내용이 같아도 참조값이 달라져 항상 새 props로 인식하게 됨

const handleIncreaseCount = useCallback((number: number) => {
  setCount(count + number);
}, [count]);

의존성 배열의 값이 변경되지 않으면 이전에 생성한 함수의 참조 값 그대로 사용

의존성 배열이 빈 배열이면 useCallback은 항상 같은 함수 참조를 반환해 함수 내부에서 참조하는 상태값이 초기값으로 고정되어 아무리 클릭해도 값이 변하지 않는 문제가 발생할 수 있다.

따라서, 함수 내부에서 참조하는 상태나 props는 반드시 의존성 배열에 포함시켜야 한다.

const handleIncreaseCount = useCallback((number: number) => {
  setCount(count + number);
  // 빈 배열이면 count는 항상 0으로 고정
  // 클릭해도 0 + 10 = 10에서 변하지 않음
}, []); // ❌

useCallback 단독으로는 하위 컴포넌트의 리렌더링을 막을 수 없다.

하위 컴포넌트가 props를 비교하는 최적화가 되어 있지 않으면 함수 참조가 유지되어도 리렌더링이 발생하기 때문이다.

React.memo

함수형 컴포넌트를 메모이징하는 고차 컴포넌트

props가 동일하다면 이전 렌더 결과를 재사용하고 변경되었다면 리렌더링되도록 한다.

export default memo(CountButton);

useCallback + React.memo

useCallback 함수 참조를 안정적으로 유지 (고정)
React.memo props 참조값을 비교해 바뀐 게 없으면 리렌더링 스킵

먼저, TanstackQuery 페이지에 있는 movies(영화 목록) 계산에 useMemo를 적용해보겠다.

현재는 selectedMovieId가 바뀔 때마다 매번 재계산 하도록 되어 있는데,

이를 useMemo를 적용해 영화 목록 값을 캐싱해두고 data가 바뀔 때만 재계산하도록 수정했다.

// 현재 — selectedMovieId 바뀔 때마다 매번 재계산
const movies = data?.pages.map((page) => page.results).flat() ?? []

// 적용 후 — data가 바뀔 때만 재계산
const movies = useMemo(
  () => data?.pages.map((page) => page.results).flat() ?? [],
  [data]
)

이를 통해 리렌더가 발생해 모달을 열고 닫을 때마다 movies가 재계산되는 문제를 해결했다.

이번에는 모달을 열고 닫을 때 각각의 카드들이 불필요하게 리렌더되는 문제를 해결해보겠다.

먼저, memo를 적용하려면 컴포넌트 형태여야 하므로 MovieCard를 컴포넌트로 분리하고 memo로 감쌌다.

import { memo } from 'react'
import type { Movie } from '../types/movie'

const IMAGE_BASE_URL = 'https://image.tmdb.org/t/p/w300'

interface Props {
  movie: Movie
  onClick: (id: number) => void
}

const MovieCard = memo(({ movie, onClick }: Props) => {

  return (
    <div className="flex flex-col cursor-pointer" onClick={() => onClick(movie.id)}>
      <div className="relative bg-gray-200 rounded overflow-hidden aspect-2/3 w-full">
        {movie.poster_path ? (
          <img
            src={`${IMAGE_BASE_URL}${movie.poster_path}`}
            alt={movie.title}
            className="w-full h-full object-cover"
          />
        ) : (
          <div className="w-full h-full flex items-center justify-center text-gray-400 text-xs">
            No Image
          </div>
        )}
        {movie.adult && (
          <span className="absolute top-1 left-1 w-5 h-5 bg-red-600 text-white text-[10px] font-bold rounded-full flex items-center justify-center">
            19
          </span>
        )}
      </div>
      <p className="mt-1 text-gray-800 text-xs truncate font-bold">{movie.title}</p>
      <button className="mt-1 border border-gray-300 py-1 rounded text-gray-700 text-xs hover:bg-gray-100 transition-colors cursor-pointer">
        예매하기
      </button>
    </div>
  )
})

export default MovieCard

인라인 화살표 함수로 작성된 모달 열기/닫기 함수를 useCallback으로 감싸 함수 참조를 유지한다.

useCallback으로 감싸면 의존성이 바뀌지 않는 한 같은 함수 참조를 유지하므로 memo가 "함수가 그대로다"라고 판단해 불필요한 리렌더를 건너뛸 수 있다.

// 전: 매 렌더마다 새 함수 생성
onClick={() => setSelectedMovieId(movie.id)}
onClose={() => setSelectedMovieId(null)}

// 후: 최초 한 번만 생성, 참조 유지
const handleCardClick = useCallback((id: number) => setSelectedMovieId(id), [])
const handleClose = useCallback(() => setSelectedMovieId(null), [])

그 후, 위에서 작성한 MovieCard 컴포넌트와 onClick 함수를 교체했다.

<div className="grid grid-cols-5 gap-3">
              {isLoading
                ? Array.from({ length: 10 }).map((_, i) => <MovieCardSkeleton key={i} />)
                : movies.map((movie, index) => (
                    <MovieCard
                      key={`${index}-${movie.id}`}
                      movie={movie}
                      onClick={handleCardClick}
                    />
                  ))}

              {isFetchingNextPage &&
                Array.from({ length: 5 }).map((_, i) => <MovieCardSkeleton key={`next-${i}`} />)}
            </div>

            <div ref={observerRef} className="h-4" />
          </section>

        </main>
      </div>
      {selectedMovieId && (
        <MovieDetailModal
          movieId={selectedMovieId}
          onClose={handleClose}
        />
      )}

이로써 Suspense + Error Boundary 패턴과 memo, useCallback, useMemo를 활용한 렌더링 최적화까지 적용했다.

마지막으로, React Devtools를 이용해 최적화가 제대로 적용되었는지 확인해보자.

React DevTools

React로 만든 앱을 디버깅하고 분석할 수 있는 크롬 확장 프로그램

Components 현재 컴포넌트 트리와 props/state 확인
Profiler 렌더링 성능 측정 및 분석

Profiler를 이용해 모달을 열고 닫았을 때 MovieCard의 리렌더가 일어나는지 확인해보자.

모달을 열었을 때 렌더링 결과다.

TanstackQuery가 리렌더되며 Suspense, ModalSkeleton, MovieDetailModal이 함께 렌더된 것을 볼 수 있다.

목록에 MovieCard가 보이지 않는데, memo가 적용되어 모달 열기/닫기 시 MovieCard의 리렌더가 발생하지 않았음을 의미한다.

useCallback으로 onClick 함수 참조를 유지했기 때문에 memo가 props가 동일하다고 판단해 리렌더를 건너뛴 것이다.

게시판 CRUD

co-cherry — Mon, 30 Mar 2026 21:21:49 +0900

앞서 게시글 생성과 상세 조회를 구현했다.

이번 시간에는 게시글 삭제와 수정을 구현해보려고 한다.

게시글 삭제와 수정은 작성자만 가능하므로 작성자 권한 검증이 서비스 로직에 들어가야 함을 유의하고 API를 설계해보자.

게시글 삭제

게시글을 삭제하기 위해서는 삭제할 게시글의 Id와 권한 검증을 위해 해당 게시글을 삭제할 user의 Id가 필요하다.

게시글을 삭제하기 전에, 아래 두 가지의 검증이 필요하다.

해당 아이디의 게시글이 존재하는지 확인 → 아니라면 POST_NOT_FOUND 반환
해당 게시글의 작성자가 삭제 요청을 보낸 user와 일치하는지 확인(권한 검증) → 아니라면 POST_UNAUTHORIZED 반환

@Transactional
    public void deletePost(Long postId, Long userId) {
        Post post = postRepository.findById(postId)
                .orElseThrow(() -> new GeneralException(PostErrorCode.POST_NOT_FOUND));

        if (!post.getUser().getId().equals(userId)) {
            throw new GeneralException(PostErrorCode.POST_UNAUTHORIZED);
        }

        postRepository.delete(post);
    }

postRepository.delete에서 delete는 JpaRepository에서 기본으로 제공하는 메서드

후에 Controller를 아래와 같이 작성하면 된다.

반환값은 성공적으로 요청을 처리했다는 뜻에서 GeneralSuccessCode.OK를 반환했다.

게시글을 삭제했으므로 result는 null로 처리했다.

@DeleteMapping("/{postId}")
    public ApiResponse<Void> deletePost(@PathVariable Long postId, @RequestParam Long userId) {
        postService.deletePost(postId, userId);
        return ApiResponse.onSuccess(GeneralSuccessCode.OK, null);
    }

게시글 수정

게시글 수정을 구현할 때, PUT과 PATCH 중 어떤 것을 사용해야 할까 고민하다가 아래 글을 보게 되었다.

https://docs.tosspayments.com/blog/rest-api-post-put-patch

POST, PUT, PATCH의 차이점 | 토스페이먼츠 개발자센터

REST API 디자인의 기본이 되는 POST, PUT, PATCH 메서드를 자세히 살펴볼게요.

docs.tosspayments.com

멱등성(Idempotent)

같은 요청을 여러 번 해도 결과가 동일한 성질

멱등성 있음: 재시도 해도 안전
멱등성 없음: 매번 다른 결과 발생

Toss Payments 기반

PUT 100번 요청을 하더라도 전체 리소스를 완전히 교체하므로 멱등성 보장
PATCH 동시에 2개의 PATCH 요청이 오는 경우, 멱등성을 보장할 수 없음(비멱등성)

따라서 PATCH의 경우, 필요한 필드만 전달하는 이점이 있지만, 동시 요청 시 데이터 손실이나 예상치 못한 결과가 발생할 수 있어 멱등성을 보장하지 않는다.

이에 따라, 게시글 수정 API를 PUT으로 작성하기로 했다.

PUT을 통해 게시글 수정 시, 일부 값만 수정하는 것이 아닌 전체 값을 포함해야 하므로 DTO를 이와 같이 작성했다.

제목과 내용 둘 중 하나라도 빠지면 안 되기 때문에 @NotBlank 조건을 추가했다.

@Getter
public class PostUpdateRequestDto {

    @NotBlank(message = "제목은 필수입니다.")
    @Size(max = 50, message = "제목은 50자 이하여야 합니다.")
    private String title;

    @NotBlank(message = "내용은 필수입니다.")
    @Size(max = 1000, message = "내용은 1000자 이하여야 합니다.")
    private String content;
}

또, 필드 수정 시 Setter를 사용할 것인가를 두고 고민이 있었다.

Setter를 사용하면 간단하게 코드를 작성할 수 있는 이점이 있지만, 아래 글들을 참고해보면 지양하라는 말밖에 없었다...

https://colabear754.tistory.com/173

[OOP] Getter와 Setter는 지양하는게 좋다

목차 들어가기 전에 얼마 전 사내에서 Getter와 Setter를 함부로 사용하면 안되는 이유에 대한 세미나가 있었다. Setter에 대한 이야기는 워낙 많이 알려져있었지만 Getter에 대한 이야기는 잘 하지 않

colabear754.tistory.com

https://octoping.tistory.com/33

사내 세미나 - Getter와 Setter를 함부로 사용하면 안되는 이유;;

들어가기 앞서 지난 번에 작성했던 사내 세미나 - 테스트 코드에 대해 알아보자 세미나의 다음 편으로 진행한 세미나이다. Getter와 Setter의 사용을 금지하라 '리팩토링' 책의 저자로 유명한 Martin F

octoping.tistory.com

https://kcode-recording.tistory.com/339

[Spring] Getter/Setter를 지양하자?

편리해 보이는 @Getter / @Setter를 지양해야 한다? 지양을 해야하는 이유를 알기 전 @Getter / @Setter 애너테이션에 대해 먼저 알고가자! @Getter / @Setter 애너테이션이란? 자바를 공부하면서 객체 지향 프

kcode-recording.tistory.com

위 글들을 참고해 간단히 정리하자면,

Setter를 사용하면 안 되는 이유

1. 불명확한 의도(변경 의도를 알 수 없음)

// ❌ Setter — 뭘 하려는 건지 모름
post.setTitle("새 제목");
post.setContent("새 내용");

// ✅ Update() — 게시글을 수정한다는 의도가 명확
post.update("새 제목", "새 내용");

2. 검증 로직 추가 불가

// ❌ Setter — 빈 제목도 그냥 들어감
post.setTitle("");

// ✅ Update() — 메서드 안에서 검증 가능
public void update(String title, String content) {
    if (title == null || title.isBlank()) {
        throw new IllegalArgumentException("제목은 비울 수 없습니다.");
    }
    this.title = title;
    this.content = content;
}

3. 객체 일관성 유지의 어려움

// ❌ @Setter를 클래스에 붙이면 이런 것도 가능해짐
post.setCreatedAt(LocalDateTime.now()); // 생성일 조작 가능!
post.setId(999L);                       // PK 조작 가능!

// ✅ Update() — title, content만 딱 열림
// createdAt, id는 건드릴 수 없음

4. 다른 객체들로 책임이 분산

// ❌ Setter — 검증이 Service에도 있고, Controller에도 있고...
// PostService.java
post.setTitle(title);

// PostController.java
if (title.isBlank()) { ... } // 검증이 다른 곳에 따로 있음

// ✅ Update() — 로직이 엔티티 안에 응집
public void update(String title, String content) {
    // 검증 + 변경이 한 곳에
}

구분	Setter	Update 메서드
캡슐화	약함(아무나 변경 가능)	강함
비즈니스 로직	없음	로직 포함 가능
검증	검증 불가	검증 가능
복잡도	간단	복잡
버그 위험	높음	낮음

따라서, @Setter를 사용하는 대신 엔티티에 Update 메서드를 추가했다.

public void update(String title, String content) {
        this.title = title;
        this.content = content;
    }

이 메서드를 활용해 서비스 로직을 작성해보자.

삭제에서와 같이 수정 시, 아래 두 가지 검증이 필요하다.

해당 아이디의 게시글이 존재하는지 확인 → 아니라면 POST_NOT_FOUND 반환
해당 게시글의 작성자가 수정 요청을 보낸 user와 일치하는지 확인(권한 검증) → 아니라면 POST_UNAUTHORIZED 반환

둘 다 해당한다면, update 함수를 활용해 title과 content를 수정한다.

@Transactional
    public PostResponseDto updatePost(Long postId, Long userId, PostUpdateRequestDto request) {
        Post post = postRepository.findById(postId)
                .orElseThrow(() -> new GeneralException(PostErrorCode.POST_NOT_FOUND));

        if (!post.getUser().getId().equals(userId)) {
            throw new GeneralException(PostErrorCode.POST_UNAUTHORIZED);
        }

        post.update(request.getTitle(), request.getContent());

        return new PostResponseDto(
                post.getId(),
                post.getUser().getId(),
                post.getTitle(),
                post.getContent()
        );
    }

Controller는 아래와 같이 작성한다.

위에서 작성한 서비스를 실행해 반환받은 DTO 값을 result로 반환한다.

@PutMapping("/{postId}")
    public ApiResponse<PostResponseDto> updatePost(
            @PathVariable Long postId,
            @RequestParam Long userId,
            @Valid @RequestBody PostUpdateRequestDto request) {
        return ApiResponse.onSuccess(GeneralSuccessCode.OK, postService.updatePost(postId, userId, request));
    }

ERDCloud로 댓글(Comment)과 게시글(Post), 유저(User) 간 관계를 표현해보았다.

댓글은 수정 API를 따로 만들지 않았으나, 확장 가능성을 두기 위해 수정 일자 필드도 추가했다.

아래는 댓글의 엔티티다.

하나의 작성자는 여러 개의 댓글을 달 수 있으므로 1:N 관계

하나의 게시글에서 여러 개의 댓글을 달 수 있으므로 1:N 관계 로 명시했다.

또한, Post 때 처럼 setter 대신 엔티티 내 메서드를 이용해서 수정하도록 update 메서드를 작성했다.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Builder
@Table(name = "comment")
@EntityListeners(AuditingEntityListener.class)
public class Comment {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "comment_id")
    private Long id;

    @Column(name = "content", nullable = false)
    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "post_id", nullable = false)
    private Post post;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id", nullable = false)
    private User user;

    @CreatedDate
    @Column(name = "created_at", nullable = false)
    private LocalDateTime createdAt;

    @LastModifiedDate
    @Column(name = "updated_at")
    private LocalDateTime updatedAt;

    public void update(String content) {
        this.content = content;
    }
}

댓글 생성

DB에 접근하고 간편한 사용을 위해 엔티티 다음 레포지토리를 생성했다.

public interface CommentRepository extends JpaRepository<Comment,Long> {
}

또한, 댓글 생성 시 필요한 Request DTO와 Response DTO를 이와 같이 선언했다.

@Getter
public class CommentRequestDto {
    @NotNull(message = "사용자 ID는 필수입니다.")
    private Long userId;

    @NotNull(message = "게시글 ID는 필수입니다.")
    private Long postId;

    @NotBlank(message = "댓글 내용은 필수입니다.")
    @Size(max = 500, message = "댓글은 500자 이하여야 합니다.")
    private String content;
}


@Getter
@AllArgsConstructor
public class CommentResponseDto {
    private Long commentId;
    private Long postId;
    private Long userId;
    private String content;
}

서비스 로직은 게시글 생성과 비슷하게 작동하되, postId 검증 부분이 추가되었다.

게시글 존재 여부와 작성자(user) 존재 여부를 먼저 확인한 후, 댓글을 생성한다.

 @Transactional
    public CommentResponseDto createComment(CommentRequestDto request) {
        User user = userRepository.findById(request.getUserId())
                .orElseThrow(() -> new GeneralException(CommentErrorCode.USER_NOT_FOUND));

        Post post = postRepository.findById(request.getPostId())
                .orElseThrow(() -> new GeneralException(CommentErrorCode.POST_NOT_FOUND));

        Comment comment = Comment.builder()
                .content(request.getContent())
                .user(user)
                .post(post)
                .build();

        Comment savedComment = commentRepository.save(comment);

        return new CommentResponseDto(
                savedComment.getId(),
                savedComment.getPost().getId(),
                savedComment.getUser().getId(),
                savedComment.getContent()
        );
    }

생성 완료 시, 리소스가 성공적으로 생성되었다는 CREATED 코드를 반환하고 result로 생성한 Comment를 반환한다.

@PostMapping
    public ApiResponse<CommentResponseDto> createComment(@Valid @RequestBody CommentRequestDto request) {
        return ApiResponse.onSuccess(GeneralSuccessCode.CREATED, commentService.createComment(request));
    }

댓글 삭제

게시글 삭제 때와 동일하게, 댓글 존재 여부와 댓글 작성자가 현재 댓글 삭제를 요청하는 유저와 동일한지 검증한다.

@Transactional
    public void deleteComment(Long commentId, Long userId) {
        Comment comment = commentRepository.findById(commentId)
                .orElseThrow(() -> new GeneralException(CommentErrorCode.COMMENT_NOT_FOUND));

        if (!comment.getUser().getId().equals(userId)) {
            throw new GeneralException(CommentErrorCode.COMMENT_UNAUTHORIZED);
        }

        commentRepository.delete(comment);
    }

댓글이 정상적으로 삭제되면 OK 코드를 반환하고, 삭제되었으므로 result로는 null을 반환한다.

@DeleteMapping("/{commentId}")
    public ApiResponse<Void> deleteComment(
            @PathVariable Long commentId,
            @RequestParam Long userId) {
        commentService.deleteComment(commentId, userId);
        return ApiResponse.onSuccess(GeneralSuccessCode.OK, null);
    }

정상적으로 동작하는지 확인해보겠다.

게시글 작성을 하니 postId로 2가 반환되며, 작성한 게시글 내용이 보인다.

방금 작성한 게시글을 수정하니 아래와 같이 수정한 내용이 반환된다.

상세 조회를 해보아도 수정한 내용으로 보인다.

만약, 존재하지 않는 게시글을 삭제하려 한다면 게시글을 삭제할 수 없다고 404 에러 메세지가 나온다.

권한이 없는 사용자가 게시글을 삭제하려 하면 아래와 같은 403 에러 메세지가 뜬다.

정상적으로 삭제하면 이렇게 요청이 성공적으로 처리되었다는 말과 함께 null이 반환된다.