KTern.AI가 에이전트 20여 개를 다루는 법

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 주요 구성 요소별 역할은 다음과 같습니다.

에이전트는 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 담당자가 공동으로 기고한 내용입니다.

원문은 과거 탐색·평가 단계가 초기 프로젝트 예산에서 가장 큰 몫을 차지했다고 설명합니다. 시스템 가동 후 지원 요청이 40% 줄어든 주요 원인으로는 커스텀 코드 분석 에이전트가 잠재 위험을 초기에 식별해 낸 점을 꼽습니다. 절감한 월 480시간의 엔지니어링 리소스는 에이전트 고도화와 신규 기능 개발에 전량 재투자했습니다. 새 에이전트는 설정 배포를 거쳐 당일 바로 프로덕션 환경에 적용됩니다.

품질 측면에서는 표준화된 에이전트 기반 프로세스를 도입하면서, 투입되는 컨설턴트 팀의 역량에 따른 프로젝트별 품질 편차가 줄었다고 설명합니다. 관측성 측면에서는 기존에 여러 시스템의 로그를 수작업으로 대조하던 디버깅 작업이 몇 분 단위로 단축되었으며, 이러한 환경이 99.8% 가동률을 안정적으로 뒷받침한다고 밝힙니다.

한편 원문 초반에 등장하는 “7배 빠른 전환, 전체 작업량 24% 감소”라는