frontend-diary-log 님의 블로그

[Aura_AI] [8편] 서버가 반복적으로 터진 이유와 전체 복구 과정

frontend-diary-log — Fri, 27 Feb 2026 15:13:47 +0900

[Aura_AI] [8편] 서버가 반복적으로 터진 이유와 전체 복구 과정

(EC2 재생성, DB 스키마 정합성 확보, GPT 오류 수정, CloudWatch 자동 복구 적용)

1️⃣ 문제 상황: 기능은 있는데, 서버가 버티지 못했다

배포 이후 일정 기간이 지나면서 이상 현상이 반복적으로 발생했습니다.

✔ /api/proxy/users/me → 500 에러

✔ 로그인 후 마이페이지 로딩 실패

✔ GPT 응답 생성 시 “응답을 생성하지 못했습니다.” 반복

✔ SSH 접속 간헐적 타임아웃

✔ EC2 상태 검사 2/3

특징은 이랬습니다.

고쳐놓으면 잠깐 정상 작동
며칠 뒤 다시 서버가 불안정해짐

단순 코드 문제가 아니라,
인프라 레벨 + DB + GPT 호출 문제가 동시에 얽힌 복합 장애였습니다.

2️⃣ 원인 분석

2-1. EC2 인스턴스 상태 불안정

백엔드는 Amazon EC2 에서 운영 중이었습니다.

상태 확인 결과:

Status Check 2/3
Instance Status Check 실패

이로 인해:

SSH 연결 불안정
서버 프로세스 간헐적 중단
일정 시간 후 다시 장애 발생

결론:

기존 인스턴스 자체가 이미 불안정한 상태였음

재부팅으로는 근본 해결이 되지 않았습니다.

2-2. DB 연결 실패

백엔드 로그에서 반복적으로 확인된 오류:

ECONNREFUSED
Can't connect to MySQL server

원인 후보:

MySQL 미실행
bind-address 설정 문제
포트 차단
계정 권한 문제

즉, 서버만이 아니라 DB 레이어도 불완전한 상태였습니다.

2-3. DB 스키마 불일치

다음과 같은 오류도 확인되었습니다.

Unknown column 'bio' in 'field list'

문제 상황:

코드에서는 bio, location, style_preference, profile_image 컬럼 사용
실제 DB에는 해당 컬럼이 존재하지 않음

결과:

→ /users/me 호출 시 500 에러 발생

이는 단순 서버 다운이 아니라
코드와 DB 구조가 맞지 않는 상태였습니다.

2-4. GPT 호출 파라미터 충돌

또 다른 문제는 GPT 호출 부분이었습니다.

max_tokens 파라미터가 새 모델 정책과 충돌
일부 요청에서 400 에러 발생
응답이 빈 문자열로 내려오는 케이스 존재

즉,

서버, DB, GPT 호출 모두 동시에 불안정

3️⃣ 해결 전략: 부분 수리가 아닌 전체 재정비

이번에는 “고쳐 쓰기”가 아니라
구조를 다시 세우기로 결정했습니다.

3-1. EC2 인스턴스 재생성

기존 인스턴스는 폐기했습니다.

✔ 신규 t3.small 생성

✔ Elastic IP 재연결 (IP 고정)

이전에는 Stop/Start 시 IP가 변경되는 구조였습니다.
이번에는 Elastic IP를 적용해 재발 방지했습니다.

3-2. SSH 및 Git 환경 복구

✔ Host key mismatch 해결

~/.ssh/known_hosts 수정

✔ GitHub SSH 키 재등록

✔ git clone 정상 완료

3-3. 백엔드 재설치 및 서비스화

✔ Python 가상환경 구성

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

✔ systemd 서비스 등록

sudo nano /etc/systemd/system/aura-api.service

적용 후:

sudo systemctl daemon-reload
sudo systemctl enable aura-api
sudo systemctl start aura-api

→ 서버 재부팅 시 자동 실행

3-4. MySQL 완전 재정비

✔ MySQL 설치

sudo apt install mysql-server

✔ DB 및 계정 생성

CREATE DATABASE aura_ai;
CREATE USER 'aura_user'@'%' IDENTIFIED BY '비밀번호';
GRANT ALL PRIVILEGES ON aura_ai.* TO 'aura_user'@'%';
FLUSH PRIVILEGES;

외부 연결 허용

✔ bind-address 수정

bind-address = 0.0.0.0

✔ 방화벽 오픈

sudo ufw allow 3306/tcp

✔ EC2 보안 그룹에서도 3306 허용

3-5. DB 스키마 정합성 확보

누락된 컬럼 추가:

ALTER TABLE users ADD COLUMN bio TEXT NULL;
ALTER TABLE users ADD COLUMN location VARCHAR(255) NULL;
ALTER TABLE users ADD COLUMN style_preference VARCHAR(255) NULL;
ALTER TABLE users ADD COLUMN profile_image VARCHAR(255) NULL;

이후 /users/me 정상 동작 확인

4️⃣ 프론트/프록시 연결 재정비

프론트는 Vercel 에 배포되어 있었습니다.

✔ 환경변수 수정

BACKEND_API_BASE_URL=http://<Elastic-IP>:8000

✔ /api/proxy/* 연결 로그 추가

→ 실제 연결 주소 디버깅 가능하도록 개선

5️⃣ GPT 오류 수정

✔ 파라미터 수정

max_tokens → max_completion_tokens
정책에 맞는 temperature 값 적용

✔ 빈 응답 안정화

1️⃣ 동일 모델 재시도
2️⃣ 재시도 실패 시 fallback 모델 적용

→ 단일 API 실패가 전체 실패로 이어지지 않도록 설계

6️⃣ CloudWatch 자동 복구 적용

며칠 뒤 다시 터지는 문제를 줄이기 위해
모니터링 + 자동 복구 구조를 추가했습니다.

6-1. CloudWatch Agent 설치

Amazon CloudWatch Agent 설치 후:

메모리
디스크 사용량

지표 수집

6-2. 상태 검사 경보 생성

시스템 상태 검사 실패 시 경보
복구 옵션 활성화

6-3. 자동 복구 설정

경보 설정에서 “복구” 체크

→ 시스템 상태 검사 실패 시 자동 복구 수행

즉,

서버가 터져도 자동으로 다시 올라오는 구조 확보

7️⃣ 최종 결과

✔ 인스턴스 안정화
✔ DB 연결 정상
✔ /users/me 정상 반환
✔ GPT 응답 정상
✔ CloudWatch 자동 복구 설정 완료

8️⃣ 이번 경험에서 배운 점

이번 장애는 단순한 버그가 아니었습니다.

인프라 불안정
DB 구조 불일치
외부 API 정책 변경
환경 설정 누락

이 모두가 겹친 복합 문제였습니다.

하지만 이를 통해:

✔ 인스턴스 레벨 복구 경험

✔ DB 스키마 정합성 관리 중요성 체감

✔ 외부 API 의존성 관리 필요성 학습

✔ 자동 복구 기반 운영 구조 구축

단순 “기능 구현자”가 아니라
운영 가능한 시스템을 설계하는 경험을 할 수 있었습니다.

[Aura_AI] [7편] GPT 호출 안정화 및 토큰 사용량 제한 설계

frontend-diary-log — Fri, 27 Feb 2026 15:12:42 +0900

[Aura_AI] [7편] GPT 호출 안정화 및 토큰 사용량 제한 설계

(운영 환경에서 비용 폭주를 막기 위한 구조 개선)

1️⃣ 왜 이 작업을 하게 되었는가

프로젝트를 실제 배포 후 운영하면서 단순 기능 구현 단계에서는 보이지 않던 문제가 드러났습니다.

✔ GPT 호출 비용 예측이 어렵다

✔ 사용자가 반복 요청을 보내면 호출이 무한히 누적될 수 있다

✔ 일부 요청에서 응답이 비어오는 현상이 발생한다

특히 가장 위험했던 부분은:

“호출이 제한되지 않으면 과금이 통제되지 않는다”는 점이었습니다.

기능은 정상 동작했지만,
운영 가능한 구조는 아니었습니다.

그래서 단순 기능 수정이 아니라
비용 통제 + 응답 안정성 개선 설계 작업을 진행했습니다.

2️⃣ 설계 목표

이번 작업의 목표는 명확했습니다.

1. 사용자 단위 일일 토큰 사용량 제한

→ 무한 호출 방지

2. 과도한 프롬프트 사전 차단

→ 비정상 입력 방어

3. 응답 실패 시 자동 복구 로직 추가

→ 빈 응답 대응

4. 모델 정책 변경에 유연한 구조 설계

→ 파라미터 충돌 방지

3️⃣ 사용자별 일일 토큰 제한 설계

3-1. 왜 사용자 단위인가?

전역 제한이 아니라 사용자 단위로 설계한 이유는:

특정 사용자의 과도한 사용이 전체 비용에 영향을 주지 않도록 하기 위함
향후 유료 플랜 확장 가능성 고려

3-2. 사용량 저장 구조

user_daily_usage 테이블 생성

def init_usage_db():
    # user_daily_usage 테이블 생성

구현 기능:

get_daily_usage(user_id) → 오늘 사용량 조회
add_daily_usage(user_id, tokens_in, tokens_out) → 사용량 누적

3-3. 환경변수 기반 제한

운영 중 유연하게 조정할 수 있도록 하드코딩하지 않았습니다.

max_prompt_tokens = int(os.getenv("MAX_REQUEST_PROMPT_TOKENS", "500"))
max_response_tokens = int(os.getenv("MAX_RESPONSE_TOKENS", "200"))
daily_limit = int(os.getenv("MAX_DAILY_TOKENS_PER_USER", "2000"))

환경 변수:

MAX_REQUEST_PROMPT_TOKENS=500
MAX_RESPONSE_TOKENS=200
MAX_DAILY_TOKENS_PER_USER=2000

→ 코드 수정 없이 운영 정책 조정 가능

3-4. 프롬프트 길이 사전 차단

if prompt_tokens > max_prompt_tokens:
    return '{"message":"요청이 너무 깁니다. 입력을 줄여 주세요."}'

모델 호출 이전에 차단하여
불필요한 비용 발생 방지

3-5. 일일 사용량 초과 차단

if projected > daily_limit:
    return '{"message":"오늘 사용 가능한 토큰을 초과했습니다. 내일 다시 시도해 주세요."}'

→ 무한 호출 구조 제거

4️⃣ GPT 응답 안정화 설계

운영 중 다음 문제가 발생했습니다.

일부 요청에서 응답이 빈 문자열로 반환됨
모델 정책 변경으로 400 오류 발생

4-1. 파라미터 정책 변경 대응

max_tokens → max_completion_tokens로 변경
모델 정책에 맞지 않는 temperature 값 수정

모델은 고정된 API가 아니라, 정책이 변할 수 있는 외부 의존성입니다.
이를 고려한 구조 수정이 필요했습니다.

4-2. 빈 응답 대응 로직

content = (response.choices[0].message.content or "").strip()

if not content:
    # 동일 모델 재시도

if not content:
    # gpt-4o-mini fallback

처리 흐름

1️⃣ 기본 모델: gpt-5-nano
2️⃣ 응답 비어있으면 재시도
3️⃣ 재시도 실패 시 gpt-4o-mini fallback

→ 단일 실패가 전체 실패로 이어지지 않도록 개선

5️⃣ 설계적으로 의미 있었던 부분

이번 작업은 단순 “기능 추가”가 아니었습니다.

✔ 비용 통제 구조 설계

✔ 실패를 전제로 한 복구 설계

✔ 외부 API 정책 변화 대응

✔ 환경변수 기반 운영 유연성 확보

기능 구현자에서
운영 환경을 고려하는 개발자로 사고가 확장된 작업이었습니다.

6️⃣ 적용 결과

✔ 무한 호출 구조 제거

✔ 과금 폭주 위험 감소

✔ 빈 응답 문제 완화

✔ 모델 변경에도 유연한 구조 확보

특히 사용자 단위 제한 설계는
향후 요금제 확장 시 그대로 활용 가능한 구조입니다.

7️⃣ 정리

이전까지의 프로젝트는 “잘 동작하는 서비스”였다면,
이번 개선 이후에는 “운영 가능한 서비스”에 가까워졌습니다.

GPT를 사용하는 서비스에서 중요한 것은
모델 호출 자체보다:

비용 통제
실패 복구
정책 변화 대응

이라는 것을 직접 경험하며 설계에 반영했습니다.

다음 편에서는
실제 서버가 반복적으로 불안정해졌던 원인과, 인스턴스를 재생성하고 자동 복구까지 구축한 과정을 정리하겠습니다.

[22편] 서버 반복적 오류 해결

frontend-diary-log — Fri, 27 Feb 2026 15:11:18 +0900

[Aura AI] 서버가 반복적으로 터진 이유와 전체 복구 과정 정리

(EC2 재생성, DB 재정비, GPT 안정화, CloudWatch 자동 복구 적용)

1️⃣ 장애 증상 요약

처음 발생한 증상은 단순 500 에러였습니다.
하지만 시간이 지날수록 서버 전체가 불안정해지는 문제가 반복되었습니다.

✔ 프론트엔드 증상

/api/proxy/users/me → 500 에러
로그인 후 마이페이지 정보 로드 실패
GPT 응답 생성 시
→ "응답을 생성하지 못했습니다." 반복

✔ 인프라 증상

EC2 상태 검사 2/3 통과
SSH 연결 간헐적 타임아웃
일정 시간이 지나면 서버가 다시 불안정해짐

즉,

프론트 → 백엔드 → DB → GPT 호출까지
전체 스택이 동시에 불안정한 상태였습니다.

2️⃣ 원인 분석 (복합 장애)

이번 장애는 단일 원인이 아니라, 여러 문제가 동시에 얽혀 있던 상황이었습니다.

2-1. EC2 인스턴스 상태 검사 2/3 문제

백엔드는 Amazon EC2 위에서 운영 중이었습니다.

상태 확인 결과:

Status Check: 2/3
Instance Status Check 실패

이로 인해:

SSH 접속 불안정
서버 프로세스 간헐적 중단
일정 시간 후 다시 장애 발생

즉, 기존 인스턴스 자체가 이미 불안정한 상태였습니다.

2-2. DB 연결 실패

백엔드 로그에서 다음 오류가 반복 확인되었습니다.

ECONNREFUSED
Can't connect to MySQL server

원인:

MySQL이 정상적으로 실행되지 않음
bind-address 문제
포트 차단 가능성
DB 초기화 미완료

2-3. DB 스키마 불일치

로그에서 다음 오류가 발견되었습니다.

Unknown column 'bio' in 'field list'

문제 상황:

코드에서는 bio, location, style_preference, profile_image 컬럼 사용
실제 DB에는 해당 컬럼이 존재하지 않음

결과적으로 /users/me 호출 시 500 에러 발생

2-4. GPT 호출 파라미터 오류

GPT 호출 시 다음 문제가 있었습니다.

max_tokens 파라미터가 새 모델 정책과 호환되지 않음
temperature 값 정책 불일치
일부 요청에서 응답이 빈 문자열로 내려오는 문제

결과:

400 에러 발생
응답 생성 실패 메시지 반복

3️⃣ 해결 과정 (실제 작업 순서)

3-1. 인스턴스 재생성

기존 EC2는 재사용하지 않기로 결정했습니다.

✔ 신규 인스턴스 생성

t3.small 생성
기존 인스턴스는 폐기
Elastic IP 재연결하여 IP 고정

→ IP 변경으로 인한 재발 방지

3-2. SSH 및 Git 환경 복구

✔ Host key mismatch 해결

~/.ssh/known_hosts 수정

✔ GitHub SSH 키 등록

새 인스턴스에 SSH 키 등록
git clone 정상 완료

3-3. 백엔드 재설치 및 서비스 등록

✔ Python 가상환경 생성

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

✔ systemd 서비스 등록

sudo nano /etc/systemd/system/aura-api.service

등록 후:

sudo systemctl daemon-reload
sudo systemctl enable aura-api
sudo systemctl start aura-api

→ 서버 재부팅 시 자동 실행

3-4. MySQL 설치 및 초기화

✔ MySQL 설치

sudo apt install mysql-server
sudo systemctl start mysql

✔ DB 및 계정 생성

CREATE DATABASE aura_ai;
CREATE USER 'aura_user'@'%' IDENTIFIED BY '비밀번호';
GRANT ALL PRIVILEGES ON aura_ai.* TO 'aura_user'@'%';
FLUSH PRIVILEGES;

3-5. MySQL 외부 연결 허용

✔ bind-address 수정

bind-address = 0.0.0.0

✔ 방화벽 오픈

sudo ufw allow 3306/tcp

✔ EC2 보안 그룹에서도 3306 허용

3-6. DB 스키마 불일치 해결

부족한 컬럼을 직접 추가했습니다.

ALTER TABLE users ADD COLUMN bio TEXT NULL;
ALTER TABLE users ADD COLUMN location VARCHAR(255) NULL;
ALTER TABLE users ADD COLUMN style_preference VARCHAR(255) NULL;
ALTER TABLE users ADD COLUMN profile_image VARCHAR(255) NULL;

이후 /users/me 500 에러 해결 완료

4️⃣ 프론트 / 프록시 연결 안정화

프론트는 Vercel 에 배포되어 있었습니다.

✔ 환경변수 수정

BACKEND_API_BASE_URL=http://54.116.93.58:8000

✔ /api/proxy/* 연결 확인

실제 연결 URL 로그 출력 추가
프록시 디버깅 가능하도록 개선

5️⃣ GPT 응답 오류 해결

5-1. 파라미터 호환성 수정

max_tokens → max_completion_tokens
temperature 정책 범위에 맞게 조정

5-2. 빈 응답 안정화

로직 개선:

응답이 빈 문자열이면 재시도
재시도 후에도 실패 시 gpt-4o-mini fallback

→ 단일 실패가 전체 실패로 이어지지 않도록 개선

6️⃣ 토큰 사용량 제한 기능 추가

사용자별 일일 토큰 제한
과도한 요청 사전 차단
사용량 추적 DB 테이블 생성

(해당 내용은 별도 정리 글과 동일)

7️⃣ CloudWatch 기반 자동 복구 설정

문제가 며칠 후 다시 터질 가능성을 줄이기 위해
모니터링 + 자동 복구를 적용했습니다.

7-1. CloudWatch Agent 설치

Amazon CloudWatch Agent 설치

메모리
디스크 사용량

지표 수집 설정

7-2. 경보 생성

시스템 상태 검사 실패 시 경보 생성
인스턴스 경보는 콘솔 오류로 1차 실패 (추후 재시도 가능)

7-3. 자동 복구 활성화

경보 설정에서 복구 옵션 활성화

→ 시스템 상태 검사 실패 시 자동 복구 수행

즉,

서버가 터져도 자동으로 다시 살아나는 구조 구축

8️⃣ 최종 결과

✔ 인스턴스 안정화
✔ DB 연결 정상화
✔ /users/me 정상 반환
✔ GPT 응답 정상 동작
✔ CloudWatch 자동 복구 준비 완료

9️⃣ 핵심 요약

이번 장애는 단순 서버 다운이 아니라:

EC2 인스턴스 불안정
DB 스키마 불일치
GPT 호출 파라미터 오류
인프라 설정 미정비

가 동시에 발생한 복합 장애였습니다.

저는:

인스턴스를 재생성하고
DB와 코드 스키마를 정확히 맞추고
GPT 호출을 안정화하고
CloudWatch 자동 복구까지 적용하여

단순 복구가 아닌 재발 방지 구조까지 구축했습니다.

[21편] 토큰 사용량 제한

frontend-diary-log — Fri, 27 Feb 2026 15:07:16 +0900

[Aura AI] 토큰 사용량 제한 / 응답 안정화 작업 정리

(gpt-5-nano, 일일 제한, 재시도 및 fallback 적용)

1️⃣ 문제 배경

최근 GPT 모델 호출 과정에서 다음과 같은 문제가 반복적으로 발생했습니다.

특정 요청에서 응답이 비어오는 현상
과도한 프롬프트 길이로 인한 비용 증가 위험
무제한 호출 가능 구조로 인한 과금 폭주 가능성

운영 환경에서 가장 위험한 요소는 예측 불가능한 비용 증가와 API 실패 누적이었습니다.

이에 따라:

사용자별 일일 토큰 제한
요청 길이 사전 차단
응답 비어올 경우 재시도 및 fallback 적용

을 통해 비용 통제 + 응답 안정화 구조를 구현했습니다.

2️⃣ 적용 목표

✅ 1. 사용자별 일일 토큰 제한 적용

과금 리스크 감소
무한 호출 방지

✅ 2. 프롬프트 길이 사전 차단

비정상적으로 긴 입력 방어
서버 리소스 보호

✅ 3. 응답 안정성 강화

응답이 비어올 경우 자동 재시도
재시도 실패 시 fallback 모델 사용

3️⃣ 변경 파일 및 주요 구현 내용

3-1. usage_service.py (신규)

역할

사용자별 일일 토큰 사용량 저장 및 조회

주요 구현

user_daily_usage 테이블 생성
get_daily_usage(user_id) → 오늘 사용량 조회
add_daily_usage(user_id, tokens_in, tokens_out) → 사용량 누적
서버 시작 시 테이블 자동 생성

def init_usage_db():
    # user_daily_usage 테이블 생성

사용자 단위로 일별 토큰 사용량을 DB에 저장하여 누적 관리하도록 설계했습니다.

3-2. gpt_service.py

역할

GPT 호출 + 토큰 제한 적용 + fallback 처리

환경변수 기반 제한값 적용

max_prompt_tokens = int(os.getenv("MAX_REQUEST_PROMPT_TOKENS", "500"))
max_response_tokens = int(os.getenv("MAX_RESPONSE_TOKENS", "200"))
daily_limit = int(os.getenv("MAX_DAILY_TOKENS_PER_USER", "2000"))

운영 환경에서 코드 수정 없이 조정 가능하도록 환경변수 기반 제어 구조로 설계했습니다.

프롬프트 길이 초과 시 즉시 차단

if prompt_tokens > max_prompt_tokens:
    return '{"message":"요청이 너무 깁니다. 입력을 줄여 주세요."}'

→ 불필요한 모델 호출 자체를 방지

일일 토큰 제한 초과 시 차단

if projected > daily_limit:
    return '{"message":"오늘 사용 가능한 토큰을 초과했습니다. 내일 다시 시도해 주세요."}'

→ 비용 통제 장치

응답 안정화 로직

content = (response.choices[0].message.content or "").strip()

if not content:
    logging.warning("GPT empty content; retrying without response_format")
    # gpt-5-nano 재시도

if not content:
    logging.warning("GPT empty content after retry; falling back to gpt-4o-mini")
    # gpt-4o-mini fallback

처리 흐름

기본 모델: gpt-5-nano
응답이 비어있으면 → 동일 모델 재시도
재시도 실패 → gpt-4o-mini fallback

단일 실패가 전체 기능 실패로 이어지지 않도록 설계했습니다.

3-3. chats.py

역할

채팅 시작 시 토큰 사용량 DB 초기화

from services.usage_service import init_usage_db

init_usage_db()

→ 서버 기동 시 자동으로 사용량 테이블 생성

3-4. summary_service.py

요약 모델을 통일했습니다.

model="gpt-5-nano"

→ 모델 일관성 확보 및 비용 관리

3-5. token_utils.py

기본 모델 상수화

DEFAULT_MODEL = "gpt-5-nano"

→ 모델 변경 시 유지보수 용이

4️⃣ 환경변수 설정 예시

.env 또는 Vercel 환경 변수에 다음 값 설정

MAX_REQUEST_PROMPT_TOKENS=500
MAX_RESPONSE_TOKENS=200
MAX_DAILY_TOKENS_PER_USER=2000

운영 상황에 따라 유연하게 조정 가능하도록 구성했습니다.

5️⃣ 적용 결과

✔ 무한 호출 및 과금 폭주 위험 감소

✔ 과도한 프롬프트 사전 차단

✔ 응답 비어오는 현상 완화

✔ fallback 모델 적용으로 안정성 향상

특히, “응답이 가끔 비어오는 문제”를
재시도 + 모델 대체 구조로 완화한 것이 가장 체감 효과가 컸습니다.

6️⃣ 기술적으로 의미 있었던 부분

이번 작업은 단순 기능 추가가 아니라 다음을 설계한 작업이었습니다.

비용 통제 장치 설계
실패를 전제로 한 복구 구조 설계
환경변수 기반 운영 유연성 확보
모델 변경 가능성을 고려한 구조화

즉,

기능 구현이 아니라 “운영 안정성 설계”에 초점을 둔 작업이었습니다.

정리

이번 개선을 통해:

토큰 사용량을 안전하게 제한하고
GPT 응답 안정성을 높이며
운영 환경에서 과금 리스크를 줄일 수 있는 구조를 구축했습니다.

실제 운영 환경에서 발생할 수 있는
비용 폭주, 무한 호출, 응답 실패를 방지하는 안정화 작업이었습니다.

[Aura_Ai] [7편] 서버오류 해결

frontend-diary-log — Wed, 25 Feb 2026 10:13:02 +0900

운영 중 서비스 장애 대응 경험 정리 (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 에러

핵심 교훈은 이것입니다.

운영 환경에서는 “코드보다 인프라가 먼저 무너질 수 있다.”

그리고 저는 이 경험을 통해
문제 해결 능력뿐 아니라, 구조 개선 역량까지 확장할 수 있었습니다.

[20편] 배포 후 오류 수정

frontend-diary-log — Wed, 25 Feb 2026 10:06:33 +0900

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

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

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

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. 환경변수 불일치로 인한 연쇄 장애

결과적으로:

EC2는 새 IP로 실행 중
Vercel은 이전 IP로 요청
요청이 도달하지 않음
Connect Timeout 발생
모든 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️⃣ 최종 원인 정리

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

EC2 내부 상태 이상 발생
Stop/Start 수행
퍼블릭 IP 변경
환경변수 갱신 누락
Vercel 프록시 연결 실패
모든 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 적용

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

필요하시다면,

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

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

[Aura_Ai] [6편] 프로젝트 배포

frontend-diary-log — Fri, 13 Feb 2026 17:58:52 +0900

[프로젝트 배포 후기] Next.js + FastAPI + MySQL 멀티 환경 배포 설계 & 장애 대응 기록

안녕하세요.
이번 글에서는 Aura AI 프로젝트를 실제 운영 가능한 구조로 배포하면서 설계한 아키텍처와, 배포 중 발생한 장애를 해결한 과정을 실무 관점에서 정리했습니다.

단순히 *“배포 성공”*이 아니라,

어떤 구조를 선택했는지
왜 그 선택이 합리적이었는지
실제 어떤 문제가 발생했는지
어떻게 해결했는지

위 4가지를 중심으로 작성했습니다.

실서비스 운영을 가정한 배포/운영/장애 대응 경험 기록이라고 보시면 됩니다.

1️⃣ 배포 구조 개요 (실무 기준 아키텍처)

사용 스택

Frontend

Next.js
NextAuth.js
배포: Vercel

Backend

FastAPI + Uvicorn
배포: Amazon Web Services EC2 (Ubuntu)

Database

MySQL
EC2 내부 localhost 운영

전체 아키텍처

Browser
   ↓
Vercel (Next.js)
   ↓
Proxy API (/api/proxy)
   ↓
EC2 FastAPI
   ↓
MySQL (localhost)

이 구조를 선택한 이유

단순히 “편해서”가 아니라 운영 관점에서 다음 기준을 만족시키기 위해 선택했습니다.

✅ Vercel

HTTPS 기본 제공
CI/CD 자동화
프론트 배포 속도 빠름

✅ EC2

장시간 실행되는 백엔드/DB 운영에 적합
서버 리소스 직접 제어 가능
서버리스 대비 안정적

✅ 프론트/백엔드 분리

확장성 ↑
장애 격리 가능
유지보수 편리

실무에서 가장 흔히 사용하는 “프론트 서버리스 + 백엔드 서버 분리” 구조를 그대로 채택했습니다.

2️⃣ 실제 배포 중 발생한 핵심 문제 & 해결 과정

문제 1️⃣ Mixed Content 오류

❌ 증상

로그인은 성공
그러나 사용자 정보 API 호출 실패
브라우저 콘솔: Mixed Content 에러

❌ 원인

Vercel → HTTPS
EC2 → HTTP

브라우저 정책상
HTTPS 페이지에서 HTTP 요청은 보안상 차단됩니다.

✅ 해결 방법

Vercel 내부 Proxy API 도입

/api/proxy/*

구조 변경:

Browser → HTTPS → Vercel → HTTP → EC2

브라우저는 HTTPS만 인식하고,
Vercel이 내부에서 백엔드로 요청을 전달하도록 설계했습니다.

✅ 결과

✔ Mixed Content 완전 해결
✔ 프론트 API 주소 통일
✔ 서버 주소 변경 시 프록시만 수정하면 됨

보안 + 유지보수성 동시 개선

문제 2️⃣ Vercel에서 MySQL 직접 접속 실패

❌ 증상

ECONNREFUSED 127.0.0.1:3306

NextAuth 로그인 실패

❌ 원인

Vercel은 서버리스 환경이므로

장기 DB 커넥션 유지 불가
내부 네트워크 접근 불가
로컬 MySQL 직접 연결 불가

즉, 구조적으로 DB 직결이 불가능

✅ 해결 방법

역할 재설계

담당역할

Vercel	인증/프록시
FastAPI	DB 작업 전담

회원가입/유저 CRUD를 전부 백엔드로 이동했습니다.

✅ 결과

✔ 로그인/회원가입 정상 동작
✔ DB 접근 로직 백엔드 집중
✔ 보안/확장성/유지보수성 개선

아키텍처 분리의 필요성을 체감한 케이스

문제 3️⃣ EC2 SSH 접속 불능

❌ 증상

SSH 접속 후 화면 멈춤

❌ 원인

SSH 데몬 응답 불가
네트워크 일시 장애

✅ 해결

EC2 콘솔 → Reboot

필요 시:

systemctl restart ssh

✅ 결과

즉시 복구

운영 환경에서 재부팅은 가장 빠른 해결책이라는 점을 경험

3️⃣ 배포 안정성 확보 — systemd 도입

초기에는 다음 방식으로 실행했습니다.

nohup uvicorn ...

문제점

터미널 종료 시 불안정
재부팅 시 자동 실행 안 됨
운영 환경에 부적합

✅ 개선 → systemd 서비스 등록

서버 부팅 시 자동 실행
장애 시 자동 재시작
SSH 종료와 무관

운영 서버 필수 설정

효과

✔ 항상 실행 상태 유지
✔ 다운타임 최소화
✔ 실서비스 수준 안정성 확보

4️⃣ 배포 과정에서 수정한 핵심 코드

✅ 프록시 라우트 (route.ts)

Mixed Content 해결
서버측 통신 브릿지

✅ apiClient.ts

API 주소 /api/proxy 통일
FormData 업로드 자동 처리

✅ 회원가입 API

Vercel → FastAPI 프록시 구조

✅ Swagger docs 대응

openapi.json 프록시 처리

“프론트는 통신만, 비즈니스 로직은 백엔드” 원칙 확립

5️⃣ 최종 배포 체크리스트

Vercel

NEXT_PUBLIC_API_BASE_URL=/api/proxy

EC2

systemctl status aura-api → active
ss -tlnp | grep 8000 → LISTEN

기능 테스트

회원가입
소셜 로그인
사용자 정보 조회
채팅 API

✅ 마무리 — 실무 관점에서 배운 점

이번 배포에서 가장 중요했던 것은 **“단순 실행”이 아니라 “운영 가능한 구조 설계”**였습니다.

✔ 핵심 개선 사항

Mixed Content 해결
서버리스 ↔ DB 구조 분리
systemd 자동 실행
장애 복구 프로세스 확보

결론

단순 구현이 아닌
실서비스 운영을 고려한 배포/아키텍처 설계 경험을 쌓을 수 있었습니다.

개인 프로젝트였지만,
실무 환경과 동일한 방식으로 설계/운영/장애 대응까지 진행했다는 점이 가장 큰 성과라고 생각합니다.

[19편] part 4 배포 배포 명령어/의미 + 오류 로그 대응표 + 체크리스트

frontend-diary-log — Fri, 13 Feb 2026 17:53:42 +0900

Aura AI 배포 기록 (Part 4)

배포 명령어 정리 · 의미 설명 · 장애 대응 매뉴얼 · 운영 체크리스트

이번 글은 FastAPI + Next.js + Vercel + Amazon Web Services EC2 환경에서 실제 운영 시 사용하는 배포 명령어와 장애 대응 방법을 한 번에 정리한 실전 매뉴얼입니다.

서버 운영을 하다 보면 매번 검색하게 되는 것들만 모았습니다.

접속 명령어
실행/재시작/백그라운드 실행
systemd 영구 실행
에러 대응법
최종 점검 체크리스트

이 글 하나면 운영/복구/재배포 전부 가능합니다.

✅ 1️⃣ 배포용 핵심 명령어 + 의미 정리

EC2 서버 접속

ssh -i "C:\Users\dddd3\aura_ai\aura-key.pem" ubuntu@51.21.202.235

의미

EC2 인스턴스 접속
PEM 키 기반 인증 (비밀번호 대신 사용)

핵심 포인트

✔ PEM 없으면 접속 불가
✔ 경로는 반드시 따옴표 사용

백엔드 폴더 이동

cd ~/aura_ai/backend

의미

FastAPI 프로젝트 위치로 이동
uvicorn 실행 기준 디렉토리

가상환경 활성화

source .venv/bin/activate

의미

Python 가상환경 활성화
패키지가 해당 환경에서만 동작

이유

✔ 시스템 Python 오염 방지
✔ 의존성 충돌 방지

패키지 설치

pip install -r requirements.txt

의미

프로젝트 의존성 전체 설치

언제 실행?

최초 배포
requirements 수정 후
서버 재구성 후

서버 실행 (임시 실행)

uvicorn main:app --host 0.0.0.0 --port 8000

의미

FastAPI 서버 실행
0.0.0.0 → 외부 접속 허용
8000 포트 사용

특징

❌ 터미널 종료 시 서버 종료

테스트용/디버깅용

서버 실행 (백그라운드 임시)

nohup uvicorn main:app --host 0.0.0.0 --port 8000 > uvicorn.log 2>&1 &

의미

터미널 닫아도 유지
로그를 uvicorn.log에 저장

특징

✔ 간단한 임시 운영 가능
❌ 재부팅 시 자동 시작 안 됨

임시 운영 전용

프로세스 종료

pkill -f uvicorn

의미

실행 중인 uvicorn 프로세스 전체 종료

사용 상황

포트 충돌
서버 재시작 전
좀비 프로세스 제거

⭐ 권장 방식 — systemd (영구 실행)

운영 서버는 반드시 systemd 사용 권장합니다.

systemd 서비스 등록

sudo tee /etc/systemd/system/aura-api.service > /dev/null <<'EOF'
[Unit]
Description=Aura FastAPI (Uvicorn)
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/aura_ai/backend
EnvironmentFile=/home/ubuntu/aura_ai/backend/.env
ExecStart=/home/ubuntu/aura_ai/backend/.venv/bin/uvicorn main:app --host 0.0.0.0 --port 8000
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target
EOF

의미

핵심 기능

✔ 서버 부팅 시 자동 실행
✔ 오류 발생 시 자동 재시작
✔ SSH 종료와 무관하게 유지

옵션 설명

옵션의미

WorkingDirectory	프로젝트 위치
EnvironmentFile	.env 자동 로드
ExecStart	서버 실행 명령
Restart=always	항상 재시작
RestartSec	재시작 딜레이

systemd 적용/실행

sudo systemctl daemon-reload
sudo systemctl enable aura-api
sudo systemctl restart aura-api

의미

새 서비스 등록 적용
부팅 시 자동 실행 설정
즉시 서버 실행

실행 상태 확인

sudo systemctl status aura-api --no-pager

의미

서비스 실행 여부 확인

정상 상태

active (running)

포트 리스닝 확인

sudo ss -tlnp | grep 8000

의미

8000 포트가 열렸는지 확인
uvicorn 실제 실행 여부 체크

✅ 2️⃣ 오류 로그 대응표 (실전 트러블슈팅)

운영 중 가장 많이 겪은 오류만 모았습니다.

❌ Mixed Content 오류

증상

HTTPS 페이지에서 HTTP API 호출 시 차단

해결

✔ /api/proxy 적용
✔ 프론트는 프록시 경유만 사용
✔ Vercel 내부 HTTPS 브릿지 활용

❌ ECONNREFUSED 127.0.0.1:3306

증상

MySQL 접속 실패

원인

Vercel 서버리스 → DB 직접 연결 불가

해결

✔ DB 접근은 전부 FastAPI 로 이동
✔ Vercel은 프록시만 담당

❌ Form data requires python-multipart

증상

파일 업로드 시 서버 실행 실패

해결

pip install python-multipart

❌ ModuleNotFoundError: bcrypt

증상

회원가입 시 비밀번호 해시 오류

해결

pip install bcrypt

❌ 이메일 형식 오류 (모든 이메일 실패)

원인

정규식 이중 이스케이프

해결

EMAIL_REGEX = re.compile(r"^[^\s@]+@[^\s@]+\.[^\s@]+$")

❌ SSH 접속 멈춤

증상

접속 후 아무 반응 없음

해결

✔ EC2 콘솔 → Reboot
✔ 또는 SSH 재시작

sudo systemctl restart ssh

✅ 3️⃣ 배포 최종 체크리스트 (운영 전 필수)

배포 완료 후 반드시 확인합니다.

Vercel 환경 변수

NEXT_PUBLIC_API_BASE_URL=/api/proxy
백엔드 서버: 51.21.202.235:8000

EC2 상태 확인

systemctl status aura-api

active (running)

ss -tlnp | grep 8000

uvicorn 리스닝 확인

기능 테스트

✔ 회원가입 성공
✔ 소셜 로그인 성공
✔ /users/me 정상
✔ /sessions 정상

✅ Part 4 전체 요약

이번 파트에서 정리한 내용

✔ 서버 접속/실행 명령어 정리
✔ systemd 영구 실행 설정
✔ 실제 발생 오류 대응법
✔ 운영 체크리스트

최종 결론

운영 환경에서는 반드시

systemd 사용
프록시 구조 유지
의존성 관리
체크리스트 점검

이 4가지를 습관화하면 장애가 거의 발생하지 않습니다.

[19편] part 3 배포 백엔드/회원가입/정규식/의존성 변경 상세

frontend-diary-log — Fri, 13 Feb 2026 17:52:25 +0900

Aura AI 배포 기록 (Part 3)

백엔드 회원가입 API · 정규식 오류 · 의존성 · 서비스 레이어 변경 총정리

이번 글은 FastAPI 기반 백엔드에서 회원가입 기능을 직접 구현하면서 발생한 문제들과 구조 개선 과정을 정리한 기록입니다.

Part 1에서는 서버/배포/운영,
Part 2에서는 프론트/프록시 구조를 다뤘다면,

Part 3는 “백엔드 비즈니스 로직 설계 + 보안 + 검증 + DB 처리” 핵심 파트입니다.

특히 다음 내용을 중점적으로 다룹니다.

회원가입 API 신규 구현
정규식 검증 오류 해결
user_service 리팩토링
requirements 의존성 추가 이유
전체 회원가입 처리 흐름

✅ Part 3 핵심 목표

해결 과제

Vercel에서 DB 직접 접근 불가
프론트에서 회원가입 처리 시 보안 취약
검증/암호화/저장 로직 분산 문제

목표 구조

✔ 회원가입 로직 100% 백엔드 처리
✔ 입력 검증 + 암호화 + DB 저장 일원화
✔ OAuth/일반 가입 스키마 통합
✔ 운영 안정성 확보

1️⃣ auth.py — 회원가입 API 추가

❓ 왜 추가했는가?

기존 문제

Vercel 서버리스 환경은 MySQL 직접 연결 불가
프론트에서 DB 로직 처리 시 보안 위험
데이터 검증 누락 가능성

즉,

프론트 → DB 직접 접근 ❌ (구조적으로 불가능 + 위험)

✅ 해결 전략

회원가입을 전부 백엔드에서 처리

검증
암호화
DB 저장

모든 책임을 서버로 이동

✅ 추가된 핵심 구조

@router.post("/signup")
def signup(body: SignupRequest):
    ...

의미

/signup POST JSON 요청 수신
서버에서 입력값 직접 검증
안전하게 DB 저장

회원가입의 단일 진입점(Single Entry Point)

2️⃣ 입력값 검증 로직 (정규식)

✅ 적용된 검증 규칙

EMAIL_REGEX = re.compile(r"^[^\s@]+@[^\s@]+\.[^\s@]+$")
PHONE_REGEX = re.compile(r"^01[016789]-?\d{3,4}-?\d{4}$")
PASSWORD_REGEX = re.compile(r"^(?=.*[A-Za-z])(?=.*\d).{8,}$")

각 정규식 의미

이메일

user@domain.com 형식만 허용

전화번호

010-1234-5678
01012345678
둘 다 허용

비밀번호

8자 이상 + 영문 포함 + 숫자 포함 필수

✅ 효과

✔ 서버 단에서 강력한 입력 검증
✔ 잘못된 데이터 DB 유입 차단
✔ 보안 강화

3️⃣ 정규식 오류 문제 (이메일 검증 실패)

❌ 발생한 이상 현상

정상 이메일도 실패

asdf@naver.com → "이메일 형식이 올바르지 않습니다"

❌ 원인 분석

정규식이 이중 이스케이프 상태로 저장됨

잘못된 코드

EMAIL_REGEX = re.compile(r"^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$")

❗ 문제점

\\s

는

공백 문자 ❌
문자 "" + "s" 로 인식

즉, 정규식이 완전히 깨진 상태

✅ 수정 후 (정상)

EMAIL_REGEX = re.compile(r"^[^\s@]+@[^\s@]+\.[^\s@]+$")
PHONE_REGEX = re.compile(r"^01[016789]-?\d{3,4}-?\d{4}$")
PASSWORD_REGEX = re.compile(r"^(?=.*[A-Za-z])(?=.*\d).{8,}$")

✅ 수정 이유

핵심 포인트

Raw string(r"")에서는
\s, \. 그대로 사용해야 함
이중 이스케이프 불필요

원인 추정

JSON 직렬화
복붙 과정
문자열 escape 중복

으로 텍스트가 깨진 것으로 판단

✅ 결과

✔ 이메일 검증 정상 동작
✔ 회원가입 성공

4️⃣ user_service.py 변경

❓ 왜 변경했는가?

기존 구조는:

OAuth 로그인 시에만 INSERT

즉,

일반 회원가입 로직이 존재하지 않음

✅ 추가된 핵심 기능

def create_user(...):
    # 중복 이메일/닉네임 확인
    # 비밀번호 해시 저장
    # provider = "credentials"

동작 의미

1️⃣ 중복 검사

이메일 중복 체크
닉네임 중복 체크

2️⃣ 비밀번호 암호화

평문 저장 ❌
해시 저장 ⭕

3️⃣ provider 설정

credentials

일반 가입 구분

✅ 구조적 장점

⭐ 가장 중요한 포인트

OAuth / 일반 가입 모두 하나의 users 테이블 사용

효과

✔ 스키마 통일
✔ 유지보수 쉬움
✔ 인증 방식 추가 쉬움
✔ DB 단순화

5️⃣ requirements.txt 변경 (의존성 추가)

✅ 추가된 패키지

bcrypt
python-multipart

각각 왜 필요한가?

bcrypt

비밀번호 해시 암호화

password → hash → DB 저장

보안 필수 요소

python-multipart

파일 업로드 처리용

프로필 이미지
FormData 요청

에서 필수

❌ 실제 발생한 에러

bcrypt 누락

ModuleNotFoundError: No module named 'bcrypt'

multipart 누락

Form data requires "python-multipart"

✅ 해결

pip install -r requirements.txt

교훈

FastAPI + 파일 업로드 = python-multipart 거의 필수

6️⃣ main.py 변경

❓ 왜 수정했는가?

라우터를 만들어도 등록하지 않으면 동작하지 않습니다.

✅ 추가 코드

from routers.auth import router as auth_router
app.include_router(auth_router)

의미

auth.py 연결
/signup 엔드포인트 실제 활성화

7️⃣ 회원가입 전체 흐름 정리

✅ 최종 동작 순서

① 프론트

/api/signup 호출

② Vercel

/signup → EC2 프록시

③ FastAPI auth.py

입력 검증
정규식 검사
bcrypt 해시

④ user_service.py

중복 검사
DB INSERT

⑤ 성공 응답

{ "message": "회원가입 완료" }

8️⃣ 왜 이 구조가 가장 효율적인가?

❌ 프론트 처리 방식

보안 취약
로직 노출
DB 직접 접근 위험
유지보수 지옥

✅ 백엔드 처리 방식 (현재 구조)

✔ 보안 강화
✔ 검증/저장 통합
✔ 비즈니스 로직 집중
✔ OAuth/일반 가입 통합
✔ 확장성 ↑

결론

회원가입은 반드시 서버 책임으로 처리하는 것이 정석 아키텍처

✅ Part 3 전체 요약

이번 파트에서 수행한 작업

✔ auth.py 회원가입 API 구현
✔ 정규식 검증 추가
✔ 이중 이스케이프 버그 수정
✔ user_service 생성 로직 추가
✔ bcrypt / multipart 의존성 추가
✔ 라우터 등록

최종 결과

안전한 회원가입 시스템 구축
비밀번호 암호화 완료
OAuth/일반 가입 통합
운영 안정성 확보

[19편] part 2 배포 프론트/프록시 구조 변경 상세 정리

frontend-diary-log — Fri, 13 Feb 2026 17:50:43 +0900

Aura AI 배포 기록 (Part 2)

프론트 구조 & Vercel 프록시 아키텍처 변경 상세 정리

이 글은 Next.js + NextAuth.js + FastAPI + Vercel + Amazon Web Services EC2 환경에서
프론트엔드 통신 구조를 개선하며 Mixed Content 문제를 완전히 해결한 과정을 정리한 실전 기록입니다.

Part 1이 서버/배포/운영 중심이었다면,
이번 글은 프론트 코드 레벨 구조 개선 + 프록시 설계 이유 + 실제 수정 내역을 다룹니다.

✅ Part 2 핵심 목표

해결하고자 했던 문제

브라우저에서 HTTP 백엔드 직접 호출 시 Mixed Content 차단 발생
일부 API/업로드/Swagger/docs 동작 실패
API 주소가 여기저기 흩어져 유지보수 어려움

최종 목표

✔ 모든 요청을 HTTPS 내부에서만 처리
✔ 브라우저 → Vercel → EC2 구조 확립
✔ API 호출 방식 통일
✔ 유지보수성 향상

1️⃣ route.ts (프록시 라우트) 추가

❓ 왜 추가했는가?

브라우저 보안 정책 때문입니다.

기존 구조

브라우저 → http://EC2:8000 직접 호출

이 경우:

Mixed Content 차단 발생 ❌

브라우저는 HTTPS 페이지에서 HTTP 요청을 보안상 차단합니다.

즉, 구조적으로 직접 호출은 불가능합니다.

✅ 해결 전략

Vercel 내부 프록시 생성

/api/proxy/*

구조 변경:

브라우저 → Vercel(HTTPS) → EC2(HTTP)

서버 ↔ 서버 통신은 Mixed Content 제한이 없습니다.

❓ 무슨 의미인가?

/api/proxy/* 는

모든 요청을 백엔드로 그대로 전달하는 통신 브릿지

역할을 합니다.

구체적인 동작 흐름

예시

GET /api/proxy/users/me

1️⃣ 클라이언트 → Vercel
2️⃣ Vercel → http://EC2:8000/users/me
3️⃣ 응답 그대로 반환

브라우저는 HTTPS만 보게 됩니다.

✅ 장점

✔ Mixed Content 완전 차단
✔ 백엔드 주소 숨김 (보안 ↑)
✔ API 주소 통일
✔ 서버 주소 변경 시 프록시만 수정하면 됨

2️⃣ apiClient.ts 수정

❓ 왜 수정했는가?

프록시를 도입했다면
모든 API 호출이 반드시 /api/proxy를 타야 합니다.

하지만 기존 코드에는:

직접 http://IP 호출
fetch/axios 혼용
업로드 시 헤더 깨짐

문제가 있었습니다.

✅ 변경 내용

1. baseURL 통일

baseURL: "/api/proxy"

이제 프론트는 백엔드 주소를 전혀 모릅니다.

2. FormData 처리 방식 개선

기존:

headers: { "Content-Type": "multipart/form-data" }

문제:

브라우저가 boundary 자동 생성 못함
파일 업로드 실패

수정:

FormData일 경우 Content-Type 설정 제거

브라우저가 자동으로 처리하도록 위임

✅ 결과

✔ JSON 요청 정상
✔ 파일 업로드 정상
✔ 헤더 오류 제거
✔ 코드 일관성 확보

핵심 효과

모든 통신을 apiFetch 하나로 통일

유지보수 난이도가 크게 감소했습니다.

3️⃣ Swagger docs(/docs) 프록시 처리

❓ 왜 문제였는가?

백엔드 Swagger는 내부적으로:

/openapi.json

을 호출합니다.

하지만:

/api/proxy/docs

로 접속하면

openapi.json → Vercel 기준 경로 → 404

발생

✅ 해결 방법

/openapi.json도 프록시 통과

즉,

모든 하위 경로를 그대로 전달하도록 route.ts 확장

✅ 결과

/api/proxy/docs

에서도 Swagger UI 정상 표시

✔ 개발/테스트 환경 유지 가능
✔ 문서 접근성 확보

4️⃣ /api/signup 프록시 처리

❓ 왜 수정했는가?

회원가입은 DB 접근이 필요합니다.

하지만 Vercel 서버리스 환경은 MySQL 직접 연결 불가입니다.

즉:

Vercel → MySQL ❌

✅ 해결 전략

회원가입 로직을 전부 FastAPI 로 이동

Vercel은 단순 전달만 수행

동작 흐름

/api/signup → Vercel → EC2 /signup

✅ 장점

✔ DB 접근 안정성 확보
✔ 인증/비즈니스 로직 분리
✔ 프론트 코드는 변경 없음

5️⃣ LocationModal.tsx 수정

❓ 기존 문제

API 직접 호출 (HTTP)
Mixed Content 위험
한글/문자열 깨짐
응답 처리 불안정

✅ 변경 내용

1. apiFetch 사용

직접 호출 → apiFetch

즉, 프록시 경유

2. 깨진 텍스트 복구

한글 인코딩 문제 해결
UI 문구 정리

3. 검색 결과 처리 안정화

에러 핸들링 추가
빈 결과 처리 개선

✅ 효과

✔ Mixed Content 예방
✔ UI 정상화
✔ 유지보수 쉬움

6️⃣ ProfileSection.tsx 수정

❓ 기존 문제

이미지 업로드/삭제 → HTTP 직접 호출
Mixed Content 발생
문자열 깨짐
UX 혼란

✅ 변경 내용

1. 업로드/삭제 → apiFetch 통일

2. 이미지 URL도 프록시 기반

/api/proxy/uploads/...

3. 텍스트/문구 정리

✅ 결과

✔ HTTPS 환경 정상 동작
✔ 파일 업로드 안정성 확보
✔ 사용자 경험 개선

7️⃣ 왜 프록시 구조가 가장 효율적인가?

❌ 대안 1

EC2 직접 HTTPS 구축

Nginx 설정
Let's Encrypt + Certbot
도메인 구매
SSL 관리

단점

설정 복잡
유지보수 비용 증가
인증서 갱신 관리 필요

✅ 현재 방식 (Vercel Proxy)

장점

✔ 별도 도메인 불필요
✔ SSL 자동 처리
✔ 구현 매우 간단
✔ 유지보수 최소화
✔ 개발 속도 빠름

결론

구현 난이도 대비 효과가 가장 좋은 선택

스타트업/개인 프로젝트에 최적의 구조입니다.

✅ Part 2 전체 요약

이번 파트에서 수행한 작업

✔ Vercel Proxy Route 도입
✔ 모든 API 호출 apiFetch 통일
✔ Mixed Content 완전 해결
✔ Swagger 문서 프록시 처리
✔ 회원가입 API 백엔드 이관
✔ Location/Profile 컴포넌트 안정화

결과

HTTPS 환경 100% 호환
프론트 코드 단순화
유지보수성 향상
배포 안정성 확보