내가 SI를 혐오하는 이유
소프트웨어 개발자 이해하기 - SI는 소프트웨어를 망친다.
SI라는 말을 들어본 적이 있는가?
System integration (SI) is an IT or engineering process or phase concerned with joining different subsystems or components as one large system. It ensures that each integrated subsystem functions as required.
사전적 정의는 요구되는 서브 시스템들을 잘 아울러서 큰 시스템을 구축/구현하는 일련의 프로세스를 말한다. 그런데 우리나라에서 이 SI를 몇 바퀴 뛰다 보면, 정말 재능 있는, 똑똑한 멋있는 소프트웨어 개발자가 할 일은 아니라는 생각을 하게 된다.
공공기반 프로젝트부터 대기업발 프로젝트까지 소위 SI 프로젝트의 비용은 주로 소프트웨어 개발자의 노임단가로 계산을 한다.
예를 들어 공공기관이 배달의 민족 같은 앱을 만든다고 치자. 이런 SI 프로젝트의 단가는 투입 인력 X 투입 인력의 단가 X 시간으로 계산이 된다.
자, 이제 이런 프로젝트가 실패할 수밖에 없는 이유를 짚어보겠다. 제공사의 이해.
해당 서비스를 제공하는 개인 또는 회사의 이윤은,
받을 돈(매출) - 투입인력 X 투입인력의 단가 X 시간
자, 여러분이 여기서, 이윤을 극대화할 수 있는 요소를 짚어보자.
- 받을 돈을, 아주 크게 책정한다. 이 프로젝트가 우리만 할 수 있다거나, 독점적인 기술이라, 수위계약이 가능하다면 이 부분을 늘리는 일은 가능하다. 하지만, 이게 어디 쉬운가? 또한, 지불자는 그 근거를 찾고자 한다. 왜 내가 더 많은 받을 돈을 책정해야 하는가?
- 두 번째 옵션은 투입인력의 퀄리티를 낮추는 방식이다. 우리나라 노임단가는 보통 학위인데 여러분... 대학 중퇴지만, 100인분을 하는 개발자와 박사지만, 서비스를 일도 못 개발해 봐서 0.5인분을 하는 팀원이 존재한다. 이럴 때 이윤을 극대화하려면, 노임단가가 높은 팀원을 이름만 올리고 실제 제품은 구현돼야 하니, 다른 이면계약을 해서, 프리랜서를 쓴다거나 투입시간을 허위로 기재하는 방식이 가능하다.
위 표는 sw 기술자 평균임금이다.
- 감히 단언컨대, 저 스펙이, 연차나 학위로는 계산될 수가 없다.
- 모든 평균임금은 객관적인 지표로 학위나 지표로 증빙하게 되어 있다. 그렇다면 제공사로서는 높은 스펙의 사람을 이름만 올리고, 뒤로 많은 사람을 쓰는 게 당연하지 않을까?
어쨌건, 투입인력의 단가와 시간이 Fair 하다고 치자. 그럼, 이 프로젝트가 성공하려면?
- 완벽한 기획이란 존재할 수 없다. CD를 구워 팔던 시절도 아니고 요즘의 서비스나 앱들은, 실시간 커밋으로 오류를 고치고, 더 나은 이용자 경험을 제공하는 게 성공의 지름길이다.
- SI 업체나 개인의 수익구조는 투입인력과 시간이므로 이미 비용이 지불된 서비스에 1도 리소스를 쓸 이유가 없다. 오류가 발견되거나, 더 나은 이용자 경험을 제공하기 위해서는? 별도 프로젝트 발주를 해야 한다.
발주사의 이해를 알아보자
발주사의 이익은 아래와 같이 정의될 수 있다.
줄 돈(- 값 지불 비용) + 절감 효과(기대 이익)
우선 많은 IT 프로젝트가 있지만, 절감 효과나 기대이익을 정확히 계산하기란 불가능하다.
그렇다면, 내 이익의 최대치는 줄 돈(지불 비용)을 절감하는 데 있다.
저 회사가 시간을 안 지키는지, QA버그 패치를 안 하는지, SLA(Service Level Agreement)에 도달하지 않는지를 통해서, 최대한 줄 돈을 낮추는 게 저들의 이해다.
검수의 함정을 알아보자. 제한된 인력, 제한된 시간으로 서비스를 마무리하기 위해서, 검수사는 흠집 찾아내기에 주력한다. 서비스의 성공따위 여기서 증빙하기도 어렵고(아직 오픈을 안했으니까), 흠집을 찾아서 지급 시기를 늦추고 가격을 깎는게 실무자들의 이해다.
IP의 함정
간혹 SI를 하면 소스코드까지 인계받아서, 우리가 운영할 수 있을 것이라는 착각을 쉽게 할 수 있다.
돌아가는 코드는 존재하지만, 그 코드가 계속 버그 패치되고, 기능 추가가 되며, 안정적으로 운영되기 위한 인수인계를 누가 받을 것인가?
내 개인 경험상, 개발자라면 100이면 100, 똑똑하면 똑똑할수록, 남이 짠 shit를 읽어보기는 싫어하는 게 정상이다. s/w코드를 구매했거나, 오픈소스를 사내에 도입하고 싶어서 리더가 git repo를 따와서 개발자에게 전달했다고 치자. 이 경우, 개발자 반응은, '제가 새로 짜는 게 나을걸요?' 다.
- 이유는 Code 문법은 있지만, 대부분 코딩 스타일 코딩 Convention이라는 게 있다. 내가 즐겨 쓰는 개발 Convention(변수명은 이렇게 쓰고, method는 이렇게 정의하고 등등)이라는 게 있다. 즉 코딩 스타일이라는 게 있다는 얘기다.
- 남이 열심히 고민해서 만든 코드를 읽고 이해하기 귀찮다. 스펙만 알면 내가 새로 짜는 게 여러모로 편리하다. 요즘 유행하는 언어들은 주로 Object Orientied 하거나, Funcitional Language 가 대부분인데, 남이 짠 코드를 쫓아가며 이해하다 보면, "나는 누구? 여긴 어디?을"라는 질문이 생기게 된다.
- 그냥 똑똑한 개발자라면, 시간보다, 내가 도전해서 짜고 싶다. 사실, 개발이 불가능한 일이란 존재하지 않는다. 다만, 내 커리어를 늘리고, 내가 할 수 있는 일을 더 많다고 어필하기 위해서, 내가 스스로 짜는 게 같은 시간을 투자할 거면 더 낫다고 생각한다. 예를 들어, 난 '카카오 싱크' 개발을 해봤어 라거나, '나는 구글 텐서 플로우로 자연어 처리 엔진을 구현해봤어' 이 말에 따라서 내 몸값이 달라진다.
아무튼 결론은 결과물 소스코드를 받는다고 정말 IP(지적재산권)을 인계받는다고 생각하는 건 잘못된 생각이다. 받아도 개발자가 관심을 가지고 해당 소스 코드를 고치고, 배포하고 모니터링하고 가 병행되지 않는다면 그건 죽은, 혹은 현재 버전 import 받는 것과 동일한 얘기다.
개발자 초년생 시절, 내가 Daum이라는 회사를 다닐 때 SI도 해본 적이 있다. 하지만, 거기서 코드 검수라는 건 정말 코미디였다. 1줄도 못 바꾸면서 코드를 받는 게 무슨 의미가 있을까?
지적재산권이란 행사할 수 있을 때 의미가 있지 않을까?
유지보수비용의 함정
뭐, 그래도 fair 하게 계약을 어찌어찌 마무리했다고 가정하자.
유지보수 계약이라는 계약을 별도로 맺게 된다. 위의 공급사와 발주사의 이해를 종합해 보면 유지보수를 위해 1도 좋은 개발자를 배정할 가능성은 낮아진다.
1억짜리 프로젝트를 완료하고 매달 100만 원의 유지보수비를 요구하는 회사를 예로 들어보자.
자, 이 회사는 덜 유지보수 리퀘스트를 받는 게 유리하다. 어차피 가격은 정해지는 거다. 심지어 우리나라 대기업들은 무상유지보수 6개월, 1년을 천연덕스럽게 주장한다.
발주사는 사실 여러 업체를 썼을 수 있기 때문에, 내부 IT관리자가 어디가 문제인지 알 수 있다면 좋겠지만, 그런 IT관리자가 없는 업체들이 주로 SI프로젝트들을 쉽게 생각하고 벌인다.
그래서 B2B영업을 많이 해본 MS, Oracle은 한달에 수천만원씩 유지보수 비용을 받는거다.
작은 업체라면 그러기 힘들기 때문에 유지보수 요청이 적으면 적을 수록 유리하고, 내 탓이 아니라고 책임 전가가 유리하다. 내부에 좋은 IT관리팀이 없다면 차라리 유지보수 비용을 넉넉하게 책정하라. 그래야 서비스가 결함으로 부터 빠르게 벗어나고 더 좋은 서비스를 구현할 수 있게 된다.
맺으며
중간에 브런치 글이 날아갔다. 긴 글 쓰기 귀찮아서 책하나 추천하면서, 맺고자 한다. 지속가능한 살아있는 소프트웨어를 만들고 유지하고자 한다면 결국 그 소트웨어를 만드는 사람들을 만들어야 한다. 내가 정말 좋아하는 책, 피플웨어로 일단 맺음.
근데 브런치 쓰다가 글이 날아갔다. 이런 걸 고치는게 브런치 개발팀이 할 일이다!
http://www.yes24.com/Product/Goods/13657193
