본문 바로가기

Java/자바 성능 개선

01. 디자인 패턴은 꼭 써야한다 - (1) MVC 모델

💡 본 게시글은 이상민 저자의 '자바 성능 튜닝 이야기' 교재를 공부하고, 이에 대해 정리한 내용입니다.

'자바 성능 튜닝이야기' 책을 읽게 된 이유

 저는 Java를 공부하는 학생으로서, 최근 팀 프로젝트에 백엔드로서 참여하게 되었습니다. 프로젝트 초기에 저희 팀은 주로 기능 구현에 중점을 두었습니다. 당시에는 성능 최적화보다는 기능적 완성도에 더 많은 관심을 기울였고, 성능 관련 문제는 크게 고려하지 않았습니다. 그러나 프로젝트가 진행됨에 따라, 애플리케이션의 반응 시간이 느려지고, 메모리 사용량이 증가하는 등의 여러 성능 저하 문제들이 눈에 띄기 시작했습니다.

이러한 문제들은 애플리케이션에 대해 직접적인 영향을 미치고, 애플리케이션의 전반적인 품질을 저하시켰습니다. 이는 저희 팀에게 중요한 깨달음을 주었습니다. 바로, 단순히 '동작하는' 소프트웨어를 개발하는 것을 넘어, '효율적으로 동작하는' 소프트웨어를 개발하는 것의 중요성입니다. 이를 위해 Java의 성능 관련 측면을 깊이 이해하고, 개선 방법을 배우고자 '자바 성능 튜닝이야기' 책을 선택하게 되었습니다. 


들어가며

 이 교재의 첫 장은 디자인 패턴에 초점을 맞추고 있습니다. 이는 자바에 대한 광범위한 지식과 코드 작성 경험을 넘어, 자바 기반 시스템을 분석하고 설계하며 개발하는 과정에서 디자인 패턴의 중요성을 부각시키기 위함입니다. 디자인 패턴을 이해하고 적용하는 것은 소프트웨어의 전체 구조를 파악하고 효율적으로 개발하는 데 필수적입니다. 충분한 디자인 패턴 지식 없이 개발을 진행하면 코드 품질이 저하되고 성능 문제가 발생할 수 있기 때문에, 이 교재는 그러한 위험을 방지하고자 디자인 패턴의 핵심을 강조합니다. 


1) MVC 모델

 그에 대한 첫 번째 내용은 MVC 모델에 관한 것입니다. 이 내용이 첫 번째로 나오는 이유는 J2EE 패턴을 효과적으로 공부하기 위해서는 먼저 MVC 모델에 대한 이해가 필수적이기 때문입니다. 일반적으로 MVC는 Model, View, 그리고 Controller로 구성됩니다.

 

View는 사용자가 결과를 보거나 입력할 수 있는 화면이라고 생각하면 됩니다. 이벤트를 발생시키고, 이벤트의 결과를 보여주는 화면의 역활을 합니다. 

 

- Model은 View를 통해 입력된 데이터를 저장하고, 이를 관리하며 필요에 따라 수정하는 부분입니다. 이는 애플리케이션의 실질적인 데이터 처리를 담당합니다.

- Controller는 View와 Model 사이를 연결하는 중간자 역할을 합니다. View에서 발생한 이벤트를 받아 Model로 전달하고, 그 결과를 다시 View로 전송하는 기능을 수행합니다.

출처: https://medium.com/@joespinelli_6190/mvc-model-view-controller-ef878e2fd6f5

 

 

MVC 모델의 이해를 돕는 예시로는 JSP 모델 1과 JSP 모델 2가 있습니다. 이들은 MVC 모델을 웹 애플리케이션에 적용한 구체적인 사례로, 각각의 구성 요소가 어떻게 상호작용하는지를 잘 보여줍니다.


(1) JSP 모델 1

JSP 모델 1은 JSP에서 자바 빈을 호출하고 데이터베이스에서 정보를 조회, 등록, 수정, 삭제 업무를 한 후 결과를 브라우저로 보내주는 방식입니다.

출처: https://ssup2.github.io/theory_analysis/MVC_MVP_%ED%8C%A8%ED%84%B4/

 

 이 방식은 간단하게 개발할 수 있지만, 수정 및 유지보수가 힘들다는 단점이 있습니다.

그에 대한 주된 이유로는 혼합된 코드로 제작되어 있기 때문입니다. 해당 JSP 안에는 프레젠테이션(HTML, CSS, Java Script 등)와 서버 사이드 로직(Java 코드)으로 구성되어 있습니다.  로직이 분산되어 있지 않고 하나의 페이지에 모두 포함되어 있기 때문에, 변경 사항이 있을 때 해당 페이지의 전체 구조를 이해해야만 수정이 가능합니다. 하지만 HTML, CSS, JavaScript, Java 코드가 혼재되어 있는 3000 줄이 넘는 JSP 소스에서 기능을 수정 및 보완을 하기란 사실상 쉽지 않습니다. 또한 위 코드는 Controller가 없기 때문에 MVC 모델이라고 하기는 어렵습니다.


(2) JSP 모델 2

위 단점을 해결하기 위해 나온 것이 JSP 모델2입니다. JSP로 직접 요청하는 JSP 모델 1과의 차이점은 JSP 모델 2는 서블릿으로 요청한다는 점이다.

출처: https://ssup2.github.io/theory_analysis/MVC_MVP_%ED%8C%A8%ED%84%B4/

 

 JSP 모델 2에서 서블릿은 Controller 역할을 수행하면서, 사용자의 요청을 받고 이를 처리합니다. 서블릿은 요청에 따른 비즈니스 로직을 실행하고, 그 결과를 JSP 페이지에 전달하여 View를 구성합니다. 이 과정에서 서블릿은 중앙 집중식으로 요청을 관리하고, 요청에 따른 적절한 Model을 선택하여 데이터를 처리한 후, 결과를 JSP(View)로 전송합니다.

 이러한 구조는 JSP 모델 1과 비교할 때 명확한 분리와 구조적인 이점을 제공합니다. JSP 모델 1에서는 JSP 페이지가 직접 요청을 받고, 비즈니스 로직 처리와 데이터 표현을 모두 담당하는 반면, JSP 모델 2는 이 두 기능을 서블릿(Controller)과 JSP(View)가 분리하여 수행함으로써 더욱 효율적이고 체계적인 개발이 가능합니다. 이 분리는 코드의 재사용성과 유지 관리의 용이성을 향상시키며, 전체적인 애플리케이션의 설계를 더욱 깔끔하고 관리하기 쉽게 만듭니다.

 또한, JSP 모델 2는 MVC 패턴의 이점을 최대한 활용하여, 각 구성 요소의 책임을 명확히 하고, 애플리케이션의 확장성과 유연성을 높이는 데 중점을 둡니다. 서블릿이 Controller로서의 역할을 분명히 하여, 다양한 View와 Model을 더욱 효과적으로 연결하고 조정할 수 있습니다. 이렇게 함으로써, 애플리케이션은 더욱 견고하고, 확장 가능하며, 다양한 요구 사항에 대응하기 쉬워집니다.


(3) 결론

 MVC, JSP 모델1, JSP 모델2 어느것을 쓰더라도 성능에서 별 차이가 나지는 않습니다. 하지만, 이러한 모델들은 애플리케이션의 유지보수성, 확장성, 그리고 코드의 명확성 측면에서 중요한 차이를 보입니다.

JSP 모델 1에서는 비즈니스 로직과 프레젠테이션 로직이 JSP 페이지 내에서 혼재되어 있어, 애플리케이션의 복잡성이 증가하고, 장기적인 유지보수가 어려워질 수 있습니다. 반면, JSP 모델 2는 MVC 패턴을 더욱 효과적으로 구현합니다. 서블릿이 Controller 역할을 맡아 요청을 처리하고, View와 Model을 분리함으로써, 각 컴포넌트의 재사용성과 테스트 용이성이 향상됩니다.

이러한 구조적 차이는 특히 대규모 프로젝트나 장기적인 프로젝트 관리에서 중요해집니다. 명확한 역할 분리와 구조화된 코드는 개발 과정에서의 협업을 촉진하고, 새로운 기능 추가나 기존 기능의 수정을 용이하게 합니다. 또한, 잘 정의된 MVC 구조는 새로운 개발자가 프로젝트에 참여할 때 학습 곡선을 줄여주고, 전체적인 프로젝트의 가독성과 관리성을 향상시킵니다.

따라서, 성능 측면만을 고려하기보다는 프로젝트의 규모, 유지보수 요구사항, 팀의 작업 흐름 등을 고려하여 적절한 모델을 선택하는 것이 중요합니다. JSP 모델 2는 이러한 측면에서 MVC 패턴의 장점을 극대화하고, 현대 웹 애플리케이션 개발에 더 적합한 접근 방법을 제공합니다.