속도 측정은 정상인데 영상회의가 멈추거나 인터넷이 잠깐 끊긴다면, 장애 중의 상태와 회복 시각을 남기는 것부터 시작합니다. 복구된 뒤 나온 빠른 속도가 끊겼던 순간까지 정상이라는 뜻은 아닙니다. 이 글을 따라 하면 지원팀이 같은 시간의 기록을 찾을 수 있는 장애 전달문을 만들 수 있습니다.
가정이나 작은 사무실에서 한 대 또는 여러 대가 간헐적으로 끊기는 상황을 다룹니다. 계속 느리다면 유선·Wi-Fi 속도 비교, Wi-Fi 연결 표시는 있지만 접속이 계속 안 된다면 Wi-Fi 연결 후 인터넷 불가 점검부터 확인합니다.
1. 정상일 때 비교할 기기와 작업을 정합니다.
문제가 생기는 기기를 A로 정하고 가능하면 같은 인터넷을 사용하는 다른 기기를 B로 둡니다. A와 B가 유선인지, 어느 Wi-Fi에 연결돼 있는지 적습니다. 휴대전화가 모바일 데이터로 전환됐거나 다른 인터넷을 쓰면 같은 회선의 비교 기기로 볼 수 없습니다.
두 기기에서 평소 열리는 웹페이지 하나와 문제가 생기는 앱을 확인해 둡니다. 웹페이지가 보였다는 것만으로는 캐시된 화면일 수 있으므로 새로 접속해 결과를 확인합니다. 앱의 정확한 오류 문구, 버전과 접속 방식을 적되 계정·회의 링크는 공개하지 않습니다.
| 장애 전 준비 | 내 기록 |
|---|---|
| A와 B의 연결 | A 유선/Wi-Fi ____, B 유선/Wi-Fi ____ |
| 비교할 작업 | 같은 웹페이지 ____, 문제가 생기는 앱 ____ |
| 시간 기준 | 날짜 ____, 시간대 ____, 기기 시계 차이 ____ |
| 주변 조건 | 충전/배터리 ____, 화면 잠금·절전 전후 ____, VPN 사용 ____ |
시계가 다르면 몇 초 차이인지 남깁니다. 화면을 잠근 직후나 절전 복귀 뒤에만 반복되는지도 관찰합니다. 시간상 함께 일어났다는 이유만으로 전원 절약 기능을 원인으로 확정하거나 설정을 일괄 해제하지 않습니다.
2. 끊긴 순간에는 세 가지를 먼저 남깁니다.
- 언제, 무엇이 멈췄는가. 처음 알아챈 시각과 앱의 증상을 적습니다. 정확한 시작을 못 봤으면
발견 시각이라고 표시합니다. - 어디까지 영향을 받았는가. 같은 기기의 다른 웹페이지, 다른 기기의 같은 작업을 확인합니다. 확인하지 못한 항목은
미확인으로 둡니다. - 어떤 상태로 돌아왔는가. 앱 재접속 시각과 웹페이지·연결 표시의 회복 시각을 따로 적습니다. 재부팅이나 케이블 변경을 했다면 그 시각도 남깁니다.
업무를 빨리 복구해야 하면 먼저 복구하고 수행한 조치를 기록합니다. 기록을 위해 장애를 유지할 필요는 없습니다. 다만 장비 재부팅 뒤 정상이라는 사실만으로 그 장비가 원인이었다고 확정하지 않습니다.
3. Windows에서는 연결 상태를 보조 자료로 확인합니다.
명령 사용이 익숙하지 않으면 연결 아이콘·앱 오류와 시각만 기록해도 됩니다. 명령을 실행하려면 시작 메뉴에서 Windows PowerShell을 검색해 엽니다. 아래 명령은 상태를 읽는 데 활용할 수 있습니다.
ipconfig
Get-NetAdapter | Select-Object Name, Status, LinkSpeedMicrosoft의 ipconfig 안내에 따르면 옵션 없는 명령은 어댑터의 IP 주소·서브넷·기본 게이트웨이를 표시합니다. Get-NetAdapter 안내는 네트워크 어댑터 속성을 조회하는 명령을 설명합니다. 실제 사용 중인 어댑터의 결과를 보고, 명령이 지원되지 않으면 오류를 기록하고 화면 관찰로 진행합니다.
Up이나 높은 LinkSpeed는 해당 어댑터의 연결 상태입니다. 인터넷 전체나 영상회의가 정상이라는 증거는 아닙니다. 두 명령은 연속으로 실행되므로 서로 정확히 같은 순간의 결과라고 적지 말고 실행 시각을 함께 남깁니다. 기록 단계에서 IP 해제·초기화 명령을 실행할 필요는 없습니다.
ping은 회선 합격 판정이 아닙니다.
평소 응답하던 기본 게이트웨이를 비교할 때만 짧게 확인할 수 있습니다. 아래 주소는 명령 형식을 위한 예시입니다. ipconfig에 표시된 실제 사용 어댑터의 기본 게이트웨이로 바꿉니다.
ping /n 4 192.168.0.1Microsoft ping 문서는 ICMP Echo 요청·응답을 확인한다고 설명합니다. Microsoft 통신 문제 해결 안내처럼 네트워크나 방화벽이 ICMP를 막을 수 있고, 대상 장비의 응답 정책·제한도 확인해야 합니다. ping 무응답만으로 인터넷 회선 장애라고 결론 내리지 않습니다. 평소부터 무응답인 대상은 이 비교의 정상 기준으로 사용할 수 없습니다.
담당자가 지정한 서비스의 TCP 포트를 따로 확인해야 할 때는 다음 형식을 사용할 수 있습니다. example.com과 443은 형식용 값이며 실제 점검 대상의 호스트명과 포트로 바꿉니다. 호스트명에는 https://나 URL 경로를 넣지 않습니다.
Test-NetConnection -ComputerName "example.com" -Port 443Microsoft Test-NetConnection 안내는 ping 시험과 TCP 연결 시험을 구분합니다. TcpTestSucceeded는 지정한 서버·포트의 연결 결과입니다. 성공해도 앱 로그인, 영상회의 미디어나 다른 서버까지 정상인 것은 아닙니다. 실패해도 서버·DNS·경로·정책 중 어느 원인인지는 추가 확인이 필요합니다. 짧은 끊김이 끝난 뒤 실행했다면 장애 중 증거로 쓰지 않습니다.
4. 채운 시간표와 반례를 함께 봅니다.
다음 시간과 관찰은 기록법을 설명하는 가상 예제이며 실제 측정이나 현장 사례가 아닙니다. A는 Wi-Fi 노트북, B는 같은 공유기의 유선 PC로 가정합니다. 두 기기 시계는 같은 시간 기준으로 확인했다고 둡니다.
| 시각 | A에서 관찰 | B·다른 작업 | 해석 |
|---|---|---|---|
| 10:14:50 | 영상회의와 비교 웹페이지 정상 | B 웹페이지 정상 | 장애 전 상태 확보. |
| 10:15:08 | 회의 음성 중단 발견, Wi-Fi 표시 유지 | 아직 확인 못 함 | 발견 시각 기록. 링크 유지가 앱 정상을 뜻하지 않음. |
| 10:15:15 | A의 비교 웹페이지 새 접속 성공 | B도 새 접속 성공 | 해당 시각에 전체 인터넷이 모두 끊겼다는 근거는 없음. |
| 10:15:45 | 회의 재접속 후 음성 복구 확인 | B에서는 증상 관찰 못 함 | 발견부터 복구 확인까지 37초. 실제 장애 시작·종료는 더 조사해야 함. |
이 기록이면 먼저 앱의 재접속 오류, 서비스 상태와 같은 회의의 다른 참여자 영향을 확인합니다. A의 VPN이나 해당 미디어 경로도 후보입니다. 다른 웹페이지가 열렸다고 모든 네트워크 원인을 배제하거나 앱 자체 고장으로 확정하지 않습니다.
반례도 함께 비교합니다.
- A의 Wi-Fi 연결이 사라지고 B의 유선 업무는 유지됐다면 A의 무선 경로·단말 상태를 먼저 확인합니다. A 단독 고장인지 AP 영향인지는 같은 무선의 다른 기기와 대조합니다.
- A·B의 서로 다른 서비스가 같은 시각에 실패했다면 공유하는 장비·회선·전원·DNS 등의 후보를 남깁니다. 통신사 장애로 바로 단정하지 말고 공유기 표시와 복구 시각을 전달합니다.
- 외부 서버의 ping만 무응답인데 실제 웹 작업은 된다면 ICMP 응답 제한을 확인합니다. 이를 인터넷 끊김 횟수로 합산하지 않습니다.
- 화면 잠금 또는 절전 복귀 직후 A만 반복된다면 그 조건과 어댑터 상태를 기록합니다. 제조사나 관리자의 해당 모델 지침을 확인한 뒤 변경 하나씩 재시험합니다.
5. 지원팀에 전달할 문장을 완성합니다.
날짜·시간대 ____,처음 발견 ____,복구 확인 ____. 문제가 생긴 작업·오류 문구는____. A는유선/Wi-Fi ____, B는같은 인터넷 여부와 연결 ____. 장애 중 다른 작업 결과____, 연결 표시·게이트웨이 확인____. 화면 잠금·전원 상태·직전 변경____. 수행한 복구 조치와 시각____. 확인 못 한 항목은____입니다. 이 시간대의 회선·장비·서비스 기록을 대조해 주세요.
한 번의 짧은 사건에서 모든 칸을 채울 필요는 없습니다. 다음 재발 때 같은 항목으로 한 줄 더 남기면 공통 조건을 비교할 수 있습니다. 속도 측정 결과만 여러 개 보내기보다 장애 중 확인한 사실과 확인하지 못한 사실을 구분한 시간표를 함께 전달합니다.