데이터베이스는 어떻게 정확성을 지킬까
비개발자를 위한 데이터베이스 정확성 원리 설명. 제약 조건, 트랜잭션, 인덱스, 복제와 백업이 두 사람의 동시 예매 같은 사고를 어떻게 막는지 다룹니다.
입력, 검색, 수정, 거래의 원리
"비개발자가 알아야 할 데이터베이스 이야기" 12부작 중 2편입니다. 1편에서 데이터베이스가 '조직의 기억'이라는 이야기를 했습니다. 이번에는 그 기억이 왜곡되지 않도록 지키는 장치들 — 입력 규칙, 거래 단위, 인덱스, 복제와 백업 — 을 다룹니다.
두 사람이 공연의 마지막 좌석을 거의 동시에 예매했다고 생각해 보자. 두 화면에는 모두 "1석 남음"이라고 표시됐다. 그러나 실제로 판매할 수 있는 좌석은 하나뿐이다. 데이터베이스는 둘 중 한 사람에게만 좌석을 주고, 다른 사람에게는 매진을 알려야 한다.
이 간단해 보이는 일이 데이터베이스의 중요한 역할을 보여 준다. 데이터베이스는 정보를 보관할 뿐 아니라, 동시에 일어나는 변화를 질서 있게 처리해야 한다.
정확성이 흔들리면 무슨 일이 벌어지는가
원리를 보기 전에, 왜 이 원리가 중요한지부터 짚고 가자. 1편에서 "왜 잘 관리해야 하는가"를 물었다면, 이번에는 "정확성이 깨지면 구체적으로 어떤 비용이 발생하는가"다.
- 이중 판매·초과 예약: 재고나 좌석이 하나인데 둘에게 팔리면, 한 명에게는 환불과 사과, 그리고 사라진 재구매 의사가 남는다.
- 잔액 오류: 은행 잔액이 화면마다 다르게 보이면 고객은 즉시 돈을 빼고 떠난다. 금융에서 정확성은 곧 존폐다.
- 처방 오류: 병원 시스템에서 약물 용량이 잘못 기록되면 기술 문제를 넘어 안전 문제가 된다.
- 조용한 오염: 더 무서운 경우도 있다. 아무도 알아차리지 못한 채 데이터가 조금씩 틀어지는 경우다. 잘못된 데이터 위에서 몇 달간 보고서가 만들어지고 의사결정이 쌓이면, 나중에 발견해도 "언제부터 틀렸는지"를 되짚는 비용이 오류 수정 비용보다 크다.
데이터베이스의 정확성 장치들은 이런 사고를 막기 위한 것이다. 하나씩 보자.
입력 규칙: 아무 값이나 받지 않는다
생년월일 칸에 이메일 주소가 들어가거나, 주문에 존재하지 않는 고객 번호가 붙으면 나중에 문제가 생긴다. 데이터베이스는 다음과 같은 규칙을 둘 수 있다.
- 주문 번호는 겹치지 않는다
- 수량은 0보다 커야 한다
- 주문에는 실제로 존재하는 고객이 연결되어야 한다
- 결제일은 정해진 날짜 형식으로 기록한다
- 꼭 필요한 값은 비워 둘 수 없다
이런 규칙을 **데이터 제약 조건(constraint)**이라고 부른다. 쉽게 말해, 잘못된 값이 들어오는 문 앞에서 확인하는 검문소다.
여기에 중요한 원칙 하나가 있다. 오류는 일찍 발견할수록 싸다. 입력 단계에서 걸러진 오류는 1원의 비용이지만, 데이터베이스를 거쳐 보고서와 경영 판단까지 오염시킨 오류는 되돌리는 데 수백만 원이 들 수 있다. 입구에서 막는 규칙이 청소보다 싼 이유다(이 주제는 6편 '데이터 품질'에서 다시 깊이 다룬다).
거래 단위: 전부 처리하거나 전부 취소한다
은행 계좌 A에서 B로 돈을 이체할 때는 최소한 두 가지 변화가 필요하다. A의 잔액에서 돈을 빼고, B의 잔액에 더해야 한다. 첫 번째만 성공하고 두 번째가 실패하면 돈이 증발한다.
데이터베이스는 관련된 작업을 하나의 **거래 단위(transaction, 트랜잭션)**로 묶을 수 있다. 모든 작업이 성공하면 확정(commit)하고, 중간에 문제가 생기면 처음 상태로 되돌린다(rollback). 식당에서 세트 메뉴를 주문했는데 일부만 계산되는 일을 막는 것과 같다.
개발자들은 거래가 지켜야 할 성질을 ACID라는 약어로 설명한다. 비개발자는 약어보다 다음 질문 하나를 기억하면 충분하다.
이 업무는 여러 단계 중 하나만 성공해도 괜찮은가, 아니면 모두 함께 성공하거나 취소되어야 하는가?
결제, 예약, 포인트 이동, 재고 차감처럼 숫자와 권리가 바뀌는 업무에서는 특히 중요하다. 서비스 기획서를 검토할 때 "이 기능에서 중간에 실패하면 어떻게 되나요?"라고 묻는 것만으로도 설계의 허점을 일찍 발견할 수 있다.
인덱스: 책 뒤의 찾아보기와 같다
수백만 명의 고객 가운데 이메일 주소 하나를 찾기 위해 모든 기록을 처음부터 읽는다면 시간이 오래 걸린다. **인덱스(index)**는 책 뒤의 찾아보기처럼 원하는 기록의 위치를 빠르게 찾게 한다.
그러나 인덱스를 많이 만들수록 무조건 좋은 것은 아니다. 찾아보기 항목이 늘면 책을 편집할 때 손이 더 가듯, 데이터가 바뀔 때 인덱스도 함께 고쳐야 한다. 어떤 검색이 자주 필요한지 보고 필요한 만큼 만들어야 한다. "검색은 빠른데 데이터 등록이 느려졌다"는 현상이 나타나면 인덱스 설계를 의심해 볼 수 있다.
복제와 백업은 다르다
많이 혼동하는 두 개념이 있다.
- **복제(replication)**는 같은 데이터를 다른 서버에도 거의 실시간으로 복사해, 한 서버가 멈췄을 때 서비스를 이어 가도록 돕는다.
- **백업(backup)**은 특정 시점의 데이터를 따로 보관해, 실수·손상·공격이 발생했을 때 과거 상태를 복구하도록 돕는다.
둘의 차이를 보여 주는 시나리오가 있다. 직원이 실수로 고객 기록을 지웠는데, 그 삭제가 복제본에도 즉시 반영되었다면? 복제본도 똑같이 지워진 상태다. 복제만으로는 복구할 수 없다. 반대로 백업이 있어도 복구에 몇 시간이 걸리면 그동안 서비스는 멈춘다.
즉, 복제는 '서비스 연속성'을, 백업은 '과거로의 복귀'를 지키는 서로 다른 장치이며 둘 다 필요하다. 그리고 "백업이 있나요?" 다음에는 반드시 "복구 시험을 해봤나요?"가 따라와야 한다. 복구해 보지 않은 백업은 가능성일 뿐이다.
빠른 것과 정확한 것 사이의 선택
모든 서비스가 같은 수준의 즉시 정확성을 요구하지는 않는다. 은행 잔액은 화면마다 다르게 보이면 곤란하다. 반면 게시물의 '좋아요' 수가 몇 초 동안 화면마다 조금 다르게 보이는 것은 받아들일 수 있을지 모른다.
데이터를 여러 지역에 나누어 저장하면 속도와 장애 대응력이 좋아질 수 있지만, 모든 복사본을 늘 같은 순간에 맞추는 일은 더 어려워진다. 그래서 데이터베이스 설계는 "가장 빠르게"가 아니라 **"이 업무가 견딜 수 있는 차이와 지연은 얼마인가"**를 먼저 묻는다.
이 질문은 기술팀만이 답할 수 있는 것이 아니다. "재고 표시가 10초 늦어도 되는가", "예약 확정 화면은 즉시 정확해야 하는가"는 사업의 질문이다. 비즈니스 담당자가 이 대화에 참여해야 하는 이유다.
핵심 정리 데이터베이스의 가치는 저장 용량보다 정확한 변화 처리에 있다. 입력 규칙은 잘못된 값이 들어오는 것을 막고, 거래 단위는 여러 작업을 함께 성공시키거나 취소한다. 인덱스는 검색을 빠르게 하지만 관리 비용이 들며, 복제(서비스 연속성)와 백업(과거 복구)은 서로 다른 문제를 해결한다. 그리고 "얼마나 정확해야 하는가"는 기술이 아니라 사업이 정하는 기준이다.
생각해 볼 질문
- 우리 서비스에서 일부 단계만 성공하면 안 되는 업무는 무엇인가? (결제, 예약, 포인트…)
- 데이터가 몇 초 늦게 맞아도 되는 영역과 즉시 같아야 하는 영역을 구분해 두었는가?
- 마지막으로 백업에서 실제 복구를 시험한 때는 언제인가?
- 데이터가 조용히 오염되고 있다면, 우리는 며칠 만에 알아차릴 수 있는가?
다음 글: 데이터 모양과 사용 목적에 따라 달라지는 데이터베이스의 종류를 살펴본다. 관계형부터 벡터 데이터베이스까지, 왜 종류가 이렇게 많은지 알아본다.
시리즈 목차
- 데이터베이스란 무엇인가 — 엑셀 파일과 무엇이 다를까?
- 데이터베이스는 어떻게 정확성을 지킬까 ← 현재 글
- 데이터베이스에는 어떤 종류가 있을까
- 데이터베이스, 데이터 웨어하우스, 데이터 레이크
- 올바른 데이터베이스 선택이 중요한 이유
- 데이터 모델과 데이터 품질
- 데이터 거버넌스란 무엇인가
- 개인정보는 적게, 필요한 만큼만
- 데이터 보안의 기본
- 데이터 침해는 왜 일어나며, 발생하면 무엇을 해야 할까
- 클라우드와 서버리스 데이터베이스
- AI 시대의 데이터베이스
