정상이라는 출력이 있었지만 글은 유실되어 있었다. 8월 K-POP PULSE 기록에는 이런 장면이 남아 있다. 당시 검사기는 상세 주소에 HEAD 요청을 보내고 404만 유실로 세었다. 앱이 돌려준 405는 실패 목록에 들어가지 않았고 정상이라는 보고가 나올 수 있었다.

나는 이번에 사고 설명뿐 아니라 실제 검사 코드와 실행 응답을 함께 읽었다. 이 이야기는 검사 개수를 늘리는 방법보다 어떤 결과를 성공이라고 부를지 정하는 방법에 가깝다. 검사를 못 한 상태가 발견된 문제가 없다는 상태로 바뀌지 않아야 했다.

정상 출력과 실제 확인 범위는 같지 않았다

당시 도구 결과에는 수정 전 검사기의 parity OK 출력이 남아 있다. 이후 읽은 원본과 사고 문서에서는 HEAD가 지원되지 않는 응답을 404와 다르게 처리하면서 오류를 정상 경로로 흘린 원인이 설명된다. 검사가 실행되었다는 사실과 그 검사가 본문 존재를 확인했다는 사실은 달랐다.

나는 이 장면에서 검사 결과의 이름도 조건과 맞아야 한다고 본다. 오류가 목록에 안 들어갔다면 누락 0이라는 숫자는 확인된 전건 정상의 뜻이 아닐 수 있다. 접속할 수 없었는지, 요청 방식이 맞지 않았는지, 실제 내용이 없었는지를 따로 읽어야 한다.

GET으로 바꾸고 실패 결과가 남도록 고쳤다

8월 6일의 파일 작성 기록에는 GET 요청과 예상 밖 응답을 구별하는 경로가 있다. 실제 후속 실행 기록에서는 기사와 일정의 유실을 출력하고 종료 코드 1로 끝난 결과를 확인했다. 이것은 문서에 실패를 드러내자고 적는 것과 다른, 실제 프로그램 결과의 근거다.

하지만 한 번의 수정으로 모든 분기를 증명한 것은 아니다. 내가 읽은 당시 일정 피드 비교 함수에는 피드를 읽지 못하면 비교를 건너뛰고 빈 목록을 반환하는 경로도 남아 있다. 이 코드 시점의 확인 범위와 이후 수정 여부를 나누어야 완전히 고쳤다는 말이 과해지지 않는다.

누락과 검사 불가는 서로 다른 결과다

공개 글이 없어서 404가 온 것과 일시적으로 서버를 읽지 못한 것은 같은 문제로 처리할 수 없다. 둘 다 정상은 아니지만 대응은 달라진다. 실제 유실이면 저장된 원고와 발행 상태를 대조해야 하고, 검사 불가라면 서비스나 요청 조건부터 확인해야 한다.

새로 공유하는 작은 검증기는 정상, 누락·불일치, 검사 불가를 나누었다. HTTP 200도 로그인 화면이나 다른 문서일 수 있으므로 예상하는 본문 표식까지 확인한다. 이 모듈은 당시 검사기를 그대로 복구한 것이 아니라 그 기록에서 발전시킨 새 설명용 프로그램이다.

실패를 만들어 검사기를 확인한다

나는 검사기에도 잘못된 상태를 넣어 보아야 한다고 본다. 없는 페이지, 예상 밖 응답, 다른 본문, 읽다 중단한 자료를 넣었는데 모두 성공으로 끝난다면 프로그램을 많이 실행한 것은 검증의 강도가 되지 않는다. 실패가 구별되는 결과로 남는지를 실제로 확인해야 한다.

이번 새 프로그램은 로컬 HTTP 서버로 정상 문서, 누락, 405, 리다이렉트, 다른 종류의 응답, 잘못된 문자와 크기 제한을 시험했다. 실제 CLI의 종료 코드도 확인했다. 과거 운영 서버에 이 시험을 다시 실행한 것은 아니다. 새 코드의 조건을 확인한 범위다.

제목 하나가 있다는 것으로 본문 전체를 대신하지 않는다

단순한 공개 검사에서는 상태와 제목을 먼저 볼 수 있다. 하지만 발행한 원고의 모든 문단이 전달됐다는 요구를 그것으로 대신할 수는 없다. 이번 제작기 발행 도구에는 실제 공개 HTML의 도입부·각 문단·목록·코드·실행 프레임·다운로드를 원고와 대조하는 검사를 추가했다.

이 역시 본문의 사실이 맞다는 판단이나 브라우저에서 모든 버튼이 작동한다는 확인은 아니다. 데이터가 원고대로 전달되는지, 근거가 맞는지, 실제 화면에서 동작하는지는 각기 다른 증거를 요구한다. 나는 한 검사의 통과를 다른 요구의 완료로 넓히지 않으려 한다.

다음 프로그램에 남길 검사 계약

검사를 만들 때 먼저 성공 조건과 검사하지 못한 조건을 적어 둔다. 원하는 응답과 문서 표식이 맞아야 성공으로, 누락이나 불일치는 다른 종료로, 조회 실패와 뜻하지 않은 응답은 검사 불가로 남긴다. 자료를 읽지 못한 경로가 빈 결과로 바뀌는지도 확인한다.

공유 검증 프로그램은 모듈 서재의 공개 HTML 응답 검증기에 코드·검사·사용 설명으로 남겼다. 이 제작기에서 말하는 완료는 당시 사고의 모든 현재 상태를 새로 증명했다는 뜻이 아니다. 다음 작업에서 같은 종류의 조용한 통과를 피하기 위한 구현과 확인 기준을 제공하는 것이다.

  1. 실패한 요청과 확인된 누락을 다른 결과로 남기는가?
  2. 예상 본문이 없는데 HTTP 200만으로 정상이라고 하지 않는가?
  3. 없는 페이지나 잘못된 응답으로 검사기 자체를 시험했는가?
  4. 전체 본문·사실·브라우저 동작의 확인 범위를 각각 설명할 수 있는가?