그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Concurrency
Concurrency

데이터베이스에서 동시성을 제어하는 방법에는 어떤 것들이 있나요?

실무4/5
설계4/5
인간4/5
기초4/5

면접관의 질문 의도

MVCC와 락 기반의 차이를 이해하는 데서 그치는지, 아니면 두 방식이 한 엔진 안에서 어떻게 섞여 쓰이는지까지 실무 감각으로 풀 수 있는지를 가른다.

큐레이션 답변

학습 자료

MVCC는 한 데이터의 여러 버전을 동시에 유지해 "읽기는 쓰기를 막지 않는다"는 스냅샷 일관성을 제공한다. 락 기반은 공유/배타 락으로 같은 자원에 접근하는 트랜잭션을 직렬화해 정합성을 보장하지만 경합과 데드락이 따라온다. 실제 엔진은 둘을 섞어 쓴다 — InnoDB·PostgreSQL은 기본을 MVCC로 두면서 갱신 충돌·범위 잠금이 필요한 구간엔 락을 함께 쓴다. 즉 "무엇을 골랐는가"가 아니라 "어디서 무엇을 섞었는가"가 운영 관점에서 더 중요하다.

좋은 답변 구조

  1. 01MVCC와 락 기반의 동작 원리를 "읽기와 쓰기의 관계"라는 같은 축에서 비교한다
  2. 02각 방식의 장점(MVCC: 읽기 처리량, 락: 정합성 직관성)과 비용(MVCC: 버전 관리, 락: 경합·데드락)을 짚는다
  3. 03실제 엔진(InnoDB·PostgreSQL)이 두 방식을 어떤 구간에서 어떻게 섞는지 사례로 보여 준다
  4. 04워크로드(읽기 위주/쓰기 위주, 짧은 트랜잭션/긴 트랜잭션)에 따라 선택과 설정이 어떻게 갈리는지로 마무리한다

자주 실수하는 포인트

MVCC를 "락이 전혀 없다"로 단정해 갱신 충돌 시 락이 필요하다는 점을 빠뜨린다
락 기반을 "옛날 방식"으로 묘사하며 현실에서 MVCC와 함께 쓰이는 점을 놓친다
격리 수준과 동시성 제어 방식을 분리해서 설명해 실제 관계를 보여 주지 못한다
데드락을 "드물게 일어나는 예외"로만 설명하고 자주 발생하는 패턴(역순 락 획득 등)을 들지 못한다

실무 맥락

  • 대량의 읽기 트래픽과 일부 쓰기 트랜잭션이 함께 도는 OLTP 백엔드
  • 재고 차감·잔액 갱신처럼 같은 행을 여러 트랜잭션이 동시에 갱신하는 케이스
  • 장시간 트랜잭션이 MVCC 버전을 누적시켜 vacuum·undo 부담이 커지는 운영 상황

본인 경험에 녹이는 힌트

lock wait timeout이나 데드락 로그를 추적해 본 경험이 있다면 "역순 락 획득" 같은 구체적 원인 패턴으로 풀어낼 수 있다

SELECT FOR UPDATE를 도입해 동시 갱신 사고를 막은 경험이 있다면 MVCC 위에 락을 얹는 사례로 보여 줄 수 있다

긴 트랜잭션이 vacuum/undo 부담을 키운 경험이 있다면 MVCC의 비용을 운영 지표로 풀어낼 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1MVCC 환경에서도 락이 꼭 필요한 상황은 언제인가요
Q2읽기 중심과 쓰기 중심 워크로드에서 동시성 전략은 어떻게 달라지나요
Q3데드락이 자주 나는 패턴과 이를 줄이는 설계 방법은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문