경유와 참조라는 두 질문

재연동 작업에서 옛 식별자를 비워야 하는지 확인해야 했고 한 채널에 대해 필요 없다는 결론을 냈다. 그 결론의 근거가 그 채널 디렉터리에서 검색이 0건이었다는 것뿐이라는 지적을 받았다.

Open Table of contents

섞여 있던 두 질문

지적은 그 채널이 신규 시스템을 경유하는데 그 신규 시스템 안에서도 그 값을 안 보는지 확인했느냐는 것이었다. 여기서 물음이 둘로 갈려 있다는 것을 알았다.

하나는 이 채널의 등록 처리가 어느 시스템을 경유하느냐이고 다른 하나는 그 경로 어디에서도 옛 식별자를 참조하지 않느냐다. 내가 답한 것은 채널 디렉터리에 없다는 사실뿐이라 둘 중 어느 쪽도 아니었다.

실제 경로를 따라가 보니 작업 생성에서 채널 허브를 거쳐 상품 서비스의 등록 처리와 신규 시스템 위임을 지나 최종 엔드포인트에 닿았다. 각 계층에 그 값을 보는 코드가 있을 수 있는 구조였다.

채널 디렉터리만 본 것은 그 경로의 마지막 한 칸만 본 것이다. 경유하는 계층을 먼저 그리지 않으면 어디를 봐야 하는지 자체가 정해지지 않는다.

또 하나는 그 값이 담기는 필드가 불변이 아니라 가변으로 선언돼 있다는 점이었다. 즉 런타임에 상류나 다른 클라이언트가 그 값을 덮어쓸 수 있다.

다른 채널의 처리가 그 필드를 채우고 공통 경로를 지나면서 값이 쓰일 수 있으므로 선언 위치로 사용처를 한정할 수 없다. 이 성질 때문에 호출부 전수 확인이 필요했다.

저장소 전체에서 그 함수의 호출부를 열거하니 정확히 열 곳이었고 다섯 채널에 두 곳씩 나뉘어 있었다. 문제의 채널은 그 열 곳 어디에도 없었다.

결론은 처음과 같았지만 근거가 달라졌는데 디렉터리에 없다가 아니라 전체가 열 곳이고 그중에 없다가 됐다. 그 채널은 옛 식별자 체계를 거치지 않고 현재 식별자를 그대로 쓰고 있었으므로 처리가 필요 없는 것이 맞았다.

전수로 보고 나니 원래 묻지 않았던 사실이 나왔는데 나머지 다섯 채널에는 그 처리가 반드시 필요하다는 것이었다. 전역 옵션 가운데 상당한 비율이 실제로 그 값을 갖고 있었다.

좁은 범위의 0건은 무엇을 뜻하는지 알 수 없다. 정말 안 쓰는 것인지 다른 이름으로 부르는 것인지 상류에서 채워지는 것인지 구분되지 않으므로 전체를 열거한 뒤의 0건만 반례를 배제한다.