스프링 기본 정리(1) 스프링은 무엇인가, 왜 좋은가, IoC란 무엇인가

스프링을 다시 정리하고자 한다.

너무 스프링 부트와 관련 기술만 생각했던 것 같다.

 

정리는 이일민님의 토비의 스프링 3.1 을 이용해 정리할 것이다.

 

옛날에 한 번 읽고... 중간에 다 읽지 못한 책이다. 

그 때는 자바 언어의 기본 문법만 알고 있었다. 대학생 때였고, 그 때에는 너무 많은 것이 이해가 가진 않았다.

지금은 아주 조금이라도 더, 객체지향에 대해 잘 이해하고 있다. 새로운 마음으로 다시 정리해보겠다.

 

당연히 개인적인 정리이다보니, 스스로가 이해한 방식대로 서술할 것이다.

혹시 누군가 이 글을 읽고 의아한 부분이 있다면, 토비의 스프링을 읽어보길 바란다. (혹은 구글링)

 

1. 스프링이란 무엇인가

 

스프링은 자바 엔터프라이즈 애플리케이션 개발에 사용되는 애플리케이션 프레임워크이다. 애플리케이션 프레임워크는 애플리케이션 개발을 빠르고 효율적으로 할 수 있도록 애플리케이션의 바탕이 되는 틀과 공통 프로그래밍 모델, 기술 API 등을 제공해준다.

 

•  애플리케이션의 기본 틀 -스프링 켄터이너
•  공통 프로그래밍 모델 -IOC/DI, 서비스 추상화, AOP
•  기술 API

 

•  애플리케이션의 기본 틀 -스프링 컨테이너

 스프링은 스프링 컨테이너 또는 애플리케이션 컨텍스트라고 불리는 스프링 런타임 엔진을 제공한다.

스프링컨테이너는 설정정보를 참고로 해서 애플리케이션을 구성하는 오브젝트를 생성하고 관리한다.

 

• 공통 프로그래밍 모델 -IoC/DI , 서비스 추상화, AOP

프레임워크는 애플리케이션을 구성하는 오브젝트가 생성되고 동작하는 방식에 대한 틀을 제공할 뿐만이 아니라, 애플리케이션 코드가 어떻게 작성돼야 하는지에 대한 기준도 제시해준다.

 이런 틀을 보통 "프로그래밍 모델"이라고 한다.

 

 

 1) 첫 번째는 IoC/DI 라고 불리는 오브젝트 생명주기와 의존관계에 대한 프로그래밍 모델이다.

 스프링은 유연하고 확장성이 뛰어난 코드를 만들 수 있게 도와주는 객체지향 설계 원칙과 디자인 패턴의 핵심 원리를 담고 있는 IoC/DI 를 프레임워크의 근간으로 삼고 있다. 스프링 프레임워크에서 동작하는 코드는 IoC/DI 방식을 따라서 작성돼야 스프링이 제공하는 가치를 제대로 누릴 수 있다.

 2) 두 번째는 서비스 추상화다.

 스프링을 사용하면 환경이나 서버, 특정 기술에 종속되지 않고 이식성이 뛰어나며 유연한 애플리케이션을 만들 수 있다. 이를 가능하게 해주는 것이 바로 서비스 추상화다. 구체적인 기술과 환경에 종속되지 않도록 유연한 추상 계층을 두는 방법이다.

 3) 세번째는 AOP다.

 AOP는 애플리케이션 코드에 산재해서 나타나는 부가적인 기능을 독립적으로 모듈화하는 프로그래밍 모델이다. 스프링은 AOP를 이용해서, 다양한 엔터프라이즈 서비스를 적용하고도 깔끔한 코드를 유지할 수 있게 해준다.

 

•  기술 API

스프링은 엔터프라이즈 애플리케이션을 개발의 다양한 영역에 바로 활용할 수 있는 방대한 양의 기술 API를 제공한다.

 

 스프링을 사용한다는 것은 바로 이 세 가지 요소를 적극적으로 활용하여 애플리케이션을 개발한다는 뜻이다. 클래스는 스프링 컨테이너 위에서 오브젝트로 만들어져 동작하게 만들고, 코드는 스프링의 프로그래밍 모델을 따라서 작성하고, 엔터프라이즈 기술을 사용할 때는 스프링이 제공하는 기술 API와 서비스를 활용해주도록 하면 된다.

 

 

2. 스프링은 왜 성공하였는가? => 왜 좋은가?

 

 스프링은 갑자기 나타는게 아니다. 자바를 통해 엔터프라이즈 시스템을 개발하는 데 좀 더 나은 방법과 전략을 찾으려고 고민하던 개발자들의 수고가 집약된 결정체다. 스프링은 사실상 자바 엔터프라이즈 표준 기술이라고 여겨진다.

 견고하고 건전한 자바 엔터프라이즈 개발의 핵심 가치에 충실하다. 스프링을 사용하는 개발자들은 자연스럽게 자바와 엔터프라이즈 개발의 기본에 충실한 베스트 프랙티스를 적용할 수 있고, 이상적인 개발 첡학과 프로그래밍 모델으르 이해하게 되고, 좋은 개발 습관을 체득하게 된다.

 

 스프링을 사용하는 개발자들이 스프링을 통해 얻게되는 두 가지 중요한 가치가 있다. 바로 단순함과 유연성이다.

 

 단순함 (Simplicity)

 스프링이 지향하는 것은 목적을 이룰 수 있는 가장 단순하고 명쾌한 접근 방법이다. 자바는 이상적인 객체지향 언어라는 캐치프레이즈를 내세우며 등장했다. 자바의 기술이 복잡해져가면서 자바의 본질인 객치제향 언어라는 특징을 점점 잃어버렸다. 스프링은 이 잃어버린 객체지향 언어의 장점을 다시 개발자들이 살릴 수 있도록 도와주는 도구다. 그래서 스프링으 강력히 주장하는 것은 가장 단순한 객체지향적인 개발 모델인 POJO 프로그래밍이다.

 

 유연성 (Flexibility)

 스프링은 유연성을 중요한 가치로 내세운다. 스프링은 유연성과 확장성이 매우 뛰어나다. 스프링의 유연성으로 인해 스프링은 다른 많은 프레임워크와 편리하게 접목돼서 사용될 수 있다. 스프링만큼 많은 서드파티 프레임워크의 지원을 받는 기술도 없다. 스프링 개발 철학 중 하나는 "항상 프레임워크 기반의 접근 방법을 사용하라" 이다. 스프링 기능의 대부분은 핵심 기능을 확장해서 발전시킨 결과물이다. 스프링은 개발자들에게 스프링을 확장해서 사용하도록 권장한다. ㅅ프링을 제대로 사용하려면 스프링을 필요에 맞게 확장해서 자신만의 프레임워크를 만들어서 사용할 줄 알아야 한다.

 

 

 요약하자면, 스프링은 개발자들이 자신이 원하는 목적을 쉽게 이루게 해준다. 자신이 짜고자 하는 코드에만 집중할 수 있게 해준다. 또한 뛰어난 개발자들이 짠, 객체지향의 결정체이기 때문에 유연성과 확장성이 뛰어난 프레임 워크이다. 스프링의 뛰어난 유연성으로 인해 스프링은 많은 서드파티 프레임워크의 지원을 받는 기술이다. 이런 모든 것들이 결국 개발자들이 자신이 원하는 목적을 쉽게 우리게 해주며, 자신의 코드에 집중할 수 있게 해준다.

 

 

 

3. IOC 에 대하여

 

Inversion Of Control 의 약자이다. 제어의 역전이라는 건, 간단히 프로그램의 제어 흐름 구조가 뒤바뀌는 것이라고 할 수 있다.

 일반적인 프로그램의 흐름은 main() 메소드와 같이 프로그램이 시작되는 지점에서 다음에 사용할 오브젝트를 결정하고,  결정한 오브젝트를 생성하고, 만들어진 오브젝트..... 하여간.

 프로그램 구조에서 각 오브젝트는 프로그램 흐름을 결정하거나 사용할 오브젝트를 구성하는 작업에 능동적으로 참여한다.

 

 모든 오브젝트는 능동적으로 자신이 사용할 클래스를 결정하고, 언제 어떻게 그 오브젝트를 만들지를 스스로 관장한다. 모든 종류의 작업을 "사용하는 쪽에서 제어하는 구조" 이다.

 제어의 역전이란 이런 제어 흐름의 개념을 거꾸로 뒤집는 것이다. 예를들어, 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않는다. 당연히 생성하지도 않는다. 또 자신도 어떻게 만들어지고 어디서 사용되는지를 알 수 없다. 모든 제어의 권한을 오브젝트 자신이 아닌 다른 대상에게 위임한 것이다.

 프로그램의 시작을 담당하는 main() 과 같은 엔트리포인트를 제외하면 모든 오브젝트는 이렇게 위임받은 제어 권한을 갖는 특별한 오브젝트에 의해 결정되고 만들어진다.

 

-예시-

 

 1. main() 메소드를 기반으로 제어되는게 아닌 코드

 원래는 main() 메소드에서 시작해서 개발자가 미리 정한 순서를 따라 오브젝트가 생성되고 실행되는 것이 일반적인 자바 프로그램의 흐름이다. 서블릿을 생각해보자. 서블릿에 대한 제어 권한을 가진 컨테이너가 적절한 시점에 서블릿 클래스의 오브젝트를 만들고 그 안의 메소드를 호출한다. 이렇게 서블릿이나 JSP, EJB처럼 컨테이너 안에서 동작하는 구조도 간단한 방식이지만 제어의 역전 개념이 들어가 있는 것이다.

 -> 일반적으로는 main() 에서 시작돼야 하는데, 서블릿을 실행 시키는 것은 main 메소드로부터가 아니라, 다른 컨테이너에 의해 실행됨. 제어의 권한을 컨테이너에게 넘김. 이 또한 제어의 역전이다. (물론 이 컨테이너 자체는 main 메소드로 인해 실행 됐겠지만)

 

 2. 디자인 패턴에서 나타나는 IoC

 템플릿 메소드 패턴과 같이, 추상 클래스를 상속한 하위 클래스의 메소드가 있다고 생각 해보자.  이 메소드는 애초에 자신이 어떻게 사용될지 모른다. 슈퍼 클래스의 템플릿 메소드에서 필요할 때 호출해서 사용한다. 즉 제어권을 상위의 템플릿 메소드에게 넘기는 것이다.

 -> 일반적으로 객체는 자신의 메소드를 자신이 호출한다. 헷갈릴 수 있으니 조금 더 정리해보자.

 A -> B 의 의존관계가 있고, A 가 B 의 메소드를 호출할 수 있다. 이 때 B의 메소드를 호출하는 것은 누구인가? A이긴 하지만 이 메소드 자체는 분명 B 오브젝트가 실행한다. 이 경우의 이 메소드의 제어건은 B에 있다. 애초에 객체지향의 객체는 자신의 메소드가 어떻게 실행되는지는 자신이 결정하는 것이 정상적이다.

 하지만 템플렛 메소드 패턴에서는 A 가 B의 메소드를 호출할 때, 사실은 B의 슈퍼클래스의 메소드를 호출한 것이며, 이 때 B에서 override해서 구현한 훅 메소드(혹은 추상 메소드) 는 B의 슈퍼클래스의 메소드에 의해 사용된다. 이 순간 B는 자신의 메소드가 어떻게 실행될 것인지를, 자신이 컨트롤 하지 않는다. 따라서 제어의 역전이라 할 수 있다.

 

 3. 프레임워크

 프레임워크도 제어의 역전 개념이 적용된 대표적인 기술이다. 프레임워크는 라이브러리의 다른 이름이 아니다. 라이브러리를 사용하는 애플리케이션의 코드는 애플리케이션의 흐름을 직접 제어한다.  하지만 프레임워큰느 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 프레임 워크 위에 갭라한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다. 개나소나 다 프레임워크로 불려도 되는 것이 아니다. 프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다.

 

이 뒤는 스프링의 IoC 로부터 다시 정리할 생각이다. 내용이 무지 방대 하므로 다음 편으로 넘기도록 하겠다.