면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
RDB는 테이블 구조와 관계(Relation)를 기반으로 데이터를 저장합니다. 열(column)과 행(row)이 고정된 스키마 안에 들어가고, 테이블 간에는 외래 키(Foreign Key)로 연결합니다. 반면 NoSQL은 스키마가 유연하거나 없는 비관계형 구조로, 문서·키-값·그래프·컬럼 등 다양한 형태로 저장할 수 있습니다. RDB는 데이터 일관성과 트랜잭션 처리에 강하고, NoSQL은 대용량 데이터나 빠른 읽기·쓰기, 수평 확장에 유리합니다. 어느 쪽이 낫냐는 데이터 구조와 서비스 특성에 따라 달라집니다. 정형화된 금융 데이터에는 RDB가, 로그나 사용자 행동 데이터에는 NoSQL이 맞는 경우가 많습니다.
RDB와 NoSQL을 선택할 때 저는 '데이터 간 관계가 얼마나 복잡한가'를 먼저 봐요. 관계가 많고 일관성이 중요하면 RDB, 관계가 단순하고 확장성이 중요하면 NoSQL을 봐요. 예를 들어 주문·결제처럼 정합성이 중요한 데이터는 RDB의 ACID 트랜잭션이 적합해요. 반면 SNS의 피드나 실시간 로그처럼 빠른 쓰기와 유연한 구조가 필요하면 NoSQL이 더 맞아요. 실무에서는 두 가지를 함께 쓰는 경우도 많아요. 한 시스템 안에서도 각 데이터의 특성에 맞게 저장소를 나눠 쓰는 것이 효율적이라고 생각해요. 데이터 설계는 기술보다 비즈니스 요구로부터 시작해요.
NoSQL은 하나가 아니라 여러 종류가 있어요. 문서형(Document)은 JSON처럼 유연한 구조의 데이터를 저장하고, 키-값형(Key-Value)은 캐시나 세션 관리에 많이 써요. 그래프형은 관계 중심 데이터(SNS 친구 관계)에, 컬럼형은 시계열 데이터나 대규모 집계에 유리해요. RDB가 '하나의 답'처럼 느껴질 수 있는데, NoSQL은 문제의 성격에 따라 골라야 하는 도구예요. 어떤 NoSQL을 선택하느냐도 데이터의 읽기·쓰기 패턴과 접근 방식에 따라 달라요.
'NoSQL이니까 뭐든 된다'가 아니라 각 유형의 특성을 이해하고 선택하는 게 중요해요. 도구의 특성을 알아야 올바른 선택을 할 수 있어요.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.