SI 프로젝트가 힘들다는 이유

보통 IT학원 마치고 타이밍을 놓치면 취업시즌이 아닌 애매한 시기에 취업시장을 보게 됩니다. 이럴때 제일 많이 보이는게 SI 업체들과 인력 파견 업체지요. 10년 정도 SI를 해봤는데 뒤늦게 돌아보면 그때가 제일 노동 대비 힘들었던 시기였기는 합니다. 그렇다고 솔루션 업체나 서비스 업체들이 널널하다는건 아닙니다만 SI 취업을 고려중이신분들께 참고가 될까 해서 기록합니다.

시작부터 모호하다

어떤 프로젝트를 보면 고객사에서도 뭘 만들어야 하는지 모호한 경우가 많습니다. RFP라는 고객의 요청서를 보면 뭘 만들려는 건지 왜 하려는건지 모르는 프로젝트들이 많습니다. 그나마 공공 프로젝트들이 경험해 봤을때는 요구사항이 명확하더군요. PM이나 영업이 역량을 발휘하여 우리가 할 범위가 어떤것이고 프로젝트내에서의 기획/설계/구현/검수 일정이 어떻게 되는지를 파악하고 선을 긋는다면 그나마 좀 수월하게 진행됩니다. 그리고 대부분의 발주사들은 고유의 내부 프로세스가 있습니다. 예를 들면 설계 단계가 끝날때 유관부서와 CDR이라는 리뷰회의 등을 하는 곳들이 있는데 그런 일정들을 미리 파악하고 준비해 두지 않으면 개발도 들어가기 전에 야근 모드로 바뀔수 있습니다. 어떤 고객사는 '모르고 계셨어요? 영업쪽에 얘기했었는데요?' 하고 영업쪽은 '그게 그 얘기였어? 몰랐지?' 하면 중간에 낀 개발자만 피곤해 집니다.  

 

고객의 단어와 내가 생각하는 단어는 다르다

처음 상대하는 고객사에서 자주 발생하는 일입니다. 구현 완료라는 단어를 예로 들어보죠. 어느 개발사는 구현 완료는 코딩만 끝내고 실제 QA에서 버그를 잡는 수준으로 이해를 하고 있는데 고객사는 단위 테스트 완료 또는 전체적인 기능이 동작하는것 까지를 원하는 경우가 있습니다. 구현 완료해서 약간의 동작을 보여주니 담당자 표정이 바뀝니다. 그럼 우리도 덩달아 불안해 지지요. 그 다음부터는 담당자의 집중 마크와 프로젝트 끝날때까지의 시달림이 기다리고 있습니다. 구현범위에서 특히 단어의 차이가 많이 발생하게 됩니다. 관리자만 쓰는 기능이다라고 해서 구현했더니 OP(오퍼레이터)가 관리자에 포함된다 등등. 그래서 처음 상대하는 고객사의 프로젝트의 경우 그 범위에 대해 다소 귀찮더라도 설계단계전에 확인하고 진행하는게 나중에 구현을 뒤집는 사태를 방지합니다. 특히나 단어가 다르다는걸 알게 되는 시점이 어느정도 구현되어 프로토타입을 보여주거나 시연, QA 단계일 가능성이 높습니다. 

 

고객은 기획과 디자인을 마음에 안들어 한다

예전에 개인적으로 했던 우스게소리로 고객은 잡스가 디자인했어도 마음에 안들어 할거다라고 했습니다. 특히 우리나라에서는 조직체계가 껴 있기 때문에 이게 더 심각하게 다가옵니다. 일단 고객사 담당자부터 보면 디자인/기획 한벌 가져가면 일단 한번에 오케이는 없습니다. 반려/재작업을 몇번해서 겨우 만들어지는 경우가 다반사 입니다. 기획이야 구현하다보면 그 논리적인 헛점(홀)이 발견되서 고칠수 없기 때문에 이해를 합니다만, 디자인은 글쎄... 뭐가 마음에 안들지? 하면서도 의견이 좀 나오니까 반영을 해서 보여주게 됩니다. 그나마 여기까지는 괜찮아요. 아직 윗분들 보고라는 관문이 남아 있습니다. 담당자 컴펌이 나서 디자인 작업하고 밑작업 진행중인데 그 와중에 담당자가 윗분들께 보고하고 나서 회의를 소집합니다. 마음에 안든다. 트렌드에 안맞다. 등등 윗분들의 의견은 우리를 미치게 합니다. 뭘 어떻게 바꾸라는거지? 차라리 명확하게 얘기해 주면 그대로 바로 고쳐서 돌려보내겠는데 저런 모호한 얘기는 답이 없습니다. 또는 아예 까일걸 생각하고 몇가지 안을 정해서 보내주면 여기는 A안, 여기는 B안, 여기는 C안을 쓰는걸로 다시 가지고와봐 라는 답변을 듣게 됩니다. 이건 뭐 개발자 입장에서는 어떻게 느낄지 모르겠지만 디자이너 입장에서는 분노하는 경우가 있습니다. 이런 상황에서 PM은 디자이너를 어떻게 달래서 처리해야 할지 전전긍긍하게 됩니다. 디자이너만 문제가 되느냐? 이 시점에는 개발쪽에서 이슈 제기를 시작합니다. 이러면 개발 일정 못맞춘다고... 일정을 무기로 담당자를 압박해서 겨우 디자인 승인을 받아 처리되기는 합니다만 PM입장에서는 양쪽으로 채이는 힘든 시기 입니다.

 

그럼에도 오픈 일정은 바뀌지 않는다

어떻게 디자인/기획이 승인되었다고 해도 시련은 끝나지 않았습니다. 분석/설계 단계에서 디자이너가 불을 뿜었지요? 이번에는 개발쪽에서 이슈 제기를 시작합니다. 개발 일정을 까먹어서 일정 지연이 우려 되어도 일단 가보자는 PM과 고객사 담당자의 얘기에 불을 뿜기 시작합니다. 제가 개발 직군이다보니 이 부분에 대해서 이해 갑니다. 고객사에 어필해도 쉽게 바뀌지 않습니다. 이 부분도 결국은 시간은 돈이기 때문이지요. 외주 업체와 연합한 프로젝트는 더 피곤합니다. 한달 더 늘렸을때 인원을 몇명을 유지시키고 그러면 총 얼마... 이런거 고민하다보면 PM은 도망을 가고 싶어지고 결정의 시기는 다가 옵니다. 지금부터 야근 모드? 하다가 안되면 그때부터? 야근하자고 하면 할까? 뒤늦게 생각해보면 개인적인 느낌으로 개발 기간이 4개월 이상으로 가늠했던 프로젝트는 그때부터 조금씩 달리기 시작하면 됩니다. 그런데 그 이하의 개발 기간이면 그건 개발 진행 초에 드러눕던가 해야 합니다. 경영진 중에는 인원 더 투입해. 하는 분들도 있습니다만 투입되면 그 다음날부터 업무하는 개발자는 없습니다. 특급 할아버지도 안돼요. 제가 이럴때 자주 쓰는 말이 있습니다. 임산부 10명이면 애가 한달만에 나옵니까?  

 

검수때 새로운 시련

어떻게 달려서 검수에 도달했습니다. 좀 꼼꼼한 개발조직은 구현시에 개발/예외 테스트를 시켜서 아예 못도는 물건은 아닌 수준으로 내놓습니다만, 여기서 고객사의 검수 프로세스를 만나게 됩니다. 위에서 얘기한 내부 프로세스라는게 있지요? 요구사항 명세서에 한줄로 간단히 써놓은게 실제로는 어마무시한 일로 번지는 경우가 있습니다. 예를 들어 '보안 검수를 진행해야 한다.' 이 한마디에 보안 담당자 인터뷰, 산출물 제출, 모의 해킹, 취약성 테스트... 얘기만 들어도 피곤하고 시간 많이 걸릴것 같지요? 이런거 몇게 있습니다. 성능 테스트, 예외 테스트 등등. 해당 고객사랑 몇번 해본 업체나 PM은 그걸 알기 때문에 시간/인력도 빼놓고 준비를 틈틈히 합니다만, 처음 당해보는 경우는 그냥 야근/주말 출근이 일상으로 바뀝니다. 그리고 그게 한번에 통과하는 법이 없습니다. 최소 두번은 하지요. 그게 세번 넘어가면 개발 역량에 대해 의구심을 가지는 경우도 생겨서 피곤해 집니다. 그거에 기능 테스트, 시나리오 테스트 등등을 하게 되면 PM/개발자는 수척해지고 미쳐가기 시작합니다. 저는 이때 살이 제일 많이 빠지더군요.

 

마치면서

요즘은 IT 세상도 점점 좋아지면서 SI 프로젝트 환경이 좋아지고 있습니다만 간혹 위기가 닥치는 경우가 많습니다. 경험과 경력이라는게 결국 위기의 순간에 고생을 덜 하거나 사전에 회피하는 노하우의 양과 시간을 의미하는게 아닐까요? 위의 내용을 참고하셔서 프로젝트 하실때 좀 더 평온하고 순탄한 프로젝트를 수행하는데 도움이 되면 좋겠습니다. 주의사항을 요약하자면 다음과 같습니다.

- 고객사의 프로세스 일정/용어를 미리 확인 하고 그 내용을 파악하자

- 기획/디자인이 컨펌나지 않을 경우를 생각해서 일정계획을 보수적으로 잡자

- 기획/디자인의 컨펌은 실무자보다 경영진(의사결정권자)에서 틀어질수 있다

- 기능 구현시 단위 테스트와 예외 테스트는 끝내는게 검수때 편하다

- 검수시에 고객사에서 원하는 시험과 일정/준비물은 미리 파악해서 대비하자