미등록이라 비어 있다

한 유동성 공급사의 마켓 가져오기 목록에서 수백 건이 전부 공란이라는 문의가 왔다. 화면에는 market_group 과 link_status 가 모두 비어 있었고 값이 안 채워지는 것이므로 조회 쪽 문제로 보였다.

Table of contents

원인 — 하드코딩된 공란

grep 으로 목록을 만드는 코드를 찾아 열어 보니 market_group 항목이 아예 빈 문자열 '' 로 고정돼 있었다. 이 화면에서는 그 항목의 값을 아예 채우지 않는 것이 원래 동작이었다.

즉 그 항목이 비어 있는 것은 그 공급사의 자료와는 아무 상관이 없었다. 화면에 자리가 있으니 값이 있어야 할 것처럼 보였을 뿐이다. 빈칸이 전부 같은 이유로 비어 있는 것이 아니라는 것이 첫 발견이었다.

기등록이 있을 때만 채워진다

화면의 다른 항목은 자료가 있을 때만 채워지는 조건부 구조로 돼 있었다. 이미 우리 쪽 MySQL 의 markets 에 등록된 마켓과 symbol 로 매칭되면 link_status 를 보여 주고 아니면 빈칸이다.

그러면 그 공급사의 마켓이 전부 미등록이라는 뜻이 된다. 미등록이라 link_status 가 비고 market_group 은 그와 무관하게 늘 비므로 화면 전체가 공란인 것이 정상 동작이었다. 결함으로 보이던 것이 조건이 안 맞았을 때의 정상 결과였다.

왜 전부 미등록인가

전부 미등록이라는 것 자체는 이상해서 그 이유를 따로 봤다. 매칭에 쓰는 symbol 을 SELECT 해 보니 그 공급사 것만 형식이 달랐다.

다른 공급사   ETH/BTC
그 공급사     BTC-ETH   ← 옛 체계

확인해 보니 그 공급사는 예전 체계로 등록된 뒤 이관 과정에서 symbol 이 그대로 남아 있었다. 다른 공급사는 새 체계 형식이라 매칭이 되는데 그 공급사만 안 됐다. 정상 동작이라는 결론과 왜 이 공급사만 그런지가 각각 다른 답이었다.

안내로 처리하기

동작이 설계대로인 것이므로 코드를 고치는 대신 안내로 처리하는 쪽을 골랐다. 이유는 화면이 설계대로 도는데 코드를 손대면 다른 공급사의 표시까지 바뀌어서다. 다만 정상 동작이라고만 답하면 받는 쪽에서는 납득하기 어려울 것이었다.

그래서 회신에 세 가지를 담았는데 화면 구조상 언제 값이 채워지는지와 이 공급사의 사정과 등록하려면 어떤 절차를 밟는지였다. 왜 그런지와 어떻게 하면 되는지를 함께 주는 것이 정상 동작 문의의 답이었다. 그리고 건수가 수백 건이라 하나씩 등록하기 어려워서 symbol 을 새 체계로 바꿔 일괄 등록하는 경로도 함께 안내했다.

정상 동작 문의의 형태

이런 문의는 결함 신고와 형태가 같아서 처음에는 구분되지 않는다. 실제로 조사를 해 보고 나서야 정상 동작인지 결함인지가 비로소 갈린다.

그래서 정상이라고 판정한 뒤에도 조사한 내용을 기록으로 남겼다. 같은 문의가 다른 공급사에서 다시 들어오면 그 기록만 열어서 바로 답할 수 있다. 정상이라는 결론이 나왔다고 해서 조사가 필요 없었던 것은 아니었다.

정리

• 목록의 값이 하드코딩으로 비어 있을 수 있다
• 빈칸이 전부 같은 이유로 비어 있는 것은 아니다
• 다른 값은 조건이 맞을 때만 채워진다
• 미등록으로 비는 칸과 늘 비는 칸이 섞여 있다
• 왜 전부 미등록인지는 따로 확인한다
• 옛 이력 때문에 symbol 형식이 다를 수 있다
• 회신에 구조와 사정과 절차 셋을 담는다
• 정상이라는 결론도 기록으로 남긴다