"AI로 반값·반기간"이라는 견적, 발주 전에 이렇게 검증하세요 — 기능점수 산정 근거로 'AI 생산성 신화' 걸러내기
외주 개발 견적을 받다 보면 유독 눈에 띄는 제안이 있습니다. "AI를 활용하니 개발이 빨라져 기간도 절반, 비용도 절반"이라는 문구입니다. 발주를 앞둔 대표나 기획자 입장에서는 솔깃할 수밖에 없습니다. 하지만 이 견적은 실행 단계의 스코프 크립이나 QA 병목처럼 '진행 중에 터지는 문제'가 아니라, 계약서에 서명하기 전에 검증해야 하는 문제입니다. 견적서 자체가 근거 없는 낙관 위에 세워졌다면, 그 위험은 고스란히 발주사가 떠안게 됩니다.
이 글은 "AI라서 저절로 싸진다"는 통념을 원 출처 데이터로 검증하고, 발주사가 정량적 산정 근거를 요구해 견적서를 걸러내는 실무 방법을 다룹니다.
'AI 생산성 신화'를 데이터로 검증하기
먼저 짚어야 할 것은, "AI를 쓰면 개발이 빨라진다"는 전제가 데이터로는 그리 단순하지 않다는 사실입니다.
비영리 연구기관 METR가 2025년 7월 발표한 무작위 대조시험(RCT, arXiv:2507.09089)에서는, 숙련된 오픈소스 개발자가 자신에게 익숙한 코드베이스에서 AI 도구를 사용했을 때 오히려 작업이 약 19% 더 오래 걸렸습니다. 흥미로운 점은 개발자들이 사전에는 AI가 24% 빠르게 해줄 것으로 기대했고, 실제로 느려진 뒤에도 20% 빨라졌다고 믿는 '체감과 실측의 괴리'가 관찰됐다는 것입니다. 다만 METR는 2026년 2월 후속 공지에서 초청 개발자의 상당수가 'AI 미사용' 조건을 거부해 표본이 AI 수혜가 적은 쪽으로 치우쳤을 수 있다는 선택 편향 등 설계 한계를 인정하고 실험을 개편한다고 밝혔습니다. 즉 이 수치는 "AI가 항상 느리다"는 결론이 아니라, "체감 생산성은 실제 성과를 과대평가하기 쉽다"는 경고로 읽어야 합니다.
조직 단위 지표도 참고할 만합니다. Google Cloud DORA의 2024년 보고서에 따르면, AI 채택도가 25% 높아질 때 소프트웨어 전달 처리량은 약 1.5%, 전달 안정성은 약 7.2% 감소하는 것으로 나타났습니다. AI가 개인의 코드 작성·문서화·리뷰 속도를 높이더라도, 전달 성과 전체가 개선된다는 보장은 없다는 뜻입니다. 견적서의 '반값·반기간'은 대개 개인 코딩 속도만을 근거로 삼는데, 실제 프로젝트 성과는 통합·테스트·배포·안정화까지 포함한다는 점에서 이 격차는 그대로 리스크가 됩니다.
견적서를 검증하는 도구 — 기능점수(FP) 산정 근거
그렇다면 발주사는 무엇을 요구해야 할까요? 핵심은 "할인율"이 아니라 "산정 근거"를 묻는 것입니다. 우리나라에는 이미 공신력 있는 기준이 있습니다. 한국소프트웨어산업협회(KOSA)의 'SW사업 대가산정 가이드'입니다.
이 가이드는 사용자에게 제공되는 기능을 정량적으로 계량한 규모 단위인 기능점수(FP)에 FP당 단가를 곱해 개발비를 산정합니다. 2024년 5월 13일 공표된 개정판에서 FP당 단가는 종전 55만3,114원에서 60만5,784원으로 9.5% 인상됐습니다. 즉 만들어야 할 기능의 규모가 정해지면, 그에 상응하는 '표준 개발비'의 준거점이 존재하는 셈입니다.
이 준거점이 있으면 '반값 견적'을 이렇게 검증할 수 있습니다.
- 기능 규모는 그대로인가: 값이 반으로 줄었다면, 기능(FP)이 줄어든 것인지 단가만 후려친 것인지 확인합니다. 전자는 스코프 축소, 후자는 품질·유지보수 리스크입니다.
- AI 관련 비용이 별도로 잡혀 있는가: KOSA 개정판은 AI 도입 사업의 대가 산정체계를 신설해, AI 라이선스 비용과 함께 알고리즘 조정·데이터 수집/전처리·학습·테스트 및 검증·사용자 교육 등을 '투입공수방식'의 전문작업비로 별도 산정하도록 했습니다. AI를 쓴다면서 이 항목이 통째로 빠진 견적은, 오히려 숨은 비용을 감춘 것일 수 있습니다.
- 검증·안정화 공수가 삭감됐는가: 앞서 본 DORA 지표처럼, 속도를 얻는 대가로 안정성이 흔들릴 수 있습니다. QA·통합·인수 검증 공수를 '기간 단축' 명목으로 잘라낸 견적은 위험 신호입니다.
계약서에 못 박아야 할 것들
검증의 마지막 단계는 확인한 내용을 계약 문서로 고정하는 것입니다. 구두 약속은 실행 단계에서 증발합니다. 발주 전 체크리스트를 제안합니다.
- 산정 근거 첨부 의무: 견적서에 기능점수 기반 산정 내역(또는 이에 준하는 규모 산정 근거)을 첨부하도록 요구하고, 이를 계약의 일부로 편입합니다.
- 스코프의 기능 단위 명시: "AI로 빠르게"가 아니라 어떤 기능을 몇 개, 어느 복잡도로 제공하는지를 기능 목록으로 확정합니다. 이후 변경은 동일한 산정 기준으로 재견적합니다.
- 검증 비중의 계약화: 전체 공수 중 테스트·통합·인수 검증에 배분되는 비중을 명시하고, 여기에서 임의 삭감이 없도록 합니다.
- 산출물·인수 기준 정의: 코드가 '완성'되는 기준을 체감이 아니라 측정 가능한 인수 조건으로 정합니다. 체감 생산성과 실측의 괴리를 계약 언어로 메우는 장치입니다.
정리하면, 발주사가 던져야 할 질문은 "얼마나 싸게 해주시나요?"가 아니라 "이 가격이 나온 근거를 기능 단위로 보여주실 수 있나요?"입니다. AI는 분명 개발 방식을 바꾸고 있지만, 그것이 곧 '자동 할인'을 의미하지는 않습니다. 좋은 개발 파트너라면 반값을 자랑하기보다, 왜 그 가격이 합당한지를 기능점수와 검증 계획으로 설명할 수 있어야 합니다. 견적서를 읽는 눈이 곧 프로젝트의 첫 번째 리스크 관리입니다.