libssl 하나로 서버가 죽었다

― 애플리케이션이 아닌 장애를 마주한 개발자의 기록

운영준비 중인 WAS 서버 하나가 갑자기 이상해졌다.
SSH는 간신히 붙는데, sudo가 안 된다
네트워크 인터페이스도 안 올라온다.
재부팅? 의미 없다.

확인 결과는 이 한 줄이었다.

 

libssl3.so  라이브러리를 찾을 수 없음

 

---

1. 이 장애는 “코드 장애”가 아니다

개발자들은 보통 장애를 이렇게 분류한다.

• 에러 로그가 있다
• 재현이 된다
• 코드로 고칠 수 있다

하지만 이번 장애는 이 셋을 전부 만족하지 않았다.

• 애플리케이션 로그 ❌
• 재현 불가 ❌
• 코드 수정 무의미 ❌

libssl, glibc 같은 OS 핵심 라이브러리 손상은
애플리케이션 레벨에서 개입할 수 있는 영역이 아니다.

이게 깨지면 무슨 일이 벌어질까?

• sudo 실행 불가
• ip, ifup, systemctl 불가
• 네트워크 복구 불가
• 패키지 재설치 불가

👉 서버는 켜져 있지만, 사실상 사망 상태다.

---

2. “왜 이런 일이 생기냐”는 질문에 대한 현실적인 답

의외로 이런 장애는 드물지 않다.

실무에서 자주 보는 원인은 다음과 같다.

• OS 업데이트 중 디스크 부족
• 스토리지 I/O 오류
• 강제 종료 이후 파일시스템 손상
• VM 내부 패키지 의존성 붕괴

중요한 포인트는 이것이다.

이 원인들은 애플리케이션 코드와 무관하다.

아무리 코드 품질이 좋아도
OS가 깨지면 서비스는 멈춘다.

---

3. “그럼 고치면 되지 않나?”라는 착각

운영 쪽에서 흔히 나오는 대응안은 이렇다.

• 다른 서버에서 라이브러리 복사
• 서버 복제
• 수동으로 파일 복구

하지만 이건 응급 CPR에 가깝다.

libssl 하나를 넣는다고 끝나지 않는다.

• glibc 버전
• ld.so 캐시
• 연동 라이브러리
• 패키지 DB 상태

의존성은 연쇄적으로 무너진다.

그래서 경험 있는 운영자들은 이렇게 말한다.

“이 서버는 살리는 대상이 아니라 버리는 대상이다.”

---

4. 서버는 이제 ‘고쳐 쓰는 물건’이 아니다

이 장애를 겪으며 다시 한 번 확신했다.

서버는 소모품이다.

정답은 언제나 같다.

1. 신규 서버 생성
2. OS 정상 상태 확보
3. 데이터 디스크만 이관
4. WAS 재설치
5. 설정 수동 복구

시간 기준으로도,
리스크 기준으로도
이게 가장 싸다. 

 

마무리

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