ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Spring Framework 시리즈 14화 – Model, ModelAndView, ResponseEntity 비교와 활용법
    기술과 산업/언어 및 프레임워크 2025. 7. 2. 11:09
    728x90

    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 초창기에는 자주 쓰였지만, 최근에는 ModelString 리턴 방식이 분리되면서 사용 빈도는 낮아졌습니다.

    @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
Designed by Tistory.