한 채널에서 옵션 관련 오류가 대량으로 나고 있었고 사례 하나를 보고 옛 옵션 코드 컬럼이 비어 있어서 나는 것이라는 가설을 세웠다. 그 사례에서는 실제로 해당 컬럼이 비어 있었으므로 그럴듯한 설명으로 보였다.
Table of contents
Open Table of contents
결정적 표본으로 한 확인
가설을 검증하려고 오류가 가장 많은 입점사를 골라 그 업체의 표본 상품을 같은 방법으로 확인했다. 그 컬럼에 값이 들어 있었고 코드도 정상으로 생성돼 있었는데 같은 오류가 그대로 재현됐다.
이미 그 컬럼의 복구가 끝난 구간도 확인했더니 3천 건이 넘는 오류가 여전히 잔존하고 있었다. 값이 있는데도 나고 복구했는데도 남는다는 두 관측이 같은 방향을 가리켰으므로 그 값이 비어서 나는 오류가 아니었다.
명시적으로 폐기한 가설
가장 중요한 결정이 여기서 나왔다. 이 오류를 그 값을 채우면 해결되는 것으로 다루지 않기로 명시했다.
이것을 안 적으면 다음 사람이 또 복구 작업을 돌리고 그러고도 안 낫는 일이 반복된다. 틀린 가설은 조용히 버리는 것이 아니라 폐기했다고 적어야 다음에 되살아나지 않는다.
유력해진 새 가설
관측을 다시 놓고 새 가설을 세웠다. 복구 작업 전후로 코드를 만드는 기준이 달라졌으므로 등록된 코드와 지금 보내는 코드가 다를 수 있다는 것이었다.
등록된 것과 보내는 것이 다르면 마켓이 거부하는 것이 자연스럽다. 오류가 조회가 아니라 수정 시점에 발생한다는 관측도 이 가설과 맞아떨어졌는데 수정할 때 코드를 보내기 때문이다.
막힌 검증 경로
확인하려면 마켓에 실제로 무엇이 등록됐는지를 봐야 했고 조회 API를 불러 봤다. 응답에 필요한 목록 자체가 들어 있지 않아서 등록된 코드를 조회할 방법이 없었다.
여기서 억지로 결론을 내지 않고 세 줄로 적었다. 유력하지만 아직 검증되지 않은 가설이 무엇이고 확인하려면 등록된 값과 대조해야 하며 현재 조회 경로가 실패하므로 대체 조회 수단 확보가 선행 과제라는 것이다.
못 푼 결과의 값어치
이렇게 적으면 다음 사람의 일이 명확해진다. 대체 조회 수단을 찾고 등록된 코드와 우리가 보내는 코드를 대조하면 되므로 원인 불명이 아니라 이것을 확인하면 된다는 형태가 된다.
이 조사의 결과가 못 풀었다는 것인데도 값어치가 있었다. 틀린 가설을 폐기하지 않았으면 3천여 건이 그대로인 채 복구 작업만 계속 돌았을 것이다. 가설을 세웠으면 유리한 표본이 아니라 결정적인 표본을 골라 반례를 적극적으로 찾아야 하고 이건 아니라고 확정하는 것도 진전이다.
정리
- 가설을 세웠으면 반례를 적극적으로 찾는다
- 유리한 표본이 아니라 결정적인 표본을 고른다
- 반증되면 틀린 가설을 명시적으로 폐기한다
- 안 적으면 같은 작업이 반복된다
- 새 가설의 검증 경로가 막힐 수 있다
- 그때는 가설과 검증 방법과 막힌 이유를 적는다
- 원인 불명이 아니라 이것을 확인하면 된다로 남긴다
- 이건 아니라고 확정하는 것도 진전이다