# AI 개발 워크플로 비용·품질 ROI 보고서

## Executive Summary

> **하이브리드 Plan/Review는 검증 완료된 Opus 바이브코딩 대비 비용을 23% 절감하고, Opus-only Plan/Review 대비 40% 절감하면서 검증 품질은 99% 수준을 유지한다.**

IOP에서 완료된 중대형 개발 작업군을 추가 분석한 결과, local worker는 최종 구현 가치의 **약 30%**에 기여한 것으로 추정된다. 합리적인 추정 범위는 **25~35%**다. 이 값은 최종 승인을 받은 실행 주체가 아니라 실제 구현 루프, 작업 난도, 구현 계획 범위와 최종 산출물 유지도를 함께 반영한다.

| 비교 기준 | 기준 비용 | 하이브리드 비용 | 비용 절감률 | 절감 ROI¹ | 품질 유지율 |
|---|---:|---:|---:|---:|---:|
| 검증 완료된 Opus 바이브코딩 | 195 | **150** | **23%** | **30%** | **100%** |
| Opus-only Plan/Review | 250 | **150** | **40%** | **67%** | **99%** |

¹ 절감 ROI = `(기준 비용 - 하이브리드 비용) ÷ 하이브리드 비용`. 즉, 하이브리드 비용 100을 투입할 때 회피하는 상대 비용이다.

경영 관점의 결론은 명확하다.

- 가장 싼 최초 결과만 필요하면 Opus 단일 세션 바이브코딩이 유리하다.
- 검증된 완료 결과가 필요하면 **하이브리드 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으로 정규화한 중심 추정치다.

| 작업 방식 | 유료 모델 비용 지수 | 검증 품질 지수² | 비용 대비 검증 품질 |
|---|---:|---:|---:|
| 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 수정, 재검증 비용이 추가된다.

```text
최초 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 하이브리드 개발 사례

### 측정 대상과 판정 기준

측정 스냅샷은 2026년 7월 30일 현재 IOP의 한 중대형 개발 작업군에서 완료된 작업 22개다. 작업 완료 기록에 남은 실제 구현·리뷰 루프만 세었으며, 문서만 만들어지고 실행 또는 리뷰되지 않은 계획 초안은 제외했다.

- local 장비에서 실행된 구현 루프는 local 기여로 분류했다.
- 유료 외부 모델이 실행한 구현 루프는 cloud 기여로 분류했다.
- 공식 Code Review는 독립 검증 단계이므로 local 구현 기여에서 제외했다.
- 최종 승인 직전의 마지막 보정 주체만으로 전체 기여도를 판단하지 않았다.

### 모델 카탈로그

이 보고서의 local 기여도와 향후 ROI 비교에는 아래 실행 구성을 표준선으로 사용한다. 세부 라우팅 이름 대신, 개발자가 비용 구조를 이해하는 데 필요한 실행 위치와 역할만 표시했다.

| 실행 위치 | 기준 모델 | 설정 | 주 역할 |
|---|---|---|---|
| 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 대체 효과를 비교하기 위한 표준선이다. 일시적인 모델 대체나 상위 모델 전환은 별도 실제 비용 로그가 있을 때만 재무 ROI에 반영한다.

### 측정 결과

| 측정 지표 | Local | 전체 | Local 비중 | 해석 |
|---|---:|---:|---:|---|
| 실제 리뷰된 구현 루프 | 20 | 65 | **30.8%** | local worker가 수행한 구현 회차 |
| 난도 가중치 | 111 | 448 | **24.8%** | 각 구현 루프의 난도를 1~10으로 환산 |
| 구현 계획 범위량 | 3,258줄 | 13,115줄 | **24.8%** | 실제 리뷰된 구현 계획서 크기를 범위량 proxy로 사용 |
| Local 참여 완료 작업 | 15 | 22 | **68.2%** | local 산출물이 한 번 이상 포함된 완료 작업 |
| 산출물 유지도 반영 종합 추정 | - | - | **약 30%** | 합리적 범위 **25~35%** |

구현 루프, 난도 가중치, 구현 계획 범위량의 단순 중심은 약 27%다. 여기에 local이 먼저 만든 package, schema, lifecycle, command와 journal 기반이 최종 코드에 유지된 사례를 반영해 대표값을 30%로 잡았다. 반대로 cloud가 핵심 불변식이나 저장 구조를 크게 확장한 사례도 있으므로 35%를 상한으로 본다.

구현 계획서 줄 수는 실제 코드 LOC나 토큰 비용이 아니다. 서로 다른 측정값이 25~31% 구간에 모이는지 확인하기 위한 보조 proxy로만 사용한다.

### 최종 산출물 유지도

| 유지도 | 대표 작업 유형 | 판단 근거 |
|---|---|---|
| 높음 | 설정 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에서 책임 경계와 구현 범위가 크게 재정리됐다. |

대표적인 높은 유지 사례는 다음과 같다.

- 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 길이와 민감정보 검증을 추가했다.

반대로 로그 sink 작업에서는 최종 cloud 구현이 project-wide replay index와 atomic batch CAS를 추가하는 구조적 보정을 수행했다. 이처럼 cloud가 핵심 구조를 확장한 작업을 함께 반영했기 때문에 local 기여도를 30%보다 과도하게 높이지 않았다.

### 해석과 운영 기준

이 사례에서 local은 독립적인 최종 해결자가 아니라, cloud Plan/Review의 검증 품질을 유지하면서 전체 구현 가치의 약 3분의 1을 흡수하는 실행 계층으로 기능했다. 따라서 최종 PASS가 local인 작업 비율만으로 ROI를 평가하면 local이 만든 기반 코드와 후속 cloud의 좁은 보정을 구분하지 못해 기여도를 크게 과소평가한다.

운영 지표로는 다음 값을 사용한다.

> **IOP 중대형 개발 작업군의 local 기여도: 대표값 30%, 합리적 범위 25~35%**

이 정도의 기여도는 **운영상 의미 있는 ROI가 나온 수준**으로 평가한다. 이미 확보한 local 장비를 활용해 추가 비용이 전력과 운영비 중심으로 제한된다는 전제에서, cloud Plan/Review 품질을 유지하면서 전체 구현 가치의 약 30%를 local로 대체한 결과는 충분히 긍정적이다. 일회성 비용 절감 실험을 넘어 local 실행 계층을 계속 운영하고 측정할 근거가 되는 수치다.

이 값은 재무상 실제 비용 절감률과 동일하지 않다. 비용 ROI로 전환할 때는 회피한 cloud worker 비용에서 local 전력·장비 상각·운영비와 local worker 결함으로 발생한 재작업비만 차감한다. 구현 계획 누락이나 리뷰에서 새로 확장된 범위는 local worker 실패 비용으로 귀속하지 않는다.

현재 측정 기록에는 worker 종료 시점의 독립적인 Git tree나 전체 patch가 없으므로 정확한 line survival 비율은 계산할 수 없다. 향후에는 worker 시작·종료 tree SHA와 최종 승인 tree SHA를 남겨 `base → local → final` 3-way 비교로 이 추정치를 교정한다.

## 기존 ROI 산정 근거

초기 품질 지수의 근거는 별도의 repository-wide 리팩터링 표본에서 완료된 작업 11개이며, 측정 기준이 다른 후속 작업 1개는 제외했다.

| 관측 항목 | 결과 |
|---|---:|
| 완료 작업 | 11개 |
| 최초 작업 루프 | 11회 |
| 후속 보완 루프 | 5회 |
| 전체 구현 루프 | 16회 |
| 최초 Review PASS | 7개, **63.6%** |
| 최종 Review PASS | 11개, **100%** |

최초 PASS 63.6%와 유사 리팩터링 작업의 약 60% 최초 PASS 관측치를 바탕으로 최초 바이브코딩 검증 품질의 중심값을 65로 두었다. 또한 실제 표본에서 최초 작업 대비 약 45%의 보완 루프가 발생했다는 점을 검토·수정·재검증 비용 추정에 반영했다.

비용 지수는 호출별 과금 로그가 없는 상태에서 작업 단계와 반복 횟수를 바탕으로 산정한 의사결정용 상대 추정치다. 따라서 실제 계약 단가에 따른 재무 실적이 아니라, 방식 간 비용 구조와 예상 절감 폭을 비교하기 위한 기준값으로 사용한다.

## 권고안

```text
작고 명확한 작업
→ Opus 단일 세션 바이브코딩

검증·책임 경계·복수 파일 변경이 필요한 작업
→ 하이브리드 Plan/Review
```

전 작업을 Opus-only Plan/Review로 수행하면 최고 수준의 검증 품질을 얻을 수 있지만 비용 효율이 가장 낮다. 반대로 모든 작업을 Opus 단일 세션으로 처리하면 최초 비용은 낮지만 검증과 재작업 비용의 변동성이 커진다.

따라서 **작은 작업에는 Opus fast path를 사용하고, 나머지 작업에는 하이브리드 Plan/Review를 적용하는 이원화 전략**을 권고한다. 이 방식은 검증 품질 99를 유지하면서 중간·대형 작업의 유료 모델 비용을 Opus-only 방식 대비 약 40% 절감하는 것을 목표로 한다.