전수 검색으로 확정했다

설정 값을 바꾸기 전에 그것을 어디서 쓰는지를 짐작으로 정했다가 한 자리를 통째로 빠뜨렸다.

Open Table of contents

짐작으로 정한 범위

이 상수는 주문 쪽에서만 쓸 것이라고 보고 주문 폴더만 뒤져서 세 곳을 고쳤다. 배포하고 나서 정산에서 오류가 났는데 거기서도 같은 값을 쓰고 있었다.

전부 찾아보니 여섯 파일에 열두 번 나왔다. 주문 서비스와 컨트롤러와 화면 말고도 정산 서비스와 점검 명령에 들어 있었는데 둘 다 짐작에는 없던 자리였다. 짐작으로 정한 범위는 내가 아는 구조만큼만 넓고 그 경계는 안에서 안 보인다.

처음에는 PHP 파일만 봤는데 다른 종류의 파일에도 있었다. 확장자 제한을 풀고 다시 찾으니 설정 파일과 프런트 스크립트와 문서에서 셋이 더 나왔다.

프런트에 값이 박혀 있어서 서버만 바꾸면 화면에 보이는 값과 안 맞는 상태가 된다. 확장자를 정해서 찾으면 그 밖에 있는 것은 처음부터 시야에 안 들어온다.

이름 말고 값으로도 찾았다.

$ grep -rn "10000" --include=*.php app/ | grep -iE "min|amount|limit"

상수를 안 쓰고 값을 직접 적어 둔 자리가 넷 더 나왔는데 이름으로만 찾으면 이런 것은 영원히 안 나온다.

설정 키 이름을 문자열로 조립해서 참조하는 자리도 있었다.

$key = 'MIN_' . strtoupper($type) . '_AMOUNT';
$value = config($key);

이건 어떤 검색어로도 직접 안 잡힌다. 조립하는 형태를 따로 찾고, 더 확실하게는 설정 조회 자체에 로그를 걸어 며칠 돌리면서 실제로 조회된 키를 모았다. 정적 검색이 닿지 않는 참조는 실행 중에 관측해야 한다.

찾아낸 것을 검색 축별로 정리해서 사용처 목록으로 남겼다.

코드 (PHP)      6곳
프런트 (JS)     1곳
설정            1곳
문서            1곳
직접 값 사용    4곳  → 상수로 바꿈
조립 참조       1곳  → 실행 로그로 확인

그리고 결국 한 자리로 모았다. 값은 정책 클래스에 두고 프런트는 값을 갖지 않고 서버에서 받아 가며 문서는 코드에서 뽑아 만든다. 열두 자리가 하나가 됐다. 흩어진 것을 다 찾는 것보다 흩어질 수 없게 만드는 쪽이 근본이다.

한 번 찾고 나서 그 명령들을 스크립트로 남겼는데 이름으로 찾고 값으로 찾고 조립 가능성을 찾는 세 축을 순서대로 도는 형태다.

다음에 다른 상수를 찾을 때 그대로 썼고 매번 어떻게 찾을지 다시 생각하지 않게 됐다. 더 중요한 것은 빠뜨리는 축이 없어졌다는 점이다. 스크립트가 없던 때는 이름으로만 찾고 끝냈다.

한 자리로 모으고 나서 다시 흩어지지 않게 막는 것까지 했다. 값을 직접 쓰면 정적 분석에서 걸리게 하고 프런트에도 같은 검사를 넣었다. 서버에서 받아 가게 했으므로 그 값이 프런트 코드에 있을 이유가 없다.

막지 않으면 다음에 급할 때 또 직접 쓰고 그것이 쌓인다. 정리한 상태를 유지하는 장치가 없으면 정리는 한 번의 이벤트로 끝난다.