오늘은 주문 하나를 가져오다가 우편번호 때문에 멈칫했다. 처음엔 그냥 외부 주문 사이트에서 내려준 값이 조금 이상한가 보다 했다. 주소도 있고, 우편번호도 다섯 자리로 들어와 있으니 비개발자 입장에서는 얼핏 보면 정상처럼 보인다. 숫자 모양이 맞으면 맞는 값일 거라고 생각하기 쉽다.
그런데 직원이 화면을 보고 이상하다고 했다. 배송지는 서울인데, 우편번호 앞자리가 서울 쪽 느낌이 아니었다. 여기서부터 머리가 조금 아파졌다. 나는 처음에 “주소 검색 API가 틀렸나?” 쪽을 의심했다. 예전에도 주소 검색에서 엉뚱한 값을 가져와 문제가 된 적이 있어서, 이번에도 같은 종류의 사고라고 생각했다.
AI에게 같이 보자고 하고 먼저 한 일은, 그 주문의 저장값과 같은 주소의 과거 주문을 비교하는 것이었다. 다행히 같은 배송지로 들어온 예전 주문들이 남아 있었다. 예전 값은 모두 같은 정상 우편번호였고, 오늘 들어온 주문 하나만 다른 지역의 번호로 저장되어 있었다.
그다음 주소 검색을 직접 다시 해봤다. 같은 주소를 넣어도, 상세주소를 조금 빼도, 검색 API는 계속 정상 우편번호를 돌려줬다. 여기서 첫 가설이 깨졌다. “API가 지금 잘못 주고 있다”가 아니었다. 적어도 확인한 시점에는 API가 맞는 답을 주고 있었다.
더 헷갈렸던 건, 이미 예전에 재발방지 코드를 넣어둔 상태였다는 점이다. 저장된 우편번호와 주소 검색 결과를 비교해서 다르면 경고를 띄우는 장치가 있었다. 그런데 이번 건은 직원이 직접 찾아내기 전까지 화면에서 먼저 막지 못했다.
한참 확인하다 보니 핵심은 다른 데 있었다. 기존 방어는 “저장된 값과 다시 조회한 값이 다른지”를 보는 방식이었다. 하지만 값이 어디서 들어왔는지 확실하지 않고, 출고 완료 상태의 주문은 검사 대상에서 빠지는 구멍이 있었다. 숫자가 다섯 자리인지 보는 것만으로는 부족했다.
그래서 이번에는 기준을 하나 더 세웠다. 우편번호 앞자리와 주소의 시·도가 말이 되는지 확인하는 방식이다. 서울 주소라면 서울권 우편번호 범위여야 하고, 인천 주소라면 인천권 범위여야 한다. 완벽한 지도 시스템은 아니어도, “서울 주소인데 전혀 다른 지역 번호” 같은 큰 사고는 저장 직전에 막을 수 있다.
내 환경에서는 잘못 들어간 주문 한 건을 정상 값으로 고치고, 저장 직전 검사와 다운로드 전 차단을 같이 넣었다. 그리고 이미 출고 완료된 건이라고 해서 검사에서 빼지 않도록 바꿨다. 사람 눈에 보이는 오류는 이미 늦은 경우가 많으니, 엑셀이나 택배 파일로 나가기 전에 한 번 더 멈추게 한 것이다.
이번에 배운 건 단순했다. 형식이 맞는 값과 실제로 맞는 값은 다르다. 우편번호가 다섯 자리라고 해서 배송지와 맞는 건 아니다. 비개발자 입장에서는 숫자가 있으면 안심하고 넘어가고 싶은데, 자동화는 그런 안심을 그대로 믿으면 안 된다.
돌아보면 AI에게 “원인 찾아줘”라고 맡기는 것보다 더 중요한 건, 내가 어느 층을 의심하고 있는지 나누는 일이었다. API가 틀렸는지, 저장 경로가 다른지, 화면 경고 조건이 빠졌는지, 마지막으로 파일 다운로드 전에 막는지. 이번 삽질 덕분에 우편번호도 그냥 숫자가 아니라 업무의 안전장치라는 걸 배웠다.