🚨 운영 중 서비스 장애 대응 경험 정리 (EC2 IP 변경 이슈)
실제 운영 중이던 프로젝트에서 로그인 및 주요 API가 전체적으로 실패하는 장애를 경험했습니다.
이 글은 단순 트러블슈팅 기록이 아니라, 문제 분석 → 원인 추적 → 재발 방지 설계까지 수행한 과정을 정리한 글입니다.
📌 장애 개요
✔ 발생 현상
- 로그인 500 에러 발생
- 채팅/마이페이지 API 전체 실패
- 프론트엔드에서 세션 유지 불가
✔ 영향 범위
- 인증 기능 전체 마비
- 사용자 데이터 조회 불가
- 실질적으로 서비스 사용 불가능 상태
🔎 1. 1차 분석 — 애플리케이션 레벨 문제인가?
로그 확인 결과:
[auth][error] CallbackRouteError
[cause]: connect ETIMEDOUT
OAuth 인증 과정에서 DB 연결 타임아웃이 발생하고 있었습니다.
또한, 프록시 요청에서도 다음과 같은 오류가 발생했습니다.
Connect Timeout Error (attempted address: 43.200.169.171:8000)
여기서 중요한 점은:
코드 에러가 아니라 네트워크 연결 타임아웃이라는 점이었습니다.
이 시점에서 애플리케이션 레벨이 아닌 인프라 레벨 문제 가능성을 의심했습니다.
🧠 2. 원인 추적 — 인프라 계층 점검
2-1. EC2 상태 점검
백엔드 서버는 Amazon EC2 위에서 실행 중이었습니다.
인스턴스 상태를 확인한 결과:
- Status Check: 2/3 통과
- Instance Status Check 실패
이는 OS 내부 문제 또는 네트워크 레벨 이상을 의미합니다.
2-2. Stop/Start 이후 퍼블릭 IP 변경
문제 해결을 위해 EC2를 재시작(Stop → Start)했습니다.
이 과정에서 퍼블릭 IP가 변경되었습니다.
기존: 43.200.169.171
변경: 새로운 퍼블릭 IP
하지만 프론트엔드는 Vercel 에 배포되어 있었고,
환경변수에는 여전히 이전 IP가 설정된 상태였습니다.
💥 3. 근본 원인
최종 원인은 다음과 같습니다.
- EC2 인스턴스 상태 이상 발생
- Stop/Start 수행
- 퍼블릭 IP 변경
- 환경변수 갱신 누락
- Vercel → 백엔드 연결 실패
- 전체 API 500 에러
즉,
코드가 아닌 고정되지 않은 인프라 IP에 직접 의존한 구조적 문제였습니다.
🛠 4. 해결 과정
4-1. 인스턴스 정상화
- EC2 상태 3/3 통과 확인
- SSH 접속 정상 확인
4-2. DB 외부 접속 점검
- bind-address = 0.0.0.0
- 3306 포트 리스닝 확인
- 사용자 권한 재설정
4-3. 환경변수 동기화
- 백엔드 .env 수정
- Vercel 환경변수 수정
- 재배포 진행
이후 로그인 및 주요 API가 정상 동작하는 것을 확인했습니다.
🚀 5. 단순 복구에서 끝내지 않고, 구조 개선
이번 장애를 단순히 "IP 수정"으로 끝내지 않았습니다.
재발 방지를 위한 구조 개선을 진행했습니다.
✅ 5-1. Elastic IP 적용 (고정 IP 도입)
Elastic IP 를 EC2에 연결했습니다.
이제:
- Stop/Start 이후에도 IP 유지
- 동일 원인 장애 원천 차단
✅ 5-2. 환경변수 관리 체계화
- Vercel
- EC2
- 로컬 환경
환경값을 일원화하고 변경 체크리스트 작성
🎯 이 경험을 통해 얻은 것
1️⃣ 애플리케이션 문제가 아닐 때, 어디를 봐야 하는지 배웠습니다.
로그의 “connect timeout” 한 줄에서
코드가 아닌 네트워크/인프라 문제로 사고를 확장할 수 있었습니다.
2️⃣ 클라우드 환경에서 IP는 고정이 아니라는 점을 체감했습니다.
Elastic IP를 사용하지 않으면
Stop/Start만으로도 서비스가 깨질 수 있다는 것을 경험했습니다.
3️⃣ 장애 복구보다 중요한 것은 재발 방지 설계라는 것을 배웠습니다.
단순 수정이 아닌:
- 구조 개선
- 고정 IP 도입
- 모니터링 도입 계획
- 도메인 기반 설계 전환
까지 진행했습니다.
📌 정리
이번 장애는 다음 흐름으로 발생했습니다.
EC2 상태 이상
→ IP 변경
→ 환경변수 불일치
→ 프록시 타임아웃
→ 전체 API 500 에러
핵심 교훈은 이것입니다.
운영 환경에서는 “코드보다 인프라가 먼저 무너질 수 있다.”
그리고 저는 이 경험을 통해
문제 해결 능력뿐 아니라, 구조 개선 역량까지 확장할 수 있었습니다.
'코디챗봇 프로젝트' 카테고리의 다른 글
| [Aura_AI] [8편] 서버가 반복적으로 터진 이유와 전체 복구 과정 (1) | 2026.02.27 |
|---|---|
| [Aura_AI] [7편] GPT 호출 안정화 및 토큰 사용량 제한 설계 (0) | 2026.02.27 |
| [Aura_Ai] [6편] 프로젝트 배포 (0) | 2026.02.13 |
| [Aura_Ai] [5편] 데이터 가공으로 UX 개선하기 (0) | 2026.02.02 |
| [Aura_Ai] [4편] GPT API를 활용한 서비스 설계 (0) | 2026.02.01 |