은행에서 10만원을 이체하는 순간을 상상해 봅시다.
이 간단해 보이는 작업 뒤에서는, 최소 두 가지의 일이 순식간에 일어나야 합니다.
- 내 계좌에서 10만원이 빠져나간다. (UPDATE)
- 상대방 계좌에 10만원이 들어온다. (UPDATE)
만약 내 돈은 빠져나갔는데, 상대방에게는 들어오지 않고 중간에 데이터가 사라진다면 어떻게 될까요?
이러한 데이터 불일치 재앙을 막기 위한 데이터베이스의 4가지 절대적인 약속이 바로 ‘ACID 원칙’입니다.
이 글에서 다루는 것
- ACID 원칙의 개념과 중요성
- 원자성(A), 일관성(C), 고립성(I), 지속성(D) 각각의 의미
- QA를 위한 ACID 원칙 테스트 방법
‘ACID 원칙’, 정확히 무엇인가요?
ACID는 하나의 ‘트랜잭션(Transaction)’이 안전하게 수행되는 것을 보장하기 위한 4가지 특성을 의미합니다.
여기서 트랜잭션이란, ‘모두 성공하거나, 하나라도 실패하면 모두 실패해야 하는’ 하나의 논리적인 작업 단위를 말합니다. (예: 계좌 이체, 상품 주문)
ACID는 다음 4가지 특성의 앞 글자를 딴 것입니다.
- Atomicity (원자성)
- Consistency (일관성)
- Isolation (고립성, 격리성)
- Durability (지속성)
[A] 원자성(Atomicity) 테스트
- 원자성이란?
- 트랜잭션에 포함된 모든 작업은 ‘모두 성공’하거나, ‘하나라도 실패하면 모두 실패(롤백)’해야 한다는 원칙입니다.
- 더 이상 쪼갤 수 없는 ‘원자’처럼, 작업이 중간에 애매한 상태로 끝나서는 안 됩니다. ‘All or Nothing’의 원칙입니다.
- QA 테스트 시나리오:
- 계좌 이체 트랜잭션 중간에 의도적으로 장애를 발생시킵니다.
- 예를 들어, 내 계좌에서 출금은 성공했지만, 상대방 계좌에 입금하는 단계에서 네트워크를 강제로 끊거나 데이터베이스 서버를 잠시 중단시킵니다.
- 기대 결과: 입금에 실패했으므로, 이전에 성공했던 ‘출금’ 작업까지 모두 자동으로 취소(롤백)되어, 내 계좌의 잔액이 원래대로 돌아와야 합니다. 데이터베이스에는 아무런 변화가 없어야 합니다.
[C] 일관성(Consistency) 테스트
- 일관성이란?
- 트랜잭션이 성공적으로 완료된 후에도, 데이터베이스는 항상 ‘일관된’ 상태를 유지해야 한다는 원칙입니다.
- 즉, 데이터베이스에 미리 정의된 규칙이나 제약 조건(예: 계좌 잔액은 음수가 될 수 없다)을 위반해서는 안 됩니다.
- QA 테스트 시나리오:
- 데이터베이스의 제약 조건을 위반하는 데이터를 의도적으로 만들어내는 테스트를 수행합니다.
- 예를 들어, ‘계좌 잔액은 0원 미만이 될 수 없다’는 제약 조건이 있는 경우, 잔액이 1만원인 계좌에서 2만원을 출금하는 트랜잭션을 시도합니다.
- 기대 결과: 트랜잭션 전체가 실패하고, 데이터베이스의 상태는 트랜잭션 시작 전과 동일하게 유지되어야 합니다. (즉, 잔액은 변하지 않고 1만원으로 남아있어야 합니다.)
[I] 고립성(Isolation) 테스트
- 고립성이란?
- 여러 개의 트랜잭션이 ‘동시에’ 실행될 때, 서로에게 영향을 주지 않고 마치 혼자 순차적으로 실행되는 것처럼 보여야 한다는 원칙입니다.
- QA 테스트 시나리오:
- 이는 이전에 다룬 ‘경쟁 상태(Race Condition)’를 테스트하는 것과 깊은 관련이 있습니다.
- 성능 테스트 도구(JMeter 등)를 사용하여, 동일한 계좌에 ‘동시에’ 입금하는 트랜잭션과 출금하는 트랜잭션을 실행합니다.
- 기대 결과: 어떤 트랜잭션이 먼저 실행되든, 최종 계좌 잔액은 모든 거래가 순차적으로 하나씩 실행된 것과 동일한 결과여야 합니다. (예: 초기 잔액 1만원 + 5천원 동시 입금 – 3천원 동시 출금 = 최종 잔액 1만 2천원)
[D] 지속성(Durability) 테스트
- 지속성이란?
- 성공적으로 완료되어 커밋(Commit)된 트랜잭션의 결과는, 시스템에 장애(예: 정전, 서버 다운)가 발생하더라도 영구적으로 ‘지속’되어야 한다는 원칙입니다.
- QA 테스트 시나리오:
- 이 테스트는 매우 어렵고 파괴적이라, QA가 직접 수행하기보다는 개념을 이해하는 것이 중요합니다.
- 보통 데이터베이스 시스템 자체가 이 기능을 보장합니다.
- ‘계좌 이체 성공’ 응답을 받은 직후, 데이터베이스 서버의 전원을 강제로 내렸다가 다시 켭니다.
- 기대 결과: 서버가 재시작된 후에도, 이체 결과는 데이터베이스에 안전하게 기록되어 있어야 하며, 데이터가 유실되어서는 안 됩니다.
결론: 신뢰의 네 가지 기둥
ACID 원칙은 모든 금융 시스템의 신뢰를 떠받치는 네 개의 단단한 기둥입니다.
QA는 이 원칙들을 이해함으로써, 단순한 기능 테스트를 넘어 데이터베이스 레벨에서 발생할 수 있는 근본적인 데이터 정합성 문제를 찾아낼 수 있습니다.
ACID를 검증하는 것은, 사용자의 소중한 자산이 그 어떤 상황에서도 안전하게 보호될 것이라는, 금융 서비스의 가장 기본적인 약속을 테스트하는 일입니다.
부록: ACID 테스트 미니 체크리스트 ✅
- 트랜잭션 중간에 실패 시, 모든 변경사항이 롤백되는가? (원자성)
- DB 제약 조건(예: Not Null, Unique)을 위반하는 트랜잭션은 거부되는가? (일관성)
- 동일한 데이터에 동시에 접근할 때, 데이터가 깨지지 않는가? (고립성)
- 커밋된 데이터는 서버 재부팅 후에도 안전하게 보존되는가? (지속성)
참고 자료 (References)
- IBM – ACID properties (ACID 원칙에 대한 기술 문서)
- 위키백과 – ACID (ACID 원칙에 대한 한글 설명)