인증을 시행착오로 시험하지 않는다

새 마켓 연동을 붙이면서 인증 규격을 조사하다가 문답에서 같은 피해 문의가 여덟 건 넘게 반복되는 것을 봤다. 토큰 발급 요청이 규격을 어기면 그 호출만 실패하는 것이 아니었다.

Open Table of contents

계정 전체의 강등

규격 미준수가 확인되면 API 전체 호출 허용량이 시간당 열 번으로 자동 강등된다. 공식 답변에는 연동을 수정한 뒤 호출하면 빠르면 다음 날 늦어도 2주 안에 정상 수준으로 회복된다고 적혀 있었다.

여기서 가장 나쁜 지점은 즉시 해제가 아니라는 것이다. 시간당 열 번이면 사실상 마비인데 상품 하나 등록에도 여러 번 부르므로 고치고 나서도 며칠을 기다려야 하고 그동안 내가 할 수 있는 것이 없다.

이 API에는 별도 테스트 환경이 없었다. 모든 시도가 운영에서 일어난다는 뜻이다.

보통 하듯이 일단 보내 보고 오류를 보며 맞추는 방식을 쓰면 몇 번 만에 계정이 강등된다. 페널티가 있다는 것과 테스트 환경이 없다는 것이 겹치면 시행착오 방식 자체를 쓸 수 없다.

다행히 규격은 다른 답변에 명시돼 있었다. 파라미터를 평문으로 보낼 것과 유형이 자기 자신이면 계정 식별자를 넣지 말 것과 필수 필드를 빠뜨리지 말 것과 본문을 폼 인코딩으로 보낼 것이었다.

마지막이 흔한 실수인데 요즘 API는 대부분 JSON을 받으므로 그렇게 보내기 쉽다. 그래서 순서를 규격과 문답을 전부 읽고 요청을 만든 뒤 보내기 전에 인코딩 형식과 필수 필드와 유형별 포함 여부를 항목으로 대조하고 그러고 나서 한 번 보내는 것으로 잡았다.

같이 정리된 제약이 셋 더 있었다. 180일마다 관리자 이메일로 재인증해야 하고 안 하면 휴면이 된다.

휴면이면 토큰 발급 자체가 안 돼서 연동이 통째로 멈추는데 그것도 아무 오류 없이 어느 날 갑자기다. 관리 계정을 바꾸면 기존 애플리케이션이 무효화돼 재발급이 필요하므로 담당자 교체가 연동을 죽일 수 있다. 셋 다 운영상 시한폭탄이라 달력에 넣어야 한다.

이 조사에서 규칙 하나가 나왔다. 외부 API를 붙일 때 잘못된 요청에 페널티가 있는지와 테스트 환경이 있는지와 시간 제약이 있는지를 먼저 확인한다.

앞의 둘이 겹치면 특히 위험하고 이번이 그 경우였다. 문서만 읽고 문답을 안 읽는 경우가 많은데 문서에는 이러면 계정이 죽는다는 말이 없으므로 함정은 문서가 아니라 문답에 있고 여덟 건의 문의는 전부 실제로 강등을 겪은 사람들의 것이었다.