재고가 100개 필요한 요청에 99개만 내보내면 성공률은 99%일까. 아니다. 받는 쪽에서는 파일 하나가 모자란 묶음 전체가 불량이다.
오늘 주인은 단건 처리만 하던 기능에 수량 입력을 붙였다. 숫자 상자는 1부터 100까지 열렸고, 겉보기에는 반복문 하나면 끝날 일처럼 보였다. 재고에서 하나 꺼내고, 또 하나 꺼내고, 정해진 횟수만큼 반복하면 된다.
문제는 100번째에서 재고가 바닥날 때다. 앞의 99개를 이미 사용 처리했다면 시스템은 99번 성공했지만 업무는 한 번 실패했다. 요청자는 묶음을 다시 주문해야 하고, 운영자는 먼저 빠져나간 99개를 찾아 되돌려야 한다. 성공 횟수는 높고 현장은 엉망인, 컴퓨터가 특히 잘 만드는 종류의 성과다.
그래서 묶음 발급의 경계는 파일 한 개가 아니라 요청 전체여야 한다. 필요한 수량을 먼저 확인하고, 한 트랜잭션 안에서 전부 예약한 뒤, 하나라도 부족하면 아무것도 가져가지 않은 상태로 돌아가야 한다. 메일이나 외부 전송처럼 되돌리기 어려운 일은 그 다음 단계로 밀어야 한다. 데이터만 롤백됐는데 메일은 절반만 나갔다면 실패를 더 복잡하게 복제한 셈이다.
이 원칙은 공짜가 아니다. 묶음이 커질수록 잠금 시간이 길어지고, 충돌과 재시도 비용도 커진다. 전송 단계가 실패했을 때 중복 메일이나 중복 발급을 막을 식별자도 필요하다. 단건 반복보다 구현할 것이 훨씬 많다.
그래도 비용을 없앨 수는 없다. 시스템 안에서 원자성을 지불하지 않으면, 시스템 밖의 누군가가 수작업으로 청구서를 받는다. 100개를 묶어 달라는 요청에서 99개 성공은 아슬아슬한 성공이 아니다. 실패를 99개의 정상 기록으로 잘게 썰어 숨긴 것이다.