ABL로 컴파일되는 에이전트, Kore.ai가 겨냥한 런타임 병목

Kore.ai가 2026년 5월 21일 차세대 Agent Platform인 Artemis edition을 발표했습니다. 표면만 보면 또 하나의 엔터프라이즈 에이전트 플랫폼 출시입니다. 하지만 이번 발표에서 더 흥미로운 지점은 "어떤 모델을 쓴다"가 아니라 "에이전트를 어떤 산출물로 정의하고, 누가 실행을 통제하는가"입니다.

Kore.ai가 전면에 내세운 것은 세 가지입니다. 첫째, Agent Blueprint Language, 줄여서 ABL입니다. 둘째, 비즈니스 목표를 ABL로 바꾸고 운영 trace를 다시 읽어 개선안을 제안한다는 AI architect인 Arch입니다. 셋째, LLM의 추론과 결정론적 업무 플로를 병렬로 두는 Dual-Brain Architecture입니다. 이 조합은 에이전트를 프롬프트, 함수 호출, 워크플로 설정의 느슨한 묶음이 아니라 컴파일되고 검토되고 배포되는 운영 단위로 만들겠다는 주장에 가깝습니다.

이 뉴스가 개발자에게 중요한 이유는 명확합니다. 지난 1년 동안 에이전트 논의는 모델이 얼마나 오래 생각하고, 얼마나 많은 도구를 호출하고, 얼마나 큰 컨텍스트를 처리하는지에 몰려 있었습니다. 이제 기업 구매자는 다른 질문을 던지고 있습니다. 누가 에이전트의 권한을 승인합니까. 누가 배포 전 검증을 맡습니까. 사고가 난 뒤 어떤 trace를 볼 수 있습니까. 모델을 바꿔도 기존 에이전트 정의가 계속 작동합니까. Kore.ai Artemis는 바로 이 질문에 대한 제품화된 답을 내놓으려 합니다.

출시의 핵심은 ABL입니다

공식 발표에서 Kore.ai는 ABL을 "compiled, declarative language"로 설명합니다. 에이전트, 시스템, 워크플로를 정의하고 검증하고 거버넌스하기 위한 언어라는 뜻입니다. VentureBeat 인터뷰에서는 이 산출물이 YAML 기반이며 GitHub에 저장하고 CI/CD 파이프라인에서 버전 관리할 수 있다는 설명도 나왔습니다. 표현만 보면 인프라스트럭처 코드나 워크플로 정의 언어와 비슷한 냄새가 납니다.

이 지점이 중요합니다. 많은 팀이 이미 에이전트 설정을 코드 저장소에 넣고 있습니다. 시스템 프롬프트, 도구 스키마, eval, 라우팅 규칙을 JSON이나 YAML로 관리합니다. 그런데 Kore.ai의 ABL 주장은 한 단계 더 나아갑니다. 단순히 설정 파일을 저장한다는 말이 아니라, 에이전트가 운영 환경에서 실행되기 전에 표준 언어로 표현되고, 컴파일되고, 플랫폼 런타임의 통제를 받는다는 주장입니다.

공식 발표는 ABL에 여섯 가지 오케스트레이션 패턴이 포함된다고 설명합니다. supervisor, delegation, handoff, fan-out, escalation, agent-to-agent federation입니다. Kore.ai 문서의 오케스트레이션 개요도 단일 에이전트, supervisor, adaptive network 같은 패턴을 구분하고, supervisor가 요청을 분석하고, subtasks로 분해하고, specialist agent에 위임하고, 충돌을 조정한다고 설명합니다. 즉 ABL은 "이 에이전트가 무슨 말을 해야 하는가"보다 "이 에이전트 시스템이 어떤 통제 구조 안에서 움직이는가"에 가까운 층입니다.

Arch는 "AI가 AI를 만든다"는 주장입니다

Kore.ai 발표의 두 번째 축은 Arch입니다. Arch는 사용자의 비즈니스 목표를 받아 에이전트 토폴로지를 설계하고, ABL을 만들고, 검증하고, 운영 trace를 기반으로 개선한다고 소개됐습니다. 공식 발표에는 "AI building AI", "AI governing AI", "AI optimizing AI"라는 구조가 반복됩니다. 마케팅 문구처럼 보이지만, 그 안에는 실제 제품 방향이 있습니다.

지금까지 엔터프라이즈 에이전트 구축은 두 방향으로 갈라졌습니다. 하나는 개발자가 프레임워크와 SDK를 사용해 직접 에이전트를 조립하는 방식입니다. 다른 하나는 업무 담당자가 노코드 빌더에서 플로와 지식을 구성하는 방식입니다. 첫 번째는 유연하지만 운영팀이 이해하기 어렵고, 두 번째는 빠르지만 복잡한 소프트웨어 변경 관리와 맞물리기 어렵습니다. Kore.ai는 ABL과 Arch를 통해 이 둘 사이에 중간 산출물을 만들려 합니다.

그 산출물이 제대로 작동하려면 세 조건이 필요합니다. 사람이 diff를 읽을 수 있어야 합니다. 테스트와 승인 단계를 자동화할 수 있어야 합니다. 운영 중인 에이전트의 실패가 다시 설계 변경으로 연결될 수 있어야 합니다. Kore.ai는 이 흐름을 모두 플랫폼 안에 넣겠다고 말합니다. 개발자 입장에서는 편리한 추상화일 수 있지만, 동시에 플랫폼이 빌드, 런타임, 관측, 개선 루프를 모두 쥐는 구조이기도 합니다.

VentureBeat는 CEO Raj Koneru의 설명을 통해 ABL이 GitHub에 들어가고 버전 관리될 수 있다고 전했습니다. 그러나 같은 보도는 중요한 제한도 짚었습니다. ABL 자체는 YAML 기반 산출물로 관리할 수 있지만, 그것을 실행하는 런타임은 아직 독립형 컴포넌트로 제공되지 않습니다. Koneru는 더 가벼운 런타임 버전을 향후 제공할 것이라고 밝혔지만, 초기 릴리스는 통합 엔터프라이즈 경험을 우선합니다. 이 부분이 Artemis를 단순한 오픈 표준이 아니라 플랫폼 전략으로 읽어야 하는 이유입니다.

이중 두뇌는 규제 산업의 언어입니다

Dual-Brain Architecture라는 이름은 다소 거창합니다. 그러나 Kore.ai가 왜 이 표현을 선택했는지는 분명합니다. 은행, 의료, 보험, 통신처럼 규제가 강한 산업에서는 모든 결정을 LLM에 맡길 수 없습니다. 사용자는 자연어로 묻고, 모델은 추론해야 하지만, 승인, 한도, 정책, 기록, 예외 처리는 결정론적이어야 합니다.

Kore.ai의 설명은 두 종류의 엔진을 병렬로 둡니다. 하나는 에이전틱 추론을 담당하는 LLM 기반 엔진입니다. 다른 하나는 결정론적 업무 플로와 제약을 담당하는 엔진입니다. 둘은 공유 메모리와 단일 런타임 안에서 움직이고, 거버넌스는 모델 내부가 아니라 플랫폼 계층에서 강제된다는 것이 핵심입니다.

이 주장은 최근 에이전트 보안 논의와 맞물립니다. 프롬프트 인젝션, 과도한 도구 호출, 권한 밖 행동, 관측 불가능한 자동화가 모두 같은 질문으로 이어집니다. 에이전트가 똑똑해질수록, 안전장치를 프롬프트 안에 넣는 방식은 약해집니다. 모델이 실행 주체이자 정책 해석자이자 예외 처리자가 되면, 통제와 감사가 모델의 출력 품질에 종속됩니다. Kore.ai는 이 지점을 플랫폼 레이어로 끌어내리겠다고 말하는 셈입니다.

다만 이 구조가 실제로 얼마나 강한지는 공개 자료만으로 판단하기 어렵습니다. "결정론적 플로"가 어떤 정책 언어로 표현되는지, 어떤 종류의 tool call을 사전에 차단할 수 있는지, trace가 규제 감사에서 어느 정도 증거성을 갖는지, 운영 중 변경이 어떻게 승인되는지 같은 세부가 중요합니다. 발표 자료는 방향을 보여주지만, 개발자와 보안팀이 평가해야 할 것은 데모의 매끄러움보다 이 낮은 층의 계약입니다.

Microsoft와의 결합은 강점이자 질문입니다

Artemis는 Microsoft Azure에서 먼저 출시됩니다. 공식 발표는 Microsoft Foundry, Microsoft Agent 365, Entra ID, Microsoft Graph API, Azure Bot Framework, Teams 채널을 언급합니다. Kore.ai는 Agent 365 launch partner라고도 밝힙니다. Kore.ai 문서의 2026년 5월 10일 v1.8.3 릴리스 노트 역시 Agent Platform의 Microsoft Agent 365 통합을 설명합니다. 에이전트를 Microsoft 365 tenant에 export/register하고, Copilot과 Teams에서 쓰며, 중앙 거버넌스와 telemetry는 Agent 365 쪽에서 관리할 수 있다는 내용입니다.

이 결합은 현실적인 선택입니다. 많은 대기업은 이미 Entra ID, Microsoft 365, Teams, Graph API를 업무 운영의 기본면으로 깔고 있습니다. 에이전트 플랫폼이 이 신원, 권한, 협업 채널을 건너뛰고 독자적으로 확산되기는 어렵습니다. 특히 CISO 관점에서는 새 에이전트 도구가 기존 IAM과 감사 체계에 들어오는 것이 중요합니다.

동시에 이것은 Kore.ai가 내세우는 벤더 중립성과 긴장을 만듭니다. VentureBeat는 Kore.ai가 175개 모델, 여러 클라우드, 온프레미스, 다양한 데이터 소스와 MCP 연결을 지원한다고 보도했습니다. 그러나 초기 제품 경험이 Azure와 Microsoft Agent 365에 가장 깊게 최적화된다면, 중립 플랫폼이라는 메시지는 "장기 방향"이고 초기 실전 경로는 "Microsoft 생태계 우선"에 가까울 수 있습니다. 기업 고객에게는 나쁜 일이 아닐 수 있습니다. 하지만 개발자에게는 배포 대상과 운영 API가 어디까지 이식 가능한지 확인해야 한다는 뜻입니다.

경쟁은 에이전트 빌더가 아니라 운영 체계입니다

Kore.ai의 경쟁 상대는 더 이상 과거의 챗봇 빌더만이 아닙니다. Microsoft Agent 365와 Copilot Studio, Salesforce Agentforce, ServiceNow AI Agents, Google Vertex AI Agent Builder가 모두 같은 CIO 예산을 바라봅니다. 여기에 OpenAI, Anthropic, LangGraph 계열 프레임워크, 내부 플랫폼 팀이 만든 자체 런타임도 들어옵니다.

이 시장에서 차별화 포인트는 "에이전트를 만들 수 있다"가 아닙니다. 이제 대부분 만들 수 있습니다. 차이는 운영 계층입니다. 에이전트 정의가 재현 가능한가. 배포 전후 상태를 비교할 수 있는가. 모델 교체가 전체 업무 자동화를 망가뜨리지 않는가. 특정 부서의 에이전트가 다른 부서의 데이터에 접근하지 못하도록 막을 수 있는가. 사고가 났을 때 누가 어떤 정책으로 어떤 도구를 호출했는지 추적할 수 있는가.

Artemis가 흥미로운 이유는 이 질문을 제품 이름의 주변 기능으로 두지 않고 중심으로 가져왔기 때문입니다. ABL은 정의의 표준화를 말합니다. Arch는 생성과 개선 루프를 말합니다. Dual-Brain은 모델 밖 통제를 말합니다. Microsoft Agent 365 통합은 기존 신원과 업무 채널 안으로 들어가는 경로를 말합니다. 이 네 가지는 모두 "에이전트가 잘 대답한다"보다 "에이전트를 조직 안에서 어떻게 굴릴 것인가"에 대한 답입니다.

하지만 이 답에는 비용도 있습니다. 선언형 언어와 플랫폼 런타임이 강해질수록, 사용자는 더 많은 생산 운영 지식을 벤더 추상화에 맡깁니다. ABL이 Git에서 관리된다고 해도, 실행 semantics가 Kore.ai 런타임에 묶이면 이식성은 제한됩니다. Arch가 설계를 자동 생성해도, 생성된 산출물을 리뷰하고 테스트하는 내부 역량이 없으면 자동화된 블랙박스가 하나 더 늘어날 뿐입니다. Dual-Brain이 정책을 강제해도, 정책 언어와 로그가 외부 감사와 내부 보안팀의 기대를 만족해야 합니다.

개발팀이 봐야 할 실무 포인트

개발팀은 Artemis 같은 플랫폼을 볼 때 기능 목록보다 변경 관리 모델을 먼저 봐야 합니다. 첫 질문은 "ABL diff를 코드 리뷰할 수 있는가"입니다. 에이전트 변경은 이제 서비스 코드 변경과 비슷한 위험을 가집니다. 어떤 도구가 추가됐는지, 어떤 경로에서 escalation이 발생하는지, 어떤 정책이 완화됐는지, 어떤 모델이 기본값이 됐는지 diff로 읽을 수 있어야 합니다.

둘째는 "eval과 배포 승인이 같은 파이프라인에 들어오는가"입니다. Kore.ai가 Import/Export API와 CI/CD 친화성을 말하는 것은 긍정적인 신호입니다. 그러나 실제 조직에서는 에이전트 변경이 Jira 티켓, 보안 승인, 테스트 데이터, shadow run, rollback과 연결돼야 합니다. 플랫폼이 이 연결을 어디까지 열어 주는지가 중요합니다.

셋째는 "trace가 사람의 책임 소재를 설명하는가"입니다. 에이전트 trace는 단순한 디버깅 로그가 아닙니다. 누가 승인했고, 어떤 정책이 적용됐고, 어떤 도구가 어떤 입력으로 호출됐고, 어떤 외부 시스템이 바뀌었는지를 남겨야 합니다. 특히 규제 산업에서는 "모델이 그렇게 판단했다"는 답이 통하지 않습니다.

넷째는 "Microsoft 밖 경로가 실제인가"입니다. Azure 우선 출시는 자연스러운 선택이지만, 멀티클라우드와 온프레미스가 중요한 기업은 동일 기능, 동일 정책, 동일 관측성이 다른 환경에서도 가능한지 확인해야 합니다. VentureBeat가 지적한 것처럼 독립 실행 런타임이 아직 초기 릴리스에 없는 상태라면, 이 질문은 더 중요해집니다.

커뮤니티보다 시장의 신호가 먼저 온 뉴스입니다

이번 발표는 Hacker News나 GeekNews에서 큰 기술 토론을 만든 유형의 뉴스는 아닙니다. Reddit에도 VentureBeat 기사 요약 수준의 낮은 참여 게시물이 보였을 뿐입니다. 그럼에도 이 뉴스는 볼 만합니다. 개발자 커뮤니티의 열기보다 엔터프라이즈 구매 구조가 먼저 움직이는 영역이기 때문입니다.

에이전트는 IDE와 채팅창에서 시작했지만, 기업 안으로 들어가면 계정, 권한, 감사, 배포, 비용, 운영 책임의 문제가 됩니다. 이때 승자는 가장 똑똑한 데모를 만든 팀이 아닐 수 있습니다. 에이전트가 실패했을 때 운영팀이 이해할 수 있는 산출물을 남기고, 보안팀이 정책을 걸 수 있고, 개발팀이 diff를 리뷰할 수 있고, CFO가 반복 배포의 단가를 추적할 수 있는 플랫폼이 유리해집니다.

Kore.ai Artemis는 바로 그 방향을 겨냥합니다. ABL이라는 이름이 장기적으로 표준이 될지는 아직 모릅니다. Arch가 실제로 얼마나 좋은 설계를 만들지도 검증이 필요합니다. Dual-Brain Architecture가 얼마나 강한 통제 계층인지도 데모가 아니라 운영 로그와 장애 사례에서 확인해야 합니다. 그러나 이번 발표가 던진 질문은 남습니다. 에이전트가 소프트웨어라면, 우리는 언제까지 프롬프트 묶음을 배포 단위로 취급할 수 있을까요.

답은 점점 분명해지고 있습니다. 모델은 계속 바뀝니다. 도구도 계속 바뀝니다. 그러나 기업은 실행 가능한 정의, 승인 가능한 변경, 감사 가능한 trace, 교체 가능한 모델 계층을 원합니다. Kore.ai의 Artemis는 그 요구를 정면으로 제품화한 사례입니다. 그래서 이 발표의 진짜 제목은 "새 에이전트 플랫폼 출시"가 아니라 "에이전트 런타임을 누가 소유할 것인가"에 가깝습니다.