3장. System R과 하나의 단어

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

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

로그와 잠금은 있었지만 이름이 없었다 → System R이 작업 단위에 transaction이라는 규칙을 붙였다 → 직렬성이 안전한 동시 실행의 기준이 되었다.

면접 실전 질문: ① System R이 트랜잭션에 준 정의 ② 논리적 작업 단위의 의미 ③ 직렬성이 안전성 기준인 이유

배경 — 이름이 없으면 다룰 수 없다

2장에서 우리는 이상한 상태를 봤습니다. 로그도 있고, 잠금도 있는데, 그걸 하나로 묶는 개념이 없었죠. 마치 ‘재료’는 다 있는데 ‘요리 이름’이 없는 상태예요. 이러면 무슨 일이 생기냐면 — 개발자마다 자기만의 방식으로 재료를 조합합니다. 누구는 잠금을 먼저, 누구는 로그를 나중에. 대화가 안 통해요.

엔지니어링에서 이름을 붙인다는 건 곧 다룰 수 있게 된다는 뜻입니다. “이 일련의 작업을 하나의 단위로 본다”에 이름과 규칙이 붙는 순간, 비로소 사람들은 같은 언어로 이야기하고, 그걸 코드로 강제할 수 있게 됩니다. 그 이름이 붙은 곳이 바로 이 장의 무대예요.

스토리 — 산호세의 실험실

1970년, IBM의 연구원 에드거 코드(Edgar Codd) 가 논문 하나를 냅니다. 데이터를 표(테이블)로 다루자는 관계형 모델. 우아했지만, 다들 반신반의했어요. “이론은 좋은데, 진짜 그렇게 만들면 느려서 못 쓸걸?”

그 도발에 답하려고 IBM 산호세 연구소가 1970년대 중반 프로젝트 하나를 시작합니다. 관계형 모델을 실제로 돌아가는 데이터베이스로 만들어 보는 실험, System R. 여기서 우리가 매일 쓰는 물건 두 개가 태어나요. 하나는 질의 언어 SEQUEL — 나중에 이름이 SQL로 바뀝니다. 그리고 다른 하나가, 이 책의 주인공이죠.

System R 팀에는 짐 그레이(Jim Gray) 라는 사람이 있었습니다. 그와 동료들은 2장이 남긴 그 빈자리 — “흩어진 재료를 하나로” — 를 정면으로 팠어요. 잠금을 어떻게 걸어야 안전한지(2단계 잠금), 사고가 나면 로그로 어떻게 되돌리는지(복구), 그리고 무엇보다 “동시에 실행해도 안전하다는 게 대체 무슨 뜻인지” 를 이론으로 정의했습니다.

그리고 이 모든 걸 하나로 묶는 단어에 기술적인 의미와 규칙을 부여합니다. transaction(트랜잭션). 사실 이 단어 자체는 은행·상거래에서, 또 초기 전산에서도 느슨하게 쓰이던 평범한 말이었어요. System R이 한 건, 이 일상어에 “전부 되거나 전부 안 되는, 하나의 논리적 작업 단위” 라는 정확한 정의와 규칙을 새겨 넣은 겁니다.

훗날 짐 그레이는 이 공로를 포함한 업적으로 1998년 튜링상(컴퓨터 과학의 노벨상)을 받습니다. 파일과 씨름하던 개발자들의 삽질을 한 단어와 규칙으로 정리한 값 — 그게 튜링상이었던 셈이죠.

핵심 — 트랜잭션이라는 “논리적 작업 단위”

System R이 못박은 정의를 코드로 보면 이렇게 생겼습니다.


BEGIN;                      -- 여기서부터 하나의 작업 단위
  UPDATE concert SET taken_seats = taken_seats + 1 WHERE id = 42;
  INSERT INTO ticket(user_id, concert_id) VALUES (7, 42);
COMMIT;                     -- 둘 다 확정. 하나라도 실패하면 ROLLBACK으로 통째 취소

BEGIN과 COMMIT 사이는 하나의 단위입니다. 좌석을 늘리는 것과 티켓을 발급하는 것은 “둘 다 되거나, 둘 다 안 되거나”. 1장 회계사의 두 장부, 그대로예요. System R이 새로 준 건 이걸 DB가 강제로 보장한다는 점입니다. 개발자가 방어 코드를 손으로 짤 필요가 없어진 거죠.

여기에 그레이 팀이 더한 결정적 한 방이 직렬성(serializability) 입니다. 질문은 이거였어요. “여러 트랜잭션이 동시에 얽혀 돌아가는데, 이게 안전한지 어떻게 판단하지?” 답은 놀랍도록 단순합니다.

동시에 실행한 결과가, 그것들을 어떤 순서로든 하나씩 실행한 결과와 같다면 — 안전하다.

순서대로 하나씩 처리하면 서로 밟을 일이 아예 없으니, 그게 “확실히 옳은” 기준선이 되는 거예요. 2장의 lost update(출금이 증발하던 그 사고)를 떠올려 보세요. 그건 “동시 실행 결과”가 “순서대로 한 결과”와 달랐기 때문에 터진 겁니다. 직렬성은 이 “다름”을 잡아내는 자(尺)예요. 앞으로 만날 격리 수준, 잠금, MVCC — 전부 이 자를 만족시키려는 서로 다른 전략입니다.

정리하면, System R은 트랜잭션에 정의(하나의 작업 단위) + 판단 기준(직렬성) + 구현 도구(잠금·로그) 를 한 세트로 줬습니다. 오늘날 우리가 @Transactional 한 줄로 누리는 모든 것의 설계도가 이때 그려진 거예요.

정리

2장의 “흩어진 재료”에 이름이 붙은 곳이 System R(IBM 산호세, 1970년대 중반). 관계형 모델의 실증 프로젝트에서 SQL의 조상(SEQUEL) 과 트랜잭션 개념이 함께 나왔다.
transaction은 원래 상거래 용어였지만, System R이 “전부 되거나 전부 안 되는 하나의 논리적 작업 단위”라는 기술적 정의와 규칙을 새겼다.
짐 그레이 팀은 직렬성이라는 판단 기준을 세웠다: 동시 실행 결과 = 순서대로 실행한 결과이면 안전하다. 이후의 모든 동시성 기법이 이 자를 만족시키려는 시도다.

생각해볼 질문: System R은 한 연구소의 실험이었습니다. 그런데 지금은 MySQL, PostgreSQL, Oracle… 저마다 다른 회사의 DB가 똑같은 COMMIT/ROLLBACK을 쓰죠. 한 실험실의 아이디어는 어떻게 온 산업의 공용어가 됐을까요? (4장에서 만납니다.)

▶ 4장 · SQL 표준이 세운 약속

Last updated on August 22, 2026

Overview