RDBMS vs BigQuery/Redshift: SMP와 MPP 아키텍처 차이 (비전공자 공부 정리)
데이터 엔지니어링 공부를 시작하면서 BigQuery나 Redshift를 처음 접했을 때, 솔직히 이런 생각이 들었어요.
“그냥 MySQL이랑 뭐가 달라? 어차피 SQL 쓰는 거 아니야?”
쿼리 문법도 비슷하고, 테이블 구조도 비슷한데 왜 굳이 다른 도구를 쓰는 건지 감이 안 잡혔거든요. 근데 SMP와 MPP 아키텍처 개념을 공부하고 나서야 “아, 이게 그냥 쿼리 도구 차이가 아니라 구조 자체가 다른 거구나”를 이해하게 됐어요.
오늘은 그 내용을 최대한 쉽게 정리해볼게요. 비전공자 입장에서 처음 이 개념을 마주하는 분들께 도움이 됐으면 해요.
RDBMS는 어떻게 데이터를 처리할까? — SMP 구조
RDBMS, 그러니까 MySQL이나 PostgreSQL 같은 전통적인 관계형 데이터베이스는 SMP(Symmetric Multi-Processing) 구조로 동작해요.
SMP를 한 줄로 요약하면 이렇게요.
하나의 강력한 서버 안에서, 여러 CPU가 메모리와 디스크를 함께 공유하며 일한다.
비유를 들자면, 회사에서 혼자 일하는 슈퍼 에이스 직원 같은 느낌이에요. 머리도 좋고(CPU), 책상도 넓고(메모리), 서랍도 많은(디스크) 사람인데, 결국 혼자 처리해야 하는 거예요.
처음엔 이 구조가 별문제 없어 보여요. 데이터가 수십만 건 정도라면 단일 서버 하나로도 충분히 빠르거든요. 근데 데이터가 수억 건, 수십억 건으로 늘어나기 시작하면 문제가 생기기 시작해요.
→ SMP 핵심 정리: 자원을 공유하는 단일 서버 구조, 작은 데이터엔 강하지만 한계가 있다.
RDBMS의 구조적 한계 — Lock 병목과 Scale-up의 벽
SMP 구조에서 가장 큰 문제는 자원을 공유한다는 점이에요.
여러 요청이 동시에 들어오면, CPU들이 같은 메모리와 디스크를 쓰려고 서로 기다려야 해요. 이걸 Lock 병목이라고 해요. 쉽게 말하면, 화장실이 하나뿐인 사무실에서 직원들이 줄 서서 기다리는 상황이에요.
그렇다면 해결책은 뭘까요? 서버를 더 좋은 걸로 바꾸는 거예요. CPU를 더 많이 꽂고, 메모리를 더 크게 늘리는 방식이죠. 이걸 Scale-up(수직 확장) 이라고 해요.
근데 여기서 한계가 명확해요. 서버 한 대가 가질 수 있는 CPU와 메모리에는 물리적인 한계가 있거든요. 아무리 좋은 서버도 결국 한계 용량이 존재하고, 그 이상은 돈을 아무리 써도 올릴 수가 없어요. 게다가 스펙이 올라갈수록 비용이 기하급수적으로 비싸지죠.
수백 테라바이트, 페타바이트급 데이터를 다루는 데이터 웨어하우스 환경에서 RDBMS가 한계를 보이는 이유가 바로 여기에 있어요.
→ Lock 병목 + Scale-up 한계 = RDBMS가 빅데이터에 적합하지 않은 이유.
BigQuery/Redshift는 어떻게 다를까? — MPP 구조
BigQuery, Redshift 같은 클라우드 데이터 웨어하우스는 MPP(Massively Parallel Processing) 구조를 사용해요.
SMP가 ‘슈퍼 에이스 직원 혼자’라면, MPP는 개미 군단이에요.
수백, 수천 대의 서버(노드)가 각자 자신의 데이터와 메모리를 독립적으로 가지고, 동시에 일한다.
이 구조의 핵심 키워드는 Shared-Nothing(공유 없음) 이에요. 각 노드는 다른 노드의 자원을 빌리거나 기다리지 않아요. 각자 자기 몫의 데이터만 처리하고, 결과를 합치는 방식이죠.
이 구조 덕분에 Lock 병목이 생기지 않아요. 아무도 서로를 기다리지 않으니까요. 화장실이 직원 수만큼 있는 사무실이라고 생각하시면 돼요.
→ MPP 핵심 정리: 독립된 노드들이 동시에 처리하는 구조, Lock 없이 병렬 처리가 가능하다.
MPP에서 쿼리는 어떻게 처리될까? — 마스터 노드와 워커 노드
여기서 자연스럽게 이런 궁금증이 생길 수 있어요.
“수백 대의 서버가 동시에 일한다고? 그럼 누가 지휘하는 거야?”
MPP 구조에는 마스터 노드(리더 노드) 라는 총감독 역할을 하는 서버가 있어요. 쿼리를 받으면 마스터 노드가 이렇게 일해요.
- 쿼리를 분석하고 쪼갠다 — “이 쿼리, A 구간은 노드 1~50이 처리해, B 구간은 노드 51~100이 처리해.”
- 각 워커 노드에 일을 분배한다 — 각자 자기 데이터만 처리하면 되니까 빠르게 움직여요.
- 중간 결과를 모아서 합친다 — 워커들이 처리한 결과를 마스터 노드가 받아서 최종 답을 내보내요.
예를 들어, 10억 개의 로그 데이터에서 특정 이벤트를 집계하는 쿼리를 날린다고 해볼게요. RDBMS라면 단일 서버가 10억 개를 처음부터 끝까지 훑어야 해요. MPP에서는 마스터 노드가 이걸 1000개 조각으로 나눠서 워커 1000개에 동시에 던져요. 각 워커는 100만 개씩만 처리하면 되고, 그 결과를 합치면 끝이에요.
처리 시간이 이론상 1/1000로 줄어드는 거예요.
→ 마스터 노드가 쿼리를 쪼개고, 워커들이 병렬 처리하고, 결과를 합치는 구조.
Scale-out, 그래서 뭐가 좋은 건데?
MPP 구조의 또 다른 강점은 Scale-out(수평 확장) 이 가능하다는 거예요.
SMP(RDBMS)의 Scale-up이 “더 좋은 서버 하나로 교체”라면, MPP의 Scale-out은 “서버를 옆으로 늘리는 것”이에요.
데이터가 10배 늘었다면? 노드 수를 10배 늘리면 돼요. 이론적으로 한계가 없어요. 클라우드 환경에서는 이게 버튼 몇 번으로 가능하고, 쓴 만큼만 비용을 내는 구조라서 비용 효율도 훨씬 높아요.
RDBMS에서 수백 테라바이트 데이터를 처리하려면 어마어마한 스펙의 서버가 필요하고 비용도 감당이 안 되는데, BigQuery는 그냥 쿼리 날리면 알아서 노드를 늘려서 처리하고 결과를 돌려줘요. 심지어 얼마나 많은 노드를 썼는지 신경 쓸 필요도 없어요.
→ Scale-out = 서버를 옆으로 늘리는 것, 데이터 증가에 유연하게 대응 가능.
그럼 RDBMS는 쓸모없는 건가요?
물론 아니에요. 둘은 설계된 목적 자체가 달라요.
RDBMS는 OLTP(Online Transaction Processing), 즉 실시간으로 수많은 소규모 트랜잭션을 빠르게 처리하는 데 최적화되어 있어요. 쇼핑몰에서 주문이 들어올 때마다 재고를 업데이트하고, 결제를 기록하는 작업 같은 거요. 이런 작업은 데이터 규모가 작고 정확성이 중요하기 때문에 RDBMS가 훨씬 적합해요.
반면 BigQuery, Redshift 같은 MPP 기반 DW는 OLAP(Online Analytical Processing), 즉 대용량 데이터를 한 번에 쭉 읽어서 집계하고 분석하는 용도에 최적화되어 있어요. “지난 1년간 전체 사용자 행동 패턴을 분석해줘” 같은 쿼리는 MPP 구조가 압도적으로 빨라요.
| RDBMS (SMP) | BigQuery/Redshift (MPP) | |
|---|---|---|
| 아키텍처 | 단일 서버, 자원 공유 | 다수 노드, Shared-Nothing |
| 확장 방식 | Scale-up (수직) | Scale-out (수평) |
| 병목 | Lock 경합 발생 | Lock 없음 |
| 최적 용도 | OLTP (실시간 트랜잭션) | OLAP (대용량 분석) |
| 데이터 규모 | GB ~ TB | TB ~ PB |
→ RDBMS와 MPP DW는 경쟁 관계가 아니라, 용도에 따라 선택하는 다른 도구예요.
마무리 — 구조를 알면 선택이 보인다
솔직히 처음 SMP, MPP 같은 용어를 마주쳤을 때 “이걸 외워야 하나?” 싶었어요. 근데 개념을 이해하고 나니까 단순히 용어 암기가 아니라, 왜 BigQuery가 수십억 행 쿼리를 몇 초 만에 처리하는지를 자연스럽게 이해하게 되더라고요.
데이터 엔지니어링 면접에서도 이 개념은 단골 질문이에요. “BigQuery와 RDBMS의 차이를 설명해보세요” 같은 질문에 단순히 “클라우드냐 아니냐”로 답하는 게 아니라, SMP vs MPP, Shared-Nothing, Scale-out 키워드로 설명할 수 있으면 훨씬 좋은 인상을 줄 수 있어요.
여러분도 이 개념이 처음엔 낯설게 느껴지실 수 있는데, ‘슈퍼 에이스 혼자 vs 개미 군단’으로 기억해두시면 훨씬 쉽게 정리될 거예요.
다음엔 BigQuery의 컬럼 기반 저장 방식(Columnar Storage)에 대해서도 정리해볼게요. MPP와 함께 알아두면 왜 분석 쿼리가 그렇게 빠른지 완전히 이해할 수 있거든요.