은행 입금 내역 조회 연동에 오류 처리를 넣었는데 상태 코드만 보게 했더니 아무것도 안 잡혔다. 그런데 데이터도 들어오지 않았다.
Table of contents
Open Table of contents
증상 — 오류가 본문에 담겨 온다
응답을 찍어 보니 HTTP 200 이고 본문의 resultCode 에 오류 코드와 메시지가 들어 있었다. 정상은 0000 이고 나머지는 전부 오류였다. 오래된 인터페이스일수록 이런 형태가 드물지 않다.
상태 코드를 전송 계층 결과로만 쓰고 응용 계층 결과는 본문에 담는 설계다. RFC 7231 이 정하는 상태 코드는 요청을 이해하고 처리하려는 시도의 결과이지 그 안의 업무가 됐다는 뜻이 아니다. 그러면 상태 코드만 보는 검사는 구조적으로 아무것도 못 잡는다.
조치 — 전송 계층과 응용 계층
검사를 두 층으로 나눴다. 상태 코드가 정상이 아니면 TransportException 을 던지고 resultCode 가 0000 이 아니면 BankResultException 을 던진다. 두 오류를 다른 예외로 만든 것은 대응이 다르기 때문이다.
전송 오류는 RetryTemplate 로 재시도할 만하지만 응용 오류는 대개 재시도해도 같은 결과가 온다. 한 종류로 뭉뚱그리면 재시도 정책을 갈라 붙일 수 없다.
막힌 지점 — 문서의 숫자와 계정별 값
오류 코드 중 하나가 호출 한도 초과였는데 문서에 적힌 숫자와 우리 계정의 실제 한도가 달랐다. 문서의 값은 기본값 안내였고 실제 한도는 계정별로 정해지고 있었다.
처음에는 코드에 DAILY_LIMIT 상수를 넣고 직접 세려 했다. 틀린 값을 넣으면 아직 여유가 있는데 스스로 멈추므로 안 넣은 것보다 나쁘다.
해 본 것 — 세지 않고 반응하는 방식
잔여 한도를 조회하는 경로가 없어서 우리가 세는 방식 자체가 성립하지 않았다. 그래서 한도 초과 코드를 받으면 그날 안 보내고 물러나는 쪽을 골랐다. 이유는 값이 바깥에서 정해지면 바깥이 알려 줄 때 반응하는 편이 맞아서다.
우리가 세지 않으므로 한도가 바뀌어도 코드를 고칠 필요가 없다. 대신 한도에 닿은 날의 나머지 조회가 다음 날로 밀리는 것을 감수했다.
주의 — 눈으로 같아 보이는 다른 문자
응답 값을 거르는 코드에서 분명 맞는 값인데 안 걸리는 일이 있었다. xxd 로 찍어 보니 내가 쓴 가운뎃점은 U+00B7 이고 응답에 온 문자는 U+318D 였다. 값 뒤에 고정 길이 전문의 공백 패딩도 붙어 있어 trim() 없이는 어차피 안 맞았다.
문자열 비교가 안 되면 눈으로 보지 말고 바이트로 찍어 봐야 갈린다. 한도 부분도 처음에는 curl 로 몇 번 호출해 보고 제공하지 않는다고 결론냈는데 개발 가이드와 이용약관을 1차 소스로 읽으니 거기 있었으므로 도구로 두드려 본 것으로 없다고 결론 내면 안 됐다.
정리
- 상태 코드가 정상이어도 본문에 오류가 담겨 올 수 있다
- 상태 코드만 보는 검사는 구조적으로 그것을 못 잡는다
- 검사를 전송 계층과 응용 계층 둘로 나눈다
- 두 오류는 재시도 정책이 다르므로 예외도 나눈다
- 한도가 계정마다 다르고 문서의 숫자는 기본값 안내일 수 있다
- 틀린 상수는 안 넣은 것보다 나쁘다
- 우리가 세지 말고 상대가 알려 줄 때 물러난다
- 도구로 몇 번 두드려 본 것으로 없다고 결론 내지 않는다