[DB] 데이터베이스 동시성 이슈(Concurrency Issue) 총정리
안녕하세요! 백엔드 개발자라면 실무에서 반드시 마주하게 되는, 그리고 면접에서도 단골로 출제되는 데이터베이스 동시성 이슈에 대해 핵심만 콕 짚어 정리해 보겠습니다.
수많은 사용자가 동시에 접속하는 서비스에서 우리가 저장한 데이터가 어떻게 보호되는지, 어떤 위험이 있는지 함께 알아볼까요?
1. 동시성 이슈란 무엇인가요?
**동시성 이슈(Concurrency Issue)**란 여러 개의 트랜잭션이 동시에 같은 데이터에 접근하여 수정할 때, 데이터의 일관성이 깨지고 논리적인 오류가 발생하는 현상을 말합니다.
쉽게 말해, **"내가 수정하고 있는데 남이 끼어들어서 데이터를 엉망으로 만드는 상황"**이라고 이해하면 쉽습니다.
2. 대표적인 동시성 이슈 3가지
① 갱신 손실 (Lost Update)
두 개의 트랜잭션이 동시에 데이터를 수정할 때, 먼저 반영된 수정 사항이 나중에 반영된 수정 사항에 의해 덮어씌워져 사라지는 문제입니다.
- 상황: 재고 10개인 상품을 사용자 A와 B가 동시에 1개씩 주문함.
- 과정: A가 10개를 읽어 9개로 만들고 저장하기 직전, B도 10개를 읽어 9개로 만들고 저장함.
- 결과: 주문은 2건인데 재고는 8개가 아닌 9개가 남음. (A의 업데이트가 손실됨)
② 더티 리드 (Dirty Read)
다른 트랜잭션이 수정 중이지만 아직 확정(Commit)하지 않은 데이터를 읽어서 발생하는 문제입니다.
- 상황: A가 잔액을 1만 원에서 0원으로 수정 중(아직 커밋 전).
- 과정: B가 A가 수정 중인 '0원'을 읽어 결제 로직을 태움. 그런데 갑자기 A의 트랜잭션에 문제가 생겨 **롤백(Rollback)**됨.
- 결과: 실제 잔액은 다시 1만 원이 됐지만, B는 존재하지도 않는 '0원'을 기준으로 작업을 처리해 버림.
③ 반복 읽기 불가능 (Non-Repeatable Read)
한 트랜잭션 내에서 같은 데이터를 두 번 조회했을 때, 그 사이 다른 트랜잭션이 데이터를 수정/삭제하여 두 조회 결과가 다르게 나타나는 현상입니다.
- 상황: A가 잔액을 조회(1만 원 확인)하고 잠시 다른 로직을 처리함.
- 과정: 그 사이 B가 잔액을 5천 원으로 수정하고 커밋함. A가 다시 잔액을 조회하니 5천 원으로 바뀜.
- 결과: 하나의 작업 단위 내에서 데이터의 일관성이 무너짐.
3. 어떻게 해결하나요?
데이터베이스는 이러한 문제를 해결하기 위해 크게 두 가지 전략을 사용합니다.
1) 트랜잭션 격리 수준 (Isolation Level)
DB 설정으로 동시성 제어의 엄격함을 조절합니다.
- Read Committed: 커밋된 데이터만 읽기 (더티 리드 방지)
- Repeatable Read: 트랜잭션 내 동일한 조회 결과 보장 (갱신 손실 등 일부 방지)
- Serializable: 가장 엄격하게 순차적으로 처리 (성능은 가장 낮음)
2) 락 (Locking) 전략
- 낙관적 락 (Optimistic Lock): 데이터 충돌이 적을 것으로 예상하고, 수정 시점에 버전 번호를 체크하는 방식.
- 비관적 락 (Pessimistic Lock): 데이터 읽기 단계부터 락을 걸어 다른 사용자의 접근을 차단하는 방식.
4. 한눈에 요약 표
| 이슈 종류 | 핵심 내용 | 해결책 |
| 갱신 손실 | 나중의 수정이 앞선 수정을 덮어씀 | 락(Lock), 원자적 연산 |
| 더티 리드 | 커밋 안 된 '가짜' 데이터를 읽음 | Read Committed 이상 설정 |
| 반복 읽기 불가능 | 조회할 때마다 값이 달라짐 | Repeatable Read 이상 설정 |