트랜잭션 원자성편집자 확인

트랜잭션 원자성은 데이터베이스 시스템과 분산 컴퓨팅에서 트랜잭션이 갖추어야 할 핵심 속성 중 하나이다. 이 개념은 하나의 트랜잭션을 구성하는 모든 작업이 전부 성공하거나, 아니면 전혀 실행되지 않은 상태로 되돌아가야 함을 의미한다. "원자성"이라는 용어는 더 이상 쪼갤 수 없는 기본 단위인 원자에서 비롯되었으며, 트랜잭션도 마찬가지로 분할될 수 없는 하나의 논리적 단위로 취급되어야 한다는 점을 상징한다.

예를 들어, 은행 계좌 간 이체 작업은 출금과 입금이라는 두 개의 데이터 변경 작업으로 구성된다. 원자성이 보장되지 않는다면, 출금만 성공하고 입금은 실패하는 상황이 발생할 수 있어 데이터의 정합성이 심각하게 훼손된다. 원자성은 이러한 부분적 성공을 방지하여, 트랜잭션의 모든 연산이 완전히 적용되거나(커밋) 전혀 적용되지 않도록(롤백) 보장하는 역할을 한다.

이 속성은 ACID 트랜잭션 특성의 첫 글자를 차지하며, 나머지 일관성, 격리성, 지속성을 위한 기초를 제공한다. 원자성의 구현은 주로 로그 기반 복구, 락킹 메커니즘, 2단계 커밋과 같은 기술을 통해 이루어진다. 데이터의 신뢰성과 정확성이 요구되는 금융, 예약, 재고 관리 등 다양한 비즈니스 시스템에서 트랜잭션 원자성은 필수적인 개념으로 자리 잡고 있다.

트랜잭션 원자성은 데이터베이스 시스템에서 하나의 트랜잭션을 구성하는 모든 연산이 전부 성공하거나, 아니면 전혀 실행되지 않은 것처럼 모두 실패해야 함을 보장하는 속성이다. 이는 더 이상 분할할 수 없는 단위라는 원자(Atomic)의 개념에서 비롯된 용어이다. 예를 들어, 은행 계좌 이체 트랜잭션은 출금과 입금이라는 두 개의 연산으로 구성된다. 원자성은 이 두 연산이 모두 완료되거나(커밋), 하나라도 실패하면 이전 상태로 완전히 롤백되어야 함을 의미한다. 부분적으로만 실행된 상태(예: 출금만 되고 입금은 안 된 상태)는 허용되지 않는다.

원자성의 중요성은 데이터 무결성을 유지하는 데 있다. 시스템 장애, 네트워크 문제, 소프트웨어 오류 등 어떤 이유로든 트랜잭션이 중단될 경우, 원자성은 데이터가 불완전하거나 모순된 상태에 빠지지 않도록 보호한다. 이는 금융 거래, 재고 관리, 예약 시스템 등 정확성이 절대적으로 요구되는 비즈니스 로직의 핵심 기반이 된다. 원자성이 없다면 부분적 업데이트로 인해 데이터의 신뢰성이 크게 훼손될 수 있다.

원자성은 일반적으로 롤백 메커니즘을 통해 구현된다. 트랜잭션이 시작되면 시스템은 변경 전의 데이터 상태를 기록해둔다. 이후 트랜잭션 실행 중 오류가 발생하면 이 기록을 이용해 모든 변경 사항을 취소하고 트랜잭션 시작 전의 상태로 되돌린다. 성공적으로 완료될 경우에는 변경 사항을 확정(커밋)한다. 이렇게 함으로써 사용자나 응용 프로그램은 트랜잭션이 "전부 아니면 전무"의 방식으로 처리된다는 것을 신뢰할 수 있다.

트랜잭션 원자성을 구현하기 위한 주요 메커니즘에는 로그 기반 복구, 락킹 메커니즘, 2단계 커밋 등이 있다. 이러한 메커니즘들은 시스템 장애 발생 시에도 모든 작업이 적용되거나 전혀 적용되지 않도록 보장한다.

로그 기반 복구, 특히 WAL은 가장 널리 사용되는 방법이다. 이 메커니즘은 데이터베이스에 실제 변경을 적용하기 전에, 모든 변경 사항을 안정적인 저장 장치에 순차적으로 기록한 로그 파일에 먼저 기록한다. 트랜잭션이 커밋되면 로그에 커밋 기록을 남기고, 이후에 메모리나 디스크의 실제 데이터를 갱신한다. 시스템 장애가 발생하면 복구 관리자는 이 로그를 검사하여, 커밋 기록은 있지만 데이터 갱신이 완료되지 않은 트랜잭션은 재실행하고, 커밋 기록이 없는 트랜잭션은 변경 사항을 모두 취소한다.

락킹 메커니즘은 동시에 실행되는 여러 트랜잭션이 같은 데이터를 충돌 없이 접근하도록 관리하여 원자성의 실행을 돕는다. 트랜잭션은 데이터 항목을 읽거나 쓰기 전에 해당 항목에 대한 락을 획득해야 한다. 쓰기 락은 배타적이며, 트랜잭션이 완료될 때까지 다른 트랜잭션이 해당 데이터를 읽거나 쓸 수 없게 한다. 이를 통해 트랜잭션의 중간 상태가 다른 트랜잭션에 노출되는 것을 방지하고, 롤백 시 변경 사항을 확실히 되돌릴 수 있는 기반을 마련한다.

분산 데이터베이스나 마이크로서비스 환경에서는 2단계 커밋 프로토콜이 사용된다. 이 프로토콜은 여러 독립적인 시스템에 걸친 트랜잭션의 원자성을 보장한다. 프로토콜은 준비 단계와 커밋 단계로 구성된다. 조정자는 모든 참여자에게 트랜잭션 준비를 요청하고, 모든 참여자가 준비 완료를 보고하면 커밋을 지시한다. 만약 한 참여자라도 준비에 실패하면 조정자는 모든 참여자에게 중단을 지시한다. 이 과정을 통해 모든 노드가 일관되게 커밋하거나 중단하도록 강제한다.

트랜잭션의 원자성을 완벽하게 보장하는 것은 시스템 설계에 있어 여러 가지 비용과 제약을 수반한다. 가장 두드러진 한계는 성능 오버헤드다. 원자성을 보장하기 위해 사용되는 락킹, 로그 기록, 2단계 커밋 등의 메커니즘은 추가적인 입출력 작업과 동시성 제어를 필요로 한다. 이는 특히 쓰기 작업이 빈번한 환경에서 처리량을 저하시키고 응답 시간을 증가시킬 수 있다. 또한, 장시간 트랜잭션이 자원을 점유하는 경우 다른 트랜잭션의 대기 시간이 길어져 시스템 전체의 처리율이 떨어질 수 있다.

분산 시스템 환경에서 원자성을 보장하는 것은 훨씬 더 복잡한 과제가 된다. 네트워크 분할, 노드 장애, 통신 지연과 같은 문제는 원자성 프로토콜의 실행을 방해한다. 예를 들어, 2단계 커밋 프로토콜은 모든 참여 노드가 준비 상태에 도달해야 커밋할 수 있으며, 단일 노드의 장애나 응답 지연이 전체 트랜잭션의 완료를 차단하는 블로킹 문제를 발생시킨다. 이러한 취약점을 해결하기 위해 3단계 커밋이나 Paxos 같은 합의 알고리즘이 제안되었지만, 이는 다시 프로토콜의 복잡성과 메시지 교환 오버헤드를 증가시킨다.

따라서 시스템 설계자는 애플리케이션의 요구사항에 따라 원자성 보장의 수준을 조정해야 하는 트레이드오프에 직면한다. 높은 일관성이 필수적인 금융 시스템에서는 성능 저하를 감수하고 강력한 원자성을 선택하는 반면, 대규모 웹 서비스나 분산 데이터베이스에서는 가용성과 확장성을 우선시하여 결과적 일관성과 같은 느슨한 모델을 채택하기도 한다. 이는 ACID 특성과 BASE 특성 사이의 근본적인 선택으로 귀결된다.

이러한 트레이드오프는 원자성이 무조건적인 선이 아니라, 데이터의 정확성, 시스템 성능, 개발 복잡도, 비용 간의 균형을 고려한 설계 결정의 결과임을 보여준다.

트랜잭션 원자성은 ACID 트랜잭션 특성 중 하나로, 나머지 세 가지 속성인 일관성, 격리성, 지속성과 밀접하게 연관되어 작동한다. 원자성은 트랜잭션의 모든 연산이 완전히 수행되거나 전혀 수행되지 않음을 보장하는 반면, 다른 속성들은 이 보장을 바탕으로 데이터의 정합성과 신뢰성을 확장한다.

원자성은 일관성과 지속성을 실현하기 위한 핵심 기반이다. 일관성은 트랜잭션이 데이터베이스의 사전 정의된 규칙(제약 조건)을 위반하지 않은 상태로 종료되어야 함을 의미한다. 원자성이 보장되지 않으면 트랜잭션의 중간 상태가 데이터베이스에 부분적으로 반영되어 일관성이 깨질 수 있다. 지속성은 커밋된 트랜잭션의 결과가 시스템 장애 후에도 영구적으로 유지됨을 보장한다. 원자성은 커밋 전의 모든 변경 사항을 안전하게 기록(예: WAL)하여, 커밋이 확정된 작업만이 지속성의 보호를 받도록 한다.

격리성은 동시에 실행되는 여러 트랜잭션이 서로 간섭하지 않도록 관리하는 속성이다. 원자성과 격리성은 상호 보완적 역할을 한다. 격리성 수준(예: Read Committed, Serializable)에 따라 다른 트랜잭션이 부분적으로 커밋된 데이터를 볼 수 없도록 보장하는 데, 이 부분적 커밋 상태 자체가 원자성에 의해 존재하지 않게 된다. 따라서 높은 격리성 수준은 원자성의 완전한 'all-or-nothing' 실행을 전제로 더 엄격한 동시성 제어를 구현한다.

ACID 속성 간의 관계는 다음 표로 요약할 수 있다.

결론적으로, 원자성은 트랜잭션을 하나의 불가분한 작업 단위로 정의함으로써, 다른 ACID 속성들이 효과적으로 구현될 수 있는 토대를 마련한다. 이들 속성은 분리되어 작동하지 않고 통합적으로 데이터베이스 시스템의 신뢰성을 구성한다.

트랜잭션의 원자성이 깨지는 실패는 주로 시스템 장애, 하드웨어 문제, 소프트웨어 버그, 또는 네트워크 분할로 인해 발생한다. 이러한 실패는 트랜잭션의 일부 연산만 적용된 상태, 즉 중간 상태를 데이터베이스에 남길 수 있다. 이는 데이터베이스 일관성을 심각하게 훼손한다.

복구 메커니즘은 이러한 중간 상태를 감지하고 원자성을 복원하는 역할을 한다. 가장 일반적인 접근법은 로그 기반 복구를 활용하는 것이다. 시스템은 트랜잭션 시작 전에 로그에 시작 기록을, 연산 수행 시 변경 사항을 리두 로그에, 그리고 완료 시 커밋 기록을 순차적으로 남긴다. 시스템 장애 후 재시작 시, 복구 관리자는 로그를 분석한다. 커밋 기록이 있는 트랜잭션의 변경 사항은 리두 로그를 통해 재적용하고(Redo), 커밋 기록 없이 종료된 트랜잭션의 부분적 변경 사항은 언두 로그를 이용해 원래 상태로 되돌린다(Undo).

분산 환경에서의 복구는 더욱 복잡하다. 2단계 커밋 프로토콜을 사용하는 중 코디네이터 또는 참여자 노드에 장애가 발생하면, 프로토콜은 차단 상태에 빠질 수 있다. 이를 해결하기 위해 새로운 코디네이터가 선출되어 로그를 조회하고, 모든 참여자의 상태를 폴링하여 트랜잭션을 최종 커밋 또는 중단시키는 과정이 필요하다[5]. 이러한 복구 절차는 데이터의 원자성과 트랜잭션 지속성을 보장하는 데 필수적이다.

트랜잭션 원자성의 개념은 컴퓨터 과학 외의 다양한 분야에서도 발견된다. 예를 들어, 데이터베이스 트랜잭션과 유사하게, 은행의 계좌 이체는 출금과 입금이 모두 성공하거나 모두 실패해야 하는 원자적 작업이다.

이 개념은 일상 생활의 많은 약속이나 계약에도 적용될 수 있다. "A를 하면 B를 한다"와 같은 조건부 계약은 A와 B가 하나의 원자적 단위로 처리되어야 완전히 이행된 것으로 간주된다[6].

컴퓨터 과학의 초기부터, 시스템 장애 시에도 데이터 무결성을 보장해야 할 필요성은 인식되어 왔다. 이는 ACID 모델의 정립으로 이어졌으며, 원자성은 그 핵심 기둥 중 하나가 되었다.

• Wikipedia - ACID (computer science)

• Wikipedia - Atomicity (database systems)

• Oracle - Transaction Management

• Microsoft SQL Docs - Transactions (Transact-SQL)

• IBM Db2 Docs - Atomicity

• PostgreSQL Docs - Transaction Isolation

• Google Cloud - What is a database transaction?

• AWS - Database transactions