다른 층에 있던 고칠 자리

하위 항목이 상위의 이미지를 함께 쓰게 만들어야 했고 경로 생성기를 갈아 끼우면 되는 것으로 보였다.

class SharedPathGenerator implements PathGenerator
{
    public function getPath(Media $media): string
    {
        // 상위 것을 가리키게
    }
}

설정 한 줄이면 되는 일로 보였다.

Open Table of contents

선택지 — 경로 생성기 교체라는 첫 안

고치기 전에 그 URL 을 누가 쓰는지 전수로 봤다.

grep -rn "getUrl\|getFirstMediaUrl\|media" app/ resources/ --include='*.php' --include='*.vue'

한 자리를 고치는 안이면 그 자리를 지나가는 것이 전부여야 하기 때문이다.

getUrl 과 getFirstMediaUrl 을 부르는 자리가 여러 군데였고 전부 같은 방식으로 URL 을 만드는 것도 아니었다. 첫 안이 성립하는지가 이 조사 결과에 달려 있었다.

나온 소비처를 분류하니 둘로 갈렸다.

부류 A   프론트·검색·어드민·공개 API
           → 프레임워크의 경로 생성기 → 저장소 원본 URL

부류 B   외부 전송 모듈 8곳 이상
           → 자체 경로 조립

PathGenerator 를 갈아 끼우면 부류 A 만 바뀌고 부류 B 에는 안 닿는다.

PathGenerator 만 고치면 부류 A 는 되고 부류 B 는 안 되는 반쪽짜리가 된다. 반대쪽을 고쳐도 마찬가지이므로 이 층에서는 어느 쪽을 골라도 답이 아니었다.

그래서 부류 A 와 부류 B 가 함께 지나가는 지점을 찾아 올라갔더니 한 층 위에 있었다. URL 을 어떻게 만들지가 아니라 Media 중 어느 것을 읽을지를 정하는 자리였다.

거기를 바꾸니 두 계통이 모두 같은 결과를 냈다. 고칠 자리를 찾는 일이 사실은 두 경로의 공통 지점을 찾는 일이었다.

그런데 그 지점은 프레임워크 설정에 걸려 있어서 값이 전역으로 적용되는 자리였다. 한 화면에서만 옛 동작으로 돌리는 것이 안 되므로 문제가 생기면 전부 원래 값으로 돌려야 한다.

그래서 적용하기 전에 영향을 받는 곳을 한 번 더 훑고 각각이 어떻게 바뀌는지를 확인했다. 손쓸 방법이 전부 원래 값으로 돌리는 것뿐이면 나가기 전에 보는 수밖에 없다.

적용한 뒤에 한 화면만 열어 보고 끝냈으면 나머지 계통에서 두 번째로 걸렸을 것이다. 실제로 확인하는 과정에서 두 자리가 더 나왔고 둘 다 조사 목록에 있던 것이었다.

전수 조사를 안 했으면 그 둘은 나중에 문의로 돌아왔을 것이다. 해법을 고르기 전에 그 해법이 어느 층에 있어야 하는지를 먼저 묻는 것이 이 건의 순서였다.