흐름을 설계하라 — DX의 핵심 엔진, 프로세스와 시스템 설계

들어가며: 아마존의 "2피자 팀" 명령

2002년, 아마존 CEO 제프 베조스(Jeff Bezos)는 악명 높은 사내 메모를 전 직원에게 보냈다. 핵심은 단 두 가지였다:

1. 모든 팀은 서비스 인터페이스(API)를 통해서만 데이터와 기능을 공유해야 한다.
2. 어떤 예외도 없다. 이를 어기는 사람은 해고될 것이다.

이 "API 명령(API Mandate)"은 아마존을 거대한 모놀리식 시스템에서 수천 개의 독립적 마이크로서비스로 재설계하는 출발점이 되었다. 각 서비스는 "피자 두 판으로 먹일 수 있는 크기"의 팀이 소유했고, 다른 팀과는 오직 API로만 소통했다.

핵심 요구사항은 5가지였다:

1. 모든 팀은 데이터와 기능을 서비스 인터페이스로 노출할 것
2. 팀 간 통신은 반드시 이 인터페이스를 통할 것
3. 다른 형태의 프로세스 간 통신(직접 링크, 메모리 공유 등)은 불허
4. 기술은 HTTP든 CORBA든 무관
5. 모든 서비스 인터페이스는 처음부터 외부화 가능하도록 설계할 것

이 구조가 나중에 AWS(Amazon Web Services), Fulfillment by Amazon(FBA), Amazon Alexa가 되었다. 내부 인프라를 서비스화한 것이 세계 최대 클라우드 플랫폼의 씨앗이 된 것이다. (이 메모는 2011년 구글 엔지니어 Steve Yegge가 외부에 처음 공개하면서 알려졌다.)

베조스의 메모가 말하는 본질: DX의 핵심은 기술 도입이 아니라, 일하는 방식 — 즉 프로세스와 시스템의 흐름(flow) — 을 재설계하는 것이다.

이전 글에서 우리는 "올바른 질문을 던지는 힘"이 DX의 70%를 결정한다고 했다. 문제를 정확하게 정의했다면, 다음 단계는 그 문제를 풀기 위한 흐름(flow)을 설계하는 것이다. 이 글은 DX 전문가 로드맵의 두 번째 편으로, 프로세스와 시스템 설계의 200년 역사와 2026년 최전선을 추적한다.

---

제1장: 프로세스 사고의 계보 — 스톱워치에서 BPMN까지

1911년: 프레더릭 테일러의 과학적 관리법 — 최초의 프로세스 엔지니어

현대적 의미의 "프로세스 설계"는 프레더릭 윈즐로 테일러(Frederick Winslow Taylor)에서 시작한다. 1911년 출간된 『과학적 관리법의 원리(The Principles of Scientific Management)』에서 테일러는 혁명적 주장을 했다:

"작업의 각 요소에는 과학이 있다."

테일러는 스톱워치를 들고 공장 현장에 나가, 노동자의 모든 동작을 시간 단위로 측정하고, 각 작업의 "최선의 방법(one best way)"을 찾아냈다. 삽질 동작의 최적 각도, 쉬는 시간의 최적 간격, 자재 이동의 최단 경로 — 모든 것을 데이터로 분석하고 표준화했다.

테일러리즘은 많은 비판을 받았지만(노동자를 기계 부품처럼 취급한다는 비판), 하나의 근본적 전환을 만들었다: "일은 원래 그렇게 하는 것"이라는 관행을, "일은 설계할 수 있는 것"이라는 엔지니어링으로 바꾼 것이다.

이것이 모든 프로세스 설계의 DNA다.

1950년대: 데밍과 일본의 품질 혁명 — PDCA 사이클

1950년, 미국의 통계학자 W. 에드워즈 데밍(W. Edwards Deming)이 일본에 초청된다. 당시 "Made in Japan"은 "싸고 품질 나쁜"의 동의어였다. 데밍은 일본 경영자들에게 PDCA(Plan-Do-Check-Act) 사이클을 가르쳤다.

핵심 통찰: 프로세스는 한 번 설계하고 끝나는 것이 아니라, 계속 돌려보고(Do), 측정하고(Check), 개선하는(Act) 순환 구조여야 한다.

일본 기업들은 이를 광적으로 실천했다. 도요타, 소니, 혼다 — 모두 PDCA를 조직의 DNA로 삼았다. 30년 뒤, "Made in Japan"은 세계 최고 품질의 상징이 되었다. 데밍은 일본에서 국보급 대우를 받았고, 일본 최고의 품질상은 "데밍상"으로 명명되었다.

DX에서 PDCA가 여전히 유효한 이유: 디지털 시스템은 측정이 쉽다(Check). 클릭, 처리 시간, 에러율, 전환율 — 아날로그 시대에는 스톱워치를 들고 현장에 나가야 했던 측정이, 디지털 세계에서는 자동으로 쌓인다. DX는 PDCA의 "Check" 단계를 자동화하고 가속화하는 것이다.

1988년: 도요타 생산 시스템(TPS) — 흐름의 철학

테일러가 개별 작업을 최적화했다면, 도요타 생산 시스템(Toyota Production System, TPS)은 전체 흐름을 최적화했다.

TPS의 창시자 오노 다이이치(大野耐一)는 1950년대부터 도요타 공장에서 혁명적인 시스템을 만들어갔다. 핵심 원리 두 가지:

TPS가 프로세스 설계 역사에 남긴 유산:

1. 풀(Pull) 방식: 앞 공정이 밀어내는 것(Push)이 아니라, 뒷 공정이 필요할 때 당기는 것(Pull). 이 원리가 나중에 소프트웨어의 Kanban 보드가 된다.
2. 낭비(무다) 제거: 과잉생산, 대기, 운반, 과잉가공, 재고, 동작, 불량 — 7가지 낭비를 식별하고 제거.
3. 카이젠(改善): 작은 개선을 매일, 모든 사람이, 영원히 계속한다.

1990년 MIT 연구팀이 『The Machine That Changed the World』에서 TPS를 분석한 결과는 충격적이었다. 대량 생산 방식 대비:

• 인적 투입 50% 절감
• 제조 공간 50% 절감
• 공구 투자 50% 절감
• 신제품 개발 공수 50% 절감, 개발 기간 50% 단축
• 재고 절반 이하, 불량 현저히 감소

MIT 연구진은 이 시스템이 완전히 새로운 패러다임이라 판단하고, "린 생산(lean production)"이라는 용어 자체를 만들어냈다. TPS는 이후 "린(Lean)" 방법론으로 확산되어, 제조업을 넘어 소프트웨어 개발, 스타트업 경영, 그리고 DX까지 영향을 미치게 된다.

1993년: 마이클 해머의 BPR — "파괴하고 다시 만들어라"

1993년, MIT 교수 마이클 해머(Michael Hammer)와 컨설턴트 제임스 챔피(James Champy)가 『리엔지니어링 기업 혁명(Reengineering the Corporation)』을 출간했다. 이 책은 비즈니스 서적 역사상 가장 논쟁적인 베스트셀러 중 하나가 되었다.

해머의 주장은 극단적이었다:

"기존 프로세스를 개선하지 마라. 파괴하고 처음부터 다시 설계하라."

비즈니스 프로세스 리엔지니어링(BPR)은 기존의 점진적 개선(카이젠)과 정반대의 접근이었다. 기존 프로세스를 백지 상태에서 다시 설계하여, 비용·품질·서비스·속도에서 극적인(dramatic) 개선을 이루겠다는 것이다.

BPR은 1990년대 초 열풍을 일으켰다. 포드는 회계팀을 500명에서 125명으로 줄이면서 동시에 처리 속도를 높였다. IBM 크레딧은 대출 승인 과정을 6일에서 4시간으로 단축했다.

그러나 BPR은 곧 "대량 해고의 구실"로 변질되었고, 실제로 많은 BPR 프로젝트가 실패했다(해머 자신도 나중에 "인간적 요소를 간과했다"고 인정했다). 하지만 BPR이 남긴 결정적 유산이 있다 — 프로세스를 부서 단위가 아닌 "end-to-end"로 보는 관점. DX가 부서별 시스템 도입이 아닌 전사적 흐름 재설계여야 한다는 사고의 뿌리가 여기에 있다.

2004~2011년: BPMN — 프로세스의 공통 언어

프로세스를 설계하려면 그릴 수 있어야 한다. 건축가가 도면을 그리듯, 프로세스 설계자에게도 표준 표기법이 필요했다.

BPMN(Business Process Model and Notation)은 2004년 BPMI(Business Process Management Initiative)에서 처음 발표되었고, 2011년 OMG(Object Management Group)에 의해 BPMN 2.0이 국제 표준으로 확정되었다.

BPMN의 핵심 요소:

BPMN이 DX에 중요한 이유: 프로세스를 표준 언어로 시각화하면, 비즈니스 담당자와 개발자가 같은 그림을 보고 소통할 수 있다. "이렇게 하면 되죠?" — "아뇨, 여기서 승인이 빠졌어요" — 이런 대화가 말이 아닌 다이어그램 위에서 이루어진다. Camunda, Appian, Pegasystems 같은 BPM 플랫폼은 BPMN 다이어그램을 그리면 바로 실행 가능한 워크플로가 되는 환경을 제공한다.

---

제2장: 워크플로 설계 — 사람과 시스템의 협업을 구조화하다

워크플로 자동화의 진화

워크플로(workflow)란 "일이 흘러가는 순서"를 말한다. 전표가 부서 간 이동하는 것, 결재가 상위자에게 올라가는 것, 고객 문의가 담당자에게 배분되는 것 — 모두 워크플로다.

RPA: 반복 업무의 로봇 대리인

RPA(Robotic Process Automation)는 사람이 컴퓨터에서 반복적으로 수행하는 작업 — 데이터 복사/붙여넣기, 시스템 간 데이터 전송, 보고서 작성 — 을 소프트웨어 로봇이 대신하는 기술이다.

RPA 시장은 폭발적으로 성장했다. UiPath, Automation Anywhere, Blue Prism이 시장을 이끌며, 글로벌 RPA 시장 규모는 2026년 기준 약 353억 달러로 추정된다(Precedence Research). 2035년에는 2,473억 달러에 달할 전망이며, 연평균 성장률(CAGR)은 24.2%다.

그러나 RPA에는 근본적 한계가 있다:

로우코드/노코드 — 개발자 아닌 사람도 워크플로를 만든다

2020년대의 가장 중요한 변화 중 하나: 비개발자도 워크플로를 설계하고 자동화할 수 있는 환경의 등장.

Microsoft Power Platform, Mendix, OutSystems, Retool 같은 로우코드/노코드 플랫폼은 코딩 없이 드래그 앤 드롭으로 업무 자동화를 구현할 수 있게 했다. 시장 규모는 2025년 374억 달러에서 2034년 3,769억 달러로, CAGR 29.1%로 성장할 전망이다. Gartner는 2026년까지 신규 앱의 75%가 로우코드 도구로 개발될 것으로 전망했다(2021년 40%에서 상승).

이것의 DX적 의미: 프로세스 설계의 주체가 IT 부서에서 현업 부서로 이동한다. 실제로 프로세스를 수행하는 사람이 직접 자동화를 설계하면, IT와 현업 사이의 "요구사항 전달 → 개발 → 검증 → 수정" 사이클이 극적으로 단축된다.

사례: 삼성SDS의 Nexplant — 제조 프로세스의 디지털 오케스트레이션

삼성SDS의 Nexplant는 제조 실행 시스템(MES)을 넘어 공장 전체의 프로세스를 디지털로 오케스트레이션하는 플랫폼이다. 원자재 입고부터 완제품 출하까지의 전 과정을 실시간 모니터링하고, 이상 징후를 감지하면 자동으로 후속 프로세스를 조정한다.

핵심은 "시스템을 깔았다"가 아니라 "흐름을 설계했다"는 점이다. 개별 설비의 자동화가 아닌, 설비 간·공정 간·공장 간 연결과 흐름의 최적화가 Nexplant의 가치다.

---

제3장: 이벤트 드리븐 아키텍처 — "요청하지 마, 알려줘"

요청-응답에서 이벤트 기반으로

전통적인 시스템 간 통신은 요청-응답(Request-Response) 방식이다. A 시스템이 B 시스템에 "데이터 줘"라고 요청하면, B가 응답한다. 단순하지만, 시스템이 수십 개로 늘어나면 문제가 생긴다 — A가 B를 호출하고, B가 C를 호출하고, C가 D를 호출하는 강결합(tight coupling) 사슬이 만들어진다. 하나가 죽으면 전체가 멈춘다.

이벤트 드리븐 아키텍처(Event-Driven Architecture, EDA)는 이 문제를 근본적으로 뒤집는다:

비유하자면, 요청-응답은 전화다 — 상대가 받아야 대화가 된다. 이벤트 드리븐은 방송이다 — 소식을 뿌리고, 관심 있는 사람이 알아서 듣는다.

Apache Kafka — 이벤트의 고속도로

2011년, LinkedIn에서 개발한 Apache Kafka는 이벤트 드리븐 아키텍처의 사실상 표준이 되었다. Kafka는 초당 수백만 건의 이벤트를 처리할 수 있는 분산 스트리밍 플랫폼이다.

Kafka를 사용하는 기업 목록은 곧 "세계 최대 디지털 기업 목록"과 같다:

• LinkedIn: 하루 1.1조 건 이상의 메시지 처리 — 2013년 이후 1,200배 성장
• Netflix: Apache Flink와 멀티클러스터 Kafka로 하루 수조 건 메시지 처리
• Uber: 전 세계 9,300만 승객, 350만 드라이버 데이터를 Kafka로 처리. Uber는 Kafka를 "기술 스택의 초석(cornerstone)"이라 부른다
• 카카오: 메시지, 결제, 추천 등 핵심 서비스에 Kafka 적용

Fortune 100 기업의 80% 이상, 전 세계 20,500개 이상의 기업이 Kafka를 기술 스택에 포함하고 있다.

DX에서 EDA가 중요한 이유

기업의 DX를 프로세스 관점에서 보면, 결국 "이 시스템에서 일어난 일을 저 시스템이 즉시 알아야 한다"는 요구가 대부분이다:

• 주문이 들어오면 → 재고 시스템이 즉시 반응
• 결제가 완료되면 → 배송 시스템이 즉시 시작
• 설비에 이상이 감지되면 → 유지보수 시스템이 즉시 알림
• 고객이 이탈 징후를 보이면 → CRM이 즉시 맞춤 대응

이 모든 것이 이벤트다. EDA는 이 이벤트들이 시스템 간에 자연스럽게 흘러가는 고속도로를 만드는 것이다.

---

제4장: API 경제 — 시스템을 연결하는 계약

SOAP에서 REST, 그리고 그 너머로

시스템을 연결하는 기술의 역사는 곧 API(Application Programming Interface)의 역사다.

API-First 기업들이 증명한 것

API를 제품으로 만든 기업들이 2010년대 이후 폭발적으로 성장했다:

• Stripe (2010): "7줄의 코드로 결제를 붙인다." 복잡한 결제 프로세스를 API로 추상화. 2023년 기업가치 약 500억 달러.
• Twilio (2008): 전화, 문자, 영상통화를 API로 제공. 2021년 매출 28억 달러.
• Plaid (2013): 금융 데이터 연결 API. 미국 핀테크 앱의 대부분이 Plaid를 사용.

이들의 공통점: 복잡한 프로세스를 API 하나로 단순화했다. Stripe 이전에는 결제 시스템 구축에 수개월이 걸렸다. Stripe 이후에는 7줄의 코드로 끝난다.

API 경제의 규모: 2025년 글로벌 API 관리 시장은 약 60억 달러 이상으로 추정되며, 2030년까지 150억 달러 이상으로 성장할 전망이다.

마이크로서비스 — 작게 나누고, API로 연결하다

마이크로서비스 아키텍처는 하나의 거대한 애플리케이션(모놀리스)을 작고 독립적인 서비스들로 분해하고, 서비스 간 통신을 API로 하는 구조다.

사례: Netflix의 마이크로서비스 전환

Netflix의 마이크로서비스 전환은 업계에서 가장 많이 인용되는 아키텍처 사례다.

2008년, Netflix의 단일 데이터베이스가 장애를 일으켜 3일간 DVD 배송이 중단되었다. 이 사건이 Netflix의 아키텍처 전환을 촉발했다. Netflix는 Adrian Cockcroft의 주도로 7년에 걸쳐 모놀리식 아키텍처를 1,000개 이상의 마이크로서비스로 분해했다.

각 마이크로서비스는 독립적으로 배포되고, 독립적으로 확장된다. 추천 엔진, 검색, 결제, 스트리밍, 사용자 인증 — 모두 별도 서비스다. 하나의 서비스에 장애가 발생해도, 사용자는 나머지 기능을 계속 사용할 수 있다.

Netflix는 더 나아가 "카오스 엔지니어링" 개념을 창시했다. 일부러 프로덕션 서비스를 무작위로 종료시키는 "Chaos Monkey"를 운영하여, 시스템의 회복력(resilience)을 상시 검증한다.

결과:

• 배포 주기: 수 주 → 하루 여러 번으로 단축
• 하루 20억 시간의 스트리밍 처리
• 전 세계 2.8억 명 이상의 가입자에게 중단 없는 서비스 제공

---

제5장: 실전 사례 — 프로세스 재설계가 만든 성과

사례 1: 정부24(gov.kr) — 대한민국 행정 프로세스의 DX

대한민국 정부24는 행정 프로세스 디지털화의 대표적 성공 사례다. 과거에는 주민등록등본 하나를 떼려면 동사무소에 직접 방문해야 했다. 공무원이 서류를 찾고, 복사하고, 도장을 찍는 — 수작업 프로세스였다.

정부24는 이 프로세스를 근본적으로 재설계했다:

• 시민이 온라인으로 요청 → 시스템이 DB에서 자동 조회 → 전자문서 즉시 발급
• 12,000개 이상의 정부 서비스 통합, 약 1,300개 온라인 이용 가능
• 등록 사용자 수 900만 명 이상
• 국민의 89%(약 3,700만 명)가 디지털 정부 서비스를 이용, 이용자 만족도 98%
• UN 2020 전자정부 평가에서 193개 회원국 중 덴마크에 이어 2위

또 하나의 한국 프로세스 DX 성공 사례: 나라장터(KONEPS). 공공조달 프로세스를 완전 디지털화한 결과, 연간 거래액이 2002년 36조 원에서 2019년 100조 원으로 성장했다. 공공기관 57,534개와 공급업체 434,000개가 사용하며, 전체 조달의 88%가 전자화되었다. 연간 국가 절감 효과: 약 3.2조 원.

핵심은 "종이 서류를 스캔해서 온라인에 올린 것"이 아니라는 점이다. 프로세스 자체를 재설계한 것이다 — "방문 → 신청 → 대기 → 수령"이라는 4단계 프로세스가 "클릭 → 즉시 발급"이라는 2단계로 바뀌었다.

사례 2: 도요타 → 현대차 — 풀 시스템의 디지털 진화

도요타가 만든 JIT/풀(Pull) 시스템은 현대자동차의 현대·기아 스마트 생산 시스템으로 진화했다. 현대차는 주문이 들어오면 실시간으로 생산 계획을 조정하는 주문-생산 연동 시스템을 구축했다. 딜러 네트워크의 수요 데이터가 실시간으로 공장의 생산 스케줄에 반영되며, 부품 공급업체에도 동시에 전달된다.

이것은 도요타의 "간판(Kanban)"을 디지털로 구현한 것이다. 종이 간판 대신, 이벤트 드리븐 메시지가 공급망 전체를 관통한다.

사례 3: 맥도날드 — 드라이브스루의 AI 최적화

맥도날드는 2019년 AI 스타트업 Dynamic Yield를 약 3억 달러에 인수했다. 목표: 드라이브스루 프로세스의 AI 최적화.

문제 정의: "드라이브스루에서 주문 완료까지 평균 대기 시간을 어떻게 줄일 수 있는가?"

AI가 해결한 것:

• 날씨, 시간대, 요일, 매장 주변 이벤트에 따라 메뉴 보드를 동적으로 변경
• 주문 이력 기반 업셀링 추천 (감자튀김 → 라지 사이즈 제안)
• 음성 인식을 통한 주문 자동화 시도

초기 파일럿(400개 매장) 결과:

• 드라이브스루 서비스 시간 27초 단축
• 시간당 차량 처리량 10% 향상
• 매장당 연간 추가 매출 약 6.5만 달러
• 음성 AI 주문 정확도 93% 달성, 고객 만족도 12점 상승

그러나 2024년, 맥도날드는 IBM과의 음성 AI 주문 파일럿을 종료했다 — 아이스크림에 베이컨을 추가하거나, 스위트티 9잔을 주문하는 등의 오류가 소셜 미디어에서 화제가 되었기 때문이다. 현재는 음성 인식 대신 컴퓨터 비전(카메라 기반 주문 검증)으로 전략을 전환 중이다.

프로세스 관점에서 핵심: 맥도날드는 "드라이브스루"라는 물리적 프로세스를 "데이터가 흐르는 파이프라인"으로 재해석했다. 초기 AI 음성 주문은 실패했지만, 프로세스를 데이터화하고 측정·최적화하는 접근 자체는 유효하다. 기술은 바뀌어도 프로세스 사고는 남는다.

---

제6장: 2026년 — 하이퍼오토메이션과 조합형 아키텍처

하이퍼오토메이션: Gartner가 정의한 "자동화의 끝판왕"

Gartner는 하이퍼오토메이션(Hyperautomation)을 "AI, 머신러닝, 이벤트 드리븐 아키텍처, RPA, BPM, iPaaS 등을 결합하여, 가능한 한 많은 비즈니스 프로세스를 자동화하는 접근법"으로 정의했다.

단순 RPA가 개별 태스크를 자동화한다면, 하이퍼오토메이션은 end-to-end 프로세스 전체를 자동화한다. 여기에 프로세스 마이닝, AI 의사결정, 디지털 트윈까지 결합된다.

하이퍼오토메이션 시장 규모는 2026년까지 1.04조 달러에 달할 전망이며(CAGR 11.9%), 네트워크 활동의 절반 이상을 자동화한 기업 비율은 2023년 10% 미만에서 2026년 30%로 증가할 것으로 예측된다. 대기업의 90%가 GenAI 부상 이후 하이퍼오토메이션을 핵심 전략으로 채택하고 있다.

조합형 비즈니스 (Composable Business)

Gartner가 제시한 또 하나의 핵심 개념: 조합형 비즈니스(Composable Business). 핵심 아이디어 — 비즈니스 기능을 레고 블록처럼 교체 가능한 모듈(Packaged Business Capabilities, PBC)로 만들어, 시장 변화에 따라 빠르게 재조합한다.

모놀리식 ERP 하나에 모든 것을 넣는 대신, 각 비즈니스 기능을 독립적 서비스(PBC)로 만들고 API로 연결한다. 결제 시스템을 바꾸고 싶으면 결제 PBC만 교체하면 된다. 나머지는 그대로다.

이것이 2026년 DX 프로세스 설계의 최전선이다 — 유연하게 조합 가능한 시스템 구조 위에서, AI가 프로세스를 실시간으로 최적화하는 것.

프로세스 마이닝의 폭발적 성장

1편에서도 언급했지만, 프로세스 마이닝은 2026년 DX의 핵심 도구로 부상했다. 시스템 로그에서 실제 프로세스를 자동으로 발굴하고, 병목과 비효율을 시각화하며, 개선 효과를 정량화한다.

프로세스 마이닝 시장은 2025년 25.7억 달러에서 2026년 54.5억 달러로, CAGR 34.4%의 폭발적 성장세다(Fortune Business Insights). 시장의 리더 Celonis는 시장 점유율 60%를 주장하며, 기업가치는 110~130억 달러로 추산된다. 총 누적 펀딩만 17.7억 달러. SAP, Siemens, ABB 등 글로벌 대기업의 프로세스 최적화를 지원하고 있다.

---

마무리: 흐름을 설계하는 사람이 DX를 이끈다

이 글에서 추적한 프로세스 설계의 계보를 정리한다.

115년의 역사가 말하는 한 가지:

DX 전문가의 두 번째 근육은 "흐름을 설계하는 힘"이다.

"어떤 시스템을 도입할까?"는 잘못된 질문이다. 올바른 질문은 이것이다:

• "이 업무의 흐름은 현재 어떻게 생겼는가?"
• "이 흐름에서 막히는 곳은 어디인가?"
• "이 막힘을 어떤 구조로 뚫을 수 있는가?"

시스템은 도구일 뿐이다. 흐름이 구조다. 흐름을 보고, 그리고, 재설계할 수 있는 사람 — 그것이 DX 전문가다.

다음 편에서는 이 흐름 위를 달리는 데이터 — DX의 기반인 "데이터 구조 이해"를 다룬다.

---

---

참고 자료

• Frederick W. Taylor, The Principles of Scientific Management (1911)
• W. Edwards Deming, Out of the Crisis (MIT Press, 1986)
• Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988)
• Michael Hammer & James Champy, Reengineering the Corporation (HarperBusiness, 1993)
• OMG, Business Process Model and Notation (BPMN) Version 2.0 (2011)
• Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures" (Doctoral dissertation, 2000)
• Jay Kreps, Neha Narkhede, Jun Rao, "Kafka: A Distributed Messaging System for Log Processing" (LinkedIn, 2011)
• Gartner, "Top Strategic Technology Trends: Hyperautomation" (2020~2025)