장애를 재현하는 법: 의도적으로 장애를 만들어 원인 추적하기 (실무 트러블슈팅 가이드)

서론: 장애는 ‘운’이 아니라 ‘재현 가능한 사건’이다

운영을 해본 사람이라면 이런 말을 한 번쯤 들어봤을 것이다.
“어제 분명히 장애가 있었는데, 지금은 괜찮네요.”

이 말이 의미하는 바는 단순하다.
장애를 재현하지 못하면, 원인도 해결도 없다.

실무에서 진짜 문제는 장애 그 자체가 아니라,
왜 발생했는지를 끝까지 추적하지 못하는 것이다.

이 글에서는 실제 운영 환경에서 사용하는 방식 그대로,
의도적으로 장애를 만들어 원인을 추적하는 방법을 단계별로 정리한다.

---

1. 왜 장애는 재현해야 하는가?

장애 대응이 실패하는 가장 흔한 이유는 다음 중 하나다.

• 로그가 남아 있지 않다
• 지표를 보지 않았다
• “추정”으로 원인을 결론지었다

재현 없는 분석은 추측에 불과하다.
재현 가능한 장애만이 검증 가능한 해결책을 만든다.

그래서 숙련된 운영자일수록 이렇게 말한다.
“장애는 고쳐도 되고, 재현은 반드시 해야 한다.”

---

2. 장애 재현의 기본 원칙

장애를 재현할 때 반드시 지켜야 할 원칙이 있다.

• 운영 환경에서 바로 시도하지 않는다
• 가능하면 동일한 설정의 스테이징을 사용한다
• 하나의 변수만 변경한다

여러 설정을 동시에 바꾸면 원인을 특정할 수 없다.
장애 재현은 항상 실험에 가깝게 접근해야 한다.

---

3. 가장 먼저 재현해야 할 장애 유형

1) 타임아웃 장애

가장 흔하고, 가장 많이 오해하는 장애다.

의도적으로 재현하는 방법은 간단하다.

Thread.sleep(30000);

또는 DB 쿼리를 강제로 지연시킨다.

SELECT pg_sleep(30);

이 상태에서 다음을 확인한다.

• Nginx error log
• WAS access log
• DB slow query log

이 과정을 통해 “어디서” 타임아웃이 발생했는지 분리할 수 있다.

---

2) 커넥션 풀 고갈 장애

서비스가 멀쩡해 보이는데 요청이 점점 느려지는 경우,
대부분 커넥션 풀 고갈이 원인이다.

재현 방법:

• DB 커넥션 풀 사이즈를 극단적으로 줄인다
• 트랜잭션을 일부러 오래 유지한다

@Transactional
public void test() {
    Thread.sleep(60000);
}

이 상태에서 HikariCP 지표를 보면,
active / idle / waiting 수치가 명확히 변한다.

---

3) 메모리 부족(OOM) 장애

OOM은 “갑자기” 발생하지 않는다.
대부분 누적된 메모리 사용의 결과다.

의도적 재현:

List<byte[]> list = new ArrayList<>();
while (true) {
    list.add(new byte[10 * 1024 * 1024]);
}

이후 다음을 확보한다.

• heap dump
• GC 로그
• 메모리 사용 그래프

OOM을 재현해보면, 실제 운영 환경에서 왜 감지하지 못했는지도 함께 보인다.

 

---

4. 로그 없이 장애를 분석하려 하지 마라

재현 실험에서 반드시 필요한 것이 로그다.

• 요청 시작 로그
• 외부 호출 전후 로그
• 에러 발생 지점 로그

특히 다음 패턴은 매우 중요하다.

[START] requestId=...
[CALL] external-api
[END] requestId=...

이 구조가 없으면 재현해도 분석이 불가능하다.

---

5. 지표(Metric)는 장애의 “증거”다

장애 분석에서 로그가 증언이라면,
지표는 객관적인 증거다.

• CPU 사용률
• 메모리 사용량
• 스레드 수
• 커넥션 대기 시간

Prometheus, Grafana를 사용한다면
재현 전·중·후 그래프를 반드시 비교해야 한다.

---

6. 재현 후 반드시 해야 할 질문

장애를 재현한 뒤, 다음 질문에 답할 수 있어야 한다.

• 이 장애는 다시 발생할 수 있는가?
• 감지 지점은 어디였는가?
• 자동으로 알림을 받을 수 있었는가?
• 사용자는 어떤 증상을 겪었는가?

이 질문에 답하지 못하면, 같은 장애는 반드시 반복된다.

---

결론: 좋은 운영자는 장애를 두려워하지 않는다

장애를 재현한다는 것은 일부러 시스템을 망가뜨리는 일이 아니다.

시스템을 이해하는 가장 빠른 방법이다.

의도적으로 장애를 만들 수 있을 때,
비로소 장애는 통제 가능한 사건이 된다.

운영에서 성장하고 싶다면,
장애를 “피하는 법”보다 재현하는 법부터 익혀야 한다.