[지디넷코리아]서버에 HTML 문서와 이미지 정도를 올려놓는 것으로 시작한 웹은 이미 다수의 시스템이 지향하는 목표가 됐고, 이 애플리케이션들이 지향하는 동작 환경으로서 자리매김한 지 오래다. 이런 추세에 따라 기존의 애플리케이션 구축을 위해 필요로 하던 복잡성 또한 웹 개발 환경에 고스란히 반영되어 있다.

반면 웹 자체가 표준이듯이 이를 구축하기 위한 표준들이 제시되고 있고 개발자는 일정 수준 이러한 틀 안에서 작업을 주로 수행하게 된다. 매번 이 복잡한 틀을 만들고 고쳐나가는 것보다 본인에게 맞는 틀을 선택하고 그 안에서 실행되는 애플리케이션 구현에 집중하는 것 또한 충분히 고려해볼 만한 일일 것이다. 흔히 프레임워크라 불리는 이러한 틀들과 이의 가치를 한 번 살펴보자.

프레임워크라는 단어는 틀, 구조, 얼개, 하부구조 등으로 번역할 수 있다. 소프트웨어의 개발과 활용을 전제로 한다면 애플리케이션의 동작을 뒷받침하는 짜여진 하부구조 정도로 해석할 수 있다. 혹자는 라이브러리의 집합체로 이해하면 된다고 하기도 하고, 컴포넌트들의 유기적 집합체라고 이야기하기도 한다.

웹의 근간을 이루는 웹 서버와 HTTP 프로토콜을 이용한 통신, HTML 문서와 이를 화면에 표현해내는 브라우저가 이루어내는 구조도 프레임워크라 하고, HTML 문서를 구성하는 문법적 요소들 또한 프레임워크라 부를 수 있을 것이다. MVC(Model-View-Controller)라는 구조 자체를 프레임워크라고도 하고, 이를 보다 쉽게 구현할 수 있도록 환경을 제공하는 컴포넌트들의 집합체를 프레임워크라 하기도 한다.

최근 많이 접하게 되는 프레임워크라는 단어와 컴포넌트라는 단어의 공통점이 보는 이에 따라서 그 규모가 달라질 수 있다는 점이다. 프레임워크라는 단어와 컴포넌트라는 단어 자체에 이를 구성하는 하위의 프레임워크와 컴포넌트, 이를 부분으로 수용하는 상위의 프레임워크와 컴포넌트가 있을 수 있음이 내재하고 있는 셈이다.

이 두 용어의 또 하나의 공통점이 재사용이 가능하다는 점이다. 붕어빵의 틀-프레임워크의 가치는 붕어빵 하나를 굽는 데 그치지 않고, 오디오 시스템을 구성하는 스피커를 떼어내 텔레비전의 스피커를 대신하도록 사용할 수도 있다. 더군다나 무한히 복제할 수 있는 소프트웨어의 특성을 고려하면 재사용이라는 의미가 원래 사용하던 곳의 결함이라는 의미로 이어지지도 않는다.

AV 시스템의 스피커 기능이 제거되는 것이 아니라 똑같은 기능을 수행하는 스피커를 만들어 텔레비전의 스피커를 대신하는 것과 같은 일들을 당연히 받아들일 수 있는 곳이 소프트웨어와 이를 개발하는 세계다. 이러한 재사용은 재사용에 익숙해진 이후부터는 생산성을 높여준다는 미덕도 동반하게 된다.

프레임워크와 재사용의 의미
다시 붕어빵 이야기를 해보자. 자기가 먹을 요량으로 복잡한 붕어 모양의 빵을 몇 개 만들고 말거라면 손으로 반죽을 주물러 빵을 구우면 될 것이다. 하지만 이 복잡한 붕어 모양의 빵을 반복적으로 만들어 판매까지 해야 한다면 붕어 모양 조각에 들어가는 수고에 대해 돈을 지불하면서 사먹을 손님은 기대하기 어려울 것이다(요새 유행하는 요리 만화에서라면 어린 시절 고향의 냇가에서 볼 수 있던 생동감 넘치는 붕어의 모습이라며 감탄하며 눈물을 흘리는 것도 가능하겠지만).

밀가루를 반죽해 붕어 모양을 만드는 대신 처음에는 밀가루 반죽보다는 어려운 쇳물을 부어 틀-프레임워크를 만드는 작업이 필요하고, 이 틀을 구입하는 초기 비용은 적지 않을 수 있다. 또 된 밀가루 반죽 대신 묽은 밀가루 반죽을 사용해야 한다는 사실 등 틀을 이용해 작업하는 방법을 스스로 깨닫거나 외부로부터 배우는 데 시간과 비용이 추가된다. 하지만, 이러한 초기 투자는 붕어빵 틀이 주는 생산성에 힘입어 일정 시간 후 회복될 것이다.

프레임워크 도입시 반드시 고려해야 할 부분이 이의 도입이 기대하던 효과를 발휘하기 위해서는 프레임워크에 대한 이해와 적응이 선행되어야 하고 이 수준에 이른 후의 재사용을 통해 초기의 투자비용을 만회하고 생산성을 확보할 수 있는 것이지, 프레임워크 도입이 바로 생산성으로 이어지지 않는다는 점이다.

붕어빵 틀도 사용법을 배우고 익히는 시간을 필요로 한다. 붕어빵보다 훨씬 다양한 경우의 애플리케이션을 지원하는 프레임워크의 경우 그만큼 복잡하고 이를 이해하고 활용하기 위한 투자를 필요로 한다.

종종 프로그래밍 언어를 배우는 것이 어려운지, 프레임워크를 배우는 것이 어려운지를 묻는 질문에 접하게 된다. 어려움이라는 막연하고 주관적인 개념에 대해서는 해답을 내리기 어렵지만 숙지해야 할 점들의 양은 프레임워크가 훨씬 많다는 사실은 이야기할 수 있다. 최소한 프레임워크에서 지원하는 언어의 지원과 한계에 대한 인식에 더해 프레임워크의 지원과 한계를 알아야 하기 때문이다.

생산성 등에 대한 고려 없이 하던 일을 반복하는 기계적 처리 역시 전혀 창의적이지 않은 방법으로 업무를 소화하는 데 급급할 뿐이라 할 수 있겠지만 프레임워크 도입이 별도의 투자 없이 생산성을 이끌어낼 것이라는 기대 역시 경계해야 할 접근법이다.

도전할 만한 프레임워크의 체급
범용 개발환경에서 웹을 지원하지 않는 개발도구를 찾아보기가 오히려 어려울 정도로 웹이라는 환경에 접근하는 다양한 개발도구가 소개되고 있다. 대중적 인기를 얻고 있는 웹 전용으로 탄생한 언어적인 환경(언어라고 하기에는 낮은 레벨의 환경 성격이 강하고 환경이라고 하기에는 언어적 특성이 강한)만 하더라도 ASP, PHP, JSP와 서블릿 등을 떠올릴 수 있을 것이고 이들은 이미 전형적인 웹 이외의 개발도 가능한 수준에 이르고 있다.

또한 닷넷과 J2EE라는 프레임워크가 무서운 속도로 세를 확장하고 있고 웹서비스라는 언어 독립적인 운영 프레임워크도 웹 애플리케이션 개발의 주역으로 조명을 받고 있다.

마치 인형 안에 인형이 들어있고 다시 그 안에 인형이 들어있는 러시아의 마트로시카 인형처럼 프레임워크를 둘러싼 프레임워크와 프레임워크 안에 들어가 있는 프레임워크들로 가득 차 있는 곳이 개발자가 업무를 수행해야 하는 공간인 셈이다. 개발자라면 의도했건 아니건 간에 프레임워크를 사용하고 있는 셈이고, 사용자 또한 눈에 보이지 않는 프레임워크의 도움을 받는 애플리케이션들을 사용하는 셈이다.

ASP에 버금가는 스크립트 언어를 만드는 것도 웹 프로그래밍이고, 서버와의 연결 없이 클라이언트 안에서 동작하는 자바스크립트로 무언가를 만드는 것도 웹 프로그래밍이다. 웹 프로그래밍의 범위만큼 사용하는 프레임워크도 다양한 것이다(자바스크립트가 경량급이고 ASP를 만드는 것이 헤비급이라는 의미는 아님을 밝혀둔다).

이러한 규모 또는 범위에 관한 문제는 ‘갑도 옳고, 을도 옳고 둘 다 옳다니 말이 되느냐고 묻는 병도 옳은’ 황희 정승 식의 해법밖에 기대하기 어려운 문제이다.

반면 웹 개발자 대부분이 반복적으로 프로그래밍해야 하는 영역을 유추해 보면 개발에 있어서의 재사용이라는 점을 극대화할 수 있는 도전할 만한 체급의 프레임워크를 생각해볼 수 있을 것이다. 개인적인 의견이나 다음과 같은 정도의 기능을 지원하는 환경 위에 이를 더 쉽게 재활용 가능하도록 구현해 놓은 프레임워크라면 다수의 웹 프로그래머가 도전할 수 있는 체급으로 인정받을 수 있을 것이라 생각한다.

위의 조건은 개인적인 의견이며 이에 대한 가감이 글의 주제는 아니니 이는 논외로 하고자 한다. 위의 조건들을 지원하는 수준이 아닌 이를 가공해 더 쉬운 접근과 재사용이 가능하도록 한 수준이 위의 프레임워크들에 대한 글이고, 이들의 사용법이 아닌 이들의 가치에 대해 이야기하고자 하는 것임을 다시 한 번 밝혀두고 몇몇 지명도 높은 프레임워크들을 살펴보고자 한다.

달콤하게 익어가는 PHP의 PEAR
PHP는 특정 업체의 주도라는 율법을 따라 흐르는 성직자들의 산물이 아닌 다수가 외치는 대세에 따라 흐르는 상인과 고객들이 만들어낸 상품이다. 소프트웨어와 관련해서는 성직자들의 산물에 대해서는 무조건 돈을 지불해야 하고 상인들과 고객들이 만들어낸 상품은 이에 참여하지 않은 고객에게도 무료로 전해지기도 한다는 사실이 실세계와의 차이를 느껴보게 해주기도 한다.

몇 년 전만 해도 대기업 사이트에서는 계속 외면할 것 같던 PHP에 대한 평가 절하는 일찌감치 옛날이야기가 되어 버렸고 이제는 금융 사이트와 심지어 ASP, JSP를 기반으로 영업을 하고 있는 소프트웨어 개발 업체의 홈페이지에서도 만나볼 수 있는 환경이 됐다.

PHP4가 이러한 대중적인 지지를 확보하던 무렵 개인적으로는 카피앤페이스트(Copy and Paste)조차 지겹다는 생각과 포털 사이트의 일정관리 기능 등에 사용하던 날짜 관련 함수 등에 주먹구구식 변경 작업이 쌓여가는 것을 보면서 이런 부분들을 담당하는 라이브러리들을 모아서 프레임워크를 만들면 어떨까 하는 생각을 했다.

필요로 하는 기능들은 이미 다 만든 듯한데, 이에 대한 교통정리와 변경 작업이 반복되는 시점에서 느껴지는 피로감-정확히 말하면 게으름과 지겨움-으로부터 돌파구를 찾고 있었던 듯하다. 이렇게 생산성이라는 단어와 어울리지 않게 보이지만 게으름이라는 단어가 생산성 추구의 한 동기가 되어주기도 한다.

당연히 남들은 어떻게 할까라는 궁금증이 뒤를 이었고 그 때 만나게 된 것이 PEAR였다. 하지만 그 때의 PEAR는 아직 맛을 보면 시큼함이 남아있을 것 같은 시작 단계의 프레임워크였다. 이미 웹 메일 등을 구축하기 위해 참조하던 IMP 웹메일(www.horde.org)의 PHP 관련 프레임워크가 설치되어 있던 시점이라 PEAR에 대한 관심은 잠시 접고, IMP 쪽의 프레임워크를 들여다보자는 방향으로 결론을 내렸다.

하지만 이러한 결론을 가지고 변절한 게으름을 생산성으로 승화시키기에는 필자의 게으름이 너무나 순수한 게으름이었나 보다. 결국 그 프로젝트를 진행하는 동안은 관련 문서들만 틈날 때마다 읽었을 뿐 프레임워크를 도입하지는 못했다.

프로그래밍 언어에 대한 문법을 익히는 만큼 프레임워크라는 장르를 구성하는 형식을 익혀야 한다는 교훈만 남은 셈이었다. 다시 말하지만 프레임워크에 대한 교육과 훈련 없이 프로젝트를 진행하면서 이에 적응하겠다는 사고는 프로젝트에 대해 지불하는 고객의 돈을 개발자의 학습비로 사용하겠다는 이야기를 하는 것과 다름없을 것이다.

사내 프로젝트에서 사용해 가며 적응하겠다는 경우도 결국 교육에 투여되는 만큼의 비용과 시간이 교육비와 교육 시간이라는 명목만 갖추지 않았을 뿐 눈에 보이지 않는 형태로 소요될 것이다.

잘 익은 배와의 만남
남의 떡이 커 보이는 법이라 했던가? 남이 하면 일도 재미있어 보이는 것 같다. 아니 정확히 말하면 하던 일도 멍석을 깔아주면 하기가 싫어지는 심리도 포함되어야 할 것 같다. PEAR를 본격적으로 수확하기 시작한 것은 본업으로 JSP와 서블릿 기반의 사이트를 유지 보수하던 때였다. PHP를 붙잡고 살 때는 그리 대단해 보이고 재미있을 것이라 생각했던 JSP와 서블릿이 막상 만지게 되니 지루함으로 이어졌다.

더군다나 남이 짜놓은 코드를 유지 보수라는 명목으로 테스트하는 수준의 프로젝트였고 게다가 이미 개념이 잘 알려져 있던 MVC 패턴과 같은 계층화(layering)도 적용하지 않은, 필요하면 데이터베이스 연결하고 데이터 읽고 저장하는, 원 개발자가 서블릿으로 구현하고 싶을 때는 서블릿으로, JSP로 구현하고 싶으면 JSP로 구현해 놓은 코드였다. 코드 대수술이라는 모험을 감행해 보기에는 리스크만 크고 리턴은 작은 경우라 더 지루해 하던 때였다.

이 때 지인으로부터 PHP에 대한 문의가 들어왔다(그렇다. 솔직히 말해 돈 안 되는 아르바이트 거리가 들어온 경우였다). 이야기를 들어보니 초보 PHP 개발자들에 대해 코딩 표준, 변경 관리, 서버 운영 규칙 등 업무 진행에 필요한 지침을 만들고 가지고 있는 라이브러리 등이 있다면 제공해 줄 수 있냐는 의뢰였다.

돈 안 되는 일은 사양한다는 프로 정신을 발휘하던 때였지만 옆에서 이것저것 시도해 보는 PHP 개발자들의 모습을 보니 $로 가득 찬 PHP 프로그래밍을 한다는 것이 길에서 $를 줍는 것만큼 재미있어 보였다. 게다가 결과물에 대한 책임이 따르는 요구도 아닌지라 바로 제의를 수락했다.

그렇다고 남에게 보여줄 만큼 잘 정리된 라이브러리를 가지고 있을 만큼 나의 게으름이 변질(?)되지는 않은 터라 PEAR를 떠올렸고, 이것이 본격적으로 PEAR의 맛을 보기 시작하는 계기가 됐다. 갓 구성된 팀이 단번에 잘 정의된 코딩 스타일과 적지 않은 예제를 소유하게 됐고, 데이터베이스의 호출과 데이터에 대한 CRUD 작업을 수행하는 코드들을 반복적으로 베끼거나 Include해 사용하던 수준에서 일정 수준 이상 물리적 데이터베이스에 대해 중립적인 코드들을 만들어내는 수준까지 어렵지 않게 진행했다.

심지어 SQL 문장을 담고 있는 파일을 만들어 SQL 문장을 재사용하기도 하고 애플리케이션 관리자용 기능, 서버 관리 기능 등을 만들면서 재미있어 하는 모습을 보니 질투가 날 정도였다. 게시판 만드는 언어가 PHP이라고 막연히 생각하던 친구들이 SQL 구문을 고민할 수 있는 시간을 가지게 되고, 반복되는 부분은 효용성을 판단해 재활용 가능하게 가공하는 ‘리팩토링’을 수행하기도 했다.

생산성이 얼마나 늘어났는지를 계량화해 이야기하기는 어렵겠지만, 적어도 학원에서 교재로 접한 ‘PHP로 게시판 만들기’ 수준의 코드만 접해본 개발자들이 PEAR라는 수준 높은 코드를 접하고, PEAR의 외형뿐 아니라 이를 구성하는 사상까지 접함으로써 눈에 접한 수준만큼의 실력 향상을 꾀했다는 점은 확실하게 경험했다.

오히려 학원을 갓 나온 개발자보다 1～2년 PHP를 경험한 개발자들이 PEAR라는 프레임워크의 일부 기능을 가리키며 ‘나도 이 정도는 짤 수 있다’고 주장하던 경우들이 PEAR라는 프레임워크 도입에 방해가 됐던 것 같다. 또 부수적으로 PEAR 의 CVS 업그레이드를 통해 CVS에 대한 이해도 어느 정도 공유할 수 있었고 이를 통한 버전 관리도 어렵지 않게 수행할 수 있었다는 점도 기억에 남는다.

경험을 적고 보니 스스로 대단한 일을 한 것 같아져 버렸는데 솔직히 “일단 시키는 대로 해보고 이야기하세요.” 이상의 정보를 제공한 기억은 없다고 해야 할 것 같다. 처음 목표는 PHP를 사용하는 팀 내부에 혼재해 있는 사투리를 임의의 표준말로 통일하는 것이었는데 기대하지 못했던 결과까지 이끌어낸 것은 개개인의 노력에 기인했을 것이라 생각한다.

굳이 PHP 개발자가 아니더라도 아래 사항에 해당하는 개발자이고 사용 중인 프레임워크가 없다면 이의 도입에 대해 고려해 보기를 권하고 싶다.

다양한 블렌딩의 자바 프레임워크
PHP가 자유로운 시장의 산물이라면 자바는 상대적으로 엄격한 틀 안에서 시장의 흐름을 따르고 있는 것으로 보인다. 자바도 PHP만큼 자유로운 개발과 재배포가 이루어지는 부분과 비교적 유연하게 외부의 요구를 수용하고 있으나 엄연히 썬이라는 업체가 표준을 주도하고 있기도 하다. 상인과 고객이 만나는 시장이 아닌 상인 대표와 고객 대표가 만나는 회의 정도가 자바라는 시장의 의사를 결정하고 있다고 표현할 수 있을 것 같다.

자바 세계에는 이미 J2EE라는 걸출한 프레임워크가 나와 있다. 하지만 J2EE 프레임워크는 상대적으로 하부에 위치하는 프레임워크로 이를 주춧돌로 삼은 또 하나의 프레임워크 계층을 만드는 것이 설득력 있어 보인다.

상용 웹 애플리케이션 서버 업체들이 자사 고유의 프레임워크를 제공하기도 하고, 오픈소스 웹 애플리케이션 서버도 또 다른 오픈소스 프레임워크를 포함하거나 제공하기도 한다. 오라클 같은 업체들도 BC4J(Business Components for java)라는 설득력 있는 제품을 내놓고 있다.

아파치 자카르타 홈페이지(jakarta.apache.org)를 방문하면 입이 다물어지지 않을 정도로 수많은 프레임워크들과 다시 이들을 조합한 프레임워크들이 소개되고 있다. 앞서 잠시 언급한 MVC 모델의 구현에는 썬이 주도하는 표준은 아니나 Struts라는 자카르타 서브 프로젝트가 사실상 표준으로 자리 잡고 있고, 데이터베이스와 관련하여 JDO, Hibernate 등 ORM(Object Relational Mapping)을 담당하는 주제로 이야기하고자 하는 프레임워크보다 작은 영역을 책임지는 프레임워크들도 세기 힘들 정도이다.

J2EE 환경에서 자신에게 맞는 프레임워크를 선택한다는 것만 해도 쉬운 일이 아닌 것이다. 막연하게 지명도 있는 프레임워크를 선택하는 것도 하나의 방법이라면 할 말은 없으나 자신이 필요로 하는 기능과 프레임워크가 제공하는 사상을 파악해 적합한 프레임워크를 선택할 수 있어야 할 것이다. J2EE 기반 프레임워크들이 일반적으로 갖추는 형상에 대해 먼저 이해하고 있어야 하는 것이다.

그 다양한 프레임워크들을 어떻게 이해해야 하는가는 이들이 J2EE 기반이라는 점에서 힌트를 얻을 수 있을 것이다. J2EE의 사상 중 일부가 이들 프레임워크의 사상의 근간이 될 터이니 J2EE의 사상을 먼저 이해해야 할 것이다.

J2EE 프레임워크 구현과 도입 사이
JSP 스펙이 1.0을 넘어갈 무렵 본격적으로 JSP와 서블릿을 이용하는 프로젝트를 수행하기 시작했다. 이미 만들어져있는 프레임워크를 도입한다는 생각보다는 자사의 자바 패키지, 공통 모듈을 만든다는 정도로 애플리케이션의 공통 기반 환경에 대한 업무를 설명하는 것이 더 쉽게 이해가 가는 상황이었다.

자료구조와 관련된 기능들을 모아서 패키지를 만들고, HTML 패키지, 문자열(String) 처리를 위한 패키지, 데이터베이스 연결과 SQL 처리 관련 패키지 등을 만드는 것이 업무의 주를 이루고 있었다. 이미 앞서 언급한 상용 프레임워크들이 속속 등장하기 시작하던 때이고 오픈소스 프로젝트들이 제 궤도에 오르고 있던 때라 기억된다.

애플리케이션의 기반 환경보다는 애플리케이션 자체의 구현과 실행에 초점이 맞추어져 있고 보니 상용 프레임워크만큼 이에 투자를 할 상황은 당연히 아니었고, 가속이 붙은 오픈소스 프레임워크 프로젝트들의 발전 속도는 얼마 지나지 않아 수행하던 프로젝트에 사용되던 공통 모듈 패키지의 질을 능가하기 시작했다.

자고 일어나면 새로 인정되는 표준들, 자바의 버전업, 스펙의 버전업을 반영한다는 것은 주어진 자원으로는 불가능하다는 결론을 얻기까지는 그리 오랜 시간이 걸리지 않았다. 양질의 패키지들이 쌓이는 것도 아니었고 패키지 명세서에 대한 문서화가 잘 이루어지는 것도 아니었다. 상용, 오픈소스 프레임워크와 비교할 때 당연히 재사용의 가능성도 뒤처지고 있었다. 상용이라면 그만큼의 투자가 이루어지니 투자한 자원을 가지고 질에 대한 변명을 할 수 도 있겠지만 오픈소스의 경우는 대단하다는 표현 이상 할 말이 없는 셈이었다.

두 번째 프로젝트가 시작할 무렵에는 미쳐 모듈화를 고려하지 못한 부분 등에는 오히려 오픈소스 프레임워크들의 소스를 차용하는 수준이었다. 다수의 J2EE 개발에 있어서 필요로 하는 부분들을 어설픈 실력으로 가공하는 것보다 견고한 프레임워크 하나를 도입하고, 해당 프레임워크에서 제공하지 않거나 부족한 부분들을 보충해 사용하는 것이 훨씬 현명한 일이라는 사실을 몸으로 깨달은 셈이었다.

현재는 J2EE와는 무관한 영역의 프로젝트를 진행하고 있는 터라 취미삼아라고 표현할 수 있을 정도로 여유를 가지고 이들에 대한 공부를 하고 있다. 프레임워크는 설치한다고 끝나는 것이 아니라 사용할 수준이 되는 것이 시작이기 때문이다.

최근 공부하고 있는 것 중 하나가 JSF(Java Server Faces)이다. 자바를 가지고 웹 개발을 하는 이들을 위한 프레임워크라고 소개되고 있으니 눈이 가지 않을 수 없다. 썬의 JSF뿐만 아니라 Smile(smile.sourceforge.net), MyFaces(www.myfaces.org) 등 오픈소스 JSF도 눈여겨 보아둘 만하다. 썬의 JSF 재배포와 관련한 라이선스 문제 등으로 오픈소스 프레임워크의 경우 이들 오픈소스 JSF를 포함할 가능성이 크기 때문이다(Smile과 MyFaces라는 이름에서 보듯이 JSF 관련 프로젝트들은 얼굴이라는 단어에 집착하는 것 같다. Smile과 Myfaces의 경우 두 프로젝트 사이에 공동 개발이 진행되고 있다).

또 개인적으로는 많은 도움이 됐다고 생각하는 Wrox 출판사의 『Expert One-on-One J2EE Design and Development』의 저자 Rod Johnson이 주도하는 Spring 프레임워크(www.springframework.org)의 경우도 저자가 책에서 이야기하던 내용의 연장선상에서 여타 프레임워크들과는 차별화된 사상을 보여주는 경우라 생각되어 열심히 만져보고 있다. 그의 말대로 J2EE 같은 구현 기술보다 객체지향 설계가 중요하다는 사상과 테스트에 대한 강조 등이 고스란히 녹아 있다는 생각을 하게 된다(Spring에 대해 비판적인 시각이 없는 것은 아니다).

상대적으로 좁은 폭의 기술적 주제에서 벗어나 객체지향이라는 넓은 시각에서 프레임워크가 갖추어야 할 모습들을 살펴 볼 수 있는 셈이니 접해 본다면 프레임워크의 사용을 떠나서 J2EE와 애플리케이션의 중간에 위치하는 프레임워크의 이해에도 큰 도움을 받을 수 있을 것이다. 아파치 자카르타 프로젝트의 프레임워크들에 견줄 만하다는 의견을 갖고 있다.

닷넷 환경의 프레임워크
PHP와 J2EE 프레임워크에 대한 글을 읽고 닷넷에 대한 기대를 했다면 먼저 죄송하다는 말씀을 드려야겠다. ASP를 가지고 프로젝트를 진행해본 경험은 있으나, 아직 ASP.NET을 가지고 남의 돈을 받는 프로젝트를 수행해본 경험은 없는 터라 실전 경험이 없는 상태이기 때문이다.

ASP.NET의 경우 개발사의 철저한 관리와 주도라는 성직자의 율법을 따르는 경우라고 할 수 있을 것이다. 견고함을 얻을 수 있는 방법이기는 하나 유연함을 발휘하기는 어려운 방법이기도 하다. 하지만 적어도 ASP의 연장선에서 ASP.NET을 바라본 경우 그 유연함에 대한 우려를 불식시킬 수 있는 수준으로 제작사가 이를 가꾸고 있다는 생각이다.

앞서 COM, DCOM 등 세부 구현 기술보다는 설계 사상을 어떻게 반영하고 있는가가 프레임워크를 평가하는 중요한 기준이 되어야 한다는 주장에 동의한다고 이야기했다. 닷넷 자체가 그 안에 재사용 가능한 수많은 컴포넌트들이 포함된 통합 프레임워크이고 아주 낮은 계층에서부터 데이터의 객체화, 사용자 인터페이스 등 애플리케이션과 직접 만나는 계층까지를 포함하고 있으니 별도의 프레임워크가 구현될 틈이 넓지는 않은 셈이다.

잘 구현되고 잘 문서화되어 있다는 점도 이러한 견고성을 한층 돋보이게 해주는 부분이 될 것이다. 프레임워크의 활용을 돕는 또 하나의 프레임워크보다는 오히려 프레임워크 안에서 기능을 확장하는 컴포넌트 개발과 도입이 주를 이루는 경우다.

다만 객체의 영속성을 보장하기 위해 관계형 데이터베이스를 사용하는 경우 발생하는 불일치에 대해서는 설계의 사상을 고스란히 옮기기에는 어려운 부분이 있다. MS SQL과 ADO.NET 간에는 이러한 불일치를 어느 정도 조정할 수 있도록 기능이 제공되고 있으나 객체지향 설계를 가지고 자동으로 코드를 생성할 수 있는 수준에는 못 미치고 있으며 관계형 데이터베이스가 MS SQL만 존재하는 것도 아니다.

이런 이유에서 닷넷 프레임워크 안에서 이를 반영할 수 있는 하부 프레임워크에 대한 다양한 접근이 시도되고 있다. 대표적인 예로 오픈소스 프로젝트로 진행되고 있는 Olero(www.olero.com)를 들 수 있다. ORM 설계에 따라 데이터 접근 코드를 생성해 주는 프로그램으로 자바의 JDO, Hibernate 등처럼 객체와 관계형 데이터베이스를 연결하는 프레임워크를 제공한다.

자바 서버가 연주하는 플래시, 플렉스
웹 프로그래밍을 업으로 삼은 뒤로 계속되는 고민이 사용자 인터페이스에 대한 부분이다. HTML의 폼(Form)만 가지고 사용자와의 상호 작용을 처리하기에는 늘 부족함을 느끼게 된다. 그런 이유에서 지속적인 관심을 기울이고 있는 것이 플래시다. 디자이너들만큼 멋진 화면을 만들지는 못하지만 자바스크립트와 동일한 문법으로 프로그래밍 할 수 있다는 장점도 플래시에 대한 접근을 수월하게 해주었다.

아직 외곽에서 구경만 하는 수준이지만 웹 애플리케이션 서버에서 MXML을 이용해 플래시 애플리케이션을 생성하고 자바 객체에 대한 접근이 가능하다는 매력을 지닌 매크로미디어의 플렉스(FLEX)라는 제품도 주목할 만하다. 웹 브라우저라는 전통적인 클라이언트 환경을 플래시로 대체하고, 고유의 데이터 연결, XML 입출력을 지원하고 있으니 충분히 또 하나의 프레임워크라 부를 수 있을 것이다.

앞서 언급한 웹 개발 관련 프레임워크들이 주로 서버 쪽에 치우쳐 있다는 인상을 주고 있는 반면에 플렉스의 경우 서버와 클라이언트 모두를 고려하는 프레임워크라 할 수 있겠다. 현재는 자바 기반의 웹 애플리케이션 서버에서만 동작하나 곧 닷넷에 대한 지원도 이루어진다고 하니 주의 깊게 살펴볼 제품 중 하나라 생각한다.

아키텍처와 프레임워크
글을 써가면서 계속 사용하고 싶었던 단어가 ‘아키텍처’라는 단어였다. 아키텍처를 구현하고 있는 것이 프레임워크라 이해할 수 있고, 프레임워크의 아키텍처를 살펴보는 것이 프레임워크를 이해하는 것이라고 간단하게 이야기하고 싶었지만 프레임워크라는 용어조차도 적절히 설명할 수 있는 수준이 못된 터라 아키텍처라는 용어의 사용을 망설였다.

프레임워크를 구성하는 개개의 코드를 보면서 ‘나는 이것보다 더 잘 만들 수 있다’는 생각을 할 수 있을 것이고, 그 생각이 틀리지 않을 수 있다. 하지만 건물을 이루고 있는 벽돌 하나를 더 잘 구울 수 있다고 해서 건물을 더 잘 지을 수 있는 것 또한 아니라는 점도 주지해야 한다.

단순히 스스로 구현하는 것보다 남이 사용할 수 있는 수준으로 구현하는 것이 더 어려운 일이고, 이를 사용하는 것 또한 이의 구현 못지않게 어려운 일일 것이다. 타인의 코드를 베끼는 것이 아니라 타인의 사상을 받아들이는 것이 프레임워크를 사용하는 일이라 생각한다. 끝으로 프레임워크가 제몫을 하기 위해서는 반드시 이에 대한 이해와 학습이 선행되어야 한다는 사실을 다시금 강조해 본다. @

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