05.28
뉴스홈 > 비즈니스IT
SW 사업대가 산정방식‘기능점수’방식이 능사 아니다
/제도화와 전문가 양성이 핵심
/제3의 범위관리자 제도 도입과 SW 분리발주 제도 시행해야

좌장
김현수 국민대 교수

토론자
황인수 삼성SDS 수석
남기찬 서강대 교수
민성기 시스템체계공학원 원장
최창학 정부혁신지방분권위원회 전자정부팀 국장
심기보 한국수력원자력 부처장
이윤성 SK C&C 상무

때 : 2004년 7월 9일
장소 : 여의도 전경련회관

Function Point 활용과 SW사업 합리화 국제 컨퍼런스가 지난달 9일 전경련 회관 국제 회의장에서 열렸다. 정통부가 주최하고 한국정보기술원가표준원과 한국소프트웨어진흥원이 주관한 이번 컨퍼런스는 국내에서는 처음 개최된 Function Point(FP : 기능점수) 관련 국제 행사로 다양한 주제가 발표되어 눈길을 끌었다.
이번에 발표된 주제는 FP의 국제 동향 및 미래 전망, 국제 활용사례, FP를 활용한 SW 프로세스 개선방안, 요구사항 변경 관리 개선방안, SW 프로젝트 견적 개선방안, SW개발지 산정 기준의 개선, SW유지보수 비용산정 방안, 정보화 사업의 합리적인 비용분석 및 통제방안 등이다.
특히 이번 컨퍼런스에서는 IT 입찰 계약ㆍ대가산정 효율화 방안을 주제로 산학연 각 분야의 전문가들이 참여한 토론회도 열려 FP 적용을 위해 해결해야할 과제를 비롯해 합리적인 소프트웨어 사업대가 산정 방안에 대한 논의가 이뤄졌다. FP는 ‘기능’을 바탕으로 SW 사업대가를 산정하는 방식으로 국내에서도 올해 2월부터 본격 시행에 들어갔다.
박시현 기자 pcsw@infotech.co.kr

김현수 먼저 국내 소프트웨어 사업 합리화 방안을 주제로 황인성 수석의 발제를 듣겠습니다.

제3의 범위관리자 제도 도입
소프트웨어 분리발주제 시행 필요

황인성 한국 소프트웨어 산업의 자화상은 몇 가지로 요약할 수 있습니다. 우선 소프트웨어의 가치 인식에 정부가 앞장서야 한다는 목소리가 높습니다. 이는 거꾸로 말하면 그동안 정부가 앞장서지 못했다는 반증입니다. 우리나라의 SW나 SI 산업은 재벌 주도로 되어 있어 중소기업들이 강점을 갖고 있는 소프트웨어 분야에서 제 역할을 할 수 없는 구조입니다.
우리나라는 아직도 소프트웨어를 전략적인 접근 보다는 한건 두건 파는 데 치중하는 느낌이 있습니다. 소프트웨어는 개발 당시에 가치가 나타나는 것이 아니라 사용을 통해서 서비스를 통해 나타나는 것입니다. 그런데 소프트웨어 산업이 개발에만 치중해 유지보수를 소홀히 하는 경향이 있습니다.
소프트웨어 개발 프로젝트는 유지보수를 포함해 자주 사용자의 요구가 바뀝니다. 그렇지만 이를 무비판적으로 받아들이고 통제의 방법도 없습니다. 그래서 전반적으로 소프트웨어가 품질의 하자가 있다는 얘기들이 많이 나옵니다.
2004년 6월 9일 정통부장관이 대통령께 보고한 것을 보면 우리나라의 IT 산업의 성장세가 OECD 국가중 1위라는 내용이 있습니다. 하지만 소프트웨어를 바라볼 때 얼마만큼 피부에 와 닫는지 모르겠다는 느낌이 듭니다.
소프트웨어 산업 육성을 위해 정부에서 노력하고 있습니다. 재경부, 산자부, 외교통상부 등 5개 부처는 공동으로 SI 산업 활성화 정책을 발표한 바 있습니다. 전문성이나 품질 경쟁력 향상, 공정경쟁 기반 확립, 수익성 제고 등에 노력하겠다는 내용이었죠.
이런 것들은 소프트웨어 사업 합리화 즉 Function Point(기능 점수)를 활용해 소프트웨어 사업을 합리화하는데 매우 관련이 있는 내용입니다.
오늘 토론하는 내용은 입찰과 계약, 대가 산정 부문입니다. 소프트웨어 산업을 좀더 합리적이며 공정한 경쟁 구도로 만들어가는 것이 소프트웨어 산업이 살 수 있는 길이 아니겠습니까. 이 차원에서 몇 가지를 제안하고 싶습니다.
먼저 사업대가 기준이 기능점수로 바뀌었습니다. 이를 얼마나 정확하게 측정하느냐가 매우 중요합니다. 이것은 예산 산정과 직결돼 있으며, 앞으로 소프트웨어 사업 발주자와 수주자간의 이견을 조정하는데 핵심적인 역할을 수행할 것입니다.
그래서 기능점수 기반의 예가 산정 전문기관이라는 제도가 도입되어 활성화되었으면 하는 생각이 듭니다.
소프트웨어 개발에서 변경에 관한 문제, 즉 요구 변경으로 인한 프로젝트의 정상화가 어렵다는 지적이 많고, 그런 고통을 우리가 겪고 있습니다. 요구사항 변경을 효과적으로 할 수 있는 제 3의 범위관리자 제도를 도입해 명확한 기준선을 확립하고 진행 중에 변경을 통제할 수 있었으면 합니다. 다시 말해 프로젝트를 성공적으로 끝날 수 있도록 조정 역할을 하는 제 3의 범위관리자 제도를 마련해야 한다는 얘기입니다.
지금 소프트웨어 발주 방식은 먼저 ISP를 하고 이어 개발(분석, 설계, 구축) 부문을 발주하는 과정으로 되어 있습니다. ISP가 단순 계획 수립에 끝나지 말고 개발에 필요한 물량을 산정하는 수준 즉 분석까지 수행해 요건을 정의했으면 합니다. ISP 및 분석, 구현(설계, 구축) 부문으로 나누어 발주하는 즉 소프트웨어 분리발주 제도를 시행하는 것이 필요합니다,
또 하나 중요한 것이 있습니다. 아무리 요구사항이 변경됐다는 것을 인지했다고 하더라도 국가 계약법상에 변경 계약을 용이하게 할 수 있는 메커니즘이 확립이 되어야 하는데 소프트웨어 분야는 미흡하다는 지적이 많습니다. 국가계약법상에 변경 계약을 용이하게 할 수 있는 조항을 신설하는 것이 필요합니다.
소프트웨어 사업대가 산정 모델의 마련이 시급합니다. 향후에는 ITO 사업이나 유지보수, 운영이 강화될 것으로 보입니다. 소프트웨어는 서비스를 통해 그 가치를 인정받을 수 있습니다. 유지보수 비용, IT0 사업대가의 합리적인 산정 방식이 필요하다고 생각합니다.

김현수 남기찬 교수가 소프트웨어 사업 입찰 계약과 문제점, 타개방안에 대해 말씀해 주시겠습니다.

FP는 측정 기법일 뿐, 제도화가 필요
남기찬 이번 세미나의 주제도 그렇듯이 최근의 주요 이슈는 Function Point(기능 점수) 입니다. 그런데 한가지 묻고 싶습니다. 만일 Function Point 기법을 사용하면 지금까지 있었던 입찰 제도의 문제들이 모두 해결될 수 있느냐는 겁니다.
Function Point는 측정하는 기법이지 그 자체가 제도는 아닙니다. 어떻게 도입해야 하느냐는 부문에 많은 노력을 새로 기울어야 한다는 사실입니다.
얼마전 어느 사업 제안서 평가를 한 모 교수를 만난 적이 있습니다. 이 교수의 말에 의하면 업체들이 Function Point를 기준으로 예산 금액을 산정해 제안서를 제출했답니다. 여기서 재미있는 사실은 요구 사항은 하나도 나오지 않았는데 이미 Function Point는 나왔다는 것입니다. 더욱 재미있는 것은 사업자 선정은 이것과 별개로 진행되었다는 겁니다.
제대로 제도를 마련하지 않고 도입하면 그 효과를 볼 수 없다는 겁니다. 제 3의 공정한 기관, 거기에 맞는 제도적 보완, 전문가 육성을 반드시 준비해야만 합니다.
Function Point는 스콥 관리(Scope Manage- ment)입니다. 기존 프로젝트 관리는 비용, 일정만을 관리하는 것입니다. 이제는 Function Point를 도입해 스콥 관리를 같이하는 것입니다. 스콥관리를 통해 프로젝트 규모가 늘어났느냐, 아니면 줄어들었느냐 이에 따라 프로젝트 비용을 비례적으로 조정하는 것이 필요합니다.
Function Point의 목적은 측정이 아닙니다. 좋은 소프트웨어 개발의 수단입니다. 거기에 걸맞는 제도와 전문가를 양성해야 Function Point의 효과를 발휘할 수 있을 것입니다.

김현수 민성기 원장이 소프트웨어 사업대가기준의 실상과 문제점 및 발전방안에 대해 말씀해 주시겠습니다.

타당성ㆍ위협ㆍ리스크ㆍ비용대 효과 분석 선행해야

민성기 1989년 소프트웨어 대가산정기준이 제정된 이후 여러 차례 기술발전과 환경변화에 따라 개정되어 왔습니다. 그러나 SW개발규모에 대한 산정방식이 일관성이 없는 ‘본수방식’을 고수해 왔으며, 비현실적인 대가산정 보정계수적용 및 저렴한 데이터베이스 구축비 문제 등으로 공공발주기관과 산업계 사이에 적지 않은 논란이 계속되어 왔습니다.
이를 개선하는 노력의 일환으로 지난 1994년 Function Point 방식을 삽입해 둔 채 이를 시행하지 못하다가 10년이 지난 올해 2월에 드디어 이를 적용하도록 한 것은 무척 반가운 일이라 여겨집니다. 이제 대가산정에 좀더 객관적이고 일관성 있는 길이 열려졌습니다. 과거 소프트웨어 업체들의 끼어 맞추기식 대가산정이나 충분한 요건분석 없이 계약을 체결한다든지, 계약 후 잦은 요건변경에 따른 지체상금 발생에 대한 논란이 없어지기를 희망하고 있습니다.
그러나 기본이 갖추어져 있지 않은 우리에게 이러한 국제표준이 과연 잘 적용되어 질수 있을지 매우 걱정스럽습니다. 그 기본은 무엇일까요.
첫째, 사용자 관점에서 해야 할 일을 바르게 알고 제시해야 한다는 점입니다. 이와 관련된 활동은 곧 RFP를 내기 훨씬 이전 기획단계에서 시작해야 합니다. 우리는 먼저 무엇이 왜 필요한지를 분명하게 정의해야 합니다. 이를 위해 실현 가능성을 짚어 보기 위한 타당성 분석도 해야 합니다. 각종 대안별 비교분석도 해야 합니다. 뿐만 아니라 위협분석, 리스크 분석, 비용대 효과분석 및 절충분석을 통해 해야 할 일을 바르게 도출해야 합니다.
우리는 이러한 과정을 통해 프로젝트를 제기하지 않은 채, 필요성과 사업의 전후방효과를 중심으로 한 경제성분석에 매달려 있다는 사실입니다. 이일을 위해 선진국은 전 사업비의 3~5%를 투자하고 있습니다. 그런데 우리는 0.1%도 투자하지 않고 있습니다.
둘째, 이렇게 도출하고 나면 이를 스펙으로 만들어야 합니다. 우리가 아는 운용개념서(OCD)와 요건규격서(SRS)를 작성해야하는 것이죠. 이를 근거로 RFP를 내고 계약을 해야 합니다. 그런데 부실한 규격내용으로 위험이 큰 리스크를 그대로 안고 계약을 하고 있습니다. 이것이 바로 부실로 연결되는 첫번째 고리입니다. 곧 요건 품질이 문제라는 겁니다. 비교적 스펙을 많이 작성해 온 전문업체들도 최초 스펙은 대개 50점 정도라는 사실을 유념해야 합니다. 이를 위험이 적은 90점 이상의 로우 리스크(low risk)로 만들어야 합니다.
셋째, 개발자 관점에서 해야 할 일을 바르게 수행할 수 있어야 합니다. 즉, 기능을 분석하여 필요한 기능인지 아닌지 분명하게 식별해야 합니다. 바로 여기에 오늘 우리가 다루고 있는 Function Point가 좀더 분명하게 분석된다는 것이지요. 오늘날 우리는 코드 수(line of code) 위주의 단가산정 때문에 얼마나 무리하게 이를 늘려 왔는지를 스스로 물어 보기 바랍니다. 앞서간 개발자나 선진 업체들이 제시한 단가에 우리 스스로 길들여져 있지나 않은지, 아니면 엔지니어링 보다 훨씬 값싼 프로그램 코딩비용에 단가를 매어 놓고 있지는 않았는지요.
요건품질을 올리고 기능분석을 통한 꼭 필요한 기능을 도출할 수 있어야 국제경쟁력이 생겨 납니다. 이를 위해 구체적인 발전방향 3가지만 말씀 드리겠습니다.
첫째, 좋은 시스템을 갖추기 위해서는 먼저 요건이 바르게 도출되어야 합니다. 또한 바르게 도출되었는지를 검증하고 확인할 수 있어야 합니다. 제 3의 기관이 이를 위해 충분한 준비기간과 예산을 투입해야 합니다. 전 예산의 3~5%를 투자해야 합니다. 준비없이, 투자 없이 프로젝트를 무조건 시작해 놓고 보는 일은 없어져야 합니다. 이렇게 준비해 놓고도 변경과 재설계가 발생하기 때문에 최근 우리는 spiral model을 적용한 리스크 계약방법을 쓰고 있지 않습니까. 더 이상 사전 분석이 안된 사업은 추진하지 말아야 합니다.
올해 초에 정부사업 상위 30개의 cost overrun이 11조에서 33조로 되었다는 사실을 보면서도 불감증에 걸려 있는 나 자신을 개혁해야 합니다. 왜 우리 스스로 22조원의 부채를 떠 안아야 합니까. 일본이나 독일을 보세요. 얼마나 철저한 준비를 하고 있는지 정말 새로워져야 합니다. 이에 대한 법적 규정화도 필요하다고 봅니다.
둘째, 선진국의 유사한 소프트웨어 개발비가 얼마나 들었는지를 조사해야 합니다. 그리고 이에 비해 우리는 얼마로 가능한지를 분석해야 합니다. 무조건 비싼 것이 아니라 상대방을 알고 이를 비교할 수 있는 정보와 능력을 길러야 합니다. 이를 위해 지식 기반(knowledge based)의 소프트웨어 비용추정 및 관리도구를 사용해야 합니다. 몇 만불이 되지 않는 이러한 도구로 수 십억불 프로젝트를 분석하고 관리할 수 있어야 합니다.
특히 유사한 소프트웨어에 대한 Function Point를 추정할 수 있다면 얼마나 많은 도움이 되겠습니까. 이제 우리는 사전 정보 없이 또 우리식으로 추정하는 시대는 끝이 나야 합니다. 2004년도 6천억불 국제소프트웨어 시장의 3% 밖에 안되는 180억불의 한국 시장에 언제까지 안주하고 있어야 합니까. 우리도 반듯하게 국제경쟁력을 갖출 수 있습니다. 특히, 요건관리도구와 비용관리도구가 함께 통합되어 가고 있는 것도 우리에게 큰 비전이 될 것입니다.
셋째, 확정계약과 개산계약 위주의 계약방식도 보다 문을 넓혀야 합니다. 잘하면 인센티브도 주고 못하면 벌과금도 무는 계약을 해야 합니다. 갑이 잘못했으면 분명하게 보전해 주는 계약을 할 수 있어야 합니다. 무조건 수주해 놓고 보자는 식으로 단가를 산정하지 맙시다. 분명하게 이윤을 만들 수 있도록 갑도 을도 함께 노력해야 합니다. 지체상금으로 허리가 휘어진 을은 갑에게도 책임이 있다는 ‘고귀한 책무’의 정신을 가져야 합니다.
마지막으로 올바른 요건을 도출하고 이를 반듯하게 개발할 수 있는 갑과 을의 능력을 CMM level 3 획득에 머무르지 말고 이를 줄기차게 개선할 수 있는 실제 능력을 키워나가야 합니다. CMM 등급은 할 수 있다는 자격에 불과합니다. 이겨야 합니다. 이는 전적으로 바른 시스템엔지니어링 프로세스를 구현할 때 가능하다는 사실을 꼭 기억하고 소프트웨어 시장을 살려 나갔으면 좋겠습니다.

김현수 이제부터는 실질적인 얘기를 해보겠습니다. 전자정부 사업이나 소프트웨어 사업이 어떻게 수행되고 있기 때문에 문제가 있는지 그 해결방안은 무엇인지를 들어보겠습니다. 최창학 국장이 전자정부사업의 예산관리 문제와 개선 방안을 말씀 드리겠습니다.

정보화 예산 확보 어려워진다

최창학 정부의 정보화 사업을 모두 전자정부 사업으로 이해하는 사람이 많은데 사실은 그렇지 않습니다. 정부 정보화 사업은 대단히 많습니다. 전자정부 사업으로 정해서 추진하는 것은 한 개 부처에서는 도저히 처리할 수 없어 다 부처에서 공동으로 추진해야 하는 사업입니다.
이런 사업을 전략적으로 선택해 대통령 과제로 선정해 집중 관리하는 체제를 전자정부 사업이라고 할 수 있습니다. 각 부처의 정보화 사업을 망라해 전자정부 사업이라고 할 수 없습니다.
주목해야할 것은 정부의 정보화 예산 책정 방식이 변경되고 있다는 사실입니다. 과거에는 정통부가 각 부처로부터 제안 받아 전자정부 사업으로 선정하고 이를 정보화 촉진 기금으로 추진하는 방식이었습니다.
이제는 전자정부 사업이 행정 개혁과 밀접하게 관련돼 있다고 해서 행정자치부로 주요 기능이 많이 넘어갔습니다. 행자부는 내년부터 전자정부 출연금이라는 ‘보따리’를 만들어 전자정부사업으로 선정된 사업을 추진하기로 했습니다.
이렇게 되면 전자정부 출연금에 포함되지 않은 사업은 어떻게 될까요. 과거에는 부처에서 기획예산처에 요구하면 기획예산처는 이를 판단해 해줄 것인지, 말지를 결정했는데 앞으로는 그렇게 할 수 없다는 얘기입니다..
2005년도부터 예산 편성 방식은 탑다운 방식으로 완전히 바뀌게 됩니다. 전체 예산을 정해두고 이를 각 부처에 나누어 주는 것입니다. 정해진 빵을 나누어 각 부처에 주고, 각 부처는 그 빵을 가지고 사업을 하는 겁니다. 이렇게 되면 각 부처는 정보화 사업을 할 수도 있고 안할 수도 있습니다. 앞으로는 부처가 결정해서 하도록 바뀐 겁니다.
이러한 예산 편성 방식이 전자정부 사업에 어떠한 영향을 끼칠까요. 앞으로 정보화 사업과 관련해 힘든 싸움이 일어날 수 있다고 봅니다. 전체적인 파이가 부처로 넘어가면서 그 부처내의 부서끼리 예산을 따내려고 견제하는 일이 잦아질 겁니다. 그러나 문제는 정보화를 담당하는 부서의 논리나 주장이 부처 내에서 강하지 않다는 사실입니다.
예산을 따기 힘들 경우 사업하지 않으면 되지 않느냐 라는 말이 나올 겁니다. 정보화 예산이 다른 것에 밀릴 수도 있다는 얘기입니다.
예산 책정에는 행정부 과정, 국회 과정이 있습니다. 말씀 드렸듯이 행정부 예산은 탑다운 방식으로 바뀐 것이 변수입니다. 국회는 과거 어떤 국회위원이든지 정보화 예산을 깎아서는 시대에 뒤떨어진다는 평가를 받을 가능성이 있어 우호적으로 통과시켜줬습니다. 그런데 국회 예산처라는 엄청나게 큰 전문 조직이 생겼습니다. 여기서 일일이 따져 예산을 집행하기 때문에 과거처럼 쉽지 않을 것입니다. 명확하게 아웃풋이 설명되지 않으면 대폭 삭감될 가능성이 있다는 얘기입니다.
다시 말해 과거보다 정보화 예산 확보가 대단히 어려워질 것이라는 것을 말하고 싶습니다.
제가 이 토론회에 참여한 것은 최근 논의되고 있는 새로운 정보화 관련 사업들의 예산 편성에서 고려해야 할 요소들이 무엇인지를 정부에서 파악해 반영하는 것이 필요해서 입니다.
참여정부는 정보화나 전자정부 사업을 새로운 제도와 관련해 유연하게 대응하겠다는 입장입니다. 어떠한 이슈를 놓고 학회나 협회, 그리고 업계의 자율적인 논의를 거쳐 의견을 수렴하면 전자정부위원회에서는 이를 구체적으로 제도화하는데 도움을 드릴 수 있습니다.
각 부처로 들어가면 결제 과정에서 상당히 시간이 걸리고 사전에 걸러져 버리는 경우도 있습니다. 하지만 전자정부위원회는 대통령 직속이기 때문에 제도의 타당성이 인정되면 충분하게 해당 부처를 탑다운 방식으로 설득할 수 있습니다.
좋은 제도들이 정부에서 신속하게 수용할 수 있도록 하기 위해서는 근본적으로 정보화 인력의 대혁신이 필요합니다. 집이 좋다고 해도 그 터전(인프라)이 잘 안되어 있으면 집을 지을 수 없습니다. 정부 내부의 정보화 관련 인력 구조의 혁신이 필요합니다.

김현수 문제 인식의 공유도 중요하지만 해결 솔루션의 도출이 더 중요하다고 봅니다. 계약은 발주자와 수주자 양자간의 문제입니다. 각 입장을 들어보겠습니다.
정부 계약기간 복수년도로 바꾸자

심기보 황인성 수석의 발제 내용에는 수긍하는 면도 있지만 달리 생각하는 것도 없지 않습니다. IT에 몸담고 있는 전문가, 사업자 등에게 그러한 시각이 도움이 될지 의문입니다. IT를 하는 사람은 자칫 ‘엉망’이라는 모습으로 비칠 수도 있기 때문입니다.
먼저 정부가 소프트웨어를 푸대접했다고 하는데, 그런 것 같기도 합니다만 우리나라만큼 소프트웨어 사업 대가 기준을 정부가 이미 1989년에 만들어 보급한 나라는 지구상에 없습니다. 정부는 또 불법 소프트웨어를 90년대 중후반부터 대대적으로 단속했습니다. 이 점 역시 정부가 소프트웨어에 대해 관심이 많다는 점을 보여주는 대목입니다.
무형의 소프트웨어에 관심이 낮다는 지적을 하시면서 제안서 보상을 거론하셨는데요, 업체 입장에서는 떨어지면 사실 힘들죠. 그렇지만 자기가 쓴 제안서를 다른 발주자가 사용할 경우에는 반드시 보상해줘야 한다고 생각합니다. 무조건 제안서 비용의 보상은 곤란합니다.
저가 입찰제와 관련해 우리나라와 일본은 유사한 점이 많습니다. 일본에서도 전자정부 프로젝트에서 낙찰가격이 너무 차이가 나서 공정거래위원회에서 나선 일이 있습니다. 몇개 사례를 들면 일본 총무성 조달정부 시스템의 경우, 예정 가격은 1억 5천만이었는데 2만 9천원에 낙찰됐습니다.
또 재무성 전자납세신고시스템은 예가가 5억 5,210만원이었는데 1만 1천에 낙찰되었어요. 그리고 동경도 문서관리시스템은 예가가 8,500만원이었지만 9천원에 낙찰됐습니다. 이런 문제점이 우리나라만이 아니라 선진국도 마찬가지라는 겁니다. 차이가 있다면 선진국에서는 이런 문제에 대해 대처를 많이 하고 있다는 것입니다.
또 일본도 우리나라와 마찬가지로 상위 몇개 업체가 시장을 장악하고 있습니다. NTT 34%, 후지쯔 10%, 히다찌 9% 등 3개사가 전체 시장의 53%를 차지하고 있습니다. 여기에 상위 5개사를 포함한 8개사의 점유율은 80%에 이릅니다.
전세계 소프트웨어 개발 프로젝트의 성공률이 언제인가 28%에 불과하다는 데이터를 본 적이 있습니다. 실패한 프로젝트는 크게 3개로 구분할 수 있습니다. 요구 정의가 제대로 안된채 추진했거나 신기술을 뚜렷한 검증을 거치지 않고 사용했을 경우가 바로 그것입니다.
또 요구정의가 잘 안된 이유로 발주자 잘못이 16%, 수주자 문제는 18%라는 조사 결과가 있습니다. 미국의 예입니다. 우리나라에서도 이러한 조사가 되어 있는지 궁금합니다.
우리나라에서는 요구 정의 문제를 놓고 발주자에게 떠미는 경향이 있는데 이처럼 외국 사례를 고려해 평가해야 하지 않을 까 생각합니다.
대가 산정과 관련해 몇 가지 대안을 제시해 보겠습니다. 먼저 가격 평가를 할 때 개발비만 가지고 하는 것이 아니라 TCO로 하자는 것입니다. 일반적으로 소프트웨어 생명주기를 4년으로 보는데 4년 동안의 유지보수와 개발비를 모두 산정해 평가하자는 얘기입니다. 이렇게 하려면 개발업체가 유지보수를 해야 하는 전제가 따르는데 쉽지 않은 문제입니다.
저가입찰 문제도 한번 꼼꼼히 분석해 봤으면 좋겠습니다. 예를 들어 서버 등 모든 시스템에 걸쳐 입찰 결과를 분석하고 그 타당성을 면밀히 평가해 공개하자는 것입니다.
입찰결과를 공개하는데 찬성입니다. 이렇게 하면 평가자가 어떠한 이유 때문에 얼마의 점수를 주었는지를 분명한 논리도 제시할 수 있을 것입니다. 또 좀더 심도있는 평가도 이뤄질 수 있음은 물론입니다.
기술 평가를 강화하자고 하는데 우리나라는 기술성 평가 기준을 1994년에 만들어 2003년에 보완했습니다. 평가 대상에는 개발 뿐만 아니라 유지보수, 컨설팅 까지 포함돼 있습니다.상당히 발전적입니다. CMM은 국제적인 레벨입니다. 이를 평가 항목에 넣어 기술 평가를 강화하는 것이 매우 바람직합니다. 공정 거래를 문란하게 하는 기업의 입찰도 제한해야 합니다.
일본도 우리나라와 마찬가지로 소프트웨어 산업 발전을 위해 금융 세제 혜택 등 몇 가지 정책을 내놓고 있는데 발주자들이 똑똑하게 잘 할 수 있도록 변화를 시도하고 있는 점이 눈길을 끕니다. 즉 프로젝트 관리에 발주자들이 EVM이나 SLA, EA를 적용할 수 있도록 시도하고 있습니다.
우리나라 정부의 경우 계약 방식이 단년도로 되어 있습니다. 계약기간을 3~5년에 이르는 복수년도로 바꾸고 정부는 이에 맞춰 예산을 확보하는 제도의 마련이 필요합니다.
발주자와 수주자의 역할도 분명히 해야 합니다. 발주자나 수주자 각자가 역할을 제대로 못하면 패널티가 반드시 돌아가는 구조를 만들어야 합니다.
우리나라에는 정부에서 수발주자의 역할 분담의 기준으로 소프트웨어 품질 보증 기준이라는 것을 두고 있습니다. 매우 세밀하게 정리되어 있는데 많은 사람들이 이의 존재 여부도 잘 모른 상태입니다.
조달 사항의 정보를 공유하는 것도 필요합니다. 발주 수주 과정을 데이터베이스로 만들어 어떤 프로젝트에 얼마가 들어가고 얼마 남았는지를 누구나 볼 수 있도록 해야 합니다.
Function Point는 목적이 아니라 수단에 불과합니다. 이의 도입으로 갑자기 소프트웨어 산업이 달라질 것으로 생각하는 것은 큰 착각입니다. 요구 정의는 무척 어려운 문제입니다. 매우 많은 노력과 교육, 토의가 필요합니다.

FT 적용 국가 프로젝트 DB화해
사업대가 기준의 합리화 자료로 활용해야

이윤성 Function Point 기반으로 발주 제도가 바뀌고 있습니다. 공급자 입장에서 이런 부문이 감안됐으면 좋은 점을 실무적인 관점에서 말씀 드리겠습니다.
Function Point 기준으로 제안하려면 무엇보다 요구 기능이 나와야 합니다. 그 기능을 제대로 정의하지 않은 채 제안하는 경우가 많습니다. 지금도 어려운데 Function Point 기준으로 제안하면 좀 더 제안비용이 많이 들어가는 문제가 있습니다. 앞에서 황 수석이 이의 문제 해결 방안으로 제기한 ISP와 요구 분석, 그리고 설계 개발을 분리 발주하는 제도가 바람직하다고 생각합니다. 그렇지 않으면 중간에 마일스톤을 갖고 요구 사항이 완전히 도출됐을 때 그 때 다시 가격을 확정하는 프로세스를 마련하는 것이 필요합니다.
프로젝트를 추진할 때 계속해서 요구 사항이 변경됩니다. 이는 어쩔 수 없는 일입니다. 요구사항의 변경을 일정 한도에서는 사업자가 수용할 수도 있지만 과도해지면 지연되고, 과도한 투입이 불가피하고....결국은 사업이 어려워지고, 부실화되는 폐해가 발생합니다.
건설업종은 외부의 감리자들이 이를 컨트롤하고 있습니다. 발주자나 수주자 위주로 흘러가는 것이 아니라 감리자가 객관적인 기준을 가지고 컨트롤 하는 기능을 갖추고 있지만 소프트웨어 업종은 그렇지 않습니다.
그래서 제 3의 기관에 맡겨 사이징을 하는 것이 좋을 것으로 생각합니다. 프로젝트의 결과물이 당초보다 얼마나 바뀌었으며 이에 따라 어느 정도의 비용과 기간이 변화되었는지를 공정하게 평가할 수 있을 것입니다. 즉 프로젝트가 왜 연기되었는지, 이 때문에 얼마의 지체보상금을 물어야 하는지 논쟁이 붙었을 때 공정한 해석을 내려줄 수 있는 제도가 필요하다는 얘기입니다.
Function Point는 소프트웨어 사이징 기법입니다. 이를 얼마의 생산성으로 만들어낼 수 있을지 연구의 여지가 있습니다. 어떤 지식을 가진 사람이 어떤 기법을 써서 만들어내는 것을 축적해 좀더 잘 쓰일 수 있도록 해야할 것입니다.
국가 차원에서 많은 프로젝트가 진행되는 것으로 알고 있습니다. 그 프로젝트들이 추적되어 어떤 Function Point 규모를 가진 프로젝트들이 얼마의 예산을 들여 만들어지고 있는지를 데이터베이스화해 사업대가 기준의 합리화 자료로 활용하는 것이 필요합니다.
인기기사 순위
여백
여백
(우)08503 서울특별시 금천구 가산디지털1로 181 (가산 W CENTER) 1713~1715호
TEL : 02-2039-6160  FAX : 02-2039-6163  사업자등록번호:106-86-40304
개인정보/청소년보호책임자:김선오  등록번호:서울 아 00418  등록일자:2007.08  발행인:김용석  편집인:김선오