지난 16일 아이티센그룹 산하 쌍용정보통신이 2022년 실적을 발표했다. 회사 발표에 따르면 지난해 매출 3252억원에 영업이익 97억원을 기록했다. 영업이익이 매출액의 3% 정도다. 다른 SI(시스템통합, 일명 IT서비스) 기업들도 영업이익이 이 수준이다. 중견과 중소SI들의 영업이익은 5%를 넘으면 '많은 수준'이다.
매출만 보면 국내 최대 SI라 할 수 있는 삼성SDS도 마찬가지다. 최근 열린 주주총회에서 2022년 실적을 공개했는데, 매출액 17조 2347억원에 영업이익이 9161억원이였다. 삼성SDS도 영업이익이 매출액의 6% 정도 밖에 안된다. 직원에 월급을 주고 좋은 복지제도를 운영하며 미래를 준비하기 위한 연구개발을 하려면 영업이익이 10%는 돼야 한다. 매출이 300조가 넘는 삼성전자도 영업이익이 지난해 10%가 넘었다.
국내 SI기업들의 영업이익은 왜 이리 낮을까? 이의 해답을 알려주는 행사가 지난 10일 열렸다. 이날 한국프레스센터에서 대기업 참여 제한 완화에 반발한 일부 중소SI·SW기업들이 모여 협의회를 결성하고 사업대가 정상화를 요구했다. 이들이 제기한 공공SI시장의 사업대가 문제점들을 무명으로 정리했다.
기업인1: 제일 급한 게, 제일 우선으로 해결해야 할게, 발주자인 공무원들이 발주만 해놓고 책임을 안지는 문제를 해결해야 하는 거라고 생각한다. 근본적인 이 문제를 풀지 않고 가는건 잘못된 접근 방식이다.
기업인2: 경제적으로 우리보다 더 후진 인도를 5~6년전 방문한 적이 있다. 당시에 오프쇼어(해외인력 사용 개발) 인력이 부족해 인도 IT 회사인 위프로를 방문했는데, 참 부끄러운 이야기를 들었다. "너희는 왜 설계가 없냐?"면서 협업을 거부하더라. 대기업이 몇 번 오프쇼어를 시도했지만 성공하지 못한 것도 설계를 그릴 수 없기 때문이다. 한국은 왜 설계가 없나? 생각해봤다. 우리는 수많은 감리를 받으며 많은 설계 산출을 만들어낸다. 그런데 그 설계의 내용이 감리 받을 때만 유효하고 이후 내팽개친다. 설계중요성을 그동안 우리는 많이 잃어버렸다.
그 배경이 뭐냐 하면, 아까 피감기관으로 발주자가 들어와야 한다는 것과 맥락이 같은데, 제작 프로세스에 반드시 발주와 사업자들이 해야하는 역할과 책임이 명시돼야 한다. 그런데 우리는 이걸 안한다. 이 한 축이 무너지다 보니 사항이 확정되지 않고, 또 그 요구 사항이 계속 변하니까 아무리 설계를 해놓은 들 이 설계가 지켜지지 않는 거다. 그동안 우리 엔지니어들도 설계 중요성에 대한 인식이 점점 희박해졌고, 역량을 쌓지도 않았다. 이 부분은 사업대가를 넘어 대한민국 소프트웨어 역량을 높이는데 정말 필요하다. 국내 소프트웨어 산업이 경쟁력을 가지고 내실 있게 성장하려면 과업 확정, 그리고 이것을 컨트롤하는 어떤 책임 있는 기구, 또 여기에 대한 정당한 대가를 보장하는 절차와 제도, 이런 부분들이 마련이 되고 강력히 지켜져야 한다. 그렇지 않으면 소프트웨어 강국은 공염불이다.
기업인3: 앞으로 10년이나 20년간 소프트웨어 생산성 향상을 위해 우리가 어떤 노력을 해야할 지 우리 모두 반성을 해야 한다. 현재는 대부분 코딩만 말하고 있다. 직원도 마찬가지인데, 특히 프리랜서가 더 심하다. 코딩만 잘하면 끝인 줄 착각을 하고 있다. 전체 밸류에서 코딩이 차지하는 비율은 미미하다. 그럼에도 이런 생각을 가지고 있고, 소프트웨어 공학이 실종이 됐다. 요건 정의와 분석 설계를 엑셀이나 파워포인트로 하면 안된다. 도구로 자동화해야 한다. 그래야 소프트웨어 생산성이 올라간다. 고객 업무는 우리가 다 자동화해주면서 분석설계 등 정작 우리가 하는 일은 자동화하지 않고 있다. 오프쇼어링의 핵심은 설명서가 미주알 고주알 MS워드나 파워포인트, 엑셀에 있는 게 아니라 도구로 자동화돼 있어야 한다는 거다.
이걸 정부 예산으로 하기 힘들면 민간사업(민간투자 공공사업)으로 하면 어떨까 한다. 만들어진 후 이걸 쓰는 기업이 적정한 사용료를 내면 된다. 현재 굉장히 큰 차세대 프로젝트 경우 사무실 구하고 개발 환경 세팅하는데만 6개월이나 걸린다. 그러니 일을 할 시간이 부족하다. 클라우드 시대인데, 아마존이나 이런 쪽에 퍼블릭 클라우드 문을 열겠는 것은 굉장히 위험스러운 생각이다. PaaS나 IaaS쪽이 굉장히 발전하고 있음을 감안, 우리가 하는 일도 보다 자동화해 효율을 높여야 한다. 예전 전자정부 프레임을 만들때는 이에 200억원이 들어갔다. 지금은 공학적으로 해야 할 일이 더 많아졌다. 코딩만 봐도 그냥 코딩이 아니라 시큐어 코딩을 해야한다."
기업인4: 차세대(부처의 현 정보화시스템을 대거 업그레이드한 대규모 새 시스템)가 문제되면 그 책임을 왜 중소기업에 돌리는지 모르겠다. 사실 대기업이 다 만든거 아닌가. 대기업이 반성을 많이 했으면 좋겠다.
기업인5: SW를 생산할 수 있는 인력은 점점 줄고 있다. 혁신을 하기 위해서는 어쨌든 SW 생산 기술을 발전시켜야 한다.
기업인6: 1만개로 추정되는 국내 IT서비스 기업 중 대기업과 중견기업은 100곳도 안 된다. 99%가 중소기업이란 의미다. 이에, 상생점수에 따른 참여 지분 50%는 전혀 과하지 않다. 그동안 중소기업들은 각자 맡은 분야에서 전문성을 갖추고 IT서비스 산업의 핵심으로 성장했다. 건강한 SW산업생태계를 위해서도 상생점수는 양보할 수 없는 부분이다.
기업인7: 프리랜서 문제를 어떻게 할 거냐도 굉장히 중요한 부분이다. 정직원을 100% 둘 수 없는 게 현실이다. IT서비스산업의 가장 큰 딜레마는 계약 가동률과 투입 가동률의 편차가 크다는 거다. 계약 가동이 되면 회사가 걱정할 일이 없다. 그런데 어쩌다 보니 사람이, 공수가 모자라고 그러면 투입 가동을 맞추기위해 프리랜서를 쓴다. 우리 회사는 3년전부터 프리랜서를 안 쓰고 있다. 악성 프리랜서 하나가 들어오면 우리 직원 전체가 오염된다.
서로 담배 피우면서 "야 너 얼마 받냐?"부터 시작해 별별 이야기를 하면서 정규직 사기를 떨어트린다. 프리랜서들은 "코딩만 잘하면 된다, 나머지는 관심 없다. 문서화와 현업과 협의는 너희가 해와라"는 식이다. 이런 행태이기 때문에 프로젝트에 책임을 지지 않으려 한다. 또 프리랜서가 도망가는 시점이 언제냐면 단위통합할 때가 가장 심하다. 그들이 떠난 후 우리 직원들이 열어보면 처음부터 다시 시작해야 하는 경우도 많다. 프리랜서가 약자인지 다시 생각해봐야 한다. 질 나쁜 프리랜서를 안 쓰는 문제를 어떻게 해결할 지에 대한 고민이 필요하다.
기업인8: 프리랜서들이 원하는 단가는 기본적으로 3년 차가 월 500만 원, 또 8년 차나 9년 차 되면 기본적으로 1천만원을 달라고 한다. 하지만 그들이 그만큼의 성과를 내느냐는 퀘스천마크다. 질 나쁜 프리랜서 한 명 때문에 프로젝트 전체가 망가지는 경우도 있다.
기업인9: 우리도 미국처럼 프리랜서를 평가, 알려주는 곳이 있으면 좋겠다. 미국에는
'업워크(UPWORK)'라는 프리랜서 평가 시스템이 있다. 프리랜서 문제만 해결해도 우리 수익성이 나아질 것으로 생각한다. 우리 회사는 자체적으로 그동안 우리가 썼던 프리랜서 100여명명을 분석한 데이터를 갖고 있다. 프리랜서 중 테스트할 때 도망가는 사람들이 많은데 이들이 말하는
핑계도 정말 가지가지다.
관련기사
- 중소SI들, 대기업 참여 완화 반발···"먼저 사업대가 정상화를"2023.03.11
- LG전자, 4개 사업본부 대수술...고객 지향 솔루션 체제로2024.11.21
- "피부 컨설팅 받고 VIP라운지 즐겨요"…체험 가득 '올리브영N 성수' 가보니2024.11.21
- "아태지역, K-콘텐츠가 이끈다"...디즈니, 내년 어떤 작품 선보이나2024.11.21
기업인10: "오버헤드 문제도 짚고 넘어가야 한다. 이 문제에 대해 회사마다 셈법이 다르고 또 프로젝트마다 다르다. 작게는 13%, 많게는 28%까지 차이가 난다. 과거보다 중견이든 대기업이든 오버헤드를 컨트롤할 사람들의 능력과 경험이 굉장히 떨어졌다. 빨리 이 부분을 어느 정도 표준화해 상생하는 방법을 찾아야 한다.
기업인11: 차세대나 대형 프로젝트들이 망가지는 공통적인 부분이 있다. 품질과 공동사업 관리 부분에서 역량이 떨어지는 사람들이 그 자리에 앉아있다는 거다. 전혀 역량이 안 되는 사람들이 그 자리에 있다보니 개발 환경 세팅도 제대로 못하고 6개월, 1년의 시간이 그냥 흘러간다. 그러다보니 중소SW 및 SI들이 실제 개발할 시간이 적어진다. 주사업자가 공통 부분을 만들어줄때까지 기다리지 않고 우리가 먼저 개발하려고 하면 뒤늦게 발주처가 이런거 저런거 참조하라고 주는 경우도 많다. 이런 환경을 빨리 바꿔야 한다."