[001] Front-Back 정리
Front-Back 구조 정리
1. Client
Client는 사용자가 직접 보는 화면을 담당한다.
현대 웹에서는 React, Vue, Angular 같은 프레임워크를 사용해 SPA 방식으로 구현하는 경우가 많다.
2. SPA 방식
SPA(Single Page Application)
SPA는 최초에 하나의 HTML 페이지를 로드한 뒤, 필요한 데이터만 서버에서 받아와 화면 일부를 동적으로 갱신하는 방식이다.
대표 기술은 다음과 같다.
- React
- Vue
- Angular
SPA의 특징
1. 동적 콘텐츠 로딩
필요한 데이터만 서버에서 비동기적으로 가져와 화면을 업데이트한다.
페이지 전체를 새로고침하지 않기 때문에 빠른 사용자 경험을 제공할 수 있다.
2. 클라이언트 사이드 라우팅
화면 이동을 서버가 아닌 클라이언트의 JavaScript가 처리한다.
즉, URL은 바뀌지만 서버에서 새로운 HTML 페이지를 매번 받아오지는 않는다.
3. 상태 관리
사용자 인터페이스의 상태를 클라이언트에서 관리한다.
예를 들어 로그인 상태, 입력값, 선택된 메뉴, 장바구니 상태 등을 클라이언트에서 유지할 수 있다.
4. 재사용 가능한 컴포넌트
SPA는 컴포넌트 단위로 화면을 구성한다.
따라서 UI를 재사용하기 쉽고, 유지보수성과 확장성이 높다.
3. MPA 방식
MPA(Multi Page Application)
MPA는 사용자가 페이지를 이동할 때마다 서버가 새로운 HTML 페이지를 렌더링해서 클라이언트에게 전달하는 방식이다.
전통적인 서버 사이드 렌더링 방식에 가깝다.
대표 기술은 다음과 같다.
- JSP
- FreeMarker
- Mustache
MPA의 특징
- 페이지 이동 시 서버에 새로운 페이지를 요청한다.
- 서버가 View를 생성해서 응답한다.
- 페이지마다 HTML을 새로 받아오기 때문에 화면 전환 시 새로고침이 발생한다.
- MVC 모델에서 View 단을 담당하는 역할을 한다.
4. SPA와 MPA의 차이
| 구분 | SPA | MPA |
|---|---|---|
| 화면 처리 | 클라이언트에서 처리 | 서버에서 처리 |
| 페이지 이동 | JavaScript 라우팅 | 서버에 새 페이지 요청 |
| 렌더링 위치 | 주로 클라이언트 | 주로 서버 |
| 서버 역할 | API 제공 중심 | HTML 렌더링 포함 |
| 사용자 경험 | 빠르고 부드러움 | 페이지 전환 시 새로고침 |
| 대표 기술 | React, Vue, Angular | JSP, FreeMarker, Mustache |
5. SPA 도입 이후 WAS의 역할 변화
SPA 방식에서는 View 처리를 클라이언트가 담당한다.
따라서 서버는 HTML 페이지를 직접 만들어주는 역할보다 데이터를 제공하는 API 서버 역할에 집중하게 된다.
즉, WAS의 역할이 단순해진다.
주요 역할은 다음과 같다.
- 데이터 조회
- 데이터 생성
- 데이터 수정
- 데이터 삭제
- 인증 및 인가 처리
- 비즈니스 로직 처리
결국 서버는 CRUD 중심의 API를 제공하게 된다.
6. Server 구조
서버 구조는 크게 Monolithic 방식과 MSA 방식으로 나눌 수 있다.
| 구분 | Monolithic | MSA |
|---|---|---|
| 구조 | 하나의 거대한 애플리케이션 | 기능별로 분리된 독립 서비스 |
| 배포 | 전체 시스템을 한 번에 배포 | 서비스별 독립 배포 |
| 확장성 | 전체 애플리케이션을 복제 | 특정 서비스만 개별 확장 |
| 데이터베이스 | 단일 DB 공유 | 서비스별 독립 DB 사용 |
| 장애 격리 | 하나의 장애가 전체 장애로 이어질 수 있음 | 장애 전파 가능성이 상대적으로 낮음 |
| 초기 개발 | 구조가 단순하고 빠름 | 설계와 인프라가 복잡함 |
7. Monolithic Architecture
Monolithic은 하나의 애플리케이션 안에 모든 기능이 포함된 구조이다.
예를 들어 다음 기능들이 하나의 프로젝트 안에 모두 들어간다.
- 회원 관리
- 상품 관리
- 주문 관리
- 결제 관리
- 배송 관리
장점
- 초기 개발이 쉽다.
- 구조가 단순하다.
- 배포 과정이 비교적 간단하다.
- 서비스 간 통신 비용이 적다.
단점
- 프로젝트가 커질수록 유지보수가 어려워진다.
- 일부 기능 수정도 전체 애플리케이션 배포가 필요할 수 있다.
- 특정 기능에 장애가 발생하면 전체 시스템에 영향을 줄 수 있다.
- 기능별 독립 확장이 어렵다.
8. MSA Architecture
MSA는 하나의 큰 애플리케이션을 여러 개의 작은 서비스로 분리하는 구조이다.
예를 들어 다음과 같이 나눌 수 있다.
- 회원 서비스
- 상품 서비스
- 주문 서비스
- 결제 서비스
- 배송 서비스
각 서비스는 독립적으로 개발, 배포, 운영될 수 있다.
장점
- 서비스별 독립 배포가 가능하다.
- 특정 서비스만 확장할 수 있다.
- 장애 격리가 가능하다.
- 팀별로 서비스를 나누어 개발하기 좋다.
단점
- 서비스 간 통신 구조가 복잡하다.
- 트랜잭션 관리가 어렵다.
- 인증/인가 처리가 복잡해질 수 있다.
- 인프라 운영 난이도가 높다.
- 로그 추적과 장애 분석이 어려워질 수 있다.
9. MSA의 주요 문제점
1. 트랜잭션 문제
Monolithic 구조에서는 하나의 DB를 사용하기 때문에 하나의 트랜잭션으로 여러 작업을 처리하기 쉽다.
하지만 MSA에서는 서비스마다 DB가 분리되어 있기 때문에 하나의 요청이 여러 서비스에 걸쳐 처리될 경우 트랜잭션 관리가 어려워진다.
예를 들어 주문 서비스와 결제 서비스가 분리되어 있다면 다음 문제가 발생할 수 있다.
- 주문은 생성되었지만 결제는 실패한 경우
- 결제는 성공했지만 주문 상태 변경이 실패한 경우
- 배송 요청은 생성되었지만 재고 차감이 실패한 경우
이런 문제를 해결하기 위해 Saga 패턴, 보상 트랜잭션, 이벤트 기반 처리 등을 사용할 수 있다.
2. 인증 문제
MSA에서는 여러 서비스가 분리되어 있기 때문에 사용자 인증 정보를 각 서비스에서 어떻게 검증할지가 중요하다.
일반적으로 JWT를 사용해 인증 정보를 전달한다.
JWT 기반 인증 흐름은 다음과 같다.
- 사용자가 로그인한다.
- 인증 서버가 JWT를 발급한다.
- 클라이언트는 요청마다 JWT를 함께 보낸다.
- 각 서비스는 JWT를 검증한 뒤 요청을 처리한다.
하지만 서비스가 많아지면 다음 문제가 생길 수 있다.
- 각 서비스마다 JWT 검증 로직이 중복될 수 있다.
- 토큰 만료 처리와 재발급 처리가 복잡해질 수 있다.
- 권한 정보가 변경되었을 때 기존 토큰과 불일치가 발생할 수 있다.
- API Gateway에서 인증을 처리할지, 각 서비스에서 처리할지 설계가 필요하다.
핵심 요약
SPA 구조에서는 View를 Client가 담당하고, Server는 데이터 API 제공에 집중한다.
따라서 WAS는 CRUD 중심의 API 서버 역할을 하게 된다.
Server 구조는 크게 Monolithic과 MSA로 나뉜다.
Monolithic은 구조가 단순하고 초기 개발이 빠르지만, 규모가 커질수록 유지보수가 어렵다.
MSA는 서비스별 독립 배포와 확장이 가능하지만, 트랜잭션과 인증 같은 분산 시스템 문제가 발생한다.