작년에 처음 들었는데, 무척 흥미롭고, 얼마나 퍼질지, 경향으로 자리 잡을 수 있을지 지켜보는 용어가 하나 있습니다. 언프레임워크(Unframework)라는 용어에요.

이 용어는 작년에 cujoJS를 통해서 처음 접했습니다. 그리고 금년엔 구글에서 “unframework”이라고 입력하면 Flourish가 가장 먼저 검색되네요.

잠깐 검색해 봤을 때, 아직 아주 저명한 분들이 권위 있는 의미를 실어서 사용했다거나, 공통된 의미로 사용한다거나 하지는 않은 것 같지만 대략 다음과 같은 의미로 사용되는 것 같습니다.

• 작은 애플리케이션이라서 소위 프레임워크라는 이름을 달고 나오는 거대한 기술까지 필요 없을 때 대용으로 쓸 수 있는 작은 프레임워크
• 몇몇 프레임워크가 다루는 큰 주제가 아닌 작은 영역의 문제를 해결하는 툴킷 모음으로 프레임워크를 보조함
• 클래스 라이브러리라고 부르기엔 아쉽고 프레임워크라고 부르기엔 잡스러운(?) 무엇

최 근엔 RoR류의 독점적 프레임워크에 대한 반발로 경량 프레임워크가 많이 등장했고 한 주류로 자리잡았습니다. 제가 보기엔 독점적 프레임워크는 시간이 지나면서 새로운 기술이 소개되거나 문제 영역이 바뀔 때, 이를 지원하기 위해 구조가 유연하게 바뀌면서 복잡해지고 결합력이 떨어지면서 단순한 기술 집합으로 변질되거나, 변화에 따라가지 못해 단명하고 (하위 호환성이 없고 사실상 새로운 제품인) 차기 버전으로 배턴(baton)을 넘기게 될 위험이 있습니다.

암튼, 지금까지는 잡설이었고, 제가 언프레임워크라는 단어에 주목하는 이유는, 그 시도 자체도 인상적이지만, 제가 스프링 프레임워크를 처음 접했을 때 제가 느낀 느낌을 아주 잘 표현해 주는 단어라는 생각이 들었기 때문입니다.

지금은 스프링 프레임워크로만, 심지어 스프링 패밀리까지 동원해서 온통 스프링으로만 애플리케이션 개발 플랫폼을 구성하는 일이 많지만 제가 처음 스프링을 접했을 때에는 스트러츠가 프레임워크의 대표였고 기업에서는 대부분 EJB를 사용했습니다. 그래서 스프링 프레임워크 참조 설명서에도 스프링을 다른 기술과 함께 사용하는 다양한 계획을 앞 부분에 설명하고 있습니다. 그 당시에는 (지금 언프레임워크들이 얘기하듯이) 이미 사용하는 프레임워크를 사용하면서 애플리케이션의 아키텍처를 잡는데 도움을 주는 용도로 스프링을 사용했습니다.

그리고 스프링은 다른 프레임워크들과 달리 그 구조를 블랙박스처럼 닫지 않고 거의 클래스 수준까지 열어 두어 확장하거나 재사용할 수 있도록 합니다. 마치 툴킷처럼 느껴집니다.

스프링 프레임워크는, 또, 특정 한 영역의 문제를 해결한다기 보다 애플리케이션 전 영역을 다룹니다.

제 가 하고 싶은 말은, 스프링이 프레임워크냐 아니냐는 것이 아니라, 다른 ‘프레임워크’라는 이름을 달고 나온 기술과 스프링은 무척 다르게 느껴졌었고, 만약 언프레임워크라는 말을 그 때 알았더라면, 저는 스프링을 그렇게 불렀을 것 같습니다.

그러고 보니 언젠가 토비에게 스프링 MVC는 스프링 프레임워크의 모듈에서 다른 스프링 포트폴리오 중 하나로 빠지는 게 좋아 보인다고 말했었는데 (토비는 반대했지만) 아마도 내가 이런 생각을 하고 있기 때문이었나 봅니다.