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

Service

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

My

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

Policy

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

© 2026 그알것 · What Still Matters

질문 목록Transaction
Transaction

트랜잭션 격리수준은 무엇인가요?

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

면접관의 질문 의도

격리 수준 이름만 외운 사람인지, _이상 현상_과 _DB 엔진별 동작_까지 묶어 상황별 선택 기준을 말하는 사람인지를 가른다.

큐레이션 답변

학습 자료

격리 수준은 동시에 실행되는 트랜잭션 간 _데이터 가시성과 충돌 허용 범위_를 정한다. READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE로 갈수록 정합성은 높아지고 동시성은 떨어진다. Dirty Read, Non-Repeatable Read, Phantom Read 같은 이상 현상을 기준으로 시스템 요구에 맞게 고른다. 또한 같은 "REPEATABLE READ"라도 MySQL InnoDB(MVCC + 갭락)와 PostgreSQL(MVCC 스냅숏)이 다르게 동작해 엔진별 특성까지 함께 봐야 한다.

좋은 답변 구조

  1. 01네 격리 수준과 Dirty/Non-Repeatable/Phantom Read라는 판단 축을 정리한다
  2. 02각 단계가 막는 이상 현상과 그 대가(락·MVCC 비용)를 균형 있게 설명한다
  3. 03결제·재고처럼 정합성 우선이냐, 검색·집계처럼 처리량 우선이냐로 결론이 갈리는 조건을 짚는다
  4. 04MySQL/PostgreSQL 엔진별 차이와 SELECT FOR UPDATE 같은 보완책으로 마무리한다

자주 실수하는 포인트

이상 현상(Dirty/Non-Repeatable/Phantom)을 헷갈려서 격리 수준 매핑이 어긋난다
MySQL InnoDB의 REPEATABLE READ가 갭락으로 Phantom Read까지 막는다는 _엔진별 특성_을 모른다
운영 정책 없이 격리 수준을 항상 가장 높게 두려 한다
락 경합으로 인한 처리량 저하를 _느린 쿼리_로만 잘못 본다

실무 맥락

  • 결제/재고 처리에서 동시 차감으로 음수가 발생하는 사고를 막아야 하는 상황
  • 대량 조회·집계 쿼리가 락 경합으로 트랜잭션을 막는 운영 문제
  • 마이크로서비스에서 분산 트랜잭션 대신 격리 수준 + 보완 패턴을 선택해야 하는 설계

본인 경험에 녹이는 힌트

동시 결제로 잔액이 꼬이는 사고를 SELECT FOR UPDATE/격리 수준 조정으로 해결한 경험이 있다면 그 케이스 자체가 답변 후크가 된다

REPEATABLE READ에서 Phantom Read가 막히는 InnoDB 동작을 활용한 경험이 있다면 엔진별 특성 이야기로 깊이를 더할 수 있다

격리 수준을 올린 뒤 락 경합으로 처리량이 떨어져 _다른 방식_으로 푼 경험이 있다면 트레이드오프 판단으로 연결할 수 있다

커뮤니티 인기 답변

전체 0개

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

관련 꼬리 질문

Q1READ COMMITTED와 REPEATABLE READ를 선택하는 기준은 무엇인가요
Q2Phantom Read와 Non-Repeatable Read를 어떻게 구분하나요
Q3격리 수준을 높일 때 성능 저하를 완화하는 방법은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문