동시성 문제 흐름
운영에서 터지는 이유는 복잡한 버그가 아니라 기준이 잡힌 사이에 다른 작업이 끼어들기 때문입니다.
동시성 문제의 이름은 달라도 구조는 같습니다. 한 트랜잭션이 값을 믿고 작업하는 동안 다른 트랜잭션이 상태를 바꾸면, 테스트에서는 안 보이던 불일치가 운영에서 드러납니다.
공통 뿌리 T1이 읽은 값, 잡아둔 행, 조건 범위가 아직 유효하다고 가정한 채 진행하는 동안 T2가 그 전제를 바꾸면 결과가 어긋납니다.
1. 기준 형성
T1이 먼저 판단의 기준을 만든다
읽은 값이나 조회 범위가 "지금 상태"라고 믿고 다음 계산, 검증, 갱신을 준비합니다.
T1: SELECT balance = 100
T1: WHERE status = 'READY'
2. 끼어듦
그 사이 T2가 같은 데이터에 손을 댄다
핵심은 이름이 아니라 어느 지점을 바꿨는가입니다. 같은 행, 미커밋 값, 조건 범위가 모두 대상이 됩니다.
같은 행 수정 이미 읽은 값이 커밋 후 달라짐
미커밋 값 노출 아직 확정되지 않은 중간 상태를 읽음
범위 안 새 행 추가 같은 조건인데 결과 집합이 달라짐
3. 운영에서 드러남
T1은 바뀐 전제를 모르고 계속 진행한다
같은 트랜잭션 안에서 본 값이 달라지거나, 존재하지 말아야 할 값이 보이거나, 먼저 한 갱신이 덮여 사라집니다.
판단 기준과 실제 상태가 벌어짐
→ 오손 읽기 / 반복 불가능 읽기
→ 팬텀 읽기 / 갱신 손실
무엇이 흔들리면 어떤 문제로 보이나?
미커밋 중간값 Dirty Read
같은 행의 값 반복 불가능 읽기
조건 범위의 행 집합 팬텀 읽기
같은 기준으로 동시 쓰기 갱신 손실
격리 수준이 하는 일
격리 수준은 "어떤 끼어듦까지 허용할지"를 정하는 경계입니다. 허용을 넓히면 동시성은 좋아지지만, 기준이 흔들릴 위험도 커집니다.
느슨함동시성 더 높음
조절허용 범위를 제한
엄격함일관성 더 강함
읽는 포인트 문제 이름을 외우기보다, 기준이 언제 생겼고 그 사이 누가 끼어들었는지를 보면 왜 격리 수준이 필요한지 바로 연결됩니다.