개발자에게 SQL++ 쿼리를 만들어주고, 인덱스를 추천하고, 앞선 대화를 이어가는 AI를 운영하려면 모델 하나만 잘 고르는 것으로는 부족해. Couchbase는 Capella iQ를 여러 모델 제공자와 연결할 수 있는 구조로 바꿨고, 2026년 7월 20일 AWS 공식 블로그에서 그 방식을 공개했어.1
핵심은 모델을 바꿀 때 애플리케이션 코드를 다시 고치지 않는다는 데 있어. Capella iQ의 요청을 받는 서비스와 모델 선택을 담당하는 층을 분리하고, Amazon Bedrock을 공통 호출 창구로 둔 거야. 모델 선택이 코드 변경이 아니라 설정 변경이 되면, 새 모델을 시험하거나 고객별로 다른 모델을 적용하기가 쉬워져.1
요청은 세 개의 서비스와 Bedrock을 지난다
구조는 AWS Control Plane 안에서 두 리전에 걸쳐 돌아가고, 한쪽 리전의 Amazon EKS 클러스터에 Capella iQ 마이크로서비스가 배치돼. cp-api는 개발자의 요청을 받고 추론 호출을 조율해. cp-internal-api는 서비스 사이 통신과 모델 라우팅을 맡고, cp-ns는 모델 제공자 설정과 테넌트별 재정의, 조직 선호도를 관리해.1
흐름을 실제 요청에 대입하면 이래. 사용자가 자연어로 SQL++ 쿼리나 인덱스 추천을 요청하면 cp-api가 인증과 세션 문맥을 확인하고 요청 종류에 맞는 프롬프트를 구성해. 여기에 여러 차례 대화의 기록과 고객별 모델 설정이 들어가고, cp-internal-api가 모델 제공자와 조직 단위 라우팅 규칙을 결정하지.
그다음 요청은 VPC 인터페이스 엔드포인트를 통해 Amazon Bedrock으로 간다. AWS와 Couchbase는 프롬프트와 응답 전체가 AWS 인프라 안에 머물고 공용 인터넷을 지나지 않는다고 설명해. 응답은 같은 사설 경로로 돌아와 cp-api에서 형식이 정리된 뒤 Capella iQ 화면에 전달되고, 대화 상태도 이어서 저장돼.1
여기서 Bedrock의 역할은 모델을 대신 고르는 마법 상자가 아니야. 여러 모델 계열을 하나의 API로 부를 수 있게 해주는 관리형 추론 층에 가까워. Capella iQ가 모델 제공자에 덜 묶이도록 애플리케이션의 공통 경계를 만들어주는 셈이지.
리전 장애를 애플리케이션 밖으로 밀어낸다
Bedrock의 Cross-Region Inference는 미국 지리 범위 안의 us-east-1, us-east-2, us-west-2 가운데 쓸 수 있는 리전으로 요청을 자동 분산한다고 AWS는 적었어. 수요가 갑자기 늘거나 특정 리전의 성능이 나빠질 때 애플리케이션이 직접 장애 조치 로직을 실행하지 않아도 된다는 설명이야.1
이 방식이 주는 운영상 이점은 단순히 리전을 세 개 쓰는 데 있지 않아. 사전에 용량을 모두 확보하지 않고도 갑작스러운 요청 증가에 대응하고, 서비스 코드에 수동 장애 조치 경로를 따로 넣지 않아도 돼. 다만 자동으로 넘겨주는 것과 자동으로 잘 작동하는 것은 다른 문제야.
실제로 가장 어려웠던 작업으로 소개된 것도 장애 조치 시험이었어. 부분적인 엔드포인트 저하와 리전 단위 throttling 같은 실패 상황을 개발 환경에서 재현하기 어려워 별도 시험 장치와 시뮬레이션이 필요했지. 정상 리전으로 요청이 넘어간 뒤에도 응답 품질과 지연 시간이 흔들리지 않는지 확인하고, timeout과 retry 설정을 조정해야 했어.1
모델을 여러 개 쓰는 비용은 평가 체계다
Couchbase는 운영 모델을 고르기 전에 SQL++ 생성, 인덱스 추천, 쿼리 설명, iQ Insights 생성, 여러 차례 대화를 포함한 벤치마크 묶음을 만들었어. 표준화한 프롬프트와 응답 세트로 여러 Bedrock 모델을 비교하면서 기능 정확성, 결정성, 지연 시간, 형식 일관성 네 가지를 봤다고 해.1
그 결과 초기 운영 모델로 선택한 Claude Sonnet 4.5는 BIRD 방법론을 본뜬 내부 평가에서 약 76% 정확도를 기록했고, 모든 작업에서 치명적인 회귀가 없었다고 AWS와 Couchbase는 설명해. 이 숫자는 독립 평가 결과가 아니라 사례 작성자가 말한 내부 평가 결과야. 중요한 점은 76% 자체보다 새 모델을 같은 기준으로 다시 비교할 수 있는 틀을 만들었다는 데 있어.1
비교도 생각보다 단순하지 않았어. 모델마다 토큰화, 문맥 창 처리, 응답 형식이 달라 그대로 점수를 나란히 놓을 수 없었고, 공정한 비교를 위해 결과를 정규화하는 작업이 필요했지. 그래서 다중 모델 운영은 모델 목록을 많이 확보하는 일이 아니라, 프롬프트와 평가 데이터, 관측 체계를 계속 관리하는 일이 돼.
아직 모르는 것
AWS 공식 사례가 확인해주는 건 Capella iQ가 어떤 구조로 Bedrock을 연결했고, Couchbase가 어떤 운영상의 이점을 얻었다고 설명하는지야. 이 글만으로 고객별 실제 모델 사용 비중, 리전 전환이 발생한 횟수, 요청당 비용, 76% 정확도의 세부 분포까지 알 수는 없어.
Couchbase는 앞으로 고빈도·범위가 좁은 인덱스 추천과 쿼리 설명 작업에 더 작은 미세 조정 모델을 배치해 추론 비용을 낮추는 방안을 검토하고 있다고 밝혔어. 그 방향이 실제 비용 절감으로 이어지는지는 모델별 품질, 지연 시간, 장애 조치 뒤의 응답까지 함께 비교해야 확인할 수 있어.1
결국 이 사례에서 다음에 볼 것은 “어떤 모델이 가장 좋은가” 하나가 아니야. 같은 업무를 모델별로 얼마나 재현성 있게 평가하는지, 리전 전환 뒤에도 사용자 경험이 유지되는지, 작업별로 작은 모델을 골랐을 때 비용과 품질의 균형이 남는지가 다중 모델 아키텍처의 실제 범위를 가를 거야.
댓글