만들면서 무엇이 어떻게 깨졌고 어떻게 알아냈는지의 기록이다. 기능 소개가 아니라 판단 기록이라 "이건 아직 안 쟀다" 도 그대로 적는다. 각 노트 끝의 근거 에서 커밋과 소스 줄을 확인할 수 있다.
Argus 는 Windows 상주형 성능 이상 탐지 프로그램이다(Python 3.11 · PyInstaller · PySide6). 아래 노트는 그것을 만들며 실제로 겪은 것들이다.
| 노트 | 한 줄 | |
|---|---|---|
| 01 | 자를 자로 쟀다 | 탐지 문턱을 정하려고 만든 시험 도형이 그 문턱을 품고 태어난 것이었다. 4점을 훑은 것이 한 점을 네 번 잰 것이었다 |
| 02 | 신호가 0인 실패 | 예외도 로그도 붉은 테스트도 없이 죽는 다섯 가지. 상주 프로그램은 죽었다는 사실조차 도달하지 않는다 |
| 03 | 트림된 값을 다섯 번 믿었다 | 워킹셋 트림 하나가 석 달 동안 다섯 개의 서로 다른 판정을 망가뜨렸다. 1회차에 이미 정체를 알았는데도 |
세 편은 따로 골랐는데 같은 자리를 가리킨다 — 틀린 것은 대개 기능이 아니라 재는 쪽이었다.
- 01 은 재는 도구가 답을 품고 있었던 경우다. 문턱을 정하려고 만든 도형이 그 문턱값을 만들도록 합성돼 있었다.
- 02 는 재는 경로가 아예 없었던 경우다. 실패는 계속 일어나고 있었고 그것을 나르는 채널만 없었다.
- 03 은 재는 지표가 다른 질문에 답하고 있었던 경우다. RSS 는 "얼마나 쓰는가"가 아니라 "OS 가 얼마나 내주고 있는가"를 잰다.
그리고 셋 다 성공처럼 보이는 결과를 한 번씩 통과했다 — 01 의 "미탐이 연속적이니 견고하다", 02 의 "테스트 531개 전부 초록", 03 의 "RSS 가 내려가니 누수 없음". 세 편에서 실제로 한 일은 그 결과를 한 번 더 본 것뿐이다.
후보를 캐는 단계에서 96건이 나왔고 위 셋은 그중 셋이다. 나머지와 왜 그것들을
고르지 않았는지는 CANDIDATES.md 에 있다 — 탈락 사유까지 남긴
것은 다음에 같은 후보를 다시 검토하지 않기 위해서다.
다음 순번으로 올려 둔 것 셋:
- 기다려서 풀릴 문제가 아니었다 — 착수 조건이
[대기]로 멈춘 네 번이 전부 데이터 부족이 아니었다 - 상한이 걸린 지표에 상대 문턱을 걸면 어떤 계수로도 도달 불가가 된다 — GPU 고온 룰이 90도 초과 표본 1,102개에서 발화 0건이던 것
- 사람에게 말하는 것 — 정직한 문장 옆에 반대되는 이름표를 붙이면 이름표가 이긴다