DX 플랫폼과 AI 적용의 관계: 왜 운영 기반이 먼저인가

AI 도입 논의가 막히는 지점은 모델 성능보다 “이 결과를 누가, 어떤 자료와 대조해, 다음 업무에 반영하는가”인 경우가 많습니다. 업무 정보가 파일과 메일에 흩어져 있으면 AI는 최신 기준을 가려내기 어렵고, 담당자는 답변을 다시 확인할 수밖에 없습니다.

DX 플랫폼은 이 문제를 해결하는 운영 기반입니다. 업무 항목의 상태, 담당 역할, 승인 조건, 참조 자료와 변경 이력을 연결합니다. AI는 이 구조를 대신하는 시스템이 아니라 그 위에서 검토 준비를 빠르게 하는 보조 역할을 맡습니다.

플랫폼과 AI는 각각 어디까지 맡아야 할까요?

플랫폼은 요청을 등록하고, 담당자를 배정하고, 승인과 예외를 기록합니다. 반면 AI는 승인된 범위의 자료를 요약하거나 누락 후보를 찾아 검토 순서를 제안할 수 있습니다. 이 구분이 없으면 AI가 만든 초안이 어디서 왔는지, 누가 확정했는지 알기 어려워집니다.

예를 들어 협력사 제출 자료를 검토한다고 해봅시다. 플랫폼에는 제출 유형, 검토 기준, 보완 기한, 승인 역할이 먼저 있어야 합니다. AI가 “누락 가능성이 있는 항목”을 표시하더라도 검토자는 원문과 기준을 대조해 보완 요청 여부를 결정합니다. 이 결정과 이유가 다음 검토에서도 참조할 수 있는 이력이 됩니다.

어떤 업무 흐름부터 연결해야 할까요?

첫 단계는 자동화할 기능을 고르는 일이 아니라, 한 건의 업무가 어디서 시작해 어떤 근거로 끝나는지 확인하는 일입니다. 그다음 필요한 데이터의 출처와 접근 범위, 상태와 예외, 역할별 화면을 정리합니다. 이 구조가 작동하는 제한된 업무에서 요약·분류·검토 준비 같은 AI 보조를 붙이고, 실제 사용 결과를 보고 범위를 넓힙니다.

처음부터 모든 문서를 AI에 연결할 필요는 없습니다. 최신성이 관리되는 자료 집합과 명확한 검토 책임이 있는 업무 하나가 더 좋은 시작점입니다. 결과가 틀리거나 자료가 부족할 때 멈추고 보완하는 경로까지 설계되어야 현장 적용 후에도 통제력을 잃지 않습니다.

AI를 붙이기 전에 세 질문에 답할 수 있나요?

1. 이 업무의 최신 기준은 어디에 있고, AI가 볼 수 있는 범위는 어디까지인가?
2. AI 결과를 확인·수정·승인할 역할과 예외 처리자는 정해져 있는가?
3. 요청, 참조 자료, 결과, 후속 조치를 같은 업무 항목에서 추적할 수 있는가?

세 질문에 답할 수 있다면 AI는 별도의 실험이 아니라 운영 흐름 안의 보조 수단이 됩니다. 답이 어렵다면 먼저 플랫폼의 업무 구조를 정비하는 편이 재작업을 줄입니다.

운영 기준이 없는 자동화는 어디에서 멈출까요?

메일함에 들어온 요청을 AI가 분류해 담당자에게 전달하는 장면을 생각해 보겠습니다. 요청 유형, 담당 부서, 기한, 필요한 첨부자료가 업무 모델에 정의되어 있으면 AI는 분류 후보를 만들고 담당자는 확인만 하면 됩니다. 그러나 같은 요청이 여러 시스템에 중복 등록되거나 담당자 변경이 반영되지 않는다면, AI는 잘못된 주소나 오래된 기준으로 작업을 이어갈 수 있습니다.

이때 필요한 개선은 모델을 바꾸는 일이 아니라 업무의 기준점을 하나로 정하는 일입니다. 요청을 어디에 등록하는지, 상태가 바뀌면 어떤 시스템이 기준인지, 대리 처리와 반려를 누가 결정하는지를 먼저 연결해야 합니다. 플랫폼은 이 기준을 유지하고, AI는 그 안에서만 도움을 줍니다.

첫 적용에서는 결과를 바로 실행하지 않는 것이 좋습니다. 분류·요약 결과를 담당자의 작업 목록에 제시하고, 수정·반려된 이유를 기록합니다. 특정 유형에서 같은 수정이 반복되면 기준 자료나 업무 규칙을 고치고, 그 뒤에 AI의 적용 범위를 넓힙니다. 이 순서가 없으면 자동화는 빨라져도 오류의 확산 속도만 빨라질 수 있습니다.

협력사 보완 요청을 한 흐름으로 묶어 봅니다

다음은 가상의 제조 현장 품질팀이 협력사 문서를 받는 장면입니다. 담당자는 메일로 도착한 파일을 내려받고, 제출 기한과 양식 준수 여부를 스프레드시트에 따로 적습니다. 누락이 있으면 메일을 보내고, 회신 파일은 다시 폴더에 저장합니다. 월말에는 팀장이 “어느 업체의 어떤 항목이 멈췄는지”를 물어보지만, 답을 만들려면 메일·폴더·표를 다시 대조해야 합니다.

이 업무에 필요한 첫 변화는 대화형 AI가 아니라 하나의 요청 번호입니다. 요청에는 제출 유형, 기준일, 협력사 담당자, 필수 자료, 기한, 현재 상태를 둡니다. 문서가 오면 담당자는 요청에 연결하고, 검토자는 체크 기준별로 통과·보완·판단 보류를 남깁니다. AI는 승인된 양식과 해당 요청에 연결된 자료만 읽어 누락 후보와 이전 보완 이력을 요약합니다. 즉, AI의 답변은 독립된 결론이 아니라 검토 화면으로 들어오는 초안입니다.

여기서 역할 충돌을 미리 다뤄야 합니다. 운영 담당자는 기한을 맞추고 싶어 하지만, 품질 검토자는 기준이 불명확한 파일을 완료로 넘길 수 없습니다. 따라서 기한 임박이라는 이유만으로 상태를 변경할 수 없도록 하고, 일정 예외는 별도 사유·승인·재검토일을 남기는 편이 낫습니다. 담당자 부재 때도 단순히 계정을 공유하는 대신, 대리자의 기간과 업무 범위를 정해 기록해야 나중에 판단의 주체를 확인할 수 있습니다.

잘못된 제안이 후속 업무로 번졌다면 어떻게 복구할까요?

첫 운영 주기에 AI가 같은 자료를 서로 다른 요청에 연결하거나, 검토자가 제안된 누락 항목을 대부분 수정한다면 모델의 표현을 다듬기 전에 기준 데이터를 확인해야 합니다. 파일명 규칙이 제각각인지, 요청 상태가 실제 흐름을 반영하는지, 최신 양식이 한곳에서 관리되는지를 먼저 점검합니다. 오류가 난 결과는 삭제하지 말고 오류 유형, 참조한 자료, 검토자의 수정, 영향을 받은 후속 조치를 남깁니다. 이 기록은 다음 배포에서 제외 규칙과 검토 화면을 고치는 근거가 됩니다.

복구는 세 단계로 진행할 수 있습니다. 첫째, 잘못된 결과가 후속 상태 전환이나 외부 발송으로 이어지지 않게 해당 업무 유형의 자동 제안을 멈춥니다. 둘째, 영향을 받은 요청을 찾아 원문과 상태 이력을 대조하고 필요한 보완 요청을 다시 엽니다. 셋째, 오류가 입력 범위·업무 규칙·권한·AI 추론 중 어디서 발생했는지 분류해 수정 후 제한된 표본으로 재확인합니다. 이때 “정확도가 좋아졌다”보다 검토자가 오류를 발견하고 되돌리는 시간이 충분히 짧은지를 함께 확인해야 합니다.

플랫폼과 AI의 관계를 평가하는 월간 점검에서는 다음 네 가지를 봅니다. 기준 문서 변경이 적용 범위에 반영되는 데 걸린 시간, 사람이 수정한 제안의 유형, 예외가 시스템 밖에서 처리된 건수, 완료된 항목에서 근거를 다시 찾는 데 걸린 시간입니다. 이 지표는 특정 도구의 성능 순위가 아니라 운영 구조가 실제로 닫혀 있는지 보여줍니다.

플랫폼에 먼저 고정할 것과 바뀔 수 있게 둘 것은 무엇일까요?

모든 업무 규칙을 플랫폼에 단단히 고정하면 처음에는 일관돼 보이지만, 기준이 바뀔 때마다 개발과 배포가 필요해집니다. 반대로 상태와 권한까지 자유롭게 설정하게 두면 부서마다 같은 뜻의 흐름이 달라져 통합된 이력을 만들기 어렵습니다. 플랫폼에는 요청 식별자, 책임 역할, 결정 이력, 근거 연결처럼 업무가 달라져도 유지할 뼈대를 두고, 분류 기준·검토 항목·기한 같은 정책은 변경 책임과 적용일을 가진 설정으로 관리하는 편이 좋습니다.

AI의 지시문이나 참조 범위도 이 변경 구조 안에 들어와야 합니다. 누가 언제 무엇을 바꿨는지, 진행 중인 요청에는 이전 기준과 새 기준 중 무엇을 쓸지, 변경 뒤 어떤 표본을 확인할지 정합니다. AI 설정을 기술팀의 숨은 구성으로만 두면 업무 책임자는 결과가 달라진 이유를 설명할 수 없습니다. 반대로 모든 문구 수정을 다단계 개발 절차로 묶으면 현장의 기준 개정을 제때 반영하기 어렵습니다. 결과 영향에 따라 변경 승인 수준을 나누는 것이 필요합니다.

플랫폼이 제공해야 할 또 하나의 경계는 ‘모름’을 정상 상태로 다루는 것입니다. 자료가 없거나 서로 충돌할 때 AI가 가장 그럴듯한 답을 채우는 대신 추가 자료 요청, 판단 보류, 책임자 검토로 전환할 수 있어야 합니다. 보류 건이 계속 쌓이면 업무 책임자는 기준이 모호한지, 데이터 소유자가 응답하지 않는지, 검토 인력이 부족한지 원인을 나눠 개선합니다. 실패를 숨기지 않는 상태가 있어야 AI의 적용 범위를 책임 있게 넓힐 수 있습니다.

AI를 바꾸거나 제거해도 업무가 이어질 수 있을까요?

운영 기반의 품질은 특정 AI가 잘 작동할 때뿐 아니라 교체할 때 드러납니다. 모델이나 공급자가 바뀌어도 요청 상태, 승인 기록, 원문과 수정 이력은 플랫폼에 남아 있어야 합니다. 업무 규칙이 AI 설정 안에만 있고 결과가 대화 기록에만 저장된다면 교체 순간에 조직의 판단 맥락도 사라집니다. 핵심 결정과 증적은 독립된 업무 항목에 저장하고, AI 결과는 출처와 버전을 가진 보조 산출물로 연결해야 합니다.

교체 검증에서는 이전과 새 결과를 단순 문장 품질로 비교하지 않습니다. 같은 승인 자료와 대표·예외 요청을 사용해 누락 후보, 근거 연결, 권한 밖 처리, 판단 보류가 어떻게 달라지는지 봅니다. 차이가 있는 항목은 사람이 원문을 확인하고 사용 가능 여부를 결정합니다. 진행 중인 요청에 새 구성을 적용한다면 전환 시점과 재검토 대상을 남기며, 문제가 발견되면 이전 구성으로 되돌릴 조건도 정합니다.

AI를 잠시 중단해도 담당자가 플랫폼에서 원자료를 찾고 검토·승인·보완을 계속할 수 있어야 합니다. 속도는 느려질 수 있지만 업무가 멈춰서는 안 됩니다. 이 수동 경로를 운영 인수 때 실제로 연습하면 AI와 플랫폼의 책임 경계가 분명해집니다. 다음 적용을 결정할 때는 더 많은 자동화를 목표로 삼기보다, AI가 없어도 설명 가능한 흐름 위에서 어떤 준비 작업을 안전하게 줄일 수 있는지를 물어야 합니다. 그 질문에 답할 수 있을 때 운영 기반이 먼저라는 원칙이 실제 설계로 완성됩니다.