야간 3시간 반 컷오버에서 30건을 검증하고 사후 수치는 못 잤다

저녁 여섯 시 반에 시작해 열 시에 끝났다. 계획한 시간 안이었고 리스크 16건 중 실제로 난 것은 없었다.
그런데 검증표 30건 중 넷은 재지 않았고 그중 하나는 운이 좋아서 통과했다.
보고서에는 그 둘을 그대로 적었다.

문제

인터넷을 끊는 작업은 실패가 바로 보인다.
다음 날 아침 직원 PC가 인터넷을 못 잡으면 그것으로 끝이다.
이런 작업의 성공 기준은 대개 하나로 줄어든다.
아침에 되는가.

그 기준 하나로 닫으면 두 가지가 사라진다.
바꾼 뒤가 바꾸기 전보다 나은지 말할 근거가 없어지고, 운으로 통과한 항목과 실력으로 통과한 항목이 구분되지 않는다.
둘 다 다음 작업에서 그대로 갚는다.
5년 전 관제센터에서 3년을 보내며 몸에 붙은 것은 이 구분을 작업 전에 미리 표로 만들어 두는 순서였다.
그날 밤 그 순서가 어디까지 작동했고 어디서 멎었는지가 이 글의 내용이다.

새벽에 쓴 체크리스트 두 장

작업 당일 새벽 한 시 반에 첫 문서를 닫았다.
새 라우터에 낮 동안 미리 넣어 둘 설정의 체크리스트였다.
메인 항목 42건과 고정 IP(인터넷 주소) 예약 11건이 들어갔고, 끝에는 절마다 몇 건 중 몇 건을 처리했는지 대조하는 칸을 두었다.
세 시 반에 두 번째 문서를 닫았다.
밤에 들고 다닐 인쇄용 수행 체크리스트였다.

두 번째 문서의 뼈대가 관제에서 가져온 것이다.
리스크 8건을 발생 확률과 영향과 대응 세 열로 적었고, 롤백 트리거를 조건과 임계 시간으로 박았다.
외부 접속이 안 되면 30분, Wi-Fi가 전부 안 잡히면 20분, 사무 PC가 주소를 못 받으면 15분.
그 시간 안에 못 고치면 구형 라우터를 다시 꽂는다.
롤백 절차 자체는 15분 SLA(작업 완료 기한)로 잡았다.
물리 교체 3분, 부팅 2분, 검증 5분, 설정 복원 5분.

당일 금지 항목
  당일 펌웨어 업데이트
  22:00 이후 신규 설정 시도
  사진을 찍지 않은 단계로 넘어가기
  UPnP(자동 포트 개방) 활성화

이 시점의 검증표는 20건이었다.
낮에 범위가 서버용 스위치와 서버 10대까지로 늘면서 확정 계획에서는 검증 30건, 리스크 16건이 됐다.
검증표를 먼저 쓰는 이유는 작업 중에 "이만하면 됐다"는 판단을 내 기분에 맡기지 않기 위해서다.
통과 기준이 종이에 있으면 못 잰 것도 종이에 남는다.

세 시간 반

저녁 여섯 시 반에 시작했다.
구형 라우터를 내리고 새 라우터를 올리는 사이 인터넷은 60분에서 90분 끊겼다.
포트포워딩 규칙은 구형 장비 백업에서 그대로 옮겨 추가도 삭제도 없이 1:1로 맞췄다.
Wi-Fi 이름과 비밀번호는 바꾸지 않았다.
사내 안내문은 이름이 바뀔 거라고 예고했지만 현장에서 유지로 바꿨다.
다음 날 아침 재연결 안내를 보낼 일이 없어졌고 직원 혼란은 0건이었다.

여덟 시 반부터 서버용 스위치를 올렸다.
관리 비밀번호를 기본값에서 바꾸고, 펌웨어는 손대지 않았고, 관리 모드는 독립형으로 단일화해 주소 배분이 두 곳에서 겹칠 여지를 없앴다.
당시 랙에 있던 맥 서버 10대에 케이블을 꽂고 양쪽 끝에 라벨을 붙이고 호스트네임과 고정 주소를 표대로 맞췄다.
이후 들어온 장비는 같은 절차로 랙에 붙였다.
열 시에 끝났다.
계획 SLA는 22:00에 15분 여유였고 그 안이었다.

계획과 달라진 것은 넷이다.

네 건 모두 현장 판단이고 장비나 시스템이 실패한 것은 없다.
그중 2번과 4번이 이 글의 나머지다.

검증표 30건의 집계

집계는 완료 보고서의 것이고 30건 전수를 개별 행으로 판정한 뒤 묶은 값이다.
통과 18건은 그 밤에 필요한 기능이 전부 살았다는 뜻이고, 나머지 12건은 이 작업이 스스로를 증명하지 못한 자리다.
둘을 한 표에 두는 것이 검증표의 값이다.
"기능 100% 동작"이라는 문장과 "30건 중 18건 통과"라는 문장은 같은 밤을 가리키지만 다음 작업에 넘겨주는 정보량이 다르다.

못 잰 것을 적었다

사후 측정을 못 잔 이유는 단순하다.
밤 아홉 시 반에 남은 것이 처리량 측정과 발열 측정과 30분 부하 시험이었고, 열 시가 종료선이었다.
기능이 다 살아 있는 것을 확인한 다음 측정은 "있으면 좋은 것"으로 밀렸다.
사전 준비 단계에서 잰 기준값도 일부만 있어서, 바꾼 뒤가 바꾸기 전보다 나은지를 숫자로 말할 수 없는 상태로 작업이 닫혔다.
보고서에는 이것을 정량 비교가 불가능한 한계로 적고, 다음 작업부터 측정 항목을 별도 체크리스트로 떼어 사전 다섯 건과 종료 30분 전 다섯 건을 의무로 두자는 권고를 붙였다.

두 번째는 운이다.
새 라우터에 구형 장비의 MAC 주소를 복제하지 않았다.
회선 사업자가 그 주소를 보고 같은 공인 주소를 내주는 구조라면 주소가 바뀌어 외부 접속 경로가 끊길 수 있는 결정이었다.
결과는 같은 주소가 다시 나왔고 외부 접속은 그대로 살았다.
보고서에는 이것을 행운 의존으로 분류했다.
사업자의 주소 배분이 장비 주소에 엄격히 묶여 있지 않았거나 이전 임대 기록이 짧은 시간 안에 재사용된 것으로 보이고, 어느 쪽이든 보장된 동작이 아니다.
다음 모뎀 재부팅이나 회선 점검에서 주소가 바뀌면 그때 끊긴다.
7일 안에 주소 복제나 DDNS(동적 주소 이름 연결) 둘 중 하나를 필수로 올렸다.

완료 선언 기준은 다섯 건이었다.
작업이 끝난 직후 내 감각은 다섯 건 전부 충족이었다.
검증표를 항목별로 다시 대조하면 전수 통과가 아니었고 사진과 측정 기록도 권고 미달이어서 셋만 남았다.
보고서에는 자체 판정 5/5와 엄격 판정 3/5를 나란히 적고 임원 보고는 3/5로 올렸다.
검증표가 없었으면 5/5로 닫혔을 밤이다.

결론

관제센터에서 남은 것은 순서다.
예외를 먼저 세고, 되돌릴 수 있는 방향으로만 손대고, 권한부터 확인한다.
그 순서가 5년 뒤 다른 회사의 야간 작업에서 리스크 16건 표와 15분 롤백 절차와 관리 비밀번호 확인으로 그대로 나왔다.

그런데 이 글에서 더 중요한 것은 그 순서가 만든 빈칸이다.
검증표를 먼저 쓰면 통과하지 못한 항목이 저절로 남는다.
운으로 통과한 항목도 표 위에서는 "재시도 필요"로 분류된다.
검증표는 성공을 증명하는 도구라기보다 실패를 적을 자리를 미리 만들어 두는 도구였다.
그날 밤 작업은 무사고였고 보고서에는 못 잰 것이 넷, 운에 기댄 것이 하나 적혔다.
그 다섯 줄이 다음 작업의 체크리스트를 한 절 늘렸고, 임원 보고에 올라간 판정은 자체 판정 5/5 대신 엄격 판정 3/5였다.

한계·재검토 트리거

2026-09 기준. 이 글의 수치는 작업 당일 밤과 다음 날 쓴 완료 보고서와 새벽 체크리스트 실물에서 왔고, 사후 성능 수치는 그 보고서에도 없다. 재검토 트리거는 둘이다. 10G 모듈 활성화 여부와 MAC 주소 복제 또는 DDNS 적용 여부는 이 글 시점 이후의 일이라 확인하지 않았고, 확인되면 "행운 의존" 항목의 결말을 여기 덧붙인다. 같은 절차를 다음 야간 작업에 썼을 때 사후 측정 다섯 건이 실제로 기록되는지가 이 글의 권고가 작동했는지를 가르는 기준이다.