원래 오래전부터 몇차례 반복했던 이야기라서 다시 비슷한 내용의 글을 쓸 생각은 없었지만, 관련 주제로 정부에 제안을 한다니 혹시 SI 시장의 문제점을 바로잡는데 조금이라도 기여할 수 있지 않을까 하는 기대감에 글을 올려봅니다.

이미 이전 토론글들을 보셨던 분들께는 양해 부탁드리겠습니다.

SI 시장의 문제에 대해서 이야기 하기 위해 우선 가장 근본적인 사실을 하나 지적하고 싶습니다.

우리나라 SI 개발자들이 겪는 어려움으로는 과도한 야근과 주말 근무, 개발자 공급 과잉으로 인한 인건비 하락, 불합리한 갑을 관계 등 매우 다양한 문제점을 나열할 수 있을 것입니다.

물론 이를 개선하기 위해 각각의 문제에 대한 개별적 해법을 제시할 수도 있을 것입니다. 예컨대 과도한 하도급을 제한한다던지, 야근과 주말근무 수당 미지급에 대한 처벌을 강화한다던지 하는 정책을 통해 어느 정도 문제를 완화할 수도 있을 것입니다.

하지만 이런 식의 대응으로 우리나라 SI 시장의 고질적인 모든 병폐들이 완전히 해소되기를 기대하는 것은 불가능하다고 생각합니다. 왜냐하면, 앞서 언급한 잘못된 관행들은 보다 근원적인 문제로 인한 현상이지 원인이 아니기 때문이고, 원인을 해결하지 않고 현상 완화만을 목표로하는 어떤 정책도 대증적 처방 이상의 효과를 가져오긴 어렵기 때문입니다.

예컨대 미국에서 노동집약적이고 열악한 근무환경의 SI 프로젝트를 우리나라에서 처럼 자주 접할 수 없는 이유는 미국에는 국비지원 IT 학원이 없거나 소프트웨어 하도급 자체를 원천금지하기라도 해서는 아닐 것입니다.

중요한 것은 이 모든 잘못된 관행들은 우리나라의 SI 시장이 왜곡되서 발생하는 것이고, 더 줄여서 말하면 한 마디로 '시장의 문제'라는 것입니다.

왜 미국에서는 우리나라 같이 초급 개발자를 갈아넣는 식의 인력지향적 프로젝트를 흔히 볼 수 없을까요? 법으로 초급 비율을 규제해서? 아니, 애초에 미국에서 '초급 개발자'이라는 인위적인 기준이 존재하기는 할까요?

정답은 시장의 성격이 다르기 때문입니다. 미국에서 제대로 된 IT 인프라를 갖추는 것은 기업의 경쟁력과 직결된 문제라는 인식이 보편적이고, 따라서 기업들은 그런 시스템 구축을 외주로 개발하더라도 일정 수준 이상의 품질을 요구합니다.

그런 수요가 있는 시장에서는 당연히 '싸고 빠르게'만 내세우는 한국식의 외주 개발 업체들이 발붙일 곳이 없습니다. 우리나라의 SI개발에 해당하는 외국의 아웃소싱 개발업체들이 광고에서 '우리 회사는 EJB의 메시징 빈 개발에 노하우를 가지고 있다' 같은 문구를 내세우는 것도 그런 내용을 보고 외주 업체를 평가하는 고객의 요구가 있기 때문일 것입니다.

그럼 우리나라 기업들은 왜 IT 시스템을 구축할 때 외국처럼 품질에 대한 까다로운 요구 조건을 내세우지 않고 싸고 빠르게 만들 수 있는 업체들만 찾는 것일까요?

그건 '그래도 되니까', 혹은 '남들도 그렇게 하니까'입니다. 미국에 비해 IT 인프라가 형편없고 구축 및 유지보수 비용이 많이 들어도, 다른 경쟁업체들도 비슷하게 비효율적이라면 큰 문제가 되지 않을 것입니다. 국제 경쟁력이 떨어진다면 외국보다 조금 더 하청업체를 쥐어짜고 직원들을 오래 야근 시키면 되는 것이니 큰 문제로 느끼지 못할 수도 있을 것입니다.

이전에 몇 차례 자바로 기업 시스템을 구축하면서 객체지향적 설계를 전혀 시도하지 않는 이상한 우리나라식의 관행에 대해 비판한 적이 있습니다만, 그 원인도 따져보면 마찬가지로 국내 고객들이 잘 설계된 비즈니스 API를 회사의 핵심 자산이라고 인식하지 못하기 때문입니다.

반면에 대부분의 기업에서 데이터베이스는 매우 중요하게 생각하고 있고, 스키마 설계나 운영을 위한 프로세스를 만들고 전문 인력을 배치하는 등의 노력을 하고 있습니다.

그렇기 때문에 핵심 자산인 데이터베이스는 놔두고 고도화다 뭐다 신규 프로젝트를 할 때마다 '중요하지 않은' 자바 계층은 값싼 인력을 투입해서 빠르게 만들고 빠르게 갈아 엎는 것입니다.

그렇게 보면 결국 모든 문제의 핵심은 기업 고객들이 자신들 회사의 IT 인프라를 구축하는 데 있어서 국제 기준에 맞는 기술 동향과 기술 수준을 요구할 수 있도록 유도할 수 있는지 여부가 될 것입니다.

사실 이는 그렇게 불가능한 일도 아닙니다. 돈을 벌기 싫어하는 경영자는 거의 없기 때문에, 우리나라에서도 어떤 기업이 특정 IT 시스템이나 방법론을 도입해서 가시적인 이득을 얻었다면 당장 그 기업의 경쟁사들이 앞다투어 뒤를 따를 것이기 때문입니다.

아마 경력이 많은 개발자분들은 이전의 ERP 시스템 도입 열풍을 기억하실 지 모르겠습니다. 국내에서 아무도 ERP를 쓰지 않는다면 굳이 내 기업이 먼저 돈을 쓰고 시행착오를 겪을 필요는 없다고 생각하는 경영자는 많을 것입니다. 하지만 일단 경쟁사가 ERP를 도입해서 가시적인 성과를 냈는데도 끝까지 수작업을 고집할 경영자는 거의 없을 것입니다.

예컨대 우리나라가 이전의 애자일(Agile),혹은 데브옵스(DevOs) 열풍에서 무풍지대로 남아있는 것도, 그리고 아마도 지금의 리액티브(Reactive) 열풍에 대해서도 앞으로도 그럴 것으로 짐작되는 것도 이들 흐름이 ERP 열풍과 같은 현상을 일으키기 위한 임계점에 다다르지 못했기 때문일 뿐입니다.

그렇게 보면 정부가 해야할 일은 간단합니다. 즉, ERP 도입 같은 연쇄반응을 일으킬 수 있는 환경과 '촉매'를 제공하는 것입니다.

예컨대 지금의 국가가 직접 개발자의 '등급'을 산정하고 초급 개발자를 양산하는 정책에서, 해외 기업들의 우수 IT 인프라 구축 사례와 기술 동향을 기업의 IT 담당자에게 소개하고 적절한 시스템 구성과 개발 방법론을 제시할 수 있는 컨설턴트와 아키텍트를 키워내는 방향으로 전환하는 것도 어느 정도 도움이 될 것입니다.

지금 공공 기관 프로젝트들에서 어떤 식으로 해외 사례를 참조하는 지 모르겠습니다만, 아마도 단지 어떤 프레임워크나 어떤 WAS 제품을 도입하는 지 정도를 넘어서 구체적으로 그 위에서 어떤 식으로 서비스 API를 구성하고 어떤 프로세스로 개발 및 운영을 하는지에 대한 보다 구체적인 그림을 요구한다면 수주업체들도 그런 부분에 보다 신경을 쓸 수 밖에 없을 것입니다.

어쩌면 그런 아키텍처나 설계 방법, 혹은 개발 및 운영 방법은 정부가 세세하게 관여하기보단 감리제도를 대폭 강화해서 그에 대한 검증을 시장에 위임하는 것도 좋은 대안이 될 것으로 생각합니다. 이미 건축 분야에서 적용 중인 교차 감리제도를 도입해서 특정 규모 이상의 프로젝트에서는 반드시 설계와 감리를 분리해서 발주하도록 제도화하고, 감리의 경우 문서와 같은 지엽적인 내용보다는 앞서 이야기한 아키텍쳐나 방법론 등에 대해 국제 경쟁력을 가질 수준의 기준을 충족하는 지 여부까지 확인하도록 하는 것도 한 가지 방법이 될 수 있습니다.

이런 접근이 다소 추상적이라면 당장 시도해볼 수 있는 내용도 있습니다. 예컨대 지금은 많은 프로젝트에서 요구하는 성능이나 보안 관련 체크리스트는 십 년 쯤 전에는 쉽게 찾아볼 수 없는 관행이었습니다.

만일 개발 및 운영 프로세스에 있어서 이슈 트래커의 활용도, 테스트 커버리지, 빌드 및 배포 자동화 시스템 구축 여부, 코드에 대한 정적 분석 결과, 브랜치 관리 정책, 최신 버전의 라이브러리 및 SDK 사용 여부, 마일스톤 관리, 개발 진척도에 대한 가시적인 측정 지표의 존재 여부, 패키지의 추상화 정도 또는 순환참조 발생 빈도, 잘 정의된 비즈니스 API의 존재 여부 등 현 시점 국제 기준에서 좋은 소프트웨어 시스템 구축을 위해 감안하는 기준들을 지표로 만들어서 체크리스트로 관리하면 지금의 비효율적인 주먹구구식 운영을 하는 빈도가 상당히 감소할 것으로 기대합니다.

만일 정부가 보다 직접적인 형태로 시장에 개입할 생각이라면, 이러한 지표를 바탕으로 지금의 개발자 경력 관리 시스템 대신 외주 개발 업체들의 기술 역량을 정량화해서 관리하는 것도 고려해볼만 합니다. 프로젝트 완료시 언급한 것과 비슷한 공통 지표에 따라 수행 업체들의 역량을 평가하고, 이를 입증할 수 있도록 소스나 커밋 기록, 이슈관리 시스템의 백업 정보 등을 보존하게 해서 부적절한 평가가 있었는지 주기적으로 감사하고 반면에 높은 평가를 받은 업체에 단가나 수주에서 유리한 요소를 마련해주는 것이 한 가지 방법이 될 수 있습니다.

보통 잘못된 정책이나 사회 구조로 인한 문제로 인해 다수가 피해를 받더라도 그로 인해 이익을 보는 기득권 세력이 있을 경우 쉽게 고칠 수 없는 경우가 많습니다.

그렇게 보면 오히려 우리나라 SI 시장의 경우 오랜 기간 심하게 왜곡된 시장 구조적 문제로 인해 여러 잘못된 관행들이 고착화되는 결과를 낳기는 했습니다만, 정부의 올바른 문제 인식과 해결 의지만 있다면 생각보다 쉽게 상황을 개선할 수 있는 환경이기도 합니다.

왜냐하면 앞서 언급한 다른 사회적 문제들과 달리, SI 시장 구조의 문제로 인해 이익을 보는 것은 오직 중간 인력 중개업체들일 뿐이고, 시장에서 가장 높은 지위에 있는 고객들 역시 개발자들과 마찬가지로 피해를 보는 입장이기 때문입니다.

만일 그런 기업의 경영자들이 지금의 잘못된 관행들로 인해 얼마나 많은 생산성 손실이 발생하는지 깨닫는다면, 혹은 선구적인 경쟁사가 그런 문제를 개선해서 얼마나 큰 경쟁력을 확보할 수 있었는지를 알게된다면, 아마도 그 다음부터는 과거 앞다투어 ERP 시스템을 도입하듯 누가 시키지 않아도 그런 관행을 척결하기 위해 노력할 것이라 기대합니다.

정부가 할 일은 고객들이 이 문제를 조금 더 빨리 깨닫기 위한 조언을 하는 것이고, 무조건 값싸고 빨리 프로젝트를 끝내는 업체가 아니라, 이러한 문제에 대한 해답을 알고 있는 업체들이 살아남을 수 있는 시장 환경을 조성하는 것입니다.

그리고 이는 우리나라 기업들이 해외 기업들에 대해 적어도 대등한 IT 경쟁 역량을 갖추도록 돕는 일이기도 하고, 동시에 IT를 '3D 업종'이라고 자조적으로 부르는데 익숙한 소프트웨어 개발자들이 낮은 급여와 과도한 업무에 시달리는 대신 보다 안정적 환경에서 기술력을 연마할 수 있도록 하는 일이기도 합니다.

우리나라에서 소프트웨어 개발자, 그 중에서도 특히 SI 개발자들이 막노동 일꾼 취급을 받는 것은 초등학교에서부터 프로그래밍을 가르치지 않아서, 또는 조금 더 철저하게 국가에서 개발자 등급을 관리하지 않아서가 아니라 단지 시장에서 단순 작업 이상의 기술력을 요구하는 일거리를 찾아보기 힘들기 때문입니다.

과도한 하도급 구조나 만성적인 야근 및 주말 근무 관행 등은 모두 이와 같은 근본 문제에서 파생된 현상일 뿐입니다.

좋은 소프트웨어를 만드는 일은 공장 생산라인에서 자동차를 찍어내는 것과 근본적으로 다른 종류의 일입니다. 만일 기술력을 전혀 모르는 인력 중개 업체에 몇 단계씩 하도급을 주거나 6개월 학원 수강을 마친 개발자를 모아서 아무런 교육없이 경력을 속여 투입하는 식으로 좋은 소프트웨어를 만들어낼 수 있다면 아마 외국에서도 한참 전부터 그런 방식으로 윈도우즈나 안드로이드 같은 제품을 개발하고 있었을 것입니다.

결국 문제의 근원은 기업들이 좋은 소프트웨어의 가치를 알고 어떻게 하면 이를 만들 수 있는지 깨닫게 하는 것이고, 저는 그것이 바로 우리나라의 잘못된 SI 시장 관행을 해소하기 위해 정부가 해야할 가장 중요한 일이라고 생각합니다.