AI 에이전트 Build vs Buy: 무엇을 만들고 무엇을 살 것인가
AI 에이전트의 Build vs Buy는 “모델을 직접 만들까, API를 살까”라는 질문으로 축소되기 쉽습니다. 하지만 기업이 실제로 소유해야 하는 것은 모델만이 아닙니다. 업무 규칙, 데이터, 권한, 평가셋, 사용자 경험과 공급자를 바꿀 수 있는 출구가 더 오래 남습니다.
좋은 결정은 이분법이 아닙니다. 차별화해야 할 업무 논리는 직접 소유하고, 표준 기능은 구매하며, 데이터·권한·평가·교체 가능성은 어느 선택에서도 통제하는 포트폴리오 결정입니다.
네 가지 선택지를 먼저 구분한다
| 유형 | 설명 | 속도 | 통제·유연성 | 적합한 경우 |
|---|---|---|---|---|
| 완제품 SaaS | 공급자가 UI·워크플로·모델·운영을 제공 | 가장 빠름 | 낮음~중간 | 표준화된 지원·생산성 업무 |
| 로우코드·관리형 에이전트 | 공급자 플랫폼 위에 업무와 연동을 구성 | 빠름 | 중간 | 빠른 통합과 일부 맞춤 필요 |
| 관리형 모델/API + 자체 앱 | 모델·인프라는 구매하고 UX·업무·평가는 자체 구축 | 중간 | 중간~높음 | 업무 논리·데이터가 차별화 |
| 자체 스택 | 모델·서빙·오케스트레이션까지 직접 운영 | 느림 | 가장 높음 | 규모·규정·핵심 IP가 비용을 정당화 |
대부분은 하나만 고르지 않습니다. 범용 기능은 사고 차별화 영역을 만들게 됩니다.
100점 의사결정표
각 기준을 1점, 구매 신호에서 5점, 구축 신호로 평가합니다. 가중치는 대화를 시작하기 위한 INLEVEL9 시작안입니다.
| 기준 | 가중치 | 1점: Buy 신호 | 3점: Hybrid | 5점: Build 신호 |
|---|---|---|---|---|
| 전략적 차별화 | 20 | 범용 백오피스 | 경험 일부 차별화 | 제품·운영의 핵심 IP |
| 워크플로 특수성 | 15 | 업계 표준 절차 | 일부 승인·예외 | 복잡한 독자 규칙·상태 |
| 통합 깊이 | 10 | 표준 커넥터 | 몇 개 내부 API | 레거시·실시간·다중 시스템 |
| 데이터·규제 통제 | 15 | 일반 데이터·표준 약관 허용 | 지역·보존 조건 | 고민감·주권·감사 요구 |
| 평가·운영 역량 | 10 | 전담 인력 없음 | 파트너와 공동 | 내부 eval·SRE·보안 역량 |
| 출시 속도 | 10 | 즉시 필요 | 분기 내 | 장기 투자 가능 |
| 3년 TCO·규모 | 10 | 소규모·가변 수요 | 손익분기 불명 | 대규모 안정 수요·단위경제 우위 |
| 교체·종속성 | 10 | 종속 허용 | 데이터 이식 필요 | 공급자 종속이 전략 위험 |
해석 시작점
- 0~39점: Buy 우선. 공급자 실사와 데이터 출구 계획을 강화합니다.
- 40~69점: Hybrid 우선. 업무 논리·데이터·평가는 소유하고 모델·인프라는 구매합니다.
- 70~100점: Build 검토. 인력, 평가와 24시간 운영비를 실제로 확보했을 때만 진행합니다.
이 구간은 규격이 아닙니다. 고위험 규정이나 필수 데이터 이동 제한은 총점과 별도 게이트입니다.
숨은 비용을 같은 표에 넣는다
| 비용·책임 | Buy에서 놓치기 쉬운 것 | Build에서 놓치기 쉬운 것 |
|---|---|---|
| 초기 | 연동·마이그레이션·보안 심사 | 데이터·평가셋·플랫폼 구축 |
| 반복 | 좌석·사용량·성과 과금, 가격 변경 | 추론·저장·관측·당직·인력 유지 |
| 품질 | 공급자 지표와 우리 과업의 차이 | 회귀 평가·모델 교체·드리프트 |
| 위험 | 하위처리자·국외이전·약관 변경 | 패치·취약점·사고 대응 책임 |
| 종료 | 데이터·로그·프롬프트 반출 | 기술 부채·핵심 인력 의존 |
3년 TCO에는 라이선스와 개발비만 들어가지 않습니다.
TCO = 라이선스·추론 + 구축·연동 + 데이터 준비 + 평가·모니터링 + 보안·준법 + 사람 검토 + 장애·복구 + 변경·교육 + 종료·이전 비용
구매 전에 물어야 할 12가지
- 고객 데이터가 모델 학습에 사용되는가? 기본값은 무엇인가?
- 데이터 저장 위치, 보존, 삭제와 이전 조건은 무엇인가?
- 하위처리자나 모델 공급자가 바뀌면 어떻게 통지하는가?
- 역할·최소권한·SSO·SCIM·감사 로그를 지원하는가?
- 도구 실행 전 승인과 금액·대상 한도를 설정할 수 있는가?
- 고객 평가셋으로 버전별 회귀 시험을 할 수 있는가?
- SLA, 지원 시간과 사고 통지 시한은 무엇인가?
- 모델·가격·기능을 공급자가 일방 변경할 수 있는가?
- 사용량·비용·성공률·사람 개입을 어떤 단위로 내보내는가?
- 데이터, 메모리, 로그와 프롬프트를 표준 형식으로 반출할 수 있는가?
- 계약 종료 뒤 삭제 증거와 업무 연속성 계획이 있는가?
- 필요한 인증이 실제 서비스 범위에 포함되는가?
영국 정부의 AI 조달 지침도 AI를 처음부터 만들거나, 완제품으로 사거나, 기존 시스템에 추가할 수 있다고 봅니다. 중요한 것은 조달 전 데이터 평가, 다학제 의사결정과 계약 이후의 지속 관리입니다.
Build를 선택할 때의 최소 조건
- 제품·업무 소유자와 12개월 이상 예산이 있다.
- 실제 업무 평가셋과 grader를 만들 수 있다.
- 보안·권한·관측·사고대응 운영자가 있다.
- 모델·도구가 바뀌어도 업무 계약과 평가를 유지하는 추상화가 있다.
- 구축으로 얻는 차별화 또는 장기 단위경제를 수치로 설명할 수 있다.
Anthropic의 Building Effective Agents는 가장 단순한 해법에서 시작하고 필요한 경우에만 복잡성을 늘릴 것을 권합니다. Build가 반드시 다중 에이전트나 자체 모델을 뜻하지는 않습니다.
세 가지 설명용 결론
- 사내 회의 요약: 완제품 Buy. 데이터·보존·접근 통제를 엄격히 실사합니다.
- 산업별 고객지원: 관리형 모델/API + 자체 지식·평가·승인. Hybrid가 기본입니다.
- 제품 핵심 자동화 엔진: 업무 오케스트레이션은 Build하고 모델은 교체 가능한 다중 공급자 API로 둡니다.
결론은 “무조건 직접 만들자”도 “검증된 SaaS를 사자”도 아닙니다. 모델보다 업무 논리·데이터·평가·출구를 소유하세요.