APP DEVELOPMENT TERM
트랜잭션
함께 확정하거나 취소할 데이터 변경의 단위
트랜잭션은 데이터베이스에서 관련 변경을 하나의 작업으로 묶어, 모두 성공하면 함께 확정하고 완료할 수 없으면 그 작업의 변경을 취소하는 처리 단위입니다.
30초 이해
하나의 업무를 끝내려면 여러 값이 함께 바뀌어야 할 때가 있습니다
창고 A에서 B로 물품 10개를 옮겼다는 기록을 저장한다고 생각해보세요. A의 수량을 줄이고, B의 수량을 늘리고, 어디에서 어디로 몇 개를 옮겼는지 기록해야 합니다. A의 수량만 줄어든 채 끝나면 두 창고의 재고와 이동 내역이 맞지 않습니다.
이렇게 함께 처리돼야 하는 변경을 하나의 트랜잭션으로 묶습니다. 필요한 변경을 모두 마치면 함께 확정하고, 끝까지 처리할 수 없으면 이번 작업에서 바꾼 내용을 취소합니다. 앞부분만 저장된 상태를 완료 결과로 남기지 않는 것입니다.
변경을 확정하는 것을 커밋(Commit), 확정하기 전 변경을 취소하는 것을 롤백(Rollback)이라고 합니다. 여기서는 같은 데이터베이스 안에서 재고 수량과 이동 기록을 함께 저장하는 경우를 살펴봅니다.
TRANSACTION
묶어서 시작하고, 결과를 함께 결정합니다
같은 데이터베이스 안의 재고 이동을 설명하는 가상 예시입니다. 확정과 취소는 서로 다른 결과입니다.
- 01
작업 시작
A의 수량, B의 수량, 이번 이동 기록을 하나의 작업으로 묶습니다.
- 02
변경 처리
A에서 10개를 빼고 B에 10개를 더하며 이동 기록을 작성합니다. 아직 확정 전입니다.
- 03
확정 또는 취소
모두 성공하면 함께 확정합니다. 완료할 수 없으면 이번 작업의 변경을 취소합니다.
- 04
결과 확인
확정된 수량과 이동 기록을 확인해 전체 반영 또는 이번 변경 취소로 구분합니다.
함께 맞아야 하는 데이터를 정하고, 그 변경을 하나의 완료 결과로 다룹니다.
언제 사용하는 개념인가요?
재고 수량과 이동 내역을 바꿀 때
출발지·도착지 수량과 이동 기록이 함께 맞아야 할 때 사용합니다. 수량만 바뀌거나 기록만 생기면 재고를 대조하기 어렵습니다.
포인트 잔액과 사용 내역을 바꿀 때
같은 데이터베이스에서 잔액 차감과 사용 기록을 함께 저장할 때 사용합니다. 사용 내역 없이 잔액만 줄어드는 결과를 막아야 합니다.
신청 상태와 처리 이력을 남길 때
신청의 상태 변경과 담당자의 처리 이력이 함께 남아야 할 때 사용합니다. 어떤 변경까지 하나의 업무 결과로 볼지 먼저 정합니다.
왜 중요한가요?
서로 맞아야 할 기록이 따로 남는 일을 막습니다
한쪽 변경만 저장되면 화면마다 다른 결과를 보여주거나 관리자가 수량을 다시 맞춰야 할 수 있습니다. 관련 변경을 묶으면 일부만 반영된 상태가 이번 작업의 최종 결과로 남지 않게 할 수 있습니다.
완료의 기준을 분명하게 만듭니다
첫 번째 값이 바뀐 것만으로 업무를 완료했다고 할 수는 없습니다. 함께 저장할 범위를 정해 두면 그 전체가 확정됐을 때 완료로 안내할 수 있습니다.
실패했을 때 무엇을 확인할지 정할 수 있습니다
검수에서는 정상 저장뿐 아니라 중간에 처리를 끝내지 못한 경우도 확인합니다. 수량과 관련 기록을 함께 조회해야 이번 작업의 변경이 일부 남지 않았는지 알 수 있습니다.
실제 상황 예시
창고 A에서 B로 10개를 옮긴 기록을 저장한다면
가상 예시입니다. 시작할 때 같은 데이터베이스의 창고 A 수량은 100개, B 수량은 30개이며 이번 이동 기록은 없습니다. 두 수량의 변경과 이번 이동 기록을 한 트랜잭션에 넣습니다. 아래 두 결과는 모두 이 시작 상태에서 각각 출발하며, 다른 사람이 동시에 재고를 바꾸는 상황은 제외합니다.
성공 — 모두 함께 확정
- 창고 A: 100개에서 90개로 변경됩니다.
- 창고 B: 30개에서 40개로 변경됩니다.
- 이번 이동 기록: A에서 B로 10개 이동한 내역이 남습니다.
- 커밋이 완료되면 두 수량과 이동 기록이 함께 확정됩니다.
실패 — 이번 변경 취소
- 이동 기록을 저장하지 못해 작업을 끝낼 수 없다면 이번 트랜잭션을 롤백합니다.
- 창고 A는 100개, 창고 B는 30개로 남습니다.
- 이번 이동 기록은 새로 남지 않습니다.
- 이번 작업에서 바꾼 내용을 취소하며, 이전에 확정된 다른 이동 기록은 그대로 둡니다.
수량과 이동 기록을 저장하는 예시입니다. 데이터 변경을 취소한다고 실제로 옮긴 물품까지 원래 창고로 돌아가는 것은 아닙니다. 현장의 물품 이동 상태는 따로 확인해야 합니다.
자주 하는 오해
“같은 데이터베이스를 쓰면 여러 저장이 자동으로 묶입니다”
각 변경을 따로 확정하도록 만들 수도 있습니다. 함께 성공하거나 취소해야 하는 범위를 정하고, 실제 처리도 같은 트랜잭션 안에서 수행하도록 구성해야 합니다. 저장 버튼 하나가 트랜잭션 하나라는 뜻도 아닙니다.
“트랜잭션이 있으면 같은 요청을 두 번 보내도 한 번만 반영됩니다”
각 요청이 별개의 트랜잭션으로 성공하면 같은 업무가 두 번 반영될 수 있습니다. 같은 요청인지 구분하고 이미 처리한 결과를 확인하는 중복 방지 기준은 따로 필요합니다.
“여러 사람이 동시에 처리해도 조건이 항상 맞습니다”
각 작업이 어떤 데이터를 읽고 다른 작업과 어떻게 기다리거나 충돌을 처리하는지는 설정과 구현에 따라 달라집니다. 재고 부족이나 정원 초과를 막으려면 동시 처리 때의 조건 검사·잠금·제약도 확인해야 합니다.
“실패하면 외부 결제나 발송한 알림도 함께 취소됩니다”
외부 결제나 알림 전송은 여기서 묶은 데이터베이스 변경과 처리 범위가 다릅니다. 결제가 완료됐는지, 취소가 필요한지, 알림이 이미 전달됐는지는 해당 서비스의 결과를 별도로 확인하고 처리해야 합니다.
“커밋한 작업도 롤백으로 언제든 되돌릴 수 있습니다”
이 글의 롤백은 아직 확정하지 않은 이번 트랜잭션의 변경을 취소하는 것입니다. 이미 확정한 이동을 취소하려면 현재 재고와 업무 조건을 확인해 되돌리는 작업을 별도로 처리하고 그 이력을 남겨야 합니다.
우리 서비스에 적용할 때 확인하세요
- 1어떤 값과 기록이 함께 확정돼야 하나요? 일부만 남으면 어떤 업무 문제가 생기나요?
- 2같은 데이터베이스의 어느 변경까지 한 트랜잭션에 넣고, 외부 결제·알림은 어떻게 구분하나요?
- 3중간에 실패했을 때 이번 변경이 모두 취소됐는지 어떤 수량과 기록으로 확인하나요?
- 4동시에 처리하거나 같은 요청이 다시 들어오면 어떤 조건으로 허용·거부·재확인하나요?
- 5화면에서 응답을 받지 못했을 때 이미 확정됐는지 어디서 확인하나요? 성공·실패를 확인하기 전에 다시 실행하지 않도록 어떻게 안내하나요?
공식 참고
서비스 기준은 공식 문서에서 다시 확인하세요
다음 자료
이해한 내용을 바로 적용해보세요
트랜잭션은 변경을 함께 처리하는 단위입니다. 데이터를 보관하는 구조, 여러 사본의 변경을 맞추는 일, 데이터베이스 선택 기준은 아래 용어에서 이어 볼 수 있습니다.
우리 서비스에서 함께 바뀌어야 할 값을 찾아보세요
하나의 업무를 골라 바꿀 값과 남길 기록을 적고, 성공했을 때와 중간에 실패했을 때 각각 어떤 결과가 남아야 하는지 정리해보세요.