「쓸수록 똑똑해집니다」는 AI 도입 제안서에 자주 들어가는 문장이지만, 판단 시점에만 기록할 수 있는 값 두 가지가 남아 있어야 성립합니다. 두 값은 판단 당시 확인한 운영 상태와 예상 결과입니다. 실제 결과와 원인 판정은 나중에 붙여도 되지만, 앞의 두 값은 판단과 같은 시각에 남기지 않으면 다시 얻기 어렵습니다. 기록 서식을 이 기준으로 나누면 석 달 뒤에도 그 판단을 평가할 수 있습니다.
TL;DR (핵심 요약)
기업 시스템의 작업 이력에는 판단 당시의 운영 상태와 예상 결과가 없습니다.
운영 상태와 예상 결과는 결과를 안 뒤에는 정확히 복원되지 않으므로 판단과 같은 시각에 기록하고 수정을 막습니다.
실제 결과와 원인 판정은 평가 시점에 붙입니다. 원인 판정에는 확인 단계를 표시합니다.
「쓸수록 똑똑해진다」는 판단을 평가할 기록이 있어야 성립한다
보통 이 문장은 AI가 운영 결과를 학습해 다음 판단을 개선한다는 뜻입니다. 하지만 결과를 학습하려면 먼저 판단이 예상대로 되었는지를 판정할 수 있어야 합니다. 판정 기준이 없으면 결과는 쌓이기만 합니다. 출발점은 기록입니다.
이벤트 로그 표준은 수행한 작업을 남기도록 설계되어 있다
기업 시스템이 남기는 작업 이력을 이벤트 로그라고 합니다. 표준 IEEE 1849-2023(XES)은 사례 번호, 작업 이름, 발생 시각, 수행자, 진행 단계를 항목으로 정의합니다. 이벤트 로그가 답하는 물음은 「누가 언제 어떤 작업을 수행하였는가」입니다.
프로세스 마이닝은 이 기록만으로도 원인을 찾을 수 있다고 봅니다. 셀로니스도 설명 자료에서 이벤트 로그로 프로세스를 재구성해 비효율의 근본 원인을 파악한다고 설명합니다. 업무 흐름 분석에는 맞는 말입니다. 판단 평가는 다릅니다.
판단이 맞았는지 평가하려면 로그에 없는 값 두 가지가 더 필요하다
판단 평가에 빠진 값은 판단 당시 확인한 운영 상태와 예상 결과입니다. 운영 상태는 담당자가 판단 시점에 확인한 재고, 설비 상태, 주문, 진행 중인 작업의 값입니다. '예상 결과'는 이 조치로 어떤 지표가 언제까지 어느 수준이 될지를 판단 시점에 제시한 값입니다.
설비 점검 주기를 2주에서 3주로 늘리는 판단을 가정해 보겠습니다. 담당자는 최근 석 달 불량률과 정비 대기 건수를 확인하였고, 불량률 ±0.2%p 유지와 정비 대기 시간 20% 감소를 예상하였습니다. 로그에는 입력자와 시각만 남습니다. 석 달 뒤 불량률이 0.4%p 올랐습니다. 이 수치가 예상 범위 안인지는 두 값이 있어야 판정됩니다.
운영 상태와 예상 결과는 사후에 정확히 복원되지 않는다
운영 상태와 예상 결과를 나중에 회의록이나 기억으로 채우기도 합니다. 하지만 이 방법의 한계는 실험으로 확인되었습니다.
심리학자 바루크 피쇼프는 1975년 논문에서 세 차례의 실험을 보고하였습니다. 결과를 전해 들은 사람은 그 결과의 가능성을 더 높게 평가하였고, 결과를 몰랐다면 자신이 알았을 것을 과대평가하였습니다. 이들은 그 영향을 거의 알아차리지 못하였고, 논문은 이 때문에 과거에서 배우는 능력이 제한될 수 있다고 지적합니다.
점검 주기 사례도 같습니다. 불량률 상승을 본 뒤에는 당시 예상을 「조금 오를 수 있다고 보았다」로 기억하기 쉽습니다. 그러면 예상 밖의 결과가 예상 범위 안으로 분류되고, 주기를 재검토할 근거도 사라집니다.
기록 항목은 사후 복원 가능 여부에 따라 두 구간으로 나누어 설계한다
따라서 판단 기록 서식은 나중에 복원되지 않는 값과 나중에 확인되는 값을 두 구간으로 나눕니다. 서식의 뼈대는 AI 연구에서 오래 쓰인 '상태–행동–결과'(State–Action–Outcome) 기록입니다. 상태–행동–결과 기록은 판단 당시의 상태, 선택한 조치, 실제 결과를 한 줄로 잇습니다.
항목 | 구간 | 기록 시점 | 점검 주기 사례(가정) |
|---|---|---|---|
목표 | 판단 시점 | 판단 시각 | 정비 대기 단축 |
판단 당시 운영 상태 | 판단 시점 | 판단 시각 | 최근 석 달 불량률, 정비 대기 건수 |
선택한 조치와 근거 | 판단 시점 | 판단 시각 | 주기 3주로 변경, 고장 이력 |
예상 결과 | 판단 시점 | 판단 시각 | 불량률 ±0.2%p, 석 달 뒤 평가 |
실제 결과 | 사후 | 평가 시점 | 불량률 0.4%p 상승 |
원인 판정(후보·확정)과 확인 단계 | 사후 | 평가 시점 이후 | 공급처 변경과 겹침, 원인으로 돌린 몫 |
처리 규칙은 두 가지입니다. 판단 시점 항목이 빈 판단은 평가에서 제외합니다. 나중에 채운 값에는 결과를 안 뒤의 기억이 섞이기 때문입니다. 판단 시점 항목은 수정할 수 없게 두고, 고칠 내용은 새 기록으로 추가합니다.
판단 기록 서식은 퓨처워크랩의 비즈니스 월드모델에서 예상 결과와 실제 결과를 채우는 방법입니다. 비즈니스 월드모델의 전체 구조는 별도 글에서 다룹니다.
나중에 붙이는 원인 판정에는 확인 단계를 함께 적는다
사후 항목 가운데 원인 판정은 실제 결과보다 까다롭습니다. 같은 기간에 원료 공급처도 바뀌었다면, 불량률 상승 가운데 점검 주기 몫은 집계만으로 산출되지 않습니다. 그래서 확인 단계를 함께 적습니다.
관찰한 결과는 불량률이나 납기 준수율처럼 집계하면 산출되는 값입니다. '원인으로 돌린 몫'은 그 결과 가운데 이 판단 때문이라고 보는 부분이며, 비교 기준에 대한 가정을 세워야 산출됩니다. 인과로 확인한 것은 조건을 바꾸어 비교한 뒤에 말할 수 있는 결론입니다.
인과 추론 교과서 『Causal Inference: What If』는 조치 효과를 조치하지 않은 경우와 비교해 정의하며, 한 대상에서 두 경우를 함께 관찰할 수 없다고 설명합니다. 한 라인을 두 주기로 동시에 운영할 수도 없습니다. 그래서 현장 기록은 대부분 관찰한 결과나 원인으로 돌린 몫 단계에 머물며, 단계를 밝히지 않은 원인 판정은 검증되지 않은 근거로 다음 판단에 쓰입니다.
원인 판정은 검토를 거친 뒤에 확정 칸으로 옮긴다
확인 단계를 적더라도 시스템이 원인을 자동으로 기재하면 틀린 원인도 검토 없이 누적됩니다. 지난달 납기 지연에 「공급처 지연」이 자동 기재되었다고 가정하겠습니다. 실제로는 긴급 주문으로 생산 계획을 두 차례 바꾼 영향이 더 컸을 수 있지만, 기재된 원인은 다음 달 계획의 근거로 그대로 쓰입니다.
이 때문에 자동 산출된 원인은 후보 칸에 두고, 담당자가 뒷받침하는 값이 기록에 있는지 검토한 뒤 확정 칸으로 옮깁니다. 승인 주체와 기준은 별도의 변경 통제 절차로 정합니다. 불량 원인 후보를 좁히는 방법은 머신비전 검출 이후의 원인 분석 절차에서 다룹니다.
판단 기록은 AI 모델 밖의 절차, 승인 권한, 지표, 자원 배분까지 바꾼다
확정 칸에 원인 판정이 쌓이면 바뀌는 대상은 AI 모델에 그치지 않습니다.
바뀌는 대상 | 예 |
|---|---|
절차 | 검토 단계를 합치거나 누락된 확인을 앞에 둔다 |
승인 권한 | 위험 수준별로 현장 확정 범위를 조정한다 |
지표 | 결과를 설명하지 못하는 관리 지표를 바꾼다 |
자원 배분 | 검사·정비 인력을 결과 편차가 큰 공정으로 옮긴다 |
그중 승인 권한이 가장 늦게 바뀝니다. 권한을 넓히려면 그 유형의 판단이 예상대로 되었다는 기록이 여러 차례 확인되어야 하기 때문입니다. 판단 시점 항목이 없으면 이 확인이 불가능합니다.
AX Flow는 판단 시점의 기록을 실제 결과와 연결한다
퓨처워크랩의 AX Flow는 업무를 실행할 때마다 목표, 판단 당시의 운영 상태, 판단 근거, 승인자, 예상 결과를 한 건으로 기록하고, 실제 결과가 확인되면 같은 기록에 연결합니다. 운영 상태 값은 품질관리와 생산관리, 전사자원관리 시스템의 설비 가동 상태, 주문 잔량, 재고에서 가져옵니다. 작업표준과 메일, 음성 기록도 근거로 연결됩니다.
판단 근거와 승인 기록은 나중에 수정할 수 없습니다. 기록은 고객에게 남고, 다른 고객에게는 검증을 거친 구조와 패턴만 공유됩니다.
정리하며
판단 기록의 관리 수준은 지난 분기에 내린 같은 유형의 판단 다섯 건으로 확인할 수 있습니다. 운영 상태와 예상 결과가 판단 날짜로 남아 있는 건수와, 실제 결과가 그 기록에 연결된 건수를 먼저 확인해 보시기를 권합니다. 두 조건을 모두 갖춘 기록이 한 건도 없다면 그 업무에는 AI가 결과에서 배울 기록이 아직 없는 셈입니다.
도입 상담 요청하기 · 판단 기록 서식을 어느 업무부터 적용할지 함께 검토합니다.
자주 묻는 질문 (FAQ)
이벤트 로그 외에 무엇을 더 기록하나요?
판단 당시 확인한 운영 상태와 예상 결과입니다. 이벤트 로그에는 수행한 작업만 남으므로 두 값을 판단과 같은 시각에 기록합니다.
예상 결과는 나중에 회의록으로 채우면 안 되나요?
결과를 안 뒤에는 당시의 예상을 정확히 복원하기 어렵습니다. 피쇼프의 1975년 실험에서 결과를 전해 들은 사람은 그 결과의 가능성을 더 높게 평가하였습니다.
원인 판정에 확인 단계를 적는 이유는 무엇인가요?
관찰한 결과와 원인으로 돌린 몫, 그리고 인과로 확인한 것은 요구하는 근거가 서로 다릅니다. 단계를 적지 않으면 검증되지 않은 원인이 다음 판단의 근거로 쓰입니다.
참고한 것
IEEE 1849-2023(XES)
Fischhoff(1975), 「Hindsight ≠ Foresight」
Hernán · Robins, 『Causal Inference: What If』(2020)
Celonis, 「How Does Process Mining Work?」