How Octave built a secure multi-tenant AI foundation on Amazon Bedrock
Quick Summary
Octave는 Amazon Bedrock 기반의 테넌트 격리·사용자별 실행·콘텐츠 보호 공통 기반을 구축해 Reliance의 AI 활용 사례별 배포 시간을 50% 단축했다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약
Octave는 Amazon Bedrock 기반의 테넌트 격리·사용자별 실행·콘텐츠 보호 공통 기반을 구축해 Reliance의 AI 활용 사례별 배포 시간을 50% 단축했다.
📌 핵심 요약
- Octave는 180개국에서 Global Fortune 500 기업의 60% 이상에 서비스를 제공하며, 원문은 전체 플랫폼 고객을 14,000곳 이상으로 설명한다. 클라우드 기반 품질관리 시스템 Reliance는 650곳 이상의 기업 고객과 40개 이상의 애플리케이션을 지원하며, 고객별 테넌트 사이의 데이터 이동을 금지한다.
- Reliance 팀은 개별 기능보다 공통 AI 기반을 먼저 구축하고 불만 요약·분류를 첫 적용 대상으로 삼았다. 핵심 과제는 테넌트 간 정보 유출 방지, 사용자 권한에 따른 에이전트 격리 실행, 신뢰할 수 없는 콘텐츠 처리, 대규모 문서의 신속하고 정확한 임베딩이었다.
- Cohere Embed v4 on Amazon Bedrock은 텍스트·이미지 통합 검색과 다국어 처리를 지원한다. 고객 데이터의 AWS 리전 외부 이동 금지 조건 아래 세 리전의 리전 내 추론 지원을 활용했으며, 대표 운영 질의에서 512차원이 목표 정확도를 유지하면서 기본 1,536차원 대비 저장 공간을 약 66% 줄였다.
- 보안 기반은 테넌트별 Amazon OpenSearch Service 벡터 저장소, AgentCore의 사용자별 권한과 전용 microVM, Amazon Bedrock Guardrails로 구성된다. 첨부파일 추출문·검색 문서와 도구 출력·최종 요약문을 검사하고, 개인정보 마스킹과 네트워크 외부 통신이 없는 추출 샌드박스를 함께 적용한다.
- Reliance는 20억 건 이상의 문서를 보유하며, 최대 규모 테넌트도 단일 근무일 안에 온보딩하는 것을 목표로 삼았다. 원문 도입부는 20억 건 임베딩 파이프라인과 Complaint Triage Assistant의 운영 적용을 소개한다고 밝히지만, 제공된 본문은 추출 파이프라인 설명 도중 끝나 실제 처리 실적과 후속 운영 결과는 확인할 수 없다.
🧩 주요 포인트
- 공통 AI 기반 선행 구축 → 애플리케이션마다 기반을 다시 만드는 부담을 줄이고, 활용 사례별 배포 시간을 50% 단축.
- 테넌트별 검색 범위와 AgentCore 실행 격리, Amazon Bedrock Guardrails의 결합 → 애플리케이션 코드의 개별 권한 검사에 집중되던 책임을 여러 통제 계층으로 분산.
- Cohere Embed v4의 통합 표현과 512차원 선택 → 검색 파이프라인 복잡성과 저장 부담을 낮춤. 다만 단일 근무일 온보딩 목표의 달성 여부는 제공된 본문만으로 검증 불가.
🧠 상세 정리
1. 규제 산업의 품질 기록과 테넌트 격리 요구
규제 산업의 품질 문제를 해결하는 지식은 과거의 유사 결함 조사, 근본 원인을 해결한 시정 및 예방 조치(CAPA), 같은 취약점을 지적한 감사 결과 등에 축적되어 있다. 그러나 이 기록은 여러 언어와 형식의 방대한 문서에 흩어져 있어 사람이 의미적 유사성을 기준으로 모두 검색하기 어렵고, 그 결과 조사가 처음부터 반복되는 문제가 생긴다. Octave Reliance 팀은 이러한 이력을 활용하는 일을 고객의 업무 속도와 규제 준수를 개선할 가장 큰 기회로 보았지만, 불만 기록과 감사 결과, 시정 조치는 동시에 가장 엄격한 격리가 필요한 데이터였다. 원문은 전체 플랫폼 고객을 의료기기·제약·식품 제조 분야의 14,000곳 이상으로 설명하며, Octave가 180개국에서 Global Fortune 500 기업의 60% 이상에 서비스를 제공한다고 밝힌다. 별도로 Reliance는 650곳 이상의 기업 고객과 40개 이상의 애플리케이션을 지원하며, 고객마다 독립된 테넌트를 구성해 데이터가 그 경계를 넘어가지 않아야 한다.
2. 개별 기능보다 공통 기반을 먼저 구축한 이유
AWS와의 구상 워크숍에서는 불만 요약·분류, 감사 준비 상태 모니터링, 사고 경위 서술 생성, 예측형 품질 위험 점수화라는 네 가지 활용 사례가 도출됐다. 수십 개 애플리케이션이 서로 다른 문서와 업무 흐름을 갖고 있었기 때문에, 한 기능을 독립적으로 만들면 다음 기능에서도 기반을 다시 구축해야 한다는 판단이 공통 플랫폼 우선 전략으로 이어졌다. 팀은 먼저 수평적인 기반을 만들고 그 위에 개별 기능을 추가하기로 했으며, 불만 요약·분류를 첫 검증 대상으로 선택했고 이후 활용 사례별 배포 시간을 50% 단축했다고 설명한다. 설계를 좌우한 네 가지 과제는 테넌트 간 유출 없는 데이터 활용, 요청 사용자 권한에 따른 에이전트 실행, 신뢰할 수 없는 입력의 안전한 처리, 품질을 유지한 대규모 임베딩이었다. 검색과 생성 문맥까지 테넌트에 한정해야 했고, 공유 서비스 계정과 고정 자격 증명 대신 실행 중에만 유효한 사용자별 권한이 필요했으며, 최대 규모 고객도 단일 근무일 안에 온보딩해야 한다는 목표가 함께 적용됐다.
3. Amazon Bedrock 위에 구성한 세 계층
Octave는 여러 모델을 단일 API로 이용할 수 있고, 기존 AWS 계정의 리전 내 데이터 보관 요구와 AWS Identity and Access Management(IAM) 거버넌스를 적용할 수 있다는 점에서 Amazon Bedrock을 선택했다. 기반의 첫 계층인 데이터 준비 단계는 Cohere Embed v4로 품질 문서를 임베딩하고, Amazon OpenSearch Service의 테넌트별 벡터 저장소에 기록한다. 두 번째인 보안 실행 단계에서는 AgentCore Gateway가 사용자 요청의 인증과 정책을 적용한 뒤 격리된 microVM 세션으로 전달하며, 세션은 Amazon Bedrock의 Anthropic Claude 모델을 호출한다. 세 번째인 콘텐츠 보호 계층은 입력과 출력에 Amazon Bedrock Guardrails를 적용해 처리 담당자에게 결과가 전달되기 전까지 내용을 검사한다. 검색·실행·검사를 별도 단계로 유지함으로써 각 통제를 독립적으로 적용하고 근거를 남길 수 있게 했으며, 뒤이어 설명하는 불만 처리 흐름에서는 이 보호를 세 개의 구체적인 검사 지점으로 구현했다.
4. 이미지와 언어의 경계를 줄인 임베딩 선택
문서가 정확하게 검색되지 않으면 이후의 에이전트 기능도 성립하기 어렵기 때문에, 팀은 공개 순위보다 자체 품질 문서 집합을 기준으로 임베딩 모델을 평가했다. 핵심 질문은 균열이 생긴 외장의 사진과 그 결함을 설명하는 문단을 연결할 수 있는지, 독일어 불만 기록과 영어 CAPA를 연관 지을 수 있는지였다. Cohere Embed v4는 텍스트와 이미지를 하나의 벡터 공간에 배치하므로, 결함 사진과 설명문을 단일 질의로 검색할 수 있고 형식마다 별도 파이프라인을 만들 필요가 줄어든다. 기본 다국어 지원은 한 테넌트 안에 여러 언어의 문서가 섞여 있어도 번역 전처리 없이 검색할 수 있게 한다. 원문은 이 두 특성이 서로 다른 형식과 언어를 위한 추가 처리 경로를 없애고, 처리 과정에서 문서가 검색 대상에서 누락될 수 있는 지점도 줄였다는 점을 모델 선택의 중요한 근거로 제시한다.
5. 리전 준수와 차원 축소, 배치 처리의 절충
고객 데이터는 추론을 위해서라도 해당 AWS 리전을 벗어날 수 없었으므로, 리전 내 모델 제공 여부는 선택 편의가 아니라 필수 조건이었다. 원문은 Cohere Embed v4가 미국 동부 버지니아 북부(us-east-1), 유럽 아일랜드(eu-west-1), 아시아 태평양 도쿄(ap-northeast-1)에서 리전 내 추론을 지원해 Octave의 세 지역 규정 준수 요구를 충족한다고 설명하며, 모델과 기능의 가용성은 지역과 시점에 따라 달라진다고 덧붙인다. Amazon OpenSearch Service 비용이 벡터 차원 수에 선형적으로 비례한다는 설명에 따라, 팀은 Embed v4의 설정 가능한 256~1,536차원을 기본값 그대로 사용하지 않고 검증했다. 대표 운영 질의에서는 512차원이 목표 정확도를 유지하면서 기본 1,536차원보다 저장 공간을 약 66% 줄였다. 또한 128K 토큰 문맥 창에 약 4K 토큰 크기의 청크 여러 개를 한 요청으로 묶을 수 있어, 온보딩 처리량을 높이는 데 기여했다고 밝힌다.
6. 애플리케이션 아래에서 강제하는 사용자별 실행 격리
애플리케이션 코드로 테넌트 분리를 구현하면 이후 모든 기능팀이 모든 실행 경로에서 검사를 정확히 수행해야 하므로, 팀은 격리를 AgentCore 런타임으로 옮겼다. 각 사용자 세션은 자체 CPU·메모리·파일시스템을 갖춘 전용 microVM에서 실행되며, 종료 시 인스턴스가 중지되고 메모리가 정리된다. AgentCore는 인증된 사용자 신원을 실행 체인 전체에 전달하고, 사용자별 OAuth 토큰 저장소와 에이전트별·세션 한정 자격 증명을 통해 공유 서비스 신원 대신 해당 사용자를 대신해 작동하도록 한다. AgentCore Gateway는 도구·작업·매개변수 수준에서 권한을 확인하며, 자동 추론은 정의된 규칙에 대한 형식 검증을 제공한다고 원문은 설명한다. 이 구조에서 테넌트 A의 품질 담당자가 제출한 불만은 A의 토큰 저장소·도구·AgentCore Code Interpreter 샌드박스에만 연결되며, 프레임워크와 모델에 독립적인 런타임 격리 덕분에 첫 기능의 구현 선택도 제한하지 않았다는 설명이다.
7. 신뢰할 수 없는 첨부파일을 다층으로 처리
불만 첨부파일은 신뢰할 수 없는 입력이지만 동시에 에이전트가 읽어야 하는 핵심 자료이므로, 의심스러운 내용을 단순히 거부하는 방식으로는 문제를 해결할 수 없었다. 원문은 OWASP의 2025년 LLM 애플리케이션 상위 위험 가운데 프롬프트 주입(LLM01), 민감정보 공개(LLM02), 부적절한 출력 처리(LLM05), 과도한 행위 권한(LLM06)을 직접 관련된 위협으로 든다. Octave는 ApplyGuardrail API로 임베딩 전 첨부파일 추출문, 에이전트 문맥에 들어가기 전 검색 문서와 도구 출력, 담당자에게 보여주기 전 최종 요약문을 검사하며, 첨부파일 유래 내용은 지시가 아닌 데이터로 태깅하고 입력 단계에서 개인정보(PII)를 마스킹한다. 탐지만으로 충분하지 않기 때문에 AgentCore Gateway가 호출 가능한 도구를 계속 제한하고, 문서 추출은 네트워크 외부 통신이 없고 세션 이후 데이터가 남지 않는 AgentCore Code Interpreter 샌드박스에서 수행한다. 탐지율과 마스킹률은 테넌트별로 추적해 실제 검사 결과를 증거로 제시할 수 있도록 했지만, 제공된 본문에는 구체적인 비율이나 공격 차단 성능 수치는 없다.
8. 20억 건 문서 처리의 과제와 제공 본문의 범위
Reliance에는 20억 건 이상의 문서가 있으며, 개별 테넌트도 수백만 개의 Word 파일, PDF, 스캔 양식, 스프레드시트, 이미지, 이메일을 보관할 수 있다고 원문은 설명한다. 임베딩 모델에 도달하기 전부터 이 자료에서 활용 가능한 내용을 추출해야 하고, 하나의 기록 안에 여러 언어가 포함되는 경우도 처리해야 한다. 팀은 가장 큰 테넌트도 단일 근무일 안에 온보딩한다는 목표를 세웠지만, 문서가 규제 관련 판단에 쓰이므로 처리량을 높이기 위해 품질을 희생할 수 없었으며 불만 기록 누락은 시스템 전체에 대한 신뢰를 훼손한다고 보았다. 도입부는 20억 건을 임베딩한 파이프라인과 운영 환경에서 기반을 입증한 Complaint Triage Assistant를 소개한다고 예고한다. 다만 제공된 본문은 추출 대상 형식과 속도 요구를 설명하는 도중 문장이 끊겨, 구체적인 추출 방식, 전체 처리 시간, 단일 근무일 목표 달성 여부, 해당 Assistant의 후속 운영 성과까지 확인할 수는 없다.
🧾 핵심 주장 / 시사점
- 공통 기반을 먼저 구축한 선택은 보안 통제와 데이터 준비를 여러 기능에서 재사용하는 전략이며, 원문은 그 효과를 활용 사례별 배포 시간 50% 단축으로 제시한다.
- 테넌트 격리는 벡터 저장소만의 문제가 아니라 검색 범위, 사용자 신원, 실행 환경, 도구 권한, 생성 문맥 전체에 걸친 요구로 다뤄진다.
- 512차원의 비용 절감은 대표 운영 질의에서 목표 정확도를 유지했다는 검증에 근거한다. 이를 모든 문서·질의에 대한 보편적 성능 보장이나 전체 온보딩 목표 달성의 증거로 확대할 수는 없다.
✅ 액션 아이템
- 테넌트별 Amazon OpenSearch Service 벡터 저장소, AgentCore 사용자별 권한, Amazon Bedrock Guardrails의 적용 범위를 함께 검토.
- Cohere Embed v4의 512차원 선택에 따른 목표 정확도 유지와 약 66% 저장 공간 절감의 적용 조건을 검증.
- 단일 근무일 온보딩 목표의 달성 여부와 Complaint Triage Assistant의 실제 운영 결과를 추가 확인.
❓ 열린 질문
- 활용 사례별 배포 시간 50% 단축은 어떤 비교 기준과 적용 범위에서 측정됐는가?
- 512차원이 유지한 목표 정확도는 어떤 기준이며, 대표 운영 질의의 범위는 어디까지인가?
- 최대 규모 테넌트의 단일 근무일 온보딩 목표는 실제로 달성됐으며, Complaint Triage Assistant의 운영 성과는 어떠했는가?