[Spring Framework] 1화 스프링 프레임워크란?

 스프링 프레임워크를 사용한 지 10년이 조금 넘은 지금 생각해보니 어느새 루틴 하게 사용하기만 하고, 제대로 스프링에 대해서 다루지 않기 시작한 것 같은 마음에, 마음을 다잡고, 10년 동안 느낀 스프링 프레임워크와 그 속에서의 노하우에 대해 이야기해볼까 합니다.

 

 유통업과 제조업을 드나들어보니 어떤 분야에서는 10년전에 도입된 것들이 또 어떤 분야에서는 신기술이 될 수도 있다는 것을 최근 많이 느끼는데, 이 이야기를 하는 이유는 10년 전 처음 스프링 프레임워크를 배울 때도 이미 신기술이라 하기 애매한 스프링이 현재에도 신기술일 수 있다는 점에서 새삼 이야기를 꺼내봅니다. (사족이 길다)

 

 스프링 프레임워크란 그럼 무엇일까요?

로드 존슨이 2002년에 출판한 자신의 저서인 Expert One-on-One J2EE Design and Developement 에 선보인 코드를 기반으로 시작하여 점점 발전하게 되었다. [2] 이 프레임워크는 2003년 6월에 최초로 아파치 2.0 라이선스로 공개되었으며 주요 버전 이력은 다음과 같다. 1.0 : 2004년 3월 2.0 : 2006년 10월 2.5 : 2007년 11월 3.0 : 2009년 12월 3.1 : 2011년 12월 4.0 : 2013년 12월 5.0 : 2017년 9월 2006년에 1.2.6 버전으로 Jolt Productive Award[3]와 Jax Innovation Award[4]를 수상하였다. 출처: 위키피디아 "스프링프 레임워크"

 흔히 JAVA는 OOP(Object-Oriented Programming, 객체지향 프로그래밍)에서 빼놓을 수 없는 언어라고 할 수 있습니다. (10년 전에는 이게 강점이 없는데, 이제는 뭐 웬만하면 OOP라 강점이라 하기도 애매해지고 있죠.)

 이 OOP라는 녀석을 개발하다 보면 어느 순간 이런 생각이 듭니다. "맨날 만드는 기능들이 반복적인데 (패턴) 이걸 그냥 레고 블록처럼 블록단위로 (모듈화) 만들어 두고 필요할 때마다 필요한 블록만 끼워서 만들 순 없을까?"라는 개념에서 사람들이 내놓은 게 MVC모델과 같은 방법론들이었습니다. 이런 모듈들을 끼워서 놀 수 있는 공간이 바로 프레임워크라는 녀석이었고, 초창기에는 EJB가 기업 사이에서는 유행하기도 했습니다. 다만, EJB는 구축이 어렵고 배워야 하는 게 많아 JAVA를 하는 사람들 사이에서도 쉽게 다가가기 어려운 분야였었습니다. 그러던 와중에 스프링이 도입되고, 정부에서 전자정부 프레임워크 전부터 스프링을 도입하여 활용하기 시작하면서, 업계에서도 스프링 바람이 불기 시작했습니다.

 

  왜 스프링일까?

 스프링의 장점은, POJO 개발이 가능하다는 점입니다. 많이들 이야기하는데 이게 뭘까? 그리고 이게 그렇게 중요해??라고 생각할 수 있지만, 이 POJO덕에 스프링이 가장 쉽게 개발자들에게 다가올 수 있는 강점이었습니다.

 

 POJO (Plain Old Java Object)란 단어도 스프링 프레임워크가 나오면서 많이 접하게 되는 단어인데 (스프링이 POJO를 지원하므로), POJO란, 일반적으로 프레임워크를 사용 시에 지켜야 하는 수칙들을 꼭 지키지 않고, 기본 Java 언어로 사용 가능함을 말합니다. 바꿔 말하면, Java로 System.out.println 정도만 찍을 줄 알면, 기존에 구축된 스프링 프레임워크 기반 프로젝트에서 쉽게 Log를 찍어볼 수 있다는 얘기입니다. (물론, Logging을 위한 api가 있지만, 이건 추후에 다루도록 하겠습니다.)

 

 때문에, Java를 조금이라도 알고 있거나, 또는 모르더라도 부분적으로 프로젝트를 진행함에 무리가 없기 때문에 스프링 프레임워크를 제대로 구축 가능한 사람 한 명만 있다면, 프로젝트 팀원 전체가 프레임워크를 모두 이해할 필요가 없기 때문에 스프링 프레임워크가 이용되었습니다.

 

  스프링 프레임워크의 특징

1. 경량 컨테이너로서 자바 객체를 직접 관리한다. 각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다. 2. 스프링은 Plain Old Java Object 방식의 프레임워크이다. 일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리 등을 지원하기에 용이하고 객체가 가볍다. 3.스프링은 제어 반전(IoC : Inversion of Control)을 지원한다. 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다. 4.스프링은 의존성 주입(DI : Dependency Injection)을 지원한다. 각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다. 5.스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented Programming)을 지원한다. 따라서 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다. 6.스프링은 영속성과 관련된 다양한 서비스를 지원한다. iBATIS나 하이버네이트 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다. 7.스프링은 확장성이 높다. 스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리가 이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다. 출처: 위키피디아 "스프링프 레임워크"

 

 1번의 경우에는 보통 스프링 프레임워크 구동 시 모든 객체가 메모리에 올라가는 게 아닌, 필요시에 객체를 가져와서 구동하는 방식을 말하는데, 최근에 웬만한 컨테이너들이 더 가볍기 때문에 경량 컨테이너라는 의미가 조금 퇴색된 느낌도 있지만, 과거 EJB 등의 경우에 구동이 매우 느렸던 거에 비해 가벼워진 걸 이야기합니다. (현재는 경량이라 하기엔 살짝 부끄러운 정도)

 

 2번의 경우 조금 전에 이야기한 POJO의 이야기입니다.

 

 3번의 경우 1번과 조금 이야기가 비슷할 수 있는데, 모든 객체가 메모리에 올라온 게 아닌 필요시에 호출되어 올라오는 방식이기 때문에 프레임워크에서 제어권을 갖는다는 이야기입니다.

 

 4번의 경우 의존성 주입은, 이런 경우입니다. 제가 만약 프로젝트를 만들어두고, A지점과 B지점에 납품하는 경우, A지점의 경우 미국에 있고, B지점의 경우 스페인에 있다고 하면, 각각을 따로 만드는 게 아니라, 기본 가이드라인은 만들어두고, 설정에 따라 A지점의 경우 영어로, B지점의 경우 스페인어로 서비스되도록 설정을 해줄 수 있습니다. (IT적으로는 오라클 DB를 사용하는 지점과 MySQL을 이용하는 지점에 동시에 납품되는 경우) 이럴 때, 기존에 implements로 지정해주는 대상을 스프링 프레임워크의 설정값으로 관리 가능하다는 이야기입니다.

 

 5번은 트랜잭션이나 로깅, 보안 등과 같이 이야기하는데, 3가지 예시를 들 수 있습니다.

 트랜잭션, 만약 순차적으로 SQL문을 호출하는 메서드를 구현해뒀는데, 시작 시에 트랜잭션 off 해뒀다가 종료 시에 commit 하고 싶다면?

 로깅, 메서드를 하나 구현해뒀는데 이게 시작과 끝에 console창이나 log파일에 "시작했습니다", "끝났습니다"라고 남기고 싶다면?

 로그인하지 않는 사람이나, 권한 없는 사람이 해당 메서드 호출을 못하게 하려면??

 이 3가지의 공통은 ~하기 전에, ~하고 나서 등과 같이 일정 패턴에 따라 어떤 행위를 해줄 수 있다는 것을 의미합니다.

 

6번의 경우 iBatis나 하이버네이트의 경우 최근에 많이 이용하지 않고, MyBATIS를 이용하는 추세입니다. (추세라고 하기엔 이미 그냥 MyBATIS를 이용 중입니다.) 이는, DB 처리 api로, xml에 Query를 만들어두고, 필요시에 xml의 Query를 호출하는 기술이라고 보면 됩니다.

 

7번의 경우는 java의 특징이고 한 부분이라 별도로 이야기할 건 없을 것 같고, jar파일이나 maven, svn 등의 연결이 쉽다는 정도로 보면 될것 같습니다. maven이나 svn에 대해서는 추후에 또 다뤄보도록 하겠습니다.

 

조금 체계적으로 해볼까 했지만, 아무래도 말이 주절주절 쓰이기만 하는 것 같네요. 다음 시간에는 주요 모듈에 대해서 좀 더 다뤄보고 각 특징에서 주로 이야기하는 IoC, DI, AOP에 대해서 심도 있게 다뤄보도록 하겠습니다.