AI 서비스를 기획하다 보면 결국 두 가지 질문에서 계속 막혀요.
데이터는 어디서 구하지, 그리고 이걸 쓰는 사람에게 도대체 무슨 이득이지.
앞선 글에서는 "AI가 필요한 문제인지"를 먼저 따져 보는 이야기를 했는데, 이번에는 그다음 단계예요.
필요한 문제라고 판단했다면 데이터를 어떻게 모을지, 그 데이터를 내어 주는 사용자에게 무엇을 돌려줄지를 함께 설계해야 합니다.
한 해를 정리하는 시기라 현업에서 겪은 고민을 정리하는 마음으로 적어 봅니다.
처음 기획서를 쓸 때는 "데이터를 모아서 학습시킨다"라는 한 줄로 넘어가기 쉬워요.
하지만 그 한 줄 안에는 꽤 많은 선택지가 숨어 있더라고요.
크게 나누면 이런 경로가 있습니다.
- 우리 서비스를 쓰는 과정에서 자연스럽게 쌓이는 데이터
- 사람이 직접 만들어 붙이는 데이터, 예를 들어 분류 라벨
- 공개되어 있거나 연구용으로 풀려 있는 데이터
- 다른 회사와 제휴를 맺어 받는 데이터
- 돈을 주고 사는 데이터
각각 장단점이 뚜렷합니다.
서비스에서 쌓이는 데이터는 우리 사용자와 가장 닮았지만 서비스가 커지기 전에는 양이 적어요.
공개 데이터는 구하기 쉬운 대신 우리 서비스의 상황과 맞지 않는 경우가 많고요.
라이선스나 이용 조건도 꼭 확인해야 합니다.
제휴나 구매는 빠르지만 비용이 들고, 계약 조건에 따라 쓸 수 있는 범위가 제한될 수 있어서 법무 쪽 확인이 필요해요.
양보다 품질도 따져 봐야 합니다.
데이터가 아무리 많아도 라벨이 들쭉날쭉하거나 한쪽으로 치우쳐 있으면, 학습한 결과도 그대로 치우쳐요.
그래서 저는 처음부터 많이 모으기보다, 적더라도 기준이 일정한 데이터를 먼저 만들어 보는 편이 낫다고 생각합니다.
라벨을 붙이는 사람이 여럿이라면 기준 문서를 만들고, 헷갈리는 사례를 따로 모아 두는 것도 도움이 되더라고요.
가장 현실적인 고민은 "서비스를 열어야 데이터가 쌓이는데, 데이터가 있어야 서비스가 쓸 만해진다"는 순환이에요.
흔히 닭과 달걀 문제라고 하죠.
제가 현업에서 배운 방법은 처음부터 자동화를 목표로 삼지 않는 것입니다.
초기에는 사람이 뒤에서 직접 처리해 주면서, 사용자 눈에는 서비스가 알아서 해 주는 것처럼 보이게 만들어 볼 수 있어요.
이렇게 하면 두 가지를 얻습니다.
하나는 사용자가 실제로 어떤 요청을 하는지에 대한 날것의 기록이고, 다른 하나는 사람이 어떻게 처리했는지에 대한 정답 기록이에요.
이 두 가지가 쌓이면 나중에 자동화할 때 가장 좋은 학습 재료가 됩니다.
범위를 좁히는 것도 방법이에요.
"모든 질문에 답하는 비서" 대신 "한 가지 상황에서만 정확한 도우미"로 시작하면 필요한 데이터가 훨씬 줄어듭니다.
여기서 많이 놓치는 부분이 있어요.
데이터는 기업이 가져가는 것이 아니라, 사용자가 건네주는 것입니다.
건네줄 만한 이유가 없으면 사용자는 입력을 줄이고, 정보를 대충 채우고, 결국 떠나요.
그래서 저는 데이터와 가치를 교환 관계로 봅니다.
내가 이만큼 알려 주면 이만큼 더 좋아진다는 것을 사용자가 바로 느낄 수 있어야 해요.
여기에는 몇 가지 원칙이 있다고 생각합니다.
- 입력한 직후에 눈에 보이는 이득이 있어야 한다
- 꼭 필요한 정보만 묻는다
- 왜 필요한지 한 줄로 설명한다
- 정보를 거부해도 기본 기능은 쓸 수 있게 한다
특히 마지막이 중요해요.
모든 정보를 줘야만 쓸 수 있는 서비스는 신뢰를 얻기 어렵더라고요.
좋은 구조는 사용할수록 서비스가 나아지고, 나아진 서비스를 더 쓰게 되는 순환입니다.
기획 단계에서는 이 순환을 그림으로 그려 보면 좋아요.
사용자가 쓴다, 데이터가 쌓인다, 결과가 좋아진다, 사용자가 더 쓴다.
그림을 그리다 보면 끊어지는 고리가 눈에 들어옵니다.
예를 들어 결과가 좋아졌다는 것을 사용자가 알아채지 못하면 순환이 이어지지 않아요.
그래서 "당신의 취향을 반영해 바꿨어요" 같은 피드백이 필요할 때도 있습니다.
가정해 보겠습니다.
사진을 찍으면 음식을 알아보고 칼로리를 계산해 주는 식단 기록 앱을 기획한다고 해요.
초기에는 음식 사진이 거의 없으니 인식이 자주 틀립니다.
이때 두 갈래 선택이 있어요.
하나는 사진을 올리면 틀린 결과를 보여 주고 사용자에게 고쳐 달라고 요청하는 방식입니다.
다른 하나는 운영팀이 사진을 확인해 정확한 결과를 돌려주고, 그 기록을 정답 데이터로 남기는 방식이에요.
첫 번째는 사용자에게 수고를 떠넘기는 느낌이라 이탈이 걱정되고, 두 번째는 비용이 들지만 초기 경험이 좋습니다.
여기에 가치 교환을 더해 봅니다.
"이 음식이 맞나요?"라고 물을 때 고치면 내 기록이 더 정확해진다고 보여 주면, 사용자는 수정이 귀찮은 일이 아니라 내 기록을 위한 일로 느낄 수 있어요.
숫자는 순전히 가정이지만, 예를 들어 초기 100장 중 60장만 맞게 인식한다면 40장의 수정 요청이 곧 학습 데이터가 되는 셈입니다.
데이터 전략은 기술 문제이기 전에 관계의 문제라고 생각해요.
사용자가 믿고 내어 줄 만한 서비스인지, 돌려받는 가치가 충분히 느껴지는지가 먼저입니다.
한 해 동안 AI 기획을 하며 가장 크게 바뀐 생각은, 알고리즘보다 데이터를 얻는 설계가 더 오래 걸리고 더 중요하다는 점이었어요.
남은 질문도 있습니다.
개인정보를 최소로 쓰면서도 충분히 개인화된 경험을 줄 수 있을까요.
그리고 초기에 사람이 개입하는 방식을 어디까지 비용으로 감당할 수 있을까요.
내년에는 이 부분을 실제 기획안에 더 구체적으로 적어 보려고 합니다.
'AI > AI Product' 카테고리의 다른 글
| AI 챗봇 페르소나 설계 노트 (0) | 2020.08.30 |
|---|---|
| 챗봇 UX 설계 시 체크 포인트 (0) | 2020.07.07 |
| 챗봇 시나리오 테스트, 엣지케이스 잡는 법 (0) | 2020.05.24 |
| 인공지능 서비스를 기획할 때 먼저 물어볼 것들 (0) | 2018.03.23 |
| 전시회 정보를 정리하는 방법, CES 같은 행사 보는 법 (0) | 2018.01.16 |