RDB vs NoSQL: 무엇이 더 나을까?

웹 서비스를 만들다 보면 한 번쯤은 고민하게 되는 주제, 바로 데이터베이스 선택입니다.

저는 실무에서 RDB 와 NoSQL 을 모두 사용해봤고, 지금도 상황에 따라 병행해서 쓰고 있습니다.

처음엔 "이게 더 낫다!" 하고 단정 짓고 싶었으나, 시간이 지날수록 그런 결론은 별로 현실적이지 않더라고요.
그래서 오늘은 제가 겪은 경험을 바탕으로 RDB 와 NoSQL 각각의 특징과 장단점, 그리고 실제로 두 개를 어떻게 함께 쓰고 있는지에 대해 공유하려고 합니다. 

---

RDB 의 특징과 장/단점

RDB 는 관계형 데이터베이스라고 불리는 구조예요. 대표적으로 MySQL, PostgreSQL, Orcle 같은 것들이 있죠.

가장 큰 특징은 데이터 간의 관계를 명확하게 정의할 수 있고, 트랜잭션과 정합성 유지에 강하다는 점이예요.

 

예를 들어 유저 테이블과 주문 테이블이 있을 때, 외래 키를 걸어 유저가 삭제되면 주문도 자동으로 삭제되게끔 만들 수 있죠. 

이건 정말 강력한 기능입니다. 

 

장점

• 명확한 스키마 설계로 안정적인 구조 확보
• SQL을 이용한 복잡한 쿼리 가능
• 트랜잭션을 통한 무결성 보장

단점

• 초기에 구조를 설계하는 데 시간이 걸림
• 스키마 변경이 번거롭고 마이그레이션 비용이 큼

---

RDB 가 어울리는 상황 

RDB 는 특히 "정적인 데이터" 에 적합하다고 느꼈어요.

예를 들어 유저 정보, 로그인 기록, 결제 이력 처럼 구조가 잘 변하지 않고 신뢰성이 중요한 데이터에는 RDB 가 적합합니다. 

 

특히 스타트업 초반에 사람 수가 적고, 기술 부채를 최소화하고 싶다면

이런 부분은 RDB 로 관리하는 게 마음이 놓이던 부분이 있습니다. 

---

NoSQL 의 특징과 장/단점

NoSQL 은 스키마가 유연한 비정형 데이터 저장소예요. 대표적으로 MongoDB DynamoDB 등이 있습니다. 

저는 새로운 서비스를 빠르게 실험할 떄 이 NoSQL 이 정말 유용하다고 느꼈어요.

 

왜냐하면 시장 반응에 따라 구조를 바꿔야 할 일이 많고,

이런 상황에서 RDB 는 발목을 잡을 때가 있거든요. 

 

장점

• 스키마 없이 유연하게 데이터 저장 가능
• 빠르게 구조 변경, 확장 가능
• 대용량 데이터를 빠르게 처리

단점

• 데이터 정합성은 개발자가 관리해야 함
• 복잡한 관계형 데이터 모델링이 비교적 어려움

---

NoSQL 이 어울리는 상황

스타트업 초기에 상품 구조가 자주 바뀌는 경우, NoSQL 이 정말 유용했어요.

예를 들어 제가 다루고 있는 전잠담배 액상 제품은 브랜드, 향, 농도, 후기 등 구성 요소가 자주 바뀌고, 추가됩니다. 

 

이런 걸 RDB 로 짜놨으면 매번 스키마 수정하고 마이그레이션 했어야 했죠. 

대신 MongoDB 에 넣고, 필요한 속성을 자유롭게 추가하니 훨씬 생산성이 좋았어요. 

---

함께 쓰는 경우

제 생각에는 결국 가장 안정적인 방식은 RDB 와 NoSQL 을 함께 쓰는 것이였어요. 

 

예를 들어 유저 정보나 로그인 관련 데이터는 RDB 에 저장하고,

상품 정보나 후기처럼 자주 바뀌고 실험적인 데이터는 NoSQL 로 처리했죠. 

 

이때 주의할 점은 두 DB 사이의 관계예요.

예로 들어 리뷰에 유저 ID 를 넣어두긴 했지만, 그건 어디까지나 약속일 뿐 외래키처럼 강제되진 않아요. 

---

RDB 와 NoSQL 을 함께 쓸 때 쓸 수 있는 전략들

실제로 두 시스템을 함께 쓸 땐 아래와 같은 전략을 활용합니다. 

 

1. Application-Level 참조

RDB 에 생성된 ID 를 NoSQL 문서에 저장해서 참조.

실행 전 검증을 API 레벨에서 수행해야 함. 

 

예: 리뷰 생성 시, userId 가 실제로 RDB 에 존재하는 지 확인 후 저장

 

저는 현재 이 방식을 사용하여 웹 애플리케이션을 만들었습니다.

 

이 방식을 통해 어느정도 외래키 역할을 지원 받고 있지만, 여전히 불편한 것들은 있습니다.

예를 들면 특정 로직이 추가 되었을 때, 기본적으로 개발자가 이 부분을 신경쓰지 않으면 데이터 무결성이 깨지게 될수도 있다는 것입니다. 

 

2. 이벤트 기반 정합성 유지

RDB 에서 삭제된 데이터가 있으면, 해당 이벤트를 발생해 NoSQL 에서 관련 문서를 정리.

Kafka, SQS, RabbitMQ 등 메세지 큐 활용

 

3. 백그라운드 정리 워커

주기적으로 두 DB 의 일관성을 확인하는 백엔드 워커를 돌림

예: 존재하지 않는 UserId 를 가진 리뷰는 삭제 처리

 

이 또한 함께 웹 애플리케이션에서 실행되고 있습니다.

 

하지만 데이터의 양이 많아지고 실행되야하는 백엔드 워커가 많아질수록 서비스 부하가 심해지고, 
이는 서비스 비용이나 원활하지 않는 서비스를 제공할 가능성도 생길 수 있습니다. 

 

4. 데이터 중복 허용 (Embedding)

필요한 경우 NoSQL 문세어 RDB 데이터의 일부를 복사해서 저장.

예: 리뷰에 유저 닉네임과 프로필 이미지도 함께 저장

 

> 다만, 수정이 생겨도 자동 반영은 안 되므로 정합성은 일부 포기해야합니다.

---

마무리하며

RDB 와 NoSQL 둘 중 하나만 무조건 옳지 않습니다. 

오히려 각각의 강점을 잘 이해하고 상황에 맞게 쓰는 것이 더 중요하겠더라고요.

 

정적인 데이터는 RDB, 유동적이고 실험적인 데이터는 NoSQL.

그리고 그 둘 사이를 연결해주는 전략들이 결국엔 실무에서 가장 현실적인 해답이었어요.

 

결국, 어떤 기술스택을 쓰냐보다는 "어떤 상황에서는 어떤 기술스택이 더 어울릴까? 를 결정하는 것이

더 중요하다는 것을 알 수 있었습니다.