한 업체의 가져오기 목록에서 수백 건이 전부 공란이라는 문의가 왔다. 화면에는 분류와 연결 상태가 모두 비어 있었고 값이 안 채워지는 것이므로 조회 쪽 문제로 보였다.
Table of contents
Open Table of contents
원인 — 하드코딩된 공란
grep 으로 목록을 만드는 코드를 찾아 열어 보니 분류 항목이 아예 빈 문자열로 고정돼 있었다. 이 화면에서는 그 항목의 값을 아예 채우지 않는 것이 원래 동작이었다.
즉 그 항목이 비어 있는 것은 그 업체의 자료와는 아무 상관이 없었다. 화면에 자리가 있으니 값이 있어야 할 것처럼 보였을 뿐이다. 빈칸이 전부 같은 이유로 비어 있는 것이 아니라는 것이 첫 발견이었다.
기등록이 있을 때만 채워진다
화면의 다른 항목은 자료가 있을 때만 채워지는 조건부 구조로 돼 있었다. 이미 우리 쪽 MySQL 에 등록된 상품과 매칭되면 그 정보를 보여 주고 아니면 빈칸이다.
그러면 그 업체의 상품이 전부 미등록이라는 뜻이 된다. 미등록이라 연결 상태가 비고 분류는 그와 무관하게 늘 비므로 화면 전체가 공란인 것이 정상 동작이었다. 결함으로 보이던 것이 조건이 안 맞았을 때의 정상 결과였다.
왜 전부 미등록인가
전부 미등록이라는 것 자체는 이상해서 그 이유를 따로 봤다. 매칭에 쓰는 식별자를 SELECT 해 보니 그 업체 것만 형식이 달랐다.
확인해 보니 그 업체는 예전 체계로 등록된 뒤 이관 과정에서 식별자가 그대로 남아 있었다. 다른 업체는 새 체계 형식이라 매칭이 되는데 그 업체만 안 됐다. 정상 동작이라는 결론과 왜 이 업체만 그런지가 각각 다른 답이었다.
안내로 처리하기
동작이 설계대로인 것이므로 코드를 고치는 대신 안내로 처리하기로 했다. 다만 정상 동작이라고만 답하면 받는 쪽에서는 납득하기 어려울 것이었다.
그래서 회신에 세 가지를 담았는데 화면 구조상 언제 값이 채워지는지와 이 업체의 사정과 등록하려면 어떤 절차를 밟는지였다. 왜 그런지와 어떻게 하면 되는지를 함께 주는 것이 정상 동작 문의의 답이었다. 그리고 건수가 수백 건이라 하나씩 등록하기 어려워서 일괄 등록 경로도 함께 안내했다.
정상 동작 문의의 형태
이런 문의는 결함 신고와 형태가 같아서 처음에는 구분되지 않는다. 실제로 조사를 해 보고 나서야 정상 동작인지 결함인지가 비로소 갈린다.
그래서 정상이라고 판정한 뒤에도 조사한 내용을 기록으로 남겼다. 같은 문의가 다른 업체에서 다시 들어오면 그 기록만 열어서 바로 답할 수 있다. 정상이라는 결론이 나왔다고 해서 조사가 필요 없었던 것은 아니었다.
정리
- 목록의 값이 하드코딩으로 비어 있을 수 있다
- 빈칸이 전부 같은 이유로 비어 있는 것은 아니다
- 다른 값은 조건이 맞을 때만 채워진다
- 미등록으로 비는 칸과 늘 비는 칸이 섞여 있다
- 왜 전부 미등록인지는 따로 확인한다
- 옛 이력 때문에 식별자 형식이 다를 수 있다
- 회신에 구조와 사정과 절차 셋을 담는다
- 정상이라는 결론도 기록으로 남긴다