개발 공부 노트

에러없이 선착순 이벤트 진행하기

개발자성장기 — Mon, 23 Mar 2026 17:37:26 +0900

들어가며

드디어 !
우리 팀이 운영하는 서비스가 2026년 2월 10일 기준 회원 수 500명을 돌파했다.

그동안 미뤄왔던 이벤트를 이제는 정말 해볼 수 있겠다는 생각이 들었다.

“유저가 어느 정도 모이고, 보여주고 싶은 기능이 갖춰지면 하자”라고 계속 미뤄왔는데, 드디어 그 시점이 온 것이다.

예전부터 꼭 해보고 싶었던 이벤트가 하나 있었다.

바로 선착순 이벤트였다.

내가 참여자 입장에서 여러 이벤트를 보며 늘 아쉬웠던 점이 있었다.

응모형 이벤트는 당첨 과정이 잘 보이지 않다 보니,

가끔은 “정말 주는 건가?” 싶은 순간이 있었다.

그래서 나중에 내가 서비스를 만들게 된다면,

적어도 이벤트만큼은 결과가 더 분명하게 보이는 방식으로 해보고 싶었다.

팀 회의에서도 비슷한 의견이 나왔고, 팀원들 역시 선착순 이벤트에 찬성했다.

그렇게 시작된 것이 봄봄의 첫 이벤트였다.

예산이 넉넉한 편은 아니었지만, 그래도 총 70개의 메가커피 기프티콘을 상품으로 준비했다.

예상 참여 인원은 대략 1,000명 정도로 잡았다.

문제는 선착순 이벤트가 생각보다 단순하지 않았다는 점이다.
짧은 시간에 요청이 한꺼번에 몰릴 가능성이 높았고, 여기에 새로고침이나 재시도까지 겹치면 순간 트래픽은 예상 참여 인원보다 훨씬 커질 수 있었다.

게다가 봄봄은 웹도 지원하고 있었기 때문에, 여러 개의 탭을 띄워 거의 동시에 시도하는 경우도 고려해야 했다.
실제로 선착순 이벤트를 할 때 탭을 2~3개 열어두고 동시에 시도하는 사람은 꽤 많다.

그래서 최악의 시나리오를 먼저 생각했다.

1,000명 중 80%가 오픈 직후 첫 1~2초 안에 진입한다고 가정하면,
진입 요청만으로도 순간적으로 약 400~800 TPS가 발생한다.

여기에 사용자가 평균 2개의 탭을 띄운다고 가정하면,
순간 트래픽은 약 800~1,600 TPS 수준까지 올라간다.

그리고 실제 운영에서는 재시도, 네트워크 지연, 예상을 벗어난 동시 진입 같은 변수도 충분히 생길 수 있다.
그래서 우리는 어느 정도 여유를 두고, 목표치를 피크 2,000 TPS로 잡았다.

즉 이번 이벤트는 단순한 기능 구현이 아니라,
짧은 순간에 몰리는 대량 요청을 어떻게 안전하게 처리할 것인가까지 함께 풀어야 하는 문제였다.

정리해보면 요구사항은 아래와 같았다.

요구사항

선착순 발급 순서 보장
목표 TPS 2,000
1인당 1개의 쿠폰만 발급 보장
이벤트 종료이후 발급 차단
발급 성공/실패를 명확히 반환

고민사항

순간적인 엄청난 트래픽을 어떻게 감당해낼지?
발급 시점에 DB 경합(락/커넥션 고갈)을 어떻게 해결할지
분산 환경에서 동시성을 어떻게 잡을지

현재 상태

“지금 구조로는 2000TPS는 절대 못 버틴다”

서버를 아키텍처를 아주 간단하게 그리면 아래처럼 분산서버로 되어있다.

문제는 “API 서버가 분산이냐”가 아니라, 순간적으로 수많은 요청이 몰릴 때 시스템이 버티느냐였다.

현재 운영 환경의 피크 TPS는 250 정도 버틸 수 있다.

지금 상태에서 기능만 구현해버리면 서버 스레드/커넥션 풀 대기 증가 → 응답 지연/타임아웃, 이로인한 사용자 경험 붕괴 그리고 최악은… 이벤트 때문에 기존 서비스까지 영향을 받는 것이다.

그래서 어떻게 할지 고민을 많았다.

1차 문제 : 운영서버에 이벤트 로직을?

기존 운영 서버에 이벤트 관련 로직을 넣는게 가장 편하다.

하지만 현재 운영서버에 아무리 설계를 해봐도 운영서버로는 한 번에 수 많은 요청을 처리할 수 없었다.

그렇다고 무작정 스케일 아웃하기에도 비용적 부담도 있었고 혹시라도 예측이 틀려서 기존에 서비스를 사용하는 유저가 이벤트 때문에 이용하지 못하는 경우는 없어야 된다고 생각했다.

1차 해결: 이벤트 서버로 분리

이벤트는 시작 순간에 트래픽이 급격히 몰린다.

따라서 이벤트 트래픽을 운영 서버 API와 분리한 이벤트 서버로 받는 것이 1차적인 안정화 전략이다.

이렇게 해두면 설사 이벤트 서버가 다운되더라도, 기존 서비스 이용은 큰 문제가 없게 된다.

어차피 이벤트 할 때만 서버를 사용하기에 비용적 부담도 적었다.

2차 문제: 제일 먼저 트래픽을 받는 곳은?

이벤트 서버를 분리했다면, 다음 고민은 “이벤트 트래픽의 입구를 어떻게 구성할 것인가” 였다.
선착순 이벤트에서는 애플리케이션 서버 자체도 중요하지만, 그보다 먼저 모든 요청이 처음 도착하는 지점이 과연 수 많은 요청을 받을 수 있는지 확인해야한다.

뒤쪽 이벤트 서버를 여러 대로 늘려 두더라도, 정작 가장 앞단에서 요청을 제대로 받아주지 못하면 그 뒤의 확장성은 아무 의미가 없어지기 때문이다.

여기서 핵심은 트래픽이 얼마나 몰릴지 예측할 수 없는 상황에서 입구를 어떻게 구성할까였다.

그래서 몇 가지 선택지를 두고 비교했다.

방법 1: EC2 인스턴스에 HAProxy를 두고 직접 로드밸런싱하기

가장 먼저 떠오른 선택지는 별도 EC2 인스턴스에 HAProxy 같은 리버스 프록시를 두고,
그 인스턴스가 로드밸런서 역할을 하게 만드는 방식이었다.

이 방식의 장점은 분명하다.

익숙한 도구로 빠르게 구성할 수 있있어서 러닝커브가 전혀없다.
처음에는 작은 비용으로 시작하기 쉽다.
세부 튜닝 포인트를 직접 통제할 수 있다.

즉, “작게 시작해보기” 에는 꽤 매력적인 선택지다.

하지만 선착순 이벤트 관점에서는 단점이 훨씬 크게 보였다.

첫째, 로드밸런서 역할을 하는 인스턴스 자체가 단일 장애 지점 즉, SPOF가 된다.
현재 운영의 로드밸런서를 담당하는 인스턴스는 t4g.nano이다.

물론 해당 스펙을 가지고 그대로 이벤트 서버에도 적용할 수는 없다.

그런다고 스펙을 올린다면 버틸 수는 있을 것 같다.
하지만 그건 어디까지나 더 큰 단일 인스턴스가 되는 것에 가깝다.
트래픽이 예측 범위를 넘는 순간, 병목은 뒤쪽 서버가 아니라 입구 인스턴스 하나에 집중될 수 있다.

물론 Route 53의 failover 라우팅을 사용하면 장애 시 다른 대상으로 우회시키는 구성은 가능하다.
또는 Auto Scaling을 통해 장애가 난 로드밸런서 인스턴스를 새 인스턴스로 교체하도록 만들 수도 있다.

하지만 이 방식들은 선착순 이벤트의 “첫 관문”을 맡기기에는 한계가 있었다.
Auto Scaling 기반 교체는 새 인스턴스가 기동되고 서비스 가능 상태가 되기까지 수 분이 걸릴 수 있고,
Route 53 failover는 DNS 기반 전환이기 때문에 캐시와 전파 지연의 영향을 받는다.
즉, 둘 다 장애 복구 수단 으로는 의미가 있지만,
짧은 순간에 대량 요청이 몰리는 선착순 이벤트에서 입구를 즉시 안정적으로 유지하는 방식 으로 보기는 어려웠다.

둘째, 운영 부담이 직접 생긴다.
커넥션 수, 커널 파라미터, 헬스체크, 장애 복구, 인스턴스 교체 같은 문제를 전부 스스로 챙겨야 한다.
평소 트래픽이 안정적이라면 괜찮지만, 선착순 이벤트처럼 짧은 시간에 요청이 급격히 몰릴 수 있는 상황 에서는 이 부담이 꽤 크게 느껴졌다 , 즉 이 방식은 비용과 단순함 면에서는 장점이 있지만, 예상치 못한 트래픽에서 가장 앞단을 직접 운영해야 한다는 점에서 구조적인 리스크가 컸다.

방법 2: NLB(Network Load Balancer)

두 번째로 고려해본 건 AWS의 관리형 로드밸런서인 NLB이다.

NLB는 L4 계층에서 동작하고, AWS 공식 문서에서도 급격하고 변동성 큰 트래픽 패턴에 최적화되어 있다고 안내한다.
또 AZ별 static IP를 제공할 수 있고, 매우 낮은 지연 시간과 높은 처리량이 강점이다.

이 특성만 보면, “순간적으로 몰리는 이벤트 트래픽”과 잘 맞아 보인다.
실제로 초고성능 TCP 처리나 정적 IP가 중요한 환경이라면 굉장히 좋은 선택지다.

다만 이번에는 몇 가지 이유로 최종 선택에서는 밀렸다.

우리에게 더 중요했던 건 단순한 L4 전달 성능만이 아니라,

HTTP 레벨에서 다루기 쉬운 운영성
웹 애플리케이션 앞단으로서의 관리 편의성
WAF 연동 같은 보안 구성
타깃 상태를 보고 빠르게 제외/복구시키는 흐름

같은 요소들이었다.

특히 AWS WAF는 대표적으로 CloudFront, API Gateway, 그리고 Application Load Balancer 와 연동되는 서비스로 안내된다. 이번 이벤트는 웹 요청을 받는 구조였기 때문에, 순수한 연결 레벨 처리보다 애플리케이션 레벨에서 다루기 쉬운 선택 이 더 적합하다고 판단했다.

즉, NLB는 성능 면에서는 매우 강력하지만,
이번 문제에서는 “가장 앞단의 웹 트래픽 운영”이라는 목적과 완전히 일치하지는 않았다.

방버 3: ALB(Application Load Balancer)

ALB는 애플리케이션 계층(L7)에서 동작하고,
AWS 문서 기준으로 트래픽 변화에 따라 자동으로 확장되며,
헬스 체크를 통해 정상 타깃에만 요청을 전달할 수 있다.

또한 타깃은 유연하게 추가/제거할 수 있다.

게다가 ELB 계열은 멀티 AZ 구성이 가능하고, AWS에서도 둘 이상의 AZ에 걸쳐 운영하는 구성을 권장하는 흐름을 확인할 수 있다.

이런 점은 앞단의 가용성을 높이는 데 유리하다.

ALB의 장점은 이번 이벤트 상황과 잘 맞았다.

앞단을 관리형으로 둘 수 있다.
특정 이벤트 서버가 비정상이면 헬스 체크 기반으로 자동 제외할 수 있다.
트래픽 증가를 직접 프록시 인스턴스 한 대로 받아내는 구조보다 안전하다.
WAF 연동이 자연스럽다.

물론 ALB에도 단점은 있다.

직접 프록시를 운영하는 것보다 비용이 더 들 수 있다.
L4 중심의 극단적인 성능 최적화나 static IP 같은 요구사항에서는 NLB가 더 잘 맞을 수 있다.
로드밸런서 동작을 세밀하게 직접 제어하는 자유도는 self-managed 프록시보다 낮다.

그럼에도 이번에는 이 단점보다 장점이 더 컸다.

우리가 정말 피하고 싶었던 것은
이벤트 트래픽의 가장 첫 번째 관문을 단일 인스턴스로 직접 책임지는 상황이었기 때문이다.

2차 문제 해결: ALB로 결정!

정리하면 판단 기준은 이랬다.

HAProxy를 EC2에 직접 올리는 방식은
작고 빠르게 시작하기엔 좋지만,
입구 자체가 단일 병목이 되기 쉽고 운영 부담이 모두 우리에게 남는다.

NLB는 급격한 트래픽과 고성능 연결 처리에는 매우 강력하지만,
이번처럼 웹 애플리케이션 앞단에서 운영성과 보안 연동까지 함께 고려하는 상황 에서는 다소 결이 달랐다.

반면 ALB는 트래픽 변화 대응, 헬스 체크 기반 타깃 제외, 멀티 AZ 구성, WAF 연동이라는 측면에서
“입구를 안전하게 관리형으로 넘긴다” 는 목적에 가장 잘 맞았다.

결국 이번 선택의 핵심은
“ALB가 무조건 최고라서”가 아니라,
트래픽 규모를 정확히 예측할 수 없는 선착순 이벤트에서 가장 위험한 단일 병목을 제거하는 것이 우선이었기 때문 이다.

입구는 관리형으로 안정성을 확보하고, 우리는 뒤쪽 이벤트 서버의 오토스케일링, 큐 처리, 재고 차감 같은
서비스 핵심 문제에 집중하는 편이 전체 시스템 관점에서 더 합리적이라고 판단했다.

여기까지 하면 서버 형태는 아래와 같아진다.

ALB까지 적용 완료!!

3차 문제: 로드밸런서 뒤의 서버는 얼마나 받아낼 수 있을까

자 그럼 ALB까지는 무사히 들어왔다.

그 다음으로 마주해야 할 곳은 서버다.
ALB는 요청을 여러 서버로 분산시켜 줄 수 있지만,

정작 그 뒤에 있는 각 서버가 그 요청을 제대로 받아낼 수 있는 상태인지 는 또 다른 문제였다.

만약 서버가 2대라면 각 서버는 1,000 TPS씩 감당해야한다.

1,000 TPS를 받기 위해 과연 아무런 준비를 하지 않아도 될까??

아니다

선착순 이벤트에서 중요한 건 단순히 요청을 여러 대로 나누는 것이 아니다.
짧은 시간에 많은 요청이 몰릴 때, 각 서버가 웹 서버 레벨에서 연결을 받아들이고, 요청을 큐잉하고, 애플리케이션 스레드로 넘겨 처리할 수 있어야 한다.
앞단에서 분산이 잘 되어도, 뒤쪽 서버가 그 요청을 받아내지 못하면 병목은 단지 위치만 바뀔 뿐이다.

그래서 이 단계에서는 DB 같은 하위 시스템까지 한 번에 보지 않았다.
그건 다음 문제로 넘기고, 먼저 더 앞단의 질문부터 풀고 싶었다.

“이벤트 서버 한 대는, 애플리케이션 서버 자체만 놓고 봤을 때 얼마나 많은 요청을 안정적으로 받아낼 수 있는까?”

평소라면 크게 고민할 필요가 없다.

대략적으로 계산해도, 현재 우리가 겪는 소규모 트래픽보다 훨씬 많은 요청을 서버가 감당할 수 있기 때문이다.

하지만 이번 이벤트는 다르다.

짧은 시간에 많은 요청이 몰릴 것으로 예상되는 만큼, 서버가 어디까지 버틸 수 있는지 대략적인 한계는 미리 알고 있어야 했다.

그래야 이 정도 트래픽은 서버 단까지는 큰 문제 없이 받아낼 수 있겠구나라는 판단을 할 수 있기 때문이다.

1. OS단 설정

일단 서버 관점에서 보면, 인스턴스의 운영체제는 리눅스다.

외부에서 들어온 요청은 곧바로 애플리케이션으로 전달되는 것이 아니라, 먼저 운영체제가 연결을 받아들이고 소켓 형태로 관리한다.

이때 소켓 역시 파일 디스크립터로 취급되기 때문에, 동시에 많은 연결이 몰릴 수 있는 환경이라면 nofile 같은 운영체제 한도도 함께 확인해야 한다.
또한 순간적으로 연결이 몰릴 수 있으므로 `somaxconn`, `tcp_max_syn_backlog` 같은 `backlog` 관련 설정도 같이 점검했다.

1) nofile

우선 ulimit -n 명령어는 현재 셸에서 열 수 있는 파일 디스크립터의 최대 개수를 확인하는 명령어다.

ulimit -n

리눅스 환경에서 모든 네트워크 소켓은 파일 디스크립터로 관리되므로, 대량의 동시 연결이 발생하는 선착순 이벤트 특성상 nofile 한도 점검은 필수적이었다. AWS Linux 2023의 기본값인 65,535는 16비트 시스템의 전통적인 상한값으로, 본 시스템에서 설정한 톰캣 maxConnections = 10,000를 상회하는 충분한 여유 수치였다. 따라서 하위 인프라의 파일 디스크립터 한도보다는 실제 연결 성립의 병목이었던 커널 대기열 최적화에 집중하는 것이 더 합리적인 우선순위라고 판단했다.

왜 65535가 기본값일까?

이 부분은 AWS 공식 문서에서 직접적인 설명을 찾지는 못했다.
65535는 2의 16제곱에서 1을 뺀 값(16비트 최대값)이라, 옛날부터 포트 번호 개수, 각종 커널/네트워크 한도 등에서 많이 쓰이던 전통적인 상한 값이라고 한다. 그래서 운영체제나 네트워크 관련 기본 한도에서도 종종 보이는 숫자라고 이해하면 된다.

2) backlog 관련 설정

요청이 서버에 들어온다고 해서 곧바로 애플리케이션이 처리하는 것은 아니다.
그 전에 리눅스 커널이 먼저 연결을 받고, 잠깐 줄을 세워두는 구간이 있다.

이걸 놀이공원 입장 줄에 비유해보면 이해가 쉽다.

문 앞에서 입장 확인을 기다리는 줄
입장 확인은 끝났지만, 실제로 안으로 들어가기 전 잠시 대기하는 줄

리눅스는 이런 식으로 연결을 단계별로 잠깐 보관한다.
그리고 이때 중요한 설정이 바로 `tcp_max_syn_backlog`와 `somaxconn`이다.

(1) tcp_max_syn_backlog

이건 아직 연결이 완전히 성립되기 전,

즉 TCP 3-way handshake가 진행 중인 연결들을 얼마나 대기열에 쌓아둘 수 있는지에 대한 값이다.

TCP 연결은 보통 아래 순서로 맺어진다.

클라이언트가 SYN을 보낸다.
서버가 SYN-ACK를 보낸다.
클라이언트가 마지막 ACK를 보내면 연결이 성립된다.

여기서 마지막 ACK가 오기 전까지는
아직 연결이 완전히 끝난 것이 아니라 half-open connection 라고 볼 수 있다.

tcp_max_syn_backlog는 바로 이 반쯤 열린 연결들을 잠깐 담아두는 대기열 크기다.

쉽게 말하면, 이 값은 서버 입장 직전, 문 앞에서 신분 확인을 기다리는 줄의 길이에 가깝다.

이 값이 너무 작으면 짧은 순간에 연결 시도가 몰렸을 때 문제가 생길 수 있다.
아직 연결이 완전히 맺어지지 않은 연결들이 금방 대기열을 채워 버리고,
그 뒤에 들어온 연결들은 재시도되거나 지연될 수 있다.

사용자 입장에서는 이런 식으로 보일 수 있다.

접속이 바로 안 됨
잠깐 멈춘 것처럼 느껴짐
재시도 끝에 겨우 붙음
심하면 타임아웃처럼 보임

즉, `tcp_max_syn_backlog`는 연결이 막 시작되는 초반 구간에서 순간적인 몰림을 흡수해 주는 완충 공간이라고 이해하면 좋다.

(2) net.core.somaxconn

이번에는 TCP handshake가 이미 끝난 뒤,
즉 연결은 성립했지만 애플리케이션이 아직 accept() 해서 가져가지 못한 상태에서 사용되는 대기열과 관련 있다.

예를 들어 연결 자체는 이미 성공했는데,

nginx가 아직 꺼내 가지 못했거나

tomcat이 아직 받아 가지 못했거나

애플리케이션이 잠깐 밀리고 있는 상태 라면 커널은 그 연결을 잠시 줄 세워 둔다.

이때 실제 대기열 크기는 애플리케이션이 listen(fd, backlog)로 요청한 값과, 커널의 somaxconn 상한이 함께 작용해 결정된다.
쉽게 설명하면 somaxconn은 그 상한선 역할을 하는 값이라고 보면 된다.

비유하면 이건 입장 확인은 끝났지만, 실제로 안으로 들어가기 전까지 서 있는 안쪽 대기줄이다.

tcp_max_syn_backlog는 문 앞 대기줄
somaxconn은 문은 통과했지만 아직 직원이 안으로 안내하기 전 대기줄

애플리케이션은 보통 listen(fd, backlog) 같은 방식으로
"이 정도까지는 대기열을 두고 싶다"는 값을 넘긴다.

하지만 커널은 그 값을 무조건 다 받아주지 않는다.

예를 들어 애플리케이션이 backlog를 10000으로 주더라도, 커널의 somaxconn 값이 4096이라면 실제로는 그보다 크게 잡히지 못한다. 즉, 애플리케이션에서 아무리 크게 설정해도 커널 쪽 상한이 더 낮으면 결국 그 값에 막히게 된다.

정리하면 이렇다.

tcp_max_syn_backlog

아직 handshake가 끝나지 않은 연결들의 대기열
연결 시작 단계의 버퍼

somaxconn

handshake는 끝났지만 애플리케이션이 아직 못 받아간 연결의 대기열 상한
연결 성립 이후의 버퍼

즉, 요청이 몰릴 때는 단순히 톰캣이나 nginx 설정만 볼 것이 아니라,
그 앞단에서 리눅스 커널이 어디까지 연결을 받아두고 버틸 수 있는지도 함께 봐야 한다.

직접 확인해보고 싶다면 아래 명령어로 현재 서버 값을 볼 수 있다.

sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog

확인한 AWS Linux 2023 인스턴스에서는 아래와 같은 값으로 설정되어 있었다.

확인 결과, somaxconn = 4096은 우리가 예상한 순간적인 접속 몰림을 기준으로 봤을 때 당장 부족해 보이지는 않았다.

또한 accept-count를 기본값으로 둘 예정이라 실질적으로 영향을 끼치지는 않는다. 다만 만약 accept-count를 크게 올려야 하는 상황이 생겼을 때 OS 상한에 막히지 않도록 조정이 필요하다.
반면 tcp_max_syn_backlog = 128은 선착순 이벤트처럼 아주 짧은 시간에 연결 시도가 몰릴 수 있는 상황에서는 다소 작게 느껴졌다.

somaxconn이 연결 성립 이후의 대기열이라면, tcp_max_syn_backlog는 연결이 완전히 맺어지기 전 단계의 완충 공간에 가깝다.
이번 이벤트에서는 전체 처리량보다도 오픈 직후의 순간적인 몰림이 더 중요하다고 판단했고, 따라서 somaxconn보다는 tcp_max_syn_backlog를 먼저 여유 있게 조정하는 것이 더 필요하다고 봤다.

물론 backlog 관련 설정만으로 모든 문제가 해결되지는 않는다.
애플리케이션이 연결을 충분히 빠르게 받아가지 못하면 병목은 결국 다른 구간에서 다시 생길 수 있다.
그럼에도 이 설정은 적어도 애플리케이션에 도달하기 전, 커널 단계에서 연결이 밀려나는 상황을 줄이기 위한 기본적인 대비라고 생각했다.

2. 톰캣 설정 점검

그다음으로 봐야 할 것은 톰캣 설정과 이벤트 서버의 수용 한계였다.

이 부분을 먼저 살펴본 이유는 단순했다.
설정이 맞지 않으면, 실제 병목은 톰캣이나 연결 처리 구간에 있는데도 인스턴스 성능이 부족한 것처럼 오해할 수 있기 때문이다.

예를 들어 CPU나 메모리는 아직 여유가 있는데도 maxThreads나 acceptCount가 먼저 한계에 도달하면, 겉으로는 서버 스펙이 부족해 보일 수 있다.
하지만 실제 원인은 인스턴스 체급이 아니라 톰캣 설정일 수도 있다.

이 단계에서 알고 싶었던 것은 조금 더 앞단의 질문들이었다.

인스턴스 스펙은 어느 정도가 적절한가
톰캣의 최대 스레드 수는 몇으로 두는 게 맞는가
요청이 몰릴 때 잠시 대기하는 accept queue 는 어느 정도가 적절한가?
서버 한 대가 안정적으로 받아낼 수 있는 요청량의 대략적인 상한은 어느 정도인가

궁금했던 것은 결국 하나였다.
“무너지지 않고 받아낼 수 있는 양이 어느 정도인가?”

이게 중요했던 이유는, 선착순 이벤트 초반에는 처리하는 것보다 먼저 받아내는 것 자체가 문제가 될 수 있기 때문이다.
모든 사용자가 거의 같은 시점에 같은 API를 호출하면, 그 순간의 병목은 비즈니스 로직보다 앞단의 연결 수용, 스레드 수, 대기 구간, 메모리 사용량 같은 곳에서 먼저 드러날 수 있다.

그래서 이 단계에서는 범위를 의도적으로 애플리케이션 서버 자체로 좁혀 보려고 했다.

1) 인스턴스 체급

가장 먼저 본 것은 인스턴스 체급이었다.

너무 작은 인스턴스는 테스트 초반에는 버텨 보일 수 있다.
하지만 요청이 몰리는 순간 CPU, 메모리, 네트워크 처리 여유가 빠르게 줄어들 수 있다.

반대로 무조건 큰 인스턴스를 선택하는 것도 좋은 답은 아니라고 생각했다.
비용은 높아지는데, 실제 병목이 톰캣 설정이나 연결 처리 구간이라면 기대한 만큼의 효과가 나오지 않을 수 있기 때문이다.

즉, 트래픽을 아무리 받아도 리소스가 남아 돌면 비용부담만 커질뿐이다.

그래서 중요한 것은 “무조건 큰 인스턴스” 가 아니라,
“이벤트 서버 역할에 맞는 최소한의 체급이 어디인가” 를 찾는 것이었다.

일단 기준점으로는 t4g.small로 잡고 조정해나갈 생각이다.

2) 톰캣 스레드 설정

그다음으로 중요한 건 톰캣이었다.

서버는 결국 톰캣을 통해 요청을 받아 애플리케이션으로 넘긴다.
이때 maxThreads가 너무 작으면 요청이 빠르게 대기 상태로 밀리고, 응답 시간도 급격히 늘어날 수 있다.

그렇다고 무작정 스레드를 늘리는 것도 정답은 아니다.

스레드 수가 지나치게 많아지면 문맥 전환 비용이 커지고, 메모리 사용량도 늘어나며, 오히려 처리 효율이 떨어질 수 있다.

즉, 톰캣 설정은 “많을수록 좋다”가 아니라
인스턴스 자원과 요청 특성에 맞는 적정값을 찾는 문제 였다.

3) 연결 수와 대기 구간

선착순 이벤트에서는 짧은 시간에 연결이 몰릴 수 있다.
이 경우 서버가 실제 비즈니스 로직을 실행하기도 전에, 연결 수용 단계나 요청 대기 구간에서 먼저 압박이 생길 수 있다.

Tomcat 기준으로 보면 maxThreads는 실제 요청 처리에 투입될 수 있는 작업 스레드 수에 가깝고, maxConnections는 동시에 유지할 수 있는 연결 수의 상한, acceptCount는 처리 여력을 넘긴 연결이 잠시 대기하는 구간과 관련된 값이다.

즉, 얼마나 처리할 수 있는지, 얼마나 받아둘 수 있는지, 순간적으로 얼마나 버텨줄 수 있는지는 서로 다른 문제였다.

이 값을 너무 작게 잡으면 순간적으로 몰리는 트래픽을 흡수하지 못한다.
연결 수 한도에 빠르게 도달하고 대기 구간도 금방 차 버리면, 일부 요청은 애플리케이션까지 도달하지도 못한 채 거절되거나 타임아웃처럼 보일 수 있다.

앞단에 ALB가 있어 요청을 잘 분산하더라도, 뒤쪽 서버가 연결 자체를 받아내지 못하면 사용자는 결국 “접속이 안 된다”라고 느끼게 된다.

반대로 값을 너무 크게 잡는다고 해서 무조건 좋은 것도 아니었다.
처리 가능한 수준보다 훨씬 많은 연결을 오래 붙잡아 두면, 실패가 빨리 드러나는 대신 지연이 서버 내부에 쌓이게 된다.초반에는 버티는 것처럼 보일 수 있지만, 어느 순간부터 응답 시간이 급격히 증가하고 전체 처리 효율도 오히려 떨어질 수 있다.

그래서 중요한 것은 단순히 값을 크게 늘리는 것이 아니라,
어느 시점부터 연결이 쌓이기 시작하는지,
어느 순간부터 응답 시간이 갑자기 증가하는지,
그리고 그 지연이 일시적인 버스트 흡수인지, 아니면 병목의 시작인지를 구분해서 보는 것이 더 중요하다고 생각했다.

다만 이 지점의 정확한 한계는 애플리케이션 서버만 보고 단정하기 어려웠다.
실제 서비스에서는 후단 DB까지 포함한 전체 처리 경로가 함께 영향을 주기 때문이다.

그래서 이 단계에서는 이런 위험이 존재한다는 점을 먼저 인지하고, 구체적인 병목 지점과 임계치는 다음 단계에서 DB를 포함한 부하 테스트를 통해 확인하기로 했다.

4) 무엇이 먼저 한계에 도달하는지

서버 한계는 단순히 CPU 사용률 하나로 설명되지 않는다.

어떤 경우에는 CPU가 먼저 치솟을 수 있고, 어떤 경우에는 메모리 사용량이나 GC 부담이 먼저 문제를 일으킬 수도 있다.
또 어떤 경우에는 톰캣 스레드 풀이 먼저 포화되거나, 연결 수와 대기 구간이 먼저 압박을 받을 수도 있다.

그래서 “지금 인스턴스가 버티는가”만 보는 것으로는 부족하다고 생각했다.
무엇 때문에 버티지 못하는가까지 같이 봐야, 스레드를 조정할지, 인스턴스 스펙을 올릴지, 서버 수를 늘릴지를 판단할 수 있기 때문이다.

3차 문제의 잠정 판단

결론부터 말하면, 이 단계에서 정답이 되는 설정값을 한 번에 확정할 수는 없었다.

인스턴스 체급, 톰캣 설정, 그리고 후단 DB까지 모든 요소가 유기적으로 연결되어 있기 때문이다. 문서나 감에 의존하기보다, 명확한 기준점을 먼저 잡고 부하 테스트를 통해 수치를 깎아 나가는 방식이 더 합리적이라 판단했다.

일단 첫 기준 인스턴스는 t4g.small로 잡았다.

톰캣 설정도 이 기준점 위에서 잠정적으로 아래와 같이 시작해보기로 했다.

maxThreads = 150
accept-count = 300
max-connections = 10000

maxThreads는 150으로 잡았다.

t4g.small은 vCPU가 2개다. 톰캣의 기본값은 200이지만, vCPU 2개 위에서 200개의 스레드가 동시에 활성화되면 컨텍스트 스위칭 비용이 커지고, 오히려 처리 효율이 떨어질 수 있다. 이번 이벤트의 핵심 로직은 Redis 조회 → 상태 판단 → 응답 반환으로, CPU를 오래 점유하는 무거운 연산이 아니라 I/O 대기가 주를 이루는 가벼운 흐름이었다. 이런 구조에서는 스레드를 무작정 늘리기보다, 한정된 CPU 위에서 문맥 전환 비용을 억제하면서 가벼운 요청을 빠르게 회전시키는 쪽이 더 유리하다고 봤다. 기본값 200에서 조금 줄여 150을 기준점으로 잡되, 부하 테스트에서 스레드 풀이 먼저 포화되는지 CPU가 먼저 한계에 도달하는지를 보고 조정할 계획이었다.

accept-count는 건드리지 않았다.

accept-count는 톰캣이 서버 소켓을 만들 때 OS에 전달하는 listen backlog 값이다. 쉽게 말하면 OS 레벨에서 잠시 연결을 줄 세워 둘 수 있는 대기 공간의 크기다.

뒤에서 설명할 max-connections와의 관계를 먼저 정리하면 이렇다. 새 연결이 도착하면 OS가 TCP handshake를 처리하고, 톰캣의 Acceptor 스레드가 그 연결을 accept()해서 NIO Selector에 등록한다. 이 시점부터 해당 연결은 max-connections에 카운트된다. 그리고 스레드가 다 바쁜 상태에서 새 요청이 들어와도, NIO 안에서 스레드가 빌 때까지 대기할 수 있다. 스레드 없이도 연결을 가볍게 유지할 수 있는 것이 NIO의 장점이다.

그렇다면 accept-count가 의미를 갖을 때는 max-connections가 꽉 찼을 때다.

max-connections 한도에 도달하면 톰캣은 accept()를 멈추고, 그 이후에 도착하는 연결은 OS backlog, 즉 accept-count 큐에서 대기하게 된다. 이 큐마저 차면 OS가 연결 자체를 거부하고, 사용자는 "접속이 안 된다"고 느끼게 된다.

정리하면 연결 거부까지의 흐름은 이렇다.

max-connections에 여유가 있으면 → 연결은 정상적으로 accept()되고, 스레드가 바쁘더라도 NIO 안에서 대기
max-connections가 꽉 차면 → 새 연결은 accept-count 큐에서 대기
accept-count마저 차면 → OS가 연결을 거부

즉, accept-count는 평소에 사용되는 큐가 아니라 max-connections가 한계에 도달한 극단적인 상황에서의 마지막 완충 장치에 가깝다.

이번 이벤트에서 이 값을 조정할 필요가 있는지를 생각해봤다.

결론부터 말하면 기본값을 유지하기로 했다.

우리의 max-connections는 5,000이고, 예상 동시 연결은 약 2,000~3,000 수준이다. 즉, 정상 시나리오에서는 max-connections에 충분한 여유가 있기 때문에 accept-count 큐가 사용될 일이 거의 없다.

만약 동시 연결이 5,000을 넘어서 이 큐까지 사용되는 상황이라면, 이미 예상 트래픽을 한참 벗어난 비정상 상태다. 그 시점에서 100건을 더 받아주든 300건을 더 받아주든 상황이 크게 달라지지 않는다. 오히려 빠르게 거절해서 사용자가 "지금은 접속이 어렵다"는 피드백을 빨리 받는 편이, OS 레벨에서 응답 없이 오래 기다리는 것보다 나은 경험이라고 봤다.

결국 중요한 것은 모든 설정을 무조건 건드리는 것이 아니라, 조정할 근거가 있는 값만 건드리는 것이라고 생각했다. accept-count는 조정할 근거가 없었고, 부하 테스트에서 이 구간이 실제로 문제가 된다면 그때 조정해도 늦지 않다고 판단했다.

max-connections는 5,000으로 잡았다.

먼저 max-connections가 뭔지부터 정리하면, 이 값은 톰캣이 동시에 열어둘 수 있는 TCP 연결의 최대 개수다.

여기서 중요한 건 "열어둘 수 있는"이라는 표현이다. 연결이 열려 있다고 해서 그 연결이 지금 당장 처리되고 있다는 뜻은 아니다.

Spring Boot의 톰캣은 기본적으로 NIO(Non-blocking I/O) 커넥터를 사용한다. NIO 방식에서는 연결 하나가 스레드 하나를 계속 점유하지 않는다. 대신 selector라는 구조가 여러 연결을 관리하다가, 실제로 데이터를 읽거나 쓸 준비가 된 연결만 스레드에 넘겨준다. 즉, 처리 중이 아닌 유휴 연결은 스레드를 잡아먹지 않고 가볍게 유지된다. 그래서 max-connections를 maxThreads보다 훨씬 크게 잡아도 CPU나 메모리 부담이 바로 늘어나지는 않는다.

예상 참여 인원 1,000명이 평균 2~3개의 탭을 열면 동시 TCP 연결은 약 2,000~3,000개 수준이다. 이 연결들은 대기열 상태 조회 폴링이 이어지는 동안 keep-alive로 유지되므로, 이벤트가 진행되는 수 분간 연결이 쌓인 채 유지될 수 있다. 여기에 예상을 벗어난 재시도나 네트워크 지연으로 연결이 예상보다 오래 남아 있는 경우까지 감안해, 약 2배의 여유를 두어 5,000으로 잡았다.

톰캣의 기본값은 8,192다. 기본값보다 오히려 낮게 잡은 셈인데, 이건 의도적인 판단이었다. 무작정 높게 잡기보다는 예상 트래픽에 근거한 값을 기준으로 두고, 부하 테스트에서 실제로 동시 연결이 어디까지 올라가는지를 확인한 뒤 조정하는 쪽이 더 낫다고 봤다. NIO 기반이라 유휴 연결의 부담은 크지 않지만, 그렇다고 근거 없이 큰 수를 넣어두면 나중에 병목이 생겼을 때 이 값이 원인인지 아닌지를 구분하기가 어려워지기 때문이다.

물론 연결을 많이 열어둔다고 처리가 빨라지는 것은 아니다. 실제 처리 속도를 결정하는 것은 여전히 maxThreads다. 다만 앞단에서 연결이 거부되어 요청이 아예 도달하지 못하는 상황보다는, 일단 연결은 받아두고 그 안에서 스레드가 순서대로 처리하는 흐름이 이번 이벤트에는 더 적합하다고 봤다.

4차 문제: DB 병목

서버를 여러개로 대비한다고 해도 이벤트 요청이 결국 같은 DB로 향한다면,

병목은 사라진 게 아니라 위치만 바뀐 셈이다.

우리의 DB는 하나였고, 사양도 AWS RDS t4g.micro 수준이었다.

이 스펙에서는 사용할 수 있는 커넥션 수에도 분명한 한계가 있었다.

예를들어 RDS t4g.micro로 한다면 최대 커넥션이 83개 수준이다.

그 이상으로 늘리는 것은 현실적으로 어렵다.

무리하게 확장하려 해도 메모리 부담이 커지고, 작은 인스턴스 특성상 안정적으로 버티기 힘들다.

겉으로 보기엔 83개면 적지 않아 보일 수 있다.

하지만 선착순 이벤트처럼 여러 서버가 동시에 같은 DB를 바라보는 상황에서는 이야기가 달라진다.

서버 한 대당 커넥션 풀을 기본값인 10개로만 잡아도 서버 2대면 20개 서버 3대면 30개 서버 4대면 40개 정도다.

즉, 이벤트 서버를 여러 대로 늘리더라도

DB 입장에서 동시에 처리할 수 있는 요청 수는 결국 이 커넥션 수에 의해 제한된다.

여기서 더 큰 문제는 처리하지 못한 요청이 그냥 사라지는 것이 아니라, 전부 애플리케이션 서버 안에서 대기하게 된다는 점이다.

이벤트 시작과 동시에 2천명이 동시에 요청을 보낸다고 가정해보자.

이벤트 서버를 4대로 늘렸다고 해도,

동시에 DB 작업을 수행할 수 있는 요청 수는 극히 적다.

그보다 많은 요청은 DB에 도달하지도 못한 채 커넥션을 기다리게 된다.

문제는 이 순간부터다.

DB가 병목이 되는 순간, 단순히 “조금 느려지는 것”으로 끝나지 않는다.

서버 내부에서는 연쇄적으로 장애가 퍼지기 시작한다.

첫 번째로, 스레드가 반환되지 못하고 점점 쌓인다.

DB 커넥션을 얻지 못한 요청은 작업을 끝내지 못한 채 계속 대기한다.

대기 중인 요청 하나하나는 스레드, 메모리, 소켓 같은 자원을 붙잡고 있고,

이 수가 많아질수록 서버는 점점 새로운 요청을 받을 여유를 잃어간다.

두 번째로, 대기열이 DB가 아니라 애플리케이션 서버 내부에 생긴다.

우리가 원한 것은 “DB가 천천히 처리하는 것”이 아니라

“DB 앞에서 질서 있게 제어하는 것”이었는데,

아무 장치 없이 DB로 바로 보내는 구조에서는 그 대기열이 전부 서버 내부에 쌓인다.

이건 굉장히 좋지 않은 신호다.

대기 중인 수천개의 요청은 스레드 점유 힙/네이티브, 메모리 증가, 커넥션 대기 증가, GC 부담 증가

로 이어지고, 결국 서버 전체를 무겁게 만든다.

세 번째로, 타임아웃이 나기 시작한다.

커넥션을 오래 기다리던 요청은 결국 timeout에 걸리고,

사용자는 502, 504 같은 차가운 에러 페이지를 마주하게 된다.

하지만 문제는 여기서 끝나지 않는다.

선착순 이벤트에서 사용자는 에러를 보면 그냥 떠나지 않는다.

대부분은 새로고침을 하거나 다시 시도한다.

즉, DB가 느려진다, 요청이 서버에 쌓인다, 타임아웃이 난다, 사용자가 재시도한다, 요청이 더 몰린다

는 식의 악순환이 만들어진다.

이벤트 서버를 늘리는 것만으로는 부족했다.

서버를 늘릴수록 앞단은 더 많은 요청을 받을 수 있게 되지만,

그 요청이 모두 같은 DB로 향하는 순간 병목은 더 선명해질 뿐이었다.

문제는 “서버가 몇 대냐”가 아니라,그 많은 요청을 DB까지 그대로 보내도 되느냐였다.

그리고 답은 명확했다.

그대로 보내면 안 된다.

DB는 최종 확정만 책임지게 하고, 그 앞에서 트래픽을 흡수하고 순서를 정리해 줄 완충 구간이 필요했다.

문제 해결 시도 1: DB 동시성 제어

처음에는 당연히 DB 안에서 해결하는 방법들을 떠올렸다.

비관적 락, 낙관적 락, 스킵 락, 조건부 업데이트 같은 방법들이다.

이 방식들은 분명 의미가 있다.

실제로 같은 재고를 여러 요청이 동시에 건드릴 때, 정합성을 지키기 위해 자주 사용하는 방법이기도 하다.

하지만 여기서 중요한 건

이 기법들은 데이터 정합성을 지키는 데는 강하지만, 폭주하는 트래픽을 막아내는 근본적인 해결책은 아니라는 것이다.

예를 들어 비관적 락은 안전하다.

대신 동시에 몰리는 요청이 많아질수록 기다리는 요청도 함께 늘어난다.

하나의 요청이 락을 쥐고 있는 동안 수십, 수백 개의 요청이 DB 커넥션을 붙잡고 대기하게 되는데, 이는 결국 커넥션 풀 고갈과 시스템 전체의 응답 지연으로 이어진다.

정합성을 지키려다 서비스 전체가 멈추는 셈이다.

낙관적 락은 락을 오래 잡지 않아 가볍지만, 충돌이 많아지면 실패와 재시도가 급격히 늘어난다. 선착순처럼 같은 자원에 경쟁이 집중되는 상황에서는 적합하지 않는 방법이다.

스킵 락은 여러 작업자가 병렬로 작업을 나눠 처리할 때 유용하지만, 그 전에 이미 요청이 DB까지 쏟아지고 있다는 사실 자체는 바꾸지 못한다.

즉, 이 기법들은

DB에 들어온 요청을 어떻게 안전하게 처리할 것인가에 대한 답이지,

DB로 너무 많은 요청이 한꺼번에 몰리는 상황 자체를 어떻게 막을 것인가에 대한 답은 아니었다.

여기서 문제의 본질이 더 선명해졌다.

우리가 막아야 했던 것은

“같은 row를 동시에 수정하는 문제” 이전에,

수많은 요청이 동시에 DB 앞에 몰려드는 상황 그 자체였다.

DB는 마지막에 정합성을 보장하는 곳으로는 적합하다.

하지만 이벤트 시작 순간의 폭주를 정면으로 받아내는 곳으로 쓰기에는 너무 비싸고, 너무 무겁고, 너무 느렸다.

그래서 DB를 정면으로 방패 삼는 구조 대신, DB 앞단에서 들어오는 폭발적인 트래픽을 흡수하는 구조로 생각을 바꾸게 됐다.

문제 해결 시도 2: 메모리 기반 저장소 도입

DB 앞단에서 트래픽을 흡수할 완충 지대를 찾기 위해, 자연스럽게 메모리 기반 저장소를 떠올리게 됐다.

다만 이때 필요한 것은 단순히 “빠른 캐시”가 아니었다.
먼저 들어온 순서를 매기고, 같은 사용자의 중복 참여를 막고, 현재 상태를 저장하고, 필요하면 여러 조건을 한 번에 처리할 수 있어야 했다.

당시 기준에서 후보는 크게 세 가지였다.

첫 번째는 Memcached였다.
Memcached는 매우 빠른 인메모리 key-value 저장소이고, 원래도 DB 부하를 줄이기 위한 캐시 용도로 널리 쓰인다. 장점은 단순하고 가볍다는 점이다. 대신 기본 성격이 어디까지나 단순한 key-value 캐시에 가깝기 때문에, 선착순 이벤트처럼 순서를 매기고 상태를 저장하고 중복 참여를 막아야 하는 문제에는 상대적으로 표현력이 부족했다.

두 번째는 Apache Ignite 같은 계열이었다.
Ignite는 단순 캐시라기보다, 메모리 우선 구조 위에 분산 SQL, ACID 트랜잭션, 지속성까지 함께 제공하는 분산 데이터 플랫폼에 가깝다. 대규모 분산 처리나 더 복합적인 데이터 처리 문제를 다루기에는 분명 강력한 선택지다. 다만 이번 이벤트에서 우리에게 필요한 것은 거대한 분산 데이터 플랫폼이라기보다, 짧은 시간 안에 빠르게 검증하고 운영할 수 있는 비교적 단순한 구조였다.

세 번째는 Redis 계열이었다.
Redis는 string, hash, list, set, sorted set, stream 같은 다양한 자료구조를 제공한다. 여기에 Lua Script를 이용하면 여러 연산을 서버 안에서 원자적으로 묶어 처리할 수도 있다. 단순 캐시를 넘어 순서, 상태, 중복 방지, 큐잉 같은 요구사항을 함께 다루기 좋은 쪽이었다.

이렇게 놓고 보니 기준은 분명해졌다.

Memcached를 선택했다면 결국 “순서”, “중복 방지”, “상태” 같은 개념을 애플리케이션 코드에서 더 많이 다시 만들어야 했을 것이다.
반면 Redis는 필요한 개념을 자료구조 수준에서 어느 정도 바로 제공해 주기 때문에, 문제를 더 자연스럽게 모델링할 수 있었다.

또 Redis는 명령 단위 처리 자체가 단순하고 빠른 편이고, 필요하다면 이후에 여러 연산을 서버 안에서 묶어 처리하는 방향도 열려 있었다.
이 시점에서는 아직 최종 원자적 처리 방식을 확정한 것은 아니었지만, 적어도 그런 방향으로 확장할 수 있는 선택지라는 점도 중요했다.

무엇보다도 Redis는 문제를 자료구조 수준에서 비교적 자연스럽게 표현할 수 있었고, 단순 캐시를 넘어 상태 관리 계층으로 쓰기에도 무리가 적었으며, 복잡한 분산 플랫폼까지 들고 오지 않아도 될 만큼 구조가 적절히 가벼웠다

여기에 더해 Redis는 현업에서도 워낙 널리 쓰이고 있었고, 참고할 수 있는 사례와 자료도 가장 풍부했다.
처음 도입하는 입장에서는 새로운 기술을 실험하는 것보다, 이미 많이 검증된 선택지를 가져가는 편이 훨씬 안전했다.

그래서 Redis를 선택하게 됐다.

문제 해결 시도 3: 원자적 연산을 향한 고민

Redis를 도입하고 나서 처음 떠올린 건 매우 단순한 방식이었다.

요청이 들어올 때마다 번호를 하나씩 증가시키고, 그 값이 정해진 수량 이내라면 성공으로 처리하면 되지 않을까?

피크 2,000 TPS를 목표로 잡은 상황에서, 가장 먼저 눈에 들어온 것은 Redis의 INCR 였다.
Redis는 명령을 순차적으로 처리하고, INCR 자체도 원자적으로 동작한다.
즉, 요청이 들어올 때마다 번호를 하나씩 증가시키고, 그 값이 발급 수량 이내라면 성공으로 처리하는 구조를 생각할 수 있었다.

예를 들어 쿠폰이 70개라면,

첫 번째 요청은 1번
두 번째 요청은 2번
70번째 요청까지는 성공
71번째 요청부터는 실패

이 구조는 처음엔 꽤 매력적으로 보였다.
Redis는 빠르고, INCR 같은 원자적 연산도 지원하고, 구현도 단순하게 가져갈 수 있기 때문이다.

하지만 구현하다 보니 놓친점이 있었다.

번호를 하나 올리는 것과, 실제 발급을 확정하는 것은 전혀 다른 문제였다.

실제 발급 과정에서는 이런 조건들이 함께 따라온다.

이미 참여한 사용자는 아닌지
이벤트가 이미 종료된 것은 아닌지
재고가 아직 남아 있는지
발급 이력을 어떻게 남길지
최종적으로 성공 상태를 어떻게 확정할지

문제는 INCR 가 보장해주는 것은 어디까지나 숫자를 하나 증가시키는 것뿐이라는 점이었다.
번호를 올리는 것 자체는 원자적이지만, 그 번호를 바탕으로 실제 발급을 확정하는 과정은 그 뒤에 따로 이어진다.

여기서 문제가 발생한다.

INCR 자체는 원자적이다.
하지만 INCR 결과를 받아와서 애플리케이션 서버가

“이 번호면 발급 가능하네”라고 판단하고

그다음에 중복 확인, 상태 변경, 저장 같은 실제 발급 로직을 수행하는 구조라면

그 사이에는 아주 짧은 틈이 생긴다.

이게 바로 전형적인 Check-Then-Act 문제다.

평소에는 별문제 없어 보일 수 있다.
하지만 선착순 이벤트처럼 많은 요청이 동시에 몰리는 상황에서는, 이 짧은 틈이 그대로 레이스 컨디션으로 이어진다.

예를 들어 여러 서버가 거의 동시에 INCR 결과를 받아 “발급 가능하다”고 판단했다고 해보자.
그다음 단계에서 중복 확인이나 상태 변경이 분리되어 있다면, 그 찰나의 순간에 여러 요청이 동시에 같은 자원을 통과할 수 있다.
결과적으로 중복 발급이나 초과 발급 같은 정합성 문제가 발생할 수 있다.

즉, 번호를 정확히 매기는 것만으로는 부족했다.
정말 필요한 것은
번호 증가, 조건 확인, 상태 변경이 하나의 원자적 단위로 움직이는 구조였다.

분산 락 vs Lua Script

이 문제를 해결하는 방법으로 분산 락을 떠올릴 수 있다.
실제로 여러 서버가 동시에 같은 자원을 다루는 상황에서는 분산 락이 꽤 익숙한 선택지이기도 하다.

하지만 이번 상황에서는 분산 락이 꼭 좋은 선택만은 아니었다.

가장 큰 이유는 비용 대비 효과였다.

분산 락을 쓰려면 보통 락을 잡고, 확인하고, 해제하는 여러 단계가 필요하다.
이 과정은 결국 네트워크 왕복을 여러 번 발생시키고, 락 만료 시간이나 해제 주체 같은 세부 설계까지 함께 고민해야 한다.
2,000 TPS처럼 짧은 순간에 요청이 몰리는 상황에서는, 이 추가 비용 자체가 부담이 될 수 있었다.

반면 우리가 하려던 작업은 생각보다 짧고 명확했다.

중복 참여를 확인하고
현재 재고를 확인하고
가능하면 카운터를 증가시키고
상태를 바꾸는 것

이 정도의 짧은 로직이라면, 락을 외부에서 관리하기보다 Redis 내부에서 한 번에 실행하는 편이 더 단순하고 빠르다고 판단했다.

그래서 선택한 것이 Lua Script였다.

Redis는 Lua Script가 실행되는 동안 다른 명령이 중간에 끼어들지 않도록 보장한다.
즉, 여러 명령을 나눠 호출하는 대신, 하나의 스크립트 안에서 한 번에 처리할 수 있다.

이 방식의 장점은 분명했다.

첫째, 진짜로 묶고 싶은 구간을 하나의 원자적 작업으로 만들 수 있다.
중복 확인, 재고 체크, 번호 증가, 상태 변경을 한 번에 처리할 수 있다.

둘째, 네트워크 왕복 횟수를 줄일 수 있다.
애플리케이션 서버가 Redis와 여러 번 통신하며 판단하는 대신, 필요한 명령을 Redis 내부에서 바로 수행하게 만들 수 있다.

셋째, 로직의 책임이 더 분명해진다.
발급 가능 여부를 애플리케이션 서버가 분산해서 판단하는 것이 아니라, Redis 안에서 한 번에 판정하게 되므로 흐름이 더 단단해진다.

결국 중요한 건 단순한 카운팅이 아니었다.
발급 가능 여부를 안전하게 판단하는 것이었다.

그래서 Lua Script 안에서는 이런 흐름을 한 번에 처리하도록 생각했다.

이미 발급된 사용자인지 확인한다
현재 재고가 남아 있는지 확인한다
조건을 만족하면 카운터를 증가시킨다
해당 사용자를 발급된 사용자 집합에 기록한다
성공/실패 결과를 반환한다

핵심은 같다.

중복 확인 → 재고 확인 → 상태 변경
이 흐름을 더 이상 애플리케이션 서버에서 나눠 처리하지 않고,
Redis 안에서 한 번에 끝내도록 만든 것이다.

다만 여기서 한 가지는 분명히 구분해야 했다.

Lua Script가 보장해주는 원자성은 스크립트 실행 중 다른 Redis 명령이 끼어들지 않는다는 의미의 원자성이다.

즉, 애플리케이션 서버에서 여러 번 나눠 호출할 때 생기던 레이스 컨디션을 줄이는 데는 매우 효과적이다.

다만 이것이 SQL 트랜잭션처럼 자동 롤백까지 보장해주는 것은 아니다.

그래서 스크립트는 최대한 짧고 단순하게 유지해야 했다.
오류가 날 여지가 적은 명령만 넣고, Redis 안에서 오래 실행되는 무거운 로직은 피해야 했다.
Lua Script가 강력한 이유는복잡한 로직을 다 때려 넣을 수 있어서가 아니라,
짧고 명확한 임계 구간을 안전하게 묶을 수 있어서라는 점을 분명히 인식하게 됐다.

문제 해결 시도 4 : Redis를 최종 저장소로?

Lua Script까지 고려하고 나니, 적어도 Redis 안에서 발급 판단을 꽤 안전하게 처리할 수는 있어 보였다.

하지만 여기서 또 다른 고민이 생겼다.

판단을 Redis에서 할 수 있다는 것과, 최종 발급 사실까지 Redis가 책임져도 되는가는 같은 문제인가?

선착순 이벤트에서 정말 중요한 것은
카운터가 몇까지 올라갔는지가 아니라,
최종적으로 누구에게 발급이 확정되었는지가 흔들리지 않게 남는 것이었다.

물론 Redis에도 스냅샷, 복제 같은 보완 장치는 있다.
하지만 그렇다고 해서 Redis만으로 최종 발급 사실까지 모두 책임지게 두는 구조는 적어도 선착순 이벤트에서는 위험하다고 생각했다.

예를 들어 주기적으로 DB에 반영하는 구조를 생각할 수도 있다.
하지만 3초마다 반영하든, 1초마다 반영하든, 그 사이 장애가 발생하면 마지막 반영 구간의 데이터는 유실될 수 있다.
이 공백은 단순한 데이터 손실 문제가 아니라, 잘못하면 누가 실제 당첨자인가가 흔들릴 수 있는 문제였다.

그렇다면 발급이 확정될 때마다 메시지 큐를 통해 DB에 저장하면 되지 않을까?

구조만 놓고 보면 꽤 그럴듯했다.

실제로 몇몇 테크 기업 블로그를 보면 메시큐를 활용한 모습을 자주 목격할 수 있다.

Redis는 빠르게 경쟁을 처리하고
메시지 큐는 발급 이벤트를 안전하게 넘기고
DB는 최종 발급 내역을 영속적으로 기록한다

하지만 이 방식도 고민할수록 간단하지 않았다.

메시지 큐는 DB를 보호하는 데는 효과적이지만 운영 복잡도와 러닝커브가 엄청났다.

producer와 consumer를 설계해야 하고
메시지 중복 처리도 고려해야 하고
재시도 정책도 정해야 하고
장애 복구 흐름도 설계해야 하고
적재는 성공했지만 응답은 실패한 경우 같은 애매한 상황도 다뤄야 한다

구조는 더 단단해질 수 있지만, 함께 감당해야 할 설계와 운영의 무게는 엄청나게 커진다.

개념적으로는 아주 얕게만 알고 있어 짧은 기간 안에 실제 운영 관점까지 고려해 운영할 수 없다고 판단했다.
또한 러닝커브도 엄청나기에 더더욱 판단에 확신이 들었다.

메시지 큐까지 도입하는 것은, 당시 상황에서는 오버엔지니어링에 가까웠다.

그래서 빠르게 포기했다.

4차 문제 해결 : 대기열

고민 끝에 내린 결론은 병목은 Redis를 통해서 잡지만 최종 저장소로는 쓰지 않기로 했다.

대신 빠르게 줄을 세우고 중복을 거르는 대기열로 쓰고자 했다.

아무리 서버를 늘려도 결국 모든 요청이 사양이 낮은 DB로 향하면 커넥션 고갈로 인한 연쇄 장애는 피할 수 없기 때문이다. 결국 Redis가 대기열과 상태 관리를 전담하며 폭주하는 트래픽을 1차로 흡수하고, 실제 발급 처리는 DB가 감당할 수 있는 만큼만 질서 있게 넘겨주는 구조로 재정의하여 시스템 전체의 생존력을 확보하고자 했다.

5차 문제 : Redis 안에서 줄 세우기

이제 Redis를 대기열로 쓰기로 했으니 어떤식으로 줄을 세울지를 정하면된다.

처음에는 List를 제일 먼저 떠올렸다.
대기열이라고 하면 가장 직관적으로 떠오르는 자료구조가 리스트였기 때문이다.
앞에서 넣고 뒤에서 빼거나, 뒤에 쌓고 앞에서 꺼내는 방식 자체는 딱 줄 서기의 이미지와 잘 맞아 보였다.

하지만 실제 요구사항을 하나씩 대입해보니 생각보다 불편한 점이 많았다.
우리에게 필요한 건 단순히 순서대로 꺼내기만이 아니었다.

특정 사용자가 이미 줄에 들어와 있는지 빠르게 확인할 수 있어야 하고
사용자가 지금 몇 번째인지도 바로 보여줄 수 있어야 하고
중간에 이탈하거나 재시도하는 상황도 다뤄야 했다

리스트는 순서를 유지하는 데는 좋았지만, 사용자가 중복으로 들어있는지 현재 내 순번이 몇 번인지는 알기 어려웠다.
결국 순서는 리스트로 관리하고, 중복 확인은 또 다른 자료구조로 따로 관리해야 하는 식으로 구조가 갈라질 가능성이 높았다.
줄을 세우는 문제를 단순하게 풀고 싶었는데, 오히려 자료구조가 둘 셋으로 흩어질 수 있다는 점이 걸렸다.

Set도 당연히 후보에 올랐다.
중복 방지만 놓고 보면 오히려 List보다 더 매력적이었다.
같은 사용자가 여러 번 요청하더라도 한 번만 들어가게 만들 수 있고, “이미 참여한 사용자인가?” 같은 체크도 훨씬 자연스럽기 때문이다.

문제는 Set에는 순서가 없다는 것이었다.
선착순 이벤트에서 핵심은 결국 “누가 먼저 들어왔는가”인데, Set만으로는 이걸 표현할 수 없다.
즉, 중복 방지는 해결되더라도 선착순의 본질인 순번 관리가 빠져버린다.
결국 Set 역시 단독으로는 부족했고, 또 다른 순서용 자료구조를 옆에 붙여야 했다.

Stream도 후보에서 완전히 배제한 건 아니었다.
오히려 한때는 꽤 진지하게 고민했다.
요청이 들어온 순서대로 append 되고, 소비자 그룹 같은 개념도 있어서 “이벤트를 순서대로 처리한다”는 느낌에는 잘 맞아 보였기 때문이다.
특히 로그처럼 요청 흐름을 쌓아두고 뒤에서 소비하는 구조를 떠올리면 꽤 그럴듯했다.

하지만 이번 문제를 다시 놓고 보니 우리가 원하는 건 단순한 이벤트 로그 저장이 아니었다.
중요한 건 “지금 누가 몇 번째인가”, “이 사용자가 현재 WAITING인지 ACTIVE인지”, “중복 없이 줄을 서게 할 수 있는가” 였다.
즉, 뒤에서 차례대로 소비하는 것만으로는 부족했고, 현재 대기열 상태를 바로 조회하고 제어할 수 있어야 했다.
Stream은 이런 요구를 풀 수는 있겠지만, 지금 우리 문제에 비해 구조가 다소 무겁게 느껴졌다.
이번 이벤트에서는 메시지를 쌓고 소비하는 시스템보다, 현재 대기 중인 줄을 빠르게 관리하는 시스템이 더 중요했다.

결국 하나씩 비교해보니 기준이 분명해졌다.

List는 순서에는 강하지만 중복 확인과 순번 조회가 불편했고
Set은 중복 방지에는 강하지만 순서 자체를 표현할 수 없었고
Stream은 이벤트 흐름을 쌓고 소비하는 데는 좋지만, 이번처럼 현재 대기열의 순번과 상태를 즉시 다루는 문제에는 다소 무거웠다

결국에 도달한 곳은

순서, 중복 방지, 현재 순번 조회를 한 번에 조금 더 자연스럽게 다룰 수 있는 자료구조

바로 Sorted Set이었다.

5차 문제 해결: Sorted Set

우리가 원하는 대기열은 아래와 같았다.

먼저 들어온 순서를 유지할 수 있어야 하고
같은 사용자가 여러 번 요청해도 중복으로 줄 서지 않아야 하고
사용자가 지금 몇 번째인지 빠르게 확인할 수 있어야 하고
필요하면 현재 상태와도 자연스럽게 연결할 수 있어야 했다

즉, 필요한 건 값 저장소가 아니라 정렬된 줄 그 자체를 표현할 수 있는 자료구조였다.

그 기준으로 보니 가장 잘 맞는 건 Sorted Set이었다.

https://medium.com/analytics-vidhya

Sorted Set은 member 와 score 를 함께 저장한다.
이 구조가 대기열 문제와 잘 맞았던 이유는 단순했다.

사용자 ID를 member 로 넣고, 들어온 순서를 나타내는 값을 score 로 넣으면 Redis 안에서 대기열 자체가 곧 정렬된 줄이 된다.

즉, 별도로 정렬 로직을 돌리지 않아도
Redis가 score 기준으로 항상 순서를 유지해준다.

이게 생각보다 컸다.

List를 쓸 때는 “순서는 유지되지만 중복 확인은 따로”, Set을 쓸 때는 “중복은 막히지만 순서는 따로”처럼 구조가 계속 둘로 갈라질 가능성이 있었다.

반면 Sorted Set은 순서와 중복 제어를 한 번에 더 자연스럽게 다룰 수 있었다.

특히 member 가 사용자 ID이기 때문에, 같은 사용자가 다시 요청했을 때도 대기열 안에 중복으로 여러 번 쌓이지 않게 제어하기가 훨씬 수월했다. 즉, 한 사람이 여러 번 줄 서는 문제를 다루기에도 잘 맞았다.

또 하나 중요했던 건 순번 조회였다.

이번 이벤트에서는 단순히 뒤에서 차례대로 꺼내기만 하면 되는 것이 아니었다.
사용자 입장에서는 “내가 지금 몇 번째인가?”를 확인할 수 있어야 했고,
서버 입장에서도 특정 사용자가 대기열 안에서 어디쯤 있는지를 비교적 빠르게 알아낼 수 있어야 했다.

이 점에서도 Sorted Set은 잘 맞았다.

정렬된 구조를 유지하고 있기 때문에,
“누가 앞에 있는가”뿐 아니라 “내가 몇 번째인가” 같은 정보까지 자연스럽게 연결할 수 있었다.

결국 Sorted Set은 우리가 대기열에 기대했던 핵심 요구사항을 가장 균형 있게 만족시켜주는 자료구조였다.

순서를 유지할 수 있고
중복 제어와 연결하기 쉽고
현재 순번 조회에도 유리하고
상태 관리 구조와도 잘 붙는다

즉, 우리가 찾고 있던 것은 큐처럼 보이는 자료구조가 아니라, 선착순 이벤트에 필요한 질서를 계속 유지해주는 자료구조였고,
그 역할에 가장 잘 맞는 것이 Sorted Set이었다.

6차 문제 : 대기열 상태에서 자신의 차례를 어떻게 확인할지

Sorted Set으로 대기열을 만들고, 사용자를 WAITING 상태로 관리하기 시작하자 바로 다음 문제가 따라왔다.

“이제 사용자는 자신의 차례를 어떻게 확인할 것인가?”

대기열은 서버 입장에서는 정리된 줄이지만, 사용자 입장에서는 보이지 않는 줄이다.
사용자는 단순히 “요청이 접수되었다”는 사실만으로는 충분하지 않았다.
지금 내가 여전히 WAITING 상태인지, 아니면 다음 단계로 넘어갈 수 있는지, 가능하다면 현재 순번이 어느 정도인지를 계속 확인할 수 있어야 했다.

즉, 대기열을 만든 순간부터는 단순히 줄을 세우는 문제만 남는 것이 아니었다.
그 줄을 사용자가 어떤 방식으로 조회하게 할 것인가까지 함께 설계해야 했다.

처음에는 이 부분도 꽤 단순하게 볼 수 있었다.
“상태가 바뀌면 서버가 알려주면 되는 것 아닌가?”
“아니면 사용자가 일정 간격으로 물어보게 하면 되지 않을까?”

그런데 이 질문을 조금만 더 깊게 파고들면, 바로 또 다른 문제가 생긴다.

이번 이벤트에서는 대기 사용자가 수백 명 수준이 아니라, 많게는 2,000명 가까이 동시에 줄을 설 수 있다고 보고 있었다.
즉, 상태 조회 방식 하나를 잘못 선택하면, 실제 발급 요청보다 상태 조회 요청이나 연결 유지 비용이 더 큰 부담이 될 수도 있었다.

이 지점에서 상태 조회 방식으로는 크게 세 가지를 검토할 수 있었다.

결국 문제는 단순했다.

“상태를 보여주는 것”도 중요하지만, 그 상태 조회 요청 자체가 또 다른 트래픽 폭탄이 되지 않게 만들어야 했다.

(대기열 잘 못 만들면 ... 큰일난다)

6차 문제 해결 방법 1: SSE

첫 번째는 SSE였다.

SSE는 서버와의 연결을 유지한 채, 서버가 클라이언트에게 상태 변화를 밀어주는 방식이다.
사용자 입장에서는 별도 요청 없이도 상태가 갱신되기 때문에, 대기열처럼 상태 변화가 중요한 기능에 꽤 잘 어울려 보였다.

특히 처음에는 이런 점이 좋아 보였다.

사용자가 계속 새로고침하지 않아도 된다
상태가 바뀌는 순간 서버가 바로 알려줄 수 있다
WebSocket보다는 구조가 단순해 보인다

즉, “대기열에서 내 차례가 오면 서버가 바로 알려주는 구조”라는 점만 보면 꽤 매력적이었다.

하지만 실제 상황에 대입해보니 부담도 분명했다.

가장 큰 문제는 연결을 오래 유지해야 한다는 점이었다.
대기 인원이 많아질수록 서버와 로드밸런서는 그 수만큼의 연결을 오래 붙들고 있어야 한다.
우리가 현재 예상하는 1,500 ~ 2,000명이 동시에 대기열에 들어와 있고, 이 중 상당수가 몇 분씩 WAITING 상태를 유지한다고 생각해보면, 그 연결 자체가 새로운 관리 대상이 된다.

게다가 대기열에서는 모든 사용자에게 실시간으로 많은 이벤트를 보내는 것도 아니다.
대부분의 사용자는 상당 시간 동안 그냥 WAITING 상태에 머물러 있고, 상태 변화는 생각보다 자주 일어나지 않는다.
즉, 연결은 계속 붙잡고 있지만 실제로 자주 보내는 정보는 많지 않은 구조가 된다.

이런 상황에서는 실시간으로 밀어줄 수 있다는 장점보다,
장시간 연결을 유지하는 비용이 더 크게 느껴졌다.

6차 문제 해결 방법 2: WebSocket

두 번째는 WebSocket 이었다.

WebSocket은 양방향 통신이 가능하고, 실시간성이 가장 뛰어난 방식 중 하나다.
서버가 상태를 즉시 밀어줄 수 있을 뿐 아니라, 필요하다면 클라이언트와 더 풍부한 상호작용도 만들 수 있다.

처음에는 이 방식도 상당히 좋아 보였다.

가장 실시간에 가까운 방식이고
서버가 상태 변화를 즉시 전달할 수 있고
이후 더 복잡한 상호작용까지 확장하기 좋다

즉, 실시간 대기열이라는 이미지와 제일 잘 어울리는 방식처럼 느껴졌다.

하지만 이번 이벤트에서 정말 필요한 것을 다시 생각해보니, WebSocket은 다소 과한 선택일 수 있었다.

우리가 필요했던 것은 채팅처럼 양방향 상호작용이 핵심인 시스템이 아니었다.
대부분의 경우 사용자는 지금 내 상태가 무엇인가만 알면 됐고, 서버도 기다리기 or 다음 단계 진행 정도의 정보만 전달하면 충분했다.

즉, WebSocket이 제공하는 강한 양방향성은 유용해보였지만
이번 문제에서는 필수 기능이라기보다 여유 기능에 가까웠다.

운영 측면의 부담도 있었다.

연결을 오래 유지해야 하고
연결이 끊겼을 때 재연결 전략도 생각해야 하고
배포나 일시적인 네트워크 문제 이후 재접속이 한꺼번에 몰릴 가능성도 고려해야 하고
애플리케이션 서버 입장에서도 지속 연결을 계속 관리해야 한다

한마디로, WebSocket은 분명 강력했지만
이번 이벤트가 요구하는 수준에 비해 운영 복잡도가 커질 가능성이 있었다.

특히 이번 이벤트는 첫 시도였고,
짧은 기간 안에 안정적으로 붙일 수 있는가가 훨씬 중요했다.
그 관점에서 보면 WebSocket은 “할 수는 있지만 지금 꼭 필요한가?”라는 질문에 선뜻 그렇다고 답할수가 없었다.

6차 문제 해결 방법 3: Polling

세 번째는 Polling 이었다.

Polling은 사용자가 일정 주기마다 서버에 상태를 다시 요청하는 방식이다.
실시간성만 놓고 보면 SSE나 WebSocket보다 덜 세련돼 보일 수 있다.
사용자가 계속 상태가 바뀌었는지를 물어봐야 하기 때문이다.

처음에는 가장 단순한 방식처럼 느껴졌다.

구현이 단순하고
브라우저와 서버 모두 익숙한 방식이고
디버깅이나 운영도 상대적으로 쉽다

하지만 단순하다고 해서 무조건 좋은 것은 아니었다.
Polling도 잘못 쓰면 꽤 위험하다.

예를 들어 대기 중인 사용자가 2,000명인데, 모두가 1초마다 상태를 조회한다고 해보자.
그러면 발급 요청과는 별개로 상태 조회 요청만으로도 초당 2,000건이 추가된다.
즉, 실제 발급 요청은 잘 제어해놓고도 조회 요청 때문에 앞단이 다시 흔들릴 수 있다.

그래서 Polling은 처음부터 “쉽다”는 이유만으로 선택할 수 있는 방식은 아니었다.
중요한 건 그 polling을 얼마나 통제된 형태로 만들 수 있느냐였다.

다만 Polling에는 분명한 장점도 있었다.

Polling은 요청이 들어온 순간에만 자원을 사용하고, 응답을 반환한 뒤에는 연결을 정리할 수 있다.
즉, SSE나 WebSocket처럼 대규모 지속 연결을 오래 유지하지 않아도 된다.

물론 매번 새 연결을 맺는다면 비효율적일 수 있다.
하지만 HTTP keep-alive를 활용하면 같은 연결을 재사용할 수 있어서, 연결 생성 비용을 어느 정도 줄일 수 있다.

즉, Polling은 실시간성에서는 조금 손해를 보더라도,

대규모 대기열 환경에서 지속 연결을 오래 유지하지 않고도 비교적 단순하게 운영할 수 있는 방식이라는 장점이 있었다.

6차 문제 해결

세 가지를 놓고 비교해보니 기준이 조금씩 분명해졌다.

이번 이벤트에서 정말 중요했던 것은
가장 실시간에 가까운 방식이 아니라,
대기열 상태를 사용자에게 충분히 보여주면서도 시스템 전체를 흔들지 않는 방식이었다.

그 관점에서 보면 SSE와 WebSocket은 분명 매력적이었지만,
대기 인원이 많을 때 장시간 연결을 계속 유지해야 한다는 부담이 있었다.
반면 Polling은 덜 세련돼 보일 수는 있어도,
요청이 들어온 순간에만 자원을 사용하고 비교적 단순하게 운영할 수 있다는 점에서 이번 이벤트의 조건에 더 잘 맞았다.

그래서 최종적으로는 Polling 을 선택했다.

다만 여기서 중요한 건,
우리가 선택한 것은 단순한 “고정 주기 폴링”이 아니라는 점이었다.

문제는 폴링을 선택했다고 해서 끝이 아니라는 것이었다.
대기 인원이 많아질수록 상태 조회 요청 자체가 또 다른 트래픽 폭탄이 될 수 있기 때문이다.

그래서 폴링은 허용하되, 조회 주기를 클라이언트에 맡기지 않았다.

대신 서버가 응답에 retryAfterMs 같은 값을 함께 내려주고, 클라이언트는 그 간격에 맞춰 다시 조회하도록 만들었다.

핵심은 조회 빈도까지 서버가 통제하는 것이었다.
대기열 뒤쪽 사용자는 더 긴 간격으로, 앞쪽에 가까워질수록 더 짧은 간격으로 조회하게 해서
상태 조회 요청 자체도 시스템이 감당 가능한 범위 안에서 움직이도록 했다.

예를 들어 뒤쪽 사용자에게는 최대 1분 수준의 간격을 주고,
순번이 앞당겨질수록 그 값을 점차 줄여
앞쪽 사용자에게는 1초 수준으로 짧게 조회하도록 했다.

이 방식이 중요했던 이유는 단순히 현재 상태를 보여주기 위해서가 아니었다.
우리는 상태 조회 요청조차도 전체 시스템 부하 관점에서 통제 가능한 구조를 만들고 싶었다.

결국 이번 이벤트에서는 SSE나 WebSocket이 가진 장점도 분명히 있었지만,
대규모 대기열 상황에서의 연결 유지 비용, 운영 복잡도, 그리고 우리가 실제로 필요로 하는 실시간성 수준을 함께 비교했을 때
가장 현실적인 선택은 서버 주도 폴링 전략이었다.

;

7차 문제: 실제 발급 구간을 어떻게 제어할 것인가

여기까지 오면 대기열 자체는 어느 정도 정리된 셈이다.

Redis 안에서 요청을 줄 세웠고,
사용자는 WAITING 상태로 관리되며,
자신의 순번과 상태도 폴링을 통해 확인할 수 있게 됐다.

하지만 여기서 끝은 아니었다.

대기열을 잘 만들었다고 해서, 그다음 단계인 실제 발급 구간까지 자동으로 안전해지는 것은 아니기 때문이다.

문제는 단순했다.

“줄을 선 사람들을 어떤 기준으로, 어떤 속도로 실제 발급 단계로 넘길 것인가?”

여기서 가장 경계했던 건 WAITING 상태의 사용자를 한꺼번에 DB로 보내는 구조였다.
애초에 대기열을 만든 이유 자체가 폭주한 요청을 바로 DB로 흘려보내지 않기 위해서였는데, 줄을 세운 뒤 다시 모든 사용자가 동시에 발급을 시도하게 만들면 결국 병목은 다시 DB로 되돌아간다.

즉, 대기열은 만들었지만 실제 경쟁이 일어나는 구간은 여전히 통제되지 않은 상태였던 셈이다.

특히 쿠폰 발급은 단순 조회가 아니다.
실제 발급 단계에 들어오면 캡차 검증이 필요하고, 발급 가능 여부를 다시 확인해야 하고, 최종적으로는 DB에 발급 내역까지 남겨야 한다.
즉, WAITING 상태에서의 조회보다 훨씬 무거운 작업이 뒤따른다.

이 구간에 너무 많은 사용자가 동시에 진입하면, 앞단에서 아무리 대기열을 잘 정리해도 마지막 발급 단계에서 다시 병목이 생길 수 있다.

결국 여기서 내린 결론은 분명했다.

대기열은 전체 요청을 흡수하기 위한 장치였고, 실제 발급 구간은 그중에서도 지금 처리 가능한 만큼만 제한적으로 들어가야 하는 구간이어야 했다.

그래서 WAITING 상태의 사용자 전체를 바로 발급 단계로 보내지 않고, 일부 트래픽만 ACTIVE 상태로 전환해 실제 발급 구간으로 넘기기로 했다.

그런데 여기서도 문제가 완전히 끝난 것은 아니었다.

Redis를 도입해서 DB로 들어오는 트래픽은 획기적으로 줄였지만, 여전히 ACTIVE 상태의 사용자들은 거의 동시에 실제 발급을 시도할 수 있다.
그리고 이 순간에는 결국 같은 쿠폰 자원을 두고 경쟁이 발생한다.

즉, 이제는 질문이 조금 바뀐다.

“ACTIVE로 넘어온 요청들은 DB 안에서 어떻게 안전하게 처리할 것인가?”

처음 떠올린 건 익숙한 동시성 제어 기법들이었다.

7차 문제 해결 방법 1: 비관적 락

비관적 락은 가장 직관적이었다.
먼저 락을 잡고, 다른 요청은 기다리게 만들면 정합성은 강하게 보장할 수 있다.
처음에는 오히려 이 방식이 제일 안전해 보이기도 했다.
“어차피 마지막 발급 단계인데, 확실하게 잠그고 처리하면 되지 않을까?”라는 생각이 들었기 때문이다.

그런데 곰곰이 생각해보니, 비관적 락의 본질은 결국 기다림이었다.

경합이 생기면 뒤의 요청이 다음 발급 가능한 대상을 바로 처리하는 것이 아니라,
앞선 트랜잭션이 락을 놓을 때까지 그대로 기다리게 된다.
즉, 충돌 상황에서 문제를 “없애는” 방식이 아니라,
대기를 통해 순서를 세워 해결하는 방식에 가깝다.

문제는 우리가 이미 앞단에서 WAITING과 ACTIVE를 나눠서,
DB 앞에 너무 많은 요청이 한꺼번에 몰리지 않도록 구조를 바꿔둔 상태였다는 점이다.
그런데 DB 안에서 다시 비관적 락으로 줄을 세우기 시작하면,
앞단에서 힘들게 줄여놓은 경쟁을 마지막 단계에서 또 다른 긴 대기열로 바꾸는 셈이 된다.

특히 선착순 발급에서는 몇 장 남지 않은 상황에서 충돌이 가장 심해진다.
이때 하나의 트랜잭션이 락을 잡고 있는 동안, 뒤의 요청들은 그냥 실패하는 것이 아니라
DB 커넥션을 붙잡은 채 대기하게 된다.
즉, ACTIVE로 넘어온 요청 수를 줄였다고 해도 그 안에서 다시 대기가 길어지면,
커넥션은 빠르게 반환되지 못하고 응답 시간은 점점 길어진다.

이 구조가 무서운 이유는, 비관적 락이 단순히 “한 요청을 잠깐 기다리게 만드는 것”에서 끝나지 않기 때문이다.

대기 중인 트랜잭션은 커넥션을 점유하고, 커넥션이 오래 점유되면 풀은 빠르게 고갈되고, 커넥션을 얻지 못한 뒤 요청들은 애플리케이션 서버에서 다시 대기하고, 그 대기는 다시 스레드 점유와 응답 지연으로 이어진다

즉, 락 경합 하나가 DB 안에서만 머무는 것이 아니라
커넥션 풀 고갈 → 애플리케이션 서버 대기 증가 → 전체 응답 지연으로 이어지는 연쇄 문제로 번질 수 있었다.

여기서 더 걸렸던 건, 비관적 락이 선착순 보장 자체를 깔끔하게 설명해주지도 못한다는 점이었다.

실제 서비스에서는 사용자가 먼저 버튼을 눌렀다는 사실과, 그 요청이 더 먼저 DB 커넥션을 얻고 락 대기열에 진입했다는 사실이 항상 일치하지는 않는다.

요청은 네트워크 지연을 겪고, 로드밸런서를 지나고, 서버에서 스케줄링되고, 커넥션 풀을 기다리는 과정까지 거친다.

즉, 사용자의 체감상 “내가 먼저 눌렀다”와
DB 레벨에서 “내가 먼저 락을 기다리기 시작했다”는 전혀 다른 이야기일 수 있다.

결국 비관적 락은 row 하나의 정합성은 강하게 지켜줄 수 있어도,
우리가 원했던 서비스 전체 관점의 선착순을 자연스럽게 보장해주는 장치는 아니었다.

정리하면, 비관적 락은 안전한 선택처럼 보였지만
실제로는 우리가 이 구조 전체를 통해 줄이고 싶었던 기다림의 비용을 마지막 단계에서 다시 크게 키울 가능성이 있었다.
그리고 그 기다림은 단순한 응답 지연을 넘어,
커넥션 풀 고갈과 전체 시스템 불안정으로 이어질 수 있었다.

7차 문제 해결 방법 2: 낙관적 락

낙관적 락도 처음에는 꽤 괜찮아 보였다.

비관적 락처럼 먼저 row를 붙잡고 기다리게 만드는 방식이 아니라,
일단 읽고 수정한 뒤 충돌이 발생했을 때만 실패로 처리하거나 재시도하면 되기 때문이다.
즉, 락을 오래 잡지 않으니 겉으로 보기에는 더 가볍고, DB 안에서 긴 대기열을 만들지 않는다는 점도 매력적으로 느껴졌다.

특히 우리는 이미 앞단에서 WAITING과 ACTIVE를 나눠 DB로 들어오는 요청 수 자체를 줄여둔 상태였다.
그래서 한때는 “이 정도로 줄여놨다면 낙관적 락으로도 충분하지 않을까?”라는 생각도 했다.
평상시처럼 충돌이 드문 상황이라면, 실제로 이 방식은 꽤 깔끔하게 동작할 수 있다.

하지만 선착순 발급은 낙관적 락이 가장 잘 맞는 상황과는 결이 달랐다.

낙관적 락은 기본적으로 “충돌은 가끔 일어나는 예외적인 상황” 이라는 전제를 깔고 있다.
그런데 선착순 이벤트, 특히 마지막 몇 장을 두고 경쟁하는 구간에서는 충돌이 예외가 아니라 거의 예상된 기본 상황에 가깝다.

예를 들어 ACTIVE 상태의 여러 사용자가 거의 동시에 마지막 쿠폰 몇 장을 두고 발급을 시도한다고 해보자.
이때 먼저 읽은 데이터가 이미 다른 트랜잭션에 의해 바뀌어 있으면,
낙관적 락은 그 요청을 실패시키고 다시 시도하게 만든다.

문제는 이 “다시 시도”가 공짜가 아니라는 점이었다.

한 번 충돌이 나면 끝나는 게 아니라,

다시 읽어야 하고

다시 검증해야 하고

다시 업데이트를 시도해야 한다

즉, 충돌이 많아질수록 요청 하나가 끝날 때까지 거치는 왕복이 늘어난다.
겉으로는 락을 오래 잡지 않아서 가벼워 보이지만,
실제로는 실패와 재시도가 누적되면서 DB에 더 많은 읽기/쓰기 부담을 줄 수 있다.

특히 선착순 이벤트에서는 이 재시도가 더 불편했다.

우리는 앞단에서 힘들게 WAITING과 ACTIVE로 구간을 나눠
DB에 들어오는 경쟁 자체를 줄여놓은 상태였다.
그런데 마지막 단계에서 낙관적 락으로 재시도가 반복되기 시작하면,
앞단에서 줄여놓은 트래픽을 DB 안에서 다시 충돌과 재시도 형태로 되살리는 셈이 된다.

게다가 선착순 관점에서도 마음에 걸리는 지점이 있었다.

낙관적 락은 결국 먼저 성공적으로 커밋한 요청이 이기는 구조에 가깝다.
하지만 사용자의 관점에서 선착순은 “내가 먼저 눌렀는가”에 더 가깝다.

이 둘은 항상 일치하지 않는다.

누군가는 먼저 요청을 보냈더라도 네트워크 지연이나 서버 스케줄링 때문에 재시도가 한 번 더 발생할 수 있고,
반대로 조금 늦게 들어온 요청이 더 빠르게 재시도를 끝내고 먼저 성공할 수도 있다.
즉, 낙관적 락은 정합성은 지킬 수 있어도, 우리가 기대하는 선착순의 체감과는 어긋날 가능성이 있었다.

정리하면, 낙관적 락은
평소처럼 충돌이 적은 상황에서는 가볍고 좋은 선택일 수 있다.
하지만 이번처럼 마지막 순간에 충돌이 집중되는 선착순 이벤트에서는
실패와 재시도가 빠르게 늘어나고, 그 비용이 다시 DB 부담으로 돌아올 수 있었다.

즉, 낙관적 락은
비관적 락처럼 긴 대기를 만들지는 않지만,
대신 충돌을 재시도로 바꿔서 처리하는 방식이었다.
그리고 이번 문제에서는 그 재시도 비용 역시 충분히 부담스러웠다.

7차 문제 해결 방법 3: 원자적 조건 업데이트

원자적 조건 업데이트도 후보였다.
예를 들어 remaining > 0 일 때만 차감하는 방식은 단순하고 빠르다.
비관적 락처럼 기다림을 길게 만들지도 않고, 낙관적 락처럼 실패 후 재시도를 전제로 하지도 않는다는 점에서 꽤 매력적으로 보였다.

하지만 우리 구조를 다시 대입해보니, 이번 문제는 단순한 수량 차감으로만 설명하기 어려웠다.
우리가 정말로 처리해야 했던 것은 remaining 값을 1 줄이는 일이 아니라, 발급 가능한 쿠폰 하나를 특정 사용자에게 확정하는 과정이었기 때문이다.

즉, 원자적 조건 업데이트는
“재고가 남아 있는가”를 판단하고 차감하는 데는 강했지만,
어떤 쿠폰이 누구에게 발급되었는가를 자연스럽게 표현하는 구조와는 조금 결이 달랐다.

결국 이번 문제에는 숫자를 줄이는 방식보다,
실제 발급 가능한 row 하나를 안전하게 가져와 사용자에게 연결하는 방식이 더 잘 맞았다.

7차 문제 해결 방법 4: 스킵 락

스킵 락도 후보였다.
이미 다른 트랜잭션이 잡고 있는 row는 기다리지 않고 건너뛰는 방식이다.

사실 이 방법이 제일 먼저 생갔났고 우리 구조에 대입해보면 가장 잘 맞을 가능성이 커 보였다.

중요한 건 선착순의 질서를 DB에서 처음부터 만들고 있지 않았다는 점이다.
우리는 이미 앞단에서 Redis 대기열을 통해 요청 순서를 정리했고,
WAITING과 ACTIVE로 상태를 나눠서 실제 발급 단계에 들어오는 요청 수까지 줄여둔 상태였다.
즉, DB의 역할은 “누가 먼저인가”를 처음부터 다시 판단하는 것이 아니라,
이미 정리된 경쟁 구간을 빠르게 마무리하는 것에 더 가까웠다.

특히 우리는 쿠폰을 단순한 숫자 재고가 아니라, 미발급 상태의 row 집합으로 보고 있었다.
즉, 실제 발급 시점에는 그중 아직 아무에게도 할당되지 않은 row 하나를 가져와 사용자에게 연결하는 구조였다.

이렇게 보면 문제는 remaining 값을 1 줄이는 것이 아니다.
핵심은 발급 가능한 쿠폰 row 하나를 지금 이 사용자에게 안전하게 확정할 수 있는가였다.

이때 비관적 락처럼 하나의 row 앞에서 기다리게 만들면, 결국 뒤의 요청들은 커넥션을 붙잡은 채 대기하게 된다.
반대로 스킵 락은 이미 다른 트랜잭션이 잡고 있는 row를 기다리지 않고, 다음으로 발급 가능한 row를 바로 찾게 만든다.

즉, 이 방식의 장점은 분명했다.

락은 사용하되 긴 대기를 만들지 않고
여러 트랜잭션이 동시에 들어와도 서로 다른 쿠폰 row를 병렬로 가져갈 수 있고
앞단에서 줄여놓은 ACTIVE 경쟁 구간을 DB 안에서 짧고 빠르게 끝낼 수 있다

결국 스킵 락은
이미 정리된 질서를 DB 안에서 대기 없이 확정하는 도구에 더 가까웠다.

7차 해결 : 결국 스킵 락이 가장 잘 맞았다

여기까지 비교해보니 기준이 조금씩 분명해졌다.

비관적 락은 안전하지만 기다림이 길어진다
낙관적 락은 가볍지만 충돌이 많아지면 실패와 재시도 비용이 커진다
원자적 조건 업데이트는 재고 차감에는 좋지만, 개별 발급 대상을 확정하는 흐름과는 조금 어긋난다

반면 스킵 락은 우리 구조와 잘 맞았다.

여기서 중요한 건 다시 한 번, 선착순의 질서를 DB가 처음부터 만들고 있지 않았다는 점이다.
우리는 이미 Redis 대기열에서 순서를 정리했고, WAITING과 ACTIVE를 나눠 실제 발급 단계로 들어오는 요청 수도 제한해둔 상태였다.
즉, DB의 역할은 “누가 먼저인가”를 다시 판정하는 것이 아니라, 이미 줄어든 경쟁 구간을 빠르게 확정하는 것이었다.

이게 중요했다.

비관적 락처럼 기다리게 만들면 ACTIVE로 들어온 요청들조차 다시 DB 안에서 줄을 서게 된다.
그 기다림은 곧 커넥션 점유 시간 증가로 이어지고, 응답 지연과 풀 고갈 위험도 다시 커진다.
앞단에서 어렵게 줄여놓은 경쟁을 마지막 단계에서 다시 대기열로 바꾸는 셈이다.

반면 스킵 락은 락을 사용하되 대기를 최소화한다.
이미 잠긴 row는 기다리지 않고 건너뛰기 때문에, 여러 트랜잭션이 동시에 들어와도 서로 다른 쿠폰 row를 병렬로 확정할 수 있다.

즉, 우리 구조에서 스킵 락은
선착순의 질서를 만드는 도구라기보다, 이미 정리된 질서를 DB 안에서 빠르게 마무리하는 도구에 더 가까웠다.

물론 이것만으로 모든 문제가 끝나는 것은 아니었다.
같은 사용자가 여러 번 발급을 시도하는 문제는 락만으로 막을 수 없었다.
그래서 마지막 안전장치로 (event_id, member_id) 같은 UNIQUE 제약도 함께 두었다.

정리하면 역할은 이렇게 나뉜다.

WAITING / ACTIVE: 앞단에서 전체 경쟁을 줄인다
SKIP LOCKED: DB 안에서 발급 가능한 쿠폰 row를 빠르게 확정한다
UNIQUE 제약: 같은 사용자의 중복 발급을 마지막으로 차단한다

결국 우리가 원했던 건 모든 요청을 강한 락으로 세워놓는 구조가 아니었다.
앞단에서는 경쟁 자체를 줄이고, DB 안에서는 이미 줄어든 경쟁을 짧고 빠르게 확정하는 구조가 더 잘 맞았다.
그 기준에서 봤을 때, 최종 선택은 스킵 락이 가장 자연스러웠다.

최종 설계

부하테스트

첫 부하 테스트: “짧은 순간의 폭주”를 버틸 수 있는지부터 확인

첫 부하 테스트는 N명의 가상 유저가 한 번씩만 요청을 보내는 방식으로 잡았다.

선착순 이벤트는 일반적인 API처럼 꾸준히 많은 요청이 들어오는 상황과는 조금 다르다.
결국 중요한 건 처음 등록하는 그 순간, 아주 짧은 시간 안에 요청이 한꺼번에 몰렸을 때 버틸 수 있느냐였다.
그래서 테스트도 그 특성에 맞춰, 지속 부하보다는 순간적인 버스트 트래픽을 재현하는 쪽으로 시작했다.

첫 테스트 한계점을 알기위해 일부러 크게 잡아서 가상 유저 5,000명, 서버 2대로 진행했다.

결과는 기대와는 꽤 거리가 있었다.

우선 p90이 5초대로 너무 느렸다.
TPS도 742 수준으로 낮게 나왔다.
또한 연결 구간에서 시간이 꽤 많이 소요되고 있었다.

즉, 단순히 비즈니스 로직만 느린 게 아니라,
연결 자체도 느리고 서버 처리도 느린 상태였다.

일단 비즈니스 로직이 왜 느린지 부터 점검해보았다.

병목 원인 1: 대기열 API가 세션 DB를 타고 있었다

원인을 확인해보니 생각보다 단순하면서도 치명적인 문제가 있었다.

이벤트 API에만 집중하고 있다보니 세션을 생각하지 못했다.

우리 서비스는 분산 서버 환경이라 세션 로그인 방식을 사용하고 있었고,
로그인 세션 정보는 세션 DB에 저장하고 있었다.
즉, 대기열 관련 API를 아주 짧게 조회하는 순간에도
매번 세션 저장소를 거치고 있었던 것이다.

선착순 이벤트에서는 이런 짧은 조회가 매우 자주 일어난다.
그런데 매 요청마다 세션 DB를 한 번씩 건드리고 있었다면,
대기열 API는 시작부터 불필요한 DB 비용을 안고 있었던 셈이다.

결국 대기열 관련 API만큼은 기존 세션 로그인 방식과는 다르게 가져가기로 했다.
즉, 이벤트 API에서 세션 DB 의존을 제거하는 방향으로 바꿨다.

1차 개선 이후: 시간은 절반 가까이 줄었다.

세션 DB를 완전히 제거한 뒤 다시 같은 조건으로 테스트를 해봤다.

확실히 효과는 있었다.
전체 응답 시간은 이전보다 절반 가까이 줄었다.
즉, 처음 병목 중 하나였던 불필요한 DB 접근은 분명히 제거된 것이다.

병목 원인 2: 왕복 횟수

더 개선할 수 있는 방법이 있는지 찾아보다가, 내가 의심한 병목은 복잡한 비즈니스 로직 그 자체보다는 Redis 왕복 횟수였다.

대기열 등록과 조회 요청 하나를 처리하는 동안 Redis에 여러 번 왕복하고 있었고,
오픈 시점처럼 짧은 시간에 요청이 몰리는 상황에서는 이 작은 왕복 비용이 그대로 지연으로 누적될 수 있었다.

결국 핵심은 비즈니스 로직을 바꾸는 것이 아니라,
같은 정보를 더 적은 네트워크 왕복으로 읽도록 바꾸는 것이라고 봤다.

문제: 요청 하나가 Redis를 너무 자주 왕복하고 있었다

대기열 등록 API는 단순히 사용자를 queue에 넣는 작업으로 끝나지 않는다.

요청을 처리하려면 현재 사용자가 어떤 상태인지 먼저 확인해야 한다.

예를 들면 아래 정보들이 필요하다.

이미 발급을 받은 사용자인지
현재 sold out 상태인지
이미 active 상태인지
이미 queue에 들어가 있는지
queue에서 몇 번째인지
active 인원이 몇 명인지
queue 전체 인원이 몇 명인지

기존 구조에서는 이런 상태를 각각 개별 메서드로 조회하는 방식에 가까웠다. 개념적으로는 아래와 같은 형태였다.

long activeCount = getActiveCount(couponName);
boolean issued = isIssued(couponName, memberId);
boolean soldOut = isSoldOut(couponName);
Long activeExpireAt = getActiveExpireAtMillis(couponName, memberId);
Long queueRank = rankQueue(couponName, memberId);
long queueCount = getQueueCount(couponName);

각 메서드는 Redis 기준으로 보면 ZCARD, SISMEMBER, GET, ZSCORE, ZRANK 같은 가벼운 명령이다.

문제는 명령이 무겁다는 것이 아니라, 상태를 잘게 나누어 조회하면서 요청 하나가 Redis와 여러 번 왕복하게 된다는 점이었다.

왜 이게 선착순 이벤트에서 더 치명적일까

선착순 이벤트는 일반적인 CRUD API와 다르다.
사용자가 고르게 들어오지 않고, 아주 짧은 시간에 요청이 한꺼번에 몰린다.

이런 상황에서는 평균 응답시간보다 p95, p99 같은 tail latency가 더 중요해진다.
몇 개의 요청이 조금 느린 정도로 끝나는 것이 아니라, 느려진 요청이 뒤쪽 요청들을 밀어내면서 전체 구간의 체감 성능을 급격히 무너뜨릴 수 있기 때문이다.

단건 요청만 보면 Redis 왕복 한두 번 차이는 작아 보일 수 있다.
한 번 조회하는 데 걸리는 시간 자체는 짧고, 로컬 캐시나 메모리 접근과 비교하지 않는 이상 충분히 빠른 편이기도 하다.

하지만 선착순 이벤트처럼 같은 시점에 수천, 수만 건의 요청이 몰리면 이야기가 달라진다.

요청 하나가 Redis를 여러 번 오갈수록 다음과 같은 문제가 생긴다.

네트워크 왕복 횟수 자체가 늘어난다.
Redis 커넥션을 점유하는 시간이 길어진다.
애플리케이션 스레드가 응답을 기다리는 시간도 함께 늘어난다.
그 결과 동시에 처리할 수 있는 요청 수가 줄어든다.
밀린 요청들은 다시 tail latency를 키운다.

특히 선착순 이벤트에서는 이 문제가 더 치명적이다.
이벤트 시작 직후에는 모든 사용자가 거의 동시에 상태를 확인하려고 들어온다.
이때 요청 하나당 Redis 왕복이 1번인 구조와 3번인 구조는, 같은 트래픽이라도 Redis와 애플리케이션이 감당해야 하는 총 작업량이 완전히 달라진다.

예를 들어 초당 5,000개의 요청이 들어오는 상황이라면,
요청당 Redis 왕복이 1번일 때는 초당 5,000번의 왕복이 발생하지만
요청당 3번 왕복하면 초당 15,000번의 왕복이 필요해진다.

이 차이는 단순히 2번 더 조회했다에서 끝나지 않는다.
커넥션 풀 경쟁, 스레드 대기, 응답 지연, 재시도 증가까지 연쇄적으로 이어질 수 있다.
그리고 선착순 시스템에서는 바로 이런 작은 지연이 공정성 문제와 실패율 증가로 이어진다.

결국 이 구간에서는
조회 한 번이 얼마나 빠른가보다
요청 하나를 끝내기 위해 Redis를 몇 번 오가야 하는가가 더 중요하다고 봤다.

개선 방향: 상태 조회를 pipeline으로 묶자

이 문제를 해결하기 위해 상태 조회를 의미 단위로 묶었다.

public QueuePreState getQueuePreState(String couponName, Long memberId) {
    List<Object> results = redisTemplate.executePipelined(
            new SessionCallback<Object>() {
                @Override
                public Object execute(RedisOperations operations) {
                    operations.opsForZSet().zCard(activeKey(couponName));
                    operations.opsForSet().isMember(issuedKey(couponName), memberId.toString());
                    operations.opsForValue().get(soldOutKey(couponName));
                    operations.opsForZSet().score(activeKey(couponName), memberId.toString());
                    operations.opsForZSet().rank(queueKey(couponName), memberId.toString());
                    operations.opsForZSet().zCard(queueKey(couponName));
                    return null;
                }
            }
    );

    long activeCount = asLong(results.get(0));
    boolean isIssued = asBoolean(results.get(1));
    boolean isSoldOut = "1".equals(asText(results.get(2)));
    Long activeExpireAt = asLong(results.get(3));
    Long rank = asLong(results.get(4));
    long queueCount = asLong(results.get(5));

    return new QueuePreState(activeCount, isIssued, isSoldOut, activeExpireAt, rank, queueCount);
}

핵심은 조회하는 값이 줄어든 게 아니었다.
같은 조회를 더 적은 왕복으로 처리하게 바꿨다는 점이 중요했다.

이전 방식이 아래와 같았다면,

질문 1 -> 응답
질문 2 -> 응답
질문 3 -> 응답
질문 4 -> 응답
질문 5 -> 응답
질문 6 -> 응답

지금 방식은 이렇게 바뀐 셈이다.

질문 1,2,3,4,5,6 한 번에 전송 -> 결과 한 번에 수신

즉 이번 개선의 본질은 "상태를 덜 읽는 것"이 아니라, "같은 상태를 덜 왕복하며 읽는 것"이었다.

2차 개선 이후

실제 5,000 VU 기준 부하 테스트에서도 응답 지표 개선이 확인됐다.

개선 전에는 처리량이 516 req/s 수준이었고, 평균 응답시간은 3.02s 정도였다.
Redis 왕복을 줄인 이후에는 처리량이 871 req/s 수준까지 올라갔고, 평균 응답시간도 2.26s 정도로 줄어들었다.

즉, 같은 구조 안에서 요청당 Redis 왕복 패턴만 줄였는데도 처리량과 응답시간이 모두 눈에 띄게 좋아졌다.

Redis 왕복 최적화가 직접 줄이는 것은 요청 내부의 상태 조회 오버헤드다.
그리고 그 변화가 누적되면서

요청당 Redis 대기 시간 감소
동시 요청 시 커넥션 점유 시간 감소
애플리케이션 스레드 대기 감소
burst 상황에서의 tail latency 완화
결과적으로 처리량 증가

로 이어질 수 있었다.

물론 여기서 조심할 점도 있다.
모든 지표 개선을 Redis 최적화 하나만의 효과로 단정할 수는 없다.
실제 부하 테스트에는 연결 상태, 스레드 상태, 서버 부하 등 여러 요소가 함께 영향을 준다.

다만 적어도 이번 테스트는 한 가지는 분명히 보여줬다.

선착순 이벤트에서는 Redis가 빠르다는 사실만으로는 부족하고, Redis를 어떤 패턴으로 읽고 쓰느냐가 전체 응답 성능에 직접적인 영향을 준다는 점이다.

본격적인 부하 테스트: 현재 구조에서 어디까지 버틸 수 있는가

이후에는 1분 동안 일정한 TPS를 유지하는 방식으로 테스트를 진행했다.
조건은 다음과 같았다.

서버 2대
톰캣 스레드 MAX 150개
목표 TPS를 점진적으로 올려가며 측정

TPS 2,000

이 구간에서는 꽤 안정적이었다.

p90 33.85ms

응답 시간도 충분히 짧았고 CPU도 3%이하로 사용했다.
현재 구조로는 이 정도 트래픽까지는 큰 무리 없이 처리할 수 있겠다는 느낌이 들었다.

즉, 최소한 2,000 TPS 구간은 안정권으로 볼 수 있었다.

TPS 2,500

다음으로 TPS 2,500을 시도했다.

여기서부터는 분위기가 달라졌다.

ㄱ

p90 345.62ms

불과 500 TPS 차이인데도,
p90 응답 시간은 거의 10배 이상 느려졌다.

CPU 사용률도 20%로 확 뛰었다.

평균값만 보면 아직 버티는 것처럼 보일 수 있지만,
상위 구간 응답 시간이 급격히 튀기 시작했다는 건
시스템이 슬슬 여유를 잃고 있다는 뜻에 더 가깝다.

즉, TPS 2,500부터는 “된다”가 아니라 “버티긴 버티지만 힘들어한다”는 느낌이 강했다.

TPS 2,800

마지막으로 TPS 2,800도 시도해봤다.

P90 2.26s

결과적으로는 목표한 2,800 TPS를 온전히 처리하지 못했고,
실제 처리량은 약 2,600 TPS 수준에서 수렴했다.

이 구간에서는 응답 시간도 크게 늘었고,
드롭된 요청도 발생하기 시작했다.
Load Average 역시 올라가면서,
이제는 시스템이 명확하게 포화 구간에 들어섰다는 게 보였다.

CPU 사용률도 50%에 육박했다.

즉, 이 테스트는 꽤 명확했다.

지금 구조에서의 한계는 2,600 TPS 전후로 보였고,
안정적으로 운영 가능한 구간은 2,200TPS 정도였다.

정리: 현재 서버 2대 기준 안정권은 약 2,100 TPS 수준으로 봤다

결과를 종합해보면 이렇다.

2,000 TPS: 안정적
2,500 TPS: 응답 지연이 눈에 띄게 커지기 시작
2,800 TPS 시도: 실제 처리량은 2,600 TPS 수준에서 한계

즉, 현재 서버 2대 구성에서는
약 2,200 TPS 전후가 현실적인 안정권이라고 판단했다.

2,500 TPS부터는 분명히 버거워하는 신호가 보였고,
2,800 TPS에서는 사실상 한계가 드러났다.
이 이상으로 밀어붙이면 “된다”기보다
언제든 흔들릴 수 있는 구간에 가깝다고 봤다.

여기서 조금 더 개선해볼 수 있을까해서 몇 가지 더 고민해보았다.

1. 스레드 설정

가장 먼저 본 건 스레드였다.
순간적으로 요청이 확 몰리는 구조다 보니, 처음에는 스레드 수가 부족해서 병목이 생기는 것 아닐까 싶었다.

그런데 지표를 같이 보면 조금 다르게 보였다.
TPS를 올릴수록 CPU 사용률이 같이 올라가고, 동시에 p90 / p95도 함께 나빠졌다.

즉, 단순히 “스레드가 부족해서 대기만 늘어나는 상황”이라기보다,
서버 한 대가 실제로 감당할 수 있는 처리 한계에 가까워지고 있었다고 보는 편이 더 자연스러웠다.

스레드 문제가 핵심이라면 CPU는 상대적으로 덜 쓰면서 대기만 길어지는 그림이 먼저 보일 수도 있는데,
지금은 처리량이 올라갈수록 CPU와 응답 지표가 함께 무너지는 쪽에 가까웠다.

그래서 이 시점에서는 스레드 수를 무작정 늘리는 것이 근본적인 해결책은 아닐 수 있다고 판단했다.
오히려 그 경우, 더 많은 요청을 동시에 붙잡고 있다가 tail latency만 더 나빠질 가능성도 있었다.

실제로 더 높여보았는데 훨씬 더 성능이 안 좋아졌다.

스레드 max를 170으로 20을 더 높여보았는데 p90/p95는 폭증하고 CPU도 사용률이 10% 더 늘었다.

2. Redis 쪽도 더 줄일 수 있는지 다시 봤다

다음으로는 Redis 쪽을 다시 봤다.

혹시 요청당 Redis 명령이 불필요하게 많지는 않은지,
조금이라도 더 줄일 수 있는 부분이 없는지 다시 점검했다.

하지만 이미 Redis 쪽은 꽤 단순하게 가져간 상태였다.
필요한 최소한의 명령만 사용하고 있었고, 구조적으로도 더 크게 덜어낼 만한 부분은 많지 않았다.

즉, 애플리케이션 레벨에서 줄일 수 있는 비용은 이미 한 번 많이 걷어낸 상태였고,
여기서 추가 최적화를 한다고 해도 TPS를 큰 폭으로 더 끌어올릴 수 있을 만큼의 여지는 크지 않아 보였다.

결론

스레드도 먼저 의심해봤고,
Redis 쪽도 다시 점검해봤지만,
결국 지금 한계는 코드 몇 줄 더 줄이거나 설정 하나 바꾼다고 해결될 문제라기보다, 서버 한 대가 감당할 수 있는 물리적인 처리량에 가까워 보였다.

즉, 이 시점에서 더 안정적으로 TPS를 올리려면 수평 확장 쪽으로 가는 것이 가장 현실적인 선택지에 가까웠다.

한 대가 감당해야 하는 TPS를 낮추고, 같은 구조를 여러 대로 분산해서 받는 것.
적어도 현재 테스트 결과만 놓고 보면, 그게 가장 직접적이고 예측 가능한 다음 단계였다.

실제 이벤트에서는 ?

봄봄 선착순 이벤트는 2026년 2월 23일 오후 2시에 진행되었다.

다행히 아무 문제 없이 무사히 잘 마쳤다.

예상보다는 많이 적지만 총 179+분 정도가 참여해주셨고 피크 5분간 총 요청은 9k, 피크 RPM 550, p90 67ms, 에러 0건으로 잘 마무리 될 수 있었다.

성과로는 회원수 300+이 늘었다.

설날도 반납하면서 3주간 열심히 고민하고 기획/설계/구현을 했는데 큰 문제없이 마무리되어서 다행이다.

구현하면서 생각할것도 많아서 배워가는 것도 참 많은 기회였다.

(이벤트 구현도 중요하지말 알리는게 더 어렵다는걸 이번에 알게되었다)

Reference

봄봄 코드 리뷰 문화 개선

개발자성장기 — Tue, 23 Dec 2025 09:44:13 +0900

솔직히 말해볼게요. 코드 리뷰, 다들 좋은 거 알잖아요? 하지만 가끔은 슬랙 알림에 뜬 [PR] 글자만 봐도 "아, 조금만 있다가 볼까..." 하고 창을 닫게 되는 순간이 있죠.

저에게 코드 리뷰는 단순히 '오타 찾기'나 '버그 검수'가 아니에요. 우리 팀이 어떤 코드를 '좋은 코드'라고 정의하는지, 이 복잡한 문제를 어떤 로직으로 풀어냈는지 서로의 머릿속을 동기화하는 가장 찐한 협업의 시간이라고 생각하거든요. 그래서 우리 팀은 "무조건 리뷰 후 머지"라는 꽤 깐깐한 원칙을 고수해왔고, 실제로 그 덕분에 대형 사고를 막거나 설계가 훨씬 단단해지는 짜릿한 경험도 꽤 했습니다.

그런데 팀이 프로젝트가 커져가며 바빠지니 문제가 생기더라고요.

리뷰가 '즐거운 대화'가 아니라 '밀린 숙제'가 되어버린 거죠. 쌓여있는 PR은 누군가에겐 압박이 되고, 누군가에겐 긴 기다림이 됩니다. 꼼꼼하게 보자니 진도가 안 나가고, 대충 하자니 찝찝한 그 미묘한 상황. 좋은 의도로 만든 시스템이 어느새 팀의 발목을 잡는 '병목'이 된 거예요.

여기서 제가 내린 결론은 하나였습니다. "사람들을 더 채찍질하지 말자." 리뷰가 늦어지는 건 팀원들의 성실함 문제가 아니라, 리뷰를 하기 힘들게 만드는 '운영의 문제'였거든요. 초반에는 "리뷰 좀 빨리해주세요"라고 서로 독촉하면서 다녔는데 이제는 리뷰어가 '딱 5분만 써도 충분히 맥락을 파악할 수 있는 환경'을 만드는 데 집중했습니다.

그렇게 바꾸고 나니 변화가 숫자로도 보이더라고요. 평균 리드 타임이 3~6일에서 1~2일 이내로 줄었습니다.

어떻게 하면 리뷰어가 길을 잃지 않게 할지, 불필요한 알림 지옥에서 어떻게 탈출했는지—저희 팀의 시행착오 끝에 정착한 '지속 가능한 코드 리뷰 운영법'을 공유합니다.

1. 문제의 시작

프로젝트를 진행하며 공통적으로 느낀 문제가 있었다.

어떤 PR은 사소한 코멘트로 논의가 길어지고
중요한 변경이 들어간 PR은 늦게 발견되거나 묻히고
리뷰 요청이 제대로 인지되지 않아 며칠씩 대기하는 상황이 발생했다

처음에는 개인의 리뷰 성향 문제라고 생각했다.
“누구는 꼼꼼하고, 누구는 빠르다” 정도로 인식했다.

하지만 PR 수가 늘어날수록 확신이 들었다.

결국 더 열심히 하자는 방식엔 한계가 있었다.
같은 노력으로도 리뷰가 더 잘 굴러가게 만드는 구조를 손봐야겠다고 느꼈다.

2. 문제 정의

팀원들과 리뷰 상황을 정리해보며, 문제를 세 가지로 정리했다.

1) 리뷰 코멘트의 중요도 기준이 제각각

필수 수정인지, 제안인지 구분되지 않음
“이건 꼭 반영해야 하나요?” 같은 질문이 반복
논의가 길어지고 PR 처리 속도가 들쭉날쭉해짐

2) PR에 맥락이 충분히 남지 않음

왜 이 변경을 했는지
다른 선택지는 무엇이었는지
비즈니스적인 요소와 어떤 연관관계가 있는지
단순히 코드 컨벤션이나 코드 구조에 대해서만 리뷰하게 됨
전체적인 그림으로 리뷰하기 위해서는 리뷰할 사람이 따로 찾아봐야 하는게 많았음

3) 리뷰 요청이 묻히는 구조

GitHub 알림은 많지만 중요 이벤트가 섞여 있음
Discord 알림은 노이즈가 많아 점점 무시됨
결과적으로 리뷰 누락·지연 발생

3. “빨리”가 아니라 “덜 소모되게 하자”

여기서 중요한 합의가 필요했다.

목표는 리뷰를 대충 빠르게가 아니라
리뷰 품질을 유지하면서도 예측 가능한 속도를 만드는 것

이를 위해 개인의 책임을 늘리는 대신, 팀 전체의 기준과 흐름을 정리하는 방향을 선택했다.

4. 해결 방법

1) 리뷰 코멘트의 언어를 통일하다 (Pn 규칙)

우리 팀은 평소 대화할 때는 말뿐 아니라 표정, 톤, 손짓 같은 비언어적 신호로 “이 얘기가 얼마나 진지한지”, “급한 건지”, “그냥 아이디어인지”를 함께 전달한다.

그런데 코드 리뷰는 대부분 텍스트로만 진행되다 보니, 의도와 뉘앙스가 쉽게 빠진다.

가볍게 던진 코멘트가 예상보다 날카롭게 읽히거나, 꼭 반영돼야 하는 지점이 “참고” 정도로 받아들여져서 서로 같은 내용을 반복 설명하게 되기도 한다.

결국 리뷰가 길어지고, 감정 소모가 생기고, 때로는 PR 흐름 자체가 멈추는 상황까지 이어질 수 있다.

그래서 우리는 뱅크샐러드에서 만든 룰을 통해 리뷰 코멘트의 중요도를 명확히 표현하기로 했다.

해당 룰은 우테코 프리코스를 할 때 처음 사용해보았는데 커뮤니케이션 비용이 많이 줄었다.

뱅샐 블로그 글을 보면 아래와 같이 쓰여 있다.

커뮤니케이션 비용을 줄이기 위한 Pn 룰

뱅크샐러드 기술 조직은 코드 리뷰의 코멘트에 Pn 룰을 사용하여 리뷰어가 코멘트를 강조하고 싶은 정도를 표현합니다.

P1: 꼭 반영해주세요 (Request changes)
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

P2: 적극적으로 고려해주세요 (Request changes)
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

P3: 웬만하면 반영해 주세요 (Comment)
작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

P5: 그냥 사소한 의견입니다 (Approve)
작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
FYI) Pn 룰은 뱅크샐러드에서 성장하는 회사에서 커뮤니케이션은 가장 큰 비용이라는 문제의식에서 이를 해결하기 위한 문화를 배경으로 탄생했습니다. Pn 룰은 코드 리뷰 외에도 슬랙 등 텍스트로 커뮤니케이션을 하는 곳에서도 활용하고 있습니다

위와 같이 p3면 comment이기 때문에 반영할 수 없거나 다음에 반영할 계획을 명시적으로 표현을 하면된다.

확실히 이렇게 앞에 pn을 작성하면

불필요한 감정 소모 감소가 감소하고 논의 포인트가 명확해진다. 또한 리뷰어도 “어디까지 개입해야 하는지” 판단이 쉬워진다.

2) PR의 시급성을 명확히 드러내다 (D-n 룰)

이 룰을 도입하기 전에는 코드 리뷰를 시간 순서대로 하거나 변경이 적은 PR 부터 했다.

얼마나 시급한지를 단순히 PR 목록만 봐서는 알 수 없었다.

엄청 시급하면 해당 크루가 구두로 말하거나 전체를 태그해서 빠르게 코드리뷰를 요청하는 경우가 종종 발생했다.

그래서 어떻게 해결하지 하다가 D-n룰이란걸 알게되었다.

D-n 룰은 리뷰를 요청하는 시점에 PR이 Merge 되어야 하는 일정을 공유하여 리뷰어가 Working day 안에서 스스로 우선순위를 결정한다.

이 규칙의 핵심은 “압박”이 아니라 정렬이었다.

리뷰어가 맥락을 읽기 전에 이 PR을 언제까지 보면 되는지 바로 알 수 있도록 하는 것이다.

확실히 이를 도입하고 나서 우선순위에 따라 더 빠르게 처리할 수 있었다.

D-n 라벨 자동 조정

그런데 며칠 지나니, 작은 문제가 보이기 시작했다.
라벨은 시간이 지나도 그대로 고정된다는 점이다.

예를 들어 D-5를 붙여두면, 5일이 지나도 여전히 D-5다.
리뷰어는 결국 PR 생성일을 다시 보고 “오늘 기준으로 며칠 남았지?”를 계산해야 했다.

이 불편함을 그냥 남겨놓으면 D-n룰을 잘 활용하지 않을 것 같았고 또 다른 불편함을 초래할 것 같았다.
내가 룰을 도입했으니, 끝까지 쓰이게 만드는 것도 내 몫이라고 봤다.
그래서 라벨을 사람이 관리하지 않도록, 자동으로 굴러가게 만들기로 했다.

어떻게 하면 할 수 있을까 찾아보다가 GitHub Actions에서 스케줄러를 지원하는 것을 알게되었다.
GitHub Actions는 cron 기반 실행을 지원하니, 매일 아침 10시에 워크플로우를 돌려서

열려 있는 PR 목록을 조회하고
D-n 라벨을 하루마다 -1씩 자동 조정하고
D-0에 도달하면 디스코드로 알림을 보낸다

그런데 여기에 디테일을 조금 더 넣었다.

D-0 알림은 “그냥 PR 링크 던지기”에서 끝내지 않았다.
D-0이 된 PR마다 리뷰 상태를 다시 조회해서, 지금 누구를 깨워야 하는지를 자동으로 판단하게 했다.

승인 수(approvedCount)와 수정 요청 여부(hasChangesRequested)를 기준으로 멘션 대상을 고른다.
- 수정 요청이 있으면 작성자를 먼저 멘션(수정이 필요하니까)
- 승인 2명 미만이면 아직 승인하지 않은 리뷰어들을 멘션(단, 작성자는 후보에서 제외)
- 승인 2명 이상이면 작성자를 멘션(이제 merge가 가능하니까)
멘션은 중복 호출이 생기지 않도록 Set으로 한번 더 정리한다.

이제 리뷰어는 PR을 열어보기 전에, 라벨만 보고 “오늘 처리할 건지”를 바로 판단한다.
남은 기간을 계산하기 위해 누군가가 기억하고 챙길 필요도 없다.

사람의 기억 대신, 시스템에 맡겼다.

3) 맥락을 남기는 PR

코드 리뷰가 지연될 때 흔히 “PR 템플릿을 만들자”는 해결책이 나온다.

나도 처음엔 그 방법을 떠올렸다.

하지만 여러 번의 협업 경험을 돌아보니, 리뷰가 느려지는 핵심 원인은 템플릿 유무가 아니라

리뷰어가 PR을 이해하기 위해 치르는 ‘맥락 로딩 비용’이었다.

변경된 코드는 있는데 “왜 바꿨는지, 어떤 대안을 고민했는지, 어떻게 검증했는지, 비즈니스 요구사항이 뭔지”가 PR에 남아 있지 않으면

리뷰는 코드 컨벤션이나 코드 구조에 대해서만 리뷰하게 된다.

전체 그림으로 리뷰를 하거나 딥하게 하기 위해서는 직접 코드를 작성한 사람에게 질문을 하거나 PR외 추가적으로 정보를 찾는 비용이 발생된다.

이런식으로 논의가 길어지고, 정보를 찾는데 시간이 걸리기에 리뷰가 뒤로 밀리며, PR 처리 속도가 느려지기 시작한다.

그래서 형식적인 PR 템플릿을 강제하는 대신, PR을 리뷰할 사람이 따로 찾아봐야하는 일이 거의 없도록 상세하게 쓰는 습관을 팀에 정착시키는 방향을 선택했다.

얼마전 향로님 블로그를 보다가 이와 관련된 코멘트를 발견했다.

요즘들어 개선되고 있기는 한데 우리팀에 있어서 조금 부족한 부분이었다.

사실 PR을 자세히 쓰는것은 상당한 비용이 들어가고 귀찮기도 하다.

하지만 나로인해 리뷰어들은 시간을 엄청 세이브 할 수 있고 코드 리뷰의 질도 높일 수 있다.

그 결과 품질이 높은 코드로 이어질 확률이 높고 이는 결국 유지보수성을 올려주고 버그를 줄여줄 수 있는 효과를 가져올 수 있다.

여기에 추가적으로, 실제로 도움이 많이 되었던 것은 PR에 ‘리뷰 포인트’를 한 줄로 미리 열어두는 습관이었다. 예를 들어 “동시성 관점에서 이 변경이 안전한지 확인 부탁드립니다”, “이 선택(설계/쿼리/API 응답)이 팀 컨벤션에 맞는지 의견이 필요합니다”처럼, 리뷰어가 어디를 중점적으로 보면 좋을지 작성자가 먼저 제시하는 방식이다. 이 한 줄이 있으면 리뷰어는 PR을 열자마자 ‘읽는 방향’을 잡고, 코멘트는 스타일 지적에서 벗어나 의사결정·설계 논의로 이동한다. 결과적으로 리뷰 품질은 유지되면서도 속도는 훨씬 안정적으로 나왔다.

이 문화를 정착시키는 과정에서 내가 중요하게 본 건 “규칙을 공지하는 것"도 있지만 던 신경쓴 것은 운영으로 습관이 퍼지게 만드는 것이었다. 누군가에게 요구하기 전에 내가 먼저 모든 PR에서 맥락을 남기고, 리뷰 포인트를 적고, 좋은 사례가 나오면 “이 PR은 맥락이 좋아서 리뷰가 쉬웠다”처럼 공개적으로 피드백했다.

반대로 부담을 늘리는 방식은 피했다. 완벽한 문서를 쓰게 하는 게 목표가 아니라, “리뷰어가 다시 묻지 않게 만들 정도의 설명”만 남기면 충분하다고 계속 강조했다. 그 결과, 반복 질문이 줄고 리뷰가 미뤄지는 빈도가 감소했으며 평균 리뷰 리드타임이 3~6일에서 1~2일 이내로 단축됐다. 무엇보다 리뷰가 ‘지적받는 자리’가 아니라 ‘생각을 맞추는 과정’으로 인식되기 시작했고, 이는 팀의 협업 피로도를 눈에 띄게 낮췄다.

4) “알림”이 아니라 “주의(Attention)”를 운영하기

리뷰 문화가 아무리 좋아져도, PR이 제때 보이지 않으면 결국 병목이 된다.

실제로 우리 팀에서 리뷰 누락·지연이 발생하던 이유 중 하나는 “사람들이 게을러서”가 아니라 알림이 너무 많아 중요한 신호가 묻히는 구조였다.

GitHub 알림은 기본적으로 촘촘하지만, PR이 늘어나면 이벤트가 쏟아지고(코멘트, 업데이트, 라벨, 머지 시도 등) 사람은 결국 노이즈를 무시하게 된다. 이 상태가 되면 가장 중요한 순간인 “리뷰 요청”조차 지나가 버린다.

기존에 쓰던 PR 알림은 너무 이벤트가 많았다.

그러다 보니 어느순간 나조차도 이 알림을 무시하기 시작했다.

왜 이렇게 알림이 많이 오는 걸까?

깃허브가 제공해주는 웹훅 설정을 보면 그 이유를 알 수 있다.

PR관련 거의 모든 이벤트를 감지해서 알림을 보내게된다.

물론 Pull request reviews, pull request review comments 같은게 있긴한데 필요한 많은 부분이 pull requests에 선물꾸러미처럼 한꺼번에 다 담겨있다.

결국 우리 입맛에 맞게 커스터마이징을 해야한다.

핵심 질문은 단순했다.

“팀이 지금 당장 주의를 써야 하는 순간은 언제인가?”

나는 GitHub의 수많은 이벤트 중에서, 리뷰 흐름을 실제로 움직이는 이벤트만 남겼다.

PR Open: 새 작업이 시작됐음을 알려야 하는 순간
Review Request / Re-request: 누군가의 행동(리뷰)이 필요하다는 신호
Approve: 병목이 풀렸고 다음 단계(머지/배포)로 넘어갈 수 있다는 신호

그리고 이 이벤트들을 기준으로 Discord 알림을 상황별로 다르게 설계했다.

1) PR Open

PR 생성에서는 리뷰어를 멘션을 걸고 제목, 작성자 D-n룰만 보이도록 적용했다.

그래서 리뷰어가 제목으로 어떤 pr인지 알 수 있고 D-n룰을 보고 시급성을 알 수 있도록 했다.

처음에는 내용도 포함하려고 했으나 길어져서 다른 알림이 묻힐 수 도 있다고 생각해서 과감하게 제거했다.

2) PR Request

리뷰 재요청을 재요청을 받을 당사자면 멘션되게 했습니다.

3) Request Change

리뷰 이벤트 중에서 가장 우선순위가 높은 알림은 Request changes였다.
이건 단순한 진행 상황 공유가 아니라, 작성자가 다음 액션을 해야 PR이 앞으로 갈 수 있는 상태가 되기 때문이다.

그래서 Request changes 알림은 다음 원칙으로 설계했다.

멘션 대상은 PR 작성자(Author)만
리뷰어 전체를 흔드는 순간 노이즈가 되기 쉽다.
“이 PR은 작성자가 수정해야 진행된다”라는 메시지이기 때문에, 작성자만 콕 집어 멘션하는 편이 효과가 컸다.
알림 본문은 ‘한 번에 파악’ 가능하게
PR 링크/제목 + 변경 요청자 + 핵심 코멘트 위치(리뷰 링크) 정도만 넣고,
“지금 뭐 해야 하지?”가 바로 보이도록 만들었다.

4) Approve

Approve 알림은 반대로, 너무 자주 울리면 가치가 급격히 떨어졌다.
한 PR에 승인 리뷰가 여러 번 달릴 수 있고, 팀 규모가 커질수록 “승인 알림 폭탄”이 되기 쉽다.

그래서 승인 알림은 내부 기준으로 merge 가능한 숫자에 도달하면 알림을 보내도록 설정했다.

이 작업은 단순한 자동화가 아니었다.
나는 알림을 “정보를 전달하는 기능”이 아니라, 팀의 주의를 어디에 쓰게 할지 결정하는 운영 설계로 봤다.

이 구조가 자리 잡으면서 리뷰 요청이 묻히거나 지나가는 일이 줄었고, “봤는데 놓쳤다” 같은 상황도 눈에 띄게 감소했다. 리뷰가 더 빨라졌다는 사실보다, 리뷰가 안정적으로 돌아가기 시작했다는 게 더 큰 변화였다.

이번 개선의 핵심은 자동화나 규칙 그 자체가 아니라, 팀의 시간을 덜 낭비하게 만드는 방식이었다. 맥락이 남는 PR은 리뷰어의 추측을 줄이고, 이벤트 기반 알림은 팀의 주의를 흩뜨리지 않는다. 결국 협업 문제는 “누가 더 잘하느냐”보다, 덜 흔들리게 만드는 구조가 있느냐에 더 가깝다.

나는 앞으로도 개인의 역량으로 버티는 방식보다, 팀이 지속 가능하게 굴러가는 시스템을 설계하는 쪽에 집중하려 한다. 리뷰가 편해지면 속도는 따라오고, 속도가 안정되면 품질을 논의할 여유가 생긴다.

그리고 팀 규모가 더 커진다면, 한 리뷰에 모든 사람이 매달리지 않도록 리뷰 참여를 설계하는 방식도 고민해보고 싶다. 메타가 공유한 “코드 리뷰 시간을 개선한 방식”은 그 다음 단계에서 충분히 참고할 만한 사례라고 생각한다.

Reference

이메일 수신 서버 구축 및 뉴스레터 적재 파이프라인 고도화

개발자성장기 — Sun, 14 Dec 2025 17:52:38 +0900

노션에 정리해놓았다가 드디어 블로그로 옮기는 작업을 하고 있다.

이번에 쓰는 글을 우리 서비스의 핵심기능인 이메일 서버관련 글이다.

먼저 우리 서비스가 모르시는 분이 있을 수도 있는데 이 서비스를 만든 가장 큰 이유 중 하나

즉 페인포인트는 여러 메일이 섞인다는 것이다.

먼저 예시를 보자

위 이미지는 제 받은메일함입니다.

메일 종류를 보면 결제 내역, 뉴스레터, facebook, github 등등 뒤죽박죽 섞여있습니다.

이를 정리하기 위해 메일함을 만들어서 분류하기도 귀찮습니다.

그렇다고 뉴스레터 전용 이메일을 만든다? 뉴스레터 이메일 갔다가 다시 원래 이메일 갔다가 하기가 번거롭다.

여기

현재 서비스를 보면 이렇게 이메일이 도착하면 오늘의 뉴스레터 페이지에서 볼 수 있다.

이 화면을 보여주면 크루들은 이렇게 말한다

"이거 어디서 긁어오는거야?"

"크롤링 해도 괜찮아??"

그럼 이렇게 대답한다.

"이거 이메일 서버를 통해서 직접 이메일 받을 거야!!"

그렇다면 이제부터 이메일서버가 왜 필요했는지? 어떻게 구축했는지에 대해서 알아보자 ㅎㅎ

뉴스레터는 크롤링 같은걸 해오는게 아니다 이것도 하나의 저작권으로 인정되기 때문에 우리가 함부로 가져올 수가 없다.

우리 서비스는 그대로 보여주기 때문에 공정사용에 해당하지 않는다.

따라서 누구나와서 볼 수 있게 하면 불법이 된다.

오직 뉴스레터를 신청한 당사자만 메일을 통해서 볼 수 있다.

그렇기에 우리서비스는 로그인이 필수이고 이메일을 받을 수 있어야 했다.

기존의 이메일은 이렇게 더럽다.

이게 너무 불편했다. 또 가끔은 이렇게 스팸메일함에 들어가있다.

지메일 같은 경우는 아래의 설정을 해줘 스팸으로 오지 않는다

그래서 뉴스레터만 받을 수 있는 앱이 있으면 어떨까 생각이 들었다.

이렇게 하려면 이메일을 받아야했다.

첫 번째 시도: Gmail API로 뉴스레터 긁어오기

이전에 했던 작은 사이드 프로젝트에서는 인프라 구축에 익숙하지 않았고 여러가지 방법도 잘 찾아보지 않았다.

그 당시 조사했던 방법은 딱 두 가지였다. Gmail API를 통해 활용하는 것 이메일 서버를 구축하는 것

이 당시 인프라 구축에 익숙하지 않았고 비용을 최대한 아끼기 위해 돈의 거의 들지 않는 Gmail API로 부턱대고 시작했다.

Google Gmail API를 이용해서 다음과 같은 구조로 만들었다.

1. 유저가 OAuth로 우리 서비스에 Gmail 접근 권한을 준다.

2. 우리가 유저의 Gmail에 들어가서 뉴스레터 메일만 골라 읽고

4. 그 내용을 파싱해서 DB에 저장한다.

처음에는 꽤 그럴듯해 보였다.

사용자는 기존 이메일 주소를 그대로 쓰면 되고 우리는 권한만 받아서 필요한 뉴스레터만 읽으면 되니 별도 메일 서버를 운영하지 않다도 됐다.

실제로도 잘 동작했다.

하지만 엄청난 문제가 있었다.

신규회원가입을 하려면 화면이 아래와 같이 뜬다.

원인은 바로 CASA다

Gmail 본문을 읽으려면 넘어야 하는 벽, CASA

구글은 요즘, Gmail 같은 민감한 사용자 데이터에 접근하는 앱에 대해
보안 검증을 굉장히 강하게 요구하고 있다.

그 중심에 있는 제도가 바로 CASA (Cloud Application Security Assessment)다.

요약하면 이런 제도다.

“너희 앱이 사용자 데이터를 안전하게 다루는지,
제3의 보안 기관이 공식적으로 확인해주는 인증 제도”

특히 Gmail 본문을 읽는 권한 같은 걸 쓰려면,
그냥 “우리가 잘 할게요” 수준으로는 안 되고,
Tier 2 이상의 CASA 인증을 요구한다.

CASA Tier 간단 정리

Tier 1 – 개발자가 체크리스트를 보고 셀프 점검하는 단계 (무료)
Tier 2 – 공인 보안 실험실에서 코드/구성 자동 분석 + 검증
Tier 3 – 인프라, 네트워크, 데이터 저장 방식까지 포함한 풀 보안 감사

문제는 비용이다.

Tier 1: 무료
Tier 2: 수백만원
Tier 3: 수천만원

즉, 작은 팀이나 사이드 프로젝트 입장에서

“Gmail API로 메일 본문을 읽는 서비스”를 만들려면
CASA Tier 2 비용 때문에 사실상 불가능에 가깝다

라는 결론이 나온다.

그 당시에는 자체 CASA Tier 2를 받을 수 있었다.

레퍼런스도 너무 부족해서 어디서부터 시작해야할지 감잡기도 어려웠고 링크드인에 어떤 현업자분이 인증받았다해서 연락을 드렸지만 회신이없었고 우리나름대로 여러가지 시도를 해보았지만 실패했었다.

심지어 지금은 자체 스캔 프로세스는 지원하지않고 무조건 인증기관에 돈을 주고 받게 되어잇다.

우리도 결국 이 문제 때문에, 정식 출시를 하지 못햇다.

프로젝트 기간도 거의 끝나갔고 아쉬움에 남았었다.

(혹시 지금 CASA Tier 2 인증을 받고 싶다면 여기를 참고하면 좋을 것 같다)

같은 실수를 반복하지 않기 위해: 이메일 수신 옵션들 비교

그렇게 우테코 팀프로젝트를 시작하고 뾰족한 대안이 없을 때 뉴스레터 관련 아이템을 제시했고 이전에 수많은 자료조사와 실패한 경을 토대로 팀원들을 설득했고 결국 이 프로젝트를 진행하게되었다.

이 아이템의 핵심은 이메일 도착이다.

찾아본 방법은 크게 네 가지 정도다.

1. AWS SES로 메일로 수신

2. SendGrid / Mailgun inbound API

3. Cloudflare Email Routing

4. 수신 전용 이메일 서버 직접 구축

1) AWS SES(Simple Email Service)로 이메일 받기

가장 먼저 검토한 선택지는 AWS SES로 메일을 받는 방식이다.
news@mydomain.com 같은 주소로 온 메일을 SES가 대신 수신하고, 그 메일을 S3에 저장하거나 Lambda를 실행하거나 SNS로 이벤트를 발행하는 식으로 다른 AWS 리소스로 넘겨주는 구조다.

이미 AWS를 쓰고 있다면, 그림 자체는 꽤 깔끔하다.

직접 메일 서버를 운영할 필요가 없다
- Postfix, Dovecot 같은 걸 설치하고 운영/백업/보안 패치를 신경 쓸 필요가 없다.
AWS가 기본적인 스팸 필터링을 어느 정도 해준다
- 우리가 여러 이메일 관련 설정과 스팸 필터를 처음부터 다 짜는 것보다 부담이 적다.
Lambda와 바로 붙일 수 있다
- “메일 수신 → Lambda 트리거 → 본문 파싱 후 DB 저장” 같은 파이프라인을 서버 없이 구성할 수 있어서,
- 초기에 빠르게 프로토타입을 만들기에는 꽤 매력적인 옵션이다.

초기 작은 서비스이거나,
“메일 수신량이 많지 않고, AWS 안에서만 빠르게 파이프라인을 구성하고 싶다”면
실제로 도입을 충분히 고려해볼 만한 구조다.

하지만 우리 서비스 기준으로는, 치명적인 단점이 몇 가지 있었다.

첫 번째는 경제성 문제다.

SES는 발송뿐만 아니라 수신도 건당 과금이 붙는다.

보수적으로 계산을 해보았다.

평균 1명당 4개의 뉴스레터를 구독하고 그 뉴스레터는 매일 도착한다고 해보자

그럼 회원수가 500명일 때 하루에 2000개의 메일을 수신해야한다.

여기에 청크 비용도 계산을 해야한다.

도착하는 이메일은 뉴스레터고 거의 대부분이 HTML이다

HTML 평균 크기는 11.5KB로 계산했다. (8,000 ~ 15,000자 -> 평균 11,500자)

메일 크기 11.5KB 기준 청크 비용 계산

✔ 청크 단위 = 256KB

→ 11.5KB / 256KB = 0.04492 청크

✔ 청크 비용

0.04492 × 0.00009 USD = 0.000004042 USD / 건

✔ 메시지 비용

0.0001 USD / 건

최종 1건당 비용 : 0.0001 + 0.000004042 = 0.000104042 USD / 건

최종 비용 예상

회원 수	하루 수신량	하루 비용(USD)	월 비용(USD)
500명	2,000건	0.208 USD	6.24 USD
1,000명	4,000건	0.416 USD	12.48 USD
2,500명	10,000건	1.040 USD	31.20 USD
5,000명	20,000건	2.080 USD	62.40 USD

회원 수가 증가할 수록 비용이 선형 증가하게된다.

중요한건 여기에 스팸처리 비용은 계산하지 않았다.

스팸 메일도 똑같이 비용이 든다.

뉴스레터 서비스 특성상,

사용자 수가 늘어나고
구독하는 뉴스레터 종류가 많아질수록
하루에 들어오는 메일 수도 기하급수적으로 증가한다.

초기에야 “얼마 안 나오네?” 싶다가도,
규모가 커졌을 때 고정 비용이 아닌 ‘트래픽 기반 비용’으로 계속 빠져나간다는 점이 큰 부담이었다.

두 번째는 커스터마이징의 제약이다.

SES를 쓰는 순간, 메일 수신 이후의 파이프라인이 AWS 리소스 중심으로 고정되는 느낌이 있다.

Maildir 같은 전통적인 디렉터리 구조를 그대로 쓰기도 어렵고
원본 .eml 파일을 어떻게 보관할지, 장기 보관 정책을 어떻게 가져갈지 등에서
SES 설계에 맞춰서 생각해야 한다.
인프라를 완전히 AWS 밖으로 빼거나,
자체 메일 서버로 구조를 전환하고 싶어지는 시점이 왔을 때 마이그레이션 비용도 고려해야 한다.

우리 서비스처럼

장기적으로 메일을 아주 많이 받게 될 가능성이 높고
원본 메일을 그대로 쌓아두고,
파이프라인과 저장 구조를 우리가 원하는 대로 세밀하게 설계하고 싶다

라는 요구사항을 생각했을 때,

초기에는 편하지만, 규모가 커질수록 비용과 제약이 서서히 발목을 잡을 수 있는 선택지 라는 결론을 내렸다.

그래서 실제 도입 후보에서 완전히 제외한 것은 아니지만,
프로토타입/소규모 서비스에는 좋지만,
장기적으로 우리가 가고 싶은 아키텍처와는 방향이 다르다고 판단했다.

2) SendGrid/Mailgun 수신 API

한 마디로 하면 “메일을 직접 ‘받아’ API로 전달해주는 서비스”

SES 다음으로 눈이 간 건 “메일 수신을 SaaS에 맡기고, 우리는 HTTP로만 받자”는 접근이었다.

메일 프로토콜(MX/SMTP) 세계를 직접 다루지 않아도 되고, 우리 서버는 웹훅 요청 하나만 처리하면 되니까 초반 생산성이 압도적으로 좋아 보였다.

동작 방식

발신자 → (MX) → SendGrid/Mailgun 수신 → 메일 파싱 → 우리 Webhook 엔드포인트로 POST → 저장/파이프라인 실행
SendGrid는 Inbound Email Parse Webhook 형태로 제공한다.

또 하나 마음에 들었던 포인트는, Webhook이 실패해도 재시도 메커니즘이 있다는 점이었다. 예를 들어 SendGrid는 우리 엔드포인트가 5xx로 응답하면 큐잉 후 재시도하고, 2xx를 받으면 처리를 끝낸다(최대 3일 재시도 후 드랍)

우리 기준에서 걸렸던 지점들

1) 비용이 고정 + 제한 형태로 다가온다

SES가 “쓴 만큼”에 가깝다면, 이쪽은 월 플랜(포함량 + 초과 과금) 성격이 강했다.

우리 서비스 가정(1인당 4개/일, 30일 기준)으로 수신량만 단순 환산하면 대략 아래 정도다.

회원 수	월 수신량(건)	Mailgun 추정 월 비용(USD)	SendGrid 추정 월 비용(USD)
500	60,000	약 48 (Foundation 50k + 초과 10k)	약 33.25 (Essentials 50k + 초과 10k)
1,000	120,000	약 112 (Scale 100k + 초과 20k)	약 52.95 (Essentials 100k + 초과 20k)
2,500	300,000	약 310 (Scale 100k + 초과 200k)	약 214.95 (Essentials 100k + 초과 200k)
5,000	600,000	약 640 (Scale 100k + 초과 500k)	약 484.95 (Essentials 100k + 초과 500k)

Mailgun은 무료 구간이 작고(하루에 100통), 유료는 월 구독(Basic이 월 15$)이 붙고, SendGrid도 월 구독(월 19.95$)이 시작점이라 장기적으로 수신량이 늘어나는 서비스에선 부담이 될 수 있다.

핵심은 수신량 증가가 곧 비용 증가로 직결되고, 스팸/오발송처럼 “원치 않는 메일”도 같은 방식으로 비용에 들어온다는 점이었다.

2) 원문(.eml) 보관이 ‘공짜’가 아니다

Maildir처럼 “메일이 오면 원문이 파일로 남는” 흐름이 아니라, Webhook으로 받은 결과를 기반으로

원문(raw MIME)을 그대로 저장할지 어디에,

얼마나 오래 보관할지(S3/DB/파일)

장애/버그 시 재처리(리플레이) 를 어떻게 할지 를 별도로 설계해야 한다.

즉 “수신”은 SaaS가 해주지만, “아카이빙”은 결국 우리가 책임져야 했다.

초기 구현 속도는 최고였다. 하지만 우리 서비스는 이메일 수신이 핵심 도메인이고, 1~2달 하고 끝낼 프로젝트도 아니다. 그래서 월 플랜 기반 비용 구조 + 원문 보관 설계 부담까지 합쳐 보면, 장기적으로 우리가 원하는 아키텍처 방향과는 거리가 있다고 판단했다.

3) 직접 이메일 서버 운영하기

마지막 선택지는, 우리가 직접 이메일 수신 전용 서버를 운영하는 방식이었다.
즉, SendGrid/Mailgun 같은 외부 Inbound 서비스에 의존하지 않고 SMTP(Postfix)로 직접 수신하고, Maildir에 원문을 저장한 뒤 내부 파이프라인(파서/저장/후처리)로 넘기는 구조다.

결론부터 말하면 우리는 이 방식을 선택했다.

왜 직접 운영을 택했을까?

1) 비용이 “고정비”로 떨어진다

Inbound SaaS는 보통 월 구독(플랜) 형태가 시작점이다. 예를 들어 SendGrid는 Essentials가 월 $19.95~부터 시작하고, Mailgun도 무료 구간 이후는 유료 플랜을 전제로 한다.
반면 직접 수신 서버는 ‘메일 건수’가 아니라 ‘서버/디스크’ 중심으로 비용이 잡힌다.

서울 리전 기준으로 아주 러프하게 잡으면(온디맨드)

EC2 t4g.micro: 시간당 약 $0.0104 → 월 약 $7.59
EBS gp3 10GB: 대략 $0.08/GB-month 기준이면 월 $0.80

합치면 월 $8~9 수준에서 시작할 수 있고, 무엇보다 메일이 늘어도 “건당 과금”이 붙지 않아서 규모가 커질수록 예측이 쉬워진다.

여기에 Saving plans을 적용하면 40%는 더 싸진다.

또한 데이터 전송은 인바운드는 과금이 없고(원칙), 아웃바운드는 월 100GB까지 무료 구간이 있다.
뉴스레터 수신/파싱 구조에서는 보통 인바운드가 중심이라 네트워크 비용이 폭발하는 패턴이 상대적으로 덜했다.

2) 설계를 마음대로 가져갈 수 있다

이 방식의 핵심은 “제약이 없다”였다.

Maildir 구조 그대로 저장(원문이 파일로 쌓임)
파싱 로직/재처리 전략(실패 메일 재시도, 파서 교체 등)
첨부파일 처리, 전처리/후처리
보관/삭제 정책(예: N일 보관, 특정 발행처 영구 보관)
트래킹/감사 로그(수신 시각, 처리 시각, 원문 해시 등)

메일이 핵심 도메인인 서비스에서, 이 “완전한 통제권”은 장기적으로 큰 자산이 된다.

3) 원본 이메일(.eml)을 그대로 확보할 수 있다

Inbound API는 “파싱된 결과”를 주는 대신, 원문을 장기 보관하려면 결국 별도 저장 설계가 필요하다.
반면 자체 수신은 원문(.eml) 확보가 기본값이라, 나중에 파서가 바뀌어도 “원문 기준으로 재처리”가 가능하고, 문제 상황에서 디버깅도 훨씬 단단해진다.

4) 대량 수신/버스트에 강하다

Postfix는 원래 큐 기반으로 트래픽을 흡수하도록 설계되어 있다.
뉴스레터처럼 특정 시간대에 몰아치는 패턴에서도, 큐/워커/파서 처리량을 조절하면서 안정적으로 버틸 수 있다는 점이 매력적이었다.

물론, 공짜는 아니다

직접 운영을 선택하는 순간 아래는 “우리 책임”이 된다.

스팸/어뷰징 대응(차단, 레이트리밋, 로그 감시)
보안 패치/권한 관리/접근 통제
디스크/백업/모니터링(메일이 쌓이는 속도, 큐 적체, 파서 지연)

다만 우리는 이메일이 서비스의 중심이고, 1~2달짜리 실험이 아니라 지속 운영이 전제라서, 이 운영 부담을 감수하더라도 비용 예측 가능성 + 설계 자유도 + 원문 확보 쪽이 장기적으로 더 맞다고 판단했다.

3) 수신 전용 이메일 서버 구현

전체적인 필요한 구조는 아래와 같다.

1. 발송 서버에서 메일 전송 시작

뉴스레터 발행 서비스의 메일 서버는 수신자 목록에 있는 user@bombom.news 주소를 보고, 해당 주소로 메일 전송을 시작

2. DNS에서 메일 담당 서버 조회(MX 레코드)

발송 서버는 먼저 DNS에 bombom.news 도메인의 메일을 어느 서버가 맡고 있는지 조회한다.

이때 DNS는 bombom.news 도메인에 설정된 MX 레코드를 보고,

예를 들어 mail.bombom.news 같은 메일 서버 주소를 알려준다.

이어서 발송 서버는 mail.bombom.news의 실제 ip 주소도 DNS로부터 조회한다.

3. 발송 서버 -> 우리 메일 서버 (SMTP 접속)

발송 서버는 조회한 IP로 SMTP(메일 전송 프로토콜) 연결을 맺고,

보내는 사람, 받는 사람, 제목, 본문 등 메일 데이터를 순차적으로 전송한다.

우리 메일 서버는 이 내용을 차례대로 수시하고, 메일을 저장할 준비를 한다.

4. 서버 내부의 Maildir에 메일을 파일로 저장

메일 서버는 수신이 끝난 이메일을 Maildir 형식의 디렉터리에 파일로 저장한다.

일반적으로 한 통의 메일은 Maildir/new 디렉터리 아래 파일 하나로 떨어지며,

이 파일 안에는 헤더(보낸 사람, 받는 사람, 제목, 날짜)와 본문 내용이 모두 포함된다.

여기까직가 이메일이 발송 서버에서 출발해, 우리 서버의 Maildir까지 도착하는 과정이다.

자 그럼 이제 우리가 구현한다고 했으니까

일단 이메일을 받는 것 까지 구현해보자

MX 레코드, 25번 포트, SMTP 서버

메일을 어디로, 어떤방식으로 받는 것을 정해한다.

1. DNS에서 메일 담당 서버를 정하는 것(MX 레코드)

2. 그 서버가 실제로 메일을 받을 준비하는 것(25번포트 + SMTP 서버)

1. MX 레코드

먼저, user@bombom.news로 메일이 도착하려면 DNS에게 bombom.news로 오는 메일은 어느서버가 담당하나요? 라는 질문을 했을 때, 우리 메일 서버를 가리키도록 MX 레코드를 설정해야 한다.

예를 들어

bombom.news의 MX레코드를 mail.bombom.news로 지정하고 mail.bombom.news에는 실제 메일 서버 IP주소를 연결한다.

이렇게 해두면, 외부 발송 서버는 항상

bombom.news -> MX 조회 -> mail.bombom.news -> IP 조회

라는 순서로 우리 서버를 찾아오게 된다.

그래서 우리가 아는 유명한 메일서버인 naver.com를 보면 아래와 같이 되어있다.

이렇게 여러개인이유는 네이버는 대형 메일 서비스 회사이기에 하루에 아마 수억 통 이상을 받을 것이다.

그럼 수신을 담당하는 서버가 하나로 버티기 힘들기도 하고 장애를 대비해야하기에 이렇게 여러개로 분산해놓는 거다.

자 그럼 이렇게 하면 메일을 받을 수 있을까??

아니다

MX 레코드만 있어서는 메일을 받을 수 없다.

표지판만 있고 정작 건물 문이 잠겨 있거나 안에 사람이 없는 것과 비슷하다.

그래서 다음 단계가 필요하다.

1. 메일 서버에서 25번 포트를 연다.

- 이메일 전송에 사용되는 기본 포트가 25번이기 때문에 외부 발송 서버가 이 포트로 접속할 수 있어야 한다.

2. MTA 서버를 설정한다.

- 25번 포트에서 대기하면서 들어오는 메일을 받아서 Maildir 같은 저장소에 기록하는 역할을 한다.

- 발송 서버가 제목,본문,수신자 정보를 보내면 이를 정상적으로 수신하고 파일로 저장한다.

앞선 글에서 SMTP는
메일 서버들이 서로 대화하기 위해 지켜야 하는 통신 규약이라고 설명했습니다.
메일을 보낼 때 어떤 순서로 명령을 주고받고, 성공이나 실패를 어떻게 응답하는지에 대한 약속이 바로 SMTP입니다.

그렇다면 자연스럽게 이런 질문이 생깁니다.

“그럼 이 SMTP 규약을 실제로 구현해서 메일을 주고받는 주체는 누구일까?”

SMTP(Simple Mail Transfer Protocol)는 이메일을 주고받기 위한 표준 통신 규약(프로토콜)이다.
사람이 메신저에서 대화를 주고받듯이, 메일 서버끼리는 SMTP라는 약속된 형식에 따라 대화를 주고받는다.
이때 보낸 사람 주소, 받는 사람 주소, 제목, 본문 내용, 그 외 헤더 정보들이 오간다.

그 역할을 맡는 것이 MTA(Mail Transfer Agent) 이다..

MTA는 SMTP 규약에 따라
외부 메일 서버와 통신하면서 메일을 받고, 전달하고, 필요하다면 큐에 쌓아 재시도하는 역할을 한다..
SMTP가 “규칙”이라면, MTA는 그 규칙을 현실에서 실행하는 프로그램이라고 볼 수 있다..

여기까지 이해했다면, 다음으로 궁금해지는 건 이 질문일 것이다.

“MTA에는 어떤 종류들이 있고, 각각 어떤 특징이 있을까?”

대표적인 MTA 종류들

1️⃣ Postfix

가장 널리 사용되는 MTA 중 하나이다.

보안, 성능, 설정 난이도의 균형이 좋음
구조가 비교적 단순하고 안정적
Maildir, 스팸 필터, 외부 필터 연동이 쉬움
많은 리눅스 배포판에서 기본 또는 권장 MTA로 사용

요즘 새로 메일 서버를 구축한다면
가장 먼저 고려되는 선택지라고 봐도 무방하다.

2️⃣ Sendmail

한때 표준처럼 사용되던 전통적인 MTA이다.

아주 오래된 역사
강력하지만 설정이 복잡함
설정 파일 문법이 난해한 편

현재는 신규 구축보다는
기존 레거시 시스템 유지에서 주로 만나는 경우가 많다.

3️⃣ Exim

특히 유럽 쪽에서 많이 사용되는 MTA이다.

유연한 설정
복잡한 메일 정책을 표현하기 좋음
설정 자유도가 높은 만큼 진입 장벽도 있음

“메일 흐름을 세밀하게 제어해야 하는 환경”에서 선택되는 경우가 많다.

여기서 우리가 고려해야할 점들은 아래와 같다.

(1) 운영 난이도와 장애 대응 가능성

설정이 복잡하면 장애 때 “원인 추적”이 어려워진다.
작은 팀/개인 운영일수록 디버깅 가능한 복잡도가 중요하다.
로그가 명확한지, 흔한 문제의 해결책이 잘 정리돼 있는지도 크다.

(2) 보안 기본값과 설계 철학

외부에서 직접 연결을 받는 컴포넌트라 공격 표면이 큼
프로세스/권한 분리, 기본 설정의 안전함, 업데이트 흐름이 중요하다.

(3) 메일 큐(queue)의 신뢰성

현실에서는 메일이 항상 한 번에 성공하지 않는다.

상대 서버 장애/지연
DNS 문제
일시적 네트워크 오류

이때 MTA가 큐잉/재시도/백오프를 얼마나 안정적으로 해주느냐가 핵심이다.

큐잉(Queuing): 실패해도 메일을 안전하게 보관하기

전송이 실패하면 MTA는 메일을 바로 버리지 않고 큐(Queue) 에 넣어둔다.
큐는 보통 디스크에 저장되기 때문에, 잠깐 장애가 있어도 메일이 사라지지 않는다.
즉 큐잉은 “전송 실패를 곧바로 ‘유실’로 만들지 않고, 다시 시도할 수 있도록 메일을 안전하게 보관하는 장치”이다.

백오프(Backoff): 재시도 간격을 점점 늘려 폭주를 막기

일시 실패가 났을 때, 바로바로 계속 재시도하면 문제가 생긴다.
상대 서버가 다운인데 계속 두드리면 상대도 더 힘들어지고 우리 서버도 큐 처리 때문에 리소스가 소모되고 특히 뉴스레터처럼 한꺼번에 많이 보내는 상황에서는 재시도가 겹쳐 폭주하기 쉽다.
그래서 MTA는 보통 재시도 간격을 점점 늘린다.
처음엔 몇 분 뒤 재시도 → 또 실패하면 더 늦게 → 계속 실패하면 간격을 더 벌리는 식이다.
이게 백오프이다.
“빠르게 회복을 노리되, 장애가 길어지면 시스템을 보호하는 전략”이다.

(4) 스팸/어뷰징/검증 확장성

운영하다 보면 “메일이 온다”가 끝이 아니라,

스팸 유입
봇/어뷰징
도메인 신뢰 판단(SPF/DKIM/DMARC)
같은 이슈가 반드시 따라온다.

MTA가 이런 확장 지점을 붙이기 쉬운지도 봐야 한다.

(5) 저장 방식과 파이프라인 궁합

Bombom처럼 “수신 → 저장 → 파싱” 구조라면 특히 중요하다.

Maildir로 떨구기 쉬운가?
파일 기반 파이프라인으로 넘기기 쉬운가?
장애 시 “어디까지 처리됐는지” 추적이 쉬운가?

(6) 레퍼런스(문서/커뮤니티/사례)

이건 너무 실무적이라서 오히려 진짜 중요하다.

시간 단축을 엄청 해준다.

검색했을 때 바로 나오는가?
배포판 패키지/운영 사례가 충분한가?
“처음 운영”의 시행착오 비용을 줄여주는가?

5) Bombom은 왜 Postfix를 선택했을까?

Bombom의 목표는 단순히 “메일을 받는다”가 아니라,

도메인으로 직접 메일 수신
수신 메일을 Maildir에 저장
이후 내부 로직에서 파싱/가공해 서비스화

이 흐름을 안정적으로 만드는 것이다.

그래서 MTA 선택 기준도 자연스럽게 이렇게 잡혔다.

운영 난이도가 과도하지 않을 것
외부 포트(25) 공개를 감당할 수 있을 만큼 안전한 설계일 것
큐/재시도 같은 “전달 신뢰성”이 검증되어 있을 것
앞으로 스팸/필터/검증을 붙일 때 확장 지점이 있을 것
Maildir 기반 파이프라인과 궁합이 좋을 것
문제 생겼을 때 레퍼런스가 풍부할 것

이 기준으로 보면 Postfix는 “특정 하나가 압도적이라서”라기보다,
운영 현실에서 중요한 요소들의 균형이 가장 좋았던 선택지에 가까웠다.

즉, Bombom의 Postfix 선택은“많이 쓰니까”가 아니라

“우리가 감당해야 할 운영 책임(보안/큐/확장/디버깅)을 고려했을 때, 가장 합리적인 균형점이라서”이다.

기준	Postfix	Exim	Sendmail
운영 난이도(초기 세팅/유지보수)	낮음~중간 (문서/예제 많음)	중간~높음 (유연하지만 복잡성↑)	높음 (레거시/설정 난해)
장애 대응(로그/트러블슈팅 레퍼런스)	매우 좋음 (사례 풍부)	좋음 (다만 설정 복잡 시 난이도↑)	보통~낮음 (레거시)
보안 기본값/설계 철학	좋음 (현대적 권한 분리 구조)	좋음 (설정에 따라 좌우)	보통 (역사 오래됨)
메일 큐/재시도 신뢰성(운영 안정성)	매우 좋음	매우 좋음	좋음
확장성(필터/검증/정책 연동)	좋음 (milter, policy, content_filter 등)	매우 좋음 (정책 표현 강력)	좋음(난이도↑)
Maildir/파이프라인 궁합	좋음 (구성 흔함)	좋음	보통
생태계/도입 사례(배포판 기본/가이드)	매우 많음	많음	레거시 많음
작은 팀이 처음 직접 운영 적합도	높음	조건부(운영 숙련도 있으면 강력)	낮음

실제 적용해보기

일단 Postfix에 잘 도달할 수 있도록 미리 설정해줘야할게 있다.

발신 서버: “example.com 메일 어디로 보내지?” → MX 조회 → mail.example.com

발신 서버: “mail.example.com의 IP 뭐지?” → A 조회 → x.x.x.x

발신 서버: 그 IP의 25번 포트로 SMTP 접속해서 메일 전달

1) MX 레코드 설정

누군가가 user@example.com 으로 메일을 보내면, 보낸 쪽 메일 서버는 DNS에서 example.com의 MX 레코드를 조회하고, 그 결과로 나온 메일 서버 호스팅명(mail.example.com)으로 SMTP 연결을 시도한다.

2) A 레코드 설정

MX가 mail.example.com을 알려줬다면, 이제 실제로 접속하려면 IP가 필요하다.

그때 DNS에서mail.example.com의 A레코드를 조회해서 서버 IP를 알아낸 다음 그 IP의 25번 포트(SMTP)로 접속한다.

3) 보안 그룹/방화벽 25번 포트 인바운드 허용

만약 발신도 한다면 안정장치를 추가로 2가지를 해주면 좋다.

PTR(Reverse DNS) 설정
오픈 릴레이(Open Relay) 차단 (reject_unauth_destination)

하지만 우리는 수신전용이기 때문에 이 부분은 넘어간다.

이제 Postfix를 설치하면된다.

Amazon Linux 2023

sudo dnf install -y postfix
sudo systemctl enable --now postfix

2) 기본 설정 적용

Postfix 핵심 설정 파일

- `/etc/postfix/main.cf`

# 1) 서버 식별
myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain

# 2) 바인딩
inet_interfaces = all
inet_protocols = all

# 3) 로컬 수신 도메인 (최소)
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# 4) 오픈 릴레이 방지(필수)
smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination

# 5) 메일 저장 형식(간단하게 Maildir 권장)
home_mailbox = Maildir/

3) 메일 저장 위치 만들기 Maildir

home_mailbox = Maildir/를 쓰면, 유저 홈 디렉토리에 Maildir로 떨어져.

예: newsletter라는 시스템 유저로 수신 받고 싶으면

sudo adduser newsletter
sudo -u newsletter mkdir -p /home/newsletter/Maildir

4) 서비스 재시작(적용 완료)

sudo systemctl restart postfix
sudo systemctl status postfix --no-pager

Postfix 설치와 DNS(MX/A), 25번 포트 개방까지 끝나면 다음 고민이 생긴다.

“메일은 이제 서버로 들어오는데… 이걸 우리 애플리케이션이 어떻게 읽어서 파싱하지?”

메일 수신 파이프라인을 만들 때 핵심은 단순히 “읽기”가 아니라, 장애가 나도 유실 없이 처리되고, 재처리/운영이 쉬우며, 추후 확장에도 부담이 적은 구조를 고르는 것이다.

우리는 크게 두 가지 방식을 비교했다.

1) pipe 방식(Push): 메일이 오면 Postfix가 즉시 프로그램에 넘긴다

이 방식은 Postfix가 메일을 받은 뒤, 그 내용을 바로 애플리케이션(혹은 스크립트) 에 전달해 즉시 처리한다.

Postfix 수신
특정 주소/도메인 규칙에 따라 “로컬 배달” 단계에서
메일 본문을 프로그램의 stdin으로 전달(pipe)
프로그램이 즉시 파싱/저장하고 종료 코드로 성공/실패를 Postfix에 알림

즉 “메일이 도착한 순간 처리”가 가능해져서 체감상 실시간에 가깝다.

장점은 확실하다: 거의 실시간

폴더에 쌓아두고 나중에 처리하는 단계가 줄어든다.
“도착 → 파싱 → 저장”이 곧바로 이어져 반응성이 좋아진다.

그런데 운영 난이도가 급격히 올라간다

pipe의 핵심 문제는, 메일 수신과 애플리케이션 처리가 강하게 결합된다는 점이다.

애플리케이션이 아래 상황에 들어가면, “수신” 자체가 불안정해질 수 있다.

파싱 로직이 느려져서 처리 시간이 길어짐
순간 트래픽으로 처리 요청이 몰림(버스트)
애플리케이션이 재시작/배포/장애로 응답 못함

이때 Postfix는 “전달 실패”로 인식하고 큐에 쌓거나 재시도하게 되는데, 이 동작을 안정적으로 굴리려면 생각보다 고려할 것이 많다.

성공/실패 기준(exit code) 설계
프로그램 실행 시간 제한(timeout)
밀릴 때의 backpressure(폭주 제어)
재시도 중 중복 처리 방지(멱등성)
장애 시 어떤 메일이 어디까지 처리됐는지 추적

정리하면, pipe는 “실시간”을 얻는 대신 운영에서 맞아야 할 변수가 확 늘어난다.

2) Maildir 폴링 방식(Pull): 폴더에 쌓아두고, 앱이 가져간다

이 방식은 Postfix가 받은 메일을 서버 파일로 저장하고, 애플리케이션이 주기적으로 확인해서 처리한다.

Postfix 수신 → Maildir/new/에 메일 파일 저장
애플리케이션(스케줄러/워커)이 new/ 폴더를 주기적으로 확인
발견한 메일을 읽어서 파싱 → DB 저장/가공
처리 완료 후 cur/ 또는 별도 archive/ 폴더로 이동 (실패 시 failed/ 이동)

즉, Postfix는 “수신 및 저장” 역할에 집중하고, 애플리케이션은 “처리”만 담당한다. 수신과 처리가 분리되는 구조다.

왜 이 방식이 안정적일까?

이 방식의 가장 큰 장점은 애플리케이션 장애가 메일 수신을 망치지 않는다는 점이다.

애플리케이션이 잠깐 죽어도 Postfix는 계속 메일을 받아서 디스크에 쌓아둔다.
장애 복구 후 애플리케이션이 다시 켜지면, 밀려 있던 메일 파일을 순서대로 처리하면 된다.
운영 관점에서 “유실”보다 “지연”이 감당 가능한 문제로 바뀐다.

뉴스레터 수집/파싱처럼 “조금 늦게 처리되어도 되지만, 빠뜨리면 안 되는” 작업에는 이 점이 특히 크다.

단점은?

폴링 주기만큼 지연이 생긴다. (예: 2초~30초)
폴더 스캔 비용이 있다.

하지만 뉴스레터 수신량이 폭발적으로 크지 않은 초기 단계에서는, 이 비용은 보통 미미하다. 폴링 주기를 적절히 잡고(예: 2~5초), 처리 중인 메일을 별도 폴더로 옮겨 중복 처리만 막아주면 안정적으로 돌아간다.

운영하면서 추가 고려할 점

Pull 방식은 “폴더를 읽는다”로 끝나지 않고, 운영을 위해 보통 아래 3가지를 함께 챙긴다.

실패 폴더 + 재처리 전략
파싱 실패/DB 장애 등으로 처리에 실패하면 failed/로 옮겨두고, 나중에 재처리 배치로 다시 돌린다.
중복 방지(멱등성)
메일은 재전송/중복 수신이 생각보다 자주 있다. Message-ID 같은 값을 DB에 저장해 unique 처리하면 안전하다.

우리는 왜 Pull(Maildir 폴링)로 결정했나

우리의 목표는 “메일이 도착하자마자 즉시 처리”가 아니라, 유실 없이 안정적으로 수집하고 파싱하는 것이었다. 뉴스레터 파이프라인에서는 특히 다음이 중요했다.

애플리케이션이 잠깐 실패해도 메일 수신이 멈추지 않을 것
실패한 메일을 따로 모아 재처리할 수 있을 것
운영이 단순해서 디버깅이 쉬울 것(원문 eml 파일 기반 확인 가능)

이 기준으로 보면, Maildir 폴링 방식은 수신과 처리를 분리해 리스크를 줄여주고, 장애가 나도 “지연”으로 흡수할 수 있는 구조였다. 반면 pipe 방식은 실시간이라는 장점은 크지만, 애플리케이션 상태가 곧바로 수신 안정성에 영향을 줄 수 있고, 재시도/폭주 제어/중복 방지 같은 운영 설계를 초기에부터 탄탄히 가져가야 했다.

그래서 우리는 초기 단계에서는 안정성과 단순성이 가장 큰 가치라고 판단했고, 최종적으로 Maildir 폴링(Pull) 을 선택했다.

봄봄 AWS 비용 다이어트 이야기

개발자성장기 — Tue, 9 Dec 2025 17:13:09 +0900

봄봄의 상황

현재 봄봄은 300명이 넘는 회원이 쓰고 있는 서비스다.
“우테코 끝나면 이거 그냥 접는 거 아니야?”라는 질문을 여러 번 들었는데,
처음 기획할 때부터 우리 팀의 목표는 분명했다.

“실험용 토이 프로젝트 말고, 진짜 계속 운영하는 서비스 한 번 만들어보자.”

처음 합을 맞출 때도 그 얘기를 했고,
우테코가 거의 끝나갈 즈음에 내가 다시 한 번 팀원들에게 물어봤다.

“진짜야? 우테코 끝나도 이거 계속 한다?”

그리고 모두가 “당연하지” 쪽에 손을 들어줬다.

그런데 한가지 문제가 있다.

바로 우리 서비스는 아직 수익이 없다는 점이다.
수익 모델에 대한 아이디어는 몇 가지 가지고 있지만, 거기까지 가려면 아직 시간이 꽤 걸린다.

그 전까지는, 말 그대로 버티는 힘이 중요하다.

버티려면 결국 고정비용을 줄여야 한다.
매달 나가는 돈이 적어야, 서비스는 오래 살아남을 수 있다.
(카드값이 가벼워야 마음도 가볍다…)

사실상 봄봄의 고정비 대부분은 AWS 서버 비용이다.
도메인, S3 같은 것도 있지만, 진짜 돈을 쓰는 곳은 EC2, RDS 같은 인프라 쪽이다.

(아 물론 도메인 비용은 내년부터 5만원이다 ㅜㅜ)

도메인 더 싼걸로 할껄

팀원들과 논의한 결과, 봄봄의 서버 운영 예산은

한 달에 2만 원 초반대,
7명이기에 14만 ~ 17만 원 수준으로 잡았다.

단순히 이 예산 안에만 맞추는 게 아니라,
나중에 서비스가 더 커졌을 때도 유지 가능한 구조를 만들고 싶었다.
그래서 “지금 줄일 수 있는 건 최대한 줄여 놓자”는 방향으로 정리했다.

1. 서버비 줄이기

앞서 말했지만 AWS 서버 비용이 대부분이라 이 부분을 최대한 줄여야했다.

그 중에 첫 번재 방법은 인스턴스 스펙 낮추고 Gravition으로 옮기기다.

1. 인스턴스 스펙 낮추기 / Graviton으로 옮기기

현재 대부분의 서버가 t4g.nano, t4g.micro처럼 최소 사양으로 운영되고 있다.

처음부터 Graviton(ARM 기반) 인스턴스를 선택한 것도 같은 이유다.
동일한 성능 대비 비용이 훨씬 저렴하기 때문에, 별도의 구조 변경 없이도 고정비를 크게 줄일 수 있는 선택지였다.

간단히 말해, ARM으로 전환하고 스펙을 낮추는 것만으로도 매달 나가는 서버비를 확실히 줄일 수 있었다는 것이다.

인스턴스	vCPU	메모리	아키텍처	시간당 요금(USD)	월 요금(약 730h)
t2.micro	1	1GB	x86	$0.0128/h	$9.34/월
t3.micro	2	1GB	x86	$0.0104/h	$7.59/월
t4g.micro	2	1GB	ARM(Graviton)	$0.0084/h	$6.13/월

왜 굳이 x86을 고집하지 않기로 했을까?

EC2 인스턴스를 고를 때 예전에는 아무 생각 없이 t2, t3 같은 x86 계열부터 보는 게 자연스러웠다.

“서버 = 인텔(x86)”이라는 인식이 워낙 강했기 때문이다.

하지만 봄봄 인프라를 설계하면서는, 굳이 x86을 계속 써야 할 이유가 없다고 판단했다.

오히려 ARM(Graviton)을 쓰는 쪽이 더 합리적이었다.

그 이유는 아래와 같다.

1) ARM은 더 이상 ‘실험용’이 아니다

예전 ARM은 라즈베리파이, 스마트폰 같은 저전력 디바이스 느낌에 가까웠다.
“운영 서버에 쓰기엔 아직 부족하지 않을까?” 하는 이미지가 강했다.

하지만 이제는 상황이 완전히 다르다.

AWS가 Graviton2, Graviton3, Graviton4까지 계속 밀어주고 있고
공식 벤치마크에서도 “같은 돈이면 더 좋은 성능, 같은 성능이면 더 싼 비용”이라는 메시지를 강하게 이야기한다.
실제로 EC2 요금표만 봐도, 같은 급에서는 x86보다 Graviton(t4g 계열)이 더 싸다.

즉, ARM은 더 이상 특이한 선택”이 아니라,안 쓰면 오히려 손해일 수 있는 기본 옵션에 가깝다.

2) 우리가 사용하는 스택은 ARM에서 전혀 문제 없다

봄봄의 백엔드는 전형적인 웹 서비스 스택이다.

Java
Spring Boot
Docker 컨테이너
MySQL등 오픈소스들

이 조합은 이미 수많은 회사에서 Graviton 위에서 정상적으로 운영되고 있고,
도커 이미지도 arm64 빌드만 추가해주면 된다.

특별한 네이티브 x86 바이너리를 쓰는 것도 아니라서,
“x86이라서만 되는 무언가”가 우리 서비스에는 없다.

그래서 “굳이 x86을 써야 한다”는 기술적인 이유가 거의 없다.

3) 가격만 놓고 보면 x86을 선택하기가 더 어렵다

단순히 요금만 놓고 보면 선택은 더 명확해진다.

같은 vCPU/메모리 기준으로
t2/t3(x86) < t4g(ARM) 순서로 나란히 놓고 보면
대부분 t4g가 더 싸다.
심지어 우리가 쓰는 구간처럼, nano / micro / medium 같이 작은 스펙에서는
t4g가 사실상 최저가 라인에 가깝다.

즉, 현재 봄봄처럼 “어떻게든 고정비를 줄여야 하는” 상황에서
굳이 더 비싼 x86을 선택하는 건, 이유 없는 사치에 가깝다.

정리

그래서 인스턴스를 고를 때 우리는 이렇게 스스로에게 물었다.

“지금 이 서비스는 정말 x86을 써야만 하는 이유가 있나?”

그리고 내린 결론은 단순했다.

기술적으로도 ARM이 충분히 안정적이고
가격은 ARM이 더 싸고
우리가 사용하는 스택은 ARM에서 아무 문제 없고
개발 환경도 이미 ARM이 일상인 시대다.

그래서 봄봄은 굳이 x86을 고집하지 않고, 처음부터 Graviton(t4g) 인스턴스를 기본 선택지로 가져가는 쪽을 택했다.
이 선택 하나만으로도, 똑같이 서버를 돌리면서 매달 나가는 돈을 꽤 크게 줄일 수 있었다.

그렇다면 인스턴스 타입은 왜 t 시리즈(버스터형)로 했을까?

그전에 인스턴스 타입에 대해 간단하게 알아보자

EC2를 아주 단순하게 말하면

“클라우드 위에 빌려 쓰는 컴퓨터”

인데, AWS가 여러 용도에 맞게 미리 스펙을 나눠둔 PC 세트를 만들어 둔 거라고 보면 된다.

어떤 건 싸고 가볍게 쓰는 용도 (T)
어떤 건 균형 잡힌 기본형 (M)
어떤 건 CPU 빡세게 돌리는 용도 (C)
어떤 건 메모리(RAM) 엄청 많이 쓰는 용도 (R)

이렇게 4개만 먼저 머릿속에 넣어두면 훨씬 편해진다.

T 시리즈 - 가끔만 힘 쓰는 가성비형

ex) t4g.nano, t4g.micro ...

평소엔 조용히 돌아가는 경차지만 필요할 때 잠깐 터보 버튼 눌러서 쎄게 달리는 느낌이라고 생각하면 편하다.

평소에 CPU 사용량이 낮을 때 아주 싸게 쓸 수 있고 짧은 순간 트래픽이 확몰료도, 잠깐은 높은 CPU 성능으로 버스트가 가능하다.

만약 무제한 모드라면 CPU를 계속 일정 기준치 이상으로 쓴다면 그만큼 비용을 내야한다.

그래서 사이드 프로젝트나, 개인 서비스, 소규모 서비스, 하루 종일 빡세게 돌리진 않는데 가끔 잠깐 바빠지는 서비스에 어울린다.

M 시리즈 - 범용 인스턴스

ex) m6g.large, m7g.medium

회사에서 주는 기본 사무용 PC 느낌이다.

CPU와 메모리가 적당히 균형 잡혀있다.

T처럼 버스트 크레딧 이런 거 없기에 CPU를 80%, 90%를 써도 추가 요금이 붙지 않는다.

그렇다면 언제 쓰면 좋을까?

- 본 서비스용 API, 웹 서버

- 소규모/중간 정도 DB 서버

3. C 시리즈 – “근육 많은 운동선수형” (컴퓨팅 최적화)

예: c7g.large, c7g.xlarge …

“생각하는 시간 말고, 연산은 내가 다 때려박는다” 타입

특징으로는 같은 가격이라면 CPU 코어 수가 더 많고, 메모리는 M 시리즈보다 상대적으로 적은 편이다.

게다가 계산/연산이 많은 작업에 최적화되어 있다.

이건 언제쓰면 좋을까?

배치 작업, 로그/데이터 처리
통계 집계, 랭킹 계산, 추천 알고리즘 등 CPU를 많이 쓰는 코드
트래픽이 많고, 요청당 계산이 많은 API 서버

4. R 시리즈 – “메모리 빵빵한 서버” (메모리 최적화)

예: r6g.large, r7g.large …

비유하자면 램 64GB, 128GB 달린 고급 사무용 PC이라고 생각하면 좋다.

엑셀, IDE, 크롬 탭 50개 켜도 멀쩡한 컴퓨터 느낌??

특징으로는 같은 세대 기준으로 CPU 개수는 M과 비슷하지만 대신 메모리가 훨씬 더 많다.

하지만 메모리 많이 주는 만큼 가격도 M보다 비싸다.

언제쓰면 좋을까?

DB 서버(MySQL, PostgreSQL 등)
- InnoDB 버퍼 풀 크게 잡아서 디스크 I/O 줄이고 싶을 때
Redis / Memcached 같은 캐시 서버
검색/분석 서버
- (Elasticsearch, OpenSearch 등 인덱스를 메모리에 많이 올려두고 싶은 경우)

이를 바탕으로 생각해보았을 때

세 가지 이유 때문에 t시리즈를 선택했다.

1. 필요한 최소 사양이 T 시리즈에만 있었다

우리가 실제로 쓰고 싶었던 낮은 등급(nano, micro, small) 은 T 시리즈에만 존재했다.
반대로 M, C, R 같은 다른 패밀리는 대부분 medium 또는 large부터 시작한다.

하지만 이제 막 서비스를 시작한 입장에서,
애초에 트래픽이 거의 없기 때문에 medium, large 급을 쓸 이유가 없다.
지금 시점에서 그런 스펙을 선택하는 것은 완전히 오버 스펙이다.

그래서 “일단 가장 작은 단위로 시작하자”는 관점에서,
선택지는 자연스럽게 T 시리즈로 좁혀졌다.

2. 비용

두 번째 이유는 비용이다.

T 시리즈는 CPU 버스트(짧은 시간 높은 CPU 사용)만 자주 일어나지 않는다면,
같은 세대의 다른 인스턴스 타입에 비해 더 저렴하게 사용할 수 있다.

지금처럼 트래픽이 크지 않고,
CPU를 계속 50~80% 이상 사용하는 구조가 아니라면,
굳이 M이나 C처럼 “항상 일정 성능이 보장되는 인스턴스”를 쓸 필요가 없다.

성능도 중요하지만 지금 그만큼의 성능도 필요없다.

3. 실제 CPU 사용량이 T 시리즈에 딱 맞는다

마지막으로, 실제 CPU 사용량 데이터가 T 시리즈 선택을 뒷받침한다.

CloudWatch 그래프를 보면,
대부분의 시간 동안 인스턴스의 CPU 사용률이 5% 미만이다.

평소에는 거의 놀고 있고
가끔 트래픽이 생기더라도 잠깐 버스트로 커버 가능한 수준이다.

즉, 현재와 가까운 미래의 트래픽을 고려했을 때
항상 높은 성능을 유지하는 인스턴스보다,
평소에는 가볍게 돌다가 필요할 때만 잠깐 힘을 쓰는 버스트형인 T 시리즈가 더 잘 맞는다고 판단했다.

이를 통해 월 약 $3.21 절감 → 연 $38.5 절감을 할 수 있다.

2. Saving plans 구매하기

AWS에서 EC2를 쓰면 기본은 온디맨드(On-Demand) 요금제다.
딱 쓴 만큼만 과금되고, 약정도 없다. 대신 가장 비싸다.

AWS는 여기에 “장기 고객”을 위한 할인을 하나 더 얹어준다.
그게 바로 Savings Plans다.

이걸 아주 단순하게 말하면:

“앞으로 1년(또는 3년) 동안,
매시간 최소 얼마어치는 꼭 쓸게요”
라고 약속하는 대신
온디맨드보다 싸게 쓰게 해주는 제도다.

여기서 중요한 포인트는 두 가지다.

기간 약정: 1년 또는 3년
금액 약정: “시간당 얼마만큼은 무조건 쓴다”라는 사용량 약속

예를 들어 “시간당 0.02 USD어치는 항상 쓸게요” 라고 1년 약정을 하면,

해당 금액까지는 할인된 요금(Savings Plans 요금)이 적용되고,
그걸 넘어가는 사용량은 기존 온디맨드 요율로 계산된다.

2. Reserved Instances랑 뭐가 다를까?

비슷한 개념으로 Reserved Instances(RI)도 있다.
둘 다 “장기 약정 + 할인”이라는 점은 같지만, 성격이 조금 다르다.

아주 대충 정리하면

Reserved Instances
- 특정 인스턴스 타입, 리전, OS 등에 꽤 딱 맞게 묶인다.
- “서울 리전의 t3.medium Linux, 1년” 이런 식.
Savings Plans
- 좀 더 유연하게 쓸 수 있다.
- 특히 Compute Savings Plans 는 Fargate, Lambda까지 적용 가능.

가격도 직접 비교해보았을 때 Savings Plans랑 같거나 거의 비슷한 수준이라서 유연성이 높은 Savings Plans을 사용하기로 했다.

3. Savings Plans의 종류

Savings Plans는 크게 두 종류가 있다.

Compute Savings Plans
- 가장 유연하다.
- EC2 인스턴스 타입이 바뀌어도, 리전이 바뀌어도, Lambda/Fargate를 써도 할인 적용.
- 그만큼 할인율은 조금 낮다. (2025년 12월 기준으로 약 30%정도 된다)

EC2 Instance Savings Plans
- 특정 인스턴스 패밀리(예: t4g, m6g) + 리전에 묶인다.
- 예) ap-northeast-2(서울) 리전의 t4g 패밀리
- 대신 Compute Savings Plans보다 할인율이 더 높다. (2025년 12월 기준으로 약 40%정도 된다)

우리 서비스는 1년안에 ec2 인스턴스 타입이 바뀔 확률이 낮고 리전은 추가하면 추가했지 절대 바뀌지 않고 Lambda/Fargate도 사용량이 많지 않을 것이라 판단해 할인율이 더 높은 EC2 Instance Savings Plans을 구매했다.

4. 어떻게 할인되는 건가요?

Savings Plans를 구매하면, AWS는 매 시간마다 이런 식으로 계산한다.

이 계정에 걸린 Savings Plans 약정 금액을 확인한다.
예: “시간당 0.02 USD 약정”
현재 이 계정에서 실제로 사용 중인 리소스 비용을 확인한다.
예: “이번 시간 EC2 비용이 0.018 USD 나왔네?”
약정 금액(0.02 USD) 안에서 커버 가능한 usage에 대해서
할인 요금(Savings Plans 요율)을 적용한다.
만약 실제 사용량이 약정을 넘으면(예: 0.03 USD 썼다),
약정 금액까지는 할인 요금,
그 이상은 기존 온디맨드 요율로 과금된다.

즉,

약정 금액 이하로 쓰면 → 전부 할인
약정 금액 이상으로 쓰면 → 약정 구간까지만 할인, 나머지는 온디맨드

그래서 약정을 걸 때,
너무 높게 잡으면 손해고,
너무 낮게 잡으면 “할인을 더 받을 수 있었는데”가 된다.

5. Savings Plans를 사기 전까지

세이빙 플랜을 사기 전, 봄봄의 EC2 사용 상황은 대략 이랬다.

봄봄에서 사용하는 인스턴스는 아래와 같다.

t4g.micro 3대 (prod1, prod2, email)
t4g.nano 3대 (lb 2대 + nat gatway 1대)
t4g.medium 1대 (monitoring)
t2.micro 1대 (dev) - 프리티어

이렇게 총 8대의 EC2 인스턴스를 24시간 돌리고 있었다.

이 상태에서 전부 온디맨드 요금으로만 계산하면 한 단 기준으로 EC2 비용만 대략 8~9만 원 정도가 나온다.

즉, 그냥 아무 생각 없이 온디맨드로만 1년을 버틴다라고 가정하면 1년 동안 EC2만 100만 원 가까이 나가는 구조였다.

우리는 Cost Explorer로 지난 몇 달간의 사용량을 쭉 보면서 트래픽이 갑자기 10배 튈 것 같지는 않고, 지금 구성도 이미 "최소한으로 쳐낸 인프라"에 가깝고 1년 동안은 최소 이 정도 인스턴스는 무조건 돌릴 수 밖에 없다는 걸 확인했다.

그래서 "무조건 쓸 수 밖에 없는 최소 구간"만큼은 온디맨드로 돈을 태우지 말고, EC2 Savings Plans 1년 약정으로 묶어버리기로 했다.

어차피 앞으로 확장 계획도 있기에 적어도 이것보다는 많이 쓸 것 같았고 같은 t4g에서 언제든 다른 타입으로 바꿀 수 있기에 걱정이 없었다.

6. 왜 지금 이 타이밍에 약정을 걸었나

Savings Plans는 “돌이키기 힘든 결정”이라,
초기에는 나도 꽤 고민을 많이 했다.

혹시 몇 달 뒤에 서비스를 접게 되면 어떡하지?
인스턴스 타입을 전면 교체해야 할 상황이 오면 어떡하지?
트래픽 패턴이 완전 바뀌어 버리면 어떡하지?

그래서 우리는 다음 기준을 세웠다.

팀원 전원이 “앞으로 1년은 최소한 운영해보자”에 동의할 것
현재 인프라 구성이 “최소치에 가깝다”고 판단될 것
약정 금액은 앞으로도 고려해서 80% 정도 수준으로 잡을 것

이 기준을 만족한 시점에서,
우리는 “이제는 약정을 걸어도 되겠다”고 보고
EC2 Savings Plans 1년을 구매했다.

총합 53.5$

이를 통해 한 달에 약 21.4$ 절감 -> 연 256.8$을 절감 할 수 있다.

3. NAT Gateway 비용 줄이기

곧 출시

4. ALB 대신 직접 로드밸런서 구성하기

곧 출시

봄봄에서 서드파티 라이브러리를 대하는 방법

개발자성장기 — Sat, 22 Nov 2025 21:33:51 +0900

들어가며

뉴스레터 검색 기능을 재설계 및 개선하다가

뜻밖에 먼저 건드려야 할 친구를 하나 발견했다. 바로 HTML 태그였다.

“본문은 텍스트가 중요한데, 왜 굳이 태그까지 다 들고 있어야 하지?”

라는 질문에서 시작된 고민과, 그걸 정리해 가는 과정들을 한 번 적어봤다.

뉴스레터 검색, 첫 번째 장애물: HTML 태그

우리 서비스에서 다루는 뉴스레터는 이런 식으로 생겼다.

모든 뉴스레터는 HTML 형태로 들어오고, DB에는 대략 이런 형태로 저장된다.

검색 기능을 개선하면서, 이 `contents` 칼럼에서 HTML 태그를 걷어내는 작업이 필요해졌다.

현재 `contents`에는 HTML 태그를 포함한 본문 전체가 들어 있다.

문제는 이 칼럼의 길이가 보통 8,000자 ~ 15,000자 정도라는 점이다.

검색 성능을 위해 일부 아티클만 골라서 FULLTEXT INDEX + ngram 파서를 쓰고 있는데,

HTML 태그까지 전부 포함해서 토큰을 만들면

토큰 수가 불필요하게 많아지고
아티클이 쌓일수록 인덱스 용량이 기하급수적으로 증가한다

결국 “검색에 진짜 필요한 텍스트”만 남겨놓고 인덱스를 만드는 게 훨씬 효율적이다.

실제로 HTML 태그를 걷어내면,

본문 길이가 평균 800 ~ 1,000자 수준까지 줄어든다.

검색 인덱스 입장에서는 거의 10배 가까이 가벼워지는 셈이라,

HTML 태그 제거는 사실상 “있으면 좋은 기능”이 아니라 거의 필수에 가까운 기능이 되었다.

그럼 자연스럽게 다음 질문이 나온다.

“HTML 태그, 어떻게 제거할까?”

제일 먼저 떠오른 건 “잘 만들어진 서드파티 라이브러리 하나 가져다 쓰자”였다.

이걸 단순히 정규표현식으로 지워버리는 건 리스크가 크다고 생각했다.

예를 들어 본문에 이런 문장이 들어올 수 있다.

진짜 텍스트 안에 <이렇게> 꺾쇠를 써야 하는 경우

이걸 무지성으로 `<[^>]*>` 같은 정규식으로 지워버리면

HTML 태그가 아니라, 사용자가 적어둔 실제 텍스트까지 같이 날아갈 수 있다.

그래서 처음부터 정규식을 주력으로 쓰는 방식은 제외하고,

“HTML을 이해하고 파싱하는 서드파티”들을 먼저 살펴보기로 했다.

그렇다면, 어떤 서드파티들이 있을까?

서드 파티 종류

1. Jsoup

공식 사이트 링크

깃허브 링크

HTML을 DOM으로 파싱해서, text() 한 번으로 태그 싹 지우는 라이브러리

태그/속성/텍스트 구조를 다 이해하는 제대로 된 파서

태그 제거뿐 아니라, 크롤링, DOM 탐색, 필터링 등에도 자주 쓰임

이 라이브러리를 쓴다면 워낙 쉽기 때문에 학습 비용이 거의 없고 문서와 예제가 많다.

구현 방식에서 DOM을 구성하기 때문에 아주 거대한 HTML에선 메모리/속도 이슈가 발생할 수 있다고 한다.

레포지토리를 가보면 사용하는 사람도 많고 버전관리도 잘하고 있다.

지금까지 본 것 중 가장 많은 사용자들이 있는 것 같다.

2. Jericho HTML Parser

Jericho HTML Parser는 예전에 많이 쓰이던 HTML 파서 라이브러리다.

최근에는 릴리스가 거의 멈춘 상태지만, 기본적인 텍스트 추출 기능 자체는 아직도 동작한다.

HTML 문서에서 텍스트를 뽑아내거나, 일부 태그를 분석·조작하는 용도로 설계되어 있다.

jsoup처럼 “브라우저스러운 DOM”을 만들어서 다루기보다는, 마크업을 훑으면서 필요한 부분만 처리하는 스타일에 가깝다.

마지막 릴리스가 2010년대 중반쯤이라, 최근 HTML5 환경이나 새로운 자바 버전에 맞춰진 발전은 거의 없다.

2015년 이후로는 릴리스가 끊긴 상태라, “지속적으로 관리되는 라이브러리”를 선호하기에 선택하기는 어려울 것 같다.

공식 홈페이지 지원이 끝난 것 같다.

2015년 이후 유지보수 X

3. HTMLCleaner

HTMLCleaner는 이름 그대로, 지저분한 HTML을 한 번 “정리(clean)”해서 잘formed된 구조로 바꿔주는 자바 기반 HTML 파서다.

원래 목적 자체가 “웹에서 긁어온 더러운 마크업을 브라우저처럼 해석해서, 괜찮은 XML/HTML로 만들어주자”에 더 가깝다.

HTMLCleaner는 대략 이런 흐름으로 동작한다.

깨진 태그, 잘못 닫힌 태그, 중첩이 엉킨 HTML을 파싱한다.
브라우저가 DOM을 만들 때 비슷하게 적용하는 규칙을 따라, 태그를 재배치·보정해서 정상적인 트리 구조로 만든다.
그 정리된 트리에서 텍스트를 꺼내 쓰거나, XML/깔끔한 HTML로 다시 출력할 수 있다.

그래서 Jsoup처럼 “바로 DOM에 접근해서 text()를 꺼내 쓰는 라이브러리”라기보다는,

“먼저 HTML을 정돈하고 나서 쓰는 정리기(Cleaner)”라는 색깔이 더 강하다.

장점부터 보면, 정말 지저분하게 깨진 HTML을 만나도 한 번 정리 과정을 거치고 나면 훨씬 다루기 편해진다는 점이 가장 크다. 게다가 결과를 꽤 깔끔한 HTML/XHTML 형태로 다시 내보낼 수 있기 때문에, 이후에 다른 XML/HTML 도구나 파이프라인에 태워야 할 때도 궁합이 괜찮다. “먼저 HTMLCleaner로 한 번 씻기고, 그 다음 다른 도구에 넘기는” 식의 구조를 만들기 좋은 편이다.

반대로 단점도 분명하다. 그냥 “HTML 태그만 빠르게 걷어내고 텍스트만 얻고 싶다” 정도의 요구라면, HTMLCleaner는 조금 과한 선택일 수 있다. 구조를 정리하고, 트리를 만들고, 다시 출력할 수 있는 기능까지 포함하다 보니, 단순 태그 제거만 필요한 경우에는 오버스펙에 가까운 느낌이다. 게다가 Jsoup처럼 친숙한 문법과 풍부한 예제를 제공하는 라이브러리는 아니라서, 처음 접하는 입장에서는 문서나 API 스타일이 다소 낯설게 느껴질 수도 있다. 프로젝트 분위기도 최신 트렌디한 라이브러리라기보다는 “꽤 오래된 도구”에 가깝다.

정리하자면, HTMLCleaner는 HTML을 한 번 깨끗하게 ‘세탁’한 뒤에 텍스트를 뽑거나, 다른 도구들로 넘기고 싶을 때 고려해볼 만한 선택지다.

4. Apache Tika

Apache Tika는 “텍스트 추출 전담 엔진”에 가까운 라이브러리다.

단순히 HTML만 다루는 게 아니라, 아래 같은 것들을 전부 텍스트로 바꿔준다.

HTML, XML
PDF
MS Office(Word, Excel, PowerPoint)
OpenOffice, RTF
이미지에서의 메타데이터 등등…

사용법 자체는 꽤 단순하다.

Tika tika = new Tika();
String text = tika.parseToString(inputStreamOrBytes);

이렇게만 호출해도, 파일 포맷을 스스로 감지해서

“이 문서에서 뽑을 수 있는 텍스트를 최대한 긁어서” 문자열로 돌려준다.

그래서 이 라이브러리는, “우리는 HTML만 처리하는 서비스야” 같은 경우에는 솔직히 좀 과하고, “메일 본문뿐 아니라 PDF·Word 같은 첨부파일까지 한 번에 검색하고 싶다” 같은 요구가 있을 때 진지하게 검토할 만한 도구에 가깝다.

장점을 정리하면,

문서 포맷을 일일이 구분하지 않고 “그냥 문서를 넣고 텍스트를 받고 싶을 때” 압도적으로 편하다.

이메일 시스템에서 첨부파일까지 검색 대상에 포함시키고 싶다면, Apache Tika는 거의 항상 후보 목록에 올라오는 편이다. “첨부까지 전부 검색 가능하게 만들고 싶다”는 요구가 나오는 순간, Tika는 꽤 매력적인 선택지가 된다.

반대로 단점도 분명하다.

HTML 태그만 제거해서 텍스트로 만들고 싶은 정도의 요구라면 너무 무겁다.

라이브러리 자체도 크고, 내부에서 포맷 감지 → 파서 선택 → 파싱 과정을 전부 거치기 때문에 그만큼 비용이 든다.

그래서 단순히 “뉴스레터 본문 HTML → 텍스트” 수준의 작업에는 Jsoup 같은 HTML 파서에 비해 확실히 과한 선택일 수 있다.

정리하자면, Apache Tika는 HTML만 다루는 서비스 입장에선 다소 과한 도구이고,

메일 본문뿐 아니라 PDF·Word 같은 첨부파일까지 함께 검색하고 싶을 때 빛을 발하는 도구라고 볼 수 있다.

“검색 범위를 어디까지 보고 있는지”에 따라, 사용할지 말지를 결정하게 되는 라이브러리다.

5. JFiveParse

JFiveParse는 digitalfondue에서 만든 순수 자바 HTML5 파서다.

이름처럼 HTML5 파싱에 꽤 진심인 친구인데, html5lib에서 제공하는 토크나이저/트리 구성 테스트 중 스크립트가 필요 없는 부분은 전부 통과하도록 만들어졌다.

특징을 정리하면

HTML5 스펙을 꽤 충실히 따라가는 파서

html5lib 테스트 스위트(토크나이저 + 트리 구성 비스크립트 케이스)를 통과하도록 구현됨

0 dependencies + 작은 JAR 크기

외부 의존성이 아예 없고, JAR 크기도 대략 150KB 정도로 가볍게 유지하는 걸 목표로 한다.

문서 전체/조각(fragment) 둘 다 파싱 가능

String에서 바로 파싱하거나, Reader를 통해 스트리밍 파싱도 지원한다. 다만 인코딩은 호출하는 쪽에서 알고 있어야 하고, 자동 인코딩 감지는 지원하지 않는다.

지속적으로 관리되는 프로젝트

GitHub를 보면 2025년까지도 커밋이 이어지는 등, 생각보다 꾸준히 관리되고 있는 편이다.

장점 쪽으로 보면,

HTML5 스펙에 더 가까운 파서가 필요할 때 후보로 올릴 만하다.

“브라우저가 파싱하는 방식과 얼추 비슷하게, 깨진 HTML까지 최대한 관대하게 받아주고 싶다” 쪽에 가깝다.

라이브러리 크기/의존성에 민감할 때 꽤 매력적이다.

0 dependency + 소형 JAR이라, “메일 처리용 유틸에 괜히 거대한 HTML 파서를 끌어오고 싶지 않다”는 팀에 잘 맞는다.

반대로 단점/고민거리는 이런 쪽에 가깝다.

생태계와 예제가 Jsoup만큼 풍부하진 않다.

Maven Central에서 사용 예시를 보면, 실제로 의존하는 프로젝트 수가 많지는 않다.

“태그 싹 지우고 텍스트만”이라는 고수준 API는 직접 만들어야 한다.

DOM 비슷한 트리를 제공해주지만, Jsoup의 doc.text()처럼 한 줄로 “텍스트만 주세요” 하는 느낌은 아니어서,

보통은 JFiveParse로 파싱 → 노드를 순회하면서 텍스트 노드만 모으는 커스텀 TextExtractor를 한 번 더 감싸서 쓰게 된다.

활발하지는 않지만 관리는 되고있다는 걸 알 수 있다.

왜 굳이 여러 서드파티를 살펴볼까?

얼핏 보면 “그냥 적당한 거 하나 골라 쓰면 되지 않나?” 싶은데, 막상 라이브러리 고르기 모드에 들어가 보면 체크리스트가 끝도 없이 늘어난다.

유지보수가 잘 되고 있는지
얼마나 많은 사람들이 쓰는지
문서와 예제가 충분한지
이슈가 꾸준히 처리되는지

이런 것들을 보는 이유도 물론 있다.

그런데 내가 여러 후보를 일부러 더 찾아보는 진짜 이유는 따로 있다.

“하나가 실패했을 때, 바로 대신 들어올 다음 주자가 있는가?”

서드파티 라이브러리는 결국 내가 통제할 수 없는 코드다.

HTML이 비정상적으로 들어온다든지, 라이브러리 내부 버그라든지,

어딘가에서 예상 못 한 예외가 터질 수 있다.

그때 그냥 실패로 끝낼 건지,

아니면 다음 후보로 넘겨서 한 번 더 시도해볼 수 있는 구조인지에 따라

안정성 측면에서 차이가 크게 벌어진다.

그래서 나는 메인 1개 + 서브 1개 정도면 충분하다고 생각했고,

그 둘을 어떻게 엮어서 "안전한 구조"로 만들지에 더 집중했다.

DispatcherServlet의 getHandler()에서 가져온 아이디어

구조를 어떻게 잡을까 고민하다가,

우테코 레벨2에서 스프링을 배우면서 DispatcherServlet을 뜯어보던 기억이 났다.

그때 봤던 getHandler() 메서드가 머릿속에 딱 떠올랐다.

DispatcherServlet은 한 번에 딱 하나의 핸들러만 고르는 역할을 한다.

이때 내부에서 하는 일은 대략 이런 흐름이다.

등록된 HandlerMapping 들을 순서대로 훑어보면서

“이 요청을 처리할 수 있는 핸들러가 누구인지”를 차례로 물어보고

그 가운데 가장 먼저 “제가 처리할 수 있습니다”라고 응답하는 핸들러를 선택한다

즉, 여러 후보를 앞에서부터 차례로 시도해 보고, 가장 먼저 ‘가능하다’고 답하는 애를 채택하는 구조다.

나는 이 동작 방식이 HTML 파서에도 잘 어울린다고 느꼈다.

단순히 아래처럼 1차원적인 `try-catch`로만 묶는 구조가 아니라,

try {
	서드파티 1 동작
} catch (e) {
	서드파티 2 동작
}

동작 가능한 파서들을 리스트에 담아두고 앞에서부터 순서대로 돌려 보다가 처음으로 성공한 결과를 바로 쓰는 방식으로 가져오고 싶었다.

동작 가능한 후보들을 리스트로 만들어두고, 차례대로 시도하면서, 가장 먼저 성공한 서드파티를 사용한다.

이게 훨씬 읽기 좋고, 나중에 후보를 추가하거나 순서를 바꾸기 편하다.

구현

먼저 인터페이스를 정의해줬다.

public interface HtmlTagCleaner {
    String clean(String html);
}

그 다음, 실제로 HTML을 파싱해서 태그를 제거하는 구현체들을 만든다.

예를 들어 Jsoup를 사용하는 구현체는 이렇게 생겼다.

import org.jsoup.Jsoup;

public class JsoupHtmlTagCleaner implements HtmlTagCleaner {

    @Override
    public String clean(String html) {
        return Jsoup.parse(html).text();
    }
}

(여기서 JFiveTextExtractor, RegexHtmlTagCleaner 등 다른 후보들도

같은 인터페이스를 구현하도록 맞춰준다.)

여러 구현체를 failover 체인으로 묶기 위해 스프링 설정에서 FailoverHtmlTagCleaner를 Bean으로 등록한다.

@Configuration
public class HtmlCleanerConfig {

    @Bean
    public HtmlTagCleaner htmlTagCleaner() {
        return new FailoverHtmlTagCleaner(
                new JsoupHtmlTagCleaner(),
                new JFiveTextExtractor(),
                new RegexHtmlTagCleaner()
        );
    }
}

서비스 쪽에서는 HtmlTagCleaner 인터페이스만 주입받고,

뒤에 어떤 구현체들이 몇 개나 줄 서 있는지는 전혀 알 필요가 없다.

@Slf4j
public class FailoverHtmlTagCleaner implements HtmlTagCleaner {

    private final List<HtmlTagCleaner> cleaners;

// .. (생략)

    @Override
    public String clean(String html) {
        if (!StringUtils.hasText(html)) {
            return "";
        }

        for (HtmlTagCleaner cleaner : cleaners) {
            try {
                String cleaned = cleaner.clean(html);
                if (cleaned != null) {
                    return cleaned;
                }
                log.warn("{} 가 null을 반환해서 다음 후보로 넘어갑니다.", cleaner.getClass().getSimpleName());
            } catch (Exception e) {
                log.warn("Cleaner {} 실패", cleaner.getClass().getSimpleName(), e);
            }
        }

        log.warn("모든 cleaners 실패");
        return html;
    }
}

FailoverHtmlTagCleaner에서는

HtmlTagCleaner 구현체들을 List<HtmlTagCleaner>로 받아두고
for문을 돌리면서 하나씩 clean()을 호출해보고
예외가 나면 quietly 로그만 남기고 다음 후보로 넘어가고
처음으로 정상적인 결과를 돌려준 구현체의 결과를 그대로 반환한다.

이렇게 해두면,

Jsoup이 대부분의 케이스를 처리하고
만약 Jsoup이 예상치 못한 HTML에서 실패하더라도
Jericho 같은 두 번째 후보가 뒤에서 받아준다

이렇게 해두면, Jsoup이 대부분의 케이스를 처리하고,

만약 Jsoup이 예상치 못한 HTML에서 실패하더라도,

JFiveTextExtractor나 정규식 기반 클리너 같은 두 번째, 세 번째 후보가 뒤에서 받아주는

failover 구조가 자연스럽게 만들어진다.

결국 중요한 건

“어떤 서드파티를 쓰느냐” 뿐만 아니라

“그 서드파티가 실패했을 때, 시스템이 어떻게 반응하도록 설계했느냐”

라고 생각했고,

그 고민의 결과가 지금의 리스트+순회 기반 Failover Cleaner 구조다.

이 구조로 한 이유 (확장성 / 테스트 / 운영 관점)

이걸 굳이 이렇게까지 나눠서 설계한 이유는 단순히

“멋있어 보이려고”가 아니라, 실제로 운영할 때 이점이 많기 때문이다.

1. 확장성: 새로운 파서를 붙이기 쉽다

나중에 “새 HTML 파서를 한 번 써보고 싶다”라는 요구가 생기면 어떻게 될까?

NewFancyHtmlTagCleaner 구현체를 하나 더 만들고
설정에서 이렇게만 바꿔주면 된다.

@Bean
public HtmlTagCleaner htmlTagCleaner() {
    return new FailoverHtmlTagCleaner(
            new JsoupHtmlTagCleaner(),
            new JerichoHtmlTagCleaner(),
            new NewFancyHtmlTagCleaner(), // 추가
            new RegexHtmlTagCleaner()
    );
}

서비스 코드(ArticleService, IngestionPipeline 등)는

여전히 HtmlTagCleaner 인터페이스만 알고 있고,

뒤에서 어떤 서드파티들이 줄 서 있는지는 전혀 모른다.

라이브러리를 교체하거나 순서를 바꾸는 일도

구현체 리스트만 건드리면 끝 나기 때문에,

개발자 입장에서 유지보수가 훨씬 편해진다.

테스트: 가짜 Cleaner로 쉽게 시뮬레이션 가능

이 구조의 또 다른 장점은 테스트가 쉽다는 점이다.

예를 들어

“첫 번째 파서가 실패하고, 두 번째 파서가 성공할 때” 케이스를 테스트하고 싶다면
간단하게 이런 가짜 구현체들을 만들어서 넣어줄 수 있다.

class AlwaysFailCleaner implements HtmlTagCleaner {
    @Override
    public String clean(String html) {
        throw new RuntimeException("항상 실패");
    }
}

class AlwaysSuccessCleaner implements HtmlTagCleaner {
    @Override
    public String clean(String html) {
        return "cleaned";
    }
}

그리고 테스트에서는

HtmlTagCleaner cleaner = new FailoverHtmlTagCleaner(
        new AlwaysFailCleaner(),
        new AlwaysSuccessCleaner()
);

String result = cleaner.clean("<p>hello</p>");
// result == "cleaned"

이렇게 시나리오별로 조합해서 넣을 수 있기 때문에,

failover 로직이 제대로 동작하는지
모든 후보가 실패했을 때 raw HTML을 돌려주는지

같은 것들을 쉽게 검증할 수 있다.

운영: 장애가 나도 “어디서, 얼마나”가 보인다

마지막으로, 이 구조는 운영과 모니터링 관점에서도 이점이 있다.

Jsoup에서 예외가 나면 로그에 JsoupHtmlTagCleaner 실패 이유=...

Jericho에서 또 예외가 나면 JerichoHtmlTagCleaner 실패 이유=...

처럼 정확히 어느 레벨에서 실패했는지 남는다.

나중에 로그/메트릭을 보면,

“전체 요청 중 몇 %가 메인 파서에서 처리되었는지”
“얼마나 자주 failover가 발생하는지”
“특정 뉴스레터 발행처에서만 유난히 자주 깨지는 HTML이 들어오는지”

같은 것들을 파악할 수 있다.

무엇보다 중요한 건,

어떤 서드파티 하나가 의도대로 동작하지 않더라도,

메일 저장과 검색 파이프라인 전체가 같이 쓰러지지 않게 막는 구조

라는 점이다.

마무리

정리해 보면, 이번 작업은 단순히 “HTML 태그를 한 번 지워보자” 수준의 문제가 아니었다.

뉴스레터 본문이 대부분 HTML로 들어오고 검색 인덱스 용량과 응답 속도에 직접적인 영향을 주고

서드파티 라이브러리가 언제든지 예상치 못한 방식으로 실패할 수 있기 때문에

“무엇을 쓰느냐” 못지않게 “어떻게 설계하느냐”가 중요했다.

HTML 태그를 지우는 동작이 실패하면 인덱스 10배는 더 들어가고 만약 실패하면 검색기능이 제대로 되지 않기 때문에 어떻게든 동작해야했다.

그래서 봄봄에서는

`Jsoup` 같은 검증된 라이브러리를 1순위로 쓰되 필요하면 다른 파서로 자연스럽게 넘어갈 수 있는 failover 구조를 만들고

서비스 코드에서는 `HtmlTagCleaner`라는 인터페이스만 바라보게 해서 성능·안정성·확장성 사이의 균형을 맞추려고 했다.

앞으로도 새로운 HTML 파서나 텍스트 추출 도구를 도입하게 되더라도,

기존 코드를 뜯어고치기보다는 이 체인에 “후보 하나 추가”하는 수준에서

유연하게 대응할 수 있을 거라고 기대하고 있다.

HTML 태그를 어떻게 지울지 고민하고 있다면,

“정규식으로 한 방에” 대신 어떤 서드파티를 쓸지

그리고 그 서드파티가 실패했을 때 어떻게 다룰지

까지 같이 고민해보면 좋을 것 같다.

봄봄 서비스에 맞게 검색 성능 개선기

개발자성장기 — Mon, 17 Nov 2025 16:23:16 +0900

들어가며

처음에는 검색을 정말 단순한 문제라고 생각했다.
그냥 검색어만 넣으면 결과가 쭉 나오면 되는 거 아닌가?

그런데 직접 구현하고, 부하 테스트까지 돌려 보니
생각보다 함께 고려해야 할 것들이 훨씬 많다는 걸 알게 됐다.
그리고 아마 앞으로도 계속 고민할 지점이 남아 있을 것 같다.

지난 몇 달 동안 검색 기능을 조금씩 만들고 고쳐 오면서 했던 생각들을
드디어 글로 정리하게 되었다.

우리 서버의 검색기능

봄봄 서비스에는 “내가 받은 아티클 안에서 검색하는 기능”이 있다.
처음 구현은 아주 단순했다.

WHERE title LIKE '%:keyword%'
   OR content LIKE '%:keyword%'

즉, 제목이나 본문에 keyword가 어디에라도 포함되어 있으면 검색 결과에 나오도록 한 것이다.

문제는 이 단순함의 대가가 너무 컸다는 거다.

처음에는 괜찮았는데 데이터가 점점 쌓이다보니 일부 검색은 응답시간이 6초까지 나오게 되었다.

이미 페이지는 떴는데, 검색 버튼 한 번 눌렀을 뿐인데 6초를 기다려야 한다면 개발자인 나조차도 안 쓰고 싶다.

❓ 왜 `LIKE %keyword%`는 이렇게 느릴까?

핵심은 간단하다. LIKE '%keyword%'는 일반 B-Tree 인덱스를 제대로 못 탄다.
B-Tree 인덱스는 왼쪽부터 정렬된 값을 기준으로 “어디서부터 읽기 시작할지(start key)”를 잡고 내려가는 구조다.
LIKE abc% → abc로 시작하는 구간을 ['abc', 'abd')처럼 범위로 잡고 range scan이 가능하다.
LIKE %abc% → 앞에 %가 붙어 있어서, 어디서부터 읽어야 할지 시작 지점을 정할 수 없다.

시작 지점을 못 정하면 어떻게 될까?
결국 “그냥 다 훑어본다(풀 스캔)” 쪽으로 떨어진다.

데이터가 조금일 때는 티가 안 나지만, 뉴스레터가 쌓이고 회원이 늘어나면 이 방식은 데이터 양만큼 선형으로 느려지는 구조다.

속도만의 문제는 아니었다.

문제는 성능만이 아니었다.

뉴스·시사 도메인에서 사용자는 종종 이렇게 검색한다.

"기준 금리 인하", "소비 심리"처럼 공백이 섞인 표현을 그대로 입력하거나
정확한 단어 대신 "금리 인하", "소비심리"처럼 조합을 조금 다르게 입력하거나
아예 "리쇼어링"이 아니라 "쇼어링", "연착륙"이 아니라 "착륙"처럼 단어 조각만 떠올리기도 한다.

예를 들어, 최근에 어떤 뉴스레터에서 이런 문장을 봤다고 해보자.

“이번 조사에서 소비 심리 회복이 뚜렷하게 나타났다.”

사용자가 나중에 이 아티클을 다시 찾고 싶을 때
꼭 "소비 심리 회복"을 정확히 입력하지는 않는다.

"소비 심리"만 치기도 하고

"소비심리"라고 붙여 쓰기도 하고

심지어 "심리 회복" 같은 애매한 조각만 떠올릴 수도 있다.

LIKE는 이런 상황에 꽤 까다롭다.

"소비 심리"로 검색하면 본문에 정확히 소비␣심리가 그대로 연속해서 들어 있어야 매칭되고

"소비심리"로 검색하면 소비심리라는 문자열이 통째로 있어야 찾을 수 있다.

결국 LIKE는 “이 문자열 조각이 이 모양 그대로 붙어 있는지” 를 보는 데는 강하지만,

“여러 단어를 토큰처럼 쪼개서, 공백·순서·위치가 조금 달라도 관련 문서를 유연하게 찾아주는 검색” 을 만들기에는 한계가 있다.

도메인 특성상 “부분 검색”은 포기하기 어렵다

여기에 도메인 특성이 얹힌다.

뉴스/시사 도메인에서는

“리… 뭐더라? 리쇼… 리쇼어링?”
“연… 뭐였지, 연착륙? 경착륙?”

처럼 앞·뒤가 흐릿한 상태에서 다시 찾는 일이 너무 많다.
머릿속에 남는 건 온전한 단어 전체가 아니라,
‘쇼어링’, ‘착륙’ 같은 단어 조각인 경우가 대부분이다.

예를 들어, 최근 통계청이 국가데이터처로 승격되었다.

사용자는 익숙하지 않는 표현이라"국가데이터처"를 기억하지 못하고

"국가데이터"까지만 치거나 "데이터처"만 칠 확률이 높다.

이때 관련 뉴스·뉴스레터가 나와야 사용자의 읽기 리듬을 끊지 않고 이어갈 수 있다.

그래서 우리 서비스에서는

“부분만 기억해도, 공백이 섞여 있어도 바로 찾아주는 검색”

을 단순한 편의 기능이 아니라,
뉴스/시사 도메인에 꽤 필수에 가까운 요구사항이라고 판단했다.

하지만 이 요구사항을 만족시키려고 LIKE '%keyword%'를 썼더니

실제 검색 속도는 6초까지 치솟았고,
최소한 1초 이하로는 줄여야 “써볼 만한 기능”이 된다는 점이 드러났다.

그래서 우리는

“부분 검색 + 공백이 섞인 여러 단어 검색 경험은 유지하면서,
LIKE보다 훨씬 빠르게 만들 수 있는 방법이 없을까?”

라는 질문을 들고,
그 다음 단계 설계를 시작했다.

해결 방안 후보

1. 캐싱 계층 적용

자주 검색되는 키워드에 대해 검색 결과를 캐싱해 두는 방법도 고민했다.
쇼핑몰 검색처럼, 모두가 같은 상품 풀에서 `"아이폰"`, `"에어팟"` 같은 키워드를 반복해서 검색하는 서비스라면
한 번 계산한 검색 결과를 여러 사용자가 같이 재사용할 수 있어서 효과가 크다.

하지만 봄봄의 검색은 구조가 조금 다르다.

우리는 “전체 아카이브”가 아니라, 각 사용자가 받은 메일함 안에서만 검색한다.
같은 `"금리 인하"`라는 키워드를 검색해도 A 사용자가 받은 뉴스레터와 B 사용자가 받은 뉴스레터가 다르기 때문에 검색 결과도 완전히 달라진다.

즉, 캐시 키가 유저 수 × 키워드 수만큼 흩어지는 롱테일(long-tail) 구조라
“한 번 캐싱해 두면 여러 사람이 같이 쓰는” 전형적인 캐시 패턴이 아니다.
히트율이 낮을 가능성이 높다는 뜻이다.

정리하면, 우리 서비스는 “자주 반복되는 글로벌 검색 결과를 여러 유저가 함께 쓰는” 구조가 아니라,

“각자 받은 메일박스 안에서, 가끔씩, 제각각 다른 키워드를 검색하는” 구조다.

이런 특성에서는
캐시를 위한 비용과 복잡도에 비해 얻을 수 있는 이득이 크지 않다고 보고,
이번 검색 개선에서는 캐싱 계층 도입은 후보에서 제외했다.

2. 경량 검색 엔진 도입

두 번째로 고민했던 건 Meilisearch / Typesense 같은 경량 검색 엔진을 붙이는 것이었다.
결론만 말하면, 검색 품질과 성능만 놓고 보면 이게 가장 깔끔한 선택이다.

전담 검색 엔진을 쓰면 MySQL만 쓸 때보다 이런 점들이 좋아진다.

더 풍부한 검색 기능
prefix 검색, typo 허용, 필터 + 정렬 조합 등 다양한 쿼리 조합을 자연스럽게 지원한다.

더 나은 관련도 정렬(Relevance)

“어떤 결과가 더 그럴듯한가?”를 점수로 표현하고, 상위 몇 개만 빠르게 가져올 수 있다.

확장성
검색 트래픽이 늘어나면 검색 엔진 인스턴스를 수평 확장해서 대응하기 쉽다.

반대로, MySQL 한 대로 LIKE・기본 FULLTEXT만 쓰는 검색에는 이런 한계가 있다.

한국어에 약함
“리쇼어링 / 리-쇼어링 / 리 쇼어링”처럼 표기가 조금만 달라져도 MySQL 기본 기능만으로는 “같은 단어다”라고 이해시켜 주기가 어렵다.

동의어 처리 없음
“연착륙 / 소프트 랜딩”, “금리 인상 / 긴축”처럼 다른 단어지만 비슷한 맥락인 것들을 한꺼번에 묶어 주려면 직접 전처리·매핑 로직을 짜야 한다.

페이징 성능
OFFSET / LIMIT 기반 페이징은 데이터가 쌓일수록 뒤 페이지로 갈수록 점점 느려진다.

부분 단어 검색의 구조적 한계
N-gram 같은 기능을 활용해 부분 검색을 구현할 수는 있지만, 인덱스 용량과 버퍼 풀 사이즈 안에서 어느 시점에는 타협이 필요하다.

뉴스/시사 도메인은 “단어가 아니라 단어 조각으로 검색하고 싶은” 도메인이라
이런 고급 검색 기능이 있으면 확실히 품질을 더 끌어올릴 수 있다.

그럼에도 우리는 검색 엔진 도입을 이번에는 보류했다.

이유는 두 가지 정도로 정리할 수 있다.

1. 비용 문제
Meilisearch / Typesense를 쓰려면 MySQL과는 별도로 항상 떠 있는 인스턴스 1개 이상이 필요하다.
지금도 t4g.micro / t4g.micro 조합으로 인프라 비용을 아껴가면서 운영하고 있어서, 여기에 “검색 엔진 전용 인스턴스”까지 추가하는 건 현재 팀 상황에서는 부담이 컸다.

2. 우리 서비스에서 검색의 위치

봄봄에서 검색은 “하루에도 몇 번씩 누르는 메인 기능”이라기보다는,
“필요한 순간엔 반드시 잘 되어 있어야 하는 기능”에 가깝다.

예전에 훑어본 뉴스레터를 다시 찾아보거나,
구독을 고민하면서 “그때 그 메일 다시 보고 싶다” 싶은 순간에 주로 쓰인다.
사용 빈도는 높지 않지만, 한 번 검색할 때마다의 중요도는 꽤 높은 편이다.

그래서 이런 질문을 다시 꺼내 들었다.
“지금 단계에서, 전용 검색 엔진을 붙일 만큼 검색이 비즈니스의 한가운데에 와 있을까?”

내린 결론은 이거였다.

“아직은 아니다.”

정리하자면, 검색 엔진이 더 나은 해답인 건 분명하지만,
현재 트래픽과 팀 리소스, 서비스 단계까지 함께 놓고 보면
지금은 검색 엔진까지 도입하는 것이 투자 대비 과한 선택에 가깝다고 판단했다.

정리하면, 검색 엔진은 분명 더 좋은 해답이지만, 지금 팀의 리소스와 서비스 단계에서는 과투자에 가깝다고 판단했다.

3. MySQL 플러그인 사용

Mroonga는 MySQL에서 쓸 수 있는 스토리지 엔진 플러그인이다.
안쪽에는 Groonga라는 전문 검색 엔진이 들어 있고,

이걸 MySQL에서 바로 쓸 수 있도록 감싼 형태라고 보면 된다.

공식 설명을 한 줄로 정리하면 대략 이런 느낌이다.

“중국어·일본어·한국어를 포함해 모든 언어에서 빠른 전문 검색을 제공하는 MySQL용 스토리지 엔진

왜 한국어에 Mroonga가 잘 맞을까?

한국어 검색이 힘든 이유는 띄어쓰기 믿기 어렵고 조사, 어미, 합성어가 많고 외래어, 영문, 숫자까지 뒤섞이기 때문이다.

기본 InnoDB FULLTEXT는 영어 기준으로 설계되어 있어서,
중국어·일본어·한국어(CJK) 텍스트에는 잘 맞지 않는다는 게 늘 문제였다.

Mroonga/Groonga 쪽은 애초에 CJK 텍스트용 전문 검색 엔진이다.

N-gram 방식으로 “문자 조각” 기준 검색을 잘 지원하고

다양한 토크나이저(tokenizer)를 통해 언어 특성에 맞게 쪼개서 인덱싱해준다.

그래서 한국어에서도 쇼어링만 쳐도 리쇼어링, 프렌드쇼어링 같은 것들을 잘 찾아주고 "데이터처"만 쳐도 "국가데이터처" 관련 글을 잘 집어내고 인덱스 기반이라 속도도 MySQL 기본 LIKE, 기본 FULLTEXT보다 훨씬 빠른 편이다.

하지만 우리 상황에서는 사용불가능하다.

우리가 사용하는 DB는 RDS mysql이다

RDS mysql은 플러그인 사용이 불가능하다.

플러그인을 설치하는 데 필요한 모든 조건을 RDS가 막아놓았기 때문에 결과적으로 불가능한 것이다.

mysql 플러그인 설치에는 아래 3개가 반드시 필요하다.

1. OS에 .so파일 업로드(shared Library) -> RDS는 OS 접근 자체가 불가능

2. Mysql 플러그인을 활성화를 위해 `INSTALL PLUGIN mroonga SONAME 'ha_mroonga.so'` 해당 명령어 입력 필요 -> RDS는 SUPER 권한을 안 줌

3. 플러그인 설치 시 내부적으로 파일 읽기 작업이 발생하는데 RDS는 file 권한 역시 차단

그럼 aws에서는 이걸 왜 막을까?

AWS는 RDS를 다음과 같은 서비스로 정의함

“운영을 AWS가 대신 관리해주는 Managed Database 서비스.”

Managed DB에서 AWS가 책임지는 영역

DB엔진 설치/업데이트/패치
백업/복구
모니터링
장애 자동 감지 / Failover
버전 호환성 유지
보안 패치 자동 적용

플러그인이 설치되면 이 모든 보장이 깨질 수 있음.

플러그인이 버전별 호환성을 망가뜨리거나,
업데이트할 때 죽어버리거나,
crash recovery에 간섭할 수 있음.

AWS는 이 리스크를 관리할 방법이 없기 때문에 일괄적으로 막는다.

정리해보면 한국어 검색 품질과 성능만 놓고 보면
Mroonga는 굉장히 매력적인 해법이지만,
“우리가 RDS MySQL을 쓰기로 한 인프라 선택” 때문에
현실적으로는 고려할 수 없는 옵션이었다.

4. Full-text Search

Full-text Search는 말 그대로 문서의 전체 텍스트를 대상으로 검색하는 기능이다.
문장/본문이 긴 컬럼을 통째로 훑는 대신,
먼저 텍스트를 분석해서 검색용 인덱스(역색인)를 만들어 두고
나중에 검색할 때는 이 인덱스를 통해 빠르게 후보를 찾는 방식으로 동작한다.

Full-text Search 동작 방법

1. 토큰화

문장을 단어 단위로 잘게 쪼갠다.

ex) "연착륙 전망 나오는 미국 경제"

-> ["연착륙", "전망", "나오는", "미국", "경제"]

2. 역색인(Inverted Index) 생성

각 단어가 어디에서 등장하는지 역으로 저장한다.

ex) "연착륙" -> [문서 3, 문서 10, 문서 25]

미국 -> [문서 1, 문서 3, 문서 8, 문서 25]

이런 구조를 역색인라고 부른다.

기존 B-Tree 인덱스가 PRIMARY KEY -> 행을 찾는 지도라면, 역색인은 단어 -> 이 단어가 들어간 문서들을 찾는 지도에 가깝다.

3. 검색 시 빠른 조회

사용자가 "연착륙 미국"을 검색하면, "연착륙"이 들어간 문서 목록과 "미국"이 들어간 문서 목록을 가져와서 교집합을 구하는 식으로, 해당 단어들이 포함된 문서를 바로 찾는다. 이 과정에서 테이블 전체를 풀 스캔할 필요가 없다.

4. 관련도 점수 계산(Scoring)

Full-text Search는 단순히 "포함 여부"만 보는게 아니라,

- 이 단어가 몇 번 나왔는지

- 제목에 있는지, 본문에 있는지

- 전체 텍스트 대비 비율은 어떤지

같은 것들을 이용해 관련도 점수(score)를 매긴다.

그리고 이 점수를 기준으로 ORDER BY score DESC 정렬을 해 주기 때문에,

사용자가 보기에도 "더 그럴듯한 결과"가 위로 올라온다.

다만 MySQL의 `FULLTEXT` 검색은 기본적으로
영어 및 공백 기반 언어에 잘 맞게 설계되어 있다.

공백·구두점을 기준으로 단어를 나누고 형태소 분석을 따로 해주지는 않는다.

그래서 한글 뉴스 본문처럼 띄어쓰기가 애매하거나 조사/어미/합성어가 많고 외래어, 영어, 숫자가 섞여 있는 텍스트에 대해서는
“그럭저럭 동작은 하지만, 한국어에 완전히 최적화된 검색이라고 보긴 어렵다.” 라는 한계가 있다.

이 빈 부분을 우리는 n그램 + FULLTEXT 혼합 전략으로 어느 정도 보완해 보려 했다.

우리가 선택한 방법

여러 가지 대안을 검토한 끝에,
우리는 RDS MySQL에서 제공하는 FULLTEXT Search(기본 파서 + ngram 테이블을 함께 쓰는 구조)를 선택했다.

이유는 아래와 같다.

1. 추가 인프라 비용이 들지 않는다.
   Elasticsearch / Meilisearch / Typesense 같은 검색 전용 엔진을 새로 띄우지 않고,  현재 사용 중인 RDS MySQL 안에서 해결할 수 있다.

2. 기존 MySQL 운영/백업 체계를 그대로 활용할 수 있다.
   검색 전용 테이블과 FULLTEXT 인덱스도 RDS 자동 백업/스냅샷에 같이 포함되기 때문에 장애 대응, 복구, 모니터링을 별도로 설계할 필요가 없다.

3. `LIKE '%keyword%'`와 비슷한 사용자 경험을 유지하면서, 인덱스 기반으로 훨씬 빠르게 동작한다.
   사용자 입장에서는 여전히 “키워드를 치면 아티클이 나온다”는 흐름이 그대로이고,
부분 검색 + 공백이 섞인 여러 단어 검색도 어느 정도 받아준다.
   대신 서버 입장에서는 테이블 풀 스캔이 아닌  FULLTEXT 인덱스(ngram + 기본 파서)를 사용하기 때문에
   데이터가 쌓여도 검색 응답 시간이 훨씬 안정적으로 유지된다.

4. 관련도(relevance) 점수 기반 정렬을 통해, ‘더 그럴듯한 결과’를 위에 올릴 수 있다.
   Full-text Search는 단순히 포함 여부만 판단하는 것이 아니라
   키워드 등장 빈도, 위치 등을 기반으로 점수를 계산해 준다.
   우리는 `ORDER BY score DESC, published_at DESC` 형태로 정렬해
   “검색어와 더 잘 맞으면서도 최신에 가까운 아티클”이 상단에 노출되도록 했다.

관련도 점수 계산

관련도 점수 계산

MySQL MATCH() AGAINST()가 점수를 계산할 때 기본 아이디어는 언어 안 가린다.

- 어떤 '토큰(단어/조각)' 들이 문서에 있고

- 검색어에서 온 토큰과 얼마나 겹치고

- 문서에서 얼마나 자주 나오고

- 전체 길이에 비해 어느 정도 비율을 차지하는지

이런 걸 가지고 relevance scroe를 만든다.

이 로직은 영어/한글/숫자/기호 가리지 않고 "토큰 단위"로 동작한다.

토큰만 잘 뽑혀 있으면 점수는 무조건 나온다.

차이점의 핵심: “토큰이 뭐냐”가 언어별로 다르다

차이는 여기서 생긴다.

1. 영어 (기본 parser)

영어는 대략 이런 식으로 토큰이 생성된다.

"Reshoring is coming back to the US"
→ ["reshoring", "coming", "back", "us"]

검색어가 "reshoring"이면

"reshoring"이 포함된 문서만 고르고
등장 횟수/위치/문서 길이 기반으로 점수 계산

즉, “단어 = 의미 단위”에 상당히 가깝게 떨어진다.
그래서 관련도 점수가 “실제 의미 관련도”랑 비슷하게 느껴진다.

2. 한글 + 기본 parser

한글은 공백이 있을 땐 그럭저럭 괜찮다.

"연착륙 전망 나오는 미국 경제"
→ ["연착륙", "전망", "나오는", "미국", "경제"]

이 정도면 "연착륙" 검색 시 점수가 꽤 그럴듯하게 나온다.

그런데

"연착륙이냐 경착륙이냐" → 조사/어미까지 붙어서 한 덩어리
- ["연착륙이냐", "경착륙이냐"]
"리쇼어링/리-쇼어링/리 쇼어링" → 표기 다 다름

여기서부터 사람이 보기엔 “다 같은 개념”인데 Full-text 입장에선 완전히 다른 토큰이라 관련도 점수가 허당처럼 느껴질 수 있다.

그래서 “영어에 비해 한글 관련도 별로다”라는 말이나온는 것이다.

3. 한글 + ngram parser

ngram 파서를 쓰면 토큰이 이렇게 바뀐다 (예: 2글자 n-gram)

"리쇼어링" → ["리쇼", "쇼어", "어링"]
"리 쇼어링" → 공백/기호 기준으로 나뉘면서도, 내부에서는 다시 2글자 단위로 쪼개짐
"연착륙이냐 경착륙이냐"
→ 대충 ["연착", "착륙", "륙이", "이냐", "경착", "착륙", ...] 이런 느낌

검색어 "쇼어링" → ["쇼어", "어링"]

그럼 점수 계산은 이런 느낌으로 이다.

이 문서의 n-gram 리스트랑
검색어의 n-gram 리스트를 비교해서
얼마나 많이 겹치는지 + 전체 대비 비율로 점수 계산

그래서

“리쇼어링” / “리-쇼어링” / “리 쇼어링”
- 전부 "쇼어", "어링" 같은 공통 n-gram을 공유
  → 관련도 점수가 “나름 그럴듯하게” 나온다
“연착륙”, “연착륙이냐”
- ["연착", "착륙", ...] 같은 공통 n-gram 공유
  → 이것도 꽤 잘 잡힌다

하지만 이때의 관련도 점수는

“이 문서와 검색어가 같은 의미를 가지냐”가 아니라
“이 문서와 검색어가 같은 글자 조합을 많이 공유하냐” 이다.

다만 여기에는 한 가지 문제점이 있다.

MySQL Full-text Search를 쓰면 기본 파서(Buil-In Parser)는 공백과, 쉼표(,), 마침표(.) 같은 구분자 문자를 기준으로 단어의 시작과 끝을 판별해서 텍스트를 토큰으로 분리한다.

(공식 문서: The built-in FULLTEXT parser determines where words start and end by looking for certain delimiter characters…)

영어처럼 단어 사이에 항상 띄어쓰기가 있는 언어에서는 이 방식이 잘 맞는다.

문제는, 한국어는 띄어쓰시가 "단어 경계 = 의미 단위"와 거의 맞지 않는다는 점이다.

예를 들어 이런 문장이 있다고 하자

한국은행이 기준금리를 인상했다.

Built-in parser / Natural Language 모드에서는 다음처럼 토큰화된다.

["한국은행이", "기준금리를", "인상했다"]

그리고 Full-text Search는 이 토큰들을 기준으로 검색을 수행한다.

중요한 점은 기본 Natural Language 모드에서는 prefix / 부분 문자열 검색을 지원하지 않는다는 것이다.

그래서 매칭 동작은 대략 아래와 같다.

built-in parser + Natural Language 모드 (모두 기본값)

토큰	검색어	매칭 여부	이유
기준금리를	기준	❌ X	단어 중간 substring → 미지원
기준금리를	기준금리	❌ X	prefix(접두어) 매칭 → 미지원
기준금리를	기준금리를	✅ O	토큰 전체와 검색어가 완전히 일치할 때만 매칭
인상했다	인상	❌ X	어근 수준 분석 없음, 부분 문자열 미지원
인상했다	인상했다	✅ O	단어 전체가 동일할 때만 매칭

이렇게 단어 전체가 동일할 때만 매칭되기 때문에, 우리가 직관적으로 기대하는 것처럼

- "기준금리"로 검색했을 때 "기준금리를"이 자동으로 잡힌다거나

- "인상"으로 검색했을 때 "인상했다"가 함께 매칭된다거나

하는 "부분 검색" 경험을 주기 어렵다.

그래서 한국어에서는, 기본 Built-in parser + Natural Language 모드만으로는 한글 부분 검색 요구를 충족하기 힘들고,

이 때문에 ngram 파서를 고려하게 되었다.

한글의 부분 검색을 자연스럽게 지원하려면, Full-text Search의 파서를 기본값대신 'ngram' 파서로 바꾸는 게 더 잘맞는다.

ngram은 말 그대로 텍스트를 N글자 단위로 잘게 쪼개는 방식이다.

예를 들어 2-gram 기준으로 보면

"금리인상" -> ["금리", "리인", "인상"]

이렇게 잘게 쪼개 두면 사용자가 "금리 인상"을 검색했을 때 "금리", "인상" 이라는 조각이 겹치는 문장들을 찾을 수 있다.

즉, ngram 파서는 "단어 단위 의미 분석"이라기보다 "글자 조각이 얼마나 많이 겹치냐"를 기준으로 검색하는 방식이라고 볼 수 있다.

완벽한 한국어 형태소 분석 수준은 아니지만, 기본 full-text의 공백 기반 파서보다 우리가 기대한 "부분 검색" 경험에 훨씬 가깝고 여전히 Full-text 인덱스를 사용하기 때문에 성능도 충분히 확보할 수 있다.

그렇지만 여기서 고려해야할 부분이 또 있다.

바로 인덱스의 크기이다.

ngram 파서를 쓰면, 인덱스가 폭발적으로 늘어난다.

ngram은 텍스트를 n글자 단위로 잘게 쪼개기 때문에 같은 문자열이라도 토큰 개수가 기본 파서보다 훨씬 많아진다.

ngram으로 바꾸는 순간 동일한 문장을 훨씬 더 많은 토큰으로 나눠서 인덱스에 저장하게 된다.

서비스 전체로 보면 이 차이는 더 크게 누적된다.

토큰 수가 몇 배까지도 쉽게 뛰어오르고, 그만큼 인덱스 크기도 커진다.

인덱스가 크기가 단순히 디스크만 조금 더 쓰는 문제에서 끝나면 좋겠지만

실제로는 MySQL 입장에서는 꽤 많은 부담이 생긴다.

디스크 용량 압박
- Full-text 인덱스는 일반 인덱스보다도 덩치가 크다.
- ngram까지 쓰면 “본문 컬럼 + 인덱스”가 합쳐져서 테이블 용량이 훅 커진다.
- RDS처럼 디스크를 넉넉하게 잡기 힘든 환경에서는 꽤 부담된다.
버퍼 풀(메모리) 부담
- InnoDB는 인덱스 페이지도 버퍼 풀에 올려서 캐싱한다.
- 인덱스가 커질수록, 같은 메모리에서 더 많은 페이지를 돌려 써야 한다 → 캐시 히트율이 떨어짐.
- 그만큼 디스크 I/O가 늘고, 검색/쓰기 성능이 서서히 떨어진다.
쓰기(INSERT/UPDATE) 비용 증가
- 한 번 INSERT를 할 때마다, ngram 토큰 개수만큼 인덱스에 엔트리가 들어간다.
- “문자열 1개 → 인덱스 1번”이 아니라
  “문자열 1개 → ngram 토큰 수만큼 여러 번 인덱스 갱신”이 일어나는 셈이다.
- 뉴스레터처럼 글이 계속 쌓이는 서비스라면 이 쓰기 비용도 무시하기 어렵다.

결국, ngram은 검색 품질과 한글 부분 검색 경험을 개선해 주는 대신,
인덱스 크기와 자원 사용량이라는 꽤 큰 대가를 요구한다.

그래서 어디선가는 타협을 해야 한다.

우리는 먼저 기술적인 타협보다, 비즈니스적인 타협부터 살펴봤다.

우리 서비스의 구독자 대부분은 뉴스 분야를 구독하고 있다.
뉴스의 특성상, 어제 본 기사도 하루만 지나도 가치가 빠르게 떨어지고,
일주일 전 기사는 “검색해서 다시 읽을 만한 기사”의 비율이 훨씬 낮다.

그래서 이렇게 생각했다.

“모든 기간 데이터를 완벽한 한글 부분 검색으로 지원하기보다는,
사용자가 실제로 많이 찾는 ‘최근 뉴스’에만 ngram의 비용을 집중하자.”

구체적으로는 ngram 인덱스는 최근 5일 치 데이터에만 적용하고,
그 이후의 데이터는 기본 파서 기반 Full-text 인덱스로만 두는 방식을 택했다.

이렇게 하면, 사용자가 가장 자주 찾는 최신 뉴스는 ngram 덕분에 "부분 검색 경험"을 충분히 제공하고 상대적으로 조회가 적은 예전 뉴스들은 인덱스를 과하게 부풀리지 않고, 저장 공간,버퍼 풀 부담도 줄일 수 있다.

즉, 모든 데이터를 완벽하게 검색할 수 있게 하기 대신 자주 검색되는 구간에 비용을 집중하는 전략으로 타협

그렇다면 왜 최근 5일치인가?

사실 5일보다 7일이나 15일정도로 더 잡고 싶었지만 5일이 한계다.

MySQL(InnoDB)은 디스크에 있는 데이터를 바로 읽어 쓰지 않고,

버퍼 풀(Buffer Pool)이라는 메모리 캐시에 올려 두고 사용한다.

- 버퍼 풀이 넉넉하면 자주 쓰는 데이터, 인덱스가 메모리에 머물러서 빠르게 응답할 수 있지만

- 버퍼 풀이 작으면 디스크 I/O가 급격히 늘어나면서 전체 성능이 눈에 띄게 떨어진다.

우리가 사용하는 RDS MySQL 인스턴스는 t4g.micro이고, 메모리는 1GB이다.

AWS에서 이 구간의 innodb_buffer_pool_size 최대값을 384MB 정도로 제한하고 있어서 결국 Full-text / ngram 인덱스가 쓸 수 있는 메모리 예산도 그 안에서 해결해야 한다.

버퍼 풀(buffer pool)

1. 버퍼 풀??

MySQL(InnoDB)은 실제 데이터(테이블, 인덱스)를 디스크에 저장한다.

그런데 디스크에서 직접 읽고 쓰는 건 엄청 느리다.

그래서 InnoDB는 이렇게 행동한다.

1. 디스크에서 데이터를 읽을 때 한 페이지(보통 16KB) 단위로 가져와서 메모리(버퍼 풀)에 올려둔다.

2. 그 다음 같은 데이터를 또 읽을 읽이 생기면 디스크 말고 버퍼 풀(메모리)에서 바로 읽는다.

3. 데이터를 변경(insert/update/delete)할 때도 먼저 버퍼 풀에 있는 페이지를 수정하고 나중에 디스크에 천천히 반영한다.

즉, 버퍼풀은 자주 쓰는 데이터/인덱스를 메모리에 캐싱해 두는 큰 바구니라고 생각하면 된다.

2. 버퍼 풀 사이즈(buffer pool size)란?

값이 크면 더 많은 데이터/인덱스를 메모리에 올려둘 수 있어서 디스크를 덜 읽고 조회/쓰기 성능이 좋아진다. 다만 너무 크게 잡으면 OS나 다른 프로세스가 사용할 메모리가 부족해 질 수 있고 swap 걸리면 오히려 성능이 망가진다.

그래서 AWS RDS는 안전하게 40% ~50% 이하로 주고있다.

값이 작으면 캐시 미스가 자주 일어나고 이는 디스크 I/O가 폭증으로 이어지고 이로인해 쿼리 응답 시간이 기하급수적으로 느려질 수 있다.

왜 전체 아티클에 n그램을 못 걸고, ‘최근 5일’만 선택했을까?

먼저 우리가 서 있는 인프라부터 짚고 가야 한다.

우리가 사용하는 DB는 RDS MySQL db t4g.micro이고, 이 인스턴스의 RAM은 1GB다.
MySQL에서는 디스크에 있는 데이터를 메모리에 캐싱해 두기 위해 InnoDB 버퍼 풀이라는 공간을 사용한다.

AWS 공식 문서를 보면, RDS for MySQL에서는 MySQL 8.4 기준으로 기본적으로 `innodb_dedicated_server`를 켜두고,
“DB 인스턴스 메모리를 기준으로 `innodb_buffer_pool_size`를 자동 계산”하도록 되어 있다.

micro 이면 처음 기본값은 128MB

실제로 우리는 `innodb_buffer_pool_size`를 640MB로 설정해 봤는데,
SHOW VARIABLES로 확인해 보면 값이 402,653,184(≈ 384MB)로 잡혀 있었다.
설정을 더 크게 줘도, RDS가 인스턴스 메모리 비율에 맞게 384MB 정도로 깎아서 적용한 것이다.

640MB로 설정했지만 실제 적용은 최적화 값인 384MB로 설정되는 것을 볼 수 있음

정리하면, 이 인스턴스(t4g.micro)에서 우리가 실제로 쓸 수 있는 InnoDB 버퍼 풀은 대략 384MB 정도가 상한선이라고 보는 게 현실적이다. 그리고 이 384MB 안에서 검색 인덱스 + 나머지 모든 쿼리/데이터가 함께 살아야 한다.

“Ngram을 전체적용 한다면?”

처음에는 솔직히 이렇게 생각했다.

“그냥 전체 아티클에 ngram 인덱스를 걸어버리면
한글 부분 검색도 잘 되고, 품질은 제일 좋지 않을까?”

하지만 MySQL이 제공하는 ngram 풀텍스트 파서는,
문장을 고정 길이 n글자씩 잘게 쪼개서 인덱싱하는 구조라 토큰 수가 급격히 늘어난다.

전 기간 아티클 전체에 ngram 인덱스를 걸면 인덱스 용량이 폭발하고,
384MB짜리 버퍼 풀로는 자주 쓰이는 인덱스/데이터를 메모리에 유지하기가 사실상 불가능해진다.

그래서 전략을 이렇게 바꿨다.

“전체를 ngram으로 도배하는 건 욕심이고,
버퍼 풀 안에서 감당 가능한 범위만큼만 ngram을 쓰자.
나머지는 MySQL이 기본으로 제공하는 FULLTEXT 인덱스를 최대한 활용하자.”

그 결과 나온 게 바로,

최근 5일치 → n그램 FULLTEXT 인덱스
그 이후 전 기간 → MySQL 기본 FULLTEXT 인덱스(기본 파서)

라는 하이브리드 전략이다.

그렇다면 이 5일이라는 기간을 어떻게 잡았을까?

아티클·인덱스 용량 가정

버퍼 풀 안에서 ngram을 얼마나 쓸 수 있을지 보려면,
대략이라도 아티클 1건당 용량을 계산해 봐야 했다.

일단 우리 서비스가 현재 기준으로 대략 300명이니까 근시일 목표로하자면 아래와 같다.

회원 수: 500명
1인당 하루에 받는 뉴스레터 수: 4개
⇒ 서버 입장에서 하루에 받는 아티클 수
500명 × 4개 = 2,000개

각 아티클의 텍스트 크기는 대략 이렇게 잡았다.

원본 뉴스레터 본문(HTML 태그 포함): 8천자 ~ 1만 5천자
HTML 태그 제거 후 실제 텍스트: 약 1,000자 정도로 가정
한글/영문 섞인 UTF-8 기준
- 한글 1글자 ≒ 3바이트
- 영문 1글자 ≒ 1바이트
- 보수적으로 한글 기준 3바이트로 계산
본문: 1,000자 × 3바이트 ≒ 3KB
제목: 보통 30자 안팎 → 30자 × 3바이트 ≒ 0.1KB

그래서 텍스트 자체만 보면 1건당 텍스트 용량 ≒ 3.1KB

여기에 n그램 인덱스까지 포함해서, 보수적으로 1건당 10KB 정도를 사용한다고 가정했다.

(즉, 10KB는 “인덱스만”이 아니라 “텍스트 + ngram 인덱스 전체”에 대한 근사치다.)

5일치 n그램 인덱스가 차지하는 메모리

이제 이 가정으로 실제 숫자를 계산해 보면

1건당: 10KB
하루 아티클 수: 2,000건
5일치 아티클 수: 2,000건 × 5일 = 10,000건

따라서,

10,000건 × 10KB = 100,000KB ≒ 97.7MB

즉, 최근 5일치 아티클에 대해 n그램 인덱스를 건다고 가정하면 약 98MB 정도의 메모리를 사용하게 된다.

우리가 줄 수 있는 InnoDB 버퍼 풀 최대값이 384MB이기 때문에,

98MB ≒ 버퍼 풀의 약 25%

정도로만 n그램 인덱스 + 텍스트 캐싱에 쓰고,
나머지 75%는 다른 테이블/쿼리/작업들이 사용할 수 있게 남겨두는 전략이다.

여기서 “버퍼 풀의 25%를 검색에 쓴다”는 말은
버퍼 풀을 파티션 나눠서 100MB를 검색 전용으로 락 걸어둔다는 뜻이 아니다.

단지,“최근 5일치 n그램 인덱스의 작업 세트가 대략 100MB 안에서 움직일 것 같다” 라고 추정한 값이고,
버퍼 풀 자체는 여전히 모든 워크로드가 함께 공유하는 캐시다.

그래서 검색은 어떻게 동작하냐? (n그램 + FULLTEXT 혼합 전략)

중요한 건, 우리는 단순히 “최근 5일만 빠르게 보이기 위해 n그램을 썼다” 에서 끝내고 싶었던 게 아니다.
사용자 입장에서는

띄어쓰기가 들어간 검색이든 ("항공 연착률")
단어 중간만 잘라 치는 검색이든 ("연착", "착률")
영어/숫자가 섞인 검색이든

가능한 한 다양한 형태의 검색이 “된다”는 경험을 주고 싶었다.

그래서 실제 검색 로직은 이렇게 동작한다.

최근 5일치 + ngram FULLTEXT 인덱스 검색
- 한글을 n자씩 잘라 인덱싱하기 때문에 연착, 착률 같은 부분 검색에 강하다.
- 검색어에 띄어쓰기가 있어도, 내부적으로는 n그램 토큰으로 잘게 쪼개져서
  "항공 연착률" → 항공, 연착, 착률, … 같은 조합으로 매칭된다.
전 기간 + 기본 FULLTEXT 인덱스(기본 파서) 검색
- 원본 article 테이블에는 MySQL 기본 파서 기반의 FULLTEXT 인덱스도 걸려 있다.
- 이 인덱스는 공백을 기준으로 단어를 나누기 때문에 "항공 연착률"은 항공, 연착률 단위로 깔끔하게 처리된다.
- 덕분에 오래된 아티클까지 포함해서 전 기간 데이터를 단어 기준으로 검색할 수 있다.
두 결과를 합쳐서 하나의 검색 결과로 반환
- 동일한 아티클이 양쪽에서 모두 걸리면 하나로 합치고,
  최근순 + 관련도 같은 기준으로 다시 정렬한다.
- 사용자는 “지금 이 키워드를 검색했을 때 나올 수 있는 결과”를
  n그램 + 기본 FULLTEXT를 모두 활용한 합산 결과로 보게 된다.

이 구조 덕분에 사용자는

“띄어쓰기를 어떻게 넣어야 하지…?”를 고민하지 않아도 되고,
"연착률", "연착", "항공 연착률"처럼 조금씩 다르게 쳐도
그나마 합리적인 결과를 볼 수 있으며,
최근 며칠치 아티클에 대해서는 부분 검색까지 포함해서 더 빠르고 풍부한 결과를 얻고,
오래된 아티클에 대해서도 기본적인 단어 기준 검색은 계속 가능하다.

“그런데 검색에 25%나 쓸 만큼 중요한가요?”

자연스럽게 나올 수 있는 질문이다.

“검색이 DAU 대비 엄청 자주 쓰이는 기능도 아닐 텐데,
메모리 25%나 쓸 만큼 가치가 있어?”

사용 빈도만 놓고 보면,
피드 스크롤이나 홈 화면 진입보다 검색은 분명 덜 쓰일 수 있다.

하지만 검색 버튼을 누르는 순간만 놓고 보면 얘기가 완전히 달라진다.

검색을 쓰는 상황은 대체로 이렇다.

“예전에 봤던 그 뉴스레터 한 편을 꼭 다시 찾고 싶을 때”
“며칠 전에 읽었던 글인데, 정확한 제목은 기억이 안 날 때”
“특정 키워드로 관련된 아티클을 한 번에 모아보고 싶을 때”

이때 검색이 6초씩 걸리거나, 결과가 엉뚱하게 나온다면
사용자는 한 번에 이렇게 느낀다.

“어… 이 서비스에 내 뉴스레터를 계속 맡겨도 되나?”

검색은 “매일 자주 쓰는 기능”은 아닐 수 있지만,
“필요한 순간의 중요도가 매우 높은 기능”이다.

특히 봄봄처럼 “내 메일박스에 쌓여 있는 콘텐츠를 대신 관리해주는 서비스”라면,
“언제든지 다시 찾아볼 수 있다”는 감각이 서비스 신뢰와 직결된다고 생각했다.

그래서 우리는 이렇게 타협했다.

“검색 사용률은 낮지만, 검색이 필요한 순간의 중요도는 높다.
→ 그렇다면 검색을 완전히 포기하기보다는,
메모리 예산 안에서 ‘최근 5일’만이라도 확실히 빠르고,
다양한 형태의 검색을 받아줄 수 있게 만들자.”

여기서 25%라는 수치는 “검색이 너무 중요하니까 무조건 25%를 박제했다”가 아니라,

현재 인프라(t4g.micro + 384MB 버퍼 풀) 기준에서
“n그램 기간을 3일·5일·7일 중 어디쯤 두면 좋을까?”를 고민하면서 잡은
초기 가설값에 가깝다.

지금은 굉장히 보수적으로 잡았기 때문에 이보다 낮을 확률이 더 높다.

실제 운영에서는 버퍼 풀 히트율, 검색 사용량, 전체 쿼리 성능을 계속 보면서

5일을 3일로 줄이거나,
오히려 7일로 늘리거나,

하는 식으로 계속 조정할 계획이다.

왜 LIKE보다도 빠를까?

마지막으로, 이런 의문도 들 수 있다.

“n그램 한 번, 기본 FULLTEXT 한 번이면
쿼리를 두 번이나 치는 건데,
LIKE '%키워드%' 한 번보다 느린 거 아냐?”

하지만 구조를 뜯어 보면 완전히 다르다.

LIKE '%키워드%'
- B-Tree 인덱스를 탈 수 없어서
  사실상 테이블 전체를 훑는 것과 크게 다르지 않다.
- 데이터가 쌓일수록 검색 시간이 행 개수에 비례해서 늘어난다.
MATCH AGAINST (ngram / 기본 FULLTEXT)
- 미리 만들어 둔 역색인(토큰 → 아티클 id 목록) 에서
  “이 토큰을 포함하는 아티클 id”만 빠르게 뽑는다.
- 즉, 전체 N개 중에서 필요한 것들만 골라 읽는 구조라
  데이터가 늘어나도 LIKE처럼 폭발적으로 느려지지 않는다.

결국 우리가 선택한 것은,

“버퍼 풀이라는 한정된 자원 안에서,
전체를 n그램으로 도배하지 않으면서도
한글 부분 검색 + 띄어쓰기 포함 검색 + 전 기간 검색을
최대한 모두 만족시키기 위한
‘최근 5일 n그램 + 전 기간 FULLTEXT’ 혼합 전략”이다.

⚒️ 실제 적용 & 부하 테스트

말로만 “LIKE보다 빠르다”라고 할 수는 없으니,
실제 서비스를 기준으로 부하 테스트를 돌려봤다.

테스트 조건은 다음과 같다.

- 도구: k6
- 시나리오: `ramping-vus`
  - 10 VU → 30 VU (2분)
  - 30 VU → 60 VU (2분)
  - 60 VU → 100 VU (2분)
  - 이후 1분 동안 0 VU까지 감소
- 한 VU는 2초에 한 번씩 검색 수행
- 검색 키워드:
  - `makeNaturalKoreanKeyword()`로 생성한 자연스러운 한글 조합*
  - 예) `뜨거운 경제`, `뉴스 성장`, `콘텐츠 기록` 등
- k6 스크립트에서는 `endpoint:search` 태그를 달아서
  검색 API만 따로 지표를 뽑을 수 있게 했다.

group('search-only', () => {
  const keyword = makeNaturalKoreanKeyword();
  const searchUrl = `${BASE}/api/v1/articles?keyword=${keyword}&limit=10`;

  const res = http.get(searchUrl, {
    headers,
    cookies: COOKIE,
    tags: { endpoint: 'search' },
  });

  check(res, { 'search 200': (r) => r.status === 200 });
  warnSlow(res, 'search');
});

BEFORE: LIKE '%keyword%' 기반 검색

먼저 기존 구현이었던 LIKE '%keyword%' 기반 검색에 대해 같은 시나리오로 돌려봤다.

http_req_duration{endpoint:search}
- 평균(avg): 약 4.03s
- p95: 약 10.34s

검색 한 번에 10초를 넘기는 구간이 적지 않게 존재했고,
사실상 “검색 버튼을 누르면 한참 기다려야 하는 서비스”에 가까운 상태였다.

AFTER: ngram+ FULLTEXT 혼합 검색

이후, 본문에서 설명한 것처럼

최근 5일치: n그램 FULLTEXT 인덱스
전 기간: 기본 FULLTEXT 인덱스

를 함께 사용하는 검색으로 교체한 뒤, 똑같은 조건으로 다시 부하 테스트를 돌렸다.

http_req_duration{endpoint:search}
- 평균(avg): 약 698ms
- p95: 약 1.9s

정리하면,

평균 응답 시간: 4.03s → 0.69s (약 5.8배 개선)
p95 기준: 10.34s → 1.9s (약 5.4배 개선)

으로, 단순 LIKE 검색에 비해 5배 이상 빨라진 것을 확인할 수 있었다.

아직 k6 threshold로 잡아둔 목표치(p95 < 350ms, p99 < 600ms)를 완전히 만족시키지는 못하지만,
t4g.micro + 384MB 버퍼 풀이라는 제약 안에서

“부분 검색 + 공백이 섞인 여러 단어 검색” 경험을 유지하면서

“테이블 풀 스캔 없이 인덱스 기반으로 동작하는 검색” 을 만들었다는 점에서 의미 있는 개선이라고 생각한다.

⚒️ 수정된 설계

이 글을 초안까지 다 쓰고, 잠들기 전에 친구랑 통화를 하면서 내가 짠 설계를 쭉 설명했다.
말로 풀어서 설명하다 보니, 듣는 사람보다 오히려 내가 더 많이 깨닫는 느낌이었다.

처음엔 “유저 500명 정도”를 가정하고 설계를 짰다.
하지만 전화를 끊고 나니 이런 생각이 들었다.

“근데… 정말 500명에서 끝날까?”
“유저가 5,000명, 1만 명이 되면 그때도 이 구조가 버틸까?”

냉정하게 말하면, 지금 구조로는 버틸 수 없다.
나는 항상 오버엔지니어링을 기피해 왔고,
유저 증가 속도를 보면서 대략 6개월 정도를 내다보고 설계를 했지만,
곰곰이 따져 보니 허점이 꽤 많아 보였다.

유저가 많아질수록 아티클은 기하급수적으로 쌓이고, 그때마다 인덱스 용량도 같이 커진다.
기본 FULLTEXT 인덱스는 Ngram FULLTEXT에 비해 훨씬 가볍긴 하지만,
그래도 10만 개, 100만 개, 1,000만 개까지 쌓인다고 생각하면
“이 정도면 괜찮겠지” 하고 넘길 수 있는 수준은 아니다.

메일이 새로 오거나 삭제될 때마다 인덱스도 같이 수정해야 한다.
데이터가 커질수록 이 비용은 눈덩이처럼 커진다.
문득, 이걸 기술로만 버티게 만드는 건 너무 근시안적인 선택이 아닐까 하는 생각이 들었다.

그래서 관점을 살짝 바꿔 보기로 했다.
“이걸 DB 튜닝으로만 버틸 게 아니라,
애초에 ‘우리가 어떤 서비스를 만들고 싶은지’에서부터 답을 찾을 수는 없을까?”

이때 예전에 팀원들끼리 했던 대화만 하고 그냥 넘어갔던게 떠올랐다.

그 당시 이런 이야기를 했던 기억이 있다.

“개인이 메일을 무제한으로 받아야 할까?”
“어느 정도에서 잘라주는 게 맞을까?”

네이버 메일처럼 일반 메일 서비스는 용량 단위로 제한을 둔다.
하지만 봄봄은 일반 메일이 아니라 “뉴스레터만 모으는 서비스”라서,
용량보다 “몇 개까지 보관해 줄지”가 훨씬 직관적이라고 느꼈다.

게다가 우리는 아직 수익도 발생하지 않고,
언제부터 어떤 방식으로 돈을 벌게 될지도 명확하지 않은 프로젝트다.
그런 상황에서 “무제한 보관”을 약속해 버리면
검색 이전에, 저장 자체가 비용 폭탄이 될 수밖에 없다.

그래서 이 문제는 “DB 성능 문제”이기 전에
“서비스가 어디까지를 책임질 것인지”에 대한 비즈니스 결정이라고 보기로 했다.
결국, 일정 개수에서 잘라야 한다는 결론에 도달했다.

그렇다면 몇 개가 적당할까?

뉴스레터를 실제로 사용해보며 대략적인 평균치를 잡아봤다.
한 사용자가 하루에 받는 뉴스레터를 4개 정도로 가정하면
한 달이면 120개, 4개월이면 약 480개다.
대부분의 사용자는 4개월 치 뉴스레터를 모두 다시 찾아볼 일은 거의 없다.
그래서 “4개월 치를 넉넉히 보관해 주는 정도면 초반엔 충분하겠다”는 기준을 세웠다.

4개월이면 충분히 습관이 형성되고 계속 우리 서비스를 이용할 것이라 판단했다.

여기서 500개라는 숫자가 나왔다.

너무 낮게 잡으면 처음부터 불편하고,
너무 높게 잡으면 나중에 줄여야 할 수도 있는데,
서비스 입장에서 “용량을 줄이는 경험”은 꽤나 최악의 경험이다.
반대로, 처음엔 보수적으로 잡아두고
서비스가 성장하면 “이제 1,000개까지 보관해 드릴게요”라고 올려주는 쪽이
훨씬 좋은 사용자 경험이라고 판단했다.

그래서 1유저 = 최대 500개 뉴스레터 보관이라는 정책을 정했다.
대략 아래와 같은 계산도 같이 했다.

한 뉴스레터를 평균 25KB 정도로 잡으면,

1유저 저장 용량 ≒ 25KB × 500개 ≒ 12.2MB
1,000명일 때 ≒ 12GB
5,000명일 때 ≒ 60GB
1만 명일 때 ≒ 120GB

대략 이 정도면 지금 인프라와 비용 구조 안에서
“감당 가능한 선”이라고 판단했다.

이렇게 해서 나온 “사용자당 500개” 정책은
단순히 DB를 살리기 위한 기술적 꼼수가 아니라,
우리가 감당할 수 있는 비용과
사용자에게 약속할 수 있는 서비스 범위를 함께 고려한
비즈니스적인 결정에 가깝다.

그리고 이 결정은 바로 검색 설계에도 영향을 줬다.

이 조건이 들어오자 전제가 다시 한 번 달라졌다.
memberId 인덱스를 타고 조회하면, 한 사용자 기준으로는 어차피 최대 500개까지만 남는다.
그렇다면 이 500개에 대해서는 LIKE '%keyword%'로 풀스캔을 하더라도,
예전에 전체 article 테이블을 대상으로 LIKE를 날렸을 때와는
성능 특성이 완전히 다르다고 볼 수 있었다.

그래서 먼저, 가장 단순한 구조부터 실험해 보기로 했다.
memberId로 범위를 500개 이내로 좁힌 뒤,
그 안에서 LIKE '%keyword%'로만 검색하는 방식이다.

이 구조로 k6 부하 테스트를 돌려 보았다.
가상 유저를 최대 100명까지 올리고 약 7,300건 정도의 검색 요청을 보냈을 때,

평균 응답 시간은 대략 800ms,
중앙값은 220ms 안쪽,
p95(95퍼센트 지점)는 약 1.6초 정도가 나왔다.

예전처럼 전체 article 테이블에 LIKE '%keyword%'를 날렸을 때
p95가 10초를 넘기던 것을 생각하면,
이 정도면 더 이상 “망했다” 수준의 수치는 아니었다.
게다가 실제 서비스에서 검색은 동시성이 아주 높지도 않고,
전체 트래픽에서 차지하는 비중도 크지 않다.
실제 사용자 환경에서는 이보다 더 여유 있는 숫자가 나오리라 기대할 수 있었다.

여기까지 보면 “그냥 LIKE만 써도 되겠다”는 결론을 내려도 이상할 건 없다.
하지만 처음 설계를 시작할 때 가졌던 생각은 여전히 같았다.

검색은 자주 쓰이지는 않더라도,
막상 사용했을 때는 “제대로” 동작해야 한다는 것이다.

그러기 위해서는 앞에서 이야기한 것처럼
어느 정도 이상의 부분 검색 품질을 유지해야 했고,
줄일 수 있는 속도는 최대한 줄이고 싶었다.

그래서 한 걸음만 더 나아가 보기로 했다.

최신 5일 이내의 아티클은 Ngram 기반 FULLTEXT 인덱스로 검색하고,
그 이후(5일 이전) 아티클은 memberId로 최대 500개까지 좁힌 뒤
LIKE '%keyword%'로 검색하는 혼합 구조를 다시 만들었다.

이때 explain으로 실제 실행 계획을 확인해 가며
인덱스를 타는 조건과 정렬 조건을 계속 바꿔보면서 쿼리 튜닝도 함께 진행했다.

구조를 바꾼 뒤, 동일하게 k6로 부하 테스트를 한 번 더 돌렸다.
마찬가지로 가상 유저를 최대 100명까지 올리고,
약 8,900건 정도의 검색 요청을 보냈을 때

http_req_duration 기준 평균은 약 260ms,
중앙값은 약 85ms,
p90은 약 510ms,
p95는 약 740ms가 나왔다.

LIKE만 썼을 때와 비교하면,

평균은 800ms에서 260ms 수준으로,
중앙값은 220ms에서 85ms로,
p95도 1.6초에서 0.74초 정도로 줄었다.

즉 “사용자당 500개 제한 + 최신 5일 Ngram + 나머지 LIKE” 구조가
단순히 LIKE만 쓰는 구조보다 응답 시간이 전반적으로 훨씬 안정적이고,
꼬리 구간을 제외한 대부분 요청에서 체감 속도를 꽤 끌어올려 주었다.

결국 지금 구조는
당장 눈앞의 성능 문제만 보는 것도 아니고,
그렇다고 먼 미래의 막연한 트래픽을 위해 과하게 투자하는 것도 아닌,
그 중간 어딘가에서 찾아낸 타협점에 가깝다.

서비스가 더 커지고, 검색이 정말 비즈니스의 중심 기능이 되는 순간이 온다면

아마 또 한 번 설계를 갈아엎게 될 것이다.
예를 들어 “최신 1년만 풀텍스트 인덱싱”,
“기간 선택을 더 적극적으로 강제”,
혹은 “전용 검색 엔진 도입” 같은 선택지를
다시 꺼내 들게 될지도 모른다.

하지만 적어도 지금 시점에서 이 선택은,
서비스의 성장 가능성과 현재 인프라의 한계를 동시에 바라보며
여러 밤을 고민하고, 실제 부하 테스트 결과까지 확인한 뒤에 내린 결정이라는 점이 중요하다고 생각한다.
지금 이 글에 적힌 설계는 그런 고민의 흔적을 기록해 둔 하나의 스냅샷에 가깝다.

정리하며

처음에는 LIKE '%keyword%' 하나로 부분 검색과 공백이 섞인 검색을 모두 해결해 보려 했다가
인덱스를 타지 못하면서 p95가 6초를 넘어가는 검색을 얻었다.
그다음에는 캐시를 얹을지, 별도 검색 엔진(Meilisearch, Typesense)을 쓸지,
MySQL 플러그인을 붙일 수 있을지 등 여러 후보를 검토했다.

하지만 RDS MySQL(t4g.micro, 1GB RAM)이라는 인프라 제약과
검색이 “매일 수백 번 쓰이는 메인 기능”은 아니라는 서비스 특성을 함께 놓고 봤을 때
지금 단계에서 전용 검색 엔진을 도입하는 건 과투자라고 판단했다.

그래서 “주어진 MySQL 안에서, 부분 검색과 공백이 섞인 검색 경험을 최대한 유지하면서
LIKE보다 훨씬 빠르게 만들 수 있는 방법”을 찾는 쪽으로 방향을 틀었고,
그 결과가 “최근 5일 Ngram + 이후 LIKE '%keyword%'” 혼합 전략이었다.

부하 테스트 기준으로 보면,
p95 기준 10.34초에서 1.9초,
평균 응답 시간도 4초대에서 0.6~0.7초대로 줄었다.

“검색 버튼을 누르고 기다리기 싫은 서비스”에서
적어도 “한 번쯤은 써볼 만한 검색” 정도까지는 끌어올렸다고 느낀다.

아직 완벽과는 거리가 멀다.
Ngram 기간(5일)을 3일이나 7일로 바꿔 본다든지,
쿼리 튜닝, 인덱스 재설계, 인스턴스 스펙 업그레이드 후 재측정 같은 실험 여지는 여전히 많다.

그래도 이번에 느낀 건,
검색은 멋진 엔진을 쓰는지보다
우리 서비스와 인프라가 감당할 수 있는 선에서 어떤 타협을 했는지가 더 중요하다는 점이었다.

언젠가 정말 검색이 비즈니스의 한가운데로 들어오는 시점이 오면,
그때는 전용 검색 엔진을 도입하는 글을 또 한 편 쓰게 되지 않을까 싶다.

Reference

저장이 왜 안되는 거지?

개발자성장기 — Sat, 15 Nov 2025 17:38:42 +0900

현재 우리 서버는 한창 알림을 만드는 중이다.

이 과정에서 알림을 보내기 위한 기본 정보들이 DB에 저장이 안 되는 일이 발생했다.

what?

분명 코드적으로 문제가 없는 것 같은데 왜 저장이 안되는 걸까??

처음에는 이유를 알 수 없었다.

    @TransactionalEventListener
    public void onArticleArrived(ArticleArrivedEvent event) {
        try {
            ArticleArrivalNotification articleArrivalNotification = ArticleArrivalNotification.builder()
                    .articleId(event.articleId())
                    .memberId(event.memberId())
                    .newsletterName(event.newsletterName())
                    .articleTitle(event.articleTitle())
                    .status(NotificationStatus.PENDING)
                    .attempts(0)
                    .isRead(false)
                    .build();
            articleArrivalNotificationRepository.save(articleArrivalNotification);

            log.info("아티클 도착 알림 저장 완료: 멤버 ID={}, 뉴스레터={}, 아티클 제목={}",
                    event.memberId(), event.newsletterName(), event.articleTitle());
        } catch (Exception e) {
			// ...
        }
    }

코드는 위와 같이 생겼다.

아티클이 저장된 뒤, AFTER_COMMIT 시점에서 알림용 엔티티를 저장하는 구조다.
로그를 봐도 save()가 이후 로그가 정상적으로 호출되었고, 예외도 보이지 않았다.

분명 AFTER_COMMIT 이후에 저장이 되어야하는데 되지 않는것이었다.

그리고 에러하나 뜨지 않았다.

실제 DB를 열어보면 이렇게 텅 비어 있었다.

1. 문제 상황 정리

로그를 자세히 보면, 해당 로그는 분명 save() 호출 이후에 찍힌 로그였다.
즉, “엔티티를 저장하라”는 명령 자체는 JPA까지는 잘 전달된 상황이었다.

하지만 실제 DB를 열어보면 테이블이 텅 비어 있었다.

그래서 제일 먼저 떠올린 생각은

“정말로 DB에 INSERT 쿼리가 실행되었는가?”

물론 당연히 `save()` 메서드가 동작했다고 해서 무조건 DB에 저장되는 것은 아니다.
JPA 입장에서 save()는 영속성 컨텍스트에 엔티티를 올려두는 작업일 뿐이고,
실제 DB에 반영되는 시점은 flush + commit이 일어날 때다.

INSERT SQL / flush 로그 확인

그렇다면 가장 먼저 할 일은 INSERT SQL이 찍혔는지 확인하는 것이다.

이게 제일 확실하다.

하지만 안타깝게도, 이 서버는 운영 이메일 서버라 SQL 쿼리 로그를 별도로 켜지 않은 상태였다.

대신, flush 로그를 통해 우회적으로 확인해보기로 했다.

Hibernate는 flush 시점에 몇 개의 엔티티가 반영되었는지 다음과 같이 로그를 남긴다.

여기서 중요한 점은 insertions(혹은 creations)가 0이었다는 것

즉, flush 시점에 “새로 추가된 엔티티”가 하나도 없었다는 것이다

정리하면,

save()는 호출되었다. 엔티티는 영속성 컨텍스트에 올라감
하지만 flush 시점에 insert 대상 엔티티가 하나도 없었다.
그래서 DB로 날아간 INSERT SQL도 없었고,
결국 DB에는 아무것도 저장되지 않았다.

이 시점에서는 외부 트랜잭션이 rollback 된 것도 아니고, readOnly 트랜잭션도 아니었고, 다른 DB를 바라보고 있는 것도 아니었다.

즉, "전형적인" 원인들은 아니었다.

그래서 팀 슬랙에 상황을 공유해두고 계속 로그를 뜯어보다가 진짜 원인을 발견했다.

진짜 원인: AFTER_COMMIT 리스너 + 트랜잭션 없음

문제의 핵심은 이 로직이 `@TransactionalEventListener` 를 사용하고 있었다는 점이다.
이 애너테이션의 기본 `phase` 값은 AFTER_COMMIT 이다.

즉, 기존 트랜잭션이 커밋된 이후에 리스너가 실행된다.

이미 기본 트랜잭션은 끝났고, 영속성 컨텍스트도 닫힌 상태다.

이 시점에서 별도의 `@Transactional` 이 없다면, 트랜잭션 없이 save()를 호출하는 상황이 된다.

(이름 자체가 AFTER_COMMIT인데 왜 트랜잭션이 있다고 생각했지??? .. 하...)

그렇다면 JPA/Hibernate는 트랜잭션 밖에서 save()를 호출하면 어떻게 될까?

내부에서는 `entityManager.persist()` 까지는 호출된다.

하지만 자동 flush는 “활성화된 트랜잭션”이 있을 때만 일어난다.

commit 역시 트랜잭션이 있어야만 발생한다.

결국, 트랜잭션이 없으면 flush/commit이 발생하지 않는다.

그래서 이 경우는 이렇게 정리된다.

JPA는 엔티티를 영속성 컨텍스트에 올리기만 하고
실제 DB로 INSERT를 날릴 기회를 갖지 못하고
그 상태로 메서드가 끝나버린다.

결과적으로 INSERT SQL이 준비되긴 했지만, 트랜잭션이 없어 커밋되지 않았고 DB에는 아무 것도 들어가지 않은 것이다.

❗️AFTER_COMMIT 리스너의 특징 정리

`@TransactionalEventListener(phase = AFTER_COMMIT)` 의 특징을 정리하면 다음과 같다.

- 이미 원래 트랜잭션이 끝난 시점에 실행된다.
- 이때 별도의 @Transactional 을 붙이지 않으면 새로운 트랜잭션이 생성되지 않고 모든 변경 작업은 DB에 반영되지 않는다.
- 영속성 컨텍스트도 이미 닫혀 있어서 단순 조회는 가능하지만 Lazy 로딩은 Detached 상태라 LazyInitializationException 이 발생한다.

그래서 트랜잭션 없이 AFTER_COMMIT 리스너에서 할 수 있는 일은 사실상 조회 외에는 거의 없다.

✔ 저장(save) → 거의 100% DB 반영 안 됨
✔ 수정(update) → Dirty checking이 안 돼서 반영 안 됨
✔ 삭제(delete) → flush/commit 없어서 반영 안 됨
✔ 조회(find) → 가능은 하지만 Lazy 관계는 터진다

2. 해결 방안

이제 “왜 저장이 안 되었는지”는 알게 되었으니,
남은 것은 “그렇다면 어떻게 고쳐야 하는가”였다.

1. 리스너를 본 트랜잭션 안에서 돌리기

첫 번째 후보는 리스너를 기존 트랜잭션 안에서 함께 돌리는 방법이다.

@TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
public void onArticleArrived(ArticleArrivedEvent event) { ... }

BEFORE_COMMIT으로 설정하면, 아티클 저장 트랜잭션이 커밋되기 전에 리스너가 실행되고, 알림 저장도 같은 트랜잭션 안에서 함께 커밋/롤백된다.

하지만 이 방법은 바로 제외했다. 이유는 명확하다.

알림 저장에서 예외가 발생하면 → 원본 아티클 트랜잭션까지 같이 롤백된다.
우리 도메인에서는 → “알림은 실패해도 상관없지만, 아티클 저장은 반드시 성공해야 한다.”

알림은 본 비즈니스의 부가 기능일 뿐인데,
부가 기능이 실패했다고 해서 핵심 흐름까지 같이 실패하게 만들고 싶지는 않았다.
그래서 트랜잭션을 분리하기 위해 계속 AFTER_COMMIT을 유지하기로 했다.

2. 리스너에서 새 트랜잭션을 열어주기

두 번째 방법은 리스너에서 아예 새 트랜잭션을 여는 것이다.

해당 메서드에 `@Transactional(propagation = Propagation.REQUIRES_NEW)` 애너테이션만 붙이면 해결이 가능하다.

이렇게 하면 아티클 트랜잭션이 정상적으로 커밋된 이후에 리스너가 완전히 별도의 트랜잭션을 열고 알림을 저장한 뒤 그 트랜잭션만 따로 커밋한다.

즉 아티클 저장 성공 여부와 알림 저장 성공 여부가 완전히 독립된다.

알림 로직에서 예외가 터져도,
이미 끝난 아티클 트랜잭션에는 전혀 영향을 주지 않는다.

그래서 우리는 2번 방식, 즉 “리스너에서 새 트랜잭션 열기”를 선택했다.

❗️그런데 왜 옵션을 `Propagation.REQUIRES_NEW` 로 했을까?

“사실 @Transactional 만 붙여도 되지 않나?
기본 전파 옵션(REQUIRED)이면 트랜잭션이 없을 때 새로 만들어주는데?”

실제로 지금 구조에서는 아래 코드만 있어도 정상 동작한다.

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Transactional // propagation = REQUIRED 기본값
public void onArticleArrived(ArticleArrivedEvent event) {
    ...
}

AFTER_COMMIT 시점에는 이미 기존 트랜잭션이 끝난 상태라,
진행 중인 트랜잭션이 없고, REQUIRED는 새 트랜잭션을 생성한다.
그래서 버그 자체만 놓고 보면, 기본값으로도 해결은 된다.

그런데도 불구하고 우리는 REQUIRES_NEW를 명시적으로 선택했다.
그 이유는 한마디로 말하면,

“이 로직은 항상 독립된 트랜잭션에서 돌려야 한다”는
의도를 코드에 박아두고 싶었기 때문이다.

즉, REQUIRES_NEW는 단순히 “동작시켜 보니 되더라” 수준이 아니라,

“이 메서드는 언제나 새 영속성 컨텍스트 + 새 트랜잭션에서 돌려야 한다”
“알림 저장은 하나의 작은 단위 작업으로 묶여서 커밋되어야 한다”
“메인 비즈니스와는 철저히 분리된 사이드 이펙트다”

라는 설계 의도를 코드만 보고도 바로 이해할 수 있게 해주는 장치다.

이런 면에서 REQUIRES_NEW는 일종의 자기 문서화(self-documenting) 도구 역할을 한다.
나중에 팀원이 코드를 보더라도,

“아, 이건 꼭 독립 트랜잭션이어야 하는 작업이구나”

라는 걸 주석 없이도 바로 읽어낼 수 있다.

한 걸음 더

여기서 또 주제에 벗어나지만 또 고려하면 좋을게 있다.

AFTER_COMMIT을 하더라도 하나의 스레드에서 동작한다 그럼 과연 동기로계속 유지하는게 좋을까? 아니면 비동기로 유지하는게 좋을까?

이건 다음시간에...

Reference

- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/event/TransactionalEventListener.html?utm_source=chatgpt.com

- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/event/TransactionPhase.html?utm_source=chatgpt.com

트랜잭션이 없는데 왜 더티 체킹이 일어나지? (feat. OSIV)

개발자성장기 — Tue, 1 Jul 2025 20:21:33 +0900

(이 글에서는 OSIV/OEMV 모두 OSIV로 지칭합니다)

(이 글을 작성할 수 있게 소스를 준 노랑에게 감사합니다)

우연히 노랑이라는 크루를 통해 `@Transactional`을 붙이지 않았는데 더디체킹이 된다는 소리를 들었고

실제로 Query를 보니 update를 하지 않았는데 update가 되었다.

처음 봤는데 신기했다. 동시에 무엇때문에 그러는지 궁금해지기 시작했다.

문제의 코드는 아래와 같다.

public void cancelReservationById(final long id) {
    waitingRepository.findFirstByReservationIdOrderByCreatedAtAsc(id)
            .ifPresentOrElse(
                    (waiting) -> processWaitingToReservation(id, waiting),
                    () -> reservationRepository.deleteById(id)
            );
}

private void processWaitingToReservation(final long id, final Waiting waiting) {
    final Reservation reservation = reservationRepository.findById(id)
            .orElseThrow(() -> new NotFoundException("예약을 찾을 수 없습니다."));
    reservation.updateMember(waiting.getMember());
    waitingRepository.delete(waiting);
}

해당 메서드는 `@Transactional` 이 존재하지 않는다.

하지만 reservation이 업데이트가 되었다.

`@Transactional`이 존재하지 않기 때문에 더티 체킹이 일어나지 않으니 당연히 reservation은 따로 save를 하지 않으면 업데이트가 일어나면 안 되지만 일어났다.

왜 그럴까?

일단 사전지식으로 JPA의 모든 CRUD메서드에는 `@Transactional`이 붙어있다는 것은 알고 있었다.

(물론 CUD에는 @Transactional이 적용되어있다)

이를 알고 있었지만 해당 동작은 이해가 되지 않았다.

그렇지만 노랑이 말하길 delete의 위치에 따라 update가 될 수도 되지 않을 수도 있다고 했다.

✅ update 쿼리 발생 O

private void processWaitingToReservation(final long id, final Waiting waiting) {
    final Reservation reservation = reservationRepository.findById(id)
            .orElseThrow(() -> new NotFoundException("예약을 찾을 수 없습니다."));
    reservation.updateMember(waiting.getMember());
    waitingRepository.delete(waiting);
}

✅ update 쿼리 발생 X

private void processWaitingToReservation(final long id, final Waiting waiting) {
    final Reservation reservation = reservationRepository.findById(id)
            .orElseThrow(() -> new NotFoundException("예약을 찾을 수 없습니다."));
    waitingRepository.delete(waiting);
    reservation.updateMember(waiting.getMember());
}

차이는 단지 delete의 위치였다.

이렇게 위치에 따라 update가 발생한 이유는 바로 OSIV 때문이다.

더티 체킹 (Dirty Checking)

OSIV에 대해 알아보기 전에 일단 더티 체킹에 대해 다시 알아보자

더티 체킹은 상태 변형 검사이다.

JPA에서는 트랜잭션이 끝나는 시점에 변화가 있는 모든 엔티티 객체를 데이터베이스에 자동으로 반영해 준다.

이때 '변화가 있다'의 기준은 최초 조회 상태이다.

JPA에서는 엔티티를 조회하면 해당 엔티티의 조회 상태 그대로 스냅샷으로 만들어 놓는다.

그리고 트랜잭션이 끝나는 시점에 이 스냅샷과 비교해서 다른 점이 있다면 Update Query를 데이터베이스로 전달한다.

당연히 이런 상태 변경 검사의 대상은 영속성 컨텍스트가 관리하는 엔티티에만 적용된다.

준영속, 비영속 상태의 엔티티는 더티 체킹 대상에 포함되지 않는다.

즉, 값을 변경해도 데이터베이스에 반영되지 않는다는 것이다.

자 그럼 다시 코드를 보자

private void processWaitingToReservation(final long id, final Waiting waiting) {
    final Reservation reservation = reservationRepository.findById(id)
            .orElseThrow(() -> new NotFoundException("예약을 찾을 수 없습니다."));
}

이렇게 조회를 했을 때는 JPA의 구현체인 Hibernate를 이용할 경우 트랜잭션 범위에서 Entity를 조회할 경우 아래와 같이 조회시점의 Entity 복사본을 만들어 준다.

https://jojoldu.tistory.com/536

그리고 트랜잭션이 끝나는 시점에 여러 가지 서비스 로직으로 원본 Entity의 변경이 있다면 조회시점에 복사해 둔 복사본과 비교를 하여 다른 점이 있다면 Update 쿼리를 발생시킨다.

그런데 여기서는 로직을 실행하는 메서드에 트랜잭션이 붙어있지 않는다.

뭐야 그럼 더티 체킹이 일어날 수 없는 조건에서 도대체 누가 업데이트 쿼리를 날리는 거야?

이를 알기 위해서는 EntityManager도 알아야 한다.

영속성 컨텍스트는 EntityManager 단위로 존재하고 일반적으로 트랜잭션이 시작될 때 스프링이 EntityManger를 만들어서 트랜잭션 바인딩을 시킨다. 하지만 트랜잭션이 먼저 열리지 않아도 EntityManger는 존재할 수 있다.

언제? OSIV가 켜져 있을 때

바로 이때 `deleteById()` 메서드를 사용하면 `deleteById()`가 트랜잭션을 열 때 이미 존재하던 영속성 컨텍스트에 reservation이라는 엔티티가 들어 있었다면, reservation.updateMember()로 수정된 상태였을 테고, reservation도 같이 DB에 반영된다.

하지만 만약 OSIV 설정이 꺼져 있다면 반영되지 않는다.

OSIV

스프링 부트에서 기본으로 켜져 있는 설정으로, HTTP 요청의 시작부터 끝(View 렌더링까지) 영속성 컨텍스트(EntityManager)를 열어두는 전략이다.

OSIV가 켜져 있으면 컨트롤러나 서비스에 `@Transactional`이 없어도 이미 요청 시점에 영속성 컨텍스트가 열려 있고, 엔티티가 조회되면 영속 상태로 관리 된다. 그래서 지금까지 View Template이나 API 컨트롤러에서 지연 로딩이 가능했던 것이다.

지연 로딩은 영속성 컨텍스트가 살아있어야 가능하고, 영속성 컨텍스트는 기본적으로 데이터베이스 커넥션을 유지한다.
이것 자체가 큰 장점이다.

그런데 이 전략은 너무 오랜 시간 동안 데이터베이스 커넥션 리소스를 사용하기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있다. 이것은 결국 장애로 이어진다.

예를 들어서 컨트롤러에서 외부 API를 호출하면 외부 API 대기 시간만큼 커넥션 리소스를 반환하지 못하고, 유지해야한다.

아래 이미지는 OSIV가 켜고 꺼짐에 따른 영속성 컨텍스트 생존 범위를 나타낸 것이다.

OSIV ON

스프링 부트와 JPA 활용 2 - 김영한

OSIV OFF

스프링 부트와 JPA 활용 2 - 김영한

OSIV가 꺼져 있으면 HTTP 요청을 시작할 때 영속성 컨텍스트가 열리지 않는다.
`@Transactional`이 걸린 시점에서야 EntityManager가 열린다.
상위 메서드에서 조회한 엔티티는 영속 상태가 아님 (Detached) 즉, 더티 체킹 대상이 아니다.
따라서 하위에서 트랜잭션이 열려도 flush 시킬 변경사항이 없다.

정리해 보면 아래와 같다.

왜 트랜잭션 어노테이션이 붙어있지 않은 상위 메서드의 변경사항이 하위 메서드에 붙어있는 트랜잭션에 영향을 받을까?

스프링에서는 보통 HTTP 요청 전체 기간 동안 하나의 영속성 컨텍스트를 유지하는 OSIV 전략을 사용한다.

OSIV 전략이 켜져 있으면

요청을 처리하는 동안 항상 영속성 컨텍스트가 유지된다. 그래서 별도의 트랜잭션 선언이 없어도 엔티티가 계속 영속 상태로 유지된다.

이때 하위 메서드에서 트랜잭션이 열릴 때, 기존 영속성 컨텍스트의 모든 변경사항이 DB에 반영된다(flush)

OSIV 전략이 꺼져 있으면

명시적으로 트랜잭션이 붙은 메서드에서만 영속성 컨텍스트가 열린다.

상위 메서드에서 조회한 엔티티는 영속성 컨텍스트가 닫힌 상태라 더티 체킹이 일어나지 않는다.

왜 스프링 부트는 OSIV 기본값을 true로 ?

여기서 이런 궁금증이 생길 수 있다.

스프링 부트는 도대체 왜 OSIV를 기본값으로 설정해 놓았을까??

그 이유는 아래 spring-projects 이슈에서 알 수 있다.

(읽는데 1시간 이상 걸리니 주의해야 한다. 아주 피 터지게 토론을 한다.)

Log a warning on startup when spring.jpa.open-in-view is enabled but user has not explicitly opted in · Issue #7107 · spring-p

Considering OSIV/OEMIV is widely considered an anti-pattern, OpenEntityManagerInViewInterceptor should IMO not be enabled by default. Rather than that it should be opt-in. If this proposal isn't ac...

github.com

OSIV 기본 활성화 찬성 측 주장

신규 사용자가 LazyInitializationException을 자주 겪고, 이를 회피하기 위한 개발자 경험(DX)을 고려해야 한다!

OSIV 기본 활성화 반대 측 주장

OSIV는 지연 로딩을 무분별하게 하게 만들어 예기치 않은 DB 쿼리 폭주, 커넥션 풀 고가, 심각한 성능 저하를 유발할 수 있음

Reddit에서 OSIV off 버전이 처리량에서 2배 이상 월등하다는 비판적인 의견도 게시

https://www.reddit.com/r/java/comments/1hcgyc4/the_opensessioninview_pattern_of_spring_boot_a/?utm_source=chatgpt.com

주요 의견

결국은 스프링의 철학은 아래와 같다.

“Spring은 복잡한 엔터프라이즈 개발을 쉽게 만들기 위해 시작되었다.”
— Rod Johnson (Spring 창시자), “Expert One-on-One J2EE Design and Development” 서문

OSIV 기본값을 true로 해놓는 것은 누구나 쉽게 러닝커브가 거의 없이 무언가를 스프링을 통해 쉽게 만들기 위해서인데 이를 false로 해놓으면 초보자 입장에서는 알아야 할게 너무나 많아진다는 것이다.(어차피 숙련자라면 상황에 따라 true/false를 자유롭게 선택할 수 있을 것이다)

이 이슈 글을 읽을 때 주의할 점은 OSIV를 써야 한다가 아니라 OSIV 기본값을 true로 해놓은 이유라는 걸 잊으면 안 된다.

현업에서 osiv를 관련 문제 발생 사례

Spring Boot의 open-in-view, 그 위험성에 대하여 - 프렙

JPA 영속성 컨텍스트와 OSIV - 한국신용데이터

Reference

- OpenSessionInViewFilter

- 스프링 부트와 JPA 활용2

- Two reasons why you might want to disable Open Session in View in a Spring application

- Spring Boot의 open-in-view, 그 위험성에 대하여.

- JPA 영속성 컨텍스트와 OSIV

- JPA | What is OSIV (Open Session In View)

Controller에서 왜 반환값을 ResponseEntity로 안 해?

개발자성장기 — Fri, 20 Jun 2025 21:56:57 +0900

레벨 2 미션을 처음 했을 때, 습관처럼 컨트롤러에서 반환 값을 ResponseEntity로 감싸서 처리했다.

예를 들어, 아래와 같은 코드였다.

@GetMapping("/users/{id}")
public ResponseEntity<UserDto> getUser(@PathVariable Long id) {
    return ResponseEntity.ok(userService.findUser(id));
}

사실 이전 프로젝트에서도 큰 고민 없이 이렇게 사용했고, "왜?"라는 질문조차 던지지 않았다.
미션을 제출한 후에도 자연스레 의심 없이 지나쳤다.

그러다 우연히 다른 크루의 코드 리뷰를 보며 처음으로 궁금증이 생겼다.

이때부터 생각했다.

`ResponseEntity`가 무엇이고 왜 써야 하지?

안 쓰면 어떻게 될까?

ResponseEntity란 ?

먼저 ResponseEntity가 무엇인지부터 간단히 정리하면 다음과 같다.

ResponseEntity<T>는 스프링의 HttpEntity<T>를 확장한 클래스로, HTTP 상태 코드와 헤더를 함께 담아 응답을 유연하게 제어할 수 있다.

기본적으로 컨트롤러에서 객체를 반환하면 HTTP 본문(body)만 전달된다. 그러나 ResponseEntity를 쓰면 상태 코드와 헤더를 직접 제어할 수 있다.

1. 상태 코드 제어

단순 반환은 200 OK만 반환되지만, ReponseEntity로는 200대, 300대, 400대, 500 대 등 다양한 코드를 직접 지정할 수 있다.

2. 커스텀 헤더 추가

예를 들어 ETag, location, 인증 토큰 등을 응답 헤더에 넣고 싶을 때 유용하게 활용할 수 있다.

3. 예외 처리 시 일관된 응답 포맷

@ControllerAdvice와 함께 ReponseEntityExceptionHandler를 상속해 오류 등답을 한 곳에서 관리할 수 있다.

ResponseEntity 없이 상태코드와 헤더 관리하기

그렇지만 다른 방법도 있다.

그냥 dto만 반환하는 거다.

그럼 상태코드와 헤더는? 할 것이다.

상태코드는 `@ResponseStatus` 어노테이션을 활용하면 가능하다.

그럼 헤더는??

아쉽게도 헤더는 어노테이션이 없다.

그 이유는 Spring-framework issues에서 찾을 수 있다.

쉽게 요약하자면 아래와 같다.

Java 어노테이션은 컴파일 시점에 상수만 허용하기 때문에 헤더 값이 요청 비즈니스 로직, DB 결과 등에 따라지는 "런타임 계산"이 필요한 경우를 처리할 수 없다.

더 쉽게 이야기하면

`@ResponseStatus`는 항상 고정된 HTTP 상태 코드(예: 404, 201 등)를 선언할 때 쓰이고, 이 경우엔 어노테이션 속성으로 충분히 표현이 가능 반면 Location, ETag, Set-Cookie 같은 헤더는 대개 "저장된 객체의 ID"나 "해시 값"처럼 동적으로 생성된 값을 담아야 한다.

정적 헤더는 예를 들어 Content-Type: application/json처럼 변하지 않는 값이고,
동적 헤더는 Location: /users/1234처럼 사용자의 요청 결과에 따라 변하는 값이다.

모든 정적과 동적 모든 경우를 다 커버하는 `@ResponseHeader` 어노테이션을 추가하려면

동적 값 바인딩 로직, 여러 타입 반환, 예외 처리 등 복잡도가 크게 늘어나고 오히려 프레임워크가 무거워진다.

따라서 헤더도 어노테이션으로 달 수야 있지만, 동적인 특성이 강하니 굳이 프레임워크 차원에서 `@RsponseHeader` 같은 어노테이션은 만들지 않은 것 같다.

ResponseEntity를 쓸 때와 쓰지 않을 때 어떻게 동작할까?

클라이언트에서 요청을 받아 컨트롤러 메서드 실행하는 단계로 가면

`ServletInvocableHandlerMethod.invodkeAndHandle(...)` 호출하게 된다.

그런 다음 리턴값을 처리할 핸들러를 선택한다.

`HandlerMethodReturnValueHandlerComposite.handleReturnValue()`가 호출된다.

`handleReturnValue`메서드는 위와 같이 생겼다.

여기서 `selectHandler`가 동작할 때 `this.returnValueHandlers`를 순서대로 돌면서 `supportsReturnType()`이 true인 핸들러를 선택한다.

핸들러의 종류는 아래와 같다.

`HandlerMethodReturnValueHandler` 구현체들

RequestResponseBodyMethodProcessor	@ResponseBody 또는 @RestController가 붙은 컨트롤러의 리턴값	JSON/XML로 변환해서 응답 본문에 직접 씀 (@ResponseBody 기반)
HttpEntityMethodProcessor	ResponseEntity, HttpEntity	상태 코드, 헤더, 본문 등을 직접 지정해서 반환
ModelAndViewMethodReturnValueHandler	ModelAndView 타입	뷰 이름과 모델 정보를 함께 반환
ViewNameMethodReturnValueHandler	String 뷰 이름	String을 반환하면 뷰 이름으로 해석
ModelMethodProcessor	Model, Map<String, Object> 등	모델 객체를 직접 반환
ViewMethodReturnValueHandler	View 타입	뷰 객체를 직접 반환 (ThymeleafView, InternalResourceView 등)
RedirectViewMethodReturnValueHandler	String + "redirect:" prefix	redirect:로 시작하면 리다이렉트 처리
CallableMethodReturnValueHandler	Callable<T>	비동기 처리용
DeferredResultMethodReturnValueHandler	DeferredResult<T>	비동기 처리용
ResponseBodyEmitterReturnValueHandler	ResponseBodyEmitter, SseEmitter	서버-푸시 또는 SSE 처리
StreamingResponseBodyReturnValueHandler	StreamingResponseBody	스트리밍 응답 처리
AsyncHandlerMethodReturnValueHandler	위 비동기 관련 핸들러들의 공통 super type 역할	내부에서 조건 분기할 때 사용

여기서 우리가 주목해야 할 것은 `HttpEneityMethodProcessor` 와 `RequestResponseBodyMethodProcessor`이다.

왜냐하면 대부분 `ResponseEntity`를 반환하거나 `@ResponseBody`가 붙은 메서드를 사용하니까 말이다.

HttpEntityMethodProcessor

HttpEntityMethodProcessor는 스프링 MVC에서 컨트롤러 메서드의 반환값이 HttpEntity나 ResponseEntity일 때 그 결과를 직접 HTTP 응답으로 만들어주는 클래스이다.

헤더·상태코드·본문을 ResponseEntity 객체로부터 꺼내서 HttpServletResponse에 세팅한다.

⁉️ HttpEntity vs ResponseEntity

`HttpEntity`는 본문 + 헤더
`ResponseEntity`는 본문 + 헤더 + 상태코드

RequestResponseBodyMethodProcessor

반환 타입이 그 외(예: DTO 객체, String, void 등)이고 메서드나 클래스에 `@ResponseBody` 또는 `@RestController` 가 붙어 있을 때 동작한다.
이 핸들러는 상태 코드를 항상 200 OK로, 헤더는 기본값으로 두고
반환 객체를 `HttpMessageConverter` (예: MappingJackson2 HttpMessageConverter)로 직렬화해서 응답 바디에 쓴다.

❓ResponseEntity를 사용하지 않는 이유?

정확히 말하면 필요한 곳이 아니면 사용하지 않는다.

실제로 받은 코드 리뷰

지금은 코드 리뷰에서 작성된 것에서 조금은 수정되었다.

RestController에서 반환값 전체를 ResponseEntity로 했다가 제거한 이유

처음에는 RestController에서 모든 메서드가 ResponseEntity를 반환하도록 했습니다.
상태 코드 제어 및 헤더 조작이 가능하기에 해당기능이 필요할 때만 사용하기보다는 일관성 있게 모든 RestController 메서드에서 동일한 값을 반환하도록 해서 일관성을 확보하고자 했습니다.

하지만 지금 다시 생각해 보니 잘못 생각한 것 같았습니다.
일단 반환할 때마다 불필요한 객체생성이 됩니다.
물론 해당 기능으로 조작이 필요할 때는 유용하지만 다른 어노테이션으로 일부는 커버가 가능합니다.
단순 상태 코드 지정을 위해서는 @ResponseStatus어노테이션을 사용했습니다.
즉, 헤더를 조작하거나 동적으로 상태코드를 조작할 필요가 없다면 ResponseEntity를 쓸 이유를 전혀 찾지 못했습니다.

또한 ResponseEntity 객체로 반환 값을 감싼다는 것은 해당 컨트롤러에서 여러 가지 케이스에 대해서 대체하여 그에 따른 HTTP Status Code를 포함하여 Response Body를 내려주겠다는 의미입니다.
그렇다는 건 개별 컨트롤러 단에서 예외에 대한 핸들링을 진행할 수도 있다는 의미입니다.
이러한 코드는 바람직하지 않다고 생각하여 GlobalExceptionHandler를 만들고 거기서 ResponseEntity를 사용하도록 하였습니다.
이렇게 만들어주면 API 서버에서 발생하는 모든 예외를 해당 객체에서 처리하여 통일성 있는 예외 Response를 내려주고 각 개별적인 컨트롤러에 예외에 대한 핸들링에 대한 책임을 부여하지 않아 컨트롤러 계층을 작게 가져가기 위함입니다.

ResponseEntity 사용하기 for 캐싱

(이 부분은 그냥 건너뛰어도 된다)

결론부터 말하면 ETag 기반 캐시 처리를 제대로 사용하려면 `ResponseEntity`를 반환해야 한다.

왜냐하면 `HttpEntityMethodProcessor`만이 ETag와 관련된 조건부 요청(If-None-Match 등)을 해석하고 처리하기 때문이다.

`handleReturnValue` 메서드를 살펴보다 우연히 발견한 것이 있다.

아래 코드를 보면 200 OK 만 따로 선별해서 처리하고 있다.

이걸 보는 순간 "왜 200 OK만 따로 처리하지?"라는 궁금증이 생겼고

이것이 캐시와 연관되어 있다는 것을 알게 되었다.

ETag란?

ETag는 서버가 리소스(파일, JSON, HTML 등)의 고유한 식별자를 만들어 클라이언트에게 응답 헤더로 보내주는 값이다.
이 값은 주로 리소스의 내용 기반 해시 또는 버전 번호 등으로 만들어지며, 클라이언트는 이 값을 캐시에 저장하고 다음 요청 시 서버에 보내 비교하게 된다.

자주 조회되지만 자주 바뀌지 않는 데이터에 사용할 때 가장 효과적이다.
(ex 사용자 프로필, 게시글, 상품 상세 등)

ETag는 서버가 저장해서 기억하고 있는 게 아니라 리소스의 현재 상태를 기반으로 매번 계산해서 비교하기 때문에 서버가 여러대라도 대응이 가능하다.
즉, 매번 동일한 리소스 상태라면 매번 동일한 ETag가 생성된다.

ETag를 활용한 예시

서버 응답 시

HTTP/1.1 200 OK
ETag: "abc123"
Content-Type: application/json

{ "name": "cheolwon" }

클라이언트는 "abc123"이라는 ETag를 캐시에 저장한다.

클라이언트가 재요청 시

GET /user HTTP/1.1
If-None-Match: "abc123"

서버는 이 ETag와 현재 리소스의 ETag를 비교한다.

만약 같다면

HTTP/1.1 304 Not Modified

위와 같이 응답하고 클라이언트에서 캐시 된 데이터를 사용한다.

만약 다르다면

HTTP/1.1 200 OK
ETag: "new456"
Content-Type: application/json

{ "name": "cheolwon updated" }

새로운 ETag와 함께 새로운 데이터를 반환한다.

해당글은 ResponseEntity에 관한 글이기 때문에 ETag설명은 여기까지 하고 더 궁금하다면 아래 글을 참고해 보면 좋을 것 같다.

Etag를 이용하여 더 나은 Restful API 만들기

Reference

- ResponseBody

- ResponseEntity

- Using Spring ResponseEntity to Manipulate the HTTP Response

- 제제의 ResponseBody vs ResponseEntity

- [Spring] ResponseEntity vs DTO

@RequestBody 이게 뭐야?

개발자성장기 — Thu, 17 Apr 2025 21:55:59 +0900

웹 개발을 공부하다 보면 클라이언트와 서버라는 말을 자주 듣게 된다.

간단히 말해 클라이언트는 웹브라우저처럼 서버에 정보를 요청하는 쪽이고, 서버는 이 요청을 받아서 처리한 후 응답을 보내주는 쪽이이다.
클라이언트가 서버에게 보내는 메시지를 요청(Request)이라고 하고, 반대로 서버가 클라이언트에게 보내는 메시지를 응답(Response)이라고 부른다.

우리가 사용하는 많은 웹사이트는 페이지를 새로 고치지 않고도 데이터를 주고받으며 자연스럽게 동작한다.

이런 방식을 바로`비동기 통신`라고 한다.

비동기 통신을 하려면 클라이언트는 서버에게 요청을 보낼 때 데이터를 'Body'라는 부분에 담아서 보내야 한다.

서버도 클라이언트에게 응답할 때 마찬가지로 'Body'에 데이터를 담아서 보내준다.

이렇게 Body에 담아서 보내는 데이터를 각각 요청 Body, 응답 Body이라고 한다.
'Body'에 담길 수 있는 데이터 형식은 다양하지만, 가장 널리 사용되는 것은 JSON이라는 형식이다.

즉, 비동기 방식에서는 클라이언트와 서버가 주로 JSON 형식의 데이터를 주고받는다.

스프링을 사용할 때도 이 방식이 자주 사용된다.

클라이언트가 JSON이나 XML 등의 데이터를 보내면, 스프링이 자동으로 이 데이터를 자바 객체로 변환해서 처리할 수 있도록 도와준다.

여기서 중요한 역할을 하는 것이 바로 `@RequestBody`와 `@ResponseBody`라는 어노테이션이다.

`@RequestBody`는 클라이언트에서 보낸 HTTP 요청 Body(JSON 등)을 자바 객체로 바꿔준다.
`@ResponseBody`는 자바 객체를 다시 HTTP 응답 Body(JSON 등)으로 바꿔서 클라이언트에 보내준다.

이렇게 스프링 MVC는 비동기 통신을 더욱 쉽게 할 수 있도록 많은 편의 기능을 제공한다.

자 이제 대략적인 흐름을 알았으니 본격적으로 `@RequestBody`에 대해서 알아보자.

@RequestBody

HTTP 요청으로 넘어오는 body의 내용을 HttpMessageConverter를 통해 자바 객체로 바꿔준다. (역직렬화)

HTTP 요청의 body 내용을 통째로 자바 객체로 변환해서 매핑된 메소드 파라미터로 전달해준다.

그럼 도대체 언제 바꿔주는 걸까?

그전에 `@RequsetBody`가 Spring Web MVC 모듈에서 HTTP 요청이 오면 대략적으로 언제 동작하는지 알기 위해 Dispatcher Servlet의 흐름을 대강 알아보자.

source : 망나니개발자

1. 클라이언트의 요청을 디스패처 서블릿이 받음

2. 요청 정보를 통해 요청을 위임할 컨트롤러를 찾음

3. 요청을 컨트롤러로 위임

4. 핸들러 어댑터가 컨트롤러로 요청을 위임함

5. 비지니스 로직을 처리함

6. 컨트롤러가 반환값을 반환함

7. 핸들러 어댑터가 반환값을 처리함

8. 서버의 응답을 클라 이언트로 반환함

"갑자기 뭐지? 이걸 다 이해하라고?"

절대 아니다 그러니 걱정할 필요는 없다.

지금 당장 Dispatcher Servlet을 전부 이해하라는 소리가 아니다.

지금은 그냥 "클라이언트의 요청을 Dispatcher Servlet이 요청을 처리할 컨트롤러를 찾아서 위임하고, 그 결과를 받아서 클라이언트로 반환한다"는 정도만 이해하면된다.

(더 자세히 이해하고 싶다면 이곳으로 가면 된다.)

우리는 여기서 4번째 과정인 "핸들러 어댑터가 컨트롤러로 요청을 위임함"에만 집중하면 된다.

source : 망나니 개발자

바로 여기서 `@RequestBody`가 드디어 일을 시작한다.

쉽게 말해 클라이언트에서 보낸 요청에 있는 body를 자바 객체로 바꿔주는 일을 바로 여기서한다.

`@RequsetBody`는 HTTP 요청으로 같이 넘어오는 Header의 Content-type을 보고 어떤 `Converter`를 사용할지 정하기에 Content-type을 반드시 명시해야 한다.

(Content-type은 따로 default 값이 없다. 그래서 프론트엔드와 협업할 때 종종 요청에 Content-Type을 명시하지 않아 에러가 발생하기도 한다)

Content-Type이란?
HTTP 요청이나 응답이 주고받는 데이터가 어떤 형식인지 명시하는 헤더이다.

naver 메인화면

자주 사용하는 Content-type 종류
- application/json : JSON 데이터 전송
- application/x-www-form-urlencoded : 폼 데이터 전송 (HTML 폼 형식)
- application/xml : XML 데이터 전송
- text/plain : 단순 문자열 데이터를 보낼 때 사용
- multipart/form-data : 파일 전송 (spring에서는 주로 @RequestPart와 함꼐 사용)
- text/html : HTML 전송

자 이제 Content-type을 대략적으로 알았으니 이제 좀 전에 말한 "Converter"에 대해서 알아보자.

일단 자세히 알아보기 전에 요약하자면 스프링에서는 위에서 말한 작업을 HttpMessageConverter라는 친구가 자동으로 처리해준다.
기본적으로는 Jackson이라는 라이브러리를 사용해서 JSON -> 객체(역직렬화) / 객체 -> JSON(직렬화)로 변환을 해준다.

그럼 여기서 말한 HttpMeesageConverter는 무엇일까?

HttpMessageConverter

Spring 웹 모듈에는 HttpMessageConverter라는 인터페이스가 있다. (조금 뒤에서 보여드릴게요 )

이 인터페이스는 HTTP 요청의 바디와 응답의 body를 읽고 쓰는데 사용된다.

Spring은 다양한 미디어 타입에 맞는 여러 구현체를 기본으로 제공하며, 필요에 따라 개발자가 직접 구현하거나 커스터마이징할 수도 있다.

그리고 이러한 구현체들은 기본적으로 `RestTemplate`이나 `RequestMappingHandlerAdapter`에 등록되어 있어, 특별한 설정 없이도 편리하게 사용할 수 있다.

주요 HttpMessageConverter 구현체들

StringHttpMessageConverter

HTTP 요청이나 응답의 바디를 String으로 읽거나 쓸 수 있도록 도와준다.

기본적으로 모든 텍스트를 지원하면 응답 시 Content-Type은 text/plain으로 설정된다.

FormHttpMessageConverter

HTML 폼 데이터를 변환한다.

기본적으로 application/x-ww-form-urlencoded 타입을 읽고 씁니다.

ByteArrayHttpMessageConverter

HTTP 메시지를 바이너리 배열(byte[])로 변환한다.

기본 application/octet-stream이다.

MarshallingHttpMessageConverter

XML 데이터 처리를 위한 변환키로, Spring의 Marshaller와 Unmarshaller를 사용한다.

기본적으로 text/xml과 application/xml 미디어 타입을 지원한다.

MappingJackson2HttpMessageConverter

Json 데이터를 변환하는 대표적인 구현체로, Jackson의 ObjectMapper를 사용한다.

기본적으로 application/json 미디어 타입을 지원한다.

Jackson 애노테이션을 이용해 JSON 매핑을 커스터마이징할 수 있다.

커스텀 ObjectMapper를 주입하여 더욱 세밀한 제어가 가능하다.

Spring에서는 위의 HttpMessageConverter 구현체들이 기본적으로 등록되어 있어, RestController를 사용할 때 별도의 설정 없이도 HTTP 요청과 응답의 데이터를 자동으로 변환해준다.

예를 들어, 클라이언트가 JSON 데이터를 보내면, `MappingJackson2HttpMessageConverter`가 이를 자바 객체로 변환해주고, 서버가 자바 객체를 JSON으로 응답할 때 역시 같은 변환기를 사용한다.

개발자는 필요한 경우, 특정 미디어 타입을 지원하도록 변환기를 커스터마이징하거나 새롭게 등록할 수 있다.

이러한 유연성 덕분에 다양한 데이터 포맷과 복잡한 요구 사항에 쉽게 대응할 수 있다.

그럼 HttpMessageConverter는 이 많은 구현체들 중 어떻게 알맞은 컨버터 구현체를 골라서 역직렬화(JSON -> 객체)를 할 수 있을까?

이전에 소개만 HttpMessageConverter의 모든 구현체들은 아래 `interface`에 있는 메서드를 당연히 갖는다.

`canRead`는 요청 body를 특정 타입으로 읽어들일 수 있는지 판단할 때 사용한다.

(클라이언트가 @RequestBody로 객체를 받을 때 - 역직렬화)

`canWrite`는 객체를 응답 body로 쓸 수 있는지 판단할 때 사용한다.

(컨트롤러가 반환한 객체를 @ResponseBody or ResponseEntity로 JSON/XML등으로 내보낼 때 - 직렬화)

자 이제 위 내용을 바탕으로 대략적으로 역직렬화가 어떻게 동작하는지 알아보자

프론트에서 아래와 같은 요청을 보냈다고 가정해보자

POST /reservations HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{
  "name": "홍길동",
  "date": "2025-04-20",
  "time": "15:30:00"
}

@RestController
@RequestMapping("/reservations")
public class ReservationController {

    @PostMapping
    public ResponseEntity<Reservation> create(@RequestBody ReservationRequest request) {
      // ...
    }
}

`@RequestBody` 어노테이션이 있기에

1. DispatcherServlet이 요청을 받는다.

2. HandlerMapping -> `/reservations` url에 매핑된 `creat(...)` 메서드를 찾음

3. HandlerAdapter 메서드를 실행하기 전 인자 해석 단계로 진입

4. RequestResponseBodyMethodProcessor

`@RequestBody`붙은 파라미터에 대해 등록된 HttpMessageConverter들 중 `canRead(ReservationRequest.class, MediaType.APPLICATION_JSON)`이 `true`인 컨버터 선택

실제 컨버터를 선택하는 코드는 일부이다.

`this.messageConverters`를 순회하면서 `canRead(...)`메서드를 통해 알맞은 컨버터 타입을 찾고있음을 알 수 있다.

컨버터의 순서는 공식문서에서 MessageConverter Implementations 표에 있는 순서와 동일하다)

대개 객체라면 `MappingJackson2HttpMessageConverter`가 선택되어, 내부 `ObjectMapper`로 역직렬화(JSON -> ReservationRequest 객체 생성)를 한다.

여기서 ObjectMapper는 Jackson 라이브러리의 클래스이다.

`spring-boot-starter-web`의존성만 추가해도 포함되는 라이브러리다.

`objectMapper.readValue`를 호출해 JSON을 `ReservationRequest` 같은 자바타입으로 변환한다.

이렇게 변환할 때 해당 객체는 반드시 기본 생성자(매개변수가 없는 "비어있는" 생성자)를 가지고 있어야한다.

물론 자바가 아무 생성자도 가지고 있지 않다면 컴파일러가 자동으로 기본 생성자를 만들어주기 때문에 신경쓸 필요가 없지만 매개변수가 있는 생성자를 만들면 명시적으로 기본 생성자를 만들어줘야한다.

그렇다면 왜 기본생성자를 요구할까?

Jackson 라이브러리는 객체를 역직렬화(deserialization)할 때 내부적으로 객체를 먼저 생성하고 그 다음에 리플렉션으로 필드를 채워 넣기 때문이다.

Jackson의 역직렬화 과정

1. 객체 생성
Jackson은 대상 클래스의 기본 생성자를 호출하여 객체를 생선한다.
기본 생성자가 없을 경우, @JsonCreator와 @JsonProperty를 사용하여 매개변수 있는 생성자를 통해 객체를 생성할 수 있다.
public class Person {
    private final String name;
    private final int age;

    @JsonCreator
    public Person(@JsonProperty("name") String name,
                  @JsonProperty("age") int age) {
        this.name = name;
        this.age = age;
    }
    // Getter methods...
}
2. 필드 값 주입
생성된 객체에 JSON의 각 필드 값을 주입한다. 이때, Jackson은 다음과 같은 방법을 사용한다.
1. Setter 메서드 : 해당 필드에 대한 setter 메서드가 존재하면 이를 호출하여 값을 설정한다.
2. 직접 필드 접근 : setter 메서드가 없을 경우, 리플렉션을 통해 필드에 직접 접근하여 값을 설정한다.

Jackson의 직렬화 과정

직렬화 할 때는 이미 만들어진 객체에서 Jackson 내부적으로 getter 메서드를 호출해서 값을 읽고 JSON 문자열로 변환한다.
따라서 역질렬화 과정과 다르게 기본 생성자는 필요없고 getter만 있으면 된다.

만약 getter이 없다면 Jackson은 아무 필드도 읽지 못해서 빈 JSON이 나올 수 있다.
하지만 `@JsonProperty`나 `@JsonAutoDetect`등의 어노테이션을 쓰면 리플렉션으로 필드 값을 읽을 수 있도록 강제할 수 있다.
public class Person {
    @JsonProperty
    private String name;

    @JsonProperty
    private int age;
}
➡ 이런 경우엔 getter 없어도 직렬화 가능!

위와 같은 과정을 거치면 요청 Body에 있는 JSON이 객체로 변환되고 그것을 통해 내부 비즈니스 로직이 동작한다.

기본 생성자가 없는 경우도 있는데 이는 왜 역직렬화가 되는거죠?

Jackson은 객체에 생성자가 하나만 있으면 그 생성자를 묵시적(@JsonCreator 없이)으로 ‘Creator’로 간주해서 디폴트 생성자 없이도 역직렬화해 준다.

다만 이게 잘 동작하려면 다음 조건이 충족되어야 한다.

생성자가 오직 하나여야 한다
- 다른 파라미터 생성자가 하나라도 더 있으면 Jackson은 어느 쪽을 쓸지 몰라서 에러를 낸다.
파라미터 이름이 JSON 필드 이름과 일치해야 한다

<작성 예정>

Controller에서 받을때 어노테이션 생략시 @ModelAttribute가 기본값이므로 @RequestBody를 사용하고자 하는 경우에는 반드시 기술해야 한다.

Reference

https://www.baeldung.com/jackson-deserialization

https://www.baeldung.com/jackson-object-mapper-tutorial

https://docs.spring.io/spring-framework/reference/web/webmvc/message-converters.html

https://github.com/FasterXML/jackson

[Spring] Dispatcher-Servlet(디스패처 서블릿)이란? 디스패처 서블릿의 개념과 동작 과정