클라우드의 숨겨진 비용

5장 — 클라우드의 숨겨진 비용

지난 5년간 지배적인 이야기는 클라우드가 경제적이고 확장 가능하며 간단하다는 것입니다. 많은 워크로드에 대해서는 완벽하게 사실입니다. 하지만 엔터프라이즈 RAG의 경우 점점 더 그렇지 않습니다. 그리고 이를 깨닫는 시점은 보통 1분기 말, 청구서가 도착할 때입니다.

비용 계산에서 가장 간과되는 부분을 살펴봅시다. 바로 비전 모델 API입니다. 회사가 최신 RAG에 사진 아카이브를 통합할 때, 각 사진은 콘텐츠, 객체, 컨텍스트, 오버레이된 텍스트, 분위기, 구성을 추출하는 멀티모달 모델에 의해 “설명”되어야 합니다. 2025년, 유럽의 주요 모델 제공업체(아직 이름은 밝히지 않음)는 320억 개의 파라미터를 가진 Qwen 계열의 우수한 모델을 매력적인 이미지당 가격으로 제공했습니다. 문제는 실제 사용 환경에서 수개월의 프로덕션 후에야 발견되었는데, 제공업체가 부하가 걸리면 응답을 잘라냈다는 것입니다. 항상 그런 것은 아니었고, 예측 가능하지도 않았으며, 테스트 팀 앞에서 발생하지도 않았습니다. 무작위로 발생했습니다. 사진 10장 중 1장, 때로는 5장 중 1장은 절반만 잘린 JSON, 잘못 파싱된 메타데이터, 부분적이거나 널(null)인 메타데이터와 함께 반환되었습니다. 처리 시간은 이미지당 10초에서 200초로 급증했으며, 패턴이 없었습니다. 재시도 비용(재시도는 서버가 잘라낸 호출을 포함하여 모든 호출에 대해 비용이 청구됨)은 예상보다 높았습니다. 데이터베이스는 불균일했습니다. 메타데이터가 풍부한 사진도 있었고, 잘린 사진도 있었습니다. 그리고 팀은 테스트 환경에서 문제를 재현할 수 없었습니다. 테스트 환경에서는 부하가 낮아 모든 것이 정상적으로 작동했기 때문입니다.

해결책은 세 가지 부분으로 이루어졌습니다. 더 간결한 프롬프트(짧은 응답은 잘릴 가능성이 적음), 지능형 재시도 로직(응답에 50초 이상 걸리고 비어 있으면 즉시 재시도) 그리고 — 볼륨이 정당화되는 경우 — 클라우드를 완전히 건너뛰고 로컬 GPU에서 비전 모델을 실행하는 기능(느리지만 결정적)입니다. 이 경험을 통해 올바른 아키텍처는 "항상 클라우드"도 아니고 "항상 로컬"도 아닙니다. "각 호출 시 필요한 것에 따라 선택"하는 것입니다.

그리고 쿼리 챕터가 있습니다. 클래식 클라우드 네이티브 RAG의 모든 사용자 검색은 유료 API 호출의 폭포를 촉발합니다. 질문 임베딩을 위한 것 하나, 의도 분류(질문 유형은 무엇입니까?)를 위한 것 하나, 문서 재정렬을 위한 것 하나, 최종 응답 생성을 위한 것 하나입니다. 각각은 센트의 일부 비용이 듭니다. 50명의 사용자 및 하루 10,000개의 쿼리가 있는 내부 서비스(그렇게 많지도 않지만 중간 규모의 회사에는 엄청난 숫자는 아님)의 월별 비용은 관대한 CFO조차도 찡그릴 수 있는 수치에 도달합니다. 그리고 성장은 선형적입니다. 사용자를 두 배로 늘리면 비용도 두 배로 늘어납니다. 소비되는 토큰에 대한 규모의 경제는 없습니다. 당신에게는 없습니다.

2025년에는 잠재적인 문제였지만 2026년에는 핵심적인 문제가 된 부분이 있습니다. 모든 개별 쿼리는 때로는 기밀이거나, NDA의 적용을 받거나, 산업별 규제를 받는 기업 문서 조각을 외부 공급업체의 서버로 전송합니다. 이러한 서버의 관할 구역은 귀사의 관할 구역과 일치하지 않을 수 있으며, 로그 보존 정책이 항상 명확하지 않을 수 있습니다. 지난 18개월 동안 유럽의 많은 기업들이 감사(보통 우려하는 고객이나 ISO 인증에 의해 유발됨)를 통해 자사의 계약서, 가격표, 기술 사양이 EU 외부 인프라에서 처리(그리고 잠재적으로 "서비스 개선" 목적으로 기록됨)되었다는 사실을 발견했습니다. 이러한 놀라움은 현지 하드웨어 절약을 통해 피하려고 했던 비용보다 더 큰 비용을 초래하는 경우가 많습니다.

대안은 정반대되는 독단이 아닙니다. “클라우드 거부, 로컬 우선”은 “항상 클라우드”만큼이나 틀렸습니다. 대안은 파이프라인의 각 부분(임베딩, 분류, 재정렬, 비전, 최종 생성)에 대해 클라우드 모델을 사용할지 로컬 모델을 사용할지 선택하고, 1분기(3개월)가 아닌 하루 만에 생각을 바꿀 수 있는 아키텍처입니다. 이는 공급업체를 교체할 수 있도록 설계되어 특정 회사의 이름에 어떤 부분도 고정되지 않고 Regolo에서 Ollama(또는 그 반대)로의 전환이 코드 재작성 대신 구성 한 줄로 이루어지는 설계를 의미합니다. 그리고 이것은 얼마 전까지만 해도 드물었습니다. 인기 있는 프레임워크는 “공급업체 독립적”이라는 허울에도 불구하고 실제로는 특정 업체와 깊이 결합되어 있었습니다.