[20편] 배포 후 오류 수정

 

🚨 배포된 사이트 로그인/채팅 전체 장애 발생 원인 및 해결 과정 상세 정리

정상적으로 운영 중이던 서비스에서 갑자기 로그인, 채팅, 마이페이지 기능이 모두 동작하지 않는 장애가 발생했습니다.
코드 수정이나 배포 변경이 없던 시점이었기 때문에, 처음에는 원인 파악이 쉽지 않았습니다.

결론부터 말씀드리면, 이번 장애는 코드 문제가 아니라 인프라 계층에서 발생한 복합적인 문제였습니다.

EC2 인스턴스 상태 이상 → Stop/Start 과정에서 퍼블릭 IP 변경 → 환경변수 불일치 → Vercel 프록시 타임아웃 발생

아래에 실제 발생 흐름과 해결 과정을 단계별로 상세히 정리하겠습니다.

---

1️⃣ 발생 증상

1-1. 로그인 기능 실패

로그인 시 다음과 같은 에러가 발생했습니다.

/api/auth/error?error=Configuration
500 (Internal Server Error)

OAuth 로그인(구글 로그인 포함)이 전부 실패하였으며, 단순 인증 오류가 아닌 서버 내부 에러(500) 로 표시되었습니다.

---

1-2. 채팅 및 마이페이지 API 실패

다음 API 요청들이 모두 실패했습니다.

/api/proxy/sessions
/api/proxy/users/me

공통적으로 500 에러가 발생했으며, 프론트엔드에서는 세션을 가져오지 못해 로그인 상태가 유지되지 않았습니다.

즉, 단순 로그인 문제가 아니라 백엔드 전체가 정상적으로 응답하지 못하는 상태였습니다.

---

2️⃣ 로그에서 확인된 주요 오류

2-1. NextAuth 에러 로그

로그인 시 다음과 같은 에러가 확인되었습니다.

[auth][error] CallbackRouteError
[cause]: connect ETIMEDOUT
[details]: { provider: "google" }

이 에러는 OAuth 콜백 처리 중 DB 연결 단계에서 타임아웃이 발생했다는 의미입니다.

즉, 인증 자체의 문제가 아니라 백엔드가 데이터베이스에 접근하지 못하고 있는 상태였습니다.

---

2-2. Vercel Functions 로그

Vercel 로그에서는 다음과 같은 오류가 확인되었습니다.

TypeError: fetch failed
Connect Timeout Error (attempted address: 43.200.169.171:8000)
code: UND_ERR_CONNECT_TIMEOUT

여기서 중요한 부분은 다음입니다.

attempted address: 43.200.169.171:8000

즉, Vercel이 특정 IP 주소(이전 EC2 퍼블릭 IP)로 계속 요청을 보내고 있었고,
해당 주소에서 응답을 받지 못해 연결 타임아웃이 발생한 상황이었습니다.

---

3️⃣ 원인 분석

3-1. EC2 상태 검사 실패

Amazon EC2 인스턴스 상태를 확인한 결과, 상태 체크가 2/3 통과로 표시되어 있었습니다.

이는 다음을 의미합니다.

• System Status Check: 통과
• Instance Status Check: 실패

Instance Status Check 실패는 보통 OS 내부 문제(네트워크, 커널, 파일시스템 등) 를 의미합니다.

이 시점에서 이미 인스턴스가 정상 동작하지 않는 상태였습니다.

---

3-2. Stop/Start 이후 퍼블릭 IP 변경

문제 해결을 위해 EC2 인스턴스를 Stop → Start 하였습니다.

이 과정에서 다음과 같은 일이 발생했습니다.

기존 IP: 43.200.169.171
변경 후: 새로운 퍼블릭 IP 할당

AWS 기본 설정에서는 Elastic IP를 사용하지 않으면 Stop/Start 시 퍼블릭 IP가 변경됩니다.

하지만 다음 환경변수들은 여전히 이전 IP를 가리키고 있었습니다.

• Vercel 환경변수
• 백엔드 .env 파일
• 일부 프록시 설정

---

3-3. 환경변수 불일치로 인한 연쇄 장애

결과적으로:

1. EC2는 새 IP로 실행 중
2. Vercel은 이전 IP로 요청
3. 요청이 도달하지 않음
4. Connect Timeout 발생
5. 모든 API 500 에러 발생

즉, 서비스 전체가 멈춘 것처럼 보였지만, 실제로는 프록시 연결 실패 문제였습니다.

---

4️⃣ 실제 해결 과정 (순서대로 정리)

4-1. EC2 상태 정상화

• 인스턴스 상태 검사 확인
• 재부팅 및 Stop/Start 수행
• 상태 3/3 통과 확인
• SSH 접속 정상 여부 재확인

---

4-2. MySQL 외부 접속 설정 점검

MySQL 설정 파일에서 다음을 확인했습니다.

bind-address = 0.0.0.0

포트 리스닝 여부 확인:

ss -lntp | grep 3306

3306 포트가 정상적으로 열려 있는지 점검했습니다.

---

4-3. MySQL 사용자 권한 재설정

CREATE USER IF NOT EXISTS 'aura_user'@'%' IDENTIFIED BY '비밀번호123!';
GRANT ALL PRIVILEGES ON aura_ai.* TO 'aura_user'@'%';
FLUSH PRIVILEGES;

외부 접속이 가능하도록 권한을 명확히 재부여했습니다.

---

4-4. 백엔드 .env 수정

• MYSQL_HOST를 새 EC2 퍼블릭 IP로 변경
• 이후 systemd 재시작

sudo systemctl restart aura-api

---

4-5. Vercel 환경변수 수정 및 재배포

Vercel 에서 다음 항목을 수정했습니다.

• MYSQL_HOST
• BACKEND_URL (또는 프록시 대상 URL)

모두 새 IP로 변경 후 Redeploy 진행

이후 로그인 및 API 요청이 정상 동작하는 것을 확인했습니다.

---

5️⃣ 최종 원인 정리

이번 장애는 코드 문제가 아니라 다음 흐름에서 발생했습니다.

1. EC2 내부 상태 이상 발생
2. Stop/Start 수행
3. 퍼블릭 IP 변경
4. 환경변수 갱신 누락
5. Vercel 프록시 연결 실패
6. 모든 API 500 에러

핵심은 다음입니다.

배포가 정상이어도, 인프라 IP가 변경되면 서비스는 즉시 장애 상태가 될 수 있습니다.

---

6️⃣ 재발 방지 조치 (완료)

6-1. Elastic IP 연결 (고정 IP 적용)

Elastic IP 를 인스턴스에 연결했습니다.

이제:

• Stop/Start 이후에도 IP가 유지됩니다.
• 동일 원인으로 인한 장애는 재발하지 않습니다.

---

6-2. 환경변수 일원화

다음 환경을 모두 동일 값으로 관리하도록 정리했습니다.

• Vercel
• EC2
• 로컬 개발 환경

또한, 변경 시 함께 수정해야 할 체크리스트를 작성하여 관리하도록 했습니다.

---

7️⃣ 앞으로 추가로 적용하면 좋은 개선 사항

1) CloudWatch 알람 설정

Amazon CloudWatch 에서

• StatusCheckFailed 감지 시 즉시 알림 수신
• 인스턴스 이상을 빠르게 인지 가능

---

2) 백엔드 헬스 체크 엔드포인트 추가

/health

간단한 상태 확인 API를 추가하여 모니터링 도구와 연동 가능하도록 개선 예정입니다.

---

3) 도메인 기반 연결 구조로 개선

IP 대신 다음과 같은 도메인을 사용하는 것이 더 안전합니다.

api.example.com

이 경우:

• IP 변경 시 DNS만 수정하면 됨
• 환경변수 변경 불필요
• 운영 안정성 향상

---

📌 최종 결론

이번 장애는 다음과 같은 복합 문제였습니다.

EC2 상태 검사 실패
→ IP 변경
→ 환경변수 불일치
→ Vercel 프록시 타임아웃

가장 중요한 해결 포인트는 다음입니다.

Elastic IP를 통한 고정 IP 적용

이를 통해 동일한 유형의 장애는 재발하지 않도록 안정화할 수 있었습니다.

---

필요하시다면,

• 기술 블로그용으로 더 전문적인 아키텍처 분석 버전
• 면접에서 활용 가능한 장애 대응 스토리 버전
• 다이어그램 포함 정리본

도 추가로 정리해 드리겠습니다.