수안이의 컴퓨터 연구실

김상훈 (동명정보대학교 정보기술원 연구원)   2004/10/25 
    

연재순서
1회. 이래서 안되는거군!
2회. PM 김씨의 좌충우돌기
3회. 더이상 꼼수는 없다
4회. MSF/CD에 대해 고민해야 하는 이유 <끝>

김씨는 대학기관에서 근무하며 강의를 한다. 어느 날 김씨는 닷넷 기반의 프로그램을 작성하는 업체와 산학협력 프로젝트로 연계해 수행하는 프로젝트의 PM을 맡기로 결정됐다. 원래 일 욕심이 많은 사람이라 누군가 일을 시키면 ‘안 한다, 못 하겠다’라는 말을 하지 못하는 사람이며, 이번에도 평소에 하던 업무도 적지 않은데 프로젝트의 PM까지 맡기로 했다. 김씨는 하루에 8시간으로 예정되어 있는 강의를 진행하면서, 프로젝트 진행 상황을 점검하고 관리와 개발까지 하기로 했다. 특히 김씨가 근무하는 기관이 산학협력으로 프로젝트를 진행하는 건 처음이었고, 프로젝트의 진행은 한 마디로 ‘좌충우돌’이었다. 이번 연재에서는 김씨가 프로젝트 경험을 통해 성공적인 ‘프로젝트를 이끌 수 있는 방법’에 대해서 알아본다.

계약 내용을 명확하게 알아야 한다
진행되는 프로젝트는 시작부터가 복잡했다. 프로젝트의 책임자가 두 번이나 바뀌고, 우여곡절 끝에 김씨가 프로젝트를 책임지게 됐고 사공이 많은 탓에 배는 산으로 갔다. 프로젝트는 애초에 윈도우 플랫폼에서 동작하는 CMS로 계획됐다. 김씨는 다이렉트X 9.0 SDK를 이용하고 XML을 사용해 컨텐츠를 검색하는 식의 동작을 하는 소프트웨어를 계획했다. 하지만 프로젝트를 시작하기 전 CMS 프로젝트는 나중에 시간 나면(?) 하는 프로젝트로 변경되고, 당장 진행해야 되는 프로젝트는 처음 계획했던 프로젝트와는 전혀 상관없는 닷넷 기반의 웹 응용 프로그램으로 변경됐다. 김씨가 처음 들어본 서울의 모 업체와 산학협력 프로젝트로 진행하기로 됐고, 김씨는 협정의 내용을 정확하게 알지 못했다. 협정서에는 단순히 ‘시제품의 개발을 김씨가 근무하는 기관에서 책임진다’는 내용만을 포함하고 있었다.

김씨는 나중에 협정서를 다시 읽어봤지만, 협정서에는 틀림없이 ‘시제품의 개발’이라고 명시돼 있었다. 김씨는 협정서를 작성한 팀과의 회의를 통해 시제품이라는 것의 범위를 명확하게 할 필요가 있다고 이야기했고, 협정서를 작성한 팀에서는 그 ‘시제품’이라는 것은 마일스톤 버전 소프트웨어를 의미한다고 이야기했다. 김씨는 시제품이라는 것이 프로토 타입도 아닌 마일스톤 소프트웨어라는 것이 조금 의아하기는 했지만, 개발팀과 의논해 시스템이 닷넷 플랫폼에서 동작할 때 고려될 수 있는 위험요소가 제거된 마일스톤 버전의 소프트웨어를 개발하기로 하고 일정을 작성했다. 김씨는 마일스톤 버전을 정하고, 3단계까지의 마일스톤(사용자 단위의 보안이 적용되는 여러 컴포넌트 기반 소프트웨어의 작성에 있어 프로젝트 위험 요소가 제거된 버전) 버전을 2개월 동안 진행하는 것으로 일정을 작성했다. 김씨는 엔터프라이즈 디자인 패턴들을 적용하고, Front Controller를 사용하지는 않지만 차후에 완전한 프레임워크 기반으로의 발전을 위해 MVC 패턴을 적용하도록 하고, 데이터베이스와의 접속에 있어 동시 접속자 기준의 커넥션 풀링에서의 안전을 지켜낼 수 있는 마일스톤 버전 소프트웨어의 개발을 진행했다.

프로젝트는 그럭저럭 순조롭게 진행됐고, 김씨는 꽤 만족할 만한 사용자 인증 프레임워크를 개발해 인증 프레임워크를 사용하는 라이브러리를 작성하는 형식으로 진행했다. 김씨는 실제로 동작하는 소프트웨어를 작성하는 프로젝트라기보다 연구 과제 프로젝트를 수행하듯이 프로젝트를 수행했고, 계획대로만 진행된다면 최초의 쓸만한 닷넷 기반 프레임워크가 개발될 것 같아 흡족해 했다.

2차 마일스톤 버전을 끝내고 결과에 만족하고 있을 무렵, 협력 업체의 사장이 격려차 부산에 내려왔고, 당연히 뒤따르는 회식에서 여러 이야기를 나누던 도중 동석하신 부장이 다음과 같은 말을 꺼냈다.

“개발이 끝나면 QA는 어떻게 해주나요?”

QA? 품질 보증? 마일스톤 소프트웨어에도 품질 보증이 필요한가? 김씨는 가만히 생각해보니 마일스톤 소프트웨어에도 품질 보증이 필요할 것도 같았다. 김씨가 세운 계획대로 프로젝트가 순조로이 진행되어 예측할 수 있는 대부분의 위험요소가 제거됐다고 해도, 김씨 혼자서 위험요소가 제거됐다고 주장하는 것 밖에 안 될 수 있다는 생각이 들었다. 김씨는 위험요소가 제거됐고 소프트웨어가 제대로 조립됐다면 조건을 만족하는 하드웨어에서는 제대로 된 동작을 보증할 수 있다고 이야기했다.

“소프트웨어가 제대로 동작할 거라고는 말씀을 드릴 수 있죠. 그런데 소프트웨어를 조립하는 건 우리가 하는 일이 아니고 귀사에서 하는 일이라서…. 필드에서 동작하는 소프트웨어에 대한 QA는 제가 담당할 일이 아니지 않은가요?”

그러자 이번엔 부장님께서 의아해했다. 뭔가 다른 내용으로 이야기하고 있다는 듯한 표정이었다.

“조립이라뇨? 시제품을 개발하기로 했잖아요?”
“그렇죠. 협약서에는 시제품이라고 명시돼 있던데요.”
“시제품을 조립할 필요가 있나요?”
“마일스톤 소프트웨어를 그냥 사용할 수는 없잖아요”
“?”

김씨는 이쯤에서 뭔가 잘못됐다고 느꼈다. 이상한데? 협정서의 내용이 잘못됐나? 아니면 협정을 체결한 팀과 업체간의 의사소통에 무슨 문제가 있었나? 김씨는 거기에서 이야기를 마무리짓고 다음 날 대외협력팀과 회의를 가졌다. 회의 결과 마일스톤 버전 소프트웨어 개발 이야기는 우리끼리 이야기였고, 업체에서는 완전히 동작하는 소프트웨어를 개발해 준다는 의미로 받아들였다고 결론을 내렸다. 기간이 꽤 지나서 알게 된 사실이었기 때문에 김씨는 일정을 급하게 재조정할 수밖에 없었다. 일정을 재조정하고, 우선 보기 좋으라고 붙이던 디자인을 필드에서 동작했을 때 손색이 없는 디자인으로 고쳐나가기 시작했다. 처음에 계획했던 일정은 완전히 틀어졌다.

일주일쯤 후 업체에서 받은 메일에는 5장 짜리 요구사항 분석서가 첨부돼 있었고, 요구사항 분석서는 특정한 개발 방법론이나 모델링 규칙에 따라 작성된 요구사항의 정의가 아닌 시스템이 필드에서 동작하기 위한 각 클라이언트의 요구사항을 항목별로 맵핑한 엑셀 문서가 전부였다.

김씨가 프로젝트를 진행하며 계획했던 야심찬 꿈은 온데 간데 없어졌다. 김씨는 며칠 남지 않은 일정을 조정하여 항목 하나하나를 구현하는 데 힘을 기울였다. 다행히 설계된 프레임워크와 라이브러리를 조합하면 되는 일이어서 일정이 많이 지연되지는 않았고, 프로젝트는 그럭저럭 굴러갔다.

프로젝트를 처음 관리해 보는 김씨는 큰 교훈을 얻었다. 근무하는 회사가 CMM 레벨을 보유하고 있고, PMO 조직이 구성돼 있어서 프로젝트를 수행하기 전 요구사항들을 파악해서 투입되는 경우가 아니라면 감히 PM이라는 직함을 달아서는 안 되는 것이고, 혹시라도 그런 식으로 프로젝트를 관리하게 된다면 다른 사람의 말을 듣고 적당히 짐작해서는 안 되는 일이다. 프로젝트의 PM이라면 프로젝트에 관계된 모든 사항들과 일정들을 꼼꼼하게 정리하고 체크하는 것이 관건이고, 그러자면 세심한 주의가 필요하며 웬만하면 몇 가지 일을 겹쳐가면서 프로젝트를 관리하겠다는 생각은 버려야 한다.

그리고 또 한 가지. 김씨가 좋아하는 외화 시리즈 ‘X-파일’에 나오는 말인데, 프로젝트를 진행하며 명심해야 할 두 마디 격언. 진실은 저 너머에 있고(Truth is out there), 프로젝트를 순조롭게 진행하고 싶으면 아무도 믿어서는 안 된다(Trust no one). 프로젝트의 진행은 개발자/회사/PM간의 대화로 진행되는 것이 아니고, 작성되는 문서로 진행된다. 오버한다 싶을 정도로 명확히 대화하고 문서로 꼼꼼이 작성하고 보관하는 것이 성공적인 프로젝트를 진행하는 길이다.

협업하는 개발자와 업체간 용어를 통일하라
아주 당연한 이야기인 것 같지만 용어가 통일되지 않으면 프로젝트가 순조롭게 진행되지 않는다. PM 김씨는 프로젝트를 진행하면서 시스템이 그렇게 큰 규모가 아니기 때문에 특별히 용어를 정리할 필요가 없다고 생각했다. 인증 프레임워크의 개발은 김씨 혼자서 진행했고, 여러 가지 추상화 기법을 동원해 공통화하고 캡슐화했기 때문에 프레임워크를 기반으로 하는 라이브러리를 개발할 때 특별한 용어에 대한 정리가 필요 없을 거라고 생각했다. 하지만 라이브러리를 작성하고 프로토타이핑을 할 때, 김씨는 용어를 정리하지 않은 것이 아주 중대한 실수였음을 깨달았다.

교수 관련 라이브러리를 작성하는 개발자 윤군에게는 “한 학기 동안 진행되는 강의”가 Course였고, 학생 관련 라이브러리를 작성하는 개발자 길군에게는 “한 학기 동안 진행되는 강의”가 Lecture였다(갑자기 윤군과 길군이 왜 나왔는지 궁금한 사람은 지난 호를 찾아보기 바란다). 데이터베이스 모델링은 김씨가 했고, 대학과 교육기관에서 강의 하는 것이 주 업무인 김씨는 한 학기 강의는 Course, 한 강의중의 각각의 수업은 Lecture라는 이름의 테이블을 만들고 1:N 관계의 테이블들로 모델링했다. 테스트에 필요한 데이터는 삽입하지 않은 상태였고, 따라서 윤군의 라이브러리에서 강의 리스트를 보여주는 프로시저는 Course 테이블에서 데이터를 select하고, 길군의 라이브러리에서 강의 리스트를 보여주는 프로시저는 Lecture 테이블에서 데이터를 select했다. 각 라이브러리를 따로 떼놓고 보면 강의 계획서를 작성하고 수정하는 로직을 포함하는 윤군의 라이브러리는 제대로 동작하고 각 강의에 대한 계획을 보기만 하면 되는 길군의 라이브러리 또한 제대로 동작했다.

테스트 데이터가 삽입되어 있지 않기 때문에 보여지는 데이터가 정확한 데이터인지 아닌지를 판단할 수도 없었다. 두 라이브러리를 조립하고 테스트 데이터를 삽입한 후 테스트 관련 라이브러리를 조립했을 때, 김씨는 페이지에 표시되는 데이터가 이상하다는 것을 느꼈다. 출석부도 제대로 동작하지 않았고, 조립하는 라이브러리의 모든 데이터는 상황에 맞지 않은 데이터를 출력했다.

김씨는 밤을 새워가며 이유를 찾았고 결국은 길군의 라이브러리가 Course 테이블에 아닌 Lecture 테이블에서 데이터를 패치한다는 것을 찾아냈다. 길군의 라이브러리를 수정하는 데는 꼬박 3일이라는 시간이 걸렸고, 김씨의 일정표에서 학생 라이브러리에 대한 FS는 1일 밖에 주어지지 않았으므로, 전체적으로 2일이라는 일정이 미뤄지는 결과를 가져왔다.

길군이 프로그램을 잘못 작성했다고 볼 수 없는 것이(길군은 객관적으로도 꽤 뛰어난 닷넷 개발자다), 요구사항 분석은 협력 업체에서 맡기로 협정이 되어 있었고, 김씨는 아무런 요구사항을 전달 받지 못한 채 프로젝트에 착수 했다. 모든 다 요구사항을 3명의 개발자가 다 파악하기에는 시간이 턱 없이 부족했다. 김씨는 궁여지책으로 개발 기간에 요구사항 분석 기간을 포함시켰고, 라이브러리에 포함되는 프로시저들을 조각조각 내어 차후에 분석되는 요구사항을 쉽게 반영할 수 있도록 작성하자는 방침을 세웠다. 그리고 모든 객체들은 Abstract Factory 패턴을 사용하기로 하고, 관련 객체들은 모두 공통 타입으로 이끌어 내어 추상화해 차후에 다른 객체가 추가되더라도 리플렉션(reflection)을 사용해 라이브러리를 사용할 수 있도록 한다는 궁여지책을 내놓았다. 하지만 궁여지책은 궁여지책일 뿐, 요구사항이 완전히 정리되지 않은 상태에서 작성된 소프트웨어는 제대로 동작할 리 없다.

부랴부랴 김씨는 밤을 새워가며 Model Dictionary를 작성했다. 모든 용어를 다 정리하기에는 시간이 모자랐고, 결국은 혼동을 일으킬 여지가 있는 용어들만 정리했다. 김씨는 나흘간 두 시간 취침해 일을 했고, 이틀 동안 혼수상태에 빠져 프로젝트 일정은 지연될 수밖에 없었다.

앞에서 이야기했듯이 용어의 정리는 개발자 사이에서나 PM 등의 내부 인력에서만 필요한 것이 아니다. 애초에 협정서를 작성하던 단계에 있어서 협정서에 표시된 시제품이라는 용어의 정리만 명확했었다면 프로젝트는 좀 더 원활하게 진행될 수 있었을 것이다. 김씨가 처음 듣기에 시제품이라는 말은 웬지 ‘Prototype’이라는 말 같이 들렸고, 협력 업체에서는 ‘’판매 가능한 제품‘이라고 인식했다. 프로젝트에 관계하는 모든 사람들이 최근의 소프트웨어 공학 지식을 다 알고 있을 리는 만무하고 마일스톤이라는 말을 누군가가 꺼낸다면 모른다고 말하기도 그렇고, 뜻이 뭔지는 모르겠고 해서 적당히 자기 생각대로 해석해서 진행하게 되는 경우가 많다.

프로젝트를 진행하기 위해서는 용어의 정리가 반드시 필요하고, 그 용어는 혼자만 알아서 되는 것이 아니라 프로젝트에 참여하는 모든 사람과 모든 업체들의 공통된 동의가 필요하고, 모든 사람이 다 알 수 있는 공통적인 용어를 사용하는 것이 중요하다. 추상화라는 것이 프로시저나 클래스를 작성할 때만 적용할 수 있는 기법이 아니고, 프로젝트를 관리하고 진행하는데 있어서도 강력하게 적용될 수 있는 기법이다. 그리고 중요한 또 한 가지, 용어를 정리하고 모두가 용어에 동의했으면 반드시 문서로 남기고 확인을 받아야 한다. 김씨과 같은 기관에 근무하는 모 선배 개발자가 다음과 같은 감동적인 말을 한 적이 있다.

“강사는 강의로 말을 한다.”
그렇다면 “프로젝트는 문서로 말을 한다.”

개발자들의 수준을 파악하라
요구사항이 정확히 정리되지 않은 상태에서 프로젝트를 진행한 김씨는 궁여지책을 하나 내놓았다. Abstract Factory 패턴을 사용해 차후에 추가될 수 있는 기능들을 라이브러리로 분리하고, 리플렉션을 사용해 라이브러리를 동적으로 로드할 수 있는 기법을 사용하기로 했다. 개발자들도 모두 동의하고 파악된 요구사항들을 기준으로 프로그램을 작성했다. 프로젝트가 그렇게 진행되던 도중 급기야 라이브러리를 동적으로 로딩해야 되는 경우가 발생했다(사실 새 요구사항이 발생하면 라이브러리의 소스를 수정하고 다시 컴파일했지 새로 발견되는 요구사항 때문에 리플렉션을 사용하는 경우는 드물다).

크리스탈 리포트의 사용을 위해서 데이터셋을 생성하고, 형식화된 데이터셋을 사용해야 하는데, 형식화된 데이터셋을 사용하는 가장 좋은 방법은 데이터셋 객체를 직접 생성하는 것이 아니고 닷넷 프레임워크 SDK의 XSD.EXE 툴을 사용해서 형식화된 데이터셋을 생성해낸 후, 데이터 셋을 채우는 방법이다. 하지만 프레임워크에서 사용하는 데이터베이스 에이전트 라이브러리는 단순 래퍼일 뿐 형식화된 데이터셋을 생성할 수 있는 방법이 없었다. 여기서 김씨가 생각해 낸 방법이 Factory Method 패턴을 데이터베이스 에이전트에서 사용하여 XSD.EXE를 사용해서 생성한 클래스를 라이브러리로 만들고, 매개변수에 따라서 라이브러리를 동적으로 로딩하게 하자는 것이었다.

김씨는 개발자들에게 데이터베이스 에이전트의 수정을 맡기고 다른 일을 진행했다. 하루가 지난 후 수정을 맡은 개발자가 부시시한 얼굴로 내려와서는 질문을 했다.

“C# 디자인 패턴 책에는 안 나와서 자바 디자인 패턴을 봤는데요, 자바에서 클래스가 뭐하는 놈입니까?”
“객체의 타입을 스트링으로 받아서 객체의 인스턴스를 생성하는 놈인데 닷넷에서는 리플렉션을 사용하면 됩니다.”
“저… 리플렉션이 뭡니까?”

이럴 수가. 김씨는 당연히 개발자들이 리플렉션 정도는 사용할 수 있는 거라고 생각했다. 리플렉션을 모른다면 Activator도 당연히 모를 테고, Type 객체를 사용할 수가 없게 된다. 그러면 의도된 대로 프로그램을 작성할 수 없게 된다. 그렇다고 데이터베이스 에이전트의 수정을 김씨가 할 수도 없었다.

결국 김씨는 개발자들을 모아놓고 저녁 11시에 시작해 새벽 3시까지 닷넷 프레임워크에서 어셈블리를 조작할 수 있는 개체들의 집합인 리플렉션을 강의할 수밖에 없었다. 아예 처음부터 김씨가 작성하기로 했다거나 아니면 다른 방법을 택했다면 또는 유스 케이스를 아예 포기하는 것이 현명한 선택이었을 수도 있었다.

PMO 조직이 있는 큰 조직에서의 프로젝트라면 이러한 위험 요소는 모두 파악이 되어 교육을 실시하거나 다른 방법을 택하는 프로세스가 있을 테지만, 불행히도 3인의 개발자가 진행하는 4개월짜리 프로젝트에 PMO 조직이 있을 리가 없다. 프로젝트 관리 기법을 적용하는 데도 영세 프로젝트나 소규모 프로젝트에서는 한계가 있다. 김씨는 이점을 간과했었다. 소규모 프로젝트를 진행하고 있다면 프로젝트를 관리하는 사람의 입장에서는 개발자들의 수준을 파악하는 것이 무엇보다 중요한 일이 될 수 있다.

신기술, 어려운 기술만이 능사가 아니다
우여곡절 끝에 프로젝트는 종료됐고, 종료된 프로젝트의 소스코드와 설계 산출 문서들을 협력 업체에 전달하고 몇 시간 정도 구조를 설명한 후 김씨는 한 숨 돌리고 다른 방향으로 진행할 준비를 했다. 그런데 며칠 후 협력업체에서 받은 연락으로는 김씨가 작성한 소프트웨어가 못쓸 수준의 소프트웨어라는 것이었다.

자신의 기술에 꽤 자부심을 느끼고 있는 김씨로서는 도저히 용납 못할 일이었다. 이유인 즉 전달한 요구사항에서 10% 정도 밖에 구현되지 않은 소프트웨어로 납품하는 것은 불가능하다는 것이었다. 한 마디로 말하면 1000원 짜리 소프트웨어를 만들 줄로만 알았는데 100원짜리 소프트웨어를 만들었다는 것이었다. 김씨는 이해할 수가 없는 것이 김씨의 기관에서 특정 클라이언트에 납품할 수 있는 소프트웨어를 작성하기로 한 것도 아니었고, 프로토타입으로 작성한 웹 응용 프로그램에서 보여지는 동작이 전체 요구사항에서 10% 정도인 것이지, 프레임워크나 라이브러리의 동작으로 볼 때 80% 정도는 구현되어 있었기 때문이다. 김씨가 만든 소프트웨어 게시판은 다음과 같이 동작한다.

구현 퍼센트에 대한 판단이 김씨의 기준에서는 프레임워크나 라이브러리에서 구현돼 있는지의 여부였고, 협력업체의 판단은 요구한 문서에서의 O표로 표기됐는지의 여부였다. 김씨의 기준으로 본다면 70%가 맞고, 협력업체의 기준으로 본다면 10%가 꼭 틀리다고는 할 수 없는 일이었다.

흥분한 김씨는 협력업체의 개발자들과 가진 회의에서, 표에서 X로 표기된 부분을 페이지로 작성해서 협력업체에 기능 구현 여부를 10%에서 70%까지 올리는 데는 사흘 정도면 충분하다는 것을 보여주기 위해 시스템을 가져다 놓고 시연을 했다. X 다섯 개가 O으로 바뀌는 데는 불과 10분도 걸리지 않았고, 피차간에 궁색한 변명만 하게 되는 경우가 발생했다.

협력업체에서는 한 클라이언트와 계약을 해서 2개월 후 프로그램을 납품해야 하는데, 김씨가 만든 프로그램을 사용할 수 없겠다는 의사를 전했다. 이유는 프레임워크 방식으로 개발해 본 경험이 있는 사용자가 없고, 프레임워크를 이해하고 라이브러리를 파악하는 데 소요되는 시간보다 협력업체의 개발자들이 처음 짜는 것이 납품 기일을 맞추는 데 유리할 거라는 것이었다. 그 의견에는 다들 동의했다.

김씨는 아무 말도 하지 않았다. 소프트웨어 산업이 어떻게 되려고 저 모양이냐는 생각이 들긴 했지만, 구태여 그런 말로 분위기를 망치고 싶지는 않았다. 모든 요구사항이 반영된 프레임워크 기반의 소프트웨어라면 패키지 형태의 배포가 가능하고, 공들여 한번 작성해 놓으면 다음부터는 클라이언트의 요구사항에 따라 조립해서 판매만 하면 될 텐데 솔루션을 판매하는 업체가 SI식의 개발을 고집하는 것이 답답하기만 했다. 차라리 김씨도 프레임워크 기반 소프트웨어가 아닌 다이렉트 액세스 방식의 소프트웨어를 페이지 단위로 개발해서 500페이지 정도의 뷰를 갖는 소프트웨어를 개발했더라면 개발자들이 이해하기도 쉬웠을 테고 협정대로 납품되어 동작하는 소프트웨어를 만들 수 있었을 거라는 생각도 했다. 하지만 김씨는 그런 방식으로 소프트웨어를 개발할 생각은 추호도 없다. 혹시 SI 일을 하게 된다면 모를 일이지만.

새로운 기술이나 신기술 또는 어려운 기술만을 사용해서 프로그램을 작성하는 것이 반드시 능사는 아니라는 결론을 내릴 수도 있을 것 같지만 김씨는 그렇게는 생각하지 않는다. 문제는 계약의 문제였다. 잘 작성된 문서는 잘 개발된 소프트웨어만큼이나 중요하다는 것을 명심하라.

김씨는 협력업체에 소프트웨어를 넘기면서 소스코드와 다이어그램, ER-D 등 몇 장의 문서만을 넘겨줬을 뿐 제대로 된 조립 매뉴얼이나 라이브러리 문서 등은 작성하지도 않았고 넘겨주지도 않았다. 김씨가 라이브러리를 작성한 것은 10%가 아님을 증명하기 위한 문서 작성이 전부였고, 프로젝트가 종료된 지금도 김씨는 문서를 완전히 작성하지 않았다.

김씨의 궁색한 변명에 따르면 협력업체의 개발자와 이야기할 때 구조를 설명했고, 협력업체의 개발자는 충분히 이해하겠노라고 이야기했다는 것이다. 개발에 참여한 개발자 중의 한명이 협력업체에 직원으로 채용됐으므로 라이브러리의 내용은 다 파악하고 있는데 굳이 개발 방법이나 라이브러리 문서, 매뉴얼 등은 작성할 필요가 없었다고 판단했기 때문이라고 한다. 하지만 협력업체의 개발자는 구조와 라이브러리의 조립법을 제대로 이해하지 못한 것 같았고, 협력업체에 직원으로 고용된 개발자는 다른 업무에 투입됐으므로 소프트웨어를 제대로 이해하고 사용할 수 있는 사용자는 드물었다. 개발자들 대부분이 이번에 비주얼 베이직 또는 ASP 개발자 출신이어서 객체지향 프로그래밍이나 CBD를 제대로 알지 못하는 상황에서 정리된 문서의 부재가 가져오는 개발의 어려움은 엄청난 것이었다. 개발자들의 수준은 둘째라고 하더라도 제대로 된 문서를 작성하고 소프트웨어와 함께 전달됐더라면, 좀 더 나은 프로젝트의 진행을 볼 수 있었을 것이다.

프로젝트는 적당한 시점에서 포기하는 것?
프로젝트를 진행하면서 가장 중요한 요소는 성질대로 되지 않는다는 것을 몸으로 이해해야 한다는 것이다. 김씨는 부산 출신 남자답게 성격이 괄괄하고 다혈질이다. 요구사항을 파악해 주기로 한 날짜가 지나도 협력업체에서 아무 말도 없자(당연히 협력업체에 연락해서 좋게 풀어야 할 상황임에도 불구하고) 프로젝트를 임의대로 진행했다. 그것이 프로젝트가 원활하게 진행되지 않은 가장 큰 이유인데, 프로젝트가 소프트웨어를 작성하기 위한 것이라고 해도 결국은 사람 대 사람의 일이다. 일이 뜻대로 진행되지 않아서 기분이 상하거나 성질을 돋운다고 해도 성질을 참고 원활하게 일을 풀어나가는 것이 성공적인 프로젝트를 진행하는 가장 지름길이 되지 않을까 싶다.

그리고 프로젝트를 진행할 때는 no man이 되어야 하는 것은 무엇이든 중요하다. 기관 대 기관 또는 업체 대 업체 사이에서의 Yes는 구두 계약이 된다. 무심코 얻어먹은 점심 한 끼로 ‘Yes’라고 대답했다가는 개발자 자신뿐만 아니라 개발자가 몸담은 기관까지 타격이 전해지는 수가 있다. 조심에 조심, 조심을 거듭해야 한다.

어떤 영화감독은 “영화는 완성되는 것이 아니다. 감독이 적당한 시점에서 영화를 포기할 뿐이다”라고 말했는데, 프로젝트의 진행도 이와 일맥상통하는 점이 있다. 세상에 완벽한 프로그램이라는 것은 존재하지 않는다. 개발자와 프로그램 매니저가 지정된 기간과 지정된 비용에 맞게 적당한 시점에서 작성을 포기하는 것이 바로 프로젝트다. @