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