시세 제공사에 나가는 마켓 정보에서 한 마켓만 DEFI 분류로 주고 싶은데 시스템은 분류를 coin_category_map 공통 매핑에서 가져온다. 그래서 그 마켓만 PUT /markets/{id} 로 분류 정보를 직접 바꿔 등록하는 우회안을 세웠다.
Table of contents
Open Table of contents
배경 — 우회안이 기댄 전제
이 안은 분류가 한 번 등록되면 그대로 고정된다는 전제 위에 서 있었다. 이후 마켓 정보 수정이 들어와도 category 는 건드려지지 않는다고 봤다.
실행하기 전에 그 전제를 코드에서 확인하기로 했다. 전제가 틀리면 안 전체가 무너지는 자리였기 때문이다.
검증 — 코드가 뒤집은 전제
MarketPayloadBuilder 를 열어 보니 호출될 때마다 coin_category_map 을 다시 읽어 category 를 조립하고 있었다. 수정이 일어날 때마다 현재 매핑값으로 새로 만들어져 덮인다는 뜻이다.
전제가 정반대였고 category 야말로 매번 재계산되는 값이었다. 한 번 고정되는 값과 매번 재계산되는 값은 겉으로 구분되지 않으므로 코드를 열어야 갈린다.
주의 — 한 번 통했다가 되돌아가는 구조
이 전제 위에서 실행했다면 직접 바꾼 category 가 다음 PUT 때 coin_category_map 값으로 돌아간다. 처음에는 반영되므로 성공한 것으로 보고 넘어가게 된다.
원인 모를 되돌림은 나중에 다른 자리에서 드러나고 그때는 이 조작과 연결되지 않는다. 아예 안 되는 것보다 한 번 통했다가 되돌아가는 쪽이 더 나쁜 이유가 여기 있다.
뒤집으면 이점이 된다
같은 사실을 반대로 보니 다른 결론이 나왔다. MarketPayloadBuilder 가 매번 읽는다는 것은 매핑이 곧 정본이라는 뜻이다. coin_category_map 자체를 바꾸면 이후 수정마다 새 값으로 나가므로 한 번 바꾸면 계속 유지된다.
전체 마켓을 다시 전송할 필요도 없어진다. 매번 재계산된다는 성질은 개별 조작을 막는 단점이면서 규칙 변경을 자동 반영하는 장점이었다.
판단 기준 — 규칙 단위가 넓은 대가
문제가 하나 남았는데 매핑의 단위가 마켓이 아니라 코인 분류라는 점이었다. 그 분류에 속한 다른 마켓들도 전부 함께 바뀐다.
두 가지 방법이 있었다. 전용 분류를 하나 만들어 그 마켓만 옮기는 것과, MarketPayloadBuilder 에 마켓별 오버라이드를 코드로 넣는 것이다. 앞쪽을 골랐다. 이유는 구조를 안 건드리는 데이터 조작이라 배포 없이 끝나서다. 대신 분류가 하나 더 늘어 관리 화면 목록이 길어지는 것을 감수했고 요구가 반복되면 뒤의 것을 하기로 했다.
전제가 틀렸다는 사실 자체도 문서에 남겼다. 이 방법은 안 된다는 것도 결과이므로 적어 두지 않으면 다음 사람이 같은 우회안을 다시 세운다.
정리
- 우회안을 세우면 그 안이 기대는 전제를 적고
MarketPayloadBuilder같은 코드로 확인한다 - 한 번 고정인지 매번 재계산인지가 자주 갈리는 전제다
- 매번 재계산되면 개별 조작이 안 되고 규칙 변경이 자동 반영된다
- 같은 성질이 단점이자 장점이 된다
- 한 번 통했다가 되돌아가는 구조가 아예 안 되는 것보다 나쁘다
coin_category_map단위가 넓으면 전용 분류를 만들거나 오버라이드를 넣는다- 구조를 안 건드리는 쪽을 먼저 쓰고 요구가 반복되면 옮긴다
- 이 방법은 안 된다는 것도 결과이므로 적어 둔다