A. 가능한 한 사업 초기 단계부터 자주 산정하는 것이 좋습니다. 프로젝트가 제공하는 기능을 빠르게 정량화할수록 일정, 비용, 범위를 더 효과적으로 관리할 수 있기 때문입니다. 과거에는 외부 설계(제품 설계)가 완료된 이후에야 기능점수를 산정할 수 있다고 여기는 실무자들이 많았습니다.
그러나 IFPUG 구성원들은 오래전부터 개발 수명 주기 초기에 기능점수를 산정하는 것의 중요성을 인식해 왔습니다. IFPUG CPM 4.0에는 요구사항이 확정된 시점부터 기능점수를 산정할 수 있는 규칙과 지침이 포함되어 있으며, 많은 실무자들은 수명 주기 더 이른 시점에서도 경험적 방법(휴리스틱)을 활용해 규모를 추정하고 있습니다. 아래에서는 수명 주기 각 단계별로 가능한 기능점수 추정 및 산정 방법을 설명합니다. 조직마다 수명 주기 구성이 다를 수 있으므로, 단계는 산출물 기준으로 설명합니다.
타당성 검토 단계 이 단계에서는 기능점수를 정식으로 산정하기 어렵습니다. 그러나 유사 프로젝트의 실적을 기반으로 규모를 추정하는 것은 가능합니다. 예를 들어 과거에 유사한 프로젝트가 2,000 기능점수였다면, 현재 프로젝트의 초기 추정치도 2,000 기능점수로 설정하는 방식이 활용됩니다.
요구사항 수집 단계 이 단계에서는 기능점수 규모 추정치를 점차 구체화할 수 있습니다. 논리적 데이터 모델이 작성되기 시작하면, 분석가는 엔터티를 추가·변경·삭제·조회하는 데 필요한 프로세스를 식별하기 시작할 수 있습니다. 또한 시스템 경계와 외부 인터페이스를 정의하는 다이어그램이 작성되면 사용자 및 외부 시스템과의 상호작용이 구체화됩니다. 이 시점에서 식별된 트랜잭션이 모두 평균 복잡도라고 가정하면, 기능점수 규모를 적절한 수준으로 추정할 수 있으며, 가치 조정 요인도 어느 정도 예측이 가능합니다.
비즈니스 요구사항 완료 시점 요구사항이 완료된 시점에서는 비교적 정확한 기능점수 산정이 가능합니다. 이 시점에는 논리적 데이터 모델이 완전히 정의되어 있어야 하며, 화면·보고서를 포함한 모든 시스템 상호작용과 관련 데이터 항목이 식별되어야 합니다. 화면이나 보고서의 구체적인 형식(레이아웃)이 확정되지 않아도 산정은 가능합니다.
외부 설계(제품 설계) 완료 시점 이 단계에서도 정확한 기능점수 산정이 가능합니다. 요구사항 완료 시점에 이미 정확한 산정이 이루어졌다면, 이 시점에서는 요구사항의 변동성과 그 영향을 분석하는 것이 중요합니다. 예를 들어 요구사항 완료 시 1,000 기능점수로 산정된 프로젝트가 제품 설계 후 1,500 기능점수로 증가했다면, 50% 이상의 범위 증가(Scope Creep)가 발생한 것입니다.
한편 더 주의해야 할 형태의 변동성도 있습니다. 요구사항 완료 시와 설계 완료 시 모두 1,000 기능점수로 동일하게 측정되더라도, 실제로는 초기에 식별된 기능 상당수가 전혀 다른 기능으로 대체된 경우가 있습니다. 규모가 같다는 이유로 이러한 변화가 간과되기 쉽지만, 수명 주기 후반에 발생하는 변경일수록 더 큰 비용을 수반합니다. 이러한 요구사항 교체(Churn) 역시 증분 기능점수(Enhancement Function Point)로 추적하여 프로젝트 재평가 시 그 영향을 적절히 반영해야 합니다.
구현 및 테스트 단계 이론적으로는 제품 설계 완료 이후 인수 테스트 종료 시까지 기능점수에 변화가 없어야 합니다. 그러나 실제로는 이 기간에도 변경 요청이 발생하며, 변경에 드는 비용은 점점 증가합니다. 이 시기에 사용자와 프로젝트 관리자가 기능, 비용, 일정을 상호 조율하는 경우, 기능점수는 이러한 협상을 정량화하는 데 유용하게 활용될 수 있습니다. 다만 올바르게 사용해야 합니다. 예를 들어 100 기능점수 규모의 기능을 추가하고 다른 100 기능점수 규모의 기능을 삭제하는 것을 단순한 등가 교환으로 볼 수 없습니다. 삭제되는 기능에 이미 투입된 작업량도 함께 고려해야 하기 때문입니다.
프로젝트 종료 시점 프로젝트 종료 시에는 기능점수를 최종 업데이트하는 것이 좋습니다. 이 실적 데이터는 향후 프로젝트의 추정 정확도를 높이는 데 활용됩니다. 또한 애플리케이션의 규모는 향후 유지관리에 필요한 지원 수준을 결정하는 근거가 되므로, 사용자 조직은 애플리케이션이 제공하는 비즈니스 가치와 유지관리 비용을 비교하여 지속 운영 여부를 판단해야 합니다.
A. 코드 라인 수(LOC, Lines of Code)는 소프트웨어 규모를 측정하는 전통적인 방법입니다. 일부에서는 개발자가 실제로 수행하는 작업, 즉 코드를 작성하는 행위 자체를 측정한다는 점에서 기능점수와 함께 코드 라인 수를 병행 활용하기도 합니다.
그러나 코드 라인 수의 한계를 지적하는 시각도 있습니다. 소프트웨어 생산성 연구의 권위자인 Capers Jones는 코드 라인 수를 생산성과 품질 측정의 기준으로 삼는 것이 적절하지 않다고 주장한 바 있습니다.
두 방법의 근본적인 차이는 측정 관점에 있습니다. 코드 라인 수는 개발자 관점에서 소프트웨어를 측정하는 반면, 기능점수는 화면, 보고서, 외부 연계 등 사용자에게 제공되는 기능을 기준으로 측정하기 때문에 사용자 관점을 취합니다.
코드 라인 수를 생산성의 주요 척도로 삼을 경우, 개발자들이 코드 라인 수를 늘리는 방향으로 작업하게 되어 코드 재사용 기회를 외면하는 등의 문제가 발생할 수 있습니다. 반면 기능점수를 기준으로 삼으면 개발자의 기능 생산성이 향상되는 경향이 있습니다. 물론 해당 기능이 실질적인 비즈니스 가치를 제공하는지를 평가하는 것은 사용자의 몫입니다.
코드 라인 수에는 기술적인 문제도 있습니다. IBM이 기능점수 활용을 장려하게 된 배경에는 BAL, COBOL, PL/I 등 서로 다른 언어가 혼재하는 이기종 개발 환경이 보편화된 상황이 있었습니다. 오늘날 대부분의 프로젝트는 여러 언어를 혼합하여 사용하며, 이러한 환경에서 코드 라인 수를 일관성 있게 집계하는 것은 더욱 어렵습니다.
또한 코드 라인 수에 대한 표준 정의가 존재하지 않는다는 점도 한계입니다. 빈 줄이나 주석은 포함되는지, 데이터 선언문은 어떻게 처리하는지, 여러 줄에 걸친 구문은 몇 줄로 계산하는지에 대한 기준이 기관마다 다릅니다. 소프트웨어공학연구소(SEI) 등에서 일부 표준화 지침을 제시하였으나 이를 관리하고 발전시키는 주체가 없는 반면, 기능점수는 IFPUG를 중심으로 지속적으로 관리·발전하고 있습니다. 현재 소프트웨어 규모 측정 방법 중 국제 표준으로 인정받은 것은 기능점수 방법이 유일합니다.
A. 예, 가능합니다. 객체 지향 개발 방식으로 구현된 애플리케이션에도 기능점수를 적용할 수 있으며, 동일한 기능을 제공하는 애플리케이션이라면 개발 방식과 관계없이 동일한 규모로 측정됩니다.
이는 기능점수가 애플리케이션의 기능적 규모를 측정하는 지표로, 개발에 사용된 기술이나 방법론과는 독립적으로 산정되기 때문입니다.
다만 객체 지향 개발 방식은 프로젝트의 기능점수 측정 과정에 영향을 미칠 수 있습니다. 예를 들어 객체 지향 기술을 활용하면 사전 구축된 컴포넌트나 외부 라이브러리를 통해 상당한 기능을 애플리케이션에 통합하는 것이 가능합니다. 이처럼 외부에서 제공되는 기능이 포함되는 경우, 해당 기능을 기능점수 측정 범위에 포함할지 여부를 판단하는 데 전문적인 경험과 기준 적용 능력이 요구됩니다.
객체 지향 기술로 개발된 애플리케이션의 측정 사례가 필요하다면, IFPUG(International Function Point Users Group)에서 발간한 사례 연구 자료를 참고하시기 바랍니다.
A. 예, 가능합니다. 기능점수는 사용자 관점에서 소프트웨어의 기능적 규모를 측정하는 방법이므로, 시스템이 클라이언트/서버 구조인지 여부와 관계없이 적용할 수 있습니다. 실제로 사용자는 해당 기능이 단일 시스템에서 수행되는지, 또는 네트워크를 통해 여러 시스템에 분산되어 수행되는지를 인식하지 못하는 경우가 대부분입니다.
다만 클라이언트/서버 환경에서는 데이터 처리와 기능 수행이 여러 계층으로 분리되어 있기 때문에, 시스템 경계를 정의하고 기능을 식별하는 과정에서 추가적인 고려가 필요할 수 있습니다. 특히 데이터베이스, 미들웨어, API 등으로 구성된 기술 인프라는 애플리케이션 기능과 구분하여 판단해야 하며, 경우에 따라 별도의 프로젝트로 다루어질 수 있습니다.
이러한 이유로 클라이언트/서버 기반 시스템은 전통적인 단일 구조의 시스템보다 측정 과정이 다소 복잡해질 수 있습니다. 그러나 기능점수는 기술 구조가 아닌 사용자에게 제공되는 기능을 기준으로 하기 때문에, 일관된 기준으로 적용이 가능합니다.
결론적으로, 클라이언트와 서버는 기술적으로 분리된 구성 요소이지만, 기능점수 측정에서는 사용자 관점에서 하나의 애플리케이션 경계로 식별하여 측정하는 것이 원칙입니다.
A. 예, 가능합니다. 기능점수가 처음 개발되던 시기에는 오늘날과 같은 그래픽 사용자 인터페이스(GUI) 환경이 일반적이지 않았기 때문에, 초기에는 GUI 기반 시스템에 대한 적용 기준이 충분히 정립되어 있지 않았습니다. 이로 인해 GUI 시스템의 기능을 어떻게 측정할 것인지에 대해 실무자 간 해석 차이가 발생하기도 했습니다.
이후 IFPUG는 Function Point Counting Practices Manual Release 4.0을 통해 GUI 기반 시스템에 대한 공식적인 측정 기준과 다양한 사례를 제시하였으며, 관련 사례 연구도 지속적으로 축적해 왔습니다. 현재는 GUI 환경을 포함한 다양한 형태의 시스템에 기능점수를 적용할 수 있는 체계가 충분히 마련되어 있습니다.
다만 일부 실무 현장에서는 과거 기준이나 오래된 교육 자료에 익숙해 최신 기술 환경을 충분히 반영하지 못하는 경우가 있을 수 있습니다. 특히 GUI와 같은 현대적 인터페이스를 기능점수 측정에 어떻게 반영하는지에 대한 이해 수준에 따라 결과의 일관성에 차이가 생길 수 있습니다.
따라서 기능점수 측정은 최신 기준과 실제 적용 경험을 갖춘 전문가에 의해 수행되는 것이 중요합니다.
A. 기능점수(Function Point, FP)는 소프트웨어의 기능적 규모를 사용자 관점에서 측정하는 방법입니다. 즉, 시스템이 사용자에게 제공하는 기능을 기준으로 규모를 정량화하는 방식입니다.
이 개념은 1970년대 후반 IBM의 Allan Albrecht에 의해 처음 제안되었으며, 이후 IFPUG(International Function Point Users Group)를 중심으로 표준화되고 발전해 왔습니다. 현재는 소프트웨어 규모 산정, 사업비 산정, 생산성 분석, 유지관리 기준 수립 등 다양한 분야에서 활용되고 있습니다.
기능점수의 가장 큰 특징은 개발 언어, 개발 방법론, 기술 스택, 개발자의 숙련도와 관계없이 오직 사용자에게 제공되는 기능 자체를 기준으로 측정한다는 점입니다. 따라서 특정 기술이나 환경에 영향을 받지 않고, 보다 객관적인 기준으로 시스템을 비교하고 평가할 수 있습니다.
이러한 특성으로 인해 기능점수는 단순한 규모 측정을 넘어 다양한 의사결정의 기준으로 활용됩니다. 예를 들어 개발 생산성을 비교하거나, 개발 및 유지관리 비용을 추정하고, 아웃소싱 계약의 적정성을 검토하며, 여러 시스템 간 규모를 비교하는 데 활용될 수 있습니다. 또한 결함 수, 투입 공수, 운영 비용과 같은 지표를 규모 기준으로 정규화하여 보다 정확한 분석을 가능하게 합니다.
다만 기능점수는 소프트웨어의 기능적 규모를 측정하는 지표로, 사업의 전체 난이도나 비즈니스 가치를 완전히 대변하는 것은 아닙니다. 동일한 규모의 시스템이라도 기술 복잡도나 품질 요구사항, 운영 환경에 따라 실제 투입 비용과 난이도는 달라질 수 있습니다.
따라서 기능점수는 객관적인 기준이 되는 출발점이며, 이를 기반으로 사업의 특성과 환경을 함께 고려하여 해석하는 것이 중요합니다.
Q. 기능점수는 언제, 어떤 단계로 산정할 수 있나요?
A. 가능한 한 사업 초기 단계부터 자주 산정하는 것이 좋습니다. 프로젝트가 제공하는 기능을 빠르게 정량화할수록 일정, 비용, 범위를 더 효과적으로 관리할 수 있기 때문입니다. 과거에는 외부 설계(제품 설계)가 완료된 이후에야 기능점수를 산정할 수 있다고 여기는 실무자들이 많았습니다.
그러나 IFPUG 구성원들은 오래전부터 개발 수명 주기 초기에 기능점수를 산정하는 것의 중요성을 인식해 왔습니다. IFPUG CPM 4.0에는 요구사항이 확정된 시점부터 기능점수를 산정할 수 있는 규칙과 지침이 포함되어 있으며, 많은 실무자들은 수명 주기 더 이른 시점에서도 경험적 방법(휴리스틱)을 활용해 규모를 추정하고 있습니다. 아래에서는 수명 주기 각 단계별로 가능한 기능점수 추정 및 산정 방법을 설명합니다. 조직마다 수명 주기 구성이 다를 수 있으므로, 단계는 산출물 기준으로 설명합니다.
타당성 검토 단계
이 단계에서는 기능점수를 정식으로 산정하기 어렵습니다. 그러나 유사 프로젝트의 실적을 기반으로 규모를 추정하는 것은 가능합니다. 예를 들어 과거에 유사한 프로젝트가 2,000 기능점수였다면, 현재 프로젝트의 초기 추정치도 2,000 기능점수로 설정하는 방식이 활용됩니다.
요구사항 수집 단계
이 단계에서는 기능점수 규모 추정치를 점차 구체화할 수 있습니다. 논리적 데이터 모델이 작성되기 시작하면, 분석가는 엔터티를 추가·변경·삭제·조회하는 데 필요한 프로세스를 식별하기 시작할 수 있습니다. 또한 시스템 경계와 외부 인터페이스를 정의하는 다이어그램이 작성되면 사용자 및 외부 시스템과의 상호작용이 구체화됩니다. 이 시점에서 식별된 트랜잭션이 모두 평균 복잡도라고 가정하면, 기능점수 규모를 적절한 수준으로 추정할 수 있으며, 가치 조정 요인도 어느 정도 예측이 가능합니다.
비즈니스 요구사항 완료 시점
요구사항이 완료된 시점에서는 비교적 정확한 기능점수 산정이 가능합니다. 이 시점에는 논리적 데이터 모델이 완전히 정의되어 있어야 하며, 화면·보고서를 포함한 모든 시스템 상호작용과 관련 데이터 항목이 식별되어야 합니다. 화면이나 보고서의 구체적인 형식(레이아웃)이 확정되지 않아도 산정은 가능합니다.
외부 설계(제품 설계) 완료 시점
이 단계에서도 정확한 기능점수 산정이 가능합니다. 요구사항 완료 시점에 이미 정확한 산정이 이루어졌다면, 이 시점에서는 요구사항의 변동성과 그 영향을 분석하는 것이 중요합니다. 예를 들어 요구사항 완료 시 1,000 기능점수로 산정된 프로젝트가 제품 설계 후 1,500 기능점수로 증가했다면, 50% 이상의 범위 증가(Scope Creep)가 발생한 것입니다.
한편 더 주의해야 할 형태의 변동성도 있습니다. 요구사항 완료 시와 설계 완료 시 모두 1,000 기능점수로 동일하게 측정되더라도, 실제로는 초기에 식별된 기능 상당수가 전혀 다른 기능으로 대체된 경우가 있습니다. 규모가 같다는 이유로 이러한 변화가 간과되기 쉽지만, 수명 주기 후반에 발생하는 변경일수록 더 큰 비용을 수반합니다. 이러한 요구사항 교체(Churn) 역시 증분 기능점수(Enhancement Function Point)로 추적하여 프로젝트 재평가 시 그 영향을 적절히 반영해야 합니다.
구현 및 테스트 단계
이론적으로는 제품 설계 완료 이후 인수 테스트 종료 시까지 기능점수에 변화가 없어야 합니다. 그러나 실제로는 이 기간에도 변경 요청이 발생하며, 변경에 드는 비용은 점점 증가합니다. 이 시기에 사용자와 프로젝트 관리자가 기능, 비용, 일정을 상호 조율하는 경우, 기능점수는 이러한 협상을 정량화하는 데 유용하게 활용될 수 있습니다. 다만 올바르게 사용해야 합니다. 예를 들어 100 기능점수 규모의 기능을 추가하고 다른 100 기능점수 규모의 기능을 삭제하는 것을 단순한 등가 교환으로 볼 수 없습니다. 삭제되는 기능에 이미 투입된 작업량도 함께 고려해야 하기 때문입니다.
프로젝트 종료 시점
프로젝트 종료 시에는 기능점수를 최종 업데이트하는 것이 좋습니다. 이 실적 데이터는 향후 프로젝트의 추정 정확도를 높이는 데 활용됩니다. 또한 애플리케이션의 규모는 향후 유지관리에 필요한 지원 수준을 결정하는 근거가 되므로, 사용자 조직은 애플리케이션이 제공하는 비즈니스 가치와 유지관리 비용을 비교하여 지속 운영 여부를 판단해야 합니다.
Q. 기능점수와 코드 라인 수(LOC)는 어떻게 다른가요?
A. 코드 라인 수(LOC, Lines of Code)는 소프트웨어 규모를 측정하는 전통적인 방법입니다. 일부에서는 개발자가 실제로 수행하는 작업, 즉 코드를 작성하는 행위 자체를 측정한다는 점에서 기능점수와 함께 코드 라인 수를 병행 활용하기도 합니다.
그러나 코드 라인 수의 한계를 지적하는 시각도 있습니다. 소프트웨어 생산성 연구의 권위자인 Capers Jones는 코드 라인 수를 생산성과 품질 측정의 기준으로 삼는 것이 적절하지 않다고 주장한 바 있습니다.
두 방법의 근본적인 차이는 측정 관점에 있습니다. 코드 라인 수는 개발자 관점에서 소프트웨어를 측정하는 반면, 기능점수는 화면, 보고서, 외부 연계 등 사용자에게 제공되는 기능을 기준으로 측정하기 때문에 사용자 관점을 취합니다.
코드 라인 수를 생산성의 주요 척도로 삼을 경우, 개발자들이 코드 라인 수를 늘리는 방향으로 작업하게 되어 코드 재사용 기회를 외면하는 등의 문제가 발생할 수 있습니다. 반면 기능점수를 기준으로 삼으면 개발자의 기능 생산성이 향상되는 경향이 있습니다. 물론 해당 기능이 실질적인 비즈니스 가치를 제공하는지를 평가하는 것은 사용자의 몫입니다.
코드 라인 수에는 기술적인 문제도 있습니다. IBM이 기능점수 활용을 장려하게 된 배경에는 BAL, COBOL, PL/I 등 서로 다른 언어가 혼재하는 이기종 개발 환경이 보편화된 상황이 있었습니다. 오늘날 대부분의 프로젝트는 여러 언어를 혼합하여 사용하며, 이러한 환경에서 코드 라인 수를 일관성 있게 집계하는 것은 더욱 어렵습니다.
또한 코드 라인 수에 대한 표준 정의가 존재하지 않는다는 점도 한계입니다. 빈 줄이나 주석은 포함되는지, 데이터 선언문은 어떻게 처리하는지, 여러 줄에 걸친 구문은 몇 줄로 계산하는지에 대한 기준이 기관마다 다릅니다. 소프트웨어공학연구소(SEI) 등에서 일부 표준화 지침을 제시하였으나 이를 관리하고 발전시키는 주체가 없는 반면, 기능점수는 IFPUG를 중심으로 지속적으로 관리·발전하고 있습니다. 현재 소프트웨어 규모 측정 방법 중 국제 표준으로 인정받은 것은 기능점수 방법이 유일합니다.
Q. 기능점수를 객체 지향 개발에도 적용할 수 있나요?
A. 예, 가능합니다. 객체 지향 개발 방식으로 구현된 애플리케이션에도 기능점수를 적용할 수 있으며, 동일한 기능을 제공하는 애플리케이션이라면 개발 방식과 관계없이 동일한 규모로 측정됩니다.
이는 기능점수가 애플리케이션의 기능적 규모를 측정하는 지표로, 개발에 사용된 기술이나 방법론과는 독립적으로 산정되기 때문입니다.
다만 객체 지향 개발 방식은 프로젝트의 기능점수 측정 과정에 영향을 미칠 수 있습니다. 예를 들어 객체 지향 기술을 활용하면 사전 구축된 컴포넌트나 외부 라이브러리를 통해 상당한 기능을 애플리케이션에 통합하는 것이 가능합니다. 이처럼 외부에서 제공되는 기능이 포함되는 경우, 해당 기능을 기능점수 측정 범위에 포함할지 여부를 판단하는 데 전문적인 경험과 기준 적용 능력이 요구됩니다.
객체 지향 기술로 개발된 애플리케이션의 측정 사례가 필요하다면, IFPUG(International Function Point Users Group)에서 발간한 사례 연구 자료를 참고하시기 바랍니다.
Q. 기능점수를 클라이언트/서버 시스템에도 적용할 수 있나요?
A. 예, 가능합니다. 기능점수는 사용자 관점에서 소프트웨어의 기능적 규모를 측정하는 방법이므로, 시스템이 클라이언트/서버 구조인지 여부와 관계없이 적용할 수 있습니다. 실제로 사용자는 해당 기능이 단일 시스템에서 수행되는지, 또는 네트워크를 통해 여러 시스템에 분산되어 수행되는지를 인식하지 못하는 경우가 대부분입니다.
다만 클라이언트/서버 환경에서는 데이터 처리와 기능 수행이 여러 계층으로 분리되어 있기 때문에, 시스템 경계를 정의하고 기능을 식별하는 과정에서 추가적인 고려가 필요할 수 있습니다. 특히 데이터베이스, 미들웨어, API 등으로 구성된 기술 인프라는 애플리케이션 기능과 구분하여 판단해야 하며, 경우에 따라 별도의 프로젝트로 다루어질 수 있습니다.
이러한 이유로 클라이언트/서버 기반 시스템은 전통적인 단일 구조의 시스템보다 측정 과정이 다소 복잡해질 수 있습니다. 그러나 기능점수는 기술 구조가 아닌 사용자에게 제공되는 기능을 기준으로 하기 때문에, 일관된 기준으로 적용이 가능합니다.
결론적으로, 클라이언트와 서버는 기술적으로 분리된 구성 요소이지만, 기능점수 측정에서는 사용자 관점에서 하나의 애플리케이션 경계로 식별하여 측정하는 것이 원칙입니다.
Q. GUI 기반 시스템에도 기능점수를 적용할 수 있나요?
A. 예, 가능합니다. 기능점수가 처음 개발되던 시기에는 오늘날과 같은 그래픽 사용자 인터페이스(GUI) 환경이 일반적이지 않았기 때문에, 초기에는 GUI 기반 시스템에 대한 적용 기준이 충분히 정립되어 있지 않았습니다. 이로 인해 GUI 시스템의 기능을 어떻게 측정할 것인지에 대해 실무자 간 해석 차이가 발생하기도 했습니다.
이후 IFPUG는 Function Point Counting Practices Manual Release 4.0을 통해 GUI 기반 시스템에 대한 공식적인 측정 기준과 다양한 사례를 제시하였으며, 관련 사례 연구도 지속적으로 축적해 왔습니다. 현재는 GUI 환경을 포함한 다양한 형태의 시스템에 기능점수를 적용할 수 있는 체계가 충분히 마련되어 있습니다.
다만 일부 실무 현장에서는 과거 기준이나 오래된 교육 자료에 익숙해 최신 기술 환경을 충분히 반영하지 못하는 경우가 있을 수 있습니다. 특히 GUI와 같은 현대적 인터페이스를 기능점수 측정에 어떻게 반영하는지에 대한 이해 수준에 따라 결과의 일관성에 차이가 생길 수 있습니다.
따라서 기능점수 측정은 최신 기준과 실제 적용 경험을 갖춘 전문가에 의해 수행되는 것이 중요합니다.
Q. 기능점수(Function Point)는 무엇이며, 왜 산정하나요?
A. 기능점수(Function Point, FP)는 소프트웨어의 기능적 규모를 사용자 관점에서 측정하는 방법입니다. 즉, 시스템이 사용자에게 제공하는 기능을 기준으로 규모를 정량화하는 방식입니다.
이 개념은 1970년대 후반 IBM의 Allan Albrecht에 의해 처음 제안되었으며, 이후 IFPUG(International Function Point Users Group)를 중심으로 표준화되고 발전해 왔습니다. 현재는 소프트웨어 규모 산정, 사업비 산정, 생산성 분석, 유지관리 기준 수립 등 다양한 분야에서 활용되고 있습니다.
기능점수의 가장 큰 특징은 개발 언어, 개발 방법론, 기술 스택, 개발자의 숙련도와 관계없이 오직 사용자에게 제공되는 기능 자체를 기준으로 측정한다는 점입니다. 따라서 특정 기술이나 환경에 영향을 받지 않고, 보다 객관적인 기준으로 시스템을 비교하고 평가할 수 있습니다.
이러한 특성으로 인해 기능점수는 단순한 규모 측정을 넘어 다양한 의사결정의 기준으로 활용됩니다. 예를 들어 개발 생산성을 비교하거나, 개발 및 유지관리 비용을 추정하고, 아웃소싱 계약의 적정성을 검토하며, 여러 시스템 간 규모를 비교하는 데 활용될 수 있습니다. 또한 결함 수, 투입 공수, 운영 비용과 같은 지표를 규모 기준으로 정규화하여 보다 정확한 분석을 가능하게 합니다.
다만 기능점수는 소프트웨어의 기능적 규모를 측정하는 지표로, 사업의 전체 난이도나 비즈니스 가치를 완전히 대변하는 것은 아닙니다. 동일한 규모의 시스템이라도 기술 복잡도나 품질 요구사항, 운영 환경에 따라 실제 투입 비용과 난이도는 달라질 수 있습니다.
따라서 기능점수는 객관적인 기준이 되는 출발점이며, 이를 기반으로 사업의 특성과 환경을 함께 고려하여 해석하는 것이 중요합니다.