고정값인 줄 알았는데 매번 다시 만든다

대상마다 다른 분류값을 주고 싶은데 시스템은 분류를 공통 매핑에서 가져온다. 그래서 그 대상만 분류 정보를 직접 바꿔 등록하는 우회안을 세웠다.

Open Table of contents

우회안이 기댄 전제

이 안은 분류가 한 번 등록되면 그대로 고정된다는 전제 위에 서 있었다. 이후 수정이 들어와도 분류는 건드려지지 않는다고 봤다.

실행하기 전에 그 전제를 코드에서 확인하기로 했다. 전제가 틀리면 안 전체가 무너지는 자리였기 때문이다.

전송 데이터를 만드는 함수를 열어 보니 호출될 때마다 매핑을 다시 읽어 분류를 조립하고 있었다. 수정이 일어날 때마다 현재 매핑값으로 새로 만들어져 덮인다는 뜻이다.

전제가 정반대였고 분류야말로 매번 재계산되는 값이었다. 한 번 고정되는 값과 매번 재계산되는 값은 겉으로 구분되지 않으므로 코드를 열어야 갈린다.

이 전제 위에서 실행했다면 직접 바꾼 값이 다음 수정 때 매핑값으로 돌아간다. 처음에는 반영되므로 성공한 것으로 보고 넘어가게 된다.

원인 모를 되돌림은 나중에 다른 자리에서 드러나고 그때는 이 조작과 연결되지 않는다. 아예 안 되는 것보다 한 번 통했다가 되돌아가는 쪽이 더 나쁜 이유가 여기 있다.

같은 사실을 반대로 보니 다른 결론이 나왔다. 매핑 자체를 바꾸면 이후 수정마다 새 값으로 나가므로 한 번 바꾸면 계속 유지된다.

전체를 다시 전송할 필요도 없어진다. 매번 재계산된다는 성질은 개별 조작을 막는 단점이면서 규칙 변경을 자동 반영하는 장점이었다.

문제가 하나 남았는데 매핑의 단위가 대상이 아니라 분류라는 점이었다. 그 분류에 속한 다른 것들도 전부 함께 바뀐다.

전용 분류를 만들어 대상만 옮기는 안과 대상별 오버라이드를 코드에 넣는 안이 있었다. 앞의 것은 구조를 안 건드리는 데이터 조작이라 당장은 그쪽으로 가고 요구가 반복되면 뒤의 것을 하기로 했다.

전제가 틀렸다는 사실 자체도 문서에 남겼다. 이 방법은 안 된다는 것도 결과이므로 적어 두지 않으면 다음 사람이 같은 우회안을 다시 세운다.