Database 면접 Q&A 정리 — 인강 노트

강의 형식: 하나의 강의 = 하나의 면접 질문. 각 질문을 브론즈(50점) → 실버(80점) → 골드(100점) 답변으로 비교 분석한다. 기준 DBMS는 대부분 MySQL(InnoDB)이다.

목차

섹션 2. 트랜잭션

1. Q. 트랜잭션이 무엇이고 ACID에 대해 설명해 주세요
2. Q. 실무에서 트랜잭션을 사용할 때 주의할 점은 무엇인가요?
3. Q. 트랜잭션 격리 수준의 종류를 설명해 주세요
4. Q. 트랜잭션 격리 수준에 따라 나타날 수 있는 문제(더티 리드, 논리피터블 리드, 팬텀 리드)를 설명해 주세요
5. Q. 트랜잭션 격리 수준에 따라 나타날 수 있는 문제는 어떻게 해결하나요?
6. Q. MVCC란 무엇이고 왜 사용하나요?
7. Q. InnoDB는 Repeatable Read만으로 팬텀 리드를 어떻게 해결하나요?

섹션 3. 락과 동시성 제어 8. Q. DB 락이란 무엇이고 어떤 종류가 있나요? 9. Q. 낙관적 락과 비관적 락의 차이는 무엇인가요? 10. Q. 낙관적 락과 비관적 락은 구체적으로 어떤 기준으로 선택하나요? 11. Q. 분산락이란 무엇이고 언제 사용하나요? 12. Q. Lost Update Problem이란 무엇이고 왜 트랜잭션 격리 수준으로 해결하지 못하나요? 13. Q. Lost Update Problem은 어떻게 해결하나요?

섹션 4. 인덱스 14. Q. 인덱스란 무엇이고 장단점을 설명해 주세요 15. Q. 인덱스는 왜 해시 테이블이 아니라 주로 B-Tree를 사용하나요? 16. Q. 인덱스는 B-Tree 방식으로 구체적으로 어떻게 동작하나요? 17. Q. 클러스터링 인덱스와 비클러스터링 인덱스의 차이는 무엇인가요? 18. Q. InnoDB에서 인덱스 검색은 구체적으로 어떻게 동작하나요? (2단계 검색) 19. Q. 복합 인덱스 사용 시 주의할 점은 무엇인가요? 20. Q. 동료가 불(bool) 타입 컬럼에 인덱스를 건다면 어떤 의견을 내시겠어요? 21. Q. LIKE 'xxx%'는 인덱스를 타는데 '%xxx%'는 왜 인덱스를 타지 않나요?

섹션 5. NoSQL과 RDBMS 비교 22. Q. RDBMS와 NoSQL의 차이를 설명해 주세요. 언제 각각을 사용하나요? 23. Q. 데이터 모델링 관점에서 RDBMS와 NoSQL의 설계 방식은 어떻게 다른가요? 24. Q. RDBMS에서도 스케일아웃이 가능한가요? 25. Q. NoSQL은 왜 스케일아웃에 유리한가요? 26. Q. MySQL과 PostgreSQL은 어떤 차이가 있나요? 27. Q. CAP 이론이 무엇인가요? 28. Q. 실무에서 C(일관성)와 A(가용성)는 어떤 기준으로 선택하나요?

섹션 6. 커넥션과 커넥션 풀 29. Q. DB 커넥션이란 무엇이고 생성 비용이 큰 이유는 무엇인가요? 30. Q. 커넥션 풀이란 무엇이고 왜 사용하나요? 31. Q. 커넥션 풀 크기는 클수록 좋은가요? 32. Q. 커넥션 타임아웃과 리드 타임아웃의 차이는 무엇이고, 타임아웃은 왜 필요한가요? 33. Q. 커넥션 풀 상태를 어떻게 모니터링하고 문제를 어떻게 진단하나요?

섹션 7. 운영 34. Q. 운영 중 슬로우 쿼리가 발생하면 어떻게 대처하나요? 35. Q. EXPLAIN에서 구체적으로 무엇을 봐야 하나요? 36. Q. 데이터 자체가 많아져서 느려지면 어떻게 해결하나요? 37. Q. 클러스터링, 리플리케이션, 샤딩의 차이를 설명해 주세요 38. Q. 리플리케이션에서 구체적으로 어떻게 데이터가 복제되나요? 39. Q. 데드락이 무엇이고 DB에서 왜 발생하나요? 40. Q. 데드락이 발생하면 어떻게 감지하고 대처하나요? 41. Q. DB에 장애가 발생하면 어떤 순서로 접근하시나요? 42. Q. DB 모니터링에서 주요하게 봐야 하는 메트릭은 무엇인가요?

섹션 2. 트랜잭션

Q. 트랜잭션이 무엇이고 ACID에 대해 설명해 주세요

핵심 답변 (골드 수준)

트랜잭션은 데이터베이스에서 논리적인 작업의 단위이며, 동시에 장애가 발생했을 때 데이터를 복구하는 작업의 단위이기도 하다. 장애가 발생하면 트랜잭션 단위로 롤백된다는 의미가 여기에 담긴다.

ACID는 트랜잭션이 보장해야 하는 네 가지 특성이다.

• 원자성(Atomicity): 트랜잭션의 작업이 모두 실행되거나 하나도 실행되지 않아야 한다.
• 일관성(Consistency): 트랜잭션 전후로 제약 조건에 맞게 데이터가 변경되어야 한다. 여기서 제약 조건은 NOT NULL 같은 DB 제약만이 아니라 "계좌 잔액은 0 미만이 될 수 없다" 같은 비즈니스 규칙까지 포함한다.
• 격리성(Isolation): 다른 트랜잭션이 끼어들지 못하도록 보장한다.
• 지속성(Durability): 커밋된 결과는 시스템 장애에서도 영구 보존되어야 한다.

다만 격리성을 엄격하게 지키면 동시성이 매우 떨어지므로, 실무에서는 격리 수준을 조절하여 적절한 트레이드오프를 가져간다.

핵심 키워드: ① 복구의 단위 ② 제약 조건(비즈니스 규칙 포함) ③ 격리성의 트레이드오프

답변 레벨 차이

꼬리 질문

• "그렇다면 실무에서 트랜잭션을 사용할 때 주의할 점은 뭔가요?" → 다음 질문에서 다룸. 골드 답변처럼 답하면 자연스럽게 이 꼬리로 이어진다.
• 격리 수준을 언급했으므로 **"격리 수준의 종류는요?"**로도 이어질 수 있다.

Q. 실무에서 트랜잭션을 사용할 때 주의할 점은 무엇인가요?

핵심 답변 (골드 수준)

트랜잭션은 꼭 필요한 최소의 코드에만 적용해야 한다. 이유는 두 가지다.

1. 커넥션 점유: 트랜잭션 동안 커넥션을 점유하므로, 트랜잭션이 길어지면 커넥션 풀이 고갈되어 다른 요청이 전부 대기하게 된다. 특히 트랜잭션 안에서 외부 API를 호출하면 응답 시간만큼 커넥션이 잠기므로 반드시 트랜잭션 밖으로 분리해야 한다.
2. 락 유지 시간: 트랜잭션이 길어지면 락 유지 시간도 길어져 다른 트랜잭션의 동시성이 떨어진다.

강사 실무 사례: 트랜잭션 안에서 호출하는 외부 API에 타임아웃이 설정되어 있지 않아 트랜잭션이 수십 초씩 커넥션을 점유했고, 결국 커넥션 풀이 고갈되면서 서비스 전체가 멈춘 장애가 있었다. 트랜잭션 범위를 잘못 잡은 것과 타임아웃 미설정 두 가지가 전체 장애로 이어진 것이다.

핵심 키워드: ① 커넥션 점유 ② 외부 API 분리 ③ 트랜잭션 길이와 락의 관계

답변 레벨 차이

꼬리 질문

• "격리 수준은 구체적으로 어떤 종류가 있나요?" → 앞 질문의 "격리 수준을 조절한다"는 언급에서 이어지는 다음 메인 질문.

Q. 트랜잭션 격리 수준의 종류를 설명해 주세요

관련 노트: isolation

핵심 답변 (골드 수준)

트랜잭션 격리 수준은 네 가지가 있다. 이름 나열이 아니라 각 수준에서 어떤 데이터를 읽을 수 있는지까지 말해야 한다.

• READ UNCOMMITTED: 커밋되지 않은 데이터도 읽을 수 있다.
• READ COMMITTED: 커밋이 된 데이터만 읽는다.
• REPEATABLE READ: 자신의 트랜잭션이 생성되기 이전의 트랜잭션에서 커밋된 데이터만 읽는다. 즉 내 트랜잭션 시작 시점 기준으로 읽는다는 것이 핵심이다.
• SERIALIZABLE: 모든 읽기와 쓰기에 락을 걸어 트랜잭션을 순차적으로 실행한다. 모든 이상 현상을 방지하지만 동시성이 가장 낮다.

핵심 키워드: 네 가지 격리 수준 각각 + 각 수준에서 읽을 수 있는 데이터의 범위. 특히 REPEATABLE READ의 "자신의 트랜잭션이 생성되기 이전"이라는 표현과 SERIALIZABLE의 동시성 트레이드오프.

답변 레벨 차이

꼬리 질문

• "각 격리 수준에서 어떤 문제가 발생할 수 있나요?" → 격리 수준을 설명하면 거의 반드시 따라오는 질문. 다음 섹션에서 다룸.

Q. 트랜잭션 격리 수준에 따라 나타날 수 있는 문제(더티 리드, 논리피터블 리드, 팬텀 리드)를 설명해 주세요

관련 노트: isolation

핵심 답변 (골드 수준)

정의만이 아니라 각 문제가 어떤 격리 수준에서 발생하는지 매핑해서 답해야 한다.

• 더티 리드(Dirty Read): 다른 트랜잭션에서 처리한 작업이 완료(커밋)되지 않았음에도 볼 수 있는 현상. READ UNCOMMITTED에서 발생한다.
• 논리피터블 리드(Non-Repeatable Read): 하나의 트랜잭션 내에서 동일한 SELECT를 실행했을 때 결과가 달라지는 현상. READ COMMITTED에서 발생한다.
• 팬텀 리드(Phantom Read): SELECT ... FOR UPDATE 같은 잠금 읽기 시 다른 트랜잭션이 INSERT한 레코드가 보였다 안 보였다 하는 현상. InnoDB 외의 REPEATABLE READ에서 발생한다.

팬텀 리드는 아무 때나 발생하는 것이 아니라 "잠금 읽기"라는 특정 조건에서 발생한다는 점이 핵심이다. 그 이유는 다음 꼬리 질문(해결 방법)에서 이어진다.

핵심 키워드: ① 문제 ↔ 격리 수준 매핑(더티 리드–READ UNCOMMITTED / 논리피터블 리드–READ COMMITTED / 팬텀 리드–REPEATABLE READ) ② 잠금 읽기 조건 ③ (MySQL 한정) InnoDB 외의 REPEATABLE READ에서 팬텀 리드 발생

답변 레벨 차이

꼬리 질문

• "그렇다면 이 문제들을 어떻게 해결하나요?" → 언두 영역, MVCC, 넥스트 키 락이 등장하는 다음 질문.

Q. 트랜잭션 격리 수준에 따라 나타날 수 있는 문제는 어떻게 해결하나요?

관련 노트: isolation

핵심 답변 (골드 수준)

문제의 정의는 잘 답해도 해결은 명쾌하게 답하지 못하는 경우가 많다. "커밋된 데이터만 읽으면 된다"는 결과이지 방법이 아니다. 어떤 메커니즘으로 해결하는지를 말해야 한다.

• 더티 리드: 언두(Undo) 영역을 사용하여 해결한다. 다른 트랜잭션이 변경 중인 데이터를 직접 읽지 않고, 언두 영역에 보관된 커밋 전 원본 데이터를 읽어 반환한다.
• 논리피터블 리드: 마찬가지로 언두 영역을 활용하되, 내 트랜잭션보다 나중에 시작된 트랜잭션이 커밋한 변경은 무시하고 내 트랜잭션 시작 시점의 데이터만 보여주는 방식으로 해결한다.
• 팬텀 리드: 일반 SELECT는 MVCC 스냅샷을 읽으므로 발생하지 않지만, SELECT ... FOR UPDATE는 잠금을 걸기 위해 현재 시점의 실제 레코드를 읽으므로 새로 추가된 로우가 보이게 된다. 이를 해결하려면 SERIALIZABLE 격리 수준을 사용하거나 InnoDB의 **넥스트 키 락(Next-Key Lock)**을 활용한다.

일반 SELECT와 잠금 읽기(SELECT ... FOR UPDATE)의 차이를 구분하는 것이 팬텀 리드를 구조적으로 이해했다는 신호가 된다.

핵심 키워드: ① 언두 영역 ② MVCC 스냅샷 vs 잠금 읽기 ③ 넥스트 키 락

답변 레벨 차이

꼬리 질문

• "MVCC가 정확히 뭐고 왜 사용하나요?" → 언두 영역·MVCC 스냅샷 키워드를 꺼냈으므로 자연스럽게 이어지는 질문.

Q. MVCC란 무엇이고 왜 사용하나요?

핵심 답변 (골드 수준)

MVCC(Multi-Version Concurrency Control)는 하나의 레코드에 대해 여러 개의 버전이 동시에 관리되는 것을 의미한다.

InnoDB에서는 언두 영역을 활용하여 이를 구현하는데, 언두 영역이란 UPDATE나 DELETE 시 변경되기 전 데이터를 보관하는 곳이다.

MVCC를 사용하면 락을 사용하지 않고 읽기 작업을 수행할 수 있어 동시성이 크게 향상된다. 트랜잭션이 시작되면 그 시점의 스냅샷을 기준으로 데이터를 읽고, 다른 트랜잭션이 이후에 데이터를 변경하더라도 내 트랜잭션은 언두 영역에 보관된 시작 시점의 버전만 보게 된다. 덕분에 논리피터블 리드 같은 문제가 자연스럽게 해결된다.

"읽기에 락을 걸지 않으니 다른 트랜잭션이 기다릴 필요가 없다" — 이것이 MVCC의 존재 이유이며, 이 한 문장을 말할 수 있어야 MVCC를 안다고 할 수 있다.

핵심 키워드: ① 언두 영역(구현 방식) ② 락 없는 읽기 ③ 스냅샷과 언두 영역의 관계(트랜잭션 시작 시점의 버전을 언두 영역에서 읽는 구조)

답변 레벨 차이

꼬리 질문

• "그러면 팬텀 리드는요? MVCC로도 해결이 안 되나요?" → 잠금 읽기는 현재 시점의 실제 레코드를 읽기 때문에 MVCC만으로 완전히 해결되지 않는다. 다음 질문(넥스트 키 락)으로 이어짐.

Q. InnoDB는 Repeatable Read만으로 팬텀 리드를 어떻게 해결하나요?

핵심 답변 (골드 수준)

InnoDB는 **레코드 락과 갭 락(Gap Lock)을 합친 넥스트 키 락(Next-Key Lock)**을 사용한다.

예를 들어 다음 쿼리를 실행하면:

SELECT * FROM t WHERE id = 5 FOR UPDATE;

id가 5인 레코드뿐만 아니라 5의 전후 갭(5보다 작은 쪽, 5보다 큰 쪽 범위)에 대해서도 락이 걸린다. 그래서 다른 트랜잭션이 해당 범위에 데이터를 추가하거나 수정할 수 없게 되어 팬텀 리드가 방지된다.

팬텀 리드 자체를 정확히 이해하고 답변하는 면접자가 많지 않아서, 여기를 명확하게 답변하면 트랜잭션을 좋아하는 면접관 눈에 확 띈다.

핵심 키워드: ① 넥스트 키 락 = 레코드 락 + 갭 락 ② 예시와 함께 설명하는 전후 갭

답변 레벨 차이

꼬리 질문

• 여기까지가 트랜잭션 섹션의 마지막 꼬리. 트랜잭션 정의·ACID → 실무 주의점 → 격리 수준 종류 → 격리 수준별 문제 → 해결 메커니즘 → MVCC → 넥스트 키 락으로 이어지는 하나의 흐름을 통째로 기억할 것.

섹션 3. 락과 동시성 제어

Q. DB 락이란 무엇이고 어떤 종류가 있나요?

핵심 답변 (골드 수준)

DB 락은 여러 트랜잭션의 공유 데이터에 대한 액세스를 제어하기 위해 사용되는 메커니즘이다.

• 공유 락(Shared Lock): 여러 트랜잭션이 동시에 동일 데이터를 읽을 수 있지만, 락이 해제될 때까지 수정은 불가능하다.
• 배타 락(Exclusive Lock): 락이 해제될 때까지 다른 트랜잭션이 읽기와 수정 모두 불가능하다.

"충돌을 막는다"는 결과이고 "액세스를 제어한다"는 메커니즘이다. 이 표현을 쓰면 락의 목적까지 이해하고 있음을 보여줄 수 있다.

핵심 키워드: ① 액세스 제어 ② 공유 락 ③ 배타 락 (각각 정확한 맥락과 함께)

답변 레벨 차이

꼬리 질문

• "낙관적 락과 비관적 락의 차이는요?" → 공유 락/배타 락 다음으로 거의 항상 따라오는 질문.

Q. 낙관적 락과 비관적 락의 차이는 무엇인가요?

핵심 답변 (골드 수준)

• 비관적 락(Pessimistic Lock): 동시성 충돌이 발생할 것으로 보고, 자원에 접근할 때 SELECT ... FOR UPDATE로 락을 걸어 선점하는 방식이다. DB단에서 동작하므로 예외 시 자동으로 롤백된다. 충돌이 많을 때 적합하다.
• 낙관적 락(Optimistic Lock): 자원을 미리 선점하지 않고, 변경할 때 버전을 확인하여 동시성을 제어하는 Compare-and-Set 방식이다. 애플리케이션단에서 구현하며 예외 시 직접 롤백을 구현해야 한다. 충돌이 적을 때 적합하다.

구현 레이어(DB단 vs 애플리케이션단)의 구분이 중요한 이유는 예외가 발생했을 때 롤백을 누가 처리하느냐가 달라지기 때문이다. DB단은 자동 롤백, 애플리케이션단은 직접 구현이다.

핵심 키워드: ① 비관적 락 ② 낙관적 락 ③ 구현 레이어의 차이(롤백 주체) ④ 충돌 빈도

답변 레벨 차이

꼬리 질문

• "구체적으로 어떤 기준으로 선택하나요?" → "충돌이 많다/적다"는 수치가 아니라 애매하므로 높은 확률로 이어지는 질문.

Q. 낙관적 락과 비관적 락은 구체적으로 어떤 기준으로 선택하나요?

핵심 답변 (골드 수준)

• 충돌이 드물고, 트랜잭션 롤백 및 재시도 비용이 낮다면 낙관적 락을 사용한다. 특히 임계 영역이 짧아서 충돌 확률 자체가 낮은 경우에 적합하다.
• 반대로 충돌이 빈번하거나 임계 영역이 길어서 재시도 비용이 커진다면 비관적 락으로 아예 선점하는 것이 효율적이다.

즉 판단 기준은 충돌 빈도 하나가 아니라 임계 영역의 길이와 재시도 비용까지 포함된다. 임계 영역이 길면 재시도 한 번의 비용이 크기 때문에, 충돌이 적더라도 오히려 비관적 락이 나을 수 있다.

보충: 충돌 빈도는 임계 영역의 길이 외에 비즈니스 맥락에 따라서도 다르다. 선착순 상품 구매는 짧은 시간에 요청이 쏟아지지만, 블로그 포스팅 같은 요청은 비교적 골고루 들어온다. 이런 맥락을 곁들이면 더 좋다.

강사 실무 사례: 충돌이 잦은 로직에 낙관적 락을 적용했더니 재시도 횟수를 넘겨 일부 요청이 유실된 적이 있다. 락 선택 하나가 데이터 유실로 이어질 수 있다.

핵심 키워드: ① 충돌 빈도 ② 임계 영역의 길이 ③ 충돌과 임계 영역의 관계 (+비즈니스 맥락)

답변 레벨 차이

꼬리 질문

• "DB 바깥의 자원까지 제어해야 하면 어떻게 하나요?" → 비관적 락은 해당 DB 안의 로우만 잠글 수 있으므로 자연스럽게 분산락으로 이어짐.

Q. 분산락이란 무엇이고 언제 사용하나요?

핵심 답변 (골드 수준)

DB의 비관적 락은 해당 DB 안의 로우만 잠글 수 있다. 하지만 실무에서는 재고를 차감한 뒤 외부 결제 API를 호출한다거나, 캐시와 DB를 동시에 갱신해야 하는 것처럼 하나의 DB 트랜잭션으로 묶을 수 없는 자원들을 함께 제어해야 하는 경우가 많다. 이럴 때 Redis 같은 중앙 저장소에 락을 걸어 DB 바깥까지 포함한 동시성을 제어하는 것이 분산락이다.

핵심은 "DB가 여러 대라서"가 아니다. DB(예: MySQL 인스턴스)가 한 대여도 DB 바깥에 자원이 있으면 분산락이 필요하다. 출발점을 "비관적 락의 범위 한계"에서 잡아야 한다.

핵심 키워드: ① DB 트랜잭션 범위의 한계 ② 비관적 락과 분산락의 범위 차이(DB 안의 로우 vs DB 바깥까지 포함한 자원)

답변 레벨 차이

꼬리 질문

• 분산락 답변 후 **"분산락은 무엇이고 왜 사용하나요?"**를 더 깊게 파고들 수 있다. 다음 메인 질문은 동시성 문제 자체(Lost Update Problem)로 넘어간다.

Q. Lost Update Problem이란 무엇이고 왜 트랜잭션 격리 수준으로 해결하지 못하나요?

관련 노트: isolation

핵심 답변 (골드 수준)

Lost Update Problem은 Read-Modify-Write 사이클에서 발생한다. 값을 SELECT로 읽고, 애플리케이션에서 계산한 뒤, UPDATE로 쓸 때 두 트랜잭션이 동시에 이 사이클을 수행하면 두 번째 쓰기가 첫 번째 변경을 포함하지 않게 된다.

예를 들어 잔액 1,000원을 두 트랜잭션이 동시에 읽고 하나는 +500, 하나는 +300을 하면, 최종 잔액이 1,800원이 아니라 1,500원 또는 1,300원이 될 수 있다.

트랜잭션 격리 수준은 더티 리드, 논리피터블 리드 같은 읽기 관련 동시성 문제는 방지할 수 있지만, Lost Update Problem 같은 쓰기 관련 동시성 문제는 해결할 수 없다. 격리 수준이 커버하는 범위와 커버하지 못하는 범위를 나눠서 답하는 것이 핵심이다.

핵심 키워드: ① Read-Modify-Write ② 잔액 숫자 예시 ③ 읽기 관련 vs 쓰기 관련 동시성 문제의 구분

답변 레벨 차이

꼬리 질문

• "그렇다면 Lost Update Problem은 어떻게 해결하나요?" → 다음 질문.

Q. Lost Update Problem은 어떻게 해결하나요?

핵심 답변 (골드 수준)

낙관적 락이나 비관적 락을 사용하여 해결할 수 있다. 더 나아가, SELECT한 변수를 UPDATE문에 사용하는 것이 아니라 원자적 쓰기 연산 하나로 처리하는 방법이 있다.

UPDATE accounts SET balance = balance + 100 WHERE id = 1;

이렇게 UPDATE문 하나로 처리하면 읽기와 쓰기가 분리되지 않으므로 Read-Modify-Write 패턴 자체가 사라져 Lost Update Problem이 원천적으로 발생하지 않는다. 이때 DB가 자체적으로 묵시적 배타 락을 획득하여 쓰기 충돌을 방지하고, MVCC 덕분에 다른 트랜잭션의 읽기는 차단되지 않는다.

핵심 키워드: ① 낙관적 락 / 비관적 락 ② 원자적 쓰기 연산(UPDATE문을 통한 묵시적 배타 락) — 특히 후자를 반드시 기억할 것

답변 레벨 차이

꼬리 질문

• 섹션 마무리. 락의 정의와 종류 → 낙관적/비관적 락 → 선택 기준 → 분산락 → Lost Update Problem 정의와 해결의 흐름을 하나로 기억할 것.

섹션 4. 인덱스

Q. 인덱스란 무엇이고 장단점을 설명해 주세요

핵심 답변 (골드 수준)

인덱스는 DBMS의 저장 성능을 희생하고 검색 성능을 높이기 위해 만들어진 자료 구조다.

• 장점: 테이블 조회 속도와 성능을 향상시키고 시스템 부하를 줄일 수 있다.
• 단점: DB의 약 10% 정도 추가 저장 공간이 필요하고, INSERT/UPDATE/DELETE가 빈번한 컬럼에 인덱스를 걸면 오히려 성능이 저하된다. UPDATE와 DELETE는 기존 인덱스를 삭제하지 않고 "사용하지 않음" 처리를 하기 때문에 인덱스가 비대해질 수 있다.

핵심 키워드: ① 저장 성능 희생 ↔ 검색 성능 향상 트레이드오프 ② "사용하지 않음" 처리 ③ 약 10% 저장 공간

답변 레벨 차이

꼬리 질문

• "그 자료 구조가 어떻게 되나요? 왜 해시 테이블이 아니라 B-Tree를 쓰나요?" → 다음 질문.

Q. 인덱스는 왜 해시 테이블이 아니라 주로 B-Tree를 사용하나요?

핵심 답변 (골드 수준)

해시 테이블 내의 데이터는 정렬되어 있지 않으므로 부등호 연산이 불가능하다. 인덱스 특성상 기준 값보다 크거나 작은 요소를 탐색하는 범위 검색이 많기 때문에 B-Tree를 사용한다.

다만 **등호(=) 연산만 사용되는 경우에는 해시 인덱스가 B-Tree보다 훨씬 좋은 성능(O(1))**을 낼 수 있다. 이 트레이드오프를 함께 말해야 양쪽을 다 아는 사람이 된다.

부록 — 같은 균형 트리인 레드-블랙 트리가 아니라 왜 B-Tree인가?

• 레드-블랙 트리는 데이터를 찾기 위해 루트부터 자식 노드로 포인터를 따라 계속 내려간다. 각 노드가 메모리상에 흩어져 있을 확률이 높아 매 이동마다 메모리 접근 오버헤드가 발생하고, 트리 깊이가 상대적으로 깊어 더 많은 포인터 연산이 필요하다.
• B-Tree는 하나의 큰 노드(페이지) 안에 여러 값을 정렬된 배열 형태로 담는다. 노드 내부에서는 포인터 연산 없이 배열 인덱스로 빠르게 키를 비교·접근할 수 있고, 한 번에 더 많은 데이터를 메모리에 올릴 수 있으며 트리 깊이가 얕아 포인터 연산 횟수가 줄어든다.

핵심 키워드: ① 해시의 한계(부등호 연산 불가) ② B-Tree 선택 이유(범위 검색) ③ B-Tree vs 해시 트레이드오프(등호 연산은 해시가 우위)

답변 레벨 차이

꼬리 질문

• "그러면 인덱스가 B-Tree 방식으로 구체적으로 어떻게 동작하나요?" → 다음 질문.

Q. 인덱스는 B-Tree 방식으로 구체적으로 어떻게 동작하나요?

핵심 답변 (골드 수준)

B-Tree 자료 구조를 사용해서, 검색할 값을 루트 노드에서부터 비교를 시작해 브랜치 노드를 거치고 최종적으로 리프 노드까지 찾아 들어간다. 그리고 리프 노드의 레코드 주소를 사용하여 실제 데이터 파일에 존재하는 레코드를 읽는다.

탐색은 "루트 → 브랜치 → 리프"의 3단계이고, 마지막에 레코드 주소로 데이터 파일을 읽는 단계까지 말해야 탐색 과정이 완성된다.

핵심 키워드: ① 루트 → 브랜치 → 리프 탐색 ② 리프 노드의 레코드 주소로 데이터 파일 접근

답변 레벨 차이

꼬리 질문

• "클러스터링 인덱스와 비클러스터링 인덱스의 차이는요?" → 리프 노드에 무엇이 저장되어 있는지는 인덱스 종류에 따라 다르므로 자연스럽게 이어짐.

Q. 클러스터링 인덱스와 비클러스터링 인덱스의 차이는 무엇인가요?

핵심 답변 (골드 수준)

• 클러스터링 인덱스: PK에 적용되며, PK 값에 의해 레코드의 물리적 저장 위치가 결정된다. 리프 노드의 레코드에 모든 컬럼이 저장된다.
• 비클러스터링 인덱스(세컨더리 인덱스): PK 외 컬럼에 적용되며, 리프 노드에 해당 레코드의 PK만 존재한다. 따라서 비클러스터링 인덱스로 검색하면 PK를 얻은 뒤 다시 클러스터링 인덱스를 탐색해야 한다.

"PK 순서로 정렬 저장"이 아니라 "PK 값에 의해 물리적 저장 위치가 결정된다"가 클러스터링 인덱스의 본질이다. 그리고 리프 노드 저장 내용의 차이(모든 컬럼 vs PK만)를 알아야 왜 비클러스터링 인덱스가 재탐색을 필요로 하는지 원리로 설명할 수 있다.

핵심 키워드: ① 클러스터링 인덱스(물리적 저장 위치) ② 비클러스터링 인덱스 ③ 리프 노드 저장 내용의 차이(모든 컬럼 vs PK만)

답변 레벨 차이

꼬리 질문

• "InnoDB에서 구체적으로 어떻게 동작하나요?" → 2단계 검색 구조. 다음 질문.

Q. InnoDB에서 인덱스 검색은 구체적으로 어떻게 동작하나요? (2단계 검색)

핵심 답변 (골드 수준)

비클러스터링 인덱스의 리프 노드에는 해당 레코드의 PK만 존재한다. 이 PK를 이용하여 클러스터링 인덱스를 다시 탐색한다. 클러스터링 인덱스의 리프 노드에는 해당 PK에 대응되는 레코드의 모든 정보가 들어있으므로, 이 2단계 검색을 통해 최종 데이터를 가져온다.

앞 질문과 거의 같은 내용이지만, 면접관이 굳이 "InnoDB에서"라고 다시 묻는 것은 방금 답변한 구조가 MySQL(InnoDB) 기준임을 알고 말한 것인지 검증하는 차원이다. PK에 따라 물리적 위치가 재배열되는 구조를 갖지 않는 DB도 있기 때문이다.

부록 — PostgreSQL의 인덱스 구조: PostgreSQL 인덱스는 클러스터링 구조가 없고, 항상 리프 노드에 실제 데이터 파일의 위치를 담고 있는 TID 값만 있다. B-Tree 인덱스 리프 노드의 키와 TID를 통해 실제 데이터 스토리지의 디스크를 조회하여 데이터를 탐색한다. 즉 PostgreSQL은 검색 과정이 항상 이 방식 하나로 통일되어 있다. (인덱스 동작 → 클러스터링/비클러스터링 차이 → InnoDB 동작 흐름이 데브시스터즈 면접에서 그대로 나온 적이 있다.)

핵심 키워드: ① 클러스터링 인덱스를 다시 탐색한다는 명시적 경로 ② "2단계 검색"이라는 구조적 명칭

답변 레벨 차이

꼬리 질문

• 다음 메인 질문(복합 인덱스)으로 이어진다. 인덱스 구조 파트 완성: 정의 → B-Tree 선택 이유 → 동작 방식 → 클러스터링/비클러스터링 → InnoDB 2단계 검색 → (부록) PostgreSQL.

Q. 복합 인덱스 사용 시 주의할 점은 무엇인가요?

핵심 답변 (골드 수준)

복합 인덱스에서 두 번째 컬럼은 첫 번째 컬럼에 의존해서 정렬되어 있으므로 컬럼 순서가 중요하다.

• 등호(=) 조건처럼 조회되는 데이터 개수가 적은 컬럼을 앞에, 범위 검색 컬럼을 뒤에 배치하는 것이 좋다.
• 또한 복합 인덱스는 단일 컬럼 인덱스보다 INSERT/UPDATE/DELETE가 더 비효율적이므로, 가급적 변경이 적은 컬럼을 선택하는 것이 좋다.

"카디널리티가 높은 컬럼을 앞에"에서 멈추지 말고, 두 번째 컬럼의 정렬이 첫 번째 컬럼에 의존한다는 원리를 먼저 말해야 한다. 이 원리를 알면 등호 조건을 앞에 두는 이유도 자연스럽게 따라온다. (최근 네이버 채용 과정에서 나온 질문)

핵심 키워드: ① 두 번째 컬럼은 첫 번째 컬럼에 의존해 정렬 ② 등호 조건 앞 / 범위 검색 뒤 ③ 변경이 적은 컬럼

답변 레벨 차이

꼬리 질문

• "동료가 불 타입 컬럼에 인덱스를 건다면 어떤 의견을 내시겠어요?" → 응용 질문. 다음 섹션.

Q. 동료가 불(bool) 타입 컬럼에 인덱스를 건다면 어떤 의견을 내시겠어요?

핵심 답변 (골드 수준)

불 타입은 키가 true/false 두 가지뿐이어서 한쪽을 조회하면 **리프 노드가 전체 데이터의 약 50%**가 된다. 인덱스 레인지 스캔은 랜덤 I/O를 사용하므로, 전체 데이터의 20~30% 이상을 읽을 때는 순차 I/O를 사용하는 풀 스캔이 더 효율적이다. 따라서 인덱스 효과가 없을 가능성이 크다는 의견과 함께, EXPLAIN으로 실제 실행 계획을 확인해서 근거를 마련하자고 제안하겠다.

"카디널리티가 낮아서 안 좋다"는 결론이지 근거가 아니다. 인덱스의 I/O 방식(랜덤)과 풀 스캔의 I/O 방식(순차)이 다르다는 것이 핵심 근거다. (과거 당근 신입 과정 출제 질문)

핵심 키워드: ① 불 타입은 전체 데이터의 50% ② 랜덤 I/O vs 순차 I/O (20~30% 기준) ③ EXPLAIN으로 검증

답변 레벨 차이

꼬리 질문

• LIKE 검색과 인덱스 관계로 이어짐(다음 질문).

Q. LIKE 'xxx%'는 인덱스를 타는데 '%xxx%'는 왜 인덱스를 타지 않나요?

핵심 답변 (골드 수준)

B-Tree 인덱스는 왼쪽 값을 기준으로 오른쪽이 정렬되어 있다.

-- 인덱스 사용 가능: 시작 값이 고정되어 정렬 순서를 활용할 수 있음
SELECT * FROM users WHERE name LIKE '김%';

-- 인덱스 사용 불가: 와일드카드가 앞에 붙어 시작점을 특정할 수 없음
SELECT * FROM users WHERE name LIKE '%김%';

LIKE 'xxx%'는 시작 값이 고정되어 있어 인덱스의 정렬 순서를 활용할 수 있지만, '%xxx%'는 와일드카드가 앞에 붙어 탐색의 시작점을 특정할 수 없으므로 인덱스를 활용할 수 없다. (이력서에 검색 관련 키워드가 있으면 매우 높은 확률로 나오는 질문)

핵심 키워드: ① 왼쪽 기준으로 오른쪽 정렬이라는 B-Tree 원리 ② 정렬 원리와 LIKE의 관계(시작 값 고정 → 탐색 가능 / 시작 값 불특정 → 불가능)

답변 레벨 차이

꼬리 질문

• "그러면 키워드 검색('%xxx%')은 RDB에서 못 하나요?" → 검색 도메인의 시작점. RDB의 전문 검색 인덱스(Full-Text Index), Elasticsearch의 역 인덱스(Inverted Index) 개념을 공부할 것 (강의에서는 섹션 8 부록 PDF로 제공).

섹션 5. NoSQL과 RDBMS 비교

Q. RDBMS와 NoSQL의 차이를 설명해 주세요. 언제 각각을 사용하나요?

핵심 답변 (골드 수준)

• RDBMS: 명확한 스키마를 가지며 트랜잭션과 조인이 강력하다. 데이터 구조가 명확하고 변경이 빈번하며 관계형 데이터를 다룰 때 적합하다.
• NoSQL: 느슨한 스키마로 **유연성과 수평 확장(스케일아웃)**에 강하다. 스키마가 불명확하거나, 대용량 데이터를 저장하고, 조인이 적고 변경이 적은 데이터에 적합하다.

RDBMS의 진짜 강점은 스키마보다 조인이고, NoSQL의 근본 특성은 유연함보다 조인이 없는 구조라는 점이다. 이 근본 차이를 알아야 나머지 차이들이 왜 생기는지 설명할 수 있다.

핵심 키워드: ① RDBMS — 트랜잭션과 조인 ② NoSQL — 유연성·스케일아웃 ③ 선택 기준의 핵심 = 조인

답변 레벨 차이

꼬리 질문

• "데이터 모델링 관점에서 설계 방식이 어떻게 다른가요?" → 다음 질문.

Q. 데이터 모델링 관점에서 RDBMS와 NoSQL의 설계 방식은 어떻게 다른가요?

핵심 답변 (골드 수준)

• RDBMS는 데이터 중심으로 설계한다. 먼저 정규화하여 중복을 제거하고, 이후에 어떤 쿼리든 조인으로 대응할 수 있다.
• NoSQL은 액세스 패턴 중심으로 설계한다. 어떤 쿼리를 날릴 것인가를 먼저 정의하고, 그에 맞게 비정규화하여 데이터를 저장한다. 조인이 없으므로 필요한 데이터를 한 번의 조회로 가져올 수 있도록 설계하는 것이 핵심이다.

저장 방식이 다른 것(정규화 vs 문서에 모아 저장)은 결과이고, **설계 순서가 다르다는 것(데이터부터 vs 쿼리부터)**이 원인이다.

핵심 키워드: ① RDBMS = 데이터 중심 설계 ② NoSQL = 액세스 패턴 중심 설계 (한 번의 조회 → 비정규화의 이유)

답변 레벨 차이

꼬리 질문

• "그러면 RDBMS에서도 스케일아웃이 가능한가요?" → 다음 질문.

Q. RDBMS에서도 스케일아웃이 가능한가요?

핵심 답변 (골드 수준)

가능하다. 다만 비용이 크다.

• 읽기 확장: 리드 레플리카를 추가하여 가능하다. 쓰기는 마스터가 담당하고, 읽기 트래픽을 여러 레플리카로 분산시키는 방식이다.
• 쓰기 확장: 샤딩으로 가능하지만, 조인과 트랜잭션이 여러 샤드에 걸치게 되면 구현이 매우 복잡해진다.

그래서 "RDBMS의 스케일아웃은 불가능한 건 아니지만 비용이 크다"가 정확한 표현이다.

핵심 키워드: ① 읽기 확장 = 리드 레플리카 ② 쓰기 확장 = 샤딩(조인·트랜잭션 복잡성)

답변 레벨 차이

꼬리 질문

• "그러면 NoSQL은 왜 스케일아웃에 좋은 건가요?" → 다음 질문.

Q. NoSQL은 왜 스케일아웃에 유리한가요?

핵심 답변 (골드 수준)

RDBMS는 테이블 간 관계로 인해 복잡한 조인이 수반되어 샤딩 구현이 어렵다. 반면 NoSQL은 집합 지향 모델이라 연관 데이터가 함께(한 덩어리로) 저장되어 있어 다른 샤드에서 조인할 필요가 없고, DB 자체에서 샤딩을 효과적으로 지원하기 때문에 스케일아웃에 유리하다.

연관 데이터가 한 덩어리로 있으니 샤드를 나눠도 다른 샤드를 참조할 필요가 없다 — 이것이 "왜 쉬운지"의 근본 이유다. RDBMS의 한계(조인 때문에 어려움)와 대비 구조로 설명하면 앞의 학습 내용이 자연스럽게 연결된다.

핵심 키워드: ① 집합 지향 모델 ② 조인 유무와 샤딩 난이도의 관계

답변 레벨 차이

꼬리 질문

• (흐름 전환) "MySQL과 PostgreSQL은 어떤 차이가 있나요?" → RDBMS 간 비교. 다음 질문.

Q. MySQL과 PostgreSQL은 어떤 차이가 있나요?

핵심 답변 (골드 수준)

크게 네 가지 차이가 있다. 비교 질문은 이렇게 개수를 먼저 말하고 하나씩 짚는 것이 효과적이다.

1. 기본 트랜잭션 격리 수준: MySQL은 REPEATABLE READ, PostgreSQL은 READ COMMITTED다.
2. 인덱스 구조: MySQL InnoDB는 PK가 클러스터링 인덱스이고 리프 노드에 데이터가 저장되지만, PostgreSQL은 리프 노드에 위치 식별자인 TID만 저장한다.
3. 스키마 구조: MySQL은 DB 아래 바로 테이블이 만들어지지만, PostgreSQL은 DB → 스키마 → 테이블 구조로 권한 그룹화가 용이하다.
4. MVCC 구현: MySQL은 언두 로그를 사용하고, PostgreSQL은 원본에 마킹 후 새 레코드를 추가하는 MGA(Multi-Generation Architecture) 방식이다.

앞 섹션에서 배운 격리 수준, 클러스터링 인덱스, MVCC 개념이 여기서 다시 연결된다.

핵심 키워드: ① 격리 수준 ② 인덱스 ③ 스키마 구조 ④ MVCC

답변 레벨 차이

꼬리 질문

• 다음 메인 질문 CAP 이론으로 전환.

Q. CAP 이론이 무엇인가요?

핵심 답변 (골드 수준)

분산 시스템은 일관성(Consistency), 가용성(Availability), 분할 내성(Partition tolerance) 세 가지를 모두 만족할 수 없다는 이론이다.

핵심은 그 다음이다. 실제로 네트워크 분단은 피할 수 없는 결함이므로 P는 사실상 필수이고, 결국 C와 A 중 하나를 선택하는 문제가 된다. CP는 MongoDB처럼 일관성을 우선하고, AP는 Cassandra처럼 가용성을 우선한다.

세 가지 중 하나를 못 고르는 것은 셋이 동등해서가 아니라 P는 빠질 수 없기 때문이다 — 이 구분이 있어야 CAP를 외운 게 아니라 이해한 것이 된다.

핵심 키워드: ① C/A/P의 개념 ② P는 사실상 필수(네트워크 분단은 피할 수 없는 결함) ③ 결국 C와 A 중 선택

답변 레벨 차이

꼬리 질문

• "실무에서 C와 A는 어떤 기준으로 선택하나요?" → 다음 질문.

Q. 실무에서 C(일관성)와 A(가용성)는 어떤 기준으로 선택하나요?

핵심 답변 (골드 수준)

데이터 불일치가 비즈니스에 얼마나 치명적인가로 판단한다.

• 결제나 재고처럼 불일치 시 금전 손실이 발생하는 도메인은 CP를 택해 일관성을 우선한다.
• 반면 SNS 좋아요 수나 추천 피드처럼 잠깐 뒤처져도 비즈니스 영향이 적은 도메인은 AP를 택해 가용성을 우선하고, **Eventual Consistency(최종적 일관성)**로 시간이 지나면 모든 노드가 동기화되도록 한다.
• 다만 Eventual Consistency는 언제 수렴되는지 보장하지 않으므로 즉시 정합성이 필요한 곳에는 적합하지 않다.

"중요한 데이터"는 주관이고 "금전 손실이 발생하는가"는 상대적으로 객관적인 기준이다. 이 기준이 있으면 어떤 도메인이든 판단할 수 있다. AP를 택한다고 일관성을 완전히 포기하는 것이 아니라는 점(Eventual Consistency), 그리고 그 한계까지 짚어야 한다. Eventual Consistency는 어떤 분산 시스템 책에서도 빠지지 않는 키워드이므로 반드시 학습할 것.

핵심 키워드: ① 비즈니스 임팩트(금전 손실 여부)라는 판단 기준 ② Eventual Consistency 개념 ③ Eventual Consistency의 한계(수렴 시점 미보장)

답변 레벨 차이

꼬리 질문

• 섹션 마무리. RDBMS/NoSQL 차이 → 설계 방식 → 스케일아웃 → MySQL/PostgreSQL → CAP → C/A 선택 기준의 흐름.

섹션 6. 커넥션과 커넥션 풀

Q. DB 커넥션이란 무엇이고 생성 비용이 큰 이유는 무엇인가요?

핵심 답변 (골드 수준)

DB 커넥션은 DB를 사용하기 위해 애플리케이션과 DB 간 통신을 할 수 있는 수단이다. 커넥션 생성 비용이 큰 이유는 크게 세 가지다.

1. TCP 3-way 핸드셰이크로 네트워크 왕복이 발생한다.
2. TCP 연결 위에서 인증·권한 확인을 거쳐야 한다.
3. DB가 해당 커넥션을 위한 세션을 초기화해야 한다.

매 요청마다 이 과정을 반복하면 응답 시간이 크게 늘어난다. 이 마지막 한 줄이 있어야 커넥션 풀이 왜 필요한지로 자연스럽게 이어진다.

핵심 키워드: ① TCP 핸드셰이크 ② 인증·권한 확인 ③ 세션 초기화

답변 레벨 차이

꼬리 질문

• "그러면 어떻게 해결하나요?" → 커넥션 풀. 다음 질문.

Q. 커넥션 풀이란 무엇이고 왜 사용하나요?

핵심 답변 (골드 수준)

일정량의 커넥션 객체를 미리 만들어서 풀에 저장해 두고, 요청 시 빌려주고 완료 후 반납받는 기법이 커넥션 풀이다. 사용하는 이유는 두 가지다.

1. 비용 절감: DB 커넥션은 TCP 연결 등 비용이 큰 작업이므로 재사용으로 비용을 절감한다.
2. 자원 고갈 방지: 커넥션 수를 제한하여 과도한 접속으로 인한 서버 자원 고갈을 방지한다.

커넥션 풀은 미리 만들어서 빠르게 쓰는 것(성능)만이 아니라, 상한선을 정해 시스템을 보호하는 역할(안정성)도 한다. 이 표현이 있으면 운영 관점도 이해하고 있다는 인상을 준다.

핵심 키워드: ① 풀에 저장·빌려주고·반납하는 기법 ② 비용 절감 ③ 자원 고갈 방지

답변 레벨 차이

꼬리 질문

• "커넥션 풀 크기는 클수록 좋은가요?" → 다음 질문.

Q. 커넥션 풀 크기는 클수록 좋은가요?

핵심 답변 (골드 수준)

아니다. 커넥션을 사용하는 주체는 스레드이므로 스레드 풀과 함께 고려해야 한다.

• 스레드 풀보다 커넥션 풀이 크다면 남는 커넥션은 메모리 낭비다.
• 둘 다 늘리면 컨텍스트 스위칭 오버헤드가 커진다.
• 또한 DB는 하드디스크 하나당 하나의 I/O를 처리하므로 디스크 병목이 발생하여, 특정 시점부터는 커넥션을 아무리 늘려도 성능 향상이 미미하다.

메모리·컨텍스트 스위칭은 애플리케이션단의 한계, 디스크 병목은 DB단의 물리적 한계다. 양쪽을 함께 말하면 좋다.

강사 실무 사례: 커넥션 풀 사이즈를 크게 잡은 상태에서 애플리케이션 서버가 계속 스케일아웃되자, DB 서버가 동시에 제공할 수 있는 커넥션 수를 넘어 DB 레벨 장애가 발생한 적이 있다.

핵심 키워드: ① 스레드 풀과 커넥션 풀의 관계 ② 컨텍스트 스위칭 ③ 디스크 병목

답변 레벨 차이

꼬리 질문

• 운영 관점 전환: "커넥션 타임아웃과 리드 타임아웃의 차이는요?" → 다음 질문.

Q. 커넥션 타임아웃과 리드 타임아웃의 차이는 무엇이고, 타임아웃은 왜 필요한가요?

핵심 답변 (골드 수준)

• 커넥션 타임아웃: DB 서버와의 연결 자체를 맺지 못할 때 발생한다. (연결 실패)
• 리드 타임아웃: 연결은 맺었지만 쿼리 결과를 받지 못할 때 발생한다. (응답 지연)

타임아웃을 설정하지 않으면 스레드와 커넥션이 무한 대기 상태로 점유되어 반환되지 않고, 이것이 쌓이면 커넥션 풀이 고갈되어 전체 서비스 장애로 이어질 수 있기 때문에 필요하다.

"무한 대기 방지"에서 끝내지 말고 "스레드·커넥션 점유 → 반환되지 않음 → 커넥션 풀 고갈 → 전체 장애"라는 연쇄 과정을 보여줘야 한다. 타임아웃이 없으면 커넥션 풀의 자원 고갈 방지 장치가 무력화된다. (토스 면접 꼬리 질문 출제 이력)

핵심 키워드: ① 커넥션 타임아웃 ② 리드 타임아웃 ③ 타임아웃 미설정의 연쇄적 결과

답변 레벨 차이

꼬리 질문

• "커넥션 풀 상태를 어떻게 모니터링하고 문제를 어떻게 진단하나요?" → 다음 질문.

Q. 커넥션 풀 상태를 어떻게 모니터링하고 문제를 어떻게 진단하나요?

핵심 답변 (골드 수준)

HikariCP 기준으로 active(사용 중), idle(대기 중), pending(대기열) 커넥션 수를 Micrometer 메트릭으로 수집하여 Grafana 대시보드에서 모니터링한다. active가 maximumPoolSize에 근접하면 커넥션 부족 경고를 설정한다.

문제 발생 시 SHOW PROCESSLIST로 DB 세션 상태를 확인하고, 슬로우 쿼리나 락 경합으로 커넥션이 오래 점유되고 있는지 진단한다. 또한 leakDetectionThreshold 설정으로 커넥션을 빌려가고 반납하지 않는 커넥션 누수(leak)도 감지한다.

도구를 아는 것과 도구로 무엇을 봐야 하는지를 아는 것은 완전히 다르다. 구체적 메트릭과 임계 경고 수준까지 말하면 "실제로 대시보드를 본 사람"이라는 인상을 준다.

핵심 키워드: ① active/idle/pending 메트릭 ② SHOW PROCESSLIST ③ leakDetectionThreshold

답변 레벨 차이

꼬리 질문

• 섹션 마무리. 커넥션 정의·비용 → 커넥션 풀 → 풀 크기 → 타임아웃 → 모니터링·진단의 흐름.

섹션 7. 운영

Q. 운영 중 슬로우 쿼리가 발생하면 어떻게 대처하나요?

핵심 답변 (골드 수준)

단계별로 답한다.

1. 슬로우 쿼리 로그를 활성화하여 문제 쿼리를 식별한다.
2. EXPLAIN으로 실행 계획을 분석하여 풀 스캔이나 비효율적 조인을 찾는다.
3. 인덱스 추가나 쿼리 리팩토링으로 개선한다.
4. 그래도 안 되면 테이블 구조 변경이나 캐싱 도입을 검토한다.

"EXPLAIN 쓰고 인덱스 걸면 됩니다"로 끝나면 도구 하나만 아는 사람이다. 발견 → 분석 → 조치 → 후속 대응의 흐름을 보여줘야 하고, 인덱스가 만능이 아님을 아는 것(4단계)이 차이를 만든다.

핵심 키워드: ① 슬로우 쿼리 로그 ② EXPLAIN ③ 인덱스 추가·쿼리 리팩토링 ④ 테이블 구조 변경·캐싱 도입

답변 레벨 차이

꼬리 질문

• "EXPLAIN에서 구체적으로 뭘 봐야 하나요?" → 다음 질문.

Q. EXPLAIN에서 구체적으로 무엇을 봐야 하나요?

핵심 답변 (골드 수준)

네 가지 컬럼을 함께 확인한다.

• type: ALL인지(풀 스캔), ref/range인지(인덱스 사용) 확인한다.
• rows: 예상 스캔 행 수가 과도하지 않은지 본다. type이 ALL이 아니어도 rows가 비정상적으로 높으면 문제일 수 있다.
• key: 실제 사용된 인덱스를 확인한다.
• Extra: Using filesort(정렬을 인덱스로 처리하지 못해 파일 정렬 사용), Using temporary(임시 테이블 생성) 같은 비효율적 연산이 있는지 확인한다.

type 하나만 아는 것은 도구의 10%만 쓰는 것이다. rows라는 정량 지표와 Extra의 비효율 연산까지 봐야 EXPLAIN을 제대로 쓴다고 할 수 있다.

핵심 키워드: ① type ② rows ③ key ④ Extra

답변 레벨 차이

꼬리 질문

• "쿼리 하나가 아니라 데이터 자체가 많아져서 느려지면 어떻게 하나요?" → 다음 질문.

Q. 데이터 자체가 많아져서 느려지면 어떻게 해결하나요?

핵심 답변 (골드 수준)

먼저 쿼리 레벨에서 해결한다. 인덱스 최적화로 풀 스캔을 제거하고, 쿼리 튜닝으로 조인이나 서브쿼리를 개선한다.

그래도 안 되면 병목 원인에 따라 전략을 선택한다.

• 조회 범위가 넓으면 → 파티셔닝으로 스캔 범위를 줄인다.
• 안 쓰는 데이터가 테이블을 비대하게 만들면 → 아카이빙으로 분리한다.
• 읽기 부하가 문제면 → 캐싱이나 리플리케이션을 도입한다.
• 쓰기 처리량 자체가 한계면 → 최종적으로 샤딩을 고려한다.

전부 외울 필요는 없고, "쿼리 레벨 먼저 + 원인에 따라 다르다"는 프레임을 아는 것이 중요하다. 인프라를 건드리기 전에 쿼리부터 최적화하는 우선순위가 체계적인 접근의 신호다.

핵심 키워드: ① 쿼리 레벨 먼저 ② 병목 원인별 전략 선택(파티셔닝/아카이빙/캐싱·리플리케이션/샤딩)

답변 레벨 차이

꼬리 질문

• 다음 메인 질문(인프라 구조: 클러스터링/리플리케이션/샤딩)으로 전환.

Q. 클러스터링, 리플리케이션, 샤딩의 차이를 설명해 주세요

핵심 답변 (골드 수준)

셋 다 서버를 여러 대 두지만 목적과 구조가 전혀 다르며, 각각의 트레이드오프까지 말해야 한다.

• 클러스터링: 하나의 DB 스토리지를 두고 여러 대의 DB 서버를 묶는 방식이다. Active-Standby로 가용성을 유지하며 데이터 정합성을 보장한다.
• 리플리케이션: 마스터(쓰기)-슬레이브(읽기)로 분리하여 각각 별도 스토리지를 가진다. 읽기 부하를 분산할 수 있지만 데이터 동기화에 지연이 발생할 수 있다.
• 샤딩: 테이블을 특정 기준으로 나눠 여러 DB 서버에 분산 저장한다. 쓰기·읽기 모두 분산할 수 있지만 여러 샤드에 걸친 조인과 트랜잭션이 복잡해진다.

핵심 키워드: ① 클러스터링 = 가용성(+정합성 보장) ② 리플리케이션 = 읽기 부하 분산(동기화 지연) ③ 샤딩 = 쓰기·읽기 모두 분산(조인·트랜잭션 복잡)

답변 레벨 차이

꼬리 질문

• "리플리케이션은 구체적으로 어떻게 구현되나요?" → 다음 질문.

Q. 리플리케이션에서 구체적으로 어떻게 데이터가 복제되나요?

핵심 답변 (골드 수준)

MySQL 기준으로 3단계다.

1. 마스터 DB에서 쓰기 트랜잭션이 수행되면 **바이너리 로그(binlog)**에 기록된다.
2. 슬레이브의 I/O 스레드가 마스터의 binlog를 복사해 와서 **릴레이 로그(relay log)**에 저장한다.
3. 슬레이브의 SQL 스레드가 릴레이 로그를 읽어 마스터에서 처리된 트랜잭션을 동일하게 재실행한다. (중계한다는 의미에서 로그 이름이 "릴레이"다.)

이 과정을 알면 리플리케이션 레그(복제 지연)가 왜 발생하는지도 설명할 수 있다. 또한 I/O 스레드(가져오는 역할)와 SQL 스레드(재실행하는 역할)를 구분하면 복제 과정 어디에서 병목이 생기는지까지 파악할 수 있다.

핵심 키워드: ① binlog ② I/O 스레드와 릴레이 로그 ③ SQL 스레드(재실행)

답변 레벨 차이

꼬리 질문

• 다음 메인 질문 데드락으로 전환.

Q. 데드락이 무엇이고 DB에서 왜 발생하나요?

핵심 답변 (골드 수준)

데드락은 두 개 이상의 트랜잭션이 서로가 보유한 락을 기다리며 무한 대기하는 상태다.

핵심 원인은 두 트랜잭션이 서로 다른 순서로 락을 획득하는 것이다. 예를 들어 트랜잭션 A가 레코드 1에 락을 걸고 레코드 2를 요청하는 동시에, 트랜잭션 B가 레코드 2에 락을 걸고 레코드 1을 요청하면 서로 상대방이 끝나길 기다리며 데드락이 발생한다.

또한 트랜잭션이 길어질수록 락 보유 시간이 늘어나 데드락 발생 확률이 증가한다.

핵심 키워드: ① 무한 대기 ② 서로 다른 순서로 락 획득 ③ 트랜잭션의 길이

답변 레벨 차이

꼬리 질문

• "발생하면 어떻게 감지하고 대처하나요?" → 다음 질문.

Q. 데드락이 발생하면 어떻게 감지하고 대처하나요?

핵심 답변 (골드 수준)

• 감지: InnoDB는 Wait-for 그래프로 데드락을 자동 감지하고, 비용이 적은 트랜잭션을 롤백한다.
• 예방: ① 락 획득 순서를 일관되게 유지하고, ② 트랜잭션 범위를 최소화하며, ③ 락 대기 타임아웃(lock wait timeout)을 설정한다.

감지만 알면 터진 뒤에 대응하는 것이고, 예방까지 알아야 터지기 전에 막을 수 있다. 특히 "락 획득 순서 통일"은 앞 질문에서 다룬 데드락의 원인(서로 다른 순서의 락 획득)과 직접 연결된다.

핵심 키워드: ① 감지 메커니즘(Wait-for 그래프, 저비용 트랜잭션 롤백) ② 예방 메커니즘(순서 통일·범위 최소화·타임아웃)

답변 레벨 차이

꼬리 질문

• 범위를 넓혀 "DB 전체 장애가 발생하면 어떤 순서로 접근하나요?" → 다음 질문.

Q. DB에 장애가 발생하면 어떤 순서로 접근하시나요?

핵심 답변 (골드 수준)

1. 모니터링 대시보드로 현상을 파악한다: CPU, 메모리, 커넥션 수, 슬로우 쿼리 수를 확인한다.
2. SHOW PROCESSLIST로 현재 실행 중인 쿼리와 락 대기 상태를 확인한다: 모니터링은 추이를 보는 것이고, SHOW PROCESSLIST는 지금 무슨 일이 벌어지고 있는지 실시간으로 보는 것이다.
3. 원인을 분류한다: 쿼리 문제 / 락 경합 / 리소스 부족 중 어디에 해당하는지 판단한다.
4. 원인별로 대응한다: 쿼리 문제면 EXPLAIN으로 튜닝, 락 경합이면 트랜잭션 범위 축소나 락 해제, 리소스 부족이면 스케일 업/아웃 또는 커넥션 풀 조정.

"로그 보고 해결합니다"는 경험이 없는 사람의 답이다. 어떤 로그를 어떤 순서로 어떤 기준으로 보는지 말할 수 있어야 장애 해결 경험이 있는 사람으로 인식된다. 3번의 원인 분류(쿼리/락/리소스)는 강의 전체에서 다룬 슬로우 쿼리, 데드락, 커넥션 풀 개념이 모두 연결되는 프레임이다. 전부 외우기보다 실제 장애 해결 경험과 접목해서 답할 것.

핵심 키워드: ① 모니터링 대시보드 ② SHOW PROCESSLIST ③ 원인 분류 ④ 원인별 대응

답변 레벨 차이

꼬리 질문

• "DB 모니터링에서 주요하게 봐야 하는 메트릭은 뭔가요?" → 다음 질문.

Q. DB 모니터링에서 주요하게 봐야 하는 메트릭은 무엇인가요?

핵심 답변 (골드 수준)

크게 트래픽 / DB 내부 / 리소스 세 관점으로 나눠서 본다.

• 트래픽 관점: QPS로 부하 추이를, 슬로우 쿼리 수로 성능 저하 징후를 파악한다.
• DB 내부 관점: InnoDB 버퍼 풀 히트 레이쇼(hit ratio)가 낮으면 디스크 I/O 증가 신호이고, 리플리케이션 레그로 동기화 지연을, 락 대기 시간으로 트랜잭션 경합을 확인한다.
• 리소스 관점: 활성 커넥션 수, CPU·메모리 사용률로 병목 지점을 판단한다.

인프라 메트릭(CPU·메모리)은 "무언가가 느리다"를 알려주지만, DB 내부 메트릭은 "왜 느린지"를 알려준다. 메트릭을 단순 나열하는 것이 아니라 관점으로 분류하면 빠진 게 없는지 체크할 수도 있다. 장애 시 가설을 세우고 증명하는 증거가 바로 메트릭이다.

핵심 키워드: ① 트래픽 관점 ② DB 내부 관점 ③ 리소스 관점 (+각 관점의 대표 메트릭 몇 개)

답변 레벨 차이

꼬리 질문

• 섹션 마무리. 슬로우 쿼리 대처 → EXPLAIN → 데이터 증가 대응 → 클러스터링/리플리케이션/샤딩 → 리플리케이션 구현 → 데드락 → 장애 대응 순서 → 모니터링 메트릭의 흐름.

부록: 섹션 8 기타 질문 안내

섹션 2~7에서 다루지 않은 빈출 질문(검색, 캐싱, SQL, JPA 등)은 강의에서 PDF 부록 형태로 별도 제공된다. 강의 영상으로는 다루지 않으므로 이 노트에는 포함하지 않는다.