프로젝트 명 : 부가서비스 관리 시스템 개선

에필로그

2013년 길고 길었던 겨울의 추위가 누그러지고 있는 2월 어느 날 유병헌 부장에게 한 통의 전화가 걸려 왔다. 고객사 PMO에게 제안서 한 부 받아와서 전달해 달라는 것이었다. 당시 진행 중인 프로젝트는 최종 검수가 완료되었고, 프로젝트 참여한 인력들이 그대로 경영관리 시스템 개발 프로젝트에 투입되는 것으로 예정되어 있었다. 주관사는 타 SI 업체였고 프로젝트 총괄 역시 SI 업체에서 맡기로 되어 있었다. 그렇게 다음 프로젝트의 SI 업체 PM과 첫 만남을 가졌고 첫 인상은 그라 좋은 편은 아니었다. 회의 내내 프로젝트에서 나올 만한 이슈사항에 대해서 논의하고 있는 중에 약간은 거만한 듯한, 그리고 개발업무의 이슈를 단지 개발팀에 스스로 해결하라고 미루는 듯한 느낌을 받았다.

그런 차에 전화 한 통을 받고 PMO에게 제안서를 받으러 갔다. 제안서는 타 SI 업체에서 작성한 것이었는데 프로젝트를 하기로 한 SI 업체에서 펑크를 낸 모양이었다. 듣기로는 개발비용 문제로 인해 프로젝트가 틀어지게 될 상황이었고 몇 차례 유병헌 부장을 통해 해당 프로젝트 수행 할 수 있는지에 대해 문의를 한 상태로 전해 들었다. 몇몇 수석들이 검토하였고 프로젝트 명에서 보듯이 너무 다른 업무를 한 프로젝트 모아 놓고 진행하는 것이여서 관리 문제 등으로 거절한 상태였다.

PMO와 만나 제안서를 받아 들었는데 설명은 단순했다. 그대로 문서 포맷만 바꿔서 제출해도 된다는 것이었다. '응? 뭐지? 제안서 받고 검토만 하는 거 아니었나?' 하는 생각을 하고 있는데 PMO에서는 당연히 그리고 반드시 넥스트리소프트에서 이번 프로젝트를 진행해야 한다고 제안서를 제출해 달라는 것이었다. 이미 유병헌 부장과 이야기 되었다고 이야기 하는 것이었다. 나중에 확인해 보니 이야기 된 것은 없었다. 그렇게 회의를 마치고 나오면서 단도직입적으로 질문을 했다. 금액이 얼마 정도 되느냐고... 너무 직설적이었다는 생각이 드는 순간 예산은 말할 수 없고 대략 70 ~ 75 M/M 정도 생각하라고 했다. 원래 투입 예정이였던 프로젝트에 비해 두 배 이상 M/M가 투입되는 것이었고 갑자기 욕심이 생기게 되어 제안서를 유병헌 부장에게 건네며 이 프로젝트 하자고 의사를 건네게 되었다.

1. 제안요청서(RFP)와 숨은 그림 찾기

다음은 제안요청서(RFP)의 일부 이며, 필자가 언급하고자 하는 내용 만을 발췌하였다.

  제안요청서(RFP)

  ... 중략

  2.2 상세 비즈니스 요구사항

  2.2.1 실효관리 시스템 구축

      계약관리 시스템 구축

- 계약 리스트 조회 및 미 입금건 조회 등 지원
- 지점 내 영업관리자 및 총무가 해당 지점 계약현황 및 리스트 조회 기능 지원
- 이탈 계약 리스트 제공
  ... 중략

  2.2.3 부가서비스 관리 시스템 개선

  .... 중략

      서비스/멤버십 통계 DB 구성

부가서비스 가입, 접수, 처리에 대한 종합 통계화면 구성
     카드발급 실적 통계화면 구성 (상품/일자 등)

  ... 중략

  3.2 상세 기술 요구사항

  3.2.1 OO보험 표준 기술 환경 준수

      실효관리 시스템: OO보험 표준 PC (Window XP, Window7 64Bit 등) 환경을 지원

- 계약 관리 시스템은 X 인터넷 기반의 인터넷 아키텍로 구축
- 단, '계약 리스트 조회' 화면은 모바일 환경(안드로이드, iOS 등)에서도 활용
  ... 중략

     부가서비스 관리 시스템: 본사 업무조직 외에 판매조직을 활용하도록 일부 서비스 의 경우 PC환경

     뿐만 아니라 모바일 환경(안드로이드, iOS 등)에서도 활용될 수 있도록 구성

  ...

보다 많은 내용을 작성할 수는 없지만 제안요청서를 통해서 제안서 작업을 할 때는 제안 요청서에 담긴 업무 정의 및 의미와 전사 시스템의 아키텍처 및 기반 기술 등을 확인해야 하고 현행시스템의 운영 환경도 충분히 이해하고 작성해야 한다. 프로젝트를 해 보겠다는 결심을 하면서도 타 SI 업체의 제안서를 카피하기 시작했고 이는 프로젝트 수행하기도 전에 범한 나의 첫 번째 과오가 되었다.

프로젝트는 그렇게 시작되었고 투입 후 업무 설명 및 현행 시스템 분석을 진행하여 그렇게 2주 가량 지난 뒤에 현업, 운영 팀, PMO 등 이해관계자 전체가 모여 프로젝트 착수회의를 진행하게 되었고, PM인 나는 프로젝트 로드맵 및 일정 계획에 대해 설명했다. 그렇게 착수회의가 끝날 무렵, 계약파트 운영 담당자가 배치 개발자가 누구인지 알려달라는 요청이 있었는데, 솔직히 조금 당황했다. 제안요청서와 타 SI 업체에서 작성한 제안서에는 어디에도 배치 관련된 문구가 없었으며 AS-IS 시스템이 배치를 통해서 데이터 발생하고 있다는 것은 전혀 생각지도 못했다. 설상가상으로 부가서비스파트 운영담당자는 통계 정보는 정보계 쪽에 어떻게 쌓을 것이며 데이터마트 구성은 누가 하는지도 요청해 왔는데 이것도 전혀 파악하지 못했다. 급히 유병헌 부장에게 연락해서 해당 인력을 구한 후 프로젝트를 진행하기 했지만, 지금 돌이켜 보면 당시까지만 해도 프로젝트를 너무 가볍게 생각하고 있었던 것이었다. 특히, 신규 시스템 위주로 개발하다 보니 기존 시스템의 기능 개선 프로젝트에서 충분히 파악해야 할 것들에 대해 많이 놓치게 되었다. 이것은 초기 제안서 작성 부터 프로젝트를 너무 쉽게 생각한 결과이다.

이제 시간이 흘러 당시를 회고해 보면 프로젝트 수행을 위해서는 준비가 소홀했다는 점은 깊이 성찰할 필요있다. 다만, 회사 차원에서 제안 작업에 대한 중요성에 대한 인식과 함께 개선방안에 대한 노력도 뒤따라 와야 한다. 대형 SI 업체와 같이 제안서 작업 팀 구성이 된다면 좋겠지만, 어렵더라도 충분한 시간과 사전 검토가 이루어질 수 있도록 지원해야 한다. 지금까지는 제안요청서 받아 제안서를 제출할 때까지 길어야 일주일, 그렇지 않으면 이틀 또는 삼일 내에 제안서 제출하는 경우도 많이 있었다. 그리고, 한 가지 문제를 더 지적하자면, 간혹 제안서 작성할 사람이 없어 제안 프로젝트와 관계 없는 직원이 제안서를 대신 작성하는 경우가 종종 있었는데 이 부분에 대한 개선도 필요하다.

2. 프로젝트 R&R, 그리고 신뢰

SW 프로젝트에서 R&R(Role and Responsibility)에 대한 고민은 프로젝트에 참여하는 모든 사람들에게 있을 것이다. 또한 모든 프로젝트가 원하는 인력을 적재적소에 배치하여 진행하는 경우는 찾아보기 힘들다. 이번 프로젝트를 진행하면서 R&R에 대한 중요성과 진행 중 실수에 대해 고찰해 보고자 한다.

첫 번째가 인력구성과 R&R 이다. 특히 이번 프로젝트의 경우 초기 인력 구성이 어려웠던 점이 여러 업무가 하나의 프로젝트로 구성되었다. PMS에 메인 프로젝트 하위로 4개 서브 프로젝트를 등록하여 관리하여, 각 업무 별 PL이 있어야 수월하게 프로젝트를 진행할 수 있었다. 당시 PL 역할을 할만한 인력이 회사에 있거나 프로젝트에서 철수 예정인 사원이 없어 프로젝트 인력을 구성하는데 어려움이 있었고, 차선으로 선택한 방법이 투입 전에 업무 범위가 적은 것과 비슷한 업무라고 판단되는 부분을 묶어서 한 명의 PL을 두고 관리하는 방향으로 결정하였다. 지금 돌이켜 보면, 작은 규모의 프로젝트라도 동시에 2개의 프로젝트의 PM 또는 PL을 맡는 다는 것이 매우 어렵고 프로젝트의 위기가 될 수 있다는 것에 대해 너무 안일한 생각하였다. 프로젝트 종료 시점 다가오면서 무사히 프로젝트를 마칠 수 있을 것이란 확신이 들었지만, 이는 프로젝트의 PL 역할을 맡은 박석재 수석과 이재욱 수석이 프로젝트를 책임 있게 이끌고 갈 수 있는 능력을 지니고 있어 가능한 것이다. 프로젝트 진행 중에 수 많은 난관을 잘 헤쳐나가 주어 더욱 감사하게 생각한다.

두 번째로 경험하지 못한 것에 대한 두려움이 신뢰라는 이름으로 둔갑되어 담당하는 개발 인력에게 모든 것을 맡기는 누를 범하였다. 지금까지 개발하면서 많은 경험을 통해 개발에 대해서는 어떤 환경에서도 잘 할 수 있는 자신감을 키워왔다고 생각했다. 프로젝트 착수회의를 통해 급하게 배치 인력을 투입하게 되었고 배치 영역은 해보지 않았다는 이유로 투입된 개발 인력이 알아서 하겠지라며 회피하였다. 투입된 인력이 과거 프로젝트를 같이 진행한 경험이 있기에 잘 할 것이라는 막연한 생각만으로 신뢰하게 되었고, 그 결과가 좋지 못했을 때에 실망이 너무 커 당시에는 배치 개발자에 대해 가진 불만을 주변 사람들에게 이야기 하곤 하였다. 그렇지만, 프로젝트가 끝나는 시점에 그 상황에 대해 회고를 하면 사실 PM으로서 개발자에 대한 관리가 제대로 이루어 지지 않은 것이 가장 큰 문제인 것이다. 가끔은 한 가지 가정을 해 보는데 만약 배치를 처음부터 내가 하고 배치 개발로 투입된 개발자를 웹 개발을 시켰으면 프로젝트가 좀 더 좋은 방향으로 진행되지 않았을까? 지금 돌이켜 보면 프로젝트에서 발생하는 모든 상황은 PM의 몫이고 그에 대한 책임이 있다는 것을 뒤 늦게 깨닫게 된 것이다.

세 번째로 한 사람에게 많은 역할이 주어졌을 때에 PM은 이를 과감히 조절해 주여야 한다. 과욕을 부리는 개발자의 경우에는 하고 싶은 것과 할 수 있는 것과의 경계가 사이에서 절묘하게 줄타기를 잘 해야만 프로젝트에서 맡은 역할을 충실히 수행하여 만족스러운 결과를 얻을 수 있다. 앞서 이야기 한 것처럼 프로젝트 인력 구성이 어려워 협력직에게 PL 역할을 주었다. 프로젝트 초기에 PL 역할을 잘 수행하였으나 개발이 진행되면서 업무 협의 외 본인의 개발 분량까지 몰리면서 몇몇 태스크에 대해 계속 놓치기 시작하였다. 흔한 말로 맨붕이 온 것이였다. 그때까지 본인은 개발과 PL을 병행할 수 있다고 자신했고 그에 대한 의사를 존중해 주었다. 하지만 시간이 지날수록 개발과 PL의 역할 모두 재대로 되고 있는 것이 없었고 결국 개발은 다른 개발자에게 위임하였다. 지금 당시 상황을 생각해 보면 사실 PL 역할을 제대로 수행하지 못했다고 평가하는 것은 아니다. 다만, 프로젝트에서 개발을 잘하면서 PM 또는 PL 역할을 수행하기란 매우 어려운 일이며 이는 상황에 맞는 집중과 선택이 필요하다는 것이다. 프로젝트에서 발생하는 모든 상황이 개발자의 욕심 만으로 되는 것이 아니며 각자 태스크에 대한 관리를 제대로 이루어져야 한다.

또한, 최근 들어 운영 팀의 추천으로 기존 운영 또는 프로젝트에서 개발을 해온 협력직과 일하는 경우가 많이 늘었다. 보험 업무에 대해 오랫동안 개발을 해 왔기에 그들이 가지고 있는 도메인의 가치는 매우 크며 이를 잘 활용할 수 있는 역할을 부여한다면 프로젝트에 긍정적인 시너지가 일 것이다. 이번 프로젝트에 참여한 협력직 개발자 중 한 명은 프로젝트 상황이 급할 때에는 자신의 개발 외에도 테스트 및 모니터링 등 본인 역할 이상으로 도움을 주었다. 한때 다른 프로젝트들 중 회사 직원들로만 구성된 프로젝트가 부러울 때가 있었으며, 나도 모르게 협력직 개발자에 대한 편견을 가지고 있었다. 사실 회사 직원 못지 않게 좋은 협력직 개발자도 많다. 그들을 프로젝트에서 어떻게 R&R을 부여하여 프로젝트에서 그들이 가진 역량을 제대로 발휘할 수 있게 만들지에 대해 고민을 하고 있다.

3. 험난한 이관 절차

프로젝트를 마무리하는 과정 중에 가장 중요한 태스크 중 하나가 이행과 관련된 작업이고, 이는 아무리 잘 만든 SW라 하더라도 적시에 출시되지 못한다면 그 의미는 많이 퇴색된다. 우리가 개발한 SW를 적시에 출시하기 위해서는 이관이라는 절차 존재하는데 이는 기업마다 이관 절차에 대한 시스템화가 잘 이루어지고 있는 추세이다. 다만, 프로젝트 중심으로 생각해 보면 운영 이관과는 성격이 달라 이관 절차를 간소화하거나 어느 정도 안정화를 거친 후 오픈을 하는 전략을 세우는 것이 통상적이다.

고객사 역시 안정적인 운영 유지보수를 위해 SR시스템을 도입하고 이를 통해 운영 이관 절차를 밟고 있다. 이러한 이관 절차는 운영 뿐만 아니라 고객사에서 진행하는 모든 프로젝트가 동일하게 적용 받고 있으며, 이로 인해 프로젝트 팀은 이관을 위해 드는 노력과 시간이 일반적으로 생각하는 이관 절차에 비해 몇 배 이상 소요되며 때론 고통스럽기까지 하다. 물론 이관팀 입장에서 운영 및 프로젝트를 포함한 이관을 담당하고 있어 더 많은 고통이 따른다고 반론할 수 있지만 지금은 프로젝트 관점의 기술하였다. 그러나 이러한 이관 절차의 분리가 일부 이관팀의 업무 경감에도 도움이 될 수 있다는 믿음은 있다.

또한, 이관 절차 중에 상당히 고통 받고 있는 부분 중 하나가 SR 및 이관결재 이다. 이관을 위해서는 현업이 작성한 SR이 필요하고 작성된 SR을 프로젝트 팀에서 사용하기 위해서는 험난한 SR 결재라인을 밟아야 한다. 동일한 사람이 두 번 결재하는 것을 제외하더라도 최소 6 ~ 7명 정도 결재라인을 거쳐야 프로젝트 현장관리자(PM, 도급법 기준으로 현장관리자라 칭함)에게 SR이 도착하며 이를 개발자에게 할당하면 소스 이관을 위한 형상관리 시스템에 소스를 병합할 수 있게 된다. 이후 가동계 반영을 위해 해당 SR에 대해 이관 상신하게 되고 동일한 이관 결재를 다시 밟아야 이관 팀에 전달이 되어 최종 가동계에 이관하게 된다. 물론 정기이관일 경우에는 앞서 이야기 한 것 보다는 결재라인이 짧아 상대적으로 이관이 용이하다.

이관 절차가 까다롭다는 것은 운영 중인 시스템을 매우 안정적으로 운영할 수 있다는 장점이 있다. 다만 논의하고자 하는 부분은 이관 절차 중 필요 이상의 결재자가 있어 긴급하게 처리하는 경우에 프로젝트 팀에서 한 사람 한 사람 전화를 해야 하고, 다시 결재가 되었는지 확인해야 한다. 바로 결재한 경우는 대단히 운이 좋은 경우이다. 운영 팀의 결재자가 회의 중이거나 본인 업무처리로 결재가 지연이 되면 프로젝트 팀은 굉장히 당황스럽기만 하다. 특히 소스를 급하게 넘길 때 결재자 중 한 두 명이 퇴근을 했다면 더욱 난감한 상황에 빠진다. 물어 물어 대결자를 찾아 결재를 하곤 하지만 그 과정에서 프로젝트 팀이 받는 스트레스는 상상 이상이 된다. 개인적인 의견은 프로젝트 팀에서 이관할 때는 프로젝트 맞는 이관 절차를 수립하는 것이 필요해 보이며, 이런 이관 절차를 만들기 어렵다면 SR 및 이관 결재라인이라도 간소화될 수 있다면 바람직할 것이다.

프로젝트를 마치며...

프로젝트가 수행 기간 내에 검수가 완료 되지는 못했으나, 몇몇 팀원들은 1 ~ 2주 정도 늦은 것은 On Time으로 봐도 된다고 이야기 한다. 이번 프로젝트처럼 개인적으로 어려웠던 프로젝트는 없었다. 아마 PM으로서 역량이 많이 부족하여 어려움을 느끼는 강도가 배가되었을 것이다. 그래도 무사히 마칠 수 있었던 것은 참여한 프로젝트 팀원들은 물론 비록 협력직 개발자지만 PL이라는 무거운 짐을 지웠는데도 불평, 불만 없이 잘 수행해 준 손경덕 책임에게도 감사한 마음을 드리고, 특히 박석재 수석과 이재욱 수석에게 진심으로 감사의 말을 전하고 싶다. 마음과 달리 프로젝트 종료 휴가도 제대로 챙겨주질 못한 채 프로젝트에서 철수시키고 어려운 프로젝트로 투입시키게 된 것에 대해 더욱 미안한 마음을 든다.

간혹 사석에서 쉬운 프로젝트는 없으며 프로젝트를 어려운 길로 인도하는 상황은 어느 누구도 예측할 수 없다고 이야기하였다. 이번 프로젝트를 수행하면서 느낀 점 중 하나가 위험관리의 중요성에 대한 인지이며, 지금 새로 진행하고 있는 프로젝트에서도 우선 순위를 위험관리로 두고 있다. 특히 프로젝트를 원활히 진행할 수 있도록 지원해 주는 많은 사람들이 있는데, 그 중에서도 PMO와의 협업을 통해 적절한 위험 통제를 하고 신속히 이슈 해결을 해야 한다.

프로젝트 PM을 수행하면 많은 것을 보고 듣고 느꼈으나, 필자의 필력이 짧아 제대로 표현하지 못하고 두서없이 작성되었으나 끝까지 읽어 주신 것에 감사하며, 끝으로 현재 진행하고 있는 프로젝트 뿐만 아니라 앞으로 다른 프로젝트에서 인연을 맺는다면 프로젝트 성공 뿐만 아니라 개인의 역량을 마음 껏 발휘할 수 있는 기회를 만들고자 한다.

감사합니다.