어제오늘내일

[O+T] 영상 품질 기반 개선기 (2. Per-Title-Encoding)

phonil — Fri, 26 Jun 2026 14:40:13 +0900

[O+T]: 영상 품질 측정하기 (1. 올바른 영상 변환과 품질 측정)

영상 트랜스코딩 - VMAF 품질 측정 과정을 거치며 마주한 문제를 해결하는 과정에 대해 적어놓은 글입니다. 문제 해결 중심으로 글이 전개되므로 영상에서 사용하는 개념에 대한 설명이 적게 들

yestomo.tistory.com

0. 개요

1편을 진행하기도 전.. 프로젝트를 막 시작했을 때, 팀원들과 영상에 대해 처음 공부하고 이것저것 알아보며 Per-Title-Encoding이라는 것을 알게 되었습니다. 프로젝트 기간에는 시간이 부족해서 완성하지 못했지만, 그때 논의했던 것들이 생각나 따로 공부해봤습니다.

영상 단위로 최적화하는 Per-Title-Encoding도 있고, 아예 장면 단위로 최적화를 진행하는 Per-Shot-Encoding도 있지만, 넷플릭스나 유튜브처럼 초대형 플랫폼이 아니라면 큰 의미가 있지는 않을 것이라고 생각했습니다.

1편에서는 트랜스코딩 결과물을 VMAF로 믿고 측정할 수 있게 만들고, 변환 시 기본적으로 갖춰야 할 요소들(정렬·CFR·GOP·매니페스트)을 보완했습니다. 그 과정에서 모든 영상의 VMAF 점수가 94~97점으로 높게 나타났습니다.

이번 2편에서는 그 기준선 위에서 '모든 영상에 같은 bitrate ladder를 쓰는 것이 정말 효율적인가?'를 따져보았습니다.

효과를 확실하게 살펴보고자 영상은 저/중/고 복잡도로 구분하여 3개 준비했고, 작업에 앞서 이번 작업의 최종 결과를 표로 먼저 정리해봤습니다.

영상	복잡도	PTE 판단	결과
Big Buck Bunny	저복잡도	줄여도 됨	총 bitrate 36.1% 절감
Meridian	중복잡도	일부 절감 가능	총 bitrate 12.4% 절감
Tears of Steel	고복잡도	무리한 절감 부적합	총 bitrate 6.8% 증가, 품질 방어

PTE는 '압축률을 무조건 높이는 기술'이 아니라 영상별로 적절한 품질-용량 균형점을 찾는 과정이었음을 확인할 수 있었습니다.

1. Per-Title-Encoding 소개

영상 인코딩과 재생 시 사용되는 데이터의 양을 비트레이트라고 하며, 이에 따라 파일의 용량이 결정됩니다.
해당 프로젝트도 그렇고, 대부분의 영상 스트리밍 서비스에서는 영상을 S3같은 저장소에 저장하고, CDN을 사용하기도 합니다. 영상 자체가 대부분 크기가 매우 큰 파일이기 때문에 이 용량이 항상 비용과 직결됩니다. 따라서 품질에 이상이 없는 한 용량을 최대한 줄여 저장 공간을 효율적으로 사용할 필요가 있습니다.

전송 측면에서도 동일하게 적은 비트레이트로 충분한 영상에 많은 비트레이트를 할당하게 되면 전송량이 낭비될 수 있습니다.
이러한 문제를 해결하기 위해 영상별 최적화 방식인 Per-Title-Encoding을 도입해보기로 결정했습니다.

1-1. 기존 방식: 모든 영상에 같은 Ladder 사용

위 표는 넷플릭스에서 제시한 대부분의 영상에 적합한 해상도 x 비트레이트 조합입니다. 이를 바탕으로 기존 트랜스코딩 과정에서는 영상이 무엇이든 360p·720p·1080p에 고정 비트레이트(800·2400·4800k)를 주도록 구성했습니다. 어떤 영상이든 업로드되면 360p, 720p, 1080p를 만들고, 각 해상도에 고정된 bitrate를 적용합니다.

하지만, 영상마다 필요한 bitrate가 다르다는 점을 온전히 반영하지는 못합니다. 같은 1080p라도 영상이 단순하면 낮은 bitrate로도 충분하고, 영상이 복잡하면 더 많은 bitrate가 필요할 수 있습니다. 잔잔한 애니메이션과 장면 전환이 잦은 액션 영상에 같은 비트레이트를 주면 단순한 영상은 용량을 낭비하고 복잡한 영상은 품질이 떨어질 수 있습니다.

1-2. Per-Title-Encoding이란 무엇인가?

PTE(Per-Title Encoding)는 영상마다 최적의 비트레이트 ladder를 측정으로 결정하는 방법입니다. 한 영상을 여러 품질 후보로 인코딩해보고, 화질(VMAF)과 용량(비트레이트)을 함께 재서 가장 효율적인 지점을 고르는 것입니다.

PTE의 핵심은 '영상별 품질-용량 곡선'을 찾는 것입니다.

구분	기존 고정 ladder	PTE
기준	모든 영상 동일	영상별로 다름
판단	해상도별 고정 bitrate	후보별 bitrate-quality 측정
장점	단순, 운영 쉬움	영상별 최적화 가능
단점	쉬운 영상은 용량 낭비, 어려운 영상은 품질 부족 가능	후보 인코딩/측정 비용 증가
결과	하나의 공통 ladder	영상마다 다른 ladder

주의할 점은 용량을 줄이는 것이 목적이긴 하지만, 무작정 줄이면 안 된다는 점입니다. 적절한 품질을 유지하는 선에서 용량을 절감하는 것이 핵심입니다.

품질 지표로 사용되는 VMAF 6점당 1JND(사람이 눈으로 인식 가능한 품질 차이라고 하네요..!)라고 합니다. 이를 활용해서 JND 하락을 신경 쓰며 작업을 수행해야 합니다. 어쨌든 영상 플랫폼의 주 목적은 좋은 품질의 영상을 제공하는 것도 있기 때문입니다!

PTE는 단순히 bitrate를 줄이는 기술이 아닙니다. 더 정확히는 아래 내용을 자동화하는 과정입니다.

영상 상태	PTE 판단
기존 bitrate가 과한 영상	bitrate를 줄인다
기존 bitrate가 적절한 영상	유지하거나 일부만 줄인다
기존 bitrate가 부족한 영상	줄이지 않거나 오히려 품질을 방어한다

PTE의 목적은 '적절한 비트레이트'를 설정하여 모든 영상을 작게 만드는 것이 아니라, 영상별로 적절한 품질-용량 균형점을 찾는 것입니다.

PTE 작업은 위 흐름으로 이어집니다.

1-3. 가설

복잡도가 낮은 영상은 Bitrate가 적게 필요하고, 복잡도가 높은 영상은 상대적으로 Bitrate가 많이 필요할 것이라고 생각했습니다. 따라서 영상의 복잡도에 따라 절감되는 Bitrate 비율이 달라질 것이라고 생각했습니다. 특히, 고복잡도 영상의 고화질에서는 Bitrate 절감보다 영상 품질 방어를 위해 오히려 Bitrate를 더 사용할 수도 있습니다.

복잡도가 낮은 영상은 적은 bitrate로도 충분한 품질을 유지할 수 있고, 복잡도가 높은 영상은 같은 품질을 유지하기 위해 상대적으로 더 많은 bitrate가 필요할 것이라고 생각했습니다.
따라서 PTE를 적용하면 영상 복잡도에 따라 결과가 다르게 나올 것이라고 가정했습니다.

고복잡도 영상에서는 '얼마나 줄였는가'보다 '무리하게 줄이지 않는가'가 더 중요하다고 보았습니다. PTE가 단순한 용량 절감 기술이라면 고복잡도 영상에서도 억지로 bitrate를 낮추겠지만, 실제로 필요한 것은 영상별 품질-용량 균형점을 찾는 것입니다.
그래서 이번 실험에서는 다음 두 가지를 함께 확인했습니다.

확인할 것	의미
Bitrate 변화	기존 고정 ladder보다 얼마나 줄거나 늘었는가
VMAF 변화	bitrate 변화 후 품질이 유지되는가

이를 바탕으로 영상 복잡도가 낮을수록 bitrate 절감 폭이 크고, 복잡도가 높을수록 절감 폭은 줄어들거나 품질 방어를 위해 bitrate가 증가할 것이라는 가설을 세웠습니다.

2. 대표 구간 추출

PTE는 영상을 여러 후보로 인코딩해 비교하는데, 영상 인코딩과 VMAF 측정은 영상 길이에 비례해 시간이 늘어납니다. 특히, VMAF는 원본과 후보 영상을 프레임 단위로 비교하기 때문에 후보 수가 늘어날수록 비용이 급격히 커집니다. 실제로 1시간 짜리 영상을 인코딩하고 VMAF 측정하는 데 각각 50분 이상 걸렸던 것으로 확인한 적이 있습니다.

그런데 후보는 해상도 × CRF 조합이라 수가 많고, 이걸 전체 영상마다 돌리면 매우 오랜 시간과 자원이 필요합니다. 그래서 전체를 대신할 대표 구간을 뽑아 인코딩과 VMAF 측정 시간을 줄이고, 이들을 통해 Ladder를 결정하기로 했습니다.

2-1. 대표 구간 정의

대표 구간은 하나의 '평균 장면'만 의미하지 않습니다. PTE에서는 쉬운 구간과 어려운 구간을 모두 봐야 합니다. 쉬운 구간만 보면 bitrate를 너무 많이 줄여도 된다고 오판할 수 있고, 반대로 어려운 구간만 보면 모든 영상을 지나치게 보수적으로 인코딩하게 되기 때문입니다.
그래서 이번 실험에서는 영상마다 5개 구간을 사용했습니다.

구간	의미	목적
LOW	복잡도가 낮은 구간	절감 가능성 확인
AVERAGE_1	평균적인 구간 1	일반 품질 확인
AVERAGE_2	평균적인 구간 2	평균 구간 편향 완화
SCENE_CHANGE	장면 전환이 뚜렷한 구간	전환 구간 품질 확인
HIGH	복잡도가 높은 구간	품질 붕괴 방지

대표 구간을 영상의 난이도 분포를 나눠서 보는 샘플로 구성하고자 했습니다.

2-2. 구간 분석 방식

해당 구간의 복잡도가 얼마나 되는지, 장면 전환은 어떻게 되는지 등을 사람이 확인할 수는 없었습니다. 많은 영상을 모두 할 수 없을 뿐더러 직접 고르면 기준이 흔들리고, 나중에 자동화하기 어렵기 때문입니다.

영상 분석 지표를 기준으로 구간을 분석했습니다.

지표	역할	사용 방식
SI	공간 복잡도, 디테일/질감	FFmpeg로 영상을 디코딩하면서 프레임별 공간/시간 복잡도 계산
TI	시간 복잡도, 움직임	FFmpeg로 영상을 디코딩하면서 프레임별 공간/시간 복잡도 계산
Scene Change Density	장면 전환 구간 선택	FFmpeg scene change 계열 필터로 컷 변화 감지
Black Frame Ratio	검은 화면/무의미 구간 제외	FFmpeg blackdetect 계열로 검은 구간 감지
Luma Mean	극단적으로 어둡거나 밝은 무정보 구간 보조 판단	FFmpeg signalstats 계열로 밝기 평균 확인

이 지표들을 이용해 각 구간의 복잡도를 계산했습니다.

대표 구간 추출 흐름

5단계를 거쳤으며, 각 단계에서 이상치를 줄이려고 노력했습니다. 구간들이 너무 붙어있거나 크레딧이나 의미 없는 장면이 대표 구간으로 선택될 수 있었고, 이들은 압축 난이도를 대표하기 어렵기 때문입니다.

2-3. 한계

대표 구간 방식은 전체 영상을 완전히 대체하지 않기 때문에 대표 구간 밖에서 품질이 무너질 가능성은 항상 남아 있습니다. 그래서 대표 구간은 후보 탐색에만 사용했고, 최종 선택된 ladder는 반드시 전체 영상으로 다시 검증했습니다.

대표 구간의 역할은 최종 판단이 아니라 탐색 비용 절감으로 후보 Ladder를 빠르게 찾는 것입니다.

3. 인코딩 조합 후보 생성 및 인코딩

영상마다 대표 구간 5개를 뽑은 후 이제 이 구간들을 실제 인코딩 후보로 펼쳐야 합니다. PTE에서 필요한 것은 '이 영상은 복잡하다/단순하다'는 판단이 아닌 실제로 여러 설정으로 인코딩했을 때, 각 설정이 어느 정도 bitrate와 품질을 만드는지입니다.

그래서 이 단계에서는 대표 구간을 해상도와 CRF 조합으로 인코딩해 후보군을 만들었습니다.

3-1. 후보 축 결정: 해상도 × CRF

후보는 해상도와 CRF 두 축으로 만들었습니다.
해상도는 360p/720p/1080p 3개로, CRF는 18/21/24/27/30 5개로 정했습니다. CRF 값이 낮을수록 화질이 좋고 bitrate가 커집니다. 해상도는 업스케일하지 않아 원본이 720p이라면 최대 제공 해상도는 720p로 설정됩니다.

CRF란?

CRF(Constant Rate Factor)는 목표 비트레이트가 아니라 목표 화질 수준을 정해 인코딩하는 방식입니다.
PTE에서 CRF를 쓴 이유는 영상마다 복잡도가 다르기 때문에 같은 bitrate로 후보를 찍는 것보다 CRF로 여러 화질 단계를 만들면 영상별 bitrate–quality 관계를 더 자연스럽게 관찰할 수 있기 때문입니다.

후보 생성 방식으로 고정 bitrate, 2-pass ABR, CRF, VMAF Target 방식을 검토했습니다. 고정 bitrate 방식은 ladder 제어가 쉽지만 영상별 복잡도를 반영하기 어렵고, 2-pass 방식은 목표 bitrate 정확도는 높지만 후보 수가 많은 PTE 실험에서는 인코딩 비용이 커집니다. VMAF Target 방식은 품질 기준이 명확하지만 반복 인코딩과 측정 비용이 큽니다.

따라서 초기 후보 생성 단계에서는 CRF를 사용해 동일한 화질 수준에서 영상 복잡도에 따라 자연스럽게 bitrate가 달라지도록 했고, 이후 각 후보의 실제 bitrate와 VMAF를 측정해 Convex Hull 기반으로 비효율 후보를 제거했습니다.

3-2. 후보 수

2장에서 선택한 대표구간은 영상마다 5개입니다.
각 구간마다 3개 해상도와 5개 CRF를 조합했습니다.

세 영상을 모두 실험했기 때문에 총 후보 수는 75 x 3 == 225개가 됩니다.

하지만, 그림처럼 이 75개가 그대로 최종 R-D Curve의 점이 되는 것은 아닙니다. 각 구간은 같은 해상도와 같은 CRF끼리 나중에 합산됩니다.

구간 인코딩 방식

처음에는 빠르게 진행하기 위해 5개 대표구간을 하나의 클립으로 이어붙인 뒤, 15개 후보만 인코딩하는 방식을 생각했습니다. 하지만, 구간을 이어붙이면 새로운 문제가 생길 수 있습니다.

문제	설명
PTS 정렬 위험	구간마다 시간축이 끊기고 다시 붙으면서 PTS reset/offset 문제가 생길 수 있음
가짜 장면 전환	원래 이어지지 않는 장면을 붙이면서 인위적인 컷이 생김
원인 추적 어려움	특정 후보가 나쁠 때 어느 구간 때문인지 분리하기 어려움

이미 PTS 정렬 문제로 VMAF가 크게 흔들리는 것을 겪었습니다..ㅜㅜ...
따라서 PTE 후보 실험에서 다시 시간축 리스크를 만들 이유가 없었기에 구간을 이어붙이지 않고, 각 구간을 독립적으로 인코딩했습니다.
가장 큰 문제는 대표 구간에서 다른 대표 구간으로 이어지는 부분에 어색한 장면 전환이 발생할 것이라 생각했고, 이것이 점수에 영향을 줄 것이라고 판단했습니다.

3-3. 원본과 결과물 클립

VMAF 측정을 하려면 원본 역할을 하는 reference와, 인코딩 결과물인 distorted가 필요합니다.
이 단계에서는 먼저 대표구간마다 reference clip을 뽑아낸 후 reference clip을 해상도와 CRF 조합으로 인코딩해 distorted clip을 만들었습니다.
이렇게 한 이유는 정렬 안정성 때문입니다.

방식	문제
후보마다 원본에서 직접 seek	매번 잘리는 위치가 미세하게 달라질 수 있음
reference clip을 한 번 만들고 재사용	모든 후보가 같은 입력에서 파생되어 프레임 대응이 안정적

이 구조 덕분에 이후 VMAF 측정에서 '서로 다른 구간을 비교하는 문제'를 줄일 수 있었습니다!!

4. VMAF 기반 R-D Curve 그리기

이제 후보들의 VMAF 점수를 측정해서 R-D Curve의 점을 만들어야 합니다. 각 후보가 실제로 어느 정도 bitrate를 만들고, 어느 정도 품질을 내는지 파악하기 위함입니다.

'이 후보가 실제로 얼마나 많은 용량을 쓰는가'를 나타내는 bitrate와 '이 후보가 원본 대비 어느 정도 품질을 유지하는가'를 나타내는 VMAF 점수를 축으로 그래프 위에 점을 찍어 bitrate-quality 관계를 보고자 했습니다. 이 곡선은 bitrate가 증가할 때 품질이 어떻게 좋아지는지 나타내며, R-D Curve(Rate-Distortion Curve)라고 부른다고 합니다!!

원본에 맞춰 VMAF 측정

1편에서는 HLS 결과물이 원본 대비 얼마나 잘 유지됐는지 보기 위해, 원본을 HLS 해상도로 낮춰 비교하는 Downscale VMAF를 사용했습니다.
하지만 PTE에서는 서로 다른 해상도인 360p, 720p, 1080p 후보끼리 비교해야 합니다. 이때, 각 후보를 자기 해상도에서만 비교하면 해상도 간 비교가 불가능해집니다.
예를 들어 360p 후보는 원본을 360p로 낮춰 비교하고, 1080p 후보는 원본을 1080p로 낮춰 비교한다고 하면 신뢰할 수 없는 결과가 나타날 수 있습니다.

PTE에서는 실제 사용자가 보는 화면 기준에서 후보들을 비교해야 합니다. 그래서 후보들을 공통 기준 해상도로 올려 비교했습니다. 해당 프로젝트의 정책으로 설정한 최대 품질인 1080p을 상한선으로 두고 후보들을 1080p 기준으로 비교했습니다. 물론 업스케일을 진행하지 않기 때문에 정확히는 1080p을 넘지 않는 한에서 원본과 1080p 중 더 낮은 것을 원본 기준으로 삼았습니다.

4-1. 왜 R-D Curve가 필요한가?

PTE는 여러 후보 중 VMAF가 가장 높은 것을 고르는 작업이 아닙니다. VMAF가 가장 높은 후보는 보통 bitrate도 가장 큽니다. 예를 들어 CRF 18은 품질은 좋지만 용량이 커질 가능성이 높습니다. 반대로 CRF 30은 용량은 작지만 품질이 떨어질 수 있습니다.
그래서 '어느 지점부터 bitrate를 더 써도 품질 개선이 크지 않은가?'에 대한 판단이 필요합니다.
예를 들어 아래와 같은 후보가 있다고 가정할 수 있습니다.

후보	bitrate	VMAF
A	1000k	88
B	2000k	94
C	4000k	95

A에서 B로 가면 bitrate는 1000k 늘고 VMAF는 6점 오릅니다. 하지만, B에서 C로 가면 bitrate는 2000k나 늘었는데 VMAF는 1점만 오릅니다. 이 경우 C는 품질은 조금 더 좋지만, 효율은 낮을 수 있습니다.

R-D Curve는 그래프를 통해 이러한 판단이 가능하도록 도와줍니다.

4-2. 후보 75개를 R-D 점 15개로 바꾸기

영상마다 75개의 해상도-비트레이트 조합 후보가 존재합니다. 하지만, R-D Curve에서 보고 싶은 것은 '각 구간의 점'보다 '이 영상에서 720p CRF24는 어느 정도 효율인가?'입니다.

그래서 같은 해상도와 같은 CRF끼리 5개 구간을 합쳤습니다.

합산 방식

R-D Curve의 각 점은 bitrate와 VMAF를 가져야 합니다.
bitrate는 CRF 값으로 추정하기보다 5개 구간의 실제 인코딩 결과를 합쳤고, VMAF은 5개 구간의 평균 품질로 계산했습니다.

평균 VMAF가 높아도 특정 구간 하나가 크게 무너지면 실제 시청 품질은 나쁠 수 있습니다.
그래서 이후 후보 선택 단계에서 worst segment와 P5 같은 하위 지표도 함께 확인할 수 있도록 기록했습니다.

4-3. 측정 결과

R-D Curve를 그려보니, 처음 예상처럼 단순히 저복잡도 영상은 항상 효율이 좋고, 고복잡도 영상은 항상 효율이 나쁘다로 정리되지는 않았습니다. 사용자 체감을 나타내는 VMAF를 사용하는 만큼 영상의 특성이 반영되었습니다.

BBB

저복잡도 영상에서는 낮은 bitrate에서도 품질이 잘 유지될 것이라고 예상했고, 실제로 1080p에서는 그 경향이 뚜렷했습니다. 실제로 CRF30에서 CRF24까지는 bitrate를 늘릴수록 VMAF가 의미 있게 상승했지만, CRF24 이후부터는 증가폭이 줄어듭니다.

BBB는 일정 수준 이후부터 bitrate를 더 써도 VMAF가 크게 오르지 않았습니다. 이 곡선은 기존 고정 ladder가 다소 보수적이었고, bitrate를 줄일 여지가 있다는 신호로 볼 수 있습니다. 전반적으로 비트레이트 효율이 꽤 높게 나타나는 것으로 분석할 수 있습니다.

다만, 360p에서는 VMAF가 낮게 나왔습니다. 이는 저복잡도 영상이라도 4K 애니메이션의 선명한 경계와 디테일이 360p로 줄어든 뒤 1080p 기준으로 비교되면 손실이 크게 반영되기 때문입니다.

Meridian

중간 복잡도 영상에서는 저복잡도 영상보다 더 많은 bitrate가 필요할 것이라고 예상했습니다. 하지만 R-D Curve에서 예상과 다른 부분이 있었습니다. 오히려 BBB보다 낮은 bitrate로 비슷한 VMAF에 도달했습니다.

Meridian이 BBB보다 더 효율적이지만, Meridian이 전체적으로 더 쉬운 영상이라는 뜻은 아닙니다.
Meridian은 어두운 SF로, 화면에 검은 영역이 많은 영상입니다. 검은 부분은 압축 비용이 저렴해서 적은 비트레이트로도 인코딩이 가능했기 때문에 예상했던 BBB와 Tears 사이로 나타나지 않은 것입니다.

Meridian은 낮은 구간에서 비트레이트 효율이 매우 높게 나타난 대신, 천장이 좀 낮고 높은 해상도 구간에서의 효율은 조금 낮다고 분석할 수 있습니다.

이는 복잡도 라벨과 VMAF 효율이 완전히 같은 개념이 아니기 때문입니다. Meridian은 실사 영상이지만 중간 품질대에서는 압축 손실이 VMAF에 덜 불리하게 나타났고, BBB는 애니메이션 특유의 선명한 경계와 디테일 손실이 VMAF에 더 민감하게 반영되었습니다.

또한, BBB는 약 3.6Mbps에서 VMAF 95.76까지 올라갔지만, Meridian은 약 4.3Mbps를 사용해도 VMAF 94.17에 머물렀습니다. Meridian의 곡선은 중간 품질대까지는 빠르게 올라가지만, 고품질 구간에서는 빨리 둔화되는 모습을 보입니다.

Tears

고복잡도 영상에서는 VFX, 장면 변화, 디테일이 많기 때문에 같은 품질을 유지하려면 더 많은 bitrate가 필요할 것이라고 예상했고, R-D Curve도 이 방향을 보여줬습니다. 같은 CRF24 기준으로 BBB 1080p는 약 3.6Mbps에서 VMAF 95.76이었지만, Tears는 약 4.8Mbps를 사용해도 VMAF 95.56으로 비슷한 품질에 머물렀습니다.

Tears는 같은 품질을 얻기 위해 BBB보다 더 많은 bitrate가 필요했습니다. 특히 360p와 720p에서는 낮은 bitrate로 줄이면 품질 하락이 커져, 단순 절감보다 품질 방어가 더 중요한 영상으로 볼 수 있습니다.

다만, 1080p에서는 CRF24 근처에서 VMAF 95점대를 확보했기 때문에, 고화질 구간은 무조건 bitrate를 늘리는 것이 아니라 품질을 유지하는 선에서 일부 절감 여지도 있었습니다.

한 번에 보기

세 영상의 그래프를 한 번에 보고 주요 포인트를 뽑아봤습니다.

VMAF 95 라인 교차:
- BBB ≈ 3,600k / Tears ≈ 4,800k / Meridian 도달 불가.
- → 같은 95점을 만드는 비용이 영상마다 다름.
곡선 교차(~2,500k 부근): 저비트레이트에선 Meridian이 위(효율적)지만, 그 지점을 지나면 천장에 막혀 BBB·Tears가 추월. '저비트레이트 효율 ≠ 고품질 가능'을 한 그림이 보여줌.
수확 체감(무릎): 세 곡선 다 초반 급상승 → 90 부근부터 완만. 특히 95 위로는 비트레이트를 크게 써도 거의 안 오름.

PTE와의 연결

BBB: 95를 baseline(5,069k)보다 싸게(3,638k) 달성 → 절감
Tears: 95에 4,800k 필요 ≈ baseline(5,157k) → 더 못 깎음 → 방어
Meridian: 1080p 천장 94 ≈ baseline(4,165k, 94.46) → 1080 유지, 곡선이 낮은 360/720만 절감

5. 후보 추리고 해상도별 Ladder 선택하기

이제 필요한 것은 위에서 그린 점들 중에서 실제 ladder 후보로 볼 만한 점만 남기는 것입니다.
후보는 많지만, 모든 후보가 의미 있는 것은 아닙니다. 어떤 후보는 더 많은 bitrate를 쓰면서도 VMAF가 낮기도 한데, 이런 후보는 실제 서비스 ladder에 들어갈 이유가 없습니다.

저는 Pareto 지배 제거와 Convex Hull이라는 두 단계를 거쳐 후보를 줄였습니다.

5-1. Pareto 지배 제거

먼저 Pareto 기준으로 명백히 비효율적인 후보를 제거했습니다.

A 후보가 B 후보보다 bitrate는 낮거나 같고,VMAF는 높거나 같다면 B 후보는 선택할 이유가 없습니다. 같은 품질이면 더 작은 파일이 좋고, 같은 bitrate면 더 높은 품질이 좋습니다.

예를 들어 아래와 같은 후보가 있다고 하면

후보	Bitrate	VMAF
A	2,000kbps	92
B	2,400kbps	91

B는 A보다 bitrate를 더 쓰면서 VMAF는 낮습니다. 따라서 B는 제거할 수 있습니다.

Pareto 제거 후 남은 후보 수는 다음과 같습니다.

영상	전체 R-D 점	Pareto 통과
BBB	15	11
Meridian	15	12
Tears	15	12

업스케일해서 비교했고, 이 단계의 목적은 최종 후보를 고르는 것이 아니라 명백히 손해인 후보를 먼저 제거하는 것이기 때문에 해상도 간 교차 비교가 가능했습니다.

5-2. Convex Hull

Pareto 제거 후에도 후보가 여전히 많이 남았습니다. Pareto 후보는 '명백히 나쁘지는 않은 점'일 뿐 모두 효율적인 점은 아니므로 다음 단계로 Convex Hull을 사용했습니다.

Convex Hull은 R-D Curve에서 품질 대비 bitrate 효율이 좋은 바깥 경계선을 찾는 과정입니다. 쉽게 말하면, 여러 점 중에서 실제 효율 곡선을 만드는 점만 남기는 것입니다.

세 점을 연결시켜 기울기를 비교합니다. 왼쪽 점부터 시작해서 점1-점3의 기울기보다 점1-점2의 기울기가 작다면(완만함) 효율이 낮다는 뜻이고, 기울기가 크다면(가파름) 효율이 좋다는 뜻입니다.

점 세 개를 이었을 때 기울기가 '가파름-완만함'이면 가운데 점의 효율이 좋고, '완만함-가파름'이면 가운데 점의 효율이 좋지 않다고 정리할 수 있습니다.

여러 점을 이어보면 아래처럼 Pareto, Convex Hull을 그래프로 확인할 수 있습니다.

판단 순서를 아래 5단계로 정리해보았습니다.

1. Pareto 통과 점들을 bitrate 낮은 순서로 정렬한다.
2. 왼쪽부터 점을 하나씩 이어 선을 만든다. 
	- 이웃한 점 사이의 기울기로, 비트레이트를 더 쓸 때 VMAF가 얼마나 오르는 지 확인하기 위함이다.
3. 새 점을 이었을 때, 가운데 점이 그 선보다 아래에 있으면 제거한다.
4. 이걸 끝까지 반복한다.
5. 남은 점들이 bitrate를 더 쓸 가치가 있는 효율 경계선이다.

위 순서로 Convex Hull까지 적용한 결과는 다음과 같습니다.

영상	전체 R-D 점	Pareto 통과	Convex Hull
BBB	15	11	8
Meridian	15	12	10
Tears	15	12	10

15개의 후보 점 중에서 실제 ladder 선택에 참고할 효율 후보는 영상별로 8~10개 정도로 줄었습니다.

5-3. 왜 Pareto만으로는 부족한가?

Pareto만 적용하면 “명백히 손해인 후보”는 제거할 수 있습니다. 하지만 효율이 애매한 후보는 남습니다.
예를 들어 어떤 후보가 아래처럼 있을 때,

후보	Bitrate	VMAF
A	1,000kbps	88
B	1,500kbps	90
C	2,000kbps	91

C는 B보다 bitrate도 높고 VMAF도 높기 때문에 Pareto 기준으로는 제거되지 않습니다. 하지만 B에서 C로 갈 때 bitrate는 500kbps 늘었는데 VMAF는 1점만 올랐습니다. 이 경우 C가 무조건 나쁘다고 할 수는 없지만, 효율이 좋은 지점인지는 따져봐야 합니다. Convex Hull은 이런 후보를 효율선 기준으로 다시 걸러줍니다.

정리하면 Pareto는 더 많이 쓰고도 더 나쁜 후보를 제거하는 것이고, Convex Hull은 남은 후보 중 효율선 안쪽에 있는 후보를 제거하는 것입니다.

5-4. 해상도별 ladder 선택

Pareto와 Convex Hull로 후보를 줄인 뒤에도 바로 최종 ladder가 정해지지는 않습니다.
실제 스트리밍 ladder는 360p, 720p, 1080p처럼 해상도별 rung이 필요합니다. 따라서 최종 선택은 전체 R-D Curve에서 효율적인 후보를 보되, 각 해상도별로 하나씩 선택해야 합니다.

저는 아래와 같은 기준으로 선택했습니다.

1. baseline(PTE 적용 x) 품질을 크게 해치지 않을 것
2. 가능하면 더 낮은 bitrate를 선택할 것
3. 품질이 부족한 영상은 bitrate를 줄이지 말고 방어할 것
4. 각 해상도별 ladder를 유지할 것

무조건 bitrate를 줄이는 것이 아니라, 영상별로 판단했으며, 아래와 같이 정리했습니다.

상황	선택 방향
기존 bitrate가 과한 경우	더 낮은 bitrate 후보 선택
기존 bitrate가 적절한 경우	비슷한 품질의 최소 bitrate 선택
기존 bitrate가 부족한 경우	bitrate를 늘려 품질 방어

결정된 영상 & 해상도 Ladder

영상	360p	720p	1080p	선택 결과
BBB	CRF24	CRF24	CRF24	세 해상도 모두 bitrate 절감
Meridian	CRF18	CRF18	CRF18	360p/720p 절감, 1080p 유지
Tears	CRF21	CRF21	CRF24	360p/720p 품질 방어, 1080p 소폭 절감

BBB는 CRF24에서도 baseline 대비 품질 하락이 JND 미만으로 유지되어, 세 해상도 모두 절감 후보로 선택되었습니다.
Meridian은 360p/720p는 절감 가능했지만, baseline 품질과의 차이를 줄이기 위해 후보 중 가장 높은 품질인 CRF18을 선택했고 1080p는 거의 유지에 가까웠습니다.
Tears는 360p/720p는 기존 bitrate가 부족해 CRF21로 품질을 방어했고, 1080p만 CRF24에서 품질 유지와 소폭 절감 가능합니다.

6. Per-Title-Encoding 적용 전/후 비교

최종으로 선택한 ladder를 실제 전체 영상에 적용해 검증했습니다.
앞 단계까지는 대표 구간 5개를 기반으로 후보를 비교했지만, 대표 구간에서 좋아 보인 선택이 전체 영상에서도 유지되는지는 별도로 확인해야 합니다. 그래서 최종 ladder만 전체 영상으로 인코딩한 뒤, baseline과 같은 조건으로 VMAF를 다시 측정했습니다.

고정 Ladder로 인코딩한 결과와 PTE를 적용한 선택 Ladder 결과의 전체 영상을 1080p로 업스케일하여 VMAF 측정했습니다. 품질에 대한 판단은 Baseline 대비 VMAF 변화량이고, 용량에 대한 판단은 Bitrate 변화량으로 진행했습니다.

6-1. 전체 결과

결과는 영상별로 명확하게 나타났습니다.

비트레이트 비교

모든 영상에서 bitrate가 줄어든 것은 아니고, 영상의 성격에 따라 결과가 달라졌습니다.

BBB      → 기존 ladder가 과해서 크게 줄일 수 있음
Meridian → 일부 줄일 수 있지만 고화질 구간은 유지에 가까움
Tears    → 기존 ladder가 부족해 일부 해상도는 오히려 늘려야 함

이 결과가 무조건 bitrate를 줄이는 작업이 아니라, 영상마다 적절한 품질-용량 균형점을 찾는 작업인 PTE의 핵심을 잘 보여줍니다.

VMAF 비교

품질 변화가 전부 JND(±6) 이내로 나타났습니다. 고정 래더에서 목표 품질 달성에 부족했던 건 품질을 높였고, 품질에 여유가 있었던 건 품질을 낮추어 용량을 줄이는 방안으로 진행되었습니다.

6-2. BBB 결과

BBB는 저복잡도 영상으로, 가장 큰 절감 효과가 나왔습니다.

해상도	Baseline bitrate	PTE bitrate	변화율	Baseline VMAF	PTE VMAF	VMAF 변화
360p	959k	602.5k	-37.2%	65.76	62.09	-3.67
720p	2641k	1747.6k	-33.8%	90.95	88.68	-2.27
1080p	5069k	3185.9k	-37.2%	96.72	95.17	-1.55

BBB는 세 해상도 모두 CRF24가 선택되었습니다. 전체 bitrate는 약 36.1% 줄었고, VMAF 하락은 모두 JND 기준인 6점 이내였습니다.
특히, 1080p는 bitrate를 약 37% 줄였지만 VMAF는 1.55점만 낮아졌습니다. 기존 고정 ladder가 BBB에는 다소 과하게 잡혀 있었던 것이고, 품질을 크게 해치지 않으면서 bitrate를 줄일 수 있었습니다.

6-3. Meridian 결과

Meridian은 중간 복잡도 영상으로, 일부 절감 효과가 나왔습니다.

해상도	Baseline bitrate	PTE bitrate	변화율	Baseline VMAF	PTE VMAF	VMAF 변화
360p	862k	490.1k	-43.1%	75.55	73.88	-1.67
720p	2215k	1682.5k	-24.0%	90.59	90.13	-0.46
1080p	4165k	4171.3k	+0.15%	94.46	94.65	+0.19

Meridian은 세 해상도 모두 CRF18이 선택되었습니다. 360p와 720p에서는 bitrate가 줄었지만, 1080p는 baseline과 거의 같은 수준으로 유지되었습니다.
즉 Meridian은 “무조건 크게 줄일 수 있는 영상”은 아니었습니다. 낮은 해상도에서는 절감 여지가 있었지만, 고화질 구간에서는 기존 ladder가 이미 적정에 가까웠습니다.

6-4. Tears 결과

Tears는 고복잡도 영상으로, 전체 bitrate가 오히려 증가했습니다.

해상도	Baseline bitrate	PTE bitrate	변화율	Baseline VMAF	PTE VMAF	VMAF 변화
360p	960k	1182k	+23.1%	67.71	73.33	+5.62
720p	2645k	3467k	+31.1%	90.69	93.31	+2.62
1080p	5157k	4704k	-8.8%	95.52	95.40	-0.12

ears는 360p와 720p에서 bitrate가 증가했습니다. 이는 실패라기보다, 기존 고정 ladder가 이 영상의 낮은 해상도 품질을 충분히 방어하지 못했다는 의미입니다.
반면 1080p에서는 bitrate를 약 8.8% 줄이면서도 VMAF는 거의 유지되며, 해상도별로 판단이 달랐습니다.

6-5. 대표 구간은 신뢰성이 있었는가?

앞선 단계에서 전체 영상을 전부 후보 탐색하지 않고, 대표 구간 5개로 후보를 고른 뒤 최종 ladder만 전체 영상으로 검증했습니다. 이에 따라 대표 구간의 신뢰성도 검증할 필요가 있었습니다.

영상	해상도	대표 구간 예측 VMAF	전체 영상 VMAF	차이
BBB	360p	60.59	62.09	+1.50
	720p	90.38	88.68	-1.70
	1080p	95.76	95.17	-0.59
Meridian	360p	74.40	73.88	-0.52
	720p	89.93	90.13	+0.20
	1080p	94.17	94.65	+0.48
Tears	360p	72.36	73.33	+0.97
	720p	93.72	93.31	-0.41
	1080p	95.56	95.40	-0.16

결과는 대체로 신뢰성 있는 대표 구간임이 나타났습니다. 모든 차이가 대략 ±1.7점 안에 들어왔고, 대표 구간 기반의 판단이 전체 영상에서도 크게 벗어나지 않았습니다.

y=x 그래프를 예측 = 실측으로 두고 점을 찍어 확인해보면 크게 벗어나지 않는 것을 확인할 수 있습니다.

7. 마무리

영상 처리를 접해본 적이 없어서 팀 프로젝트 기간 동안 회의를 정말 많이 했었는데, 기획을 좀 줄이고 아예 이러한 부분을 팀원들과 함께 더 깊게 공부해봤으면 좋았겠다는 아쉬움이 있습니다.

영상하면 역시 넷플릭스가 떠올라서 기술 블로그도 종종 봤었는데, 하나같이 다 거대하고 어려워서 프로젝트에 적용하기엔 어려웠습니다. 참고한 글도 처음엔 난해하고 어려웠는데, 지하철 오가며 여러 번 반복해서 보니까 좀 익숙해지는 것 같았습니다.

테스트를 정말 많이 했습니다. 부하 테스트나 쿼리 돌려보는 건 많이 해보기도 했고 익숙했는데, 이렇게 직접 가설을 세우고 뽑아낼 수치를 정하고, 비교군을 설정하여 계속해서 숫자를 만들어가는 건 조금 낯설었습니다. 하지만, 이 과정에서 작업의 목적과 제가 확인하고 싶은 게 무엇인지 여러 번 생각해 볼 수 있어 방향을 잃지 않았던 것 같습니다.

역시나 실제 결과로 확인하는 게 정말정말 중요한 것을 느꼈습니다!

참고 자료: https://netflixtechblog.com/per-title-encode-optimization-7e99442b62a2

Per-Title Encode Optimization

delivering the same or better experience while using less bandwidth

netflixtechblog.com

영상은 어떻게 전달되는가

phonil — Tue, 9 Jun 2026 22:57:05 +0900

0. 개요

영상 업로드, 트랜스코딩, 스트리밍 가능한 OTT 프로젝트를 진행하면서 영상 처리에 사용되는 개념들을 처음 접했습니다. 익숙하지 않았고 비슷한 개념들이 많았기 때문에 뭐가 뭔지 파악하는 것부터 난관이었습니다. 이번 글에서는 아키텍처나 세세한 설정, 개념이 아닌 영상 처리에 있어 필수적인 기본 개념들을 소개하는 느낌으로 정리해보았습니다.

트랜스코딩이나 영상 처리 개발 관련 개념을 빠르게 보고 싶으신 분은 '2-3 코덱과 컨테이너’ 부분부터 보시면 됩니다!

1. 동영상이란

동영상은 여러 이미지(영상)들과 오디오, 자막 등 부가 데이터의 조합입니다. 이렇게 생각하면 모호하게 느껴지니 이미지부터 하나씩 알아보고 이들을 조합해보겠습니다.

1-1. 프레임과 비트레이트

프레임

동영상에서는 사진을 빠르게 이어 붙여 사람에게 움직이는 것처럼 보이게 합니다. 우리 눈은 1초에 24장 이상의 그림이 바뀌면 움직이는 것으로 인식한다고 합니다.
학창 시절에 책 모서리에 그림을 그려놓고 빠르게 파바박 넘겼을 때 움직이는 것처럼 보였던 것과 같습니다.

이때, 한 장의 정지 영상을 프레임(Frame)이라고 하며, 영상 1초에 들어가는 프레임의 수를 프레임레이트(FPS, Frames Per Second)라고 합니다. 게임에서 네트워크가 느릴 때 fps를 보는데, 바로 이것입니다.

비트레이트

비트레이트는 1초당 사용하는 데이터의 양입니다. 단위는 bps(bits per second)를 사용하며, 영상에서는 주로 Kbps나 Mbps 단위가 쓰입니다. 영상 품질과 파일 크기를 결정하는 요소로, 비트레이트가 높을수록 빠른 것이 아니라 고품질이며 파일 용량이 큽니다.

비트레이트가 높을수록 영상을 표현하기 위한 데이터가 더 많이 필요합니다. 하지만, 그만큼 초당 전송해야 할 데이터의 양이 많아지기 때문에 네트워크 속도가 빨라야 합니다. 느린 네트워크 환경에서 높은 비트레이트의 영상을 재생하면 데이터를 충분히 받지 못하게 되어 버퍼링이 발생하게 됩니다.

1-2. 픽셀과 해상도

한 장의 이미지인 프레임은 다시 아주 작은 블럭들로 이루어져 있으며,이 블럭들을 픽셀(Pixel)이라고 합니다.

여기서 각 픽셀은 색을 나타내고, 한 프레임에 들어갈 수 있는 픽셀 수가 해상도입니다.

색을 저장하는 방법

저에겐 미술이 너무 어렵지만, 색을 나타내는 가장 직관적인 방식은 빛의 삼원색을 섞는 방식이라고 배웠던 기억이 있습니다. RGB를 얼마씩 섞느냐로 모든 색을 만들 수 있습니다. 각 색마다 1바이트씩 사용하며, 픽셀 1개당 3바이트를 차지합니다.

하지만, 픽셀 하나가 3byte를 차지하게 되므로 영상이 길어질수록 용량이 어마어마하게 늘어날 수 있습니다.

픽셀당 3바이트로 FHD 영상 1시간 용량을 계산해 보면 아래와 같습니다.

 픽셀 수      : 1920 × 1080  ≈ 207만 픽셀
 픽셀당 색    : 3 byte (RGB)
 프레임 1장   : 207만 × 3   ≈ 6.2 MB
 1초(30fps)   : 6.2 MB × 30 ≈ 187 MB
 1시간        : 187 MB × 3600 ≈ 660 GB

이렇게 데이터를 있는 그대로 저장하는 것이 어렵기 때문에 영상에서는 RGB 대신 YUV와 크로마 서브샘플링 방식을 사용해서 크기를 줄입니다.

YUV와 크로마 서브샘플링

YUV는 밝기(Y)와 색차(U, V)를 분리해서 표현합니다.

사람 눈은 밝기 변화에는 민감하지만 색 변화에는 둔감합니다. 그래서 밝기는 꼼꼼히, 색은 대충 저장해도 사람은 차이를 거의 못 느낍니다. 문제는 RGB는 색과 밝기가 한 덩어리로 섞여 있어 ‘색만 골라서 줄이는 것’이 불가능하다는 점입니다.

그래서 먼저 YUV로 밝기와 색을 분리해 둡니다. 이렇게 떼어 놓으면 밝기(Y)는 그대로 두고 색(U, V)만 줄일 수 있습니다.

이때, ‘색 정보만 줄이는 기술’을 크로마 서브샘플링이라고 합니다. 주로 색상 정보를 2×2 픽셀당 1개씩만 저장하는 4:2:0 비율을 사용합니다.(해상도가 짝수인 이유)

크로마 서브샘플링

2. 압축: 줄이고 표현하는 방법

압축의 본질은 ‘똑같거나, 사람이 못 느끼는 정보를 반복 저장하지 않는 것’입니다. 주로 용량을 줄이기 위한 목적으로 사용됩니다.

손실 압축과 무손실 압축이 있는데, 영상은 대부분 손실 압축이 사용됩니다. 화질을 약간 희생해서 용량을 많이 줄이기 위함입니다. 따라서 여러 번 반복되면 화질이 저하되어 화질구지가 될 수 있습니다.

2-1. 네 가지 압축 관점

구분	의미	예시
공간적 압축	한 프레임 안의 중복 제거	하늘처럼 비슷한 색 영역 압축
시간적 압축	프레임 사이의 중복 제거	이전 프레임과 달라진 부분만 저장
지각적 압축	사람이 잘 못 느끼는 정보 줄이기	색 정보 일부 줄이기, 미세한 디테일 제거
엔트로피 압축	남은 데이터를 더 짧은 코드로 표현 (표현 자체를 더 효율적으로 줄임)	자주 나오는 값은 짧게, 드문 값은 길게 저장

사진과 다르게 영상은 시간이라는 축이 존재하기 때문에 시간적 압축을 통해 사진 묶음보다 훨씬 효율적으로 압축될 수 있습니다.

오디오 압축(AAC·MP3·Opus)도 똑같이 사람 귀의 약점을 이용합니다. 큰 소리에 묻혀 안 들리는 작은 소리, 사람이 못 듣는 주파수 대역을 버리는 방식입니다.(심리음향 압축). '압축 == 사람 지각의 약점을 이용한다.'는 원리는 영상의 색(눈)이든 오디오(귀)든 동일하게 적용됩니다.

2-2. I·P·B프레임과 GOP

영상에는 프레임이 여러 장 존재한다는 특성을 살려 프레임을 세 역할로 나누어 시간적 압축을 활용할 수 있습니다.

구분	의미	예시
I 프레임	- 다른 프레임을 참조하지 않고 자기 자신만으로 복원 가능한 프레임 - 용량은 크지만 탐색/재생 시작 기준이 됨	장면의 시작점, 탐색 기준점
P 프레임	이전 프레임을 참고해서 변화한 부분 중심으로 저장하는 프레임	사람이 조금 움직인 부분만 저장
B 프레임	이전 프레임과 이후 프레임을 모두 참고해서 더 효율적으로 압축하는 프레임	움직임이 중간에 있는 프레임
GOP (Group Of Pictures)	- 하나의 I 프레임을 기준으로 이어지는 프레임 묶음 - 보통 다음 I 프레임 전까지를 하나의 GOP로 봄	I B B P B B P 한 묶음

GOP가 길면 I 프레임이 적기 때문에 용량은 줄지만 중간 탐색·오류 복원이 불리하고, 짧으면 용량이 늘어납니다. 또한, I 프레임의 위치는 ABR이 화질을 바꿀 때 중요한 조건으로 사용됩니다.

2-3. 코덱과 컨테이너

코덱 (Codec)

앞에서 계속 살펴본 것처럼 동영상 원본의 크기는 너무 거대합니다. 그래서 저장하거나 전송하기 좋게 줄여 사용하는데, 이때 어떤 방식으로 줄이고 어떤 방식으로 다시 풀지 정한 규칙이 코덱입니다.

덱은 Coder와 Decoder의 합성어로, 영상을 압축하고 다시 복원하기 위한 규칙입니다.

H.264 같은 영상 코덱은 공간적 중복, 시간적 중복을 줄이고 I·P·B 프레임 구조, 예측, 변환, 양자화, 엔트로피 부호화 같은 과정을 통해 데이터를 줄입니다. 보통 YUV 계열 표현과 크로마 서브샘플링을 함께 활용해 사람이 덜 민감한 색 정보도 효율적으로 저장합니다.

대표적인 비디오 코덱들은 아래와 같습니다.

코덱	특징	같은 화질일 때 용량
H.264 (AVC)	가장 널리 쓰임, 호환성 최고. 사실상 기본값	기준 (100%)
H.265 (HEVC)	H.264의 약 절반 용량, 라이선스 비용 이슈	~50%
VP9	구글, 로열티 무료	~50%
AV1	차세대, 무료·고압축. 인코딩 매우 느림	~30~40%

코덱은 알고리즘은 호환성, 용량, 인코딩/디코딩 속도 등 용도에 따라 선택해야 합니다.

컨테이너

영상 파일은 컨테이너(포장 상자) + 코덱(압축 방식)으로 이뤄집니다.
코덱은 “어떻게 압축할지”만 정하기 때문에 압축된 영상·오디오·자막을 하나로 묶는 포장 상자가 따로 필요합니다.

컨테이너는 비디오, 오디오, 자막, 메타데이터를 하나의 파일에 담는 규격입니다.

같은 .mp4 확장자라도 내부 코덱이 다를 수 있고, 같은 H.264 코덱이라도 MP4, MKV, TS 등 다른 컨테이너에 담길 수 있습니다.

여기서 비디오·오디오 등 여러 트랙을 하나의 컨테이너로 묶는 행위를 먹싱(Muxing)이라 합니다.

컨테이너	특징
MP4	호환성 최고, 웹·모바일 표준
MKV	다중 트랙·자막 자유로움
MOV	애플이 개발한 멀티미디어 비디오 컨테이너 포맷
TS	방송·스트리밍 전송용

코덱을 모르면 파일을 열어볼 수 없기 때문에 같은 .mp4라도 안에 든 코덱이 다르면 재생이 안 될 수 있습니다.

3. 인코딩, 디코딩 그리고 트랜스코딩

3-1. 인코딩과 디코딩

영상에서 인코딩(Encoding)은 원본 영상 데이터를 코덱 규칙에 따라 압축하는 과정입니다.

인코딩은 연산량이 매우 많아서 오래 걸리고 CPU를 많이 사용합니다. 같은 코덱이라도 '얼마나 공들여 압축하느냐'에 따라 결과가 달라지는데, 이때 쓰이는 요소들을 조절하여 영상의 품질과 속도, 용량을 결정할 수 있습니다.

앞에서 살펴본 압축 방식들이 인코딩에 포함됩니다.

1) RGB → YUV + 크로마 서브샘플링 (지각적 중복)

2) 프레임을 I·P·B로 나눠 차이만 (시간적 중복)

3) 한 프레임 안 비슷한 영역 요약 (공간적 중복)

디코딩(Decoding)은 압축된 영상을 풀어 화면에 그릴 픽셀 프레임으로 되돌리는 과정입니다.

영상 재생기는 그 코덱의 디코더를 반드시 가져야 합니다. 없으면 소리는 나는데 화면이 안 나오거나 재생 불가 현상이 발생할 수 있습니다. 바로 이 문제 때문에 트랜스코딩이 필요해집니다.

3-2. 트랜스코딩

트랜스코딩은 이미 인코딩된 영상을 디코딩 후 다른 코덱/포맷/해상도/비트레이트로 변환하여 다시 인코딩하는 작업입니다. 스트리밍 환경에서 꼭 필요한 과정으로, 다양한 환경의 사용자가 영상 시청을 할 수 있도록 돕습니다.

트랜스코딩은 이미 압축된 것을 풀어서 또 다른 압축본으로 만드는데, 이미 손실된 걸 또 손실 압축하므로 화질이 더 떨어질 수 있습니다(세대 손실).

FFmpeg

트랜스코딩(디코딩 → 재인코딩)을 실제 코드로 실행할 때 사실상 표준처럼 쓰이는 도구가 FFmpeg입니다. 오픈소스 커맨드라인 도구이고 거의 모든 코덱·컨테이너를 다룹니다. 유튜브·넷플릭스를 비롯한 수많은 서비스의 내부 파이프라인에 들어가 있습니다.

아래는 input.mp4 파일을 1080p, 영상은 H.264, 오디오는 AAC로 트랜스코딩하여 output_1080p.mp4 파일로 변환하는 명령어입니다.

ffmpeg -i input.mp4 -vf scale=-2:1080 -c:v libx264 -c:a aac output_1080p.mp4

FFmpeg은 필터, 고급 기술, 하드웨어 가속 등 여러 기능을 제공합니다!

4. 전달: 스트리밍

영상을 시청자에게 보내는 방식은 파일을 건네줄 것인지 흘려보낼 것인지에 따라 다운로드와 스트리밍 두 가지로 나눌 수 있습니다.

4-1. 다운로드와 스트리밍

다운로드는 영상 파일 하나를 통째로 보냅니다. 시청자 받은 파일은 내 것이 되고, 다 받아야 온전히 쓸 수 있습니다. 그런데 영상은 파일이 크다 보니 다운로드 안에서도 다 받고 나서 재생하는 방식과 받는 중에 앞부분부터 재생하는 방식(Progressive Download)으로 갈립니다.

그럼에도 영상을 받으면서 재생하긴 하지만 결국 하나의 통파일을 처음부터 순서대로 받는 것이라 중간으로 건너뛰기(seek)도 불편하고 화질을 바꿀 수 없습니다. 스트리밍을 통해 이 문제를 해결할 수 있습니다.

스트리밍은 영상 재생을 위해 전체 파일을 보내지 말고, 하나의 영상 파일을 잘게 쪼개 필요한 만큼만 주는 방식입니다. 스트리밍을 위해서는 조각들에 대한 정보가 담긴 플레이리스트를 먼저 다운로드 받아야 합니다. 이를 바탕으로 작게 나눠진 영상 조각들 중에서 보고싶은 지점을 쉽게 찾아 볼 수 있고, 중간에 화질을 마음대로 변경할 수 있습니다.

4-2. 세그먼트와 버퍼링

현대 스트리밍은 영상을 작은 조각(Segment)으로 쪼갭니다. 보통 2~10초로 쪼개며, 6초 단위가 국룰이라고 합니다.

영상을 여러 조각으로 자르면 전체 영상을 다 받지 않아도 첫 조각부터 바로 재생할 수 있으며, 조각마다 다른 화질로 받을 수 있습니다. 물론 이를 위해 트랜스코딩 과정에서 미리 같은 영상을 화질별로 여러 개 만들어두어야 합니다.

쾌적한 시청을 위해 플레이어는 영상을 시청하는 동안 뒷 조각을 미리 받아 버퍼에 쌓아둡니다. 네트워크가 느려지더라도 버퍼에 다음 세그먼트가 존재한다면 기다릴 필요 없이 바로 재생이 가능하지만, 만약 버퍼에 다음 영상이 존재하지 않는다면 버퍼링이 발생합니다.

4-3. 매니페스트와 ABR

같은 영상을 4K·1080p·720p·480p로 트랜스코딩해 두고, 각각을 조각으로 쪼개어 저장합니다. 그리고 '어떤 화질의, 몇 번째 조각이, 어디 있는지' 적어둔 목차 파일을 만드는데 이것이 매니페스트(Manifest)입니다.

매니페스트 파일을 바탕으로 네트워크 상태에 따라 조각 단위로 화질을 자동 전환하는 것이 ABR(Adaptive Bitrate)입니다.

자동 화질 전환 기능을 효율적으로 사용하려면 화질이 골고루 준비되어 있어야 합니다. 고화질 영상만 제공한다면 버퍼링이 많이 발생할 것이고, 저화질 영상만 제공한다면 불필요하게 낮은 화질만 제공되기 때문입니다.

ABR 알고리즘은 여러 가지가 존재한다고 합니다.

Throughput 기반 (대역폭 측정)
- 최근 N개 세그먼트 다운로드 속도 측정
- 간단하고, 반응이 빠름 / 네트워크 변동에 민감하여 화질 변경이 잦음

Buffer 기반
- 버퍼에 쌓인 재생 시간을 모니터링
- 안정적이며, 버퍼링 방지에 좋음 / 반응이 느리고, 초기화질 결정에 어려움이 존재함

하이브리드 (Throughput + Buffer)
- 실제로 많은 플레이어들이 사용한다고 함

4-4. 스트리밍 프로토콜

스트리밍을 위한 별도 프로토콜이 존재하며, 대표적인 스트리밍 방식으로는 HLS와 MPEG-DASH가 있습니다. 두 방식 모두 기본 구조는 비슷합니다. 긴 영상을 몇 초 단위의 세그먼트로 나누고, 이 세그먼트들의 위치와 재생 순서를 적어둔 재생목록 또는 매니페스트 파일을 함께 제공합니다. 이 구조를 바탕으로 네트워크 상황에 따라 화질을 바꿀 수 있는 ABR이 가능하게 됩니다.

HLS와 DASH

서버에서 다수 시청자에게 영상을 배포하는 HTTP 기반 프로토콜의 양대 표준이 HLS와 DASH입니다. 조각(세그먼트)을 평범한 HTTP 파일로 주고받는 방식 덕분에 일반 웹서버·CDN에 사용되며 사실상 표준이 됐습니다.

	HLS (HTTP Live Streaming)	DASH (Dynamic Adaptive Streaming over HTTP)
만든 곳	애플	국제 표준(MPEG)
매니페스트	- 플레이리스트 - .m3u8	- MPD - .mpd
조각	- 전통적 .ts - 현대 .mp4(fMP4)	.mp4(fMP4)
코덱 제약	비교적 한정적	코덱 무관(유연)
호환성	애플 생태계 필수 지원	웹·안드로이드 강세

예전에는 구분을 해서 사용했지만, 각각의 장단점이 존재하기 때문에 요즘은 CMAF를 사용하는 경우도 종종 있다고 합니다. CMAF는 HLS와 DASH 양쪽에서 사용할 수 있는 세그먼트 포맷으로 활용되어 있습니다. 공용 .mp4(FMP4)을 하나 만들어두고, HLS용 m3u8과 DASH용 mpd가 가리키도록 합니다.

플레이리스트

대부분의 동영상 플랫폼에서 사용하는 HLS는 2단 구조로 되어 있습니다. 먼저 화질 목록을 담은 마스터 플레이리스트가 있고, 각 화질마다 그 화질의 조각 목록을 담은 미디어 플레이리스트가 따로 있습니다.

이 플레이리스트를 바탕으로 아래와 같이 영상 재생이 진행됩니다.

마스터 플레이리스트 파일(m3u8)을 다운로드하여 재생 가능한 화질 확인
네트워크 상황에 맞는 미디어 플레이리스트 선택
선택한 미디어 플레이리스트를 읽으며 세그먼트를 다운받으며 재생
재생하면서 네트워크 상황을 측정하여 상황에 맞는 화질로 자동 변경

키프레임 정렬

화질을 변경하기 위해 조각을 바꿔 끼우려면 그 조각이 혼자 완전하게 시작될 수 있어야 합니다. 조각이 이전 조각을 참고하는 P·B 프레임으로 시작하면 화질을 바꾼 순간 기준이 사라져 화면이 깨지기 때문에 모든 조각은 I 프레임으로 시작하도록 만들고, 화질이 달라도 조각 경계를 똑같이 맞춥니다. 이를 키프레임 정렬이라고 합니다.

결국, 스트리밍 조각 길이와 GOP 길이가 맞아야 ABR이 정상적으로 동작합니다. 만약 둘이 일치하지 않는다면 다른 조각이 필요하게 될 수 있습니다.

라이브 스트리밍의 경우

VOD는 미리 다 처리해두므로 영상 재생 시 별도 수집 과정이 필요하지 않습니다. 하지만, 라이브의 경우 실시간으로 수집 구간 작업이 필요합니다. 이 구간은 '한 명(방송자)이 서버로 끊김 없이 올린다'가 목표이기 때문에 배포(HLS/DASH)와는 다른 프로토콜을 사용합니다.

라이브 파이프라인은 보통 방송자가 RTMP(또는 SRT)로 올리면 서버가 실시간 트랜스코딩·세그먼트화해서 HLS/DASH로 재생할 수 있도록 제공합니다. 영상을 올리고 내리는 프로토콜이 다르게 사용됩니다.

프로토콜	구간	특징
RTMP	수집	- 오래된 사실상 표준 - 지연이 낮고 OBS 등 송출 도구 호환성이 좋다. 단 옛 기술이라 시청자 배포용으로는 부적합
SRT	수집	- RTMP의 현대적 대안 - 불안정하거나 먼 네트워크에서도 손실을 복구하며 안정적으로 전송
WebRTC	수집·배포 양쪽	- 초저지연(1초 미만) - 양방향 실시간 상호작용 용도
HLS / DASH	배포	- HTTP 기반, 확장성 최고 - 단, 조각을 모으느라 지연 발생

5. 영상 품질은 어떻게 알까

5-1. 영상 품질 지표

영상의 품질을 알아보는 가장 쉬운 방법은 사람이 직접 눈과 귀로 확인하는 것입니다. 하지만, 세세한 차이까지 다 알 수 없고 모든 영상을 사람이 검토하는 것은 매우 오랜 시간이 걸립니다. 또한, 일정 품질 목표가 있다고 한들 '봐줄 만한가'가 모호합니다.

화질을 수치화하는 방식이 있는데, 크게 세 가지가 사용됩니다.

	PSNR (픽셀 오차)	SSIM (구조적 유사도)	VMAF (사람 체감 예측)
세대	1세대	2세대	3세대 (현재 표준)
무엇을 재나	픽셀이 얼마나 다른가	구조(윤곽·명암 패턴)가 얼마나 비슷한가	사람이 몇 점이라 느낄까
원리	원본↔압축본의 수학적 픽셀 오차	사람은 개별 픽셀이 아닌 "전체 형태"로 인식한다는 점 활용	사람이 직접 매긴 평가를 학습해 예측 (여러 지표를 fusion)
결과 형태	dB (높을수록 좋음)	0~1 (1에 가까울수록 좋음)	0~100 점수
사람 체감과의 일치	낮음 (괴리 큼)	중간	높음
약점	픽셀 오차 작아도 눈엔 거슬리거나 그 반대	픽셀보단 낫지만 여전히 체감과 거리	결국 예측값 (진짜 기준은 사람 평가 MOS)

낮은 세대일수록 계산이 빠르고 단순하다는 장점이 있지만, 그 수치가 영상 품질을 대표하기 부정확하다는 단점이 있습니다. 따라서 실제 사용할 때에는 전체 영상에 대한 검수는 PSNR과 SSIM으로 빠르게 처리하고, 최종 품질 판단은 VMAF로 하는 방식으로 섞기도 한다고 합니다.

VMAF가 있으면 화질을 점수로 관리할 수 있습니다. 이걸 활용하면 'VMAF 93점을 유지하면서 비트레이트는 최소로'같은 목표를 세우고 최적화를 진행할 수 있게 됩니다.

참고로 VMAF 6점 차이는 인간의 시각으로 인지할 수 있는 최소 단위인 1JND (Just Noticeable Difference)라고 한다고 하네요!!

5-2. 영상 품질 최적점 찾기

영상 품질과 용량은 반비례합니다. 용량이 커지면 품질이 높아지고, 그 반대도 마찬가지이기 때문에 품질과 용량의 균형점을 잘 잡아야 합니다. 이를 위해 CRF라는 방식을 사용하여 품질을 기준으로 용량을 결정해 압축할 수 있습니다. CRF 비트레이트가 아니라 품질을 기준으로 인코딩합니다. CRF 말고도 CBR, VBR 등 방식이 존재하는데, 간단하게 아래처럼 정리할 수 있습니다.

CBR → 비트레이트 고정
VBR → 평균 비트레이트 중심
CRF → 품질 기준 고정

예를 들어, CRF 값을 하나 정하면 인코더는 비슷한 체감 품질을 유지하기 위해 필요한 만큼 비트를 사용합니다.

CRF는 파일 크기를 정하는 방식이 아니라 원하는 품질을 정하는 방식입니다. 같은 CRF 값이라도 토크쇼는 파일이 작게 나오고, 스포츠 영상은 훨씬 크게 나올 수 있습니다. 품질을 유지하기 위해 필요한 데이터 양이 다르기 때문입니다.

그렇다면 적절한 CRF 값을 설정해야 하는데, 여기서 VMAF같은 품질 지표가 등장합니다. 같은 영상을 여러 CRF 값으로 인코딩한 뒤 품질을 측정해서 비교해볼 수 있습니다.

CRF 18 → 파일 큼, 화질 높음
CRF 23 → 균형점
CRF 28 → 파일 작음, 화질 낮음

그리고 각 결과의 비트레이트와 VMAF를 비교합니다.

CRF 값 변경 → 인코딩 → 비트레이트 측정 → VMAF 측정 → 품질 대비 효율 비교

이 과정을 통해 어느 지점부터 화질 차이가 거의 느껴지지 않는지, 어느 지점부터 비트를 더 써도 품질 향상이 크지 않은지를 확인할 수 있습니다.

CRF와 VMAF가 헷갈릴 수 있는데, CRF는 인코딩 설정값 / VMAF는 품질 측정 점수라는 차이가 있습니다.

6. 마무리

최대한 흐름 중심으로 내용을 연결시키려고 했는데, 막상 작성해보니 조금 장황한 것 같아서 슬픕니다.. 다소 깊어진 내용이나 영상 트랜스코딩에는 불필요했던 개념들이 들어가기도 했네요. 그래도 영상 처리를 위한 기초 개념을 전체적으로 한 번 훑어본다는 느낌으로 읽어보면 좋을 것 같습니다.

처음부터 모든 개념이 필요하지는 않지만, 기본적인 영상 트랜스코딩 작업을 수행하면서 '기본적으로 올바른' 결과물을 내는 것만으로도 상당히 많은 설정이 들어갑니다. 이들을 모르고 사용할 수 있는데, 그렇다면 나중에 품질을 측정하거나 고도화를 진행할 때 기본적인 곳에서부터 문제가 발생할 수 있습니다.

실제로 잘 모른 채로 영상 트랜스코딩을 완료됐지만, 조금씩 아는 것이 생기면서 저는 제대로 한 것이 아니었음을 깨달았던 기억이 있습니다. 그래서 기본 개념을 익히고 FFmpeg 명령어들이 영상에 어떤 영향을 미치는지 체감할 필요가 있겠다고 느껴서 글을 작성했습니다.

[O+T] 영상 품질 기반 개선기 (1. 올바른 영상 변환과 품질 측정 방식)

phonil — Sat, 16 May 2026 22:01:21 +0900

영상 트랜스코딩 - VMAF 품질 측정 과정을 거치며 마주한 문제를 해결하는 과정에 대해 적어놓은 글입니다. 문제 해결 중심으로 글이 전개되므로 영상에서 사용하는 개념에 대한 설명이 적게 들어가 있습니다!

2편: https://yestomo.tistory.com/27

[O+T] 영상 품질 측정하기 (2. Per-Title-Encoding 적용)

1편: https://yestomo.tistory.com/25 [O+T]: 영상 품질 측정하기 (1. 올바른 영상 변환과 품질 측정)영상 트랜스코딩 - VMAF 품질 측정 과정을 거치며 마주한 문제를 해결하는 과정에 대해 적어놓은 글입니다.

yestomo.tistory.com

0. 개요

영상 업로드와 스트리밍을 제공하는 OTT 서비스 프로젝트에서 트랜스코딩 서버를 개발했습니다. FFmpeg으로 HLS 변환을 완료하면 360p, 720p, 1080p 결과물은 생성되지만, 막상 해당 영상이 '잘 변환되었는지' 판단하기는 어려웠습니다.

눈으로 봤을 때 큰 차이를 느끼기 어려웠고, 모든 영상을 하나하나 사람이 볼 수도 없었습니다. 영상 원본과 트랜스코딩 후 변환된 영상을 수치로 비교할 수 있으면 좋겠다고 생각했고 이를 기반으로 내가 정말 잘 변환했는지, 더 좋은 방법이 있는지 알 수 있을 것이라고 생각했습니다.

이번 글에서는 트랜스코딩 결과물에 대한 최적화(2편, Per-Title-Encoding) 전 영상 변환 시 기본적으로 적용해야 할 요소들을 다룹니다. 품질을 측정하며 이상한 숫자가 발견되면 원인을 찾고 정말 문제인지 알아보며 진행했습니다.

1. 영상 품질 측정

1-1.지표 선택

화질을 수치화하는 방식으로 보통 세 가지가 사용됩니다.

	PSNR (픽셀 오차)	SSIM (구조적 유사도)	VMAF (사람 체감 예측)
세대	1세대	2세대	3세대
무엇을 재나	픽셀이 얼마나 다른가	구조(윤곽·명암 패턴)가 얼마나 비슷한가	사람이 몇 점이라 느낄까
원리	원본 ↔ 압축본의 수학적 픽셀 오차	사람은 개별 픽셀이 아닌 '전체 형태'로 인식한다는 점 활용	사람이 직접 매긴 평가를 학습해 예측 (여러 지표를 fusion)
결과 형태	dB (높을수록 좋음)	0~1 (1에 가까울수록 좋음)	0~100 점수
사람 체감과의 일치	낮음 (괴리 큼)	중간	높음
약점	픽셀 오차 작아도 눈엔 거슬리거나 그 반대	픽셀보단 낫지만 여전히 체감과 거리있음	결국 예측값임

낮은 세대일수록 계산이 빠르고 단순하다는 장점이 있지만, 그 수치가 영상 품질을 대표하기 부정확하다는 단점이 있습니다. 이번 작업의 목표는 그저 픽셀 차이를 줄이는 것이 아니라 트랜스코딩 후 사용자가 체감하는 품질을 확인하는 것이기 때문에 VMAF을 선택했습니다.

추가로 실제로는 전체 영상에 대한 검수는 PSNR과 SSIM으로 빠르게 처리하고, 최종 품질 판단은 VMAF로 하는 방식으로 섞기도 한다고 합니다.

1-2. 영상 고르기

품질 측정 대상은 하나의 영상만 사용하지 않기로 했습니다. 영상마다 움직임의 양, 장면 전환 빈도, 질감, 조명, FPS 특성이 다르기 때문에 한 영상에서 좋은 결과가 나왔다고 해서 기존 트랜스코딩 로직이 항상 안정적이라고 보기 어렵기 때문입니다.

저는 저/중/고 복잡도로 나눠 서로 다른 특성의 영상을 세 개 준비했습니다. 움직임은 적은 애니메이션을 복잡도가 낮은 영상으로, 액션이 많은 실사 CG 영상을 고복잡도 영상으로 골랐습니다.

큰 토끼 / 미국 / 멋있는 아저씨

Big Buck Bunny (낮은 복잡도): 밝은 애니메이션 영상
Meridian (중간 복잡도): 높은 FPS 특성을 가진 영상
Tears of Steel (높은 복잡도): 장면 전환, 실사, 어두운 장면 등 압축 난도가 높은 영상

2. 기존 트랜스코딩 방식으로 vmaf 측정

먼저 기존 트랜스코딩 로직으로 생성된 HLS 결과물을 기준으로 VMAF를 측정했습니다. 측정 대상은 Big Buck Bunny, Meridian, Tears of Steel 세 영상이었고, 각 영상마다 360p, 720p, 1080p 결과물을 비교했습니다.

2-1. 측정 방식

원본(4K)과 변환본의 해상도가 다르기 때문에 원본을 HLS 결과물의 실제 해상도로 낮춘 뒤 비교했습니다. 예를 들어 720p 결과물을 평가할 때는 원본도 720p 기준으로 맞춘 뒤 VMAF를 계산했습니다.

넷플릭스는 VMAF 측정의 국룰?로 HLS 결과물을 원본 해상도에 맞추는 Upscale 방식을 사용하라고 합니다. 하지만, 지금 저의 측정 의도는 최종 시청 품질을 판단하기 위한 목적이 아닌 현재 트랜스코딩 결과물의 압축 품질과 측정 과정에서 발생할 수 있는 문제 신호를 확인하기 위한 진단용 측정이기 때문에 스케일로 인한 점수 저하는 배제하고자 Downscale로 측정했습니다. 이는 같은 해상도 안에서 '현재 인코딩 결과가 얼마나 원본 정보를 유지하는가'를 진단하기 위함입니다

2-2. 측정 결과

저/중 복잡도 영상은 VMAF 점수가 정상으로 나타났지만, 고복잡도 영상은 점수가 이상하리만치 낮았습니다. 하위 5% 구간의 점수가 0이 나타난 것을 보아 상당 구간에서 이상치가 발생한 것임을 알 수 있었습니다.

각 영상의 평균 VMAF 점수를 표로 보면 아래와 같습니다.

영상	360p	720p	1080p	해석
Big Buck Bunny	96.43	96.92	97.17	정상
Meridian	95.68	95.07	94.52	정상
Tears of Steel	49.84	40.23	35.55	비정상

문제를 두 갈래로 나누기

결과만 보면 고복잡도 영상의 트랜스코딩 품질이 크게 낮다고 판단할 수도 있지만, 품질 측정 과정에서 오류가 발생했을 수도 있습니다. VMAF는 원본과 변환본을 비교하는 방식이기 때문에, 비교 조건이 어긋나도 점수가 낮게 나올 수 있기 때문입니다.

따라서 문제를 두 갈래로 나누어 보기로 했습니다.

첫 번째는 트랜스코딩 산출물 자체의 문제입니다. 트랜스코딩 과정에서 적절한 보정이 이뤄지지 않아 segment와 keyframe 구조가 불안정하다면 VMAF 이전에 결과물 자체를 먼저 보완해야 합니다.

두 번째는 VMAF 측정 방식의 문제입니다. timestamp, frame alignment, FPS 처리 방식이 맞지 않으면 실제 화질이 나쁘지 않아도 서로 다른 프레임끼리 비교되어 점수가 낮게 나올 수 있습니다.

실제 화질이 나쁜 것인지, 아니면 비교 조건이 잘못된 것인지를 분리해서 '트랜스코딩 변환'과 'VMAF 측정' 과정에서의 오류로 나눠서 살펴보았습니다.

먼저 HLS 산출물에서 확인된 문제를 정리하고, 그 다음 VMAF 측정 방식에서 점수를 왜곡할 수 있는 요소를 분리해 확인했습니다.

3. 트랜스코딩 산출물 문제

앞서 분리한 두 문제는 완전하게 떨어지지 않습니다. 특히, 고복잡도 영상의 낮은 점수에는 측정 왜곡과 산출물 문제가 섞여 있었습니다. 그래서 먼저 점수가 몇 점이든 상관없이 결과물(HLS) 자체에서 객관적으로 확인되는 구조적 결함만 먼저 정리하기로 했습니다. '그래서 실제 화질이 낮은가?'라는 판단은 측정 왜곡을 걷어낸 뒤 진행해야 또다른 오류로 인해 엉키는 문제가 없기 때문입니다.

즉, 산출물 문제는 '결과물이 원래부터 가지고 있던, 측정과 무관한 문제'입니다.

3-1. master.m3u8 표기와 실제 HLS 해상도가 달랐다

첫 번째로 확인한 문제는 master.m3u8에 표기된 해상도와 실제 HLS 결과물의 해상도가 다르다는 점이었습니다.

Big Buck Bunny와 Meridian은 master에 표기된 해상도와 실제 HLS 해상도가 일치했지만, Tears of Steel은 달랐습니다.

영상	화질	master 표기	실제 HLS 해상도
Tears of Steel	360p	640x360	806x360
	720p	1280x720	1614x720
	1080p	1920x1080	2420x1080

Tears of Steel은 원본 영상의 화면 비율이 프로젝트 정책 16:9와 다른 21:9였고, 트랜스코딩 과정에서 비율을 유지하며 리사이징되었습니다. 그 결과 실제 출력 영상은 806x360, 1614x720, 2420x1080처럼 생성되었습니다.

문제는 실제 출력은 비율을 유지해 정상적으로 생성되었지만, master에는 고정된 16:9 해상도처럼 기록되고 있었다는 점입니다.

불일치가 발생한 이유

두 값이 서로 다른 출처에서 나왔기 때문입니다.

기존 방식은 360p, 720p, 1080p 같은 화질 enum을 기준으로 master 정보를 구성하고 있었습니다. 실제 영상은 ffmpeg의 scale=-2:height 명령어로 만들어지며, 높이만 맞추고 너비는 원본 비율대로 자동 계산합니다. 일반적인 16:9 영상에서는 큰 문제가 없어 보일 수 있지만, 입력 영상의 화면 비율이 다르면 실제 출력 해상도는 enum에 고정된 값과 달라질 수 있습니다.

반면, 매니페스트(master.m3u8) 표기는 코드에 박힌 고정값(16:9를 가정한 640 × 360 등)을 그대로 적었습니다. 실제 출력물을 다시 확인하지 않았습니다.

즉, '영상을 만드는 쪽'과 '목록에 적는 쪽'에서 각기 다른 것을 바라보도록 로직이 작성되어 있었기 때문입니다.

왜 문제인가

처음에는 단순한 metadata 표기 오류처럼 보였습니다. 하지만 HLS에서 master playlist는 플레이어가 각 화질을 선택할 때 참고하는 정보입니다. master에 적힌 해상도와 실제 미디어의 해상도가 다르면, 플레이어와 모니터링 도구는 실제 출력과 다른 정보를 기준으로 판단하게 됩니다.

또한, VMAF 측정에서도 혼란이 생길 수 있습니다. 측정은 실제 HLS 해상도를 기준으로 진행했지만, master에 기록된 값과 실제 값이 다르다면 '어떤 해상도의 결과물을 평가하고 있는가'를 문서와 리포트에서 명확히 설명하기 어려워집니다.

ABR 환경에서 플레이어는 master의 해상도·대역폭을 보고 네트워크 상황에 맞는 화질을 고름. 표기가 틀리면 잘못된 화질을 선택할 수 있음.
측정·리포트에서 '해상도'의 의미가 흔들림. 640 × 360을 비교 기준으로 삼으면 실제 806 × 360 결과를 잘못 평가하게 됨.

해결

매니페스트를 고정값이 아니라 실제 출력물을 다시 probe한 값 기준으로 생성하는 것입니다. 원본의 비율을 살리기로 결정했다면, 해당 비율에 맞춰 스케일된 실제 값을 매니페스트 파일에 작성합니다.

기존 방식	보완 방향
360p, 720p, 1080p enum 기준으로 master 작성	실제 HLS output metadata 기준으로 master 작성
예상 해상도를 기록	실제 생성된 해상도를 기록
코드가 의도한 결과를 기준으로 설명	FFmpeg이 실제 만든 결과를 기준으로 설명

이렇게 해야 HLS 산출물과 metadata가 서로 일치하고, 이후 품질 측정 리포트에서도 어떤 결과물을 비교했는지 명확하게 설명할 수 있습니다.

3-2. 키프레임/GOP가 고정되어 있지 않다

HLS는 단일 영상 파일이 아니라 여러 segment와 playlist로 구성됩니다. 따라서 파일이 생성되었다고 해서 곧바로 안정적인 HLS 결과물이라고 볼 수는 없습니다. 특히, ABR 스트리밍에서는 segment 길이, keyframe 위치, rendition 간 segment 정렬이 중요합니다. 화질 전환은 보통 segment 경계에서 발생하기 때문에, keyframe과 segment 구조가 어긋나면 seek나 화질 전환 시점에서 문제가 생길 수 있습니다.

키프레임은 혼자서 완전히 디코딩되는 프레임이고, GOP(Group of Pictures)는 키프레임 하나부터 다음 키프레임 직전까지의 묶음을 말합니다.

하지만, 기존 ffmpeg 명령에는 키프레임 간격을 정하는 옵션(-g, -keyint_min, force_key_frames)이 하나도 없었습니다. 키프레임을 언제 넣을지를 인코더 자율에 맡긴 셈입니다.

이렇게 되면 세그먼트는 시간(ex. 6초)으로 자르는데, 키프레임 간격이 제멋대로면 세그먼트 시작점이 키프레임과 맞지 않습니다. 그래서 화질 전환(ABR) 시 깨지거나, 특정 시점 이동(seek)이 부정확하거나, 세그먼트 단위로 영상을 다룰 때 경계가 어긋납니다.
측정 관점에서도 세그먼트 경계가 들쭉날쭉하면 구간 단위 분석이 불안정합니다.

해결

GOP를 일정 간격(예: 2초)으로 고정하고, 장면 전환마다 키프레임을 추가로 넣지 않도록(closed GOP) 만들어 세그먼트 경계와 키프레임을 정렬합니다.

저는 GOP를 2초로 설정했는데, 중요한 건 세그먼트 길이의 약수로 설정하는 것입니다. 세그먼트의 경계와 키프레임이 일치해야 영상을 끊김없이 독립적으로 제공할 수 있기 때문입니다.

추가로 세그먼트 길이는 6초로 설정했습니다. 일반적으로 HLS에서 6초를 많이 사용한다고 하며, 길이에 따라 장단점이 존재합니다. 세그먼트가 길면 압축 효율이 좋고 클라이언트가 적은 요청으로 재생할 수 있다는 장점이 있지만, 네트워크 상황에 민감하게 반응하지 못 한다는 단점이 있습니다. 반대로 세그먼트 길이가 짧으면 네트워크 상황에 따라 빠르게 화질을 변경할 수 있지만, 압축 효율이 좋지 않습니다.

또한, independent_segments를 설정하여 각 세그먼트가 독립적으로 디코딩 가능하도록 했습니다. 결국 세그먼트 단위로 전송되고 플레이어에서 재생되기 때문에 하나의 세그먼트만 있어도 그만큼의 영상을 시청할 수 있도록 하기 위함입니다.

4. VMAF 측정 방식 문제

HLS 산출물에서 확인된 구조적 문제를 정리한 뒤에는 VMAF 측정 방식 자체를 확인했습니다. 여기서 확인하려는 것은 “영상이 정말 나쁜가?”가 아니라 “같은 장면끼리 비교하고 있는가?”입니다.

앞에서 본 측정에서 고복잡도(Tears) 영상의 VMAF 점수가 낮았습니다. 이에 대한 결과 지표를 중심으로 하나씩 원인을 파악하고 개선해보겠습니다.

4-1. 시도 1: 시작 시간 맞추기

측정 전 ffprobe로 원본과 HLS 출력의 정보를 확인했는데, 이를 바탕으로 살펴보니 HLS 결과물이 원본보다 늦게 시작했습니다(BBB 1.445초, Meridian 1.433초, Tears 1.463초). VMAF는 '원본 0초 프레임 ↔ 변환본 0초 프레임'을 비교한다고 가정하는데, 한쪽이 1.4초 밀려 있으면 같은 인덱스인데 다른 장면을 비교하게 되므로 정상적인 비교를 할 수 없습니다.

가장 먼저 시작 시점을 맞추는 필터 setpts=PTS-STARTPTS(각 입력의 첫 프레임을 0초로 당김)를 떠올려 바로 적용해봤습니다. 여기서 PTS는 간단하게 말하면 '이 프레임을 영상의 몇 초 시점에 화면에 보여줘야 하는가'를 나타내는 시간표입니다.

Tears에 적용하니 전체 영상 평균이 회복됐지만, 저복잡도인 BBB에서는 오히려 점수가 크게 떨어졌습니다. 흐르는 눈물을 닦고 제가 놓친 것이 무엇인가 고민해보았습니다.

세 영상 모두 start_time이 비슷한 1.4초였는데 결과가 갈렸으므로 start_time이 직접적인 원인이 아니었습니다.

찾아보니 setpts는 같은 장면을 찾아 맞춰주는 필터가 아니라 첫 PTS를 0으로 미는 필터였습니다. Tears는 그 밀림이 오차라 0으로 당기는 게 도움이 됐지만, BBB는 그 밀림 자체가 '원본이 정확히 몇 프레임 늦다'는 의미 있는 정렬 정보였습니다. 이 상태에서 setpts가 그 정보를 지워버리니, 오히려 어긋난 프레임끼리 비교된 것입니다.

진짜 기준은 디코딩된 첫 프레임의 PTS가 fps 프레임 격자(1/fps 간격의 눈금) 위 어디에 놓이는가이고, 모든 영상에 같은 보정을 적용하면 안 되었습니다.

4-2. 시도 2: 영상마다 다르게 정렬하기

FPS와 PTS

fps는 프레임의 시각(PTS)을 결정합니다.

fps = 초당 프레임 수 → 1프레임의 시간 = 1/fps (30fps면 0.033초, 24fps면 0.042초)
PTS = 그 프레임이 표시될 시각. CFR이면 프레임 N의 PTS = 첫 PTS + N × (1/fps)

프레임들은 1/fps 간격으로 시간축에 일정하게 놓입니다. 이 균일한 눈금이 프레임 격자입니다.

Offset이 정수냐 비정수냐

원본과 HLS는 같은 fps라 격자 간격은 똑같습니다. 다만 첫 PTS가 다르면 격자가 통째로 옆으로 밀리는데(offset), 이 밀림이 프레임 간격의 정수배냐 아니냐가 갈림길입니다.

BBB: offset 0.067초 = 30fps로 정확히 2.0프레임(정수) → 두 격자 눈금이 포개짐 → 1:1로 깔끔. 이 2프레임은 "원본이 2칸 늦다"는 정확한 정렬 정보라 보존해야 합니다. 따라서 이를 setpts로 지우면 깨지는 것입니다.
Tears: offset 0.003초 = 24fps로 0.072프레임(비정수) → 눈금이 영영 포개지지 않아 framesync가 경계에서 흔들립니다. 그래서 0으로 리셋(reset)해 양쪽을 같은 칸에 올리는 게 낫습니다.

보강: 프레임 끝단 오염 차단

시작점을 맞춰도 원본과 HLS의 프레임 수가 미세하게 다르면 끝부분에서 한 칸씩 밀려 비교가 오염될 수 있습니다. 그래서 측정 명령에 'shortest=1:repeatlast=0:eof_action=endall'을 넣어 짧은 쪽 기준으로 비교를 종료하고, 끝 프레임이 반복되며 점수를 왜곡하는 것을 막았습니다.

결과

정렬을 모두 보정하자 Tears의 중간값은 90점대, 평균은 70점대가 나타났습니다. 이는 아직 이상치가 존재한다는 신호였습니다.

처음 측정 결과인 '비정상 저점'의 상당 부분은 화질이 아니라 측정 정렬 문제였습니다. 다만, 정렬 후에도 Tears 평균은 72~77로 90 미만이 남았습니다. 남은 문제는 VMAF 측정 문제가 아닌 인코딩 결과물에 대한 보정이 필요했습니다.

5. CFR로 재인코딩

측정 자체를 신뢰할 수 있게 만든 다음, 3장에서 살펴본 산출물 결함(키프레임/GOP 등)을 실제로 고쳐 HLS를 CFR로 재인코딩하고 같은 규칙으로 다시 측정했습니다.

VFR 원본과 CFR 출력의 비대칭

VFR은 Variable Frame Rate, 즉 프레임 간격이 일정하지 않은 영상이고, CFR은 Constant Frame Rate, 즉 일정한 간격으로 프레임이 배치된 영상입니다. VMAF는 프레임 단위 비교이기 때문에, 한쪽은 VFR이고 다른 한쪽은 CFR이면 문제가 생길 수 있습니다.

Tears는 원본이 VFR(가변 프레임레이트)이었습니다(다른 영상은 원본이 CFR). reset_pts로 시작점은 맞췄지만, VFR 원본과 CFR 출력의 프레임 간격 자체가 달라 여전히 짝이 어긋났습니다.

기존 명령에는 출력 프레임레이트를 명시적으로 CFR로 고정하는 정책이 없었습니다. 그래서 입력이 VFR일 때 출력의 프레임 간격을 어떤 기준으로 정규화할지 파이프라인에서 결정하지 못했습니다. 이 점이 아래 두 문제를 일으켰습니다.

측정: 시작점을 맞춰도(reset) 프레임 간격이 불규칙해서, 중간 프레임들이 다시 한 칸씩 어긋납니다. 시작만 정렬해선 부족했던 이유입니다.
재생·세그먼트: 프레임 타이밍이 들쭉날쭉하면 세그먼트 경계 정렬과 플레이어 동기화에 불리합니다.

그래서 인코딩할 때 '-r {대표 fps} -fps_mode cfr'로 출력을 CFR로 고정했습니다. 입력이 VFR이어도 출력은 일정한 간격의 프레임으로 정규화하여 일정한 fps 격자 위에 놓이도록 만든 것입니다.

다만 VFR을 CFR로 바꾸는 과정에서는 프레임 복제나 삭제가 발생할 수 있습니다. 이는 원본의 시간 리듬을 일부 바꿀 수 있다는 단점이 있지만, HLS 재생 안정성과 VMAF 측정 일관성을 얻기 위한 선택이었습니다.

그리고 측정할 때는 원본도 출력과 같은 fps 격자에 올린 뒤 비교했습니다. 즉 “원본 VFR vs 출력 CFR”을 그대로 비교하지 않고, 양쪽을 같은 시간 격자에 맞춘 상태에서 VMAF를 측정했습니다.

이렇게 출력을 CFR로 만들어 두면, 측정할 때 원본(VFR)과 출력(CFR)을 같은 fps 격자 위에 올려 공정하게 비교할 수 있습니다.

그래서 원본과 출력을 모두 같은 24fps 격자에 올린 뒤 정렬하는 'symmetric_cfr_reset_pts'를 적용했고, Tears의 VMAF 점수는 360p 94.97 / 720p 95.52 / 1080p 95.56으로 정상 수준에 올라왔습니다.

아래 표로 정리해보았습니다.

영상	원본 프레임레이트	인코딩 (HLS 출력)	측정 (VMAF 정렬)
BBB	CFR 30fps	-fps mode cfr -> CFR 30fps	preserve_pts (PTS 보존)
Meridian	CFR 59.94fps	-fps mode cfr -> CFR 59.94fps	preserve_pts (PTS 보존)
Tears	VFR	-fps mode cfr -> CFR 24fps	symmetric_cfr_reset_pts (원본, 출력을 원본(24) fps 격자로 맞춤 + 시작점 리셋)

6. 결론 및 정리

BBB와 Meridian은 원래 높았던 점수를 유지했고, Tears의 점수가 정상 궤도로 진입했다고 볼 수 있는 값이 되었습니다.

Tears의 상승을 단계별로 그려봤습니다. 보정 전 41.9 → 측정 정렬만 바로잡은 단계(기존 출력 그대로) 74.6 → 출력 개선 + 대칭 측정 95.4로 상승분 기준 약 60%는 정렬 보정 단계에서 회복되었고, 화질 자체 문제는 일부였습니다.

3장에서 개선한 트랜스코딩 과정에서의 보강은 GOP/세그먼트 보강은 재생 안정성이 1차 목적이고, CFR/대칭 측정은 VMAF 신뢰성에도 관련이 있었습니다.

마무리

이 글에서 다룬 작업은 'VMAF를 몇 점 올렸다'보다 아래 두 가지 목적이 있었습니다.

측정을 신뢰할 수 있게 만들었다 (정렬·프레임·해상도 기준 확립).
HLS 구조를 안정화했다 (GOP·세그먼트·매니페스트·CFR).

이들이 합쳐져 신뢰 가능한 VMAF 기준선을 얻었고, 이것이 2편(Per-Title Encoding)의 출발점이 되어 영상과 품질 측정에서의 문제로 슬플 일이 없게 해줍니다.

인코딩하고 측정하는 시간이 너무 오래 걸려서 힘들었습니다... 영상 관련 내용도 이론으로 공부를 해 두었던 게 조금은 도움이 되었던 것 같아요. 이것저것 참고하고, 의심하며 측정을 여러 번 해봤습니다.

다음 편에는 넷플릭스에서 제시한 Per-Title-Encoding을 적용한 과정을 다뤄보겠습니다.

[O+T] 영상 이어보기 처리량 개선하기

phonil — Wed, 13 May 2026 11:49:22 +0900

0. 개요

유튜브나 넷플릭스, 혹은 다른 OTT 서비스에서 영상을 시청하면 아래와 같이 어디까지 봤는지 그 지점을 표시해줍니다.

이렇게 시청 전에 재생 지점을 보여주는 것뿐만 아니라, 이전에 시청했던 영상을 다시 볼 때 마지막으로 봤던 지점부터 이어 볼 수 있는 기능을 제공합니다.

특히, 사용자가 영상을 시청하는 동안 일정 주기로 현재 재생 위치를 갱신해야 하기 때문에 같은 사용자가 같은 영상에 대해 짧은 간격으로 반복 요청을 보내는 구조가 됩니다. 또한, OTT 서비스에서 사용자는 영상 시청에 대부분의 시간을 사용하므로 자연스레 트래픽이 가장 몰리는 지점이 됩니다.

이 요청은 같은 사용자와 같은 영상에 대해 짧은 간격으로 반복 호출된다는 특징이 있습니다. 따라서 일반적인 조회와 다르게 반복적인 write 요청을 어떻게 더 효율적으로 처리할 것인지의 관점에서 접근했습니다.

이어보기 갱신 작업이 트래픽을 더 잘 견디도록 개선한 과정을 정리해보겠습니다.

1. 테스트 결과

많은 트래픽이 예상되는 지점이므로 K6 부하 테스트를 진행해봤습니다.

각 VU가 이어보기 지점을 5초마다 갱신하는 /playlist API를 호출합니다.

VU2000부터 평균 응답 시간이 매우 높아지는 것을 볼 수 있고, VU3000이상은 에러율이 너무 높아서 기존 상태에서 사실상 무의미했습니다. 처리량 역시 기대에 미치지 못했습니다.

요청 스레드 대기 증가
DB Connection 부족
GC

등이 주요 병목 원인으로 예상되었고, Grafana를 살펴봤습니다.

우선 VU2000~부터는 지표 수집 자체가 잘 되지 않았고, 로그에서 request fail이 많이 발생한 것을 확인했습니다. 이는 요청 스레드의 대기가 증가해서 요청 자체가 실패한 것으로 파악되었습니다.

서버 스펙이 작아서 발생하는 것이기도 하지만, 병목 지점이 있기 때문에 요청-응답의 순환이 원활하지 않은 것이 근본적인 문제였습니다. DB Connection 부족이 발견되었고, 쿼리 자체의 속도 혹은 쿼리 개수로 문제를 좁혔습니다.

타임아웃은 없었지만 pending 상태가 70개를 넘어서는 것을 통해 쿼리 자체의 속도보다는 쿼리 개수가 너무 많아서 발생하는 병목으로 확인했고, 실제 로직에서 사용하는 쿼리 또한 간단했기에 쏟아지는 트래픽에서 쿼리 수를 줄이는 방향으로 잡았습니다.

컴퓨터 자원의 부담을 최소화한 상태에서 응답 시간을 줄이고 처리량을 향상시키는 것을 목적으로 진행했습니다.

2. Read: 이어보기 캐시 도입

2-1. 이어보기 지점 갱신 로직

먼저, 이어보기 기능을 담당하는 Playback 갱신 API의 로직을 살펴봤습니다.

Select문으로 mediaId에 대한 예외 처리를 먼저 하고 contentsId를 가져온 후 Playback에 대한 Upsert를 진행합니다.

우선 쿼리를 단순화하고자 매번 Upsert가 아닌 플레이어 화면 진입 후 첫 재생 시 Insert, 영상 재생 중 update API로 분리했습니다.

Playback 갱신 요청은 사용자가 영상을 시청하는 동안 일정 주기로 반복해서 호출됩니다. 한 번 호출되고 끝나는 요청이 아니라 같은 사용자와 같은 영상에 대해 짧은 간격으로 계속 들어오는 write 요청입니다. 이런 요청 경로에서 기존 구조는 성공 요청마다 항상 두 번의 데이터베이스 접근이 필요했습니다.

한 번의 요청만 보면 큰 차이가 없어 보일 수 있지만, 이 요청은 반복 호출되기 때문에 요청당 데이터베이스 접근이 한 번 더 필요하다는 것이 부담된다고 생각했습니다.

특히, 대부분인 성공 요청도 체크를 위해 항상 먼저 조회를 수행해야 했고, 아래과 같은 아쉬움이 있었습니다.

성공 경로에서도 DB round trip이 2번 발생한다.
반복적인 write 요청 경로에서 select 비용이 누적된다.

2-2. 단일 쿼리 통합을 선택하지 않은 이유

처음에는 기존 SELECT + UPSERT 흐름을 하나의 SQL로 합치는 방향을 생각했습니다. INSERT ... SELECT ... ON DUPLICATE KEY UPDATE 형태로 mediaId -> contentsId 변환, 재생 가능 여부 확인, playback upsert를 하나의 경로로 묶는 방식입니다.

INSERT INTO playback (member_id, contents_id, position_sec, created_date, modified_date, status)
SELECT :memberId, c.id, :positionSec, NOW(), NOW(), 'ACTIVE'
FROM contents c JOIN media m ON m.id = c.media_id
WHERE m.id = :mediaId AND c.status = 'ACTIVE' ...
ON DUPLICATE KEY UPDATE position_sec = :positionSec, ...

이 방식은 동기 write의 경우 장점이 있습니다.

성공 경로의 DB 왕복을 줄일 수 있다.
조회와 저장을 하나의 경로로 묶을 수 있다.

하지만 이번 작업은 반복적으로 들어오는 write 자체를 버퍼링하고, 이후 bulk로 처리하는 구조가 필요했습니다.

int affectedRows = playbackRepository.updatePlaybackByMediaId(memberId, mediaId, positionSec);
if (affectedRows > 0)
	return;

if (!contentsRepository.existsPlayableByMediaId(mediaId)
	throw new BusinessException(ErrorCode.CONTENTS_NOT_FOUND);

이를 기준으로 보면 단일 쿼리 통합에는 한계가 있었습니다.

잘못된 mediaId에 대해 즉시 실패 응답을 주기가 어려움
- 버퍼에 적재한 뒤 바로 204를 반환하면 검증이 DB write 시점으로 밀리는 순간 잘못된 요청도 일단 성공처럼 보이게 됨
bulk upsert의 복잡함
- 나중에 버퍼에 쌓인 데이터를 한 번에 반영할 때는 검증과 변환이 붙은 무거운 쿼리보다 필요한 데이터만 빠르게 반영하는 쿼리가 더 적합함
- Upsert -> Update 변경 후에도 결국 조인이 필요함

따라서 검증 + 저장을 하나의 SQL로 묶는 방식보다 검증은 앞단에서 빠르게 처리하고, 저장은 뒤로 미루는 구조가 더 자연스럽다고 판단했습니다.

2-3. 캐시 도입

갱신 요청 외에도 해당 요청이 유효한지 확인하기 위해 MediaID를 검증하는 과정에서 지속적으로 DB Connection을 사용하여 리소스를 낭비하고 있었습니다. 이때 캐시를 도입하여 DB Connection 사용을 최소화하는 방법으로 개선했습니다. 영상 최초 진입 시에만 쿼리를 날리고, 그 다음 요청부터는 캐시에 접근합니다.

mediaId가 재생 가능한 대상인지 먼저 확인한다.
이 검증 결과를 캐시에 저장한다.
이후 요청에서는 DB 조회 없이 캐시로 검증한다.
검증을 통과한 요청만 갱신 작업을 진행한다.

크게 아래 세 가지 이유로 캐시를 선택했습니다.

자주 변경되지 않고 조회가 빈번하다

미디어는 관리자 페이지에서만 수정이 가능하고, 변경이 매우 드문 특성을 가지고 있습니다. 반면, 이어보기 갱신은 영상을 시청하고 있는 모든 사용자로부터 5초마다 요청이 발생하여 같은 데이터를 반복적으로 조회하게 됩니다.

미디어 수정은 관리자 기능을 통해 제한적으로 발생하므로, 수정 시점에 해당 캐시를 갱신하거나 삭제하는 방식으로 데이터 정합성 관리가 비교적 단순하다고 판단했습니다.

잘못된 요청에 대해 즉시 실패 응답을 줄 수 있다

버퍼링 구조에서는 요청을 받은 뒤 바로 204를 반환하는 쪽이 자연스럽습니다.

이때 검증까지 뒤로 미뤄버리면 존재하지 않는 mediaId나 재생 불가능한 콘텐츠에 대해서도 일단 성공 응답을 주게 됩니다.

반면, 앞단에서 캐시 기반 검증을 수행하면 재생 가능한 대상인지 먼저 판별한 뒤에만 버퍼에 적재할 수 있습니다.

유효한 요청 -> 204
잘못된 요청 -> 404

를 바로 구분할 수 있습니다.

bulk update를 단순한 저장 쿼리로 유지할 수 있다

검증 단계에서 contentsId까지 확정해 두면, flush 시점에는 더 이상 mediaId -> contentsId 변환이나 상태 검증이 필요하지 않습니다.

버퍼를 비울 때의 SQL은 단순해집니다.

(memberId, contentsId, positionSec, ...)으로 Update
Update 내 Join 없음

무거운 검증 로직을 다시 요청 시점으로 끌어오고, bulk update는 최대한 저장 전용 쿼리로 단순화할 수 있습니다.

2-4. 로컬 vs 글로벌 캐시

로컬 캐시를 사용할지 글로벌 캐시를 사용할지 결정해야 했는데, 다중 서버 환경임에도 로컬 캐시가 적합하다고 생각했습니다.

속도
- 글로벌 캐시는 매 요청마다 네트워크를 왕복해야 하지만, 로컬 캐시는 바로 응답 가능
캐시 장애 시 DB 부하
- 별도 캐시 서버에 장애가 발생하면 검증을 위한 Select 쿼리가 매 요청마다 DB에 발생
추가 인프라 및 관리의 어려움
Media 데이터 변경에 민감하지 않음
- 메타 데이터 변경이 빈번하지 않으며 Select 검증 로직에서 상태를 체크하지만, 이 값들이 변경되더라도 즉시 반영되어 playback 갱신을 막을 필요는 없음. 캐시 데이터의 일관성을 완벽히 유지하지 않고, TTL로 충분히 허용 가능한 수준.

2-5. 문제

정합성 문제

어떤 media가 PUBLIC에서 PRIVATE로 바뀌거나, COMPLETED 상태가 아닌 값으로 바뀌는 경우 캐시에 이전 상태가 남아 있으면 재생 불가능한 대상임에도 검증을 통과시킬 수 있습니다. 변경 후 이어보기 갱신은 큰 문제가 없기 때문에 짧은 TTL로 충분히 관리 가능하다고 보았습니다.

메모리 관리

미디어 데이터에 대해 각 서버별로 같은 미디어를 캐싱하게 되며, 그 수가 많아질 경우 메모리 관리가 필수적입니다.

적절한 TTL 설정
캐싱 미디어 수 제한
키-값 크기 최소화

Grafana에서 Heap을 보며 Promotion, GC가 얼마나 일어나는지 체크해야 합니다.

2-6. 결론

로컬 캐시로 Caffeine을 사용했고, 아래 그림처럼 검증에 캐시를 두어 Select를 최소화했습니다.

구분	기존 흐름	개선 후 흐름
정상 요청	SELECT -> UPDATE	캐시 체크 -> Update
실패 요청	조회 단계에서 예외	캐시 확인 후 예외

3. Write: 문제 인식

캐시로 Select를 줄였으나, 부하 테스트 결과에는 큰 변화가 없었습니다. 여전히 이어보기 갱신 요청마다 Update 쿼리를 수행했고, 이로 인한 DB 접근이 너무 잦았기 때문입니다.

캐시 후에도 눈에 띄는 개선이 없는 이유

여전히 Update 자체가 요청 수만큼 발생하기 때문에 요청 스레드가 매번 DB Update에 묶여, DB Connection이 금방 부족해졌습니다. 기본값인 이 설정을 늘리는 방법도 있지만, 처음부터 늘릴 것이 아니라고 생각해 다른 방식을 찾아보았습니다.

동기 Write 구조의 한계

DB 접근 대기로 요청 스레드의 대기가 늘어남
커넥션 점유 및 대기 시간동안 요청에 대한 응답 시간이 지연됨
고부하에서 톰캣 스레드 고갈로 요청 자체가 실패함

위의 이유들로 인해 검증은 캐싱으로, 저장은 미루는 방식을 선택하여 사용자 요청에 대한 응답은 빨리 주는 구조로 변경하는 방안을 선택했습니다.

4. Write: 버퍼링

버퍼를 두어 요청에 대한 작업을 모아두고 일정량 혹은 일정 주기마다 한 번에 DB에 접근하는 방식으로 변경했습니다.

작업 특성

Playback의 특성을 간단히 정리해보자면 아래와 같습니다.

어느 정도의 유실은 허용한다. (이어보기 요청 3~4회 정도의 사이클까지)
즉시 반영되지 않아도 된다.
가장 최근 발생한 요청이 반영되어야 한다.
Write 비율이 매우 높다.
사용자 + 콘텐츠 조합으로 구분되며, 하나의 조합으로 지속적인 요청이 들어온다.

Step 1. 큐 도입

요청과 DB Write를 분리하기 위해 작업을 큐에 모아 한 번에 갱신합니다. 요청 스레드가 직접 DB에 접근하는 대신 큐에 작업만 넣고 즉시 응답하도록 바꿨습니다. 실제 DB 반영은 별도의 워커 스레드가 뒤에서 처리합니다.

로컬 큐 vs 글로벌 큐

캐시처럼 큐도 마찬가지로 로컬이냐 글로벌이냐 결정해야 했고, 큐 외의 다른 자료구조를 쓸 것인지 고민했습니다.

후보	장점	단점	적합한 상황
Local Queue	네트워크 왕복, 인프라 추가 x	서버 다운 시 큐 작업 유실, 서버 간 순서 보장 필요	빠른 속도 필요, 손실 허용
Redis Write-Behind	다중 서버 공유 간편, 순서 보장 가능	네트워크 왕복 발생, 인프라 추가	다중 서버, 내구성
In-Memory Map	중복 key 자동 제거	크기 한정 및 원자적 처리 어려움	중복이 많이 발생하는 경우

저는 로컬 큐를 선택했습니다. 다중 서버 환경에서 순서 문제가 가장 크게 다가왔지만 충분히 해결할 수 있었고, 글로벌 큐 다운 시 트래픽을 견디기 어려울 것이라 생각했습니다. 또한, Playback 특성 상 주기가 짧다면 중복이 많이 발생하지 않고, 자연스러운 FIFO를 사용하고자 큐를 선택했습니다.

LinkedBlockingQueue

큐는 LinkedBlockingQueue를 사용했습니다.

bounded: 트래픽이 매우 많아져 큐에 작업이 무한히 쌓일 수 있으므로 큐의 상한을 정했습니다.
put/take 락 분리: 큐에 작업을 넣는 쪽과 꺼내는 쪽의 락이 분리되어 있어 락 경합을 줄일 수 있습니다.

public class PlaybackCommandQueue {

    private final BlockingQueue<PlaybackCommand> queue;

    public PlaybackCommandQueue(int capacity) {
        this.queue = new LinkedBlockingQueue<>(capacity);
    }
    // offer(), drain(), size() ...
}

상한은 Bulk Size(1000)보다 큰 10000으로 잡았습니다. 순간적으로 몰리는 경우 Flush보다 더 많은 요청이 들어올 수 있기 때문입니다.

큐에 추가하는 함수는 put()이 아닌 offer()를 사용했습니다. 큐에 빈 공간이 없는 경우 put()은 대기합니다. 하지만, 스레드 대기로 인해 트래픽이 늘어날수록 병목이 거대해질 수 있었고, 이어보기는 모든 데이터가 반드시 포함되어야 하는 것은 아니므로 바로 false를 반환하는 offer()를 수행합니다.

Step 2. Bulk Update

큐에 모은 PlaybackCommand 객체를 작업 단위로, 하나씩 쿼리를 날리는 것이 아니라 일정 주기마다 Bulk Update를 수행했습니다.

API 요청은 큐에 적재 후 사용자에게 응답하고, 백그라운드 스레드로 큐를 확인합니다. 큐를 보는 스레드는 하나로 고정하여 스레드 낭비를 줄였습니다. Flush 트리거는 두 개로, 큐가 꽉 차거나 정해진 시간(5초 ~)마다 큐를 비우고, 쿼리를 날립니다.

public record PlaybackCommand(
    long memberId,
    long contentsId,
    int positionSec,
    Instant requestedAt
) {
    public PlaybackKey key() {
        return new PlaybackKey(memberId, contentsId);
    }
}

A유저가 M영상에 대한 이어보기를 보내는 것을 구분하고자 member, contents를 key로 잡았습니다.

데드락

Bulk Update로 인해 여러 대의 서버에서 Flush를 할 때, Update 쿼리는 로우 락을 잡기 때문에 순서에 따라 데드락이 발생할 수 있었습니다.

서버 1에서 K1, K2, K3로, 서버 2에서 K2, K1, K3 순서로 Flush를 진행할 때, 위처럼 락이 엇갈릴 수 있습니다.

쿼리를 날리기 전에 키 기준으로 정렬해 데드락을 방지했습니다.

List<PlaybackCommand> sorted = commands.stream()
    .sorted(Comparator.comparing(PlaybackCommand::memberId)
                       .thenComparing(PlaybackCommand::contentsId))
    .toList();

Step 3. 중복 제거

큐에서 작업을 꺼내는 Flush 주기가 사용자 이어보기 지점 갱신 주기보다 길다면 한 번의 Flush 작업에 동일한 키를 가진 Command가 여러 개 존재할 수 있습니다.

이어보기는 '가장 최근 발생'한 것만 DB에 반영되면 되므로 한 번의 Flush에서 중복 키에 대한 비효율을 줄일 수 있었습니다.

그림처럼 큐에 있는 5개의 작업에서 중복을 제거한 후 3개만 Flush 한다면 수행해야 할 작업이 줄어듭니다.

하지만, 현재 유실 문제를 최소화하고자 클라이언트로부터 발생하는 이어보기 요청 주기와 Flush 주기를 5초로 같게 설정했기 때문에 하나의 큐에 동일한 키의 작업이 존재하지 않습니다.

이는 트래픽이 더 높아져, 클라이언트가 작업을 모아서 주거나, Flush 주기를 늘리게 되는 경우 더욱 최적화할 수 있는 방안입니다.

Step 4. 순서 보장

앞서 본 것처럼 이어보기는 '가장 최근 발생'한 것이 DB에 반영되어야 하는데, 여러 서버의 각 큐에서 동시다발적으로 Flush가 발생하면 요청이 발생한 순서와 DB에 반영되는 순서가 어긋날 수 있습니다.

13:00:01  사용자 A → 서버 2 큐: key=(42, 100), position=100, event_time=13:00:01
13:00:06  사용자 A → 서버 1 큐: key=(42, 100), position=200, event_time=13:00:06

13:00:08  서버 1 Flush → UPDATE playback SET position_sec=200
                         WHERE member_id=42 AND contents_id=100   → DB position=200 ✅
13:00:10  서버 2 Flush → UPDATE playback SET position_sec=100
                         WHERE member_id=42 AND contents_id=100   → DB position=100 ❌

사용자 A가 200초 지점까지 봤는데, DB에는 100초가 마지막으로 기록되는 문제가 발생할 수 있습니다.

5초 주기로 이어보기 지점 갱신을 하니까 괜찮을 수 있다고 생각했지만, 사용자가 직접 바를 눌러서 다른 지점으로 이동하여 시청하는 경우 불편함이 있을 것이라고 생각했습니다.

Event_Time 컬럼 추가

요청이 발생한 시각을 데이터베이스에 함께 저장하고, 더 오래된 요청은 무시하는 방식으로 해결했습니다.

playback 테이블에 event_time 컬럼을 추가하고, Update 조건으로 event_time을 확인하도록 구성했습니다.

UPDATE playback
SET position_sec = ?, modified_date = NOW(), event_time = ?
WHERE member_id = ? AND contents_id = ? AND ...
AND event_time < ?

사용자가 직접 영상 시청 지점을 이동할 수 있기 때문에 position으로 정렬하는 방식은 사용할 수 없었습니다.

5. 결과

개선 작업을 진행하고 다시 부하 테스트를 진행했습니다.

VU2000부터 문제가 보이던 것이 VU5000까지 에러 없이 처리하는 것을 확인했습니다. TPS 또한 VU / 5초 정도로 예상치만큼 요청을 처리하여 최대 761/s까지 나타나며 처리량이 상당이 높아졌습니다.

VU10000은 또다시 에러율이 높은데, 이는 요청 자체가 실패하는 경우가 많았습니다. 요청을 받아줄 톰캣 스레드가 부족하여 서버에 들어가지 못했습니다.

DB 커넥션

기본값으로 설정해 둔 10개를 넘어 커넥션을 얻기 위해 대기하던 작업 전과 다르게 안정된 커넥션 사용을 보여주고 있었고, DB 커넥션 부족 문제는 해결되었습니다.

버퍼

큐 사이즈와 실패 횟수를 메트릭으로 확인했습니다.

큐가 상한까지 차지 않았고, 버려진 요소가 존재하지 않았기에 버퍼의 병목이 크지 않았습니다.

Heap

주된 원인은 아니었지만, 힙이 작고 Servivor Space의 크기가 작아서 금방금방 가득 찼습니다. 이로 인해 트래픽이 높은 경우 요청 객체 생성이 많아지며 공간을 많이 차지하고, Major GC가 발생하기도 했습니다. 이는 작은 사이즈로 인한 조기 승격으로 Old 영역에 객체가 금방 많아져 발생한 것으로 파악되었습니다. 힙 사이즈를 키워 어느 정도 해결이 가능했습니다.

CPU

vcpu가 2개인 t3.micro 인스턴스로 부하 테스트를 진행하여 낮은 서버 스펙으로 인해 Load 패널에서 코어를 넘어서는 것을 확인할 수 있습니다.

마찬가지로 그 시점에 CPU 사용률과 스레드 개수, runnable 스레드까지 CPU 할당을 대기하고 있는 것이 매우 많았습니다.

자원을 할당받지 못한 스레드로 인해 결국 요청이 실패하게 되어 VU10000 지점에서는 업그레이드가 필요했습니다.

혹은 요청 주기를 늘리며 이어보기 지점을 클라이언트 단에서도 버퍼링하여 모아서 보내는 방식으로 처리량을 늘릴 수 있을 것 같습니다. 아래 7번 항목에서 이 경우 어떤 식으로 확장 가능한지 더 다루겠습니다.

VU10000 구간에서 발생한 실패는 DB나 큐의 병목이 아니라 톰캣 스레드와 CPU 자원 한계였습니다. DB 커넥션은 안정적으로 유지되었고, 큐도 상한에 닿지 않았으며 drop된 요소도 없었습니다. 결국 처음 마주한 "DB 접근이 잦아서 요청 스레드가 묶이는 문제"는 해소되었고, 그 다음 병목은 인스턴스 자체의 처리 한계로 옮겨갔습니다.

이 지점은 t3.micro 인스턴스 자체의 vCPU 2개로는 더 받을 여력이 없다는 신호이므로, 요청의 구조를 변경하거나 인프라 업그레이드 또는 수평 확장이 필요했습니다.

6. 성능 외 문제

정상 흐름 중심으로 진행된 성능 개선과 별도로 문제가 되는 상황들이 있습니다. 여러 문제가 있지만, 사실 playback은 약간의 유실이 허용되는 가벼운? 느낌의 데이터이기 때문에 이를 막고 얻는 이득보다 오히려 복잡도가 높아지는 경우가 많았습니다. 이득과 복잡도를 따져보며 할 수 있는 것은 하되, 너무 복잡하지 않도록 해결하고자 했습니다.

6-1. 큐가 가득 찬 경우

트래픽이 몰릴 때 Timeout 전, Flush 동안 큐에 요소가 BulkSize 이상으로 쌓일 수 있습니다. 큐의 bounded를 정해두었기 때문에 큐가 가득찼을 때 요청이 들어오면 어떻게 처리할지 정책을 정해야 했습니다.

대안	방식	장점	단점	판단
A. overflowMap 사용	- queue full 시 overflowMap에 key별 최신값 저장 - queue drain과 overflow를 합쳐 batch update	queue full 데이터도 flush 가능	- batch size 예측 어려움 - shutdown 처리 복잡 - unbounded map 관리 필요	보존이 꼭 필요하면 사용
B. 429 응답	queue full 시 클라이언트에 실패 반환	실패를 명시적으로 알림	클라이언트가 backoff 필요	이어보기에 불필요
C. put()으로 blocking	queue에 공간이 날 때까지 요청 thread 대기	유실 감소	요청 thread가 병목이 됨	write-behind 목적과 충돌
D. drop + warn	queue full 시 command를 버리고 로그/지표 기록	가장 단순, 메모리 안전, 장애 전파 적음	마지막 위치 일부 유실 가능	선택

이어보기는 5초 뒤 같은 사용자의 다음 update가 발생하므로 drop + logging을 선택했습니다.

boolean offered = playbackCommandQueue.offer(memberId, contentsId, positionSec);
if (!offered) {
    playbackMetrics.incrementQueueFullDrop();
    log.warn("Playback queue full, dropping command: memberId={}, contentsId={}",
        memberId, contentsId);
}

대신, 메트릭을 수집하여 큐 지표를 확인하고 적절한 상한 및 큐 개수를 산정할 수 있도록 했습니다.

6-2. Flush 실패

Bulk Update 중 DB 일시 장애, connection timeout 등으로 batchUpdate가 실패할 수 있습니다.

대안	방식	장점	단점	판단
A. drop + warn	실패 batch를 버리고 warn/metric 기록	- worker 지연 없음 - 정책 명확	실패 순간 batch 유실	선택
B. retry	짧게 대기 후 한 번 재시도	deadlock/일시 장애에 효과 가능	retry 동안 worker가 멈추고 queue가 쌓임	실패가 잦은 경우
C. retry buffer	실패 batch를 메모리에 보관 후 재시도	유실 감소	메모리, 순서, shutdown, 중복 처리 복잡	현재 과함
D. WAL	flush 전 파일에 기록 후 성공 시 삭제	프로세스 종료에도 복구 가능	파일 I/O, 복구 로직, 중복 처리 필요	Playback에는 과설계

이 문제도 마찬가지로 Playback 특성상 처리하고자 한다면 복잡도가 높아졌습니다. DB 장애는 종종 발생하는 일이지만, 대부분의 사용자는 영상에 오랜 시간 머물고, 계속하여 5초마다 요청이 들어오기 때문에 원인을 기록하고 drop하는 방식을 선택했습니다.

공부하면서 느낀 건 RabbitMQ나 Kafka에서 처리해주는 것들과 비슷했습니다. 저는 로컬 큐로 이들을 대신하여 구현했기 때문에 직접 처리해야 했고, 처리 정책이나 방식의 결정에 대해서는 메시지 브로커를 사용했던 프로젝트와 결이 비슷했습니다.

6-3. Graceful Shutdown

서버가 정상 종료될 때, 메모리에 남아 있는 작업들에 대한 처리는 어떻게 할지 고민했습니다. 큐에 남은 command를 그냥 버리면 마지막 5~10초 분량의 모든 사용자 위치가 사라집니다. Graceful Shutdown을 통해 정상 종료 경로에서 남은 작업을 최대한 반영하고 종료하는 정책을 만들었습니다.

앞선 결정들처럼 굳이?하면서 버릴 수 있었지만, 이는 충분히 예측과 처리가 가능한 문제였기 때문입니다.

Spring의 graceful shutdown을 켜서, 진행 중인 요청이 끝날 시간을 설정했고,

server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

워커가 @PreDestroy 시점에 직접 큐를 비웁니다

@PreDestroy
void shutdown() {
    running = false;          // 1. 새 flush loop 진입 차단
    waitForLeaderToStop();    // 2. 진행 중인 flush가 끝나길 대기
    drainRemainingQueue();    // 3. 남은 큐 flush
}

주의할 점은 서버를 끌 때 kill -15를 사용하면 안 된다는 점입니다. SIGKILL 시그널이 발생하여 즉시 강제 종료하므로 설정한 작업이 수행되지 않고 바로 종료될 수 있습니다.

kill -9를 사용하여 SIGTERM을 주거나 kill -2로 SIGINT를 통해 프로세스를 종료해야 Graceful Shutdown이 수행됩니다.

7. 나아가

5초 주기로 발생하는 Playback에 대해서는 현재까지의 개선 작업으로 충분하다고 생각하지만 더 높은 부하, 정책 변경 혹은 아예 다른 Log나 데이터 사용량같은 Write 트래픽이 쏟아지는 경우에는 현재 구조에서 더 발전시킬 수 있습니다. 이에 대해 생각해 본 내용들을 간단히 적어보겠습니다.

7-1. 클라이언트 버퍼링

클라이언트에서 요청을 모아서 주는 방식입니다.

현재는 5초 주기로 요청하는데, 이를 30초로 변경하고, 한 번에 6개씩 모아서 List로 요청합니다.

요청 횟수 자체가 현저히 줄어들지만, 그만큼 장애 시 유실 범위(5초 -> 30초)가 커진다는 단점이 있습니다. 텀을 두고 주기적으로 발생하는 Playback보다는 Write가 제한 없이 몰리는 구조에서 유용합니다.

백엔드보단 프론트에서 처리해줘야 하는 영역입니다.

7-2. Queue의 Lock이 병목일 수도

LinkedBlockingQueue를 쓰는 상황에서 위 방식을 사용하면 큐에 작업을 넣기 위한 락 경합이 심해질 수 있습니다. 요청 스레드 간 경합 + 하나의 스레드가 리스트를 순회하며 여러 요소를 하나씩 넣기 때문입니다.

Producer - Consumer 구조를 통해 큐에 넣는 스레드를 싱글 스레드로 제한합니다. Lock이 병목이었다면 큐에 접근하는 스레드를 하나만 두어 락 경합을 없앨 수 있습니다.

저는 테스트 결과 큐에 병목이 발생하려면 현재보다 월등히 높은 부하가 필요했기에 Producer Thread를 도입하지 않았습니다.

7-3. Multi Queue + Worker Pool

이 모든 것을 종합하고 파이프라인을 확장해 큐를 여러 개 두어 큐에서 작업을 꺼내는 스레드와 DB Flush 작업을 처리하는 스레드를 분리하는 방식입니다.

큐를 여러 개 두고, 특정 기준(우리의 경우 member_contents 키가 될 수 있음) 혹은 랜덤으로 큐를 선택합니다. 해당 큐의 Producer Thread(Single Thread)가 큐에 작업을 넣고, Consumer Thread가 해당 작업을 Flush 전용 Worker Pool에 제출합니다. 이렇게 각 스레드들의 작업을 분리하여 락을 없애고, 스케일 아웃을 내부적으로 구성할 수 있습니다.

위 그림에선 공간이 부족해서 Worker Pool 하나에서 모든 큐의 작업을 처리하지만, 이 Pool도 격리하여 큐마다 전용 풀을 둘 수 있습니다.

8. 마무리

최고 TPS가 280/s에 VU2000을 버거워하던 것을 TPS 760/s까지 수용하고, VU5000을 견딜 수 있도록 개선했습니다. 평균 응답 시간도 예측한대로 거의 즉시 완료되는 모습을 확인하기도 했습니다. 고민한 지점이 많았고, 실제로 적용한 것과 그렇지 못 한 것도 많았습니다. 스레드 풀, 락, 싱글 스레드, 큐 등 이러한 구조들 중에서 현재 서비스의 병목 지점에 알맞은 해결책을 과하지 않게 내고자했고, 이 과정에서 공부가 더 많이 되었던 것 같습니다.

특히, 다중 서버와 순서가 중요함에도 로컬 큐를 도입하기로 결정한 점이 이전까지의 시도와 달랐습니다. '정말 필요한가'를 따져보며 관리의 복잡성을 줄이면서 문제가 발생하지 않도록 구성하고자 했고, 역시 우리가 해결하려는 문제가 무엇인지 정확히 인식하는 것이 중요했습니다.

이 작업을 거치며 크게 두 가지를 배웠습니다.

기본 지식과 원리를 공부하면서도 이것이 나에게 어떤 쓸모가 있을까 고민한 적이 있습니다. 이번에 큐 구현 및 이로 인해 발생하는 문제들의 해결법을 찾으며 이미 만들어진 메시지 큐들로부터 힌트를 얻을 수 있었습니다. 사용법에 더해 내부 원리를 이해하며 응용할 수 있도록 학습하는 것이 정말 필요하다고 생각했습니다.

그리고 의심되는 지점에 대한 가설을 세우고 지표로 확인하는 것이 중요했습니다. 이전까지는 예측한 범위 내에서 실제로 문제가 발생했고, 이번에도 처음에는 그렇게 접근했습니다. 하지만, 락으로 인한 큐 병목을 예상해서 확장된 버전으로 개선을 했었는데 효과가 없었습니다. 그제서야 테스트 및 지표를 통해 큐가 병목이 아님을 확인해서 과한 설계를 적용하지 않게끔 돌아올 수 있었습니다.

귀찮다고 예측으로 넘겨짚지 말고 기본 지식을 쌓는 것이 중요했습니다!

[O+T] 홈 화면 인기 플레이리스트 API 개선하기

phonil — Sat, 9 May 2026 00:36:55 +0900

0. 개요

프로젝트를 진행하며 사용자가 보게 될 '플레이리스트' 구성에 있어 '시리즈'와 '시리즈가 아닌 콘텐츠' 구분 로직이 복잡했습니다. 특히, OTT 서비스의 홈 화면 API들은 자주 호출되기 때문에 사용자와 데이터가 많다면 병목이 있을 것이라고 예상했습니다.

따라서 K6 테스트 후 병목 지점을 수치로 확인하고, 원인 파악 및 개선 작업을 진행하기로 했습니다.

대표적으로

인기 차트 플레이리스트 조회
Top Tag(태그 기반) 플레이리스트 조회
시청 이력 플레이리스트 조회

위 세 가지 API가 홈 화면에서 호출됩니다.

겹치는 로직이 많아 인기 차트 플레이리스트 조회 중심으로 개선 과정을 정리했습니다.

테스트 환경

다른 요소들은 제외하고, 요청-응답 중심으로 간단하게 그림으로 나타내면 아래와 같습니다.

서버 스펙

자원	타입	vCPU	메모리	디스크/스토리지
user-api EC2	t3.micro	2	1 GiB	gp3 8GB
redis EC2	t3.micro	2	1 GiB	gp3 8GB
RDS MySQL	db.t3.micro	2	1 GiB	gp3 20GB

더미 데이터

스크립트를 작성하여 규모별로 데이터셋을 생성했습니다. Small/Mideum/Large/XLarge 4개로 구분했으며, 다양한 데이터 규모에서 문제 지점을 파악하기 위해 나눴습니다.

테스트 도구

부하 테스트를 위해 K6를 사용했습니다. 스크립트를 작성해서 VU 규모별로 테스트를 진행했습니다.

기본적으로 Prometheus, Grafana를 사용하여 메트릭을 수집하고, 대시보드에서 확인했습니다.
- 주로 CPU, Heap, HTTP/DB Connection 등 서버 자원을 확인하는 용도로 사용했습니다.

개선 전 테스트 결과

Large 데이터 셋 테스트 결과

XLarge 데이터 셋에서 K6 부하 테스트를 진행해보니 데이터가 많은 상태에서 긴 쿼리 + 많은 쿼리 + 많은 요청으로 인해 타임아웃이 발생하는 경우가 매우 많아 결과를 확인하기 어려웠습니다. 그래서 우선 Large로 부하 테스트 결과를 보고, 단 건 확인은 XLarge로 진행하기로 결정했습니다.

홈 화면의 API는 Large 데이터 셋에 데이터가 그리 많지 않음에도 응답 시간이 꽤 걸렸습니다. VU100 선에서 벌써 평균 응답 시간이 1.5초 이상 나타났습니다.

더 적은 데이터 셋에서는 모든 API의 Avg가 거의 비슷하게 나타났습니다. 비효율적인 쿼리가 있더라도 데이터 수가 적기 때문에 빠르게 실행되어 대부분 네트워크 왕복 시간만 필요했기 때문입니다.

1. 로직 파악

API 호출 결과, 생각보다 많은 쿼리가 발생했고, 소수의 긴 쿼리가 존재했습니다. 흐름을 파악하고 쿼리 수를 줄이기 위해 API의 로직을 먼저 정리했습니다.

하나의 흐름으로 보면 위 그림과 같고, 붉은 색으로 표시된 부분에서 가장 긴 두 쿼리와 N+1 문제가 발생합니다.

첫 번째 쿼리

ACTIVE/PUBLIC/COMPLETED 상태 필터링
시리즈/단편 콘텐츠 필터링
미디어 북마크 순 정렬
상위 20개 반환

두 번째 쿼리

페이지네이션 시 Page 인터페이스 사용으로 인한 count() 쿼리 발생

N+1 문제

가져온 콘텐츠가 시리즈일 경우 이어보기 지점 표시를 위해 해당 시리즈의 모든 콘텐츠 중 가장 최근 시청 미디어를 찾아야 함
첫 번째 쿼리에서 가져온 미디어 수만큼 반복

이어보기 지점이라 함은 이렇게 포스터 아래에 표시되는 시청 기록을 말합니다.

2. 쿼리 및 로직 개선

인기 차트 플레이리스트 API를 포스트맨으로 호출해 로그를 확인했습니다. 응답 시간은 약 11초 정도 걸렸습니다.

2개의 주요 쿼리와 N+1 쿼리로 인해 상당한 지연이 발생했습니다.

2-1. 1번 쿼리: 3096ms

INFO 528 --- [io-8080-exec-10] p6spy : [STATEMENT] | 3096 ms |
    select
        m1_0.id,
        m1_0.bookmark_count,
        ...
    from media m1_0
    where 
        m1_0.status='ACTIVE' and m1_0.public_status='PUBLIC' and m1_0.media_status='COMPLETED'
        and (
            m1_0.media_type='SERIES'
            or m1_0.media_type='CONTENTS' 
            and not exists(select 1 from contents c1_0 where c1_0.media_id=m1_0.id and c1_0.series_id is not null)
        )
    order by m1_0.bookmark_count desc
    limit 0, 20

쿼리 한 번에 3096ms가 걸렸고, 이를 분석하고자 Explain (+ Analyze)를 통해 실행 계획을 확인해봤습니다.

크게 두 가지 문제로 인해 쿼리 실행 시간이 길어짐을 확인할 수 있었습니다.

문제 1. 수많은 서브쿼리 Loop

콘텐츠가 시리즈의 에피소드인 경우와 시리즈가 아닌 단편 영화와 같은 일반 콘텐츠인 경우를 확실하게 구분지어야 하는데,

시리즈에 소속된 에피소드를 제거하기 위한 조건으로 Where절 안에 OR + 서브쿼리가 필요했습니다.

플레이리스트에 구성되는 콘텐츠는 '더글로리 1화'와 같은 단독 에피소드가 아닌, 시리즈 단위 혹은 단편 영화와 같은 콘텐츠가 되어야 하기 때문입니다.

Explain Analyze 결과를 보면, NOT EXISTS 서브쿼리의 loop 횟수가 240,070회에 달합니다.

-> Select #2 (subquery in condition; dependent)
    -> Single-row index lookup on c1_0 using uk_contents_media (media_id=m1_0.id)
       (actual time=0.00846..0.00846 rows=1 loops=240070)

서브쿼리 1회 실행은 유니크 인덱스 lookup이라 약 0.00846ms로 빠르지만, 이것이 24만 번 반복되면 약 2초가 소모됩니다. 전체 쿼리 시간 중 풀스캔이 865ms, 나머지 약 2초가 이 서브쿼리 반복에서 발생한 것입니다.

상관 서브쿼리와 Anti-Join

현재 NOT EXISTS 내부의 서브쿼리는 외부 테이블(Media)의 현재 행을 참조하는 상관 서브쿼리로, Media의 행마다 Contents를 반복하며 조회합니다. 이는 외부 행이 바뀔 때마다 매번 다시 실행되어야 합니다.

하지만, MySQL 옵티마이저는 NOT EXISTS 상관 서브쿼리를 Anti-Join으로 변환하는 최적화를 지원하기 때문에 상관 서브쿼리 자체가 문제는 아닙니다.

Anti-Join은 두 테이블을 한 번 조인하여 매칭되지 않는 행만 남기는 연산입니다. 행마다 서브쿼리를 반복하는 것이 아니라 media 전체와 contents 전체를 한 번에 매칭하는 하나의 조인 동작으로 바뀌는 것입니다.

이 최적화가 적용되었다면 24만 건의 loop는 발생하지 않았을 것입니다.

OR 조건

문제는 NOT EXISTS가 OR 조건 안에 감싸져 있기 때문에 발생했습니다.

MySQL의 세미조인/안티조인 최적화는 서브쿼리가 WHERE 최상위 레벨에 AND로 연결되어 있을 때 적용됩니다. OR 안에 들어가는 순간 옵티마이저가 Anti-Join 변환을 수행하기 어려워져 의도한 대로 동작하지 않을 수 있습니다.

Anti-Join은 이 테이블 전체와 저 테이블 전체를 한 번에 매칭하는 연산입니다. 그런데 OR 조건이 있으면

media_type = 'SERIES'인 행    → contents 조인 자체가 필요 없음
media_type = 'CONTENTS'인 행  → contents 조인이 필요함

행마다 조인을 해야 할지 말아야 할지가 달라집니다. 조인을 할지 말지 행 단위로 분기하는 것은 조인 연산의 구조와 맞지 않기 때문에, 옵티마이저는 Anti-Join 변환을 포기하고 원래 의미 그대로 행 하나씩 서브쿼리를 평가하는 Dependent Subquery로 실행하게 됩니다.

정리

요소	단독으로 문제인가	이유
상관 서브쿼리	X	Anti-Join 최적화 가능
NOT EXISTS	X	Anti-Join 최적화 가능
OR + NOT EXISTS	O	Anti-Join 최적화 차단 → 행마다 서브쿼리 반복

결국 상관 서브쿼리 자체가 아니라, OR 조건이 Anti-Join 최적화를 차단하여 상관 서브쿼리가 행마다 반복 실행되는 것이 문제입니다. 실행 계획에서는 50만 행 중 media_type='CONTENTS'인 약 24만 행 각각에 대해 서브쿼리가 1번씩 실행되어, loops=240,070이라는 수치가 나타난 것입니다.

해결 방안 1. 반정규화 ✅

Media 테이블에 단독 콘텐츠임을 나타내는 is_standalone 컬럼을 추가하여 혼자 노출될 수 있는지(Series/단편 Contents) 표시하는 방법입니다. 이를 통해 Media 테이블만 보고도 플레이리스트 포함 여부를 찾아갈 수 있게 됩니다.

WHERE m1_0.status = 'ACTIVE'
  AND m1_0.public_status = 'PUBLIC'
  AND m1_0.media_status = 'COMPLETED'
  AND m1_0.is_standalone = true

장점: NOT EXISTS 완전 제거 / 인덱스 포함 가능

단점: 콘텐츠 수정 시 동기화 필요

팀에서는 해당 방식인 반정규화를 선택했습니다. 그 이유로 아래 세 가지가 대표적입니다.

OR과 NOT EXISTS 근본적 제거
필요 시 인덱스 포함 가능
백오피스에서 가능한 미디어 수정은 자주 일어나지 않음

OR과 NOT EXISTS가 모두 사라지므로, 서브쿼리 루프 240,070회가 0회가 됩니다. 또한, WHERE 필터링만 남기 때문에 복합 인덱스를 구성하면 풀스캔과 filesort까지 함께 해결할 수 있습니다.

단점은 반정규화로 인한 동기화입니다. 콘텐츠가 시리즈에 편입되거나 시리즈에서 빠질 때 is_standalone 값을 함께 갱신해야 합니다. 이 동기화가 누락되면 플레이리스트에 에피소드가 노출되거나, 반대로 단편 콘텐츠가 누락되는 정합성 문제가 발생합니다.

다만, 이 프로젝트에서는 미디어 수정이 백오피스에서만 이루어지고, 그 빈도가 낮기 때문에 동기화 비용 대비 조회 성능 이득이 더 크다고 판단하여 이 방식을 선택했습니다.

Media_Type에 EPISODE를 추가하여 Contents의 타입을 에피소드/단편으로 세분화하는 것(해결 2)이 더 근본적인 해결 방법이라고 생각했습니다. 하지만, 현재 다른 API 로직에서 매우 많이 사용 중이므로 변경 범위가 상당히 컸기 때문에 컬럼을 기존 로직 수정을 최소화 할 수 있도록 컬럼을 추가하는 방식으로 결정했습니다.

해결 방안 2. Media_Type에 EPISODE 추가

Media_Type을 세분화하여 Contents를 EPISODE/CONTENTS로 분리하는 방식입니다. 현재는 Media_Type이 SERIES/CONTETNS/SHORT_FORM 이렇게 세 가지가 존재하며, CONTENTS 타입에 에피소드와 단일 콘텐츠가 모두 존재합니다.

WHERE m1_0.status = 'ACTIVE'
  AND m1_0.public_status = 'PUBLIC'
  AND m1_0.media_status = 'COMPLETED'
  AND m1_0.media_type IN ('SERIES', 'CONTENTS')

장점: 도메인 의미 명확 / NOT EXISTS 완전 제거

단점: 기존 Contents 참조하는 코드 모두 수정 / 영향 범위 큼

반정규화와 마찬가지로 OR과 NOT EXISTS가 완전히 사라집니다. 에피소드인지 아닌지가 타입 자체에 표현되어 있는 가장 정석적인 해결 방법입니다.

하지만, Media_Type은 현재 프로젝트 전반에 걸쳐 매우 광범위하게 참조되고 있었습니다. media_type = 'CONTENTS'로 분기하는 모든 코드에서 EPISODE를 함께 고려해야 하고, QueryDSL 조건, Enum 클래스, 프론트엔드 분기 등 변경 범위가 상당히 컸기 때문에 이번 시점에서는 선택하지 않았습니다.

가장 정석적인 해결 방법이라고 생각하지만, 앞서 정리한 것처럼 변경 사항이 너무 많아지기 때문에 지금 시점에서는 변경 범위가 적은 방안을 선택하고자 해당 방식을 선택하지 않았습니다.

해결 방안 3. Union All 사용

Series 쿼리와 단독 Contents 쿼리를 분리하여 OR을 제거하고, UNION ALL로 합치는 방식입니다.

OR 조건을 UNION ALL로 분리하면 각 서브쿼리가 독립적인 WHERE 절에 AND로 연결되므로, Anti-Join 최적화가 적용될 가능성이 생깁니다.

장점: 스키마 변경 x

단점: OR는 분리하지만, NOT EXISTS 자체가 남음 / 쿼리 2개로 복잡함

-- 변경 후 쿼리
(
    SELECT
        m1_0.id, m1_0.bookmark_count, m1_0.created_date, ...
    FROM media m1_0
    WHERE m1_0.status = 'ACTIVE'
      AND m1_0.public_status = 'PUBLIC'
      AND m1_0.media_status = 'COMPLETED'
      AND m1_0.media_type = 'SERIES'
)
UNION ALL
(
    SELECT
        m1_0.id, m1_0.bookmark_count, m1_0.created_date, ...
    FROM media m1_0
    WHERE m1_0.status = 'ACTIVE'
      AND m1_0.public_status = 'PUBLIC'
      AND m1_0.media_status = 'COMPLETED'
      AND m1_0.media_type = 'CONTENTS'
      AND NOT EXISTS (
          SELECT 1 FROM contents c1_0 
          WHERE c1_0.media_id = m1_0.id 
            AND c1_0.series_id IS NOT NULL
      )
)
ORDER BY bookmark_count DESC
LIMIT 0, 20;

해당 방식은 스키마 변경이 없다는 큰 장점이 있지만, NOT EXISTS의 반복을 줄이지 못 한다는 한계가 있습니다. 현재 해결하고자 하는 문제는 OR 제거라기보단, OR를 비효율적으로 수행하는 서브쿼리 제거이므로 해당 방식은 선택하지 않았습니다.

OR이 사라지면서 두 번째 쿼리의 NOT EXISTS가 WHERE 최상위에 AND로 연결되므로, 옵티마이저가 Anti-Join으로 변환할 수 있는 구조가 됩니다. 스키마 변경 없이 쿼리만으로 개선할 수 있다는 점이 장점입니다.

하지만, Anti-Join 변환은 보장이 아닌 가능성입니다. 옵티마이저 버전, 테이블 통계 정보, 데이터 분포에 따라 여전히 Dependent Subquery로 실행될 수 있어서 EXPLAIN ANALYZE로 매번 확인이 필요합니다. 또한, NOT EXISTS 자체가 남아있으므로 쿼리 구조의 복잡성이 유지됩니다. 해결하고자 하는 핵심은 OR 제거가 아니라 서브쿼리 반복 실행의 제거이므로, 이를 구조적으로 보장하지 못하는 이 방식은 선택하지 않았습니다.

이와 비슷하게 Left Join으로 풀어내는 방식도 존재하지만, OR가 남아 있게 되어 옵티마이저가 효율적으로 처리하지 못 할 가능성이 존재합니다.

결국, or 조건을 없애고, 시리즈/콘텐츠 여부를 확정할 수 있도록 해 주어야 하는 문제였습니다.

적용

변경은 간단했습니다. 우선 컬럼 추가를 위해 Flyway를 작성하고, Media 엔티티에 컬럼을 추가했습니다.

저희는 QueryDSL로 쿼리를 작성하고 있었고, 이를 함수로 분리하여 표현하고 있었기 때문에 기존 로직(주석 부분)에서 새로 추가한 컬럼 확인 로직으로 변경해주면 바로 적용할 수 있었습니다.

private BooleanExpression isDisplayable() {
//	return media.mediaType.eq(MediaType.SERIES)
//		.or(media.mediaType.eq(MediaType.CONTENTS)
//			.and(JPAExpressions.selectOne()	
//				.from(contents)
//					.where(contents.media.id.eq(media.id)
//						.and(contents.series.isNotNull()))
//							.notExists()));
                return media.isStandalone.isTrue();
}

반정규화 후 API 호출을 해 보니 3096ms -> 1323ms로 감소한 것을 확인할 수 있었습니다.

INFO 34772 --- [nio-8080-exec-6] p6spy: [STATEMENT] | 1323 ms |
    select
        m1_0.id,
        m1_0.bookmark_count,
        ...
    from
        media m1_0
    where
        m1_0.status='ACTIVE'
        and m1_0.public_status='PUBLIC'
        and m1_0.media_status='COMPLETED'
        and m1_0.is_standalone=true
    order by
        m1_0.bookmark_count desc
    limit
        0, 20

문제 2. 테이블 풀 스캔 + Filesort

반정규화를 통해 OR과 서브쿼리를 없앴지만, 여전히 비효율적인 쿼리가 실행되었습니다.

WHERE 절의 조건들과 ORDER BY 컬럼에 인덱스가 없어 풀스캔을 진행합니다. 데이터를 추린 후에도 북마크 수 기반 정렬이 필요하기 때문에, 풀스캔 + filesort가 발생합니다.

모든 데이터에 접근하여 필터링해야 함
남은 데이터에 대해 정렬까지 진행해야 함

Where 조건 필터링을 위한 도움과 효율적인 정렬을 위한 도움이 필요했고, 인덱스를 통해 해결 가능했습니다.

선택: 인덱스 추가 ✅

idx_media_trending (Status, Public_Status, Media_Status, is_standalone, bookmark_count DESC) 인덱스를 추가하는 방법입니다.

bookmark_count는 보통 '인기 차트'같이 역순(높은 순)정렬로 쓰입니다. 정방향 인덱스를 걸어도 페이지 간은 양방향으로 연결되어 있기 때문에 역순 정렬에 도움이 되지만, 페이지 내부의 실제 데이터끼리는 단방향으로만 연결되어 있기 때문에 DESC를 걸어줍니다.

장점

카디널리티가 낮은 컬럼이지만, 복합 인덱스로 사용되어 필터링에 효과적으로 활용됨
인덱스로 인해 정렬된 상태를 유지하므로 매 조회 시 발생하는 File Sort가 사라질 것으로 예상

단점

인덱스 용량이 커짐
쓰기 비용 발생
- 앞 필터링 조건에 변화는 적지만, 북마크 수가 변할 때마다 bookmark_count가 재정렬되어야 함

필터링 조건들은 미디어가 사용자에게 노출되기 위한 최소한의 조건으로, 삭제 여부/공개 여부/트랜스코딩 완료 여부를 확인합니다. 이는 User-API 서버에서 제공하는 미디어들에 대해 대부분 적용하고 있으므로, 인덱스의 사용 범위가 매우 넓어 활용도가 높습니다.

O+T 서비스에서 북마크는 보고 싶은 목록을 구성하는 일종의 모음 폴더 역할을 합니다. 따라서 북마크는 좋아요, 시청 등보다 훨씬 적게 발생할 것이므로 쓰기 빈도에 비해 조회 빈도가 매우 높아 인덱스 설정이 효과적일 것이라고 판단했습니다.

적용

코드 상 변경은 없었고, 인덱스 추가 flyway를 작성했습니다. 따라서 Where절의 모든 컬럼이 인덱스의 선행 컬럼에 해당되며, Order By의 bookmark_count가 후행 컬럼으로 인덱스를 타게 됩니다.

모든 조건 및 정렬이 인덱스를 활용하여 1323ms -> 68ms로 감소한 것을 확인할 수 있습니다.

INFO 38628 --- [io-8080-exec-10] p6spy: [STATEMENT] | 68 ms |
    select
        m1_0.id,
        m1_0.bookmark_count,
        ...
    where
        m1_0.status='ACTIVE'
        and m1_0.public_status='PUBLIC'
        and m1_0.media_status='COMPLETED'
        and m1_0.is_standalone=true
    order by
        m1_0.bookmark_count desc
	...

개선 후 실행계획

테이블 풀 스캔 + Filesort에서 Index Condition(ICP)으로 변경되었으며, 전체적인 실행 시간도 매우 빨라졌습니다.

데이터 수와 환경에 따라 다르겠지만, 이렇게 가장 오래 걸렸던 첫 번째 쿼리가 3096ms -> 1323ms -> 68ms로 개선되었습니다.

2-2. 2번 쿼리: 3028ms

INFO 528 --- [io-8080-exec-10] p6spy : [STATEMENT] | 3028 ms |
    select count(m1_0.id) 
    from media m1_0
    where 
        m1_0.status='ACTIVE'
        and (m1_0.public_status='PUBLIC'
            and m1_0.media_status='COMPLETED')
        and (m1_0.media_type='SERIES'
            or m1_0.media_type='CONTENTS'
            and not exists(select 1 from contents c1_0 where c1_0.media_id=m1_0.id and c1_0.series_id is not null))

두 번째 쿼리는

1. Where 절 or 조건 + 서브쿼리

2. count() 함수

로 인해 시간이 오래 걸립니다. 앞에서 서브쿼리와 조건절 및 정렬에 대한 인덱스를 설정했지만, count 쿼리 자체는 전체 개수를 세는 것이기 때문에 비교적 속도가 느렸습니다.

count 쿼리 발생 이유는 Page<T>를 반환하려면 총 데이터 수(totalElements) 가 필요한데, Spring Data의 Page 인터페이스가 getTotalPages(), getTotalElements()를 제공하기 때문에 Repository에서 데이터 쿼리와 별도로 동일 조건의 COUNT 쿼리를 한 번 더 날려야 했기 때문입니다.

전체 요소 개수가 필요 없다면, 그리고 Page 인터페이스 대신 Slice 인터페이스를 사용하면 count 쿼리가 발생하지 않기 때문에 쿼리 개선보다 코드 변경을 통해 쿼리 자체를 없애는 방법을 택했습니다.

또한, 해당 서비스는 번호가 있는 페이지네이션을 제공하는 것이 아닌, 특정 개수만큼만 무한 스크롤 형식으로 전달하면 됐기 때문에 Slice 인터페이스를 사용할 수 있었습니다.

필요한 정보	Page	Slice
현재 페이지 데이터	O	O
다음 페이지 존재 여부	O (COUNT 기반)	O (limit+1 기반)
총 페이지 수	O	불필요
총 데이터 수	O	불필요

코드 변경

boolean hasNext = content.size() > pageable.getPageSize();
if (hasNext) {
        content = content.subList(0, pageable.getPageSize());
}
return new SliceImpl<>(content, pageable, hasNext);

Page 대신 Slice로 변경하며, 전체 수가 아닌 다음 페이지가 존재하는지 확인한 후 구현체인 SliceImpl을 응답합니다.

이렇게 다른 플레이리스트는 페이지네이션이 필요한 경우 Page 인터페이스 대신 Slice를 사용할 수 있었고, 인기 차트 플레이리스트 API의 경우에는 페이지네이션이 필요하지 않으므로 List를 사용하여 상위 20개의 Media를 반환합니다.

2-3. N+1 쿼리

앞의 가장 큰 두 개의 쿼리 개선을 진행했음에도 한 번의 API 호출에 최대 60개의 N+1 쿼리가 발생하여 응답 시간이 여전히 300ms 근처에 머물렀습니다.

왜 발생하는가

Trending API는 인기 미디어 목록을 조회합니다. 이 목록에는 시리즈와 단편 콘텐츠가 섞여 있습니다.

단편 콘텐츠는 그 자체가 재생 대상이므로 추가 조회가 필요 없습니다. 하지만 시리즈는 껍데기입니다. 시리즈 자체를 재생할 수는 없고, 그 안의 에피소드 중 하나를 재생해야 합니다.

그래서 시리즈마다 아래 내용을 결정해야 합니다

이 유저가 가장 최근에 본 에피소드가 있으면 → 그 에피소드의 Media ID (이어보기)
시청 이력이 아예 없으면 → 1화의 Media ID (처음부터 보기)

이 결정을 for문 안에서 시리즈마다 개별 쿼리로 하고 있었습니다.

따라서 조회된 미디어가 시리즈일 경우 N+1 문제가 발생합니다. 아래 흐름으로 진행됩니다.

시리즈의 경우 이어보기 지점 표시를 위해 시리즈 내 미디어 중 가장 최근에 시청한 미디어를 찾아야 함
Watch_History -> Contents -> Series -> Media
1번 쿼리에서 가져온 Media 개수 (20개)만큼 반복

기존 코드

for (Media media : mediaPage.getContent()) {
    if (media.getMediaType() == MediaType.SERIES) {
        // (1) 시리즈마다 시청 이력 조회 → 1회 쿼리
        Long targetId = watchHistoryRepository
            .findLatestContentMediaIdByMemberIdAndSeriesMediaId(memberId, media.getId())
            // (2) 이력 없으면 1화 조회 → 2회 쿼리 (데이터 + COUNT)
            .orElseGet(() -> getFirstEpisodeMediaId(media.getId()));
        mediaToTargetIdMap.put(media.getId(), targetId);
    } else {
        mediaToTargetIdMap.put(media.getId(), media.getId());
    }
}

위 for문이 조회된 Media의 수만큼 반복되는 것이 문제였습니다. 한 페이지에 20개의 미디어가 있고 전부 시리즈라면 루프가 20번 돌면서 매번 DB에 쿼리를 날리게 됩니다.

최대 60개의 쿼리가 발생하는 이유

쿼리	발생 조건	횟수
findLatestContentMediaIdByMemberIdAndSeriesMediaId	시리즈마다 "이 유저가 최근에 본 에피소드가 있나?" 확인 : 시리즈마다 1회	20회
getFirstEpisodeMediaId: 데이터 쿼리	시청 이력이 없으니 1화를 가져오러 감 : 시청 이력 없는 시리즈의 fallback	20회
getFirstEpisodeMediaId: Count 쿼리	fallback이 Page 인터페이스를 반환하므로 COUNT가 따라옴	20회
합계		60회

getFirstEpisodeMediaId는 내부적으로 contentsRepository.findBySeries_Media_Id...를 호출하는데, 이 함수가 Page<Contents>를 반환합니다. Page는 totalElements를 알아야 하므로 데이터 쿼리와 별도로 COUNT 쿼리가 한 번 더 나갑니다. 그래서 시청 이력이 없는 시리즈 하나당 2회, 총 40회가 여기서 발생합니다.

정리하자면

본질적 원인: for문 안에서 시리즈마다 개별 쿼리를 날림

악화 요인: 1화 조회가 Page 반환이라 불필요한 COUNT 쿼리까지 추가 발생

문제

시리즈 20개면 최대 60번 쿼리 발생
각 1ms ~ 3ms로 괜찮아 보이지만, 클라우드에서 네트워크 지연이 누적될 수 있음
쿼리 수만큼 DB 커넥션을 점유하므로 동시 요청이 몰리면 커넥션 풀 소모가 빨라짐

해결: IN절 일괄 조회 ✅

시리즈 ID를 하나씩 불러오던 기존 방식에서 한 번에 불러오는 방식으로 변경하여 해당 문제를 해결하기로 했습니다.

구체적인 단계는 아래와 같습니다.

1단계. 시리즈 ID 목록 모으기

for문에 들어가기 전에 조회된 미디어 중 시리즈만 골라서 ID 목록을 만듦
해당 목록이 IN절에 들어갈 값

2단계. 시청 이력 일괄 조회 (1회)

시리즈마다 1회씩 호출하던 기존 함수에서 목록을 한 번에 넘기는 함수로 교체하여 한 번에 조회
Map<시리즈MediaId, 최근시청에피소드MediaId>를 반환
쿼리 내부에서는 서브쿼리로 시리즈별 MAX(lastWatchedAt)인 행을 찾아 해당 에피소드의 Media ID를 가져옴

3단계. 시청 이력 없는 시리즈 -> 1화 일괄 조회 (1회)

2단계에서 시청 이력이 없는 시리즈(latestEpisodeMap에 키가 없는 것)를 골라내어 이 시리즈들의 1화를 역시 IN절로 한 번에 조회
기존 getFirstEpisodeMediaId는 Page<Contents>를 반환해서 Count 쿼리가 발생했지만, 새 메서드는 Map<Long, Long>을 직접 반환하므로 Count 쿼리가 발생하지 않음

4단계. 두 맵을 합쳐 최종 결과 만들기

이 for문은 이미 조회된 Map에서 값을 꺼내기만 하므로 쿼리가 발생하지 않음
시청 이력이 있는 시리즈 → latestEpisodeMap에서 가져옴
시청 이력이 없는 시리즈 → firstEpisodeMap에서 가져옴
단편 콘텐츠 → 자기 자신의 ID

쿼리 수 비교

항목	Before	After
시청 이력 조회	시리즈 수 x 1회 (20회)	1회 (IN절)
1화 fallback 조회	이력 없는 시리즈 x2회 (40회)	1회 (IN절, COUNT 없음)
총 쿼리 수	최대 60회	2회

루프에서 하나하나 조회하는 것을 없애고, 미리 IN절로 한 번에 조회한 후 루프 안에서는 별도의 조회 없도록 변경하여 쿼리 수가 확연히 줄어들었습니다.

대안 비교

방법	설명	이 상황에 적합한지
IN절 일괄 조회	시리즈 ID를 모아서 한 번에 조회	적합 - 조회 로직이 커스텀(최근 시청 에피소드)이라 직접 IN절로 제어해야 함
@BatchSize	지연 로딩 시 N개씩 묶어서 IN절 자동 생성	부적합 - JPA 연관관계 로딩용, 커스텀 비즈니스 쿼리에는 적용 불가
@EntityGraph / Fetch Join	연관관계를 즉시 로딩	부적합 - '시리즈 -> 최근 시청 에피소드'는 연관관계까 아닌 비즈니스 로직 기반 조회

이 경우 발생하는 많은 쿼리는 흔히 발생하는 JPA 지연 로딩으로 인한 N+1 문제와 달랐습니다. JPA로 인한 문제의 경우 주로 BatchSize나 Fetch Join 등으로 해결합니다. 하지만 이 경우의 N+1은 for문 안에서 커스텀 쿼리를 반복 호출하는 패턴입니다. '이 시리즈에서 이 유저가 가장 최근에 본 에피소드가 뭔지'는 엔티티 연관관계가 아니라 비즈니스 로직이므로, JPA 레벨의 자동 최적화가 적용되지 않습니다. 직접 IN절 쿼리를 작성하여 모아서 한 번에 쿼리를 날리는 방식으로 해결했습니다.

JPA로 인한 문제인지, 로직 상 쿼리 최적화가 가능한 부분인지를 먼저 살펴보고 그에 대한 적절한 해결책을 세우는 것이 중요했습니다.

3. 개선 결과

개선 전 Controller/Service 응답 시간

INFO 528 --- ... .PerformanceLoggingAspect: [SERVICE] PlaylistStrategyService.getPlaylists() 6457ms
INFO 528 --- ... .PerformanceLoggingAspect: [CONTROLLER] PlaylistController.getTrendingPlaylists() 6466ms

개선 후 Controller/Service 응답 시간

INFO 37396 --- ... .PerformanceLoggingAspect: [SERVICE] PlaylistStrategyService.getPlaylists() 51ms                                 : 
INFO 37396 --- ... .PerformanceLoggingAspect: [CONTROLLER] PlaylistController.getTrendingPlaylists() 64ms

AOP로 Controller/Service 계층의 응답 시간을 비교해봤습니다. 대략 6400ms정도 걸리던 API 응답 시간이 작업 후 60~80ms 정도로 개선된 것을 확인할 수 있었습니다.

또한, 쿼리 수 자체도 64개 -> 5개로 최소화하여, 필요한만큼만 DB에 접근하게 되었습니다.

이렇게 쿼리 속도 개선과 쿼리 수 감소가 함께 어우러져 전체 API 응답 시간이 줄어들었습니다.

4. 캐싱 도입

4-1. 배경

홈 화면은 메인 페이지로, 서비스를 사용하는 모든 사용자가 처음 진입하는 가장 트래픽이 많은 지점입니다. 따라서 해당 페이지의 응답 속도가 곧 사용자 경험과 연결됩니다.

현재 조회 구조는 단순하게 Client 요청 -> Server -> DB 쿼리 순서로 진행됩니다. 매 요청마다 DB를 거칩니다.

여기서 DB 쿼리 횟수 자체를 줄인다면 트래픽이 늘어났을 때 응답 속도가 더욱 안정적일 것이라고 생각했고, 캐싱을 도입하기 위한 조건들을 검토해보았습니다.

인기 차트 API는 아래 특성들을 가지고 있습니다.

읽기 비중이 높고, 변경에 둔감하다.(약간의 지연 허용)
- 차트가 변하는 시점은 북마크 수가 변동될 때이고, 조회 대비 쓰기 비율이 낮다.
- 북마크 특성 상 쓰기 비중이 극히 낮진 않지만, 이를 인기 차트에 반영하는 것은 변경에 둔감하다. OTT 서비스에서는 오히려 실시간성을 위해 변경 사항을 즉시 반영하는 것보다 주기적으로 갱신하는 것이 좋다.(해당 프로젝트의 기획이기도 함)
모든 사용자가 동일한 데이터를 본다.
- 개인화가 없기 때문에 유저 A와 유저 B의 응답이 동일하다.
- 100명이 동시에 요청해도 DB에서 꺼내오는 결과는 하나이다.
쿼리 개선이 완료되었다.
- 앞의 과정을 거쳐 한 번의 요청에서 발생하는 쿼리 수를 줄이고, 속도를 개선했다.
- 남은 병목은 트래픽에 따른 DB 쿼리 횟수이다.

높은 읽기 비중 + 변경 지연 허용 + 모든 사용자에게 동일한 데이터 제공이라는 조건을 바탕으로 캐싱을 도입하면 응답 속도를 더욱 개선할 수 있다고 생각했습니다.

4-2. 인기 차트 플레이리스트 정의

캐싱 방식을 결정하기 전에 인기 차트 플레이리스트에 대한 기획 확정이 필요했습니다. 인기 차트 플레이리스트는 북마크 수가 가장 높은 Media 20개를 제공합니다.

1. 북마크 수 기반 인기 차트 실시간 반영 vs 지연 허용

또한, 데이터가 즉시 반영되어야 하는지에 따라 구조가 달라질 수 있습니다. 마찬가지로 DB 업데이트에 이어 캐시 데이터도 업데이트 하는지에 대한 문제가 발생하기 때문입니다.

현재 서비스의 인기 차트 플레이리스트는 북마크 수 기반으로 제공됩니다. 북마크는 사용자 행동으로 인해 발생하는 데이터로, 이 데이터가 발생할 때마다 실시간으로 반영해서 사용자에게 제공하는 방식과 일정 주기마다 데이터를 갱신해서 플레이리스트를 구성하는 방식이 있습니다.

넷플릭스나 왓챠같은 OTT 서비스들은 (북마크 기반같은 단순한 로직이 아니겠지만) 즉시 반영하기보다 일정 주기마다 순위를 갱신합니다. OTT 서비스의 특성을 고려했을 때, 실시간 반영보단 한 번에 뭉텅이로 제공하는 것이 더 낫다고 판단했습니다.

이렇게 된다면 DB와 캐시는 항상 일관된 데이터를 유지할 필요는 없습니다. DB를 중심으로 모든 데이터를 관리하고, 시간 단위로 데이터를 캐싱하는 방식을 사용할 수 있습니다.

따라서 '인기 차트 플레이리스트는 일정 시간의 지연을 허용한다'로 결정했습니다.

2. 데이터 불일치 가능 여부

다중 서버 환경에서는 캐시 데이터 불일치 문제가 발생할 수 있습니다.

홈 화면에서 새로고침을 할 때마다 인기 차트 플레이리스트가 변경된다면 사용자 입장에서 혼란을 겪을 수 있을 것이라고 생각했습니다. 물건의 수량이나 결제와 같이 완전무결하게 데이터가 유지되어야 하는 서비스는 아니지만, 사용자 경험 측면에서 살펴보면 일관된 데이터를 제공하는 것이 좋습니다.

따라서 데이터 일치에 관해서 '사용자는 일관된 데이터를 받아야 한다'로 결정했습니다.

4-3. 캐싱 방식 결정

1. 로컬 캐시 단독 사용

각 서버마다 로컬 캐시를 두고, 요청 시 각자의 캐시에서 데이터를 확인하고 응답하는 방식입니다.

가장 큰 장점은 응답속도가 빠릅니다. 네트워크 지연 없이 각 서버의 메모리에서 바로 응답하기 때문입니다.

하지만, TTL 범위 내에서 일관된 데이터를 응답하지 않을 수 있습니다. 서버 1의 TTL이 먼저 만료되어 새로운 데이터를 가져오고, 서버 2는 아직 이전 데이터를 가지고 있을 때 응답 데이터의 차이가 나타납니다. 또한, Auto Scaling에 따라 새로운 서버 인스턴스가 생성되고, 캐시 데이터 구성 시 다른 서버들과 다른 데이터를 가지고 있을 수도 있습니다.

앞서 정의한 내용에 따르면 '데이터 불일치'를 허용하지 않았기 때문에 이러한 요구사항에서는 추가적인 갱신 방법을 도입하지 않는다면 사용하기 어려운 방식입니다.

2. 글로벌 캐시 사용 ✅

각 서버별 캐시가 아닌 Redis 혹은 Memcached와 같은 글로벌 캐시를 두어 요청이 올 때마다 모든 서버가 해당 캐시를 보고 데이터를 응답하는 방식입니다.

첫 번째 방식인 로컬 캐시에 비해 응답 속도는 느리지만, DB에 직접 접근하여 쿼리를 날리지 않고, 이미 가공된 데이터가 글로벌 캐시에 존재하기 때문에 충분히 응답 속도가 빠릅니다. 이 방식은 캐시 자체가 글로벌 캐시 하나만 존재하기 때문에 서버 캐시 간 데이터 불일치 문제가 해결됩니다.

단점은 운영 복잡도가 올라간다는 것입니다. 인프라 하나가 추가되기 때문입니다. 또한, 해당 글로벌 캐시가 SPOF가 된다는 점입니다. 모든 서버가 하나의 캐시를 보기 때문에 해당 서버의 장애 발생 시 모든 서버의 캐시가 동시에 사라지고, 전체 트래픽이 DB로 직행합니다.

3. 로컬 캐시 + Redis Pub/Sub

1번 방법처럼 각 인스턴스가 로컬 캐시를 유지하되, 데이터 변경 시 Redis Pub/Sub과 같은 메시징 시스템을 사용하여 모든 인스턴스에 캐시 무효화 이벤트를 발행하여 캐시를 동기화하는 방식입니다.

첫 번째 방법의 가장 큰 문제였던 데이터 일관성 문제가 개선됩니다. 변경이 발생하면 모든 인스턴스가 거의 동시에 캐시를 갱신하므로 인스턴스 간 차이가 최소화됩니다. 조회 시에는 로컬 캐시를 사용하므로 글로벌 캐시로의 네트워크 비용조차 아껴야 하는 트래픽이 쏟아지며 조회가 매우 빈번하게 발생하는 상황에서 유용하게 쓰입니다.

단점은 로컬 캐시를 사용함에도 Redis 의존성, 메시지 유실/중복 처리, Pub/Sub 구독 관리와 같은 복잡도가 높아진다는 것입니다. 또한, 일시적으로 구독이 끊기는 등 장애 상황에서의 대비로 캐시의 TTL 설정 또한 필요합니다.

해당 프로젝트는 앞서 정의한 것처럼 북마크 수의 '실시간 반영'이 필요하지 않고, 주기적인 갱신이 필요합니다. 따라서 사용자의 북마크 혹은 북마크 취소로 인한 랭킹 변동을 캐시 데이터에 즉 반영할 필요가 없습니다. 사실상 TTL 만료 시에만 메시지가 발행됩니다. 이렇게 매우 드물게 발생하는 작업을 위해 새로운 인프라를 추가하고, 관리 포인트를 늘리는 것이 부담될 수 있습니다.

네트워크 지연을 최소화하거나 Redis나 다른 메시징 시스템 등 이미 사용 중인 인프라가 존재하는 경우에는 충분히 고려할 만한 선택지라고 생각합니다.

4. 로컬 캐시 (L1) + 글로벌 캐시 (L2)

각 서버에 로컬 캐시를 두고, 모든 서버가 사용하는 글로벌 캐시도 두는 방식입니다. 요청이 들어오면 먼저 로컬 캐시(L1)를 확인하고, 미스 시 Redis(L2)를 조회하고, 그것도 미스면 DB를 조회하는 계층 구조입니다.

로컬 캐시의 속도와 글로벌 캐시의 일관성을 동시에 얻을 수 있습니다. L1 TTL을 짧게(ex. 1분), L2 TTL을 길게(ex. 5분) 설정하면 대부분의 요청은 L1에서 처리되고, L1 미스 시에도 DB까지 가지 않고 L2에서 응답합니다.

하지만 해당 API에서는 복잡도 대비 이점이 적습니다. TTL 내 적중률이 높은 상황에서 L1 미스가 발생하는 시점은 TTL 만료 직후뿐입니다. 이때 DB를 한 번 조회하는 것과 Redis를 한 번 조회하는 것의 차이는 미미합니다. 앞선 쿼리 개선 작업 이후 쿼리 자체가 큰 병목이 아닌 상황에서 L2 계층이 막아주는 DB 부하가 크지 않습니다.

결국, L1 TTL 관리, L2 TTL 관리, 계층 간 정합성, Redis 의존성까지 모두 안고 가면서 얻는 실질적 이점이 부족해 보입니다.

정리

방안	응답 속도	일관성	복잡도
로컬 캐시 단독	매우 빠름	TTL 내 불일치	최소
글로벌 캐시 단독	빠름	거의 일치	중간
로컬 캐시 + Redis Pub/Sub	매우 빠름	완전 일치	높음
L1 + L2 계층	빠름(TTL 짧음)	TTL 내 불일치	높음

팀에서는 데이터 일관성과 구현 및 관리 복잡도를 고려하여 글로벌 캐시와 로컬 캐시 + Redis Pub/Sub 중 고민하다가 글로벌 캐시를 사용하기로 결정했습니다.

로컬 캐시를 활용하는 방안을 여러 방면으로 고려해봤지만, 데이터 일치 문제와 이를 해결하기 위한 메시징 시스템은 오히려 과하다고 생각했습니다.

4-4. Memcached vs Redis

글로벌 캐시에 대표적으로 사용되는 Memcached와 Redis 두 가지를 검토했습니다.

Memcached는 단순한 Key-Value 인메모리 캐시입니다. 멀티스레드 기반으로 동작하며, 단순 캐싱 용도에 매우 빠르고 가볍습니다. 하지만, 자료구조가 단순 Key-Value뿐이며 영속성 기능이 존재하지 않는 등 부가적인 기능이 적습니다.

Redis는 다양한 자료구조를 지원하는 인메모리 데이터 스토어입니다. 캐시 외에도 다양한 용도로 사용 가능합니다. 풍부한 자료구조 (String, List, Set, Sorted Set, Hash ...)를 제공하며, 영속성 옵션 (AOF) 또한 존재합니다. 하지만, memcached보다 복잡도가 높다는 점도 존재합니다.

선택: Redis

Redis를 사용하기로 결정했고, 아래의 이유들을 고민했습니다.

확장 가능성: 현재는 단순 Key-Value 캐싱이지만, 다른 기능에서 Redis를 재사용할 가능성이 높습니다. 또한, 차후 차트 정렬을 Redis 자체에 맡기는 방식(Sorted Set)으로 전환하거나 시간 윈도우 trending을 도입할 경우 Redis의 다양한 자료구조가 적합하기 때문입니다.
학습: Spring Data Redis, Redisson, RedisTemplate 등 생태계가 풍부하고 학습 자료가 많습니다.

4-5. String vs Sorted Set(ZSET)

String 타입은 20개의 인기 차트에 대한 응답을 JSON 직렬화된 형태로 통째로 저장합니다.

미디어 플레이리스트는 응답은 ID만 필요한 게 아니라 제목, 썸네일 등 메타데이터까지 포함됩니다. JSON 형식으로 데이터를 통째로 캐싱하여 그대로 응답할 수 있어, 추가적인 DB 조회가 필요없습니다. 또한, GET/SET 두 가지 명령어를 사용하며 구현이 매우 단순합니다.

Sorted Set은 score로 정렬된 member들의 집합입니다. Media ID를 식별자로 미디어별 score를 기준으로 정렬된 형태를 유지합니다.

부분 갱신, 페이지네이션, score 범위 조회와 같은 ZSET 기능이 필요하지 않음

배치로 TOP 20을 통째 갱신 / 한 콘텐츠만 score 바꾸는 시나리오
인기 차트는 TOP 20 고정 노출 -> 11~20위 별도 페이지 x
score 범위 조회 불필요 -> '북마크 5000개 이상인 콘텐츠' 등 x

메타데이터 분리 운영

ZSET에는 contentId만 저장되므로 제목, 썸네일 등의 메타데이터는 별도 캐싱하거나 DB 조회 필요

ZSET의 강점이 활용되지 않음

자동 정렬은 좋지만, IN절은 순서를 보장하지 않으므로 추려진 데이터에 대해 DB에서 정렬 후 가져옴

이러한 이유로 String 타입에 JSON 형식으로 응답 페이로드를 모두 캐싱하기로 결정했습니다. 인기 차트 플레이리스트는 20개 뿐이며, 필요한 컬럼만 추려서 저장한다면 메모리에 큰 부담이 없을 것이라고 생각했습니다.

하지만, 실시간성이나 정교한 요청 등 결국 확장을 생각하면 ZSET을 고려하는 것이 좋을 것 같습니다.

4-6. 캐싱 전략

Cache Aside + Write Around

읽기 전략은 Cache Aside, 쓰기 전략은 Write Around를 선택했습니다.

그림처럼 사용자의 요청이 들어오면 바로 DB를 보는 것이 아닌 캐시를 먼저 확인합니다. 캐시에 데이터가 존재하면 바로 응답을 보내고, 그렇지 않다면 DB에서 데이터를 조회한 후 캐시에 저장하고, 사용자에게 응답 데이터를 보냅니다.

사용자의 북마크 설정 및 취소 행동이 발생하면 쓰기 작업이 시작됩니다. 앞서 일정 주기 간격으로 랭킹을 갱신하기로 결정했으므로 쓰기 작업을 바로 캐시에 반영하지 않고, RDB에만 반영합니다. 그리고 설정해 둔 캐시 데이터의 TTL이 만료되면 DB에서 새로운 랭킹을 받아 저장합니다.

TTL

TTL은 1시간으로 잡았습니다. 넷플릭스의 인기 순위를 살펴봐도 그 주기가 더 긴 것 같지만, 해당 프로젝트는 복합적인 요소가 아닌 북마크 수 기반이므로 너무 길게 잡지 않고 적당한 주기로 갱신하기로 결정했습니다.

적용

Spring의 @Cacheable을 Service 계층에 붙여주어 간단히 적용할 수 있었습니다.

@Cacheable(value = "trending", key = "#top20")
public TrendingPlaylistResponse getTrending() {
	// 북마크 수 Top 20 조회
}

캐시 스탬피드 문제

TTL 만료 시점에 동시에 여러 트래픽이 발생하는 경우 순간적으로 DB에 부하가 크게 발생할 수 있습니다. 쿼리 개선 후 진행되고 있고, 캐시를 사용하는 지점도 많지 않아 현재는 크게 문제가 되지 않지만, 캐시를 사용하는 부분이 많아진다면 응답 지연의 원인이 될 수 있습니다.

해결에는 Lock, PER, 논리적 만료 + 비동기 갱신, pre-warming 등 여러 방법이 존재합니다. 저는 간단하게 스케줄러를 통해 TTL보다 아주 약간 짧은 주기로 데이터를 갱신하도록 구성했습니다.

이 경우에는 다중 서버에서 스케줄러가 여러 번 실행되어 중복 갱신이 될 수 있으므로 ShedLock이나 분산 락으로 한 번만 실행되게 설정해줍니다.

5. 결과

캐시 히트 시 레디스에서 바로 꺼내오기 때문에 응답시간이 굉장히 빨라진 것을 확인할 수 있었습니다.

INFO 37396 --- ... .PerformanceLoggingAspect: [CONTROLLER] PlaylistController.getTrendingPlaylists() 4ms

시작 전과 동일한 VU 구성으로 부하 테스트를 해 봤습니다. 데이터 셋은 Large -> XLarge로 변해 개선 후가 훨씬 데이터가 많음에도 응답 속도가 빨라진 것을 확인할 수 있었습니다.

6. 마무리

다중 서버라고 무작정 인프라를 추가하는 방식보다 최대한 각 인스턴스의 로컬 자원을 활용할 수 있는 방법을 고민해봤습니다. 하나의 서버에서 사용할 수 있는 것을 최대한 사용하는 것이 좋다고 생각했습니다. 결국은 트래픽에 따라 조정할 일이고, 무언가 추가된다면 그에 따른 운영 비용이 발생할 수 있음을 체감했습니다.

기획적으로 결정된 사항에 알맞게 해결 방식을 결정하는 것도 중요했습니다. 프로젝트에서 기능을 구현하면서 시리즈/콘텐츠 쪽에 시간을 많이 사용했고, '인기 차트'를 정의하면서도 나름대로의 기준이 필요했습니다. 기획/설계 단계에서 실시간성이 짙은 인기 차트를 제공하고자 한다면 Redis의 자료구조 중 하나인 ZSET을 사용할 수도 있다는 말이 나왔던 기억이 있습니다. 기획이 모호하면 기술 결정에 어려움이 있을 것이라는 점을 다시 한 번 떠올렸습니다.

이번 개선 작업은 눈으로 확인할 수 있는 정보를 바탕으로 여러 대안을 하나씩 따져가며 진행했습니다. 마무리 단계에서 돌아보면 간단한 개선 작업이었지만, 선택한 방식 외에도 다른 방식들을 살펴볼 수 있었고, 그들보다 현재 방식을 선택한 이유를 찾고자 고민했기 때문에 생각보다 시간을 많이 사용한 것 같습니다.

[O+T] 테스트 준비하기

phonil — Tue, 28 Apr 2026 21:26:03 +0900

병목 지점 탐색 및 개선 결과 확인을 위해 테스트 환경을 구축한 내용입니다.

프로젝트 내에 병목 지점으로 의심되는 부분은 많지만, 막상 테스트를 진행하지 않아 정말 개선이 필요한 지점인지, 또, 어느 규모에서 얼마나 문제인지 구체적으로 알 수 없었습니다.

의심에 대한 가설을 세우고, 테스트를 진행하여 실제 병목 지점을 파악하고, 이유를 찾아가며 개선 후 검증하는 절차를 거쳐가며 문제 지점부터 해결까지 지표 기반으로 진행하고자 합니다.

( 가설 -> 테스트 -> 병목 지점 선정 -> 개선 -> 검증 -> 결과 )

User API 서버의 테스트 및 개선을 위한 환경 구축 과정을 기록합니다.

더미 데이터 준비

데이터 규모에 따라 응답 시간이 달라집니다. 너무 작거나 큰 규모의 데이터를 가진 환경에서는 정확한 문제 파악 및 개선 측정이 어렵습니다.
이 규모를 여러 프리셋으로 지정해놓고, 필요한만큼 변경해가며 테스트를 진행하기 위한 목적으로 스크립트를 작성했습니다.

데이터 선정

현재 프로젝트에는 총 26개의 테이블이 존재하는데, 21개의 테이블을 채우고, 관련 없다고 판단한 5개의 테이블은 빈 상태로 두었습니다.

시드 대상 (21개)

그룹	테이블	FK 의존	비고
메타데이터	category	없음	고정 데이터 직접 INSERT (seed-metadata.sql)
	tag	category	고정 데이터 직접 INSERT (seed-metadata.sql)
	mood_category	없음	V8에서 8개 시드됨 → 스킵
	mood_tag	mood_category	V8에서 31개 시드됨 → 스킵
회원	member	없음	최상위
	preferred_tag	member, tag	회원당 3~5개
	member_radar_preference	member (1:1)	회원당 1개
미디어	media	member	공통 부모
	series	media	media_type='SERIES'
	contents	media, series(nullable)	media_type='CONTENTS'
	short_form	media, series/contents(nullable)	media_type='SHORT_FORM'
	media_tag	media, tag	미디어당 2~4개
	media_mood_tag	media, mood_tag	미디어당 1~3개
	media_metrics	media (1:1)	미디어당 1개
상호작용	bookmark	member, media
	likes	member, media
	comment	member, contents	contents에만
시청	watch_history	member, contents	UK(member, contents)
	playback	member, contents	UK(member, contents)
	click_event	member, short_form
분위기	member_mood_refresh	member	회원당 0~1개

시드 제외 (5개)

아래 5개 테이블은 트랜스코딩 서버 관련 테이블이므로, User-Api 서버의 테스트 대상에서 제외했습니다.

테이블	제외 이유
ingest_job	트랜스코딩 파이프라인용
ingest_command	위와 동일
transcode_outbox	위와 동일
flyway_schema_history	Flyway 내부 관리용
shedlock	ShedLock 내부 잠금용

데이터 규모

데이터 규모를 프리셋별로 나눠, 점진적으로 테스트해 볼 수 있도록 구분했습니다.

프리셋별 규모

xl은 member 10,000 고정, 나머지 테이블만 large 대비 크기를 늘렸습니다. 요청 수는 VU로 조절이 가능하기 때문에, 늘리는 것이 의미 없다고 판단했습니다.

small / medium / large / xl로 구분하여 규모별로 데이터를 삽입할 수 있도록 구성했습니다.

테이블	small	medium	large	xl
member	100	1,000	10,000	10,000
category	고정	고정	고정	고정
tag	고정	고정	고정	고정
media	1,000	10,000	50,000	500,000
┗ series (10%)	100	1,000	5,000	50,000
┗ contents (60%)	600	6,000	30,000	300,000
┗ short_form (30%)	300	3,000	15,000	150,000
media_tag	3,000	30,000	150,000	1,500,000
media_mood_tag	2,000	20,000	100,000	1,000,000
media_metrics	1,000	10,000	50,000	500,000
preferred_tag	400	4,000	40,000	40,000
member_radar_preference	100	1,000	10,000	10,000
bookmark	5,000	50,000	200,000	2,000,000
likes	5,000	50,000	200,000	2,000,000
comment	3,000	30,000	100,000	1,000,000
watch_history	10,000	100,000	500,000	5,000,000
playback	5,000	50,000	200,000	2,000,000
click_event	3,000	30,000	100,000	1,000,000
member_mood_refresh	50	500	5,000	5,000

고정 메타데이터 (category / tag)

시드 스크립트로 직접 생성. OTT 서비스에 맞는 장르/테마 기반.

테스트 시나리오 작성

가장 접근이 잦고, 호출되는 API가 많은 홈 화면에 대한 테스트 시나리오를 작성했습니다.

총 4개의 API가 호출되며, 그 중 한 개의 API는 상황에 따라 세 가지로 분류되어 6개의 API를 시나리오에 포함시켰습니다.

1 iteration == 사용자가 홈 화면에 진입했을 때 호출되는 API 묶음으로 설정했습니다.

#	API	설명	예상 부하 특성
1	GET /playlists/trending	인기 차트	가벼움 (전체 사용자 동일, 캐싱 후보)
2	GET /playlists/recommend	OO님이 좋아할만한	무거움 (사용자별 동적 CASE WHEN 쿼리)
3	GET /playlists/tags/top?index=0	선호태그 1순위	중간 (사용자별 태그 기반 조회)
4	GET /playlists/tags/top?index=1	선호태그 2순위	중간
5	GET /playlists/tags/top?index=2	선호태그 3순위	중간
6	GET /playlists/history	시청이력	무거움 (조건부 JOIN + GROUP BY)

K6 스크립트

import http from 'k6/http';
import { check, group, sleep } from 'k6';
import { BASE_URL, THRESHOLDS, STAGES } from '../config.js';
import { getAuthHeaders } from '../helpers/auth.js';

// -------------------------------------------------------
// 시나리오: 홈 화면 진입
//
// 사용자가 홈 화면에 진입하면 프론트엔드가 6개 API를 호출한다.
// 이 시나리오는 1 iteration = 6 HTTP requests로 실제 동작을 시뮬레이션.
//
// 포함 API:
//   1. GET /playlists/trending         - 인기 차트 (북마크 수 기준 인기순)
//   2. GET /playlists/recommend        - OO님이 좋아할만한 (태그 가중치 기반 추천)
//   3. GET /playlists/tags/top?index=0 - 선호태그 1순위 콘텐츠
//   4. GET /playlists/tags/top?index=1 - 선호태그 2순위 콘텐츠
//   5. GET /playlists/tags/top?index=2 - 선호태그 3순위 콘텐츠
//   6. GET /playlists/history          - 시청이력 (최근 시청 영상 목록)
//
// 사용법:
//   k6 run --env LOAD=smoke k6/scenarios/home-screen.js       # 동작 확인
//   k6 run --env LOAD=vu100 k6/scenarios/home-screen.js       # VU 100
//   k6 run --env LOAD=vu1000 k6/scenarios/home-screen.js      # VU 1,000
//
//   # Grafana 모니터링 연동
//   k6 run --env LOAD=vu1000 --out influxdb=http://localhost:8086/k6 k6/scenarios/home-screen.js
//
//   # 결과 JSON 저장 (Before/After 비교용)
//   k6 run --env LOAD=vu1000 --out json=k6/results/before/home-screen-vu1000.json k6/scenarios/home-screen.js
//
// 주요 지표 해석:
//   http_req_duration            : 개별 API 응답 시간
//   http_req_duration{name:XXX}  : API별 응답 시간 (tag로 분리)
//   group_duration               : 홈 화면 전체 로드 시간 (6 request 묶음)
//   http_reqs                    : 초당 처리량 (RPS)
//   http_req_failed              : 에러율 (1% 미만이어야 정상)
//
// Before/After 비교 포인트:
//   - recommend의 p95가 가장 높을 것으로 예상 (동적 CASE WHEN 쿼리)
//   - history도 조건부 JOIN+GROUP BY로 높을 수 있음
//   - 개선 후 동일 VU로 재측정하여 개선율(%) 산출
// -------------------------------------------------------

export const options = {
    stages: STAGES[__ENV.LOAD || 'vu100'],
    thresholds: {
        ...THRESHOLDS,
        // API별 임계값 (tag name으로 분리 측정)
        // Before에서 이 기준을 넘기는 API = 개선 대상
        'http_req_duration{name:trending}':   ['p(95)<500'],
        'http_req_duration{name:recommend}':  ['p(95)<500'],
        'http_req_duration{name:tags_top_0}': ['p(95)<500'],
        'http_req_duration{name:tags_top_1}': ['p(95)<500'],
        'http_req_duration{name:tags_top_2}': ['p(95)<500'],
        'http_req_duration{name:history}':    ['p(95)<500'],
    },
};

export default function () {
    const params = getAuthHeaders();

    // -------------------------------------------------------
    // group: 홈 화면 전체를 하나의 묶음으로 측정
    // → group_duration 지표로 "홈 진입 1회 총 소요 시간" 확인 가능
    // → Grafana에서 group별 차트로 전체 로드 시간 추이 확인
    // -------------------------------------------------------
    group('홈 화면 진입', function () {

        // 1. 인기 차트
        // 북마크 수 기준 인기 콘텐츠. 모든 사용자 동일 결과 → 캐싱 후보.
        const trending = http.get(
            `${BASE_URL}/playlists/trending?page=0&size=20`,
            Object.assign({}, params, { tags: { name: 'trending' } })
        );
        check(trending, {
            '[trending] status 200': (r) => r.status === 200,
        });

        // 2. OO님이 좋아할만한 (추천 플레이리스트)
        // 사용자별 선호 태그 가중치 기반. 동적 CASE WHEN 쿼리 → 가장 무거울 것으로 예상.
        const recommend = http.get(
            `${BASE_URL}/playlists/recommend?page=0&size=20`,
            Object.assign({}, params, { tags: { name: 'recommend' } })
        );
        check(recommend, {
            '[recommend] status 200': (r) => r.status === 200,
        });

        // 3~5. 선호태그 순위별 top3 (index 0, 1, 2)
        // 사용자의 상위 3개 선호 태그별 콘텐츠 목록.
        // 홈 화면에서 3번 연속 호출됨.
        for (let i = 0; i < 3; i++) {
            const tagsTop = http.get(
                `${BASE_URL}/playlists/tags/top?index=${i}&page=0&size=20`,
                Object.assign({}, params, { tags: { name: `tags_top_${i}` } })
            );
            check(tagsTop, {
                [`[tags_top_${i}] status 200`]: (r) => r.status === 200,
            });
        }

        // 6. 시청이력 (최근 시청 영상 목록)
        // 조건부 JOIN + GROUP BY + MAX 서브쿼리 → 복잡 쿼리 개선 후보.
        const history = http.get(
            `${BASE_URL}/playlists/history?page=0&size=20`,
            Object.assign({}, params, { tags: { name: 'history' } })
        );
        check(history, {
            '[history] status 200': (r) => r.status === 200,
        });
    });

    // think time: 사용자가 홈 화면 결과를 보는 시간 (1초)
    // 제거하면 요청을 쉬지 않고 연속으로 쏨 → 순수 서버 처리 한계 측정
    sleep(1);
}

JWT 토큰 발급

해당 프로젝트는 카카오 로그인만을 제공하고, Spring Security + JWT를 사용했기 때문에, 요청 시 토큰이 필요했습니다.

'공유 토큰 사용 → 1명 데이터만 반복 조회 → 캐시 히트 비정상 → 결과 왜곡'이라는 문제가 있었기에 각 VU는 다른 사용자의 JWT를 사용하도록 구성했습니다.

VU 수	토큰 1000개 기준	상태
100	100명 각각 고유	이상적
500	500명 각각 고유	이상적
1,000	1:1 매핑	이상적
5,000	1명당 5 VU 공유	허용
10,000	1명당 10 VU 공유	허용

부하 테스트 자동화

매번 수동으로 데이터 규모별로, VU 프리셋별로 테스트를 진행하기엔 번거로움이 많았습니다. 그래서 테스트를 원하는 데이터 규모와 프리셋을 지정하면 자동으로 K6 테스트를 수행하고 그 결과를 JSON으로 저장하는 자동화 환경을 구성했습니다. 또한, 개선 후에도 비교하기 수월하도록 저장된 결과를 MD 문서로 보기 쉽게 정리하는 스크립트를 작성했습니다.

'DB 초기화 -> 데이터 생성 -> VU별 테스트 실행 -> 부하 테스트 결과 JSON 저장' 구조를 자동으로 반복하기에, 필요할 때마다 한 번만 실행시키고, 이를 바탕으로 결과 요약 스크립트를 실행시키면 .md 파일로 변환시킬 수 있습니다.

[파일 구조]

k6/
├── config.js                          ← 공통 설정 (URL, 임계값, VU 단계)
├── helpers/auth.js                    ← VU별 개별 JWT 토큰 관리
├── data/tokens.json                   ← 시드 사용자 1,000명 JWT (gitignore)
├── scenarios/home-screen.js           ← 홈 화면 시나리오 (6 API, 6 requests)
├── docker-compose.monitoring.yml      ← InfluxDB (k6 결과 저장)
├── run-all-before.ps1                 ← 일괄 측정 (PowerShell)
├── run-all-before.sh                  ← 일괄 측정 (Bash)
├── parse-results.ps1                  ← 결과 → md 보고서 (PowerShell)
├── parse-results.sh                   ← 결과 → md 보고서 (Bash)
└── results/                           ← 측정 결과
    ├── before/{seed}/summary-{vu}.json
    ├── before/report.md
    ├── after/{seed}/summary-{vu}.json
    └── after/report.md

[결과 요약 예시]

로깅

p6spy

API에서 발생하는 쿼리를 파악하기 위해 p6spy를 사용했습니다.

K6 부하 테스트로 병목 지점을 파악하고, 해당 API를 실행시켜 쿼리가 몇 번 나가고 얼마나 걸리는지, 어떤 쿼리가 나가는지를 확인하기 위함입니다.

2026-04-28T18:57:06.791+09:00  INFO 38132 --- [nio-8080-exec-6] p6spy : [STATEMENT] | 1 ms | 
    select
        m1_0.id,
        m1_0.bookmark_count,
        m1_0.created_date,
        ...
    from
        media m1_0 
    where
        m1_0.id=24508

AOP

p6spy와 더불어 Controller, Service 등 계층별로 소요되는 시간을 함께 파악하고자 AOP를 적용했습니다.

INFO 38132 --- [nio-8080-exec-1] c.o.c.web.aop.PerformanceLoggingAspect   : [SERVICE] PlaylistStrategyService.getPlaylists()  690ms
INFO 38132 --- [nio-8080-exec-1] c.o.c.web.aop.PerformanceLoggingAspect   : [CONTROLLER] PlaylistController.getHistoryPlaylists()  792ms

당장 쓰이진 않지만, 함수 단위로 호출 횟수와 소요 시간을 파악할 수 있고, 이를 기반으로 Grafana에서 확인 가능합니다.

모니터링

Prometheus와 Grafana로 지표를 확인하고 있습니다.

기본적인 JVM 리소스와 DB 커넥션, HTTP 통계를 확인할 수 있습니다.

위 기록은 데이터 규모 small, medium, large / VU 100, 500, 1000으로 3x3 테스트를 진행한 결과입니다.

다중 기기 환경에서의 푸시 알림

phonil — Thu, 3 Apr 2025 22:49:35 +0900

전시회 기록 서비스의 푸시 알림 중 다중 디바이스에 관한 내용입니다. 알림이 발생하는 상황들과 현재 상태를 소개하고, 다중 디바이스를 지원할 수 있는 설계로의 고민들을 적어보았습니다. 여러 기기에 알림을 보내는 것을 넘어 추가와 삭제, 업데이트를 고려하여 설계하고자 했습니다.

0. 소개

해당 서비스는 안드로이드 앱이며, 사용자에게 푸시 알림을 보내고 사용자는 서비스의 알림 탭에서 해당 알림을 조회할 수 있습니다. 푸시 알림이 어떤 상황에서 발생하는지, 단일 디바이스의 한계는 무엇이었는지를 알아본 후 다중 디바이스로의 변경을 중심으로 예외 상황(앱 삭제, 로그아웃 등)을 어떻게 처리했는지 등의 설계와 구현을 정리했습니다.

1) 단일 디바이스

기존 설계는 User 테이블에 fcm_token 컬럼을 두어 사용자의 기기를 식별하고, 푸시 알림을 보냈습니다. 그렇기에 한 명의 회원은 하나의 기기만을 갖고 있다는 가정으로 구현되어 있습니다. 사용자가 새로운 기기에서 앱을 사용하면 해당 토큰은 업데이트되어 이전 기기로는 푸시 알림이 가지 않게 됩니다.

@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
@Getter
public class User extends BaseEntity {
	@Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "user_id")
    private Long id;

    @Column(name = "nickname", unique = true, nullable = false)
    private String nickname;

    @Column(name = "fcm_token")
    private String fcmToken;
   
    //...
}

하지만, 평소에 사용하는 여러 앱들은 하나의 아이디로 여러 기기에서 사용하더라도 알림을 잘 보내곤 했습니다. 기존에는 하나의 사용자 계정이 한 기기만 사용한다고 가정해 알림을 처리했지만, 실제 사용 환경은 그렇지 않다는 점을 인식하고 여러 기기를 사용할 수 있도록 구조를 개선하게 되었습니다.

2) 알림 발생

서비스는 사용자의 활동에 따라, 그리고 전시회 일정에 따라 크게 두 가지로 분류하여 푸시 알림을 전송합니다.

사용자는 알림 탭에서 전송받은 푸시 알림의 자세한 내용을 확인할 수 있으며, 각 종류별 알림 수신 여부를 결정할 수 있습니다.

활동 알림

먼저, 활동 알림은 유저의 행위에 의해 발생하며, 4가지 경우로 나누어집니다.

타 유저가 나를 팔로우 한 경우
내가 팔로우 한 유저가 감상평을 남기는 경우
내가 팔로우 한 유저가 별점을 남기는 경우
내 감상평에 댓글이 달린 경우

전시 알림

전시 알림은 매일 정해진 시간에 발생하며, 2가지 경우로 나누어집니다.

관심 전시회로 설정했으며, 전시 시작 7일, 3일, 1일 전인 전시회에 대한 리마인드 알림
관심 전시회로 설정했으며, 댓글과 별점을 모두 남기지 않은 전시 종료 7일, 3일, 1일 전인 전시회에 대한 리마인드 알림

1. 다중 디바이스 지원으로 변경

User 테이블에 컬럼으로 fcm_token을 저장했기에, 여러 기기 토큰을 저장하지 못하여 다중 디바이스를 지원하지 못하는 점을 가장 먼저 해결해야 했습니다. 따라서, 우선 테이블 설계를 변경하여 다중 디바이스를 지원할 수 있도록 한 뒤 추가 고려 사항을 이야기 해보겠습니다.

1) 테이블 설계 변경

user 테이블에 있던 토큰을 분리하여 별도 테이블로 만들었습니다. 1:M 관계를 설정해, 유저 한 명에 대해 여러 기기의 토큰을 저장할 수 있습니다. token 컬럼은 Unique 제약 조건을 걸어주어 중복된 기기에 대한 write 작업이 발생하면 update할 수 있도록 해, 하나의 기기에 여러 유저가 존재하는 상황을 방지했습니다.

각 device_token 테이블에 알림 수신 여부를 넣어 기기별로 알림 수신 여부를 결정하도록 할 수도 있지만, 초기 요구사항에 따라 우선 사용자 단위 방식을 유지하기로 했습니다.

2) 기본적인 등록 및 알림 요청

테이블 설계 변경에 따라 유저가 가지고 있는 모든 기기에 푸시 알림을 보내야 합니다. 기존에 작성된 기기 토큰 저장 로직은 단순히 User 테이블의 fcm_token을 업데이트하는 형식이었는데, 기기 토큰의 존재 여부에 따라 수행할 작업이 변경될 필요가 있습니다.

변경된 테이블 구조에 따라 필수적인 로직들만 우선 변경하고, 아래에서 상황을 따져보며 변경 사항을 추가로 반영했습니다.

[토큰 등록]

@Transactional
public void registerToken(UserPrincipal userPrincipal, DeviceTokenReq deviceTokenReq) {
    User user = userService.validateUserByToken(userPrincipal);
    String token = deviceTokenReq.getDeviceToken();
    deviceTokenRepository.findByDeviceToken(token)
            .ifPresentOrElse(
                    existingToken -> existingToken.updateUser(user),
                    () -> {
                        DeviceToken deviceToken = DeviceToken.builder()
                                .user(user)
                                .deviceToken(token)
                                .build();
                        deviceTokenRepository.save(deviceToken);
                    }
            );
}

위와 같이 Unique한 token 컬럼으로 Device Token을 찾은 후에 존재하면 업데이트, 존재하지 않으면 삽입을 진행했습니다. 동시성을 생각하고 쿼리를 줄이고자 한다면 ON DUPLICATE KEY UPDATE 문으로 한 번에 수행할 수 있지만, 앱 특성 상 매우 드물게 발생하는 로직이기 때문에 도메인을 좀 더 활용하고 가독성을 높일 수 있는 방법으로 구현했습니다.

[푸시 알림 생성 요청]

// 기존 단일 기기 푸시 알림
fcmService.makeActiveAlarm(receiver.getFcmToken(), sender.getNickname() + " 님이 별점을 남겼어요");

// 여러 기기 푸시 알림
deviceTokenList.stream()
                    .map(DeviceToken::getDeviceToken)
                    .forEach(token -> fcmService.makeActiveAlarm(token, message));

푸시 알림을 생성할 때에도 마찬가지로 모든 기기에 대해 생성할 수 있도록 변경했습니다.

2. 생각해 볼 문제들

여러 기기를 허용하면 그만큼 사용자의 앱 사용 경우의 수가 늘어나게 됩니다. 이에 따라 여러 상황을 따져보아야 하는데, 계정(회원)과 기기(Device Token)의 관계를 위주로 살펴보면 여러 상황에 대비할 수 있습니다.

1개의 계정으로 여러 기기에서 접속한 경우
1개의 기기에서 여러 계정으로 접속한 경우
로그아웃?
앱 삭제 시

위 순서로 살펴보겠습니다.

1) 같은 유저, 다른 토큰

일반적인 흐름으로, 여러 기기에서 하나의 계정으로 접속한 경우입니다. 이렇게 되면 푸시 이벤트가 발생했을 때, 등록된 모든 기기에 푸시 알림이 전송됩니다. 이미 토큰을 가지고 있는 회원도, 추가로 등록할 수 있으므로 이상적인 상황입니다.

앞에서 변경한 테이블 구조에 따라 로그인 시 토큰 등록을 함께 수행하여 하나의 계정에 여러 기기를 등록하여 서비스를 사용할 수 있습니다.

2) 같은 토큰, 다른 유저

문제가 될 수 있는 상황으로, 하나의 기기에서 다른 아이디로 접속한 경우입니다. 하나의 기기에 여러 계정을 사용한 경우인데, 내 알림을 다른 사람이 받게 될 수 있다는 심각한 문제를 가지고 있습니다.

이러한 상황을 방지하기 위해 기기 토큰을 UK로 설정하여 로그인 시 토큰 등록을 함께 수행하는데, 이미 존재하는 토큰이 들어오는 경우 user_id(fk)를 변경하여 기기를 사용하는 계정이 유일할 수 있게끔 유지해야 합니다. 앞에서 소개한 등록 코드에 포함되어 있는 내용입니다.

3) 로그아웃

사용자가 로그아웃을 하는 경우입니다. 로그아웃 시 앱 관련 소식에 관심이 없다는 것으로 보아 푸시 알림을 보내지 않기로 결정했습니다. 앞에서 변경된 토큰 등록 코드와 등록 시 두 상황을 확인했는데, 이제는 토큰 삭제를 고려해야 합니다.

로그아웃을 했음에도 푸시 알림을 받게 되는 상황을 방지하기 위해서는 로그아웃 시 토큰 삭제를 함께 수행해야 합니다.

@Transactional
public void deleteToken(UserPrincipal userPrincipal, DeviceTokenReq deviceTokenReq) {
    User user = userService.validateUserByToken(userPrincipal);
    deviceTokenRepository.deleteByDeviceToken(deviceTokenReq.getDeviceToken());
}

위와 같이 계정이 아닌 기기 단위로 삭제를 수행합니다. 로그아웃 시 서버가 해당 기기를 알림 대상으로 계속 유지하면 개인 정보 노출 등의 문제가 생길 수 있습니다. 따라서 로그아웃은 단순한 세션 종료가 아니라 '푸시 수신 중단'이라는 의미도 포함되며, 이에 따라 기기 단위로 토큰을 제거하는 정책을 세웠습니다.

로그아웃 뿐만 아니라 회원 탈퇴의 경우에도 마찬가지로 알림을 보내면 안되므로 토큰 삭제가 필요합니다.

4) 앱 삭제

기기에서 앱 삭제 시에는 해당 기기로 푸시 알림이 보내지면 안됩니다. 토큰 삭제를 고려해야 한다는 점에서 로그아웃과 비슷한데, 서버는 앱 삭제 여부를 직접 알 수 없다는 충격적인 문제가 있습니다.

하지만, 기기에서 앱 삭제 여부를 알기 위해 푸시 알림을 활용할 수 있습니다. 서버에서 매일 주기적으로 삭제 확인을 위한 Silent Push를 보낸 후 응답을 통해 삭제 여부를 알아냅니다. FCM에 푸시 전송 시 응답으로 "이 토큰은 무효"라는 메시지가 오면 해당 응답을 기반으로 삭제하는 방법입니다.

// 매일 확인
@Scheduled(cron = "0 0 8 * * *")
public void sendSilentCheckPush() {
    List<DeviceToken> tokenList = deviceTokenRepository.findAll();
    int total = tokenList.size();
    tokenList.stream()
            .map(DeviceToken::getDeviceToken)
            .forEach(fcmService::sendSilentCheck);
}

// silent push 생성
public void sendSilentCheck(String token) {
    JSONObject jsonData = new JSONObject();
    jsonData.put(TYPE, SILENT_CHECK);

    JSONObject jsonMessage = new JSONObject();
    jsonMessage.put(TOKEN, token);
    jsonMessage.put(DATA, jsonData);

    JSONObject message = new JSONObject();
    message.put(MESSAGE, jsonMessage);

    pushAlarm(message);
}

// 만들어진 알림을 받아서 푸시
private void pushAlarm(JSONObject jsonMessage) {
    try {
        OkHttpClient okHttpClient = new OkHttpClient();
        Request request = new Request.Builder()
                .addHeader("Authorization", "Bearer " + getAccessToken())
                .addHeader("Content-Type", "application/json; UTF-8")
                .url(API_URL)
                .post(RequestBody.create(jsonMessage.toString(), MediaType.parse("application/json")))
                .build();
        Response response = okHttpClient.newCall(request).execute();
        String body = response.body().string();
        if (!response.isSuccessful() && body.contains(SILENT_PUSH_BODY))
            deleteDeviceToken(jsonMessage.getJSONObject(MESSAGE).getString(TOKEN));
    } catch (Exception e) {
        // ...
    }
}

@Scheduled를 사용하여 매일 Silent Push 알림을 보내도록 합니다. 푸시 알림을 생성하고, 이를 토대로 알림 서버에 요청을 보냅니다. 알림 요청의 응답에 따라 사용자가 앱을 삭제했는지(토큰이 유효한지) 알 수 있고, 만약 앱을 삭제했다면 해당 기기를 더 이상 서비스에서 관리하지 않기 위해 토큰을 삭제해줍니다. (Firebase Docs)

IOS는 푸시를 보내는 순간 Notification이 만들어지므로 추가적인 설정이 필요하다고 하는데, IOS와 다르게 Android는 Notification을 직접 만들기 때문에 이 경우에는 Notification 자체를 만들지 않으면 된다고 합니다. 즉, 안드로이드 개발자와 협의하여 Silent Push인 경우 아무 작업을 하지 않도록 하면 됩니다.

프로젝트를 진행하던 시기에 푸시 알림 기능은 막바지에 추가되어서 많은 사항을 고려하지 못했지만, 팀원들과 어느 정도 이야기를 해 본 부분이라 다중 디바이스를 포함해 푸시 알림에 대한 개선 방안은 마음에 품고 있었습니다. 토큰의 신선도 관리 혹은 다중 디바이스 상황에서도 활성 기기에만 푸시를 보내는 등 더욱 세밀한 관리가 들어가면 좋을 것 같다는 이야기까지 했었는데, 현재 서비스는 스토어에서 내려갔고, 사용자가 없기 때문에 다른 작업들을 먼저 하면 좋을 것 같다고 생각했습니다.

짧은 시간 동안 개발하기도 했고, 팀원이 개발한 내용이라 어렴풋이 알고 있었는데, 푸시 알림에 대해 어느 정도 알 수 있었습니다. 코드를 보니 개선점이 더 보이기도 하고, 사용자를 고려해서 늘 다양한 상황을 생각한 개발을 할 필요가 있다고 느낍니다.

참고 :

앱 삭제 여부 확인

상황별 조회수 성능을 위해 고려할 수 있는 것

phonil — Tue, 1 Apr 2025 18:27:59 +0900

이 글은 동시성 처리가 필요한 상황에서 서비스와 게시글의 특성을 통해 효율적으로 조회수를 카운팅 할 수 있는 방법에 대해 살펴봅니다. 동시성을 처리하는 가장 기본적인 작업만 되어 있는 상태부터 세분화하여 업데이트를 위한 락을 줄여가는 방식으로 전개됩니다.

이전 글에서 조회수 카운팅 관련하여 크게 두 가지 문제를 다뤄봤습니다. 하나는 맞춤형 집계를 위한 조회수 카운팅 정책 설정이고, 다른 하나는 여러 요청이 발생할 때의 동시성 문제입니다. 조회수 정책 관련 글과 동시성 처리 관련 글에서 각각의 내용을 확인하실 수 있습니다.

이번에는 사용자가 많아질 경우 게시글 조회마다 발생하는 조회수 업데이트로 인한 성능에 대한 이야기를 해보겠습니다. 현재, update쿼리를 직접 사용하여 업데이트 할 때, 레코드에 x락을 걸게 됩니다. 락의 발생이 많아질수록 성능은 저하되기 때문에 실시간성과 어느정도 타협하여 성능을 끌어올릴 수 있습니다.

0. 상황 정의

현재 서비스는 회원/비회원 모두가 사용 가능한 기술 블로그입니다. 동아리 부원만 회원 가입과 글 작성이 가능하고, 현재 부원은 80명 정도 존재합니다. 따라서 게시글 조회(Read)에 비해 게시글 작성(Write)은 확실히 적게 발생할 것임을 예상할 수 있습니다(요청이 많이 발생한다면!). 이에 따라 게시글 수에 비해 읽기 요청이 많다는 가정으로 진행하였습니다.

조회수 집계 정책에 대해 설정해 놓은 것이 있어 더더욱 문제가 발생할 가능성이 적지만, 집계 정책과 별도로 단순 +1 상황을 기준으로 성능 개선을 생각해보겠습니다.

기술 블로그 특성 상 특정 키워드 검색으로 방문을 가장 많이 합니다. 하지만, 이는 사용자마다 다르며, 예측이 매우 어렵기 때문에 배제하고자 합니다. 특정 키워드를 통해 어떤 게시글로 유입된 사용자가 다른 글을 조회하고자 한다면 주로 기술 블로그 메인 화면 최상단에 배치된 게시글을 조회할 것입니다. 현재는 최신 순으로 배치하며, 만약 다른 방식을 추가로 도입한다면 조건을 걸어 인기글로 지정된 가장 최근 게시글을 상단에 배치할 수 있습니다.

페이지 단위로 10개씩 메인 화면에 배치가 되므로 게시글 작성 시간을 고려하여 조회수 업데이트 방식을 살펴보겠습니다.

간단하게 테스트용 프로젝트를 생성하고 코드를 작성한 후 서버를 3개 띄운 뒤 추이 파악을 위한 테스트를 진행해보았습니다.

1. 모든 게시글 통합

1) 조회 시 DB 업데이트

동시성 처리를 진행한 현재 상태 그대로 진행하는 방식입니다. 모든 게시글을 조회할 때마다 바로 DB에 +1 업데이트 해줍니다.

딱히 처리해 줄 것이 없어 구현이 매우 간단하고, 저희 서비스처럼 사용자가 많지 않은 경우 적합합니다. 하지만 조회 요청이 많은 경우 매번 락 경합으로 인해 성능에 문제가 생길 가능성이 높습니다.

// repository
public interface PostRepository extends JpaRepository<Post, Long> {
    @Modifying
    @Query("UPDATE Post p SET p.viewCount = p.viewCount + 1 WHERE p.id = :postId")
    void incrementViewCount(@Param("postId") Long postId);
}

// service
@Transactional
public SuccessResponse<?> getPostDetail(Long postId) {
    Post post = postRepository.findById(postId).orElseThrow();
    postRepository.incrementViewCount(postId);
    // ...
}

Jmeter를 사용해 1분 간 테스트를 진행해보았습니다. 다만, 테스트용 프로젝트이며, 로컬 환경이므로 테스트 결과 값보단 다른 방식과의 추이를 비교하는 정도로 사용하면 좋을 것 같습니다.

해당 방식의 경우 사용자 요청 간 텀이 없을 때에 비해 텀이 있는 경우 평균 속도가 높은 것을 볼 수 있습니다. 텀으로 인해 전체 처리 속도는 느려졌지만, 비교적 느슨한 요청으로 인해 락 경합이 줄어들어 평균적인 속도가 빨라진 것입니다.

2) 카운팅 후 DB 업데이트

조회수를 바로 업데이트 하지 않고, 어딘가에 쌓아놓은 후 주기적으로 DB에 업데이트 하는 방법입니다. 서버마다 메모리에 조회수를 카운팅하는 방식과 Redis로 대표되는 저장소에 카운팅 후 업데이트 하는 방식이 대표적입니다.

서버마다 인 메모리 카운팅 -> DB 업데이트

게시글 조회 요청이 들어오면 각 서버는 메모리에 게시글 별 조회수를 카운팅하고, 주기적으로 DB에 업데이트 합니다. 이 경우, 각 서버에서 로컬 변수를 사용하거나 로컬 캐시에 저장하는 방법이 있습니다. 조회수는 단순 업데이트하는 간단한 작업이기 때문에 ConcurrentHashMap을 사용해보겠습니다.

// service
@Transactional
public SuccessResponse<?> getPostDetailInMemoryCount(Long postId) {
    Post post = postRepository.findById(postId).orElseThrow();
    inMemoryViewCountStore.increment(postId);
    // ...
}

@Component
public class InMemoryViewCountStore {
    private final ConcurrentHashMap<Long, AtomicInteger> viewCountMap = new ConcurrentHashMap<>();

    public void increment(Long postId) {
        viewCountMap.computeIfAbsent(postId, k -> new AtomicInteger(0)).incrementAndGet();
    }

    public Map<Long, AtomicInteger> getAllCounts() {
        return viewCountMap;
    }
}

// 주기적 update
@Scheduled(fixedRate = 10000)
@Transactional
public void flushToDb() {
    Map<Long, AtomicInteger> countMap = inMemoryViewCountStore.getAllCounts();
    if(countMap.isEmpty()) return;
    int increment = 0;
    for(Map.Entry<Long, AtomicInteger> entry : countMap.entrySet()){
        Long postId = entry.getKey();
        increment = entry.getValue().getAndSet(0);
        if(increment > 0)
            postRepository.incrementViewCount(postId, increment);
    }
    log.info("인메모리 조회수 반영 완료, 대상 {}건", increment);
}

ConcurrentHashMap과 AtomicInteger를 사용하여 원자적 연산을 가능하게 했습니다. ConcurrentHashMap과 AtomicInteger는 내부적으로 CAS 연산을 수행하기 때문에 여러 스레드가 동시에 값을 변화시켜도 lock-free 상태로 빠르고 안전하게 업데이트를 수행합니다. 정말정말 최악의 경우 스핀락이 걸려 무한히 돌게 될 수 있는데, 이 경우 제한 횟수를 두어 한계에 도달하면 block 후 처리하는 방식으로 해결할 수 있습니다.

각 서버마다 자체적으로 조회수를 카운팅하고 주기적으로 update 해주므로 update 쿼리 자체의 발생이 적습니다. 따라서 락 경합이 적어지고 이로 인한 성능 문제가 매우 줄어듭니다. 또한, 추가적인 인프라 구성이 필요 없기 때문에 이 방법 또한 간단하게 구현할 수 있습니다.

하지만, 조회수를 실시간으로 정확하게 제공하지 못한다는 단점이 있습니다. 사용자에게 보여지는 조회수는 중요하지 않은 경우가 많기 때문에 괜찮지만, 실시간성이 높아야 하는 경우 적합하지 않습니다. 또한, 사용 중인 서버가 죽을 때, 데이터 처리가 적절히 이뤄지지 않는다면 일부 누락될 수 있습니다. 데이터가 누락되면 안되는 서비스의 경우 Graceful Shotdown을 고려해야 합니다.

DB에서 락 경합 자체가 거의 없기 때문에 요청에 텀을 주지 않았을 때 엄청나게 처리량이 많아지는 것을 확인할 수 있습니다. 텀이 있을 때 역시 전반적으로 매우 빠른 속도를 보여줍니다.

Redis 카운팅 -> DB 업데이트

이 전 방식과 비슷한데, 각 서버에서 조회수를 카운팅하는 것이 아닌 Redis에 카운팅을 하고, 주기적으로 업데이트 하는 방법입니다.

작성한 기본적인 코드는 아래와 같습니다. Redis를 사용할 때, 주기적 Update를 스케줄링한다면 여러 서버에서 동시에 실행되지 않도록 방지하는 코드를 추가해야 합니다.

// service
@Transactional
public SuccessResponse<?> getPostDetailRedis(Long postId) {
    String key = "post:view:" + postId;
    redisUtil.increment(key);
    // ...
}

@RequiredArgsConstructor
@Component
public class RedisUtil {

    private final StringRedisTemplate stringRedisTemplate;
    
    public Set<String> scanKeys(String pattern) {
        Set<String> keys = new HashSet<>();
        ScanOptions options = ScanOptions.scanOptions().match(pattern).count(1000).build();
        Cursor<byte[]> cursor = stringRedisTemplate.getConnectionFactory().getConnection().scan(options);
        while (cursor.hasNext()) {
            keys.add(new String(cursor.next(), StandardCharsets.UTF_8));
        }
        try {
            cursor.close();
        } catch (Exception e) {
            //
        }
        return keys;
    }

    public Long increment(String key) {
        return stringRedisTemplate.opsForValue().increment(key, 1);
    }
    // ...
}

스케줄링 작업을 구성할 때 주의해야 할 또 다른 점은 DB 업데이트 시 redis 키를 삭제하면 안 된다는 것입니다. 키를 삭제할 때, 다른 서버에서 조회수 카운팅을 한다면 그만큼 데이터가 손실될 수 있기 때문입니다. 따라서 업데이트 시에는 키를 삭제하지 말고 값을 차감하는 방식으로 구현하는 것이 좋습니다.

// 주기적 update
@Slf4j
@Component
@RequiredArgsConstructor
public class RedisFlushScheduler {

    private final RedisUtil redisUtil;
    private final PostRepository postRepository;

    @Scheduled(fixedRate = 5000)
    @Transactional
    public void flushRedisCountsToDb() {
        Set<String> keys = redisUtil.scanKeys("post:view:*");
        if (keys.isEmpty()) return;
        for (String key : keys) {
            String value = redisUtil.getData(key);
            if (value != null) {
                int inc = Integer.parseInt(value);
                String[] parts = key.split(":");
                if (parts.length == 3) {
                    try {
                        Long postId = Long.parseLong(parts[2]);
                        if (inc > 0) {
                            postRepository.incrementViewCount(postId, inc);
                            redisUtil.decrement(key, inc);
                            // redisUtil.deleteData(key); 삭제하면 안됨!!
                            log.info("Redis 키 {}의 조회수 {}를 DB에 반영 완료", key, inc);
                        }
                    } catch (NumberFormatException e) {
                        log.error("키 {}에서 postId 파싱 실패", key, e);
                    }
                }
            }
        }
    }
}

모든 서버에서 레디스에 먼저 조회수를 올리고, DB 업데이트를 한 번만 수행하기 때문에 락으로 인한 충돌은 더욱 적어집니다. 하지만, 추가적인 인프라 구성이 필요하다는 점, 네트워크 병목이 생길 가능성이 높아진다는 점과 게시글이 많아질수록 레디스에서 관리해야 하는 데이터가 많아지기 때문에 자원 소모가 갈수록 커진다는 단점들이 있습니다.

이 방식도 마찬가지로 요청 간 텀이 없을 경우 처리량이 매우 많아집니다. 이전 방식보다 DB 업데이트는 적어지지만, 서버 개수가 3개 뿐이기 때문에 큰 의미는 없을 것 같습니다. 레디스를 사용하는 경우 레디스 자체가 단일 병목 지점이 될 수 있고, 네트워크를 거치는 시간이 길어지기 때문에 해당 사항 역시 고려해야 합니다.

2. 메인 페이지 게시글과 일반 게시글 분리

앞에서 살펴본 방법들을 조합하여 각각 메인 페이지에 노출될 게시글과 일반 게시글에 적용하는 방법을 사용할 수도 있습니다. 이렇게 된다면 실질적인 성능은 개선하고, 불필요한 메모리나 외부 자원 사용을 더욱 줄일 수 있습니다.

메인 페이지 게시글은 카운팅, 일반 게시글은 DB 업데이트

조회가 적을 것으로 예상되는 일반 게시글은 따로 처리하지 않고 바로 DB에 업데이트합니다. 메인 페이지에 노출될 최근 게시글은 위에서 살펴본 것처럼 따로 카운팅을 한 후 DB에 주기적으로 업데이트합니다. 이렇게 게시글을 둘로 나누어 작업하면 Redis에 올라갈 데이터의 양이 한정되기 때문에 자원 소모가 적다는 장점도 있습니다. 조회수가 몰릴 게시글은 당장의 정합성보다 성능이 중요할 수 있기 때문에 이렇게 나누어 적용하는 방식도 좋은 것 같습니다.

구현이 더욱 까다롭다는 점과 동기화 시 새로운 글 작성을 고려하여 key를 삭제하고 추가해줘야 한다는 주의점도 있습니다.

사용자가 많지도 않으며, 기술 블로그라는 서비스 특성 상 이번 글에서 살펴본 내용들을 적용하지는 않고 맨 처음 소개한 조회 시 바로 update 방식으로 유지할 것입니다. 하지만, 다른 서비스 혹은 사용자가 많은 경우라면 고민해 본 내용들을 효과적으로 적용할 수 있을 것 같습니다! 여러 경우를 함께 살펴보면서 흐릿했던 정보들이 조금은 뚜렷해진 느낌입니다.

조회수 카운팅 시 동시성 문제

phonil — Sun, 23 Mar 2025 13:25:31 +0900

이 글은 조회수 카운팅 시 동시성 문제에 대한 내용을 담고 있습니다. 동시성 문제를 해결하고 조회수를 정확히 카운팅하기 위해 사용할 수 있는 방법들에 대해 살펴봅니다. 특히, 잠금을 통해 해당 문제를 해결하는 여러 방법을 탐구하고 있습니다. 끝으로, 테스트 결과와 선택한 방식을 소개합니다.

현재, 게시글 조회 시 조회수를 +1 하는 형태로 카운팅하고 있습니다. 하지만, 동시에 여러 요청이 발생한다면 조회수 카운팅이 정확이 이루어지지 않을 수 있습니다. 이는 동일한 Row를 Update하는 과정에서 발생하는 Race Condition으로, 다양한 방법을 통해 해결할 수 있습니다.

자바에서 제공하는 키워드를 사용할 수 있으며, DB를 통해 동시성을 보장할 수도 있습니다. 자바에서 제공하는 synchronized, volatile, Atomic과 같은 키워드는 다중 서버 환경에서 정확하게 동시성을 보장하지 못 할 수 있다는 한계가 있습니다. 따라서 다중 서버 환경에서도 올바르게 동시성을 처리할 수 있는 방법들에 대해 살펴보고자 합니다.

비관적 락(Pessimistic Lock),
낙관적 락(Optimistic Lock),
직접 Update 쿼리,
분산 락

위 4가지 방법 위주로 살펴보고, 각 방법의 장/단점을 검토해, 서비스 특성에 맞추어 선택하여 적용해보겠습니다.

조회수 카운팅 정책에 관한 내용은 여기에서 볼 수 있습니다!

1. 동시성 문제

0) 현재 상태

비회원을 기준으로 현재 조회수 상승 코드를 살펴보겠습니다.

@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
@Getter
@Table(name = "post")
public class Post extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id", nullable = false)
    private Member member;

    @Column(name = "title")
    private String title;

    @Column(name = "view_count")
    @Min(value = 0)
    private Integer viewCount;
    
    // ...

    public void incrementViewCount() {
        this.viewCount++;
    }
}

// Service 계층 코드
@Transactional
public SuccessResponse<AnonymousPostDetailRes> getPostDetail(PostDetailParams postDetailParams) {
    Post post = postRepository.findById(postDetailParams.getPostId())
            .orElseThrow(() -> new ResourceNotFoundException());

    String cookieName = POST_COOKIE_NAME_PREFIX + postDetailParams.getPostId();
    Cookie existingCookie = WebUtils.getCookie(postDetailParams.getRequest(), cookieName);
    if (existingCookie == null) {
        post.incrementViewCount();
        Cookie newCookie = new Cookie(cookieName, POST_COOKIE_VALUE);
        postDetailParams.getResponse().addCookie(newCookie);
        // ...
    }
}

현재는 단순히 게시글 조회 후 viewCount++ 연산을 수행하고 저장하는 구조입니다.

이렇게 조회 쿼리와 update 쿼리가 각각 발생합니다. 이 경우 여러 요청이 동시에 들어왔을 때, 서로 다른 트랜잭션에서 동일한 viewCount 값을 기준으로 연산하여 조회수 카운팅이 제대로 되지 않을 수 있는 문제가 있습니다.

위 그림처럼 User1의 트랜잭션이 커밋되어 조회수 상승이 DB에 반영되기 전에 새로운 트랜잭션에서 Select를 하게 되고, 이 값을 바탕으로 조회수를 상승시킵니다. 따라서 User1의 변경 사항이 먼저 반영되고, User2의 변경 사항(조회수 = 11)이 이를 덮어쓰게 되는 것입니다. 의도한 바는 조회수 12지만, 11이라는 결과가 나타나게 됩니다.

100번의 조회를 테스트했을 때, 고작 11번만 카운팅되었습니다. 89번의 조회수 카운팅이 손실되었고, 요청이 더 많이 몰린다면 더 많은 양의 손실이 발생할 수 있습니다.

성능, 비용과의 조율이 필요하겠지만, 동시성 문제만을 놓고 보았을 때 이를 해결하기 위해서는 락(잠금)이 필요합니다. 다양한 방식이 있으니, 이에 대해 알아보고 적절한 방안을 선택하는 과정을 살펴보겠습니다.

1) 비관적 락

비관적 락은 이름에서 알 수 있듯이 강력한 락을 통해 동시성을 제어합니다. 동일한 데이터에 대해 동시에 여러 작업이 수행되지 않도록 락을 거는 방법입니다.

내부적으로 SELECT ... FOR UPDATE 쿼리를 사용하는데, @Lock 어노테이션을 사용하여 간단하게 구현할 수 있습니다.

public interface PostRepository extends JpaRepository<Post, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT p FROM Post p WHERE p.id = :postId")
    Optional<Post> findByIdForUpdate(@Param("postId") Long postId);
}

@Lock의 LockModeType를 통해 비관적 락으로 설정하고, @Query에 JPQL을 작성해줍니다.

실제 쿼리를 살펴보면 이전과는 다르게 for update가 포함되어 있습니다.

select ... for update를 사용하면 조회한 데이터(행)에 대해 트랜잭션이 종료될 때까지 X락을 걸어, 다른 트랜잭션에서 데이터를 읽거나 쓸 수 없게 됩니다. 단순 Select는 S락을 포함하지 않기 때문에 조회가 가능하지만, S락을 포함한 Select가 대기하게 됩니다.

만약 다른 트랜잭션이 S락을 가지고 데이터를 읽으려고 한다면 잠금이 해제될 때까지 대기하고, 잠금을 획득한 트랜잭션이 커밋 혹은 롤백되면 잠금이 해제되어 접근이 가능해집니다.

비관적 락을 사용하면 각 트랜잭션이 시작되고 조회할 때, 잠금이 걸리기 때문에 커밋 전 조회로 인해 발생하는 덮어쓰기 문제가 해결됩니다. 하지만, 한 번에 하나의 트랜잭션이 온전히 실행되기를 기다려야 하기 때문에 요청이 많은 경우 대기 시간이 길어져, 응답 시간이 길어질 수 있습니다.

데이터 정합성 측면에서는 가장 좋은 방법이라고 생각되나, 그만큼 성능을 포기해야 한다는 단점이 명확합니다. 데이터의 오차에 민감한 경우 성능을 조금 포기하더라도 정합성을 지키기 위해 사용하면 좋은 방법입니다.

2) 낙관적 락

비관적 락은 충돌 상황을 허용하나, 이를 감지하고 충돌이 발생했다면 어떻게 할 지 처리를 결정하는 방식입니다. @Lock 어노테이션과 Post 엔티티의 version 컬럼을 추가한 후 @Version 어노테이션 붙여 구현할 수 있으며, 데이터의 버전 정보를 사용합니다.

public interface PostRepository extends JpaRepository<Post, Long> {

    @Lock(LockModeType.OPTIMISTIC)
    @Query("SELECT p FROM Post p WHERE p.id = :postId")
    Optional<Post> findByIdForUpdate(@Param("postId") Long postId);
}

// Post 엔티티
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
@Getter
@Table(name = "post")
public class Post extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "view_count")
    @Min(value = 0)
    private Integer viewCount;
    
    @Version
    private Integer version;
    
    // ...
}

낙관적 락은 트랜잭션에서 조회 쿼리를 날릴 때 잠금을 걸지 않고, 트랜잭션이 커밋될 때 버전 정보를 비교하여 충돌 여부를 확인합니다.

쿼리를 살펴보면 update 시 version과 함께 검색하는 것을 볼 수 있습니다. 따로 락을 걸지 않고, 버전 충돌이 발생하면ObjectOptimisticLockingFailureException 예외를 발생시킵니다. 따라서 무시되기를 원치 않는다면 재시도 로직을 작성하여 예외 처리 로직을 작성해주어야 합니다.

낙관적 락을 사용하면 락을 걸지 않기 때문에 비관적 락에 비해 성능이 우수합니다. 하지만, 충돌 시 로직을 직접 작성해야 한다는 번거로움이 존재합니다. 또한, 충돌이 많을 경우 재시도 등 처리 로직을 여러 번 수행하게 되므로 충돌이 많지 않을 것으로 예상되는 상황일 때 사용하면 좋은 방법입니다.

3) Update 쿼리 직접 사용

update를 쿼리를 직접 날리는 방식으로 현재의 동시성 문제를 해결할 수도 있습니다. 마찬가지로 @Query에 JPQL을 작성해주고, @Modifying 어노테이션을 붙여줍니다.

public interface PostRepository extends JpaRepository<Post, Long> {

    @Modifying
    @Query("UPDATE Post p SET p.viewCount = p.viewCount + 1 WHERE p.id = :postId")
    void incrementViewCount(@Param("postId") Long postId);
}

// Service 계층 코드
@Transactional
public SuccessResponse<AnonymousPostDetailRes> getPostDetail(PostDetailParams postDetailParams) {
    String cookieName = POST_COOKIE_NAME_PREFIX + postDetailParams.getPostId();
    Cookie existingCookie = WebUtils.getCookie(postDetailParams.getRequest(), cookieName);
    if (existingCookie == null) {
        postRepository.incrementViewCount(postDetailParams.getPostId());
        Cookie newCookie = new Cookie(cookieName, POST_COOKIE_VALUE);
        postDetailParams.getResponse().addCookie(newCookie);
    }
    
	// ...
}

repository를 통해 바로 DB에 쿼리를 날려줍니다.

update 순간부터 락을 얻고, 커밋 후에 락을 해제하기 때문에 비교적 락 점유 시간이 짧습니다. 작성한 update 쿼리가 나타나는 것을 확인할 수 있습니다.

앞의 두 방법은 게시글 조회 후 애플리케이션 단에서 값을 수정했습니다. 따라서 커밋 전 조회 시 값이 올바르지 않다는 문제가 발생할 수 있었습니다. 하지만, 이 방식은 데이터베이스 단에서 값을 바로 수정하기 때문에 조회로 인한 데이터 충돌 문제가 발생하지 않습니다. 따라서 update 시 레코드에 x락을 걸어 커밋 전까지 사용하고, 이를 통해 효과적으로 동시성 처리를 할 수 있습니다.

4) 분산 락

분산 락은 중앙 시스템을 사용하여 경쟁 상황(Race Condition)에서의 충돌을 방지하는 방법입니다. 애플리케이션의 규모가 커지면서 DB가 여러 대로 늘어나게 된다면 다시 동시성 문제가 발생할 수 있는데, 이 때 분산락을 통해 해결할 수 있습니다.

분산 락은 다양한 방식으로 구현 가능한데, 대표적으로 MySQL의 네임드 락과 Redis를 사용하여 구현할 수 있습니다.

네임드 락

네임드 락은 데이터베이스를 통해 락을 획득하고, 다른 트랜잭션은 락이 해제된 이후에 획득할 수 있도록 합니다. MySQL에서 제공하는 GET_LOCK(lock_name, timeout) 함수를 사용하여 네임드 락을 획득할 수 있으며, 획득한 락은 RELEASE_LOCK(lock_name) 함수로 해제하거나 세션이 종료되면 자동으로 해제됩니다.

락 획득

락을 획득하기 위해서는 획득하려는 락의 이름과 TIMEOUT을 설정해주어야 합니다.

@Query(value = "select get_lock(:key, 3000)", nativeQuery = true)
void getLock(String key);

락 해제

락을 해제할 때는 해제할 락의 이름을 사용합니다.

@Query(value = "select release_lock(:key)", nativeQuery = true)
void releaseLock(@Param("key") String key);

네임드 락은 락을 획득하기 위해 커넥션을 유지해야 하므로 애플리케이션에서 데이터베이스에 대한 커넥션 풀이 부족할 수 있습니다.

Redis 사용

MySQL은 메인 저장소로 사용하는 경우가 많기 때문에 Redis를 사용하여 분산 락을 구현하는 경우도 많습니다. Redis를 사용하는 방법은 Lettuce와 Redisson으로 나뉩니다.

Lettuce

Lecttuce는 Spring에서 기본적으로 사용하는 Redis 클라이언트입니다. Lettuce를 사용 시에는 SETNX(SET if Not eXists)명령어를 사용해서 락을 생성하고, 성공한다면 락을 획득합니다. 락이 있는 동안 다른 노드가 똑같은 키로 SETNX를 시도하면 락을 획득하지 못하게 됩니다. 락이 필요한 작업을 마친 후에는 delete로 해당 키를 삭제합니다.

// 락 획득
public Boolean lock(Long key) {
    return redisTemplate
            .opsForValue()
            .setIfAbsent(generateKey(key), "lock", Duration.ofSeconds(3));
}

// 락 해제
public Boolean unlock(Long key) {
    return redisTemplate.delete(generateKey(key));
}

// 락 사용
Boolean isLockSuccess = redisUtil.lock(key);
if (Boolean.TRUE.equals(isLockSuccess)) {
    try {
        postRepository.incrementViewCount(postId);
    } finally {
        redisTemplate.delete(key); 
    }
}

Redisson

Redisson은 Redis 기반의 고급 Java 클라이언트로, 락 획득, 유지, 연장, 해제 등 다양한 기능을 편리하게 제공합니다. Redisson을 사용하기 위해서는 우선 build.gradle에 redisson 의존성을 추가해야 합니다.

RLock lock = redissonClient.getLock("post_view:" + postId);
boolean isLocked = lock.tryLock(1, 3, TimeUnit.SECONDS); // 락 획득
if (isLocked) {
    try {
        postRepository.incrementViewCount(postId);
    } finally {
        if (lock.isLocked() && lock.isHeldByCurrentThread()) 
		lock.unlock();
    }
}

getLock으로 락을 정의한 후, tryLock으로 락 획득을 시도할 시간과 획득 시 점유할 시간을 명시합니다.

점유한 시간이 끝나기 전에 작업이 종료되면 락을 해제해주어야 합니다. 락을 해제할 때에는 해제하려는 락이 현재 세션에서 사용 중인 것인지 확인하고 해제하는 것이 좋습니다.

2. 선택

비관적 락은 매번 락을 걸기 때문에 데이터 정합성은 훌륭하지만 성능 면에서 가장 떨어집니다.
낙관적 락은 정합성은 보장되지만, 충돌 시 복잡한 예외 처리 및 재시도 로직이 필요하며, 실시간성이 중요한 조회수에는 다소 부적합합니다.
직접 UPDATE 쿼리 방식은 명시적 쿼리를 통해 락을 짧게 유지하고, 성능과 정합성의 균형을 모두 갖춘 방식입니다.
분산 락은 분산 환경을 고려한 전략이지만, 현재 단일 DB 구조에서는 크게 필요하지 않습니다.

현재 동시성 처리를 하고자 하는 조회수 데이터는 정합성이 크게 중요하지 않고, 자원을 많이 투입하지 않아도 괜찮은 상태입니다. 따라서 데이터 정합성과 성능을 균형있게 챙길 수 있는 낙관적 락과 직접 Update 쿼리를 작성하는 방식 중 고민하였고, 아래와 같은 이유로 직접 Update 쿼리를 작성하는 방식을 선택했습니다.

낙관적 락
- 장점: 평소 충돌이 적으면 락 없이 빠르게 처리함.
- 단점: 충돌이 잦으면 여러 번 재시도해야 하므로 오히려 성능이 저하됨. 또한, 충돌 로직 핸들링(재시도, 예외 처리)을 직접 작성해야 함.
직접 Update 쿼리
- 장점: 구현이 단순하며, lock이 비교적 짧게 점유됨. DB 자체가 “view_count = view_count + 1” 연산 시 원자성을 보장하여 안전하게 처리함.
- 단점: 트래픽이 많아질 경우 DB 락 경합이 올라갈 수 있음. 그러나 트래픽이 한 번에 몰릴만한 서비스가 아니며, 조회수 증가 정도라면 대체로 문제가 크지 않을 가능성이 높음.

직접 Update 쿼리 방식 선택

충돌이 적을 것으로 예상되므로 낙관적 락도 괜찮았습니다. 하지만 충돌 시 재시도 및 예외 처리를 직접 작성해야 하며, 조회수를 활용하여 인기 글 노출 기능 등이 추가된다면 특정 글에서 충돌 시 성능 저하가 우려되었습니다. 특히, 최상단에 있는 게시글같이 접근하기 쉬운 경우 충돌 가능성이 높기 때문에 update 쿼리를 작성하는 방식으로 선택했습니다.

데이터베이스 책과 운영체제를 공부했던 기억들과 함께 다시 책을 펼쳐보고 적용해보았습니다. 주로 사용하는 MySQL에서의 S락과 X락 그리고 넥스트 키락과 같이 다른 동시성 제어 방법에 대해서도 살펴볼 수 있는 좋은 시간이었습니다.

회원과 비회원을 고려한 복합 조회수 카운팅 정책

phonil — Thu, 20 Mar 2025 21:08:18 +0900

이 글은 현재 리팩토링 중인 동아리 기술 블로그 서비스의 조회수 카운팅 정책에 대한 내용입니다. 다양한 정책이 존재할 때, 장/단점을 따져보며 필요한 정책을 채택하는 고민이 담겨있습니다. 회원과 비회원에게 각각 다른 정책을 적용하는 방식을 선택하였습니다.

1. 조회수 카운팅 정책

조회수를 어떻게 올릴까? 생각해보면 저는 단순히 조회마다 +1하는 방법이 가장 먼저 떠오릅니다. 이 경우 새로고침을 연타하여 조회수를 상승시켜 본 기억도 있습니다. 때에 따라 카운팅 정책을 알맞게 설정하여 예전의 저와 같은 행동으로 인해 발생하는 부정확한 조회수 문제를 방지할 수 있습니다. 아래에 소개하는 것처럼 다양한 방식으로 조회수 카운팅 정책을 설정할 수 있습니다.

1) 클릭 시 +1

현재 조회 수 카운팅 정책으로, MVP 개발을 위해 채택한 구현에 가장 부담없는 정책입니다. 단순히 게시글 조회 시 +1을 해주며, 회원/비회원 모두 동일하게 적용됩니다.

이 방식은 구현이 쉬우며, 어찌됐든 페이지의 총 조회수를 확인할 수 있다는 장점이 있습니다.

반면, 새로고침을 계속 하는 등 조회 수 어뷰징 문제가 발생할 수 있으며, 실제 방문자 수와는 거리가 멀어 과대 집계될 수 있다는 문제가 있습니다.

2) 쿠키 기반 제한

브라우저에 쿠키를 저장하여 일정 기간 내 중복 조회 방지하는 방법입니다. 요청 시 쿠키가 없다면 조회수를 상승시키고 쿠키를 발급합니다. 발급된 쿠키는 저장소에 저장하여 추후 요청 시 사용합니다. 요청 시 쿠키가 있다면 조회수를 상승시키지 않습니다.

따라서 쿠키가 저장되어 있는 동안에는 여러 번 조회하더라도 조회수가 상승하지 않습니다.

이 방식은 회원 유저뿐만 아니라 비회원 유저의 중복 조회도 방지할 수 있으며, IP 기반 제한처럼 다른 사용자임에도 동일한 사용자로 인식되지 않기 때문에 정확하다는 장점이 있습니다.

반면, 사용자가 브라우저 리셋을 하거나 쿠키를 삭제하는 등 제어할 수 없는 부분으로 인한 부정확한 카운팅이 존재할 수 있습니다.

3) IP 기반 제한

사용자의 IP를 기준으로 일정 시간 내 한 번만 카운팅하는 방법입니다. 사용자의 IP를 통해 해당 게시글의 방문 여부를 확인합니다. 만약 방문한 적이 없다면 저장소에 저장하고, 조회수를 카운팅 합니다. 이전에 방문한 적이 있다면 카운팅하지 않습니다.

이 방식은 회원과 비회원 모두 중복 조회 방지가 가능하며, 같은 IP를 사용하지 않는 경우 좋은 중복 조회 방지 방식입니다.

하지만, 여러 사용자임에도 하나의 IP로 묶여 같은 취급을 받기 때문에, 조회수가 카운팅되지 않는 경우가 많이 발생할 수 있습니다. 특히, 교내 동아리 서비스인만큼 같은 IP를 사용하는 학교 내에서 다수의 사용자가 접근할 가능성이 있는데, 이러한 경우 사용이 적합하지 않을 수 있습니다.

4) 세션 기반 제한

사용자의 세션 단위로 조회수를 카운팅합니다. 사용자가 처음 조회 시 세션 저장소에 세션 ID를 저장하고 조회수를 카운팅합니다. 이미 세션 저장소에 방문 기록이 있다면 카운팅하지 않습니다.

이는 세션이 유지되는 동안 중복 조회를 막아주는 효과가 있습니다.

이 방식은 세션을 통해 회원과 비회원 모두 적용 가능하다는 장점이 있습니다.

5) 사용자(로그인) 기반 제한

로그인 된 사용자의 id를 기반으로 조회수를 카운팅하는 방법입니다. 위 방식들과 마찬가지로 사용자의 방문 기록을 저장소에 저장합니다. 저장 여부를 통해 조회수를 카운팅합니다.

이 방식은 로그인 한 사용자에 한해 정확도 높은 조회수를 측정할 수 있지만, 비회원의 조회수 카운팅 제한할 수 없다는 문제가 있습니다.

해당 서비스는 동아리 부원만 회원가입하여 로그인 할 수 있기 때문에 조회의 경우 비회원 사용자가 훨씬 많이 존재합니다. 이러한 경우, 비회원의 조회에 더 신경을 써야 하므로 로그인 유저 기반 방식은 다소 부족함이 많습니다.

6) 복합(혼합) 정책

여러 정책을 복합적으로 사용하는 방식입니다. 동아리 기술 블로그 서비스는 부원들만 회원 가입이 가능합니다. 비회원은 게시글 조회가 가능하기 때문에 회원과 비회원을 나누어 관리할 수 있습니다. 회원의 경우 ID로 방문 기록을 확인하고, 비회원의 경우 쿠키나 IP 등 앞에서 설명한 방식으로 조회수 중복 상승을 방지할 수 있습니다.

이 방식은 상황에 맞게 조정할 수 있다는 점으로 인해 원하는 조회수 카운팅 방식을 만들기 좋습니다. 하지만, 따져 볼 것이 많기 때문에 구현에 불편함이 다소 존재할 수 있습니다.

각각의 사용자 유형(회원/비회원)에 대해 최대한 정확한 집계가 가능하기 때문에 회원에 대한 통계를 바탕으로 동아리 컨텐츠로 사용할 수 있으며, 비회원 역시 다양한 형태로 정보를 사용할 수 있습니다.

2. 선택

현재 프로젝트에서 글 작성은 회원만 가능하고, 조회는 회원과 비회원 모두 가능합니다. 이미 게시글 상세 조회 시에 회원과 비회원을 나누어 작업하고 있었고, 분리해서 처리한다면 더욱 정확한 조회수 카운팅 할 수 있을 것입니다. 따라서 회원은 ID, 비회원은 쿠키를 사용한 복합 정책을 사용하기로 했습니다. TTL은 2시간으로 설정해놓아 2시간 후 재방문하면 다시 조회수가 카운팅되도록 했습니다.

처음에는 회원 - ID 사용 / 비회원 - IP + 쿠키 사용 방식으로 계획했습니다. 쿠키와 IP를 함께 사용하면 IP 사용 방식의 단점인 같은 IP에 속한 다른 사용자의 조회를 무시한다는 점을 쿠키로 해결할 수 있었습니다. 하지만, 쿠키를 단일로 사용할 때의 문제인 사용자가 쿠키를 제어할 수 있다는 문제는 해결되지 않았습니다. 이렇게 되면 IP를 함께 검사하더라도 쿠키 여부에 따라 조회수 카운팅 여부가 결정되었습니다.

쿠키 o + IP o => 카운팅 x
쿠키 o + IP x => 카운팅 x
쿠키 x + IP o => +1 카운팅
쿠키 x + IP x => +1 카운팅

위와 같이 네 가지 경우로 나누어 따져볼 수 있는데, 사용자가 쿠키를 삭제할 수 있는 상황에서 IP를 검사하여 얻을 수 있는 것이 없습니다.

따라서 회원은 ID 사용, 비회원은 쿠키 사용 방식으로 조회수 카운팅 정책을 결정했습니다. 사용자가 쿠키를 삭제할 수 있다는 문제는 해결되지 않지만, 아직 조회수 집계로 생산하는 컨텐츠가 없기 때문에 비용을 줄이는 방안으로 선택했습니다. 조회수 수집 방식이 조금 더 면밀해져야 한다면 view용 조회수와 분석용 조회수를 나누어 수집하는 것도 좋을 것 같습니다.

회원의 경우 ID를 사용하는 것이 가장 효과적이며, 회원은 동아리 부원에 한정되기 때문에 저장소 공간 차지가 적습니다. 따라서 결정에 어려움이 없었지만, 비회원은 IP와 쿠키, 세션 중 선택해야 했습니다. 먼저, IP는 동일한 IP에서 접근하는 모든 조회를 카운팅하지 않기 때문에 학교라는 특징이 있는 서비스 특성 상 무시되는 카운팅이 많아질 것이라고 생각했습니다. 또한, IP와 세션은 별도 저장소를 필요로 하기 때문에 관리하는 데 사용되는 자원이 상대적으로 클 것입니다. 트래픽에 따라 달라지겠지만 회원과 다르게 비회원은 들어오는 요청이 매우 많이 늘어날 수 있기 때문입니다.

구현

조회수는 게시글 상세 조회 API를 기준으로 카운팅합니다. 현재 게시글 상세 조회 시 회원/비회원의 응답 값이 다르고, 이를 전략 패턴으로 구현하고 있습니다. Factory에서 회원/비회원인지 판별 후 그에 맞는 Service를 반환하고, 게시글 상세 조회 응답을 전달합니다.

각자에게 맞는 서비스에서 게시글 상세 응답을 구성합니다. 게시글 상세 조회와 함께 조회수를 카운팅하는데, 알맞은 정책에 따라 업데이트 여부를 결정합니다.

비회원

[ AnonymousPostDetailServiceImpl.java ]

@Transactional
public SuccessResponse<AnonymousPostDetailRes> getPostDetail(PostDetailParams postDetailParams) {
    Post post = postRepository.findById(postDetailParams.getPostId())
            .orElseThrow(() -> new ResourceNotFoundException());

    String cookieName = POST_COOKIE_NAME_PREFIX + postDetailParams.getPostId();
    Cookie existingCookie = WebUtils.getCookie(postDetailParams.getRequest(), cookieName);
    if (existingCookie == null) {
        post.incrementViewCount();
        Cookie newCookie = new Cookie(cookieName, POST_COOKIE_VALUE);
        newCookie.setPath(COOKIE_PATH);
        newCookie.setMaxAge(COOKIE_AGE);
        newCookie.setHttpOnly(true);
        postDetailParams.getResponse().addCookie(newCookie);
    }

    List<String> tagNameList = taggingRepository.findByPost(post).stream()
            .map(tagging -> tagging.getTag().getName())
            .collect(Collectors.toList());

    Member writer = post.getMember();
    AnonymousPostDetailRes anonymousPostDetailRes = AnonymousPostDetailRes.of(post, writer, tagNameList);
    return SuccessResponse.of(anonymousPostDetailRes);
}

앞에서 살펴본 것처럼 요청에 쿠키가 없다면 조회수 +1 후 쿠키를 생성하여 함께 응답합니다. 쿠키와 함께 요청을 한다면 게시글 정보만을 응답합니다.

회원

[ MemberPostDetailService.java ]

    @Transactional
    public SuccessResponse<MemberPostDetailRes> getPostDetail(PostDetailParams postDetailParams) {
        Member member = postDetailParams.getUserDetails().getMember();
        Post post = postRepository.findByIdAndStage(postDetailParams.getPostId(), Stage.PUBLISHED)
                .orElseThrow(() -> new ResourceNotFoundException());

        String key = REDIS_KEY_MEMBER_PREFIX + member.getId() + REDIS_KEY_POST_PREFIX + post.getId();
        if (!redisUtil.hasKey(key)) {
            post.incrementViewCount();
            redisUtil.setDataExpire(key, POST_REDIS_VALUE, REDIS_DURATION);
        }

        List<String> tagNameList = taggingRepository.findByPost(post).stream()
                .map(tagging -> tagging.getTag().getName())
                .collect(Collectors.toList());

        Member writer = post.getMember();
        boolean sameUser = member.equals(writer);
        boolean liked = likesRepository.existsByMemberAndPost(member, post);
        boolean scraped = scrapRepository.existsByMemberAndPost(member, post);


        MemberPostDetailRes memberPostDetailRes = MemberPostDetailRes.of(post, writer, tagNameList, sameUser, liked, scraped);
        return SuccessResponse.of(memberPostDetailRes);
    }

마찬가지로 저장소에서 방문 여부를 확인한 후, 조회수 카운팅 여부를 결정합니다. 메일 인증과 JWT 토큰을 위해 Redis를 사용하고 있었으며, 다중 서버 환경에서도 문제 없이 확인할 수 있도록 하기 위해 외부 저장소로 Redis를 사용했습니다.

개발 당시 해당 주제에 대해 PM과 이야기 한 기억이 있습니다. 정책을 추가하면 좋겠지만, MVP로 빠르게 개발을 완료해야 했기 때문에 잠시 접어두고 단순 +1 방식으로 하기로 결정했었습니다. 남겨두었던 것을 다시 자세히 알아보며 따져보아야 할 것들을 생각해보는 유익한 시간이었습니다.

category	tags
장르	액션, 로맨스, SF, 스릴러, 코미디, 드라마, 호러, 판타지, 다큐멘터리, 애니메이션
분위기	긴장감, 따뜻한, 유쾌한, 어두운, 감동적인
시청상황	혼자볼때, 연인과, 가족과, 심심할때, 잠들기전
테마	성장, 복수, 우정, 가족, 사랑, 생존, 범죄, 일상