근거 네 가지가 같은 것을 가리켰다

원인을 찾았다고 생각했는데 근거가 하나뿐이라 확인을 더 했다.

Table of contents

근거 하나의 한계

처음 가진 것은 그 시각 로그에 오류가 있다는 사실 하나였고 그것으로 원인을 정하려 했다. 그런데 로그에 오류가 있다는 것이 그것이 원인이라는 뜻은 아니다. 결과일 수도 있고 관련 없는 다른 일일 수도 있다.

같은 결론을 다른 종류의 근거로 한 번 더 확인할 수 있는지가 판단 기준이 됐다. 한 종류의 근거만으로는 그 근거가 틀렸을 때 알 방법이 없다.

네 종류의 근거와 각각의 성격

넷을 확인했고 넷이 같은 것을 가리켰을 때 단정했다.

로그   그 시각에 무슨 일이 있었다 (원인인지는 안 말한다)
시점   시간이 맞는다 (우연일 수 있다)
코드   그럴 만한 변경이 있다 (실제로 그런지는 안 말한다)
재현   되돌리면 안 난다 (가장 강하다)

넷의 성격이 다르다는 것이 요점이다. 앞의 셋은 정황이고 마지막 하나만 인과를 직접 건드린다. 되돌려서 안 나면 그것이 원인이므로 재현이 가장 강한 근거다. 다만 되돌리는 것이 위험하거나 어려운 경우가 있어서 그때는 나머지 셋으로 판단하되 확신도를 낮춰 잡았다.

안 맞는 근거의 값

한 번은 셋이 맞고 재현만 어긋났다. 로그와 시점과 코드가 전부 한 커밋을 가리키는데 그것을 되돌려도 문제가 그대로 났다.

다른 원인이 하나 더 있었고 셋만 보고 끝냈으면 그것을 못 찾았을 것이다. 근거가 전부 일치할 때보다 하나가 어긋날 때 알게 되는 것이 많다. 어긋나는 근거는 지금 그림에 안 들어가는 무언가가 있다는 신호다.

기록 형식과 확신도 표시

조사하면서 근거를 그때그때 적었고 확인하지 않은 것도 함께 적었다.

### 근거
1. 로그: 2026-04-28 14:02 부터 계산 오류 (417건)
2. 시점: 배포 2026-04-28 13:58. 4분 뒤부터
3. 코드: 해당 배포에 할인 계산 변경 있음 (커밋 8f2a1c3)
4. 재현: 시험 환경에서 그 커밋 되돌리면 안 남

### 확인 안 한 것
- 417건 전부가 같은 원인인지 (표본 20건 확인)

표본만 봤다는 것을 적어 두니 나중에 다른 원인이 섞여 있어도 놀라지 않았다. 확신도도 세 단계로 표시했다. 근거 네 종류가 일치하고 재현되면 높음이고, 셋이 맞고 재현을 못 하면 중간이며, 하나나 둘이면 짐작이다. 한 번 낮음으로 보고한 것이 실제로 아니었는데 그렇게 표시해 둔 덕분에 문제가 되지 않았다.

재현이 안 될 때의 대체

운영에서만 나고 재현이 안 되는 경우가 있었다. 그때는 어느 조건에서 나는지 조건을 좁혀 가거나 전체가 아니라 일부만 되돌려 보거나 로그를 더 남겨 관찰을 늘리는 것으로 대신했다.

부분적으로 되돌려 보는 것이 특히 도움이 됐다. 배포 전체를 되돌리기는 어려워도 한 함수는 되돌릴 수 있고, 그 범위가 좁을수록 원인 후보도 함께 좁아진다.

혼자 본 근거의 범위

혼자 넷을 확인하고 결론을 냈는데 남에게 보이니 다섯째가 나왔다. 그 시각에 다른 배포도 있지 않았느냐는 물음이었고 실제로 같은 날 다른 팀 배포가 있었다. 나는 우리 저장소만 보고 있었다.

전 저장소를 그 시간대로 조회하니 배포가 셋 있었다. 결과적으로 우리 것이 원인인 게 맞았지만 확인하지 않았으면 운이 좋았던 것이 된다. 혼자 모은 근거는 내가 아는 범위 안에서만 모이고 그 범위의 경계는 안에서 안 보인다.

정리

• 근거 하나로는 짐작이므로 다른 종류로 확인한다
• 로그와 시점과 코드와 재현은 각각 다른 것을 말한다
• 앞의 셋은 정황이고 재현만 인과를 직접 건드린다
• 안 맞는 근거가 있으면 그것이 가장 중요한 신호다
• 근거를 적으면서 하고 확인 안 한 것도 적는다
• 확신도를 표시해 짐작과 단정을 구분해 말한다
• 재현이 안 되면 조건 좁히기와 부분 되돌리기와 관찰 늘리기로 대신한다
• 혼자 모은 근거는 내가 아는 범위 안에서만 모인다