RDBMS와 SQL (RDBMS and SQL)

RDBMS와 SQL이란

RDBMS(Relational Database Management System) 는
테이블, 행, 열, 관계를 기반으로 데이터를 저장하고 관리하는 데이터베이스 시스템입니다.

SQL(Structured Query Language) 은
이 관계형 데이터를 정의하고, 조회하고, 변경하고, 제어하는 표준 언어입니다.

이 문서는 데이터베이스 구현·운영 관점에서 관계형 모델과 SQL을 어떻게 이해하고 활용할지를 설명합니다.
시스템 설계 관점에서 어떤 저장소를 선택할지, 왜 RDBMS 또는 NoSQL을 고를지 같은 판단은 데이터베이스 설계 문서와 함께 보면 경계가 더 분명합니다.

백엔드 면접에서 RDBMS와 SQL은 단순한 문법 문제가 아닙니다.
보통 다음 질문이 같이 나옵니다.

관계형 모델이 왜 여전히 중요한가
조인은 왜 강력하지만 비싸질 수 있는가
SQL은 내부적으로 어떤 흐름으로 실행되는가
인덱스와 실행 계획은 어떻게 읽어야 하는가

즉, 핵심은 “SELECT를 외웠는가”가 아니라
정형 데이터와 조회 패턴을 어떻게 다룰지 설명할 수 있는가입니다.

관계형 모델이 잘 맞는 경우

관계형 모델의 강점은 무결성, 관계 표현력, ad-hoc query 에 있습니다.

다음처럼 엔티티 간 관계가 분명한 업무에 특히 잘 맞습니다.

주문과 주문 항목
결제와 정산
사용자와 권한
재고와 창고

관점	RDBMS의 강점	주의점
무결성	PK, FK, UNIQUE, CHECK로 제약을 강하게 표현 가능	제약이 많을수록 쓰기 경로가 복잡해질 수 있음
질의 유연성	SQL로 다양한 조건 조회와 집계를 수행 가능	복잡한 질의는 비용 예측이 어려울 수 있음
트랜잭션	여러 테이블 변경을 하나의 작업으로 묶기 좋음	분산 쓰기 확장은 더 복잡함
도구 생태계	실행 계획, 백업, 모니터링, 관리 도구가 성숙함	운영 편의성이 높아도 성능 문제는 직접 봐야 함

관계형 모델이 특히 잘 맞는 경우는 다음과 같습니다.

여러 엔티티를 함께 읽고 써야 함
중복보다 무결성이 더 중요함
정렬, 집계, 필터, 조인이 자주 필요함
데이터 구조가 비교적 명확하고 장기적으로 유지됨

반대로 다음 조건이 강하면 다른 저장소도 후보가 될 수 있습니다.

문서 구조가 자주 바뀜
단순 key-value 조회가 대부분임
대규모 분산 쓰기와 수평 확장이 더 중요함

관련 선택 기준은 NoSQL 데이터베이스, 데이터베이스 설계 문서와 연결해서 보면 좋습니다.

SQL 실행 흐름 개요

SQL은 선언형 언어라서, 개발자는 “무엇을 원한다”를 적고 실제 실행 방법은 옵티마이저가 선택합니다.

개략적인 흐름은 다음과 같습니다.

파싱
- 문법이 맞는지 확인하고 SQL을 내부 표현으로 변환합니다.
분석/검증
- 테이블, 컬럼, 타입, 권한이 유효한지 확인합니다.
최적화
- 어떤 인덱스를 쓸지, 어떤 조인 순서와 조인 알고리즘을 쓸지 선택합니다.
실행
- 스캔, 필터, 조인, 정렬, 집계 같은 연산자를 실제로 수행합니다.

면접에서는 SQL 실행 흐름을 너무 DBMS 내부 구현 수준으로 몰아갈 필요는 없습니다.
대신 다음 정도는 분명히 말하는 편이 좋습니다.

SQL은 선언형이라 실행 계획을 DB가 정한다
같은 SQL도 데이터 분포와 인덱스에 따라 다른 계획이 나올 수 있다
느린 쿼리는 문법보다 실행 계획을 봐야 한다

예를 들어 아래 쿼리는 표면상 단순해 보여도, 실제 비용은 인덱스 유무와 조인 순서에 크게 좌우됩니다.

SELECT o.id, o.created_at, p.status
FROM orders o
JOIN payments p ON p.order_id = o.id
WHERE o.user_id = 100
  AND o.created_at >= '2025-01-01'
ORDER BY o.created_at DESC
LIMIT 20;

즉, SQL 답변은 문법보다 어떤 실행 계획이 만들어질지 감을 잡는가가 더 중요합니다.

조인 전략과 인덱스 활용

조인은 관계형 데이터베이스의 강점이지만, 데이터가 커질수록 비용이 커질 수 있습니다.

대표 조인 전략은 다음과 같습니다.

전략	잘 맞는 경우	주의점
Nested Loop Join	한쪽 집합이 작고, 반대쪽에 인덱스가 있을 때	큰 집합끼리 만나면 비싸질 수 있음
Hash Join	큰 집합 간 동등 조인	해시 테이블 메모리 사용량이 커질 수 있음
Merge Join	양쪽이 정렬되어 있거나 정렬 비용이 낮을 때	정렬 비용이 추가될 수 있음

Nested Loop Join

한쪽 테이블의 행을 하나씩 읽으면서 다른 쪽에서 매칭을 찾는 방식입니다.¹

장점: 작은 드라이빙 집합과 인덱스가 있을 때 매우 효율적
주의점: 바깥쪽 집합이 커지면 반복 탐색 비용이 커질 수 있음

Hash Join

한쪽 집합으로 해시 테이블을 만들고, 다른 쪽 집합을 읽으며 매칭을 찾는 방식입니다.

장점: 대용량 동등 조인에서 유리할 수 있음
주의점: 메모리 부족 시 디스크 spill이 발생할 수 있음

Merge Join

정렬된 두 집합을 병합하며 조인하는 방식입니다.

장점: 이미 정렬된 데이터나 인덱스 순서를 활용할 수 있음
주의점: 정렬 비용이 추가되면 이점이 줄어듦

인덱스는 조인과 필터링 모두에 중요합니다.²

조인 키에 인덱스가 있으면 Nested Loop Join 효율이 올라갈 수 있습니다.
WHERE, ORDER BY, GROUP BY 패턴에 맞는 인덱스가 필요합니다.
복합 인덱스는 컬럼 순서가 매우 중요합니다.

예를 들어 다음과 같은 조회 패턴이 잦다면:

SELECT id, created_at
FROM orders
WHERE user_id = 100
  AND status = 'PAID'
ORDER BY created_at DESC;

다음과 같은 복합 인덱스를 검토할 수 있습니다.

CREATE INDEX idx_orders_user_status_created_at
ON orders (user_id, status, created_at DESC);

이 지점의 구현 상세는 데이터베이스 최적화 문서와 직접 연결됩니다.

실행 계획과 쿼리 튜닝 기본

느린 SQL을 만났을 때는 감으로 고치기보다 실행 계획부터 봐야 합니다.

대표 흐름은 다음과 같습니다.

느린 쿼리 수집
- 슬로우 쿼리 로그, APM, 애플리케이션 타이머로 후보를 찾습니다.
실행 계획 확인
- EXPLAIN, EXPLAIN ANALYZE로 실제 스캔과 조인 전략을 확인합니다.³
병목 유형 구분
- 풀 스캔인지
- 잘못된 조인 순서인지
- 정렬 비용인지
- 락 대기인지
변경 후 비교
- 인덱스 추가, SQL 수정, 통계 갱신 후 실제로 latency와 자원 사용량이 좋아졌는지 봅니다.

자주 나오는 튜닝 기본기는 다음과 같습니다.

SELECT * 지양: 필요한 컬럼만 읽기
조건절 함수 사용 주의: 인덱스 활용이 깨질 수 있음
저선택도 인덱스 주의: 인덱스가 있어도 풀 스캔이 더 나을 수 있음
N+1 제거: 애플리케이션 반복 조회 대신 join, batch fetch, preloading 사용
통계 갱신 확인: 옵티마이저 통계가 오래되면 나쁜 계획이 선택될 수 있음

면접에서는 “인덱스를 추가했다”보다
왜 풀 스캔이 나왔고, 어떤 실행 계획 변화가 있었는지까지 말해야 답변이 단단해집니다.

정규화와 비정규화

정규화와 비정규화는 관계형 모델에서 자주 나오는 설계 선택입니다.

항목	정규화	비정규화
장점	중복 감소, 무결성 유지, 수정 일관성 확보	조회 단순화, 조인 감소, 읽기 성능 개선
단점	조인이 많아질 수 있음	데이터 중복과 동기화 비용 발생
잘 맞는 경우	주문, 결제, 정산 같은 쓰기 정확도가 중요한 업무	피드, 목록, 대시보드처럼 읽기 비중이 큰 업무

좋은 답변은 둘 중 하나를 절대화하지 않습니다.

원본 데이터는 정규화 중심으로 설계
읽기 병목이 생기는 부분만 선택적으로 비정규화
캐시, materialized view, 읽기 전용 모델도 함께 검토

이 문서는 구현과 운영 관점에서 비정규화가 어떤 대가를 만드는지를 설명합니다.
시스템 설계 관점에서 왜 비정규화를 선택하는지는 데이터베이스 설계 문서가 더 직접적입니다.

운영 관점에서 자주 보는 포인트

RDBMS와 SQL을 실무에서 잘 다룬다는 말은 다음 항목을 같이 본다는 뜻입니다.

슬로우 쿼리 로그: 어떤 SQL이 실제로 느린지 확인
실행 계획 변화: 배포나 통계 갱신 이후 계획이 바뀌었는지 확인
락 대기: 성능 문제처럼 보이지만 실제로는 트랜잭션 경합일 수 있음
인덱스 사용률: 거의 안 쓰는 인덱스는 쓰기 비용만 늘릴 수 있음
데이터 증가 추세: 지금 빠른 쿼리도 10배 데이터에서 유지되는지 확인

RDBMS 운영은 “SQL을 쓸 줄 안다”로 끝나지 않습니다.

실행 계획을 읽을 수 있어야 하고
인덱스의 대가를 이해해야 하며
스키마 변경이 쿼리 성능에 어떤 영향을 주는지 볼 수 있어야 합니다

읽기 확장과 replica lag, 파티셔닝, 샤딩 같은 주제는 데이터베이스 스케일링 문서와 함께 보면 좋습니다.

면접 포인트

RDBMS의 강점은 무결성, 조인, 트랜잭션, 질의 유연성에 있습니다.
SQL은 선언형 언어이므로 느린 쿼리는 문법보다 실행 계획을 먼저 봐야 합니다.
조인 전략은 데이터 크기, 인덱스 유무, 정렬 상태에 따라 달라질 수 있습니다.
복합 인덱스는 컬럼 순서가 핵심이고, 읽기 성능을 얻는 대신 쓰기 비용이 늘어납니다.
정규화와 비정규화는 절대선이 아니라 읽기 패턴과 무결성 요구에 따른 선택입니다.