CS 프로그램의 일부를 ActiveX로 포팅하기-어떻게 만들까?

The most common miracles of software engineering are the transitions 

from analysis to design and design to code.    Richard Due

0. 어떻게 만들까? 소프트웨어 설계 단계

당연한 얘기지만 설계 없이 프로그램을 만들 수는 없는 노릇이다. 제아무리 바빠도 바늘 허리에 실 매어 쓸 수 없다는 우리네 속담 처럼 말이다.

더우기 이번 프로젝트에서 처럼 일정이 촉박한 경우에는 설계에 투자하는 시간이 그 어느 때보다 빛을 발하게 된다. 

전산학을 전공한 이라면 소프트웨어 공학 수업을 통해 소프트웨어 설계가 차지하는 비중이 전체 소프트웨어 라이프 사이클에서 30~40% 

정도라는 것을 배웠을 것이다. 이번 설계에 들어간 시간도 여기서 크게 벗어나지 않았다. 주어진 전체 일정의 약 30% 정도를 할애한 것이다.

후배들에게 "설계에 투자하는 시간을 절대 아까워하지 말라"는 당부를 하고 싶다. 설계를 위해 투자한 시간은 분명히 보상 받게 될 것이다.

설계를 하는 동안 우리가 할 일을 자료 구조, 시스템 구조, 인터페이스 그리고 컴포넌트 이 네 가지의 관점에서 살펴봐야 한다.

어떤 형태, 구조의 자료를 취급하는지 입력은 어떤 형식으로 받아서 중간과정의 가공을 어떻게 하며 마지막으로 출력은 어떻게 할 것인가를 

면밀하게 따져봐야 한다. 이러한 데이터들을 프로그램 또는 프로세스 간 전달하는 방법을 기술하는 것이 인터페이스가 될 것이다.

이러한 인터페이스 과정에서 다양한 플랫폼들이 등장하는 것이 보통이다. 클라이언트인 웹브라우저와 서비스를 제공하는 웹서버 그리고 

데이터를 제공하는 미들웨어 등이 그것인데 ActiveX는 클라이언트인 웹브라우저와 기반 플랫폼인 윈도 운영체제 위에서 동작한다. 

그러면서 미들웨어인 데이터베이스와도 통신해야 하고 웹서버 프로그램과도 인터페이스해야 한다. 

잘 만들어진 컴포넌트는 시간과 노력을 아껴줄 뿐더러 품질을 보증한다. 설계에서 중요한 것 한 가지는 새로운 것을 발명하는 것 보다 

이미 있는 것을 잘 활용하는 방법을 고민하는 것이다.

 

1. 이미 만들어진 것들과 앞으로 만들어야 하는 것들 파악하기

이번 프로젝트는 이미 잘 쓰고 있는 프로그램을 ActiveX로 전환하는 것이다. 그러므로 기존 모듈 또는 라이브러리를 변경없이 그대로 쓰는 것이

설계의 큰 원칙이다. 하지만 ActiveX라는 겉옷을 입혀야 하기 때문에 어쩔 수 없이 바껴야 하는 부분이 있을텐데 이에 적응하면서 변화를 

최소화하는 것이 이 설계의 목표가 될 것이다.

분석 결과 기존 CS 프로그램은 MFC의 SDI를 기반으로 제작되었고 개발팀에서 자체적으로 만든 프레임웍을 적용하였다. 

그리고 각 화면 단위로 DLL을 분리하였으며 화면들에서 공통적으로 사용하는 도구들 역시 공통 DLL 형태로 분리 개발되어 있다.

사용자는 웹페이지에 기술된 자바스크립트들을 통해서 ActiveX와 인터페이스 할 것이다. 그리고 ActiveX는 윈도의 자원들과 인터페이스하는데

기존 화면을 구현하고 있는 DLL들을 메모리로 불러들이고 그 모듈에 정의된 함수들을 호출하는 것이 바로 그것이다.

그러므로 ActiveX는 기존 CS 프로그램의 SDI를 처리하는 역할을 대신하면 된다. 

2. 얼마 만큼의 시간(대체로 충분한 시간은 아니다)이 주어졌나?

좋은 설계란 무엇일까? 적어도 현실 세계에서는 제한된 자원을 가지고 약속한 시간 안에 주어진 요건들을 만족하는 버그 없는 프로그램을 만들어 

낼 수 있는 설계일 것이다. 다시 한 번 강조하자면 "약속한 시간 안에" 만들 수 있어야 한다는 점이 중요하다.

시간을 절약하는 제일 좋은 방법은 새로 만들기 보다는 기존에 만들어져 있는 것을 최대한 재사용하는 것이다. 아울러 개발 환경, 개발 패턴 등도

그대로 따라가는 것이 시간을 절약하는 방법이 된다. 물론 이는 새로 만들어야 하는 것과 기존 것을 재활용하는 것의 비중이 후자에 몰려 있을 때 

얘기이다. 약속한 시간을 지키기 위해서 중요한 것과 덜 중요한 것이 무엇인지 잘 알고 일을 진행하도록 하자. 개발 도구와 개발 환경이 맘에 들지

않더라도 빨리 적응하는 것이 좋다. 개발 프레임웍이 역시 맘에 들지 않더라도 어느 정도는 존중해줘야 한다. 

적어도 기존 모듈을 최대한 활용하기로 했다면 말이다. 

3. 이 설계대로 만들면 문제가 없을까? 품질 보증

좋은 설계란 무엇일까? 앞서 얼마 만큼의 시간이 주어졌나에서 스스로 묻고 답한 것과 같이 제한된 자원을 가지고 약속한 시간 안에 주어진 

요건들을 만족하는 버그 없는 프로그램을 만들어 낼 수 있는 설계가 좋은 설계라고 했다. 이번에는 "주어진 요건들을 만족하는 버그 없는 

프로그램"에 집중해보도록 하자.

당연한 얘기지만 설계 과정에서 이미 테스트 및 검증에 대한 것도 고려되어야 한다. 또한 어느 정도는 나중에 있을 수 있는 변경을 수용할 수

있는 구조가 되어야 한다. 또한 사용자들의 예기치 못한 사용 방법에도 프로그램이 죽는 등의 문제가 없어야 한다. 

4. 설계한 결과물을 개발자, 기획자 그리고 실 사용자들과 리뷰하기

이전에 CS 프로그램에서 잘 사용하던 프로그램을 ActiveX로 전환하면서 무엇이 바뀌는지 그리고 사용자들이 쓰기에 불편한 점은 없는지 

마지막으로 웹서비스를 개발하는 개발자들이 알아야 하는 것 등 이번 설계에는 각자가 기대하는 바가 있다. 잘 만들어진 좋은 설계라면 

모인 사람들이 대체로 만족하고 동의할 수 있어야 할 것이다.

기획자는 ActiveX로의 전환을 통해 이전보다 향상된 사용환경과 나아진 성능 등을 어필하고자 하는 기대가 있을 것이고 사용자들은 이전에 

익숙했던 방법대로 사용할 수 있기를 기대할 것이다. 그리고 개발자들은 인터페이스를 구현하는 과정에서 쉽고 효율적인 코딩을 기대하는 

것이 당연하다. 

좋은 설계란 이러한 기대에 부응하는 것이다. 쉽진 않겠지만...