La programmazione è bella

레디스의 자료구조들은 굳이 알아야 할까?

klom — Wed, 8 Jul 2026 08:58:44 +0900

레디스에는 다양한 명령어와 자료구조가 존재합니다. 하지만 막상 어떤 자료구조들이 있는지 하나씩 찾아보며 학습하는 경우는 많지 않습니다. 제가 그 이유를 생각해 보니 크게 두 가지였습니다. 첫 번째는, 프로그래밍을 학습하면서 리스트, 집합, 맵과 같은 기본적인 자료구조를 이미 익혔다고 생각했습니다. 그래서 자료구조 자체는 이미 알고 있다고 생각하며, 굳이 다시 학습할 필요성을 느끼지 못했습니다. 두 번째는, 세상에는 수많은 자료구조가 존재하기 때문에 모든 것을 미리 학습하는 것은 비효율적이라고 생각했습니다. 필요할 때마다 찾아보고 사용하는 것이 더 효율적이라고 판단하게 된다고 생각하였습니다. 그럼에도 제가 레디스의 자료구조를 학습하기로 마음먹은 이유가 있습니다. 레디스의 자료구조는 단순히 데이터를 저장하는 컨테이너가 아니라, 각 자료구조에 대해 원자적인 연산(Atomic Operation) 을 제공합니다. 그렇다면 과연 모든 자료구조가 어떤 원자적 연산을 제공하며, 이를 어떻게 활용할 수 있을지 궁금해졌습니다. 물론 레디스의 모든 자료구조를 학습할 생각은 없습니다. 하지만 필요한 자료구조를 판단할 수 있을 정도의 이해는 갖추고 싶었습니다. 과연 '필요할 때만 찾아보면 된다'는 과거의 생각이 정말 맞았을까요? 이번 글에서는 그 생각을 직접 깨보려고 합니다.

대표적인 자료구조 5종 부터 파악해봅시다.

레디스를 처음 접하면 생각보다 자료구조의 종류가 많아 보입니다. 하지만 실제 서비스에서 가장 많이 사용되는 자료구조는 다음 다섯 가지입니다. String, Hash, List, Set, Sorted Set이 존재합니다.

stream은 Redis5.0에 추가되었다고 합니다. 기본은 Stream을 제외한 5종이 맞습니다.

이 다섯 가지를 이해하면 대부분의 Redis 활용 사례를 이해할 수 있습니다. 이제 각 자료구조가 어떤 특징을 가지며, 어떤 원자적 연산을 제공하는지 하나씩 알아보겠습니다.

String

이름 때문에 문자열만 저장하는 자료구조라고 생각하기 쉽습니다. 하지만 Redis의 String은 문자의 연결이 아니라 바이트(Byte)의 연속된 데이터를 의미합니다. 따라서 텍스트뿐만 아니라 숫자, JSON, 직렬화된 객체, 이미지와 같은 바이너리 데이터까지 저장할 수 있습니다.

그렇다면, 어째서 Redis는 바이트 단위로 저장할까요?

가장 큰 이유는 범용성입니다. 문자 단위로 저장한다면 인코딩(UTF-8, EUC-KR 등)을 신경 써야 하고, 이미지나 직렬화된 객체 같은 바이너리 데이터는 저장하기 어려워집니다. 바이트 단위로 저장하면 이런 구분 없이 모든 데이터를 그대로 담을 수 있습니다.
이를 실제로 저장해봅시다.

이모지를 저장하고 Get을 시켜보겠습니다.

테이블

트리

바이트단위로 저장이 된것을 확인 할 수 있었습니다.

그렇다면, String으로 저장된 데이터는 어떤식으로 이용할 수 있을까요?

String은 데이터를 바이트 단위로 저장합니다. Redis는 싱글 스레드로 명령을 처리하기 때문에, String의 모든 단일 명령은 원자적으로 실행됩니다. 즉, 여러 클라이언트가 동시에 같은 값을 조작해도 각 명령은 끊김 없이 실행됩니다. 이러한 원자성 덕분에 String은 캐시, 분산 락, 카운터 등 값 하나를 안전하게 다뤄야 하는 상황에서 널리 활용됩니다.
하지만 이 원자성은 '단일 값' 단위입니다. 만약 논리적으로 함께 다뤄져야 할 값들이 여럿이라면, 예를 들어 사용자의 이름과 나이가 언제나 함께 갱신되어야 한다면 String을 두 개 사용해서는 원자성을 확보할 수 없습니다. 이런 경우엔 필드 단위로 여러 값을 함께 관리할 수 있는 Hash 같은 다른 자료구조가 필요합니다.

Hash

Hash는 String과 달리 하나의 키 안에서 필드 단위로 접근/수정이 가능합니다. 앞서 Redis의 명령이 원자적으로 실행된다는 점을 살펴봤습니다. 그렇다면 Hash 역시 원자성을 가진다는 뜻이 됩니다.

그렇다면 Hash의 원자성은 String과 무엇이 다를까요?

100명의 사용자가 동시에 사용자 정보를 수정하는 상황을 가정해 보겠습니다.
먼저 String으로 사용자 정보를 저장했다고 가정해 보겠습니다. 이름과 나이를 각각 다른 키에 저장하고 있다면, 이름을 변경하는 SET 명령과 나이를 변경하는 SET 명령은 서로 별개의 명령으로 실행됩니다.
예를 들어 A 클라이언트가 이름을 먼저 변경했다고 하겠습니다. 아직 나이를 변경하기 전에 B 클라이언트가 데이터를 조회한다면 새로운 이름과 기존 나이를 함께 조회할 수 있습니다. 즉, 하나의 사용자 정보가 중간 상태로 노출되어 일관성이 깨질 수 있습니다.
반면 Hash는 하나의 HSET 명령으로 여러 필드를 동시에 수정할 수 있습니다. 예를 들어 이름과 나이를 하나의 HSET 명령으로 변경한다면, 해당 명령은 원자적으로 실행됩니다. 따라서 다른 클라이언트는 수정이 모두 완료된 상태 또는 수정되기 전 상태만 조회할 수 있으며, 이름만 변경되고 나이는 변경되지 않은 중간 상태를 볼 수 없습니다.
즉, Hash가 String보다 더 원자적인 자료구조인 것이 아닙니다. 두 자료구조 모두 Redis 명령은 원자적으로 실행됩니다. 차이점은 String은 여러 값을 수정하려면 여러 개의 명령이 필요하지만, Hash는 여러 필드를 하나의 명령으로 수정할 수 있다는 점입니다. 이 차이로 인해 여러 필드를 함께 관리해야 하는 경우에는 Hash가 데이터의 일관성을 유지하기에 더 적합합니다.

그렇다면, Hash는 언제 사용할까요?

String과 Hash가 크게 다르지 않으니 사용처도 비슷할 것이라 예상할 수 있습니다. 이는 반은 맞고 반은 틀린 답입니다.
사용처의 카테고리 자체는 비슷합니다.
캐싱, 세션, 카운터 등 String이 잘 쓰이는 곳에서 Hash도 자주 쓰입니다. 다만 어느 쪽이 더 자연스러운지는 상황에 따라 다릅니다. 분산 락, 바이너리 통 저장, 단순 캐시된 문자열 같은 경우는 String이 더 자연스럽습니다. 반면 하나의 객체를 이루는 여러 필드를 관리하거나, 부분 갱신이 잦은 상태를 다뤄야 한다면 Hash가 더 자연스럽습니다.
즉, 어떤 자료구조를 쓰느냐는 개발자의 재량이지만, '자연스러움'을 기준으로 판단하는 것이 좋습니다.

List

이제부터 단일 객체가 아닌, 여러 객체를 다루는 자료구조들을 알아봅시다. 그 중 가장 먼저 학습할 자료구조는 List입니다.
프로그래밍 언어에서 List는 여러 값을 순서대로 저장할 수 있는 자료구조입니다.
예를 들어 자바로 작성하면 다음과 같습니다.

List<String> strs = new ArratList<>();

strs.add("1");
strs.add("2");
strs.add("3");

List는 입력한 순서를 유지하고, 중복된 값도 허용한다는 특징이 있습니다. Redis에서는 이러한 List를 어떻게 다루는지 확인해봅시다.
단일 값으로는 String과 Hash가 있습니다. (굳이 따진다면, String은 값이고 Hash는 객체지만 딱히 분류하지는 않겠습니다.)
그렇다면, Redis List에는 어떠한 값이 들어갈 수 있을까요? 그리고 어떻게 사용할까요?
결론부터 말하면, Redis List의 원소로는 String(바이트 시퀀스)만 넣을 수 있습니다. Hash처럼 구조화된 자료구조를 List 원소로 담는 것은 불가능합니다. 이는 Redis의 설계 철학에서 비롯됩니다. Redis는 '단순함'을 최우선으로 두어, 자료구조의 중첩을 허용하지 않습니다. 모든 자료구조는 최상위 키에만 존재하며, 그 안의 원소 값은 언제나 바이트 시퀀스입니다.

그렇다면, List 자료구조는 어떻게 원자성을 지킬 수 있을까?

List의 원자성은 3가지 레벨로 나눠 생각할 수 있습니다.
기본적으로 Redis는 싱글 스레드로 명령을 처리하기 때문에 List의 모든 단일 명령이 원자적으로 실행됩니다.

RPUSH tasks "job"    → 원자적 추가
LPOP tasks           → 원자적 꺼내기
LRANGE tasks 0 -1    → 원자적 스냅샷 조회

즉, 여러 클라이언트가 동시에 조작해도 각 명령은 끊김 없이 실행됩니다. 원자성의 원천은 자료구조가 아닌 Redis의 실행 모델에 있기 때문입니다. 그 다음으로, Hash가 여러 필드를 한 명령으로 다뤘듯 List도 여러 원소를 한 명령으로 처리할 수 있습니다.

RPUSH tasks "job1" "job2" "job3"

세 원소가 원자적으로 한번에 추가되고, 중간에 다른 클라이언트가 낄 수 없습니다. 이 덕분에 큐잉 작업을 안전하게 처리할 수 있습니다.
마지막으로, List에는 리스트 간 원자적 이동이라는 특수 연산이 있습니다.

LMOVE (또는 옛 RPOPLPUSH)
LMOVE source dest LEFT RIGHT

한 리스트에서 꺼내 다른 리스트로 옮기는 작업이 한 명령으로 이뤄지기 때문에 원자적입니다. 이것이 중요한 이유는, 만약 두 명령으로 나눠 처리한다면 다음과 같은 유실 위험이 있기 때문입니다.

LPOP source     → "job" 꺼냄
                ↓ 여기서 서버 죽으면?
                → job 유실!
RPUSH dest "job"

LMOVE는 이 사이의 유실 가능성을 원천 차단합니다. 또한, BLPOP 같은 블로킹 팝 명령도 있습니다. 값이 없으면 원자적으로 대기하고, 값이 생기면 원자적으로 꺼내옵니다. 폴링 없이 안전한 큐 소비 패턴에 활용됩니다.

그렇다면, List는 어떻게 사용 할까요?

List는 앞서 살펴봤듯이 순서가 존재하며, 중복을 허용하는 자료구조입니다. 그렇기 때문에 입력한 순서를 유지해야 하는 상황에서 주로 사용됩니다. 예를 들어 메시지 큐, 최근 목록, 히스토리, 스택 등에서 활용할 수 있습니다.

Set

앞서 살펴본 List와 비교하면, Set은 크게 달라 보이지 않을 수 있습니다. 차이점은 중복을 허용하지 않고, 순서 또한 유지하지 않는다는 점입니다. 프로그래밍 언어의 Set 자료구조를 떠올려보면, 중복을 자동으로 제거해주고 존재 확인이 빠르다는 특징이 있습니다.

Redis에서 Set은 어떤 특별함이 있을까?

사실 프로그래밍 Set과 굉장히 유사합니다. 하지만 Redis는 모든 값들을 원자단위로 관리합니다. 전통적으로 Set은 집합 연산에 능합니다. 이를 Redis에서는 원자단위로 할 수 있다는 점입니다. 예를 들어, 교집합, 합집합, 차집합이 있습니다.
만약 프로그래밍상에서 이들을 구하려면 여러 연산이 뒤섞여서 찾아야 합니다.

Set의 진짜 특별함은 집합 연산에 있습니다. 교집합, 합집합, 차집합 같은 연산을 원자적인 단일 명령으로 처리할 수 있습니다.
예를 들어 Set A에는 {1, 2, 3}이, Set B에는 {3, 4, 5}가 있다고 해봅시다.

- 합집합 A ∪ B = {1, 2, 3, 4, 5}
- 교집합 A ∩ B = {3}
- 차집합 A - B = {1, 2}

일반적인 프로그래밍 언어에서 이런 연산을 하려면 두 집합을 순회하며 조건을 검사하는 여러 단계가 필요합니다. Redis에서는 이를 명령 하나로 원자적으로 처리합니다. 게다가 서로 다른 클라이언트가 각기 관리하는 집합에 대해서도 동일하게 동작하기 때문에, 분산 환경에서의 집합 관계 계산도 자연스럽게 가능해집니다.

그렇다면 어떻게 활용되어질까?

복습해보면, List는 중복은 상관없고 순서가 중요한 경우에 주로 사용된다고 했습니다. 반면 Set의 가장 큰 특징은 중복을 허용하지 않는다는 점입니다. 대표적인 활용 예로는 태그 관리, 팔로우 관계, 방문자 분석, 좋아요 이력, 권한 관리 등이 있습니다. 중복 없이 값을 담아야
하거나, 특정 값의 존재 여부를 빠르게 확인해야 하거나, 두 집합의 공통 원소나 차이를 계산해야 하는 경우 Set이 잘 어울립니다.

특히 팔로우 관계에서 '공통 친구', 방문자 분석에서 '충성 유저 vs 신규 유저 vs 이탈 유저' 같은 계산이 Set의 집합 연산 하나로
해결됩니다.

Sorted Set

Sorted Set은 특별합니다. 단순한 Set이 아니라 정렬까지 지원하기 때문입니다. Set과 마찬가지로 중복은 제거되지만, 각 원소에 ’점수(score)‘를 부여해 그 점수를 기준으로 자동 정렬됩니다.

그런데 여기서 한 가지 의문이 생깁니다. List나 Set은 원소를 추가하기만 합니다. 하지만 Sorted Set은 원소 추가와 함께 정렬까지 수행합니다. 한 명령 안에서 두 가지 일이 벌어지는 셈인데, 이것이 원자적으로 가능할까요? 그리고 성능은 어떻게 유지될까요?

Sorted Set이 원자적으로 정렬과 원소 추가를 할 수 는 방법?

원자성의 원천은 다른 자료구조와 같습니다. Redis는 싱글 스레드로 명령을 하나씩 처리하기 때문에, 명령 안에서 아무리 여러 단계를 거치더라도 그 명령이 실행되는 동안 다른 클라이언트가 끼어들 수 없습니다. 그렇다면 성능은 어떻게 유지될까요? 원소를 넣을 때마다 전체를 정렬한다면 원소가 많아질수록 급격히 느려질 것입니다. Redis는 Skip List라는 자료구조를 활용해 이 문제를 해결합니다. Skip List는 '매번 정렬'하는 것이 아니라 '항상 정렬된 상태를 유지'하는 자료구조로, 원소가 100만 개여도 삽입 위치를 로그 시간에 찾아냅니다.

즉, Sorted Set은 원자적인 동시에 빠릅니다. Redis의 실행 모델이 원자성을 보장하고, Skip List의 특성이 성능을 보장합니다.

그렇다면, Sorted Set은 어떻게 활용할까요?

Sorted Set은 순위, 우선순위, 시간 순서 같은 '점수로 표현할 수 있는 정렬 기준'이 필요할 때 자연스럽습니다. 대표적인 활용 예로는 실시간 랭킹(게임 점수, 인기 게시글), 우선순위 큐(긴급 작업 먼저), 시계열 데이터(활동 이력, 로그), 지연 큐(예약 발송), 자동완성(빈도 기반 추천) 등이 있습니다.

특히 실시간 랭킹에서 점수 증가와 순위 재정렬이 명령 하나로 원자적으로 처리된다는 점이 강력합니다. 일반적인 데이터베이스에서는 트랜잭션과 잠금을 신경 써야 하는 작업이 Sorted Set에서는 자연스럽게 해결됩니다.

이 외에도 Stream이라는 자료구조가 5.0에서 추가되었습니다. 로그형 자료구조로 이벤트 스트리밍이나 메시지 큐에 활용되지만, 개념이 다른 차원이라 별도 학습이 필요합니다. 이 글에서는 기본 5개 자료구조에 집중합니다.

모든 자료구조의 기본적인 명령어를 표로 알아보자.

추가 (ADD/SET/PUSH)

패턴	String	Hash	List	Set	Sorted Set
기본 추가	SET	HSET	LPUSH / RPUSH	SADD	ZADD
조건부 추가	SET ... NX	HSETNX	-	-	ZADD ... NX

조회 (GET)

패턴	String	Hash	List	Set	Sorted Set
단건 조회	GET	HGET	LINDEX	SISMEMBER	ZSCORE
다건 조회	MGET	HMGET	LRANGE	SMISMEMBER	ZRANGE
전체 조회	GET	HGETALL	LRANGE 0 -1	SMEMBERS	ZRANGE 0 -1

삭제 (DEL / REM)

패턴	String	Hash	List	Set	Sorted Set
값/필드 삭제	DEL (키)	HDEL	LREM	SREM	ZREM
꺼내면서 삭제	GETDEL	-	LPOP / RPOP	SPOP	ZPOPMIN / ZPOPMAX

개수 (LEN / CARD)

패턴	String	Hash	List	Set	Sorted Set
개수	STRLEN (바이트)	HLEN	LLEN	SCARD	ZCARD

존재 확인 (EXISTS)

패턴	String	Hash	List	Set	Sorted Set
존재 확인	EXISTS (키)	HEXISTS	-	SISMEMBER	ZSCORE (nil 여부)

증가 (INCRBY)

패턴	String	Hash	List	Set	Sorted Set
원자 증가	INCR / INCRBY	HINCRBY	-	-	ZINCRBY

반복 순회 (SCAN)

패턴	String	Hash	List	Set	Sorted Set
대용량 순회	SCAN (키)	HSCAN	-	SSCAN	ZSCAN

블로킹 (B 접두사)

패턴	List	Sorted Set
블로킹 꺼내기	BLPOP / BRPOP	BZPOPMIN / BZPOPMAX

예외

예외 명령	이유
MSET / MGET	Multiple의 M (String 전용)
GETSET / GETDEL / GETEX	복합 동작 (String)
SINTER / SUNION / SDIFF	Set 집합 연산 (교/합/차)
LMOVE / RPOPLPUSH	List 간 원자 이동
ZRANGEBYSCORE / ZRANGEBYLEX	Sorted Set 범위 종류

마무리

이번 글에서는 Redis의 자료구조에 대해 살펴봤습니다. 학습을 진행하면서 Redis의 모든 자료구조가 원자적으로 동작한다는 것을 알게 되었습니다. 그러다보니 자연스럽게 "어떻게 원자적으로 가능한지"가 궁금해졌습니다. 여러 자료를 찾아보며 '아, 이래서 원자적이구나' 하고 깨닫게 되었습니다.
또한 자료구조들이 비슷해 보여도 각자의 사용처가 확실하게 구분된다는 점을 느꼈습니다. 처음에는 "필요할 때만 찾아보면되겠지" 싶었지만, 원리를 이해하고 나니 언제 어떤 자료구조를 선택해야 하는지 감이 잡히더군요.
몇 가지 남은 아쉬움도 있습니다. 첫째, Stream이라는 자료구조는 다루지 않았습니다. 지금까지 살펴본 자료구조와 성격이 상이하다고 느꼈기 때문입니다. 기본 자료구조와는 다른 카테고리로 느껴져 이 글에 함께 담기에는 무리가 있었습니다. 이 부분은 나중에 별도의 글로 풀어보려고 합니다. 둘째, 각 자료구조 간 비교가 충분하지 않은 것도 사실입니다. 자바 자료구조와의 대비를 통해 실무 감각을 더 살려볼 수 있을텐데, 이 부분도 다음 기회에 시도해보려고 합니다.

긴 글 읽어주셔서 감사합니다.

레디스가 싱글 스레드임에도 불구하고 빠른이유

klom — Sat, 4 Jul 2026 02:33:34 +0900

일반적으로는 싱글 스레드보다 멀티 스레드가 더 빠르다고 생각합니다. 실제로도 혼자 일하는 것보다 여러 사람이 함께 일하는 편이 더 많은 일을 처리할 수 있습니다. 하지만 우리가 간과하기 쉬운 사실이 하나 있습니다. 바로 락(Lock) 입니다. 멀티 스레드는 여러 작업을 동시에 처리할 수 있지만, 공유 자원에 접근하는 순간 락이 발생합니다. 락 경쟁이 심해질수록 스레드는 대기하거나 문맥 교환을 반복하게 되고, 기대했던 성능 향상을 얻지 못하는 경우도 적지 않습니다. 그렇다면 락을 사용하는 멀티 스레드보다, 락 자체가 필요 없는 싱글 스레드가 더 효율적일 수도 있지 않을까요? 오늘날 Redis, Nginx, Node.js처럼 싱글 스레드 기반의 이벤트 루프를 활용하는 기술들은 이러한 질문에 대한 하나의 답을 보여 주고 있습니다. 하지만 이러한 발상이 처음부터 존재했던 것은 아닙니다. 그 시작은 1999년 Dan Kegel이 제시한 C10K 문제에 있습니다. 당시 서버는 1만 개의 동시 연결조차 효율적으로 처리하지 못했고, 기존의 멀티 스레드 멀티 프로세스 모델은 한계를 드러내고 있었습니다.

이번 글에서는 C10K 문제가 무엇이었는지, 왜 기존 방식으로는 해결하기 어려웠는지, 그리고 이 문제가 이후의 서버 아키텍처와 이벤트 기반 프로그래밍에 어떤 영향을 주었는지 살펴보겠습니다.

C10K 문제란 무엇일까?

생각보다 문제는 단순합니다.

"서버가 동시에 10,000개의 클라이언트 연결을 처리하려면 어떻게 해야 할까?"

이 질문이 바로 C10K(C10,000) 문제입니다.

1999년 Dan Kegel은 당시 서버 아키텍처가 10,000개의 동시 연결을 효율적으로 처리하지 못한다는 점을 지적했습니다. 당시에는 연결마다 하나의 프로세스나 스레드를 생성하는 방식이 일반적이었습니다.

예를 들어 동시에 10,000명의 사용자가 서버에 접속한다면, 서버는 최대 10,000개의 스레드를 생성하게 됩니다. 처음에는 각 스레드가 독립적으로 요청을 처리하므로 효율적으로 보일 수 있습니다.

하지만 스레드가 많아질수록 문제가 발생합니다. 각 스레드는 메모리를 차지할 뿐만 아니라, 운영체제는 여러 스레드를 번갈아 실행하기 위해 끊임없이 문맥 교환(Context Switching) 을 수행해야 합니다. 결국 CPU는 실제 요청을 처리하는 시간보다 스레드를 전환하는 데 더 많은 시간을 사용하게 되고, 서버의 성능은 급격히 저하됩니다.

그렇다면 정말 연결마다 스레드를 하나씩 생성해야만 할까요? 하나의 스레드가 여러 연결을 효율적으로 관리할 수는 없을까요?
C10K 문제는 바로 이러한 질문에서 시작되었습니다.

I/O 멀티 플렉싱(I/O Multiplexing)

C10K 문제를 해결하기 위한 방법은 여러 가지가 있지만, 그중 가장 대표적인 기술이 I/O 멀티플렉싱(I/O Multiplexing) 입니다.

멀티플렉싱(Multiplexing)을 직역하면 '여러 개를 하나로 처리한다'는 의미를 가지고 있습니다.

기존의 서버는 연결(Connection) 하나당 하나의 스레드를 생성하여 요청을 처리했습니다. 따라서 동시에 연결되는 클라이언트가 많아질수록 스레드 수도 함께 증가했고, 메모리 사용량과 문맥 교환(Context Switching) 비용도 커질 수밖에 없었습니다.

반면, I/O 멀티플렉싱은 하나의 스레드가 여러 연결을 동시에 감시하다가 이벤트가 발생한 연결만 선택적으로 처리하는 방식입니다. 즉, 모든 연결에 스레드를 할당하는 것이 아니라, 하나의 스레드가 여러 연결을 효율적으로 관리할 수 있도록 만든 기술입니다.

덕분에 적은 수의 스레드만으로도 수많은 동시 연결을 처리할 수 있게 되었으며, C10K 문제를 해결하는 핵심 기술로 자리 잡게 되었습니다.

I/O 멀티플렉싱을 기반으로 select, poll, epoll, kqueue와 같은 다양한 기술이 등장했습니다.

이러한 기술의 발전으로 하나의 스레드가 여러 연결을 지속적으로 감시하고, 이벤트가 발생한 연결만 처리하는 이벤트 루프(Event Loop) 방식이 널리 사용되기 시작했습니다.

이벤트 루프

이벤트 루프(Event Loop)라는 이름을 보면 이벤트를 반복적으로 처리하는 구조라는 의미를 떠올릴 수 있습니다.

실제로 이벤트 루프는 하나의 스레드에서 계속 실행되며, 이벤트가 발생한 연결을 확인하고 해당 작업을 처리하는 실행 방식입니다. 즉, 모든 연결에 스레드를 생성하는 것이 아니라 하나의 스레드가 지속적으로 이벤트를 감시하고, 이벤트가 발생한 연결만 선택적으로 처리합니다.

이러한 방식 덕분에 적은 수의 스레드만으로도 많은 동시 연결을 효율적으로 처리할 수 있습니다.

그렇다면 이벤트 루프는 실제로 어떻게 동작할까요? 간단한 자바 코드를 통해 살펴보겠습니다.

구현

public class EventLoop {

    public static void main(String[] args) throws Exception {

        List<Connection> connections = List.of(
                new Connection("Client-1"),
                new Connection("Client-2"),
                new Connection("Client-3")
        );

        while (server.isRunning()) {

            // 이벤트가 발생한 연결만 가져온다.
            List<Connection> readyConnections = findReadyConnections(connections);

            // 이벤트 처리
            for (Connection connection : readyConnections) {
                connection.handle();
            }
        }
    }

    private static List<Connection> findReadyConnections(List<Connection> connections) {

        return connections.stream()
                .filter(Connection::hasEvent)
                .toList();
    }
}

class Connection {

    private final String name;

    Connection(String name) {
        this.name = name;
    }

    boolean hasEvent() {
        // 실제로는 epoll, kqueue 등이 이벤트를 알려준다.
        return Math.random() > 0.7;
    }

    void handle() {
        System.out.println(name + " 요청 처리");
    }
}

이벤트 루프는 매우 단순한 구조입니다.

먼저 이벤트가 발생한 연결을 확인한 뒤(findReadyConnections()), 이벤트가 존재하는 연결만 순회하며 처리합니다(handle()). 이후 다시 이벤트를 확인하고 처리하는 과정을 계속 반복합니다. 실제 운영체제에서는 findReadyConnections() 역할을 epoll, kqueue와 같은 I/O 멀티플렉싱 기술이 수행합니다. 이벤트 루프는 전달받은 이벤트만 처리하면서 계속 반복 실행됩니다. Redis의 이벤트 루프도 개념적으로는 이 구조와 거의 같습니다. 다만 실제 구현에서는 epoll_wait() 등이 이벤트가 발생할 때까지 블로킹하며 대기하고, 이벤트가 발생하면 해당 이벤트 목록만 전달받아 처리하는 방식으로 동작합니다.

여기서는 epoll을 "이벤트가 발생했음을 알려주는 알람 기능" 정도로 이해해도 충분합니다. 내부 동작은 훨씬 복잡하지만, 이벤트 루프가 필요한 연결만 처리할 수 있도록 도와주는 역할을 한다고 생각하면 됩니다.

이벤트 기반 서버를 구현하는 대표적인 I/O 처리 패턴

이벤트 기반 서버를 구현하는 대표적인 I/O 처리 패턴은 Reactor와 Proactor, 크게 두 가지입니다. 앞에서 살펴본 코드는 이벤트 루프의 동작 원리를 이해하기 위해 단순화한 예제입니다. 실제 시스템에서는 이벤트를 감지하고 처리하는 방식에 따라 Reactor와 Proactor 패턴으로 구현됩니다. 두 패턴 모두 이벤트 기반으로 동작한다는 공통점이 있지만, 누가 I/O를 수행하고 이벤트를 처리하는지에 따라 동작 방식에 차이가 있습니다.

이 글에서는 Reactor 패턴을 중심으로 설명하겠습니다. 그 이유는 Reactor 패턴이 Redis를 비롯해 Nginx, Netty와 같은 네트워크 서버에서 널리 사용되는 이벤트 처리 방식이기 때문입니다. 반면 Proactor 패턴도 이벤트 기반으로 동작하지만, 주로 운영체제가 비동기 I/O를 직접 지원하는 환경에서 사용됩니다. 따라서 Redis의 동작 방식을 이해하기 위해서는 Reactor 패턴을 먼저 이해하는 것이 가장 자연스럽습니다.

Reactor

Reactor Pattern은 이벤트가 발생할 때까지 기다렸다가(Event Demultiplexing), 이벤트가 발생하면 해당 이벤트를 적절한 처리 로직(Handler)으로 전달하는 이벤트 기반 설계 패턴입니다. 쉽게 말하면 "이벤트를 감지하고, 적절한 담당자에게 일을 분배하는 패턴"이라고 생각하면 됩니다.

while (true) {

    List<Event> events = findReadyEvents();

    for (Event event : events) {
        reactor.dispatch(event);
    }
}

public void dispatch(Event event) {

    switch (event.getType()) {
        case GET -> get(event);
        case SET -> set(event);
        case DEL -> del(event);
    }
}

이벤트 루프가 계속 실행되면서 이벤트를 기다리고 있다가, 이벤트가 발생하면 어떤 작업을 수행해야 하는지 확인한 뒤 해당 처리 로직을 호출합니다.

Redis는 클라이언트의 요청을 적절한 명령 처리 로직으로 전달하기 위해 Reactor 패턴을 사용합니다.

결론

이번 글에서는 Redis가 싱글 스레드임에도 높은 성능을 낼 수 있는 이유를 C10K 문제부터 I/O 멀티플렉싱, 이벤트 루프, 그리고 Reactor 패턴까지 살펴보며 알아보았습니다. Redis가 단순히 "싱글 스레드라서 빠르다"가 아니라, C10K 문제를 해결하기 위해 등장한 기술과 설계 방식을 적극적으로 활용한 결과라는 점을 이해할 수 있었습니다. 다만 이번 글에서는 주제에서 벗어나지 않기 위해 Reactor 패턴의 내부 동작이나 구현 방식까지는 자세히 다루지 않았습니다. Redis의 동작 원리를 이해하는 데 필요한 수준에서만 살펴보았습니다.

다음 글에서는 Reactor 패턴을 조금 더 깊이 있게 살펴보고, 또 다른 이벤트 처리 방식인 Proactor 패턴과의 차이점도 함께 알아보겠습니다. 두 패턴은 모두 이벤트 기반으로 동작하지만 I/O를 처리하는 방식에 차이가 있으며, 어떤 환경에서 각각이 적합한지도 함께 살펴볼 예정입니다.

경쟁조건을 해결하거나 완화하기 위한 다양한 기술들

klom — Mon, 29 Jun 2026 08:54:55 +0900

여러 요청이 동시에 같은 데이터를 수정하려고 하면, 실행 순서에 따라 결과가 달라질 수 있습니다. 이러한 문제를 경쟁 조건이라고 합니다. 가장 대표적인 해결 방법은 락 을 사용하는 것입니다. 락을 사용하면 하나의 요청이 공유 자원을 사용하는 동안 다른 요청들은 해당 자원에 접근하지 못하고 대기하게 됩니다. 이후 현재 작업이 모두 끝나고 락이 해제되면 다음 요청이 자원을 사용할 수 있으므로 경쟁 조건을 방지할 수 있습니다. 하지만 락이 항상 좋은 해결책인 것은 아닙니다. 하나의 요청이 작업을 수행하는 동안 다른 요청들은 모두 대기해야 하므로 동시성이 낮아지고 응답 시간이 증가할 수 있습니다. 또한 요청이 많아질수록 대기 시간이 길어져 전체 처리량이 감소하는 문제도 발생할 수 있습니다. 그렇다면 경쟁 조건을 해결하기 위해 락만이 유일한 방법일까요? 락의 단점을 보완하면서도 경쟁 조건을 해결할 수 있는 다른 방법은 없을까요? 이번 글에서는 이러한 해결 방법에 대해 알아보겠습니다.

경쟁조건이 발생한다는건 어떤 의미일까?

경쟁 조건은 여러 스레드나 여러 서버가 동시에 동일한 자원에 접근하는 환경에서 발생할 수 있습니다. 특히 분산 환경에서는 여러 서버가 동일한 데이터를 동시에 수정할 수 있기 때문에, 경쟁 조건을 더욱 주의해야 합니다.

예를 들어 재고가 100개인 상품이 있다고 가정해 보겠습니다. 100개의 스레드가 동시에 재고를 1개씩 차감한다면, 정상적인 결과는 재고가 0개가 되는 것입니다.

하지만 경쟁 조건이 발생하면 여러 스레드가 동일한 재고 값을 동시에 읽고 수정하면서 일부 차감 연산이 반영되지 않을 수 있습니다. 실제로 테스트해 보면 재고가 87개와 같이 예상과 다른 결과가 나오는 경우도 발생합니다.

이러한 현상을 경쟁 조건(Race Condition) 이라고 합니다. 여러 스레드나 서버가 동시에 동일한 자원에 접근하면서 서로의 작업이 충돌하여, 예상했던 결과와 다른 값이 발생하는 것입니다.

이러한 경쟁 조건을 해결하기 위해 가장 널리 사용되는 방법 중 하나인 Lock을 적용해보겠습니다.

하지만 Lock을 사용하면 하나의 요청이 작업을 수행하는 동안 다른 요청들은 대기해야 하므로, 동시성이 낮아지고 성능이 저하될 수 있습니다. 요청 수는 10만건으로 테스트를 진행해보겠습니다.

10만 건의 요청을 기준으로 테스트한 결과, 전체 처리 시간은 59.97초였으며 처리량은 약 1,667 req/s를 기록했습니다. 또한 평균 응답 시간은 0.600ms로 측정되었습니다.

아직까지는 Lock이 실제로 성능을 얼마나 저하시켰는지는 판단하기 어려웠습니다. 다만 10만 건의 요청을 처리하는 데 약 1분이 소요된 것을 보면, 개선의 여지가 있지 않을까 하는 생각이 들었습니다.

Lua script

Lock만이 경쟁 조건을 해결하는 유일한 방법은 아닙니다. Lock을 사용하지 않고도 경쟁 조건을 해결하거나 완화할 수 있는 방법이 있으며, 그중 하나가 Lua Script입니다. 이번에는 Lock 대신 Lua Script를 적용하여 성능과 동작 방식을 비교해보겠습니다.

다행히 경쟁조건은 해결한듯합니다.

그렇다면, 10만건을 대상으로 진행하면 어떻게 되는지 Lock과 비교를 해봅시다.

소요 시간이 20배 가까이 빨라졌다는 것을 알 수 있습니다.

그렇다면 왜 이렇게 빠를까요?

분산 락은 일반적으로 락 획득 → 비즈니스 로직 수행 → 락 해제 과정을 거칩니다. 이 과정에서 Redis와 여러 번 통신해야 하므로 네트워크 왕복(RTT)이 반복적으로 발생하고, 락을 획득하기 위해 대기하는 시간도 생길 수 있습니다.

반면 Lua Script는 여러 Redis 명령을 하나의 스크립트로 묶어 원자적으로 실행합니다. 따라서 클라이언트는 Redis와 한 번의 네트워크 왕복(RTT) 만 수행하면 되고, 스크립트 내부에서는 다른 요청이 개입하지 않으므로 경쟁 조건도 방지할 수 있습니다.

또한 Redis를 단일 데이터 저장소로 사용하는 경우에는 DB를 별도로 조회하거나 갱신하는 과정이 줄어들기 때문에 성능 향상에 더욱 큰 영향을 줄 수 있습니다.

하지만 그렇다고 해서 Lua Script가 항상 정답은 아닙니다. Redis가 단일 진실 소스(Single Source of Truth) 가 되는 만큼, 데이터의 영속성이나 감사(Audit)가 필요한 서비스라면 DB와의 동기화 전략도 함께 고려해야 합니다. 예를 들어 CDC(Change Data Capture) 나 비동기 이벤트를 이용하여 Redis와 DB의 데이터를 동기화하는 방식을 선택할 수 있습니다.

그렇다면 Lua Script로 변경하는 것이 항상 좋은 선택일까요?

가장 큰 단점은 경쟁 조건을 해결하는 로직이 애플리케이션이 아닌 Lua Script에 작성된다는 점입니다. 따라서 Java 코드만으로는 전체 동작을 파악하기 어렵고, 디버깅이나 테스트도 상대적으로 까다로워질 수 있습니다.

또한 Redis는 단일 스레드 기반으로 Lua Script를 실행하기 때문에, 스크립트의 실행 시간이 길어질수록 다른 요청들도 함께 대기하게 됩니다. 따라서 복잡한 비즈니스 로직을 Lua Script에 작성하기보다는, 짧고 원자적인 작업만 수행하도록 구성하는 것이 좋습니다.

정렬 집합

Lock이나 Lua Script를 사용하지 않고도 경쟁 조건을 해결하거나 완화할 수 있는 방법은 없을까요? 이번에 살펴볼 방법은 정렬 집합(Sorted Set) 을 활용하는 방식입니다.

기본적인 아이디어는 단순합니다. 요청을 일정한 기준으로 정렬하여 관리함으로써 동일한 자원에 대한 충돌을 최소화하는 것입니다. 이를 통해 복잡한 락을 사용하지 않고도 경쟁 조건을 완화할 수 있으며, 특히 시간 순서가 중요한 데이터나 요청을 처리할 때 효과적으로 활용할 수 있습니다.

예상과 달리 정렬 집합만 했을뿐인데도 재고는 0으로 찍혔다는것을 알 수 있었습니다.

엄청난 성능 향상이 있었던 것은 아니지만, 이전 방식보다 준수한 성능을 보여주었습니다. 특히 10만 건의 요청을 기준으로 했을 때도 Lua Script와의 차이는 약 3초 정도에 불과했습니다.

또한 Lua Script와 달리 순수하게 Java 코드만으로 구현할 수 있다는 점도 큰 장점이라고 생각합니다. 별도의 스크립트를 관리할 필요가 없기 때문에 디버깅과 테스트가 비교적 수월하며, 유지보수 측면에서도 부담이 적습니다.

여기서 한 가지 의문이 생깁니다. 단순히 정렬만 했을 뿐인데 어떻게 경쟁 조건을 해결할 수 있었던 걸까요? 정렬 집합은 어떤 원리로 경쟁 조건을 완화하는지 함께 살펴보겠습니다.

정렬 집합은 어떻게 경쟁 조건을 완화할 수 있을까?

엄밀히 말하자면, 정렬 집합만으로 경쟁 조건을 해결할 수는 없습니다. 그럼에도 불구하고 경쟁 조건을 완화하는 데 활용되는 이유는 데이터를 일정한 기준으로 정렬하여 일관성 있게 관리할 수 있기 때문입니다.

예를 들어 시간(timestamp)을 기준으로 정렬한다면, 각 요청은 발생한 시점에 따라 순서가 부여됩니다. 이렇게 되면 요청의 순서를 쉽게 파악할 수 있고, 특정 범위의 데이터를 조회하거나 오래된 데이터를 제거하는 작업도 효율적으로 수행할 수 있습니다.

즉, 정렬 집합은 여러 요청이 하나의 값을 반복해서 수정하는 구조가 아니라, 각 요청을 독립적인 데이터로 관리할 수 있도록 도와주는 자료구조입니다. 이러한 특성 덕분에 데이터 충돌이 발생하기 쉬운 구조를 개선할 수 있으며, 경쟁 조건을 완화하는 데 활용됩니다.

사실, 경쟁 조건을 해결할 수 있었던 것은 정렬 집합이 아니라 Redis의 특성 때문입니다. Redis는 싱글 스레드로 동작합니다. 즉, 하나의 요청을 처리하는 동안 다른 요청은 순차적으로 대기하게 됩니다. 이러한 특성 덕분에 요청이 순차적으로 처리되어 경쟁 조건을 해결할 수 있습니다.

결론

이번 학습을 통해 경쟁 조건은 반드시 Lock만으로 해결해야 하는 문제가 아니라는 것을 알게 되었습니다. 대표적으로 Lua Script와 정렬 집합(Sorted Set) 을 이용해서도 경쟁 조건을 해결하거나 완화할 수 있었습니다.

이 두 방법의 핵심은 원자성(Atomicity) 입니다. 원자성이란 하나의 작업을 중간에 다른 요청이 개입할 수 없는 하나의 작업 단위로 처리하는 특성을 의미합니다. 예를 들어 추가와 삭제 작업을 하나의 작업 단위로 처리함으로써 경쟁 조건을 방지할 수 있습니다.

성능만 비교한다면 Lua Script가 가장 좋은 결과를 보여주었습니다. 다만 원자성을 보장하는 로직이 Java 코드가 아닌 Lua Script에 작성되기 때문에, 문제가 발생했을 경우 디버깅이나 유지보수가 다소 어려울 수 있습니다. 따라서 Lua Script는 스크립트만으로도 동작을 쉽게 이해할 수 있을 정도의 단순한 로직에 사용하는 것이 적합하다고 생각합니다.

반면 정렬 집합은 Lua Script보다는 성능이 다소 떨어졌지만 충분히 준수한 성능을 보여주었습니다. 또한 Java 코드만으로 구현할 수 있다는 점도 장점이라고 생각합니다. 따라서 구현해야 하는 로직이 다소 복잡하거나 Java 코드 중심으로 관리하고 싶다면 정렬 집합도 충분히 좋은 선택지가 될 수 있다고 생각합니다.

그렇다면 Lock은 사용하지 말아야 할까요? 그렇지는 않습니다. Lock은 경쟁 조건을 가장 확실하게 방지할 수 있는 방법 중 하나입니다. 다만 다른 방식에 비해 성능 저하가 발생할 수 있으므로, 실시간 처리가 중요한 환경에서는 신중하게 사용하는 것이 좋다고 생각합니다. 반대로 배치 작업이나 스케줄링처럼 처리 시간이 다소 길어져도 문제가 없는 환경에서는 Lock이 가장 적합한 선택이 될 수 있다고 생각합니다.

Rate Limiter (intro.)

klom — Sun, 28 Jun 2026 01:59:19 +0900

수많은 사용자들이 동시에 서비스에 접근하게 되면 서비스가 정상적으로 동작하지 못하는 상황이 발생할 수 있습니다. 특히 특정 사용자가 과도한 요청을 보내거나 예상보다 많은 트래픽이 유입되는 경우, 서버의 자원이 빠르게 소모되어 응답 지연이나 장애로 이어질 수 있습니다.이러한 문제를 방지하기 위해 서비스는 사용할 수 있는 자원을 적절히 제어해야 하며, 그중 가장 대표적인 방법이 Rate Limiter입니다. Rate Limiter는 일정 시간 동안 허용되는 요청 수를 제한하여 서비스의 안정성을 보장하고, 모든 사용자에게 공정한 사용 환경을 제공하는 역할을 합니다.

Rate Limiter를 왜 사용해야 할까? 대안은 없을까?

본론적으로 생각해보면 API 요청에 굳이 제한을 두어야 하는지 의문이 들 수 있습니다. 캐시를 활용하여 응답 속도를 개선하거나, 큐를 이용해 요청을 순차적으로 처리하고, 서버를 증설하여 처리량을 늘리는 방법도 존재하기 때문입니다. 이러한 방법들만으로도 충분히 트래픽 문제를 해결할 수 있다고 생각할 수 있습니다.

또한 Rate Limiter를 적용하면 모든 요청에 대해 제한 여부를 확인해야 하므로 API 성능에 영향을 주지 않을까 걱정될 수도 있습니다. 하지만 일반적으로 Rate Limiter가 성능 저하의 원인이 될 정도라면 설계 자체에 문제가 있을 가능성이 높습니다. 대부분의 Rate Limiter는 메모리 기반 저장소를 활용하거나 단순한 카운팅 연산만 수행하기 때문에 오버헤드가 크지 않습니다.

물론 캐시, 큐, 서버 증설과 같은 방법은 시스템의 처리 능력을 높이거나 부하를 분산시키는 데 효과적입니다. 하지만 이러한 방법들은 시스템이 더 많은 요청을 처리할 수 있도록 돕는 역할일 뿐, 과도한 요청 자체를 제어하지는 못합니다.

반면 Rate Limiter는 시스템이 감당할 수 있는 수준 이상의 요청을 사전에 제한함으로써 서비스 전체를 보호합니다. 따라서 Rate Limiter는 캐시나 큐, 서버 증설을 대체하는 기술이 아니라, 예기치 못한 트래픽 증가나 비정상적인 요청으로부터 시스템을 보호하기 위한 안정장치(Safety Net)로 이해하는 것이 적절하다고 생각합니다.

그렇다면, Rate Limiter는 어느 위치에 둬야할까요?

Rate Limiter는 크게 클라이언트, 서버, 그리고 미들웨어 계층에 배치할 수 있습니다. 어느 위치에 배치하느냐에 따라 목적과 효과가 조금씩 달라집니다. 예를 들어, 클라이언트 측에 Rate Limiter를 적용하면 사용자는 요청 제한 여부를 즉시 확인할 수 있으므로 사용자 경험(UX) 측면에서 유리합니다. 또한 중복 클릭이나 짧은 시간 내 반복 요청을 방지하여 불필요한 네트워크 트래픽을 줄일 수 있습니다.

하지만 클라이언트는 사용자가 제어할 수 있는 영역입니다. 브라우저의 개발자 도구를 이용하거나 직접 API를 호출하는 방식으로 제한을 우회할 수 있기 때문에, 보안이나 서버 보호 관점에서는 신뢰하기 어렵습니다. 따라서, 클라이언트 측 Rate Limiter는 서버를 보호하기 위한 수단이라기보다는 사용자 경험을 개선하고 불필요한 요청을 줄이기 위한 보조적인 수단으로 활용됩니다.

그렇다면, 서버에 Rate Limiter를 두는 이유는 무엇일까요?

가장 큰 이유는 서버가 신뢰할 수 있는 영역이기 때문입니다. 클라이언트 측에 적용된 Rate Limiter는 사용자가 직접 수정하거나 우회할 수 있지만, 서버 측 Rate Limiter는 모든 요청이 반드시 거쳐야 하는 지점에서 동작하므로 우회가 어렵습니다. 또한, 서버는 전체 트래픽 현황을 파악할 수 있습니다. 특정 사용자가 짧은 시간 동안 과도한 요청을 보내고 있는지, 특정 IP에서 비정상적인 트래픽이 발생하고 있는지, 혹은 서비스 전체가 처리 가능한 한계를 초과하고 있는지 등을 판단할 수 있습니다. 무엇보다 서버 측 Rate Limiter는 애플리케이션 로직이 수행되기 전에 요청을 차단할 수 있다는 장점이 있습니다. 만약 제한 없이 모든 요청을 애플리케이션까지 전달한다면 CPU, 메모리, 데이터베이스 커넥션과 같은 자원이 불필요하게 소모될 수 있습니다. 반면 Rate Limiter를 통해 초기에 요청을 거부하면 시스템 자원을 보호하고 서비스 전체의 안정성을 유지할 수 있습니다.

따라서 클라이언트 측 Rate Limiter가 사용자 경험 향상을 위한 보조 수단이라면, 서버 측 Rate Limiter는 시스템을 보호하기 위한 핵심 방어 수단이라고 볼 수 있습니다.

추가적으로 애플리케이션 서버 앞단에 위치한 게이트웨이를 통해 Rate Limiter를 적용할 수도 있습니다. 게이트웨이는 클라이언트의 요청을 가장 먼저 수신하는 계층으로, 인증, 로깅, 라우팅, Rate Limiting과 같은 공통 기능을 처리하는 역할을 담당합니다.

Rate Limiter를 게이트웨이에 배치하면 애플리케이션 서버에 요청이 전달되기 전에 제한 여부를 판단할 수 있습니다. 이를 통해 불필요한 요청이 서버까지 도달하는 것을 방지하고, 애플리케이션의 자원을 더욱 효율적으로 보호할 수 있습니다.

실제로 스프링 생태계에서는 Spring Cloud Gateway를 제공하며, Redis 기반의 Rate Limiting 기능을 지원합니다. 이를 활용하면 별도의 Rate Limiter를 직접 구현하지 않고도 요청 수를 효과적으로 제어할 수 있습니다.

그렇다면, 단순히 요청을 count하면 되지 않을까요?

단순하게 생각하면 API 요청 횟수를 데이터베이스에 저장하고, 요청이 들어올 때마다 조회하여 제한 여부를 판단하면 될 것 같습니다. 하지만 Rate Limiter를 설계할 때 가장 중요한 점은 Rate Limiter 자체가 시스템에 큰 부하를 주어서는 안 된다는 것입니다.

만약 모든 API 요청마다 데이터베이스에 접근하여 요청 횟수를 조회하고 갱신한다면, 트래픽이 증가할수록 데이터베이스에 과도한 부하가 발생할 수 있습니다. 극단적인 경우에는 서비스 로직보다 Rate Limiter가 더 많은 자원을 소비하는 상황이 발생할 수도 있습니다.

따라서 Rate Limiter는 요청을 제한하는 기능뿐만 아니라, 매우 빠른 속도로 동작해야 한다는 요구사항도 함께 만족해야 합니다. 이상적인 Rate Limiter는 요청 처리에 미치는 영향을 최소화하면서도 정확하게 요청 횟수를 제어할 수 있어야 합니다.

그렇다면 데이터베이스의 부하를 최소화하면서도 효과적으로 요청 수를 관리할 수 있는 방법은 무엇일까요?
Rate Limiter를 구현하기 위한 알고리즘은 다양하지만, 큰 관점에서 보면 버킷(Bucket) 기반 알고리즘과 윈도우(Window) 기반 알고리즘으로 구분할 수 있습니다.

버킷 기반 알고리즘

버킷(Bucket)을 바구니라고 생각해봅시다. 그리고 바구니 안에는 요청을 처리할 수 있는 권한인 토큰(Token)이 들어있다고 가정하겠습니다.

그렇다면 버킷 기반 알고리즘은 크게 두 가지 관점으로 생각해볼 수 있습니다. 첫 번째는 일정한 속도로 버킷에 토큰을 채우는 방법이고, 두 번째는 요청이 발생할 때 버킷에서 토큰을 소비하는 방법입니다.

결국 버킷 기반 알고리즘은 토큰을 어떻게 채우고, 어떻게 소비하느냐에 따라 다양한 형태로 구현될 수 있습니다. 대표적으로 Token Bucket은 요청이 발생할 때 토큰을 소비하는 방식으로 동작하며, Leaky Bucket은 일정한 속도로 요청을 처리하도록 제어하는 방식으로 동작합니다.

Token Bucket

이에 해당하는 그림을 그려보면 다음과 같이 그릴 수 있습니다.

토큰은 일정한 주기에 따라 버킷에 충전됩니다. 그리고 API 요청이 들어오면 버킷에 저장된 토큰을 하나 소비하여 요청을 처리합니다.

하지만 버킷에 사용할 수 있는 토큰이 남아 있지 않다면 요청은 거부되며, 일반적으로 HTTP 429(Too Many Requests)를 반환합니다.

이 알고리즘에서 가장 중요한 것은 토큰의 충전 속도(Refill Rate) 와 버킷의 최대 크기(Capacity) 를 어떻게 설정할 것인가입니다. 예를 들어, 초당 2개의 토큰을 충전하는 경우와 2초마다 1개의 토큰을 충전하는 경우는 장기적인 처리량은 비슷할 수 있지만, 순간적인 요청을 처리하는 방식에는 차이가 발생합니다.

또한, 버킷의 크기가 크다면 평소 사용하지 않은 토큰을 저장해 두었다가 순간적으로 많은 요청(Burst Traffic)이 발생했을 때 이를 처리할 수 있습니다. 반대로 버킷의 크기가 작거나 충전 속도가 너무 느리다면 정상적인 사용자도 요청이 제한될 수 있습니다.

따라서 Token Bucket 알고리즘은 토큰을 얼마나 빠르게 충전할 것인지와 버킷의 크기를 어떻게 설정할 것인지가 성능을 결정하는 핵심 요소라고 볼 수 있습니다.

Leaky Bucket

Token Bucket은 버킷에 토큰을 일정한 속도로 충전(Refill)하고, 요청이 들어올 때마다 토큰을 소비하여 처리율을 제한하는 방식입니다.

반면 Leaky Bucket은 요청을 버킷에 저장한 뒤, 일정한 속도로 요청을 처리합니다. 버킷의 용량을 초과하는 요청이 들어오면 더 이상 저장할 수 없기 때문에 해당 요청은 거부됩니다.

갑작스럽게 많은 트래픽이 유입되면 버킷은 빠르게 가득 차게 됩니다. 버킷의 용량을 초과한 요청은 더 이상 저장할 수 없으므로 거부됩니다. 반면 일반적인 트래픽 환경에서는 요청이 일정한 속도로 버킷을 통과하며 정상적으로 처리됩니다.

개인적으로 Leaky Bucket은 바리게이트와 비슷한 방식이라고 생각합니다. 한 번에 많은 요청이 몰리더라도 모두를 처리하는 것이 아니라, 미리 정해진 속도로만 요청을 통과시킵니다. 이를 통해 갑작스러운 트래픽 증가에도 시스템이 일정한 처리율을 유지할 수 있도록 도와줍니다.

그렇다면 언제 Token Bucket을 선택하고, 언제 Leaky Bucket을 선택해야 할까요? 두 알고리즘 모두 요청을 제한한다는 공통점이 있지만, 트래픽을 처리하는 방식은 분명한 차이가 있습니다.

순간적으로 많은 요청을 허용하면서도 평균 처리율을 제한하고 싶다면 Token Bucket이 적합하고, 요청을 항상 일정한 속도로 처리하여 시스템의 안정성을 우선시한다면 Leaky Bucket이 적합하다고 생각합니다.

윈도우 기반 알고리즘

도우 기반 알고리즘을 이해하기 위해서는 먼저 윈도우(Window) 라는 개념을 이해할 필요가 있습니다. 지금까지 살펴본 버킷 기반 알고리즘과 달리, 윈도우 기반 알고리즘은 시간을 일정한 구간(Window)으로 나누어 요청을 관리합니다.

윈도우 기반 알고리즘은 시간 구간을 어떻게 관리하느냐에 따라 여러 방식으로 나뉩니다. 대표적으로 고정 윈도 카운터(Fixed Window Counter), 이동 윈도 로깅(Sliding Window Log), 이동 윈도 카운터(Sliding Window Counter) 의 세 가지 알고리즘이 있습니다.

고정 윈도 카운터

윈도우가 시간을 일정 구간으로 나눠서 요청을 관리한다고 하였습니다. 그렇다면 고정 윈도(Fixed Window) 는 이름 그대로 시간을 동일한 크기의 구간으로 나누어 요청을 관리하는 알고리즘입니다.

예를 들어 윈도우의 크기를 1분으로 설정했다면, 시간은 00:00 ~ 00:01, 00:01 ~ 00:02, 00:02 ~ 00:03과 같이 고정된 구간으로 나뉘게 됩니다. 그리고 각 구간마다 요청 수를 별도로 계산하여, 설정한 임계치를 초과하는 경우 더 이상 요청을 처리하지 않습니다.

하지만 실제 트래픽은 윈도우의 경계에 맞춰 발생하지 않습니다. 평소에는 요청이 적더라도 특정 시점에 많은 요청이 한꺼번에 몰릴 수 있으며, 이러한 특성 때문에 고정 윈도 카운터는 예상하지 못한 문제가 발생할 수 있습니다.

예를들어,

특정 시점에 트래픽이 몰리는 상황을 가정해보겠습니다. Rate Limiter의 정책은 1분 동안 최대 100개의 요청을 허용한다고 가정합니다.

먼저 00:00 ~ 01:00 구간의 마지막 20초인 00:40부터 80개의 요청이 발생했다고 해보겠습니다. 그리고 새로운 윈도우가 시작된 직후인 01:00 ~ 01:40 사이에 40개의 요청이 추가로 발생했다고 가정하겠습니다.

고정 윈도 카운터는 두 요청을 서로 다른 윈도우로 판단합니다.

00:00 ~ 01:00 → 80개
01:00 ~ 02:00 → 40개

따라서 두 윈도우 모두 임계치인 100개를 넘지 않았기 때문에 Rate Limiter는 정상이라고 판단합니다.

하지만 실제 시간을 기준으로 보면 00:40 ~ 01:40 사이에는 총 120개의 요청이 발생한 것입니다. 즉, 매우 짧은 시간 동안 임계치를 초과하는 트래픽이 유입되었음에도, 고정된 시간 구간으로 나누어 계산했기 때문에 이를 감지하지 못하는 문제가 발생합니다.

이처럼 윈도우의 경계(Boundary) 에서 발생하는 문제를 해결하기 위해 등장한 알고리즘이 이동 윈도 로깅(Sliding Window Log) 입니다.

이동 윈도 로깅

이동 윈도 로깅은 고정 윈도 카운터에서 발생하는 경계 문제(Boundary Problem) 를 해결하기 위해 등장한 알고리즘입니다.

이 알고리즘은 모든 요청의 발생 시각을 로그 형태로 기록합니다. 이후 새로운 요청이 들어올 때마다 현재 시점을 기준으로 최근 일정 시간(예: 최근 1분) 동안의 요청 개수를 계산하여 처리 여부를 결정합니다.

따라서 특정 시점에 트래픽이 집중되더라도 고정된 시간 구간에 영향을 받지 않으며, 실제 트래픽 흐름을 기준으로 Rate Limiting을 수행할 수 있다는 장점이 있습니다.

하지만 모든 요청의 로그를 저장해야 하기 때문에 메모리 사용량이 증가한다는 단점이 있습니다. 또한 새로운 요청이 들어올 때마다 현재 시점을 기준으로 오래된 로그를 제거하고, 남아 있는 요청 수를 계산해야 하므로 처리 비용이 증가할 수 있습니다.

즉, 이동 윈도 로깅은 정확도가 높은 대신, 많은 요청이 발생하는 환경에서는 메모리 사용량과 연산 비용이 커질 수 있다는 단점을 가지고 있습니다.

이러한 문제를 해결하기 위해 나온것이 이동 윈도 카운터입니다.

이동 윈도 카운터

이동 윈도 로깅의 가장 큰 단점은 모든 요청의 로그를 저장해야 한다는 점입니다. 요청이 많아질수록 메모리 사용량이 증가하고, 요청을 계산하는 비용도 함께 커질 수 있습니다.

이러한 문제를 개선하기 위해 등장한 것이 이동 윈도 카운터(Sliding Window Counter) 입니다. 이동 윈도 카운터는 모든 요청을 저장하지 않고, 이전 윈도우의 요청 수와 현재 윈도우의 요청 수만을 이용하여 현재 시점의 요청 수를 계산합니다.

즉, 모든 로그를 관리하는 대신 두 개의 윈도우 정보를 활용해 현재 요청량을 추정하는 방식입니다. 이로 인해 이동 윈도 로깅보다 메모리 사용량이 적고 연산 비용도 낮아지지만, 실제 요청 수를 계산하는 것이 아니라 추정하는 방식이므로 약간의 오차가 발생할 수 있습니다.

계산식은 다음과 같습니다.

예상 요청 수 = 이전 윈도우 요청 수 × (남은 시간 비율) + 현재 윈도우 요청 수

그렇다면 왜 이러한 계산식을 사용하는 것일까요?

그렇다면 어째서 이러한 계산식을 사용하는 것일까요? 이전 윈도우의 요청 수는 이미 집계가 완료된 값이지만, 현재 윈도우는 아직 진행 중이기 때문에 최종 요청 수를 알 수 없습니다.

따라서 현재 윈도우가 얼마나 진행되었는지를 시간의 비율로 계산하여, 이전 윈도우에서 현재 시점까지 영향을 미치는 요청 수를 추정합니다. 이후 여기에 현재 윈도우에서 발생한 요청 수를 더하면, 현재 시점을 기준으로 최근 1분 동안의 요청량을 근사치로 계산할 수 있습니다.

예를 들어, 이전 윈도우의 요청 수가 80개, 현재 윈도우의 요청 수가 30개라고 가정해보겠습니다. 또한 윈도우는 1분 단위로 갱신되며, 현재 시각은 새로운 윈도우가 시작된 지 20초가 지난 시점이라고 가정하겠습니다.

그렇다면 현재 시점을 기준으로 최근 1분인 00:20 ~ 01:20 구간에는 총 몇 개의 요청이 발생했을까요?

이동 윈도 카운터는 이 값을 직접 계산하지 않습니다. 대신 이전 윈도우의 요청이 시간 전체에 고르게 분포되어 있다고 가정하고 계산합니다.

현재 윈도우가 20초 진행되었다는 것은, 최근 1분에는 이전 윈도우의 마지막 40초만 포함된다는 의미입니다. 따라서 이전 윈도우의 요청 수 80개 중 2/3만 반영하여 다음과 같이 계산합니다.

80 × 2/3 ≒ 53

여기에 현재 윈도우에서 발생한 요청 수 30개를 더하면,

53 + 30 = 83

즉, 00:20 ~ 01:20 구간에서는 약 83개의 요청이 발생한 것으로 추정할 수 있습니다.

이렇게 하면 이동 윈도 로깅 방식에서 문제가 되었던 메모리 사용량을 크게 줄일 수 있습니다. 하지만 한편으로는 모든 요청을 저장하지 않고 추정값을 이용한다는 점에서, 정확도가 떨어지는 것은 아닐까 하는 의문이 생길 수 있습니다.

그렇다면 과연 이러한 근사 계산만으로도 트래픽을 안전하게 제어할 수 있을까요?

이러한 의문에 대한 대표적인 사례로 Cloudflare의 실험을 들 수 있습니다. Cloudflare는 이동 윈도 카운터(Sliding Window Counter) 와 이동 윈도 로깅(Sliding Window Log) 을 비교하기 위해 약 4억 건의 요청을 대상으로 실험을 진행했습니다.

그 결과, 오분류율(Misclassification Rate)은 0.003%에 불과했으며, 평균 추정 오차는 약 6% 수준으로 나타났습니다. 또한 임계치 이하의 요청이 잘못 차단된 사례는 없었고, 임계치를 초과했음에도 허용된 요청 역시 대부분 임계치 근처에서만 발생한 것으로 확인되었습니다.

즉, 이동 윈도 카운터는 모든 요청을 저장하지 않더라도, 실제 서비스에서는 이동 윈도 로깅과 매우 유사한 수준의 정확도를 제공하면서 메모리 사용량과 연산 비용을 효과적으로 줄일 수 있는 알고리즘이라는 것을 확인할 수 있습니다.

Rate Limiting Strategies: Token Bucket, Leaky Bucket, and Sliding Window — Sujeet Jaiswal - Principal Software Engineer

Five rate limiting algorithms compared — token bucket, leaky bucket, fixed window, sliding window log, and sliding window counter — with how AWS API Gateway, Stripe, Cloudflare, GitHub, and NGINX deploy them, plus distributed coordination patterns usin

sujeet.pro

하지만 그렇다고 해서 이동 윈도 카운터를 모든 상황에서 만능 해결책처럼 사용할 수 있는 것은 아닙니다. 이동 윈도 카운터는 이전 윈도우와 현재 윈도우를 기반으로 요청 수를 추정하는 방식이기 때문에, 실제 요청 수와는 약간의 오차가 발생할 수 있습니다.

일반적인 웹 서비스에서는 이러한 오차가 거의 문제가 되지 않을 수 있습니다. 하지만 대규모 이벤트나 티켓 예매처럼 짧은 시간 동안 트래픽이 폭발적으로 몰리는 환경에서는 작은 오차도 큰 차이를 만들어낼 수 있습니다. 따라서 서비스의 특성과 트래픽 패턴을 고려하여, 필요한 경우에는 이동 윈도 로깅과 같이 더 높은 정확도를 제공하는 알고리즘을 선택하는 것이 적절할 수 있습니다.

알고리즘	장점	단점	추천 사용 환경
고정 윈도 카운터	구현이 단순하고 메모리 사용량이 적다.	윈도우 경계에서 순간적으로 많은 요청을 허용하는 Boundary Problem이 발생할 수 있다.	내부 시스템, 간단한 Rate Limiter, 정확도가 크게 중요하지 않은 서비스
이동 윈도 로깅	최근 요청을 정확하게 계산하여 가장 높은 정확도를 제공한다.	모든 요청을 저장해야 하므로 메모리 사용량과 연산 비용이 크다.	로그인, 결제, 금융, 보안 정책 등 정확도가 중요한 서비스
이동 윈도 카운터	적은 메모리로 높은 정확도를 제공하며 성능과 정확도의 균형이 좋다.	근사치를 계산하므로 약간의 오차가 발생할 수 있다.	API Gateway, 일반 REST API, 대부분의 웹 서비스, 대규모 서비스

마무리

이번 글에서는 Rate Limiter의 대표적인 알고리즘에 대해 학습해보았습니다. 크게 버킷 기반 알고리즘과 윈도우 기반 알고리즘으로 구분할 수 있으며, 각각의 특징과 장단점을 살펴보았습니다.

개인적으로 버킷 기반 알고리즘은 순간적으로 몰리는 트래픽을 제어하는 1차 방어막이라는 느낌을 받았습니다. 또한 Token Bucket과 Leaky Bucket은 목적이 조금 다르기 때문에, 상황에 따라 함께 사용하더라도 크게 문제되지 않을 수 있다고 생각합니다.

반면 윈도우 기반 알고리즘은 일정 시간 동안의 요청을 기준으로 트래픽을 관리하는 방식입니다. 따라서 고정 윈도우 카운터, 이동 윈도 로깅, 이동 윈도 카운터는 각각의 특성을 고려하여 서비스 환경에 맞게 선택하는 것이 더 적합하다고 생각합니다.

결국, 어느 알고리즘이 절대적으로 우수하다고 말하기는 어렵습니다. 중요한 것은 서비스의 트래픽 특성과 요구사항을 이해하고, 그에 맞는 Rate Limiting 알고리즘을 선택하는 것이라고 생각합니다.

로그인은 어떤 방식으로 개발해야 안전할까?

klom — Sun, 14 Jun 2026 22:00:35 +0900

로그인을 처리하는 방식에는 크게 세션 방식과 토큰 방식이 있습니다. 토큰 방식을 사용하는 대표적인 이유는 stateless하기 때문입니다. 여기서 stateless하다는 것은 서버가 로그인 상태를 직접 저장하지 않아도 된다는 뜻입니다. 즉, 사용자가 로그인한 뒤 요청을 보낼 때마다 토큰을 함께 전달하고, 서버는 그 토큰이 유효한지만 검증하면 됩니다. 토큰 방식의 장점은 트래픽이 많아졌을 때 조금 더 잘 드러납니다. 세션 방식은 로그인 상태를 서버나 세션 저장소에 보관해야 하기 때문에, 요청이 많아질수록 세션 조회 비용이 계속 발생합니다. 반면, 토큰 방식은 서버가 별도의 로그인 상태를 저장하지 않아도 되기 때문에, 많은 요청이 동시에 들어와도 상대적으로 서버 부담이 적을 수 있습니다. 물론 실제 서비스에서는 중복 로그인 확인, 로그아웃 처리, refresh token 관리 등을 위해 데이터베이스나 Redis 같은 저장소를 함께 사용하는 경우도 많습니다. 하지만 여기서는 그런 예외 상황은 제외하고, 순수하게 세션 방식과 토큰 방식 중 트래픽이 많을 때 어떤 차이가 발생하는지를 비교해보겠습니다.

간단하게 세션과 토큰 방식에 대해 이해 해봅시다.

세션 방식

세션 방식은 사용자가 로그인에 성공하면 서버가 세션을 생성하고 저장하는 방식입니다. 이후 서버는 사용자를 식별할 수 있는 고유한 세션 ID를 발급하며, 클라이언트는 이 값을 쿠키에 저장하게 됩니다. 사용자가 요청을 보낼 때마다 쿠키에 저장된 세션 ID가 함께 전달되고, 서버는 해당 세션 ID를 이용해 저장된 세션 정보를 조회한 뒤 인증 여부를 확인합니다.

즉, 실제 로그인 정보는 서버가 관리하고 있으며, 클라이언트는 단순히 세션을 식별하기 위한 키(Session ID)만 가지고 있는 구조입니다.
간단히 표현하면 다음과 같습니다.

세션 방식의 특징은 서버가 사용자의 로그인 상태를 직접 관리하기 때문에 강제 로그아웃이나 중복 로그인 제어가 비교적 쉽다는 점입니다. 반면 사용자가 많아질수록 서버 또는 세션 저장소가 관리해야 하는 데이터도 함께 증가하게 됩니다.

토큰 방식

토큰 방식은 사용자가 로그인에 성공하면 서버가 토큰을 발급하고, 이후 사용자는 요청마다 해당 토큰을 함께 전달하는 방식입니다.
서버는 별도의 로그인 상태를 저장하지 않고 토큰의 유효성만 검증하기 때문에 Stateless한 구조를 만들 수 있습니다.

즉, 세션 방식은 서버가 로그인 상태를 관리하고, 토큰 방식은 사용자가 인증 정보를 직접 가지고 다니는 방식이라고 이해하면 됩니다. 토큰 방식은 서버에 로그인 상태를 저장하지 않기 때문에 서버를 여러 대로 확장하기 쉽다는 특징이 있습니다.

그럼 어떻게 테스트를 할까?

세션 방식과 토큰 방식의 공통점은 모두 인증을 위해 사용되는 기술이라는 점입니다. 따라서 회원가입과 로그인을 제공하는 대부분의 서비스에서 사용됩니다.

하지만 모든 기술이 하나의 목적에만 사용되는 것은 아닙니다.

예를 들어 세션 방식은 반드시 로그인에만 사용되는 것이 아닙니다. 대표적으로 장바구니 기능이 있습니다. 사용자가 로그인하지 않았더라도 세션을 이용해 장바구니 정보를 저장할 수 있습니다. 이 경우 세션은 인증이 아닌 사용자의 상태를 유지하기 위한 용도로 활용됩니다.

토큰 방식 역시 로그인에만 사용되는 것은 아닙니다. 외부 API를 호출할 때 사용하는 API Key나 Access Token도 넓은 의미에서는 토큰 기반 인증 방식에 해당합니다. 사용자가 아닌 시스템 간 통신에서도 토큰은 자주 활용됩니다.

즉, 세션과 토큰은 주로 인증에 사용되지만, 본질적으로는 사용자를 식별하거나 특정 권한을 증명하기 위한 수단이라고 볼 수 있습니다. 따라서 로그인뿐만 아니라 상태 유지, 시스템 간 인증, API 접근 제어 등 다양한 영역에서 활용될 수 있습니다.

하지만 저는 이 모든것을 구현하지 않을겁니다.

계획은 단순합니다. 사용자가 API를 호출하면 세션 또는 토큰을 통해 인증을 수행하고, 인증에 성공한 경우 "hello" 문자열을 반환하도록 구현할 예정입니다.

이를 통해 동일한 기능을 세션 방식과 토큰 방식으로 각각 구현한 뒤, 트래픽이 증가했을 때 어떤 차이가 발생하는지 비교해보겠습니다.

예상대로라면 토큰 방식이 더 빠를 것이라 생각했습니다. 서버가 상태를 저장하지 않는 Stateless 구조이기 때문에, 세션 조회 비용이 존재하는 세션 방식보다 유리할 것이라고 예상했기 때문입니다. 하지만 실제 결과를 확인해보니 오히려 세션 방식이 더 빠르게 측정되었습니다. 특히 30K 트래픽 구간에서는 세션 방식이 토큰 방식보다 약 2배 이상 빠른 결과를 보여주었습니다.

그렇다면 왜 이런 결과가 발생한 것일까요?

그 이유는 인증 과정에서 수행되는 작업의 차이에 있습니다. 세션 방식은 클라이언트가 전달한 Session ID를 기반으로 서버에 저장된 세션 정보를 조회하면 인증이 완료됩니다. 반면 토큰 방식은 요청이 들어올 때마다 토큰의 서명을 검증하고, 만료 시간을 확인하며, 토큰의 무결성을 검증하는 과정을 수행해야 합니다.

특히 JWT를 사용한다면 Base64 디코딩, Signature 검증(HMAC, RSA, ECDSA 등), Claims 파싱 과정이 매 요청마다 발생하게 됩니다. 이 과정은 서버 메모리 조회보다 CPU 사용량이 더 높은 작업에 해당합니다.

즉, 흔히 토큰 방식이 더 빠를 것이라고 생각하기 쉽지만, 실제로는 세션 조회 비용보다 토큰 검증 비용이 더 클 수 있습니다. 따라서 단순히 인증 처리 성능만 비교한다면 세션 방식이 더 빠르게 측정되는 경우도 충분히 발생할 수 있습니다.

결국 토큰 방식의 장점은 인증 속도 자체가 아니라 Stateless 구조를 통한 확장성에 있습니다. 서버가 로그인 상태를 저장하지 않아도 되기 때문에 여러 대의 서버를 운영하거나 MSA 환경으로 확장할 때 관리가 쉬워지는 것이지, 반드시 요청 처리 속도가 더 빠르다는 의미는 아닙니다.

여기서 알수 있는 사실은 단순히 속도가 빨라서 토큰을 사용하는게 아니라는 뜻입니다.

그렇다면, 실행 환경이 늘어나면 어떻게 될까요?
토큰 방식의 장점은 stateless하다는 점입니다. 그렇다면, 이 점을 가장 극대화를 시키려면 어떻게 해야 할까요?

만약 실행 환경(Pod 또는 WAS)이 여러 개라고 가정해봅시다. 세션 방식은 기본적으로 서버가 로그인 상태를 저장합니다. 따라서 각 서버가 자신만의 세션 저장소를 가지고 있다면 문제가 발생할 수 있습니다. 예를 들어, 사용자가 실행 환경 1에서 로그인하여 세션이 생성되었다고 가정해보겠습니다. 이후 다음 요청이 로드밸런서에 의해 실행 환경 2로 전달된다면, 실행 환경 2는 해당 세션 정보를 가지고 있지 않기 때문에 사용자를 인증할 수 없습니다.

즉, 사용자는 이미 로그인했음에도 불구하고 다시 로그인을 요구받을 수 있습니다.

이러한 문제를 해결하기 위해 Sticky Session을 사용하거나, Redis와 같은 외부 세션 저장소를 두어 모든 실행 환경이 동일한 세션 정보를 조회할 수 있도록 구성합니다.

반면, 토큰 방식은 서버가 로그인 상태를 저장하지 않습니다. 사용자가 토큰만 가지고 있다면 어떤 실행 환경으로 요청이 전달되더라도 동일한 방식으로 인증을 수행할 수 있습니다. 이러한 특징 때문에 분산 환경에서는 토큰 방식이 확장성 측면에서 유리하다고 평가받습니다.

하지만 현재 테스트 방식은 실제 로그인 방식과는 다릅니다. 사용자가 로그인하고 인증 정보를 발급받는 구조가 아니라, 단순히 API를 요청하면 인증 과정을 거친 뒤 "hello" 문자열을 반환하는 단순한 코드입니다. 따라서 세션 방식과 토큰 방식을 더 정확하게 비교하려면, 실제 로그인 과정까지 포함하도록 코드를 변경할 필요가 있다고 생각합니다. 그렇다고 해서 위 테스트가 의미 없다는 뜻은 아닙니다. 단일 실행 환경에서는 세션 방식과 토큰 방식 모두 큰 구조적 차이 없이 동작하기 때문에, 결과적으로는 지연 시간 차이만 발생하고 전체적인 흐름은 비슷하게 나올 것이라고 예상할 수 있습니다.

로그인 방식으로 변경해봅시다.

실행 환경을 3개로 늘려서 테스트를 진행해보겠습니다. 그렇다고 해서

이렇게 테스트하면 곤란해집니다. 왜냐하면 실행 환경이 여러 개인 것처럼 보이더라도, 실제로는 실행 환경이 한 개인 것과 큰 차이가 없기 때문입니다.

그래서 저는 중간에 Nginx를 두고 테스트를 진행할 예정입니다. 이렇게 하면 사용자는 하나의 주소로만 접근하지만, Nginx가 요청을 여러 서버로 분산시켜 실제 운영 환경과 유사한 구조를 만들 수 있습니다.

이제 똑같이 부하를 주면서 재 테스트를 진행해보겠습니다. 어떤 결과가 나올까요?

지연시간을 확인해보니 생각보다 흥미로운 결과가 나왔습니다. 1,000건까지는 토큰 방식의 지연시간이 세션 방식보다 조금 더 높게 나타났습니다. 하지만 5,000건부터 10,000건 구간에서는 오히려 토큰 방식의 지연시간이 더 낮게 측정되었습니다.

그런데 트래픽이 20,000건을 넘어가자 다시 토큰 방식의 지연시간이 증가하면서 세션 방식보다 느린 결과가 나타났습니다.

일반적으로 토큰 방식은 매 요청마다 토큰을 검증해야 하므로 세션 방식보다 불리할 것이라고 예상했습니다. 하지만 실제 결과는 단순하지 않았습니다. 특정 구간에서는 토큰 방식이 더 좋은 성능을 보여주었고, 트래픽이 더욱 증가하자 다시 역전되는 모습을 확인할 수 있었습니다.
이는 단순히 "세션이 빠르다", "토큰이 빠르다"로 결론 내릴 수 있는 문제가 아니라, 트래픽 규모와 실행 환경에 따라 결과가 달라질 수 있다는 점을 보여주는 사례라고 생각합니다.

그렇다면, 인증 성공률은 어떨까요?

100 - 인증 성공률 = 커넥션 에러

인증 성공률을 확인해보니 더욱 흥미로운 결과가 나왔습니다. 트래픽이 10건에 불과한 상황에서도 세션 방식의 인증 성공률은 16.8%로 매우 낮게 측정되었습니다. 반면 토큰 방식은 85%가 넘는 인증 성공률을 보여주었습니다.

이러한 차이가 발생한 이유는 인증 방식 자체의 문제가 아니라 분산 환경에서의 동작 방식 차이 때문입니다.

세션 방식은 로그인 정보가 각 서버 내부에 저장됩니다. 따라서 사용자가 서버 A에서 로그인하더라도 이후 요청이 서버 B로 전달되면 서버 B는 해당 세션 정보를 알 수 없어 인증에 실패하게 됩니다.

반면 토큰 방식은 서버가 로그인 상태를 저장하지 않습니다. 사용자가 토큰만 가지고 있다면 어떤 서버로 요청이 전달되더라도 동일한 방식으로 인증을 수행할 수 있습니다. 따라서 여러 서버로 요청이 분산되는 환경에서도 비교적 안정적인 인증 성공률을 보여줄 수 있습니다.

결국 현재 테스트 환경에서 세션 방식의 인증 성공률을 높이기 위해서는 Sticky Session을 적용하거나, Redis와 같은 외부 세션 저장소를 구축하여 모든 서버가 동일한 세션 정보를 조회할 수 있도록 구성해야 할 것으로 보입니다.

참고로 단일 환경에서의 인증 성공률은 다음과 같습니다.

단일 환경에서는 세션이나 토큰이나 결과가 크게 다르지 않다는 것을 알 수 있었습니다.
다시 3파드로 넘어와서 위에서 100 - 인증 성공률은 커넥션 실패라고 하였습니다. 과연 그럴까요?

하지만 결과를 보니 토큰은 항상 100%를 기록하는거에 비해 세션 파트는 100%가 된적이 단 한번도 존재하지 않았습니다. 이런 현상이 발생한 이유가 무엇 일까요?

그 이유는 위에서 계속 언급했듯이 세션 정보의 저장 위치 때문입니다. 토큰 방식은 사용자가 직접 토큰을 가지고 요청하기 때문에 어떤 서버로 요청이 전달되더라도 동일한 방식으로 인증을 수행할 수 있습니다.

마무리

처음에는 토큰 방식이 Stateless 구조이기 때문에 세션 방식보다 처리 속도가 빠를 것이라고 생각했습니다. 하지만 실제 테스트 결과를 확인해보니 단일 환경에서는 오히려 세션 방식이 토큰 방식보다 더 빠르게 동작한다는 사실을 확인할 수 있었습니다.

그렇다면 실행 환경(Pod)이 여러 개로 늘어나면 어떤 현상이 발생할까요?

지연시간 측면에서는 단일 환경과 비교했을 때 눈에 띄는 차이를 발견하지 못했습니다. 하지만 인증 성공률을 기준으로 비교해보니 토큰 방식이 압도적으로 높은 결과를 보여주었습니다.

특히 세션 방식은 인증 성공률과 HTTP 연결 실패율을 합쳐도 100%가 되지 않는 현상을 발견하였습니다. 처음에는 원인을 이해하지 못했지만, 확인해보니 현재 테스트 환경의 세션 방식은 세션 정보를 서버 간에 공유하지 않고 있었습니다. 즉, 사용자가 로그인한 서버와 요청을 처리하는 서버가 달라질 경우 인증에 실패할 수 있었고, 이러한 구조 때문에 예상치 못한 결과가 발생한 것이었습니다.

저는 세션 방식이 구현해야 할 코드가 적기 때문에 토큰 방식보다 단순하다고 생각했습니다. 하지만 실행 환경이 여러 개로 늘어나는 순간 이야기가 달라졌습니다. 세션을 사용하기 위해서는 Sticky Session을 적용하거나 Redis와 같은 공통 세션 저장소를 구축해야 하며, 이 과정에서 추가적인 운영 및 관리 비용이 발생합니다.

반면 토큰 방식은 별도의 세션 공유 구조 없이도 여러 실행 환경에서 동일하게 인증을 수행할 수 있었습니다. 물론, 토큰 검증 과정에서 추가적인 연산 비용이 발생하지만, 분산 환경에서는 이러한 특징이 큰 장점으로 작용할 수 있다는 점을 확인할 수 있었습니다.

이번 학습을 통해 인증 방식은 단순히 처리 속도만으로 판단할 수 있는 문제가 아니라는 것을 깨달았습니다. 실제 서비스에서는 성능뿐만 아니라 확장성, 운영 편의성, 인증 성공률까지 함께 고려해야 합니다.

또한 토큰 방식에서 중복 로그인 관리, 로그아웃 처리, Refresh Token 관리 등을 위해 Redis나 데이터베이스를 사용하는 것이 Stateless라는 개념과 상충되는 것이 아니라는 점도 배울 수 있었습니다. 중요한 것은 데이터를 저장하느냐가 아니라, 인증 자체를 서버 세션 상태에 의존하지 않는다는 점이라는 사실을 이번 실습을 통해 확인할 수 있었습니다.

한국어 형태소 분석 vs BPE

klom — Mon, 8 Jun 2026 18:30:38 +0900

한국어를 뉴럴 네트워크로 학습시킬 때는 몇 가지 어려움이 존재합니다. 대표적인 예가 조사입니다. 한국어에는 ‘가’, ‘는’, ‘이’와 같은 조사가 존재하며, 이들은 명사와 결합하면서 문장에서의 역할이나 의미를 바꿀 수 있습니다. 예를 들어 같은 명사라도 어떤 조사가 붙느냐에 따라 주어가 되기도 하고, 목적어나 비교 대상처럼 해석될 수도 있습니다. 따라서 단순히 공백 기준으로 문장을 나누면 단어의 의미나 문법적 역할을 정확하게 파악하기 어렵습니다. 이러한 문제를 해결하기 위해 형태소 분석을 사용할 수 있습니다. 형태소 분석을 통해 명사와 조사를 분리하면, 모델이 단어 자체의 의미와 문장 내 역할을 더 명확하게 학습할 수 있습니다.

하지만, ChatGPT와 같은 현대적인 LLM은 형태소 분석을 사용하지 않습니다. 대신, BPE(Byte Pair Encoding) 기반의 토크나이징 방식을 사용합니다. 한국어에는 조사와 어미가 존재하기 때문에 과거에는 형태소 분석이 중요하게 여겨졌습니다. 그렇다면 현대의 LLM은 왜 형태소 분석 없이도 한국어를 이해할 수 있는 것일까요?

형태소 분석은 왜 해야 하는가?

일단 한국어 문장을 신경에 넣으려면 잘게 쪼개야 합니다. 그럼 어떻게 쪼갤 수 있을까요?
방법은 크게 3가지입니다.

글자 단위로 쪼개는 방법, 공백 단위로 쪼개는 방법, 형태소 단위로 쪼개는 방법이 있습니다.
다음과 같은 문장이 있다고 가정해봅시다.

오늘 날씨가 화창합니다.

먼저 글자 단위로 쪼개는 방법에 대해 알아봅시다.

위 문장을 글자 단위로 쪼개면 다음과 같습니다.

오,늘,날,씨,가,화,창,합,니,다,

즉, 글자 하나 하나가 토큰이라고 할 수 있습니다. 이것을 뉴럴 네트워크에 접목을 시켜보겠습니다.

'오'라는 토큰만으로는 다음 글자를 예측하기 어렵습니다. 실제로 '오'로 시작하는 단어는 111개나 존재하기 때문에 어떤 글자가 뒤에 올지 판단할 수 없습니다. 또한 '오'만 보고는 사용자가 어떤 단어를 의도했는지 추론하는 것도 사실상 불가능합니다. 즉, 정보가 너무 부족하여 정확한 예측이 어려워지는 문제가 발생합니다.

그 다음은 공백 단위로 쪼개는 방법입니다.

위 방법이 글자 단위로 문장을 분리했다면, 이번에는 공백 단위로 분리하는 방법입니다. 여담으로 현대 LLM에서 사용하는 BPE도 이러한 아이디어에서 출발하여 발전한 방식입니다. (BPE에 대해서는 추후 자세히 설명하겠습니다.)

오늘, 날씨가, 화창합니다

얼핏 보기에는 큰 문제가 없어 보입니다. 하지만 토큰으로 분리된 단어를 살펴보면 문제가 발생합니다.
'오늘', '화창합니다'는 큰 문제가 없지만, '날씨가'라는 단어는 다릅니다.

실제로 우리가 생각하는 단어는 '날씨'이지만, 신경망은 '날씨가', '날씨는', '날씨도'를 모두 서로 다른 단어로 인식합니다. 즉, 하나의 명사에 조사와 어미가 결합하면서 수많은 변형이 생성되고, 이러한 변형들이 모두 별개의 어휘로 취급됩니다.

결과적으로 어휘 수가 급격하게 증가하게 되며, 이를 어휘 폭발(Vocabulary Explosion) 문제라고 합니다.

이를 해결 하기 위해 형태소 단위로 쪼개게 되었습니다.

형태소 단위로 쪼개면 어떤 장점이 있을까요?

오늘,날씨,가,화창,하,ㅂ니다

이렇게 분리하면 장점이 '날씨가'와 '날씨는' '날씨를' 등등 의미를 해치지 않고 토큰으로 구별할 수 있는 장점을 가지고 있습니다.

이렇게 분리하면 '날씨가', '날씨는', '날씨를'과 같은 단어들을 각각 별개의 단어로 학습할 필요가 없습니다. 공통된 의미를 가진 '날씨'는 그대로 유지하고, 조사만 별도로 구분하여 학습할 수 있기 때문입니다.

즉, 의미를 훼손하지 않으면서도 어휘 수를 줄일 수 있으며, 다양한 단어 변형에 보다 효율적으로 대응할 수 있다는 장점이 있습니다.

그렇다면, 어째서 현대 LLM은 형태소 분석을 하지 않을까요?

가장 큰 이유는 언어마다 가진 특성이 너무 다르기 때문입니다. 영어는 공백 단위로 분리해도 큰 문제가 없지만, 한국어는 조사와 어미 때문에 형태소 분석이 필요합니다.

하지만 이것은 한국어만의 문제가 아닙니다. 중국어나 태국어와 같은 언어는 한국어보다 상황이 더 복잡합니다. 이들 언어는 띄어쓰기가 없거나 형태소 경계가 명확하지 않아 형태소 분석 자체가 매우 어렵습니다. 경우에 따라서는 언어학자들 사이에서도 분리 기준이 달라질 수 있습니다.

예를 들어 다음과 같은 중국어 문장이 있다고 해봅시다.

我喜欢学习人工智能

(나는 인공지능 공부를 좋아한다.)

중국어는 띄어쓰기가 없기 때문에 다음과 같이 먼저 분절해야 합니다.

我 / 喜欢 / 学习 / 人工智能

태국어도 비슷합니다.

ฉันชอบเรียนปัญญาประดิษฐ์ -> ฉัน / ชอบ / เรียน / ปัญญาประดิษฐ์

(나는 인공지능 배우는 것을 좋아한다.)

즉, BPE가 없던 시절에는 언어마다 전용 전처리기를 만드는 방식이 일반적이었습니다.

문제는 이런 방식이 언어마다 구현해야 해서 유지보수 비용이 컸습니다.
또한 다국어 모델을 만들기가 어려웠으며 신조어 오타 새로운 단어 대응에 약하다는 단점이 있었습니다.

그래서 현대 LLM은 "언어학자가 규칙을 만들어주는 방식" 대신 "문자열 패턴을 모델이 스스로 학습하는 방식"을 선택했고, 그 결과가 BPE, WordPiece, SentencePiece 같은 서브워드 토크나이저입니다. 그래서 LLM 이전 시대의 NLP는 언어학(Language-driven) 에 가까웠고, 현대 LLM은 데이터 중심(Data-driven) 에 가깝다고 볼 수 있습니다.

그렇다면 BPE는 이러한 문제를 어떻게 해결할 수 있을까요?

13-01 바이트 페어 인코딩(Byte Pair Encoding, BPE)

기계에게 아무리 많은 단어를 학습시켜도 세상의 모든 단어를 알려줄 수는 없는 노릇입니다. 만약 기계가 모르는 단어가 등장하면 그 단어를 단어 집합에 없는 단어란 의미에서 해당 토…

wikidocs.net

형태소 분석은 한국어의 조사와 어미를 효과적으로 분리할 수 있지만, 언어마다 다른 분석기가 필요하다는 한계가 있습니다. 또한 신조어나 외래어, 잘 알려지지 않은 언어를 처리하는 데도 어려움이 존재합니다.

이러한 문제를 해결하기 위해 현대의 LLM은 BPE(Byte Pair Encoding)라는 방식을 사용합니다.

BPE의 핵심 아이디어는 매우 단순합니다.
"문법은 모르겠고, 자주 같이 등장하는 문자열은 하나로 합치자."
즉, 사전이나 문법 규칙을 사용하지 않고 오직 통계만을 이용하여 토큰을 생성합니다.

BPE의 동작 원리

BPE는 다음과 같은 과정을 반복합니다.

모든 단어를 글자 단위로 분리한다.
데이터에서 가장 자주 등장하는 글자 쌍을 찾는다.
해당 글자 쌍을 하나의 토큰으로 합친다.
원하는 어휘 크기가 될 때까지 반복한다.

예를 들어 다음과 같은 데이터가 있다고 가정해보겠습니다.

강아지가
강아지를
강아지는

초기 상태에서는 모두 글자 단위로 분리됩니다.

강 아 지 가
강 아 지 를
강 아 지 는

이후 가장 자주 등장하는 문자열 쌍을 반복적으로 병합합니다.

강아지 + 가
강아지 + 를
강아지 + 는

이 과정을 반복하면 다음과 같은 결과를 얻을 수 있습니다.

강아지가 → [강아지, 가]
강아지를 → [강아지, 를]
강아지는 → [강아지, 는]

흥미로운 점은 형태소 분석기를 사용하지 않았음에도 형태소 분석과 유사한 결과를 얻을 수 있다는 것입니다.

다만, BPE는 자주 등장하는 문자열을 기준으로 토큰을 생성하기 때문에 항상 의미 있는 패턴을 찾는다고 보장할 수는 없습니다.

하지만 이러한 문제는 GPT와 같은 대규모 LLM 환경에서는 크게 발생하지 않습니다. 방대한 데이터가 존재하기 때문에 재사용 가능한 단어와 패턴을 자연스럽게 학습할 수 있기 때문입니다.

반대로 데이터셋이 매우 작은 경우에는 문제가 될 수 있습니다.

예를 들어 학습 데이터에 "아버지가방에들어가신다" 라는 문장만 반복적으로 존재한다고 가정해보겠습니다. 이 경우 BPE는 해당 문자열을 매우 자주 등장하는 패턴으로 인식하여, 결국 문장 전체를 하나의 토큰으로 학습할 수 있습니다.

이렇게 되면 '아버지', '방', '들어가신다' 와 같은 재사용 가능한 패턴을 학습하지 못하게 되고, 새로운 문장에 대한 일반화 성능이 떨어질 수 있습니다. 즉, BPE는 충분히 크고 다양한 데이터셋이 주어질 때 가장 효과적으로 동작합니다.

이제 본견적으로 BPE로 학습을 진행해보겠습니다.

위키를 데이터를 통해 학습을 진행시켜보겠습니다.
테스트 결과 학습은 약 38.2초 만에 완료되었습니다. 이전에 수행했던 형태소 분석 방식이 약 36분이 소요되었던 것과 비교하면 약 56배 빠른 결과입니다.

그렇다면 어떻게 이러한 속도를 보여줄 수 있을까요?

이유는 단순합니다. BPE는 형태소 분석처럼 품사나 조사, 어미를 판별하지 않습니다. 단순히 데이터에서 자주 등장하는 문자열 패턴을 찾아 병합하는 과정을 반복할 뿐입니다.

즉, 언어학적 규칙을 해석하는 과정이 없기 때문에 형태소 분석보다 훨씬 빠르게 학습을 수행할 수 있습니다.
다만, 그렇다고 해서 BPE가 형태소 분석보다 우수하지는 않습니다.

제가 구현한 BPE는 한국어 데이터만을 학습한 상태이기 때문에, 영어 문장을 입력할 경우 토큰 수가 더 많이 증가하는 경향을 보였습니다. 이는 영어 단어가 충분히 병합되지 않아 작은 단위로 분리되기 때문입니다.

물론 GPT와 같은 상용 LLM은 영어를 포함한 다양한 언어를 함께 학습하기 때문에 이러한 문제가 크게 발생하지 않습니다. 따라서 해당 결과는 한국어 데이터만으로 학습한 BPE의 한계로 보는 것이 적절합니다.

영어뿐만 아니라 일부 문장에서는 형태소 분석 방식이 BPE보다 더 적은 토큰을 사용하는 경우도 확인할 수 있었습니다.

사실 이러한 결과는 어떤 데이터를 학습했는지에 따라 크게 달라질 수 있습니다. 특정 단어나 표현이 학습 데이터에 자주 등장했다면 BPE가 더 효율적일 수 있고, 반대로 그렇지 않다면 형태소 분석 방식이 더 적은 토큰을 사용할 수도 있습니다.

즉, 토큰 수는 단순히 알고리즘의 우열보다는 학습 데이터의 특성과 분포에 더 큰 영향을 받는다고 볼 수 있습니다.

그렇다면 학습을 계속 시킨다면 어떤 효과가 나타날까요?

실험 결과를 종합해보면, 어휘 크기 16K~32K 구간이 가장 균형 잡힌 선택으로 보였습니다.

이 구간에서는 토큰 효율이 충분히 높았으며(문장당 약 24~28개), 학습 시간도 약 40초 내외로 빠르게 유지되었습니다. 또한 어휘 수가 지나치게 크지 않아 모델 크기와 메모리 사용량 측면에서도 부담이 적었습니다.

반면 64K 이상의 어휘를 사용할 경우 토큰 효율은 일부 개선되지만, 그에 비해 메모리 사용량과 학습 비용이 증가하는 경향을 보였습니다. 한국어만을 대상으로 하는 모델이라면 64K 이상의 어휘는 다소 과한 선택일 수 있습니다.

참고로 GPT-2는 약 50K 규모의 어휘를 사용하였으며, GPT-4와 같은 최신 다국어 모델은 100K 이상의 어휘를 사용합니다. 반면, 이번 실험에서 구축한 형태소 기반 어휘는 약 16K 규모로, 한국어를 처리하는 데에는 충분히 실용적인 수준이라고 판단됩니다.

마무리

저번 글에서는 형태소 분석을 이용하여 뉴럴 네트워크를 학습시켜보았습니다. 그리고 이번에는 형태소 분석 대신 BPE를 적용하여 동일한 실험을 진행해보았습니다.

가장 인상적이었던 부분은 학습 속도였습니다. 형태소 분석 방식은 30분 이상이 소요되었던 반면, BPE는 약 30초 만에 학습을 완료할 수 있었습니다. 물론 토큰 구성 방식과 특성에는 차이가 존재하지만, 언어학적 규칙을 고려하지 않고 순수 통계 기반으로 동작한다는 점에서 상당한 속도상의 이점을 확인할 수 있었습니다.

또한 BPE가 단순히 토큰을 분리하는 기술이 아니라, 현대 LLM이 다양한 언어와 신조어를 처리할 수 있도록 만들어주는 핵심 기술 중 하나라는 점도 확인할 수 있었습니다.

다음 글에서는 임베딩 연산에 대해 살펴보겠습니다. 흔히 임베딩은 단순히 단어를 숫자로 변환한 벡터라고 생각하기 쉽습니다. 하지만 실제로는 벡터 간 덧셈과 뺄셈을 통해 의미적인 관계를 표현할 수 있습니다. 다음 글에서는 형태소 분석과 BPE로 생성된 토큰을 바탕으로, 임베딩이 어떻게 의미를 학습하고 연산하는지 알아보겠습니다.

다량의 엑셀 정보는 어떻게 저장할 수 있을까?

klom — Sat, 6 Jun 2026 16:03:30 +0900

현재 SI 프로젝트를 진행하고 있습니다. 프로젝트의 상세한 내용은 보안상 말씀드릴 수 없지만, 업무를 진행하면서 확인하고 싶은 기술적인 내용을 정리해보려고 합니다. 이번에 다루려는 주제는 프론트 화면에서 엑셀 파일을 업로드하면, 해당 데이터를 서버에서 읽어 DB에 저장하는 흐름입니다. 단순히 엑셀을 업로드하고 저장하는 기능처럼 보일 수 있지만, 실제로는 파일 파싱 방식, 데이터 검증, 대량 데이터 처리, 트랜잭션 범위, 실패 처리 방식 등 여러 가지 선택지가 존재합니다. 따라서 이번 글에서는 특정 실무 코드를 공개하기보다는, 예제 코드를 바탕으로 어떤 기술을 선택할 수 있는지, 그리고 그 선택에 어떤 트레이드오프가 있는지를 정리해보려고 합니다. 여기에 등장하는 코드는 실제 프로젝트 코드가 아니며, 개념 설명을 위해 별도로 작성한 예제 코드입니다.

일단, 100만건의 데이터를 엑셀업로드를 진행해봅시다.

* 실무에서 정했던 엑셀 데이터 수보다 더 많이 진행할 예정입니다.

엑셀에는 100만건 이상의 데이터가 존재합니다. 이것을 바로 파일 업로드를 시켜 바로 DB에 넣다보면 서버에서 OOM이 발생할 수 있습니다.

테스트 결과 생각보다 100만건의 데이터는 업로드에 성공하였습니다.

4건은 원래 있던 데이터입니다.

하지만, 업로드가 완료가 될때까지 약 25분 정도 흘렀습니다. 또한, 동기 방식으로 데이터를 전송하기 때문에, 모든 데이터가 업로드가 종료가 되어야 DB에 반영이 되는 문제도 있었습니다.
이러한 문제를 해결하기 위해서는 어떻게 해야 할까요?

전송되는 데이터를 쪼개서 처리하면 됩니다. 이를 청크 단위 처리라고 볼 수 있습니다.
예를 들어 100만 건의 데이터를 하나의 큰 그룹으로 보고 한 번에 전송하면, 업로드 요청 한 번에 100만 건이 모두 실리게 됩니다. 하지만 이 데이터를 10개 또는 100개의 그룹으로 나누면, 한 번에 전송되는 데이터 수는 각각 10만 건, 1만 건 수준으로 줄어들게 됩니다.

그렇다면 데이터를 쪼개는 작업은 어느 위치에서 수행할 수 있을까요?

데이터를 쪼개는 위치는 크게 세 가지로 볼 수 있습니다.
첫 번째는 프론트 화면에서 엑셀 데이터를 읽고, 일정 단위로 나누어 서버에 전송하는 방식입니다.
두 번째는 프론트에서는 엑셀을 단순한 파일로만 업로드하고, 서버에서 파일을 읽으면서 데이터를 나누어 처리하는 방식입니다.
마지막은 현재 구조와 동일하게 프론트에서 서버로 데이터를 전달한 뒤, DB 적재 단계에서 프로시저를 활용하여 데이터를 나누어 처리하는 방식입니다.

이제 각각의 방식이 어떤 장단점을 가지는지, 그리고 현재 상황에서는 어떤 방식이 가장 적합한지 정리해보겠습니다.

프론트에서 데이터를 쪼개보자.

프론트에서 데이터를 쪼개기 위한 전제조건은 브라우저에서 엑셀 파일을 직접 읽어야 한다는 것입니다.
즉, 프론트는 엑셀 파일을 단순히 서버로 전송하는 것이 아니라, 파일 내부의 행 데이터를 파싱한 뒤 일정 단위로 나누어 서버에 전송해야 합니다.

프론트에서 데이터를 쪼개는 방식은 크게 두 가지로 볼 수 있습니다.

행 단위로 분할 하는 방법

먼저 SheetJs같은 클라이언트 파서를 준비해줍니다.

예를 들어 엑셀에 100만 건의 데이터가 있다면, 이를 1만 건씩 나누어 서버에 100번 요청하는 방식입니다.

100만 건 엑셀
→ 프론트에서 엑셀 파싱
→ 1만 건씩 분할
→ API 100번 호출
→ 서버 저장

이 방식의 장점은 한 번에 서버로 전송되는 데이터 양을 줄일 수 있다는 점입니다.
네트워크가 불안정하더라도 전체 100만 건이 한 번에 실패하는 것이 아니라, 일부 청크만 실패할 수 있습니다.

위에서 프론트에서 Excel을 읽을 수 있어야 한다고 했기 때문에 SheetJs 같은 클라이언트 파서가 필요합니다.
실행해보겠습니다.

또한 업로드 진행 상황을 확인할 수 있다는 장점도 있습니다.
그 이유는 데이터를 청크 단위로 나누어 전송하기 때문입니다. 각 청크가 서버로 전송될 때마다 API 호출 결과를 확인할 수 있으며, 이를 통해 전체 데이터 중 몇 건이 업로드되었는지 사용자에게 진행률 형태로 제공할 수 있습니다.

실행 시간을 확인해보니 다음과 같이 나왔습니다.

약 총 337초 정도 걸린것을 확인할 수 있었습니다. 5분정도 걸렸습니다.
테스트 결과, 아무런 분할 없이 데이터를 전송했을 때는 약 25분 정도가 소요되었습니다. 반면 데이터를 청크 단위로 분할하여 전송했을 경우 약 5분 내외로 처리되었으며, 이를 통해 전체 처리 시간이 약 80% 감소한 것을 확인할 수 있었습니다.

이렇게 보면 나쁘지 않아 보이지만, 단점도 명확합니다.

우선 브라우저가 100만 건의 엑셀 데이터를 직접 읽고 파싱해야 합니다. 데이터의 양이 많아질수록 클라이언트의 메모리 사용량도 함께 증가하게 되며, 경우에 따라서는 브라우저가 일시적으로 응답하지 않거나 화면이 멈추는 현상이 발생할 수 있습니다.
결국, 서버의 부담을 줄일 수 있다는 장점은 있지만, 그 부담이 사용자 브라우저로 이동하는 구조라고 볼 수 있습니다. 특히 대용량 데이터를 처리해야 하는 환경에서는 사용자의 PC 성능이나 브라우저 상태에 따라 업로드 품질이 달라질 수 있다는 점도 고려해야 합니다.

ai를 시켜 벤치마킹을 해본결과

크롬이 살짝 빠른것을 알 수 있었습니다. 물론 테스트를 많이 해본것이 아니기 때문에 오차는 있을 수 있지만, 브라우저마다 속도가 다르다는 느낌은 받을 수 있었습니다.

두 번째 방법은 "이진 단위(바이트 단위)로 분할"하는 방식입니다.

이진 단위로 분할하는 방식

앞선 방식이 브라우저에서 엑셀 파일을 직접 파싱한 뒤, 데이터를 JSON 형태로 분할하여 서버에 전송하는 방식이었다면, 이번 방식은 엑셀 파일 자체를 바이트 단위로 나누어 서버에 전송하는 방식입니다.

예를 들어 file.slice()를 활용하면 파일을 1MB, 5MB와 같은 일정 크기의 조각으로 분할할 수 있습니다. 이후 분할된 파일 조각들을 서버로 전송하고, 서버에서는 이를 다시 하나의 파일로 재조립합니다. 재조립이 완료되면 Apache POI와 같은 라이브러리를 이용해 엑셀을 파싱하고 DB에 데이터를 저장하게 됩니다.

이 방식은 브라우저에서 엑셀 파일을 직접 파싱하지 않기 때문에 엑셀 파싱 라이브러리에 대한 의존도가 낮습니다. 또한 엑셀 데이터를 메모리에 모두 올려 처리하지 않으므로, 행 단위 분할 방식에 비해 브라우저의 메모리 부담이 상대적으로 적습니다.

delete 됨

가장 큰 특징은 업로드가 바이트 단위로 이루어진다는 점입니다. 따라서 마지막으로 성공한 파일 조각 정보를 관리하고 있다면, 업로드 도중 네트워크 오류가 발생하더라도 처음부터 다시 전송할 필요 없이 실패한 지점부터 업로드를 재개할 수 있습니다. 실제로 Google Drive와 같은 대용량 파일 업로더나 AWS S3 Multipart Upload 역시 이와 유사한 방식을 사용하고 있습니다.

실제로 구동을 시켜보겠습니다.

테스트 결과, 처리 시간은 약 360초로 측정되었습니다. 이는 앞서 프론트에서 엑셀을 직접 파싱한 뒤 데이터를 분할하여 전송했던 방식보다 약 24초 정도 느린 결과였습니다.

이쯤 되니 브라우저의 메모리 사용량이 얼마나 차이 나는지도 궁금해집니다. 비록 처리 시간은 조금 더 소요되었지만, 사용자 입장에서 체감하는 경험은 오히려 더 나았기 때문입니다.

이 방식의 가장 큰 특징은 프론트만으로는 구현이 어렵다는 점입니다. 파일을 바이트 단위로 분할하여 전송하는 것은 프론트에서 수행할 수 있지만, 분할된 파일 조각들을 다시 하나의 파일로 재조립하는 작업은 서버에서 담당해야 합니다. 즉, 프론트와 백엔드가 함께 구현되어야만 완성할 수 있는 구조입니다.

반면 프론트 입장에서는 상대적으로 부담이 적습니다. 브라우저가 엑셀 데이터를 직접 읽고 파싱할 필요가 없으며, 단순히 파일을 일정 크기의 조각으로 나누어 전송하기만 하면 됩니다. 따라서 대용량 엑셀 파일을 처리하는 과정에서도 브라우저가 멈추거나 과도한 메모리를 사용하는 현상이 상대적으로 적어, 사용자 입장에서는 보다 쾌적하게 동작한다고 느껴졌습니다.

다만, 이 방식은 대용량 파일 전송의 안정성을 높이는 데 초점이 맞춰져 있습니다. 서버에 파일이 모두 업로드된 이후에는 여전히 파일 재조립, 엑셀 파싱, DB 적재 과정을 거쳐야 하므로 데이터 처리 성능 자체를 직접적으로 개선하는 방식은 아닙니다. 즉, 데이터 처리 최적화보다는 파일 업로드 안정성 향상에 더 적합한 방법이라고 볼 수 있습니다.

개인적으로 엑셀 업로드에 이 방식을 사용하는 것은 비효율적이라고 생각합니다. 엑셀 데이터는 결국 row 단위로 파싱되고 처리되어야 합니다. 따라서 바이트 단위로 파일을 분할하여 업로드하더라도, 서버에서는 다시 파일을 재조립한 뒤 row 단위로 파싱해야 합니다. 결국 업로드 안정성은 높일 수 있지만, 엑셀 데이터 처리 자체를 개선하는 방식은 아니라고 판단이 되어집니다.

서버에서 데이터를 쪼개보자.

앞서 살펴본 방식들은 데이터를 분할하는 주체가 프론트였습니다. 엑셀을 직접 파싱하여 JSON 형태로 분할하는 방법도 있었고, 파일 자체를 바이트 단위로 분할하는 방법도 있었습니다. 이번에는 관점을 바꿔보겠습니다. 프론트는 엑셀 파일을 그대로 서버에 전달하고, 데이터를 분할하는 작업은 서버에서 수행하는 방식입니다. 즉, 데이터를 쪼개는 주체가 프론트가 아닌 서버가 되는 것입니다.

찾아보니 서버에서는 기술적으로 쪼개는 방법도 존재하지만, 프로토콜 또는 스펙 기반으로, 인프라 아키텍처 레벨로 , 언어/ JVM 기능적으로 쪼개는 방법들도 다양하게 존재합니다.

기술적 관점

기술적으로 엑셀 데이터를 쪼개는 방법에 대해 고민해보았습니다. 크게 보면 처리량을 높이는 방법과, 대용량 데이터를 안정적으로 처리하는 방법으로 나누어 볼 수 있습니다. 이번에 적용해볼 기술은 Spring Batch입니다. Spring Batch는 데이터를 일정한 chunk 단위로 나누어 처리할 수 있기 때문에 대량 데이터 적재에 적합하다고 판단하였습니다. 또한 Apache POI SAX도 함께 적용해보려고 하였지만, 확인해보니 이미 적용된 상태였습니다. Apache POI SAX는 엑셀 전체를 메모리에 올리지 않고 row 단위로 읽는 방식이기 때문에, OOM이 발생하지 않았던 이유도 이와 관련이 있었습니다.

spring batch

이번에는 프론트에서는 단순히 파일 업로드만 수행하고, 서버에서 Spring Batch를 이용해 엑셀 데이터를 분할 처리하기로 하였습니다.

어떻게 보면 서버에서 엑셀 파일을 읽고 바로 저장하는 방식에 비해 row를 chunk 단위로 나누는 과정이 추가되었을 뿐입니다. 하지만 실제 테스트 결과 처리 시간에는 차이가 있었습니다. 약 25분 정도 소요되던 작업이 7분 내외로 단축된 것을 확인할 수 있었습니다.

이렇게 보면 프론트에서 데이터를 미리 분할하여 전송하는 방식이 가장 좋아 보일 수 있습니다. 하지만 서버에서 row를 분할하여 처리하는 방식도 분명한 장점이 존재합니다. (336s -> 360s -> 420s)

가장 큰 장점은 처리 현황을 서버에서 직접 관리할 수 있다는 점입니다. 프론트에서 데이터를 분할하여 전송하는 방식은 업로드 진행률은 확인할 수 있지만, 실제 데이터가 얼마나 저장되었는지는 확인하기 어려웠습니다. 반면, 서버에서 Spring Batch를 통해 데이터를 처리하는 경우에는 현재 몇 건이 처리되었고, 몇 건이 남았는지와 같은 실제 처리 현황을 확인할 수 있습니다.

파일을 읽고 db에 쓰기 작업을 가집니다. procress는 사용할 팔요가 없어 의도적으로 사용하지 않았습니다.

즉, 단순히 파일 업로드 진행 여부가 아니라 실제 데이터 적재 진행 상황을 확인할 수 있다는 점은 운영 관점에서도 의미가 있다고 생각합니다.

언어 관점

현재는 서버(JVM)에서 엑셀 데이터를 읽고 처리한 뒤 DB에 저장하는 구조를 사용하고 있습니다. 한 행씩 순차적으로 진행되는 이 흐름을 JVM 차원에서 어떻게 쪼갤 수 있는지 InputStream을 통한 스트리밍 입력, ExecutorService를 통한 병렬 처리, Parallel Stream을 통한 선언적 분산 등의 도구를 중심으로 정리합니다.

InputStream을 통한 스트리밍 입력

사실 이 부분은 이미 적용이 되어 있습니다. 그렇다면, 이 방식으로 왜 적용해야 하는지 생각해봅시다.

MultipartFile.getInputStream()으로 받은 입력을 그대로 POI에 흘려보내고, POI는 한 행씩 SAX 이벤트로 파싱합니다. 메모리에 파일 전체를 올리지 않습니다.

만약 같은 동작을 스트리밍 없이 짠다고 가정해봅시다.

두 단계에서 메모리가 부풀어 오릅니다.

1. getBytes() — 파일 크기만큼 byte[] 점유 (28MB)
2. WorkbookFactory.create() — 모든 셀을 객체로 메모리에 보관 (수 GB 가능)

100만 행짜리 파일이면 JVM 힙 한도를 쉽게 넘겨 OutOfMemoryError가 발생합니다. 28MB → 28MB가 아니라, 28MB → 수 GB로 부풀어 오를 수 있습니다. xlsx는 압축 포맷이라 압축 해제 시 5~10배로 커지고, 그걸 모두 객체로 다시 표현하면 또 한 차례 늘어나기 때문입니다.

하지만 예상과달리 oom이 발생하지 않았습니다. 이는 POI라이브러리가 자체 안전장치로 100MB 이상 배열할당을 거부합니다.
(POI 5.2.1에서 추가)
POI 라이브러리가 이런 가드를 만든 이유는 xlsx 파일은 zip으로 압축되어 있어서 28MB 파일을 압축 해제 시 수 GB로 부풀 수 있습니다. 그렇게 되면 악의적인 zip bomb 공격이 가능해집니다. 만약, DOM 파서가 그걸 그대로 메모리에 올린다면, 서버는 OOM이 발생하게 됩니다. 그래서 POI는 이만큼 이상은 위험하니 거부 한도를 내장하였습니다. 물론, IOUtils.setByteArrayMaxOverride()을 통해 강제로 늘릴 수 있수 있지만, 그 길로 가면 진짜 OOM이 발생할 수 있다고 합니다.

ExecutorService를 통한 병렬 처리

ExecutorService를 통한 병렬 처리도 검토해보았습니다. Spring Batch를 사용하면 chunk 단위 처리와 함께 병렬 처리도 구성할 수 있습니다. 하지만 그 전에 순수 Java 관점에서도 데이터를 병렬로 처리할 수 있는지 확인해보고 싶었습니다. 현재 서버에서는 InputStream을 통해 엑셀 파일을 읽고 있습니다. 그렇다면 InputStream으로 읽어온 데이터를 일정 단위로 나눈 뒤, ExecutorService를 이용해 병렬로 처리하면 성능이 개선될 수 있을까요?

이번에는 이 방식을 직접 테스트해보며, 서버 내부에서 병렬 처리를 적용했을 때 처리 시간이 어떻게 달라지는지 확인해보겠습니다.

예상 밖의 결과였습니다. Spring Batch를 사용하지 않았음에도 처리 시간이 약 268.2초로 측정되었고, 지금까지 테스트한 방식 중 가장 빠른 결과였습니다.

아무래도 데이터를 일정 단위로 나눈 뒤 ExecutorService를 통해 여러 스레드에서 병렬로 처리하면서 전체 처리 시간이 줄어든 것으로 보입니다. 즉, 하나의 스레드가 모든 데이터를 순차적으로 처리하는 방식보다, 여러 스레드가 작업을 나누어 처리한 것이 성능 개선에 영향을 준 것으로 판단하였습니다.

그렇다면, 스레드가 2~20까지 테스트한 결과는 어떨까요?

스레드 풀 4개 짜리의 시간이 다른 이유는 재 테스트를 진행하였습니다.

테스트 결과, 스레드 수가 6개가 되는 시점부터 처리 시간이 급격하게 단축되는 것을 확인할 수 있었습니다. 이는 일정 수준까지는 병렬 처리 효과가 분명히 존재한다는 의미로 볼 수 있습니다.

하지만 스레드 수가 10개를 넘어가면서부터는 처리 시간이 안정적으로 감소하지 않고, 오히려 증가와 감소를 반복하는 모습을 보였습니다. 즉, 스레드 수를 늘린다고 해서 무조건 성능이 좋아지는 것은 아니었습니다.

특히 스레드 풀 크기를 16개로 설정했을 때는 알 수 없는 이유로 작업이 중단되었습니다. 원인을 확인해보니 DB 연결이 끊어진 것이 문제였습니다. 여러 스레드가 동시에 insert를 수행하면서 Oracle 쪽 세션이 종료되었고, 그 결과 chunk 작업에서 예외가 발생하였습니다.

이후 Future.get()을 통해 예외가 전파되면서 서버에서는 500 에러가 발생하였고, 최종적으로 curl 응답 파싱 실패로 기록되었습니다.

이를 통해 병렬 처리에는 적정 수준이 존재한다는 것을 확인할 수 있었습니다. 스레드 수를 늘리면 일정 구간까지는 처리량이 증가하지만, DB 커넥션 수, Oracle 세션 제한, insert 부하 등을 넘어서면 오히려 실패 가능성이 높아질 수 있습니다. 이는 ExecutorService 자체의 문제가 아니라, HikariCP 커넥션 풀에서 병목이 발생했던 것이 원인이었습니다. 여러 스레드가 동시에 DB insert를 수행하려고 했지만, 실제로 사용할 수 있는 DB 커넥션 수에는 제한이 있었기 때문입니다.

그렇다면 이를 어떻게 해결할 수 있을까요?

가장 간단한 방법은 HikariCP 커넥션 풀 크기를 스레드 풀 크기에 맞춰 늘리는 것입니다. 예를 들어 작업 스레드가 16개라면, DB 커넥션도 16개 이상 사용할 수 있도록 설정하는 방식입니다.

하지만 이 방법은 권장하기 어렵습니다. 커넥션 풀 크기를 늘리면 애플리케이션 입장에서는 대기 시간이 줄어들 수 있지만, 그만큼 DB가 동시에 처리해야 하는 요청 수가 증가합니다. 결국 병목이 애플리케이션에서 DB로 이동할 뿐이며, DB 세션 수나 insert 부하를 초과하면 오히려 장애 가능성이 높아질 수 있습니다.

따라서 커넥션 풀을 무작정 늘리기보다는, DB가 안정적으로 감당할 수 있는 수준에서 스레드 수와 커넥션 수를 함께 조정하는 것이 더 적절하다고 판단하였습니다.

하지만, 이 글에서는 테스트를 위해 HikariCP 커넥션 풀을 20으로 올려보겠습니다.

이번에는 스레드 2개를 기준으로 얼만큼 성능이 향상 되었는지도 파악해보겠습니다.

결과를 확인해보니 가장 안정적이면서 성능이 우수했던 구간은 스레드 수가 8개일 때였습니다. 가장 빠른 처리 시간은 스레드 12개에서 측정되었지만, 스레드 10개 구간에서 오히려 성능이 감소하는 현상이 나타났기 때문에 안정적인 구간이라고 보기는 어려웠습니다.

결국 단순히 스레드 수를 늘리는 것이 성능 향상으로 이어지는 것은 아니었으며, 적절한 스레드 수를 찾는 과정이 중요하다는 것을 확인할 수 있었습니다.

이번 테스트를 통해 ExecutorService를 활용한 병렬 처리 방법과, 병렬 처리 과정에서 발생할 수 있는 커넥션 풀 병목에 대해 함께 학습할 수 있었습니다. 또한 성능 최적화는 단순히 스레드를 늘리는 것이 아니라, 애플리케이션과 DB가 감당할 수 있는 균형점을 찾는 과정이라는 점도 확인할 수 있었습니다.

프로토콜 관점

현재 업로드는 HTTP Multipart 기반입니다. 하지만 네트워크 장애로 업로드가 실패하면, 서버에 수신 상태가 남지 않아 처음부터 다시 올려야 합니다. 이때 재개 가능한 업로드 프로토콜인 tus를 적용하면, 끊긴 지점부터 이어서 전송할 수 있습니다.

tus

tus - resumable file uploads

tus is the open protocol standard for resumable and reliable file uploads across the web, facilitating efficient and seamless file transfer experiences.

tus.io

tus는 생각보다 다양한 기능을 제공하기 때문에 모든 내용을 다루기에는 범위가 너무 넓습니다. 따라서 이번 글에서는 핵심 동작 원리와 간단한 구현 방법만 살펴보겠습니다.

구현은 가장 간단한 CDN 방식을 이용하여 진행하겠습니다.

tus프로토콜을 이용하면 서버에 얼마나 적재중인지 확인할 수 있습니다.

하지만, db에 적재가 되어지는것이 아니기 때문에 서버 메모리에 저장이 되어지는것으로 추정이 되어집니다.

확인해보니 성능 측면에서는 기대했던 만큼의 차이를 확인할 수는 없었습니다. 다만 tus 프로토콜을 사용하는 가장 큰 이유는 성능이 아니라 전송 재개(Resumable Upload) 에 있습니다. 네트워크 문제가 발생하더라도 처음부터 다시 업로드하는 것이 아니라, 중단된 지점부터 업로드를 이어갈 수 있다는 점이 가장 큰 특징입니다.

실제로 적용해보기 위해 테스트를 진행하였지만 생각보다 쉽지는 않았습니다. 인텔리제이를 재시작하거나 개발 환경을 다시 구성하는 과정에서 업로드 상태가 초기화되는 문제가 있었고, 기대했던 형태로 동작을 확인하지는 못하였습니다.

추후 tus에 대해 조금더 자세하게 학습해보겠습니다.

따라서 이번 글에서는 tus의 핵심 개념과 동작 원리 정도만 소개하고, 상세한 구현 내용은 추후 별도로 다뤄보도록 하겠습니다.

DB에서 데이터를 쪼개보자.

드디어 마지막 단계입니다. 지금까지 프론트와 서버에서 대용량 엑셀 데이터를 어떻게 분할하고 처리할 수 있는지 살펴보았습니다.

그렇다면 DB에서 데이터를 분할하는 것은 어떤 의미가 있을까요?

사실 DB에서 데이터를 분할한다고 해서 파일 업로드 속도가 빨라지거나, 서버가 데이터를 읽는 속도가 개선되는 것은 아닙니다. 즉, 전송 과정의 최적화와는 거리가 있습니다.

그럼에도 불구하고 DB에서 데이터를 분할하는 이유는 무엇일까요?

그 이유는 처리량보다는 안정성에 있습니다. 트랜잭션 범위를 줄이고, DB 부하를 분산하며, 실패 시 재처리 범위를 최소화할 수 있기 때문입니다. 그렇다면 DB에서는 어떤 방식으로 데이터를 분할할 수 있을까요?

프로시저

DB에서 데이터를 분할하는 방법으로는 여러 가지가 있지만, 이번 글에서는 프로시저를 중심으로 살펴보겠습니다. 프로시저를 사용하면 서버가 임시 테이블에 데이터를 적재한 뒤, DB 내부에서 일정 단위로 데이터를 검증하고 실제 테이블에 반영할 수 있습니다.

역시나 처리량은 줄지 않았군요. 프로시저 쿼리를 보면 다음과 같습니다.

이 프로시저는 user_row_tab 형태의 여러 사용자 데이터를 입력받아 users 테이블에 한 번에 저장하는 역할을 합니다. 여기서 핵심은 FORALL입니다. 일반적인 FOR LOOP는 한 건씩 SQL을 실행하지만, FORALL은 PL/SQL 컬렉션에 담긴 데이터를 SQL 엔진에 한 번에 전달하여 대량 INSERT를 수행할 수 있습니다. 즉, 서버에서 100만 건을 한 건씩 DB에 전달하는 것이 아니라, 일정 단위로 묶은 데이터를 프로시저에 전달하고 DB 내부에서 일괄 처리하는 방식입니다. 이를 통해 애플리케이션과 DB 사이의 반복 호출을 줄일 수 있고, 대량 데이터 적재 시 발생하는 오버헤드를 줄일 수 있습니다.

다만 이 구조는 단순 INSERT에 가깝습니다. 실제 운영 환경에서는 여기서 한 단계 더 발전시킬 수 있습니다. 예를 들어 중복 데이터 검증, 필수값 누락 검증, 실패 데이터 별도 저장, 처리 결과 건수 반환, 예외 발생 시 로그 테이블 적재 등을 추가할 수 있습니다.

결국 프로시저 방식의 장점은 DB 내부에서 대량 데이터를 빠르게 반영할 수 있다는 점이고, 발전 방향은 단순 저장을 넘어 검증, 실패 관리, 결과 추적이 가능한 적재 프로세스로 만드는 것이라고 볼 수 있습니다.

다만 프로시저가 제공하는 장점 중 상당수는 서버에서도 대체할 수 있습니다. 데이터 검증, 실패 처리, 배치 Insert, 트랜잭션 제어는 Java와 Spring 기반에서도 충분히 구현할 수 있습니다. 따라서 프로시저는 반드시 필요한 선택이라기보다는, DB 내부에서 처리하는 것이 더 적합한 환경에서 선택할 수 있는 방식이라고 볼 수 있습니다.

간단하게 DB는 이 정도만 알아보도록 하겠습니다. DB파트는 DB에서도 데이터 분할이 가능한지 체크하기 위함이었습니다.

마무리

원래 목적은 프론트, 서버, DB에서 엑셀 row를 어떻게 분할하여 처리할 수 있는지 간단하게 정리하는 것이었습니다. 하지만 생각보다 다양한 방법들을 새롭게 알게 되었습니다. 예를 들어 프론트에서 데이터를 row 단위로 분할하여 전송하는 방법, 파일을 바이트 단위로 분할하여 전송하는 방법, tus 프로토콜을 이용한 전송 재개 방식, 그리고 ExecutorService를 활용한 병렬 처리 방식 등이 있었습니다. 이번에 테스트한 방법들이 모두 대용량 엑셀 업로드에 적합한 것은 아니었습니다. 엑셀 업로드는 결국 파일을 읽고 row 단위로 처리해야 하기 때문에, 바이트 단위 분할과 같은 방식은 목적에 비해 다소 우회적인 접근이라고 느껴졌습니다. 하지만 이런 방식도 존재한다는 것을 알게 되었고, 언젠가 다른 문제를 해결할 때 활용할 수 있을 것이라 생각합니다.

또한, 이번 글에서 소개한 방법들이 전부는 아닙니다. 조금만 더 깊게 들어가도 훨씬 다양한 기술과 아키텍처를 확인할 수 있었습니다. 다만 모든 내용을 담기에는 범위가 너무 넓고, 실제 엑셀 업로드 문제를 해결하는 데 필요한 수준을 넘어선다고 판단하여 제외하였습니다.

결과적으로, 이번 글을 통해 느낀 점은 단순히 엑셀 업로드 기능 하나를 구현하는 것이 아니라, 데이터를 어디에서 분할할 것인지에 따라 전송 방식, 처리량, 안정성, 운영 방식까지 달라질 수 있다는 점이었습니다. 앞으로도 새로운 요구사항을 마주하게 된다면 구현에만 집중하기보다는 어떤 위치에서 문제를 해결하는 것이 가장 적절한지 먼저 고민해보려고 합니다.

뉴럴 네트워크

klom — Mon, 25 May 2026 15:52:42 +0900

기존 언어 모델 방식 중 하나인 N-gram은 이전 데이터를 기반으로 다음 단어를 예측하는 방식입니다. 하지만 N의 크기가 너무 낮다면 문맥을 충분히 이해하지 못해 의도를 알 수 없는 문장을 생성할 수 있습니다. 반대로 N의 크기가 너무 높아진다면 문맥 자체는 자연스러워지지만, 희소성 문제가 심해져 새로운 문장을 생성할 가능성이 낮아지게 됩니다. 이러한 한계를 해결하기 위해 다양한 연구가 진행되었고, 2003년 조수아 벤지오 교수의 신경망 기반 언어 모델 연구가 큰 전환점이 되었습니다. 특히 단어를 벡터로 표현하고 신경망을 통해 다음 단어를 예측하는 방식은 이후 현대 LLM의 기반이 되는 흐름으로 이어지게 됩니다. 이번 글에서는 이러한 흐름 속에서 등장한 뉴럴 네트워크가 무엇인지에 대해 알아보겠습니다.

뉴럴 네트워크란?

뉴럴 네트워크는 인간의 뇌 신경망 구조에서 아이디어를 얻어 만들어진 모델입니다. 인간은 뉴런(neuron)들이 서로 연결되어 정보를 처리합니다. 이러한 구조를 컴퓨터에서도 비슷하게 표현하여 데이터를 학습하고 패턴을 분석할 수 있도록 만든 것이 뉴럴 네트워크입니다.

그렇다면 뉴럴 네트워크는 실제로 어떤 방식으로 데이터를 학습하게 될까요?
단순한 이론보다는 흐름을 보는 것이 이해가 더 쉽다고 생각하여 간단한 영상을 준비해보았습니다.

초반에는 어떤 단어가 정답인지 제대로 학습되지 않았기 때문에 여러 글자들이 비슷한 확률로 출력되고 있으며, loss 값 역시 높게 측정됩니다. 하지만 학습이 반복될수록 데이터의 패턴을 점차 학습하게 되고, 최종적으로는 "다"라는 글자가 가장 높은 확률로 예측되는 것을 확인할 수 있습니다.
여기서 한 가지 의문이 생깁니다.
"사, 랑, 하"라는 문자와 "다, 는, 늙, 기"라는 문자 사이의 관계를 컴퓨터는 어떻게 이해할 수 있을까요?
중요한 점은 컴퓨터는 인간처럼 문자 자체의 의미를 이해하지 못한다는 것입니다. 컴퓨터 입장에서는 단순한 데이터에 불과하기 때문입니다.
이를 해결하기 위해 문자를 숫자로 변환하여 표현하기 시작하였고, 숫자를 기반으로 특정 위치(좌표)에 배치하여 문자 간의 관계를 학습할 수 있도록 하였습니다.

좌표를 만드는건 알겠는데 어떤 기준으로 좌표를 만드는가?

"사"라는 문자가 정확히 어떤 숫자나 의미를 가지는지는 초반에는 알 수 없습니다. 실제로 뉴럴 네트워크는 처음부터 의미를 이해하고 있는 것이 아니라, 랜덤한 값에서 시작하여 점차 학습을 통해 관계를 찾아가게 됩니다.
그렇기 때문에 초기에는 예측 결과가 불안정하며 여러 단어들이 비슷한 확률로 출력될 수 있습니다. 이후 학습이 반복되면서 특정 패턴의 확률이 점점 높아지게 됩니다.
흔히 LLM이 "주사위를 굴려서 답변한다"라고 표현하는 이유 역시, 내부적으로 확률 기반 예측을 수행하기 때문입니다.
컴퓨터가 문자 간의 관계를 이해할 수 있도록 숫자 형태의 좌표로 변환하는 과정을 임베딩(Embedding)이라고 합니다.

즉, 임베딩은 글자들을 숫자 좌표로 변환하는 과정을 의미합니다. 보통 이러한 숫자 변환은 벡터(Vector) 형태의 좌표로 표현됩니다.
하지만 임베딩만 했다고 해서 학습이 끝난 것은 아닙니다. 첫 번째 영상을 다시 보면, 앞 글자를 확인하고 숫자로 변환한 뒤 은닉층(Hidden Layer)과 출력층(Output Layer)으로 이동하는 것을 알 수 있습니다.

벡터(Vector)란 여러 숫자를 하나의 좌표처럼 묶어서 표현한 값을 의미

즉, 실제 학습은 그 이후부터 시작된다고 볼 수 있습니다.

그렇다면 뉴럴 네트워크는 숫자로 변환된 데이터를 어떤 방식으로 학습하게 될까요?

임베딩까지 마쳤습니다. 위 이미지를 다시 확인해보면, 실제 학습은 은닉층(Hidden Layer)에서 진행되는 것을 알 수 있습니다.
그렇다면 은닉층에서는 어떤 일이 발생하게 될까요?
쉽게 말하면 은닉층은 임베딩을 통해 구한 좌표값에 가중치(Weight)를 부여하여 데이터의 중요도를 학습하는 과정이라고 볼 수 있습니다. 은닉층에서 말하는 가중치는 어떤 데이터를 얼마나 중요하게 볼 것인가에 있습니다.
예를 들어 "사, 랑, 하"라는 입력이 들어왔다고 가정해보겠습니다. 컴퓨터는 어떤 글자가 중요한지, 어떤 패턴이 자주 등장하는지, 어떤 연결이 강한지를 숫자로 조정하며 학습하게 됩니다.

그렇다면, 어떤 기준으로 가중치를 부여하는 걸까요?

뉴럴 네트워크는 예측한 값과 실제 정답을 비교하여 가중치를 조정하게 됩니다. 예를 들어 "사, 랑, 하" 다음에 "다"가 정답이라고 가정하였는데 다른 글자를 높은 확률로 예측하였다면, 오차(loss)가 크게 발생하게 됩니다.
이후 뉴럴 네트워크는 이 오차를 줄이기 위해 가중치를 반복적으로 수정하게 됩니다. 즉, 학습이란 결국 정답에 가까워지도록 가중치를 계속 조정하는 과정이라고 볼 수 있습니다.
뉴럴 네트워크는 입력된 데이터를 가중치와 활성화 함수(Activation Function)를 통해 계산한 뒤 결과를 출력하게 됩니다. 이후 예측값과 실제 정답을 비교하여 오차(loss)를 계산하고, 역전파(Backpropagation)를 통해 가중치를 수정하며 학습하게 됩니다.

활성화 함수

활성화 함수(Activation Function)는 신경망에 비선형성을 추가해주는 역할을 합니다. 만약 활성화 함수가 존재하지 않는다면 단순한 선형 계산만 반복되기 때문에 복잡한 패턴을 학습하기 어려워집니다.
대표적으로 sigmoid, relu, tanh와 같은 활성화 함수들이 존재합니다.

그렇다면 왜 단순한 선형 계산만으로는 복잡한 패턴을 학습하기 어려운 것일까요?

가장 큰 이유는 선형 계산은 결국 직선 형태의 결과만 표현할 수 있기 때문입니다. 예를 들어 활성화 함수가 다음과 같다고 가정해보겠습니다.

여기서 의문은 어째서 단순한 선형 계산만 반복이 되는게 왜 복잡한 패턴을 학습하기 어려울까요?
가장 큰 이유는 선형 계산은 결국 직선 형태의 결과만 표현할 수 있기 때문입니다. 예를 들어 활성화 함수가 다음과 같다고 가정해보겠습니다. 그리고 입력값이 -1, 2, 3이라고 가정해보겠습니다. 이렇게 되면 모든 데이터는 결국 하나의 직선 위에 존재하게 됩니다.
하지만 실제 데이터는 단순한 직선 형태로만 존재하지 않습니다. 이미지, 언어, 음성 데이터처럼 복잡한 데이터들은 곡선 형태의 관계나 비선형적인 패턴을 가지는 경우가 많습니다.

따라서 뉴럴 네트워크는 활성화 함수를 통해 비선형성을 추가하여 복잡한 패턴 역시 학습할 수 있도록 구성됩니다.

역전파

뉴럴 네트워크는 예측값과 실제 정답을 비교하여 오차(loss)를 계산한다고 하였습니다. 이러한 과정을 통해 어떤 부분이 잘못 예측되었는지를 확인하고, 이를 기반으로 학습을 진행하게 됩니다.
오차를 보고 수정한다는 개념까지는 이해할 수 있습니다. 하지만 여기서 몇 가지 문제가 발생합니다.
신경망에는 수많은 가중치(Weight)가 존재합니다. 그렇다면 어떤 가중치가 잘못된 것일까요?
또한 어느 정도 수정해야 하는지 역시 알 수 없습니다. 이러한 문제를 해결하기 위해 등장한 개념이 역전파(Backpropagation)입니다.
쉽게 말하면 역전파는 "책임 분배" 과정이라고 볼 수 있습니다. 출력된 오차를 기반으로 원인을 출력층(Output Layer)에서 입력층(Input Layer) 방향으로 거꾸로 추적하면서, 각 가중치에게 얼마나 책임이 있는지를 계산하게 됩니다.
역전파라는 이름 역시 여기서 등장합니다. 계산은 입력 → 출력 방향으로 진행되지만, 오차의 책임은 출력 → 입력 방향으로 전달되기 때문입니다.

설명을 위해 다음과 같이 가정해보겠습니다.

입력값: x = 2
가중치: w1 = 0.5, w2 = 3

은닉값(h)은 다음과 같이 계산됩니다.

h=w1*x=0.5×2=1

출력값(y)은 다음과 같습니다.

y=w2*h=3×1=3

하지만 실제 정답이 9라고 가정해보겠습니다.
그렇다면 오차(loss)는 다음과 같이 계산됩니다.

(9−3)^2=36

즉, 현재 예측값과 실제 정답의 차이가 크기 때문에 loss 역시 크게 측정된다는 뜻입니다.
이제 역전파는 이 오차를 줄이기 위해 어떤 가중치가 얼마나 잘못되었는지를 계산하기 시작합니다.
마지막으로 softmax와 cross-entropy를 간단하게 알아보고 마치겠습니다.

softmax

출력층(Output Layer)에서는 여러 값들이 계산되어 출력됩니다. 하지만 이 값들은 아직 확률이라고 보기 어렵습니다.
예를 들어 다음과 같은 값이 출력되었다고 가정해보겠습니다.

다 → 3.2
기 → 1.1
늙 → 0.3

이 상태에서는 어떤 값이 얼마나 높은 확률을 가지는지 직관적으로 이해하기 어렵습니다.
이러한 값을 확률 형태로 변환해주는 함수가 Softmax입니다.
Softmax는 출력값들을 0~1 사이의 값으로 변환하며, 전체 합이 1이 되도록 만들어줍니다.
예를 들어, 다음과 같이 변환될 수 있습니다.

다 → 0.83
기 → 0.12
늙 → 0.05

즉, 뉴럴 네트워크는 "다"가 가장 높은 확률을 가진다고 판단하게 됩니다.

cross-entropy

Cross Entropy(교차 엔트로피)는 뉴럴 네트워크가 예측한 확률과 실제 정답이 얼마나 차이가 나는지를 계산하는 Loss 함수입니다.
예를 들어 다음과 같은 결과가 나왔다고 가정해보겠습니다.

다 → 0.83
기 → 0.12
늙 → 0.05

그리고 실제 정답이 "다"라고 해보겠습니다.
이 경우 뉴럴 네트워크는 정답인 "다"를 높은 확률로 예측하였기 때문에 Loss 값은 낮게 측정됩니다.
반대로 다음과 같은 결과가 나왔다고 가정해보겠습니다.

다 → 0.10
기 → 0.80
늙 → 0.10

이 경우 실제 정답인 "다"를 낮은 확률로 예측하였기 때문에 Loss 값은 크게 증가하게 됩니다.
즉, Cross Entropy는 정답에 가까운 확률을 예측할수록 Loss를 낮게 만들고, 정답과 멀어질수록 Loss를 크게 증가시키는 역할을 합니다.
보통 Softmax와 함께 사용되며, 뉴럴 네트워크는 Cross Entropy를 최소화하는 방향으로 가중치를 수정하며 학습을 진행하게 됩니다.

마지막으로 전체 흐름을 한번에 확인해보겠습니다.

입력 문장: "나는 강아지를 ___"
   ↓ ① 토큰화
[나는=42, 강아지를=1057, ___]
   ↓ ② 임베딩 조회
[0.2, 0.5, ...] [0.1, 0.9, ...]   ← 각 토큰의 벡터
   ↓ ③ 합치기 (concatenate)
[0.2, 0.5, ..., 0.1, 0.9, ...]    ← 하나의 큰 벡터
   ↓ ④ 은닉층 (행렬곱 + 활성화)
[0.7, -0.3, 0.2, ...]              ← 압축된 의미
   ↓ ⑤ 출력층 (어휘수만큼 점수)
[3.2, -1.5, 0.8, 7.1, ..., 0.4]   ← 각 단어의 점수
   ↓ ⑥ Softmax
[1%, 0.1%, 5%, 70%, ..., 2%]      ← 확률
   ↓ ⑦ 정답과 비교 (Cross-Entropy)
Loss = 1.99
   ↓ ⑧ 역전파
모든 가중치 + 임베딩까지 살짝 조정

마무리

간단하게 뉴럴 네트워크에 대해 알아보았습니다. 이번 글에서는 뉴럴 네트워크가 어떤 방식으로 동작하는지에 초점을 맞춰 설명하였습니다.
그러다 보니 뉴럴 네트워크가 새로운 문장을 어떻게 만들어내는지에 대한 설명은 다소 부족하다고 느껴졌습니다. 물론, 확률을 기반으로 loss를 계산하고, 이를 통해 어떤 값이 더 정답에 가까운지를 학습한다는 흐름까지는 이해할 수 있었습니다.

그래서 다음 글에서는 뉴럴 네트워크가 어떤 방식으로 새로운 문장을 생성하는지에 대해 조금 더 자세히 알아보려고 합니다.
또한 이번 글에서 설명하지 못한 부분이 하나 있습니다. 앞에서 임베딩은 단어를 좌표 형태로 변환한다고 설명하였습니다. 하지만 실제로는 각 단어를 표현하기 위한 좌표값이 하나만 존재하는 것이 아닙니다. 상황에 따라 수십 개, 수백 개 이상의 좌표값을 가질 수도 있습니다. 이러한 좌표의 개수를 임베딩 차원(Dimension)이라고 부릅니다.
일반적으로 차원이 커질수록 더 많은 정보를 표현할 수 있기 때문에 정확도는 높아질 수 있습니다. 하지만 반대로 계산량 증가, 과적합, 희소성 문제와 같은 부작용 역시 함께 발생할 수 있다는 점도 고려해야 합니다.

외부 API 호출은 어떤 라이브러리를 선택해야 할까

klom — Thu, 21 May 2026 23:43:13 +0900

외부 API에 접근하기 위해서는 HTTP 통신이 필요합니다. 직접 HTTP 통신 코드를 구현할 수도 있지만, Spring 환경에서는 WebClient, RestTemplate, FeignClient와 같은 HTTP 클라이언트 라이브러리를 사용할 수 있습니다. 그렇다면 어떤 라이브러리를 사용하는 것이 좋을까요?

일단 내가 중요하다고 생각하는걸 생각해보자.

기술을 선택할때 가장 먼저 고려해야 하는 요소는 환경입니다. 현재 어떤 프레임워크를 사용하고 있는지, 팀원들의 숙련도는 어느 정도인지, 현재 프로젝트 구조와 운영 방식은 어떠한지 등을 함께 고려할 필요가 있습니다.

예를 들어 팀 전체가 RestTemplate에 익숙한 환경이라면, 무조건 최신 기술이라는 이유만으로 WebClient를 도입하는 것이 오히려 유지보수 비용을 증가시킬 수 있습니다. 반대로 외부 API 호출이 많고 timeout, retry, logging과 같은 기능이 중요하다면 WebClient가 더 적합할 수 있습니다.

그럼에도 불구하고 webClient를 선택하였습니다. 그 이유는?

일단 간단하게 비교를 진행해봅시다.

RestTemplate

가장 큰 장점은 구축하기 쉽다는 점입니다. RestTemplate은 동기 방식 기반으로 동작하기 때문에 코드 흐름이 직관적이고, 요청과 응답의 흐름을 이해하기 쉽습니다. 또한 기존 프로젝트에서도 많이 사용되어 왔기 때문에 레퍼런스가 많고, 러닝 커브가 낮다는 점 역시 장점이라고 생각합니다.

하지만 기본적으로 동기 방식만 지원하기 때문에 비동기 처리를 하고 싶다면 @Async, CompletableFuture, ExecutorService와 같은 자바 비동기 기능을 추가로 구성해야 합니다.

즉, 비동기 처리를 자연스럽게 지원한다기보다는 별도의 구조를 덧붙여야 하는 방식에 가깝습니다. 그렇기 때문에 외부 API 호출이 많아지고, timeout, retry, logging 같은 세밀한 제어가 필요해질수록 다소 불편함이 생길 수 있습니다.

예를 들어, RestTemplate에서 요청/응답 로깅이나 공통 처리를 하려면 보통 ClientHttpRequestInterceptor를 사용합니다.

config에서 등록

즉, 공통 logging이나 header 처리를 위해서는 ClientHttpRequestInterceptor를 직접 구성해야 합니다. 물론 확장은 가능하지만, 외부 API 호출이 많아질수록 설정 코드 역시 점점 증가할 가능성이 높습니다.

FeignClient

그렇다면 Feign은 어떨까요? 편의상 Client는 빼고 Feign이라고 부르겠습니다. Feign은 선언형 방식으로 동작합니다.

그렇다면 선언형이란 무엇일까요? 위에서 살펴본 RestTemplate은 필요한 위치에서 직접 객체를 주입받아 메서드를 호출하는 방식입니다. 물론 스프링 빈으로 등록해서 공통으로 사용할 수 있지만, API 호출 코드가 서비스 로직 안에 섞이기 쉽다는 부담이 있습니다.

반면, Feign은 인터페이스 기반으로 외부 API 호출을 정의합니다. 즉, 어떤 URL로 요청을 보낼지, 어떤 메서드를 사용할지, 어떤 값을 파라미터로 전달할지를 인터페이스에 선언해두고 사용할 수 있습니다. 이런 특징 덕분에 외부 API 호출 규격을 한곳에 모아 관리하기 쉽고, 코드도 비교적 간결해집니다.

또한 서비스 간 호출 구조가 많은 MSA 환경에서는 각 서비스의 API 호출을 Feign 인터페이스로 분리해 관리할 수 있기 때문에 자주 사용됩니다.

그렇다면 비동기는 어떻게 지원할까요?

아쉽게도 Feign 또한 기본적으로 동기 방식으로 동작합니다. 그렇기 때문에 RestTemplate와 비슷하게 직관적으로 사용할 수 있다는 장점이 존재합니다.

물론 비동기 방식으로 사용하는 방법도 존재합니다. CompletableFuture와 같은 자바 비동기 기능을 함께 사용할 수도 있고, 비동기를 지원하는 별도의 설정을 추가할 수도 있습니다. 하지만 기본적으로는 동기 호출에 가까운 방식이라고 볼 수 있습니다.

얼핏봤을때 RestTemplate와 비슷하게 보이는데 선언형으로 만들었을때 무슨 장점이 있나?

하지만 선언형으로 구성했을때 가장 큰 차이는 외부 API 호출 자체를 하나의 역할로 분리할 수 있다는 점에 있다고 생각합니다.

예를 들어 RestTemplate는 아래처럼 서비스 내부에서 직접 URL, header, 요청 방식을 작성하는 경우가 많습니다.

이 방식은 간단하지만, 외부 API 호출 코드가 서비스 로직 안으로 들어오게 됩니다. 즉, 비즈니스 로직과 HTTP 호출 로직이 서로 섞이기 쉬워집니다.

반면 Feign은 외부 API 자체를 인터페이스로 분리합니다.

이렇게 구성하면 서비스에서는 외부 API 호출 방법을 신경쓰기보다는, 그냥 메서드를 호출하듯 사용할 수 있습니다. 즉, 선언형 방식의 장점은 단순히 코드가 짧아지는 것이 아니라 외부 API 역할 분리, 유지보수성 증가, 중복 감소,API 호출 규격 관리 용이,테스트 구조 분리 쉬움과 같은 구조적인 장점에 있다고 생각합니다. 특히 MSA처럼 서비스 간 호출이 많아질수록 “HTTP 요청 코드”를 여기저기 작성하는 것보다, 인터페이스 단위로 관리하는 방식이 훨씬 깔끔해질 수 있습니다.

WebClient

이제 마지막으로 WebClient에 대해 이야기해봅시다. WebClient는 Spring WebFlux에서 제공하는 HTTP Client입니다. 기존 RestTemplate와 다르게 비동기 및 논블로킹 방식을 지원한다는 특징이 존재합니다.

그렇다면 논블로킹은 무엇일까요?

기존 RestTemplate는 외부 API 요청을 보내면 응답이 올때까지 현재 스레드가 대기하게 됩니다. 즉, 응답이 돌아오기 전까지 다른 작업을 처리하지 못합니다.

반면 WebClient는 요청을 보낸 이후 응답을 기다리는 동안 스레드를 계속 점유하지 않습니다. 즉, 다른 작업을 수행하다가 응답이 도착했을때 다시 이어서 처리하는 방식에 가깝습니다.

이러한 특징 때문에 외부 API 호출이 많거나, 동시에 많은 요청을 처리해야 하는 환경에서 장점이 존재합니다.

또한 WebClient는 단순히 비동기만 지원하는 것이 아니라, 외부 API 호출 흐름 자체를 세밀하게 제어할 수 있습니다.

예를 들어 timeout, retry, logging, 공통 header, 응답 상태별 예외 처리와 같은 기능들을 비교적 유연하게 구성할 수 있습니다.

물론, RestTemplate 역시 interceptor나 config를 이용해 공통 설정을 구성할 수 있습니다. 하지만 timeout, logging, header 처리와 같은 기능들이 점점 늘어나게 되면 설정 코드가 커지고, 요청 흐름을 파악하기 어려워질 수 있습니다.

반면, WebClient는 builder와 filter 기반으로 흐름을 구성할 수 있기 때문에 요청 처리 과정을 비교적 명확하게 관리할 수 있었습니다.

즉, WebClient의 핵심은 단순히 비동기를 지원한다는 것이 아니라, 외부 API 호출 과정에서 발생할 수 있는 다양한 흐름을 유연하게 제어할 수 있다는 점에 있다고 생각합니다.

RestClient

Spring6부터 등장한 새로운 HTTP Client입니다. 기존 RestTemplate의 단순하고 직관적인 사용 방식은 유지하면서, 조금 더 현대 적인 API 스타일로 개선되었습니다.

기존 RestTemplate는 다음과 같이 작성하였습니다.

반면, RestClient는 builder 기반으로 조금 더 직관적으로 구성할 수 있습니다.

그래서 RestClient를 선택한 이유가 무엇인가요?

지금까지 RestTemplate, FeignClient, WebClient, RestClient에 대해 간단하게 알아봤습니다.

가장 러닝 커브가 낮은 것은 RestTemplate, 가장 선언적으로 사용하기 좋은 것은 FeignClient, 그리고 비동기 및 논블로킹 방식을 지원하는 것은 WebClient입니다. 그리고 RestClient는 기존 RestTemplate의 직관적인 사용 방식과 WebClient의 현대적인 API 스타일을 함께 가져온 기술이라고 볼 수 있습니다.

그렇다면 어떤 기술을 도입하는 것이 가장 현실적일까요?

현재는 AI의 등장으로 인해 과거보다 러닝 커브에 대한 부담이 많이 낮아졌다고 생각합니다. 하지만 현재 프로젝트에서는 Reactive 기반의 비동기 흐름까지 사용할 필요는 크지 않다고 판단했습니다.

물론 WebClient 역시 Spring MVC 환경에서 사용할 수 있습니다. 하지만 Mono, Flux와 같은 Reactive 흐름을 적극적으로 사용하지 않는다면, 현재 프로젝트에서는 오히려 구조가 과해질 수 있다고 느껴졌습니다.

반면 RestClient는 기존 MVC 환경에서도 비교적 자연스럽게 사용할 수 있었고, RestTemplate보다 조금 더 현대적인 방식으로 HTTP 요청 흐름을 구성할 수 있다는 장점이 존재했습니다.

그렇기 때문에 현재 프로젝트에서는 RestClient를 선택하게 되었습니다.

마무리

AI의 발전으로 인해 과거보다 훨씬 적극적으로 새로운 기술을 선택할 수 있는 환경이 되었다고 생각합니다. 예전에는 러닝 커브나 레퍼런스 부족 때문에 익숙한 기술을 우선적으로 선택하는 경우가 많았습니다.

만약 3년 전에 동일한 프로젝트를 진행했다면, 저 역시 RestClient보다는 기존에 많이 사용해왔던 RestTemplate를 선택했을 가능성이 높다고 생각합니다.

물론 RestTemplate를 사용하는 것이 잘못되었다는 의미는 아닙니다. 실제로 지금도 많은 프로젝트에서 안정적으로 사용되고 있는 기술입니다. 다만 현재 프로젝트에서는 Reactive 기반까지 사용할 필요는 크지 않았지만, 기존 RestTemplate보다는 조금 더 현대적인 방식으로 외부 API 호출 흐름을 관리하고 싶었습니다.

그 과정에서 RestClient는 RestTemplate의 직관적인 사용 방식은 유지하면서도, builder 기반의 현대적인 API 스타일을 제공한다는 점에서 현재 프로젝트와 가장 잘 맞는 선택이라고 느껴졌습니다.

결국 중요한 것은 최신 기술을 사용하는 것이 아니라, 현재 프로젝트의 목표와 환경에 가장 잘 맞는 기술을 선택하는 것이라고 생각합니다.

N-gram을 이용해서 새로운 데이터 만들기

klom — Sun, 17 May 2026 01:20:25 +0900

N-gram 이해해보기

TL;DR; N그램을 설명한 글입니다. LLM from Scratch - Part 1. Statistical Language Models[LLM 바닥부터 만들기 - 파트1. 통계적 언어 모델의 원리] 부담 없이 즐기며 배우는 LLM 입문 강의 오픈이벤트 50%할인! (~5

b-programmer.tistory.com

이전에 국립국어사전 데이터를 기반으로 N-gram을 적용한 적이 있습니다. 당시에는 총 548,385개의 단어를 추출하였으며, 한 글자 단어, 속담, 관용구, 구 형태의 표현, 신조어 등은 제외하였습니다. N-gram을 간단히 설명하자면, 이전 데이터(문맥)를 기반으로 다음에 어떤 데이터가 등장할지를 예측하는 방식입니다. 하지만 당시 실험을 진행하면서 한 가지 아쉬운 점이 있었습니다. 사전 중심으로 데이터를 구성하다 보니, 실제 LLM이 동작하는 방식과는 다소 거리가 있다고 느껴졌기 때문입니다. 실제 LLM은 단순 사전 데이터가 아니라, 문서와 문장 단위의 대규모 텍스트 데이터를 기반으로 학습이 이루어집니다. 그래서 이번에는 위키피디아와 같이 외부에 공개되어 있는 실제 문서 데이터를 기반으로 N-gram을 구성해보려고 합니다. 과연 실제 문서를 기반으로 새로운 문장을 생성했을 때, 얼마나 자연스럽게 동작할 수 있을까요? 그리고 어느 정도까지 문맥을 이해하는 것처럼 보일 수 있을까요?

이번에는 이를 직접 확인해보겠습니다.

위키 문서에서 문서를 추출해봅시다.

생각보다 학습에는 꽤 오랜 시간이 필요했습니다. 전체적으로 약 2~3시간 정도 문서를 수집하고 정리하는 작업이 진행된 것 같습니다. 문학 자료의 경우 약 1,531개를 추출하였으며, 비문학 자료는 무려 480,538개를 수집하였습니다. 데이터 출처는 주로 위키피디아와 위키문헌을 기반으로 구성하였습니다. 특히 비문학 자료는 수집된 문서 수 자체가 매우 많았기 때문에 데이터 정리와 전처리에 상당한 시간이 소요되었습니다. 반면 문학 자료의 경우에는 단순히 문서 수를 늘리는 것보다, 실제 순수 문학에 가까운 데이터만 남기기 위해 문학성이 낮거나 성격이 다른 자료들은 제외하는 방식으로 정리를 진행하였습니다.

테스트는 문학 자료를 중심으로 진행할 예정입니다. 특별한 이유가 있는 것은 아니며, 단순히 문학 문체에서 생성 결과가 어떻게 나타나는지 궁금했기 때문입니다.

문학 자료 일부분입니다.

이 데이터를 이용해서 uni-gram부터 N-gram까지 진행해보겠습니다. 문장이 최대한 자연스러워질때까지 진행할 거 같습니다.

테스트 시작

uni-gram

uni-gram부터 테스트를 진행해보겠습니다. 다만 uni-gram은 이전 문맥을 전혀 고려하지 않기 때문에, 사실상 자주 등장한 글자들을 기반으로 랜덤한 문자열을 생성하는 것에 가깝습니다. 즉, 어떤 글자가 얼마나 자주 등장했는지를 확인할 수는 있지만, 문맥 자체를 이해하지는 못하기 때문에 생성 결과에는 큰 의미가 없었습니다.

처음 테스트를 진행했을 때는 단어가 아니라 음절 단위로 계산하고 있었습니다. 하지만 음절 단위로 N-gram을 구성하게 되면, 이전에 사전 데이터를 기반으로 실험했던 방식과 큰 차이가 없다고 느껴졌습니다.

결국 실제 문장 흐름과 문맥을 조금 더 반영하기 위해서는 음절보다 단어 단위로 접근하는 것이 더 적절하다고 판단하였습니다. 그래서 여러 전처리 과정을 거친 뒤, 최종적으로 단어 기준으로 다시 계산을 진행하였습니다.

이것을 토대로 랜덤 문자열을 만들어보겠습니다.

역시 uni-gram은 순수하게 등장 빈도만 기반으로 랜덤 문자열을 생성하기 때문에, 실제로 생성된 결과가 무슨 의미인지 거의 이해할 수 없었습니다. 멀리서 보면 문장처럼 보이기는 합니다. 하지만 실제로 가까이에서 읽어보면 문맥과 의미가 전혀 이어지지 않는다는 것을 확인할 수 있었습니다. 게다가 문장의 종료 역시 일정한 규칙 없이 등장하였습니다. 즉, 모델이 문장의 흐름을 이해하고 마무리한다기보다, 단순히 등장 확률에 따라 종료 토큰이 우연히 선택되는 수준에 가까웠던 것입니다.

그렇다면 왜 이런 현상이 발생한 것일까요?

그 이유는 uni-gram이 앞뒤 문맥을 전혀 고려하지 않기 때문입니다. uni-gram은 단순히 각 단어가 얼마나 자주 등장했는지에 대한 빈도 정보만 알고 있을 뿐, 어떤 단어들이 서로 자연스럽게 연결되는지는 알 수 없습니다.

즉, 단어를 하나씩 무작위로 선택하게 되면 겉보기에는 한국어 단어들이기 때문에 문장처럼 보일 수는 있습니다. 하지만 실제로는 단어 사이의 관계가 존재하지 않기 때문에 의미를 이해할 수 없는 결과가 만들어지게 됩니다.

예를 들어 아무! 와 같이 어색한 위치에서 문장이 종료되는 것 역시 같은 이유입니다.

uni-gram은 <EOS>가 얼마나 자주 등장하는지는 알 수 있습니다. 하지만 어떤 단어 뒤에서 종료되어야 자연스러운지는 전혀 알지 못합니다. 결국 종료 토큰 역시 단순 확률에 의해 선택되기 때문에, 문장이 엉뚱한 위치에서 끝나는 현상이 발생하게 됩니다.

정리해보자면, uni-gram은 개별 단어의 등장 빈도만 학습하는 구조입니다. 그리고 n의 차원이 증가할수록 단순한 단어 나열에서 벗어나, 이전 문맥을 조금씩 따라가는 방향으로 발전하게 됩니다.

2-gram

이제 2-gram으로 만들어보겠습니다.

'하고'로 시작하는 문장은 총 24,520회 등장하였으며, 전체 데이터 기준 약 0.3%로 1위를 차지하였습니다. 생각보다 굉장히 흥미로운 결과였습니다. 아마 문장 사이를 이어주는 접속 표현이나 설명형 문장에서 자주 사용되었기 때문으로 보입니다.

그렇다면 이제 이 데이터를 기반으로 실제 랜덤 문자열을 생성해보겠습니다.
모델이 커서 그런지 생각보다 오래걸리는 군요. 앞으로 3,4,5,6,7도 진행해야 하는데 걱정이 되는군요... ㅠㅠ

uni-gram으로 생성했을 때와 비교하면 확실히 문장에 가까운 형태로 생성되는 것을 확인할 수 있었습니다. 실제로 단어들의 연결 역시 이전보다 훨씬 자연스러워졌습니다. 하지만 생성된 결과를 자세히 읽어보면, 여전히 전체적으로 무슨 이야기를 하고 싶은 것인지는 이해하기 어려웠습니다. 즉, 문장 형태는 어느 정도 따라가기 시작했지만, 아직 의미와 흐름까지 연결되지는 못한 상태에 가까웠습니다.

이제 조금씩 차원을 하나씩 더 올려보겠습니다.

3-gram

분포도

랜덤 문자열

4-gram

분포도

랜덤 문자열

4-gram까지 올리니 놀라운일이 발생하였습니다. 문장이 자연스럽게 이어졌습니다. 게다가 좀 짧은 문장들은 실제로 본문에서 찾아볼수 있었습니다. 예를 들어, '이번 사건은 나에게 가장 귀중한 교훈을 가르쳐 주었습니다'를 본문에서 조회를 해보면

실제로 생성된 결과 중 일부는 실제로 존재하는 문장이라는 것을 확인할 수 있었습니다. 다만 문장이 길어질수록 사전이나 원문 데이터에서 정확히 일치하는 결과는 거의 조회되지 않았습니다.

아마 문장이 길어질수록 단어 조합의 경우의 수가 급격하게 증가하기 때문으로 보입니다. 즉, 짧은 문장은 우연히 기존 데이터와 일치할 가능성이 있지만, 긴 문장은 새로운 조합으로 생성될 확률이 훨씬 높아지게 되는 것입니다.

5-gram

여기 부터는 원문을 더 많이 따라가는 구간으로 파일 크기와 희소성이 커지는 구간입니다.

희소성

가능한 조합의 수는 엄청나게 많지만, 실제로 관측된 조합은 극히 일부에 불과합니다.
예를 들어 2-gram은 다음과 같은 형태입니다.

나는 -> 갔다
나는 -> 보았다
나는 -> 말했다

즉, 앞 단어 1개만 참고하기 때문에 동일한 문맥이 여러 번 반복됩니다. 따라서 하나의 문맥에서 등장할 수 있는 다음 단어 후보 역시 비교적 다양하게 존재하게 됩니다. 하지만 5-gram은 이야기가 달라집니다.

그러나 은몽씨 나는 결코 -> 은몽씨가

이처럼 앞 단어 4개를 함께 참고하게 됩니다.
문제는 이런 긴 문맥 조합은 대부분 코퍼스 안에서 단 한 번만 등장하는 경우가 많다는 점입니다.
결국 모델은 다음과 같은 형태로 동작하게 됩니다.

그러나 은몽씨 나는 결코 -> 은몽씨가 (1회)
은몽씨 나는 결코 은몽씨가 -> 믿고 (1회)
나는 결코 은몽씨가 믿고 -> 있는것과 (1회)

이 상태가 되면 모델은 일반적인 패턴을 학습한다기보다, 원문 자체를 그대로 따라가는 방향에 가까워지게 됩니다.
정리해보면 다음과 같습니다.

N이 작다
- 문맥 정보는 약함
- 하지만 후보 수는 많음
- 따라서 이상한 조합이 자주 등장함
N이 크다
- 문맥 정보는 강함
- 하지만 후보 수는 매우 적음
- 결국 원문 암기에 가까워짐

즉, 5-gram에서 발생하는 희소성 문제(Sparsity)는 "앞 단어 4개가 동일한 경우" 자체가 거의 존재하지 않기 때문에, 다음 단어를 예측할 선택지가 급격하게 줄어드는 현상이라고 볼 수 있습니다.

분포도

랜덤 문자열

솔직히 말씀드리자면, 차원을 계속 증가시켜 6-gram, 7-gram, 8-gram … 11-gram까지 테스트하는 것은 큰 의미가 없다고 느껴졌습니다. 물론 문맥 정확도 자체는 계속 상승할 수 있습니다. 하지만 그만큼 희소성 문제 역시 더욱 심해지게 됩니다. 결국, 모델은 새로운 패턴을 예측한다기보다, 기존 원문을 그대로 외우고 재현하는 방향에 가까워지게 됩니다. 즉, 문맥을 일반화해서 이해하는 것이 아니라 긴 문자열 패턴 자체를 기억하는 형태가 되어버리는 것입니다. 이렇게 된다면 언어 모델이 가져야 하는 "새로운 문장을 생성하고 예측하는 능력"은 오히려 약해질 수 있다고 느껴졌습니다. 결국 단순히 N을 높이는 것만으로는 좋은 언어 모델이 만들어지는 것은 아니라는 점을 확인할 수 있었습니다.

결론

저번 시간에는 사전 데이터를 기반으로 N-gram을 실습해보았습니다. 하지만 실제 LLM은 단순 사전 데이터가 아니라, 실제 문서와 문장 데이터를 기반으로 학습이 이루어진다는 점에서 차이가 존재하였습니다. 그래서 이번에는 문학 데이터를 직접 수집하여 N-gram을 다시 실습해보았습니다. uni-gram부터 시작하여 5-gram까지 차례대로 실험을 진행해보니, 초반에는 새로운 문자열을 생성해내는 모습을 확인할 수 있었습니다. 하지만 단어의 위치와 문맥이 뒤죽박죽이었기 때문에, 실제로 읽어보면 무슨 의미인지 이해하기 어려운 경우가 대부분이었습니다. 반대로 차원을 계속 증가시키자 훨씬 자연스러운 문장이 생성되기 시작하였습니다. 하지만 이번에는 또 다른 문제가 발생하였습니다. 문장이 자연스러워질수록 새로운 문장을 생성한다기보다, 원문 자체를 그대로 따라가는 형태에 가까워졌기 때문입니다. 결국 희소성 문제(Sparsity) 역시 함께 증가하게 되었고, 모델은 점점 더 긴 패턴을 기억하는 방향으로 동작하게 되었습니다. 개인적으로는 이 부분이 굉장히 아이러니하게 느껴졌습니다. 일반적으로 LLM이라면 새로운 문장을 창조할 것이라고 기대하게 됩니다. 하지만 N을 계속 증가시키게 되면 오히려 창의성과는 점점 거리가 멀어지고, 학습 데이터를 재현하는 방향에 가까워졌기 때문입니다. 그렇다고 해서 차원을 낮추게 되면 이번에는 문맥 자체를 거의 이해하지 못한 채, 의미를 알 수 없는 문장들만 생성하게 됩니다. 제가 느끼기에는 이것이 N-gram의 가장 큰 한계처럼 보였습니다. 그럼에도 불구하고 데이터를 기반으로 다음 데이터를 예측한다는 핵심 아이디어 자체는 굉장히 흥미로웠습니다. 실제로 이후 등장한 다양한 언어 모델들 역시, 결국은 이전 문맥을 기반으로 다음 데이터를 예측한다는 방향성 자체는 이어지고 있다고 느껴졌습니다.

출처
https://www.honglab.ai/courses/llmpt1

마이바티스 매퍼 방식은 어떤것을 사용해야 할까?

klom — Sat, 16 May 2026 01:00:49 +0900

마이바티스에서는 SQL을 매핑하는 방식으로 크게 어노테이션 방식과 XML 방식을 제공하고 있습니다. 저는 이 중 어노테이션 방식을 선택하게 되었습니다. 가장 큰 이유는 멀티 모듈 구조에서 조금 더 관리하기 좋다고 느꼈기 때문입니다. 특히 어떤 기능이 어디에 존재하는지 추적하는 과정에서 어노테이션 방식이 더 직관적이라고 생각했습니다. 물론, 단점도 존재합니다. 복잡한 동적 쿼리를 작성하게 되면 XML 방식에 비해 불편함이 생길 수 있습니다. 그럼에도 불구하고 어노테이션 방식을 선택한 이유와, 왜 멀티 모듈 환경에서 잘 어울린다고 생각했는지 이번 글에서 정리해보려고 합니다.

어노테이션 방식은 어떻게 사용할까?

어노테이션 방식은 Mapper 인터페이스 위에 SQL을 직접 작성하여 사용하는 방식입니다.
기존 XML처럼 별도의 mapper.xml 파일을 생성하는 것이 아니라, 자바 코드 내부에서 SQL을 함께 관리하게 됩니다.

예를 들어 간단한 조회는 다음과 같이 작성할 수 있습니다.

빨간건 스키마가 없기때문이다. 예제라 스키마는 추가하지 않았다. 실제로 동작하는건 중요하지 않는다.

이렇게 작성하게 되면 Mapper 인터페이스만 확인해도 어떤 SQL이 실행되는지 바로 확인할 수 있습니다.
즉, XML 파일로 이동하지 않아도 되기 때문에 코드 흐름을 따라가기 조금 더 수월하다고 느껴졌습니다.

또한 멀티 모듈 환경에서는 mapper.xml 파일이 resources 하위로 분리되면서 위치를 추적해야 하는 경우가 생길 수 있습니다. 반면 어노테이션 방식은 인터페이스와 SQL이 함께 존재하기 때문에, 도메인이 증가하더라도 상대적으로 구조를 파악하기 쉽다고 느껴졌습니다.

다만 SQL이 길어질수록 가독성이 급격하게 떨어질 수 있다는 단점 역시 존재합니다.
특히 동적 쿼리가 많아질수록 XML 방식이 더 적합할 수 있기 때문에, 프로젝트 상황에 따라 혼합하여 사용하는 것도 고려할 수 있다고 생각합니다.

그래서 Annotation 방식을 선택한 이유가 무엇일까?

제가 생각하는 Annotation 방식의 가장 큰 장점은 바로 "추적"입니다. 만약, XML 방식으로 작성하게 된다면 아래와 같이 resources 하위에 mapper xml 파일이 생성됩니다.

그렇다면 user 도메인에 대한 매퍼를 찾는다고 가정해보겠습니다. 이 경우 app 영역에서는 자바 코드를 따라가다가, 실제 SQL을 확인하려면 다시 infrastructure 모듈의 resources 영역으로 이동해야 합니다. 특히 멀티 모듈 구조에서는 infrastructure 모듈에 여러 설정 파일과 라이브러리 관련 리소스가 함께 존재하는 경우가 많습니다. 즉, 개발자는 자바 코드와 resources 영역을 계속 오가며 흐름을 추적해야 합니다.

게다가 resources 영역에는 mapper xml 뿐만 아니라 application.yml 같은 설정 파일도 함께 존재합니다. 결국 도메인이 증가할수록 "어떤 기능이 어디에 존재하는지" 파악하는 비용 역시 함께 증가한다고 느꼈습니다. 반면 Annotation 방식은 인터페이스와 SQL이 함께 존재하기 때문에, 코드 흐름을 따라가기가 조금 더 직관적이라고 생각했습니다.

이러한 이유로 멀티 모듈 환경에서 마이바티스를 적용할 때 Annotation 방식을 선호하게 되었습니다.

하지만 여기서 한 가지 의문이 생깁니다.
최근에는 AI를 활용해 코드 흐름을 추적하는 경우가 많아졌습니다.
그렇다면 "추적이 쉽다"는 Annotation 방식의 장점은 이전보다 약해진 것이 아닐까요?

AI 입장에서는 SQL이 Annotation에 있든 XML에 있든, 관련 파일을 함께 읽어낼 수 있다면 큰 차이가 없을 수 있습니다.
그럼에도 불구하고 멀티 모듈 환경에서 Annotation 방식을 선택하는 것이 여전히 의미가 있을까요?

AI 시대에 이 선택이 여전히 의미가 있는가?

그럼에도 불구하고 의미는 있다고 생각합니다. 이유는 AI가 코드를 작성하고 리뷰를 도와주더라도, 최종적으로 그 코드를 판단하는 주체는 사람이기 때문입니다. AI는 XML과 Annotation을 모두 읽을 수 있지만, 사람은 최종 리뷰어로서 변경된 코드가 적절한지 확인해야 합니다.

이때 Annotation 방식은 Mapper 인터페이스와 SQL이 함께 존재하기 때문에, 리뷰하는 입장에서 변경 범위를 더 빠르게 파악할 수 있습니다. 즉, 단순히 "AI가 찾을 수 있느냐"의 문제가 아니라, 사람이 최종적으로 검토할 때 얼마나 적은 맥락 이동으로 판단할 수 있느냐의 문제라고 생각했습니다. 그래서 AI가 개발을 도와주는 환경에서도 Annotation 방식은 여전히 의미가 있다고 생각합니다.

특히, 멀티 모듈처럼 구조가 나뉘어 있는 환경에서는 코드와 SQL이 가까이 있는 것만으로도 최종 리뷰 비용을 줄일 수 있다고 느꼈습니다.

지금까지 멀티 모듈 환경에서 Annotation 방식을 선택한 이유에 대해 알아봤습니다.
그렇다면 이 선택을 하면서 어떤 것을 포기해야 할까요? Annotation 방식은 코드와 SQL을 가까이 둘 수 있다는 장점이 있지만, 그만큼 XML 방식이 가지고 있던 장점 일부를 내려놓아야 합니다. 특히 복잡한 동적 쿼리를 작성하거나 SQL을 별도로 관리해야 하는 상황에서는 Annotation 방식이 오히려 불편하게 느껴질 수 있습니다.

Annotation 방식을 선택하면 포기해야 하는 것들

그렇다면 XML 방식이 가장 강점을 가지는 부분은 무엇일까요?
바로 복잡한 SQL과 동적 쿼리를 관리하는 부분입니다.
특히 문자열 내부에 조건문이나 반복문이 계속 추가되는 구조에서는 Annotation 방식보다 XML 방식이 훨씬 깔끔하게 느껴질 수 있습니다. Annotation 방식 역시 동적 쿼리를 작성할 수는 있습니다. 하지만 문자열 내부에 다시 문자열을 작성해야 하는 구조가 반복되다 보니, 쿼리가 복잡해질수록 가독성이 빠르게 떨어질 수 있습니다.

반면 XML 방식은 SQL 자체를 분리해서 관리하기 때문에, 복잡한 쿼리일수록 오히려 구조를 파악하기 쉬워진다고 느꼈습니다.

여기서 선택지는 크게 두 가지가 있습니다.

첫 번째는 XML과 Annotation을 함께 사용하는 하이브리드 방식입니다.
단순한 쿼리는 Annotation으로 작성하고, 복잡한 동적 쿼리는 XML로 분리하는 방식입니다.

두 번째는 Annotation 방식을 유지하되, SQL Provider와 같은 별도의 클래스를 사용하는 방식입니다.
이 경우 기존 Mapper 인터페이스 안에서 모든 SQL을 처리하는 것이 아니라, SQL을 생성하는 책임을 다른 클래스로 분리하게 됩니다.

결국 Annotation 방식을 선택한다는 것은 단순히 XML을 사용하지 않는다는 의미가 아닙니다.
복잡한 쿼리가 등장했을 때, 그 복잡도를 어디로 옮길 것인지 함께 고민해야 한다는 의미에 가깝습니다.

이 글에서는 후자의 방법을 중심으로 고민해보려고 합니다.

Annotation 방식을 유지하면서도 복잡한 쿼리를 어떻게 다룰 수 있을지 살펴보고, 어느 정도 복잡도가 높아졌을 때 XML 방식을 고려해야 하는지도 함께 정리해보겠습니다.

Annotation 방식을 유지하면서 복잡한 쿼리를 다루는 방법

Annotation 방식을 살펴보기 이전에 XML은 어떻게 복잡한 쿼리를 다루는지 간단하게 알아봅시다.

이 코드는 CTE(WITH 절)와 서브쿼리를 이용해 사용자별 주문 합계를 구한 뒤, 주문 금액을 기준으로 오름차순 정렬하는 쿼리입니다.
그렇다면 이 쿼리를 Annotation 방식으로 작성하면 어떻게 될까요?

작성된 이 쿼리를 그대로 옮겨 보겠습니다.

이처럼 순수 SQL만 존재하는 경우에는 Annotation 방식에서도 거의 그대로 옮겨 사용할 수 있습니다.
다만 XML에서 사용하던 SQL을 그대로 복사하는 경우에는 XML 엔티티 escape를 확인해야 합니다. 예를 들어, >는 >로, <는 <로 변경해줘야 합니다. 즉, XML 내부에서 사용하던 쿼리를 Annotation 방식으로 옮길 때는 단순히 복사해서 붙여넣는 것이 아니라, XML 엔티티 escape가 남아 있지는 않은지 확인하는 과정이 필요합니다.

하지만, <if> <foreach> <where>을 사용하는 경우에는 어떨까요?

이처럼 조건에 따라 SQL이 동적으로 변경되는 쿼리를 동적 쿼리라고 합니다.
마이바티스 XML 방식에서는 if, choose, foreach 같은 태그를 이용해 이러한 동적 쿼리를 처리할 수 있습니다.
그렇다면, Annotation 방식에도 똑같이 적용해보겠습니다.

하지만 XML에서 사용하던 태그를 Annotation 방식에 그대로 옮기자 컴파일 예외가 발생했습니다. 그렇다면 왜 Annotation 방식에서는 XML 태그를 그대로 사용할 수 없을까요? 근본적인 이유는 Annotation 방식은 문자열이고, XML 방식은 문서 구조이기 때문입니다.

XML 방식에서는 <if>, <foreach> 같은 태그 자체가 XML 구조의 일부로 인식됩니다. 그래서 마이바티스가 해당 태그를 읽고 동적 SQL로 변환할 수 있습니다. 반면, Annotation 방식에서는 SQL이 단순 문자열로 전달됩니다. 즉, <if> 같은 내용이 들어가더라도 구조가 아니라문자열로 취급되기 때문에 그대로 해석할 수 없습니다.

문자열은 취급할 수 없는 이유

그렇다면, 문자열로 취급을 하면 어째서 해석하지 못하는 걸까요? 문자열은 단순 데이터이기 때문입니다.
예를 들어 Annotation 방식에서는 SQL이 아래처럼 자바 문자열로 전달됩니다.

java
@Select("select * from user")

즉, 자바 입장에서는 이것을 단순한 문자 집합으로만 인식합니다. <if> 역시 마찬가지입니다.

@Select("<if test='id != null'> ... </if>")

이렇게 작성하더라도 자바는 이것이 조건문 구조인지 알지 못합니다. 그냥 <, i, f 로 이루어진 문자열일 뿐입니다.반면, XML 방식에서는 <if>가 문자열이 아니라 XML 문서의 태그 구조로 존재합니다. 그래서 마이바티스가 XML을 파싱하면서 이건 조건문이구나라고 해석할 수 있습니다. 즉, 핵심은 단순합니다. 문자열은 의미를 가지지 않지만, XML 태그는 구조를 가지기 때문에 마이바티스가 동적 SQL로 해석할 수 있는 것입니다.

그렇다면, Annotation방법을 사용할때는 동적 쿼리를 사용하지 못할까요?

다행스럽게도 Annotation 방식에서도 동적 쿼리를 사용할 수 있습니다.

다만 XML 방식처럼 태그를 바로 사용하는 것이 아니라, 마이바티스가 동적 SQL로 해석할 수 있는 형태로 만들어줘야 합니다.

그 과정에 대해 조금 더 자세히 확인해보겠습니다.

마이바티스에서는 이러한 문제를 Provider를 통해 해결할 수 있습니다.
기존 Mapper 인터페이스 내부에 모든 SQL을 작성하는 것이 아니라, 별도의 클래스에서 동적 SQL을 생성하도록 분리하는 방식입니다.

즉, Annotation 방식은 유지하면서도 복잡한 동적 쿼리를 처리할 수 있도록 만들어주는 구조라고 볼 수 있습니다.

즉, Annotation 방식을 유지하면서도 복잡한 동적 쿼리를 처리할 수 있도록 만들어주는 구조라고 볼 수 있습니다. 코드를 확인해보면 SQL 객체를 생성한 뒤, SELECT, FROM, WHERE 절에 해당하는 메소드를 사용하는 것을 볼 수 있습니다. 또한, 자바 코드 기반으로 동작하기 때문에, 전달받은 파라미터 값을 기준으로 조건을 분기하여 동적 쿼리를 구성할 수 있습니다.

하지만 이것은 실제 SQL 자체가 아닙니다. 정확히는 SQL을 생성하기 위한 Provider 클래스에 가깝습니다.
그렇다면 이렇게 생성한 SQL은 어디에서 사용되는 것일까요? 마이바티스는 Mapper 인터페이스에서 Provider 클래스를 참조하여, 실행 시점에 동적으로 SQL을 생성한 뒤 실제 쿼리로 변환하여 사용하게 됩니다.

이를 해석해보면 @SelectProvider를 통해 Provider 클래스가 생성한 SQL을 실행하라는 의미입니다. 즉, Mapper 인터페이스 내부에서 직접 SQL을 작성하는 것이 아니라, 별도의 Provider 클래스에서 생성한 SQL을 가져와 실행하는 구조라고 볼 수 있습니다.

다시 코드를 자세히 확인해보면 문장 끝마다 `;`를 붙이고 있는 것을 볼 수 있습니다. 즉, 결국 SQL을 문자열이 아닌 자바 코드 형태로 조합하고 있다는 뜻입니다. 이 때문에 조건이 많아지고 쿼리 복잡도가 올라갈수록 가독성이 빠르게 떨어질 수 있습니다. 특히 단순 SQL이 아니라 여러 조건과 분기가 추가되기 시작하면, 실제 SQL을 작성하는 것보다 자바 문법을 맞추는 데 더 집중하게 되는 경우도 발생할 수 있습니다.

현재 수준의 복잡도에서는 충분히 사용할 수 있는 방식이라고 느껴졌습니다. 하지만 쿼리 복잡도가 계속 증가하는 경우에는 Annotation 방식만 고집하기보다는, XML 방식을 함께 사용하는 하이브리드 구조 역시 고려할 필요가 있다고 생각합니다. 특히 동적 조건이 많아지고 SQL 길이가 길어질수록 XML 방식이 오히려 더 읽기 쉽고 유지보수에 유리할 수 있습니다.

결론

특정 구조나 기술을 선택할 때는 단순히 유명한 기술인가를 보는 것이 아니라, 왜 이 구조를 선택했는지와 어떤 트레이드오프가 존재하는지를 함께 고민해야 한다고 생각합니다. 저 역시 SQL 매퍼 기술을 선택하는 과정에서 ORM인 JPA 대신 마이바티스를 선택하였습니다. 그 이유는 현재 프로젝트에서는 마이바티스가 JPA보다 SQL 흐름을 직접 제어하고 접근하기 더 쉽다고 느꼈기 때문입니다. 또한 프로젝트 구조를 멀티 모듈로 구성하였기 때문에, Annotation 방식이 XML 방식보다 더 잘 맞는다고 생각하였습니다. 같은 Java 코드 흐름 안에서 SQL을 함께 관리할 수 있기 때문에, 구조를 추적하고 흐름을 이해하기 조금 더 직관적이라고 느꼈습니다. 하지만 동적 쿼리를 작성하기 시작하면서 문제 역시 존재하였습니다. 복잡한 조건이 증가할수록 XML 방식보다 Annotation 방식의 복잡도가 더 빠르게 증가하였기 때문입니다.
그럼에도 불구하고 Annotation 방식을 선택한 이유는, 동적 쿼리를 작성하는 복잡성보다 프로젝트 전체 흐름을 추적하고 제어하는 것이 더 중요하다고 판단하였기 때문입니다. 물론, 프로젝트 규모와 복잡도에 따라 XML 방식이 더 적절한 상황 역시 충분히 존재할 수 있습니다. 결국 중요한 것은 어떤 방식이 무조건 더 좋다가 아니라, 현재 프로젝트 구조에서 어떤 방식이 더 적절한지를 계속 고민하는 것이라고 생각합니다.

N-gram 이해해보기

klom — Thu, 14 May 2026 00:12:24 +0900

TL;DR; N그램을 설명한 글입니다.

LLM from Scratch - Part 1. Statistical Language Models

[LLM 바닥부터 만들기 - 파트1. 통계적 언어 모델의 원리] 부담 없이 즐기며 배우는 LLM 입문 강의 오픈이벤트 50%할인! (~5/17이후 가격이 인상됩니다.)

www.honglab.ai

N-gram의 아이디어는 1948년 Claude Shannon 의 정보이론 논문에서 시작되었습니다. 핵심은 단순합니다. "다음 글자를 이전 글자를 기반으로 예측할 수 있지 않을까?" 라는 아이디어였습니다. 이후 1980년대에 들어서며 컴퓨터 성능이 발전하였고, 이러한 통계 기반 언어 모델을 실제로 활용할 수 있는 환경이 만들어지기 시작하였습니다. 그렇게 N-gram은 음성 인식, 자동 완성, 기계 번역과 같은 다양한 자연어 처리 분야에서 활용되기 시작하였습니다. 현대의 LLM은 N-gram보다 훨씬 복잡한 구조를 사용하지만, "이전 문맥을 기반으로 다음 단어를 예측한다"는 핵심적인 방향성 자체는 크게 다르지 않습니다. 그렇다면 이런 의문이 들 수 있습니다. "이렇게 단순한 아이디어인데, 왜 실제로 이해하고 학습하는 것은 어려울까?" 겉으로 보면 단순히 다음 단어를 연결하는 방식처럼 보입니다. 하지만 N이 증가할수록 경우의 수가 급격하게 증가하게 되고, 데이터 부족 문제 역시 함께 발생하게 됩니다.

이번 글에서는 N-gram이 어떤 방식으로 동작하는지, 그리고 왜 단순해 보이는 구조가 생각보다 복잡한 문제를 가지게 되는지 확인해보겠습니다.

그래서 N그램이 뭔데?

N-gram은 이전 글자를 기반으로 다음 글자를 예측하는 방법입니다. 예를 들어 토큰이 가 → 나 → 다 이렇게 존재한다고 가정해봅시다. 그렇다면 가 다음에는 무엇이 올까요? 바로 나입니다. 그렇다면 나 다음에는 무엇이 올까요? 바로 다입니다.

즉, 핵심은 단순합니다. 이전에 등장한 패턴을 기반으로 다음 글자를 예측하는 것입니다. 하지만 여기서부터 헷갈리기 시작합니다.

"AI는 이런 단순한 연결만 보고 어떻게 학습한다는 거지?"

실제로 N-gram은 우리가 생각하는 것보다 훨씬 단순한 구조입니다. 문장을 이해한다기보다, 이전에 등장했던 패턴과 확률을 기반으로 다음 글자를 이어붙이는 방식에 가깝습니다.

지금 예시는 하나의 경우만 존재하기 때문에 단순해 보입니다. 하지만 경우의 수가 수십, 수백 개로 증가한다면 이야기는 달라집니다.

그렇다면 이런 의문이 들 수 있습니다. "모든 경우를 전부 조합해서 계산하는 것일까?"

결론부터 말하면 완전히 틀린 생각은 아닙니다. 실제로 N-gram은 이전에 등장했던 패턴들을 저장하고, 현재 상태에서 다음에 등장할 가능성이 높은 토큰을 찾아 이어붙이는 방식에 가깝습니다. 즉, 문장을 이해한다기보다 이전에 등장했던 연결 관계를 기반으로 다음 토큰을 예측하는 구조라고 볼 수 있습니다.

아니 잠깐만 이거 끝말잇기랑 유사한 느낌인데...

N-gram은 현재 상태에서 다음에 등장할 가능성이 높은 토큰을 찾아 이어붙이는 방식이라고 하였습니다. 그렇다면 우리가 익숙하게 알고 있는 '끝말잇기'와 비슷한 느낌이라고 볼 수도 있지 않을까요?

출처: https://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:%EB%81%9D%EB%A7%90%EC%9E%87%EA%B8%B0.png

예를 들어 끝말잇기 역시 현재 단어를 기준으로 다음에 어떤 단어가 이어질 수 있는지를 생각하게 됩니다. 만약 다음에 등장할 가능성이 높은 단어들을 어느 정도 예측할 수 있다면, 게임을 훨씬 유리하게 풀어나갈 수 있을 것입니다.
N-gram 역시 이와 유사하게 이전에 등장했던 패턴들을 기반으로 다음 토큰을 예측하는 방식이라고 볼 수 있습니다.

이 개념을 조금 더 직관적으로 이해하기 위해, 저는 우리말샘 + 표준국어대사전 + 한국어기초사전에서 총 548,385개의 단어를 추출하였습니다. 여기에는 한 글자 단어, 속담, 관용구, 구 형태의 표현은 제외하였으며, 최근 등장한 일부 신조어 역시 포함되지 않았습니다.

그렇다면 이 단어들을 기반으로 N-gram이 어떤 방식으로 동작하는지 직접 확인해봅시다.

저희는 현재 끝말잇기를 기반으로 N-gram을 이해하려고 하기 때문에, 먼저 가 ~ 힣까지 어떤 글자들이 얼마나 등장하는지 빈도수를 확인해보겠습니다.

1 - gram(Unigram)

빈도수를 확인해보니, 다가 포함된 단어는 전체의 약 5%를 차지하고 있었습니다.

반면 힗, 힡과 같은 글자는 단 1회만 등장하였으며, 비율로 보면 약 0.0001% 수준에 불과하였습니다.
일단 이 방식이 얼마나 효과적인지 확인하기 위해, 무작위 문자열을 생성해 보겠습니다.

단어를 무작위로 조합해 보았지만, 사전 기준으로는 의미를 가지지 않는 문자열이 대부분이었습니다.
즉, 단순히 글자를 이어 붙인다고 해서 자연스러운 단어가 만들어지는 것은 아니었습니다. 그렇다면 이런 의문이 들 수 있습니다.

"의미는 없더라도, 실제 한국어 단어에서 자주 나타나는 글자 배열을 따라가면 더 자연스러운 문자열을 만들 수 있지 않을까?"

이제부터는 실제 단어에서 나타나는 글자 패턴과 빈도수를 바탕으로, 무작위 문자열이 얼마나 단어처럼 보이도록 생성될 수 있는지 확인해 보겠습니다. 이거에 대한 아이디어가 바로 N-gram입니다.

2-gram (bi-gram)

그렇다면 같은 방식으로 2-gram(Bigram)으로 만들면 어떻게 변할까요?

이제부터는 단순히 글자의 등장 횟수만 보는 것이 아니라, 현재 글자 다음에 어떤 글자가 자주 등장하는지 함께 확인하게 됩니다. 즉, 이전 글자 1개를 기반으로 다음 글자를 예측하는 방식으로 변경됩니다. 결과는 다음처럼 나왔습니다.

'다'를 기준으로 다시 비교해보면, 기존에는 약 5%의 비율을 차지하고 있었지만 2-gram(Bigram)에서는 약 3% 수준으로 감소한 것을 확인할 수 있었습니다. 왜 이런 차이가 발생한 것일까요?

실제로 생성된 문자열을 확인해보니 EOS, BOS와 같은 특수 문자가 함께 포함되어 있는 것을 발견할 수 있었습니다.

BOS(Beginning Of Sequence) : 문자열의 시작을 의미
- 예: _다, _라, _가
EOS(End Of Sequence) : 문자열의 끝을 의미
- 예: 다_, 라_, 가_

즉, 2-gram부터는 단순히 글자 자체만 보는 것이 아니라, 앞뒤 위치 정보까지 함께 고려하게 됩니다. 따라서 기존에는 단순 포함 기준으로 계산되던 다의 비율이, 실제 문맥 기준으로 다시 계산되면서 비율 차이가 발생하게 된 것입니다.

그렇다면, 2-gram을 이용해서 무작위 문자열을 만들어보겠습니다.

1-gram과의 가장 큰 차이점은 시작 지점과 종료 지점이 존재한다는 점입니다. 즉, <BOS>에서 시작하여 <EOS>로 종료되는 구조를 가지게 됩니다. 아직은 왜 이런 차이가 발생하는지 직관적으로 이해되지 않을 수 있습니다. 하지만 실제로 생성된 문자열을 확인해보면, 1-gram에 비해 훨씬 실제 단어와 비슷한 형태가 등장하는 것을 확인할 수 있었습니다.

여기서 한 가지 의문이 들었습니다. "왜 1-gram은 최대 길이를 6자리로 제한했을까?"

그 이유는 너무 짧게 생성할 경우, 1-gram 역시 우연히 실제 사전에 존재하는 단어가 등장할 가능성이 높아지기 때문입니다. 즉, 모델이 자연스럽게 생성한 것인지, 단순히 짧아서 우연히 맞아떨어진 것인지 구분하기 어려워집니다.

따라서 조금 더 명확하게 차이를 확인하기 위해 1-gram은 최대 6자리로 고정하여 비교를 진행하였습니다. 참고로 2-gram 또한 max는 6자리입니다.

실제로 생성된 결과를 사전과 비교해보니, 100개의 문자열 중 27개가 실제 사전에 등재된 단어인 것을 확인할 수 있었습니다. 단순히 글자의 등장 빈도만 기반으로 생성하였음에도 생각보다 실제 단어가 꽤 많이 등장한 것입니다.

즉, 완전히 의미를 이해하지 못하더라도 자주 등장하는 글자 패턴만으로도 어느 정도 자연스러운 문자열이 만들어질 수 있다는 사실을 확인할 수 있었습니다.

정확도를 높이기 위해 gram의 차원을 높인다?

여기서 알 수 있었던 점은, gram의 차원이 높아질수록 생성 결과의 정확도 역시 함께 높아진다는 사실이었습니다. 실제로 N 값을 증가시키면 이전 문맥을 더 많이 참고하게 되기 때문에, 생성되는 문자열 역시 훨씬 자연스러워지는 경향이 있습니다.

하지만 무조건 높다고 좋은 것은 아니었습니다. 차원이 지나치게 증가하게 되면 학습 데이터에 존재하지 않는 문맥에서는 제대로 동작하지 못하게 됩니다. 또한 새로운 패턴을 생성하기보다는, 학습했던 문자열 자체를 그대로 기억하는 방향에 가까워질 수 있습니다. 즉, 문맥을 일반화해서 이해한다기보다 단순히 긴 패턴을 외워버리는 형태에 가까워지는 것입니다.

왜 이런 현상이 발생할까요?

N이 증가할수록 경우의 수 역시 함께 폭발적으로 증가하기 때문입니다.

예를 들어 다음과 같이 문맥을 기억한다고 가정해봅시다.

2-gram: 하 → 다
3-gram: 사랑 → 하
4-gram: 사랑하 → 다
5-gram: 사랑하다 → <EOS>

이처럼 N이 증가할수록 더 긴 문맥과 구체적인 패턴을 함께 참고하게 됩니다. 문제는 문맥이 지나치게 구체적이 되면, 학습 데이터에서 단 한 번도 등장하지 않은 조합들이 급격하게 많아진다는 점입니다.

이를 Sparsity(희소성 문제)라고 합니다.

예를 들어 다음과 같은 문맥이 존재한다고 가정해봅시다.

므쀍졀

이런 조합은 실제 학습 데이터에 존재하지 않을 가능성이 매우 높습니다. 그렇다면 모델은 다음 글자를 예측할 수 없게 됩니다.
결국 N을 증가시키면 다음과 같은 현상이 동시에 발생하게 됩니다.

문맥 정확도 증가
하지만 데이터 커버리지 감소

즉, 더 자연스러운 결과를 만들 수는 있지만, 반대로 학습 데이터에 없는 새로운 문맥에는 점점 더 약해지게 되는 것입니다. 결국 문맥을 일반화하여 예측하는 모델이라기보다, 학습 데이터를 기억하고 재현하는 방향에 가까워지게 됩니다. 그렇다면, 2-gram까지 진행해봤는데 3,4,5,6까지 진행하면서 한번 몸소 느껴봅시다.

3-gram 부터는 빠르게 진행이 되어집니다.

3-gram

count

ramdom 문자열

확실히 단어의 길이가 줄었다는 것을 알 수 있습니다. 확률도 100개중에 71개가 실제로 사전에 존재하는 단어입니다.

4-gram

5-gram

99/100

마지막 6-gram

놀라운 점은 5-gram과 6-gram의 확률 결과가 거의 동일하게 나타났다는 사실이었습니다. 즉, 문맥을 하나 더 늘렸음에도 생성 결과에는 큰 차이가 발생하지 않았습니다.

또한 이번에는 문자열 길이를 6자리로 제한하였기 때문에, 생성된 100개의 결과 중 무려 98개가 실제 사전에 등재된 단어인 것을 확인할 수 있었습니다.

이는 N이 증가할수록 모델이 새로운 패턴을 생성하기보다, 학습 데이터에 존재했던 문자열 자체를 그대로 재현하는 방향에 가까워지고 있다는 점을 보여주는 결과라고 볼 수 있습니다.

N-gram의 차수를 증가시킬수록 저장해야 하는 글자 조합의 수 역시 함께 증가하였습니다. 실제로 2-gram counts 파일은 약 5.6MB 수준이었지만, 6-gram counts 파일은 약 66.4MB까지 증가한 것을 확인할 수 있었습니다.

즉, 더 긴 문맥을 참고할수록 생성 결과는 더욱 자연스러워질 수 있었지만, 반대로 저장해야 하는 패턴 수 역시 급격하게 증가하게 됩니다. 결국 문맥 정확도를 높이기 위해서는 그만큼 더 많은 저장 공간과 계산 비용이 필요하게 되는 것입니다.

마무리

LLM의 예측 방식과 연결되는 개념 중 하나인 N-gram에 대해 알아보았습니다. 핵심은 이전 문맥을 기반으로 다음에 어떤 문자가 등장할지를 예측하는 구조였습니다. 실제로 N의 차원이 증가할수록 생성 결과는 더욱 자연스러워졌습니다. 하지만 반대로 문맥이 지나치게 길어질 경우, 새로운 패턴을 예측하는 것인지, 아니면 학습 데이터를 그대로 외워서 재현하는 것인지 구분하기 어려워지는 문제 역시 함께 확인할 수 있었습니다. 또한 차원이 증가할수록 경우의 수와 저장해야 하는 패턴 역시 함께 폭발적으로 증가하였고, 결국 희소성 문제(Sparsity) 역시 발생하게 되었습니다. 물론 이번 실험은 어디까지나 N-gram의 동작 원리를 이해하기 위한 단순화된 방식에 가깝습니다. 실제 LLM은 단순히 문자열 패턴만 저장하는 것이 아니라, 훨씬 복잡한 구조를 기반으로 문맥과 의미를 함께 처리합니다. 다음에는 실제 문서를 학습시켜 새로운 문장을 생성하는 방식에 대해 조금 더 깊게 확인해보겠습니다.

그레들DSL은 어떤것을 사용해야 할까?

klom — Sun, 10 May 2026 21:19:36 +0900

최근에 입사한 회사에서 새로운 프로젝트를 도입하려 하였습니다. 기존의 단일 모듈 기반 controller - service - repository 구조가 아닌 멀티 모듈 구조로 도입하기로 결정하였습니다. 멀티 모듈로 결정한 이유는 역할별 책임을 분리하여 이후 변경 범위를 줄이고 유지보수를 용이하게 만들기 위함입니다. 또한 도메인과 인프라를 분리함으로써 구조적인 의존성을 조금 더 명확하게 관리할 수 있다고 여겨졌습니다.

빌드 툴은 메이븐이 아닌 그레들로 결정하였습니다. 그레들로 결정한 이유는 확장성과 유지보수성 때문입니다. 특히 멀티 모듈 환경에서는 공통 설정 관리와 유연한 빌드 구성이 중요하다고 판단하였고, 이러한 부분에서 그레들이 조금 더 적합하다고 느껴졌습니다.

그레들로 결정하고 보니 메이븐처럼 XML 하나로 관리되는 방식과 달리, 그레들은 빌드 스크립트를 작성하는 방식으로 코틀린 DSL과 그루비 DSL이 존재하였습니다. 그렇다면 어떤 방식이 좋고, 어떤 기준으로 결정해야 할까요?

이번 글에서는 그레들에서 제공하는 코틀린 DSL과 그루비 DSL을 비교해보며 어떤 방식이 조금 더 적절한지 고민해보겠습니다.

코틀린 DSL? 그루비 DSL? 왜 구분을 지을까?

들어가기 앞서 그레들은 어째서 DSL을 두 가지나 지원하는지에 대해 고민해봅시다.

기존에는 그루비 DSL만 존재하였습니다. 하지만 어느 순간부터 코틀린 DSL이 추가되었습니다. 그렇다면 어째서 그레들은 코틀린 DSL을 추가하였을까요? 단순히 새로운 기술이 등장했기 때문만은 아니라고 여겨집니다.

기존 그루비 DSL은 동적 타입 기반이다 보니 자유롭게 작성할 수 있다는 장점이 존재하였습니다. 하지만 반대로 IDE 자동완성이나 타입 안정성과 같은 부분에서는 아쉬움이 존재하였습니다.

반면 코틀린 DSL은 정적 타입 기반으로 동작합니다. 그렇기 때문에 IDE 지원이나 자동완성, 컴파일 단계에서의 검증과 같은 부분에서 조금 더 안정적으로 사용할 수 있습니다.

그렇다면 얼마나 효과가 있을까요?

확인해보니 코틀린 DSL이 무조건적으로 좋은 것은 아니었습니다. 오히려 빌드 성능 자체는 그루비 DSL이 유리한 경우도 존재하였습니다.대표적으로 Gradle 공식 이슈에서는 실제 성능 비교 자료를 공개한 적이 있습니다. 해당 자료는 Gradle 8.1 기준으로 작성된 결과이며, 현재 버전과는 약간의 차이가 존재할 수 있습니다..

https://github.com/gradle/gradle/issues/15886#issuecomment-1432923669

아쉽게도 현재 최신 버전인 Gradle 9.X 기준으로 직접 비교한 공식 성능 자료는 공개되어 있지 않습니다.
다만 Gradle 공식 자료에서는 코틀린 DSL recompilation avoidance와 관련하여 일부 상황에서 약 2.5배 정도 개선되었다고 설명하고 있습니다. (그루비 DSL와 코틀린DSL의 비교가 아닙니다. Gradle 8.2 -> Gradle 9.0에 대한 개선입니다.)

Gradle | What's new in Gradle 9.0.0

Gradle 9.0.0 is a new major release which incorporates many features since the version 8.0. It makes Gradle configuration cache the preferred execution mode, provides more clean and actionable error reporting, and also updates Gradle to Kotlin 2 and Groovy

gradle.org

그럼에도 불구하고 현재도 순수 빌드 성능만 보면 상황에 따라 그루비 DSL이 조금 더 유리한 경우가 존재한다고 합니다.

그렇다면 어째서 많은 기업들이 코틀린 DSL을 선택하는 것일까요?

대표적으로 IDE 자동완성, 타입 안정성, 리팩토링 안정성, 대규모 멀티 모듈 유지보수와 같은 부분 때문이라고 합니다. 실제로 Gradle 역시 8.2 버전부터 코틀린 DSL을 기본 생성 방식으로 변경하였습니다.

즉 핵심은 단순합니다.

코틀린 DSL은 빌드 성능을 극적으로 개선하기 위한 목적보다는, 조금 더 안정적이고 유지보수하기 쉬운 빌드 스크립트를 만들기 위해 등장하였습니다.

정리하자면, 상황에 따라 빌드 성능은 그루비 DSL이 유리한 경우도 존재하였습니다. 반면 코틀린 DSL은 IDE 지원과 타입 안정성을 기반으로 유지보수에 조금 더 초점을 맞춘 방식이라고 느껴졌습니다.

그렇다면 실제로는 어떤 차이가 존재할까요?

개념적으로 보면 유지보수성과 타입 안정성이라는 차이로 정리할 수 있었습니다. 하지만 단순히 설명만으로는 크게 와닿지 않았습니다. 아무래도 실제 코드로 확인하지 못했기 때문이라고 여겨졌습니다. 이번에는 조금 더 문법적인 부분에서 차이를 확인해보겠습니다.

문법적인 차이는?

위에서 그루비 DSL과 코틀린 DSL을 비교하였을 때, 자동완성, 타입 안정성, 리팩토링 안정성, 대규모 멀티 모듈 유지보수와 같은 부분들이 코틀린 DSL의 강점이라고 하였습니다.

하지만 자동완성의 경우에는 IDE의 발전으로 인해, 이제는 코틀린 DSL만의 강점이라고 말하기에는 애매하다고 느껴졌습니다.
실제로 그루비 DSL 역시 IDE에서 자동완성을 어느 정도 지원하고 있기 때문입니다.
그렇다면 코틀린 DSL의 장점은 어디에서 더 명확하게 드러날까요?

개인적으로는 타입 안정성, 리팩토링 안정성, 그리고 대규모 멀티 모듈 유지보수 측면에서 차이가 조금 더 드러난다고 느껴졌습니다.

그루비 DSL은 동적 타입 기반이기 때문에 유연하게 작성할 수 있다는 장점이 존재합니다. 하지만 그만큼 잘못된 설정이 작성되었을 때 실행 시점에서 확인되는 경우가 존재할 수 있습니다.

반면 코틀린 DSL은 정적 타입 기반으로 동작하기 때문에, 잘못된 설정을 작성했을 때 IDE나 컴파일 단계에서 더 빠르게 확인할 수 있습니다. 또한 타입 기반으로 코드 탐색이나 리팩토링이 가능하기 때문에, 모듈 수가 많아지고 설정이 복잡해질수록 유지보수 측면에서 조금 더 안정적으로 사용할 수 있다고 여겨졌습니다.

코틀린 DSL의 타입 안정성

플러그인 선언

그루비 DSL은 플러그인을 지정할 때 id를 이용하여 문자열 형태로 등록합니다.
반면 코틀린 DSL은 다음과 같이 바로 사용할 수 있습니다.

처음에는 단순히 문법 차이처럼 보였습니다. 하지만 자세히 보면 코틀린 DSL의 java는 단순 문자열이 아니라 타입 안전한 accessor로 동작합니다. 즉 문자열 기반으로 처리되는 것이 아니라, IDE와 Gradle이 인식할 수 있는 형태로 제공된다는 차이가 존재하였습니다.
그렇기 때문에 잘못된 값을 사용하거나 존재하지 않는 설정을 작성했을 때 IDE나 컴파일 단계에서 조금 더 빠르게 확인할 수 있습니다.

java toolChain

이 부분에서 코틀린 DSL의 장점이 드러난다고 합니다. 그루비 DSL에서는 다음과 같이 설정할 수 있습니다.

반면 코틀린 DSL은 다음과 같이 작성합니다.

처음 보았을 때는 오히려 코틀린 DSL쪽이 더 복잡하게 느껴졌습니다. set()과 같은 코드가 추가되다 보니 뭔가 덕지덕지 붙은 느낌도 존재하였습니다. 그렇다면 어째서 이것이 코틀린 DSL의 장점이라고 말하는 것일까요?

가독성만 보면 오히려 그루비 DSL이 더 좋아 보였습니다. 하지만 차이는 값을 어떻게 다루는지에 존재하였습니다.

그루비 DSL은 동적 타입 기반이다 보니 비교적 자유롭게 값을 설정할 수 있습니다. 반면 코틀린 DSL은 languageVersion이 어떤 타입인지 알고 있으며, 정해진 API를 통해 값을 설정하도록 구성되어 있습니다.

즉 단순히 문법이 길어진 것이 아니라, 그레들 API를 타입 기반으로 조금 더 안전하게 다루도록 변경된 것입니다.

gradle api

즉, 코틀린 DSL은 단순 문자열 기반으로 동작하는 것이 아니라, Gradle API를 타입 기반으로 직접 활용하고 있다는 것을 알 수 있습니다.

Task 타입 지정

간략하게 task가 어떤것인지 부터 이해를 해봅시다.

그레들에서 Task는 하나의 작업 단위를 의미합니다. 쉽게 말해 Gradle이 수행하는 기능 하나하나를 Task라고 볼 수 있습니다.
예를 들어 프로젝트 컴파일, 테스트 실행, JAR 생성, 애플리케이션 실행등과 같은 작업들이 모두 Task로 동작합니다.
실제로 build 역시 내부적으로 여러 Task를 실행하면서 동작합니다.
즉, 그레들은 단순히 코드를 빌드하는 도구가 아니라, 여러 작업(Task)을 조합하여 실행하는 구조라고 볼 수 있습니다.

그루비 DSL에서는 다음과 같이 작성합니다.

테스트 실행 환경 공통 설정

반면 코틀린 DSL은 다음과 같이 작성합니다.

테스트 실행 환경 공통 설정

처음 보았을 때는 단순히 문법 차이처럼 느껴졌습니다. 하지만 코틀린 DSL은 Test 타입의 task만 대상으로 지정하고 있다는 차이가 존재하였습니다. 즉, Gradle이 현재 블록이 Test 타입이라는 것을 명확하게 알고 있기 때문에, 해당 타입에서 사용할 수 있는 API들을 IDE가 조금 더 안정적으로 인식할 수 있었습니다.
결국 코틀린 DSL은 단순히 문법이 다른 것이 아니라, Gradle API를 명확한 타입 기반으로 직접 다루고 있다는 특징이 존재하였습니다.

의존성 선언은 타입 안정성

이 부분은 다른 분들과 달리 타입 안정성이 떨어지는 편입니다. 왜냐하면

각기 다른 프로젝트입니다.

여전히 문자열 기반으로 의존성을 선언하고 있다는 점도 확인할 수 있었습니다. 그렇다는 것은 의존성 이름이나 버전에 오타가 발생하더라도 컴파일 단계에서 바로 확인되는 것이 아니라, 의존성을 해석하는 시점에서 실패할 수 있다는 의미입니다.

물론 이를 보완하기 위한 다양한 방법들도 존재하였습니다. 하지만 이번 글은 코틀린 DSL과 그루비 DSL의 차이를 확인하는 것이 목적이기 때문에, 해당 내용은 여기까지만 보고 넘어가도록 하겠습니다.

코틀린 DSL이 타입 안정성 측면에서 어떤 장점이 있는지 살펴보았습니다. 그렇다면 대규모 멀티 모듈 유지보수 측면에서는 어떤 점이 더 좋을까요?

대규모 멀티 모듈 유지보수 측면에서는 어떤점이 더 좋을까?

위에서 그루비 DSL은 동적 타입 구조라고 설명하였습니다.

반면 코틀린 DSL은 정적 타입 기반으로 동작합니다. 즉, Gradle 설정을 타입 기반으로 관리할 수 있다는 의미입니다.
그렇기 때문에 프로젝트 규모가 커지고 멀티 모듈 환경처럼 공통 설정과 build logic이 증가할수록, IDE 지원이나 리팩토링, 설정 관리 측면에서 조금 더 안정적으로 유지보수할 수 있다고 여겨졌습니다.

하지만 타입이 정적이라고 해서 대규모 프로젝트에 무조건 적합하다고 보기는 어려워 보였습니다. 언어 관점에서 보면 일반적으로 동적 타입 언어보다 정적 타입 언어가 대규모 환경에서 유지보수 측면에 조금 더 유리하다고 알려져 있습니다. 컴파일 단계에서 타입 오류를 조금 더 빠르게 확인할 수 있고, IDE 지원이나 리팩토링 역시 조금 더 안정적으로 동작하기 때문입니다.

실제로 Kotlin 공식 문서에서도 정적 타입 기반 구조가 IDE 리팩토링과 자동완성 지원에 도움을 준다고 설명하고 있습니다.

Gradle best practices | Kotlin

kotlinlang.org

또한 Gradle 공식 문서에서는 Kotlin DSL이 기존 그루비 DSL의 동적 접근 방식 대신, type-safe model accessor를 제공한다고 설명하고 있습니다.

Gradle best practices | Kotlin

kotlinlang.org

다만, 이것이 빌드 툴에서도 완전히 동일하게 적용되는지는 아직 확실하지 않았습니다. 실제로 빌드 성능만 보면 상황에 따라 그루비 DSL이 조금 더 유리한 경우도 존재하였기 때문입니다.

또한 실제 대규모 멀티 모듈 환경에서도 여전히 그루비 DSL을 사용하는 사례들 역시 존재하였습니다. 결국 어떤 방식이 무조건적으로 정답이라기보다는, 프로젝트 규모나 팀의 경험, 유지보수 방향에 따라 선택이 달라질 수 있다고 여겨졌습니다.

아쉽게도 어떤 방식을 더 선호하는지에 대한 명확한 통계 자료는 찾아볼 수 없었습니다. 하지만 여러 사례들을 종합해보면, 코틀린 DSL을 선호하는 입장과 그루비 DSL을 선호하는 입장 두 가지 모두를 확인할 수 있었습니다.
실제로 Gradle 공식 블로그에서는 신규 프로젝트에 대해 Kotlin DSL을 기본 생성 방식으로 변경하였다고 설명하고 있습니다.

Kotlin DSL is Now the Default for New Gradle Builds

Kotlin DSL is Now the Default for New Gradle Builds Calendar April 13, 2023 Introduction Kotlin DSL for Gradle was introduced in version 3.0 of the Gradle Build Tool in August 2016 and released as 1.0 in Gradle 5.0. Since then, it’s been growing in popul

blog.gradle.org

반면 복잡한 build logic을 가진 대규모 레거시 프로젝트에서는 마이그레이션 비용이나 기존 생태계 문제로 인해, 여전히 그루비 DSL을 유지하는 경우도 존재한다는 것을 확인할 수 있었습니다.

즉 실제 현업에서는 단순히 "무조건 코틀린 DSL이 좋다"기보다는, 신규 프로젝트에서는 코틀린 DSL을 선택하는 흐름이 증가하고 있었고, 대규모 레거시 프로젝트에서는 여전히 그루비 DSL을 유지하는 사례들도 존재하였습니다.

거두 절미하고 빌드 툴을 사용하는 이유가 무엇일까?

대표적으로 외부 라이브러리나 프레임워크를 가져오고, 프로젝트를 빌드하고 실행하기 위함입니다. 결국 build.gradle 역시 의존성을 관리하고 프로젝트를 실행하기 위한 설정 파일이라고 볼 수 있습니다. 그렇다면 외부에서 정보를 가져오는 작업에서도 정적인지 동적인지가 그렇게까지 중요한 것일까요?

개인적으로는 이 부분에서 조금 의문이 들었습니다. 실제로 의존성 선언만 보더라도 여전히 문자열 기반으로 작성되는 부분이 존재하였기 때문입니다.

즉 코틀린 DSL이라고 해서 모든 부분이 완전한 타입 안정성을 가지는 것은 아니었습니다.

오히려 실제 차이는 단순 의존성 선언보다는, 공통 build logic이나 task 설정, 멀티 모듈 환경에서의 설정 관리 측면에서 조금 더 드러나는 것으로 보였습니다. 결국, 빌드 툴 관점에서는 단순히 정적 타입인지 동적 타입인지 자체보다, 프로젝트 규모가 커졌을 때 build logic을 얼마나 안정적으로 관리할 수 있는지가 더 중요한 부분처럼 느껴졌습니다.

마무리

정확하게 어떤 DSL을 사용하는 것이 무조건 더 좋다는 내용은 찾을 수 없었습니다. 다만 여러 자료들을 확인해보면서, 단순히 문법 차이가 아니라 어떤 방향으로 build logic을 관리할 것인지에 대한 고민이 담겨있다는 것을 느낄 수 있었습니다.

기존에는 그루비 DSL만 사용하였습니다. 그러다 코틀린 DSL 역시 알게 되었고, 어떤 DSL을 사용하는 것이 더 적절한지에 대해 여러 자료들을 찾아보게 되었습니다.

실제로 현재 흐름을 보면 신규 프로젝트에서는 코틀린 DSL을 사용하는 사례가 증가하고 있었고, 레거시 프로젝트에서는 여전히 그루비 DSL을 유지하는 경우도 존재하였습니다. 하지만 이 역시 프로젝트 규모나 팀 경험, migration 비용 등에 따라 선택이 달라질 수 있다고 느껴졌습니다.

또한 성능만 보면 상황에 따라 그루비 DSL이 조금 더 유리한 경우도 존재하였습니다. 반면 코틀린 DSL은 정적 타입 기반 구조를 통해 IDE 지원이나 리팩토링, build logic 관리 측면에서 조금 더 안정적으로 사용할 수 있다는 평가들이 존재하였습니다.

결국 어떤 DSL이 절대적으로 더 좋다기보다는, 프로젝트 환경과 유지보수 방향에 따라 선택이 달라질 수 있다고 여겨졌습니다. 다만 신규 프로젝트를 시작하는 입장이라면, 개인적으로는 코틀린 DSL을 사용하는 방향이 조금 더 좋아 보였습니다.

배치 작업시 예외가 발생한다면 어떻게 처리할까?

klom — Wed, 6 May 2026 22:09:26 +0900

만약 외부 API의 스펙이 변경된다면 어떻게 처리해야 할까요? 이 경우에도 skip을 해야 할까요, 아니면 retry를 해야 할까요?

외부 API 장애라고 해서 모두 같은 방식으로 처리하면 안 됩니다. 예를 들어 특정 row의 값이 잘못되었거나 필수 데이터가 누락된 경우라면, 이는 개별 데이터 품질 문제로 보고 skip 처리를 고려할 수 있습니다. 반면 외부 API의 응답 구조가 변경된 경우는 다르게 봐야 합니다. 이는 단순히 특정 데이터 하나가 잘못된 것이 아니라, 배치가 기대하던 계약이나 제약 자체가 깨진 상황입니다. 이런 경우까지 skip해버리면 전체 데이터가 잘못 처리되거나, 문제를 늦게 발견할 수 있습니다. 또한 네트워크 타임아웃이나 5XX 오류처럼 일시적인 장애는 retry 대상이 될 수 있습니다. 하지만 API 스펙 변경은 retry를 한다고 해결되는 문제가 아닙니다. 구조 자체가 달라졌기 때문입니다. 따라서 응답 구조 변경이 감지되면 skip이나 retry보다는 배치를 실패시키고, 빠르게 문제를 감지할 수 있도록 처리하는 것이 더 안전합니다.

어째서 process단계에서 skip or retry를 하는가?

배치 작업은 크게 읽기(Read) → 처리(Process) → 쓰기(Write) 단계로 구분할 수 있습니다. 이 중에서 skip이나 retry 같은 예외 처리 전략이 가장 중요하게 적용되는 구간은 처리(Process) 단계입니다. 그 이유는 단순합니다. 데이터를 읽거나 저장하는 것도 중요하지만, 실제 비즈니스 로직과 데이터 변환이 수행되는 중심 영역이 바로 처리 단계이기 때문입니다. 예를 들어 특정 row의 데이터가 잘못되었거나 필수 값이 누락된 경우에는 처리 단계에서 이를 검증하고 skip 여부를 결정할 수 있습니다. 또한 일시적인 네트워크 장애나 외부 API 호출 실패가 발생했다면 retry 전략 역시 이 과정에서 고려될 수 있습니다. 반면 외부 API의 응답 구조 자체가 변경된 경우는 다르게 봐야 합니다. 이는 단순 데이터 오류가 아니라, 처리 로직이 기대하던 계약 자체가 깨진 상황입니다. 이런 경우까지 skip하거나 무의미하게 retry를 반복하면 문제를 숨긴 채 잘못된 데이터가 계속 처리될 수 있습니다. 따라서 처리 단계에서는 예외를 단순히 "실패"로만 보는 것이 아니라, 어떤 종류의 실패인지 구분하여 skip, retry, fail-fast 전략을 다르게 가져가는 것이 중요합니다.

먼저 커스텀 exception을 준비해줍니다.

사실 커스텀 Exception은 반드시 만들어야 하는 것은 아닙니다. 기존 자바에서 제공하는 Exception만으로도 충분히 예외 처리는 가능합니다. 그럼에도 불구하고 커스텀 Exception을 만드는 이유는 단순합니다. 예외가 발생했을 때 상황을 더 명확하게 구분하고, 보다 간단하게 처리하기 위함입니다. 예를 들어 IllegalArgumentException, RuntimeException만 사용하게 되면 현재 발생한 문제가 비즈니스 오류인지, 외부 API 문제인지, 일시적인 장애인지 구분하기 어려워질 수 있습니다.

반면 커스텀 Exception을 사용하면 예외 자체에 의미를 부여할 수 있습니다.

InvalidCouponException
ExternalApiTimeoutException
ResponseSpecChangedException

이처럼 예외를 목적에 따라 분리하면 catch 구문이나 예외 처리 정책에서도 의도를 명확하게 표현할 수 있습니다.

결국 핵심은 단순합니다. 커스텀 Exception의 목적은 "새로운 기능 추가"가 아니라,
예외 상황을 명확하게 분리하고 처리 흐름을 단순하게 만들기 위함입니다.

만약 커스텀 Exception을 사용하지 않는다면, 예외를 구분하기 위한 조건문이 많아지면서 처리 로직이 복잡해질 수 있습니다.
결과적으로 catch 구문 내부가 점점 비대해지고, 코드 역시 읽기 어려워질 가능성이 높아집니다. 예를 들어 메시지 문자열이나 상태값으로 예외를 구분하기 시작하면, 예외 처리의 책임이 분산되고 유지보수도 어려워질 수 있습니다. 반면 커스텀 Exception을 사용하면 예외 자체에 의미를 담을 수 있기 때문에, 어떤 상황에서 발생한 문제인지 명확하게 표현할 수 있습니다. 또한 예외 타입 기준으로 처리 전략을 나눌 수 있어 코드 흐름도 훨씬 단순해집니다.

즉 핵심은 단순합니다. 커스텀 Exception은 단순히 예외 클래스를 늘리는 것이 아니라, 복잡한 예외 처리 로직을 역할별로 분리하여 코드의 가독성과 유지보수성을 높이기 위한 방법입니다.

그러면 어떤 정보를 skip할까?

중요한 점은 커스텀 Exception을 만들었다고 해서 비즈니스 로직이 사라지는 것은 아니라는 것입니다.

결국 skip 여부를 결정하는 기준은 Exception 클래스가 아니라, 비즈니스적으로 "이 데이터를 버려도 되는가"에 대한 판단입니다.
예를 들어 특정 row의 필수 값이 누락되었거나, 이미 잘못된 데이터라고 판단되는 경우에는 해당 데이터만 skip하고 다음 작업을 이어갈 수 있습니다. 이런 경우는 개별 데이터 문제이기 때문에 전체 배치를 중단할 필요는 없을 수 있습니다.

이런 경우는 해당 row 자체의 문제이기 때문에 무시하고 넘어갈 수 있습니다. 하지만 네트워크 이슈로 예외가 발생한 경우는 다르게 봐야 합니다. 이 경우에도 skip을 해야 할까요? 물론 skip을 한다고 해서 배치 자체가 바로 실패하지는 않을 수 있습니다. 하지만 중요한 점은, 이 데이터는 잘못된 데이터가 아니라 정상 데이터라는 것입니다. 단지 외부 API 호출이나 네트워크 문제로 인해 일시적으로 처리하지 못했을 뿐입니다. 그런데 이를 skip해버리면 정상 데이터를 처리하지 않고 넘어간 것이 됩니다. 즉, 데이터 누락이 발생할 수 있습니다.

따라서 네트워크 타임아웃이나 일시적인 5XX 오류처럼 복구 가능성이 있는 장애라면 skip보다는 retry를 먼저 고려하는 것이 안전합니다.
retry 후에도 계속 실패한다면, 별도의 실패 이력으로 남기거나 배치를 실패시켜 후속 조치가 가능하도록 만들어야 합니다.

이번에는 skip이 아니라 retry를 적용해봅시다.

대부분의 retry 대상은 비즈니스 예외가 아니라 네트워크 이슈입니다. 그렇기 때문에 커스텀 Exception의 위치도 다르게 가져가는 것이 좋습니다. 예를 들어 skip 대상 Exception은 처리 단계에서 발생하는 데이터 검증 실패나 비즈니스 규칙 위반에 가깝기 때문에 process 하위 패키지에 둘 수 있습니다.

하지만 retry 대상 Exception은 성격이 다릅니다. 네트워크 타임아웃, 일시적인 5XX 응답, 외부 API 호출 실패처럼 외부 시스템과의 통신 과정에서 발생하는 예외에 가깝습니다. 따라서 이를 비즈니스 예외와 같은 위치에 두면 예외의 의미가 섞일 수 있습니다.

만약 같은 위치에서 관리하고 싶다면, exception 패키지를 별도로 만들고 그 안에서 skip과 retry에 사용되는 예외를 함께 관리하는 것이 더 적절하다고 생각합니다.

retry Exception은 비즈니스 예외가 아니라 외부 통신 과정에서 발생하는 예외에 가깝습니다. 따라서 이를 process 내부의 비즈니스 코드에서 직접 사용하는 것은 적절하지 않습니다.

그래서 저는 Mapper 클래스를 만들어 적용하기로 했습니다.

retry 대상 예외는 비즈니스 예외가 아니라 외부 통신 과정에서 발생하는 예외에 가깝습니다. 따라서 이를 process 내부의 비즈니스 코드에 직접 넣기보다는, 외부 API 응답이나 예외를 배치에서 사용할 수 있는 형태로 변환하는 계층이 필요하다고 판단했습니다.

이렇게 구성해두면 외부에서 어떤 예외가 발생했는지와 관계없이, 내부에서는 일관된 방식으로 처리할 수 있습니다.
즉, 외부 라이브러리나 API의 예외에 직접 의존하는 것이 아니라,
내부에서 정의한 예외 기준으로 retry나 실패 정책을 적용할 수 있게 됩니다. 또한 해당 코드는 상태를 가지는 객체가 아니라 단순히 예외를 변환하는 역할만 수행합니다. 즉, 특정 값을 저장하거나 관리하지 않고 입력값을 기반으로 결과만 반환하는 유틸성 메소드에 가깝습니다. 그래서 저는 이 코드를 static으로 구성했습니다. 굳이 Spring Bean으로 등록해서 관리할 필요가 없다고 판단했기 때문입니다.

둘 다 해당되지 않는 경우는?

여기서 한 가지 의문이 듭니다. skip도 적용했고, retry도 적용했습니다. 그렇다면 두 가지에 모두 해당하지 않는 예외는 어떻게 처리해야 할까요? 이 경우에는 무리하게 skip이나 retry 대상으로 포함시키면 안 됩니다.
skip은 "해당 데이터를 버려도 되는 경우"에 사용하고, retry는 "다시 시도하면 성공할 가능성이 있는 경우"에 사용합니다.

반대로 두 조건에 모두 해당하지 않는 예외라면, 이는 배치가 계속 진행해도 안전한지 판단하기 어려운 예외입니다.

따라서 이런 예외는 기본적으로 배치를 실패시키는 것이 더 안전합니다.
예상하지 못한 예외를 억지로 무시하면 데이터 누락이나 잘못된 처리로 이어질 수 있기 때문입니다.

즉 핵심은 단순합니다. 결국 배치에서는 "처리해도 되는 실패"와 "멈춰야 하는 실패"를 구분하는 것이 중요합니다.
위 서두에서 말한 외부 API 스펙 변경이 바로 여기에 해당됩니다. 스펙 변경은 특정 row의 데이터 품질 문제가 아니기 때문에 skip 대상이 아닙니다. 또한 네트워크 타임아웃이나 5XX처럼 일시적인 장애도 아니기 때문에 retry 대상도 아닙니다.

즉, 다시 시도한다고 해결되지 않고, 무시하고 넘어가도 안 되는 예외입니다. 이런 경우에는 배치를 계속 진행시키는 것보다 실패시키는 것이 더 안전합니다.
왜냐하면 배치가 기대하던 응답 구조와 실제 응답 구조가 달라졌다는 것은, 이후 처리 결과를 신뢰하기 어렵다는 의미이기 때문입니다. 따라서 외부 API 스펙 변경처럼 skip과 retry 어디에도 해당하지 않는 예외는 fail 처리하여 빠르게 감지할 수 있도록 해야 합니다.

마무리

이 글에서 학습한 핵심은 실패를 어떻게 관리할 것인가에 있습니다. 배치에서 발생하는 모든 예외를 동일하게 처리해서는 안 됩니다. 무조건 실패시키는 것이 정답도 아니고, 반대로 모든 예외를 skip하거나 retry하는 것도 올바른 방식은 아닙니다. 어떤 예외는 무시해도 되는 데이터 품질 문제일 수 있습니다. 반면 어떤 예외는 일시적인 네트워크 장애이기 때문에 재시도를 통해 복구할 수 있습니다. 그리고 외부 API 스펙 변경처럼 시스템의 계약 자체가 깨진 경우라면, 빠르게 실패를 감지하고 배치를 중단하는 것이 더 안전할 수 있습니다. 결국 안정적인 프로젝트를 구성하기 위해서는 “성공 로직”만큼이나 “실패를 어떻게 관리할 것인가”에 대한 설계 역시 중요하다고 생각합니다.

java에서 println()을 사용하면 안되는 이유

klom — Fri, 1 May 2026 20:05:13 +0900

몇 일 전, 긴 공백기를 지나 새로운 회사에 입사하게 되었습니다. 다행히도 저를 불러주는 곳이 있었고, 그 기회를 잡게 되었습니다. 해당 회사는 주로 SI 프로젝트를 수행하지만, 자체 솔루션도 함께 운영하고 있는 것으로 보입니다. 아직 구체적으로 어떤 프로젝트에 투입될지는 정해지지 않았습니다. 사전에 코드를 간단히 살펴보던 중, 로그를 println()으로 출력하는 방식이 사용되고 있는 것을 확인했습니다. 감각적으로는 println()을 로깅 용도로 사용하는 것이 적절하지 않다는 것을 알고 있었고, 실제로도 사용하지 않고 있었습니다. 다만, 왜 사용하면 안 되는지에 대해서는 명확하게 정리되어 있지 않았습니다. 그래서 출근 전에, println()을 로그로 사용하는 것이 왜 적절하지 않은지에 대해 스스로 정리하고 학습해보려고 합니다.

println을 어째서 사용하지 말라고 하는걸까?

println()은 출력 도구이지 로깅 도구가 아니기 때문입니다.
그 차이는 운영환경에서 꽤 많이 들어납니다.

성능 문제

System.out.println()은 내부적으로 동기화가 걸려 있습니다.
즉, 여러 스레드가 동시에 호출하면 병목이 생깁니다.

그렇다면, synchronized를 걸게 되면 어째서 성능 문제가 발생할까요?
동기화가 걸린다는 것은 스레드와 밀접하게 연결된 개념입니다. synchronized가 적용된다는 것은 여러 스레드가 동시에 접근하더라도, 한 번에 하나의 스레드만 해당 작업을 수행하도록 보장한다는 의미입니다. 이러한 구조는 데이터의 일관성을 맞추는 데에는 유리하지만, 동시에 여러 스레드를 직렬화시키기 때문에 성능 저하의 원인이 될 수 있습니다. 특히 요청이 많은 환경에서는 스레드들이 락을 획득하기 위해 대기하게 되고, 그로 인해 전체 처리량이 감소하는 병목 현상이 발생합니다.

그렇다면 Java는 왜 이러한 선택을 했을까요? 그 이유는 println()의 목적이 성능이 아닌 정확한 출력에 있기 때문입니다.

출력은 단순히 데이터를 내보내는 행위가 아니라, 메시지의 형태를 유지한 채 온전히 전달되는 것이 중요합니다. 만약 동기화가 없다면 여러 스레드가 동시에 출력하면서 문자열이 서로 뒤섞일 수 있습니다. 이 경우 출력 자체가 사라지는 것은 아니지만, 문장이 깨져 의미를 해석할 수 없는 상태가 될 수 있습니다. 따라서 Java는 출력의 일관성을 보장하기 위해 synchronized를 적용했고,
그 결과 각 출력이 원자적으로 실행되도록 설계되었습니다.

로그 레벨이 존재하지 않음

로그 레벨이 존재하지 않는다는 점도 중요한 문제입니다.
println()은 단순히 메시지를 출력하는 도구이기 때문에, 출력되는 정보에 대한 구분이 존재하지 않습니다.

즉, 어떤 로그가 단순한 정보인지, 디버깅을 위한 것인지, 혹은 실제 장애 상황을 나타내는 것인지 판단하기 어렵습니다.

반면, 로깅 프레임워크를 사용하면 debug, info, warn, error와 같이 로그의 성격에 따라 레벨을 나누어 관리할 수 있습니다.
이를 통해 운영 환경에서는 특정 레벨 이상의 로그만 출력하도록 설정하는 등, 상황에 맞게 로깅을 제어하는 것이 가능합니다.

하지만 println()은 이러한 제어가 불가능합니다.
출력 여부를 조정하려면 결국 코드 수정이 필요하며, 경우에 따라서는 조건문을 추가하는 방식으로 억지스럽게 제어해야 하는 상황이 발생할 수 있습니다.

또한 로깅 프레임워크를 활용하면, 이러한 로그를 단순 콘솔 출력이 아닌 파일로 저장하고 관리하는 것도 가능해집니다.
이를 통해 로그를 지속적으로 보관하거나, 장애 분석 및 모니터링에 활용할 수 있습니다.

결론

얼마나 빠르게 만들려고 했는지는 모르겠지만, 생각보다 코드가 엉망이었습니다. 패키지 구조는 상황에 따라 달라질수 있다고 여겨지지만 로깅만큼은 참을 수 없었습니다. 그래서 왜 println()을 사용하면 안되는지에 대해 학습을 진행하였습니다. 다음에는 로깅 프레임워크를 어떻게 사용하면 좋은지에 대해 학습해보겠습니다.

카프카의 설정은 진짜일까?? - offset(3)

klom — Sun, 26 Apr 2026 23:16:32 +0900

지금까지 학습한 내용을 간단하게 정리해보면, offset은 broker에 저장된 메시지의 순서를 의미하고, consumer는 이 offset을 기준으로 메시지를 읽고 처리하게 됩니다.

그리고 어디까지 처리했는지를 기록하는 과정을 offset commit이라고 합니다. 이 commit 방식에는 크게 두 가지가 존재합니다. 자동 commit은 일정 주기에 따라 offset을 자동으로 기록해주기 때문에 구현이 간단하다는 장점이 있습니다. 하지만 처리 완료 여부와 관계없이 offset이 기록되기 때문에, 메시지를 처리하는 도중 애플리케이션에 장애가 발생할 경우 문제가 발생할 수 있습니다.

이 경우 Kafka는 해당 메시지를 이미 처리된 것으로 인식하게 되고, consumer가 재시작되더라도 메시지는 다시 전달되지 않습니다. 결과적으로 데이터 유실이 발생할 수 있습니다.
반면 수동 commit은 개발자가 직접 commit 시점을 제어해야 하기 때문에 다소 번거롭지만,
처리 흐름을 보다 명확하게 관리할 수 있습니다.

자동 commit은 어떻게 하는지 대충 알겠는데 수동 commit은 도대체 어떻게 하는 걸까?

코드를 확인하기 전에 먼저 동작 흐름부터 이해해보겠습니다.
수동 commit은 말 그대로 consumer가 메시지를 처리한 뒤, 개발자가 직접 commit 시점을 결정하는 방식입니다.
consumer는 poll()을 통해 broker로부터 메시지를 가져옵니다. 그리고 가져온 메시지를 바탕으로 비즈니스 로직을 처리한 뒤,
처리가 완료되었다고 판단되는 시점에 commit을 수행합니다.

여기서 주목해야 할 점은 commit 시점을 개발자가 직접 결정할 수 있다는 것입니다.
즉, 자동 commit처럼 일정 주기에 의해 offset이 기록되는 것이 아니라, 처리가 끝났다고 판단한 시점에 직접 offset을 기록할 수 있습니다. 수동 commit은 말 그대로 consumer가 메시지를 처리한 뒤, 개발자가 직접 commit 시점을 결정하는 방식입니다.

그렇다면, 어떻게 처리가 끝났다고 판단할 수 있을까?

이를 이해하기 위해서는 Acknowledgment 개념을 알아야 합니다.
Acknowledgment는 간단하게 말해, 메시지 처리가 완료되었음을 Kafka에 알리는 신호입니다.

consumer는 메시지를 처리한 뒤 Acknowledgment를 호출하게 되며,
이 시점에 commit이 수행되거나 commit이 가능한 상태가 됩니다.

Acknowledgment는 commit 시점을 어떻게 제어하느냐에 따라 다양한 방식으로 동작하며, 내부적으로는 여러 구현체를 통해 처리됩니다. 대표적으로는 RECORD, BATCH, MANUAL 등의 방식이 있으며, 이러한 방식에 따라 commit 시점이 달라지게 됩니다.

여기서 드는 의문은 어떻게 RECORD인지 BATCH인지 MANUAL인지 알고 다양한 구현체를 리턴해주는 걸까요?

Acknowledgment의 동작 방식은 개발자가 직접 선택하는 것이 아니라, config나 yml에 설정된 AckMode 값을 기준으로 결정됩니다.

그렇다면 왜 이렇게 하는걸까요? 이유는 단순합니다. 메시지 처리 방식에 따라 commit 시점이 달라지기 때문입니다.
어떤 경우에는 메시지를 하나씩 처리한 뒤 commit하는 것이 적절할 수 있고,
어떤 경우에는 여러 메시지를 한 번에 처리한 뒤 commit하는 것이 더 효율적일 수 있습니다.

조금더 직관적으로 말씀드리자면, RECORD는 하나씩 안전하게, BATCH는 묶어서 효율적으로 MANUAL은 내가 직접 제어 하는 방법입니다. 그나저나 이상합니다. 분명 이 챕터는 수동 commit에 관한 방식인데 RECORD, BATCH는 자동 commit인 걸까요?

결론부터 말하면 그렇지 않습니다.

RECORD와 BATCH는 Kafka의 자동 commit이 아니라, Spring Kafka의 컨테이너가 메시지 처리 이후 commit을 대신 수행해주는 방식입니다.

그렇다면, MANAL방식은 어떻게 사용하는 걸까?

사용하는 방식 자체는 크게 어렵지 않습니다.

acknowledgment.acknowledge();

를 호출하면, consumer가 처리한 offset이 commit됩니다.
즉, broker 입장에서는 이 메시지는 처리 완료되었다고 판단할 수 있게 됩니다.

그렇다면 여기서 한 가지 의문이 생깁니다.

acknowledgment.acknowledge();
couponIssueRequestHandler.handle(event);

처럼 실제 처리 로직인 couponIssueRequestHandler.handle()을 실행하기 전에 commit을 하면 어떻게 될까요?

이 경우 문제가 발생할 수 있습니다.

commit이 먼저 수행되면 Kafka는 해당 메시지를 이미 처리된 것으로 인식합니다.
그런데 그 이후 handle() 실행 중 애플리케이션 장애가 발생한다면, consumer가 재시작되더라도 해당 메시지는 다시 가져오지 않습니다.

결과적으로 처리되지 않은 메시지가 처리된 것으로 기록되어 데이터 유실이 발생할 수 있습니다.

따라서 MANUAL commit에서는 보통 다음 순서가 되어야 합니다.

couponIssueRequestHandler.handle(event);
acknowledgment.acknowledge();

핵심은 단순합니다. commit은 처리 전에 하는 것이 아니라, 처리 완료 이후에 해야 합니다. 다만 commit을 먼저 수행하게 되면,
메시지를 처리하기 전에 이미 offset이 기록되기 때문에 consumer 입장에서의 처리 지연(latency)은 줄어들 수 있습니다.
하지만 이 경우에는 중요한 문제가 발생합니다. 처리 도중 장애가 발생하더라도 해당 메시지는 다시 전달되지 않습니다.

즉, 데이터 유실 가능성을 감수해야 합니다. 따라서 이러한 방식은 정합성보다 처리 속도를 우선하는 경우에만 제한적으로 고려될 수 있습니다.

마무리

벌써 2번째 완료를 미루고 있네요. 원래 이번글에 종료하고 싶었는데 점점길어지네요. 다음에 완료하는 것을 목표로 해보겠습니다.
다음 시간에는 이번에 알아보지 못한 BATCH와 RECORD에 대해 학습해보겠습니다.

카프카의 설정은 진짜일까?? - offset(2)

klom — Wed, 22 Apr 2026 23:47:49 +0900

카프카의 설정은 진짜일까?? - offset(1)

원래 시나리오대로면, producer를 전부 끝내고 나서 consumer를 학습하려고 하였지만 살짝 우회하기로 결정하였습니다. 그 이유가 뭐냐면 카프카의 주요 특징중 하나가 offset으로 알고 있습니다. 제

b-programmer.tistory.com

오랜만에 Kafka 관련 글을 작성하게 되었습니다. 이번 글에서는 offset commit에 대해 알아보려고 합니다. Kafka의 offset은 기본적으로 broker에 저장됩니다. 하지만 이 offset을 기준으로 어디까지 처리했는지 관리하는 주체는 consumer입니다. 그 이유는 broker와consumer의 역할이 다르기 때문입니다. broker는 메시지를 저장하고 전달하는 역할을 할 뿐, 우리 서비스의 비즈니스 로직을 직접 수행하지는 않습니다. 실제 메시지를 전달받아 처리하는 쪽은 consumer입니다. 따라서 consumer는 자신이 어디까지 처리했는지 직접 기록할 필요가 있는데, 이 과정을 offset commit이라고 부릅니다. 이번 글에서는 offset commit이 왜 필요한지, 그리고 어떤 방식으로 동작하는지 정리해보겠습니다.

언제, 어떻게 commit이 발생하는지를 직접 확인할 수 있을까?

그 전에 Kafka의 전체 흐름부터 다시 짚어보겠습니다. Kafka는 기본적으로 producer → broker → consumer 구조로 동작합니다.
producer는 메시지를 broker에 저장하고, consumer는 broker로부터 메시지를 가져와 처리합니다.
이때 중요한 포인트가 하나 있습니다. broker에는 메시지가 계속 쌓일 수 있지만, consumer는 그 속도를 따라가지 못할 수도 있습니다.
이렇게 아직 consumer가 처리하지 못한 메시지의 차이를 Kafka에서는 LAG이라고 부릅니다.

LAG와 Commit의 관계

LAG는 다음과 같은 기준으로 계산됩니다.

LAG = LOG-END-OFFSET - CURRENT-OFFSET

여기서 핵심은 두 가지 값입니다.

LOG-END-OFFSET
→ broker에 쌓인 마지막 offset
CURRENT-OFFSET
→ consumer가 commit한 offset

이 의미를 조금 더 풀어보면 다음과 같습니다. producer는 계속해서 메시지를 broker에 적재하고,
consumer는 메시지를 처리한 뒤 offset을 commit합니다.
이때 consumer의 처리 속도가 producer의 적재 속도를 따라가지 못하거나, commit이 지연되면 두 offset의 차이가 벌어지게 됩니다.

이 차이가 바로 LAG입니다. 반대로 consumer가 메시지를 처리하고 commit을 진행하면 CURRENT-OFFSET이 증가하면서
LAG는 점점 줄어들게 됩니다.

결국 LAG가 증가한다는 것은 broker에서 consumer로 메시지가 덜 전달되는 것이 아니라,
consumer가 메시지를 충분히 빠르게 처리하지 못해 처리되지 않은 메시지가 누적되고 있는 상태를 의미합니다.

그렇다면 broker로부터 전달받은 메시지는 consumer에서 어떻게 처리될까요?

consumer는 메시지를 단순히 읽는 것이 아니라, 해당 메시지에 대해 비즈니스 로직을 수행하게 됩니다.
하지만 여기서 한 가지 중요한 문제가 있습니다.
Kafka는 메시지를 전달해줄 뿐, 해당 메시지가 실제로 처리되었는지는 알 수 없습니다.
따라서 consumer는 이 메시지까지는 처리 완료했다는 상태를 직접 기록해야 합니다.
이때 사용하는 개념이 바로 commit입니다.

commit은 수동 commit과 자동 commit이 존재합니다. 그렇다면, 수동과 자동으로 왜 분리가 되었을까요?

자동 commit

그 이유는 단순합니다.
언제 처리 완료로 볼 것인가를 누가 결정하느냐의 차이입니다.

자동 commit은 일정 주기마다 offset을 자동으로 commit하는 방식입니다.
consumer는 메시지를 poll로 가져온 이후, 설정된 주기에 따라 offset을 commit합니다.

메시지 조회(poll) → 일정 시간 경과 → 자동 commit

이 방식의 장점은 명확합니다. 구현이 단순하고 별도의 처리 없이도 offset이 관리됩니다.
하지만 치명적인 문제가 존재합니다. 아직 처리가 끝나지 않았는데 commit이 발생할 수 있습니다.
예를 들어 다음과 같은 상황을 생각해볼 수 있습니다.

poll → 메시지 수신
(비즈니스 로직 처리 중)
→ 자동 commit 발생
→ 애플리케이션 장애 발생

이 경우 Kafka 입장에서는 이미 해당 메시지가 처리된 것으로 인식하게 됩니다.
따라서 consumer가 재시작되더라도 해당 메시지는 다시 전달되지 않습니다. 결과적으로 데이터 유실 가능성이 발생하게 됩니다.

여기서 말하는 Kafka는 무엇일까요?

기존에 우리가 말하는 Kafka는 broker였습니다. 그렇다면 여기서 말하는 Kafka도 broker일까요?
정확히 말씀드리자면, 여기서 말하는 Kafka는 broker가 아닙니다.
consumer client를 의미합니다.
consumer client는 broker와 분리된 애플리케이션이지만, Kafka 프로토콜을 기반으로 통신하며 동작합니다.

즉, commit은 broker 내부에서 자동으로 처리되는 것이 아니라, consumer client가 주도적으로 수행하는 동작입니다.

이 점이 중요한 이유는 다음과 같습니다.

consumer client는 Kafka broker와 분리되어 있지만, 네트워크를 통해 연결된 상태에서 동작하기 때문에 실행 환경의 영향을 직접적으로 받습니다. 따라서 commit 시점은 항상 안정적으로 보장되는 것이 아니라, 애플리케이션의 상태에 따라 달라질 수 있습니다.

수동 commit

수동 commit은 개발자가 직접 commit 시점을 결정하는 방식입니다.

poll → 메시지 받음 → 처리 완료 → commit

이 방식의 가장 큰 특징은 처리 완료 이후에만 commit을 수행할 수 있다는 점입니다.
따라서 메시지를 처리하기 전에 commit이 발생하는 상황을 방지할 수 있으며, 데이터 유실 가능성을 크게 줄일 수 있습니다.
하지만 그만큼 고려해야 할 점도 존재합니다. 처리가 완료된 이후에 commit을 수행하기 때문에,
commit 이전에 장애가 발생할 경우 동일한 메시지가 다시 전달될 수 있습니다.
즉, 중복 처리 가능성이 발생할 수 있습니다. 또한 commit 시점을 직접 제어해야 하기 때문에, 구현 복잡도가 증가하는 단점도 존재합니다.

오늘은 여기까지 정리해보겠습니다. 이번 글에서는 자동 commit과 수동 commit의 개념을 간단하게 살펴보았습니다. 그렇다면 수동 commit은 개발자가 직접 commit 시점을 제어한다고 했는데, 실제로 어떤 방식으로 처리되는지는 다음 글에서 자세히 다뤄보겠습니다.
또한 consumer가 메시지를 처리할 때 정합성을 우선할 것인지, 처리 속도를 우선할 것인지 이와 관련된 다양한 방법들도 함께 살펴보겠습니다.

웹소켓 vs mq

klom — Mon, 20 Apr 2026 22:51:20 +0900

웹소켓과 MQ는 모두 데이터를 전달하는 통로라는 공통점을 가지고 있습니다. 겉보기에는 둘 다 어떤 큐를 통해 메시지를 주고받는 것처럼 느껴질 수 있습니다. 하지만 실제로는 사용하는 목적도 다르고, 시스템 안에서 맡는 역할도 다릅니다. 보통 웹소켓은 실시간성, MQ는 비동기 처리라고 설명합니다. 물론 틀린 말은 아닙니다. 다만 이렇게 이분법적으로 나누면 두 기술의 차이를 충분히 설명하기에는 다소 부족하다고 느껴졌습니다. 웹소켓도 결국 비동기적으로 동작하고, MQ 역시 상황에 따라 실시간에 가깝게 활용될 수 있기 때문입니다. 따라서 이 글에서는 단순한 특징 비교에 그치지 않고, 웹소켓과 MQ에서 말하는 "큐"를 각각 어떻게 이해해야 하는지에 초점을 맞춰 정리해보겠습니다.

각각의 큐에는 어떤것을 전달 할까?

간단히 웹 소켓이 왜 만들어졌는지 생각해보자.

이것을 이해하기 위해서는 웹소켓이 왜 존재하는지부터 생각해야 합니다. 웹소켓은 기존 HTTP 위에서 동작하도록 만들어진 프로토콜입니다. 그렇다면, 왜 기존 방식을 유지하지 않고 새로운 방식을 만들었을까요?

HTTP는 요청을 전달하고 응답을 반환하면 연결이 종료되는 구조입니다. 이러한 구조에서는 실시간 데이터가 필요한 서비스에서 문제가 발생했습니다. 예를 들어, 채팅이나 실시간 알림과 같은 서비스에서는 데이터의 변화가 발생할 때마다 클라이언트가 지속적으로 요청을 보내야 했습니다. 이 과정에서 불필요한 요청이 반복적으로 발생했고, 요청과 응답 사이클로 인해 지연이 발생했습니다.

결국 다음과 같은 문제가 발생했습니다.

지속적인 요청으로 인한 불필요한 네트워크 비용이 발생했습니다.
요청-응답 구조로 인해 지연 시간이 증가했습니다.
서버와 클라이언트 모두에 부담이 증가했습니다.

이러한 문제를 해결하기 위해 "요청을 반복하지 않고 데이터를 지속적으로 받을 수 있는 방법"이 필요했습니다.
그 결과로 등장한 것이 웹소켓입니다. 웹소켓은 한 번 연결을 맺으면 이를 유지한 채, 서버와 클라이언트가 자유롭게 데이터를 주고받을 수 있도록 설계되었습니다. 즉, 요청과 응답이 반복되는 구조에서 벗어나 데이터가 지속적으로 흐를 수 있도록 만들기 위해 등장한 방식입니다.

웹소켓은 데이터가 지속적으로 흐를 수 있도록 하기 위해 등장한 기술입니다. 즉, MQ에서 말하는 큐의 개념과는 다릅니다.
큐는 말 그대로 대기열입니다. 어떤 작업이나 메시지를 잠시 쌓아두고, 이후에 처리하기 위해 존재합니다.
하지만 웹소켓에서의 통로는 이러한 대기열의 개념이 아닙니다. 데이터를 쌓아두기 위한 공간이 아니라, 흐르게 하기 위한 경로에 가깝습니다. 비유를 하자면 고속도로의 하이패스와 유사합니다. 일반적인 HTTP 요청은 톨게이트에서 매번 멈췄다가 지나가는 구조라면,
웹소켓은 하이패스를 통해 멈추지 않고 계속 흐르는 구조라고 볼 수 있습니다.

즉, 웹소켓은 데이터를 "쌓기 위한 구조"가 아니라 지속적으로 전달하기 위한 통로라고 이해하는 것이 더 적절합니다.

그렇다면 MQ는 어떨까?

MQ는 이름 그대로 메시지를 큐에 적재하여 전달하는 것이 핵심입니다.
간단히 설명하면 MQ는 producer와 consumer로 구성되며, producer에서 발생한 메시지를 consumer가 가져가서 처리하는 구조입니다.

즉, 메시지를 즉시 처리하는 것이 아니라, 큐에 적재해두고 나중에 처리하는 시스템이라고 볼 수 있습니다.

이러한 구조를 사용하는 이유는 요청과 처리를 분리하기 위함입니다.
요청을 받은 시점에서 모든 로직을 처리하지 않고, 메시지만 큐에 넣은 뒤 빠르게 응답을 반환할 수 있습니다.

그 결과로 다음과 같은 이점이 발생합니다.

요청 처리 시간이 단축되었습니다.
시스템 간 결합도가 낮아졌습니다.
트래픽이 몰리더라도 유연하게 대응할 수 있게 되었습니다.

또한 MQ는 메시지를 순서대로 저장할 수 있는 구조를 가지고 있습니다. 하지만 중요한 점은, 빠른 전송의 핵심이 순서 자체에 있는 것은 아니라는 점입니다. 실제로는 메시지를 큐에 적재한 이후, consumer가 이를 비동기적으로 처리하거나 병렬로 처리할 수 있기 때문에 전체적인 처리 효율이 증가하게 됩니다. 즉, MQ는 단순히 메시지를 전달하는 것이 아니라 처리 시점을 뒤로 미루고, 시스템을 분리하기 위한 구조라고 이해하는 것이 더 적절합니다.

누가 보아도 서로 다른 두 기술을 "통로"라는 공통점으로 묶어 비교해보았습니다. 비교를 진행해보니, 언제 웹소켓을 사용하고 MQ를 사용해야 하는지 조금 더 명확하게 보였다고 느꼈습니다. 경우에 따라서는 웹소켓과 MQ를 함께 사용하는 구조도 존재합니다. 이렇게 두 기술을 함께 사용하는 이유는, 웹소켓이 제공하는 통로에서 동시성이 높아질 수 있기 때문입니다. 이로 인해 동일한 자원에 대해 동시에 접근하는 상황이 발생할 수 있으며, 이는 race condition으로 이어질 수 있습니다. 결과적으로 데이터가 의도하지 않은 형태로 처리될 가능성도 존재합니다. 이를 해결하기 위한 방법은 여러 가지가 있지만, 그 중 하나로 MQ를 활용하여 메시지를 큐에 적재하고 순차적으로 처리하는 방식도 고려할 수 있습니다. 앞으로도 이처럼 서로 다른 기술을 비교하고, 그 내부 동작을 깊이 있게 이해한다면 보다 나은 설계를 할 수 있을 것이라 생각합니다.

race condition

klom — Mon, 13 Apr 2026 21:47:26 +0900

Race condition은 여러 작업이 동시에 같은 데이터를 처리할 때, 실행 순서에 따라 결과가 달라지는 문제입니다.
쉽게 말해, 같은 자원에 대한 접근이 동시에 발생하면서 기대한 결과와 실제 결과가 달라지는 상황입니다.

이전 선착순 쿠폰 시스템을 개발할 때도 이러한 문제가 발생했습니다.

예를 들어 100명의 사용자가 동시에 쿠폰 발급을 요청했다고 가정하겠습니다. 응답 결과만 보면 6건만 성공했고, 94건은 실패했습니다.
그렇다면 정상적인 시스템이라면 실제 DB에도 성공한 6건만 저장되어 있어야 합니다.

하지만 실제로 확인해보니 DB에는 96건의 쿠폰 발급 내역이 저장되어 있었습니다.
즉, 애플리케이션이 사용자에게 반환한 결과와 실제 데이터베이스 상태가 서로 일치하지 않았습니다.

이런 상황을 정합성이 깨졌다고 할 수 있습니다. 더 정확하게는, 동시성 문제로 인해 데이터 정합성이 깨진 상태라고 표현할 수 있습니다.
반대로, 응답 결과가 6건 성공, 94건 실패이고 실제 DB에도 정확히 6건만 저장되었다면, 비록 실패 요청이 많았더라도 정합성은 유지된 것입니다. 즉, 정합성은 단순히 성공이나 실패 수가 많은지가 아니라, 시스템이 기대한 결과와 실제 저장된 데이터가 일치하는지로 판단해야 합니다.

이처럼 race condition은 단순히 일부 요청이 실패하는 문제를 넘어, 성공/실패 응답과 실제 데이터 상태를 어긋나게 만들어 시스템 신뢰성을 무너뜨릴 수 있습니다. 그렇다면 이제 중요한 질문은 하나입니다. 이 race condition을 어떻게 제어하고, 데이터 정합성을 어떻게 보장할 것인가입니다.

race condtion이 왜 발생하는지 생각해봅시다.

위에서 동시성 문제로 인해 race condition이 발생한다고 설명했습니다.
그렇다면 race condition이란 무엇일까요?

다음 그림을 보면 여러 요청이 동시에 동일한 자원에 접근하고 수정하는 상황을 확인할 수 있습니다.
이때 각 요청은 독립적으로 처리되기 때문에 실행 순서가 보장되지 않습니다.

그 결과 다음과 같은 문제가 발생할 수 있습니다.

중복 발급
데이터 불일치
응답 결과와 DB 상태 불일치

즉, 여러 요청이 서로의 상태를 고려하지 않은 채 동시에 실행되면서 예상하지 못한 결과가 발생하는 것이 바로 race condition입니다.
race condition이라는 용어는 말 그대로 경주(race)에서 유래했습니다.

여러 요청이 동시에 자원에 접근하면서 누가 먼저 실행될지 알 수 없는 상태,
즉 제어되지 않은 경쟁 상황을 의미합니다.

여기서 알 수 있는 정보는 하나입니다. 실행 순서가 보장이 되지 않는 점입니다.
그렇다면, 순서를 보장하기 위해서는 어떻게 할 수 있을까요?

순서를 보장하기 위해서는 어떻게 할 수 있을까?

핵심은 단순합니다. 여러 요청이 동시에 같은 자원을 수정하지 못하도록 만들어야 합니다.
동시에 같은 자원을 수정하지 못하게 만들려면 어떻게 해야 할까요?

Lock을 건다

락을 사용하게 되면 동시에 하나의 요청만 자원에 접근할 수 있도록 제어할 수 있습니다.
즉, 하나의 요청이 작업을 수행하는 동안 다른 요청들은 대기하게 됩니다.

이러한 방식은 race condition을 방지하고 데이터 정합성을 보장하는 데 효과적입니다.
하지만 동시에 처리할 수 있는 요청 수가 제한되기 때문에,
대기 시간이 발생하며 전체적인 응답 지연(latency)이 증가할 수 있습니다.

대표적인 방법은, synchronized, DB Lock, 분산 락등이 있습니다.

범위를 줄인다

범위를 줄이는 방법은 lock을 사용하는 방식에 비해 근본적인 해결책은 아닙니다. 범위를 줄인다는 것은 동일한 자원에 대한 접근 빈도를 낮추는 것이지, 동시에 접근이 발생하는 상황 자체를 제거하는 것은 아니기 때문입니다.

예를 들어 처리 대상이 100만 건에서 1000건으로 줄어들었다고 하더라도, 여전히 여러 요청이 동시에 같은 자원에 접근할 수 있으며,
race condition이 발생하지 않는다는 보장은 없습니다.
다만 이 방식은 추가적인 락이나 큐를 사용하지 않기 때문에, 자원 사용 측면에서는 가장 부담이 적은 접근입니다.
따라서 race condition이 치명적이지 않거나, 충돌 가능성을 낮추는 것만으로도 충분한 경우라면
범위를 줄이는 방식부터 적용하는 것이 효과적인 선택이 될 수 있습니다.

큐를 이용해서 순차화를 시킨다

락을 사용하는 방법이나 범위를 줄이는 방법과 비교하면, 큐를 사용하는 방식도 비슷한 해결책처럼 보일 수 있습니다.
이 점은 부정하지 않겠습니다.

하지만 큐를 사용하는 방식의 본질은 다릅니다. 요청과 실제 처리를 분리하는 구조라는 점입니다.

요청을 받는 시점에는 단순히 큐에 적재만 하고, 실제 처리는 이후에 별도의 consumer가 수행하게 됩니다.
즉, 요청 처리 경로에서 무거운 작업을 제거할 수 있고, 그 결과 사용자 입장에서는 더 빠르게 응답을 받을 수 있습니다.
또한 큐를 사용하면 다음과 같은 장점을 얻을 수 있습니다.

첫 번째는 처리 흐름을 제어할 수 있다는 점입니다. 단일 consumer를 사용한다면 요청을 순차적으로 처리할 수 있고,
동시에 접근하면서 발생하는 race condition을 줄일 수 있습니다.

두 번째는 확장성입니다. 큐는 여러 개의 consumer를 통해 병렬 처리가 가능하기 때문에, 트래픽이 증가하더라도 유연하게 대응할 수 있습니다.

하지만 이 구조에도 중요한 함정이 존재합니다.
첫 번째는 큐에 들어가기 전 단계에서 race condition이 발생할 수 있다는 점입니다.
즉, 큐에 넣기 전에 이미 공유 자원을 조회하거나 검증하는 로직이 있다면, 여전히 동시성 문제가 발생할 수 있습니다.

두 번째는 병렬 처리로 인한 race condition입니다. 여러 consumer를 사용해 병렬로 처리할 경우, 다시 동시에 같은 자원을 수정하는 상황이 발생할 수 있습니다. 이 경우 latency는 개선될 수 있지만, 정합성 문제가 다시 나타날 수 있습니다.

따라서 큐 기반 구조는 단순히 도입하는 것만으로는 충분하지 않고, 큐에 들어가기 전 단계와 consumer 처리 단계 모두에서
동시성 제어를 함께 고려해야 합니다.
이 두 가지 문제를 함께 해결할 수 있다면, 락 기반 방식이나 단순 범위 축소 방식보다 더 높은 성능과 정합성을 동시에 확보할 수 있는 구조라고 생각합니다.

앞에서 설명한 여러 방법을 적용하더라도, 모든 상황에서 race condition을 완벽하게 제거할 수 있다고 보기는 어렵습니다. 중요한 것은 race condition을 무조건 없애는 것 자체보다, 어떤 구간에서 동시성 문제가 발생할 수 있는지를 인지하고, 그에 맞는 방법으로 제어하는 것이라고 생각합니다. 즉, 핵심은 race condition의 가능성을 이해하고, 문제가 발생할 수 있는 지점을 찾은 뒤, 락, 큐, 조건부 갱신, 범위 분산과 같은 적절한 방법을 상황에 맞게 적용하는 것입니다. 결국 실무에서 중요한 것은 동시성 문제를 완벽하게 통제할 수 있다고 믿는 것이 아니라, 문제가 발생할 수 있음을 전제로 설계하고 대응하는 것이라고 생각합니다.

선착순 쿠폰 시스템을 개발하면서 2가지 문제가 발견이 되었습니다. 그 중 하나를 다음 시간에 적용해볼려고 합니다.

10000장의 쿠폰을 대상으로 500명의 동시 요청을 발생시키는 테스트를 진행했습니다. 그 결과, 일부 요청에서 총 63건의 실패가 발생했습니다. 이 시점에서는 큐를 통해 처리하기 이전 단계였기 때문에, HTTP 요청을 처리하는 과정에서 동시 접근이 발생했고,
그로 인해 race condition이 발생했을 가능성이 높다고 판단했습니다. 이를 해결하기 위해, 요청 처리 구조를 다시 점검해보았습니다.

batch - step,job

klom — Fri, 10 Apr 2026 23:05:42 +0900

배치의 전반적인 처리 과정에 대해 학습을 진행하였다. 배치는 기본적으로 3가지 단계로 동작한다.

Reader → Processor → Writer

데이터를 읽고, 가공하고, 저장하는 구조이다.
하지만 현재까지는 이 흐름을 단순하게 확인하기 위해 배치를 강제로 실행시키는 방식으로 동작을 확인하고 있었다.

즉, 배치의 구조를 제대로 사용하기보다는 동작 자체를 이해하는 데에 초점을 맞춘 상태였다. 하지만 스프링 배치에서는 이러한 작업 흐름을
Job과 Step이라는 개념을 통해 구조적으로 관리할 수 있다. 단순 실행에서 벗어나, 실행 단위와 흐름을 명확하게 정의할 수 있는 것이다.
그렇다면 스프링 배치에서는 이 Job과 Step을 어떻게 구성하고 사용하는지 확인해보자. 그리고 저번시간에 재대로 설명하지 않은 chunk도 함께 알아보자.

그렇다면, Step이란 무엇일까?

사실 지금까지 작성했던 코드를 보면 이미 Step과 비슷한 구조로 동작하고 있었다.
Reader → Processor → Writer 흐름을 직접 이어서 실행하고 있었기 때문이다.
즉, 위에서 보였던 코드는 Step을 "흉내낸 코드"라고 볼 수 있다.

하지만 스프링 배치에서의 Step은 단순히 흐름을 묶는 수준이 아니다.
Step은 배치 처리의 "실행 단위"이다. Reader, Processor, Writer를 하나로 묶어서 실제로 동작시키는 역할을 한다.
조금 더 정확하게 말하면 Step은 다음과 같은 것들을 관리한다.

Reader → Processor → Writer 흐름 실행
트랜잭션 관리
반복 처리 (chunk 기반 처리)
실패 시 재시도 및 롤백

즉, 우리가 직접 구현했던 단순한 흐름에 "운영에 필요한 기능"이 추가된 구조라고 보면 된다.
그래서 이전까지는 "동작을 이해하기 위해 직접 연결해서 실행했다"라면
이제부터는 "스프링 배치가 제공하는 Step을 통해 구조적으로 실행한다"라고 보면 된다.

그렇다면, Step이 많아지면 어떻게 되어질까?

답은 생각보다 단순하다. 여러 개의 Step을 하나로 묶어서 관리하게 된다.
이때 등장하는 개념이 바로 Job이다. Job은 여러 개의 Step을 하나의 흐름으로 구성한 상위 개념이다.
즉, Step이 하나의 작업 단위라면 Job은 그 작업들을 순서대로 실행하는 "전체 흐름"이라고 보면 된다.

예를 들어, 다음과 같은 상황을 생각해볼 수 있다.

Step1: 데이터 조회
Step2: 데이터 가공
Step3: 데이터 저장

이렇게 여러 개의 Step이 존재할 경우, 이 Step들을 순서대로 실행하도록 묶어주는 것이 바로 Job이다.
즉 구조를 정리하면 다음과 같다.

Job → Step → (Reader → Processor → Writer)

이렇게 계층 구조로 이루어져 있다. 결국 Step이 하나일 때는 단순한 배치 작업이지만,
Step이 여러 개가 되면 하나의 흐름으로 관리해야 할 필요가 생기고 그 역할을 Job이 담당하게 된다.

현재는 배치의 모든 과정을 하나의 Step으로 만들었기때문에 Job에 들어가는 Step하나 뿐이다.

JobOperator

아무리 Job과 Step을 잘 나누어두었다고 하더라도, 결국 이것을 실제로 실행시켜줄 실행기가 필요하다.
물론 처음 보여줬던 코드처럼 직접 호출하는 방식으로 작성할 수도 있다. 동작만 놓고 보면 그렇게 작성해도 큰 문제는 없다.

하지만 여기에는 중요한 차이점이 존재한다. 바로 스프링이 관리하는 코드인가, 아닌가 하는 점이다.

처음 방식은 개발자가 직접 실행 흐름을 제어하는 구조이다. 즉, 스프링 배치의 실행 구조 안에서 동작하는 것이 아니라,
우리가 강제로 호출해서 실행시키는 코드라고 볼 수 있다.

다시 말해, 이 코드는 스프링이 관리하는 배치 코드라기보다는, 배치와 비슷한 흐름을 직접 구현한 코드에 가깝다.

반면 스프링 배치에서는 JobOperator와 같은 실행 구조를 통해
스프링이 Job을 인식하고, 정해진 방식에 따라 실행하고 관리할 수 있도록 한다.

즉 핵심은 단순하다.

직접 실행하는 방식은 "배치처럼 보이는 코드"이고, 스프링이 관리하는 방식은 "실제로 스프링 배치 위에서 동작하는 코드"이다.

Chunk

Chunk는 데이터를 일정 단위로 끊어서 처리하는 역할을 한다.
한 번에 너무 많은 데이터가 들어오게 되면, 처리 중 실패할 가능성이 높아진다.

그래서 배치에서는 데이터를 일정 크기로 나누어 처리하는 방식을 사용한다.
예를 들어 10,000개의 데이터를 한 번에 저장하는 것보다, 100개씩 나누어 100번 저장하는 방식이 더 안정적 일 수 있다.
이렇게 하면 중간에 실패하더라도 전체가 아닌 일부만 다시 처리하면 되기 때문에, 복구와 재처리 측면에서도 유리하다.

배치에 대해 기본적으로 학습해야 하는 부분은 완료가 되어졌다고 느껴진다. 하지만 이것보다 깊게 들어가는 작업은 아직 진행하지는 않았습니다. 예를 들면, 기존에는 JobLaucher이 존재하였습니다. 하지만 spring 6.0이후부터는 JobOperator를 사용하도록 권장하고 있습니다. 어째서 JobLauncher는 더 이상 사용하지 않는지, 두 개의 차이점은 무엇이며, JobOperator의 장점이 어떤게 있는지 상세하게 파볼 예정입니다. 또, 현재는 스케쥴방식이 아닌 수동으로 배치를 돌리고 있습니다. 스케쥴 방식으로 바꾸게 되면 어떤 문제가 있는지도 살펴보면 좋을거 같네요. 다음 배치는 조금더 깊게 들어가는 시간을 가져보겠습니다. 긴 글 읽어주셔서 감사합니다.

Batch - processor, writer

klom — Thu, 9 Apr 2026 22:58:01 +0900

저번시간에 간단하게 배치가 어떤것인지 그리고 Reader에 대해 짧게 학습을 진행하였다. 간단하게 복습하면 Reader은 어딘가에 쌓여있는 데이터를 읽는 작업을 일컫는다. 하지만 배치의 전 과정을 생각해보면, 단순히 읽는 것으로 끝나지 않는다. 데이터를 읽고, 가공하고, 저장하는 흐름으로 이루어져 있다. 그렇다면, 어째서 이러한 과정을 거칠까? 이유는 생각보다 단순하다.

첫 번째는 데이터의 크기 때문이다. 대량의 데이터를 한 번에 처리하려고 하면 메모리 부담이 커지고, 중간에 실패했을 때 다시 처음부터 실행해야 하는 문제가 발생한다. 그래서 배치는 데이터를 일정 단위로 나누어 끊어서 처리하는 방식을 선택한다.

두 번째는 데이터의 구조가 서로 다르기 때문이다. 어딘가에 쌓여있는 데이터의 구조와 DB에 저장되어 있는 데이터 구조는 대부분 동일하지 않다. 그렇기 때문에 읽어온 데이터를 그대로 저장하는 것이 아니라, 목적에 맞게 변환하는 과정이 필요하다.

이러한 흐름 때문에 배치는 Reader, Processor, Writer라는 구조를 가지게 된다.
이번에는 Processor와 Writer를 진행해볼 예정이다. 작업을 해봤는데 생각보다 크기가 크지 않아 두 개를 나눠서 설명하기보다는 하나의 흐름으로 묶어서 설명하려고 한다.

데이터 가공을 시작해보자.

위에서 데이터 가공을 왜 하는지 간략하게 살펴봤다.
그렇다면 스프링 배치에서는 어떻게 데이터 가공할 수 있을까?

Reader에서 ItemReader라는 것을 본 적이 있다. Reader에서는 분명 implements ItemReader<PriceReadItem> 이렇게 되어 있었다. 그런데 ItemProcessor를 확인해보면 조금 다르다. PriceReadItem뿐만 아니라 PriceData까지 같이 선언되어 있는 것을 확인할 수 있다.

이 부분에서 헷갈릴 수 있는데, 구조는 생각보다 단순하다.
ItemProcessor<PriceReadItem, PriceData>는 Reader에서 읽어온 PriceReadItem을 받아서,
PriceData 형태로 변환해서 넘긴다는 의미이다. 즉, 입력 타입과 출력 타입이 다르다. 이게 바로 Processor의 핵심이다.

놀랍게도 이게 전부다. 물론 여기에 추가적으로 특정 데이터는 필요 없으니 제거하거나, 서비스에 맞게 값을 가공하거나, 형태를 조금 더 보기 좋게 바꾸는 작업이 들어갈 수도 있다. 하지만 모든 서비스에서 복잡한 가공이 필요한 것은 아니다.

경우에 따라서는 단순히 DTO → Entity처럼 매핑만 수행해도 Processor의 역할은 충분히 끝났다고 봐도 무방하다.
결국 Processor의 본질은 "읽어온 데이터를 다음 단계에서 사용할 수 있는 형태로 바꿔주는 것"이다.

가공한 데이터를 사용해보자

가공한 데이터를 사용하는 방법도 크게 틀리지는 않는다.

여기서 chunk라는 단위가 등장한다. 하지만 현재 나는 chunk를 사용하지 않고 배치를 실행하고 있다.
그 이유는 단순하다. 배치의 동작을 조금 더 명확하게 이해하기 위해서이다.

chunk를 사용하게 되면 내부적으로 묶어서 처리되기 때문에, 데이터가 어떻게 흘러가는지 직관적으로 파악하기 어렵다고 느꼈다.
그래서 현재는 chunk 없이 하나씩 처리하는 방식으로 동작을 확인하고 있다.

현재 Writer에서는 RDB에 데이터를 저장하고 있다. 레디스에 넣든, 로그로 찍든, 파일로 만들든 그것은 크게 중요하지 않다.
결국 Writer의 역할은 "어딘가에 기록한다"는 점에서 동일하다.

여기서 중요한 포인트는 따로 있다. 바로 chunk 단위로 데이터가 처리된다는 점이다.
이제 한번 실행해보자. 현재는 스케줄링이 아닌, 수동으로 배치를 실행하고 있는 상태이다.

확인을 해보면, 약 230개의 데이터가 추가적으로 쌓이고 있는 것을 확인할 수 있다. 이 과정을 통해 Reader → Processor → Writer까지의 전체 흐름이 정상적으로 동작한다는 것을 확인할 수 있었다. 이렇게 해서 배치의 기본 구성 요소인 Reader, Processor, Writer를 모두 살펴보았다. 하지만 그렇다고 해서 배치에 대한 학습이 끝난 것은 아니다.

다음 단계에서는 배치를 구성하는 핵심 개념인 Job, Step, 그리고 Chunk에 대해 조금 더 자세하게 알아보려고 한다.

카프카의 설정은 진짜일까?? - offset(1)

klom — Wed, 8 Apr 2026 23:27:21 +0900

원래 시나리오대로면, producer를 전부 끝내고 나서 consumer를 학습하려고 하였지만 살짝 우회하기로 결정하였습니다. 그 이유가 뭐냐면 카프카의 주요 특징중 하나가 offset으로 알고 있습니다. 제가 알기로 offset은 카프카(브로커)에서 값을 읽을때 특정 부분까지 읽도록 하는걸로 알고 있습니다. 물론 이게 틀린내용일 수 도 있지만, 뭐 상관없습니다. 다시 제대로 학습하면 되는거니까요. 시작해봅시다.

그래서 offset이 뭐냐면..

offset은 메시지의 위치를 나타내는 번호입니다. kafkasms 메시지를 다음과 같이 저장합니다.

[0] [1] [2] [3] [4] ...

여기서 숫자가 바로 offset입니다. 즉, kafka는 메시지를 순서대로 쌓고, index처럼 offset을 붙입니다.
또한, kafka는 메시지를 삭제하지 않습니다. 대신 어디까지 읽었는지만 관리합니다.

그렇다면, offset은 어떻게 관리가 되어질까요?

offset은 기본적으로 kafka에서 관리하지만, 언제 기록할지는 consumer가 결정하게 됩니다.

그림을 이렇게 그릴 수 있습니다. kafka의 구조를 이해할 때, kafka는 곧 broker라고 볼 수 있습니다.
즉, kafka는 메시지를 저장하고 관리하는 서버 역할을 수행합니다.

따라서 kafka를 이야기할 때는 단일 애플리케이션이라기보다는 메시지를 저장하는 Broker의 집합으로 이해하는 것이 더 적절합니다.
반면에 producer와 consumer는 kafka 내부에 포함된 요소가 아니라, kafka와 통신하는 별도의 애플리케이션입니다.

producer는 메시지를 kafka로 전송하는 역할을 하고
consumer는 kafka에 저장된 메시지를 읽어가는 역할을 합니다

정리하면, kafka는 데이터를 저장하는 broker이고,
producer와 consumer는 그 데이터를 주고받기 위해 kafka와 상호작용하는 외부 애플리케이션이라고 볼 수 있습니다.

하지만 여기서 한 가지 이상한 점이 있습니다. offset은 kafka에서 메시지를 순서대로 저장하면서,
각 메시지에 index처럼 붙는 값이라고 알고 있습니다. 즉, broker가 관리하는 값이라고 볼 수 있습니다.
그런데 실제로 동작을 살펴보면, offset의 흐름은 오히려 consumer가 주도하는 것처럼 느껴집니다.

어디까지 읽을지 결정하는 것도 consumer이고
언제 offset을 기록할지도 consumer가 결정합니다

이쯤 되면 자연스럽게 이런 의문이 생깁니다.
offset은 kafka(Broker)의 것일까요, 아니면 consumer의 것일까요?

핵심은 소유가 아니라 역할 분리입니다

이 질문의 답은 둘 중 하나가 아니라, 역할이 나뉘어 있다고 보는 것이 더 정확합니다.

offset 자체는 broker에 저장됩니다
하지만 offset을 언제, 어디까지 올릴지는 consumer가 결정합니다

즉, offset은 kafka가 보관하고, consumer가 정의하는 값입니다.

좋습니다. consumer가 offset을 정의한다고 하였는데 왜 정의를 하는걸까요? 이미 broker에 순서가 저장이 되었는데 말이죠.
broker에서 메시지를 순서대로 쌓고 offset을 붙입니다. 여기까지는 데이터를 저장하는 역할입니다.
하지만 여기에는 한 가지 중요한 정보가 빠져잇습니다. 이 메시지는 처리가 되었는가 라는 정보입니다.

핵심은 다음과 같이 정리할 수 있습니다. broker는 메시지를 저장하는 역할을 하고,
consumer는 해당 메시지를 실제로 처리하는 역할을 수행합니다.
이 둘은 단순히 데이터를 주고받는 관계가 아니라, "저장"과 "처리"라는 서로 다른 책임을 가진 구조입니다.
그렇다면 consumer는 메시지를 수신한 이후, 자신의 처리 상태를 broker에게 알려줄 필요가 있습니다.

왜냐하면 broker는 메시지를 쌓아두기만 할 뿐, 해당 메시지가 실제로 처리되었는지에 대해서는 알 수 없기 때문입니다.
따라서 consumer는 다음과 같이 동작합니다. "나는 이 메시지들(offset 기준)을 이미 처리했습니다."
이 정보를 Broker에 전달하는 행위가 바로 offset commit입니다.

그렇다면, 저장과 처리를 구분하는 이유가 무엇일까요?

그 이유는 앞서 말했듯이, broker와 consumer가 서로 다른 애플리케이션으로 동작하기 때문입니다.

broker는 메시지를 저장하고 offset을 부여하는 역할만 수행합니다. 하지만 해당 메시지가 실제로 사용되었는지,
즉 처리되었는지 여부는 알 수 없습니다. 이 말은 곧, 이런 상황을 의미합니다.
broker는 메시지를 전달할 수는 있지만, 그 메시지가 성공적으로 처리되었는지는 책임지지 않는습니다.
따라서 Consumer는 단순히 메시지를 읽는 것에서 끝나는 것이 아니라, 자신이 어디까지 처리했는지를 명확하게 알려줄 필요가 있습니다.

즉, "나는 여기까지(offset 기준) 처리 완료했습니다" 라는 상태를 Broker에 전달해야 합니다.
이 과정을 통해서만 kafka는 이후에 어디부터 다시 읽어야 하는지를 판단할 수 있습니다.

이 행위를 offset을 commit한다고 표현합니다. 즉, consumer가 처리한 위치를 기록하여 이후에는 해당 지점 이후부터 메시지를 읽을 수 있도록 만드는 과정입니다. 다음 시간에는 offset이 Broker에 실제로 어떻게 저장되는지,그리고 offset commit이 어떤 방식으로 이루어지는지 이 두 가지를 중심으로 살펴보도록 하겠습니다.

Batch- Reader

klom — Tue, 7 Apr 2026 23:43:02 +0900

저번 글에서는 스프링 배치를 왜 사용하는지에 대해 살펴보았다. 일괄 작업이 필요한 경우, 배치는 효과적인 선택지가 될 수 있다.
배치의 기본 흐름은 단순하다. 데이터를 읽고, 가공한 뒤, 저장하는 것이다. 데이터의 출처가 어디든 상관없이, 해당 위치에서 데이터를 읽어오고, 배치 애플리케이션 내부에서 가공한 뒤, 최종 결과를 저장한다. 여기서 중요한 특징 중 하나는 배치가 주로 스케줄링 기반으로 실행된다는 점이다. 즉, 정해진 시간에 자동으로 실행되며, 사용자 요청과는 분리되어 동작한다.

이 말은 곧, 배치가 처리하는 작업은 실시간으로 즉시 반영될 필요가 없으며, 대량의 데이터를 나누어 처리하더라도 서비스에 직접적인 영향을 주지 않는다는 의미다. 따라서 배치는 뒤에서 안정적으로 대량 데이터를 처리하는 데 적합한 방식이라고 볼 수 있다.

이제부터는 스프링 배치에 대해 본격적으로 학습해보려고 한다. 첫 번째로 살펴볼 것은 Reader이다.

Reader의 역할은 무엇일까?

Reader의 역할은 단순하다. 데이터를 가져오는 것이다.
좀 더 정확하게 말하면, 어딘가에 쌓여 있는 데이터를 하나씩 꺼내오는 것을 의미한다.

그렇다면 왜 데이터를 하나씩 처리할까? 배치는 대량의 데이터를 처리하는 방식이라고 배워왔다.

여기서 중요한 점은, 수천 건, 수만 건의 데이터를 한 번에 모두 가져오게 되면
메모리 부담이 커지고, 처리 흐름을 관리하기도 어려워진다는 것이다.

그래서 Reader는 데이터를 한 건씩, 혹은 스트림처럼 순차적으로 읽어온다.
이 방식은 메모리 사용을 줄이고, 대량 데이터를 안정적으로 처리할 수 있게 해준다.

또한 배치는 실시간 처리가 목적이 아니기 때문에,
즉시 결과를 확인하기보다는 전체 데이터를 끝까지 안정적으로 처리하는 것이 더 중요하다.
정리하면, Reader의 역할은 다음과 같다. 어딘가에 저장된 대량의 데이터를, 순차적으로 하나씩 읽어와 다음 단계로 전달하는 것이다.

한번 실제로 사용해보자.

현재 외부 api를 통해 데이터를 가져오고 있다. 여기서 의문이 드는 사실이 있다.
데이터를 그냥 가져와서 저장하면 되는것이 아닌가 라는 생각이 들 수 있다.

이유는 다음과 같다.
데이터는 항상 그대로 쓸 수 없다. 외부 API에서 가져온 데이터는 우리 서비스의 데이터 구조와 다를 수 있고, 불필요한 값이 포함되어 있을 수 있으며, 추가적인 계산이나 변환이 필요할 수 도 있다.

막상 이 데이터를 쓰기에는 뭔가 애매하다는 생각이 들 수 있다. 즉, 단순 저장이 아니라 가공 과정이 반드시 필요하다.
또, 가져온 데이터를 바로 변환하면 되지 않나 생각할 수 있다. 하지만, 대량 처리 시 안정성이 중요하다.
데이터가 많아질수록 중간에 실패할 수 있고 일부만 저장될 수 있으며 재처리가 필요할 수 있다.
이때 단순 저장 구조로는 대응이 어렵다. 다른 이유도 있겠지만 지금 파트는 Reader이기 때문에 이쯤하고 넘어가겠다.

그렇다면 어떻게, 데이터를 가져올까?

앞서 살펴본 예시는 외부 API를 통해 데이터를 가져오는 방식이었다. 하지만 지금부터 살펴볼 내용은, 외부 API의 결과를 단순히 사용하는 것이 아니라, 스프링 배치에서 데이터를 읽어오는 방식에 대해 이야기해보려고 한다.

즉, 데이터의 출처가 어디인지보다 중요한 것은 배치 내부에서 이 데이터를 어떤 방식으로 읽어오고 처리하느냐이다.
이러한 관점에서, 스프링 배치는 데이터를 읽기 위해 ItemReader라는 개념을 제공한다.
이제 이 ItemReader를 통해 데이터를 어떻게 읽어오는지 살펴보자.

ItemReader은 무엇인가?

ItemReader는 스프링 배치에서 데이터를 읽기 위한 인터페이스이다.
배치 처리의 첫 단계에서 동작하며, 어딘가에 저장되어 있는 데이터를 하나씩 가져오는 역할을 한다.

여기서 중요한 점은, ItemReader는 데이터를 가공하거나 저장하지 않는다는 것이다. 오직 데이터를 읽어오는 것에만 집중한다.
또한 ItemReader는 데이터를 한 번에 모두 가져오는 것이 아니라, read() 메서드를 통해 한 건씩 순차적으로 반환하는 방식으로 동작한다.
이러한 구조 덕분에, 대량의 데이터를 처리하더라도 메모리 사용을 최소화하면서 안정적으로 작업을 수행할 수 있다.
정리하면, ItemReader는 배치에서 데이터를 읽어오는 시작점이자, 데이터를 하나씩 다음 단계로 전달하는 역할을 한다.

배치는 대량의 데이터를 처리하는 방식이다.
수천 건, 수만 건의 데이터를 한 번에 모두 메모리에 올려 처리하게 되면, 메모리 부담이 커지고 처리 흐름을 제어하기도 어려워진다.
이러한 이유로 Reader는 데이터를 한 번에 모두 가져오는 것이 아니라, 필요한 시점에 하나씩 꺼내어 다음 단계로 전달하는 방식으로 동작한다. 즉, Reader는 단순히 데이터를 조회하는 것이 아니라, 처리 흐름에 맞게 데이터를 공급하는 역할을 수행한다고 볼 수 있다.

이제 이 Reader를 실제로 어떻게 사용할 수 있는지 살펴보자.

ItemReader를 통해 데이터를 하나씩 읽는 방식과, 외부 API를 통해 데이터를 가져오는 방식은 이미 살펴보았다.
하지만 아직 이 두 가지가 어떻게 연결되는지는 살펴보지 않았다. 현재 코드에서는 이 연결 지점에서 ListItemReader 를 사용하고 있다.
즉, 외부 API를 통해 조회한 데이터를 리스트로 만든 뒤, ListItemReader가 이를 하나씩 꺼내어 ItemReader처럼 동작하도록 구성하고 있는 것이다.

그렇다면, 이렇게 데이터를 가져오는 방법은 ListItemReader만 존재할까?

물론 그렇지 않다.
스프링 배치는 다양한 데이터 소스에 맞게 여러 종류의 ItemReader를 제공하고 있다.
ListItemReader는 그 중 하나일 뿐이며, 상황에 따라 더 적합한 Reader를 선택할 수 있다.

예를 들어, 데이터베이스에서 직접 조회하는 경우에는 JdbcCursorItemReader나 JdbcPagingItemReader를 사용할 수 있고,
파일을 읽는 경우에는 FlatFileItemReader를 사용할 수 있다. 즉, ListItemReader는 외부에서 이미 수집된 데이터를 처리할 때 유용한 방식이며, 데이터의 출처와 특성에 따라 다양한 Reader를 선택할 수 있다.

이에 대해서는 나중에 다시 정리해보자.

결론

배치의 첫 단계인 Reader에 대해 살펴보았다. 데이터가 어디에서 들어오고, 어떤 방식으로 읽히는지에 대해 학습해보았다.
다음 시간에는 Processor에 대해 알아보자.

인덱스 정리

klom — Mon, 6 Apr 2026 23:30:22 +0900

2026년 4월3일 면접을 보게 되었습니다. 그때 나왔던 질문중 하나가 인덱스에 대한 질문이었습니다. 과거에 인덱스를 활용해서 성능을 개선해본적이 있었냐는 질문이었습니다. 했었던거 같아 일단 답변은 하긴했었는데 정재되지 않았습니다. 버벅된게 아니라 무슨 답변을 했는지도 기억이 안나는 정도였으니까요. 저는 인덱스를 통해 읽기 성능을 올렸던적이 있었다고 답변하였는데 지금 생각해보면 이것도 애매한 답변이었던거 같습니다. 왜냐하면 성능을 올렸던적이 있었다면 정확한 수치가 필요했을텐데 그렇지 못했으니까요.

아무튼 제 경험을 토대로 인덱스를 정리를 해보겠습니다.

인덱스는 어떤 성능을 올릴 수 있을까?

기존 테스트..

인덱스 적용브랜드 Id만 인덱스를 거는 경우는 어떨까? 생각보다 속도는 비슷하게 나오는듯하다.요렇게 나왔는데 이건 안 거는거랑 비슷한거 같다라는 생각이 들었다.그래서 좋아요를 기준으로

b-programmer.tistory.com

인덱스는 다들 알다시피 읽기 성능을 올릴 수 있습니다. 위 글을 확인해보면 2250 ms -> 590.58ms 약 73.75%가 감소했다는것을 확인할 수 있었습니다. 하지만 문제는 이것을 왜 했는지 그거에 대한 논리가 부족하다는점입니다. 아무래도 학습이 주가 되었기 때문에 읽기 속도가 늘었다는 점만 확인되었을 뿐이죠. 그렇다면, 어떻게 표현할 수 있을까요?

이렇게 표현한다면 어떨까요?

특정 조회 API에서 평균 2250ms의 지연이 발생하였고, 실행 계획 분석 결과 Full Table Scan이 발생하고 있었습니다.
필터링과 정렬이 동시에 수행되는 쿼리 특성을 고려하여 인덱스를 설계하였고, 이를 통해 Index Scan 기반으로 실행 계획을 개선했습니다.
그 결과 Latency를 2250ms → 590.58ms로 약 73.75% 감소시킬 수 있었습니다.

그렇다면, 인덱스를 사용하면 어째서 Latency가 감소하나요?

인덱스를 사용하지 않는 경우, 조건에 맞는 데이터를 찾기 위해 테이블의 모든 데이터를 확인하게 됩니다.
이는 테이블 전체를 순차적으로 읽는 Full Table Scan으로 이어집니다.
반면 인덱스를 사용하면, 정렬된 구조를 기반으로 필요한 데이터의 위치를 빠르게 탐색할 수 있습니다.
따라서 전체 데이터를 읽지 않고도 원하는 데이터에 접근할 수 있어, 결과적으로 읽기 성능이 향상되고 Latency가 감소합니다.

그렇다고 해서 인덱스를 건다고 해서 무조건 Latency가 감소하는 것은 아닙니다.

인덱스는 조건에 따라 선택적으로 사용되기 때문에, 선택도가 낮거나 쿼리 패턴과 맞지 않는 경우에는 Full Table Scan이 더 효율적일 수 있습니다. 또한 인덱스가 많아질수록 쓰기 성능 저하와 추가적인 관리 비용이 발생할 수 있습니다.

어떤경우에 성능이 떨어지는지 자세하게 말씀해주세요.

조회 결과가 너무 많은 경우

예를 들어 전체 100만 건 중 70만 건을 읽어야 한다고 해봅시다.
이때 인덱스를 타면 인덱스에서 조건에 맞는 위치를 찾고 다시 실제 데이터 페이지로 이동해서 읽어야 합니다

이 과정을 랜덤 I/O가 많이 발생하는 구조라고 볼 수 있습니다.
반면, 그냥 Full Table Scan은 테이블을 처음부터 끝까지 순서대로 읽습니다. 데이터를 거의 다 봐야 한다면, 오히려 이런 순차 읽기가 더 효율적일 수 있습니다.

예를 들면 이런 경우입니다.

SELECT *
FROM users
WHERE gender = 'M';

만약 남성 데이터가 전체의 50% 이상이라면, 인덱스를 타도 절반 이상을 다시 테이블에서 읽어야 하므로 큰 이점이 없습니다.
즉, 조건은 있지만, 실제로는 너무 많은 행을 가져오는 쿼리에서는 인덱스가 큰 효과를 내지 못할 수 있습니다.

선택도가 낮은 컬럼에 인덱스를 건 경우

이건 방금 사례와 연결됩니다. 선택도는 간단히 말하면 이 컬럼이 데이터를 얼마나 잘 구분해 주는가입니다.

예를 들어 성별: 남/여, 상태값: Y/N, 삭제 여부: true/false이런 값은 종류가 적습니다.
즉, 한 값으로 조회했을 때 너무 많은 행이 걸립니다.

예를 들어 is_deleted = false 같은 조건은 대부분의 데이터가 false일 수 있습니다.
그럼 인덱스를 타더라도 거의 전체 데이터를 읽게 됩니다.
그래서 이런 컬럼 단독 인덱스는 기대만큼 성능이 안 나오는 경우가 많습니다.

**SELECT *처럼 인덱스만으로 처리가 안 되는 경우**

인덱스는 조건 검색에는 도움이 되지만, 실제 필요한 컬럼이 인덱스에 다 들어 있지 않으면 결국 테이블 본문까지 다시 읽어야 합니다.

예를 들어

SELECT *
FROM product
WHERE brand_id = 10;

brand_id에 인덱스가 있어도, *를 조회하면 나머지 컬럼들을 가져오기 위해 테이블 페이지를 다시 읽어야 합니다.
즉, 인덱스는 탐색은 빠르게 해주지만 최종적으로 읽어야 할 데이터가 많으면 비용이 커집니다.

반면 이런 경우는 좋습니다.

SELECT brand_id, likes
FROM product
WHERE brand_id = 10
ORDER BY likes DESC;

만약 인덱스가 (brand_id, likes)로 잡혀 있고 조회 컬럼도 그 안에 다 있다면, 테이블을 다시 안 보고 인덱스만 읽어도 됩니다.
이걸 보통 커버링 인덱스 관점에서 설명합니다.

정리하면 인덱스를 썼더라도, 결국 테이블을 다시 많이 읽어야 하면 느려질 수 있습니다.

복합 인덱스 순서가 쿼리와 맞지 않는 경우

복합 인덱스는 아무 순서로나 만들면 되는 게 아닙니다.

예를 들어 인덱스가 (brand_id, likes) 이렇게 잡혀 있다고 해봅시다.
그러면 보통은 brand_id를 먼저 활용한 뒤, 그 안에서 likes를 활용하는 구조가 됩니다.

이때 다음 쿼리는 잘 탈 가능성이 높습니다.

WHERE brand_id = ?
ORDER BY likes DESC

그런데 이런 쿼리는 애매할 수 있습니다.

WHERE likes > 100

왜냐하면 인덱스의 첫 컬럼인 brand_id를 안 쓰고 있기 때문입니다.
즉, 복합 인덱스는 앞쪽 컬럼부터 맞춰서 써야 효과가 큽니다.

함수나 연산 때문에 인덱스를 못 타는 경우

컬럼에 가공을 해버리면 DB가 기존 인덱스를 그대로 활용하기 어려워집니다.

예를 들어:

WHERE YEAR(created_at) = 2026

이렇게 쓰면 created_at 인덱스가 있어도 컬럼에 함수가 먼저 적용되기 때문에 인덱스를 제대로 못 탈 수 있습니다.

보통은 이렇게 바꾸는 편이 좋습니다.

WHERE created_at >= '2026-01-01'
AND created_at < '2027-01-01'

또 비슷하게

WHERE price + 10 > 100

이런 식으로 컬럼에 계산이 들어가도 인덱스 활용이 어렵습니다.
핵심은 인덱스는 원본 값 기준으로 정렬되어 있는데, 쿼리에서 값을 바꿔버리면 그 정렬 구조를 활용하기 어려워진다는 점입니다.

앞에 와일드카드가 붙는 LIKE 검색

이것도 매우 흔합니다.

WHERE name LIKE '%phone'

이 경우는 문자열 앞부분이 고정되어 있지 않기 때문에 B-Tree 인덱스로 어디서부터 찾아야 할지 애매합니다.
반면 이런 경우는 비교적 유리합니다.

WHERE name LIKE 'phone%'

앞부분이 정해져 있으면 인덱스 범위 탐색이 가능해집니다.

즉,

'abc%' → 인덱스 활용 가능성 높음
'%abc' → 인덱스 활용 어려움
'%abc%' → 보통 더 어려움

그래서 contains 검색이 많으면 일반 인덱스보다 풀텍스트 검색이나 별도 검색 엔진을 고민하기도 합니다.

정렬과 인덱스 방향이 맞지 않는 경우

인덱스는 검색뿐 아니라 정렬에도 영향을 줍니다. 그런데 정렬 조건이 인덱스 구조와 안 맞으면 결국 별도 정렬 작업이 필요해집니다.
예를 들어 필터는 brand_id로 하고, 정렬은 created_at인데
인덱스가 (brand_id, likes)라면 created_at 정렬에는 직접 도움이 안 됩니다.
그러면 DB는 조건으로 일부 찾고 결과를 따로 정렬하게 됩니다.
이 정렬 비용이 큰 경우 Latency가 늘어납니다.

즉, 필터링과 정렬을 함께 고려하지 않은 인덱스는 기대보다 효과가 약할 수 있습니다.

쓰기 작업이 많은 테이블

인덱스는 조회를 빠르게 해주지만, INSERT, UPDATE, DELETE 시에는 오히려 부담이 됩니다.
왜냐하면 테이블 데이터만 바꾸는 게 아니라 관련 인덱스도 같이 수정해야 하기 때문입니다.
예를 들어 인덱스가 1개면 한 번 수정할 걸, 인덱스가 5개면 5군데를 더 관리해야 할 수 있습니다.

주문
결제
로그성 이벤트
실시간 트래픽 테이블

처럼 쓰기 비중이 높은 곳에서는 인덱스를 많이 걸수록 전체 처리량이 떨어질 수 있습니다.
즉, 조회 한 번 빠르게 하려다가, 전체 쓰기 성능이 계속 손해 볼 수 있습니다.

업데이트가 잦은 컬럼에 인덱스를 건 경우

예를 들어 view_count, likes, updated_at처럼 값이 자주 바뀌는 컬럼에 인덱스를 걸면 인덱스 재정렬/유지 비용이 자주 발생합니다.
이 경우는 단순 조회뿐 아니라 수정이 반복될 때마다 인덱스도 계속 손봐야 하므로 부담이 커질 수 있습니다.
그래서 자주 바뀌는 컬럼은 정말 필요한 경우가 아니면 신중하게 봐야 합니다.

조인에서 인덱스가 어긋나는 경우

조인도 인덱스 영향이 큽니다.
예를 들어 두 테이블을 조인할 때 조인 컬럼에 인덱스가 없으면, 한쪽 데이터를 반복적으로 훑으면서 비용이 커질 수 있습니다.
특히 큰 테이블끼리 조인할 때 조인 키 인덱스가 없으면 성능이 급격히 나빠질 수 있습니다.
반대로 인덱스를 걸었더라도 조인 순서나 필터 조건이 맞지 않으면 기대만큼 개선이 안 될 수도 있습니다.

결국, 인덱스는 항상 Latency를 줄이는 것이 아닙니다.
조회 대상이 너무 많거나, 선택도가 낮은 컬럼에 인덱스를 건 경우에는 효과가 작을 수 있습니다.
또한 함수 사용, 와일드카드 LIKE, 복합 인덱스 순서 불일치처럼 쿼리 패턴이 인덱스 구조와 맞지 않으면 인덱스를 제대로 활용하지 못합니다. 반대로 인덱스가 많아지면 INSERT/UPDATE/DELETE 시 유지 비용이 증가해 전체 성능이 저하될 수도 있습니다.

이제 정리할것은 2가지정도 남은것으로 확인되었습니다.

1. 커버링 인덱스
2. 함수에는 인덱스가 먹히지 않는 이유
이 두개는 간단하게 작성하고 넘어가겠습니다.~

커버링 인덱스는 쿼리에 필요한 모든 컬럼을 인덱스만으로 해결하는 것을 뜻합니다.
함수에 인덱스가 먹히지 않는 이유는 인덱스는 원본 값 기준 정렬인데, 함수는 값을 바꿔버리기 때문에 그 정렬을 못 쓴다

결론

인덱스를 사용하면 어떻게 성능이 오르는지 언제 사용하는지에 대해 알아봤습니다. 만약에, 인덱스 관련 질문이 들어온다면, 일단은 다음과 같이 답변을 할것 같습니다.

배치는 언제 사용이 되어질까?

klom — Sat, 4 Apr 2026 22:10:52 +0900

이제는 레디스를 언제 쓰고, 카프카를 언제 써야 하는지에 대해서는 어느 정도 감이 잡힌 것 같다. 그런데 이상하게도 이 두 기술보다 더 직관적으로 느껴질 것 같은 스프링 배치는 여전히 잘 와닿지 않는다. 분명 사용해본 적은 있지만, 전체 흐름이 머릿속에 자연스럽게 그려지지는 않는다. 아마 구조가 복잡해서일 수도 있지만, 그보다 더 큰 이유는 내가 배치의 핵심을 제대로 이해하지 못했기 때문일지도 모른다. 그래서 이번 기회에 스프링 배치의 본질을 제대로 짚고 넘어가보려고 한다.

그래서 본질이 뭔데?

google은 배치를 다음과 같이 설명하고 있습니다.

배치는 데이터를 한 번에 모아서 처리하는 방식으로 이해할 수 있다.
좀 더 정확하게 말하면, 이미 쌓여있는 데이터를 가져와 처리하는 것을 의미한다.

그렇다면 이 데이터는 어디에서 들어올까?

결론부터 말하면, 데이터의 출처는 크게 중요하지 않다. 데이터베이스, 파일, 외부 API, 메시지 큐 등 다양한 곳에서 유입될 수 있다.
하지만 배치에서 더 중요한 것은 데이터가 어디서 왔는지가 아니라, 쌓인 데이터를 어떤 방식으로 안정적으로 처리할 것인가이다.
즉, 배치의 본질은 데이터의 입력 경로가 아니라 대량의 데이터를 어떻게 읽고, 가공하고, 끝까지 정확하게 처리할 것인가에 있다.

그렇다면, 어떻게 데이터를 처리할 수 있을까?

배치는 복잡해 보이지만, 본질적인 처리 방식은 의외로 단순하다.
바로 읽고, 가공하고, 저장하는 것이다.
즉, 배치의 기본 흐름은 읽기 → 가공 → 저장 으로 정리할 수 있다.
그런데 가만히 생각해보면, 이런 과정은 반복문만으로도 충분히 구현할 수 있어 보인다.

List<?> list = new ArrayList<>();
for (data : list) {
process(data);
}

데이터를 읽고, 가공하고, 저장한다. 이 자체만 놓고 보면 분명 원하는 처리는 가능하다.
하지만 이것은 어디까지나 동작에 가깝다.

반면 스프링 배치는 단순히 동작만 수행하는 데서 끝나지 않는다.
어디까지 처리했는지 기록하고, 중간에 실패하면 다시 이어서 실행할 수 있으며, 처리 결과를 남기고,
운영자가 전체 흐름을 추적할 수 있도록 돕는다.
즉, 스프링 배치의 핵심은 단순한 반복 처리가 아니라, 동작을 운영 가능한 시스템으로 만드는 것에 있다.

마무리

대략적으로 배치에 대해 학습을 진행하였습니다. 배치를 어떻게 사용하면 좋을까 또, 왜 사용하는게 좋을지에 대해 고민을 했던거 같습니다.
짧게 쓴글이지만, 추후에 어떻게 읽고 하고 어떤것을 사용하고 처리는 어떻게 하는지 심도 깊게 학습해볼 예정입니다.

LLM이란 무엇일까?

klom — Wed, 1 Apr 2026 17:35:34 +0900

최근 ChatGPT, Gemini, Grok 등 다양한 LLM 서비스가 빠르게 확산되고 있습니다. LLM(Large Language Model)은 말 그대로 대규모 언어 모델을 의미하며, 인간의 언어를 이해하고 생성할 수 있는 인공지능 기술입니다. 불과 몇 년 전까지만 해도 LLM은 일부 기업이나 연구 기관만 다룰 수 있는 고난도 기술이었습니다. 하지만 현재는 상황이 완전히 달라졌습니다. 누구나 손쉽게 사용할 수 있고, 나아가 직접 활용하거나 구축까지 가능한 수준으로 대중화되었습니다. 지금은 마치 전기나 클라우드처럼 LLM을 '구독'하여 사용하는 시대입니다. 그러나 머지않아 개인이 LLM을 기반으로 서비스를 만들고, 이를 통해 직접 가치를 창출하는 시대가 올지도 모릅니다. 이러한 변화 속에서 LLM을 단순히 사용하는 것을 넘어, 그 구조와 동작 방식을 이해하는 것은 매우 중요하다고 판단했습니다. 따라서 본 글에서는 LLM이 무엇인지에 대해 기초부터 정리하며 학습해보고자 합니다.

LLM이 등장하기 이전

LLM이 등장하기 이전에는 자연어 처리를 위해 사람이 직접 정의한 규칙 기반 방식이나, 제한적인 패턴 인식 기술이 주로 사용되었습니다.
이러한 방식은 특정 패턴을 처리하는 데에는 효과적이었지만, 문맥을 이해하거나 다양한 표현을 유연하게 처리하는 데에는 한계가 있었습니다.

이후 이러한 한계를 보완하기 위해 통계 기반 모델이 등장하였습니다.
대표적으로 n-gram 모델은 이전 단어들의 등장 확률을 기반으로 다음 단어를 예측하는 방식입니다.

예를 들어, "나는 오늘 밥을"이라는 문장이 주어지면, 학습 데이터에서 "밥을 먹다"라는 표현이 자주 등장했기 때문에
"먹었다"가 나올 확률이 높다고 판단하는 방식입니다.
하지만 n-gram 모델은 앞의 일부 단어만 참고할 수 있다는 한계가 있었고, 문장이 길어질수록 전체 의미를 제대로 반영하기 어려웠습니다.
이러한 문제를 해결하기 위해 등장한 것이 RNN(Recurrent Neural Network)입니다.
RNN은 이전 정보를 순차적으로 전달하면서 문맥을 반영하려는 구조를 가지고 있습니다.
그러나 RNN 역시 다음과 같은 한계를 가지고 있었습니다.

문장이 길어질수록 앞의 정보를 잃어버리는 문제
학습이 어렵고 속도가 느린 구조
장기 의존성(Long-term dependency) 문제

이처럼 자연어 처리 기술은 점진적으로 발전해왔지만, 여전히 문장을 전체적으로 이해하기보다는
부분적인 정보나 패턴을 기반으로 처리하는 수준에 머물러 있었습니다.

이러한 한계를 극복하기 위해 등장한 것이 바로 Transformer 기반의 LLM입니다.

Transformer은 무엇인가?

Transformer는 자연어 처리에서 사용되는 딥러닝 모델 구조로, 문장을 순차적으로 처리하지 않고 전체를 한 번에 이해하도록 설계된 모델입니다. 기존의 RNN은 단어를 순서대로 처리하는 구조를 가지고 있었기 때문에 문장이 길어질수록
앞의 정보를 점점 잃어버리는 한계가 있었습니다.
이러한 문제를 해결하기 위해 등장한 것이 Transformer이며, 핵심은 Self-Attention 메커니즘에 있습니다.

Self-Attention이란?

Self-Attention은 문장 안의 단어들이 서로를 참고하여 각 단어 간의 관계와 중요도를 계산하는 방식입니다.
예를 들어, "나는 어제 도서관에서 책을 읽었다"라는 문장에서 "읽었다"라는 단어는
"책", "도서관"과의 관계를 함께 고려하여 의미가 결정됩니다.
즉, Transformer는 단어를 순서대로 이해하는 것이 아니라 문장 전체의 관계 속에서 의미를 파악합니다.

그래서 LLM이 뭔데..??

LLM(Large Language Model)은 사람의 언어를 이해하고, 생성하며, 자연스럽게 응답하도록 설계된 신경망 모델입니다.

여기서 "대규모(Large)"는 단순히 모델의 크기만을 의미하는 것이 아니라, 수십억 개 이상의 파라미터와 방대한 텍스트 데이터로 학습되었다는 의미를 포함합니다. LLM은 입력된 문장을 기반으로 다음에 올 단어를 확률적으로 예측하는 방식으로 동작하며,
이 과정에서 문장 전체의 맥락을 반영하기 위해 Transformer 구조를 사용합니다.

특히 Transformer의 핵심인 Self-Attention 메커니즘을 통해 입력 문장의 각 요소들 간의 관계를 고려하며 중요한 정보에 선택적으로 집중할 수 있습니다. 현재 AI 분야에서는 머신러닝과 딥러닝 기반 접근 방식이 주를 이루고 있지만,
과거에는 규칙 기반 시스템, 전문가 시스템, 퍼지 논리, 기호 추론과 같은 다양한 방식들도 함께 연구되어 왔습니다.
LLM은 이러한 전통적인 접근 방식과 달리, 데이터를 기반으로 패턴을 학습하고 일반화할 수 있는 모델이라는 점에서 큰 차이를 가집니다.

요약

LLM은 최근 ChatGPT, Gemini, Grok 등을 통해 빠르게 대중화된 기술이다.
과거에는 규칙 기반, 패턴 인식, n-gram, RNN등과 같은 방식으로 자연어를 처리했지만 문맥 이해에 한계가 있었다.
이러한 한계를 해결하기 위해 Transformer 구조가 등장했고, Self-Attention을 통해 문장 전체의 관계를 이해할 수 있게 되었다.
LLM은 이 Transformer를 기반으로 대규모 데이터와 파라미터를 활용해 다음 단어를 확률적으로 예측하는 모델이다.
기존 방식과 달리 데이터 기반으로 패턴을 학습하고 일반화할 수 있다는 점이 핵심 차이이다.

로드벨런서 vs API 게이트웨이

klom — Tue, 31 Mar 2026 22:26:07 +0900

개발을 하다 보면 헷갈리는 용어를 자주 마주하게 됩니다. 대표적인 예가 바로 로드 밸런서와 API 게이트웨이입니다. 이름만 보면 서로 전혀 다른 역할을 하는 것처럼 느껴집니다. 하지만 실제로 어떤 일을 하는지 떠올려 보면, 둘 다 "요청을 전달한다"는 공통점 때문에 비슷한 개념처럼 느껴지기도 합니다. 이러한 혼란은 개념을 충분히 분리해서 이해하지 못했을 때 자연스럽게 발생합니다. 이번 글에서는 로드 밸런서와 API 게이트웨이의 차이점과 공통점을 명확하게 정리해보겠습니다.

그렇다면, 이 두 개념이 왜 혼동되는지 그 이유부터 살펴보겠습니다.

두 기술 모두 클라이언트의 요청을 받아 다른 서버로 전달한다는 공통점을 가지고 있습니다.
이 과정에서 "중간에서 요청을 처리한다"는 점 때문에 두 개념이 비슷하게 느껴질 수 있습니다.
예를 들어, 클라이언트가 요청을 보내면 로드 밸런서든 API 게이트웨이든 직접 요청을 처리하는 것이 아니라, 다른 서버로 전달합니다.
즉, 두 기술 모두 시스템의 앞단에서 동작하며, 요청을 적절한 위치로 보내는 역할을 수행합니다.
또한, 두 기술 모두 트래픽을 분산시키는 것처럼 보일 수 있습니다.
로드 밸런서는 실제로 여러 서버로 요청을 분산시키고, API 게이트웨이 역시 여러 서비스로 요청을 라우팅하기 때문입니다.
아래 그림을 보면 HTTPS 요청이 로드 밸런서를 통해 여러 서버로 분산되어 전달되는 것을 확인할 수 있습니다.

위 그림을 커다란 이미지로 다시 그려보면 다음과 같습니다.

그렇다면 무엇이 다를까요? 바로 사각형으로 그린 부분과 무엇이 분산이 되어지는지가 다릅니다.

로드 벨런서

로드 밸런서는 클라이언트로부터 들어오는 요청을 여러 서버로 분산시켜, 특정 서버에 트래픽이 몰리지 않도록 하는 역할을 수행합니다.

사용자가 증가하거나 트래픽이 급증하는 상황에서는 하나의 서버만으로 모든 요청을 처리하기 어렵습니다.
이때 로드 밸런서를 앞단에 두면 요청을 여러 서버로 나누어 처리할 수 있기 때문에, 전체 시스템의 안정성과 처리량을 향상시킬 수 있습니다.

그렇다면 로드 밸런서가 왜 필요할까요?

서버를 여러 대로 확장하더라도, 클라이언트는 어떤 서버로 요청을 보내야 할지 알 수 없습니다.
또한 사용자 입장에서 모든 서버의 주소를 기억하는 것도 비효율적입니다.

이러한 상황에서는 결국 특정 서버로만 요청이 집중될 가능성이 높아지고, 서버를 여러 대로 운영하는 의미가 사라지게 됩니다.

로드 밸런서는 이러한 문제를 해결하기 위해 존재합니다. 클라이언트는 하나의 진입점만 알고 있으면 되고, 로드 밸런서는 내부적으로 여러 서버에 요청을 균등하게 분산시켜 줍니다. 대표적인 예로는 Nginx가 있습니다.

API 게이트 웨이

그렇다면, API 게이트 웨이는 어떨까요?

API 게이트웨이는 클라이언트의 요청을 받아 적절한 서비스로 전달하는 역할을 수행합니다.
하지만 단순히 요청을 전달하는 것에 그치지 않고, 요청을 처리하는 과정에서 다양한 로직을 함께 수행합니다.

예를 들어, 클라이언트의 요청이 들어오면 API 게이트웨이는 먼저 인증 및 인가를 확인하고, 요청의 유효성을 검증합니다.
이후 요청을 적절한 서비스로 라우팅하며, 필요에 따라 요청이나 응답을 변환하기도 합니다.

그렇다면 API 게이트웨이는 왜 필요할까요?

마이크로서비스 아키텍처에서는 여러 개의 서비스가 존재하게 됩니다. 이때 클라이언트가 각각의 서비스에 직접 요청을 보내게 되면,
서비스의 주소를 모두 알아야 하고, 인증이나 로깅과 같은 공통 기능도 각각 처리해야 하는 문제가 발생합니다.

API 게이트웨이는 이러한 문제를 해결하기 위해 존재합니다. 클라이언트는 하나의 진입점만 호출하면 되고, API 게이트웨이가 내부적으로 적절한 서비스로 요청을 전달합니다. 또한 인증, 로깅, 유량 제어와 같은 공통 기능을 중앙에서 관리할 수 있습니다.
대표적으로는 Spring Cloud Gateway와 Kong 등이 있습니다.

결론

간단하게 로드 밸런서와 API 게이트웨이의 공통점과 차이점에 대해 살펴보았습니다. 제가 생각하는 두 기술의 가장 큰 차이는 분산과 관리입니다. 로드 밸런서는 여러 서버를 하나의 서버처럼 사용할 수 있도록, 앞단에서 트래픽을 통합하고 이를 각 서버에 균등하게 분산시키는 역할을 합니다. 반면, API 게이트웨이는 주로 MSA 환경에서 사용되며, 여러 서비스(도메인)를 하나의 진입점으로 통합하고 인증, 라우팅, 로깅과 같은 기능을 통해 이를 관리하는 역할을 수행합니다. 결국 두 기술은 모두 요청을 전달하는 중간 계층이라는 공통점을 가지지만, 로드 밸런서는 트래픽 분산, API 게이트웨이는 요청 관리와 제어에 초점을 둔다는 차이가 있습니다. 멀리서 보면 비슷해 보이지만, 역할과 책임을 기준으로 보면 명확하게 구분되는 기술이라고 볼 수 있습니다.

출처
https://blog.bytebytego.com/p/ep208-load-balancer-vs-api-gateway

리플렉션 deep 하게 JDK관점에서 풀어보기

klom — Mon, 30 Mar 2026 23:13:05 +0900

이전에 여러 객체를 프록시로 생성하거나, 프록시 객체를 활용하는 과정에서 Java는 자연스럽게 리플렉션(Reflection)이라는 기술을 사용하게 됩니다.

문제 발견: LazyConnectionDataSourceProxy 톺아보기

read-only일때 replica 사용하게 하기master-slave 구조 이해하기DB에서 master-slave 형태로 변경하다는 뜻은 읽기 전용과 쓰기 전용을 분리한다는 의미입니다.최근에는 master-slave라는 용어보다는 primary-repl

b-programmer.tistory.com

분명... slow쿼리를 모니터링하려고 했는데... 어째서...

return wrapPreparedStatement(preparedStatement, sql); 슬로쿼리 모니터링 인터페이스 제작슬로 쿼리를 모니터링 인터페이스를 만들기위해 어떤 작업을 해야 할까요? slow 쿼리는 어떻게 탐지할 수 있을까?Sl

b-programmer.tistory.com

리플렉션은 간단히 말하면, 런타임 시점에 클래스의 구조를 조회하고, 메서드나 필드에 접근하여 동적으로 실행할 수 있는 기능입니다.
이를 통해 일반적인 코드에서는 접근할 수 없는 private 메서드나 필드에도 접근이 가능합니다. 대표적으로 java.lang.Class, java.lang.reflect.Method 와 같은 API를 통해 클래스의 메타데이터를 조회하고 실행할 수 있습니다. 이러한 특성만 보면 "JVM을 조작한다"는 느낌 때문에 위험한 기술처럼 보일 수 있습니다. 하지만 정확히 말하면, 리플렉션은 JVM 자체를 변경하는 것이 아니라 JVM이 제공하는 메타데이터를 기반으로 객체를 동적으로 제어하는 기능에 가깝습니다.

그렇다면, 리플렉션 기술은 왜 필요하고, 어디에서 사용할까?

사실, 이 기술을 직접적으로 사용하는 일은 거의 없습니다. 대부분은 이미 구현되어 있는 프레임워크나 라이브러리를 통해 간접적으로 사용하게 됩니다. 그럼에도 불구하고 리플렉션을 알아야 하는 이유는 명확합니다. 우리가 사용하는 많은 기능들이, 내부적으로 리플렉션 위에서 동작하기 때문입니다. 예를 들어 Spring Framework 의 DI, AOP, 애노테이션 기반 기능들은 모두 런타임에 객체를 분석하고 제어해야 하는데, 이 과정에서 리플렉션이 적극적으로 사용됩니다. 또한 java.lang.reflect.Proxy 를 기반으로 한 동적 프록시 역시 리플렉션을 통해 메서드 호출을 가로채고 위임하는 구조로 동작합니다.

다음과 같은 의문이 들 수 있습니다. "이미 잘 만들어진 추상화가 있는데, 굳이 내부 구현까지 알아야 할까?"
이 질문에 대한 답은 명확합니다. 추상화는 편의를 제공하지만, 문제 상황에서는 원인을 숨기기 때문입니다.

실제로 이러한 문제를 경험한 적이 있습니다. readOnly 트랜잭션이 적용되어 있다면 일반적으로 Replica DB로 라우팅될 것이라고 기대합니다. 하지만 예상과 달리 Primary DB가 사용되는 문제가 발생했습니다. 원인을 분석해보니, 트랜잭션 속성이 적용되기 전에
Connection이 먼저 생성되면서 라우팅이 잘못 이루어지고 있었습니다. 이 문제를 해결하기 위해,
Connection 생성 시점을 트랜잭션 속성이 반영된 이후로 미루는 방식을 선택했습니다. 구체적으로 LazyConnectionDataSourceProxy 를 활용하여 올바른 시점에 Connection이 생성되도록 구조를 변경했습니다.

이제 실제로 리플렉션이 어떻게 동작하는지 살펴보겠습니다.

앞서 리플렉션은 런타임에 클래스의 구조를 조회하고, 메서드나 필드에 접근하여 동적으로 실행할 수 있는 기능이라고 설명했습니다.
그렇다면 내부에서는 어떤 흐름으로 동작하고 있을까요?

리플렉션의 시작은 항상 java.lang.Class 객체로부터 시작합니다.

이는 객체를 생성할 때 클래스를 정의하는 것과 비슷한 개념으로 볼 수 있습니다.
다만 중요한 차이는, 리플렉션에서는 실제 객체 생성 여부와 관계없이 클래스의 구조에 접근할 수 있다는 점입니다.

예를 들어 다음과 같은 클래스가 있다고 가정해보겠습니다.

Class Person {
  private int num;

  public Persion(int num) {
   this.num = num;
  }
  
  public void methods(int a) {
   // 암튼 구현
  }

}

하지만 리플렉션을 사용하면, 객체를 생성하지 않더라도 Class 객체를 통해 클래스의 구조에 접근할 수 있습니다.

Class<?> clazz = Person.class;

이렇게 얻은 Class 객체를 통해 필드, 메서드, 생성자 정보를 조회할 수 있습니다.

리플렉션을 통해 접근할 수 있는 주요 요소는 크게 세 가지입니다.

필드(Field)
메서드(Method)
생성자(Constructor)

각 요소는 서로 다른 역할을 가지고 있습니다.

필드는 객체의 상태를 나타내며, 리플렉션을 통해 private 필드까지 접근하여 값을 조회하거나 변경할 수 있습니다.
생성자는 객체를 생성하는 역할을 하며, 리플렉션을 통해 특정 생성자를 선택하여 동적으로 객체를 생성할 수 있습니다.
하지만 실제로 리플렉션에서 가장 많이 사용되는 부분은 메서드입니다.
메서드는 단순 조회를 넘어, invoke()를 통해 런타임에 직접 실행할 수 있기 때문입니다.

리플렉션을 사용한 객체는 JVM에서 바로 실행되지 않습니다. 내부적으로는 Method.invoke() -> MethodAccessor.invoke() -> 실제 메서드 실행 이 되어집니다. 즉, 리플렉션은 바로 실행되는 것이 아니라, 중간 레이어를 통해 간접적으로 실행되는 구조입니다.

어째서 JVM으로 바로 실행하지 않고, 리플렉션은 중간과정을 거치는가?

리플렉션은 컴파일 시점에 구조가 확정되지 않기 때문에, JVM이 직접 최적화할 수 없고 중간 레이어를 거치게 됩니다.
일반 메서드 호출과 리플렉션 호출을 비교해보겠습니다. 일반 메서드 호출은 컴파일 시점에 어떤 메서드가 실행될지 이미 확정됩니다.
그렇기 때문에 JVM은 해당 호출에 대해 직접 최적화를 수행할 수 있습니다.
반면, 리플렉션 호출은 어떤 메서드가 실행될지 런타임에 결정됩니다.
즉, JVM 입장에서는 정적 정보가 부족한 상태입니다. 그렇다면 왜 invoke()로 바로 실행하지 못할까요?

그 이유는 크게 세 가지입니다.
첫 번째는 타입 안정성 보장입니다. 리플렉션은 실행 시점에 객체와 파라미터를 전달받습니다.

method.invoke(obj, args);

이때 JVM은 매번 다음과 같은 검사를 수행해야 합니다.

객체 타입이 올바른지
매개변수 타입이 맞는지
해당 메서드를 호출할 수 있는지

즉, 컴파일 시점이 아니라 런타임에 모든 검증이 이루어집니다.
두 번째는 접근 제어 및 보안 문제입니다. 리플렉션은 private 메서드나 필드에도 접근이 가능합니다.
이는 캡슐화를 깨는 접근이기 때문에 JVM 입장에서는 반드시 보안 체크가 필요합니다.

즉, 검증 없이 바로 실행시키는 것은 위험합니다.
세 번째는 호출 대상의 불확정성입니다.

리플렉션은 어떤 메서드가 실행될지 런타임에 결정됩니다. 이 구조에서는 JVM이 호출 대상을 미리 알 수 없기 때문에 최적화가 어렵습니다.
결국 이러한 이유들 때문에, 리플렉션은 바로 실행되지 않고 중간 계층을 거치게 됩니다.

Method.invoke()
 → MethodAccessor.invoke()
   → 실제 메서드 실행

이 중간 계층은 타입 검증, 접근 제어, 호출 위임과 같은 역할을 수행합니다.
정리해보면, 리플렉션은 단순히 느린 것이 아니라, 유연성을 얻기 위해 필수적인 검증과정을 포함하고 있는 구조라고 볼 수 있습니다.

다행인 점은, 리플렉션이 항상 느린 것은 아니라는 점입니다. JDK는 성능 문제를 인지하고 있기 때문에, 내부적으로 최적화를 수행합니다.초기에는 Native 방식으로 실행되지만, 일정 횟수 이상 호출되면 bytecode 기반 호출로 변경됩니다.
이 과정에서 기존의 Native 호출은 보다 빠른 형태의 호출로 대체되며, 반복 호출이 많은 경우 성능을 개선할 수 있습니다.

이러한 최적화 과정을 Reflection Inflation이라고 합니다.

초기: NativeMethodAccessorImpl
 → 이후: GeneratedMethodAccessor

그렇다면, Reflection Inflation는 무엇일까요?

리플렉션은 앞서 살펴본 것처럼 중간 계층을 거쳐 실행되기 때문에 일반 메서드 호출보다 상대적으로 느릴 수 있습니다.
JDK는 이러한 성능 문제를 완화하기 위해 내부적으로 최적화 전략을 사용합니다.

그 중 하나가 바로 Reflection Inflation입니다.

리플렉션은 처음 호출될 때는 Native 방식으로 실행됩니다.
이 방식은 초기 실행 비용은 적지만, 반복 호출이 많아질수록 성능이 좋지 않습니다.

그래서 JDK는 일정 횟수 이상 동일한 리플렉션 호출이 발생하면,
해당 호출을 보다 빠르게 처리하기 위해 바이트코드 기반 호출 방식으로 변경합니다.

초기: NativeMethodAccessorImpl
 → 이후: GeneratedMethodAccessor

이렇게 기존의 Native 기반 호출을, 더 빠른 형태의 accessor로 교체하는 과정을 Reflection Inflation이라고 합니다.
이 구조를 보면 재미있는 점이 하나 있습니다. 처음부터 빠른 방식을 사용하지 않고, 왜 굳이 두 단계를 나누었을까요?

그 이유는 비용 때문입니다.
바이트코드를 생성하는 작업 자체도 비용이 크기 때문에, 호출이 적은 경우에는 오히려 손해가 될 수 있습니다.

그래서 JDK는 처음에는 가볍게 Native로 실행하고 반복 호출이 많아질 때만 최적화를 적용하는 방식으로 설계되어 있습니다.
하지만 Reflection Inflation방식은 과거의 방식이고 최근 JDK에는 MethodHandle 기반으로 내부 구현이 변경되었습니다.

어째서 Reflection Inflation방식대신 MethodHandle방식으로 변경되었는가?

Reflection Inflation은 반복 호출 시 성능을 개선하기 위한 전략이었지만,
근본적인 한계를 가지고 있었습니다.

첫 번째는 JVM이 이해하기 어려운 구조라는 점입니다.
리플렉션은 Method.invoke()를 통해 실행되며, 중간에 MethodAccessor와 같은 계층을 거치게 됩니다.
이 구조는 JVM 입장에서 "어떤 메서드가 호출되는지"를 명확하게 알기 어렵기 때문에, 인라이닝과 같은 최적화를 적용하기 힘듭니다.
즉, 최적화의 한계가 존재합니다.

두 번째는 복잡한 내부 구현 구조입니다.

Reflection Inflation은

Native 호출
바이트코드 생성
accessor 교체

와 같은 여러 단계를 포함하고 있습니다.
이러한 구조는 유지보수 비용이 높고, JVM 내부 구현을 복잡하게 만드는 원인이 됩니다.

세 번째는 일관되지 않은 성능 특성입니다.
초기에는 Native 방식으로 실행되고, 일정 횟수 이후에만 최적화가 적용됩니다.
즉, 호출 횟수에 따라 성능이 달라지는 구조이며, 예측하기 어려운 성능 특성을 가지게 됩니다.
이러한 문제를 해결하기 위해 등장한 것이 MethodHandle입니다.
MethodHandle은 리플렉션과 달리 JVM이 이해할 수 있는 형태로 호출을 표현합니다.

그렇다면, MethodHandle은 어떻게 동작하길래 JVM이 이해할 수 있는 형태로 표현하는 걸까요?

MethodHandle은 단순한 메타데이터가 아니라 이미 호출 대상과 타입이 확정된 실행 가능한 참조로 동작합니다.
코드로 확인해봅시다.

리플렉션

리플렉션 방식에서는 다음과 같이 코드가 작성이 되었습니다.

class Person {
    public void hello(int a) {
        System.out.println("hello " + a);
    }
}

Method method = Person.class.getMethod("hello", int.class);
Person p = new Person();
// 실행
method.invoke(p, 10);

리플렉션은 런타임 시점에서 메서드가 실행됩니다. 그렇다는 이야기는, 컴파일 시점에는 호출 대상이 확정되지 않기 때문에 보안 검사와 호출 대상의 불확실성을 런타임에 처리해야 한다는 의미입니다. 이 과정에서 리플렉션은 중간 계층을 두어 실행되는 구조를 가지게 되었고,
그 결과 매번 해석과 검증이 필요한 문제가 발생했습니다. 이러한 성능 문제를 완화하기 위해 등장한 것이 Reflection Inflation입니다.

리플렉션은 처음에는 Native 방식으로 실행되지만, 일정 횟수 이상 호출이 발생하면 바이트코드 기반 호출로 전환됩니다.
이를 통해 반복 호출에 대한 성능을 일부 개선할 수 있었습니다.
하지만 이 방식은 근본적인 해결책은 아니었습니다. 여전히 중간 계층을 거치는 구조이기 때문에
추가적인 호출 비용이 존재했고, JVM이 직접 최적화하기 어려운 구조라는 한계를 가지고 있었습니다.

이러한 한계를 해결하기 위해 등장한 것이 MethodHandle입니다.

MethodHandle 방식

MethodHandle은 리플렉션과 달리, 호출 대상과 타입 정보를 미리 확정된 형태로 표현합니다.
이 덕분에 JVM은 해당 호출을 더 명확하게 이해할 수 있고, 인라이닝과 같은 최적화를 적용할 수 있게 됩니다.

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

MethodHandles.Lookup lookup = MethodHandles.lookup();

MethodHandle mh = lookup.findVirtual(
    Person.class,
    "hello",
    MethodType.methodType(void.class, int.class)
);

Person p = new Person();

// 실행
mh.invokeExact(p, 10);

이렇게 되면 호출 방식 자체가 달라지게 됩니다. 리플렉션은 실행 시점마다 호출 대상을 해석하고 검증하는 구조입니다.
즉, 매번 "무엇을 호출할지"를 확인하는 과정이 필요합니다. 반면 MethodHandle은 메서드와 타입 정보가 이미 결합된 상태로 생성되기 때문에, 호출 시점에는 추가적인 해석 과정이 필요하지 않습니다.

핵심 차이는 다음과 같습니다.

Reflection
문자열 → 메서드 탐색 → 실행 시 검증 → 호출

MethodHandle
메서드 + 타입 → 생성 시 확정 → 바로 호출

이러한 차이로 인해, MethodHandle은 JVM이 호출 구조를 명확하게 인식할 수 있는 형태로 표현됩니다.
즉, 단순한 동적 실행이 아니라, 정적인 호출에 가까운 구조로 변환된 것입니다.

그 결과 JVM은 해당 호출에 대해

인라이닝
JIT 최적화
호출 경로 단순화

와 같은 최적화를 적용할 수 있게 됩니다.

마무리

리플렉션부터 MethodHandle까지 살펴보았습니다. 리플렉션의 한계와, 이를 어떻게 보완하고 개선해왔는지에 대해 학습할 수 있었습니다. 특히 단순히 "리플렉션은 느리다"는 수준이 아니라, 왜 그런 구조를 가지게 되었는지, 그리고 JDK가 이를 어떻게 해결하려 했는지를 이해할 수 있었다는 점이 의미 있었습니다. 다만 아쉬운 점도 있습니다. MethodHandle에 대해서는 개념적으로 이해하는 수준에 그쳤고,
아직 내부 동작이나 활용 방식까지 깊게 다루지는 못했습니다. 아무래도 처음 접한 개념이다 보니, 완전히 체화하기에는 시간이 조금 더 필요할 것 같습니다.

카프카의 설정은 진짜일까..?! - Acks 편

klom — Fri, 27 Mar 2026 23:56:47 +0900

EDA 패턴을 적용해보자.(feat.kafka)

이전 포스트에서 이어져서 진행이 되어집니다. 선착순 쿠폰 발급기 개발당신의 동시성 테스트가 원하는 결과가 나오지 않는 이유TL;DR: 낙관락과 비관락을 고르는 기준에 대해 설명합니다.배경

b-programmer.tistory.com

마지막 글에 간단하게 outbox패턴을 얘기하면서 카프카의 설정을 살짝 언급한 적이 있습니다. 사실 outbox패턴이 없어도 카프카는 메시지를 다시 읽을 수 있었습니다. 바로 @RetryalbeTopic이라는 어노테이션을 이용하면 producer에서 발송된 메시지를 다시 읽을 수 있게 유도할 수 있었습니다. 그렇다면, 이러한 설정들이 실제로 어떻게 동작을 할까요? 마지막에도 언급했듯이 제 목표는 native 하게 kafka를 사용하는 것이 목표입니다. 그 이후에는 CDC까지 사용해서 outbox를 풀링 하는 방식이 아닌 DB내부의 로그를 읽는 방식으로 변경할 예정입니다. 한번 해봅시다.

시작은 간단하게 producer의 설정들부터 들어가 봅시다.

ack를 간단하게 설명하면, 어떻게 요청하는 방법에 대해 정의를 하고 있습니다.

acsks=0:
- 가장 빠르게 전송할 수 있는 방식이지만, 유실 위험이 가장 큽니다.
- 지연 시간은 줄일 수 있지만, 메시지가 broker에 실제로 저장되었는지는 보장하지 않습니다.

acsks=1:
- 리더 broker가 메시지를 받으면 성공으로 판단합니다.
- follower replica에 반영될 때까지는 기다리지 않습니다.
- 따라서 리더까지 전달되었다는 보장은 있지만, 리더 장애가 발생하면 유실 가능성이 있습니다.

acks=all(-1):
- 리더와 ISR(in-sync replicas)에 기록되어야 성공으로 판단합니다.
- 가장 안전한 방식이지만, 상대적으로 지연 시간이 길어질 수 있습니다.

broker가 여러 대가 있어야 의미 있는 테스트를 할 수 있는 걸까요? 사실은 그렇지 않습니다. acks=0을 다시 읽어보면
메시지가 "broker에 저장되었는지는 보장하지 않는다"라고 하였습니다. 그렇다는 이야기는 broker한대로도 충분히 테스트가 가능할거 같습니다. 만약, 제가 원하는 테스트라고 되었다는 가정하에 말하자면, 아무래도 유실이 있을 거라 예상합니다.
하지만, 일반적인 상황에서는 아무런 변화가 없을겁니다. broker에 강제적으로 장애를 심어줘야 하지 않을까 싶습니다.

먼저 broker를 한개만 두고 실습해 보죠.
다음과 같은 시나리오로 테스트를 수행했습니다. 각 설정별로 총 50만 건의 메시지를 전송했으며, 전송은 5만 건 단위의 배치 방식으로 진행했습니다. 전체 전송량의 50%인 25만 건을 보낸 시점 이후 장애를 주입했고, 다음 배치를 전송하는 도중 브로커를 3초간 중지한 뒤 재시작했습니다. 전송 실패가 발생한 배치는 브로커 복구 후 재시도하도록 구성했습니다.

이번 테스트를 통해 acks=0과 acks=1의 정합성 차이를 직접적으로 판단하기는 어려웠습니다.
두 설정 모두 장애 구간에서 약 5만 건의 전송 실패가 발생했으며, 이후 재시도 과정에서 중복 메시지가 관찰되었습니다. 특히 acks=1의 경우, acks=0 대비 약 2~3배 더 많은 중복 메시지가 발생했습니다.
다만 이 결과만으로 acks=1이 acks=0보다 정합성을 더 잘 보장한다고 단정하기는 어렵습니다. 단일 브로커 환경에서는 복제가 존재하지 않기 때문에, acks 설정에 따른 내구성(정합성) 차이가 실제로 드러나지 않기 때문입니다.

이번 테스트를 통해 확인할 수 있었던 것은 acks 설정에 따른 정합성 차이 자체보다는, 장애 이후 재시도 과정에서 중복 메시지가 발생하는 양상이었습니다. 따라서 본 결과는 정합성에 대한 직접적인 검증이라기보다는, 단일 브로커 환경에서 acks 설정에 따라 중복 및 재시도 양상이 어떻게 나타나는지를 보여주는 참고 수준의 결과로 보는 것이 적절합니다.

계속 안정성을 언급해왔었는데 acks=1이 중복값이 많다는건 어떤 안전성을 말하고 있는걸까요?
여기서 말하고 있는 안전성이란, 유실 가능성을 말하고 있습니다.
중복 메시지의 증가는 동일한 데이터를 여러 번 처리해야 함을 의미하며, 네트워크 전송, 디스크 I/O, 컨슈머 처리량 측면에서 추가적인 비용을 발생시킬 수 있습니다. 따라서 재시도로 인해 중복 메시지가 증가하는 상황은 시스템 전체 관점에서 성능 저하 요인으로 작용할 수 있습니다. 사실 이것은 kafka의 의도적인 트레이드 오프라고 볼 수 있습니다.
중복 메시지를 늘려 유실 가능성이 줄게 된다면, 최종적으로는 최소 한 번 이상은 반드시 처리가 되어집니다. 다른 말로는 at-least-once라고 합니다.

그렇다면, acks=0에서 중복데이터가 발생한것은 무엇때문일까요?

acks=0에서 중복 데이터가 발생한 이유는, 장애가 발생한 시점에 일부 메시지가 이미 브로커에 전달되었을 가능성이 있기 때문입니다.

그림을 그려봅시다.

producer가 broker쪽으로 메시지를 보냅니다. 여기에 만약 acks=0인 상태라면

broker에 확인하지 않고 지나갑니다. producer가 해당 메시지가 실제로 broker에 정상 반영되었는지 확인하지 못한 채 다음 전송으로 넘어간다는 뜻입니다.
만약 broker가 중지된 상태라면, producer broker로 메시지를 정상적으로 전달하지 못할 수 있습니다. 이후 broker 다시 활성화되더라도, producer 입장에서는 broker 장애 시점에 해당 메시지가 실제로 전송되었는지, 또는 전송되지 않았는지를 정확히 알 수 없습니다.

이처럼 저장 여부가 불확실한 상태에서는, 유실을 방지하기 위해 동일한 메시지 또는 동일한 배치를 다시 전송하게 됩니다.
그 결과, 장애 직전에 이미 일부 저장된 메시지까지 함께 재전송되면서 중복 메시지가 발생할 수 있습니다.

이렇게 하면 단일 브로커에서의 acks동작 결과에 대해 이해를 해보았습니다.

하지만 Kafka는 브로커를 단일로만 구성하는 시스템이 아닙니다. 필요에 따라 여러 대의 브로커로 클러스터를 구성할 수 있으며, 이 환경에서 acks=1과 acks=all의 차이가 보다 분명하게 드러납니다. 단일 브로커 환경에서는 acks=1과 acks=all 모두 사실상 리더 브로커 1대의 응답만 기준이 되기 때문에, 두 설정의 차이를 충분히 확인하기 어렵습니다. 반면 다중 브로커 환경에서는 리더 외에 복제본(replica)이 함께 존재하므로, acks=1은 리더 브로커의 저장만 확인한 뒤 응답하지만, acks=all은 in-sync replica(ISR)까지 반영된 이후 응답하게 됩니다.

따라서 다중 브로커 환경에서는 acks=1과 acks=all이 단순한 응답 속도 차이를 넘어, 장애 상황에서 데이터 유실 가능성과 정합성 보장 수준에 어떤 차이를 만드는지를 보다 명확하게 이해할 수 있습니다.

이제 acks=1 vs acks=all을 비교해보자

두 개 모두 replica라는 용어가 등장합니다. replica는 메인 브로커가 아닌 서브 브로커라고 생각하시면 됩니다.
그렇다면, 어떤 점이 다를까요? 저는 이번 테스트를 위해 kafka를 2대를 더 설치하기로 하였습니다.

대략 요런 느낌이 되는거죠.
테스트는 2가지로 진행이 되어질 예정입니다.

정상적으로 동작하였을때, 어떤 방법이 더 빠른지, 안정적인지 점검해봅시다.

메시지는 5000건으로 진행하였습니다.

5회 평균에서도 acks=0이 가장 빠르고, acks=all이 가장 느렸다. 하지만 내구성 차이는 장애 상황에서 따로 확인해야 한다.

이번 결과는 acks=0이 Throughput이 높다는 의미라기보다는,
브로커의 응답을 기다리지 않는 방식으로 동작하기 때문에 producer 관점에서의 latency가 낮게 나타난 것으로 해석할 수 있습니다.

패킷 수를 비교해보면 acks=0은 약 7,000개 수준인 반면, acks=1 및 acks=all은 약 16,000개로 약 2.5배 더 많은 패킷이 발생했습니다.

이는 acks=1과 acks=all이 브로커의 응답을 포함한 request-response 구조로 동작하기 때문에,
왕복 통신 및 추가적인 네트워크 비용이 발생한 결과로 볼 수 있습니다. 즉, acks 설정에 따른 차이는 단순한 속도 차이가 아니라,
응답 대기 여부에 따른 latency와 네트워크 비용의 트레이드오프로 해석하는 것이 적절합니다.

그렇다면, 장애 상황에서는 어떻게 변화할까요?

레플리카 broker을 사용하는 acks는 1과 all입니다. 그렇다는건 레플리카를 사용하지 않는 acks=0은 어떻게 동작이 되어질까요?
한번 확인해봅시다.

테스트는 leader가 죽었을때와 follow가 죽었을때로 비교가 되어집니다.

리더가 죽게되어지면 wireshark를 통해 다음과 같이 보여집니다.

이렇게 발생하는 이유는 producer입장에서는 기존 리더가 죽었는지 모르는 상황이라는 뜻입니다. 그래서 기존리더에게 요청을 계속 보내는 것을 확인 할 수 있습니다. 메시지는 3만건씩을 발송하였습니다.

leader가 죽으면 acks=0은 빠르지만 큰 유실이 생기고, acks=1은 거의 유지되며, acks=all은 느리지만 이번 5회에서는 전량 보존됐다

놀랍게도 acks=0은 11,800건이 유실이 되었으며, 약 1/3정도가 유실이 되었지만 latency는 여전히 가장 빠른것을 확인 할 수 있었습니다.
acks=1도 약간의 유실이 있긴하지만, 나름 괜찮은 대안이 된다고 여겨집니다.

그렇다면 replica에 장애가 발생한다면 어떻게 되어질까요?

요약: follower 1대가 죽는 조건에서는 acks=0, 1, all 모두 전량 적재됐다. 차이는 주로 속도에서만 나타났다

리더와 달리 follow에 장애가 발생했을때는 유실이 되어지는것이 존재하지 않았습니다. 하지만 평균 실행 속도가 1초가량 늘었다는것을 확인할 수 있었습니다.
이걸로 kafka의 성능은 leader의 장애 여부에 따라 차이가 존재한다는것을 확인할 수 있었습니다.

마무리

원래 producer쪽 전체를 전부 작성하고 싶었지만 ack하나만 적었을 뿐인데도 생각보다 길게 적게 되었네요. 정상 상태에서는 acks=0가 가장 빠르지만, leader 장애까지 고려하면 acks=all이 가장 안전하였습니다. 또한, acks=1은 성능과 내구성 사이의 중간 지점이지만, leader 장애에서 완전 무손실을 보장하지는 못한다는것을 확인하였습니다.

참고로 테스트는 kcat과 tcpdump를 이용해 ai와 함께 테스트 하였습니다.

EDA 패턴을 적용해보자.(feat.kafka)

klom — Wed, 25 Mar 2026 13:24:25 +0900

이전 포스트에서 이어져서 진행이 되어집니다.

선착순 쿠폰 발급기 개발

당신의 동시성 테스트가 원하는 결과가 나오지 않는 이유TL;DR: 낙관락과 비관락을 고르는 기준에 대해 설명합니다.배경그 전에도 낙관락, 비관락을 해봤기때문에 금방할 줄 알았다.하지만 아니

b-programmer.tistory.com

초기 구현에서는 쿠폰 재고를 DB에서 직접 관리했습니다. 발급 요청이 들어오면 트랜잭션 안에서 재고를 확인하고 차감하는 구조였기 때문에, 정합성 측면에서는 비교적 안전했습니다. 실제로 초과 발급도 발생하지 않았습니다. 하지만 대량 트래픽 환경에서는 다른 문제가 드러났습니다. 특정 쿠폰에 요청이 집중되자 동일한 재고 데이터에 대한 동시 접근이 늘어났고, 결국 DB 락 경합이 병목으로 이어졌습니다.
즉, 정합성은 확보했지만 성능 비용이 커지는 구조였던 것입니다.

발급 재고 처리를 DB 락 중심에서 Redis 중심으로 옮기기

가장 먼저, 현재 DB 락 중심의 재고 처리 방식을 Redis 중심으로 변경해보려고 합니다.

왜 Redis가 더 적합하다고 판단했는가

현재 시나리오의 핵심 문제는 정합성이 아니라 처리량과 응답 성능이었습니다.
실제로 현재 구조는 비관락을 통해 초과 발급을 방지하고 있었고, 재고 정합성도 정상적으로 유지되고 있었습니다.
즉, 재고가 틀어지는 문제는 이미 어느 정도 해결된 상태였습니다.
하지만 문제는 그다음이었습니다. 쿠폰 발급 요청이 하나의 쿠폰에 집중되자, 모든 요청이 동일한 coupon row에 접근하게 되었고, 비관락 기반 구조에서는 이 요청들이 사실상 순차적으로 처리될 수밖에 없었습니다. 그 결과 DB는 재고 저장소인 동시에 동시성 제어 지점이 되었고, 결국 락 경합이 성능 병목으로 이어졌습니다.
이 지점에서 Redis가 더 적합하다고 판단했습니다.
Redis는 메모리 기반 저장소이기 때문에 DB보다 훨씬 빠르게 접근할 수 있고, DECR 같은 원자적 연산을 통해 재고 차감도 매우 가볍게 처리할 수 있습니다. 무엇보다 중요한 점은, DB처럼 특정 row에 대한 락 대기를 길게 유발하지 않으면서도 동시성 제어를 수행할 수 있다는 점입니다. 즉, 현재 문제는 "정합성을 어떻게 맞출 것인가"가 아니라 "정합성은 유지한 채, 더 많은 요청을 더 빠르게 처리할 수 있는가"였고, 그 관점에서 Redis는 DB보다 훨씬 적합한 선택지라고 판단했습니다.

즉, 지금 구조는 DB가 재고 관리와 동시성 제어를 모두 담당하는 형태입니다.
이 방식은 초과 발급을 막는 데는 효과적이었지만, 요청이 많이 몰리는 상황에서는 특정 쿠폰 row에 대한 락 경합이 발생하면서 성능 병목으로 이어질 수 있습니다.

그래서 이 부분을 Redis 중심 구조로 변경할 예정입니다.
앞으로는 DB에서 직접 락을 잡아 재고를 차감하는 대신, Redis에서 재고를 원자적으로 감소시키고, DB는 최종 이력 저장 역할에 더 집중하도록 개선하려고 합니다.

이제부터 DB에서 재고를 차감하는 것이 아닌 Redis에서 재고를 차감하는 방식으로 변경하였습니다.

재고가 마이너스가 된다면, 강제적으로 0으로 바꿔주는 코드입니다.

이제 실행해 봅시다. 똑같은 상황에서 테스트를 진행하겠습니다.

테스트를 해보니 정합성은 지켜졌다는 것을 알 수 있었었습니다. 7961 + 2039 = 10000
이전 결과를 가져와서 비교해 봅시다.
k6 스크립트 문제가 있었네요. finalStock이 몇 개인지 알려주지는 않네요.
하지만 이상하게도 생각보다 효과적이지 않았습니다. 이전 결과를 불러와서 비교해 봅시다.

생각보다 성능이 올라가지 않았다는 것이 발견되었습니다. 이유가 무엇일까요?
나아진 거라고는 duration이 조금 더 빨라졌네요.
한 번에 10,000 연결로 때리지 말고, 10,000명 시뮬레이션과 동시 연결 수를 분리해야 합니다.
그러면 VUS 수를 점진적으로 올리면서 어느 지점에서 connection refused이 발생하는지 확인해 보겠습니다.
(200 → 500 → 1000 → 2000)
이것을 토대로 그래프를 그려보겠습니다.

예상과는 다른 결과가 나와 당황스럽네요. 이러면 DB 쪽도 확인을 해봐야 하는 생각이 문득 드는데요.
사실 잘 모르겠습니다. 성능이 얼마나 올라갈지는 모르겠네요. ㅜㅜ

DB-only는 해당 구간에서 측정된 p95 수치가 더 낮았지만, 동시에 실패율이 매우 높아 성능 우위로 해석하기 어렵습니다. 높은 실패율로 인해 요청이 조기 종료되면서 응답시간 지표가 낮게 관측되었을 가능성이 있습니다.

하지만 이거는 제가 원하는 결과가 아닙니다. 어떻게 하면 조금 더 실패율을 줄일 수 있을까요?

EDA에도 패턴들이 이렇게나 많이 존재 하다니..

EDA(Event Driven Architecture)가 MQ나 이벤트 리스너를 통해 동작한다는 것은 알고 있었습니다. 하지만 "어느 상황에서 사용해야 하는가?"에 대해서는 명확하게 정리되어 있지 않았습니다. 단순히 도메

b-programmer.tistory.com

전에 EDA패턴에 대해 학습을 한 적이 있습니다. 물론 패턴에 대해 자세하게 학습은 안 했지만 말이죠.ㅎㅎ
아무튼, 저희가 생각해야 하는 부분은 10000UV를 버틸 수 있게 만들 수 있을까입니다.
여기서 저희가 생각할 수 있는 부분은 두 가지입니다. 처리량과 정합성을 지켜야 합니다.

처리량을 지켜야 하는 이유는 몇 명이 동시에 메시지(API) 발송을 할지 모르기 때문이고
정합성을 지켜야 하는 이유는 쿠폰을 신청을 했다면, 반드시 받아야 하기 때문입니다.
(kafka를 사용하지 않고 스프링 이벤트로 진행해 보겠습니다. kafka는 추후에 연결시켜 보고 비교해 보겠습니다.)

처리량을 먼저 해결해 봅시다.

처리량 문제를 해결하기 위해서는 작업을 어떻게 분산하고, 어떻게 동시에 처리할 것인지가 중요합니다.
이를 위한 대표적인 패턴으로 Competing Consumer Pattern과 Asynchronous Task Execution Pattern이 있습니다.

Competing Consumer Pattern은 여러 Consumer가 하나의 작업 흐름을 나누어 병렬로 처리함으로써 처리량을 높이는 방식입니다.
반면 Asynchronous Task Execution Pattern은 작업을 비동기로 위임하여, 요청 처리와 실제 작업 수행을 분리하는 방식입니다.

이 두 가지 중 하나를 선택해서 사용하는 것이 아닌 둘 다 사용해도 무방합니다.
위 실험결과에 따르면 200 UVS의 동시사용자에서는 예외가 발생하지 않았음을 확인하였습니다.
그렇다면 메시지를 수신하는 Consumer를 50개 정도 만들면 될 겁니다. 하지만 Consumer의 개수를 늘린다고 해서 '메시지 처리 성능'이 좋아질 거 같지는 않습니다.

만약, 200에서 500 아니 1000까지 증가시킬 수 있다면 병렬적으로 사용되는 Consumer의 개수는 현저히 줄게 될 것입니다.
500은 20개의 Consumer가 1000은 10개의 Conumser를 사용할 수 있게 됩니다.

즉, 우리가 가장 먼저 해야 할 일은 메시지를 얼마나 많이 보낼 수 있는지 알아야 합니다.
메시지를 많이 보내면 보낼수록 사용해야 할 Consumer의 개수는 현저히 줄 거라고 여겨집니다.

Asynchronous Task Execution Pattern

위와 같은 이유로 최대 전달할 수 있는 메시지를 올리는 방법을 먼저 선택하겠습니다.

1) 스프링 이벤트로 보내기

이벤트는 두 가지 속성이 존재합니다. producer와 consumer가 존재합니다.
publiser를 통해 이벤트를 발송하고, consumer를 통해 이벤트를 수신하는 역할을 합니다.
자세한 내용은 아래 블로그 글을 참고해 주시기 바랍니다.

어째서 메시지 브로커가 왜 필요한가?

카프카나 레빗 MQ같은 MQ시스템들을 학습하다보면 브로커라는 개념이 등장합니다. 인터넷에 브로커를 검색해보니 판매자와 구매자 사이에서 정보를 교환하고 중개하여 수수료를 받는 개인 또는

b-programmer.tistory.com

스프링 이벤트에서는 producer를 publisher로 consumer는 listener로 표기합니다. 이렇게 표기하는 이유는 Pub/Sub 개념을 따르기 때문이라고 합니다.

먼저 publisher를 준비해 둡니다.

publisher

스프링 이벤트는 이벤트 객체 타입(dto)에 따라 어떤 listener로 실행이 될지 결정됩니다.

listener

현재 비동기 이벤트로 확인하려는 목적이기 때문에 @Async를 붙여줍니다.
하지만 @Async를 붙인다고 해서 비동기로 동작하는 것은 아닙니다.

@EnableAsync로 비동기를 활성화시켜야 비동기를 사용할 수 있습니다.
간단하게 500UV에서 실패율을 확인했기 때문에 요걸로 돌려봅시다.

크읍.. 비동기로 돌렸음에도 실패율이 존재하는군요..ㅜㅜ
하지만 처리 속도가 월등히 높아졌다는 것을 알 수가 있었습니다.
그렇다면 200 UVS -> 10000 UVS까지 결과는 어떨까요?

redis만 사용하는 방식과 비동기 이벤트 방식을 비교해 보았습니다.
생각보다 꽤 흥미로운 결과가 나왔습니다.
특히 1,000 VUS에서 2,000 VUS로 증가하는 구간에서는 오히려 실패율이 상승하는 모습을 확인할 수 있었습니다.
또한 10,000 VUS 구간에서는 비동기 이벤트 방식의 실패율이 동기 방식보다 더 높게 나타났습니다.
그렇다면 스프링 이벤트를 kafka로 변경하면 어떻게 될까요?

2) kafka로 보내기

kafka를 선택한 이유: Kafka를 선택한 이유는 단순히 요청을 비동기로 분리하기 위해서가 아닙니다.
Kafka는 메시지를 로그 형태로 저장하고, 이를 소비자에게 제공하는 구조를 가지고 있습니다.
이러한 특성 덕분에 장애가 발생하더라도 메시지를 다시 읽어 재처리하거나 재시도할 수 있습니다.

결국 Kafka를 도입한 이유는 비동기 처리 자체보다도,
메시지의 유실 가능성을 줄이고 안정적으로 다시 처리할 수 있는 구조를 만들기 위해서입니다.

자세한 내용은 아래 블로그 글을 참고해 주시기 바랍니다.

카프카를 왜 사용해야 할까?

카프카를 계속 공부해 왔지만, 솔직히 말하면 "왜 이걸 써야 하는지" 스스로 완전히 납득했다고 말하기는 어렵습니다.문서와 강의에서는 늘 대규모 트래픽, 이벤트 스트리밍, 비동기 아키텍처

b-programmer.tistory.com

이 특성은 추후 다시 다뤄질 예정입니다.

kafaka 또한 publisher와 listener가 필요합니다. kafka에서는 producer와 consumer라고 합니다.
producer가 메시지를 전달하고, consumer가 메시지를 수신하게 됩니다.
스프링 이벤트와 다른 차이점(mq에서)은 바로 broker가 존재한다는 점입니다. 즉, producer가 consumer로 바로 메시지를 전달하지 않고 broker를 통해, 메시지를 발송하고 수신하게 됩니다. 이것을 간단하게 그림을 그려보면 이렇게 그릴 수 있습니다.

broker를 사용하는 가장 큰 이점은 메시지를 발송하는 쪽과 메시지를 처리하는 쪽이 분리된다는 점입니다.
Producer는 메시지를 보내는 역할만 담당하고, Consumer는 메시지를 받아 처리하는 역할을 담당합니다.
이처럼 메시지 발행과 처리 과정이 분리되면 시스템 간 결합도가 낮아지고, 처리 구조를 유연하게 확장할 수 있습니다.
해당 내용은 다음 글에서 더 자세하게 설명하겠습니다. 자세한 내용은 다음 글을 참고해 주세요.

어째서 메시지 브로커가 왜 필요한가?

b-programmer.tistory.com

broker는 직접적으로 구현하지는 않습니다. 즉, producer와 consumer만 구현하면 됩니다.
producer를 만들어줍니다.

기존 스프링 이벤트가 이벤트 DTO로 통신을 했다면, kafka는 토픽으로 통신을 하게 됩니다. 즉, coupon-issue-requests라는 토픽으로 메시지를 전송하게 됩니다.

producer를 만들었으니 이것을 수신하는 consumer도 만들어 봅시다.

이 코드는 producer로 발행된 토픽을 받아오는 역할을 합니다. 이렇게 되면 카프카를 통해 다음과 같이 전달이 됩니다.

가장 기본적인 형태로 진행하였습니다.
이번에도 역시 500UV에서 한번 돌려보겠습니다.

스프링이벤트보다 실패율이나 속도가 많이 증가가 된 걸로 확인이 됩니다. 물론, 이거 하나로 판단하기에는 어려움이 있다고 여겨집니다.

그렇다면 200UV부터 10000UV까지 돌린 결과는 어떨까요?

생각보다 성능이 월등하게 좋아졌다고 말하기는 애매한 결과입니다. 전체적으로 보면 kafka 방식의 실패율이 더 낮은 경향을 보이긴 했지만, 5000 VUS에서는 오히려 kafka 방식의 실패율이 더 높게 나타났습니다.

이러한 현상이 발생한 이유는 kafka 이전 단계에서 오류가 발생했을 가능성이 높기 때문입니다.
즉, 요청이 kafka까지 전달되기 전에 이미 실패했을 수 있습니다.

예를 들면 다음과 같은 경우입니다.

HTTP 요청 처리 과정에서 발생한 예외
애플리케이션 내부 처리 오류
로컬 네트워크 지연이나 연결 문제
서버의 일시적인 리소스 부족

이러한 오류들은 kafka로 메시지가 전송되기 이전 단계에서 발생하기 때문에, kafka 자체의 처리 방식과는 직접적인 관련이 없을 수 있습니다. 따라서 일부 구간에서 kafka 방식의 실패율이 더 높게 나타난 것은 kafka의 문제라기보다는 요청이 kafka에 도달하기 이전 단계에서 발생한 오류일 가능성이 높다고 볼 수 있습니다. 이 말을 다시 말하면, 환경에 따라 결과는 다르게 나올 수 있다는 뜻이 됩니다.
이것을 kafka를 사용해서 해결할 수는 없습니다. 대신 이러한 실패에 대해서는, 실패 내역을 남기고 이를 바탕으로 재발행하거나 재처리하는 방식으로 실패율을 낮출 수 있습니다. 이러한 문제를 해결하기 위한 대표적인 방법 중 하나가 바로 Outbox Pattern입니다.
이 방식은 추후 다뤄보겠습니다.

Competing Consumer Pattern

다시 말하지만, 이 패턴을 사용한다고 해서 실패율을 0으로 만들 수 있는 것은 아닙니다.
다만 여러 Consumer가 동시에 메시지를 처리할 수 있기 때문에 전체 처리 속도와 처리량을 향상하는 효과는 기대할 수 있습니다.

그럼에도 불구하고 Outbox Pattern보다 먼저 다루는 이유는, 이 패턴이 Asynchronous Task Execution Pattern과 마찬가지로 처리량(throughput)을 개선하기 위한 접근 방식에 속하기 때문입니다.

즉, Competing Consumer Pattern은 메시지의 신뢰성이나 재처리를 해결하기 위한 패턴이라기보다는,
여러 Consumer가 병렬로 작업을 처리하여 시스템의 처리량을 높이기 위한 패턴이라고 볼 수 있습니다.

병렬로 작업하기 위해서는 어떻게 해야 할까요?
이것을 이해하기 위해서는 kafka-key를 이해를 해야 합니다.

기존에는 couponId로 키를 나눴습니다.

이 말을 다시 말하면, 키는 최대한 겹치지 않게 만드는 것이 굉장히 중요하다고 생각합니다. 그래야 많은 파티션을 사용할 수 있기 때문이죠.
그렇다면, 현재 방식에서 최대한 키를 겹치지 않게 하는 방법은 userId 또는 requestId입니다.
그렇게 되면 다음과 같이 그릴 수 있습니다.

이제 파티션 0번은 101번만 파티션 1번은 102번만, 파티션 2는 103번만 작업할 수 있게 되었습니다. 이렇게 되면 병렬적으로 작업할 수 있어 이전 테스트 asychronous를 할 때보다 작업효율이 높아질 거라고 예상합니다.
그럼에도 불구하고, 속도가 빠르냐는 다른 문제라고 여겨집니다. 왜냐하면 작업 효율이 좋다고 해서 무턱대고 속도가 빠르다고 말하는 건 결론부터 말하는 꼴이기 때문에 추후 테스트를 통해 설명드려보겠습니다.

producer를 couponId에서 userId로 변경하였습니다. producer 쪽은 많은 파티션을 사용하기 위해 key만 변경하였습니다.
그렇다면, consumer는 코드가 어떻게 변경되었을까요?

consumer 쪽을 확인해 보니 용어가 두 가지가 등장하였습니다. groupId와 concurrency입니다.
이들은 무엇이며 concurrency에 적힌 숫자는 의미가 무엇일까요?

groupId

groupId는 현 프로젝트에서는 엄청나게 의미가 없을 수도 있습니다. 왜냐하면 컨슈머 여러 개를 하나의 팀으로 만드는 건데
현 프로젝트에서는 group이라고 해봤자 요거 하나뿐이기 때문이죠.
하지만, 앱의 개수가 많아지거나 프로듀서가 많아진다면 얘기는 달라질 겁니다.

concurrency

concurrency는 동시에 병렬로 동작할 수 있는 consumer의 개수를 나눠서 처리를 할 수 있습니다.
그렇다면, concurrency는 많으면 많을수록 좋을까요? 만약, 입구의 크기가 최대 500 UVS라면 10번을 진행하게 되면 5000이고 20번을 하게 되면 10000번이 훌쩍 넘어가게 됩니다.

만약, concurrency를 무턱 되고 올리면 다음과 같은 상황이 발생하게 됩니다.

1. 파티션 개수를 적게 생성하게 된다면, concurrency를 높게 선정하는 것이 의미가 없어집니다. 즉, 파티션이 3이고 concurrency이 10개라면, 동시에 작업하는 consumer는 총 3개입니다.

2. 만약, 파티션 개수는 상관없다고 한다고 해도 concurrency를 높게 설정하는 것은 다음과 같은 문제를 초래합니다.
동시에 많은 consumer가 동작한다는 것은 스레드를 많이 사용한다는 뜻이니, 콘텍스트 스위칭이 많이 발생하게 됩니다.
즉, 콘텍스트 스위칭 비용이 증가된다는 뜻이 되는 거죠.
이 밖에도 DB 커넥션 경쟁, Redis / 외부 API 부하 증가, 락 경합 증가, 중복 처리 / race condition 가능성 증가, 로그/모니터링 복잡도 증가 등등.. 그러니까 처리량보다 충돌이 먼저 발생이 될 수 있다는 뜻이 됩니다. 아이러니하게도 성능이 떨어지는 꼴이 됩니다.

즉, concurrency는 시스템이 버틸 수 있는 최대 개수까지 적당히 높이는 것이 핵심이라고 여겨집니다.
또, 현재 테스트하고 있는 환경이 문제가 로컬이라는 점입니다. 결국, 로컬환경에서의 concurrency의 최대 개수까지 설정하여도 운영 환경에서 도는 또 틀어질 수 있다는 뜻입니다.

그럼에도 불구하고, 로컬에서 얼마나 버틸 수 있는지 왜 concurrency를 높게 설정하면 안 되는지 테스트를 진행해 보겠습니다. 이렇게 만들면 competing Consumer patten의 형태로 만들기는 하였습니다. 하지만 여기서 끝난 것은 아닙니다.

다음과 같은 작업이 동반이 되어야 비로소 패턴이 완성이 되었다고 할 수 있죠.

1. 중복 처리와 멱등성 처리

같은 요청이 들어와도 같은 유저에게는 쿠폰이 2번 이상 발급이 되지 않게 해야 합니다.
현재는 다음과 같은 코드가 존재합니다.

코드상으로도 동일 인물이 같은 쿠폰을 받지 못하도록 처리가 되어 있습니다.
하지만 이것만으로는 부족합니다. DB에서 최종적으로 중복 저장을 막아야 합니다.

왜냐하면, 동시에 두 요청이 들어와서 race condition이 발생한다면, 최종적으로 DB가 막아 줄 수 있기 때문입니다.

하지만 지금 방식은 최종 결과의 종복방지지 이벤트 자체의 멱등성과는 거리가 있어 보입니다.
그렇다면, 어떻게 처리할 수 있을까요?

현재 이벤트에는 couponId, userId, requesedAt뿐만 존재합니다. 여기에는 이벤트의 고유한 값이 존재하지 않습니다.
그렇다는 이야기는 이벤트에 대한 고유한 값을 적용시키지 못한다는 뜻이 됩니다.

그렇다면 어떻게 해야 할까요? eventId라는 고유한 값을 추가한 뒤, 이미 처리가 되어있다면, 무시를 하고
처음 본 이벤트 하면 proccessed_event 같은 저장소에 기록하면 됩니다.

이렇게 되면 동일한 이벤트를 두 번 이상 작업되지 않게 방지할 수 있습니다.

producer 쪽에서 보낸 메시지를 수신한 뒤, consumer 쪽에서 수신을 하게 됩니다.

이전과 다른 점은 eventId를 저장하고 있고 있습니다.

coponId와 userId가 코드 상에서 멱등성을 측정한 것처럼 역시

애플리케이션에서 동일한 이벤트가 다시 발행되더라도, 재고가 중복 차감되거나 쿠폰이 중복 발급되지 않도록 하기 위해서입니다. 하지만 이상한 점이 있습니다. 어째서 예외를 던지지 않고 return을 하게 되는 걸까요? 그 이유는 첫째, 이벤트의 중복 발행을 예외 상황으로 보지 않기 위함입니다. 둘째, 이미 처리된 이벤트에 대해 불필요한 재처리 없이 그대로 종료하기 위함입니다.

처리 도중 다른 스레드가 먼저 성공하는 경우도 고려해야 합니다.
앞선 조회는 이미 처리 완료된 이벤트를 빠르게 걸러내기 위한 사전 확인입니다.
다만 동시 요청 상황에서는 둘 다 조회 시점에는 미처리로 판단할 수 있으므로, 저장 충돌이 발생한 뒤 다시 조회해 선행 처리 결과를 확인합니다.

동시에 요청이 들어온다면, 한쪽이 먼저 성공했다면, 다른 쪽은 DB unique 제약에 걸려 실패하게 됩니다.

참고로 쿠폰 재고를 다시 증가시키는 이유는, 이미 Redis에서 재고를 감소시킨 이후 예외가 발생했기 때문에 차감한 재고를 복구하기 위해서입니다.

이 파트에 대한 내용은 추후 outbox를 설명할 때, 다시 등장할 예정입니다.

2. 동시성 안전성

요청이 몰려서 재고보다 많이 발급되지 않게 해야 합니다.
다행스럽게도 동시성 안전성은 적용되어 있었습니다.

첫째, 재고 수량을 초과해서 쿠폰이 발급되지 않도록 방어하는 로직이 존재합니다.

이로써, 여러 요청이 동시에 들어와도 재고가 0보다 작아지면 다시 복구하고 실패처리가 가능합니다.

둘째, 같은 유저가 같은 쿠폰을 동시에 여러 번 발급받으려고 해도 최종적으로 하나만 저장이 됩니다.
즉, 동시 요청이 들어와도 동일 유저의 중복 방지 발급은 방어할 수 있습니다.

이 정도만 해도 어느 정도, 동시성은 보장이 됩니다. 조금 더 정확하게 동시성을 적용하려면 다음과 같은 것들을 적용할 수 있습니다.

현재는 Redis 재고 차감과 DB 저장이 하나의 원자적 작업이 아닙니다.
현재는 중복을 확인하고 Redis 재고 감소가 발생하며, 그 후에 DB에 저장이 됩니다.
하지만 이 과정이 하나의 원자적 연산으로 묶여 있지는 않습니다. 즉, 처리 중간에 실패가 나면 잠시 어긋날 가능성이 존재합니다.

Redis 재고 차감과 DB 저장은 하나의 원자적 연산이 아닙니다. 현재는 Redis에서 재고를 먼저 감소시킨 뒤 DB에 발급 쿠폰을 저장합니다. 이때 DB 저장이 실패하면, 감소했던 Redis 재고를 다시 증가시켜 보정합니다. 즉, 정상적인 예외 흐름에서는 보상 로직이 존재하지만, Redis 차감 직후 프로세스 장애 같은 상황까지 완전히 원자적으로 보장하는 구조는 아닙니다.

그렇다면, 원자적으로 동작을 시키려면 어떻게 수정할 수 있을까요?
일단 우리가 생각해야 되는 것이 DB를 기준으로 정합성이 발생을 시켜야 된다는 점입니다. 현재는 redis를 기준으로 정합성이 발생하고 있습니다. 이를 다시 말하면 보조 수단으로 사용을 해야 하는 redis가 메인으로 사용이 되었다고 할 수 있습니다.

다시 동시성을 완벽하게 통제하기 위해 DB로 바뀐 것을 확인할 수 있습니다.
그러면 redis는 어떻게 바뀌었을까요?
바로 DB의 트랜잭션이 종료된 이후에 반영이 됩니다. 바로 다음과 같은 코드로 반영이 됩니다.

코드가 두 가지로 나뉘는 이유는, 트랜잭션 동기화가 활성화된 경우와 활성화되지 않은 경우를 구분하기 위해서입니다. 동기화가 활성화되어 있으면 트랜잭션이 정상 커밋된 후 Redis 캐시를 삭제하고, 활성화되어 있지 않으면 Redis 캐시를 즉시 삭제합니다.

이전 코드에서는 redis 차감이 발생하였지만 이제는 차감이 아니라 제거하는 방식을 선택하였습니다.
이렇게 만든 이유는 redis를 재고의 기준 저장소로 쓰지 않고, 조회 캐시로만 사용하기로 했기 때문입니다.

그러면 이런 의문이 들 수 있습니다. redis가 이제 의미가 없는 걸까? 현재 구조에서는 redis는 보조 수단으로 넘어갔기 때문에 조회 최적화를 위한 의미로 가진다고 볼 수 있습니다.

물론 조회 시에는 다음과 같은 코드가 반영되어 있습니다.

조회 시 redis에 데이터가 존재하지 않는다면, DB를 데이터가 존재한다면 redis를 가져오는 코드입니다.

여기까지 진행했다면, 의문이 드는 것이 있습니다. 실제로 동시성 제어는 괜찮을까?

500UV만 돌려보겠습니다. 200~10000 UVS는 추후 테스트 예정입니다.

걱정했던 것과 달리, 이번 테스트에서는 실패가 발생하지 않았습니다. 물론 1회 실행 결과이기 때문에 오차 가능성은 있지만, 응답 속도도 전반적으로 준수한 수준으로 보입니다. 이를 통해 재고 차감 과정의 동시성 제어가 현재 기준에서는 비교적 안정적으로 동작하고 있다고 볼 수 있습니다.

위에서 consumer을 3으로 지정했습니다. consumer:3은 기존 Asynchronous Task Execution Pattern과 비교를 해보겠습니다.

500 VUS 구간에서 소폭의 실패율 증가가 관찰되었습니다. 다만 이는 RDB의 구조적 한계라기보다는, 일시적인 EOF/connection issue 또는 애플리케이션 인스턴스의 순간적인 흔들림에 기인했을 가능성이 큽니다. 그럼에도 전체적으로는 고부하 구간에서 실패율이 크게 감소해, 안정성 측면에서는 오히려 개선된 것으로 볼 수 있습니다.

이제부터는 동시에 얼마나 많은 consumer를 활용할 수 있는지 확인해보려 합니다. 이를 위해 concurrency 값을 점진적으로 증가시키면서, 실제 처리량이 얼마나 늘어나는지와 어느 지점부터 한계가 나타나는지를 함께 살펴볼 예정입니다.

concurrency를 3번부터 10번까지 증가시키면서 테스트를 진행해 보았습니다.

이제 Competing Consumer Pattern까지 적용시켜 봤습니다. 동시성을 지키기 위해서는 자원이 가진 ID들 뿐만 아니라 이벤트까지 중복을 체크를 해야 했습니다. 또한, 애플리케이션에서 중복을 체크를 하지 못하는 것을 방지하고자 DB단에서 키 관리를 하여 최종적으로 체크하여 중복을 최대한 줄였습니다.
데이터 일관성을 지키기 위해 레디스 차감 방식이 아닌, RDB에서 차감하는 방식으로 변경하였으며, 비관락까지 재 추가하였습니다. 이는 레디스로 옮기는 과정에서 누락이 있었던 걸로 파악이 됩니다.

이제 처리량은 마무리를 지었습니다. 제 목표는 10000 UVS까지 안전하고 빠르게 전달하는 것이 목표입니다. 고로 concurrency에서 가장 빠른 성능을 보여준 concurrency=9를 중심으로 진행될 예정이며, 만약, 속도가 너무 느리다면,
5도 함께 진행해 볼 예정입니다.

Outbox 패턴 적용

처리량 개선을 위한 패턴 적용이 마무리되었으니, 이제는 정합성과 안정성을 높이는 단계로 넘어가 보겠습니다. 단순히 요청을 빠르게 처리하는 것만으로는 충분하지 않습니다. 중요한 것은 실제로 누락 없이 완료되는 요청의 수를 늘리는 것입니다. 이러한 문제를 해결하기 위한 대표적인 방법이 Outbox 패턴입니다. 이번에는 Outbox 패턴을 적용하여, 데이터 저장과 메시지 발행 사이의 불일치 가능성을 줄이고 최종 완료 건수를 높여보겠습니다.

Outbox 패턴이란?

Outbox 패턴은 비즈니스 데이터 변경과 이벤트 발행을 분리하되, 둘 사이의 정합성을 보장하기 위한 패턴입니다.
지금까지는 consumer 측에서 중복 처리와 동시성 제어를 통해 안정성을 확보했지만, producer 측에서는 DB 변경과 Kafka 발행이 하나의 원자적 흐름으로 묶여 있지 않아 이벤트 유실 가능성이 있습니다. 이를 해결하기 위해 비즈니스 데이터와 함께 outbox 이벤트를 같은 트랜잭션으로 저장하고, 이후 별도 relay/publisher가 이를 Kafka로 발행하는 방식이 outbox 패턴입니다.
일단 간단하게

outbox에 이벤트를 저장하고 바로 프로듀서를 통해 이벤트를 넘겨주도록 하였습니다.
하지만 결과는...

흐음... kafka로 통신으로 9937개가 성공하였습니다. 여가까지는 뭐 그럴 수 있다고 생각이 듭니다. 왜냐하면 저에게는 이제 outbox가 존재하기 때문이죠. 하지만..

9937개가 저장이 되었습니다. concurrency도 증가시켜 봤고, VUS를 증가시켜 봤지만 결과는 똑같았습니다.

사실 정합성이라는 것은 단순히 모든 요청이 성공해야 한다는 의미는 아닙니다. 성공한 요청 수와 실패한 요청 수를 합친 결과가 전체 입력값과 일치하고, 그 결과가 시스템의 기대 동작과 맞아떨어진다면 정합성이 유지된다고 볼 수 있습니다. 그런 관점에서 보면, 지금까지는 정합성이 크게 깨졌다고 보기는 어렵습니다.

그렇다면 outbox 패턴은 굳이 적용할 필요가 없는 것일까요?

그렇지는 않습니다. 현재는 정합성이 잘 맞아 보일 수 있지만, 그렇다고 해서 장애 상황에 대비한 안전장치가 불필요하다는 뜻은 아닙니다.
outbox 패턴은 평상시에 큰 차이를 드러내기보다는, 장애가 발생하더라도 이벤트 유실 없이 데이터와 메시지의 정합성을 최대한 유지하기 위한 장치에 가깝습니다.

이러한 관점에서 보면, outbox 패턴의 가치를 단순히 결과 수치의 차이로만 증명하기는 어려울 수 있습니다. 오히려 정합성을 위한 안전장치를 추가했음에도 시스템의 성능이 크게 저하되지 않았음을 보여주는 것 역시 충분히 의미 있는 접근입니다.
즉, 안정성을 높이면서도 처리 성능을 일정 수준 이상 유지할 수 있음을 입증하는 것입니다.

물론 시간이 충분하다면 kafka에 적재된 메시지는 결국 모두 소비될 가능성이 높습니다. 그러나 실제 운영 환경에서는 consumer 애플리케이션이 중단되거나, 메시지 처리 도중 장애가 발생하거나, 동일한 메시지가 중복 전달되는 상황도 고려해야 합니다. 이런 이유로 단순히 메시지를 발행하는 것만으로는 정합성을 충분히 보장하기 어렵습니다.

따라서 정합성을 더 높이기 위해서는 producer 측의 outbox 패턴뿐 아니라, consumer 측에서도 멱등성 보장, 재처리 전략, 실패 메시지 관리와 같은 추가적인 설계가 함께 이루어져야 합니다.

결국 outbox 패턴이 없더라도 항상 정합성이 깨지는 것은 아닙니다. 다만 outbox 패턴은 데이터 저장과 이벤트 발행 사이에서 발생할 수 있는 불일치를 줄이고, 장애 상황에서도 정합성을 보다 명확하고 안전하게 보장하기 위한 방법이라고 볼 수 있습니다.

transactional outbox

우리는 outbox 패턴을 이미 적용하고 있었습니다. 현재 구조는 transactional outbox 패턴을 기반으로, 비즈니스 데이터와 이벤트를 동일 트랜잭션으로 저장한 뒤, 커밋 이후 동일 요청 흐름에서 즉시 메시지를 발행하는 Inline 방식으로 구현되어 있습니다.

하지만 현재는 메시지를 다시 발행해 주는 요소는 없습니다. 단순히 outbox와 발행을 하나의 트랜잭션 내에서 할 뿐입니다. 여기서 조금 더 정확히 말하면, 트랜잭션이 완료된 이후에 메시지를 발행해야 한다는 요구에 초점을 둔다면, afterCommit 방식도 하나의 선택지로 고려할 수 있습니다. 이제 저희가 고려해야 할 것은, 어떻게 하면 이러한 안전장치를 더 확실하게 만들 수 있을까 하는 점입니다.

재시도 발행 메커니즘

현재 방식은 이벤트를 outbox에 저장만 할 뿐, 그 값을 다시 발행하는 구조는 아닙니다. 따라서 consumer 측에 문제가 발생하더라도, outbox 데이터를 기반으로 복구를 진행할 수 없습니다. 결국 정합성을 더 확실하게 보장하려면, outbox에 저장된 이벤트를 다시 발행하는 메커니즘이 필요합니다. 이러한 방식으로는 재시도 발행 방식과 CDC 방식을 고려할 수 있습니다.

여기에서는 우선 재시도 발행 방식을 중심으로 살펴보겠습니다.

1초에 한번씩 이벤트를 재 발행을 하고 있습니다. 일정량(BATCH_SIZE)을 정해서 FAIL 혹은 PANDING상태인 이벤트들만 가져옵니다. 그리고 재 발행을 시도하고 있습니다.

일단 테스트를 돌려봅시다.
성능 최적화 대상이 아닌 안전장치에 가깝긴하지만요. 성능 테스트는 의미는 상대적으로 크지 않다고 여겨집니다.

지금까지 DB에 데이터가 완전히 쌓인뒤에 테스트를 보내는 방식을 선택하였지만 이번에는 부하테스트는 DB의 데이터 여부와 상관없이 이벤트를 보내게 하였습니다. 그렇다는 것은 어느 정도 시간이 지났을 때 결과를 봤을 때 값이 일치하는지 여부를 확인해 봐야 하니다.

총개수는 9737개로 위에서 발행된 이벤트의 개수와 일치한다는 것을 알 수 있습니다. 이로서 정합성은 맞추었습니다.

여기에는 치명적인 문제가 있습니다.

1. 1초마다 DB를 조회합니다.
이는 불필요한 polling을 유발하고, DB 부하를 증가시켜 서비스 성능 저하의 원인이 될 수 있습니다.

2. 처리 방식이 batch polling 중심입니다.
현재 구조에서는 outbox relay가 정해진 배치 단위로 이벤트를 조회·발행하므로,
상황에 따라 뒤에 있는 이벤트가 즉시 발행되지 못하고 다음 처리 주기까지 대기하게 됩니다.

이벤트 발행은 outbox뒤에서 처리가 되어집니다.

3. 이 구조만 놓고 보면 굳이 Kafka일 필요가 없습니다.
현재 방식은 kafka의 고유한 특성을 적극적으로 활용한다기보다, DB polling 기반의 비동기 전달 구조에 kafka를 연결한 형태에 가깝습니다.

따라서 동일한 방식은 다른 MQ에서도 구현 가능하며, 이 점에서 "kafka를 kafka 답게 사용하고 있다"라고 보기는 어렵습니다.

이쯤에서 테스트를 진행해봅시다.

이에 대한 내용은 재 테스트를 하는것이 좋다고 여겨집니다.

kafka가 꺼졌다가 켜졌음에도 정합성은 지켜졌다는 것을 알 수 있습니다.

그렇다면 kafka답게 outbox 패턴을 사용하는 방법이 무엇일까요?

가능하면 즉시 Kafka 발행하도록 합니다.

여기서 핵심은 publish가 되었을 때, 성공하였다면, outbox를 SENT로 실패하였다면, FAILED으로... 설정이 되어야 합니다.

현재는 트랜잭션 전파 방식을 사용해 별도의 트랜잭션을 생성하도록 구현했습니다. 다만 이 부분은 Spring Event 기반으로 분리해도 충분히 가능하다고 생각합니다. 그리고 해당 로직은 비동기로 처리해야 의미가 있는데, @Async가 적용되지 않으면 결국 동기적으로 실행됩니다. 이 경우 쿠폰 생성 이후 발행까지의 지연 시간이 예상보다 훨씬 커질 수 있습니다.

이렇게 되면, 평소 이벤트 흐름은 kafka가 담당하고 outbox는 실패 시 복구용으로 남겨 둘 수 있습니다.

outbox poller는 느린 safety net으로만 사용

이제 outbox 복구 reply는 1s가 아닌 10s 이상으로 해도 괜찮습니다.

이렇게까지 작성하면, 특정 MQ서비스에 구에 받지 않고 outbox패턴을 적용할 수 있습니다.
하지만 저희는 kafka를 사용중에 있습니다. 그렇다면, 전통적인 outbox패턴 방식보다는 조금 더 kafka스럽게 작성하려면 어떤 방식으로 구현하는 것이 적절할까요?

재시도를 조금더 kafka 답게

지금까지 재시도를 위해 outbox라는 안전장치를 두었습니다. 하지만 그렇다고 해서 이 구조가 kafka를 충분히 잘 활용하고 있다고 보기는 어렵습니다. 그렇다면 어떻게 해야 조금 더 kafka스럽게 만들 수 있을까요?
우선 가장 기본적인 부분부터 살펴보기 위해, producer 옵션부터 조정해보겠습니다.

producer 설정을 수정한다는 것은, 이벤트 발행 방식을 kafka의 특성에 더 맞게 다듬는다는 의미입니다.

asks=all(-1):
- 리더와 ISR(in-sync replicas)에 기록되어야 성공으로 판단합니다.
- 가장 안전한 방식이지만, 상대적으로 지연 시간이 길어질 수 있습니다.

저는 신뢰성이 중요하다고 생각하여 asks=all을 선택하였습니다.

enable.idempotence=true
- producer 재시도로 같은 레코드가 중복 저장되는 것을 막습니다.

retries=3
- 전송 실패시 producer가 최대 3번 다시 시도 합니다.

retry.backoff.ms=1000
- 재시도 사이에 1초 기다립니다.

이제는 consumer 측도 함께 살펴볼 필요가 있습니다.
producer뿐 아니라 consumer까지 보완한다면, 수신 측 역시 kafka의 특성에 더 맞는 방향으로 구성할 수 있을 것 같습니다.

consumer에는 무엇을 넣을 수 있을까요?

consumer는 producer와 달리 이벤트를 보내는 역할이 아니라 받아서 처리하는 역할을 담당합니다. 따라서 이벤트를 어떤 방식으로 수신하고 처리할지에 대한 흐름을 이 부분에서 설계할 수 있습니다.

다음과 같은 것들을 추가할 수 있습니다.
즉,consumer 측에서는 처리 실패에 대비한 retry/backoff, 최종 실패 메시지를 위한 DLT, 그리고 중복 소비를 방지하기 위한 idempotent consumer 전략을 함께 설계할 수 있습니다.

@RetryableTopic: 실패한 메시지를 별도의 retry topic으로 보내고 시간이 지난 뒤 다시 소비하게 만드는 방식입니다.
DLT: 원본 메시지 처리 실패 -> retry 여러 번(default:3번) -> 실패 시 -> 더 이상 메인 흐름에서 처리하지 않고 DLT(Dead Letter Topic)으로 보냄
BackOff: 메시지 처리에 실패했다고 해서 바로 즉시 다시 처리하지 않고 조금 기다렸다가 재시도하게 만드는 방식입니다.

지수 백오프(Exponential backoff): delay 값으로 시작하고, 재시도할 때마다 대기 시간이 multiplier만큼 증가하는 방식입니다.
고정 백오프(Fixed backoff): 재시도할 때마다 항상 동일한 delay 간격으로 대기하는 방식입니다.

DLT는 어떻게 처리가 되어지는가?

최종적으로 더 이상 재시도를 수행하지 않는 경우에는, 이렇게 fallback 코드를 작성할 수 있습니다.

이렇게까지 구성하면 어느 정도는 kafka답게 사용하고 있다고 말할 수 있는 수준에는 도달한거 같습니다.

마무리

약 2주간 쿠폰 발급 서비스를 개발하면서 많은 것을 학습을 했습니다. 그렇다고 해서 이게 native-kafka라고 말하기는 어렵다고 생각이 듭니다. 왜냐하면 운영쪽으로 많은 고민이 있어야 하지만 현재로써는 반영이 되지 않았습니다. 예를 들면, Consumer retry/DLT를 실제 운영 흐름, DLT 메시지 운영 체계등을 말할 수 있습니다. 게다가 CDC기반 outbox도 구현하지는 않았습니다. CDC기반으로 하게 되면 더 이상 풀링 방식으로 주입을 시켜줄 필요가 없습니다. 현재로써는 이 정도만 해도 큰 문제가 없다고 생각하였습니다. outbox가 없었을때도 정합성은 0%였기 때문입니다. 그래서 outbox때는 부하테스트한 내용이 없던거구요. 그렇다고 해서 여기서 마무리를 짓는다는 것은 아닙니다. 계속 언급했던 kafka답게를 실천하기 위해 앞으로도 꾸준히 개선해나갈 예정입니다.

선착순 쿠폰 발급기 개발

klom — Mon, 23 Mar 2026 21:22:49 +0900

당신의 동시성 테스트가 원하는 결과가 나오지 않는 이유

TL;DR: 낙관락과 비관락을 고르는 기준에 대해 설명합니다.배경그 전에도 낙관락, 비관락을 해봤기때문에 금방할 줄 알았다.하지만 아니었다. 어디서 부터 문제 였을까?생각하기에는 비관락을 사

b-programmer.tistory.com

그때는 낙관락과 비관락에 대해서만 집중해서 테스트를 진행했던 거 같다.
이번에는 차근차근 진행해 볼 예정이다. 낙관락도 비관락도 무엇인지 정확하게 알았으니 다른 테스트도 해도 크게 문제 될 건 없을 거 같다.

일단 쿠폰을 한 장 준비해 둡니다. 이 쿠폰은 100장 제한이 걸려있으며, 불특정 한 사람들이 이 쿠폰 이용이 가능합니다.
먼저 k6 스크립트를 준비해 주고 테스트를 진행해 봅니다.

락을 걸기 전에

현재 선착순 쿠폰을 구하는 api는 다음과 같습니다.

{
  "userId": 1
}

userId를 바꿔가면서 데이터를 넣어야 한다는 뜻입니다. 저는 겹치지 않게 userId를 100개 준비하였습니다.

초기 상태는 쿠폰이 100개가 남아있는 상태입니다. 이제 100명을 대상으로 테스트를 진행해 봅시다.

정상적으로 테스트가 완료가 되었습니다. 하지만 알 수 없는 오류가 발생하여 장상적인 결과가 나오지 않았습니다.

WARN[0000] [issue] failed status=500, body={"success":false,"data":null,"message":"일시적인 오류가 발생했습니다."}  source=console

6장뿐만 성공했다고 나오고 나머지는 실패를 하였습니다. 생각보다 성공률이 높지는 않네요.
이제 stock을 확인해 봅시다.

이상합니다. 역시 6장이 성공했으면 94가 되어야 하는 게 아닐까요? 2장은 어디로 간 걸까요?
그 이유는 쿠폰 2장에 대해 데드락이 발생이 하였다고 합니다. 이렇게 남은 수량은 신뢰도를 떨어뜨릴 수밖에 없습니다.

그렇다면 어떻게 해야 100장을 요청하면 100장이 모두 소진되게 할 수 있을까요?

비관 락 사용

초기상태로 되돌린 다음 테스트를 다시 진행하겠습니다. 똑같이 쿠폰아이디 1번으로 진행하였습니다.

이번에는 모든 쿠폰이 발급이 되었다는 것을 확인할 수 있었습니다.
DB락에는 2가지 방법이 존재합니다.
낙관락과 비관락입니다. 저는 비관락을 선택하여 사용했습니다. 그 이유는 모든 데이터를 전부 성공을 시켜야 하기 때문입니다.
그렇다는 뜻은, 하나의 작업이 실행 중이라면, 나머지 작업들은 실행을 시키면 안 되기 때문입니다. 만약, 낙관락을 여기에서 사용한다면,
하나만 성공하고 나머지는 실패하는 전략이기 때문에 여기에는 비관락을 선택을 하겠습니다.

쿠폰이 100장을 100명에게 성공한 것을 확인하였습니다.

비관락은 제대로 걸린 거 같습니다. 이제 몇 가지 테스트를 더 진행해보려고 합니다.

추가 테스트

그렇다면 다음과 같은 상황에서도 똑같은 결과를 리턴할 수 있을까요?
1. 쿠폰이 100장이 아닌 10000장인 상황
2. 선착순 쿠폰 10장을 5000명이 발급을 시도하는 상황

바로 진행해 봅시다.

쿠폰이 100장이 아닌 10000장인 상황

- 목적: 락 걸린 상태에서 처리량/지연(p95/p99) 확인
- 기대: 성공률 높음, 대신 동시성 높이면 지연 증가 가능

이 상황은 성능 테스트를 뜻합니다.

이번에는 만장을 준비해 줍니다. 그리고 테스트를 다시 한번 더 돌려봅시다.

예상과 다르게 타임아웃이 발생하였다는 것을 확인할 수 있었습니다. 초반 테스트처럼 쿠폰 100장이 일부만 성공했던 그림과는 전혀 다른 그림이었습니다.

만장모두 종료되었다는 것을 알 수 있습니다.

그렇다면, 결과는 어떨까요?

확인해 보니 http_req_duration은 다음과 같다고 합니다.

- avg: 6.91초
- p95: 15.49초
- p99: null
- max: 16.29초

이 결과의 의미

이번 테스트에서는 총 10,000건의 쿠폰 발급 요청 중 7,629건이 성공하고 2,371건이 실패했습니다.
그럼에도 불구하고 초과 발급은 발생하지 않았고, 초기 재고 10,000장에서 성공 건수 7,629건만큼만 차감되어 최종 재고가 2,371장으로 정확히 일치했습니다.

즉, 성공 건수와 재고 감소량이 정확히 일치했고 oversold가 발생하지 않았으며 409(중복 발급), 400(잘못된 요청/발급 불가) 도 없었습니다. 이 점을 보면 쿠폰 발급 로직 자체는 동시성 상황에서도 재고 정합성을 안정적으로 유지했다고 볼 수 있습니다.
반면, 실패한 2,371건은 모두 failureOther로 집계되었습니다.
이는 비즈니스 규칙 위반이 아니라, 500 응답, 타임아웃, 커넥션 문제, 서버 처리 한계 초과 같은 시스템 과부하성 실패일 가능성이 높다는 뜻입니다.

따라서 이 결과는 다음을 의미합니다.

쿠폰 발급 로직은 동시성 상황에서도 재고 정합성을 잘 지킨다.
하지만 10,000 VU 수준의 순간 스파이크 부하는 현재 시스템이 안정적으로 감당하지 못한다.
결과적으로 일부 요청은 성공했지만, 상당수는 애플리케이션/인프라 병목으로 인해 실패했다.

한 줄 결론

정합성은 통과했지만, 10,000 VU 스파이크 상황에서 성능과 안정성은 실패했습니다.

성능과 안전성을 올리면서 어떻게 해결할 수 있을까요?

선착순 쿠폰 10장을 5000명이 발급을 시도하는 상황

  - 목적: 정합성(초과 발급 0) 검증
  - 기대: 성공은 정확히 10건 근처, 나머지는 소진/중복 실패
  - 핵심 체크: issuedQuantity=10, 발급 row도 10, 초과발급 없음

이 상황은 정합성/경합 테스트를 뜻합니다.

10장이 만들어졌습니다.
예상외의 결과가 나왔습니다. 의외로 나쁘지 않게 나와 당황스러운대요.

다만 조금 이상한 부분이 존재합니다. 바로 failOther부분인데요.
이 부분은 409 말고 다른 실패라서, 약간의 시스템성 실패(500/timeout 등)가 섞여 있을 가능성이 있습니다.

즉 failureOther가 잡혔다는 건, 비즈니스적으로 의도된 탈락(재고 소진/중복 등)이 아니라 정상적이지 않은 추가 실패가 섞였다는 뜻으로 보는 게 맞습니다.

한 줄 결론

이 결과가 의미하는 것은 다음과 같습니다.

쿠폰 발급 로직은 극심한 경쟁 상황에서도 초과 발급 없이 정확히 동작했다.
대부분의 실패는 의도된 경쟁 탈락(409)으로 처리되었다.
하지만 일부 요청은 시스템 과부하성 실패(failureOther)로 떨어져 완전한 안정성 확보에는 미치지 못했다.

이 두 가지 테스트를 통해 확인할 수 있었던 고무적인 점은, 쿠폰 재고가 음수로 내려가는 초과 발급 현상이 발생하지 않았다는 것입니다. 이는 동시성 제어가 의도대로 동작했다는 의미이며, 비관적 락 적용이 정합성 보장에 유효했을 가능성을 보여줍니다. 반면, 초과 발급은 방지했지만 여전히 일부 요청에서 실패가 발생했고 응답 시간도 크게 증가한 것으로 보아, 정합성 문제는 해결되었더라도 성능 및 안정성 이슈는 여전히 남아있다고 판단할 수 있습니다.

어떻게 하면 해결할 수 있을까요?

결제 성공 콜백의 동시성 처리 안정화

klom — Fri, 20 Mar 2026 21:16:53 +0900

분산락을 적용한 뒤 부하 테스트를 진행하는 과정에서 5XX 응답이 과도하게 발생하는 현상을 확인했습니다. 이번 작업의 목적은 동일한 결제 성공 콜백이 동시에 들어오는 상황에서 분산락이 의도한 대로 동작하는지 검증하고, 그 결과를 해석 가능하게 만드는 것이었습니다. 문제는 5XX가 발생했을 때 그것이 분산락 경합에 의한 결과인지, 아니면 락 외부의 예외인지 구분하기 어려웠다는 점이었습니다. 따라서 이번 작업에서는 결제 기능 전체의 안정성 개선보다, 분산락 동작을 방해하는 노이즈를 줄이고, 락 경쟁 결과를 명확히 관측할 수 있도록 만드는 것에 초점을 맞췄습니다.

먼저 200UV를 기준으로 잡고 k6를 돌려보겠습니다.

30분간 200UV를 돌린결과 5XX에러가 19950번이 발생이 되었다는 것을 알 수 있습니다.
하지만 정확히 어떤 문제에서 터졌는지 알 수 없다는 문제가 있었습니다.

이제 본격적으로 진행해보겠습니다.

사전 작업

제가 테스트하려고 하는 부분은 결제이후에 토스 api를 통해 구독을 처리하는 부분입니다.
테스트 하기전에 두 가지 문제가 발생하였습니다. 테스트를 하기 위해서는 로그인이 필수불가하게 필요하다.
두 번째, 토스 API로 직접 부하테스트를 진행할 수 없다.

첫 번째

강제로 특정 프로파일인 경우 헤더에 EMAIL표기가 되어있다면, 로그인 절차를 거치지 않고 세션에 헤더에서 읽어온 이메일을 반영해주는걸로 변경하였습니다. 그래서 특정 이메일로 회원가입을 하고, 그것으로 로그인을 하는 절차를 지웠습니다.

두 번째

직접적으로 토스API를 테스트하는 것이 아닌 Fake혹은 Mock객체를 만들어서 진행하였습니다.

물론, 실제 토스 API를 사용하는 곳에서는 @Profile("!dev")로 설정해놓았습니다.
어째서 프로파일이 test나 local이 아닌 이유는 저는 스프링 부트를 직접적으로 돌리는 것이 아닌 도커로 띄워서 돌리는 것을 선택하였습니다. 도커로 띄우는 경우에는 프로파일을 dev로 설정하여서 분산락 테스트는 dev로 하기로 결정하였습니다.

저는 도커 앱을 3개를 띄우고 시작하였습니다.

하지만 이렇게 되면 시작 포인트가 8083,8084,8085 이렇게 3개로 고정이 되어집니다. 사실 우리가 웹을 들어가게 되면
8083으로도 들어갈수도 있고, 8084로도 들어갈수도 있고, 8085로 들어가게 설정하지는 않습니다.
단 하나의 시작 포인트로 들어가게 됩니다. 그렇다고 해서 3개중 하나가 리더가 되는 형태는 전혀아닙니다.

하나의 시작 포인트에서 들어가기 위해서는 로드벨런서라는것이 필요합니다.
이는 부하를 고르게 전달해주는 장치라고 생각하시면 됩니다. 저는 nginx로 롤링배포를 사용해서 8083,8084,8085를 사용하게 해두었습니다.

dragons1:8083 dragon2:8084 dragon3: 8085

그리고 30분간 200UVS로 잡고 테스트를 진행하였습니다.
부하 테스트를 진행하던 과정에서 5XX 응답이 과도하게 발생하는 문제를 확인했습니다. 물론 부하 상황에서 일부 5XX가 발생하는 것은 가능하지만, 문제는 해당 오류가 분산락충돌 이후 중복 처리 과정에서 발생한 것인지, 혹은 락과 무관한 다른 원인 때문인지 즉시 구분하기 어려웠다는 점이었습니다. 그래서 동일한 orderId에 대한 동시 confirm 요청이 들어오더라도, 분산락 경합 결과가 예측 가능한 응답으로 처리되도록 로직을 보완했습니다.

1. 동일한 orderId에 대한 동시 confirm 요청이 들어오더라도, 분산락 경합 결과가 409 Conflict 등 예측 가능한 응답으로 처리되도록 한다.
2. 5XX 응답 발생 시, 분산락 경합에 의한 문제인지 락 외부 문제인지 구분 가능하도록 한다.
3. 30분 baseline 테스트에서 분산락 관련 메트릭과 응답 패턴을 안정적으로 검증할 수 있도록 한다.

동일한 orderId에 대한 동시 confirm 요청이 들어오더라도, 분산락 경합 결과가 409 Conflict 등 예측 가능한 응답으로 처리되도록 한다.

토스 결제시스템은 다음과 같은 절차를 가집니다.

토스 UI에서 success API로 리다이렉트될 때 paymentKey가 전달됩니다. 이 값을 이용해 토스 승인 API를 호출하고, 결제가 정상적으로 완료됐는지 확인할 수 있습니다.

paymentKey는 토스 결제를 식별하는 고유값이므로 중복되면 안 됩니다.하지만 현재는 이에 대한 제약이 없습니다. 우리 시스템은 토스 UI에서 바로 결제 요청을 보내는 구조가 아니라, 먼저 결제 API를 호출해 결제 데이터를 READY(대기) 상태로 저장합니다.

따라서 결제 전에는 paymentKey가 null일 수밖에 없습니다. 이후 토스 성공 리다이렉트 시점에 전달받은 paymentKey를 저장하게 되는데, 이때 동일한 paymentKey가 중복 저장되면 동일 결제가 여러 번 처리될 위험이 있습니다. 그래서 paymentKey에는 유니크 제약이 반드시 필요합니다.

이렇게 하면 기존 payment가 등록이 되어있다면, 409예외를 터드리도록 하였습니다.
하지만 이럼에도 불구하고 DB측에서 먼저 데이터가 저장이 될 수 있습니다.

DB측에도 paymentKey를 unique로 등록시켜두었습니다. 하지만 이렇게 설정하다보면 동일한 payment가 저장이 되어진다면, 409가 아님 5XX에러가 발생이 되어집니다. 이를 방지하고자

결제 완료 처리 시 paymentKey를 저장합니다. paymentKey는 토스 결제를 식별하는 고유값이므로 중복되면 안 됩니다. 따라서 저장 과정에서 중복으로 인해 DataIntegrityViolationException이 발생하면, 서버 내부 오류(5XX)로 두지 않고 409 Conflict로 변환해 이미 처리된 결제 요청임을 명확하게 반환합니다.

그러면 어째서 saveAndFlush를 했냐라고 한다면?
paymentKey 중복 여부는 애플리케이션 메모리에서 확인되는 것이 아니라 DB의 유니크 제약으로 최종 보장됩니다. 따라서 단순히 엔티티 값만 변경하는 것으로는 부족하고, saveAndFlush()를 통해 DB 반영 시점을 앞당겨야 중복 충돌을 현재 로직 안에서 감지할 수 있습니다.

-> saveAndFlush()를 쓴 이유는 중복 예외를 트랜잭션 커밋 시점이 아니라 현재 confirm 처리 흐름 안에서 잡기 위해서입니다.

이 작업을 한다고 해서 5XX예외가 4XX예외로 바뀌지는 않습니다. 하지만 조금더 동일한 orderId에 대한 동시 confirm 요청이 들어와도, 분산락 경합 결과를 예측 가능한 응답으로 처리하도록 개선하는것이 목적입니다.

간단하게 10분정도만 테스트를 진행해보겠습니다. 이걸 한다고 해서 전에꺼랑 비교는 어렵지만 말이지만 말입니다.

역시 예상한거와 달리 아직도 예상치 못한 오류가 발생이 되어지는군요.

10m 테스트

시간이 달라 얼마나 더 좋아졌는지는 알수 없습니다. 아무튼 추후 얼마나 좋아졌는지 확인해봅시다.

5XX 응답 발생 시, 분산락 경합에 의한 문제인지 락 외부 문제인지 구분 가능하도록 한다.

기존에는 분산락 처리 과정에서 발생한 오류와 락 외부에서 발생한 오류가 모두 5XX로 동일하게 응답되어, 원인 구분이 어려웠습니다. 그 결과, 장애가 분산락 경합/처리 문제인지 아니면 다른 내부 오류인지 파악하기 어려운 경우가 많았습니다. 이번에는 이 둘을 구분 가능한 응답으로 분리해, 문제 원인을 더 명확하게 식별할 수 있도록 개선하려고 합니다.

이제 분산락을 얻는 도중 문제가 발생이 되어진다면, LockException이 발생하게 됩니다.

이제 분산락에서 발생한 예외랑 그렇지 않는 예외를 구분을 지을 수 있게 되었습니다. 이번에도 10분간 테스트를 진행해보았습니다.
놀랍게도 일시적인 오류는 발생하지 않았습니다.

10m

30분 baseline 테스트에서 분산락 관련 메트릭과 응답 패턴을 안정적으로 검증할 수 있도록 한다

이제 다시 30분동안 재 테스트하면서 얼마나 변화하였는지 살펴봅시다.

추가적인 5XX에러가 노출되지 않았습니다. 그렇다고 해서 100%없어진것은 아니네요.

예상치못하게 예외가 발생하는 경우를 8.23%에서 0.02%로 감소 시켰습니다.

로드벨런싱도 잘되고 있네요.

그렇다면 레디스 트랜잭션으로 변경하면 어떨까요?

레디스 트랜잭션은 여러 Redis 명령을 하나의 작업 단위처럼 묶어 실행하는 기능입니다.

주로 MULTI / EXEC 를 사용합니다.
  - MULTI : 트랜잭션 시작
  - 이후 명령들: 바로 실행되지 않고 큐에 쌓임
  - EXEC : 쌓인 명령을 순서대로 실행

생각한거보다 성능이 너무 처참하네요.

실행 시간은 나쁘지는 않은거 같은데 22:30분 전후로 p99가 좀 많이 우뚝 서있는거 말고는 괜찮아보입니다.
하지만

루아로 작업했을때는 보이지 않은 락해제 실패가 보이네요..

그렇다면, 레디슨은 어떨까?

레디슨(Redisson)은 Java에서 Redis를 더 쉽게 쓰게 해주는 고수준 클라이언트 라이브러리입니다.

다행히 실패율은 발생하지 않았네요..

나쁘지는 않지만 예상치못한 예외가 발생하는 경우가 0.04%로 루아만 사용했을때보다 높게나왔네요.

마무리

원래는 분산락 자체를 더 근본적으로 조정하는 방향을 생각했지만, 이번에는 Lua 스크립트 기반 락 처리만으로도 충분히 의미 있는 개선을 확인할 수 있었습니다. 초반에는 예상치 못한 오류가 발생했는데, 원인을 확인해보니 DB의 unique 제약 예외가 그대로 500 응답으로 노출되고 있었습니다. 즉, 실제 문제는 분산락 자체라기보다 동시 처리 과정에서 발생한 DB 중복 예외가 적절히 변환되지 않았던 점에 있었습니다. 이후 DB 중복 예외 발생 시 이를 409 Conflict로 처리하도록 보완한 결과, 비정상 응답 비율을 8.23%에서 0.02%로 감소시킬 수 있었습니다.

Stateless하게 개발하기

klom — Thu, 19 Mar 2026 22:08:06 +0900

Stateless하게 개발한다는 것은 무엇을 의미할까? HTTP는 무상태(stateless)라고 하고, 아키텍처에서도 stateless라는 말이 자주 등장한다. 처음에는 이 개념이 잘 이해되지 않았다. 왜냐하면 상태를 가진다는 것은 결국 어딘가에 데이터가 저장된다는 의미이기 때문이다. 그렇다면 DB나 Redis 같은 저장소를 사용하는 순간 stateless하지 않은 것이 아닌가라는 생각이 들었다. 하지만 이는 잘못된 이해였다. Stateless의 기준은 인프라 전체가 아니라 서버이다. DB나 Redis를 사용하는 것은 상태를 없애는 것이 아니라, 서버 외부로 분리하는 것이다. 즉, stateless하게 개발한다는 것은 서버가 데이터를 전혀 저장하지 않는다는 의미가 아니라, 서버가 이전 요청의 상태를 기억하지 않도록 만드는 것이다. 각 요청은 독립적으로 처리되어야 하며, 서버는 이전 요청이 무엇이었는지 알 필요가 없다. 필요한 상태는 요청에 포함되거나, DB나 Redis와 같은 외부 저장소에서 조회한다. 결국 stateless 아키텍처란 상태를 제거하는 것이 아니라, 상태를 서버 밖으로 이동시키는 설계 방식이라고 볼 수 있다.

Stateless하게 개발한다는것은 무슨말일까?

Stateless하게 개발한다는 것은 무엇을 의미할까?
Stateless하게 개발한다는 것은 서버가 이전 요청을 기억하지 않도록 만드는 것이다.
간단하게 말하면 stateless는 '상태 없음'으로 보이지만, 실제로는 서버가 상태를 가지고 있지 않다는 의미에 가깝다.

그렇다면 stateful하다는 것은 무엇일까? 상태를 저장한다는 의미를 가지고 있는데, 다음의 예시를 보자.
사용자의 로그인 여부를 확인해야 하는 상황을 생각해보면, stateful 구조에서는 서버가 사용자 세션을 메모리에 저장한다.
이 경우 해당 사용자의 이후 요청은 같은 서버로 전달되어야 한다.
왜냐하면 상태가 특정 서버에 있기 때문이다. 따라서 서버가 죽으면 세션 정보도 함께 사라지게 된다.

반대로 stateless 구조에서는 서버가 "나는 아무것도 기억하지 않는다. 필요한 정보를 요청에 담아달라"고 가정한다.
요청마다 토큰이나 사용자 ID가 포함되고, 필요한 정보가 있다면 DB나 Redis 같은 외부 저장소에서 조회한다. 즉, 특정 서버에 상태가 묶이지 않기 때문에 어떤 서버든 동일하게 요청을 처리할 수 있다. 결국 stateless 아키텍처란 상태를 없애는 것이 아니라, 상태를 서버 외부로 분리하는 방식이라고 볼 수 있다.

이것을 확실하게 보여줄수있는 예시가 바로 세션 로그인과 JWT로그인이다.

그렇다고 해서 Staless가 마냥좋고 Stateful이 마냥 나쁜것은 아니다.

Stateless를 하게 되면 어떤 점을 신경을 써야 하는지 알아보자.

Statless 구조는 서버가 상태를 가지지 않기 때문에 확장성과 유연성 측면에서 큰 장점을 가진다.
하지만 상태를 외부로 분리한 만큼 이로 인해 새롬게 고려해야 할 문제들도 생기게 된다.

첫 번째는 네트워크 비용 증가이다.
Stateless 환경에서는 요청마다 필요한 정보를 모두 포함해야 한다.
예를 들어, JWT를 사용하는 경우, 매 요청마다 토큰이 함께 전달된다. 또한 필요한 데이터를 조회하기 위해 DB나 Redis와 같은 외부 저장소를 호출해야 한다. 이로 인해 네트워크 트래픽이 증가할 수 있다.

두 번째는 데이터 일관성 문제이다.
상태가 여러 저장소에 분산되면서 데이터가 즉시 반영되지 않을 수 있다. 특히 분산 캐시나 복제된 데이터베이스를 사용하는 경우, 어느 시점에서는 다른 데이터를 바라보는 상황이 발생할 수 있다. 이를 궁극적 일관성이라고 한다.

세 번째는 멱등성이다.
Stateless 환경에서는 동일한 요청이 여러 번 들어올 수 있다. 예를 들어 네트워크 문제로 인해 요청이 재시도되는 경우, 같은 요청이 중복 실행이 될 수 있다. 이때 요청을 여러 번 처리하더라도 결과가 동일하게 설계해야 한다.

네 번째는 보안 문제이다.
JWT와 같은 토큰 기반 인증을 사용할 경우, 토큰이 탈취되면, 만료 전까지는 계속 사용할 수 있다.
세션 기반 방식처럼 서버에서 즉시 무효화하기 어렵기 때문에 토큰의 만료 시간이나 재발급 전략을 신중하게 설계해야 한다.

마지막으로 운영 복잡성 증가이다.
서버는 단순하지만, 대신 DB, Redis, 메시지 큐 등 여러 외부 시스템을 함께 운영해야 한다. 이로 인해 전체 시스템의 복잡도가 증가하고 문제 발생 시 디버깅 난이도가 높아질 수 있다.

출처
https://blog.bytebytego.com/p/stateless-architecture-benefits-and

스프링 이벤트 리뉴얼(1) - Publisher

klom — Wed, 18 Mar 2026 23:08:15 +0900

스프링 이벤트

스프링 이벤트(Spring Events)는 애플리케이션 내에서 컴포넌트 간의 느슨한 결합(loose coupling)을 유지하면서 비동기적 또는 동기적으로 메시지를 전달하는 메커니즘입니다.스프링의 Observer 패턴 기

b-programmer.tistory.com

이전에 스프링 이벤트를 학습한 적이 있습니다. 당시에는 이벤트가 어떻게 전달되고 실행되는지, 즉 내부 동작 방식에 집중해서 이해하려고 했습니다. 이번에는 조금 다른 관점에서 스프링 이벤트를 다시 바라보려고 합니다. 스프링 이벤트는 이벤트를 발행하는 퍼블리셔와 이를 처리하는 리스너로 구성되어 있으며, 이러한 구조는 메시지를 주고받는 MQ와 유사한 형태를 가지고 있습니다. 다만 스프링 이벤트는 Kafka나 RabbitMQ와 같은 외부 메시지 브로커를 사용하는 방식이 아니라, 동일한 애플리케이션 내부, 즉 하나의 JVM 자원을 공유하며 동작한다는 점에서 차이가 있습니다. 이번 글에서는 이러한 특징에 초점을 맞춰, 스프링 이벤트를 단순한 기능 설명이 아닌 애플리케이션 내부 메시지 전달 구조라는 관점에서 다시 정리해보려고 합니다.

스프링 이벤트란?

스프링 이벤트는 애플리케이션 내부에서 이벤트를 발행하고 이를 처리하기 위한 메커니즘입니다.

특정 로직에서 이벤트를 발행하면, 이를 구독하고 있는 리스너가 해당 이벤트를 받아 처리하는 구조로 동작합니다. 이 과정에서 발행자와 처리 로직이 직접적으로 연결되지 않기 때문에, 서로 간의 의존성을 낮출 수 있습니다.

즉, 스프링 이벤트는 하나의 기능을 여러 책임으로 나누고, 이를 느슨하게 연결하기 위한 방식입니다.
예를 들어 회원 가입이 완료된 이후, 포인트 지급이나 알림 발송과 같은 후속 작업을 이벤트로 분리하면, 기존 로직을 수정하지 않고도 기능을 확장할 수 있습니다.

Publisher

여기 publisher가 있습니다. String 메시지를 보내는 간단한 코드입니다. 그리고나서 동일한 이벤트 DTO를 사용하는 리스너로 이동하게 되어집니다. 그러면 어떻게 전달 할 수 있는걸까요? 마법이라도 부린 걸까요?

ApplicationEventPublisher부터 이해하도록 하겠습니다.
다음과 같은 동작 방식을 사용이 되어진다고 합니다.
publishEvent를 호출하게 되면 ApplicationContext로 전달이 된다고 합니다.
ApplicationContext:모든 객체(Bean)를 생성하고 관리하는 컨테이너

확인을 해보니 AbstractApplicationContext쪽으로 이동하게 됩니다.

현재 Event는 아쉽게도? 스프링 객체가 아닙니다. 여기서 드는 의문이 있습니다. 그러면 ApplicationContext에 넘겨주지 않아도 되지 않나 싶습니다. 조금더 정확하게 말하면, 넘겨주는 것이 아니라 발행하는것입니다.

비유를 하자면, 우체통에 편지를 넣는다고 해서 편지가 우체국 직원이 되는 건 아닙니다. 편지는 그냥 전달할 내용이고,
우체국 시스템이 그 편지를 적절한 곳으로 보내는 것입니다. 그렇다는 이야기는 ApplicationContext가 우체통이고, event는 편지라고 할 수 있겠네요. 코드를 자세히 보면 event자체가 ApplicationEvent도 될 수 있다는 사실을 알 수 있습니다.

사실 그전에는 event객체를 만들기 위해서는 AplicationEvent를 상속을 받아 이벤트를 만들었습니다. 하지만 지금의 방식은 dto객체를 전달할 뿐입니다.

확인해보면 역시 PayloadApplicationEvent로 applicationEvent를 만들어주고 있습니다.
그위 코드는 typeHint가 명시가 되었을 경우에 사용이 되어집니다. 고로 저희는 다음 코드를 읽을 수 있습니다.

사실 typeHint.. eventType 모두 null인 상태입니다. 고로 타입을 확인을 해줘야 합니다.

객체가 ResolvableTypeProvider를 구현하여 타입 정보를 직접 제공할 수 있다면 해당 타입을 사용하고, 그렇지 않다면 객체의 런타임 클래스 타입을 기반으로 판단합니다.

약간의아하는 곳이 있다고 여겨집니다. 바로 earlyApplicationEvents입니다. 이는 스프링의 초기화여부에 따라 결정이 되어집니다.
즉, 스프링 초기화가 이미 진행중이라면, null이 아니기 때문에 earlyApplicationEvents에 등록되어집니다. 그리고 나서 초기화가 완료가 되어지면 그제서야 이벤트를 발행이 되어집니다.

하지만, 일반적으로 springEvent를 사용할때는 필요가 없습니다. 왜냐하면 스프링 이벤트는 단순히 메시지(payload)만 발행하는 것이 아닙니다. 기본적으로 제공되어지는 스프링 이벤트들도 굉장히 많습니다. 예를 들면, 스프링 준비가 완료가 되었다, 스프링 환경 설정이 종료되었다는 등을 뜻합니다.

아무튼 그게 아니라면 applicationEventMulticaster를 통해 메시지를 발행이 되어진다는 것을 확인 할 수 있습니다.
자세히보면 eventType을 함께 전달 하고 있습니다. 이는 같은 eventType에게 모두 발행이 되어진다는 뜻이 되어집니다.

마지막으로 하위에 parent도 사실은 ApplicationContext입니다. 이말 뜻은 스프링에서 관리가 되어지는 객체라는 뜻입니다. 고로 이것 또한 스프링이 내부적으로 만든 이벤트들을 위해 만들어졌다고 생각하면 될거 같습니다. 간단하게 생각했을때, 자식이 하는 일을 부모도 알게 한다고 이해면 될거 같습니다.

ApplicationEventMulticaster

이제 거의 마지막 단계입니다.
단순히 publisher 하나의 흐름을 따라왔을 뿐인데, 생각보다 내부 구조가 길고 세분화되어 있다는 점을 확인할 수 있었습니다.

ApplicationEventMulticaster는 먼저 현재 이벤트와 타입 정보에 맞는 ApplicationListener들을 조회합니다.
이 과정에서 어떤 리스너가 해당 이벤트를 처리할 수 있는지 선별하게 되며, 내부적으로는 추가적인 필터링 로직이 존재하지만 여기서는 자세히 다루지 않겠습니다. 이후 실제 리스너 실행 단계로 넘어갑니다.
비동기 방식이라면 Executor를 통해 invokeListener를 실행하고, 동기 방식이라면 현재 호출 흐름에서 직접 invokeListener를 수행합니다.

결국 이 단계의 핵심 역할은 명확합니다.
ApplicationEventMulticaster는 이벤트를 처리할 리스너를 찾고, 동기 또는 비동기 방식에 맞춰 해당 리스너에게 이벤트를 전달하는 역할을 수행합니다.

마무리

기존에는 listener까지 학습을 진행하려고 했지만, 생각보다 길게 된느낌이 듭니다. 그래서 publisher까지만 작성하고 listener쪽은 다음에 진행하려고 합니다. instener을 학습할때는, 어노테이션별로 어떻게 동작이 되어지는지 이해해보는 과정을 가져보면 좋다고 느껴집니다.
특히 트랜잭션리스너와 일반 리스너의 차이에 대해 학습할 예정입니다.

라이브락 vs 데드락

klom — Mon, 16 Mar 2026 23:21:45 +0900

이전에 데드락 관련 질문을 한적이 있었습니다. 그 당시 락을 학습을 했었을 때였던걸로 기억합니다. 아무튼 어떤 질문을 했었는데 그거는 데드락이 아니고 라이브락이라는 답변을 받은 적이 있습니다. 지금 이것들이 무엇인지 어떤건지 답변하기 어려워 이번 챕터를 준비를 하였습니다. 라이브락과 데드락의 차이는 무엇일까요?

데드락 (Deadlock)

Deadlock은 두 단어로 이루어져 있습니다.

Dead : 죽은, 멈춘
Lock : 잠금, 자물쇠

이를 직역하면 "죽은 잠금", 혹은 "완전히 막혀버린 상태"라는 의미가 됩니다.
여기서 중요한 것은 Dead입니다. 단순히 잠겨 있는 상태가 아니라 더 이상 아무것도 진행되지 않는 상태를 의미합니다.

가장 유명한 예시가 식사하는 철학자 문제입니다. 여러 명의 철학자가 원형 테이블에 앉아 식사를 하고 있습니다.
각 철학자 사이에는 포크가 하나씩 놓여 있습니다. 철학자는 식사를 하기 위해 양쪽 포크 두 개가 필요합니다.
예를 들어 철학자 A가 식사를 하려면 왼쪽 포크, 오른쪽 포크두 개를 모두 들어야 합니다.
그런데 모든 철학자가 동시에 왼쪽 포크를 먼저 집었다고 가정해 보겠습니다.

출처: 나무위키

그 결과는 어떻게 될까요?

철학자 A는 오른쪽 포크를 기다립니다.
철학자 B도 오른쪽 포크를 기다립니다.
철학자 C도 오른쪽 포크를 기다립니다.
철학자 D도 오른쪽 포크를 기다립니다.

하지만 그 오른쪽 포크는 이미 다른 철학자가 잡고 있습니다. 결국 모든 철학자는 다음과 같은 상태가 됩니다.

하나의 포크는 잡고 있음
다른 포크를 기다리는 중

하지만 그 포크는 절대 풀리지 않습니다. 그래서 아무도 식사를 하지 못한 채 영원히 기다리게 됩니다.
이 상태가 바로 데드락(Deadlock) 입니다. 즉, 서로가 가진 자원을 기다리면서 아무도 작업을 진행하지 못하는 상태입니다.

여기서 철학자는 스레드 혹은 트랜잭션일겁니다. 그리고 포크는 공유 자원입니다. 어떻게 보면 되게 탐욕스럽다고 할 수 있죠.
머릿속에서 상상하길 여러 스레드가 하나의 자원을 점유하려고 한다면, 그것을 점유하려고 싸우게 될겁니다. 그렇게 되면 결국엔 아무도 움직이 못하는 상황이 됩니다.

그렇다면, 데드락이 언제나 발생할까요? 데드락이 발생하는 원인은 총 4가지로 설명할 수 있습니다.

1. 상호 배제 (Mutual Exclusion)

동시에 같은 자원을 사용하는 것은 불가능합니다. 다시 철학자 문제를 생각해봅시다.
철학자문제에서 2개의 포크를 집어야 식사가 가능했다고 하였습니다.

1번철학자와 2번 철학자는 동시에 식사를 할 수 없습니다. 왜냐하면 이미 포크를 이미 누군가(1 or2)가 사용하고 있기 때문이죠.
이를 방지하기 위해서는 순차적으로 식사를 하는 방법을 사용해야 할거 같습니다.

2. 점유 대기 (Hold and Wait)

점유 대기(Hold and Wait)는 이미 하나의 자원을 점유한 상태에서 다른 자원을 기다리는 상황을 의미합니다.
다시 식사하는 철학자 문제로 돌아가 보겠습니다. 철학자가 식사를 하기 위해서는 왼쪽 포크와 오른쪽 포크 두 개가 필요합니다.
예를 들어 1번 철학자가 다음과 같은 상황이라고 가정해 보겠습니다.

왼쪽 포크는 이미 집었습니다.
하지만 오른쪽 포크는 다른 철학자가 사용 중입니다.

이 경우 1번 철학자는 어떻게 될까요?
왼쪽 포크는 계속 쥔 상태로 유지하면서, 오른쪽 포크가 사용 가능해질 때까지 기다리게 됩니다.

즉, 하나의 자원은 점유하고 있고 다른 자원은 대기하고 있는 상태 이것이 바로 점유 대기(Hold and Wait) 입니다.
여기서 중요한 점은 자원을 놓지 않는다는 것입니다.
만약 철학자가 다음과 같이 행동한다면 상황은 달라집니다.
오른쪽 포크가 없으면 왼쪽 포크도 내려놓는다 이렇게 되면 점유 대기 조건이 깨지게 됩니다.
즉, 이미 가진 자원을 계속 쥐고 있으면서 다른 자원을 기다리기 때문에 데드락이 발생할 수 있는 환경이 만들어집니다.

3. 비선점 (No Preemption)

비선점(No Preemption)은 이미 점유된 자원을 강제로 빼앗을 수 없다는 특징을 의미합니다.
다시 식사하는 철학자 문제를 예로 들어보겠습니다.
철학자가 포크를 하나 집었다면, 다른 철학자가 그 포크를 강제로 빼앗을 수 없습니다.
즉, 포크를 집은 철학자가 스스로 내려놓기 전까지는 다른 철학자가 사용할 수 없습니다.
이처럼 자원을 강제로 회수할 수 없다면, 자원을 기다리는 상황이 더 쉽게 만들어질 수 있습니다.

4. 순환 대기 (Circular Wait)

순환 대기(Circular Wait)는 여러 작업들이 서로의 자원을 기다리는 순환 구조가 만들어지는 상황을 의미합니다.
예를 들어 다음과 같은 상황을 생각해 볼 수 있습니다.

철학자 A → 철학자 B의 포크 대기
철학자 B → 철학자 C의 포크 대기
철학자 C → 철학자 D의 포크 대기
철학자 D → 철학자 A의 포크 대기

이처럼 서로가 서로의 자원을 기다리는 순환 구조가 만들어지면 어느 누구도 작업을 진행할 수 없게 됩니다.
이 상태가 바로 데드락입니다.

이렇게 4가지 원인.. 아니고 특징에 대해 작성해봤는데 어찌보면 당연한느낌이라고 인거 같습니다. 즉, 4가지가 충족이되어지면, 데드락이 발생하는 것이 아니라 데드락이 발생이 되어지면 4가지의 조건이 있다고 여겨집니다.

라이브락 (Livelock)

역시 어원을 먼저 생각해봅시다.

Livelock = Live + Lock

Live : 살아있는, 계속 움직이는
Lock : 잠금

직역해 보면 살아있는 락이라는 의미입니다.
이 말은 조금 이상하게 들릴 수도 있습니다. 왜냐하면 락이 걸렸다면 보통 멈춰 있다고 생각하기 때문입니다.
하지만 라이브락은 조금 다른 특징을 가지고 있습니다.
스레드나 작업이 멈춰 있는 것은 아니지만, 서로의 행동 때문에 작업이 계속 진행되지 않는 상태입니다.

어떻게 보면, 데드락과 정반대의 길을 걷는다고 할 수 있습니다. 이것은 반은 맞고 반은 틀린 표현이라고 생각합니다.
혹자는, 데드락의 반대고 점유의 반대가 양보니까 그 둘을 반대로 생각하는 경우도 있을거라고 생각합니다.
하지만, 실제로는 그렇지 않습니다.

다시, 식사하는 철학자 문제로 돌아가봅시다.

만약, 데드락이 아닌 라이브 락이 걸린 상황이라면 어떨까요?
위 특징에 대입을 해봅시다.

다시 철학자 5명이서 식사를 하고 있습니다. 역시나 양쪽에 포크를 들어야 식사가 가능했습니다.
이전에는 철학자끼리 자신이 먼저 식사를 하려고 하다가 음식이 상한 경험이 있는지 이번에는 서로 양보하기 시작했습니다.

출처: 나무위키

여기서 주목해야 하는 점은 점유를 하려 포크를 봤을때, 이미 사용중이라면, 데드락인 경우에는 기다렸습니다.
하지만 양보는 다릅니다.

양보의 가장 큰 특징은 가만히 앉아서 양보가 불가능하다는 점입니다.

양보는 움직여야 합니다. 아니면 말로 식사를 먼저 권유를 해야겠죠?
하지만 모든 철학자가 배려심이 넘쳐서 양보를 계속한다고 해봅시다.

먼저 드세요 먼저 드세요.... 철학자들은 계속 움직이고 양보할겁니다.
하지만 음식은 아무도 먹지 않는 기이한 현상이 발생이 되는 거죠. 이것이 라이브락입니다.

결론

식사하는 철학자 문제를 통해 데드락과 라이브락에 대해 살펴보았습니다. 데드락은 서로 자원을 기다리면서 아무도 움직이지 못하는 상태이고, 라이브락은 서로 양보하려다 계속 움직이지만 작업이 진행되지 않는 상태입니다. 여기서 기억해야 할 점은 양보를 하려면 움직여야 한다는 점입니다. 움직이지 않으면 양보할 수도 없기 때문에, 결국 아무것도 진행되지 않는 데드락 상태가 됩니다. 반대로 계속 움직이며 서로를 피하려다 보면 라이브락이 발생할 수 있습니다. 결국 두 문제는 방식은 다르지만, 시스템의 진행을 막는다는 점에서는 같은 문제라고 볼 수 있습니다.

문제 발견: LazyConnectionDataSourceProxy 톺아보기

klom — Fri, 13 Mar 2026 18:58:00 +0900

read-only일때 replica 사용하게 하기

master-slave 구조 이해하기DB에서 master-slave 형태로 변경하다는 뜻은 읽기 전용과 쓰기 전용을 분리한다는 의미입니다.최근에는 master-slave라는 용어보다는 primary-replica라는 용어로 더 많이 사용이

b-programmer.tistory.com

Master-Slave 환경을 구성하던 중 이상한 현상을 발견했습니다. 정상적인 구조라면 @Transactional(readOnly = true) 상황에서는
Primary가 아니라 Replica로 라우팅되어야 합니다. 하지만 테스트를 진행해보니 예상과 다르게 ReadOnly 트랜잭션에서도 Primary가 사용되는 상황이 발생했습니다. 코드를 잘못 작성한 것일까 여러 부분을 확인해보았지만 특별히 문제를 발견하지는 못했습니다. 그러던 중 LazyConnectionDataSourceProxy를 사용하면 이 문제가 해결된다는 것을 발견했습니다. 실제로 적용해보니 ReadOnly 트랜잭션에서 정상적으로 Replica로 라우팅되었습니다. 하지만 여기서 한 가지 의문이 들었습니다. LazyConnectionDataSourceProxy를 하나 추가했을 뿐인데 왜 문제가 해결된 것일까요? 단순히 붙였더니 된다 수준으로 넘어가기에는 이 동작의 원인을 정확히 이해하지 못한 상태였습니다. 그래서 이번 글에서는 LazyConnectionDataSourceProxy가 무엇인지, 그리고 왜 이 문제가 발생했고 어떻게 해결되는지를 제대로 알아보겠습니다.

LazyConnectionDataSourceProxy란 무엇일까?

간단히 말해 LazyConnectionDataSourceProxy는 커넥션 시점을 늦추는 역할을 합니다.
이 문제를 이해하기 위해서는 먼저 스프링이 언제 데이터베이스 커넥션을 획득하는지 살펴볼 필요가 있습니다.
트랜잭션이 새롭게 시작될 때마다 데이터베이스와 통신하기 위해 Connection을 하나 획득하게 됩니다.
다음과 같은 코드가 존재한다고 합시다.

이 코드는 게시글을 수정하는 간단한 코드입니다. 스프링에서 @Transactional이 적용된 메서드가 호출되면 TransactionManager가 실행되며 트랜잭션을 시작합니다. 이 과정에서 DataSource로부터 Connection을 하나 획득하게 됩니다.

우리가 주목해야 하는 부분은
1. TransactionManager가 트랜잭션이 실행이되며 트랜잭션이 시작이 된다.
2. 그 과정에서 DataSource가 어떻게 Connection을 획득하게 하는가?

이 글을 보면 TransacinalManager이 트랜잭션을 얻는 방법에 대해 나와있습니다.

어떻게 트랜잭셕은 Read only 여부를 알 수 있을까?

b-programmer.tistory.com

다시 복습해보면 PlatformTransactionManager -> AbstractPlatformTransactionManager으로 트랜잭션을 전달하고 있는것을 확인 할 수 있습니다.
AbstractPlatformTransactionManager는 PlatformTransactionManager을 상속받고 있는 클래스입니다. 즉, 자식 클래스라는 뜻이죠.
트랜잭션이 시작이 되어질때, getTransaction을 얻게 되어집니다.

트랜잭션이 시작이 된다는것을 알 수 있습니다. getTransaction() 단계에서 기존 트랜잭션의 존재 여부를 확인합니다.
이후 새로운 트랜잭션이 필요하다고 판단되면 doBegin()이 호출되며, 이 과정에서 실제 Connection을 획득하고 트랜잭션이 시작됩니다.

이름에서 알 수 있듯이 AbstractPlatformTransactionManager는 추상 클래스입니다.
따라서 트랜잭션을 실제로 시작하는 doBegin()의 구체적인 동작은 하위 구현체에서 처리하게 됩니다.

DataSourceTransctionanManager을 선택하면,

Connection이 획득된다는것을 확인 할 수 있습니다. 그렇다면 LazyConnectionDataSourceProxy이라는것은 이름에서 알 수 있듯이 이 프록시는 Connection을 획득하는 시점을 지연시키는 역할을 합니다.

Connection획득시점을 지연을 시키는 이유?

문제의 상황을 다시 살펴보겠습니다.
트랜잭션이 ReadOnly인 상황에서 REPLICA가 아닌 PRIMARY로 동작이 되어지는 상황입니다.

실제 Connection이 획득되는 내부 과정은 잠시 제외하고, 위 흐름만 기준으로 생각해보겠습니다.
DataSource에서 Connection을 획득하는 시점에 라우팅이 이루어지며, 이때 어떤 데이터베이스를 사용할지 결정됩니다.

다시 생각해보면, 원래는 라우팅 이후에 사용할 데이터베이스가 결정되어야 합니다. 하지만 실제로는 라우팅이 수행되기 전에 이미 Connection이 획득되었습니다. 이는 곧 라우팅 로직이 반영되기 전에 데이터베이스 선택이 먼저 이루어졌다는 뜻입니다.

저희가 해야할일은 라우팅 이후에 커넥션을 받도록 유도를 하는것입니다. 이것을 LazyConnectionDataSourceProxy을 통해 커넥션 시점을 뒤로 미루는 이유도 요겁니다.

LazyConnectionDataSourceProxy의 코드를 확인해봅시다.

Connection을 받는 부분을 살펴봅시다.

이걸로 Connection은 프록시로 만들어졌고 다음과 같은 과정을 가지게 됩니다.

LazyConnectionDataSourceProxy -> Connection Proxy -> Statement 실행 시 -> 실제 Connection 획득

결론

Primary-Replica 환경에서 예상과 다르게 데이터베이스 라우팅이 정상적으로 동작하지 않는 상황을 확인할 수 있었습니다. LazyConnectionDataSourceProxy를 적용하자 해당 문제가 해결되는 것을 확인할 수 있었고, 이를 통해 왜 이 클래스가 필요한지에 대해 살펴보는 시간을 가졌습니다. 결국 문제의 핵심은 Connection을 언제 획득하느냐에 있었으며, LazyConnectionDataSourceProxy는 Connection 획득 시점을 지연시켜 올바른 데이터베이스 라우팅이 이루어지도록 도와주는 역할을 한다는 것을 알 수 있었습니다.

Actuator 메트릭 생성 하기

klom — Wed, 11 Mar 2026 23:41:42 +0900

Actuator

k6를 통해 부하 테스트와 API 테스트를 진행하면서 한 가지 한계를 느꼈습니다.요청을 보내고 결과를 확인하는 것은 가능했지만, 실제로 부하가 걸리는 동안 애플리케이션 내부에서 어떤 변화가

b-programmer.tistory.com

이전 장에서 Actuator에 대해 학습해봤습니다. Actuator는 Spring Boot 애플리케이션의 상태 정보를 확인할 수 있도록 제공되는 기능이라는 것을 알 수 있었습니다. Actuator를 통해 애플리케이션의 상태뿐만 아니라 메트릭 정보도 확인할 수 있으며, Prometheus와 같은 모니터링 시스템과 연동할 수 있는 endpoint도 제공됩니다. 또한 기본적으로 제공되는 다양한 메트릭 정보를 확인할 수 있다는 점도 알 수 있었습니다.

그렇다면 기본적으로 제공되는 메트릭 정보 외에도, 애플리케이션에서 필요한 메트릭을 직접 추가할 수 있을까요?

그렇다면 기본적으로 제공되는 메트릭 정보 외에도, 애플리케이션에서 필요한 메트릭을 직접 추가할 수 있을까요?
다행스럽게도 커스텀 메트릭을 추가하는 것도 가능합니다.

보통은 Micrometer의 MeterRegistry를 주입받아 메트릭을 추가합니다.
Actuator가 메트릭 정보를 외부로 노출하는 창구라면, Micrometer는 메트릭을 생성하고 관리하는 도구에 가깝다고 볼 수 있습니다.

MeterRegistry는 Micrometer에서 모든 메트릭을 등록하고 관리하는 중앙 저장소 역할을 합니다.
메트릭은 보통 다음과 같은 흐름으로 수집되고 노출됩니다.

Application -> MeterRegistry -> Micrometer -> Actuator endpoint

즉, 애플리케이션에서 메트릭을 생성하고 MeterRegistry에 등록하면, Actuator가 이를 endpoint 형태로 외부에 노출하게 됩니다.
Micrometer에서는 이러한 메트릭들을 Meter라는 개념으로 관리합니다. 대표적인 Meter의 종류로는 다음과 같은 것들이 있습니다.

Counter : 이벤트 발생 횟수 측정
Gauge : 현재 값 측정
Timer : 작업 수행 시간 측정
DistributionSummary : 값의 분포 측정

해당 내용은 Micrometer 공식 문서를 통해 확인할 수 있습니다.

Supported Monitoring Systems :: Micrometer

AppOptics, Atlas, Azure Monitor, Cloudwatch, Datadog, Datadog StatsD, Dynatrace, Elastic, Humio, Influx, KairosDB, New Relic, Prometheus, SignalFx, Sysdig StatsD, Telegraf StatsD, Wavefront

docs.micrometer.io

저는 다음과 같이 작성하였습니다.

count를 이용했고 다음과 같은것을 확인할 수 있습니다.

락 획득 성공 횟수
락 충돌 횟수
Redis 장애로 fallback 된 횟수
unlock 실패 횟수

acquire time을 이용했고 다음과 같은 것을 확인할 수 있습니다.

락 획득 성공까지 걸린 시간
락 충돌을 판단하기까지 걸린 시간
Redis 장애 발생 후 fallback 판단까지 걸린 시간

task time을 이용했고 다음과 같은 것을 확인할 수 있습니다.

락 획득 이후 실제 비즈니스 로직 수행 시간
락 구간 내부 작업의 병목 여부
성공/실패 케이스별 작업 시간 차이

마무리

메트릭을 메트릭을 생성하고, Actuator를 이용해서 생성한 메트릭을 노출을 시킬수 있습니다. 그걸 프로메테우스가 수집 하고 그라파나를 통해 화면으로 보여줄 수 있는거죠. 이전에 이러한 사실을 모르고 제가 설정을 잘못했는지에 대해 고민한적이 있었습니다. 하지만 알고보니 메트릭을 설정하지 않아서 발생한거라는 생각이 문득 드네요. 내일 프로메테우스랑 그라파나를 연동시켜봅시다.

Actuator

klom — Wed, 11 Mar 2026 16:36:02 +0900

k6를 통해 부하 테스트와 API 테스트를 진행하면서 한 가지 한계를 느꼈습니다.
요청을 보내고 결과를 확인하는 것은 가능했지만, 실제로 부하가 걸리는 동안 애플리케이션 내부에서 어떤 변화가 일어나는지 화면으로 확인하기는 어렵다는 점입니다. 그래서 자연스럽게 이런 생각이 들었습니다. 부하가 걸리는 상황을 시각적으로 모니터링할 수 있다면 더 좋지 않을까? 이럴 때 떠올릴 수 있는 대표적인 도구가 바로 Grafana입니다. Grafana는 메트릭 데이터를 시각화하여 시스템 상태를 한눈에 확인할 수 있게 도와줍니다. 그런데 Grafana가 사용하려면 먼저 애플리케이션이 자신의 상태 정보를 외부로 제공할 수 있어야 합니다. Spring Boot에서는 이를 위해 Actuator를 사용할 수 있습니다. Actuator는 애플리케이션의 상태, 메트릭, 헬스 체크 정보 등을 외부에 노출해주는 기능이며, 이러한 정보들은 모니터링 도구와 연동하는 데 활용됩니다. 이번 기회에 Actuator가 무엇이고, 왜 사용하는지, 그리고 어떤 정보를 제공하는지 학습해보겠습니다.

Actuator란 무엇일까?

Actulator는 Spring boot 애플리케이션의 운영 상태를 외부에서 확인하고 관리할 수 있도록 정보를 제공하는 기능입니다. 애플리케이션이 실행되는 동안 내부에서 발생하는 다양한 정보들을 HTTP endpoint 형태로 노출하여, 개발자나 운영 환경에서 이를 확인 할 수 있도록 도와줍니다.

제일 먼저 그레들에 Actulator를 등록합니다.

implementation 'org.springframework.boot:spring-boot-starter-actuator'

그렇다면, 어떠한 정보들을 HTTP endPoint형태로 제공할까요?

확인을 해보니 Rest형식으로 제공하고 있는것을 확인 할 수 있었습니다. 눈에 띄이는것은 health부분입니다.
들어가서 확인을 해봅시다.

다행히 상태가 UP으로 되어 있네요. 참고로 link에 group을 path로 사용할 수 있습니다.

그 이유는 Actuator가 기본값만 노출하고 있는 상태입니다. 그래서 /actuator에 들어가면 health 관련 링크만 보이는 것입니다.
다른 endpoint는 열어두지않는 상태입니다. 찾아보니 보안상 문제로 많은 endpoint들을 오픈하지 않는다고 합니다.
그렇다면, 다른 endpoint들도 확인을 하려면 어떻게 해야 할까요?

Endpoints :: Spring Boot

If you add a @Bean annotated with @Endpoint, any methods annotated with @ReadOperation, @WriteOperation, or @DeleteOperation are automatically exposed over JMX and, in a web application, over HTTP as well. Endpoints can be exposed over HTTP by using Jersey

docs.spring.io

이 문서를 보면 확인할 수 있습니다.

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus

요렇게 지정하면, health, info, metrics,prometheus가 노출됩니다.
만약 include를 *로 지정한다면 모든 endpoint를 열 수 있습니다.

Actuator를 통해 다양한 정보를 endpoint 형태로 제공할 수 있다는 것을 확인할 수 있습니다.
또한 일반적인 endpoint 외에도 특수한 목적을 가진 endpoint들이 존재합니다.

대표적으로 다음과 같은 endpoint가 있습니다.

heapdump : JVM Heap Dump 파일을 제공합니다.
logfile : 애플리케이션 로그 파일의 내용을 확인할 수 있습니다.
prometheus : Prometheus 서버가 수집할 수 있는 형식으로 메트릭을 노출합니다.

각 endpoint는 동작에 필요한 조건이 충족되어야 하며, 조건이 맞지 않는 경우에는 endpoint 자체가 생성되지 않을 수도 있습니다.
참고로 prometheus는 의존성을 추가해야 합니다.

implementation 'io.micrometer:micrometer-registry-prometheus'

이제 실제로 테스트를 진행해봅시다.

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus

저는 이렇게 4개를 등록해보겠습니다. 현재 상태에서는 prometheus의 의존성이 추가가 되지 않았기 때문에 앞에 3개만 endpoint로 사용할 수 있습니다.

그래서 Actuator를 이용해서 무엇을 할 수 있는데?

Actuator를 사용하면 애플리케이션의 현재 상태를 확인할 수 있으며, 추후에는 메트릭 정보를 수집하고 모니터링하는 용도로 활용할 수 있습니다. 예를 들어 health endpoint를 통해 애플리케이션이 정상적으로 동작하고 있는지 확인할 수 있고, metrics나 prometheus endpoint를 통해 JVM 메모리 사용량, HTTP 요청 수와 같은 다양한 메트릭 정보를 확인할 수 있습니다. 이러한 정보들은 Prometheus와 같은 모니터링 시스템이 수집하여 Grafana와 같은 도구를 통해 시각적으로 확인할 수 있습니다.

결론

간단하게 Actuator가 어떤 것인지 알아보았습니다. Actuator를 사용하면 현재 애플리케이션의 상태를 확인할 수 있으며, 추후에는 다양한 메트릭 정보를 확인하는 데 활용할 수 있다는 점을 알 수 있었습니다. 또한 운영 환경에서는 보안 문제로 인해 모든 endpoint를 외부에 노출하지 않고, Actuator 포트를 분리하거나 내부 네트워크에서만 접근할 수 있도록 구성하여 관리한다고 합니다. 다만 이 부분은 아직 직접 구성해보지는 않아 자세하게는 알지 못했습니다. 추후에는 Actuator를 통해 수집한 메트릭 정보를 Prometheus와 Grafana와 연동하여 모니터링 환경을 구성해보는 것도 좋을 것 같습니다.

OpenAI는 어떻게 PostgreSQL을 스케일했을까

klom — Tue, 10 Mar 2026 23:21:51 +0900

국내에서는 많은 기업들이 MySQL을 사용하는 경우가 많습니다. 그래서 다른 회사들이 어떤 데이터베이스를 사용하는지에 대해서는 크게 의식하지 않았습니다. 그러다가 우연히 OpenAI가 수억 명의 사용자 규모까지 서비스를 확장한 과정을 설명한 글을 읽게 되었습니다.
(https://blog.bytebytego.com/p/how-openai-scaled-to-800-million) 글을 읽다 보니 OpenAI가 PostgreSQL을 사용하고 있다는 점이 눈에 들어왔습니다. 다양한 데이터베이스가 존재하는데 왜 PostgreSQL을 선택했는지 궁금해졌습니다. 물론 이 글에서 PostgreSQL을 선택한 명확한 이유가 직접적으로 설명되지는 않습니다. 다만 일반적으로 PostgreSQL은 안정성과 성숙한 생태계를 갖춘 관계형 데이터베이스로 알려져 있습니다. 또한 복잡한 쿼리 처리 능력과 확장 기능이 강점으로 꼽히기 때문에 많은 서비스에서 기본적인 선택지로 사용되기도 합니다. 결국 OpenAI가 PostgreSQL을 선택한 이유가 반드시 특별한 기술적 이유 때문이라고 보기는 어렵지만, 안정적이고 검증된 관계형 데이터베이스라는 점에서 자연스러운 선택이었을 가능성이 높다고 생각했습니다.

Open Ai는 왜 스케일을 선택하였을까?

답은 간단합니다. 사용자가 급격히 증가했기 때문입니다.

OpenAI의 서비스는 매우 빠르게 성장했습니다. 예를 들어 GPT 출시 이후 API 서비스와 기업 고객이 늘어나면서 사용자 규모가 수억 명 수준까지 확대되었습니다.

사용자가 늘어나면 자연스럽게 서비스 요청도 증가합니다.
사용자가 증가하면 API 요청이 많아지고, 그 결과 데이터베이스에 대한 조회와 쓰기 요청 역시 함께 증가하게 됩니다.

만약 이런 상황에서 데이터베이스를 스케일하지 않는다면 어떤 문제가 발생할까요?

데이터베이스가 증가한 요청을 감당하지 못하게 되면 응답 속도가 느려지고, 동시에 데이터베이스 연결(connection)이 급격히 늘어나게 됩니다. 결국 이러한 상황이 지속되면 데이터베이스가 병목 지점이 되어 서비스 장애로 이어질 가능성이 높아집니다.

따라서 이러한 문제를 방지하기 위해 데이터베이스를 확장(Scaling) 하는 전략이 필요하게 됩니다.

DB확장 포인트

데이터베이스를 확장하기 위해서는 먼저 어디에서 병목이 발생하는지를 생각해 볼 필요가 있습니다.
즉, 쓰기 성능을 확장해야 하는지, 아니면 읽기 성능을 확장해야 하는지를 판단해야 합니다.

일반적으로는 읽기(Read) 성능부터 확장하는 경우가 많습니다.
먼저 성능 개선 단계로 쿼리 최적화 → 인덱스 사용 → 캐시 도입을 진행합니다. 그래도 문제가 해결되지 않는다면 레플리케이션(Replication)을 통해 읽기 트래픽을 분산합니다.

이후에도 트래픽이 계속 증가한다면 쓰기(Write) 성능 확장을 고려하게 됩니다.

앞서 살펴본 것처럼 OpenAI의 사용자 수는 급격하게 증가했습니다. 사용자 수가 증가했다는 것은 그만큼 쓰기 요청 또한 함께 증가했을 가능성이 높습니다.

그렇다면 자연스럽게 쓰기 성능 확장도 필요해 보입니다.
하지만 OpenAI는 쓰기 확장을 선택하지 않고, 레플리케이션을 통해 읽기 트래픽을 분산하는 구조를 사용했습니다.

그렇다면 어떻게 이런 구조로도 대규모 트래픽을 처리할 수 있었을까요?

그 이유는 생각보다 쓰기 요청이 많지 않기 때문입니다.
크게 3가지 이유가 있습니다.

대부분의 서비스는 읽기 >쓰기 구조입니다.

예를 들어, 사용자 프로필 조회, 설정 조회, 대화 기록 조회, API 상태 조회등 같은 요청들은 대부분 읽기 요청입니다.
그래서 보통 읽기 90% 쓰기 10%정도 구조가 됩니다. 그래서 Open AI도 읽기 트래픽을 분산 하는 것만으로도 큰 효과를 얻을 수 있었습니다.

하지만 OpenAI는 ChatGPT라는 LLM을 사용합니다. LLM은 채팅을 입력을 하게 되면 그것에대한 응답을 작성해줍니다.
여기서 OpenAI가 쓰기작업을 한다고 여겨집니다. 그렇다면, 읽기 90% 쓰기 10%는 OpenAI한테는 다른 의미인걸까요?

그 이유는 ChatGPT 응답은 DB가 아니라 GPU에서 처리가 되어지기 때문입니다.

사용자가 질문을 하면 실제로 일어나는 일은 이렇습니다.

User 질문 -> API Server -> LLM 모델 실행(GPU) -> 응답 생성

여기서 핵심 연산은 모델 추론입니다. 이 과정은 DB, SQL과 거의 관련이 없습니다.
즉, ChatGPT 응답 생성 은 GPU 계산입니다.

그래서 OpenAI도 읽기 트래픽을 분산하는 것만으로도 큰 효과를 얻을 수 있습니다.

여기까지 이해한 내용으로는 LLM 요청 자체는 데이터베이스의 쓰기 작업과 직접적인 관련이 없다는 점을 알 수 있었습니다. 하지만 여전히 의문이 완전히 해소된 것은 아닙니다.

LLM의 응답 생성이 GPU에서 이루어진다고 하더라도, 수억 명 규모의 사용자에게 발생하는 서비스 트래픽을 생각하면 여전히 상당한 쓰기 요청이 발생할 가능성이 있기 때문입니다.

예를 들어 사용자 수가 증가하면 자연스럽게 다음과 같은 데이터가 기록될 수 있습니다.

API 사용량 기록
billing 정보
사용자 활동 로그
시스템 메타데이터

이러한 정보들은 결국 데이터베이스에 저장되어야 합니다. 그렇다면 8억 명 규모의 사용자 환경에서 발생하는 쓰기 트래픽을 어떻게 감당할 수 있었을까요?

OpenAI는 Primary DB가 하는 일을 최소화했습니다.

일반적으로 Primary 역할은 쓰기만 담당하고 읽기는 Replica로 보냅니다.

이렇게 되면 Primary DB는 쓰기 작업만 처리하게 됩니다.
하지만 읽기와 쓰기 데이터베이스를 분리했다고 하더라도 데이터베이스에 부담이 완전히 사라지는 것은 아닙니다.

이를 해결하기 위해 OpenAI는 데이터베이스에 부담을 주는 요소를 최대한 줄이는 방향으로 시스템을 설계했습니다.
예를 들어 느린 쿼리를 제거하고, 인덱스를 최적화하며, connection pool을 사용하는 방식으로 데이터베이스 부하를 줄였습니다.
특히 PostgreSQL은 connection = process 구조를 가지고 있습니다.
즉, 데이터베이스 연결이 하나 생성될 때마다 하나의 프로세스가 생성됩니다.

따라서 connection 수가 과도하게 증가하면 메모리 사용량이 증가하고 context switching이 발생하면서 성능이 저하될 수 있습니다.
이를 해결하기 위해 connection pool을 사용하여 데이터베이스에 직접 연결되는 connection 수를 제한하고, 효율적으로 관리할 수 있도록 했습니다.

PostgreSQL은 connection 하나마다 하나의 process가 생성되는 구조를 가지고 있습니다.
이 방식은 thread 기반 구조에 비해 약간의 성능 비용이 발생할 수 있지만, 대신 높은 안정성을 제공하는 장점이 있습니다.

예를 들어 하나의 process에서 문제가 발생하더라도 해당 connection만 종료되며, 다른 connection에는 영향을 주지 않습니다.
즉, 하나의 요청에서 오류가 발생하더라도 데이터베이스 전체가 영향을 받지 않도록 격리된 구조로 동작합니다.

이러한 특성 때문에 PostgreSQL은 안정성과 신뢰성이 중요한 환경에서 널리 사용되는 데이터베이스 중 하나로 평가됩니다.

결론

물론 이것이 OpenAI의 PostgreSQL 확장 전략의 전부는 아닙니다.
글에서는 MVCC를 비롯해 더 깊이 있는 내용들도 함께 다루고 있으며, 실제로 어떤 방식으로 문제를 해결했는지에 대한 설명도 이어집니다.

이번 글에서는 그중에서도 OpenAI가 PostgreSQL을 어떤 방향으로 확장했는지, 그리고 왜 쓰기 확장보다 읽기 확장과 Primary DB 부하 최소화에 집중했는지를 중심으로 정리해보았습니다.

결국 중요한 점은 데이터베이스를 무작정 바꾸는 것이 아니라, 현재 사용 중인 데이터베이스를 어떻게 효율적으로 운영하고 확장할 것인지 고민하는 과정이라고 생각합니다.

출처
https://blog.bytebytego.com/p/how-openai-scaled-to-800-million
https://openai.com/ko-KR/index/scaling-postgresql/

프록시 JDBC(2)

klom — Mon, 9 Mar 2026 18:27:01 +0900

프록시 JDBC(1)

이전에 저는 파일을 통해 slow쿼리를 계산을 진행하였습니다. 하지만 그러다 보니 실시간으로 메시지를 보여주지 못하였습니다. 처음 의도가 네트워크 상황이라던지 여러 요인들이 존재하기 때

b-programmer.tistory.com

분량과 시간 문제로 다음 편에 작성하게 되었습니다.
이전 장에서는 DelegatingDataSource와 Wrapper를 사용해야 하는 이유를 살펴보았습니다. 우리가 최종적으로 관찰하고 싶은 지점은 execute() 메서드입니다. 이 메서드는 실제로 SQL을 실행하는 역할을 합니다. 하지만 SQL은 execute() 시점에 갑자기 만들어지는 것이 아닙니다. SQL을 실행하려면 그보다 앞서 SQL을 준비하는 과정이 필요합니다. 그리고 그 역할을 담당하는 객체가 바로 PreparedStatement입니다. 즉 우리가 관심 있는 지점은 execute()이지만, execute()를 이해하려면 결국 PreparedStatement까지 올라가야 합니다. 그런데 PreparedStatement는 스스로 생성되지 않고, Connection을 통해 생성됩니다. 또한 Connection 역시 직접 생성되는 객체가 아니라 DataSource를 통해 획득됩니다. 정리하면 JDBC 실행 흐름은 다음과 같습니다.

DataSource → Connection → PreparedStatement → execute()

이 구조 때문에 execute() 호출을 자동으로 관찰하려면, 가장 안쪽 메서드만 따로 다룰 수 있는 것이 아니라 객체가 생성되는 흐름의 시작점부터 개입해야 합니다. 그래서 DataSource부터 Wrapping이 필요했던 것입니다. 다행스럽게도 Spring은 DataSource를 감쌀 수 있는 DelegatingDataSource를 제공합니다. 이를 통해 DataSource 단계에는 비교적 쉽게 개입할 수 있습니다. 다만DelegatingDataSource가 Connection부터 PreparedStatement, execute()까지 자동으로 모두 감싸주는 것은 아닙니다. 즉 DataSource 이후의 흐름에 대해서는 개발자가 직접 Wrapping을 구현해야 합니다. 이번 글에서는 이러한 JDBC 실행 흐름을 따라가며,
Connection과 PreparedStatement를 어떻게 감싸고, 최종적으로 execute() 시점을 어떻게 관찰할 수 있는지 알아보겠습니다.

프록시 객체로 만드는 방법?

프록시 객체를 만드는 방법은 다양합니다.
대표적으로 프록시 패턴을 직접 구현하는 방법, JDK 동적 프록시를 사용하는 방법, 그리고 CGLIB과 같은 라이브러리를 사용하는 방법 등이 있습니다.
이번 글에서는 이 중 JDK 동적 프록시를 이용해 구현해보겠습니다.

그 전에, 왜 JDK 동적 프록시 방식을 선택했는지 먼저 살펴보겠습니다.

방법	장점	단점
JDK 동적 프록시	외부 의존성 없음, execute* 시점에서 정확한 SQL 실행 시간 계측 가능, traceId 같은 애플리케이션 정보 연동 쉬움	프록시 코드 직접 구현 및 유지보수 필요
Hibernate StatementInspector	JPA 환경에서는 자연스럽게 SQL을 가로챌 수 있음	JDBC 직접 호출이나 다른 ORM 경로의 SQL은 잡지 못할 수 있음
Spring AOP (Service/Repo 계층)	적용이 쉽고 코드 스타일 일관성 유지 가능	실제 DB execute 시간이 아니라 서비스 로직 시간까지 포함될 수 있음

방법은 크게 세 가지가 있습니다. 하지만 제가 필요한 것은 SQL 실행 시간을 측정하여 해당 쿼리가 슬로우 쿼리인지 판단하는 것입니다.
먼저 Hibernate StatementInspector의 경우 JPA 환경에서 실행되는 SQL을 가로챌 수 있다는 장점이 있습니다. 하지만 JDBC를 직접 사용하는 경우나 다른 경로로 실행되는 SQL은 잡지 못할 수 있다는 한계가 있습니다. 또한 Spring AOP를 사용하는 방식은 서비스나 리포지토리 계층에서 메서드 실행 시간을 측정하게 됩니다. 이 경우 실제 SQL 실행 시간뿐만 아니라 서비스 로직 수행 시간까지 함께 포함될 수 있습니다. 따라서 제가 원하는 방식은 서비스 로직의 시간이 포함되지 않고, SQL이 실제로 실행되는 시점의 시간만 측정할 수 있는 방법이어야 합니다.
이를 위해서는 JDBC에서 SQL이 실제로 실행되는 지점인 execute() 호출 시점을 기준으로 시간을 측정하는 방식이 가장 적절하다고 판단했습니다.

가장 먼저 DataSource를 Wrapper 클래스로 만들어야 합니다.
이렇게 접근한 이유는 execute() 호출 시점을 관찰하려면, 객체가 생성되는 흐름의 시작점인 DataSource부터 개입해야 한다고 판단했기 때문입니다.

하지만 DataSource를 직접 Wrapping하려고 살펴보니 한 가지 문제가 있었습니다.
DataSource는 단순히 getConnection() 하나만 가진 객체가 아니라, 여러 메서드를 함께 가지고 있는 인터페이스였습니다.
즉, DataSource를 직접 구현하는 방식으로 Wrapper를 만들 경우, 실제로 필요한 기능은 많지 않더라도 인터페이스에 선언된 수많은 메서드를 함께 구현해야 하는 번거로움이 발생했습니다. 결국 DataSource를 Wrapping한다는 것은 단순히 getConnection() 하나만 다루는 일이 아니라, 기존 DataSource가 가지고 있는 동작 전체를 유지하면서 필요한 지점만 확장해야 하는 작업이었습니다.

다행스럽게도 Spring에서는 DataSource를 wrappring해놓은 클래스를 제공하고 있었습니다.
그렇다면 DataSource를 제외한 나머지를 어떻게 하면 wrapping 할 수 있을지 살펴보겠습니다.

wrapping 방법

Proxy.newProxyInstance()

새로운 프록시객체로 만드는 방법입니다. 어떤 정보가 필요한지 체크 해봅시다.

newProxyInstance(ClassLoader loader,
                 Class<?>[] interfaces,
                 InvocationHandler h)

메서드 시그니처를 살펴보면 세 가지 파라미터가 필요합니다.
코드를 확인해보니 자바의 리플렉션(Reflection) 기술을 이용해 런타임에 프록시 객체를 생성하는 방식이라는 것을 알 수 있습니다.

ClassLoader

프록시 객체를 생성할 때 사용할 클래스 로더입니다.
보통 프록시를 생성할 인터페이스의 클래스 로더를 그대로 사용합니다.

그렇다면 클래스 로더를 가져오는 이유가 무엇일까요?
자바에서는 모든 클래스가 ClassLoader를 통해 JVM에 로딩됩니다.
JDK 동적 프록시는 런타임에 새로운 프록시 클래스를 생성하기 때문에, 이 클래스 역시 JVM에 로딩되어야 합니다.

따라서 JVM은 새로 생성된 프록시 클래스를 어떤 ClassLoader를 통해 로딩할지 알아야 합니다.
그래서 Proxy.newProxyInstance() 메서드는 ClassLoader를 파라미터로 요구합니다.

Connection.class.getClassLoader(),

Interfaces

프록시 객체가 구현해야 할 인터페이스 목록입니다.
JDK 동적 프록시는 인터페이스 기반으로 동작하기 때문에, 반드시 구현할 인터페이스를 전달해야 합니다.

ClassLoader는 프록시 클래스를 JVM에 로딩하기 위한 정보이고, interfaces는 프록시 객체가 구현해야 할 인터페이스 목록입니다. 따라서 전달된 인터페이스는 해당 ClassLoader에서 접근 가능한 타입이어야 하며, 보통은 인터페이스를 로딩한 ClassLoader를 그대로 사용하는 방식이 가장 안전합니다.

new Class[]{Connection.class},

InvocationHandler

프록시 객체의 메서드 호출을 실제로 처리하는 객체입니다.
프록시 객체의 메서드가 호출되면, 실제 메서드가 바로 실행되는 것이 아니라 이 InvocationHandler의 invoke() 메서드가 먼저 실행됩니다.

그렇다면 여기에서 진행이 되어지는 것이 무엇일까요?
InvocationHandler는 프록시 객체에서 발생하는 모든 메서드 호출을 가로채고, 그 호출에 대해 추가적인 로직을 수행할 수 있는 핵심 지점입니다.

예시를 몇개 들어봅시다.

Object result = invoke(conn, method, args);
if (result instanceof PreparedStatement ps) {
  return wrapPreparedStatement(ps, (String) args[0]);
}

이 코드는 메소드에 아무것도 실행하지 않고 원 상태를 실행을 시켜줬습니다.
만약, result가 PrepredStatement인 경우 PrepraredStatmet를 wrapping한 결과로 넘어갑니다.

여기서 또 의문이 들었습니다. 이럴거면 원문에서 PrepredStatement가 리턴되어지는것으로 바꾸면 되지 않을까요?
아쉽게도 불가능합니다. 그 이유는 Connection -> PrepredStatement를 리턴해주는 메소드들을 살펴봅시다.

PreparedStatement prepareStatement(String sql)
        throws SQLException;
        
PreparedStatement prepareStatement(String sql, int resultSetType,
                                       int resultSetConcurrency)
        throws SQLException;
        
PeparedStatement prepareStatement(String sql, int resultSetType,
                                       int resultSetConcurrency, int resultSetHoldability)
        throws SQLException;
        
PreparedStatement prepareStatement(String sql, int autoGeneratedKeys)
        throws SQLException;

PreparedStatement prepareStatement(String sql, int columnIndexes[])
        throws SQLException;

하나같이 전부 sql문이 필요합니다. 하지만 api를 실행하기 전까지는 어떤 sql이 실행이 되어졌는지는 모릅니다.
그렇다면 방법은 하나뿐입니다. 이것또한 프록시로 만드는 방법입니다.
다시 코드를 보면

Object result = invoke(conn, method, args);

invoke가 되어지는 부분이 존재합니다. 보시면 conn, method, args정보가 들어가있습니다.
우리가 주목해야 하는 부분은 바로 args입니다. 그러니까 이렇게 처리하게 되면 2가지 장점이 있습니다.
첫 번째는 객체 도중에 추가 기능을 추가하는 것이 있고, 두 번째는 매개변수를 개발자가 몰라도 넣을 수 있다는 점입니다.

이를 이용하게 하면

if (result instanceof PreparedStatement ps) {
  return wrapPreparedStatement(ps, (String) args[0]);
}

요렇게 사용할 수 있습니다. 만약 결과가 PreparedStatemet라면 result값이랑 매개변수 첫번째를 넘겨줍니다.

이제 두번째 예시입니다.

return (PreparedStatement) Proxy.newProxyInstance(
    PreparedStatement.class.getClassLoader(),
    new Class[]{PreparedStatement.class},
    (proxy, method, args) -> {
      long startedNanos = System.nanoTime();
      try {
        return invoke(target, method, args);
      } finally {
        monitor.collect(sql, toElapsedMillis(startedNanos));
      }
    }
);

코드가 살짝 다른데요.
우리가 주목을 해야 하는 부분은 바로

long startedNanos = System.nanoTime();
try {
  return invoke(target, method, args);
} finally {
  monitor.collect(sql, toElapsedMillis(startedNanos));
}

이것이 바로 wrapper로만 사용하지 않고 프록시까지 사용하는 방법입니다. invoke위를 보시면 startedNanos가 존재하는 것을 확인 할 수 있습니다. 그리고 나서 invoke가 실행이 된다면? 물론 약간의 네트워크 시간이 있을 수 는 있겠지만, 그것이 확인하는데 문제가 될정도는 아닐겁니다. 만약, 문제가 된다면 직접 db 로그를 확인 하는 방법이 더 효율적이라고 생각합니다.

그리고 나서 객체가 생성이 완료가 된 이후에 시간 측정을 완료한다면, slow쿼리를 측정할 수 있습니다.
이는 프록시 객체로 만들어서 추가 기능을 만드는 방법입니다.

두 가지 예시를 살펴봤는데요. 어째서 Connection도 wrapping을 하는지 이해를 했습니다.

결론

어제에 이어서 코드 분석을 진행하였습니다. 어째서 jdk 동적 프록시를 사용하는지 알아보았습니다.
이제와서 고백하는데 프록시 JDBC라는 말은 없습니다. 정확히 말하면 Datsource를 프록시화한거지만요..
사실 이 기능은 라이브러리를 사용하면 조금더 편한다고는 하는데 정확하게 이 코드에 대해 설명하기 위해서는 라이브러리를 사용하지 않는것이 좋다고 판단하였습니다.
아무튼 이렇게 정리를 해보니 눈에 보이는것같습니다. 리플렉션 기술은 무분별하게 사용하면 안된다고 합니다.

시간이 된다면 jdk 동적 프록시 vs cglib와 레플렉션에 대해 깊게 학습하는 시간을 가져봅시다.

프록시 JDBC(1)

klom — Sun, 8 Mar 2026 22:52:25 +0900

이전에 저는 파일을 통해 slow쿼리를 계산을 진행하였습니다. 하지만 그러다 보니 실시간으로 메시지를 보여주지 못하였습니다. 처음 의도가 네트워크 상황이라던지 여러 요인들이 존재하기 때문에 파일을 읽는 것을 선택하였지만, 곰곰히 생각해보니 그것을 어플리케이션 쪽에서 파일을 읽을 필요는 없었습니다. 어플리케이션에서 slow쿼리를 확인할때 그것이 네트워크 이슈나 다른 이슈들이 섞여있지 않다는 것을 확인할 필요가 없었습니다. 만약, db쪽에 slow쿼리 이슈라면 파일만 만들어두고 확인하는 방법을 선택하면 되었기 때문입니다. 그래서 slow쿼리를 파일로 읽는 방식이 아닌 datasource를 이용해서 어플리케이션에서 읽는 방법을 선택하였습니다. 중요한 사실은 datasorce에서시간 측정하는 것은 불가능합니다. 이것을 가능하게 하는것이 프록시입니다. 이 파트에서 설명할 주제는 프록시 jdbc입니다.

프록시 JDBC는 무엇일까?

프록시 JDBC를 알기전에 프록시가 무엇인지 부터 알아보는게 좋을거 같습니다.
프록시는 대리인이라는 뜻을 가지고 있습니다. 즉, 프록시 JDBC는 JDBC를 대신해서 무언가를 처리를 해주는 것을 의미합니다.
그렇다면 프록시 JDBC는 어떻게 하면 만들 수 있을까요?

이제 Java 애플리케이션이 JDBC를 통해 데이터베이스에 어떻게 접근하는지 살펴보겠습니다. Java에서는 데이터베이스와 직접 연결하기 위해 JDBC(Java Database Connectivity) 를 사용합니다. 일반적으로 애플리케이션은 JDBC를 사용할 때 DataSource를 통해 Connection을 획득하게 됩니다. DataSource는 데이터베이스 연결 정보를 관리하고, 애플리케이션이 데이터베이스와 연결할 수 있도록 Connection을 제공하는 객체입니다.

즉, Java 애플리케이션에서 데이터베이스에 접근하는 흐름은 다음과 같습니다.

DataSource → Connection → PreparedStatement → execute

JDBC를 대신해서 시간을 측정을 하는 것을 만들 기 위해서는 execute쪽에 프록시 객체를 만들면 되지 않을까요?
이러한 방식이라면 Service나 Repository 메서드 전체 시간이 아니라, 실제로 실행된 SQL 단위로 정확한 실행 시간을 측정할 수 있습니다.

하지만 execute만 프록시 객체로 만들어서 사용하기는 어렵다고 합니다. 그 이유가 무엇일까요?

execute만 프록시 객체로 만들어서 사용하기는 어려운 이유?

핵심은 생성 지점입니다. PreparedStatement는 Connection.prepareStatement()를 통해 생성되어 즉시 호출자에게 반환됩니다. 따라서 이 반환 과정에 개입하지 못하면 원본 객체를 프록시 객체로 치환할 수 없습니다. 결국 자동 적용을 위해서는 Connection이나 DataSource를 래핑하거나, 더 아래 계층인 JDBC 드라이버 수준에서 개입해야 합니다.

결국은 execute를 실행하기 위해서는 PreparedStatement가 필요하고,
PreparedStatement를 생성하기 위해서는 Connection을 필요하고,
Connection은 DataSource를 통해 생성되어집니다. 결국 DataSource부터 Wrapper 객체로 만들어야 합니다.
결국 객체 생성 흐름의 시작점인 DataSource 단계부터 프록시를 적용해야 합니다.

다행스럽게도 스프링은 DataSource를 Wrapper 객체를 제공해주고 있네요. 바로 DelegatingDataSource입니다.
그렇다면 DelegatingDataSource가 어떤것인지 알아봅시다.

DelegatingDataSource는 무엇인가?

DelegatingDataSource는 Spring에서 제공하는 DataSource Wrapper 클래스입니다.
이 클래스의 역할은 기존 DataSource를 감싸서 호출을 위임(delegate)하면서 필요한 동작을 확장할 수 있도록 하는 것입니다.
즉, DelegatingDataSource 자체가 특별한 로직을 수행하는 것은 아니고, 기존 DataSource를 감싸는 기본 구조를 제공하는 클래스라고 볼 수 있습니다.

그렇다면 DelegatingDataSource로 무엇을 할 수 있을까?

즉, DataSource를 그대로 두면서, 중간에 원하는 동작을 추가할 수 있게 해줍니다.
예를 들어 getConnection()이 호출될 때 로그를 남기는 작업, 반환되는 Connection을 감싸는 작업,추가 설정을 넣는 작업
같은 작업들을 할 수 있습니다. 쉽게 말해서, 기존 DataSource를 바꾸지 않고 확장할 수 있게 해주는 Wrapper라고 보면 됩니다.

우리가 짚고 넘어가야 할 부분이 있습니다. 바로 반환되는 Connection을 감싸는 작업과 추가 설정을 넣는 작업입니다.
얘네가 왜 중요하냐면

DataSource → Connection → PreparedStatement → execute

이 흐름에서 다음 단계로 가기 위해서는 Connection을 감싸야 하기 때문이죠.

결론

주말이라 생각보다 많이 쓰지 못하였습니다. 최대한 이것을 왜 사용하고 좀더 줄일 수 없을까 라는 고민을 했던거 같습니다.
오늘은 조금 더 쉬고 싶어서 내일로 미루려고 합니다.
다음 글에서는 프록시 객체로 만들 수 있는지 확인해봅시다.

분명... slow쿼리를 모니터링하려고 했는데... 어째서...

klom — Fri, 6 Mar 2026 19:27:23 +0900

 return wrapPreparedStatement(preparedStatement, sql);

슬로쿼리 모니터링 인터페이스 제작

슬로 쿼리를 모니터링 인터페이스를 만들기위해 어떤 작업을 해야 할까요? slow 쿼리는 어떻게 탐지할 수 있을까?Slow Query는 단순히 실행 시간이 길었던 쿼리를 의미하는 것이 아니라, 데이터베이

b-programmer.tistory.com

모니터링 서비스를 만들면서, DB가 슬로우 쿼리로 판단한 요청을 로그나 알람 형태로 수집하고 보여주는 기능을 구현하고자 했습니다. 초기에는 long_query_time 값을 의도적으로 매우 낮게 설정한 뒤 테스트를 진행했고, 이때는 스케줄링 방식으로 실행했을 때도 비교적 정상적으로 슬로우 로그가 기록되는 것을 확인할 수 있었습니다. 하지만 실제 운영 환경을 가정해 long_query_time을 1~2초 수준으로 조정한 뒤 다시 테스트했을 때는 기대와 달리 slow.log가 기록되지 않았습니다. 조회한 쿼리가 단순한 SELECT 문이었기 때문일 수도 있지만, 현재로서는 그 이유를 명확히 판단하지 못했습니다. 이 부분은 추가적인 확인이 필요하다고 생각합니다. 그래서 데이터를 의도적으로 크게 늘려 보면서 다시 테스트했습니다. 100만 건, 1000만 건, 그 이상까지 확장하려 했고, 최종적으로는 1억 건 수준까지 시도하고자 했습니다. 다만 도커 환경의 디스크 용량 문제로 인해 더 이상 데이터를 적재할 수 없었고, 확인해보니 약 4000만 건 정도까지 입력된 상태였습니다.이 정도로 데이터를 늘렸음에도 불구하고 SQL 자체의 처리 시간은 여전히 1초 안팎이었습니다. 이 결과를 보면 데이터 양이 아직 충분하지 않았다고 볼 수도 있고, 혹은 단일 테이블 조회였기 때문에 생각보다 빠르게 처리된 것일 수도 있습니다. 이러한 해석 모두 완전히 틀렸다고 보기는 어렵습니다. 다만 흥미로운 점은 API 전체 조회 속도는 1초 이상이 소요되었다는 점입니다. 즉, 실제 체감 성능은 느렸지만, DB 쿼리 자체는 슬로우 쿼리로 분류되지 않았습니다. 앞으로는 많은 데이터가 들어왔음에도 왜 쿼리 실행 시간이 1초 이내로 유지되었는지 학습해보고, 슬로우 쿼리를 어떤 방식으로 효과적으로 수집하고 보여줄 수 있을지 더 고민해볼 예정입니다.

1000만건의 데이터도 1초안에 쿼리가 실행되어지는 이유

쿼리 실행이 1초안에 발생하는 이유는 여러가지가 있었습니다. 일단 제가 사용했던 쿼리를 먼저 살펴보겠습니다.

Page<Post> findAllByDeletedAtIsNull(Pageable pageable);

이것을 쿼리로 생각해보면 다음과 같습니다.

SELECT *
FROM post
WHERE deleted_at IS NULL
LIMIT 10000000;

제일 큰 이유는 조건이 매무 단순하다는 것입니다.
delete_at이 null인 조건은 DB가 처리하기에 복잡한 조건이 아닙니다.
그렇다면 어떤 조건들이 복잡한 조건인지 살펴보겠습니다.

DB가 생각하는 복잡한 조건에 대해 알아봅시다.

DB에서 말하는 복잡한 조건은 단순히 조건식이 길다는 의미가 아니라, DB가 데이터를 찾거나 계산하는 과정에서 추가적인 작업이 많이 필요한 경우를 의미합니다. 즉, 한 row를 읽고 바로 판단할 수 있는 조건이 아니라 추가 연산, 정렬, 집계, 탐색 비용이 발생하는 조건을 말합니다.

첫 번째는 컬럼에 함수나 연산이 적용된 경우입니다.

WHERE LOWER(name) = 'john'
WHERE DATE(created_at) = '2025-01-01'
WHERE price * 1.1 > 100

이 경우 DB는 값을 읽은 뒤 함수나 연산을 수행해야 하므로 모든 row에 대해 추가 계산이 발생합니다.

두 번째는 패턴 검색이나 문자열 탐색이 필요한 경우입니다.

WHERE name LIKE '%kim'

앞에 %가 붙은 검색은 B-Tree 인덱스를 활용하기 어렵기 때문에 대부분 테이블 전체를 검사해야 합니다.

세 번째는 정렬이 필요한 경우입니다.

SELECT *
FROM post
ORDER BY created_at DESC

정렬을 수행하려면 DB는 데이터를 읽은 뒤 메모리에 모아서 정렬 작업을 수행해야 합니다.
데이터가 많을수록 정렬 비용이 크게 증가합니다.

네 번째는 집계나 그룹 연산이 필요한 경우입니다.

SELECT author_id, COUNT(*)
FROM post
GROUP BY author_id

이 경우 DB는 데이터를 읽은 뒤 같은 값을 가진 row들을 묶고 집계 계산을 수행해야 합니다.

다섯 번째는 여러 테이블을 결합하는 경우입니다.

SELECT *
FROM post p
JOIN user u ON p.user_id = u.id

JOIN이 들어가면 DB는 한 테이블의 데이터를 읽으면서 다른 테이블에서 매칭되는 데이터를 계속 찾아야 하기 때문에 처리 과정이 더 복잡해집니다.

여섯 번째는 서브쿼리가 포함된 경우입니다.

SELECT *
FROM post
WHERE user_id IN (
SELECT id FROM user WHERE age > 30
)

이 경우 DB는 내부적으로 서브쿼리를 실행하거나 결과를 별도로 처리해야 하므로 실행 계획이 복잡해질 수 있습니다.
정리하면, SQL에서 복잡한 조건이란 단순히 값 비교만 하는 것이 아니라 추가적인 계산, 정렬, 그룹핑, 테이블 결합 등의 작업이 필요한 경우를 의미합니다. 이러한 작업이 많아질수록 DB가 수행해야 하는 연산량과 I/O 비용이 증가하게 됩니다.
따라서 데이터베이스 성능에서는 단순히 데이터의 개수보다, 쿼리가 수행하는 작업의 종류와 복잡도가 더 큰 영향을 미칩니다.

순차적으로 읽었을 가능성이 매우 크다.

PK만 잡혀 있고 deleted_at 인덱스가 없다면, DB는 보통 테이블을 순서대로 읽으면서 조건을 검사합니다.
이게 중요한 이유는 순차 읽기(sequential scan) 가 생각보다 빠르기 때문입니다. DB가 힘들어하는 건 여기저기 점프하는 랜덤 I/O인데,
지금은 단일 테이블을 앞에서부터 쭉 읽는 형태라면 오히려 효율적일 수 있습니다.
즉, 1000만 건을 복잡하게 찾는 것은 느릴 수 있지만, 1000만 건을 "쭉 읽는 것"은 생각보다 빠를 수 있습니다.

저장 장치와 캐시 영향이 크다

1000만 건이어도 전부 디스크에서 매번 새로 읽는 게 아닐 수 있습니다.

InnoDB Buffer Pool
OS 페이지 캐시

(이들에 대해서는 이글에서는 다루지는 않습니다.)

이런 곳에 이미 데이터가 올라와 있으면, 디스크가 아니라 메모리에서 읽게 됩니다. 그러면 속도가 확 빨라집니다.
그래서 실험에서 특히 주의해야 하는 게, 처음 조회한 속도와 두 번째 이후 조회한 속도는 다를 수 있다는 점입니다.

row 크기가 작으면 1000만 건도 감당 가능하다

1000만 건은 숫자만 보면 커 보이는데, 실제로는 row 하나가 얼마나 큰지도 중요합니다.
예를 들어 컬럼이 몇 개 안 되고 TEXT, BLOB 같은 큰 컬럼이 없으면 한 페이지에 많은 row가 들어갑니다.
그러면 DB는 적은 페이지 I/O로 많은 데이터를 읽을 수 있습니다.
즉, 같은 1000만 건이어도 row가 가벼운 테이블은 빠를 수 있고 row가 무거운 테이블은 훨씬 느릴 수 있습니다.

DB 실행 시간과 애플리케이션 응답 시간은 다르다

여기서 많이 헷갈립니다. DB는 1초 안에 끝났더라도, API는 더 오래 걸릴 수 있습니다.

왜냐하면 API 쪽에는

JDBC ResultSet 처리
JPA 엔티티 매핑
영속성 컨텍스트 관리
Page 객체 생성
JSON 직렬화
네트워크 전송

이런 비용이 추가되기 때문입니다.
특히 1000만 건을 JPA 엔티티로 들고 오는 것은 DB보다 애플리케이션이 더 힘들 수 있습니다.
그래서 DB slow log 는 안 찍혔지만, 그런데 API 는 느리는 상황이 충분히 나올 수 있습니다.

먼저 슬로우 쿼리라는 개념을 다시 정의할 필요가 있다고 생각합니다. 앞선 실험에서 확인했듯이, 데이터가 1000만 건 이상 존재하더라도 항상 느린 쿼리가 되는 것은 아니었습니다. 단순 조회의 경우 예상보다 빠르게 처리될 수 있으며, 이 경우 DB 입장에서는 슬로우 쿼리로 판단되지 않을 수도 있습니다. 하지만 이러한 상황에서도 API 응답 시간은 충분히 느려질 수 있습니다. 즉, 사용자는 느리다고 느끼지만 DB에서는 슬로우 쿼리가 기록되지 않는 상황이 발생할 수 있습니다. 이때 중요한 것은 어디에서 지연이 발생하는지 정확하게 파악하는 것이라고 생각합니다. 일반적으로 슬로우 쿼리를 확인하기 위해 DB에서 생성하는 slow.log 파일을 분석하는 것은 매우 자연스러운 접근 방식입니다. 하지만 만약 쿼리 자체는 빠르게 실행되었고, 실제 병목이 애플리케이션 로직이나 데이터 처리 과정에 있다면 어떻게 해야 할까요? 이 경우 단순히 DB의 슬로우 로그만 확인하는 방식으로는 문제를 파악하기 어렵습니다. 그렇다고 해서 애플리케이션 레벨에서만 느린 요청을 기준으로 판단하는 것도 정확한 접근이라고 보기는 어렵습니다. 결국 중요한 것은 DB, 애플리케이션, 네트워크 등 각 계층에서의 처리 시간을 구분하여 관찰하는 것입니다. 어디에서 실제 지연이 발생하는지를 명확하게 파악해야 보다 정확한 모니터링과 문제 분석이 가능하다고 생각합니다.

일단은 다시 처음부터 테스트를 진행하도록 하겠습니다.

일단 DB에서 슬로우 쿼리는 1초로 설정하겠습니다.
앞으로 DB에서 발생한 슬로우 쿼리는 단순히 느린 요청이 아니라, 쿼리 자체의 성능이 떨어졌다는 신호로 보고 쿼리를 수정하거나 튜닝해야 하는 대상으로 사용해야 할 것 같습니다.

slow.log파일도 초기화를 시켜뒀습니다.

데이터는 1000만건 정도 들어가있는 상태입니다. 이제 postman으로 돌려보겠습니다. (스웨거로 돌리고 싶었지만 시간체크를 하지 않나요..ㅜㅜ)

생각보다 api 조회 성능이 나쁘지 않네요. 이러면 어떻게 해야할지... 당황스럽네요.

일단, 마음 추수리고 그럼에도 불구하고 앱에서도 측정하는 방법을 추가하였습니다.
처음에는 AOP를 이용하는 방법을 생각했었는데 AOP말고 인터셉터로 사용할 수 있는 방법이 있었습니다.

AOP가 아닌 인터셉터로 구현한 이유?

AOP를 사용하면 일반적으로 Repository 나 Service 메서드의 실행 시간을 측정하게 됩니다. 하지만 이렇게 측정한 시간은 실제 SQL 1건의 실행 시간이라기보다, 메서드 전체 수행 시간이 함께 포함된 값입니다. 예를 들어 하나의 서비스 메서드 안에서 여러 개의 SQL이 실행될 수 있습니다. 이 경우 AOP로는 해당 메서드가 얼마나 오래 걸렸는지는 알 수 있지만, 어떤 쿼리가 느렸는지, 혹은 각 쿼리가 얼마나 걸렸는지를 정확하게 구분하기 어렵습니다.
또한 JPA를 사용하는 경우에는 지연 로딩과 같이 개발자가 직접 작성하지 않은 SQL이 내부적으로 추가 실행될 수 있습니다.
이러한 쿼리들은 메서드 단위 측정만으로는 추적이 부정확해질 수 있습니다.
반면 현재처럼 DataSource 또는 Statement 레벨을 가로채는 방식은, 실제 JDBC execute 시점을 기준으로 동작합니다.
즉, 애플리케이션 메서드가 아니라 실제로 실행된 SQL 단위로 시간을 측정할 수 있습니다.

결국 슬로우 쿼리 모니터링의 목적이 "어떤 서비스 메서드가 느린가"를 찾는 것이 아니라 "어떤 SQL이 실제로 느리게 수행되었는가"를 식별하는 것이라면, AOP보다 인터셉터 기반의 데이터소스 프록시 방식이 더 적절하다고 판단했습니다.

DataSource 또는 Statement 레벨 가로채기

public class AppDbLatencyDataSource extends DelegatingDataSource

이 클래스를 사용하게 되면 Datasource를 유지하면서 새로운 기능으로 확장이 가능하다고 합니다.
데이터베이스 성능을 이해하려면 애플리케이션과 데이터베이스가 어떻게 통신하는지부터 생각해볼 필요가 있습니다.
애플리케이션은 데이터베이스와 직접 데이터를 주고받으며 동작하기 때문입니다. 먼저 애플리케이션과 데이터베이스가 어떤 방식으로 연결되는지 살펴보겠습니다. 일반적으로 데이터베이스와 애플리케이션 간의 통신은 TCP 기반 네트워크 프로토콜을 통해 이루어집니다.
즉, 애플리케이션에서 쿼리를 실행하면 내부적으로는 TCP 연결을 통해 데이터베이스 서버로 요청이 전달되고, 데이터베이스는 쿼리를 처리한 뒤 결과를 다시 TCP를 통해 애플리케이션으로 반환합니다.
이 과정에서 단순히 SQL을 실행하는 것뿐만 아니라 네트워크 전송, 결과 데이터 반환, 데이터 파싱 등의 과정이 함께 이루어지게 됩니다.
따라서 데이터베이스 성능을 분석할 때는 단순히 SQL 실행 시간뿐만 아니라, 애플리케이션과 데이터베이스 간의 통신 과정도 함께 고려할 필요가 있습니다.

데이터베이스와 통신하기 위해서는 Connection을 통해 연결을 맺어야 합니다

Connection은 애플리케이션과 데이터베이스 사이에서 실제로 데이터를 주고받는 대화 채널(세션) 역할을 합니다.
Connection을 통해 다음과 같은 작업을 수행하게 됩니다.

SQL 실행 객체(PreparedStatement) 생성
트랜잭션 제어 (commit, rollback)
자동 커밋 및 트랜잭션 격리 수준 설정
데이터베이스와의 실제 연결 유지 및 종료

일반적으로 SQL이 실행되는 흐름은 다음과 같습니다.

Connection → PreparedStatement → execute

먼저 Connection을 통해 데이터베이스와 연결을 맺고, 그 다음 PreparedStatement를 생성하여 실행할 SQL을 준비합니다.
마지막으로 execute()를 호출하면서 실제로 SQL이 데이터베이스로 전달됩니다. 여기서 우리가 주목해야 하는 부분은 바로 execute() 호출 시점입니다. 이 시점에서 애플리케이션은 실제로 SQL을 데이터베이스로 보내게 되고, 데이터베이스는 쿼리를 실행한 뒤 그 결과를 다시 애플리케이션으로 반환합니다.
즉, SQL 실행 시간을 정확하게 측정하려면 메서드나 비즈니스 로직 단위가 아니라, 실제 JDBC execute()가 호출되는 시점을 기준으로 측정해야 합니다.

Connection에 대해서는 어느 정도 이해가 되었으니, 이제 PreparedStatement와 execute가 무엇인지 생각해볼 필요가 있습니다.

특히 PreparedStatement의 역할을 이해하는 것이 중요합니다. PreparedStatement는 실제로 실행할 SQL을 준비하는 객체입니다.
애플리케이션은 Connection을 통해 PreparedStatement를 생성하고, 그 안에 실행할 SQL을 설정하게 됩니다.

예를 들어 다음과 같은 코드가 있다고 가정해보겠습니다.

PreparedStatement ps = connection.prepareStatement(
    "SELECT * FROM post WHERE id = ?"
);
ps.setLong(1, 10);
ps.executeQuery();

이 과정에서 먼저 prepareStatement()를 호출하면서 SQL이 준비(prepared) 됩니다.
이 단계에서는 SQL 구조가 데이터베이스에 전달되고, 실행 계획을 준비하는 과정이 이루어질 수 있습니다.
그 다음 setLong()과 같은 메서드를 통해 실제 파라미터 값을 바인딩합니다.

마지막으로 execute() 또는 executeQuery()가 호출되는 순간,
PreparedStatement에 준비된 SQL이 실제로 데이터베이스에 전달되고 실행됩니다.
즉, 흐름을 정리하면 다음과 같습니다.

Connection → PreparedStatement 생성 → 파라미터 바인딩 → execute() 호출 → SQL 실행

여기서 중요한 점은 실제 SQL 실행은 execute() 시점에 발생한다는 것입니다. 따라서 SQL 실행 시간을 정확하게 측정하려면 Service나 Repository 메서드가 아니라, JDBC의 execute()가 호출되는 시점을 기준으로 측정하는 것이 더 정확합니다.
이러한 이유로 슬로우 쿼리를 측정할 때는 AOP보다는 DataSource 또는 Statement 레벨을 가로채는 방식이 더 적절하다고 볼 수 있습니다.

여기서 주목해야 하는 사실이 우리는 쿼리의 시간을 측정하는것이 목표입니다. 그렇기 때문에 만약 preparedStatement이 아니라면 시간 측정 대상이 아니기 때문에 결과를 그대로 반환 합니다.

if (!"prepareStatement".equals(methodName) && !"prepareCall".equals(methodName)) {
  return result;
}

if (!(result instanceof PreparedStatement preparedStatement)) {
  return result;
}

이제 모든 sql문이 preparedStatement인 코드만 모여졌습니다.
다시 프록시로 감싸겠습니다.

return wrapPreparedStatement(preparedStatement, sql);

앞서 Connection과 PreparedStatement, 그리고 execute() 호출 시점을 살펴보았으니, 이제는 실제로 SQL 실행에 얼마의 시간이 소요되는지 측정해야 합니다.

String traceId = resolveTraceId();
long startedNanos = System.nanoTime();

try {
  Object result = invoke(target, method, args);
  monitor.collect(sql, traceId, toElapsedMillis(startedNanos));
  return result;
} catch (Throwable throwable) {
  monitor.collect(sql, traceId, toElapsedMillis(startedNanos));
  throw throwable;
}

traceId는 MDC에서 읽은 값을 사용하였습니다. 자세한 내용은 다음글을 참고해주세요.

MDC란 무엇인가 그리고 어떻게 설정할 수 있을까?

MDC는 ThreadLocal에 로그 컨텍스트를 저장해두고, logframwork가 자동으로 꺼내 쓰게 만드는 장치라고 합니다. 위의 메시지로 그려보면 위와 같은 그림이 그려집니다. 그렇다면 우리는 어떤것을 학습

b-programmer.tistory.com

그리고 monitor를 통해 기록을 하도록 하였습니다.

이제 모니터...

if (!enabled || elapsedMillis < slowThresholdMillis) {
  return;
}

만약, 설정된 시간보다 더 적게 걸린다면, 슬로우 쿼리가 아니기 때문에 무시를 하고
그렇지 않는 경우에는 적절한 파싱을 거친뒤, 어떻게 보여줄지에 대한 핸들러를 만들었습니다.

@Bean
public AppDbLatencyEventHandler appDbLatencyEventHandler() {
  return event -> {
    log.info("앱 슬로쿼리 감지: queryTime={}초, sql={}", event.queryTime(), event.sql());
  };
}

결론

처음 의도자체는 DB에서 읽어서 보여주는 것이 조금더 합리적이라고 판단하였습니다. 하지만 외부 환경에서 파일을 읽는 작업이다보니 추가적인 리소스가 발생하여 자주 사용하지 못한다는 단점을 가지고 있었습니다. 그럼에도 불구하고 진행했던 이유는 실시간으로 보여줄 필요가 없을거 같다 느껴져 진행했었습니다. 하지만 1000만건의 데이터가 들어갔음에도 불구하고 slow.log에 로그가 찍히지않는 문제가 발생하였습니다. 엎친데 덮친격으로 스웨거에서는 속도가 빠르게 나오지는 않았습니다. 체감상 2~3s정도 걸렸던거 같습니다. 그래서 애플리케이션측면에서도 슬로우 쿼리를 측정하는것이 나쁘지 않다고 판단하였습니다. 아무리 슬로우 쿼리일지라도 어디에서 느린 성능을 보이는지 정확하게 판단이 되어진다면, 조금더 빠른 대처가 가능하다고 생각하였습니다. 만들다보니 하나 안 사실이 있는데 애플리케이션은 실시간으로 보여줄수 있었습니다. 즉, DB에서 읽었을때 보다 빠르게 대처가 가능하였습니다. 지금 생각해보면 DB에서 파일을 읽어서 가져올 필요없이 DB에는 설정만해놓고 애플리케이션에서 확인하고 만약에 로그가 발생하였다면, 그때 DB의 slow.log파일을 읽어보는 것이 합당하지 않나 여겨집니다. (참고로 스웨거에서는 느렸지만 포스트맨으로 확인해보니 50s안쪽으로 들어왔었습니다.)

데이터베이스의 종류

klom — Thu, 5 Mar 2026 23:39:56 +0900

데이터베이스는 데이터를 저장하고 관리하기 위한 인프라입니다. 일반적으로 데이터베이스라고 하면 가장 먼저 관계형 데이터베이스(RDB)를 떠올리는 경우가 많습니다. 하지만 최근에는 관계형 데이터베이스뿐만 아니라 NoSQL 데이터베이스도 함께 사용하는 경우가 많아졌습니다. 특히 애플리케이션의 요구사항에 따라 서로 다른 데이터베이스를 조합하여 사용하는 사례도 점점 늘어나고 있습니다. 또한 데이터베이스의 종류는 RDB와 NoSQL만 존재하는 것이 아닙니다. 각각의 목적과 특성에 따라 다양한 데이터베이스 유형이 존재합니다.
이번 글에서는 이러한 다양한 데이터베이스 유형에 대해 함께 알아보겠습니다.

RDB vs Nosql

크게 DB에는 2가지 종류가 존재합니다. SQL을 사용하는 RDB와 SQL도 사용하는 NoSql(NoSql이 왜 Nosql인지에 대해 sql을 안써서 noSql이다 아니다 Not only sql의 약자라 그렇다라는 말들이 존재합니다. 안 중

b-programmer.tistory.com

이전 글에서는 2가지만 소개했었네요. 그럼 빠르게 RDB랑 NoSQL정리하고 나머지도 학습해봅시다.

가장 잘 알고 있는 관계형 데이터 베이스 RDB부터 알아봅시다.

가장 익숙한 데이터베이스 유형인 관계형 데이터베이스(RDB)부터 살펴보겠습니다.
관계형 데이터베이스에서 가장 중요한 특징 중 하나는 트랜잭션(Transaction)입니다. 트랜잭션은 ACID라는 특성을 기반으로 동작합니다. 이 글에서는 ACID에 대해 자세히 다루지는 않지만, 이러한 특성 덕분에 관계형 데이터베이스는 정확한 데이터 관리가 중요한 서비스에서 널리 사용됩니다. 예를 들어 데이터의 정확성과 일관성이 매우 중요한 영역에서 주로 활용됩니다.

관계형 데이터베이스의 주요 특징으로는 강한 데이터 정합성 보장과 복잡한 쿼리 처리 능력을 들 수 있습니다. 반면, 수평 확장이 상대적으로 어렵고 스키마 변경이 까다롭다는 단점이 있습니다. 이말은 한번 결정하면 수정하기가 굉장히 까다롭다는 뜻이라고 할 수 있습니다.

또한 구조화된 데이터에 최적화되어 있기 때문에 비정형 데이터나 반정형 데이터를 처리하는 데에는 한계가 있을 수 있습니다.

그렇다면 NoSQL은 어떨까?

관계형 DB의 확장성 문제를 해결하려고 등장하였습니다. 대표적으로 MongoDB, Cassandra, Redis, DynamoDB가 존재합니다.
이들은 관계형 DB와 달리 테이블 구조가 아닌 다양한 형태로 존재합니다.

총 4가지 유형이 존재합니다.

Document DB

NoSQL 데이터베이스의 한 종류로, 데이터를 문서(Document) 형태로 저장하는 데이터베이스입니다. 여기서 말하는 문서는 일반적으로 JSON, BSON, XML 같은 반정형 데이터 구조를 의미합니다.
대표적으로 MongoDB가 존재합니다.

반정형 데이터 구조란?

반정형 데이터는 완전히 고정된 구조는 아니지만, 일정한 형태의 구조를 가지고 있는 데이터를 의미합니다.
즉, 기본적인 구조는 존재하지만 필드가 자유롭게 추가되거나 변경될 수 있어 유연하게 데이터를 표현할 수 있습니다.

이러한 데이터들은 주로 JSON 형태로 표현되고 저장됩니다.

{
  "user": {
    "id": 1,
    "name": "name"
  },
  "status": "active"
}

이러한 JSON 구조 덕분에 Document DB에서는 하나의 문서 안에 다양한 형태의 데이터를 함께 저장할 수 있습니다.

Column DB

NoSQL 데이터베이스의 한 종류로, 데이터를 행(Row)이 아닌 열(Column) 단위로 저장하는 데이터베이스입니다.
관계형 데이터베이스는 데이터를 행 단위로 저장하지만, Column DB는 특정 컬럼을 중심으로 데이터를 저장하기 때문에 대량의 데이터를 조회하거나 분석하는 작업에 유리합니다. 이러한 특징 덕분에 대규모 데이터 처리나 분석 시스템에서 많이 사용됩니다.
대표적인 Column DB로는 Apache Cassandra, HBase 등이 있습니다.

열로 저장을 한다는 것은 무슨 의미일까요?

일반적으로 RDB는 행으로 데이터를 저장합니다.

[1, minzzi, 30]
[2, minsu, 28]

하지만 Colunm DB의 저장 방식은 다릅니다.

id   → 1, 2
name → minzzi, minsu
age  → 30, 28

여기서 드는 의문은 이게 왜 대량의 데이터를 저장하는데 유리할까요?

Column DB는 각 행마다 컬럼을 따로 두는 것이 아니라 같은 컬럼 데이터를 묶어서 저장하는 방식입니다.
이러한 구조 덕분에 특정 컬럼을 조회할 때 더 효율적으로 데이터를 읽을 수 있습니다.
예를 들어 age가 30 이상인 사람을 조회하는 상황을 생각해 보겠습니다.
관계형 데이터베이스에서는 다음과 같은 쿼리를 사용합니다.

SELECT * FROM users WHERE age >= 30

관계형 데이터베이스는 데이터를 행(Row) 단위로 저장하기 때문에, 실제로는 각 행의 데이터를 읽으면서 그 안에 있는 age 값을 확인하게 됩니다. 즉, name과 같은 다른 컬럼 데이터도 함께 읽게 됩니다.
하지만 Column DB는 다릅니다. Column DB는 컬럼 단위로 데이터를 저장하기 때문에, age 컬럼 데이터만 읽어도 조건을 판단할 수 있습니다. 즉, 필요한 컬럼 데이터만 조회하면 되기 때문에 읽어야 하는 데이터의 양이 줄어들게 됩니다.
이러한 이유로 Column DB는 대규모 데이터 분석이나 로그 처리와 같은 환경에서 높은 성능을 발휘합니다.

Column DB는 데이터 개수가 다른 것이 아니라 저장 방식이 다르며, 특정 컬럼만 읽을 수 있어 분석 쿼리에 유리합니다.

Key-Value DB

Key-Value DB는 NoSQL 데이터베이스의 한 종류로, 데이터를 Key와 Value의 쌍 형태로 저장하는 데이터베이스입니다.
가장 단순한 형태의 데이터 구조를 가지고 있으며, 특정 Key를 통해 Value를 빠르게 조회할 수 있는 특징을 가지고 있습니다.
예를 들어 다음과 같은 형태로 데이터를 저장할 수 있습니다.

user:1 → yonghun
user:2 → minsu

이처럼 Key를 통해 데이터를 바로 조회할 수 있기 때문에 매우 빠른 읽기와 쓰기 성능을 제공합니다.
이러한 특징 덕분에 Key-Value DB는 캐시, 세션 저장, 설정 정보 관리와 같은 용도로 많이 사용됩니다.
대표적인 Key-Value DB로는 Redis, Amazon DynamoDB 등이 있습니다.

graph DB

graph DB는 데이터 간의 관계(Relationship)를 저장하고 조회하는 데 특화된 데이터베이스입니다.
일반적인 데이터베이스가 데이터를 테이블이나 문서 형태로 저장하는 것과 달리, Graph DB는 노드(Node)와 엣지(Edge) 구조를 통해 데이터를 표현합니다.
예를 들어 다음과 같은 관계를 표현할 수 있습니다.

사용자A → 친구 → 사용자B
사용자B → 친구 → 사용자C

여기서 Node : 데이터를 나타내는 객체 Edge : 객체 간의 관계를 의미합니다.
이러한 구조 덕분에 Graph DB는 데이터 간의 복잡한 관계를 빠르게 탐색할 수 있는 특징을 가지고 있습니다.
대표적인 Graph DB로는 Neo4j, Amazon Neptune 등이 있습니다.
이러한 특징 때문에 Graph DB는 다음과 같은 서비스에서 많이 사용됩니다.

소셜 네트워크(SNS)
추천 시스템
사기 탐지 시스템
네트워크 분석

NoSQL 데이터베이스는 크게 Document DB, Column DB, Key-Value DB, Graph DB 네 가지 유형으로 나눌 수 있습니다.
이러한 데이터베이스는 구조가 유연하고 대량의 데이터를 빠르게 처리할 수 있다는 장점을 가지고 있습니다. 하지만 관계형 데이터베이스와 달리 표준화된 쿼리 언어가 존재하지 않는 경우가 많으며, 데이터 일관성이 상대적으로 약할 수 있다는 특징도 가지고 있습니다.
이러한 이유로 NoSQL 데이터베이스는 관계형 데이터베이스를 완전히 대체하기보다는, 특정 용도에 맞게 함께 사용하는 보조적인 데이터 저장소로 활용되는 경우가 많습니다.

새로운 데이터 베이스: New SQL

NewSQL은 관계형 데이터베이스와 NoSQL 데이터베이스의 장점을 결합하려는 목적으로 등장한 데이터베이스 유형입니다. 기존 관계형 데이터베이스는 ACID 트랜잭션을 기반으로 강한 데이터 일관성을 보장하지만, 대규모 분산 환경에서 수평 확장이 어렵다는 단점이 있었습니다. 반면 NoSQL 데이터베이스는 높은 확장성과 성능을 제공하지만, 데이터 일관성이 약해질 수 있다는 특징이 있습니다.

NewSQL은 이러한 문제를 해결하기 위해 등장했습니다.
SQL과 ACID 트랜잭션을 유지하면서도 분산 환경에서 수평 확장이 가능하도록 설계된 데이터베이스라고 볼 수 있습니다.
대표적인 NewSQL 데이터베이스로는 Google Spanner, CockroachDB, TiDB 등이 있습니다.
정리하면, NewSQL은 관계형 데이터베이스의 강한 일관성과 NoSQL의 확장성을 함께 제공하기 위해 등장한 데이터베이스입니다.

하지만 아직까지는 생태계와 인프라가 충분히 성숙하지 않았다는 단점이 있습니다. 이러한 이유로 현재까지는 관계형 데이터베이스와 NoSQL 데이터베이스를 함께 사용하는 방식이 더 널리 사용되고 있습니다.

시계열 데이터베이스는 도대체 뭘까?

시계열 데이터베이스는 시간을 기준으로 생성되는 데이터를 저장하고 분석하기 위해 만들어진 데이터베이스입니다.
여기서 말하는 시계열 데이터란 시간(Time)과 함께 기록되는 데이터를 의미합니다.
예를 들어 다음과 같은 데이터를 생각해볼 수 있습니다.

10:00 CPU 사용률 30%
10:01 CPU 사용률 35%
10:02 CPU 사용률 33%

이처럼 시간의 흐름에 따라 계속 기록되는 데이터를 시계열 데이터라고 합니다.
이러한 데이터는 일반적인 데이터베이스에서도 저장할 수 있지만, 데이터 양이 매우 많고 지속적으로 기록되기 때문에 효율적으로 저장하고 조회하는 데 한계가 있을 수 있습니다.
그래서 등장한 것이 시계열 데이터베이스(Time-Series DB)입니다.

시계열 데이터베이스는 다음과 같은 특징을 가지고 있습니다.

매우 높은 데이터 쓰기 성능
시간 기반 데이터 조회 최적화
데이터 압축 기능
일정 시간이 지나면 데이터를 자동으로 삭제하는 보존 정책(retention policy)

이러한 특징 때문에 시계열 데이터베이스는 다음과 같은 분야에서 많이 사용됩니다.

서버 모니터링
IoT 센서 데이터
금융 데이터 분석
로그 및 메트릭 데이터 저장

대표적인 시계열 데이터베이스로는 InfluxDB, TimescaleDB 등이 있습니다.

어째서 시간 데이터를 위한 데이터베이스가 등장했을까요?

관계형 데이터 베이스 데이터는 다음과 같은 특징을 가지고 있습니다.

시간이 지날수록 데이터가 계속 추가됩니다.
대부분 쓰기(Insert) 작업이 많습니다.
기존 데이터를 수정하는 경우는 거의 없습니다.
특정 시간 범위를 기준으로 조회하는 경우가 많습니다.

하지만 일반적인 관계형 데이터베이스는 이러한 데이터 패턴에 최적화되어 있지 않습니다.
데이터가 계속 쌓이게 되면 저장 공간이 빠르게 증가하고, 시간 기반 조회 성능도 점점 떨어질 수 있습니다.
그래서 등장한 것이 시계열 데이터베이스(Time-Series DB)입니다.

결론

이번 글에서는 관계형 데이터베이스, NoSQL, NewSQL, 시계열 데이터베이스와 같은 다양한 데이터베이스 유형에 대해 간단하게 살펴보았습니다. 처음에는 새롭게 알게 된 NewSQL과 시계열 데이터베이스를 중심으로 정리해보려고 했지만, 생각보다 정리할 수 있는 내용이 많지 않았습니다. 반면 NoSQL은 여러 가지 유형(Document, Column, Key-Value, Graph)이 존재하다 보니 자연스럽게 NoSQL에 대한 분량이 더 많아졌습니다. 지금까지 ByteByteGo 글을 읽으면서 주로 아키텍처나 설계와 관련된 내용을 중심으로 학습해 왔지만, 장애 상황에 대한 글들은 아직 많이 읽어보지 못했습니다. 그래서 다음 주부터는 서비스 장애나 시스템 장애와 관련된 글들을 중심으로 학습해볼 계획입니다.

하나의 데이터베이스가 모든 문제를 해결할 수는 없기 때문에, 서비스의 특성과 요구사항에 맞게 적절한 데이터베이스를 선택하는 것이 중요하다고 생각합니다.

출처
https://blog.bytebytego.com/p/understanding-database-types

kafka가 Zookeeper대신 KRaft를 사용하는 이유가 뭘까?

klom — Wed, 4 Mar 2026 23:06:34 +0900

카프카를 왜 사용해야 할까?

b-programmer.tistory.com

이전에 카프카가 어떻게 동작하며 왜 필요한지에 대해 학습한 적이 있습니다. 간단히 복습해 보겠습니다. 카프카는 단순한 MQ 시스템이라고 보기는 어렵습니다. MQ 시스템의 구조와 유사한 점은 있지만, 보다 정확하게 표현하면 중앙 이벤트 로깅 시스템에 가깝습니다. 물론 전체적인 구조는 MQ와 크게 다르지 않습니다. 프로듀서(Producer)가 메시지를 발행하고, 컨슈머(Consumer)가 이를 소비하며, 그 사이에는 메시지를 저장하고 전달하는 브로커(Broker)이 존재합니다. 그래서 처음 접하게 되면 "그냥 여러 번 읽을 수 있는 MQ 시스템 아닌가?"라고 이해할 수도 있습니다. 이러한 이해도 크게 틀린 것은 아니지만, 카프카를 단순히 MQ라고 표현하는 것은 다소 부족한 설명이 될 수 있습니다. 그렇다면 한 가지 의문이 생길 수 있습니다. 왜 프로듀서와 컨슈머만 있으면 되지, 굳이 브로커가 존재해야 할까요? 간단히 설명하면 브로커를 사용하는 이유는 효용성때문으로 이해하시면 됩니다. 자세한 내용은

EDA에도 패턴들이 이렇게나 많이 존재 하다니..

b-programmer.tistory.com

이 글을 참고해주면 감사하겠습니다. 초반에는 브로커와 브로커의 메타 정보를 읽는 Zookeeper가 존재하였습니다. 그렇다면 어째서 kafka내부에서 동작시키지않고 Zookeeper라는 외부 인프라를 이용하게 되었을까요?

Zookeeper는 무엇이고, 왜 사용하게 되었을까?

KRaft를 이해하기 전에 먼저 Zookeeper라는 시스템을 이해할 필요가 있습니다.
Zookeeper는 분산 시스템에서 상태를 관리하고 여러 노드의 동작을 조율하는 분산 코디네이션 시스템입니다.
kafka 초기 버전에서는 여러 브로커가 함께 동작하는 클러스터 구조를 사용합니다.

이때 어떤 브로커가 살아있는지, 누가 리더인지, 토픽과 파티션의 메타데이터는 무엇인지와 같은 클러스터 상태 정보를 관리할 필요가 있습니다. 여기서 브로커가 왜 이렇게까지 많이 필요할 이유가 있을까요? 브로커가 많다는 건 어떤 이점이 있을까요?

kafka는 기본적으로 대량의 데이터를 처리하기 위해 설계된 시스템입니다.
단일 서버로는 처리할 수 없는 수준의 트래픽과 데이터를 안정적으로 처리하기 위해 여러 개의 브로커를 사용하는 클러스터 구조를 채택하고 있습니다. (레디스의 전략과는 사뭇 다른 느낌이 듭니다. _.._)

어째서 위와 같은 클러스터 상태 정보들을 관리하는 이유가 무엇일까요?

kafka 초기 버전에서는 클러스터 상태 정보들을 관리하는 역할을 Zookeeper가 담당하고 있었습니다.
kafka는 여러 개의 브로커로 구성된 클러스터 환경에서 동작합니다.
이러한 구조에서는 단순히 메시지를 저장하는 것뿐만 아니라, 클러스터 전체의 상태를 지속적으로 관리해야 합니다.
이처럼 분산 환경에서는 시스템의 상태가 계속해서 변화할 수 있습니다.
kafka는 단순히 메시지를 전달하는 시스템을 넘어, 여러 서버가 함께 동작하는 분산 시스템이기 때문에 이러한 클러스터 상태 정보들을 관리하는 역할이 반드시 필요합니다.

결국 분산 환경에서 클러스터 상태 정보를 관리하기 위해 Zookeeper라는 분산 코디네이션 시스템을 사용하게 되었습니다.

이쯤에서 3가지 의문이 듭니다.

다른 기술들도 많을텐데 Zookeeper를 사용하는 이유가 무엇일까?

kafka가 처음 개발되던 시점에는 분산 시스템의 상태를 관리하는 표준적인 도구로 Zookeeper가 널리 사용되고 있었습니다.
Zookeeper는 다음과 같은 기능들을 제공하고 있었습니다.

분산 환경에서의 리더 선출(Leader Election)
분산 락(Distributed Lock)
클러스터 메타데이터 관리
노드 상태를 감지하는 Watch 기능

이러한 기능들은 kafka와 같은 분산 시스템에서 클러스터 상태를 관리하기 위해 필요한 요소들이었습니다.
따라서 kafka는 이러한 기능을 직접 구현하기보다는 이미 검증된 Zookeeper를 활용하는 방식을 선택하게 되었습니다.
결과적으로 kafka는 초기 설계에서 클러스터 상태 관리 역할을 Zookeeper에 위임하는 구조로 만들어지게 되었습니다.

초창기 kafka에서 Zookeeper를 사용하지 않는 다면, 어떻게 될까?

kafka는 여러 브로커로 구성된 클러스터 환경에서 동작합니다.
이 환경에서는 브로커의 상태, 파티션의 리더 정보, 토픽 메타데이터와 같은 클러스터 상태 정보를 지속적으로 관리해야 합니다.
만약 이러한 정보들을 관리하는 시스템이 존재하지 않는다면 다음과 같은 문제가 발생할 수 있습니다.

어떤 브로커가 살아있는지 알 수 없음
파티션의 리더가 누구인지 결정할 수 없음
토픽 및 파티션 메타데이터가 일관되게 유지되지 않음

이러한 상황에서는 클러스터가 일관된 상태를 유지하기 어렵기 때문에 kafka 시스템 자체가 정상적으로 동작하기 어려워집니다.

Zookeeper는 Kafka와는 별개의 시스템입니다. 그렇다면 Zookeeper에서 장애가 발생하면 어떻게 되는 것일까요?

결론부터 말하자면, Zookeeper 역시 단일 서버로 운영되지 않습니다. kafka와 마찬가지로 클러스터 형태로 구성하여 장애에 대응합니다.
Zookeeper는 여러 개의 노드로 구성된 Zookeeper Ensemble이라는 구조를 사용합니다.
일반적으로 3개 ~ 5개로 사용하는 경우가 많습니다. 이러한 구조에서는 과반수(Quorum) 기반으로 시스템이 동작합니다.
즉, 전체 노드 중 절반 이상이 정상적으로 동작하고 있다면 시스템은 계속해서 동작할 수 있습니다.
예를 들어 Zookeeper 노드가 3개라고 가정해보겠습니다.

이 중 한 노드가 장애가 발생하더라도 나머지 두 노드가 살아 있다면 과반수를 유지하기 때문에 시스템은 계속 동작합니다.
하지만 만약 과반수 이상의 노드가 장애가 발생하게 된다면 클러스터의 합의가 깨지게 되고 정상적인 동작이 어려워질 수있습니다.
이러한 이유로 Zookeeper는 단일 노드로 운영하기보다는 여러 노드로 구성된 클러스터 형태로 운영하는 것이 일반적입니다.
결과적으로 kafka는 브로커 클러스터 외에도 Zookeeper 클러스터를 함께 운영해야 하는 구조를 가지고 있었습니다.

합의는 분산락 3대 요소중 하나로 다음 포스트를 참고하시면 됩니다.

분산락은 도대체 무엇일까?

이전에도 Lock에 대해 학습을 진행한적이 있었습니다. DB락 부터, 낙관 락, 비관 락에 대해 학습을 진행하였죠. RDB vs Nosql크게 DB에는 2가지 종류가 존재합니다. SQL을 사용하는 RDB와 SQL도 사용하는 N

b-programmer.tistory.com

분산 환경에서 클러스터의 상태를 관리하기 위해 초창기 kafka는 Zookeeper를 사용했습니다. 하지만 kafka를 운영하기 위해서는 kafka 브로커뿐만 아니라 Zookeeper 서버도 함께 운영해야 하는 상황이 발생했습니다. 또한 Zookeeper에 장애가 발생할 경우, 심각한 상황에서는 kafka 클러스터의 관리 기능이 정상적으로 동작하지 않을 수도 있습니다. 이처럼 별도의 시스템에 의존하는 구조는 운영 복잡도를 높이는 문제가 있었습니다. 이러한 문제를 해결하기 위해 kafka는 Zookeeper 없이 메타데이터를 관리할 수 있는 구조인 KRaft(Kafka Raft Metadata mode) 를 도입하게 되었습니다.

KRaft는 Zookeeper과 무엇이 다른가?

지금까지 Zookeeper가 어떤 역할을 하는지 대략적으로 살펴보았습니다. 그리고 이러한 역할을 이제는 KRaft가 대신 수행하게 되었습니다. 이전의 kafka 구조에서는 브로커만으로 클러스터를 운영할 수 없었기 때문에 클러스터 상태 관리, 리더 선출, 메타데이터 관리와 같은 기능들을 Zookeeper가 담당하고 있었습니다.

즉, kafka가 직접 처리하지 못하는 클러스터 관리 기능을 외부 시스템인 Zookeeper에 의존하는 구조였습니다.

하지만 KRaft가 도입되면서 이러한 구조가 변경되었습니다. 이제 kafka는 Zookeeper 없이도 클러스터 메타데이터를 관리할 수 있게 되었으며, 관련 기능들은 kafka 내부에 포함된 KRaft 모듈이 담당하게 됩니다.
결과적으로 kafka는 더 이상 외부 시스템에 의존하지 않고 kafka 내부에서 클러스터 상태를 관리할 수 있는 구조로 변화하게 되었습니다.
이러한 구조 덕분에 기존처럼 Zookeeper 장애로 인해 kafka 운영이 복잡해지는 상황을 줄일 수 있게 되었습니다.

그렇다면 이러한 구조적인 차이 외에도 KRaft는 Zookeeper와 어떤 차이점이 있을까요?

가장 큰 차이점은 메타데이터를 관리하는 방식입니다.
기존 kafka 구조에서는 브로커의 상태, 토픽 정보, 파티션 정보와 같은 클러스터 메타데이터를 Zookeeper에 저장하고 관리했습니다.
kafka 브로커들은 필요할 때마다 Zookeeper와 통신하여 해당 정보를 조회하거나 변경했습니다.
하지만 KRaft 구조에서는 이러한 메타데이터를 kafka 내부의 로그(Log) 형태로 저장하고 관리합니다.

즉, kafka가 메시지를 로그 형태로 저장하는 것처럼 클러스터 메타데이터 역시 로그 기반으로 기록하고 복제하는 방식을 사용합니다.
이 과정에서 Raft 합의 알고리즘이 사용됩니다. Raft 합의 알고리즘을 통해 여러 kafka 노드가 메타데이터에 대해 합의를 이루고, 이를 통해 일관된 상태를 유지할 수 있습니다.

Raft 합의 알고리즘이란 무엇일까?

Raft는 분산 시스템에서 여러 노드가 동일한 상태를 유지하기 위해 사용하는 합의(Consensus) 알고리즘입니다.
분산 시스템에서는 여러 서버가 동시에 동작하기 때문에 다음과 같은 문제가 발생할 수 있습니다.

어떤 노드의 정보가 최신 상태인지 알기 어려움
동시에 여러 노드에서 상태 변경이 발생할 수 있음
네트워크 장애로 인해 노드 간 상태가 달라질 수 있음

이러한 상황에서 시스템이 정상적으로 동작하기 위해서는 모든 노드(브로커)가 동일한 상태에 대해 합의하는 과정이 필요합니다.
Raft 알고리즘은 바로 이러한 문제를 해결하기 위해 만들어진 합의 알고리즘입니다.

여러 노드(브로커) 중 하나를 Leader로 선출하고, 나머지 노드(브로커)들은 Follower로 동작합니다.
Leader는 시스템의 상태 변경을 관리하는 역할을 하며, 상태 변경이 발생하면 이를 로그(Log) 형태로 기록한 뒤 다른 노드들에게 전파합니다.
과반수 이상의 노드(브로커)가 해당 로그를 받아들이면 그 상태 변경은 합의된 상태(Committed) 로 인정됩니다.

이러한 과정을 통해 여러 서버가 존재하더라도 모든 노드(브로커)가 동일한 상태를 유지할 수 있게 됩니다.
kafka의 KRaft 구조에서도 이 Raft 알고리즘을 사용하여 클러스터 메타데이터를 관리하고 노드(브로커) 간 상태를 일관되게 유지합니다.

그렇담, Zookeeper는 어떤 합의 알고리즘을 무엇을 사용할까?

Zookeeper 클러스터에서는 다음과 같은 구조가 만들어집니다.

Leader
Follower

Leader가 상태 변경을 관리하고, Follower들은 Leader의 로그를 받아 복제합니다.
동작 과정은 대략 다음과 같습니다.

클라이언트 요청이 Leader에게 전달됩니다.
Leader는 상태 변경을 트랜잭션 로그로 기록합니다.
해당 로그를 Follower들에게 전파합니다.
과반수 노드가 승인하면 commit 됩니다.

이 방식 덕분에 여러 노드가 존재하더라도 데이터의 순서와 일관성을 유지할 수 있습니다.

결론

kafka가 Zookeeper를 더 이상 사용하지 않고 KRaft를 사용하는 이유에 대해 살펴보았습니다. 기존 kafka 구조에서는 kafka 브로커와 함께 Zookeeper 서버를 별도로 운영해야 하는 구조였습니다. 이러한 구조는 시스템을 운영하는 과정에서 운영 복잡도를 증가시키는 요소가 되었습니다. 또한 Zookeeper에 심각한 장애가 발생할 경우, kafka 클러스터의 메타데이터 관리 기능에도 영향을 줄 수 있는 상황이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Kafka는 Zookeeper에 의존하지 않고 내부적으로 메타데이터를 관리하는 구조인 KRaft(Kafka Raft Metadata mode) 를 도입하게 되었습니다. KRaft는 Raft 합의 알고리즘을 기반으로 메타데이터를 관리하며, 이를 통해 분산 환경에서도 여러 노드가 동일한 상태를 유지하면서 안정적으로 시스템을 운영할 수 있도록 합니다. 결과적으로 kafka는 KRaft를 통해 시스템 구조를 단순화하고 운영 복잡도를 줄이는 방향으로 발전하게 되었습니다.

AI시대에서 클린 아키텍처 이해하기

klom — Tue, 3 Mar 2026 23:44:43 +0900

현재 우리는 AI 시대에 살고 있습니다. "AI가 코드를 다 작성해주는데, 이제 아키텍처를 공부하는 것이 과연 의미가 있을까?"
이런 질문을 종종 듣게 됩니다. 어느 정도는 공감이 가는 말입니다. 실제로 AI는 빠르게 코드를 생성하고, 기본적인 구조를 만들어내며, 심지어 리팩토링까지 제안합니다. 과거에 비해 구현의 진입 장벽은 확실히 낮아졌습니다. 하지만 한 가지는 분명합니다. AI가 작성한 코드의 책임은 결국 사람이 져야 한다는 점입니다. AI는 코드를 생성할 수 있지만, 그 코드가 시스템의 맥락에 맞는지, 장기적으로 유지 가능한지, 확장 시 문제가 발생하지는 않는지까지 완전히 보장해주지는 않습니다. 설령 AI를 신뢰한다고 하더라도, 언제나 동일한 환경과 도구를 사용할 수 있다는 보장도 없습니다. 만약 AI의 도움 없이 코드를 작성해야 하는 상황이 온다면, 결국 설계와 구조에 대한 이해는 사람의 몫이 됩니다. 그래서 저는 이번에 클린 아키텍처를 학습해보려 합니다. AI가 코드를 대신 작성해주는 시대일수록, 오히려 시스템의 중심이 되는 구조와 책임에 대해 더 깊이 고민해야 하지 않을까 하는 생각에서입니다.

클린 아키텍처란?

클린 아키텍처는 소프트웨어 시스템을 여러 계층으로 분리하여 각 계층이 명확한 책임을 가지도록 설계하는 구조입니다. 그렇다면 왜 여러 계층으로 나누는 것이 "클린하다"고 표현하는 걸까요? 클린하다는 것은 계층이 많아서 깨끗하다는 뜻이 아닙니다.
오히려 계층이 늘어나면 구조는 더 복잡해질 수도 있습니다. 그럼에도 불구하고 클린이라고 부르는 이유는 따로 있습니다.

소프트웨어가 "더러워지는" 순간은 언제일까요?

컨트롤러에 비즈니스 로직이 섞여 있고,
도메인 객체가 DB 어노테이션에 강하게 묶여 있으며,
서비스가 HTTP 응답 포맷을 알고 있고,
하나의 클래스가 여러 이유로 변경되는 상황입니다.

이때 코드가 복잡해지는 이유는 하나입니다. 기술과 책임이 뒤섞였기 때문입니다.
클린 아키텍처는 이 혼합을 강제로 분리합니다.

이 코드는 비즈니스인가?
기술 구현인가?
외부 시스템과의 연결인가?

이 질문을 끊임없이 던지게 만듭니다. 책임이 명확해질수록 코드의 의도는 선명해집니다. 그 상태를 우리는 "클린하다"고 부릅니다.
또한, 클린 아키텍처는 사실 "시간"을 고려한 설계입니다.
시간이 지나면 프레임워크는 바뀌고, DB는 교체되며, API 방식은 변하고, 팀 구성도 달라집니다.
하지만 비즈니스 규칙은 비교적 오래 유지됩니다. 그래서 클린 아키텍처는 변하지 않는 것을 중심에 두고, 쉽게 변하는 것을 바깥으로 밀어냅니다. 의존성의 방향을 통제하여 변화가 중심을 오염시키지 않도록 합니다. 시간이 지나도 핵심이 유지되는 구조. 그것이 바로 깨끗한 상태를 유지하는 구조입니다. 즉, 클린하다는 것은 책임이 명확하고, 의존성이 통제되어 있으며, 변화가 중심을 침범하지 못하는 상태를 의미합니다.

핵심 원칙 (Key Principles)

클린 아키텍처는 유지보수성과 확장성, 테스트 용이성을 확보하기 위한 몇 가지 핵심 원칙을 기반으로 합니다.
이 원칙들은 시스템의 책임을 명확히 하고, 변화에 강한 구조를 만들기 위한 기준이 됩니다.

관심사 분리 (Separation of Concerns)

관심사 분리는 각 계층이 자신의 책임만 가지도록 명확히 분리하는 원칙입니다.
하나의 구성 요소가 여러 역할을 동시에 수행하지 않도록 하여 책임의 경계를 분명히 합니다.

예를 들어, 컨트롤러는 요청을 받고 응답을 반환하는 역할만 수행해야 합니다.
실제 비즈니스 규칙은 서비스나 유스케이스 계층에서 처리하며, 데이터 저장과 같은 기술적 세부사항은 리포지토리 계층에서 담당합니다.

이 접근 방식에는 두 가지 주요 이점이 있습니다.

첫째, 각 계층이 단일 책임을 가지므로 코드의 의도가 명확해지고 유지보수가 쉬워집니다.
변경이 필요할 때 어디를 수정해야 하는지 명확해지기 때문입니다.
둘째, 특정 계층의 변경이 다른 계층에 영향을 주지 않습니다.
예를 들어 SQL 데이터베이스를 NoSQL로 전환하더라도, 데이터 접근 계층만 수정하면 되며 핵심 비즈니스 로직은 그대로 유지될 수 있습니다.
관심사를 분리한다는 것은 단순히 코드를 나누는 것이 아니라, 변화의 범위를 통제하는 설계 전략입니다.

의존성 규칙 (Dependency Rule)

의존성 규칙은 클린 아키텍처의 핵심 원칙입니다.
이 규칙에 따르면 모든 의존성은 시스템의 중심을 향해, 즉 안쪽으로만 흘러가야 합니다.

프레임워크, UI, 데이터베이스와 같은 외부 계층은 내부 계층(엔티티, 유스케이스)에 의존할 수 있지만, 내부 계층은 외부 계층을 알지 못해야 합니다. 핵심 비즈니스 로직은 기술적 세부사항에 의해 오염되어서는 안 됩니다.

예를 들어, 사용 사례는 특정 데이터베이스 스키마나 UI 프레임워크에 직접 의존해서는 안 됩니다. 대신 데이터 접근 계층은 리포지토리와 같은 인터페이스를 통해 계약만 제공하고, 실제 구현은 외부 계층에서 담당합니다. 데이터베이스가 변경되더라도 유스케이스와 엔티티는 수정할 필요가 없습니다.

이 규칙의 이점은 명확합니다.

첫째, 데이터베이스 교체와 같은 외부 변화가 핵심 비즈니스 로직에 영향을 주지 않습니다. 기술은 바뀌더라도 비즈니스 규칙은 안정적으로 유지됩니다.
둘째, 내부 레이어는 외부 시스템과 결합되지 않기 때문에 독립적으로 테스트할 수 있습니다. 실제 데이터베이스 없이도 핵심 로직을 검증할 수 있습니다.
셋째, 사용자 인터페이스나 데이터베이스와 같은 구성 요소를 최소한의 영향으로 교체할 수 있습니다. 예를 들어 REST API를 GraphQL로 전환하더라도 인터페이스 어댑터 계층만 수정하면 됩니다.
넷째, 새로운 기술이나 기능을 도입하더라도 핵심 논리를 건드리지 않고 시스템을 확장할 수 있습니다.

외부 시스템은 본질적으로 변동성이 큽니다. 웹 프레임워크는 업데이트되고, 라이브러리는 deprecated되며, 인프라는 교체됩니다. 의존성 규칙은 이러한 변화를 코어에서 격리함으로써 장기적으로 안정적인 구조를 유지하게 합니다.

단일 책임 원칙 (SRP)

단일 책임 원칙은 클래스나 모듈이 오직 하나의 이유로만 변경되어야 한다는 원칙입니다.
즉, 하나의 구성 요소는 하나의 책임에만 집중해야 합니다. 여기서 말하는 "책임"은 단순한 기능 단위가 아니라, 변경의 이유를 의미합니다.
만약 하나의 클래스가 서로 다른 이유로 수정될 가능성이 있다면, 이미 여러 책임을 동시에 가지고 있는 것입니다.

예를 들어, 하나의 클래스가 사용자 인증 로직을 처리하면서 동시에 이메일 알림까지 담당하고 있다면 이는 좋은 설계가 아닙니다. 인증 정책이 변경될 때도 수정되어야 하고, 이메일 발송 방식이 바뀌어도 수정되어야 하기 때문입니다. 서로 다른 변화가 하나의 클래스에 영향을 미치게 됩니다. 이 경우 인증을 담당하는 클래스와 알림을 담당하는 클래스를 분리하는 것이 바람직합니다. 각 클래스는 자신의 책임에만 집중하고, 서로 다른 변경 요인이 서로에게 영향을 주지 않도록 해야 합니다.

단일 책임 원칙은 코드의 길이를 줄이기 위한 규칙이 아니라, 변화의 방향을 분리하기 위한 설계 원칙입니다. 책임이 명확해질수록 변경의 영향 범위는 작아지고, 시스템은 더 안정적으로 유지될 수 있습니다.

이 레이어들은 동심원을 형성하며, 코어는 시스템의 가장 근본적이고 변하지 않는 부분을 포함하고 있으며, 외부 레이어는 사용자 인터페이스와 데이터베이스와 같은 기술별 세부 사항을 처리합니다.

각 레이어를 더 자세히 살펴보겠습니다.

계층 구조 (Layered Structure)

1. Entities (핵심 비즈니스 규칙)

한국에서는 “도메인”이라는 용어가 더 익숙하게 사용됩니다. 실제로 많은 프로젝트에서 엔티티 계층을 도메인 계층이라고 부르기도 합니다.

다만 엄밀히 구분하자면, 클린 아키텍처에서 말하는 Entities는 단순한 도메인 모델을 넘어서는 개념입니다. 도메인은 문제 영역 전체를 의미하는 포괄적인 개념인 반면, 엔티티는 그 안에서 변하지 않는 핵심 비즈니스 규칙을 직접적으로 담고 있는 객체를 가리킵니다.

즉, 도메인이 “문제 영역 전체”라면, 엔티티는 그 영역 안에서 가장 본질적인 규칙을 표현하는 중심 모델에 가깝습니다.

그래서 용어는 익숙한 “도메인”을 사용할 수 있지만, 클린 아키텍처의 맥락에서는 “엔티티”라는 표현이 조금 더 정확하다고 볼 수 있습니다.

예를 들어 다음과 같은 코드가 있다고 가정해보겠습니다.

@Getter
@Entity
@Table(name = "boards")
public class Post extends BaseEntity {
...
public void reWrite(String title, String content) {
    ...
  }

  public void checkAuthor(String author) {
    ...
  }
}

이 코드는 게시판 엔티티를 표현하고 있습니다.
재작성(reWrite)과 작성자 확인(checkAuthor)이라는 행위를 포함하고 있는 점은 긍정적으로 볼 수 있습니다. 데이터만 담고 있는 단순한 객체가 아니라, 게시글이라는 개념이 가져야 할 행위를 함께 표현하고 있기 때문입니다. 그러나 한 가지 생각해볼 부분이 있습니다.
이 클래스는 @Entity, @Table과 같은 JPA 어노테이션에 의존하고 있습니다. 즉, 이 객체는 이미 특정 ORM 프레임워크에 결합되어 있습니다. 클린 아키텍처 관점에서 보면, 핵심 엔티티는 프레임워크와 무관해야 합니다. (하지만 편의상 넣는 경우도 있습니다.)

데이터베이스가 JPA인지, MyBatis인지, 심지어 NoSQL인지조차 알 필요가 없습니다.
이처럼 기술적 어노테이션이 직접 붙어 있는 순간,
이 객체는 "순수한 엔티티"라기보다는 "영속성 모델에 가까운 객체"가 됩니다.
결국 질문은 이것입니다. 이 객체는 비즈니스 규칙을 표현하는 중심 모델인가? 아니면 데이터 베이스 매핑을 위한 모델인가?
클린 아키텍처에서 말하는 엔티티는 전자에 더 가깝습니다. 기술이 아닌, 비즈니스 자체를 표현하는 모델이어야 하기 때문입니다.

정확히 클린아키텍처에서 말하는 코드는 다음과 같습니다.

public class Post extends BaseEntity {
...
public void reWrite(String title, String content) {
    ...
  }

  public void checkAuthor(String author) {
    ...
  }
}

2. Use Cases (애플리케이션 비즈니스 규칙)

많은 경우, 클린 아키텍처에서 말하는 Use Case는 우리가 흔히 사용하는 Service와 매우 비슷하게 느껴집니다.
저 역시 처음에는 "Use Case 계층이 내 코드에는 없는 것 같은데?"라는 생각이 들었습니다. 하지만 다시 구조를 들여다보면, 이미 Service가 Use Case의 역할을 수행하고 있는 경우가 많습니다.

스프링 기반의 전형적인 구조에서는 보통 Controller → Service → Repository 형태로 계층이 구성됩니다. 이때 우리는 비즈니스 로직을 Service에 작성해왔습니다. 클린 아키텍처 관점에서도 핵심은 동일합니다. 다만 용어가 조금 다를 뿐입니다.
Controller는 Interface Adapter에 가깝고,
Repository는 Gateway의 역할을 하며,
우리가 Service라고 부르던 영역이 사실상 Use Case 계층에 해당합니다.

즉, Use Case는 "반드시 새로운 레이어를 추가해야 한다"는 의미가 아니라, 애플리케이션의 특정 기능 흐름을 책임지는 계층을 어떻게 바라볼 것인가에 대한 관점에 가깝습니다. 결국 중요한 것은 이름이 Service냐 Use Case냐가 아니라, 그 코드가 하나의 사용자 행동(기능)을 명확히 표현하고 있는지, 그리고 기술적 세부사항으로부터 얼마나 독립적으로 유지되는지입니다.

정리하자면, 제 사례에서 Use Case 계층이 없어 보였던 이유는 이미 Service가 그 역할을 하고 있었기 때문입니다. 다만 클린 아키텍처에서는 이를 더 명확히 "행위 단위"로 분리하고, 비즈니스 규칙을 보호하는 구조로 강화하는 것을 권장합니다.

3. Interface Adapters

Interface Adapters는 핵심 로직(Entities, Use Cases)과 외부 시스템을 연결하는 계층입니다. 하지만 단순히 연결하는 통로라기보다는, 서로 다른 계층의 형식을 변환하고 조정하는 역할을 담당합니다.

외부 세계는 보통 HTTP 요청, JSON, 메시지, DB 레코드와 같은 형태로 데이터를 주고받습니다. 반면, 내부의 유스케이스와 엔티티는 순수한 객체와 비즈니스 규칙 중심으로 동작합니다. Interface Adapter는 이 둘 사이에서 데이터를 변환하여 핵심 로직이 외부 기술에 오염되지 않도록 보호합니다.

예를 들면 다음과 같은 구성 요소들이 해당됩니다.

UI ↔ Controller
API ↔ Controller
Producer ↔ Consumer
Repository 구현체 ↔ Database

Controller는 HTTP 요청을 받아 유스케이스가 이해할 수 있는 형태로 전달합니다.
Consumer는 메시지를 받아 내부 로직이 처리할 수 있는 구조로 변환합니다.
Repository 구현체는 데이터베이스와 통신하지만, 유스케이스에는 인터페이스만 노출합니다.

즉, Interface Adapter는 외부와 연동할 수 있는 경로이면서 동시에,
핵심 비즈니스 로직을 기술적인 세부사항으로부터 보호하는 방패 역할을 합니다.
핵심은 이것입니다. 내부는 외부를 몰라도 된다. 대신 외부가 내부를 이해할 수 있도록 번역해주는 계층이 필요하다.
그 역할을 수행하는 곳이 바로 Interface Adapters입니다.

4. Frameworks & Drivers (가장 바깥)

Frameworks & Drivers는 시스템의 기술적 세부사항을 담고 있는 가장 바깥 계층입니다.
이 계층에는 프레임워크, 데이터베이스, 외부 API, 메시징 시스템 등과 같은 구현 기술이 포함됩니다.

가장 중요한 특징은 변경 가능성이 가장 높은 영역이라는 점입니다.
라이브러리는 버전이 바뀌고, 데이터베이스는 교체되며, 외부 API는 변경됩니다. 이 계층은 언제든지 바뀔 수 있는 기술 요소를 모아두는 영역입니다.

이 계층의 역할은 애플리케이션이 동작하기 위한 인프라를 제공하는 것입니다.
하지만 여기에는 핵심 비즈니스 로직이 포함되어서는 안 됩니다. 오직 외부 시스템과 상호작용하기 위한 구현 세부사항만 존재해야 합니다.

infra 아래에 다음과 같은 폴더가 있습니다:

이 구성은 전형적인 Frameworks & Drivers 계층입니다.

여기에는

데이터 접근 기술 (jpa, pg, redis)
외부 통신 (gRpc, restTemplate)
인증 기술 (jwt)
인프라 유틸리티 (threadpool, retry, lock, logging)
직렬화 (jackson)

같은 것들이 모여 있습니다. 이건 정확히 클린 아키텍처가 말하는 "가장 바깥"입니다.

결론

AI시대에서 클린아키텍처를 이해를 해야할까 고민이 많았습니다.

AI가 주니어 개발자를 쓸모없게 만들고 있다 | GeekNews

AI 도구가 주니어 개발자에게 얕은 역량만 만들어주고 있으며, 코드를 빠르게 출력하지만 왜 그런 접근을 택했는지 설명하지 못하는 상황이 빈번해짐시니어 개발자의 진정한 가치는 코드 작성

news.hada.io

이 글을 읽고 생각이 완전히 바뀌었다는건 아니지만, 뭐랄까 AI가 완전히 개발 시장을 장악하기전까지는 최선을 다해 그들위에 서야 한다고 된다고 느꼈던거 같습니다. 이 글도 AI를 통해 적고 읽고를 반복했습니다. 적다보니 이해가 되더라구요. AI가 쓴글을 바로 복사해서 사용하는것이 아닌 읽고 옮기다보니 새로운 글이 되어지는 느낌이 듭니다.
클린 아키텍처를 보면 대부분 제가 아는것들이었습니다. 다만 용어가 조금 다른경우도 더러있었습니다. 일단 최선을 다할 생각입니다.
하고 싶은게 있는데 그걸 하는게 제일 행복이 아닐까 생각합니다.

출처: https://blog.bytebytego.com/p/clean-architecture-101-building-software

minikube 간단하게 사용해보기

klom — Mon, 2 Mar 2026 23:55:23 +0900

무중단 배포를 적용해보자.

502 게이트웨이를 없애보자. (이론편)배포를 진행하게 되면 일정 시간 동안 딜레이가 발생합니다.현재 화면은 배포 전 상태이며, localhost인 이유는 로컬 환경에서 배포를 진행했기 때문입니다.문

b-programmer.tistory.com

이 글에서 저는 무중단 배포를 실습해 봤습니다. 로드벨런서(nginx)를 이용해서 rolling배포를 진행해 봤습니다. 그리고 쿠버네티스를 이용하면, rolling배포를 조금 더 편하게(?) 사용할 수 있다고 합니다. 그래서 쿠버네티스를 직접 사용해 보면 어떨까 싶었습니다. 하지만 요게 운영환경에서 사용이 되어서 로컬에서 사용하기에는 어렵다고 알고 있습니다. 그래서 찾다 보니 로컬에서는 minikube를 사용하면 쿠버네티스로 개발이 가능하다는군요. 이걸 통해서 실습을 진행해 볼 예정입니다.

minikube 실행

minikube를 실행시켜 보겠습니다.

minikube start --driver=docker

뜻은 minikube를 docker 드라이버로 실행하겠다는 뜻입니다.

이렇게 되면 로컬에서도 쿠버네티스를 사용할 수 있게 됩니다.

애플리케이션 배포

kubectl create deployment hello-node \
--image=registry.k8s.io/e2e-test-images/agnhost:2.53 \
-n test

테스트를 위해 hello-node라는 것을 배포한다고 하지만, 쿠버네티스에서 이것이 무엇을 의미하는지 알 필요가 있다고 생각합니다.
우리가 일반적으로 말하는 배포는 다음과 같습니다. 서버에 접속해서 jar 파일을 올리고, 프로세스를 실행합니다. 애플리케이션이 죽으면 직접 다시 실행하고, 버전이 바뀌면 기존 파일을 덮어씌워 재실행합니다. 즉, 우리가 말하던 배포는 "애플리케이션을 실행시키는 행위"에 가까웠습니다. 하지만 쿠버네티스에서 말하는 앱 배포는 조금 다릅니다.

이해를 위해 그림을 그려보았습니다.

그림에서 보면, 앱 배포가 쿠버네티스를 거쳐 여러 개의 파드로 이어지고, 그 파드들이 운영 서버 위에서 실행되는 구조처럼 표현되어 있습니다. 겉으로 보기에는 "파드를 만들고 그것을 운영 서버에 적절하게 배치하는 과정"처럼 보일 수 있습니다.
하지만 이것은 결과일 뿐입니다. 쿠버네티스에서 배포란 단순히 파드를 생성하는 행위가 아니라, 해당 애플리케이션이 어떤 상태로 존재해야 하는지를 선언하는 행위입니다.
예를 들어, hello-node는 항상 1개의 파드로 실행되어야 한다고 선언하면 쿠버네티스는 이를 클러스터의 목표 상태로 기록합니다.

목표 상태가 어떤지 현재 상태가 무엇인지 확인해보겠습니다.

목표 상태

spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: agnhost
        image: registry.k8s.io/e2e-test-images/agnhost:2.53

replicas: 1 → "파드 1개를 유지해줘"라는 선언
image: ... → "어떤 앱(이미지)으로 띄울지" 선언

현재 상태

status:
  replicas: 1
  readyReplicas: 1
  availableReplicas: 1

readyReplicas: 1 → 실제로 준비 완료된 파드가 1개
즉, 목표(spec)와 현재(status)가 일치하고 있다는 증거

그 이후에는 시스템이 현재 상태와 비교합니다. 파드가 없으면 새로 생성하고 개수가 부족하면 추가로 만들며 필요하다면 적절한 노드에 다시 배치합니다.
따라서 쿠버네티스에서의 배포는 직접 애플리케이션을 실행하는 행위라기보다, 애플리케이션의 운영 상태를 시스템에 위임하는 과정이라고 볼 수 있습니다. 혹자는 쿠버네티스의 배포를 "상태를 변경한다"라고 표현합니다. 이는 단순 실행이 아니라, 클러스터가 유지해야 할 목표 상태를 정의하는 행위이기 때문입니다.

그렇다면, 현재 상태를 목표 상태로 변경하는 작업이 필요할 것이라는 생각이 들 수 있습니다.
하지만 쿠버네티스는 현재 상태를 기준으로 동작하지 않습니다. 항상 "내가 선언한 목표 상태"를 기준으로 삼고, 현재 상태를 그에 맞추는 방식으로 동작합니다. 그렇다면 목표 상태는 어떻게 설정할 수 있을까요?
방법은 여러 가지가 있지만, 가장 단순하게 생각하면 “다시 선언하면 된다”는 말로 정리할 수 있습니다.

대시보드를 확인하면 다음과 같이 확인할 수 있습니다.

현재 hello-node 이미지는 기본적으로 정식 HTTP 서버로 동작하지 않습니다.
따라서 HTTP 요청을 확인하기 위해 실행 옵션을 추가해주어야 합니다.

아래 명령은 디플로이먼트에 실행 인자를 추가하여, 컨테이너가 HTTP 테스트 서버 모드로 동작하도록 설정하는 과정입니다.

kubectl patch deployment hello-node --type='json' -p='[
  {"op":"add","path":"/spec/template/spec/containers/0/args","value":["netexec","--http-port=8080"]}
]'

deployment.apps/hello-node patched

변경했습니다. 이제 hello-node는 port가 8080입니다. 그러니까 http라는거죠

뭐지 왜 레플리케이션이 왜 두 개지?

kubectl patch 명령을 실행한 이후, ReplicaSet이 두 개로 보이는 현상이 발생했습니다.
그 이유는 Deployment의 파드 템플릿(spec.template) 이 변경되었기 때문입니다.

쿠버네티스는 Deployment의 스펙이 달라지면 "새로운 버전이 배포되어야 한다"고 판단합니다.
즉, 단순히 값을 수정하는 것이 아니라 새로운 버전으로 다시 배포하는 과정이 시작됩니다.

내부적으로 일어나는 일

스펙이 변경되면 쿠버네티스는 다음과 같은 과정을 수행합니다.

새로운 ReplicaSet을 생성한다.
새 Pod를 생성한다.
기존 Pod를 점진적으로 종료한다.
최종적으로 목표 개수만 유지한다.

이 과정을 롤링 업데이트(Rolling Update) 라고 합니다.

서비스의 등장

현재 디플로이먼트를 만들었고 파드가 정상적으로 떠있는것을 확인했습니다. 잠시 위의 그림을 소환해보겠습니다.

그림을 보면 마치 Pod가 곧바로 운영 서버에 배포되어 바로 외부 요청을 처리하는 것처럼 보일 수 있습니다.
하지만 실제로는 그렇지 않습니다. 파드는 단지 "실행 단위"일 뿐이며, 외부에서 직접 접근하기 위한 고정된 접점이 아닙니다.
파드는 언제든지 재 생성될 수 있고, IP 또한 변경될 수 있습니다.

따라서 Pod가 떠 있다고 해서 곧바로 외부 요청을 안정적으로 받을 수 있는 상태는 아닙니다.

여기서 등장하는 개념이 바로 서비스입니다. 서비스는 파드 앞에 위치하는 고정된 접속 지점으로, 외부 요청을 받아 내부의 파드로 전달하는 역할을 합니다. 즉, 디플로이먼트는 애플리케이션을 실행시키는 역할을 하고, 서비스는 실행된 애플리케이션에 접근할 수 있도록 연결해주는 역할을 합니다. 따라서 서비스를 생성하는 이유는 단순히 리소스를 하나 더 만드는 것이 아니라,
실제로 애플리케이션에 접근할 수 있는 통로를 마련하는 과정이라고 볼 수 있습니다.
결국 서비스는 외부 요청이 파드까지 도달할 수 있도록 연결해주는 통로라고 이해하면 됩니다. 파드는 언제든지 재생성될 수 있고, IP 또한 변경될 수 있기 때문에 안정적인 접점이 아닙니다. 따라서 이러한 변화를 중앙에서 흡수하고, 항상 동일한 방식으로 접근할 수 있도록 해주는 역할이 필요하며, 그 역할을 서비스가 담당합니다.

한번 실행해보겠습니다.

kubectl expose deployment hello-node --type=LoadBalancer --port=8080

정상적으로 올라갔다는것이 보여집니다.

그렇다면, Type은 무엇이며, ClusterIP, 내부 엔드 포인트는 무엇을 말하는 걸까요? 그리고 외부 엔드 포인트는 아무것도 없을까요?

Type

Type은 서비스의 접근 방식을 의미합니다. 대표적으로 ClusterIP, NodePort, LoadBalancer가 존재합니다.

ClusterIP 외부에 노출할 필요가 없는 내부 서비스 용도로 사용됩니다.
NodePort 간단한 외부 접근 테스트 용도로 사용됩니다.
LoadBalancer 운영 환경에서 외부에 공개해야 하는 서비스에 사용됩니다.

Minikube는 클라우드 환경이 아니기 때문에, 실제 외부 LoadBalancer는 존재하지 않습니다.
따라서 서비스의 Type을 LoadBalancer로 설정하더라도 EXTERNAL-IP는 <pending> 상태로 표시됩니다.
이는 오류가 아니라, 외부 LoadBalancer를 생성할 수 없는 로컬 환경의 특성 때문입니다.

ClusterIP

서비스가 가지는 고정된 내부 IP입니다. 그림으로 그려보면 대략적으로 다음과 같은 그림 같습니다.

그러니까 현재 실행 중인 파드로 트래픽을 전달하는 역할을 합니다.

Endpoints

서비스가 실제로 연결하고 있는 파드 목록입니다.
하지만 여기서 조금 이상하게 느껴질 수 있습니다. 저는 분명 파드를 하나만 실행했고, 실행 포트도 8080으로 변경했습니다.

현재 실행 중인 파드도 하나뿐입니다. 그렇다면 서비스 쪽에서는 이전 파드의 기록을 제거하지 않고 남겨두는 것처럼 보일 수 있습니다.
하지만 실제로는 그렇지 않습니다. 서비스는 파드를 기록하는 것이 아니라, 현재 라벨 조건에 맞는 파드를 실시간으로 조회하여 연결 대상을 구성합니다. 즉, Endpoints에 표시되는 값은 과거의 기록이 아니라, 지금 이 순간 실제로 연결 가능한 파드의 정보(IP:Port) 입니다.
파드가 재생성되거나 IP가 변경되면 Endpoints 또한 자동으로 갱신됩니다.
따라서 Endpoints는 누적되는 기록이 아니라, 현재 상태를 반영한 연결 대상 목록이라고 이해하면 됩니다.

외부 Endpoints가 존재하지 않는 이유

minikube 환경에서는 진짜 클라우드 LoadBalancer가 존재하지 않기 때문에 EXTERNAL-IP가 비어있거나 <pending>으로 나옵니다.
그렇다면, 외부로 접근하려면 어떻게 해야 할까요?

여러가지 방법이 있겠지만 여기에서는 포트포워딩 방법을 소개하려고 합니다.

포트 포워딩이란?

포트 포워딩은 쿠버네티스 내부에서 실행 중인 애플리케이션을 로컬 환경에서 직접 접근할 수 있도록 임시로 연결해주는 기능
애플리케이션이 로컬로 이동하는 것이 아니라, 로컬과 클러스터 사이에 통로를 만들어주는 방식

다음과 같은 명령어로 사용이 되어집니다.

kubectl port-forward service/hello-node 18080:8080

그러면 다음과 같이 동작이 되었다는 것을 알 수 있습니다.

이제 이렇게 만든 앱을 로컬에서도 사용할 수 있습니다.

저는 분명 18080을 배포한적이 없지만 쿠버네티스에서 포트포워딩한 결과로 사용할 수 있었습니다.

결론

간단하게 minikube를 사용해봤습니다. 쿠버네티스는 어떻게 앱을 배포하고 그것을 어떻게 로컬에서 사용하는거까지 사용해본느낌입니다.
이제 본견적으로 디플로이먼트, 파드, 레플리케이션등 기본적인 개념도 알아보고, 제가 직접 개발하고 있는 앱도 올려보는 시간도 가져보겠습니다. 회사에서 일했을때 alroCD를 이용했던적이 있었는데 그것은 쿠버네티스를 사용해야지 이용할 수 있다고 합니다. 이것도 추후에 다뤄보겠습니다.

완벽한 일관성은 존재하지 않는다.

klom — Fri, 27 Feb 2026 23:20:31 +0900

DB만 사용할 때는 들어오는 데이터와 나가는 데이터가 크게 다르지 않습니다. 하나의 서버가 하나의 상태를 관리하고 있기 때문입니다.
모든 요청은 동일한 저장소를 바라보고, 하나의 진실(Source of Truth)이 존재합니다. 하지만 서비스의 규모가 커지는 순간 상황은 달라집니다. 트래픽을 감당하기 위해 서버를 늘리고, 응답 속도를 개선하기 위해 Redis를 도입하고, 비동기 처리를 위해 Kafka를 붙입니다.
그리고 그 순간부터 우리는 불편한 사실과 마주하게 됩니다. 어떤 곳에는 최신 데이터가 있고, 어떤 곳에는 아직 반영되지 않은 값이 있습니다. 어떤 요청은 성공했는데, 다른 곳에서는 여전히 이전 상태를 반환합니다. 데이터의 불일치는 사라지지 않았습니다. 오히려 더 자주, 더 복잡한 형태로 나타납니다. 그렇다면 우리는 Redis나 Kafka를 잘못 사용하고 있는 걸까요?

Eventual Consistency: The Key Trade-Off Behind Modern Databases

In this article, we will look at what eventual consistency is, why it exists, how to control it, and how to handle the challenges it creates.

blog.bytebytego.com

Eventual Consistency에 대한 글에서는 그렇지 않다고 말합니다. 문제는 기술의 사용법이 아니라, 분산이라는 선택 그 자체에 있다고 이야기합니다.

그 전에 데이터 일관성이란 무엇일까요?

인터넷에 데이터 일관성을 검색해보니 다음과 같은 답변이 나왔습니다.

데이터 일관성은 모든 사본 또는 인스턴스가 모든 시스템 및 데이터베이스에서 동일한 데이터 상태를 나타냅니다. 일관성은 다양한 데이터베이스 시스템, 애플리케이션 및 플랫폼에서 데이터가 정확하고 최신이며 일관성이 있는지 확인하는 데 도움이 됩니다. google search
그렇다는건 데이터가 들어올때와 저장이 되어질때의 데이터가 일치를 해야 한다는 뜻이라는것을 알 수 있습니다.

우리는 무엇을 얻고, 무엇을 포기했는가

우리는 Redis를 사용하면서 속도를 얻었습니다. 하지만 동시에 안전성을 일부 포기했습니다.
Redis는 매우 빠른 시스템입니다. 메모리 기반이며, 조회 성능은 뛰어납니다.
그러나 Redis는 애초에 데이터의 절대적인 정확성을 보장하기 위해 설계된 시스템은 아닙니다.
강한 정합성과 영속성을 최우선으로 하는 전통적인 데이터베이스와는 목적이 다릅니다.
그럼에도 불구하고 우리는 Redis에게 속도도 요구하고, 데이터 유실도 없어야 하며, 항상 최신 상태이기를 기대합니다.
문제는 기술이 아니라 우리의 기대일지도 모릅니다.

모든것은 의도가 있어야 한다.

기술은 특정 문제를 해결하기 위해 등장합니다. 그 기술이 가진 한계를 억지로 덮기 위해
본래 목적과 다른 방식으로 일관성을 강요할 필요는 없다고 생각합니다.
Redis는 속도를 위해 존재합니다. Kafka는 비동기 처리를 위해 설계되었습니다.
각 기술은 명확한 목적과 전제가 있습니다.
그 한계를 인정하지 않은 채 모든 계층에서 완벽한 정합성을 맞추려는 시도는
오히려 설계를 복잡하게 만들 뿐입니다.
중요한 것은 한계를 부정하는 것이 아니라, 그 한계를 이해하고 어떻게 다룰 것인지 고민하는 일입니다.
그리고 그 고민이 구조로 표현되어야 합니다. 재현 가능하고 설명 가능한 형태로 정리되어야 합니다.
우리는 그것을 패턴이라고 부릅니다.
패턴은 한계를 부정한 결과가 아니라, 한계를 인정한 설계의 결과입니다.

결론

중요한 것은 기술을 어떻게 이해하고 표현하느냐라고 생각합니다. 그리고 그 기술이 가진 한계점을 정확히 인지하는 것이 무엇보다 중요합니다. 기술의 한계를 억지로 덮어 문제를 해결하려 하기보다는, 그 한계를 인정하고 설계에 반영하는 태도가 필요합니다. 어떤 기술은 속도를 위해 존재하고, 어떤 기술은 정합성을 위해 존재합니다. 모든 기술이 모든 문제를 해결해주지는 않습니다. 기술이 가진 전제와 한계를 이해한 상태에서 적절한 위치에 배치한다면, 그 기술은 훨씬 효과적으로 사용될 수 있다고 생각합니다. 완벽함을 강요하는 대신, 의도를 분명히 하고 한계를 설계로 다루는 것. 그것이 분산 환경에서 우리가 가져야 할 태도라고 생각합니다.

무중단 배포를 적용해보자.

klom — Thu, 26 Feb 2026 23:43:35 +0900

502 게이트웨이를 없애보자. (이론편)

배포를 진행하게 되면 일정 시간 동안 딜레이가 발생합니다.현재 화면은 배포 전 상태이며, localhost인 이유는 로컬 환경에서 배포를 진행했기 때문입니다.문제는 배포가 완료되는 과정에서 잠시

b-programmer.tistory.com

무중단 배포에는 대표적으로 세 가지 방법이 있습니다. Rolling, Blue-Green, Canary 방식입니다. Rolling 배포는 인스턴스를 하나씩 교체하는 방식으로, 서비스 중단 없이 배포가 가능하다는 장점이 있습니다. 하지만 배포 과정에서 구버전과 신버전이 동시에 존재할 수 있어 버전 불일치 문제가 발생할 수 있습니다. 이러한 문제를 보완하기 위해 등장한 방식이 Blue-Green 배포입니다. 기존 환경과 새로운 환경을 동시에 준비한 뒤, 트래픽을 한 번에 전환하는 방식입니다. 하지만 이 방법 역시 새로운 환경에 치명적인 버그가 존재할 경우 전체 사용자에게 동시에 영향을 줄 수 있다는 위험이 존재합니다. 이를 해결하기 위해 일부 사용자에게 먼저 배포하여 안정성을 검증하는 Canary 배포가 등장했습니다.

이번 파트에서는 이 세 가지 전략 중 Rolling과 Blue-Green 배포를 직접 실습해 보며, 우리 환경에 어떻게 적용할 수 있을지 고민해 보겠습니다.

rolling 배포

Rolling 배포는 인스턴스를 하나씩 교체하며 점진적으로 업데이트하는 방식입니다.
쿠버네티스에서는 RollingUpdate가 기본 전략으로 제공되기 때문에, 비교적 쉽게 롤링 배포를 적용할 수 있습니다.
하지만 저는 현재 쿠버네티스를 사용하고 있지 않습니다. 그렇다면 롤링 배포를 적용할 방법이 없을까요?
결론부터 말하면, 가능합니다. 쿠버네티스가 자동으로 처리해 주는 인스턴스 교체 과정을,
우리가 직접 도커 기반으로 구성하고 트래픽을 제어하면 됩니다.
Rolling 배포를 위해서는 최소 두 개 이상의 인스턴스가 필요합니다.
배포 중에도 항상 하나 이상의 인스턴스가 요청을 처리해야 하기 때문입니다.
따라서 이번 실습에서는 Docker(Compose)를 이용해 동일한 애플리케이션 인스턴스를 두 개 띄우는 것부터 시작해 보겠습니다.

기존 Docker compose를 확인해 봅시다.

services:
  dragons-api:
    build:
      context: .
      dockerfile: Dockerfile
    image: dragons:${PROFILE:-dev}
    container_name: dragons
    restart: unless-stopped

    ports:
      - "8083:8083"

    env_file:
      - .env

인스턴스가 2개 이상 필요하기 때문에 단순히 docker compose down 후 up 하는 방식으로는,
배포 순간에 애플리케이션이 내려가면서 502가 발생할 수 있습니다.

따라서 먼저 동일한 애플리케이션을 두 개의 인스턴스로 실행할 수 있도록 구성해야 합니다.
가장 단순한 방법은 기존 dragons-api를 복제하여 dragons-api-1, dragons-api-2처럼 두 개의 서비스로 나누는 것입니다.

예를 들어 다음과 같이 컨테이너 이름과 포트만 분리해 두 인스턴스를 동시에 띄울 수 있습니다.

services:
  dragons-api1:
    build:
      context: .
      dockerfile: Dockerfile
    image: dragons:${PROFILE:-dev}
    container_name: dragons1
    restart: unless-stopped
    ports:
      - "8083:8083"
    env_file:
      - .env

  dragons-api2:
    build:
      context: .
      dockerfile: Dockerfile
    image: dragons:${PROFILE:-dev}
    container_name: dragons2
    restart: unless-stopped
    ports:
      - "8084:8083"
    env_file:
      - .env

이제 인스턴스가 2개가 되었습니다. 이렇게 해서 띄운다고 해서 rolling배포가 되는 것은 아닙니다.
그전에 정상적으로 인스턴스가 띄워졌는지 확인해 봅시다.

다행히 올라와있는 것을 확인할 수 있었습니다.
지금 단계에서는 단순히 인스턴스를 2개 띄운 것뿐입니다. 그렇다면 여기서 어떻게 Rolling 배포가 가능해질까요?
Rolling 배포를 하려면, 사용자 요청이 특정 인스턴스 하나에만 고정되지 않고 여러 인스턴스로 분산될 수 있어야 합니다.
즉, 앞단에서 트래픽을 분산해 주는 로드밸런싱이 필요합니다.
하지만 저는 별도의 로드밸런서를 사용하고 있지 않습니다. 대신 리버스 프락시 서버(Nginx)를 사용하고 있습니다.
리버스 프락시는 서버 앞단에서 요청을 받아, 내부 애플리케이션 서버로 전달하는 역할을 합니다.
그리고 설정에 따라 여러 인스턴스로 트래픽을 분산시킬 수 있기 때문에,
결과적으로 로드밸런서 역할도 함께 수행할 수 있습니다.
즉, 이번 실습에서는 별도의 로드밸런서 대신 Nginx를 이용해 트래픽을 분산시켜 Rolling 배포를 구현해 보겠습니다.

이를 해결하기 위해 nginx의 upstream기능을 사용할 수 있습니다.

nginx upstream

간단히 말해서 upstream은 여러 서버(인스턴스)를 하나의 서비스 풀로 묶는 설정입니다.
그렇다면 어떻게 적용할 수 있을까요? Nginx 설정 파일을 다음과 같이 변경하였습니다.

http {
    upstream dragons {
        server dragons1:8083;
        server dragons2:8083;
    }

    # -------------------------
    # HTTPS
    # -------------------------
    server {
        ...
       # }

        # -------------------------
        # API (backend)
        # -------------------------
        location /api {
           proxy_next_upstream error timeout http_502 http_503 http_504;  
           proxy_pass http://dragons;
        ...
        }

여기서 proxy_pass의 대상이 기존에는 특정 컨테이너(서버)를 직접 가리키는 방식이었다면,
이제는 upstream 그룹 이름(dragons)을 바라보도록 변경되었습니다.
즉, nginx가 dragons라는 서비스 풀에 포함된 인스턴스들로 요청을 분산하게 됩니다.
또한 proxy_next_upstream 설정을 통해 특정 인스턴스가 일시적으로 응답하지 못하는 경우,
다른 인스턴스로 요청을 재시도하여 502 발생 가능성을 줄일 수 있습니다.
이렇게 되면 Rolling 배포를 진행하기 위한 준비 과정은 완료되었습니다.
이제 본격적으로 배포 테스트를 진행해 봅시다.

while true; do
curl -k -s -o /dev/null -w "%{http_code}\n" https://localhost/api
sleep 0.3

위 코드를 통해 /api 요청을 지속적으로 보내보겠습니다.
요청 결과로 401이 출력되었습니다. 이는 서버가 죽었다는 의미가 아니라, 인증이 필요한 API에 로그인 없이 접근했기 때문에 발생한 것으로 추측됩니다.

그렇다면 여기서 dragons1 인스턴스를 종료하면 어떻게 될까요? 502가 발생할까요, 아니면 여전히 401이 발생할까요?

결과적으로 401이 계속 발생했습니다.
즉, 한쪽 인스턴스를 종료하더라도 Nginx가 다른 인스턴스로 요청을 전달하면서 서비스가 유지되고 있음을 확인할 수 있었습니다.

Bule-Green 배포

Rolling 배포가 같은 서비스 풀 안에서 인스턴스를 하나씩 교체하는 방식이라면, Blue-Green 배포는 두 개의 세트를 동시에 실행해 두고,
전환 순간에 하나의 세트만 활성화하는 방식입니다.

즉, 기존 환경(Blue)과 새로운 환경(Green)을 동시에 준비해 두고, 트래픽을 한 번에 전환하는 전략입니다.

그렇다면 여기서 이런 의문이 생길 수 있습니다.
그렇다면 Docker Compose에서 만들어지는 인스턴스와 큰 차이가 없는 것 아닌가?

실제로 물리적인 구성만 놓고 보면 크게 다르지 않습니다. 컨테이너를 두 개 이상 띄운다는 점에서는 Rolling과 유사해 보일 수 있습니다.

하지만 차이는 어디에 트래픽을 보내느냐에 있습니다.

Rolling은 두 인스턴스를 동시에 활성화한 상태에서 하나씩 교체합니다.
Blue-Green은 두 세트를 모두 띄워두되, 항상 한 세트만 활성화합니다.

즉, 구조는 비슷해 보이지만 트래픽 제어 방식과 배포 철학이 다르다는 점이 핵심입니다.

인스턴스는 다음과 같이 진행하였습니다.

services:
  dragons-api1:
    build:
      context: .
      dockerfile: Dockerfile
    image: dragons:${PROFILE:-dev}
    container_name: dragons1
    restart: unless-stopped
    ports:
      - "8083:8083"
    env_file:
      - .env

  dragons-api2:
    build:
      context: .
      dockerfile: Dockerfile
    image: dragons:${PROFILE:-dev}
    container_name: dragons2
    restart: unless-stopped
    ports:
      - "8084:8083"
    env_file:
      - .env

Blue-Green 배포 방식은 트래픽을 전환하는 방식입니다.
즉, 새로운 버전을 배포할 때 기존 서버를 하나씩 교체하는 것이 아니라, 트래픽이 향하는 대상을 바꾸는 것이 핵심입니다.

이를 위해 서비스 풀을 Blue(기존)와 Green(신규) 두 세트로 나누어 준비해야 합니다.
그리고 전환 순간에는 두 세트 중 하나의 풀만 활성화하여 사용자 트래픽을 처리하도록 구성합니다.

저는 nginx_blue.conf와 nginx_green.conf로 구분을 짓겠습니다.

nginx_blue.conf

upstream dragons {
   server dragons1:8083;
}

nginx_green.conf

upstream dragons {
   server dragons2:8083;
}

핵심은
기존 nginx.conf에서

include /etc/nginx/conf.d/active.conf;

입니다.

이 설정은 Nginx가 모든 설정을 한 파일에 고정해 두는 것이 아니라,
active.conf라는 파일을 동적으로 포함(include) 하도록 만들어줍니다.
즉, active.conf가 어떤 파일을 가리키느냐에 따라 Blue 또는 Green으로 트래픽을 전환할 수 있습니다.

(참고로 모든 설정은 모두 같습니다.)

결론

시간 관계상 Blue-Green 배포는 끝까지 테스트를 진행하지 못했습니다. 어쩌면 그 결과는 블로그에 모두 담지 못할 수도 있을 것 같습니다.
하지만 Rolling과 Blue-Green 배포를 직접 구성해보며 한 가지를 분명히 느꼈습니다.
무중단 배포는 막연히 어렵고 복잡한 기술이라고 생각했지만, 핵심 원리를 이해하고 나니 생각보다 단순한 구조라는 점이었습니다.

결국 Rolling이든, Blue-Green이든 본질은 동일합니다.

인스턴스를 준비하고
트래픽을 제어하고
전환을 설계하는 것

이 세 가지를 이해하면, 배포 전략은 더 이상 두려운 개념이 아닙니다.
이번 실습을 통해 무중단 배포는 특정 도구의 기능이 아니라, 설계와 트래픽 제어의 문제라는 것을 깨닫게 되었습니다.

도커 네트워크 이해해보기

klom — Wed, 25 Feb 2026 21:43:40 +0900

도커를 학습하면서 가장 어렵게 느껴졌던 부분이 무엇이냐고 묻는다면, 저는 단연 네트워크라고 말할 것 같습니다.

Dockerfile은 컨테이너가 실행될 환경을 정의하는 파일이고, Docker Compose는 여러 개의 컨테이너를 하나의 서비스처럼 구성해주는 도구입니다. Volume은 컨테이너의 데이터를 영속적으로 저장하기 위해 호스트와 연결되는 저장 공간으로 이해하고 있습니다.

이처럼 각 요소의 역할은 비교적 명확하게 정리할 수 있었지만, 도커 네트워크는 개념을 아는 것과 실제로 이해하는 것 사이에 간극이 있었습니다.

'도커 안에 네트워크를 만든다'는 것은 알고 있었지만,

왜 굳이 네트워크를 분리해야 하는지
언제 기본 bridge를 쓰고, 언제 사용자 정의 네트워크를 써야 하는지
컨테이너들은 어떻게 서로를 찾고 통신하는지

이 부분들은 쉽게 와닿지 않았습니다.

그래서 이번 글에서는 단순히 "네트워크를 만든다"는 수준이 아니라, 도커 네트워크를 실제로 어떻게 사용해야 하는지를 정리해보려 합니다.

컨테이너들은 어떻게 서로를 찾고 통신하는지

컨테이너가 서로 통신하기 위해서는 동일한 Docker 네트워크에 연결되어 있어야 합니다.
각 컨테이너는 기본적으로 격리된 환경에서 실행되기 때문에, 같은 네트워크에 속해 있지 않다면 서로를 찾을 수 없습니다.

Docker는 하나의 네트워크만 사용하는 것이 아니라, 여러 개의 네트워크를 생성하고 관리할 수 있습니다. 이를 통해 서비스 단위로 네트워크를 분리하거나, 특정 컨테이너들만 서로 통신하도록 구성할 수 있습니다.

같은 네트워크에 속한 컨테이너들은 Docker 내부 DNS를 통해 컨테이너 이름을 기반으로 서로를 찾고 통신하게 됩니다.
대략적으로 그리면 다음과 같이 그릴 수 있죠.

Docker는 설치 시 기본 네트워크(bridge, host, none)를 자동으로 생성합니다.
하지만 서비스 간 네트워크를 분리하거나, 이름 기반 통신을 사용하기 위해서는 사용자 정의 네트워크를 직접 생성해야 합니다.

만약에, 네트워크를 설정하지 않는다면, 컨테이너는 서로 정보를 공유 할 수 있을까요?

처음에는 네트워크를 설정하지 않으면 통신할 수 없다고 생각할 수 있습니다. 하지만 실제로는 그렇지 않습니다. Docker는 컨테이너를 실행할 때 별도의 설정이 없더라도 기본 bridge 네트워크에 자동으로 연결합니다. 따라서 완전히 고립되는 것은 아니며, 같은 bridge 네트워크에 속한 컨테이너끼리는 통신이 가능합니다.

다만 여기서 중요한 차이가 있습니다. 우리가 실무에서 말하는 "통신"은 단순히 IP로 접근하는 것이 아니라, 컨테이너 이름을 기반으로 한 통신을 의미하는 경우가 많습니다. 사용자 정의 네트워크에서는 Docker 내부 DNS가 동작하여 컨테이너 이름으로 서로를 찾을 수 있습니다. 반면 기본 bridge 네트워크에서는 이러한 이름 기반 통신이 제한적이거나 불편합니다.

즉, 기본 bridge 네트워크에서도 IP를 통해 통신은 가능하지만, 이름 기반 통신이 자연스럽게 지원되지 않기 때문에 실무에서는 사용자 정의 네트워크를 사용하는 경우가 많습니다.

그렇다면, bridge 네트워크는 어째서 DNS를 제공하지 않을까요?

초기 Docker는 단순히 컨테이너를 실행하고 포트를 매핑하는 데 초점이 맞춰져 있었습니다. 이후 사용자 정의 네트워크와 내부 DNS 기능이 도입되었지만, 기존 환경과의 호환성을 위해 기본 bridge 네트워크의 구조는 그대로 유지되었습니다. 따라서 이름 기반 DNS는 기본 bridge가 아닌, 사용자 정의 네트워크에서 제공됩니다.

결론

도커를 사용하면서 가장 막연하게 느껴졌던 부분은 네트워크였습니다.
컨테이너를 실행하고, 이미지를 빌드하고, Compose로 묶는 것까지는 비교적 명확했지만, 네트워크는 어딘가 추상적으로 느껴졌습니다. 그래서 언젠가는 한 번 정리해봐야겠다고 생각했고, 이번에 차근차근 개념을 짚어보게 되었습니다.

막상 정리해보니 생각보다 복잡하지는 않았습니다.
같은 네트워크에 있어야 통신할 수 있다는 점, 사용자 정의 네트워크에서 이름 기반 DNS가 동작한다는 점, 그리고 Compose가 네트워크를 어떻게 관리하는지까지 이해하고 나니 전체 구조가 비교적 명확해졌습니다.

물론 여기서 더 깊게 들어가면 리눅스 네트워크 네임스페이스, 브리지, iptables 같은 영역까지 확장될 수 있겠지만, 적어도 Docker를 사용하는 개발자 관점에서는 이 정도 이해만으로도 충분히 네트워크를 설계하고 활용할 수 있을 것 같습니다.

내일부터는 무중단 배포 실습을 진행해볼 예정인데, 오늘 정리한 내용이 분명 도움이 될 것이라 기대해봅니다.

502 게이트웨이를 없애보자. (이론편)

klom — Tue, 24 Feb 2026 22:42:25 +0900

배포를 진행하게 되면 일정 시간 동안 딜레이가 발생합니다.

현재 화면은 배포 전 상태이며, localhost인 이유는 로컬 환경에서 배포를 진행했기 때문입니다.

문제는 배포가 완료되는 과정에서 잠시 동안 502 Bad Gateway 오류가 발생한다는 점입니다.
이는 프록시 서버가 백엔드 서버와 원활하게 통신하지 못하고 있음을 의미합니다.
일정 시간이 지나야 정상적으로 서비스가 동작하며, 새로고침을 해야 변경된 화면을 확인할 수 있습니다.

지금 보고 있는 화면은 Swagger이기 때문에 크게 문제가 없어 보일 수 있습니다.
하지만 이 상황을 실제 운영 중인 사용자 UI라고 가정해보겠습니다.

수백, 수천 명이 동시에 서비스를 이용하는 상황에서 배포가 이루어지고, 그 순간마다 502 오류가 발생한다면 어떻게 될까요?
상품을 구매하려던 사용자는 갑자기 튕기고, 웹을 탐색하던 사용자도 오류 화면을 마주하게 됩니다.
이러한 경험이 반복된다면 서비스에 대한 신뢰도는 크게 떨어질 수밖에 없습니다.

이처럼 배포 과정에서 발생하는 일시적인 중단은 사용자 경험을 해칠 수 있습니다.
이를 해결하기 위해 사용하는 방법이 바로 무중단 배포(Zero-Downtime Deployment)입니다.
무중단 배포란, 배포가 진행되는 동안에도 서비스가 끊기지 않도록 하여 사용자가 중단을 인지하지 못하게 만드는 방식입니다.
그렇다면, 어떻게 하면 배포 중에도 서비스가 끊기지 않도록 만들 수 있을까요?

무중단 배포를 하는 이유와 무중단 배포가 무엇인지는 알아봤으니
어떻게 하면 무중단 배포를 적용할 수 있는지 확인해보겠습니다.

무중단 배포는 어떻게 제공할 수 있을까?

무중단 배포의 핵심은 단순합니다.
배포 중에도 트래픽을 받을 수 있는 인스턴스를 항상 최소 1개 이상 유지하는 것입니다.
즉, 새 버전을 올리는 순간에 기존 서버가 내려가면서 생기는 "빈 구간"을 없애야 하고, 이를 위해 보통 서버를 2개 이상 운영하며 트래픽을 스위칭하는 방식을 사용합니다. 대표적으로 Rolling 배포, Blue-Green 배포, Canary 배포가 존재합니다.

Rolling 배포

인스턴스를 하나씩 교체하며 점진적으로 업데이트하는 방식
여기서 인스턴스를 하나씩 교체한다는 말은 다음과 같이 표현할 수 있습니다.

즉, 배포 과정 내내 항상 하나 이상의 인스턴스가 Up 상태를 유지하도록 만드는 것이 롤링 배포의 핵심입니다.
롤링 배포는 여기까지가 전부입니다. 그런데 여기서 두 가지 한계점이 존재합니다.

1. 단일 도메인 뒤에서 이루어지는 트래픽 분산
브라우저에서 URL을 입력하면 항상 같은 도메인으로 접속합니다.
서버 IP가 변경되더라도, 사용자가 접속하는 도메인 자체가 바뀌는 일은 없습니다.
하지만 실제로는 하나의 서버가 아니라, 로드밸런서(Nginx 등)를 통해 여러 인스턴스 중 하나로 요청이 전달됩니다.
즉, 사용자는 하나의 서버에 접속한다고 인식하지만, 실제로는 여러 인스턴스가 하나의 도메인 뒤에서 동작하고 있는 구조입니다.

2. 모든 서버(인스턴스)를 전부 띄워서 유지를 시켜야 할까?
이 질문에 대한 답은 뒤에서 이어서 다루겠습니다.
사실 이런 배포는 쿠버네티스를 활용하면 훨씬 편하게 진행할 수 있습니다.
kubectl rollout 같은 기능으로 배포 과정을 자동화할 수 있고, 쿠버네티스의 기본 배포 전략 자체가 Rolling Update이기 때문입니다.

하지만 현재 환경에서는 쿠버네티스를 사용하고 있지 않습니다. 그렇다면 방법이 없을까요?

결론부터 말하면, 방법은 있습니다.
바로 Nginx를 이용해 트래픽을 제어하고, 그 과정을 Jenkins 파이프라인으로 자동화하는 방식입니다.

즉, 쿠버네티스가 해주던 인스턴스 제외 → 교체 → 헬스체크 → 복귀 과정을
Jenkins + Nginx 스크립트(혹은 설정 전환)로 직접 구현하는 것입니다.

이 배포 방법에는 한 가지 문제가 존재합니다.
롤링 배포는 배포 과정에서 new 버전과 old 버전이 동시에 올라가 있는 구간이 발생할 수 있습니다.

이때 old 버전에서는 문제가 없던 기능이 new 버전에서 버그가 발생하면, 사용자는 서비스를 정상적으로 사용하다가도 갑자기 특정 기능이 막히는 경험을 하게 됩니다.
즉, 사용자 경험을 개선하기 위해 도입한 무중단 배포가 역설적으로 일관성 측면에서 사용자 경험을 떨어뜨릴 수 있는 가능성도 존재합니다.

이제 두 번째 한계점에 대해 말씀드리겠습니다.
무중단 배포를 위해서 반드시 두 개의 인스턴스가 항상 동시에 떠 있어야 하는 것은 아닙니다.
다만, "항상 하나 이상이 살아있게 유지한다"는 특성은 롤링 배포의 구현 방식에서 비롯된 특징으로 이해하시면 좋습니다.

이러한 한계를 보완하기 위해 사용할 수 있는 방식이 바로 Blue-Green 배포입니다.

Blue-Green 배포

Blue-Green 배포는 기존 환경(Blue)과 신규 환경(Green)을 동시에 준비한 뒤,
검증이 완료되면 트래픽을 한 번에 전환하는 방식입니다.

Rolling 배포는 가용성을 유지한다는 점에서 훌륭한 전략입니다.
하지만 배포 과정에서 old 버전과 new 버전이 동시에 존재하는 구간이 발생할 수 있다는 한계가 있습니다.

이러한 한계를 보완하기 위한 방식이 바로 Blue-Green 배포입니다.

이것 또한 간단한 그림으로 표현할 수 있습니다.

여기서 중요한 점은, 버전이 섞이지 않는다는 것입니다. 전환 전에는 Blue만, 전환 후에는 Green만 사용자에게 노출됩니다.

다만 이 방식에도 단점은 존재합니다.
트래픽을 다른 환경으로 전환하는 순간, 요청이 새로운 서버로 연결되는 과정에서 아주 짧은 딜레이가 발생할 수 있습니다.

하지만 전환 시점을 헬스체크와 워밍업을 통해 충분히 검증하고, 트래픽 전환을 안전하게 설계해두면 이러한 지연은 대부분 사용자가 체감하지 못하는 수준으로 충분히 커버할 수 있습니다.

블루 그린 방식은 버전이 섞이지 않는다는 장점이 있습니다.
하지만 전환 순간, 전체 트래픽이 한 번에 새로운 버전(Green)으로 이동하게 됩니다.

만약 그린 환경에 치명적인 버그가 존재한다면, 그 영향은 일부 사용자가 아니라 전체 사용자에게 동시에 전달될 수 있습니다.
즉, 성공하면 매우 안정적이고 깔끔한 배포 전략이지만, 실패할 경우에는 한 번에 큰 장애로 이어질 수 있는 구조입니다.

Canary 배포

일부 트래픽만 신규 버전에 먼저 흘려보내며 문제 여부를 확인한 뒤 점진적으로 확대하는 방식

Rolling 배포는 배포 과정에서 버전 불일치가 발생할 수 있다는 한계가 있고,
Blue-Green 배포는 전환 순간에 문제가 발생할 경우 전체 사용자에게 영향을 줄 수 있다는 위험성을 가지고 있습니다.

이러한 단점을 보완하기 위해 등장한 전략이 바로 Canary 배포입니다.

Canary라는 이름은 과거 광부들이 유독가스를 감지하기 위해 사용했던 작은 노란 새, 카나리에서 유래했습니다.
카나리는 유독가스에 민감하게 반응하기 때문에, 위험을 조기에 감지하는 역할을 했습니다.

배포 전략에서도 이 개념을 동일하게 적용합니다.

새로운 버전을 전체 사용자에게 한 번에 공개하는 것이 아니라,
일부 사용자(예: 5% 또는 특정 그룹)에게 먼저 배포하여 안정성을 검증합니다.

이후 모니터링과 피드백을 통해 문제가 없다고 판단되면, 점진적으로 배포 범위를 확대하여 최종적으로 전체 사용자에게 적용합니다.

마무리

각 배포 전략은 서로 배타적인 선택지라기보다는, 상황에 따라 조합하여 사용할 수 있는 전략의 집합에 가깝다고 생각합니다.
하나의 방법을 선택했다고 해서, 다른 방법을 전혀 사용하지 않는 것은 아닙니다.

예를 들어,

Rolling + Blue-Green을 함께 사용할 수도 있고,
Rolling + Canary 전략을 적용할 수도 있으며,
더 나아가 Rolling + Blue-Green + Canary를 조합하는 것도 가능합니다.

결국 배포 전략은 정답이 있는 문제가 아니라, 서비스의 규모, 리스크 허용 범위, 운영 환경에 따라
적절히 설계해야 하는 아키텍처 선택의 문제라고 생각합니다.

La programmazione è bella

레디스의 자료구조들은 굳이 알아야 할까?

대표적인 자료구조 5종 부터 파악해봅시다.

String

그렇다면, 어째서 Redis는 바이트 단위로 저장할까요?

그렇다면, String으로 저장된 데이터는 어떤식으로 이용할 수 있을까요?

Hash

그렇다면 Hash의 원자성은 String과 무엇이 다를까요?

그렇다면, Hash는 언제 사용할까요?

List

그렇다면, List 자료구조는 어떻게 원자성을 지킬 수 있을까?

그렇다면, List는 어떻게 사용 할까요?

Set

Redis에서 Set은 어떤 특별함이 있을까?

그렇다면 어떻게 활용되어질까?

Sorted Set

Sorted Set이 원자적으로 정렬과 원소 추가를 할 수 는 방법?

그렇다면, Sorted Set은 어떻게 활용할까요?

모든 자료구조의 기본적인 명령어를 표로 알아보자.

추가 (ADD/SET/PUSH)

조회 (GET)

삭제 (DEL / REM)

개수 (LEN / CARD)

존재 확인 (EXISTS)

증가 (INCRBY)

반복 순회 (SCAN)

블로킹 (B 접두사)

예외

마무리

레디스가 싱글 스레드임에도 불구하고 빠른이유

C10K 문제란 무엇일까?

I/O 멀티 플렉싱(I/O Multiplexing)

이벤트 루프

구현

이벤트 기반 서버를 구현하는 대표적인 I/O 처리 패턴

Reactor

결론

경쟁조건을 해결하거나 완화하기 위한 다양한 기술들

경쟁조건이 발생한다는건 어떤 의미일까?

Lua script

그렇다면 왜 이렇게 빠를까요?

그렇다면 Lua Script로 변경하는 것이 항상 좋은 선택일까요?

정렬 집합

정렬 집합은 어떻게 경쟁 조건을 완화할 수 있을까?

결론

Rate Limiter (intro.)

Rate Limiter를 왜 사용해야 할까? 대안은 없을까?

그렇다면, Rate Limiter는 어느 위치에 둬야할까요?

그렇다면, 서버에 Rate Limiter를 두는 이유는 무엇일까요?

그렇다면, 단순히 요청을 count하면 되지 않을까요?

버킷 기반 알고리즘

Token Bucket

Leaky Bucket

윈도우 기반 알고리즘

고정 윈도 카운터

이동 윈도 로깅

이동 윈도 카운터

마무리

로그인은 어떤 방식으로 개발해야 안전할까?

간단하게 세션과 토큰 방식에 대해 이해 해봅시다.

세션 방식

토큰 방식

그럼 어떻게 테스트를 할까?

그렇다면, 실행 환경이 늘어나면 어떻게 될까요?토큰 방식의 장점은 stateless하다는 점입니다. 그렇다면, 이 점을 가장 극대화를 시키려면 어떻게 해야 할까요?

로그인 방식으로 변경해봅시다.

마무리

한국어 형태소 분석 vs BPE

형태소 분석은 왜 해야 하는가?

먼저 글자 단위로 쪼개는 방법에 대해 알아봅시다.

그 다음은 공백 단위로 쪼개는 방법입니다.

이를 해결 하기 위해 형태소 단위로 쪼개게 되었습니다.

그렇다면, 어째서 현대 LLM은 형태소 분석을 하지 않을까요?

그렇다면 BPE는 이러한 문제를 어떻게 해결할 수 있을까요?

BPE의 동작 원리

이제 본견적으로 BPE로 학습을 진행해보겠습니다.

마무리

다량의 엑셀 정보는 어떻게 저장할 수 있을까?

일단, 100만건의 데이터를 엑셀업로드를 진행해봅시다.

프론트에서 데이터를 쪼개보자.

행 단위로 분할 하는 방법

그렇다면, 실행 환경이 늘어나면 어떻게 될까요?
토큰 방식의 장점은 stateless하다는 점입니다. 그렇다면, 이 점을 가장 극대화를 시키려면 어떻게 해야 할까요?