[후기] 토비의 스프링 3.1 Vol.1 후기

0. 이 글을 쓰게 된 이유

토비의 스프링 vol.1의 정독을 완료하였다. 사실 3달 전에 완독을 했지만 부족한 부분을 다시 읽고, 후기를 미루고 미루다가 지금 쓰게 되었다. 개인적으로 스프링과 객체 지향을 이해함에 있어 큰 도움이 되었기 때문에 이 글을 쓰고 싶었다.

1. 스프링을 사용하는 이유

백엔드 웹개발에서 스프링은 가장 많이 쓰는 프레임 워크 중 하나이다. 우리나라에서는 대부분의 기업에서 스프링을 사용하고, 전자 정부 표준 프레임 워크이다. 사실 내가 스프링을 공부하게 된 것도 이러한 이유에서이다.
하지만 이것만으로는 충분하지 않다. 물론 많은 개발자들이 사용하니 그만큼 자료도 많은 장점이 있긴 하지만 그게 스프링을 사용하는 직접적인 이유가 될 수 없다. 토비의 스프링을 읽으며 내가 이해한 스프링 사용하는 이유는 다음과 같다.
엔터프라이즈 시스템 개발은 비즈니스적으로나 기술적으로나 점점 복잡해져왔고 지금도 복잡해지고 있다. 즉, 개발자가 고려해야할 사항이 많아지고 그만큼 개발을 하기가 어려워졌다. 하지만 이러한 복잡함은 제거할 수 없는 요소이다. 대신 그 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요해졌고 일단 가장 큰 문제인 비즈니스 복잡함과 기술적인 복잡함을 분리해내는 것이었다. 이 문제를 깔끔하게 해결한 것이 스프링이다.

1.1 스프링의 해결책

1.1.1 비침투적인 방식을 통한 해결책

스프링 이전에 EJB가 기술과 비즈니스의 복잡함을 분리하려는 시도가 있었다. 하지만 EJB는 비즈니스 코드에서 일부 기술적인 코드를 제거시키기는 했지만 오히려 틀 안에서 자바 코드를 만들게 강제하였고(침투적인 해결책), 이는 객체지향 언어인 자바의 장점을 근본적으로 저해시키는 요소가 되었다.
스프링도 EJB와 목표는 같았다. 하지만 스프링은 비즈니스 로직 코드에 기술 코드가 직접 노출되지 않도록 설계되었다. 사용자는 기술 코드를 가릴 수 있게 되었고 이는 성격이 다른 복잡함들을 깔끔하게 분리해주는 역할을 하였다.

스프링 개발을 하다보면 트랜잭션 처리를 해본적이 있을것이다. 우리는 그때마다 적절한 위치에 어노테이션만 붙히면 해결이 가능했다. 즉, 비즈니스 로직과는 완벽하게 분리되어 어디에선가 로우레벨의 기술을 처리해주는 것이다. 이것이 스프링이 주는 깔끔함이라고 할 수 있다.

1.1.2 기술적 복잡함을 상대하는 전략

비즈니스의 복잡함과 기술의 복잡함을 잘 분리 했으니 이제 처리할 것은 각각의 복잡함을 해결하는 것이다. 먼저 기술적 복잡함을 상대하는 전략에 대해 알아보자.

1.1.2.1 기술에 대한 접근 방식의 일관성, 특정 환경에 종속적이지 않게하는 방법

적용하는 기술이 달라지면 그에 따라 코드도 바뀐다는 건 심각한 문제이다. 그래서 스프링은 서비스 추상화를 통해서 이 부분을 해결했다.
기술적인 복잡함은 일단 추상화를 통해 기술에 독립적인 접근 인터페이스를 분리하고, 환경과 세부 기술에 독립적인 접근 인터페이스를 제공함으로서 이 문제를 해결했다.

1.1.2.2 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장하는 것을 방지

비즈니스 로직 전후로 경계가 설정되어야 하는 트랜잭션, 로깅, 보안, 예외의 일괄 변환 같은 것은 서로 성격이 다르고 비즈니스와도 성격이 다르다. 아무리 책임에 따라 계층을 구분하고 그 사이에 서로의 기술과 특성에 의존적인 인터페이스나 예외 처리 등을 최대한 제거한다고 해도 근본적으로 이러한 복잡함을 해결할 수는 없다.
스프링은 이를 해결하는 접근 방식으로 AOP를 제공하였다. AOP는 비즈니스 로직을 담당하는 코드에 남아 있는 기술 관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술이다. AOP를 적용하지 않으면 기술 로직과 비즈니스 로직이 여기저기 얽혀서 뭐가 뭔지 모르게 될 수 있고, 중복 코드가 여기저기 나타날 수 있다. 그 문제를 AOP라는 강력한 수단으로 깔끔하게 해결 하였다.

1.1.3 비즈니스 복잡함을 상대하는 전략

사실 비즈니스 로직은 굉장히 다양하기 때문에 스프링에서 일괄적인 처리를 해줄 수 있는 부분이 많지 않다. 물론 자주 쓰이는 부분에 있어서는 가능하겠지만 대부분이 그렇지 않을 것이다. 그래서 스프링은 사용자에게 객체 지향을 이용할 수 있도록 최대한의 자유도를 주려고 했다.
스프링은 DI를 통해서 사용자에게 객체지향적인 설계를 할 수 있는 환경을 만들어줬고 그로 인해 사용자는 편리하게 객체지향적인 코드를 작성할 수 있다. DI가 없었다면 스프링도 없었을 것이다.

2. 스프링의 핵심

스프링은 위와 같은 전략, 스프링의 3대 기술을 이용하여 이루고자 하는 핵심은 따로있다. 이것은 바로 언터프라이즈 서비스 기능을 POJO에 제공하는 것이다. 이 말은 엔터프라이즈 서비스 기술과 POJO라는 비즈니스 로직을 담은 코드를 분리했다는 뜻이다.
스프링은 우리에게 환경에 종속되지 않고, 기술에 종속되지 않고, 어떠한 규약에도 종속되지 않는 POJO를 제공 받음으로서 편리하게 개발을 할 수 있다.

3. 정리

그렇다면 누군가가 "이번 프로젝트에 스프링을 왜 사용했어?" 라고 질문을 한다면 어떻게 대답해야할까? 나는 객체 지향적인 코드를 짜려고 라고 대답할 것이다. 스프링이 제공해주는 일괄적인 기술과 가치를 이용해서 자유도가 높은 객체지향적인 코드를 짜서 객체지향의 장점을 최대한 활용하기 위함이다.
객체 지향 프로그램으로 유지 보수하기 쉽고, 테스트 하기 쉬우며, 코드의 재사용을 최대한 활용하는 코드를 짜기위해 스프링을 이용하는 것이 맞는 것 같다.