이미지 처리를 새로 만든 ImageService 로 위임하는 작업에서 걱정거리는 하나로 좁혀져 있었다. 위임하면서 변환 규격이 달라지면 지금까지 만들어 온 결과물이 바뀐다는 것이었다.
Table of contents
Open Table of contents
배경 — 위임 전에 대조할 것
위임에서 생기는 위험은 대체로 양쪽 규격이 어긋나는 데서 온다. 두 가지 방법이 있었는데 위임하고 결과물이 달라지는지 지켜보는 것과 위임 전에 규격 정의 파일을 대조하는 것이다. 뒤쪽을 골랐다. 이유는 결과물이 달라진 뒤에는 이미 만들어진 것이 섞여 되돌리기 어려워서다. 대신 위임 착수가 하루 늦어지는 것을 감수했다. 새 서비스의 conversions.php 를 먼저 열어 어떤 단위로 분기하는지를 봤다.
그 안에는 모델과 컬렉션별로 생성할 결과물의 이름이 그대로 나열돼 있었다. Product 에는 thumb 부터 다섯 종류가 걸려 있고 본문 이미지에는 하나만 걸려 있는 식이었다.
검증 — 옛 정의와의 일치
기존 시스템의 registerMediaConversions() 도 열어서 같은 단위로 나열한 뒤에 옆에 놓고 하나씩 대조했다. 개수도 이름도 전부 같았고 ProductContent 같은 나머지 모델에서도 어긋나는 자리가 하나도 없었다.
이 대조 하나로 앞의 걱정이 원인 후보에서 빠졌다. 문제가 생기면 규격이 아니라 다른 곳을 봐야 한다는 것이 이 대조의 결론이었다.
조치 — 대조에서 나온 생성 알고리즘
예상하지 못한 것을 같이 얻었는데 결과물의 생성 알고리즘이 그 파일에 들어 있었다. crop-center 로 짧은 축 기준 정사각 중앙 크롭을 하고 한 변을 MIN_SIDE 와 MAX_SIDE 구간으로 제한하는 방식이었다.
원본의 짧은 축이 그 구간보다 작으면 MIN_SIDE 로 올라가고 크면 MAX_SIDE 로 내려간다. 구간 안에 들어오면 원본의 짧은 축 값이 그대로 한 변의 길이가 된다.
원인 — 알고리즘이 설명한 두 가지
오래 궁금했던 두 가지가 이 알고리즘 하나로 한꺼번에 설명됐다. 결과물이 항상 정사각인 것은 crop-center 이기 때문이고 크기가 특정 구간에 몰리는 것은 한 변에 상한과 하한이 걸려 있기 때문이었다.
앞서 이미지가 작게 나온다는 조사에서 확인한 것과 정확히 같은 알고리즘이었다. 왜 이런지 아무도 모른다는 상태는 대개 그 파일을 아무도 안 읽어서 생긴다.
주의 — 규격이 같다는 것의 다른 면
안 쓰는 medium 크기를 빼서 생성 개수를 줄이자는 물음이 이어졌는데 여기서 규격이 같다는 사실이 반대로 작용했다. 새 서비스의 규격이 옛 규격과 같으므로 줄이는 것은 옛 규격 자체를 줄이는 변경이 된다.
옛 경로로 이미 만들어진 결과물에도 영향이 가므로 국소 변경이라고 할 수 없었다. 그래서 어느 대상이 어느 크기를 실제로 쓰는지 grep 사용처 분석이 선행돼야 한다고 TODO.md 에 미결로 남겼다.
정리
- 위임 전에 규격을 대조하면 원인 후보 하나가 줄어든다
- 대조는 같은 단위로 나열해서 옆에 놓고 본다
- 대조하다 결과물의 생성 알고리즘 자체를 얻을 수 있다
- 왜 이런지 모른다는 상태는 대개 안 읽어서 생긴다
- 규격이 같으면 줄이는 변경도 옛 경로에 영향을 준다
- 국소 변경이 아니면 할 수 있다가 아니라 무엇이 먼저인지로 답한다
- 다른 사람이 정리해 준 규격도 직접 읽어서 확인한다
- 확인 없이 받아 쓰면 틀렸을 때 틀린 줄 모른다