작은 도움이 필요할 때, Leon
Unexpected Delight! 기진님과의 최종 아이템 선정 미팅이 끝나고, 윤성님 유혹 작전(?)이 거의 끝나갈 무렵이었어요. 그 동안 사업부에서는 외부 미팅으로 바쁜 나날을 보내고 있었는데요, 사업부의 외부 미팅 기록을 살펴보니 “자연어로 질의하면 SQL 쿼리문을 도출해주는 서비스가 있으면 좋을 것 같다”와 “내부 생산성을 향상시킬 수 있는 Tool이 있으면 좋을 것 같다”는 Information이 생각보다 많았어요. 원래 계획대로라면 2nd-Cycle에서 하나의 아이템이, 3rd-Cycle에서 또 다른 하나의 아이템이 나와야 하지만, 이 아이템은 3rd-Cycle까지 진행하기로 결정되었습니다.
시간이 더 늘어서 좋을 줄 알았지만, 웬걸요. 2nd-Cycle에서 나와야 하는 Output과 3rd-Cycle에서의 최종 Output, 두 개가 나와야 한다는 것는 변함이 없었어요. 다만, 윤성님을 주축으로 진행될 서비스 개발에서는 조금 변화가 생겼는데요, 연구원 분들에게 AI에 관련된 지식과 교육을 따로 진행해야 하니, 3rd-Cycle에서 최종 결과물만 나오면 되는 것으로 결정되었습니다. 결론적으로 서비스 기획과 개발은 동시에 진행되지만, Output은 서비스 기획과 디자인이 One-step 더 앞서 나오게 될 예정이었죠(윤성님과 연구원분들의 엄청난 노력과 열정에 2nd-Cycle에서 Streamlit으로 개발된 Service Prototype이 나왔습니다).
아참, 이전 아티클에서 잠깐 언급했는데요, Speech to SQL의 서비스명은 Leon으로 결정되었습니다.
Tmax의 언어모델인 SPARATA(Llama 3.0을 Fine-Tuning한 언어모델)를 누구보다 잘 다룰줄 아는 사람이 되길 바라는 기진님의 말씀을 바탕으로
스파르타의 국왕, Leonidas에서 이름을 가져왔습니다.
그렇다면 이제, PM manger 신영님과 하루 종일 붙으며 Speech to SQL, Leon을 기획했던 스토리에 대해 말씀드릴게요.
이전 내용을 놓치셨나요? 아래의 링크에서 2nd-Cycle Story Part.1의 모든 Story를 확인하실 수 있어요.
Service goal
Leon이 도와줄 수 있는 일은
제일 먼저 신영님과 논의했던 것은 과연 “Service Goal은 무엇이어야 하는가”였어요. 이 서비스를 사용하게 될 사람들의, Leon을 사용하는 목적은 “DB Table을 조회해서, 원하는 답을 얻기 위함”이었는데요, 그렇다면 “Leon을 사용하지 않고서는 원하는 답을 얻을 수가 없나?”라는 대화를 주고 받았어요.
정답은 No. 당연히 아니겠죠. 말 그대로 DB에서 Query문을 직접 작성해 원하는 결과를 확인할 수 있어요. 하지만 이 과정에서 수많은 문제가 발생하고, 문제를 해결하는 데에 많은 장벽이 존재해요. 그 문제점과 장벽들은 아래와 같습니다.
첫 번째, 개발자를 제외한, 마케터, 디자이너와 같은 비개발직군은 Query문을 작성할 수가 있나? 두 번째, Query문을 작성할 수 있다고 하더라도 DB에 접근할 수 있는 권한이 모두에게 주어져있나? 세 번째, 그렇지 않다면, 담당자를 통해서 확인을 해야 할텐데, 그 비즈니스 로직은 각 기업마다 어떻게 구성되어 있으며, 원하는 결과물을 받는 데까지 얼마의 시간이 소요되고, 얼마의 커뮤니케이션 비용이 요구되는가? 마지막으로, 사용자는 이 일련의 행위들을 통해 어떤 목적을 달성하려고 하는가?
이 의문들에 대한 답은 추후 한국투자증권의 디지털혁신본부, 한국투자저축은행의 IT기획팀과의 미팅기록에서 확인할 수 있었습니다.
“캠페인 성과 평가, 응답률 데이터, 추세 분석 등 다양한 데이터가 필요한 경우가 많은데, 담당자가 한 명이라, 그 분이 소화해야 하는 업무가 너무 많아요. 작업 지시서를 작성해서 담당자에게 요청해야 하는데, 결국에는 전화를 걸어서 해결합니다. 작업 지시서가 오고가면 답변 받는 데에 일주일도 넘게 걸릴 거에요. 작업 지시가 오고 가는 로그가 남지 않다 보니까 결과값이 맞는지 검증도 못하고 보고서를 올리는 경우도 많구요.”
단 하나의 목적, Productivity
신영님과 위의 답을 살펴보며, Leon은 Productivity(생산성)이라는 단 하나의 목적을 가진 서비스가 되어야 한다는 결론을 내렸어요.
데이터 담당자 뿐만이 아닌, 누구라도 간편하게(Easy to use) 자연어 질의를 통해 데이터를 확인하고, 커뮤니케이션에 들어가는 비용을 최소화(Effective)해야 합니다. 추가적으로 커뮤니케이션에 들어가는 비용을 최소화하기 위해서는 LLM 모델이 내놓은 답을 신뢰할 수 있어야 합니다(Reliable). 궁극적으로 서비스를 이용하는 사람의 업무 생산성(Productivity)를 향상시켜야 한다는 것으로요. 신영님과 저, 그리고 연구원분들은 Productivity라는 가치에 초점을 맞추고 Service Goal을 향해 달려나갔습니다.
Tech Section에서 더 자세하게 다루겠지만, Leon에는 RAG(Retrieval Augmented Generation, 검색 증강 생성)를 이용해 LLM 모델의 Hallucination을 줄이고, Prompt를 통한 정확도를 높이기 위해 질문과 답변에 예제를 추가하는 방법, Example Selector(예제 선택기)를 삽입되어 있습니다. 그리고 LLM모델이 LLM 답변을 평가하는 2개의 Evaluator(평가자)를 두어 답변의 정확성을 더욱 향상시켰죠.
Leon이 답변을 내놓는 과정
FEVER팀이 그리는 Leon의 모습
ChatGPT한테 물어봐 vs ChatGPT에 검색해봐
혹시 여러분은 필요한 정보를 찾을 때, 어떤 경로를 이용하시나요? 저는 올해 8월부터 ChatGPT를 결제해 사용하고 있는데요, 질문의 단계를 심화시켜야 하거나, 맞춤형 정보를 제공받고 싶을 때 Google 대신 이용하고 있습니다. 저를 포함한 사내 구성원들 대다수가 ChatGPT 혹은 Gemini와 같은 AI기반 대화형 에이전트 서비스를 이용하고 있는데요, 한 가지 신기했던 점은 팀원 혹은 구성원들은 모두 ChatGPT한테 “물어보세요”라고 말했던 것이었어요. 모르는 것이 있을 때, 잘 해결되지 않는 문제가 있을 때, 승민님한테 한 번 물어보세요, 기진님한테 물어보세요와 같은 대답을 듣곤 했는데요, “ChatGPT한테 물어보세요”라는 대답을 듣고난 후 사람들은 AI로부터 질문에 대한 답과 정보를 제공받지만, 함께 일을 하고 있는 동료로서 인식하고 있는 건 아닐까? 하는 생각이 들었습니다. 만약 그렇다면 여러 명의 동료를 두어, 목적에 맞는 대화를 나눌 수 있겠다고 생각했죠.
내 자신조차도 ChatGPT를 동료로서 인식하고 있던 것은 아니었는지
Chat interface
ChatGPT, Gemini와 KakaoTalk, Facebook Messenger등의 Interface를 참고하면서, 몇 가지 추가하거나, 제거해야 할 요소들을 확인해봤어요. 일단 제일 먼저 ChatGPT에게 물어봤던 질문들을 확인해봤는데요, ChatGPT는 지금까지 나누었던 대화를 월별로 나누어 Side 영역에 보여주고 있습니다. Thumbnail title은 초기 질문 내용을 기준으로 자동 설정되고, 이후 다른 대화가 전개되더라도 제목이 유지되는 방식입니다(from. ChatGPT). 이 방식을 유지하다보니 한 가지 불편했던 것은, 이전에 나누었던 대화를 찾기가 어렵다는 것이었어요.
예를 들어, 첫 질문이 “맥용 ChatGPT 다운로드 방법”이고, 다음 질문이 “무료로 사용이 가능한 파워포인트 템플릿을 제공하는 플랫폼”일 때, Thumbnail title은 “맥용 ChatGPT 다운로드 방법”으로 설정이 돼요. 그러나 후자의 질문에 대한 답을 다시 찾고 싶을 때에는 많은 번거로움이 생겨요.
'Download ChatGPT for Mac' 안에서 나눈 다른 주제의 대화
그래서 저와 신영님은 아래와 같은 사항에 대해 고민하며 Chat interface를 어떻게 활용하면 좋을지 논의하며 요구사항 정의서를 작성해 나갔습니다.
개개인 vs 개인
첫 번째는 개개인과 개인의 차이인데요, 일반 Messenger의 경우, ‘개개인’과 대화를 나누지만, ChatGPT의 경우 ‘하나의 개인’과 대화를 나누기 때문에, 대화를 채팅룸을 나누었다고 하더라도, 이전에 나누었던 대화를 다시 꺼내기가 어려워요. A에게는 A’에 대한 대화를, B에게는 B’에 대한 대화를 나누면 되지만, C에게는 C와 D를 모두 말해야 하는 상황인거죠. 대화의 목적이 다른 경우, 대화가 길게 이어지는 경우, 이전에 나누었던 대화 내용을 이어가야 하는 경우를 생각한다면, ‘개인이 아닌, 개개인으로 분리’하는 것이 좋을 것 같다고 생각했어요. 그렇게 된다면 개개인은 프로젝트 혹은 지속적으로 진행하는 업무 등이 될 것 같습니다.
프로필 사진(Image) vs Title thumbnail(Text)
두 번째는 개개인을 인식하는 방법의 차이입니다. 일반 Messenger의 경우, 개개인을 ‘프로필’과 ‘이름’으로 구분하지만, ChatGPT는 ‘첫 질문이 요약된 Title’로만 채팅룸을 구분해야 합니다. 단어의 의미를 이해하며 읽어야 하는 텍스트 정보 보다는, 더 쉽고, 빠르고, 한눈에 담을 수 있는 이미지 정보를 제공하는 게 훨씬 정보 접근성에 유리할 것 같습니다.
System notification
마지막은 서비스 정책과 관련이 있는데요, Leon의 요금제에 대해 많은 의견을 나누었습니다. 구독제가 아닌, 서비스 기본 이용료와 토큰 사용량에 따라 월 요금을 부과할 예정이었는데요(확정된 것은 아니었습니다), 사용량에 따라 요금이 과하게 부과될 가능성을 염려해 System notification의 기능을 추가해야 했습니다. System notification은 또 다른, 하나의 '개개인'으로 정의했기 때문에 Chat interface를 활용하는 게 좋을 것 같았습니다.
신영님이 성심성의껏 정리해주신 요구사항 정의서
User define
사용자에게 Leon이 필요한 순간 - Scenario
Chat interface의 모습을 띄게 될 Leon, Leon이 제공할 기능과 모습들을 신영님과 정리 후, "사용자가 언제 Leon을 찾게 될까?"라는 질문을 바탕으로 Scenario를 그려나갔습니다. 어떤 사용자가 있는지, 그 사용자는 어떤 Pain point를 가지고 있고, Leon이 어떻게 해결해줄 수 있는지를 정리했죠. 총 8개의 Scenario를 그렸는데요, 수협은행, 그리고 한국투자증권과 미팅을 하고 온 사업무 매니저님들의 생생한 목소리가 담긴 Scenario 8을 바탕으로 User persona & journey map을 만들어 나갔습니다.
User scenario
User persona & journey map
User persona
수협은행 디지털 금융부에서 근무하고 있는 36세 여성, 김지수님은 온라인 마케팅과 제휴 마케팅을 통해 금융 상품을 홍보하고 있습니다. 마케팅 캠페인을 기획하고, 실행하기 위해서는 데이터 분석을 통해 성과를 정확하게 분석하고, 전략 수립 및 개선 방안을 지속적으로 확인할 수 있어야 합니다.
Journey map
수협은행 디지털 금융부에서 근무하고 있는 36세 여성, 김지수님이 Leon을 사용하지 않았을 경우와 Leon을 사용했을 경우에 발생할 수 있는 UX scale, emotion, experience, expectation, 그리고 예상 결과입니다.
MVP of Leon
2nd-Cycle에서 Leon은 크게 세 가지 기능을 중심으로 기획 & 디자인 & 개발되었는데요, 사용자가 Voice 혹은 Text로 질문을 입력하면, Leon은 그 질문에 대한 답변을 내놓는 기능입니다. 답변에는 SQL Query, 시각화된 결과물(Chart and graph), 그리고 AI보고서가 있어요. AI보고서는 Leon이 추후 Speech to SQL에서 Speech to Insight로 Level-up했을 때 나올 기능인데요, 자세한 내용은 3rd-Cycle Story에서 공개하도록 하겠습니다.
Information architecture
UX design prototype
2nd-Cycle에서 진행된 최종 UX design prototype은 아래의 영상과 같아요. 여기에서는 Figma prototype을 확인하실 수 있습니다.
Leon design prototype
Service prototype
이 Article 첫 부분에서도 말씀드렸다시피, Service prototype은 3rd-Cycle에서 진행될 예정이었는데요, 윤성님을 비롯한 연구원분들의 엄청난 노력으로 Streamlit으로 개발된 Service prototype을 2nd-cycle에서도 볼 수 있게 되었습니다.
Service prototype은 배달의 민족 데이터를 바탕으로 만들어졌어요. Service logic, data structure 등, Service prototype을 만들기 위해 최소한의 재화가 들어가는 서비스를 선택했고, 이 데이터 역시 윤성님께서 주말 밤낮을 꼬박 새며 만들어주셨습니다! 아래에서 Leon의 ERD와 Service prototype을 확인하실 수 있어요.
Leon ERD
Leon service prototype