COUNT(*) 대신 EXISTS 써보기

안녕하세요, 백엔드 개발자입니다.백엔드 로직을 구현하다 보면, 특정 조건에 맞는 데이터가 '존재하는지' 여부만 확인하면 되는 경우가 많습니다. 예를 들면 다음과 같은 상황입니다.사용자가 닉네임 중복 확인을 요청했을 때게시글에 좋아요를 눌렀는지 여부를 확인할 때이런 경우, 가장 먼저 떠오르는 방법은 COUNT(*)를 사용하는 것입니다.SELECT COUNT(*)FROM usersWHERE nickname = 'supiz';이 쿼리의 결과가 0보다 크면 '존재한다', 0이면 '존재하지 않는다'고 판단하는 방식이죠.매우 직관적이고 저 또한 오랫동안 습관적으로 사용해왔습니다. 하지만 '존재 여부' 확인이 목적이라면, COUNT(*)는 성능상 비효율을 유발할 수 있습니다.이번 글에서는 이런 상황에서 EXISTS를..
Backend 2025. 9. 8. 23:23

OFFSET 페이지네이션 개선하기: 커서 기반 페이지네이션 도입

안녕하세요, 백엔드 개발자입니다. 지난 편에서는 OFFSET을 사용한 페이지네이션이 데이터 규모가 커질수록 왜 성능 문제를 일으킬 수 있는지 알아보았습니다. 불필요한 데이터를 대량으로 읽고 버리는 내부 동작 방식 때문이었죠.이번 글에서는 이에 대한 해결책으로, 대규모 서비스에서 안정적인 성능을 위해 사용하는 '커서 기반 페이지네이션(Cursor-based Pagination)' 기법을 소개하겠습니다.1. 접근 방식의 전환: 페이지 번호에서 데이터 기준으로커서 기반 페이지네이션의 핵심 아이디어는 '페이지 번호' 대신 '특정 데이터의 위치'를 기준으로 다음 목록을 조회하는 것입니다.OFFSET 기반: "3번째 페이지의 목록을 줘"커서 기반: "지난번 마지막으로 본 게시글 ID 12345 다음 목록을 줘"여기..
Backend 2025. 9. 2. 14:55

목록 조회 API, OFFSET 페이지네이션 괜찮을까?

안녕하세요, 백엔드 개발자입니다. 게시판, 상품 목록, SNS 피드 등 많은 서비스에서 페이지네이션(Pagination) 기능은 필수적입니다. 이때 가장 흔히 사용되는 방법은 LIMIT과 OFFSET 키워드를 활용하는 것입니다.-- 3번째 페이지의 게시글 10개를 조회SELECT *FROM postsORDER BY id DESCLIMIT 10 OFFSET 20; -- 앞의 20개를 건너뛰고, 10개를 조회이 방식은 코드가 직관적이고 "N번째 페이지로 바로 이동" 같은 기능을 구현하기 편리하다는 장점이 있습니다.하지만 서비스 규모가 커지고 데이터가 쌓이면, 이 편리함이 성능 저하의 원인이 되기도 합니다. 이번 글에서는 OFFSET을 사용한 페이지네이션이 어떤 방식으로 동작하고, 왜 성능 이슈를 유발할 수 ..
Backend 2025. 9. 1. 17:14

나만의 데코레이터 만들기: 실전 기능 구현

안녕하세요, 백엔드 개발자입니다.지난 1편에서는 applyDecorators를 사용하여 여러 데코레이터를 하나로 묶는 기본적인 방법에 대해 알아보았습니다.이번 2편에서는 1편에서 다룬 기본 개념을 확장하여, 실제 프로젝트에서 사용하는 @ApiRoute 데코레이터의 전체 코드를 살펴보며 어떤 실용적인 기능들을 추가할 수 있는지 자세히 분석해 보겠습니다.인증, 파일 업로드, API 문서화 등 데코레이터 하나로 처리하는 과정을 보실 수 있습니다.1. 우리의 설계도: ApiRouteOptions 인터페이스좋은 데코레이터는 사용하는 사람이 어떤 옵션을 사용할 수 있는지 명확하게 알려주는 것에서 시작합니다. @ApiRoute가 처리할 모든 기능을 인터페이스로 먼저 정의합니다.// decorators/route/in..
Backend 2025. 8. 29. 09:57

나만의 데코레이터 만들기: NestJS에서 반복적인 API 설정 줄이기

안녕하세요, 백엔드 개발자입니다.NestJS로 REST API를 개발하다 보면, 하나의 API 엔드포인트를 정의하기 위해 여러 데코레이터를 함께 사용하는 경우가 많습니다.// 일반적인 NestJS 컨트롤러 메소드@Post('/')@ApiOperation({ summary: '새로운 리소스 생성' })@ApiCreatedResponse({ description: '성공적으로 생성됨' })@UseGuards(JwtAuthGuard, RolesGuard)@Roles('admin')async createResource(@Body() createDto: CreateResourceDto) { // ...}HTTP 메소드, Swagger 문서, 응답 스펙, 그리고 인증/인가 가드까지. 기능적으로는 명확하지만, AP..
Backend 2025. 8. 27. 16:58

서버 부하를 줄이는 이미지 업로드 전략 (3편): 유연한 썸네일 URL 관리 패턴

안녕하세요, 백엔드 개발자입니다.지난 1편과 2편에 걸쳐, 서버의 부하를 줄이기 위한 이미지 업로드 전략과 실제 구현 방법을 알아보았습니다. 이제 S3에는 원본 이미지와 함께 리사이징된 썸네일 이미지가 잘 저장되고 있습니다.이번 마지막 3편에서는 이렇게 업로드된 이미지들의 URL을 어떻게 관리하는 것이 효율적인지, 작지만 장기적인 유지보수성에 큰 영향을 미치는 URL 관리 패턴에 대해 이야기해 보겠습니다.1. 일반적인 접근: 모든 URL을 DB에 저장하기가장 직관적인 방법은 생성된 모든 이미지의 URL을 DB에 각각 저장하는 것입니다.CREATE TABLE `resources` ( `id` int NOT NULL AUTO_INCREMENT, `resource_url` varchar(255) DEFAU..
Backend 2025. 8. 24. 16:19

서버 부하를 줄이는 이미지 업로드 전략 (2편): Multer 스트리밍 파이프라인 구현

안녕하세요, 백엔드 개발자입니다.지난 1편에서는 이미지 업로드 시 서버 부하를 줄이기 위해, 스트리밍 파이프라인을 구성하고 역할을 분리하는 전략에 대해 알아보았습니다.이번 2편에서는 그 전략을 실제로 구현하는 방법에 대해 자세히 다뤄보겠습니다. NestJS 환경에서 multer와 multer-s3-transform 라이브러리를 사용하여, 이벤트 루프를 막지 않는 스트리밍 파이프라인을 구축해 보겠습니다.1. 스트리밍 파이프라인의 원리multer-s3-transform 라이브러리의 핵심은 여러 스트림을 파이프처럼 연결하는 것입니다.HTTP Request Stream → Sharp Transform Stream → S3 Upload Stream데이터는 큰 덩어리가 아닌 작은 조각(chunk)으로 위 파이프라인..
Backend 2025. 8. 21. 13:40