트랜잭션

트랜잭션은 흩어진 낱개를 한 벌로 묶어 다루는 것을 가리키는 말입니다. 무엇을 묶는지는 쓰는 자리마다 다릅니다. 묶은 뒤에 무엇을 약속하는지도 자리마다 다릅니다. 그래서 데이터베이스에서 배운 뜻 하나로 다른 자리의 트랜잭션을 만나면 어긋납니다.

쉽고 빠른 이해

흩어진 낱개를 한 벌로 묶어 다루는 일을 가리키는 말입니다. 데이터베이스에서는 여러 단계를 한 벌로 묶어 전부 반영되거나 전부 취소되게 합니다.

같은 낱말이 여러 맥락에 따로 자리 잡았습니다. 무엇을 묶는지가 맥락마다 다릅니다. 묶은 뒤에 무엇을 약속하는지도 다릅니다. 메일에서도 트랜잭션이라고 부릅니다. 그쪽은 전부 아니면 전무를 약속하지 않습니다.

읽는 순서는 셋입니다.

1. 어느 맥락의 말인지 이름을 먼저 댑니다. 데이터베이스인지 분산인지 메일인지 블록체인인지.
2. 그 맥락에서 무엇을 묶는지 봅니다. 여러 단계인지, 여러 참가자인지, 명령 한 벌인지, 아니면 묶음이 아니라 보내는 메시지 한 개인지.
3. 묶은 뒤에 무엇을 약속하는지 봅니다. 전부 아니면 전무를 약속하는 자리도 있고 안 하는 자리도 있습니다.

대가는 이 낱말 하나로는 아무것도 정해지지 않는다는 것입니다. 맥락 이름을 빼고 트랜잭션이라고만 하면 듣는 쪽이 자기 맥락의 뜻으로 알아듣습니다.

상세

여러 뜻이 공유하는 뼈대는 하나입니다. 흩어진 낱개를 한 벌로 묶어 다룬다는 것입니다. 갈리는 자리는 둘입니다. 무엇을 묶는가, 그리고 묶은 뒤에 무엇을 약속하는가입니다.

데이터베이스에서 묶이는 것은 여러 단계입니다. PostgreSQL 공식 문서는 트랜잭션의 요점이 여러 단계를 하나의 전부 아니면 전무 연산으로 묶는 것이라고 적습니다. 단계 사이의 중간 상태는 동시에 도는 다른 트랜잭션에 보이지 않습니다. 트랜잭션이 끝나지 못하게 막는 실패가 나면 어느 단계도 데이터베이스에 영향을 주지 않습니다. 문서는 이것을 원자적이라고 부릅니다. 다른 트랜잭션의 관점에서 완전히 일어나거나 아예 일어나지 않는다는 뜻입니다.

분산에서 묶이는 것은 참가자입니다. MySQL 참조 매뉴얼은 XA 가 분산 트랜잭션을 지원한다고 적습니다. 분리된 여러 트랜잭션 자원이 하나의 전역 트랜잭션에 참여할 수 있게 하는 능력입니다. 여기서 묶이는 것은 한 데이터베이스 안의 단계가 아니라 서로 다른 자원들입니다.

메일에서 묶이는 것은 명령 한 벌입니다. RFC(Request for Comments) 5321 은 SMTP(Simple Mail Transfer Protocol) 메일 트랜잭션에 세 단계가 있다고 적습니다. 보내는 쪽을 알리는 MAIL, 받는 쪽을 알리는 RCPT, 본문 전송을 시작하는 DATA 입니다. 이 묶음은 전부 아니면 전무를 약속하지 않습니다. 갈리는 자리가 여기서 제일 뚜렷하게 보입니다.

블록체인에서는 묶는 대상 자체가 다릅니다. ethereum.org 개발자 문서는 트랜잭션을 계정이 암호학적으로 서명한 지시라고 적습니다. 여러 단계의 묶음이 아니라 보내는 메시지 한 개입니다.

그래서 트랜잭션이라는 말만으로는 전부 아니면 전무가 약속되는지가 정해지지 않습니다. 맥락 이름을 먼저 대야 뜻이 섭니다.

맥락별 뜻

데이터베이스

PostgreSQL 공식 문서는 트랜잭션이 모든 데이터베이스 시스템의 근본 개념이라고 적습니다. PostgreSQL 에서 트랜잭션은 SQL(Structured Query Language) 명령들을 BEGIN 과 COMMIT 으로 감싸서 만듭니다. 트랜잭션 도중에 커밋하지 않기로 정하면 COMMIT 대신 ROLLBACK 을 부릅니다. 그때까지의 갱신은 모두 취소됩니다. ROLLBACK 을 부르지 못한 채 트랜잭션이 끝나지 못하게 막는 실패가 나도 결과는 같습니다. 어느 단계도 데이터베이스에 영향을 주지 않습니다.

stateDiagram-v2
    state "진행 중" as 진행
    state "전부 반영" as 반영
    state "전부 취소" as 취소
    [*] --> 진행: BEGIN
    진행 --> 진행: SQL 명령
    진행 --> 반영: COMMIT
    진행 --> 취소: ROLLBACK
    진행 --> 취소: 완료를 막는 실패
    반영 --> [*]
    취소 --> [*]

트랜잭션은 진행 중이라는 한 상태에 머뭅니다. 거기서 전부 반영과 전부 취소 둘 중 하나로만 빠져나옵니다. 완료를 막는 실패도 전부 취소로 갑니다.

중간 상태가 다른 트랜잭션에 안 보인다는 것도 이 맥락의 뜻에 함께 붙어 있습니다. 그 가림을 어느 정도까지 하느냐는 격리 수준이 정합니다. 세이브포인트는 트랜잭션 안에 되돌아갈 지점을 두는 장치입니다. 둘 다 각각 별도 항목이 받습니다.

분산

MySQL 참조 매뉴얼은 XA 지원이 InnoDB 스토리지 엔진에서 제공된다고 적습니다. MySQL 의 XA 구현은 X/Open CAE 문서인 「Distributed Transaction Processing: The XA Specification」에 바탕을 둡니다. 트랜잭션 자원은 대개 관계형 데이터베이스 관리 시스템이지만 다른 종류의 자원일 수도 있다고 적습니다.

전역 트랜잭션을 실행하는 과정은 2단계 커밋(two-phase commit)을 씁니다. 전역 트랜잭션의 가지들이 수행할 동작을 이미 끝낸 뒤에 이 과정이 일어납니다.

flowchart TD
    T["트랜잭션 매니저"] --> R1["자원 관리자"]
    T --> R2["자원 관리자"]
    R1 --> B1["전역 트랜잭션의 가지"]
    R2 --> B2["전역 트랜잭션의 가지"]

Jakarta Transactions 명세는 이 자리에 누가 서는지를 이름으로 적어 둡니다. 트랜잭션 매니저와 분산 트랜잭션 시스템에 관여하는 쪽들 사이의 자바 인터페이스를 규정합니다. 관여하는 쪽은 애플리케이션, 자원 관리자, 애플리케이션 서버입니다. 자원을 묶어 두면 트랜잭션 매니저가 자원 관리자들과 2단계 커밋 프로토콜을 진행할 수 있습니다. 그 진행 방식은 X/Open XA 명세가 정합니다. XAResource 인터페이스를 지원하는 Jakarta Messaging 제공자는 자원 관리자로서 이 시스템에 참여할 수 있습니다.

메일

RFC 5321 은 메일 트랜잭션의 세 단계를 순서로 적습니다. 트랜잭션은 보내는 쪽을 식별하는 MAIL 명령으로 시작합니다. 이어서 받는 쪽 정보를 주는 RCPT 명령이 하나 이상 따라옵니다. 그다음 DATA 명령이 메일 데이터 전송을 시작합니다. 전송은 메일 끝 표시로 끝납니다. 그 표시가 트랜잭션을 확정합니다.

sequenceDiagram
    participant 클라이언트
    participant 서버
    클라이언트->>서버: MAIL 로 보내는 쪽을 알림
    클라이언트->>서버: RCPT 로 받는 쪽을 알림
    서버-->>클라이언트: 250 OK 또는 550
    클라이언트->>서버: DATA 로 본문을 보냄
    Note over 클라이언트,서버: 메일 끝 표시가 트랜잭션을 확정한다

RCPT 단계는 몇 번이든 되풀이할 수 있습니다. 받아들여지면 서버는 250 OK 응답을 돌려줍니다. 그리고 forward-path 를 저장합니다. 배달할 수 없는 주소로 알려진 수신자면 서버는 550 응답을 돌려줍니다. 메일 끝 표시는 트랜잭션을 확정합니다. 동시에 저장해 둔 수신자와 메일 데이터를 이제 처리하라고 서버에 알립니다.

여기가 데이터베이스 쪽과 갈리는 자리입니다. RFC 5321 은 실제로는 본문을 다 받은 뒤에야 수신자 확인을 하는 서버들이 있다고 적습니다. 그런 서버에 이 문서가 권하는 처리는 둘입니다. 수신자 하나 이상에 대한 실패를 후속 실패로 다루는 것, 그리고 메일 메시지를 돌려보내는 것입니다. 한 벌로 묶여 있어도 전부 아니면 전무가 아닙니다.

블록체인

ethereum.org 개발자 문서는 트랜잭션을 계정이 암호학적으로 서명한 지시라고 적습니다. 계정은 이더리움 네트워크의 상태를 갱신하려고 트랜잭션을 시작합니다. 여기서 말하는 계정은 외부 소유 계정(externally-owned account)입니다. 컨트랙트가 아니라 사람이 관리하는 계정이라는 뜻입니다.

문서가 드는 예는 한 사람이 다른 사람에게 이더를 보내는 일입니다. 보내는 쪽 계정에서는 빠집니다. 받는 쪽 계정에는 더해집니다. 이 상태 변경 동작이 트랜잭션 안에서 일어납니다.

제출된 트랜잭션에는 서명이 들어갑니다. 보내는 쪽의 개인 키가 트랜잭션에 서명할 때 만들어지는 값입니다. 서명은 보낸 쪽이 이 트랜잭션을 승인했음을 확인해 줍니다. nonce 도 들어갑니다. 그 계정이 보낸 트랜잭션 번호를 가리키는, 순차적으로 올라가는 계수기입니다. 서명 해시가 있으면 이 트랜잭션이 보낸 쪽에서 왔다는 것을 암호학적으로 증명할 수 있습니다.

flowchart TD
    A["외부 소유 계정"] -- "개인 키로 서명" --> T["트랜잭션 · 지시 한 개"]
    T --> N["이더리움 네트워크"]
    N --> S1["보내는 계정에서 빠짐"]
    N --> S2["받는 계정에 더해짐"]

배경

먼저 있던 것은 서로를 못 믿는 자리의 불편입니다. Jim Gray 는 1981년 글 「The Transaction Concept: Virtues and Limitations」에서 트랜잭션 개념이 계약법에서 왔다고 적습니다. 계약을 맺을 때 둘 이상의 당사자가 한동안 협상한 뒤 거래를 맺습니다. 그 거래는 문서에 함께 서명하거나 그에 준하는 행위로 구속력을 얻습니다. 악수나 고갯짓처럼 간단한 행위여도 됩니다.

서로를 꽤 의심하거나 그저 안전하게 가고 싶은 당사자들은 중개자를 세운다고 Gray 는 적습니다. 그 중개자가 트랜잭션의 확정을 조율합니다. Gray 는 이 자리를 대개 에스크로 담당자라고 부른다고 적습니다. 이미 맺힌 거래를 손보는 방법도 계약법에서 그대로 옵니다. 계약은 애초에 불법이었을 때만 무효로 할 수 있습니다. 어긋난 트랜잭션의 조정은 보상 트랜잭션을 더 걸어서 합니다.

Gray 는 이 개념이 세 성질을 갖고 나타난다고 정리합니다. 일관성은 트랜잭션이 규정된 절차를 지켜야 한다는 것입니다. 원자성은 일어나거나 일어나지 않거나 둘 중 하나라는 것입니다. 모두가 계약에 묶이거나 아무도 안 묶입니다. 지속성은 한번 커밋된 트랜잭션은 취소되지 않는다는 것입니다. 이 개념이 계약이라는 뿌리에서 왔다는 것이 Gray 의 설명입니다. 데이터베이스가 이 말을 만들어 낸 쪽이 아니라 가져다 쓴 쪽이라는 뜻이기도 합니다.

관련 항목

데이터베이스 트랜잭션을 다루는 명령·장치

BEGIN · COMMIT · ROLLBACK · 커밋 · 세이브포인트 · 격리 수준

트랜잭션을 규정하는 언어와 구현 제품

SQL · PostgreSQL · MySQL · InnoDB

분산 트랜잭션을 규정하는 표준·인터페이스

XA · XAResource · Jakarta Transactions

분산 트랜잭션에 관여하는 역할·참여자

트랜잭션 매니저 · 자원 관리자 · 애플리케이션 서버

분산 트랜잭션이 놓이는 상위 개념·프로토콜

전역 트랜잭션 · 분산 시스템 · 2단계 커밋

메일 트랜잭션을 이루는 명령

MAIL · RCPT · DATA

메일 트랜잭션이 오가는 프로토콜과 응답

SMTP · forward-path · 상태 코드

블록체인 트랜잭션을 이루는 구성 요소

서명 · 개인 키 · nonce

블록체인 트랜잭션이 오가는 네트워크와 계정

이더리움 · 외부 소유 계정 · 컨트랙트

트랜잭션이 계약법에서 물려받은 개념

원자성 · 일관성 · 지속성 · 보상 트랜잭션 · 에스크로