AI 기획 방법론, AI 서비스기획에서의 고민
Intro
안녕하세요, 인트로, 상위기획에 이어 세 번째 메이커로그를 작성하게 되었습니다.
세 번째 메이커로그에서는 AI 프로덕트, 스킬의 기획 방법론에 대해 작성하고자 합니다.
AI 서비스기획은 LLM의 특성으로 인해 일반적인 서비스기획 방법론과 다소 다른 점들이 존재합니다.
해당 부분에 대해 스스로 정리하며 향후 기획 업무에 활용할 수 있도록 하고자 합니다.
그렇다면, 제가 기획에 참여한 하이퍼클로바X의 ‘스킬’은 어떤 프로덕트이며,
어떤 고민을 통해 기획을 진행하였는지 간략하게 정리하며 시작하겠습니다.
※ 해당 글의 내용은 네이버 AI 기획의 기획 방법론 전체를 담고 있지 않으며, 넓은 범위의 AI 기획 업무 과정에서 고려해야 할 점과 그 과정에 대해 작성한 글입니다.
‘스킬’은 어떤 프로덕트인가?
‘스킬’은, 네이버 컨퍼런스에서 소개되었듯이, AI의 최신 정보 한계를 넘어 ‘완결성’을 만드는 기능이며,
현재 네이버 여행, 네이버 쇼핑, 쏘카 스킬이 클로바X에 구현되어 최신 정보를 바탕으로 답변을 제공하고 있습니다.
스킬은 단순한 클로바X의 확장 기능이 아닌, 더 큰 확장성을 가지고 있습니다.
클로바X가 단순히 유저의 문제를 해결하고 정보를 찾아주는 ‘도구’를 넘어,
유저가 한 화면에서 수많은 서비스를 대화형으로 이용할 수 있는 새로운 시대의 ‘포털’이자 ‘인터페이스’가 될 수 있도록 합니다.
네이버 및 외부 서비스의 정보를 바탕으로, 클로바X와 대화하실 수 있습니다.기획 과정에서의 고민은?
기획 과정에서 최근 챗GPT를 통해 AI와의 대화가 유저들에게 다소 익숙해졌으나,
대화형으로 일상의 문제를 해결하는 것이 아직 다소 생소한 상황에서,
B2C 서비스로서 유저에게 다가가기 위하여 많은 고민을 하게 되었습니다.
그 고민들은, 주로 세 갈래로 이루어졌습니다.
1) 유저의 목적 : 유저는 대화형으로 어떤 문제를 해결하고 싶어할 것인가?
2) 기술적/상업적 실현 가능성 : 스킬을 통해 어떤 기능까지 제공할 수 있으며, 사업 관점에서 이익을 창출할 수 있을까?
3) 유저의 편익 : 기존의 문제해결 방법이 아닌, 유저가 스킬을 사용할 이유, 더 편리한 점은 무엇인가?
본 메이커로그에서는 그 고민들을 충족시키기 위해 수행한 기획 방법론에 대해 다룰 예정입니다.
그리고, 세부적인 고민들은 다음 메이커로그에서 다루도록 하겠습니다.
그럼, 그렇게 탄생한 스킬의 시연 영상과 함께, 메이커로그를 시작하겠습니다!
Skill의 활용으로, 클로바X와의 대화를 통해 수없이 많은 일을 할 수 있게 됩니다.
Skill 기획 및 개발 방법론 개요
chatGPT Plugin 방법론 레퍼런스
먼저, chatGPT 플러그인의 개발 방법론을 레퍼런스로 참고하는 것이 필요합니다.
현재 구현되어 PoC가 완료된 플러그인의 방법론을 참고하며, 네이버만이 할 수 있는 강점을 방법론에 추가하고자 하였습니다.
OpenAI는 자체 블로그에서 플러그인에 대해 전반적으로 설명하고 있습니다.
해당 내용을 참고하여 플러그인의 제작 방법론을 정리하겠습니다.
https://openai.com/blog/chatgpt-plugins
ChatGPT plugins
1. manifest
먼저, 생성형 AI에게 내가 플러그인으로 무엇을 하고 싶은지 알려주어야 합니다.
이를 챗gpt는 ‘manifest(선언)’이라고 명명하는데,
말 그대로 AI에게 해당 플러그인을 통해 ‘너는 어떤 일을 어떻게 도와주면 돼’라고 설명해 주며 선언하는 것입니다.
출처 : youtube ‘노마드 코더’먼저, AI에게 플러그인의 ‘이름’과 ‘설명’을 제공합니다.
위 그림에서는 플러그인의 이름을 ‘Oscars Winners’, ‘오스카 수상자’로 설정하고,
플러그인의 설명을 ‘오스카상 수상자의 목록을 가져오는 플러그인’으로 작성하였습니다.
챗gpt는 본질적으로 언어 모델이므로, 이렇게 사람의 언어를 통해 플러그인에 대해 이해하도록 설명할 수 있습니다.
다만, name과 description에서 for human/model로 설명 대상을 나누어,
사람이 플러그인을 이해하기 쉬운 설명과, AI가 이해하기 쉬운 설명을 각자 나누어 작성합니다.
2. auth 인증
출처 : youtube ‘노마드 코더’‘auth’는, ‘유저의 인증 방법’을 설정하는 내용입니다.
예를 들어 항공권 예매 플러그인의 경우, 예매를 진행하기 위한 로그인 과정이 필요할 것이고,
나아가 실제 결제를 진행하기 위해 결제수단을 등록하고 인증하는 과정이 필요할 것입니다.
해당 과정에서 어떻게 유저의 권한인증 및 본인인증을 수행하는지를 정의합니다.
위 그림에서는 인증 유형이 ‘none’으로 설정되어 있으므로, 별다른 인증 없이 유저 정보는 ‘익명’으로 처리됩니다.
인증이 필요한 경우, Token 인증, http 인증, OAuth 인증 방법을 통해 인증할 수 있습니다.
최근 트렌드는 ‘OAuth’ 인증 방식으로, ‘구글로 로그인하기’, ‘네이버로 로그인하기’와 같이 타 플랫폼의 정보로 로그인할 수 있는 방식입니다.
‘인증’은 향후 AI가 새로운 시대의 포털로 자리매김하여 더 많은 업무를 진행하기 위해 반드시 고려되어야 하는 기능입니다.
대화형으로 더 편리하게 본인인증을 수행하고, 다소 민감할 수 있는 결제, 금융업무 등을 원활히 서비스할 수 있도록 하기 위해
Skill 기획 과정에서 유저 인증에 대해서도 많은 고민을 하였습니다.
3. OpenAPI 형태를 통한 API 설명
출처 : 위시켓 블로그그리고 ‘api’는, 플러그인으로 질문에 답하기 위해 어떤 정보를 가져올 수 있는지 설명하는 부분입니다.
‘api’에 대해 한 문장으로 정리하면, 식당의 웨이터가 주문에 맞는 음식을 가져오듯, 요구사항(파라미터)에 맞는 데이터를 가져오는 기능입니다.
위 그림의 내용은, 표시된 url을 따라가면, ‘openai.yaml’ 파일이 나오고, 이 파일의 내용을 참고하라는 의미입니다.
그리고, 해당 파일은 ‘OpenAPI’라는 형식을 통해, chatGPT에게 API에 대해 설명하는 내용을 포함합니다.
chatGPT는 사용자의 질문을 받고, 아래 형식의 문서를 참고하여 답변을 제공하게 됩니다.
출처 : youtube ‘노마드 코더’
위 그림이 OpenAPI 형식으로서, chatGPT에게 API의 활용법을 알려주는 내용입니다.
간략하게 정리하면, 위의 ‘url’ 값을 통해 오스카 수상자들의 정보를 가져와서 유저에게 설명해 주라는 내용이죠.
‘paths’를 통해 ‘엔드포인트’, 즉 가져올 값을 지정하고,
‘parameters’를 통해 가져올 데이터의 형태를 지정하는 등
전체적으로 chatGPT가 API에 대해 이해할 수 있도록 설명해 주어야 합니다.
생각보다 간단하게도, 이 3단계를 거치면 플러그인의 구축은 끝이 납니다.
정리하면,
챗GPT에게 manifest를 통해 무엇을 하고 싶은지 알려주고,
auth 인증방법을 통해 유저를 어떻게 식별하고 인증할지 정의해주며,
API에 대해 설명하며 어떤 데이터를 참고해서 답변을 생성할 지 알려주는 과정입니다.
네이버 Skill 기획 방법론
그렇다면, 네이버는 어떠한 방식으로 ‘스킬’을 제작하고 있을까요?
그리고, 기획자의 입장에서 ‘스킬’은 어떻게 기획되고, 개발되어 서비스될까요?
스킬 기획을 비롯한 AI 기획의 핵심은, AI의 ‘생각하는 방식’을 설계하는 것입니다.
AI의 판단을 보고, 이를 하나하나 수정해주어야 합니다.
‘생각하는 방식’이 왜 중요할까요?
본질적으로 AI 기획이 어려운 가장 큰 이유는, 모델의 ‘생각’을 기획자나 개발자, 모델러가 컨트롤할 수 없기 때문입니다.
생성형 AI는 자체적인 판단으로 답변을 생성하며, 그 판단의 근거를 AI에게 물을 수는 있으나
AI의 판단을 모두 알 수는 없고, 이를 완전히 통제하는 것은 불가능합니다.
클로바X의 입력창 아래에 이러한 멘트가 있는 것도 완전한 통제가 불가능하기 때문입니다.이를 아래 그림과 같은 ‘알고리즘 블랙박스’라고 하며, 이러한 한계를 극복하기 위해
‘설명 가능한 AI’가 각광받고 있지만, 생성형 언어모델에서는 아직 완전히 답변을 생성하는 알고리즘을 설명할 수 없습니다.
출처 : IRS글로벌그렇지만, 메이커로그 2편에서 언급한 ‘지도학습’, ‘파인튜닝’과 같은 기법을 통해
제작자가 원하는 대로 어느 정도 답변을 디자인할 수 있습니다.
어떤 답변은 하지 않게, 어떤 답변은 모델이 어떤 API를 참고하도록, 답변의 말투 및 포함할 내용은 무엇으로,
이러한 형태로 모델의 사고 과정과 답변을 디자인하는 것,
나아가 유저가 어떤 대화를 클로바X와 나누게 될지, 그 경험을 설계하는 것이 스킬 기획의 핵심입니다.
그럼 스킬 답변의 기획 요소에 대해 정리하고, 방법론까지 정리해 보겠습니다.
1. 할루시네이션
먼저 가장 먼저 컨트롤해야 할 할루시네이션에 대해 말씀드리겠습니다.
가장 익숙한 예시인 ‘세종대왕 맥북 던짐 사건’과 같은 환각(할루시네이션) 현상이 일어나는 이유는,
본질적으로 생성형 AI는 확률에 기반하여 무조건 응답을 생성하게 되고,
모델의 지식 내에서 확인되는 사실이 없더라도 응답을 생성하다 보니 실제와 다른 거짓말을 하게 되는 경우입니다.
문제는, 정말 그럴듯하게 논리를 맞춰서 답변합니다.
해당 내용이 생성형 AI에서는 가장 치명적인 오류이며, 실시간 정보를 보여주어야 하는 ‘스킬’에서는 더 심각한 문제입니다.
예를 들어 ‘제주공항 근처에 바다 보이고 해물라면 먹을 수 있는 식당 찾아줘’라고 했을 때,
검색 결과가 없다면 없다고 답변해야 하지, 그럴듯한 답변을 통해 유저를 속이면 이는 유저 입장에서 큰 문제가 됩니다.
소위 헛걸음을 하게 되는 것이죠.
기획자 입장에서 통제해야 하는 할루시네이션은 크게 두 가지입니다.
1. 일반적인 할루시네이션으로, 실제가 아닌 답변을 생성하여 답변하는 상황
- 예) 대전에 바다뷰 카페 추천해줘.
2. 실제로 존재할 수 있으나, 현재 Spec 내 기능이 아니기에 정확한 답변이 불가능한 상황
- 예) 도쿄에 가볼 만한 맛집 추천해줘
할루시네이션을 통제하는 방법은, 최대한 많은 경우의 수를 테스트하여, 할루시네이션이 발생하는 Case를 모으는 것입니다.
위의 예시 질문과 같이 유저 입장에서 물어볼 만한 내용들을 포함하여 질문하고, 답변의 진위 여부를 테스트하는 과정이 꼭 필요합니다.
이에 실제로 스킬별로 물어볼 만한 쿼리(질문)를 분류하고, 분류별로 다양한 질문을 클로바X에게 한 뒤,
할루시네이션이 발생하는 쿼리를 확인하고 면밀하게 파인튜닝하여 할루시네이션에 대응하였습니다.
테스트 쿼리 생성 -> 테스트 -> 할루시네이션 확인
-> 파인튜닝 -> 테스트 -> 문제 확인
위 과정을 최대한 많이 반복합니다.
본질적으로 AI 서비스기획은 AI의 능력에 따라 기능이 결정되는 기술 중심의 기획이며, 알고리즘 블랙박스 이슈가 있기에,
우리가 원하는 방향성을 AI가 할 수 있는지 끊임없이 테스트하고, 튜닝하는 과정을 반복하며 발전시키는 과정입니다.
여담으로 기획 업무를 하며 느낀 것은, 기술의 최첨단을 달리는 AI이지만,
실제 업무는 상당히 반복적이며 사람의 능력이 많이 필요하다는 것입니다.
AI는 ‘인공’지능인 만큼, 이 지능을 만드는 사람들의 능력이 인공지능의 퀄리티를 결정하게 될 것이라 생각합니다.
2. Skill 선택
두 번째 스킬 기획의 요소는, ‘스킬 선택’입니다.
유저의 질문을 받았을 때, 모델이 ‘이 질문에 답변하기 위해 어떤 스킬을 써야 하지?’ 라고 판단하는 과정입니다.
출처 : 클로바 시선위 그림은 DAN 23에서 발표된 클로바X가 스킬을 사용하는 과정입니다.
‘렌터카 알아봐줘’ 쿼리에 ‘렌터카 조회 API를 사용해야겠다’로 대응하는 것과 같이,
유저의 질문에서 의도를 파악하고, 해당 의도를 가장 잘 해결할 수 있는 ‘스킬’, API를 선택하는 과정이 필요합니다.
해당 기능 또한 매우, 매우 중요합니다.
만약 저 쿼리에서 쏘카 스킬이 아닌, 네이버 여행 스킬로 판단, 사용하게 된다면,
렌터카를 알아보는 것이 아니라 렌터카를 빌릴 수 있는 업체를 찾아주거나, 혹은 사실과 다른 할루시네이션이 발생할 수 있습니다.
즉, 이러한 ‘판단’과정을 면밀하게 기획하는 것이 중요합니다.
해당 과정은 프롬프트 엔지니어링 평가, 데이터 입력, 학습의 반복으로 이루어집니다.
1) 몇 가지 기준을 모델에게 프롬프트 엔지니어링을 통해 설정해주며,
예) ~~~ 스킬은 ~~~한 상황에서 활용할 수 있고, ~~한 상황에서는 활용될 수 없습니다.
2) 좀 더 세부적으로 모델의 판단만을 위한 데이터를 구축하여 파인튜닝합니다.
데이터의 예시를 들어 설명하겠습니다.
쿼리 : 나 오랜만에 소개팅 하기로 했는데, 입고 갈 만한 원피스 있을까?
질문 type : 의문문
질문 카테고리 : 쇼핑
활용 스킬 : 네이버 쇼핑
액션 : 상품추천
위와 같은 형태로, 모델의 판단 기준을 ‘지도학습’의 형태로 직접 지정하여 학습시킵니다.
그리고, 할루시네이션과 같이 판단의 정확도를 측정, 지속적으로 학습시키고 파인튜닝합니다.
해당 과정을 통해 모델이 유저의 의도에 맞는 스킬을 선택할 수 있도록 합니다.
LLM과의 대화에서, 유저의 의도를 적절하게 이해하고 해결 방법을 찾는 능력은 매우 중요한 능력이므로,
스킬 팀의 기획에서 아주 중요한 목표 지표로 작용하였습니다.
기획에서의 고민 : 이전 대화의 맥락을 기억하는 능력의 중요성
유저와 클로바X의 대화가 길어지고, 유저가 이전 대화의 맥락이 필요한 질문을 하는 경우에, 정말로 판단 오류가 많이 발생하였습니다,
특히 이전 대화에 영향을 받아 오류가 발생하는 경우가 많았습니다.
간단하게 예를 들어,
유저 : “나 오랜만에 이번 주말에 소개팅 가기로 했어, 뭘 준비해야 할까?”
클로바X : “소개팅을 준비 중이시군요! 성공적인 소개팅을 위해 다음과 같은 것들을 준비해 보면 어떨까요?…”
라는 대화를 했을 때,
유저가 “오, 그럼 입을 만한 옷 좀 추천해줘” 라는 질문을 한다면
클로바X는 일반적인 옷이 아니라, ‘이번 주말의 날씨에 맞으며, 소개팅에 어울리는 옷’을 추천해 주어야 합니다.
이런 부분을 기억하지 못하고 다시 ‘이번 주말에 소개팅 갈 때 입을 만한 옷 좀 추천해줘’라고 알려주어야 한다면
사용자 경험이 크게 나빠질 것입니다.
이처럼 멀티 턴(여러 번의 대화)에서의 맥락 기억은 사용자 경험을 위해 포기할 수 없는 중요한 요소입니다.
하이퍼클로바 모델을 활용한 어르신 돌봄 서비스 ‘케어콜’의 성공 요소에도,
‘기억하기’ 기능이 매우 중요하게 작용했습니다.
출처 : 클로바 시선, 케어콜이전의 대화 내용을 기억하고, 어르신들의 건강 및 마음 상태를 지속적으로 여쭈었기에,
성공적인 서비스로 자리매김할 수 있었다고 생각합니다.
생성형 AI가 더 발전하여 개인화 비서의 역할을 하고자 한다면, 가장 중요한 능력 중 하나가 이러한 ‘맥락 이해’입니다.
또한 이러한 ‘맥락 이해’를 넘어, 유저의 기호, 취향을 더 학습하여 더 개인화된 각자의 AI를 활용하는 방향으로 더 발전해야 한다고 생각합니다.
OpenAI 또한 GPTs를 통해 각자의 목적에 맞는 특화된 AI를 제작할 수 있도록 지원하기 시작하였습니다.
또한, 최근에는 답변 방식 뿐 아니라 유튜브 알고리즘과 유사하게 유저의 취향을 학습하는 시도 또한 활발히 이루어지고 있습니다.
실제로 ‘유저의 취향’을 학습하는 방법에 대한 논문을 리뷰하고, 기획에 적용하고자 시도해 보았습니다.
https://five-printer-42c.notion.site/LLM-c3735fe6b51a46d0aeafbcbc1a30a10a?pvs=4
LLM 개인화 논문분석 리서치 및 기획
그 외에도 AI의 개인화에는 아직 발전해야 할 부분들이 많습니다.
예를 들면 언제 어디서나 편리하게 대화를 주고받을 수 있도록 더 원활한 모바일 환경의 지원,
입력의 번거로움을 줄이기 위한 음성 인풋/아웃풋 지원 등을 통해 개인화 AI의 발전이 계속해서 이루어지기를 바랍니다.
똑똑한 AI가 맥락과 기호를 기억하여 ‘개인’에 대해 더 잘 알게 되는 시점부터,
진정한 의미의 AI 개인화 비서가 유저에게 편익을 제공할 수 있다고 생각합니다.
3. 사고 과정 및 답변 생성
AI가 유저의 의도를 이해했고, 어떤 API를 활용할 지 결정했다면,
이제 할 일은 유저의 의도에 맞는 데이터를 호출하고, 생각하고 재구성하여 유저가 원하는 형태의 답변으로 제공하는 일입니다.
출처 : 클로바 시선위 그림에서, ‘액션’ 및 ‘결과’에 해당하는 내용이죠.
이 부분의 기획 내용을 정리하려면, ‘CoT’라는 개념이 필수적입니다.
CoT는 Chain-of-Thought, ‘생각의 사슬’의 약자로, 프롬프트 엔지니어링의 한 방법으로 제시되었습니다.
구글 리서치 팀의 논문입니다. 출처: 하단 링크
https://arxiv.org/pdf/2201.11903.pdf
CoT 프롬프트 엔지니어링은 Few-shot Learning과 어느 정도 유사하게 작동합니다.
모델의 Output이 확실히 바뀌는 것을 볼 수 있습니다.
LLM에게 유저의 질문을 받았을 때, 해당 질문에 답하기 위한 사고 과정을 예시로 제공하면,
LLM이 이 사고 과정을 참고해서 더 나은 추론을 통해 답변을 제공한다는 것이죠.
이와 유사한 원리로, 스킬 또한 일종의 퓨샷 러닝, CoT를 제시하는 방법을 통해 더 나은 답변을 생성하도록
사고 방식을 학습시킬 수 있습니다.
총 3단계로 나누어 생각할 수 있습니다.
1. 유저의 의도 파악
2. 파라미터 추출 및 API 선택
3. 답변 생성
첫 번째로, 유저의 의도 파악입니다.
아래의 예시와 같이 유저의 의도를 파악하고 답변하기 위한 초기 사고 과정을 튜닝할 수 있습니다.
유저 : “나 오랜만에 이번 주말에 소개팅 가기로 했어, 입고 갈 만한 옷 좀 추천해줄래?”
클로바X(사고 과정) : “유저는 입고 갈 만한 옷을 추천받기를 원하니, 쇼핑 스킬을 사용해야겠다. 시점으로 이번 주말을 언급하였으니 12월 2일 날씨에 맞는 옷을 선별하고, 소개팅에 맞는 분위기의 옷을 호출하여 답변을 제공할 수 있겠다.”
이와 같은 형태로 AI의 사고 방식을 제시할 수 있습니다.
두 번째로, 모델은 API를 호출하기 위한 호출 값, ‘파라미터’를 사고 과정에서 생성하게 되는데,
해당 파라미터 또한 생성하는 방식을 제시할 수 있습니다.
예를 들면, 위 대화에서 모델이 추출할 수 있는 파라미터는 다음과 같습니다. 간략한 수준의 예시입니다.
API : 쇼핑 스킬용 API
카테고리 : 의류
계절 : 겨울
상황 : 소개팅
위와 같이 생성된 파라미터를 통해 API를 호출하는 과정이 이루어진 뒤,
세 번째로 모델은 API를 통해 호출한 데이터를 바탕으로 답변을 생성합니다.
예를 들어, 아래와 같이 해당 답변에서 포함되어야 할 내용들을 제시할 수 있습니다.
소개팅에 일반적으로 어울리는 옷을 선택한 기준
소개팅에 어울리는 옷 중, 이번 주말 날씨에 맞는 옷을 선택한 기준
해당 기준에 의해 호출된 옷
해당 옷들이 선택된 이유, 장점
제안할 수 있는 코디법
추가 제안 및 유저가 물을 수 있는 예시 질문
이렇게 세 단계로 이루어지는 AI의 사고 과정을 디자인할 때,
무엇을 중요하게 생각하고 답변에서 강조할 지 여부를 설계하는 것이 필요합니다.
기획에서의 고민 : 유저가 얼만큼 정보를 제공하고, 얼만큼 AI의 판단에 맡겨야 하는가?
이렇게 AI의 사고 과정 및 답변을 설계하다 보면,
답변을 생성하는 과정에서, 어디까지 AI의 판단에 맡기고,
어디까지 유저가 정보를 제공하는 것이 맞을지, 그 정도에 대해 많이 고민하게 되었습니다.
하나의 답변을 생성하기 위해 모델은 여러 단계를 거쳐 수많은 판단과 사고를 해야 합니다.
1) 유저의 의도를 파악하고
2) 유저의 질문에서 조건, 데이터를 어떤 파라미터로 추출할지 판단하며
3) 문제를 해결하기 위해 어떤 ‘스킬’, ‘api’를 쓸지 판단하며
4) api에서 가져온 데이터가 답변에 타당한지 판단하며
5) 데이터를 정제된 답변의 형태로 생성하여 답변해야 합니다.
물론 수많은 언어를 학습한 똑똑한 초대형AI모델은 이 수많은 과정을 잘 해내고 있지만,
유저의 의도와 벗어나게 사고하는 경우, 해당 과정을 교정하기 위해, 더 나은 판단을 위해 수많은 데이터를 파인튜닝합니다.
이러한 과정에서의 리소스 또한 상당하며,
유저의 의도에 맞지 않는 답변이 생성될 경우 사용자 경험이 나빠져 더 이용하지 않을 리스크 또한 존재합니다.
이에, ‘그러면 차라리 AI가 다 판단하지 말고,유저에게 어떻게 판단하는 게 좋을 지 묻는 게 낫지 않을까?’ 하는 고민이 들었습니다.
위의 방식은 명백한 장점이 있습니다.
이러한 방식을 차용하면 AI의 판단을 교정하기 위해 수많은 파인튜닝의 리소스가 필요하지 않게 되고,
유저의 의도에 벗어나는 판단을 하는 일 또한 없을 것입니다.
그러나, 이러한 방법은 유저를 번거롭게 하며, 대화형 UX의 장점인 ‘간편함’을 잃게 된다는 큰 단점이 있습니다.
이에, 기획 과정에서 협의를 통해 기준점을 정하여,
어느 정도까지의 정보는 유저에게 다시 질의하여 명확하게 정의하고,
어느 정도까지의 정보는 AI의 정확한 판단을 위해 파인튜닝하는 과정을 수없이 반복하였습니다.
이러한 판단은 유저의 목소리, 리소스의 현황, 최종적으로 원하는 프로덕트의 형태 등 많은 것들을 고려하여 판단합니다.
이처럼 기획에서의 고민은 수많은 판단의 기준들을 고려하여, 각 방향성의 장점과 단점을 파악하고,
조직의 우선 순위에 맞게 저울질하며 판단하는 과정임을 배우게 되었습니다.
4. AI 윤리, 답변 정제
그렇다면, ‘스킬’을 통해 답변하는 모든 과정을 기획하였으니, 여기까지가 일의 끝일까요?
아닙니다, 저희가 기획한 프로덕트라면, 해당 프로덕트가 사용자에게 위해를 끼칠 수 있는 가능성을 차단함으로써
안전하고 즐겁게 활용할 수 있는 프로덕트로 만드는 과정이 필요합니다.
해당 과정의 중요성은 2020년 말 출시된 ‘이루다’에서 증명되었습니다.
2020년 12월 23일 출시된 AI 챗봇 ‘이루다’는, 3주 만에 약 80만 명의 이용자를 끌어모으며 성공가도를 달리는 듯 보였습니다.
그러나 성소수자 혐오, 사회적 차별 발언, 개인정보 유출 등 AI 윤리 논란에 휩사이며 서비스가 종료되었습니다.
유저를 불편하게 하는, 논란이 될 수 있는 답변을 제공하는 것은 분명히 막아야 합니다.
이러한 문제를 예방하기 위해, 네이버의 AI 프로덕트는 네이버의 ‘AI 윤리 준칙’을 따라 안전하게 설계되고 있습니다.
[출처] [클로바 시선#5] AI는 사람을 도울 수 있을까?
해당 윤리 준칙 아래에, 스킬 팀은 유저에게 위해를 끼치거나 불편함을 일으킬 수 있는 답변들을 정제하는 과정을 거쳤습니다.
1) 특정 정치적, 개인적 성향을 반영하는 편파적 답변
2) 특정 사회 집단 대상을 혐오하는 답변
3) 자해, 타해 등 본인 혹은 타인에게 해를 끼칠 수 있는 답변
이러한 답변을 유도하는 유저의 질문들을 클로바X가 ‘위험한 질문’으로 인지하고,
AI 윤리준칙에 근거한 안전한 답변을 제공할 수 있도록 파인튜닝하였습니다.
이러한 과정을 통해, 누구나 즐겁게 활용할 수 있는, ‘사람을 위한 AI’ 프로덕트를 만들기 위한 과정을 수행하였습니다.
지금까지, 근무하며 수행한 AI 서비스기획, Skill 서비스기획의 방법론에 대해 다루어 보았습니다.
Skill의 기획은, 일반적인 UI&UX, 서비스기획과 공통점과 차이점을 모두 가집니다.
공통점은, 마치 일반적인 UI&UX를 설계하듯이, 유저의 니즈를 파악하고, 우선순위를 결정하며, 정보의 표시 방식을 결정합니다.
차이점은, AI의 알고리즘은 완전하게 통제할 수 없기에 원하는 방향을 최대한 자세하게 프롬프트 엔지니어링을 통해 설명하며,
원하는 답변이 있다면 수많은 데이터의 생성, 파인튜닝, 테스트를 통해 원하는 형태로 모델의 답변을 설계하여야 합니다.
정리하면, 작동 과정을 다 알 수 없고, 기획자의 마음처럼 생각하지 않는 AI를최대한 명료한 프롬프트 엔지니어링과 파인튜닝으로 설계하는 과정입니다.
어쩌면 모르기에, 더 재미있을 수 있는 과정입니다.
저는 그럼 다음 메이커로그로 돌아오겠습니다.
다음 메이커로그에서는 해당 방법론으로 기획되어 실제 서비스되고 있는
네이버 쇼핑, 네이버 여행, 쏘카 스킬의 기획 과정에 대해 작성하겠습니다.
아직도 클로바X에서 이렇게 서비스되는 것을 보면 신기하면서 뿌듯할 따름입니다.
좋아요, 댓글, 이웃추가 등의 모든 반응은 언제나 큰 힘이 됩니다, 감사합니다.
Contact
�hsm4680@naver.com
�� 개인 포트폴리오
https://five-printer-42c.notion.site/a9d04461ba8c44a7bbbbbede06064d20?pvs=4
