jaso extends j2ee

첫 번째로 아직까지 많은 프로젝트 또는 시스템들이 구조적 프로그래밍 기법으로 개발되고 있다. 이것에 대한 원인에 대해 필자는 다음과 같이 생각한다.

프로젝트 관리자의 인식 부족
구조적 프로그래밍에서 객체지향 또는 컴포넌트로의 변화는 개발팀에게 많은 변화를 요구하게 된다. 단순히 개발자만 객체지향에 적응하면 되는 것이 아니라 참여하는 구성원(프로젝트 관리자. 분석/설계자, 개발자, 품질 담당자) 모두가 변해야 하며, 이 변화의 강도가 이미 개발 조직이 겪었던 90년대 초반의 Client/Server 프로그래밍으로의 변화보다 생각할 수 없을 정도로 크다고 할 수 있다.
이러한 급격한 변화는 프로젝트 관리자에게는 프로젝트 성공과 직결되는 요소로 외부에서의 강한 압력이 없는 한 관리자는 기존의 방식을 고수하고자 하는 경향이 있다. 따라서 프로젝트 관리자 또는 프로젝트 팀의 주 구성원 중 객체지향에 대한 충분한 지식과 경험이 없는 경우라면 프로젝트 관리자가 객체지향, 더 나아가 CBD를 선택하기는 어렵다.

레퍼런스의 부족
CBD라는 것이 소프트웨어의 각 부분을 각각 개발한 후 조립하는 형태이고 이런 각각의 요소들은 향후 재사용 할 수 있다라는 것이 최대 장점인데, 현재까지의 CBD 프로젝트들은 컴포넌트에 대한 정확한 정의나 컴포넌트의 도출 방식에 경험이 없다 보니 이를 재활용하거나 최소한 컴포넌트들간의 의존 관계를 줄일 수 있을 만큼의 경험이 없었다는 것이다.
EJB 또는 .NET으로 많은 프로젝트가 진행되었는데 이런 프로젝트들은 CBD에 대한 레퍼런스가 되지 않냐라는 반문에 대해서는 본문의 컴포넌트 기반 개발 방법에 대해 설명할 때 자세하게 설명하기로 하고 여기서는 EJB, .NET을 바라보는 필자의 입장은 EJB, .NET은 객체지향 또는 컴포넌트 기반 개발을 지원해주는 프레임워크 일 뿐 단순히 이를 이용해서 시스템을 구축한다고 해서 객체지향 또는 컴포넌트 기반의 시스템이 아니라는 것이다.

개발자의 설계/구현 능력 부족
지금까지 객체지향에 대한 연구는 많이 진행되었지만 실제 엔터프라이즈 애플리케이션에 적용되거나 연구된 사례는 많지 않다. 가장 대표적인 문제점이 대부분의 엔터프라이즈 애플리케이션 시스템에서 사용하는 데이터의 저장과 객체지향에서의 객체와의 연결 문제에 대한 정확한 가이드 및 사례가 없다는 것이다. 이 문제에 대해 개발자들이 지금의 웹 페이지를 만드는 것과 같이 쉽게 구현하는 수준까지 도달하지 않으면 실제 프로젝트에서 객체를 이용하여 시스템을 구현하는 데에는 한계가 있다. 그리고 CBD, 객체지향은 모델링이 가장 중요한 부분을 차지하게 되는데 객체지향적으로 분석/설계해 본 경험이 많지 않은 것도 큰 문제라고 할 수 있다.

두 번째 경우는 대외적으로는 컴포넌트 기반을 지양하고는 있지만 실제 프로젝트 내부를 들여다보면 단순히 프로젝트의 기반이 되는 프레임워크나 아키텍쳐만 객체지향 기반 또는 컴포넌트 기반을 사용하고 시스템의 가장 중요한 요소인 실제 업무를 수행하는 기능의 구현에서는 기존의 구조적 프로그래밍 기법을 사용하는 경우이다. 따라서 프로젝트에서 사용한 기술이나 방법론은 CBD를 이용하였지만 프로젝트 완료 후 재사용 가능한 컴포넌트는 거의 없으며 모든 컴포넌트들이 내부적으로는 기존의 구조적 프로그램에서와 같이 복잡한 SQL문으로 구성되어 있는 경우가 많다.
이것에 대한 원인은 앞에서 살펴본 패러다임의 변화에서 "구조적 → 객체지향 → 컴포넌트"의 방향으로 정상적으로 이동한 것이 아니라 "구조적 → 컴포넌트"로 이동함으로써 컴포넌트 기반의 기본 기술을 구성하는 객체지향에 대한 경험이 없었다는 것이다.
프로젝트의 기본 구조를 구성하는 프레임워크의 경우에는 숙련된 객체지향 개발자가 만들어진 것을 사용하여 프로그램의 구조 자체는 컴포넌트의 모습을 갖추었다. 하지만 실제 개발자들이 설계/구현하는 비즈니스 로직의 경우 객체지향에 대한 설계/구현 능력 또는 경험의 부족으로 개발자들에게 익숙한 구조적 프로그래밍의 모습으로 만들어 진 것이다.
실제 CBD 방법론을 적용하여 진행된 프로젝트에서 만들어진 컴포넌트를 재사용 한다거나 다른 컴포넌트로 대체하기에는 어려운 점이 많다. 동일한 테이블 구조를 가지면서 단순히 테이블명, 컬럼명 정도만 틀린 사이트 정도에 다른 프로젝트에서 생성한 컴포넌트를 적용할 수 있는데 엔터프라이즈 애플리케이션에서 이런 경우는 거의 드물다 할 수 있다. 따라서 현재 EJB에서의 재사용성이라는 것은 동일한 시스템 내부 또는 외부 시스템에서 분산 환경으로서의 재사용성만 의미를 가지고 있다(서비스 제공의 형태). 그렇기 때문에 CBD를 이용하여 소프트웨어 개발의 생산성 향상이라는 것은 공염불에 지나지 않고 CBD 진영에서 영역 확장을 위한 사탕발림이라 할 수 있다. 지금까지 많은 프로젝트들을 보면 굳이 EJB로 구축할 필요가 없는 시스템임에도 불구하고 EJB를 구축한다던 지 아니면 단순히 JSP/ Servlet만 운영하는데 있어서도 Weblogic, WebSphere 등과 같은 고가의 WAS를 도입하고 있는 사례를 많이 볼 수 있다.

따라서 진정한 재사용 가능한 컴포넌트를 만들기 위해서는 늦었지만 우리가 아무렇제 않게 뛰어 넘은 객체지향 패러다임에 대한 연구와 동일 조직내에서 몇개의 파일럿 프로젝트에 적용함으로써 엔터프라이즈 애플리케이션에서의 객체지향 기술을 축적하는 것이 먼저라고 생각한다.