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

🚀 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% 호환
• 프론트 코드 단순화
• 유지보수성 향상
• 배포 안정성 확보