트랜잭션 격리 수준 (Transaction Isolation Level)
쉽게 풀면
은행 계좌 앱을 여러 사람이 동시에 쓰는 상황을 생각해봅시다. 내가 잔액을 조회하는 그 순간, 다른 사람이 그 계좌에 돈을 입금하고 있다면 어떻게 될까요? 격리 수준이 낮으면 나는 아직 확정되지 않은(커밋되지 않은) 중간 값을 볼 수도 있고, 격리 수준이 높으면 다른 트랜잭션이 완전히 끝날 때까지 내 조회 결과는 변하지 않는 것처럼 보장받습니다. 대표적으로 READ UNCOMMITTED(가장 느슨함, dirty read 허용) → READ COMMITTED → REPEATABLE READ → SERIALIZABLE(가장 엄격함) 순으로 단계가 있으며, 격리 수준이 높아질수록 데이터 일관성은 좋아지지만 동시 처리 성능은 떨어지는 트레이드오프가 있습니다.
왜 중요한가
격리 수준은 데이터베이스 시스템 설계에서 정합성과 성능 사이의 균형을 조정하는 핵심 손잡이입니다. 분산 시스템, 클라우드 데이터베이스, 대규모 트랜잭션 처리 시스템 연구에서는 격리 수준을 어떻게 구현하고 어떤 수준을 기본값으로 선택하느냐가 시스템 처리량과 이상 현상(anomaly) 발생 가능성을 동시에 좌우하기 때문에 성능 평가와 신뢰성 검증에서 반복적으로 다뤄집니다.
논문에서는 이렇게 쓰입니다
이 문장은 "여러 작업이 동시에 실행되어도 마치 하나씩 순서대로 처리된 것과 같은 결과를 보장하도록 가장 엄격한 격리 규칙을 사용했다"는 뜻입니다.
분산 시스템 성능 연구에서 격리 수준을 낮췄을 때 얻는 처리 성능 이득을 정량적으로 비교하는 전형적인 문장이다.
동시성 제어 연구에서 특정 격리 수준이 허용하는 이상 현상을 실험적으로 재현하고 그 원인을 분석할 때 쓰이는 서술이다.
조금 더 깊게 보면
격리 수준 간의 차이는 흔히 dirty read, non-repeatable read, phantom read, lost update 같은 이상 현상을 어디까지 허용하는지로 구분됩니다. 실제 구현에서는 락(lock) 기반 방식뿐 아니라 다중 버전 동시성 제어(MVCC, Multi-Version Concurrency Control)를 사용하는 경우가 많으며, 같은 이름의 격리 수준이라도 데이터베이스 제품마다 내부 동작이 조금씩 다를 수 있어 논문에서는 사용한 DBMS와 구체적인 구현 방식을 함께 명시하는 것이 일반적입니다.
주의할 점
격리 수준은 ACID 트랜잭션의 "Isolation(고립성)" 속성을 구체적으로 구현하는 방식일 뿐, 무조건 가장 높은 수준(SERIALIZABLE)이 정답인 것은 아닙니다. 실제 시스템 설계에서는 데이터 정합성 요구 수준과 동시 처리 성능(로드밸런싱 등) 사이의 균형을 고려해 적절한 수준을 선택합니다.