하룻밤을 꼬박 샌 장애, 원인은 32초
세 시간을 파고도 원인은 못 찾았고, 대신 우회로로 살렸습니다
밤 아홉 시쯤 매일 쓰는 업무 도구가 실행되지 않았습니다. 아이콘을 눌러도 아무 일이 일어나지 않았습니다. 그날 밤에 벌어진 일을 순서대로 적으면 이렇습니다.
- 첫 번째 원인은 설치 파일이 통째로 빠진 손상된 빌드였습니다. 다시 설치해서 해결했습니다.
- 앱은 떴는데 연결 화면에서 멈췄습니다. 두 번째 원인은 앱이 아니라 이 PC에서 특정 시스템 명령 하나가 실행되는 데 32초가 걸린다는 사실이었습니다.
- 그 32초의 원인은 끝내 못 찾았습니다. 가설을 여덟 개쯤 세웠고 전부 빗나갔습니다.
- 결국 원인을 못 고친 채로 도구를 살렸습니다. 앱이 그 명령을 30초까지 기다리도록 되어 있었는데 이 PC는 32초가 걸려서, 간발의 차로 매번 실패하고 있었습니다.
저는 개발자가 아니라 여러 법인의 재무와 경영 실무를 보는 사람입니다. 이 기록을 남기는 이유는 도구 자랑을 하려는 게 아니라, 실무자가 업무 도구 장애를 만났을 때 어디까지 파고 어디서 방향을 틀어야 하는지가 이날 밤에 꽤 선명하게 드러났기 때문입니다.
첫 번째 문제: 실행 파일이 통째로 빠져 있었습니다
앱을 눌러도 반응이 없으니 먼저 로그를 봤습니다. 두 개의 로그가 서로 다른 이야기를 하고 있었습니다. 하나는 그날 낮 이후로 갱신이 끊겨 있었고, 다른 하나에는 저녁 사이 여러 번의 실행 시도가 찍혀 있는데 매번 같은 오류만 남기고 끝나 있었습니다.
즉 실행은 되고 있었습니다. 뜨자마자 죽었을 뿐입니다. 작업 관리자에 프로세스가 남아 있지 않은 것도 이걸 뒷받침했습니다.
명령창에서 직접 실행해보니 종료 코드와 함께 오류 문구가 그대로 나왔습니다. 프로그램이 실행에 필요한 데이터 파일 하나를 못 찾는다는 내용이었습니다. 설치 폴더를 열었습니다. 없었습니다. 같이 있어야 할 다른 필수 파일들도 여러 개 빠져 있었으니, 설치가 중간에 잘렸거나 어떤 이유로 손상된 상태였던 겁니다.
여기서 판단이 하나 있었습니다. 빠진 파일 하나만 다른 폴더에서 복사해 넣으면 당장은 뜰 수도 있고, 실제로 원본이 될 만한 파일이 다른 위치에 있었습니다. 그런데 빠진 게 하나가 아니라는 걸 확인한 뒤로는 그 방향을 접었습니다. 몇 개가 빠졌는지 정확히 모르는 상태에서 눈에 띄는 것만 채워 넣으면 나중에 또 다른 파일 때문에 같은 자리로 돌아옵니다. 전체 재설치로 갔습니다. 이 단계는 깔끔하게 끝났습니다.
앱이 떴습니다. 그런데 연결 중이라는 화면에서 더 나아가지 않았습니다.
두 번째 문제: 30초 타임아웃과 32초 실행 시간
연결 화면에서 멈추는 원인을 찾는 데 시간이 걸렸습니다. 엉뚱한 데를 짚기도 했습니다.
처음 의심한 건 외부 서비스 연동이었습니다. 회사 재무 자료를 조회하는 연동 하나가 인증이 풀려서 앱이 켜질 때마다 브라우저 인증 창을 띄우며 시작을 붙잡고 있었고, 며칠 전부터 크롬 창이 자꾸 뜨던 게 그것 때문이었다는 것도 이때 알았습니다. 인증을 다시 걸었습니다. 그 증상은 사라졌습니다. 그런데 연결 화면 문제는 그대로였습니다.
로그를 더 보니 진짜 원인이 나왔습니다. 앱이 백엔드 프로세스를 띄운 뒤 그 프로세스가 정말 살아 있는지 확인하려고 시스템 명령을 하나 호출하는데, 그 확인이 실패하면서 전체가 그 자리에 멈추고 있었습니다.
그래서 그 명령을 직접 실행해봤습니다. 32초가 걸렸습니다. 다시 해도 32초, 또 해도 32.4초였습니다. 소수점까지 일정했습니다.
소수점까지 일정한 지연은 성능 문제가 아닙니다. 어딘가에 걸린 고정 타임아웃을 매번 끝까지 기다리고 있다는 뜻입니다. 이 판단 하나가 이후 방향을 정했습니다.
원인 후보를 하나씩 지웠고, 전부 빗나갔습니다
여기서부터 세 시간이 들어갔습니다. 시도한 것과 결과를 적어둡니다. 전부 실패한 목록이라 오히려 참고가 될지도 모르겠습니다.
| 의심한 원인 | 확인 방법 | 결과 |
|---|---|---|
| 원격 접속으로 연결된 네트워크 드라이브 | 연결 구성 확인 | 무관 |
| 프로그램 서명의 온라인 인증서 확인 | 해당 확인 옵션 끄기 | 적용됐지만 그대로 32초 |
| 루트 인증서 자동 업데이트 | 정책값 변경 | 그대로 |
| 프록시 자동 감지 | 자동 감지 끄고 초기화 | 그대로 |
| 백신 실시간 검사 | 잠시 끄고 측정 후 복구 | 그대로 |
| 쌓여 있던 좀비 프로세스 | 전부 정리 후 재측정 | 그대로 |
| 내부 캐시 손상 | 캐시 삭제 후 재생성 | 그대로 |
| 꽉 찬 이벤트 로그 | 비우고 재측정 | 그대로 |
| 스크립트 검사 연동 | 우회 설정으로 테스트 후 복구 | 그대로 |
중간에 쓸 만한 측정이 몇 개 나오긴 했습니다.
지연되는 32초 동안 새로 나가는 네트워크 연결 시도가 하나도 없었습니다. 네트워크 문제가 아니라는 결정적인 증거였습니다. 다른 프로그램들의 실행 속도를 재봤더니 대부분 100밀리초 안쪽이었고 오직 이 명령 하나만 32초였는데, 도움말만 출력하게 하면 116밀리초에 끝나면서 실제 엔진을 시작할 때만 32초가 걸린다는 것까지 확인했습니다. 즉 프로그램이 뜨는 단계가 아니라 내부 초기화 단계에서 멈춥니다.
여기까지 좁혔는데도 마지막 한 칸을 못 갔습니다. 그 시점에 제가 받은 보고가 이랬습니다. 지금 원인을 못 찾고 있고, 지금까지 세운 가설이 전부 틀렸다는 내용이었습니다.
솔직히 이 보고가 이날 밤에 가장 쓸모 있었습니다. 못 찾고 있다는 말을 세 시간 만에 듣는 것과, 그 뒤로도 계속 “이번엔 될 것 같습니다”를 듣는 것은 완전히 다릅니다. 실무자는 원인을 못 찾았다는 정보를 근거로 다음 판단을 합니다.
방향을 틀었습니다: 고칠 수 없으면 비켜 갑니다
그래서 질문을 바꿨습니다. 이 32초를 없애는 게 아니라, 이 32초가 있어도 도구가 돌아가게 만들 방법이 있느냐로요.
앱이 그 확인 작업에 30초까지 기다리도록 되어 있었습니다. 이 PC는 32.4초가 걸립니다. 2.4초 차이였습니다. 기다리는 시간을 늘리면 그대로 통과합니다.
원인을 고친 게 아니니 근본 해결은 아닙니다. 그건 분명합니다. 다만 실무자 입장에서 이 선택은 명확했는데, 저는 이 PC의 시스템 내부를 연구하려던 게 아니라 다음날 아침에 이 도구로 일을 해야 하는 사람이었고 원인 규명은 언제 끝날지 모르는 작업인 반면 우회는 지금 확실하게 끝나는 작업이었기 때문입니다.
재부팅도 시도할 값어치가 있었습니다. 그 사이에 시스템 설정을 여러 개 바꿨고, 그중 일부는 재부팅해야 반영되는 종류였기 때문입니다. 성공 확률이 반반이라는 말도 함께 들었습니다. 정확한 표현이었다고 봅니다.
그날 밤 남긴 것
작업을 접기 전에 진단 기록을 파일 하나로 정리해 바탕화면에 저장했습니다. 재부팅하면 대화가 끊기니까, 다시 켠 뒤에 처음부터 다시 설명하지 않으려는 목적이었습니다.
내용은 이렇습니다. 지금까지 확인된 사실, 배제된 원인 목록, 남은 문제 하나, 그리고 최악의 경우 쓸 우회 방법. 다음날 몇 분이면 됐습니다.
이날 얻은 것 중에 가장 재사용성이 높은 습관이었습니다. 장애 대응은 어차피 중간에 끊기기 마련이고, 그 끊기는 지점에서 지금까지의 상태를 파일 하나로 떨어뜨려 두느냐 아니냐가 다음날 아침에 다시 붙는 시간을 통째로 결정합니다.
실무자 관점에서 정리한 다섯 가지
- 증상과 원인을 분리해서 셉니다. 이날 문제는 하나로 보였지만 실제로는 두 개였습니다. 설치 손상과 시스템 명령 지연입니다. 앞의 것을 고쳤다고 다 된 게 아니었습니다.
- 소수점까지 일정한 지연은 성능이 아니라 타임아웃입니다. 32.4초가 매번 반복되면 어딘가에서 30초를 기다리고 있는 겁니다. 이 감각 하나로 엉뚱한 방향을 여럿 걷어낼 수 있습니다.
- 비교군을 만듭니다. 이 명령만 느린지 전부 느린지 재보는 데 몇 분이면 됩니다. 다른 프로그램들이 전부 빠르다는 사실이 확인되면서 범위가 절반 이하로 줄었습니다.
- 못 찾고 있다는 보고를 받을 수 있어야 합니다. 계속 “이번엔 될 것 같습니다”만 돌아오면 실무자는 언제 방향을 틀어야 할지 판단할 수 없습니다. 저는 이후로 진단 작업을 시킬 때 “지금 확신도가 어느 정도인지”를 같이 답하라고 붙입니다.
- 우회로도 답입니다. 근본 원인을 못 찾은 채 우회하는 건 찜찜한 선택이지만 내일 아침에 일을 해야 하는 사람에게는 이게 옳을 때가 많고, 대신 우회했다는 사실 자체를 기록으로 남겨둬야 나중에 같은 자리가 다시 문제가 될 때 알아챌 수 있습니다.
한 가지 덧붙이면, 원인 규명에 들어간 세 시간이 통째로 낭비는 아니었습니다. 그 시간에 배제된 항목들이 기록으로 남아 있어서 나중에 비슷한 증상이 나왔을 때 같은 곳을 다시 파지 않아도 됩니다. 실패 목록도 자산입니다. 정리해두면요.
