BPMN의 시대적 한계: 정적 워크플로우 설계에서 생성형 자동화로

"수동으로 그리는 다이어그램의 비효율을 넘어, LLM과 중간 표현식을 활용한 엔터프라이즈 워크플로우 생성 시대로"

✍️ 정보부자 편집장 JYLEE · 10년차 IT 엔지니어 출신 · 2026년 07월 28일

예전에 대규모 프로젝트 아키텍처를 짤 때, 현업 담당자들과 화이트보드 앞에 붙어 BPMN 다이어그램을 그렸던 기억이 납니다. 박스 하나 그리고 화살표 연결하고, “여기서 조건 분기 타면 어떻게 되죠?”라고 묻고 수정하는 과정의 무한 반복이었죠. 그런데 정작 그렇게 공들여 그린 문서가 실제 구현 단계에서 그대로 쓰이던가요? 대부분은 설계서와 코드가 따로 놀게 되고, 비즈니스 로직이 바뀌면 다이어그램 업데이트는 뒷전으로 밀리기 일쑤입니다.

이제는 사람이 일일이 박스를 그리는 ‘드로잉’의 시대가 저물고 있습니다. 전통적인 BPMN 기반의 수동 설계 방식은 현대 기업이 요구하는 변화 속도를 따라잡기에는 너무 경직되어 있고 복잡하거든요. 이제 우리는 LLM을 통해 텍스트를 실행 가능한 워크플로우로 바로 바꾸는 ‘생성형 접근법’과, 스스로 판단해 움직이는 ‘에이전틱 AI(Agentic AI)’의 유연한 추론 모델로 패러다임을 완전히 전환해야 합니다.

‘그리는’ 워크플로우에서 ‘생성하는’ 시스템으로

사실 BPMN은 비즈니스 프로세스를 명시적으로 보여주는 아주 훌륭한 그래픽 도구입니다 [7]. 하지만 문제는 이게 ‘문서화’에 너무 치중되어 있다는 점이에요. 현대의 엔터프라이즈 환경은 매주, 아니 매일 로직이 바뀝니다. 사람이 수동으로 다이어그램을 그리고 이를 다시 개발자가 코드로 옮기는 과정 자체가 거대한 병목이 되는 거죠.

그래서 최근에는 “Stop Drawing Workflows. Start Generating Them.” (워크플로우를 그리지 말고 생성하라) [1]라는 말처럼, 프로세스 묘사를 직접 실행 가능한 형태로 변환하려는 시도가 늘고 있습니다. 단순히 그림을 자동으로 그려주는 수준을 넘어, 자율적 에이전트가 생성적 추론을 통해 상황에 맞게 적응하는 ‘에이전틱 AI 워크플로우’로 진화하고 있는 겁니다 .

이제 설계자의 역할은 화살표를 연결하는 것이 아니라, 비즈니스 의도를 어떻게 정의하고 AI가 생성한 결과물을 어떻게 검증할 것인지에 집중하는 방향으로 바뀌어야 합니다.

LLM 기반 BPMN 생성의 현재와 기술적 병목

그렇다면 그냥 GPT-4 같은 최신 모델에 “우리 회사 결재 프로세스 BPMN XML로 짜줘”라고 하면 끝나는 걸까요? 저도 처음엔 그렇게 생각했는데, 실제 결과물을 보면 한숨이 나옵니다. 겉보기에는 그럴싸한 XML 코드가 나오지만, 막상 툴에 넣어보면 에러가 터지거나 논리가 엉망인 경우가 허다하거든요.

여기서 우리가 주목해야 할 기술적 병목이 몇 가지 있습니다.

첫째로, LLM은 ‘구문론적(Syntactic)’으로는 훌륭하지만 ‘의미론적(Semantic)’ 정확도는 떨어집니다. 예를 들어 생성 과정에서 논리적 불일치가 발생하는 사례가 보고되기도 합니다 [3].

둘째로, 복잡도가 올라가면 ‘환각(Hallucination)’ 현상이 나타날 수 있습니다. 중첩된 흐름이나 복잡한 의존성이 얽힌 프로세스를 생성할 때 논리적 불일치가 발생하거나 설명 가능성이 부족해질 우려가 있습니다 [2].

가장 치명적인 건 보조 요소의 누락입니다. 실제 비즈니스에서는 ‘누가(Resource)’ 이 일을 하고 ‘어떤 데이터’가 오가는지가 핵심인데, LLM 기반 도구들이 구조적 오류를 일으키거나 필수 요소를 누락 없이 표현하는 데 어려움을 겪는다는 지적이 있습니다 [5, 6]. 말 그대로 ‘뼈대’는 그리지만 ‘알맹이’를 채우지 못하는 상태인 거죠.

효율적 생성을 위한 전략: 중간 표현식(Intermediate Representation)의 도입

그럼 어떻게 해야 할까요? LLM에게 곧바로 복잡하고 엄격한 BPMN XML을 쓰라고 강요하는 건, 마치 외국어 초보자에게 바로 법률 문서를 작성하라는 것과 같습니다.

해결책은 ‘중간 단계’를 두는 것입니다. LLM이 직접 XML을 생성하게 하지 말고, 훨씬 단순한 중간 포맷(예: Graphviz DOT나 JSON)으로 먼저 출력하게 한 뒤, 이를 스크립트로 변환하는 파이프라인을 구축하는 거죠.

실제로 이러한 중간 표현식 활용 방식은 직접 XML을 생성할 때보다 효율적일 수 있다는 분석이 있습니다 [2]. 토큰 생성량이 줄어드니 비용은 낮아지고, 논리적 일관성은 높아지는 효과를 얻게 됩니다.

또한 모든 것을 거대 모델(LLM)에 맡기기보다 특정 도메인 데이터셋으로 파인튜닝된 소형 언어 모델(SLM)을 쓰는 게 훨씬 효율적일 때가 많습니다. 예를 들어 BPM 전용 데이터로 튜닝된 파인튜닝된 소형 언어 모델(SLM)이 일반적인 거대 LLM보다 더 신뢰할 수 있는 출력을 내놓는다는 분석이 있습니다 [2].

아래는 이런 파이프라인을 구현할 때 사용할 수 있는 개념적인 DOT 표현식과 변환 흐름의 예시입니다.

// LLM이 생성하는 단순화된 중간 표현식 (DOT 포맷)
// 복잡한 XML 대신 노드와 엣지 중심으로 정의하여 환각을 줄임
digraph BusinessProcess {
  rankdir=LR;
  node [shape=rectangle, style=filled, color=lightblue];

  Start [shape=circle, label="시작", color=green];
  Request [label="휴가 신청"];
  Approval [label="팀장 승인", shape=diamond, color=yellow];
  Notify [label="결과 통보"];
  End [shape=doublecircle, label="종료", color=red];

  // 워크플로우 흐름 정의
  Start -> Request;
  Request -> Approval;
  Approval -> Notify [label="승인"];
  Approval -> Request [label="반려"]; // 루프 구조 명시
  Notify -> End;
}

LLM은 위와 같이 단순한 텍스트 기반 그래프 정의서를 생성하고, 이후 Python 스크립트 등이 이를 읽어 표준 BPMN XML로 변환합니다. 이 방식이 직접 XML을 작성하는 것보다 훨씬 정확도가 높습니다.

짚고 넘어갈 한계와 고려사항

물론 장밋빛 미래만 있는 건 아닙니다. 우리가 경계해야 할 지점들이 분명히 있어요.

가장 큰 문제는 ‘결정론적(Deterministic)’ 사고의 상실입니다. 기존 규칙 기반 파이프라인은 딱딱하지만 입력이 같으면 결과가 항상 같습니다. 반면 LLM 기반 방식은 표현력은 풍부하지만 언제든 환각을 일으킬 수 있죠 [4].

또한 모델 크기에 따른 성능 격차도 무시 못 합니다. 일부 연구에 따르면 파라미터 수가 적은 소형 SLM들은 유효한 BPMN-XML 생성에 어려움을 겪는 경우가 있습니다 [4]. 즉, ‘적당히 작은’ 모델과 ‘너무 작은’ 모델 사이에는 넘어야 할 벽이 있다는 뜻입니다.

무엇보다 실제 조직의 복잡한 맥락을 반영한 검증 데이터가 턱없이 부족합니다. 실험실 환경에서는 잘 돌아가도, 실제 기업의 레거시 프로세스에 적용했을 때 재현성 문제나 평가 프레임워크 파편화로 인해 성능 측정이 까다롭다는 한계가 제기됩니다 [4].

핵심 요약

• BPMN 드로잉은 이제 문서화 도구일 뿐, 실제 실행 가능한 자동화를 위한 정답지가 아닙니다.
• 복잡한 XML을 LLM에게 직접 맡기지 마세요. ‘텍스트 $\rightarrow$ 중간 표현식(DOT/JSON) $\rightarrow$ XML’ 파이프라인을 구축하는 것이 훨씬 빠르고 정확합니다.
• 무조건 큰 모델이 정답은 아닙니다. 특정 프로세스 데이터로 튜닝된 효율적인 SLM 활용을 검토하세요.
• 생성된 결과물을 그대로 믿지 말고, 구문·실용·의미·유효성을 따지는 다각도 평가 체계 도입을 고려해야 합니다 [3].
• 이제 정적인 흐름 제어를 넘어, 상황에 따라 AI가 추론하고 결정하는 에이전틱 워크플로우로 시야를 넓혀야 할 때입니다.

설계자에서 오케스트레이터로

돌이켜보면 우리는 너무 오랜 시간 동안 박스를 그리고 화살표를 연결하는 ‘그리기 작업’에 많은 에너지를 쏟았습니다. 하지만 이제 도구의 시대가 바뀌고 있습니다. 중요한 건 “어떻게 그릴 것인가”가 아니라, “비즈니스의 의도를 어떻게 정확하게 정의하고, AI가 만든 결과물이 맞는지 어떻게 검증할 것인가”입니다.

이제 엔지니어와 아키텍트의 역할은 단순 설계자에서, AI와 협업하며 워크플로우를 지속적으로 최적화하는 ‘오케스트레이터’로 이동하고 있습니다. 명세서를 쓰는 시대에서 생성하고 최적화하는 시대로의 전환, 그 흐름에 올라타야 할 때입니다.

※ 주의사항: 본문에 제시된 AI 기반 워크플로우 생성 방식은 기술적 제언이며, 생성형 AI 특유의 환각 현상으로 인한 비즈니스 리스크가 존재할 수 있습니다. 실제 운영 환경에 적용 시에는 반드시 충분한 검증과 전문가의 검토 과정을 거치시기 바랍니다.

References

1. [medium.com] Stop Drawing Workflows. Start Generating Them. — https://medium.com/@khaledwj90/stop-drawing-workflows-start-generating-them-754bab4db7c7?source=rss——artificial_intelligence-5 2. [link.springer.com] Size matters less: how fine-tuned small LLMs excel in BPMN generation — https://link.springer.com/article/10.1186/s43067-025-00288-9 3. [arxiv.org] Assessing the Business Process Modeling Competences of Large Language Models — https://arxiv.org/html/2601.21787v2 4. [arxiv.org] Large Language Models to Enhance Business Process Modeling: Past, Present, and Future Trends — https://arxiv.org/html/2604.14034v1 5. [www.mdpi.com] Do LLMs Speak BPMN? An Evaluation of Their Process Modeling Capabilities Based on Quality Measures — https://www.mdpi.com/2079-3197/14/1/10 6. [www.preprints.org] Do LLMs Speak BPMN? An Evaluation of Their Process Modeling Capabilities Based on Quality Measures — https://www.preprints.org/manuscript/202509.2350 7. [en.wikipedia.org] Business Process Model and Notation — https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation 8. [linkedin.com] Agentic AI Workflows vs Traditional BPMN Workflows: A Paradigm Shift with … — https://www.linkedin.com/pulse/agentic-ai-workflows-vs-traditional-bpmn-paradigm-shift-chatterjee-ztizc

관련 글 추천

• https://infobuza.com/2026/07/27/20260727-vga9jo/
• https://infobuza.com/2026/07/27/20260727-gr8b62/

FAQ

전통적인 BPMN 기반 수동 설계 방식의 한계는 무엇인가요?

현대 기업이 요구하는 변화 속도를 따라잡기에 너무 경직되어 있고 복잡하며, 사람이 직접 다이어그램을 그리고 이를 다시 코드로 옮기는 과정이 거대한 병목이 되어 설계서와 실제 코드가 일치하지 않는 문제가 발생합니다.

LLM을 이용해 BPMN XML을 직접 생성할 때 발생하는 기술적 문제는 무엇인가요?

구문론적으로는 훌륭하지만 의미론적 정확도가 떨어져 논리적 불일치가 발생할 수 있고, 복잡한 프로세스에서 환각 현상이 나타나며, 리소스(누가)나 데이터와 같은 필수 보조 요소가 누락되는 구조적 오류가 발생할 수 있습니다.

LLM 기반의 효율적인 워크플로우 생성을 위한 전략은 무엇인가요?

LLM이 직접 XML을 생성하게 하지 않고, Graphviz DOT나 JSON 같은 단순한 '중간 표현식'으로 먼저 출력하게 한 뒤 이를 스크립트로 변환하는 파이프라인을 구축하는 것입니다.

거대 언어 모델(LLM)보다 소형 언어 모델(SLM)이 더 효율적인 경우가 있나요?

네, BPM 전용 데이터셋으로 파인튜닝된 소형 언어 모델(SLM)이 일반적인 거대 LLM보다 더 신뢰할 수 있는 출력을 내놓는다는 분석이 있습니다.

AI 기반 워크플로우 생성 방식 도입 시 주의해야 할 점은 무엇인가요?

LLM 특유의 환각 현상으로 인해 결정론적 사고가 상실될 수 있으며, 실제 조직의 복잡한 맥락을 반영한 검증 데이터가 부족하여 재현성 문제나 성능 측정의 어려움이 있을 수 있으므로 반드시 전문가의 검토와 충분한 검증 과정이 필요합니다.