관계형 데이터베이스와 NoSQL — 무엇을 고르고, 무엇을 기준으로 고르는가

"어떤 DB를 쓸까"라는 질문에 "Redis가 빠르다" 또는 "MongoDB가 유연하다"로 답하면 절반만 답한 것이다. 제품의 성능은 선택 근거로 충분하지 않다. 조직을 실제로 무너뜨리는 쪽은 성능이 아니라 유지·보수 비용이기 때문이다.

이 글은 저장소를 고르기 전에 정리해야 할 것들을 다룬다. 관계형 모델이 "관계"를 물리적으로 어디에 저장하는지, NoSQL 네 유형이 각각 무엇을 잘하고 무엇을 못하는지, 그리고 제품 선택을 성능이 아니라 문제 해결·비용·유지·보수 세 축으로 판정하는 이유다. 저장소를 새로 고르는 자리에 있거나, 이미 쓰고 있는 저장소가 왜 그 자리에 있는지 설명해야 하는 백엔드 엔지니어를 위한 글이다.

이 시리즈의 구성

데이터베이스 기초는 "데이터를 어떻게 담고(모델링) → 어떻게 꺼내고(SQL) → 어떻게 동시에 안전하게 다룰 것인가(트랜잭션)" 라는 하나의 축을 따라간다. 이 축을 다섯 구간으로 끊어 한 편씩 맡겼다. 어느 편부터 펼쳐도 읽히도록 썼고, 시리즈 전체가 쓰는 용어 정의는 이 글이 갖는다.

용어 정리

약어가 어느 층의 이야기인지 모르면 같은 문서 안에서도 길을 잃는다. 이 시리즈가 쓰는 용어 29개를 주제별로 네 묶음(7 · 4 · 9 · 9)에 전수 배정했다. 묶는 방식은 이 글의 정리다.

개요 층 — 7개

모델링 층 — 4개

SQL 층 — 9개

트랜잭션 층 — 9개

이 시리즈가 따라가는 축

비즈니스 요구사항이 하나의 파이프라인을 거쳐 서비스가 된다. 각 편이 이 파이프라인의 어느 구간을 맡는지 먼저 보면 길을 잃지 않는다.

이 파이프라인의 각 구간에는 고유한 실패 방식이 있고, 그 실패를 막는 해법도 구간마다 다르다. 층별로 짝지어 배열한 것은 이 글의 정리다.

세 행의 해법 열을 나란히 읽으면 성격이 갈린다. 세 행 모두 교환 조건을 담지만 더 나은 쪽이 있느냐가 다르다. 모델링과 SQL에는 기본값이 있다 — 중복은 제거하는 쪽에서 출발하고, 실행계획은 재사용하는 쪽에서 출발한다. 언제 그 기본값을 되돌릴지가 판단이고, 반정규화와 인덱스 추가가 그 자리다. 격리수준에는 그런 더 나은 쪽이 없다. 올리면 일관성이 오르고 동시성이 떨어질 뿐이어서, 원 자료도 이 행에만 "이 트레이드오프를 의식적으로 선택하는 것이 설계" 라고 적었다.

데이터베이스와 DBMS — 무엇이 무엇인가

용어 네 개의 관계부터 못박고 시작한다. 일상에서 뭉뚱그려 쓰이지만 층이 다르다.

핵심은 첫 두 행의 차이다. 데이터베이스는 데이터이고 DBMS는 소프트웨어다. "MySQL을 쓴다"는 말은 DBMS 층의 이야기이고, "회원 DB"라는 말은 데이터 층의 이야기다. 그 아래 두 행 RDBMS와 NoSQL은 DBMS를 저장 구조를 기준으로 가른 것이지, 서로 다른 계층이 아니다.

역사 — 저장에서 관계로, 유연성으로, 분산으로

데이터베이스 역사는 "저장 → 관계 정립 → 유연성 확보 → 분산" 순으로 움직였다. 지금 고르는 선택지들이 각각 어떤 문제에 대한 답으로 태어났는지가 이 흐름에 들어 있다.

마지막 행의 단서가 이 표에서 가장 중요하다. NoSQL이 나온 뒤에도 RDBMS 영역은 여전히 확고하다. 새 선택지는 기존 선택지를 대체한 것이 아니라 기존 선택지가 못 풀던 문제를 가져간 것이고, 그래서 오늘날의 선택은 "무엇이 최신인가"가 아니라 "이 문제가 어느 쪽 것인가"가 된다. NewSQL이 이 표의 마지막 행에 올라온 것도 같은 맥락이다 — 트랜잭션 보장과 확장성 중 하나를 포기하고 싶지 않은 자리가 남아 있다는 뜻이다.

뒷이야기: 커드 박사는 관계형 모델 논문 발표 후 정작 IBM 내부에서 배척당했고, 그 논문에서 영감을 얻은 래리 엘리슨이 오라클을 만들었다.

정규형 BCNF의 "C"가 바로 Codd다. 이름 하나에 이 계보가 통째로 들어 있다.

RDBMS — "관계"는 어디에 저장되는가

관계형 모델을 이해했는지 가르는 질문은 하나다. 도서관 시스템의 "작가는 도서를 집필한다"를 개체-관계로 옮기면 아래처럼 된다.

"집필이라는 관계는 어디에 저장되는가?" — 이 질문이 RDBMS의 핵심이다. 답은 book 테이블의 FK 컬럼(AUTHOR_ID) 이다. 관계는 별도 객체가 아니라 외래키 값으로 물리적으로 구현된다.

도식에서 화살표로 그려진 "집필 1:M"은 저장 구조에 존재하지 않는다. 존재하는 것은 book 행마다 들어 있는 AUTHOR_ID 값 하나뿐이다. 관계가 값이라는 사실에서 관계형 모델의 성질이 거의 다 따라 나온다 — 관계를 검사하는 일이 곧 값을 검사하는 일이므로 무결성 제약이 성립하고, 관계를 따라가는 일이 곧 값을 맞춰 보는 일이므로 조인이 필요하며, 관계가 깊어질수록 조인이 쌓여 비용이 는다.

테이블을 구성하는 요소는 다음과 같다.

(4)와 (6)을 붙여 읽어야 한다. PK는 NULL을 허용하지 않는데 NULL은 0도 공백도 아닌 "값 없음"이다. 이 둘을 함께 두면 왜 PK에 NULL이 불가능한지가 정의에서 바로 나온다 — 식별이란 값을 비교하는 일이고, "값 없음"끼리는 비교가 성립하지 않는다.

NoSQL 네 유형

NoSQL은 하나의 제품군이 아니다. 저장 구조가 서로 다른 네 계열의 총칭이고, 계열이 다르면 잘하는 일도 다르다.

이 표는 세로가 아니라 가로로 읽어야 한다. 강점 열만 훑으면 네 유형이 전부 좋아 보이는데, 각 행의 강점과 약점은 같은 설계 결정의 양면이기 때문이다. Key-Value가 빠른 것과 복잡한 쿼리에 불리한 것은 둘 다 "구조가 단순해서"이고, Column-oriented가 압축이 잘 되는 것과 단건 조회에 불리한 것은 둘 다 "컬럼 단위로 직렬화해서"다.

Graph 계열은 앞의 세 계열과 성격이 조금 다르다. Key-Value·Column·Document가 RDBMS의 관계 제약을 덜어내는 방향이라면, Graph는 반대로 관계를 일급 저장 대상으로 끌어올린다. 앞에서 본 대로 RDBMS에서 관계는 FK 값이고 따라가려면 조인이 필요한데, Graph DB는 관계 자체에 저장 구조를 부여해 순회 비용을 낮춘다. "NoSQL은 관계를 안 쓴다"는 요약이 틀리는 지점이 여기다.

DBMS를 고르는 세 기준

선택 기준은 "문제 해결 / 비용 / 유지·보수" 세 가지다. 이 세 기준이 각각 어떤 질문인지 풀어 두면 실제 회의에서 쓸 수 있다. 질문 형태로 편 것은 이 글의 정리다.

첫 기준에 답하려면 유형별로 어떤 영역이 자리 잡았는지를 알아야 한다.

금융과 공공이 관계형에 남아 있는 이유는 그쪽이 보수적이어서가 아니라, 무결성과 트랜잭션 안전성을 포기할 수 없는 도메인이기 때문이다.

왜 성능이 아니라 이 세 기준인가.

"이 제품이 성능이 좋다"는 선택 근거가 되지 못한다.

실제로 조직을 무너뜨리는 것은 유지·보수 비용이다. 운영 인력이 다룰 줄 모르는 DBMS는 장애 시 복구 시간이 곧 서비스 정지 시간이 된다.

마지막 문장은 다시 읽을 값어치가 있다. 복구 시간이 서비스 정지 시간과 같아진다는 말은, 제품을 고른 시점의 판단이 몇 년 뒤 장애 대응 속도로 청구된다는 뜻이다. 도입 시점에 보이는 것은 벤치마크 수치이고 청구서는 장애가 났을 때 날아온다. "왜 그 DB를 골랐나"에 성능만으로 답하는 것이 부족한 이유가 여기 있다.

정리

이 글이 정리한 것을 세 줄로 압축하면 이렇다.

저장소를 골랐다면 다음 질문은 "그 안에 데이터를 어떤 구조로 담을 것인가"다. 관계를 FK로 저장한다는 사실은 곧 어떤 테이블을 만들고 어디에 FK를 둘 것인가라는 설계 문제로 이어진다. 여기서 중복을 어디까지 제거할지, 언제 다시 되돌릴지를 정하는 것이 모델링과 정규화이고, 다음 편이 그 주제를 받는다.