ISSUE REPORT l 2025.12.24. IS-217
( Extra Bold 11pt 줄 간격 130% 작성 완료 시 이 글은 삭제) 
AI프로젝트 규모산정 프레임워크
- 빙산의 수면아래, 기술규모 측정하기 - 
An AI Project Cost Estimation Framework
- The Hidden Iceberg: Measuring Technical Scope -
유호석, 이윤석
이 보고서는 「과학기술정보통신부 정보통신진흥기금」에서 지원받아 제작한 것으로 
과학기술정보통신부의 공식의견과 다를 수 있습니다.
이 보고서의 내용은 연구진의 개인 견해이며, 본 보고서와 관련한 의문 사항 또는 수정·보완할 
필요가 있는 경우에는 아래 연락처로 연락해 주시기 바랍니다.
소프트웨어정책연구소 산업정책연구실
유호석 책임연구원 hsy@spri.kr
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
  CONTENT
  
Ⅰ. 전통적인 SW사업과 AI사업의 밸류체인 비교
Ⅱ. 기존 FP기반 AI프로젝트 규모산정의 한계
III. 기능규모의 한계를 보완하는 기술규모 측정
IV. 기술요소를 반영한 규모측정 모델
V. 적용방안
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
4
요 약 문
AI 기술의 급격한 발전으로 AI 프로젝트 발주가 증가하고 있지만, 기존의 기능점수(FP) 방식은, 
챗봇이나 RAG(검색 증강 생성)와 같이 사용자 인터페이스는 단순하지만 그 이면에서 방대한 데
이터 처리와 복잡한 연산을 수행하는 AI 사업의 실질적 규모를 반영하지 못한다는 한계를 드러
내고 있다. 이로 인해 AI 프로젝트의 예산 책정의 현실성이 떨어질 위험성을 안고 있다.
이러한 문제를 해결하기 위해서 본 보고서는 AI프로젝트를 거대한 빙산에 비유하며, 수면 아래 
잠겨 있는 데이터 전처리, 임베딩, 벡터 저장소 구축 등 고난도 기술 엔지니어링 영역은 국제 표
준인 SNAP(Software Non-functional Assessment Process) 모델을 도입하여 별도로 정량화
할 것을 제안한다. 이는 기존 방식으로는 측정 불가능했던 백엔드(Back-end) 기술 공수에 대해 
정당한 가치를 부여하는 해결책이 될 것이다.
마지막으로 합리적인 규모산정 체계의 적용을 위해 AI 기술규모 자동화 측정 도구 발굴, AI 
프로젝트 데이터 축적, 그리고 AI 엔지니어링 기업 생태계 육성을 실현방안으로 제시한다. 
궁극적으로는 이러한 노력이 AI 프로젝트 사업 대가 산정의 정확성과 투명성을 제고하는 데 
기여할 것으로 기대한다.
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
Executive Summary 
As AI technologies advance rapidly, the number of AI project procurements 
continues to grow. Yet the traditional Function Point (FP) method shows clear 
limitations: in AI projects such as chatbots or Retrieval-Augmented Generation 
(RAG), the user interface may appear simple while massive data processing and 
complex computational workflows operate underneath. FP cannot capture the true 
scale of these hidden engineering efforts, creating a risk that AI project budgets 
will be underestimated and ultimately unrealistic.
To address this gap, this report shifts the focus from AI model development to 
AI Application Service Construction (Engineering) and proposes a framework for 
scope estimation. It recommends adopting the international SNAP (Software 
Non-functional Assessment Process) standard to quantify the technical 
complexity involved in back-end operations—such as data preprocessing, 
embedding generation, and vector-store construction—that FP cannot measure.
For a sound compensation system to take root, this report suggests key 
directions: discovering automated measurement tools for AI technical scope, 
accumulating AI project data, and fostering the AI engineering company 
ecosystem. Ultimately, these efforts will contribute to enhancing the accuracy and 
transparency of AI project cost estimation.
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
6
Ⅰ. 전통적인 SW사업과 AI사업의 밸류체인 비교
전통적인 SW사업 밸류체인
기획 → 구현 → 운영 으로 이루어 지는 선형적인 흐름이 기본임
AI사업 밸류체인
선형적인 흐름이 아닌 반복·지속적(continuous)으로 최적화해 나가야 함
데이터와 AI모델을 확보하고 학습하는데 상당한 공수(effort)를 투입해야 
하는 대신, 인간 개발자가 직접적으로 투입하는 공수는 상대적으로 감소
* 출처 : SPRi (2024a)
[그림1] 데이터를 중심으로 반복·지속적으로 진행되는 AI사업의 특징
AI 응용 서비스 기획
데이터 수집·가공·분석
AI 모델 개발·학습
·AI 전략·로드맵 기획
·신기술 연구개발
·데이터 확보
·AI 거버넌스 관리
·데이터 큐레이팅
·AI 데이터 엔지니어링
·데이터 애널리스트
·AI 아키텍처 설계
·AI 엔지니어링
·모델 학습 및 튜닝
·모델 성능 평가·최적화
AI 응용 서비스 지원
AI 응용 서비스·
어플리케이션 구현
AI 모델 배포
·AI 교육
·AI 서비스 확산
·AI 윤리 관리
·AI 서비스 기획/개발
·AI 응용프로그램 개발
·AI 테스트 엔지니어링
·AI Ops 엔지니어링
·AI 클라우드 운영
·보안/접근 제어
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
7
[표1] AI사업 밸류체인 구성요소
구분
정의 
AI 서비스 
기획
AI 전략·로드맵 기획
인공지능 사업・프로젝트를 기획 및 총괄
신기술 연구개발
새로운 AI 알고리즘 개발, 모델 구조, 강화학습 이론, 자연어 처리 기술, 
피지컬AI, 컴퓨터 비전 기술을 개발
데이터 
수집·
가공·분석
AI 거버넌스 관리
AI가 학습하기 위해 필요한 데이터를 수집하는 과정(유료, 무료, 
정부공개 등)에서 데이터의 활용 양식, 관리 주기 및 절차 등 관리
데이터 라벨링
인공지능이 학습할 영상, 언어 등의 데이터를 수집, 구축, 정제 및 
데이터의 품질을 관리
AI 데이터 엔지니어링
인공지능의 학습과 분석을 위한 대규모 데이터 저장관리, 데이터 
변환/통합, 선별과 자동 가공을 수행
데이터 애널리스트
인공지능을 위한 데이터 분석 및 기계학습 목적, 응용 서비스 정의, 
데이터 알고리즘 선정, 모델 최적화를 수행
AI 모델 
개발·
학습
AI 아키텍처 설계
인공지능 프레임워크와 대규모 분산병렬 학습, 추론 및 서비스 
아키텍처의 설계와 개발을 수행
AI 개발
데이터를 활용해 비즈니스 목적에 맞는 AI(머신러닝, 딥러닝 등) 모델을 
설계·개발
모델 학습 및 튜닝
데이터로 모델을 학습시키고 하이퍼파라미터를 최적화
모델 성능 평가·최적화
다양한 지표로 개발된 모델의 성능을 실험, 검증, 비교 및 최적화
AI 모델 
배포
AIOps 엔지니어링
다양한 자동화 도구와 스크립트, CI/CD 파이프라인, 모니터링 및 인프라 
관리를 통해 AI 시스템의 신뢰성·효율성·확장성을 확보하고, 개발부터 
배포, 운영까지 전체 프로세스를 통합
AI클라우드 운영
인공지능의 병렬분산 학습, 대규모 추론 및 AI서비스 시스템과 클라우드 
체계의 운영 및 관리
보안/접근 제어
모델과 데이터를 안전하게 보호하고, 적절한 사용자 권한을 체계적으로 
관리하여 무단 접근을 차단하며, 보안정책과 사고대응
AI 응용 
서비스 
개발·구현
AI서비스 기획/개발
다양한 AI 기술을 서비스화하고 사업 모델을 구현
AI응용프로그램 개발
다양한 분야/산업에 AI 모델 기반의 응용기술을 적용한 솔루션(서비스, 
에이전트 등) 개발, 사용자 경험 설계, API 개발
AI 테스트 엔지니어링
인공지능 모델 퀄리티 평가 등 테스트와 품질을 관리
AI 응용 
서비스 운영
AI 교육
인공지능 및 관련 기술·서비스에 대한 교육과 트레이닝을 제공
AI 솔루션 영업
기업이나 개인에게 AI 솔루션을 판매하거나 컨설팅을 제공
AI 윤리 관리
인공지능 기술의 윤리적·사회적 영향 연구, 개인정보 및 보완 등을 
관리하고 관련 지침과 정책을 제안
본 리포트 에서는 상기 영역 중 AI모델 개발·학습을 제외한 규모산정을 논의함 
AI모델 개발·학습단계의 규모는 응용 서비스 이전 단계로서 GPU등 컴퓨팅 
자원, 전기료 등 투입되는 투자규모에 큰 영향을 받음
이 리포트는 AI모델 개발 이후 최종사용자 또는 발주자와 밀접한 AI서비스 
엔지니어링(기획, 데이터 확보, 배포, 응용 서비스 개발·구현 및 운영) 분야에서의 
규모산정에 중점을 두어 서술함
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
8
Ⅱ. 기존 FP기반 AI프로젝트 규모산정의 한계
기능점수(FP)의 개요와 AI서비스 규모 산정의 한계
기능점수(Function Point, FP)는 1970년대 IBM에서 소프트웨어 개발 
규모를 객관화하기 위해 도입된 개념임
FP는 사용자가 인식할 수 있는 “기능 단위(Functional User 
Requirements)”를 기반으로 입력·출력·조회·내부파일·외부인터페이스의 5
개 요소를 세어 시스템의 논리적 크기를 산정함
[그림2] FP 기반의 기능규모 산정 방식
기능
기능별 복잡도 판정기준
단순
보통
복잡
화면
입력
·참조파일 0 또는 1개
데이터 항목 15개 이하
·참조파일 2개~(이하 생략)
·참조파일 0 또는 1개
데이터 항목 16개 이상
·참조파일 2개~(이하 생략)
·참조파일 2개
데이터 항목 16개 이상
·참조파일 3개 이상~(이하 생략)
출력/
 조회
·참조파일 0 또는 1개
데이터 항목 19개 이하
·참조파일 2~3개(이하생략)
·참조파일 0 또는 1개
데이터항목20개~(이하생략)
·참조파일 2~3개
데이터 항목 20개 이상
·참조파일 4개 이상~(이하생략)
데이
내부/
외부
 파일
·서브데이터 1개,
데이터 항목 50개 이하
·서브데이터 2~5개이상
(이하 생략)
·서브데이터 1개
 데이터항목 51개~(이하생략)
·서브데이터 2~5개, 데이터 항
목 51개 이상
·서브데이터 6개 이상~
(이하 생략)
* 출처 : 기능점수측정실무매뉴얼(Ver 4.3.1 한글판, 한국소프트웨어측정원)
FP방식은 사용자 기능요구사항을 세는 것이 기본이나, AI서비스는 사용자가 
인식할 수 없는 기술적 요구사항의 비중이 높음
FP 방식의 핵심은 “사용자에게 인식 가능한 기능(what the software 
shall do)”의 수를 계량화하는 것이며, 기능의 개수에 따라 투입공수와 사
업비가 비례하는 구조를 전제함
AI서비스는 정해진 기능의 실행이 아니라 확률적 추론·패턴 인식·언어생성 
등 “내부 학습로직”에 기반하여 동작하므로, FP로 셀 수 있는 명시적 기능
이 제한적
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
9
*
챗봇이나 추천시스템은 사용자의 입력과 시스템의 출력이 확정적이지 않으며, 
동일한 요청에도 결과가 달라질 수 있는 비결정적(Non-deterministic) 특성을 가짐
전통적인 SW의 기능요소
AI 서비스의 기능요소
Countable
메뉴,버튼 등 기능요소를 셀수 있음
사용경로가 변화하여 세기가 어려움
계좌관리
서비스
예시
   * Intuit社 Mint앱
   
*https://www.nairaland.com/3626189/feedback-ai-
chatbot-send-money
[표2] 기능요소 계량이 어려운 AI서비스 
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
10
Ⅲ. 기능규모의 한계를 보완하는 기술규모 측정
기능+기술 통합 측정의 필요성
AI 서비스의 효용은 “정확도·응답속도·학습데이터 품질·모델 안정성” 등 기술
적 요소에 크게 의존
*
예컨대 생성형 챗봇의 “응답의 자연스러움”, 추천시스템의 “정확도·재현율”, 
인공지능 API의 “응답속도와 안정성”은 모두 명시적 기능이 아니라 기술적 
특성·품질속성으로 표현되는 기술 요구사항임
결국, AI 서비스의 규모산정은 눈에 보이는 기능 보다, 보이지 않는 기
술요소를 더 많이 측정해야 하는 과제에 직면
[그림3] 빙산의 수면 아래처럼 보이지 않는 기술요소의 비중이 높은 AI서비스
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
11
‘무엇’(What)을 계량하는 기능측정 vs ‘어떻게’(How)를 계량하는 기술요소 측정
계량 대상, 분석 단위, 적용 범위의 차이
기술요소 측정은 동일한 기능이라도 데이터구조의 복잡성, UI 설계 난이도, 
성능요구, 플랫폼 연계 수준 등에 따라 추가 공수(effort)를 계량
분석 단위도 기능요소는 “사용자 관점의 업무기능 단위”인 반면, 기술요소 
요소는 “시스템 관점의 기술요소 단위(컴포넌트, 연계, 플랫폼, 성능요소 
등)”로 평가대상이 다름
적용 범위 측면에서 기능점수는 요구분석–설계–개발의 개발 프로세스 
중심이며, 기술요소점수는 성능·보안·확장성·데이터관리 등 운영 및 
품질관리 단계에 중심
*
예를 들어 동일한 “질의응답 기능”이라도, 단순 FAQ형 챗봇은 기능점수 10점, 
기술요소점수 0점이지만, LLM을 활용해 자연어 이해와 추론을 수행하는 AI 챗봇은 
기능점수 10점(예시) + 기술요소점수 35점(예시) 등으로 계량하는 것이 합리적임
따라서 기술요소 측정은 기능측정의 대체재가 아니라 기능점수가 포착하지 
못하는 기술요소의 규모를 계량해주는 보완적 수단으로서, AI서비스와 같은 
고기술 구현에 드는 기술인력의 공수(effort)를 측정하게 하는 현실적인 
방안임
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
12
IV. 기술요소를 반영한 규모측정 모델
(국제표준) 기능/기술 요구사항의 식별·분리 후 각 규모를 별도로 계산
아래 그림에서 기능영역은 기존 FP(Function Point) 표준으로, 비기능 영역은 
SNAP(Software Non-functional Assessment Process) 표준으로 측정할 수 있음
*
IFPUG(국제기능점수사용자그룹)는 기능점수(FP)만으로는 측정하기 어려운 비기능 
요구사항의 규모를 정량화하기 위해 2011년 SNAP 측정 매뉴얼(APM v1.0)을 최
초 발표하며 보급을 시작함
*
2019년에 IEEE 2430-2019(소프트웨어 비기능 규모측정에 대한 IEEE 표준)로 
승인되었고, 2025년에 ISO/IEC/IEEE 32430:2025 “Software engineering — 
Software non-functional size measurement Standard”로 발간되면서 ISO 
국제표준 지위를 획득
[그림4] 기능요소와 기술요소의 통합측정 절차
*
출처: IFPUG (2017)를 저자들이 번역, 편집
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
13
적용범위
FP :  기능요구 전반에 광범위하게 적용 가능
SNAP :  데이터 검증·서식·인터페이스 설계·다중플랫폼·배치 
처리·구성요소 아키텍처 등 4개 카테고리·14개 서브카테고리로 대표되는 
기술 요구에 적용 (아래 그림 참조)
기본개념
FP : 데이터 기능 2개(내부논리피일, 외부연계파일), 트랜잭션 기능 
3개(외부입력, 외부출력, 외부조회)
SNAP : 각 카테고리별 기술 규모 식별하되, FP와 합산하지 않고 두 가지 
규모를 나란히 관리해야 함
[그림] SNAP 측정의 4대 카테고리와 15개 서브 카테고리
*
별첨1. SNAP 카테고리별 설명 참조
측정 절차
FP : 범위/경계 정의 → 기능유형 5개 식별 → 각 기능유형별 복잡도 식별 
→ 기능규모 합산
SNAP : 기술 요구사항과 서브카테고리 매핑 → 서브카테고리 측정 규칙 
적용 → 기술규모 합산
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
14
[표3] SNAP 측정대상과 vs. FP 측정대상 비교
이하 내용에서는 AI프로젝트의 기술규모의 측정에 집중하여 SNAP 표준으로 
실제 기술규모를 측정하는 예시를 제시함
구분
SNAP (기술 규모)
FP (기능 규모)
국제 표준
ISO/IEC/IEEE 32430:2025
ISO/IEC 20926:2009
측정 대상
비기능 요구사항의 서브카테고리 별 규모
(상기 그림)
사용자 기능
(트랜잭션 기능/데이터 기능)
주요
AI
기술
요소
1.2 Logical and 
Mathmatical 
Operations
알고리즘 복잡도 반영
알고리즘 복잡도를 규모에 반영하지 
않음
1.4 Internal Data 
Movement
어플리케이션 경계 내 
파티션 간 이동을 규모에 반영
어플리케이션 경계 내부↔외부로의
데이터 이동만 규모에 반영
3.2 Database 
Technology
코드 데이터 등 물리 테이블 요소 반영
(코드/뷰/파티션/인덱스 등)
물리 테이블은 규모로 인정하지 
않음(논리적 구성만 인정)
3.3 Batch Process
기능 요구사항(Transactional Function)으로 
인정되지 않는 경계 내 배치작업을 규모로 
인정
어플리케이션 경계를 넘어 사용자가 
인식가능한 경우만 반영
4.  Architecture
재사용 Component 수 등 
아키텍쳐 복잡도를 규모에 반영
아키텍처 복잡도는 규모에 반영하지 
않음
AI 규모산정 적용
- 지연시간·가용성·보안·플랫폼·배치·UI 
가이드라인 등 운영·품질 특성을 별도 
크기로 계량.
- 모델 응답시간/형식 검증, 다중 포맷 
출력, 다중 플랫폼 배포, 배치 
파이프라인 등 AI 시스템의 운영·품질 
부하를 규모로 반영
- 챗봇 UI나 AI응답 등 사용자가 인식가
능한 기능 흐름만 측정
- 기술적 난이도는 규모에 거의 
반영되지 않음
 * 일부 보정계수 방식으로만 반영
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
15
(예시 시나리오) 내부지식을 LLM에 전달하기 위한 RAG 구축
(배경) AI로 부터 일반적인 답변이 아닌 사용자(기업)에 특화된 답변을 얻기 
위한 RAG(Retrieval Augmented Generation; 검색증강생성) 기술이 활발하게 활용 중
 - 내부정보를 Vector DB*에 저장해 놓은 상태에서, 사용자가 LLM에 질문하
면 해당 Vector DB의 특화정보를 검색하여 LLM이 종합적 답변을 생성함
*
기존DB는 정형 데이터(숫자,텍스트)를 그대로 저장하는 데 비해, Vector DB는 문
서, 이미지, 동영상과 같은 비정형데이터를 벡터값으로 바꾸어(embedding) 저장
[그림] 일반적인 RAG 구축 절차
*
그림출처: AWS Korea(2024)
 - 이러한 RAG 구축과정은 기술요소를 측정해야 규모를 측정할 수 있는데, 이
는 발주자가 인식가능한 기능이 아니어서 FP방식으로는 불가능 하고 SNAP 
과 같은 기술규모 측정방식을 적용해야함
 - 상기 이미지의 점선 박스내 ❷ Store Vector data 까지의 과정(저장) 까지
만 SNAP을 기준으로 측정하는 예시를 이하에서 제시하고자 함
*
사용자가 질의하는 번 과정은 저장이 아닌 별도의 측정절차(검색) 에서 규모를 
산정하는 것이 바람직함
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
16
(측정예시) 기업 공시자료에서 데이터를 ①추출(Parsing), ②분해(Chunk*), 
③변환(Embedding) 한 후 저장하는 과정을 SNAP측정으로 예시하고자 함
*
Chunk 는 Embedding Model 이 한번에 수용할 수 있는 물리적인 크기(Token)로 
데이터를 쪼개는 것으로 문장, 페이지 단위 등으로 쪼갤 수 있음
[그림5] 입력 데이터, Parsing, Chunk 등 세부 기술요소가 반영된 RAG 구축 절차
1) 사업보고서(비정형)만 Vector DB에 저장하는 기술규모 예시 : 187 SP(Snap Point)
*
사업보고서 1개 파일 내 사업내용, 주주구성 등 7개(DET;Data Element Type)로 가정
한 자연어 데이터셋을 Vector DB에 저장하는 과정
*
아래 표의 각셀은 [복잡도(Low/Average/High) x DET수]로 계산되며, 복잡도는 별첨2참조
[표4] 기업 사업보고서를 RAG로 저장하는 기술규모 측정예시
- 원본 문서의 Parsing 공수가 가장 높은 기술규모를 가지는 것으로 측정
SNAP
카테고리
① Parsing
(70 SP)
② Chunk
(42 SP)
③ Embedding
(63 SP)
1.2 논리 및 
수학 연산
28 = 4(Low)×7DETs
*사업보고서 파일(FTR) 1개는 
복잡도 ‘Low’× 7개 DET
-
-
1.3 데이터 
포맷팅
14 = 2(Low)×7DETs
*Type단순변환×7개 데이터
14 = 2(Low)×7DETs
*데이터 단순분해 × 물리적 
분해로는 DET증가 없음(7개 유지)
 35= 5(High)×7DETs
*벡터형으로 대규모 변환 × 
7개 데이터유형
1.4 내부 
데이터 이동
28 = 4(Low)×7DETs
* 1곳에서 1곳(FTR)으로 
단순이동×7개 데이터
(원본→Parsing)
 28 = 4(Low)×7DETs
* 1곳에서 1곳(FTR)으로 
단순이동×7개 데이터
(Parsing→Chunking)
28 = 4(Low)×7DETs
* 1곳에서 1곳(FTR)으로 
단순이동×7개 데이터
(Chunking→Embedding)
4.1 컴포넌트 
기반 SW
④ 공통 아키텍처 (12 SP)
12 = 4(Third Party Component) * 3
*3개(Parsing+Chunking+Embbeding) 의 3rd party 컴포넌트로 구성
총합
 (SNAP Point)
187 SP = ①70 + ②42 + ③63 + ④12
*
별첨2. SNAP 세부 카테고리별 측정표 참조
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
17
2) 사업보고서에 재무제표(정형데이터)까지 추가하는 기술규모 예시 : 292 SP
*
재무제표의 매출액, 영업이익 등 수치 데이터 5개(DET)의 필드로 가정하고, 이를 
Vector DB에 추가저장하는 기술규모를 추가
[그림6] 그림5에 재무데이터 입력이 추가된 RAG절차
[표5] 표4에 재무제표 데이터를 추가한 기술규모 측정예시
- 복잡도가 높은(High) Embedding (Vector화) 과정이 가장 높은 기술규모 - 
SNAP
카테고리
① Parsing
(100 SP)
② Chunk
(72 SP)
③ Embedding
(108 SP)
1.2 논리 및 
수학 연산
<사업보고서> 28 
*재무제표는 정형데이터이므로 
Parsing이 없어 논리·수학 연산없음
-
-
1.3 데이터 
포맷팅
<사업보고서> 14 
<재무제표> 10 
2(Low)×5DETs
*Type단순변환×5개 데이터유형
<사업보고서> 14 
<재무제표> 10 
2(Low)×5DETs
*데이터 단순분해 × 물리적 
분해로는 DET증가 없음(5개 유지)
<사업보고서> 35
<재무제표> 25 
5(High)×5DETs
*벡터형으로 대규모 변환 × 
5개 데이터유형
1.4 내부 
데이터 이동
<사업보고서> 28
<재무제표> 20 
= 4(Low)×5DETs
* 1곳에서 1곳(FTR)으로 
단순이동×5개 데이터유형
<사업보고서> 28
<재무제표> 20 
= 4(Low)×5DETs
* 1곳에서 1곳(FTR)으로 
단순이동×5개 데이터유형
<사업보고서> 28
<재무제표> 20 
= 4(Low)×5DETs
* 1곳에서 1곳(FTR)으로 
단순이동×5개 데이터유형
4.1 컴포넌트 
기반 SW
④ 공통 아키텍처 (12 SP)
<사업보고서+재무제표 공통> 12 
총합
 (SNAP Point)
292 SP = ①100 + ②72 + ③108 + ④12
*
별첨2. SNAP 세부 카테고리별 측정표
상기의 SNAP표준과 예시는, AI서비스의 규모는 AI에 입력되는 정형,비정형 
데이터의 종류와 양에 따라 증가하는 구조임을 의미함
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
18
V. 적용방안
AI기술규모 측정 자동화 도구 확보
측정 자동화의 필요성 및 기술적 용이성
(수작업 측정의 한계) AI 프로젝트의 복잡성과 비정형성으로 인해 전문가의 
수작업 측정은 시간과 비용이 과다하게 소요되므로 자동화 전환이 시급함
(기술규모 측정 자동화의 기회)사용자 의도 해석 등 주관적 판단이 많이 개입되는 
기능규모(FP)와 달리, 기술규모(SNAP)는 데이터 처리량, 알고리즘 복잡도, 
컴포넌트 수 등 객관적·물리적 속성에 기반하므로 인간의 판단 의존도가 낮아 
자동화 구현에 훨씬 용이
그러나, AI기술요소의 규모를 측정하는 자동화 도구는 아직 부재함
[그림7] 현재는 기능요구 사항을 구체화하여 FP규모를 자동 산정하는 도구만 존재
*
LeadMC社, < Quanter, The Smart AI Estimation >, ISMA 2025(Seoul) 발표자료
AI 기술규모(SNAP) 측정 자동화 도구 발굴
자동화 도구 개발: 자연어(NLP) 기술을 적용하여, AI 요구사항 문서에서 
기술규모 점수(SNAP)를 자동으로 추출하는 도구를 탐색
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
19
RAG 파이프라인(전처리, 임베딩, 벡터DB 등)과 같이 명확한 기술적 
패턴을 가진 AI 프로젝트의 특성을 활용하여, 비기능적 기술 요소를 
자동으로 식별하고 SNAP 점수로 변환하는 알고리즘을 중점 육성함
단순 코드 라인 수(LOC)가 아닌, 데이터 파이프라인의 복잡도와 입력 
데이터의 분량·유형을 기반으로 기술 규모를 산출하는 자동화 엔진 확보
데이터 기반의 지능형 견적 생태계 조성
데이터 축적과 자동화의 선순환: 자동화 도구를 통해 수집된 AI 프로젝트의 
규모 및 비용 데이터를 익명화하여 중앙 데이터베이스(가칭 AI 프로젝트 
데이터뱅크)에 축적하고, 이를 다시 자동화 도구의 예측 정확도를 높이는 
데 활용하는 선순환 구조를 구축함
생산성 혁신: 측정 전문가가 단순 반복적인 산정 업무에서 벗어나 프로젝트 
가치 평가와 리스크 관리 등 고부가가치 업무에 집중할 수 있도록, 'AI가 
AI 사업 대가를 산정'하는 지능형 견적 체계로 전환
AI 프로젝트 데이터 축적
데이터 축적의 필요성: 규모(Size)에서 예산(Budget)으로의 연결
(실증 데이터 부재) 현재 AI 사업은 참조 가능한 과거 실적 데이터가 
부족하여 적정 단가 산정에 한계, 실제 수행된 프로젝트의 '측정 
규모(SP)'와 '실제 투입 공수·비용' 간 관계를 입증할 실증 데이터 필요
벤치마킹 사례: 국제 SW 벤치마킹 표준 그룹(ISBSG) 모델
(데이터 기반 규모산정 참조사례) ISBSG는 전 세계 IT 프로젝트의 
개발·유지보수 데이터를 수집·분석하여 산업계에 제공하는 비영리 기구로 
객관적 대가 산정의 모범 사례임
(참여 인센티브) 데이터 제출 기업에 벤치마킹 리포트 무료 제공 및 구매 
할인 혜택을 부여하여 자발적 데이터 유입의 선순환 생태계 구축
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
20
[그림8] 사업규모와 예산 데이터 제출의 인센티브를 홍보하는 isbsg.org 홈페이지
추진 방안
ISBSG 모델을 참조한 데이터 수집으로 급변하는 시장 상황 즉각 반영
데이터 기반의 적정 예산(Price per SP)규모 구간 도출
AI엔지니어링 기업 생태계 조성
SW개발에서 ‘AI 서비스 엔지니어링’으로의 산업 비중 확대
(가치사슬 변화) AI 사업의 핵심 부가가치가 기능 구현(UI/UX)에서 데이터 
전처리, 벡터 최적화, LLM 아키텍처 설계 등 비기능적 기술 엔지니어링 영
역으로 이동함에 따라, ‘AI 엔지니어링’으로 산업의 비중을 확대할 필요
(전문 기업 육성) 기능 점수(FP)로는 보상받기 어려웠던 데이터 파이프라
인 구축, 임베딩 모델 튜닝, 벡터 저장소 최적화 등 고난도 기술 역량을 보
유한 「AI 데이터/기술 엔지니어링 전문 기업」을 발굴·육성
기술 규모 기반의 정당한 보상 체계 안착
(기술요소에 대한 가치 인정) 눈에 보이지 않는 백엔드(Back-end) 기술 
공수를 정량적으로 인정하고 합당한 대가를 지급함으로써, 기술력 있는 중
소·스타트업이 정당한 수익을 창출하는 공정 생태계를 조성함
(저가 수주 경쟁 해소) 인력 투입 위주의 소모적 경쟁에서 벗어나, 기술적 
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
21
난이도와 복잡도를 해결하는 ‘기술 가치’ 중심의 경쟁 구조로 전환하여 AI 
사업의 질적 성장을 유도함
AI 규모 산정 전문가 양성
(융합형 인재 양성) AI 기술의 구조(RAG, 파인튜닝 등)를 이해하고 이를 
SNAP 등 대가 산정 모델에 적용할 수 있는 「AI 대가 산정 전문가(AI 
Cost Engineer)」 교육 과정을 신설하여, 발주자와 수주자 간의 신뢰할 수 
있는 소통 창구를 마련
지속 가능한 성장을 위한 선순환 구조 확립
재투자의 유인: 정당한 대가 지급을 통해 확보된 수익이 기업의 R&D 투자
와 우수 인재 영입으로 이어지고, 이것이 다시 고품질의 AI 서비스 개발로 
귀결되는 ‘수익-투자-품질 향상’의 산업 선순환 고리를 완성
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
22
[별첨1] SNAP 카테고리별 설명
SNAP Framework 는 비기능 요구사항(NFR)을 충족시키기 위해 사용되는 
구성 요소, 프로세스 또는 활동을 분류하는 네 가지 주요 카테고리(영역)로 구성
[표] 4대 영역(Catrgory)과 각 영역의 세부 영역(Sub-categories) 해설
대분류 (Category)
세부 영역 (Sub-category)
명칭
설명
명칭
설명
1. 데이터 
운영
데이터의 정확성, 일관성, 
무결성 등 품질 요구사항을 
위해 수행되는 내부 데이터 
처리 작업의 복잡도를 
측정합니다. 복잡한 데이터 
검증 논리, 광범위한 
논리적/수학적 연산, 그리고 
파티션 간의 내부 데이터 
이동 등이 포함됩니다. 
1.1 데이터 
입력 유효성 
검증
데이터의 정확성, 일관성, 무결성 등 품질 
요구사항을 충족하기 위한 복잡한 데이터 검증 
및 오류 처리 로직을 측정합니다.
1.2 논리 및 
수학 연산
단순 계산을 넘어, 광범위한 논리적 결정이나 
복잡한 알고리즘을 포함하는 수학적 연산의 
복잡도를 측정합니다. (예: 금융 상품의 복잡한 
이자 계산, 프로젝트 일정의 중요 경로 분석)
1.3 데이터 
포맷팅
기능적 목적이 아닌 비기능적 목적을 위한 
데이터 구조나 포맷 변경의 복잡도를 측정합니다. 
(예: 데이터 암호화/복호화, 표준화된 메시지 
형식 준수)
1.4 내부 
데이터 이동
애플리케이션 내의 서로 다른 구성 요소(파티션) 
간에 데이터를 이동시키고 처리하는 과정의 
복잡도(주로 성능, 아키텍처 요구사항과 관련)를 
측정합니다.
1.5 데이터 
구성을 통한 
사용자 가치 
제공
코드 변경 없이 참조 데이터나 구성 파일을 
수정하는 것만으로 새로운 기능이나 비즈니스 
가치를 추가하는 활동의 크기를 측정합니다.
2. 
인터페이스 
설계
사용자가 소프트웨어와 
접하는 디자인 및 상호작용 
요소의 복잡성을 
측정합니다. 
사용성(Usability), 
접근성(Accessibility) 
개선을 위한 사용자 
인터페이스 요소 추가/변경, 
도움말 기능 제공, 그리고 
2.1 사용자 
인터페이스
사용성(Usability), 학습 용이성, 접근성 등 품질 
요구사항을 위해 화면 요소(UI Element)의 
속성이나 모양을 추가/변경하는 복잡도를 
측정합니다.
2.2 도움말 
방식
사용자에게 소프트웨어 사용법이나 보조 정보를 
제공하는 도움말 객체(Help Object) (예: 툴팁, 
팝업 도움말, 매뉴얼)의 복잡성을 측정합니다.
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
23
*
출처: IFPUG (2017)
대분류 (Category)
세부 영역 (Sub-category)
명칭
설명
명칭
설명
다중 입/출력 매체 (예: 웹, 
바코드, 스마트폰) 지원 
등이 이 영역에 
해당합니다. 
2.3 다중 입력 
방식
동일한 기능을 수행하면서도 여러 가지 입력 
매체나 기술(예: 키보드, 스마트폰, 바코드 
리더기)을 지원하는 작업의 복잡도를 측정합니다.
2.4 다중 출력 
방식
동일한 기능을 수행하면서도 여러 가지 출력 
매체나 기술(예: 인쇄, PDF, SMS)을 지원하는 
작업의 복잡도를 측정합니다.
3. 기술 환경
소프트웨어 운용을 위한 
기술적 기반과 관련된 
복잡성을 측정합니다. 다중 
플랫폼 (예: 여러 운영체제 
또는 브라우저) 지원, 
데이터베이스 기술 (예: 
성능 개선을 위한 인덱스 
추가), 그리고 내부 배치 
프로세스 (외부 입출력이 
없는 사용자 식별 가능한 
배치 작업)의 크기를 
측정합니다. 
3.1 다중 
플랫폼
소프트웨어가 둘 이상의 다른 환경 (예: 다른 
운영체제, 다른 프로그래밍 언어 계열, 다른 
브라우저)에서 작동하도록 지원하는 복잡도를 
측정합니다.
3.2 
데이터베이스 
기술
성능 개선이나 데이터 무결성 등의 비기능적 
요구사항을 위해 데이터베이스 구조 자체 (예: 
인덱스 추가, 뷰 생성, 쿼리 튜닝)를 변경하는 
크기를 측정합니다.
3.3 배치 
프로세스
외부 입력/출력이 없어 기능 점수(FP)로 측정할 
수 없는, 애플리케이션 내부에서 실행되는 사용자 
식별 가능한 배치 작업의 크기를 측정합니다.
4. 아키텍처
시스템의 구조적 복잡성을 
측정합니다. 재사용 가능한 
소프트웨어 컴포넌트의 
활용이나 구축, 그리고 
기능 변경 없이 성능 또는 
용량 확대를 위해 동일한 
인터페이스를 
복제/추가하는 작업 등이 
여기에 해당합니다. 
4.1 컴포넌트 
기반 
소프트웨어
재사용성을 높이거나 표준 인터페이스를 통해 
통합하기 위해 컴포넌트를 구축하거나 활용하는 
복잡도를 측정합니다.
4.2 다중 
입/출력 
인터페이스
기능 변경 없이 용량 증대나 성능 개선을 위해 
기존 입/출력 인터페이스를 복제하거나 추가하는 
작업의 크기를 측정합니다 (예: 추가 서버를 통한 
인터페이스 복제)
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
24
[별첨2] SNAP 세부 카테고리별 측정표
SNAP 프레임워크는 소프트웨어의 비기능 요구사항(NFR)의 크기를 측정하며, 
이를 위해 4가지 대분류(Category)와 15개의 세부 카테고리
(Sub-category)를 사용함
대분류
세부 카테고리
SNAP 산정 
단위
복잡도 매개변수
SNAP 점수 산정 공식
1. 데이터 
운영
1.1 데이터 입력 
유효성 검증
단위프로세스
1. 중첩 수준 (Nesting Level)의 
복잡도
2. 모든 유효성 검증에 사용되는 
고유 DET 수
복잡도(Low: 2, Average: 
3, High: 4) × DET 수
1.2 논리 및 수학 
연산
단위프로세스
1. FTR 밀도 (0-3, 4-9, 10+ 
FTRs)
2. 프로세스 로직 유형 
(논리적/수학적)
3. DET 수
FTR 밀도 및 
단위프로세스 유형에 따라 
상이한 상수(3, 4, 6, 7, 
10) × DET 수
1.3 데이터 
포맷팅
단위프로세스
1. 변환 복잡도 (Low: 단순 변환, 
Average: API 사용 
암호화/복호화, High: 로컬 
암호화/복호화)
2. 변환되는 DET 수
복잡도(Low: 2, Average: 
3, High: 5) × DET 수
1.4 내부 데이터 
이동
파티션 간 
경계를 넘는 
단위프로세스
의 부분
1. 파티션 간 전송되며 
처리/유지되는 고유 DET 수 
2. 교차하는 두 파티션에서 
단위프로세스가 읽거나 
업데이트하는 고유 FTR 수
FTR 복잡도(Low: 4, 
Average: 6, High: 10) × 
DET 수 (각 파티션 
교차마다 계산)
1.5 데이터 
구성을 통한 
사용자 가치 제공
논리 파일당 
단위프로세스
1. 단위프로세스에 관련된 고유 
속성 수
2. 구성되는 레코드 수 (Low: 
1-10, Average: 11-29, High: 
30+).
레코드 복잡도(Low: 6, 
Average: 8, High: 12) × 
고유 속성 수
2. 
인터페이
스 설계
2.1 사용자 
인터페이스
단위프로세스 
로 정의된 
스크린 집합
1. SCU에서 각 UI 요소에 대해 
구성된 고유 속성 수의 합 (Low: 
<10, Average: 10-15, High: 
16+)
2. 영향받는 고유 UI 요소 수
UI 복잡도(Low: 2, 
Average: 3, High: 4) × 
고유 UI 요소 수
2.2 도움말 방식
도움말 객체
도움말 항목에 스크린샷이 
포함되는지 여부
스크린샷 없음: (도움말 
객체 수 / 16). 스크린샷 
있음: (도움말 객체 수 / 
16) + 2
2.3 다중 입력 
방식
단위프로세스
1. SCU의 DET 수 (Low: 1-4, 
Average: 5-15, High: 16+)
2. 추가 입력 방식 수.
DET 복잡도(Low: 3, 
Average: 4, High: 6) × 
추가 입력 방식 수
2.4 다중 출력 
방식
단위프로세스
1. SCU의 DET 수 (Low: 1-5, 
Average: 6-19, High: 20+)
2. 추가 출력 방식 수.
DET 복잡도(Low: 3, 
Average: 4, High: 6) × 
추가 출력 방식 수
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
25
*
출처: IFPUG (2017)
대분류
세부 카테고리
SNAP 산정 
단위
복잡도 매개변수
SNAP 점수 산정 공식
3. 기술 
환경
3.1 다중 플랫폼
단위프로세스
1. 플랫폼의 특성 (소프트웨어, 
하드웨어). 2. 작동해야 하는 
플랫폼 수.
플랫폼 카테고리 및 
플랫폼 수에 따라 
결정되는 상수 요인의 합 
(예: 카테고리 
1-소프트웨어: 2개 
플랫폼=20 SP)
3.2 
데이터베이스기술
단위프로세스
1. FTR 복잡도 (DETs 및 RETs 
기반)
2. 데이터베이스 관련 변경 수
FTR 복잡도(Low: 6, 
Average: 9, High: 12) × 
변경 수
3.3 배치 
프로세스
사용자 식별 
배치 작업
1. 작업에서 처리되는 DET 수
2. 작업에서 읽거나 업데이트하는 
FTR 수 (Low: 1-3, Average: 
4-9, High: 10+).
FTR 복잡도(Low: 4, 
Average: 6, High: 10) × 
DET 수
4. 
아키텍처
4.1 컴포넌트 
기반 소프트웨어
단위프로세스
1. 컴포넌트 유형 (내부 
재사용/타사 컴포넌트)
2. 단위프로세스에 관련된 고유 
컴포넌트 수
컴포넌트 유형(내부: 3, 
타사: 4) × 고유 
컴포넌트 수
4.2 다중 입/출력 
인터페이스
단위프로세스
1. SCU의 DET 수 (Low: 1-5, 
Average: 6-19, High: 20+)
2. 추가 입/출력 인터페이스 수
DET 복잡도(Low: 3, 
Average: 4, High: 6) × 
# 추가 인터페이스 
SPRi 이슈리포트 IS-217                     AI프로젝트 규모산정 프레임워크 : 빙산의 수면아래, 기술규모 측정하기
26
참고문헌
1. 국내문헌
AWS Korea(2024), ‘RAG 아키텍쳐 – 개념에서 구현까지’
  - https://www.youtube.com/watch?v=zI7rin2S_Ak&t=651s
SPRi(2024a), 생성형 AI에 의한 소프트웨어 개발자 업무 영향 분석
SPRi(2024b), AI인프라에서 AI서비스로 - SW기업의 AI도입 모델과 신서비스 모델의 탐색
2. 국외문헌
IFPUG(2017), ‘Software Non-functional Assessment Process(SNAP)’, Release 2.4
GetGenie(2024), ‘AI Native in Action’
[소프트웨어정책연구소]에 의해 작성된 [SPRI 보고서]는 공공저작물 자유이용허락 표시기준 
제4유형(출처표시-상업적이용금지-변경금지)에 따라 이용할 수 있습니다.
주      의
이 보고서는 소프트웨어정책연구소에서 수행한 연구보고서입니다. 
이 보고서의 내용을 발표할 때에는 반드시
소프트웨어정책연구소에서 수행한 연구결과임을 밝혀야 합니다.
AI프로젝트 규모산정 프레임워크
빙산의 수면아래, 기술규모 측정하기
경기도 성남시 분당구 대왕판교로 712번길 22 글로벌 R&D 연구동(B) 4층
Global R&D Center 4F 22 Daewangpangyo-ro 712beon-gil, Bundang-gu, Seongnam-si, Gyeonggi-do 
www.spri.kr