단방향이 설계다

연동 마켓을 전부 판매 중지했는데 마스터에 반영이 안 되니 역전파 로직이 필요하다는 요청을 받았다. 요청이 이미 해법까지 담고 있었으므로 그 해법이 맞는지부터 봤다.

Open Table of contents

해법까지 담긴 요청

요청에 해법이 들어 있으면 그것을 만드는 일로 바로 넘어가기 쉽다. 그러면 그 해법이 옳은지는 아무도 검토하지 않는다.

받은 것은 증상과 제안이고 확인할 것은 지금 구조가 왜 그렇게 되어 있는지였다. 그래서 상태 변경 코드부터 읽었다.

마스터를 바꾸면 하위 마켓 상품이 전부 바뀌고 외부 채널 작업까지 생성됐다. 마켓 상품을 바꾸면 그 하나만 바뀌었다.

상위로 거슬러 마스터를 바꾸는 코드는 찾아도 없었고 하위 상태를 모아 상위를 정하는 집계도 없었다. 그러면 이것이 빠뜨린 것인지 의도한 것인지를 가려야 했다.

역전파를 넣었을 때의 흐름을 그려 보니 마지막 마켓을 중지하는 순간 마스터가 중지되고 그것이 다시 아래로 퍼진다. 지금은 이미 전부 중지 상태라 티가 안 나지만 나중에 한 채널만 다시 열 때 문제가 된다.

특정 마켓만 잠시 내린다는 통상 운영이 그 순간 성립하지 않게 되므로 역전파가 없는 것이 결함이 아니라 설계였다. 마스터는 판매 여부를 정하는 층이고 마켓 상품은 각 채널에 지금 내보내는지를 정하는 층이다.

아래층의 상태를 모아 위층을 정하면 두 층의 구분이 무너진다. 그래서 전 마켓 중지가 목적이면 마켓 상품이 아니라 마스터에서 중지해야 한다고 회신했다.

이미 마켓만 전부 중지된 상태를 되돌리는 방법도 함께 냈는데 마스터를 중지했다가 다시 판매 중으로 바꾸면 전파가 다시 일어난다. 안 된다는 답으로 끝내지 않고 지금 구조에서 가능한 조작을 준 것이다.

같은 요구가 반복되면 미봉책으로 역전파를 넣지 말고 상태 계층을 다시 보는 기획 사안으로 올린다고 적었다. 부작용을 알면서 코드로 몰래 처리하면 나중에 원인을 못 찾는다.

없다는 결론을 내려면 어디까지 봤는지를 밝혀야 하므로 상품 서비스와 채널 서비스 전체를 훑고 확인한 지점 셋을 적었다. 그래야 받는 쪽에서 안 본 자리를 지적할 수 있다.