[프레임워크 전략 ①] 프레임워크의 재발견

프레임워크의 도움 없이 애플리케이션을 개발한다는 것은 상상하기 힘든 시대가 다가오고 있다. 하루가 다르게 늘어만 가는 각종 프레임워크의 홍수 속에서 자신에게 필요한 최적의 프레임워크를 선별하고 효과적으로 사용할 줄 아는 능력이 개발자들에게 요구되고 있다. 프레임워크는 애플리케이션 개발자들의 오랜 숙원을 해결해 주기 위해 등장한 멋진 도구가 분명하다. 하지만 그것을 적절하게 다루고 사용할 줄 아는 지혜를 가진 자들만 얻을 수 있는 혜택이다.

프레임워크가 무엇이라고 한마디로 정의하기는 쉽지 않다. 사람들 입에 많이 오르내리는 IT용어들은 그 정의가 사실 매우 느슨한 경우가 많다. 프레임워크라는 말은 유행어처럼 점점 많은 곳에서 폭넓은 의미로 사용되고 있다.

그래서 많은 경우에 프레임워크의 개념에 대한 오해로 인해 잘못된 판단을 하기도 한다. 그런 탓에 프레임워크의 활용 방법을 알아보기에 앞서 프레임워크라는 용어의 정확한 의미와 특징을 이해해 두는 것이 중요하다.

프레임워크 vs 디자인 패턴

프레임워크는 애플리케이션의 구조와 디자인을 결정하는 요소를 가지고 있다. 디자인 패턴과 마찬가지로 프레임워크는 반복적으로 발견되는 문제를 해결하기 위한 특화된 솔루션이라고 이해할 수 있다. 구조적인(architectural) 디자인 패턴인 MVC 패턴 (Model-View-Controller Pattern) 기반의 애플리케이션을 손쉽게 만들 수 있도록 설계되어있는 대표적인 프레임워크가 스트럿트 프레임워크이다.

스트럿트는 GUI기반의 MVC 패턴을 웹 애플리케이션 개발에 적용할 수 있는 더 특화된 구조적 패턴을 가지고 있다. 테스팅 프레임워크의 대표 격인 xUnit 프레임워크들은 커맨드패턴과 콤포짓 패턴으로 설계되어있다. 따라서 그 프레임워크를 기반으로 만드는 애플리케이션의 구조도 자연스럽게 이 두 가지 패턴의 영향을 받게 된다.

디자인 패턴은 프레임워크의 핵심적인 특징이고 프레임워크를 사용하는 애플리케이션에 그 패턴이 적용된다는 특징을 가지고 있다. 하지만 프레임워크는 디자인 패턴이 아니다. 디자인 패턴은 애플리케이션을 설계할 때 필요한 구조적인 가이드라인이 되어 줄 수는 있지만 구체적으로 구현된 기반코드를 제공하지 않는다.

그 패턴을 어떤 식으로 적용하고 어떤 클래스로 만들 것인가는 그 패턴을 사용하는 개발자의 책임이다. 하지만 프레임워크는 디자인 패턴과 함께 그 것이 적용 되어진 기반 클래스 라이브러리를 제공해서 프레임워크를 사용하는 구조적인 틀과 구현코드를 함께 제공한다.

결국 개발자는 프레임워크의 기반코드를 확장하여 사용하면서 자연스럽게 그 프레임워크의 패턴을 적용하게 된다.

프레임워크 = 디자인 패턴 + 라이브러리

프레임워크는 이렇게 디자인 패턴과 그것이 적용된 기반 라이브러리의 결합으로 이해할 수 있다. 이 두 가지가 프레임워크의 모든 특징을 다 설명해줄 수는 없다 하더라도 이 두 가지 관점에서 프레임워크를 관찰하는 것은 프레임워크를 이해하는 좋은 출발점은 될 수 있다.

때론 자신이 사용하고 있는 프레임워크에 적용된 패턴이 어떤 것인지 의식하지 않고 개발할 수도 있다. 하지만 그 패턴을 이해하는 것은 프레임워크 기반의 개발이 잘못된 방향으로 나아가지 않도록 해주는 가이드라인이 되어 줄 수 있다.

또 프레임워크의 라이브러리를 살펴볼 때도 그 적용된 패턴을 주목해서 살펴본다면 그 구성을 이해하기가 매우 쉽다. 특히 프레임워크를 확장하거나 커스터마이징 할 때는 프레임워크의 패턴에 대한 이해가 꼭 필요하다.

프레임워크 활용의 지름길

라이브러리에 대한 분석과 이해도 매우 중요하다. 많은 프레임워크들이 실제 그 기능의 10~20%이하만 사용되고 있다는 보고가 있다. 프레임워크의 일부 기능만 필요해서 그랬다면 상관없지만 때로는 프레임워크에서 이미 제공되고 있는 기능과 클래스를 몰라서 똑같은 기능을 가진 코드를 직접 개발해서 쓰는 경우도 적지 않다는 점이 문제다.

프레임워크 개발자들이 자주 하는 이야기는 사용자들이 요청하는 새로운 기능의 많은 부분은 이미 다 구현이 되어 있는 것들이라고 한다. 숙련된 프레임워크 사용자일수록 오히려 자신이 오랫동안 써 온 기능 외에는 관심을 두지 않아 유용한 라이브러리 기능을 놓치는 함정에 빠지기 쉽다.

레퍼런스 매뉴얼과 API/클래스 문서를 꾸준히 살펴보고 유용한 라이브러리의 기능에 대한 지식을 쌓는 것이 프레임워크를 잘 활용하기 위한 지름길이다.

프레임워크에 대해 정확히 이해하려면 프레임워크와 그 특징이 비슷하지만 프레임워크는 아닌 것들과 비교해 보는 것이 좋다. 여기에서는 프레임워크와 혼용되어 사용되기도 하는 라이브러리와 디자인 패턴이 프레임워크와 어떻게 다른 특징을 가지는지에 대해 알아보자.

프레임워크 vs 라이브러리

프레임워크의 가장 대표적인 특징 중 하나는 그 안에 클래스 라이브러리를 가지고 있다는 것이다. 혹자는 프레임워크를 반제품이라고 설명하기도 한다. 개발해야 할 애플리케이션의 일부분이 이미 만들어져 있다는 뜻이다.

프레임워크를 이용한 개발은 결국 그 기반이 되는 이미 존재하는 부분을 확장하고 이용하는 것이라고 볼 수 있다. 윈도우즈 환경의 대표적인 GUI 애플리케이션 프레임워크인 마이크로소프트의 MFC(Microsoft Foundation Classes)와 볼랜드의 OWL(Object Windows Library)는 그 이름 그대로 클래스 라이브러리로 구성되어있다.

자바기반의 대표적인 애플리케이션 프레임워크인 스프링프레임워크는 수 천 개의 클래스기반 API 라이브러리를 포함하고 있다. 또 .NET 프레임워크는 CLR, ASP.NET과 함께 프레임워크 클래스 라이브러리가 그 핵심구성요소이다. 이렇듯 프레임워크는 라이브러리와 유사하게 생각할 수도 있다.

하지만 프레임워크는 라이브러리와는 분명히 다르다. 그 차이는 프레임워크를 사용하는 사용자코드와 라이브러리를 사용하는 코드를 비교해보면 쉽게 알 수 있다.

프레임워크는 주로 프레임워크 쪽에서 사용자의 코드를 호출하는 구조로 동작한다. 즉 실행의 흐름에 대한 제어를 프레임워크가 담당하게 된다. 많은 프레임워크는 템플릿 메소드 패턴 기반으로 만들어진 클래스를 서브 클래싱해서 사용하도록 되어있다.

결과적으로 사용자의 코드는 프레임워크 클래스에 이미 설계되어있는 흐름구조에 따라 동작하게 된다. 그래서 프레임워크의 동작원리를 그 제어흐름 일반적인 프로그램 흐름과 반대로 동작한다고 해서 IoC(Inversion of Control)이라고 설명하기도 한다. 반면 라이브러리는 유저의 코드가 라이브러리를 호출해서 사용하는 구조로 되어있다.

즉 코드의 흐름을 유저코드가 관장하고 있는 것이다. 또 프레임워크는 오브젝트간의 연동구조를 미리 정의하고 있다. 이렇듯 같은 클래스 라이브러리이지만 프레임워크와 라이브러리는 그 것을 사용하는 유저코드의 작성방식이 판이하게 다르다.

프레임워크 vs 디자인 패턴

결국 개발자는 프레임워크의 기반코드를 확장하여 사용하면서 자연스럽게 그 프레임워크의 패턴을 적용하게 된다.

프레임워크 = 디자인 패턴 + 라이브러리

프레임워크 활용의 지름길

일반적으로 개발팀에서 프레임워크를 선정하고 도입을 담당하는 것은 아키텍트의 역할이다. 그 이유는 프레임워크가 애플리케이션의 아키텍처에 미치는 영향이 매우 크기 때문이다.

프레임워크는 애플리케이션의 구조를 결정하기 때문에 아키텍처의 일부분을 차지하게 된다. 따라서 프레임워크의 선택에 따라 아키텍처 설계가 달라질 수 있다. MVC 기반의 웹 프레임워크를 사용하려고 한다면 그에 맞게 Model2 아키텍처를 사용해야 한다.

반대로 아키텍처가 정해져 있다면 그 아키텍처에 맞는 프레임워크를 선별해야 한다. 3계층 기반의 분산형 아키텍처를 설계했다면 C/S를 위한 프레임워크를 사용할 수 없다.

만약 리치 클라이언트(Rich Client) 아키텍처 기반이라면 Ajax 프레임워크 등의 도입을 고려해야한다. 따라서 프레임워크와 아키텍처는 서로 깊은 연관관계가 있다. 따라서 프레임워크를 선정할 때에는 항상 아키텍처 적으로 미치는 영향을 잘 판단해야 한다.

문제는 모두 같은 프레임워크라 하더라도 사용하는 패턴에 따라서 각기 다른 아키텍처적인 특성을 가지게 된다는 점이다. 또 한 개 이상의 프레임워크를 사용한다면 어떤 방식으로 조합하느냐에 따라서 아키텍처의 설계에 미치는 영향이 다를 수 있다.

따라서 어떤 프레임워크를 사용할 것인가 뿐만 아니라 그 프레임워크를 어떤 식으로 사용할 것인가도 고려해야만 한다. 결국 최종적으로 완성되는 아키텍처는 사용하는 프레임워크의 종류와 그 사용전략이 결합되어 결정된다고 볼 수 있다.

아키텍처 관점에서 매우 제한적인 프레임워크가 있는 반면에 다양한 아키텍처를 지원하는 유연한 프레임워크도 있다. 필자는 최근에 아키텍트로 참여하고 있는 프로젝트에서 개발하고 있는 애플리케이션에 적용된 아키텍처를 대폭 수정하는 작업을 진행했다.

전통적인 계층형 아키텍처(Layered Architecture)에서 사용하는 서비스계층 중심의 아키텍처를 리치 도메인 모델(Rich Domain Model)을 사용하는 DDD(Domain Driven Design)스타일의 아키텍처로 변경하게 되었다.

애플리케이션 구조적으로는 매우 큰 변화이지만 이 과정에서 기존에 사용하던 애플리케이션 프레임워크는 변경할 필요 없이 그대로 사용할 수 있었다.

단지 프레임워크에서 사용하지 않던 기능 일부를 적용하고 사용방식을 변경했을 뿐이다. 프레임워크를 잘못 선택해서 문제가 생기는 많은 경우는 아키텍처적으로 매우 제한이 심한 프레임워크를 도입했을 때 많이 일어난다. 따라서 프레임워크 도입 시 아키텍처적인 유연성을 따져보는 것도 중요한 일이다.

프레임워크를 정확히 분석하고 검증하기 위해서는 앞서 말한 프레임워크에 대한 세 가지 이해가 반드시 필요하다. 프레임워크의 특징과 그 종류를 파악해야 하고 프레임워크가 아키텍처에 미치는 영향도 이해해야 한다. 이러한 프레임워크에 대한 이해를 기반으로 프레임워크 선정과 도입에 필요한 상세한 전략에 대해서 살펴보자.

프레임워크의 종류는 갈수록 늘고 있다. 웹 개발을 위한 언어인 PHP만 해도 이미 70여개의 프레임워크가 나와 있다. 가장 프레임워크를 활발하게 사용하고 있는 자바는 프레임워크의 종류와 수를 헤아리기 조차 힘들다. 대표적인 자바개발자 포털 사이트인 TSS에는 거의 매일 끊이지 않고 새로운 프레임워크를 소개하는 뉴스가 실리고 있을 정도이다.

때론 프레임워크가 그만 나왔으면 싶은 생각이 들 때도 있을 정도이다. 이렇게 다양한 프레임워크 중에서 개발에 필요한 적절한 프레임워크를 찾고 검증하고 도입하는 것은 매우 어렵고 번거로운 작업이다.

프레임워크를 선택하는 것이 중요한 이유는 한번 선택한 프레임워크는 쉽게 바꾸기 힘들다는 데 있다. 프레임워크는 애플리케이션 개발의 구조를 좌우하기 때문에 이미 개발이 어느 정도 진행된 후에 프레임워크를 변경한다는 것은 애플리케이션의 구조도 함께 바꿔야 한다는 부담을 동반한다.

또 프레임워크의 라이브러리에 의존적으로 만들어진 코드를 수정하려면 최악의 경우 그 동안 개발한 것을 버리고 새로 개발하는 것이 나을 만큼 큰 작업이 될 수 있다.

프레임워크가 가진 결함이나 한계를 미리 파악하지 못하면 결국 프로젝트가 실패하게 되는 위험을 맞을 수도 있다. 따라서 프레임워크의 선택은 매우 신중해야 하고 충분한 시간과 검토가 필요하다. 프레임워크를 잘 적용하면 생산성을 높여 개발기간을 단축할 수 있다. 따라서 프레임워크 없는 개발보다 상당한 시간적인 여유를 가질 수 있다.

그렇다면 개발초기의 시간을 프레임워크 분석과 선정에 넉넉하게 투자할 줄 아는 지혜가 필요하다.

프레임워크 도입의 목적

프레임워크 도입을 위해서 가장 먼저 생각해야 할 것은 도입의 목적이다. 프레임워크를 사용하려는 이유와 그로 인해 얻어야 하는 결과가 있어야만 그 기준에 부합하는 프레임워크를 선택할 수 있다.

하지만 많은 개발자들이 단지 요즘 유행하는 유명 프레임워크이니까 한번 써보려는 생각에 도입 목적은 뒷전으로 하고 특정 프레임워크를 선택하는 실수를 하기도 한다. 범용적으로 쓰이는 프레임워크가 있기는 하지만 모든 경우와 모든 목적에 맞는 프레임워크란 있을 수 없다.

프레임워크 도입의 목적은 크게 두 가지로 생각할 수 있다. 첫째는 생산성이고 둘째는 품질이다.

●생산성

프레임워크에는 이미 애플리케이션 개발의 상당 부분이 만들어져 있다. 또 아키텍처나 구조적인 부분도 어느 정도 결정되어있다. 코드의 구성이나 흐름에 대한 표준도 정해져 있는 덕에 생산성을 높일 수 있는 것은 자명한 일이다. 공통적으로 반복되는 코드들은 프레임워크 내부에 감춰져 있어 개발자는 애플리케이션의 핵심 로직에 집중해서 개발할 수 있다.

하지만 프레임워크가 생산성을 높여주는 것은 단지 기반코드가 미리 작성되어있어서 개발해야 되는 코드의 양이 줄어들기 때문만은 아니다. 프레임워크는 애플리케이션 코드를 심플하게 작성할 수 있도록 도와주기도 한다.

필자가 POJO 기반의 투명한 영속성(Transparent Persistence)을 지원하는 ORM 프레임워크를 쓰면서 가장 좋았던 점은 SQL 문장을 직접 편집하지 않아도 된다거나 Connection, Statement 등을 관리하는 코드를 작성하고 close 여부 따위를 신경 쓰지 않아도 된다는 부분이 아니었다.

가장 좋은 점은 만들어진 비즈니스 로직 코드가 매우 심플해졌다는 데 있었다. 이전에는 레이어 구분 없이 비즈니스 로직과 데이터 로직 그리고 API를 호출하는 코드들이 스파게티처럼 얽혀 있게 마련이었다.

또 DAO 패턴을 적용해서 만들었다 하더라도 DB 관련 액션이나 트랜잭션에 대해서 비즈니스 로직을 작성하거나 검토하는 중에도 같이 신경을 써야하던 것을 프레임워크가 해결해 준 것이다.

결국 POJO로 설계된 모델오브젝트 만을 다루게 되니까 자연스럽게 모든 개발 작업이 비즈니스 로직을 구현하는데 집중하게 되고 결과적으로 복잡한 로직을 매우 간결하게 처리하는 심플한 코드로 깔끔하게 마무리 할 수 있었던 것이다. 이런 면에서 프레임워크의 도입목적에는 생산성이 큰 비중을 차지한다.

루비 온 레일즈와 같은 프레임워크는 초기 프로토타입을 매우 빠르게 개발할 수 있도록 해준다. 만약 고객에게 짧은 시간 안에 개발능력을 보여주고 검증을 받아야 한다면 그런 RAD 개발이 가능한 프레임워크의 도입을 먼저 검토해야 한다. 물론 생산성의 문제는 뒤에서 다룰 개발팀의 수준과 프레임워크에 대한 숙련도에도 영향을 받는다.

●품질

품질과 관련된 부분도 많은 경우에 중요한 도입목적이 될 수 있다. 품질은 여러 가지 관점으로 생각해 볼 수 있는데 우선 결함이 없거나 적은 애플리케이션이라는 면에서 생각해보자. 프레임워크는 개발자가 반복적인 작업에서 실수하기 쉬운 부분들을 프레임워크 내에서 처리해줌으로써 버그발생의 가능성을 최소화 한다.

한동안 JDBC 기반의 DB개발을 하는 개발자들에게는 Connection/Statement의 정확한 리소스 반환 문제의 원인은 단순하지만 시스템을 오랜 시간 운영시키기 전에는 쉽게 발견하기 힘들다. 또 그 위치를 추적하기가 매우 어렵기 때문에 큰 고민거리였다.

사실 테스트 시에 잘 드러나지 않는 결함을 해결하기 위한 다양한 팁과 솔루션이 있었지만 사실 가장 손쉬운 해결책은 퍼시스턴트 프레임워크를 사용하는 것이다. 각종 ORM이나 iBatis, JPA 등의 프레임워크를 사용하면 DB 관련 리소스의 처리로 인한 결함에 대한 걱정을 덜 수 있어 결함이 적고 품질이 뛰어난 애플리케이션을 만드는데 큰 도움이 된다.

그 밖에도 프레임워크가 기존 개발에서 많이 등장해서 문제가 되었던 개발상의 고질적인 문제들을 손쉽게 해결해주는 예는 아주 많다.

테스팅 프레임워크는 그 자체가 애플리케이션의 품질을 검증하고 관리하기 위한 것이 주목적이다. xUnit 등을 통한 자동화된 테스트를 도입함으로 애플리케이션 개발의 품질 향상에 얼마나 큰 도움이 됐는가는 잘 알려진 사실이다. 프레임워크에는 그와 관련된 많은 노하우와 경험이 농축되어있는 경우가 많다.

애플리케이션의 구조적인 부분뿐만 아니라 기술적인 면에서도 경험이 많지 않은 개발자들이 쉽게 구현해 낼 수 없는 고급기법들이 담겨져 있다. 그 프레임워크가 일부가 되는 애플리케이션은 자연스럽게 그 프레임워크가 가진 품질을 이어받게 되어있다.

이미 언급했듯이 프레임워크는 애플리케이션의 복잡함을 제거해주고 심플한 개발을 돕게 된다. 심플함이 주는 큰 이득은 뛰어난 품질의 개발을 가능하게 해준다는 것이다. 개발이 복잡해지고 코드가 지저분해지면 품질이 저하될 가능성이 높아진다. 프레임워크를 도입해서 얻으려는 목적은 결국 그런 복잡함을 제거하기 위한 것이다.

프레임워크는 생산성과 품질 양쪽의 목적을 모두 충족시킬 수 있는 도구이지만 필요에 따라 더 중요하게 생각할 것이 무엇인지를 잘 판단해야 한다. 예를 들어 JSP를 이용한 Model1 기반에서 MVC 프레임워크를 사용하는 Model2 방식으로 변경했을 경우 프레임워크를 도입한 것이 오히려 생산성을 떨어뜨릴 수 있다.

프레임워크를 사용하는 코드의 양이나 클래스 개수가 더 증가하기 때문에 초기에는 생산성이 떨어져 보이는 것이 당연하다. 이런 경우 프레임워크를 도입하는 목적은 그로 인해서 애플리케이션의 품질을 높이는 것이 우선이 된다고 볼 수 있다.

트랜잭션 스크립트 방식에서 SoC(Separate of Concenrs)의 원칙을 따라 적절히 역할이 분리된 계층형 아키텍처를 사용하는 것도 마찬가지의 경우다. 이렇게 프레임워크도입으로 품질을 높였을 경우 애플리케이션의 결함이 적어지고 복잡한 로직을 쉽게 구현할 수 있다.

더불어 요구사항의 변화에 민첩하게 대응할 수 있기 때문에 장기적으로는 생산성이 다시 높아지는 결과를 가져오기도 한다.

반대로 생산성이 더 중요하고 복잡하지 않은 애플리케이션이라면 구지 무겁고 복잡한 프레임워크 보다는 가볍고 생산성이 뛰어난 프레임워크를 찾는 것이 좋다. 단 이런 선택을 했을 경우 시스템이 복잡해지면 애플리케이션의 품질관리가 점점 더 어려워질 수 있다는 점을 기억해야 한다.

최근에 등장하는 프레임워크들은 이 두 가지를 모두 충족시키는 방식으로 설계된 것이 많다. 심플하면서도 강력한 개발이 가능한 프레임워크들이 그런 것이다. 루비 온 레일즈는 높은 생산성으로 유명하지만 그러면서도 루비(Ruby)라는 언어가 가진 장점과 계층형으로 잘 설계된 프레임워크 구조로 인해서 뛰어난 품질의 개발이 가능하다고 평가받고 있다.

그밖에 애플리케이션의 성능 향상을 목적으로 도입하는 캐싱 프레임워크나 사용자의 사용 편의성을 높이기 위한 UI 프레임워크도 있다. 이 처럼 애플리케이션 개발의 요구사항을 충족하기 위해서 필요한 도입목적을 명확히 정리하고 그것을 충족할 수 있는 프레임워크를 찾는 것이 프레임워크 선택의 첫 번째 작업이다.

기술 검증

도입 목적을 충족할 수 있는 프레임워크들을 선별했다고 해서 이를 바로 적용할 수는 없다. 반드시 검증 과정을 거쳐야 한다. 프레임워크의 검증 시 가장 지양해야 하는 태도가 있다. 그것은 바로 자신이 써본 경험이 없거나 주위에서 적용한 사이트를 찾을 수 없다고 해서 그것은 검증 안 된 프레임워크라고 단정하는 태도이다.

반대로 주변에서 적용한 사례가 있다고 무턱대고 검증되었다고 판단하는 것 또한 위험한 태도이다.

성공적인 프레임워크 검증의 핵심은 직접 검증해보는 것이다. 모든 상황에 잘 들어맞는 만능 프레임워크는 결코 없다. 모든 프레임워크는 요구 조건과 상황 그리고 적용 방법에 따라서 그 가치가 다 달라질 수 있다. 가장 좋은 방법은 그 프레임워크를 사용한 검증용 애플리케이션을 만들어 보는 것이다.

요즘은 애플리케이션 개발 과정에서 프로토타이핑이 매우 중요한 과정으로 자리 잡고 있다. 프레임워크가 적용된 실제 사례와 유사한 프로토타입을 만들어 보면 프레임워크를 적용한 코드의 모습을 볼 수 있으며 프레임워크의 활용 방법도 사전에 체크해 볼 수 있다. 또 프레임워크를 적용해서 나타나는 문제점도 쉽게 체크할 수 있다.

프로토타입을 만들어서 프레임워크를 검증할 때에는 다음의 두 가지를 주의해야 한다.

버티컬 슬라이스(Vertical Slice)

첫째는 개발할 애플리케이션에서 발생할 수 있는 가능한 모든 기술적인 케이스를 다루어야 한다는 점이다. 간단한 샘플 애플리케이션을 가지고는 충분한 검증을 할 수 없다. 프레임워크를 가장 잘못 사용하는 경우는 프레임워크에 딸려온 샘플이나 관련 서적에 나온 예제 프로그램을 가지고 간단한 테스트를 해 본 후 그것을 확장해서 쓰는 것이다.

보통 그런 예제는 프레임워크의 활용 방법 중 가장 단순한 방식을 사용해서 학습 초기에 이해를 돕도록 만들어진 것이 대부분이다. 따라서 실제 애플리케이션에서 발생할 수 있는 다양한 난이도의 케이스를 검증하기에는 턱없이 부족하다.

개발할 시스템의 요구 사항 중 가장 기술적인 난이도가 있고 복잡하다고 생각되는 부분을 구현해 보아야 한다. 그럴 경우에도 프레임워크를 사용하는 것이 문제가 없고 개발을 심플하게 해준다는 확인이 필요하다.

만약 한 대 이상의 서버에 클러스터를 구축해서 운용해야 하는 대용량 시스템을 단일 서버 환경에서만 검증을 했다면 클러스터에 분산했을 때 검증 과정에서는 발견하지 못했던 새로운 문제를 만날 수 있다. 이런 경우는 클러스터 환경에서 동작하는 프로토타입을 만들어서 검증했어야 한다.

롭 존슨(Rod Johnson)은 애플리케이션의 핵심적이고 복잡한 케이스를 가능한 모두 가지고 있는 이런 검증용 샘플 코드를 버티컬 슬라이스(vertical slice)라고 부른다. 가능한 최소한의 범위를 다루지만 모든 레이어와 케이스를 관통하는 검증용 애플리케이션이어야 한다는 의미이다.

성능 테스트

두 번째는 초반 검증과정에서 성능에 대한 테스트가 충분히 필요하다는 것이다. 많은 경우 프레임워크의 적용은 개발 생산성과 품질의 향상과는 반대로 성능의 손해를 감수해야 한다. 프레임워크가 가지는 오버헤드가 있기 때문이다.

하지만 대부분 애플리케이션의 성능 테스트는 개발 막바지에 하게 된다. 그런 경우 프레임워크의 사용이 원하는 충분한 성능을 내지 못하는 것을 발견하게 되도 어떻게 손쓸 수 없는 때가 많다.

EJB 프레임워크는 엔터프라이즈 서비스를 지원하는 분산 객체 기술과 이상적인 엔티티 기술이라는 아키텍처적인 장점을 가졌음에도 그 성능상의 문제로 인해서 많은 프로젝트를 실패로 이끌었던 대표적인 케이스이다.

ORM 프레임워크는 개발 생산성과 성능을 높여주지만 SQL을 직접 사용해서 개발하는 것에 비해서 오버헤드가 크다. 만약 애플리케이션이 잦은 입출력을 주로 하는 OLTP성 프로그램이라면 ORM이 성능 상에 큰 지장을 주지 않는다.

생산성과 품질을 위해서 그 정도의 성능 손해를 감수하는 것은 가능하다. 하지만 복잡한 분석과 조회중심의 OLAP 애플리케이션이라면 ORM 프레임워크는 성능 상에 큰 지장을 줄 수 있기 때문에 도입을 재고해야 한다.

이러한 검증은 개발 사이클의 초반에 프레임워크를 검증하는 과정 중에서 다양한 케이스에 대한 충분한 성능 테스트를 통해 사전 검증해야만 한다.

프레워크 자체에 기술적인 검증까지 충분히 했다 하더라도 최종 도입을 결정을 하려면 한 가지 과정이 더 필요하다. 그것은 프레임워크의 교육에 관한 고려이다. 아무리 좋은 프레임워크라 하더라도 개발팀이 그것에 익숙하지 않다면 충분한 학습 시간이 필요하다. 프레임워크 샘플 예제를 가지고 어설프게 개발을 시작하는 것은 매우 위험하다.

프레임워크가 도입 목적에 맞고 기술적으로도 완벽하다고 하더라도 그 것을 원활하게 사용하게 되기까지 시간이 오래 걸린다면 프레임워크 도입을 다시 재고해 봐야 한다.

ORM 프레임워크는 기존의 트랜잭션 스크립트를 사용해서 개발하는 것보다 생산성이 높은 것으로 알려져 있지만 그것을 학습하는데 드는 시간이 오래 걸리는 어려운 프레임워크다. 따라서 개발 기간이 길지 않고 충분히 학습하는데 시간을 사용할 수 없다면 ORM에 익숙한 개발팀을 구성하던지 다른 프레임워크를 찾아보는 편이 좋다.

충분한 시간을 가지고 프레임워크의 도입을 할 수 있다면 체계적인 교육 전략을 세우고 접근해야 한다. 그렇지 않으면 좋은 프레임워크를 사용하면서도 오히려 잘못된 적용으로 손해를 볼 수 있다. 필자가 활동하는 오픈소스 커뮤니티에서 제법 유명한 오프소스 포털 제품의 소스 분석을 시도해 본 적이 있다.

그 제품을 선택한 이유는 그 당시 관심을 많이 가지고 있는 프레임워크를 어떻게 적용했는지 사례를 연구해보기 위함이었다. 그 포털 제품은 당시 버전 업그레이드를 하면서 유명 오픈소스 프레임워크를 새롭게 적용을 했고 그것을 제품의 강점으로 내세우고 있었다. 하지만 막상 분석해 본 소스의 프레임워크 적용 방법은 최악이었다.

프레임워크를 사용한 것은 분명하지만 그 프레임워크를 적용하는 기초적인 방법조차 모르고 어설프게 사용한 흔적이 역력했다. 아마도 그 개발자들은 프레임워크를 학습할 시간도 제대로 가지지 못한 채 프레임워크를 사용한 것이 분명했다.

결과적으로 프레임워크 도입이 그 이전보다 별다른 장점을 주지 못하고 오히려 코드만 지저분하게 만든 케이스였다. 비슷한 실수가 프레임워크의 명성 때문에 급하게 도입해서 적용한 많은 프로젝트에서 종종 반복되고 있다.

개발팀의 아키텍트나 리드 개발자라면 사용 프레임워크의 관련 서적과 레퍼런스 문서는 반드시 충분히 숙지한 후에 개발에 적용해야 할 것이다. 검증과 마찬가지로 프레임워크 학습에 투자하는 시간도 프로젝트의 전 기간에 걸쳐서 충분히 시간을 보상 받을 수 있다. 또 충분한 학습은 개발에 적용할 프레임워크의 Best Practice를 찾을 수 있도록 도와줄 것이다.

지난 2~3년 동안 달아오른 프레임워크의 열풍 뒤로 서서히 프레임워크 무용론이 등장하고 있다. 프레임워크 사용이 그다지 장점이 크지 않고 오히려 문제점이 많다는 실패한 경험인 낳은 비판이다. 그동안 유행하는 기술이라고, 주위 개발자들이 많이 사용한다고 무턱대고 프레임워크 도입에 열을 올린 것이 아닌지 반성을 해봐야 할 대목이다.

프레임워크는 다루기 힘든 도구이다. 좋은 프레임워크 일수록 적용한 수준의 격차가 크다. 막강한 기능만큼 제대로 사용하기 힘들 수 있다는 것이다.

그 동안 너무 급하게 적용하고 사용해온 프레임워크가 있다면 이제 한발 뒤로 물러나서 다시 차근차근 살펴볼 필요가 있다. 프레임워크의 다양한 특성을 이해하고 그 장점을 어떻게 잘 활용할 것인가에 대해 전략부터 찬찬히 세워야 할 것이다. 프레임워크에 대한 연구와 투자는 개발자에게 그만큼 보상을 안겨줄 것이다.

필자가 3년째 사용하고 있는 프레임워크가 하나있다. 처음 그 프레임워크를 알게 됐을 때는 완고한 개발자들에게서 별 근거도 없이 검증이 안 된 것이라고 외면당하던 초라한 프레임워크였다. 하지만 필자 스스로의 다양한 검증과정을 통해서 그 가치를 발견했고 개발프로젝트에 과감히 적용했을 때 그 결과는 모두가 놀랄 정도로 대단했다.

기존의 개발에서는 상상할 수조차 생산성과 품질 모두를 얻을 수 있었다. 이제는 그 가치를 인정받아 세계적인 유수기업들이 표준 프레임워크로 삼을 정도로 발전했다. 그 프레임워크에 녹아있는 개발 철학과 디자인 패턴, 잘 설계된 API를 사용해오면서 필자의 실력도 그에 따라 한층 발전했다고 생각된다.

프레임워크는 그것을 잘 사용하려는 개발자를 위해서 존재하는 멋진 동반자이다. @

참고자료

1. Expert One-on-One J2EE Design and Development, Rod Johnson, Wrox

2. Pattern Oriented Software Architecture, Frank Buschmann, Wiley

3. Why Use Framework http://www.jcorporate.com/expresso/doc/edg/edg_WhyUseFramework.html

4. What Is A Framework http://www.codeproject.com/gen/design/WhatIsAFramework.asp

5. .NET Framework http://msdn.microsoft.com/netframework

6. SpringFramework http://www.springframework.org

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.