기능점수(Function Point, FP) 분석
1. 개요
가. 정의
기능점수(Function Point, FP) 는 소프트웨어가 사용자에게 제공하는 기능(functionality)의 양을, 구현 언어·기술·플랫폼과 무관하게 정량적으로 측정하는 기능 규모 측정(Functional Size Measurement, FSM) 방법이다. 사용자 요구를 데이터 기능과 트랜잭션 기능으로 식별하고 각 기능의 복잡도에 가중치를 부여해 합산함으로써, 코드가 한 줄도 쓰이기 전에 '만들어야 할 일의 크기'를 숫자로 환산한다.
기능점수의 출발점은 소프트웨어 규모를 '무엇으로 재는가'라는 근본 질문이다. 전통적인 LOC(Lines of Code)는 완성된 코드의 양을 세지만, 같은 기능을 어셈블리로 짜면 수천 줄, 고수준 언어로 짜면 수십 줄이 되어 생산성이 높을수록 규모가 작게 잡히는 역설이 발생한다. 또한 코드는 개발이 끝나야 셀 수 있어 '착수 전 예측'이라는 산정의 본래 목적과 충돌한다. 기능점수는 측정의 기준을 '코드'에서 '사용자가 체감하는 기능'으로 옮김으로써 이 역설을 해소한다. 사용자 입장에서 '고객 등록', '월별 매출 조회'가 제공하는 가치는 구현 기술이 무엇이든 동일하므로, 기능으로 규모를 재면 기술 중립적이고 비교 가능한 척도를 얻는다.
이 전환이 가지는 의미는 크다. 기능점수는 단순한 산정 보조 수단이 아니라, 소프트웨어를 '측정 가능한 공학적 대상'으로 다루기 위한 메타포다. 서로 다른 언어·프레임워크로 개발된 두 시스템의 생산성(FP/Man-Month)이나 결함밀도(결함/FP)를 같은 잣대로 비교할 수 있게 되고, 발주자와 수행사가 '얼마짜리 사업인가'를 두고 벌이는 소모적 논쟁을 객관적 규모라는 공통 언어로 바꾼다. 국내 공공 정보화 사업이 기능점수를 대가 산정의 법정 표준으로 채택한 이유도 여기에 있다.
나. 등장 배경과 필요성
기능점수는 1979년 IBM의 앨런 알브레히트(Allan J. Albrecht)가 제안했다. 당시 IBM 내부에서는 서로 다른 언어로 개발된 애플리케이션들의 개발 생산성을 비교할 공통 척도가 없어, LOC 기반 비교가 언어 차이에 오염되는 문제가 심각했다. 알브레히트는 "사용자에게 전달되는 기능의 양"을 재면 언어에 독립적인 생산성 지표를 얻을 수 있다는 통찰에서 기능점수를 고안했고, 이후 1986년 IFPUG(International Function Point Users Group) 가 결성되어 측정 규칙을 표준화·정교화했다. 현재 IFPUG의 측정 규칙은 CPM(Counting Practices Manual) 으로 관리되며, ISO/IEC 20926으로 국제표준화되었다.
국내에서는 공공 소프트웨어 사업의 예산 적정성과 발주 투명성이 감사·감리의 핵심 쟁점이 되면서 기능점수의 필요성이 더욱 부각되었다. 과거 투입공수(Man-Month) 기반 대가 산정은 '사람을 얼마나 오래 투입했는가'를 근거로 삼아, 생산성이 낮을수록 대가가 커지는 역유인과 분쟁을 낳았다. 이에 정부는 SW사업 대가산정 가이드를 통해 개발비를 기능점수 기반으로 산정하도록 정착시켰고, 결과물(기능)의 규모에 비용을 연동함으로써 생산성 향상을 보상하는 구조를 만들었다. 즉 기능점수는 기술적 측정 기법인 동시에, 공정한 거래 질서를 떠받치는 제도적 인프라다.
다. 기능점수가 갖는 본질적 특성
기능점수가 좋은 규모 척도로 기능하려면 몇 가지 성질을 갖춰야 하며, 실제로 그렇게 설계되어 있다. 첫째 기술 독립성 — 측정 대상은 사용자 요구이지 구현이 아니므로 언어·DBMS·아키텍처에 좌우되지 않는다. 둘째 조기 적용성 — 요구사항·기능 명세가 정리되는 분석 단계부터 측정할 수 있어 발주·계약 시점에 근거를 제공한다. 셋째 반복 가능성 — 측정 규칙이 문서화되어 있어 서로 다른 측정자가 재어도 유사한 결과에 수렴한다(다만 완전한 객관성은 아니며 측정자 숙련도에 따른 편차는 존재한다).
반면 한계도 분명하다. 기능점수는 사용자에게 보이는 기능을 재므로, 성능·보안·가용성 같은 비기능 요구나 복잡한 알고리즘(예: 영상 압축, 수치해석)의 내부 난도는 잘 포착하지 못한다. 겉보기 기능은 단순한 '계산 한 번'이지만 그 안에 들어가는 알고리즘적 노력이 막대한 경우, 기능점수는 그 노력을 과소평가한다. 이 간극을 메우기 위해 뒤에서 다룰 SNAP(비기능 규모 측정)이나 COSMIC(실시간·임베디드 특화) 같은 보완·대안 기법이 등장했다.
2. 기능점수 산정의 전체 구조와 측정 절차
기능점수 측정은 소프트웨어의 기능을 데이터 기능과 트랜잭션 기능으로 나누어 식별하고, 각각의 복잡도를 평가해 가중치를 합산하는 체계적 절차를 따른다. 전체 구조는 다음과 같다.
flowchart TB
FP["기능점수(FP)"] --> DF["데이터 기능(Data Function)<br/>저장·유지되는 데이터의 규모"]
FP --> TF["트랜잭션 기능(Transaction Function)<br/>처리·이동하는 프로세스의 규모"]
DF --> ILF["내부논리파일(ILF)<br/>시스템이 유지·관리하는 데이터"]
DF --> EIF["외부연계파일(EIF)<br/>외부가 유지, 참조만 하는 데이터"]
TF --> EI["외부입력(EI)<br/>데이터를 변경하는 입력"]
TF --> EO["외부출력(EO)<br/>가공·계산된 출력"]
TF --> EQ["외부조회(EQ)<br/>단순 조회·검색"]
style DF fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style TF fill:#fff3e0,stroke:#e8890c,stroke-width:2px
위 다섯 유형은 소프트웨어를 '데이터를 담는 그릇(파일)'과 '그 데이터를 다루는 일(트랜잭션)'이라는 두 축으로 분해한 결과다. 데이터 기능은 시스템이 책임지고 유지·관리하는 데이터의 묶음을 센다. 그 데이터를 시스템 내부에서 생성·수정·삭제까지 책임지면 ILF, 다른 시스템이 관리하고 우리는 읽기만 하면 EIF 다. 트랜잭션 기능은 경계를 넘나드는 처리 단위를 세며, 데이터를 변경시키면 EI, 가공·계산해 내보내면 EO, 계산 없이 있는 그대로 보여주면 EQ 로 구분한다. 이 분류의 묘미는 '기능'이라는 모호한 개념을 측정 가능한 다섯 범주로 환원했다는 점에 있다.
측정은 다음 절차로 진행된다. 전체 흐름은 측정 유형과 경계를 먼저 정하고, 기능을 식별·분류한 뒤, 복잡도를 매겨 미조정 기능점수를 구하고, 필요 시 조정인자를 적용해 확정하는 순서다.
flowchart LR
A["측정 유형·목적 결정"] --> B["측정 경계(Boundary) 설정"]
B --> C["데이터·트랜잭션 기능 식별"]
C --> D["각 기능 복잡도 평가<br/>(Low/Average/High)"]
D --> E["가중치 합산 = 미조정 FP(UFP)"]
E --> F["조정인자(VAF) 적용"]
F --> G["조정 기능점수(AFP) 확정"]
style E fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style G fill:#e6f4ea,stroke:#1e8e3e,stroke-width:2px
가. 측정 유형 결정과 경계 설정
측정의 첫 단계는 '무엇을 재는가'를 정하는 일이다. IFPUG는 측정 유형을 신규 개발(Development), 기능 개선(Enhancement), 기존 애플리케이션(Application) 세 가지로 구분한다. 신규 개발은 처음 만드는 기능 전체를, 개선은 추가·변경·삭제되는 기능만을, 애플리케이션은 현재 운영 중인 시스템이 제공하는 기능 전체를 센다. 유지보수 대가나 재개발 타당성을 따질 때 '현재 시스템의 규모'가 필요하므로 애플리케이션 측정은 실무에서 매우 자주 쓰인다.
다음으로 측정 경계(Application Boundary) 를 설정한다. 경계란 '측정 대상 시스템'과 '그 바깥(사용자·타 시스템)'을 가르는 논리적 선으로, 데이터와 처리가 이 경계를 넘나드는지에 따라 기능 유형이 결정된다. 예를 들어 어떤 데이터를 우리 시스템이 직접 관리하면 ILF로 경계 안에 있고, 타 기관 시스템이 관리하는 것을 참조만 하면 경계 밖의 EIF가 된다. 경계를 어디에 긋느냐에 따라 같은 기능이 다른 유형으로 잡힐 수 있어, 경계 설정은 측정 결과를 좌우하는 가장 중요한 설계 결정이다. 잘못된 경계는 기능의 중복 계수나 누락을 초래하므로, 사용자 관점과 업무 책임 소재를 기준으로 일관되게 그어야 한다.
경계 설정의 실무 난점은 마이크로서비스·API 중심 아키텍처에서 두드러진다. 하나의 업무 기능이 여러 서비스에 흩어져 있을 때, 각 서비스를 독립 경계로 볼지 하나의 애플리케이션으로 볼지에 따라 EIF·내부호출의 계수가 달라진다. 이때는 '사용자에게 하나의 애플리케이션으로 인식되는 단위'를 경계로 삼되, 조직·계약·운영 책임의 분할선과 맞추는 것이 분쟁을 줄인다.
나. 데이터 기능(ILF·EIF)
데이터 기능은 시스템이 다루는 논리적 데이터 그룹을 센다. 여기서 '논리적'이라는 수식이 핵심인데, 물리적 테이블 개수가 아니라 사용자 관점에서 하나의 의미 단위로 인식되는 데이터 묶음을 센다는 뜻이다. 예컨대 정규화로 '고객'이 고객기본·고객연락처·고객등급 세 테이블로 쪼개져 있어도, 사용자에게는 하나의 '고객 정보'이므로 하나의 ILF로 계수한다. 이 원칙 덕분에 기능점수는 물리 설계(정규화 수준, 인덱스 전략)에 좌우되지 않는다.
내부논리파일(ILF, Internal Logical File) 은 측정 대상 시스템이 스스로 생성·수정·삭제하며 유지·관리하는 데이터 그룹이다. 주문 시스템의 '주문', '상품', '회원'이 대표적이다. 반면 외부연계파일(EIF, External Interface File) 은 다른 시스템이 ILF로 유지·관리하는 데이터를, 우리 시스템은 참조(읽기)만 하는 경우다. 예를 들어 주문 시스템이 결제 시스템의 '카드사 코드' 테이블을 조회만 한다면 그것은 EIF다. 동일한 데이터라도 책임 소재(누가 유지하는가)에 따라 ILF와 EIF로 갈린다는 점이 중요하다. 한 시스템의 ILF는 그 데이터를 참조하는 다른 시스템에게는 EIF가 된다.
데이터 기능의 복잡도는 두 지표로 결정된다. DET(Data Element Type) 는 사용자가 인식하는 고유한 필드(속성)의 수이고, RET(Record Element Type) 는 그 데이터 그룹 안의 하위 그룹(부분집합)의 수다. 예컨대 '고객'에 개인고객·법인고객 두 하위 유형이 있으면 RET=2가 된다. DET가 많을수록, RET가 많을수록 복잡도가 올라가며, 이 둘의 조합으로 Low/Average/High가 결정된다. 데이터 기능에 더 높은 가중치(ILF 7~15)가 부여되는 이유는, 데이터를 유지·관리하는 일이 단순 처리보다 설계·정합성 측면에서 더 큰 노력을 수반한다는 경험칙 때문이다.
다. 트랜잭션 기능(EI·EO·EQ)
트랜잭션 기능은 경계를 넘나드는 기본 처리 단위(Elementary Process) 를 센다. 기본 처리란 사용자에게 의미 있는 가장 작은 완결된 활동으로, '일부만 수행되면 업무적으로 불완전한' 단위를 말한다. '회원 가입'이 중간에 끊기면 아무 의미가 없듯, 하나의 완결된 업무가 하나의 트랜잭션 기능이다.
외부입력(EI, External Input) 은 경계 밖에서 데이터·제어정보가 들어와 ILF를 변경(생성·수정·삭제)하거나 시스템 동작을 바꾸는 처리다. '상품 등록', '주문 취소', '비밀번호 변경'이 전형적인 EI다. 외부출력(EO, External Output) 은 데이터를 경계 밖으로 내보내되, 계산·가공·파생 로직이 포함된 출력이다. '월별 매출 집계표', '손익계산서'처럼 합계·비율·파생값을 만들어 내보내면 EO다. 외부조회(EQ, External Inquiry) 는 계산 없이 저장된 데이터를 있는 그대로 검색·조회해 보여주는 처리다. '회원 정보 상세 조회', '상품 목록 검색'이 EQ다. EO와 EQ를 가르는 결정적 기준은 '파생 데이터나 계산 로직의 유무'이며, 이 구분이 모호할 때 측정자 간 편차가 가장 크게 발생한다.
트랜잭션 기능의 복잡도는 FTR(File Type Referenced, 참조하는 파일 수) 과 DET(처리에 관여하는 데이터 요소 수) 로 결정된다. 하나의 처리가 많은 파일을 참조하고 많은 필드를 다룰수록 복잡도가 높아진다. 예를 들어 '주문 생성' EI가 주문·상품·재고·회원 네 ILF를 참조하면 FTR=4로 High 쪽에 가까워진다. 트랜잭션 기능의 가중치가 데이터 기능보다 낮게 설정된 것(EI 3~6 등)은, 처리 로직 하나하나보다 데이터 구조의 유지·관리가 더 근본적인 노력이라는 설계 철학을 반영한다.
3. 복잡도 평가와 기능점수 계산
가. 복잡도 매트릭스와 가중치
식별된 각 기능은 복잡도(Low/Average/High)에 따라 다음 가중치를 받는다. 이 표는 IFPUG가 수많은 프로젝트 데이터를 회귀분석해 정한 값으로, 데이터 기능이 트랜잭션 기능보다, High가 Low보다 더 큰 노력을 요구한다는 경험적 사실을 수치화한 것이다.
| 기능 유형 | Low | Average | High | 비고 |
|---|---|---|---|---|
| ILF(내부논리파일) | 7 | 10 | 15 | DET·RET로 복잡도 결정 |
| EIF(외부연계파일) | 5 | 7 | 10 | 참조 전용, ILF보다 낮음 |
| EI(외부입력) | 3 | 4 | 6 | FTR·DET로 결정 |
| EO(외부출력) | 4 | 5 | 7 | 계산·가공 포함 |
| EQ(외부조회) | 3 | 4 | 6 | 단순 조회 |
가중치의 상대적 크기 자체가 많은 것을 말해 준다. ILF의 High(15)는 EQ의 Low(3)의 다섯 배인데, 이는 '데이터를 책임지고 관리하는 복잡한 마스터'가 '단순 조회 화면'보다 다섯 배의 노력을 요한다는 경험칙이다. 측정자는 이 표를 기계적으로 적용하되, 각 기능을 어느 복잡도로 분류하느냐가 결과를 좌우하므로 DET·RET·FTR 산정에 일관된 기준을 유지해야 한다.
복잡도 판정의 실제를 보면, 데이터 기능은 DET와 RET의 조합으로 3단계 복잡도 매트릭스에 대입한다. 예컨대 ILF에서 DET가 1~19개이면서 RET가 1개이면 Low, DET가 많거나 RET가 여러 개면 Average·High로 올라간다. 트랜잭션 기능도 마찬가지로 FTR과 DET의 조합표를 쓴다. 중요한 것은 이 경계값(threshold) 자체를 외우는 것이 아니라, '복잡도는 참조 범위(파일·레코드)와 데이터 요소의 양이라는 두 축으로 결정된다'는 원리를 이해하는 것이다. 같은 '회원 등록' EI라도 다루는 필드가 수십 개이고 여러 파일을 갱신하면 High, 몇 개 필드만 단일 파일에 넣으면 Low가 된다.
이 복잡도 구분이 실무에서 중요한 이유는, 전체 기능점수의 상당 부분이 소수의 High 기능에서 나오기 때문이다. 수십 개의 단순 조회(EQ Low)보다 핵심 업무 마스터(ILF High) 몇 개가 규모와 노력을 좌우하는 경우가 많다. 따라서 측정 품질을 높이려면 모든 기능에 균등한 주의를 쏟기보다, 복잡도가 높은 핵심 기능의 식별·판정에 검증 역량을 집중하는 것이 효율적이다.
나. 미조정 기능점수(UFP)와 조정인자(VAF)
식별된 모든 기능의 가중치를 합한 값이 미조정 기능점수(UFP, Unadjusted Function Point) 다. UFP는 순수하게 기능 규모만을 나타내며, ISO/IEC 20926은 바로 이 UFP를 공식적인 '기능 규모'로 정의한다.
IFPUG 방식은 여기에 선택적으로 조정인자(VAF, Value Adjustment Factor) 를 곱해 조정 기능점수(AFP, Adjusted Function Point) 를 구한다. VAF는 데이터 통신, 분산 처리, 성능, 과부하 구성, 트랜잭션율, 온라인 입력, 최종사용자 효율, 온라인 갱신, 복잡한 처리, 재사용성, 설치 용이성, 운영 용이성, 다중 사이트, 변경 용이성이라는 14개의 일반시스템특성(GSC) 을 각 0~5점으로 평가해 산출한다. 계산식은 VAF = 0.65 + 0.01 × ∑(14개 GSC 점수) 로, 모든 특성이 평균(각 미미)이면 VAF≈1에 수렴하고 최대 ±35%의 보정이 가능하다. AFP = UFP × VAF 가 최종 기능점수다.
다만 VAF는 논쟁적이다. 14개 특성이 1980년대 기술 환경(메인프레임·배치)을 전제로 만들어져 현대의 클라우드·웹 환경과 맞지 않고, 비기능 요구를 '14개로 뭉뚱그린' 보정이 과학적 근거가 약하다는 비판이 많다. 이 때문에 ISO FSM 표준과 국내 SW사업 대가산정 가이드는 VAF를 사용하지 않고 UFP(미조정 기능점수)만을 규모로 채택하며, 비기능 요소는 별도의 보정계수나 SNAP으로 다룬다. 기술사 답안에서는 "VAF는 IFPUG의 선택적 조정일 뿐, 국내 표준은 UFP 기준"이라는 점을 정확히 구분해 서술하는 것이 중요하다.
다. 정통법(정규법)과 간이법
실무에서 기능점수를 재는 방식은 정밀도와 측정 시점에 따라 두 갈래로 나뉜다. 둘의 차이는 '각 기능의 복잡도를 개별 평가하느냐, 평균값으로 일괄 적용하느냐'에 있다.
| 구분 | 정통법(정규법, IFPUG) | 간이법(국내 대가산정) |
|---|---|---|
| 복잡도 평가 | 기능별 DET·RET·FTR로 Low/Avg/High 개별 산정 | 평균 복잡도 가중치 일괄 적용 |
| 정밀도 | 높음 | 낮음(근사치) |
| 적용 시점 | 설계가 어느 정도 구체화된 후 | 요구사항 수준의 초기 |
| 노력·비용 | 큼(측정 전문성 요구) | 작음(신속) |
| 국내 활용 | 상세 검증·정산 | 예산 수립·발주 단계 표준 |
간이법은 각 기능의 복잡도를 일일이 따지지 않고 유형별 평균 가중치(예: ILF 평균, EI 평균)를 적용한다. 요구사항만 정리되면 빠르게 규모를 추정할 수 있어, 상세 설계 전인 예산 수립·사업 발주 단계에 적합하다. 국내 SW사업 대가산정 가이드가 공공사업 예산 산정의 기본으로 간이법을 채택한 이유가 바로 이 조기 적용성에 있다. 반면 정통법(정규법) 은 기능마다 DET·RET·FTR을 분석해 복잡도를 개별 판정하므로 정밀하지만, 설계가 구체화된 뒤라야 측정이 가능하고 전문 인력과 시간이 든다. 실무에서는 발주 시 간이법으로 예산을 잡고, 설계 완료 후 정통법으로 정산·검증하는 2단계 운용이 흔하다.
간단한 수치 예로 감을 잡아 보자. 어떤 시스템을 간이법으로 재어 평균 가중치 기준 ILF 5개(평균 10) = 50, EIF 2개(평균 7) = 14, EI 20개(평균 4) = 80, EO 10개(평균 5) = 50, EQ 15개(평균 4) = 60 으로 식별했다면 UFP = 50+14+80+50+60 = 254 FP 가 된다. 국내 대가산정에서는 이 254 FP에 한국소프트웨어산업협회가 매년 공표하는 기능점수당 단가(FP 단가) 와 각종 보정계수(규모·연계·성능·운영환경 등)를 곱해 개발원가를 산출한다. 단가는 물가·임금 변동을 반영해 매년 갱신되므로, 답안에서는 특정 금액을 단정하기보다 '협회가 공표하는 당해 연도 단가를 적용한다'고 서술하는 것이 안전하다.
4. 비교 및 적용 사례
기능점수의 위상을 이해하려면 경쟁·대안 척도와의 비교가 필요하다. LOC 대비 기능점수의 핵심 우위는 기술 독립성과 조기 적용성이다. LOC는 개발 완료 후에야 정확히 셀 수 있고 언어·생산성에 오염되지만, FP는 요구 단계에서 언어와 무관하게 측정된다. 반대로 LOC는 자동 집계가 쉽고 측정자 주관이 개입하지 않는 반면, FP는 측정자 숙련도에 따라 결과가 10% 안팎 흔들릴 수 있다는 약점이 있다. 그래서 두 지표는 '생산성(LOC/FP, 언어별 변환계수)'이라는 형태로 서로를 보완하며, Capers Jones의 언어별 LOC/FP 테이블이 그 대표적 변환 도구다.
COCOMO(LOC 기반 모델) 대비 기능점수는 '규모 측정'과 '공수 환산'의 역할이 다르다. COCOMO는 규모(KLOC)를 입력받아 공수를 계산하는 모델이고, FP는 규모 자체를 재는 방법이다. 실제로 COCOMO II는 초기 단계 입력으로 FP를 받아 LOC로 환산(backfiring)해 쓰기도 한다. 즉 둘은 경쟁이 아니라 'FP로 규모를 재고 → 모델로 공수를 환산'하는 파이프라인으로 결합된다.
COSMIC(ISO/IEC 19761) 대비 기능점수는 적용 도메인에서 갈린다. IFPUG FP는 데이터 중심의 경영정보시스템(MIS)에 강하지만, 데이터 이동(Entry·Exit·Read·Write)만으로 규모를 재는 COSMIC은 실시간·임베디드·제어 소프트웨어에 더 적합하다. 겉보기 데이터는 적지만 내부 데이터 이동이 빈번한 통신·제어 시스템에서는 IFPUG FP가 규모를 과소평가하는 경향이 있어 COSMIC이 선호된다.
구체적 산업 적용 사례로, 국내 공공 차세대 시스템 구축에서는 요구사항정의서(RFP)를 기준으로 간이법 FP를 산정해 사업 예산을 확정하고, 설계 완료 시점에 기능점수를 재산정해 과업 변경(증감)을 정량적으로 정산한다. 금융권에서는 벤더 성과를 비교하기 위해 '개발 생산성 = 인도 FP / 투입 Man-Month', '품질 = 결함 수 / FP' 같은 FP 정규화 지표를 KPI로 삼아, 서로 다른 언어·팀의 성과를 같은 잣대로 평가한다. 글로벌 아웃소싱 계약에서도 'FP당 단가' 방식의 성과 기반 계약(Price-per-FP)이 투입공수 기반 계약을 대체하며, 생산성 향상의 이익이 발주자에게 돌아가게 하는 유인 구조로 쓰인다.
5. 심화 — 비기능 규모 측정과 자동화 동향
기능점수의 가장 근본적인 한계는 '사용자에게 보이는 기능만 잰다'는 데 있다. 성능·보안·확장성·가용성 같은 비기능 요구와, 아키텍처 전환·대규모 리팩터링처럼 기능 변화 없이도 막대한 노력이 드는 작업을 FP는 거의 포착하지 못한다. 이 공백을 메우기 위해 IFPUG는 2013년 SNAP(Software Non-functional Assessment Process) 을 발표했다. SNAP은 데이터 운영, 인터페이스 설계, 기술환경, 아키텍처 등 네 범주의 비기능 요구를 SP(SNAP Point)로 측정해, 기능점수(FP)와 상호 보완적인 별도 척도로 사용한다. FP가 '무엇을 하는가', SNAP이 '어떻게·얼마나 견고하게 하는가'를 재는 식이다. 최근 국내 대가산정 논의에서도 비기능 요구의 보상 체계로 SNAP 도입이 검토되고 있다.
측정의 자동화도 중요한 흐름이다. 전통적 FP 측정은 전문가가 명세를 읽고 손으로 세므로 비용과 측정자 편차가 크다는 고질적 문제가 있었다. 이를 해결하기 위해 OMG는 소스코드와 트랜잭션 구조로부터 기능점수를 자동 산정하는 Automated Function Points(AFP) 표준을 제정했고, 정적 분석 도구가 데이터 함수·트랜잭션을 코드에서 역추출해 FP를 계산한다. 다만 자동 측정은 '구현된 것'을 재므로 요구 단계의 조기 산정에는 쓸 수 없고, 측정자의 업무적 판단(기본 처리 식별, 경계 설정)을 완전히 대체하지는 못한다.
가장 최근의 변화는 AI·LLM 기반 규모 추정이다. 요구사항 문서나 사용자 스토리를 자연어 처리로 분석해 데이터·트랜잭션 기능을 자동 식별하고 FP를 추정하려는 연구·도구가 등장하고 있으며, 과거 프로젝트의 FP-공수 데이터로 학습한 모델이 산정 오차를 줄이는 데 활용된다. 그러나 AI 추정은 학습 데이터의 편향과 설명가능성 문제를 안고 있어, 당분간은 전문가 측정을 보조·검증하는 용도에 머물 전망이다. 애자일 환경에서는 FP 대신 상대적 규모인 스토리 포인트가 쓰이지만, 조직 차원의 예산·벤치마킹에는 여전히 절대 척도인 FP가 필요해 '스토리 포인트 ↔ FP' 상호 환산을 시도하는 하이브리드 접근도 나타나고 있다.
6. 고려사항 및 시사점
기술사 관점에서 기능점수를 적용·운영할 때 고려할 전략과 함의는 다음과 같다.
- 측정 시점과 방법의 2단계 운용: 발주 단계에서는 요구사항만으로 신속히 재는 간이법으로 예산을 확정하고, 설계 완료 후 정통법으로 재산정해 과업 변경을 정산하는 이원 전략이 바람직하다. 조기 산정은 '추정의 원뿔'에 따라 ±오차가 크므로, 한 번의 측정으로 확정하지 말고 단계별 재측정으로 정련해야 한다.
- 측정의 일관성·거버넌스 확보: FP는 측정자 숙련도에 따라 결과가 흔들리므로, 경계 설정·복잡도 판정 기준을 조직 표준으로 문서화하고 인증 측정사(CFPS) 또는 숙련자의 교차 검증을 두어야 신뢰를 얻는다. 측정 근거(식별 내역·복잡도 판정)를 추적 가능하게 남기는 것이 감리·분쟁 대응의 핵심이다.
- 비기능·고난도 요구의 별도 보상: FP가 과소평가하는 성능·보안·알고리즘 난도는 SNAP이나 별도 보정계수로 보완해야 한다. 특히 실시간·임베디드·AI 시스템은 IFPUG FP만으로 규모를 정하면 노력이 심각하게 왜곡되므로 COSMIC 등 도메인 적합 척도 병용을 검토한다.
- 성과 기반 계약의 유인 설계: FP당 단가 방식은 생산성 향상의 이익이 발주자에게 돌아가게 하지만, 수행사가 '불필요한 기능을 늘려 FP를 부풀리는' 역유인도 생긴다. 따라서 기능의 필요성 검증(과업 적정성 심사)과 결합해 운용해야 공정성이 유지된다.
- 전망과 연계 기술: 장기적으로 측정 자동화(OMG AFP)와 AI 추정이 측정 비용·편차를 줄이고, 애자일·DevOps 환경에서는 스토리 포인트와의 환산을 통해 FP가 조직 차원의 벤치마킹·포트폴리오 관리 지표로 재자리매김할 것이다. 다만 자동화가 측정자의 업무적 판단을 완전히 대체할 수는 없으므로, '자동 측정 + 전문가 검증'의 결합이 현실적 방향이다.
참고자료
- IFPUG, "Function Point Counting Practices Manual (CPM)", https://www.ifpug.org/
- ISO/IEC 20926, "Software and systems engineering — IFPUG functional size measurement method", https://www.iso.org/standard/51717.html
- 한국소프트웨어산업협회, "SW사업 대가산정 가이드", https://www.sw.or.kr/
- OMG, "Automated Function Points (AFP)", https://www.omg.org/spec/AFP/
한 줄 요약: 기능점수(FP)는 소프트웨어가 제공하는 기능을 데이터 기능(ILF·EIF)과 트랜잭션 기능(EI·EO·EQ)으로 식별·가중합산해 구현 기술과 무관하게 규모를 재는 기능 규모 측정 방법으로, 국내 SW사업 대가산정의 표준이자 비기능(SNAP)·자동화(AFP)·AI 추정으로 확장되는 공학적 척도다.