규격이 허용하는 문자로 값을 채웠다

상품을 외부에 등록하는 과정에서 일부가 거부당했는데 오류 메시지는 잘못된 파라미터라는 말뿐이었다. 어느 항목이 문제인지는 응답 어디에도 나오지 않아서 우리가 직접 좁혀야 했다.

Open Table of contents

비교가 좁힌 범위

그래서 통과한 것과 거부된 것을 나란히 놓고 어디가 다른지부터 비교했더니 괄호와 슬래시가 들어간 상품명만 골라 거부되고 있었다.

규격 문서를 다시 읽으니 허용 문자 목록이 명시돼 있었고 괄호와 슬래시가 거기 없었다. 문서에 있었는데 길이만 확인하고 허용 문자는 안 읽고 있었다.

허용되지 않는 문자를 공백으로 바꾸고 연속 공백을 정리하는 함수를 먼저 만들었다. 대부분의 상품명은 그 처리만으로 원래 뜻이 그대로 유지됐다.

그런데 슬래시 자체가 뜻을 담고 있는 경우가 섞여 있었는데 규격 이름에 들어간 슬래시를 공백으로 바꾸니 아예 다른 이름이 됐다. 뜻이 있는 문자는 없애지 않고 허용되는 다른 문자로 먼저 바꾸는 단계를 앞에 뒀다.

길이 상한을 넘으면 자르게 했는데 단어 중간에서 잘려 이상해지는 경우가 나왔다. 상한 안쪽의 마지막 공백 위치를 찾아 거기서 자르되 너무 짧아지면 그냥 자르게 했다.

바꾼 것은 바꾸기 전과 후를 함께 로그에 남기게 했다. 그러면 무엇이 어떻게 바뀌었는지가 보이고 며칠치를 훑으니 대부분 괄호였는데 규격 담당자에게 물으니 곧 허용될 예정이라고 했다.

그래서 거부당하기 전에 우리 쪽에서 먼저 알 수 있는 형태로 바꿨다. 길이 하한과 상한과 허용 문자 패턴을 보내기 전에 확인하고 안 맞으면 그 자리에서 예외를 던진다.

그렇게 하고 나니 거부율이 8퍼센트에서 0퍼센트로 떨어졌다. 규격 자체도 코드로 옮겨 상수로 두고 어느 규격서 몇 절에서 온 것인지를 주석에 적어 규격이 바뀌면 그 자리만 고치게 했다.

상품명만 고치고 나서 이번에는 다른 항목 때문에 또 거부당했다. 설명과 가격과 재고와 이미지에 각각 다른 제약이 걸려 있었기 때문이다.

한 항목씩 걸리면 그때마다 왕복이 생기므로 전 항목을 한 번에 검증해 오류를 모아서 돌려주게 바꿨다. 하나씩 걸리는 대신 문제가 전부 한 번에 나오므로 한 번에 고칠 수 있었다.