레이스 컨디션은 코드 순서가 아니라 실행 순서가 바뀌는 버그입니다

레이스 컨디션은 두 작업이 같은 상태를 보고 서로 다른 결정을 내릴 때 생깁니다.

소스 파일에서는 A 다음에 B가 있습니다.
그래서 사람은 자연스럽게 A가 끝난 뒤 B가 실행된다고 생각합니다.
문제는 실제 서버가 여러 요청을 동시에 받는다는 점입니다.
두 요청이 같은 값을 읽고, 각자 괜찮다고 판단한 뒤, 거의 동시에 저장하면 파일에 적힌 순서는 별 도움이 안 됩니다.

읽기와 쓰기 사이가 벌어질수록 위험합니다

대표적인 예는 재고 차감입니다.
재고가 1개 남았습니다.
요청 1이 재고를 읽고 “구매 가능”이라고 판단합니다.
요청 2도 같은 값을 읽고 똑같이 판단합니다.
둘 다 1을 빼서 저장하면 결과는 음수거나, 한쪽 구매가 사라집니다.
버그는 계산식이 틀려서가 아니라 읽은 시점과 쓴 시점 사이에 세상이 바뀌어서 생깁니다.

락보다 먼저 불변식을 봅니다

해결책을 바로 락으로 시작하면 시스템이 불필요하게 무거워집니다.
먼저 깨지면 안 되는 불변식을 문장으로 써야 합니다.
“재고는 0보다 작아질 수 없다”, “한 사용자는 같은 쿠폰을 한 번만 쓸 수 있다”처럼요.
그다음 DB의 조건부 업데이트, 유니크 제약, 트랜잭션, 큐, 분산 락 중 가장 작은 도구를 고르면 됩니다.

테스트는 동시에 밀어 넣어야 드러납니다

레이스 컨디션은 단일 요청 테스트에서 거의 안 보입니다.
같은 작업을 동시에 10개, 100개 밀어 넣고 마지막 상태를 확인해야 합니다.
성공 응답 개수와 실제 저장 상태가 맞는지도 봐야 합니다.
이 버그는 조용합니다.
그래서 한 번 재현 스크립트를 만들어두면 다음부터는 훨씬 빨리 잡힙니다.

마지막으로 확인할 것은 하나입니다.
이 개념을 외웠는지가 아니라, 실패했을 때 어떤 상태가 남는지 설명할 수 있는지입니다.