KTern.AI, 4~6시간 만에 배포하는 에이전트

요약

KTern.AI는 서비스형 디지털 전환 플랫폼에 20개가 넘는 전문 에이전트를 도입했습니다.
인프라 구축 시간을 95% 줄이고 프로젝트 기간을 평균 45% 단축했습니다.
도메인 소프트웨어 기업은 기반 인프라를 맡기고 업무 규칙 설정에 집중해야 합니다.

기업 시스템 전환의 거대한 복잡성과 마주한 질문

기업의 핵심 전사적 자원 관리 시스템을 최신 환경인 SAP S/4HANA로 전환하는 작업은 정보기술 업계에서 손꼽히는 고난도 프로젝트입니다. 기업의 모든 구매, 생산, 영업, 회계 데이터가 얽혀 있는 데다 그동안 덧붙여 만든 맞춤형 개발 코드가 거대하게 얽혀 있기 때문입니다. 보통 이러한 SAP 전환 프로젝트는 탐색, 설계, 테스트, 실제 시스템 전환을 거치며 짧아도 12개월에서 길게는 18개월이 걸립니다. 이 긴 시간 동안 고도로 숙련된 전문 컨설턴트들이 투입되어 수많은 업무 흐름을 일일이 분석해야 했습니다.

SAP 공인 DXaaS(서비스형 디지털 전환) 플랫폼을 운영하는 KTern.AI는 이 거대한 장벽을 해결하고자 했습니다. DXaaS는 복잡한 디지털 전환 과정을 클라우드 서비스 형태로 제공하는 방식을 뜻합니다. KTern.AI는 기존 SaaS 형태의 플랫폼을 인공지능 에이전트 기반 플랫폼으로 탈바꿈시키며 20개가 넘는 전문 에이전트를 프로덕션 환경에 투입했습니다. 그 결과 프로젝트 기간을 평균 45% 단축하고, 초기 탐색 및 평가 단계에 걸리던 시간을 60~70%까지 줄였습니다. 이 글은 KTern.AI와 AWS 담당자가 AWS Machine Learning Blog에 공동으로 게재한 기술 사례를 바탕으로, 복잡한 기업 업무를 수십 개의 에이전트로 쪼개어 자동화한 구조를 살펴봅니다.

에이전트 하나를 추가하는 데 2~3주가 걸리던 기반의 한계

단발적인 대화형 인공지능 도구로는 1년이 넘게 이어지는 SAP 전환 프로젝트를 온전히 이끌 수 없었습니다. 에이전트는 수백 번의 대화가 이어지는 긴 호흡 속에서도 과거의 결정을 기억해야 했고, 여러 업무 영역을 넘나들며 동시에 추론해야 했습니다. KTern.AI가 자율 에이전트 네트워크를 구축하는 과정에서 맞닥뜨린 과제는 크게 다섯 가지였습니다.

첫째는 대규모 프로젝트 맥락의 유지였습니다. 에이전트는 프로젝트 전체 기간에 걸쳐 수백 건의 상호작용 상태를 보존하고 과거의 결정을 참조해야 했습니다. 하지만 무작정 모든 대화 기록을 프롬프트에 밀어 넣으면 응답 속도가 느려지고 비용이 치솟으며 환각 현상이 발생할 위험이 커집니다. 따라서 모든 맥락이 아니라 당장 필요한 적절한 맥락만을 선별해 유지하는 장치가 절실했습니다.

둘째는 안전하고 감사 가능한 도구 연동이었습니다. 에이전트가 SAP의 응용 프로그래밍 인터페이스(API), 고객사의 ERP 시스템, 프로세스 저장소, KTern.AI 데이터베이스에 실시간으로 접근하려면 기업 보안팀이 승인할 수 있는 엄격한 인증과 감사 추적 체계가 뒷받침되어야 했습니다.

셋째는 멀티테넌시 환경에서의 유연성이었습니다. 멀티테넌시는 하나의 소프트웨어 인프라에서 여러 고객사의 데이터를 논리적으로 완벽히 격리해 서비스하는 구조를 말합니다. 고객사마다 고유한 업무 규칙과 예외 처리 절차가 완전히 달랐기 때문에, 고객사를 추가할 때마다 엔지니어가 맞춤형 코드를 새로 짜지 않고 설정만으로 대응할 수 있어야 했습니다.

넷째는 동적 확장성이었습니다. 가벼운 평가 작업은 에이전트 몇 개만 몇 시간 동안 실행하면 충분하지만, 전사 마이그레이션이 시작되면 수십 개의 에이전트가 몇 달 동안 쉬지 않고 돌아가야 했습니다.

다섯째는 프로덕션 수준의 관측성이었습니다. 복잡한 다중 에이전트 환경에서 문제가 발생했을 때 각 에이전트의 판단 과정과 도구 호출 경로를 처음부터 끝까지 추적할 수 없다면 기업 환경에 배포할 수 없었습니다.

AgentCore를 도입하기 전, KTern.AI는 직접 관리하는 컨테이너 환경에서 애플리케이션을 운영했습니다. 시스템 자체는 돌아갔지만, 정작 가장 중요한 업무 지식 개발 대신 기반 인프라를 만드느라 막대한 엔지니어링 시간이 소모되었습니다. 에이전트 하나를 새로 추가할 때마다 오케스트레이션, 메모리, 도구 접근, 인증, 모니터링 인프라를 일일이 손으로 조립해야 했고, 이 작업에만 최소 2~3주가 걸렸습니다.

도메인 지식은 KTern.AI가 쥐고 인프라는 AgentCore에 맡기다

KTern.AI는 Strands Agents SDK로 에이전트를 만들고, 이를 Amazon Bedrock AgentCore 위에서 구동하는 아키텍처를 세웠습니다. 기본 설계 원칙은 관심사의 분리였습니다. SAP 전환을 깊이 이해하는 고유 도메인 지식은 KTern.AI 계층에 집중시키고, 호스팅, 확장, 메모리, 도구 접근, 인증, 관측성과 같은 공통 인프라 영역은 전부 AgentCore에 위임했습니다. 언어 모델은 Amazon Bedrock을 통해 Anthropic Claude 제품군 등을 유연하게 호출해 사용했습니다.

이 구조의 핵심은 커스텀 오케스트레이션 코드를 단 한 줄도 작성하지 않고 오직 설정만으로 에이전트를 배포한다는 점입니다. 에이전트의 작동 방식은 프롬프트, 도구 연결, 오케스트레이션 패턴이라는 세 가지 설정값의 조합으로 결정됩니다. 오케스트레이션 패턴은 Strands의 세 가지 멀티 에이전트 패턴을 업무 성격에 맞춰 골라 썼습니다. 여러 경로를 병렬로 탐색해야 할 때는 스웜 패턴을 적용했고, 단계별로 순서대로 진행해야 하는 작업에는 워크플로 패턴을 활용했습니다. 조건에 따라 파이프라인이 분기되어야 하는 복잡한 작업에는 그래프 패턴을 배치했습니다.

설정 기반 에이전트 오케스트레이션

에이전트는 세 설정의 조합이며 워크로드별 패턴을 적용합니다. (출처: AWS Machine Learning Blog)

기업 사용자가 KTern.AI 플랫폼을 통해 전환 작업을 요청하면, 요청은 에이전트 오케스트레이션 계층을 거쳐 AgentCore 런타임으로 전달됩니다. AgentCore를 구성하는 핵심 요소들은 복잡한 인프라 작업을 다음과 같이 나누어 처리합니다.

Runtime은 컴퓨팅 자원을 할당하고 자동으로 확장하며, 여러 고객 환경 사이의 세션을 완벽하게 격리합니다. 이 덕분에 KTern.AI는 멀티테넌트 격리 구조를 사내에서 직접 설계하고 감사받을 필요가 없어졌습니다. Memory는 커스텀 코드 목록, 과거의 프로세스 결정, 예외 처리 패턴을 세션이 끊겨도 프로젝트 전반에 걸쳐 안전하게 유지합니다. Gateway는 표준 연결 규격인 MCP(Model Context Protocol)를 활용해 SAP 환경, 고객 ERP API, 프로세스 마이닝 데이터, 분석 저장소를 단순 설정 등록만으로 에이전트가 쓰는 도구로 변환합니다. Identity는 에이전트마다 최소한의 권한만 부여하고 도구 호출 이력을 감사 로그로 남기며 고객사의 기존 인증 체계와 매끄럽게 연동합니다. Observability는 로그, 지표, 트레이스를 OpenTelemetry 규격으로 Amazon CloudWatch에 전송해 최초 요청부터 판단, 도구 호출, 응답에 이르는 전체 과정을 빈틈없이 추적합니다. Evaluations는 KTern.AI 고유의 SAP 테스트 케이스를 사용해 설정이 바뀔 때마다 품질 평가를 자동으로 수행합니다.

네트워크 보안 측면에서는 AWS PrivateLink 기반의 VPC(가상 사설 클라우드) 인터페이스 엔드포인트를 구축했습니다. 이를 통해 모든 에이전트가 공용 인터넷을 거치지 않고 완전히 격리된 사설망 안에서 Amazon Bedrock과 AgentCore에 안전하게 접근합니다. 보조 시스템으로는 Amazon S3, AWS Lambda, AWS IAM이 유기적으로 맞물려 돌아갑니다.

전환 단계마다 전문성을 발휘하는 7개의 핵심 에이전트

KTern.AI는 프로덕션 환경에서 20개가 넘는 전문 에이전트를 운영하고 있으며, 고객사 시나리오에 따라 적용되는 설정은 50개가 넘습니다. 각 에이전트는 장기 프로젝트의 특정 영역을 전담하며 긴밀하게 협업합니다.

첫 번째는 리버스 엔지니어링 에이전트입니다. 기존 SAP 환경에 축적된 커스텀 ABAP 코드, 사용자가 임의로 기능을 추가한 사용자 출구(user exit), 기능 개선(enhancement), 시스템 설정, 업무 프로세스 변형을 샅샅이 스캔합니다. 이를 통해 현재 시스템의 상세한 목록을 만들어 내며, 이 결과물은 후속 에이전트들이 전환 영향도와 현대화 방안을 추론하는 공통 기준으로 쓰입니다.

두 번째는 포워드 엔지니어링 에이전트입니다. 리버스 엔지니어링 에이전트가 파악한 현재 상태를 바탕으로 클린 코어 원칙에 맞춘 목표 아키텍처와 마이그레이션 코드를 생성합니다. 클린 코어 원칙은 핵심 디지털 코어에는 표준 기능만 두고 독자적인 확장 기능은 바깥으로 분리해 유지하는 SAP의 현대적 아키텍처 설계 방식입니다. 이 에이전트는 어떤 코드를 그대로 유지하고, 어떤 부분을 리팩터링하며, 무엇을 폐기해야 할지 명확한 권고안을 제시합니다. 두 에이전트는 “리버스에서 포워드로 이어지는 연속 파이프라인”을 이룹니다.

세 번째는 Fit-to-standard 에이전트입니다. 기업의 기존 업무 프로세스를 SAP 표준 기능과 일일이 대조해 표준에서 벗어난 지점을 찾아내고 대안을 제시합니다. 과거에는 기능 컨설턴트들이 수백 개에 달하는 프로세스를 일일이 눈으로 검토하던 고된 작업이었습니다.

네 번째는 커스텀 코드 분석 에이전트입니다. 고객사가 자체 개발한 방대한 ABAP 코드를 분석해 최신 시스템과의 호환성, 더 이상 지원하지 않는 API 사용 여부, 성능 저하 위험, 최신화 가능성을 평가합니다. 객체마다 복잡도를 분류하고 우선적으로 조치해야 할 가이드를 정리해 줍니다.

다섯 번째는 테스트 케이스 생성 에이전트입니다. 비즈니스 프로세스 흐름, 코드 분석 결과, 시스템 구성 데이터를 종합해 실제 수행할 수 있는 테스트 케이스를 만듭니다. 여기에는 테스트용 데이터, 기대 결과, 명확한 검증 기준이 빠짐없이 포함됩니다.

여섯 번째는 프로세스 마이닝 에이전트입니다. 구매부터 대금 지급까지를 뜻하는 P2P, 주문부터 대금 회수까지를 뜻하는 O2C, 회계 기록부터 결산 보고까지를 뜻하는 R2R 흐름의 이벤트 로그를 분석합니다. 이를 통해 최초 설계된 프로세스와 직원들이 실제로 수행하는 운영 방식 사이의 괴리를 찾아내고, 병목 지점, 반복 재작업 구간, 자동화 기회를 짚어냅니다.

일곱 번째는 예외 마이닝 에이전트입니다. 재무회계(FI), 관리회계(CO), 영업관리(SD), 자재관리(MM) 모듈 전반에서 발생하는 운영상의 예외를 사전에 찾아내 분류합니다. 과거에는 문제가 터진 뒤에야 확인하던 대사 불일치 송장, 시스템에 묶여 있는 구매 주문, 미결 대변 메모, 청구 예외 등을 선제적으로 감지합니다. 이 에이전트는 Gateway를 통해 고객 시스템 내부의 금융 및 영업 데이터에 직접 접근해 상태를 확인합니다.

프롬프트는 중앙에서 버전을 관리하고 문제가 생기면 즉시 이전 상태로 되돌릴 수 있는 롤백 거버넌스 체계를 갖추었습니다. 에이전트 설정, 오케스트레이션 패턴, 심지어 기반 모델 선택까지 모두 설정에서 변경하며 실험할 수 있습니다. 특히 테스트 케이스 생성 에이전트처럼 결과물의 정확도가 실제 시스템 가동 위험과 직결되는 곳에서는 AgentCore Evaluations를 사용해 설정이 바뀔 때마다 품질을 자동으로 평가합니다. 이를 통해 기반 모델이 업데이트되면서 발생할 수 있는 미세한 행동 변화를 일찍 잡아냅니다.

실제 시스템에서는 공통 기본 정의 위에 고객사별 전용 설정을 덧씌우는 방식으로 작동했을 것입니다. 에이전트의 기본 역할과 모듈 접근 도구는 공통 프롬프트로 유지하고, 고객사 고유의 예외 기준이나 엔드포인트는 개별 설정으로 관리하는 형태입니다. 이렇게 하면 공통 프롬프트가 개선되어도 개별 고객사의 특화 규칙은 안전하게 보호됩니다.

또한 리버스 엔지니어링 에이전트가 만든 방대한 분석 결과는 프로젝트 전반의 공통 자료로 활용되었을 것입니다. 전체 코드 덤프는 Amazon S3에 저장하고, AgentCore Memory에는 객체별 복잡도 분류와 폐기 권고안 같은 핵심 요약 및 결정 기록만 담아 두었을 가능성이 높습니다. 그래야 후속 에이전트들이 문맥 크기를 낭비하지 않고 필요한 정보만 꺼내 쓸 수 있기 때문입니다.

아울러 새로운 설정 배포는 자동 평가를 통과해야만 승인되는 배포 파이프라인으로 구성되었을 것입니다. 과거 검증된 벤치마크 데이터를 기준으로 평가 점수를 확인한 뒤 일부 프로젝트에 먼저 적용하고, CloudWatch 지표에서 오류가 감지되면 즉시 이전 버전으로 롤백하는 안전장치를 두었을 것입니다.

입증된 수치와 달라진 프로젝트 현장

이러한 체계를 구축한 뒤 나타난 성과는 뚜렷했습니다. 이 수치들은 KTern.AI가 프로덕션 SAP 전환 프로젝트 현장에서 내부적으로 측정한 결과입니다.

실제 현장에서 SAP 프로젝트 전체 기간은 평균 45% 단축되었습니다. 분석 단계의 업무 전문가(SME)와 컨설턴트 의존도는 최대 60% 감소했습니다. 자동 생성 테스트 케이스의 1회 실행 성공률은 82%에 달했습니다. 재무 및 영업 모듈 운영 예외의 90%를 에이전트가 스스로 찾아냈습니다.

개발 주기는 85% 단축되었습니다. 인프라 구축 시간은 95% 단축되었습니다. 인프라 비용은 이전에 직접 운영하던 컨테이너 스택 대비 70% 절감되었습니다.

KTern.AI 도입 항목별 단축·감소율

KTern.AI가 프로덕션 SAP 전환 프로젝트에서 내부 측정한 값입니다. 인프라 비용은 이전에 직접 운영하던 컨테이너 스택과 비교한 값입니다. (출처: AWS Machine Learning Blog)

과거 SAP 프로젝트 초기 예산에서 가장 큰 비중을 차지하던 탐색 및 평가 단계가 60~70% 줄어들면서 전체 사업 속도가 크게 개선되었습니다. 실제 시스템을 가동한 이후 지원 요청이 40% 줄어든 가장 결정적인 이유는 커스텀 코드 분석 에이전트가 위험을 초기에 짚어냈기 때문입니다.

개발 조직의 체질도 바뀌었습니다. 이전에는 에이전트 하나를 인프라까지 조립해 배포하는 데 최소 2~3주가 걸렸지만, 이제는 4~6시간이면 첫 프로덕션 에이전트를 내보낼 수 있습니다. 새로운 에이전트는 설정만 배포하여 당일 프로덕션에 즉시 투입됩니다. 매월 회수한 480시간의 엔지니어링 시간은 엔지니어 3명에 맞먹는 규모로, 인프라 유지보수 대신 에이전트의 지능을 고도화하고 새로운 도메인 기능을 개발하는 데 전액 재투자되었습니다.

품질의 편차도 줄었습니다. 투입되는 컨설턴트 팀의 숙련도에 따라 들쑥날쑥하던 프로젝트 품질이 에이전트 기반 프로세스로 표준화되면서 고르게 맞춰졌습니다. 여러 시스템에 흩어져 있던 로그를 손으로 대조하던 디버깅 작업은 단 몇 분으로 줄어들었고, 이는 99.8%라는 높은 에이전트 가동률을 뒷받침하는 든든한 밑바탕이 되었습니다. 까다롭기로 유명한 엔터프라이즈 보안 심사에서도 에이전트별 최소 권한 원칙과 투명한 도구 호출 감사 기록 덕분에, KTern.AI가 별도의 접근 제어 소프트웨어를 개발하지 않고도 기업 고객 보안팀의 프로덕션 승인을 빠르게 받아냈습니다.

한편 KTern.AI 플랫폼 전체가 내세우는 7배 빠른 전환과 전체 작업량 24% 감소라는 성과는 플랫폼 고유의 지식 인텔리전스 엔진과 데이터 기반 하이퍼오토메이션이 결합된 전체 결과이며, 이번 에이전트 도입 성과와는 구별되는 플랫폼 차원의 수치입니다.

엔터프라이즈 AI 에이전트를 준비하는 조직을 위한 교훈

KTern.AI의 전환 사례는 복잡한 기업용 소프트웨어 환경에서 인공지능 에이전트를 대규모로 운영하려는 조직에 명확한 기준점을 제공합니다. 원문이 강조하는 핵심 교훈은 다음과 같습니다.

첫째, 코드를 작성하는 것보다 설정을 택하는 것이 훨씬 유리합니다. 에이전트의 역할을 프롬프트, 도구 연결, 오케스트레이션 패턴이라는 설정의 조합으로 추상화하면, 코드를 새로 컴파일하고 배포하지 않고도 20여 개의 에이전트를 50개가 넘는 설정으로 유연하게 운영할 수 있습니다. 자체 오케스트레이션 코드를 직접 작성하고 싶은 충동을 억누르고 표준화된 설정 방식을 고수하는 것이 운영 속도와 유지보수성 측면에서 훨씬 뛰어납니다.

둘째, 메모리 구조는 1급 설계 대상이어야 합니다. 1년 이상 지속되는 대형 프로젝트에서 에이전트가 매번 대화를 처음부터 시작한다면 노련한 전문가처럼 일할 수 없습니다. 반대로 과거의 모든 대화 기록을 쏟아부으면 시스템은 느려지고 비용은 폭증합니다. 원문이 “첫 프롬프트를 쓰기 전에 메모리부터 설계하라”고 강조한 이유가 여기에 있습니다. 어떤 정보를 요약해 장기 기억으로 남기고, 어떤 시점에 꺼내 쓸 것인지 체계적인 메모리 스키마를 먼저 확립해야 합니다.

셋째, 첫날부터 철저하게 계측하고 설정이 바뀔 때마다 평가해야 합니다. 언어 모델은 살아있는 유기체와 같아서 기반 모델이 업데이트되거나 데이터 패턴이 달라지면 예기치 않게 동작이 달라집니다. 설정값이 바뀔 때마다 자동으로 돌아가는 엄격한 평가 체계를 갖추어야만 고객이 문제를 겪기 전에 성능 변화를 감지할 수 있습니다.

넷째, 첫 대화를 나누기 전에 기업 보안팀이 신뢰할 수 있는 구조를 먼저 만들어야 합니다. 기업 내부 데이터를 다루는 에이전트는 권한 격리와 감사 추적이 완벽하지 않으면 시험 단계를 넘어 프로덕션 환경으로 나갈 수 없습니다. 에이전트마다 최소한의 도구 권한만 부여하고 네트워크 트래픽을 사설망 안에 가두는 보안 아키텍처가 선행되어야 도입 논의가 급물살을 탈 수 있습니다.

KTern.AI는 이제 검증된 에이전트 네트워크를 공급망(Supply Chain), 인사(HR), 그리고 SAP 시스템의 기술적 운영을 담당하는 Basis 영역으로 넓혀가고 있습니다. 복잡한 도메인 지식을 가진 기업일수록 인프라 구축의 늪에서 벗어나 자신이 가장 잘 아는 업무 규칙을 정교한 에이전트로 모델링하는 데 집중해야 합니다. 그것이 수십 개의 인공지능 에이전트를 안정적으로 거느리고 비즈니스의 속도를 끌어올리는 가장 현실적인 경로입니다.

출처

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)