📘 RDB vs NoSQL

데이터베이스(Database)가 정확히 뭘까?

단순히 “데이터를 저장하는 곳”이라고 하기에는 너무 추상적이다.

데이터베이스는 데이터를 구조적으로 저장하고, 관리하며, 필요할 때 효율적으로 조회할 수 있도록 만든 시스템이다.

여기서 중요한 포인트는 “저장”이 아니라 데이터를 구조적으로 관리하고, 효율적으로 꺼내 쓸 수 있다는 점이다.

예를 들어 메모장에 사용자 정보를 이렇게 적어둔다고 가정해보자.

짱구, 28, 서울
철수, 22, 부산

여기서 특정 사람을 찾거나, 나이가 26 이상인 사람만 골라내고 싶으면
하나하나 눈으로 확인해야 하고, 데이터가 많아질수록 거의 불가능에 가까워진다.

반면 데이터베이스는 데이터를 일정한 구조로 저장하고, 조건에 맞게 빠르게 검색하고, 수정, 삭제까지 효율적으로 처리할 수 있다

즉, 단순한 저장소가 아니라 데이터를 다루기 위한 시스템이다.

여기서 자연스럽게 다음 질문이 나온다.

그렇다면 이 데이터를 어떤 방식으로 저장해야 할까?
모든 데이터를 하나의 방식으로만 저장하는 게 최선일까?

이 질문에 대한 대표적인 두 가지 답이 바로 RDB와 NoSQL이다.

RDB (관계형 데이터베이스)

RDB : 데이터를 정해진 구조(스키마)에 맞춰 테이블 형태로 저장하는 데이터베이스

RDB는 Relational Database의 약자로 데이터를 행과 열이 있는 테이블 형태로 저장하는 방식이며, 대표적으로 MySQL, MariaDB, PostgreSQL, SQLite, OracleDB이 있다.

엑셀을 떠올리면 이해하기 쉽다.

id	name	age
1	seungje	28

이처럼 데이터가 일정한 구조를 가지며 저장된다.

RDB는 가장 많이 사용되는 데이터베이스의 유형으로, Schema(스키마)라는 틀에 맞춰 데이터를 저장한다는 특징이 있다.

여기서 스키마란 단순한 형식이 아니라 “어떤 데이터가 들어올지 미리 정의해두는 규칙”이라고 보면 된다.

이해하기 쉽게 맥도날드에 가면 메뉴판이 딱 정해져 있다.
햄버거는 햄버거, 콜라는 콜라, 감자튀김은 감자튀김

근데 갑자기 “불고기버거에 갑자기 김치 넣어주세요” 이런 건 안 된다..
이미 정해진 레시피(스키마)가 있기 때문이다.

실제 코드로 보면 더 명확할거다.

CREATE TABLE users (
user_id BIGINT NOT NULL AUTO_INCREMENT,
point BIGINT DEFAULT 0,
nickname VARCHAR(20),
information VARCHAR(100),
tags VARCHAR(255),
role ENUM(‘NOT_REGISTERED’, ‘USER’, ‘ADMIN’) NOT NULL,
PRIMARY KEY (user_id),
UNIQUE (nickname)
);

처음 보면 굉장히 복잡해 보이는데, 사실 하나씩 뜯어보면 별거 아니다.

이 코드는 한 줄로 정리하면 “users라는 테이블을 만들고, 어떤 데이터만 들어올지 미리 정의한 것”이다.

조금만 나눠서 보면 이해가 훨씬 쉽다.

user_id BIGINT → 숫자로 된 id를 저장한다는 뜻이다.
NOT NULL → 반드시 값이 있어야 한다. (비어있으면 안 됨)
AUTO_INCREMENT → 값이 자동으로 1씩 증가한다. 즉, 회원가입할 때마다 id가 자동으로 붙는다.

point BIGINT DEFAULT 0 → point라는 숫자 필드가 있고, 값을 안 넣으면 기본값이 0으로 들어간다.

nickname VARCHAR(20) → 최대 20글자의 문자열을 저장할 수 있다.

role ENUM(‘NOT_REGISTERED’, ‘USER’, ‘ADMIN’) → 아무 값이나 넣는 게 아니라 정해진 값만 들어갈 수 있다. 즉 USER, ADMIN 같은 값만 가능하고 “SUPER_ADMIN” 같은 건 아예 못 넣는다

마지막으로 제약 조건
PRIMARY KEY (user_id) → 이 테이블에서 user_id는 유일한 기준값이다.

UNIQUE (nickname) → nickname은 중복되면 안 된다.

이걸 한 문장으로 정리하면 “users 테이블에는 이런 형태의 데이터만 넣을 수 있고, 그 규칙을 어기면 아예 저장 자체가 안 된다”

이게 바로 RDB의 핵심이다.
데이터를 넣기 전에 형태 + 규칙 + 제한 조건을 전부 미리 정해둔다.

---

RDB의 강점

RDB “데이터를 엄격하게 관리한다” 이 한마디로 정리할 수 있다.

﹖ ⁇

하나씩 살펴보자.

데이터 무결성 (Data Integrity)

RDB에서 가장 중요한 개념이다. 데이터 무결성이란 데이터가 항상 정확하고, 일관되고, 믿을 수 있는 상태를 유지하는 것을 의미한다.

쉽게 말하면 “데이터가 깨지지 않게 지켜주는 규칙”이다.

예를 들어 회원 테이블에서 user_id가 중복되거나 존재하지 않는 사용자를 참조하는 데이터가 있다면?
-> 아마 그 순간 데이터는 신뢰할 수 없는 상태가 된다.

RDB는 이런 상황을 아예 시스템적으로 막는다.
데이터 무결성은 크게 세 가지로 나뉜다.

• 개체 무결성 (Entity Integrity)
  • 모든 테이블은 기본키(PK)를 가져야 한다
  • PK는 중복될 수 없고, NULL도 허용되지 않는다
  • 각 데이터는 고유하게 식별 가능해야 한다
• 참조 무결성 (Referential Integrity)
  • 외래키(FK)는 반드시 존재하는 데이터를 참조해야 한다
  • 없는 데이터를 가리키는 일은 없다
• 도메인 무결성 (Domain Integrity)
  • 컬럼에 들어갈 값의 타입과 범위를 제한한다
  • 이 컬럼에는 이 값만 들어올 수 있다

즉 RDB는 이상한 데이터가 들어올 가능성 자체를 막는거다.

명확한 데이터 구조 보장

RDB는 데이터를 넣기 전에 반드시 스키마(Schema)를 먼저 정의해야 한다.
이 스키마는 단순한 형식이 아니라 데이터 타입, 길이, 제약 조건을 모두 포함한 데이터 설계도다.

아까 users 테이블에서 규칙을 어기면 아예 저장이 안 된다고했다.

이처럼 RDB는 데이터를 넣는 순간부터 구조를 강제하는데 이게 바로 안전성이 높은 이유이다.

ACID 특성 보장 (트랜잭션)

RDB는 트랜잭션(Transaction)을 통해 ACID 특성을 보장한다. 이에대해서는 다음 글에서 설명을 하도록 하겠다.

핵심만 보면 무슨 일이 있어도 데이터는 정상 상태를 유지한다는 거다.

중간에 오류가 나면 아예 전부 취소하는 등 일부만 저장되는 일 없고, 동시에 여러 요청이 와도 데이터 꼬이지 않는다.

예를들어 계좌 이체 중에 서버가 꺼져도 아예 거래 자체가 없던 일로 돌아가는 것이다.

그래서 은행이나 결제 시스템, 주문 처리같은 곳에서 RDB는 필수이다.

---

RDB의 한계

반대로 생각해보자. 맥도날드처럼 메뉴가 딱 정해져 있으면 안정적이긴 한데 문제가 하나 있다.

“메뉴를 바꾸기 힘들다”

경직된 스키마 (Schema)

RDB는 데이터를 넣기 전에 구조를 먼저 정의해야 한다. 이는 장점도 있지만, 문제는 서비스가 커질수록 요구사항이 계속 바뀐다는 점이다.

예를 들어 갑자기 “프로필 이미지” 추가하거나 “소셜 로그인 정보” 추가하는 상황이 오면 이럴 때마다 컬럼 추가 → 스키마 변경하는 과정이 필요하다. 아직은 괜찮아보이지만, 만약 데이터가 수천만 건이면??

이 작업 자체가 위험하고 무거운 작업이 된다..

JOIN으로 인한 성능 문제

RDB는 데이터 중복을 줄이기 위해 테이블을 나눠서 저장한다. 이걸 정규화라고 한다.

예를들어 users, orders, payments 이렇게 나뉘어 있는데, 한번에 조회하려면?

JOIN을 해야하는데, 문제는 테이블이 많아지거나 데이터 관계가 복잡해지면,,JOIN 비용이 커지고 성능이 떨어진다..

Scale-out이 어려움

트래픽(특정 시간 동안 네트워크나 서버를 통해 전달되는 데이터의 전체 양)이 많아지면 서버를 늘려야 한다.

여기에는 두가지 방법이 있다.

Scale-up → 서버 성능을 올림
Scale-out → 서버를 여러 개로 나눔

RDB는 구조상 Scale-up에는 강하지만, Scale-out에는 상대적으로 불리하다. 데이터의 일관성(ACID)을 유지해야하기 때문이다.

그래서 보통 읽기 전용 복제 DB를 두거나, 일부 트래픽만 분산시키는 방식 을 사용하지만 write가 많아지면 결국 한계가 온다.

즉 RDB는 변화가 많고, 구조가 자주 바뀌고, 확장이 중요한 서비스에서는 한계를 드러내기 시작한다.

그래서 등장한 것이 바로 NoSQL이다.

NoSQL (비관계형 데이터베이스)

RDB의 한게를 보다보면 굳이 데이터를 이정도로 빡세게 관리해야할까싶은 생각이 든다.

서비스가 커지고, 데이터가 다양해지고, 구조가 계속 바뀌는 상황에서는 오히려 이런 규칙이 발목을 잡기 시작하는데, 이 문제를 해결하기 위해 등장한 것이 바로 NoSQL이다.

NoSQL : 고정된 스키마 없이 유연하게 데이터를 저장하는 데이터베이스

NoSQL은 Not Only SQL의 약자로 하나의 특정 DB를 의미하는 것이 아니라 Document (MongoDB), Key-Value (Redis), Graph 같은 다양한 형태의 데이터베이스를 포함하는 개념이다.

RDB가 테이블 구조에 데이터를 맞추는 방식이라면
NoSQL은 데이터를 먼저 만들고, 그에 맞춰 저장하는 방식이다.

예를 들어 MongoDB 같은 Document DB를 보면

{
  "name": "seungje",
  "age": 28,
  "hobby": ["study", "sleep"]
}

이런식으로 데이터를 저장하는데, 여기서 중요한 점은 모든 데이터가 같은 구조일 필요가 없다는거다. 모든 사람이 hobby가 있지는 않지 않은가?

음식점으로 예시를 들면 RDB는 맥도날드지만 NoSQL은 손님이 원하는 대로 만들어주는 커스텀 음식점이라 생각하면 이해하기 쉽다.

---

NoSQL의 강점

유연한 스키마 (Flexible Schema)

RDB에서는 컬럼 추가 → 스키마 변경 → 위험한 작업의 과정을 거쳐야했지만, NoSQL은 정해진 스키마가 없다.

그냥 새로운 형태로 데이터를 넣으면 된다

예를들어

{
  "name": "seungje",
}

{
  "name": "seungje",
  "age": 28,
  "hobby": ["study", "sleep"]
}

이 두 개가 같은 컬렉션에 들어가도 전혀 문제 없다. 구조 변경이 거의 비용 없이 가능하다.

빠른 읽기 성능 (Read Performance)

RDB는 데이터를 나눠서 저장하기 때문에 JOIN이 필요하지만,
NoSQL은 필요한 데이터를 한 번에 같이 저장한다 (중복 허용)

그래서 조회할 시 JOIN 없이 바로 가져올 수 있기에 결과적으로 읽기 성능이 훨씬 빠르다.

Scale-out에 유리

NoSQL은 구조가 단순한데, 데이터를 나눠서 저장할 때도 그냥 범위로 잘라서 서버에 분산하면 된다.

예를 들어 데이터가 100개라면

서버1 → 1~25
서버2 → 26~50
서버3 → 51~75
서버4 → 76~100

이런 식으로 단순하게 분산이 가능하다.

그래서 NoSQL은 대규모 서비스, 트래픽이 많은 시스템 에서 많이 사용된다.

---

NoSQL의 한계

트랜잭션 부족 (ACID 미보장)

RDB는 ACID를 보장하지만, NoSQL은 대부분 트랜잭션을 지원하지 않거나 제한적이다.

즉 일부만 저장되는 상황이나 데이터 불일치 가 발생할 수 있다. (물론 MongoDB 같은 일부 DB는 지원하긴 한다)

데이터 중복으로 인한 update 비용 증가

NoSQL은 데이터를 한 번에 가져오기 위해 중복 저장을 허용한다

문제는 데이터를 수정할 때다 같은 데이터가 여러 곳에 있다면 전부 다 수정해야 한다..

그래서 update 비용이 커질 수 있다.

구조 관리 책임이 개발자에게 있다

RDB는 스키마가 구조를 강제하지만, NoSQL은 아무 제약이 없다.

그래서 데이터 구조를 어떻게 설계할지, 어떻게 저장하고 사용할지 개발자가 직접 고민해야 한다. 이는 데이터를 불러오거나, 구조를 결정할 때 우리에게 많은 불편함을 줄 수 있다..

어떤 DB를 선택해야 할까?

NoSQL이 RDB를 대체하는 것이 아니라 서로 부족한 부분을 보완하는 관계다.

“무조건 좋은 DB”는 없고 “상황에 맞는 DB”만 존재한다.

실제 해외 개발 커뮤니티에서도 “일단 RDB를 먼저 고려하고, 필요하면 NoSQL을 추가하자”는 의견이 많다.

그럼에도 어떤 상황에서 어떤 DB를 사용하는 것이 좋을지 정리해보자면

• RDB
  • 데이터가 절대 틀리면 안 되는 경우 (ex. 결제, 계좌, 주문 시스템)
  • 데이터 간 관계가 중요한 경우 (JOIN이 많이 필요한 경우)
  • 데이터 구조가 명확하고 자주 바뀌지 않는 경우
  • 트랜잭션이 반드시 필요한 경우
  • 수평 확장보다 안정성과 일관성이 더 중요한 경우
• NoSQL
  • 데이터 구조가 계속 바뀌는 경우
  • 어떤 형태의 데이터가 들어올지 명확하지 않은 경우
  • 빠른 개발과 유연성이 중요한 경우
  • 대규모 트래픽을 처리해야 하는 경우
  • 읽기 성능이 중요한 서비스 (ex. SNS, 로그, 추천 시스템)
  • 수평 확장(Scale-out)이 필수적인 경우

정리하면 RDB는 데이터를 정확하게 관리하는 데 강하고, NoSQL은 데이터를 유연하게 처리하는 데 강하다.

결국 중요한건 기술이 아니라 상황이다.