검수 모델이 위험한 경계를 지적하면 바로 수정해야 할 것처럼 느껴진다. 하지만 지적이 구체적이라는 것과 실제 코드에 그 결함이 있다는 것은 다르다. 북극성의 커널 시작 검수에는 이미 있던 취소 guard를 놓친 판단이 있었고, 제품을 더 고치기 전에 실제 지연 시험으로 근거를 보완했다.
초기 판단이 말한 실패 순서를 분해한다
문제의 순서는 커널 시작이 named pipe listen을 기다리는 동안 종료 요청이 들어오고, 나중에 listen이 끝난 뒤 controller가 새로 spawn되는 경쟁이었다. 초기 응답은 listen 뒤 취소 확인이 보이지 않는다는 이유로 E07 시작 경로를 보류했다. 다른 경로의 true와 설치 보류 판단도 같은 기록에 남았다.
이것은 실제로 발생 가능한 순서를 묻는 좋은 질문이지만 guard의 부재라는 전제는 코드에서 다시 확인해야 했다. 오류 코드 하나나 모델의 확신을 근거로 이미 검증한 부분을 다시 바꾸면 새 문제가 생길 수 있다. 먼저 await 앞뒤와 spawn 이전을 정확히 찾아 읽는 쪽을 택했다.
이미 있는 조건을 새로 넣었다고 기록하지 않는다
과거 보고서는 최초 검수와 같은 SHA 코드에 listen 직후 cancelled를 확인하고 server를 닫는 guard가 이미 있었다고 남긴다. 현재 해당 함수에서도 listen을 기다린 뒤 취소 상태를 검사하고 그 아래에서 child를 시작하는 순서를 읽을 수 있다. 현재 코드 읽기와 당시 동일 SHA 기록은 각각의 근거다.
모델이 틀렸다는 말만으로 끝내지도 않았다. 새 제품 패치 없이 그 경계를 더 직접 시험할 필요가 있었다. 이미 있는 조건을 다시 써 놓고 수정 한 건으로 세면 실제로 무엇이 나아졌는지 흐려진다. 이 사례에서 추가한 것은 제품 guard가 아니라 누락됐던 경계의 시험 근거였다.
실제 listen 완료를 지연해 종료를 끼워 넣었다
과거 소유 시험은 pipe가 연결된 시점에 listen callback 완료를 보류하고 커널이 아직 할당되지 않은 상태에서 shutdown을 요청한 뒤 callback을 풀었다. source와 packaged에서 늦은 controller spawn과 listening 잔류가 없는지 확인했다. 단순히 guard 문장이 존재한다는 정적 읽기보다 실제 경쟁 순서를 가깝게 만든 시험이다.
자료에는 셀이 실행되지 않았고 실제 프로세스 정리가 제한 시간 안에 확인됐다는 결과가 남아 있다. 다른 경로의 커널 비정상 종료와 새 커널 재사용도 별도 사례다. 하나의 true가 이 모든 경우를 자동 인증하지는 않는다. 어떤 순서를 만들고 어떤 부작용이 없었는지가 각각 기록돼 있어야 한다.
후속 응답도 원래 응답과 함께 남긴다
추가 근거를 보낸 뒤 후속 판단은 해당 경계와 로컬 설치 진행을 확인하는 쪽으로 바뀌었다. 초기 false와 후속 true를 모두 보존했다. 처음부터 모델이 한 번에 맞힌 것처럼 요약하지 않고 무엇을 더 읽고 시험했는지 남기는 것이 검수 기록의 가치다.
이 응답은 generated judgment이며 확률이나 검증된 정답률, 프로그램 전체의 무오류 인증이 아니다. 이번 집필에서는 저장된 요청·판단·보고서와 관련 코드 범위를 읽었고 모델에 새 검수를 보내지 않았다. 과거 도구의 완료 응답과 이번에 내가 수행한 자료 검토를 같은 실행으로 세지 않는다.
판단은 조사할 질문을 만들고 실행은 답을 좁힌다
모델의 지적은 놓친 경계를 찾는 재료가 될 수 있다. 반대로 실제 코드와 반례가 지적의 전제를 바꿀 수도 있다. 둘 중 한쪽을 최종 권위로 놓기보다 함수·실패 순서·시험 결과가 서로 맞는지 보는 작업이 필요했다. 제품 수정량이 적다는 이유로 검수가 덜 된 것도 아니다.
공유 구조 보고서 모듈은 이런 조사의 사건을 작은 필드로 설명하는 예제이며 판단이나 실제 수리를 대신하지 않는다. 나는 모델이 말한 오류를 바로 고쳤다는 속도보다 불필요한 수정을 피하고 확인된 경계만 정확히 남기는 쪽을 제작자의 기준으로 공개한다. 다음 사람이 같은 근거로 다른 결론도 검토할 수 있어야 한다.