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

Service

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

My

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

Policy

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

© 2026 그알것 · What Still Matters

질문 목록Transaction
Transaction

낙관적 락과 비관적 락은 어떻게 다르고 언제 선택하나요?

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

면접관의 질문 의도

두 락의 정의를 구분할 수 있는지가 아니라, 충돌률·재시도 비용·교착 위험 같은 운영 변수를 가지고 어느 쪽을 골라야 하는지 끊을 수 있는지 가르려는 질문이다.

큐레이션 답변

학습 자료

낙관적 락은 '충돌은 흔치 않다'고 가정하고 읽을 때는 락을 잡지 않는다. 대신 수정 시점에 버전 컬럼이나 타임스탬프로 다른 트랜잭션이 먼저 바꾸진 않았는지 검증하고, 어긋났으면 애플리케이션이 재시도하거나 사용자에게 실패를 돌려준다. 비관적 락은 '충돌은 잦다'고 보고 트랜잭션을 시작하면서 공유·배타 락을 잡아 다른 세션의 접근을 막는다. 그래서 낙관적 쪽은 동시성·처리량은 좋지만 충돌이 많아질수록 재시도 비용이 폭주하고, 비관적 쪽은 무결성은 단단하지만 대기·교착·처리량 저하를 떠안는다. 결국 워크로드의 실제 충돌률과 실패를 사용자에게 어떻게 보여줄지가 선택을 가른다.

좋은 답변 구조

  1. 01두 락이 깔고 있는 충돌 가정의 차이를 먼저 정리한다
  2. 02버전 검증·재시도와 트랜잭션 락이라는 동작 방식의 차이를 비교한다
  3. 03처리량·무결성·교착 위험 같은 트레이드오프를 정리한다
  4. 04충돌률·읽기·쓰기 비중·사용자 노출 정책을 기준으로 선택 기준과 큐·이벤트 대안까지 짚는다

자주 실수하는 포인트

낙관적 락에서 재시도 정책 없이 OptimisticLockException을 그대로 사용자에게 노출한다
비관적 락을 걸면서 쿼리 순서·인덱스를 같이 손보지 않아 교착을 만든다
읽기 비중이 큰 시스템에 비관적 락을 일괄 적용해 처리량을 무너뜨린다

실무 맥락

  • 주문·재고처럼 같은 행을 여러 사용자가 동시에 갱신하려는 핫 키 자리
  • JPA의 @Version·SELECT FOR UPDATE를 골라 써야 하는 도메인 코드
  • 트래픽 피크에서 처리량과 실패율을 같이 봐야 하는 결제·정산 서비스

본인 경험에 녹이는 힌트

충돌률을 측정해 낙관적·비관적 락을 전환해 본 경험이 있다면 데이터 기반 선택 사례로 연결할 수 있다

재시도 백오프·실패 정책을 다듬어 실패율을 낮춰 본 적이 있다면 낙관적 락 운영 관점에서 말할 수 있다

교착 로그를 보고 쿼리 순서·인덱스를 조정해 본 경험이 있다면 비관적 락 운영 측면으로 엮을 수 있다

커뮤니티 인기 답변

전체 0개

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

관련 꼬리 질문

Q1낙관적 락에서 재시도 횟수와 백오프는 어떻게 정하나요
Q2비관적 락 적용 시 교착을 줄이는 실무 전략은 무엇인가요
Q3락 대신 큐 기반 직렬화가 더 나은 경우는 언제인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문