Daily Dev Q&A: RDBMS

Topic (오늘의 주제)

RDBMS (Relational Database Management System)

: 데이터를 테이블(Table) 형태의 관계(Relation)로 정의하고, 이들 간의 연관 관계를 통해 데이터를 관리하는 시스템.

Why (왜 사용하는가? 왜 중요한가?)

• 실무: 엄격한 스키마와 제약 조건(Constraint)이 없으면 데이터의 중복, 누락, 모순 등 데이터 무결성(Integrity) 문제가 발생하여 시스템의 신뢰도가 무너진다.
• 구조적 의미: 정규화(Normalization)를 통해 데이터 중복을 최소화하여 저장 효율을 높이고, SQL이라는 표준 언어를 통해 복잡한 데이터를 체계적으로 추출할 수 있다.
• 면접 의도: 백엔드 개발자의 가장 기초 소양으로, 데이터 모델링 능력, 트랜잭션에 대한 이해(ACID), 그리고 NoSQL과의 차이를 명확히 알고 기술 스택을 선정할 수 있는지 확인한다.

Core Concept (핵심 개념 정리)

요소	내용
개념 정의	2차원 테이블(행/열)로 데이터를 표현하며, 테이블 간의 관계(PK, FK)를 통해 데이터를 구조화하여 저장/관리하는 시스템. (예: MySQL, PostgreSQL, Oracle)
동작 방식	1. 스키마 정의: 데이터 타입과 구조를 미리 정의. 2. SQL 수행: 클라이언트가 SQL 요청. 3. 옵티마이저: 가장 효율적인 경로 계획 수립. 4. 스토리지 엔진: 디스크 I/O 수행 및 트랜잭션 처리(ACID 보장).
장점/단점	장점: 데이터의 정확성(무결성) 보장, 표준화된 언어(SQL), 트랜잭션 처리 용이. 단점: 스키마 변경이 유연하지 않음, 수평적 확장(Scale-out)이 NoSQL에 비해 복잡하고 어려움.
필요 조건	데이터가 구조적이고 일관성이 중요해야 함. 명확한 스키마(Schema) 설계가 선행되어야 함.
예시/비교	vs NoSQL: RDBMS는 '은행 거래'처럼 정확성이 생명인 곳에 적합하고, NoSQL(MongoDB 등)은 '로그 데이터'나 'SNS 피드'처럼 구조가 가변적이고 대용량 확장이 필요한 곳에 유리함.

Interview Answer Version (면접 답변식 요약)

"RDBMS는 데이터를 2차원 테이블 형태로 정의하고, 테이블 간의 관계를 통해 데이터를 관리하는 시스템입니다.

주로 사용하는 이유는 데이터의 무결성과 일관성을 보장하기 위해서입니다. 트랜잭션의 ACID 성질을 준수하기 때문에, 금융 시스템이나 결제 로직처럼 데이터의 정확성이 중요한 서비스에서 필수적으로 사용됩니다. 반면 스키마가 고정되어 있어 유연성이 떨어지는 단점이 있지만, 이를 통해 안정적인 데이터 관리가 가능합니다."

Practical Tip (사용시 주의할 점 or 활용 예)

1. 인덱스(Index)의 양날의 검

RDBMS 성능의 핵심은 인덱스이지만, 무분별하게 생성하면 오히려 성능이 저하됩니다.

• 문제: 인덱스는 SELECT 속도를 높이지만, INSERT, UPDATE, DELETE 시에는 인덱스도 함께 수정해야 하므로 쓰기 성능이 떨어집니다.
• 주의: 카디널리티(Cardinality, 중복도가 낮고 고유한 값의 정도)가 높은 컬럼(예: 주민번호, ID)에 인덱스를 걸어야 효과적입니다. 성별(남/여) 같은 컬럼에 걸면 효율이 떨어집니다.

2. 정규화 vs 반정규화 (Normalization vs Denormalization)

• 개념: 이론적으로는 제3 정규화까지 수행하여 중복을 없애는 것이 좋지만, 실무에서는 조인(Join) 연산 비용 때문에 의도적으로 데이터를 중복시키는 반정규화를 하기도 합니다.
• Tip: 처음 설계는 정규화를 원칙으로 하되, 쿼리 성능 분석 후 조인이 너무 많아 성능 저하가 발생하는 지점(병목)에 한해 반정규화를 고려해야 합니다.

3. N+1 문제 (ORM 사용 시)

• 상황: JPA 같은 ORM을 사용할 때, RDBMS의 연관 관계 설정을 잘못하면 목록 조회 시 1번의 쿼리 후 연관 데이터를 가져오기 위해 N번의 추가 쿼리가 발생합니다.
• 해결: Fetch Join이나 Batch Size 설정을 통해 쿼리 수를 최적화해야 합니다.

예상 꼬리 질문 정리

1. "RDBMS의 트랜잭션 특징인 ACID에 대해 설명해주실 수 있나요?"
   • (Atomic, Consistency, Isolation, Durability 각각의 의미와 실무 적용 예시 준비 필요)
2. "인덱스(Index)는 어떤 자료구조로 되어있으며, 왜 그 자료구조를 쓰나요?"
   • (B-Tree, B+Tree 구조와 해시 테이블과의 차이점, 범위 검색(Range Scan) 효율성 설명 필요)
3. "데이터가 너무 많아져서 RDBMS 한 대로는 감당이 안 될 때, 어떤 방법을 쓸 수 있나요?"
   • (Replication(복제)을 통한 읽기 분산, Sharding(샤딩)을 통한 쓰기 분산 개념 준비 필요)

Deep Dive (공부하며 몰랐던 개념)

① 트랜잭션의 4대 요소 (ACID)

**트랜잭션(Transaction)**이란 데이터베이스의 상태를 변화시키는 하나의 논리적인 작업 단위입니다. RDBMS가 데이터의 무결성을 보장하기 위해 반드시 지키는 4가지 성질이 바로 ACID입니다.

1. Atomicity (원자성)

"All or Nothing" (전부 실행되거나, 아예 실행되지 않거나)

• 개념: 트랜잭션 내의 모든 연산은 반드시 한꺼번에 완료되어야 하며, 그중 하나라도 실패하면 트랜잭션 전체가 취소(Rollback)되어야 합니다.
• 실무 예시 (계좌 이체):
  • A의 잔고 차감 → B의 잔고 증가
  • 이 두 과정은 한 몸입니다. 만약 A의 돈은 빠져나갔는데 시스템 오류로 B에게 돈이 안 들어갔다면, Rollback을 통해 A의 돈을 다시 원상복구 시켜야 합니다. 어정쩡한 성공은 없습니다.
• 관련 명령어: COMMIT(저장), ROLLBACK(취소)

2. Consistency (일관성)

"트랜잭션 전후의 데이터는 항상 규칙(제약 조건)을 만족해야 한다"

• 개념: 트랜잭션이 성공적으로 완료되면, 데이터베이스는 항상 미리 정의된 규칙(Constraints)을 만족하는 일관성 있는 상태를 유지해야 합니다.
• 실무 예시:
  • '모든 고객의 잔고는 0원 이상이어야 한다'는 제약 조건(Constraint)이 있다고 칩시다.
  • 만약 A가 잔고보다 많은 금액을 이체하려 한다면, 시스템은 이를 거부하고 트랜잭션을 실행하지 않음으로써 데이터의 일관성을 지킵니다.
  • 데이터 타입(문자/숫자)이나 기본 키(PK), 외래 키(FK) 제약 조건도 여기에 포함됩니다.

3. Isolation (격리성 / 고립성)

"끼어들기 금지 (독립적인 수행)"

• 개념: 여러 트랜잭션이 동시에 실행될 때, 서로의 작업에 영향을 주거나 중간 연산 결과를 볼 수 없습니다.
• 실무 예시:
  • A가 B에게 송금하는 도중(아직 커밋 전), C가 B의 잔고를 조회했을 때, **'입금 처리 중인 엉뚱한 값'**을 보게 해서는 안 됩니다.
  • C는 입금 전의 잔고를 보거나, 입금이 끝난 후의 잔고를 봐야 합니다.
• 주의점: 격리성이 너무 높으면(직렬화) 성능이 떨어지므로, 실무에서는 **'격리 수준(Isolation Level)'**을 조절하여 성능과 안정성의 균형을 맞춥니다.

4. Durability (지속성)

"한 번 저장된 것은 영원하다"

• 개념: 트랜잭션이 성공적으로 완료(Commit)되었다면, 그 결과는 시스템 오류나 정전이 발생해도 영구적으로 반영되어야 합니다.
• 실무 예시:
  • "이체 완료" 메시지가 뜬 0.1초 뒤에 은행 서버의 전원이 꺼지더라도, 서버를 다시 켰을 때 이체 내역은 데이터베이스에 안전하게 기록되어 있어야 합니다.
  • 데이터베이스는 이를 위해 로그(Log)를 먼저 남기는 방식(WAL 등)을 사용합니다.

---

💡 요약 테이블

성질	개념 요약	핵심 키워드
Atomicity (원자성)	트랜잭션은 쪼개질 수 없음. (전부 성공 or 전부 실패)	All or Nothing, Rollback
Consistency (일관성)	트랜잭션 전후 데이터는 제약 조건을 위배하지 않음.	무결성, Constraint, 규칙 준수
Isolation (격리성)	동시에 실행되는 트랜잭션끼리 서로 간섭 불가.	동시성 제어, Isolation Level
Durability (지속성)	성공한 트랜잭션 결과는 영구적으로 저장됨.	영구 보존, 로그(Log)

---

TIP: 꼬리 질문 대비

작성하신 "예상 꼬리 질문" 섹션의 첫 번째 질문에 대한 답변이 위 내용이 될 것입니다. 여기서 조금 더 깊게 들어간다면 다음 질문이 나올 확률이 매우 높습니다.

"격리성(Isolation)을 완벽하게 지키면 성능 문제가 발생할 수 있는데, 이를 어떻게 해결하나요?"

이 질문에 대비하기 위해 트랜잭션 격리 수준(Transaction Isolation Level) 4단계(Read Uncommitted, Read Committed, Repeatable Read, Serializable)에 대해 간단히 알아두시면 좋습니다.

 

② 트랜잭션 격리 수준 (Transaction Isolation Level)

왜 필요한가요?

격리성(Isolation)을 100% 보장하려면 모든 트랜잭션을 줄 세워서 하나씩 처리해야 합니다(동시성 0). 이러면 데이터는 안전하지만 성능이 너무 느려집니다. 반대로 성능을 위해 막 끼어들게 하면 데이터가 꼬입니다.

따라서, **"얼마나 엄격하게 격리할 것인가?"**를 4단계로 나누어 상황에 맞게 선택합니다.

1단계: Read Uncommitted (커밋되지 않은 읽기)

• 설명: A 트랜잭션이 데이터를 변경하고 아직 커밋하지 않았는데, B 트랜잭션이 그 변경된 값을 읽을 수 있습니다.
• 문제점: Dirty Read (오손 읽기)
  • A가 데이터를 수정했다가 문제가 생겨 롤백(취소)했는데, B는 이미 수정된(취소되어야 할) 값을 가지고 로직을 수행해버리는 치명적인 오류가 발생합니다.
• 특징: 데이터 정합성이 보장되지 않아 실무에서는 거의 사용하지 않습니다.

2단계: Read Committed (커밋된 읽기) - [가장 많이 사용]

• 설명: 트랜잭션이 커밋을 확정한 데이터만 다른 트랜잭션이 읽을 수 있습니다. (Dirty Read 해결)
• 특징:
  • Oracle, SQL Server, PostgreSQL 등 대부분의 RDBMS의 기본 설정입니다.
• 문제점: Non-Repeatable Read (반복 불가능한 조회)
  • A가 데이터를 조회 중인데, B가 그 사이 데이터를 수정하고 커밋해버리면, A가 다시 조회했을 때 값이 달라져 있습니다. (한 트랜잭션 내에서 조회 결과가 다름)

3단계: Repeatable Read (반복 가능한 읽기) - [MySQL 기본]

• 설명: 트랜잭션이 시작되기 전에 커밋된 내용만 조회할 수 있습니다. 트랜잭션 내에서 여러 번 조회해도 항상 결과가 동일합니다.
  • 자신의 트랜잭션 번호보다 낮은(먼저 일어난) 트랜잭션의 변경만 봅니다.
• 특징: **MySQL(InnoDB)**의 기본 설정입니다.
• 문제점: Phantom Read (유령 읽기)
  • 데이터를 수정하는 것(UPDATE)은 막았지만, 새로운 데이터가 생성(INSERT)되는 것은 못 막는 경우가 있습니다.
  • A가 "직원 수"를 조회(5명)했는데, B가 새로운 직원을 추가(INSERT)하고 커밋하면, A가 다시 조회했을 때 6명이 되는(없던 유령 데이터가 보이는) 현상입니다.
  • 참고: MySQL InnoDB는 MVCC(다중 버전 동시성 제어) 등을 통해 Phantom Read도 어느 정도 방지합니다.

4단계: Serializable (직렬화 가능)

• 설명: 가장 엄격한 수준입니다. 읽기 작업 중에는 다른 트랜잭션이 해당 데이터에 접근(수정, 추가)조차 못 하게 락(Lock)을 걸어버립니다.
• 특징: 데이터 정합성은 완벽하지만, 동시 처리 성능이 급격히 떨어집니다.
• 문제점: 교착 상태(Deadlock)가 자주 발생합니다.

---

💡 한눈에 보는 비교 표 (면접용)

위로 갈수록 **성능(동시성)**이 좋고, 아래로 갈수록 **데이터 정확성(격리성)**이 높습니다.

수준 (Level)	발생 가능한 문제 (Side Effect)	설명	주요 DB 기본값
1. Read Uncommitted	Dirty Read, Non-Repeatable, Phantom	커밋 안 된 것도 읽음 (위험)	-
2. Read Committed	Non-Repeatable Read, Phantom	커밋 된 것만 읽음	Oracle, PostgreSQL
3. Repeatable Read	Phantom Read	내 트랜잭션 동안은 결과 동일	MySQL
4. Serializable	없음 (완벽 격리)	그냥 줄 서서 기다림 (느림)	-

---

🗣 면접 답변 가이드

Q. "어떤 격리 수준을 사용하는 것이 좋나요?"

A.

"무조건 높은 단계가 좋은 것은 아닙니다. 격리 수준이 높아질수록 데이터의 무결성은 보장되지만, 락(Lock)으로 인한 성능 저하와 데드락(Deadlock) 발생 가능성이 커집니다.

따라서, 일반적인 서비스에서는 Read Committed나 Repeatable Read 수준을 사용하여 성능과 정합성의 균형을 맞춥니다. 하지만 결제 잔고 처리처럼 정합성이 매우 중요한 로직에서는 필요에 따라 비관적 락(Pessimistic Lock) 등을 활용해 더 높은 수준의 격리성을 보장하도록 설계해야 합니다."