'장비가 안 됩니다'를 기술적 장애로 구체화하는 방법

'장비가 안 됩니다'를 기술적 장애로 구체화하는 방법#

1장 “장비가 안 됩니다”는 장애 원인이 아니다#

1.1 같은 말 안에 전혀 다른 문제가 숨어 있다#

현장 담당자에게 다음과 같은 연락을 받았다고 가정해보겠습니다.

장비가 안 됩니다.

사용자 입장에서는 충분한 설명처럼 들릴 수 있습니다.

하지만 기술적으로는 거의 아무것도 확정할 수 없습니다.

실제로는 다음처럼 전혀 다른 상황일 수 있습니다.

전원이 들어오지 않는다.

전원은 들어오지만 부팅되지 않는다.

화면은 정상인데 입력을 받지 않는다.

장비는 동작하지만 Network에서 접근되지 않는다.

Network 연결은 되지만 Server에 접속하지 못한다.

Server까지 요청은 전달되지만 오류 응답이 돌아온다.

Application은 정상인데 실제 Motor나 Relay가 동작하지 않는다.

물리 장비는 동작했는데 관리 화면에는 실패로 표시된다.

특정 시간대에만 간헐적으로 실패한다.

모두 사용자의 표현으로는:

안 된다.

가 될 수 있습니다.

따라서 장애 대응의 첫 작업은 장비를 재부팅하거나 Cable을 뽑는 것이 아닙니다.

모호한 증상을 관찰 가능한 기술적 문장으로 바꾸는 것부터 시작해야 합니다.

2장 좋은 장애 설명은 무엇이 다른가#

2.1 나쁜 장애 설명#

1번 장비가 이상합니다.

여기에는 분석할 수 있는 정보가 거의 없습니다.

2.2 조금 나아진 장애 설명#

1번 장비가 오늘 아침부터 Server와 통신되지 않습니다.

장비와 시간, 증상의 범위가 조금 보입니다.

2.3 분석 가능한 장애 설명#

2026-09-24 08:42부터
DEVICE-01에서 Sensor 입력은 정상적으로 감지되지만
처리 결과가 중앙 Server에 등록되지 않는다.

동일 Network의 DEVICE-02는 정상이며
DEVICE-01에서 Server IP까지 Ping은 정상이다.

이 문장에는 다음 정보가 들어 있습니다.

언제
→ 2026-09-24 08:42부터

무엇이
→ DEVICE-01

어디까지 정상인가
→ Sensor 입력

어디부터 실패하는가
→ Server 등록

비교 대상은 있는가
→ DEVICE-02 정상

Network 기본 연결은 어떤가
→ Ping 정상

이 정도만 확보해도 장애 범위가 크게 줄어듭니다.

3장 장애를 한 문장으로 정의하는 방법#

3.1 기본 형식#

현장에서는 다음 형식을 사용할 수 있습니다.

[언제]
[어떤 장비 또는 서비스에서]
[어떤 입력을 수행했을 때]
[어디까지 정상이고]
[어떤 결과가 기대값과 달라지는가]

예:

09:20부터 KIOSK-03에서
카드 인증을 수행하면
카드 판독까지는 정상이나
Server 인증 API가 Timeout되어
결제가 진행되지 않는다.

또는:

14:35부터 SENSOR-GW-02에서
Sensor Data는 Local Log에 기록되지만
MQTT Broker로 Publish되지 않는다.

이런 표현이 좋은 이유는 장애 분석의 시작점과 끝점을 명확하게 만들어주기 때문입니다.

4장 하나의 동작은 여러 단계를 거친다#

4.1 사용자는 최종 결과만 본다#

사용자가 버튼을 눌렀다고 가정해보겠습니다.

사용자에게 보이는 것은:

버튼 클릭
↓
장비 동작

정도입니다.

그러나 실제 시스템에서는 다음과 같은 과정을 거칠 수 있습니다.

사용자 입력
↓
UI Event
↓
Application Logic
↓
API 호출
↓
Network
↓
Server
↓
Database 조회
↓
업무 판단
↓
응답
↓
Controller 명령
↓
Relay 출력
↓
Physical Device
↓
Sensor 확인
↓
상태 저장
↓
화면 갱신

어느 한 지점이라도 실패하면 최종 사용자는:

안 됩니다.

라고 말합니다.

4.2 장애 분석은 처음 실패한 경계를 찾는 작업이다#

정상적인 처리 흐름이:

입력
↓
전송
↓
처리
↓
명령
↓
물리 동작
↓
상태 확인
↓
기록

이라고 하겠습니다.

확인 결과:

입력        정상
전송        정상
처리        정상
명령 생성   정상
명령 수신   정상
물리 동작   실패

라면 Server Network를 계속 분석할 이유가 줄어듭니다.

반대로:

입력        정상
전송        실패

라면 Physical Device보다 Network나 Protocol을 먼저 보는 편이 합리적입니다.

핵심 질문은 항상 같습니다.

마지막으로 정상 확인된 지점은 어디이며, 처음 비정상이 확인된 지점은 어디인가?

5장 장애를 구성하는 다섯 가지 기본 정보#

장애 신고를 받으면 최소한 다음 다섯 가지를 확보하는 것이 좋습니다.

5.1 대상#

어떤 장비인가?

어떤 Server인가?

어떤 Service인가?

어떤 Interface인가?

가능하면 단순한 장비 이름보다 식별 가능한 값을 사용합니다.

예:

DEVICE-01

CAM-B2-04

SW-F3-02

API-SERVER-01

5.2 발생 시각#

언제 처음 발생했는가?

마지막 정상 시각은 언제인가?

현재도 지속되는가?

간헐적인가?

이 정보는 Log를 찾을 때 매우 중요합니다.

5.3 입력#

문제를 발생시킨 조건입니다.

예:

버튼 클릭

카드 입력

Sensor Trigger

API 호출

File Upload

Device Boot

특정 User Login

예약 작업 실행

5.4 기대 결과#

예:

Relay가 ON 되어야 함

HTTP 200이 반환되어야 함

Database에 Record가 저장되어야 함

파일이 생성되어야 함

장비 상태가 ONLINE으로 바뀌어야 함

5.5 실제 결과#

예:

아무 반응 없음

HTTP 500

Connection Timeout

상태는 OFFLINE

Data는 저장됐지만 화면 갱신 안 됨

이 다섯 가지가 있어야 장애를 객관적으로 이야기할 수 있습니다.

6장 영향 범위를 먼저 파악하자#

6.1 한 대만 문제인가#

예:

DEVICE-01 X

DEVICE-02 O

DEVICE-03 O

라면 개별 장비의:

전원

Cable

Port

설정

Firmware

등을 우선 의심할 수 있습니다.

6.2 같은 구역 전체가 문제인가#

예:

1층 장비 정상

2층 장비 전체 장애

3층 장비 정상

이라면:

2층 Switch

Uplink

VLAN

전원

중간 Gateway

등 공통 요소가 중요해집니다.

6.3 모든 장비가 동시에 문제인가#

예:

DEVICE-01 X
DEVICE-02 X
DEVICE-03 X
DEVICE-04 X

공통 Server나 Network Infrastructure를 우선 확인할 가치가 있습니다.

중앙 Server

Database

Firewall

Core Switch

DNS

Authentication Service

처럼 여러 장비가 공유하는 구성요소를 찾습니다.

7장 영향 범위는 장비 개수만 의미하지 않는다#

다음 네 가지 관점으로 보는 것이 좋습니다.

장비 범위
→ 몇 대인가?

지역 범위
→ 어느 건물·층·구역인가?

기능 범위
→ 어떤 기능만 실패하는가?

사용자 범위
→ 특정 사용자 또는 전체 사용자인가?

예를 들어:

모든 장비가 고장난 것은 아니고
모든 장비에서 Login만 실패한다.

라면 장비보다 인증 Server를 먼저 확인할 수 있습니다.

8장 재현이 가능한 장애와 불가능한 장애#

8.1 재현 가능한 장애#

예:

버튼을 누르면 항상 Timeout

특정 파일을 올리면 항상 Error

DEVICE-01에서만 항상 접속 실패

재현 가능한 문제는 비교적 분석하기 쉽습니다.

같은 입력을 넣고 각 단계의 변화를 관찰할 수 있기 때문입니다.

8.2 간헐 장애#

더 어려운 것은 다음과 같은 문제입니다.

하루에 두세 번 발생

비가 오면 발생

야간에만 발생

부하가 높을 때 발생

재부팅 후 며칠 지나면 발생

이 경우 억지로 장애를 재현하려 하기보다 발생 당시의 증거를 자동으로 남기는 것이 더 중요할 수 있습니다.

예:

Log

Metric

Event History

Packet Capture

Error Counter

System Resource

Environmental Data

등입니다.

9장 장애 재현은 단순히 같은 오류를 다시 보는 것이 아니다#

좋은 재현은 다음 관계를 고정합니다.

입력
↓
조건
↓
처리
↓
출력

예를 들어 API 장애라면:

입력
POST /api/device

조건
DEVICE-01 Token

기대 결과
HTTP 200

실제 결과
HTTP 500

처럼 만듭니다.

이렇게 해야 다른 사람이 같은 조건으로 테스트해도 동일한 결과를 확인할 수 있습니다.

10장 재현 조건을 하나씩 고정하자#

다음 조건을 기록할 수 있습니다.

장비 ID

Firmware Version

Server Version

User Account

입력값

시간대

Network 위치

VLAN

Protocol

Request ID

조건을 고정하지 않고 여러 변수를 동시에 바꾸면 장애 원인을 찾기 어려워집니다.

11장 한 번에 하나의 조건만 바꾸는 것이 좋다#

예를 들어 통신 장애가 있다고 해서 동시에:

Cable 교체

Switch Port 변경

IP 변경

Firmware Update

Server Restart

를 모두 수행하면 문제가 해결되더라도 원인을 알 수 없습니다.

가능하다면:

현재 상태 기록
↓
한 가지 변경
↓
결과 확인
↓
기록
↓
다음 변경

방식으로 진행합니다.

이를 통해 원인과 결과 관계를 더 명확하게 판단할 수 있습니다.

12장 장애 발생 전후의 변경 이력을 확인한다#

장애가 갑자기 생겼다면 다음 질문이 중요합니다.

문제가 발생하기 직전에 무엇이 바뀌었는가?

확인 대상:

Firmware Update

OS Update

Application 배포

Firewall Rule 변경

VLAN 변경

IP 변경

Certificate 교체

Password 변경

DB Migration

Network 공사

전원 공사

장비 교체

입니다.

12.1 변경과 장애 발생 시간이 가깝다면 중요한 단서다#

예:

02:00 DB Backup 정책 변경

02:15 Server 응답시간 증가

02:20 API Timeout 발생

이라면 관련성을 확인해야 합니다.

다만:

변경이 있었다
=
그것이 반드시 원인

이라고 단정해서도 안 됩니다.

변경 전후의 증거를 비교해야 합니다.

13장 로그는 한 곳만 보면 안 된다#

하나의 요청이 여러 시스템을 통과한다면 각 지점에 흔적이 남을 수 있습니다.

예:

Client Log
↓
Network Device Log
↓
Firewall Log
↓
Server Access Log
↓
Application Log
↓
Database Log

각각 다른 사실을 보여줍니다.

13.1 Client Log#

확인할 수 있는 내용:

요청 시작

Destination

Timeout

Error Code

Retry

13.2 Network Log#

예:

Link Up / Down

Port Error

MAC 이동

VLAN

Packet Drop

13.3 Server Log#

예:

Request 수신

Processing Time

HTTP Status

Authentication

Exception

13.4 Database Log#

예:

Connection Timeout

Slow Query

Lock

Storage Error

이런 로그를 같은 사건의 시간축에서 연결해야 합니다.

14장 로그 시간부터 맞아야 한다#

예를 들어 Client에서는:

10:31:05
Request Failed

Server에서는:

10:28:14
Database Timeout

으로 나타난다고 가정해보겠습니다.

두 시스템의 시간이 3분 가까이 다르다면 같은 사건인지 판단하기 어렵습니다.

그래서 장애 분석 전에:

현재 시간

Timezone

NTP 동기 상태

Clock Drift

를 확인하는 것이 중요합니다.

14.1 Timestamp 정합성이 중요한 이유#

하나의 Event가 다음처럼 기록될 수 있습니다.

10:30:00.120 Client Request

10:30:00.128 Firewall Allow

10:30:00.135 Server Receive

10:30:02.150 DB Timeout

10:30:02.152 HTTP 500

10:30:02.160 Client Error

이렇게 시간이 맞으면 하나의 사건을 연결하기 쉽습니다.

15장 Request ID와 Correlation ID를 활용하자#

분산 시스템에서는 시간만으로 같은 요청을 찾기 어려울 수 있습니다.

Application에서 다음과 같은 ID를 사용할 수 있습니다.

Request ID
REQ-9F73A2

각 시스템이 동일한 ID를 기록하면:

Client
REQ-9F73A2

API Gateway
REQ-9F73A2

Application
REQ-9F73A2

Database 작업
REQ-9F73A2

처럼 하나의 요청을 추적하기 쉬워집니다.

가능하다면 로그 설계 단계부터 Correlation ID를 고려하는 것이 좋습니다.

16장 “어디까지 정상인가”를 먼저 찾는다#

다음과 같은 Device 동작을 생각해보겠습니다.

Sensor
↓
Controller
↓
Network
↓
Server
↓
Database

무조건 처음부터 모든 것을 확인할 필요는 없습니다.

예를 들어:

Controller Log
Server 전송 성공

Server Access Log
Request 수신

Application Log
DB Timeout

이라면 이미:

Sensor
Controller
Network
Server 수신

까지는 어느 정도 정상이라는 증거가 있습니다.

문제는 Database 영역으로 좁혀집니다.

17장 반으로 나누어 장애 영역을 줄여라#

전체 경로가:

Device
↓
Switch
↓
Router
↓
Firewall
↓
Server
↓
Database

라고 하겠습니다.

Server까지 Packet이 도착하는지 확인합니다.

도착한다면#

Device ~ Server Network

보다:

Server Application ~ Database

를 우선 확인합니다.

도착하지 않는다면#

Network 쪽을 다시 나눕니다.

Device → Switch

Switch → Firewall

Firewall → Server

이런 방식으로 범위를 계속 줄일 수 있습니다.

18장 장애 원인을 계층으로 나눠보자#

18.1 전원#

전원 공급

전압 강하

PoE

Adapter

UPS

재부팅

18.2 물리 연결#

Cable

Connector

Fiber

Port

Link

18.3 Layer 2#

VLAN

MAC Address

Switch Port

STP

18.4 Layer 3#

IP

Subnet Mask

Gateway

ARP / NDP

Routing

18.5 Transport#

TCP

UDP

Port

Connection

Timeout

18.6 Application#

HTTP

API

Authentication

MQTT

Protocol Parsing

18.7 Data#

Database

Cache

File System

Storage

18.8 Physical Action#

Relay

Motor

Actuator

Sensor Feedback

“장비가 안 된다”는 현상을 이런 층으로 나누면 원인을 찾기가 훨씬 쉬워집니다.

19장 Ping만으로 Network 정상 여부를 판단하지 않는다#

Ping이 성공했다고 하겠습니다.

PING
Reply

확인할 수 있는 것은 제한적입니다.

예를 들어:

ICMP는 정상

TCP 443은 차단

Application은 장애

일 수도 있습니다.

따라서:

Ping 성공
=
서비스 정상

은 아닙니다.

19.1 서비스 Port까지 확인한다#

필요에 따라:

IP 연결성
↓
TCP / UDP
↓
Port
↓
Application

순서로 확인합니다.

예를 들어 HTTPS Service라면:

TCP 443 연결 가능?
↓
TLS 정상?
↓
HTTP 응답?
↓
Application 정상?

까지 구분합니다.

20장 HTTP Status Code도 중요한 증거다#

API 기반 시스템에서 다음 결과는 의미가 다릅니다.

401 Unauthorized

403 Forbidden

404 Not Found

500 Internal Server Error

503 Service Unavailable

예를 들어:

HTTP 401

이 돌아왔다면 Network Packet은 Server까지 도달했고 Application도 어느 정도 요청을 처리했다는 강력한 단서입니다.

이런 상황에서 Cable부터 교체하는 것은 우선순위가 낮습니다.

21장 API 장애를 단계별로 나누자#

API 호출:

Client
↓
DNS
↓
TCP
↓
TLS
↓
HTTP
↓
Authentication
↓
Application
↓
Database

각 단계의 실패 증상은 다릅니다.

예:

DNS 실패
→ Hostname 해석 안 됨

TCP 실패
→ Connection Timeout

TLS 실패
→ Certificate Error

HTTP 정상
→ 500 반환

Application 정상
→ DB Timeout

사용자는 모두:

API가 안 된다.

라고 표현할 수 있습니다.

22장 Packet Capture는 결과가 아니라 경계를 보여준다#

Packet Capture의 목적은 단순히 Packet을 보는 것이 아닙니다.

다음 질문에 답하는 데 있습니다.

요청이 실제로 나갔는가?

Server에 도착했는가?

응답이 돌아왔는가?

어느 구간에서 사라졌는가?

예:

Client
SYN O

Server
SYN X

라면 문제 범위를 Network 중간 구간으로 좁힐 수 있습니다.

23장 TCP Retransmission은 원인이 아니라 증거다#

Packet Capture에서:

TCP Retransmission

이 많이 보인다고 가정합니다.

이것만으로:

Cable 문제다.

라고 결론 내릴 수는 없습니다.

가능한 원인은:

Packet Loss

Network 혼잡

Queue Drop

무선 품질

Server 응답 지연

Capture Loss

Routing 변화

등 다양할 수 있습니다.

Retransmission은 추가 분석이 필요하다는 단서입니다.

24장 전원 문제도 통신 장애처럼 보일 수 있다#

Network 장비가 갑자기 Offline 상태가 됩니다.

잠시 뒤 다시 Online으로 돌아옵니다.

처음에는 Network 장애처럼 보일 수 있습니다.

하지만 실제로는:

전압 강하
↓
Device Reset
↓
Network Link Down
↓
Boot
↓
Network Link Up

과정일 수도 있습니다.

따라서 간헐적 Network 장애에서는 다음도 확인합니다.

Uptime

Boot Log

Reset Reason

Power Event

PoE Event

25장 Server 장애도 Network 장애처럼 보일 수 있다#

예:

Client
Connection Timeout

이라고 해도 Network가 반드시 문제는 아닙니다.

Server에서:

CPU 100%

Thread Pool Full

Connection Pool Full

Database Timeout

Disk I/O 증가

가 발생해 응답하지 못하는 경우도 있습니다.

그래서 Network Log와 Server Metric을 같은 시간대에 비교해야 합니다.

26장 한 사건을 여러 관찰값으로 조립하자#

다음 사건을 생각해보겠습니다.

10:00:00
사용자가 기능 실행

각 시스템에서는:

10:00:00.010
Device Input

10:00:00.030
Client Request

10:00:00.040
Firewall Allow

10:00:00.060
Server Request

10:00:02.080
Database Timeout

10:00:02.085
HTTP 500

10:00:02.100
Client Error

가 남습니다.

사용자의 증상은:

장비가 안 된다.

였지만 증거를 다시 조립하면:

Device 정상
↓
Network 정상
↓
Server 요청 수신 정상
↓
Database 응답 Timeout
↓
Application 500

으로 바뀝니다.

이것이 장애 분석의 핵심입니다.

27장 범용 장애 사례 — 단말에서 업무 처리가 되지 않는다#

현장 신고:

단말기가 안 됩니다.

질문을 통해 다음과 같이 바꿨다고 하겠습니다.

TERMINAL-07에서
09:10부터 인증 요청을 보내면
Network 연결은 정상이나
Server가 HTTP 500을 반환한다.

Server Log:

DB connection timeout

Database Monitoring:

Disk I/O 100%

변경 이력:

09:00
Backup Job 시작

이를 연결하면:

Backup
↓
Storage I/O 증가
↓
DB 응답 지연
↓
Application Timeout
↓
HTTP 500
↓
단말 업무 실패

라는 가설을 만들 수 있습니다.

중요한 점은 각 단계가 Log나 Metric으로 확인되어야 한다는 것입니다.

28장 범용 장애 사례 — 특정 장비만 반복적으로 Offline#

다음 상황입니다.

DEVICE-01
하루에 여러 차례 Offline

다른 장비
정상

Server Log:

Connection Lost

Switch Log:

Port 12 Link Down
Port 12 Link Up

Device Log:

System Boot

세 가지를 같은 시간에 연결하면:

Device Reset
↓
Link Down
↓
Boot
↓
Link Up
↓
Server Reconnect

흐름이 보입니다.

이때 Server TCP 설정만 계속 수정하는 것은 올바른 접근이 아닐 수 있습니다.

29장 범용 장애 사례 — 모든 장비가 동시에 접속 실패#

다음과 같은 상황입니다.

DEVICE-01 X
DEVICE-02 X
DEVICE-03 X
DEVICE-04 X

모든 장비에서:

Server Connection Timeout

이 발생했습니다.

이럴 때 장비 하나씩 Cable을 교체하기 전에 공통 요소를 봅니다.

Server

Firewall

Router

Core Switch

DNS

Authentication

Data Center Network

공통 장애 가능성이 훨씬 높기 때문입니다.

30장 재부팅은 진단 방법이 아니라 변경이다#

장애가 나면 가장 먼저:

재부팅해보세요.

라고 하기 쉽습니다.

물론 재부팅으로 정상화되는 장애도 있습니다.

하지만 재부팅은 현재 상태를 없애버릴 수 있습니다.

Memory 상태

Socket 상태

Error Counter

Temporary Log

Process State

등이 사라질 수 있습니다.

따라서 가능하다면 먼저:

현재 상태 기록
↓
Log 확보
↓
Metric 확보
↓
필요하면 Packet Capture
↓
그다음 재부팅

순서가 좋습니다.

31장 설정을 바꾸기 전에 원본을 남겨라#

예를 들어:

IP 변경

Gateway 변경

VLAN 변경

Firewall Rule 변경

Firmware 변경

을 하기 전에 현재 설정을 기록해야 합니다.

최소한:

변경 전 값

변경 시간

변경 담당자

변경 이유

변경 후 결과

Rollback 방법

을 남깁니다.

장애 대응 도중 여러 설정을 바꿨다가 원래 상태를 잃는 경우가 의외로 많습니다.

32장 현장에서 확보하면 좋은 기본 자료#

장애 발생 시 다음 자료를 확보하면 좋습니다.

장비 정보#

Device ID
Model
Serial
Firmware
IP
MAC
설치 위치

Network 정보#

Switch
Port
VLAN
Gateway
DNS
Route

장애 정보#

발생 시각
마지막 정상 시각
재현 조건
오류 메시지
영향 범위

변경 정보#

최근 배포
최근 설정 변경
장비 교체
Network 작업
전원 작업

이 정보가 모이면 다른 담당자에게 문제를 전달하기도 쉬워집니다.

33장 좋은 장애 티켓은 어떻게 작성할까#

다음 형식을 사용할 수 있습니다.

제목
DEVICE-07 Server 인증 요청 Timeout

발생 시각
2026-09-24 09:10

영향 범위
DEVICE-07만 발생

증상
Network 연결은 정상이나 인증 API 호출 시 Timeout

재현
로그인 시 100% 발생

마지막 정상
2026-09-24 08:55

최근 변경
09:00 Server Application 배포

확인한 내용
Ping 정상
TCP 443 정상
TLS 정상
API 응답 없음

관련 로그
Client Log
Server Log
Firewall Log

현재 가설
Server Application 또는 Backend 처리 문제

이런 Ticket은 단순히:

로그인 안 됨

보다 훨씬 빠르게 협업할 수 있습니다.

34장 원인과 증상을 구분하자#

예를 들어:

Connection Timeout

은 원인이 아닐 수 있습니다.

그것은 증상입니다.

실제 원인은:

Routing 오류

Firewall Drop

Server 과부하

Application Deadlock

Database 지연

Network Loss

중 하나일 수 있습니다.

마찬가지로:

장비 Offline

도 원인이 아닙니다.

34.1 장애 분석 문장에서 표현을 구분한다#

예:

관찰
TCP SYN에 응답 없음

가설
Firewall에서 Drop되고 있을 가능성

검증
Firewall Log 확인 필요

이렇게 쓰는 편이 좋습니다.

관찰된 사실과 추측을 섞지 않습니다.

35장 가설을 세울 때는 반증 방법까지 생각한다#

예:

가설
Server가 Down 상태다.

검증:

다른 Client에서도 접속 안 되는가?

Server Process는 실행 중인가?

Port는 LISTEN 상태인가?

또 다른 가설:

Cable 불량이다.

검증:

Switch Error Counter 증가?

Link Flap 존재?

정상 Cable로 교체 시 변화?

좋은 가설은 틀렸다는 것도 확인할 수 있어야 합니다.

36장 증거의 신뢰도를 구분하자#

다음 세 문장은 신뢰 수준이 다릅니다.

사용자:
아마 10시쯤부터 안 된 것 같다.

Application Log:
10:07:32 Connection Timeout

Firewall Log:
10:07:32 Packet Drop

사용자 증언도 중요하지만 정확한 Timestamp가 있는 System Log와 동일하게 취급하면 안 됩니다.

장애 기록에서는:

사용자 진술

관찰

System Log

Packet Capture

Measurement

등의 출처를 함께 기록하면 좋습니다.

37장 로그가 없다는 것도 중요한 사실이다#

예를 들어 사용자가 10:00에 API 요청을 했다고 말하지만 Server Access Log에는 아무 기록도 없습니다.

그렇다면:

Client
↓
Network
↓
Server

중 Server Application에 도달하기 전 어딘가를 확인해야 할 가능성이 높습니다.

반대로 Server Log에 Request가 있다면 Network의 기본 전달 여부에 대한 중요한 증거가 됩니다.

기대했던 로그가 없다는 사실도 하나의 증거입니다.

38장 장애 분석 도구를 목적별로 구분하자#

목적 대표적으로 확인할 것
전원 상태 장비 상태·전압·PoE·Uptime
물리 연결 Link·Cable·Port Error
Layer 2 MAC·VLAN·Switch Port
Layer 3 IP·ARP/NDP·Gateway·Route
TCP SYN·ACK·RST·Retransmission
UDP Datagram 송수신·Loss
API Status Code·Latency·Payload
Server CPU·Memory·Disk·Process
Database Connection·Query·Lock·I/O
Application Error Log·Thread·Queue

도구부터 선택하는 것이 아니라 확인하려는 가설에 맞는 도구를 선택합니다.

39장 간단한 API 재현 예#

시험 환경에서 Server API의 응답을 확인하고 싶다면 예를 들어 다음과 같이 요청할 수 있습니다.

curl -X POST http://test-server.local/api/device \
  -H "Content-Type: application/json" \
  -d '{
    "deviceId":"DEVICE-01",
    "event":"TEST",
    "timestamp":"2026-09-24T01:15:00Z"
  }'

중요한 것은 단순히 명령을 실행하는 것이 아닙니다.

다음 결과를 기록해야 합니다.

실행 시간

Request

HTTP Status

Response Body

Response Time

이렇게 해야 다른 담당자가 같은 테스트를 재현할 수 있습니다.

40장 기본 Network 연결 확인#

시험 또는 허가된 환경에서 다음과 같은 기본 도구를 사용할 수 있습니다.

Linux:

ping -c 4 192.168.10.20

하지만 Ping 결과는 다음 정도의 정보입니다.

ICMP Echo가 왕복 가능한가?

그 이상을 자동으로 증명하지 않습니다.

필요하면 이후:

ARP / NDP

Route

TCP Port

Application

까지 확인합니다.

41장 장애 재현이 위험하다면 직접 반복하지 않는다#

모든 장애를 재현해야 하는 것은 아닙니다.

예를 들어:

Motor 이상

안전 장치 오류

전력 과부하

생산설비 정지

결제 Transaction

출입통제

처럼 실제 업무나 물리적 안전에 영향을 줄 수 있다면 운영 시스템에서 반복 테스트해서는 안 될 수 있습니다.

이런 경우:

기존 Log

Event History

Monitoring Data

Test Environment

Simulator

를 사용합니다.

42장 로그에는 민감한 정보가 들어갈 수 있다#

장비와 Application Log에는 다음과 같은 정보가 포함될 수 있습니다.

사용자 ID

차량번호

Access Token

Session ID

개인정보

결제정보

내부 IP

API Key

따라서 장애 분석을 위해 Log를 공유할 때도:

필요한 범위만 수집

접근 권한 제한

민감값 Masking

안전한 저장

보관기간 관리

가 필요합니다.

43장 Packet Capture는 더 신중하게 다룬다#

Packet Capture는 일반 Application Log보다 훨씬 많은 정보를 포함할 수 있습니다.

암호화되지 않은 Protocol이라면:

Password

Token

Command

Personal Data

까지 포함될 가능성이 있습니다.

따라서:

필요한 Host

필요한 Port

필요한 시간

필요한 Interface

만 Capture하도록 범위를 제한하는 것이 좋습니다.

44장 장애 대응의 기본 순서#

전체 흐름을 정리하면 다음과 같습니다.

사용자 신고
↓
증상 구체화
↓
발생 시각 확인
↓
영향 범위 확인
↓
마지막 정상 상태 확인
↓
최근 변경 이력 확인
↓
재현 가능 여부 판단
↓
현재 상태와 Log 확보
↓
처리 흐름 작성
↓
마지막 정상 지점 확인
↓
최초 실패 지점 확인
↓
가설 수립
↓
한 가지씩 검증
↓
원인 확인
↓
복구
↓
재발 방지

장애 분석을 체계적으로 수행하려면 이 순서를 습관처럼 사용하는 것이 좋습니다.

45장 가장 먼저 던질 질문#

현장에서 “안 됩니다”라는 말을 들으면 다음 질문부터 시작할 수 있습니다.

무엇이 안 되는가#

전원?

Network?

화면?

입력?

Server 통신?

특정 기능?

물리 동작?

언제부터인가#

정확한 발생 시각?

마지막 정상 시각?

계속 발생?

간헐 발생?

누구에게 발생하는가#

한 장비?

한 구역?

한 사용자?

전체?

어떤 조건에서 발생하는가#

특정 시간?

특정 입력?

특정 Network?

높은 부하?

장비 재부팅 후?

무엇이 바뀌었는가#

Firmware?

Application?

Network?

전원?

설정?

인증서?

이 다섯 질문만 잘해도 장애 분석의 방향이 크게 달라집니다.

46장 장애 접수 체크리스트#

확인 항목 기록할 내용
대상 장비·서비스·기능
Device ID 고유 식별자
위치 물리적·논리적 위치
발생 시각 최초 장애 시각
마지막 정상 마지막 확인 시각
증상 실제 관찰 내용
기대 결과 정상이라면 발생해야 할 결과
실제 결과 실제 발생한 결과
재현 조건 입력·환경·순서
발생 빈도 항상·간헐·특정 시간
영향 범위 장비·지역·기능·사용자
최근 변경 배포·설정·전원·Network
관련 로그 Client·Server·Network
임시 조치 이미 수행한 작업

47장 흔히 하는 잘못된 장애 대응#

47.1 무조건 재부팅부터 한다#

증거가 사라질 수 있습니다.

47.2 Cable부터 무조건 교체한다#

증상이 Application Layer 문제라면 의미가 없습니다.

47.3 Ping이 되니 Network는 정상이라고 한다#

Service Port나 Routing, Application까지 정상이라는 뜻은 아닙니다.

47.4 Error Message 하나만 보고 원인을 결정한다#

Timeout

이라는 결과만으로 Network 문제인지 Server 문제인지 결정할 수 없습니다.

47.5 여러 설정을 동시에 바꾼다#

문제가 해결돼도 무엇이 원인이었는지 알 수 없습니다.

47.6 사용자의 기억을 정확한 시각으로 취급한다#

시스템 Log와 비교해야 합니다.

48장 좋은 장애 분석의 핵심 원칙#

첫째, 증상과 원인을 구분합니다.

증상
장비 Offline

원인
아직 모름

둘째, 관찰과 추측을 구분합니다.

관찰
TCP SYN 반복

추측
Firewall Drop 가능성

셋째, 마지막 정상 지점과 최초 실패 지점을 찾습니다.

넷째, 시간축을 맞춥니다.

다섯째, 한 번에 하나의 가설을 검증합니다.

49장 자기 점검#

49.1 사용자가 “장비가 안 된다”고 하면 가장 먼저 무엇을 해야 할까#

무엇이, 언제, 어떤 조건에서, 어디까지 정상이고 어디부터 실패하는지 질문하여 증상을 기술적인 문장으로 바꿉니다.

49.2 장애 재현이란 무엇인가#

단순히 오류를 다시 발생시키는 것이 아니라 동일한 입력과 조건에서 기대 결과와 실제 결과를 반복적으로 비교할 수 있도록 만드는 것입니다.

49.3 왜 Timestamp가 중요한가#

Client·Network·Server·Database 등의 Log를 하나의 사건으로 연결하기 위해서입니다.

시스템 시간이 다르면 같은 Event를 서로 다른 사건으로 오해할 수 있습니다.

49.4 장애가 한 장비에서만 발생하면 무엇을 먼저 볼까#

다른 장비와 공유하지 않는 요소를 우선 확인합니다.

예:

전원

Cable

Port

설정

Firmware

장비 자체

입니다.

49.5 장애가 전체 장비에서 동시에 발생하면 무엇을 볼까#

모든 장비가 공유하는 요소를 우선 확인합니다.

예:

Server

Database

Firewall

Router

Core Switch

Authentication Service

입니다.

50장 이 글을 마치며#

“장비가 안 됩니다”라는 문장은 장애 분석의 끝이 아니라 시작입니다.

현장에서는 이 문장을 다음과 같이 바꾸는 과정이 필요합니다.

장비가 안 됩니다.
        ↓
어떤 장비인가?
        ↓
어떤 기능인가?
        ↓
언제 발생했는가?
        ↓
어떤 입력에서 발생하는가?
        ↓
어디까지 정상인가?
        ↓
어디부터 실패하는가?
        ↓
누구에게 영향을 주는가?
        ↓
최근 무엇이 바뀌었는가?

그 다음에야 실제 원인 분석이 시작됩니다.

전체 과정을 다시 정리하면:

증상 정의
↓
영향 범위
↓
발생 시각
↓
재현 조건
↓
변경 이력
↓
로그 확보
↓
시간축 정렬
↓
처리 흐름 확인
↓
최초 실패 지점 발견
↓
가설 수립
↓
검증
↓
원인 확인

특히 다음 네 가지를 기억하면 됩니다.

“안 된다”는 원인이 아니라 사용자에게 보이는 결과입니다.

장애 분석은 마지막 정상 지점과 최초 실패 지점 사이를 좁혀가는 과정입니다.

로그 하나보다 여러 시스템의 증거를 같은 시간축으로 연결하는 것이 중요합니다.

설정을 바꾸기 전에 현재 상태를 기록하고, 한 번에 하나의 가설을 검증해야 합니다.

결국 좋은 장애 대응은 특정 명령어나 도구를 많이 알고 있는 것만으로 완성되지 않습니다.

모호한 상황을 관찰 가능한 사실로 바꾸고, 하나의 사건을 여러 증거로 다시 조립하는 능력이 문제 해결의 출발점입니다.

이 페이지의 목차