AI가 기능당 배포 시간을 3일에서 3시간으로 단축했습니다. 실제 사용된 스택을 공개합니다.

저는 항상 똑같은 DM을 받습니다: "멋지네요, 하지만 AI가 실제로 배포 속도를 높여주나요, 아니면 그냥 거품인가요?" 그래서 지난 분기에 완료된 한 MVP 구축 사례의 표를 가져왔습니다. 이 수치들은 느낌이 아니라 측정된 것입니다.

| 활동 | 전통적인 시니어 팀 | 에이전트 기반 SDLC (Software Development Life Cycle) 사용 시 | 속도 향상 |
| :--- | :--- | :--- | : |
| 기능 계획 (ARCH 문서 + 태스크) | 2–4시간 인간 토론 | 15분 (architect agent + gate:plan) | ~10배 |
| 작은 기능 코딩 | 1–3일 시니어 개발자 | 1–2시간 에이전트 출력물에 대한 인간 리뷰 | ~10–15배 |
| 코드 리뷰 | 2–4시간, 1–2일에 걸친 비동기 방식 | 30분 (5명의 리뷰어가 병렬로 진행) | ~10배 |
| QA / 테스트 스위트 (test suite) | 1일 | 15분 (qa-engineer agent + 스팟 체크) | ~25배 |
| 배포 (canary + 모니터링) | ~4시간 | ~10분 (auto-canary) | ~25배 |
| 기능당 엔드 투 엔드 (End-to-end) | ~3–5일 | ~3–5시간 | ~10배 |

기능 하나를 배포하는 시간이 "다음 주에 준비될 겁니다"에서 "점심 식사 후에 준비될 겁니다"로 줄어듭니다. 실제로 일하는 개발자에게 있어, 이는 그 어떤 "비용 55% 절감"이라는 헤드라인보다 더 중요한 지표입니다.

전체 MVP 그림

좋습니다, 하지만 단일 기능의 속도 향상이 반드시 MVP의 전체 배포 속도가 빨라진다는 것을 의미하지는 않습니다. 때로는 절약한 시간을 더 많은 리뷰에 소비하기도 합니다. 그래서 여기 엔드 투 엔드(end-to-end) 결과가 있습니다:

| 작업 영역 | 전통적 방식 (PM 1명 + 엔지니어 4명, ~3개월) | 에이전트 + voice-pack 사용 시 (PM 1명 + 엔지니어 2명 + 에이전트, ~6–8주) |
| :--- | :--- | : |
| Architecture + ADRs | ~$20K | ~$10K |
| Backend (Twilio, OpenAI, call routing) | ~$80K | ~$30K |
| Frontend (operator dashboard) | ~$40K | ~$15K |
| Database + migrations | ~$15K | ~$5K |
| Test suite + QA | ~$25K | ~$10K |
| Security review + pen test | ~$20K | ~$15K (외부 pen test는 여전히 필요) |
| Compliance (voice-pack) | ~$42K | ~$22K |
| Deployment + CI/CD | ~$15K | ~$8K |
| Documentation | ~$10K | ~$3K |
| PM + buffer | $20K | $10K |
| 합계 | **$287K** | **$128K** |
| LLM 연산 비용 | $0 | ~$500–$1,500 |
| 실제 소요 시간 (Wall-clock) | ~3개월 | ~6–8주 |
| 인원 (Headcount) | PM 1명 + 엔지니어 4명 | PM 1명 + 엔지니어 2명 + 에이전트 |

비용 절감: ~55%. 시간 절감: ~40–50%. 인원: 4명 → 2명 (0명이 아닙니다).

실무 개발자들을 위한 두 가지 중요한 솔직한 세부 사항: 전체 MVP에 걸친 LLM 비용은 $500–$1,500입니다.

단순히 몇 센트 수준이 아닙니다. 아키텍처 초안 작성(architecture drafting), 코드 생성(code generation), 병렬 리뷰어(parallel reviewers), 배포 자동화(deployment automation), 그리고 메모리 피드백 루프(memory feedback loop) 전반에 걸쳐 네 자릿수 달러의 비용이 소모됩니다. 단일 에이전트 프롬프트(agent prompt)를 전체 빌드(full build)와 비교하지 마세요. 여전히 엔지니어가 필요합니다. "엔지니어 2명 + 에이전트"라는 말은 실제 인간이 파이프라인(pipeline)을 운영하고, 에이전트의 출력물을 검토하며, 에이전트가 생성한 버그를 수정하고, Twilio(또는 기타 서비스)를 통합하며, 코드를 배포(shipping)한다는 의미입니다. 2026년에 인간이 한 명도 없이 MVP를 출시하는 스타트업은 존재하지 않습니다. "에이전트들"이 실제로 무엇을 하고 있을까요? 대부분의 게시물이 이 부분에서 모호하게 넘어갑니다. 현실은 이렇습니다: 34개의 전문 에이전트(specialist agents), 8단계의 프로세스, 기능당 2개의 인간 게이트(human gates). 아키텍처 다이어그램은 여기에서 확인할 수 있습니다: greatcto.systems/architecture – SVG의 모든 박스는 해당 에이전트의 GitHub 소스로 연결됩니다. 가장 빈번하게 실행되는 데일리 드라이버(daily-driver) 에이전트들은 다음과 같습니다:

• architect – ARCH.md + ADR + 비용 추정치를 작성하며, gate:plan 단계 전 실행
• pm – 명시적인 의존성을 가진 세부 작업(beads tasks)으로 분해
• parallel-friendly senior-dev (×N) – 작업을 할당받아 TDD, 격리된 워크트리(isolated worktree)를 사용하여 diff를 배포
• qa-engineer – 타입 체크(type-check) + 린트(lint) + 테스트 + 커버리지(coverage)
• security-officer – OWASP, CVE 스캔, 비밀값 탐지(secret detection)
• code-reviewer – 최종 diff에 대한 12개 관점의 리뷰
• devops – 카나리(canary) + 상태 확인(health checks) + 자동 롤백(auto-rollback)
• l3-support – 운영 환경 트리아지(production triage) + 사후 분석(postmortem)
• continuous-learner – 교훈을 추출하여 .great_cto/lessons.md에 저장

여기에 더해, 특정 도메인이 트리거될 때만 실행되는 26개의 아키타입(archetype) 특화 리뷰어들이 있습니다 – voice-AI, healthcare, fintech, robotics 등. 핵심은 34개의 에이전트가 항상 켜져 있다는 것이 아닙니다. 핵심은 특정 PR(Pull Request)에 대해 5~7개가 실행된다는 것이며, 그 7개가 무엇인지는 귀하의 레포지토리(repo) 상태에 따라 달라진다는 점입니다.

컴플라이언스 팩 (Compliance packs, 10개)
규제 산업 분야로 제품을 출시한다면, 에이전트 기반의 SDLC(Software Development Life Cycle)만으로는 충분하지 않습니다. 어떤 게이트를 연결해야 할지 알 수 있는 적절한 리뷰어 에이전트도 필요합니다. 그래서 '팩(packs)'이 존재합니다. 팩은 레포지토리 내의 산업 신호(예: package.json에 twilio가 있으면 → voice)에 따라 트리거됩니다. 이는 전문 리뷰어 에이전트를 부착하고, 위협 모델(threat model)을 생성하며, 지정된 인간 게이트를 연결합니다.

각 항목별 요약:
voice-pack – twilio, livekit, deepgram, elevenlabs → TCPA + 주(state) 녹음 동의 + STIR/SHAKEN + PCI redaction
clinical-pack – clinical, PHI, SaMD, CDS → FDA SaMD 분류 + HIPAA + 21 CFR Part 11
hr-ai-pack – recruit, candidate, ATS → NYC LL 144 AEDT 편향성 감사 + EEOC + EU AI Act Annex III
api-platform-pack – REST, GraphQL, webhook, OpenAPI → OAuth 2.1 + RFC 8594 Sunset + HMAC webhook 서명 + 멱등성 (idempotency)
lending-pack – loan, BNPL, credit, FCRA, ECOA → ECOA Reg B 불이익 조치 (adverse-action) + BISG 공정 대출 + NMLS 주(state) 매트릭스
clinical-trials-pack – CTMS, EDC, eConsent, FHIR, HL7 → ICH-GCP + Part 11 감사 추적 (audit trail) + CDISC + IRB 준비 완료
robotics-pack – cobot, ROS 2, surgical robot → ISO 10218 + IEC 61508 + HARA + SROS2
em-fintech-pack – RBI, CBN, BSP, UPI, PIX, M-Pesa → 인도 DPDP + 국가 간 (cross-border) + 라이선스 전략
climate-pack – Verra, Gold Standard, Scope 1/2/3, CDP, CSRD → MRV 방법론 + 생물 보안 (biosecurity)
drug-discovery-pack – binding affinity, ADMET, AlphaFold, LIMS, GLP → 적용 영역 (applicability domain) + IQ/OQ/PQ + ALCOA+

각 팩(pack)은 1~4개의 리뷰어 에이전트(reviewer agents), 지정된 인간 게이트(human gates), 평가 고정 장치(eval fixtures), 그리고 필수 산출물 목록(required-artefact list)을 추가합니다. 기업 카탈로그를 포함한 전체 상세 내용은 greatcto.systems/packs 에서 확인할 수 있습니다.

탐지 작동 방식 (Hacker News 독자들이 물어볼 부분) {
name : ' voice-pack ' ,
signals : {
deps : [ ' twilio ' , ' @livekit/agents ' , ' deepgram-sdk ' ] ,
keywords : [ ' voice agent ' , ' IVR ' , ' phone tree ' ] ,
files : [ ' twilio.config.* ' , ' livekit.yaml ' ] ,
} ,
attaches : {
archetypes : [ ' ai-system ' , ' agent-product ' ] ,
reviewer : ' voice-ai-reviewer ' ,
gates : [ ' gate:voice-compliance ' ] ,
}
}

퍼지 부분 일치(fuzzy substring)가 아닌 정확한 키워드 매칭(Exact-match keyword scanning) 방식을 사용합니다. 예를 들어, 의존성(dependencies)에 있는 'twilio'는 'twilio'와 일치하지만, README에 있는 'twilio-helpers'와는 일치하지 않습니다. 이를 통해 오탐(false-positive)으로 인한 오버레이 부착률을 1% 미만으로 유지합니다.

그 1%에 대한 고백: v0.1 버전은 퍼지 부분 문자열 매칭 (fuzzy substring matching)을 수행했는데, README에 "우리는 Twilio를 명시적으로 사용하지 않습니다"라고 적힌 정적 사이트 생성기 (static-site-generator) 리포지토리에서 voice-pack이 트리거되었습니다. 왜 블로그 생성기가 TCPA 위협 모델 (threat model)을 받고 있는지 한 시간 동안 고민했습니다. 또한, 키워드 목록에 'phone'을 포함하지 않은 채 2주 동안 voice-pack을 배포했습니다. 두 스타트업이 이를 설치하고 음성 기능을 출시했지만, 해당 팩은 단 한 번도 실행되지 않고 정중하게 그 자리에 머물러 있었습니다. 이제 모든 새로운 팩이 시작하는 보일러플레이트 (boilerplate)에는 다음과 같은 규칙이 있습니다: 가장 명백한 키워드를 마지막이 아닌 가장 먼저 포함할 것. 팩은 가산적으로 쌓입니다. twilio + stripe + livekit → voice-pack + commerce-pack. 만약 두 팩이 동일한 게이트 (gate)의 이름을 지정하면, 커널 (kernel)이 이름별로 중복을 제거 (dedupes)합니다. 리뷰어들은 동일한 PR에서 병렬로 실행되며, 판결은 gate:ship 단계에서 하나의 APPROVED / BLOCKED 칩으로 집계됩니다. 출처: skills/great_cto/packs/ , packages/cli/src/packs.ts . 설치 + 시도: npx great-cto init. 로컬에서 실행됩니다. MIT 라이선스. LLM API 비용은 본인 부담입니다. AGENTS.md + MCP를 통해 Claude Code, Cursor, OpenAI Codex CLI, Aider, 그리고 Continue 내부에서 작동합니다. init 후: /start "식당 주문 접수를 위한 음성 에이전트 추가"를 입력하면, Architect 에이전트가 ARCH 문서를 초안합니다. PM이 이를 beads 태스크로 분해합니다. gate:plan이 귀하의 승인을 기다립니다. 그 후 senior-dev 에이전트들이 태스크를 병렬로 가져가며, 5명의 reviewer 에이전트가 결과물인 diff에 대해 팬아웃 (fan out)합니다. gate:ship이 귀하의 승인을 다시 한번 기다립니다. 기능 하나당 두 번의 클릭이면 충분합니다. 나머지는 무인으로 실행됩니다.

속도를 높여주지 않는 것들
속도 향상 헤드라인보다 더 중요하기에 솔직한 면책 조항을 밝힙니다: 외부 감사 주기 (External audit cycles)는 여전히 자연적인 시간이 소요됩니다 (LL 144 감사관 ~2-4주, FDA 사전 제출 60-90일). IRB 승인은 여전히 2-3개월이 걸립니다. 규제 기관과의 회의는 여전히 일정을 잡아야 합니다. Wet-lab 검증은 여전히 실제 생물학의 영역입니다. HARA 승인은 인간이 소유하는 단일 달력상의 순간입니다. 다른 조직의 시간 투입이 필요한 모든 것은 인간의 속도로 진행됩니다. LLM은 귀하의 코드베이스와 컴플라이언스 (compliance) 탐색을 가속화합니다. 타인의 달력을 가속화하지는 않습니다.

요약 (TL;DR): 기능당 소요 시간이 약 10배 감소합니다 (35일 → 35시간).

MVP의 실제 소요 시간 (wall-clock)이 약 40–50% 감소합니다 (3개월 → 6–8주). 비용은 약 55% 감소합니다. MVP 전체에 걸친 LLM 비용은 $500–$1,500입니다. 무료는 아니며, 아주 저렴한 것도 아닙니다. 인력(Headcount)은 4명에서 2명의 엔지니어 + 에이전트(agents)로 감소합니다. 0명이 되는 것은 아닙니다. 여전히 인간이 필요합니다. 10개의 컴플라이언스 팩 (compliance packs)은 voice-AI, 임상 (clinical), HR-AI, API 플랫폼, 대출 (lending), 임상 시험 (clinical trials), 로보틱스 (robotics), EM 핀테크 (fintech), 기후-MRV (climate-MRV), 신약 개발 (drug discovery)을 다룹니다. 아키텍처 다이어그램 (Architecture diagram): greatcto.systems/architecture . 실제 실행 사례를 단계별로 확인하세요: greatcto.systems/proof . MTTR 벤치마크 방법론 (MTTR benchmark methodology): docs/benchmarks/MTTR.md . 시도해 보세요: npx great-cto init . 유용했다면 ⭐를 남겨주세요: github.com/avelikiy/great_cto . 각 팩별 세부 사항 + 현실적인 MVP 경제성 분석 + 런웨이 (runway) 계산을 포함한 전체 심층 분석은 Hashnode에서 확인할 수 있습니다: Ten compliance packs for ten regulated industries .