개인 프로젝트 | 01 _ 웹앱 도입에 대하여

기술 스택

웹앱 구축을 위한 핵심 기술 스택은 다음과 같다.

 

Nginx : Reverse Proxy & Web Server

• 홈서버 구축 시 Nginx는 프록시 서버 역할이 핵심이다.
• 하지만 기본적으로 웹 서버 기능도 제공하므로, 웹앱이나 웹서비스 배포 시 함께 사용할 수 있다.
• 즉, 웹앱 컨테이너만 별도로 구성하고, Nginx를 통해 라우팅과 정적 파일 제공을 관리하는 방식이 가능하다.

FastAPI : 고성능 Python 기반 비동기 API 서버

• 비동기 처리를 지원하기때문에 API 응답 속도가 빠르며, 간단하게 백엔드 구축 가능
• Pydantic을 활용한 데이터 검증과 Swagger UI 자동 생성 기능도 제공한다

 

Next.js : React 기반의 SSR(서버 사이드 렌더링) 프레임워크

• SSR과 CSR(Client Side Rendering)의 장점을 결합한 하이브리드 웹 프레임워크이다.
• 보통은 SEO 최적화, 빠른 초기 로딩, 서버에서 직접 페이지를 생성하여 사용자 경험(UX) 개선

 

---

웹앱을 도입한 이유

웹앱을 도입한 핵심 이유는 앱의 성능 최적화와 사용자 경험(UX) 개선이다.

단순히 네이티브 앱으로 개발하게 되는 경우 다음과 같은 문제점이 예상된다.

• 2D 맵과 캐릭터의 움직임을 처리하는 데 리소스 사용량 증가
• 여러 사용자가 실시간으로 상호작용해야 하는 공간 구현
• 유저 간 실시간 통신 및 동적 데이터 렌더링 필요
• 앱의 무거운 데이터 처리 부담 증가 → 성능 저하 발생

이 문제를 해결하기 위해, 웹앱(Web App)을 활용하여 복잡한 연산 및 데이터 처리를 분리하기로 결정했다.
즉, 네이티브 앱이 가벼운 역할을 수행하고, 웹앱이 무거운 데이터 처리 및 동적 렌더링을 담당하는 구조다.

 

이제 웹앱을 배포하기 전, 적절한 렌더링 방식을 선택해보자.

---

웹앱의 렌더링 방식: CSR vs SSR

웹앱을 구축할 때 가장 중요한 고려 사항 중 하나가 렌더링 방식이다.
렌더링 방식에 따라 성능, 사용자 경험, SEO(검색 엔진 최적화)에 큰 차이가 발생한다.

 

CSR (Client Side Rendering) – 클라이언트 측 렌더링

• 초기 로딩 시 최소한의 HTML을 제공하고, 이후 JavaScript가 실행되면서 동적으로 UI를 생성하는 방식.
• 장점:
  • 클라이언트에서 모든 렌더링을 처리하므로 서버 부하 감소
  • 네비게이션 속도가 빠름 (Single Page Application)
• 단점:
  • 초기 페이지 로딩 속도가 느림 (JS 실행 후 렌더링되기 때문)
  • SEO(검색 엔진 최적화)에 불리함

 

SSR (Server Side Rendering) – 서버 측 렌더링

• 요청이 들어올 때 서버에서 HTML을 완전히 구성하여 클라이언트에 전달하는 방식.
• 장점:
  • SEO에 최적화됨 (검색 엔진이 HTML을 직접 읽을 수 있음)
  • 초기 로딩 속도가 빠름 (서버에서 미리 HTML을 생성하여 제공하기 때문)
• 단점:
  • 모든 요청에 대해 서버가 HTML을 생성해야 하므로 서버 부하 증가
  • 클라이언트에서 추가적인 상호작용을 위해 Hydration 과정 필요

 

=> SSR 채택

내 프로젝트에서는 SSR을 선택했다.

선택 이유:

• 웹앱이 무거운 데이터 처리 및 실시간 통신을 담당해야 함
• 초기 로딩 속도를 최적화하여 사용자 경험(UX) 개선 필요
• SEO보다 실시간 반응성과 성능 최적화가 더 중요함

하지만 아직 문제가 남아있다. 바로 FastAPI는 SSR을 지원하지 않는 프레임워크라는 것...

 

해결책: FastAPI + Next.js 조합

SSR의 성능 최적화를 위해 Next.js를 도입하여 SSR을 처리하는 구조를 설계했다.
즉, FastAPI는 API 서버 역할을 수행하고, Next.js가 SSR을 담당하는 방식이다.

이렇게 FastAPI는 API 응답에 집중하고, Next.js가 SSR을 처리하니 서버 부하가 감소되고 오히려 좋다.

 

---

웹앱 배포 방식

웹앱을 배포하는 방법에는 여러 가지가 있지만, 내가 고민한 것은 아래 두가지 방식이다. 

1. 서버리스(Serverless) 배포

• 장점:
  • 웹 서버 별도 관리 필요 없음
  • 정적 웹사이트 및 API 호출이 빈번하지 않은 웹 서비스에 적합
• 단점:
  • 콜드 스타트 문제 발생 가능 (API 호출 시 초기 로딩이 지연될 수 있음)
  • 무거운 연산이나 복잡한 데이터 처리가 필요한 경우 부적절

ex: Vercel, Netlify, AWS Lambda 등

 

2. SSR 기반 웹 서버 구축 배포

• 장점:
  • SSR을 활용한 빠른 초기 로딩 가능
  • SEO 최적화 및 안정적인 성능 유지
• 단점:
  • API 서버(FastAPI)와 별도로 웹 서버(Next.js) 관리 필요

ex: FastAPI + Next.js 조합

 

=> 2번 방식 채택

우선, SSR을 활용해서 2D맵이나 실시간 상호작용 등 성능 최적화로 UX개선이 목표이니 서버 프로세스가 유지되어야한다. 그러므로 서버리스 방식은 내 상황에 부적절하다. 또한 웹앱 서비스 구조 상 FastAPI와의 잦은 연결이 필요할 것으로 보인다. 그리고 서버 부하를 줄이면서 안정적인 배포가 가능한 2번 방식이 적절해보인다.

 

최종 아키텍처

사용자 → Nginx (리버스 프록시 서버) → Next.js (SSR) → FastAPI (백엔드)

• Nginx: API 요청 프록싱 + 정적 파일 제공(필요하다면)
• Next.js: SSR 처리, 프론트엔드 렌더링
• FastAPI: 백엔드 API 요청 처리

 

---

결론

"FastAPI는 데이터를 제공하는 백엔드 역할을 하고, Next.js는 그 데이터를 이용해 서버에서 HTML을 렌더링(SSR)하는 웹 서버 역할을 한다." 

 

앞으로는 웹앱의 확장성과 최적화 방법을 공부해봐야겠다.