트랜잭션으로 DB 변경을 예측 가능하게 만들기

I’m happy to translate the article for you, but I’ll need the full text of the article (the content you’d like translated). Could you please paste the article’s body here? Once I have the text, I’ll provide a Korean translation while keeping the source link and all formatting exactly as you requested.

Introduction

안녕하세요, 저는 Maneshwar입니다. 현재 FreeDevTools online에서 모든 개발 도구, 치트 코드, TLDR을 한 곳에 모은 무료 오픈소스 허브를 만들고 있습니다. 개발자들이 인터넷을 여기저기 뒤져볼 필요 없이 빠르게 도구를 찾고 사용할 수 있도록 하는 것이 목표입니다.

이전 포스트에서는 인덱스가 효율적인 접근 경로를 정의하고, DBMS가 애플리케이션과 스토리지 사이에 위치해 파일, 디스크, 장애로부터 애플리케이션을 보호한다는 것을 살펴보았습니다.

하지만 인덱스와 스키마만으로는 해결할 수 없는 더 깊은 문제가 있습니다.

데이터베이스는 정적인 것이 아닙니다. 시간에 따라 변화하는 실제 시스템을 모델링합니다.

주문이 들어오고, 결제가 처리되며, 학생이 등록하고, 잔액이 변합니다. 이러한 변화는 다음과 같은 상황에서도 정확히 데이터베이스에 반영되어야 합니다:

• 여러 사용자가 동시에 작업할 때
• 애플리케이션이 실패할 때
• 시스템이 충돌할 때
• 전원이 작업 중에 끊길 때

이때 트랜잭션이라는 개념은 피할 수 없게 됩니다.

왜 트랜잭션이 필요한가

사용자는 개념적 수준에서 데이터를 봅니다—관계, 속성, 제약 조건 등. 내부적으로 DBMS는 데이터를 파일과 블록에 저장하고, 인덱스와 메타데이터를 관리합니다.

응용 프로그램은 현실 세계의 사건을 반영하도록 데이터베이스를 수정합니다. 이러한 수정은 종종 여러 관련 데이터 항목을 포함합니다.

예시

• 한 계좌에서 돈을 차감
• 다른 계좌에 추가
• 이체를 기록

이러한 업데이트는 상호 일관성을 유지해야 합니다.

업데이트 중 발생할 수 있는 두 가지 주요 위험

1. 일시적인 불일치

   • 응용 프로그램이 로직을 중간에 수행하고 있는 동안, 데이터베이스는 중간 상태에 있을 수 있습니다.
   • 다른 응용 프로그램이 이 상태를 보게 되면, 완벽하게 작성되었더라도 잘못 동작할 수 있습니다.

2. 업데이트 중 실패

   • 응용 프로그램이 충돌할 수 있습니다.
   • 시스템이 재부팅될 수 있습니다.
   • 전원이 끊길 수 있습니다.
   • 데이터베이스가 부분적으로 업데이트된, 일관성 없는 상태로 남을 수 있습니다.

접근되지 않는 데이터베이스는 일관성을 유지하고 있다고 가정합니다.

• 읽기 작업은 일관성을 유지합니다.
• 쓰기 작업은 일시적으로 일관성을 깨뜨립니다.

DBMS는 이러한 일시적인 불일치가

• 다른 사용자에게 절대 보이지 않도록
• 실패로 인해 영구적으로 남지 않도록

보장해야 합니다.

일관성 단위로서의 트랜잭션

이 문제를 해결하기 위해 애플리케이션의 데이터베이스 작업을 함께 묶습니다. 이 묶음을 트랜잭션이라고 합니다.

트랜잭션은 논리적 작업 단위입니다:

• 여러 하위 수준 데이터베이스 작업으로 구성됨
• 데이터베이스를 한 일관된 상태에서 다른 일관된 상태로 변환하도록 설계됨

격리된 상태에서 실행될 때, 트랜잭션은 데이터베이스 일관성을 유지합니다. 트랜잭션이 활성화되어 있는 동안, DBMS는 다음과 같이 가정합니다:

“데이터베이스가 지금은 일관성이 없을 수 있습니다.”

따라서 트랜잭션이 끝날 때까지 DBMS는 예방 조치를 취합니다.

What Exactly Is a Transaction?

A transaction은 데이터 항목에 대한 일련의 작업입니다. DBMS의 책임은 이 일련의 작업을 외부 세계에 다음과 같이 보이게 하는 것입니다:

• Indivisible
• Instantaneous

다른 트랜잭션의 관점에서 보면:

• 전체 트랜잭션이 발생했거나, 또는
• 전혀 발생하지 않았습니다

보이는 중간 상태는 없습니다. 이 개념은 현대 데이터베이스 시스템의 핵심입니다. 거의 모든 주요 데이터베이스 추상화—SQL, 격리 수준, 복구 로그—는 트랜잭션을 지원하기 위해 존재합니다.

Key points

• 애플리케이션에 의해 시작됨
• 애플리케이션 로직에 의해 정의됨
• DBMS가 일관성 단위로 가정함
• 현실 세계의 이벤트를 나타냄 (발생하거나 발생하지 않음)

커밋, 중단, 그리고 완료

각 DBMS는 애플리케이션이 다음을 수행할 수 있는 트랜잭션 인터페이스를 제공합니다:

1. 트랜잭션 시작

2. 데이터베이스 작업 실행

3. 트랜잭션 완료는 두 가지 방법 중 하나로 수행됩니다:

   • 커밋
   • 중단

커밋

애플리케이션이 트랜잭션을 커밋하면 DBMS에 다음을 알립니다:

“이 트랜잭션에 의해 이루어진 모든 변경 사항은 영구적으로 적용되어야 합니다.”

커밋된 후에는 트랜잭션의 효과가 다음 상황에서도 유지되어야 합니다:

• 시스템 충돌
• 재시작
• 전원 장애

중단

트랜잭션이 중단될 때:

• 모든 효과를 제거해야 합니다
• 데이터베이스를 트랜잭션 시작 시점의 상태로 복구해야 합니다

중단은 다음과 같이 발생할 수 있습니다:

• 명시적으로, 애플리케이션에 의해 시작됨
• 암묵적으로, DBMS에 의해 강제됨(오류 또는 제약 조건 위반으로 인함)

두 경우 모두 트랜잭션이 커밋되거나 중단되면 완료된 것으로 간주됩니다. 애플리케이션은 데이터베이스와 트랜잭션을 통해서만 상호 작용할 수 있습니다.

Source: …

ACID 특성

동시성 및 장애가 존재하는 상황에서 정확성을 보장하는 것은 어렵습니다. 이를 관리하기 위해 DBMS는 ACID 라는 이름으로 알려진 일련의 특성을 보장합니다:

원자성 (Atomicity)

트랜잭션의 모든 작업은 다음 중 하나만 발생합니다:

• 모두 실행됨, 혹은
• 전혀 실행되지 않음

트랜잭션이 완료된 후에는 부분적인 효과가 존재하지 않습니다. 실패하거나 중단된 트랜잭션은 데이터베이스에 흔적을 남기지 않습니다.

일관성 (Consistency)

트랜잭션이 일관된 데이터베이스 상태에서 시작하고 격리된 상태로 실행된다면, 반드시 일관된 상태에서 종료되어야 합니다.

일관성은 다음을 포함합니다:

• 무결성 제약조건
• 올바른 애플리케이션 로직
• 유효한 상태 전이

DBMS가 제약조건을 강제하지만, 일관성의 의미는 애플리케이션과 데이터 모델에 의해 정의됩니다.

격리성 (Isolation)

트랜잭션이 동시에 실행될 수 있지만, 최종 결과는 마치 순차적으로 실행된 것처럼 보여야 합니다.

각 트랜잭션의 관점에서 보면:

• 혼자 실행되는 것처럼 보임
• 그 작업들은 순간적으로 발생한 것처럼 보임

격리성은 트랜잭션이 다음을 보지 못하도록 보호합니다:

• 일시적인 불일치
• 다른 트랜잭션의 부분적인 효과

지속성 (Durability)

트랜잭션이 커밋된 후에는:

• 그 효과가 영구히 유지되어야 함
• 시스템이 바로 뒤에 충돌하더라도

지속성은 디스크, 로그, 영속성에 대해 배운 모든 내용과 트랜잭션을 연결합니다.

DBMS가 보장하는 것과 보장하지 않는 것

DBMS가 보장하는 것:

• 커밋된 트랜잭션의 원자성, 일관성, 격리성, 지속성
• 로그와 체크포인트를 이용한 장애 복구
• 동시 트랜잭션 간 간섭을 방지하는 동시성 제어

DBMS가 보장하지 않는 것:

• 올바른 애플리케이션 로직(비즈니스 규칙은 애플리케이션이 강제)
• 개발자가 트랜잭션을 올바르게 작성하는지(예: 교착 상태 방지)
• 위 보장 외의 성능 특성(지연 시간, 처리량)

ACID 보증

• 원자성
• 격리성
• 내구성
• 무결성 제약 조건의 적용

DBMS 하지 않는다:

• 애플리케이션 의미를 이해하지 않는다
• 트랜잭션 경계를 결정하지 않는다
• 트랜잭션 내부의 작업을 재배열하지 않는다

애플리케이션 정의

• 트랜잭션이 수행하는 작업 
• 포함하는 연산 
• 커밋 또는 중단 시점 

DBMS는 발행된 연산 순서를 그대로 준수합니다.

여기까지 온 우리

현재 우리는 전체 추상화 사다리를 모두 올랐습니다:

• Disks는 영속성과 실패를 설명합니다
• Relations는 구조를 정의합니다
• Indexes는 접근 경로를 정의합니다
• The DBMS는 저장과 접근을 조정합니다
• Transactions는 시간에 따른 정확성을 정의합니다

남은 것은 DBMS가 실제로 어떻게 ACID를 구현하는가 입니다.

이는 곧 다음으로 이어집니다:

• Transaction management
• Concurrency control
• Failure recovery
• Checkpointing

이 메커니즘들은 이론이 실제 시스템 공학과 만나는 지점이며, 바로 다음 글이 시작되는 부분입니다.

👉 Check out: FreeDevTools

피드백이나 기여는 언제든 환영합니다!
온라인에 공개되어 있으며, 오픈‑소스이고 누구든지 사용할 수 있습니다.

⭐ Star it on GitHub: freedevtools