-
Spring Framework 시리즈 14화 – Model, ModelAndView, ResponseEntity 비교와 활용법기술과 산업/언어 및 프레임워크 2025. 7. 2. 11:09728x90
Spring MVC로 웹 애플리케이션을 개발하다 보면 컨트롤러에서 데이터를 뷰에 전달하거나, REST API 형태로 JSON 응답을 줄 일이 많습니다. 이때 자주 마주치는 것이 바로 Model, ModelAndView, 그리고 ResponseEntity입니다. 세 가지 모두 응답 데이터를 처리하는 방식이지만, 각각의 목적과 사용 방식에는 뚜렷한 차이가 있습니다. 오늘은 이 세 가지의 차이점과 실제 현업에서는 어떤 기준으로 선택하는지를 집중적으로 짚어보겠습니다.
Model – 뷰(View) 렌더링 중심의 데이터 전달자
Model은 전통적인 MVC 패턴에서 “데이터를 뷰로 넘기는” 역할에 충실한 객체입니다. 주로 JSP, Thymeleaf 같은 템플릿 뷰에서 사용됩니다.
@GetMapping("/hello") public String hello(Model model) { model.addAttribute("message", "Hello, Spring!"); return "hello"; // hello.html or hello.jsp }
- model.addAttribute()를 통해 데이터를 설정
- 리턴값은 뷰 이름 (ViewResolver가 이 이름에 해당하는 파일을 찾아 렌더링)
- RESTful API 개발보다는 웹 화면에 데이터를 넘길 때 주로 사용됨
언제 쓰나?
- Thymeleaf, JSP 등 뷰 템플릿 기반의 서버사이드 렌더링을 쓸 때
- 데이터를 뷰에 넘기고 싶을 때
ModelAndView – 데이터 + 뷰 정보를 동시에 담는 컨테이너
ModelAndView는 말 그대로 모델 데이터와 뷰 정보를 한 객체에 담아 반환할 수 있게 해줍니다. Spring 초창기에는 자주 쓰였지만, 최근에는 Model과 String 리턴 방식이 분리되면서 사용 빈도는 낮아졌습니다.
@GetMapping("/legacy") public ModelAndView legacy() { ModelAndView mav = new ModelAndView("hello"); mav.addObject("message", "From ModelAndView"); return mav; }
- setViewName() 혹은 생성자에서 뷰 지정
- addObject()로 데이터 설정
- 뷰 이름과 모델 데이터를 모두 컨트롤
장점
- 하나의 객체로 응답 구성 가능
- MVC의 구조를 깔끔하게 캡슐화
단점
- 코드가 장황해지고, 유연성이 떨어짐
- 테스트 코드 작성 시 복잡성 증가
ResponseEntity – HTTP 응답 제어의 끝판왕
이제는 REST API 시대. 클라이언트와 JSON, XML 등의 데이터만 주고받는 경우가 대부분입니다. 이때 필요한 게 바로 ResponseEntity입니다. 단순히 데이터를 넘기는 게 아니라, 상태 코드, 헤더, 본문까지도 직접 제어할 수 있는 게 큰 장점입니다.
@GetMapping("/api/data") public ResponseEntity<Map<String, Object>> getData() { Map<String, Object> body = new HashMap<>(); body.put("name", "Spring"); body.put("version", "6.x"); return ResponseEntity .status(HttpStatus.OK) .header("Custom-Header", "value") .body(body); }
주요 특징
- HTTP Status를 명시적으로 설정 가능
- 헤더 설정이 용이
- REST 컨트롤러와 찰떡궁합
어디서 쓰나?
- JSON 기반 REST API
- 에러 메시지 응답을 커스터마이징할 때
- HTTP 헤더 제어가 필요할 때
실무에서는 어떻게 선택할까?
기능/상황추천 방식이유
뷰 렌더링 중심 Model 데이터만 넘기고 뷰 이름을 String으로 지정 구식 MVC 패턴 또는 프레임워크 통합 필요 ModelAndView 캡슐화된 구조가 필요할 때 REST API 응답 ResponseEntity 상태 코드, 헤더, 본문까지 제어 가능 예외 처리 응답 ResponseEntity 에러 상태 전달, 커스터마이징 쉬움
개인적인 팁 하나
최근에는 대부분 REST API 위주로 개발이 이루어지고 있기 때문에, ResponseEntity를 표준처럼 사용하는 프로젝트가 많습니다. 특히 HTTP 400, 401, 403, 500 같은 에러 처리나, 응답 헤더를 정밀하게 조작할 일이 있다면 ResponseEntity는 거의 필수에 가깝습니다.
반면, 어드민 페이지 같이 화면 렌더링이 필요한 서버사이드 뷰 프로젝트에서는 여전히 Model 객체가 기본값처럼 쓰입니다. 다만 ModelAndView는 점점 줄어들고 있는 추세입니다. 레거시 유지보수용 프로젝트라면 꼭 익숙해져야겠지만, 새로운 프로젝트에서는 많이 보기는 어렵습니다.
정리하며
세 가지 객체는 Spring MVC 안에서 각각의 역할을 잘 수행합니다. 하지만 목적이 다른 만큼, 무작정 외우기보다는 “언제 어떤 응답이 필요한가?“라는 관점에서 선택하는 게 더 중요합니다. 결국 좋은 개발자는 상황에 따라 최적의 도구를 고르는 사람이라는 걸 기억해주세요.
728x90'기술과 산업 > 언어 및 프레임워크' 카테고리의 다른 글
Spring Framework 시리즈 15화 – 스프링 MVC의 예외 처리 전략과 @ExceptionHandler 사용법 (1) 2025.07.18 Spring Boot 고급 시리즈 8화 – 비동기 프로그래밍과 @Async의 활용 전략 (3) 2025.07.02 Spring AI 시리즈 9화 - Milvus와 Spring AI 통합 전략 (1) 2025.06.26 FastAPI 시리즈 15화 - 보안 관점에서 보는 FastAPI 최적 설정 가이드 (0) 2025.06.22 전자정부 표준프레임워크 시리즈 15화 – Gradle + Spring Boot 전환 전략: 표준프레임워크의 현대화 실전 사례 (2) 2025.06.22