네트워크 장애가 나면 무엇부터 확인하고 복구할까

장비 경보와 서비스 장애를 구분하되 대응을 늦추지 않는다 ↑

장비에 경보가 떴다면 실제 서비스에 어떤 영향을 주는지부터 확인합니다. 사용자가 필요한 서비스를 사용할 수 있는지, 품질이 합의한 범위를 벗어났는지, 고장을 버틸 여유가 사라졌는지를 함께 봅니다. 서로 다른 상태를 구별해야 영향과 긴급도를 정확히 전달할 수 있습니다.

D1이 고장 났지만 D2를 통해 업무가 유지된다면 현재 서비스 중단과 이중화 상실을 구분해 보고합니다. 업무가 된다고 해서 장비 수리를 미뤄도 되는 것은 아닙니다. 남은 한 경로의 추가 고장이나 과부하를 감당할 여유가 줄었으므로 위험에 맞춰 복구 기한을 정하고 남은 경로를 더 주의 깊게 살펴야 합니다.

반대로 모든 장비가 켜져 있어도 요청이 반복해서 실패하거나 지연이 허용 기준을 넘으면 서비스 장애가 될 수 있습니다. 링크가 연결돼 있어도 사용자의 업무는 실패할 수 있습니다. 어떤 사용자와 어떤 요청에서 문제가 발생했는지 실제 결과를 먼저 확보해야 합니다.

접수 시에는 시작 시각과 현재 시각, 영향을 받는 사용자·장소·서비스, 재현 조건, 최근 변경, 정상으로 보이는 비교 대상을 남깁니다. 원인이 밝혀지지 않았다면 미확인으로 기록합니다. 추정 원인을 확정 원인처럼 전파하면 다음 조사자도 그 원인만 찾다가 다른 단서를 놓칠 수 있습니다.

이중화가 사라진 상태에서는 다음 고장에 대한 보호 수준을 따로 알립니다. 현재 업무가 된다는 보고만 전달하면 긴급 정비의 필요가 낮게 보일 수 있습니다. 남은 경로와 여유, 복구 예상 시각, 추가 고장 시 영향을 함께 공유해 업무 담당자가 위험을 판단할 수 있게 합니다.

장애 등급을 정하는 동안에도 긴급한 피해 차단은 진행해야 합니다. 영향이 확산하거나 안전과 데이터 손실 위험이 크면 승인된 긴급 대응 절차를 먼저 적용하고 기록을 이어갑니다. 동시에 기술 조치 담당과 상황 공유 담당을 정해, 여러 사람이 서로 모르는 변경을 같은 장비에 넣는 일을 막습니다.

정상 단말과 장애 단말을 비교해 문제 구간을 좁힌다 ↑

장애 범위를 좁히려면 어떤 통신이 안 되고 어떤 통신은 계속 되는지를 함께 기록해야 합니다. 사무실 전체가 안 된다는 말은 출발점일 뿐입니다. 유선과 무선, 같은 VLAN과 다른 VLAN, 내부 서비스와 외부 서비스처럼 조건을 나누어 비교합니다.

PC-A만 통신이 안 되고 같은 포트 조건의 다른 단말은 정상이라면 단말과 접속 설정부터 살펴볼 이유가 생깁니다. 같은 Access 아래 여러 단말이 함께 실패하면 공유하는 링크나 정책을 의심할 수 있습니다. 다만 이 비교는 조사 범위를 줄이는 근거이지 특정 장비의 고장을 즉시 확정하는 증거는 아닙니다.

주소로 연결하는 시험과 이름으로 연결하는 시험도 조건을 맞춰야 합니다. HTTPS에서 주소만 바꾸면 서버 이름과 인증서, 가상 호스트 조건이 달라질 수 있습니다. 비교하려던 이름 해석 외에 요청 조건까지 달라졌다면 두 결과만으로 DNS 문제라고 판단할 수 없습니다.

관찰은 영향이 작은 방법부터 시작합니다. 기존 모니터링과 로그, 인터페이스 상태, 경로와 정책의 조회 결과를 먼저 비교합니다. 재부팅이나 광범위한 초기화는 증거와 정상 상태를 함께 없앨 수 있으므로 원인 확인 없이 첫 조치로 반복하지 않습니다.

로그와 캡처에는 수집한 시각과 위치를 기록합니다. A1에서 보였다는 패킷이 같은 시점의 D1에서도 보였는지, 어느 방향의 어떤 요청을 말하는지 구체화합니다. 정상 기준선과 비교 가능한 자료를 모은 뒤 가능성이 있는 원인을 하나 정하고, 그 원인이 맞는지 구별할 수 있는 시험부터 하면 불필요한 설정 변경을 줄일 수 있습니다.

PC-A의 실패와 PC-B의 정상을 같은 목적지까지 나란히 놓아 보겠습니다. 두 경로가 따로 지나는 접속 구간과 함께 지나는 구간을 나누면 무엇을 먼저 비교할지 정할 수 있습니다. 원인을 판단하려면 그림에서 찾은 구간의 장비 상태와 측정 결과를 함께 확인해야 합니다.

보안 침해가 진행 중이면 가용성보다 확산 차단을 우선한다 ↑

악성 행위나 침해 확산이 진행 중이면 서비스를 계속 운영하는 것보다 추가 피해를 막는 것이 우선입니다. 확인된 감염·침해 시스템과 구간을 즉시 격리하고, 침해 범위를 확실히 알 수 없거나 여러 구간으로 확산하고 있다면, 영향을 받는 망 전체를 다른 망과 차단하는 등 격리 범위를 넓혀야 합니다. 인터넷 연결만 끊고 내부 이동 경로를 남기면 충분하지 않을 수 있습니다. 생명·안전에 직접 연결된 설비는 사전에 정한 안전 절차와 대체 운영으로 전환하되, 서비스가 중요하다는 이유로 침해 경로를 계속 열어 두어서는 안 됩니다.

격리와 전원 차단은 같은 조치가 아닙니다. 사고 대응 지휘 체계에 따라 네트워크 연결을 차단하고, 로그·메모리 등 필요한 증거를 안전하게 확보합니다. 다만 증거를 수집하느라 긴급한 격리를 늦춰서는 안 됩니다. 침해된 통신 수단 대신 신뢰할 수 있는 별도 연락 경로를 사용합니다. 재연결 전에는 침해 원인과 침투 경로를 해결하고 남아 있는 위협을 제거해야 합니다. 복구본을 검증하고 필요한 계정·인증 정보 조치를 마친 뒤, 감시를 강화한 상태에서 단계적으로 다시 연결합니다. 접속이 다시 된다는 사실만으로 보안 사고가 끝났다고 판단하지 않습니다.

복구 순서는 중요도와 서비스 의존성을 함께 본다 ↑

복구 순서는 불편을 겪는 사용자 수만으로 정하지 않습니다. 먼저 추가 피해와 안전 위험을 막고, 관리자가 장비에 안전하게 접근해 작업할 수단을 확보합니다. 그다음 업무 중요도와 각 서비스가 먼저 필요로 하는 기능을 함께 살펴봅니다.

예를 들어 업무 애플리케이션이 인증과 이름 해석에 의존한다면 인증과 이름 해석이 먼저 정상적으로 되는지 확인해야 합니다. 애플리케이션만 반복해서 재시작해도 필요한 인증과 이름 해석이 동작하지 않으면 결과는 달라지지 않습니다. 반대로 이름 해석이 정상인데 경로 정책이 막힌 사례에서는 DNS를 먼저 바꾸는 조치가 문제를 해결하지 못합니다.

DHCP도 모든 장애의 첫 복구 대상은 아닙니다. 이미 유효한 주소를 가진 단말의 현재 통신과 신규 접속·임대 갱신은 영향 시점이 다를 수 있습니다. 지금 멈춘 업무에 DHCP의 어느 기능이 필요한지 확인하고, 앞으로 영향을 받을 범위와 시간을 함께 적어야 합니다.

같은 중요도의 서비스라면 적은 변경으로 더 넓은 필수 업무를 회복할 수 있는 조치를 우선 검토할 수 있습니다. 다만 임시 우회가 보안 경계를 없애거나 남은 경로를 과부하로 만들면 다른 피해가 생깁니다. 기대 효과뿐 아니라 새 위험, 중단 조건, 되돌릴 방법을 한 묶음으로 승인받아야 합니다.

복구 우선순위와 근본 원인 조사 순서가 언제나 같지는 않습니다. 신뢰할 수 있는 이전 설정으로 최소 복구가 가능하다면 서비스를 회복하면서 증거에 근거한 원인 분석을 이어갈 수 있습니다. 무엇을 복구했고 무엇이 아직 밝혀지지 않았는지 분리해서 알려야 임시 복구를 최종 해결로 오해하지 않습니다.

추가 피해를 막고 관리 접속을 확보한 뒤, 멈춘 업무에 필요한 기능을 따라 복구 순서를 정합니다. DNS나 DHCP가 실제로 필요한 단계인지도 이 과정에서 확인합니다.

통신이 안 되는 PC-A와 정상인 PC-B에서 같은 요청을 보내 본다 ↑

가상 사례에서 PC-A는 10.60.10.21/24, PC-B는 10.60.40.21/24이고 목적지는 App-S 10.60.20.10의 TCP 443 서비스입니다. 두 단말은 서로 다른 업무 VLAN에 있으며 같은 애플리케이션 요청을 사용합니다. 같은 요청을 보냈을 때 PC-A에서는 실패하고 PC-B에서는 성공한다는 점부터 기록합니다.

PC-B의 성공은 서버 전체가 꺼진 상황과는 맞지 않는 단서입니다. 그러나 서버가 PC-A의 주소만 거부하거나 중간 정책이 다르게 적용될 수도 있으므로 서버가 모든 조건에서 정상이라는 결론은 아닙니다. 같은 시각에 같은 요청을 보내는 조건을 유지하면서 양쪽 경로를 비교합니다.

PC-A의 게이트웨이 도달성과 목적지 경로를 확인하고, 허용된 관찰 지점에서 요청 패킷을 따라갑니다. 이 사례에서는 A1을 떠난 요청이 D1의 입력에서 관찰되지만 서버 방향 출력에서는 관찰되지 않습니다. 그러면 D1의 입력과 출력 사이에서 경로와 정책을 더 살펴볼 수 있습니다. 다만 캡처에서 패킷을 놓쳤을 가능성도 함께 확인해야 합니다.

D1의 최근 변경과 정책 순서를 비교하니 VLAN10의 해당 요청에 잘못 적용된 ACL 거부 규칙이 발견되었다고 하겠습니다. 같은 요청을 재현할 때 해당 규칙의 카운터가 증가하는 점과 정상 기준 설정의 차이를 함께 확인합니다. 카운터 하나만 보고 결론을 내리지 않고, 경로·패킷 캡처·정책 기록이 모두 같은 문제를 가리키는지 대조합니다.

차단되어야 할 게스트 시험은 승인된 시험 단말과 목적지로 제한합니다. 관련 없는 주소나 서비스를 광범위하게 탐색하는 방식으로 정책을 확인하지 않습니다. 원래 허용하거나 차단하기로 한 통신을 승인된 범위에서 시험합니다. 장애가 났다는 이유로 점검 대상이나 권한을 임의로 넓혀서는 안 됩니다.

조치는 전체 ACL을 제거하는 것이 아니라 승인된 원래 정책으로 잘못된 규칙과 순서를 복원하는 범위로 제한합니다. 복원 뒤 PC-A의 요청과 응답, PC-B의 기존 정상 통신, 계속 차단되어야 하는 게스트 통신을 함께 확인합니다. 허용되어야 할 통신만 돌아왔는지까지 확인해야 업무를 복구하면서 기존 차단 정책도 유지했는지 알 수 있습니다.

PC-A와 PC-B의 같은 요청을 D1의 입력과 출력에서 비교합니다. PC-A의 요청이 어디에서 막히는지 찾은 뒤, 잘못된 ACL만 복원하고 기존 허용·차단 통신을 다시 시험합니다.

가설 하나에 최소 변경 하나를 적용하고 결과를 남긴다 ↑

조치 전에는 관찰한 사실, 현재 가설, 변경 범위, 기대 결과를 짧게라도 적습니다. 로그나 캡처의 어떤 단서 때문에 그 설정을 바꾸려는지 적는 것입니다. 여러 설정을 한 번에 바꾸면 통신이 돌아와도 무엇이 원인이었고 무엇이 불필요한 변경이었는지 구분하기 어려워집니다.

기존 설정과 필요한 상태를 확보하고, 변경 권한과 되돌릴 담당자를 확인합니다. 긴급 상황에서도 어느 시점에 무엇을 바꿨는지 기록은 이어가야 합니다. 다른 담당자의 동시 변경을 통제하지 않으면 정상과 실패의 비교 조건이 조치 중에 다시 바뀔 수 있습니다.

이 사례에서는 확인된 ACL 차이 하나를 정상 기준으로 되돌린 뒤 같은 요청으로 결과를 비교합니다. 예상한 위치에서 요청이 통과하고 응답이 돌아오는지 확인하며, 오류와 부하도 관찰합니다. 예상한 결과가 나오지 않으면 다른 설정부터 더 바꾸지 말고, 추정한 원인이 맞는지와 이전 상태로 되돌릴 조건을 다시 확인합니다.

임시 우회를 선택했다면 남은 용량과 보안 제한, 적용 기한을 기록합니다. 우회 경로가 평상시 전체 수요를 계속 감당할 수 있는지 별도 판단이 필요합니다. 임시 상태를 잊고 정상 구성처럼 운영하지 않도록 원복 또는 정식 변경의 담당자와 종료 조건을 정해야 합니다.

보안 침해와 관련된 복구에서는 이전 설정이라는 이유만으로 안전하다고 간주하지 않습니다. 침해 이전의 신뢰할 수 있는 기준과 복구본인지 확인하고, 필요한 원인 제거와 계정·인증 정보에 대한 조치를 거쳐야 합니다. 단순한 통신 장애의 설정 롤백과 침해 시스템의 재연결은 같은 승인 기준으로 처리할 수 없습니다.

패킷 복구·업무 복구·사고 종결을 구분한다 ↑

복구 확인은 ping 응답 한 번으로 끝나지 않습니다. 패킷이 왕복하는 상태, 사용자가 업무를 완료하는 상태, 원인과 재발 방지까지 처리한 상태를 구분해야 합니다. 각 단계의 담당자와 확인 근거를 따로 남기면 현재 무엇이 회복되었는지 정확히 전달할 수 있습니다.

네트워크 복구에서는 기대한 양방향 경로와 정책, 오류와 잔여 부하를 확인합니다. 업무 복구에서는 영향을 받았던 사용자와 위치에서 실제 요청을 확인합니다. 시험 단말에서 통신이 되더라도 다른 VLAN과 무선 구간, 신규 접속은 별도로 확인합니다.

기존 세션과 신규 세션, 필요한 이름 해석과 인증도 서비스 조건에 맞춰 확인합니다. 복구 직후 정상이어도 부하가 쌓이거나 임대 갱신, 경로 복귀 시점에 다시 문제가 나타날 수 있습니다. 얼마나 오래 지켜보고 어떤 시점에 다시 확인할지는 해당 장애의 영향과 서비스 특성에 따라 정합니다.

사고를 마칠 때는 시각별 상황과 조치, 영향 범위, 직접 원인과 피해를 키운 조건, 남은 위험을 기록합니다. 원인을 아직 찾지 못했다면 후속 조사 담당자와 확인할 항목을 남깁니다. 담당자의 잘못을 지적하는 데 그치지 않고 같은 문제가 되풀이되지 않도록 바꿀 설정과 절차, 다시 시험할 내용을 정해야 합니다.

업무 담당자의 확인과 기술 담당자의 관찰이 다르면 그 차이를 조사합니다. 시험 요청은 성공해도 특정 사용자 권한이나 저장 기능이 실패할 수 있습니다. 확인한 기능과 확인하지 못한 기능을 구분해 남겨야 일부 성공을 전체 복구로 전달하는 일을 막을 수 있습니다.

이번에 확인한 경로와 정책, 장애 범위는 설계 문서와 정상 상태의 기준 기록에 반영합니다. 빠졌던 시험도 검증 목록에 추가합니다. 네트워크 보안의 배치에서 살펴본 접근 통제와 탐지 기능이 실제로 제 역할을 했는지 되짚어 보고, 다음 사고에 대비해 격리 지점과 복구 절차를 보완합니다. 이어지는 맺음 글에서는 한 번의 웹 접속을 다시 따라가며 통신 원리와 설계·운영을 함께 정리합니다.

패킷이 다시 흐르는 상태, 사용자 업무가 되는 상태, 원인과 재발 방지까지 처리한 상태를 구분했습니다. 각 단계에서 확인한 내용과 아직 남은 일을 나란히 봅니다.