SQL과 NOSQL의 차이

웹 앱을 개발할 때, 데이터베이스를 선택할 때 고민하게 된다.

MySQL과 같은 SQL을 사용할까? 아니면 MongoDB와 같은 NoSQL을 사용할까?

중요한 것은 프레임워크가 아니라 데이터 구조, 조회 패턴, 일관성 요구사항, 확장 방식이다. 프로젝트를 진행하기 전에 적합한 데이터베이스를 선택해야 한다.

SQL (관계형 DB)

---

SQL을 사용하면 RDBMS에서 데이터를 저장, 수정, 삭제 및 검색 할 수 있음

관계형 데이터베이스에는 핵심적인 두 가지 특징이 있다.

• 데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
• 데이터는 관계를 통해 여러 테이블에 분산된다.

데이터는 테이블에 레코드로 저장되는데, 각 테이블마다 명확하게 정의된 구조가 있다. 해당 구조는 필드의 이름과 데이터 유형으로 정의된다.

따라서 스키마를 준수하지 않은 레코드는 테이블에 추가할 수 없다. 즉, 스키마를 수정하지 않는 이상은 정해진 구조에 맞는 레코드만 추가가 가능한 것이 관계형 데이터베이스의 특징 중 하나다.

또한, 데이터의 중복을 피하기 위해 '관계'를 이용한다.

하나의 테이블에서 중복 없이 하나의 데이터만을 관리하기 때문에 다른 테이블에서 부정확한 데이터를 다룰 위험이 없어지는 장점이 있다.

NoSQL (비관계형 DB)

---

NoSQL은 "비관계형 데이터베이스 전체"를 묶어 부르는 큰 범주다.

문서형, 키-값형, 컬럼 패밀리형, 그래프형 등 종류가 다양하며, 공통점은 관계형 모델 하나에만 묶이지 않는다는 점이다.

문서형 NoSQL에서는 레코드를 문서(document)라고 부른다.

SQL은 스키마가 엄격한 편이고, NoSQL은 스키마가 더 유연한 편이다. 다만 NoSQL도 스키마 검증(schema validation)이나 애플리케이션 레벨 규칙을 둘 수 있으므로 "완전히 스키마가 없다"고 보는 것은 부정확하다.

문서(document)는 JSON과 비슷한 형태를 많이 사용한다. 관계형 데이터베이스처럼 여러 테이블에 정규화해 저장하기보다, 함께 조회되는 데이터를 하나의 문서에 묶어 저장하는 경우가 많다.

따라서 RDBMS에서 Orders, Users, Products로 나누던 정보를, 문서형 NoSQL에서는 조회 패턴에 따라 하나의 문서에 중첩해 저장할 수 있다.

이 방식은 조인을 줄이는 데 유리하다. 다만 "NoSQL에는 조인이 없다"라고 단정할 수는 없다. 예를 들어 MongoDB의 $lookup처럼 조인 유사 기능을 제공하는 제품도 있다.

그러면 관계가 필요할 때 NoSQL은 어떻게 할까?

문서에 데이터를 중첩하거나, 필요한 일부 데이터를 비정규화(denormalization)하여 중복 저장하는 방식을 자주 사용한다.

하지만 이러면 데이터 중복과 동기화 비용이 늘어날 수 있다. 따라서 쓰기 일관성보다 읽기 패턴 최적화와 유연한 모델링이 더 중요한 경우에 잘 맞는다.

확장 개념

두 데이터베이스를 비교할 때 중요한 Scaling 개념도 존재한다.

데이터베이스 서버의 확장성은 '수직적' 확장과 '수평적' 확장으로 나누어진다.

• 수직적 확장 : 단순히 데이터베이스 서버의 성능을 향상시키는 것 (ex. CPU 업그레이드)
• 수평적 확장 : 더 많은 서버가 추가되고 데이터베이스가 전체적으로 분산됨을 의미 (하나의 데이터베이스에서 작동하지만 여러 호스트에서 작동)

전통적인 단일 노드 RDBMS는 수직 확장이 상대적으로 단순했고, 많은 NoSQL 시스템은 처음부터 샤딩/분산을 염두에 두고 설계되었다.

다만 SQL 데이터베이스도 샤딩, 파티셔닝, 읽기 복제본, 분산 SQL 등을 통해 수평 확장이 가능하다. 따라서 "SQL은 수평 확장이 안 된다"는 표현은 과도한 단순화다.

그럼 둘 중에 뭘 선택?

정답은 없다. 둘다 훌륭한 솔루션이고 어떤 데이터를 다루느냐에 따라 선택을 고려해야한다.

SQL 장점

• 명확하게 정의된 스키마, 강한 제약조건과 데이터 무결성 관리에 유리
• 관계는 각 데이터를 중복없이 한번만 저장

SQL 단점

• 스키마 변경 비용이 상대적으로 크고, 초기에 모델링을 더 신중히 해야 함
• 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
• 분산 설계가 가능하더라도 운영 복잡도가 커질 수 있음

NoSQL 장점

• 스키마가 유연해 변화하는 요구사항에 대응하기 쉬움
• 조회 패턴에 맞게 데이터를 한 번에 읽도록 모델링하기 쉬움
• 많은 제품이 샤딩/복제를 전제로 확장 전략을 제공함

NoSQL 단점

• 유연성 때문에 데이터 구조가 느슨해질 수 있음
• 비정규화로 인해 데이터 중복과 동기화 비용이 커질 수 있음
• 제품별 기능 차이가 커서, 트랜잭션/쿼리/인덱스 지원 범위를 개별적으로 확인해야 함

SQL 데이터베이스 사용이 더 좋을 때

• 관계를 맺은 데이터가 자주 변경되고, 트랜잭션 일관성이 중요한 경우

  정규화와 조인, 제약조건으로 데이터를 일관되게 관리하기 좋다.

• 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우

NoSQL 데이터베이스 사용이 더 좋을 때

• 정확한 데이터 구조가 자주 바뀌거나 빠르게 확장될 수 있는 경우
• 조회 패턴에 맞춘 문서 단위 응답이 중요한 경우
• 대규모 분산 환경에서 샤딩 친화적인 모델이 필요한 경우

하나의 제시 방법이지 완전한 정답이 정해져 있는 것은 아니다.

SQL을 선택해서 복잡한 JOIN문을 만들지 않도록 설계하여 단점을 없앨 수도 있고

NoSQL을 선택해서 중복 데이터를 줄이는 방법으로 설계해서 단점을 없앨 수도 있다.