규칙이 시점에 따라 달랐다

이미지 변환 규칙에 대해 두 사람의 기억이 달랐다. 한쪽은 조건이 있다고 했고 다른 쪽은 조건 없이 항상 만든다고 했다.

Table of contents

상황 — 엇갈린 두 기억

두 사람이 기억하는 규칙은 이랬다.

A: 조건이 있다. 원본이 일정 크기 이상일 때만 만든다
B: 조건 없다. 항상 만든다

A 와 B 가 정반대라 둘 중 하나는 틀렸다고 봤다.

한쪽 말대로 만들면 다른 쪽이 기대하는 결과가 안 나오므로 어느 쪽이 맞는지 정하지 않으면 복구를 시작할 수 없었다.

두 사람 다 오래 이 자료를 다뤄 온 쪽이었다. 한쪽이 잘못 기억했다고 보기에는 양쪽 다 확신이 분명했다.

조사 — 양쪽 코드를 다 읽기

시스템이 옛 것과 새 것 둘이라 각각의 변환 정의를 열었다.

public function registerMediaConversions(Media $media = null)
{
    if ($media && $media->getCustomProperty('width') >= 1000) {
        $this->addMediaConversion('resize')...;
    }
}

registerMediaConversions 안에 너비 기준 조건이 있었다. 원본이 그 값을 넘을 때만 변환을 등록한다.

const rules = { 'HtmlContent': ['resize'] };
// 조건 없음

rules 에는 조건 없이 변환 이름만 적혀 있었다.

addMediaConversion 쪽과 rules 쪽이 서로 다른 규칙을 갖고 있었고 각각 자기 시스템에서는 맞았다.

원인 — 시점 차이였다

A 는 옛 시스템을 말하고 B 는 새 시스템을 말한 것이라 시점이 달랐다. 서로 다른 코드를 보고 서로 다른 규칙을 기억한 셈이다.

[틀린 물음]  A 가 맞나 B 가 맞나
[맞는 물음]  A 는 언제, B 는 언제 얘기인가

어느 쪽이 맞느냐가 아니라 언제 이야기냐가 물어야 할 것이었다.

둘 다 맞을 수 있다는 것을 전제하지 않으면 한쪽을 틀린 것으로 몰게 되고 오래된 시스템일수록 규칙이 바뀌어 와서 이런 경우가 흔하다.

제약 — 옛 데이터의 구멍

규칙이 달랐다는 것을 알고 나니 하나가 보였다.

큰 이미지   →  변환본 참조
작은 이미지  →  원본 참조

옛 시대에는 너비 기준에 안 걸린 작은 이미지의 resize 가 아예 없다.

그러면 그 건들의 참조는 원본을 가리키고 있고 코드가 지금 어떤지만 알아서는 이 구멍을 예상할 수 없다.

지금 규칙으로는 전부 있어야 하는데 실제로는 없는 구간이 생긴다. 없는 이유가 오류가 아니라 그때의 규칙이라는 것이 이 구멍의 성격이다.

규칙이 바뀐 시점이 자료의 경계를 만들고 있었다.

주의 — 백필이 참조와 포맷을 바꾼다

빠진 변환본을 지금 채우면 어떻게 되는지 봤다.

변환본을 만든다
    ↓
참조를 변환본으로 바꾼다
    ↓
원본이 다른 포맷이었으면 포맷이 바뀐다

새 시스템의 sharp 옵션이 포맷을 정규화하기 때문이다.

sharp(input)
  .resize({ width: 1000, fit: 'inside', withoutEnlargement: true })
  .jpeg({ quality: 80, mozjpeg: true })

withoutEnlargement 로 확대는 안 하는데 jpeg 로 포맷이 고정된다.

원본이 애니메이션이면 첫 프레임만 남고 투명 배경을 쓰던 것은 그 투명이 사라지므로 채우는 것이 이득만은 아니다.

결과 — 실측한 손실과 비교의 전제

백업에서 포맷별로 셌다.

기본 포맷    1,846건
애니메이션 가능 포맷   159건
투명 지원 포맷        25건

애니메이션 가능 포맷 과 투명 지원 포맷 을 합쳐 184건이라 전체의 10퍼센트쯤이었다.

숫자가 나오고 나서야 판단이 가능해졌고 전부 채울지 말지가 아니라 어느 것을 채울지의 문제로 바뀌었다.

대부분은 채우는 쪽이 이득이었다. 일부는 원본을 그대로 두는 편이 나아서 그 건들만 따로 표시해 뒀다.

그래서 이렇게 적어 남겼다. 채우면 참조가 원본에서 resize 로 바뀌므로 원본이 다른 포맷이었던 건은 정적화와 투명 손실 여부를 따로 판단해야 한다.

jpeg 정규화가 새 시스템에만 있다는 것도 함께 적었다.

옛 것으로 만든 것   원본 포맷
새 것으로 만든 것   정규화된 포맷

두 시스템의 산출물을 비교할 때 jpeg 냐 아니냐가 다른 것이 정상이다. 이것을 모른 채 비교하면 그 차이를 결함으로 읽게 되므로 비교의 전제로 적어 뒀다.

정리

• 두 기억이 다 맞을 수 있다
• 어느 쪽이 맞나보다 언제 이야기냐를 먼저 묻는다
• 둘 다 맞을 수 있다는 것을 전제하지 않으면 한쪽을 틀린 것으로 몬다
• 오래된 시스템일수록 규칙이 바뀌어 와서 이런 경우가 흔하다
• 옛 규칙에 조건이 있으면 그 시대 자료에 구멍이 있다
• 규칙이 바뀐 시점이 자료의 경계를 만든다
• 채우면 참조가 원본에서 변환본으로 바뀐다
• 포맷이 정규화되면 애니메이션과 투명이 사라진다
• 그런 건이 몇 건인지 포맷별로 센다
• 숫자가 나오면 전부 채울지가 아니라 어느 것을 채울지가 된다
• 정규화가 한쪽에만 있으면 산출물이 다른 것이 정상이다
• 그것을 비교의 전제로 적어 둔다