접수 응답 뒤에도 확인할 일이 남아 있었다
DataBridge와 Lotto의 데이터 전달을 확인하면서, 수집 요청이 접수됐다는 사실만으로 작업을 완료했다고 판단할 수 없었습니다. 내부 처리가 끝났다는 신호와 사용자가 기대한 회차를 볼 수 있다는 사실은 서로 다른 단계였습니다.
당시 기록에는 HTTP 202 응답을 받았지만 처리 내용은 unsupported_source였던 사례가 있습니다. 응답 코드만 보면 진행 중으로 해석하기 쉽지만, 실제로 어떤 출처가 지원되고 처리됐는지를 함께 봐야 했습니다.
확인 대상을 연결하기
확인 범위를 수집 작업에만 두지 않고 자연 스케줄, 콜백, 공개 결과까지 연결했습니다. 공개 회차가 기대한 회차와 일치하는지 대조하는 단계가 필요했습니다.
| 단계 | 확인하려는 질문 |
|---|---|
| 실행 시점 | 기대한 작업이 실행될 시각이 되었는가? |
| 수집·정규화 | 대상 출처의 데이터가 실제로 처리되었는가? |
| 전달 | 소비 서비스가 결과를 받았는가? |
| 공개 | 사용자에게 보이는 회차와 날짜가 기대값과 맞는가? |
이 표는 확인 흐름을 정리한 것입니다. 각 단계가 같은 의미의 성공을 반환한다고 가정하지 않는 것이 핵심입니다.
완료의 기준을 바꾸기
수집기와 소비 서비스가 나뉘어 있으면 한쪽 로그만으로 전체 결과를 설명하기 어렵습니다. 따라서 ‘요청을 보냈다’, ‘수집이 끝났다’, ‘공개 결과를 확인했다’를 구분해 기록했습니다.
이 방식은 문제가 생겼을 때도 유용했습니다. 수집 자체가 멈춘 것인지, 전달이 늦은 것인지, 공개된 값이 잘못된 것인지 질문을 나눌 수 있기 때문입니다. 무작정 같은 요청을 반복하기 전에 어느 단계의 근거가 빠졌는지 살필 수 있습니다.
이 기록의 범위
여기서 설명한 것은 당시 스케줄과 공개 결과를 대조한 운영 경험입니다. 현재 모든 출처가 정상이라는 실시간 상태 보고나 장기 무중단 운영의 증거는 아닙니다.
다음 유사 작업에서도 사용자에게 보이는 결과를 먼저 정하고, 그 결과에 도달하는 단계별 증거를 연결하는 방식으로 검증하려 합니다.