프런트엔드가 index.html을 직접 서빙하도록 구조 전환

이 게시물은 백엔드 리포지터리에서 관리되던 index.html과 정적 리소스 책임을 프런트엔드로 이관해, 프런트엔드 독립 배포와 성능/운영 개선을 이룬 과정을 설명합니다.

기존 구조의 문제

• 프런트엔드는 빌드된 JS를 S3에 올리고 백엔드 템플릿에 “연결”만 하는 역할이라 index.html 수정이 어려웠음
• 정적 리소스 책임 경계가 모호해 장애 원인 파악과 커뮤니케이션 비용이 증가
• 백엔드 템플릿에 JS 경로를 하드코딩해 contenthash 기반 캐시 전략을 적용하기 어려워 캐시 불일치가 발생

이관 설계와 구현

구조 선택

• CloudFront 경로 기반 라우팅(1안)은 보안/비용/로그 복잡도 이슈로 배제
• 프런트/백엔드 도메인 완전 분리(2안)로 WAF/Shield 정책 분리, 장애 격리, 배포 독립성을 확보

배포·라우팅·검증

• S3+CloudFront로 정적 배포 파이프라인을 만들고 캐시 무효화를 포함한 자동화를 구성
• MPA 특성상 Lambda@Edge로 요청 경로에 맞는 /{path}/index.html을 찾아 반환
• 도메인 분리로 인한 SameSite 쿠키 문제와 WAF 규칙 문제를 해결했고, 위험을 줄이기 위해 내부→외부 순의 분리 배포로 안정성을 검증

결과

• 프런트엔드 독립 배포로 배포 주기 단축 및 책임 분리 명확화
• 로딩 시간: 내부 어드민 72% 감소, 외부 어드민 77% 감소 / Lighthouse 점수: 내부 71→87, 외부 58→87
• 백엔드는 불필요한 인증/필터 로직과 프런트 관련 코드를 제거(필터 20→10, 약 400개 파일·12만 라인 감소)하고 API/인증 구조를 정리