ACID 보장을 갖춘 신뢰할 수 있는 지갑 전송 시스템 설계 pt - 3 (Isolation)

발행: (2026년 3월 29일 PM 06:07 GMT+9)
3 분 소요
원문: Dev.to

Source: Dev.to

격리

여러 트랜잭션이 서로 간섭하지 않고 독립적으로 실행되도록 보장합니다. 동시에 실행될 때도 마찬가지입니다.

설정

-- Create the accounts table
CREATE TABLE accounts (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    balance INT NOT NULL CHECK (balance >= 0),
    last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Insert dummy data
INSERT INTO accounts (name, balance)
VALUES ('Alice', 1000), ('Bob', 500);

초기 잔액:

  • Alice = 1000
  • Bob = 500

격리 테스트

트랜잭션 1

BEGIN;

UPDATE accounts
SET balance = balance - 500
WHERE name = 'Alice';

트랜잭션 2 (동시 실행)

BEGIN;

UPDATE accounts
SET balance = balance - 700
WHERE name = 'Alice';

적절한 격리 없이

  • 두 트랜잭션이 동일한 초기 잔액(1000)을 읽을 수 있습니다.
  • 각 업데이트가 오래된 데이터를 기반으로 진행됩니다.
  • 잘못된 최종 잔액(경합 조건)이 발생할 수 있습니다.

적절한 격리와 함께

  • 한 트랜잭션이 다른 트랜잭션이 같은 행에 영향을 주기 전에 실행되거나 완료됩니다.
  • 두 번째 트랜잭션은 대기하거나 업데이트된 값을 보게 됩니다.
  • 일관성 없는 업데이트가 방지되고 최종 잔액이 올바르게 유지됩니다.

메커니즘

격리는 다음과 같은 메커니즘을 통해 유지됩니다:

  • 낙관적 잠금 – 커밋 전에 충돌을 검사합니다.
  • 비관적 잠금 – 잠금이 해제될 때까지 다른 트랜잭션을 차단합니다.

데이터베이스가 두 트랜잭션이 서로 간섭하지 못하게 하고 올바른 결과를 유지한다면, 격리가 의도대로 작동하고 있는 것입니다.

0 조회
Back to Blog

관련 글

더 보기 »

ALTER 쿼리

이번 과제에서는 ALTER TABLE을 사용하여 기존 테이블을 수정하는 작업을 수행했습니다. 이를 통해 테이블을 다시 생성하지 않고도 제약 조건을 업데이트하는 방법을 이해할 수 있었습니다. Task...

CA 36 – 격리 (ACID)

시나리오 이 실험은 두 세션이 동일한 계좌에 동시에 작업하려 할 때 ACID의 Isolation 특성이 어떻게 작동하는지를 보여줍니다. 단계 세션...