결과를 만든 확인 행위

이미지 변환본이 저장소에 있는지 확인하려고 주소를 호출해 200을 받고 있다고 기록했다. 그런데 그 서비스의 코드를 읽어 보니 요청한 변환본이 없으면 원본에서 즉석 생성해 저장한 뒤 응답하는 구조였다.

Open Table of contents

사후에 구분되지 않는 두 경우

200이 왔다는 것은 그 파일이 이미 있었다는 뜻이 아니라 내 요청이 그것을 만들었을 수도 있다는 뜻이었다.

원래 있어서 200이 온 경우와 없었는데 내가 만들어서 200이 온 경우가 응답만으로는 같아 보인다. 확인하려던 사실을 확인하는 행위가 지워 버린 것이다. 존재 여부를 알려면 저장소를 직접 조회해야 했고 그 경로는 없는 것을 만들지 않는다.

어떤 키의 실제 호출 한도를 알아보려고 직접 호출해서 잰 적이 있다. 그 키는 운영 트래픽과 공유하는 한정 자원이었고 호출 하나하나가 그날의 한도를 실제로 깎았다. 읽기 조사로 분류했지만 상태 변경이었다.

연결된 기기의 폴더를 목록으로 훑었을 때는 데이터 요금이 발생했다. 그 항목들은 로컬에 실체가 없고 열어 볼 때 기기에서 끌어오는 구조라 목록을 본 것만으로 통신이 일어났다.

세 경우의 공통점은 조회하는 쪽에서 그것을 알 방법이 없었다는 점이다. 인터페이스는 전부 읽기처럼 생겼고 부작용은 그 뒤에 있었다.

반대 방향도 봤다. 부재를 감시하는 시스템이 있었는데 특정 신호가 안 오면 경보를 내는 방식이었다. 그 감시 대상 목록에 새 항목을 넣었더니 최초 1회 시딩 이후로 아무 신호가 없어도 30분 뒤 부재로 판정해 주기적으로 경보를 냈다.

아직 안 왔으니 조용할 것이라고 생각했는데 실제로는 안 왔으니 계속 울리는 구조였다. 목록을 넓히는 행위 자체가 오탐 폭주를 만든 것이다.

또 다른 감시는 정상 경로에서 아무 출력을 하지 않았다. 잘 돌 때와 아무것도 안 할 때의 출력이 같으므로 오류 로그가 0건이라는 사실로는 둘을 가를 수 없다.

이 조회가 대상을 바꾸는지 먼저 묻는다. 없으면 만드는지와 한도를 쓰는지와 캐시를 채우는지와 요금이 붙는지를 본다.

바꾼다면 바꾸지 않는 다른 경로가 있는지 찾는다. 존재 확인은 만들지 않는 조회로 하고 한도 확인은 문서나 대시보드에서 본다. 바꿔야만 확인할 수 있다면 그 사실을 기록에 남긴다. 200을 받았다고 적는 대신 200을 받았고 이 경로에는 생성 부작용이 있다고 적는다.

빈 출력이 무엇을 뜻하는지도 먼저 정한다. 정상일 때도 비어 있으면 그 검사는 아무것도 가르지 못한다.

이 건은 코드를 읽다가 알았고 확인 결과를 이미 보고한 뒤였다. 확인 방법이 대상에 어떻게 닿는지를 확인하기 전에 봐야 한다는 것이 여기서 남았다. 응답 코드는 결과만 알려 주고 그 경로가 도중에 무엇을 했는지는 알려 주지 않는다.