요즘 SI 등 외주 개발 프로젝트 흐름과 가장 중요한 요소

SI 같은 외주 개발 프로젝트에 참여를 하면서 느낀 부분을 통해 가장 중요한 것을 뽑아보았습니다. 개인적 생각 외에 함께 프로젝트에 참여한 개발자와 디자이너 등과도 이야기한 내용을 감안하였습니다. 기획자로 투입되었기에 이런 토론이 가능했습니다. 

 

 

최근 SI 등 외주 개발 흐름에 대한 공통된 의견

 

기획자다 보니 자연스럽게 고객뿐 아니라 개발자와 디자이너와 이야기하는 일이 많고, SI 등 외주 개발 프로젝트를 하다 보니 대기업에서 공공, 스타트업에 이르기까지 다양한 프로젝트를 참여하게 되는 건 자연스러운 흐름입니다.

 

현장에서 워낙 개발자가 부족하다 보니 나타나는 뻥튀기 경력의 문제도 있지만 전반적인 개발 인력의 질이 떨어지고 있다는 것은 기획, 개발할 것 없는 공통된 의견이었습니다.

 

이외에도 SI 등 외주 개발 프로젝트가 워낙 하청에, 하청으로 다단계로 진행이 되므로 실제 개발 외에 인건비를 빼내기 위한 인력이 꽤 있다는 것입니다. 특히 하청으로 넘어가면서 한 명씩 넣는 관리자 또는 리더급인 PM, PL에서 이런 경향은 최근 SI로 갈수록 많아지는 것을 경험하였습니다.

 

그리고 또 하나 공통된 의견으로 SI 등 외주 개발자의 연령이 높아지고 있다는 점입니다. 많은 개발자들이 15년 전에 자신이 지금까지 SI 개발을 하고 있을 거라고는 상상도 하지 못했다고 이야기합니다. 더해 많은 40대 개발자들이 자신이 프로젝트 막내 라인에 있으리라고는 생각하지 못했다고도 합니다.

 

최소 10년 이상 대형 SI 프로젝트를 해온 개발자들과 이야기해본 공통된 의견을 정리하면 크게 2가지입니다.

1. 점점 SI 개발 인력의 질이 낮아지고 있다.
2. SI 개발자 평균 연령이 높아지고 있다.

입니다.  

  

 

최근 SI 흐름의 원인

 

최근 SI 등 외주 개발 흐름을 만든 가장 큰 원인은 인하우스 SI 기업에서 시작되는 하청의 구조 때문입니다. 이는 공공과는 또 다른 형태의 문제를 만들어 냅니다. 이 둘은 결국 개발 프로젝트의 실패율을 높이는 공통점이 있습니다.

 

대기업 계열 SI 기업의 특징은 개발 실무 경험이 없는 PL, PM을 현장에 투입한다는 것입니다. 어쩌면 대기업 계열사기에 가능한 것일 수도 있습니다. 문제는 개발 하청 업체도 이런 흐름을 답습하고 있다는 것입니다.

 

영업형 PM, PL 흐름은 대기업 계열사들이 분사하면서 심해졌습니다. SDS, CNS, C&C 등과 같이  대기업 계열 SI 기업의 경우 분사된 기업은 과거에는 당연한 고객이었지만 이제는 영업을 해야 하는 대상으로 변경됩니다. 물론 인맥과 내부 정보 등에서 앞선 우위는 있지만 상황이 달라진 것은 분명합니다.

 

특히 GS, LX 등 큰 규모 분사가 많은 LG에서 이런 현상은 두드러졌습니다. 일단 SI 기업의 규모나 과거 진행 사항 등을 기반으로 영업을 통해 이탈할 수도 있는 고객을 잡아두면서 수익률을 유지해야 하기에 무리한 영업적 약속과 함께 하청을 진행하게 됩니다.      

 

당연히 영업적으로 하는 약속은 크고 수익률을 높이기 위해 하청을 주면서 수수료(갑자기 단어가 생각나지 않네요)를 높게 책정합니다. 중견급 SI 하청 업체도 수익을 확보하기 위해 수수료 외 인력 투입 수익을 위해 적당한 관리는 할 수 있는 PM과 PL을 넣고 나머지는 또 하청을 줍니다.

    

 

무엇을 개발할지를 모르는 상황에서의 개발이 가져오는 문제들

 

그러다 보니 재벌 후계자형 PM, PL이 SI 등 외주 개발 프로젝트에 투입되게 됩니다. 재벌 후계자형 PM, PL이란 해당 업무의 실무 경험이 없는 PM, PL을 의미합니다. 재벌 후계자가 업무 시작부터 실장 또는 이사에서 시작하듯 SI 시작부터  PM, PL만 했거나, 그냥 PM, PL이 하고 싶어서 회사에 하겠다고 요구해서 하고 있는 것을 의미합니다.

 

그러다 보니 PM은 요구사항 정의서 만드는 방법도 모르고 이를 상세화 하는 것은 해본 적도 없습니다. WBS는 당연히 만들지 모릅니다. 당연히 개발 업무의 범위와 목표를 모르는 것은 당연합니다. 단지 얼굴 마담으로 책상에 앉아 있을 뿐입니다.

 

이런 PM은 공공에서는 대기업 개발 프로젝트만 했다고 하고, 대기업 개발 프로젝트에서는 공공 프로젝트만 해서 그렇다고 핑계를 댑니다. 그런데 SI 등 외주 개발 프로젝트 인력의 고령화로 인해 프로젝트 경력이 최소 10년 이상 되는 인력들이다 보니 공공 프로젝트도, 대기업 프로젝트도 다 해본 경력자이다 보니 이 말이 얼마나 말이 안 되는지 알고 있습니다.  

 

제가 기획자이기에 기획 PL을 보면 기획 업무를 해온 경력자가 PL을 하는 것이 아니라 수행사 또는 하청 수행사의 직원 중 기획자를 하고 싶은 사람이 기획 PL을 하는 경우가 꽤 있는 것을 보게 됩니다. 그러다 보니 기획 업무가 아니라 기획 문서에 집착하게 됩니다.

 

기획 과정에 따른 적절한 문서가 연결되는 것이 아니라 그냥 아는 문서의 작성을 지시하기만 합니다. 대부분 본 기획 문서가 스토리보드, IA 이기에 프로젝트가 시작되면 개발 목표의 파악은 필요 없고 그냥 IA, 스토리보드만 만들어 댑니다. 당연히 고객은 왜 이런 화면을 그려오는지 이해하지 못합니다.

 

이는 기획 PL이 기획이라는 단어조차 모르는 상황입니다. 단지 기획하면, 삼성 기획실처럼 먼가 멋있어 보이기에 기획 PL을 하려 하는 것으로 비추어집니다.

 

PM, PL이 실무를 해본 적도 없고 알지도 못하고, 단지 밑에 사람들이 해온 문서만 정리해 보고만 합니다. 오히려 고객이 눈치채고 프로젝트 범위를 벗어난 이런저런 요구를 하고 PM, PL은 이런 요구를 수용합니다. 더 큰 문제는 수용한 요구사항을 공유하지 않는 것입니다.

 

요구사항 정의 작업을 할지도 모르고 왜 해야 하는지도 모르기에 모든 것이 그냥 말로 진행됩니다. 심한 경우는 고객과 하는 전체 회의에서 안된다고 한 개발 부분도 PM, PL이 개발자 없이 고객과 한 회의에서는 한다고 한 것입니다. 하도 문서화하지 않으니까 고객이 문서를 만들어 전달해 주고 보고서 형태로 받아가는 일도 일어난 것을 목격하기도 했습니다.

 

 

무엇을 개발할지 결정하는 요소 '요구사항 정리'

 

물론 계약 단계에서 개발할 내용을 상세히 작업할 수도 있습니다. 그런데 최근 SI 등 외주 개발에서 이런 일은 거의 없는 것 같습니다. 그러므로 요구사항 파악 및 상세화 단계에서 프로젝트를 정의해야 합니다.

 

개발의 범위와 목표를 분명히 하지 않는 상황에서 어떤 개발도 성공할 수 없습니다. 인터넷 쇼핑몰을 만드는 프로젝트를 한다고 할 때 형식적인 산출물은 5천만 원이나 100억 원이나 비슷할 수 있지만 그 내용은 비슷할 수 없습니다. 네이버 스마트 스토어 쇼핑몰 구축과 쿠팡 같은 쇼핑몰 구축이 같을 수 없습니다.

 

경영학과 출신이라 ERP 관련 프로젝트에 참여를 하기도 합니다. 그런데 ERP에 SI 기획자가 투입되지 않는 이유는 있습니다. 투입된 ERP 프로젝트에 기획자가 투입된 이유도 있습니다. 일단은 사용자 화면 편의성 증대를 목적으로 투입되었는데 영업과 PM, PL ERP에 대한 이해가 없다 보니 화면 사용성 증대가 아니라 자꾸 SAP 같은 시스템 구축으로 흐르고 있는 것을 보게 됩니다. 10명 안팎의 프리랜서 개발자로 말입니다.

 

이렇게 개발 대상을 파악하지 못한다면 그 프로젝트가 성공할 수 없을 것입니다. 

 

개발 대상의 실무적 실체를 구체화하는 작업이 요구사항 정의 및 상세화입니다. 이를 통해 프로세스가 나오고 기능이 도출되고 개발의 규모와 수준이 결정됩니다. 또한 WBS 작성을 위한 항목과 각각의 개발 항목의 시작과 끝, 연결이 정의되게 됩니다.

 

그러기에 개인적으로 SI 등 외주 개발에서 가장 중요하고 반드시 가장 먼저 해야 하는 작업이 요구사항 정의라 생각합니다. PM, PL이 요구사항 정의를 할 수 없다는 것은 업무 파악을 할 능력이 없다는 말과 같다고 생각합니다.  

 

이 요구사항 정의는 특정 방법, 특정 파일 형식으로 해야 하는 것은 아닙니다. 프로젝트마다 다 그 특성이 다르고 요구사항의 항목이나 상세화 방법이 다를 수 있습니다. 그러므로 프로젝트 특성에 맞추어 전체 아우트라인을 PM이 만들고, 상세 파트는 각 PL이 채워나가면 됩니다. 이때 PM과 PL 협의는 반드시 필요합니다.

 

제 개인적으로 개발 프로젝트 성공을 위해 두 번째 중요한 것은 대화라 생각합니다. 잡담도 필요하지만 개발과 관련한 대화가 매우 중요합니다. 그런데 점점 개발 업무 대화를 안 하는 분위기로 흐르는 것 같습니다. PM이 고객을 피하고 PL온 노이즈 캔슬링 이어폰을 끼고 집중합니다.

 

요즘 SI 등 외주 개발 프로젝트들이 형식적으로는 성공이지만 실질적으로는 대부분 실패인 이유가 여기에 있지 않을까 하는 생각도 들었습니다.