외부 전송이 실패하고 로그에 낯선 문구가 남았다. 파라미터 이름이 낯설어서 우리가 보낸 것인지부터 봐야 했다.
Table of contents
Open Table of contents
상황 — 낯선 파라미터 이름
로그는 이랬다.
... 해당 예외 조건이 존재하지 않습니다.
exceptDivCd : 10 exceptCd : 102 / FAILexceptDivCd 와 exceptCd 를 본 기억이 없었다.
우리 로그에 찍혔으니 우리가 보낸 값으로 읽히는데 exceptCd 라는 이름을 아는 사람이 없었다. 로그에 있다는 것과 우리가 만들었다는 것이 같은지부터 확인해야 했다.
조사 — 전수 검색과 직접 열람
여러 표기로 저장소 전체를 찾았다.
rg 'exceptDivCd|exceptCd|except_div_cd'
rg '예외 조건'rg 로 두 번 돌렸는데 전부 0건이었다.
rg 에 안 나오는 것이 정말 없다는 뜻인지는 한 번 더 봐야 했는데 이름이 const 나 설정에서 조립되면 그 문자열이 코드에 통째로 없을 수 있다.
전송 파라미터를 구성하는 자리를 직접 열었다.
브로커 클래스
요청 구성 클래스
내부 전송 객체
공통 전송 객체넷을 다 봤지만 exceptDivCd 를 만드는 코드가 없었다.
사내 API 문서에서도 찾아봤는데 우리가 아는 파라미터 목록에 그 이름이 없었다.
원인 — 상대가 준 응답이었다
흐름을 정리하면 이렇다.
우리가 요청을 보냄
↓
상대가 내부 검증
↓
검증 실패 → 오류 응답 (그 파라미터 이름 포함)
↓
우리 코드가 그 응답을 그대로 던짐던지는 자리는 한 줄이었다.
if ($this->isException($response)) {
throw new Exception($response['message']);
}$response['message'] 를 그대로 Exception 에 실어 던진다.
그래서 상대가 쓴 파라미터 이름이 우리 로그에 우리 것처럼 찍힌다. 남의 문구를 그대로 옮겨 담는 자리가 하나 있으면 로그의 출처가 섞인다.
로그를 볼 때 그 문구를 누가 만들었는지부터 가려야 했다. 우리 코드에 그 문자열이 있으면 우리 것이고 없으면 상대 것이다.
제약 — 우리 코드로 못 고친다
출처가 갈리면 대응 방향도 갈린다.
exceptDivCd 와 exceptCd 는 상대 쪽 예외 설정 코드였다. 해당 업체 계정에 그 조건이 등록돼 있지 않은 상태였다.
우리 코드를 아무리 고쳐도 이 오류는 없어지지 않고 재시도를 늘리거나 값을 바꿔 보내도 같은 FAIL 이 온다.
조치는 상대 담당자에게 등록을 요청하는 것이었다. 어디에서 나온 오류인지를 가리는 것이 대응의 첫 단계였다.
비교 — 한 업체와 여러 업체
두 업체에서 같은 시각에 같은 FAIL 이 났다는 것도 단서였다.
[한 업체만] 그 업체 설정 문제
[동시에 여럿] 상대 정책 변경 또는 신규 설정 누락조건이 서로 다른 건들이 같은 시각에 함께 실패하면 공통 원인이 밖에 있을 가능성이 높다.
회신에는 두 업체에서 동시에 났으므로 정책 변경이거나 신규 입점 설정 누락을 의심한다고 적었다. 실패한 건을 시각으로 모아 보는 것만으로 이 패턴이 드러났고 값싼 확인이었다.
검증 — 없음을 확정하는 방법
이 조사의 핵심은 없다는 것을 확정한 쪽이었다.
① 여러 표기로 전수 검색 → 0건
② 전송 파라미터를 만드는 클래스 넷을 직접 열람 → 없음
③ 사내 문서 확인 → 없음rg 와 클래스 열람과 문서 확인 셋을 다 하고 나서 우리 것이 아니라고 말했다.
rg 만 하고 끝냈으면 동적으로 만들어졌을 가능성이 남는다. 없음을 증명하려면 범위를 정하고 여러 방법으로 봐야 한다.
회신에는 결론만 쓰지 않고 확인 방법을 같이 적었다.
이 오류는 상대 시스템이 반환한 것으로, 우리 코드에 해당 파라미터가 없습니다.
(확인: 전체 검색 0건, 전송 파라미터 구성 클래스 4곳 직접 확인)
해당 코드는 상대 측 예외 설정으로 보이며,
그 업체 계정에 조건이 등록돼 있지 않은 상태입니다.
조치: 상대 담당자에게 해당 업체 예외 조건 등록 요청우리 것이 아니라고만 쓰면 책임 회피로 읽힌다. 어떻게 확인했는지를 붙이면 같은 말이 근거가 된다.
정리
- 로그의 파라미터 이름이 낯설면 우리 코드에 있는지 검색한다
- 검색으로 없으면 전송 값을 만드는 클래스도 직접 연다
- 이름이 조립되면 그 문자열이 코드에 통째로 없을 수 있다
- 우리 코드가 상대 응답을 그대로 예외로 던지면 출처가 섞인다
- 로그에 찍힌 것이 우리 것이라는 뜻은 아니다
- 코드에 그 문자열이 있으면 우리 것이고 없으면 상대 것이다
- 우리 것이 아니면 우리 코드로 못 고친다
- 동시 발생은 공통 원인이 밖에 있음을 가리킨다
- 없음을 확정하려면 범위를 정하고 여러 방법으로 확인한다
- 회신에 확인 방법을 같이 적는다