AI
해커톤에서 하루 만에 만든 RAG 서비스를, 실제 서비스로 만들기
2025.05.09
•
15 min read
안녕하세요! 코멘토의 제품을 AI로 더 똑똑하게 만들고 있는 AX 팀입니다.
오늘은 코멘토 커뮤니티에 새롭게 출시한 코멘토픽(Comentopick) 서비스가 어떻게 구현되었는지, 특히 RAG를 활용한 검색 구조와 비용 계산 과정에 대해 자세히 이야기해보려 합니다.
최근 많은 회사들이 사내 데이터와 AI를 결합한 RAG 서비스를 출시하고 있습니다. RAG는 관련 정보를 검색(Retrieval)하여 AI 모델의 답변 생성(Generation)의 맥락을 추가하는 방식으로, 특정 도메인에 특화된 데이터를 활용해 더 정확하고 맥락에 맞는 응답을 제공할 수 있게 해줍니다.
저희 AX 팀도 이러한 RAG 기술을 활용하여 코멘토픽(Comentopick) 서비스를 최근 출시했습니다. 코멘토픽은 사용자가 자신의 고민을 입력하면, 해당 고민과 유사한 질문을 찾아 사용자의 상황에 딱 맞는 현직자의 답변을 제공하는 서비스입니다.
왜 RAG를 선택했을까요?
현재 코멘토 커뮤니티에는 약 24만 개에 달하는, 현직자들이 남긴 신뢰도 높은 답변들이 축적되어 있습니다.
하지만 이렇게 많은 콘텐츠가 있다는 건, 오히려 유저가 본인의 상황에 딱 맞는 답변을 찾기 어렵다는 뜻이기도 합니다. 여러 질문들을 하나하나 열어보며, 본인과 비슷한 사례를 찾고, 그 안에서 필요한 정보를 스스로 추려내야 하는 구조는 꽤 번거롭고 시간이 많이 드는 일이었죠. 게다가 유저가 원하는 정보를 찾지 못할 경우, 결국 새로 질문을 등록하게 됩니다. 이런 흐름이 반복되다 보면, 비슷한 질문과 답변이 여러 번 누적되고 결국 커뮤니티 전체의 정보 구조도 점점 비효율적으로 변하게 됩니다.
이 불편함을 해결하기 위해 코멘토는 RAG(Retrieval-Augmented Generation) 방식을 도입했습니다. 이미 존재하는 수많은 질문들 중에서 사용자 질문과 비슷한 사례를 찾아내고, 그 내용을 바탕으로 사용자의 상황에 맞는 응답을 빠르게 구성해주는 방식입니다. 새로 만들어낸 답이 아니라, 검증된 데이터에서 출발하기 때문에 신뢰할 수 있고, 무엇보다 내 질문에 딱 맞는 답을 더 빠르게 받을 수 있습니다.
코멘토픽은 어떻게 설계됐을까요?
코멘토픽의 검색 과정은 크게 세 단계로 이루어집니다. 하나씩 살펴보며 RAG 서비스를 구축하기위해 필요한 것들을 알아볼게요.
1. Retrieval: 임베딩과 벡터DB로 가장 유사한 질문 찾기
1) Embedding: CLOVA STUDIO V2 API
첫 번째 단계는 사용자가 입력한 질문과 의미적으로 가장 가까운 기존 질문을 찾는 것입니다. 그러기 위해서 사용자가 입력한 값을 숫자로 바꿔주는 임베딩 과정이 필요합니다. 사용자가 검색한 문장을 임베딩 하기 위해 저희팀은 네이버 CLOVA Studio v2 API의 bge-m3 모델을 선택했습니다.
이 임베딩 모델을 선택하는 과정에서 여러 고민이 있었습니다. 임베딩을 직접 처리하려면 서버를 별도로 운영해야 하는데, 임베딩 모델은 최초 현직자들의 24만 개 데이터를 임베딩하는 것 말고는 유저가 검색하는 시점에만 필요합니다. 따라서 상시로 서버를 켜두는 것은 비용 대비 효율이 맞지 않는 상황이었습니다.
초기에는 AWS Lambda를 이용해 필요할 때만 Amazon Bedrock 모델을 호출하는 방안도 고려했지만, AWS에서는 원하는 수준의 임베딩 모델이 부족했습니다. 그러던 중 네이버 클라우드 플랫폼(NCP)에 다국어 환경에서 우수한 성능을 보이는 bge-m3 모델을 API로 제공하고 있다는 것을 알게 되었습니다. 이 API 방식은 서버를 상시 운영하지 않고도 필요할 때만 호출하여 사용할 수 있어 인프라 유지 비용이 들지 않고, 사용량에 따라 비용을 지불하는 구조였습니다. 게다가 AWS Bedrock의 임베딩 모델 대비 토큰당 비용도 훨씬 저렴했기 때문에, 성능과 비용 효율성 모두를 고려하여 네이버 CLOVA API를 선택하게 되었습니다.
class ClovaStudioEmbeddingFunction(EmbeddingFunction):
def __init__(self, url: str, api_key: str, request_id: str):
self._url = url
self._api_key = api_key
self._request_id = request_id
self._normalize_embeddings = normalize_embeddings
def __call__(self, input: Documents) -> Embeddings:
response = httpx.post(
url=self._url,
headers={
"Content-Type": "application/json; charset=utf-8",
"Authorization": f"Bearer {self._api_key}",
"X-NCP-CLOVASTUDIO-REQUEST-ID": self._request_id
},
json={"text": input[0]}
).json()
return response['result']['embedding']
2) VECTOR DB: Chroma DB
이렇게 생성된 벡터는 Chroma DB라는 벡터 데이터베이스에 저장된 과거 질문들의 벡터와 비교되어, 의미적으로 가장 유사한 질문을 유사도 계산을 통해 빠르게 찾게 됩니다.
초기에는 AWS OpenSearch를 활용해 임베딩 기반 검색을 구현하려 했습니다. 그러나 OpenSearch는 사용 비용이 상당히 높았고, 임베딩 결과 품질도 만족스럽지 못했습니다. 게다가 OpenSearch 자체의 구조적 난이도도 만만치 않아서, 개발 초기부터 크고 작은 이슈들이 계속 발생했어요.
그래서 임베딩 DB 중 구축이 비교적 간단한 솔루션을 찾아보기 시작했습니다. 그 과정에서 Chroma DB를 발견했는데, 비교적 설치와 사용이 간단하고, 빠른 프로토타이핑에 적합하다는 평이 많았습니다. 직접 구축해보니 운영 수준으로 확장하는 데에도 충분히 사용할 수 있을 것 같다는 확신이 들었습니다.
특히 Chroma 공식 문서에 따르면, OpenSearch 대비 훨씬 가벼운 스펙의 인스턴스에서도 충분히 운영 가능해 비용 측면에서도 큰 장점이 있었습니다. Chroma의 유연성 덕분에 인스턴스 스펙도 서비스 트래픽에 맞게 적절히 조정할 수 있어, 비용과 성능을 모두 만족시키는 방향으로 안정적인 구조를 완성할 수 있었습니다.
2. 프롬프트 엔지니어링: 생성된 답변의 신뢰성 확보하기
처음부터 완벽한 프롬프트 구조를 만들 수는 없었는데요. 반복적인 실험과 튜닝을 통해 프로덕션에서 사용할만한 퀄리티로 프롬프트를 만들어낼 수 있었어요.
LLM ops를 위한 다양한 툴들이 있지만, 비용없이 빠르게 적용해보기 위해 내부적으로 간단한 LLM 운영용 어드민 툴을 구축했습니다. 이 어드민에서는 다양한 프롬프트 포맷을 실험해보고, 모델의 응답 품질에 영향을 주는 온도(temperature), 확률 기반 생성 제어값(p-value) 등을 자유롭게 조정해볼 수 있도록 했습니다.
예를 들어,
- 동일한 문맥에서 질문 순서를 바꾸거나, 답변 예시를 다른 형식으로 배치해보기도 했고,
temperature값을 높여 창의성을 유도하거나, 반대로p값을 낮춰 정답에 수렴하도록 조절하기도 했습니다.
이 과정을 통해 모델이 응답에서 말도 안 되는 추론을 하거나 너무 애매하게 대답하는 경우를 줄여나갔고, 최종적으로는 가장 유용하고 명료한 답변을 안정적으로 생성할 수 있는 조합을 찾아 프롬프트를 고도화할 수 있었습니다.
3. Generation: Amazon Nova Micro LLM으로 답변 최종 생성하기
세 번째 단계에서는 Vector DB에서 가져온 유사도 높은 현직자의 답변과 프롬프트를 바탕으로, 유저에게 최종 답변을 생성합니다. 이때 활용된 LLM은 Amazon의 Nova Micro 모델입니다. 비용이 저렴한 경량 모델로, 특히 짧고 명료한 답변 생성에 강점이 있습니다. 코멘토 픽에서 사용될 LLM은 단지 이 정보를 사용자의 질문 맥락에 맞게 정리하고 전달하는 역할만 수행하면 됩니다. 따라서 GPT-4나 Claude 같은 고성능 모델보다는 비용 효율적이면서 기본적인 텍스트 재구성 능력이 있는 Nova 가 더 적합했습니다.
실제 응답을 생성하는 코드 구조는 아래와 같이 구성되어 있습니다:
private function bedrockGenerate(array $options)
{
$bedrockRuntime = new BedrockRuntimeClient($this->client);
$retrieve = '';
foreach ($options['retrieve'] as $index => $value) {
$retrieve .= '출처 ' . ($index + 1) . ":\\n";
$retrieve .= "- 제목:{$value['title']}\\n";
$retrieve .= "- 내용:{$value['content']}\\n";
$retrieve .= "- 답변:{$value['answer']}\\n";
}
return $bedrockRuntime->converseStream([
'modelId' => $options['model'],
'inferenceConfig' => [
'maxTokens' => 2048,
'temperature' => $options['temperature'],
'topP' => $options['topP'],
],
'messages' => [
[
'role' => 'user',
'content' => [
[
'text' => str_replace(
['{query}', '{context}'],
[$options['question'], $retrieve],
$options['prompt']
),
],
],
],
],
'@http' => [
'stream' => true,
],
]);
}
이렇게 만들어진 답변은 단순히 '그럴듯한 AI 응답'을 넘어서, 실제로 사용자의 질문에 신뢰할 수 있는 정보가 담긴 답변으로 만들어집니다. 코멘토 픽은 기존 현직자의 답변을 기다리는 것 대비 평균적으로 10배 더 빠르게 원하는 답변에 도달할 수 있었고, 정확도 또한 1.6배 향상되어 1회 검색만으로 원하는 답변을 찾는 비율이 약 43%에서 70%로 상승했습니다.
RAG 서비스 구축 비용은 어떻게 예측했나요?
이러한 코멘토픽을 실제 상용화된 서비스로 구현하기 위해 가장 중요했던 건 바로 비용 계산이었습니다. RAG 시스템은 지속적인 서비스 운영을 위해 정확한 비용 예측이 필수적이기 때문입니다. 이를 명확히 예측하기 위해 저희 팀은 서비스 구축 초기에 비용 계산기를 직접 만들어 시뮬레이션했습니다.
토큰 계산기로 실제 운영 비용 예측하기
RAG 시스템 구축에서 가장 현실적인 문제는 "이 서비스를 실제로 운영하면 얼마나 비용이 들까?"라는 질문이었습니다. 이를 해결하기 위해 저희는 엑셀 기반의 상세한 토큰 계산기를 만들었습니다.
이 계산기는 RAG 시스템의 모든 구성 요소를 포괄적으로 다루도록 설계했습니다. 실시간 원-달러 환율을 반영하고, 다음과 같은 항목들을 세부적으로 분석했습니다:
임베딩 모델 비용 분석
- 사용 방식별(API, 로컬 호스팅, 하이브리드) 비용 비교
- 각 사용 환경(네이버 CLOVA, OpenAI 등)별 비용 구조
- 필요한 인스턴스 타입과 그에 따른 vCPU, 메모리 요구사항
- 일일 및 월간 운영 비용 계산
벡터 DB 비용 분석
- 다양한 벡터 DB 옵션(Chroma DB, Pinecone 등) 비교
- 각 DB별 필요 인스턴스 타입과 일일/월간 사용 비용
- 데이터 양에 따른 스케일링 비용 예측
LLM 모델 비용 분석
- 입력/출력 토큰당 비용 계산
- 쿼리당(질문당) 평균 비용 산정
- 일일 최대 사용량 기준 예상 비용
트래픽 기반 시뮬레이션
- 하루 최대 이용자 수와 사용 빈도에 따른 API 호출 수 예측
- 월간 최대 사용량 기준 비용 계산
- 다양한 트래픽 시나리오에 따른 비용 변동 예측
이 계산기에서 다양한 구성 옵션을 비교하며 최적의 비용 효율성을 찾을 수 있었습니다. 예를 들어, 임베딩 모델을 API 방식으로 사용할 경우와 로컬 호스팅할 경우의 비용 차이, 다양한 벡터 DB 옵션 간의 비용 효율성 등을 한눈에 비교할 수 있었죠.
특히 '월 합계' 항목을 통해 임베딩 모델, 벡터 DB, LLM 모델의 모든 비용을 합산하여 서비스 운영의 총 비용을 계산해서 지속 가능한 서비스 구조를 설계했고 예산 범위 내에서 최적의 성능을 낼 수 있는 구성을 찾아낼 수 있었습니다.
이 계산을 통해 결과적으로 네이버 CLOVA Studio API를 임베딩에 활용하고, Chroma DB를 벡터 저장소로, Amazon Nova Micro를 LLM 모델로 선택하는 조합이 우리의 사용 사례와 예산에 가장 적합하다는 결론을 내릴 수 있었습니다.
코멘토픽을 구축하며 알게된 것들
지금까지 코멘토픽이 어떻게 탄생하고 구축되었는지 기술적인 여정을 공유했습니다. RAG 기술 도입에서부터 벡터DB와 LLM의 조합, 그리고 세부적인 비용 계산까지, 실제 서비스를 출시하는 과정은 여러 고민과 결정들이 얽혀 있었습니다.
특히 AI를 개인적으로 실험하는 수준이 아니라 서비스로 제공하려고 할 때, 비용이 정말 빠르게 불어날 수 있다는 인사이트를 얻을 수 있었는데요. 초기에는 단순히 '이 기능을 넣으면 되겠지' 생각했던 부분도, 막상 직접 구현하고 운영 환경을 고려하다 보면 서버 사양, 호출 단가, 스케일링 문제 등 예상보다 많은 비용 요소가 숨어 있었습니다. 따라서 가능성 있는 선택지를 넓게 조사하고, 비용과 품질을 꼼꼼히 비교한 후에 결정하는 과정이 필수적이라는 점을 깨달았습니다.
또한, 생성형 AI를 활용한 서비스를 만들 때는 외부 API, 새로운 라이브러리, 프레임워크를 적극적으로 도입하게 되는데, 이 과정에서 시스템 구조가 처음 생각했던 것보다 훨씬 빠르게 복잡해질 수 있다는 점도 크게 느꼈습니다. MVP를 만들 때는 "이것도 필요하고, 저것도 있으면 좋겠다"는 식으로 범위를 넓히기보다는, 불필요한 요소를 최대한 과감하게 쳐내면서 빠르게 작동하는 최소 구조를 구축하는 게 훨씬 중요했습니다. 그렇지 않으면 작은 기능 추가나 구조 변경이 반복되면서 개발 기간이 예상보다 길어지고, 서비스 출시가 늦어질 수 있습니다.
앞으로도 더 많은 유저가 쉽고 빠르게 원하는 답변을 얻을 수 있도록 코멘토픽을 계속 발전시켜 나갈 계획입니다. 곧 다시 만나요! 👋