http://subokim.wordpress.com/2014/06/20/problem-of-si-industry/
SI산업의 문제점
얼마전 최근 IT분야에 들어오신 분이 이런 질문을 합니다.
‘왜 다들 SI가 문제라고 하는건가요?’
글쎄요. 무엇부터 말해야 할지 몰라 선뜻 대답을 하지 못했습니다.
이미 악순환의 고리로 접어들어서 불평할 것들이 너무 많기 때문입니다.
물론 SI 개발자 입장에서 좋았던 부분도 꽤 있습니다.
짧은 경험을 바탕으로 제 생각을 정리해 보았습니다.
IT를 잘 모르는 일반인들의 이해를 위해 쉽게 써보려고 노력했습니다.
SI 프로젝트 현장, 베트남, 어디나 비슷하다.
1. SI 란 (System Integration)
윈도우가 나오기 이전에 IT라는 것은 어떤 기능을 하는 하드웨어를 사는 것이었습니다.
시스템 통합(System Integration)이란 여러 개의 솔루션을 조립하여 납품하는 행위였습니다.
사용자 요구사항을 분석하고 거기에 맞게 소프트웨어를 하드웨어에 넣어서 팔았습니다.
소프트웨어를 만들기도 하고 솔루션과 패키지를 설치해서 팔았습니다.
대부분의 경우가 수작업을 전산화하는 것이어서 비교적 ‘불확실성’이 적었습니다.
‘주민등록관련 업무’나 ‘회계 업무’ 등을 생각하시면 됩니다.
오랫동안 해왔던 업무이므로 기성품을 선택하거나 기능을 새로 만들기도 어렵지 않았습니다.
틀에 박힌 업무여서 납품이 되고 나면 소프트웨어 변경은 거의 없었습니다.
하지만, IT가 발달하자 온라인 비즈니스가 중심에 서기 시작했습니다.
기존에 없었던 새로운 일들을 바로 시스템으로 만듭니다.
어떤 비즈니스는 매일 개발자들의 손으로 돌려야 돌아가기도 합니다.
인터넷 쇼핑몰, 인터넷 뉴스 서비스, 인터넷 뱅킹 서비스 등을 생각하시면 됩니다.
사업 환경이 수시로 변해서 ‘설계 후 개발’을 하는 것도 어려워 졌습니다.
개발이 완료되어도 종료라고 보기 힘들어졌습니다.
‘불확실성’이 높아진 것입니다.
2. SI의 본질이 바뀌다.
초기 SI 회사들은 자동차 공장의 회계시스템과 백화점의 회계시스템이 같다고 생각했습니다.
그래서 기성복을 만드는 것 처럼 시스템과 매뉴얼을 만들고 값싼 노동력을 투입해서 이윤을 만들고자 했습니다. 즉, 건설처럼 ‘비싼 설계’에 ‘값싼 노동력과 자재’를 조달하는 방식입니다.
이것이 아웃소싱 사업의 시작이었습니다.
사업의 규모는 Man Per Month (1달에 투입된 사람수)인 투입되는 개발자 수로 측정했습니다.
너무 많은 일을 싸게 하는 것 같아서 Function Point (기능 난이도, 개발량 등을 점수화) 제도를 도입하기도 합니다.
그러나,둘다 표준화된 노동력을 팔아서 이윤을 남기고자 하는 본질은 같습니다.
수많은 차세대 첨단 프로젝트들이 만들어집니다.
하지만, 많은 프로젝트들이 실패합니다.
자동차 공장의 회계시스템과 백화점의 회계시스템이 많이 달라지게 됩니다.
요구사항을 정의하지 못해서 엉뚱한 걸 개발하기도 합니다.
잦은 변경으로 기일 내에 개발을 못 끝내기도 합니다.
업체는 발주자들이 자신들의 요구사항조차 모른다고 비아냥대기도 합니다.
발주사는 주관 수행업체가 요구사항을 정리하지 못했으므로 책임져야 한다고 합니다.
물론 갑과 을의 능력부족으로 실패하는 프로젝트도 있지만, 뜯어보면 요구사항을 정의하기 힘든 새로운 일들인 경우도 많습니다.
요구사항을 정하고 만들었는데 원하던 결과물이 아니기도 합니다.
설계를 중간에 변경하는 경우도 허다합니다.
따라서, 처음부터 끝까지 베테랑들을 투입할 수 밖에 없습니다.
규격 개발자들을 대량으로 공급해서 이윤을 남기는 사업 방식이 어려워진 것입니다.
SI 회사들은 이렇게 이야기합니다.
“시장에 쓸 만한 개발자들이 없다.”
“개발자 몸값이 높아져서 사업해도 남는게 없다.”
“프로젝트 위험도가 높아서 맨날 적자 본다.”
3. IT현업부서의 개발능력 상실
예전에는 전산실 직원들이 직접 개발을 했습니다.
하지만, IT 시장이 성장하면서 큰 규모의 프로젝트가 계속해서 만들어지게 됩니다.
전산실은 개발부서가 아닌 용역발주부서로 바뀌게 됩니다.
이 기간이 오래 되면서 많은 전산실이 개발능력을 상실해 버리고 맙니다.
이것은 기업들이 기술 주도권을 상실하게 만들었습니다.
SI 회사들은 기업들이 쉬지않고 IT 용역사업을 발주하도록 이슈를 만들어 냅니다.
각 기업들의 IT 비용은 당연히 상승합니다.
기업들은 이렇게 이야기 합니다.
“ 매년 투자를 엄청나게 하는데 뭐가 좋아지는지 모르겠다.”
최근 대기업들은 이런 교훈을 바탕으로 아웃소싱 보다는 자체 개발역량을 보유하는 방향으로 전환하고 있기도 합니다.
4. 갑을병정 생태계
아웃소싱이 없어지지는 않을 겁니다.
모두가 천재일 수 없으므로 부족한 부분에 전문가의 힘을 빌리는 것은 자연스러운 것입니다.
그러나, 재하청구조는 문제가 됩니다.
재하청은 중간 업체가 이윤을 가로채기 때문에 일의 최종 대가는 낮아집니다.
베테랑이 해야 할 일에 초급자를 고용할 수 밖에 없습니다.
두 명 들어가야 하는 일에 한 명을 쓸 수 밖에 없습니다.
베테랑의 실력을 가진 초급자나 두 배 일할 수 있는 개발자를 고용하고자 합니다. (물론 그런 개발자는 없습니다.)
초보자도 기능을 개발할 수는 있습니다.
하지만 오랜 경험을 넣어서 개발할 수는 없습니다.
시행착오가 잦아지니 야근을 할 수 밖에 없습니다.
이것은 나중에 수습해야 할 기술적 부채를 만들어 냅니다.
재하청은 대표적으로 ‘일감 몰아주기’에서 발생됩니다.
하청업체가 자기가 소화할 수 없는 분야를 다시 아웃소싱 하면서도 이윤을 떼기 때문입니다.
일감 몰아주기는 주관업체에게 실패 책임을 묻기는 좋습니다.
발주사가 관리를 하기에도 용이합니다. (한 놈만 패는 거니까)
그러나 여러번 이윤떼기는 실제 일하는 사람에게 제값을 줄 수 없게 만듭니다.
원하는 수준의 전문가와 일할 수 없으므로 이상한 결과물이 나오게 됩니다.
일감 몰아주기가 적어지면 ‘중간업체 살찌우기’가 사라집니다.
그러면, 많은 SI업체들이 인력유통사업의 비중을 줄일 수 밖에 없습니다.
슈퍼을이 되기 위해 고객영업에 집중하는게 불필요해집니다.
높은 값을 받을 수 있는 기술 개발이 더 남는 장사가 될겁니다.(이 이야기를 펼치면 좀 복잡해지네요.)
5. 요약
한마디로 정의하면, 한국형 SI 의 본질은 기술 개발보다는 인력유통 산업에 가깝습니다.
따라서, 고부가가치의 상품이 나오지 않고 학연 지연을 바탕으로 한 영업경쟁만 치열합니다.
당연히 국제적인 경쟁력도 약합니다.
IT 산업분야에서 이런 환경 개선을 위한 자성의 목소리들이 나오고 있습니다.
하지만, 산업적 체질이 변화되기 위해서는 적지 않은 시간이 흘러야 할 것입니다.
제도의 개선과 함께 IT 종사자들의 마인드도 바뀌어야 하기 때문입니다.
SI산업의 문제점 2
시카고의 일용직 근로자 시장
SI산업의 문제점 두번째 이야기입니다.
SI 시장에는 인력소개소 수준의 업체들이 많습니다.
왜 생겼을까요? 여기에 대해 이야기 한 번 해보겠습니다.
정책과 제도는 양날의 검인데 부정적인 효과가 오랫동안 방치되지 않았나 싶습니다.
1. 제도의 부정적 효과가 오래 지속
발주사는 개발의뢰를 위해 제안요청서를 공지합니다.
업체들은 제안서, 제안설명회, 가격입찰서를 통해 수주경쟁을 합니다.
경쟁에서 이긴 업체는 주관업체가 되어 해당 프로젝트를 진행합니다.
당연히 발주사는 믿을만한 업체, 실패를 책임질 수 있는 업체를 원합니다.
어려운 사업일수록 입찰자격은 까다롭습니다.
한 번 자격을 가진 업체는 진입 장벽 안에 서게 됩니다.
자격이 되지 않는 업체는 입찰할 수 없습니다.
입찰할 수 없다보니 자격을 얻을 수 없습니다.
바보같은 쳇바퀴지만 엄연히 존재합니다.
자격이 없는 작은 기업들은 큰 기업을 통해 제품을 납품합니다.
큰 기업들은 자사의 이익을 위해 제품을 헐값에 제공하기도 합니다.
작은 기업은 오히려 치명적인 피해를 입기도 합니다.
자격제도의 폐단입니다.
실제로 꽤 많이 일어나고 있습니다.
SI 주관업체는 항상 충분한 리소스를 가지고 있지 못합니다.
그러다보니 인력파견전문 SI 업체들이 등장하게 됩니다.
많은 SI개발자들이 겪는 사례를 살펴 보겠습니다.
2. 경력 속이기
대부분의 제안사가 선수주, 후수습을 합니다.
프로젝트 제안을 할 때는 자바 개발자 스무명이면 충분히 수행할 수 있을 것 같습니다.
규격화된 개발자가 넘치던 시절의 구축 논리입니다.
하지만 현실은 자바 개발자 스무명을 구하기 힘듭니다.
그래서 아래와 같은 일들이 일어납니다.
1) 초급인데 중급으로 투입
주관업체가 약속된 중급개발자를 못구하는 경우입니다.
경력을 속입니다. 정체가 노출되므로 가능한 침묵하게 됩니다.
커뮤니케이션이 쉽지 않으므로 프로젝트는 힘들고 개인의 멘탈도 무너집니다.
2) C고급자가 java고급자로 투입
자바를 배운지는 1~2년 밖에 되지 않습니다.
언어 숙련도가 낮아 java고급만큼 성과를 내지 못합니다.
커뮤니케이션도 어렵고 개발환경도 잘 이해하지 못합니다.
처음엔 잘 모르고 투입 됩니다만 대부분 중간에 발각됩니다.
안타깝지만 주관업체는 여러가지 이유로 이 길을 선택하거나 선택할 수 밖에 없습니다.
경력속이기는 결국 품질의 하락으로 이어집니다.
대부분 펑크가 나고 PM이 가장 큰 스트레스를 받게 됩니다.
3. 회사 소속 속이기
주관업체가 현재 역량에 비해 초과수주를 한 경우입니다.
즉 영업은 너무 잘 되는데 사업수행 인력이 부족한 경우입니다.
정상적인 경우라면 사업포기를 해야 하는데 현실적으로 그렇게 하기 쉽지 않습니다.
그래서 아래와 같은 일이 일어납니다.
1) 한시적 소속 변경
최근 계약서에는 주관업체 직원의 참여비율을 지정하는 경우가 많습니다.
정직원들의 책임감을 기대하기 때문입니다.
그래서 한시적으로 하청 회사 직원들의 소속을 바꾸어 투입합니다.
하지만 회사 소속감이 없으므로 정직원 수준의 책임감을 기대하긴 힘듭니다.
2) 수행업체 PM으로 투입
심지어 PM을 확보하지 못한 경우도 있습니다.
하청업체 소속이지만 주관업체 PM으로 소개됩니다. 고객을 속입니다.
당연히 권한과 책임을 제대로 행사하기 힘듭니다.
프로젝트는 연속된 이슈와의 싸움인데 모든게 여의치 않습니다.
좌절 속에서 시간을 보내면서 프로젝트는 망가집니다.
개인은 정체성 혼란으로 인한 스트레스가 매우 높아집니다.
하청업체는 회사 이력으로 쌓을 수가 없어 사업자격을 확보할 수 없습니다.
자격조건이 권력화되어 기형적인 구조를 만들어 내는 것입니다.
4. 희생양으로 투입되기
프로젝트 문제가 발생되면 기술부분이 희생양이 되어 아웃소싱하는 경우가 있습니다.
솔루션 문제, 아키텍쳐 문제, DB 문제 등은 거의 단골로 등장합니다.
1) 아키텍트로 투입되었는데 아키텍쳐 문제가 아닌 경우
어떤 문제의 원인으로 아키텍쳐가 지목되었습니다.
그래서 아키텍트로 투입됩니다.
하지만 경험상 정말로 그런 경우는 거의 없었던 것 같습니다.
대부분은 투입되면 기술 이슈 이외 정치적 부담까지 짊어지게 됩니다.
2) DBA로 투입되었는데 어플리케이션 문제인 경우
어플리케이션이 느린 이유는 대부분 SQL Query 때문입니다.
그런데 SQL Query는 전부 어플리케이션에 있습니다.
진단은 DBA가 할 수 있지만, 조치는 DBA가 할 수 없습니다.
DB만 보면 된다고 해서 가보면 아무것도 할 수 없는 경우가 많습니다.
위의 경우는 주관업체나 발주사의 프로젝트 수행역량이 부족하기 때문에 발생됩니다.
프로젝트는 사람을 움직여서 일을 하는 것입니다.
IT프로젝트는 기술도 알아야 하고 사람도 알아야 합니다.
사람에 서투르고 기술에도 서툴러서 생기는 문제입니다.
사람문제는 서로 회피를 하게 되므로 결국 기술만 남아서 기술문제처럼 보이게 됩니다.
5. 왜 문제일까?
위 사례들은 한국적 SI 문화로 이미 오랫동안 자리를 잡았습니다.
그래서 대부분 조용히 별 문제없이 지내왔습니다.
먹고 사는 문제야 해결되겠지만 장기적 관점에서는 문제가 됩니다.
어떤 문제가 될까요?
1) 어디에도 축적되지 않은 경험과 기술
겉으로는 수행업체에 기술력이 쌓입니다.
하지만, 실제로는 어디에도 기술력이 쌓이지 않습니다.
주관업체도 아니고 하청업체도 아닙니다. 발주고객도 아닙니다.
그저 개발자 개인의 경험으로만 쌓입니다.
사회적으로는 별 도움이 되지 못합니다.
사회적으로 가치가 생기려면 경험과 기술이 조직화되어야 하기 때문입니다.
SI 환경에서는 누구도 기술을 올바로 자산화하지 않습니다.
그냥 개발자 노트북에 하나의 개발소스로 존재할 뿐입니다.
2) 아무도 책임지지 않는 구조
실패나 문제에 대한 외형적 책임은 수행업체가 집니다.
돈을 토해내거나 추가 개발자를 투입해서 프로젝트를 정상화합니다.
담당고객은 감봉이나 문책을 당하기도 합니다.
하지만, 책임은 ‘문제를 바로잡는 것’과 ‘재발방지’를 전제로 합니다.
IT가 핵심역량인 비즈니스의 경우 일회성으로 끝나지 않고 계속 프로젝트가 이어집니다.
발주사에 학습시스템이 없으므로 문제는 반복되고 상황은 나아지지 않습니다.
사회적으로 매년 막대한 비용이 전산으로 지출됩니다만 비슷한 사례가 반복되고 아무도 해결할 수 없습니다.
3) 개발자 시장의 붕괴
SI시장에서는 신입 개발자들이 진입할 공간이 없습니다.
개발자 한 명으로서의 역할을 기대하기 힘들기 때문입니다.
SI 시장에서 초급이란 단순작업의 일을 하는 것이지 배우면서 일하라는 의미가 아니기 때문입니다.
주로 개인 단위 고용이라 좋은 사수를 만날 수도 없습니다.
실수나 실패를 완충해줄 팀원들도 없습니다.
즉, 좋은 자질의 인력이 개발시장에 들어와서 성장할 수 없습니다.
팀웍이 낮으므로 높은 협업 생산성을 기대하기도 힘듭니다.
잘 훈련된 사람과 팀은 훌륭한 개발방법론이나 소프트웨어공학보다 몇 배 더 중요합니다.
개인단위 아웃소싱은 사회적 개발역량의 성장을 방해하는 가장 큰 요소입니다.
6. 요약
현재 한국 SI 시장의 큰 문제점은 이런 구조가 넓게 퍼져 있다는 것입니다.
SI 발주물량이 늘어나면 IT회사들은 제품개발보다는 이 구조에 참여하게 됩니다.
생존을 위해서이기도 하거니와 회사 성장이 쉽고 빠르기 때문입니다.
그러나 사회적 IT자산은 쌓이지 않습니다.
10년이 넘도록 솔루션 하나 만들지 못하고 SI 파견만 하는 회사도 꽤 많습니다.
자산이 쌓이지 않으니 부가가치는 생기지 않습니다.
최근 SI 사업이 많이 줄면서 자연스레 이런 업체들이 줄고 있기는 합니다.
하지만 사회적 체질개선이 되었다고 보기는 힘듭니다.
IT가 사업의 핵심역량이라면 그 곳에 시간을 들여서 경험과 기술자산을 쌓아야 합니다.
인력소싱을 유발하는 풀 아웃소싱은 일반적이고 규격화된 결과물을 얻는데는 무난한 선택일 수 있습니다.
하지만, 훌륭한 결과물을 얻기 위해서는 훈련된 정직원 팀을 갖는 것이 기본입니다.
여기에는 시간과 문화가 필요합니다.
종래산업 분야에서 IT의 역할은 점점 커지고 있습니다.
그러나 SI산업에게 IT분야의 씽크탱크 역할을 기대하기 힘들 것 같습니다.
개인이 잘해서 풀릴 것 같지는 않습니다.
제도적, 정책적, 사회적으로 함께 풀어야하는 이슈가 아닐까 싶습니다.
SI 시장이야기
아직도 이런 현장들이 있습니다.
국내 IT시장의 80%정도가 SI시장임을 감안하더라도, 아직 선순환 구조로 접어들고 있지 못하는 답답함이 있습니다. 국내 소프트웨어 시장이 성장하기 위해서는 IT종사자들 스스로의 노력과 함께 정책적 접근도 절실한 시점이 아닌가 생각해봅니다.
2011년 국내 IT서비스기업 매출 순위
사례1) 정상적인 프로젝트라면 이래야?
이번 일은 높은 가치 생산성이 있다.
구축하고 나면 현장업무의 생산성이 두 배로 높아질 것이다.
하지만, 만들어야 하는 것이 규격화되어 있지 않기 때문에 패키지를 이용하긴 힘들다.
직접 모든 걸 개발하는 SI 비용은 비싸다.
하지만, 투자비용보다 더 높은 부가가치를 만들거라 믿기 때문에 예산을 받아낼 수 있었다.
충분한 비용을 가지고, 훌륭한 개발업체의 도움을 받아 시스템을 만들었다.
시스템이 생산성을 높여 회사고객을 더 만족시켰다.
사례2) 어떤 프로젝트 이야기
업체가 적자를 본다.
범위 대비 많은 인력과 시간이 투입되었다.(사실 예상되었던, 들어가야할 비용이 들어갔다.)
원래 무리한 계획과 목표였다. (무리한 요구였다.)
무리하지만, 누군가 할 수 있다고 했다.
누군가는 무리하지 않다고 했다. (영업이겠지)
누군가는 예산이 작아 그 일을 하기에는 무리라고 생각했다. (“갑” 님이겠지.)
“갑”은 윗사람을 제대로 설득하지 못했다.
“갑”은 그 일이 정말 회사에 이로운 일인지는 모르겠다.
그러나, “갑”은 그 일을 평가시즌 이전에 꼭 끝내야겠다고 생각했다.
그 일이 “갑”의 진급과 성과에 중요한 영향을 끼친다.
사례3) 적자 프로젝트의 뒷편
“을”이 적자를 본다.
“갑”이 적자 보전을 위해 2차 프로젝트에 과다예산을 상정한다.
하지만, “갑”은 과다예산에 맞는 새로운 목표를 회사로부터 받는다.
“을”이 다시 적자를 보고 일을 한다.
“을”이 망한다.
결국 “갑” 회사는 “을” 회사의 돈을 빼앗아서 발전하는 거다.
돈 바치고, 몸 바치는 “을” 회사는 미친 거?
계속 이런 악성 프로젝트 물어오시는 사장님. 직원들 생각 좀 했으면.
이런 상황 모르고, “내가 돈주는 거”라고 착각하는 “갑”님은 미친 거?
그 돈은 당신 회사가 당신에게 빌려주는 돈이라고.
당신은 그 돈으로 “을” 회사와 힘을 합쳐 회사가 만족할 결과물을 만들어 내야 하는 거라고.
회사 돈을 쓸 때는 책임이 뒤따르는 법!!!
사례4) 시장이야기, 언제쯤 이렇게 될까?
시장에 SI 업체들이 넘쳐난다.
공급이 많아서, 가격이 자꾸 내려간다.
수지타산이 맞지 않아 업체가 망한다.
개발자가 죽어난다. (일정도 힘들고, 사람 수도 적다.)
대졸자들이 개발을 기피한다. 시장에 개발자가 없다.
SI 업체가 점점 줄어든다.
오랜 시간 후 이제는 SI 업체 찾아보기도 힘들고, 가격도 비싸다.
SI 하려면, 알기도 많이 알아야 하고 경험도 많아야 해서 경쟁률이 빡세다.
사례5) 시장이야기, 요즘 좀 이런 트렌드?
기업들의 부가가치 생산성이 낮아진다.
낮은 비용으로 적당한 효율을 올리고자 한다.
SI는 비싸니, 패키지나 플랫폼을 이용하려고 한다.
시장에 패키지나 플랫폼을 제공하고 A/S 해주는 회사가 많다.
적당한 패키지를 골라, 우리 회사에 맞는 적당한 제품을 만든다.
현장에 적용해서 우리 고객을 만족시키고 협업 생산성을 올린다.
사례6) 어떤 개발자 이야기
대학교 4년 다니는 동안, 동아리에서 개발해본게 전부.
우연히 손재주 있는 친구를 만나 전산과 실습으로 개발해본게 전부.
취직 전에 멀티캠퍼스에서 자바개발 초급과정 들어본게 전부. (스스로 위안을 삼고자)
작은 회사에 취직. 선배가 개발하는 거 어깨너머로 보고 요령을 익힘.
아 저렇게 하면 되는군.
그렇게 3~5년을 보냄.
개발 요령이 점점 늘어난다.
“이론은 없고, 경험만 있을 뿐.” (이론 없는 경험은 발전이 없다.)
발전은 없고, 계속 사이트를 떠돈다.
이런게 개발자 인생인가?
해외 유명개발자들도 이렇게 사나?
이런 개발자 손에서 만들어진 제품은 유지보수비용이 계속 더 들어간다.
요즘 오라클이 인수한 몇몇 회사 제품이 이렇던데…
(Technical Sales, 실제 현장에서 이런 멋있는 화면은 거의 연출되지 않는다.)
