Hacker News 2026.06.08 62

우리는 미묘한 버그보다 'Serializable 격리 수준'을 더 무서워하는 걸까요?

데이터베이스의 '격리 수준', 들어보셨나요

여러 사용자가 동시에 같은 데이터베이스를 쓰면 문제가 생길 수 있어요. A가 잔액을 읽는 사이에 B가 그 잔액을 바꿔버리면, A는 이미 낡은 값으로 계산을 하게 되거든요. 이런 "동시에 일어나는 작업들이 서로 꼬이는 문제"를 막으려고 데이터베이스에는 격리 수준(isolation level)이라는 개념이 있어요.

격리 수준은 단계가 있어요. 가장 느슨한 것부터 가장 엄격한 것까지요. 그중 가장 엄격한 게 바로 Serializable(직렬화 가능)이에요. 이게 뭐냐면, 여러 트랜잭션이 동시에 돌아가더라도 마치 "한 번에 하나씩 순서대로 실행한 것과 똑같은 결과"를 보장해주는 거예요. 가장 안전한 모드인 셈이죠.

그런데 현실에서는 대부분의 개발자가 이 Serializable을 잘 안 써요. 보통 Read Committed라는 중간 단계를 기본으로 쓰거든요. 왜냐? "Serializable은 느리고, 충돌 나면 트랜잭션이 자꾸 실패해서 골치 아프다"는 인식이 강하기 때문이에요. 이번 글은 바로 그 인식에 의문을 던져요. "우리가 미묘한 버그보다 Serializable을 더 두려워하는 거 아니냐"고요.

느슨한 격리 수준이 만드는 함정

기본값인 Read Committed를 쓰면 어떤 일이 생기냐면요. 대표적으로 write skew(쓰기 비대칭)라는 함정이 있어요.

예를 들어볼게요. 병원에 의사 두 명이 당직을 서는데, 규칙이 "최소 한 명은 반드시 당직이어야 한다"예요. 두 의사가 동시에 "나 빠질래" 버튼을 눌렀다고 해봐요. 각자 트랜잭션 안에서 "지금 당직이 2명이네, 한 명 빠져도 되겠다"고 확인하고 둘 다 빠져버려요. 결과적으로 당직이 0명이 되는 거예요. 각각의 트랜잭션은 규칙을 지켰다고 생각했는데, 동시에 실행되니까 규칙이 깨진 거죠.

이런 버그가 무서운 이유는요, 평소엔 멀쩡하다가 트래픽이 몰리는 아주 드문 순간에만 터진다는 점이에요. 재현도 어렵고, 로그를 봐도 원인을 찾기가 정말 힘들어요. 반면 Serializable을 쓰면 데이터베이스가 이런 충돌을 알아서 감지하고 한쪽 트랜잭션을 실패시켜요. 그럼 우리는 그냥 재시도(retry)만 해주면 돼요.

그래서 진짜 느린가요

글의 핵심 주장은 이거예요. "성능 걱정 때문에 Serializable을 피한다지만, 정작 측정해본 적은 있느냐"는 거죠. PostgreSQL 같은 현대 데이터베이스는 SSI(Serializable Snapshot Isolation)라는 똑똑한 방식을 써요. 이게 뭐냐면, 무작정 모든 걸 잠그는(lock) 게 아니라, 실제로 충돌이 의심될 때만 개입하는 방식이에요. 그래서 옛날처럼 성능이 폭삭 주저앉지 않아요.

물론 공짜는 아니에요. 충돌이 감지되면 트랜잭션이 실패하니까, 애플리케이션 쪽에 "실패하면 다시 시도하는 로직"을 꼭 넣어야 해요. 글쓴이는 바로 이 retry 처리를 귀찮아하는 마음 때문에 다들 안전한 길을 포기하는 거라고 지적해요. 미묘한 버그를 디버깅하느라 밤새우는 것보다, retry 코드 한 번 잘 짜두는 게 낫지 않냐는 거죠.

업계 맥락에서 보면

사실 데이터베이스 진영마다 입장이 조금씩 달라요. CockroachDB나 글을 쓴 YDB 같은 분산 데이터베이스들은 아예 Serializable을 기본으로 밀어요. 분산 환경에선 미묘한 버그의 대가가 훨씬 크기 때문이에요. 반면 MySQL이나 PostgreSQL은 호환성과 성능을 이유로 더 느슨한 기본값을 유지하고 있고요. 이 논쟁은 "안전이 먼저냐, 성능이 먼저냐"라는 오래된 트레이드오프의 한 단면이에요.

한국 개발자에게

토스나 카카오페이처럼 돈을 다루는 금융·결제 서비스를 만든다면 이 주제는 남 얘기가 아니에요. 동시성 버그는 진짜 사고로 이어지거든요. 당장 모든 걸 Serializable로 바꾸라는 건 아니에요. 다만 "우리 서비스에서 동시에 일어나면 안 되는 규칙"이 뭔지 정리해보고, 그 부분만큼은 격리 수준을 높이거나 별도 잠금을 거는 걸 검토해볼 가치가 있어요. 그리고 한 번쯤은 직접 부하 테스트로 Serializable의 성능을 측정해보세요. 막연한 두려움이 사실이 아닐 수도 있거든요.