$47,000의 실수: 계약 체결 전 Fractional CTO가 감사해야 할 사항

AIdeazz에 처음 게시되었습니다 — 정식 링크와 함께 이곳에 교차 게시되었습니다.

$47,000. 이것은 제가 18개월 전에 내린 단일 벤더(single vendor) 결정으로부터 벗어나기 위해 지불해야 할 비용입니다. 계약은 아직 14개월이 더 남아 있습니다. API 지원 종료(API deprecation) 통지는 지난 화요일에 도착했습니다.

VC(Venture Capital) 자금 지원 없이 AI 시스템을 구축할 때, 모든 벤더 선택은 생존을 위한 결정입니다. 저는 제 손익계산서(P&L)를 괴롭히는 세 가지 결정을 내렸습니다. 에이전트 트래픽의 40%를 가로막는 하나의 API 계약, 컴퓨팅 비용을 세 배로 늘린 하나의 데이터베이스 아키텍처(database architecture), 그리고 서명한 지 6개월 만에 Oracle에 의해 구식이 되어버린 하나의 인프라(infrastructure) 베팅입니다.

다음은 Fractional CTO가 무엇인가에 서명하기 전에 AI 벤더 락인(vendor lock-in) 감사를 통해 잡아내야 할 사항들입니다.

API 감옥: 트래픽의 40%가 단일 제공자를 통해 흐를 때

저희의 WhatsApp 에이전트들은 제가 이름을 밝히지 않을 한 제공자를 통해 라우팅됩니다. 저희가 시작했을 당시 파나마에서 저희의 특정 유스케이스(use case)를 지원하는 유일한 옵션이었습니다. 계약 조건은 다음과 같습니다: 월 최소 $2,800, 24개월 약정, 90일 전 통지 시 자동 갱신.

락인은 세 단계로 발생했습니다:

1~3개월 차: 그들의 웹훅(webhook) 구조를 중심으로 라우팅 로직을 구축함
4~6개월 차: 그들의 커스텀 세션 관리(표준 WABA가 아님)를 통합함
7개월 차 이후: 대화 상태(conversation state)를 그들의 포맷으로 저장함

이제 그들은 v2 API를 지원 종료(deprecating)하고 있습니다. 마이그레이션(Migration)을 하려면 전체 세션 레이어(session layer)를 다시 작성해야 합니다. 더 큰 문제는, 그들의 새로운 가격 정책이 저희의 사용량 기준으로 3.4배 더 높다는 것입니다.

감사 시 확인해야 할 사항:

모든 저장된 데이터에 대한 내보내기(Export) 기능 (저희는 기능이 없습니다)
API 버전 관리(versioning) 약속 (그들은 12개월을 약속했지만, 8개월 만에 이행했습니다)
호환 가능한 인터페이스를 가진 대체 제공자 (두 곳이 있었지만, 저는 문서화하지 않았습니다)
전체 재작성 비용 vs 남은 계약 의무

중요한 계산식: 마이그레이션 비용($47K) + 남은 계약 금액($33.6K) + 새 제공자 설정 비용($12K) = 저희의 런웨이(runway)에서 $92.6K의 구멍이 생김.

데이터베이스 아키텍처: 숨겨진 컴퓨팅 승수

저는 이미 OCI(Oracle Cloud Infrastructure)를 사용 중이었기 때문에 Oracle Autonomous Database를 선택했습니다. 서류상으로는 합리적이었습니다. 통합 백업, 자동 스케일링 (automatic scaling), ML 최적화 인덱스 (ML-optimized indexes) 등이 갖춰져 있었으니까요. 경쟁사보다 비용이 30% 더 저렴할 것이라는 약속도 있었습니다.

규모가 커졌을 때의 현실:

기본 컴퓨팅 (Base compute): 월 $1,200 (예상대로)
에이전트 급증 시 자동 스케일링 (Auto-scaling): +월 $800 (모델링되지 않음)
ML 인덱스 최적화 (ML index optimization): +월 $450 (이 티어에 대해서는 언급이 없었음)
Telegram 에이전트를 위한 교차 리전 복제 (Cross-region replication): +월 $600

총합: 월 $3,050 vs 예산 월 $1,200. 이는 연간 $22,200의 계획되지 않은 비용입니다.

아키텍처 종속성 (Architectural lock-in)은 비용보다 더 심각합니다. 우리의 에이전트 상태 관리 (agent state management)는 Oracle 전용 JSON 함수를 사용합니다. 쿼리 최적화 도구 (query optimizer)는 그들의 ML 인덱스에 의존합니다. Postgres로 이전하려면 데이터 레이어 (data layer)의 60%를 다시 작성해야 합니다.

우리를 구해줄 수 있었던 감사 체크포인트 (Audit checkpoints):

샘플 데이터가 아닌 실제 워크로드 (workload) 비용을 벤치마킹할 것
운영 환경과 유사한 급증 상황에서 자동 스케일링 트리거를 테스트할 것
모든 "자동" 기능의 가격을 개별적으로 산출할 것
코드베이스 내의 Oracle 전용 함수 개수를 셀 것 (우리는 847개가 있었습니다)

인프라 베팅: 제공업체가 방향을 틀 때

우리는 에이전트 배포를 위해 OCI의 컨테이너 인스턴스 (container instances)로 표준화했습니다. 6개월 후, Oracle은 모든 사용자를 Kubernetes로 유도하겠다고 발표했습니다. 컨테이너 인스턴스가 폐기(deprecated)된 것은 아니지만, 명백히 방치되었습니다. 새로운 기능은 없고, 지원 티켓(support tickets) 처리 시간은 5배 더 오래 걸립니다.

구체적인 고통:

컨테이너 인스턴스 배포: 45초
Kubernetes 배포: 4~7분
우리의 SLA는 60초 미만의 에이전트 업데이트를 요구함
Kubernetes 마이그레이션은 CI/CD 파이프라인 전체를 다시 작성해야 함을 의미함

이것은 컨테이너 인스턴스에서 절약하는 월 $400의 문제가 아닙니다. 기능을 출시하면서 인프라를 마이그레이션하는 데 드는 3~4주간의 엔지니어링 시간의 문제입니다.

당신의 Fractional CTO는 다음 사항을 감사해야 합니다:

제공업체의 로드맵 (Roadmap)과 귀사 아키텍처 (Architecture) 간의 정렬 여부
마지막 주요 기능 업데이트 이후 경과 시간 (12개월 이상 경과 시 위험 신호)
해당 특정 서비스에 대한 기술 지원 응답 시간
서비스가 정체될 경우를 대비한 마이그레이션 경로 (Migration paths)

아무도 말하지 않는 멀티 클라우드(Multi-Cloud)의 함정

"멀티 클라우드를 사용하여 락인 (Lock-in)을 방지하세요."라고들 말합니다. 그래서 우리는 다음과 같이 실행했습니다:

컴퓨팅 및 데이터베이스는 Oracle
S3 호환 스토리지는 AWS
CDN 및 Workers는 Cloudflare
Groq/Claude는 서로 다른 제공업체 이용

결과: 4개의 벤더 (Vendor) 관계, 4개의 결제 주기, 4세트의 IAM 규칙, 그리고 4배의 운영 복잡성.

숨겨진 비용:

클라우드 간 데이터 전송 (Cross-cloud data transfer): 월 $1,100 (아무도 데이터 송출 수수료 (Egress fees)에 대해 말하지 않습니다)
IAM 동기화 도구: 월 $350
클라우드 통합 모니터링: 월 $500
클라우드 특정 이슈 해결을 위한 엔지니어링 시간: 전체의 20%

멀티 클라우드는 락인을 방지하지 못했습니다. 오히려 네 가지 종류의 서로 다른 락인을 만들어냈을 뿐입니다.

락인 감사 체크리스트 (Lock-In Audit Checklist)

방지할 수 있었던 락인으로 인해 $92.6K를 허비한 후, 제가 현재 사용하고 있는 Fractional CTO용 AI 벤더 락인 감사 프레임워크는 다음과 같습니다:

계약 포렌식 (Contract forensics):

최소 약정량 (Minimum commit) 대비 실제 사용량 예측치
6개월, 12개월, 18개월 시점의 해지 비용
자동 갱신 조건 및 통지 기간
가격 인상 상한선 (또는 상한선 부재 여부)

기술적 의존성 (Technical dependencies):

벤더 특정 함수/API (Vendor-specific functions/APIs)의 개수
데이터 내보내기 (Data export) 형식 및 제한 사항
마이그레이션 도구 (Migration tooling) 가용성
호환 가능한 대체 제공업체

숨겨진 승수 (Hidden multipliers):

오토스케일링 (Auto-scaling) 비용 곡선
서비스 간 데이터 전송 수수료
규모 확장 시 요구되는 지원 등급 (Support tier)
유료 애드온 (Add-ons)으로 변하는 기능 플래그 (Feature flags)

전략적 정렬 (Strategic alignment):

귀사의 유스케이스 (Use case)에 대한 제공업체의 투자 여부
귀사의 아키텍처와 로드맵의 일치 여부
해당 업체가 최적화하고 있는 고객 규모
최근의 기능 폐지 (Deprecation) 이력

Oracle에 대한 현실 점검

우리는 Oracle Cloud를 깊게 사용하고 있으므로, OCI 사용자들을 위한 구체적인 락인 감사 항목은 다음과 같습니다:

Autonomous Database JSON 함수 (JSON functions): 개수를 세어보세요. 함수 하나당 2~3시간의 마이그레이션(migration) 작업이 필요합니다.
OCI CLI 의존성 (OCI CLI dependencies): 우리의 배포 스크립트에는 50개 이상의 OCI 전용 명령어가 포함되어 있습니다. 이는 다시 작성하는 데 2주가 소요됨을 의미합니다.
ID 및 액세스 관리 (Identity and Access Management, IAM): Oracle의 컴파트먼트(compartment) 구조는 AWS나 Azure와 깔끔하게 매핑되지 않습니다. IAM 마이그레이션에만 최소 1주의 예산을 잡으세요.
모니터링 및 메트릭 (Monitoring and metrics): OCI 메트릭(metrics)을 표준 도구에서 사용하려면 커스텀 익스포터(custom exporters)가 필요합니다. 우리는 Prometheus 통합만을 위해 1,200줄의 Python 코드를 작성했습니다.

전략적 락인 (Strategic Lock-In)과 타협하기

어떤 락인은 전략적입니다. 우리는 추론(inference)을 위해 Groq에 락인되어 있지만, Claude의 100만 토큰당 $3.00와 비교했을 때 $0.10인 Groq라면 기꺼이 받아들일 수 있는 락인입니다. 핵심은 당신이 어떤 의존성을 선택하고 있는지, 그리고 그 이유가 무엇인지 아는 것입니다.

우리의 전략적 락인:

대량 추론을 위한 Groq (10배의 비용 이점)
복잡한 쿼리를 위한 Oracle 데이터베이스 (ML 인덱스가 컴퓨팅 자원의 30%를 절감)
Telegram Bot API (현실적인 대안이 없음)

우리의 우발적 락인:

WhatsApp 제공업체 (인터페이스를 추상화했어야 함)
컨테이너 인스턴스 (Kubernetes로 시작했어야 함)
멀티 클라우드 복잡성 (하나를 선택하고 전념했어야 함)

차이점은 이렇습니다: 전략적 락인은 명확한 ROI(투자 대비 수익)를 제공하지만, 우발적 락인은 그저 비용만 발생시킵니다.

다음 감사 (The Next Audit)

나는 매 분기 감사를 다시 실시합니다. 하루가 걸리지만, 수만 달러를 아껴줍니다.

현재의 위험 신호 (Red flags):

우리의 Redis 배포가 AWS 전용 기능을 사용하고 있음
Cloudflare Workers 구문이 핵심 로직에 스며들고 있음
새로운 Oracle "AI 서비스"가 매력적으로 보이지만 락인의 냄새가 남

47,000달러의 실수가 내게 가르쳐준 것은 이것입니다: 벤더 락인을 감사해야 할 시점은 Fractional CTO를 찾고 있을 때가 아닙니다. 벤더 전용 코드를 첫 줄 작성하기 전이어야 합니다.

하지만 이미 운영 중인 프로덕션 시스템을 두고 이 글을 읽고 계신가요? 오늘 바로 감사를 시작하십시오. 기다리는 매달마다 마이그레이션 비용이 5~10%씩 추가됩니다.

그것은 추측이 아닙니다. 제가 그 WhatsApp 계약서를 볼 때마다 수치가 말해주는 사실입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 벤더 종속적 (vendor-locked) AI 시스템의 실제 마이그레이션 비용 공식은 무엇인가요?
A: (벤더 전용 코드 라인 수 × $50) + (데이터 보유 개월 수 × $1,000) + (계약 해지 수수료) + (2주간의 엔지니어링 시간 × 번 레이트 (burn rate)). 저희의 경우, 이는 지속적으로 월간 벤더 비용의 15~20배에 달합니다.

Q: Fractional CTO는 아키텍처 (architecture) 결정 전과 후 중 언제 락인 (lock-in) 감사를 수행해야 하나요?
A: 결정 과정 중에 해야 합니다. 방향을 바꿀 수 있는 시점에 상위 3개 후보군을 대상으로 감사를 실시하십시오. 결정 후의 감사는 문제를 발견할 뿐이지만, 결정 전의 감사는 문제를 예방합니다. 4시간의 감사 투자가 400시간의 마이그레이션 시간을 아껴줍니다.

Q: AI 워크로드 (workloads)에서 전략적 락인 (strategic lock-in)과 우발적 락인 (accidental lock-in)을 어떻게 수치화하나요?
A: 전략적 락인은 비교 가능한 대안이 없는 상태에서 3배 이상의 명확한 이점(비용, 성능 또는 기능)을 가집니다. 우발적 락인은 이점이 1.5배 미만이거나