저장 구조사고를 계기로 저장 구조 자체를 다시 설계하다
구분
CASE 03 · 아키텍처
아키텍처 · 오프라인 큐
상태
완료 · 운영 중
2026
역할
설계 · 판정 · 운영
코드는 AI
분야
엔지니어링
멱등 키 · 유니크 제약 · 로컬 정본
CASE-03엔지니어링
4건
중복 생성된 레코드
개요
저장 구조
운영 환경에서 일정이 중복 생성되는 사고가 발생했습니다(레코드 4건).
01
원인
로그인 세션 만료를 앱이 "오프라인 상태"로 잘못 분류하고 있었습니다. 그 상태에서 만든 일정이 오프라인 큐에 쌓였고 재로그인 시 큐가 일괄 재전송되며 같은 일정이 다시 생성됐습니다.
02
결정
큐 로직만 고치지 않고 비로그인 사용자의 저장 모델 자체를 바꿨습니다. 비로그인 상태에서는 로컬 저장소를 정본으로 삼아 서버 통신을 아예 하지 않고 로그인 순간에만 1회 병합합니다.
인증 오류와 오프라인을 분리. 만료 시 "다시 로그인" 안내
생성 요청에 멱등 키 동봉 + DB 유니크 제약으로 중복을 구조적으로 차단
기존 큐를 재활용하지 않음. 재전송 대기열을 저장소로 남용한 것이 사고 원인이었기 때문
기록
잰 숫자와 출처
측정 · 사고 기록
4건중복 생성된 레코드
측정 · 설계
0회게스트 구간 서버 통신
측정 · 설계
1회로그인 순간 병합
결과
가입 없이 핵심 기능 사용 가능 · 게스트 구간 서버 통신 0회 · 중복 생성 원천 차단
배운 것
표면 원인은 큐였지만 진짜 원인은 "임시 저장"과 "재전송 대기열"을 같은 저장소로 쓴 설계였습니다. 증상을 막는 수정과 원인을 없애는 수정은 다르다는 걸 이 건에서 배웠습니다.
