while-true-study.log

이미지를 굳이 CNN으로 봐야 하나? - Vision Transformer (ViT)

Sat, 29 Aug 2026 10:42:04 GMT

지난 글에서는 Transformer를 보면서 이런 질문에서 시작했다.

문장을 굳이 순서대로 읽어야 하나?

RNN은 문장을 앞에서부터 순서대로 읽었다. Transformer는 이 구조를 버리고 Self-Attention을 사용해서 각 단어가 다른 단어를 직접 볼 수 있게 만들었다.

그런데 Transformer가 NLP에서 그렇게 잘 된다면 이런 생각도 해볼 수 있다.

이미지도 Transformer로 보면 안 되나?

이미지 쪽에서는 이미 CNN이 너무 잘하고 있었다. AlexNet, VGG, ResNet 등을 거치면서 이미지를 처리한다면 CNN을 사용하는 게 거의 당연하게 여겨졌다.

그런데 2021년, 이런 논문이 등장한다.

An Image is Worth 16×16 Words: Transformers for Image Recognition at Scale

이름부터 상당히 특이하다. 이미지가 16×16개의 단어라는 걸까?

그런 뜻은 아니다. 이 논문의 아이디어는 생각보다 단순하다.

이미지를 작은 조각으로 나누고, 그 조각들을 단어처럼 Transformer에 넣으면 안 될까?

이렇게 등장한 모델이 Vision Transformer, 줄여서 ViT다.

1. 그런데 이미지는 원래 어떻게 보고 있었지?

ViT를 보기 전에 CNN부터 다시 생각해보자.

예를 들어 크기가 224 × 224 × 3인 고양이 사진 하나가 있다고 해보자. 224 × 224는 이미지의 높이와 너비이고, 3은 RGB 채널을 의미한다.

CNN은 이 이미지를 처음부터 통째로 보는 게 아니다. 예를 들어 3 × 3 kernel을 사용한다면 이미지의 아주 작은 영역부터 본다.

전체 이미지

┌───────────────────────────┐
│                         │
│        ┌─────┐           │
│        │ 3×3 │          │
│        └─────┘           │
│                         │
└───────────────────────────┘

이 kernel이 이미지 전체를 이동하면서 각 위치의 픽셀 값과 kernel의 weight를 이용해 가중합을 계산한다. 학습을 반복하면 kernel의 weight도 계속 바뀌고, 어떤 kernel은 경계나 texture 같은 특정 패턴에 잘 반응하게 될 수 있다.

깊은 CNN에서는 앞쪽 layer에서 얻은 feature들이 다시 조합되면서 점점 복잡한 표현을 만든다. 아주 단순하게 생각하면 초반에는 edge나 texture 같은 비교적 단순한 특징을 잡고, 뒤로 갈수록 부분적인 형태와 더 복잡한 특징을 표현하게 된다.

물론 실제 신경망을 보고

"이 kernel은 정확히 고양이 귀를 찾는다."

라고 딱 잘라 말할 수 있는 건 아니다. 중요한 건 CNN이 작은 영역부터 특징을 만들어간다는 점이다.

2. 왜 CNN은 굳이 작은 영역부터 볼까?

여기서 질문이 하나 생긴다.

왜 굳이 3 × 3 같은 작은 영역부터 보는 걸까?

생각해보면 이미지에는 꽤 강한 특징이 있다. 어떤 픽셀 하나가 물체의 어떤 부분인지 판단한다고 했을 때, 이미지 반대편 끝의 픽셀보다 바로 주변 픽셀이 더 중요할 가능성이 높다.

· · ·
· X ·
· · ·

예를 들어 고양이 눈에 해당하는 픽셀 주변에는 다른 눈 픽셀이나 털, 얼굴과 관련된 픽셀이 있을 가능성이 높다. 따라서 가까운 픽셀끼리 관계가 강할 것이다라는 가정은 꽤 합리적이다.

CNN은 이 생각을 모델의 구조 자체에 넣었다. 3 × 3 kernel을 사용한다는 것 자체가 모델에게 일단 주변부터 봐라고 알려주는 것과 비슷하다.

또 하나 있다. 어떤 kernel이 특정 특징에 잘 반응하게 학습되었다면 그 특징이 이미지 왼쪽 위에 있든 오른쪽 아래에 있든 비슷하게 잡아내는 것이 좋을 것이다. 그래서 CNN에서는 같은 kernel을 이미지 전체에 공유해서 사용한다.

        같은 Kernel
      ↙      ↓      ↘
    왼쪽     중앙    오른쪽

즉 CNN은 학습을 시작하기 전부터 이미지에 대해 어느 정도 힌트를 받고 있다.

가까운 픽셀끼리 중요할 것이다. 같은 특징이라면 위치가 바뀌어도 비슷하게 볼 수 있을 것이다.

이런 식으로 모델에 미리 넣어주는 가정을 Inductive Bias라고 한다. 이름은 어려운데 개인적으로는 모델에게 미리 주는 힌트 정도로 이해하면 편했다.

CNN은 이미지를 완전히 아무것도 모르는 상태에서 보는 것이 아니다. 이미지 처리에 유리한 규칙을 어느 정도 가지고 시작하고, 이러한 inductive bias 덕분에 상대적으로 적은 데이터에서도 잘 학습할 수 있다.

그런데 여기서 ViT가 재미있는 질문을 던진다.

이런 규칙을 우리가 꼭 미리 넣어줘야 할까?

3. Transformer는 조금 다르게 생각했다

다시 문장으로 돌아가보자.

The cat sat on the mat

Transformer의 Self-Attention에서는 cat이 반드시 바로 옆 단어만 볼 필요가 없다. 문장 안의 다른 token들과 직접 관계를 계산할 수 있다.

즉 누구와 관계가 중요한지는 모델이 직접 학습한다.

그러면 이미지도 이런 식으로 보면 안 될까?

CNN처럼 가까운 영역부터 보고 layer를 쌓으면서 점점 넓은 영역의 정보를 합치는 대신, 이미지의 서로 멀리 떨어진 영역도 처음부터 직접 관계를 계산하게 만드는 것이다.

왼쪽 위 영역  <---------------->  오른쪽 아래 영역

문제는 하나다. Transformer는 원래 이미지를 입력받는 모델이 아니다.

4. 그럼 이미지를 어떻게 Transformer에 넣지?

Transformer가 받는 입력은 기본적으로 sequence다.

Token 1 → Token 2 → Token 3 → ... → Token N

반면 이미지는 $H \times W \times C$ 형태다. 예를 들어 224 × 224 × 3 크기의 이미지를 Transformer에 넣는다고 생각해보자.

가장 단순하게 생각하면 픽셀 하나를 token 하나로 만들 수도 있다. 하지만 그러면

$$ 224 \times 224 = 50,176 $$

개의 token이 생긴다.

Self-Attention은 token 사이의 관계를 계산하기 때문에 token 수가 $N$이라면 계산량은 대략

$$ O(N^2) $$

으로 증가한다. 5만 개가 넘는 token을 모두 서로 보게 만드는 것은 너무 비싸다.

그래서 ViT에서는 픽셀 하나를 token으로 사용하지 않는다.

픽셀 하나 말고, 이미지의 작은 영역 하나를 token으로 쓰자.

이 작은 영역이 바로 Patch다.

5. 이미지를 Patch로 잘라보자

224 × 224 이미지를 16 × 16 크기의 patch로 자른다고 해보자. 가로와 세로에 각각 14개씩 들어가므로 총 patch의 개수는

$$ 14 \times 14 = 196 $$

개가 된다.

224 × 224 Image
        ↓
16 × 16 Patch로 분할
        ↓
196 Patches

이제 이 196개의 patch를 문장의 단어처럼 생각한다.

문장  : Word 1, Word 2, Word 3, ...
이미지: Patch 1, Patch 2, Patch 3, ...

이게 ViT의 핵심 아이디어다.

논문의 제목인 An Image is Worth 16×16 Words도 여기에서 나온다. 이미지가 정말 16 × 16개의 단어라는 뜻이 아니라, 16 × 16 pixel 크기의 이미지 조각을 하나의 단어처럼 다룬다는 의미다.

Figure 1. Vision Transformer의 전체 구조 이미지를 일정한 크기의 Patch로 나누고 Linear Projection한 뒤 Position Embedding을 더해 Transformer Encoder에 입력한다. 출처: Dosovitskiy et al., An Image is Worth 16×16 Words, ICLR 2021.

논문의 전체 구조를 보면 생각보다 단순하다. 이미지를 patch로 나누고 Transformer가 받을 수 있는 vector로 바꿔준 뒤에는 기존 Transformer Encoder를 거의 그대로 사용한다.

이제 그림의 앞부분부터 하나씩 뜯어보자.

6. 그런데 Patch를 그냥 Transformer에 넣을 수 있나?

아직 안 된다.

RGB 이미지에서 16 × 16 patch 하나에는

$$ 16 \times 16 \times 3 = 768 $$

개의 값이 들어 있다.

우선 이 patch를 길게 펼치면 하나의 768차원 vector를 만들 수 있다.

16 × 16 × 3 Patch → Flatten → 768차원 Vector

그리고 이 vector를 Linear Projection에 통과시켜 Transformer가 사용하는 $D$차원의 vector로 바꿔준다.

Patch → Flatten → Linear Projection → Patch Embedding

식으로 표현하면 대략 다음과 같다.

$$ \mathbf{x}_p^i E $$

여기서 $E$도 학습되는 weight다. 단순히 patch의 픽셀을 펼쳐서 그대로 사용하는 것이 아니라, 이 patch를 어떤 vector로 표현해야 분류에 유리한지도 학습 과정에서 같이 배우는 것이다.

이를 Patch Embedding이라고 한다.

이 과정은 NLP의 Word Embedding과 상당히 비슷하다.

NLP : Word        → Word Embedding  → Transformer
ViT : Image Patch → Patch Embedding → Transformer

Patch Embedding이 끝난 순간부터 Transformer 입장에서는 이 vector가 이미지에서 왔는지 문장에서 왔는지가 크게 중요하지 않다. 그냥 여러 개의 vector로 이루어진 sequence를 받은 것이고, 이제 이 vector들 사이에서 Self-Attention을 계산하면 된다.

7. 그런데 이미지에서 위치가 바뀌면 큰일 아닌가?

여기서 또 문제가 하나 생긴다.

얼굴에서 눈, 코, 입이라는 특징이 모두 존재하더라도 위치가 뒤섞이면 전혀 다른 이미지가 된다. 이미지에서는 무엇이 있는가뿐만 아니라 어디에 있는가도 중요하다.

하지만 Self-Attention 자체는 token이 원래 어디에 있었는지를 자동으로 알지 못한다. Transformer에서도 같은 문제가 있었고, 이를 해결하기 위해 위치 정보를 따로 추가했다.

ViT도 마찬가지로 Patch Embedding에 Position Embedding을 더한다.

Patch Embedding + Position Embedding → Transformer Input

각 patch에게 너는 원래 이미지의 이 위치에 있었어라는 정보를 같이 주는 것이다.

ViT에서는 학습 가능한 Position Embedding을 사용한다. 흥미로운 부분은 처음부터 2차원 이미지의 구조를 아주 강하게 설계해서 넣어준 것이 아니라, 학습 과정에서 patch 사이의 위치 관계도 같이 배우게 했다는 점이다.

Figure 7 (Center). 학습된 Position Embedding의 유사도 출처: Dosovitskiy et al., An Image is Worth 16×16 Words, ICLR 2021.

실제로 학습이 끝난 Position Embedding을 확인해보면 가까이에 있는 patch들의 embedding이 서로 비슷해지고, 같은 행이나 열에 있는 patch 사이에서도 구조가 나타난다.

처음부터 복잡한 2차원 위치 규칙을 강하게 넣어주지 않았는데도 모델이 학습하면서 이미지의 2차원 공간 구조를 어느 정도 스스로 만들어낸 것이다.

8. 갑자기 `[CLS]`는 왜 나올까?

ViT 구조를 보면 patch들 앞에 [CLS]라는 특별한 token 하나가 붙어 있다.

[CLS] [P1] [P2] [P3] ... [P196]

이 token도 다른 patch들과 함께 Self-Attention에 참여한다. Transformer layer를 여러 개 지나면서 [CLS]에는 이미지 전체를 분류하는 데 필요한 정보가 모이게 되고, 마지막에는 이 vector를 classifier에 넣어 고양이인지 강아지인지 등을 판단한다.

즉 [CLS]는 이미지 전체를 대표하는 token처럼 사용하는 것이다.

9. 여기까지 왔으면 이제 거의 Transformer다

전체 흐름을 다시 보면 다음과 같다.

Image
 → Patch
 → Flatten
 → Linear Projection
 → Patch Embedding + Position Embedding
 → [CLS] 추가
 → Transformer Encoder × L
 → [CLS]
 → Classifier

Transformer Encoder 내부도 기존 Transformer와 크게 다르지 않다. LayerNorm, Multi-Head Self-Attention, MLP와 Residual Connection이 반복된다.

결국 ViT에서 정말 중요한 아이디어는 엄청나게 새로운 Attention을 만든 것이 아니다.

이미지를 Transformer가 받을 수 있는 형태로 바꿔버렸다.

이미지를 patch들의 sequence로 만들고 나면 그 이후에는 기존 Transformer 구조를 거의 그대로 사용할 수 있다.

10. 근데 CNN도 작은 영역을 보고 ViT도 Patch를 보잖아?

여기서 나도 처음에 궁금했던 게 있다.

CNN도 작은 영역을 보는데 ViT도 이미지를 작은 patch로 자르면 둘이 비슷한 거 아닌가?

겉으로 보면 비슷해 보이지만 작은 영역을 사용하는 목적과 그 이후의 처리 방식이 다르다.

CNN에서는 작은 영역에 convolution을 적용해 local feature를 만들고, 그 feature에 다시 convolution을 적용하면서 점점 넓은 영역의 정보를 합친다.

CNN: Local → Local → Local → 점점 넓은 영역

반면 ViT의 patch는 convolution을 수행하기 위한 영역이라기보다 하나의 token 단위다. patch가 token으로 변환된 이후에는 첫 Transformer layer부터 서로 멀리 떨어져 있는 patch 사이의 관계를 계산할 수 있다.

ViT: Patch → Token → Global Self-Attention

예를 들어 이미지 왼쪽 위의 patch와 오른쪽 아래의 patch도 첫 layer부터 직접 Attention을 계산할 수 있다.

물론 CNN이 global 정보를 못 본다는 뜻은 아니다. CNN도 layer가 깊어지면서 receptive field가 커지고 결국 전체 이미지 정보를 사용할 수 있다.

차이는 전체 정보를 만들어가는 방식이다.

Figure 6. ViT의 Attention 시각화 출처: Dosovitskiy et al., An Image is Worth 16×16 Words, ICLR 2021.

논문에서는 실제로 ViT가 이미지의 어디에 Attention을 두는지도 확인했다. 강아지 사진에서는 강아지가 있는 영역, 비행기 사진에서는 비행기가 있는 영역처럼 분류에 의미 있는 부분에 Attention이 모이는 것을 볼 수 있다.

즉 patch들을 무작정 섞는 것이 아니라, 이미지 분류에 필요한 영역 사이의 관계를 실제로 학습하고 있는 것이다.

11. 그럼 ViT가 CNN보다 무조건 좋은 건가?

여기서 가장 조심해야 한다.

ViT 논문을 보고

CNN은 이제 필요 없다.

라고 이해하면 안 된다.

오히려 작은 규모의 데이터에서는 CNN이 상당히 강했다. 이유는 앞에서 봤던 Inductive Bias다.

CNN은 가까운 픽셀부터 보는 것이 좋다, 같은 특징은 위치가 달라져도 비슷하게 처리할 수 있다 같은 이미지에 유리한 힌트를 가지고 시작한다.

반면 ViT는 이런 이미지 전용 힌트가 상대적으로 적다.

조금 과장해서 표현하면 CNN은

이미지는 이런 특징이 있으니까 이런 방식으로 보면 좋아.

라는 힌트를 받고 시작하는 반면, ViT는

여기 Patch들이 있어. 어떤 관계가 중요한지는 데이터를 보고 네가 알아내.

에 더 가깝다.

따라서 데이터가 적을 때는 CNN이 유리할 수 있다. ViT는 이미지가 가진 구조 자체도 데이터에서 더 많이 학습해야 하기 때문이다.

실제로 논문에서도 작은 규모의 데이터에서는 ViT가 비슷한 크기의 ResNet보다 좋지 않았다.

그런데 데이터가 많아지면서 상황이 달라진다.

12. 데이터가 엄청 많아지면?

ViT 논문에서는 서로 다른 규모의 데이터로 pre-training을 진행했다.

Dataset	이미지 수
ImageNet	약 130만 장
ImageNet-21k	약 1,400만 장
JFT	약 3억 장

작은 데이터에서는 CNN의 inductive bias가 강력했다. 하지만 pre-training 데이터가 커지면서 ViT의 성능이 계속 올라갔고, 대규모 데이터에서는 굉장히 강력한 결과를 보여줬다.

즉 이 논문의 이야기는 단순히

Transformer를 이미지에 사용했더니 CNN보다 좋더라.

가 아니다.

오히려 다음 질문에 더 가깝다.

충분한 데이터가 있다면 사람이 미리 넣어준 규칙을 줄이고, 필요한 구조를 데이터에서 직접 배우게 할 수도 있지 않을까?

CNN은 강한 inductive bias를 가지고 있고 ViT는 상대적으로 그 bias가 적다. 대신 ViT는 그만큼 많은 것을 데이터에서 배워야 한다.

Figure 3, 4. Pre-training 데이터 규모에 따른 ViT와 ResNet의 성능 변화 출처: Dosovitskiy et al., An Image is Worth 16×16 Words, ICLR 2021.

이 두 그림이 사실 ViT 논문의 핵심 결과 중 하나다.

Figure 3을 보면 작은 데이터에서는 큰 ViT가 ResNet보다 좋지 않다. 하지만 ImageNet-21k를 거쳐 JFT-300M으로 pre-training 데이터가 커질수록 상황이 달라진다.

Figure 4에서는 이 차이가 조금 더 직접적으로 나타난다. 데이터가 적을 때는 ResNet이 강하지만 데이터의 규모가 커지면서 ViT의 성능도 계속 증가한다.

결국 작은 데이터에서는 CNN이 가지고 있는 inductive bias가 큰 도움이 되지만, 데이터가 충분히 많다면 필요한 이미지 구조를 모델이 데이터에서 직접 학습하는 것도 가능하다는 것이다.

13. 그러면 Patch 안에서 CNN을 쓰면 더 좋은 거 아닌가?

ViT를 보다 보면 이런 생각도 들 수 있다. 나도 이 부분이 처음에 궁금했다.

16×16 patch 안에서 convolution으로 특징을 먼저 뽑아주면 더 좋은 token을 만들 수 있지 않을까?

가능하다. CNN이 먼저 local feature를 뽑고 Transformer가 그 feature 사이의 관계를 학습하도록 만들 수 있다.

다만 patch를 먼저 완전히 잘라놓은 뒤 각각 독립적으로 convolution하는 것보다는 이미지 전체에 CNN을 적용한 후 만들어진 feature map을 Transformer의 token으로 사용하는 방식이 더 자연스럽다.

Image → CNN → Feature Map → Tokens → Transformer

patch를 먼저 잘라버리면 patch 경계에 걸린 local feature를 CNN이 한 번에 보기 어렵기 때문이다.

실제로 원래 ViT 논문에서도 ResNet + Transformer 형태의 Hybrid Architecture를 함께 실험했다. CNN이 local feature extraction을 담당하고 Transformer가 global relationship을 담당하는 식이다.

Figure 5. ViT, ResNet, Hybrid 모델의 Pre-training Compute 대비 성능 파란색은 순수 ViT, 회색은 ResNet, 주황색은 ResNet과 ViT를 결합한 Hybrid 모델이다. 출처: Dosovitskiy et al., An Image is Worth 16×16 Words, ICLR 2021.

그렇다고 CNN과 Transformer를 합치면 항상 더 좋은 것도 아니었다. 작은 computational budget에서는 Hybrid가 순수 ViT보다 조금 유리했지만, 모델과 계산 규모가 커질수록 그 차이는 거의 사라졌다.

결국 중요한 질문은 CNN이 좋냐 Transformer가 좋냐보다, 모델에 이미지에 대한 inductive bias를 얼마나 넣어줄 것이냐에 더 가깝다.

CNN을 앞에 붙이면 local feature를 쉽게 학습할 수 있도록 다시 강한 힌트를 주는 셈이고, 순수 ViT는 그런 가정을 줄인 대신 더 많은 것을 데이터에서 직접 학습한다.

14. Patch는 작을수록 좋은 거 아닌가?

16×16 patch보다 8×8 patch를 사용하면 이미지를 더 세밀하게 볼 수 있다. 그렇다면 patch를 그냥 최대한 작게 만들면 되는 걸까?

그렇게 간단하지는 않다.

224×224 이미지에서 32×32 patch를 사용하면

$$ 7 \times 7 = 49 $$

개의 token이 생기지만, 16×16 patch를 사용하면

$$ 14 \times 14 = 196 $$

개의 token이 생긴다.

patch가 작아질수록 이미지의 정보를 더 세밀하게 유지할 수 있는 대신 token의 개수가 크게 늘어난다. 문제는 Self-Attention의 계산량이 token 수에 대해 대략 $O(N^2)$으로 증가한다는 점이다.

즉 작은 Patch → 더 많은 Token → 더 세밀한 표현 → 더 큰 Attention 계산 비용이라는 trade-off가 있다.

그래서 ViT-B/16 같은 모델 이름에서 B는 Base 크기의 Transformer를, /16은 16 × 16 patch를 사용한다는 의미다. 같은 방식으로 ViT-L/32라면 Large 모델에 32×32 patch를 사용하는 구조라고 이해하면 된다.

15. 결국 ViT는 뭘 한 걸까?

처음 보면 ViT가 상당히 복잡해 보이지만 전체 흐름만 다시 보면 의외로 단순하다.

Image
 → Patch로 분할
 → Patch Embedding
 → Position Embedding 추가
 → Transformer Encoder
 → [CLS]
 → Classification

먼저 이미지를 여러 patch로 자르고, 각 patch를 Transformer가 사용할 수 있는 vector로 바꾼다. 여기에 위치 정보를 추가한 뒤 Transformer Encoder에 넣고, 마지막 [CLS] representation으로 이미지를 분류한다.

결국 ViT가 한 가장 중요한 일은 이미지를 단어들의 sequence처럼 바꿔 Transformer가 처리할 수 있게 만든 것이라고 볼 수 있다.

마치며

Transformer 논문에서는 이런 질문을 던졌다.

문장을 굳이 순서대로 읽어야 하나?

RNN이 당연하게 사용하던 순차적인 계산 방식을 버리고 Self-Attention이라는 다른 방법을 선택했다.

ViT도 비슷하다. Computer Vision에서는 CNN을 사용하는 것이 너무나 당연하게 여겨지고 있었는데, 여기서 다시 질문을 던졌다.

이미지를 굳이 CNN으로 봐야 하나?

그리고 이미지를 patch로 자른 뒤 각 patch를 단어처럼 Transformer에 넣었다. 기존 Transformer가 Word ↔ Word의 관계를 봤다면 ViT에서는 Patch ↔ Patch의 관계를 보는 셈이다.

처음에는 조금 이상해 보인다. CNN은 이미지에 정말 잘 맞는 구조이고 이미지에는 실제로 locality 같은 성질도 존재한다. 그런데 ViT는 이런 가정을 상대적으로 줄이고, 대신 많은 데이터를 통해 어떤 관계가 중요한지를 직접 학습하게 만들었다.

그리고 데이터의 규모가 충분히 커지자 이 단순한 방식이 굉장히 강력해졌다.

그래서 개인적으로 이 논문의 핵심은

Transformer를 이미지에도 사용할 수 있다.

라는 사실보다도 다음 질문에 더 가까운 것 같다.

우리가 모델에 당연하게 넣고 있던 구조는 정말 반드시 필요한가?

기존 CNN을 조금 수정하는 것이 아니라, 이미지를 바라보는 방식 자체를 다시 생각했다는 점에서 재미있는 논문이었다.

논문 정보

이 글은 Dosovitskiy et al.이 2021년 ICLR에서 발표한 「An Image is Worth 16×16 Words: Transformers for Image Recognition at Scale」 논문을 읽고, 쉽게 이해할 수 있도록 제 방식대로 정리한 글입니다. 감사합니다.

논문명: An Image is Worth 16×16 Words: Transformers for Image Recognition at Scale
저자: Alexey Dosovitskiy et al.
발표: ICLR 2021
arXiv: 논문 페이지
PDF: 원문 PDF 보기
ICLR: 공식 발표 페이지
Google Research: 공식 연구 페이지

본문에 사용된 논문의 표와 그림에는 원 출처를 함께 표기했습니다.

Source: Dosovitskiy et al., An Image is Worth 16×16 Words: Transformers for Image Recognition at Scale, ICLR 2021.

문장을 굳이 순서대로 읽어야 하나? (Attention Is All You Need)

Mon, 17 Aug 2026 21:15:04 GMT

Transformer를 만든 논문, Attention Is All You Need

Transformer? 자동차가 로봇으로 변신하는거?

당연히 그 로봇 트랜스포머는 아니다.

AI를 조금 공부하면 이 단어를 자주 만나게 된다. ChatGPT도 Transformer, BERT도 Transformer, 요즘 나오는 LLM도 대부분 Transformer를 기반으로 한다.

그런데 막상 Transformer가 뭔지 설명해보라고 하면 조금 애매해진다.

1: Transformer가 뭐야? 2: Attention을 사용하는 모델이야 1: Attention은 뭔데? 왜 써?

그래서 이번에 Transformer가 처음 등장한 2017년 논문, Attention Is All You Need를 읽어봤다.

이 논문의 아이디어는 상당히 센세이션하다

문장을 굳이 앞에서부터 하나씩 읽어야 할까?

당시 널리 사용되던 RNN과 LSTM을 아예 빼버리고, Attention만으로 문장을 처리해보자는 것이다.

1. Transformer 이전에는 문장을 어떻게 읽었을까?

예를 들어서 이런 문장이 있다고 해보자.

나는 어제 친구와 영화를 보고 집에 돌아왔다.

사람은 이 문장을 읽을 때 단어 하나하나를 완전히 독립적으로 이해하지 않는다.

돌아왔다를 보면 자연스럽게

누가 돌아왔지 ?? -> 나
언제 ?? -> 어제
뭘 했는데 ?? -> 영화를 보고

같은 관계를 동시에 생각한다. 그런데 당시 대표적인 방식이었던 RNN은 조금 다르다.

문장을 이런 식으로 순서대로 처리한다.

나는 → 어제 → 친구와 → 영화를 → 보고 → 집에 → 돌아왔다

앞 단어를 처리한 결과가 다음 단어를 처리하는 데 사용된다.

h1 → h2 → h3 → h4 → h5 ...

처럼 이전 계산이 끝나야 다음 계산을 할 수 있다. 문장이 짧을 때는 큰 문제가 아닐 수 있다.

하지만 문장이 길면? -> 앞부분의 계산이 끝나기를 계속 *기다려야 한다. *

GPU가 아무리 빨라도 문장 내부 계산 자체가 순차적이기 때문에 병렬화하기 어렵다.

Attention Is All You Need의 저자들은 이 부분을 RNN 계열 모델의 제약으로 짚었다.

그래서 아예 다른 방향을 생각했다.

각 단어가 문장 전체에서 필요한 정보를 직접 찾게 하면 안 될까?

여기서 Transformer가 시작됐다.

2. 지금 이 단어와 관련 있는 단어는 뭘까? ( Self-Attention )

이런 문장을 봐보자

나는 어제 시장에서 사과를 먹었다.

먹었다라는 단어를 이해할 때 어떤 단어를 참고하면 좋을까? 아마 사과를이 눈에 들어올 것이다.

기존 RNN에서는 정보가 앞에서부터 전달된다.

나는 → 어제 → 시장에서 → 사과를 → 먹었다

Self-Attention에서는 먹었다가 문장 안의 다른 단어들과 직접 관련도를 계산할 수 있다.

예를 들어서 이런식이다.

나는        -> 관련도 낮음
어제        -> 조금 관련
시장에서 -> 조금 관련
사과를    -> 관련도 높음

그러면 모델은 먹었다를 표현할 때 사과를의 정보를 더 많이 참고할 수 있다.

Self-Attention은 이런 질문을 각 단어마다 하는 방식이라고 생각하면 편하다.

지금 이 단어를 이해하는데 어떤 단어가 얼마나 관련있을까?

논문에서는 Self-Attention을 하나의 sequence 안에 있는 서로 다른 위치 사이의 관계를 계산하는 Attention이라고 설명한다.

3. Q, K, V는 뭘까?

Transformer를 공부하다 보면 여기서 갑자기 세 글자가 등장한다.

Q, K, V

Query, Key, Value다.

이것은 검색이라고 생각하면 꽤 단순하다.

예를 들어서 갑자기 오디세이 원작 소설을 읽어보고 싶어졌다고 해보자. 서점에 가서 책을 찾을 것이다.

호메로스의 오디세이아 책을 찾고 싶다.

이게 Query다. 그리고 서점에는 수많은 책이 있다.

그리스 로마 신화
오디세이
일리아스
그리스 여행 가이드
영화 각본집
...

각 책에는 제목이나 카테고리처럼

나는 이런 책이야.

라고 알려주는 정보가 있다. 이것을 Key라고 생각할 수 있다.

내가 찾고 싶은 것(Query)과 책이 가진 정보(Key)를 비교하면,

Query: 오디세이 원작을 찾고 싶다

오디세이       → 관련도 매우 높음
일리아스       → 어느 정도 관련 있음
여행 가이드    → 관련도 낮음

이런 식으로 관련도를 계산할 수 있다. 내가 실제로 꺼내 읽을 책의 내용이 Value다.

정리하면 이렇다.

Query
내가 지금 무엇을 찾고 있는가?

        ↓ 비교

Key
각 정보는 무엇과 관련되어 있는가?

        ↓

    관련도 계산

        ↓

Value
실제로 가져올 정보

Transformer도 문장의 각 단어에서 Q, K, V를 만들고 비슷한 일을 한다.

4. 논문에 나오는 Attention 수식도 같은 이야기다

Transformer의 유명한 수식이다.

$$ Attention(Q,K,V) = softmax\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

처음 보면 꽤 많이 부담스러울 수 있다. 그래도 방금 서점 이야기를 생각해보면 쉽다.

먼저

QKᵀ

를 이용해 Query와 Key가 얼마나 관련 있는지 계산한다.

그다음 softmax를 거치며 아래처럼 정보의 비중을 만든다. (중요도)

이 정보는 70%
저 정보는 20%
다른 정보는 10%

마지막으로 그 비중을 이용해 Value를 가져온다.

Q와 K 비교
   ↓
관련도 계산
   ↓
Softmax
   ↓
비중 결정
   ↓
Value를 비중만큼 가져오기

5. 왜 $\sqrt{d_k}$로 나눌까?

수식을 자세히 보면 QKᵀ만 있지 않다. $\sqrt{d_k}$로 나눈다.

그래서 이름도 그냥 Dot-Product Attention이 아니라 Scaled Dot-Product Attention이다.

출처: Vaswani et al., Attention Is All You Need, NeurIPS 2017, Figure 2.

Q와 K의 차원이 커지면 dot product 값도 너무 커질 수 있다.

그 상태에서 softmax통과하면 결과가 한쪽으로 심하게 몰릴 수 있고, gradient도 매우 작아질 수 있다. 그래서 값이 너무 커지지 않도록 $\sqrt{d_k}$로 한 번 조절해준다.

Attention score가 너무 커지지 않도록 한 번 줄여준다.

정도로 이해해도 충분할 것이다.

6. Attention 하나로는 부족했나?

이런 문장을 보자.

민수는 영희에게 책을 빌려주었고, 그녀는 다음 날 책을 돌려주었다.

사람은 이 문장에서 여러 관계를 동시에 본다.

빌려주었다를 보면 민수와 연결되고, 그녀를 보면 영희와 연결되고, 돌려주었다를 보면 책과 연결된다.

문장 안에는 관계가 하나만 있는 게 아니다. 그래서 Transformer는 Attention을 하나만 사용하지 않는다. 여러 Attention을 동시에 돌린다.

이게 Multi-Head Attention이다.

출처: Vaswani et al., Attention Is All You Need, NeurIPS 2017, Figure 2.

하지만

"Head 1은 주어 담당, Head 2는 목적어 담당"

처럼 사람이 역할을 정해놓는게 아니다. 모델이 학습하면서 서로 다른 위치와 서로 다른 표현을 바라보게 된다.

실제로 논문 뒤쪽의 Attention 시각화를 보면, 일부 Head가 멀리 떨어진 단어 사이의 관계를 포착하거나 문장의 구조와 관련된 서로 다른 패턴을 학습한 것을 볼 수 있다.

출처: Vaswani et al., Attention Is All You Need, NeurIPS 2017, Figure 3.

7. RNN을 없앴더니 문제가 하나 생겼다

지금까진 RNN을 없애면 모든 게 좋아지는 것처럼 보인다. 그런데 문제가 생겼다.

다음 두 문장을 보자.

개가 사람을 물었다.

사람이 개를 물었다.

사용된 단어는 거의 똑같다. 그런데 뜻은 전혀 다르다. 순서 때문이다.

RNN은 구조 자체가

1 → 2 → 3 → 4

형태이기 때문에 자연스럽게 순서 정보가 들어간다. 그런데 Self-Attention은 여러 단어들을 동시에 바라본다.

모델 입장에서는

"그래서 이 단어가 몇 번째야?"

라는 정보가 필요하다. 그래서 Transformer는 Positional Encoding을 추가한다.

단어의 의미
Embedding

    +

문장에서의 위치
Positional Encoding

    ↓

Transformer

논문에서는 sine과 cosine 함수를 이용해 위치 정보를 만들어 입력 Embedding에 더해준다.

Transformer의 입력에는 무슨 단어인지 + 몇 번째 단어인지 가 함께 담긴다.

8. Transformer 그림을 보자

Transformer를 처음 검색하면 거의 반드시 이 그림을 보게 된다.

출처: Vaswani et al., Attention Is All You Need, NeurIPS 2017, Figure 1.

논문 3페이지에 나오는 Encoder-Decoder 그림이다.

Multi-Head Attention, Add & Norm, Feed Forward, Masked Multi-Head Attention이 한꺼번에 나와서 상당히 복잡해 보인다.

그래도 지금까지 이야기한 내용을 알고 보면 조금? 다르게 보일 수 있다.

Encoder쪽만 간단하게 줄이면 이렇다.

입력 문장
   ↓
Embedding
   +
Positional Encoding
   ↓
Multi-Head Self-Attention
   ↓
Feed Forward Network
   ↓
다음 Layer

논문에서는 이런 Encoder Layer를 6개 쌓았다.

각 Layer는 이런걸 한다.

1. Attention으로 단어들의 관계를 본다.

2. Feed Forward Network로
   각 위치의 정보를 다시 가공한다.

이 과정을 여러 번 반복한다.

9. Decoder에는 왜 Mask가 붙어 있을까?

논문의 Transformer 그림을 보면 Encoder에는 그냥 Multi-Head Attention이 있는데,

Decoder에는 Masked Multi-Head Attention 이라는 게 있다. Masked 라는 이름 그대로 뭔가를 가린다는 뜻이다. 왜 가릴까?

만약에 번역한다고 생각해보자.

I love this movie.

Decoder가 지금까지

나는 이

까지 만들었다면 다음 단어를 예측해야 한다.

근데 모델을 학습할 때 미래의 정답까지 미리 볼 수 있다면? 그건 사실상 답안지를 펼쳐놓고 문제를 푸는 것이다.

그래서 현재 단어보다 뒤에 있는 단어를 못 보게 가린다.

현재까지 생성한 단어 -> 볼 수 있음
미래에 생성할 단어   -> 볼 수 없음

이게 Masked Self-Attention이다.

10. 그래서 RNN보다 뭐가 좋았을까?

Transformer의 가장 큰 장점 중 하나는 병렬화였다.

RNN은 구조상

1 → 2 → 3 → 4 → 5

처럼 앞에 계산이 끝나야 다음 계산으로 넘어갈 수 있다.

Self-Attention은 문장 안의 여러 위치에 대한 연산을 병렬화할 수 있다. 멀리 떨어진 단어를 연결하는 방식도 다르다.

RNN에서 첫 번째 단어의 정보가 마지막 단어까지 전달되려면 여러 단계를 거쳐야 한다.

A → B → C → D → E

하지만 Self-Attention은 두 위치 사이의 관계를 바로 계산할 수 있다.

A ------------- E

논문의 Table 1에서는 maximum path length를 다음처럼 비교한다.

출처: Vaswani et al., Attention Is All You Need, NeurIPS 2017, Table 1.

순차 연산 수도 Self-Attention은 O(1), recurrent layer는 O(n)으로 분석한다.

그렇다고 Transformer가 언제나 RNN보다 계산량 자체가 적다는 뜻은 아니다.

Self-Attention은 sequence 길이에 대해 O(n²·d)의 계산 복잡도를 가진다.

문장이 아주 길어지면 Attention 자체의 계산량이 빠르게 커지는 문제가 있다.

Transformer의 강점은 단순히 연산량이 적어서가 아니라, 병렬화하기 쉽고, 멀리 떨어진 단어끼리 직접 관계를 계산할 수 있고, 번역 성능까지 잘 나온 것이다.

11. 실제 성능은?

RNN과 CNN까지 뺐는데, 성능은 오히려 어떻게 나왔을까?

출처: Vaswani et al., Attention Is All You Need, NeurIPS 2017, Table 2.

논문에서는 WMT 2014 영어→독일어 번역 문제에서 Transformer Big이 BLEU 28.4를 기록했다. 당시 비교된 기존 최고 결과보다 2 BLEU 이상 높은 성능이었다.

RNN과 CNN을 뺀 구조였는데도, 당시 비교한 기존 모델보다 더 높은 성능을 냈다.

12. Attention을 만든 논문이 아니다

Attention Is All You Need라는 제목만 보면

그럼 이 논문에서 Attention이 처음 나온 건가?

라고 생각하기 쉽다. 근데 Attention은 이 논문 이전에도 이미 사용되고 있었다.

당시에는 주로 RNN / LSTM + Attention 처럼 기존 sequence model에 Attention을 함께 사용하는 방식이었다.

Transformer가 다른건 이거였다.

Attention이 이렇게 잘 되는데, RNN이 정말 필요할까?

그리고 RNN과 CNN을 제거했다.

기존 방식

RNN / CNN
   +
Attention


Transformer

Self-Attention
      +
Feed Forward

Transformer를 한 문장으로 설명하면?

문장을 반드시 앞에서부터 하나씩 처리하지 말고, 각 단어가 필요한 다른 단어를 직접 바라보게 하자.

그 방법이 Self-Attention이고, 그 Self-Attention을 모델의 중심으로 놓은 구조가 Transformer이다.

결국에 Transformer를 하나씩 뜯어보면 비슷한 질문으로 돌아온다.

"지금 이 단어를 이해하려면 어디를 봐야 할까?"

2017년에 나온 이 구조는 이후 BERT와 GPT 같은 모델로 이어졌고, 지금의 LLM을 이해할 때도 빠지지 않는 구조가 됐다.

논문 정보

이 글은 Vaswani et al.이 2017년 NeurIPS에서 발표한 「Attention Is All You Need」 논문을 읽고, 쉽게 이해할 수 있도록 제 방식대로 정리한 글입니다. 감사합니다.

논문명: Attention Is All You Need
저자: Ashish Vaswani et al.
발표: NeurIPS 2017
arXiv: 논문 페이지
PDF: 원문 PDF 보기
NeurIPS: 공식 Proceedings

논문에 사용된 표와 그림은 원 논문에 명시된 이용 허가에 따라 출처를 표기하여 사용했습니다.

Source: Vaswani et al., Attention Is All You Need, NeurIPS 2017.

블로그 검색에 Elasticsearch를 붙이면서 MySQL-ES 정합성 맞춘 과정 (Outbox 패턴)

Tue, 24 Mar 2026 11:18:17 GMT

0. 문제 상황

블로그 검색 기능을 붙이면서 게시글 검색을 Elasticsearch로 분리했다.
처음에는 단순하게 생각했다.

게시글 생성
MySQL 저장
Elasticsearch에도 바로 반영

그런데 구현하다 보니 진짜 문제는 검색 기능 자체가 아니었다.

문제는 MySQL이 원본이고 Elasticsearch는 검색용 인덱스일 때, 두 저장소 상태가 어긋날 수 있다는 점이었다.

예시 1) 생성 시

MySQL 저장은 성공
Elasticsearch 저장은 실패
결과적으로 DB에는 있는데 검색에는 안 잡힘

예시 2) 삭제 시

DB에서는 삭제 처리됨
ES에서는 문서 삭제 실패
결과적으로 이미 지워진 글이 검색에 계속 노출됨

결국 원본 DB와 검색 인덱스의 정합성을 어떻게 유지할 것인가가 문제였다.

1. 처음 생각했던 방식

처음에는 아래처럼 처리하려고 했다.

MySQL에 게시글 저장
바로 Elasticsearch에도 저장

이 방식은 생각보다 불안했다. 이전에 했던 토스 프로젝트 경험이 떠올랐다.

문제점

MySQL 저장과 ES 저장은 하나의 트랜잭션으로 묶이지 않음
ES 반영 실패 시 재시도 기준이 없음
어떤 게시글이 반영 실패했는지 추적하기 어려움
운영 중 장애가 나면 DB와 ES 상태가 어긋난 채 남을 수 있음

이 방식은 장애 상황까지 고려한 구조는 아니었다.

2. 그래서 Outbox 패턴으로 바꿨다

그래서 아래 구조로 변경했다.

MySQL: 원본 데이터 저장소
Elasticsearch: 검색 전용 저장소
게시글 변경 시 ES에 바로 쓰지 않고, 먼저 outbox 이벤트를 남김
스케줄러가 outbox를 읽어 ES 반영 처리

전체 흐름

게시글 변경 → MySQL 저장 + outbox_event 기록 → Scheduler가 읽어서 ES 반영

이 구조로 바꾼 이유는 아래와 같다.

게시글 변경과 동기화 이벤트 기록을 같은 DB 트랜잭션 안에서 처리할 수 있음
ES 반영 실패 시 재처리 대상이 남음
어떤 이벤트가 아직 처리되지 않았는지 추적 가능
ES 반영이 조금 늦더라도 결국 최신 상태로 수렴하게 만들 수 있음

최종적 일관성(Eventual Consistency) 을 선택한 구조이다.

3. 내가 만든 구조

3-1. 역할 분리

MySQL: 게시글 원본 저장
outbox_event: ES 반영해야 할 작업 저장
Scheduler: 미처리 이벤트 조회 및 ES 반영
Elasticsearch: 검색 전용 인덱스

3-2. 전체 처리 흐름

사용자가 게시글 생성 / 수정 / 삭제
post 테이블 변경
같은 트랜잭션 안에서 outbox_event 저장
스케줄러가 PENDING 이벤트 조회
이벤트 타입에 따라 ES 색인 또는 삭제
성공 시 SUCCESS, 실패 시 재처리 가능 상태 유지

ES에 바로 쓰는 구조가 아니라, 반영해야 할 작업 자체를 DB에 남겨두는 구조로 바꿨다.

4. 데이터 모델에서 중요했던 점

4-1. `post` 엔티티에 `syncVersion` 추가

게시글에는 syncVersion 필드를 추가했다. 이 값은 지금 ES에 반영하려는 데이터가 최신인가? 를 판단하기 위한 기준이다.

최초 생성: syncVersion = 1
수정 1회: syncVersion = 2
수정 2회: syncVersion = 3
삭제: syncVersion = 4

아직 오래된 이벤트 역전 방지 로직까지 구현한 것은 아니지만,
나중에 그 문제를 처리할 수 있도록 기반은 만들어두었다.

4-2. `outbox_event`에 넣은 정보

outbox에는 아래 정보를 저장했다.

aggregateType = POST
aggregateId = postId
이벤트 타입: CREATED, UPDATED, DELETED
ES 반영용 payload
version
상태값: PENDING, SUCCESS, FAILED
생성 시각 / 처리 시각 / 재시도 횟수

이렇게 하면 다음이 가능해진다.

어떤 게시글 반영이 실패했는지 확인
지금 어디까지 처리됐는지 확인
재처리 대상 추적

4-3. Elasticsearch 문서 구성

ES 인덱스는 post_search_v4를 사용했고, 문서 _id는 postId로 맞췄다.

필드 구성

postid
title
contentpreview
authorid
authornickname
viewcount
likecount
createdat
updatedat
poststatus
version

5. 구현 흐름

5-1. 생성

생성 흐름

post 저장
CREATED outbox 이벤트 저장
스케줄러가 PENDING 이벤트 조회
ES 문서 저장
outbox 상태 SUCCESS

생성 후 Dev Tools에서 _doc/{postId}로 조회했을 때
found: true가 나오는 것을 확인했다.

ES 문서가 생성된 것까지 검증했다.

5-2. 수정

수정 흐름

제목 / 내용 수정
updatedAt 직접 갱신
syncVersion 증가
UPDATED outbox 이벤트 저장
스케줄러가 ES 문서 재색인

처음에는 JPA lifecycle에 맡겼는데,
outbox payload 생성 시점과 updatedAt 갱신 시점이 어긋나서
ES 문서에는 이전 수정 시간이 들어가고 있었다.

그래서 수정 로직에서 updatedAt을 명시적으로 넣도록 변경했다.

수정 후 확인한 것

outbox에 UPDATED 이벤트 생성
처리 후 SUCCESS
ES 문서의 title 변경
contentpreview 변경
version 증가
updatedat 변경

ES까지 정상적으로 따라 수정 되는 것을 확인했다.

5-3. 삭제

삭제는 아래처럼 처리했다.

DB: 소프트 삭제
ES: 문서 삭제

삭제 흐름

postStatus = DELETED
deletedAt = now
updatedAt = now
syncVersion 증가
DELETED outbox 이벤트 저장
스케줄러가 ES 문서 삭제
outbox 상태 SUCCESS

삭제 후에는 ES에서 _doc/{postId}를 직접 조회해서
found: false가 나오는지 확인했다.

DB에는 삭제 이력이 남고
검색에서는 노출되지 않는 구조

로 정상 동작하는 것을 확인했다.

6. 구현하면서 막혔던 부분

6-1. `payload` 컬럼 길이 부족

outbox payload를 JSON 문자열로 저장할 때
payload 컬럼 길이가 부족해서 insert가 실패했다.

애플리케이션에서는 @Lob를 붙였지만,
DB 컬럼 타입이 충분히 크지 않아서 실제 저장 시점에 길이 초과가 발생했다.

해결

DB 컬럼을 LONGTEXT 쪽으로 수정
@Column(nullable = false, columnDefinition = "LONGTEXT")

JPA 애노테이션만 바꿨다고 DB 스키마까지 자동으로 안전해지는 건 아니다.

6-2. `LocalDateTime` 직렬화 문제

PostOutboxPayload에 createdAt, updatedAt을 LocalDateTime으로 넣었더니
Jackson 기본 설정만으로는 직렬화가 되지 않았다.

해결

ObjectMapper에 JavaTimeModule 등록

payload 구조를 바꾸면 직렬화 설정도 같이 따라와야 한다.

6-3. `updatedAt`이 ES에 반영되지 않던 문제

수정 후 version은 올라가는데 updatedAt은 이전 값으로 남는 문제가 있었다.

원인

payload 생성 시점이 JPA 자동 갱신보다 빨랐음

해결

수정 / 삭제 로직에서 updatedAt 직접 세팅

이후에는 ES에서도 수정 시간이 정상적으로 반영됐다.

6-4. `post_status`에 `DELETED` 저장 실패

삭제 처리 시 postStatus = DELETED로 바꾸는 순간
DB에서 상태값 저장 오류가 발생했다.

원인

자바 enum에는 DELETED 추가
DB 컬럼 제약은 아직 반영 안 됨

해결

DB 컬럼 제약 수정

DB 스키마 제약도 함께 맞췄다.

6-5. 수정 API 테스트에서 인증 객체 null

Postman으로 수정 API 테스트를 하다가
@AuthenticationPrincipal이 null이라 NPE가 발생했다.

처음에는 인증 로직이 문제인 줄 알았는데,
실제로는 security 설정에서 .permitAll() 때문에 요청은 통과하고 있었고
인증 객체는 보장되지 않는 상태였다.

해결

수정 / 삭제 API는 인증이 필요하다는 전제로 정리
테스트 시 실제 인증 헤더 포함해서 다시 검증

7. 실제로 확인한 것

생성 검증

게시글 작성
outbox_event에 CREATED
처리 후 SUCCESS
ES _doc/{postId} 조회
found: true

수정 검증

게시글 수정
syncVersion 증가
UPDATED 이벤트 생성
처리 후 SUCCESS
ES 문서에서 title, contentpreview, updatedat, version 변경 확인

삭제 검증

게시글 삭제
DELETED 이벤트 생성
처리 후 SUCCESS
ES _doc/{postId} 조회 시 found: false

결국 생성 / 수정 / 삭제 전부
MySQL → Outbox → Scheduler → Elasticsearch
흐름으로 실제 반영되는 것을 확인했다.

8. 한계점

8-1. 초기 대량 색인

Outbox 패턴은 운영 중 발생하는 변경 이벤트를 안정적으로 ES에 반영하는 데는 적합했지만, 이미 MySQL에 쌓여 있는 기존 전체 데이터 (1000만건)를 처음부터 적재하는 용도로는 적절하지 않았다.

그래서 초기 색인은 Logstash 기반 배치 적재로 처리하고, 그 이후의 생성/수정/삭제 동기화는 Outbox + Scheduler 구조로 분리했다.

초기 적재는 Logstash
운영 동기화는 Outbox

로 책임을 나눴다.

8-2. 오래된 이벤트 역전 방지

지금은 syncVersion을 넣어뒀지만,
늦게 도착한 오래된 이벤트를 ES 반영 단계에서 건너뛰는 로직은 아직 없다.

이후 고도화하려고 한다.

8-3. 보정 배치

장기적으로는 MySQL과 ES 상태를 주기적으로 대조해서
누락이나 불일치를 보정하는 배치도 필요하다.

지금은 outbox 재시도 구조까지 맞춘 단계이고,
보정 배치까지 들어가야 운영 안정성이 더 올라간다.

8-4. 운영성

아직 아래 같은 부분은 없다.

성공 이벤트 정리 정책
장기 실패 이벤트 분리
관리자 모니터링
장애 대응용 운영 도구

9. 정리

중요한 것은 검색 인덱스를 별도 저장소로 분리했을 때, 원본 DB와 어떻게 정합성을 맞출 것인가
이 문제를 직접 구현하고 검증해본 점이라고 생각한다.

처음에 생각했던 것 처럼 서비스 로직에서 DB 저장 직후 바로 ES 저장하는 구조로 갔다면,

실패 추적도 어렵고
재처리 기준도 없고
운영 중 정합성 문제도 남았을 가능성이 컸다

반면 이번에는

MySQL을 원본으로 두고
outbox에 반영할 작업을 남기고
스케줄러가 비동기 반영하고
생성 / 수정 / 삭제 각각을 직접 검증했다

정합성 문제를 고려한 검색 동기화 구조를 직접 구현한 것에 의미가 있다고 생각한다.

10. 요약

블로그 검색 기능에 Elasticsearch를 도입하면서,
MySQL과 ES 간 정합성 문제를 해결하기 위해
Outbox 패턴 + Scheduler 기반 비동기 동기화 구조를 적용했다.

그리고 생성 / 수정 / 삭제 전 경로에서
실제로 ES 반영까지 되는지 직접 검증했다.

검색 기능 개선기 2

Mon, 02 Mar 2026 15:59:23 GMT

0. 왜 Elasticsearch를 도입하게 됐는가

1편에서는 MySQL 기반 검색을 단계적으로 비교했다.

LIKE '%keyword%'
prefix LIKE ('keyword%')
MySQL Full-Text (기본)
MySQL Full-Text + ngram

1편에서는 검색 결과 후보 수 + 정렬(ORDER BY) + OFFSET 페이징 + 동시성 부하가 합쳐진 비용이었다는 점이다.

MySQL Full-Text / ngram까지 적용해보면서 개선 가능성은 확인했지만, 내 환경에서는 아래 문제가 남았다.

키워드/모드/offset에 따라 응답시간 편차가 큼
p95/p99 관점에서 성능 안정성이 부족함
일부 구간은 여전히 타임아웃 발생
한글 검색 품질과 성능을 동시에 맞추기 어려움

그래서 검색 부하를 DB에서 분리하고, 검색 전용 인덱싱/분석/튜닝이 가능한 Elasticsearch를 다음 단계로 선택했다.

1. 이번 글 내용 요약

이번 글에서는 Elasticsearch를 실제로 붙이면서 겪은 과정을 정리했다.

MySQL => Logstash => Elasticsearch 재색인 과정
대량 적재 최적화와 병목 대응
재색인 중 발생한 트러블슈팅 (document_id, 필드명, refresh 등)
Spring 검색 API 연동 시 발생한 매핑/날짜 파싱 이슈
Locust로 확인한 Elasticsearch 검색 성능 결과

1편이 왜 DB 검색에서 병목이 생겼는지 다뤘고, 이번 글은 DB 데이터를 어떻게 옮겼고, 결과가 어떻게 바뀌었는지를 다룬다.

2. 도입 구조 (MySQL → Logstash → Elasticsearch)

Elasticsearch 도입 구조는 아래처럼 잡았다.

MySQL: 원본 데이터 저장소
Logstash (JDBC input): MySQL 데이터를 읽어 Elasticsearch로 적재
Elasticsearch: 검색 인덱스 저장소
Spring Boot API: 검색 요청을 Elasticsearch로 조회

즉, 검색 요청이 DB를 직접 때리지 않고, 검색 전용 인덱스(Elasticsearch) 를 조회하도록 분리했다.

2-1. 왜 Logstash를 선택했는가

대량 재색인을 빠르게 붙이는 게 먼저 목표였기 때문에, ETL 파이프라인을 코드로 직접 짜기보다 Logstash JDBC input을 사용했다.

장점:

JDBC 기반으로 빠르게 구성 가능
MySQL → ES 적재 파이프라인을 짧은 시간 안에 만들 수 있음
대량 적재 설정(paging, batch, workers) 조절 가능

3. Elasticsearch 인덱스 적재 전략

3-1. 대량 적재 중 Elasticsearch 설정

대량 적재 중에는 검색 가시성보다 적재 성능이 중요해서 아래 설정을 사용했다.

refresh_interval = -1
number_of_replicas = 0

이렇게 하면 인덱싱 중 refresh/replica 비용을 줄여 적재 성능을 높일 수 있다고 한다. 적재가 끝난 뒤에는 운영용 값으로 다시 돌려놓았다. (refresh_interval='1s', replicas=0)

3-2. Logstash JDBC paging 사용

Logstash JDBC input에서 paging을 켰다.

jdbc_paging_enabled => true
jdbc_page_size => 5000
jdbc_fetch_size => 5000

처음에는 이걸로 충분할 줄 알았는데, 뒤로 갈수록 속도가 점점 느려지는 문제가 나타났다. 원인은 OFFSET 페이징 병목이었다.

4. 재색인 병목: Logstash JDBC OFFSET이 뒤로 갈수록 느려짐

Logstash JDBC paging은 내부적으로 LIMIT ... OFFSET ... 형태로 페이지를 가져오는데, 뒤 페이지로 갈수록 OFFSET 비용이 커진다.

[dac520dce07779dc404cec35c0fbaec9d88feb4eac871abdc56f519785748ee3] (1.893400s) 
SELECT * FROM ( logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 840000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 940000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1040000 logstash_1-1 | [2026-02-28T23:23:27,400][INFO ][logstash.inputs.jdbc ][main]
[dac520dce07779dc404cec35c0fbaec9d88feb4eac871abdc56f519785748ee3] (2.203273s) 
SELECT * FROM ( logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1140000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1240000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1340000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1400000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1440000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1540000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1640000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1740000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1840000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 1940000 logstash_1-1 | [2026-02-28T23:32:44,666][INFO ][logstash.inputs.jdbc ][main]
[dac520dce07779dc404cec35c0fbaec9d88feb4eac871abdc56f519785748ee3] (3.940005s) SELECT * FROM ( logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 2040000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 2140000 logstash_1-1 | ) AS t1 LIMIT 5000 OFFSET 2240000

1.8s => 2.2s => 3.9s 실제로 로그를 보면 뒤로 갈수록 같은 5000건을 가져오는 쿼리 시간이 증가했다. 하나의 Logstash로 1000만개를 하니 5000개당 10초수준으로 되기도 했다. 1편에서 검색 쿼리의 OFFSET 병목을 본 것과 비슷했다.

4-1. 해결: `post_id` 범위 분할 + 병렬 재색인

한 개 Logstash 파이프라인으로 끝까지 미는 대신, post_id 범위 기준으로 4분할해서 병렬 적재했다.

나는 1000만개의 row가 있기 때문에 250만개씩 분할 해서 적재했다.

1번: post_id <= 2500000
2번: 2500000 < post_id <= 5000000
3번: 5000000 < post_id <= 7500000
4번: post_id > 7500000

이렇게 하면 각 파이프라인이 처리하는범위가 줄어 OFFSET 깊이가 작아졌고, 재색인 속도가 훨씬 나아졌다.

4-2. 병렬 실행 시 주의점

4개를 동시에 돌릴 때 기본 worker 설정으로 두면 오히려 로컬 리소스가 과포화될 수 있어서, 서비스별 pipeline workers를 줄여서 실행했다.

logstash_1:
  image: docker.elastic.co/logstash/logstash:9.2.1
  depends_on:
    - elasticsearch
  command: >
    logstash -f /usr/share/logstash/pipeline
    --pipeline.workers 2
    --pipeline.batch.size 200
  volumes:
    - ./logstash/pipeline-1:/usr/share/logstash/pipeline
    - ./logstash/mysql-connector-j.jar:/usr/share/logstash/mysql-connector-j.jar

병렬성은 늘리고 서비스당 과도한 worker를 줄이는 방식으로 조절해서 사용했다.

5. 재색인 트러블슈팅

성능 튜닝보다 더 시간을 잡아먹은 건, 재색인 중 데이터 정합성/필드명/가시성 문제였다.

5-1. Kibana 문서 수가 안 올라가 보였던 문제

Logstash 로그에서는 데이터가 많이 들어가는 것처럼 보이는데 Kibana 문서 수가 적게 보이는 상황이 있었다.

refresh_interval=-1 영향
- 대량 적재 중에는 바로 검색 가능 상태로 보이지 않을 수 있음
실제로 적재 건수가 적은 경우도 있음
- _stats, _count, _cat/indices로 확인 필요

5-2. `document_id` 문제로 `deleted`만 폭증

재색인 중 1 document + deleted만 폭증하는 이상한 상태를 겪었다.

원인은 document_id에 넣은 필드명이 실제 이벤트 필드명과 달랐기 때문이었다.

예를 들어서 SQL에서는 AS postId로 alias를 줬지만, Logstash JDBC가 컬럼명을 소문자로 내리면서 실제 필드가 postid로 들어왔다. 그 상태에서 아래처럼 쓰면:

document_id => "%{postId}"

치환에 실패해서 모든 문서가 같은 _id로 들어가고, 결과적으로 한 문서만 계속 덮어쓰기 되는 현상이 발생했다.

증상:

Kibana 문서 수는 1개만 늘어났다.
deleted수치만 계속 증가, 감소하는 패턴이 보였다.

해결:

나는 document_id => "%{postid}" 로 변경해서 해결 했다.
lowercase_column_names => false 사용해도 가능하다고 한다.

문제 원인 찾는 데 시간이 꽤 걸렸었다.

5-3. `hosts => ["http://elasticsearch:9200"]` vs `localhost:9200`

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "post_search_v4"
    document_id => "%{postid}"
    action => "index"
  }
}

처음엔 localhost:9200로 써야 하는지 헷갈렸는데, Logstash가 Docker 컨테이너 안에서 돌고 있을 때는 localhost가 컨테이너 자기 자신을 가리킨다.

Docker Compose 네트워크에서 Elasticsearch 컨테이너 서비스명(elasticsearch)으로 접근하는 설정이 맞았다.

컨테이너 내부 Logstash → http://elasticsearch:9200 (정상)
호스트에서 직접 실행하는 클라이언트 → http://localhost:9200

6. 최종 적재 결과

필드명/document_id 문제를 정리하고 재색인을 다시 수행한 뒤, 최종적으로 post_search_v4 인덱스에 약 9,824,079건이 적재되었다.

Kibana 기준으로 문서 수와 저장 크기가 정상 범위로 올라오는 것을 확인했다.

인덱스: post_search_v4
Documents: 약 9,824,079
Storage: 약 2.07GB (실험 기준)

재색인 문제는 해결했으니 이제 Spring 검색 API와 Elasticsearch 조회를 제대로 연결을 해야했다.

7. Spring 검색 API 연동과 쿼리 이슈

Elasticsearch 인덱스가 만들어졌다고 끝이 아니었다. 애플리케이션 코드와 실제 ES 문서 필드명이 맞지 않으면 검색이 바로 깨졌다.

7-1. `all shards failed` 발생

재색인한 문서의 필드명은 Logstash 문제를 해결하며 소문자로 바꿨었다.

postid
createdat
poststatus
viewcount
likecount

그런데 Spring 코드에서 예전 camelCase 기준으로 정렬/조회 필드를 쓰면, 예를 들어 createdAt 같은 필드로 정렬할 때 Elasticsearch에서 all shards failed가 발생할 수 있었다.

해결 방향:

ES 쿼리에서 실제 필드명(createdat, postid, poststatus) 사용
PostSearchDocument 매핑에서 @JsonProperty로 소문자 필드명 매핑

7-2. 날짜 파싱 이슈

필드명 문제를 해결한 뒤에는 날짜 파싱 이슈가 발생했다.

Elasticsearch에서 내려온 날짜 값은 아래처럼 Z(UTC offset)가 포함된 문자열이었다.

2026-02-25T09:52:02.000Z

처음에는 LocalDateTime.parse()로 바로 파싱했는데, Z를 처리하지 못해서 DateTimeParseException이 발생했다.

해결은 Instant.parse()(또는 OffsetDateTime.parse())로 먼저 파싱한 뒤, 필요한 시간대(예: Asia/Seoul)로 변환하는 방식으로 했다.

즉, Elasticsearch 연동에서는 성능 이전에 필드명/매핑/날짜 포맷 정합성을 맞추는 작업이 중요했다.

8. Elasticsearch 부하 테스트 설계

Elasticsearch 검색 성능을 깔끔하게 보기 위해, Locust 스크립트도 수정했다.

초기에는 /posts 목록 API를 같이 호출해서 키워드 풀을 만들었는데, 이 요청 자체가 aggregate 수치를 오염시킬 수 있었다. 그래서 최종 테스트에서는 ES 검색 API만 호출하도록 분리했다.

테스트 대상:

GET /api/v1/search/posts/es

분포:

키워드: 한글/영문 혼합 + 핫키워드
offset: 0, 1~200, 201~1000, 1001+

9. Elasticsearch 부하 테스트 결과 (Locust)

9-1. 전체 집계

실측 결과는 아래와 같았다.

총 요청 수: 653,979
실패 수: 0
평균 응답시간: 8.69ms
중앙값(p50): 7ms
p95: 18ms
p99: 26ms
최대 응답시간: 178ms
RPS: 약 62.1

1편에서 했던 MySQL 기반 검색 결과와 완전히 다른 차원이었다. 너무 빨랐다.

9-2. offset 구간별 결과

offset 구간이 커질수록 응답시간이 올라가는 패턴은 여전히 보였다.

offset=0
- 평균 7.04ms
- p95 10ms
- p99 14ms
offset=1~200
- 평균 7.41ms
- p95 11ms
- p99 15ms
offset=201~1000
- 평균 9.05ms
- p95 15ms
- p99 19ms
offset=1001+
- 평균 12.19ms
- p95 24ms
- p99 29ms

9-3. 해석

Elasticsearch로 바꿔도 from/size 기반 offset 페이징 비용은 완전히 사라지지 않았다. offset이 커질수록 느려지는 패턴 자체는 남아 있었다.

실패율 0
p95 18ms / p99 26ms
RPS 안정적 유지

내가 원했던 건 평균값 몇 ms보다도 p95/p99와 timeout 안정성이었는데, 그 기준에서 Elasticsearch 도입 효과가 확실했다.

10. 최종 비교 요약

이번 실험에서 얻은 결론을 정리하면 아래와 같다.

LIKE '%keyword%': 구현은 단순하지만 대용량 + 정렬/offset 조합에서 병목이 크게 발생했다.
prefix LIKE: 이론상 인덱스 후보이지만, 내 실험 조건에서는 실행계획상 풀스캔 + 파일정렬
MySQL Full-Text / ngram: 개선 가능성은 있지만 키워드/모드/offset 편차가 크고 안정성 부족 + 한글 검색 빈약
Elasticsearch: 재색인/동기화/매핑 관리 비용은 늘지만, 제품 API 응답시간 안정성은 크게 개선

실험 한계와 해석 범위

이번 글의 비교는 내 데이터 분포 / 내 쿼리 구조 / 내 정렬·페이징 조건 / 내 튜닝 수준에서의 결과다.
MySQL Full-Text / ngram은 설정과 데이터 특성에 따라 결과가 달라질 수 있다.

따라서 이 글의 결론은 MySQL Full-Text/ngram이 항상 느리다가 아니라,
현재 조건에서는 키워드/모드/offset에 따른 편차가 크고, 내가 목표로 한 p95/p99·timeout 안정성을 만족시키기 어려웠다는 의미로 해석해야 한다.

11. 결론

Elasticsearch를 붙이고 나서 가장 크게 느낀 점은 두 가지였다.

검색 엔진 도입보다 어려운 건 데이터 이행과 정합성 관리다
- Logstash JDBC paging 병목
- document_id 덮어쓰기
- 필드명 소문자화
- Spring-ES 매핑/날짜 파싱 이슈
최종 사용자 관점 성능은 확실히 개선됐다
- 1편의 MySQL 기반 검색은 최악 구간에서 수십 초 ~ 타임아웃
- 2편의 ES 기반 검색은 p95/p99가 수십 ms 수준으로 안정적

현재 데이터 규모와 검색 요구사항, 그리고 내가 중요하게 본 지표(p95/p99/timeout 안정성) 기준을 보고 내상황에서는 ES가 더 맞았던 선택인 것 같다.

12. 다음 개선 포인트

아직 해야할 것들이 많이 남았다.

from/size → search_after 전환 (커서 기반 페이징)
검색 품질 튜닝 (analyzer, ranking)
재색인 자동화/운영 개선
MySQL ↔ ES 동기화 전략 정리 (최종적 일관성 포함)

다음 글에서는 search_after 적용 전/후 비교를 정리해보려고 한다.

검색 기능 개선기 1

Sun, 15 Feb 2026 14:14:57 GMT

0. 당시 상황

블로그 서버를 만들고 있었고, 검색 기능도 함께 붙이고 있었다. 데이터가 적을 때는 검색이 잘 됬는데, 게시글을 늘려보니까 문제가 생겼다.

초기에는 DB에서 바로 검색했었다.

SELECT *
FROM post
WHERE title   LIKE CONCAT('%', :keyword, '%')
   OR content LIKE CONCAT('%', :keyword, '%')
ORDER BY created_at DESC
LIMIT :limit OFFSET :offset;

데이터가 커질수록 검색 응답시간이 급격히 늘어났고, 40초 이상 걸리는 구간도 나왔다.

0-1. 구현 흐름

검색 API: GET /api/v1/search/posts?...
검색 방식(초기 방법): MySQL LIKE '%keyword%'
정렬/페이징: ORDER BY created_at DESC LIMIT/OFFSET

0-2. 실험 환경

앱: Spring Boot + JPA + MySQL8 + Tomcat
커넥션 풀: HikariCP
부하 도구: Locust
관측: access log, actuator metrics, MySQL, Elasticsearch/Kibana

0-3. 스펙

CPU: 13th Gen Intel(R) Core(TM) i5-13500
DB 분리 여부: 로컬 동일 머신
Hikari 설정 maximumPoolSize: 10

0-4. 테스트 데이터 규모

데이터가 적었을때는 병목이 잘 보이지 않았다. 그래서 데이터 규모를 많이 크게 해서 확인해보았다.

post 테이블: 약 990만 ~ 1,100만 건 규모 테스트
검색 요구사항: 부분 포함 검색 (%keyword%)
페이징: offset/limit

이 글은 위 조건에서 검색 병목을 관측하고, 여러가지 시도를 해보며 개선을 한 과정을 정리했다.

1. 부하 테스트 설계

같은 조건에서 검색 방식을 바꿨을 때 숫자로 비교했다.

1-1. 테스트 대상

검색 API (초기: MySQL 검색, 이후: ES 검색 API) 키워드 분포: 한글/영문 혼합 페이징 분포: offset=0, 1~~200, 201~~1000, 1001+

1-2. 성공/실패 기준

Locust failure rate(실패율) p95 / p99 응답시간 RPS 유지 여부 timeout 발생 여부

DB(MySQL) EXPLAIN / EXPLAIN ANALYZE 결과 rows examined filesort 여부 performance_schema / 상태 변수

서버/앱 access log 응답시간 HikariCP active / idle / pending Tomcat thread / connection 메트릭

2. 원인 분석

LIKE '%keyword%'쿼리를 확인했다.

2-1. 왜 LIKE '%keyword%'가 문제일까

MySQL 공식문서의 B-Tree 인덱스 특성 설명에 따르면, LIKE 비교에서 인덱스는 상수 문자열이며 선행 와일드카드가 없는 경우에 사용할 수 있다. 반대로 LIKE '%Patrick%'처럼 선행 와일드카드가 있는 경우는 인덱스를 사용하지 않는 예시로 제시된다. 관련 문서: https://dev.mysql.com/doc/refman/8.4/en/index-btree-hash.html

그런데 %keyword%는 앞에 와일드카드가 있어서 시작점을 모른다. 그래서 B-Tree인덱스로는 범위 탐색에 불리하다.

인덱스로 빠르게 범위 탐색 못 함
테이블/인덱스를 넓게 훑음
조건 필터링
ORDER BY 정렬
OFFSET 있으면 앞부분을 읽고 버림

데이터가 커질수록 선형적으로 비싸지는 구조라고 생각했다.

2-2. EXPLAIN / EXPLAIN ANALYZE

EXPLAIN
SELECT
    p.post_id,
    p.title,
    p.created_at
FROM post p
WHERE p.post_status = 'PUBLISHED'
  AND p.deleted_at IS NULL
  AND p.title LIKE CONCAT('%', '검색', '%')
ORDER BY p.created_at DESC, p.post_id DESC
LIMIT 20 OFFSET 1000;

EXPLAIN ANALYZE
SELECT p.post_id, p.title, p.created_at
FROM post p
WHERE p.post_status = 'PUBLISHED'
  AND p.deleted_at IS NULL
  AND p.title LIKE CONCAT('%', '검색', '%')
ORDER BY p.created_at DESC, p.post_id DESC
LIMIT 20 OFFSET 1000;

-> Limit: 20 row(s)  (cost=1.21e+6 rows=20) (actual time=6763..6763 rows=20 loops=1)     
-> Sort: p.created_at DESC, p.post_id DESC, limit input to 20 row(s) per chunk  (cost=1.21e+6 rows=10.9e+6) (actual time=6763..6763 rows=20 loops=1)         
-> Filte...

여기에서 확인한 것은

type=ALL인가?(풀스캔 성향)
key=NULL인가?
Using where, Using filesort가 붙어 있는가?
rows examined가 얼마나 큰가?
actual time이 얼마나 나오는가?

확인한 결과 쿼리의 비용이 너무 크다고 생각했다.

3. 개선 가설과 실험 계획

3-1. 비교 후보

infix LIKE (%keyword%) Prefix LIKE (keyword%) MySQL Full-Text (기본) MySQL Full-Text + ngram Elasticsearch (전용 검색엔진)

3-2. 비교 포인트

실제로 검색 속도가 얼마나 빨라지나
한글 검색 퀄리티가 괜찮은가
운영하기 너무 복잡하지는 않나

4. infix LIKE (%keyword%)

일단 부분 포함 검색을 하고 싶어서 먼저 infix LIKE를 테스트 해보았다

4.1 %keyword%는 왜 위험한가?

MySQL 공식문서의 B-Tree 인덱스 특성 설명에 따르면, LIKE 비교에서 인덱스는 상수 문자열이며 선행 와일드카드가 없는 경우에 사용할 수 있다. 반대로 LIKE '%Patrick%'처럼 선행 와일드카드가 있는 경우는 인덱스를 사용하지 않는 예시로 제시된다. https://dev.mysql.com/doc/refman/8.4/en/index-btree-hash.html

나는 LIKE '%keyword%'에 ORDER BY + OFFSET까지 붙으면서 비용이 엄청 커진 상황인것 같다.

4.2 Locust 테스트

타임 아웃을 90초로 늘려서 테스트 했다. 그 결과 infix 검색에서 60~70초대 응답시간도 확인됐다.

GET /search/posts/infix (offset=0)

평균 61,943ms
p95 / p99 = 68,000ms / 68,000ms

GET /search/posts/infix (offset=1001+)

평균 65,939ms
p95 / p99 = 71,000ms / 71,000ms

5. Prefix LIKE (keyword%)

대비 실험으로 prefix 검색도 같은 조건에서 확인했다.

EXPLAIN
SELECT
    p.post_id,
    p.title,
    p.created_at
FROM post p
WHERE p.post_status = 'PUBLISHED'
  AND p.deleted_at IS NULL
  AND p.title LIKE CONCAT('검색', '%')
ORDER BY p.created_at DESC, p.post_id DESC
LIMIT 20 OFFSET 1000;

5-1. prefix가 인덱스 후보가 맞는데 못탔다.

MySQL 공식문서 기준으로 B-Tree 인덱스는 LIKE 'abc%'처럼 선행 와일드카드가 없는 상수 문자열일 때 인덱스를 사용할 수 있다.

그런데 내 실험에는 아래처럼 나왔다.

type = ALL key = NULL rows = 10,852,380 Extra = Using where; Using filesort

나는 풀스캔 + filesort가 발생했다. 좀 더 찾아본 결과 아래 이유도 고려해야 한다고 한다.

옵티마이저는 조건 조합, 정렬, 선택도, 사용 가능한 인덱스 상태를 보고 계획을 정한다.
MySQL 공식문서도 인덱스가 있어도 옵티마이저가 테이블 스캔을 선택할 수 있다고 설명한다.

5-2. EXPLAIN ANALYZE로 본 실제 비용 (prefix)

EXPLAIN ANALYZE
SELECT
    p.post_id,
    p.title,
    p.created_at
FROM post p
WHERE p.post_status = 'PUBLISHED'
  AND p.deleted_at IS NULL
  AND p.title LIKE CONCAT('검색', '%')
ORDER BY p.created_at DESC, p.post_id DESC
LIMIT 20 OFFSET 0;

-> Limit: 20 row(s)  (cost=1.21e+6 rows=20) (actual time=5339..5339 rows=20 loops=1)     
-> Sort: p.created_at DESC, p.post_id DESC, limit input to 20 row(s) per chunk  (cost=1.21e+6 rows=10.9e+6) (actual time=5339..5339 rows=20 loops=1)         
-> Filte...

EXPLAIN ANALYZE에서도 prefix 쿼리는 가볍지 않았다.

prefix로 바꿨다고 해도 현재 스키마/실행계획에서는 대용량 스캔 + 정렬 비용이 아직 너무 크다는 것을 확인했다.

5-3. Locust 테스트

Locust 결과에서도 prefix가 기대만큼 빠르지 않았다.

GET /search/posts/prefix (offset=200~1000)

평균 65,723ms
p95 / p99 = 68,000ms / 68,000ms

5-4. prefix 정리

prefix LIKE는 B-Tree 인덱스를 탈 수 있는 형태가 맞다.

근데 내 실험 조건에서는 prefix도 EXPLAIN상 풀스캔/파일정렬로 나왔고, 부하 테스트에서도 병목이 해소되지 않았다.

그래서 prefix는 비교 기준점으로만 해보고, 이후 실험은 Full-Text / ngram / Elasticsearch로 넘어갔다.

6. MySQL Full-Text (기본)

LIKE '%keyword%' 병목을 확인한 뒤, 다음으로 시도한 것은 MySQL Full-Text 검색이었다. 목표는 단순했다.

풀스캔 성향을 줄일 수 있는지
실제 API 응답시간이 내려가는지
키워드(한글/영문)에 따라 어떤 차이가 나는지

6-1. Full-Text 인덱스 추가

ALTER TABLE post
ADD FULLTEXT INDEX ft_title_content (title, content);

6-2. MATCH ... AGAINST 사용해보기

SELECT post_id, title
FROM post
WHERE MATCH(title, content)
      AGAINST (:keyword IN NATURAL LANGUAGE MODE)
ORDER BY created_at DESC
LIMIT 20;

초기 가설은 이랬다.

LIKE '%keyword%'보다 Full-Text가 유리할 가능성이 크다.
영문/공백 기반 검색에서는 개선될 가능성이 있다.
한글은 토큰화 방식 때문에 품질/성능 편차가 클 수 있다.

6-3. 수동 호출(브라우저 네트워크 탭)키워드별 속도

먼저 브라우저에서 키워드를 직접 넣어 호출해보니,키워드에 따라 시간이 크게 달랐다.

spring 검색: 약 13.75초

redis 검색: 약 8.98초

explain 검색: 약 1.20초

query 검색: 약 1.84초

Full-Text를 붙였다고 해서 일괄적으로 빨라지는 게 아니었다. 키워드에 따라 결과 건수(선택도), 토큰화 방식, 정렬 비용이 달라지면서 응답시간 편차가 나오는 것 같았다.

6-4. Locust 부하 테스트 결과 (Full-Text / Natural)

Locust로 같은 엔드포인트를 부하 테스트했을 때도 비슷한 패턴이 나왔다. 응답시간 분포가 넓었다. 키워드에 따라 편차가 있었다.

6-4-1. 초기 Locust 스크립트의 /posts 키워드 풀 요청도 매우 느렸다.

초기 테스트 스크립트에는 키워드 풀 갱신용 /posts 요청이 포함되어 있었는데, 이 요청 자체도 느려서 aggregate 수치를 제대로 나오지 않게 할 수 있던 것 같다. 그래서 이후로는 합계만 보지 않고, 검색 엔드포인트 row를 따로 보는 방식으로 정리해야겠다고 생각했다.

6-4-2. Full-Text 검색 엔드포인트 자체도 여전히 느리다.

동일 표에서 Full-Text 검색 API는 아래 수준이었다

GET /search/posts/fulltext (offset=0)
- 평균 11,165.51ms
- p95 25,000ms
- p99 25,000ms
GET /search/posts/fulltext (offset=1~200)
- 평균 12,805.45ms
- p95 25,000ms
- p99 25,000ms
GET /search/posts/fulltext (offset=201~1000)
- 평균 14,099.95ms
- p95 26,000ms
- p99 26,000ms
GET /search/posts/fulltext (offset=1001+)
- 평균 13,082.16ms
- p95 26,000ms
- p99 27,000ms

LIKE '%keyword%'보다 개선된 구간이 있더라도, 서비스 응답시간 관점에서 봤을 때 여전히 수 초~수십 초가 나오고 있었다. 내 목표에서는 아직 충분하지 않았다고 생각했다.

6-5. Full-Text 기본 파서에서 확인한 한계

이 실험에서 확인한 건 단순히 느리다/빠르다가 아니었다.

키워드별 편차가 매우 큼 (query는 몇초, spring/redis는 수십초까지)
ORDER BY created_at DESC + LIMIT/OFFSET가 붙으면서 정렬 비용이 계속 커짐
한글/짧은 키워드는 검색 품질과 성능이 모두 불안정할 수 있음. 어떤 단어는 아예 안나오기도 하고 너무 느리기도 했다.

7. MySQL Full-Text + ngram

기본 Full-Text의 다음 후보는 ngram 파서였다. 한글 검색에서 찾아보니 많이 보여서 직접 해보고 싶었다.

기본 파서: 단어/공백 기반에 가까움
ngram 파서: 문자열을 n-그램(예: 2글자 단위)으로 쪼개서 색인

한글 부분 검색 기대치에는 더 맞을 수 있다. 대신 인덱스/성능 비용이 늘어날 수 있다고 한다.

7-1. ngram 인덱스 생성

ALTER TABLE post
ADD FULLTEXT INDEX ft_title_content_ngram (title, content) WITH PARSER ngram;

7-2. 동일 쿼리로 비교

SELECT post_id, title
FROM post
WHERE MATCH(title, content)
      AGAINST (:keyword IN NATURAL LANGUAGE MODE)
LIMIT 20;

7-3. 브라우저에서 본 ngram/boolean 편차

브라우저에서 FULL-TEXT-BOOLEAN 테스트를 해보니, 한글 키워드에서도 결과가 나오긴 하지만 편차가 매우 컸다. 어떤 키워드는 잘나오기도 했지만 아예 검색이 안되기도 하고, ngram없을때보다 더 느리게 나오기도 했다.

테스, 테 계열: 약 2.47초 ~ 3.45초

query: 약 12.33초

추적: 약 2.40초

쿼리: 약 55.68초

같은 모드에서도 키워드 선택도와 토큰 분해 결과에 따라 시간 편차가 매우 큰 걸 확인할 수 있었다.

7-4. Locust 결과 (Full-Text + ngram 키워드)

Locust에서도 NGRAM_KEYWORDS (한글 + 영어 키워드)로 분리해서 테스트했는데, 응답시간 분포가 더 거칠게 나왔다.

offset=0
- 평균 46,122.36ms
- p95/p99 90,000ms / 90,000ms
- 최대 90,001ms
offset=1~200
- 평균 40,644.15ms
- p95/p99 73,000ms / 73,000ms
offset=201~1000
- 평균 29,365.20ms
- p95/p99 48,000ms / 48,000ms
offset=1001+
- 평균 31,644.53ms
- p95/p99 45,000ms / 45,000ms

Locust 설정의 read timeout(90초)로 설정을 해놨기 때문에 90초동안 못받고 실패한 것이다.

7-5. Boolean 모드

Boolean 모드도 같이 테스트했지만, 키워드/offset에 따라 편차가 컸다.

GET /search/posts/fulltext-boolean (offset=0)
- 평균 52,375.67ms
- p95/p99 90,000ms / 90,000ms
GET /search/posts/fulltext-boolean (offset=1~200)
- 평균 52,556.51ms
- p95/p99 90,000ms / 90,000ms

오히려 키워드와 데이터 분포에 따라 극단적인 지연/타임아웃이 계속 발생했다.

7-6. ngram 정리

이번 실험에서 내 환경 기준으로 확인한 점은 다음과 같다.

기본 Full-Text에서 잘 안 맞는 부분 검색 기대치를 맞출 가능성이 있다.
짧은 한글 키워드는 후보가 많아질 수 있고 ORDER BY + OFFSET 비용과 겹치면 응답시간이 급격히 느려졌다.
키워드 편차가 상당히 크다.

ngram은 검색 품질 개선에는 유효할 가능성이 있었지만, 내 조건에서는 성능 안정성이 생각보다 나오지 않았다. 그래서 다음 단계로 Elasticsearch를 붙여 비교하게 되었다.

8. 정리

8-1. 증상

LIKE '%keyword%' 검색에서 응답시간이 급격히 증가했다
ORDER BY created_at DESC + LIMIT/OFFSET 조합으로 정렬/페이징 비용이 커졌다
Locust에서 p95/p99가 빠르게 상승했고, 일부 구간은 타임아웃 상한에 걸렸다
prefix LIKE(keyword%)도 이론상 유리할 수 있지만, 내 실험 조건에서는 EXPLAIN상 풀스캔(type=ALL, key=NULL)이 나왔다
MySQL Full-Text / ngram도 적용해봤지만, 키워드/모드/offset에 따라 응답시간 편차가 매우 컸다 (+ 그래도 느렸다)

8-2. 이번 글 결론

이번 실험에서 확인한 핵심은 아래였다.

검색 병목의 출발점은 단순히 DB가 느리다가 아니라 LIKE '%keyword%' + 정렬 + OFFSET 의 비용이 상당히 컸다.
MySQL Full-Text와 ngram은 개선 가능성은 확인했지만, 나는 성능 안정성과 검색 품질이 좀 더 필요하다고 생각했었다.
데이터 규모와 요구사항에 맞는 검색 전략을 잘 선택해야 하겠다고 생각이 들었다.

8-3. 다음 글

그래서 다음 글에서는 Elasticsearch를 실제로 도입한 과정, DB데이터를 ES에 적재한 경험, 테스트 결과를 정리하려고 한다.

대량 적재 중 겪었던 문제들 (OFFSET 병목, document_id 덮어쓰기, 필드명 mismatch)
MySQL → Logstash → Elasticsearch 재색인 과정
Spring 검색 API 연동 시 발생한 매핑/날짜 파싱 이슈
Locust로 확인한 ES 검색 성능 결과

개선 과정은 다음 글에 정리하겠습니다.

자동 배포(ECR/ECS) 구축하면서 터진 오류 유형과 해결 과정

Thu, 12 Feb 2026 14:02:04 GMT

지난 글에서는 git tag 푸시로 GitHub Actions => ECR push => ECS 롤링 배포가 되는 CI/CD 파이프라인을 구성했다. 이번 글에서는 구축 과정에서 실제로 마주쳤던 오류들을 증상 => 원인 => 확인 => 해결 순서로 정리했다.

같은 에러를 다시 만났을 때 해결 방법을 바로 떠올릴 수 있도록, 내가 확인했던 포인트까지 함께 정리했다.

0. 내 배포 구성

Trigger: git tag v0.0.1 && git push --tags
CI: GitHub Actions (OIDC)
Image: Amazon ECR
Runtime: Amazon ECS + Service 롤링 배포
Secret: AWS Secrets Manager → Task Definition secrets.valueFrom 주입
Log: CloudWatch Logs (awslogs)

1. 내가 확인한 정보들

나는 에러가 났을때 아래 정보들을 확인했다.

GitHub Actions 로그: OIDC/권한, ECR push, ECS deploy 단계
ECS Service 이벤트: 배포 실패 이유
ECS Task 목록/상세: STOPPED 이유, exit code
CloudWatch Logs: 스프링 부트 로그

2. 클러스터 생성 실패: Unable to assume the service linked role

클러스터 생성 중 아래 오류가 발생했다.

CreateCluster Invalid Request: Unable to assume the service linked role. Please verify that the ECS service linked role exists.

에러 로그

클러스터 service-cluster 생성 중 오류가 발생했습니다. 
Resource handler returned message: "Invalid request provided: CreateCluster Invalid Request: Unable to assume the service linked role.
Please verify that the ECS service linked role exists. (Service: AmazonECS; Status Code: 400; Error Code: InvalidParameterException;
Request ID: c2aa1ff6-cda9-4955-84ae-ad63fb144861; Proxy: null)" (RequestToken: 3747083a-bed9-1901-3746-7539ec34229c, HandlerErrorCode: InvalidRequest)

ECS가 내부적으로 사용하는 Service linked role이 계정에 없거나(삭제), ECS가 그 Role을 Assume 할 수 없는 상태다.

원인

현재 계정/권한 정책이 iam:CreateServiceLinkedRole 같은 작업을 막음
드물게 IAM 설정이 꼬여 Role이 있으나 ECS가 정상 assume 실패

확인 방법 IAM 콘솔 => Roles(역할)에서 아래 이름을 검색한다. AWSServiceRoleForECS 가 있는지 찾아본다.

해결 방법 Service linked role을 생성한다. 생성후에 클러스터 생성을 다시 시도하면 해결된다.

3. GitHub Actions 배포 실패: Error: Service is INACTIVE

GitHub Actions의 amazon-ecs-deploy-task-definition 단계에서 아래 에러가 났다.

Error: Service is INACTIVE

의미

워크플로우가 가리키는 ECS 서비스가 존재는 하되 INACTIVE 상태라는 뜻이다.

원인

서비스가 삭제되었거나
생성이 실패해서 활성화되지 못했거나
다른 이름/다른 클러스터를 가르키는데 변수만 남아있는 경우

확인 방법

ECS 콘솔 → Cluster → Services에서 weblog-service가 ACTIVE인지 확인
GitHub Variables의 ECS_CLUSTER, ECS_SERVICE가 콘솔 이름과 일치하는지 확인

나는 github variables에 이름 설정이 동일하지 않아 오류가 났었다.

해결

서비스가 없거나 비활성(INACTIVE)이면 서비스를 정상 생성한다.
서비스 이름이 바뀌었다면 GitHub Variables의 ECS_SERVICE를 최신으로 수정한다.

4. ECS 배포 실패: ECS Deployment Circuit Breaker was triggered

ECS 쪽 이벤트에서 아래 메시지가 보였다.

ECS Deployment Circuit Breaker was triggered

이 메시지는 ECS가 배포를 포기했다는 뜻이다. 원인은 task에 있다.

의미

배포된 새 태스크들이 정상 상태에 도달하지 못해서 ECS가 자동으로 배포를 중단한 것이다.

원인

태스크가 뜨자마자 죽는다 (컨테이너 exit)
헬스체크가 계속 실패한다 (ALB/컨테이너 헬스체크)
초기화 단계에서 막힌다 (Secrets/Logs/Pull 등 ResourceInitializationError)

해결

ECS → Service → Tasks 탭에서 STOPPED가 있는지 확인
STOPPED 태스크 클릭 → Stopped reason / Container exit code 확인
Container → CloudWatch logs 열기
로그에서 원인을 확인하고 수정하기

5. 태스크가 계속 중지됨: Essential container in task exited + Exit code 1

Tasks 목록에서 반복적으로 아래 상태가 쌓였다.

Essential container in task exited

그리고 Task 상세에서 컨테이너가:

Stopped | 종료 코드: 1

의미 스프링 부트 컨테이너가 실행 직후 에러로 종료된 것이다. 서비스는 태스크를 유지해야 하므로 재기동을 반복하다가 배포가 실패한다.

원인

DB 연결 실패 (보안그룹/URL/계정/비번)
환경변수 누락 (SPRING_DATASOURCE_URL, USERNAME 등)
Secrets Manager 주입 실패로 필수 값이 비어있음
포트 불일치(앱이 8080인데 설정은 다른 포트 설정)

확인 방법 CloudWatch Logs에서 스프링이 왜 죽었는지를 보거나 태스크가 중단되었을때 태스크 로그에서 스프링 로그를 확인해보면 된다.

나의 경우에는 secret manager에서 ARN 키 지정을 잘못 사용해서 DB 연결이 실패해 저 오류가 났었다.

해결

RDS 보안그룹 인바운드에 ECS 태스크 보안그룹을 Source로 허용했는지
Task Definition의 DB URL/USERNAME이 정확한지
비밀번호는 environment가 아니라 secrets로 들어가며 ARN 포맷이 맞는지
포트 설정이 8080 기준으로 일치하는지

6. 초기화 단계에서 막힘: ResourceInitializationError: failed to validate ...

Tasks 목록에 아래처럼 뜨고 바로 STOPPED 됐다.

ResourceInitializationError: failed to validate ...

원인

Secrets 주입 단계 실패
CloudWatch Logs 설정 문제
Execution Role의 ECR pull 권한 부족

확인 방법 STOPPED task를 클릭해 상세 메시지에서 secrets, logs, pull 키워드를 확인한다.

나의 경우는 task-definition에 awslog-group이름과 실제 log group 이름이 달라서 오류가 났었다.

해결 방향

secrets 관련: Execution Role에 secretsmanager:GetSecretValue 추가, ARN/키 지정(:password::) 재확인
logs 관련: Log Group 존재 여부, Execution Role의 logs 권한 및 region/이름 일치 확인
pull 관련: ECR 권한 및 네트워크 점검

7. 결론

특히 권한이나 리소스 이름(서비스/클러스터/로그 그룹) 같은 기초 설정이 아주 조금만 달라도 배포가 전혀 안됬다. 나의 경우 문제가 생겼을 때는 바로 STOPPED task와 CloudWatch logs를 먼저 확인하는 것이 가장 빠르게 해결이 됬다.

ECS + ECR + GitHub Actions로 Spring Boot 배포 자동화(CI/CD) 구축하기

Mon, 09 Feb 2026 21:01:36 GMT

0. 목표

0.1 요약

먼저 ECR에 리포지토리 만들고 docker 빌드 파일 업로드하기
ECS에서 클러스터를 하나 만들고 태스크 정의를 ECR에서 만든 docker로 설정하기
GitHub Actions Workflow로 배포 설정하기

0.2 목표

로컬에서 docker-compose up으로 돌리던 Spring Boot 서버를, CI/CD 자동화 구축을 하게 만들어 보고자 했다.

git tag v0.0.1
git push --tags

나는 이런식으로 태그를 붙여서 push하면 자동으로 배포까지 되는 것을 원했다.

GitHub Actions이 Docker 이미지를 빌드해서 Amazon ECR에 push한다.
Amazon ECS가 새 이미지를 가져와서 배포한다.
RDS(MySQL) 비밀번호와 JWT 시크릿은 AWS Secrets Manager로 관리하고, 태스크 실행 시 주입한다.

1. 아키텍처

아래 사진은 CI/CD 흐름도이다.

Secrets Manager는 태스크가 시작될 때 ECS가 값을 조회해 컨테이너 환경변수로 주입한다. CloudWatch Logs는 컨테이너 표준 출력 로그를 전송해 확인한다.

2. 준비

2.1 애플리케이션 포트/환경변수

Spring Boot 컨테이너는 8080을 포트로 썼다.

DB 정보는 ECS Task 환경변수로 주입한다.

SPRING_DATASOURCE_URL SPRING_DATASOURCE_USERNAME SPRING_DATASOURCE_PASSWORD (Secrets manager로 넣기)

3. ECR 리포지토리 만들기

ECR에서 리포지토리를 생성한다.

이 리포지토리에 GitHub Actions가 빌드한 Docker이미지를 푸시한다.

4. RDS(MySQL)

서버에서 사용할 RDS의 URL이나 비밀번호 같은것을 정리해서

4.1 RDS 정보

ECS 태스크는 스프링 부트 컨테이너를 실행하고, 그 컨테이너는 DB에 접속하기 때문에 DB정보를 태스크에 넣어줘야 한다. 사용하는 RDS의 URL, password, username등을 잘 알아두어야한다.

SPRING_DATASOURCE_PASSWORD
SPRING_DATASOURCE_URL
SPRING_DATASOURCE_USERNAME

4.2 보안그룹(Security Group)

RDS 인바운드 규칙을 설정해줘야한다.

Type: MySQL/Aurora (3306) Source: CS Task가 사용하는 보안그룹 이런식으로 ECS 보안 그룹을 허용해주면 된다. 그러면 ECS에서만 DB접근이 가능하게된다.

ECS서비스를 만들 때 어떤 보안그룹을 붙였는지 확인하고 그 보안그룹을 RDS 인바운드에 넣어야한다.

5. Secrets Manager 만들기

5.1 Secret 생성 타입

Amazon RDS 데이터베이스 자격 증명 타입으로 만들면 편하다.

새 보안 암호 저장을 누르고 DB에서 사용하는 비번같은 비밀정보를 넣어서 사용하면 된다.

레포지토리가 public이기때문에, 비밀번호/JWT 시크릿을 코드나 GitHub 저장소에 직접 적지 않는다.

5.2 ECS Task Definition에서 valueFrom으로 주입하기

secrets사용법에서 조금 헷갈렸는데 보안 암호 세부 정보에서 보안암호 ARN 정의에서 secret 사용은 이렇게 했다.

ECS 태스크 정의에서 secrets에 valueFrom으로 ARN을 넣는다. Secrets Manager ARN은 :키이름:: 형태로 특정 키를 지정할 수 있다.

ex) arn:~~~~:secret:service_name:root_password::

"secrets": [
  {
    "name": "SPRING_DATASOURCE_PASSWORD",
    "valueFrom": "arn:aws:secretsmanager:ap-northeast-2::secret:XXXXXX"
  }
]

6. CloudWatch Logs

log를 남겨서 보고 싶어서 cloudWatch로 로그를 남겨놓도록 설정해놨다. 이부분은 사실 하지 않아도 된다.

ECS 컨테이너 로그를 CloudWatch로 보내려면 CloudWatch Log Group을 미리 만들어야한다.

Task Definition 로그 설정에 awslogs를 넣고 CloudWatch에서 같은 이름의 로그 그룹을 만들어 주면 된다.

예: /ecs/service/log 로 로그 그룹을 만들었다면

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/service/log",
    "awslogs-region": "ap-northeast-2",
    "awslogs-stream-prefix": "ecs",
    "awslogs-create-group": "true"
  }
}

7. IAM 권한 구성

권한은 두 종류로 나눠서 만든다.

7.1 ECS Task Execution Role

아래 사진을 보면 weblog-ecs-secrets-read이라고 커스텀 권한이 있는데 Secrets Manager read write 아님 GetSecretValue 같은 것을 넣어줘도 될 것이다. ecs는 배포하고 실행까지 하기 때문에 RDS에 접근해야한다. 그래서 RDS비밀번호가 있는 Secrets Manager 권한이 필요하다.

7.2 GitHub Actions 배포 Role (OIDC)

GitHub Actions가 AWS에 배포를 하려면 OIDC Role이 필요하다. 나는 Access Key를 저장하지 않고, OIDC로 임시 자격 증명을 발급받는 방법을 사용했다.

8. ECS 클러스터 생성

쉽게 말해보면 ECS는 우리가 사용하는 컨테이너(Docker 같은 것)를 관리하기 위한 도구이다. 컨테이너를 쉽게 실행, 중지하는 등의 관리가 가능하다.

9. Task Definition 작성

나는 레포에 .aws/ecs/task-definition.json로 고정을 해두었다.

9.1 레포 구조

9.2 Task Definition

내가 사용하는 Def구조이다. 여기를 참고하면 더 자세히 볼 수 있다.

{
  "family": "여기에 task이름",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole 여기에 역할 ARN넣기",
  "taskRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole 여기도",
  "containerDefinitions": [
    {
      "name": "태스크 안 컨테이너 이름",
      "image": ".dkr.ecr.ap-northeast-2.amazonaws.com/service:latest",
      "essential": true,
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "environment": [
        { "name": "SPRING_DATASOURCE_URL", "value": "jdbc:mysql://:3306/serviceDB?serverTimezone=Asia/Seoul&characterEncoding=UTF-8&sslMode=REQUIRED" RDS URL넣기},
        { "name": "SPRING_DATASOURCE_USERNAME", "value": "service_root" RDS에서 사용하는 이름}
      ],
      "secrets": [
        { "name": "SPRING_DATASOURCE_PASSWORD", "valueFrom": "arn:aws:secretsmanager:ap-northeast-2::secret:service-db-password-XXXXXX:password::" 여기는 secretmanager에 비번 ARN}
      ],
      "logConfiguration": { CloudWatch를 안쓰면 없애야함
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/weblog",
          "awslogs-region": "ap-northeast-2",
          "awslogs-stream-prefix": "ecs",
          "awslogs-create-group": "true"
        }
      }
    }
  ]
}

DB 비번은 environment가 아니라 secrets을 썼다. 로그를 설정하면 CloudWatch log group이랑 IAM권한도 맞춰줘야 한다.

10. ECS 서비스 생성

클러스터 위에 서비스를 만들면, 서비스는 태스크를 항상 N개 유지하고, 새 task definition이 올라오면 롤링 배포를 한다.

11. GitHub Actions Workflow

11.1 레포 변수/시크릿

나는 Github에있는 레포 변수값을 사용했다 위치는 아래 사진과 같다.

Variables

AWS_REGION
ECR_REPOSITORY
ECS_CLUSTER
ECS_SERVICE
ECS_TASK_DEFINITION
CONTAINER_NAME

Secrets

AWS_ROLE_TO_ASSUME (OIDC role arn)

11.2 워크플로우

내가 사용한 워크플로우는 아래와 같다.

name: Deploy to ECS

on:
  push:
    tags: ["v*"]
  workflow_dispatch:

env:
  AWS_REGION: ${{ vars.AWS_REGION }}
  ECR_REPOSITORY: ${{ vars.ECR_REPOSITORY }}
  ECS_CLUSTER: ${{ vars.ECS_CLUSTER }}
  ECS_SERVICE: ${{ vars.ECS_SERVICE }}
  ECS_TASK_DEFINITION: .aws/ecs/task-definition.json
  CONTAINER_NAME: ${{ vars.CONTAINER_NAME }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build, tag, and push image to ECR
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.ref_name }}
        run: |
          IMAGE_URI="$ECR_REGISTRY/${{ env.ECR_REPOSITORY }}:$IMAGE_TAG"
          echo "IMAGE_URI=$IMAGE_URI" >> $GITHUB_OUTPUT

          docker build -t "$IMAGE_URI" .
          docker push "$IMAGE_URI"

      - name: Render Amazon ECS task definition
        id: render-task
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ${{ env.ECS_TASK_DEFINITION }}
          container-name: ${{ env.CONTAINER_NAME }}
          image: ${{ steps.build-image.outputs.IMAGE_URI }}

      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: ${{ steps.render-task.outputs.task-definition }}
          service: ${{ env.ECS_SERVICE }}
          cluster: ${{ env.ECS_CLUSTER }}
          wait-for-service-stability: true

11-3. 워크플로우 설명

on:은 워크플로우 트리거이다. tag에 v가 붙은게 푸시된다면 실행이 된다. (v0.0.1, v1,2,4같은 태그) env:는 워크플로우 전역 환경변수이다.. 여기에서 github variables에 있는것을 가져와서 썼다. jobs:는 수행할 작업을 넣는 곳이다. 서로 병렬 실행도 가능하다고 한다. jobs: 안 steps: 위에서 아래로 순서대로 실행된다. 각 step에 무슨 이름(name), 어떤 액션(uses), 어떤 쉘 명령(run)하는지 들어간다.

나는 워크플로우 안에 순서대로

Checkout (여기에서 레포 소스코드 내려받음)
Configure AWS credentials (여기에서 AWS 자격증명을 한다. 저기 넣어놓은 AWS_ROLE_TO_ASSUME으로 임시 자격 증명을 받아 다음 작업들을 할 수 있다)
Login to Amazon ECR (ECR에 docker push를 함)
Build, tag, and push image to ECR (도커 이미지를 만들고, 이미지를 빌드하고, 태그를 붙인 후 ECR에 올림)
Render Amazon ECS task definition (task-definition.json을 읽고 container-name에 해당하는 이미지로 태스크를 정의함)
Deploy Amazon ECS task definition (정의된 태스크를 ECS에 등록하고 여기에 들어가있는 클러스터의 서비스를 그 새 태스크로 업데이트를 함)

12. 태그 푸시 후 배포

12.1 태그 푸시

git tag v0.0.1
git push --tags

12.2 성공

13. 결론

배포 방식을 태그 푸시 기반 자동 배포로 바꿨다.
ECS_CLUSTER, ECS_SERVICE는 ECS 콘솔에 표시된 실제 이름을 그대로 사용해야 한다.
Secrets Manager는 ARN으로 주입하며, Task Execution Role에 GetSecretValue 권한이 필요했다.
IAM과 보안 그룹 설정은 너무 어려웠고 중요하다라는 걸 알게됐다. 권한이랑 인바운드 규칙이 달라지면 바로 에러를 쏟아냈다.

다음 글에서는 이 인프라를 구축하면서 겪었던 오류 유형과 해결 과정을 정리해보겠다.

블로그 인기글 부하 테스트 병목현상 개선 과정 2

Wed, 04 Feb 2026 01:25:31 GMT

이전 글에서 약 10만 건 데이터 기준으로 부하 테스트를 했고, connection refused / 지연 폭증 / Hikari pending 증가 / InnoDB row lock wait 증가까지 연쇄 병목을 확인했다. 이번 글에서는 무엇을 어떻게 개선했고, 왜 그 실험을 했는지를 쓸 예정이다.

0. 실험 목표, 기준

0-1. 목표

Locust failures 감소 p95/p99 지연 감소 InnoDB row lock wait 감소 Hikari pending 감소 Tomcat threads/connections 상한 도달 방지 를 달성하는 것을 목표로 했다.

0-2. 테스트 설계

데이터 규모: 게시글 10만건 트래픽 믹스: 핫스팟 80 / 랜덤 20 Locust 시나리오 대로 실험

1. 개선 후보

개선은 할게 끝이 없다고 생각했다. 그래서 3가지를 잡았다.

리소스 상한 튜닝하기 (Tomcat/Hikari)
DB 최적화하기 (쿼리/인덱스/트랜잭션)
아키텍처 변경하기 (Redis/비동기/배치)

2. 실험 설계

2-1. 테스트를 분리

Break test(파괴 테스트): 유저 10,000(스텝 1,000)

Observation test(관측 테스트): 유저 1,000(스텝 100)

파괴 테스트는 failures가 너무 많으면 p95 같은 지표가 왜곡되기 쉽다. 그래서 원인 추적은 관측 테스트 구간에서 진행했다.

2-2. 비교 지표

Locust: failures, RPS, p95/p99, (가능하면 실패 사유 캡처)

DB: Innodb_row_lock_waits, Innodb_row_lock_time

Hikari: active/idle/pending

Tomcat: threads.busy/current/max, connections.current/max, keepalive

3. 상한 튜닝 먼저 해보기

이 실험의 목적은 간단하다.

연결 거절/타임아웃은 줄어들 수 있지만, DB row lock 병목은 남는다. 그냥 조금 더 버틸 것이다.

3-1. 변경한 것

properties

# Tomcat tuning
server.tomcat.threads.max=400
server.tomcat.max-connections=20000
server.tomcat.accept-count=200

# HikariCP tuning 새 요청이 커넥션을 못받고 3초 지나면 타임아웃 에러
spring.datasource.hikari.maximum-pool-size=50
spring.datasource.hikari.minimum-idle=50
spring.datasource.hikari.connection-timeout=3000

3-2. 관측 결과

ERROR [http-nio-8080-exec-386] o.a.c.c.C.[.[.[.[dispatcherServlet] - 
Servlet.service() for servlet [dispatcherServlet] in context with path 
[] threw exception [Request processing failed: org.springframework.transaction.CannotCreateTransactionException: 
Could not open JPA EntityManager for transaction] with root cause
java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available,
request timed out after 3003ms (total=50, active=50, idle=0, waiting=2)...

Hikari 풀을 50으로 늘렸지만, 요청이 증가하면서 active가 50까지 고정되고 idle은 0이 된다.
그 상태에서 신규 요청은 커넥션을 얻지 못하고 connectionTimeout(3s) 이후 실패한다.
스프링에서는 트랜잭션을 시작하기 위해 EntityManager를 열어야 하는데 커넥션을 못 얻어서 CannotCreateTransactionException으로 떨어진다.

상한을 늘려 더 많이 받는 것처럼 보였지만 결국 DB병목이 남아있으면 실패가 발생했다.

3-3. 한 줄 결론

상한을 늘리면 좀 더 늦게 밀리지만, 조회수 UPDATE라는 단일 row 핫스팟은 그대로라서 결국 다시 같은 형태로 포화된다.

4. DB 최적화하기

4-1. 변경한 것

트랜잭션 범위 최소화 이전 코드는 서비스 클래스에 @Transactional이 잘못 걸려서, 조회 API까지도 불필요하게 트랜잭션이 넓게 잡힐 수 있었다.

트래픽이 몰릴 때 DB가 느려지면 트랜잭션이 길어질 것이다. 그리고 트랜잭션을 메서드 단위로 다시 분리했다.

Post get 메소드

    @Override
    @Transactional(readOnly = true)
    public PostDetailDto getPost(Long id) {
        viewCountService.increment(id);
        return PostDetailDto.from(postRepository.findById(id).orElse(null));
    }

ViewCountService

    @Transactional // 또는 REQUIRES_NEW (의미를 더 강하게 주고 싶으면)
    public void increment(Long postId) {
        postRepository.incrementViewCount(postId);
    }

이런식으로 커넥션을 조금이라도 짧게 잡아보고자 생각해봤다.

인기글 쿼리 인덱스 추가 10만 건 기준에서 인기글 API는 아래 쿼리를 사용한다. WHERE post_status = 'PUBLISHED' ORDER BY view_count DESC LIMIT 20

데이터가 적을 떄는 티가 많이 나지 않지만, 데이터가 커지면 비용이 크게 늘어날 수 있다. 그래서 post_status, view_count가 인덱스를 타도록 추가했다.

CREATE INDEX idx_post_status_viewcount ON post (post_status, view_count, post_id);

EXPLAIN ANALYZE 결과 실제로 굉장히 많이 줄어든 것을 확인할 수 있었다. 인덱스 추가 전에는 Sort가 들어가 있고 수십 ms가 걸렸다.

인덱스 추가 전

-> Limit: 20 row(s)  (cost=10164 rows=20) (actual time=65.7..65.7 rows=20 loops=1)
     -> Sort row IDs: p.view_count DESC, limit input to 20 row(s) per chunk  
     (cost=10164 rows=99148) (actual time=65.7..65.7 rows=20 loops=1)
         -> Filter: (p.post_sta...

인덱스 추가 후

-> Limit: 20 row(s)  (cost=5704 rows=20) (actual time=0.0324..0.067 rows=20 loops=1)
     -> Filter: (p.post_status = 'PUBLISHED')  (cost=5704 rows=49574) (actual time=0.0317..0.0657 rows=20 loops=1)
         -> Index lookup on p using idx_post_status_view...

인덱스 추가 후에는 Sort가 사라지고 Index lookup으로 바뀌었다. 실행 시간도 크게 줄어들었다.

4-2. 테스트 결과

튜닝 후 (10,000명) 튜닝 이후에도 전과 비슷하게 RPS가 급격하게 오르며 실패율이 굉장히 높아졌다.

튜닝 전(1,000명) 하지만 튜닝 전 1,000명 테스트에서 RPS가 60대였고, 응답속도가 계속 증가하는 것을 볼 수 있다.

튜닝 후 (1,000명) 튜닝 후 1,00명 테스트에서 RPS가 약 300까지 상승해 개선효과가 있었다.

그리고 실패율이 상대적으로 안정되고, p95/p99도 10,000 유저 대비 훨씬 완만한 형태로 보였다. 이 결과로 볼 때, 인기글 쿼리 인덱스 적용으로 정렬/스캔 비용이 크게 완화되었고, 중간 부하 구간에서는 처리량이 눈에 띄게 개선됐다.

4-3. 결론

인기글 인덱스 튜닝으로 정렬/스캔 비용은 줄어 중간 부하(1,000명)에서는 처리량이 크게 개선됐지만, 조회수 증가 UPDATE는 여전히 단일 row 핫스팟 쓰기 병목이라 고부하(10,000명)에서는 커넥션 풀/스레드 포화로 다시 실패했다.

5. 샤딩 해보기

5-1 변경한 점

조회수 증가 로직 샤딩 카운터로 분리 기존 구현은 게시글 상세 조회 시 post.view_count = post.view_count + 1 업데이트가 발생했다. 트래픽이 몰리면 같은 post row를 계속 UPDATE하는 구조가 되고, 결국 row lock 경합과 InnoDB write 부담이 병목이 나는 상황이라고 생각했다.

그래서 post 테이블의 view_count 업데이트를 제거하고, 별도의 샤딩 카운터 테이블로 조회수 증가를 분리했다.

하나의 row에 쓰기가 몰리는 구조를 여러 row로 분산시키면 좋아지지 않을까라는 생각으로 시도해보았다.

테이블 구조 변경 post_view_counter_shard(post_id, shard_id, view_count) 형태로 테이블을 만들고, (post_id, shard_id)를 PK로 뒀다. 하나의 post에 shard 8개(0~7)가 존재하도록 구성했다.

조회수 증가 로직 변경 상세 조회 API에서 더 이상 post를 UPDATE하지 않고, shard_id를 랜덤으로 골라 해당 row만 증가시키도록 바꿨다.

PostServiceImpl

@Override
@Transactional
public PostDetailDto getPost(Long id) {
    viewCountService.incrementView(id);   // post 테이블 UPDATE 제거
    Post post = postRepository.findById(id).orElse(null);
    return PostDetailDto.from(post);
}

ViewCountService

private static final int SHARD_COUNT = 8;

@Transactional
public void incrementView(Long postId) {
    int shardId = ThreadLocalRandom.current().nextInt(SHARD_COUNT);
    repo.increment(postId, shardId);
}

PostViewCounterShardRepository

@Modifying
@Query(value = """
    UPDATE post_view_counter_shard
    SET view_count = view_count + 1
    WHERE post_id = :postId AND shard_id = :shardId
""", nativeQuery = true)
int increment(@Param("postId") Long postId, @Param("shardId") int shardId);

의도 같은 게시글의 조회수가 몰려도 업데이트 대상 row가 8개로 분산되기 때문에, 단일 row에 락이 몰리는 핫스팟을 완화하려고 했다.

한계 쓰기 경합은 줄일 수 있어도, 읽기와 랭킹에서 비용이 커졌다. 조회수 조회 시 SUM(view_count)로 8개 shard를 합산해야 했다.

인기글처럼 정렬/랭킹이 필요한 경우 ORDER BY SUM(view_count) DESC 형태가 되어서 쿼리가 너무 복잡해질 것이라고 생각했다.

데이터 규모가 너무 커진다고 생각했다. 지금 게시글이 10만개인데 게시글 개당 8개라고 생각하면 80만개가 들어가야한다. 게시글이 늘어날 수록 카운터 테이블과 인덱스도 함께 커지기 때문에 계속 불어난다고 생각했다.

5-2. 부하 테스트 결과

테스트 초반 응답 시간이 수 초~10초대로 급상승하는 구간이 존재했다.
이후 특정 시점부터 응답 시간이 급격히 내려가며, 동시에 RPS가 크게 상승하는 구간이 나타났다.
안정 구간 진입 이후에도 응답 시간과 RPS가 완만하게 오르내리는 파동이 반복됐다.

초반 급상승 => 급회복 => 안정 구간 파동패턴이 반복적으로 나타났다.

5-3. 왜 이렇게 나왔지?

포화 근처에서 시스템이 밀렸다가 회복되는 사이클로 해석하는 게 자연스럽다.

초반 급상승은 워밍업/콜드 상태 영향 가능성이 크다 테스트 시작 직후에는 JVM/DB/OS 캐시가 차지 않은 상태라 지연이 쉽게 튄다. 일정 시간이 지나면서 캐시가 채워지고 실행 경로가 안정화되면 응답 시간이 내려가서 이렇게 나왔다고 생각했다.

Locust(닫힌 모델) 특성 Locust는 요청 => 응답이 끝나야 다음 요청을 보내는 구조라, 서버가 느려지면 유저당 요청 빈도가 줄어 RPS가 내려가고, 잠깐 빨라지면 RPS가 다시 튄다.

그래서 응답 시간이 떨어지는 순간 RPS가 확 올라가는 모양이 만들어질 수 있다. 참고: 닫힌 모델 vs 열린 모델

5-4. Redis를 쓰기로 한 이유

샤딩 카운터는 DB에서 조회수 쓰기 핫스팟을 분산시키는 데는 도움이 됐지만, 구조적으로 한계가 있다고 생각했다.

조회수는 고빈도 쓰기인데 샤딩을 해도 조회 1회당 DB write 1회라는 건 바뀌지 않았다. 락 경합을 완화할 수는 있어도 쓰기 트래픽의 근본 비용은 계속 DB가 떠안게 됐다.
읽기에서 합산이 필요해졌고, 인기글처럼 정렬이 필요한 순간 너무 복잡해졌다. SUM(view_count) 기반 정렬은 쿼리 비용이 커지고, 결국 결과를 별도로 캐시하거나 집계 테이블로 머지하거나 랭킹을 미리 계산하는 작업이 필요해졌다.

Redis는 메모리 기반이라 INCR 같은 카운터 증가가 매우 가볍고, 랭킹은 Sorted Set으로 상위 N개 조회가 빠르다. 조회수처럼 쓰기 빈도가 극단적으로 높은 데이터와 인기글 조회를 DB보다 훨씬 단순한 형태로 처리할 수 있었다. DB는 데이터의 정합성과 영속 저장에 집중시키고, 조회수/랭킹처럼 변동이 극심한 값은 Redis로 분리하는게 더 좋아보인다고 생각했다.

5-5. 결론

DB에서 조회수는 결국 쓰기 핫스팟이었고, 샤딩으로 락을 완화할 수는 있었지만 읽기 합산/랭킹과 충돌하면서 복잡도가 급격히 증가했다. 그래서 조회수/랭킹은 Redis 같은 인메모리 구조로 분리하는 방향이 더 현실적이라고 생각했다.

6. Redis로 요청당 DB UPDATE 제거

요청 경로에서 조회수 쓰기(UPDATE) 를 빼버리는 방식으로 바꿨다.

기존에는 게시글 상세 조회 요청이 들어올 때마다 DB에서 view_count = view_count + 1 같은 쓰기 트랜잭션이 매번 발생했다. 이 구조는 트래픽이 몰릴수록 DB가 락/redo/flush 비용을 계속 떠안게 되고, 결국 조회 API인데도 DB write 병목이 터지는 형태라고 판단했다.

그래서 조회수와 랭킹은 Redis로 처리하고, DB 반영은 나중에 하는것으로 생각을 했다.

6-1. 변경점

요청 경로에서 DB UPDATE를 제거했다

상세 조회 요청이 들어와도 더 이상 DB에 조회수 UPDATE를 하지 않게 바꿨다. Redis에만 카운트를 올리도록 바꿨다.

조회수: HINCRBY (Hash)

랭킹: ZINCRBY (Sorted Set)

랭킹 쿼리를 DB 정렬에서 Redis ZSET으로 바꿨다 DB에서 인기글을 구하려면 ORDER BY view_count DESC LIMIT N을 계속 했어야 했다. Redis ZSET은 점수 기반 정렬이 기본이어서, 상위 N개 조회가 구조적으로 유리하다고 생각했다.

정합성은 최종 DB 반영이 아니라 요청 경로 분리가 목표였다

이 단계에서 목표는 완벽하게 실시간으로 DB에 맞추기가 아니었다. 목표는 요청 경로에서 write를 제거해 병목을 없애는 것이었다.

UI에서 보여줄 조회수는 Redis에서 읽으면 된다.

DB 반영은 배치/스케줄로 나중에 합쳐도 된다.

6-2. 테스트 결과

RPS 상승

Redis 적용 후 차트에서 피크 구간 RPS가 약 1,900~2,000 수준까지 올라간 구간이 확인됐다. 동일하게 1,000 유저 조건에서 진행했는데도, DB UPDATE를 제거하자 처리량 상한이 크게 올라갔다고 생각했다.

레이턴시가 급락하는 구간 존재

3시 6분쯤에는 지연시간이

p50 ≈ 360ms p95 ≈ 430ms

수준까지 내려간 구간이 보였다.

쓰기 제거가 응답시간과 처리량에 반영됐다고 생각했다.

6-3. 근데 그래프가 왜 이렇게 출렁거릴까?

차트가 반복적으로 출렁이는 이유는, 이번 캡처들이 DB가 완전히 병목에서 해방된 상태는 아니었기 때문이라고 생각했다.

Hikari 풀 자체가 꽉 찼다 hikaricp.connections.max = 10

hikaricp.connections.active = 10

hikaricp.connections.idle = 0

hikaricp.connections.pending ≈ 182 ~ 190

풀 최대치(10)까지 항상 active가 꽉 찼다. idle(대기 커넥션)은 0이었다 커넥션을 못 빌려서 기다리는 스레드(pending)가 180명대까지 쌓였다.

조회수 UPDATE는 Redis로 빠졌지만, 상세 조회 자체가 DB SELECT를 계속 필요로 했고 (게시글/태그/작성자 등), 그 read 트래픽으로 커넥션 풀이 꽉 찼다고 생각했다.

Locust의 닫힌 모델 이 패턴은 Locust가 기본적으로 요청 => 응답 후 다음 요청을 보내는 닫힌 모델이라, 서버가 잠깐 느려지면 RPS가 같이 내려가고, 잠깐 빨라지면 RPS가 튀는 특성이 반영된 결과로 볼 수 있다.

그래서 서버가 느려져 응답이 밀리면, Locust가 초당 요청을 덜 보내게 되고 RPS가 내려가고 잠깐이라도 응답이 빨라지면 유저들이 한꺼번에 더 자주 때리면서 RPS가 확 올라간것같다.

참고: 닫힌 모델 vs 열린 모델

6-4. 결론?

조회수 증가에서 요청당 DB UPDATE를 제거하자, 처리량이 눈에 띄게 올라갔다.

Failures/s가 0에 수렴하는 구간이 길게 유지되어, 쓰기 병목 패턴이 크게 줄었다고 봤다.

Actuator 지표에서 Hikari 풀(max=10)이 상시 포화(active=10, idle=0, pending 180~200) 상태였기 때문에, 병목이 완전히 사라진 것이 아니라 DB read/커넥션 풀이 병목이 됬다고 생각한다.

그래서 다음 단계는 Redis 도입 성공에서 끝이 아니라, DB 조회의 커넥션 점유 시간을 줄여서 병목을 완화시키는 게 목표이다.

7. 또 다른 병목

7-1. Read 병목

Redis로 조회수 UPDATE를 요청 경로에서 제거했지만, 병목이 완전히 사라진 것은 아니었다. Actuator에서 Hikari가 active=max, idle=0, pending 180+ 상태로 포화된 것을 확인했다. 즉, 병목이 write에서 read로 이동했다고 판단했다.

Locust 통계에서도 GET /posts (list)가 다른 API보다 지연이 크게 튀는 순간이 있었고, 그 타이밍에 전체 RPS가 함께 꺾였다. 목록(list)이 DB 커넥션을 오래 점유하면서 풀 포화를 유발했다고 해석했다.

7-2. 쿼리 인덱스 추가

목록 API는 PUBLISHED 필터와 정렬을 사용한다.

CREATE INDEX idx_post_status_created_at_id ON post (post_status, created_at, post_id);

튜닝 전

-> Limit: 50 row(s)  (cost=5704 rows=50) (actual time=103..103 rows=50 loops=1)     
-> Sort: p.created_at DESC, p.post_id DESC, limit input to 50 row(s) per chunk  
(cost=5704 rows=49574) (actual time=103..103 rows=50 loops=1)         -> Index lookup on p...

튜닝 전에도 조건 자체는 인덱스를 탔지만, 정렬(created_at DESC)을 만족시키지 못해 Sort 단계를 진행한것 같다.

튜닝후

-> Limit: 50 row(s)  (cost=5701 rows=50) (actual time=0.3..0.318 rows=50 loops=1)     
-> Filter: (p.post_status = 'PUBLISHED')  (cost=5701 rows=49549) (actual time=0.299..0.315 rows=50 loops=1)         
-> Index lookup on p using idx_post_status_created_a...

인덱스가 (post_status → created_at → post_id) 순서로 잡히면서, 옵티마이저가 정렬을 별도 Sort로 처리하지 않고 인덱스 순서로 해결할 수 있는 형태가 됐다.

7-3. 적용후 부하 테스트 결과

인덱스 적용 후에는 failures가 0으로 유지된 상태에서 RPS가 1,700~~2,100 범위로 훨씬 안정적으로 유지되었고, p50/p95 지연도 300~~500ms대에서 안정적으로 관측되었다.

Locust 통계에서 GET /posts (list)는 median이 1초대, p95가 4~~11초까지 튀었고, detail은 p95가 1~~2초대로 상대적으로 낮았다.

그래프가 주기적으로 출렁이는 형태는 남아있었는데, 이는 Locust 시나리오에서 list를 일정 주기로 refresh하는 요청이 순간적으로 몰리면서 read 경로가 잠깐 포화되고, 닫힌 모델 특성상 RPS가 같이 출렁이는 패턴이라고 생각을 하고 있다.

실제로 Locust시나리오에 list를 60초 주기로 refresh하도록 설정되어있어 60초마다 list 요청이 몰리는 상태였다.

def _refresh_post_pool(self, force=False):
        now = time.time()
        if not force and (now - self._last_refresh) < REFRESH_LIST_EVERY_SEC:
            return

8. 정리

처음 병목은 단순했다. 상세 조회가 들어올 때마다 view_count = view_count + 1 UPDATE가 발생했고, 트래픽이 몰리면 특정 post row에 쓰기가 집중되면서 InnoDB row lock wait => 커넥션 점유 시간 증가 => Hikari pending 증가 => 지연 폭증/실패로 이어졌다.

상한(Tomcat/Hikari) 튜닝은 실패를 늦게 만들 뿐이었다. DB 병목이 남아 있으면 active가 max에 붙고, 결국 connection timeout으로 무너졌다.
DB 인덱스/트랜잭션 정리는 중간 부하에서는 분명 효과가 있었지만, 조회수 UPDATE라는 본질적인 쓰기 핫스팟은 고부하에서 한계가 왔다.
샤딩 카운터는 쓰기 락 경합을 분산시키는 데는 도움이 됐지만, 읽을 때 합산(SUM)과 랭킹(ORDER BY SUM)을 만들기가 너무 복잡해졌다.

그래서 최종적으로 선택한 방식이 Redis로 요청 경로에서 DB UPDATE를 제거하는 것이었다. 그 결과 failures가 0으로 수렴했고, 처리량 상한도 눈에 띄게 올라갔다.

마지막으로, 인덱스를 정렬 패턴에 맞춰 추가하면서 list의 Sort 비용을 줄였고, 그 결과 RPS와 지연이 더 안정적인 형태로 바뀌었다. 그래프에 남아 있는 출렁임은 Locust 시나리오에서 list refresh가 일정 주기로 몰리는 구조가 반영된 결과라고 생각했다.

개선 전

개선 후

블로그 인기글 부하 테스트 병목현상 개선 과정

Fri, 30 Jan 2026 22:58:43 GMT

0. 당시 상황

블로그 서버를 만들고 있었고, 인기글 기능을 추가한 뒤 부하 테스트를 돌리고 있었다. 테스트 시나리오는 단순했다.

상세 조회 API는 조회할 때 조회수(view_count)를 1 증가시킨다. 인기글 API는 view_count DESC 로 상위 N개를 가져온다.

0-1. 구현 흐름

게시글 상세 조회: GET /posts/{id}
조회수 증가: 상세 조회 시 view_count = view_count + 1
인기글(랭킹): ORDER BY view_count DESC LIMIT 20

0-2. 실험 환경

앱: Spring Boot + JPA + MySQL + Tomcat
커넥션 풀: HikariCP
부하 도구: Locust
관측: access log, actuator metrics, MySQL

0-3. 스펙

CPU: 13th Gen Intel(R) Core(TM) i5-13500
DB 분리 여부: 로컬 동일 머신
Hikari 설정 maximumPoolSize: 10

0-4. (수정) 테스트 데이터 규모 변경 3 => 약 10만개

처음에는 게시글 테이블에 데이터가 거의 없는 상태(3건 수준)로 테스트했다. 그 상태에서는 인기글 정렬이든, 리스트 조회든 별로 티가 나지 않았다.

그래서 실서비스에 가까운 조건을 만들기 위해 게시글 데이터를 약 100,000건으로 늘려서 다시 테스트했다.

ORDER BY view_count DESC LIMIT 20 는 데이터가 많아질수록 정렬/스캔 비용이 커진다.
조회수 UPDATE 핫스팟 문제뿐 아니라 인기글 SELECT 자체도 병목일 수도 있다.

이 글은 약 10만 건 기준으로 병목을 관측/추적한 내용으로 수정했다.

1. 부하 테스트 설계

실제 서비스는 조회가 특정 글/특정 컨텐츠에 몰릴 것이라고 생각했다. 그래서 핫스팟을 의도적으로 만들었다.

1-1. 핫스팟 만들기

특정 게시글 1~2개에 조회 트래픽의 80% 집중 나머지는 랜덤 게시글로 트래픽을 조절했다.

1-2. 성공/실패 기준

Locust failure rate(실패율) timeout 발생 여부/개수 p95/p99 응답시간 RPS 변화(피크 찍고 떨어지는지)

서버 access log에서 엔드포인트별 응답시간(%D)이 튀는지

DB(MySQL/InnoDB) row lock wait / deadlock 흔적 UPDATE가 병목이 되는지

풀(HikariCP) pending(대기 커넥션) 증가 여부 pool timeout 발생 여부

2. Locust failures가 뜨기 시작했다

2-1. Break test (10,000명)

유저 수를 10,000까지 올리자 Failures/s가 RPS와 거의 비슷한 속도로 증가했다.
원인 분석은 관측 가능한 구간(1,000명 테스트)에서 진행했다.

2-2. Observation test (1,000명)

10,000명 구간은 실패율이 너무 높아 내부 병목을 관측하기 어려웠다.
그래서 유저 수를 1,000명으로 낮추고 동일 시나리오로 재현하여, 실패 없이도 지연이 급증하는 구간을 확보했다.
이후의 access log / HikariCP / InnoDB / Tomcat 메트릭 분석은 1,000명 테스트를 기준으로 정리했다.

2-3. 이 failures는 어디에서 나온걸까

Locust의 실패는 서버가 500을 주는 것 같은 HTTP 실패만 의미하지 않는다. 연결 자체 실패도 failures로 묶어서 보여준다.

그래서 나는 제일 먼저 살펴본것은 3가지 였다

서버는 요청을 받았고, HTTP 에러를 돌려줬다
서버가 너무 느려서 timeout으로 응답을 못 받았다
아예 TCP 연결이 성립하지 않았다 (요청이 서버까지 못 갔다)

3. 원인 찾기

관측 가능한 1,000명 재현 테스트를 기준으로 정리했다.

3-1. access log 확인

내가 먼저 확인한 것은 access log였다.

access log에 찍히면 요청이 톰캣까지는 도착했다. 라고 생각하기 떄문이다. access log에 안 찍히면 애초에 연결이 안 됐거나(서버까지 못 왔음), 톰캣 앞단에서 끊겼다쪽이라고 생각했다.

access log는 아래와 같이 설정했다.

server.tomcat.accesslog.enabled=true
server.tomcat.accesslog.directory=logs
server.tomcat.accesslog.prefix=access_log
server.tomcat.accesslog.suffix=.log
server.tomcat.accesslog.pattern=%h %l %u %t "%r" %s %b %D
server.tomcat.accesslog.buffered=false

그리고 확인해보니 아래와 같이 모두 200 응답만 찍혀 있었다.

access log는 톰캣이 받아서 처리한 요청만 찍는다. 연결 단계에서 거절된 요청은 애초에 로그에 남지 않는다.

GET /api/v1/posts?page=0&size=50 HTTP/1.1" 200 562 12155
GET /api/v1/posts?page=0&size=50 HTTP/1.1" 200 562 13103
GET /api/v1/posts?page=0&size=50 HTTP/1.1" 200 562 13111
.
.
.
GET /api/v1/posts?page=0&size=50 HTTP/1.1" 200 564 643916
GET /api/v1/posts?page=0&size=50 HTTP/1.1" 200 564 641821
GET /api/v1/posts?page=0&size=50 HTTP/1.1" 200 564 633855

여기서 생각한건 서버가 받은건 대부분 정상 처리됬는데 Locust는 failures가 40%정도였다. 서버가 500을 한게 아니고 서버에 도달하지 못했거나 도달 전에 끊겼다고 생각을 하였다.

3-1-1. %D가 계속 증가

access log에는 요청 처리 시간(%D = ms단위) 도 같이 찍히게 해두었다. (요청을 받아서 응답을 완료할 때까지 처리 시간)

부하가 올라갈수록 access log에 200은 유지되지만 %D가 계속 커지는 현상을 발견하였다. 이것을 보고 서버는 정상 응답을 주긴 주지만, 점점 더 오래걸리며 처리가 제대로 되지 않는 것을 확인하였다.

처리 시간이 커지니까 (%D 증가) =>
워커 스레드가 더 오래 잡고 있으면 (스레드가 고갈되니까) =>
threads, connections가 상한에 도달함 =>
그때부터 연결이 거절됨.

처리 시간이 증가하니까 워커 스레드가 더 오래잡고있게 되고, 오래 잡으니까 스레드가 상한에 도달하게 된다. 그때부터 연결이 거절될 수 있다고 생각하게 되었다.

3-2. Locust failure 확인

access log 다음으로 본 건 Locust failures 상세였다. 실패 메시지는 아래와 같았다.

HTTP 요청을 보내고 500을 받은 게 아니다. TCP 연결 자체가 성립하지 않았다. 그래서 access log에 안 찍히는 게 정상이라고 생각했다.

애플리케이션이 아닌 서버에서 새 연결을 받아줄 여유가 없었던 상태였다고 생각했다.

4. 그럼 왜 connection refused가 났을까?

localhost:8080에서 connection refused가 나오는 대표 원인은 보통 이거라고 한다.

해당 시점에 8080 리스너가 없었다 (프로세스 죽음/재시작/포트 변경)
리스너는 있지만 Tomcat 리소스(threads/maxConnections)가 포화되어 새 연결이 거절되는 상태
로컬 환경 특수 이슈(방화벽/보안SW 등)

5. 8080 리스너 확인

아래 순서로 확인했다.

5-1. 8080 리스닝 PID확인

netstat -ano | findstr :8080

결과: LISTENING 49260

5-2. PID가 뭔지 확인:

tasklist /FI "PID eq 49260"

결과: java.exe 49260

5-3. 이 java.exe 가 내 서버인지 확인

wmic process where "ProcessId=49260" get ProcessId,Name,ExecutablePath,CommandLine /format:list

결과: CommandLine에 프로젝트 classpath랑 com.example.blog.BlogApplication이 찍혔다.

8080은 내 스프링 서버가 맞았다.

6. 원인 생각 (앱, 풀, DB)

나는 아래 3개로 원인을 생각해보았다.

6-1. 애플리케이션 CPU/GC 병목

CPU가 100%에 붙거나 GC가 길게 발생하거나 스레드가 특정 락에 묶이거나

6-2. 커넥션 풀 병목(Hikari)

DB가 느려지면 커넥션이 반환이 안 되고 결국 요청 스레드가 커넥션 기다리다가 잠듦 결과적으로 API가 타임아웃/실패

6-3. DB(InnoDB) 락/쿼리 병목

상세 조회마다 실행되는 쿼리: UPDATE post SET view_count = view_count + 1 WHERE id=?

특정 게시글에 트래픽이 몰리면 같은 row를 동시에 update InnoDB row lock wait 증가 => 트랜잭션 지연 => 풀 대기 증가

인기글 쿼리: ORDER BY view_count DESC LIMIT 20 데이터가 10만 건이라서 인덱스 구성에 따라 정렬/스캔 자체가 병목이 될 수 있다.

인덱스가 없으면 큰 지연이 일어날 수 있다.

7. 병목이 일어나는 시나리오

한번 병목이 일어나는 시나리오를 생각해보았다.

요청이 들어온다
톰캣 worker thread가 처리한다
처리 중 DB 작업에서 막힌다(락/슬로우쿼리/커넥션풀 대기)
worker thread가 대기 상태로 점유된다
어느 순간 톰캣의 처리 스레드가 꽉 찬다
새 연결은 대기열로 쌓이다가, 클라이언트에서 timeout/거부 같은 형태로 failures가 생겨난다.

DB 대기 → 애플리케이션 스레드 점유 → 새 연결을 못 받음

8. 원인 추적 결과 정리

나는 크게 3가지를 확인하였다.

8-1. HikariCP(커넥션풀)에 대기열이 생기나?

HikariCP 메트릭 찍는방법 active(사용 중 커넥션) = 10 (모두 사용중)

idle(남은 커넥션) = 0 (없음)

pending(커넥션 기다리는 스레드 수) = 188~190

pool timeout 발생 여부 = 0 (Hikari의 connectionTimeout으로 실패한 건수는 관측되지 않았다)

active가 max(10)에 고정되고 idle은 0이고 pending은 계속 증가했다. 요청 스레드가 DB 커넥션을 못 얻고 있다는 뜻이라고 생각했다.

pending이 190까지 올라간 걸 보면, 커넥션 대기가 엄청났고, 일부 요청은 Hikari timeout까지 가지기 전에 톰캣 연결 단계에서 실패했을 것 같다.

8-2. InnoDB row lock wait로 병목 확인

조회수 증가가 UPDATE post SET view_count=view_count+1 형태면, 핫스팟 트래픽에서는 같은 row에 업데이트가 몰린다.

8-2-1. InnoDB Row Lock Wait확인

부하 테스트 직후 MySQL 상태 변수에서 아래 값을 확인했다.

SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%';

variable_name	value
Innodb_row_lock_current_waits	1
Innodb_row_lock_time	3056796
Innodb_row_lock_time_avg	25
Innodb_row_lock_time_max	140
Innodb_row_lock_waits	118284

Innodb_row_lock_waits 는 행 락 대기 발생 횟수이고, Innodb_row_lock_time 은 누적 대기 시간이다. 핫스팟 UPDATE가 반복되면 이 값들이 빠르게 증가한다.

조회수 UPDATE가 같은 row에 몰리면서 락 경합이 실제로 발생했고, 그 대기가 커넥션 반환 지연과 pending 증가로 이어진 것 같다.

8-2-2. 실제로 시간이 많이 든 쿼리

슬로우/요약에서 쿼리 분포를 보니, 가장 비중이 큰 쿼리가 조회수 UPDATE였다.

SELECT
  DIGEST_TEXT,
  COUNT_STAR,
  ROUND(SUM_TIMER_WAIT/1e12, 3) AS total_sec,
  ROUND(AVG_TIMER_WAIT/1e12, 6) AS avg_sec
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;

이 상황은 인기글/상세조회가 읽기처럼 보여도, 조회수 때문에 결국 쓰기 병목이 된 것 같다.

8-2-3. 이게 왜 Locust failures / %D 증가 / Hikari pending으로 이어졌을까?

DB에서 row lock 대기가 늘어나면, 트랜잭션이 오래 잡히고 커넥션이 늦게 반환된다.

DB 락 대기 커지면 => 커넥션 반환 지연 커짐
커넥션 반환 지연 커짐 => Hikari active=10(고정), idle=0, pending 약 190
pending(대기 스레드) 커짐 => 요청 처리시간 증가(access log의 %D 폭증)
처리 스레드가 대기로 묶이면 => 결국 일부 요청은 connection refused, timeout로 Locust 실패로 측정됨.

이 문제는 DB 락 대기가 애플리케이션 스레드/커넥션풀을 잠그면서 생긴 리소스 병목이었다.

8-3. 톰캣/서버 메트릭 확인

Actuator에서 Tomcat 메트릭을 찍어보니:

tomcat.threads.busy = 200

tomcat.threads.current = 200

워커 스레드가 200개 전부 바쁘다. (스레드 풀 고갈)

그리고 tomcat.connections.current = 8192

tomcat.connections.keepalive.current = 8192 (열려있는 연결이 keep-alive로 살아있는 상태)

tomcat.threads.config.max = 200

tomcat.connections.config.max = 8192

threads.busy(200) == threads.config.max(200) connections.current(8192) == connections.config.max(8192)

tomcat.threads.busy=200 이고 tomcat.threads.config.max=200 이었다. 톰캣 워커 스레드 풀이 상한에 도달해 더 이상 요청을 처리할 여유가 없었다.

또한 tomcat.connections.current=8192 와 tomcat.connections.config.max=8192 가 똑같았다. 동시 연결이 설정 상한까지 차서 새 연결은 OS/Tomcat 단계에서 거절될 수 있는 상태였다.

DB 락 대기 때문에 요청 처리가 느려짐
느려지니 커넥션이 오래 열려있음(keep-alive 포함)
스레드는 DB 대기 상태로 점유됨
결국 톰캣은 threads도 상한, connections도 상한
그 순간부터 신규 연결은 거절/실패로 되고, 그게 Locust의 WinError 10061로 관측된 것 같다.

Tomcat 메트릭 사용 커맨드

curl.exe -s "http://localhost:8081/actuator/metrics/tomcat.threads.busy"
curl.exe -s "http://localhost:8081/actuator/metrics/tomcat.threads.current"
curl.exe -s "http://localhost:8081/actuator/metrics/tomcat.connections.current"
curl.exe -s "http://localhost:8081/actuator/metrics/tomcat.connections.keepalive.current"
curl.exe -s "http://localhost:8081/actuator/metrics/tomcat.threads.config.max"
curl.exe -s "http://localhost:8081/actuator/metrics/tomcat.connections.config.max"

9. 정리

9-1. 증상

InnoDB row lock wait 증가
커넥션 반환 지연
pending 누적
처리 지연이 누적되면서 톰캣 스레드/커넥션이 상한 도달

DB 락대기 => 풀 대기 => 톰캣 리소스 X => 클라 연결 실패

9-2. 결론

조회수 UPDATE는 핫스팟 트래픽에서 DB row lock 경합을 만든다

그 결과 DB에서 끝나지 않고, Hikari pending, %D (요청시간) 폭증, Tomcat threads/connections 상한까지 연쇄로 번진다

그래서 Locust failures는 연결 레벨에서 거절로 관측될 수 있다.

9-3. 개선 과정

개선 과정은 다음 글에 정리하겠습니다.

RabbitMQ consumer 처리량 개선 과정

Fri, 02 Jan 2026 14:54:48 GMT

0. 문제 상황

컨슈머 처리량이 20~40 msg/s 정도로 매우 느렸습니다.

publish는 300~400 msg/s 까지 발행되었는데, 컨슈머가 따라가지 못해서 snapshot의 반영이 지연되었습니다.

1. 조건

DB: MySQL (동일 인스턴스)

테이블: 변경 없음(최적화 실험 전/후 동일)

메시지: 동일 DTO(SnapshotMsg)

테스트: Locust로 동일 패턴/부하로 발행

측정: RabbitMQ 관리 페이지 deliver/ack rate 기준 msg/s 측정

실험 모두 동일합니다.

2. consumer늘리기 (20~40 => 100초반)

처음에는 코드를 보기전에 단순 consumer를 늘리면 해결될 것이라고 생각했습니다.

2.1 변경내용

RabbitListener concurrency를 늘렸습니다.

@RabbitListener(queues = RabbitConfig.Q, concurrency = "#")

2.2 결과

concurrency 증가 전 : 약 20 msg/s concurrency 증가 후 : 약 60~100 msg/s

처리량은 올라갔지만 여전히 너무 느렸습니다. 그리고 1개에서 10개로 늘렸지만 200이 아닌 100이 된 이유는 로컬머신의 한계라고 생각했습니다. 테스트를 할때 CPU는 100% 이용을 하고 있었고 한계치라고 생각했습니다.

그래서 결국 메시지를 처리하는 consumer 시간 자체를 줄여야한다고 생각했습니다.

실제로 메시지 한건의 처리 속도는 약 100~200 ms로 매우 느렸습니다.

3. 느린 이유에 대한 생각

당시 로직은 아래와 같습니다.

    @Transactional
    public void processOneMessage(SnapshotMsg msg) {
        validate(msg);
        ledgerRepository.existsByTxIdAndSideAndStatus // ledger상태 조회
        snapshotAppliedRepository.save(SnapshotApplied.of(msg.accountId(), msg.txId())); // 멱등 처리
        availableBalanceRepo.credit(msg.accountId(), msg.amount()); // 잔액 업데이트
        snapshotRepository.applyDelta(msg.accountId(), msg.amount()); // 스냅샷 업데이트
        ledgerRepository.markCommitted(msg.txId(), msg.accountId(), msg.entrySide()); // ledger 상태 업데이트
        outboxRepository.markSent(msg.outboxId()); // outbox 상태 업데이트
    }

메시지 1건당 DB왕복이 너무 많았고 생각해본건 아래 3가지였습니다.

DB왕복이 너무 많다
balance 업데이트가 쿼리가 2개라 오래걸릴 것이다.
existsBy 조회가 비쌀것 같다

4. outbox 업데이트를 조건부로 변경

먼저 쿼리문들을 한번 봤습니다. 이 쿼리는 이미 SENT인 row에도 매번 UPDATE를 시도합니다. 메시지가 중복되거나 재시도되면 이 UPDATE가 계속 찍힙니다.

UPDATE outbox
SET status = 'SENT'
WHERE outbox_id = ?;

4.1 변경내용

아래와 같이 이미 SENT라면 굳이 다시 쓰지 않도록 수정했습니다. 작지만 얼마나 개선되는가를 확인해 보고싶었습니다.

UPDATE outbox
SET status = 'SENT'
WHERE outbox_id = ?
  AND status <> 'SENT';

4.2 결과

큰 차이가 없었습니다.

5. 쿼리 합치기

이번에는 쿼리의 개수를 줄여보고자 해보았습니다. 원래는 가용잔액 테이블에 + 연산을 해주고 스냅샷 테이블에서 + 연산을 해줍니다. 여기서 account_id가 같으니까 두개를 합쳐보자는 생각을 해보았습니다.

5.1 변경내용

아래와 같이 JOIN을 하여 묶어서 처리를 하도록 했습니다.

UPDATE available_balance ab
        JOIN snapshot_balance sb
          ON sb.account_id = ab.account_id
           SET ab.balance = ab.balance + :amt,
               ab.ver     = ab.ver + 1,
               sb.balance = sb.balance + :amt,
               sb.update_time = NOW()
         WHERE ab.account_id = :accountId

5.2 결과

이것 또한 차이가 없었습니다. 쿼리 수는 줄었지만, 전체 병목이 잔액+스냅샷 업데이트보다 ledger existsBy/트랜잭션 비용 쪽에 있었던 것으로 보였습니다.

6. existsBy 제거

처음 로직에는 이런 쿼리가 있었습니다.

ledgerRepository.existsByTxIdAndSideAndStatus(...)

이 쿼리는 이미 COMMITTED이면 처리하지 않기위한 의도로 넣었습니다.

6.1 변경내용

markCommittedIfPending으로 한번에 처리하고 변수(int updated)로 빼서 분기를 하였습니다. 이렇게 하면 existsBy(SELECT)가 없어지고, UPDATE한번으로 할 수 있습니다.

@Modifying
@Query("""
update Ledger l
   set l.status = com.maeng.toss.ledger.domain.Status.COMMITTED
 where l.txId = :txId
   and l.accountId.accountId = :accountId
   and l.side = :side
   and l.status = com.maeng.toss.ledger.domain.Status.PENDING
""")
int markCommittedIfPending(String txId, Long accountId, EntrySide side);

int updated = ledgerRepository.markCommittedIfPending(msg.txId(), msg.accountId(), msg.entrySide());
if (updated == 0) { // 변경된 것이 없다 => 이미 다른 컨슈머가 처리했거나 중복 메시지이므로 스킵
    return;
}

6.2 결과

existsBy(SELECT)를 제거하고 조건부 UPDATE로 통합한 뒤, 메시지 처리 시간이 눈에 띄게 줄었습니다. 메시지 한건의 처리 속도가 6~20 ms 수준으로 빨라지며, ACK rate기준 약 2000 msg/s를 찍기도 하였습니다.

6.3 왜 차이가 컸을까

제가 생각한 existsBy가 느린 이유는 이렇습니다.

일단 메시지 1건에서 SELECT가 한번 늘어나는 구조입니다. 처리량이 많아질 수록 그게 손해라고 생각했습니다. 즉 메시지 한건당 DB왕복이 SELECT + UPDATE에서 UPDATE 하나로 줄었습니다.
Time-of-check to time-of-use 가 발생할 수도 있다고 생각했습니다. 이건 검사 시점과 사용 시점 사이에 발생하는 레이스 컨디션입니다. existsBy로 확인 후 UPDATE는 분리되어 레이스가 일어날 수 있습니다.
existsBy는 결국 내부적으로 limit 1 형태의 조회 SQL이 실행됩니다. 실제로 아래 SQL 로그에서 LIMIT 1 조회로 나가는 것을 확인할 수 있습니다. DB작업이 이미 많이 있는 상황에서 읽기 하나 추가가 느리게 만든다고 생각했습니다.
```
DEBUG org.hibernate.SQL -
 select
     l1_0.ledger_id
 from
     ledger_entry l1_0
 where
     l1_0.tx_id=?
     and l1_0.side=?
     and l1_0.status=?
 limit
     ?
...
binding parameter (3:ENUM) <- [COMMITTED]
binding parameter (4:INTEGER) <- [1]
```

7. 정리

최종 변경 코드

@Transactional
public void processOneMessage(SnapshotMsg msg) {
    snapshotAppliedRepository.insertIgnore(msg.accountId(), msg.txId());
    outboxRepository.markSentIfNotSent(msg.outboxId());
    balanceRepository.applyDeltaBoth(msg.accountId(), msg.amount());
    ledgerRepository.markCommitted(msg.txId(), msg.accountId(), msg.entrySide());
}

existsBy는 읽기-판단이라서 DB왕복도 늘리고 동시성도 완벽하지 않다고 생각했습니다. 같은 조건의 작업이면 조건부 UPDATE로 합치는게 더 빠르고 안전할 것 같습니다.

스프링 서버에서 커넥션 풀(Connection Pool) 확인하고 조절하는 방법 (HikariCP/Actuator)

Thu, 18 Dec 2025 16:12:23 GMT

0. 3줄 요약

Actuator 의존성 추가

dependencies {implementation 'org.springframework.boot:spring-boot-starter-actuator'}

서버 재시작 후 터미널에 명령어 치고 커넥션 상태 확인
```
curl.exe -s http://localhost:8080/actuator/metrics/hikaricp.connections
```

application.properties 기준

# 최대 커넥션 수 조절
spring.datasource.hikari.maximum-pool-size=20

1. 왜 커넥션 풀을 볼까

저는 서버에 부하 테스트를 하였고 RPS가 올라감에 따라 응답속도가 증가하는 경험을 하였습니다.

응답속도가 높아져 timeout이 발생했고, 원인 후보 중 하나로 DB 커넥션 풀 포화를 의심했습니다. 커넥션 풀이 부족하면 요청이 커넥션을 얻기까지 대기하게 되고(pending 증가), 그 대기가 길어지면 결국 timeout으로 이어질 수 있습니다. 그래서 Actuator 메트릭으로 현재 커넥션 풀 상태를 확인한 뒤, 필요하다면 최대 풀 크기를 조절해 보기로 했습니다.

DB 커넥션은 무겁고 비싼 자원입니다. 커넥션 풀이 너무 작으면 요청이 몰릴 때 커넥션을 못 구해서 대기(pending) 증가 → 응답 지연/타임아웃이 나고, 너무 크면 DB가 감당 못해서 DB CPU/메모리/스레드 폭증, 락 경합 증가, 전체가 느려질 수 있습니다.

2. 현재 커넥션 풀 상태 확인하기

2-1. Actuator 의존성 추가

Gradle

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-actuator'
}

2-2. metrics 엔드포인트 노출

application.properties

management.endpoints.web.exposure.include=health,info,metrics,threaddump
management.endpoint.health.show-details=always

서버 재시작후

curl.exe http://localhost:8080/actuator

이런식으로 mertrics가 잘 보이면 Actuator 엔드포인트 노출이 제대로 된 상태입니다.

3. HikariCP 커넥션 풀 메트릭 조회하기

3-1. Total 커넥션 수 확인하기

curl.exe -s http://localhost:8080/actuator/metrics/hikaricp.connections

value: 10 이라고 나와있습니다. 이는 현재 풀에 존재하는 전체 커넥션 수가 10이라는 것입니다. 보통 active + idle의 합입니다. (최대치는 아님)

3-2. active/idle/pending/max

무슨 메트릭이 있는지 목록을 확인할 수 있습니다. 아래 사진을 잘 보시면 connections.active, .pending , .timeout, idle등 여러가지를 확인할 수 있습니다.

curl.exe -s http://localhost:8080/actuator/metrics | findstr /i hikaricp

hikaricp.connections.active : 사용 중 커넥션 수
hikaricp.connections.idle : 유휴 커넥션 수
hikaricp.connections.pending : 커넥션을 못 구해 대기 중인 스레드 수(병목 신호)
hikaricp.connections.max : 풀 최대치

hikaricp.connections.min : 풀 최소치

curl.exe -s "http://localhost:8080/actuator/metrics/hikaricp.connections.active?tag=pool:HikariPool-1"
curl.exe -s "http://localhost:8080/actuator/metrics/hikaricp.connections.idle?tag=pool:HikariPool-1"
curl.exe -s "http://localhost:8080/actuator/metrics/hikaricp.connections.pending?tag=pool:HikariPool-1"
curl.exe -s "http://localhost:8080/actuator/metrics/hikaricp.connections.max?tag=pool:HikariPool-1"

현재 풀 최대 커넥션 수가 10입니다.(maximum-pool-size:10)

현재 유휴상태 커넥션이 10개입니다.

현재 DB에 붙어서 실제로 사용중인 커넥션이 0개입니다.

커넥션을 못구해서 기다리는 스레드가 0개입니다.

4. 커넥션 풀 설정 변경(HikariCP)

properties기준

# 최대 커넥션 수
spring.datasource.hikari.maximum-pool-size=20

# 최소 유휴 커넥션
spring.datasource.hikari.minimum-idle=10

# 커넥션을 못 구했을 때 기다리는 최대 시간(ms)
spring.datasource.hikari.connection-timeout=30000

# 유휴 커넥션 제거 기준(ms)
spring.datasource.hikari.idle-timeout=600000

# 커넥션 최대 생존시간(ms)
spring.datasource.hikari.max-lifetime=1800000

5. 코드로 커넥션 풀 상태 출력하기

import com.zaxxer.hikari.HikariDataSource;
import com.zaxxer.hikari.pool.HikariPoolMXBean;
import javax.sql.DataSource;

public class PoolLogger {
    public static void print(DataSource dataSource) {
        HikariDataSource hikari = (HikariDataSource) dataSource;
        HikariPoolMXBean mx = hikari.getHikariPoolMXBean();

        System.out.println("최대 풀 개수 =" + hikari.getMaximumPoolSize());
        System.out.println("최소 Idle=" + hikari.getMinimumIdle());
        System.out.println("전체 풀=" + mx.getTotalConnections()
                + ", active=" + mx.getActiveConnections()
                + ", idle=" + mx.getIdleConnections()
                + ", awaiting=" + mx.getThreadsAwaitingConnection());
    }
}

Spring mysql jpa 데드락 상황 해결 과정 (REQUIRES_NEW)

Tue, 16 Dec 2025 17:07:41 GMT

0. 문제 상황

이전 글과 이어진다.

이전 글에서 snapshot_balance / available_balance 업데이트 과정에서 데드락이 났던 원인과 해결 과정을 정리했다.
이번에는 스냅샷 프로젝터 (consumer) 쪽에서 비슷한 데드락이 다시 발생했다.

이전에 락 순서를 맞춰놔서 이번에는 데드락 덤프를 확인했다.

SHOW ENGINE INNODB STATUS

덤프 일부는 아래와 같았다.

LOCK WAIT ... 1952 row lock(s), undo log entries 141
update available_balance ... where account_id=3

HOLDS THE LOCK(S):
RECORD LOCKS ... index FKn763t766d31cgf7m4w4kj3hs0 of table `tossclone`.`ledger_entry` ...

 그 뒤로 무수히 많은 record lock들 . . .

현재 실행중인 쿼리는 available_balance update이다. 그런데 같은 트랜잭션이 ledger_entry쪽 인덱스 락을 엄청 많이 잡고 있었다. (HOLDS THE LOCKS)

추가로 FKn... 처럼 보이는 인덱스명은

SELECT
    kcu.CONSTRAINT_NAME         AS fk_name,
    kcu.TABLE_NAME              AS table_name,
    kcu.COLUMN_NAME             AS column_name,
    kcu.REFERENCED_TABLE_NAME   AS referenced_table,
    kcu.REFERENCED_COLUMN_NAME  AS referenced_column
FROM information_schema.KEY_COLUMN_USAGE kcu
WHERE
    kcu.TABLE_SCHEMA = '테이블 명'
    AND kcu.REFERENCED_TABLE_NAME IS NOT NULL
ORDER BY
    kcu.TABLE_NAME,
    kcu.CONSTRAINT_NAME,
    kcu.ORDINAL_POSITION;

ledger_entry.account_id => account.account_id FK와 연관된 이름이었다.

1. 문제 원인

당시 스냅샷 프로젝터가 메시지 큐에서 메시지를 꺼내서 다음을 처리한다.

1) SnapshotApplied에 UNIQUE(accountId, txId)로 멱등 락
2) snapshot_balance 반영
3) available_balance 반영
4) outbox SENT 마킹
5) ledger 상태 COMMITTED 마킹

그런데 이 작업을 스케줄러에서 다음처럼 돌리고 있었다.

    @Scheduled(fixedRate = 500)
    @Transactional
    public void scheduledQueue() { // 소비자임 MQ를 받아서 스냅샷/가용잔액 반영함.
        // 엄청 많은 row lock이 걸림
        int max = 2000;
        for (int i = 0; i < max; i++) {
            SnapshotMsg msg = sharedMessageQueue.poll();
            if (msg == null) break;
            // 1,2,3,4,5 처리
        }
    }

@Scheduled(fixedRate = 500)
한 번에 최대 2000개까지 for문으로 처리
스케줄러 메서드에 @Transactional이 붙어 있음

결과: 테스트를 돌려보면 가끔씩 데드락이 터졌다.

이부분이 원인이라고 생각하였다.

2. 문제를 해결해보자

현재는 Transactional안에 for문이 있었기 때문에 2000개를 한 트랜잭션으로 처리하기 때문에 이부분을 고쳐야겠다고 생각했다.

REQUIRES_NEW를 사용하여 분리해보았다.

    @Scheduled(fixedRate = 500)
    @Transactional
    public void scheduledQueue() {
        // 엄청 많은 row lock이 걸림
        int max = 2000;
        for (int i = 0; i < max; i++) {
            SnapshotMsg msg = sharedMessageQueue.poll();
            if (msg == null) break;
            log.info("메시지 큐에서 꺼냄", msg);
            processOneMessage(msg);
        }
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void processOneMessage(SnapshotMsg msg) {
        // 1,2,3,4,5 처리
    }

하지만 또 다시 데드락이 났다.

2-1. REQUIRES_NEW를 붙였는데도 왜 데드락이 났을까?

처음엔 processOneMessage()에 REQUIRES_NEW를 붙였으니 메시지 1개당 트랜잭션이 분리되겠지? 라고 생각했다.

하지만 다시 데드락 로그를 확인해봤더니 한 트랜잭션이 이미 수백 개의 row lock을 잡고 있었다.

LOCK WAIT ... 1952 row lock(s), undo log entries 141
현재 실행 중인 쿼리는 available_balance 업데이트인데,
동시에 ledger_entry 쪽 인덱스 락을 엄청 많이 쥐고 있는 상태였다.

메시지 하나 처리 => 커밋 => 락 해제 순서가 아니라
한 트랜잭션이 계속 살아 있으면서 ledger_entry 락이 누적되고, 마지막에 available_balance에서 서로 물려 데드락이 터진 형태였다.

REQUIRES_NEW가 실제로는 적용되지 않았다라고 생각을 했다 그래서 한번 확인해보기로 하였다.

2-1-1. REQUIRES_NEW 확인

트랜잭션 로그를 TRACE로 하고 확인했다.

logging.level.org.springframework.transaction: TRACE
logging.level.org.springframework.transaction.interceptor: TRACE
logging.level.org.springframework.orm.jpa.JpaTransactionManager: TRACE

정상적으로 REQUIRES_NEW가 적용되면 processOneMessage 진입 시점에 이런 로그가 떠야한다고 한다.

Suspending current transaction
Creating new transaction with name [..processOneMessage]: PROPAGATION_REQUIRES_NEW
(메서드 종료 후) Resuming suspended transaction

하지만 실제 로그는 processOneMessage안에서 찍힌 트랜잭션 이름이 계속 scheduledQueue였다. (기존 트랜잭션 컨텍스트를 그대로 사용하고 있었던 것 같다.)

아래 로그를 보면 No need to create transaction for... 이 있는데 이건 해당 메서드 호출에서 새로운 트랜잭션을 만들 필요가 없다라는 의미이다.

INFO 46256 --- [toss] [   scheduling-1] c.m.t.s.S.BalanceSnapshotProjector       : [TX] where=processOneMessage:beforeCommitPoint, active=true, name=com.maeng.toss.snapshot.SnapshotProjector.BalanceSnapshotProjector.scheduledQueue, isNew=true, thread=scheduling-1
INFO 46256 --- [toss] [   scheduling-1] c.m.t.s.S.BalanceSnapshotProjector       : 메시지 큐에서 꺼냄
INFO 46256 --- [toss] [   scheduling-1] c.m.t.s.S.BalanceSnapshotProjector       : [TX] where=processOneMessage:enter, active=true, name=com.maeng.toss.snapshot.SnapshotProjector.BalanceSnapshotProjector.scheduledQueue, isNew=true, thread=scheduling-1
TRACE 46256 --- [toss] [   scheduling-1] o.s.t.i.TransactionInterceptor           : No need to create transaction for [org.springframework.data.jpa.repository.support.SimpleJpaRepository.existsByTxIdAndAccountId_AccountIdAndStatus]: This method is not transactional.

아래 로그를 보면 실제로 새로운 트랜잭션을 열지않고 기존 트랜잭션에 합류했다.

DEBUG 46256 --- [toss] [   scheduling-1] o.s.orm.jpa.JpaTransactionManager        : Found thread-bound EntityManager [SessionImpl(1793071322)] for JPA transaction
DEBUG 46256 --- [toss] [   scheduling-1] o.s.orm.jpa.JpaTransactionManager        : Participating in existing transaction
TRACE 46256 --- [toss] [   scheduling-1] o.s.t.i.TransactionInterceptor           : Getting transaction for [org.springframework.data.jpa.repository.support.SimpleJpaRepository.save]

이를 통해 REQUIRES_NEW가 제대로 분리되지 않았다고 생각했다.

2-2. 원인: 같은 빈 내부 호출(Self-invocation)로 프록시를 안 탄다

Spring의 @Transactional은 AOP 프록시 기반이다.
프록시를 통해 호출될 때만 트랜잭션이 새로 열리고(REQUIRES_NEW), 커밋/롤백이 관리된다.

그런데 내 코드는 이런 구조였다.

scheduledQueue() (같은 클래스)
- processOneMessage()를 직접 호출

이 같은 빈 내부에서 자기 메서드 호출은 프록시를 거치지 않는다.
그래서 processOneMessage()에 REQUIRES_NEW를 붙여도, 실제로는 새로운 트랜잭션이 열리지 않을 수 있다.

결과적으로 아래 코드는 의도와 달리 2000개를 한 트랜잭션으로 처리하는 효과가 남는다.

@Scheduled(fixedRate = 500)
@Transactional
public void scheduledQueue() {
    for (...) {
        processOneMessage(msg); // 같은 빈 내부 호출 -> 프록시 미적용 가능
    }
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void processOneMessage(SnapshotMsg msg) { ... }

3. 해결: 메시지 처리 로직을 별도 빈으로 분리하기

그래서 DB 반영 (processOneMessage)을 별도 컴포넌트로 분리했다.

스케줄러: 큐에서 poll만 하고 위임 프로세서 빈: 메시지 1개를 트랜잭션으로 처리

그리고 스케줄러 메서드의 @Transactional은 제거했다.

스케줄러 빈

@Component
@RequiredArgsConstructor
public class BalanceSnapshotProjector {
    private final Queue sharedMessageQueue;
    private final SnapshotMessageProcessor processor;

    @Scheduled(fixedRate = 500)
    public void scheduledQueue() {
        int max = 2000;
        for (int i = 0; i < max; i++) {
            SnapshotMsg msg = sharedMessageQueue.poll();
            if (msg == null) break;
            processor.processOneMessage(msg); // 다른 빈 호출 -> 프록시 적용
        }
    }
}

처리 빈

@Component
@RequiredArgsConstructor
public class SnapshotMessageProcessor {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void processOneMessage(SnapshotMsg msg) {
        // 1,2,3,4,5 처리
    }
}

이렇게 바꾸니 트랜잭션이 메시지 1개 단위로 끊기면서 락이 누적되지 않았고, 같은 조건에서 데드락이 일어나지 않았다.

4. 정리

@Transactional + for(2000) 조합은 트랜잭션 생존시간이 길어지고 락이 누적될 가능성이 커진다.

REQUIRES_NEW를 쓸때는 프록시를 타는 호출인지 확인하는 것이 핵심이라고 생각했다.

같은 빈 내부 호출(self-invocation)이면 REQUIRES_NEW가 적용되지 않을 수 있다.

트랜잭션/락 문제는 SHOW ENGINE INNODB STATUS + 트랜잭션 TRACE 로그를 확인하여 방향을 잡으면 해결이 빨라진다.

Spring mysql jpa 데드락 상황 해결 과정

Mon, 01 Dec 2025 11:06:08 GMT

0. 당시 상황

나는 현재 뱅킹 시스템을 혼자 만들어 보고 있었고 locust로 테스트를 하는데 deadlock을 만나게 되었다

transfer 서비스는 HTTP 요청을 받아 실제 이체를 처리하는 온라인 트랜잭션이다.

available_balance에서 출금 가능 금액을 차감하고
snapshot_balance를 업데이트하고
ledger_entry에 이중기장(DEBIT/CREDIT)을 기록하고
outbox에 이벤트를 적재한다.

비동기 프로젝터는 Outbox → MQ → 메모리 큐(sharedMessageQueue)를 통해 들어온 메시지를 처리하는 오프라인 트랜잭션이다.

snapshot_balance를 업데이트하고
available_balance를 증가시키고
ledger 상태를 COMMITTED로 확정한다.

transfer 서비스

@Transactional
public void transfer(Long fromId, Long toId, Long amount) {
    // 1. 출금 계좌: 가용잔액 차감
    availableBalanceRepo.tryDebit(fromId, amount);
    //  → available_balance(account_id = fromId) UPDATE (SELECT ... FOR UPDATE 포함 가능)

    // 2. 출금 계좌: 스냅샷 -amount 반영
    snapshotRepository.applyDelta(fromId, -amount);
    //  → snapshot_balance(account_id = fromId) 에
    //     INSERT ... ON DUPLICATE KEY UPDATE (PK = account_id)

    ledgerRepo.saveAll(List.of(debit, credit)); // 원장에 2줄 insert
    outboxRepository.save(outbox);                // outbox에 insert
}

스케줄러 (인메모리 큐에서 메시지를 빼어 스냅샷, 가용잔액에 반영하는 스케줄러)

@Scheduled(fixedRate = 500)
@Transactional
public void scheduledQueue() {
    for (...) {
        SnapshotMsg msg = sharedMessageQueue.poll();
        if (msg == null) break;

        if (ledgerRepository.existsByTxIdAndSideAndStatus(
                msg.txId(), EntrySide.CREDIT, Status.COMMITTED)) {
            continue;
        }

        try {
            snapshotAppliedRepository.save(SnapshotApplied.of(msg.accountId(), msg.txId()));

            snapshotRepository.applyDelta(msg.accountId(), msg.amount());  // 1. snapshot + insert
            int updated = availableBalanceRepo.credit(msg.accountId(), msg.amount());  // 2. available + update
            if (updated == 0) throw ...;

            outboxRepository.markSent(msg.outboxId());
            ledgerRepository.markCommitted(msg.txId(), msg.accountId(), msg.entrySide());
        } catch (DataIntegrityViolationException dup) {
            outboxRepository.markSent(msg.outboxId());
        }
    }
}

1. 왜 발생했을까

왜 발생할까에 대해 계속 고민하다가 이상한 점을 하나 찾았다

출처 : 땔감툰

프로젝터 입장에서 특정 계좌 accountId에 대해 테이블을 만지는 순서는 다음과 같다.

snapshot_balance(accountId) – applyDelta(+amount)
available_balance(accountId) – credit(+amount)

즉, 락 순서: snapshot => available 이다.

transfer입장에서 accountId에 대해 테이블을 만지는 순서는 다음과 같다.

available_balance(accountId) – tryDebit(-amount)
snapshot_balance(accountId) – applyDelta(-amount)

즉, 락 순서: available => snapshot 이다.

예를 들어서,

계좌 A, B, C가 있다고 하자. 이전에 B → A 송금이 이미 발생했고, 그때 생성된 “계좌 A, CREDIT, +10,000원” 메시지가 Outbox → MQ → sharedMessageQueue 에 들어와 있다.

그 와중에 사용자가 A → C 송금을 요청했다. 즉, 아래 두 트랜잭션이 거의 동시에 실행될 수 있다.

두 트랜잭션은 모두 계좌 A에 대해 snapshot_balance와 available_balance를 건드린다.

T1 = 스케줄러 트랜잭션 (B → A 송금의 CREDIT 메시지 처리 중) snapshot_balance(A) += 10,000 (락 순서 1: snapshot_balance) available_balance(A) += 10,000 (락 순서 2: available_balance)

T2 = 온라인 트랜잭션 (A → C 송금 처리 중) available_balance(A) -= 50,000 (락 순서 1: available_balance) snapshot_balance(A) -= 50,000 (락 순서 2: snapshot_balance)

이 상황이라고 생각했다.

2. 문제를 해결

락 순서를 통일 시키면 해결이 될 것이라 생각해 프로젝터 입장 락 순서를 snapshot => available 에서 available => snapshot으로 수정했다.

// 변경 전 (프로젝터)
snapshotRepository.applyDelta(msg.accountId(), msg.amount());                // 1. snapshot
int updated = availableBalanceRepo.credit(msg.accountId(), msg.amount()); // 2. available

// 변경 후 (락 순서 통일: available -> snapshot)
int updated = availableBalanceRepo.credit(msg.accountId(), msg.amount()); // 1. available
snapshotRepository.applyDelta(msg.accountId(), msg.amount());             // 2. snapshot

그랬더니 snapshot deadlock은 더이상 볼 수 없게 되었다.

3. 그 이후

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed:
org.springframework.dao.CannotAcquireLockException: could not execute statement [Deadlock found when trying to get lock; try restarting transaction]
[insert into ledger_entry (account_id,amount,idempotency_key,memo,occurred_at,side,status,tx_id) values (?,?,?,?,?,?,?,?)]; 
SQL [insert into ledger_entry (account_id,amount,idempotency_key,memo,occurred_at,side,status,tx_id) values (?,?,?,?,?,?,?,?)]] with root cause

snapshot과 available의 락 순서는 맞춰서 해결했지만 ledger를 동시에 insert하는 부분이 남아있었다. 이 부분에서 새로운 deadlock이 나왔다.

이 데드락은 다음 글에서 정리해보겠다.

Can't lock pointer back immediately after escape 오류 해결하는 방법

Thu, 15 May 2025 02:11:41 GMT

0. 들어가기

R3F로 웹 게임을 제작하다가 Can't lock pointer back immediately after escape라는 오류를 만났습니다.. 이 오류는 LockPointerAPI라는 API를 쓸때 나는 오류입니다.. 마우스 커서가 Lock되있는 상태에서 사용자가 ESC를 누르고 다시 바로 상호작용시 오류가 나는 문제입니다. 해당 오류는 크게 2가지 정도 해결 방법이 있는 것을 알게 되었는데 그것을 정리해보고자 합니다.

1. 버튼 만들기

https://sbcode.net/threejs/follow-cam/ 이 방법은 Three.js 공식 사이트 튜토리얼 예제에서 쓴 방법입니다. PointerLock이 걸리고 ESC를 누르면 화면이 뿌애지면서 Click to Start라는 버튼을 표시합니다.

그리고 이 버튼을 클릭해야만 다시 Pointer Lock이 작동을 합니다. 저는 이방법으로 해결을 했습니다.

구현 코드

{pointerLocked ? null : (
    
)}

컴포넌트
import React, { useEffect, useState } from 'react';
import CTSbutton from './CTSbutton';

const ClicktoStart = ({ reqInside, pointerLocked }) => {
  const [visible, setVisible] = useState(false);
  useEffect(() => {
    const timeout = setTimeout(() => {
      setVisible(true);
    }, 1000);
    return () => clearTimeout(timeout);
  }, []);

  const handleClick = (e) => {
    if (pointerLocked) {
      e.preventDefault();
      return;
    }
  };

  return (
    
      
    
  );
};

export default ClicktoStart;

pointerLocked는 포인터가 잠긴 상태면 true, 아니면 false입니다. CTSbutton은 단순 버튼 컴포넌트입니다.

2. 시간차 두기

두 번째 방법은 inactivatePointerLock()이 호출될때 최근 pointer Lock이 활성화된 시점과 현재 시간의 차이를 계산해서 만약에 100ms보다 작으면 그냥 return을 해주는 코드입니다. 사용자가 너무 빨리 잠금해제/클릭을 하면 그것을 막을 수 있다고 합니다. 저는 어떻게 구현해야할지 이해가 안가서 첫 번째 방법을 사용해 해결했습니다.

let pointerLockActivatedAt = null;

function inactivatePointerLock() {
    const now = performance.now()
    if (pointerLockActivatedAt != null && now - pointerLockActivatedAt < 100) {
        return // 무시
    }
    // do your thing
}
function activatePointerLock() {
    const now = performance.now()
    pointerLockActivatedAt = now
}

이렇게 마치겠습니다. 오늘도 고생하셨습니다.

async await 은 진짜 비동기일까? 내부 작동 원리 알아보기

Fri, 02 May 2025 01:21:14 GMT

출처 : https://pozafly.github.io/javascript/event-loop-and-async/

들어가며

JavaScript를 하다 보면 async/await, Promise, setTimeout 등에서 예상치 못한 로그 순서를 마주하게 됩니다. 이번 글에서는 이벤트 루프, 콜 스택, 마이크로태스크, 콜백 큐를 중심으로 JavaScript의 비동기 실행 원리를 파헤쳐 보겠습니다.

async 함수는 언제 비동기일까?

async function asyncFunc() {
  console.log("1. Start");
  const data = await longRunningAsyncOperation(); // 논블로킹
  console.log("3. End");
}

console.log("0. Before asyncFunc call");
asyncFunc();
console.log("2. After asyncFunc call");

이 코드에서 로그 순서는 어떻게 될까요?

0. Before asyncFunc call
1. Start
2. After asyncFunc call
3. End

포인트

asyncFunc()을 호출하면 바로 실행되며, 내부 코드도 await 전까지는 동기적으로 실행됨.

await을 만나면 해당 줄 이후는 마이크로태스크 큐에 등록되고, 나중에 실행된다.

JavaScript 이벤트 루프 구조

JavaScript는 싱글 스레드 언어지만 비동기처럼 작동하는 이유는 이벤트 루프(Event Loop) 덕분입니다.

구성 요소

Call Stack : 실행 중인 함수들이 쌓이는 곳 Microtask Queue : Promise.then(), async/await, queueMicrotask() 등 Task Queue : (Callback Queue) setTimeout, setInterval, DOM 이벤트 등 Event Loop : 콜 스택이 비면 큐에서 작업을 꺼내 실행

실행 흐름 예제

console.log("1");

setTimeout(() => {
  console.log("2 - setTimeout");
}, 0);

Promise.resolve().then(() => {
  console.log("3 - Promise");
});

console.log("4");

실행 순서

1
4
3 - Promise
2 - setTimeout

1, 4는 동기 코드이니까 즉시 실행됩니다.

Promise.then()은 마이크로태스크 큐 → 콜 스택이 비자마자 실행됩니다. setTimeout()은 콜백 큐 → 마이크로태스크가 끝난 뒤 실행됩니다.

예제

async function run() {
  console.log("1");
  await Promise.resolve("result");
  console.log("2");
}

run();
console.log("3");console.log("3");
console.log("3");console.log("3");console.log("3");console.log("3");console.log("3");
console.log("3");console.log("3");console.log("3");console.log("3");console.log("3");
console.log("3");console.log("3");console.log("3");console.log("3");console.log("3");
console.log("3");console.log("3");console.log("3");console.log("3");console.log("3");
console.log("3");console.log("3");console.log("3");console.log("3");console.log("3");
console.log("3");console.log("3");console.log("3");console.log("3");console.log("3");
console.log("3");console.log("3"); // 3이지만 오래걸리는 동기작업 이라고 생각

실행 순서

1
3 (반복 출력)
2
console.log("2")는 await 이후라 마이크로태스크 큐에 들어감

모든 동기 작업이 끝난 후 실행됨 (절대 끼어들지 않음!)

비유로 이해하는 구조

브라우저
├── Web API (setTimeout, fetch 등)
├── JavaScript Engine
│   ├── Call Stack
│   ├── Callback Queue
│   ├── Microtask Queue
│   └── Event Loop

예를 들면 Web API = 무대 뒤 작업자들 (실제로 오래걸리는 일 작업중인 곳) JS 엔진 = 무대 감독 (어떤 장면이 올라갈지 선택, 결정함) Call Stack = 현재 무대 위 배우 (현재 작업중인 곳) Microtask/Callback Queue = 대기 중인 장면들 (대기중인 작업) Event Loop = 무대가 비었는지 확인하는 스태프 (다음 장면을 바로 올리는 스태프)

실전 예제: 순서 맞춰보세요!

console.log("A");

setTimeout(() => {
  console.log("B - setTimeout");
}, 0);

Promise.resolve().then(() => {
  console.log("C - Promise");
});

(async () => {
  console.log("D - async start");
  await Promise.resolve();
  console.log("E - after await");
})();

console.log("F");

순서 해설

A
D - async start
F
C - Promise
E - after await
B - setTimeout

A, D, F는 동기 Promise.then() → 마이크로태스크 큐 C await 이후 → 마이크로태스크 큐 E setTimeout() → 콜백 큐 B

정리

async 함수 await 전까지는 동기적으로 실행된다. await 이후 코드는 마이크로태스크 큐에 등록된다. 마이크로태스크 큐 Promise.then, await, 우선순위 높음 콜백 큐 (Task Queue) setTimeout, DOM 이벤트 등 이벤트 루프 콜 스택이 비면 큐에서 작업을 꺼내 실행한다.

Bun vs Node.js - Bun이 뭐야? JS 런타임 Bun이 Node.js를 대체할 수 있을까?

Mon, 10 Mar 2025 08:35:10 GMT

출처: https://expertbeacon.com/a-quick-look-at-bun-1-0-the-node-js-alternative/

0. Bun이란?

Bun은 JavaScript 개발 환경을 획기적으로 개선할 것을 목표로 만들어진 초고속 JavaScript 런타임입니다. Node.js, Deno와 같은 기존 런타임 대비 더 빠른 실행 속도와 가벼운 빌드 환경을 제공합니다.

출처: https://snyk.io/blog/javascript-runtime-compare-node-deno-bun/

Bun의 주요 특징

고속 실행: Safari 엔진인 JSC(JavaScriptCore)를 기반으로 동작하여, 기존 Node.js(V8 엔진)보다 더 빠른 실행 속도를 가짐.
내장 패키지 관리자: npm, pnpm 없이도 bun install을 통해 빠르게 의존성을 설치 가능.
TS & JSX 지원: 별도 설정 없이 TypeScript 및 JSX 파일 실행 가능.
네이티브 API 제공: fetch, WebSocket, FS 모듈 등 웹 API를 자체 지원.
번들러 & 테스트 러너 내장: 추가적인 빌드 툴 없이 번들링 및 테스트 실행 가능.
Node.js와 높은 호환성: 대부분의 Node.js 모듈과 함께 사용 가능.

출처: https://www.linkedin.com/pulse/bun-next-gen-javascript-runtime-jay-shah-cqvcf

1. Bun vs Node.js 성능 차이

Bun은 성능 면에서 기존 Node.js보다 강력한 경쟁력을 자랑합니다. 공식 벤치마크에 따르면 Bun은 Node.js보다 4배 빠른 실행 속도를 보여줍니다.

실행 속도 비교 (console.log("hi") 실행 기준)

Bun: Node.js 16 대비 약 4.5배 빠름
Deno: Node.js보다 2배 빠름
Node.js: 비교적 느린 실행 속도

패키지 설치 속도 비교 (bun install vs npm install)

Bun은 pnpm보다 빠른 패키지 설치 속도를 제공하며, 기존 npm 대비 최대 4배 빠름

2. Bun이 빠른 이유는?

Bun이 압도적인 속도를 자랑하는 이유는 다음과 같습니다.

1. JavaScriptCore (JSC) 사용

Bun은 V8 대신 JSC(JavaScriptCore) 엔진을 사용하여 빠른 Engine Start Time을 제공합니다.

브라우저 엔진 비교

Chrome, Brave, Edge → V8 사용
Safari → JavaScriptCore(JSC) 사용 (Bun도 동일)
Firefox → SpiderMonkey 사용

2. Zig 언어로 개발

Bun은 메모리 관리를 효율적으로 수행할 수 있는 Zig 언어로 개발되었습니다. Zig는 Rust처럼 안전성과 속도를 동시에 보장하는 언어이며, 이를 활용해 Bun은 최적화된 메모리 사용이 가능합니다.

3. 번들러 & 빌드 시스템 최적화

Node.js는 별도 번들러(Webpack, Rollup, esbuild 등)가 필요하지만, Bun은 자체 번들러를 내장하여 빌드 속도가 더 빠릅니다.

3. Node.js와의 호환성

Bun은 기본적으로 ES Modules (ESM)을 권장하지만, 기존 CommonJS (CJS)도 지원합니다. 따라서 기존 Node.js 프로젝트를 Bun으로 쉽게 마이그레이션할 수 있습니다.

지원하는 기능:

require() 및 import 모두 지원
process.env 및 Buffer와 같은 Node.js 글로벌 객체 사용 가능
Node.js의 네이티브 모듈 대다수와 호환 가능

그러나 일부 패키지는 Bun에서 완벽하게 동작하지 않을 수도 있습니다.

4. Bun을 사용해야 할까?

Bun은 빠른 속도와 간편한 설정을 원하는 스타트업, 실험적인 프로젝트, 개인 개발자에게 매우 유용합니다.

Bun을 추천하는 경우

빠른 실행 속도가 중요한 프로젝트 (예: CLI 툴, 서버리스 환경)
스타트업, 신규 프로젝트 (빠른 개발 & 배포가 중요한 경우)
패키지 설치 속도를 개선하고 싶은 경우

Node.js가 여전히 유리한 경우

안정성이 중요한 대규모 프로덕션 프로젝트
완벽한 호환성이 필요한 경우 (일부 패키지가 Bun에서 완전히 동작하지 않을 수 있음)
이미 Node.js 환경이 잘 구축된 팀

5. Bun 설치 방법

Bun을 설치하는 방법은 간단합니다. 터미널에서 다음 명령어를 실행하면 됩니다.

curl -fsSL https://bun.sh/install | bash

설치가 완료되면 bun 명령어를 사용할 수 있습니다.

bun --version

6. Bun 기반 초고속 프레임워크: ElysiaJS

Node.js의 Express, Fastify보다 훨씬 빠른 성능을 자랑하는 ElysiaJS가 Bun을 위한 서버 프레임워크로 주목받고 있습니다.

ElysiaJS 생김새

import { Elysia, t } from 'elysia';

new Elysia()
    .post('/sign-in', ({ body }) => signIn(body), {
        body: t.Object({
            username: t.String(),
            password: t.String()
        })
    })
    .listen(8080);

7. 결론

Bun은 빠른 실행 속도, 가벼운 패키지 관리, Zig 기반의 최적화된 메모리 사용을 통해 Node.js의 강력한 대안이 될 가능성이 높습니다. 다만 아직 호환성과 안정성이 100% 검증되지 않았기 때문에, 대규모 프로덕션 환경에서 사용하기 전에는 충분한 테스트 기간이 필요할 것 입니다.

향후 전망

Bun 생태계가 성장한다면, 장기적으로 Node.js를 대체할 수도 있을 것 같습니다.
현재로서는 스타트업, 개인 프로젝트, 신규 애플리케이션에 적합할 것 같습니다.

출처: https://codingmart.com/bun-1-0-fast-javascript-runtime-with-built-in-tools/

마치며

저는 이번에 Bun을 처음 알게 되었는데 여러분들은 알고 계셨나요? 이번에 처음 구글링을하며 js 런타임을 직접 만들 수 있다는 것에 놀랐습니다. 특히 Bun은 빠른 실행 속도, 메모리 최적화 등으로 사용할 만한 가치가 있다고 느꼈습니다.

코드 수정중인데 코드가 PR되었을 때 (git stash)

Thu, 20 Feb 2025 04:00:44 GMT

그림 출처: https://sysxplore.substack.com/p/what-is-git-stash

PR(풀 리퀘스트)이 머지되거나 업데이트되었을 때, pull을 하면 작업 중인 변경 사항이 날아갈 가능성이 있는 상황이 있습니다.

0. 결론

git stash 임시저장
git pull --rebase origin main 업데이트
git stash pop 임시저장 적용

작업을 안전하게 유지하는 방법

1. 변경 사항을 커밋하거나 스태시 하기

PR 업데이트 전에 작업이 날아가는 걸 방지하려면 커밋을 하거나 git stash로 임시 저장하는 게 좋습니다.

아직 커밋할 준비가 안 되었다면 스태시하기 git stash를 하면 현재 변경 사항이 임시로 저장되고 워킹 디렉터리는 깨끗한 상태가 되니 놀라지 마세요.

임시 저장하기
git stash

커밋 하기 (커밋 후에는 충돌을 해결할 가능성 있음)

커밋하기
git add .
git commit -m "add feature"

2. 업데이트된 PR 내용 가져오기 (rebase or merge)

1번째나 2번째 방법으로 해주시면 됩니다.

** 1. git pull --rebase origin main (pull 가져오기)**

git pull --rebase origin main  # (혹은 master, develop 등)

내 변경 사항을 PR 업데이트 위에 재적용함.
충돌이 나면 해결한 후 git rebase --continue 실행.

리베이스는 내 커밋을 최신 업데이트 위에 올려서 히스토리를 일직선으로 유지하게 도와주며, 머지 커밋이 생성되지 않습니다.

** 2. git pull (머지)**

git pull origin main

기존 변경 사항과 PR 업데이트 내용을 병합.
필요하면 충돌을 해결하고 커밋.

3. 스태시 사용 시 내 작업 다시 적용

스태시를 사용했으면 둘중 하나로 스태시를 적용시켜 주시면 됩니다.

임시저장 꺼내기
git stash pop  # 스태시에서 꺼내서 다시 적용

혹은

임시저장 적용하기
git stash apply  # 스태시를 적용하지만, 삭제되지는 않음.

4. 결론

git stash
git pull --rebase origin main
git stash pop
충돌나면 빠르게 reset 해줍시다...

Expo go java.io.IOException: Failed to download remote update 오류 해결하는 방법

Thu, 13 Feb 2025 08:03:51 GMT

0. 배경

최근 Expo Go와 React Native를 연동하는 과정에서 java.io.IOException: Failed to download remote update라는 오류가 발생하여 해결해보았습니다.이번 글에서는 이 오류가 발생한 원인과 그에 대한 해결 방법을 공유하고자 합니다.

먼저 Expo go로 QR scan을 하고 오류가 난 뒤에 Viw error log를 눌러주세요

저의 경우는 오류에 java.io.IOException: Failed to download remote update가 떴습니다.

1. 해결 방법 찾기

그래서 오랜 구글링을 하다가 https://www.reddit.com/r/expo/comments/1gr2tij/javaioioexception_failed_to_download_remote_update/?rdt=64267 이런 래딧글을 발견했습니다. 저와 비슷한 오류를 겪고 있는 유저였고 여러 해결 의견들중에

Remarkable_Car_9916 Just a guess, but are you using windows? I think its very likely the windows defender which blocks the request. You do not see any logs in the terminal on the host machine where you start the expo app isnt it? if I am correct with my assumings you need to enable access to the node.js (javascript) runtime on your machine for the local network. activate both private and public networks.
Edit: Sometimes the settings can break without changing them! ie after a restart. I am not very sure about if it's a problem on expo side or on windows side, but anyway if it breaks, check the settings again. you might find a new node.js (javascript) runtime. if so activate both private and public network access as well. And it should work again. But this is just a quick workaround, not a fix of the problem itself.

윈도우 Defender를 확인해보라는 글이었습니다. Window 방화벽 설정을 확인하고 변경해주니 바로 해결되었습니다. 아래는 해결 방법 단계입니다.

1. Windows Defender 방화벽 열기

1. cmd로 열기

Windows Key + R을 눌러서 실행을 열어주시고 wf.msc를 입력하시면 바로 방화벽이 열립니다.

2. 찾기로 열기

찾기에서 Windows Defender 방화벽을 쳐서 열어줍니다. 왼쪽 사이드바에서 고급 설정에 들어가주세요.

2. 인바운드 규칙 들어가기

왼쪽 로컬 컴퓨터의 고급 보안이 포함된 Windows Defender 방화벽에서 인바운드 규칙에 들어가주세요.

여기에서 Node.js JavaScript Runtime을 찾아주세요. 여기서 빨간 경고 아이콘이 있으면 연결이 차단되어 있는 것입니다. 모두 V 표시가 되어있다면 문제가 없으신 것입니다.

3. 연결 허용

경고 아이콘인 Node.js JavaScript Runtime 더블클릭

작업에 연결 허용(L) 눌러주시면 됩니다.

4. 재시도

expo start

다시 Expo Start 해서 QR찍어보시면 됩니다.

캐시 초기화 해서 하기

expo start --clear

오류가 해결 되셨으면 좋겠습니다. 고생하셨습니다.

왜 페이스북은 Git을 사용하지 않을까 - 대부분의 개발자는 Git을 사용할까 (번역글)

Thu, 06 Feb 2025 07:35:45 GMT

Facebook, by solomon7 via Shutterstock

페이스북의 내부 개발은 처음에 Subversion을 사용하고 Git 미러를 운영하는 방식으로 시작했으나, 이후 소스 코드 관리를 위해 Mercurial로 전환했다. 이에 대해 페이스북에서 일했던 일부 개발자들은 "압도적으로 최고의 개발 도구"라고 평가했지만, 대부분의 개발자는 여전히 Git을 사용하고 있으며, 이러한 흐름이 바뀔 가능성은 낮다.

Graphite라는 코드 리뷰 도구 회사의 공동 창립자이자 CTO인 Greg Foster는 지난 3월 페이스북이 Git을 사용하지 않는 이유에 대해 글을 작성했다. 그는 페이스북에서 근무한 적은 없지만, Graphite 도구들이 페이스북 내부 개발 환경에서 영감을 얻었다고 밝혔다. 그는 페이스북이 왜 Git을 사용하지 않는지를 조사했다.

그 이유는 규모의 문제였다. 페이스북은 방대한 코드베이스를 가지고 있으며, 모든 코드가 하나의 저장소에 포함되는 모노레포(monorepo) 방식을 사용하고 있다. 엔지니어들은 코드베이스가 계속 증가할 경우 어떤 문제가 발생할지 예측했고, 기본적인 Git 명령어 실행에 45분 이상이 소요된다는 사실을 발견했다.

페이스북은 Git 유지보수팀에 해결책을 문의했지만, 답변은 코드베이스를 여러 개의 저장소로 나누라는 것이었다. 그러나 페이스북은 Mercurial 팀과 논의했고, Mercurial은 협력할 의사를 보였다. 그 결과 페이스북은 Mercurial의 성능을 개선하는 데 기여했고, 대규모 모노레포를 관리하는 데 가장 적합한 버전 관리 시스템이 되었다고 Foster는 전했다.

어떤 개발자는 Reddit에서 "여러 회사를 다녀봤지만, 메타(Meta)의 개발 도구가 단연 최고였다"고 말했다. 또 다른 개발자는 "나는 지금 메타에서 일하고 있는데, 솔직히 시스템이 너무 특이하지만 실제로는 잘 작동한다"고 평가했다.

그렇다면 다른 개발자들도 Mercurial을 사용해야 할까? 가능성은 있지만, Foster는 "10년이 지난 지금, Git도 모노레포를 더 잘 지원하도록 상당한 개선이 이루어졌다"고 지적했다.

다만, 페이스북은 일반적인 사례와 다르다. 페이스북은 방대한 자원을 투자해 자체 개발 도구를 최적화할 수 있기 때문이다. 현재 페이스북은 Git을 완전히 배제한 것은 아니며, Sapling SCM이라는 Git 호환 도구를 일부 사용하고 있다. 이 도구의 CLI는 원래 Mercurial 기반으로 개발되었으며, EdenFS라는 가상 파일 시스템을 포함하고 있다. EdenFS는 메타의 프로덕션 환경에서는 사용되지만, 오픈소스 환경에서는 빌드되지 않으며 외부에서 사용할 수 없다. 즉, 페이스북 내부에서는 효과적이지만, 일반 개발자들이 사용하기에는 적합하지 않은 맞춤형 도구인 것이다.

Git은 복잡하고 직관적이지 않은 경우가 많다. 예를 들어, 특정 파일을 .gitignore 목록에 추가하더라도 이미 추적 중인 파일은 자동으로 Git에서 제외되지 않는다. Stack Overflow에서 9,000개 이상의 추천을 받은 답변에 따르면, 추적을 중지하려면 다음과 같이 명령어를 실행해야 한다.

git rm --cached

하지만 이 명령어를 실행하면, 다른 개발자가 git pull을 할 때 해당 파일이 삭제된다는 문제가 있다. 개발자가 로컬에서 해당 파일을 유지하면서 Git에서만 제외하려면 추가적인 조치가 필요하다.

그럼에도 불구하고 Git의 성장세는 멈출 기미가 보이지 않는다. 2020년 Atlassian은 Bitbucket Cloud에서 Mercurial 지원을 중단하고, Git을 기본 버전 관리 시스템으로 채택했다. 2022년 Apple의 Safari에 사용되는 WebKit 오픈소스 프로젝트가 Subversion에서 GitHub로 이동했다. 2023년 Mozilla는 Firefox 개발을 Mercurial에서 GitHub로 이전했다.

Git usage share according to a 2022 StackOverflow survey

현재 Stack Overflow의 설문조사에 따르면, Git은 93.87%의 점유율을 차지하고 있으며, 그다음으로 많이 사용되는 Subversion은 5.18%에 불과하다.

개발자들이 Git을 선택하는 이유 중 하나는 Git이 이미 표준이 되었기 때문이다. Git의 단점에도 불구하고, 대부분의 개발자가 Git을 알고 있기 때문에 새로운 개발자를 빠르게 온보딩할 수 있다. 또한, GitHub와 GitLab 같은 플랫폼이 제공하는 이슈 관리, 토론 기능, 보안 기능, CI/CD(지속적 통합 및 배포) 지원 등이 Git의 가치를 더욱 높이고 있다.

출처 : https://devclass.com/2024/07/17/why-facebook-does-not-use-git-and-why-most-other-devs-do/

Three.js를 이용해 웹사이트를 예쁘게 꾸며보자! – 5 (Camera)

Wed, 05 Feb 2025 07:05:59 GMT

지난글

Material
MeshBasicMaterial
MeshLambertMaterial
MeshPhongMaterial
MeshToonMaterial
MeshStandardMaterial
MeshPhysicalMaterial

이어서

지난 포스트에서는 주로 많이 쓰이는 텍스쳐들을 알아봤는데요. 이번 포스트에서는 카메라에 대해 알아보겠습니다. 카메라는 저희가 보는 눈을 담당하기 때문에 많이 중요합니다. 이번에는 카메라 개념을 빠르게 알아보고 예제 하나를 해보고 마무리할께요.

0.Camera

출처 : https://www.tutorialspoint.com/threejs/threejs_perspectivecamera.htm

fov는 field of view(시야각)의 줄임말입니다. 예제의 경우 수직면 75도로 설정했습니다. 알아둬야 할 건 Three.js의 대부분이 각도 단위로 호도(radians)를 사용하는데, 원근 카메라만 특이하게 도(degrees)를 인자로 받는다는 점입니다.

aspect는 canvas의 가로 세로 비율입니다. 이는 다른 글 에서 자세히 다루겠지만, 기본 설정으로 canvas의 크기는 300x150이니 비율도 300/150, 2로 설정했습니다.

Near와 Far는 카메라 앞에 렌더링되는 공간 범위를 지정하는 요소입니다. 이 공간 바깥에 있는 요소는 화면에서 잘려나가며, 렌더링되지 않을 것입니다.

위에서 살펴본 4가지 속성은 하나의 "절두체"를 만듭니다. "절두체"는 끝부분이 잘려나간 피라미드처럼 생긴 3차원 모양인데, 구, 정육면체, 각기둥(prism)처럼 3차원 모양의 하나로 생각하면 됩니다.

결국 위의 사진을 보면 Near와 Far사이의 공간만 저희 카메라로 볼 수 있다는 뜻입니다. Mesh를 조절하다가 갑자기 안보이면 Carmera 설정도 확인해보면 좋습니다.

1.사용법

사실 저희 예제에도 계속 있었습니다.

const fov = 70;
const aspect = window.innerWidth / window.innerHeight;
const near = 0.1;
const far = 100;
const camera = new THREE.PerspectiveCamera(fov, aspect, near, far);

바로 이부분인데요 near는 0.1, far은 100 즉 position 0.1~100정도 볼 수 있었던거예요. 저런식으로 4가지 요소를 주고 new THREE.PerspectiveCamera 를 해주면 됩니다. PerspectiveCamera는 원근법이 적용된 카메라인데요 원근법을 없애고 싶으면 OrthographicCamera 정사영 카메라를 사용하시면 됩니다.

2.예제 코드

예제코드는 전에 쓰던 예제코드를 변형해서 만들어볼께요

index.html


  
    
    
    Document

index.js
import * as THREE from './node_modules/three/build/three.module.js';

const canvas = document.querySelector('#c');
const renderer = new THREE.WebGLRenderer({ antialias: true, canvas });
renderer.setSize(window.innerWidth, window.innerHeight);
const fov = 70;
const aspect = window.innerWidth / window.innerHeight;
const near = 0.1;
const far = 100;
const camera = new THREE.PerspectiveCamera(fov, aspect, near, far);
camera.position.z = 10;

const scene = new THREE.Scene();

const color = 0xffffff;
const intensity = 10;
const light = new THREE.DirectionalLight(color, intensity);
light.position.set(0, 10, 0);
scene.add(light);

const geometry = new THREE.SphereGeometry(1);
const material = new THREE.MeshBasicMaterial({
  color: '#049ef4',
  clearcoat: 1, // 빤딱빤딱
  clearcoatRoughness: 0.5,
});
const mesh = new THREE.Mesh(geometry, material);
scene.add(mesh);

const geometry2 = new THREE.SphereGeometry(2);
const material2 = new THREE.MeshBasicMaterial({
  color: 'red',
  clearcoat: 1, // 빤딱빤딱
  clearcoatRoughness: 0.5,
});
const mesh2 = new THREE.Mesh(geometry2, material2);
mesh2.position.set(0, 0, 0);
scene.add(mesh2);

let angle = 0;
const radius = 5; // 공전 반경
const speed = 0.01; // 회전 속도

function animate() {
  angle += speed;
  mesh.position.x = Math.cos(angle) * radius;
  mesh.position.z = Math.sin(angle) * radius;

  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

animate();

이렇게 만들어주고 보면 이렇게 태양을 도는 지구처럼 빙글빙글 돌게 됩니다. 그냥 도는거 보는건 식상해서 이번엔 저 원을 한번 따라다녀보도록 하겠습니다.

3.lookAt

lookAt은 카메라가 보는 위치를 정할 수 있는 함수입니다. lookAt(position[])을 넣어주면 그 좌표를 쳐다보게됩니다. 이것을 활용해보겠습니다. 아래쪽 animate 부분을 살짝 수정해주세요

let angle = 0;
const radius = 5;
const speed = 0.01;

function animate() {
  angle += speed;
  mesh.position.x = Math.cos(angle) * radius;
  mesh.position.z = Math.sin(angle) * radius;

  camera.lookAt(mesh.position);

  renderer.render(scene, camera);

  requestAnimationFrame(animate);
}
animate();

카메라가 지구를 따라다니는 것 보이시나요? 이런식으로 mesh의 좌표를 줘서 쳐다보게끔 할 수 있습니다.

4.camera.position

카메라가 있는 위치또한 바꿔줄 수 있습니다. camera.position = position(,,) 줄수 있고 그 위치로 카메라가 가게됩니다. position과 lookAt을 활용해서 만들어 볼게요. 지구 위를 따라다니면서 태양을 찍어보겠습니다.

let angle = 0;
const radius = 5;
const speed = 0.01;

function animate() {
  angle += speed;
  mesh.position.x = Math.cos(angle) * radius;
  mesh.position.z = Math.sin(angle) * radius;

  const cameraOffset = 3;
  camera.position.x = mesh.position.x + Math.cos(angle) * cameraOffset;
  camera.position.z = mesh.position.z + Math.sin(angle) * cameraOffset;
  camera.position.y = mesh.position.y + 3;
  camera.lookAt(mesh2.position);

  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

animate();

하지만 뭔가 아직 아쉬워서 조금 더 다이나믹하게 만들어볼게요.

import * as THREE from './node_modules/three/build/three.module.js';

const canvas = document.querySelector('#c');
const renderer = new THREE.WebGLRenderer({ antialias: true, canvas });
renderer.setSize(window.innerWidth, window.innerHeight);
const fov = 70;
const aspect = window.innerWidth / window.innerHeight;
const near = 0.1;
const far = 100;
const camera = new THREE.PerspectiveCamera(fov, aspect, near, far);
camera.position.set(0, 5, 10);

const scene = new THREE.Scene();
const light = new THREE.DirectionalLight(0xffffff, 2, 50);
light.position.set(0, 3, 0);
scene.add(light);
// 지구 (Mesh)
const geometry = new THREE.SphereGeometry(1);
const material = new THREE.MeshBasicMaterial({ color: '#049ef4' });
const mesh = new THREE.Mesh(geometry, material);
scene.add(mesh);
// 태양 (Mesh2)
const geometry2 = new THREE.SphereGeometry(2);
const material2 = new THREE.MeshBasicMaterial({ color: 'red' });
const mesh2 = new THREE.Mesh(geometry2, material2);
mesh2.position.set(0, 0, 0);
scene.add(mesh2);

let angle = 0;
const radius = 5;
const speed = 0.01;
const cameraPositions = [
  { x: 7, y: 5, z: 6 },
  { x: -6, y: 3, z: 7 },
  { x: 6, y: 1, z: -7 },
  { x: -7, y: 0, z: 6 },
];

let currentPositionIndex = 0;
function moveCameraToNextPosition() {
  currentPositionIndex = (currentPositionIndex + 1) % cameraPositions.length;
}
function animate() {
  angle += speed;
  mesh.position.x = Math.cos(angle) * radius;
  mesh.position.z = Math.sin(angle) * radius;

  const targetPosition = cameraPositions[currentPositionIndex];
  camera.position.x = targetPosition.x;
  camera.position.y = targetPosition.y;
  camera.position.z = targetPosition.z;
  camera.lookAt(mesh.position);

  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}
//2초마다 바꾸기
setInterval(moveCameraToNextPosition, 2000);
animate();

2초마다 시점을 바꾸면서 지구를 따라가게 됩니다. 조금 다이나믹해진 것 같습니다.

정리

이번 포스트에서는 카메라에 대해 다뤄봤습니다. 카메라는 3D 씬에서 우리가 보는 눈이기 때문에 굉장히 중요한 요소입니다.

원근법(Perspective) 카메라와 정사영(Orthographic) 카메라로 나누어 집니다.
카메라 기본 속성 : fov, aspect, near, far
camera.lookAt()을 사용해 카메라가 항상 특정 객체를 쳐다보도록 만들 수 있음.
camera.position을 직접 설정하여 카메라의 위치를 변경할 수 있습니다.

감사합니다. 오늘도 굉장히 길었는데 고생하셨어요.

while-true-study.log

이미지를 굳이 CNN으로 봐야 하나? - Vision Transformer (ViT)

1. 그런데 이미지는 원래 어떻게 보고 있었지?

2. 왜 CNN은 굳이 작은 영역부터 볼까?

3. Transformer는 조금 다르게 생각했다

4. 그럼 이미지를 어떻게 Transformer에 넣지?

5. 이미지를 Patch로 잘라보자

6. 그런데 Patch를 그냥 Transformer에 넣을 수 있나?

7. 그런데 이미지에서 위치가 바뀌면 큰일 아닌가?

8. 갑자기 [CLS]는 왜 나올까?

9. 여기까지 왔으면 이제 거의 Transformer다

10. 근데 CNN도 작은 영역을 보고 ViT도 Patch를 보잖아?

11. 그럼 ViT가 CNN보다 무조건 좋은 건가?

12. 데이터가 엄청 많아지면?

13. 그러면 Patch 안에서 CNN을 쓰면 더 좋은 거 아닌가?

14. Patch는 작을수록 좋은 거 아닌가?

15. 결국 ViT는 뭘 한 걸까?

마치며

논문 정보

문장을 굳이 순서대로 읽어야 하나? (Attention Is All You Need)

Transformer를 만든 논문, Attention Is All You Need

1. Transformer 이전에는 문장을 어떻게 읽었을까?

2. 지금 이 단어와 관련 있는 단어는 뭘까? ( Self-Attention )

3. Q, K, V는 뭘까?

4. 논문에 나오는 Attention 수식도 같은 이야기다

5. 왜 $\sqrt{d_k}$로 나눌까?

6. Attention 하나로는 부족했나?

7. RNN을 없앴더니 문제가 하나 생겼다

8. Transformer 그림을 보자

9. Decoder에는 왜 Mask가 붙어 있을까?

10. 그래서 RNN보다 뭐가 좋았을까?

11. 실제 성능은?

12. Attention을 만든 논문이 아니다

Transformer를 한 문장으로 설명하면?

논문 정보

블로그 검색에 Elasticsearch를 붙이면서 MySQL-ES 정합성 맞춘 과정 (Outbox 패턴)

0. 문제 상황

예시 1) 생성 시

예시 2) 삭제 시

1. 처음 생각했던 방식

문제점

2. 그래서 Outbox 패턴으로 바꿨다

전체 흐름

3. 내가 만든 구조

3-1. 역할 분리

3-2. 전체 처리 흐름

4. 데이터 모델에서 중요했던 점

4-1. post 엔티티에 syncVersion 추가

4-2. outbox_event에 넣은 정보

4-3. Elasticsearch 문서 구성

필드 구성

5. 구현 흐름

5-1. 생성

생성 흐름

5-2. 수정

수정 흐름

수정 후 확인한 것

5-3. 삭제

삭제 흐름

6. 구현하면서 막혔던 부분

6-1. payload 컬럼 길이 부족

해결

6-2. LocalDateTime 직렬화 문제

해결

6-3. updatedAt이 ES에 반영되지 않던 문제

원인

해결

6-4. post_status에 DELETED 저장 실패

원인

해결

6-5. 수정 API 테스트에서 인증 객체 null

해결

7. 실제로 확인한 것

생성 검증

수정 검증

삭제 검증

8. 한계점

8-1. 초기 대량 색인

8-2. 오래된 이벤트 역전 방지

8-3. 보정 배치

8. 갑자기 `[CLS]`는 왜 나올까?

4-1. `post` 엔티티에 `syncVersion` 추가

4-2. `outbox_event`에 넣은 정보

6-1. `payload` 컬럼 길이 부족

6-2. `LocalDateTime` 직렬화 문제

6-3. `updatedAt`이 ES에 반영되지 않던 문제

6-4. `post_status`에 `DELETED` 저장 실패

4-1. 해결: `post_id` 범위 분할 + 병렬 재색인

5-2. `document_id` 문제로 `deleted`만 폭증

5-3. `hosts => ["http://elasticsearch:9200"]` vs `localhost:9200`

7-1. `all shards failed` 발생