---
title: "동시에 실행해도 순서대로 한 것처럼: 직렬 가능성"
author: "Lee"
published_at: "2026-10-04T09:07:04.793Z"
updated_at: "2026-09-30T09:50:10.491Z"
tags: ["컴퓨터공학","데이터베이스"]
canonical_url: "https://ariser.io/@writer_a1cd615ab19e/%EB%8F%99%EC%8B%9C%EC%97%90-%EC%8B%A4%ED%96%89%ED%95%B4%EB%8F%84-%EC%88%9C%EC%84%9C%EB%8C%80%EB%A1%9C-%ED%95%9C-%EA%B2%83%EC%B2%98%EB%9F%BC-%EC%A7%81%EB%A0%AC-%EA%B0%80%EB%8A%A5%EC%84%B1"
ai_assisted: false
---

# 동시에 실행해도 순서대로 한 것처럼: 직렬 가능성

[원문](https://ariser.io/@writer_a1cd615ab19e/%EB%8F%99%EC%8B%9C%EC%97%90-%EC%8B%A4%ED%96%89%ED%95%B4%EB%8F%84-%EC%88%9C%EC%84%9C%EB%8C%80%EB%A1%9C-%ED%95%9C-%EA%B2%83%EC%B2%98%EB%9F%BC-%EC%A7%81%EB%A0%AC-%EA%B0%80%EB%8A%A5%EC%84%B1)

직렬 가능성은 동시에 섞여 실행한 트랜잭션들의 효과가 어떤 직렬 실행과 동등해야 한다는 정확성 기준이다. 직렬 실행은 한 트랜잭션을 마친 뒤 다음 트랜잭션을 수행하는 방식이다. 실제 실행을 반드시 직렬로 만들라는 요구는 아니며, 중첩 실행의 이점을 유지하면서 허용된 결과를 검토하는 기준이다.

![충돌 그래프에 사이클이 없는 실행과 두 트랜잭션 사이에 사이클이 생긴 실행을 비교한 그림](/api/v1/media/5c7a46b2-5e0c-4aff-a955-4e5289aa68a9)

*충돌 직렬 가능성은 선행 그래프의 사이클 유무로 검토할 수 있다.*

### 실행 순서보다 결과의 관계를 본다
두 트랜잭션이 같은 데이터를 읽고 쓸 때 어떤 순서로 충돌했는지가 중요하다. 서로 다른 항목만 다루거나 같은 값을 읽기만 하는 작업은 보통 이 관점의 충돌을 만들지 않는다. 같은 항목에서 적어도 한 작업이 쓰기일 때 순서를 바꾸면 관찰과 결과가 달라질 수 있다.

T1이 x를 읽은 뒤 T2가 x를 쓰면 충돌의 순서에서 T1이 T2보다 앞서야 한다는 간선을 그릴 수 있다. 반대로 T2가 y를 읽은 뒤 T1이 y를 쓰면 T2에서 T1으로 간선이 생긴다. 두 간선이 함께 있으면 어느 직렬 순서로도 이 충돌 순서를 모두 유지할 수 없는 사이클이 된다.

이 선행 그래프가 순환하지 않으면 해당 스케줄은 충돌 직렬 가능하다. 그래프의 위상 순서가 대응하는 직렬 순서를 제공한다. 사이클 검사는 모든 형태의 직렬 가능성을 완전히 같은 방식으로 판정하는 정의가 아니라 충돌 직렬 가능성이라는 널리 쓰이는 기준에 해당한다. 더 일반적인 뷰 직렬 가능성과는 차이를 둘 수 있다.

### 안전한 결과가 최신 실시간 순서와 같지는 않다
직렬 가능성만으로 선택된 직렬 순서가 외부의 실시간 순서까지 따르리라고 단정해서는 안 된다. 이미 완료된 작업 뒤에 시작한 작업을 현실의 순서대로 취급하는 성질은 추가적인 논의가 필요하다. 분산 시스템의 선형 가능성과 데이터베이스 트랜잭션의 직렬 가능성은 대상과 요구를 구분해 이해해야 한다.

은행 업무가 순서대로 실행될 때 항상 옳다고 입증되었다면, 커밋한 실행이 직렬 가능하다는 보장은 그 논증을 동시 실행에도 연결하는 기반이 된다. 다만 트랜잭션의 코드 자체가 잘못되었으면 어떤 직렬 순서도 업무를 올바르게 만들지 못한다. 데이터베이스의 동시성 기준과 업무 불변식의 검증은 함께 필요하다.

2단계 잠금처럼 충돌을 제어하는 방식이나, 낙관적으로 실행한 뒤 검증하는 방식으로 직렬 가능성을 지원할 수 있다. 여러 버전을 유지하는 방식도 적절한 추가 제어가 필요하다. 단순한 스냅샷 격리가 읽기 안정성을 주더라도 쓰기 편향 같은 비직렬 실행을 허용할 수 있기 때문이다.

직렬화 실패는 DB가 고장났다는 신호만은 아니다. 허용할 수 없는 의존성 조합을 발견하여 한 트랜잭션을 취소한 정상적인 제어 결과일 수 있다. 응용은 같은 트랜잭션의 판단과 변경을 전체 단위로 다시 수행해야 할 수 있으며, 외부 효과의 중복도 고려해야 한다.

수강 정원이 한 자리 남은 상황에서 두 사용자가 각각 여유를 읽고 다른 등록 행을 추가하는 예를 떠올려 보자. 서로 다른 행을 썼다는 이유로 안전한 것은 아니다. 읽은 정원 조건과 상대의 쓰기 사이에 의존성이 생긴다. 행별 충돌만 보기보다 질의 조건과 여러 작업의 관계를 함께 살펴야 한다.

스케줄을 검토할 때는 각 읽기와 쓰기, 대상 데이터, 커밋과 취소를 시간 순서로 적는다. 이어 충돌 간선을 그려 한 직렬 순서가 가능한지 확인한다. 이 과정을 익히면 동시 실행이 빠르게 끝났다는 사실과 결과가 올바르다는 사실을 구분하고, 격리 설정이 실제로 어떤 약속을 제공해야 하는지 설명할 수 있다.

### 참고 자료

- [CMU Concurrency Control Theory](https://15445.courses.cs.cmu.edu/fall2025/notes/17-concurrencycontrol.pdf)
- [PostgreSQL Serializable Isolation](https://www.postgresql.org/docs/current/transaction-iso.html)