본문 바로가기
  • Where there is a will there is a way.
개발/spring

스프링이란 무엇인가?

by 소확행개발자 2020. 7. 12.

스프링에 대해 가장 잘 알려진 정의는 이렇다

 

자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크 

 

우리가 자바 개발을 하면서 컬렉션 프레임워크라고 불리우는 프레임워크를 사용한 경험이 있다. ( 물론 스프링도 )

그런데 왜 스프링은 애플리케이션 프레임워크라고 하는 것일까? 

 

애플리케이션 프레임워크

스프링의 기원이 된 예제 애플리케이션의 프레임워크는 책에서 설명한 각종 자바 엔터프라이즈 개발 전략의 핵심을 담아서 개발됐다. 자바 엔터프라이즈 개발의 전 계층에 등장하는 기술과 애플리케이션의 전 영역에 대한 효과적인 설곋와 개발 기법을 다루고 있기 때문에 자연스럽게 애플리케이션의 전 영역을 지원하는 종합적인 애플리케이션 프레임워크라고 하는 것이다.

 

스프링의 일차적인 존재 목적은 핵심 기술에 담긴 ㅍ로그래밍 모델을 일관되게 적영해서 애플리케이션을 편리하게 개발하게 해주는 애플리케이션 프레임워크로 사용됨을 기억하자 

-> 단순히 MVC 지원 ORM 지원 AOP IoC/DI 로 만 보는게 아니라

 

경량급 

스프링은 예전 EJB ( Enterprice javaBeans ) 기술과 비교하여 단순한 서버환경인 톰캣이나 제티에서도 완벽하게 동작한다. 

 

스프링의 목적

 

그저  스프링을 가져다가 어떻게든 사용해서 개발만 하면 스프링을 적용했고 스프링의 장점을 개발에 사용했다고 말할 수 있을까 ?

이렇게 사용하면 스프링이 주는 혜택을 전혀 누리지 못하고 사용하는 의미가 없다.

 

기존에는 자바 엔터프라이즈 시스템 개발이 너무 복잡해서 대부분 개발에 실패하거나 정해진 기간과 예산을 맞추지 못한 경우아 많았다고 한다. 그렇다면 왜 복잡할까 ?

  • 기술적인 제약조건과 요구사항이 늘어나기 때문
  • 앤터프라이즈 애플리케이션이 구현해야 할 핵심기능인 비즈니스 로직의 복잡함이 증가하기 때문

스프링의 핵심 로직은 기술적인 복잡함을 애플리케이션 로직의 복잡함에서 제거하는 데 목표를 뒀다.

-> 비침투적인 기술로 기술의 적용 사실이 코드에 직접 반영되지 않는다는 특징을 이용했다. 

 

스프링의 기술적인 복잡한 문제를 해결하는 전략

  • 기술에 대한 접근 방식이 일관성이 없고 특정 환경에 종속적이다. 
    • 서비스 추상화를 통해서 로우레벨 기술 구현 부분과 기술을 사용하는 부분에 인터페이스로 분리
  • 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다.
    • AOP 를 통해서 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 기술

스프링의 기술과 전략은 객체지향이라는 자바 언어가 가진 강력한 도구를 극대화해서 사용할 수 있도록 돕는 것이라고 볼 수 있다. 스프링은 단지 거들 뿐이다. 

 

POJO 프로그래밍 

스프링의 핵심 개발자들은 스프링의 정수는 엔터프라이즈 서비스 기능을 POJO 에 제공하는 것이라고 했다. 이 이야기는 엔터프라이즈 기술 POJO ( 트랜잭션 같은 기술 ) 과 애플리케이션 POJO 와 분리했다는 이갸이다. 

 

다음은 우리가 스프링을 공부할때 흔히 보게되는 삼각형이다.

 

POJO를 이용해서 만든 애플리케이션 코드와 POJO 가 어떻게 관계를 맺고 동작하는지를 정의해놓은 설계정보이다. 

 

그렇다면 POJO 프로그래밍은 어떻게 해야하는가 ? 아래 두가지 조건을 만족해야 POJO 라고 불리울 수 있다.

 

  • 특정규약에 종속되지 않는다.
    • 자바 언어와 꼭 필요한 API 외에는 종속되지 않아야 한다. 
  • 특정 환경에 종속되지 않는다. 
    • 진정한 POJO 란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다. 

특정한 기술과 환경에 종속되지 않는 오브젝트는 그만큼 깔끔한 코드가 될 수 있다. 로우레벨의 기술과 환경에 종속적인 코드가 비즈니스 로직과 함께 섞여 나오는 것만큼 지저분한 코드도 없다. 그런 코드는 개발하기도 힘들고, 오류를 찾고 디버깅도 힘들다. 테스트 코드를 작성하기도 힘들다. 

 

 

댓글