diff --git a/docs/agent-development-workflow-cost-quality-report.md b/docs/agent-development-workflow-cost-quality-report.md index 546967e..04cb74c 100644 --- a/docs/agent-development-workflow-cost-quality-report.md +++ b/docs/agent-development-workflow-cost-quality-report.md @@ -4,7 +4,7 @@ > **하이브리드 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 범위량과 최종 산출물 유지도를 함께 반영한다. +IOP에서 완료된 중대형 개발 작업군을 추가 분석한 결과, local worker는 최종 구현 가치의 **약 30%**에 기여한 것으로 추정된다. 합리적인 추정 범위는 **25~35%**다. 이 값은 최종 승인을 받은 실행 주체가 아니라 실제 구현 루프, 작업 난도, 구현 계획 범위와 최종 산출물 유지도를 함께 반영한다. | 비교 기준 | 기준 비용 | 하이브리드 비용 | 비용 절감률 | 절감 ROI¹ | 품질 유지율 | |---|---:|---:|---:|---:|---:| @@ -19,6 +19,20 @@ - 검증된 완료 결과가 필요하면 **하이브리드 Plan/Review가 가장 높은 비용 효율**을 보인다. - 작은 작업은 Opus 단일 세션으로 즉시 처리하고, 중간·대형 작업에는 하이브리드 Plan/Review를 적용하는 것이 권장 운영안이다. +## 문서를 읽기 위한 최소 배경 + +IOP는 AI 모델과 개발 에이전트의 실행을 여러 환경에 배치하고 통제하는 플랫폼이다. 이 보고서가 평가하는 대상은 IOP 제품의 추론 API 비용이 아니라, **IOP 개발 과정에 적용한 AI 개발 워크플로의 비용 대비 품질**이다. + +이 문서에서는 다음 용어를 사용한다. + +- **local worker**: 사내 또는 보유 장비에서 실행되는 모델이 코드 탐색, 구현, 테스트를 수행하는 실행 단위 +- **cloud worker**: 유료 외부 모델이 같은 종류의 개발 작업을 수행하는 실행 단위 +- **Plan/Review**: 구현 전에 범위와 검증 기준을 계획하고, 구현 후에는 별도의 모델이 독립 검토하는 방식 +- **바이브코딩**: 하나의 고성능 모델 세션이 계획, 구현, 검증을 대부분 연속해서 수행하는 방식 +- **하이브리드 Plan/Review**: local과 cloud worker가 구현을 분담하되, 계획과 독립 검토 절차는 유지하는 방식 + +따라서 이 보고서의 핵심 질문은 “local 모델만으로 개발을 끝낼 수 있는가”가 아니다. **검증 품질을 유지하면서 유료 cloud 모델이 담당하던 구현량을 local 실행으로 얼마나 안전하게 대체할 수 있는가**다. + ## 핵심 비교 지표 Opus 단일 세션 바이브코딩의 최초 실행 비용을 100으로 정규화한 중심 추정치다. @@ -75,68 +89,61 @@ Opus 바이브코딩은 구현, 검토, 수정 과정에서 Opus가 반복적으 즉, 품질을 결정하는 독립 검증은 유지하면서 가장 많은 토큰이 발생하는 실행 구간의 평균 단가를 낮추는 것이 비용 우위의 핵심이다. -## IOP Agent CLI Runtime local 기여도 사례 +## IOP 하이브리드 개발 사례 ### 측정 대상과 판정 기준 -측정 스냅샷은 2026년 7월 30일 현재 `m-iop-agent-cli-runtime` archive의 완료 작업 22개다. `complete.log`의 Loop History에 기록된 실제 구현·리뷰 루프만 세었으며, archive에는 남았지만 실행 또는 리뷰되지 않은 PLAN stub은 제외했다. +측정 스냅샷은 2026년 7월 30일 현재 IOP의 한 중대형 개발 작업군에서 완료된 작업 22개다. 작업 완료 기록에 남은 실제 구현·리뷰 루프만 세었으며, 문서만 만들어지고 실행 또는 리뷰되지 않은 계획 초안은 제외했다. -- `local-G01`~`local-G08`: local 구현 -- 모든 `cloud-*`: cloud 구현 -- `local-G09`~`local-G10`: 이름과 무관하게 cloud 구현 -- 공식 Code Review: 항상 cloud이므로 local 구현 기여에서 제외 -- 최종 PASS worker: 마지막 보정 주체일 뿐이므로 전체 기여도 판정에 사용하지 않음 - -이번 스냅샷에는 실행된 `local-G09`~`local-G10`이 없어서 해당 재분류가 측정값을 바꾸지는 않았다. +- local 장비에서 실행된 구현 루프는 local 기여로 분류했다. +- 유료 외부 모델이 실행한 구현 루프는 cloud 기여로 분류했다. +- 공식 Code Review는 독립 검증 단계이므로 local 구현 기여에서 제외했다. +- 최종 승인 직전의 마지막 보정 주체만으로 전체 기여도를 판단하지 않았다. ### 모델 카탈로그 -이 보고서의 local 기여도와 향후 ROI 비교에는 아래 표준 모델 카탈로그를 사용한다. 특히 `local-G07`~`local-G08`은 시간대별 대체 모델이 아니라 **Pi `iop/laguna-s:2.1`**을 기준으로 정규화한다. +이 보고서의 local 기여도와 향후 ROI 비교에는 아래 실행 구성을 표준선으로 사용한다. 세부 라우팅 이름 대신, 개발자가 비용 구조를 이해하는 데 필요한 실행 위치와 역할만 표시했다. -| 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 | Pi `iop/ornith:35b` | thinking high | 일반 구현·수정 | +| Local | Pi `iop/laguna-s:2.1` | Laguna 기준 | 상대적으로 복잡한 local 구현 | +| Cloud | Gemini 3.6 Flash | Low~High | 비용 최적화형 cloud 구현 | +| Cloud | Claude `claude-opus-4-8` | effort xhigh | 고난도 구현·보정 | +| Cloud | Codex `gpt-5.6-sol` | reasoning xhigh | 고난도 구현과 독립 Code Review | -이 카탈로그는 등급별 실행 비용과 local 대체 효과를 비교하기 위한 표준선이다. 개별 과거 실행의 일시적인 failover나 승격 target은 별도 실제 비용 로그가 있을 때만 재무 ROI에 반영한다. +이 구성은 실행 위치별 비용과 local 대체 효과를 비교하기 위한 표준선이다. 일시적인 모델 대체나 상위 모델 전환은 별도 실제 비용 로그가 있을 때만 재무 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로 사용 | +| 난도 가중치 | 111 | 448 | **24.8%** | 각 구현 루프의 난도를 1~10으로 환산 | +| 구현 계획 범위량 | 3,258줄 | 13,115줄 | **24.8%** | 실제 리뷰된 구현 계획서 크기를 범위량 proxy로 사용 | | Local 참여 완료 작업 | 15 | 22 | **68.2%** | local 산출물이 한 번 이상 포함된 완료 작업 | | 산출물 유지도 반영 종합 추정 | - | - | **약 30%** | 합리적 범위 **25~35%** | -구현 루프, G등급, PLAN 범위량의 단순 중심은 약 27%다. 여기에 local이 먼저 만든 package, schema, lifecycle, command와 journal 기반이 최종 코드에 유지된 사례를 반영해 대표값을 30%로 잡았다. 반대로 cloud가 핵심 불변식이나 저장 구조를 크게 확장한 사례도 있으므로 35%를 상한으로 본다. +구현 루프, 난도 가중치, 구현 계획 범위량의 단순 중심은 약 27%다. 여기에 local이 먼저 만든 package, schema, lifecycle, command와 journal 기반이 최종 코드에 유지된 사례를 반영해 대표값을 30%로 잡았다. 반대로 cloud가 핵심 불변식이나 저장 구조를 크게 확장한 사례도 있으므로 35%를 상한으로 본다. -PLAN 문서 줄 수는 실제 코드 LOC나 토큰 비용이 아니다. 서로 다른 경로의 측정값이 25~31% 구간에 모이는지 확인하기 위한 보조 proxy로만 사용한다. +구현 계획서 줄 수는 실제 코드 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에서 책임 경계와 구현 범위가 크게 재정리됐다. | +| 높음 | 설정 fixture, host lifecycle, bootstrap 조립, 로그 record | local이 핵심 파일·타입·동작을 만들었고 최종 cloud 작업은 좁은 검증 또는 edge case 보정이었다. | +| 중간 이상 | 실행 정책, CLI command tree, binary 계약, 로그 journal | local 구조가 유지됐지만 cloud가 중요한 정확성·경계 조건을 추가했다. | +| 중간 | 공통 runtime 연결, 설정 registry, 상태 복구, 로그 sink | local 보정이 유지됐으나 초기 또는 최종 핵심 변경에서 cloud 비중도 컸다. | +| 낮음 | 계약 경계, workflow evidence, agent domain | local 범위가 evidence 중심이거나 후속 cloud에서 책임 경계와 구현 범위가 크게 재정리됐다. | 대표적인 높은 유지 사례는 다음과 같다. -- `15_host_lifecycle`: local이 production deadlock을 해결했고 [최종 cloud PLAN](../agent-task/archive/2026/07/m-iop-agent-cli-runtime/15+13_host_lifecycle/plan_cloud_G03_2.log)은 production code를 바꾸지 않고 cleanup 중 terminal status를 확인하는 테스트만 보강했다. -- `16_bootstrap_composition`: local이 bootstrap package와 typed-nil·identity 처리를 구현했고 [최종 cloud PLAN](../agent-task/archive/2026/07/m-iop-agent-cli-runtime/16+13,15_bootstrap_composition/plan_cloud_G03_2.log)은 `Name()` 중복 호출과 회귀 테스트를 좁게 보정했다. -- `17_project_log_records`: local이 record schema와 archive manifest를 구현했고 [최종 cloud PLAN](../agent-task/archive/2026/07/m-iop-agent-cli-runtime/17+13_project_log_records/plan_cloud_G02_3.log)은 sealed quota identity의 길이·민감정보 검증을 추가했다. +- host lifecycle에서는 local이 production deadlock을 해결했고, 최종 cloud 작업은 production code를 바꾸지 않고 cleanup 중 terminal status를 확인하는 테스트만 보강했다. +- bootstrap 조립에서는 local이 package와 typed-nil·identity 처리를 구현했고, 최종 cloud 작업은 중복 호출과 회귀 테스트를 좁게 보정했다. +- 로그 record에서는 local이 record schema와 manifest를 구현했고, 최종 cloud 작업은 identity 길이와 민감정보 검증을 추가했다. -반대로 [21_project_log_sink의 최종 cloud PLAN](../agent-task/archive/2026/07/m-iop-agent-cli-runtime/21+13,17,20_project_log_sink/plan_cloud_G10_3.log)은 project-wide replay index와 atomic batch CAS를 추가한 구조적 보정이었다. 이처럼 cloud가 핵심 구조를 확장한 작업을 함께 반영했기 때문에 local 기여도를 30%보다 과도하게 높이지 않았다. +반대로 로그 sink 작업에서는 최종 cloud 구현이 project-wide replay index와 atomic batch CAS를 추가하는 구조적 보정을 수행했다. 이처럼 cloud가 핵심 구조를 확장한 작업을 함께 반영했기 때문에 local 기여도를 30%보다 과도하게 높이지 않았다. ### 해석과 운영 기준 @@ -144,17 +151,17 @@ PLAN 문서 줄 수는 실제 코드 LOC나 토큰 비용이 아니다. 서로 운영 지표로는 다음 값을 사용한다. -> **`m-iop-agent-cli-runtime` local 기여도: 대표값 30%, 합리적 범위 25~35%** +> **IOP 중대형 개발 작업군의 local 기여도: 대표값 30%, 합리적 범위 25~35%** 이 정도의 기여도는 **운영상 의미 있는 ROI가 나온 수준**으로 평가한다. 이미 확보한 local 장비를 활용해 추가 비용이 전력과 운영비 중심으로 제한된다는 전제에서, cloud Plan/Review 품질을 유지하면서 전체 구현 가치의 약 30%를 local로 대체한 결과는 충분히 긍정적이다. 일회성 비용 절감 실험을 넘어 local 실행 계층을 계속 운영하고 측정할 근거가 되는 수치다. -이 값은 재무상 실제 비용 절감률과 동일하지 않다. 비용 ROI로 전환할 때는 회피한 cloud worker 비용에서 local 전력·장비 상각·운영비와 local worker 결함으로 발생한 재작업비만 차감한다. PLAN 누락이나 리뷰에서 새로 확장된 범위는 local worker 실패 비용으로 귀속하지 않는다. +이 값은 재무상 실제 비용 절감률과 동일하지 않다. 비용 ROI로 전환할 때는 회피한 cloud worker 비용에서 local 전력·장비 상각·운영비와 local worker 결함으로 발생한 재작업비만 차감한다. 구현 계획 누락이나 리뷰에서 새로 확장된 범위는 local worker 실패 비용으로 귀속하지 않는다. -현재 archive에는 worker 종료 시점의 독립적인 Git tree나 전체 patch가 없으므로 정확한 line survival 비율은 계산할 수 없다. 향후에는 worker 시작·종료 tree SHA와 최종 PASS tree SHA를 남겨 `base → local → final` 3-way 비교로 이 추정치를 교정한다. +현재 측정 기록에는 worker 종료 시점의 독립적인 Git tree나 전체 patch가 없으므로 정확한 line survival 비율은 계산할 수 없다. 향후에는 worker 시작·종료 tree SHA와 최종 승인 tree SHA를 남겨 `base → local → final` 3-way 비교로 이 추정치를 교정한다. ## 기존 ROI 산정 근거 -측정 대상은 `m-agent-readable-repository-refactor`의 완료 작업 1~11번이며, 12번 작업은 제외했다. +초기 품질 지수의 근거는 별도의 repository-wide 리팩터링 표본에서 완료된 작업 11개이며, 측정 기준이 다른 후속 작업 1개는 제외했다. | 관측 항목 | 결과 | |---|---:|