좋은 디버깅은 흔적이 남지 않는다

한 줄 요약

30분 만에 정확히 좁혀 고친 사람과 세 시간 헤매다 우연히 고친 사람의 커밋은 똑같이 생겼고, 그래서 기록을 남기지 않으면 실력도 조직의 자산도 쌓이지 않는다.

왜 이게 필요했나

디버깅이 경력에 비례해 늘지 않는 이유가 셋 있습니다.

첫째, 명시적으로 가르치는 곳이 거의 없습니다. 언어와 프레임워크는 배우지만 좁히는 절차는 어깨너머로 배웁니다.

둘째, 피드백이 잘못 걸려 있습니다. 증상이 사라지면 보상이 옵니다. 왜 사라졌는지 모르는 상태도 똑같이 보상받습니다. 그래서 운으로 고친 경험이 실력으로 오인됩니다.

셋째, 좋은 디버깅은 흔적이 안 남습니다. 조직이 이 능력을 알아보기 어렵고, 알아보지 못하면 육성되지도 않습니다.

여기에 대한 대응은 하나뿐입니다. 흔적을 남기는 것.

어떻게 동작하나

FDE 가 남겨야 하는 기록은 네 종류입니다.

재현 명령. 증상을 일으키는 최소 명령 한 줄. 이것이 있으면 수리 여부를 같은 잣대로 판정할 수 있고, 없으면 "고친 것 같다" 까지만 말할 수 있습니다.

배제 목록. 확인해서 지운 계층과 그 근거. 한 줄이면 충분합니다. auth — 401/403 이 로그에 한 건도 없음 처럼.

측정값의 전후. 수리 전 20회 중 5회 실패, 수리 후 20회 중 0회. 두 숫자가 같은 방법으로 측정됐다는 것이 중요합니다.

떠난 뒤에도 남는 문서. FDE 의 성공 조건은 특이합니다. 내가 없어도 굴러가야 성공입니다. 상주가 끝나는 날 시스템이 같이 멈춘다면 그것은 배포가 아니라 대여였던 셈입니다.

현장에서 만나는 모습

인수인계 문서에서 고객이 가장 자주 다시 여는 것은 아키텍처 그림이 아니라 장애 런북입니다. 자주 나는 증상별로 첫 30분에 무엇을 할지가 적힌 문서. 런북이 없는 시스템은 넘길 수 없는 시스템입니다.

그리고 문서를 넘기는 날에는 문서만 넘기지 말고, 고객 엔지니어가 런북대로 장애 시나리오 하나를 직접 처리해 보는 리허설까지 하는 것이 완결입니다. 읽고 이해한 것과 손이 움직이는 것은 다릅니다.

기록의 형식보다 중요한 것은 타이밍입니다. 인수인계 문서는 마지막 주가 아니라 프로젝트 중반부터 쌓아야 합니다. 마지막 주에 몰아 쓴 문서는 예외 없이 "무엇이 안 되는지" 가 빠져 있습니다. 그때쯤이면 본인이 이미 그 예외에 익숙해져서 특별하다고 느끼지 않기 때문입니다.

다음 실습에서 할 것

네 종류를 실제로 남깁니다. 그리고 마지막에 채점기가 다음 사람 역할을 합니다 — 여러분이 쓴 재현 명령을, 여러분의 셸이 아닌 깨끗한 환경에서 다시 돌립니다. 거기서 같은 숫자가 나와야 기록이 기록입니다.