[Lymo 개발일지 #2] Genkit + RTDB로 해석 실시간 스트리밍하기

1️⃣ Lymo 개발일지 #1: https://parkcool.tistory.com/8

2️⃣ Lymo 개발일지 #2: 현재 글

3️⃣ Lymo 개발일지 #3: https://parkcool.tistory.com/14

4️⃣ Lymo 개발일지 #4: https://parkcool.tistory.com/17

안녕하세요!

 

지난 첫 번째 개발 일지에서는 Lymo의 기획 배경과 기술 스택을 결정하는 과정을 공유해 드렸습니다. "음악 앱인데 음악을 재생하지 않는" 기묘한 기획 배경을 설명드렸죠. 실시간 AI 가사 해석 기능을 구현하기 위한 기술 스택으로 Genkit을 선택했었죠.

 

오늘은 그 기획을 현실로 만들기 위해 개발하며 겪었던, 삽질기를 공유하려 합니다.

 

🚀 챗지피티처럼 쭈르륵 나오게

Lymo의 핵심 경험은 속도입니다. 사용자가 음악을 듣다가 "이 가사 뭐지?" 하고 앱을 켰는데, 화면에는 "로딩 중..."만 10초동안 떠 있으면 가차없이 앱을 꺼버리겠죠? 그래서 목표는 명확했습니다.

 

"챗지피티처럼, AI가 글자를 생성하는 족족 화면에 실시간으로 뿌려주자"

 

이걸 구현하기 위해 가장 먼저 떠올린 기술은 SSE (Server-Sent Events)였습니다. HTTP 요청을 끊지 않고 유지하면서 서버가 클라이언트로 데이터를 계속 흘려보내는 방식입니다. 챗지피티를 비롯한 대부분의 채팅형 AI 서비스가 이 방식을 쓴다고 합니다. 그래서 저도 별 생각 없이 SSE를 이용하여 개발을 시작하였습니다. 그랬으면 안 됐는데...

 

🪏 삽질 1: React Native엔 SSE가 없다

시작부터 난관이었습니다. 웹 브라우저에는 EventSource라는 API가 내장되어 있어서 SSE를 쉽게 쓸 수 있지만, 제가 개발 중인 React Native 환경에는 그런 게 없었습니다. react-native-sse 같은 라이브러리를 써볼까 했지만, 커스텀 헤더 설정 등의 문제때문에 결국 fetch 함수를 직접 뜯어고치기로 했습니다.

• 들어오는 바이트 스트림을 직접 디코딩
• \n\n 같은 구분자로 데이터를 쪼개서 이벤트 파싱

이 과정에서 저만의 프로토콜도 만들었습니다. update_lyrics_translation, update_overview 같은 이벤트 타입을 정의하고, 데이터를 받을 때마다 상태를 업데이트하는 로직을 짰죠. 며칠 동안 머리를 싸매면서 개발한 끝에, 드디어 글자가 하나씩 타닥타닥 찍히는 걸 보았을 때의 쾌감!!!

 

하지만 그 기쁨은 딱 하루 갔습니다.

 

🪏 삽질 2: 모바일 네트워크는 가혹하다

구현해놓고 보니, 치명적인 허점이 생각나기 시작했습니다.

1. 지하철 와이파이가 끊길 때: 사람이 많이 탄 지하철에서 와이파이에 연결하면 조금 사용하다가 끊기는 경우가 많죠? 하나의 와이파이를 많은 사람들이 연결하면 그런 경우가 많은데요. SSE에 연결된 상태에서 와이파이 연결이 끊어져버리면 SSE 연결도 바로 끊겨버립니다.
2. 재연결의 악몽: SSE는 연결이 끊기면 처음부터 다시 요청해야 합니다. 하지만 제가 쓰는 백엔드는 서버리스 환경의 Cloud Functions였습니다.
3. 기억상실증 걸린 서버: Cloud Functions는 상태를 저장하지 않습니다. 사용자의 연결이 잠깐 끊겼다 다시 연결되면, 아까 그 인스턴스가 아니라 새로운 독립적인 인스턴스에 다시 연결됩니다. "저 아까 절반까지 받았는데요?"라고 외쳐봤자, 새 인스턴스의 함수는 "누구세요? 처음부터 다시 보내드리겟슴."라고 답할 뿐이었죠.

이걸 해결하려면 Last-Event-ID를 도입하고, 서버 어딘가에 진행 상황을 저장하고... 배보다 배꼽이 더 커지는 상황이 왔습니다. "텍스트 쪼가리 보여주는데 이렇게까지 해야 해?" 현타가 오더라고요..

 

💡 해답은 가까이 있었다

일주일 동안 짠 SSE 코드를 붙들고 끙끙대다가, 문득 파이어베이스 콘솔을 멍하니 보는데 Realtime Database (이하 RTDB)가 눈에 들어왔습니다. RTDB를 사용해본 적 없던 저는 이게 뭔지 찾아봤고, 말 그대로 데이터가 변하면 실시간으로 동기화되는 데이터베이스였습니다.

 

갑자기 생각이 번뜩 떠올랐습니다. 생각을 완전히 뒤집어봤습니다. 서버가 클라이언트에게 쏘는 것이 아니라, 서버는 DB에 쓰고 클라이언트는 그걸 쳐다보는 방식으로요.

1. 클라이언트: "이 노래 해석해줘!" 하고 RTDB에 요청 티켓을 씁니다.
2. Cloud Functions: 새 요청을 감지하는 트리거가 발동됩니다.
3. Genkit (AI): 해석을 생성하면서, 한 글자 나올 때마다 RTDB의 요청 티켓에 내용을 덧붙입니다.
4. 클라이언트: 자기가 쓴 RTDB 요청 티켓을 쳐다보고 있다가, 내용이 변하면 화면에 그대로 보여줍니다.

이 구조로 바꾸는 데는 하루도 안 걸렸습니다. 그리고 결과는 놀라웠습니다.

• 지하철에서도 OK: 지하철에서 와이파이가 끊겨도 상관없습니다. 인터넷이 다시 연결되는 순간, Firebase SDK가 알아서 최신 데이터를 DB에서 긁어와 화면을 채워줍니다.
• 비용 절감: SSE를 유지하려면 Cloud Functions 인스턴스가 계속 살아있어야 해서 시간당 비용이 나가는데, RTDB 방식은 함수가 빨리빨리 처리하고 꺼져도 됩니다. RTDB 읽기/쓰기 비용이 훨씬 저렴했죠.
• 코드 다이어트: 커스텀 fetch 로직, 청크 파싱 로직, 재연결 로직... 그 복잡했던 수백, 수천 줄의 코드를 없애버릴 수 있었습니다.

 

‼️ 배운 점

물론 제가 일주일 동안 공들여 짠 SSE 코드를 제 손으로 지울 때는 속이 좀 쓰렸습니다... 하지만 이를 통해 배운 점이 몇 가지 있었습니다.

 

• HTTP와 스트리밍의 본질: 라이브러리 없이 직접 바이트 단위로 데이터를 쪼개고 받아보면서, SSE 통신이 저수준에서 어떻게 이루어지는지 알게 되었습니다.
• 모바일 환경의 특수성: 모바일 서비스를 위한 백엔드 개발의 특수성을 알게 되었습니다. 불안정한 네트워크를 전제로 하지 않는 백엔드는 모바일에서 무용지물이라는 것을요.
• BaaS의 위력: Firebase 같은 BaaS가 왜 존재하는지, BaaS가 해결해주는 귀찮은 문제들이 얼마나 거대한지 체감했습니다.

결국 Lymo는 RTDB와 Genkit의 조합 덕분에, 아주 매끄럽고 끊김 없는 실시간 AI 해석 경험을 제공할 수 있게 되었습니다.

 

➡️ 정리 및 다음 단계

Genkit과 RTDB의 조합은 정말 강력했습니다. 비록 처음에 SSE로 구현하느라 일주일을 날렸지만, 덕분에 많은 걸 배웠다고... 정신승리 해봅니다.. ㅎㅎ

 

다음 편에서는, 이렇게 힘들게 연결한 AI가 헛소리할 때마다 제가 어떻게 프롬프트 엔지니어링을 통해 AI를 참교육했는지, 프론트엔드 - 백엔드 간의 타입 안정성을 보장해준 Zod 이야기를 해보겠습니다.

읽어주셔서 감사합니다! 😄