[Spring] 스프링(Spring)이란?

 

 

 

 

스프링(Spring)이라는 단어는 웹 개발을 공부해봤다면 한번 쯤은 꼭 들어봤을 만큼 유명합니다. 

또한 스프링과 함께 스프링 부트(Spring Boot) 묶여 자주 언급되곤 합니다. 

 

스프링에서 공부한 내용을 포스팅하기에 앞서, 

누군가 저에게 "스프링이 도대체 뭐야? 스프링 부트는 또 뭐고?" 라고 물어본다면

정확하게 스프링이 무엇이고 스프링 부트가 무엇이라고 대답하지 못하겠다는 생각이 들었습니다.

그래서 두 개의 포스팅에 걸쳐서 스프링과 스프링 부트에 대해 알아보고 정리해보기로 했습니다. 

 

 

 

 

1.  스프링(Spring)이란?

 

 

"자바 언어를 기반으로 엔터프라이즈 개발을 위한 경량형 오픈소스 프레임워크"

 

1-1. 프레임워크(Framework)

 

사실 스프링은 '스프링 프레임워크'가 좀 더 정확한 용어입니다. 즉, 스프링은 프레임워크입니다. 

프레임워크란 애플리케이션을 구축할 때 공통적인 개발에 필요한 공통적인 개발 환경을 제공해주는 프로그램입니다.

좀 더 풀어서 말하자면 설계 기반의 코드와 코드를 사용자 정의에 따라 확장시킬 수 있는 라이브러리를 개발자에 제공해 개발자로 하여금 반복적인 재사용 코드 작성 대신 진짜 프로그램의 기능에 집중할 수 있게 해주는 것입니다. 

 

 

1-2. 엔터프라이즈 개발을 위한 경량형 

 

엔터프라이즈(Enterprise)급 개발이란 기업으로 대상으로 대규모 데이터 처리와 트랜잭션이 동시에 여러 사용자로부터 일어나는 큰 규모의 환경을 처리하는 개발을 뜻합니다. 왜 하필 엔터프라이즈 개발이었을까요? 이것은 스프링이 어떻게 탄생하게 되었는지 배경과 관련이 있습니다. 스프링의 기원이 되는 책은 그 당시 EJB와 같은 자바 엔터프라이즈 기술들이 가지는 복잡함과 무겁고 느린 점을 비판하면서 이와 반대로 단순한 개발툴과 기본적인 개발환경만으로 엔터프라이즈 개발이 가능함을 설명하였고 이는 이후에 스프링으로 발전하게 되었습니다. 

 

좀 더 구체적으로 들어가보면, 엔터프라이즈 시스템 개발은 많은 사용자의 요청을 동시에 처리해야 하며, 동시에 안정적이어야 하며 다양한 확장성을 갖춰야 합니다. 또한 비즈니스적 복잡함이 추가적으로 얽혀 있기에 규모가 커질수록 개발의 어려움 역시 증가할 수 밖에 없는 구조입니다. 스프링은 이를 객체지향과 DI 개념을 통해서 비즈니스 로직을 처리하는 코드와 엔터프라이즈 기술을 처리하는 코드를 분리시켜 엔터프라이즈 개발에서 가지는 문제를 해결하였습니다. 

 

즉, 스프링은 엔터프라이즈 개발의 복잡함을 제거하는 방법으로 이전의 무겁고 느린 기술들과는 다르게 기본적인 툴과 환경만으로 엔터프라이즈 개발을 편리하게 해주는 경량형 프레임 워크라는 것입니다. 

 

 

1-3. 오픈소스

 

오픈 소스란 특별한 라이선스를 취득할 필요 없이 누구든지 가져다 자유롭게 이용할 수 있다는 뜻입니다.  스프링은 이렇게 오픈소스 프로젝트 방식으로 개발되었습니다. 스프링은 오픈소스 라이선스 중에서도 비교적 제약이 적고 사용이 매우 자요로운 편인 아파치 라이선스 2.0을 따릅니다. 

 

Spring의 저장소  :  https://github.com/spring-projects/spring-framework

 

 

 

2. 스프링(Spring)의 핵심 개념 : 스프링 삼각형(Spring Triangle)

 

 

 

스프링의 핵심 개념들을 설명하기 위해 만든 그림으로, 스프링으로 개발한 애플리케이션의 기본 구조를 나타냅니다. 

스프링의 핵심 개념인 POJO 프로그래밍을 중심으로 POJO 프로그래밍을 가능하도록 지원하는 세가지 기술로 이뤄져있습니다.

 

 

2-1. POJO(Plain Old Java Object) 프로그래밍 

 

"평범한 구식 자바 객체라는 뜻으로 오래되고 단순한(보통의) 자바 객체를 이용하여 프로그래밍 하는 방식"

 

POJO란 용어는 마틴 파울러가 이전의 복잡하고 무거운 EJB보다 일반적이고 보통의 객체를 사용하는 것을 꺼려하는 이유에 보통의 객체에 EJB와 같은 명칭이 없기 때문이라며, 훨씬 편리한 보통의 객체를 사용하는것을 권장하기 위해서 POJO라는 용어를 만들었습니다. 

 

POJO 프로그래밍을 지향하는 가장 큰 이유는 코드가 간결해지기 때문입니다. 그로 인해 테스트하기에 더 좋아지며, 유연해지고, 요구사항에 따라 기술적 결정을 바꿀 수 있게 되었습니다. 

 

 

2-2. AOP (Aspect Oriented Programming) : 관점 지향 프로그래밍

 

"어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나눠 각각의 관점을 기준으로 각각 모듈화를 하는 프로그래밍 방식"

 

좀 더 풀어쓰자면 핵심 비즈니스 로직과 관련이 없고, 여러곳에서 공통적으로 쓰이는 기능들을 따로 분리하여 애플리케이션 전반에 걸쳐 사용되는 기능을 재사용할 수 있도록 모듈화하는 프로그래밍 방식인 것입니다. AOP를 통해서 다른 서비스 모듈들이 본인의 목적에만 충실하고 그 외 사항들은 신경쓰지 않아도 됩니다. 

 

 

2-3. PSA (Portable Service Abstraction) : 이식 가능한 서비스 추상화 

 

"환경의 변화와 관계없이 일관된 방식으로 기술의 접근 환경을 제공하는 추상화 구조"

 

스프링에서 동작할 수 있는 라이브러리들은 POJO 원칙을 지키게끔 PSA 형태의 추상화가 되어있다는 것을 뜻합니다. 좀 더 자세히 말하면 스프링에는 특정 기술이나 환경에 영향을 받지 않게끔  객체를 POJO 기반으로 한번 더 추상화한 레이어를 갖고 있어 이를 통해서 일관된 서비스 추상화를 만들어 낸다는 것입니다. 이를 통해서 개발자는 라이브러리에 따라 의존성을 고려할 필요가 없어집니다. 

 

 

2-4. IOC/DI (Inversion of Control/Dependency Injection) 제어 반전/의존성 주입

 

"IOC : 프로그램의 제어권이 외부(프레임워크)로 역전되어 필요에 따라 스프링에서 사용자의 코드를 호출"

 

컨테이너가 개발자를 대신하여 객체가 생성될 때, 메서드가 호출될 때 등 제어권이 외부로 역전되어 필요에 따라 사용자의 코드를 호출하는 방식으로 개발자로 하여금 유연한 코드를 작성할 수 있게 합니다. 

 

 

"DI : 각각의 계층이나 서비스들 간에 의존성을 외부(프레임워크)가 서로 연결"

 

객체를 직접 생성해 의존관계를 주입하는 방식이 아니라, 외부(프레임워크)에서 생성해 의존관계를 주입해주는 방식입니다. 이를 통해서 코드가 단순해지며, 컴포넌트간의 결합도가 제거됩니다. 객체간의 의존관계를 한눈에 파악 할 수 있습니다.