뭐RAG하는거야: RAG에 대한 모든 것을 담은 세미나

안녕하세요, 코멘토 개발 세미나에 진심인 앱 개발자 최수빈입니다. 🐥

코멘토 개발팀은 매달 서로의 성장을 돕기 위해 기술 세미나를 진행하고 있는데요. 이번 세미나에서는 RAG(Retrieval-Augmented Generation) 서비스를 실제 서비스로 만들기위해 필요한 지식과 기술에 대해 공유해보는 시간을 가졌어요.

지난 1월 열린 코멘토 사내 AI 해커톤, '해코톤'에서 처음으로 RAG 기술을 활용한 다양한 서비스들이 나왔어요. 그 중에서도 대상을 거머쥔 서비스는 24만 개의 현직자 답변 데이터를 바탕으로 나에게 딱 맞는 현직자의 답변을 찾아주는 코멘토픽이었어요. 하루라는 짧은 시간 안에 임팩트있는 프로토타입이 나와 다들 신기해했습니다.

하지만 막상 코멘토픽을 실제 제품으로 디벨롭하기 위해선 RAG 기술에 대한 좀 더 깊은 이해가 필요했어요.

💁‍♀️ "RAG가 정확히 뭐야? 해커톤에서 만들어보긴 했지만 제대로 이해한 게 맞나?"

🤷 "실제 서비스로 만들기 위해 우리가 해결해야 하는 문제는 뭐고, 비용은 얼마나 들까?"

따라서 기획자부터 개발자까지 코멘토 팀원들이 모두 같은 수준에서 RAG를 이해해보기 위한 RAG 기술 세미나, “뭐RAG하는거야”를 열게 되었습니다!

RAG를 이해하기 전 LLM부터 이해해보기

RAG를 제대로 이해하려면 먼저 LLM(Large Language Model)이 어떻게 동작하는지 이해해야 합니다. LLM은 쉽게 말해 다음 단어를 자연스럽게 예측하는 모델입니다.

"나는 오늘 아침에 밥을 ______"

여기서 우리는 빈칸에 "먹었다", “차렸다” 등이 떠오르는 것 처럼 언어모델은 이 문장 뒤에 뒤에 올 확률이 가장 높은 단어를 예측해 생성하는거죠.

다음에 올 단어가 무엇인지 계산하기 위해선 텍스트를 계산이 가능한 숫자값으로 변환하는 과정이 필요합니다. 이를 위해 모든 텍스트를 '토큰'이라는 일정 단위로 쪼갠 후, 이 토큰들을 숫자로 바꾸어 계산 가능한 값으로 바꾼 후 이 값들로 다음에 올 단어의 확률을 계산합니다. 결국 언어 모델이라는 것은 단어 시퀀스에 확률을 할당하는 일을 하는 모델을 말하고, 이것을 방대하게 학습한 것이 거대언어모델인 것이죠.

하지만 LLM이 갖고 있는 가장 큰 한계는 방대하게 학습한 그 데이터가, 과거의 데이터라는 점이죠. 즉, 최신 정보나 특정 문서를 반영하지 못해 때로는 엉뚱한 답변을 하기도 합니다. 이 한계를 극복하기 위해 외부의 최신 맥락을 실시간으로 가져오는 방법이 등장했고 그것이 검색 증강 생성, RAG입니다.

세미나에서는 이 기본적인 개념을 팀 전체가 함께 확인해서 RAG 서비스를 만들기 위해 고려해야하는 부분에 대한 이해를 함께할 수 있었어요.

실제 RAG 서비스를 만들 때 해야하는 필수 질문 3가지

1. 임베딩 모델은 어떤걸로 선택하나요?

앞서 문장을 단어로 쪼개서 숫자로 만드는 과정을 거친다고 했는데, 이 단어를 쪼개는 과정을 토큰화라고 합니다. 토큰화엔 다양한 방법들이 있습니다. 띄어쓰기를 기준으로 할 수도 있고 단어의 최소 의미인 형태소를 기반으로 쪼갤 수도 있죠.

영어와 달리 한국어는 띄어쓰기를 하지 않아도 이해하기가 쉬워서 많은 한국어 문장들이 띄어쓰기를 잘 지키지 않은 문장들이 많습니다. 또한 한국어의 구조상 형태소를 기준으로 쪼개는 것도 어렵습니다. 이런 이유들로 토큰화를 담당하는 임베딩 모델은 무엇보다 한국어에 특화된 모델을 선택하는 것이 중요합니다. 실무에서는 현실적으로 비용과 성능 균형이 맞는 한국어 특화 모델을 선택하는게 중요합니다. 가장 보편적으로 쓰이는 임베딩 모델은 다국어 성능이 우수한 bge-m3 모델입니다.

2. 벡터 DB는 뭘 기준으로 골라야하나요?

벡터DB는 텍스트 데이터를 숫자화한 벡터 형태로 저장하는 데이터베이스입니다. 사용자가 질문을 입력하면 이 질문을 임베딩해서 벡터DB에 저장된 수많은 벡터 중 가장 비슷한 벡터를 빠르게 찾아주는 역할을 합니다.

이 과정에서 벡터DB는 벡터 데이터를 빠르게 읽고 비교하는 작업을 수행하는데요. 문제는 이 작업이 수백, 수천 개의 벡터 데이터를 동시에 읽고 처리해야 하는 작업이라 매우 많은 디스크 입출력이 필요하다는 점입니다. 이때 스토리지 성능을 나타내는 지표 중 하나인 IOPS(초당 입출력 횟수) 가 매우 중요합니다.

IOPS가 낮으면, 좋은 임베딩 모델을 사용하더라도 사용자가 느끼기에 서비스가 느려지거나 답답할 수 있습니다. 그래서 실제 서비스를 운영할 때는 단순히 DB의 벡터 저장 및 검색 성능뿐 아니라 스토리지의 IOPS까지도 꼭 확인해야 합니다.

3. MAU를 어느정도 규모로 생각하시나요?

일반적인 서비스를 기획할 때는 보통 이렇게 생각합니다.

"우리 서비스는 누구의 어떤 문제를 해결할 수 있을까?"

"이 서비스가 사용자에게 얼마나 가치를 줄 수 있을까?"

일반적인 웹사이트나 앱에서는 사용자 수가 많을수록 좋습니다. 하지만 RAG 기술이 들어간 서비스는, 사용자가 많아질수록 매번 질문할 때마다 비용이 증가하고 규모에 따라 필요한 스펙도 큰 차이가 납니다. 그래서 처음부터 "하루에 사용자가 몇 번 질문할지", "월간 사용자 수(MAU)는 어느 정도 될지" 정확히 예측하는 게 가장 중요합니다. 실제로 RAG 서비스를 만들 때 비용을 관리하기 위해서는 다음의 4가지 요소를 명확히 이해하고 미리 계산해야 합니다.

특히나 이 중 가장 비용에 큰 영향을 미치는 것이 쿼리 비용입니다. MAU를 고려해서 LLM은 어떤 모델을 선택할지, 그리고 그 나머지 스펙들도 여러 선택지를 두고 예상 비용을 계산하는 것이 중요합니다.

이번 세미나는 RAG에 관한 지식공유 세션 이후, 실제로 코멘토에서 생성형 AI 서비스인 포텐스닷을 구축한 창섭님과 함께 즉문즉답 형태의 Q&A 세션으로 마무리 됐습니다. RAG 서비스 구축 시 기술적으로 어떤 구성 요소가 필수적인지, 현재 포텐스닷은 어떤 기술 스택과 프레임워크로 운영되고 있는지, 그리고 실제 사용량에 따라 구체적으로 얼마만큼의 비용이 발생하고 있는지 등을 현실적인 질문들이 많이 오고갔습니다.

또한, RAG 서비스를 처음 구현할 때 맞닥뜨렸던 기술적 장벽과 어려움에 대해서도 함께 고민해봤는데요. 특히 비개발자도 쉽게 RAG 서비스를 만들어볼 수 있는 방법은 없는지, 비용 효율성을 높이기 위해서는 어떤 부분을 최적화해야 하는지와 같은 현업에서 바로 적용 가능한 팁들도 활발히 공유되었습니다. 이번 Q&A 세션을 통해 세미나 참여자 모두가 더 깊고 실무적인 관점에서 RAG 서비스에 대한 이해도를 높일 수 있었습니다.

그래서, 코멘토픽은 어떻게 만들었나요?

이 RAG 세미나에서 나온 내용들을 바탕으로 코멘토픽을 디벨롭해 실제 제품으로 출시했습니다! 👏👏👏코멘토픽은 코멘토가 가진 무려 24만개 현직자 답변 데이터를 임베딩해 누구보다 빠르게, 내 상황에 꼭 맞는 답변을 찾을 수 있는 서비스입니다.

코멘토픽 사용해보기

다음 글에서는 저희 코멘토픽팀이 실제로 서비스를 출시하기까지의 이야기를 더 구체적이고 기술적인 내용으로 다뤄보려고 합니다.

• 실제로 사용한 임베딩 모델과 왜 그 모델을 선택했는지
• 벡터DB의 정확한 구성과 최적화 방법은 무엇이었는지
• 구체적으로 비용 예측 계산은 어떻게 했는지

RAG 기술이 실제 서비스로 구현될 때 어떤 현실적인 고민과 결정을 거쳤는지, 다음 글에서 더욱 깊고 자세한 이야기로 돌아오겠습니다.

다음 글도 기대해주세요! 👋

이번 세미나의 코멘토 팀원들의 후기

참가자 1 : RAG에 대해 즉문즉답을 해주셔서 좋았습니다.

참가자 2 : RAG이해를 위한 사전 지식을 쉽게 알 수 있어서 좋았습니다. 특히 기초 지식과 더불어 실무자 인터뷰를 바탕으로 한 주요 실무 체크 포인트들이 포함되어 있어서 도움을 많이 받았습니다.