왜 Next.js와 Spring Boot를 선택했는가: 솔로 SaaS 프로젝트 기술 스택 선택 이유

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

웹 개발

대상자

- 대상자: 소규모 SaaS 개발자, 인디 해커, 프론트엔드/백엔드 혼합 아키텍처 경험자

- 난이도: 중급~고급 (프레임워크 통합, 보안 설정, 인프라 관리 기술 필요)

핵심 요약

• Next.js + Spring Boot 혼합 아키텍처 선택 이유:
• 보안 강화: 클라이언트에서 직접 API 호출 없이 Next.js 서버 컴포넌트를 통해 CORS 문제 해결
• 모듈화 가능성: Spring Boot Starter로 핵심 로직 재사용
• 구조적 안정성: Spring Security를 통한 산업 수준 보안 적용
• 기술적 제약:
• JWT 쿠키 설정 문제: Spring Boot에서 직접 설정 불가, Next.js API 라우트를 통해 중간 프록시 필요
• Server-Sent Events (SSE) 지원 제한: 복잡한 처리 필요
• 인프라 관리: Terraform을 사용한 AWS Fargate 배포, VPC 엔드포인트 비용 최적화

섹션별 세부 요약

1. 기술 스택 선택 배경

• Next.js + Spring Boot 선택 이유:
• 타입 강제와 구조화된 프레임워크 필요성 (Java/Python 중 Java 선택)
• RESTful API 정의와 클라우드 통합 우위 (Spring Boot의 장점)
• 혼합 아키텍처 장점:
• 전체 API 호출 경로 숨기기 (브라우저 네트워크 탭에서 노출 방지)
• 서버 측 실행만 가능 (클라이언트 정보 유출 방지)

2. API 호출 흐름 및 보안

• Next.js 서버 컴포넌트를 통한 API 중개:
• Spring Boot API 직접 호출 대신 Next.js를 중간 매개체로 사용
• 쿠키/헤더 관리 복잡성 증가 (JWT 설정 예외 처리 필요)
• 보안 강화:
• Spring Security를 통한 인증/인가 강화
• CORS 문제 해결 (클라이언트-서버 간 직접 통신 제거)

3. 인프라 및 배포 전략

• Terraform 활용:
• 개발/프로덕션 환경 일관성 유지
• Fargate 작업을 공개 서브넷에 배치 (VPC 엔드포인트 비용 최소화)
• 배포 과정의 어려움:
• AWS SAA 인증자라도 인프라 관리 복잡성 존재
• MVP 단계에서 비용 최적화를 위한 선택

4. 경험과 교훈

• 기술적 교훈:
• 아키텍처 고민 강제 (Spring Boot의 구조적 제약)
• 모듈화 기술 (Spring Boot Starter로 재사용성 확보)
• 향후 개선사항:
• 프론트엔드 아키텍처 단순화 (인증 및 API 라우팅 복잡성 줄이기)
• SSE 처리 방식 개선

결론

• 혼합 아키텍처 실무 적용 팁:
• Next.js 서버 컴포넌트를 통해 보안 강화 및 CORS 문제 해결
• Terraform으로 인프라 일관성 유지
• Spring Boot Starter를 통한 모듈화를 통해 재사용성 확보
• 권장사항:
• 프론트엔드 복잡성 관리를 위한 인증/라우팅 단순화
• SSE 지원을 위한 별도 처리 로직 설계
• 프로젝트 예시: Fenixs (AI 기반 스토리텔링 플랫폼)에서 아이디어 → 스크립트 → 시각적 레이아웃 자동화 기능 구현 중