1. SI란?

SI는 Ssibal Igeonmichinjiteeya 의 약자로 돈을 들여 원하는 걸 얻지 못하는 갑회사 와 받은 돈 보다 많은 일을 해주고 사람을 잃는 수행사 그리고 월급을 얻었지만 모든 걸 잃는 개발자 에 의해 돌아가는 승리는 없고 패배만이 존재하는 산업이다. 정상인의 시각으로는 있을 수 없는 산업으로 보이지만, 이 곳에 종사하는 사람들은 모두 세뇌를 당한 듯 이 산업을 믿고 있으며, 심지어는 인원이 늘어나기도 하는 기묘한 산업이다.

2. SI의 구성요소

2-1. 갑회사

흔히 SI에서 프로젝트를 오픈하는 역할을 수행한다. 이곳에서 일하는 사람들은 현업 이라고 칭해지며 프로젝트를 맡은 가장 우두머리 격인 사람들은 현업 PM 이라고 칭한다.

SI산업에서 돈을 쓰는 역할이지만 그 댓가로 받는 것은 일반적으로 유지보수가 제대로 안되는 결과물 이다. 물론 유지보수가 되는 결과물을 받는다 하더라도 자체적으로 유지보수 능력이 전무하다. 유지보수가 제대로 안되기 때문에 그들은 일정시기마다 다시 돈을 써서 새로 만드는 일을 반복하고 있다. 항상 똑같은 일들을 반복하는 것으로 봐서는 아마도 학습능력이 현저히 떨어지는 것으로 보인다.

2-2. 수행사

돈을 받고 개발자를 투입하는 인력시장 의 역할을 수행한다. 원래는 돈을 버는 역할을 맡고 있지만, 실제로는 항상 개발자가 빠지고 그 자리를 메우기 위하여 새로 인력을 데려오기 위해 돈을 소모하는 역할을 수행한다. 물론 돈을 아끼기 위하여 연차가 낮거나 신입 개발자 를 뽑는 경우가 많지만, 빠지는 인력은 최소 몇년은 일했고 다른 회사에서 충분히 데려갈 만큼의 실력을 가진 개발자 이기때문에 점차적으로 회사의 개발능력은 하향곡선을 그리게 된다. 물론 이쪽도 어느 정도가 되면 정신을 차릴만 하지만 많은 회사들이 자체 개발능력이 바닥으로 떨어져 폐업하는 것을 보면 역시 학습능력이 현저히 떨어지는 것으로 보인다.

2-3. 개발자

노예 라고도 부른다. 실제로 일을 하는 주체이며 그 댓가로 월급을 받고 산다. 보통은 수행사에 소속되어 있는 개발자 이지만, 프리랜서도 꽤 많은 비율을 차지한다. 대부분은 애초에 SI산업을 꿈꾸며 개발자가 된 것이 아니기 때문에 업무 만족도가 항상 떨어져 있다. 여기에 갑회사에게 온갖 갑질을 당하다보면 당연한 듯 다들 지쳐서 회사를 그만두게 되지만, 다시 SI로 회기하는 사람들도 존재한다. 역시나 학습능력이 현저히 떨어지는 것으로 보인다.

때로는 오랫동안 살아남는 경우가 있는데, 이때는 오랜 경험을 바탕으로 훌륭한 꼰대가 되기도 한다.

3. SI의 진행과정

3-1. 프로젝트 수주 단계

프로젝트를 따오는 단계이다. 갑회사가 프로젝트를 던지며 보통은 프로젝트를 수주하기 위한 조건들을 던지지만, 보통은 일반적인 내용들과 어디서 주워들은 신기술에 관한 내용들이다. 하지만 보통은 현업들은 자신들이 뭘 만들어야 되는지 어떻게 만들어야 되는지 감도 못 잡고 있는 상황이므로 제대로 된 조건은 달린것이 딱히 없다.

3-2. 인력할당 단계

수행사에서 실제로 투입될 인력을 뽑고 때로는 프리랜서를 투입하는 단계이다. 물론 개발자들은 가기 싫어하기 때문에 수행사에서는 이 프로젝트가 잘 되면 돈을 많이 받아서 연봉을 올려주는 등 대우해주겠다고 뻐꾸기를 날려보지만 대부분 당한 것이 있기 때문에 믿지 않는다.

3-3. 투입 및 개발환경셋팅 단계

인력이 투입되고 개발환경을 셋팅하는 단계이다. 본래는 일주일내로 셋팅이 끝나야 되지만 항상 일정을 넘기기 일쑤다. 현업은 보안을 핑계로 항상 늦게 장비를 셋팅하며, 때로는 개발공간까지 제대로 셋팅해주지 않는 경우도 있다. 하지만 시간은 흘러가고 개발기간은 한정되어 있기 때문에 그 기간만큼 결과물은 구려진다.

3-4. 개발 기획 기간

개발을 위한 기획을 진행하는 기간이다. 수행사가 이런저런 합리적인 개발방안과 기획을 내놓지만, 갑회사가 뻰찌를 놓는 기간이다. 하지만 사실 갑회사는 자신들이 이 프로젝트를 통해 만들려고 하는 것인지 청사진은 고사하고 개념조차 없으므로 그냥 일단 뻰찌놓다가 기분이 좋을 때 오케이 하는 것일 가능성이 높다. 자신들이 뻰찌 놓는 그 기간의 소비만큼 개발기간이 줄어들므로 결국 결과물이 그만큼 구려진다는 기본상식도 모르는 우매함을 드러내는 기간이다.

3-5. 개발 기간

진짜 개발이 진행되는 기간이다. 본래는 상당히 길어야 되는 기간이지만 앞에서 까먹은 기간이 있기 때문에 상당히 짧아져 있는 상황이다. 이 상황을 타개하기 위해 야근과 주말출근을 하게되는데 결국 이는 개발효율을 떨어뜨리므로 오히려 마이너스 효과만 존재한다. 당연히 갑회사의 비어있는 머릿속에는 이런 기본상식은 존재하지 않으며, 수행사는 이런 사항을 알지만 면피용으로 야근과 주말출근을 장려하게 된다. 물론 그로 인한 마이너스 효과로 인해 오히려 개발기간 동안 나오는 결과물은 더 구려지게 된다.

3-6. 테스트 기간

현업이 실제로 결과물을 접하는 기간이다. 그리고는 자신들의 생각과는 다른 모습에 그들은 반발하고 수정을 요구하는 기간이기도 하다. 분명 개발자들은 기획대로 동작하는 결과물을 내놓았음에도 불구하고 수정을 요구하는 것을 보면 현업이 위쪽의 기획 기간에 기획서를 제대로 보지 않고 그냥 기분이 좋을 때 오케이 했다는 것이 명확하다.

본래는 결과물에 대한 오류를 찾아내고 수정하는 기간이지만, 결국은 수정개발에 기간을 소비하게 된다. 물론 오류를 수정하기는 커녕 점점 늘어나게 되며, 내부 코드 또한 엉망이 된다.

3-7. 유지보수 기간

이론적으로는 딱히 할일이 없는 기간이다. 하지만 이미 엉망이 된 결과물이기에 수많은 오류가 발견되고 급한 일정에 엉망이 된 코드때문에 하나를 고치면 사이드 이펙트가 10개가 발생하는 아름다운 상황이 발생한다. 점점 코드는 누더기가 되어가며 어느정도 보이는 문제를 수습하게 되면 거대한 쓰레기가 된다.

그리고 프로젝트에 지친 개발자가 이 기간동안 회사를 그만두고 이직하는 경우가 허다하다. 물론 그 이전에 엉망이 된 코드를 제대로 파악하고 있는 사람은 해당 개발자이므로 수많은 사람들은 멘붕하게 되고 이는 큰 혼란으로 이어지기도 한다.