이번 초급 프로젝트에서는 PostgreSQL 을 채택해서 진행했다.
그런데 프로젝트와 별개로 진행하던 스프린트 미션에서는 MongoDB 를 사용하고 있었다.
멘토님은 스프린트 미션 코드리뷰도 함께 진행해주시고, 초급 프로젝트 방향까지 같이 봐주시는데,
그러다 보니 자연스럽게 “초급 프로젝트도 MongoDB를 쓰고 있겠구나” 하고 잠깐 오해하신 상황이 있었다.
그 작은 해프닝을 계기로 이런 궁금증이 생겼다.
- MongoDB와 PostgreSQL은 정확히 뭐가 다를까?
- 어떤 상황에서 서로 다른 DB를 선택하게 될까?
- 그리고 DB를 공부한다면, 결국 무엇을 깊게 파야 할까?
팀원분도 비슷한 질문을 멘토님께 드렸고, 돌아온 답변은 꽤 인상적이었다.
현업에서는 하나만 정답처럼 쓰이지 않는다.
서비스 성격과 상황에 따라 정말 다양한 DB가 사용된다.
그 말을 듣고 나니 단순히 “MongoDB vs PostgreSQL” 비교를 넘어서,
세상에는 어떤 종류의 데이터베이스가 있고, 각각 어디에 쓰이는지 정리해보고 싶어졌다.
그래서 이번 글에서는 다양한 데이터베이스의 종류와 특징, 그리고 어떤 상황에서 선택되는지를 중심으로 정리해보려고 한다.
1. 다양한 종류의 데이터베이스, 왜?
처음 데이터베이스를 접했을 때는
그냥 “데이터를 저장하는 공간” 정도로만 생각했었다.
그래서 왜 스프린트 미션에서는 MongoDB 를 사용하고,
초급 프로젝트에서는 PostgreSQL 를 사용하는지 크게 의문을 가지지도 않았다.
그런데 이번 기회에 조금 더 찾아보면서
데이터베이스는 생각보다 훨씬 다양한 종류가 존재한다는 걸 알게 됐다.
모든 데이터가 같은 모습일까?
아니다.
이게 어쩌면 이번 섹션에 핵심으로 작용된다.
예를 들어 데이터를 보면
- 사용자 정보처럼 구조가 명확한 데이터
- 게시글처럼 자유롭게 형태가 바뀌는 데이터
- 친구 관계처럼 연결 구조가 중요한 데이터
- 로그처럼 계속해서 대량으로 쌓이는 데이터
등이 존재한다.
즉, 데이터마다 다루는 방식과 성격 자체가 다르다는 뜻이다.
하나의 방식에서 생기는 한계
이런 데이터를 모두 하나의 방식으로 처리하려고 하면 분명 문제가 생긴다.
어떤 경우에는 구조가 지나치게 엄격해지고,
어떤 경우에는 성능이 떨어지며,
어떤 경우에는 데이터 관리 자체가 복잡해진다.
결국 데이터의 성격에 따라
더 적합한 저장 방식이 필요해지기 시작한 것이다.
그래서 등장한 것이 바로
각각 다른 방식으로 데이터를 저장하는 다양한 데이터베이스들이다.
데이터베이스를 나누는 대표적인 기준
정답은 바로 위에서 다뤘다.
데이터를 어떤 형태로 저장하느냐
이 기준에 따라 데이터베이스는
- 테이블 형태로 정리해서 저장하는 방식
- JSON 문서 형태로 묶어서 저장하는 방식
- key-value 형태로 빠르게 저장하는 방식
등으로 나뉘게 된다.
그리고 이 저장 방식의 차이가
각 데이터베이스의 특징과 사용 목적을 결정하게 된다.
2. 데이터를 저장하는 방식
앞에서 말했듯이
데이터베이스를 이해하는 가장 큰 기준 중 하나는
데이터를 어떤 방식으로 저장하느냐
이다.
이 기준으로 보면
데이터베이스 종류들이 왜 나뉘는지 조금 더 명확하게 보이기 시작한다.
데이터를 "정리해서" 저장하기
가장 익숙한 방식은
데이터를 정해진 구조 안에서 관리하는 방식이다.
데이터를 정해진 구조 안에 넣어서 관리하는 방식이다.
이 방식이 바로 관계형 데이터베이스(RDBMS)이며,
대표적으로 이번 초급 프로젝트에서 채택했던 PostgreSQL, MySQL이 있다.
선 구조 후 데이터
관계형 데이터베이스는 흐름이 비교적 명확하다.
- 테이블 구조를 먼저 정의
- 정의된 구조에 맞게 데이터 저장
예를 들어
- 사용자 테이블
- 습관 테이블
- 기록 테이블
처럼 데이터를 역할별로 나누고,
각 테이블을 관계로 연결해서 관리한다.
장점
관계형 데이터베이스의 가장 큰 특징은
데이터의 정확성과 일관성을 유지하기 쉽다는 점이다.
예를 들어
- 존재하지 않는 사용자에 대한 기록 생성
- 잘못된 타입의 데이터 입력
- 관계가 맞지 않는 데이터 저장
같은 문제들을 데이터베이스 단계에서 방지할 수 있다.
즉, 데이터 구조를 엄격하게 관리하는 대신
안정성을 높이는 방식이라고 볼 수 있다.
단점
다만 구조를 엄격하게 관리하는 만큼
설계와 관리가 상대적으로 복잡해진다.
테이블을 나누고,
관계를 연결하고,
여러 데이터를 함께 고려해야 하기 때문이다.
그래서 데이터를 저장하거나 수정하는 과정이
비교적 무겁게 느껴질 수 있다.
데이터를 "묶어서" 저장하기
반대로 데이터를 하나의 문서처럼 저장하는 방식도 존재한다.
이 방식이 바로 문서형 데이터베이스이며,
대표적으로 MongoDB 가 있다.
선 데이터 후 구조
문서형 데이터베이스는 관계형 데이터베이스보다 훨씬 유연하다.
예를 들면 아래처럼 JSON 형태에 가까운 구조 자체를 그대로 저장할 수 있다.
{
"user": "명곤",
"habits": [{ "name": "공부", "done": false }]
}하나의 문서 안에 필요한 데이터를 함께 넣어서 관리하는 방식이다.
장점
문서형 데이터베이스는
구조를 엄격하게 미리 정의하지 않아도 된다는 특징이 있다.
그래서
- 빠르게 개발 가능
- 구조 변경에 유연함
- 데이터를 한 번에 저장 가능
같은 장점을 가진다.
특히 데이터 구조가 자주 바뀌거나
빠른 개발 속도가 중요한 서비스에서 자주 사용된다.
단점
다만 유연한 만큼
데이터 관리 책임이 개발자 쪽으로 많이 넘어온다.
관계형 데이터베이스처럼
강하게 관계를 검증하지 않기 때문에
- 데이터 중복
- 일관성 문제
- 복잡한 관계 관리 어려움
같은 문제가 발생하기 쉽다.
특히 규모가 커질수록
같은 데이터가 여러 곳에 퍼지면서
어떤 값이 실제 기준 데이터인지 헷갈리는 상황도 생길 수 있다.
SQL vs MongoDB
MongoDB와 SQL 계열 데이터베이스를 비교할 때 자주 나오는 말이 있다.
MongoDB는 쓰기가 빠르고, SQL은 느리다.
하지만 이 표현은 조금 단순화된 이야기라고 한다.
관계형 데이터베이스는 데이터를 저장할 때
- 관계 확인
- 데이터 검증
- 제약 조건 검사
등을 함께 수행한다.
반면 문서형 데이터베이스는
상대적으로 자유로운 구조 안에서 데이터를 저장한다.
그래서 체감상 문서형 데이터베이스가 더 가볍고 빠르게 느껴질 수 있는 것이다.
MongoDB가 무조건 더 뛰어난 성능을 가진다기보다는
저장 방식 자체가 다르기 때문에 체감 차이가 발생하는 것에 가깝다.
결국 중요한 건
어떤 데이터와 어떤 서비스 구조에 더 잘 맞느냐이다.
3. 속도를 위해 태어난 데이터베이스
앞에서 본 관계형 데이터베이스와 문서형 데이터베이스는
결국 데이터를 저장하고 관리하는 것이 핵심 목적이었다.
- 관계형 데이터베이스 → 구조를 나눠서 저장
- 문서형 데이터베이스 → 데이터를 묶어서 저장
그런데 서비스 규모가 커지면
단순히 “저장”만 잘한다고 끝나지 않는다.
예를 들어 서비스에서는 아래 같은 요청이 정말 자주 발생한다.
- 로그인 상태 확인
- 오늘의 습관 조회
- 토글 상태 확인
- 자주 조회되는 데이터 불러오기
이런 요청마다 매번 메인 데이터베이스에 접근하게 되면
점점 성능 부담이 커지기 시작한다.
그래서 등장한 방식이 바로
데이터를 엄청 빠르게 꺼내는 데 집중한 데이터베이스
로, 대표적으로 Redis가 있다.
Key-Value 방식
이 방식은 구조 자체가 굉장히 단순하다.
key → value예를 들면
- user:1 → 명곤
- habit:3 → false
처럼 key 하나에 value 하나를 연결해서 저장한다.
구조가 극단적으로 단순한 이유는 하나다.
오직 속도를 위해서다.
어떻게 이런 속도가?
핵심은 크게 두 가지다.
1. 메모리 기잔 저장
일반적인 관계형 데이터베이스는
주로 디스크 기반으로 데이터를 저장한다.
반면 Redis는 데이터를 메모리(RAM)에 저장한다.
- 디스크 → 상대적으로 느림
- 메모리 → 매우 빠름
즉, 물리적인 접근 속도 자체에서 차이가 발생한다.
2. 구조 자체가 단순함
Redis는 복잡한 관계를 거의 고려하지 않는다.
- 조인 없음
- 관계 관리 없음
- 복잡한 쿼리 최소화
그냥 key 하나로 바로 데이터를 찾는다.
“빠르게 찾기”에만 집중한 구조인 것인데, 어떻게 느릴 수 있겠는가 ...
빠른 속도가 필요한 사용처
중요한 건 Redis가 보통 메인 데이터베이스 역할을 하지는 않는다는 점이다.
대신 아래 같은 곳에서 많이 사용된다.
- 로그인 세션 저장
- 캐시(Cache) 저장
- 조회 결과 임시 저장
- 실시간 데이터 처리
예를 들어 오늘의 습관 조회 결과를 Redis에 저장해두면,
- 첫 요청 → 메인 DB 조회
- 조회 결과를 Redis에 저장
- 다음 요청 → Redis에서 바로 반환
처럼 동작할 수 있다.
즉, 매번 데이터베이스를 조회하지 않아도 되기 때문에
서비스 속도가 훨씬 빨라질 수 있다.
실제로 서비스 고도화 과정에서
캐시 전략으로 자주 고려되는 방식이라고 한다.
단점
물론 빠르다고 해서 모든 상황에 적합한 건 아니다.
Redis 같은 Key-Value 방식은
- 데이터 유실 가능성
- 복잡한 관계 표현 어려움
- 데이터 일관성 관리 한계
같은 단점이 존재한다.
그래서 보통은
메인 데이터베이스를 보조하는 역할
로 많이 사용된다.
4. 관계를 저장하는 데이터베이스
앞에서 다룬 관계형 데이터베이스는
테이블을 나누고, 관계를 연결한 뒤 필요한 순간에 JOIN으로 데이터를 가져오는 방식으로,
관계를 간접적으로 표현하는 구조에 가깝다.
그런데 세상에는 관계 자체가 핵심인 데이터들도 존재한다.
예를 들면
- 친구의 친구 추천
- 팔로우 관계
- 추천 시스템
- 네트워크 분석
같은 경우들이다.
이런 데이터들은 연결이 계속 늘어나고,
관계 구조도 점점 복잡해진다.
관계형 데이터베이스의 한계
관계형 데이터베이스에서도 이런 구조를 구현할 수는 있다.
다만 관계가 많아질수록
- 테이블 수 증가
- JOIN 증가
- 쿼리 복잡도 증가
같은 문제가 발생하기 시작한다.
특히 “연결을 따라가며 탐색”하는 작업이 많아질수록
성능과 관리 복잡도가 함께 커질 수 있다.
그래서 등장한 방식이 바로
관계 자체를 중심으로 저장하는 데이터베이스
이다.
대표적으로 Neo4j 가 있다.
그래프 데이터베이스
그래프 데이터베이스는 데이터를 아래처럼 표현한다.
- 노드(Node) → 데이터
- 엣지(Edge) → 관계
여기서 중요한 건
관계 자체가 하나의 핵심 데이터로 다뤄진다는 점
이다.
예를 들어 관계형 데이터베이스에서는
- 유저 테이블
- 팔로우 테이블
처럼 관계를 별도 테이블로 관리한다.
반면 그래프 데이터베이스는 연결 자체가 구조가 된다.
A --- 친구 --- B
|
팔로우
|
C“누가 누구와 연결되어 있는가”
를 굉장히 자연스럽게 표현하는 방식으로 볼 수 있다.
장점
그래프 데이터베이스의 가장 큰 장점은
관계 탐색에 특화되어 있다는 점이다.
예를 들어
“A의 친구의 친구 찾기”
같은 작업을 수행한다고 하면,
관계형 데이터베이스에서는
- 여러 JOIN 수행
- 복잡한 쿼리 작성
- 관계 깊어질수록 성능 부담 증가
같은 문제가 생길 수 있다.
반면 그래프 데이터베이스는
- 연결된 노드 따라가기
방식으로 탐색이 가능하다.
관계를 따라 이동하는 작업 자체에 최적화된 구조인 것이다.
관계 탐색이 필요한 사용처
그래프 데이터베이스는 보통
- 친구 추천 시스템(SNS)
- 콘텐츠 추천 알고리즘
- 네트워크 분석
- 경로 탐색
처럼 “연결 관계”가 핵심인 서비스에서 많이 사용된다.
단점
다만 모든 상황에서 좋은 건 아니다.
그래프 데이터베이스는
- 일반적인 CRUD 작업에는 비효율적일 수 있고
- 단순 데이터 저장에는 과한 구조가 될 수 있으며
- 학습 난이도와 설계 난이도가 높은 편
이라는 특징도 존재한다.
그래서 보통은
관계 탐색이 핵심인 특정 문제를 해결하기 위해 사용하는 데이터베이스
라고 볼 수 있다.
5. 데이터를 분석하기 위한 데이터베이스
앞에서 살펴본 데이터베이스들은 공통적으로
서비스를 운영하기 위한 데이터 저장
에 초점이 맞춰져 있었다.
예를 들면
- 사용자 정보 저장
- 습관 데이터 저장
- 로그인 상태 관리
같은 작업들이다.
그런데 서비스 규모가 커지면
단순히 데이터를 저장하는 것을 넘어
데이터를 분석하려는 요구가 생기기 시작한다.
예를 들어
- “유저들이 어떤 기능을 가장 많이 사용할까?”
- “하루 평균 습관 완료율은 얼마일까?”
- “이번 주 활동량은 지난주보다 늘었을까?”
같은 질문들이다.
데이터를 저장하는 것을 넘어
데이터를 통해 흐름과 패턴을 분석하려는 단계로 넘어가는 것이다.
운영 데이터베이스로 분석하면?
물론 기존의 PostgreSQL 같은 관계형 데이터베이스에서도 분석 자체는 가능하다.
하지만 데이터 규모가 커질수록
- JOIN 증가
- 복잡한 집계 쿼리 증가
- 대량 데이터 조회 발생
같은 문제가 생기기 쉽다.
그리고 운영 중인 데이터베이스에서
무거운 분석 작업까지 함께 수행하면
실제 서비스 성능에도 영향을 줄 수 있다.
그래서 대규모 서비스에서는 종종
운영용 데이터베이스와 분석용 데이터베이스를 분리
해서 사용하기도 한다.
컬럼 기반으로 저장하는 방식
이런 분석 작업에 특화된 방식 중 하나가 바로
컬럼형(Column-oriented) 데이터베이스
이다.
대표적으로 Apache Cassandra 같은 계열이 자주 언급된다.
기존 데이터베이스와의 차이점
기존 관계형 데이터베이스는 보통 행(Row) 단위로 저장된다.
id | name | age | habit즉, 한 줄 안에 하나의 데이터 정보가 모두 들어간다.
반면 컬럼형 데이터베이스는
같은 컬럼끼리 묶어서 저장한다.
id → [1, 2, 3]
name → [A, B, C]
age → [20, 25, 30]같은 종류의 데이터들을 연속적으로 저장하는 구조인 것이다.
장점
이 방식은 특정 데이터만 대량으로 분석할 때 굉장히 강력하다.
예를 들어
“전체 유저 평균 나이 계산” 같은 작업을 수행한다고 하면,
행 기반 저장에서는
모든 row를 읽으면서 필요한 데이터를 꺼내야 한다.
반면 컬럼형 데이터베이스는
age 컬럼만 읽기만 하면 된다.
분석에 필요한 데이터만 빠르게 가져올 수 있기 때문에
대규모 집계와 통계 작업에 정말 유리하다.
분석이 필요한 사용처
이런 데이터베이스는 보통
- 로그 분석
- 통계 처리
- 데이터 시각화
- BI(Business Intelligence)
- 대규모 집계 시스템
같은 분야에서 사용된다.
서비스 기능 자체보다는
데이터를 기반으로 의사결정을 내리기 위한 영역에서 많이 활용된다.
단점
물론 일반 서비스 운영에는 잘 맞지 않는 부분도 존재한다.
- 실시간 CRUD 작업에는 상대적으로 약하고
- 일반적인 서비스 구조와는 사용 방식이 다르며
- 데이터 수정이 잦은 환경에는 비효율적일 수 있다.
그래서 운영 DB랑 분리해서 사용해야 한다.
