DBMS 완전 정복 시스템 구성부터 쿼리 최적화까지 [1]
시스템 디자인 데이터베이스 설계편.
데이터베이스의 역할
DBMS => Database Management System
데이터베이스(Database) 의 주요 역할은 신뢰성있는 데이터 저장 그리고 애플리케이션 내부의 다른 컴포넌트들간의 데이터 공유를 돕는 것으로 정의할 수 있다. 또한, 우리는 데이터베이스를 주요 데이터들의 원천으로 사용한다는 점이다.
따라서, 데이터베이스는 목적성에 따라 다르게 서빙(Serving)될 수 있습니다.
일시적으로 부하가 몰리는 데이터를 다루기 위해서.
오랜 시간동안 저장되는 저장소를 위해서.
복잡한 분석 쿼리를 허용하기 위해서.
키를 사용하여 데이터 값에 접근하기 위해서.
큰 블롭 데이터(Large Blobs) 를 효율적으로 처리하기 위해서.
이러한 목적들이 있지만, 데이터베이스는 크게 3가지의 카테고리로 나뉠 수 있습니다.
Online Transaction Processing(OLTP) Databases
실시간으로 빠르고 정확하게 다수의 사용자 트랜잭션 요청을 처리하는 시스템을 말합니다.
예시로 MySQL, PostgreSQL, Oracle 이 있습니다.
Online Analytical Processing (OLAP) Databases
온라인 분석 처리 시스템으로, 비즈니스 의사결정에 필요한 인사이트를 제공하기 위한 데이터 분석에 사용되는 데이터베이스 시스템 입니다.
아래는 예시입니다.
“올해 2분기 미국 지역에서 가장 많이 팔린 상품은?”
“지난 3년간 월별 매출 추세를 카테고리별로 보고 싶다”
“지역별로 사용자의 이탈률 분석”
예시로 BigQuery, Redshift, Snowflake 등이 있습니다. 다차원 분석을 빠르게 처리하고, 전략적 의사결정을 지원하는 읽기 중심 대규모 데이터베이스입니다.
Hybrid Transactional and Analytical Processing (HTAP)
HTAP 는 OLTP 와 OLAP 두 개의 속성을 결합한 데이터베이스 시스템 입니다.
인터뷰 팁!
OLAP 는 읽기 위주의 대규모 분석 시스템이므로, 사용자의 액션 처리용 시스템 OLTP 와 분리된 구조로 운영됩니다. 일반적으로 ETL → DW → BI 구조를 설계하게 되며, 이 때 OLAP DB 는 DW(Data Warehouse) 역할을 합니다.
예상 질문 시나리오
“월간 매출 보고서를 빠르게 생성할 수 있는 시스템을 설계하라”
“OLAP DB 를 왜 따로 분리해서 써야 하나요?”
DBMS Architecture - 아키텍처
현대의 데이터베이스 관리 시스템(DBMS)은 단순한 CRUD 스토리지가 아닙니다. 효율적인 쿼리 수행, 트랜잭션 처리, 장애 복구, 메모리 최적화까지 수많은 컴포넌트들이 협업하여 데이터의 정확성과 속도를 보장합니다. 이 글에서는 빅테크 면접에서 자주 등장하는 DBMS 내부 구조와 작동 방식을 한눈에 이해할 수 있도록 정리했습니다.
DBMS 아키텍처 한눈에 보기
DBMS는 Transport → Query Processor → Execution Engine → Storage Engine
4단계로 이루어져 있습니다.
1) Transport Layer
클라이언트와의 통신을 담당합니다.
쿼리는 이 계층에서 Query Processor로 전달됩니다.
2) Query Processor
Query Parser: 쿼리를 파싱, 해석, 유효성 검증합니다.
Query Optimizer: 불필요한 연산을 제거하고 최적 실행 계획을 만듭니다.
Index cardinality, intersection size, access method 선택, cardinality estimation 등을 통해 가장 효율적인 경로를 계산합니다.
실무 팁: 대부분의 RDBMS는 이 Optimizer의 성능에 따라 쿼리 속도가 수십 배 이상 차이날 수 있습니다.
3) Execution Engine
최적화된 실행 계획에 따라 로컬 또는 원격 노드에 쿼리를 실행합니다.
클러스터 환경에서는 Remote Execution을 통해 분산된 데이터에 접근합니다.
4) Storage Engine
다양한 하위 컴포넌트가 함께 작동합니다.
Transaction Manager - 트랜잭션 스케줄링 및 일관성 보장
Lock Manager -데이터 객체에 대한 락을 관리
Access Methods - B-Tree, LSM Tree 등 실제 데이터 구조와의 인터페이스
Buffer Manager - 디스크 ↔ 메모리 간 페이지 캐싱
Recovery Manager - 장애 발생 시 로그 복구 및 상태 복원
메모리 기반 DBMS vs 디스크 기반 DBMS
In-Memory DBMS
모든 데이터를 RAM에 저장하고, 디스크는 복구용 로그 저장소로만 사용
성능은 빠르지만, 전원 차단이나 장애 시 휘발성으로 인한 위험 존재
고성능 저지연이 필요한 환경 (예: 실시간 분석, 캐시 시스템)에 적합
Disk-Based DBMS
데이터를 디스크에 저장하고 필요한 경우 일부를 메모리에 캐싱
복구 및 내구성(durability)이 뛰어나며, 일반적인 OLTP/OLAP 용도에 적합
Meta 엔지니어와의 모의 시스템 디자인 인터뷰 기출
Check Pointing 기법 - 일정 시점에 snapshot을 생성하고, 그 이후의 로그는 폐기하여 복구 시간 단축
Memory DBMS의 약점과 극복 전략
단점
RAM은 휘발성이기 때문에 전원 차단, 오류 발생 시 데이터 유실 가능
해결책
Disk로 백업 유지
Write-Ahead Logging으로 durability 확보
배터리 백업 RAM, NVRAM 같은 하드웨어적 접근도 존재
시스템 디자인 관점
Query Optimizer는 DBMS의 두뇌이며, 효율적인 쿼리 수행의 핵심
Execution Engine과 Storage Engine은 실제 I/O와 트랜잭션의 병렬성을 관리
In-Memory vs Disk-Based 구조 선택은 성능 ↔ 내구성의 트레이드오프
Buffer Manager와 Recovery Manager는 실무에서 자주 튜닝하게 되는 영역
인터뷰 대비 팁
“Query Optimizer가 선택하는 기준은?” → Index cardinality, Access method, Join order 등 언급
“In-memory DBMS의 단점은?” → 데이터 유실 위험, 복구 메커니즘 필요성
“Storage Engine 내부 구성은?” → Transaction, Lock, Access Method, Buffer, Recovery 다섯 요소 언급
종류와 개념 비교
관계형 데이터베이스 (RDBMS)
관계형 데이터베이스는 데이터를 테이블(행과 열)의 형태로 저장하며, 테이블 간에 관계인 키 제약을 맺어 구조화된 정보를 관리합니다.
각 테이블에는 기본 키(Primary Key)가 설정되어 행을 고유 식별하고, 다른 테이블은 해당 키를 외래 키(Foreign Key)로 참조하여 정규화된 관계를 구축합니다. 이러한 체계는 데이터 무결성과 ACID 트랜잭션을 보장하여 금융 거래와 같이 정확성과 일관성이 중요한 업무에 적합합니다.
예를 들어, 은행 시스템에서 계좌 이체는 하나의 트랜잭션으로 처리되어, 중간에 일부만 적용되는 일이 없도록 원자성(Atomicity)과 일관성(Consistency)을 유지합니다.
RDBMS는 SQL이라는 질의 언어로 복잡한 조인과 집계를 수행할 수 있어 관계가 많은 데이터를 다루는 데 강점이 있습니다. 그러나, 스키마가 고정되고 수직적으로 확장(서버 성능 향상)에 의존하는 경향이 있어, 급격히 증가하는 데이터나 트래픽을 처리할 때는 수평 확장이 어려울 수 있습니다.
수평 확장을 위해 샤딩(sharding)이나 레플리카(Replica) 즉, 복제본 구축으로 읽기 부하는 분산할 수 있지만, 데이터의 쓰기(Write) 부하를 분산하려면 데이터 파티셔닝(Partitioning)과 어플리케이션 단의 복잡한 논리가 필요합니다. 요약하면, 관계형 DB는 정형화된 데이터 구조와 강한 정합성을 요구하는 시스템에서 여전히 최선의 선택이며, 트랜잭션 무결성이 핵심인 애플리케이션에 적합합니다.
NoSQL 데이터베이스
NoSQL은 “Not Only SQL”의 약자로, 전통 RDBMS와 다른 유연한 데이터 모델과 수평 확장성을 제공하는 비관계형 데이터베이스들을 포함하는 포괄적 용어입니다.
자세히는 데이터 모델에 따라 여러 하위 유형으로 나뉘며, 공통적으로 스키마가 고정되어 있지 않거나 느슨하고, CAP 이론에서 전통적인 RDBMS가 일관성(C) 위주인 반면 NoSQL 시스템들은 가용성(A)이나 파티션 내구성(P)을 더 중시하도록 설계된 경우가 많습니다. 결과적으로 빅데이터나 실시간 웹앱 등 규모가 크고 변화가 빠른 데이터를 처리하는 데 유리하며, 쓰기·읽기 성능과 확장성을 위해 일부 즉시 정합성을 희생하는 BASE성향의 설계가 흔합니다.
Basically
Available
Soft state
Eventual consistency
NoSQL의 대표적인 하위 유형은 다음과 같습니다.
키-값 저장소(Key-Value Storage)
해시 테이블처럼 고유 키로 값을 저장/조회하는 가장 단순한 형태입니다.
예를 들어, Redis, DynamoDB 등이 이에 속하며, 애플리케이션에서 캐시나
세션 관리처럼 키로 직접 데이터를 가져오는 용도에 적합합니다.
키 기반으로 O(1)에 가까운 빠른 조회 성능을 내지만, 값의 내부를 기준으로
한 질의는 지원하지 않기 때문에 범위 검색이나 조건 필터가 필요할 경우
한계가 있습니다.
그럼에도 불구하고 대규모 트래픽에도 일관된 저지연을 보장하고, 구조가 단순하여 확장성과 분산 구성에 용이합니다. 예컨대 아마존 Dynamo 시스템은
쇼핑카트 서비스에 키-값 스토어를 활용하여
서버 장애시에도 고가용성(High Availability) 을 보장했는데,
이는 전통 RDBMS가 엄격한 정합성 때문에 달성하기 어려웠던 부분입니다.
DynamoDB 는 네트워크 분할 중에도 쓰기를 허용하는 AP 지향 설계로
언제든 쓰기 가능한 시스템을 구현했고,
결국 DynamoDB 등의 상용 서비스로 발전했습니다.
문서 지향 데이터베이스 (Document Object Database)
JSON, BSON, XML 등 문서 형식으로 데이터를 저장하는 DB로 MongoDB, CouchDB 등이 해당됩니다.
한 문서(document)가 보통 하나의 객체나 레코드에 해당하며,
필드를 자유롭게 추가할 수 있어 스키마가 유연합니다.
예를 들어, MongoDB에서는 같은 컬렉션에 속한 사용자 문서마다
각기 다른 속성을 가질 수 있고, 새로운 속성을 추가해도
다른 문서에 영향이 없습니다.
내부 필드로 인덱싱과 질의가 가능하여, 관계형 DB의 테이블처럼
필터나 범위 조회도 지원합니다. 즉 키-값 스토어보다 풍부한 쿼리가
가능하면서도, 관계형 DB처럼 모든 레코드가 동일 스키마를 가질 필요가
없어서 데이터 모델의 진화에 탄력적입니다.
Aggregation 파이프라인을 통해 집계 연산도 수행할 수 있지만,
복잡한 조인이나 다중 문서에 걸친 트랜잭션은 제약이 있습니다.
MongoDB도 최근 다중문서 트랜잭션을 도입했으나,
전통 RDBMS만큼 강력하지는 않습니다.
웹 애플리케이션, 사용자 프로필, 콘텐츠 관리 시스템(CMS) 등에 많이 쓰이며, 데이터 구조가 자주 변경되거나 다양한 형식의 데이터를 수용해야 할 때
특히 유용합니다.
컬럼 패밀리 데이터베이스
Google Bigtable 논문에서 유래한 와이드 컬럼 스토어로, HBase, Cassandra, ScyllaDB 등이 있습니다. 행(Row) 대신 컬럼 패밀리 단위로 데이터를 묶어 저장하며, 각 행마다 갖는 컬럼 수나 구조가 달라도 허용됩니다.
예를 들어, Cassandra에서는 한 “행”이 수천 개의 컬럼을 가질 수도 있고, 다른 행은 몇 개만 가질 수 있습니다.
이러한 유연한 테이블 구조와 분산 해시 파티셔닝을 결합하여 수평 확장에 매우 뛰어난 특성을 보입니다. 대용량 데이터를 저장하고 부분 집합(특정 컬럼들)만 빠르게 읽어오는 패턴에 최적화되어, 시계열 데이터나 IoT 센서 데이터,
로그 수집 등에 널리 활용됩니다.
수억 건 이상 대량의 행을 가지는 테이블에서도 특정 컬럼만 조회하면 불필요한 데이터를 읽지 않아도 되어 효율적이며, 컬럼 단위 압축으로 저장 효율도
높습니다. 다만 데이터 모델이 관계형보다 덜 직관적이고 복잡한 조인 연산이
불가능하므로, 애플리케이션 레벨에서 데이터를
비정규화(denormalization)하여 중복 저장하는 등의 설계가 필요합니다.
AP 지향 시스템이 많아(예: Cassandra는 멀티 마스터 구조로 일관성보다
가용성을 택함) 강한 정합성이 요구되는 실시간 트랜잭션에는 부적합하지만,
노드 간 자동 복제와 장애 허용도가 높아 글로벌 서비스에 적합합니다.
실제로 넷플릭스(Netflix)는 Cassandra를 여러 리전에 분산 배치해 수십억 개의 시청 이벤트와 사용자 행동 로그를 저장하고, 서비스 중단 없이 데이터를 무한 확장하도록 구축했습니다.
그래프 데이터베이스 GraphQL
데이터간 복잡한 연결 관계를 노드(Node)와 간선(Edge)의 그래프 모델로
표현하는 DB입니다. Neo4j, Amazon Neptune 등이 대표적이며,
소셜 네트워크, 추천 시스템, 지식 그래프 등에서 관계 중심 질의에
뛰어난 성능을 보입니다.
예를 들어, 친구의 친구를 탐색하거나, 특정 사용자와 두 다리 이하로
연결된 사람들을 찾는 질의는 관계형 DB로 조인만으로 구현하면
복잡하고 느리지만, 그래프 DB에서는 인접 노드를 탐색하는 것으로
직관적으로 처리됩니다.
노드는 개체(사용자, 제품 등), 에지는 개체 간의 관계(“~의 친구”, “~를 구매함” 등)를 나타내고, 둘 다 속성(Property)을 가질 수 있어 관계 자체에도 정보를
담습니다. 이처럼 관계 그 자체를 일급 데이터로 취급하기 때문에,
다단계 연결이나 최단 경로 탐색 등의 연산이 최적화되어 있습니다.
그래프 DB는 내부적으로 인메모리 그래프 트래버설 등을 통해
고성능을 내지만, 수평 확장은 상대적으로 까다롭습니다.
데이터가 거대해지면 노드를 분산 저장해야 하는데,
분산 환경에서 그래프 질의는 통신 비용이 높아지므로 일반적으로
특정 규모 이하 데이터셋에 적합하거나, 혹은 특정 도메인별 서브그래프로
분할하는 전략이 필요합니다.
그래프 DB는 추천 엔진에서 사용자-아이템 관계를 파악하거나, 사기 탐지에서 복잡한 거래 네트워크의 패턴을 찾는 데 활용되고, SNS 팔로워 관계나 메시지 전파 경로 등의 분석에도 유용합니다.
요약하면, NoSQL 데이터베이스들은 관계형에 비해 데이터 모델 유연성과 확장성 측면에서 우위를 가지며, 대용량 데이터나 실시간 웹 규모를 처리할 때 주로 선택됩니다. 다만, 일반적으로 즉각적인 강한 정합성은 포기하거나(예: Eventually Consistent 모델) 제한된 범위에서만 제공하므로, 애플리케이션 수준에서 정합성 유지 전략이 필요할 수 있습니다. 면접에서 NoSQL을 논할 때는 해당 유형이 어떤 제약을 완화하고 무엇을 얻었는지 (예: 스키마 유연성 vs. JOIN 불가, 높은 가용성 vs. 잠재적 데이터 불일치)를 언급하는 것이 중요합니다.
다음에서 이어집니다.