was 서버가 죽었다

— 이번 장애로 돌아본, 미리 할 수 있었던 것들

이번 장애는 애플리케이션 문제가 아니었다.
코드도, 로직도, 배포도 아니었다.

단 하나의 WAS 서버에서 OS 핵심 라이브러리가 손상되었고,
그 순간 서비스는 그대로 멈췄다.

돌이켜보면 이 장애는
“특이한 사고”라기보다
구조적으로 언제든 발생할 수 있는 사건이었다.

이 글은 원인 분석이 아니라,
이번 사태를 통해 미리 할 수 있었던 것들을 정리한 고찰이다.

---

1. 애플리케이션 설계로 막을 수 없는 장애가 있다

이번 장애의 본질은 명확했다.

• sudo, ip, systemctl이 동작하지 않음
• 네트워크 복구 불가
• 패키지 설치 불가

즉, 애플리케이션 이전에 OS가 무너진 상태였다.

이런 장애는:

• Circuit Breaker로도
• Queue로도
• Stateless로도
  막을 수 없다.

OS가 무너지면,
애플리케이션 설계는 아무 힘도 없다.

이 사실을 인정하는 것부터가 출발점이다.

---

2. 단일 WAS는 항상 단일 장애 지점(SPOF)이다

이번 구조에서 가장 치명적인 부분은 단순했다.

 

WEB → WAS(1대) → DB

WAS가 단일 인스턴스였기 때문에,

• OS 장애 = 서비스 중단이었다.

WAS 다중화가 있었다면:

• 장애는 발생했어도
• 서비스 전체 중단으로 번지지는 않았을 것이다.

여기서 중요한 점은 이것이다.

WAS 다중화는 장애를 막는 기술이 아니라,
장애를 서비스 중단으로 확장시키지 않는 기술이다.

---

3. 서버를 “살리려는 시도”가 가장 위험했다

OS가 깨진 서버에서 가장 흔히 나오는 대응은 이렇다.

• 라이브러리 수동 복사
• 패키지 강제 설치
• 서버 복제 시도

하지만 OS 핵심 영역이 손상된 상태에서의 수동 복구는
대부분 시간을 쓰는 도박에 가깝다.

이 상황에서의 정답은 명확하다.

서버는 고쳐 쓰는 대상이 아니라,
다시 만드는 대상이다.

이 전제가 없으면 장애 대응은 감정 노동이 된다.

---

4. IaC가 없으면 복구는 ‘기억 의존 작업’이 된다

이번 장애에서 가장 아쉬웠던 점은,
정상 상태를 즉시 재현할 수 있는 방법이 없었다는 것이다.

IaC가 없을 때의 복구는 보통 이렇게 흘러간다.

• OS 버전: “아마 이거였을걸?”
• 패키지: “그때 깔았던 것 같은데…”
• 설정: “예전 서버랑 비슷하게”

이건 복구가 아니라 추억 복원 작업이다.

그래서 이 결론에 도달하게 된다.

IaC는 자동화를 위한 도구가 아니라,
시스템을 다시 만들 수 있다는 ‘증명’이다.
그래서 편의가 아니라 최소 조건이다.

---

5. 네트워크는 속도가 아니라 경로와 경계의 문제다

장애 상황에서 가장 시간을 잡아먹은 것도 네트워크였다.

• WEB → WAS 접근 불가
• 내부 IP 대역 차단
• 방화벽 / ACL / NACL / SG 경계 혼재

대부분의 네트워크 장애는
속도나 대역폭 문제가 아니다.

네트워크 설계는
얼마나 빠르냐가 아니라,
어디까지 허용하고 어디서 차단하느냐의 문제다.

경계가 불명확할수록,
장애 원인은 방화벽 뒤에 숨어버린다.

---

6. DNS와 방화벽은 문제를 조용히 숨긴다

이번 장애에서 또 하나 느낀 점은 이것이다.

• DNS는 단순해 보이지만, 장애 나면 모든 걸 멈춘다
• 방화벽은 보안을 지키지만, 문제도 같이 지킨다

서버는 살아 있는데 접근이 안 되는 상태,
로그는 없고 타임아웃만 남는 상태.

이럴수록 장애는 더 늦게 발견되고,
복구는 더 느려진다.

---

7. 미리 할 수 있었던 것들 (정리)

이번 사태를 기준으로,
사전에 할 수 있었던 것들을 정리하면 아래와 같다.

• WAS 최소 2대 이상 구성
• Stateless 기반 구조
• 서버 이미지를 기준으로 한 재생성 전략
• IaC를 통한 환경 정의
• 네트워크 경계 명확화 (DMZ / Private)
• 장애 시 “복구”보다 “재생성”을 선택하는 기준 합의

이 중 어느 하나도
장애 발생 자체를 막지는 못한다.

다만,

장애가 곧 서비스 중단이 되는 구조는 피할 수 있었다.

마무리

이번 장애는 나에게 이렇게 정리된다.

애플리케이션 장애는 고칠 수 있지만,
OS가 무너진 클라우드 인프라 장애 앞에서
애플리케이션은 아무런 힘도 없다.