언제 트랜잭션으로 묶을까 —
비즈니스 작업 단위 찾기
마트 계산대에 우유, 빵, 달걀을 올렸습니다. 우유만 결제되고 나머지는 오류가 났다면 — 고객은 계산이 끝났다고 생각할까요? 상품은 세 개지만 고객이 기대한 것은 한 번의 완전한 결제입니다.
이번 섹션의 여정
완료 ✓
지금 여기
직접 실행해보기
잠금 · 종합 실습
첫 번째 질문 — 하나만 남아도 괜찮은가
쇼핑몰 주문으로 돌아가 볼게요.
주문 정보만 저장되고 어떤 상품을 샀는지 빠진다면 이상합니다. 주문은 실패했는데 재고만 줄어도 안 되죠. 세 가지 변경 중 하나라도 빠지면 주문이 완성되지 않습니다.
일부 작업만 성공했을 때 데이터가 이상해진다면 — 함께 묶어야 합니다. 반대로 같은 화면에서 실행됐더라도 서로 없어도 되는 작업이라면, 반드시 한 트랜잭션으로 묶을 필요는 없어요.
“SQL 이 세 줄이니까 묶는다” 가 아니라 — 함께 성공해야 하는 하나의 업무인가로 판단합니다. 한 줄짜리 업무도 있고, 열 줄이 한 업무일 수도 있어요.
트랜잭션에 넣을 작업 고르기
주문을 처리할 때는 입력값 확인부터 완료 알림까지 여러 단계가 있습니다. 하지만 이 모든 단계를 트랜잭션에 넣는 것은 아닙니다.
이름이 비어 있거나 수량에 글자가 들어간 것처럼 바로 알 수 있는 오류는 먼저 확인할 수 있습니다. 반면 가운데 세 작업은 처리하는 동안 다른 주문이 끼어들 수 있어서, 중간 상태가 남지 않도록 함께 처리해야 합니다.
너무 작게 묶으면 — 반쪽 결과가 남습니다
주문 저장 뒤에 한 번, 주문상세 저장 뒤에 또 한 번 커밋했다고 해볼게요. 그리고 마지막 재고 차감에서 오류가 났습니다.
커밋은 잠깐 저장해 두는 버튼이 아니라 — 지금까지의 변경을 최종 반영하는 명령입니다. 하나의 주문을 만드는 중간에 습관적으로 커밋해서는 안 돼요.
너무 크게 묶으면 — 다른 작업이 기다립니다
반대로, 직원이 화면을 보며 고민하는 동안 트랜잭션을 계속 열어 둔다면 어떨까요?
필요한 데이터를 오래 잡고 있으면, 같은 상품을 주문하거나 수정하려는 다른 작업이 기다리게 됩니다.
반쪽 결과앞의 변경만 확정된 채 남는다
되돌리기 불가이미 커밋한 것은 롤백 못 한다
대기 발생다른 작업이 데이터를 못 만진다
사람 시간 포함고민하는 동안 DB 가 붙잡혀 있다
좋은 범위는 —
반쪽 결과를 막을 만큼 충분히 크고, 다른 작업을 오래 기다리게 하지 않을 만큼 짧습니다.
실무 원칙은 간단합니다 — 필요한 데이터 작업 직전에 시작하고, 작업이 끝나면 가능한 한 빨리 커밋합니다. 사용자의 입력을 기다리는 시간은 트랜잭션 안에 두지 마세요.
두 가지 사례로 판단해 보기
| 상황 | 판단 | 이유 |
|---|---|---|
| 회원 가입 + 반드시 필요한 기본 설정 생성 | 함께 묶는다 | 둘 중 하나가 빠지면 가입이 불완전하다 |
| 주문 저장 + 추천 상품 통계 갱신 | 나눌 수 있다 | 통계가 잠시 실패해도 주문은 정상이고 나중에 다시 계산할 수 있다 |
같은 작업이라도 회사의 업무 규칙에 따라 답이 달라질 수 있습니다. 통계가 실시간으로 정확해야 하는 서비스라면 함께 묶을 수도 있어요. 규칙을 확인하고 정하세요.
경계를 정하는 세 단계
한눈에 정리
| 질문 | 판단 |
|---|---|
| 무엇을 기준으로 묶나 | SQL 개수가 아니라 함께 성공해야 할 업무 |
| 이 작업만 남아도 되나 | 이상해진다 → 묶는다 / 괜찮다 → 나눌 수 있다 |
| 무엇을 넣나 | 꼭 필요한 데이터 작업만 (알림·검증은 밖) |
| 너무 작으면 | 반쪽 결과가 확정돼 되돌릴 수 없다 |
| 너무 크면 | 다른 작업이 기다린다 |
함께 성공해야 하는 데이터만 하나로 묶고 — 작업이 끝나면 빠르게 확정합니다.
이제 이 범위를 실제 명령으로 처리해 볼 차례입니다.