It's Myself

대략적으로 만들어야 하는 제품을 기준으로 각 구성요소들을 단순 무식하게 계산하여 약 400 M/M 사이즈 프로젝트가 있다고 하자.

1인당 1달 유지비를 1천만원(유지비에는 월급, 행정 처리, 프로젝트 진행 잡비 등등)으로 잡는다고 했을 때, 이 프로젝트는 최소한 40억은 있어야 한다. 그 외에는 별개로 이익 5% 까지 계산하면, 42억 정도 잡힌다.

24개월 기준으로 보면 최소 16명이 있어야 되며, 16명이 24개월 정도 업무를 수행해야 한다. 그런데, 이 M/M에는 함정이 있다. 바로 인력의 개개별의 능력이나 속도 그 외 업무에 대한 이해도 따위는 전혀 없다.

다행히 1~2명은 사업에 대한 이해나, 관련 기술의 이해가 있다고 치다.

문제는 주변인이다. 많게 쳐서 4명이 잘 안다고 해도, 16 명 중 4명 빼면 12명이 있는데, 이 사람들은 이 사업에 대한 이해에서 부터 기술이 전무하다고 하면 아주 진행이 웃기게 된다.

자.. 이것이 한국형 계산법이다.

그런데 한국에서는 저 40억이라고 하면 무척 많은 금액이라고 한다. 그러니 자연스럽게 400 M/M이 걸리는 작업을 마구 후려쳐서 200 M/M으로 계산한다. 즉 40억을 20억으로 줄인다. 상도덕 적으로 40억을 20억으로 줄였으니 전체적인 업무를 줄여야 하는데, 또 그렇지가 않다. 즉 400 M/M짜리를 금액만 200M/M 으로 줄이게 된다.

이와 같은 형태가 되면 어떻게 될까? 그나마 16명으로 어떻게든 유지해보려는 프로젝트는 8명이 해야 되고, 일은 2배가 된다. 인력이 마구 투입된다고 자연스럽게 흘러가지도 않겠지만, 그렇다고 무턱대고 줄이면, 그 나머지 업무를 결국 개개인에게 쏠리게 된다.

이게 야근의 원리다.

결국 전체적인 프로젝트의 퀄리티는 저하될 수 밖에 없고, 개발자는 자연스럽게 허덕이고 야근하고 개발을 하게 된다.

그런데 저 사이즈의 프로젝트가 되게 되면 자연스럽게 개발과는 상관 없는 사업관리 조직이 생긴다. 줄어든 금액에서 또 쪼개 쪼개서 사업관리를 하게 된다. 금액의 절약은 다시 개발자에게 얹어지게 되고, 개발자는 더 많은 일을 할 수 밖에 없는 구조가 계속 진행되게 된다.

이렇게 만들어 놓고 많은 금액을 투입했으니, 넉넉한 기간을 주었으니 잘 만들어 달라고 한다.

?

이 작업에서 기술적으로 풀어야 되는 최고의 숙제는 COM 개체를 CPP 코드를 이용하여 붙이는 작업이다.
그렇다고 COM 관련 API를 직접 붙여 만들기는 귀찮기도 하고, 기술적으로 능력이 딸리기 때문에, 힘들고, 대신 Visual Studio의 기능을 십분활용하는 방법으로 진행한다.

이 중 MFC 기반으로 만드는 응용 프로그램인 경우, 전체 프로그램의 사이즈는 커지지만,
그래도 편하게 작성할 수 있는 장점은 확실히 이용가능하다고 본다.
여기서 작업 결과물은 ActiveX로 나와야 겠지만, 먼저 COM 연결과 같은 테스트에 가까운 작업 부분에 대해서는 MFC 기반 응용 프로그램으로 만들어 직접 테스트와 디버깅을 하여 결과물을 만든 후 그 내용을 ActiveX로 붙이는 것이 좋을 것 같다.
이를 위해 하는 작업은 COM의 TypeLib를 사용하여 ProxyClass를 자동으로 생성하는 방법을 적용한다.
TypeLib에서 ProxyClass를 만드는 방법은 Visual Studio 버전에 따라 틀리지만, 여기서는 모든 작업을 Visual Studio 2005로 할 것이며, 이 방법을 중심으로 펼칠 예정이다.

Proxy Class 만들기.

• 프로젝트에서 컨텍스트 메뉴를 띄우고 추가를 선택한다.
• 추가 아래에서 클래스를 선택한다.
• 클래스 추가라는 제목의 마법사가 뜨면, 그 중 MFC 항목을 선택한 후 템플릿 중 TypeLib의 MFC 클래스를 선택한다.
• 사용 가능한 형식 라이브러리에서 원하는 COM을 선택한다. 여기서는 ClearQuest OleServer를 선택한다.
• 그러면 이 COM에 딸린 각종 인터페이스들이 나열되는데, 그 중 필요한 인터페이스를 선택한다. 여기서는 CQ Workflow의 작업에 필요한 IOAdEntityDef, IOAdEntityDefs, IOAdSession 세가지가 필요하다. 그래서 그 클래스를 추가한다.
• 그러면 프로젝트의 헤더 파일 목록에 위의 세가지에 대한 프락시 클래스 정의 내용이 담긴 헤더 파일(*.h) 파일이 추가된다.

일단 위의 헤더 파일이 만들어졌으면 1차적으로 완성된 것이다.

Proxy Class 활용하기.

COM에서 인터페이스를 이용하여 사용하려면, COM에 대한 인스턴스가 필요하다. 지금 위의 작업까지 된 부분은 운영체제 내 등록되어 있는 COM 자체의 설정 값들을 읽어온 것이 전부이다. 이 설정 값만으로는 실제 메모리 존재하는 것이 아니다. 그렇다고 단순하게 Proxy Class를 new 해서 만드는 것은 사실 아무 의미 없다. Proxy Class를 new해서 만드는 것 만큼이나, COM 자체에 대한 인스턴스를 만드는 것이 같이 병행 되어야 하고, 인스턴스화 된 COM 개체를 new해서 만드는 Proxy Class와 연결하면 되는 것이다. 이제 이 COM을 메모리에 올리고 new 해서 만드는 Proxy Class와 연결하는 작업을 수행할 것이다.

ClearQuest OleServer를 사용하려면, 최초 Session 이 필요하다. 즉 이 Session에 대한 인스턴스가 있다면, 이 인스턴스를 통해서 각종 하위 내용들을 끄집어 낼 수 있다. 즉 시작점 같은 의미를 하는 부분을 먼저 인스턴스화 하는 것이 핵심인 것이다.  그래서 다음과 같은 순서로 실행하면 된다.

먼저 Proxy Class를 new 해준다. 여기서는 시작 인스턴스로 사용할 IOAdSession 이라는 것을 먼저 시도하게 된다.
COAdSession *pSession = new COAdSession();

이제 만들어진 ProxyClass에 COM 인스턴스를 싣는다. 이 Proxy Class들은 모두 COleDispatchDriver를 상속받는데, 그 상위 클래스에 정의된 CreateDispatch 함수를 실행하면 된다. 이 때 Program ID 혹은 CLSID를 알아야 하는데, 이 중 제일 접근하기 쉬운 Program ID로 정의해서 넣는다.
pSession->CreateDispatch(_T(“CLEARQUEST.SESSION”));

이제 인터페이스에 정의된 매소드를 실행해 본다.
pSession->UserLogon(_T(“admin”), _T(“”),_T(“udb1”), 1L, _T(“7.0.0”));

정리를 하자면, 일단 TypeLib를 통해 ProxyClass를 만든다. 이 작업은 직접 만들 수 있지만, 귀찮으니, MFC에서 제공하는 자동화 도구를 사용해서 만든다. 그리고 난뒤, Proxy Class의 인스턴스를 만들고, 그 안에서 다시 COM 자체의 인터페이스를 생성한 뒤, 실제로 사용한다는 것이다.