Daily Dev Q&A: 트랜잭션 격리 수준

Topic (오늘의 주제)

트랜잭션 격리 수준 (Transaction Isolation Level)

(Read Uncommitted, Read Committed, Repeatable Read, Serializable)

Why (왜 사용하는가? 왜 중요한가?)

• 실무: 데이터베이스의 성능(동시 처리량)과 데이터 정합성(정확도)은 반비례 관계입니다. 서비스의 특성에 맞춰 "어느 정도의 불안정함을 감수하고 속도를 높일지" 결정하는 기준이 됩니다.
• 구조적 의미: 트랜잭션의 ACID 성질 중 **Isolation(고립성)**을 얼마나 엄격하게 지킬지 레벨(Level 0~3)로 나누어 정의한 표준입니다.
• 면접 의도: 각 단계별로 발생하는 데이터 불일치 문제(Dirty Read 등)를 이해하고 있는지, 그리고 자신이 사용하는 DB(MySQL vs Oracle)의 기본 격리 수준을 알고 있는지 확인합니다.

Core Concept (핵심 개념 정리)

격리 수준이 낮을수록 동시성은 높아지지만 데이터 문제가 발생하고, 높을수록 데이터는 안전하지만 느려집니다.

레벨 (Level)	이름	설명	발생 가능한 문제	특징
Level 0	Read Uncommitted	커밋하지 않은 데이터도 다른 트랜잭션이 읽을 수 있음.	Dirty Read, Non-Repeatable Read, Phantom Read	성능은 가장 좋으나 데이터 신뢰성이 없어 거의 사용 안 함.
Level 1	Read Committed	커밋된 데이터만 읽을 수 있음.	Non-Repeatable Read, Phantom Read	Oracle, PostgreSQL, SQL Server의 기본값. 가장 널리 사용됨.
Level 2	Read Repeatable	트랜잭션 내에서 조회를 반복해도 항상 같은 결과가 나옴.	Phantom Read (InnoDB는 거의 발생 안 함)	MySQL(InnoDB)의 기본값. MVCC로 구현됨.
Level 3	Serializable	가장 엄격함. 읽기 작업에도 락을 걸어 한 번에 하나씩만 처리.	없음 (완벽한 격리)	동시성이 급격히 떨어져 실무에서 거의 사용 안 함.

Interview Answer Version (면접 답변식 요약)

"트랜잭션 격리 수준은 동시에 실행되는 트랜잭션끼리 서로 얼마나 영향을 미치게 할지 결정하는 기준입니다.

크게 4단계가 있으며, Read Uncommitted, Read Committed, Repeatable Read, Serializable 순으로 격리성이 강해집니다.

격리 수준이 낮으면 동시성은 좋지만 'Dirty Read' 같은 데이터 정합성 문제가 발생할 수 있고, 높으면 데이터는 안전하지만 성능이 떨어집니다. 보통 실무에서는 성능과 안정성의 균형을 맞춘 Read Committed나 Repeatable Read를 주로 사용합니다."

Practical Tip (사용시 주의할 점 or 활용 예)

1. 사용하는 DB의 기본값(Default) 파악 필수

• MySQL: 기본값이 REPEATABLE READ입니다. 따라서 하나의 트랜잭션 안에서 SELECT를 여러 번 해도 값이 바뀌지 않습니다.
• Oracle/PostgreSQL: 기본값이 READ COMMITTED입니다. 트랜잭션 도중에 다른 사용자가 데이터를 수정하고 커밋하면, 내 트랜잭션 안에서도 값이 바뀐 것을 보게 됩니다. 이 차이를 모르면 로직 오류가 발생할 수 있습니다.

2. Serializable 사용 지양

• 데이터가 정말 중요하다고 해서 무조건 SERIALIZABLE을 설정하면 안 됩니다. 이 레벨은 단순 조회(SELECT) 시에도 공유 락(Shared Lock)을 걸기 때문에 데드락이 빈번하게 발생하고 서비스 속도가 현저히 느려집니다.
• 대신 **낙관적 락(@Version)**이나 SELECT ... FOR UPDATE 같은 명시적 락을 사용하는 것이 좋습니다.

3. 트랜잭션 전파 속성과의 관계

• 스프링 프레임워크 사용 시 @Transactional(isolation = Isolation.READ_COMMITTED) 처럼 코드 레벨에서 격리 수준을 변경할 수 있습니다. 하지만 DB 설정을 따르는 것이 일반적이며, 특수한 경우에만 변경합니다.

예상 꼬리질문 정리

Q1. MySQL의 InnoDB는 Repeatable Read 단계에서도 Phantom Read가 발생하지 않는다고 하는데, 이유가 무엇인가요?

• 핵심 키워드: **MVCC(Multi-Version Concurrency Control)**와 Next-Key Lock 덕분입니다. 조회 시점의 스냅샷을 읽어오므로(MVCC) 다른 트랜잭션의 변경이 보이지 않고, 범위 검색 시 사이 공간을 잠그는(Gap Lock) 방식(Next-Key Lock)을 통해 데이터 추가를 막습니다.

Q2. 실무에서 Read Committed를 사용하다가 Non-Repeatable Read 문제가 발생하면 어떻게 해결하나요?

• 핵심 키워드: 격리 수준을 전체적으로 올리기보다는, 해당 로직에서만 **비관적 락(Pessimistic Lock, FOR UPDATE)**을 걸어 데이터 변경을 막거나, **낙관적 락(Optimistic Lock)**을 사용하여 데이터 정합성을 맞춥니다.

Q3. MVCC(다중 버전 동시성 제어)가 무엇인지 격리 수준과 연관 지어 설명해주세요.

• 핵심 키워드: 락을 쓰지 않고 읽기 일관성을 유지하는 기술입니다. 데이터를 수정할 때 변경 전 데이터를 Undo Log에 저장해두고, 다른 트랜잭션이 조회할 때 격리 수준에 따라 실제 데이터가 아닌 Undo Log의 과거 데이터를 보여줌으로써 Repeatable Read를 구현합니다.