전체 사례No. 037
KTern.AI 12~18개월짜리 SAP 전환을 설정만으로 배포하는 에이전트 20여 개에 나눠 맡기다
- 사례 번호
- 037
- 1차 출처
- AWS Machine Learning Blog (KTern.AI·AWS 공동 작성)
- 원문 게시
- 2026-07-10
1. 왜 이 사례인가
원문은 SAP 전환을 기업이 맞닥뜨리는 가장 복잡하고 위험 부담이 큰 과제 가운데 하나로 꼽습니다. SAP 전환 프로젝트는 탐색, 설계, 테스트, 전환(cutover)을 거치며 12~18개월 동안 이어집니다. 업무 프로세스와 커스텀 코드가 복잡하게 얽혀 있는 데다, 사람 컨설턴트만으로는 단기간에 확충하기 어려운 도메인 전문성이 필요하기 때문입니다.
KTern.AI는 SAP 인증을 받은 DXaaS(Digital Transformation as a Service) 플랫폼으로, SAP S/4HANA 마이그레이션과 시스템 전환을 돕습니다. 이 회사는 기존 SaaS 플랫폼을 에이전트 플랫폼으로 개편하면서, 전환 단계별 작업을 각각 전담하는 전문 에이전트 20여 개를 Amazon Bedrock AgentCore 위에 올렸습니다. 원문은 이 에이전트들이 SAP 프로젝트 전체 기간을 평균 45%, 탐색·평가 기간을 60~70% 줄였다고 밝힙니다.
이 사례를 고른 이유는 뛰어난 성과 수치보다 구체적인 운영 방식에 있습니다. KTern.AI는 에이전트를 하나씩 코드로 개발하지 않고, 프롬프트·도구 연결·오케스트레이션 패턴으로 구성된 설정(configuration)만으로 배포합니다. 새 에이전트를 만드는 데 걸리던 시간도 2~3주에서 4~6시간으로 줄었습니다. 몇 달씩 이어지는 프로젝트에서 에이전트가 맥락을 잃지 않도록 돕는 메모리 설계, 고객사마다 다른 규칙을 코드 수정 없이 반영하는 멀티테넌트 구성도 함께 다룹니다. 도메인 소프트웨어 기업이 에이전트 인프라를 직접 구축하지 않고 어디까지 관리형 서비스에 맡길 수 있는지 보여 주는 사례입니다.
2. Problem
KTern.AI의 플랫폼이 발전할수록, 단순한 일문일답 형태의 AI 기능만으로는 자율적인 SAP 전환을 이끌기에 한계가 드러났습니다. 에이전트가 몇 달, 길게는 몇 년에 걸친 프로젝트 전체를 시야에 넣고 추론해야 했고, 여러 업무 영역을 동시에 조율하면서도 엄격한 기업 보안과 컴플라이언스 기준을 지켜야 했기 때문입니다. 원문은 맞물려 있던 과제를 다섯 가지로 정리합니다.
- 대규모 지속 맥락: 에이전트는 수백 번 이어지는 상호작용 속에서 상태를 유지하고, 과거 결정을 참조하며 프로젝트 전 기간에 걸친 맥락을 축적해야 했습니다. 하지만 맥락을 지나치게 많이 주입하면 응답이 느려지고 비용이 늘어나며 환각 위험도 커집니다. 따라서 핵심 목표는 무조건 많은 맥락이 아니라 적절한 맥락을 선별하는 것이었습니다.
- 안전하고 통제된 도구 연결: SAP API, 고객사 ERP 시스템, 프로세스 저장소, KTern.AI 데이터 저장소에 실시간으로 접근하려면, 기업 보안팀의 기준을 충족하는 인증 체계와 감사 가능한 연결 방식이 필수적이었습니다.
- 멀티테넌시와 설정 기반 유연성: 고객사는 저마다 독립된 테넌트로 운영되며, 프로세스와 예외 처리 방식, 비즈니스 규칙도 제각각입니다. 배포할 때마다 엔지니어가 맞춤형 코드를 작성하지 않고도 에이전트를 테넌트별 환경에 맞춰 유연하게 설정할 수 있어야 했습니다.
- 동적 확장: 가벼운 SAP 평가 작업에는 에이전트 몇 개를 몇 시간 동안만 쓰지만, 전사 마이그레이션 프로젝트에서는 에이전트 수십 개가 몇 달 동안 쉬지 않고 돌아갑니다.
- 프로덕션 수준의 관측성: 상세한 로그, 트레이스, 지표 없이 멀티 에이전트 워크플로를 디버깅하는 일은 기업 환경에서 불가능합니다. 에이전트의 모든 판단과 도구 호출 경로를 빠짐없이 추적할 수 있어야 했습니다.
AgentCore를 도입하기 전 KTern.AI는 자체 구축한 컨테이너 스택에서 애플리케이션을 운영했습니다. 원문은 이 방식이 작동은 했으나, 핵심 경쟁력인 “SAP 전환을 이해하는 에이전트 설계”와 무관한 기반 인프라 관리에 엔지니어링 역량을 낭비하게 만들었다고 설명합니다. 에이전트를 하나 추가할 때마다 오케스트레이션, 메모리, 도구 접근, 인증, 모니터링 인프라를 일일이 따로 구축해야 했고, 에이전트당 최소 2~3주가 걸렸습니다.
확인된 사실: SAP 전환 프로젝트 12~18개월, 지속 맥락·도구 연결·멀티테넌시·동적 확장·관측성의 다섯 가지 과제, 자체 운영 컨테이너 스택, 에이전트당 최소 2~3주 개발 기간.
3. Solution
3.1 도메인은 KTern.AI가, 인프라는 AgentCore가
KTern.AI는 Strands Agents SDK로 에이전트를 만들고 Amazon Bedrock AgentCore 위에서 운영합니다. 설계의 핵심 원칙은 관심사의 분리입니다. SAP 도메인 지식은 KTern.AI 계층에 집중하고, 호스팅, 확장, 메모리, 도구 접근, 인증, 관측성과 같은 인프라 영역은 전부 AgentCore에 맡겼습니다. 모델은 Amazon Bedrock을 통해 Anthropic Claude 계열 모델 등을 사용합니다.
모든 에이전트는 커스텀 오케스트레이션 코드 없이 설정으로 배포합니다. 에이전트의 동작 방식은 프롬프트, 도구 연결(tool binding), 오케스트레이션 패턴으로 정의됩니다. 오케스트레이션 패턴은 작업 성격에 맞춰 Strands의 멀티 에이전트 패턴 세 가지를 나누어 씁니다. 병렬 탐색에는 스웜(swarm), 순차 진행 작업에는 워크플로(workflow), 조건부 파이프라인에는 그래프(graph)를 적용합니다.
3.2 아키텍처
기업 사용자가 KTern.AI 플랫폼에 전환 요청을 전달하면, 이 요청은 에이전트 오케스트레이션 계층으로 들어갑니다. 전문 에이전트들은 AgentCore 런타임 위에서 세션별로 완벽히 격리된 상태로 실행되므로, 다른 고객사의 맥락에 접근하는 일이 원천 차단됩니다. 원문이 밝힌 AgentCore 주요 구성 요소별 역할은 다음과 같습니다.
| 구성 요소 | KTern.AI에서의 역할 |
|---|---|
| Runtime | 컴퓨팅 자원 할당, 확장, 동시 운영 고객 환경 간의 세션 격리 담당. 멀티테넌트 격리를 자체 설계·구현·감사할 필요를 없앰 |
| Memory | 커스텀 코드 목록, 프로세스 결정 사항, 예외 패턴 같은 프로젝트 맥락을 세션이 바뀌어도 유지 |
| Gateway (MCP) | SAP 환경, 고객사 ERP API, 프로세스 마이닝 데이터, 분석 저장소를 설정 등록만으로 도구화 |
| Identity | 에이전트별 최소 권한 적용, 도구 호출 전 과정의 감사 기록 생성, 고객사 기존 인증 체계와의 연동 |
| Observability | 로그·지표·트레이스를 Amazon CloudWatch(OpenTelemetry)로 전송. 최초 요청부터 개별 판단, 도구 호출, 최종 응답까지 전 과정 추적 |
| Evaluations | KTern.AI 고유의 SAP 테스트 케이스를 바탕으로 설정이 바뀔 때마다 품질 평가 수행 |
에이전트는 AWS PrivateLink 기반 VPC 인터페이스 엔드포인트를 통해 Amazon Bedrock과 AgentCore에 접근하므로, 트래픽이 공용 인터넷을 거치지 않습니다. 주변 보조 시스템으로는 Amazon S3, AWS Lambda, AWS IAM을 활용합니다.
3.3 전환 단계를 나눠 맡는 에이전트 네트워크
KTern.AI는 20개가 넘는 전문 에이전트를 프로덕션 환경에서 운영하며, 고객 시나리오별로 50개가 넘는 에이전트 설정을 관리합니다. 에이전트는 저마다 SAP 전환 과정의 특정 영역을 책임집니다. 원문이 소개하는 핵심 에이전트는 다음과 같습니다.
- 리버스 엔지니어링 에이전트: 기존 SAP 환경에서 커스텀 ABAP 코드, 사용자 출구(user exit), 개선(enhancement), 설정, 프로세스 변형을 스캔하여 현재 시스템 상태 목록을 구축합니다. 이 결과물은 후속 에이전트들이 마이그레이션 영향도와 현대화 경로를 판단하는 공통 기준 자료가 됩니다.
- 포워드 엔지니어링 에이전트: 파악된 현재 상태를 토대로 클린 코어(표준 기능은 디지털 코어에 두고 확장은 외부로 분리하는 원칙)에 부합하는 목표 아키텍처, 표준 연동 패턴, 마이그레이션 코드를 작성하며, 유지·리팩터링·폐기 대상 항목을 권고합니다. 리버스 엔지니어링 에이전트와 맞물려 “리버스에서 포워드로 이어지는” 연속 파이프라인을 구성합니다.
- Fit-to-standard 에이전트: 비즈니스 프로세스를 SAP 표준 프로세스와 대조하여 커스터마이징으로 갈라지는 지점을 찾아내고 대체 방안을 제안합니다. 과거 기능 컨설턴트가 수백 개 프로세스를 수작업으로 검토하던 업무입니다.
- 커스텀 코드 분석 에이전트: 커스텀 ABAP 코드 전반을 마이그레이션 호환성, 사용 중단(deprecated) API 활용 여부, 성능 위험, 현대화 가능성 측면에서 평가하고, 객체별 복잡도를 분류하여 우선순위에 따른 조치 방안을 제시합니다.
- 테스트 케이스 생성 에이전트: 비즈니스 프로세스 흐름, 커스텀 코드 분석 결과, 시스템 설정 데이터를 바탕으로 테스트 데이터, 기대 결과, 검증 기준이 포함된 실행 가능한 테스트 케이스를 생성합니다.
- 프로세스 마이닝 에이전트: 구매-지급(P2P), 주문-수금(O2C), 기록-보고(R2R) 등의 SAP 이벤트 로그를 분석하여, 설계된 프로세스와 실제 운영 환경 간의 차이, 병목 구간, 재작업 루프, 자동화 기회를 도출합니다.
- 예외 마이닝 에이전트: 미대사 송장, 보류된 구매 주문, 미결 대변 메모, 청구 예외처럼 주로 사후에 발견되던 재무·영업 부문의 운영 예외를 FI, CO, SD, MM 모듈 전반에서 사전에 찾아 분류합니다. Gateway를 통해 고객사 시스템의 재무·영업 데이터에 직접 접근합니다.
3.4 프롬프트 관리와 평가
원문은 프롬프트를 중앙에서 통합 관리하여 전체 에이전트 배포에 걸쳐 버전 관리, 롤백, 일관된 거버넌스를 적용한다고 설명합니다. 에이전트 설정, 오케스트레이션 패턴, 적용 모델 역시 설정 기반으로 유연하게 테스트하며 배포 부담 없이 개선을 이어갑니다. 특히 결과물의 정확도가 가동(go-live) 위험과 직결되는 테스트 케이스 생성 에이전트의 경우, 별도의 자체 평가 도구를 구축하는 대신 AgentCore Evaluations를 활용해 설정이 바뀔 때마다 평가를 수행합니다. 원문은 이 방식을 통해 기반 모델 업데이트 등으로 일어나는 동작 변화를 조기에 감지한다고 설명합니다.
확인된 사실: Strands Agents SDK + Amazon Bedrock AgentCore, 도메인·인프라 관심사 분리, 프롬프트·도구 연결·오케스트레이션 패턴으로 구성된 설정 기반 배포, 스웜·워크플로·그래프 패턴, AgentCore 6개 구성 요소의 역할, PrivateLink VPC 엔드포인트, Claude 계열 모델, 20개 이상의 프로덕션 에이전트와 50개 이상의 설정, 7개 핵심 에이전트의 역할, 중앙 프롬프트 관리(버전 관리·롤백), 설정 변경마다 실행하는 평가.
4. Impact
원문은 다음 수치가 KTern.AI가 프로덕션 SAP 전환 프로젝트 전반에서 내부적으로 측정한 값이라고 명시합니다. 외부 감사를 거친 수치는 아니며, AWS 블로그에 KTern.AI와 AWS 담당자가 공동으로 기고한 내용입니다.
| 영역 | 지표 | 수치 |
|---|---|---|
| SAP 전환 | SAP 프로젝트 전체 기간 | 평균 45% 단축 |
| SAP 전환 | 탐색·평가 기간 | 60~70% 단축 |
| SAP 전환 | 분석 단계의 SME·컨설턴트 의존도 | 최대 60% 감소 |
| SAP 전환 | 자동 생성 테스트 케이스의 1회 실행 성공률 | 82% |
| SAP 전환 | 재무·영업 모듈 운영 예외 중 자율 식별 비율 | 90% |
| SAP 전환 | 가동 이후 지원 요청(incident) | 40% 감소 |
| 개발 속도 | 첫 프로덕션 에이전트 배포 | 4~6시간 (이전 최소 2~3주, 개발 주기 85% 단축) |
| 개발 속도 | 인프라 구축 시간 | 95% 단축 |
| 운영 | 에이전트 가동률 | 99.8% |
| 운영 | 인프라 비용 | 이전 자체 운영 컨테이너 스택 대비 70% 절감 |
| 운영 | 회수한 엔지니어링 시간 | 월 480시간 (엔지니어 3명분) |
원문은 과거 탐색·평가 단계가 초기 프로젝트 예산에서 가장 큰 몫을 차지했다고 설명합니다. 시스템 가동 후 지원 요청이 40% 줄어든 주요 원인으로는 커스텀 코드 분석 에이전트가 잠재 위험을 초기에 식별해 낸 점을 꼽습니다. 절감한 월 480시간의 엔지니어링 리소스는 에이전트 고도화와 신규 기능 개발에 전량 재투자했습니다. 새 에이전트는 설정 배포를 거쳐 당일 바로 프로덕션 환경에 적용됩니다.
품질 측면에서는 표준화된 에이전트 기반 프로세스를 도입하면서, 투입되는 컨설턴트 팀의 역량에 따른 프로젝트별 품질 편차가 줄었다고 설명합니다. 관측성 측면에서는 기존에 여러 시스템의 로그를 수작업으로 대조하던 디버깅 작업이 몇 분 단위로 단축되었으며, 이러한 환경이 99.8% 가동률을 안정적으로 뒷받침한다고 밝힙니다.
한편 원문 초반에 등장하는 “7배 빠른 전환, 전체 작업량 24% 감소”라는 수치는 축적된 전환 패턴 지식 엔진과 하이퍼오토메이션을 아우르는 KTern.AI 플랫폼 전체를 가리키는 설명이며, 본문에서 다룬 에이전트 도입 성과와는 구별되는 별개의 수치입니다.
현재 KTern.AI는 에이전트 네트워크의 적용 범위를 공급망(Supply Chain), 인사(HR), Basis 운영 영역으로 확장하고 있습니다.
확인된 사실: 위 표의 수치와 “내부 측정”이라는 원문 단서, 탐색 단계의 예산 비중, 가동 후 요청 감소의 주된 요인, 480시간 재투자, 당일 배포, 품질 편차 감소, 추적 시간 단축, 7배·24%가 플랫폼 전체 수치라는 점, 공급망·HR·Basis 확장 계획.
5. Insight
도메인 기업은 도메인에 집중하고 인프라는 외부에 맡깁니다. KTern.AI가 AgentCore로 전환하며 얻은 가장 큰 소득은 단편적인 수치 개선보다 엔지니어링 리소스의 투입처가 바뀌었다는 점입니다. 이전에는 에이전트를 하나 만들 때마다 오케스트레이션, 메모리, 인증, 모니터링 환경을 조립하는 데 2~3주를 쏟아야 했지만, 이제는 SAP 전환을 깊이 이해하는 에이전트를 설계하는 본질적 작업에 그 시간을 사용합니다. 확보한 월 480시간을 에이전트 고도화에 온전히 재투자한 점이 이러한 변화를 잘 보여 줍니다.
에이전트를 코드가 아닌 설정으로 다루면 확장이 한결 수월해집니다. 에이전트 하나를 프롬프트, 도구 연결, 오케스트레이션 패턴의 조합으로 규정하면, 새로운 에이전트나 고객사용 변형 모델을 추가할 때 설정값 하나만 새로 정의하면 됩니다. 20여 개의 에이전트를 50개가 넘는 설정으로 유연하게 운영할 수 있는 배경입니다. 커스텀 오케스트레이션 코드를 직접 작성하고 싶을 때마다 설정 기반으로 풀어내는 편이 개발 속도와 유지보수성 면에서 훨씬 유리했다는 점 역시 원문이 꼽는 첫 번째 교훈입니다.
장기 프로젝트에서는 메모리 설계가 에이전트의 완성도를 결정합니다. 12~18개월 동안 이어지는 장기 프로젝트에서 에이전트가 매 작업마다 처음부터 다시 파악해야 한다면, 숙련된 컨설턴트처럼 일관되게 추론하기 어렵습니다. 그렇다고 모든 맥락을 전부 집어넣으면 응답이 느려지고 비용이 치솟으며 환각도 잦아집니다. 원문이 “첫 프롬프트를 쓰기 전에 메모리부터 설계하라”고 권고하는 배경입니다.
품질 평가는 출시 시점에 한 번으로 끝내지 않고 설정이 바뀔 때마다 수행합니다. 기반 파운데이션 모델이 업데이트되거나 프로덕션 데이터의 특성이 달라지면 에이전트의 동작 양상도 함께 바뀝니다. 설정이 변경될 때마다 평가를 자동으로 실행해야 고객이 문제를 겪기 전에 선제적으로 변화를 포착할 수 있습니다.
기업 고객 환경에서는 명확한 보안 검증이 도입을 가르는 전제 조건입니다. 규제가 엄격한 산업군의 고객은 에이전트가 내부 시스템에 접근하기 전에 인증 방식, 접근 제어 범위, 감사 가능 여부부터 꼼꼼히 점검합니다. 원문은 에이전트별 최소 권한 부여와 도구 호출에 대한 감사 기록 체계를 갖춘 덕분에, KTern.AI가 별도의 접근 제어 작업을 하지 않고도 보안팀이 프로덕션 배포를 승인할 수 있었다고 밝힙니다. 보안 요구사항에 확실히 대응할 수 있다면 구매 절차는 걸림돌이 아닌 신속한 도입의 계기가 됩니다.
복제 조건과 한계. 이 방식은 KTern.AI처럼 수년에 걸쳐 축적한 SAP 전환 패턴과 깊이 있는 전문 지식을 갖추고 있어야 실질적인 효과를 낼 수 있습니다. 설정만으로 에이전트를 빠르게 찍어낼 수 있는 이유는 그 설정에 채워 넣을 도메인 지식이 이미 탄탄하게 정리되어 있기 때문입니다. 또한 제시된 성과 수치는 모두 KTern.AI 내부 측정 결과이며, AWS 블로그에 AWS 담당자와 공동 작성한 자료라는 점을 함께 고려해야 합니다. 인프라 비용 70% 절감 역시 기존에 자체 운영하던 컨테이너 스택과 비교한 인프라 비용 기준입니다.
한 줄 요약: SAP처럼 길고 복잡한 전환 프로젝트에서는 인프라 관리를 전문 플랫폼에 위임하고 에이전트를 설정 기반으로 신속하게 배포하는 구조가, 도메인 전문성을 수십 개 에이전트로 빠르게 확장하는 유효한 방법이 될 수 있습니다.
6. 원문에 없는 추정 (구현 가설)
6.1 공통 에이전트 정의 위에 고객사 설정을 덧씌우는 구조
근거: 원문은 20개가 넘는 에이전트가 50개가 넘는 설정으로 운영되고, 에이전트의 동작이 프롬프트·도구 연결·오케스트레이션 패턴으로 정의되며, 고객사마다 프로세스·예외·비즈니스 규칙이 다른 독립 테넌트로 운영된다고 설명합니다. 프롬프트는 중앙에서 버전 관리하고 롤백할 수 있습니다.
에이전트 수보다 설정 수가 두 배 이상 많다는 점을 고려하면, 에이전트의 핵심 역할을 정의하는 공통 기본값과 고객사 시나리오별 변경 요소를 분리하여 관리했을 가능성이 높습니다. 예컨대 예외 마이닝 에이전트의 기본 설정에는 공통 역할 프롬프트와 FI·SD 모듈 데이터 조회 도구가 정의되어 있고, 고객사 설정에는 해당 기업 고유의 예외 판단 기준, 사용 가능한 도구 허용 범위, 대상 SAP 시스템 접속 정보가 추가로 얹히는 형태입니다. 이렇게 계층을 분리하면 공통 프롬프트를 수정했을 때 모든 고객사 환경에 일괄 반영하면서도 고객사 고유의 규칙은 안전하게 유지할 수 있습니다. 만약 공통 프롬프트 변경이 특정 고객사에서 문제를 일으키더라도 해당 고객사만 이전 버전으로 고정하는 유연한 대처도 가능했을 것입니다. 테넌트 간 분리는 AgentCore 런타임의 세션 격리 기능과 함께 메모리 저장 단위를 고객사 및 프로젝트별로 구분하는 방식으로 구현했을 것으로 추정됩니다.
6.2 리버스 엔지니어링 결과를 공통 자료로 두는 프로젝트 메모리
근거: 원문은 리버스 엔지니어링 에이전트의 결과가 뒤따르는 에이전트들의 공통 기반이 되고, AgentCore Memory가 커스텀 코드 목록·프로세스 결정·예외 패턴을 세션을 넘어 유지한다고 설명합니다. 또 모든 맥락이 아니라 적절한 맥락이 목표이며, 메모리 스키마 설계가 에이전트의 추론 품질을 좌우한다고 말합니다.
리버스 엔지니어링 에이전트가 도출한 현재 상태 분석 데이터는 초기에 한 번 생성된 뒤 여러 후속 에이전트가 지속적으로 참조하는 프로젝트 공용 자산으로 저장되었을 가능성이 높습니다. 용량이 큰 원본 데이터(커스텀 객체 전체 목록, 시스템 설정 덤프)는 Amazon S3에 보관하고, 메모리에는 객체별 복잡도 분류나 유지·리팩터링·폐기 여부와 같은 핵심 요약 및 의사결정 기록만을 압축해 유지했을 것입니다. 이러한 구성을 취하면 커스텀 코드 분석, Fit-to-standard, 테스트 케이스 생성 에이전트가 각자 필요한 데이터만 선별적으로 가져갈 수 있어 맥락 크기를 가볍게 유지할 수 있습니다. 설계 단계의 결정이 테스트 단계에서 번복되는 일이 흔한 SAP 프로젝트 환경을 고려할 때, 의사결정마다 시점과 판단 근거를 함께 기록하여 후속 에이전트가 항상 가장 최근의 결정을 따르도록 유도했을 것으로 보입니다. 그래프 패턴은 이러한 공통 자료를 토대로 분기 로직을 처리하는 데 활용되었을 것입니다. 예를 들어 복잡도가 높게 분류된 객체만 별도의 집중 처리 경로로 연결하는 식입니다.
6.3 설정 변경을 평가 결과로 승인하는 배포 절차
근거: 원문은 설정이 바뀔 때마다 KTern.AI 고유의 SAP 테스트 케이스로 평가를 돌려 82%의 1회 실행 성공률을 유지하고, 모델 변화로 인한 동작 변화를 일찍 잡는다고 설명합니다. 또 새 에이전트가 설정 배포로 당일에 프로덕션에 나가며, 프롬프트 변경은 롤백할 수 있습니다.
신규 에이전트 당일 배포와 설정 변경 시마다 진행되는 평가 작업이 유기적으로 맞물려 돌아가려면, 자동화된 평가 결과가 배포 승인 여부를 가르는 필수 관문으로 연동되어 있었을 가능성이 높습니다. 에이전트 설정이 갱신되면 유형별로 사전 정의된 벤치마크 데이터(과거 프로젝트에서 검증을 마친 테스트 케이스, 주요 예외 사례, 커스텀 코드 표본)를 바탕으로 자동 평가가 실행되고, 이전 버전 대비 품질 지표가 떨어지면 배포가 자동으로 차단되는 구조입니다. 평가를 통과한 설정이라 하더라도 전체 고객사에 즉각 배포하기보다는 일부 파일럿 프로젝트에 선적용한 뒤, CloudWatch를 통해 오류율과 도구 호출 실패 추이를 확인하며 점진적으로 확대 적용했을 것으로 보입니다. 만에 하나 예기치 못한 결함이 발견되면 중앙 프롬프트 관리 시스템의 롤백 기능을 통해 즉시 이전 정상 설정으로 되돌렸을 것입니다. 파운데이션 모델 업데이트 역시 이와 동일한 검증 절차를 거치는 설정 변경의 일환으로 관리되었을 가능성이 큽니다.
7. 출처
- AWS Machine Learning Blog — How KTern.AI built agentic AI for SAP on Amazon Bedrock AgentCore
https://aws.amazon.com/blogs/machine-learning/how-ktern-ai-built-agentic-ai-for-sap-on-amazon-bedrock-agentcore/
발행일: 2026-07-10 (Vijayaraghavan C P — KTern.AI, Prabhu G — AWS)