기능점수 산정 방법 2026 — 투입공수 방식과 개발 견적서 읽는 법

개발 외주 견적서를 받으면 대개 맨 아래에 금액 하나가 적혀 있다. 그 위에는 "웹 개발 1식", "관리자 페이지 1식" 같은 줄이 몇 개 있고, 그 숫자가 어떻게 나왔는지는 적혀 있지 않다.

이 글은 그 금액이 어떻게 계산되는지, 그리고 발주처가 무엇을 물어야 검증할 수 있는지를 정리한 것이다. 국내 SW 개발 대가는 크게 기능점수 방식과 투입공수 방식 둘로 산정되는데, 두 방식은 계산 논리가 다르고 유리한 상황도 다르다. 어느 쪽으로 받았는지 모른 채 금액만 비교하면 비교 자체가 성립하지 않는다.

두 가지 산정 방식 — 무엇을 세느냐가 다르다

핵심 차이는 위험을 누가 지느냐다. 기능점수는 "이 기능들을 이 금액에 만든다"이므로 예상보다 오래 걸려도 개발사가 감당한다. 투입공수는 "이 인력을 이 기간 투입한다"이므로 오래 걸리면 발주처가 더 낸다.

이 차이는 견적 금액에도 그대로 나타난다. 기능점수 견적에는 초과 위험을 감당하는 몫이 얹혀 있어 같은 범위라도 투입공수보다 높게 나오는 경우가 있다. 그 차액이 "비싸다"가 아니라 위험 이전 비용이라는 것을 알고 봐야 한다. 반대로 투입공수 견적이 낮아 보이는 이유는 초과분을 발주처가 나중에 내기 때문이지, 총액이 싸기 때문이 아니다.

발주처가 스스로 물어야 할 질문은 하나다. 일정이 예상보다 두 달 늘어나면 그 비용을 누가 내는가. 계약서에서 이 답이 안 나오면 어느 방식으로 받았든 산정이 끝난 게 아니다.

⚠️ 그래서 요구사항이 확정되지 않았는데 기능점수로 받은 견적은 위험 신호다. 셀 대상이 없는데 숫자가 나왔다는 뜻이고, 실제로는 개발사가 가정한 범위로 계산한 것이다. 착수 후 "그건 범위 밖입니다"가 반복된다.

기능점수를 세는 다섯 가지 항목

기능점수는 화면 개수가 아니라 데이터가 드나드는 지점을 센다. 국제 표준(IFPUG)을 따르는 국내 공공 산정 체계도 같은 다섯 항목을 쓴다.

같은 화면이라도 항목이 갈린다. 목록 화면에 합계가 붙으면 EQ가 아니라 EO다. 계산이 들어갔기 때문이다. 이 구분이 실제 점수 차이를 만들고, 견적 차이의 일부를 설명한다.

발주처가 이 다섯 항목을 다 셀 필요는 없다. 다만 견적서에 "화면 N개"가 아니라 이 다섯 항목의 개수가 적혀 있는지는 볼 수 있다. 적혀 있으면 기능점수로 산정한 것이고, 없으면 사실상 감으로 낸 금액이다.

또 하나 볼 수 있는 것은 비율이다. 일반적인 업무 시스템은 입력(EI)과 조회(EQ)가 많고 출력(EO)이 상대적으로 적다. 만약 EO가 전체의 절반을 넘는다면 집계·정산 로직이 많은 시스템이라는 뜻이고, 그런 시스템은 요구사항 문서에 계산식이 명시돼 있어야 한다. 계산식 없이 EO만 많이 잡힌 견적은 개발사가 임의로 가정한 것이다.

⚠️ 화면 개수로만 견적을 내면 화면 하나에 기능이 몇 개 들어가는지가 무시된다. 등록·수정·삭제·조회·엑셀 내려받기·일괄 처리가 한 화면에 다 들어간 것과, 단순 목록 하나가 같은 "화면 1개"로 세어진다. 견적 분산의 흔한 원인이다.

기능점수에서 실제 금액이 나오는 과정

발주처가 확인할 지점은 2번과 4번이다. 복잡도를 전부 "복잡"으로 판정하면 점수가 크게 뛴다. 판정 근거를 요구하면 대개 조정된다. 보정계수는 시스템 규모가 클수록 낮아지는 구조라, 작은 프로젝트에 큰 보정을 붙였다면 근거를 물어야 한다.

FP 단가는 공식 발표 자료가 매년 갱신되므로 그 해 기준을 확인해야 한다. 다만 민간 발주에서 공공 단가를 그대로 쓰는 경우는 드물다. 공공 단가는 산정 근거로 쓰고, 실제 계약 금액은 협상으로 정해지는 것이 보통이다.

발주처 입장에서 실용적인 사용법은 이렇다. 업체 견적을 받은 뒤 역산해 보는 것이다. 제시된 금액을 그 해 공표 단가로 나누면 몇 FP짜리 사업으로 계산했는지가 나온다. 그 수치를 요구사항 개수와 견줘 보면 과대·과소 산정이 대번에 드러난다. 요구사항 25개짜리 사업이 600 FP로 계산돼 있다면 근거를 물어야 한다.

투입공수 방식에서 확인할 것

투입공수는 계산이 단순해 보이지만 검증이 더 어렵다. "3명 4개월"이라는 숫자에는 그 3명이 누구인지가 안 들어 있기 때문이다.

⚠️ 가장 흔한 함정은 투입률이다. 견적서에 "5명 투입"이라 적혀 있어도 각자 30%씩이면 실제 인력은 1.5명이고, 일정은 5명 기준으로 잡혀 있다. 투입률이 안 적힌 투입공수 견적은 반드시 다시 받아야 한다.

인력의 실명과 이력을 계약 부속서로 받고, 교체 시 동등 이상 등급으로만 가능하도록 조항을 넣는 것이 표준적인 방어다. 업체 선정 단계에서 이를 배점에 반영하는 방법은 제안서 평가 기준에서 다룬다.

투입공수 계약에서 발주처가 반드시 확보해야 할 것이 하나 더 있다. 월별 투입 실적 보고다. 계약된 인원이 실제로 그만큼 붙었는지는 사후에 확인할 방법이 없기 때문에, 월 단위로 인력별 투입 일수를 제출받아야 한다. 이 조항이 없으면 "3명 4개월" 계약이 실제로는 1.5명 6개월이었어도 알 수 없고, 알아도 정산할 근거가 없다.

어느 방식으로 받아야 하는가

두 방식을 섞는 것도 실무에서 흔하다. 분석·설계는 공수로, 구현은 기능점수로 나눠 계약하면 요구사항이 없는 단계에서 총액을 확정하는 무리를 피할 수 있다. 이 구조를 쓰려면 1단계 산출물이 무엇인지를 계약에 명시해야 한다. 산출물 목록은 요구사항 정의서 작성법에 정리했다.

분리 발주에는 한 가지 조건이 붙는다. 1단계를 수행한 업체가 2단계에 유리해지는 구조를 그대로 두면 안 된다. 분석을 맡은 업체가 자기가 만들기 쉬운 형태로 요구사항을 쓰면 다른 업체는 견적을 낼 수 없다. 1단계 계약에 "산출물은 발주처 소유이며 특정 기술 스택을 전제하지 않는다"를 명시하고, 2단계 입찰에 1단계 업체도 동등하게 참여하게 하면 이 문제가 상당 부분 해소된다.

유형별 견적 기준선

산정 방식과 무관하게, 결과 금액이 상식적인 범위에 있는지는 볼 수 있다.

⚠️ 이 표는 비교의 출발점이지 기준가가 아니다. 실제 금액은 연동 대상, 데이터 이관량, 인쇄물 개수, 보안 요구 수준에서 갈린다. 표의 범위를 크게 벗어난 견적이 있으면 금액을 깎을 게 아니라 무엇이 포함되고 빠졌는지를 먼저 물어야 한다.

견적서에서 반드시 물어야 할 여덟 가지

1. 산정 방식은 기능점수인가 투입공수인가 — 안 적혀 있으면 물어라
2. 기능점수라면 다섯 항목 개수 — ILF/EIF/EI/EO/EQ
3. 투입공수라면 등급별 인원과 투입률 — "3명"이 아니라 "특급 1×100%, 중급 2×80%"
4. 요구사항 몇 번까지 포함인가 — 요구사항 번호로 답하게 한다
5. 데이터 이관이 포함되는가 — 회차와 정리 작업 포함 여부
6. 인쇄물·리포트 개수 — "일체"가 아니라 숫자로
7. 테스트와 검수 지원 범위 — 인수 테스트 지원이 견적에 있는가
8. 하자보수 기간과 이후 유지보수 요율 — 계약 이후 비용까지 합쳐야 총액이다

여덟 개를 같은 양식으로 모든 업체에 다시 물어보면, 금액 차이의 대부분이 범위 차이였다는 것이 그 자리에서 드러난다. 남는 차이가 진짜 단가 차이다.

견적 검증에서 흔한 실패 5가지

1. 최저가와 최고가만 보고 중간을 고른다. 세 견적이 서로 다른 범위를 담고 있으면 중간값에는 아무 의미가 없다. 범위를 맞춘 뒤에야 금액 비교가 성립한다.

2. 산정 방식을 안 물어본다. 기능점수 견적과 투입공수 견적을 나란히 놓고 "A사가 싸다"고 결론 내리는 경우다. 두 숫자는 애초에 다른 것을 세었다.

3. 유지보수를 빼고 총액을 본다. 구축비 3,000만 원에 연 유지보수 10~15%면 3년 총액은 4,000만 원에 가깝다. 구축비만 비교하면 유지보수를 비싸게 잡은 업체가 유리해 보인다.

4. 투입 인력을 확인하지 않는다. 제안 때 특급 개발자 이력을 냈지만 실제로는 초급이 투입되는 경우, 투입공수 견적의 전제가 무너진다. 실명과 교체 조항이 필요한 이유다.

5. 요구사항 없이 총액을 확정한다. 셀 대상이 없는 상태에서 나온 금액은 개발사의 가정이다. 착수 후 범위 논쟁이 반복되고, 결국 추가 계약으로 간다. 요구사항 정리에 드는 2~4주를 아끼면 그 몇 배를 나중에 쓴다.

AI-Native 팀이 견적 검증을 다루는 방식

견적 검증의 어려움은 판단이 어려워서가 아니라 비교할 형태로 만드는 데 시간이 들어서다. 업체 세 곳의 제안서가 각각 다른 목차, 다른 용어, 다른 단위로 쓰여 있고, 그걸 같은 표로 옮기는 일이 사람 손으로는 하루 이틀 걸린다.

나무숲(TreeSoop)은 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 쓰고, 이 정규화 단계를 코딩 에이전트에 맡긴다. 제안서와 견적서를 통째로 넣고 위 여덟 항목을 기준으로 업체별 비교표 초안을 뽑은 뒤, 어느 업체 견적에 무엇이 빠져 있는지 목록을 먼저 확인하는 순서다. 사람은 "빠진 항목을 추가로 물을 것인가, 범위 밖으로 둘 것인가"라는 판단에만 시간을 쓴다. 이런 AI-Native 개발 방식이 잘 맞는 이유는 자료가 이미 문서로 존재하고, 대조 항목이 정해져 있으며, 빠뜨리면 그대로 비용이 되는 종류의 일이기 때문이다.

⚠️ 자동으로 만든 비교표는 문서에 적힌 것만 비교한다. "적혀 있지 않다"와 "포함되지 않는다"는 다르다. 빠진 항목은 업체에 직접 물어 서면으로 답을 받아야 하고, 그 답이 계약서에 반영돼야 의미가 있다.

자주 묻는 질문

Q. 공공 SW 대가산정 가이드를 민간 발주에도 쓸 수 있나요?

산정 논리는 그대로 쓸 수 있다. 다섯 항목 분류와 복잡도 판정은 민간 프로젝트에도 유효하다. 다만 단가는 다르게 형성되므로 금액을 그대로 가져다 쓰면 안 된다. 가이드는 "이 규모면 이 정도 기능점수"를 가늠하는 용도로 쓰고, 금액은 시장 견적으로 확인하는 것이 현실적이다.

Q. 기능점수를 발주처가 직접 세어야 하나요?

셀 필요는 없다. 다만 견적서에 다섯 항목 개수가 적혀 있는지, 그 개수가 요구사항 정의서와 맞는지는 확인할 수 있다. 요구사항 30개짜리 문서에 EI가 60개로 잡혀 있다면 근거를 물어야 한다.

Q. 견적을 깎아도 되나요?

금액을 깎는 대신 범위를 조정하는 협상이 낫다. 같은 범위에서 금액만 깎으면 품질이나 투입 인력이 조정되고, 그 손해는 오픈 후에 나타난다. Must/Should/Could로 요구사항을 나눠 Could를 2차로 미루는 방식이 실질적이다.

Q. "1식"으로만 적힌 견적서는 어떻게 하나요?

다시 받아야 한다. "1식"은 산정 결과가 아니라 산정을 안 했다는 표시다. 위 여덟 항목을 양식으로 만들어 같은 형식으로 다시 요청하면, 그 요청에 성실히 답하는지 자체가 업체 판단 근거가 된다.

Q. 개발 기간이 짧으면 금액도 싼가요?

반대인 경우가 많다. 같은 범위를 짧게 하려면 인원을 늘려야 하고, 인원이 늘면 커뮤니케이션 비용이 붙어 총공수가 오히려 증가한다. 기간 단축을 요구할 때는 범위를 함께 줄이는 것이 정상적인 대응이다.

정리

개발 견적 검증의 결과를 가르는 지점은 세 가지다.

첫째, 산정 방식을 확인했는가. 기능점수인지 투입공수인지 모르면 두 견적을 비교할 수 없다. 안 적혀 있으면 물어야 하고, 답을 못 하면 산정을 안 한 것이다.

둘째, 금액이 아니라 범위를 비교했는가. 여덟 항목을 같은 양식으로 다시 받으면 차이의 대부분이 설명된다. 설명되지 않는 나머지가 진짜 단가 차이다.

셋째, 요구사항을 확정한 뒤에 총액을 정했는가. 셀 대상 없이 나온 총액은 개발사의 가정이고, 그 가정과 발주처의 기대가 다르면 착수 후 전부 추가 비용이 된다.