해법의 비용이 문제의 크기나 수명을 넘으면, 그 해법은 틀렸다

해법을 고르기 전에 회수까지 몇 달과 이 문제·프로젝트가 몇 달 더 사나를 나란히 놓고, 앞쪽이 크면 더 가벼운 해법을 고른다.

이럴 때

새 도구·프레임워크·인프라를 들일 때. 레거시 전환을 제안할 때. "일단 우회해서"가 나올 때. 요금 청구서가 왔을 때.

이렇게

  • "이걸로 무엇을 할 수 있나"보다 "이걸 쓰면 무엇을 치르나"를 먼저 센다.
  • 레거시에서는 기존 제약을 건드리지 않는 개선을 먼저 본다.
  • 내 레포 밖에 더 싼 답이 있는지 묻는다.
  • 쓰지 않는 통계·잡·인프라의 유지 비용은 끈다.

멈출 신호·예외

요구가 진짜라면 무거운 해법이 맞다. 그 요구가 진짜인지를 먼저 확인한다. 하나를 피하려고 우회 장치를 여러 개 만들고 싶어지면 우회를 멈추고 원인을 본다.

설명

해법의 값은 그 해법이 무엇을 할 수 있느냐가 아니라 무엇을 치르게 하느냐에서 갈린다. 몇 달 뒤 끝날 프로젝트에 프레임워크 전환을 제안한 적이 있는데, 회수될 수 없는 비용이었다. 가족 몇 명이 쓰는 앱에 컨테이너 오케스트레이션을 올렸다가 이틀 만에 걷어낸 적도 있다. 관측 도구가 관측 대상보다 무거우면 안 된다는 것도 같은 말이다.

우회 구조의 원가는 개수로 센다. 하나를 피하려고 여러 개를 만들고 있으면 그건 우회가 아니라 다른 문제를 푸는 중이다. 선언 스무 개가 헤더 한 줄을 피하려고 치른 값이었다.

반례

가벼운 것이 항상 맞지는 않는다. 가벼운 해법은 값을 낮출 뿐 위험까지 없애 주지는 않는다. 중복을 한 곳으로 모으자 한 곳이 깨지면 전 페이지가 깨지는 성질이 새로 생겼다.

판별법

"이 해법이 회수되려면 몇 달이 필요하고, 이 문제는 몇 달 더 사는가?"

두 숫자를 나란히 놓는다. 두 번째를 모른다면 그것부터 묻는다. 대개는 내가 답할 수 없는 질문이다.