“시니어가 느끼는 답답함을 최소화하기 위해 ”
답답한 것을 싫어하는 시니어의 특성을 고려하여 ‘챗봇(손자봇)’과 ‘1:1 채팅 문의’ 서비스를 만들었습니다.
챗봇의 경우 24시간 대기하여 서비스에 대한 궁금증을 언제든지 해결할 수 있고, 1:1 채팅 문의는 강의에 대한 문의 사항을 강사에게 직접 물어볼 수 있어, 프라이빗한 질문도 실시간으로 답변받을 수 있습니다.
사용 기술
챗봇  | YourGPT |
1:1 문의채팅 | - Socket io
- Redis PUB/SUB |
‘챗봇(손자봇)’
저희 서비스의 모든 화면 좌측 하단에서 챗봇을 만나보실 수 있습니다.
이 챗봇은 YourGPT라는 서드파티 서비스를 도입하여 구현되었으며, 사용자의 질문에 즉각적으로 답변함으로써 적은 리소스로 높은 만족도를 제공하고 있습니다.
•
챗봇 Training
예상 질문 또는 답변을 등록해 놓으면 스스로 학습해 사용자에게 적합한 답을 제공해 줍니다.
•
도입 이유
처음에는 구글의 OpenAI API를 사용해 챗봇을 구현하려고 했으나, HTTP 통신 방식으로는 실시간 상호작용에 한계가 있었습니다. 웹소켓 기반 기술이 필요한 상황이었지만 시간상의 여유가 없고, 이미 다른 곳에서 사용되고 있어 대안을 찾고자 했습니다. 그 결과, Your GPT라는 서드파티 서비스를 도입하여 실시간 대화 기능을 구현하게 되었고, 이를 통해 별도의 통신 시스템을 구축할 필요 없이 실시간 상호작용이 가능해졌습니다.
‘1:1 채팅 문의’
채팅창
* 강의 상세보기 페이지
*내강의 상세보기 페이지
유저는 강의를 구매하기 전 ‘강의 상세 보기 페이지’ 그리고 강의 구매 후 ‘내강의 상세 보기 페이지’를 통해 1:1 문의채팅방에 입장할 수 있습니다.
.gif&blockId=18f2dc3e-f514-81c5-bcf4-cfa4029cdc2e)
Socket io를 통해 유저는 해당 강의 담당자와 실시간으로 소통해 궁금증을 해소할 수 있습니다.
이전 대화 | 일회성의 대화가 아닌 점을 감안하여 대화 내용을 DB에 저장하도록 하였습니다.
→ 채팅방 입장 시 api를 통해 DB에서 이전 대화를 불러옵니다.
❗️ 문의 용도이기 때문에 사용이 잦지 않아, 리소스가 크게 들지 않을 것 같다고 판단했습니다.
→ Redis나 다른 기술을 고려하는 대신 직접 DB에 저장하는 방식을 선택하였습니다. |
실시간 대화 | 보내지는 메세지는 DB에 저장한 후, 해당 메세지를 Socket io를 통해 해당 채팅방 참여자에게 실시간으로 전송시켜 주었습니다. |
•
Socket io
◦
고려했던 부분
http 요청과 SSE를 사용하면 동일하게 구현할 수 있는 것이 아닌가?
▪
SSE와 HTTP 요청을 조합하면 실시간 양방향 통신을 구현할 수 있지만, Socket.IO나 WebSocket에 비해 복잡할 수 있으며, Socket.IO는 클라이언트와 서버 간의 실시간 상호작용이 중요한 상황에서 더 자연스럽고 효율적으로 동작하므로 클라이언트의 반응이 빈번하게 필요한 채팅 기능에 Socket.IO가 더 적합하다고 판단했습니다.
채팅 목록
•
USER 문의 채팅 목록
•
CP 계정 문의 채팅 목록
USER와 강의 담당자인 CP 모두 문의 채팅 목록을 통해 자신의 채팅방을 한눈에 볼 수 있습니다.
Redis pub/sub을 사용해 실제로 채팅방에 참여하지 않은 상황(채팅 목록 페이지)에서도 실시간으로 해당 채팅방이 업데이트 되는 것을 확인할 수 있습니다. 새로운 메세지가 올 경우 해당 채팅방이 제일 위로, 읽지않음 표시인 빨간 점과 함께 업데이트됩니다.
채팅 목록 업데이트 과정 | 메세지가 보내짐
→ 실시간 채팅방 참여 유저에게 socket을 통해 메세지를 전달
→ 채팅방 유저(실시간 미참여 유저 포함)를 배열로 불러온 후, 메세지와 유저 id를 담은 payload를 redis pub/sub 채널에 퍼블리시
→ 해당 채널을 구독하고 있는 서버는 구독된 메시지를 받아 해당 유저들의 소켓에 메시지를 전달
→ 각 유저의 클라이언트는 수신한 메시지를 통해 채팅방 목록을 업데이트
→ 채팅 목록에서 해당 채팅방이 맨 위로 이동하며, 새로운 메시지와 읽음 상태가 갱신됨(안 읽음 상태)
|
목록 읽음 처리 과정 | 읽음
사용자가 채팅방을 열거나 실시간으로 온 메세지를 읽음
→ 클라이언트에서 markAsRead 이벤트를 서버로 전송
→ 서버에서 해당 메세지를 읽음 상태로 DB 업데이트
→ 목록에서 빨간불이 사라진 채팅방 확인 |
Redis pub/sub 선택 이유 | - 여러 서버 간의 실시간 데이터 동기화를 보장하기 위해 선택하게 되었습니다.
- 다양한 서비스에서 데이터를 주고받는 여러 서비스 아키텍처를 사용하기에 확장성을 고려하였습니다.
- 알림 기능에서 이미 Redis pub/sub을 구현한 상황이었기에 일관성도 고려했습니다. |