AI 유스케이스 발굴 · 업무 과제 도출
AI Use Case Discovery
AI 유스케이스 발굴이란?
- 기술이 아니라 반복 업무에서 출발
- 작업 단위 분해 후 효과와 난이도로 배치
- 과제마다 현업 책임자 한 명 지정
유스케이스 발굴을 'AI로 뭘 할 수 있을지 아이디어를 모으는 회의'로 열면 포스트잇은 수십 장 나오지만 실행되는 과제는 거의 없습니다. 출발점이 기술이기 때문입니다. 순서를 뒤집어 지금 시간이 많이 들고 반복되는 업무에서 시작해야 합니다. 발굴의 산출물은 아이디어 목록이 아니라 '누가, 어떤 입력으로, 어떤 결과물을, 얼마나 자주 만드는가'가 적힌 과제 정의서입니다.
방법은 업무 분해입니다. 직무 하나를 주간 단위 작업 10~20개로 나눈 뒤 작업마다 소요 시간, 빈도, 입력 자료, 결과물의 형태를 적습니다. 그다음 세 가지를 묻습니다. 입력이 문서·표·대화처럼 AI가 읽을 수 있는 형태인가, 결과를 사람이 검토할 수 있는가, 틀렸을 때 피해가 감당할 만한가입니다. 세 질문을 통과한 작업이 후보가 됩니다. 초안 작성, 요약, 분류, 대조, 양식 변환이 대표적입니다. 반대로 결과를 확인할 방법이 없는 작업은 효과가 커 보여도 후보에서 뺍니다.
후보가 모이면 효과와 난이도 두 축으로 배치합니다. 효과는 '건당 절감 시간 × 월 빈도 × 해당 인원'으로 어림하고, 난이도는 데이터 접근 권한, 보안 등급, 기존 시스템 연동 여부로 봅니다. 효과가 크고 쉬운 과제 두세 개를 먼저 실행하고, 효과는 크지만 어려운 과제는 PoC 후보로 넘깁니다. 과제마다 현업 책임자 한 명을 적지 않으면 워크숍이 끝난 뒤 아무도 움직이지 않습니다.
현장에서 어긋나는 지점은 두 가지입니다. 하나는 눈에 띄는 과제에 쏠리는 것입니다. 경영진 보고에 좋은 챗봇이나 대시보드가 먼저 뽑히고, 매일 30분씩 드는 평범한 정리 작업은 밀립니다. 그러나 확산은 작고 잦은 업무에서 일어납니다. 다른 하나는 개인정보나 고객 기밀이 든 업무를 보안 검토 없이 후보로 올리는 것입니다. 실행 직전에 막히면 참여자의 의욕이 꺾이므로, 발굴 단계에서 보안 담당자가 함께 걸러야 합니다.
유스케이스는 본래 소프트웨어 요구사항을 사용자의 사용 장면으로 기술하던 용어입니다. 기업의 AI 도입 실무에서는 '적용 대상 업무'라는 뜻으로 넓혀 쓰이며, 발굴 방법 자체는 특정 창시자 없이 업무 분석과 과제 선정 관행에서 굳어졌습니다.
가상의 사례로 살펴보겠습니다. 산업용 장비를 판매·정비하는 C사는 임직원 280명입니다. 연초에 전사 AI 아이디어 공모로 과제 63건을 모았지만 반년 동안 실행된 것은 2건뿐이었고, 대부분 '고객 응대 챗봇'처럼 범위가 큰 제안이었습니다.
- 교육팀과 기획팀은 공모를 접고 부서별 반나절 워크숍으로 바꿨습니다. 서비스팀 8명이 한 주 업무를 작업 17개로 쪼개 소요 시간을 적었더니 정비 보고서 작성에만 주 11시간이 들고 있었습니다.
- 진행자가 작업마다 "입력이 문서인가, 결과를 검토할 수 있는가, 틀리면 얼마나 위험한가"를 물었고, 17개 가운데 6개가 후보로 남았습니다.
- 정보보안 담당자가 그 자리에서 고객 계약서가 들어가는 후보 1개를 보류로 돌렸습니다. 서비스팀장은 "나중에 막히는 것보다 지금 아는 게 낫다"고 답했습니다.
- 남은 5개를 효과와 난이도로 배치해 정비 보고서 초안 작성과 부품 문의 메일 분류를 먼저 실행하기로 했고, 과제마다 책임자 이름과 4주 기한을 적었습니다.
- 두 달 뒤 6개 부서에서 과제 14건이 정의됐고 9건이 실행에 들어갔습니다. 서비스팀의 정비 보고서 작성 시간은 주 11시간에서 4시간으로 줄었습니다.