코딩짜는 일상

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 12차 - 스프링 본문

TIL

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 12차 - 스프링

Remily 2025. 10. 1. 01:48
반응형

📚 서론

지난주에는 Servlet과 JSP에 대해 알아보았습니다.

덕분에 웹 페이지를 동적으로 만들 수 있어서 다양한 기능을 만들어볼 수 있었죠.

이제야 그럴듯한 웹 프로젝트가 만들어지는군! 출처:giphy

 

 

 

하지만 이 또한 완벽하지 않았습니다.

 

HTML 코드와 자바 코드가 완전히 분리된 건 아니라서

프로젝트 규모가 커지면 커질수록 뷰와 로직이 제대로 분리되지 않았습니다.

 

요청 처리, 비즈니스 로직, 데이터 접근, 화면 출력, 반복되는 코드와 설정 등등...

 

 

다양한 내용이 JSP 파일에 섞이기 시작했고 그럴수록 유지보수는 더욱 어려워졌습니다.

뿐만 아니라 기능을 사용할 때마다 매번 객체를 생성하고 관리하는 것도 번거로웠죠.

 

전부 하나의 파일에 담겨서 뭐가 뭔지 모르겠어! 출처: giphy

 

 

그리하여 귀찮은 작업은 위임하고

반복되는 작업도 공통으로 처리해 버리고

로직과 뷰는 분리될 수 있도록 스프링 프레임워크(Spring Framework)가 탄생하게 되었습니다.

 

스프링의 목표는 개발의 복잡성을 줄이고 개발자가 컨텐트에만 집중할 수 있도록 지원하는 것이라고 합니다.

 

 

 

 

 

🎷 DI (Dependency Injection)

그렇다면 스프링은 어떤 방법으로 개발의 복잡성을 줄였을까요?

 

 

이때 가장 먼저 소개되는 스프링의 핵심 개념은 의존성 관리입니다.

 

설명을 위해 A 클래스가 B 클래스의 기능을 사용하는 상황을 가정해 보겠습니다.

class A {
	public void A() {
    	b = new B(); // B 클래스 객체 생성
    }
}

 

지금까지는 위 코드처럼 A 클래스가 B 클래스의 기능을 사용하기 위해

B의 객체를 직접 생성한 다음 사용하는 방식을 써왔습니다.

 

이것을 A 클래스는 B 클래스에 의존 또는 종속한다 라고 말합니다.

 

 

이러한 의존성,

기능을 사용하기 위해 해당 클래스의 객체를 생성하거나 닫아주는 모든 관리 행위를

사용하는 주체가 아닌 외부에서 담당하고 필요하다면 주입해주는 것을 의존성 주입이라고 합니다.

 

스프링에선 스프링 컨테이너가 이 의존성 주입을 담당하는데

설정 한 번으로 객체를 생성&관리하고 알아서 클라이언트에게 전달합니다.

 

 

스프링 컨테이너는 공용으로 사용할 객체라면 하나만 만들어 같이 쓸 수 있게 해주거나

각자 사용하는 객체라면 복사해서 클라이언트에게 나눠줍니다.

뿐만 아니라 참조가 사라지면 객체를 필요한 곳에 자동으로 재배치해주어 효율성을 높였습니다.

스프링 컨테이너: hey~객체 여러분! 제 지시에 따라 이동해주세요~😎 출처: giphy

 

 

뿐만 아니라 확장성도 뛰어납니다.

 

A 클래스의 객체를 30개 정도 만들어서 사용하고 있다고 가정했을 때,

본래라면 모든 객체를 일일이 바꿔줘야겠지만

의존성 주입을 사용하면 설정에서 클래스명을 바꿔주는 것만으로도 간단히 다른 클래스로 교체할 수 있습니다.

 

 

 

의존성 주입을 사용하는 방법에는

  1. XML을 이용한 방법
  2. 자바가 제공하는 어노테이션을 사용한 방법

이렇게 2가지가 있습니다.

 

 

 

 

 

🎺 Spring MVC(Model View Controller) 패턴

스프링의 두 번째 핵심 개념은 MVC 패턴입니다.

 

 

이름 그대로 model, view, controller로 구성된 구조이며

 

컨트롤러Controller는 사용자의 요청을 받아 처리하고

모델Model은 DB와 통신하여 요청받은 로직을 처리해 응답을 회신하고

뷰View는 도출한 응답을 클라이언트의 브라우저에 보여주기 위해 화면을 구성하고 전달합니다.

MVC

 

 

 

 

스프링은 여기서 몇 가지 요소가 더 포함된 프론트 컨트롤러 방식을 채택하고 있습니다.

 

이 방식은 프론트 컨트롤러 한 곳에서 모든 클라이언트의 요청을 처리하는 방식인데

프록시가 없는한 클라이언트가 가장 처음 마주하는 요소로써 공통 처리 로직을 실행하기 좋습니다.

 

즉, 인증과 로깅, 예외처리 등이 프론트 컨트롤러에서 이뤄집니다.

프론트 컨트롤러 MVC

 

위 다이어그램은 프론트 컨트롤러 MVC 방식을 도식한 것입니다.

 

클라이언트가 프론트 컨트롤러에 요청을 전달하면

프론트 컨트롤러는 가장 먼저 핸들러 맵퍼에게 요청에 맞는 컨트롤러가 어디있는지 물어봅니다.

 

컨트롤러를 회신받으면 받은 응답을 해당 컨트롤러로 전달하고

컨트롤러는 다시 서비스로 전달하고

서비스는 응답에 맞는 비즈니스 로직을 처리합니다.

이때 DB와 통신이 필요하다면 DAO에 요청합니다.

 

서비스가 응답 내용을 만들어 컨트롤러에 회신하면

컨트롤러는 이 응답을 출력할 뷰를 지정하여 같이 프론트 컨트롤러로 전달합니다.

 

프론트 컨트롤러는 뷰 리졸버에 전달해 뷰를 검색하고

해당 뷰는 응답 내용을 토대로 화면을 구성하여 다시 프론트 컨트롤러로 전달하며

프론트 컨트롤러는 이 최종 응답을 클라이언트에게 전달합니다.

 

 

 

 

 

🔥 결론

스프링이 귀찮은 객체 관리도 대신해주고 뷰와 비즈니스 로직을 분리해주기도 했지만

xml 파일을 통한 설정 과정이 특히 어렵고 번거롭다고 느꼈습니다.

 

아니나 다를까 전 이것 때문에 무수한 에러 메시지를 봐야만 했습니다...😭

매핑을 했는데 왜 못 찾겠단거야?!😵 출처:giphy

 

 

그런데 이러한 불편함을 해소하고자 스프링 부트가 개발된 것이라고 하네요!

 

 

다음주는 요 스프링 부트를 다뤄보도록 하겠습니다.

 

지금 강의에서 배우는 중인데

확실히 새로운 프로젝트를 아주 빠른 시간에 생성할 수 있어서 편하네요!😎✨

반응형