수안이의 컴퓨터 연구실김상훈 (필자) ( 마이크로소프트웨어 ) 2004/10/11
연재순서
1회. 이래서 안되는거군!
2회. PM 김씨의 좌충우돌기
3회. 더이상 꼼수는 없다
4회. MSF/CD에 대해 고민해야 하는 이유 <끝>
프로젝트를 처음 시작한다는 것은 개발자의 입장으로서 참 가슴 설레는 일이 아닐 수 없다. 프로젝트를 시작할 때는 누구나가 다 원대한 목표를 가지고 시작하게 된다. 하지만 프로젝트 종료 날짜가 다가오면 애초의 원대한 목표는 간 곳이 없고 누가 이 코드들을 보고 욕이나 하지 않을까 걱정하게 되는 경우가 허다하다. 물론 가장 큰 이유는 개발 플랫폼을 잘 이해하지 못했다거나 기술을 제대로 사용할 수 있을 만큼 숙달되지 않아서 그런 경우겠지만, 그런 기술적인 요소 외에 다른 엉뚱한 돌발 상황이 발생해 프로젝트의 발목을 잡는 경우가 허다하다. 이번 연재에서는 프로젝트를 진행할 때 고려해야 하는 부분에 대해 생각해 보기로 하겠다.
김씨가 근무하는 대학의 기관에서는 닷넷 기반에서 동작하는 중간 규모 정도의 프로그램을 작성하는 프로젝트를 서울의 한 업체와 산학협력 프로젝트로 연계해 수행하기로 결정했다. 그리고 닷넷 기술을 4년 동안 강의했고, 닷넷 기술로 여러 컨설팅을 수행한 경험이 있는 김씨에게 프로젝트가 맡겨졌다. 김씨는 최근에 수행되는 여러 닷넷 프로젝트가 ‘닷넷답게’ 수행되지 않는다며 한탄하던 사람 중 한 사람이어서 자신이 수행하게 된 이번 프로젝트를 정말 ‘닷넷 프로젝트의 모범이 될 수 있는’ 레퍼런스급 소프트웨어로 만들어보자는 결심을 하고 프로젝트를 수행하게 된다(DVD로 치면 ‘반지의 제왕’급의 소프트웨어를 만들어보자는 결심).
그동안 강의를 위해, 또는 다른 목적을 위해 공부하고 실험했던 기술들을 제대로 한번 써먹을 수 있는 기회가 왔음을 반가워하며 프로젝트에 써먹을 수 있는 기술들을 정리하고 개발에 착수할 준비를 했다. 김씨는 전체 소프트웨어의 보안을 관리하는 모듈(보안 모듈)의 구성대로 보안 등급을 관리하는 모듈, 보안 등급에 따라 구성되는 게시판 모듈, 시험 모듈, 강의실 모듈 등의 설계를 머리 속에 그리며 실제 개발을 담당할 개발자들과 토의를 시작으로 개발에 착수했다.
윤군의 개발 이야기 - 프로젝트는 결국 노가다인가?
대학에서 컴퓨터공학을 전공하고 소규모 프로젝트에 여러 번 참여한 경력이 있는 윤군은 프로젝트 매니저(PM) 김씨의 아이디어를 주의 깊게 들었다. 프리젠테이션 자료 준비도 하고, 빔 프로젝트까지 빌려서 브리핑해 주는 김씨의 열정에도 감동을 받았다. 여러 프로젝트에 참여를 했었어도 ‘몇 페이지’를 작성하느냐가 관건이었던 개발 업무에서 벗어나 제대로 된 프레임워크 기반에서의 개발을 해볼 수 있겠다는 기대에 마음이 부풀었다. 대학 4학년때 꽤 잘 가르친다는 교육기관에서 1년간 닷넷을 배우기도 한 윤군은 공부한 기술들을 제대로 써 먹을 수 있는 프로젝트에 참여할 수 있겠다는 희망에 부풀었다. 윤군이 들은 PM 김씨의 계획은 이러했다.
[1] 전체 시스템을 파악한 결과 시스템에는 여섯 단계의 사용자 인증이 필요하다.
[2] 시스템에는 각 사용자별로 다르게 동작하는 게시판이 여러 개 필요하다.
[3] 설문조사/블로그/메시징 등의 시스템이 필요하다.
[4] 전체 시스템에 통용되는 범용 강의실 시스템이 필요하다.
[5] 학사정보를 관리할 수 있는 시스템이 필요하다.
[6] 시험을 온라인으로 실시할 수 있는 시스템이 필요하다.
PM 김씨는 전체 시스템을 완전한 컴포넌트 기반 시스템으로 구성하겠다고 했고, 프로젝트의 진행도 MSF/CD를 제대로 사용해 보겠다고 했다. 실질적인 개발에 착수하기 전, PM 김씨는 윤군에게 <그림 1>과 같은 다이어그램을 보여주었다.
TIIT 프레임워크는 PM 김씨가 개발하겠다고 했다. TIIT 프레임워크 Arda(반지의 제왕을 좋아하는 PM 김씨가 톨킨의 소설 『실마릴리온』을 읽고 감동받아서 붙인 이름이라고 한다)에는 Data Access Block이 포함되어 있고(마이크로소프트의 DAL을 쓰는 것이 어떨까 생각했지만 김씨는 끝까지 고집을 부렸다. 이 시스템은 MS-SQL 서버에서만 동작할 게 아니고 오라클이나 액세스에서도 동작 가능하도록 구성되어야 하기 때문에 마이크로소프트가 제공하는 DAL로는 적당하지 않다는 것이 김씨의 고집이었다. 결국은 김씨의 고집에 따르기로 했다), 전체 웹 응용 프로그램의 설정을 담당하는(Web.Config 파일을 관리하는) 컴포넌트들을 작성할 것이라고 했다.
“이 컴포넌트가 언제 나옵니까?”
“일주일 후!”
윤군은 일주일을 놀기로 했다(?). 윤군이 일주일을 놀아야 하는 이유는 전체 시스템의 어떤 컴포넌트나 페이지라도 보안 인증이 없이는 작성될 수 없기 때문이었다. 일주일 동안 MVC 같은 디자인 패턴들을 공부하면서 시간을 보낸 윤군은, 일주일 후에 김씨가 작성한 보안 인증 컴포넌트의 소스코드와 클래스 다이어그램을 받아보았다. 컴포넌트 이름이 TIIT.Arda.Trainman인데(영화 ‘매트릭스’를 좋아하는 김씨가 3편에 등장하는 현실세계에서 매트릭스로의 인증을 담당하는 프로그램의 이름에서 따온 이름이란다), 컴포넌트는 Visitor 패턴을 응용해 작성되었고, 여섯 가지 타입의 클래스를 정의해서 인스턴스의 타입을 검사해 각각 다른 인증을 보여주는 방식이다. 보여준 클래스 다이어그램은 다음과 같다.
그리고 김씨는 작성된 사용자 인증 컴포넌트를 사용해 다중 수준의 보안 등급을 유지하며 동작하는 범용 게시판 컴포넌트의 코드를 보여주었다. 게시판 컴포넌트(이 컴포넌트의 이름은 Hihava인데, 김씨의 여자친구가 ‘미래소년 코난’을 좋아해서 붙인 이름이라고 한다)의 모든 객체들은 IVisitor 인터페이스의 서브 타입인데, IAcceptor 타입의 사용자들이 게시판 객체를 매개변수로 Accept() 메쏘드를 호출하면 각 객체의 Visit 메쏘드가 Acceptor의 타입에 따라 다른 동작을 하여 각 사용자별 기능 제한을 주는 다중 수준의 보안을 유지할 수 있는 소형 프레임워크 구성이라고 한다. 김씨는 이 프레임워크의 이름을 TIIT 프레임워크라고 이름을 붙였다.
윤군은 전에 일하던 개발 회사에서 게시판을 관리하고자 할 때 일반 사용자용 게시판과 관리자용 게시판을 따로 만들었던 기억이 났다. 그 게시판은 일반 사용자/회원/관리자의 세 등급으로 나누어져 있었는데 일반 사용자는 글을 읽을 수만 있고 회원은 글을 쓸 수 있고 관리자는 모든 권한을 다 가지는 형식의 동작을 구성했다. 일반 사용자가 액세스할 수 있는 페이지, 사용자가 로그인하면 사용자의 등급에 따라 다른 페이지로 리다이렉트(redirect)하는 형식으로 여러 페이지를 구성했는데, 김씨의 말대로라면 한 페이지에서 객체의 상호 작용에 따라 모든 동작이 한 페이지에서 구현되는 형태의 프로젝트를 구성할 수 있을 것 같았다.
평소에 디자인 패턴에 관심이 많아 여러 책들을 읽으며 디자인 패턴을 공부한 윤군은 1시간 정도의 설명을 듣고 프레임워크를 이해할 수 있었다. 일주일간 Iterator 패턴과 Visitor 패턴에 대해 조금 더 상세히 공부했던 터라 윤군은 프레임워크의 동작 방식을 완벽하게 이해할 수 있었고, 작성된 프레임워크가 코딩 양과 페이지의 수를 많이 줄여줄 수 있을 것이라고 믿게 되었다.
학사 관리 쪽의 모듈 개발을 맡은 윤군은 TIIT 프레임워크의 보안 인증 시스템을 기반으로 학사 관리 모듈을 작성하기 시작했다. 현재 페이지에 액세스하고 있는 모든 사용자의 등급을 알아내기 위하여 다음과 같은 코드를 삽입하였다.
학사 관리 쪽의 FAQ 페이지를 작성하던 윤군은 FAQ 중 글을 보여주는 페이지를 작성하는데 다음과 같은 몇 줄의 코드만으로 전체 작업이 이루어진다는 것에 감동받았다.
Q&A를 만드는 작업 역시 비슷한 동작으로 가능했다. 다음 코드는 Q&A의 리스트를 보여주는 페이지이다.
고민과 짜증에 한숨 내쉬는 윤군
윤군은 TIIT 프레임워크가 꽤 잘 만들어진 프레임워크라고 생각하며 개발 작업을 계속했다. 그러나 페이지의 수가 늘어나자 윤군은 슬슬 짜증이 나기 시작했다. 모든 페이지마다 저 코드를 꼭 써야만 하나, 페이지에서 저런 코드를 쓰지 않고 단순히 HttpContext만 사용해서 현재 사용자와 사용하는 객체에 대한 동작을 이루게 할 수는 없을까 등등 고민이 늘어만 갔다.
윤군은 PM 김씨와 그 점에 대해서 이야기를 했다. “TIIT 프레임워크가 하는 일이 조금 더 많으면 페이지에서 저런 귀찮은 코드를 일일이 쓰지 않아도 하부 프레임워크가 다 알아서 해줄 수 있는 프레임워크를 구성하는 것이 바람직하지 않겠느냐”고 건의했다. 하지만 PM 김씨는 한마디로 안 된다고 일축했다. 윤군은 다음과 같은 코드로 동작하는 프레임워크를 만들 수 있을 것이라고 이야기했다.
윤군은 닷넷 프레임워크의 HttpModule 객체를 사용하면 충분히 구현할 수 있다고 이야기하며, 프로젝트가 끝나고 배포 단계에 이르렀을 때 좀 더 손쉬운 배포와 쉬운 커스터마이징을 위해서는 복잡하지만 페이지에서의 코드를 줄여주는 이와 같은 방식이 올바를 거라고 이야기했다. 윤군은 자신의 생각이 당연이 바람직하다고 생각했다.
PM 김씨의 말은 이랬다. “현재 TIIT 프레임워크를 설계하고 코드를 작성하고 동작시키는 데만 일주일이 걸렸다. 이와 같은 코드로 동작 가능한 프레임워크를 작성하려면 한 달, 아니 제대로 만들려면 6개월 정도는 소요될 거다. 전체 프로젝트의 기간이 3개월 남짓인데, 프레임워크를 개발하는 데 그만한 시간이 소요되어서는 프로젝트를 기간 내에 끝낼 수가 없게 된다. 현재 프레임워크도 그걸 고려하지 않은 바는 아니지만, HttpModule을 사용해서 구성할 수 있는 Front Controller 프레임워크의 안정성이나 위험 요소가 제거된 상태가 아니기 때문에 기간 내에 끝내야 하는 프로젝트에서 그런 모험을 할 수 없다.”
윤군도 그 말에는 곧 동의했다. 프로젝트가 끝나면 혼자서라도 Front Controller 프레임워크를 작성해 보겠다고 다짐하면서 페이지들을 작성해나갔다. 개발하는 도중에 틈틈이 MVC 모델을 자세히 살펴보고 HttpModule 객체의 활용 가능성을 검토해나갔다. 하지만 작성하는 페이지가 30페이지가 넘어가자 윤군은 또 짜증이 나기 시작했다.
모든 페이지마다 사용자 인증 컴포넌트의 메쏘드를 호출해야 한다는 것이 마음에 들지 않았다. 다른 문제는 디자이너가 작성한 페이지에 프로그램을 붙여나가는 일이었다. 웹 디자이너가 닷넷 프레임워크를 잘 이해하고 있을 리는 만무하고, 웬만한 경력의 개발자도 제대로 이해하지 못하는 MVC2 모델을 고려해 디자인하고 있을 리가 없었다. 예를 들면 페이징이 필요한 모든 데이터 리스트는 DataGrid 컨트롤을 사용해 DataGrid 컨트롤의 페이징 기능을 사용하기로 결정했는데, 디자이너의 디자인은 그렇지 않기 때문이었다.
프로젝트는 결국 노가다야?
닷넷 환경 이전의 ASP였다면 이와 같은 디자인대로 작성하는 것이 별 문제가 되지 않겠지만, 닷넷 환경에서 IDataReader 타입의 Read() 메쏘드를 일일이 호출하며 쓴다는 것은 말도 안 되는 이야기다.
윤군은 Hihava 컴포넌트에서 몇줄의 코드로 전달받은 데이터 소스를 디자인과 같이 보이게 하기 위해서는 HTML과 CSS 기술이 훨씬 중요하다는 것을 깨닫게 된다. 디자인과 같이 페이지를 보이게 하는 것이 분명히 기술적으로 어려운 것은 아닌데 태그 하나 잘못 붙임으로 해서 전체 페이지가 뒤틀려 보이게 되고, 데이터 그리드 컨트롤의 각 행에 점선을 긋기 위해서는 두꺼운 CSS 사전을 뒤져서 스타일 시트에 클래스를 추가해야 함을 깨달았다.
학교나 집에서 연습삼아 작성하던 프로그램에는 디자인이 필요 없었지만, 실제 프로젝트에서는 디자인대로 프로그램을 작성하는 것이 아주 중요하다는 사실을 깨달았다. 그 작업은 기반 컴포넌트를 개발하는 작업보다 훨씬 손이 많이 가고 지겨운, 정말 ‘노가다’성 작업이었다. 윤군은 결국 Front Controller 프레임워크 개발의 꿈을 접으면서 새삼 깨달았다. ‘프로젝트는 결국 노가다일 수밖에 없구나.’
프로젝트를 진행하는데 단순 무식 노동 집약적 작업을 하지 않으려면? 프로젝트에 참여하는 모든 사람들이, 개발자고 디자이너고 PM이고 관계 없이 기반 플랫폼을 잘 이해해야 하고, 잘 만들어진 프레임워크가 필요하다는 것. 프레임워크 기반 작업의 가장 큰 단점은 프레임워크를 학습하는 시간이 많이 소요된다.
TIIT 프레임워크 같은 경우에는 디자인 패턴을 이해하지 못하면 제대로 사용할 수 없는데, 윤군의 주위에는 Visitor 패턴 하나라도 제대로 이해하고 있는 사람이 드물다. 윤군은 PM 김씨가 항상 이야기하는 “대한민국의 닷넷 프로젝트가 제대로 수행되지 못하는 이유”를 이해할 수 있을 것 같았다.
길군의 개발 이야기 - 개발자와 디자이너
PM 김씨, 개발자 윤군과 같이 프로젝트에 참여하고 있는 개발자 길군 또한 프로젝트의 진행 중에 슬슬 짜증이 솟구치기 시작했다. 강의와 교수 쪽의 모듈 개발을 맡은 길군은 설계대로 컴포넌트 개발을 어느 정도 진행한 후 개발 일정에 맞추기 위해 페이지에서 컴포넌트를 사용해 페이지를 만들어내는 작업에 착수했을 때였다. 길군은 디자이너가 작성해놓은 페이지가 이쁘다고는 느끼면서도 개발자의 입장은 전혀 고려하지 않은 디자인이라고밖에 생각할 수 없었다.
항상 빌 게이츠를 ‘우리 회장님’이라고 부르며 마이크로소프트를 너무나 좋아하는, 회식할 때마다 웹 사이트에서 본 스티브 발머 동영상에서 발머가 뛰어다니면서 외치며 ‘디벨로퍼’를 건배 구호로 외치던 PM 김씨와 오래 생활한 탓인지? 길군도 회장님의 저서를 항상 들고 다니며 읽었다. 『생각의 속도』에서 읽은 다음 글귀가 길군을 감동하게 했다.
나의 주된 염려는 웹 페이지의 구성이 너무 복잡하고, 웹 페이지들끼리 서로 일관성이 없으며, 그래픽을 너무 화려하게 처리한 나머지 다운로드되는 속도가 느려서 실제로 필요한 정보에 접속하는데 시간이 너무 오래 걸린다는 것이었다.
“물론 우리 회사 웹 페이지의 전체적인 모양새는 나아졌으나, 우리가 의도한 기준에는 미치지 못한다고 생각합니다. 인터넷에 대해 MS가 지대한 관심을 가지고 있다는 것을 사람들에게 보여주려고 했던 의도를 제대로 반영하지 못하고 있습니다. 우리 회사의 전반적인 웹 사이트는 여전히 매우 취약합니다. 어지러운 색상의 그래픽이 쓸데없이 많이 들어가 있습니다. 마치 훌륭한 웹 페이지를 평가하는 척도가 필요한 정보를 얻는 기능에 있는 게 아니라 웹 페이지가 다운로드되는 동안 멀찍이 떨어져서 감상하는 데 있다고 생각하고 만든 것 같아요. 회사로서는 한 페이지에 가능한 한 많은 정보를 담으려고 노력하는 신문의 1면 편집자와 같은 생각을 소유한 사람이 필요합니다. 한 페이지를 보면 또 다음 페이지로 넘어가야 되도록 만들어 사용자들을 웹 페이지의 미로 속에서 헤매게 만들어서는 안 됩니다”
회장의 이러한 말들에 감동받은 길군은 현재 디자인에 컴포넌트의 루틴을 붙여서 처리하는 작업이 너무 한심하다고 생각되었다. 강의 모듈을 개발하는 과정에 강의 정보를 보여주고 수정하는 사용자 정의 컨트롤을 개발하며 길군은 현재 디자인이 프로젝트의 일정을 지연시키는 가장 큰 요소라는 극단적인 생각까지 하게 되었다. 얼마 전 컴포넌트를 설계하면서 Factory를 잘못 작성하는 바람에 Factory가 생성해 반환하는 객체와 반환받은 객체가 다른 곳을 참조하도록 하는 어이없는 실수를 저질러 하룻밤을 꼬박 새운 길군은 기껏 디자인에 컴포넌트 로직을 붙여나가는 작업이 훨씬 힘든 작업일 이유가 없다고 생각하고 고민하다가 결국은 성질을 못 참게 되는 지경까지 이르렀다.
늘어만 가는 길군의 고민과 근심
개발팀에서 나이가 제일 많은 길군은 성질대로라면 디자이너에게 당장 디자인 작업은 제쳐두고 닷넷 프레임워크에서 System.Web.UI 네임스페이스 부분이라도 공부하라고 이야기하고 싶었다. 그러나 디자이너는 내부 개발팀원이 아닌 협력 업체에서 파견된 외부 업체의 직원이었고, 유일한 여성 팀원이었으므로 모든 사람의 갖은 총애를 받는 인력이었기에 함부로 말할 수도 없었다. 길군은 시간이 지날수록 부아가 치밀기 시작했다.
디자이너 박양은 박양 나름대로 화가 나 있었다. 만리타향에 한 달씩 파견나와 있는 것도 서러운데, 파견지의 근무 환경이 원래 직장과는 너무 달랐다. 생전 처음 보는 이상한 포맷을 주면서 이대로 디자인하라고 해놓고는 그대로 디자인해 주면 또 닷넷 플랫폼의 특성을 제대로 살리지 못하는 디자인이라며 화를 낸다. 생전 처음 보는 양식을 들이밀며 이게 UI Specification이라며 그 많은 페이지들을 다 작성하라는 이상한 일을 시키지를 않나(개발자라는 사람들이 포토샵을 사용해서 그림에 쓰여진 글자 하나 고치지를 못하는 수준이다), 작업 좀 하려면 무슨 버튼을 만들어 달라, 어디에 무슨 글씨를 고쳐 달라, 어디에 무슨 내용이 들어가 있으니 고쳐 달라 등 만리타향에 귀양 온 듯한 서러운 기분이 드는 것이었다.
길군은 드림위버로 작업된 asp 파일을 넘겨받고는, 파일의 Indentation이 아예 안 되어 있어 일일이 탭으로 지정해야 하는 작업에 진저리가 났다. 한 두 페이지도 아니고 ASCX 파일을 만들어 메뉴를 재사용하는 코드도 전혀 들어가 있지 않은 페이지를 열어서 일일이 작성하다 보니 화가 났다. 특히</table> 태그를 하나 빠뜨림으로 해서 전체 페이지의 레이아웃이 무너져 빠진 태그를 찾아내는 데만 두어 시간 정도 허비하고 나서는 현재 작업에 깊은 회의를 느끼기 시작했다.
PM 김씨는 길군의 이런 속사정을 아는지 모르는지, 컴포넌트 수정은 우선 미루고 페이지부터 작성하라는 닥달만을 하고 있고, 페이지에 로직을 붙여나가는 작업은 기반 프레임워크가 아무리 코드를 줄여준다고 해도 성질나는 일이었다. 길군은 참고 또 참으며 일정을 지키기 위해 코드를 작성했다. PM 김씨가 대문짝만하게 인쇄해 벽에 붙여놓은 ‘Be the Miracle’이라는 개발 구호가 원망스럽게 느껴졌다.
결국 길군은 개발 일정을 지키지 못했고, 현재 건강 상태가 별로 좋지 못한 이유도 있지만 정말 ‘별 것 아닌 것 같은’ 디자인대로 UI를 수정하는 작업 때문에 일정을 지키지 못한 것 같아 화가 났다. 평소 일정을 못 지키는 것을 견디지 못하던 길군은 결국 사고를 저지르고야 말았다.
PM 김씨는 어느 날 아침 출근해서는 디자이너 박양이 출근하지 않았음에도 별로 신경쓰지 않았다. 사람이 살다보면 어쩌다가 아플 때도 있는 법이고, 김씨의 평소 신조인 ‘아프다고 전화할 수 있는 체력이 남아있으면 출근한다’는 신조에 따라 박양도 그렇겠거니 하고 신경쓰지 않았다. 그런데 해가 질 무렵이 되고 퇴근 시간이 다 되어서도 박양이 출근하지 않자 김씨는 의아심이 들기 시작했다. ‘이상하네 왜 출근을 안 할까?’ 여러 회사에서 근무해 본 김씨의 생각으로는 파견 업체에서 근무하면서 무단결근을 한다는 것은 회사간의 관계로 볼 때도 이해할 수가 없는 일이었다.
상처받은 박양, 길군의 깨달음
사건의 전말은 이러했다. 길군과 같이 근무하는 윤군과 김군의 말에 따르면, 전날 개발팀이 다 모여서 술을 마셨는데, 길군과 박양 사이에 약간의 다툼이 있었다는 것이다. 길군은 박양에게 개발자와 디자이너가 프로젝트를 진행하면서 지켜야 할 여러 가지에 대해서 이야기했고, 결론은 디자이너가 개발 플랫폼을 이해하지 않으면 프로젝트가 제대로 수행되지 못한다는 이야기였다.
박양은 자신의 전공은 개발이 아니고, 자기는 프로그래밍을 별로 배우고 싶은 생각도 없고, 웹 디자인이라는 게 쉬워 보여도 생각할 것이 아주 많다며, 작성한 디자인대로 프로그래밍하지 못하는 프로그래머가 무슨 대단한 능력을 가진 프로그래머냐고 팽팽히 맞서서 대들었다(길군이 나이가 훨씬 많으므로)고 한다. 심성은 곱지만 욱하는 성질을 가지고 있는 길군은 참지 못하고 몇 마디 언성을 높였는데, 몇 마디 말의 요지는 이러했다고 한다.
“프로젝트 수행의 주체는 무조건 개발자다. 디자이너의 임무는 개발자의 코드를 조금 더 예쁘게 보이도록 하는 데 지나지 않는다. 그러므로 시키면 시키는 대로 하라.”
박양은 마음에 큰 상처를 받았고, 반쯤 찬 맥주잔을 앞에 놓고 펑펑 울었다고 한다. 김군의 말에 따르면 아주 서럽게 울더란다. 그 후로 박양은 출근을 하지 않았고, 김씨의 일정에 따르면 이번 주 안에 UI 작업을 마무리하고 다음 주에 컴포넌트 정제 작업에 들어가려는 일정에 커다란 차질이 생길 수밖에 없었다. 미치고 펄쩍 뛸 일이 아닐 수 없어서, 김씨는 박양에게 전화를 해서 구스르고 달래고 협박하고 회유하고 갖은 수를 다 썼다.
하지만 박양은 말을 듣지 않았다. ‘말을 듣지 않는 게 당연하지. 전화로 말을 들을 사람 같았으면 애초부터 무단결근 같은 건 하지 않았을 테니까.’ 김씨는 이해할 수가 없었다. 아무리 기분 나쁜 일이 있다고 해도 파견 나온 회사에서 무단결근까지 하고 일 못하겠다는 파행을 저지르다니. 결국은 협력 회사의 사장까지 나서서 문제를 해결했다. 일주일쯤 지난 후, 디자이너는 다시 출근을 했고, PM 김씨는 모든 일정을 재조정해야 했다. 김씨는 이런 어이없는 일 때문에 일정이 늦춰지고 재조정되는 일이 발생한다는 것에 화가 나서 일정을 새로 잡는 데 시간이 꽤 걸렸고 전체적으로 보름이 넘게 일정이 지연되는 결과를 가져왔다.
개발자 길군은 자기 나름대로 ‘벙어리 냉가슴’을 앓고 있었다. 김씨가 자기를 조용하면서도 으슥한 데로 불러서 린치(?)라도 가하지 않을까 불안했다. 또한 김씨가 자기를 불러서 한마디쯤은 할만한 데 아무 말도 없는 것이 더 불안하고 미안했다. 일주일 후 재출근한 디자이너 얼굴 대하는 것도 영 머쓱했고, 웬만하면 박양에게 일을 부탁하지 않으려고 노력했다. 꼭 필요한 디자인이라도 길군은 서툰 포토샵을 실행해서 아이콘을 만들고 붙이고 했다. 개발 속도가 떨어지는 건 당연하다. 하지만 자기가 저지른 사고로 인해 일이 이렇게 됐으니 불평 한 마디 못하고 전보다 더한 밤샘 작업을 계속했다.
길군은 느낀 바가 컸다. 프로젝트를 제대로 진행하려면 성질부터 죽여야 되는구나. 말 한 마디 잘못했다가 일정이 보름씩이나 지연되는 결과가 발생하다니. 길군은 한때의 분함을 참으면 하루가 편안해진다는 옛 성현의 말이 한 마디도 틀림이 없음을 깨달았다.
하지만 PM 김씨한테도 섭섭한 점이 없지 않았다. 애초에 PM이라는 사람이 나서서 이런 경계를 좀 그어줬어야 하는 것 아닌가. 다른 바쁜 일 있다고 하루에 한두 번쯤 개발실에 얼굴 비추는 PM 김씨한테 관리 잘못이 더 큰 게 아닌가 생각했다. ‘PM 김씨도 아마 그렇게 생각하기 때문에 길군에게 아무 말 못했던 것이 틀림없다.’
뛰어난 기술만이 프로젝트를 성공적으로 이끄는 요소가 아니었다. 프로젝트를 성공적으로 이끌려면 기술적인 요소 이외에도 관리해야 할 문제가 아주 많다는 것. 특히 팀원들 간에 불화가 발생하면 개발 일정이 한 달씩 지연되는 건 일도 아니란 것을 느꼈다. 그 일이 있은 후, 길군은 김씨와 술을 마시면서 이런 저런 이야기를 했다.
“개발하면서 주의해야 되는 일에 대한 내용을 적은 책은 없습니까? 기술 서적이야 넘쳐나지만 실제 프로젝트를 수행해 보니까 기술만 뛰어나다고 무조건 프로젝트가 성공하는 건 아니네요. 물론 기술 없이는 프로젝트를 시작할 수도 없겠지만…”
김씨는 책을 한권 읽어보라고 했다. 책 제목이 『Programatic Programmer』라는 책인데, “담배 빼앗아가는 동료를 비난하지 말라”는 내용까지 있다고 한다. 책을 한번 읽어 보고는 싶은데 인터넷 서점에서 검색해 봐도 없었다. 또 물어보니 원서란다. “개발 1등급을 받는 업체가 한국에 하나도 없는 이유가 거기에 있구나.” 길씨는 원서라도 사서 읽어 봐야겠다고 생각한다.
“프로젝트라는 게 정말 산 너머 산이구나”
PM 김씨는 또 다른 고민이 생겼다. 김씨가 생각하는 현재 솔루션은 MileStone 버전이라고 생각하는데 협력 업체에서는 완전한 판매 가능한 솔루션이라고 생각하는 모양이다. ‘3개월 만에 판매 가능한 솔루션을 만들라고 했으면 시험적으로 프레임워크를 작성해 기반 개발을 시도하지 않았을 텐데.’ 김씨는 “기간을 단축해서라도 개발을 해야 하는지 아니면 접어야 하는지 고민에 빠졌다.
PM 김씨는 책임 연구원으로 근무하는 선배 개발자이자 스승으로부터 공부 똑바로 안 하고 서툰 일만 한다는 꾸중까지 들었다. 다음 주에 이런 일들로 여럿이 모여서 회의를 진행하기로 했다. 김씨는 ‘그동안 손놓았던 소프트웨어 공학 책을 주의 깊게 읽어보고 회의에 참석할 필요가 있다’고 생각했다. PM을 처음 해보는 김씨는 딜레마에 빠진다. “정말 개발만 잘 한다고 되는 일이 아니구나.” 일이 마음먹은 대로 안 풀리니까 자신의 실력에 대해서도 의심이 가기 시작한다. “프로젝트라는 게 정말 산 너머 산이구나.” @
- [닷넷 프로젝트를 정복하라] ③ 더이상「꼼수」는... (0)2007/06/09
- [닷넷 프로젝트를 정복하라] ② PM 김씨의 좌충우돌기 (0)2007/06/09
- [닷넷 프로젝트를 정복하라] ① 이래서 안되는거군! (0)2007/06/09
- 소스 코드 공유를 위한 패턴 (0)2007/05/17
- 소프트웨어 개발과 디자인 패턴 (0)2007/05/17
Leave your greetings.