공공 SW 사업의 기술성 평가 기준과 운영 절차

공공 SW 사업에서 기술성을 평가하는 이유

정부와 공공기관의 소프트웨어 사업은 국가 인프라와 연결되는 경우가 많고, 상당한 예산도 투입된다. 계약 과정에서는 사업자의 수행 역량과 제안 기술이 사업 목적에 맞는지를 가격 외의 기준으로 검토할 필요가 있다.

소프트웨어 기술성 평가는 소프트웨어 산업 진흥법 제20조 제3항을 근거로 공공부문 SW 사업 계약 시 적용되는 평가 기준이다. 상용 SW 도입과 정보시스템 기획·구축·운영에 필요한 기술 역량을 객관적으로 확인하기 위해 마련됐다. 저가 수주 경쟁을 줄이고, 기술 중심으로 고품질 시스템과 건전한 SW 산업 생태계를 만들려는 제도적 장치이기도 하다.

발주기관은 고시된 기준을 토대로 사업 특성에 맞는 세부 평가 항목과 배점을 조정한다. 평가는 기능 보유 여부만 확인하는 절차가 아니다. 기술의 사업 적합성, 성능과 품질 보장 방안, 프로젝트 관리 역량을 함께 검토한다.

평가 기준이 지향하는 공정한 계약 구조

기술성 평가는 검증된 기술력을 갖춘 사업자를 선정해 시스템의 안정성과 성능을 확보하는 데 목적이 있다. 표준화된 지표는 평가 과정의 투명성과 신뢰성을 높이는 기반이 된다.

또한 우수 기술을 보유한 중소기업과 품질 인증 기업을 우대해 기술 개발 의욕을 높이고 산업을 육성하려는 취지도 담고 있다. 최근 기준 개정은 공정 경제와 SW 산업의 상생 협력, 특히 하도급 구조 개선과 중소 SW 기업 보호에 초점을 둔다.

공공 SW 사업에서 다단계 하도급은 수익성 악화와 품질 저하로 이어질 수 있다. 이를 줄이기 위해 하도급 계약이 적정하게 설계됐는지를 평가하는 항목이 신설됐다. 이는 현장 개발자의 처우와도 맞닿아 있다.

GS(Good Software) 인증 등 공인된 품질 인증을 획득한 제품이나 기업에는 가점을 부여해 소프트웨어 신뢰성을 높인다. 국내에서 상용 SW를 직접 개발·공급하는 중기(중소기업)를 우대하는 기준은 외산 소프트웨어 의존도를 낮추고 국내 SW 생태계의 자생력을 강화하기 위한 것이다.

구축 제안과 상용 제품을 보는 관점

기술성 평가는 기술제안서 평가와 상용소프트웨어 평가로 나뉜다. 사업 성격에 따라 한 영역을 선택하거나 두 영역을 함께 적용할 수 있다.

정보시스템 구축·운영 사업의 기술제안서 평가는 사업자의 수행 역량과 실행 계획을 중심으로 판단한다.

• 전략 및 방법론: 사업 이해도, 추진 전략, 개발 방법론의 적정성
• 기술 및 기능: 요구사항 분석의 정확성, 아키텍처 설계, 구현 방안
• 성능 및 품질: 목표 성능 달성 방안, 품질 보증 체계, 테스트 계획
• 프로젝트 관리: 일정 관리, 리스크 관리, 의사소통 관리 등 수행 체계의 안정성
• 프로젝트 지원: 기술 전수, 교육 지원, 유지관리 방안
• 상생 협력 및 하도급 계약의 적정성: 중소기업 참여 비중, 하도급 계약 구조의 공정성

별도 구축 없이 완제품으로 도입하는 상용 SW는 제품 자체의 품질 특성을 중심으로 평가한다. ISO/IEC 25010 기반 항목에는 기능성(Functionality), 신뢰성(Reliability), 사용성(Usability), 효율성(Efficiency), 유지보수성(Maintainability), 이식성(Portability)이 포함된다.

기능성은 사용자 요구사항을 정확히 수행하는 기능의 완비성을, 신뢰성은 특정 조건에서 고장 없이 수준 높은 성능을 유지하는 능력을 본다. 사용성은 이해·학습·조작의 용이성, 효율성은 자원 사용 대비 성능의 최적성과 관련된다. 유지보수성은 수정과 업그레이드의 용이성을, 이식성은 하드웨어나 운영체제 환경 변경 시 설치의 용이성을 평가한다. 여기에 벤더사의 기술 지원 역량과 사후 관리 체계도 공급업체 지원 항목으로 검토한다.

RFP에서 확정되는 평가의 골격

기술성 평가는 발주 전 RFP 준비와 제안서 평가의 흐름으로 운영된다. 발주기관은 공고 전에 사업 특성에 맞는 평가 기준을 구체화해야 한다.

먼저 평가 부문과 평가 항목을 설계하고, 항목별 평가 기준과 등급을 정한다. 수, 우, 미, 양, 가와 같은 등급별 점수 부여 기준도 이 단계에서 수립한다. 이후 기술 점수(보통 90점) 안에서 항목 중요도에 따라 배점을 배분하고, 내부 검토를 거쳐 기술성평가기준을 확정한다. 발주계획서와 제안요청서는 상급 부서나 심의 위원회 승인을 받은 뒤 공고를 준비한다.

공고 이후에는 확정된 평가 기준과 등급 체계를 공고문에 명시하고 제안서와 부속 서류를 접수한다. 제안사별 자가점검표를 통해 제출 내용이 평가 항목에 어떻게 반영됐는지도 확인한다. 외부 전문가로 구성된 기술평가위원회는 제안 발표(PT)와 서류 평가를 진행하며, 항목별 점수를 합산하고 가점·감점 요인을 반영해 최종 순위를 결정한다.

⤢✕

평가 점수가 실제 품질로 이어지려면

기준이 마련돼 있어도 평가의 실효성은 운영 방식에 따라 달라진다. Cloud, AI, Microservices 등 복잡해지는 최신 IT 기술을 정확히 판단할 수 있도록 평가위원의 전문성을 확보해야 한다.

제안사 간 점수가 유사하게 형성되는 점수 상향 평준화도 과제다. 기술적 차별성을 드러낼 수 있는 정교한 평가 지표가 필요하다. 평가 당시 제안한 기술적 약속이 실제 수행 단계에서 얼마나 이행됐는지 모니터링하고, 그 결과를 이후 사업 평가에 환류하는 체계 역시 보완돼야 한다.

기술성 평가는 공공 SW 사업의 사업자 선정 절차를 넘어 품질과 공정 경쟁 환경을 만드는 기반이다. 하도급 적정성 평가와 품질 인증 우대가 제안서 평가, 수행 단계의 사후 관리와 연결될 때 제도는 더 실질적으로 작동한다.

Sources

• 과학기술정보통신부 고시, 소프트웨어 기술성 평가기준
• 소프트웨어 산업 진흥법 제20조 및 시행령
• 한국지능정보사회진흥원(NIA), 공공 소프트웨어 사업 발주 가이드라인
• ISO/IEC 25010 시스템 및 소프트웨어 품질 모델 표준