들어가며: 확장성을 말하려면 질문부터 정해야 한다

우리는 종종 “X 시스템은 확장성이 좋다” 또는 “Y 시스템은 확장성이 없다"는 말을 듣습니다. 하지만 확장성(Scalability) 은 단순히 좋다/나쁘다로 나눌 수 있는 개념이 아닙니다. 확장성은 증가하는 부하(Load)에 시스템이 어떻게 대응하는가 에 관한 문제이며, 결국 다음 질문에 답하는 과정입니다.

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

확장성을 제대로 이야기하려면 먼저 우리 시스템의 ‘부하’와 ‘성능’을 숫자로 표현해야 합니다. 이 글에서는 확장성을 분석할 때 필요한 기본 개념을 정리합니다.

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

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

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

여기서 중요한 점은 평균적인 상황만으로는 충분하지 않다 는 것입니다. 소수의 무거운 요청이나 피크 타임 트래픽이 시스템 전체의 병목을 만들 수 있습니다. 부하를 설명할 때는 평균값뿐 아니라 최대 부하 시나리오도 함께 봐야 합니다.

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와 같은 상위 백분위에서의 높은 응답 시간을 꼬리 지연 시간 이라고 부릅니다. 서비스에서 가장 느린 응답을 경험하는 사용자들이 여기에 포함됩니다. 평균 응답 시간이 좋아 보여도 p99가 나쁘면 일부 사용자는 계속 느린 서비스를 경험합니다.

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

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

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

  • 수평적 확장 (Scaling Out / Horizontal Scaling): 여러 대의 장비에 부하를 분산시키는 방식입니다. (예: 로드 밸런서 뒤에 여러 웹 서버를 두는 것) 초기 설계는 더 복잡하지만, 특정 장비 하나에 의존하지 않고 용량을 늘릴 수 있습니다.

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

‘확장성’은 막연한 구호가 아니라, 다음 순서로 분석할 수 있는 엔지니어링 문제입니다.

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

이렇게 부하와 성능을 숫자로 정의해두면, 확장성 논의가 감이 아니라 측정과 실험에 가까워집니다.

이 글은 AI의 도움을 받아 교정 및 정리되었습니다.