1.
중소SI들이 낮은 영업이익에 허덕이는 이유는을 읽으면서 든 생각을 적어봅니다. 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산업생태계를 위해서도 상생점수는 양보할 수 없는 부분이다.
아마도 ‘중소SI SW기업 협의회’를 만든 이유를 설명하네요.
기업인7: 프리랜서 문제를 어떻게 할 거냐도 굉장히 중요한 부분이다. 정직원을 100% 둘 수 없는 게 현실이다. IT서비스산업의 가장 큰 딜레마는 계약 가동률과 투입 가동률의 편차가 크다는 거다. 계약 가동이 되면 회사가 걱정할 일이 없다. 그런데 어쩌다 보니 사람이, 공수가 모자라고 그러면 투입 가동을 맞추기위해 프리랜서를 쓴다. 우리 회사는 3년전부터 프리랜서를 안 쓰고 있다. 악성 프리랜서 하나가 들어오면 우리 직원 전체가 오염된다.
서로 담배 피우면서 “야 너 얼마 받냐?”부터 시작해 별별 이야기를 하면서 정규직 사기를 떨어트린다. 프리랜서들은 “코딩만 잘하면 된다, 나머지는 관심 없다. 문서화와 현업과 협의는 너희가 해와라”는 식이다. 이런 행태이기 때문에 프로젝트에 책임을 지지 않으려 한다. 또 프리랜서가 도망가는 시점이 언제냐면 단위통합할 때가 가장 심하다. 그들이 떠난 후 우리 직원들이 열어보면 처음부터 다시 시작해야 하는 경우도 많다. 프리랜서가 약자인지 다시 생각해봐야 한다. 질 나쁜 프리랜서를 안 쓰는 문제를 어떻게 해결할 지에 대한 고민이 필요하다.
기업인8: 프리랜서들이 원하는 단가는 기본적으로 3년 차가 월 500만 원, 또 8년 차나 9년 차 되면 기본적으로 1천만원을 달라고 한다. 하지만 그들이 그만큼의 성과를 내느냐는 퀘스천마크다. 질 나쁜 프리랜서 한 명 때문에 프로젝트 전체가 망가지는 경우도 있다.
기업인9: 우리도 미국처럼 프리랜서를 평가, 알려주는 곳이 있으면 좋겠다. 미국에는 ‘업워크(UPWORK)’라는 프리랜서 평가 시스템이 있다. 프리랜서 문제만 해결해도 우리 수익성이 나아질 것으로 생각한다. 우리 회사는 자체적으로 그동안 우리가 썼던 프리랜서 100여명명을 분석한 데이터를 갖고 있다. 프리랜서 중 테스트할 때 도망가는 사람들이 많은데 이들이 말하는 핑계도 정말 가지가지다.
저도 같은 경험을 많이 했지만 채용하는 회사가 해결할 문제입니다. 회사의 수익을 위해 고용을 유연화하는 것이고 그렇지만 프리랜서가 없으면 프로젝트를 수주할 수도 없는 것 또한 현실입니다. 어렵지만 프리랜서가 담당하는 업무를 명확히 하여 위험을 낮추거나 대안을 마련하는 것말고 선택지가 없을 듯 합니다. 하여튼 프리랜서의 문제가 아니라 발주사의 문제입니다.
2.
저는 제안요청서를 무척 중요히 생각합니다. 성공 혹은 실패 혹은 분쟁의 씨앗을 모두 제안요청서에 있다고 생각합니다. 2017년 자료라 현재를 반영하지 못할 수도 있지만 공공SW사업 발주관리의 현황, 문제점, 개선방안중 핵심이라고 생각한 부분입니다.
또 공공부분의 경우 제안요청서를 어떻게 작성하는지 찾아보니까 2022년 자료가 있습니다. 공공 소프트웨어 사업 제안요청서 작성 예시 제작 배포에 올라온 예시입니다.
항상 보던 제안요청서입니다. 요구사항 총괄표가 무척 중요할텐데 앞서 발주관리의 문제점으로 지적한 부분을 극복할 수 있는 예시는 아닌 듯 합니다. 보기에 형식 혹은 Template일 뿐입니다.
