Kwangmin Kim - MINERVA Phase C-10 — 바이브 코딩에서 설계 기반 개발로 (전환점과 거버넌스)

1 두 가지 개발 모드

정의: 바이브 코딩 vs 설계 기반 개발

바이브 코딩 (Vibe Coding): 직관·빠른 시도·LLM과의 대화 중심 개발. 작동하는 prototype을 빨리 만든다. - 강점: 발견 속도·실험 부담 ↓ - 약점: 거버넌스·검증·재현성 ↓ — 운영에 그대로 가져가면 사고

설계 기반 개발 (Design-driven Development): 명세·계약·검증·생명주기 중심. - 강점: 안정성·확장성·팀 협업·운영 가능성 - 약점: 초기 마찰 — 작은 변경에도 절차 부담

두 모드가 대립이 아니라 단계의 차이다. 1.5명·prototype 단계에는 바이브 코딩이 옳고, 50명·1000 사용자 단계에서는 설계 기반이 옳다. 핵심은 언제·어떻게 전환할지.

MINERVA 자체가 이 전환의 사례다 — Phase B는 바이브 코딩, Phase C는 그 위에 설계 기반으로 인프라 도입. 본 편은 그 전환 패턴의 일반화.

2 4 전환점

[Phase 0: 발견]            1명 · prototype · 사용자 0~10명
   ↓
[Phase 1: MVP]             1.5~3명 · 첫 사용자 · 50명 미만
   ↓
[Phase 2: 검증]            5~10명 · 50~500명 사용자
   ↓
[Phase 3: 운영]            10~30명 · 500~5000명 사용자
   ↓
[Phase 4: 거버넌스]        30+명 · 5000+ 사용자 · 외부 노출·규제

각 전환점에서 어떤 인프라가 부족하면 망가지는가가 다르다. 사전에 도입해야 할 것이 다른 단계에 도입되면 — 너무 일찍 (over-engineering) 또는 너무 늦게 (incident 발생) 도입.

3 전환점 1 — Discovery → MVP

신호: 한 사용자가 "이거 다른 사람에게 보여줄 만하다"고 말함
필요: 안정적인 BaseAgent contract + 기본 lift·error handling

도입할 것	Phase
BaseAgent v1 (contract)	02-0
기본 RAG 파이프라인	03
FastAPI 서빙	04
기본 React 프론트엔드	05
단순 환경 변수 관리	11-0

이 단계에서 하지 말아야 할 것: - 복잡한 LangGraph (단순 Chain으로 시작) - 다중 에이전트·하네싱 (단일 에이전트로 충분) - A/B·Bandit (사용자 부족 — 실험 의미 X) - 정교한 관측성 (간단한 logging으로 충분)

Anti-pattern: 사용자 5명에 OpenTelemetry·Bandit·Multi-agent 도입 → over-engineering, 발견 속도 ↓.

4 전환점 2 — MVP → 검증

신호: 사용자 50명 — 일부가 "이게 잘못된 답을 줘" 신고 시작
필요: 데이터 수집 + 분석 + 기초 검증 인프라

도입할 것	Phase
대화 로깅 (C20)	structured 계층까지
A/B 실험 운영 (06)	YAML·sticky hash·JSONL
응답 품질 평가 (C22)	thumbs_up + heuristic
의도 분류 (C21)	5~12개 라벨
기본 테스트 (12-0)	unit·snapshot

전환 신호 검출: - 사용자가 같은 종류 issue를 반복 신고 - 어떤 query 카테고리가 약한지 모름 - 새 모델 도입 시 영향 정량화 안 됨

이 신호가 보이면 — 검증 인프라 도입 timing.

5 전환점 3 — 검증 → 운영

신호: 사용자 500명 — 새 부서·새 use case가 동시에 들어옴
필요: 안전·확장성·자동화 인프라

도입할 것	Phase
LangGraph 전환 (C-2 5편)	StateGraph·HITL
Bandit·Contextual (C16)	자동 트래픽 분배
사용자 세그멘테이션·개인화 (C17·C18)	부서별 분기
실험 파이프라인 자동화 (C19)	9단계 + governance
하네싱 + 실행 제어 (C24·C25)	guard·quota·circuit breaker
생명주기 관리 (C26)	6단계 게이트
관측성 (C34)	OpenTelemetry·SLO
비용 최적화 (C35)	tiering·cache
보안 기초 (C36)	RBAC·audit·tenant 격리

전환 신호 검출: - Incident 빈도 ↑ — 한 변경이 다른 곳을 깸 - 비용이 사용자 증가보다 빠르게 증가 - “이 결정이 어디 영향 주나” 추적 불가 - 새 도메인 도입 시 weeks 걸림

이 단계가 가장 큰 인프라 투자 — Phase C-2~C-9 대부분이 여기서 도입.

6 전환점 4 — 운영 → 거버넌스

신호: 사용자 5000명 + 외부 규제·감사·SLA 계약
필요: 조직·governance·DR·compliance 인프라

도입할 것	Phase
스킬 생태계 완성 (C-7 4편)	registry·composition·테스트
지식 기반 관리 완성 (C-8 3편)	lifecycle·청킹·monitoring
보안 깊이 (C36 5계층 + LLM 4 위협)	red team·compliance
조직 분리 (C37)	Platform·Domain·SRE·Governance
운영 인프라 (C38)	SRE 5축·24/7 on-call·DR

전환 신호 검출: - 외부 audit 요구 (SOC 2·GDPR·HIPAA·KISA) - 조직이 작은 팀으로 분리되기 시작 - 24/7 on-call 필요 - governance review 빈도 ↑ - 단일 incident가 여러 도메인 영향

7 전환 신호 일반 패턴

신호 종류별로 어떤 인프라가 답인가:

신호	답 (도입할 인프라)
“이 응답이 왜 이런가” 추적 안 됨	C20 logging·C34 trace
같은 issue가 반복 발생	C22 quality eval·C23 feedback loop
새 변경이 다른 곳 깸	C26 lifecycle·C30 skill testing
비용 증가 비선형	C35 비용 최적화·tiering
사용자 부서별 만족도 다름	C17 segmentation·C18 personalization
Incident 늘고 회복 느림	C25 실행 제어·C38 SRE 절차
보안·권한 누출 의심	C24 하네싱·C36 보안
새 부서 도입 weeks 걸림	C19 실험 자동화·C31 lifecycle
조직 협업 마찰	C37 Team Topologies

신호 → 인프라 매핑이 명확 — 단계별 우선순위 결정.

8 거버넌스 측면

운영 단계 진입 후 모든 변경이 거버넌스를 통과:

변경 분류 ([C19](./26-minerva-experiment-pipeline.qmd)·[C26](./33-minerva-agent-lifecycle.qmd) 패턴)
├── auto_ship          - 저위험 (프롬프트 미세·예시 추가)
├── pending_review     - 중위험 (모델 교체·새 스킬·새 collection)
└── governance_review  - 고위험 (가격·외부 노출·정책·security scope)

거버넌스가 사람 부담으로 인식되지 않게 — 자동 게이트로 작동: - 저위험은 자동 사후 검증 (golden eval·canary) - 중위험은 영업일 1~2일 내 review (정해진 reviewer) - 고위험은 분기 예정 review (PM·법무·security 동석)

각 단계에서 검증 산출물이 명시: - golden eval pass rate - A/A test false positive rate - canary 7일 monitoring 결과 - pairwise comparison vs baseline - security scan·red team 통과

9 Phase A~C-10 통합 매핑

Phase A: 선수지식 (Engineering Tier 1·2·3)
  └── 도입 시점: Phase 0~1 (개발자 onboarding)

Phase B: 구현·배포 (9편)
  └── 도입 시점: Phase 1 MVP (작동하는 prototype)

Phase C-1: 현재 분석 (8편)
  └── 도입 시점: Phase 2 검증 진입 (바이브 결과물 정밀 이해)

Phase C-2: LangGraph 전환 (4편)
  └── 도입 시점: Phase 3 운영 진입 (multi-step·HITL 필요)

Phase C-3: Agentic Mode (4편)
  └── 도입 시점: Phase 3 운영 (자율 도구 선택·delegation)

Phase C-4: 실험과 최적화 (5편)
  └── 도입 시점: Phase 2 검증·Phase 3 운영 (자동 학습)

Phase C-5: 발화 데이터 분석 (4편)
  └── 도입 시점: Phase 3 운영 (피드백 루프)

Phase C-6: 하네싱 시스템 (3편)
  └── 도입 시점: Phase 3 운영 (자율성 ↑ 시 안전)

Phase C-7: 스킬 생태계 (4편)
  └── 도입 시점: Phase 3 후반·Phase 4 거버넌스 (150+ 스킬 운영)

Phase C-8: 지식 기반 관리 (3편)
  └── 도입 시점: Phase 3 운영 (콘텐츠 양·복잡도 ↑)

Phase C-9: 관측성과 비용 (3편)
  └── 도입 시점: Phase 3 운영 (시스템 가시성 필수)

Phase C-10: 플랫폼 스케일링 (3편 — 이 글 포함)
  └── 도입 시점: Phase 4 거버넌스 (조직·SRE·전환 결정)

이 시리즈가 Phase 1~4의 진화 전체를 다룬다. 각 phase에서 다음 단계로 갈 때 어떤 변환이 필요한지의 매뉴얼.

10 안 다룬 영역

본 시리즈가 다루지 않은 — 향후 시리즈 후보:

영역	이유
Multi-modal (image·voice·video)	본 시리즈는 텍스트 중심
Fine-tuning·distillation 깊이	별도 시리즈 (LLMOps)
Edge·on-device 배포	클라우드 중심 운영
Federation·multi-org governance	단일 조직 가정
Real-time collaborative agents	단일 사용자·session 가정
Reinforcement Learning from Human Feedback	model 학습은 외부
Ethics·AI safety 깊이	보안·compliance 부분만
Open-source self-hosted LLM 운영	클라우드 provider 가정

각 영역이 별도 책 분량 — 본 시리즈는 “운영 가능한 LLM Agent 시스템”의 표준 케이스에 집중.

11 회고 — 이 시리즈가 다룬 것

46개 글
35,000+ 줄
22개 세션
3개월 가까운 작업

각 글이 한 가지 작은 결정·패턴·운영 지침. 합쳐서 — 바이브 코딩에서 시작해 1000명 사용자 시스템까지 가는 모든 단계의 결정 매뉴얼.

본 시리즈 첫 글 00 prerequisites에서 자가 진단 표를 제시. 이제 마지막 글에서 그 표가 어떻게 진화했는지 — 모든 영역이 단계별 게이트로 묶여 있다.

12 다음 단계

본 시리즈를 끝낸 독자가 할 수 있는 것:

단계	행동
Phase 0	Phase B 9편을 따라 자기 prototype 구현
Phase 1 (MVP)	Phase C-1 정밀 분석으로 자기 코드 이해
Phase 2 (검증)	Phase C-4·C-5 도입 — 실험·피드백 루프
Phase 3 (운영)	Phase C-2·C-3·C-6·C-9 — multi-agent·하네싱·관측성
Phase 4 (거버넌스)	Phase C-7·C-8·C-10 — 스킬·지식·조직

각 단계에서 본 시리즈를 reference로 — 무엇을 도입해야 하는지·왜 필요한지 답.

13 결론

LLM Agent 시스템은 3년 전과 다르다. 단순한 chatbot이 아니라: - Multi-step plan - 도구 호출·외부 시스템 연동 - 사용자별 개인화·세그먼트 - A/B·Bandit으로 학습 - 보안·compliance·SLA - 24/7 운영·DR

이 모두를 한 번에 도입하면 — over-engineering. 하나도 안 도입하면 — 사용자 늘어날 때 사고. 본 시리즈가 한 가지를 답: 각 단계에서 무엇이 필요한지.

Phase A 선수지식에서 시작해, Phase B에서 작동하는 시스템을 만들고, Phase C-1에서 그 시스템을 정밀 이해하고, Phase C-2~C-3에서 LangGraph·Agentic mode로 진화시키고, Phase C-4~C-9에서 운영 인프라를 도입하고, Phase C-10에서 조직·SRE·거버넌스로 묶는다.

이것이 — 바이브 코딩에서 설계 기반 개발로의 전환 매뉴얼.

14 Phase C 통합 요약

[Phase C-1] 현재 분석    - 바이브 결과물 정밀 이해
[Phase C-2] LangGraph    - Chain → StateGraph
[Phase C-3] Agentic Mode  - 정적 → 자율
[Phase C-4] 실험·최적화   - 통계·Bandit·자동화
[Phase C-5] 발화 분석     - 데이터 → 인사이트 → 처치
[Phase C-6] 하네싱 시스템 - 자율의 안전 경계
[Phase C-7] 스킬 생태계   - 150+ 스킬의 표준 단위
[Phase C-8] 지식 관리     - 문서·인덱스 lifecycle
[Phase C-9] 관측성·비용   - 시스템 가시성·통제
[Phase C-10] 플랫폼 스케일링 - 조직·SRE·거버넌스 (이 글 포함)

Phase C 전체가 — “운영 가능한 LLM Agent 시스템을 만들고 유지하는 방법”.

15 정리

영역	핵심
두 모드	바이브 코딩(빠름·검증 X) vs 설계 기반(안정·확장)
4 전환점	Discovery·MVP·검증·운영·거버넌스
전환 신호	추적 안 됨·반복 issue·비용 ↑·보안 누출·조직 마찰
거버넌스	auto_ship·pending_review·governance_review (변경 위험 분류)
Phase 매핑	Phase A~C-10이 단계별 인프라 카탈로그
안 다룬 영역	Multi-modal·LLMOps·Edge·Federation 등 별도 시리즈
결론	각 단계에서 필요한 만큼만 도입 — over X·under X

16 응용 분야

시나리오	본 글 활용
자기 시스템 단계 진단	4 전환점 + 전환 신호 매트릭스
다음 도입 인프라 결정	Phase 매핑 + 단계별 우선순위
거버넌스 정책 수립	변경 분류 + 게이트
새 팀원 onboarding	시리즈 전체를 phase별로 권장
회사 내 다른 프로젝트	Phase 1~4 매뉴얼로 적용

17 관련 주제

시리즈 전체 cross-link

00 Phase A 선수지식 — 시작점
01 아키텍처 개요 — Phase B 진입
02-0 BaseAgent v1·2-1 v2 — contract 토대
13 LangGraph 기초 — Phase C-2 진입
18 Tool Binding — Phase C-3 진입
22 A/B 심화 — Phase C-4 진입
27 대화 로깅 — Phase C-5 진입
31 하네싱 — Phase C-6 진입
34 스킬 정의 — Phase C-7 진입
38 지식 lifecycle — Phase C-8 진입
41 관측성 — Phase C-9 진입
44 조직 설계 — Phase C-10 진입

Phase C-10 직접 결합

C37 개발 조직 설계 — Conway’s Law·4팀
C38 운영 인프라 — SRE 5축

Engineering Tier 1·2·3 (선수지식)

Engineering 카테고리 — 13편 통합
신규 개발자가 본 시리즈를 따라가기 위한 기초

18-LangGraph 시리즈 cross-reference (이론적 배경)

33편의 Agent 이론·아키텍처·프롬프트 패턴
본 시리즈가 그 이론을 MINERVA에 적용한 사례

다음 시리즈 후보 (안 다룬 영역)

Multi-modal Agent (image·voice 통합)
LLMOps (fine-tuning·distillation·evaluation 깊이)
Self-hosted LLM 운영
Federation·multi-org governance