실무자가 알려주는 실패 없는 SI업체 선정 기준과 리스크 관리법

SI업체 계약 시 흔히 범하는 실수와 눈에 보이지 않는 비용들

새로운 시스템을 도입하거나 업무용 프로그램을 개발할 때 가장 먼저 고민하는 지점은 결국 외부 조력을 어디까지 받을 것인가로 귀결된다. 많은 기업이 SI업체 선정을 단순히 기술력을 사는 과정으로 오해하곤 하지만 사실상 이는 우리 조직의 업무 프로세스를 타인에게 이식하는 고도의 협력 과정에 가깝다. 단순히 포트폴리오가 화려하다고 해서 덜컥 계약을 체결했다가는 나중에 유지보수 단계에서 예상치 못한 비용 폭탄을 맞기 십상이다.

업계에서 흔히 발생하는 실수 중 하나는 투입 인력의 숙련도를 문서로만 확인하고 실제 면담을 생략하는 경우다. 제안서에는 특급 개발자가 투입된다고 적혀 있지만 정작 프로젝트가 시작되면 주니어급 인력들이 코딩을 전담하고 시니어는 관리만 하는 상황이 발생한다. 이런 불일치는 개발 속도 저하뿐만 아니라 나중에 코드를 수정하거나 기능을 확장할 때 구조적인 결함으로 이어진다. 결국 초기에 아낀 비용보다 더 큰 수습 비용이 발생하는 악순환이 시작되는 셈이다.

비용 산정 과정에서도 함정은 존재한다. 단순히 개발 단가만 따질 게 아니라 도입 이후의 운영 비용까지 포함된 총소유비용을 계산해야 한다. 우리나라 주요 SI업체들의 평균 PER이 약 8배에서 10배 내외로 형성되어 있다는 점을 고려하면 이들이 제시하는 단가는 어느 정도 시장 표준을 따른다. 하지만 표준보다 지나치게 낮은 금액을 제시하는 곳은 일단 경계하는 것이 좋다. 인건비 중심의 비즈니스 구조상 낮은 단가는 필연적으로 인력의 질 저하나 과도한 추가 비용 요구로 돌아오기 마련이다.

내부 개발 조직 구축과 SI업체 외주 활용의 기회비용 비교

직접 개발자를 채용해서 내재화할 것인지 아니면 전문 SI업체에 맡길 것인지에 대한 고민은 정답이 없는 문제처럼 보이기도 한다. 하지만 프로젝트의 성격과 기간을 따져보면 의외로 답은 명확해진다. 일시적인 시스템 구축이나 특정 시기에만 집중되는 개발 수요라면 외주가 압도적으로 유리하다. 개발자 한 명을 채용하는 데 드는 리크루팅 비용과 퇴직금, 4대 보험 등 부대비용을 따져보면 전문 업체에 외주를 주는 것이 오히려 예산 집행의 유연성을 높여준다.

반면 비즈니스의 핵심 로직이 수시로 변하거나 데이터 보안이 무엇보다 중요한 경우라면 내재화를 고민해야 한다. SI업체는 프로젝트 기간이 끝나면 철수하기 때문에 이후 발생하는 미세한 요구사항 변화에 기민하게 대응하기 어렵다. 협력사와 일할 때는 사소한 UI 변경 하나도 변경 계약이나 추가 공수 산정의 대상이 되지만 내부 조직은 즉각적인 피드백 반영이 가능하다는 점이 가장 큰 차이다. 시간 대비 결과물의 완성도를 생각하면 단기 성과는 외주가, 장기 운영은 내재화가 유리한 편이다.

결국 리소스 배분의 문제로 귀결된다. 안드로이드 스튜디오를 활용한 모바일 앱 개발처럼 특정 기술 스택에 특화된 인력을 상시 보유하기 부담스럽다면 해당 분야의 숙련된 SI업체를 파트너로 두는 게 합리적이다. 다만 이때도 모든 것을 맡기기보다는 요구사항 정의서와 기획안만큼은 내부에서 철저히 준비해야 한다. 우리가 무엇을 만들고 싶은지 모르는 상태에서 외부 전문가의 손에만 의지하는 것은 항해사 없이 배를 띄우는 것과 다를 바 없다.

신뢰할 수 있는 SI업체 선별을 위한 4단계 검증 프로세스

좋은 파트너를 찾는 과정은 생각보다 까다롭고 많은 시간이 소요된다. 우선 첫 번째 단계로 기업의 재무 건전성과 업력을 확인해야 한다. 최소한 법인 설립 후 3년 이상 경과했는지와 기업 신용평가 등급이 B+ 이상인지를 따져봐야 한다. 프로젝트 도중 업체가 자금난으로 흔들리면 개발 중단은 물론이고 이미 지급한 중도금까지 회수하기 어려워지는 최악의 상황이 발생할 수 있기 때문이다.

두 번째 단계는 유사 프로젝트 수행 실적을 직접 확인하는 절차다. 단순한 목록 나열이 아니라 우리가 구축하려는 시스템과 유사한 규모와 도메인 지식이 필요한 작업을 해봤는지가 핵심이다. 가령 금융권 시스템 통합 프로젝트라면 보안 가이드라인 준수 경험이 필수적이고 이커머스라면 대규모 트래픽 분산 처리 경험이 있는지를 물어야 한다. 관련 레퍼런스 사이트를 직접 방문해보고 속도나 사용자 편의성을 직접 테스트해보는 수고를 아끼지 말아야 한다.

세 번째로는 실제 투입될 핵심 인력과의 인터뷰를 진행해야 한다. PM과 리드 개발자가 우리 비즈니스의 언어를 이해하고 있는지 확인하는 과정이다. 기술적인 용어로만 답변을 늘어놓는 사람보다는 비즈니스 요구사항을 기술적으로 어떻게 구현할지 논리적으로 설명하는 전문가를 찾아야 한다. 이 단계에서 소통이 원활하지 않다면 프로젝트 내내 의사소통 오류로 인한 재작업이 반복될 확률이 매우 높다.

마지막 네 번째 단계는 사후 관리 체계에 대한 확답을 받는 것이다. 개발 완료 후 무상 유지보수 기간은 보통 1년이 표준이지만 이 기간 내의 지원 범위가 어디까지인지 명확히 해야 한다. 단순 버그 수정뿐만 아니라 운영 중 발생하는 경미한 수정 사항에 대해서도 지원을 약속받는 문구를 계약서에 명시해야 한다. 이 네 단계를 거치지 않고 이름값이나 지인 추천으로 업체를 고르는 것은 도박이나 다름없다.

프로그램 개발 단가 산정과 유지보수 조건 협상 시 주의사항

견적서를 받아보면 소프트웨어 노임단가를 기준으로 계산된 숫자들이 보일 것이다. 하지만 이 숫자만 보고 비싸다거나 싸다고 판단해서는 곤란하다. 개발비 산정 방식은 크게 투입 인력의 수와 기간을 곱하는 M/M 방식과 기능의 복잡도를 수치화한 기능점수 방식으로 나뉜다. 최근에는 요구사항이 가변적인 경우가 많아 기능점수 방식이 더 객관적이라는 평가를 받지만 공공기관이 아닌 민간 영역에서는 여전히 M/M 방식이 주를 이룬다.

유지보수 비용은 통상 전체 개발 비용의 10%에서 15% 사이에서 결정되는 것이 관례다. 만약 시스템의 복잡도가 높거나 24시간 실시간 모니터링이 필요하다면 이 비율은 20%까지 올라가기도 한다. 여기서 중요한 것은 유지보수의 범위다. OS 업데이트에 따른 호환성 패치나 간단한 텍스트 수정은 포함되지만 새로운 기능을 추가하는 것은 별도의 개발 건으로 처리된다는 점을 명심해야 한다. 이 경계를 명확히 설정하지 않으면 나중에 업체와 감정 싸움을 벌이게 되는 원인이 된다.

또한 시스템 안정화 기간을 최소 90일 이상 확보하는 조건으로 협상해야 한다. 개발 완료 직후에는 발견되지 않던 잠재적인 오류들이 실제 사용자들이 접속하기 시작하면서 쏟아져 나오기 때문이다. 이 안정화 기간에 PM이 상주하는지 혹은 원격으로 즉시 대응이 가능한지를 체크해야 한다. 비용을 조금 깎는 것보다 이런 안정 장치를 하나 더 마련하는 것이 장기적으로는 훨씬 이득이다.

우리 조직의 디지털 전환 속도에 맞는 최적의 파트너 찾기

모든 기업이 대형 SI업체와 일할 필요는 없다. 대형사는 체계적인 프로세스를 갖추고 있지만 그만큼 의사결정이 느리고 관리 비용이 높게 책정된다. 반대로 규모가 작은 업체는 유연하고 단가가 저렴하지만 인력 이탈 시 프로젝트 연속성이 떨어진다는 치명적인 약점이 있다. 결국 우리 프로젝트의 규모와 예산 그리고 내부에서 관리할 수 있는 역량에 맞춰 적정 수준의 파트너를 고르는 지혜가 필요하다.

기술은 계속해서 변하고 한 번 구축한 시스템은 영원하지 않다. SI업체는 그 변화의 과정에서 징검다리 역할을 해주는 존재일 뿐이다. 업체에 모든 것을 의지하기보다는 협업 과정에서 그들의 노하우를 흡수하고 우리 것으로 만드는 노력이 병행되어야 한다. 그래야만 나중에 업체가 바뀌거나 독자적인 운영 체제로 전환할 때 시행착오를 줄일 수 있다.

가장 먼저 해야 할 일은 과학기술정보통신부에서 제공하는 소프트웨어 개발 표준 계약서를 꼼꼼히 읽어보는 것이다. 업계의 표준적인 권리와 의무가 무엇인지 알아야 협상 테이블에서 불리한 조건을 걸러낼 수 있다. 지금 당장 눈앞의 개발 환경이 안드로이드 스튜디오인지 자바인지 따지기에 앞서 우리 비즈니스의 본질을 가장 잘 이해해 줄 파트너를 찾는 안목을 기르는 것이 우선이다. 만약 내부 기획 역량이 전혀 없는 상태라면 무작정 개발 업체를 찾기보다 기획과 컨설팅을 먼저 수행할 전문가를 찾는 것이 훨씬 생산적인 순서다.