좋은 AI 유스케이스를 발굴하는 방법
AI 프로젝트의 성패는 모델 선택보다 문제 선택에서 먼저 갈린다.
많은 회사가 AI 도입을 시작할 때 이렇게 묻는다. "어떤 모델이 제일 좋은가?", "어떤 도구를 사야 하는가?", "우리도 에이전트를 만들어야 하지 않을까?" 물론 도구와 모델은 중요하다. 하지만 실제 기업 현장에서 더 중요한 질문은 따로 있다.
"우리는 어떤 업무 문제를 AI로 풀 것인가?"
문제가 흐릿하면 아무리 좋은 모델을 써도 성과가 흐릿하다. 반대로 문제가 선명하면 처음에는 단순한 자동화나 프롬프트 템플릿만으로도 꽤 큰 효과를 낼 수 있다. 고객지원팀의 문의 분류, 영업팀의 미팅 요약, 마케팅팀의 고객 리뷰 분석, 인사팀의 온보딩 문서 작성처럼 말이다.
AI 유스케이스란 거창한 개념이 아니다. 쉽게 말해 AI를 적용할 구체적인 업무 사용 사례다. "AI를 도입한다"는 말은 너무 크다. "고객 문의를 배송, 환불, 제품 문의, 불만 접수로 자동 분류한다"는 말은 실행할 수 있다. "영업을 AI로 혁신한다"는 말은 추상적이다. "고객 미팅 녹취를 요약해 CRM 필드에 자동 입력한다"는 말은 프로젝트가 된다.
이번 장에서는 성과가 나는 AI 유스케이스와 실패하기 쉬운 유스케이스의 차이를 살펴본다. 그리고 업무 시간, 고객 불만, 병목 프로세스, 사내 데이터라는 네 가지 관점에서 AI 기회를 발굴하는 워크숍 방식을 제시한다.
좋은 AI 유스케이스는 작지만 선명하다
좋은 AI 유스케이스는 처음부터 거대하지 않다. 오히려 작다. 다만 작아도 선명하다. 누가, 언제, 어떤 입력을 가지고, 어떤 결과물을 만들며, 그 결과를 어떻게 검토하고, 무엇으로 성과를 판단할지가 분명하다.
예를 들어 "AI로 마케팅을 잘하고 싶다"는 유스케이스가 아니다. 이것은 희망 사항에 가깝다. 반면 "최근 6개월간 고객 리뷰 3,000건을 긍정, 부정, 기능 요청, 배송 불만, 가격 불만으로 분류하고, 매주 상위 이슈를 마케팅팀과 제품팀에 공유한다"는 유스케이스다. 입력 데이터가 있고, 처리 방식이 있으며, 산출물이 있고, 활용자가 있다.
좋은 유스케이스에는 공통된 조건이 있다.
| 조건 | 의미 | 확인 질문 |
|---|---|---|
| 명확한 업무 주기 | 반복되는 시점과 빈도가 있다 | 매일, 매주, 매월 또는 특정 이벤트마다 발생하는가? |
| 충분한 입력 데이터 | AI가 읽고 처리할 자료가 있다 | 문서, 대화, 로그, 고객 문의, 거래 데이터가 존재하는가? |
| 검수 가능성 | 사람이 결과를 확인할 수 있다 | 맞고 틀림, 좋고 나쁨을 판단할 기준이 있는가? |
| 측정 가능한 결과 | 성과를 숫자로 볼 수 있다 | 시간, 비용, 품질, 매출, 리스크 지표로 비교할 수 있는가? |
이 네 가지가 갖춰지면 AI 프로젝트는 훨씬 현실적이 된다. 반대로 이 중 하나라도 빠지면 프로젝트가 흔들린다. 업무 주기가 없으면 사용량이 쌓이지 않는다. 입력 데이터가 부족하면 AI가 추측에 의존한다. 검수 기준이 없으면 결과물의 품질을 논쟁으로 판단하게 된다. 측정 지표가 없으면 성공했는지 실패했는지 말하기 어렵다.
좋은 AI 유스케이스는 "AI가 할 수 있는 일"에서 출발하지 않는다. 회사가 반복적으로 겪는 문제에서 출발한다. AI는 그 문제를 더 빠르게, 더 일관되게, 더 확장 가능하게 처리하기 위한 수단이다.
업무 주기가 있어야 성과가 쌓인다
AI가 가장 잘 성과를 내는 곳은 반복되는 업무다. 여기서 반복이란 단순히 매일 같은 일을 한다는 뜻만은 아니다. 같은 구조의 일이 계속 발생한다는 뜻이다.
고객 문의는 매번 내용이 다르지만 구조는 반복된다. 고객은 질문하고, 상담원은 내용을 파악하고, 유형을 분류하고, 정책을 확인하고, 답변을 작성하고, 처리 기록을 남긴다. 영업 미팅도 고객마다 다르지만 구조는 비슷하다. 대화가 있고, 고객의 니즈가 있고, 예산과 일정이 있고, 다음 액션이 있다. 채용 인터뷰도 후보자는 다르지만 질문, 평가, 기록, 공유라는 흐름은 반복된다.
반복되는 구조가 있으면 AI를 붙일 수 있다. 그리고 같은 업무가 계속 발생해야 개선 효과도 누적된다. 한 달에 한 번만 하는 업무를 자동화하기 위해 3개월을 쓰는 것은 신중해야 한다. 반면 하루에 수십 번 반복되는 업무라면 작은 개선도 큰 성과가 된다.
예를 들어 상담원이 문의 한 건을 분류하고 답변 초안을 작성하는 데 평균 6분이 걸린다고 하자. 하루 300건의 문의가 들어오는 회사라면 이 업무에만 하루 1,800분, 즉 30시간이 쓰인다. AI가 이 시간을 30%만 줄여도 하루 9시간이 절감된다. 한 달이면 180시간이 넘는다. 이 정도면 단순한 편의 기능이 아니라 운영 개선이다.
반대로 1년에 두 번 하는 전략 워크숍 자료 작성을 AI로 자동화하겠다는 프로젝트는 신중해야 한다. 물론 AI가 도움을 줄 수는 있다. 그러나 반복 주기가 낮으면 데이터가 쌓이지 않고, 사용자가 익숙해지기 어렵고, 성과를 측정할 기회도 적다. 처음 AI 프로젝트로는 적합하지 않을 수 있다.
유스케이스를 검토할 때는 먼저 이렇게 물어야 한다.
"이 업무는 얼마나 자주 발생하는가?"
"업무의 형태가 매번 완전히 다른가, 아니면 비슷한 구조가 반복되는가?"
"개선 효과가 한 번으로 끝나는가, 계속 누적되는가?"
AI 도입 초기에는 반복 주기가 짧은 업무가 좋다. 매일 또는 매주 발생하는 업무를 고르면 짧은 기간 안에 충분한 사용 사례가 쌓인다. 그래야 문제도 빨리 발견되고, 개선도 빨리 이루어진다.
입력 데이터가 없으면 AI는 추측한다
AI는 빈손으로 일하지 않는다. 사람도 자료 없이 보고서를 쓰면 추측이 많아진다. AI도 마찬가지다. 좋은 결과물을 내려면 좋은 입력이 필요하다.
입력 데이터는 꼭 거대한 데이터베이스일 필요가 없다. 고객 문의 메일, 상담 채팅, 회의 녹취, 제품 매뉴얼, FAQ, 영업 제안서, 계약서, 사내 규정, 재무 리포트, 지원자 이력서처럼 이미 회사 안에 존재하는 자료가 모두 입력 데이터가 될 수 있다.
문제는 데이터가 "있는 것"과 "쓸 수 있는 것"은 다르다는 점이다. 문서가 있더라도 최신 버전이 무엇인지 모르거나, 파일명이 제각각이거나, 담당자 개인 PC에 흩어져 있거나, 접근 권한이 정리되어 있지 않으면 AI 프로젝트는 금세 막힌다.
예를 들어 고객지원 챗봇을 만들려고 하는데 FAQ가 2년 전 기준이라면 어떻게 될까. AI는 오래된 정책을 바탕으로 답변할 수 있다. 영업 제안서 자동 생성 기능을 만들려는데 최신 제품 가격표와 고객 산업별 사례가 정리되어 있지 않다면 어떨까. AI는 그럴듯하지만 부정확한 제안서를 만들 가능성이 높다.
AI는 회사의 지식을 확대해주는 장치가 아니라, 회사가 가진 지식을 빠르게 꺼내 쓰도록 돕는 장치에 가깝다. 회사 안의 지식이 어지럽다면 AI도 어지러운 답을 한다.
유스케이스 후보를 평가할 때는 데이터에 대해 다음 네 가지를 확인해야 한다.
| 확인 항목 | 질문 | 위험 신호 |
|---|---|---|
| 위치 | 필요한 데이터가 어디에 있는가? | 개인 PC, 메신저, 이메일에 흩어져 있다 |
| 품질 | 데이터가 최신이고 정확한가? | 오래된 문서와 최신 문서가 섞여 있다 |
| 구조 | AI가 읽기 쉬운 형태인가? | 이미지, 스캔본, 자유 양식 문서만 있다 |
| 권한 | 누가 접근해도 되는가? | 개인정보와 기밀 정보가 구분되어 있지 않다 |
입력 데이터가 부족한 유스케이스를 무조건 버릴 필요는 없다. 다만 순서를 바꿔야 한다. 먼저 문서를 정리하고, 필요한 데이터를 모으고, 권한을 나눈 뒤 AI를 붙여야 한다. 데이터 정비 없이 AI부터 붙이면 프로젝트는 기술 문제가 아니라 운영 문제로 실패한다.
검수할 수 없는 AI는 업무에 넣기 어렵다
AI 결과물은 반드시 검수 가능해야 한다. 특히 기업 업무에서는 "그럴듯함"보다 "확인 가능성"이 중요하다. AI가 만든 답변이 멋져 보여도, 맞는지 확인할 수 없다면 실제 업무에 넣기 어렵다.
검수 가능성이란 결과물을 사람이 판단할 수 있다는 뜻이다. 고객 문의 분류는 비교적 검수하기 쉽다. 배송 문의인지, 환불 문의인지, 제품 오류 문의인지 확인할 수 있다. 회의 요약도 원문 대화와 비교해 누락이나 왜곡을 볼 수 있다. 계약서 요약도 원문 조항을 근거로 확인할 수 있다.
반면 "우리 회사의 5년 뒤 미래 전략을 AI가 결정한다"는 식의 유스케이스는 검수하기 어렵다. 틀렸는지 맞았는지 당장 알기 어렵고, 책임 소재도 불분명하다. 물론 AI가 전략 수립을 위한 자료 조사, 시나리오 정리, 경쟁사 비교를 도울 수는 있다. 하지만 최종 전략 판단을 AI에게 맡기는 것은 다른 문제다.
좋은 유스케이스는 AI의 역할과 사람의 역할이 나뉘어 있다. AI는 초안을 만들고, 분류하고, 요약하고, 후보를 추천하고, 이상 신호를 표시한다. 사람은 맥락을 확인하고, 예외를 판단하고, 최종 결정을 내린다.
검수 구조는 처음부터 설계해야 한다. "AI가 일단 해보고 사람이 알아서 보겠지"라고 생각하면 현업은 불안해서 쓰지 않는다. 언제, 누가, 무엇을 기준으로 확인할지가 분명해야 한다.
| AI 결과물 | 검수자 | 검수 기준 | 최종 처리 |
|---|---|---|---|
| 고객 문의 답변 초안 | 상담원 | 정책 일치, 톤, 고객 맥락 | 상담원이 수정 후 발송 |
| 계약서 리스크 요약 | 법무 담당자 | 조항 근거, 누락 여부, 중요도 | 법무 검토 의견으로 반영 |
| 영업 미팅 요약 | 영업 담당자 | 고객 발언 정확성, 다음 액션 | CRM에 저장 |
| 채용 인터뷰 질문 | 채용 담당자 | 직무 관련성, 차별 요소 여부 | 면접관에게 공유 |
검수 가능성은 AI 신뢰의 출발점이다. 처음부터 AI에게 최종 결정을 맡기려 하지 말고, 사람이 확인할 수 있는 중간 산출물부터 맡겨야 한다. 기업 AI는 자율성보다 신뢰성이 먼저다.
측정할 수 있어야 확산할 수 있다
AI 유스케이스가 조직 안에서 살아남으려면 성과를 숫자로 말할 수 있어야 한다. "편해졌다", "좋아진 것 같다", "팀원들이 만족한다"는 말도 중요하지만, 예산과 인력을 투입하는 기업 프로젝트에서는 부족하다.
성과 측정은 복잡할 필요가 없다. 처음에는 전후 비교만으로도 충분하다. AI 도입 전 평균 처리 시간이 얼마였는지, 도입 후 얼마로 줄었는지 본다. 오류율이 어떻게 변했는지 본다. 고객 응답 시간이 줄었는지, 콘텐츠 생산량이 늘었는지, 영업 후속 메일 발송률이 올라갔는지 확인한다.
중요한 것은 유스케이스마다 맞는 지표가 다르다는 점이다. 비용 절감형 유스케이스와 매출 증대형 유스케이스를 같은 지표로 평가하면 안 된다. 리스크 감소형 유스케이스는 더더욱 다르다.
비용 절감형 유스케이스: 시간을 돈으로 바꾸기
비용 절감형 유스케이스는 가장 이해하기 쉽다. 반복 업무 시간을 줄이거나, 외주 비용을 낮추거나, 오류로 인한 재작업을 줄이는 것이 목표다.
대표적인 예는 회의록 요약, 고객 문의 분류, 보고서 초안 작성, 데이터 입력 자동화, 문서 검색, 내부 규정 질의응답, 영업 미팅 후 CRM 기록 자동화다. 이런 업무는 사람이 이미 하고 있고, 시간을 많이 쓰며, AI를 붙였을 때 절감 효과를 비교적 쉽게 계산할 수 있다.
비용 절감형 유스케이스의 핵심 지표는 다음과 같다.
| 지표 | 의미 | 계산 예시 |
|---|---|---|
| 처리 시간 절감 | 업무 한 건당 줄어든 시간 | 10분에서 6분으로 감소 |
| 처리량 증가 | 같은 인원으로 처리한 건수 증가 | 하루 200건에서 280건으로 증가 |
| 재작업 감소 | 오류나 누락으로 다시 처리한 비율 감소 | 재작업률 12%에서 5%로 감소 |
| 외주 비용 절감 | 외부 업체에 맡기던 비용 감소 | 월 300만 원 리서치 비용 절감 |
다만 비용 절감형 프로젝트를 설계할 때 조심할 점이 있다. 시간을 줄였다고 해서 자동으로 비용이 줄어드는 것은 아니다. 상담원의 답변 작성 시간이 줄어도 실제 인건비가 바로 줄지 않을 수 있다. 대신 같은 인원으로 더 많은 문의를 처리하거나, 고객 불만 대응에 더 많은 시간을 쓰거나, 상담 품질을 높이는 방향으로 효과가 나타날 수 있다.
그래서 비용 절감형 유스케이스는 "몇 명을 줄일 수 있는가"보다 "같은 인원으로 얼마나 더 처리할 수 있는가"를 함께 봐야 한다. AI 도입의 목적을 인력 감축으로만 말하면 현업의 저항이 커진다. 반대로 "반복 작업을 줄이고 더 중요한 일에 시간을 쓰자"고 설계하면 참여도가 높아진다.
매출 증대형 유스케이스: 더 많이 팔 기회를 찾기
매출 증대형 유스케이스는 비용 절감형보다 측정이 어렵지만, 성공하면 임팩트가 크다. AI가 직접 매출을 만드는 것이 아니라, 매출이 발생할 가능성이 높은 활동을 더 빠르고 정교하게 만드는 방식이다.
예를 들어 영업 리드 우선순위 평가를 생각해보자. 모든 리드를 같은 방식으로 따라가면 영업팀의 시간이 분산된다. AI가 산업, 회사 규모, 웹사이트 행동, 과거 문의 내용, 예산 신호 등을 바탕으로 우선순위를 제안하면 영업 담당자는 가능성이 높은 고객에게 먼저 집중할 수 있다.
마케팅에서도 마찬가지다. AI가 고객 리뷰와 검색 데이터를 분석해 사람들이 반복적으로 말하는 불편을 찾아내면, 그 불편을 해결하는 콘텐츠나 광고 메시지를 만들 수 있다. 고객 세그먼트별로 다른 랜딩페이지 문구를 테스트하면 전환율 개선으로 이어질 수 있다.
매출 증대형 유스케이스의 핵심 지표는 다음과 같다.
| 지표 | 의미 | 예시 |
|---|---|---|
| 전환율 | 방문자나 리드가 고객으로 바뀌는 비율 | 랜딩페이지 전환율 3.2%에서 4.1%로 증가 |
| 리드 품질 | 영업 가능성이 높은 리드 비율 | MQL에서 SQL 전환율 증가 |
| 영업 속도 | 첫 접촉부터 계약까지 걸리는 시간 | 평균 영업 주기 45일에서 36일로 단축 |
| 객단가 또는 업셀 | 고객당 매출 증가 | 추천 제안으로 추가 구매율 상승 |
| 캠페인 성과 | 광고, 이메일, 콘텐츠의 성과 | 클릭률, 응답률, 예약률 증가 |
매출 증대형 유스케이스는 실험 설계가 중요하다. AI를 도입한 뒤 매출이 올랐다고 해서 모두 AI 덕분이라고 말하기는 어렵다. 시즌 효과, 가격 정책, 경쟁 상황, 광고 예산 변화가 영향을 줄 수 있다. 그래서 가능하면 A/B 테스트를 설계해야 한다. 일부 고객군에는 기존 방식을 적용하고, 일부에는 AI가 만든 메시지나 추천 방식을 적용해 비교한다.
매출 증대형 프로젝트는 "AI가 매출을 올려줄 것"이라는 막연한 기대가 아니라, "어떤 고객 행동을 개선할 것인가"로 정의해야 한다. 클릭률을 높일 것인지, 상담 예약률을 높일 것인지, 견적 제출 속도를 높일 것인지, 재구매 제안을 정교하게 할 것인지가 분명해야 한다.
리스크 감소형 유스케이스: 사고를 줄이는 AI
기업에서 AI의 가치는 속도와 매출에만 있지 않다. 실수, 누락, 위반, 지연, 불만, 부정 사용 같은 리스크를 줄이는 데도 큰 역할을 할 수 있다.
리스크 감소형 유스케이스는 특히 재무, 법무, 보안, 인사, 고객지원, 품질관리 부서에서 중요하다. 계약서의 불리한 조항을 표시하거나, 비용 청구에서 이상 패턴을 찾거나, 고객 불만이 심각해지기 전에 감지하거나, 개인정보가 포함된 문서를 외부 공유 전에 탐지하는 식이다.
리스크 감소형 유스케이스의 핵심 지표는 다음과 같다.
| 지표 | 의미 | 예시 |
|---|---|---|
| 오류율 감소 | 잘못 처리된 업무 비율 감소 | 잘못 분류된 문의 비율 감소 |
| 누락 탐지율 | 사람이 놓친 항목을 AI가 찾아낸 비율 | 계약서 필수 조항 누락 탐지 |
| 사고 발생 건수 | 보안, 법무, 품질 사고 감소 | 개인정보 포함 파일 외부 전송 차단 |
| 대응 시간 | 위험 신호 발견 후 조치까지 걸린 시간 | 불만 고객 감지 후 24시간 내 대응 |
| 감사 추적성 | 누가, 언제, 무엇을 처리했는지 기록 가능성 | 검토 로그 자동 저장 |
리스크 감소형 프로젝트는 단순 ROI로 평가하기 어렵다. 사고가 나지 않은 것의 가치를 숫자로 계산하기 어렵기 때문이다. 그러나 한 번의 계약 실수, 개인정보 유출, 대형 고객 이탈, 규제 위반이 회사에 큰 비용을 만들 수 있다면 리스크 감소 효과는 매우 크다.
이 유형의 유스케이스에서는 AI의 자율성을 낮추고 통제를 강화해야 한다. AI가 위험 신호를 표시하고, 근거를 보여주고, 담당자에게 알림을 보내는 역할은 유용하다. 하지만 법적 판단, 징계, 채용 탈락, 대출 승인, 의료·금융 판단처럼 개인에게 중대한 영향을 주는 결정은 사람이 책임져야 한다.
나쁜 유스케이스는 대개 목표가 흐릿하다
실패하기 쉬운 AI 유스케이스에는 공통점이 있다. 겉으로는 멋있어 보이지만, 실제로 들어가 보면 목표가 모호하고, 데이터가 부족하고, 책임자가 없고, AI에게 너무 많은 자율성을 준다.
가장 흔한 유형은 "AI로 업무 효율을 높인다"는 식의 유스케이스다. 듣기에는 좋지만 무엇을 어떻게 바꾸겠다는 것인지 알 수 없다. 어느 부서의 어떤 업무인지, 현재 시간이 얼마나 걸리는지, AI가 어느 단계를 맡는지, 성공 기준이 무엇인지가 없다.
나쁜 유스케이스의 대표적인 신호는 다음과 같다.
| 위험 신호 | 설명 | 바꿔야 할 질문 |
|---|---|---|
| 모호한 목표 | 생산성 향상, 혁신, 고도화처럼 추상적 표현만 있다 | 어떤 지표를 얼마나 개선할 것인가? |
| 책임자 부재 | 현업 오너 없이 IT팀이나 기획팀만 추진한다 | 이 결과를 실제로 쓸 사람은 누구인가? |
| 데이터 부족 | 필요한 자료가 없거나 품질이 낮다 | AI가 무엇을 근거로 답할 것인가? |
| 과도한 자율성 | AI가 최종 결정까지 하도록 설계한다 | 어느 단계에서 사람이 승인할 것인가? |
| 업무 흐름 미연결 | 결과물이 실제 시스템이나 프로세스에 들어가지 않는다 | AI 결과는 어디에 기록되고 누가 다음 행동을 하는가? |
특히 책임자 부재는 치명적이다. AI 프로젝트에는 반드시 현업 오너가 있어야 한다. 현업 오너는 그 업무의 문제를 알고, 결과물을 실제로 사용할 사람이며, 성과를 판단할 수 있는 사람이다. IT팀은 기술 구현을 도울 수 있지만, 어떤 결과가 유용한지는 현업이 결정해야 한다.
또 하나의 위험은 AI에게 너무 많은 것을 한 번에 맡기는 것이다. "고객 문의를 받아서, 의도를 파악하고, 보상 여부를 판단하고, 고객에게 답변하고, 환불까지 처리한다"는 식의 완전 자동화는 매력적으로 들린다. 하지만 정책 예외, 감정적 고객, 악성 클레임, 법적 표현, 브랜드 톤이 얽히면 위험이 커진다.
처음에는 AI가 분류하고, 요약하고, 답변 초안을 만들고, 위험 신호를 표시하는 정도가 좋다. 사람이 확인한 뒤 발송하거나 승인한다. 신뢰가 쌓이고 데이터가 충분해지면 일부 저위험 업무부터 자동 발송이나 자동 처리로 확장할 수 있다.
유스케이스 발굴의 네 가지 출발점
좋은 유스케이스는 책상 위에서 갑자기 떠오르지 않는다. 현장의 불편, 고객의 불만, 프로세스의 병목, 회사 안에 쌓인 데이터에서 발견된다. 그래서 유스케이스 발굴 워크숍은 "AI로 무엇을 해볼까요?"라는 질문으로 시작하면 안 된다. 그 질문은 사람들을 도구 상상으로 끌고 간다.
더 좋은 질문은 이것이다.
"어디에서 시간이 새고 있는가?"
"고객은 무엇을 반복해서 불평하는가?"
"업무는 어디에서 멈추는가?"
"우리는 어떤 데이터를 쌓아두고도 쓰지 못하고 있는가?"
이 네 질문이 유스케이스 발굴의 출발점이다.
업무 시간 기준으로 기회 찾기
첫 번째 출발점은 시간이다. 직원들이 많은 시간을 쓰는 업무에는 AI 기회가 숨어 있다. 특히 반복 입력, 자료 검색, 문서 작성, 회의 정리, 시스템 기록, 보고서 작성처럼 눈에 잘 띄지 않지만 시간을 잡아먹는 업무가 중요하다.
워크숍에서는 먼저 부서원들에게 최근 1~2주 동안 시간을 많이 쓴 업무를 적게 한다. 이때 "중요한 업무"가 아니라 "시간을 많이 쓴 행동"을 적어야 한다. "고객 관리"라고 쓰면 너무 크다. "미팅 후 CRM에 상담 내용을 입력함", "고객사 정보를 검색해 제안서 앞부분을 작성함", "지난 메일을 찾아 요청 사항을 확인함"처럼 행동 단위로 적어야 한다.
그다음 각 업무에 대해 빈도와 소요 시간을 적는다.
| 업무 | 빈도 | 1회 소요 시간 | 월간 총시간 | AI 적용 아이디어 |
|---|---|---|---|---|
| 미팅 녹취 요약 | 주 15회 | 20분 | 약 20시간 | 요약 및 액션 아이템 추출 |
| CRM 기록 입력 | 주 15회 | 15분 | 약 15시간 | 필드 자동 입력 초안 생성 |
| 경쟁사 콘텐츠 확인 | 주 2회 | 60분 | 약 8시간 | 신규 콘텐츠 요약 및 변화 감지 |
| 월간 보고서 초안 작성 | 월 1회 | 6시간 | 6시간 | 데이터 요약과 문장 초안 작성 |
월간 총시간이 크고, 입력 데이터가 있으며, 결과물을 검수할 수 있다면 좋은 후보가 된다. 단, 시간이 많이 걸린다고 무조건 자동화해야 하는 것은 아니다. 그 시간이 고객과의 관계 형성, 창의적 판단, 리더십 발휘처럼 사람의 가치가 큰 시간이라면 AI가 대체하기보다 보조해야 한다.
시간 기준 발굴의 핵심은 직원의 하루를 되찾는 것이다. AI가 가장 먼저 줄여야 할 것은 생각하는 시간이 아니라, 생각하기 전에 반복적으로 소모되는 시간이다.
고객 불만 기준으로 기회 찾기
두 번째 출발점은 고객 불만이다. 고객이 반복해서 불편을 말하는 곳은 AI를 적용했을 때 효과가 크게 드러난다. 고객 불만은 회사 밖에서 들려오는 업무 진단 신호다.
고객 불만은 여러 곳에 흩어져 있다. 상담 티켓, 콜센터 녹취, 채팅 기록, 앱 리뷰, 쇼핑몰 리뷰, 영업 미팅 메모, NPS 주관식 답변, 커뮤니티 게시글, 환불 사유, 해지 사유에 들어 있다. 많은 회사가 이 데이터를 쌓아두지만 정기적으로 분석하지 못한다.
AI는 이 지점에서 강력하다. 대량의 텍스트를 읽고 유형을 분류하고, 반복되는 불만을 묶고, 심각도가 높은 표현을 찾고, 제품·배송·가격·정책·상담 품질 같은 주제로 나눌 수 있다.
예를 들어 고객 불만 분석 워크숍에서는 다음과 같은 표를 만들 수 있다.
| 불만 유형 | 발생 빈도 | 고객 영향 | 현재 대응 | AI 유스케이스 후보 |
|---|---|---|---|---|
| 배송 지연 문의 | 높음 | 불안, 반복 문의 증가 | 상담원이 수동 확인 | 배송 상태 기반 답변 초안 생성 |
| 환불 정책 불만 | 중간 | 불신, 악성 리뷰 가능 | 상담원별 설명 차이 | 정책 기반 일관 답변 추천 |
| 제품 사용법 문의 | 높음 | 초기 이탈 가능 | FAQ 링크 전달 | 고객 상황별 안내문 생성 |
| 불친절 상담 불만 | 낮음 | 브랜드 신뢰 하락 | 사후 확인 | 상담 품질 자동 점검 |
고객 불만 기준 유스케이스는 단순히 상담 시간을 줄이는 데 그치지 않는다. 고객 경험을 개선하고, 제품 개선 아이디어를 찾고, 이탈을 줄이는 데 연결될 수 있다. 특히 같은 불만이 반복된다면 그것은 상담팀만의 문제가 아니다. 제품, 물류, 정책, 마케팅 메시지의 문제일 수 있다.
AI는 불만을 "처리할 티켓"에서 "개선할 신호"로 바꾸는 데 도움을 준다.
병목 프로세스 기준으로 기회 찾기
세 번째 출발점은 병목이다. 병목은 업무가 멈추는 지점이다. 고객은 기다리고, 직원은 다음 단계로 가지 못하고, 관리자는 왜 지연되는지 모른다.
병목은 보통 승인, 검토, 검색, 입력, 전달, 조율에서 생긴다. 계약서 검토가 밀려 영업 계약이 늦어지고, 디자인 검수가 늦어 캠페인이 지연되고, 재무 승인 대기 때문에 구매가 멈추고, 개발 이슈의 원인 분석이 늦어 장애 대응이 길어진다.
AI는 병목을 완전히 없애기보다 병목 앞뒤의 시간을 줄이는 데 효과적이다. 승인자가 판단할 수 있도록 근거를 정리하고, 검토자가 볼 항목을 미리 표시하고, 누락된 정보를 요청하고, 다음 액션을 자동으로 알릴 수 있다.
병목을 찾을 때는 업무 흐름을 한 줄로 그려보면 좋다.
| 단계 | 담당 | 평균 소요 시간 | 대기 시간 | 병목 원인 | AI 적용 가능성 |
|---|---|---|---|---|---|
| 요청 접수 | 현업 | 10분 | 0시간 | 양식 불완전 | 누락 항목 자동 체크 |
| 1차 검토 | 담당 부서 | 30분 | 2일 | 요청 몰림 | 요약 및 우선순위 분류 |
| 승인 | 팀장 | 15분 | 1일 | 판단 근거 부족 | 승인 근거 자동 정리 |
| 기록 | 운영 담당 | 10분 | 4시간 | 수동 입력 | 승인 결과 자동 기록 |
이 표를 보면 AI가 어디에 들어가야 하는지 보인다. 단순히 승인자를 재촉하는 것이 아니라, 승인자가 빨리 판단할 수 있게 자료를 정리해주는 것이 더 효과적일 수 있다. 병목은 사람의 게으름 때문이 아니라 정보가 정리되지 않았기 때문에 생기는 경우가 많다.
병목 기준 유스케이스는 조직 전체 성과와 연결되기 쉽다. 한 부서의 시간이 아니라 여러 부서를 가로지르는 흐름을 개선하기 때문이다. 영업 계약 속도, 채용 리드타임, 구매 승인 시간, 장애 대응 시간처럼 경영진이 관심을 가질 만한 지표와도 연결된다.
사내 데이터 축적 정도로 기회 찾기
네 번째 출발점은 사내 데이터다. 회사 안에는 이미 많은 데이터가 쌓여 있다. 문제는 그것이 업무에 충분히 활용되지 못한다는 점이다.
고객 상담 기록은 제품 개선의 단서가 될 수 있다. 영업 미팅 메모는 구매 장벽을 알려준다. 계약서와 협상 이력은 리스크 패턴을 보여준다. 채용 인터뷰 기록은 좋은 인재의 특징을 드러낼 수 있다. 장애 로그는 시스템의 약점을 말해준다. 사내 Q&A는 직원들이 반복해서 막히는 지점을 보여준다.
AI 유스케이스를 찾을 때는 이렇게 물어야 한다.
"우리는 어떤 데이터를 많이 쌓아두고 있는가?"
"그 데이터는 지금 의사결정에 쓰이고 있는가?"
"사람이 읽기에는 너무 많지만, AI가 요약하면 가치가 생기는가?"
"그 데이터에서 반복 패턴, 이상 신호, 추천 근거를 찾을 수 있는가?"
데이터 축적 정도를 기준으로 보면 다음과 같은 유스케이스가 나온다.
| 축적 데이터 | 현재 상태 | AI 유스케이스 | 기대 효과 |
|---|---|---|---|
| 고객 상담 기록 | 쌓이지만 분석 부족 | VOC 자동 분류와 월간 이슈 리포트 | 제품·정책 개선 |
| 영업 미팅 메모 | 담당자별로 흩어짐 | 구매 장벽과 경쟁사 언급 분석 | 영업 전략 개선 |
| 사내 문의 기록 | 반복 질문 많음 | 내부 FAQ 추천과 지식 챗봇 | 직원 셀프서비스 강화 |
| 장애 로그 | 엔지니어가 수동 분석 | 유사 장애 검색과 원인 후보 제안 | 대응 시간 단축 |
| 계약 검토 이력 | 법무팀에 축적 | 반복 리스크 조항 탐지 | 협상 품질 향상 |
데이터 기반 유스케이스의 장점은 시간이 지날수록 좋아질 수 있다는 점이다. 상담 기록이 많아질수록 고객 불만 패턴을 더 잘 볼 수 있고, 영업 기록이 쌓일수록 승률에 영향을 주는 요인을 더 잘 찾을 수 있다. 단, 데이터가 계속 쌓이려면 기록 방식이 표준화되어야 한다. AI 프로젝트는 종종 데이터 입력 습관을 바꾸는 프로젝트이기도 하다.
AI 유스케이스 워크숍 진행법
이제 실제 워크숍 방식을 정리해보자. 목적은 아이디어를 많이 내는 것이 아니라, 실행 가능한 후보를 고르는 것이다. 한 부서 기준으로 2~3시간이면 1차 워크숍을 진행할 수 있다.
참석자는 현업 실무자, 팀장, IT 또는 자동화 담당자, 보안·데이터 담당자가 함께하는 것이 좋다. 실무자는 실제 문제를 알고, 팀장은 우선순위를 판단하며, IT 담당자는 구현 가능성을 보고, 보안 담당자는 위험을 짚어준다.
워크숍은 다음 순서로 진행한다.
| 단계 | 활동 | 핵심 질문 | 산출물 |
|---|---|---|---|
| 1단계 | 문제 수집 | 시간이 새는 곳, 불만이 쌓이는 곳, 멈추는 곳은 어디인가? | 문제 목록 |
| 2단계 | 유스케이스 문장화 | AI가 어떤 입력을 받아 어떤 결과를 만들 것인가? | 유스케이스 후보 |
| 3단계 | 조건 점검 | 업무 주기, 데이터, 검수, 측정이 가능한가? | 1차 필터링 |
| 4단계 | 유형 분류 | 비용 절감형, 매출 증대형, 리스크 감소형 중 무엇인가? | 평가 지표 선택 |
| 5단계 | 위험 확인 | 보안, 법무, 품질, 현업 수용성 리스크는 무엇인가? | 통제 방안 |
| 6단계 | 우선순위 결정 | 작게 시작해도 성과가 보이는가? | 파일럿 후보 1~3개 |
워크숍에서 가장 중요한 도구는 유스케이스 문장 템플릿이다. 아이디어를 아래 형식으로 쓰게 하면 모호한 생각이 실행 가능한 문장으로 바뀐다.
우리는
[대상 사용자]가[업무 상황]에서[입력 데이터]를 바탕으로[AI가 수행할 작업]을 하게 하여,[측정 지표]를[목표 수준]만큼 개선하고자 한다.
예를 들어 이렇게 쓸 수 있다.
우리는 고객지원 상담원이 배송 문의를 처리할 때 주문 상태, 배송 정책, 과거 상담 이력을 바탕으로 AI가 답변 초안을 생성하게 하여, 평균 응답 시간을 30% 줄이고자 한다.
또는 이렇게 쓸 수 있다.
우리는 영업 담당자가 고객 미팅 후 후속 조치를 정리할 때 녹취록과 메모를 바탕으로 AI가 고객 니즈, 의사결정자, 다음 액션을 추출하게 하여, CRM 기록 누락률을 50% 줄이고자 한다.
이 문장으로 표현되지 않는 아이디어는 아직 유스케이스가 아니다. 더 다듬어야 한다.
유스케이스 점수표 만들기
워크숍에서 후보가 여러 개 나오면 점수표로 비교한다. 여기서 점수표의 목적은 완벽한 계산이 아니다. 토론을 감정이 아니라 기준으로 옮기는 것이다.
다음 여섯 가지 기준을 1점부터 5점까지 평가할 수 있다.
| 평가 기준 | 질문 | 점수가 높다는 의미 |
|---|---|---|
| 업무 반복성 | 자주 발생하고 구조가 반복되는가? | 성과가 누적될 가능성이 크다 |
| 성과 임팩트 | 시간, 매출, 리스크에 미치는 영향이 큰가? | 경영 성과와 연결된다 |
| 데이터 준비도 | 필요한 입력 데이터가 확보되어 있는가? | 빠르게 실험할 수 있다 |
| 검수 용이성 | 사람이 결과를 확인할 수 있는가? | 품질 관리가 가능하다 |
| 구현 난이도 | 시스템 연동과 기술 구현이 쉬운가? | 낮을수록 빠르게 시작할 수 있다 |
| 보안 위험 | 민감 정보나 규제 이슈가 적은가? | 높을수록 안전하게 실험할 수 있다 |
구현 난이도와 보안 위험은 표현에 주의해야 한다. 점수표에서는 "실행 용이성"과 "보안 안전성"처럼 높을수록 좋은 방향으로 바꾸어 평가하는 편이 좋다. 그래야 총점을 계산하기 쉽다.
예시는 다음과 같다.
| 유스케이스 | 반복성 | 임팩트 | 데이터 준비도 | 검수 용이성 | 실행 용이성 | 보안 안전성 | 합계 |
|---|---|---|---|---|---|---|---|
| 고객 문의 자동 분류 | 5 | 4 | 4 | 5 | 4 | 3 | 25 |
| 영업 미팅 요약 및 CRM 입력 | 4 | 4 | 3 | 4 | 3 | 3 | 21 |
| 전사 전략 자동 수립 | 1 | 5 | 2 | 1 | 1 | 2 | 12 |
| 계약서 리스크 검토 보조 | 3 | 5 | 3 | 4 | 2 | 1 | 18 |
| 마케팅 리뷰 분석 리포트 | 4 | 4 | 4 | 4 | 4 | 4 | 24 |
이 표를 보면 첫 파일럿 후보가 선명해진다. 고객 문의 자동 분류나 마케팅 리뷰 분석은 반복성, 데이터 준비도, 검수 용이성이 높아 빠르게 시작하기 좋다. 계약서 리스크 검토는 임팩트가 크지만 보안 안전성과 실행 용이성이 낮으므로 별도 통제 환경에서 전략 프로젝트로 다루는 편이 좋다. 전사 전략 자동 수립은 멋있어 보이지만 첫 프로젝트로는 위험하다.
점수표의 결과가 항상 정답은 아니다. 하지만 토론의 질을 높인다. "이게 더 멋있다"가 아니라 "이 업무는 데이터가 충분한가?", "검수할 수 있는가?", "성과를 측정할 수 있는가?"로 대화가 바뀐다.
첫 파일럿은 작고, 빠르고, 안전해야 한다
유스케이스를 발굴한 뒤 바로 대규모 구축으로 가면 위험하다. 첫 파일럿은 작아야 한다. 빠르게 실험할 수 있어야 하고, 실패해도 피해가 작아야 하며, 성공하면 확장 가능해야 한다.
좋은 첫 파일럿은 다음 조건을 갖는다.
| 조건 | 설명 |
|---|---|
| 범위가 좁다 | 한 부서, 한 업무, 한 사용자 그룹에서 시작한다 |
| 기간이 짧다 | 2~6주 안에 결과를 볼 수 있다 |
| 데이터가 확보되어 있다 | 별도 대규모 정비 없이 실험할 수 있다 |
| 사람이 검수한다 | AI 결과가 바로 외부로 나가지 않는다 |
| 지표가 단순하다 | 시간, 오류, 응답 속도 등 비교가 쉽다 |
| 확장 경로가 있다 | 성공하면 다른 팀이나 업무로 넓힐 수 있다 |
예를 들어 고객지원팀이라면 "전체 상담 자동화"가 아니라 "배송 문의 답변 초안 생성"으로 시작할 수 있다. 영업팀이라면 "AI 영업 에이전트 구축"이 아니라 "미팅 요약과 후속 메일 초안 작성"으로 시작할 수 있다. 법무팀이라면 "계약 자동 승인"이 아니라 "표준 계약서와 다른 조항 표시"로 시작할 수 있다.
파일럿의 목표는 완벽한 시스템을 만드는 것이 아니다. 세 가지를 확인하는 것이다. 첫째, AI가 실제 업무 시간을 줄이는가. 둘째, 현업이 결과를 신뢰하고 사용하는가. 셋째, 더 큰 프로세스로 확장할 가치가 있는가.
이 세 가지에 답할 수 있다면 파일럿은 성공이다. 설령 처음 기대한 만큼 성과가 나오지 않아도, 어떤 데이터가 부족한지, 어떤 검수 기준이 필요한지, 어떤 사용자 경험이 불편한지 알게 되면 다음 실험의 수준이 올라간다.
좋은 유스케이스는 조직의 언어로 설명된다
AI 프로젝트가 조직 안에서 확산되려면 기술의 언어가 아니라 업무의 언어로 설명되어야 한다. "RAG를 붙이고 에이전트 워크플로우를 구성하겠습니다"라는 말은 일부 담당자에게만 통한다. 현업과 경영진에게는 이렇게 말해야 한다.
"상담원이 배송 문의를 처리하는 시간을 줄이겠습니다."
"영업 미팅 후 CRM 기록 누락을 줄이겠습니다."
"계약 검토에서 놓치기 쉬운 조항을 먼저 표시하겠습니다."
"고객 리뷰에서 반복 불만을 매주 제품팀에 전달하겠습니다."
좋은 유스케이스는 듣는 사람이 바로 이해할 수 있다. 어떤 업무가 바뀌는지, 누가 편해지는지, 어떤 숫자가 좋아지는지 보인다. 반대로 나쁜 유스케이스는 설명할수록 기술 용어가 늘어난다. 기술 설명이 길어질수록 업무 문제는 흐려진다.
AI 네이티브 기업으로 가는 길은 거대한 선언에서 시작되지 않는다. 좋은 유스케이스 하나에서 시작된다. 작은 업무 하나가 바뀌고, 팀의 흐름이 바뀌고, 부서의 운영 방식이 바뀌고, 결국 회사의 실행 속도가 달라진다.
이번 장의 핵심은 분명하다. AI 프로젝트의 성공은 어떤 모델을 고르느냐보다 어떤 문제를 고르느냐에서 결정된다. 좋은 유스케이스는 명확한 업무 주기, 충분한 입력 데이터, 검수 가능성, 측정 가능한 결과를 갖는다. 나쁜 유스케이스는 목표가 모호하고, 책임자가 없고, 데이터가 부족하며, AI에게 과도한 자율성을 준다.
다음 장에서는 이렇게 발굴한 유스케이스를 30일, 60일, 90일, 6개월, 1년의 실행 로드맵으로 연결하는 방법을 살펴본다. 좋은 아이디어는 출발점일 뿐이다. 기업 AI의 진짜 성과는 그것을 조직의 실행 계획으로 바꿀 때 시작된다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.