트랜잭션과 ACID: 은행 이체가 ‘정확하게’ 처리되는 기술적 원리

왜 은행 이체는 거의 틀리지 않을까

인터넷 뱅킹이나 모바일 앱으로 이체를 할 때 사용자는 몇 초 안에 “이체가 완료되었습니다”라는 메시지를 본다. 계좌에서 돈이 빠져나가고, 상대 계좌에 돈이 들어가는 과정은 눈에 보이지 않지만, 거의 항상 정확하게 처리된다.

그러나 내부에서는 여러 가지 위험이 상존한다.

• 이체 도중 서버가 다운될 수도 있고,
• 네트워크가 끊길 수도 있고,
• 같은 이체 요청이 두 번 들어올 수도 있다.

그럼에도 불구하고 은행 시스템이 안정적으로 동작하는 이유는 데이터베이스 트랜잭션(Transaction)과 ACID 특성(Atomicity, Consistency, Isolation, Durability) 덕분이다.

이 글에서는 트랜잭션, ACID, 은행 이체, 데이터베이스, 일관성을 핵심 키워드로 삼아,

• 트랜잭션이 무엇인지,
• ACID 네 가지 특성이 어떤 문제를 막아 주는지,
• 실제 은행 이체 상황에서 어떻게 적용되는지
  를 전산학 입문 수준에서 차근차근 설명한다.

---

트랜잭션의 개념 – 은행 이체를 하나의 작업으로 묶는 기술

1. 트랜잭션(Transaction)이란 무엇인가

트랜잭션(Transaction)은 데이터베이스에서 하나의 논리적인 작업 단위를 의미한다. 중요한 특징은 “중간까지만 성공”이 없다는 점이다.

트랜잭션은 다음 두 상태 중 하나로 끝나야 한다.

1. 커밋(Commit):
   • 트랜잭션 안의 모든 작업이 정상적으로 수행되어 영구 반영하는 것.
2. 롤백(Rollback):
   • 중간에 오류나 문제가 발생했을 때,
   • 트랜잭션 안에서 진행된 변경을 처음 상태로 되돌리는 것.

트랜잭션의 핵심 아이디어는 간단하다.

• 여러 개의 데이터 변경 작업을 하나로 묶어서
• “모두 성공하거나 모두 취소”시키는 것이다.

2. 은행 이체 예시로 보는 트랜잭션

은행 계좌 A에서 B로 10만 원을 이체한다고 가정해 보자. 데이터베이스 수준에서 보면 다음과 같은 작업이 필요하다.

1. A 계좌의 잔액에서 10만 원을 뺀다.
2. B 계좌의 잔액에 10만 원을 더한다.

단순해 보이지만, 데이터베이스 입장에서는 두 개의 별도 업데이트 작업이다.

트랜잭션이 없다면 다음과 같은 문제가 발생할 수 있다.

• A 계좌에서 10만 원을 빼는 작업은 성공했지만,
• B 계좌에 10만 원을 더하는 작업 전에 시스템이 다운되는 경우
  → 결과적으로 A의 돈은 줄었는데, B의 돈은 늘지 않는 불일치 상태가 된다.

이런 상황을 막기 위해 은행 시스템은

• “A에서 10만 원 감소 + B에서 10만 원 증가”를
• 하나의 트랜잭션으로 처리한다.

즉,

• 두 작업이 모두 성공하면 커밋하고,
• 중간에 한 작업이라도 실패하면 롤백하여
  • 아예 아무 일도 없었던 것처럼 되돌린다.

이렇게 하면 “A 돈만 줄고 B 돈은 안 늘어나는” 불완전한 상태는 발생하지 않는다.

 

은행 계좌 간 이체 트랜잭션 흐름 개념도

3. 데이터베이스와 트랜잭션의 관계

데이터베이스 관리 시스템(DBMS)는 트랜잭션을 지원하기 위해 여러 기능을 제공한다.

1. 트랜잭션 시작과 종료 제어
   • 애플리케이션은 “트랜잭션 시작”을 선언한 후,
   • 여러 SQL(INSERT, UPDATE, DELETE 등)을 실행하고,
   • 마지막에 “COMMIT” 또는 “ROLLBACK”을 호출하여 트랜잭션을 끝낸다.
2. 로그 기록과 복구 메커니즘
   • DBMS는 변경 작업을 수행할 때, 내부적으로 로그(Log)를 남긴다.
   • 시스템 장애가 발생하면 로그를 읽어
     • 성공한 트랜잭션은 다시 반영하거나,
     • 실패한 트랜잭션은 롤백하여 일관된 상태를 유지한다.
3. 동시성 제어(Concurrency Control)
   • 여러 사용자가 동시에 데이터를 변경하더라도
   • 트랜잭션 단위로 정합성을 유지할 수 있도록
   • 잠금(Lock)과 격리 수준(Isolation Level)을 관리한다.

이러한 기능들이 결합되어,

• 은행, 카드사, 쇼핑몰 결제, 증권 거래 등
• “돈과 관련된 중요한 데이터”도 트랜잭션을 통해 안정적으로 처리할 수 있다.

---

ACID 네 가지 특성과 은행 이체에서의 역할

1. ACID란 무엇인가

트랜잭션이 제대로 동작하기 위해서는 몇 가지 필수적인 성질을 만족해야 한다. 이를 네 글자로 정리한 것이 ACID이다.

• A (Atomicity, 원자성)
• C (Consistency, 일관성)
• I (Isolation, 고립성)
• D (Durability, 지속성)

각 특성이 어떤 의미를 가지며, 은행 이체에서 어떤 역할을 하는지 순서대로 살펴본다.

2. A – Atomicity(원자성): 모두 성공하거나 모두 취소

원자성(Atomicity)은 트랜잭션 안에 묶인 여러 작업이 불가분의 한 덩어리로 취급된다는 의미이다.

• 은행 이체 예시에서 “A 계좌에서 10만 원 감소 + B 계좌에서 10만 원 증가”는
  • 둘 중 하나만 성공하는 일이 없어야 한다.
• 둘 다 성공하면 커밋, 하나라도 실패하면 전체 롤백된다.

원자성이 없다면 다음과 같은 문제들이 발생한다.

• A 계좌 잔액은 줄고, B 계좌 잔액은 그대로인 상태
• 재고는 감소했는데, 주문 내역이 기록되지 않는 상태

원자성은 이러한 “절반만 처리된 상태”를 원천적으로 차단해 준다.

3. C – Consistency(일관성): 규칙을 어기는 상태는 허용하지 않음

일관성(Consistency)은 트랜잭션이 시작되기 전과 후에 데이터베이스가 정해진 규칙과 제약 조건을 만족하는 상태를 유지해야 한다는 뜻이다.

예를 들어 은행 시스템에는 다음과 같은 규칙이 있을 수 있다.

• 계좌 잔액은 0원 이상이어야 한다.
• 특정 통화 단위는 소수 둘째 자리까지만 허용한다.
• 계좌별로 고유 번호(기본 키)가 중복되면 안 된다.

트랜잭션이 실행되는 동안에는 잠시 규칙을 어기는 중간 상태가 있을 수 있지만,

• 최종적으로 커밋된 이후의 데이터베이스 상태는 항상 규칙을 만족해야 한다.

만약 A 계좌에 5만 원밖에 없는데,

• 10만 원을 빼는 이체 트랜잭션을 허용한다면
• 규칙을 어기는 일관성 없는 상태가 된다.

DBMS는 제약 조건과 검증 로직을 통해

• 규칙 위반이 감지되면 해당 트랜잭션을 롤백하거나 오류를 발생시켜
• 데이터베이스가 항상 일관된 상태를 유지하도록 한다.

트랜잭션과 ACID 특성이 적용된 은행 이체 단계

4. I – Isolation(고립성): 동시에 처리해도 서로 간섭하지 않음

고립성(Isolation)은 여러 트랜잭션이 동시에 실행될 때,

• 마치 각각 혼자 실행된 것처럼 결과가 나와야 한다는 의미이다.

은행 이체 예시를 조금 확장해 보자.

• 트랜잭션 T1: A 계좌에서 10만 원을 B 계좌로 이체
• 트랜잭션 T2: 같은 시각에 A 계좌 잔액을 조회해 화면에 표시

고립성이 없으면, 다음과 같은 애매한 상태가 발생할 수 있다.

• T1이 A 계좌에서 10만 원을 빼고 아직 B 계좌에 더하지 않은 순간에,
• T2가 잔액을 조회하면 “중간 상태”의 값을 보게 된다.

사용자 입장에서는

• 같은 시각에 본 잔액이 페이지마다 다르게 보이는 등
• 이해하기 어려운 결과가 나타날 수 있다.

고립성은

• 트랜잭션들이 서로의 중간 결과를 보지 못하도록 제어하여,
• 최종 결과가 “어느 한 순서대로 차례로 실행된 것과 같은 효과”가 나도록 보장한다.

DBMS는 이를 위해

• 레코드 수준, 테이블 수준의 잠금(Lock),
• 다양한 격리 수준(Isolation Level)을 제공한다.

실제 시스템에서는 성능과 정확도 사이에서 균형을 맞추기 위해

• 완전한 고립성(Serializable)부터,
• 약간의 중간 상태 허용(Read Committed, Repeatable Read 등)까지
  여러 옵션을 선택할 수 있다.

5. D – Durability(지속성): 한 번 성공한 이체는 영구히 남는다

지속성(Durability)은 트랜잭션이 커밋되면,

• 그 결과가 디스크 등 안정적인 저장 장치에 영구히 기록된다는 의미이다.

예를 들어,

• 사용자가 A 계좌에서 B 계좌로 10만 원 이체를 수행했고,
• 시스템이 “이체 완료”를 보여주었다면,

그 이후에

• 갑자기 전원이 나가거나,
• 서버가 다운되더라도,

이미 커밋된 이체 내역은 다시 살아나야 한다.

이를 위해 DBMS는

• 트랜잭션 로그를 디스크에 기록하고,
• 장애 발생 시 로그를 재적용하는 복구(Recovery) 기능을 제공한다.

지속성이 없다면,

• 사용자는 이미 이체 완료 화면을 봤는데
• 나중에 잔액을 확인해 보니 이체가 되지 않은 상태가 될 수 있다.

은행, 카드사, 증권사 등에서 트랜잭션 로그와 백업, 복구 전략을 중요하게 다루는 이유가 바로 지속성 때문이다.

6. ACID가 없는 경우에 발생할 수 있는 문제들

ACID 특성이 지켜지지 않으면 다음과 같은 문제가 실제로 발생할 수 있다.

1. 원자성 부족 → 반쪽짜리 이체
   • 출금은 되었는데 입금이 안 되는 상황
2. 일관성 부족 → 규칙 위반
   • 계좌 잔액이 음수가 되거나,
   • 통화 단위와 맞지 않는 수치가 저장되는 상황
3. 고립성 부족 → 이상한 조회 결과
   • 동시에 이체와 조회를 할 때,
   • 어떤 화면에서는 이체가 반영되고, 다른 화면에서는 반영되지 않는 것처럼 보이는 현상
4. 지속성 부족 → 사라지는 거래 내역
   • “완료” 메시지를 받은 후에도,
   • 장애 발생으로 인해 실제 데이터베이스에는 반영되지 않는 상황

트랜잭션과 ACID는 이런 문제를 구조적으로 예방하기 위한 기술적 원리라고 볼 수 있다.

---

트랜잭션과 ACID를 이해하면 금융 시스템의 신뢰성이 보인다

이 글에서는 트랜잭션과 ACID를 중심으로, 은행 이체가 정확하게 처리되는 기술적 원리를 살펴보았다. 핵심 내용을 정리하면 다음과 같다.

1. 트랜잭션은 데이터베이스에서 하나의 논리적인 작업 단위이다.
   • 여러 변경 작업을 묶어 “모두 성공하거나 모두 취소”되도록 만든다.
2. ACID 네 가지 특성은 트랜잭션이 믿을 수 있게 동작하는 기준이다.
   • 원자성(Atomicity): 반쪽짜리 작업을 허용하지 않는다.
   • 일관성(Consistency): 규칙을 어기는 최종 상태를 허용하지 않는다.
   • 고립성(Isolation): 동시에 실행해도 서로 간섭하지 않은 것처럼 보이게 한다.
   • 지속성(Durability): 한 번 커밋된 결과는 장애가 나도 유지된다.
3. 은행 이체, 결제, 증권 거래 등 돈이 오가는 시스템은 ACID 기반 트랜잭션에 의존한다.
   • 이체 도중 장애나 중복 요청이 발생해도,
   • 사용자가 기대하는 “정확한 결과”를 제공할 수 있는 이유가 여기에 있다.
4. 일반 웹 서비스에서도 트랜잭션과 ACID 이해는 중요하다.
   • 주문 처리, 재고 관리, 포인트 적립, 회원 정보 변경처럼
   • “반쪽짜리 변경”이 허용되지 않는 영역에서는
   • 트랜잭션 경계를 올바르게 설정해야 한다.

이제 “왜 은행 이체가 거의 틀리지 않는가”라는 질문에 대해,

• 데이터베이스 트랜잭션이 작업을 하나로 묶어서 처리하고,
• ACID 특성이 그 작업의 정확성과 안정성을 보장하기 때문이라는 설명을 할 수 있을 것이다.

다음 단계에서 함께 살펴볼 만한 주제로는 예를 들어 다음과 같은 것들이 있다.

• “격리 수준(Isolation Level) 상세: READ COMMITTED, REPEATABLE READ, SERIALIZABLE의 차이”
• “분산 트랜잭션과 2PC: 여러 시스템에 걸친 이체를 어떻게 안전하게 처리하는가”

이러한 주제들을 이어서 학습하면, 전산학과 실무 개발에서 핵심이 되는 데이터베이스 설계와 금융 시스템의 안정성을 더 깊이 이해하는 데 도움이 된다.