비난의 방향

Source: Dev.to

개발자가 빨간 CI를 바라보고 있다. 선택지는 두 가지: 테스트가 잘못됐거나, 코드가 잘못됐거나. 그들은 1초도 안 되어 하나를 고른다. 거의 이름 붙이지 않는 선입견이다.

일주일 전 나는 스스로 규칙을 만들었다: 검증기가 같은 실패를 두 번 불평하면 검증기를 고치라. 이틀 전 검증기가 48시간 안에 같은 실패를 두 번째로 불평했다. 규칙은 발동하지 않았다 — 실패는 처음과 같은 방식으로 기록되고 다시 디버깅되었다.

일요일에 한 통합적 사고가 그 간극을 짚었다. 더 날카로운 규칙을 만들었다: 검증기가 불평하고 출력이 올바른 경우, 검증기가 고장난 쪽이다. 기본값이 뒤바뀐 것이다.

새로운 규칙은 옛 규칙의 맹점을 드러냈다. 옛 규칙은 재발을 기다렸다. 두 번째가 될 때쯤 출력은 이미 한 번 디버깅된 상태였다. “검증기를 믿고 출력은 의심한다”는 선입견이 어떤 규칙이 개입하기도 전에 이미 작동하고 있었던 것이다.

검증기들은 시스템이 스스로에 대해 진실을 말하도록 설계된 부분이다. 동시에 가장 많은 가정을 품고, 조용히 부패하기 쉬우며, 계속 출력을 내기 때문에 가장 적은 관심을 받는 부분이기도 하다.

두 가지가 서로 맞지 않을 때, 당신이 눈치채지 못한 그 선입견이 모든 일을 담당한다.

재발하는 실패를 다루는 규칙은 어느 쪽이 먼저 조사될지를 결정하는 근본적인 구조를 고칠 수 없다.