들어가며: 확장성에 대한 올바른 질문 던지기

우리는 종종 “X 시스템은 확장성이 좋다” 또는 “Y 시스템은 확장성이 없다"와 같은 말을 듣곤 합니다. 하지만 확장성(Scalability) 은 단순히 좋다/나쁘다로 평가할 수 있는 이분법적인 개념이 아닙니다. 확장성은 증가하는 부하(Load)에 시스템이 얼마나 효과적으로 대처할 수 있는 능력 을 의미하며, 이에 대해 논의하는 것은 다음과 같은 구체적인 질문에 답하는 과정입니다.

“만약 시스템의 부하가 현재의 두 배가 된다면, 어떤 일이 발생할까?” “현재의 성능을 유지하면서 두 배의 부하를 처리하려면, 어떤 자원을 얼마나 더 투입해야 할까?”

이처럼 확장성을 제대로 이해하고 설계하려면, 먼저 우리 시스템의 ‘부하’와 ‘성능’을 명확하고 정량적으로 기술하는 방법부터 알아야 합니다. 이 글에서는 확장성을 체계적으로 분석하기 위한 기본 개념들을 살펴보겠습니다.

1. 부하 기술하기: 무엇이 시스템을 바쁘게 만드는가?

확장성을 논의하려면, 먼저 현재 시스템이 경험하고 있는 부하를 간결하고 구체적인 숫자로 표현해야 합니다. 이를 부하 매개변수(Load Parameters) 라고 합니다. 시스템의 아키텍처에 따라 적합한 부하 매개변수는 달라집니다.

  • 웹 서버: 초당 요청 수 (requests per second)
  • 데이터베이스: 읽기 대 쓰기 비율, 활성 커넥션 수
  • 실시간 채팅 서비스: 동시 접속자 수, 분당 전송되는 메시지 수
  • 캐시 시스템: 캐시 적중률 (cache hit rate)

여기서 중요한 점은 평균적인 상황만으로는 충분하지 않다 는 것입니다. 때로는 소수의 극단적인 요청(예: 매우 비싼 API 호출)이나 피크 타임의 트래픽이 시스템 전체의 병목 현상을 유발할 수 있습니다. 따라서 부하를 기술할 때는 평균적인 값과 함께 최대 부하 시나리오도 함께 고려해야 합니다.

2. 성능 기술하기: 시스템이 얼마나 잘하고 있는가?

부하를 명확히 정의했다면, 부하가 증가했을 때 시스템의 성능이 어떻게 변하는지를 측정해야 합니다. 성능을 나타내는 지표 역시 시스템의 종류에 따라 다릅니다.

  • 일괄 처리 시스템 (Batch Processing Systems): 대량의 데이터를 처리하는 시스템(예: Hadoop, 데이터 분석 파이프라인)의 경우, 주된 관심사는 처리량(Throughput) 입니다. (예: 초당 처리 가능한 레코드 수, 1TB 데이터 처리 시간 등)

  • 온라인 시스템 (Online Systems): 실시간으로 사용자의 요청에 응답해야 하는 시스템(예: API 서버, 웹사이트)의 경우, 가장 중요한 지표는 응답 시간(Response Time) 입니다.

3. 응답 시간 분석: 평균값의 함정과 백분위의 중요성

응답 시간은 요청마다 다르게 나타나는 가변적인 값이므로, 분포로 이해해야 합니다. 많은 시스템에서 응답 시간을 모니터링할 때 평균(average) 응답 시간 을 사용하지만, 이는 사용자 경험을 제대로 반영하지 못하는 위험한 지표일 수 있습니다.

예를 들어, 100개의 요청 중 99개가 100ms 만에 처리되고 단 1개의 요청이 10초(10,000ms) 걸렸다고 가정해 봅시다. 평균 응답 시간은 약 199ms로 매우 양호해 보이지만, 사용자 100명 중 1명은 10초라는 끔찍한 지연을 경험했습니다. 이처럼 평균값은 소수의 특이값(outlier)에 의해 쉽게 왜곡되며, 실제 사용자 경험의 ‘최악의 경우’를 숨깁니다.

이러한 문제를 해결하기 위해 백분위(Percentiles) 를 사용하는 것이 훨씬 효과적입니다.

  • 중앙값 (Median, p50): 전체 요청을 응답 시간이 빠른 순으로 정렬했을 때, 정확히 중간에 위치하는 값입니다. 이는 가장 일반적인 사용자 경험을 나타냅니다. (위 예시에서 p50은 100ms입니다.)

  • 상위 백분위 (High Percentiles, p95, p99, p99.9): ‘최악의 경우’를 측정하는 데 사용됩니다.

    • p95: 100개의 요청 중 95개는 이 시간보다 빠르고, 5개는 이 시간보다 느리다는 의미입니다.
    • p99: 100개의 요청 중 99개는 이 시간보다 빠르고, 단 1개만이 이보다 느리다는 의미입니다. (위 예시에서 p99는 10초에 가깝습니다.)

꼬리 지연 시간 (Tail Latency)

p95, p99, p99.9와 같은 상위 백분위에서의 높은 응답 시간을 꼬리 지연 시간 이라고 부릅니다. 서비스에 가장 불만족한 사용자들이 경험하는 시간이 바로 이 꼬리 지연 시간이며, 서비스의 품질을 결정하는 매우 중요한 지표입니다. Amazon과 같은 기업들은 꼬리 지연 시간을 줄이는 데 막대한 노력을 기울이는 것으로 알려져 있습니다. p99 응답 시간을 최적화하는 것이 충성도 높은 고객을 확보하는 비결이 될 수 있습니다.

4. 부하에 대처하는 접근 방식

부하와 성능을 정량적으로 파악했다면, 증가하는 부하에 대처하기 위한 전략을 선택할 수 있습니다.

  • 수직적 확장 (Scaling Up / Vertical Scaling): 더 강력한 하드웨어로 교체하는 방식입니다. (예: 더 빠른 CPU, 더 많은 메모리 추가) 구현이 간단하지만, 비용이 비싸고 단일 장비의 성능에는 물리적인 한계가 있습니다.

  • 수평적 확장 (Scaling Out / Horizontal Scaling): 여러 대의 장비에 부하를 분산시키는 방식입니다. (예: 로드 밸런서 뒤에 여러 웹 서버를 두는 것) 초기 설계는 더 복잡하지만, 비용 효율적이며 이론적으로 거의 무한한 확장이 가능합니다. 대부분의 현대적인 대규모 아키텍처는 수평적 확장을 기반으로 합니다.

결론: 확장성에 대한 체계적인 접근

‘확장성’은 막연한 개념이 아니라, 다음과 같은 체계적인 과정을 통해 분석하고 개선할 수 있는 구체적인 엔지니어링 문제입니다.

  1. 시스템의 부하 를 명확한 매개변수 로 정의합니다.
  2. 시스템의 성능 목표를 처리량 또는 응답 시간 백분위 로 설정합니다.
  3. 부하를 증가시키면서 성능이 어떻게 변하는지 측정하고 분석 합니다.
  4. 분석 결과를 바탕으로 수직적/수평적 확장 또는 아키텍처 개선 등 적절한 대처 전략을 선택합니다.

이러한 데이터 기반의 정량적인 접근 방식을 통해, 우리는 더 이상 ‘감’에 의존하지 않고 시스템의 확장성을 효과적으로 설계하고 관리할 수 있게 될 것입니다.