14 KiB
AI 개발 워크플로 비용·품질 ROI 보고서
Executive Summary
하이브리드 Plan/Review는 검증 완료된 Opus 바이브코딩 대비 비용을 23% 절감하고, Opus-only Plan/Review 대비 40% 절감하면서 검증 품질은 99% 수준을 유지한다.
m-iop-agent-cli-runtime 완료 작업을 추가 분석한 결과, G08 이하 local worker는 최종 구현 가치의 **약 30%**에 기여한 것으로 추정된다. 합리적인 추정 범위는 **25~35%**다. 이 값은 최종 PASS를 만든 worker가 아니라 실제 구현 루프, G등급, PLAN 범위량과 최종 산출물 유지도를 함께 반영한다.
| 비교 기준 | 기준 비용 | 하이브리드 비용 | 비용 절감률 | 절감 ROI¹ | 품질 유지율 |
|---|---|---|---|---|---|
| 검증 완료된 Opus 바이브코딩 | 195 | 150 | 23% | 30% | 100% |
| Opus-only Plan/Review | 250 | 150 | 40% | 67% | 99% |
¹ 절감 ROI = (기준 비용 - 하이브리드 비용) ÷ 하이브리드 비용. 즉, 하이브리드 비용 100을 투입할 때 회피하는 상대 비용이다.
경영 관점의 결론은 명확하다.
- 가장 싼 최초 결과만 필요하면 Opus 단일 세션 바이브코딩이 유리하다.
- 검증된 완료 결과가 필요하면 하이브리드 Plan/Review가 가장 높은 비용 효율을 보인다.
- 작은 작업은 Opus 단일 세션으로 즉시 처리하고, 중간·대형 작업에는 하이브리드 Plan/Review를 적용하는 것이 권장 운영안이다.
핵심 비교 지표
Opus 단일 세션 바이브코딩의 최초 실행 비용을 100으로 정규화한 중심 추정치다.
| 작업 방식 | 유료 모델 비용 지수 | 검증 품질 지수² | 비용 대비 검증 품질 |
|---|---|---|---|
| Opus 바이브코딩 최초 결과 | 100 | 65 | 0.65 |
| Opus 바이브코딩 검증 완료 | 195 | 99 | 0.51 |
| Opus-only Plan/Review | 250 | 100 | 0.40 |
| 하이브리드 Plan/Review | 150 | 99 | 0.66 |
² 품질 지수 65는 절대적인 코드 완성도가 아니라 독립 검토 시 최초 결과가 수정 없이 승인될 가능성의 중심 추정치다. 99~100은 수정과 독립 검토를 거쳐 완료된 결과의 검증 신뢰도를 의미한다.
하이브리드는 비용 대비 검증 품질이 0.66으로 가장 높다.
- 검증 완료된 Opus 바이브코딩보다 비용 효율이 30% 높다.
- Opus-only Plan/Review보다 비용 효율이 65% 높다.
- Opus-only 방식의 검증 품질을 99% 유지하면서 비용은 40% 절감한다.
바이브코딩 검증 완료 비용
Opus 바이브코딩의 비용 100은 가장 저렴하지만, 이는 별도 검증을 통과하기 전의 최초 결과 비용이다. 일반적인 개발 완료 기준에 맞추려면 검토, Required finding 수정, 재검증 비용이 추가된다.
최초 Opus 단일 세션 100
독립 검토 40~60
수정 및 재검증 30~60
──────────────────────────────
검증 완료 기대비용 170~220
중심 추정치 195
따라서 최초 비용 100과 하이브리드 비용 150을 직접 비교하면 하이브리드가 비싸 보이지만, 같은 검증 완료 상태를 기준으로 하면 비교 대상은 195와 150이다. 이 기준에서 하이브리드는 45포인트, 즉 23%를 절감한다.
하이브리드의 실질적 이점
| 비교 대상 | 하이브리드 효과 |
|---|---|
| Opus 바이브코딩 최초 결과 | 비용은 50% 증가하지만 검증 품질은 65에서 99로 상승 |
| 검증 완료된 Opus 바이브코딩 | 동일한 검증 품질에서 비용 23% 절감 |
| Opus-only Plan/Review | 품질 99% 유지, 비용 40% 절감 |
| 비용 대비 검증 품질 | 세 방식 중 최고 수준인 0.66 |
하이브리드는 단순히 저가 모델로 대체하는 방식이 아니다. 작업 특성에 따라 클라우드와 로컬 실행을 조합하고, 별도의 Plan/Review gate로 결과를 통제한다. 이 때문에 구현 비용을 낮추면서도 검증 완료 수준의 품질을 유지할 수 있다.
왜 하이브리드가 더 저렴한가
Opus 바이브코딩은 구현, 검토, 수정 과정에서 Opus가 반복적으로 전체 문맥을 처리한다. Opus-only Plan/Review는 여기에 별도 계획과 리뷰 세션의 문맥 재로딩 비용까지 추가된다.
하이브리드는 대량의 코드 탐색·구현·테스트·후속 수정을 여러 클라우드 및 로컬 실행으로 분산하고, Plan/Review gate를 독립적으로 유지한다. 그 결과 다음 두 비용을 동시에 줄인다.
- 모든 구현 토큰을 Opus로 처리하는 비용
- 오류가 발견됐을 때 Opus가 전체 구현 문맥을 다시 처리하는 비용
즉, 품질을 결정하는 독립 검증은 유지하면서 가장 많은 토큰이 발생하는 실행 구간의 평균 단가를 낮추는 것이 비용 우위의 핵심이다.
IOP Agent CLI Runtime local 기여도 사례
측정 대상과 판정 기준
측정 스냅샷은 2026년 7월 30일 현재 m-iop-agent-cli-runtime archive의 완료 작업 22개다. complete.log의 Loop History에 기록된 실제 구현·리뷰 루프만 세었으며, archive에는 남았지만 실행 또는 리뷰되지 않은 PLAN stub은 제외했다.
local-G01~local-G08: local 구현- 모든
cloud-*: cloud 구현 local-G09~local-G10: 이름과 무관하게 cloud 구현- 공식 Code Review: 항상 cloud이므로 local 구현 기여에서 제외
- 최종 PASS worker: 마지막 보정 주체일 뿐이므로 전체 기여도 판정에 사용하지 않음
이번 스냅샷에는 실행된 local-G09~local-G10이 없어서 해당 재분류가 측정값을 바꾸지는 않았다.
모델 카탈로그
이 보고서의 local 기여도와 향후 ROI 비교에는 아래 표준 모델 카탈로그를 사용한다. 특히 local-G07~local-G08은 시간대별 대체 모델이 아니라 **Pi iop/laguna-s:2.1**을 기준으로 정규화한다.
| Route | 실행 구분 | 기준 모델 | 설정 |
|---|---|---|---|
local-G01~local-G06 |
Local | Pi iop/ornith:35b |
thinking high |
local-G07~local-G08 |
Local | Pi iop/laguna-s:2.1 |
Laguna 기준 |
local-G09~local-G10 |
Cloud | Claude claude-opus-4-8 |
effort xhigh |
cloud-G01~cloud-G02 |
Cloud | Gemini 3.6 Flash | Low |
cloud-G03~cloud-G04 |
Cloud | Gemini 3.6 Flash | Medium |
cloud-G05~cloud-G06 |
Cloud | Gemini 3.6 Flash | High |
cloud-G07~cloud-G08 |
Cloud | Claude claude-opus-4-8 |
effort xhigh |
cloud-G09~cloud-G10 |
Cloud | Codex gpt-5.6-sol |
reasoning xhigh |
| 모든 공식 Code Review | Cloud | Codex gpt-5.6-sol |
reasoning xhigh |
이 카탈로그는 등급별 실행 비용과 local 대체 효과를 비교하기 위한 표준선이다. 개별 과거 실행의 일시적인 failover나 승격 target은 별도 실제 비용 로그가 있을 때만 재무 ROI에 반영한다.
측정 결과
| 측정 지표 | Local | 전체 | Local 비중 | 해석 |
|---|---|---|---|---|
| 실제 리뷰된 구현 루프 | 20 | 65 | 30.8% | local worker가 수행한 구현 회차 |
| G등급 가중치 | 111 | 448 | 24.8% | G01=1, G10=10으로 둔 난도 가중치 |
| PLAN 구현 범위량 | 3,258줄 | 13,115줄 | 24.8% | 실제 리뷰된 PLAN 문서 크기를 범위량 proxy로 사용 |
| Local 참여 완료 작업 | 15 | 22 | 68.2% | local 산출물이 한 번 이상 포함된 완료 작업 |
| 산출물 유지도 반영 종합 추정 | - | - | 약 30% | 합리적 범위 25~35% |
구현 루프, G등급, PLAN 범위량의 단순 중심은 약 27%다. 여기에 local이 먼저 만든 package, schema, lifecycle, command와 journal 기반이 최종 코드에 유지된 사례를 반영해 대표값을 30%로 잡았다. 반대로 cloud가 핵심 불변식이나 저장 구조를 크게 확장한 사례도 있으므로 35%를 상한으로 본다.
PLAN 문서 줄 수는 실제 코드 LOC나 토큰 비용이 아니다. 서로 다른 경로의 측정값이 25~31% 구간에 모이는지 확인하기 위한 보조 proxy로만 사용한다.
최종 산출물 유지도
| 유지도 | 대표 작업 | 판단 근거 |
|---|---|---|
| 높음 | 14_cli_config_fixtures, 15_host_lifecycle, 16_bootstrap_composition, 17_project_log_records |
local이 핵심 파일·타입·동작을 만들었고 최종 cloud 작업은 좁은 검증 또는 edge case 보정이었다. |
| 중간 이상 | 07_target_policy, 18_cli_command_tree, 19_cli_binary_contract, 20_project_log_journal |
local 구조가 유지됐지만 cloud가 중요한 정확성·경계 조건을 추가했다. |
| 중간 | 01_common_runtime_node_bridge, 06_config_registry, 10_state_recovery, 21_project_log_sink |
local 보정이 유지됐으나 초기 또는 최종 핵심 변경에서 cloud 비중도 컸다. |
| 낮음 | 05_contract_boundary, 09_workflow_evidence, 13_agent_domain |
local 범위가 evidence 중심이거나 후속 cloud에서 책임 경계와 구현 범위가 크게 재정리됐다. |
대표적인 높은 유지 사례는 다음과 같다.
15_host_lifecycle: local이 production deadlock을 해결했고 최종 cloud PLAN은 production code를 바꾸지 않고 cleanup 중 terminal status를 확인하는 테스트만 보강했다.16_bootstrap_composition: local이 bootstrap package와 typed-nil·identity 처리를 구현했고 최종 cloud PLAN은Name()중복 호출과 회귀 테스트를 좁게 보정했다.17_project_log_records: local이 record schema와 archive manifest를 구현했고 최종 cloud PLAN은 sealed quota identity의 길이·민감정보 검증을 추가했다.
반대로 21_project_log_sink의 최종 cloud PLAN은 project-wide replay index와 atomic batch CAS를 추가한 구조적 보정이었다. 이처럼 cloud가 핵심 구조를 확장한 작업을 함께 반영했기 때문에 local 기여도를 30%보다 과도하게 높이지 않았다.
해석과 운영 기준
이 사례에서 local은 독립적인 최종 해결자가 아니라, cloud Plan/Review의 검증 품질을 유지하면서 전체 구현 가치의 약 3분의 1을 흡수하는 실행 계층으로 기능했다. 따라서 최종 PASS가 local인 작업 비율만으로 ROI를 평가하면 local이 만든 기반 코드와 후속 cloud의 좁은 보정을 구분하지 못해 기여도를 크게 과소평가한다.
운영 지표로는 다음 값을 사용한다.
m-iop-agent-cli-runtimelocal 기여도: 대표값 30%, 합리적 범위 25~35%
이 정도의 기여도는 운영상 의미 있는 ROI가 나온 수준으로 평가한다. 이미 확보한 local 장비를 활용해 추가 비용이 전력과 운영비 중심으로 제한된다는 전제에서, cloud Plan/Review 품질을 유지하면서 전체 구현 가치의 약 30%를 local로 대체한 결과는 충분히 긍정적이다. 일회성 비용 절감 실험을 넘어 local 실행 계층을 계속 운영하고 측정할 근거가 되는 수치다.
이 값은 재무상 실제 비용 절감률과 동일하지 않다. 비용 ROI로 전환할 때는 회피한 cloud worker 비용에서 local 전력·장비 상각·운영비와 local worker 결함으로 발생한 재작업비만 차감한다. PLAN 누락이나 리뷰에서 새로 확장된 범위는 local worker 실패 비용으로 귀속하지 않는다.
현재 archive에는 worker 종료 시점의 독립적인 Git tree나 전체 patch가 없으므로 정확한 line survival 비율은 계산할 수 없다. 향후에는 worker 시작·종료 tree SHA와 최종 PASS tree SHA를 남겨 base → local → final 3-way 비교로 이 추정치를 교정한다.
기존 ROI 산정 근거
측정 대상은 m-agent-readable-repository-refactor의 완료 작업 1~11번이며, 12번 작업은 제외했다.
| 관측 항목 | 결과 |
|---|---|
| 완료 작업 | 11개 |
| 최초 작업 루프 | 11회 |
| 후속 보완 루프 | 5회 |
| 전체 구현 루프 | 16회 |
| 최초 Review PASS | 7개, 63.6% |
| 최종 Review PASS | 11개, 100% |
최초 PASS 63.6%와 유사 리팩터링 작업의 약 60% 최초 PASS 관측치를 바탕으로 최초 바이브코딩 검증 품질의 중심값을 65로 두었다. 또한 실제 표본에서 최초 작업 대비 약 45%의 보완 루프가 발생했다는 점을 검토·수정·재검증 비용 추정에 반영했다.
비용 지수는 호출별 과금 로그가 없는 상태에서 작업 단계와 반복 횟수를 바탕으로 산정한 의사결정용 상대 추정치다. 따라서 실제 계약 단가에 따른 재무 실적이 아니라, 방식 간 비용 구조와 예상 절감 폭을 비교하기 위한 기준값으로 사용한다.
권고안
작고 명확한 작업
→ Opus 단일 세션 바이브코딩
검증·책임 경계·복수 파일 변경이 필요한 작업
→ 하이브리드 Plan/Review
전 작업을 Opus-only Plan/Review로 수행하면 최고 수준의 검증 품질을 얻을 수 있지만 비용 효율이 가장 낮다. 반대로 모든 작업을 Opus 단일 세션으로 처리하면 최초 비용은 낮지만 검증과 재작업 비용의 변동성이 커진다.
따라서 작은 작업에는 Opus fast path를 사용하고, 나머지 작업에는 하이브리드 Plan/Review를 적용하는 이원화 전략을 권고한다. 이 방식은 검증 품질 99를 유지하면서 중간·대형 작업의 유료 모델 비용을 Opus-only 방식 대비 약 40% 절감하는 것을 목표로 한다.