공부하기에 앞서
어느 언어, 프레임워크, OS든 공부를 하고 사용하기 전에 우선 찾아보는 것이 있다.
내가 공부하고자 하는 대상에 대한 '철학'이다.
개발자가 무언가를 개발한다면 그것은 그냥 하는 것이 아닌 세상에 조금 더 도움이 되기 위해서이다.
그럼 그 개발자가 생각했던 불편한 점은 무엇이었고 왜 개발을 하였는지에 대해 알아야 한다.
내가 공부를 할 때 그냥 단순히 공부에 그쳐 언어, 프레임워크, OS의 장점을 모르고 쓴다면 그것은 그 기술의 반 밖에 모르고 사용하는 것이다.
기술이 탄생한 이유, 배경을 알 때.
기술의 철학을 알아야 비로소 그 기술에 대해 완벽히 이해할 준비가 되는 것이다.
스프링에 대한 공부를 시작하기에 앞서 스프링에 대한 철학을 나름대로 생각해보았다.
스프링을 어째서 만들었을까?
스프링이 나타나기 이전 세상에는 EJB(엔터프라이즈 자바빈즈(Enterprise JavaBeans))라는 기술이 판을 치고 있었다.
EJB는 자바의 표준이 되어 은행 등 여러 공공기관에서 사용되었지만 객체지향과는 거리가 있는 기술이었다.
너무 복잡한 EJB 때문에 사람들이 추구하게 된 것이 POJO(Plain Old Java Object)이다.
(POJO는 EJB와 같이 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다.)
POJO, 다시 자바의 객체지향으로 돌아가자.
지나치게 무거운 객체에 시달리던 자들의 외침은 오래된 방식의 간단한 자바 오브젝트로의 회귀를 바라고 있었다.
그 외침은 곧 행동이 되어 새로운 프레임워크가 개발되었고
그들의 소리가 한 데 뭉쳐 창조한 오픈소스가 스프링이다.
스프링의 시작은 로드 존슨(Rod Johnson)이 2002년 출간한 책, Expert One-on-One J2EE Design and Developement 에서 시작되었다.
이 책에서 EJB의 문제점을 지적하고 있으며, EJB 없이도 충분히 좋고 확장 가능한 애플리케이션을 개발 할 수 있음을 30000줄의 예제 코드를 통해 보여주고 있다.
개발자들이 이 3만 줄의 예제 코드를 프로젝트에 사용하기 시작했으며 이를 기반으로 스프링이 개발되었다.
스프링(Spring)이라는 이름은 어디에서 유래가 스프링이 개발된 배경을 함축하여 나타내 준다.
Spring은 EJB라는 겨울을 넘어 새로운 시작. 즉, 봄의 시작이라는 뜻으로 지어졌다.
그리고 위의 배경을 종합하면 스프링의 간단하지만 모든 자바 개발자들이 바라는 바를 담은 철학을 알 수 있다.
“좋은 객체 지향 프로그래밍을 할 수 있게 하자.”
좋은 객체 지향 프로그래밍과 SOLID
그럼 좋은 객체 지향 프로그래밍은 무엇일까.
컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법
즉, 다형성이 객체지향의 핵심.
클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경할 수 있다면 좋은 객체지향 프로그래밍이라고 할 수 있을 것이다.
이에 대한 내용을 알기 쉽게 정리한 것이 SOLID 원칙이다.
클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리하였다.
좋은 객체 지향 설계의 5가지 원칙 (SOLID)
SRP : 단일 책임 원칙 (Single Responsibility Principle)
- 한 클래스는 하나의 책임만 가져야 한다.
OCP : 개방-폐쇄 원칙 (Open/Close Principle) to
- “소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”
LSP : 리스코프 치환 원칙 (Liskov Substitution Principle)
- “프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.
ISP : 인터페이스 분리 원칙 (Interface Segregation Principle)
- “특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.”
DIP : 의존관계 역전 원칙 (Dependency Inversion Principle)
- 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
SOLID 원칙을 지키려면 어떡해야할까?
많은 개발자들이 이 SOLID 원칙을 지키며 자바로 개발을 하였다.
하지만 이 원칙중 지키기 어려운 두 가지 원칙이 있었다.
OCP와 DIP이다.
자바 개발자들은 OCP 원칙을 지키기 위해 다형성을 활용하였다. 인터페이스를 만들고, 구현체를 만들어 함수들을 오버라이드 함으로써 확장에는 열려있지만 변경에는 닫혀있는 OCP 원칙을 지킬 수 있었다.
하지만 다형성을 활용하는 데 문제가 생긴다. 클라이언트가 직접 구현체를 지정해주어야 한다는 점이었다.
구현체를 지정해주기 위해서는 클라이언트 코드의 변경이 불가피했고 이는 곧 코드의 변경으로 이어져 OCP 원칙을 지킬 수 없었다.
즉, OCP의 변경에는 닫혀있고 확장에는 열려있는 소프트웨어 요소를 위해 다형성을 활용한 구현체를 만들게 되었으나, 클라이언트가 직접 구현체를 지정해주게 되면 코드가 변경되므로 OCP를 지키지 못하게 되는 일이 발생하게 된다.
개발자들이 고민한 다른 한 가지 요소는 DIP였다. 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안 된다. 이를 위해 개발자들은 인터페이스를 만들어 추상화하였다.
하지만 자바를 사용하는 개발자들은 결국 추상화 한 인터페이스에 대한 구현체를 클라이언트에서 직접 가져다 쓸 수 밖에 없었다. 그리고 이는 결국 구체화에 의존하게 되는 상황이 되었다.
위의 두 가지 문제는 하나의 해결점에 도달했다.
클라이언트가 직접 구현체를 지정하지 않는다면 어떨까?
그럼 클라이언트가 구현체를 지정하지 않으니까 코드의 변경이 없어져 OCP를 지킬 수 있다.
그리고 클라이언트에서 추상화 한 인터페이스만을 적고 구현체를 쓰지 않아도 된다면, 이는 구체화가 아닌 추상화에 의존하게 되는 상황이 되어 DIP를 지킬 수 있다.
이 두 가지 문제에 대한 하나의 해결책으로 클라이언트가 직접 구현체를 지정하는 것이 아닌, 중간다리 역할을 해 줄 무언가가 있으면 OCP를 지킬 수 있게 되었다.
그리고 그 중간다리 역할을 해 줄 무언가가 바로 스프링(Spring)이다
스프링은 DI와 컨테이너를 이용해 OCP, DIP를 가능하게 지원해 준다.
이를 통해 클라이언트 코드의 변경 없이 기능 확장할 수 있다.
끝으로...
스프링이 등장하기 전 까지의 자바 개발자들의 고뇌가 하나가 되어 탄생한 결정체.
그 결정체의 탄생 배경과 존재 이유, 그 효율성에 대해 알아보았으니 이제 Spring에 대해 공부해 보고자 한다.
