ProcessOS 폐쇄 베타, 에이전트가 업무 절차를 고치는 층

AI 요약

• 무슨 일: Camunda가 ProcessOS를 폐쇄 베타로 공개했습니다.
  • CamundaCon에서 발표된 새 계층은 기존 프로세스 발견, AI-native 재설계, KPI 기반 개선 제안을 묶습니다.
• 핵심 변화: 에이전트가 답변이 아니라 process, integration, decision, UI form까지 생성하는 방향입니다.
• 실무 영향: 개발자는 모델 호출보다 승인 로그, deterministic workflow, ERP/CRM 연결 경계를 더 봐야 합니다.
  • 제품은 아직 closed beta입니다. 생산성 주장보다 human-in-the-loop와 감사 가능성이 먼저 검증 대상입니다.

Camunda가 2026년 5월 20일 Amsterdam에서 열린 CamundaCon에서 ProcessOS를 발표했습니다. 이름만 보면 또 하나의 "AI 운영체제"처럼 들립니다. 하지만 이번 발표에서 볼 지점은 운영체제라는 수사가 아니라, AI 에이전트 경쟁의 무대가 모델 창과 코드 편집기를 지나 기업 업무 절차 자체로 내려왔다는 점입니다.

Camunda의 설명에 따르면 ProcessOS는 기존 Camunda agentic orchestration platform 위에 올라가는 intelligence layer입니다. 역할은 세 가지입니다. 기업 안에서 실제로 굴러가는 업무 프로세스를 발견하고, 그 프로세스를 AI-first 방식으로 다시 설계하며, 배포된 뒤에는 KPI에 맞춰 지속적으로 개선안을 제안합니다. 발표문은 이 제품이 agentic processes, integrations, data mapping, agent prompts, decisions, UI forms까지 생성하고 수정한다고 설명합니다.

이 문장은 단순한 기능 목록처럼 보이지만, 개발자와 AI 팀에는 꽤 큰 방향 전환입니다. 지금까지 많은 AI 도입은 기존 화면 옆에 챗봇을 붙이거나, 사람이 하던 일부 작업에 추천·검색·요약을 더하는 방식이었습니다. Camunda는 이것을 "task assistance" 단계로 봅니다. ProcessOS가 겨냥하는 것은 그 다음입니다. 업무 결과를 먼저 정의하고, 어떤 단계는 AI agent가 맡고, 어떤 단계는 deterministic workflow가 맡고, 어떤 단계는 사람이 승인해야 하는지 다시 짜는 계층입니다.

왜 프로세스가 다음 전장인가

최근 AI 에이전트 뉴스는 대부분 실행 환경을 중심으로 움직였습니다. OpenAI와 Anthropic은 코드 실행, 파일 접근, MCP, sandbox, managed agent를 강조합니다. Google은 Gemini API와 Search, Workspace 안에서 agent 기능을 넓히고 있습니다. SAP, ServiceNow, Microsoft, UiPath는 기업 업무 시스템 안에서 에이전트를 통제하는 층을 만들고 있습니다. Honeycomb은 agent observability를 꺼냈고, AWS는 Bedrock AgentCore 쪽에서 정책과 평가를 제품화했습니다.

이 흐름의 공통점은 "모델이 똑똑하다"는 주장만으로는 기업 업무가 자동화되지 않는다는 것입니다. 에이전트가 고객 기록을 읽고, 환불을 승인하고, 보험 청구를 처리하고, 은행 업무를 넘기고, 공급망 예외를 해결하려면 단순히 API key를 주는 것으로 끝나지 않습니다. 어느 시스템에 들어갈 수 있는지, 어떤 조건에서 상태를 바꿀 수 있는지, 실패하면 어디로 되돌아가는지, 사람이 어느 순간에 승인해야 하는지, 나중에 감사인이 무엇을 볼 수 있는지가 필요합니다.

Camunda는 원래 이 영역에 가까운 회사입니다. BPMN, workflow orchestration, human task, process modeling은 AI 열풍 이전부터 존재했습니다. 흥미로운 점은 ProcessOS가 이 오래된 프로세스 계층을 AI 시대의 약점이 아니라 강점으로 다시 포장한다는 것입니다. 기존 업무 절차는 느리고 복잡하고 조직마다 다릅니다. 하지만 바로 그 이유 때문에 에이전트가 혼자 뛰어다니기 어려운 영역이기도 합니다. Camunda의 메시지는 "프로세스를 버리고 AI로 바로 간다"가 아니라 "프로세스를 AI가 이해하고 다시 쓰게 하되, 실행은 통제 가능한 오케스트레이션 안에 둔다"에 가깝습니다.

발표 내용의 핵심은 네 가지입니다

첫째, ProcessOS는 자동화 도구가 아니라 "프로세스 재설계 도구"로 제시됐습니다. 공식 제품 페이지는 ProcessOS를 Camunda platform의 intelligence layer라고 설명합니다. 네 개의 specialized agents가 process discovery, design, build/deploy, optimization을 맡는 구조입니다. 이 설명에서 중요한 단어는 "discover"와 "design"입니다. 기업 업무는 문서화된 절차와 실제 현장 절차가 다를 때가 많습니다. AI가 프로세스를 바꾸려면 먼저 실제 흐름과 예외를 알아야 합니다.

둘째, ProcessOS는 closed beta입니다. 일반 사용자가 바로 써볼 수 있는 제품이 아닙니다. 발표문은 selected enterprises를 대상으로 제공한다고 했고, 제품 페이지도 closed beta와 Process Zero engagement를 강조합니다. 그래서 이번 뉴스는 "써보니 좋다"가 아니라 "엔터프라이즈 에이전트 제품이 어떤 계층을 노리는가"로 읽어야 합니다. 데모와 실제 운영 사이에는 늘 긴 거리가 있습니다.

셋째, Camunda는 human-in-the-loop를 제품 메시지 중앙에 뒀습니다. 발표문은 "every process modification is reviewed and approved by humans before it reaches production"이라고 설명합니다. 이 대목은 중요합니다. AI 에이전트가 프로세스 개선안을 내는 것과, 그 개선안이 곧바로 고객 데이터와 돈이 오가는 프로덕션 업무에 반영되는 것은 완전히 다른 문제입니다. ProcessOS는 후자를 피하고, 사람이 승인한 뒤에만 운영 반영을 하겠다는 쪽입니다.

넷째, ProcessOS는 기존 시스템을 대체하지 않는다고 말합니다. 발표문은 ERP, CRM, core banking, claims systems 같은 기존 enterprise stack 위에서 open orchestration and intelligence layer로 작동한다고 설명합니다. 이것은 Camunda 입장에서 현실적인 포지션입니다. 은행과 보험, 제조, 공공 조직의 핵심 시스템을 AI 제품 하나가 갑자기 대체하기는 어렵습니다. 대신 에이전트가 읽고 쓰는 흐름을 중간에서 통제하는 쪽이 빠릅니다.

"AI가 프로세스를 만든다"는 말의 위험한 부분

Camunda CTO Daniel Meyer는 발표문에서 소프트웨어 개발에서 벌어진 변화가 business operations에도 온다고 말했습니다. 개발자가 모든 줄을 직접 쓰던 시대에서 AI가 더 많은 코드를 쓰는 시대로 옮겨가듯, 업무 프로세스도 자연어로 원하는 결과를 설명하면 ProcessOS가 만들고 배포하고 최적화한다는 주장입니다.

이 비유는 강력하지만, 그대로 받아들이면 위험합니다. 코드 생성과 프로세스 생성은 닮았지만 같지 않습니다. 코드가 잘못되면 테스트가 실패하거나 장애가 납니다. 물론 그것도 심각합니다. 하지만 업무 프로세스가 잘못되면 고객에게 잘못된 승인·거절·청구·환불·통지가 나갈 수 있습니다. 법적 책임과 규제 리스크가 곧바로 붙습니다. 따라서 프로세스 생성에서 중요한 것은 생성 능력보다 생성된 절차를 어떻게 검증하고 승인하느냐입니다.

Camunda가 visual process model을 강조하는 이유가 여기에 있습니다. 모델이 자연어로 "개선했습니다"라고 말하는 것만으로는 부족합니다. 어떤 단계가 AI에 의해 수행되는지, 어떤 조건에서 human task로 넘어가는지, 어떤 integration이 상태를 바꾸는지, 어떤 decision rule이 적용되는지 눈으로 볼 수 있어야 합니다. 이것이 BPMN 같은 프로세스 모델링 문화가 AI 시대에 다시 의미를 갖는 지점입니다.

또 하나의 위험은 조직 기억입니다. 제품 페이지는 ProcessOS가 organizational memory를 만든다고 설명합니다. 조직의 시스템, integration pattern, edge case, process decision을 private git repository에 축적하고, shared model training에는 쓰지 않는다고 말합니다. 이 방향은 유용합니다. 기업마다 업무 예외는 너무 다르고, 그 예외를 모르면 AI는 일반론만 말합니다. 하지만 조직 기억은 동시에 강한 종속성을 만듭니다. 프로세스, connector, approval pattern, KPI scoring model이 한 플랫폼 안에 쌓이면 나중에 플랫폼을 바꾸는 비용도 커집니다.

ProcessOS가 겨냥하는 고객은 누구인가

이번 발표는 개발자 도구라기보다 enterprise architecture 도구에 가깝습니다. 발표문은 Camunda가 700개 이상 조직, 미국 상위 10개 은행 중 9곳을 고객으로 둔다고 말합니다. 이 고객군을 보면 ProcessOS의 첫 시장이 어디인지 보입니다. 단순 SaaS 백오피스가 아니라 core banking, claims, compliance, insurance, supply chain처럼 절차가 길고 예외가 많고 책임 소재가 중요한 영역입니다.

ComputerWeekly의 보도도 비슷한 지점을 짚었습니다. CamundaCon 발표 맥락에서 안전한 customer data agent에는 높은 수준의 human approval이 필요하고 deterministic이어야 한다는 설명이 나옵니다. 이것은 AI 에이전트 도입을 둘러싼 현실적인 긴장입니다. 에이전트는 자율적이어야 가치가 커집니다. 하지만 기업 핵심 업무에서는 자율성이 커질수록 통제와 감사 비용도 커집니다. ProcessOS는 그 긴장을 "orchestration"으로 흡수하려 합니다.

이 지점에서 Camunda의 경쟁자는 LangChain이나 CrewAI 같은 개발 프레임워크만이 아닙니다. SAP은 Joule Studio와 Business Data Cloud를 통해 ERP 프로세스를 AI agent와 연결하려 합니다. ServiceNow는 IT와 운영 워크플로 안에서 AI Control Tower와 에이전트 거버넌스를 밀고 있습니다. Microsoft는 Agent 365와 Copilot Studio를 통해 조직 안의 agent inventory와 통제 평면을 만들려 합니다. UiPath는 RPA와 orchestration을 coding agent와 연결합니다.

Camunda의 차별점은 특정 업무 앱의 소유자가 아니라 프로세스 오케스트레이션 계층의 공급자라는 점입니다. 강점은 이 중립성입니다. ERP, CRM, 은행 코어, 보험 청구 시스템을 바꾸지 않고도 그 사이를 조율하는 계층이 될 수 있습니다. 약점도 같은 곳에 있습니다. SAP이나 Microsoft처럼 시스템 오브 레코드 자체를 쥐고 있지는 않습니다. 결국 고객이 Camunda를 중심 통제 계층으로 놓을 만큼 신뢰할 수 있는지, 그리고 기존 조직의 프로세스 소유자가 그 권한을 내줄지가 관건입니다.

AWS와 Bedrock AgentCore가 붙은 이유

발표문 말미에는 AWS 통합도 들어 있습니다. ProcessOS는 AWS에서 native로 실행되며 Amazon Bedrock과 Amazon Bedrock AgentCore를 foundation model, agent memory, identity, gateway services에 활용한다고 설명합니다. 또한 Amazon EKS, ECS, EC2용 production-ready reference architecture와 AWS Marketplace 제공도 언급합니다.

이 부분은 단순한 파트너 문구로 넘기기 어렵습니다. 에이전트 오케스트레이션은 결국 세 가지 자원이 필요합니다. 첫째, 모델입니다. 둘째, agent memory와 tool gateway입니다. 셋째, 기존 엔터프라이즈 시스템에 닿는 네트워크와 identity boundary입니다. AWS는 이 세 번째에서 강합니다. 많은 기업 시스템은 이미 AWS VPC, IAM, EKS, ECS, EC2 같은 경계 안에 있습니다. ProcessOS가 그 안에서 실행될 수 있으면 고객은 새로운 AI SaaS에 민감한 데이터를 그대로 보내는 부담을 줄일 수 있습니다.

하지만 이것도 자동으로 안전하다는 뜻은 아닙니다. Bedrock AgentCore와 IAM이 있어도 프로세스 설계 자체가 잘못되면 잘못된 업무가 안전하게 실행될 뿐입니다. 그래서 ProcessOS의 성패는 cloud integration보다 fitness function과 approval workflow에 달려 있습니다. 어떤 KPI를 최적화할 것인지, 그 KPI가 고객 경험·규제 준수·비용·처리 속도 사이의 균형을 제대로 담는지, 개선안이 과거 데이터에만 과적합되지 않는지 검증해야 합니다.

제품 페이지는 fitness function을 outcome goal에 대한 weighted scoring model로 설명합니다. cycle time, resolution rate, cost per case, compliance rate 같은 KPI를 가중치로 두고 process variant를 평가한다는 개념입니다. 개발자 관점에서는 이 지점이 특히 중요합니다. AI가 업무 절차를 제안할 때 "더 빠르다"는 말만으로는 부족합니다. 더 빠른 대신 compliance exception이 늘었는지, 비용을 줄이는 대신 고객 이탈이 늘었는지, 사람이 승인해야 할 위험 업무가 자동화됐는지 함께 봐야 합니다.

커뮤니티의 조용함도 신호입니다

취재 시점에 Hacker News 첫 페이지에서는 ProcessOS 토론을 찾지 못했습니다. GeekNews에도 ProcessOS 자체는 보이지 않았습니다. 대신 AI 에이전트를 위한 가상 파일시스템, Gemini 3.5 Flash, Cursor Composer 2.5 같은 개발자 친화적 주제가 올라와 있었습니다. 이것은 Camunda 발표가 중요하지 않다는 뜻이 아닙니다. 오히려 반대입니다. 엔터프라이즈 프로세스 오케스트레이션은 개발자 커뮤니티에서 즉시 뜨거운 반응을 얻기 어렵지만, 실제 도입 예산과 운영 권한이 걸린 영역입니다.

AI 에이전트가 개인 개발자의 터미널과 브라우저에서 벗어나 기업의 결재, 청구, 고객 데이터, 계약, 공급망으로 들어가면 논의의 언어도 달라집니다. prompt, context window, benchmark보다 process owner, audit trail, approval matrix, rollback, segregation of duties가 중요해집니다. ProcessOS는 바로 그 언어로 AI agent를 번역하려는 시도입니다.

물론 회의적으로 볼 이유도 많습니다. "AI가 프로세스를 발견하고 재설계한다"는 주장은 데모에서는 매력적이지만, 현실의 업무 프로세스는 문서와 시스템 로그만으로 설명되지 않습니다. 사람들은 예외 처리를 구두로 넘기고, 오래된 시스템의 제한 때문에 우회 절차를 만들고, 규정과 실제 처리 사이의 회색지대를 경험으로 메웁니다. ProcessOS가 이런 암묵지를 얼마나 정확히 포착할 수 있는지는 아직 공개 검증되지 않았습니다.

또한 closed beta라는 사실은 중요한 제한입니다. Camunda가 밝힌 고객 기반과 파트너십은 신뢰 신호지만, 제품 자체의 일반 사용성, 비용, 모델 선택권, integration 난이도, 실패 복구 방식은 더 봐야 합니다. AI 에이전트 제품에서 가장 좋은 데모는 대개 "행복한 경로"를 보여줍니다. 기업 업무에서 진짜 시험은 반대입니다. 불완전한 데이터, 충돌하는 정책, 오래된 시스템 장애, 사람이 늦게 승인하는 상황, 고객 민원이 들어온 상황에서 어떻게 멈추고 설명하고 복구하는지가 중요합니다.

개발자와 AI 팀이 지금 확인할 질문

ProcessOS 발표를 개발자 관점에서 보면, 당장 써볼 수 없는 제품이더라도 체크리스트는 남습니다. 앞으로 업무 에이전트를 만드는 팀은 모델 성능만 보지 말고 다음 질문을 해야 합니다.

첫째, 에이전트가 바꿀 수 있는 상태는 무엇이고, 바꿀 수 없는 상태는 무엇입니까. 읽기 권한과 쓰기 권한이 같은 API key에 묶여 있으면 위험합니다. 둘째, AI가 제안한 프로세스 변경은 어떤 테스트와 backtest를 거칩니까. 셋째, approval은 단순 버튼입니까, 아니면 책임 있는 사람이 변경 diff와 예상 영향을 이해할 수 있는 형태입니까. 넷째, 프로세스 실행 로그는 감사와 디버깅에 충분합니까. 다섯째, KPI는 실제 조직 목표를 반영합니까, 아니면 측정하기 쉬운 속도 지표만 최적화합니까.

이 질문들은 Camunda만의 문제가 아닙니다. 모든 enterprise agent 플랫폼이 피할 수 없는 질문입니다. 다만 Camunda는 이 질문을 프로세스 오케스트레이션이라는 오래된 문법으로 풀려고 합니다. 그 선택은 현실적입니다. AI agent의 장기 작업은 예측 불가능성을 갖고 있지만, 기업 업무는 예측 가능한 경계가 필요합니다. 두 세계를 억지로 하나로 만들기보다, agentic step과 deterministic workflow를 함께 모델링하는 쪽이 더 실용적입니다.

이번 뉴스의 의미

ProcessOS는 아직 시장의 승자를 말해주는 뉴스가 아닙니다. closed beta이고, 공개 벤치마크도 없고, 실제 고객 사례도 제한적입니다. 하지만 이 발표는 AI 에이전트 경쟁의 방향을 잘 보여줍니다. 에이전트가 더 많은 일을 하려면 더 많은 권한이 필요합니다. 더 많은 권한을 주려면 더 강한 통제, 감사, 승인, 관측성이 필요합니다. 결국 경쟁은 "누가 더 자율적인 에이전트를 만들었나"가 아니라 "누가 자율성을 업무 책임 안에 넣을 수 있나"로 이동합니다.

Camunda가 제안하는 답은 프로세스입니다. 기존 업무 절차를 낡은 것으로만 보지 않고, AI가 안전하게 행동할 수 있는 실행 지도와 책임 장부로 다시 보는 것입니다. 이 답이 실제 현장에서 얼마나 작동할지는 아직 열려 있습니다. 그러나 AI 팀이 배워야 할 신호는 선명합니다. 다음 세대의 에이전트 인프라는 모델 API wrapper가 아니라 업무 절차, 승인, 시스템 통합, 감사 로그를 함께 다루는 계층이 될 가능성이 큽니다.

그래서 ProcessOS의 진짜 뉴스 가치는 "Camunda도 AI를 한다"가 아닙니다. AI가 업무를 바꾸려면 채팅창 밖의 오래된 절차까지 바꿔야 하고, 그 절차를 바꾸는 권한은 모델보다 더 엄격한 통제를 요구한다는 점입니다. 에이전트가 기업 안에서 실제 일을 하려면, 이제 질문은 "무엇을 생성할 수 있나"에서 "무엇을 변경해도 되는가"로 바뀝니다. ProcessOS는 그 질문을 정면으로 제품화하려는 시도입니다.