인증처럼 보이는 범위 불일치

몇몇 업체의 상품 수정이 계속 실패하면서 상품번호를 확인하라는 메시지와 기본정보 조회가 안 된다는 메시지가 나왔다. 상품번호 자체의 문제로 보이는 메시지였다.

Open Table of contents

등록만 성공하는 패턴

이상한 점이 있었는데 같은 업체의 신규 등록은 전부 성공하고 있었다. 등록과 수정과 중지를 나눠 세니 등록만 실패가 0이었다.

인증 문제라면 등록도 실패해야 하고 인증 오류 코드가 와야 하는데 둘 다 아니었다. 인증은 맞는데 특정 작업만 실패한다는 조합이 원인을 다른 축으로 옮겼다.

외부 시스템의 동작을 확인하니 인증 토큰 안의 사이트 식별자를 기준으로 기존 상품을 조회하고 있었다. 우리 쪽 연결을 보니 상품 데이터의 사용자 식별자와 연결된 계정의 사이트 식별자가 서로 달랐다.

그러면 등록은 조회할 대상이 없으므로 그냥 만들어져 성공하고 수정과 중지는 기존 상품을 조회하는데 다른 사이트 것이라 못 찾아 실패한다. 조회 범위 불일치였다.

이것이 왜 인증 오류 코드로 안 나오는지도 분명했다. 인증 자체는 성공했고 토큰이 유효하다.

그 토큰으로 조회할 수 있는 범위에 그 상품이 없을 뿐이므로 외부 입장에서는 그런 상품이 없다는 정상 응답이다. 우리 쪽에서만 이상해 보이는 응답이고 등록만 성공하면서 조회 관련 오류가 나오면 이 패턴을 의심하면 된다.

가설을 확정하려고 같은 데이터인데 올바른 경로로 연결된 건들을 찾아 대조군으로 삼았다. 그쪽은 수정과 중지 실패가 0건이었다.

문의 온 세 건만 고치면 되는지도 확인하려고 같은 조건을 전부 셌더니 25개 업체에 1,300여 건이었다. 문의 온 것만 고치면 나머지가 순차로 돌아온다.

이 건에서 규칙 하나가 나왔는데 등록이 성공한다는 것만으로 연결이 옳다고 판단하면 안 된다는 것이다. 새 연동을 붙이고 등록이 되면 됐다고 생각하지만 수정과 중지는 나중에 필요해지고 그때 실패한다.

그래서 연동 검증에 수정과 중지까지 포함하기로 했다. 이 조사에서 결정적이었던 것은 작업 유형별로 나눠 센 것인데 전체 실패율만 봤으면 가끔 실패한다는 결론이었고 나눠 보니 특정 유형만 90퍼센트 실패한다는 것이 드러났다.