AI 시대의 SI 용역비 산정 체계

AI 시대 SI 소프트웨어 개발 용역비
산정 체계 개편 방안

AI가 소프트웨어 개발에 많이 사용되면서, 공공 민간에서 진행된 시스템 개발 사업 (SI, System Integration)의 대가 (즉, 용역비) 산수가 복잡해졌다.

'갑' 또는 하청업체(병정...)를 거느리고 사업 수주사인 '을'은 'AI가 개발을 하니 인건비를 줄여야 하는 것 아닌가?' 라는 생각을 하게 된 것이다. 소프트웨어 개발이 코딩을 의미하지는 않는다는 말은 현장에서 잘 통하지 않는다.

그래서 역시 AI (Claude, Opus 4.6)에게 물어봤다. 어찌하는 것이 좋을지. (실현이나 이 논리로 협상이 불가능하거나 말은 좋은데 구현이 어려운 부분이 있지만, 사고의 틀을 배운다는 관점에서 유용한 내용을 뱉어주었다. 아주 약간 손으로 수정한 버전이다.)

▲ 이미지를 클릭하면 관련 영상으로 이동합니다

1. 문제의 본질: 왜 기존 체계가 붕괴하는가

기존 MM 및 FP 기반 산정 체계는 "인간 개발자의 노동량 = 소프트웨어의 가치"라는 등식 위에 성립한다. AI 코딩 도구(Copilot, Cursor, Claude Code 등)와 AI Agent가 개발 생산성을 3~10배 끌어올리는 환경에서, 이 등식은 두 가지 방향으로 동시에 붕괴한다.

첫째, 투입량 기반 왜곡이다. 동일한 기능을 AI 활용 시 1/5의 인력으로 구현할 수 있다면, MM 기반 산정은 발주자에게 "AI 써서 빨리 만들었으니 돈을 적게 내라"는 논리를 제공하고, 수주자에게는 AI 활용을 숨기거나 의도적으로 비효율을 유지할 유인을 만든다. 둘째, 기능점수의 정의 자체가 흔들린다. AI Agent가 자율적으로 판단·실행하는 기능, RAG 기반 동적 응답, 프롬프트 엔지니어링으로 구현되는 로직 등은 전통적 FP 측정 항목(EI, EO, EQ, ILF, EIF)으로 포착되지 않는다.

핵심 질문은 이것이다: "무엇에 대한 대가를 지불할 것인가?" 노동 투입이 아닌 산출 가치(outcome value)와 지속적 운영 역량(operational capability)으로 대가의 기준축을 전환해야 한다.

---

2. 새로운 비용 산정 프레임워크

2.1 산정 체계의 3축 전환

기존의 단일축(투입 노동량)에서 다음 3축 복합 모델로 전환한다.

축 1: 산출물 가치 기반 (Outcome-Based Pricing)

ISP에서 도출된 요구사항을 기능 단위가 아닌 BOU로 재정의한다. 예컨대 "민원 처리 시간 40% 단축", "수작업 데이터 입력 제거율 90%" 등 측정 가능한 성과 지표를 계약의 기준으로 삼는다. FP가 "얼마나 많은 기능을 만들었는가"를 셌다면, BOU는 "그 기능이 어떤 가치를 만들었는가"를 센다.

축 2: 역량·아키텍처 복잡도 기반 (Capability Complexity Pricing)

AI 시대의 개발 난이도는 코드 라인 수가 아니라 시스템 설계 복잡도와 AI 통합 아키텍처의 정교함에 있다. 이를 측정하기 위한 새로운 복잡도 지표로서 CP를 도입한다.

• AI Agent 자율성 수준 (L1: 규칙 기반 → L5: 완전 자율 판단)
• 데이터 파이프라인 복잡도 (소스 수, 전처리 난이도, 실시간성 요구)
• 보안·컴플라이언스 등급 (개인정보, 의료정보 등 규제 수준)
• 통합 시스템 수 및 레거시 연동 난이도
• 프롬프트/파인튜닝 설계 정교도

축 3: 지속 운영·진화 비용 (Continuous Operation Cost)

AI 시스템은 배포 후에도 모델 드리프트 대응, 프롬프트 튜닝, 데이터 품질 관리, Agent 행동 모니터링 등 지속적 관리 비용이 발생한다. 이는 전통적 유지보수(버그 수정 + 기능 추가)와 본질적으로 다르며, 별도의 비용 축으로 산정되어야 한다.

2.2 단계별 비용 산정 구조

Phase 0: ISP 후 AI-Ready 전환 설계 (신규 단계)

ISP가 종료된 시점에서 바로 개발에 들어가는 것이 아니라, AI 전환 설계(AI Transformation Design) 단계를 신설한다.

• ISP 산출물의 AI 구현 적합성 분류: 전통 개발 vs. Agentic AI 구현 vs. SaaS 대체 vs. Agentic AI로 SaaS 대체
• 데이터 자산 현황 감사 및 AI 활용 가능성 평가
• Build vs. Agent vs. Subscribe 의사결정 매트릭스 작성 (후술 3.3 참조)
• 산정 방식: 고정가(Fixed Fee) — 컨설팅 성격이므로 산출물 기준 정액제

Phase 1: 개발 단계

구분	산정 방식	비고
Agentic AI 구현 영역	CP × 단가	아키텍처 복잡도 기반
전통 개발 영역	수정 FP × AI 보정계수(0.3~0.7)	기존 FP에 AI 생산성 반영
SaaS/Agent 대체 영역	구독료 또는 토큰 비용 + 통합 개발비	3.3절 기준 적용
데이터 준비·정제	데이터 볼륨 × 복잡도 등급	별도 항목으로 명시
프롬프트/파인튜닝 설계	전문가 공수 기반 (수정 MM)	AI 전문 인력 단가 별도 적용

AI 보정계수는 핵심적 개념이다. 기존 FP 방식을 완전히 폐기하기보다, AI 도구 활용에 따른 생산성 향상을 계수로 반영한다. 이 계수는 매년 실증 데이터에 기반하여 갱신하며, 초기에는 0.5~0.7 수준(30~50% 비용 절감)에서 시작하고 AI 도구 성숙도에 따라 점진적으로 하향 조정한다.

Phase 2: 전환·안정화 단계

기존 체계에서 경시되었던 데이터 마이그레이션, AI 모델 검증(hallucination 테스트, 편향 감사), 사용자 수용성 테스트를 독립 비용 항목으로 분리한다. 특히 AI Agent의 의사결정 품질 검증은 전통 소프트웨어 테스팅과 근본적으로 다른 전문성을 요구하므로 별도 단가를 적용한다.

Phase 3: 운영·진화 단계 (유지보수 대체)

전통적 유지보수 계약(개발비의 연 10~15%)을 폐기하고, 다음 구조로 전환한다.

• 기본 운영비: AI 인프라(GPU/API 호출 비용), 모니터링, 보안 패치 — 실비 정산
• 모델 관리비: 프롬프트 최적화, 모델 업데이트, 드리프트 대응 — CP 기반 산정
• 진화 개발비: 신규 기능 추가, Agent 역할 확장 — BOU 또는 CP 기반
• SaaS/토큰 비용: 외부 서비스 및 LLM API 호출분 — 실비 pass-through + 관리 수수료

---

3. 개발 방법론의 전환과 용역 단가에 대한 영향

3.1 기존 방법론의 한계

현행 공공 SI의 주류 방법론은 사실상 Waterfall의 변형(정보시스템 구축·운영 지침 기반)이며, 일부 프로젝트에서 형식적으로 Agile을 차용하는 수준이다. AI 개발 환경에서 이 방법론은 근본적으로 부적합하다. AI 시스템은 설계 시점에 완전한 요구사항 정의가 불가능하고, 데이터와 모델의 상호작용에서 창발적으로 기능이 정의되는 특성이 있기 때문이다.

3.2 제안: AI-Native 개발 방법론 — DEE (Design-Experiment-Evolve)

원칙 1: 실험 기반 설계(Experiment-Driven Design)

전통적 요구사항 정의서 대신, 가설-실험-검증 사이클을 도입한다. "이 업무에 AI Agent를 적용하면 처리 시간이 50% 줄어들 것이다"라는 가설을 세우고, 2~4주의 실험 스프린트에서 프로토타입으로 검증한 후, 결과에 따라 본개발 범위를 조정한다.

원칙 2: AI-Human 협업 개발 프로세스

개발 과정 자체에서 AI Agent를 개발 도구로 적극 활용하되, 인간 개발자의 역할을 재정의한다.

• AI Agent: 코드 생성, 테스트 코드 작성, 문서화, 코드 리뷰 보조
• 인간 개발자: 아키텍처 설계, AI 출력 검증, 비즈니스 로직 판단, 보안·윤리 검토
• 산출물 기준: 코드 라인 수가 아닌 VCU

원칙 3: 지속적 진화 계약(Evolutionary Contract)

일회성 납품 계약 대신, 기본 구축 + 진화 계약의 2단계 계약 구조를 채택한다. 기본 구축에서 핵심 기능의 70%를 구현하고, 나머지 30%와 최적화는 운영 데이터를 기반으로 진화 단계에서 구현한다.

3.3 방법론 전환이 용역 단가에 미치는 구체적 영향

DEE 방법론의 각 원칙은 비용 산정 구조를 다음과 같이 변화시킨다.

실험 스프린트 비용의 독립 항목화. 기존 Waterfall에서는 분석·설계·구현·테스트를 순차적 공정으로 산정했다. DEE에서는 Phase 0과 Phase 1 초기에 실험 스프린트 비용이 별도로 발생한다. 이 비용은 실패한 실험(가설 기각)도 포함하므로, 발주자가 "실패 비용"을 사업비로 인정하는 계약 구조가 전제되어야 한다. 실험 스프린트당 정액 단가를 설정하고, 총 스프린트 수의 상한을 계약에 명시하는 방식이 적합하다.

인력 구성 변화에 따른 단가 재편. AI-Human 협업 구조에서는 전통적 초·중·고급 기술자 등급 체계가 무의미해진다. 대신 다음과 같은 역할 기반 단가 체계가 필요하다.

역할	핵심 역량	단가 수준 (기존 대비)
AI 아키텍트	시스템 설계, Agent 오케스트레이션, 모델 선정	특급 기술자 × 1.3~1.5
프롬프트 엔지니어	프롬프트 설계, 파인튜닝, 평가 체계 구축	고급 기술자 × 1.0~1.2
AI 품질 검증 전문가	Hallucination 테스트, 편향 감사, 안전성 검증	고급 기술자 × 1.1~1.3
풀스택 개발자 (AI 도구 활용)	AI 보조 코딩, 통합 개발, 배포	중급~고급 기술자 × 0.8~1.0
데이터 엔지니어	파이프라인 구축, 데이터 품질 관리	고급 기술자 × 1.0~1.2

주목할 점은 풀스택 개발자의 단가가 기존보다 낮아질 수 있다는 것이다. AI 도구가 코딩 생산성을 높이므로 순수 코딩 인력의 투입 단가는 하향 압력을 받지만, 대신 AI 아키텍트나 품질 검증 전문가 등 새로운 고단가 역할이 등장한다. 결과적으로 프로젝트 총 인건비는 줄어들되, 인당 평균 단가는 상승하는 구조가 된다.

진화 계약의 비용 산정 방식. 70/30 구조에서 후반 30%는 고정가 계약이 불가능하다. 실 운영 데이터에 기반한 최적화이므로, BOU 달성 시 성과급 또는 CP 기반 T&M 변형 방식으로 산정한다. 이는 발주자에게 "개발 끝난 후에도 계속 돈을 내야 한다"는 인식 전환을 요구하지만, 그 대가로 실제 작동하는 AI 시스템을 확보하게 된다.

3.4 Build vs. Agent vs. Subscribe — 3원 의사결정 매트릭스

기존의 Build vs. Buy 이분법은 Agentic AI의 등장으로 3원 구조로 확장된다. Agentic AI가 많은 SaaS의 기능을 대체할 수 있게 되면서, 기능별로 어떤 구현 방식이 TCO 측면에서 최적인지를 비교하는 새로운 의사결정 체계가 필요하다.

선택지 1: SaaS 구독 (Subscribe)

기존처럼 상용 SaaS를 구독하는 방식이다. 장점은 즉시 도입 가능하고 벤더가 업데이트를 책임진다는 것이며, 비용 구조는 월/연 정액 구독료 + 사용자 수 비례 요금으로 예측 가능하다. 그러나 커스터마이징에 한계가 있고, 데이터가 외부 벤더에 종속되며, 장기적으로 구독료가 누적된다.

선택지 2: Agentic AI 구현 (Agent)

SaaS가 수행하던 기능을 LLM 기반 AI Agent로 직접 구현하는 방식이다. 예컨대 고객 문의 대응을 위해 Zendesk를 구독하는 대신, RAG + AI Agent를 구축하여 동일한 기능을 수행하게 할 수 있다. 비용 구조는 초기 구축비(CP 기반) + LLM API 토큰 비용(사용량 비례) + 운영 관리비로 구성된다. 장점은 완전한 커스터마이징과 데이터 주권 확보이며, 단점은 초기 구축 비용과 모델 관리 책임이 발생한다는 것이다.

선택지 3: 커스텀 개발 (Build)

전통적인 소프트웨어 개발 방식이다. AI 도구를 활용하여 생산성은 높이되, 기본적으로 코드를 직접 작성한다. 고도로 특수한 비즈니스 로직이나 규제 요건이 엄격한 영역에 적합하다.

이 세 선택지를 비교하기 위한 TCO 산정 비교 프레임워크는 다음과 같다.

비교 항목	SaaS 구독	Agentic AI 구현	커스텀 개발
초기 비용	낮음 (설정·연동비)	중간 (Agent 구축비)	높음 (전체 개발비)
월간 운영비	구독료 (고정·예측 가능)	토큰 비용 (변동·사용량 비례)	유지보수 인건비 (고정)
5년 TCO 추세	선형 누적 (구독료 인상 리스크)	초기 높고 후반 체감 (토큰 단가 하락 추세)	초기 매우 높고 이후 안정
커스터마이징	제한적	완전 자유	완전 자유
데이터 주권	벤더 의존	완전 보유	완전 보유
기능 진화	벤더 로드맵 의존	자체 결정	자체 결정
장애 대응	벤더 SLA 의존	자체 운영팀 필요	자체 운영팀 필요

토큰 비용 vs. SaaS 구독료 비교 산정법. Agentic AI 도입 여부를 판단할 때 가장 핵심적인 비교는 "SaaS 구독료 대비 토큰 비용이 얼마인가"이다. 이를 산정하기 위해 다음 절차를 따른다.

1단계로, 해당 기능의 월간 사용량을 추정한다 — 처리 건수, 평균 입출력 토큰 수, 호출 빈도를 포함한다. 2단계로, 토큰 단가(현 시점 기준 + 연간 30~50% 하락 추세 반영)를 적용하여 월간 토큰 비용을 산출한다. 3단계로, 여기에 Agent 구축 초기 비용의 월 상각분과 운영 관리 인건비를 더한다. 4단계로, 이 합계를 SaaS 월간 구독료와 비교한다.

현재 시점에서 일반적 패턴은 이렇다: 사용량이 적을 때는 SaaS가 유리하고(고정 구독료가 토큰 비용보다 낮음), 사용량이 일정 규모를 넘으면 Agentic AI가 유리해진다(토큰 비용의 한계비용이 SaaS의 사용자당 추가 비용보다 낮음). 이 손익분기 사용량(Break-Even Usage Volume)을 기능별로 산출하는 것이 Phase 0 AI 전환 설계의 핵심 작업이 된다.

추가로 고려해야 할 변수는 토큰 단가의 하락 추세이다. LLM API 가격은 최근 2년간 급격히 하락해왔으며, 이 추세가 지속될 경우 Agentic AI의 TCO 우위는 시간이 갈수록 확대된다. 반대로 SaaS 구독료는 통상 매년 5~10% 인상되는 경향이 있어, 5년 TCO 비교 시 이 격차가 크게 벌어질 수 있다.

의사결정 기준 요약. 다음 조건 중 다수를 충족하면 Agentic AI 구현을 우선 고려한다.

• 월간 처리량이 손익분기점을 초과하는 경우
• 해당 기능에 높은 수준의 커스터마이징이 요구되는 경우
• 데이터 주권·보안 요건이 외부 SaaS 사용을 제약하는 경우
• 기존 SaaS로는 구현 불가능한 복합적 업무 자동화가 필요한 경우
• 여러 SaaS를 조합하여 쓰던 것을 하나의 Agent로 통합할 수 있는 경우

반면 다음 조건에서는 SaaS 구독을 유지하는 것이 합리적이다.

• 해당 기능이 표준화되어 있고 커스터마이징 필요가 낮은 경우
• 사용량이 손익분기점 이하인 경우
• 벤더의 지속적 기능 업데이트가 자체 개발보다 빠른 경우
• Agent 구축·운영 역량을 내부에 확보하기 어려운 경우

---

4. 제도적 전환을 위한 로드맵

단기 (1~2년): 기존 체계 위의 보정

• 현행 FP 산정에 AI 보정계수 도입 (SW사업 대가 기준에 반영)
• AI 전문 인력 등급 및 단가 신설 (프롬프트 엔지니어, AI 아키텍트, MLOps 등)
• SaaS 구독료 및 LLM API 토큰 비용의 사업비 인정 근거 마련
• AI 구현 영역에 대한 실증 데이터 수집 사업 착수
• Build vs. Agent vs. Subscribe 의사결정 가이드라인 시범 적용

중기 (3~4년): 새 체계의 병행 운영

• CP 산정 기준 고시
• BOU 기반 성과 계약 시범 사업 실시
• DEE 방법론의 공공 SI 적용 가이드라인 수립
• AI Agent 품질 검증 표준 제정
• 토큰 비용 벤치마크 데이터 공공 축적 및 단가 기준표 발행

장기 (5년~): 전면 전환

• MM/FP 기반 산정의 단계적 폐지
• CP + BOU + 운영비의 3축 산정 체계 전면 적용
• AI 시스템 전문 감리 체계 구축
• 실증 데이터 기반 단가 자동 갱신 시스템 운영

---

5. 핵심 쟁점과 유의사항

발주자-수주자 간 정보 비대칭 심화 문제. AI 활용 수준에 따른 실제 생산성 향상 정도를 발주자가 검증하기 어렵다. 이를 해소하려면 AI 활용 내역의 투명한 보고 의무, 제3자 기술 감리의 강화, 그리고 오픈소스 기반 생산성 벤치마크 데이터의 공공 축적이 필요하다.

토큰 비용의 급격한 변동성 관리. LLM API 토큰 단가는 모델 세대 교체, 경쟁 심화, 하드웨어 발전에 따라 급변할 수 있다. 하락 추세가 지배적이지만 특정 고성능 모델의 단가가 일시적으로 상승하는 경우도 있다. 계약에 토큰 단가 변동 조항(Price Adjustment Clause)을 반드시 포함하고, 분기별로 실비 정산하는 구조가 필요하다.

중소 SI 업체의 전환 충격 완화. MM 기반 체계는 사실상 인력 파견 사업에 가까운 중소 SI 업체의 생존 기반이었다. 체계 전환 시 이들의 역량 전환을 지원하는 교육·전환 프로그램이 병행되어야 하며, 전환 기간 중 경과 조치가 필요하다. 특히 Agentic AI 구축 역량을 중소 업체가 확보할 수 있도록, 공공 교육 프로그램과 표준 Agent 프레임워크의 제공이 병행되어야 한다.

AI Agent의 책임 소재 명확화. AI Agent가 자율적으로 판단·실행한 결과에 대한 책임이 발주자에게 있는지 수주자에게 있는지를 계약에 명시해야 한다. 특히 공공 부문에서 AI Agent의 오류가 시민에게 직접 영향을 미치는 경우, SLA에 Agent 정확도 기준과 fallback 절차를 포함시켜야 한다.

---

부록: 약어표

약어	원어	설명
MM	Man-Month	인월, 소프트웨어 개발 투입 공수의 전통적 측정 단위
FP	Function Point	기능점수, 소프트웨어 기능 규모를 정량적으로 측정하는 단위
EI	External Input	외부 입력, FP 측정의 5대 구성요소 중 하나
EO	External Output	외부 출력, FP 측정의 5대 구성요소 중 하나
EQ	External Inquiry	외부 조회, FP 측정의 5대 구성요소 중 하나
ILF	Internal Logical File	내부 논리 파일, FP 측정의 5대 구성요소 중 하나
EIF	External Interface File	외부 인터페이스 파일, FP 측정의 5대 구성요소 중 하나
ISP	Information Strategy Planning	정보화 전략 계획
SI	System Integration	시스템 통합, 정보시스템 구축 사업의 통칭
BOU	Business Outcome Unit	비즈니스 성과 단위, 본 문서에서 제안하는 신규 산정 단위
CP	Capability Point	역량점수, 본 문서에서 제안하는 AI 시스템 복잡도 측정 단위
VCU	Verified Capability Unit	검증된 기능 단위, DEE 방법론의 산출물 측정 기준
DEE	Design-Experiment-Evolve	설계-실험-진화, 본 문서에서 제안하는 AI-Native 개발 방법론
TCO	Total Cost of Ownership	총 소유 비용
RAG	Retrieval-Augmented Generation	검색 증강 생성, LLM의 외부 지식 활용 기법
LLM	Large Language Model	대규모 언어 모델
SaaS	Software as a Service	서비스형 소프트웨어
SLA	Service Level Agreement	서비스 수준 협약
MLOps	Machine Learning Operations	머신러닝 운영, ML 모델의 배포·관리 체계
T&M	Time and Material	실비 정산 방식의 계약 유형