데이터베이스 병목 현상

발행: (2026년 4월 22일 PM 07:50 GMT+9)
3 분 소요
원문: Dev.to

Source: Dev.to

“It was fast… until users showed up.”
그것은 빠른데… 사용자가 나타날 때까지라고 나는 친구에게 시스템을 디버깅하면서 말했다.

The Problem

모든 요청이 데이터베이스에 의존했다. 사용자가 무언가를 할 때마다:

  • 데이터를 가져오기
  • 레코드 업데이트하기
  • 잔액 확인하기

작은 규모에서는 문제가 없었다. 하지만 규모가 커지면서 모든 요청이 같은 자원을 놓고 경쟁하게 되었고, 데이터베이스는 병목 현상이 되었다:

  • 읽기 과다
  • 쓰기 과다
  • 동시 쿼리 과다

그리고 애플리케이션 서버와 달리 데이터베이스는 무한히 확장할 수 없다.

Why This Is Dangerous

시스템은 여전히 동작하지만, 사용자는 다음과 같은 현상을 겪기 시작한다:

  • 응답 지연
  • 지연 시간 증가
  • 타임아웃

사용자 수가 늘어날수록 성능은 더욱 악화된다.

The Solution

데이터베이스를 없애는 것이 아니라, 그 의존도를 줄이는 것이다. 실제 시스템은 다음과 같이 구현한다:

  • 자주 읽는 데이터를 캐시하기
  • 무거운 읽기를 위해 읽기 복제본 사용하기
  • 쿼리와 인덱스 최적화하기
  • 무거운 작업을 백그라운드 작업으로 옮기기

목표는 간단하다: 필요할 때만 데이터베이스에 접근하라.

Mental Model

데이터베이스를 한 명의 계산원에 비유해 보라. 처음엔 줄이 없지만, 사람이 더 많이 오면 모두가 기다리게 된다—계산원은 완벽히 일하고 있음에도 불구하고.

The Lesson

시스템이 느려지는 이유는 고장이 난 것이 아니라, 모든 것이 하나의 요소에 의존하기 때문이다.

Takeaway

확장 가능한 시스템은 단순히 더 많은 사용자를 처리하는 것이 아니라, 가장 중요한 구성 요소에 가해지는 압력을 줄인다.

0 조회
Back to Blog

관련 글

더 보기 »

SQL에서 서브쿼리와 CTE

SQL을 사용할 때 결국 단일 query만으로는 충분하지 않은 상황에 직면하게 됩니다. 문제를 여러 부분으로 나누고, intermediate 결과를 계산해야 합니다.