[기업 환경에 닷넷 적용하기] ⑤ 닷넷 개발에서 UML과 케이스 툴의 사용

[기업 환경에 닷넷 적용하기] ⑤ 닷넷 개발에서 UML과 케이스 툴의 사용

 

연재순서
1.제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
3.엔터프라이즈 솔루션 패턴 해부하기
4.닷넷의 웹 프리젠테이션 패턴
5.닷넷 개발에서 UML과 케이스 툴의 사용

 

얼마 전 필자는 한 통의 전화를 받았다. 통화 내용은 닷넷 환경에서 작성된 ASP. NET 웹 응용 프로그램이 클라이언트의 CLR 버전을 알 수 있느냐는 내용에 대한 질문이었다. 간단한 질문이라 Request 객체의 Brawser 속성 중 ClrVersion에 액세스하면 알 수 있다는 답변을 하고 전화를 끊었다. 전화를 끊고 나서 떠오른 의문은 ‘ASP.NET 웹 응용 프로그램에서 클라이언트의 CLR 버전을 알 필요가 있을까?’라는 것이었다. 윈폼으로 작성된 프로그램을 클라이언트로 다운받아 실행하는 것이 아니라면, ASP.NET 응용 프로그램이 동작하기 위해 CLR이 필요한 경우는 거의 없기 때문이다.

나중에 이어진 전화 통화에서, “ASP.NET 응용 프로그램이 동작하기 위해 클라이언트에 CLR이 필요한 경우는 거의 없다. 정말 없다고 봐도 무방하다”고 말했고, 전화를 받은 실무 담당자는 “우리 회사에는 윈도우 98이나 심지어 윈도우 95 운영체제가 설치된 여러 대의 컴퓨터가 동작하므로 안심할 수 없다”라고 했다. 필자는 아무런 문제가 없다고 했지만, 담당자는 “선생님께서는 책만 보고 공부하시니 실무에서 발생할 수 있는 여러 문제에 대한 이해가 부족하다. 실무에서 소프트웨어가 동작하다 보면 어떠한 문제가 발생할지 모른다”고 반박했다.

몇 년간 필드에서 근무하는 사람들을 만날 기회가 많았는데, 닷넷 환경에 대한 것이나 프로젝트 관련 이야기를 하다 보면 다음과 같은 이야기를 종종 듣게 된다.

“실무에서는 그렇게 못합니다.”
“그게 좋은 방법이긴 한데 실무에서는 그렇게 못하죠.”
“실무에서는…”
“실무에서는…”

이론적으로 부족하다보니 지기 싫어서 실무 핑계를 댄다고 생각할 수도 있지만, 어쩌다가 한 번씩은 무시당한다는 느낌이 들 때도 있다. 그럴 때 다음과 같이 반문한다.

“실무에서는 1+1이 3이 됩니까?”

정해진 아키텍처 기반으로 잘 정의되어 구성된 프레임워크, 이를 구성하는 디자인 패턴과 개발 방법론, 그리고 개발을 위한 케이스 툴 등 다 좋은 이야기라고 한다. 하지만 대부분 인력과 시간에 시달리는 실무 개발 환경에서 아직은 요원하다고 말한다. 하지만 훌륭한 이야기이고 좋은 말이며 그게 맞는지는 알고 있다면 왜 하지 않는가?

ASP.NET 응용 프로그램에서 코드 비하인드(Code-Behind) 파일의 코드가 5000라인을 넘어가는 재사용 불가능한 프로그램을 매번 작성하는 것보다는 바른 객체지향 기법으로 잘 설계된 프레임워크를 한 번 만들어놓고 그것을 사용하는 것이 장기적으로 볼 때 좋다. 아니 그렇지 않더라도 몇 번 정도의 프로젝트만 한다고 해도 훨씬 유리하다.

<화면 1> 비지오를 셋업하면 VS>NET 2003의 프로잭트 메뉴에 비지오 메뉴가 추가된다.

아키텍처 또는 프레임워크를 제대로 설계하기 위해서는 아무래도 코드를 직접 작성하면서 하는 것보다는 다이어그램으로 그려가면서 하는 것이 작업 효율도 높아지고 보기도 좋으며, 팀 단위 개발에 있어 많은 장점을 가져올 수 있다. 처음 비주얼 스튜디오 닷넷(이하 VS.NET)이 공개됐을 때 순공학과 역공학이 가능한 닷넷 기반에서의 케이스 도구는 비지오(Visio) 밖에 없었고 사실 너무 불편했다. 시간이 흐르면서 볼랜드 투게더, 래쇼날 로즈 등의 케이스 도구가 VS.NET에 플러그인 되었고, 비주얼 스튜디오 2005에서는 아예 케이스 도구가 기본 기능으로 추가되었다. 이제, 본격적으로 닷넷 환경에서 사용할 수 있는 케이스 도구들에 대해 알아보자.

비지오 2003
MS 비지오 2003은 닷넷 환경이 처음 공개됐을 때 코드 역공학과 순공학이 가능한 것만으로 여러 개발자들 사이에서 화제가 됐던 제품이다. 볼랜드 투게더 또는 래쇼날 로즈와 비교했을 때 그 기능이 단순하고 미비하기 짝이 없지만, MS는 장기적으로 닷넷 환경에서 사용되어야 하는 여러 다이어그램들을 구성하고 사용하기 위한 도구로 비지오를 선택했던 것 같다. 비즈토크 서버의 초기 버전들에서 오케스트레이션을 구성하기 위한 드로잉 도구도 비지오 인터페이스를 가지고 있었고, 여러 오피스 제품들에서 다이어그램을 작성하기 위한 도구도 비지오 인터페이스를 가지고 있었다.

볼랜드 투게더나 래쇼날 로즈 등의 도구는 코드의 변화 또는 다이어그램의 변화를 실시간으로 서로 적용시켜 주지만 비지오는 그렇지 않다. 비지오는 <화면 1>과 같이 작성된 역공학 작업에서 작성된 코드를 리버스 엔지니어링 하면 비지오 파일을 생성한다. 물론 실시간 동기화는 불가능하다.

<화면 2>비지오의 클래스 다이오그램 드로잉과 역공학 UML 관련 메뉴

비지오에서 작성된 다이어그램을 VS.NET로 순공학하는 것 역시 가능하다. 역공학에서와 마찬가지로 다이어그램과 소스코드 간의 실시간 동기화는 불가능하고, 작성된 다이어그램을 역공학하면 새 VS.NET 프로젝트를 생성하거나, 소스코드를 수동적으로 생성한다.

비지오는 이러한 역공학과 순공학 이외에도 표준 UML이 제공하는 거의 모든 다이어그램들을 제공하고 VS.NET과 병행 작업을 진행할 수 있게 한다. 또한 템플릿을 이용한 여러 다이어그램을 작성할 수 있도록 지원하는데, UML의 거의 모든 표준 다이어그램뿐만 아니라 데이터베이스 다이어그램(순공학과 역공학이 가능하다), 블럭 다이어그램 등을 작성할 수 있는 기능들을 제공한다.

비주얼 스튜디오 2005 팀 스위트
비주얼 스튜디오 2005가 베타 2를 통해 그 모습을 드러내고 있다. 6개월 전에 받았던 비주얼 스튜디오 위드비 팀 시스템(Visual Studio Whidbey Team System)이 비주얼 스튜디오 2005 팀 스위트 베타 2로 이름이 바뀌었는데 이전 버전의 VS.NET들과는 확연히 변했다. 비주얼 스튜디오 2005는 5년 전, ‘2001년에 개발 환경의 패러다임 시프트’라고 불리었던 VS.NET의 등장만큼이나 큰 변화를 가져올 듯하다. 여기서는 비주얼 스튜디오 2005에서 지원하는 케이스 도구들에 대해 한번 살펴보자.

<화면 3> 비주얼 스튜디오 2005의 클래스 다이어그램

반드시 필요한 도구만 제공한다
사실, 래쇼날 로즈나 볼랜드 투게더 같은 것을 케이스 도구라고 부를 수 있는데 이들 도구는 특정 개발 방법론(예를 들어 UP(Unified Process)와 같은)을 기반으로 한 요구사항 분석 등의 개념 설계 단계, 클래스 다이어그램 등의 논리 설계 단계를 자동화 도구로 분석하고 응용 프로그램에 적용할 수 있게 되어 있다. 하지만 단적으로 말하면 비주얼 스튜디오 2005 팀 스위트는 이러한 절차적인 설계 단계들을 지원하지 않는다. 비주얼 스튜디오 2005는 MS에 따르면 ‘꼭 필요한’ 도구들만을 제공한다.

필자도 많은 개발 프로젝트들을 수행하면서 문서화를 위해 여러 케이스 도구들을 사용했다. 케이스 도구들을 사용해 다양하게 그려진 여러 다이어그램들을 깔끔하게 문서화하려고 노력하고, 실제로 그렇게 했지만 프로젝트가 종료된 시점에서 보면 언제나 작성된 문서들과 실제 소프트웨어와의 차이는 있었다. 사용하는 여러 케이스 도구들이 다이어그램과 소스코드의 동기화를 지원하여 소스코드와 클래스 다이어그램이 다르다든지 하는 문제는 웬만해서는 발생하지 않았다.

하지만 유스케이스 다이어그램 또는 활동 다이어그램 등은 100% 분석된 요구사항으로 작업할 수 없는 환경에서 개발을 진행하다 보면 요구사항은 변하기 마련이다. 그리고 변한 요구사항을 소스코드에 먼저 적용한 다음 유스케이스에 반영하는 작업들을 반복하게 된다.

결국은 처음 작성할 때는 그렇게 자랑스럽고 훌륭해 보이던 다이어그램들이 프로젝트가 꽤 진행된 시점에서는 무용지물이 된다. 만약, 고집 센 PM이 있었다면 프로젝트의 진행을 조금 늦추는 한이 있더라도 작성된 문서와 코드를 일치시키는 작업을 따로 진행하겠지만 이는 소프트웨어 개발의 라이프 사이클을 지연하게 된다.

가슴에 손을 얹고 생각해보면, 필자 역시 유스케이스 다이어그램을 제대로 그리거나 메쏘드를 작성하기 위해 모든 메쏘드의 활동 다이어그램을 작성한 적은 없다. 적당히 프로젝트의 개요 정도만을 파악하기 위해 VS.NET이 아닌 다른 케이스 도구를 실행하여 다이어그램을 그리고(또는 연습장에 손으로 그려서 그려진 다이어그램을 여러 장 복사해두기도 했다) 그 다이어그램과 프로젝트를 동기화하는 것이 아닌 코드를 작성할 때 ‘참고’하는 정도로 진행한 프로젝트가 꽤 된다(정석은 아니겠지만 프로젝트의 빠른 진행에 꽤 도움은 됐다).

하지만 반드시 있어야 되는 것은 있는 법이다. 1+1은 항상 2이고, 꽁수를 쓰더라도 1+1의 결과로 나온 2를 기반으로 적당한 꽁수를 펼쳐야 제대로 된 소프트웨어가 만들어진다. 기업용 응용 프로그램을 작성하는 프로젝트라면 당연히 응용 프로그램의 아키텍처 정도는 작성해야 하고, 작성된 아키텍처는 활동 다이어그램이나 클래스 다이어그램처럼 프로젝트가 진행되면서 적당히 변경될 수 있는 성질의 것이 아니다. 응용 프로그램 아키텍처는 한 번 지정되면 반드시 그 아키텍처를 강제해야 소프트웨어의 재사용성과 가용성을 기대할 수 있게 된다. 하나의 컴포넌트라도 여러 계층에 걸쳐 작성된다면 전체 응용 프로그램을 재사용할 수 없게 되는 최악의 경우가 발생할 수 있다.

비주얼 스튜디오 2005는 이런 식으로 ‘반드시 필요한 도구만 제공하겠다’는 철학을 가지고 있는 듯하다. 즉 반드시 필요해서 작성했다면 작성된 다이어그램대로 소프트웨어의 개발이 진행되어야 한다는 것이다. 비주얼 스튜디오 2005는 새로운 여러 디자인 도구를 지원하는데, 새로운 디자인 도구는 클래스 디자이너(class designer)와 분산 시스템 디자이너(distributed system designers)로, 분산 시스템 디자이너는 긴밀하게 통합된 4개의 도구 그룹으로 구성된다.

<그림 1> 응용 프로그램 아키텍처

이들 4개의 도구는 응용 프로그램 연결 디자이너(application connection designer), 논리적 데이터센터 디자이너(logical datacenter designer), 시스템 디자이너(system designer), 배포 디자이너(deployment designers)로 구성되고, 이들 중 응용 프로그램 디자이너와 클래스 디자이너는 시스템과 구성 요소의 그래픽 디자인 지원과 코드 생성 지원 등 주요 특성을 공유한다. 모든 디자이너는 볼랜드 투게더와 래쇼날 로즈가 그러하듯이 양방향 동기화를 지원한다.

응용 프로그램 아키텍처의 정의
예를 들어, 지난 1회 연재에서 설명했듯이 응용 프로그램은 <그림 1>과 같은 구조를 가져야 한다고 하자. 그러면 응용 프로그램 작성을 위해 참여하는 모든 개발자들이 응용 프로그램의 구조를 따라 작성해야 한다(물론 이런 아키텍처를 지켜 나가려면 케이스 도구들보다 능력 있는 PM의 올바른 팀 구성이 우선된다).

아키텍처대로 응용 프로그램을 구성한다면, 프리젠테이션 계층을 구성하는 ASP.NET 웹 응용 프로그램, 비즈니스 컴포넌트를 구성하는 클래스 라이브러리 응용 프로그램, 데이터베이스 연결을 담당하는 응용 프로그램, 서비스 인터페이스를 구성하는 웹 서비스 응용 프로그램 등의 여러 응용 프로그램 솔루션이 구성되고, 이 솔루션 하나에 구성된 여러 응용 프로그램들은 연결을 가진다. 비주얼 스튜디오 2005는 닷넷 개발에 필요한 이런 응용 프로그램의 구성 연결들을 작성할 수 있는 다이어그램을 제공한다. 그 다이어그램이 바로 응용 프로그램 연결 디자이너 (application connection designer)이다.

<화면 4> 응용 프로그램 다이어그램 추가

<화면 5> 응용 프로그램 다아이어그램이 추가된 모습

비주얼 스튜디오 2005에서 솔루션을 하나 작성했다면, 가장 처음 만나게 되는 디자이너가 바로 이 응용 프로그램 연결 디자이너이다. 응용 프로그램 연결 디자이너는 솔루션을 오른쪽 클릭하고 「Add… New Item…」을 선택하여 구성할 수 있다. 솔루션에 응용 프로그램 다이어그램이 추가되면 <화면 5>와 같은 디자인 창을 보여준다.

<그림 1>의 응용 프로그램 아키텍처를 보면 웹 응용 프로그램은 웹 서비스인 서비스 인터페이스에 연결되어 동작한다. 응용 프로그램 디자이너는 다이어그램에 추가할 수 있는 여러 도구들을 제공하는데 제공되는 도구상자에서 ASP.NET 웹 서비스를 선택하고 디자인 창으로 드래그하여 응용 프로그램 간의 연결을 공유할 수 있게 한다. ASP.NET 웹 서비스를 선택하고 디자인 창으로 드래그&드롭한 후, 두 응용 프로그램의 엔드 포인트(end point)를 서로 연결해주면 두 응용 프로그램이 연결된다.

<화면 6> 연결된 두 응용 프로그램

<화면 7> 추가된 비지니스 로직 계층 컴포넌트 응용 프로그램

응용 프로그램 아키텍처를 계속 구성하기 위해 다음 절차를 계속 진행해보자. 응용 프로그램 아키텍처는 모델을 구성하기 위해 두 개의 컴포넌트를 사용한다. 하나는 비즈니스 컴포넌트이고, 다른 하나는 비즈니스 엔티티이다. 복잡한 전자상거래를 수행하는 기업용 응용 프로그램이라면 비즈토크 웹 서비스(Biztalk WebService)를 추가해서 사용할 수도 있다. <그림 1>은 두 응용 프로그램을 일반적인 클래스 라이브러리 응용 프로그램으로 작성하므로 도구 상자에서 Generic Application을 선택하여 다이어그램에 추가하고, Generic Endpoint를 삽입한 후, 같은 방법으로 연결하여 사용할 수 있다.

마지막으로 데이터 연결이 필요하다. 데이터 연결은 도구상자의 ExternalDatabase를 선택하고 다이어그램에 삽입하여 사용할 수 있다. ExternalDatabase 구성 요소를 다이어그램에 추가하면 비주얼 스튜디오 2005는 어떤 데이터베이스에 어떻게 연결할 것인지에 대한 정보를 요구한다. 적당한 정보를 입력해주면 데이터베이스와의 연결이 완성된다.

이러한 아주 간단한 방법으로 응용 프로그램의 아키텍처를 정의할 수 있는데, 완료된 응용 프로그램 다이어그램은 <화면 8>과 같다.

작성된 응용 프로그램 아키텍처는 여러 컴포넌트의 구성을 알려주는 여러 형태의 다이어그램을 대신할 수 있다. 적당히 주석을 붙여준다면, Business Context 다이어그램도 대체할 수 있다. 이러한 개발 방법은 개발자와 분석가/설계자의 활동 영역을 확연하게 구분해 줄 수 있다. 이런 도구는 반드시 여러 직종의 사람들이 모인 팀 단위의 기업용 설계에서 문서를 찾아 보관하고 문서의 버전을 일일이 확인하는 등의 작업을 확연히 줄여준다.

<화면 8> 작성된 응용 프로그램 다이어그램

<화면 9>시스템 다이어그램

이렇게 작성된 응용 프로그램 아키텍처를 응용해서 각 하위 시스템을 설계할 수 있게 한다. 비주얼 스튜디오 2005는 시스템 다이어그램을 지원하는데, <화면 8>에서와 같이 작성된 여러 응용 프로그램을 분산 응용 프로그램에서 하나의 배포 단위인 시스템을 구성하고 조직할 수 있도록 도와준다.

비주얼 스튜디오 2005에는 클래스 다이어그램이나 배포 다이어그램 같은 많은 새로운 기능들이 포함되어 있다. 필자가 원고를 작성하고 있는 중에, 모 학교에서 동작하는 응용 프로그램이 동작하지 않는다는 연락을 받고 에러를 해결하러 다녀온 적이 있다. 오류는 커넥션 풀(connection pool)이 꽉 차서, 더 이상의 데이터 연결을 작성할 수 없다는 오류였다.

정석대로라면 응용 프로그램의 아키텍처를 제대로 설계하고 커넥션 풀링을 하나의 컴포넌트에다 위임하여 위기 상황에 즉시 대처할 수 있도록 구조를 개선해야 한다. 하지만 우선 급한 불부터 끄고 봐야 한다고, 모든 페이지와 데이터 패치를 한 다음 닫히지 않는 데이터리더 개체들을 일일이 찾아 닫아야 했다. 제대로 된 아키텍처를 기반으로 설계됐다면 이런 오류는 발생하지도 않았을 것이고, 하나의 응용 프로그램을 수정하는 것만으로 전체 프로그램의 오류가 해결됐을 것이다.

다른 도구는 필요한가?
닷넷 개발에서 반드시 비주얼 스튜디오 2005를 사용해야 하는 것은 아니다. 케이스 도구라는 것은 자동차 수리 장비와 같은 것이다. 수 없이 많은 도구들 중에 자기 손에 가장 맞고 사용하기 편한 것 하나만을 골라 사용하면 된다. 래쇼날 로즈가 편하면 그것을 쓰면 되고, 개발 방법론이 UP가 편하다면 UP를 선택하여 사용하면 된다. 꼭 옮겨 올 필요가 있을까 하는 고민은 자바가 처음 등장했을 때 C++ 개발자들의 고민과 같은 맥락이다.

필자는 비주얼 스튜디오 2005가 있더라도 다른 도구 하나 정도는 필요하다고 생각한다. 하지만 그 도구가 꼭 래쇼날 로즈나 볼랜드 투게더 같이 UP 개발 방법에 필요한 모든 도구들을 다 제공하는 무거운 것일 필요는 없다. 몇 장의 종이와 연필, 지웠다 다시 쓰기 위한 지우개면 충분하다.

좋은 변화는 계속되야 한다
얼마 전 간단한 ATL 프로젝트를 수행하기 위해 비주얼 스튜디오 6.0을 설치하고 사용했는데, 5년간 VS.NET을 사용한 필자에게는 고역 같은 일이었다. 우선 인텔리센스 기술의 초기 시점이라 코드를 작성하기가 너무 불편했다(디버거 또한 불편했다). 세상 모든 것은 진화하기 마련이고, 개발 도구 또한 세상 어떤 개체들보다 빨리 진화한다.

비주얼 스튜디오 2005를 접해본 주위의 개발자들이나 학생들은 한숨부터 쉬고 시작한다. 완전히 새로 배워야 되는 것이 아니냐는 것이다. 가끔 필자도 너무 빨리 변화하는 IT를 업으로 삼은 것을 후회할 때도 있다. 『비주얼 스튜디오 2005 베타 2에서 변화한 8532가지』라는 문서를 받을 때면 다 그만두고 머리 깎고 산으로 들어가고 싶어지는 것이다. 하지만 등대가 보이는데 가까운 암초에 배를 댈 수는 없는 법. 그 등대가 구원의 길을 제공한다면 그 등대의 이름이 자바이건, 닷넷이건, 다른 기술이건 상관없다. 기술은 날이 갈수록 변화하고 개발은 갈수록 재미있어지고 있다. 부디, 이런 좋은 변화가 계속 되기를 바란다.@

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

 

김상훈 (동명정보대학 정보기술원 연구원)

2005/09/21

 

 

 

 

 

원문 :http://www.zdnet.co.kr/builder/dev/dotnet/0,39031607,39139648,00.htm