ABL 6개 패턴, Kore.ai가 노린 에이전트 통제권

AI 요약

• 무슨 일: Kore.ai가 2026년 5월 21일 기업용 Agent Platform Artemis를 공개했습니다.
  • 핵심은 에이전트 제작 도구가 아니라 go-live 전 거버넌스, 관측성, 감사, 운영 제어를 강제하는 실행 기반입니다.
• 기술 축: ABL, Arch, Dual-Brain Architecture가 프롬프트 기반 자동화를 검토 가능한 설계도로 바꾸려 합니다.
  • ABL은 supervisor, delegation, handoff, fan-out, escalation, agent-to-agent federation 등 6개 orchestration pattern을 내세웁니다.
• 시장 의미: Microsoft Agent 365와 Azure 통합은 에이전트 경쟁이 모델보다 control plane과 identity로 이동했다는 신호입니다.
• 주의점: ABL 개발자 경험과 Agent 365 통합 깊이는 아직 발표·문서 중심이라 실제 고객 검증이 더 필요합니다.

Kore.ai가 2026년 5월 21일 Agent Platform Artemis edition을 발표했습니다. 표면적으로는 또 하나의 기업용 AI 에이전트 플랫폼 출시입니다. 하지만 이번 발표의 핵심은 "누가 더 쉽게 에이전트를 만들게 해주는가"가 아닙니다. Kore.ai가 밀고 있는 메시지는 에이전트를 만들기 전에 그 에이전트가 어떤 언어로 정의되고, 어떤 경로로 배포되며, 어떤 정책과 감사 체계 안에서 행동하는가입니다.

AI 에이전트 시장은 이미 prompt builder와 workflow canvas만으로 설명하기 어려운 단계로 들어섰습니다. 코딩 에이전트는 저장소를 수정하고, 사내 에이전트는 메일과 문서를 읽고, 고객 서비스 에이전트는 CRM과 결제 시스템에 접근합니다. 기업 입장에서 문제는 "에이전트가 할 수 있나"에서 "그 행동을 누가 승인했고, 어떤 권한으로 실행됐으며, 사고가 났을 때 어디까지 되감을 수 있나"로 바뀝니다. Kore.ai Artemis는 이 질문에 대해 자체 언어, AI 설계자, 결정적 실행 계층, Microsoft control plane 통합을 한 묶음으로 제시한 발표입니다.

Kore.ai는 이번 플랫폼이 Microsoft Azure에서 먼저 출시되며, 더 넓은 클라우드 지원은 추후 제공한다고 설명합니다. 특히 Microsoft Foundry, Microsoft Agent 365, Entra ID, Microsoft Graph API, Azure Bot Framework, Teams channel을 구체적으로 언급했습니다. 이 조합은 중요합니다. 기업용 에이전트가 실제 업무에 들어가려면 모델 API보다 identity, permission, channel, audit, endpoint security가 더 먼저 걸리기 때문입니다. Artemis는 에이전트 제작 플랫폼이면서 동시에 Microsoft 365 조직 안에서 관리 가능한 에이전트 공급원이 되려는 움직임입니다.

ABL은 프롬프트가 아니라 설계도라는 주장입니다

Kore.ai 발표에서 가장 눈에 띄는 단어는 Agent Blueprint Language, 줄여서 ABL입니다. 회사는 ABL을 compiled, declarative language라고 설명합니다. 에이전트, 시스템, workflow를 정의하고 검증하고 통제하는 표준 언어라는 뜻입니다. 여기서 "compiled"라는 표현은 단순한 마케팅 장식이 아닙니다. 기업이 원하는 것은 자연어 프롬프트가 어딘가에 저장된 상태보다, 리뷰하고 버전 관리하고 정책 검사를 걸 수 있는 실행 설계도에 가깝습니다.

Kore.ai가 공개한 ABL의 built-in orchestration pattern은 여섯 가지입니다. supervisor, delegation, handoff, fan-out, escalation, agent-to-agent federation입니다. 이름만 보면 이미 여러 agent framework에서 익숙한 구조입니다. supervisor가 작업을 나누고, delegation으로 하위 agent에 맡기며, handoff로 맥락을 넘기고, fan-out으로 병렬 조사나 작업을 실행하고, escalation으로 인간이나 더 강한 agent에 넘기고, federation으로 외부 agent와 연결합니다.

차이는 이것을 "코드나 prompt 조합"이 아니라 플랫폼 언어의 primitive로 만들려 한다는 점입니다. 개발팀이 LangGraph나 AutoGen 같은 framework에서 graph와 handler를 직접 구성할 수도 있습니다. 하지만 regulated enterprise에서는 그 graph 자체가 검토 대상이 됩니다. 어떤 agent가 어떤 tool을 호출할 수 있는지, 어느 단계에서 approval을 요구하는지, escalation 조건이 무엇인지, 실패 시 fallback이 무엇인지 문서와 코드, 정책이 서로 어긋나지 않아야 합니다. ABL은 이 간극을 줄이려는 시도로 읽힙니다.

Kore.ai의 Agent Platform 문서도 같은 방향을 보여줍니다. 문서는 플랫폼의 핵심 구성요소로 multi-agent orchestration, tools and integrations, knowledge and RAG, model hub, prompt studio, evaluation studio, safety and guardrails, analytics and observability, interaction context, agent protocol, marketplace, enterprise CI/CD, collaboration and audit, SDK를 나열합니다. 개발자에게 익숙한 요소가 많지만, 한 가지 흐름은 분명합니다. 단일 agent를 만드는 도구가 아니라 agent lifecycle 전체를 enterprise software lifecycle 안에 넣겠다는 구성입니다.

Arch는 에이전트를 만드는 에이전트입니다

두 번째 축은 Arch입니다. Kore.ai는 Arch를 AI agent architect라고 부릅니다. 비즈니스 목표를 production-ready ABL로 바꾸고, agent topology를 설계하고, lifecycle을 지원하며, production trace를 바탕으로 agent를 계속 개선한다는 설명입니다. 쉽게 말하면 사용자가 "이런 업무를 자동화하고 싶다"고 말하면, Arch가 agent 구조와 ABL을 만들고, 운영 데이터를 보며 다시 고치는 역할입니다.

이 대목은 에이전트 시장의 반복되는 역설을 보여줍니다. 기업은 AI로 업무 자동화를 만들고 싶지만, 그 자동화 자체가 점점 복잡해집니다. agent가 많아질수록 tool schema, permission, memory, retrieval, evaluation, versioning, rollback, audit이 늘어납니다. 그러면 다시 그 에이전트를 설계하고 관리하는 AI가 필요해집니다. Kore.ai의 표현을 빌리면 "AI building AI"와 "AI governing AI"입니다.

물론 여기에는 조심할 점이 있습니다. 에이전트가 에이전트를 만든다고 해서 거버넌스가 자동으로 해결되는 것은 아닙니다. 오히려 생성된 설계도를 사람이 어떻게 검토하고, policy engine이 무엇을 검증하고, production trace가 어떤 형태로 수집되고, 잘못된 자동 개선을 어떻게 막는지가 더 중요해집니다. Arch가 의미 있으려면 자연어 요구사항을 ABL로 바꾸는 능력만큼이나, 결과물을 검토 가능한 변경 단위로 남기는 능력이 필요합니다.

Kore.ai 제품 페이지는 "every agent run"을 개선 신호로 쓰고, quality, safety, cost, performance, ROI, compliance를 한곳에서 모니터링하며, Arch가 workflow, tools, prompts, orchestration 전반의 문제를 분석한다고 설명합니다. 이 메시지는 Honeycomb Agent Timeline이나 IBM Instana AI Agent and LLM Observability 같은 최근 발표와 같은 흐름에 있습니다. AI agent의 성공 조건이 모델 응답 품질에서 run-level trace, eval, cost, policy, rollback으로 확장되고 있습니다.

Dual-Brain Architecture가 겨냥한 현실

세 번째 축은 Dual-Brain Architecture입니다. Kore.ai는 두 cognitive engine이 agentic reasoning과 deterministic flows를 병렬로 운용하고, shared memory와 unified language, single runtime으로 묶인다고 설명합니다. 이 표현은 조금 추상적이지만, 문제의식은 분명합니다. 기업 업무는 LLM의 유연한 추론만으로 굴러가지 않습니다. 승인, 규칙, SLA, 개인정보 처리, 감사, 예외 처리 같은 deterministic control이 필요합니다.

많은 에이전트 데모는 LLM이 계획을 세우고 tool을 호출하는 모습을 보여줍니다. 하지만 실제 기업 업무에는 "이 고객 등급이면 이 문서를 요구해야 한다", "이 금액 이상이면 관리자 승인이 필요하다", "이 필드는 저장 전에 익명화해야 한다", "이 system of record에는 특정 역할만 쓰기 권한이 있다" 같은 규칙이 붙습니다. 이런 규칙을 prompt에만 넣으면 테스트와 감사가 어렵습니다. 규칙은 모델 바깥에서 강제되어야 합니다.

Kore.ai가 Dual-Brain을 강조하는 이유도 여기 있습니다. agentic reasoning은 사용자의 모호한 목표를 해석하고, 여러 tool과 agent를 조합하는 데 필요합니다. deterministic flow는 실행의 경계와 승인 조건을 고정합니다. 둘을 한 runtime 안에서 운용한다고 말하는 것은, 기업용 agent가 "창의적 판단"과 "규칙 기반 통제"를 동시에 가져야 한다는 주장입니다.

이 구조는 개발팀에게도 익숙한 긴장을 떠올리게 합니다. 순수 LLM agent는 빠르게 만들 수 있지만 예측 가능성이 낮습니다. 순수 workflow engine은 예측 가능하지만 모호한 업무를 다루기 어렵습니다. 기업용 AI agent 플랫폼은 결국 둘 사이의 타협을 제품화해야 합니다. Kore.ai Artemis는 그 타협을 ABL, Arch, Dual-Brain이라는 제품 언어로 포장했습니다.

Microsoft Agent 365와의 결합이 더 큰 신호입니다

Artemis 발표에서 놓치기 쉬운 부분은 Microsoft와의 결합입니다. Kore.ai는 플랫폼이 Azure stack 위에서 먼저 출시되고, Microsoft Foundry, Agent 365, Entra ID, Microsoft Graph API, Teams channel과 통합된다고 말합니다. 이는 단순한 클라우드 파트너십 이상의 의미가 있습니다. Microsoft가 2026년 5월 1일 Agent 365 일반 제공을 발표하며 제시한 문제의식과 정확히 맞닿아 있기 때문입니다.

Microsoft는 Agent 365를 agents를 observe, govern, secure하는 control plane으로 설명합니다. 발표문은 에이전트가 Microsoft Copilot과 Teams처럼 예상 가능한 곳에도 있지만, 로컬 personal AI assistant나 SaaS agent처럼 민감 데이터에 연결된 예상 밖의 곳에도 나타난다고 지적합니다. 문제는 agent sprawl입니다. 에이전트가 tool을 호출하고, 데이터에 접근하고, 다른 agent와 상호작용하면 helpful workflow가 data oversharing, tool misuse, over-privileged action으로 바뀔 수 있습니다.

이 맥락에서 Kore.ai가 Agent 365 partner라는 사실은 중요합니다. Microsoft 발표는 Agent 365가 Microsoft Copilot Studio나 Foundry로 만든 agent뿐 아니라 partner agent와 agent factory까지 관리하려 한다고 설명합니다. Kore.ai, Kasisto, n8n 같은 agent factory가 언급됩니다. 조직은 이런 partner agent를 Agent 365 control plane에서 observe, govern, secure할 수 있다고 Microsoft는 말합니다. Kore.ai Artemis는 바로 그 생태계 안에서 기업용 agent를 대량 공급하고 운영하려는 위치에 서 있습니다.

개발자 관점에서 이 변화는 agent platform의 구매 기준을 바꿉니다. 과거에는 "어떤 모델을 지원하나", "workflow builder가 쉬운가", "connector가 많은가"가 중요했습니다. 이제는 "내 조직의 identity plane과 붙는가", "endpoint와 SaaS shadow AI 탐지에 걸리는가", "Agent 365나 유사한 control plane에서 inventory와 lifecycle을 관리할 수 있는가", "감사 로그가 보안팀 언어로 남는가"가 중요해집니다. 에이전트가 많아질수록 생성 도구보다 통제 표면이 더 큰 구매 이유가 됩니다.

40개 채널과 300개 통합은 장점이자 리스크입니다

Kore.ai는 Artemis가 40개 이상의 voice and digital channels와 300개 이상의 integration을 지원한다고 발표했습니다. Microsoft A365, Salesforce, HubSpot, Jira, GitHub, core banking, healthcare, retail, telecom system 등이 언급됩니다. 이 숫자는 기업용 agent platform에서 강력한 장점입니다. 에이전트가 실제 업무를 하려면 데이터와 시스템에 붙어야 하고, 기업은 이미 여러 SaaS와 legacy system을 쓰고 있기 때문입니다.

하지만 통합 수가 늘어난다는 것은 공격 표면과 운영 표면도 커진다는 뜻입니다. agent가 GitHub issue를 읽고 Jira ticket을 수정하고 Salesforce record를 갱신하고 Teams 메시지를 보내는 순간, 장애와 권한 실수의 비용은 단일 챗봇보다 커집니다. 특히 agent-to-agent federation이 들어오면 한 agent가 다른 agent에게 업무를 넘기는 과정에서 context, 권한, 책임 소재가 흐려질 수 있습니다.

따라서 300개 통합을 볼 때는 connector 수보다 policy model을 봐야 합니다. 각 connector가 read/write 권한을 어떻게 나누는지, tool call input과 output을 어떻게 로그로 남기는지, PII tokenization이 어느 경계에서 적용되는지, agent별 권한이 사용자 delegated access인지 service principal 같은 own access인지 확인해야 합니다. Microsoft Agent 365가 delegated access와 own access agent를 구분해 설명하는 이유도 여기에 있습니다.

Kore.ai 문서는 agent를 scope, instructions, tools, knowledge 네 가지 구성요소로 설명합니다. agent를 만들기 전에는 tool-calling을 지원하는 model이 필요하며, OpenAI, Gemini, Anthropic, Azure OpenAI를 지원한다고 명시합니다. 외부 agent 연결 문서에서는 A2A Protocol과 Kore Agent Protocol 방식도 설명합니다. 이는 플랫폼이 native agent뿐 아니라 외부 agent를 orchestration 대상에 넣으려 한다는 뜻입니다. 에이전트 생태계가 커질수록 경계 정의는 더 중요해집니다.

Salesforce, ServiceNow, UiPath와도 충돌합니다

Kore.ai Artemis는 Microsoft 생태계와 강하게 묶여 있지만, 경쟁은 Microsoft 내부에서만 일어나지 않습니다. Salesforce Agentforce, ServiceNow, UiPath, IBM, AWS, Google, Docusign, Fiserv 같은 업체들이 각자의 업무 시스템 위에 agent layer를 만들고 있습니다. 차이는 어디에 주도권이 있느냐입니다.

Salesforce는 CRM 데이터와 영업·서비스 workflow를 갖고 있습니다. ServiceNow는 ITSM과 enterprise workflow의 중심에 있습니다. UiPath는 RPA와 orchestration에서 출발했습니다. Docusign은 계약서와 agreement workflow를 붙잡고 있습니다. Fiserv는 은행 코어와 결제 시스템 위에 agentOS를 얹었습니다. Kore.ai는 고객 서비스와 업무 자동화 경험, multi-channel conversational AI, enterprise integration을 기반으로 agent factory와 운영 플랫폼을 내세웁니다.

이 경쟁에서 모델은 차별화의 일부일 뿐입니다. Kore.ai도 model hub를 통해 OpenAI, Anthropic, Google, Azure OpenAI, custom model을 지원한다고 말합니다. 모델이 바뀌어도 agent blueprint, policy, integration, audit, evaluation, channel이 유지되어야 한다는 주장이 더 중요합니다. 기업은 특정 모델의 한두 달 성능 우위보다, 여러 해 동안 운영 가능한 control layer를 원합니다.

그래서 Artemis는 "모델 독립적"이라는 문구를 강조합니다. 이것은 실무적으로 의미가 있습니다. 특정 업무에는 빠르고 저렴한 모델이 맞고, 다른 업무에는 강한 reasoning model이 필요합니다. 보안 정책 때문에 일부 데이터는 특정 region이나 private cloud에서만 처리해야 할 수 있습니다. model-independent agent platform은 이런 요구를 흡수할 수 있다고 주장합니다. 하지만 실제로는 eval, prompt behavior, tool reliability가 모델마다 달라지기 때문에, 모델 교체가 완전히 공짜는 아닙니다.

개발팀은 무엇을 확인해야 하나

첫째, ABL이 실제로 얼마나 열려 있고 검토 가능한지 봐야 합니다. 선언형 언어라는 말은 좋지만, 개발자가 Git에서 diff를 보고 code review를 할 수 있는지, policy-as-code와 연결할 수 있는지, CI/CD에서 lint와 test를 돌릴 수 있는지, vendor UI 밖으로 export/import가 가능한지가 중요합니다. agent blueprint가 플랫폼 안에만 갇힌다면, compiled language라는 장점은 lock-in으로 바뀔 수 있습니다.

둘째, Arch의 자동 생성 결과를 사람과 시스템이 어떻게 검증하는지 봐야 합니다. AI가 agent topology를 만든다면, 그 결과에는 test, eval, permission review, threat modeling이 붙어야 합니다. "비즈니스 목표를 말하면 production-ready agent가 나온다"는 문구는 매력적이지만, production-ready의 기준은 회사마다 다릅니다. regulated industry에서는 문서, 승인, segregation of duties, audit retention 같은 조건이 따로 붙습니다.

셋째, observability의 깊이를 확인해야 합니다. Kore.ai는 every decision, path, outcome을 logged, traced, analyzed한다고 설명합니다. 좋은 출발점입니다. 하지만 개발팀이 필요한 것은 agent run ID, tool call span, model name, token usage, retrieval source, policy decision, human approval, downstream API response, retry loop, cost anomaly까지 이어지는 구체적 schema입니다. 단순 대화 로그는 agent observability가 아닙니다.

넷째, Microsoft Agent 365 통합이 조직의 실제 보안 운영과 어떻게 만나는지 봐야 합니다. Agent 365에서 inventory가 보이는지, Entra ID와 permission이 어떻게 연결되는지, Defender/Intune 기반 shadow AI 탐지와 어떤 관계인지, agent가 own access로 동작할 때 blast radius를 어떻게 계산하는지 확인해야 합니다. Microsoft 발표는 2026년 6월 preview로 로컬 agent context mapping과 runtime blocking을 예고했습니다. Artemis 도입도 이런 control plane의 성숙도와 함께 봐야 합니다.

다섯째, 통합 수보다 failure mode를 봐야 합니다. 300개 connector가 있다면 300개의 권한 모델, 장애 모델, rate limit, 데이터 민감도, 감사 요구가 있습니다. agent가 Jira를 수정하다 실패하면 rollback이 필요한지, Salesforce record를 갱신하기 전에 승인이 필요한지, GitHub write action은 어떤 branch policy를 따라야 하는지, 고객 데이터가 prompt에 들어갈 때 redaction이 자동인지 수동인지 확인해야 합니다.

왜 지금 기업용 에이전트 언어가 중요해졌나

LLM application의 첫 단계에서는 prompt가 제품의 중심이었습니다. 좋은 prompt, 좋은 retrieval, 좋은 UI가 중요했습니다. 이후에는 tool calling과 workflow가 붙었습니다. 이제는 prompt와 tool list만으로 agent system을 설명하기 어렵습니다. 수십 개 agent, 수백 개 tool, 여러 모델, 여러 채널, 외부 agent, human approval, compliance rule이 얽히면 자연어 설명이나 UI 캔버스만으로는 충분하지 않습니다.

이때 필요한 것이 machine-readable agent specification입니다. Kubernetes manifest가 컨테이너 운영을 선언형으로 바꿨고, Terraform이 인프라 변경을 코드 리뷰 가능한 형태로 바꿨듯, agent platform도 agent behavior와 orchestration을 검토 가능한 artifact로 만들려 합니다. ABL이 그 역할을 제대로 할 수 있을지는 아직 미지수입니다. 하지만 문제의 방향은 맞습니다. enterprise agent에는 prompt보다 강한 운영 문법이 필요합니다.

물론 모든 팀이 Kore.ai 같은 platform을 필요로 하지는 않습니다. 개발자 중심 스타트업은 open-source framework와 자체 telemetry, eval pipeline으로 충분할 수 있습니다. 고객 서비스와 contact center에 강한 기업은 Kore.ai 같은 vertical 경험을 더 가치 있게 볼 수 있습니다. Microsoft 365와 Azure에 표준화된 Global 2000 기업은 Agent 365와 Entra ID 통합을 중요하게 볼 것입니다. 선택 기준은 agent 수, 업무 리스크, 보안 조직의 관여도, 기존 Microsoft stack 의존도에 따라 달라집니다.

남은 질문은 제품 완성도입니다

Kore.ai Artemis 발표는 방향이 선명합니다. 그러나 발표만으로는 몇 가지를 판단하기 어렵습니다. ABL이 실제로 어떤 문법인지, 얼마나 expressive한지, 기존 workflow와 코드 자산을 어떻게 가져오는지, generated blueprint를 어디까지 사람이 수정할 수 있는지 공개 정보가 더 필요합니다. Arch가 production trace를 기반으로 개선한다고 할 때, 어떤 eval과 guardrail이 자동 변경을 막는지도 중요합니다.

Agent 365 통합도 마찬가지입니다. Microsoft 발표는 partner agents가 Agent 365 control plane에서 observable, governable, securable하다고 말합니다. 그러나 실제 기업 환경에서는 identity mapping, SaaS connector 권한, endpoint agent 탐지, data residency, audit retention이 복잡하게 얽힙니다. Kore.ai가 Azure first로 출시된다는 점은 Microsoft 고객에게 장점이지만, multi-cloud나 sovereign deployment를 요구하는 기업에는 세부 조건을 확인해야 합니다.

커뮤니티 반응도 아직 초기입니다. Reddit에서는 Agent 365 licensing이나 shadow AI detection 범위에 대한 실무 질문이 보이고, Artemis 자체에 대한 독립적인 사용기는 많지 않습니다. 이는 자연스럽습니다. 이런 플랫폼은 공개 데모보다 실제 enterprise rollout에서 장단점이 드러납니다. 특히 agent governance 제품은 "좋은 화면"보다 "문제 상황에서 멈추고 설명할 수 있는가"로 평가됩니다.

결론: 에이전트 플랫폼의 중심이 제작에서 통제로 이동합니다

Kore.ai Artemis가 중요한 이유는 새로운 agent builder가 하나 더 나왔기 때문이 아닙니다. ABL, Arch, Dual-Brain Architecture, Microsoft Agent 365 통합을 한 번에 밀어붙였다는 점입니다. 이것은 기업용 에이전트 시장이 프롬프트와 데모의 시대를 지나, 통제 가능한 설계도와 운영 runtime의 시대로 넘어가고 있다는 신호입니다.

개발자에게 이 뉴스는 두 가지 질문을 남깁니다. 첫째, 우리가 만드는 에이전트는 나중에 리뷰 가능한 artifact로 남는가. 둘째, 그 에이전트가 실제 시스템을 건드릴 때 identity, policy, trace, approval, rollback이 함께 움직이는가. 이 질문에 답하지 못하면 agent는 생산성 도구가 아니라 관리되지 않는 shadow automation이 됩니다.

Kore.ai의 답은 ABL과 Agent 365 쪽에 있습니다. 다른 벤더는 다른 언어와 control plane을 내놓을 것입니다. 하지만 방향은 비슷합니다. 에이전트가 많아질수록 시장은 더 쉬운 생성 화면보다 더 강한 통제권을 요구합니다. Artemis의 핵심 뉴스는 바로 그 지점입니다. 기업용 AI 에이전트 경쟁에서 다음 병목은 "만드는 속도"가 아니라 "운영할 수 있는 증거"입니다.