4장. SQL 표준이 세운 약속

만화로 보는 요약 — 먼저 읽어보세요

만화로 보는 요약 — 먼저 읽어보세요

제품마다 다른 SQL 사투리가 생겼다 → 표준이 COMMIT과 ROLLBACK의 뜻을 공용 계약으로 묶었다 → 이식성과 신뢰가 생겼지만 현실 구현은 조금씩 다르다.

면접 실전 질문: ① SQL 표준이 필요한 이유 ② COMMIT/ROLLBACK이 공용어가 된 의미 ③ 표준과 실제 DB 구현의 차이

배경 — 좋은 아이디어의 위험한 시기

3장 끝에서 물었죠. 한 실험실(System R)의 아이디어가 어떻게 온 산업의 공용어가 됐을까? 그 답에 다다르기 전에, 좋은 아이디어가 겪는 위험한 시기를 짚고 갈게요.

새로운 개념이 뜨면 무슨 일이 벌어지냐면 — 다들 각자 만들기 시작합니다. 트랜잭션도 그랬어요. “전부 되거나 전부 안 되거나”라는 아이디어는 훌륭했지만, 이걸 구현한 회사가 하나둘 늘면서 저마다 조금씩 다른 사투리를 쓰기 시작했습니다. 누구는 커밋을 이렇게, 누구는 저렇게. 좋은 아이디어가 파편으로 흩어질 뻔한 순간이었죠.

스토리 — 사투리에서 공용어로

System R이 관계형 DB가 “진짜 된다”는 걸 증명하자, 시장이 움직입니다. 1979년, 오라클(Oracle) 이 상용 SQL 데이터베이스를 처음 내놓고, 뒤이어 IBM의 DB2를 비롯한 상용 관계형 제품이 잇따라 나왔어요. 관계형 DB의 시대가 열린 겁니다.

문제는 저마다 SQL이 미묘하게 달랐다는 거예요. A사 DB에서 짠 쿼리가 B사 DB에선 안 돌아갑니다. 트랜잭션을 시작하고 끝내는 문법도, 세부 동작도 제품마다 달랐어요. 기업 입장에선 악몽이죠. DB 하나에 종속되면 갈아탈 수가 없으니까.

그래서 업계가 협상 테이블에 둘러앉습니다. 표준화 기구(ANSI, 그리고 국제표준 ISO)가 SQL 표준을 만들기 시작해요. 1986년 첫 표준(SQL-86)이 나옵니다. COMMIT·ROLLBACK 같은 트랜잭션 제어는 이미 이 초기 표준부터 담겼어요. 그리고 1992년의 SQL-92가 결정타를 날립니다. 트랜잭션이 동시에 얽힐 때 어디까지 허용할지를 단계로 나눈 격리 수준(isolation level) — 뒤에서 정면으로 만날 그 개념 — 을 표준에 못 박은 거죠.

이 순간이 중요합니다. 트랜잭션이 더 이상 “오라클의 기능”이나 “DB2의 기능”이 아니라, 산업 전체가 서명한 공용 계약이 된 거예요. 어느 회사 DB를 쓰든 COMMIT은 확정을 뜻하고 ROLLBACK은 취소를 뜻합니다. 사투리가 공용어가 된 거죠.

핵심 — 표준은 “이식성”과 “신뢰”의 계약서

표준화가 우리에게 준 실질적 이득은 두 가지입니다.

이식성(portability). 표준 SQL로 짠 트랜잭션은 특정 DB에 묶이지 않습니다. MySQL에서 PostgreSQL로 옮겨도 START TRANSACTION … COMMIT의 의미는 그대로예요.
신뢰(공통의 약속). “COMMIT하면 확정된다”를 제품마다 다시 의심할 필요가 없습니다. 모두가 같은 뜻으로 쓰니까.

트랜잭션을 제어하는 이 표준 구문들을 TCL(Transaction Control Language) 이라 부릅니다.


START TRANSACTION;     -- 트랜잭션 시작 (표준 구문. MySQL·PostgreSQL은 BEGIN도 허용)
  UPDATE account SET balance = balance - 100 WHERE id = 'A';
  UPDATE account SET balance = balance + 100 WHERE id = 'B';
COMMIT;                -- 정상 종료: 둘 다 확정

중간에 문제가 생겼다면? COMMIT 대신 이걸 부릅니다. 둘은 양자택일이에요.


ROLLBACK;              -- 시작 전 상태로 통째 되돌림 (COMMIT과 함께 쓰는 게 아니라, 대신 쓰는 것)

여기에 나중 표준(SQL:1999)에서 SAVEPOINT 가 더해집니다. 트랜잭션 중간에 “체크포인트”를 찍어두고, 문제가 생기면 전체가 아니라 그 지점까지만 되돌리는 장치예요. 핵심 작업은 지키고 부가 작업만 취소할 때 씁니다.


START TRANSACTION;
  INSERT INTO orders(user_id, amount) VALUES (7, 20000);  -- 핵심: 주문은 반드시 남긴다
  SAVEPOINT before_coupon;
  UPDATE coupon SET used = true WHERE id = 55;             -- 부가: 쿠폰 적용 시도
  -- 앗, 이미 만료된 쿠폰이었다!
  ROLLBACK TO before_coupon;                              -- 쿠폰 적용만 취소, 주문은 유지
COMMIT;                                                   -- 주문은 확정된다

그런데 여기서 이 책 후반부의 큰 복선을 하나 심어둘게요. 표준은 “최소한의 합의”일 뿐입니다. 표준이 “격리 수준은 이렇게 나뉜다”고 적어놨지만, 실제 DB들은 그 정의를 저마다 조금씩 다르게 구현해요. 심지어 기본값도 제품마다 다릅니다. 표준과 현실 사이의 이 틈은 11장에서 정면으로 다룹니다. 지금은 “표준이 있다고 다 똑같은 건 아니다”만 기억해 두세요.

자, 여기까지가 제1부입니다. 우리는 트랜잭션이 없던 세계에서 출발해(1·2장), 그 개념에 이름과 규칙이 붙고(3장), 산업의 공용 계약이 되는(4장) 과정을 따라왔어요. 이제 그 “약속”의 내용물을 열어볼 차례입니다. COMMIT이 지켜주겠다는 게 정확히 뭘까요? 그 답이 바로 네 글자, ACID입니다.

정리

좋은 아이디어(트랜잭션)는 여러 회사가 제각각 구현하며 사투리(dialect) 로 흩어질 뻔했다.
SQL 표준(ANSI/ISO)이 트랜잭션을 특정 제품 기능이 아닌 산업 공용 계약으로 만들었다. COMMIT/ROLLBACK은 초기 표준(SQL-86) 부터, 격리 수준은 SQL-92가 못 박았다.
표준의 실익은 이식성과 공통의 신뢰. 트랜잭션 제어 구문 = TCL(COMMIT, ROLLBACK, SAVEPOINT).
단, 표준은 최소 합의일 뿐 — 실제 DB는 조금씩 다르게 구현한다(11장 복선).

생각해볼 질문: 이제 트랜잭션에는 이름도, 규칙도, 표준도 생겼습니다. 그런데 정작 우리는 COMMIT이 무엇을 보장하는지를 아직 정확히 정의하지 않았어요. “안전하다”는 게 대체 몇 개의 약속으로 이루어져 있을까요? (2부에서 네 개로 쪼갭니다.)

▶ 5장 · 전부 아니면 전무 — 원자성

Last updated on August 22, 2026

Overview