David.Cheon
UIpac
David.Cheon
  • UIpac (647) N
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (64) N
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (33) N
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352) N
      • Weekly Curation (251)
      • Performing Arts (17) N
      • Collection (6)
      • Books (0)
      • Life (78) N

인기 글

Tags

  • 벤치마킹
  • 반응형웹
  • 기획참고
  • 인공지능
  • 다음카카오
  • 디자인참고
  • 큐레이션
  • 세계 게임시장 규모
  • 동향
  • trend
  • 사물인터넷
  • 애플리케이션
  • 트렌드
  • 웨어러블
  • 유니티
  • 2014
  • 디자인
  • 가트너
  • daumkakao
  • Mreport
  • 기획
  • UI
  • 2015
  • Gartner
  • 모바일
  • Curation
  • 사이트
  • 분석
  • UX
  • 트랜드

최근 댓글

방명록

전체 방문자
오늘
어제
hELLO · Designed By 정상우.
David.Cheon

UIpac

AI/AI Product

인공지능 서비스를 기획할 때 먼저 물어볼 것들

2018. 3. 23. 21:23

 

요즘은 회의에서 "여기에 AI를 넣어 보면 어떨까요"라는 말이 자주 나옵니다.
기대가 큰 만큼 시작은 쉬운데, 끝까지 가 보면 AI가 꼭 필요하지 않았거나 필요한 준비가 빠져 있었던 경우가 많았어요.
그래서 저는 AI 서비스를 기획하기 전에 먼저 던져 보는 질문을 목록으로 정리해 두었습니다.
기술을 어떻게 만드느냐보다, 만들기 전에 무엇을 확인하느냐에 가까운 글이에요.
예시는 제가 가정해서 만든 사례이고, 특정 기술의 성능 수치는 쓰지 않았습니다.

 

 

질문 1. 이 문제는 정말 AI가 필요한 문제인가

 

가장 먼저 물어볼 질문입니다.
규칙으로 풀 수 있는 문제라면 규칙으로 푸는 편이 빠르고 싸고 설명하기도 쉬워요.
AI, 특히 기계학습은 규칙을 일일이 쓰기 어렵지만 예시는 많은 문제에서 힘을 냅니다.
저는 판단 기준을 이렇게 둡니다.

  • 사람이 해도 정답이 애매하거나 사람마다 다른가
  • 조건이 너무 많아 규칙으로 다 쓰기 어려운가
  • 입력이 이미지, 음성, 자연어처럼 정리되지 않은 형태인가
  • 시간이 지나며 패턴이 바뀌어 규칙을 계속 고쳐야 하는가

네 가지 중 해당되는 것이 없다면, 먼저 단순한 규칙이나 검색 조건으로 시작해 보는 게 좋습니다.
AI는 마지막에 붙일 수 있는 도구이지, 출발점이 아니라고 생각해요.
AI를 쓰자는 아이디어의 뒤에는 보통 풀고 싶은 진짜 문제가 숨어 있습니다.
그래서 회의에서는 그 문제를 한 문장으로 적어 보는 것부터 시작해요.
한 문장으로 적히지 않는다면 아직 AI를 논할 단계가 아니라는 신호입니다.

 

 

질문 2. 학습할 데이터가 있고, 쓸 수 있는가

 

AI 서비스는 데이터의 양과 질에 크게 좌우됩니다.
여기서는 간단히 짚고 넘어갑니다.

  • 필요한 데이터가 지금 있는가, 없다면 어떻게 모을 것인가
  • 그 데이터를 이 목적으로 써도 되는가 (개인정보 등은 확인 필요)
  • 정답이 붙어 있는가, 붙이는 데 비용이 얼마나 드는가

데이터가 있더라도 대표성을 확인해야 합니다.
예를 들어 특정 시기나 특정 고객층의 데이터만 있다면, 그 밖의 사용자에게는 서비스가 잘 작동하지 않을 수 있어요.
데이터가 없다면 처음에는 사람이 직접 처리하면서 데이터를 쌓는 방식도 생각해 볼 수 있어요.
데이터 확보 전략과 사용자 가치의 관계는 따로 깊게 다룰 만한 주제라서, 이번 글에서는 질문 목록에만 올려 둡니다.

 

 

질문 3. 틀렸을 때 어떻게 되는가

 

AI는 틀립니다.
틀릴 수 있다는 점을 받아들이고 설계하느냐가 서비스의 품질을 가릅니다.
기획자가 확인할 것은 틀림의 비용이에요.

  • 틀렸을 때 사용자가 입는 피해는 무엇인가 (시간 낭비인지, 금전 손해인지)
  • 틀렸음을 사용자가 알아차릴 수 있는가
  • 틀린 걸 바로잡을 방법이 있는가 (되돌리기, 사람에게 넘기기)

가정해서 고객 문의를 자동으로 분류하는 기능이라면, 분류가 틀려도 상담원이 다시 옮기면 되니 비용이 작아요.
반대로 환불 승인처럼 돈이 오가는 판단을 맡긴다면 틀림의 비용이 크기 때문에 사람의 확인을 꼭 붙여야 합니다.
이렇게 틀림의 비용에 따라 자동화의 범위를 정하면 위험을 줄일 수 있습니다.

 

 

질문 4. 기대는 어떻게 관리하고, 성공은 어떻게 재는가

 

AI라는 이름이 붙으면 사용자는 사람처럼 모든 걸 알아듣는다고 기대합니다.
기대가 높을수록 한 번의 실수에 실망도 큽니다.
그래서 서비스가 무엇을 할 수 있고 무엇은 못 하는지 처음에 분명히 알려 주는 것이 중요해요.
첫 화면에서 할 수 있는 일의 예를 몇 개 보여 주면, 사용자가 서비스의 범위를 짐작하고 쓰게 됩니다.
조직 안의 기대도 마찬가지예요.
경영진이나 다른 팀이 "AI니까 다 해결해 주겠지"라고 생각하고 있다면 초반에 현실적인 범위를 합의해 두는 편이 낫습니다.

기대를 관리하는 일은 성공 기준을 정하는 일과 맞닿아 있어요.
성공 기준이 없으면 AI 프로젝트는 끝나지 않는 실험이 되기 쉬워요.
기술 지표와 서비스 지표를 구분해서 정합니다.

  • 기술 지표: 얼마나 정확하게 맞히는가
  • 서비스 지표: 사용자가 일을 끝냈는가, 문의가 줄었는가, 다시 쓰는가

정확도가 올라도 사용자가 만족하지 않을 수 있으니, 기술 지표만 보지 말라고 스스로에게 자주 말합니다.
시작 전에 목표 수준을 가정으로라도 적어 두면, 나중에 결과를 해석할 때 흔들리지 않습니다.

 

 

가정해서 쇼핑몰 고객센터에 문의 자동 응대를 도입하자는 아이디어가 나왔다고 해 볼게요.

  • 질문 1: 문의의 절반이 배송 조회라면 규칙과 조회 연동으로 먼저 풀 수 있다
  • 질문 2: 과거 상담 기록이 있지만 개인정보가 섞여 있어 정리 방법을 확인해야 한다
  • 질문 3: 환불 같은 민감한 문의는 사람에게 넘기는 흐름이 필요하다
  • 질문 4: 첫 인사에서 처리 가능한 문의 종류를 안내하고, 상담원 연결 비율과 해결 완료율을 서비스 지표로 둔다

이렇게 적어 보니 AI가 꼭 필요한 부분은 일부였고, 나머지는 기획과 연동으로 해결되는 일이었어요.

 

AI 서비스 기획은 AI를 잘 아는 것보다 질문을 잘 던지는 일에서 시작한다고 느꼈어요.
질문에 답하다 보면 AI 없이 해결되는 경우도 있고, 정말 필요하다는 확신이 생기기도 합니다.
다음에 새 AI 아이디어를 들으면 이 질문들을 종이에 적고 답을 채워 보는 데서 시작하려고 합니다.
빈칸이 많을수록 아직 만들 때가 아니라는 신호로 읽을 수 있어서, 팀과 이야기할 때도 도움이 돼요.
남은 질문은 데이터가 처음엔 없지만 서비스를 해야만 쌓이는 경우예요.
그럴 때 어디까지 사람이 대신하고 언제부터 자동화로 넘길지, 그 기준을 더 구체적으로 배우고 싶습니다.

저작자표시 비영리 변경금지 (새창열림)

'AI > AI Product' 카테고리의 다른 글

AI 챗봇 페르소나 설계 노트  (0) 2020.08.30
챗봇 UX 설계 시 체크 포인트  (0) 2020.07.07
챗봇 시나리오 테스트, 엣지케이스 잡는 법  (0) 2020.05.24
전시회 정보를 정리하는 방법, CES 같은 행사 보는 법  (0) 2018.01.16
AI 서비스 기획, 데이터와 사용자 가치 사이에서  (0) 2017.12.23

티스토리툴바