프로젝트 진단 (응답하라 2007~2008)

하다보니 IT컨설턴트 28년차(업무편)-아홉번째이야기

by 연작가

여덟번째 이야기까지 적고 또 벌써 3달이 지났다. 이 속도면 2022년까지 쓰는데 몇 년 걸리겠다.

해가 바뀌어 제목도 27년차에서 28년차로 바뀌었다. 속도 좀 냅시다, 깡지씨


이제부터는 '죽도록 바쁜' 시기는 지났다.

이는 몇가지 의미를 담고 있는데 첫째는 5년간 몸담은 N프로젝트를 끝으로, 말 그대로 물리적으로 바쁜 시기를 넘겼다는 것을 의미한다. 두번째는 지나고 보니 N프로젝트에서의 경험이 제법 IT컨설턴트로서 큰 자산이 되어 이전보다 일하는 속도가 훨씬 빨라지고 노련해져서 그만큼 시간을 아낄 수 있다는 의미다.


반면 점차 부각되는 일은 '나의 미래'와 '점차 커가는 션'이다.

하루 24시간이라는 한정적 시간 속에서 일과 육아 두가지를 균등한 비율로 둔다는 것이 점차 어려워졌다. 그렇다고 둘 다 소홀히 할 수는 없다보니, 꽤 많은 갈등 속에 살았다. 항상 현명한 선택을 한 것은 아니다 보니 후회할 일이 있을 수도 있으나, 후회할 시간에 어떻게 만회를 하지에 더 촛점을 맞췄다.


그래서 이후 행보는 '난데없는 결정' 스러운 것도 많았다.


o 프로젝트 명 :

- S사 차세대시스템 고도화 프로젝트 (2005.11~2007.12)

- IBM QRM(Quality assurance management) (2008.01~2008.07)

o 역할 : IBM내 프로젝트 관리 및 진단

o 수행할 당시 나이 : 35세~36세 / 션 5세~6세





N프로젝트 오픈 후 2년 가량은 몸이 상당히 편했다.

2007년은 N 고도화 프로젝트를, 2008년은 IBM QRM부서로 옮겨서다.

대게 대형 프로젝트를 할 때 오픈을 앞두게 되면 일부 과제는 오픈 후 수행과제로 남기기도 하고, 오픈 후 안정화를 위한 추가 활동이 더 필요하다. 또한 운영조직에게 업무 인수인계 및 유지보수 작업을 위한 프로세스 set up을 해준다. 프로젝트 기간 안에 이 모든 것이 마무리 되면 좋으나, N프로젝트는 모든 영역이 새롭게 개편되다 보니 오픈 이후에도 해야 할 일을 N고도화 프로젝트라는 이름으로 따로 진행했다.


다행인 점은, N프로젝트를 할 때의 살인적인 스케줄, 과도한 업무량은 사라져서 비교적 안정적인 출퇴근 시간을 할 수 있었고, 주말에 더 이상 출근을 하지 않아도 괜찮았다.


당시 내가 맡았던 것은 '새로운 운영 프로세스 Set up' 이었다. 운영과정에서 요구사항 (신규/변경)이 발생했을 때 분석/설계/개발/테스트/배포까지 일련의 절차와 양식을 정의해 주고 실제 가동해 보는 것이었다.

이미 아키텍트, 데이터 전환, 테스트, 이행을 골고루 했기 때문에 누구보다 S사 절차에 대해 잘 알고 있어서 운영을 위한 절차 수립은 그리 어렵지 않았다.

단지 프로젝트보다는 '안정성'에 더 집중해야 하므로 영향도 분석 (Impact analysis)을 많이 강조했고, 프로젝트에서 만들어낸 테스트 시나리오/케이스 중 핵심 기능관련 한 것들은 재활용할 수 있도록 절차에 포함했다. Application측면만 정의했다가 데이터 영역에서 사고가 터질 수 있으므로, 이에 대한 Cross check도 잊지 않았다.

그렇게 절차를 Set up하고, 메타시스템에 반영하도록 하여 가급적 자동화와 Rule base 를 통해 Human error를 줄이도록 했다.


그렇게 1년의 안정화 기간 후, 처음으로 회사 내 부서를 옮겨보기로 했다. 10년이상 IT컨설팅을 하다가 본사 내 부서로 가보기로 한 것은 나름 큰 결정이었다.


N프로젝트 하면서 생긴 나의 딜레마는, 너무 재미있다 vs 이러다 과로사하겠다 였다. 무엇보다 션 얼굴 보기가 너무 힘들어서 이대로 가도 괜찮을지 걱정이 되었다. 아무리 멘토를 찾아보려고 해도 여자가 직장에서 성공한다는 것은 가정을 포기하지 않는 이상 불가능한 시대이기도 했다. 게다가 아무리 강철 체력이라고 해도 잠을 이리 못자고도 앞으로 긴 세월 견딜 수 있을까도 의문이었다.


그러면서 N 고도화 프로젝트가 주는 이 평화로움에 대해 낯설어 했다. 바쁘게 산 세월이 너무 길었는지, 일이 줄면 좋아해야 할텐데 나는 오히려 나의 정체성, 나의 향후 행보에 대한 생각을 할 시간으로 다가왔다.

찾아보니, 그 당시 혼란스러운 마음을 적은 글이 남아 있다.


https://blog.naver.com/jykang73/90024534510



그래서 본사 부서 중 QRM팀으로 옮기게 되었다. QRM은 IBM이 수행하는 그 많은 프로젝트를 관리/점검/진단하는 부서로 크게 금융, 통신, S&M 3가지 영역의 담당자가 있었다. 나는 S&M 영역의 후임으로 가게 되었다.

처음 몇 개월은 새로운 일을 하다보니, 너무 재미있었다. 꼭 새 프로젝트 시작할 때의 흥분과 같았다.

프로젝트를 직접 할 때와 또 다른 시각으로 프로젝트를 바라볼 수 있게 되었고, 프로젝트 전체를 보는 시각 및 객관적 진단 능력을 기를 수 있었다.

그동안 10년 넘게 프로젝트를 하면서 한 분야를 깊이 있게 했다면 이번에는 프로젝트의 탄생부터 종말까지 전 프로세스를 훑었고, 프로젝트 제안과 계약단계의 과정도 참여해 보면서 전체 Life cycle에 대한 이해도 할 수 있었다. 프로젝트 관리 및 진단에 대한 방법론을 공부하면서도 꽤나 희열을 느꼈다.

프로젝트라고 하는 것이 여러 분야가 결부된 종합 예술품과도 같은데, 전체를 보는 눈도 키워볼 수 있었다.

그 당시 얼마나 재미있어 했는지 글도 남아 있다. 이 모습은 새로운 프로젝트 할 때마다 새로운 것에 신나하던 모습이기도 했다.


https://blog.naver.com/jykang73/90027070996


반면, QRM팀의 문제점이 하나 있었는데, 금융(은행), 통신, S&M 의 구분 단위였다.

당시 IBM에서 동시 수행하던 프로젝트가 100개라고 하면, 우리나라 은행수, 통신사수는 얼마안되어서 금융을 맡은 사람과 통신을 맡은 사람이 관리하는 프로젝트는 대형이긴 해도 몇개 되지 않았다. 나머지는 모조리 S&M에 몰려있었으며 그 중 대형프로젝트가 5개 가량 포함되어 있었다. 즉, 일의 양에 있어서 형평성에 맞지 않았으나, 이에 대한 조정이나 인력 추가 없이 팀이 운영되다 보니 S&M 담당자는 일이 너무 버거워 계속 바뀌어 왔던 것이다.


그 영역을 맡고 보니, 챙길 일이 한두가지가 아니다. 프로젝트 규모에 따라 관리 강도가 다르긴 해도 작다고 해서 방치할 수는 없다. 그렇다고 해서 억울하지 않았던 이유는, 그간 내가 주로 했던 프로젝트는 제1금융권과 통신 중심이었는데 다른 영역의 프로젝트를 볼 수 있어 좋았고, 내가 했던 차세대 프로젝트가 아닌 다른 형태의 프로젝트에 대해서도 접할 수 있어 좋았다. (이 쓸데없이 무한 긍정 마인드 같으니라고)


내가 맡은 프로젝트 중, 대형 프로젝트는 자리에 앉아서 관리/진단하는 것이 아니라 해당 프로젝트 SITE로 주기적으로 가서 진단을 해야 한다. 고객/IBMer/협력업체 인터뷰까지 하여 Risk를 발굴하기도 하는데 S&M 특성상 전국 각지에 프로젝트가 있다. 그 덕에(?) 타 지방에도 출장을 다녔다.

대형 프로젝트는 AP조직과도 Communication 및 각종 승인절차를 준수해야 해서 영어에 대한 스트레스가 살짝 쌓이기도 했다.

프로젝트 착수터 종료과정까지 전체를 바라보는 일을 하였고, 관리해야 하는 프로젝트가 상당히 많았으나 실제 프로젝트 하는 것에 비하면 야근 강도가 확 줄었다. 그것보다 수백명을 상대하고 설득하고 호령하는 일에서 벗어나다 보니 그에 따른 스트레스도 사라졌다. 게다가 당시 본사 위치가 코엑스 아셈타워여서 창밖으로 보이는 경치가 얼마나 사람을 매료시켰는지 모른다. 이렇게 퇴근하고 집에 오면 션과 함께 하는 시간이 이전보다 늘어서 책을 읽어준다거나 놀아주는 일도 더 자주 해 줄 수 있었다.


그러면 QRM의 객관적 입장으로 프로젝트를 바라볼 때 주로 보이는 문제점은 무엇이 있을까.


■ Underestimation

프로젝트를 발주할 때, 제안할 때 정확하지는 않더라도 어느 정도 합리적인 계획이 세워져야 하는데 대게는 예산에 맞추어 정해진다. 가장 크게 좌우되는 것이 기간과 참여인원이다. 프로젝트 준비과정에서 기간과 참여인원 맨먼스는 엿가락 같은 유동성을 보이며 최종 계약이 되고 나면 의례히 할인이 적용된다.

오픈일은 정해져 있다 보니, 준비기간이 늘어나게 되면 프로젝트 기간을 줄이게 되는 결과를 초래하고, 할인이 적용되다 보니 맨먼스가 줄게 된다. 이런 여파는 주 사업자와 계약하는 많은 중소 서비스 업체에도 영향을 주며 양질의 인력이 투입되는 것을 막는 결과를 낳기도 한다.

계약에 참여한 인력과 실제 프로젝트에 참여한 인력은 다른 경우가 많다. 프로젝트에 참여한 인력은 계약단계에서 약속한 일을 행해야 하는데 짧아진 기간과 줄어든 인력으로 고생하는 경우가 많아진다.


■ 초기 Risk

프로젝트 시작할 때 이미 많은 Risk들이 있다. 이런 초기 Risk를 발굴하여 해결방안을 미리 마련하는 것이 중요하나, 많은 경우 이를 간과하고 바로 시작한다. 프로젝트 초반이다 보니 적응 및 분위기 파악을 한다고 더더욱 초기 Risk를 방치하는 경우가 크다.

준비가 다 되어 있는 상태로 제 날짜에 프로젝트가 시작하는 법이 없다 보니, 첫 시작부터 일정지연을 안고 시작하나 이에 대한 파악도 잘 하지 않는다. 또한 초기 조직 셋업와 달리 실제 가동할 때 그레이 존이 발생하는데 이를 빨리 표면화 해 둬야 이후 추가 Risk 가 발생하지 않는데 조용히 지나가려는 분위기도 많다.

가장 좋은 것은 초기 Risk를 적극적으로 발굴하고, 불편함을 말할 수 있는 분위기를 조성하는 것이다. 그리고 발굴하는 것에서 그치는 것이 아니라 해결하려는 노력을 보여줘야 프로젝트 참여자들의 신뢰를 얻을 수 있다. 이는 리더와 프로젝트관리자(PMO)에게 달려있다.


■ 단계지연

분명 단계가 끝났고, 일이 마무리 되지 않았음에도 불구하고 다음 단계로 그냥 진입한다. 단계 종료에 대한 절차가 있으나, 프로젝트 참여자들은 절차라면 진저리 치는 습성이 있으며 산출물의 중요성을 인지 하지 못하는 경우가 많다. 이는 개발자의 특성이라고만 말하기 어렵다. 전체 분위기 그러하다.

그러면서 절차를 꼬박꼬박 준수하게 하니, 눈 가리고 아웅하는 경우가 많다.

일정이 되었으니, 다 했다고 숫자로 표기하고 산출물이나 소스 품질은 높지가 않다.

이렇게 다음 단계, 다음 단계 넘어가서 테스트 단계에 가면 여러 문제가 복합적으로 결부되어서 손쓸 수가 없다. 그러면서 다시금 산출물은 버리고 소스, 테스트에 집중하자고 한다.

그 결과는 오픈 지연 또는 요구사항 축소로 이어진다.

뭐든 기본에 충실해야 한다. 분석단계, 설계단계, 개발단계, 테스트단계 각각 의미가 있다. 이런 waterfull 방식에 회의를 품은 분들이 agile방법론을 만들기도 했으나 대형 프로젝트에서는 그 어떤 방법론도 적용하기에 여의치 않다. 오히려 방법론을 떠나 약속된 기간 내 약속된 물량을 최상의 품질로 만들어 내고, 그 사이에 생긴 이슈나 리스크를 꾸준히 오픈해 준다면 오히려 생산성 향상 뿐 아니라 저녁 있는 삶을 누려볼 수도 있다.


■ 품질

프로젝트를 할 때 가장 중요한 두 가지가 일정준수와 품질확보이다. 이 두가지를 동시에 진행하지 않으면 프로젝트는 실패한다. 특히 품질은 인력을 추가 한다고 되는 문제가 아니다. 이왕이면 양질의 인력이 프로젝트를 참여해 준다면 천군마마를 얻은 것이겠으나, 성실하고 배우려는 자세만 되어 있어도 충분히 품질확보는 가능하다.

개발자 자율에 맡기는 것보다, 품질 확보에 대한 노력을 다 같이 하면 훨씬 효과가 좋은데 다양한 방법이 있다. 이건 향후 프로젝트 관리 방법론에 대한 글을 쓸 때 자세히 쓰기로 하자. 단지 트러블 브로젝트 일수록 그런 노력이 없었다는 것은 공통 현상이다.

또 하나는 프로젝트마다 품질 담당자들이 있다. 안타깝게도 이 조직은 유명무실하게 운영되는 것이 현실이다 보니 이에 대한 기대치가 아예 낮다. 분명 방법이 있는데도 품질이 중요하다고 다들 알고 있으나 이에 대한 방안은 보고서에만 적혀 있는 것으로 끝이 난다.


■ 리더십과 소통 부재

뛰어난 리더 한 명이 있다고 프로젝트가 성공하는 것은 아니지만, 한정된 기간에 여러 이해관계자가 동시에 한 방향으로 나아가려면 리더십은 상당히 중요하다. 앞에서 무조건 진두지휘하는 것이 리더십이 아니라, 각각 자율성을 주되 냉철한 판단력은 반드시 있어야 한다.

세상을 살아갈 때는 성선설이 필요할 수 있으나, 프로젝트 만큼은 성악설을 바탕으로 바라봐야 한다. 문제가 생기면 사고로 이어지는 곳은 모두 다 성악설이 바탕이어야 한다고 생각한다.

만약 지속적으로 '문제 없이 진행 중입니다'라는 보고를 받는다면, 그것이 위험신호다.

세세한 내용을 몰라도, 잘 모르는 기술에 대한 것이라도, 들여다 보면 구멍이 보인다.

소크라테스의 문답법은 이때 필요한 스킬이다.

그렇게 가만히 들여다 보면, 가장 크게 보이는 것이 서로간 '소통 부재'이다. 정보가 시차가 생기거나 전달에 구멍이 있으면 이 또한 프로젝트의 리스트로 작용을 하며, 서로 원하는 것이 다를 때 대화를 나눌 수 있는 자리를 지속적으로 마련해야 한다.

무엇보다, 인간은 기계가 아니므로 마음을 어루만져주는 노력이 필요하다.



비교적 평온한 시기를 맞이한 것으로 아홉번째 이야기는 끝을 맺을까 하고, 이 기간이 션 5,6세니 션의 영어, 그림이야기를 열번째 이야기에서 하려고 한다.


그.런.데..

나도 참 병이다. 남들은 일을 많이 하면 병이 나는데, 나는 그리 프로젝트를 빡세게 해 놓고서, QRM부서 온지 대랴 4,5개월 넘어가서 어느 정도 익숙해 지려니 영 좀이 쑤시기 시작한다. 이런 식의 안정적으로 루틴한 일을 앞으로 쭈욱 계속한다고 생각하면 내 성미에 맞지 않는다. 월급을 받기 위해 일을 한 것이 아니었던 게 맞았나 보다.

야근을 하고, 밤을 세더라도 열정을 가지고 일을 하거나, 계속 새로운 프로젝트를 하는 것이 내 성미에 딱 맞다. 아이를 키우면서 일을 하려면 현실과 타협을 해야 하는데, 문제는 나 자신과 타협이 안된다.


그래서 소위 말하면 아이키우며 일을 병행하기에 좋은 부서를 온지 몇 개월 되지 않아 새로운 결심을 하게 된다. 이 이야기는 11번째 이야기에서 썰을 풀어보겠다.


그래도 일을 재미있어 하는 엄마에 대해 션도 아나보다. 엄마랑 헤어지는 것을 그리 싫어하면서도 어릴때 부터 엄마에 대해 자랑스러워했고, 지금도 그러니까. 고마워. 아들


https://blog.naver.com/jykang73/90029543314




매거진의 이전글데이터 전환/이행 (응답하라 2005~2006)