Skip to content
isdnetworks
Go back

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

(수정됨)

할인 계산이 틀리는 원인을 찾았다고 생각했는데 근거가 error.log 하나뿐이라 확인을 더 했다.

Table of contents

Open Table of contents

판단 기준 — 근거 하나의 한계

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

같은 결론을 다른 종류의 근거(deploy.log 의 시점, git log -p 의 코드 변경, git revert 재현)로 한 번 더 확인할 수 있는지가 판단 기준이 됐다. 한 종류의 근거만으로는 그 근거가 틀렸을 때 알 방법이 없다.

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

넷을 확인했고 넷이 같은 것을 가리켰을 때 단정했다. 재현은 의심 커밋을 git revert 로 되돌린 시험 환경에서 봤다.

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

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

안 맞는 근거의 값

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

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

조치 — 기록 형식과 확신도 표시

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

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

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

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

대안 — 재현이 안 될 때의 대체

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

부분적으로 되돌려 보는 것이 특히 도움이 됐다. 좁히는 데는 두 가지 방법이 있었는데 git 공식 문서의 git-bisect 페이지가 설명하는 대로 이분 탐색으로 문제를 넣은 커밋을 찾는 것과 의심 함수 하나만 이전 판으로 바꿔 배포하는 것이다. 뒤쪽을 골랐다. 이유는 커밋이 몇 개 안 돼 이분 탐색보다 함수 하나를 바꿔 보는 것이 빨라서다. 대신 그 판이 커밋 이력에 없는 손 편집으로 잠시 남는 것을 감수했다. 배포 전체를 되돌리기는 어려워도 한 함수는 되돌릴 수 있고, 그 범위가 좁을수록 원인 후보도 함께 좁아진다.

혼자 본 근거의 범위

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

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

정리


Share this post on:

Previous Post
15만 건을 막은 조건 하나
Next Post
데이터를 숨긴 짧은 조회 최적화