SI는 System Integration(시스템통합) 약자로, 그 자체로 부정적인 의미가 아니며 과거 하드웨어에 소프트웨어가 포함되어 납품되는 형태가
시간이 지남에따라 소프트웨어의 비중이 커지게 되자 자연스레 소프트웨어 개발 아웃소싱 을 지칭하는 단어가 되었습니다.
오늘날의 소프트웨어의 요구사항은 점점복잡해지고,요구사항이 변경되는 불확실성이 점점 늘어나고 있지만
SI개발을 다루는 과정이, 과거 제조에서 영향을 받아 물품을 납품하는 '제조하청' 방식에서 크게 다를바가 없습니다.
'하청(下請)'은 일본식 한자어로 알려져 있으며 국립국어원은 '하청'의 순화어로 '하도급'을 선정한 바 있습니다.
하지만 이것역시 상하 관계는 변화하지 않으며용어이며
갑을병정도 상하관계를 표현하거나 하도급에 하도급을 표현하는 표준단어는 아니지만
국내에서 통용될수 있는 가장 이해가 빠른 공통단어입니다.
하청업체대신 협력사,파트너사라는 용어를 사용하려고순화하려고 하지만 여전히 일하는 방식은 변화하지 않으며
문화가 좋다라고 생각한 대기업의 원청업체에서 일을 주기 시작하고 업무가 시작되면
원청 담당자는 '외주사','하청업체','하청개발자' 로 인지하고 개발자를 다루는 방식으로 이용하는것도 사실이며
이미 좋은개발문화를 가진 개발자를 보유하고 더 좋은 개발방법론을 알고있는 갑업체일지라도 일부 시스템은 하청으로 전환하며
개발문화와 방법론은 우리 조직을 위한것이지 남의 회사까지 챙겨주는 것은 아니다란점을 인식하는 것에서 시작합니다.
이러한 이유때문에 이 분야의 개발자는 개발자로 누려야할 문화와함께 권리를 못받는 경우가 대부분이며
그래서 'SI는 개발자의 무덤' 이라고 불리며 안좋은 의미로 일반적으로 인식이되고 있습니다.
하지만 SI를 경험했던 실무자 경험자체를 모두 부정적 요소로 일반화하고 그 기술적 경험까지 모두 나쁜것으로 정의할 필요는 없다고 보여지며
SI를 프로젝트를 경험하면서 발생하는 경험적 요소를 정리해보았습니다.
SI프로젝트의 경험적 요소 - 부정 vs 긍정
| 부정 | 긍정 |
|---|---|
남의 회사 일을 해주는 개발자를 말합니다. 따라서 대부분 자기 회사의 발전은 없습니다. | 기업단위의 복잡하고 다양한 문제의 해결방법을 제시하고, 규모있는 프로젝트만을 진행하기 때문에 개인의 스킬향상과 함께 회사에도 좋은 레퍼런스가 될수 있습니다. |
| 내가 책임지거나 결정할 수 있는 일이 별로 없습니다. | 다양한 해결방법을 축적하였으며, 최적화된 방법으로 고객사의 문제 해결을 제시합니다. |
| WBS는 고객의 요구사항을 방어하기 위한 수단이며 불필요한 산출물이 많다. | 일정준수와 함께 수준높은 문서를 작성해야한다. |
| 납품까지 완료까지 '갑'으로 명시된 계약관계를 준수해야합니다. | 소프트웨어 개발 한 사이클을 경험할수 있습니다. |
기업문화및 계약에따라 긍정적 요소도 있을수 있지만, 대부분 부정적 요소가 훨씬 많은것이 사실이며
SI는를 이해 하기위해 이 프로젝트는 어떠한 절차로 진행이 되는지도 추가로 살펴보겠습니다.
SI 프로세스
RFI라고 하면, 인적 네트워크 등을 통해 외주 업체를 미리 만나 회사 소개나 제품/서비스 소개를 받는 것에 해당되겠지만
이는 비공식적인 절차이므로 유무형의 압력에 노출되기 쉽다. 따라서 미리 업체들에게 RFI를 보내,
진행하고자 하는 업무(프로젝트)에 대한 정보를 수집할 필요가 있다.
따라서 RFI에는 많은 요구사항을 담지 않는다. RFI에서는 추진하고자 하는 업무(프로젝트)에 대한 간단한 개요/목적/예상 기간 정도를 표시하고,
이에 맞추어 외주 업체에 대한 정보, 제품/서비스에 대한 정보, 간단한 시장 동향, 주요 경쟁사 정보를 요청할 수 있다.
그리고 RFI에 대한 회신으로 20페이지 이내의 워드 문서로 받는 것이 좋다.
RFP로 넘어간다. RFI를 통해 수집된 정보를 바탕으로 실제 해당 프로젝트를 추진할 수 있도록 구체적인 정보들을 요청해야 한다.
RFP 단계에 참여하는 외주 업체는 모두 해당 업무나 프로젝트를 수행할 가능성이 있는 업체이므로, 최대한 자세하고 구체적이고 정확하게
RFP를 작성하여 요청해야 한다.RFP가 구체적일수록, 제안서의 품질인 높아지고 예산에 대한 이견도 줄어들 수 있기 때문이다.
또한 프로젝트를 진행하는 동안의 의견 충돌이나 갈등을 미연에 막을 수 있다.
RFP에는 해당 업무(프로젝트)에 대한 자세한 정보, 추진 일정, 예산, 그리고 제안서의 목차, 제안 평가 기준 등을 구체적으로 명시해야 한다.
RFP 작성부터 해당 외주 업무(프로젝트)의 성공 여부가 달려있다고 해도 과언이 아니다. RFI를 하는 이유도 실은 RFP를 제대로 작성하기 위해서이다.
착수되기까지 제안및 계약과정을 간단하게 요약해보았으며 계약이 잘 성사되어 착수가 되었다라고하면
이후 단계는 워터폴의 사이클과 거의 동일한 개발 방법론이 사용되게 됩니다.
과거에는 납품이후 소프트웨어의 변화필요없이 생명주기가 끝날때까지 업무방식/시장이 거의 변하지 않기때문에 최소 3년이상 그대로 사용가능했지만
오늘날의 소프트웨어는 업무상황과 시장상황이 지속적으로 변화하고 있기때문에 작동이후 변화에 대응하지 않으면 1년이내에 쓸모없을 가능성이 많아집니다.
SI→SM으로 전환될때 사실 신규구축때 발견하지 못한 추가적인 문제가 발생하며 이때의 경험적 차이를 추가로 살펴보겠습니다.
SM에서 - 부정 vs 긍정
| 부정 | 긍정 |
|---|---|
운영대응은 이미 계약시 정해진것으로 | 서비스가 수익을 내지못해도 유지되던 과거 스타트업의 성공 방식은 이제 거의 사라져가고 있습니다. 자신이 서비스개발 조직에 있다고하면 수익을 내야하는것에 대한 압박 을 견디고 이겨내야합니다. |
기술적 비용은 SI에서 이미 사용되었기에 | 새로운것을 연구하고 시도하지 않기때문에 |
| 만든사람의 지원없이, 문서를 보고 스스로 분석해야 합니다. | 문서수준/설계수준이 높고 연구한다고하면 |
| 장애가 발생하면 SLA준수계약을 바탕으로 실제 배상청구가 이루어지며 개발자는 부담으로 이어질수 있습니다. | 이 영역의 시스템은 일반서비스개발자가 접근도 못하는 특수한 영역일수 있으며 이 분야의 전문개발자가되면 회사를 나가도 프래랜서로 의뢰를 받을수 있습니다. |
| 시스템의 문제를 해결하기위해 출장가는 경우가 있을수 있으 며 시기가 길어진다면 재 책상환경은 아무런 의미가 없어지며 소속감을 중요하게 생각한다면 이 분야에 발을 들이면 안됩니다. | 계약회사에 따라 다를수 있지만 -자율출근/자유로운 커피타임/근무시간 제약없음등 |
고객의 성장이 곧 우리의 성장이라는 착각을 버려야합니다. 오히려 고객이 성장하면 개발팀을 꾸릴수도 있기때문에 | 규모가 큰 회사에서 제공하는 개발인프라는 작은규모에서 엔터프라이즈급의 회사의 프로젝트를 진행했다란점은 |
SM에서는 최근 개발문화와 비교했을때 , SI보다 더 부정적 경험을 가지는 요소로 가득합니다. 같은 을이라도 SI를 초기구축했던 A업체 ,
이것을 이어받아 SM을 해야하는 B업체 나뉠수 있기때문에 즉 이영역은 갑/을 의 갈등도 있지만 을/을의 갈등도 있기때문입니다.
그래서 SM이 부정적이라할지라도 그 프로젝트가 누구나 알만한 프로젝트와 연관되고 가치있는 기술을 보유했다라고 하면
1년만의 경험자체로 대기업의 개발사에 취직한 확률이 높습니다.
제 경험기준으로는 80%라고 이야기 드릴수 있을것같습니다. 지난 4년간 SI/SM을 경험하면서 팀초기빌딩을 포함 4년간 개발총괄및 개발자이기도 했으며
그 과정에서 구성원이 1년단위로 점프하는것이 이 팀의 문화와 같은것이 되어 버렸습니다.
NEXT :
Add Comment