How OneAdvanced deployed over 50 AI agents on UK-sovereign AWS

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OneAdvanced는 영국 밖으로 데이터를 내보내지 않는 조건 아래 Llama 4 Maverick와 Llama Guard 4를 직접 호스팅하고, RAG와 Strands Agents SDK를 결합해 3주 만에 50개 이상의 전문 AI 에이전트를 구축했다.

📌 핵심 요약

• 10,000곳 이상의 고객을 지원하는 OneAdvanced는 의료·법률 등 규제 산업의 데이터 주권 요구에 따라 사용자 데이터가 영국을 벗어나지 않는 AI 서비스를 구축했다.
• 원하는 Llama 4 Maverick와 Llama Guard 4가 당시 영국 리전의 관리형 서비스에서 제공되지 않아, 런던 리전의 Amazon SageMaker AI와 p5.48xlarge 인스턴스에 vLLM으로 두 모델을 직접 배포했다.
• 시스템은 Amazon ECS의 Strands Agents SDK 기반 에이전트, Amazon DynamoDB의 런타임 설정, Amazon S3·Amazon Aurora PostgreSQL·pgvector 기반 RAG, 공유 도구 계층으로 구성됐다.
• OneAdvanced는 120K~128K 토큰의 긴 문맥을 지원하기 위해 p4d.24xlarge에서 p5.48xlarge로 이전했으며, 높은 오탐 거부율을 보인 Llama Guard 3를 Llama Guard 4로 교체해 주 모델 추론 전에 입력을 검사했다.
• OneAdvanced는 3주 만에 50개 이상의 에이전트를 배포했고 대부분을 하루 이내에 만들었으며, 2,048토큰 청킹과 출처 표시, 개인·조직 문서 공간 격리, 데이터 미보존·학습 미사용 정책으로 투명성과 통제를 강화했다.

🧩 주요 포인트

1. 호스팅 제약 → 영국 리전에 원하는 모델이 없자 자체 호스팅으로 데이터 위치와 모델 제공 계층을 직접 통제하는 대신 배포·확장·콘텐츠 조정까지 운영 범위에 포함했다.
2. 에이전트 확장 → Strands Agents SDK의 모델 중심 구조와 시스템 프롬프트·도구·선택형 입력 폼 구성을 활용해 3주 만에 50개 이상의 업무별 에이전트로 확장했다.
3. 검색과 신뢰 → Amazon S3·pgvector 기반 RAG의 2,048토큰 청킹과 출처 표시를 데이터 격리·사전 유해성 검사와 결합해 문서 기반 답변의 투명성과 규제 산업의 신뢰 요구를 지원했다.

🧠 상세 정리

1. 데이터 주권과 모델 가용성 문제

OneAdvanced는 의료, 법률 및 기타 규제 산업에 특화된 SaaS를 제공하며 10,000곳 이상의 고객을 지원한다. 이 고객들이 다루는 환자 기록, 법률 사건 파일, 규정 준수 문서는 민감도가 높아 데이터가 어디에 있고 누가 접근하며 어느 법률 체계 아래 보관되는지가 중요한 요구사항이었다. 초기 2주간의 Amazon Bedrock 시제품에서는 채팅 완성, 영국 성문법 조회 에이전트, Snowflake 연동, 차트 생성까지 빠르게 구현했다. 그러나 원하는 Llama 4 Maverick와 Llama Guard 4가 당시 영국 리전의 관리형 서비스에서 제공되지 않았기 때문에, OneAdvanced는 자사 영국 기반 AWS 계정 안에서 모델을 직접 배포·제공·확장하고 콘텐츠 조정, 문서 검색, 에이전트 조율, 비개발자용 제작 기능까지 운영하는 경로를 택했다.

2. 영국 주권형 시스템의 전체 구조

핵심 추론 계층은 런던 리전의 Amazon SageMaker AI에서 vLLM으로 제공되는 Llama 4 Maverick FP8과 Llama Guard 4이며, p5.48xlarge 인스턴스를 사용한다. 50개가 넘는 Strands 에이전트는 Amazon ECS에서 실행되고, 각 에이전트의 시스템 프롬프트와 도구 구성 및 선택형 입력 폼에 관한 런타임 설정은 Amazon DynamoDB에 저장된다. 사용자가 올린 문서는 Amazon S3에 저장된 뒤 마크다운으로 변환되고 분할·임베딩되어 Amazon Aurora PostgreSQL 호환 데이터베이스의 pgvector 검색에 활용된다. 요청이 들어오면 Llama Guard 4가 먼저 유해성을 검사하고, 적절한 에이전트가 도구를 호출하거나 pgvector와 Amazon S3에서 관련 문서를 검색하며 필요할 경우 조직별·질의별로 허용된 웹 검색 같은 전문 도구를 사용한다.

3. 긴 문맥을 위한 모델 배포

OneAdvanced는 meta-llama/Llama-4-Maverick-17B-128E-Instruct-FP8과 meta-llama/Llama-Guard-4-12B를 AWS Deep Learning Containers 및 vLLM과 함께 Amazon SageMaker AI 엔드포인트에 배포했다. 대형 문서 분석과 여러 차례 이어지는 대화를 위해 목표 문맥 길이를 120K~128K 토큰으로 설정했고, 이 요구가 P5 인스턴스로 이전한 주요 배경이었다. AWS 자문 과정에서 P5와 vLLM을 대상으로 부하 시험을 수행해 처리량 요구를 감당할 수 있음을 확인했으며, 초기 p4d.24xlarge 구성에서 생산 환경의 p5.48xlarge 구성으로 전환하고 GPU 예약 인스턴스 할인도 활용했다. 기존 Llama Guard 3에서는 높은 오탐 거부율이 관찰되어 Llama Guard 4로 교체했으며, 보호 모델은 주 모델보다 먼저 직렬로 실행된다. 이러한 자체 호스팅에는 대상 리전의 p5.48xlarge 할당량, Hugging Face 모델 라이선스 승인, Python 기반 ML 및 컨테이너 운영 경험, pgvector가 활성화된 PostgreSQL이 전제된다.

4. 50개 이상 전문 에이전트의 확장

에이전트 카탈로그는 의료, 법률, 인사, 마케팅, 물류 등 여러 분야를 대상으로 하며 Care Incident Response, Clinical Safety Bulletin 생성기, 교육용 학습 계획 생성기, 운영 시나리오 시뮬레이션, 성과 검토 지원, 문서 비교, AWS Architect Agent 등을 포함한다. OneAdvanced는 첫 에이전트에서 50개 이상으로 확장하는 데 3주가 걸렸고, 대부분의 에이전트를 하루 이내에 만들었다. LangChain과 LangGraph를 비롯한 여러 프레임워크를 평가한 뒤, 엄격한 워크플로 정의보다 모델 중심 접근을 사용하고 순차 대화와 인터뷰형 상호작용을 지원한다는 이유로 Strands Agents SDK를 선택했다. 각 에이전트는 시스템 프롬프트, 사용할 도구 집합, 선택적인 구조화 입력 폼으로 정의된 뒤 컨테이너화되어 Amazon ECS에 배포된다. 사용자는 카탈로그에서 자신의 작업에 맞는 에이전트를 선택하므로 하나의 범용 대화창이 아니라 구체적인 업무 목적에 맞춘 구성을 이용하게 된다.

5. 비개발자 제작 기능과 공유 도구

OneAdvanced는 제품 관리자, 임상의, 비즈니스 분석가 같은 비개발자도 코드를 작성하지 않고 에이전트를 만들 수 있도록 시각적 비코드 제작기를 구축했다. 사용자는 에이전트의 역할을 정하고 드래그앤드롭 필드로 입력 폼을 설계하며, @ 문법으로 폼 값을 참조하는 시스템 프롬프트를 작성하고 허용할 도구를 고른다. 공유 도구 모음에는 계산기, 차트 생성, 파일 내용 읽기, Mermaid 다이어그램 생성, 개인·조직 지식 검색, Snowflake를 포함한 스프레드시트 질의, 텍스트 파일 질의, 영국 성문법 검색, 선택형 웹 검색이 포함된다. 따라서 하나의 상호작용 안에서 Snowflake 데이터베이스를 조회한 뒤 그 결과로 차트를 만드는 것과 같은 연속 작업이 가능하다. 또한 하위 에이전트와 문맥 유지 패턴을 사용하며, Strategic Thinking 지원처럼 세 개의 구조화된 질문을 차례로 던지는 인터뷰형 에이전트로 사용자가 처음부터 모든 정보를 제공하지 않아도 필요한 맥락을 축적한다.

6. 개인·조직 지식을 연결하는 RAG

RAG 시스템은 사용자가 파일 관리 화면을 통해 Amazon S3의 개인 공간 또는 조직 공유 공간에 올린 문서를 에이전트가 검색할 수 있게 한다. 문서는 마크다운으로 변환된 뒤 2,048토큰 단위로 분할되며, 이 크기를 넘는 긴 내용에는 재귀적 요약이 적용된다. 임베딩에는 다국어 지원과 지시 이행 능력을 고려해 intfloat/multilingual-e5-large-instruct 모델을 사용하고, 벡터 유사도 검색은 pgvector가 담당한다. OneAdvanced는 기성 RAG 프레임워크 대신 내부적으로 Llamadex라고 부르는 검색 시스템을 직접 구축해 파이프라인을 통제했으며, 빠른 생산 전환과 단순성을 이유로 pgvector를 먼저 채택한 뒤 대안도 검토하고 있다. 에이전트는 Personal knowledge search 또는 Organization knowledge search 도구를 호출해 관련 문서 조각과 출처 정보를 반환하며, 사용자는 답변 생성에 실제로 사용된 문서를 확인할 수 있다.

7. 보안·개인정보 보호와 AI 거버넌스

전체 인프라는 런던 AWS 리전에서 실행되며 사용자 데이터는 영국 밖으로 나가지 않는다. 사용자 질의와 응답은 보존되거나 모델 학습에 사용되지 않고, 개인 및 조직 공간에 올린 문서는 서로 완전히 격리되며 OneAdvanced 직원도 읽을 수 없도록 구성됐다. Llama Guard 4는 주 추론 모델에 요청이 도달하기 전에 입력의 유해성을 검사하고, 개인정보 보호 설정은 조직 수준에서 조정할 수 있다. 인프라 측에서는 Amazon GuardDuty가 Amazon S3 문서 저장 계층의 위협 탐지를 담당한다. OneAdvanced는 AI 거버넌스에 관한 ISO 42001 인증을 보유하고 있으며 자사 설명에 따르면 영국과 유럽에서 이를 이른 시기에 취득한 조직 중 하나이고, EU AI Pact에도 서명했다.

8. 구축 성과와 운영 범위

AWS 자문을 거치며 OneAdvanced는 영국 주권 요건을 반영한 시제품에서 생산 시스템으로 전환했고, 모델 제공 인프라에 대한 통제를 유지하면서 50개 이상의 에이전트를 배포했다. 첫 에이전트 이후 3주 만에 에이전트 수를 50개 이상으로 늘리고 대부분을 하루 이내에 제작한 결과는 시스템 프롬프트, 도구, 선택형 입력 폼을 조합하는 배포 방식과 비코드 제작 기능의 속도를 보여준다. 동시에 120K~128K 토큰 문맥, 사전 유해성 검사, 개인·조직 검색, 출처 표시, 데이터 격리 같은 요소를 생산 구조 안에 함께 배치했다. 이 사례에서 자체 호스팅은 모델 파일을 실행하는 작업에 그치지 않고 GPU 용량 확보, 모델 제공과 확장, 검색 파이프라인, 콘텐츠 조정, 도구 실행, 에이전트 설정 관리까지 포함하는 운영 선택이었다. 결과적으로 OneAdvanced는 원하는 모델의 영국 관리형 제공이 없다는 제약 아래에서도 데이터의 영국 내 잔류와 전문 에이전트의 빠른 배포를 함께 구현했다.

🧾 핵심 주장 / 시사점

• OneAdvanced 사례에서는 모델 선호보다 영국 데이터 주권이 호스팅 방식을 결정했으며, 관리형 서비스의 지역별 모델 가용성 부족을 자체 호스팅으로 보완하는 대신 운영 책임이 확대됐다.
• Strands Agents SDK의 모델 중심 구조, 공유 도구, 구성형 입력 폼, 비코드 제작 방식은 전문 에이전트를 개별 개발하기보다 공통 실행 기반에서 빠르게 늘리는 구조로 작동했다.
• Amazon S3·pgvector 기반 검색의 출처 표시를 문서 공간 격리와 Llama Guard 4의 사전 검사에 결합함으로써 답변 근거의 투명성, 개인정보 보호, AI 거버넌스를 하나의 요청 흐름 안에서 다뤘다.

✅ 액션 아이템

• Llama 4 Maverick와 Llama Guard 4의 영국 리전 자체 호스팅 조건 및 p5.48xlarge·120K~128K 토큰 운용 근거 재확인.
• Strands Agents SDK 기반 50개 이상 에이전트의 시스템 프롬프트·도구·선택형 입력 폼 구성 검토.
• Amazon S3·pgvector 기반 RAG의 2,048토큰 청킹, 출처 표시, 개인·조직 공간 격리 조건 점검.

❓ 열린 질문

• Llama 4 Maverick와 Llama Guard 4의 영국 리전 자체 호스팅이 데이터 주권을 충족한 핵심 조건은 무엇인가?
• Strands Agents SDK와 공유 도구 계층은 3주 만에 50개 이상 에이전트를 확장하는 데 어떻게 기여했는가?
• Amazon S3·pgvector 기반 RAG에서 2,048토큰 청킹과 출처 표시는 검색 결과의 투명성을 어떻게 높였는가?