확인하려던 요청이 만든 것

동영상 변환본이 제대로 생성됐는지 확인해야 했다. 변환본 주소로 요청을 보내 정상 응답이 오면 있는 것으로 보고 전부 있다고 보고했다.

Open Table of contents

200이 온 확인 요청

며칠 뒤에 일부 영상이 재생되지 않는다는 제보가 왔고 확인했던 것 중에도 있었다. 저장소를 직접 조회하니 그 변환본이 없었다.

없는데 확인할 때는 정상 응답이 왔다는 뜻이다. 그러면 응답을 만든 것이 무엇인지를 봐야 했다.

미디어 서버 코드를 보니 요청한 변환본이 없으면 그 자리에서 만들어 저장한 뒤에 돌려주고 있었다. 미리 다 만들지 않고 요청이 올 때 만드는 지연 생성이었다.

내가 보낸 확인 요청이 변환을 촉발했으므로 정상 응답은 원래 있었다는 증거가 아니라 그 요청이 만들었다는 증거였다. 관측이 대상을 바꾸면 그 관측은 증거가 되지 못한다.

올바른 확인은 저장소에 그 객체가 있는지를 직접 조회하는 것이었다. 그것은 읽기만 하므로 없으면 없다는 결과가 그대로 나온다.

서비스 경로로 존재를 확인하면 그 경로가 어떤 부수효과를 갖는지 모른 채로 판정하게 된다. 확인 대상과 확인 수단을 같은 계층에 두지 않는 것이 이 건의 교훈이었다.

이후로 조회 경로를 쓸 때 이것을 부르면 무슨 일이 일어나는지를 함께 묻게 됐다. 없으면 만드는 것 말고도 호출 수를 올리거나 캐시를 채우거나 접근 기록을 남기거나 비용이 붙는 조회가 있었다.

읽기니까 안전하다는 문장이 항상 참은 아니다. 통계가 오염되거나 다음 사람에게 옛 데이터가 나가는 것도 확인 행위가 만든 결과다.

같은 조사에서 어떤 원본은 규격 조건 때문에 애초에 변환 대상이 아니라는 것도 확인했다. 그러면 변환본이 없다는 관측이 실패와 미완료와 대상 아님 셋 중 하나가 된다.

셋째를 모르면 첫째로 오해하고 계속 재시도하게 된다. 그래서 원본 존재와 변환 대상 여부와 변환본 존재와 작업 이력을 단계로 나눠 어느 단계에서 갈리는지를 원인으로 삼았다.