뒤끝터디 2주차 – 데이터 모델과 질의 언어
1. 들어가며
이번 챕터에서는 데이터 모델과 질의 언어에 대해 다룬다.
사실 평소에 개발을 하며 데이터베이스 구조에 대해 깊게 고민할 기회가 많지는 않다.
MSSQL을 중심으로 정형화된 모델만 사용해 온 입장에서, 이번 장은 모델링과 시스템 설계 전반을 다시 생각해보게 하는 내용이었다.
관계형 모델의 태생적 한계와 이를 보완하기 위해 등장한 다양한 비관계형 DB의 목적, 그리고 각각의 데이터 모델이 사용되는 맥락에 대해 살펴볼 수 있었다.
2. New – 새롭게 알게 된 개념 정리
2-1. 계층 구조로 쌓이는 데이터 모델
대부분의 애플리케이션은 데이터 모델이 단일 계층이 아니라 여러 계층 위에 얹힌 구조다.
예를 들어 도메인 객체 → JSON → 관계형 테이블처럼 여러 표현 방식이 존재하며,
이러한 계층 간의 전환이 중요한 이슈가 된다고 설명한다.
각 계층마다 하위 관점에서 상위 데이터를 어떻게 표현하고 매핑하느냐가 설계 포인트다.
2-2. NoSQL의 등장 배경
NoSQL은 단순히 ‘SQL을 쓰지 않는다’기보다는 ‘SQL만 고집하지 않는다(Not Only SQL)’라는 의미에 가깝다.
책에서는 NoSQL이 등장하게 된 이유를 아래와 같이 정리하고 있다.
- 매우 큰 데이터셋을 다루거나 높은 쓰기 처리량이 필요할 때 확장성이 더 뛰어남
- 상용 관계형 DB의 높은 라이선스 비용에 비해, 오픈소스 도입을 선호하는 흐름
- 관계형 모델이 표현하기 어려운 질의 요구사항 존재
- 고정된 스키마 구조에 대한 불만 → 유연하고 동적인 스키마 요구
결국 현실적인 문제에서 출발한 해결책이라는 점에서, 비즈니스와 맞닿아 있는 기술이라 느껴졌다.
2-3. 다중 저장소 지속성 (Polyglot Persistence)
이 개념은 처음 알게 되었는데, 이미 실무에서는 무의식 중에 사용하고 있었다.
사용자 정보는 MSSQL, 로그는 MongoDB, 캐시는 Redis처럼
하나의 시스템에 서로 다른 특성을 가진 DB를 병렬적으로 사용하는 것을 의미한다.
각 데이터 모델의 강점을 조합하는 방식으로 이해할 수 있다.
2-4. 문서형 vs 그래프형 데이터베이스
- 문서형(Document): 각 문서가 독립적이며, 문서 간 연관이 거의 없는 경우에 적합. 예: 주문 내역, 게시글
- 그래프형(Graph): 모든 데이터 간 연결이 중요할 때 적합. 예: 소셜 관계망, 추천 시스템
데이터의 연관성 정도에 따라 데이터 모델이 달라질 수 있다는 점이 실무에서도 도움이 될 만한 기준이었다.
2-5. 트리플 저장소 / SPARQL
지식 그래프나 의미론적 웹에서 사용하는 RDF 기반의 데이터 저장소.
SPARQL은 이를 질의하는 언어로, 일반적인 CRUD와는 다소 결이 다르다.
이 챕터에서는 간단한 용도만 소개되며, 깊은 이해보다는 개념 위주의 정리였다.
3. Difficulty – 명확하게 이해되지 않았던 부분
3-1. 임피던스 불일치 (Impedance Mismatch)
객체지향 시스템과 관계형 데이터베이스 모델 간의 간극을 설명하는 용어다.
예를 들어, User 객체 내부에 Address 클래스가 포함되어 있다면
RDB에서는 이걸 별도 테이블로 나눠 외래키로 연결해야 한다.
그 과정에서 데이터 표현 방식과 흐름이 자연스럽지 않게 되며, 이 전환 자체가 개발자에게 부담이 된다.
ORM이 존재하는 이유이기도 하다.
아직도 이 개념이 정확히 “어디까지를 임피던스 불일치라 부르나?”에 대해선 감이 확 오진 않았다.
하지만 객체지향과 RDB의 구조적 차이를 표현하는 용어로는 적절하다는 생각이다.
3-2. 트리 구조 → 관계형 모델의 역사
초기에는 계층적 트리 모델로 데이터를 표현했지만, 다대다 관계 표현이 어렵고 유연성이 떨어졌다.
이를 해결하기 위해 관계형 모델이 등장했다는 설명이 있었는데, 이 흐름을 시간 순으로 정리하면 다음과 같다.
- 트리 구조 모델: 단방향 계층 관계 표현에는 적합하지만 유연성이 부족
- 관계형 모델: 모든 데이터를 릴레이션으로 추상화 → 조인을 통한 유연한 질의 가능
- 비관계형 모델: 관계형이 해결하지 못하는 성능/확장성/표현력 문제를 해결하기 위해 등장
이 관점은 단순한 기술 비교를 넘어, 시스템 아키텍처 설계의 배경 논리를 제공한다.
4. 각 데이터 모델별 특성 정리
구분 관계형 DB (MSSQL) 비관계형 DB (MongoDB)
| 구조 | 고정된 스키마 | 유연한 JSON 기반 문서 구조 |
| 트랜잭션 | 강력한 ACID 지원 | 트랜잭션보다는 가용성과 속도 중시 |
| 확장성 | 수직 확장 중심 | 수평 확장에 유리 |
| 장점 | 복잡한 조인 가능, 성숙한 툴 생태계 | 빠른 쓰기, 자유로운 구조, 유연한 개발 |
| 단점 | 구조 변경이 번거롭고 유연성 떨어짐 | 조인 연산이 약하고 관계 표현이 제한적 |
5. 마무리
이번 챕터는 단순한 CRUD 중심의 사고에서 벗어나,
“왜 이 모델을 쓰는가”, “우리 서비스는 어떤 데이터 구조가 맞는가” 같은 질문을 던지게 만든다.
데이터베이스 선택은 결국 기술이 아니라 요구사항에서 출발한다는 점에서
각 모델의 배경과 쓰임새를 알아두는 게 꽤 중요하다는 생각이 들었다.