AI 요약
데이터베이스 시스템에서 레이스 컨디션은 리팩토링 시 운영 환경을 위협하는 주요 요인이며, 특히 금융 서비스에서 치명적입니다. 본 기사는 $100의 잔액을 가진 계좌에 두 개의 $50 입금(Credit) 요청이 동시에 들어올 때, 두 프로세스가 모두 잔액을 $100로 조회(SELECT)하고 각각 $150로 업데이트(UPDATE)하여 결국 $50가 사라지는 구체적인 사례를 통해 문제의 심각성을 설명합니다. 일반적인 테스트 코드에서는 이러한 동시성 이슈를 발견하기 어렵고, sleep()을 활용한 지연 방식은 테스트가 느려지고 불확실하다는 단점이 있습니다. 필자는 이를 해결하기 위해 '동기화 배리어(Synchronization Barrier)' 기법을 제안합니다. 이는 createBarrier 함수를 통해 정해진 수의 작업이 모두 도착할 때까지 실행을 일시 중단시켰다가 한꺼번에 해제하는 방식으로, 확률에 의존하지 않고 100% 확률로 레이스 컨디션을 재현하고 검증할 수 있게 해줍니다.
핵심 인사이트
- 데이터 증발 시나리오: $100 잔액에 $50씩 두 번 입금될 때, 동시성 문제로 인해 결과값이 예상치인 $200가 아닌 $150로 기록되며 에러 로그나 롤백조차 발생하지 않는 'Write Race Condition'의 위험성을 경고합니다.
- 기존 테스트의 한계:
Promise.all이나 단순 반복 테스트는 실행 타이밍이 우연히 맞아야만 버그를 발견할 수 있어 '테스트'가 아닌 '주사위 굴리기'와 같은 불확실성을 가집니다. - 동기화 배리어 솔루션:
createBarrier(count)함수를 구현하여, 모든 작업이 쓰기(Write) 단계로 넘어가기 전 동일한 상태 값을 읽도록 강제함으로써 결정론적인(Deterministic) 테스트 환경을 구축합니다.
주요 디테일
- Race Condition의 메커니즘: 두 개의 작업 P1과 P2가 동시에
SELECT balance를 수행하여 둘 다 100을 읽고, 각각 150을 계산한 뒤UPDATE를 수행하면 나중에 실행된 쓰기 작업이 이전 작업을 덮어쓰게 됩니다. - createBarrier 구현 원리: 내부적으로 카운터(
arrived)와 대기자 목록(waiters)을 관리하며, 설정된count에 도달할 때까지Promise를 통해 실행을 중단시킵니다. - 테스트의 신뢰성: 배리어를 사용하면 비결정론적인 동시성 버그를 100% 재현 가능한 형태로 변환하여, 코드가 동시성을 올바르게 처리하는지 명확한 '증명'이 가능해집니다.
- 비즈니스 영향: 돈을 다루는 시스템에서 이러한 레이스 컨디션은 고객 잔액 오류를 유발하며, 원인을 파악할 수 있는 로그조차 남지 않아 추적이 매우 어렵습니다.
향후 전망
- 복잡한 분산 시스템과 고성능 백엔드 개발에서 동기화 배리어를 활용한 결정론적 동시성 테스트가 정합성 검증의 필수적인 관행으로 자리 잡을 것으로 예상됩니다.
- 데이터베이스 격리 수준(Isolation Level) 설정만으로 해결되지 않는 복잡한 비즈니스 로직의 검증 도구로서 배리어 패턴의 활용도가 높아질 것입니다.
출처:hackernews