목차
팀이 스프린트 두 번 만에 출시한 프로젝트에 대해 COCOMO II 스프레드시트가 33개월이라는 일정을 예측하는 것을 지켜본 적이 있다면, 문제가 무엇인지 이미 아실 것입니다. 오늘날 실무에서 쓰이는 모든 추정 모델은 개발자가 모든 줄을 직접 타이핑하고, 컨텍스트 전환에 비용이 따르며, 업무가 오후 5시에 끝나는 세계를 기준으로 보정되었습니다. 그런 세계는 더 이상 존재하지 않습니다. 저희는 최근 286 KLOC, 672개 파일, 여러 서브시스템(프로토콜 계층, 데이터 계층, 렌더링 엔진, 플랫폼 통합)으로 이루어진 애플리케이션을 처음부터 개발해 7일 만에 테스트 가능한 알파 버전에 도달했습니다. 전체 모델 패널(COCOMO Basic/Intermediate/Post-Architecture, 기능 점수, SLOC 기준선, Putnam/SLIM)이 내놓은 예측의 중앙값은 30.3개월이었습니다. 생산성 배수의 중앙값은 4,240배입니다. 가장 보수적인 기준선(복잡한 시스템 기준 하루 개발자당 25 SLOC)조차 1,433배 빗나갔습니다. 모델이 틀린 것이 아닙니다. 잘못 적용되고 있는 것입니다. 아래에서 모델별 분석, 동일 작성자 기반의 실증적 보정, 그리고 2024~2026년 무작위 대조 시험(RCT) 문헌이 에이전틱 AI가 실제로 어디서 기간을 단축하고 어디서는 단축하지 못하는지에 대해 말하는 내용을 살펴보겠습니다.
추정을 무너뜨린 프로젝트
RIADVICE는 최근 기능이 풍부하고 복잡한 애플리케이션을 개발했습니다. 분산 아키텍처 전반에서 여러 서브시스템을 조율하는 종류의 애플리케이션으로, 새로운 구현을 요구하는 시장 요건에 따라 하나의 코드베이스로 모바일과 데스크톱을 모두 지원하는 네이티브 크로스 플랫폼 환경으로 만들었습니다. 규모는 코드베이스가 말해 줍니다.
- 672개 소스 파일에 걸친 286,662 SLOC(약 286 KLOC)
- 총 변경량 1,329,399줄: 추가 862,488줄, 삭제 466,911줄
- 테스트 가능한 첫 알파 버전까지 실제 개발일 7일 동안 커밋 700건
- 수십 개 로케일로의 완전한 국제화
- 서로 깊은 연관이 없는 여러 서브시스템(프로토콜 처리, 데이터 관리, 렌더링, 플랫폼 통합)을 모두 대상 환경에 맞춰 처음부터 구축
이것은 래퍼나 껍데기만 바꾼 작업이 아니었습니다. 기존 솔루션으로는 충족할 수 없던 시장 요건을 만족시키기 위해 바닥부터 만든 네이티브 구현이었습니다. 저는 코드를 한 줄도 쓰기 전에, 코드베이스가 커지는 동안 업계 표준 소프트웨어 공수 추정 모델 전체를 코드베이스에 대해 실행하는 맞춤형 분석 도구를 프로젝트에 연결했습니다. 목표는 정직했습니다. 고전적인 모델이 예측하는 것과 AI 지원 개발이 실제로 만들어 내는 것 사이의 차이를 측정하는 것이었습니다. 결과는 반올림 오차 수준이 아닙니다. 범주 자체가 달라진 것입니다.
추정 모델의 예측과 실제 결과
이 도구는 소프트웨어 공학 문헌의 주요 추정 모델을 모두 실행합니다. COCOMO Basic(Organic, Semi-Detached, Embedded), COCOMO Intermediate(Semi-Detached와 Embedded, 튜닝 적용), COCOMO II Post-Architecture(튜닝 적용), 기능 점수(Function Points), SLOC 생산성 기준선, Putnam/SLIM이며, 원 출처 문헌에 공개된 상수를 사용해 프로젝트 유형에 맞게 보정했습니다.
| 추정 모델 | 예측 공수 | 예측 기간 | 실제 대비 배수 |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 인월 | 33.3개월 | 2,282× |
| COCOMO Basic (Semi-Detached) | 1,696 인월 | 33.7개월 | 4,240× |
| COCOMO Basic (Embedded) | 3,200 인월 | 33.1개월 | 8,000× |
| COCOMO Intermediate (Semi-Det., 튜닝) | 1,259 인월 | 30.4개월 | 3,148× |
| COCOMO Intermediate (Embedded, 튜닝) | 2,376 인월 | 30.1개월 | 5,940× |
| COCOMO II Post-Architecture (튜닝) | 1,703 인월 | 30.3개월 | 4,257× |
| 기능 점수 (간이 계산) | 17.9 인월 | 7.5개월 | 45× |
| SLOC 생산성 기준선 (하루 개발자당 25 SLOC) | 573 인월 | 573.3개월 | 1,433× |
| Putnam/SLIM | 생략 (기간 30일 미만, T 4/3 항이 발산) | 해당 없음 | 해당 없음 |
모든 모델에 걸친 생산성 배수의 중앙값은 4,240배입니다. 가장 보수적인 모델조차 실제보다 약 1,400배 긴 납기를 예측합니다. 가장 낙관적인 기능 점수 모델도 7.5개월을 예측했는데, 이는 실제 7일보다 45배 긴 기간입니다. 모델들에 따르면 이 프로젝트에는 7개월에서 47년이 걸렸어야 합니다. 알파 버전은 7일 만에 테스트할 준비를 마쳤습니다.
모델끼리도 50배에서 8,000배까지 서로 다른 답을 냅니다
이 모델들은 서로 일치하지 않습니다. 같은 코드베이스에 대해 예측값은 17.9인월에서 3,200인월까지, 178배의 편차를 보입니다. 실제 프로젝트 51건을 대상으로 COCOMO II, SEER-SEM, SLIM, TruePlanning을 비교한 SEAA 2013 벤치마크에서는 MMRE가 50~100% 수준으로 나타났습니다. COCOMO NASA 데이터셋을 대상으로 한 2023년 평가에서는 MMRE가 1.0에 가까웠고 PRED(0.25)는 0.0이었습니다. 25% 오차 범위 안에 추정된 프로젝트가 단 하나도 없었다는 뜻입니다. 이 모델들은 애초에 AI 지원 프로젝트를 위해 설계된 적이 없습니다. 그러나 모델의 부정확성을 감안하더라도 차이의 크기는 무언가 구조적인 변화가 일어났음을 알려 줍니다.
에이전틱 AI와 개발자 생산성에 대해 연구가 실제로 말하는 것
4,240배라는 수치는 극단적이며, 저는 이를 과장하고 싶지 않습니다. 그린필드 스캐폴딩은 변경량을 부풀리고, SLOC는 가치를 나타내는 지표로서 약합니다. 그래서 동료 심사를 거친 문헌을 살펴보겠습니다. Copilot 같은 어시스턴트는 크지 않지만 실질적인 향상을 가져옵니다. Peng 외(2023)는 AI 페어 프로그래머를 사용한 개발자가 과제를 55.8% 더 빨리 완료했다고 보고했습니다(95% 신뢰구간: 21~89%). 현재까지 가장 큰 규모(n=4,867)인 Microsoft/Accenture/Fortune 100 RCT(2025)는 완료한 작업이 26% 증가했다고 보고했습니다. Google의 내부 RCT(2024)는 과제 소요 시간이 약 21% 줄었다고 밝혔습니다. BIS/Ant Group 현장 실험(2024)은 주니어 직원의 코드 산출량이 55% 증가했다고 측정했습니다. 정직하게 요약하면 적합한 과제에서 1.26~1.56배입니다. 실질적이지만 판도를 바꿀 정도는 아닙니다. 에이전틱 AI는 전혀 다른 차원에서 작동합니다. Cognition의 2025년 Devin 리뷰는 고객 사례로 ETL 마이그레이션에서 10배, Java 버전 마이그레이션에서 14배, 보안 수정에서 20배를 보고했습니다. Nubank는 이전에 수년간 수천 명의 엔지니어가 필요하다고 추정되었던 수백만 줄 규모의 리팩터링에서 효율 12배 향상과 비용 20배 절감을 보고했습니다. 저희의 포팅 작업은 정확히 이 범위에 들어갑니다. 커밋 히스토그램을 보면 22시, 0시, 1시에 커밋이 집중되어 있는데, 이는 에이전트 주도 세션의 특징입니다. 반대 근거도 분명히 존재합니다. Metr.org의 2025년 RCT(숙련 개발자 16명, 성숙한 프로젝트의 과제 246개)에서는 AI가 완료 시간을 19% 늘렸습니다. 익숙한 코드베이스에서 숙련 개발자의 속도를 오히려 늦춘 것입니다. AI 도구를 도입한 GitHub 저장소 807개를 대상으로 한 2026년 이중차분법 연구(He 외, MSR '26)는 개발 속도의 "일시적" 상승과, 장기적으로 속도를 떨어뜨린 코드 복잡도의 "지속적" 증가를 확인했습니다. 논문 제목이 모든 것을 말해 줍니다. Speed at the Cost of Quality. 합의된 결론은 이렇습니다. AI는 그린필드 개발과 구조화된 개발에서 크게 도움이 되고, 코드 완성 작업에서는 조금 도움이 되며, 성숙한 코드베이스에서는 속도를 떨어뜨릴 수 있습니다. 품질 부채는 실재합니다.
모델이 무너지는 이유: 세 가지 구조적 변화
고전적인 모델의 비용 요인 중 어디에도 "개발자에게 잠들지 않고 코드베이스 전체를 컨텍스트에 담고 있는 자율 에이전트가 있다"는 설정은 없습니다. 세 가지 변화가 기간 곡선을 무너뜨립니다.
- 타이핑 병목이 사라졌습니다.
모델은 공수의 상당 부분이 기계적인 작업, 즉 보일러플레이트, 스캐폴딩, 반복적인 리팩터링, 현지화 리소스 같은 구조화된 데이터라고 가정합니다. 이번 포팅에서는 분량의 상당 부분이 에이전트가 대량으로 생성하거나 변환할 수 있는 매우 규칙적인 텍스트와 연결 코드였습니다. 사람이 직접 만들던 코드(스캐폴딩, 생성자, 플랫폼 연결 코드)도 이제 한 줄씩 타이핑하는 것이 아니라 한꺼번에 생성됩니다.
- 컨텍스트 전환 비용이 무너지고 있습니다.
프로토콜 계층, 데이터 계층, 렌더링 엔진 사이를 오가는 사람은 전환할 때마다 컨텍스트를 다시 불러오는 비용을 치릅니다. 672개 파일로 된 저장소 전체를 읽은 에이전트는 그 비용을 한 번만 치릅니다. 이 정도 규모의 코드베이스에서는 이 비대칭이 빠르게 누적됩니다.
- 달력은 더 이상 병목이 아닙니다.
모델은 사람의 근무일을 전제로 한 인력 배치 방정식을 통해 인월을 개월 단위 기간으로 변환합니다. 에이전트 세션은 밤새 실행됩니다. 커밋 히스토그램을 보면 오전 7시부터 새벽 1시까지 산출이 꾸준히 이어집니다. 8시간이 아니라 18시간 동안 활동한 것입니다.
동일 작성자 기반의 실증적 보정
파라메트릭 모델은 자릿수가 달라질 만큼 서로 다른 답을 내기 때문에, 저는 프로젝트 간 실증 보정도 실행했습니다. 같은 생태계에 속한 다른 프로덕션 저장소 세 곳에서, 에이전틱 AI 도구를 도입하기 전과 후의 인일당 코드 변경량을 비교한 것입니다.
| 프로젝트 | AI 이전 인일당 변경량 | AI 시대 인일당 변경량 | 배수 |
|---|---|---|---|
| 프로젝트 A (로드 밸런서) | 673 | 2,056 | 3.1× |
| 프로젝트 B (리포팅 서비스) | 239 | 2,127 | 8.9× |
| 프로젝트 C (처리 서비스) | 1,322 | 982 | 0.7× |
| 종합 (평균 / 중앙값) | 해당 없음 | 해당 없음 | 4.2× / 3.1× |
같은 작성자, 같은 도메인, 실제 유지보수 작업입니다. 실증적 배수는 3~9배로, 그린필드의 4,240배보다 훨씬 보수적이며 공개된 에이전틱 AI 연구의 상단 범위와 일치합니다. 한 프로젝트는 실제로 더 느려졌습니다. 향상 폭은 과제에 따라 달라지며, 보편적이지 않습니다.
프로젝트 계획에 주는 시사점
아직도 보정하지 않은 모델과 하루 25 SLOC라는 기준선으로 소프트웨어 프로젝트를 추정하고 계시다면, AI 지원 작업에서는 한 자릿수에서 세 자릿수까지 틀리게 됩니다. RIADVICE는 다음과 같이 합니다.
- 자신의 이력에 맞춰 보정하십시오. AI를 사용했을 때와 사용하지 않았을 때의 인일당 코드 산출량을 직접 비교하십시오. 비용이 적게 들고 더 정직하며, 프로젝트 계획에서 설득력 있게 제시할 수 있는 3~9배라는 범위를 얻을 수 있습니다.
- 그린필드와 유지보수를 구분하십시오. 에이전틱 AI의 배수는 그린필드와 구조화된 개발에서 가장 크고, 성숙한 코드베이스의 유지보수에서 가장 작습니다(때로는 마이너스입니다). 두 경우에 같은 숫자를 적용하지 마십시오.
- 품질 부채를 예산에 반영하십시오. AI가 주는 속도에는 복잡도의 지속적인 증가가 따라옵니다. 안정화 단계를 계획하고 측정 체계를 갖추십시오. 릴리스마다 순환 복잡도를 추적하고 복사-붙여넣기 탐지를 실행하십시오.
- 곡선의 앞부분이 아니라 전체를 추정하십시오. 결함 밀도를 두 배로 늘리는 10배의 속도 향상은 10배의 향상이 아닙니다. 더 긴 안정화 기간을 대가로 일정을 앞당긴 것일 뿐입니다.
결론
모든 추정 모델이 7개월에서 47년이 걸린다고 말한 프로젝트가 7일 만에 테스트 가능한 알파 버전에 도달했습니다. 4,240배라는 중앙값이 누군가의 프로젝트 계획이 되어서는 안 됩니다. 그러나 이는 복잡한 소프트웨어 개발의 공수를 압축하고 있는 바로 그 힘이 기간까지 다시 압축하고 있다는 분명한 신호입니다. 공개된 연구에 따르면 AI가 가져오는 효과는 1.26배의 소폭 향상에서 20배의 급등까지 다양하며, 성숙한 코드베이스에서는 마이너스 효과의 실제 위험과 측정 가능한 품질 비용이 따릅니다. 이 프로젝트에 수십 년이 걸린다고 말한 모델들은 오늘날에도 기업의 추정 스프레드시트에서 여전히 쓰이고 있는 바로 그 모델들입니다. 문제는 에이전틱 AI가 프로젝트 기간을 바꾸는지 여부가 아닙니다. 그 질문에는 연구가 이미 답했습니다. 문제는 여러분의 추정 관행이 근거를 따라잡았는지 여부입니다. 아직도 COBOL과 어셈블리를 기준으로 보정된 1981년 모델에서 숫자를 얻고 계시다면, 이제 다시 보정할 때입니다. 적어도 그 모델이 출력하는 일정을 그대로 믿는 일은 그만두어야 합니다.
"실무에서 마주하는 예측 과제에 더 잘 대응하기 위해서는 여전히 개선의 여지가 크다."
Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013
🏆 신뢰할 수 있는 엔지니어링 및 클라우드 전문성
RIADVICE: 소프트웨어 엔지니어링을 위한 믿을 수 있는 파트너
저희는 AI 시대에 맞는 엔지니어링 규율과 도구를 바탕으로 복잡한 소프트웨어 시스템을 설계, 구축, 배포합니다. 일정과 예산, 품질을 모두 지킵니다.
📚 출처 및 참고 자료
이 글은 AI 지원 소프트웨어 개발의 생산성과 소프트웨어 공수 추정에 관한 동료 심사 연구, 무작위 대조 시험, 업계 현장 보고서를 바탕으로 합니다.
- AI 생산성 연구 (RCT 및 현장 실험)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 과제 완료 시간 55.8% 단축
- Cui, R., et al. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software DevelopersMicrosoft Research, n=4,867, 완료 작업 +26.08%
- Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944, Google RCT, n=96, 과제 소요 시간 약 21% 단축
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer ProductivityMetr.org, RCT, n=16, 과제 246개, AI가 완료 시간을 19% 늘림
- He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects, arXiv:2511.04427, GitHub 저장소 807개 대상 이중차분법 연구, MSR '26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks재현 연구, +13%(통계적으로 유의하지 않음)
- 에이전틱 AI 업계 보고서
- Cognition AI (2025). Devin's 2025 Performance Review: Learnings From 18 Months of Agents At WorkETL 마이그레이션 10배, Java 마이그레이션 14배, 보안 수정 20배
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin수백만 줄 규모 리팩터링에서 엔지니어링 시간 12배, 비용 20배 절감
- BIS / Ant Group (2024). 현장 실험, 코드 산출량 +55%, 주니어 직원에게서 집중적으로 나타남
- 소프트웨어 공수 추정: 기초와 정확도
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall, 최초의 COCOMO
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall, 프로젝트 161건으로 보정
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models프로젝트 51건 대상 COCOMO II, SEER-SEM, SLIM, TruePlanning 비교, MMRE 50~100%
- Kemerer, C. F. (1993). An empirical validation of software cost estimation models, Communications of the ACM
- Nguyen, V., et al. (2019). Determining relevant training data for effort estimation using window-based COCOMO calibration프로젝트 341건 + 93건 대상 윈도 기반 보정
- Ahmad, M., & Wani, M. A. (2023). Evaluation of COCOMO Model Accuracy in Software Effort EstimationMMRE 약 1.0, PRED(0.25) = 0.0
- Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimation problem. IEEE TSE, Putnam/SLIM 모델
⚡ RIADVICE.com은 신뢰할 수 있는 엔지니어링, 클라우드 전문성, 엔터프라이즈급 소프트웨어 솔루션을 제공합니다. 일정과 예산, 품질을 모두 지킵니다.





