같은 요청이 두 번 와도,
결과는 한 번만 남깁니다

2026.10.27 기준입니다.

구매요청부터 발주, 입고, 원료 LOT, 작업 로그까지 이어지는 흐름을 테이블로 나눴습니다. 입고 한 건은 원료 LOT 하나를 만들고, 작업 로그는 LOT와 N:M으로 연결됩니다.

색칠한 테이블은 직접 구현한 구매·알림 모듈과 공통 작업 로그입니다.

발주 상태(부분 입고, 입고 완료)는 같은 발주의 모든 품목 입고 합계로 정해집니다. 같은 발주의 다른 품목이 동시에 입고되면 각 거래가 상대 품목을 "아직 안 들어옴"으로 보고 잘못된 상태를 저장할 수 있었고, 같은 품목이면 미입고량을 넘겨 입고될 수 있었습니다. 그래서 잠금 대상을 발주 품목이 아니라 상위 발주 행으로 정하고(TypedSQL SELECT … FOR UPDATE), 확인부터 기록까지 한 트랜잭션으로 묶었습니다.

같은 품목에 60t를 동시에 두 번 입고하면 하나만 성공하고 다른 하나는 PUR-003으로 롤백되며 원료 LOT도 하나만 생기는 것을 테스트로 고정했습니다. 버튼을 두 번 누르는 경우까지 막도록 수주 모듈의 멱등 키 저장소를 공통 모듈로 옮기자고 팀에 제안했습니다.

외부 LLM 호출은 느리고 실패할 수 있어 DB 트랜잭션 밖에서 부르고, 호출 전과 트랜잭션 안에서 같은 조건을 두 번 확인합니다.

구매요청 생성은 승인권자가 없거나 채번이 겹치면 실패할 수 있습니다. 확정을 먼저 커밋하고 실행은 다른 트랜잭션으로 나눠, 실행이 실패해도 확정은 남고 다시 실행할 수 있게 했습니다.

데이터 수치는 2026.09.17 실측입니다.

main에 반영되면 GitHub Actions가 빌드한 이미지를 운영 중이 아닌 쪽 포트에 띄우고, 헬스체크를 통과하면 Nginx 대상을 바꿉니다. 적용 하루 전에 별도 저장소에서 같은 구조를 먼저 검증했습니다.