Spring WebMVC Process 로직도 + React/Vue

Spring WebMVC Process 로직도

 

 

 

 

• 파란색 (Main Control): 요청을 총괄하는 DispatcherServlet (매니저)
• 초록색 (Data & Logic): 실제 비즈니스 로직과 데이터를 처리하는 핵심 영역 (요리사/DB)
• 주황색 (UI & View): 최종적으로 사용자에게 보여줄 화면을 생성하는 영역 (그릇/플레이팅)
• 회색 (Entrance/Exit): 사용자와의 접점 (손님)

 

개발자가 직접 코드를 짜야 하는 **'노동의 영역'**과 Spring이 알아서 다 해주는 **'자동화의 영역'**을 구분하는 것이 Spring 공부의 핵심입니다!

방금 전 그림의 구성 요소들을 기준으로, 개발자의 역할과 Spring의 역할, 그리고 API가 들어왔을 때의 변화를 명확하게 정리해 드릴게요.

 

핵심 설명

---

1. 누가 무엇을 하나요? (개발자 vs Spring)

대부분의 복잡한 연결 고리는 Spring이 이미 다 만들어 놨습니다. 개발자는 핵심 비즈니스 로직에만 집중하면 됩니다.

구성 요소	주체	개발자가 하는 일 (실제 코드 작성)	Spring이 해주는 일 (마법)
DispatcherServlet	Spring	건드릴 필요 없음.	모든 요청을 받고 적절한 곳으로 배달함.
HandlerMapping	Spring	@RequestMapping("/api/chat") 처럼 주소 이름표만 붙여줌.	주소(URL)를 보고 어떤 컨트롤러로 보낼지 매칭해줌.
Controller	개발자	(가장 중요!) 사용자의 요청을 받고, 서비스에 일을 시키고, 결과를 반환하는 코드를 직접 짬.	객체를 생성하고 관리함 (Bean 등록).
Service/DAO/DB	개발자	실제 데이터 계산, DB 저장, 외부 API 호출 등의 핵심 로직을 구현함.	트랜잭션 처리(DB 오류 시 되돌리기 등)를 도와줌.
ViewResolver	Spring	설정 파일에서 "JSP 파일은 /WEB-INF/views/에 있어"라고 한 줄 설정만 함.	컨트롤러가 준 이름(예: "profile")을 보고 실제 파일 경로를 찾아냄.
JSP (View)	개발자	HTML/CSS 코드를 짜서 화면을 디자인함.	데이터를 HTML 사이에 쏙쏙 끼워 넣어줌.

1. Controller 안의 실제 모습 (비유: 주방장과 보조 요리사)

Controller가 단순히 "실행"만 하는 게 아니라, 아래와 같은 계층 구조를 가지고 협업합니다.

• Controller (주방장): 손님의 주문(/profile.do)을 받고, 최종 요리를 접시에 담아 내보냅니다. 직접 칼질(로직)을 하기보다는 Service에게 시킵니다.
• Service (수석 요리사): 실제 요리(비즈니스 로직)를 합니다. "고기는 3분 굽고, 소스는 ChatGPT API에서 받아온 걸 섞어!" 같은 핵심 명령을 내립니다.
• DAO/Repository (재료 담당): 냉장고(DB)에서 재료를 꺼내오거나, 다 쓴 재료를 다시 채워넣는 역할만 합니다.
• DB (냉장고): 데이터가 저장되어 있는 곳입니다.

실행 로직 (순서):

1. 사용자가 profile.do 클릭!
2. Controller가 "오케이, 프로필 조회 시작!" 하고 Service를 호출합니다.
3. Service는 DAO에게 "DB에서 user123 정보 좀 가져와"라고 시킵니다.
4. DAO가 DB에서 데이터를 꺼내 Service에게 주고, Service는 그 데이터를 가공해서 Controller에게 돌려줍니다.
5. Controller는 이 데이터를 가지고 JSP라는 접시에 담습니다.

---

2.  💡보너스: 요즘 트렌드 (REST API) React/Vue를 쓰면 7~11번(View)이 어떻게 되나요?

💡 보너스: 요즘 트렌드 (REST API)

만약 React나 Vue 같은 프론트엔드를 따로 쓰거나, FastAPI와 통신하는 구조라면 위 그림에서 7~11번(View/JSP 과정)이 아예 사라집니다. 대신 컨트롤러가 데이터를 HTML로 만드는 대신 JSON 데이터 그 자체를 바로 브라우저나 타 서버로 쏴버리는데, 이를 **@RestController**라고 부릅니다. 현대적인 백엔드 개발자는 대부분 이 방식을 씁니다

이 부분이 가장 흥미로운 지점입니다! React나 Vue를 쓰면 Spring이 더 이상 "화면(JSP)을 그리는 일"을 하지 않습니다. #### [비유의 변화]

• JSP 방식 (기존): 식당에서 요리를 다 만들고 접시에 예쁘게 플레이팅까지 해서 손님 식탁에 딱 내놓는 방식 (완제품 배달).
• React/Vue 방식 (현대): 식당(Spring)은 **'신선한 손질 재료(JSON 데이터)'**만 깔끔하게 박스에 담아 보냅니다. 손님(브라우저)은 자기 집에 있는 **최신형 에어프라이어(React)**를 돌려 직접 예쁘게 차려 먹습니다.

[로직의 변화: 7~11번의 실종]

React를 쓰면 Spring Controller는 **@RestController**가 됩니다.

1. 7~8번 (View 검색): 안 합니다. "어떤 화면을 보여줄까?" 고민할 필요가 없습니다.
2. 9~10번 (JSP 실행): 안 합니다. HTML 파일을 만들지 않습니다.
3. 11~12번 (응답 전송): 대신, 데이터만 JSON이라는 아주 가벼운 텍스트 형식으로 쏴버립니다.
   • 예: {"name": "Yeona", "job": "Engineer"}

[왜 이렇게 하나요?]

• 역할 분담: Spring은 데이터만 잘 관리하면 되고(Back-end), React는 화면만 예쁘게 만들면 됩니다(Front-end). 서로의 영역을 침범하지 않으니 개발이 훨씬 깔끔해집니다.
• 속도: 서버(Spring)가 무거운 HTML을 매번 만들 필요가 없으니 부담이 줄고, 브라우저(React)가 필요한 데이터만 쏙쏙 받아 화면을 부분적으로 바꾸니 사용자 경험이 훨씬 부드러워집니다.

 

2. API(ChatGPT, Gemini 등)가 적용되면 어디에 들어갈까?

사용자가 질문을 입력하고 AI 답변을 받는 기능을 만든다고 가정하면, API 호출 코드는 보통 Controller나 그 뒤의 Service 계층에 위치하게 됩니다.

1. Controller: 사용자의 질문 메시지를 받습니다.
2. Service (개발자 영역): 여기서 FastAPI 서버나 OpenAI API를 직접 호출하는 코드를 작성합니다.
   • 예: Spring의 WebClient라는 도구를 써서 FastAPI에게 "이 질문 분석해줘"라고 요청 보냄.
3. 결과 반환: AI의 답변이 오면, 이를 다시 Controller를 통해 사용자 화면(JSP)으로 보냅니다.

---

3. 요약: 개발자의 실제 작업 범위

실제로 코딩을 하실 때는 아래 3개 포인트만 기억하시면 됩니다.

• 설정: "어떤 기술(DB, View 등)을 쓸 거야"라고 Spring에게 알려주기 (주로 설정 파일이나 Annotation 활용).
• Controller 작성: "이 주소로 들어오면 이 함수를 실행해!"라고 길을 닦아주기.
• Logic(Service) 구현: "AI API를 호출하고 결과값을 가공해!"라는 진짜 실력을 발휘하는 구간.

---

 

더 쉽게 풀어 설명

[1단계] 아주 쉬운 설명: 비유 vs 기능

이 전체 과정은 **"손님이 식당에 가서 음식을 주문하고 받는 과정"**과 똑같습니다.

• 중요 역할 분담:
  • 손님 = Web Browser (웹 브라우저)
  • 매니저 = DispatcherServlet (전체 지휘자)
  • 메뉴판 담당 = HandlerMapping (어디로 갈지 안내)
  • 서빙 직원 = HandlerAdapter (요청을 전달하고 결과 수신)
  • 요리사 = Controller (실제 주문 처리)
  • 음식 스타일 결정 = ViewResolver (어떤 그릇에 담을지 결정)
  • 최종 완성된 요리 = View/JSP (사용자가 보는 화면)

예시 상황: "사용자가 웹사이트에서 '내 프로필 보기' 버튼을 눌렀다."

이 상황이 위 그림에서 어떻게 돌아가는지 단계별로 매칭해 보겠습니다.

 

단계	실제 기능적 상황 (가장 쉬운 버전)	생활 속 비유 (식당)
1. 요청 전송	사용자가 브라우저에서 /my-profile 주소로 접속합니다.	손님이 식당에 들어와 "제 프로필 메뉴 주세요"라고 주문합니다.
2. 매핑/검색	매니저(DispatcherServlet)는 "이 주소 요청은 누가 처리하지?"라며 메뉴판(HandlerMapping)을 확인합니다. "아, /my-profile은 '프로필 요리사'가 담당하는구나."	매니저가 주문을 받고, 메뉴판을 보니 이 요리는 'A 요리사' 전공인 것을 확인합니다.
3~4. 처리 요청/실행	매니저의 지시를 받은 서빙 직원(HandlerAdapter)이 '프로필 요리사(Controller)'에게 "회원 ID 'user123'의 프로필 정보를 가져오세요"라고 요청을 전달합니다. 요리사는 데이터베이스(Service/DAO)에서 회원 정보를 가져와 조리합니다.	매니저가 서빙 직원에게 지시하고, 서빙 직원은 'A 요리사'에게 주문서를 전달합니다. 요리사는 냉장고에서 재료(데이터)를 꺼내 요리를 시작합니다.
5~6. 결과 리턴	요리사가 "여기 회원 정보(이름, 이메일 등) 데이터 나왔습니다!" 하고 데이터 세트(ModelAndView)를 서빙 직원에게 줍니다. 서빙 직원은 이걸 매니저에게 전달합니다.	요리사가 맛있는 음식(데이터)을 다 만들어서 서빙 직원에게 줍니다. 서빙 직원은 이 음식을 매니저에게 가져다줍니다.
7~8. View 검색/요청	매니저가 이 데이터를 보고 "이 데이터는 사용자한테 어떻게 보여줘야 예쁠까?" 고민하다가 '스타일 담당(ViewResolver)'에게 물어봅니다. "이 데이터는 profile.jsp라는 그릇에 담으면 됩니다." 답변을 듣고 매니저는 그릇(View)에 응답을 만들라고 지시합니다.	매니저가 음식을 보고 "이건 어떤 접시에 담아야 가장 먹음직스러울까?" 고민합니다. 스타일 담당이 "그건 '세라믹 접시(profile.jsp)'에 담아야 해요"라고 알려줍니다. 매니저는 접시에 음식을 플레이팅하라고 지시합니다.
9~11. 응답 생성/전달	그릇(View)은 실제 HTML 코드 조각인 JSP 파일에 요리사에게 받은 데이터를 쏙쏙 끼워 넣어, 완벽한 HTML 페이지를 만듭니다. 완성된 페이지는 다시 매니저에게 전달됩니다.	접시 위에 음식을 예쁘게 담고, 소스도 뿌려서(데이터 결합) 완벽한 최종 요리를 만듭니다. 이 요리는 매니저에게 전달됩니다.
12. 응답 전송	매니저는 최종 완성된 HTML 페이지를 사용자의 브라우저로 보내줍니다. 브라우저는 이걸 우리 눈에 보이는 화면으로 띄워줍니다.	매니저가 최종 요리를 손님 테이블에 서빙합니다. 손님은 요리를 맛있게 먹습니다(화면을 봅니다).

 

 

백엔드 개발자가 하는 일의 90%는 **"어떤 주소(URL)로 요청이 오면, 어떤 데이터를 어떤 형식(JSON)으로 내뱉어줄지"**를 설계하는 것이고, 그 설계 방식의 표준이 바로 REST API입니다.

그 과정을 Controller 코드를 예로 들어 아주 쉽게 보여드릴게요.

---

2. 코드로 보는 REST API 설계 (Spring Boot 예시)

개발자가 Controller 안에 작성하는 로직이 바로 REST API 그 자체가 됩니다.

 

• 설계 포인트: 주소는 /api/ai/chat이고, 방식은 POST이며, 결과는 JSON 데이터다! -> 이게 바로 REST API 설계입니다.

---

3. 왜 Controller가 REST API의 핵심인가요?

앞서 보셨던 Spring WebMVC 도식을 다시 떠올려보세요.

1. DispatcherServlet이 요청을 받아서...
2. HandlerMapping이 "이 주소는 이 Controller네!" 하고 찾아주면...
3. Controller가 실행되는데, 이때 **@RestController**를 써두면 Spring이 알아서 7~11번(JSP 생성 과정)을 생략하고 데이터를 바로 쏴줍니다.

"**React(프론트)**가 **Spring(백엔드)**의 **Controller(REST API 창구)**에 질문을 던지면, Spring은 내부적으로 **FastAPI(AI 특화 서버)**와 통신한 뒤, 최종 결과를 **JSON(데이터 봉투)**에 담아 React에게 돌려준다."

 

 

4. 전통 JSP 방식과 현대적 React/Vue의 WebMVC 프로세스를 각각 별도의 이미지

 

 

[버전 1: 전통적인 JSP 방식 (Server-Side Rendering)]

이 방식은 **"완성된 요리(HTML)"**를 배달하는 구조입니다. 서버(Spring)가 화면까지 다 만들어서 브라우저에게 던져줍니다. 7번부터 11번까지의 'View' 관련 과정이 핵심입니다.

설명: 전통적인 JSP 방식은 서버가 모든 화면을 그려서 브라우저에 전달합니다. 위 그림의 파란색(매니저)과 초록색(요리사)을 거쳐 주황색(그릇 담당)이 최종적으로 화면을 만들고, 매니저가 이를 손님에게 서빙하는 구조입니다.

---

[버전 2: React/Vue(REST API) 방식 (Client-Side Rendering)]

이 방식은 **"신선한 손질 재료(JSON 데이터)"**를 배달하는 구조입니다. 서버(Spring)는 데이터만 잘 관리하고, 화면은 React가 직접 예쁘게 차려 먹습니다. 7번부터 11번까지의 'View' 관련 과정이 아예 생략되었습니다.

 

설명: React/Vue 방식은 서버(Spring)가 데이터만 깔끔하게 JSON으로 던집니다. 위 그림에서 파란색(매니저)과 초록색(요리사)을 거친 후, 주황색(그릇 담당)이 아예 생략되었습니다. 대신 매니저가 결과 데이터를 JSON이라는 가벼운 텍스트 형식으로 바로 브라우저에게 전달합니다. 브라우저는 이를 받아 React가 화면의 일부분만 데이터를 갈아끼우는 방식으로 작동합니다

버전 1: 전통적인 JSP 방식 (Server-Side Rendering)]

이 방식은 **"완성된 요리(HTML)"**를 배달하는 구조입니다. 서버(Spring)가 화면까지 다 만들어서 브라우저에게 던져줍니다. 7번부터 11번까지의 'View' 관련 과정이 핵심입니다.

 

설명: 전통적인 JSP 방식은 서버가 모든 화면을 그려서 브라우저에 전달합니다. 위 그림의 파란색(매니저)과 초록색(요리사)을 거쳐 주황색(그릇 담당)이 최종적으로 화면을 만들고, 매니저가 이를 손님에게 서빙하는 구조입니다.

---

[버전 2: React/Vue + Spring REST API 통합 프로세스 ]

 

 

구분	버전 1: JSP (전통적 식당)	버전 2: React/Vue (밀키트 배달)
Spring의 역할	요리를 다 만들고 접시에 완벽하게 플레이팅까지 해서 내옴.	최고급 식재료와 레시피(데이터)만 깔끔하게 손질해서 포장함.
브라우저의 역할	가져다준 요리를 먹기만 함. (HTML을 보여줌)	배달받은 식재료 박스(JSON)를 열고, 자기네 집 주방(React)에서 직접 예쁘게 차려 먹음. (화면을 그림)
장점	손님이 할 게 없음.	식당(서버)이 플레이팅할 노력을 안 해도 돼서 엄청 빠름. 손님은 자기 취향대로 가장 신선하게 즐길 수 있음.

 

설명: React/Vue 방식은 서버(Spring)가 데이터만 깔끔하게 JSON으로 던집니다. 위 그림에서 파란색(매니저)과 초록색(요리사)을 거친 후, 주황색(그릇 담당)이 아예 생략되었습니다. 대신 매니저가 결과 데이터를 JSON이라는 가벼운 텍스트 형식으로 바로 브라우저에게 전달합니다. 브라우저는 이를 받아 React가 화면의 일부분만 데이터를 갈아끼우는 방식으로 작동합니다

 

 

PE / FE / Flow  핵심 정리

1. 프론트엔드 영역

• User
• Browser
• React/Vue App
• fetch/axios

2. 백엔드 영역

• DispatcherServlet
• HandlerMapping
• HandlerAdapter
• Controller
• Service
• DAO/Repository
• DB
• HttpMessageConverter(JSON 변환)

3. 실제 흐름

1. React가 fetch('/api/profile') 호출
2. 요청이 Spring DispatcherServlet으로 감
3. HandlerMapping이 Controller 찾음
4. HandlerAdapter가 Controller 실행
5. Controller → Service → DAO → DB
6. 결과를 Controller가 객체로 반환
7. Spring이 JSON으로 직렬화
8. JSON 응답을 브라우저가 받음
9. React state 업데이트
10. 화면 재렌더링