1.3.4 평범한 옛 디자인 패턴이 자바 EE를 만나다

자바는 태생이 디자인 패턴과 친화적입니다. 바로 꺼내 쓸 수 있게 자바 SE와 한 몸인 패턴도 있고(예: 옵저버 패턴), 자바 자신도 여러 디자인 패턴을 채용했습니다. 예를 들어, 싱글톤 패턴은 시스템과 런타임 클래스에 썼고 비교기(comparator)는 전형적인 전략 패턴 구현체입니다.

이런 전통은 엔터프라이즈 자바에도 이어졌지만, 자바 EE는 GoF 책 패턴 상당수를 내부에 구현했습니다. 대부분 간단하고 쓰기 쉬운 애너테이션 형태로 사용할 수 있어서 클래스 다이어그램을 뚫어지게 쳐다보며 틀에 박힌 코딩을 하지 않아도 코드 몇 줄 추가하면 패턴 맛을 음미할 수 있습니다. 거짓말 같다고요? 그렇지 않습니다. 자바 EE 런타임은 정교하게 설계되어 있어서 하부 플랫폼의 힘을 빌려 다양한 기능을 제공합니다. 패턴에서 필요한 기능은 대개 EJB나 컨텍스트/의존체 주입(Context and Dependency Injection, CDI) 같은 자바 EE 상위 기능 없인 구현하기 어렵습니다. 자바 EE 컨테이너는 수많은 서비스 및 기능을 서버에 탑재함으로써 우리가 해야 할 일을 대행합니다. 그래서 아파치 톰캣 같은 기본 웹 서버보단 서버 런타임 환경이 다소 무거워지는 단점이 있지만, 그간 꾸준히 개선된 덕분에 최신 빌드한 자바 EE 7 런타임은 아주 가벼워졌죠.

엔터프라이즈 애플리케이션에서 디자인 패턴이 계속 필요한 이유는 뭘까요? 실은 그 어느 때보다도 패턴은 긴요해졌습니다. 일반적으로 엔터프라이즈 애플리케이션은 개발팀만 여럿인, 규모가 큰 기업용으로 구축하므로 각기 다른 파트를 재사용하는 일이 드물지 않습니다. 자주 나오는 패턴의 문제를 혼자서 또는 작은 팀 안에서 해결하는 게 아니라 자신이 착안한 해결 방법을 전사적으로(만약 오픈 소스 프로젝트라면 전 세계 개발자들과) 적극 공유하는 것입니다. 설계가 불량한 애플리케이션을 도입하면 좋지 못한 사내 관행 또는 빗나간 개발 전략으로 고착되기 쉽습니다. 많은 개발자가 라이브러리, 유틸리티 클래스, API를 공유하는 상황에선 호환성을 무너뜨리고 급진적인 변경을 단행하기 힘듭니다. 반환 타입을 바꾸거나 인터페이스 메서드 하나만 추가해도 해당 코드를 바라보는 프로젝트 전부가 어긋날지 모르니까요.