2nd-Cycle이 끝난 후 두 가지의 변화가 생겼는데요, 첫 번째는 바로 팀원의 변동입니다. Leon의 서비스 개발에 힘을 보태어줄 광원님과 상민님이 FEVER팀에 합류하게 되었습니다. 사실 여기에는 FEVER팀 중 한 명의 퇴직 문제가 있어, 광원님이 그 업무를 이어받을 예정이었지만, 퇴직이 보류(?)되었고, 광원님은 3rd-Cycle부터 FEVER팀에 합류하게 된 것이죠! 광원님이 합류하고 나서 FEVER팀이 그리는 Leon의 마지막 모습에 한 걸음 더 다가간 듯한 기분을 받았습니다. 상민님은 3rd-Cycle 기간에만 현지님과 함께 프론트엔드 부분을 도와주시기로 하셨구요!

두 번째는 2nd-Cycle에서 지었던, Speech to SQL의 서비스명, Leon을 사용할 수 없다는 것이었어요. Tmax Group에서 최종적으로 서비스를 배포할 때, 서비스명에 대해 고민하고 작명하시는 한 분(?)이 계시기 때문에, 그 분의 허락없이는 Leon이라는 이름을 사용할 수 없었던 것이죠. 이렇게 되면, 신영님과 저의 고민이 많이 깊어질 수밖에 없는데요, 3rd-Cycle에서는 Leon에 Identity를 부여하고, 서비스를 기획하기로 Roadmap 상에 올려놨기 때문이죠.

신영님과 머리를 맞대고 한참을 고민하다 결국 해결책을 찾지 못한 채, Leon을 고도화할 수 있는 서비스 기획 먼저 진행하기로 했습니다. 당장 풀리지 않는 건 나중에 천천히 생각해보기로 하면서요. 결론적으로 제 반항심이 아주 살짝 담긴 ËÖ라는 이름을 사용했는데요, 그 이유와 배경은 천천히 아래에 적어보도록 하겠습니다.

세 가지의 변화

Goal은 여전히 생산성을 향해

2nd-Cycle과 비교해볼 때, Leon은 3rd-Cycle에서는 크게 세 가지의 변화가 생겼는데요, 첫 번째는 강화학습과 추천 키워드, 두 번째는 Room 생성과 AI Report, 그리고 마지막은 Leon의 아이덴티티입니다. 그 외 Leon과 상호작용할 수 있는 Interaction design, Visual design, 그리고 개발의 영역에 있어서 많은 변화도 있지만, 이건 이미지와 비디오를 통해 짧게 소개하도록 할게요. 그렇다면 강화학습과 추천 키워드부터 소개할게요.

Good or Bad

Leon의 강화학습은 2nd-Cycle에서 이미 논의가 되었던 내용인데요, 아래의 이미지를 보면 사용자는 Leon의 답변에 대해 Good 혹은 Bad를 선택할 수가 있어요. Leon을 업무를 함께 진행하는 개개인 중 한 명으로 정의했고, Leon의 메세지에 대해 감정 표현 기능을 넣는 것은 어떨까? 라는 질문에서 시작됐는데요, 이 기능을 단순히 감정표현에 그칠 것이 아니라, 이 다음에도 사용자의 질문에 대한 답에도 긍정적인 영향을 미칠 방법은 없을까라는 생각이 들었죠.

사실 좋아요, 싫어요, 넵, 헐, 다양한 이모티콘 등을 넣으려고 했는데요, 이것을 Leon의 강화학습을 위한 기능으로 사용하기로 한 순간부터 Thumbs up / Thumbs down 두 가지 기능으로 정리를 했습니다. 하지만 생각해보면, 사용자가 과연 Leon의 답변에 일일이 좋아요, 싫어요를 누를까? 라는 의문이 머리에 맴돌았어요. FEVER팀도 KakaoTalk, Wapl, Messenger 등을 이용할 때, 특별한 경우를 제외하면 감정표현을 잘 하지 않는다고 얘기가 나왔거든요. 그래서 3rd-Cycle에서는 과감하게 Thumbs down만 노출시키기로 했어요. 사용자가 정말 '이 답변은 정말 최악이다', 혹은 '이건 정말 연관이 없는 답변이다'라는 생각이 들었을 경우에만 Thumbs down을 누르고, '이 답변은 적절하지 않다'라는 것을 Leon에게 인식시켜주는 것으로요.

결정 제안: Keywords of Insight

여기서 신영님과 논의한 것 중 또 다른 하나는 바로 추천 키워드, Keywords of Insight입니다. 한국투자증권의 VoC를 바탕으로 생각하게 된 사용자 flow인데요, 2nd-Cycle Story Part.2에서도 언급한 내용입니다.

"작업 지시서를 작성해서 담당자에게 요청해야 하는데, 결국에는 전화를 걸어서 해결합니다. 작업 지시서가 오고가면 답변 받는 데에 일주일도 넘게 걸릴 거에요. 작업 지시가 오고 가는 로그가 남지 않다 보니까 결과값이 맞는지 검증도 못하고 보고서를 올리는 경우도 많구요."

실무자의 경우 어떤 데이터를 Join해야 하는지, 어떤 데이터가 Join 되었는 지를 파악하는 것은 거의 불가능에 가까워 보였어요. 추천 키워드를 제공함으로써 더 정확한 데이터를 받고, Business logic을 남김으로써 추후 업무 생산성에 긍정적인 영향을 미칠 수 있겠다고 생각했습니다.

업무 대행의 역할: Room 생성과 AI Report

두 번째는 사용자가 프로젝트 별로 Room을 생성하고, 그 안에서 AI Report를 추출하는 기능이에요. 2nd-Cycle에서 프로젝트 별로 룸을 생성해 관리하는 것을 논의했었는데요, 3rd-Cycle에서 이 내용이 다시 나온 이유는 바로 'AI Report' 기능 때문입니다. 하나의 Room에서 Leon과 대화를 주고 받으면 많은 양의 대화가 쌓이게 될텐데요, 그 대화 안에는 사용자에게 필요한 내용과 필요하지 않은 내용이 혼재되어 있을 거에요. 그 필요한 내용만을 선택해 AI가 정리하고, Report로 추출해주는 기능입니다.

처음 신영님과 논의했을 때에는 Room 안에서 나온 내용을 모두 종합해 하나의 pdf file로 만드는 방법을 생각했어요. 하지만 팀원들과 논의를 해보았을 때, 사용자에게 필요없는 내용도 포함이 되기 때문에, 양질의 인사이트를 포함한 Report인지에 대해서는 확신할 수 없다는 것이었죠. 한참을 어떻게 해야 하나 고민하는 와중에 윤성님께서 Report 생성에 필요한 내용만 선택해 Report로 추출하는 건 어떤지 의견을 주셨어요. 사용자와 Leon의 대화마다 Keyword를 이용해 저장해놓을 수 있고, 그 내용들만을 모아 Report를 만드는 것이었죠.

윤성님의 의견을 받고, 신영님과 저는 AI Report를 생성할 때 필요한 요소들을 정리했어요. 사용자가 질문하고, Leon이 답변한 내용들 중 필요한 결과값만 선택하여 제목, 작성자, 작성일자, 데이터 분석 결과 요약, 보고서 전체 요약이 포함된 AI Report 기능을 정리해 연구원분들과 공유했고, 이 부분은 최종적으로 4th-Cycle 이후에 진행하는 것으로 결정했습니다.

참고로 3rd-Cycle에서도 AI Report를 받아볼 수는 있는데요, 사용자의 질문에 대해 답을 할 때 마다 생성되는 1회성의 Report에요. 아래의 영상에는 반영되어 있지 않지만, 사용자의 질문에 '레포트 혹은 리포트', 'Report', '보고서'등의 단어가 포함될 때에만 Report를 출력하는 것으로 수정되었습니다.

보이지 않는 큰 변화, 개발

Prompt Engineering

이번에는 개발 부분에서의 변화를 설명드리려고 하는데요, 첫 번째는 Prompt Engineering입니다. LLM 모델이 구체적으로 수행해야 하는 역할과 능력을 설정해 훈련시켰어요. 동규님이 많이 수고해주셨죠. 이 과정에서 다양한 훈련 템플릿을 적용하여, AB 테스트를 통해 사용자가 요청한 결과를 정확하게 반환하는지를 검증했습니다. 아래의 영상을 통해 확인하실 수 있는데요, 아래의 예시는 FEVER팀이 직접 사용했던 수많은 템플릿 중 하나에요. LLM 모델을 교정 전문가로 설정해서, 오탈자 등 수정이 필요한 단어나 문장을 문맥에 맞게 수정할 수 있도록 일종의 슈퍼파워를 부여했죠. 그렇기 때문에 아래의 영상처럼 오탈자가 심한 질문을 입력했을 때에도 문맥에 맞게 질문을 수정할 수 있었습니다.

LangGraph

LangGraph는 LangChain 생태계의 일부로, 복잡한 AI Work flow를 구축하기 위한 강력한 프레임워크인데요, RAG의 파이프라인을 유연하게 설계해 답변을 생성하는 과정에서 문제가 있거나 정확도가 떨어질 때, LLM 모델이 평가자로서 피드백을 제공하고, 이전 혹은 어떤 단계로 돌아가야 할지에 대해 판별해 최종 답변을 보완해주는 역할을 하고 있습니다. 평가자로 활약할 LLM 모델에게 적합한 평가 기준을 만들어주고, 문서 검색 결과에 원하는 정보가 없거나 혹은 생성된 결과값이 적합하지 않을 때, 다시 적합한 단계로 돌려보내기 때문에 최종 답변의 정확도가 올라갈 수 있는 거죠.

ËÖ Prototype

아래는 Figma로 만들어진 Design prototype video입니다. 어떤 기능들을 담아야 매력적인 Prototype video가 될까를 신영님과 많이 고민해서 만들었습니다. 3rd-Cycle Keynote에는 아래의 Prototype과는 별개로, 윤성 & 현지님이 시연한 Service prototype이 따로 있었어요.

Leon에 Identity 부여하기

ESFJ의 멘토

다 끝난 줄 알았지만, 아직 해결해야 할 문제가 하나 남아있었죠. 바로 Leon의 Identity를 부여하는 일입니다. 여기에는 재미있는 연구 결과와 견해가 존재하는데요, 첫 번째는 AI에게 인간적인 면이 드러날수록 사용자들은 AI와 정서적으로 친밀감 혹은 사회적 유대감을 느끼고, 상호작용을 긍정적으로 받아들일 가능성이 높아진다는 연구 결과이구요, 두 번째는 많은 연구자들과 디자이너들이 AI를 인간과 유사하게 만들기 위해 갖은 노력을 해왔지만, 사용되는 목적에 따라 인간다운 정도를 조절해야 한다는 것이었어요.

인간다움을 드러내는 방법은 여러 가지가 있습니다. 언어적 & 비언어적 표현, 감정표현, 대화 패턴, 일상적 단어 사용, 상대방의 상황과 의도를 파악하여 미리 대응하는 선제성 등 시각적, 대화적, 행동적 측면에서 인간다움을 설정하는 것이죠.

Leon을 함께 업무를 진행하는 개개인 중 한 명으로 정의했기 때문에 인간다운 정도를 어느 정도 조절해야 했는데요, 함께 업무를 진행해야 하는 Leon을 심심이와 같이 만들 수도 없으니, 좋은 Persona를 정하는 게 중요했습니다.

한참 혼자서 Mind mapping을 하다 ‘내가 함께 일하고 싶은 사람은 누구일까?’라는 생각이 들었어요. 친절하고, 따뜻하고, 좋은 말과 조언을 해주고, 모르는 것이 있으면 알려주고, 똑똑하고. 여러 가지의 특징들을 산발적으로 적어 내려가다보니 첫 직장의 멘토가 생각나기도 했습니다. 대화를 주고 받을 때의 애정어린 눈빛이 떠오르기도 했구요. 이러한 산발적인 생각들을 가지고 신영님께 미팅을 요청했고, 신영님은 무릎을 ‘탁’ 치는 동시에 신영님의 경험과 생각들을 Mind mapping하기 시작했어요.

모르는 것을 누군가에게 물어본다는 것, 해결책을 제시하는 것, 똑똑한 것, 따뜻한 시선과 함께 진심 어린 조언을 건네주는 우리들의 멋진 Mento를 생각하며 Leon의 Identity를 만들어가기 시작했습니다. 그런데 잠깐, Leon이라는 이름을 사용하지 못하게 되었다고 했는데 왜 자음만 제거하고, eo에 Umlaut가 추가된 형태냐구요?

그 자세한 스토리, 그리고 Speech to SQL, ËÖ의 마지막 스토리는 아래의 링크에서 확인하실 수 있어요:)

3rd-Cycle Story Part.2