AI와 비즈니스 프로세스 아키텍처: 검토와 승인을 거친 단일 기준 정보

AI assistant는 주문부터 대금 회수까지의 일반적인 흐름을 몇 초 만에 설명할 수 있습니다. 하지만 재무팀이 어떤 예외는 승인하고 다른 예외는 상위 단계로 넘기는 이유, 또는 창고에서 안전 재고 규칙을 따르지 않는 이유까지 알려주지는 못합니다. 이런 지식은 비즈니스 프로세스 아키텍처에 담겨야 하며, 기록해 두었을 때만 활용할 수 있습니다.

AI가 아키텍처 업무를 바꿀지 묻는 것은 더 이상 의미가 없습니다. 이미 바꾸고 있기 때문입니다. 중요한 것은 정의, 우선순위, 절충안, 승인처럼 우리가 직접 결정해야 할 일이 무엇인지입니다. 우리의 입장은 분명합니다. AI를 지지하지만, 사람을 더 중요하게 생각합니다. AI는 판단을 대신하는 것이 아니라 판단에 필요한 주변 업무를 줄여야 합니다.

AI와 비즈니스 프로세스 아키텍처가 서로 필요한 이유

AI가 없는 아키텍처는 검토와 검토 사이에 내용이 낡아 버리는 수작업입니다. 아키텍처가 없는 AI는 빠르고 자신감 넘치는 일반론에 그칩니다.

사람이 모든 내용을 직접 수집하고, 그려서 설명하고, 확인해야 한다면 비즈니스 프로세스 아키텍처를 최신 상태로 유지하는 데 많은 비용이 듭니다. AI는 초안을 만드는 비용과 프로세스 환경 전체를 살펴보는 비용을 낮춥니다. assistant는 추론 능력이 부족한 것이 아니라 사용자 조직의 프로세스 정보가 부족합니다. 원시 테이블만 제공하면 워크플로를 추측해야 합니다. 정리된 아키텍처를 제공하면 모델, 문서, 역할, 측정된 실제 업무를 근거로 답할 수 있습니다.

두 요소가 서로의 부족한 점을 채웁니다. 한쪽은 적용 범위를 넓히고, 다른 쪽은 사실에 근거하게 합니다. 단순히 AI에 다이어그램을 더하는 것이 아닙니다. 조직이 업무의 의미를 기록해 둔 곳에 AI를 연결하는 것입니다.

데이터에 assistant를 연결하는 것과 프로세스 지식에 연결하는 것은 다릅니다. MCP 프로세스 컨텍스트는 연결 방법을 다룹니다. 더 어려운 질문이자 이 페이지에서 다룰 내용은 assistant가 연결된 뒤 무엇을 찾게 되는가입니다. 조직의 디지털 트윈도 마찬가지입니다. 모델과 데이터는 측정 결과 및 의사결정과 연결될 때 비로소 쓸모가 생깁니다.

하나로 연결된 기준 정보는 어떤 모습일까요?

비즈니스 프로세스 아키텍처는 업무가 어떻게 진행되는지 연결된 구조로 보여줍니다. 가치 흐름, 프로세스, 하위 프로세스와 활동, 각 항목의 담당 역할과 이를 지원하는 시스템, 관련 문서와 아티팩트, 상태와 버전을 담습니다. 파일 하나가 아니라 한곳에서 관리하는 구조입니다.

계층은 사람이 정보를 찾아가는 방식이고, 연결 관계는 assistant가 정보를 탐색하는 방식입니다. 다이어그램을 모아 둔 폴더로는 프로세스가 어디에 속하는지 보여줄 수 있지만, “이 프로세스에 의존하는 것은 무엇인가요?”, “담당자는 누구인가요?”, “승인된 버전은 무엇인가요?“라는 질문에는 답하기 어렵습니다. 이런 질문에는 파일 캐비닛이 아니라 연결 구조가 필요합니다.

BPM 아키텍처, 엔터프라이즈 프로세스 아키텍처, 비즈니스 프로세스 관리 아키텍처 등 여러 이름으로 부르기도 합니다. 이름보다 중요한 것은 정보 간 연결입니다. 각 사실을 한곳에서 확인하고, “어떤 버전이 기준인가요?“라는 질문에 일관되게 답할 수 있어야 합니다.

APQC와 같은 프레임워크는 계층을 표현할 용어를 제공합니다. 하지만 사용자 조직의 프로세스와 담당자, 예외까지 정해주지는 않습니다. 이를 결정하고 기록하는 것은 조직의 몫입니다.

연결되지 않은 모델도 워크숍에서는 쓸모가 있습니다. 연결된 모델에서는 가치 흐름부터 활동까지 이어서 살펴볼 수 있고, assistant도 같은 경로를 따라 답할 수 있습니다. 그래서 정보를 계속 관리할 가치가 생깁니다.

계층, 프로세스와 상태를 하나의 연결 구조로 관리하는 프로세스 카탈로그

AI가 아키텍처 작업을 돕는 부분과 결정을 맡겨서는 안 되는 부분

AI는 답을 확인할 수 있는 작업이나 사람이 검토하고 고칠 수 있는 초안을 만드는 데 가장 유용합니다. 아키텍처 업무에는 이런 작업이 많습니다.

두 영역을 가르는 기준은 AI의 능력이 아니라 결정 권한입니다. AI가 사람보다 모델 초안을 더 잘 작성하더라도, 회사의 업무 방식을 정할 권한까지 갖는 것은 아닙니다.

실무에서는 검토가 가능한 업무를 AI에 맡기고, 담당자가 결정해야 하는 사안은 사람이 맡는 것이 좋습니다. 모델 초안, 요약, 누락된 문서 목록, 개선안은 모두 검토할 수 있습니다. 반면 승인 기준 변경, 담당자 변경, 통제 항목 폐지는 그렇지 않습니다. 이는 조직의 합의를 바꾸는 일이므로, 합의에 참여한 사람들이 결정해야 합니다.

조직 문화와 목표를 위임할 수 없는 이유

프로세스 아키텍처에는 조직의 업무 방식에 관한 결정이 기록됩니다. 이런 결정은 데이터가 아니라 전략과 문화에서 나옵니다.

두 회사가 같은 ERP에서 동일한 물량의 수주부터 수금까지 프로세스를 운영하더라도 서로 다른 아키텍처가 필요할 수 있습니다. 한 회사는 납기 약속을 지키기 위해 비용을 감수하고, 다른 회사는 수익성을 지키며 조건을 다시 협의합니다. 한 회사는 현장 관리자가 예외를 승인하고, 다른 회사는 승인을 중앙에서 처리합니다. 모델은 비슷해 보여도 적절한 결정은 다릅니다.

목표에 따라 속도, 비용, 회복탄력성, 규정 준수, 고객의 수고 중 무엇을 우선할지가 달라집니다. 문화는 의사결정 방식, 협의 대상, 예외를 허용하는 기준, 조직이 하지 않기로 한 일을 결정합니다. 이런 내용은 이벤트 로그에 담겨 있지 않고 문서에도 없는 경우가 많습니다. 실제 프로세스를 운영하는 사람들에게 남아 있습니다.

Assistant는 기록된 내용을 학습할 수 있지만, 그 내용의 근거가 된 선택에 책임을 질 수는 없습니다. 더 큰 모델을 사용한다고 해결되는 문제가 아닙니다. 책임을 지려면 이유를 설명할 사람이 필요합니다.

사람과 AI 모두 이해할 수 있게 문서화하려면 어떻게 해야 할까요?

먼저 사람이 읽기 쉽게 작성하세요. 동료에게 필요한 명확성은 assistant에게도 필요합니다. 기계 전용 문서를 따로 만들면 기존 문서와 내용이 달라질 수 있습니다.

프로세스를 열어 본 사람은 프로세스의 목적, 존재 이유, 담당자, 예외 상황과 다음에 할 일을 알고 싶어 합니다. 같은 프로세스를 읽는 assistant도 탐색 가능한 구조로 같은 정보를 확인해야 합니다. 모델은 단계와 연결 관계를 보여주고, 문서는 의미를 설명합니다. 아티팩트는 근거를 제공하고, 역할은 권한을 알려줍니다.

그래서 긴 양식보다 “적게 쓰되, 이유를 기록하는 것”이 효과적입니다. 승인 이유를 기록한 설명은 새로 합류한 동료에게도, 해당 승인을 없애도 되는지 묻는 assistant에게도 유용합니다. 다이어그램을 글로 반복하는 설명은 어느 쪽에도 도움이 되지 않습니다.

이용 경로는 세 가지지만 기준 정보는 하나입니다. Process Portal은 실제 업무를 수행하는 사람이 이용합니다. MCP 서버는 호환되는 assistant라면 사용할 수 있습니다. MCP는 개방형 표준이므로 여러 클라이언트에서 같은 연결을 사용할 수 있습니다. REST API는 데이터를 전달하거나 시뮬레이션을 실행하는 스크립트와 연동에 사용합니다. 어느 경로도 아키텍처의 별도 사본을 관리하지 않습니다.

이것이 워크플로 아키텍처의 기본 구조입니다. 정리된 기준 정보 하나를 세 가지 경로로 제공하고, 별도의 기준 정보는 만들지 않습니다. 포털은 초안을 게시하지 않으며, assistant도 초안을 읽지 않습니다.

정보가 비어 있는 곳에서 AI는 추측을 시작합니다

기록되지 않은 규칙은 중립적인 공백이 아닙니다. 모델이 그럴듯한 내용으로 채우게 됩니다.

이름을 붙이지 않은 게이트웨이는 assistant가 임의로 이름을 붙이는 의사결정이 됩니다. 역할을 지정하지 않으면 “팀”으로 뭉뚱그려집니다. 문서화되지 않은 예외는 이상적인 경로를 따른다는 가정으로 처리됩니다. 설명이 없는 프로세스는 목적이 아니라 형태를 요약합니다. assistant는 “모르겠습니다”라고 답하는 경우가 드뭅니다. 가장 가능성이 높은 답을 내놓는데, 그 답은 다른 조직의 프로세스를 바탕으로 만들어집니다.

이것이 통제의 실제 의미입니다. 알고 있는 내용은 명확히 정리하세요. 비워 둔 부분은 AI가 대신 판단하며, 확신에 찬 어조로 답할 수 있습니다.

모델 품질을 확인하면 이런 누락을 찾을 수 있습니다. 캔버스의 품질 배지에는 점수와 함께 연결되지 않은 요소, 누락된 라벨, 균형이 맞지 않는 게이트웨이, 빠진 문서나 역할이 표시됩니다. 관리자는 아키텍처 계층별로 점수에 반영할 검사를 설정할 수 있습니다. 따라서 100%는 해당 계층에서 요구하는 항목이 모두 충족되었음을 뜻합니다.

점수를 성적이 아니라 지식 정리 목록으로 보세요. 검사를 통과하지 못했다면 아직 결정하지 않았거나 기록하지 않은 사실이 있다는 뜻입니다. 가장 중요한 문제는 대개 다이어그램 오류가 아닙니다. 문서나 역할이 빠져 있으면 의도와 책임이 불분명하다는 뜻입니다. assistant가 근거를 가장 적게 확보하고 추측할 여지가 가장 큰 부분이기도 합니다. 따라서 모델 품질은 모델 작성자의 성적표라기보다 조직이 아직 결정하지 않은 사항을 보여주는 안내에 가깝습니다.

모델 품질 검사를 통해 문서가 없는 활동, 빠진 역할, 모델링 오류를 목록으로 확인할 수 있습니다

버전 관리로 통제력을 유지하세요

변경 이력이 없는 아키텍처는 기준 정보가 아닙니다. 그저 현재 누군가의 의견일 뿐입니다.

각 프로세스에는 초안, 검토 중, 승인, 폐기, 보관 등의 상태가 지정됩니다. 게시하면 버전 스냅샷이 생성되고, Process Portal에서 조회 권한이 있는 사용자는 게시된 버전을 확인합니다. 검토자는 버전 이름을 지정하고 승인과 게시를 한 번에 처리할 수 있습니다. 카탈로그에서는 최신 항목, 검토 대기 항목, 오래된 항목을 확인할 수 있습니다. 엔터프라이즈 아키텍처 거버넌스에서 검토하는 것처럼, 프로세스 아키텍처도 변경할 때마다 검토합니다. 이미 아키텍처 검토 위원회 절차가 있다면 같은 검토를 더 짧은 주기로 진행하면 됩니다.

버전 기록은 AI를 사용할 때 중요한 기능을 제공합니다. 스냅샷에 이름을 붙이고 초안과 비교해 변경 사항을 묶음별로 검토한 뒤 승인하거나 거부할 수 있습니다. 이전 상태를 복원하고 특정 버전을 게시할 수도 있습니다. 검토 결정은 당시 검토한 스냅샷과 연결되므로, 이후 편집 내용에 이전 승인이 자동으로 적용되지 않습니다.

AI에도 이 원칙을 적용합니다. assistant는 검토자가 확인하지 않은 초안이 아니라 승인되거나 게시된 버전을 기준으로 작업해야 합니다. AI의 제안은 검토할 변경 사항으로 전달되어야 하며, 편리하다는 이유만으로 자동 확정되어서는 안 됩니다. 버전은 결정한 사람과 내용을 읽는 시스템 사이의 합의입니다. 담당자, 검토 주기, 변경 승인 절차를 포함한 운영 방식은 프로세스 거버넌스에서 자세히 설명합니다.

게시 이력과 상태를 통해 조직이 승인한 프로세스 버전을 확인할 수 있습니다

아키텍처가 승인된 뒤 AI가 할 수 있는 일

정리하고 승인한 아키텍처를 제공하면 assistant는 일반적인 조언을 넘어 검증할 수 있는 업무를 수행합니다.

• 프로세스를 분석하고 개선안을 제안합니다. 제안의 근거도 함께 제공합니다.
• 문서 초안을 작성합니다. 모델과 아티팩트, 관련 프로세스를 바탕으로 활동 설명을 작성합니다.
• RACI 배정을 제안합니다. 이미 정의된 역할을 활용하고, 담당자가 검토하고 수정할 수 있습니다.
• 프로세스 환경 전반의 질문에 답합니다. 담당자가 없는 프로세스, 문서가 누락된 곳, 마지막 승인 버전 이후 변경된 내용을 확인합니다.
• 첫 모델을 생성합니다. 문서를 바탕으로 아키텍처 초안을 만든 뒤 프로세스별로 검토할 수 있습니다.
• 시뮬레이션 매개변수를 설정합니다. 제안된 변경 사항을 현재 프로세스와 비교합니다.

이 모든 작업에 결정을 맡길 만큼 assistant를 신뢰할 필요는 없습니다. 아키텍처와 승인 절차의 범위 안에서 작동하도록 하면 됩니다.

MCP 서버를 이용하면 호환되는 assistant가 관련 정보에 접근할 수 있습니다. Enterprise 요금제에서는 접근 범위가 제한된 API 키로 프로세스와 BPMN 모델, 문서, 역할과 RACI, 인력 및 조직 메타데이터, 프로세스 통계와 ProcessMind의 분석 도구를 사용할 수 있습니다. 쓰기 권한이 있는 키에서는 변경 도구도 사용할 수 있지만, 먼저 제안을 반환하고 미리보기로 실행 결과를 확인한 뒤 사람이 승인해야 적용됩니다. API 호출은 키에 연결되어 감사 로그에 기록됩니다. 데이터 세트 업로드, 데이터 매핑과 시뮬레이션은 의사결정이 아닌 운영 작업이므로 REST API에서 처리합니다.

AI Assistant도 이 방식으로 활용할 수 있습니다. 프로세스에 관한 질문에 답하고, 관련 대시보드와 모델을 근거로 제시하며, 변경 제안은 검토할 수 있도록 차이점으로 보여줍니다. 범위가 정해져 있어 유용한 것이지, 범위가 정해져 있는데도 유용한 것이 아닙니다.

에이전트도 운영 모델의 일부가 되고 있습니다. 프로세스에 따라 작업하는 assistant에는 시스템이나 역할과 마찬가지로 담당자, 범위, 아키텍처 내 위치가 필요합니다. 에이전트가 변경을 제안할 수 있다면, 아키텍처에 누가 이를 승인할 책임이 있는지 기록해야 합니다. 별도의 프레임워크를 만들지 않고도 AI 에이전트를 관리할 수 있습니다. 아키텍처가 설명하는 대상에 에이전트를 추가하면 됩니다.

처음부터 모든 일을 한꺼번에 시작하지 않으려면 어떻게 해야 할까요?

AI를 활용하기 전에 조직 전체를 아키텍처에 담을 필요는 없습니다. 실제 의사결정과 연결된 작은 범위부터 시작하면 됩니다.

1. 가치 흐름 하나와 관련 프로세스 몇 개를 선택합니다

   담당자와 측정 가능한 결과가 있고, 이미 의견이 엇갈리는 업무를 고르세요. 승인, 인계 또는 재작업 과정 하나만으로도 접근 방식을 검증할 수 있습니다.

2. 먼저 담당자와 검토자를 정합니다

   assistant를 연결하기 전에 역할과 RACI를 지정하세요. 권한이 먼저 정해져야 이를 읽을 수 있고, 아키텍처의 책임 소재도 검토자를 기준으로 명확해집니다.

3. 필요한 수준까지 문서화합니다

   각 활동에 설명과 역할, 명확한 범위를 지정하세요. 아무도 활용하지 않을 내용은 생략해도 됩니다. 완성되어도 아무도 읽지 않는 아키텍처는 또 다른 다이어그램 폴더에 불과합니다.

4. 품질 기준을 충족합니다

   라벨이나 연결, 문서가 누락된 요소를 먼저 보완하세요. 남은 문제는 결함 목록이 아니라 개선 과제로 다루세요.

5. 버전을 게시하고 assistant 하나를 연결합니다

   답을 이미 알고 있는 질문을 하고, 작업 공간의 정보와 대조하세요. 답이 맞으면 기준 정보가 잘 정리되었다는 뜻이고, 틀리면 정보가 누락되었다는 뜻입니다.

6. 정기 검토 주기를 정합니다

   모델 품질, 마지막 버전 이후의 변경 사항, AI가 제안한 개선안을 확인하세요. 각 항목을 승인하거나 거부하거나 보류하고, 이유를 기록하세요.

첫 범위에서 접근 방식을 검증하면 두 번째는 더 빠르게 진행할 수 있습니다. 아키텍처는 문서화 캠페인이 아니라 실제 의사결정에 맞춰 확장됩니다.

아키텍처는 조직의 합의입니다

AI가 도입되어도 문서화의 가치는 줄지 않습니다. 워크숍에서만 쓰이던 모델도 이제 회사의 assistant가 업무 방식을 설명할 때 근거가 됩니다.

AI를 효과적으로 활용하는 조직은 에이전트를 가장 많이 보유한 곳이 아닙니다. 지식을 명확히 기록하고, 담당자를 지정하고, 최신 상태로 유지하며, 승인하는 조직입니다. 사람이 찾아볼 수 있는 경로와 assistant가 접근할 방법도 마련되어 있습니다.

우리가 생각하는 역할 분담은 이렇습니다. AI는 정보를 읽고, 초안을 작성하고, 확인합니다. 사람은 무엇이 사실인지 결정합니다. 아키텍처는 둘 사이의 합의입니다.