1. 팬텀 충돌(Phantom Conflict)의 개념
가. 정의
한 트랜잭션 내에서 동일한 범위 질의(Range Query)를 두 번 실행했을 때, 첫 번째 쿼리에는 없던 레코드가 두 번째 쿼리에서 나타나는 현상입니다.
데이터 수정(Update)이 아닌 **삽입(Insert) 또는 삭제(Delete)**에 의해 발생하며, **유령 읽기(Phantom Read)**라고도 불립니다.
나. 발생 원인
불충분한 고립 수준(Isolation Level): 트랜잭션이 읽은 개별 레코드에만 락(Lock)을 걸고, 레코드 사이의 간격(Gap)은 보호하지 못할 때 발생합니다.
동시성 제어 미흡: 다중 사용자 환경에서 트랜잭션 간의 간섭을 완전히 차단하지 못해 발생합니다.
2. 팬텀 충돌의 발생 메커니즘 (Scenario)
T1 (Step 1):
SELECT * FROM 사원 WHERE 급여 > 5000;실행 (결과: 3건)T2 (Step 2):
INSERT INTO 사원 (이름, 급여) VALUES ('홍길동', 6000);실행 및 CommitT1 (Step 3): 동일한 쿼리 재실행 (결과: 4건)
결과: T1은 동일 트랜잭션 내에서 데이터의 일관성이 깨지는 '팬텀 충돌'을 경험하게 됩니다.
3. 트랜잭션 고립 수준(Isolation Level)과 팬텀 충돌
ANSI/ISO SQL 표준에 정의된 고립 수준에 따른 팬텀 충돌 발생 여부는 다음과 같습니다.
| 고립 수준 | Dirty Read | Non-Repeatable Read | Phantom Read |
| Read Uncommitted | 발생 | 발생 | 발생 |
| Read Committed | 방지 | 발생 | 발생 |
| Repeatable Read | 방지 | 방지 | 발생 (기본) |
| Serializable | 방지 | 방지 | 방지 (차단) |
참고: InnoDB(MySQL) 등 일부 DBMS는 Next-Key Lock을 통해 Repeatable Read 수준에서도 팬텀 충돌을 방지합니다.
4. 팬텀 충돌 방지를 위한 기술적 대응 방안
가. 고립 수준 상향 (Serializable)
가장 높은 수준의 격리성을 제공하여 모든 읽기 작업에 공유 락을 설정하고 트랜잭션을 직렬화합니다.
단점: 동시 처리 성능(Concurrency)이 급격히 저하됩니다.
나. 인덱스 기반 락킹 (Index/Gap Lock)
간격 락 (Gap Lock): 레코드 자체가 아니라 레코드와 레코드 사이의 빈 공간에 락을 걸어 새로운 데이터의 삽입을 차단합니다.
넥스트 키 락 (Next-Key Lock): 레코드 락(Record Lock)과 간격 락(Gap Lock)을 결합하여 현재 레코드와 이전 간격까지 모두 보호합니다.
다. 다중 버전 동시성 제어 (MVCC, Multi-Version Concurrency Control)
데이터의 스냅샷(Snapshot)을 생성하여 읽기 시점의 데이터를 보장합니다.
특정 시점의 일관된 데이터를 읽게 함으로써 락 대기 없이 팬텀 현상을 억제합니다.
5. 기술사적 제언: 성능과 정합성의 트레이드오프(Trade-off)
비즈니스 영향 분석: 금융 결제나 재고 관리와 같이 엄격한 정합성이 필요한 업무는 Serializable 수준이나 Pessimistic Lock 도입을 고려해야 합니다.
낙관적 락(Optimistic Lock) 활용: 충돌 빈도가 낮다면 버전 번호(Version Number)를 활용하여 애플리케이션 계층에서 충돌을 감지하고 재시도하는 전략이 성능상 유리할 수 있습니다.
DBMS 특성 파악: 사용하는 DBMS가 제공하는 기본 고립 수준과 락킹 메커니즘(예: MySQL의 Next-Key Lock vs Oracle의 Snapshot Isolation)을 정확히 이해하고 아키텍처를 설계해야 합니다.
