Extracting ODRL Policies from Business Process Models: A Graph Traversal Approach to Compliance-by-Extraction

당신이 상점에 들어갈 때마다 로봇 경비원이 당신의 신분증, 쇼핑 리스트, 그리고 예산을 확인한 뒤에야 물건을 하나라도 집을 수 있게 허용하는 세상을 상상해 보십시오. 그 로봇은 단순히 추측하는 것이 아니라, 상점 주인이 작성한 엄격한 규칙 책(rulebook)을 따르고 있습니다. 디지털 세계에서 이 규칙 책은 '정책(policy)'이라고 불립니다. 이것은 컴퓨터가 무엇을 할 수 있는지, 무엇을 해야 하는지, 그리고 무엇을 엄격히 금지하는지를 알려줍니다. 오랫동안 이러한 디지털 규칙 책을 작성하는 것은 마치 한 번에 벽돌 한 장씩 쌓아 올려 마천루를 짓는 것과 같았습니다. 그것은 느리고, 인간의 실수에 취약하며, 만약 벽돌 하나를 잘못 놓으면 전체 구조가 무너질 수도 있습니다.

이제 '컴플라이언스(compliance, 준수)'라는 개념을 살펴보겠습니다. 이것은 모두가 규칙을 잘 따르고 있는지 확인한다는 뜻의 멋진 단어입니다. 비즈니스 세계에서 기업들은 자신들의 업무가 어떻게 진행되는지에 대한 지도를 그리는 데 수년을 보냅니다. 이 지도들을 '비즈니스 프로세스 모델(BPMN)'이라고 부릅니다. 이것들을 공장의 설계도나 연극의 대본이라고 생각하면 됩니다. 이 지도들은 누가, 언제, 어떤 순서로 무엇을 하는지를 보여줍니다. 과학자들이 던져온 핵심적인 질문은 이것입니다: "이미 이렇게 상세한 설계도가 있다면, 왜 우리는 규칙 책을 처음부터 다시 써야 하는가?" 설계도에는 이미 규칙들이 포함되어 있습니다. 다만 언어가 다를 뿐입니다. 이 논문은 그 설계도들을 직접 현대적인 기계 판독 가능 규칙 책으로 바꿔주는 '번역기'를 구축하는 것에 관한 내용입니다. 즉, 규칙을 두 번 쓸 필요가 없도록 만드는 것입니다.

마법의 번역기: 설계도에서 규칙으로

이 논문의 저자들인 스페인과 이탈리아의 연구팀은 디지털 탐정처럼 작동하는 영리한 파이프라인을 구축했습니다. 그들의 임무는 회사의 프로세스 맵(BPMN 파일)을 살펴보고 그 안에 숨겨진 규칙들을 자동으로 추출하여, 'ODRL'이라고 불리는 형식으로 변환하는 것입니다. ORL을 세상 어디서나 컴퓨터가 이해할 수 있는 '보편적 언어'이자 디지털 권리 및 규칙을 위한 표준이라고 생각하면 됩니다.

그들의 '탐정 작업'이 어떻게 이루어지는지 간단한 단계별로 나누어 설명하겠습니다.

1. 설계도는 이미 규칙 책이다
연구진은 프로세스 맵이 그려지는 방식 자체가 이미 일련의 규칙이라는 점을 깨달았습니다. 만약 지도가 작업자가 배송 전에 주문을 반드시 확인해야 한다고 보여준다면, 그것은 '의무(Duty)'라는 규칙입니다. 만약 지도가 특정 조건이 충려되면 작업자가 단계를 건너뛸 수 있다고 보여준다면, 그것은 '허가(Permission)'입니다. 만약 지도가 특정 사건이 발생하기 전까지 작업자가 앞으로 나아갈 수 없음을 보여준다면, 그것은 '금지(Prohibition)'입니다. 문제는 이 규칙들이 그림 속에 갇혀 있다는 것입니다. 새로운 파이프라인은 이 규칙들을 해제합니다.

2. 그래프 순회 (미로 찾기)
팀의 소프트웨어는 프로세스 맵을 미로처럼 취급합니다. 이들은 '그래프 순회(graph traversal)'라는 기술을 사용하는데, 이는 기본적으로 미로의 모든 경로를 체계적으로 걸어가며 어떤 일이 일어나는지 확인하는 방식입니다.

• '반드시 해야 함' 체크: 소프트웨어는 "만약 이 작업을 제거한다면, 프로세스가 여전히 완료될 수 있는가?"라고 묻습니다. 만약 답이 "아니오, 프로세스가 중단됩니다"라면, 그 작업은 **의무(Duty)**입니다.
• '건너뛸 수 있음' 체크: 만약 작업이 항상 선택되는 경로가 아닌 경로에 있다면, 그것은 **허가(Permission)**입니다.
• '기다림'의 규칙 (위대한 발견): 이 부분이 논문에서 정말 영리한 부분입니다. 기존 방식에서는 프로세스가 이메일이나 신호(이를 '중간 포착 이벤트'라고 함)를 기다려야 하는 경우, 이 규칙을 무시하거나 단순한 지연으로 취급하곤 했습니다. 저자들은 이것이 틀렸다고 주장합니다. 그들은 "기다리고 있다면, 신호가 도착할 때까지 앞으로 나아가는 것이 실제로 금지된 상태이다"라고 말합니다. 그래서 그들은 이 순간들을 '리프팅 제약(lifting constraint)'이 있는 **금지(Prohibitions)**로 라벨링하는 새로운 방법을 발명했습니다. 이것은 마치 특정 자동차(이벤트)가 지나갈 때만 초록불로 바뀌는 빨간불과 같습니다.

3. 출력물
미로를 다 돌고 나면, 소프트웨어는 JSON-LD라는 형식의 깔끔하고 유효한 규칙 책을 내놓습니다. 이것은 컴퓨터가 즉시 읽을 수 있는 파일입니다. 가장 좋은 점은 무엇일까요? 회사는 새로운 규칙을 단 하나도 새로 쓸 필요가 없었다는 것입니다. 소프트웨어가 이미 존재하는 지도에서 숨겨져 있던 규칙들을 그냥 뽑아냈을 뿐이기 때문입니다.

그들이 발견한 것 (그리고 발견하지 못한 것)

연구팀은 다섯 가지 서로 다른 '벤치마크' 시나리오(단순한 '물품 발송' 프로세스부터 세 명의 서로 다른 사람(풀)이 상호작용하는 복잡한 '셀프 서비스 레스토랑'까지)를 대상으로 이 번역기를 테스트했습니다.

• 성공 사례: 다섯 가지 경우 모두에서 소프트웨어는 오류 없이 지도를 규칙 책으로 변환하는 데 성공했습니다. 소프트웨어는 누가 무엇을 해야 하는지, 누가 단계를 건너뛸 수 있는지, 그리고 누가 기다려야 하는지를 정확하게 식별했습니다. 예를 들어, "신용 평가(Credit Scoring)" 시나리오에서 소프트웨어는 은행이 점수를 요청해야 하지만, 점수 서비스는 데이터가 도착할 때까지 점수를 계산할 수 없다는 것을 알아냈습니다. 또한 까다로운 '기다림' 규칙도 완벽하게 처리하여, 이벤트가 발생할 때 해제되는 금지로 라벨링했습니다.
• 한계점: 논문은 이 마법이 멈추는 지점에 대해서도 솔직하게 밝히고 있습니다.
  • 루프(Loops): 프로세스에 루프(예: 고객이 계속해서 재시도하는 경우)가 있으면 소프트웨어는 이를 단순화합니다. 루프를 하나의 '반드시 해야 할' 작업으로 취급하는데, 이는 안전하지만 '성공할 때까지 반복한다'는 미묘한 차이를 잃게 됩니다.
  • 이름(Names): 때때로 지도에 참여하는 사람(예: '은행' 또는 '직원')의 이름이 없는 경우가 있습니다. 이 경우 소프트웨어는 단순히 'Participant_1'과 같은 일반적인 라벨을 사용하는데, 이는 컴퓨터는 완벽히 이해하더라도 인간이 읽기에는 다소 어렵게 만듭니다.
  • 복잡한 타이밍: 소프트웨어는 아직 "작업 A가 작업 B가 시작되기 정확히 5분 전에 끝나야 한다"와 같은 복잡한 타이밍 규칙을 표현할 수 없습니다. 순서는 포착하지만, 정밀한 시간은 포착하지 못합니다.

이것이 왜 중요한가

이 논문은 세상의 모든 규칙 문제를 해결했다고 주장하지 않습니다. 이것이 최종적이고 완벽한 해결책이라고 말하는 것도 아닙니다. 대신, 프로세스 맵을 규칙 책으로 바꾸는 특정한 자동화 방식이 작동한다는 것을 증명합니다.

이전에는 기업이 새로운 법률(예: 데이터 프라이버시 규칙)을 준수하기 위해 전문가를 고용하여 수천 개의 정책 문서를 수동으로 작성해야 했습니다. 이는 느리고 비용이 많이 들었습니다. 만약 회사가 프로세스를 변경하면, 정책도 다시 써야 했습니다. 이 새로운 접근 방식은 만약 당신이 프로세스 맵을 변경하면, 규칙 책도 자동으로 업데이트된다는 것을 시사합니다. 이는 기업이 '하는 일'과 그들이 '따르는 규칙' 사이에 직접적이고 감사 가능한 연결 고리를 만들어냅니다.

연구진은 자신들의 방법이 표준적인 프로세스 맵에는 매우 잘 작동하지만, 복잡한 루프와 정밀한 타이밍을 다루기 위해서는 여전히 더 많은 작업이 필요하다는 점을 유념하고 있습니다. 하지만 현재로서는, 규칙들이 이미 그곳에, 눈에 띄게 숨겨진 채로 존재하며, 그것들을 해방시켜 줄 번역기를 기다리고 있다는 사실을 입증해 보였습니다. 이것은 컴플라이언스가 서류 작업의 악몽이 아니라, 우리가 업무를 설계하는 방식의 자연스러운 부산물이 되는 미래를 향한 한 걸음입니다.