◆ ESSAY
저장 단계는 장치, 구간, 거리, 측정값, 발생 시각을 기록한다. 좌표 계산은 이 입력과 별도의 위치 기준정보를 함께 읽는 단계에서 맡는다.
이벤트 입력
→ 원본 값 저장
→ 기준정보와 결합
→ 좌표와 위치 설명 계산
이렇게 두면 기준정보를 고친 뒤 같은 이벤트를 다시 계산할 수 있다. 좌표만 저장하면 그 값이 어떤 기준점과 규칙에서 나왔는지 추적하기 힘들다. 재현성이 중요해지면 계산 시각이나 사용한 기준정보의 버전도 함께 남길 수 있다.
이벤트를 받은 순간 모든 일을 끝내면 저장 성공과 알림 성공이 한 응답에 묶인다. 외부 서비스가 느리거나 중단될 때 입력 요청까지 기다리는 구조를 피하려고 이벤트를 먼저 저장하고 분류 결과가 확인된 뒤 별도 작업을 예약했다.
분류 결과 저장
if 저장된 이벤트가 있다면:
후속 알림 작업 예약
이 경계를 두니 각 응답의 의미가 분명해졌다. 첫 응답은 이벤트 저장을, 분류 요청의 응답은 분류 결과 반영을 뜻한다. 외부 알림의 접수 여부는 별도 기록에서 확인한다.
프로세스 안에서 비동기 작업을 실행하면 요청은 빨리 끝나지만 작업이 시작되기 전에 프로세스가 종료될 때 복구할 방법은 없다. 이 설계는 응답 시간과 단순한 구현을 얻는 대신 작업 유실 가능성을 감수한다. 작업을 반드시 다시 이어야 하는 서비스라면 내구성 있는 큐나 아웃박스가 필요하다.
후속 작업은 외부 요청을 만들기 전에 발송 조건을 살핀다. 분류가 끝났는지, 이미 성공한 시도가 있는지, 알림이 활성화되어 있는지, 받을 대상이 있는지 확인한다. 조건을 만족하지 않으면 외부 호출을 하지 않는다.
성공한 기록은 중복 요청을 줄여 주지만 조회와 외부 호출 사이를 원자적으로 묶어 주지는 않는다. 같은 이벤트를 처리하는 작업이 겹치면 둘 다 성공 기록을 찾지 못하고 요청을 보낼 수 있다.
작업 A: 성공 기록 없음 확인
작업 B: 성공 기록 없음 확인
작업 A: 외부 요청
작업 B: 외부 요청
중복을 막으려면 작업을 예약하는 순간 이벤트별 권한을 확보하거나, 외부 요청에 멱등 키를 붙여야 한다. SUCCESS 기록만으로는 동시 실행을 막을 수 없다.
조건을 만족하지 않아 건너뛴 이유도 남길 필요가 있다. 성공과 실패만 기록하면 알림이 없었던 원인이 비활성 설정인지, 대상 부재인지, 전송 오류인지 구분되지 않는다. 이 선택은 운영자가 어떤 질문에 답해야 하는지부터 정하고 결정할 수 있다.