1장. 장부 앞의 회계사

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

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

복식부기는 왜 두 번 적었나 → 한쪽만 적히면 무엇이 깨지나 → 둘 다 되거나 둘 다 안 되는 약속이 어떻게 트랜잭션이 되었나.

면접 실전 질문: ① 복식부기와 원자성의 관계 ② 부분 실패가 위험한 이유 ③ BEGIN/COMMIT/ROLLBACK의 역할

배경 — 코드가 등장하기 500년 전

트랜잭션이라고 하면 보통 DB, BEGIN, COMMIT 같은 단어를 떠올립니다. 그런데 트랜잭션의 핵심 아이디어는 컴퓨터보다 500년쯤 먼저 나왔어요. 데이터베이스는커녕 전기도 없던 시절, 장부에 펜으로 숫자를 적던 사람들의 손끝에서요.

왜 하필 회계일까요? 돈을 다루는 일이 틀리면 안 되는 일의 원조이기 때문입니다. 계산이 반만 맞는 장부는 아예 없느니만 못하죠. “정확하게, 그리고 완전하게” 기록해야 한다는 압박 — 우리가 트랜잭션에 기대하는 바로 그것 — 을 사람들은 이미 수백 년 전에 온몸으로 겪고 있었습니다.

스토리 — 두 번 적는 사람들

15세기 이탈리아, 베네치아의 상인들에게는 골치 아픈 문제가 있었습니다. 거래는 점점 많아지는데, 장부에 한 줄씩 적다 보면 어디서 돈이 새는지 도무지 알 수가 없었죠. 여기서 등장한 게 복식부기(double-entry bookkeeping) 입니다.

규칙은 이래요. 모든 거래를 두 번, 장부의 양쪽에 나눠 적는다. 예를 들어 물건을 팔고 현금 100을 받았다면, 한쪽에는 “현금 100이 들어왔다”를, 다른 쪽에는 “매출 100이 생겼다”를 동시에 기록합니다. 1494년, 수학자 루카 파치올리가 이 방식을 책으로 정리해 세상에 퍼뜨렸어요. (그가 발명한 건 아니고, 상인들이 이미 쓰던 걸 문서로 박제한 겁니다.)

여기서 마법 같은 성질이 하나 생깁니다. 제대로만 적으면 양쪽 합계가 항상 똑같아요. 왼쪽 합과 오른쪽 합이 어긋났다? 그럼 어딘가 기록을 하다 말았다는 뜻입니다. 장부가 스스로 “나 지금 뭔가 빠졌어”라고 알려주는 거죠.

문제는 사람이라는 겁니다. 회계사가 한쪽 장부에 100을 적고, 반대쪽을 적기 직전에 누가 부르거나, 촛불이 꺼지거나, 그냥 깜빡 졸면? 장부는 한쪽만 100이 늘어난 채 어긋난 상태로 남습니다. 다음 날 아침, 맞지 않는 숫자 앞에서 회계사는 등에 식은땀이 납니다.

그래서 좋은 회계사에게는 규율이 있었습니다. 한 거래의 두 기록은 반드시 한 묶음으로 끝낸다. 둘 다 적거나, 둘 다 안 적거나. 중간에 멈추지 않는다. 익숙하지 않나요?

핵심 — 이게 바로 원자성과 일관성이다

500년 전 회계사의 규율을 현대 용어로 번역하면 이렇게 됩니다.

“두 기록을 한 묶음으로, 중간에 멈추지 않는다” → 원자성(Atomicity). 하나의 작업 단위는 전부 되거나 전부 안 되거나, 둘 중 하나다.
“자산 = 부채 + 자본이라는 등식은 항상 성립한다” → 일관성(Consistency). 거래가 끝난 뒤에도 데이터는 늘 “말이 되는 상태”여야 한다.

그리고 이 모든 규율이 막으려던 단 하나의 적이 있습니다. 부분 실패(partial failure) — 작업의 일부만 반영되고 나머지는 날아간 상태. 트랜잭션이라는 개념이 평생을 싸우는 상대가 바로 이겁니다.

여는 글의 계좌 이체를 다시 볼까요. 오늘날 이 거래는 이렇게 생겼습니다.


-- A가 B에게 100 보내기
UPDATE account SET balance = balance - 100 WHERE id = 'A';  -- ①
UPDATE account SET balance = balance + 100 WHERE id = 'B';  -- ②

①과 ② 사이에서 서버가 죽으면? A의 돈은 사라졌는데 B는 못 받았습니다. 500년 전 회계사를 괴롭히던 그 “어긋난 장부”가, 이번엔 초 단위로 재현되는 거예요. 그래서 우리는 이 두 줄을 하나의 묶음으로 감쌉니다.


BEGIN;                                                       -- 여기서부터 한 묶음
UPDATE account SET balance = balance - 100 WHERE id = 'A';
UPDATE account SET balance = balance + 100 WHERE id = 'B';
COMMIT;                                                      -- 여기까지 왔으면 둘 다 확정

BEGIN과 COMMIT 사이는 회계사가 두 장부를 적는 그 순간과 똑같습니다. 중간에 무슨 일이 생기면 ROLLBACK, 즉 “방금 건 없던 걸로” 하고 원래대로 되돌립니다. 촛불이 꺼져도 장부가 어긋나지 않도록.

결국 트랜잭션은 대단히 새로운 발명이 아닙니다. 틀리면 안 되는 일을 다루는 사람들이 수백 년간 손으로 지켜온 규율을, 컴퓨터가 대신 지키게 만든 것입니다. 다음 장부터 우리는 그 규율이 어떻게 코드의 세계로 넘어왔는지를 따라갑니다.

정리

트랜잭션의 아이디어는 컴퓨터 이전, 복식부기(1494, 파치올리 정리)에서 이미 살아 있었다.
복식부기의 “두 번 적기”는 원자성을, “합계가 항상 맞는다”는 일관성을 손으로 구현한 것.
이 모든 규율의 공통 적은 부분 실패 — 일부만 반영되고 나머지가 날아간 상태.

생각해볼 질문: 회계사는 “졸음”이나 “꺼진 촛불” 때문에 장부가 어긋났습니다. 그렇다면 오늘날 우리의 BEGIN ... COMMIT을 위협하는 “꺼진 촛불”은 무엇일까요? (힌트: 2장에서 만날 겁니다.)

▶ 2장 · 파일과 씨름하던 프로그래머들

Last updated on August 22, 2026

Overview