요카이는 제안서를 그대로 따라 하지 않게 했다

오래된 진단보다 현재 코드를 먼저 보게 했다. 제안과 다른 원인을 찾거나 수정하지 않기로 한 사례.

요카이에게 맡긴 것은 제안을 실제 작업으로 옮기는 일이었다. 그렇다고 받은 검토서를 순서대로 실행하게 하지는 않았다. 이미 구현돼 있는지, 지금 코드와 맞는지, 다른 기능과 충돌하지 않는지 먼저 확인하도록 했다.

제안과 다르게 처리하면 이유와 남은 위험도 피드백에 적었다. 적용했다는 표시뿐 아니라 왜 그렇게 했는지 남기려는 방식이었다.

오래된 진단과 지금 코드가 달랐다

6월 8일 사진 요청 실패 피드백에 구체적인 사례가 있다. 검토 문서는 과거 오류를 원인 후보로 봤지만, 적용 쪽에서 현재 코드를 확인하니 그 문제의 방어 처리는 이미 들어가 있었다.

당시 피드백이 찾은 원인은 프로젝트를 옮긴 뒤 남은 고정 경로였다. 생성 전 단계가 예전 위치를 가리켜 사진 생성까지 가지 못했다는 내용이다. 이 글에서 장애를 다시 재현한 것은 아니지만, 제안서를 그대로 따랐다면 엉뚱한 부분을 다시 고칠 수 있었던 사례다.

6월 7일에는 규칙이 없는 문제와 실행 중인 프로세스가 옛 코드를 쓰는 문제도 구분했다. 일부 제안은 기존 구현으로 충분하다고 보고 추가 수정하지 않았다. 파일을 바꿨더라도 돌아가는 프로그램이 그 파일을 쓰는지는 따로 확인해야 했다.

요카이에게 기대한 실행 역할에는 이런 판단도 포함됐다. 코드를 더 넣는 것보다 지금 필요한 변경인지 확인하는 일이다.

다음에도 작업을 맡길 때는 고칠 목록만 주기보다 어떤 경우에 수정하지 않아도 되는지 같이 적으려 한다. 오래된 설명을 최신 코드에 다시 적용하면 기능을 중복해서 만들 수도 있다. 제안과 다른 결론을 낸 이유 역시 남길 만한 결과였다.