A. 사업비 산정의 객관성은 단순한 경험이나 추정이 아니라, 유사 프로젝트의 실제 수행 데이터를 기반으로 확보되어야 합니다. 당사는 다양한 SW사업 수행실적 데이터를 바탕으로 비용·공수·기간 정보를 분석하여 사업비를 산정하는 데이터 기반 견적 솔루션을 보유하고 있습니다.
A. 정보화 사업에서 사업비는 예산 수립, 계약 체결, 사업 수행 전반에 영향을 미치는 핵심 기준입니다. 그러나 실제 현장에서는 산정 기준이 불명확하거나 담당자의 경험에 의존하여 비용이 산정되는 경우가 많아, 객관성과 신뢰성이 부족한 사례가 적지 않습니다.
특히 아래와 같은 상황에 해당한다면 산정 결과에 대한 검증이 필요합니다.
기능점수(Function Point) 등 규모 산정 기준이 명확하지 않은 경우
동일한 사업임에도 기관 또는 담당자에 따라 산정 결과가 달라지는 경우
예산 산출 근거를 명확히 설명하기 어려운 경우
사업 수행 이후 비용 적정성에 대한 이슈가 발생하는 경우
이러한 문제는 단순한 산정 오류를 넘어, 예산 과다·과소 산정, 사업 지연, 감사 및 분쟁 리스크로 이어질 수 있습니다.
- 왜 객관적인 산정 기준이 필요한가요? SW사업대가 기준 개정 이후, 투입공수(Man-Month)나 LOC 방식은 축소되고 사용자 요구사항 기반의 기능점수(Function Point) 방식이 표준으로 활용되고 있습니다. 이에 따라 공공 정보화 사업에서는 관련 지침과 제도를 기반으로 객관적인 규모 산정과 비용 산출 근거 확보가 필수적으로 요구됩니다.
그러나 실제로는 담당자의 경험이나 해석에 따라 산정 결과의 편차가 발생할 수 있어, IFPUG 공인 기능점수 전문가(CFPS)에 의한 산정 또는 검증이 중요합니다.
- 산정 및 검증은 어떤 절차로 진행됩니까?
단계
주요 내용
1. 요청 및 자료 준비
산정·검증 요청 접수 및 요구사항 관련 자료 수집
2. 산정 또는 검증 수행
CFPS 전문가 직접 수행, 자동 측정 도구 활용, 필요 시 인터뷰 및 추가 분석 진행
3. 결과 검토 및 확정
결과 보고서 작성 후 검토 및 보완을 거쳐 최종 확정
- 무엇이 달라집니까? 기능점수 기반의 국제 표준 방법론을 적용함으로써 재현 가능하고 설명 가능한 산정 근거를 확보할 수 있습니다.
발주기관 — 예산 신뢰성 확보 및 감사 대응력 강화
수행사 — 합리적인 비용 기준 확보 및 분쟁 최소화
사업비의 적정성은 단순한 수치가 아니라, 객관적인 기준과 검증 절차를 통해 확보되어야 합니다. 현재 산정된 결과가 정확한지는 경험이 아닌 표준 기반의 검증을 통해 확인하는 것이 가장 확실한 방법입니다. 보다 구체적인 문의는 홈페이지의 연락처를 참고하시기 바랍니다.
A. 많은 조직이 과거 관행이나 기존 계약 기준을 바탕으로 ITO 대가체계를 운영하고 있습니다. 그러나 실제로는 업무량 대비 비용이 적정하지 않거나, 산정 기준이 불명확하여 분쟁 가능성을 내포하고 있는 경우가 적지 않습니다.
특히 아래와 같은 상황에 해당한다면 현재의 대가체계를 점검해볼 필요가 있습니다.
업무량 변화와 무관하게 비용이 고정되어 있는 경우
산정 기준이 명확하지 않거나 담당자에 따라 해석이 달라지는 경우
신규 사업이나 시스템 변경 시 적용할 대가 산정 기준이 없는 경우
계약 변경 또는 정산 과정에서 이견이 반복적으로 발생하는 경우
이러한 문제는 단순한 비용 이슈를 넘어, 과다 지출·계약 분쟁·감사 리스크로 이어질 수 있습니다.
당사는 기능점수(Function Point) 등 객관적인 업무량 기반 지표를 활용하여 현재 운영 중인 대가체계를 진단하고, 비용 구조의 적정성과 기준의 명확성을 검증합니다. 또한 조직과 사업 특성에 맞는 대가체계를 설계하여 지속 가능한 운영 기준과 분쟁 예방이 가능한 구조를 제안합니다.
현재의 대가체계가 적정한지에 대한 판단은 단순 비교가 아닌, 객관적인 기준에 근거한 진단을 통해 확인하는 것이 가장 확실한 방법입니다. 보다 구체적인 문의는 홈페이지의 연락처를 참고하시기 바랍니다.
Q. 로우코드 및 노코드 솔루션 활용에 따른 생산성 향상 효과는 사업비에 어떻게 반영해야 하나요?
A. 최근 많은 기업들이 로우코드(Low-Code) 및 노코드(No-Code) 솔루션을 활용하거나 도입을 검토하고 있으며, 이러한 도구들은 개발 생산성을 크게 향상시킬 수 있는 것으로 알려져 있습니다.
그러나 실제로 개발 노력이 어느 수준까지 절감되는지에 대해서는 공신력 있는 정부 정책기관이나 표준화된 기준이 아직 명확하게 제시되어 있지 않습니다. 이로 인해 생산성 향상 효과를 사업비 산정에 직접 반영하는 데에는 현실적인 한계가 존재합니다.
특히 공공 정보화 사업의 경우, 객관성과 재현성이 확보된 기준에 따라 사업비를 산정해야 합니다. 특정 도구의 생산성 향상 효과를 임의로 반영할 경우, 적정성 논란이나 분쟁으로 이어질 가능성이 있어 주의가 필요합니다.
따라서 현 시점에서는 로우코드·노코드 도구의 도입 여부와 관계없이, 기능점수(Function Point)와 같이 기술 중립적인 규모 산정 기준을 기반으로 사업비를 산정하는 것이 바람직합니다. 향후에는 축적된 실증 데이터와 정책 연구를 토대로, 생산성 향상 효과를 공식적으로 반영할 수 있는 기준이 마련될 필요가 있습니다.
결론적으로, 로우코드 및 노코드 솔루션의 생산성 향상 효과는 앞으로 중요한 고려 요소가 될 수 있습니다. 그러나 현재로서는 이를 사업비 절감 요소로 직접 반영하기보다, 표준화된 산정 체계를 유지하는 것이 합리적인 접근입니다.
A. 단가 계약은 완료된 작업량이나 사용된 자재의 수량에 따라 대가가 결정되는 계약 방식입니다. 지불이 실제 수행된 작업량과 직접 연동되므로, 전체 프로젝트를 고정 금액으로 계약하는 방식에 비해 프로젝트 상황 변화에 유연하게 대응할 수 있으며, 비용 산정의 투명성이 높다는 특징이 있습니다.
장점
유연한 비용 관리 — 실제 수행된 작업량을 기준으로 비용이 산정되므로, 작업 범위가 변경되더라도 계약 구조 자체를 재협상할 필요 없이 대응이 가능합니다.
청구의 투명성 — 작업량과 비용의 연계가 명확하여 발주자와 수행자 모두 비용 발생 근거를 쉽게 확인할 수 있습니다.
범위 조정의 용이성 — 프로젝트 진행 중 업무 범위가 추가되거나 축소되는 경우에도 단가 기준으로 유연하게 조정이 가능합니다.
단점
최종 사업비의 불확실성 — 작업 범위가 확대될 경우 전체 비용이 예상을 초과할 수 있어, 사전에 총 사업비를 확정하기 어렵습니다.
작업량 관리의 필요성 — 비용이 수행량과 직결되므로, 발주자 측에서 작업량을 지속적으로 모니터링하고 관리하는 체계가 필요합니다.
단가 계약은 프로젝트 특성상 범위 변동 가능성이 높거나, 업무가 점진적으로 정의되는 경우에 적합한 계약 방식입니다. 다만 사업비 총액의 예측 가능성이 중요한 경우에는 계약 전 작업 범위와 수량 기준을 명확히 설정하는 것이 중요합니다.
A. 두 지표 모두 소프트웨어 개발에서 규모나 작업량을 표현하는 데 사용되지만, 그 목적과 성격은 본질적으로 다릅니다.
1. 스토리 포인트(Story Point)란? 스토리 포인트는 프로젝트 내 개별 작업의 난이도와 투입 노력을 나타내기 위해 사용하는 추정 단위입니다. 팀이 자체적으로 정의하는 추상적 측정 단위로, 작업의 복잡성, 예상 소요 시간, 필요 자원 등을 종합적으로 고려하여 각 작업을 평가하고 비교하는 데 활용됩니다.
스토리 포인트는 주로 프로젝트 백로그를 구성하고 우선순위를 결정하는 데 사용됩니다. 각 작업 항목에 스토리 포인트를 부여함으로써 팀이 어떤 작업을 먼저 착수해야 하는지 판단하는 데 도움을 줍니다.
그러나 스토리 포인트는 국제적으로 표준화된 소프트웨어 측정 단위가 아닙니다. 팀마다 기준이 다르기 때문에 동일한 사업 내에서 상대적인 작업 규모를 비교하는 용도로는 유용하지만, 조직 간 비교나 계약·비용 산정의 기준으로는 활용하기 어렵습니다. 즉, LOC나 기능점수와 같이 정규화된 표준 척도로서의 역할은 하지 못합니다.
2. 기능점수(Function Point)란? 기능점수는 사용자 관점에서 소프트웨어가 제공하는 기능의 규모를 측정하는 단위입니다. 소프트웨어 기능은 데이터 측면과 트랜잭션 측면으로 구분되며, 데이터 기능에는 내부논리파일(ILF)과 외부연계파일(EIF)의 2가지 유형이, 트랜잭션 기능에는 외부입력(EI)·외부출력(EO)·외부조회(EQ)의 3가지 유형이 있습니다.
기능점수는 국제표준으로 정립된 소프트웨어 규모 측정 단위로, 특정 조직이나 프로젝트에 관계없이 일관된 기준으로 규모를 산정할 수 있습니다. 우리나라를 포함한 전 세계적으로 소프트웨어 규모 및 사업비 산출에 활용되며, 규모당 단가 방식 또는 규모와 투입 공수를 활용한 표준 생산성 기준을 적용하여 사업 예산을 산출하는 데 사용됩니다.
3. 정리 스토리 포인트는 팀 내부의 작업 계획과 우선순위 관리에 유용한 도구입니다. 반면 팀 간·조직 간 비교나 ISBSG와 같은 산업 벤치마크 데이터와의 비교, 그리고 계약 및 사업비 산정 등 공식적인 기준이 필요한 상황에서는 활용에 한계가 있습니다. 이러한 목적에는 국제표준으로 정립된 기능점수를 사용하는 것이 적합합니다.
A. 정보시스템 비용은 크게 자본적 지출(CapEx)과 운영적 지출(OpEx)로 구분됩니다. 두 개념은 회계 처리 방식과 비용의 성격이 서로 다르므로, 예산 계획 및 투자 의사결정 시 명확히 구분하여 관리하는 것이 중요합니다.
1. CapEx (Capital Expenditure, 자본적 지출) 미래의 이익 창출을 위해 지출하는 비용으로, 유효 수명이 당해 회계연도를 초과하는 자산을 구매하거나 개량할 때 발생합니다. 장비·토지·건물 등 유형자산의 취득 및 개선에 사용되며, 회계상 자산 계정에 추가(자본화)되어 자산 가치의 증가로 처리됩니다. 일반적으로 현금흐름표의 투자 항목에서 확인할 수 있습니다.
정보시스템 분야에서는 서버·네트워크 장비 등 하드웨어 구매, 소프트웨어 라이선스 취득, 신규 정보시스템 구축 사업 등이 CapEx에 해당합니다.
2. OpEx (Operational Expenditure, 운영적 지출) '업무지출' 또는 '운영비용'이라고도 하며, 갖춰진 설비나 시스템을 운영하는 데 드는 제반 비용을 말합니다. 인건비·재료비·수선유지비와 같은 직접 비용과 제세공과금 등의 간접 비용으로 구성되며, OpEx가 높다는 것은 기존 생산설비나 시스템이 노후화되었음을 나타내는 신호로 해석되기도 합니다.
정보시스템 분야에서는 시스템 운영·유지보수 비용, 클라우드 서비스 이용료, IT 운영 인력의 인건비 등이 OpEx에 해당합니다.
CapEx와 OpEx는 상호 대조적으로 사용되는 개념으로, 동일한 정보시스템이라도 자체 구축 방식은 CapEx 비중이 높고, 클라우드 기반 서비스 이용 방식은 OpEx 비중이 높아지는 경향이 있습니다. 조직의 재무 전략과 시스템 운영 방향에 따라 두 지출의 균형을 적절히 고려하는 것이 바람직합니다.
A. 기능점수 측정 규칙을 이해하고 실무 경험을 갖춘 사람이라면 누구든지 기능점수를 산정할 수 있습니다. 다만 실무에서는 기술 인력이 맡아야 하는지, 사용자(고객) 측이 담당해야 하는지, 또는 조직 내 특정 인원을 지정해야 하는지에 대한 질문이 자주 제기됩니다. 아래에서는 이에 대한 실무 경험을 바탕으로 한 주요 고려사항을 정리합니다.
기술 인력이 산정해야 합니까? 기술 인력은 오랫동안 기능점수 산정의 주요 담당자였습니다. 규모 추정이 필요할 때 자연스럽게 참여해 왔으며, 조직의 생산성 분석, 애플리케이션 아키텍처 설계, 유지·폐기·재설계 결정 등 다양한 목적으로 기능점수를 활용해 왔습니다.
다만 기술 인력에게는 한 가지 주의해야 할 경향이 있습니다. 기능점수 산정 결과가 프로젝트 전체의 투입 공수와 연결된다는 점을 잘 알기 때문에, 세부 항목별 산정값을 실제 작업 경험에 맞추려는 편향이 생길 수 있습니다. 예를 들어 도움말 시스템 개발에 수 주가 소요되었는데 IFPUG 기준으로 8 기능점수(낮은 복잡도 외부출력 3점, 낮은 복잡도 외부참조파일 5점)밖에 산정되지 않는다며 이의를 제기하는 사례가 대표적입니다. 이는 기능적 규모와 기술적 난이도를 혼동하는 데서 비롯되며, 기능점수의 측정 목적과 원칙에 대한 충분한 이해가 중요합니다.
사용자(고객) 측이 산정해야 합니까? 초기 GUIDE 산정 매뉴얼에서는 시니어급 사용자도 훈련을 통해 기능점수를 산정할 수 있다고 언급하고 있습니다. 기능점수 산정은 회계와 유사한 측면이 있습니다. 회계사가 FASB(재무회계기준위원회)의 규칙을 적용하여 재무 건전성을 측정하듯, 기능점수 전문가는 IFPUG 규칙을 적용하여 소프트웨어 규모를 측정합니다.
복잡한 시스템 개발이 대부분의 비즈니스에서 핵심 역량이 된 오늘날, 사용자 측이 필요한 기능 요구사항을 확보하고 개발자와 협의하기 위해서는 기능점수에 대한 이해가 실질적으로 도움이 됩니다.
경험이 풍부한 시니어 인력이 담당해야 합니까? 일반적으로 그렇습니다. 경험이 풍부한 인력은 주요 기능이 누락되지 않도록 적절한 질문을 할 줄 알며, 경험이 부족한 담당자가 간과할 수 있는 문제를 사전에
Q. 사업비 산정의 객관성은 어떻게 확보하나요?
A. 사업비 산정의 객관성은 단순한 경험이나 추정이 아니라, 유사 프로젝트의 실제 수행 데이터를 기반으로 확보되어야 합니다. 당사는 다양한 SW사업 수행실적 데이터를 바탕으로 비용·공수·기간 정보를 분석하여 사업비를 산정하는 데이터 기반 견적 솔루션을 보유하고 있습니다.
*산정 방식 및 결과 목록은 하단 이미지 참조
Q. 기능점수를 자동으로 측정 및 검증할 수 있나요?
A. 네, 가능합니다. 당사는 기능점수를 자동으로 측정하고 검증할 수 있는 도구를 보유하고 있으며, 사용자 요구사항과 프로그램 소스코드를 기반으로 기능 규모를 객관적으로 산정할 수 있습니다.
기능점수 자동화 도구는 다음과 같은 두 가지 방식으로 구성됩니다.
1. 사용자 요구사항 기반 자동화 도구
요구사항 정의서를 기반으로 기능을 식별하고 구조화하여 기능점수를 산정하며, 누락되거나 잘못 정의된 기능을 자동으로 검증합니다. 개발 이전 단계에서 활용할 수 있어 예산 수립 및 발주 단계의 규모 산정과 검증에 효과적입니다.
2. 프로그램 소스 기반 자동화 도구
개발된 시스템의 소스코드를 분석하여 화면, 처리 로직, 데이터 구조를 기반으로 기능을 식별하고 기능점수를 산정합니다. 실제 구현된 시스템 기준의 규모를 검증할 수 있으며, 유지보수 및 운영 단계에서도 활용이 가능합니다.
자동화 도구를 활용하면 기존의 수작업 중심 산정 방식 대비 산정 기준의 일관성을 확보할 수 있으며, 오류와 누락을 최소화하고 분석 시간을 단축할 수 있습니다. 또한 동일한 기준으로 반복 측정이 가능하여 결과의 재현성과 객관성을 높일 수 있습니다.
본 도구는 당사가 보유한 특허 기술을 기반으로 개발되었으며, 공공 SW사업정보저장소 데이터 수집 및 검증 지원 사업에 다년간 적용되어 실무에서 품질과 신뢰성이 검증되었습니다.
기능점수 자동 측정 및 검증 도구는 단순한 편의 기능을 넘어, 기능점수 산정의 객관성과 신뢰성을 확보하기 위한 효과적인 수단입니다. 도구의 구성과 적용 방식에 대한 보다 자세한 사항은 아래 이미지 및 홈페이지의 연락처를 참고하시기 바랍니다.
1. 요구사항을 이용한 기능점수 자동화 도구
2. 프로그램 소스를 이용한 기능점수 자동화 도구
Q. 지금 산정된 사업비, 정말 정확한 걸까요?
A. 정보화 사업에서 사업비는 예산 수립, 계약 체결, 사업 수행 전반에 영향을 미치는 핵심 기준입니다. 그러나 실제 현장에서는 산정 기준이 불명확하거나 담당자의 경험에 의존하여 비용이 산정되는 경우가 많아, 객관성과 신뢰성이 부족한 사례가 적지 않습니다.
특히 아래와 같은 상황에 해당한다면 산정 결과에 대한 검증이 필요합니다.
이러한 문제는 단순한 산정 오류를 넘어, 예산 과다·과소 산정, 사업 지연, 감사 및 분쟁 리스크로 이어질 수 있습니다.
- 왜 객관적인 산정 기준이 필요한가요?
SW사업대가 기준 개정 이후, 투입공수(Man-Month)나 LOC 방식은 축소되고 사용자 요구사항 기반의 기능점수(Function Point) 방식이 표준으로 활용되고 있습니다. 이에 따라 공공 정보화 사업에서는 관련 지침과 제도를 기반으로 객관적인 규모 산정과 비용 산출 근거 확보가 필수적으로 요구됩니다.
그러나 실제로는 담당자의 경험이나 해석에 따라 산정 결과의 편차가 발생할 수 있어, IFPUG 공인 기능점수 전문가(CFPS)에 의한 산정 또는 검증이 중요합니다.
- 산정 및 검증은 어떤 절차로 진행됩니까?
- 무엇이 달라집니까?
기능점수 기반의 국제 표준 방법론을 적용함으로써 재현 가능하고 설명 가능한 산정 근거를 확보할 수 있습니다.
사업비의 적정성은 단순한 수치가 아니라, 객관적인 기준과 검증 절차를 통해 확보되어야 합니다. 현재 산정된 결과가 정확한지는 경험이 아닌 표준 기반의 검증을 통해 확인하는 것이 가장 확실한 방법입니다. 보다 구체적인 문의는 홈페이지의 연락처를 참고하시기 바랍니다.
Q. 지금 운영 중인 ITO 대가체계, 점검이 필요하지 않을까요?
A. 많은 조직이 과거 관행이나 기존 계약 기준을 바탕으로 ITO 대가체계를 운영하고 있습니다. 그러나 실제로는 업무량 대비 비용이 적정하지 않거나, 산정 기준이 불명확하여 분쟁 가능성을 내포하고 있는 경우가 적지 않습니다.
특히 아래와 같은 상황에 해당한다면 현재의 대가체계를 점검해볼 필요가 있습니다.
이러한 문제는 단순한 비용 이슈를 넘어, 과다 지출·계약 분쟁·감사 리스크로 이어질 수 있습니다.
당사는 기능점수(Function Point) 등 객관적인 업무량 기반 지표를 활용하여 현재 운영 중인 대가체계를 진단하고, 비용 구조의 적정성과 기준의 명확성을 검증합니다. 또한 조직과 사업 특성에 맞는 대가체계를 설계하여 지속 가능한 운영 기준과 분쟁 예방이 가능한 구조를 제안합니다.
현재의 대가체계가 적정한지에 대한 판단은 단순 비교가 아닌, 객관적인 기준에 근거한 진단을 통해 확인하는 것이 가장 확실한 방법입니다. 보다 구체적인 문의는 홈페이지의 연락처를 참고하시기 바랍니다.
Q. 로우코드 및 노코드 솔루션 활용에 따른 생산성 향상 효과는 사업비에 어떻게 반영해야 하나요?
A. 최근 많은 기업들이 로우코드(Low-Code) 및 노코드(No-Code) 솔루션을 활용하거나 도입을 검토하고 있으며, 이러한 도구들은 개발 생산성을 크게 향상시킬 수 있는 것으로 알려져 있습니다.
그러나 실제로 개발 노력이 어느 수준까지 절감되는지에 대해서는 공신력 있는 정부 정책기관이나 표준화된 기준이 아직 명확하게 제시되어 있지 않습니다. 이로 인해 생산성 향상 효과를 사업비 산정에 직접 반영하는 데에는 현실적인 한계가 존재합니다.
특히 공공 정보화 사업의 경우, 객관성과 재현성이 확보된 기준에 따라 사업비를 산정해야 합니다. 특정 도구의 생산성 향상 효과를 임의로 반영할 경우, 적정성 논란이나 분쟁으로 이어질 가능성이 있어 주의가 필요합니다.
따라서 현 시점에서는 로우코드·노코드 도구의 도입 여부와 관계없이, 기능점수(Function Point)와 같이 기술 중립적인 규모 산정 기준을 기반으로 사업비를 산정하는 것이 바람직합니다. 향후에는 축적된 실증 데이터와 정책 연구를 토대로, 생산성 향상 효과를 공식적으로 반영할 수 있는 기준이 마련될 필요가 있습니다.
결론적으로, 로우코드 및 노코드 솔루션의 생산성 향상 효과는 앞으로 중요한 고려 요소가 될 수 있습니다. 그러나 현재로서는 이를 사업비 절감 요소로 직접 반영하기보다, 표준화된 산정 체계를 유지하는 것이 합리적인 접근입니다.
Q. 단가 계약이란 무엇이며, 어떤 특징과 장단점이 있나요?
A. 단가 계약은 완료된 작업량이나 사용된 자재의 수량에 따라 대가가 결정되는 계약 방식입니다. 지불이 실제 수행된 작업량과 직접 연동되므로, 전체 프로젝트를 고정 금액으로 계약하는 방식에 비해 프로젝트 상황 변화에 유연하게 대응할 수 있으며, 비용 산정의 투명성이 높다는 특징이 있습니다.
장점
단점
단가 계약은 프로젝트 특성상 범위 변동 가능성이 높거나, 업무가 점진적으로 정의되는 경우에 적합한 계약 방식입니다. 다만 사업비 총액의 예측 가능성이 중요한 경우에는 계약 전 작업 범위와 수량 기준을 명확히 설정하는 것이 중요합니다.
Q. 스토리 포인트(Story Point)와 기능점수는 어떻게 다릅니까?
A. 두 지표 모두 소프트웨어 개발에서 규모나 작업량을 표현하는 데 사용되지만, 그 목적과 성격은 본질적으로 다릅니다.
1. 스토리 포인트(Story Point)란?
스토리 포인트는 프로젝트 내 개별 작업의 난이도와 투입 노력을 나타내기 위해 사용하는 추정 단위입니다. 팀이 자체적으로 정의하는 추상적 측정 단위로, 작업의 복잡성, 예상 소요 시간, 필요 자원 등을 종합적으로 고려하여 각 작업을 평가하고 비교하는 데 활용됩니다.
스토리 포인트는 주로 프로젝트 백로그를 구성하고 우선순위를 결정하는 데 사용됩니다. 각 작업 항목에 스토리 포인트를 부여함으로써 팀이 어떤 작업을 먼저 착수해야 하는지 판단하는 데 도움을 줍니다.
그러나 스토리 포인트는 국제적으로 표준화된 소프트웨어 측정 단위가 아닙니다. 팀마다 기준이 다르기 때문에 동일한 사업 내에서 상대적인 작업 규모를 비교하는 용도로는 유용하지만, 조직 간 비교나 계약·비용 산정의 기준으로는 활용하기 어렵습니다. 즉, LOC나 기능점수와 같이 정규화된 표준 척도로서의 역할은 하지 못합니다.
2. 기능점수(Function Point)란?
기능점수는 사용자 관점에서 소프트웨어가 제공하는 기능의 규모를 측정하는 단위입니다. 소프트웨어 기능은 데이터 측면과 트랜잭션 측면으로 구분되며, 데이터 기능에는 내부논리파일(ILF)과 외부연계파일(EIF)의 2가지 유형이, 트랜잭션 기능에는 외부입력(EI)·외부출력(EO)·외부조회(EQ)의 3가지 유형이 있습니다.
기능점수는 국제표준으로 정립된 소프트웨어 규모 측정 단위로, 특정 조직이나 프로젝트에 관계없이 일관된 기준으로 규모를 산정할 수 있습니다. 우리나라를 포함한 전 세계적으로 소프트웨어 규모 및 사업비 산출에 활용되며, 규모당 단가 방식 또는 규모와 투입 공수를 활용한 표준 생산성 기준을 적용하여 사업 예산을 산출하는 데 사용됩니다.
3. 정리
스토리 포인트는 팀 내부의 작업 계획과 우선순위 관리에 유용한 도구입니다. 반면 팀 간·조직 간 비교나 ISBSG와 같은 산업 벤치마크 데이터와의 비교, 그리고 계약 및 사업비 산정 등 공식적인 기준이 필요한 상황에서는 활용에 한계가 있습니다. 이러한 목적에는 국제표준으로 정립된 기능점수를 사용하는 것이 적합합니다.
Q. 정보시스템 비용 관리에서 CapEx와 OpEx는 무엇인가요?
A. 정보시스템 비용은 크게 자본적 지출(CapEx)과 운영적 지출(OpEx)로 구분됩니다. 두 개념은 회계 처리 방식과 비용의 성격이 서로 다르므로, 예산 계획 및 투자 의사결정 시 명확히 구분하여 관리하는 것이 중요합니다.
1. CapEx (Capital Expenditure, 자본적 지출)
미래의 이익 창출을 위해 지출하는 비용으로, 유효 수명이 당해 회계연도를 초과하는 자산을 구매하거나 개량할 때 발생합니다. 장비·토지·건물 등 유형자산의 취득 및 개선에 사용되며, 회계상 자산 계정에 추가(자본화)되어 자산 가치의 증가로 처리됩니다. 일반적으로 현금흐름표의 투자 항목에서 확인할 수 있습니다.
정보시스템 분야에서는 서버·네트워크 장비 등 하드웨어 구매, 소프트웨어 라이선스 취득, 신규 정보시스템 구축 사업 등이 CapEx에 해당합니다.
2. OpEx (Operational Expenditure, 운영적 지출)
'업무지출' 또는 '운영비용'이라고도 하며, 갖춰진 설비나 시스템을 운영하는 데 드는 제반 비용을 말합니다. 인건비·재료비·수선유지비와 같은 직접 비용과 제세공과금 등의 간접 비용으로 구성되며, OpEx가 높다는 것은 기존 생산설비나 시스템이 노후화되었음을 나타내는 신호로 해석되기도 합니다.
정보시스템 분야에서는 시스템 운영·유지보수 비용, 클라우드 서비스 이용료, IT 운영 인력의 인건비 등이 OpEx에 해당합니다.
CapEx와 OpEx는 상호 대조적으로 사용되는 개념으로, 동일한 정보시스템이라도 자체 구축 방식은 CapEx 비중이 높고, 클라우드 기반 서비스 이용 방식은 OpEx 비중이 높아지는 경향이 있습니다. 조직의 재무 전략과 시스템 운영 방향에 따라 두 지출의 균형을 적절히 고려하는 것이 바람직합니다.
Q. IT 아웃소싱 표준 대가체계는 어떤 절차로 수립되나요?
A. 표준 대가체계 수립은 아래와 같은 절차로 진행됩니다. 각 단계는 프로젝트 특성에 따라 조정될 수 있습니다.
위 절차는 프로젝트 상황에 따라 항목이 추가되거나 조정될 수 있습니다. 보다 구체적인 문의는 홈페이지의 연락처를 참고하시기 바랍니다.
Q. 기능점수는 누가 산정해야 하나요?
A. 기능점수 측정 규칙을 이해하고 실무 경험을 갖춘 사람이라면 누구든지 기능점수를 산정할 수 있습니다. 다만 실무에서는 기술 인력이 맡아야 하는지, 사용자(고객) 측이 담당해야 하는지, 또는 조직 내 특정 인원을 지정해야 하는지에 대한 질문이 자주 제기됩니다. 아래에서는 이에 대한 실무 경험을 바탕으로 한 주요 고려사항을 정리합니다.
기술 인력이 산정해야 합니까?
기술 인력은 오랫동안 기능점수 산정의 주요 담당자였습니다. 규모 추정이 필요할 때 자연스럽게 참여해 왔으며, 조직의 생산성 분석, 애플리케이션 아키텍처 설계, 유지·폐기·재설계 결정 등 다양한 목적으로 기능점수를 활용해 왔습니다.
다만 기술 인력에게는 한 가지 주의해야 할 경향이 있습니다. 기능점수 산정 결과가 프로젝트 전체의 투입 공수와 연결된다는 점을 잘 알기 때문에, 세부 항목별 산정값을 실제 작업 경험에 맞추려는 편향이 생길 수 있습니다. 예를 들어 도움말 시스템 개발에 수 주가 소요되었는데 IFPUG 기준으로 8 기능점수(낮은 복잡도 외부출력 3점, 낮은 복잡도 외부참조파일 5점)밖에 산정되지 않는다며 이의를 제기하는 사례가 대표적입니다. 이는 기능적 규모와 기술적 난이도를 혼동하는 데서 비롯되며, 기능점수의 측정 목적과 원칙에 대한 충분한 이해가 중요합니다.
사용자(고객) 측이 산정해야 합니까?
초기 GUIDE 산정 매뉴얼에서는 시니어급 사용자도 훈련을 통해 기능점수를 산정할 수 있다고 언급하고 있습니다. 기능점수 산정은 회계와 유사한 측면이 있습니다. 회계사가 FASB(재무회계기준위원회)의 규칙을 적용하여 재무 건전성을 측정하듯, 기능점수 전문가는 IFPUG 규칙을 적용하여 소프트웨어 규모를 측정합니다.
복잡한 시스템 개발이 대부분의 비즈니스에서 핵심 역량이 된 오늘날, 사용자 측이 필요한 기능 요구사항을 확보하고 개발자와 협의하기 위해서는 기능점수에 대한 이해가 실질적으로 도움이 됩니다.
경험이 풍부한 시니어 인력이 담당해야 합니까?
일반적으로 그렇습니다. 경험이 풍부한 인력은 주요 기능이 누락되지 않도록 적절한 질문을 할 줄 알며, 경험이 부족한 담당자가 간과할 수 있는 문제를 사전에