정의: 엔터프라이즈용 Java 애플리케이션 개발을 편하게 할 수 있게 해주는 오픈소스 경량급 애플리케이션 프레임워크
경량급?
스프링은 수십개의 세부 모듈 및 수십만줄의 방대한 코드로 이루어진 프레임워크이지만 기존에 스프링 대신 사용하던 기술들과 비교하여 스프링을 사용할 때 개발자가 작성해야 할 코드가 상대적으로 단순하다는 것을 의미한다.
애플리케이션 프레임워크?
애플리케이션을 개발하는 데에 있어 필요한 모든 업무 분야 및 모든 기술과 관련된 코드들의 뼈대를 제공한다.
스프링(Spring) 특징
POJO(Plain Old Java Object) 프로그래밍 지향
: 즉 순수 Java만을 통해서 생성한 객체를 의미한다. 순수 Java만을 사용한다는 것은 Java 및 Java의 스펙에 정의된 기술만 사용한다는 의미이다.
Question. 그렇다면 왜 POJO가 중요할까?
만약 객체가 사용하고 있는 기술이 Deprecated되거나, 개선된 신 기술이 등장하여 기존 기술과 관련된 코드를 모두 고쳐야하는 상황이 발생하면 해당 기술을 사용하고 있는 모든 객체들의 코드를 전부 바꿔줘야한다. 이는 해당 객체가 외부 모듈에 직접적으로 의존하고 있기때문에 자연스럽게 발생하는 문제이다.
반면, POJO는 순수 Java만을 사용하여 만든 객체이므로 특정 기술이나 환경에 종속되지 않는다. 따라서, 외부 기술이나 규약의 변화에 얽매이지 않아, 보다 유연하게 변화와 확장에 대처할 수 있다.
→ 객체지향 설계를 제한없이 적용할 수 있으며, 코드가 단순해져 테스트와 디버깅 또한 쉬워진다.
→ 이처럼 비즈니스 로직을 구현하는 데에 POJO를 적극적으로 활용하는 프로그래밍 패러다임을 POJO 프로그래밍이라고 한다.
스프링의 가장 큰 특징은 POJO 프로그래밍을 지향하는 것이다. 이제는 POJO 프로그래밍을 위해 스프링이 지원하는 기술인 IoC/DI, AOP, PSA에 대해 알아보자.
1. IoC/ DI (Inversion of Control/ Dependency Injection, 제어의 역전/ 의존성 주입)
Java 애플리케이션의 동작 흐름에서 객체들 간의 관계를 적절히 맺어주는 것이 중요한 요소이다.
A 인스턴스가 B 인스턴스의 메서드를 호출하고 있다면 A는 B와 의존관계를 맺은 것이 되며, 이 둘의 관계를 A가 B의 기능을 가져가 사용하기 때문에 "A가 B에 의존하는 관계"라고 표현할 수 있다.
위 예제에서 A는 자신이 사용할 객체를 스스로 생성하지 않고, 생성자를 통해 외부로부터 받아오고있다. 즉, A는 자신이 사용할 객체를 알지 못하며, 그저 i에 할당된 인스턴스에 example()이라는 메서드가 존재한다는 것만 알고있다.
그렇다면 누군가 A가 사용할 객체를 결정하고 생성해서 A가 인스턴스화될 때 인자로 전달해주어야만 한다. 그래야 A는 B or C의 example() 메서드를 호출할 수 있기때문이다.
그 누군가가 바로 스프링이다. 스프링을 사용하면 애플리케이션의 로직 외부에서 A가 사용할 객체를 별도로 설정할 수 있다. 개발자가 설정 클래스 파일에 A가 사용할 객체를 C로 설정해두면, 애플리케이션이 동작하면서 스프링이 설정 클래스 파일을 해석하고, 개발자가 설정해준대로 C객체를 생성하여 A의 생성자의 인자로 C를 전달해준다.
이처럼 개발자가 아닌 스프링이 A가 사용할 객체를 생성하여 의존 관계를 맺어주는 것을 IoC(Inversion of Control)라고 하며, 그 과정에서 C를 A의 생성자를 통해 주입해주는 것을 DI(Dependency Injection)라고 한다.
2. AOP (Aspect Oriented Programming, 관전 지향 프로그래밍)
애플리케이션을 개발할 때에 구현해야하는 기능들은 크게 공통 관심 사항과 핵심 관심 사항으로 분류할 수 있다.
핵심 관심 사항은 애플리케이션의 핵심 기능과 관련된 관심 사항으로, 커피 주문 애플리케이션을 예로 든다면 메뉴 등록하기, 주문하기, 주문 변경하기 등이 있다.
반면, 공통 관심 사항은 모든 핵심 관심 사항에 공통적으로 적용되는 관심 사항들을 의미한다.
이 때, 필연적으로 공통 관심 사항과 관련된 코드가 중복될 수 밖에 없다. 이처럼 코드가 중복되어져 있는 경우, 공통 관심사항을 수행하는 로직이 변경되면 모든 중복 코드를 찾아서 일일이 수정해주어야만 한다.
이러한 코드의 중복이라는 문제를 해결하기 위해서 애플리케이션 전반에 걸쳐 적용되는 공통 기능을 비즈니스 로직으로부터 분리해내는 것을 AOP(Aspecti Oriented Programming)이라고 한다.
AOP는 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다. 여기서 모듈화란 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다.
3. PSA (Portable Service Abstraction, 일관된 서비스 추상화)
스프링은 Java 백엔드 개발에 있어 핵심적인 역할을 수행하는 프레임워크이며, 백엔드 개발에서 데이터베이스는 떼어놓기 어렵다. 웹 서버는 데이터베이스와 소통하며 웹 클라이언트의 요청을 처리해야하기 때문이다.
만약, MySQL을 사용하여 개발을 완료했는데, MariaDB로 데이터베이스가 바뀌면 기존 DB와 새로운 DB간에 사용 방법이 다른 코드를 모두 찾아 일일이 수정해주어야한다.
그러나, 스프링을 사용하면 동일한 사용방법을 유지한 채로 데이터베이스를 바꿀 수 있다. 이는 스프링이 데이터베이서 서비스를 추상화한 인터페이스를 제공해주기 때문에 가능하다. 즉, 스프링은 Java를 사용하여 DB에 접근하는 방법을 규정한 인터페이스를 제공하고 있고, 이를 JDBC(Java DataBase Connectivity)라고 한다.
각 DB를 만든 회사들은 자신의 DB에 접근하는 드라이버를 Java 코드의 형태로 배포하는데, 이 드라이버에 해당하는 Java 코드의 클래스가 JDBC를 구현한다. 따라서, JDBC 기반으로 DB 접근 코드를 작성하면, 이후에 DB가 바뀌어도 기존에 작성한 데이터베이스 접근 로직을 그대로 사용할 수 있다.
이러한 JDBC처럼 특정 기술과 관련된 서비스를 추상화하여 일관된 방식으로 사용될 수 있도록 한 것을 PSA(Portable Service Abstraction)라고 한다.
스프링부트(SpringBoot)란?
스프링은 기존 기술의 복잡성을 크게 줄인 프레임워크지만, 그럼에도 불구하고 스프링을 사용하기 위해서는 여러가지의 사항들을 설정해주어야한다. 스프링부트는 스프링으로 애플리케이션을 만들 때에 필요한 설정을 간편하게 처리해주는 별도의 프레임워크이다.
스프링부트를 사용하면 초기 설정을 간편하게 할 수 있는 것 외에도 몇 가지 장점이 있다.
기존에는 배포를 할 때에 별도의 외장 웹 서버를 설치하고, 프로젝트를 War 파일로 빌드하여 배포를 진행했는데, 이러한 방식은 처리 속도가 느리며 번거롭다는 단점을 가진다. 반면, 스프링 부트는 자체적인 웹 서버를 내장하고 있어, 빠르고 간편하게 배포를 진행할 수 있다. 또한, 독립적으로 실행 가능한 Jar파일로 프로젝트를 빌드할 수 있어, 클라우드 서비스 및 도커와 같은 가상화 환경에 빠르게 배포할 수 있다.
웹 서버(Web Server)
웹 클라이언트로부터 http요청을 받아서 컨텐츠를 제공하는 프로그램이다. 컨텐츠라는 것은 정적인 컨텐츠와 동적인 컨텐츠로 나뉘는데 그 종류에 따라서 서비스 방식이 바뀐다.
1) 정적인 컨텐츠 제공: WAS를 거치지않고 바로 클라이언트로 자원을 제공한다.
2) 동적인 컨텐츠 제공: 클라이언트의 요청을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달한다.
ex) Apache, Nginx etc..
웹 어플리케이션 서버(Web Application Server)
동적인 컨텐츠를 제공하기 위해 만들어진 Application Server로 클라이언트의 http요청을 받아 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어다. 내부적인 구조로 웹 서버와 웹 컨테이너가 들어있다.
즉, WAS = Web Server + Web Container
1) Web Container: 자바일 경우 JSP, Servelet Class파일을 실행하기 위한 실행 환경을 제공하는 역할, 주로 DB와 함께 실행된다.
2) Web Server: 웹 서버가 WAS안에도 존재한다. 역시 URL 주소의 해석을 맡아 컨텐츠를 넘겨주고, 요청된 URL이 Servlet Class 또는 JSP 파일의 경우 Web Container가 처리하도록 요청을 넘긴다. 처리 후에 그 결과를 다시 받아 클라이언트에게 제공한다.
ex) Tomcat, JBoss, Jeus, Web Sphere etc..
※ WAS 내부에도 Web Server가 존재하는데 굳이 WS를 거치는 이유는?
1) 기능을 분리하여 서버 부하 방지
2) 물리적으로 분리하여 보안 강화
3) 여러 대의 WAS를 연결 가능
4) 여러 웹 WAS 서비스 가능 (php와 java를 함께 사용)
Aache & Tomcat
Aache
→ 세계에서 가장 많이 쓰는 웹 서버(WS) 중 하나이다. Apache 재단에서 만든 HTTP서버이며 이 서버가 굉장히 다양하고 기능적인 면에서 우수하다. 또 구축이 쉽다는 이유때문에 많이 사용한다. 단, Apache자체만으로 엄청 무겁고, Squid와 함께 Slowloris 취약점이 발견되었기에, 보통 프로그래밍 능력이 능숙한 사람들이나, 대형사이트 운영자는 Nginx, IIS를 주로 사용한다.
Tomcat
→ 자바 서블릿을 실행하고 jsp코드가 포함되어있는 웹페이지를 만들어준다. 자바 서블릿과 jsp 규격의 '참조용 구현'으로 평가되고 있다. 쉽게 말하면 톰캣은 WS에서 넘어온 동적인 페이지를 읽어들여 프로그래밍을 실행하고 그 결과를 다시 html으로 재구성하여 아파치에게 되돌려 준다.
+ 톰캣 WAS
- 서블릿 컨테이너: HTTP 요청을 받아 웹 페이즈를 동적으로 생성하는 역할
- 컨테이너: 동적인 데이터를 받아 가공하여 정적인 파일(HTML)로 만드는 것
- 서블릿: 클라이언트 요청을 받아 요청을 처리하고, 그 결과를 클라이언트에게 제공하는 자바 인터페이스
+ Spring ..
Jar: tomcat 내장한 빌드 파일
war: tomcat 내장하지 않은 필드 파일, 다른 WAS를 연결할 수 있다.
출처
스프링과 스프링부트(Spring Boot)ㅣ정의, 특징, 사용 이유, 생성 방법 (codestates.com)
[Spring] 스프링 AOP (Spring AOP) 총정리 : 개념, 프록시 기반 AOP, @AOP (tistory.com)
'이론' 카테고리의 다른 글
2024-07-30 (0) | 2024.07.30 |
---|---|
2024-07-29 (0) | 2024.07.29 |
DB 발전 과정 (1) | 2023.11.14 |
Session VS JWT (1) | 2023.11.12 |
싱글톤(singleton) 패턴 (0) | 2023.11.09 |