thumb 변환본 생성 조건을 넓히려 했고 지금은 MIN_WIDTH 이상만 변환하고 있었다. 넓히면 무엇이 깨지는지를 확인해야 했다.
Table of contents
Open Table of contents
배경 — 넓히기 전에 던진 반대 질문
무엇이 깨지느냐보다 먼저 물을 것이 있었다. 지금 조건 때문에 변환이 안 생기는 대상이 이미 있는데 그것들은 왜 안 깨지고 있는지였다.
이미 없는 상태로 돌고 있는 것이 있으면 그 사실 자체가 의존 관계를 알려 준다. 그래서 grep -rn "thumb" 으로 변환본을 쓸 만한 곳을 전부 찾아 각각이 없을 때 어떻게 되는지를 봤다.
검증 — 세 저장소의 의존 여부
ChannelPayloadBuilder 는 원본 주소를 그대로 저장하고 전송해서 변환본에 의존하지 않았다. ContentRenderer 는 상세 내용을 처리할 때 <img src> 를 재작성하지 않고 원본을 그대로 넘겼다.
마지막 ImageController 는 요청이 오면 없을 때 즉석에서 만들어 준다. 어느 곳도 사전 존재를 강제하지 않으므로 변환이 안 생겨도 오류가 나지 않았다.
원인 — 존재를 확인 안 하는 대기
한 곳에는 최근 생성된 media 가 있으면 sleep(3) 으로 일정 시간을 그냥 쉬는 코드가 있었다. 변환이 실제로 생겼는지는 확인하지 않는다.
그래서 영영 안 생겨도 멈추거나 예외가 나지 않고 정해진 시간만 쉬고 지나간다. 의도한 구조인지는 알 수 없지만 결과적으로 이것도 의존하지 않는 쪽에 기여하고 있었다.
조치 — 변경의 자유도
아무도 강제하지 않으니 조건을 넓히든 좁히든 렌더링과 전송은 안 깨진다. 두 가지 방법이 있었는데 조건을 바로 넓히는 것과 의존 관계를 먼저 세는 것이다. 뒤쪽을 골랐다. 이유는 깨지는지 모르는 채 넓히면 어디서 깨졌는지 찾는 데 더 오래 걸려서다. 대신 변경 자체는 하루 늦어지는 것을 감수했고 원래는 넓히려던 것인데 좁혀도 안전하다는 것까지 함께 확인된 셈이다.
의존 관계를 세고 나면 무엇을 바꿔도 되는지의 폭이 드러난다. 그 폭을 모르면 안전한 변경도 위험한 것으로 다루게 된다.
주의 — 반대 방향의 부담
넓히는 쪽에는 다른 위험이 있었는데 조건을 풀면 아주 큰 이미지도 변환 대상이 된다. 그런 이미지는 ImageMagick 이 변환할 때 메모리를 많이 쓴다.
지금 조건이 결과적으로 그것을 걸러 내고 있었을 수 있다. 안 깨진다는 확인만 하고 늘어나는 부담을 안 보면 절반만 확인한 것이므로 MAX_WIDTH 상한이 필요한지는 이번 범위 밖의 별도 판단으로 남겼다.
정리
- 조건을 바꾸기 전에 누가 그것에 의존하는지 센다
- 이미 없는 상태로 도는 것이 있으면 그것이 의존 관계를 알려 준다
- 각각이 없을 때 오류인지 폴백인지 그냥 지나가는지를 본다
- 아무도 사전 존재를 강제하지 않으면 조건을 바꿔도 안 깨진다
- 존재를 확인 안 하고 고정 시간만 쉬는 대기가 있을 수 있다
- 의존 관계를 세면 변경의 자유도가 드러난다
- 안 깨진다는 확인만 하면 절반만 확인한 것이다
- 넓혔을 때 늘어나는 부담을 따로 본다