검증 순서를 읽어 화면에 반영했다

외부 채널 API에 상품을 등록하는 부분을 맡았다. Guzzle로 호출하는데 실패하면 오류 코드만 오고 어느 필드가 문제인지는 오지 않았다.

Open Table of contents

상황 — 상세 없는 오류 응답

응답에 INVALID_PARAMETER만 있고 필드명이 없었다. 담당자가 하나씩 바꿔 가며 시도하고 있었다.

한 번 등록하는 데 몇 분이 걸려서 시행착오 한 번에 드는 비용이 상당히 컸다.

규격 문서를 처음부터 읽어 보니 검증 순서가 적혀 있었다. MISSING_PARAMETER → INVALID_FORMAT → INVALID_PARAMETER → INVALID_COMBINATION 순이었다.

즉 INVALID_PARAMETER가 왔다는 것은 앞 단계는 통과했다는 뜻이었고, 어느 단계까지 갔는지가 오류 코드마다 갈렸다.

지원 값이 하나뿐인 필드도 있었다. 사실상 고정값인데 Laravel 화면에서는 자유 입력이었다.

방법이 셋이었다. 화면 입력 순서를 검증 순서에 맞추거나, 우리 쪽에서 같은 검증을 먼저 돌리거나, 오류 코드를 필드로 매핑하는 표를 만드는 것이다.

입력 순서를 맞추는 쪽은 구현이 가벼운 대신, 규격이 바뀌면 화면 순서도 따라 바꿔야 한다.

자체 검증은 시행착오가 없어지는 대신 로직이 이중이 되고 둘이 갈라질 위험이 있다.

매핑 표를 두면 오류가 왔을 때 안내가 정확해지는 대신, 오류 코드가 늘 때마다 그 표를 갱신해야 한다.

입력 순서를 맞추고 고정값 필드만 우리가 막는 쪽을 골랐다. 지원 값이 하나뿐인 필드는 규격이 바뀔 일이 거의 없어 이중 검증의 위험이 작았다.

나머지 검증은 API에 맡기고 Blade 화면에서 앞 단계 필드부터 채우게 하니, 어디서 걸렸는지가 순서로 드러났다.

전체 검증을 우리 쪽에 복제하는 것은 하지 않았다. 규격이 분기마다 바뀌는데 그때마다 양쪽을 맞추는 비용이 시행착오 비용보다 컸다.

규격의 검증 순서를 우리 문서로 옮겨 적었다. 규격이 200쪽이라 다시 찾는 데만 시간이 걸린다.

고정값으로 막은 필드가 어느 것인지도 함께 적었는데, 규격이 바뀌어 값이 늘면 그 자리부터 풀어야 하기 때문이다.