팀원과 소통 중 '분산'이란 단어가 참 골치아팠다.
다들 '분산'이라고 말하는 데 설명하는 바가 전혀 달랐기 때문이다.
"DB를 나누는 게 분산 아니야?"
"로드밸런싱으로 트래픽을 나눠 처리하면 분산 아니야?"
이렇게 대화를 시작하니 끝이 없었다.
오해를 방지하기 위해 분산이라 말할 수 있는 게 무엇이며 어떤 종류가 있는지 알아보자.
분산의 본질
분산이란 여러 개의 독립된 노드가 협력하여 하나의 작업 또는 서비스를 수행하는 것이다.
노드는 프로세스일 수도 있고 서버, 머신이어도 된다.
핵심은 물리적으로 나뉘어 있으며, 네트워크로 통신하여 하나처럼 보이게 동작해야한다는 점이다.
왜 이렇게 헷갈리는가?
우선 '분산 시스템'과 '분산 처리'를 분리할 필요가 있다.
분산 시스템은 여러 노드가 협력하여 서비스를 제공하는 구조이며,
분산 처리는 하나의 작업을 여러 노드가 나눠 병렬 수행하는 것이다.
분산을 나누는 기준은 두가지다.
1. 어디에서 분산되느냐 (구조 기준)
- 인프라 레벨
- 애플리케이션 레벨
- 데이터 레벨
2. 무엇을 분산하느냐 (처리 기준)
- 트래픽 분산
- 데이터 분산
- 연산 분산
아래의 다양한 분산 예시를 통해 어떤 차이가 있는지 살펴보자.
인프라 레벨의 분산
여기서는 요청(트래픽) 을 나눈다. (트래픽 분산)
1. 로드 밸런싱 (Load Balancing)

클라이언트의 요청을 여러 서버에 분산하여 전달하는 기술이다.
서버 과부하를 방지하고 가용성과 확장성을 확보하기 위해 사용된다.
서버가 하나인 단일 서버 구조인 경우 트래픽 폭증 시 다운된다. 장애라도 발생하면 전체 서비스가 중단되어 심각한 결과를 초래할 수 있다. 이러한 문제가 예상되는 경우 로드 밸런서 (Load Balancer)를 추가하여 요청을 분산시키는 것을 고려해봐야한다.
요청이 분산되면 서버 하나가 죽어도 서비스는 유지되고 수평적 확장(Scale-out)이 가능해진다.
이번 프로젝트에서 로드 밸런싱이 필요할 것 같아 정리할 예정이다. 더 자세한 내용은 다음 포스팅에 이어서 작성하겠다.
로드 밸런싱은 '분산 시스템'이지만
'연산을 분산 처리'하는 것은 아니다.
2. 트래픽 분산 (CDN, 멀티리전)
클라이언트의 요청을 물리적으로 다른 지역(Region)에 위치한 서버로 분산시키는 방식이다.
네트워크 지연(latency)을 줄이고, 특정 지역 장애로부터 서비스를 보호하기 위해 사용된다.
정말 말 그대로 다른 곳에 둔다는 말이다.
예를 들어 한국 사용자는 서울 리전으로, 미국 사용자는 오리건 리전으로 요청을 보내는 방식이다.
또한 정적 리소스의 경우 전 세계 여러곳에 분산된 서버 네트워크인 CDN(Content Delivery Network)을 사용하여 사용자와 가장 가까운 엣지 서버에서 응답하도록 구성한다.
쉽게 말하면 변하지 않는 파일들은 멀리 있는 본사 서버에서 가져오지 않고, 사용자 바로 옆에 있는 작은 서버에 미리 복사해 둔 후, 거기서 바로 보내주어 화면이 빨리 뜨게 만든다는 뜻이다.
이를 통해 응답 속도 개선, 글로벌 서비스 대응, 지역 장애 격리의 이점을 얻을 수 있다.
하지만 이런 분산은 요청을 지역 단위로 나누는 것이지 하나의 작업을 여러 서버가 협력하여 처리하는 것은 아니다.
트래픽 분산은 '분산 시스템'이지만
'연산을 분산 처리'하는 것은 아니다.
애플리케이션 레벨 분산
여기서는 기능과 책임을 나눈다. (구조적 분산)
1. Microservices Architecture (마이크로 서비스)
하나의 거대한 애플리케이션을 여러 개의 독립된 서비스로 분리하는 구조이다.
각 서비스는 독립 서버에서 실행되고, HTTP나 메시지 큐를 통해 통신한다.
이 구조를 통해 기능 단위로 책임이 분리되고, 독립 배포가 가능해진다.
하지만 이 또한 기능을 나눴을 뿐 하나의 연산을 여러 서버가 동시에 나눠 계산하지는 않는다.
마이크로서비스는 '분산 시스템'이지만
'연산을 분산 처리'하는 것은 아니다.
데이터베이스 분산
Replication에서는 읽기를 나누고(트래픽 분산), Sharding에서는 데이터를 물리적으로 나눈다. (데이터 분산)
1. Replication (복제)
하나의 Primary DB와 여러 Replica DB를 두는 구조이다.
Primary는 쓰기(Write)를 담당하고,
Replica는 읽기(Read)를 담당한다.
읽기 트래픽을 분산하고, 장애에 대비하여 데이터 안정성을 확보하는 데에 목적이 있다.
읽기 요청이 여러 서버로 나뉘기 떄문에 트래픽이 분산된다.
하지만 데이터 자체를 나눠 저장하는 것은 아니다.
Replication은 '분산 시스템'이지만
'데이터를 분할하여 처리하는 분산 처리'는 아니다.
2. Sharding (샤딩)
데이터를 여러 데이터베이스에 나눠 저장하는 방식이다. 수평 분할한다고도 한다.
예를 들면, 사용자 ID 1~10000까지는 1번 DB를 쓰고, 10001~20000까지는 2번 DB를 쓰는 것이다.
- User 1~10000 → DB1
- User 10001~20000 → DB2
데이터 자체가 정말 물리적으로 나뉘어 존재하기 때문에 전체 데이터를 조회하려면 여러 DB 노드의 결과를 모아야 한다.
이렇게 하는 이유는 데이터 용량과 쓰기 성능이 확장되어 대규모 서비스 대응이 용이하기 때문이다.
샤딩은 진짜 분산 데이터 처리 구조라고 할 수 있다.
데이터가 분리되어 있고, 여러 노드가 협력해야 전체 처리가 가능하기 떄문이다.
샤딩은 '분산 시스템'이면서
'데이터 분산 처리'에 해당한다.
빅데이터 프레임워크 (하둡, 스파크)
그렇다면 연산 분산이란 무엇일까? 앞에서 살펴본 로드 밸런싱, 마이크로서비스, 샤딩은 요청이나 기능, 데이터를 나누는 방식이었다. 하지만 연산 분산은 하나의 “작업”을 여러 서버가 동시에 나눠 계산하는 구조이다. 대표적인 예가 바로 하둡과 스파크 같은 빅데이터 프레임워크다.
즉, 대량의 데이터를 여러 노드가 동시에 나눠 처리하는 구조이다.
왜 연산을 분산해야 할까?
예를 들어 1TB 규모의 로그 파일을 분석해야 한다고 가정해보자.
단일 서버에서 이 파일을 처리한다면 아래와 같은 문제가 발생한다.
- 디스크 I/O 병목 발생
- CPU 사용률 100%
- 처리 시간 수 시간~수십 시간 소요
하지만 이를 100대 서버가 나눠 처리한다면 이야기가 달라진다.
- 1TB 로그 → 100개로 분할 → 100대 서버가 동시에 처리 → 결과를 모아 집계
처리 시간은 이론적으로 1/100 수준까지 줄어들 수 있다. 이것이 연산 분산의 핵심이다.
이 구조가 성립하려면 무엇이 필요할까?
연산 분산은 단순히 “서버를 여러 대 둔다”로 해결되지 않는다.
아래 세 가지 전제가 필요하다.
1. 데이터가 분산 파일 시스템에 저장되어야 한다.
데이터가 한 서버에만 있다면 결국 그 서버가 병목이 된다. 따라서 데이터 자체가 여러 노드에 분산 저장되어 있어야 한다.
하둡은 HDFS(Hadoop Distributed File System)를 통해 파일을 여러 서버에 블록 단위로 나누어 저장한다.
2. 연산이 병렬로 실행되어야 한다.
데이터가 나뉘어 있다면 각 노드에서 해당 블록을 독립적으로 처리할 수 있어야 한다.
예를 들면,
- 로그에서 특정 키워드 개수 세기
- 사용자 행동 집계
- 통계 계산
이러한 작업은 데이터 블록 단위로 나누어 처리 가능하다.
3. 결과를 다시 집계해야 한다.
각 노드에서 계산된 결과는 마지막에 다시 하나로 합쳐져야 한다. 이를 보통 Reduce 단계라고 부른다.
노드1 결과
노드2 결과
노드3 결과
→ 최종 집계
이 과정을 통해 하나의 최종 결과가 만들어진다.
이 방식의 목적은 아래와 같다.
- 대용량 데이터 처리
- 병렬 연산
- 처리 시간 단축
특히 로그 분석, 추천 시스템, 통계 처리, 머신러닝 학습 등 데이터 규모가 TB~PB 단위로 증가하는 환경에서는 연산 분산이 필수적이다.
이 경우에는 명확하게 '분산 시스템'이면서
'연산 자체가 분산 처리'된다.
전체 정리
| 구분 | 분산 시스템 | 연산 분산 처리 |
| 로드 밸런싱 | O | X |
| CDN / 멀티리전 | O | X |
| 마이크로서비스 | O | X |
| DB Replication | O | X |
| DB Sharding | O | O |
| 하둡 / 스파크 | O | O |
분산의 종류는 많지만 모든 분산이 ‘분산 처리’는 아니다.
인프라 분산, 구조적 분산, 데이터 분산, 연산 분산은 서로 다른 개념이기 때문에 소통에 오류가 생기지 않도록 개념을 잘 숙지하자.
'개발 > CS' 카테고리의 다른 글
| 서버는 왜 죽는가? - Nginx 로드밸런싱 (4) | 2026.04.02 |
|---|---|
| 채팅 기능 구현을 위한 WebSocket + STOMP 구조 정리 (5) | 2026.02.17 |