🎱 생애 첫 투 서버 도전기, 서버 두 개를 클린~하게 운영해보아용 - [2탄] 내가 짠 플로우가 틀렸다고? 개발 도중 플로우 갈아엎기

🖤 Intro

자 저번 1탄에 이어서 이번에는 개발 도중에 플로우가 틀려서 갈아 엎었어야 했던 이야기에 대해서 해볼까 한다.

나의 경우는 사실 챗봇 자체도 처음이고, 서버끼리 통신하고 데이터 주고 받는 것 자체도 이번이 처음이기 때문에 구조와 플로우를 잡는데 상당히 시간을 많이 들였다.

🤯 그 와중에 개발 거의 마무리 단계쯤 내가 짠 플로우가 틀렸다는 것을 알아챘다!

사실상 MVP 제출이 얼마 남지 않은 상황이라, 지금 상황에서 플로우를 뜯어 고친다는 것은 많은 리스크가 존재하기는 하지만, 좋은 결과물을 위해서 이정도 노력도 못하랴

그런 의미에서 오늘은 왜 플로우를 바꾸게 되었는지, 바뀐 플로우에서 얻을 수 있는 장점은 무엇인지를 먼저 얘기하고, 3탄에서는 바뀐 플로우로 어떻게 개발을 진행했는지를 풀어보고자 한다.

🩶 Start

기존 플로우는 어땠는데?

사실 우리 챗봇의 경우, “요약본”만을 DB에 저장하기로 했었기 때문에

타 챗봇에서 벡터 DB를 사용해서 메세지를 불러와서 맥락을 파악했던것과 방향을 다른 식으로 끌고 갔어야 했다.

그래서 처음에 생각했던 방식은, 각 채팅 마다 채팅 생성시 필요한 요소가 있고 (예를 들어, 취미를 물어보는 채팅에서는 취미 값이 필요하고, 사용자의 기분을 확인하는 채팅에서는 기분값을 확인해야 하고 이런식이다) 우리는 맥락을 따로 저장하지 않으니, 각 채팅 요청 API마다 따로따로 Request, Response dto를 만들어서 채팅마다 필요한 정보값을 실어보내자!라는 아이디어였다.

이를 시퀀스로 나타내면 다음과 같다.

자 이렇게 일단 개발까지 마무리하고 바로 llm 연동을 통해 플로우를 test 해보았다.

여기서 치명적인 문제점이 생겼는데, 과연 무엇이 문제였을까?

문제상황 ) LLM이 맥락을 모르니, 대화가 이어지지 않는다!

LLM을 사용하는 주된 목적이 무엇일까?

바로 사용자 맞춤형 채팅을 & 맥락을 이해해서 응답하여 꼭 대화가 이어지는 것처럼 진행한다는 것이다.

진짜 채팅을 하는 것 같은 챗봇을 만들자는 것이 우리의 목표였기에 이 부분이 매우 중요했다.

그러나, 각 채팅마다 필요한 값을 전달하고 맥락을 전달하지 않으니, 매 대화마다 마치 새로운 대화를 시작하는 것 같은 느낌을 준다는 치명적인 단점을 발견했다.

프롬프터 엔지니어링으로 이어지게끔 가능하지 않을까? 싶어서 이 부분도 시도해봤지만 역부족이었다….

아 이 부분 스크린샷을 찍어 뒀어야 했는데 말이다!!!!!!

그 와중에 문제가 하나 더 있었다. 바로 각 말풍선 채팅 요청마다 실어 보내는 값이 다르고, 응답이 다르다 보니

이렇게 채팅 관련 DTO가 채팅 마다 생기고, 이에 따른 서비스도 불필요하게 많이 중복된다는 것이었다.

챗봇의 장점이자 가장 큰 특징은 자유도인데, 이렇게 개발하면 오히려 챗봇의 특징에 매우 어긋나는것 아닌가? 이정도면 솔직히 안티 패턴에 가깝지 않나? 고민에 빠졌다……

그러나 우리에게는 DB에 저장하지는 않아도

캐싱 특화 되어있는 메모리 DB인 레디스!!!!가 존재한다.

그렇다면, 레디스에 대화 맥락을 저장해두고 이걸 LLM에 요청시 사용하게끔 한다면, API가 훨신 간단해지고 응답도 대화가 이어지는듯한 자유로운 응답이 가능하지 않을까?

로직 리팩터링) Redis를 이용해서 대화 맥락을 파악하도록 하자!

그래서 플로우를 뜯어 고치기로 마음먹었다.

채팅 플로우에 필요한 사용자 정보 값들을 어떤 말풍선이든, 항상 동일하게 흘려보내고, 대화 맥락을 redis에 캐싱해서 llm에 대화 맥락 & 프롬프터 & 사용자 정보 값 받은 것 & front에서 받은 메세지들을 항상 동일하게 request에 보내는 방식으로 API 양을 줄이고, 챗봇의 자유도는 살리되 아웃풋은 더 향상되도록 하는 것이다.

플로우가 더 복잡해진거 같지만 이렇게 하면 불필요한 중복 코드량도 줄일 수 있고, 자유도도 훨씬 올라가며 플로우 관리 및 프롬프터 관리를 전부 FAST API에 위임하는 것이 가능하다.

시간이 얼마 안남은 상황이라 고민이 많았지만, 누가봐도 리팩토링한 방식이 올바른 방식이기에 걍 내가 잠 좀 줄이고 코드 로직 싹 다 갈아 엎기로 했다.

코드를 어떻게 바꾸었는지는 3탄에 계속~