프로세스의 귀환: AI 시대의 BPM은 도구가 아니라 경영 규율이다

사람, 에이전트, 로봇이 함께 일하는 기업에서 '일의 구조'를 누가, 어떻게 관리할 것인가.

"BPM 은 죽었다"는 선언이 10 년 넘게 반복되었습니다. 그러나 AI 에이전트가 실제 업무를 수행하기 시작한 지금, 기업이 가장 먼저 마주친 벽은 모델의 성능이 아니라 일의 구조가 관리되고 있지 않다는 사실이었습니다. 이 글은 왜 지금 BPM 이 도구가 아니라 경영 규율(management discipline)로 돌아와야 하는지를 정리합니다.

한 보험사가 보험금 심사 프로세스의 서류 검증 태스크를 AI 에이전트에게 이관했다고 하겠습니다. 첫 달의 성적표는 훌륭했습니다. 건당 처리 시간이 40분에서 6분으로 줄었고, 심사역들은 밀린 고액 건에 집중할 수 있었습니다. 그런데 두 달째부터 이상 신호가 잡혔습니다. 이의제기율이 조금씩 올라갔고, 추적해 보니 에이전트가 비정형 진단서의 특정 유형을 일관되게 오독하고 있었습니다.

회사는 세 달째에 배분을 다시 조정했습니다. 정형 서류는 에이전트에 남기고, 비정형·고액 건은 사람에게 되돌리되, 에이전트가 1차 요약을 붙이는 방식으로 말이죠. 그리고 다음 분기, 모델이 업그레이드되자 이 경계선은 또 움직였습니다.

이 시나리오에서 주목할 것은 실패가 아닙니다. "이 태스크는 누가 수행하는 것이 최적인가"라는 질문의 답이 계속 움직였다는 사실, 그리고 그 재조정을 가능하게 한 전제 조건입니다. 이 회사는 서류 검증이라는 태스크의 경계, 전후 의존성, 예외 경로, 주체별 성과를 명시적으로 알고 있었습니다. 즉 프로세스가 관리되고 있었습니다. 만약 이 일이 심사역들의 암묵지 속에만 존재했다면, 이관도 측정도 회수도 불가능했을 것입니다.

지금 대부분의 기업이 AI 도입에서 마주치는 진짜 문제가 이것입니다. 모델이 부족한 것이 아니라, 모델을 투입할 일의 구조가 관리되지 않고 있다는 것. 그리고 이 문제를 다루는 규율에는 이미 이름이 있습니다. BPM 입니다.

지난 10여 년간 반복된 "BPM 은 죽었다"는 선언에는 처음부터 범주 오류가 있었습니다. 죽은 것은 2000년대의 무겁고 경직된 BPMS(BPM Suite)라는 도구였고, 프로세스를 명시적으로 설계하고, 실행을 측정하고, 지속적으로 혁신하는 경영 규율로서의 BPM 은 죽은 적이 없습니다. 오히려 이름만 바꿔 살아남았습니다. 프로세스 마이닝, 하이퍼오토메이션, 오퍼레이셔널 엑설런스, 그리고 최근의 프로세스 오케스트레이션까지 — 모두 BPM 규율의 파편들입니다.

이 구분이 지금 중요한 이유는, AI 에이전트 시대의 질문이 "어떤 워크플로우 엔진을 살 것인가"가 아니라 "기업의 일(work) 자체를 어떻게 재설계하고 누구에게 배분할 것인가"이기 때문입니다. 이것은 도구 선택의 문제가 아니라 경영과 아키텍처의 문제입니다. BPMN 기반 도구의 활용 여부는 부차적입니다. 본질은 프로세스라는 렌즈로 기업의 일을 바라보고, 그것을 자산으로 관리하며, 끊임없이 최적화하는 규율의 복원입니다.

역사를 보면 BPM 규율은 늘 노동 구성의 대전환기에 소환되었습니다. 각 물결의 공통점은 "일을 수행하는 주체가 바뀔 때, 일의 구조를 다시 설계해야 한다"는 것이었습니다.

그리고 지금, 앞선 어떤 물결보다 근본적인 주체의 전환이 진행 중입니다.

오늘날 기업의 일은 세 종류의 수행 주체에게 배분됩니다. 판단하고 책임지는 사람, 추론하고 생성하는 AI 에이전트, 그리고 규칙적으로 반복 실행하는 로봇(소프트웨어 봇과 물리 로봇 모두)입니다. 결정적인 변화는 이것입니다. 삼자 간의 작업 배분은 한 번 정하고 끝나는 설계 결정이 아니라, 지속적으로 재최적화해야 하는 운영 변수가 되었다는 것입니다.

과거의 자동화는 정적이었습니다. RPA 봇에게 넘긴 업무는 프로세스가 바뀌기 전까지 봇의 것이었습니다. 그러나 에이전트의 역량은 분기 단위로 변합니다. 어제 사람만 할 수 있던 예외 처리를 오늘은 에이전트가 80% 정확도로, 다음 분기에는 95%로 수행합니다. 반대로 에이전트에게 맡겼다가 오류 비용이 드러나 사람에게 되돌려야 하는 업무도 생깁니다. 배분의 경계선이 살아 움직이는 것입니다.

이 동적 배분 문제를 풀려면 세 가지가 필요합니다

• 🧭 일의 구조가 명시적이어야 한다: 태스크의 단위, 순서, 의존성, 예외 경로가 암묵지로 머릿속에만 있으면 배분을 논할 대상 자체가 없습니다. 프로세스 모델은 배분 최적화의 좌표계입니다.
• 📊 수행 성과가 주체별로 측정되어야 한다: 같은 태스크를 사람이 할 때와 에이전트가 할 때의 처리 시간, 오류율, 재작업률, 비용을 비교할 수 있어야 합니다. 보험사가 이의제기율 상승을 특정 태스크의 특정 주체 문제로 짚어낼 수 있었던 것은 이 측정 체계 덕분입니다. 프로세스 마이닝과 태스크 마이닝이 여기서 증거 기반을 제공합니다.
• 🛡️ 전환 비용과 리스크가 거버넌스되어야 한다: 사람→에이전트 이관은 단순한 효율 문제가 아니라 책임소재, 감사추적, 규제 준수, 조직 역량 유지의 문제입니다. 어떤 태스크를 넘길 수 있는지, 어떤 태스크에는 반드시 인간 승인 게이트를 남겨야 하는지는 프로세스 수준에서 정의되고 버전 관리되어야 합니다.

한 문장으로 요약하면, AI 시대의 BPM 은 "이종(異種) 워크포스에 대한 지속적 작업 배분 최적화(continuous work allocation optimization)" 라는 새로운 핵심 과업을 얻었습니다. 산업공학이 공장의 인간-기계 배분을 다뤘듯, 이제 모든 지식노동 기업이 사무실의 인간-에이전트-로봇 배분을 다뤄야 합니다. 그리고 이 문제는 개별 팀이나 개별 애플리케이션 수준에서 풀 수 없습니다. 프로세스는 팀과 시스템을 가로지르기 때문입니다.

여기서 흔한 반론이 나옵니다. "BPMN 은 에이전트의 비결정적 행동을 표현하지 못한다. 그러니 프로세스 모델링은 시대에 뒤떨어졌다." 전제는 맞지만 결론이 틀렸습니다. 이 논리는 다시 한번 규율과 표기법을 혼동하고 있습니다.

BPMN 은 2000년대 중반, 사람과 시스템이 수행하는 절차적 워크플로우를 표현하기 위해 표준화된 하나의 표기법일 뿐입니다. 에이전트의 자율 구간을 표현하기 어렵다면 표기법을 바꾸거나 확장하면 됩니다. 실제로 선택지는 이미 풍부합니다. 케이스 중심 업무에는 CMMN이, 규칙과 판단에는 DMN이, "무엇을 해야 한다"가 아니라 "무엇을 하면 안 된다"만 정의하고 나머지를 열어두는 선언적(declarative) 접근에는 DCR 그래프 같은 표기가 있습니다. 에이전트의 자율 구간은 "목표와 제약, 사용 가능한 도구, 종료 조건"만 명시하고 내부 경로는 비워두는 식으로 모델링할 수 있습니다. 결정적 골격과 비결정적 자율 구간을 한 모델 안에서 혼합하는 것이 현재 업계가 수렴하는 방향입니다.

중요한 것은 표기법의 선택이 아니라 표현의 원칙입니다

• 👁️ 명시성: 일의 구조가 사람과 기계가 모두 읽을 수 있는 형태로 표현될 것
• 🔀 버전 관리: 변경 이력이 추적되고 되돌릴 수 있을 것
• 🔗 실행 연결: 실행 데이터와 연결되어 검증 가능할 것
• 🤝 공통 언어: 비즈니스와 IT 가 같은 그림을 보고 대화할 수 있을 것

이 원칙을 만족한다면 BPMN 이든, 이벤트 그래프든, 상태 머신이든, 온톨로지 기반 표현이든 무엇이라도 좋습니다. 표기법 논쟁으로 규율 자체를 기각하는 것은 "맞춤법이 불완전하니 문서 작성을 포기하자"는 논리와 같습니다.

이 지점에서 2026년의 가장 흥미로운 현상을 보겠습니다. AI 엔지니어링 커뮤니티에서 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링에 이어 그래프 엔지니어링(graph engineering)이 부상하고 있습니다. 2026년 7월, "아직도 루프 얘기를 하고 있나, 아니면 그래프로 넘어갔나"라는 한 유명 개발자의 짧은 포스트가 루프 엔지니어링 시대의 종료를 상징적으로 선언했고, 이후 담론이 폭발했습니다. 단일 에이전트의 반복 루프를 넘어, 여러 에이전트로 구성된 '조직'을 명시적 그래프로 설계하는 것이 다음 단계의 핵심 역량이라는 것입니다.

이 담론이 다루는 문제를 나열해 보면 기시감이 듭니다. 그래프 하네스는 에이전트 간 메시지 라우팅, 노드 장애 격리, 작업 그래프 전반의 상태 일관성, 어떤 노드가 어떤 순서로 실행됐는지에 대한 관측가능성을 관리합니다. 루프의 하네스는 스크립트 하나에 들어가지만 그래프의 하네스는 분산 시스템 런타임에 가깝습니다. 실무자들이 씨름하는 첫 번째 과제는 "에이전트 역할 정의 — 각 에이전트가 어떤 도메인을 소유하는가"이며, 담론은 조직 구조를 표현하는 org graph 와 일의 흐름을 표현하는 work graph 를 구분하기 시작했습니다.

노드는 태스크와 수행 주체, 엣지는 제어 흐름과 데이터 흐름, 그리고 상태 관리와 예외 처리와 실행 관측가능성. 역할 정의와 도메인 소유권, 조직 그래프와 작업 그래프의 분리 — 이것은 프로세스 모델링과 조직 모델링, 즉 BPM 이 수십 년간 다뤄온 바로 그 문제들입니다. 엔지니어들은 코드에서 출발해 상향식으로, BPM 이 경영에서 출발해 하향식으로 도달했던 동일한 지점에 도착하고 있습니다.

다만 그래프 엔지니어링을 "곧 BPM"이라고 등치하는 것은 절반만 맞습니다. 현재의 그래프 엔지니어링은 단일 시스템의 런타임 수준 규율이고, 거기에는 아직 세 가지가 없습니다.

2000년대에 BPMN 모델과 실행 엔진이 만나 BPMS 가 되었듯, 2020년대에는 프로세스 규율과 에이전트 그래프 런타임이 만나 새로운 형태의 프로세스 플랫폼이 될 것입니다. 다른 점이 있다면, 이번에는 실행 계층이 먼저 태어나 관리 계층을 기다리고 있다는 것입니다.

그렇다면 이 관리 계층은 조직 어디에 위치해야 할까요. 답은 엔터프라이즈 아키텍처(EA) 입니다. 전략과 가치흐름, 프로세스와 역할, 정보와 의미 체계, 기술과 실행을 잇는 계층 구조는 EA 가 이미 갖고 있는 골격이며, 새로 발명할 필요가 없습니다. 달라지는 것은 골격이 아니라 그 위에 올라가는 두 가지입니다.

첫째, 에이전트 레지스트리가 애플리케이션 포트폴리오급 EA 산출물로 승격된다

사람에게 직무기술서와 조직도가 있고 시스템에 애플리케이션 목록이 있듯, 에이전트에게도 공식 대장이 필요합니다. 어떤 에이전트가 존재하고, 어떤 프로세스의 어떤 태스크에 어떤 권한과 데이터 접근 범위로 투입되어 있으며, 성과와 사고 이력은 어떤가. 지금 대부분의 기업에서 에이전트는 개별 팀의 코드 저장소 안에 흩어져 있고, 전사 수준에서 "우리 회사에 에이전트가 몇 개나 일하고 있는가"에 답할 수 있는 곳이 거의 없습니다. 이 대장이 없으면 배분 최적화는 물론, 사고 발생 시의 영향 분석과 규제 대응도 불가능합니다. 여기에 프로세스가 다루는 개념의 의미 체계(온톨로지)가 결합되어야 합니다. 에이전트는 스키마가 아니라 의미로 그라운딩되어야 하며, 온톨로지는 에이전트의 오해와 환각을 막는 구조적 가드레일이기 때문입니다.

둘째, EA의 존재 이유가 통제에서 변경의 속도로 이동한다

작업 배분의 최적화는 런타임 문제이기 이전에 아키텍처 문제입니다. 태스크 단위, 권한 경계, 승인 게이트, 데이터 접근 범위가 아키텍처 수준에서 정의되어 있지 않으면, 런타임에서의 유연한 재배분은 통제 불능의 재배분이 됩니다. 반대로 아키텍처가 정의되어 있으면, 에이전트 역량이 향상될 때마다 "이 태스크의 수행 주체를 교체한다"는 결정을 낮은 리스크로, 빠르게, 반복적으로 내릴 수 있습니다. 앞의 보험사가 세 달 만에 배분을 두 번 조정할 수 있었던 것은 통제가 느슨해서가 아니라 경계가 명확해서였습니다. AI 시대의 EA 는 변화를 막는 관문이 아니라 변화를 싸게 만드는 인프라로 재정의되어야 하며, 그 재정의에 실패한 EA 조직은 이번에도 문서 생산 부서로 남을 것입니다.

반론 ① "AI가 프로세스 자체를 불필요하게 만든다"

에이전트들이 실시간으로 협상하고 조율한다면 명시적 프로세스가 왜 필요한가라는 급진론입니다. 그러나 그래프 엔지니어링의 부상 자체가 이 주장에 대한 실무의 반박입니다. 자율 주체가 늘어날수록 명시적 구조의 필요는 줄지 않고 늘었습니다. 완전한 창발적 조율은 통제 불가능한 비용과 리스크를 낳으며, 감사추적을 요구하는 규제 환경에서는 애초에 선택지가 아닙니다.

반론 ② "프로세스 모델링은 병목이다"

이 반론은 정직하게 다룰 필요가 있습니다. 흔한 재반박은 "LLM 이 문서와 로그로부터 모델 초안을 생성하고 프로세스 마이닝이 실행에서 모델을 역추출하니, 모델링 비용은 급락했다"는 것입니다. 맞는 말이지만 절반의 답입니다. 진짜 병목은 모델을 처음 그리는 비용이 아니라 모델과 현실의 정합성을 유지하는 비용이었고, 이것은 LLM 이 자동으로 해결해 주지 않습니다. 오히려 생성 비용이 급락하면 아무도 관리하지 않는 모델이 양산될 위험이 커집니다. 싸게 만든 다이어그램 백 장은 비싸게 만든 열 장보다 나쁠 수 있습니다. 따라서 결론은 "모델링이 쉬워졌으니 다 모델링하자"가 아니라, 실행 데이터와 연결되어 스스로 검증되는 모델만 만들자는 것이어야 합니다. 모델↔실행 로그의 살아있는 루프가 형성되는 곳에서는 정합성 유지가 자동화되고, 그렇지 않은 곳에서는 이번에도 죽은 문서가 쌓입니다. 병목 반론은 모델링을 포기할 이유가 아니라, 모델링의 범위를 규율할 이유입니다.

반론 ③ "EA 수준의 전사 모델링은 늘 실패해 왔다"

뼈아프게 타당합니다. 전사를 먼저 온톨로지화하고 나서 움직이려는 빅뱅 접근은 이번에도 실패할 것입니다. 처방은 범위의 절제입니다. 모호함이 비싸지는 지점 — 매출이 결정되는 프로세스, 컴플라이언스 경계, 되돌릴 수 없는 자동 실행 — 부터 명시화하고, 나머지는 실행 데이터가 쌓이는 속도에 맞춰 점진적으로 확장하는 것입니다.

정리하겠습니다. AI 시대에 BPM 을 다시 주목해야 하는 이유는 BPMN 도구가 훌륭해서가 아닙니다. 일을 수행하는 주체의 구성이 근본적으로 바뀌고 있고, 그 배분이 정적 결정에서 동적 최적화 문제로 변했으며, 이 문제를 다룰 수 있는 유일한 관리 단위가 프로세스이기 때문입니다.

엔지니어링 커뮤니티는 이미 '그래프'라는 이름으로 프로세스의 필요를 재발견했습니다. 이제 필요한 것은 그 실행 계층 위에 비즈니스 시맨틱스, 라이프사이클 거버넌스, 포트폴리오 최적화라는 관리 계층을 세우는 일이며, 그 자리는 EA 안에 있습니다. 표기법은 무엇이든 좋습니다. BPMN 이어도, 그래프여도, 온톨로지여도 좋습니다. 중요한 것은 기업의 일이 명시적 자산으로 관리되고, 사람과 에이전트와 로봇 사이의 배분이 증거에 기반해 계속 갱신되는 체계입니다.

1990년대의 BPR 이 "자동화하지 말고 재설계하라"고 외쳤다면, 2020년대의 교훈은 그 역설적 완성입니다. 재설계 없는 AI 도입은 혼란의 자동화입니다. 프로세스라는 오래된 언어가 돌아온 것이 아닙니다. 우리가 이제야, 그 언어 없이는 말할 수 없는 시대에 들어선 것입니다.

그래서 이 규율을 지금 어디서 실행할 수 있을까요. 유엔진이 20여 년간 만들어 온 uEngine6 BPM 과 그 AI 버전인 Process GPT 는 이 글이 말한 "관리 계층 + 실행 계층"을 하나의 제품 라인으로 구현한 결과물입니다. 결정적 프로세스는 BPMN·DMN 국제 표준 위에서 통제하고, 비결정적 자율 구간은 AI 에이전트에게 위임하며, 그 경계선을 언제든 다시 그을 수 있게 만드는 것 — 그것이 두 제품의 설계 원칙입니다.

uEngine6 BPM 은 여신 심사, 제조 공정, 공공 인허가처럼 명확한 규칙과 절차가 요구되는 결정적 프로세스를 클라우드 네이티브 아키텍처 위에서 실행합니다. 이벤트 기반 아키텍처로 서비스 간 의존성을 낮추고, 재시도·보상 트랜잭션·타임아웃을 모델링만으로 처리합니다. 반면 Process GPT 는 계획되지 않은 비정형 업무와 에이전트 자율 구간을 맡습니다. 한 기업 안에서 두 성격의 일이 공존하듯, 두 제품은 같은 프로세스 자산 위에서 함께 동작합니다.

규율은 제품만으로 세워지지 않습니다. 그래서 유엔진은 BPM 교육 으로 프로세스 설계·측정·개선의 방법론을 조직에 이식하고, BPM 컨설팅 으로 어느 프로세스부터 명시화할지, 어떤 태스크에 승인 게이트를 남길지를 함께 결정합니다. 실제 적용 사례는 Case Studies 에서 확인하실 수 있습니다.

프로세스가 관리되지 않는 기업에서 AI 는 혼란을 더 빨리 만들 뿐입니다. 먼저 일의 구조를 세우고, 그 위에 에이전트를 올리십시오.

함께 읽기

• AI-Native Enterprise: 성과 중심의 경영 재설계와 실행 전략
• 프롬프트를 넘어 프로세스로 — '루프 엔지니어링'과 'BPM'의 필연적 만남
• 팔란티어가 증명한 것 — 에이전틱 AI 시대, '온톨로지 플랫폼'의 자격을 묻다
• uEngine6 BPM 제품 소개
• Process GPT 제품 소개