비즈니스 성격에 맞는 데이터 모델링
모든 데이터는 안전하게 보관되고 가공될 수 있어야 합니다. 그러나 애플리케이션의 성격과 트래픽 양에 따라 데이터를 RDBMS(관계형)로 처리할지, NoSQL(비관계형)로 유연하게 처리할지는 시스템의 아키텍처적 선택에 달려 있습니다.
1. 엄격한 정규화와 ACID 트랜잭션, SQL
MySQL, PostgreSQL, Oracle 등 정통 관계형 데이터베이스는 데이터가 사전에 정의된 고정된 테이블 스키마에 의거하여 저장됩니다. JOIN 연산을 통해 관계를 파악하고, 일관성을 보장하기 위해 강력한 ACID 트랜잭션을 적용합니다.
장점은 은행 거래나 전자상거래 결제 시스템처럼 한 치의 오차나 불일치도 허용되지 않는 금융/비즈니스 논리에 필수적이라는 점입니다. 하지만 스키마 구조 변경이 힘들고, 수평적 확장(Scale-out)이 복잡하다는 단점이 있습니다.
2. 유연한 데이터 저장과 무한한 수평 확장, NoSQL
MongoDB, Redis, Cassandra 등 NoSQL 데이터베이스는 데이터의 형태가 고정되어 있지 않고 다양(JSON Document, Key-Value 등)하게 존재합니다. 스키마 리스(Schema-less) 방식이므로 자유롭게 레코드를 적재하고 유연하게 변경할 수 있습니다.
장점은 거대한 트래픽 분산을 위한 수평적 스케일링이 매우 직관적이고 쉬워 실시간 대규모 데이터 쓰기에 매우 탁월하다는 것입니다.
데이터베이스 선택을 위한 질문
SQL과 NoSQL 선택은 유행이 아니라 데이터의 일관성 요구와 조회 패턴에서 출발해야 합니다. 주문, 결제, 포인트처럼 정합성이 중요한 데이터는 관계형 모델이 유리하고, 로그, 세션, 이벤트 스트림처럼 쓰기량이 큰 데이터는 NoSQL 계열이 적합할 수 있습니다.
실무 점검표
- 트랜잭션 실패가 사용자 금전 손실로 이어진다면 ACID 보장을 우선합니다.
- 조회 패턴이 자주 바뀐다면 스키마 변경 비용과 인덱스 전략을 함께 비교합니다.
- 운영팀이 백업, 복구, 모니터링을 감당할 수 있는지도 선택 기준에 포함합니다.
대부분의 서비스는 하나의 데이터베이스만 쓰지 않습니다. 핵심 원장은 SQL로, 검색이나 캐시, 이벤트 처리는 목적에 맞는 저장소로 나누는 하이브리드 구성이 흔합니다.
참고 자료와 업데이트 기준
이 글은 실무 적용 관점에서 작성했으며, 관련 기술의 공식 문서와 브라우저 지원 현황이 바뀌면 내용을 다시 점검합니다. 특히 프레임워크 버전, API 정책, 성능 측정 방식은 시간이 지나며 달라질 수 있으므로 배포 전에는 최신 문서를 함께 확인하는 것을 권장합니다.
- MDN Web Docs에서 웹 표준과 브라우저 동작을 확인합니다.
- web.dev에서 성능, 접근성, 사용자 경험 기준을 확인합니다.
- React 공식 문서에서 React 관련 API와 권장 패턴을 확인합니다.
