검증과 매핑이 다른 필드를 본다

인터페이스로 데이터를 등록해야 하는데 형식을 몰라서 기존 것을 조회해 템플릿으로 쓰려고 했다. 값만 바꿔 보냈더니 필수 필드가 없다는 오류가 돌아왔다.

Open Table of contents

조회 응답과 등록 요청의 형식 차이

두 형식을 나란히 놓고 보니 같은 것을 다른 이름으로 부르고 있었다. 소속은 응답에는 인코딩된 값으로 있고 등록에서는 인증 정보에서 가져오며 브랜드와 분류도 이름이 각각 달랐다.

옵션은 이름이 아니라 구조 자체가 달랐다. 조회 결과를 그대로 등록 입력으로 쓸 수 있다는 전제가 성립하지 않았다.

더 이상한 것은 검증 클래스와 실제 처리 코드가 서로 다른 필드를 본다는 점이었다. 검증은 한쪽 이름을 필수로 요구하고 처리는 다른 쪽 이름을 읽고 있었다.

그러면 양쪽 이름을 다 보내야 검증을 통과하면서 동작한다. 하나만 보내면 검증에서 막히거나 값이 빈 채로 처리되고 뒤쪽은 오류도 안 난다.

이력을 보니 원래 관리자 화면용 검증 클래스가 있었고 나중에 외부 인터페이스가 생기면서 처리 코드만 새로 쓴 것으로 보였다. 두 화면이 다른 필드명을 쓰는데 검증만 공유한 셈이다.

검증 클래스 안에 관리자 화면의 중첩 구조를 참조하는 코드도 남아 있었다. 외부 요청에는 그런 구조가 없으므로 그 부분은 항상 빈 값으로 검증을 통과한다.

코드를 읽어 정답을 조립하려니 검증과 처리가 다르고 옵션 구조는 문서에도 없어서 확신이 서지 않았다. 각 계층이 요구하는 것을 합집합으로 만들면 불필요한 필드까지 보내게 된다.

이 시스템에는 실제로 들어온 요청을 본문까지 기록하는 테이블이 있었다. 성공한 클라이언트의 요청 본문 하나가 여러 계층에서 추론한 것보다 확실한 답이다.

여기까지 알아내고 정리했지만 그 테이블을 실제로 조회하지는 않았다. 작업 범위가 다른 곳에 있었고 이 부분은 다음으로 미뤘다.

그래서 형식을 어디서 확인할 수 있는지를 적으면서 이번에 조회하지 않았으므로 미검증이라고 함께 적었다. 나중에 이 메모를 보는 사람이 확인된 것으로 오해하면 같은 자리에서 다시 막히기 때문이다.