이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
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이니까 뭐든 된다'가 아니라 각 유형의 특성을 이해하고 선택하는 게 중요해요. 도구의 특성을 알아야 올바른 선택을 할 수 있어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.