한쪽만 막으면 다른 쪽으로 샌다

상위 항목을 수정하면 하위로 전파되는 기능에 확인 절차를 붙이려 했다. 편집 화면의 저장 경로를 찾아 거기에 넣고 배포 직전에 다른 경로가 있는지 훑었다.

Open Table of contents

저장 경로가 하나가 아니었다

목록에서 옵션 아이콘으로 바로 고치는 경로가 따로 있었다. 별도 컨트롤러와 별도 서비스 메서드를 타므로 내가 손댄 저장 경로를 거치지 않는다.

그쪽에서도 전파는 똑같이 일어난다. 확인 절차는 한쪽에만 붙어 있고 다른 쪽으로는 그대로 나가는 상태였다.

이력을 보니 목록에서 바로 옵션을 고치는 기능이 나중에 추가된 것이었다. 편집 화면을 열지 않고 빠르게 바꾸는 용도였으므로 전체 저장 로직이 필요 없다고 본 것이다.

옵션만 바꾸는데 무거운 경로를 재사용할 이유가 없으니 합리적인 판단이었다. 다만 전파는 양쪽 다 하므로 보호가 필요한 지점도 양쪽이 된다.

이런 것을 놓치지 않으려면 함수 이름으로 검색하는 방식이 약하다. 이번에도 두 경로의 함수 이름이 달라서 하나만 검색했으면 놓쳤을 것이다.

더 확실한 방법은 결과에서 거슬러 올라가는 것이었다. 전파가 결국 작업 큐에 넣는 것이라면 그 큐에 넣는 코드를 찾아 호출자를 전부 역추적한다.

이 건에서 가장 중요한 것은 고쳤다고 보고하기 전에 경로를 다 찾았는지 확인하는 일이었다. 한쪽만 고치고 완료로 보고하면 나중에 같은 증상이 다시 나온다.

그때는 아무도 둘째 경로를 의심하지 않는데 이미 고쳤다는 기록이 있기 때문이다. 부분 수정이 미수정보다 나쁠 수 있는 것은 그 기록이 다음 조사를 막기 때문이다.

확인 절차를 만들면서 화면에 보여 줄 하위 목록이 없다는 문제도 나왔다. 편집 화면이 쓰는 인터페이스가 하위를 전혀 로드하지 않아서 추가하려니 부하가 걱정됐다.

하위 개수와 조인 키의 인덱스와 실행 계획을 실측하니 무시할 수 있는 수준이었다. 걱정만 하고 안 넣었으면 화면이 계속 정보 없이 동작했을 것이고 실측 없이는 그 판단을 못 했다.

자동 전파 여부를 나타내는 플래그는 상품 쪽에 있을 줄 알았는데 계정 설정에 있었다. 컬럼이 아니라 접근자로 구현돼 있어서 관계처럼 보이지만 매번 서브쿼리를 타는 형태였다.