DB 격리 수준(Isolation Levels)을 AICC 콜센터 예제와 함께 알아보기

오늘은 데이터베이스 트랜잭션의 격리 수준(Isolation Level)에 대해 알아보겠습니다. AICC 콜센터 시스템에서는 동시에 여러 고객이 접속하고, 여러 상담사가 채팅·전화·상담 등을 동시에 처리합니다. 이러한 동시성(Concurrency)을 안전하게 보장하기 위해서는 트랜잭션 격리 수준을 어떻게 적용하느냐가 매우 중요합니다.

---

1. 격리 수준(Isolation Level)이란? 🤔

격리 수준(Isolation Level)은 데이터베이스가 여러 트랜잭션을 동시에 처리할 때, 각 트랜잭션이 다른 트랜잭션의 중간 연산 결과를 볼 수 있는지 혹은 볼 수 없는지를 결정하는 규칙입니다.

• 왜 필요할까요?
  동시에 많은 트랜잭션이 실행될 때, 데이터 무결성과 일관성을 지키면서도 최대한 높은 성능(동시성)을 내야 하기 때문입니다.

보통 데이터베이스 시스템은 다음 네 가지 기본 격리 수준을 제공합니다(ANSI/ISO 표준):

1. READ UNCOMMITTED
2. READ COMMITTED
3. REPEATABLE READ
4. SERIALIZABLE

---

2. AICC 콜센터 시나리오 🎬

AICC 콜센터 시스템에서 자주 발생할 수 있는 상황을 생각해봅시다.

1. 여러 고객이 동시에 채팅 세션을 열고 메시지를 주고받는다.
2. 상담사 여러 명이 동시에 고객 정보를 확인하거나, 상담 상태를 갱신한다.
3. 실시간으로 상담 이력을 조회하고 분석하는 모듈이 존재한다.

이런 상황에서 한 트랜잭션(예: “고객 A의 채팅 로그를 INSERT”)이 끝나기도 전에, 다른 트랜잭션(예: “관리자가 고객 A의 현재 채팅 로그를 SELECT”)이 접근한다면, “어느 시점”의 데이터를 보여줄 것인지를 결정해야 합니다. 바로 이 지점을 격리 수준이 조절하게 됩니다.

---

3. 각 격리 수준별 특징과 AICC 사례

3.1 READ UNCOMMITTED

가장 낮은 격리 수준으로, 트랜잭션이 커밋되지 않은(UNCOMMITTED) 변경 내용까지 다른 트랜잭션에서 읽을 수 있습니다.

• 장점: 동시성(Concurrency)이 가장 높다 (락이 거의 없음).
• 단점: Dirty Read 발생.
  • Dirty Read: 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽어버리는 현상.
  • 만약 롤백(ROLLBACK)이 된다면, 읽어간 데이터는 잘못된 값이 됩니다.

AICC 콜센터 예시

• 상담사 A가 고객 DB에 새로운 고객 정보를 입력하던 중(아직 커밋 전), 상담사 B가 “신규 고객” 리스트를 조회합니다.
• 하지만 상담사 A가 입력 도중에 오류가 발생해 롤백했다면? 상담사 B가 봤던 신규 고객 정보는 실제로 존재하지 않는 데이터가 되어버립니다.

이런 이유로 실무 환경에서 READ UNCOMMITTED는 거의 사용되지 않습니다.

---

3.2 READ COMMITTED

가장 널리 쓰이는 기본 격리 수준 중 하나로, 커밋된(Committed) 데이터만 읽을 수 있도록 제한합니다.

• Dirty Read가 방지됩니다. (커밋 안 된 데이터는 볼 수 없음)
• 하지만 Non-Repeatable Read가 여전히 발생할 수 있습니다.
  • Non-Repeatable Read: 한 트랜잭션이 같은 쿼리를 두 번 조회했을 때, 그 사이에 다른 트랜잭션이 데이터를 수정·커밋하면 결과가 달라지는 현상.

AICC 콜센터 예시

• 상담사 A가 고객 정보(예: “김영희” 고객의 전화번호)를 조회했습니다.
• 조회 후에 상담사 B가 같은 고객 정보를 수정(전화번호 변경)하고 커밋했습니다.
• 상담사 A가 다시 “김영희”의 정보를 조회하면 처음 조회 결과와 달라진 정보를 얻게 됩니다.
• 콜센터 업무 자체에는 큰 문제가 없을 수도 있지만, 만약 “같은 트랜잭션 내에서는 일관된 정보를 봐야 한다”는 요구가 있다면 불편할 수 있습니다.

READ COMMITTED는 트랜잭션마다 “SELECT가 실행되는 순간”에 커밋된 최신 데이터를 보여주는 방식입니다.

---

3.3 REPEATABLE READ

MySQL InnoDB 등에서 기본으로 많이 사용되는 방식.

• Non-Repeatable Read를 방지하기 위해, 한 트랜잭션 내에서 이미 읽은(SELECT한) 데이터는 같은 트랜잭션이 다시 읽어도 처음과 같은 데이터가 보장됩니다.
• 하지만 Phantom Read(유령 레코드)가 발생할 수 있습니다.
  • Phantom Read: WHERE 조건에 맞는 “새로운 행”이 중간에 삽입·커밋되면, 이전 SELECT와 결과 집합의 행 개수가 달라지는 현상.

AICC 콜센터 예시

• 상담사 A가 “오늘 새로 접수된 채팅 세션”을 조회하는 트랜잭션을 시작했다고 가정합시다.
• 첫 번째 조회 때, 결과적으로 채팅 세션이 5개가 나왔습니다.
• 그 사이에 상담사 B가 새로운 채팅 세션을 추가하고 커밋합니다.
• 상담사 A가 다시 “오늘 새로 접수된 채팅 세션”을 조회하면, 새로 생긴 채팅 세션(6번째)이 등장할 수도 있습니다. 이를 Phantom Read라고 합니다.

MySQL InnoDB의 REPEATABLE READ는 MVCC(다중 버전 동시성 제어)를 통해 Non-Repeatable Read는 막지만, INSERT/DELETE로 인해 “행 자체”가 새로 추가·삭제되는 건 막지 못하므로 “팬텀 레코드”가 나타날 수 있습니다.

---

3.4 SERIALIZABLE

가장 엄격한 격리 수준으로, 여러 트랜잭션이 직렬화(Sequential하게 수행된 것) 한 것과 동일한 결과를 보장합니다.

• Non-Repeatable Read와 Phantom Read 모두 방지 가능.
• 하지만 락(LOCK)을 많이 사용하므로, 동시성이 크게 떨어질 수 있습니다. 성능이 중요하게 고려되는 시스템에서는 잘 사용하지 않습니다.

AICC 콜센터 예시

• 상담 이력 조회, 고객 정보 수정 등 모든 작업이 철저히 순차적으로 처리되어야 한다고 가정하면, Serializble 수준을 쓸 수 있습니다.
• 하지만 트래픽이 몰리는 콜센터 시스템에서는 여러 상담사가 동시에 데이터를 업데이트해야 하므로, 트랜잭션 간 대기 시간이 길어져 응답 지연이 커질 수 있습니다.

---

4. 각 격리 수준에서 일어날 수 있는 문제점 정리

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	주로 쓰임
READ UNCOMMITTED	발생함	발생함	발생함	거의 사용 안 함
READ COMMITTED	방지됨	발생함	발생함	Oracle, MSSQL 기본
REPEATABLE READ	방지됨	방지됨	발생함	MySQL InnoDB 기본
SERIALIZABLE	방지됨	방지됨	방지됨	가장 엄격; 성능↓

---

5. AICC 콜센터에서 어떤 격리 수준을 선택해야 할까? ⚖️

1. READ COMMITTED

   • 실무에서 가장 많이 사용되는 수준. Dirty Read를 방지하면서, 적당한 동시성을 확보합니다.
   • 상담 이력 조회, 고객 정보 수정 등 일반적인 트랜잭션 처리에 충분한 경우가 많습니다.

2. REPEATABLE READ

   • MySQL InnoDB에서 기본. Non-Repeatable Read를 방지해 한 트랜잭션 내에서는 같은 SELECT 쿼리 결과가 일관됩니다.
   • 다만 “팬텀 레코드”가 발생할 수 있으므로, 집계나 통계 등을 정확히 “고정된 시점”에 보고 싶다면 주의가 필요합니다.

3. SERIALIZABLE

   • “사람 생명과 직결되는” 은행 거래나 항공권 예매 시스템 등, 무결성이 절대적으로 중요한 곳에서 사용될 수 있습니다.
   • 하지만 동시 트래픽이 많은 콜센터에서는 성능이 급격히 저하될 위험이 큽니다.

---

6. 실제 적용 예시 📱

아래 예시는 MySQL에서 전역 트랜잭션 격리 수준을 설정하는 방법입니다.

-- 현재 격리 수준 확인
SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

-- REPEATABLE READ로 설정 (MySQL InnoDB 기본)
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- 특정 세션에서만 격리 수준 설정
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

Oracle이나 PostgreSQL 등 다른 DBMS에서도 비슷한 형태로 트랜잭션 격리 수준을 조정할 수 있습니다.

---

7. 마치며 🎁

AICC 콜센터 같은 멀티 유저·실시간 처리 환경에서는, DB 트랜잭션 격리 수준을 어떻게 설정하느냐에 따라 성능과 데이터 무결성이 크게 달라집니다.

• READ UNCOMMITTED는 성능상 이점이 있지만 Dirty Read 문제로 실무에선 권장되지 않습니다.
• 대부분의 경우 READ COMMITTED나 REPEATABLE READ로도 충분합니다.
• SERIALIZABLE는 가장 안정적이지만, 가장 성능이 떨어질 수 있음을 유념해야 합니다.

결국, 격리 수준은 “AICC 콜센터 시스템의 특성(트래픽 양, 무결성 요구 정도, 분석 vs. 실시간 처리 비율 등)”을 종합해 결정하는 것이 좋습니다.
적절한 격리 수준을 선택해 동시성과 데이터 안정성 사이에서 균형을 찾으면, 상담사는 원활하게 여러 고객을 처리하고, 고객 역시 지연 없이 서비스를 이용할 수 있게 됩니다.

---

참고 자료 및 출처

• MySQL 공식 문서 - Transaction Isolation Levels
• Oracle Database Concepts - Isolation Levels
• PostgreSQL 공식 문서 - Transaction Isolation

위 자료를 참고하여 여러분의 AICC 시스템 설계에 맞는 격리 수준을 현명하게 선택해보세요!