스파킷 - SparkIT

[MYSQL] Like 연산자와 %,_ 와일드카드를 이용한 검색 성능 개선하기(InnoDB)

SparkIT — Sat, 25 Oct 2025 14:24:59 +0900

데이터베이스를 다루다 보면 “부분 검색”이 꼭 필요할 때가 있습니다.
예를 들어 이름이 '김'으로 시작하거나 포함된 사용자를 찾고 싶을 때 다음과 같은 쿼리를 자주 작성하죠.

SELECT * FROM users WHERE name LIKE '%김%';

하지만 이런 쿼리는 굉장히 느리게 동작하여 시스템에 무리를 일으키기도 합니다. 인덱스도 걸어놨는데, 왜 느릴까요?
이번 글에서는 MySQL의 LIKE 연산자와 와일들카드 그리고 인덱스가 어떻게 동작하는지 이해하고 이를 통해 어떻게 검색 성능을 개선할 수 있는지 여러 방법에 대해 고민해보겠습니다.

기본 용어 설명

먼저 기본부터 짚고 갑시다.
LIKE는 MySQL에서 비교 연산자(Comparison Operator) 중 하나입니다.
'=' 혹은 '>' 같은 비교 연사자처럼 두 값을 비교해서 TRUE/FALSE를 반환합니다.

SELECT * FROM users WHERE name LIKE '김%';

이 쿼리는 "김"으로 시작하는 문자열을 찾는 연산입니다.

LIKE와 함께 자주 쓰이는 특수 문자가 있습니다. 바로 와일드 카드 문자입니다.

와일드카드 예시

%	0개 이상의 임의의 문자	'김%' → "김", "김준", "김민수"
_	정확히 1개의 임의의 문자	'김_수' → "김민수", "김진수"

문자열 패턴을 만들 때 이 둘을 조합해 다양한 조건을 걸 수 있습니다.

B+Tree 구조는 문자열에 대한 인덱스를 생성할때 문자열의 가장 왼쪽부터 이용해 정렬한다

데이터베이스 조회 속도에 가장 큰 영향을 주는 것은 '인덱스'라고 말할 수 있습니다.

이런 인덱스의 구조부터 이해하고 갑시다.

우선 저는 MySQL의 InnoDB 엔진을 사용합니다. 해당 엔진에서는 B+Tree 기반 인덱스 구조를 사용합니다.

B+Tree 인덱스는 문자열을 정렬 가능한 값으로 바꾼 뒤 트리 형태로 만듭니다.

B+Tree 구조에 대한 간단한 예시입니다. 다음과 같은 이름 데이터가 5개 존재한다고 가정합시다.

김강민
김정구
이민혁
백호민
최호찬

그리고 이 데이터들은 'utf8mb4_general_ci' 으로 저장되어있다고 가정합니다. (utf8mb4_general_ci는 유니코드값을 기준으로 비교됩니다)

다음은 각 이름에 대한 유니코드값 정보입니다.

김강민 --> [44608, 44053, 48188]
김정구 --> [44608, 51221, 44428]
이민혁 --> [51060, 48188, 54849]
백호민 --> [48353, 54840, 48188]
최호찬 --> [52572, 54840, 52268]

이는 이름을 이루고 있는 각각의 문자에 대한 유니코드값을 배열로 표현한 것입니다. 예로 '김강민'의 '김'이 44608, '강'이 44053, '민'이 48188이라는 유니코드값을 가진 것이죠.

이 부분이 중요합니다!

B+Tree 구조에서는 문자열 정보를 저장할 때 유니코드값 배열을 왼쪽에서부터 비교하고 차례대로 정렬됩니다.

즉, 5개의 이름 데이터가 아래와 같이 정렬된다는 것이죠.

                          [EA B9 80 ... 김*] ──┬── [EB B0 ... 백*] ──┬── [EC 9D ... 이*]
                                              │                     │
                                              ▼                     ▼
                              [김강민, 김정구]          [백호민]          [이민혁, 최호찬]

여기서 두 가지 경우를 비교해봅시다.

경우1) '김'으로 시작하는 이름 찾기
경우2) 중간에 '호'가 들어가는 이름 찾기

첫번째 경우에서는 루트에서 '김'으로 시작하는 브랜치로 바로 이동할 수 있습니다. 이를 통해 '김강민'을 알아낼 수 있죠. 그리고 리프 노드들은 모두 양방향 연결되어있기 때문에 '김강민' --> '김정구' --> '백호민' 순서로 이동하면서 검사합니다. 이때 '백호민'이라는 데이터는 조건을 만족하지 않기에 '김강민', '김정구' 데이터만 반환됩니다. 이 과정에서는 조건에 맞는 첫번째 데이터를 찾기 굉장히 쉽고, 조건을 만족하지 않을 때까지 오른쪽으로 계속 이동하기만 되기 때문에 빠르게 처리됩니다.

두번째 경우에서는 루트에서 특정 브랜치로 이동 자체가 불가합니다. 이름 중간에 '호'가 있는 데이터는 여러 브랜치에 있을 수 있기 때문이죠. 그래서 결국 모든 데이터를 순환해야합니다. 이 과정은 모든 데이터를 탐색하게 되므로 느릴 수 밖에 없죠.

그럼 어떻게 조회(검색) 성능을 높일까?

상황에 따라 여러가지 방식을 활용할 수 있습니다.

방법 1 ) LIKE 연산자 + '검색어%' 형식으로 제한하기

위에서 설명했듯이 '검색어%' 형식처럼 접두사 검색은 인덱스를 활용할 수 있기에 성능상 이점이 있습니다.

그러므로 시작하는 문자열을 모두 적어야 제대로 된 검색이 가능하도록 UX를 설계하는 것이 첫번째 방법입니다.

방법 2 ) FULLTEXT INDEX 활용하기

InnoDB에서는 FULLTEXT 인덱스를 지원하는데요.

이는 단어 단위로 토큰화하여 검색할 수 있는 인덱스 구조입니다.

예를 들어 '안녕하세요. 저는 홍길동이라고 합니다' 라는 문자열을 저장한다면 '안녕하세요', '저는', '홍길동이라고', '합니다' 로 나누어 검색할 수 있다는 것입니다. '저는'이라는 단어를 검색하면 해당 문자열을 빠르게 조회할 수 있습니다.

하지만 이런 인덱스는 여러 단어를 구성된 문장을 저장할 때 사용되면 좋은 구조입니다.

위에서 예시로 들었던 이름 검색같은 경우에서는 이점이 없습니다.

방법 3 ) REVERSE INDEX 활용하기

문자열을 거꾸로 뒤집고, 이에 대한 인덱스를 생성하는 것도 생각해볼 수 있는 방법 중 하나입니다.

예를 들어 한국어로 된 이름을 검색할 때, 성을 빼고 검색하는 경우가 많을 수 있습니다.('김정구' 검색 시 '정구'라는 이름만 가지고 검색)

이런 경우에는 가장 마지막 문자열로부터 역으로 인덱스를 사용하면 위에서 설명했던 B+Tree 구조의 이점을 그대로 이용할 수 있어 성능 향상에 도움이 될 수 있습니다.

마무리

결국 인덱스를 활용한 조회의 핵심은 “정렬된 순서를 얼마나 잘 활용할 수 있느냐”에 있습니다.

LIKE, FULLTEXT, REVERSE INDEX 모두 이 정렬 특성을 어떤 방향으로 사용할지를 달리한 전략일 뿐이죠.

검색 성능을 높이는 일은 결국 기술의 문제가 아니라, 데이터와 검색 의도를 정확히 이해하는 일에서 출발합니다.

[TypeORM] 데이터베이스 마이그레이션

SparkIT — Sun, 25 May 2025 12:56:49 +0900

타입스크립트 사용 시 TypeORM 공식 문서에 따른 명령어는 에러가 발생하여 사용하지 못한다.

Migrations | typeorm

Once you get into production you'll need to synchronize model changes into the database. Typically, it is unsafe to use synchronize: true for schema synchronization on production once you get data in your database. Here is where migrations come to help. A

orkhan.gitbook.io

공식문서 상 명령어

npx typeorm-ts-node-esm migration:generate ./src/migrations/update-post-table -d ./src/data-source.ts

수정한 명령어

npm install --save-dev ts-node

npm install --save-dev typescript @types/node

npx ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js migration:generate src/migrations/migration -d src/data-source.ts

이때 migration:generate 뒤에 오는 파라미터는 경로라고 나오는데 이상한게 마지막 경로는 이름에 넣어짐.

ex) src/migrations/migration

--> 마이그레이션된 파일이 src/migrations/ 하위에 생기고 '숫자-migration'이런 식으로 이름 뒤에 하이픈 migration이렇게 들어감. 즉 마지막 경로는 파일명 뒤에 하이픈과 추가되는 것임.

반영

 npx ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js migration:run -d ./src/data-source.ts

데이터소스 예시

// src/data-source.ts

import { DataSource } from 'typeorm';
import * as dotenv from 'dotenv';
import 'reflect-metadata';

dotenv.config({ path: `.env.${process.env.NODE_ENV}` });

export default new DataSource({
	type: 'mysql',
	host: process.env.MYSQL_HOST,
	port: Number(process.env.MYSQL_PORT),
	username: process.env.MYSQL_USERNAME,
	password: process.env.MYSQL_PASSWORD,
	database: process.env.MYSQL_DATABASE,
	entities: ['src/**/*.entity.ts'],
	migrations: ['src/migrations/*.ts'],
	logging: true,
});

[Prisma] TypeORM vs Prisma 차이와 Prisma를 선택한 이유

SparkIT — Sun, 25 May 2025 12:55:43 +0900

타입스크립트를 이용해 개발하는 과정에서 사용할 수 있는 대표적인 ORM은 TypeORM과 Prisma입니다. 많은 사람들이 두 ORM 중 하나를 선택하는데요. 이때 두 ORM 중 어떤 것을 채택하는 것이 더 좋을지에 대해 많이 궁금하실 것입니다. 저도 마찬가지였습니다. 저는 타입스크립트 초기부터 현재까지 TypeORM을 잘 활용해오고 있었는데요. 이번에 새롭게 시작하는 프로젝트에는 TypeORM 대신 Prisma를 도입하기로 결정했습니다. 오늘은 그 이유를 TypeORM과 Prisma를 비교하며 공유해보려 합니다.

참고자료

Prisma ORM vs TypeORM | Prisma Documentation

Learn how Prisma compares to TypeORM.

www.prisma.io

TypeORM vs Prisma

TypeORM과 Prisma를 비교한 간단한 표입니다.

	TypeORM	Prisma
패러다임	Code-First ORM	Schema-First ORM
모델 정의	TypeScript 클래스 + 데코레이터 사용	schema.prisma 파일로 정의 (선언적 방식)
쿼리 작성	엔티티 메서드 또는 Repository 사용	Prisma Client를 통한 타입 안전한 쿼리
타입 안전성	제한적 (특히 쿼리에서)	매우 강력 (컴파일 타임에서 오류 탐지 가능)
마이그레이션	수동으로 SQL 작성 또는 TypeORM CLI 사용	Prisma Migrate로 자동 마이그레이션 생성 및 적용
관계 처리	복잡한 관계 설정 시 코드가 난해해질 수 있음	관계 정의가 명확하고, 연결된 쿼리도 직관적
성능 및 최적화	중간 수준, 일부 성능 문제 보고 있음	최적화된 쿼리 및 요청 배치 기능 제공

TypeORM은 사실 JAVA Spring 진영의 JPA와 상당히 닮은 ORM입니다. OOP 스타일 패러다임을 사용해 데이터베이스 내 테이블과 1:1 매핑되는 엔티티 클래스를 만드는 방식을 사용합니다. 반면에 Prisma는 스키마 기반의 ORM으로 데이터베이스 모델을 schema.prisma 파일 하나에 모두 정의합니다. 이 파일을 활용해 타입 안정성을 제공합니다. 또한 Prisma는 마이그레이션 관리와 최적화된 쿼리를 제공합니다. 아래는 Prisma를 선택하면서 느낀 장점과 단점입니다.

Prisma 장점

1. 타입 안정성

TypeORM 쿼리에서 잘못된 속성을 사용하는 경우를 컴파일 단계에서 잡지 못합니다. 즉, 다음과 같은 예시에서 에러가 발생하지 않습니다.

const user = await userRepository.findOne({
  where: { wrongField: 'test'} //   문제없는거 아닌가?
});

하지만 Prisma에서는 잘못된 속성을 사용하면 이를 컴파일 단계에서 잡아줍니다.

const user = await prisma.user.findUnique({
  where: { wrongField: 'test' }, // ❗️ 타입 오류 발생
});

Prisma 단점

1. enum

데이터베이스 테이블 컬럼 중 enum 타입을 사용해야 하는 경우가 있습니다. TypeORM을 사용하던 때에는 애플리케이션 레벨에서 먼저 enum을 정의하고 이를 DB에 반영했습니다. 즉, enum이라는 코드 파일을 먼저 작성하고 @Entity 코드에서 이를 import 해 사용하게 했습니다.

하지만 prisma의 경우 prisma.schema라는 스키마 설정 파일에 모든 enum을 설정해야 합니다.(제가 알기로는 외부 enum 파일 import 불가합니다) 이때 저는 도메인 모델을 만들어 사용 중이었는데요. 이 과정에 도메인 모델에 사용할 enum 파일을 따로 만들어야 한다는 문제점이 발생했습니다. 물론 prisma.schema에 작성한 enum값은 prisma client를 생성할 때 자동으로 @prisma/client 경로에 타입으로 생성됩니다. 이를 그대로 사용하면 prisma.schema에 설정된 enum을 그대로 외부에서 사용할 수 있죠. 하지만 이 경우 도메인 모델과 prisma라는 ORM 간 높은 결합도가 생깁니다. 중간에 prisma typeORM으로 교체하게 되면 도메인 모델 부분도 수정해야 한다는 뜻이죠. 저는 이런 부분이 prisma의 단점이라고 느꼈습니다.

[Github] private 레포지토리 clone 에러 - remote: Repository not found

SparkIT — Sat, 10 May 2025 16:46:37 +0900

에러 상황

git clone {레포지토리 URL}

github에서 운영중인 private 레포지토리 코드를 clone 받으려는 상황. 아래와 같은 에러 발생

Cloning into '{레포지토리명}'...
remote: Repository not found.
fatal: repository '{레포지토리 URL}' not found

에러 코드를 읽어보면 해당 레포지토리를 찾지 못한다는 내용입니다. 하지만 보통 이런 경우 레포지토리 URL이 잘못된 경우는 많지 않습니다. 다른 이유가 더 일반적입니다. 그 이유는 바로 해당 레포지토리가 private이기 때문에 접근 권한이 없어 발생하는 에러입니다.

해결 방법

1. Github 퍼스널 토큰 발급

Github 홈페이지에서 Settings 클릭

github 퍼스널 토근을 발급하기 위해서는 github 접속 시 우측 상단에 위치한 자신의 프로필 이미지를 클릭해 사이드 메뉴를 확인합니다. 사이드 메뉴에서 'Settings' 탭을 클릭합니다.

Developer settings 클릭

Settings 탭에서 왼쪽 최하단에 있는 'Developer settings' 탭을 클릭합니다.

Personal access tokens 하위 토큰 종류 중 원하는 토큰 클릭

Developer settings 탭에서 Personal access tokens 탭을 통해 private 레포지토리에 접근할 수 있게 도와주는 퍼스널 토큰 발급이 가능합니다. 위 사진과 같이 현재 토큰 방식에는 2 가지 방식이 존재합니다. 두 종류에 큰 차이는 없습니다. 원하는 방식을 선택해 안내를 따라 퍼스널 토큰 발급을 마무리 합니다.

⚠️ 퍼스널 토큰 저장해놓기
퍼스널 토큰은 발급 이후 다시 조회할 수 없습니다. 만약 퍼스널 토큰을 분실하셨을 시 재발급 밖에 방법이 없습니다. 이 때문에 퍼스널 토큰을 발급받은 뒤 계속 재사용하기 위해서는 해당 토큰을 개인적으로 보관하셔야 합니다.

2. git clone 시 유저명과 퍼스널 토큰 입력

public 레포지토리는 다음과 같은 방식으로 단순하게 클론 가능합니다.

git clone {레포지토리 URL}

하지만 private 레포지토리는 다음과 같이 clone하셔야합니다. 더 자세히 설명드리자면 기존 레포지토리 URL에서 'https://' 와 'github.com' 사이에 방금 퍼스널 토큰을 발급받은 github 계정의 유저명과 '@' 문자를 넣어주는 것입니다.

❗️public repository
git clone https://github.com/SHINDongHyeo/test.git

✅ private repository
git clone https://SHINDongHyeo@github.com/SHINDongHyeo/test.git

그럼 아래와 같이 퍼스널 토큰을 입력하라는 안내가 표시됩니다.

Cloning into 'test'...
Password for 'https://SHINDongHyeo@github.com':   여기에 퍼스널 토큰값 입력

퍼스널 토큰까지 입력해주면 성공적으로 레포지토리가 clone 되는 모습을 확인할 수 있습니다.

[MySQL] 쿼리 실행 계획(Query Execution Plan)을 통해 쿼리 최적화하기

SparkIT — Tue, 6 May 2025 21:57:31 +0900

쿼리 실행 계획은 데이터베이스에서 특정 SQL 쿼리문을 실행할 때, DB 옵티마이저가 해당 쿼리를 어떻게 실행할 지에 대한 계획을 의미합니다. 그래서 효율적인 데이터베이스 활용을 위해서는 쿼리 실행 계획에 대해 파악하는 것은 필수입니다. 저는 평소에 MySQL 데이터베이스를 많이 사용합니다. 그래서 오늘은 MySQL에서 쿼리 실행 계획을 확인하고 이를 통해 더 좋은 쿼리를 작성하는 방법에 대해 공유해보려합니다.

쿼리 실행 계획이란?

MySQL :: MySQL 8.4 Reference Manual :: 10.8 Understanding the Query Execution Plan

10.8 Understanding the Query Execution Plan Depending on the details of your tables, columns, indexes, and the conditions in your WHERE clause, the MySQL optimizer considers many techniques to efficiently perform the lookups involved in an SQL query. A qu

dev.mysql.com

DBMS(MySQL, PostgreSQL 등)가 SQL 쿼리를 실제로 어떻게 처리할지에 대한 단계별 계획을 말합니다. 즉, 쿼리를 실행하기 전에 DB가 스스로 세우는 가장 빠른 처리 방법에 대한 절략이라고 생각할 수 있습니다. 이런 쿼리 실행 계획은 유동적입니다. 같은 쿼리문일지라도 상황에 따라 다른 쿼리 실행 계획을 가지며 다르게 실행될 수 있다는 뜻입니다.

mysql에서 쿼리 실행 계획을 확인하기 위해서는 EXPLAIN 명령어를 사용합니다. 예를 들어 SELECT * FROM users; 라는 쿼리가 있다고 가정하면 EXPLAIN SELECT * FROM users;처럼 쿼리문 앞에 EXPLAIN 명령어를 붙이기만 하면 됩니다.

쿼리 실행 계획 구조

mysql에서 EXPLAIN 명령어 사용 후 반환되는 값을 구성하는 컬럼 종류는 다음과 같습니다.

✅ id

실행 계획 쿼리별 식별자값입니다.

예시)
하나의 select 문에 대한 실행 계획을 확인한다면 id값이 1인 실행 계획 하나만 반환됩니다. 하지만 서브 쿼리로 select 문이 하나 더 있다면 id값이 1,2로 총 2개의 실행 계획이 반환됩니다.

서브 쿼리 예시

서브 쿼리 실행 계과 예시

✅ select_type

실행 계획 쿼리 타입입니다. insert문이라면 insert, delete라면 delete라고 표시됩니다. select문에 대해서는 여러 타입이 존재합니다. 아래 몇 가지 select 타입을 정리해보았습니다.

SIMPLE

서브 쿼리도 없고 UNION도 없는 가장 단순한 형태의 쿼리문

-- 예시
EXPLAIN
SELECT
  *
FROM
  users u
;

PRIMARY

아우터 쿼리문 ( 예를 들면 서브쿼리가 있을 때 서브 쿼리는 SUBQUERY, 메인 쿼리 혹은 아우터 쿼리는 PRIMARY )

-- 예시
EXPLAIN
SELECT
  name 
FROM
  users 
WHERE
  id
IN (
  SELECT user_id FROM orders WHERE amount > 100
);

SUBQUERY

서브 쿼리문 ( 예를 들면 서브쿼리가 있을 때 서브 쿼리는 SUBQUERY, 메인 쿼리 혹은 아우터 쿼리는 PRIMARY )

-- 예시
EXPLAIN
SELECT
  name 
FROM
  users 
WHERE
  id
IN (
  SELECT user_id FROM orders WHERE amount > 100
);

✅ table

참조할 테이블명 ( 만약 별칭을 지정했다면 별칭이 표시됩니다 )

✅ partitions

파티셔닝이 되어있을 경우 사용될 파티션 표시 ( 만약 파티션되지 않은 테이블일 경우 null로 표시됩니다 )

✅ type

( 더 자세한 설명은 아래 '쿼리 실행 계획 예제' 참조 )

ALL
풀 스캔하는 경우
index
전체 인덱스 스캔하는 경우
range
인덱스를 이용한 범위 검색의 경우
ref
조인 시 사용되며, 해당 조인에 여러 행이 매칭되는 경우
eq_ref
조인 시 사용되며, 해당 조인에 단 하나의 행만 매칭되는 경우
const
테이블에 단 하나의 행만 매칭되는 경우 (ex. PRIMARY KEY나 UNIQUE 인덱스를 통한 조회)
system
테이블에 단 하나의 행만 존재하는 테이블

✅ possible_keys

옵티마이저가 해당 쿼리에 사용할 수 있다고 판단한 인덱스 목록

✅ key

선택된 인덱스

✅ key_len

선택된 인덱스 길이(단위: 바이트)

✅ ref

조인에서 인덱스를 통해 참조한 컬럼 혹은 상수

✅ rows

예측된 액세스 행 수

✅ filtered

조건을 만족하는 행의 비율

✅ Extra

추가 정보

쿼리 실행 계획 예제

쿼리를 최적화하기 위해 쿼리 실행 계획에서 집중할 부분은 type 컬럼입니다. 여러 SQL 쿼리 예시를 통해 type 컬럼에 대해 더 자세히 알아봅시다. 먼저 다음과 같은 테이블 구조가 있다고 가정합시다.

예시 다이어그램(users, posts 테이블 구조)

테이블은 총 2가지로 users 테이블과 posts 테이블이 존재합니다. 그리고 각 테이블은 id라는 컬럼명으로 PK값을 사용합니다. 이때 posts 테이블은 user_id 컬럼을 가지고 있고, 이는 users 테이블 id에 대한 FK입니다. 이 상황에서 여러 SQL을 사용하고 각 SQL 쿼리문에 대한 EXPLAIN 결과를 확인해봅시다.

전체 행 조회

전체 users 테이블 데이터를 조회합니다.

EXPLAIN
SELECT
  *
FROM
  users u
;

Name         |Value |
-------------+------+
id           |1     |
select_type  |SIMPLE|
table        |u     |
partitions   |      |
type         |ALL   |
possible_keys|      |
key          |      |
key_len      |      |
ref          |      |
rows         |4     |
filtered     |100.0 |
Extra        |      |

type이 ALL로 표시됩니다. 즉, 모든 데이터를 풀 스캔으로 조회 중임을 알 수 있습니다. 또한 rows, filtered 결과를 통해 현재 users 테이블에는 총 4개의 데이터가 존재하여 이 행의 모두 조회했음을 확인할 수 있습니다.

PK로 조회

users 테이블의 PK 컬럼 id를 활용하여 id가 1인 단 하나의 데이터만 조회합니다.

EXPLAIN
SELECT
  *
FROM
  users u
WHERE
  u.id=1
;

Name         |Value  |
-------------+-------+
id           |1      |
select_type  |SIMPLE |
table        |u      |
partitions   |       |
type         |const  |
possible_keys|PRIMARY|
key          |PRIMARY|
key_len      |4      |
ref          |const  |
rows         |1      |
filtered     |100.0  |
Extra        |       |

type이 const로 표시됩니다. 즉, 특정 PK값을 만족하는 데이터는 테이블에서 단 한개만 존재하기 때문에 const로 표시됨을 알 수 있습니다. possible_keys에는 PRIMARY값만을 해당 쿼리에 사용할 수 있는 인덱스 목록으로 선정했고, key에서도 PRIMARY값을 인덱스로 사용하기로 했음을 알 수 있습니다.

서브 쿼리 조회

users 테이블의 age 컬럼을 통해 조회합니다. 이때 서브 쿼리문을 추가해봅니다.

EXPLAIN
SELECT
  *
FROM
  users u
WHERE
  u.age = (
	SELECT age FROM users WHERE id=1
  )
;

Name         |Value      |
-------------+-----------+
id           |1          |
select_type  |PRIMARY    |
table        |u          |
partitions   |           |
type         |ALL        |
possible_keys|           |
key          |           |
key_len      |           |
ref          |           |
rows         |4          |
filtered     |25.0       |
Extra        |Using where|




Name         |Value   |
-------------+--------+
id           |2       |
select_type  |SUBQUERY|
table        |users   |
partitions   |        |
type         |const   |
possible_keys|PRIMARY |
key          |PRIMARY |
key_len      |4       |
ref          |const   |
rows         |1       |
filtered     |100.0   |
Extra        |        |

아우터 쿼리와 서브 쿼리에 대한 실행 계획 결과값이 2개 출력됩니다.

[NodeJS] 싱글 스레드도 경쟁 상태(Race Condition)는 발생합니다

SparkIT — Sun, 4 May 2025 05:05:14 +0900

Node.js는 싱글 스레드로 동작하는 서버 환경으로, 일반적으로 멀티스레드 환경에서 발생하는 Race Condition 문제와는 거리가 멀다고 여겨집니다. 그러나 비동기 코드가 사용되면 Node.js에서도 Race Condition 문제가 발생할 수 있습니다. 이번 글에서는 Race Condition의 개념을 짚어보고, Node.js에서 이를 어떻게 실험할 수 있는지에 대한 예제를 소개하려 합니다.

경쟁 상태(Race Condition)란?

Race Condition은 여러 프로세스나 스레드가 동시에 동일한 자원에 접근하면서 발생하는 문제입니다. 이는 공유 자원을 동시에 변경하려 할 때, 각 작업의 실행 순서에 따라 예상치 못한 결과가 발생하는 상황을 말합니다.

예를 들어 CounterService라는 클래스가 존재하고 해당 클래스에 counter라는 멤버 변수가 있다고 가정합니다. 그리고 이 멤버 변수 counter 값을 +1 하는 메서드가 존재합니다. 이때 해당 메서드에 여러 요청이 동시에 도착하면 어떻게 될까요? 순서대로 counter 값이 +1 된다면 race condition 문제가 발생하지 않는 경우고, 단순히 counter값이 +1 한 번 실행되면 race condition 문제가 발생된 경우입니다.

Node.js는 싱글스레드니까 Race Condition 자체가 성립할 수 없지 않나요?

보통 race condition은 멀티 스레드 환경으로 실행되는 Java Spring 프레임워크에서 많이 거론됩니다. 반면 Node.js는 애초에 싱글 스레드 환경이기 때문에 race condition이 발생하지 않는다는 오해를 사기도 합니다. 하지만 이는 정확하지 않은 정보입니다. 더 정확하게 표현하자면 여러 스레드가 하나의 자원에 접근하면서 발생하는 race condition은 없습니다. 하지만 서로 다른 논리적 트랜잭션 간 race condition을 발생 가능합니다.

Node.js에서 개발된 코드가 모두 동기적인 코드로만 구성된다면 race condition이 발생하지 않을 수 있습니다. Node.js는 이벤트 루프라는 싱글 스레드로 동작하기 때문에 동기적인 코드는 모두 순서대로 작동하기 때문입니다. 하지만 비동기 코드가 포함되면 이야기가 달라집니다. 비동기 코드는 먼저 실행된 코드가 먼저 반환됨을 보장하지 않습니다. 여기서 순서가 꼬이게 됩니다. (Node.js의 이벤트 루프에 대한 내용은 아래 글에 더 자세하기 작성했습니다)

[NodeJS]이벤트 루프 동작 이해하기

용어 정리콜 스택(Call stack)수행해야 하는 함수들 대기 장소(To Do List 같은 역할). 실제로 노드가 함수들을 실행하기 위해 확인하는 곳이라고 생각하면 됩니다. 노드 엔진은 콜 스택에 함수들이 대

sparkit.tistory.com

그럼 비동기 코드를 넣어서 Node.js에서 강제로 race condition을 발생시켜 보겠습니다. 아래 예제를 통해 쉽게 이해해봅시다.

Node.js 환경 race condition 예제

Typescript와 Nest JS 프레임워크를 활용한 예제입니다. 서비스 코드 일부로 testRaceCondition 메서드를 실행하면 동시에 increment 메서드를 5번 실행시킵니다.

import { Injectable } from '@nestjs/common';

@Injectable()
export class CounterService {
	private counter = 0;

	async testRaceCondition() { // ❗️ 이 메서들 통해 5번의 increment 메서드 동시에 요청
		return Promise.all([
			this.increment(),
			this.increment(),
			this.increment(),
			this.increment(),
			this.increment(),
		]);
	}

	async increment() {
		const currentValue = this.counter;
		this.counter = currentValue + 1;     // ✅ 위 아래 코드 순서 변경하면 결과 달라짐
		await this.simulateAsyncOperation(); // ✅ 위 아래 코드 순서 변경하면 결과 달라짐
	}

	private async simulateAsyncOperation() {
		return new Promise((resolve) => setTimeout(resolve, 50));
	}

	getCounter() {
		return this.counter;
	}
}

위 예제 코드에서 testRaceCondition 실행 후 getCounter 실행하여 this.counter 값을 확인하면 어떤 값이 나올까요?

바로 5입니다. 5개의 요청(increment 메서드에 대한)이 동시에 실행되어도 콜 스택에서 동기적인 코드는 모두 순서를 보장받으며 실행되기 때문입니다. 즉, increment 메서드의 const currentValue = this.counter; 와 this.counter = currentValue = 1;는 5개의 요청 순서대로 실행되어 결과적으로 this.counter는 5라는 값을 가지게 됩니다.

만약 increment 메서드를 다음과 같이 수정하면 어떻게 될까요?

	async increment() {
    		const currentValue = this.counter;
        	await this.simulateAsyncOperation(); // ✅ 위 아래 코드 순서 변경하면 결과 달라짐
        	this.counter = currentValue + 1;     // ✅ 위 아래 코드 순서 변경하면 결과 달라짐
	}

이와 같이 increment 메서드를 수정하게 되면 this.counter값은 5가 아니라 1이 반환됩니다. 왜 그럴까요?

그 이유는 콜 스택에서 동기적인 코드 const currentValue = this.counter;만 먼저 순서대로 실행되기 때문입니다. 이를 통해 5개의 요청이 아무런 변환 없는 this.counter값을 그저 요청 간 순서를 지키며 읽기만 합니다. 그럼 모든 요청의 currentValue값은 0이 됩니다. 여기서 밑에 await 코드가 반환되길 기다리죠. 그리고 해당 비동기 코드의 콜백 함수가 반환되면 그제야 this.counter = currentValue + 1;이 실행되어서 this.counter 값이 0에서 1이 되는 것입니다.

마무리

위처럼 Node.js 환경에서도 상황에 따라 race condition 문제가 발생할 수 있음을 확인했습니다. 이를 통해 코드를 설계하는 과정에서 이런 race condition 문제를 미리 예측하여 문제가 발생하지 않는 구조를 사용하도록 해야 합니다.

함수형 프로그래밍에 대한 이해와 오해 (feat.절차지향, 객체지향)

SparkIT — Sat, 3 May 2025 18:41:53 +0900

'함수형 프로그래밍'은 함수형이라는 이름으로 인해 많은 오해를 불러일으킵니다. 가장 흔한 오해는 함수형 프로그래밍의 반대는 '객체 지향 프로그래밍'이라는 생각입니다. 이외에도 함수형 프로그래밍에 대한 오해는 꽤 많습니다. 그래서 오늘 이 글에서 함수형 프로그래밍이 무엇인지에 대해 설명하고, 관련한 오해를 풀어보려합니다. 먼저 함수형 프로그래밍과 관련한 여러 프로그래밍 관점들을 소개하겠습니다.

절차 지향 vs 함수형 vs 객체 지향

✅ 절차 지향 프로그래밍 (Procedural Programming)

절차 지향 프로그래밍 일러스트레이션

핵심 개념: 프로그램을 순차적인 절차(명령의 흐름)로 구성하여 문제를 해결함.
기반 구조: 함수(또는 프로시저)를 사용하여 코드를 구조화하되, 주로 전역 상태와 공유된 데이터를 중심으로 동작.
대표 언어: C, Pascal, Fortran 등

특징:

명령어들이 순서대로 실행됨 (절차적 흐름 중요)
상태 변화(변수 변경)를 자유롭게 함
가변 데이터를 많이 사용
함수는 보조 도구이며, 상태를 변경하거나 입출력을 수행함

예시:

let total = 0;
function addToTotal(num) {
  total += num;
}
addToTotal(5);
console.log(total); // 5 (상태 변화)

위 예시에서 단순히 함수 addToTotal을 만들고 이를 사용했으니 함수형 프로그래밍이 아니냐?라고 생각할 수 있습니다. 하지만 이는 함수형 프로그래밍이 아닙니다. 그 이유는 다음과 같습니다.

함수형 프로그래밍이 아닌 이유
1. 외부 상태 변경
  전역 변수인 total을 함수 내부에서 변경하고 있습니다. 이렇게 외부 상태를 변경하는 것은 함수형 프로그래밍 철칙에 위배됩니다.
2. 새로운 값 반환 안함
  함수형 프로그래밍에서는 새로운 값을 만들고 이를 반환해야합니다. 하지만 위 addToTotal은 단순히 외부 상태인 total 변수만 수정하고 새로운 값을 만들거나 반환하지 않고 있습니다.

✅ 함수형 프로그래밍 (Functional Programming)

순수함수 일러스트레이션

핵심 개념: 프로그램을 수학적 함수처럼 구성하며, 상태와 부작용을 최소화함.
기반 구조: 순수 함수(Pure Function)를 중심으로 프로그램을 구성
대표 언어: Haskell, Clojure, Elm, (함수형 기능이 있는 JavaScript, Python, Scala 등)

특징:

순수 함수(Pure function)
순수 함수 사용하여 같은 입력에 대해 항상 같은 출력을 보장함. 외부 상태를 변경하지 않음
불변성(immutability)
외부 상태를 변경하지 않고, 새로운 값을 생성함
고차 함수 사용
함수를 인자로 받거나 반환하는 함수
상태와 부작용을 최소화하여 디버깅과 테스트가 용이함

예시:

function add(a, b) {
  return a + b;
}
const result = add(3, 5); // 항상 8
console.log(result); // 8 (불변, 순수 함수)

위에서 설명한 절차 지향 프로그래밍과 어디가 달라졌을까요?

함수형 프로그래밍인 이유
1. 외부 상태 변경
  외부 상태를 변경하지 않습니다. 만약 add 함수 내부에서 외부에서 전달된 a, b값을 수정했다면 함수형 프로그래밍 철칙을 위배합니다.
2. 새로운 값 반환
  a와 b를 더한 새로운 값을 반환하고 있습니다.

✅ 객체 지향 프로그래밍 (Object-Oriented Programming)

객체 지향 프로그래밍 일러스트레이션

핵심 개념: 현실 세계의 개념을 객체(object)로 모델링하여, 객체 간의 상호작용으로 프로그램을 구성함
기반 구조: 클래스(class)와 객체(instance)를 중심으로 프로그램을 구성
대표 언어: Java, C++, C#, Python, Ruby, Kotlin, Swift 등

특징:

캡슐화(Encapsulation)
데이터(속성)와 동작(메서드)을 하나의 객체 안에 묶어 외부에 불필요한 내부 구현을 숨김
상속(Inheritance)
상위 클래스의 속성과 동작을 하위 클래스가 물려받아 재사용성과 확장성을 높임
다형성(Polymorphism)
동일한 인터페이스나 메서드가 여러 클래스에서 다르게 동작할 수 있게 함 (오버라이딩, 오버로딩)
추상화(Abstraction)
복잡한 내용을 숨기고, 필수적인 요소만 외부에 제공하여 복잡도를 줄임

예시:

class Adder {
  constructor(a, b) {
    this.a = a;
    this.b = b;
  }

  add() {
    return this.a + this.b;
  }
}

// 객체 생성
const myAdder = new Adder(3, 5);

// 메서드 호출
const result = myAdder.add(); // 8
console.log(result);

위에서 설명한 함수형 프로그래밍과 다른 점이 확실히 보일 것입니다. 객체 지향 프로그래밍에서는 하나의 역할과 책임을 담당하는 class를 만들기 때문에 위와 같이 Adder라는 클래스를 만들고 해당 클래스 내부에 add라는 메서드를 만드는 방식을 이용합니다.

함수형 프로그래밍에 대한 오해

1. 함수형(or 절차지향) 프로그래밍의 반대는 객체지향 프로그래밍이다?

함수형 프로그래밍과 객체 지향 프로그래밍은 정반대의 개념이라고 생각하시는 분들이 많습니다. 혹은 절차 지향 프로그래밍과 객체 지향 프로그래밍이 정반대 개념이라고 생각하시는 분들도 있습니다. 각 프로그래밍 철학이 서로 다른 관점을 가지고 있는 것은 맞지만, 정확히 정반대의 개념을 가지고 있어 혼용될 수 없다는 이야기는 틀렸다고 볼 수 있습니다.

예를 들어 객체 지향 프로그래밍은 객체(클래스)라는 존재를 이용해 객체 간 관계를 중심으로 코드를 작성하겠다는 뜻입니다. 이때 전체적인 도메인 모델링만 객체 지향 프로그래밍 관점을 활용하고, 객체에 대한 데이터 처리 로직 과정에는 함수형 프로그래밍을 적극 활용하면 객체 지향 프로그래밍과 함수형 프로그래밍을 동시에 사용하는 것이죠.

2. map, filter 같은 것만 사용하면 함수형 프로그래밍인가요?

map이나 filter와 같은 함수를 사용해도 내부에서 객체의 프로퍼티를 직접 수정하는 경우는 이를 함수형 프로그래밍이라고 할 수 없습니다. 간단한 예시입니다.

// ❌ 불변성 위반 예시
const users = [{ name: "Alice", active: true }];
const deactivated = users.map(u => {
  u.active = false; // 원본 변경!
  return u;
});

위 예시에서는 users라는 배열을 순회하면서 active 프로퍼티 값을 바꾸도록 설정되어 있습니다. 이는 함수형 프로그래밍의 철칙인 불변성(immutability)를 위배하므로 함수형 프로그래밍이라고 볼 수 없습니다.

3. Java, Python, Javascript로 함수형 프로그래밍이 가능한가요?

위 언어로도 함수형 프로그래밍이 가능은 합니다. 하지만 여기서 조심해야할 것은 위 언어는 함수형 언어는 아니라는 점입니다. 즉, 함수형 프로그래밍을 위한 기능을 지원하지만 제한적이라는 것입니다. 더 확실한 함수형 프로그래밍을 위해서는 Haskell, Elm 같은 함수형 프로그래밍에 최적화된 언어를 사용하는 것이 좋습니다.

[JS] 자바스크립트 호이스팅 쉽게 이해하기

SparkIT — Fri, 2 May 2025 00:23:58 +0900

자바스크립트를 공부하는 과정에서 자주 등장하는 개념 중 하나가 바로 호이스팅(Hoisting)입니다. 호이스팅은 자바스크립트의 변수 선언과 함수 선언이 코드 실행 전에 "끌어 올려진다"는 특성을 의미합니다. 이 글에서 호이스팅이 무엇인지, 어떻게 동작하는지, 그리고 이를 어떻게 다뤄야 하는지에 대해 설명하겠습니다.

호이스팅이란?

Hoisting 이미지

호이스팅(Hoisting)은 자바스크립트에서 변수 선언과 함수 선언이 실행되기 전에 스코프(범위)의 최상단으로 끌어올려지는 현상을 말합니다. 이때 사용된 단언 hoist는 hoist crane에서 따온 것으로 hoist crane은 위 이미지에서 볼 수 있는 공사현장의 크레인을 의미합니다. 즉, 자바스크립트 엔진은 코드 실행 전에 선언된 변수와 함수들을 미리 최상단으로 끌어올려 기억해두고, 이후에 차례대로 코드를 실행하는 것입니다.

이 특성으로 인해 변수나 함수를 선언하기 전임에도 불구하고 이를 사용할 수 있는 상황이 발생하기도 합니다. 하지만 여기서 중요한 점은 변수와 함수 선언은 끌어올려지지만, 변수 초기화나 함수 표현식은 끌어올려지지 않는다는 것입니다.

⚙️ 호이스팅 원리

자바스크립트는 코드를 실행할 때, Execution Context라는 것을 생성하고, 아래 2단계를 거칩니다:

1. Creation Phase (생성 단계)

→ 변수, 함수, 스코프 등을 메모리에 미리 할당
→ 이 때 호이스팅이 발생

2. Execution Phase (실행 단계)

→ 실제 코드가 한 줄씩 실행됨
→ 할당, 연산, 함수 호출 등이 이 단계에서 일어남

즉, 2번 실행 단계 전에 1번 생성 단계에서 인터프리터 형식으로 코드를 한줄한줄 실행하기 전에 변수, 함수, 스코프 등을 메모리에 미리 할당하기 때문에 호이스팅이라는 현상이 발생하게 됩니다.

상세 설명

호이스팅은 여러 상황에 따라 다르게 작동합니다. 각 상황에 따른 상세 설명은 다음과 같습니다.

1. 변수

✅ var 변수

선언 : 호이스팅 ⭕️
초기화 : 호이스팅 ❌

console.log(x); // undefined
var x = 5;
console.log(x); // 5

위 코드에서 x는 변수 선언이 호이스팅 되어 코드 상단으로 끌어올려집니다. 그러나 x = 5는 호이스팅되지 않아서, x의 값은 undefined로 출력됩니다.

✅ let, const 변수

선언 : 호이스팅 ⭕️
초기화 : 호이스팅 ❌

console.log(x); // ReferenceError: Cannot access 'x' before initialization
let x = 5;

let과 const는 var와 달리 선언된 위치로 호이스팅되지만, 초기화 전에 접근하려고 하면 ReferenceError가 발생합니다. 이를 일시적 사각지대(Temporal Dead Zone, TDZ)라고 합니다.

2. 함수

✅ 선언식 함수

함수 선언식은 전체 코드 블록이 실행되기 전에 선언부가 끌어올려지고 초기화됩니다.

hello(); // "Hello, World!"
function hello() {
  console.log("Hello, World!");
}

✅ 표현식 함수

함수 표현식은 변수에 함수가 할당되는 방식이기 때문에 함수 표현식이 호이스팅되지 않습니다. 정확히 말하면 함수가 할당된 변수는 호이스팅되지만 함수 자체는 할당되지 않습니다.

hello(); // TypeError: hello is not a function
var hello = function() {
  console.log("Hello, World!");
};

ESLint, Prettier 기초부터 실전 적용까지 - Node 개발자 필수 상식

SparkIT — Thu, 1 May 2025 16:34:57 +0900

개요

prettier, eslint 로고

ESLint는 정적 분석을 통해 코드 품질을 체크하는 도구로, 주로 코드의 문법적 오류나 불필요한 코드를 찾아내는 데 집중합니다. 반면, Prettier는 코드를 자동으로 포맷해서 일관된 스타일을 유지하는 데 도움을 줍니다. 그래서 Node 개발자들이 협업할 때는 이 둘을 같이 사용해 코드 품질과 스타일을 일관성있게 유지하는 것이 일반적입니다.

	ESLint	Prettier
설명	코드 문법 오류, 버그 가능성 탐지 목적	코드 스타일 일관성 유지 목적
목적	코드 안정성	코드 가독성

간단한 예시를 통해 ESLint와 Prettier를 사용하는 이유를 알아보겠습니다.

ESLint
- 사용되지 않는 변수 찾기
  : 쓸데없는 변수 선언 피할 수 있음
- 잘못된 함수 호출
  : 존재하지 않는 함수. 혹은 함수 호출 시 함수명을 잘못 사용한 부분 캐치 가능
- ...
Prettier
- 들여쓰기 일관성 유지
  : 누구는 들여쓰기 2칸 쓰고, 누구는 들여쓰기 4칸 사용하면 코드 가독성이 너무 안 좋아짐
- 문자열 쌍따움표 vs 홑따움표
  : 누구는 쌍따움표 사용하고, 누구는 홑따움표 사용해 문자열 표시하면 코드 가독성이 너무 안 좋아짐
- ...

각 도구에 대한 더 상세한 내용은 아래와 같습니다.

ESLint

설치

자바스크립트 사용 시

npm install --save-dev eslint

타입스크립트 사용 시

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

설정파일

사용 가능한 eslint v9 이전 eslint 설정파일명
- .eslintrc.js
- .eslintrc.json
- .eslintrc.yaml
사용 가능한 eslint v9 이후 eslint 설정파일명
- eslint.config.js
- eslint.config.mjs
- eslint.config.cjs

기본적으로 eslint 설정 파일은 2가지 형식으로 나뉩니다. eslint 9 버전 이전에는 .eslintrc.js/json/yaml 파일로 설정을 관리했지만, eslint 9 버전 이후에는 eslint.config.js/mjs/cjs 파일로 설정을 관리합니다. 하지만 두 설정 파일은 사실상 같은 파일이라고 생각해도 됩니다. 약간의 구조적 차이만 존재하기 때문입니다. 아래는 이런 설정 파일에 공통적으로 들어가야할 핵심 정보 5가지 정도를 소개합니다.

1. env

env는 코드가 실행될 환경을 명시하는 부분입니다. 예를 들어 browser 환경에서 사용된다면 window, document 등의 전역 객체를 사용할 수 있습니다. 하지만 env에 browser 옵션이 없는데 window, document 등의 전역 객체를 사용한다면 에러로 파악될 것입니다.

env: {
  browser: true,
  node: true,
  es2021: true,
  jest: true
}

2. extends

extends는 상속할 외부 규칙을 명시하는 부분입니다. 보통 다음과 같이 인기 있는 airbnb, standard 등을 활용합니다. 여러 규칙을 명시할 경우 앞에서부터 뒤로 이동하며 덮어쓰여지기 때문에 후순위 설정이 우선 적용되는 방식이 적용됩니다.

extends: [
  'eslint:recommended',
  'plugin:react/recommended',
  'airbnb',
  'prettier'  // prettier와 충돌 방지용
]

3. parserOptions

parserOptions는 ES 버전, 모듈 시스템 등의 최신 문법에 대해 명시하는 부분입니다.

parserOptions: {
  ecmaVersion: 2021,
  sourceType: 'module',
  ecmaFeatures: {
    jsx: true
  }
}

4. plugins

plugins는 플러그인을 명시하는 부분입니다. 보통 다음과 같이 react, typescript 등을 활용합니다.

plugins: ['react', '@typescript-eslint']

5. rules

rules는 코드 규칙을 명시하는 부분입니다. 만약 extends에서 명시한 외부 규칙과 다른 부분이 존재하면 rules가 우선 적용됩니다.

rules: {
  'semi': ['error', 'always'],          // 세미콜론 필수
  'quotes': ['error', 'single'],        // 작은 따옴표 사용
  'no-console': 'warn',                 // console.log 경고
  'react/react-in-jsx-scope': 'off'     // React 17+ JSX에서 필요 없음
}

자바스크립트 vs 타입스크립트 - 예시

eslint에서 자바스크립트 파일을 이용할 때와 타입스크립트 파일을 이용할 때 설정을 다르게 해야합니다. 자세한 내용은 다음과 같습니다.

	Javascript	Typescript
Parser	기본 제공 (espree) 사용	@typescript-eslint/parser 필요
플러그인	필요 없음 또는 JS 전용	@typescript-eslint/eslint-plugin 필수
tsconfig.json 사용	사용 안 함	사용함 (parserOptions.project) 설정 필요
확장 규칙	eslint:recommended	plugin:@typescript-eslint/recommended 등 추가 필요

자바스크립트 .eslintrc.js 예시

module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  extends: ['eslint:recommended'],
  rules: {
    'no-console': 'warn',
  },
};

타입스크립트 .eslintrc.js 예시

module.exports = {
  root: true,
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: './tsconfig.json',
  },
  plugins: ['@typescript-eslint'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended', // 기본 TS 규칙
    'plugin:@typescript-eslint/recommended-requiring-type-checking', // 타입 체크 기반 규칙
    'prettier', // Prettier와 충돌 방지
  ],
  rules: {
    '@typescript-eslint/no-floating-promises': 'error',
    '@typescript-eslint/no-unused-vars': ['warn', { argsIgnorePattern: '^_' }],
  },
};

명령어

npx eslint src --ext .ts,.js --fix

위 명령어는 가장 흔하게 사용될만한 명령어로 내용은 다음과 같습니다.

npx eslint
eslint 실행
src
eslint 적용할 디렉토리 경로
--ext .ts,.js
디폴트는 .js 파일에만 eslint가 적용됨. 하지만 직접 명시하여 .ts 파일만 eslint 적용하거나 .ts, .js 둘 다 eslint 적용할 수 있음
--fix
eslint 규칙에 따라 자동 수정

즉, 위 명령어를 사용하면 src 디렉토리 하위에 있는 .ts, .js 확장자 파일이 모두 eslint 설정에 맞게 수정됩니다.

자동 적용

저는 VSCode를 이용해 작업을 주로 합니다. VSCode에서 ESLint를 손쉽게 사용하는 방법은 extension을 설치하는 것입니다. ESLint Extension은 VSCode에서 작업 시 파일을 저장하면 자동으로 ESLint 검가 작동하게 하거나, 에러에 대한 하이라이팅 표시를 해주는 등 ESLint 활용한 개발을 도와줍니다. 해당 익스텐션을 활용해 파일 저장할 때마다 자동으로 ESLint 검사가 실행되게 하는 방법은 다음과 같습니다.

1. ESLint Extension 설치

vscode eslint extension 설치

2. vscode 설정 추가

해당 Extension을 활용하기 위해서는 설정 파일을 수정해야하는데요. 이때 파일 저장 시 자동적으로 eslint 검사가 적용되도록하는 방법은 두 가지 존재합니다.

방법1) VSCode 자체 Preferences: Open User Settings (JSON) 설정
1. 'cmd + shift + P' 입력
2. 'Preferences: Open User Settings (JSON)' 검색
3. 아래 코드 추가

  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit",
    "source.fixAll.eslint": "explicit"
  },
  "eslint.validate": ["javascript", "typescript"],
  "editor.formatOnSave": false

방법2) 프로젝트 하위에 .vscode/settings.json 설정
1. 프로젝트 루트 경로에 .vscode 디렉토리 추가
2. .vscode/settings.json 추가
3. 아래 코드 settings.json에 추가

  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit",
    "source.fixAll.eslint": "explicit"
  },
  "eslint.validate": ["javascript", "typescript"],
  "editor.formatOnSave": false

Prettier

설치

npm install --save-dev prettier

설정파일

사용 가능한 prettier 설정파일명
- .prettierrc
- .prettierrc.json
- .prettierrc.yaml
- .prettierrc.js
- .prettierrc.yaml
- .prettierrc.config.js

Prettier 설정파일에서 설정할 수 있는 옵션들은 다음과 같습니다.

printWidth
- 설명 : 한 줄 최대 문자 수. 이를 넘기면 자동으로 개행
- 디폴트 : 80
tabWidth
- 설명 : 한 탭 너비(공백 수)
- 디폴트 : 2
useTabs
- 설명 : 탭을 사용 여부(or 공백을 사용)
- 디폴트 : false
semi
- 설명 : 세미콜론 자동 추가 여부
- 디폴트 : true
singleQuote
- 설명 : 홑따움표 사용 여부(or 쌍따움표 사용)
- 디폴트 : false
quoteProps
- 설명 : 객체 속성 이름에 대한 따움표 적용 방식
- 디폴트 : 'as-needed'
- 종류
"as-needed": 필요한 경우에만 따옴표 사용
"consistent": 모든 속성에 따옴표를 일관되게 사용
"always": 모든 속성에 따옴표 사용
jsxSingleQuote
- 설명 : JSX 속성에 홑따움표 사용 여부(or 쌍따움표 사용)
- 디폴트 : false
trailingComma
- 설명 : 콤마를 통해 연속되는 값 마지막에 콤마 추가 여부
- 디폴트 : "none"
- 종류
"none": 추가하지 않음
"es5": ES5 구문에서만 끝에 콤마 추가
"all": 모든 곳 끝에 콤마 추가
bracketSpacing
- 설명 : 중괄호와 속성 사이 공백 추가 여부
- 디폴트 : true
endOfLine
- 설명 : 파일 줄 바꿈 문자 처리 설정
- 디폴트 : "auto"
- 종류
"auto": 운영체제애 맞게 변환
"lf": \n 사용 ( 리눅스, 맥OS )
"crlf": \r\n 사용 ( 윈도우 )
"cr": \r 사용 (예전 맥OS)

// .prettierrc 예시

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all"
}

명령어

npx prettier "src/**/*" --write

위 명령어는 가장 흔하게 사용될만한 명령어로 내용은 다음과 같습니다.

npx prettier
prettier 실행
"src/**/*"
prettier 적용할 디렉토리 경로. src 하위 모든 파일을 타겟으로 지정한다는 의미
--write
prettier 규칙에 따라 자동 수정

즉, 위 명령어를 사용하면 src 디렉토리 하위에 있는 파일이 모두 prettier 설정에 맞게 포맷팅됩니다.

자동 적용

1. Prettier Extension 설치

vscode prettier extension 설치

2. vscode 설정 추가

위 ESLint와 동일하게 해당 설정 파일은 프로젝트별 .vscode/settings.json 에 넣을 수도 있고 VSCode 자체 settings.json에 넣을 수도 있습니다. 각자 상황에 맞게 아래 내용을 추가해줍니다.

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

ESLint, Prettier 충돌 해결하기

eslint와 prettier에는 중첩되는 설정이 몇 가지 존재합니다. 이로 인해서 두 설정 간 충돌이 발생하기도 합니다. 충돌이 발생할 수 있는 부분은 다음과 같습니다.

	ESLint	Prettier	설명
세미콜론 사용 여부	✅ (semi)	✅	둘 다 설정 가능하지만 충돌 위험
문자열 따옴표 (single/double)	✅ (quotes)	✅	둘 다 강제할 수 있음
들여쓰기	✅ (indent)	✅	기본 설정이 다르면 충돌 가능
객체 속성 끝에 콤마 사용 (trailingComma)	✅	✅	스타일 충돌 가능
max line length	✅ (max-len)	✅ (printWidth)	출력 위치가 다를 수 있음

보통 이런 충돌을 막기 위한 방법으로는 Prettier가 담당하는 영역에 대해 ESLint 규칙을 끄는 것입니다. 이를 위해 보통 eslint-config-prettier를 많이 사용합니다. 충돌 해결 과정에 대해 간략하게 소개합니다.

1. eslint-config-prettier 설치

npm install --save-dev eslint-config-prettier

2. eslint 설정 파일 내용 추가

    plugins: ['@typescript-eslint/eslint-plugin'], // ✅ 이를 통해 충돌 해결
    extends: [
        'plugin:@typescript-eslint/recommended',
        'plugin:prettier/recommended', // ✅ 이를 통해 충돌 해결
    ],

[TypeORM] connection pool size 조정해서 데이터베이스 작업 효율 높이기

SparkIT — Sun, 20 Apr 2025 17:31:03 +0900

커넥션 테스트 준비

(현재 글은 typeorm 0.3.21 버전, mysql 8.0 버전을 토대로 작성하였습니다.)

저는 NestJS 프레임워크에서 typeorm을 활용하여 데이터베이스 작업을 진행하고 있습니다. 그리고 typeorm과 관련된 설정에서 connection pool과 관련된 설정은 어떠한 것도 수정하지 않았습니다. 이때 typeorm에서 데이터베이스와 연결되는 커넥션 수가 궁금하여 다음과 같은 테스트를 진행하였습니다.

커넥션 수 확인
nest js 어플리케이션 실행 후 커넥션 수 확인
nest js 서비스 코드 중 데이터베이스에 한 번 CRUD 작업을 진행하는 메서드 실행 후 커넥션 확인
nest js 서비스 코드 중 데이터베이스에 여러 번 CRUD 작업을 진행하는 메서드 실행 후 커넥션 확인

이때 사용한 서비스 코드는 다음과 같습니다.

// 서비스 코드 중 일부

async updateTest() {
	// 데이터베이스에 데이터 수정하는 로직
}
    
async concurrencyProblem() {
    await Promise.all([
    	this.updateTest(),
        this.updateTest(),
        	... // 20번 반복
    ]);
}

해당 코드에서 concurrencyProblem 메서드를 실행해서 데이터베이스 작업인 updateTest 메서드를 여러번 실행시켰습니다.

커넥션 테스트 결과

테스트 결과는 다음과 같습니다.

1. 커넥션 수 확인

커넥션 수는 아래 쿼리를 통해 확인했습니다.

SHOW PROCESSLIST;

해당 쿼리로 실행된 프로세스 하나만 존재하는 것을 확인할 수 있습니다.

2. nest js 어플리케이션 실행 후 커넥션 수 확인

nest js 어플리케이션 실행 후에는 typeorm으로 인해 커넥션이 하나 생성되면서 프로세스도 하나 추가된 모습을 확인할 수 있습니다.

3. nest js 서비스 코드 중 데이터베이스에 한 번 CRUD 작업을 진행하는 메서드 실행 후 커넥션 확인

nest js에서 특정 API를 호출해 서비스 코드에 설정한 데이터베이스 관련 CRUD 작업을 한 번 실행합니다. 그럼 위와 같이 이미 nest js 어플리케이션 실행 시 생성된 커넥션을 그대로 활용하기 때문에 추가적인 프로세스는 생성되지 않은 모습을 확인할 수 있습니다. 단순히 해당 커넥션의 Time 부분이 다시 0초로 바뀌었다가 카운트되는 모습을 확인할 수 있습니다.

4. nest js 서비스 코드 중 데이터베이스에 여러 번 CRUD 작업을 진행하는 메서드 실행 후 커넥션 확인

이번엔 nest js에서 데이터베이스 작업을 20번 연속해서 실행하는 메서드에 요청을 보냅니다. 그럼 위와 같이 총 10개의 데이터베이스 커넥션이 생성된 모습을 확인할 수 있습니다. 이때 궁금한 점이 생깁니다. 왜 20번 요청을 보냈는데 커넥션 수는 10개밖에 생기지 않을까요? 이는 typeorm이 사용하는 mysql2 라이브러리의 디폴트 설정인 것으로 추정됩니다. 이때 더 많은 커넥션이 필요하다면 어떻게 해야할까요?

커넥션 관리하기

typeorm에서는 기본적으로 1개의 커넥션만 생성한 채로 이후 추가 커넥션이 필요할 때마다 커넥션을 추가하는 것으로 보입니다. 그리고 이때 최대로 늘어날 수 있는 커넥션 수는 10개로 보입니다.( typeorm 0.3.21, mysql 8.0 사용 시 ) 이때 최대 커넥션 수를 수정하고 싶다면 아래와 같은 옵션을 사용하면 됩니다.

TypeOrmModule.forRootAsync({
    imports: [ConfigModule],
    inject: [ConfigService],
    useFactory: async (configService: ConfigService) => ({
        type: 'mysql',
        host: configService.get<string>('MYSQL_HOST'),
        port: configService.get<number>('MYSQL_PORT'),
        username: configService.get<string>('MYSQL_USERNAME'),
        password: configService.get<string>('MYSQL_PASSWORD'),
        database: configService.get<string>('MYSQL_DATABASE'),
			
            ...
            
        // ✅ 커넥션 수 설정하기!    
        extra: {
            connectionLimit: 20,
        },
    }),
}),

위처럼 `extra` 옵션을 통해 최대 커넥션 수를 설정할 수 있습니다.