How DXC Technology built a multi-model AI substrate on Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

DXC Technology는 Amazon Bedrock의 다중 모델·보안 기반과 자체 에이전트 실행·통제 계층을 결합해, DXC OASIS에서 업무별 모델 선택과 운영 행위에 대한 권한 통제를 분리했다.

📌 핵심 요약

• DXC OASIS는 Amazon Bedrock의 일관된 API를 통해 Anthropic Claude, Amazon Nova, Meta Llama 및 오픈웨이트 모델 계열에 접근하며, 모델 접근 기반과 DXC 자체의 오케스트레이션·거버넌스·검증 계층을 분리한다.
• DXC는 2025년 초 시제품 개발을 시작해 2026년 3월 정식 출시했으며, 측정한 56개 사용 사례에서 해결 시간이 평균 95% 단축됐다고 밝혔다. Amazon EKS의 테넌트별 네임스페이스와 GitOps 배포를 활용해 고객 환경 130개를 향한 확장을 추진하고 있다.
• Amazon Bedrock Guardrails는 콘텐츠·금지 주제·개인 식별 정보 필터를 제공하고, AWS PrivateLink와 리전별 추론 통제는 비공개 통신 및 데이터 처리 요건을 지원한다. 고객의 프롬프트와 응답은 AWS 데이터 경계 안에 유지되며, 외부 모델 제공자에게 공유되거나 기반 모델 학습에 사용되지 않는다고 설명한다.
• 모델은 비용·지연 시간·역량에 따라 선택한다. 지능형 프롬프트 라우팅은 동일 모델 계열 안에서 단순한 요청을 저비용 모델로, 복잡한 추론을 더 유능한 모델로 보내며, 모델 교체 전에는 자체 실행·통제 계층이 DXC OASIS 작업군으로 동작 차이를 검증한다.
• DXC 자체 실행·통제 계층은 60년간의 런북과 에스컬레이션 로직, 운영 데이터를 활용한다. 모든 페르소나는 읽기 전용으로 시작하며, 관찰·제안·승인 후 실행·허용 범위 내 실행의 4단계 권한과 정책 검사, 필요한 사람의 승인, 행위별 추적을 담당한다.

🧩 주요 포인트

1. 공통 API로 모델 의존성을 낮춤 → 제공자 장애나 모델 지원 종료를 라우팅 변경으로 다룰 수 있지만, 모델별 동작 차이에 대한 검증은 별도로 필요하다.
2. 모델 입출력 필터와 운영 권한 통제를 분리함 → Amazon Bedrock의 보호 장치에 더해 DXC 자체 계층이 실제 도구 사용과 운영 행위의 허용 범위를 제한해야 한다.
3. 측정 성과와 시연 사례는 근거의 성격이 다름 → 56개 사용 사례의 평균 95% 단축 수치와 가상 항공사 AnyCompany Airlines의 시연을 구분해야 하며, 제공된 원문은 장애 해결 흐름의 첫 단계 뒤에서 끊긴다.

🧠 상세 정리

1. 운영 에이전트의 핵심 위험과 기반 통제

글은 은행이나 병원의 운영 서버에서 행동할 수 있는 AI 에이전트에는 유능한 기반 모델만으로 충분하지 않다는 문제 제기에서 출발한다. 운영자의 의도와 다른 파괴적 행동을 한 자율 에이전트의 공개 사례를 언급하며, 핵심 위험을 모델 자체보다 과도한 권한과 이를 막지 못하는 아키텍처에서 찾는다. DXC는 이에 대응하기 위해 인프라 수준에서 모델 접근을 관리하는 기반 계층을 Amazon Bedrock 위에 구축했다. 이 계층은 여러 모델에 대한 관리형 접근과 공통 보호 장치, 비공개 네트워크 경로, 서버리스 확장을 제공한다. 다만 글은 이러한 기반 통제만으로 에이전트의 운영 행위까지 안전해지는 것은 아니며, 실제 작업을 조율하고 권한을 제한하며 감사하는 별도의 실행·통제 계층이 필요하다고 설명한다.

2. DXC OASIS의 두 계층과 개발 성과

DXC Technology는 70개국에서 11만 5,000명 이상의 직원을 두고 은행·병원·정부기관 등 규제가 엄격한 조직의 핵심 IT 시스템을 운영한다. DXC OASIS를 만들면서 팀은 Amazon Bedrock 기반의 관리되는 모델 접근 계층과, 그 위에서 동작하는 DXC 자체의 오케스트레이션·거버넌스·검증 계층으로 문제를 나눴다. 목표는 모델 계층의 단일 장애 지점을 피하고, 비용·지연 시간·역량에 따라 모델을 선택하며, 규제 고객의 데이터 처리 요건과 운영 행위의 안전성을 충족하는 것이었다. 개발은 2025년 초 시제품으로 시작해 여러 기능 조직이 참여한 팀을 거쳐 2026년 3월 정식 출시에 도달했다. 글은 출시 이후 측정한 56개 사용 사례에서 해결 시간이 평균 95% 단축됐다고 밝히지만, 개별 사례별 결과나 구체적인 측정 방식은 제공하지 않는다. 고객 환경 130개를 향한 확장도 설명하고 있으나, 이를 이미 모두 구축한 수치로 제시하지는 않는다.

3. 고객 VPC 안의 실행 환경과 관측 구조

엔지니어와 운영자는 Amazon Route 53 및 고객 Amazon VPC 안의 Application Load Balancer를 거쳐 DXC OASIS에 접근한다. 에이전트 런타임은 프라이빗 서브넷의 Amazon EKS에서 동작하며, 감독 에이전트가 지식 기반과 AWS Secrets Manager, Amazon EventBridge, Amazon S3 등을 활용하는 기능별 에이전트에 작업을 위임한다. 모델 호출은 VPC 인터페이스 엔드포인트와 AWS PrivateLink를 통해 Amazon Bedrock으로 전달되므로 추론 트래픽이 공용 인터넷을 통과하지 않도록 구성된다. 보안과 관측에는 AWS IAM, AWS KMS, TLS 1.2, Amazon CloudWatch, VPC Flow Logs, AWS CloudTrail, OpenTelemetry가 사용된다. 확장 과정에서는 테넌트별 네임스페이스와 GitOps 배포를 적용하며, Amazon EKS 자동 확장을 통해 신규 고객 수용을 용량 계획의 문제로 다루도록 설계했다.

4. 다중 모델 접근과 여러 층의 복원력

DXC OASIS가 사용하는 Anthropic Claude, Amazon Nova, Meta Llama 및 오픈웨이트 모델 계열은 모두 Amazon Bedrock 모델 추론을 통해 호출된다. 따라서 특정 제공자의 장애나 모델 지원 종료에 대응할 때 전체 시스템을 다시 만드는 대신 라우팅을 바꾸는 방식으로 접근할 수 있지만, 공통 API가 모델의 역량·응답 스타일·실패 양상까지 같게 만들지는 않는다. 운영 라우팅에 새 모델을 넣기 전에는 DXC 자체 계층이 작업군을 기준으로 해당 모델의 동작을 검증한다. 복원력은 서버리스 모델 계층과 AWS가 관리하는 Amazon EKS 제어 영역, 공통 Guardrails, 비공개 암호화 통신, 탄력적 용량을 함께 적용하는 방식으로 구성된다. 데이터 주권 측면에서는 리전별 추론 통제와 AWS PrivateLink로 승인된 AWS 리전 안에서 비공개 추론이 이뤄지도록 하며, 고객 프롬프트와 응답은 외부 모델 제공자에게 공유하거나 기반 모델 학습에 사용하지 않는다고 설명한다. 모델 가용성은 AWS 리전마다 다르다는 제약도 명시한다.

5. 업무별 모델 선택과 비용·지연 시간 최적화

DXC가 Amazon Bedrock을 선택한 전략적 이유는 모델 선택권이며, 각 작업의 역량·지연 시간·비용 요구가 사용할 모델을 결정하게 하는 데 초점을 맞춘다. 공통 API를 사용하면 새로운 프런티어 모델이 등장해도 시스템 연결 구조를 다시 구성하지 않고 도입할 수 있다는 설명이다. 지능형 프롬프트 라우팅은 하나의 서버리스 엔드포인트에서 응답 품질을 예측해 동일 모델 계열 안의 모델 사이로 요청을 분배하고, 단순한 프롬프트는 저비용 모델에, 복잡한 추론은 더 유능한 모델에 보낸다. 프롬프트 캐싱은 지연 시간과 비용을 추가로 줄이는 수단으로 제시된다. Custom Model Import를 통해 DXC나 고객이 가져온 모델에도 같은 관리 체계와 도구를 적용할 수 있으며, 독점 모델과 오픈웨이트 모델을 함께 사용해 프런티어 추론과 고객이 조정·배포할 수 있는 모델을 공통 보호 장치 아래 결합한다.

6. 오케스트레이션·맥락·거버넌스의 책임 경계

글은 기업용 에이전트에 필요한 여섯 역량을 제시하고, Amazon Bedrock이 제공하는 기반 기능과 DXC 자체 실행·통제 계층이 추가해야 하는 기능을 구분한다. 오케스트레이션에서 Amazon Bedrock은 호출하거나 확장할 수 있는 기본 서비스 계층을 제공하고, DXC는 오픈소스 LangGraph 런타임을 바탕으로 감독 에이전트와 기능별 에이전트가 도구·시스템·다단계 작업을 수행하도록 조율한다. 맥락 측면에서는 지식 기반 인프라와 프롬프트 캐싱 위에 60년간의 런북, 에스컬레이션 로직, 실시간 IT 서비스 관리 데이터가 더해진다. 거버넌스에서는 AWS IAM, 리전별 추론 통제, 테넌트별 모델 접근 격리가 기반 역할을 맡는다. DXC 자체 계층은 여기에 요청별 정책 집행, 페르소나별 권한 부여, 필드 수준 제약을 추가하므로, 모델을 호출할 수 있는 권한과 실제 업무에서 허용되는 행위의 범위를 별도로 관리한다.

7. 운영 보호 장치·사람의 감독·행위 추적

Amazon Bedrock Guardrails는 콘텐츠 필터, 금지 주제, 개인 식별 정보 필터와 같은 모델 입출력 보호 장치를 제공하지만, 에이전트가 실제로 무엇을 할 수 있는지 제한하는 책임은 DXC 자체 계층에 있다. 이 계층은 계층화된 지식 체계, 범위가 제한되고 감사 가능한 에이전트 역할, 고객별 운영 규칙을 적용해 기반 필터 위에서 운영 정책을 집행한다. 사람의 감독은 기반 계층의 기능으로 보지 않으며, 관찰·제안·승인 후 실행·허용 범위 내 실행이라는 4단계 권한으로 구현한다. 모든 페르소나는 읽기 전용 상태에서 시작하고, 승인 관문과 에스컬레이션 경로를 통해 운영에 영향을 주는 행위를 통제한다. 검증과 추적에서는 기반의 암호화·감사 가능한 인프라·VPC Flow Logs에 더해, 각 행위에 고유 실행 ID를 부여한 OpenTelemetry 추적으로 의도에서 실제 행동까지 연결한다.

8. 가상 항공사 시연과 제공 원문의 범위

구체적인 업무 예시는 온프레미스와 AWS를 함께 사용하는 가상의 중견 항공사 AnyCompany Airlines를 배경으로 한 DXC OASIS 시연 환경에서 나온다. 장애 해결 사례는 위험 상태의 운영 서버를 경보부터 해결까지 10분 이내에 진단·수정하는 작업이며, 문제 관리 사례는 ITSM 에이전트가 상위 5개 장애 범주와 각 범주의 감소 방안을 제안하는 것으로 수작업에는 2~3시간이 걸린다고 설명한다. 클라우드 비용 분석에서는 Metrics 에이전트가 90일 비용 추세를 서비스와 리전별로 나누고, 요청에 따라 지출 급증 원인을 조사한다. 이어지는 장애 해결 흐름의 첫 단계에서는 FlightOps 서버의 디스크 공간을 확보하는 런북이 실패하고, CIO에게는 4시간 이내에 항공 운항 일정에 영향을 줄 수 있는 사업 위험으로 경보가 제시된다. 동시에 Linux 엔지니어에게는 대응에 필요한 기술 세부 정보가 전달되지만, 제공된 원문은 그 뒤의 불완전한 단어에서 끊겨 이후 계획·승인·실행·해결 과정은 확인할 수 없다. 따라서 이 시연의 시간과 작업 예시는 앞서 제시된 56개 사용 사례의 평균 성과와 구분해서 읽어야 한다.

🧾 핵심 주장 / 시사점

• 공통 모델 API는 제공자 교체에 필요한 연결 작업을 줄이지만, 모델의 행동적 호환성까지 보장하지는 않는다. DXC가 모델 교체를 라우팅과 검증의 결합으로 다루는 이유다.
• 에이전트 안전성의 책임 경계는 모델 응답을 필터링하는 지점에서 끝나지 않는다. 실제 운영 도구를 사용할 권한과 승인 조건을 실행·통제 계층에서 제한하는 구조가 핵심이다.
• 평균 95%의 해결 시간 단축은 글이 제시한 측정 성과이지만 사례별 분포와 측정 방식은 확인되지 않는다. 가상 항공사 시연과 중간에 끊긴 업무 흐름도 성과 해석의 범위를 제한한다.

✅ 액션 아이템

• DXC OASIS의 모델 선택에서 비용·지연 시간·역량을 함께 검토하고, 모델 교체 전 작업군을 통한 동작 차이 검증을 적용.
• Amazon Bedrock Guardrails와 DXC 자체 실행·통제 계층의 책임을 구분해, 읽기 전용 시작과 4단계 권한 및 필요한 사람의 승인 조건을 점검.
• 56개 사용 사례의 평균 95% 해결 시간 단축을 평가할 때 AnyCompany Airlines 시연과 측정 근거를 구분하고, 제공된 원문에서 확인 가능한 범위를 명시.

❓ 열린 질문

• 56개 사용 사례에서 해결 시간이 평균 95% 단축됐다는 수치의 측정 기준과 사례별 결과는 무엇인가?
• 동일 모델 계열 안의 지능형 프롬프트 라우팅은 비용·지연 시간·역량 사이의 우선순위를 어떻게 결정하는가?
• 모든 페르소나가 읽기 전용으로 시작한 뒤 4단계 권한 사이를 이동하는 조건과 사람의 승인이 필요한 기준은 무엇인가?