RAG 기술 블로그 최신 글

크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까?

네이버 사내 기술 교류 행사인 NAVER Engineering Day 10th 에서 발표되었던 세션을 공개합니다. ​ 크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까? NAVER D2 | 크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까? naver.me ​ 발표 내용 여러 엔티티를 한 공간에 담은 통합 임베딩과 범용 리트리벌이 크림 추천 곳곳에 쓰이는 방식, 운영하며 드러난 한계를 v2에서 해결한 과정, 그리고 확장 방향을 공유합니다. ​ 발표 대상 추천 시스템의 후보 생성(Retrieval) 단계에 관심 있으신 분들 여러 서비스·지면에서 함께 쓰는 공용 임베딩을 설계하고 운영하고 싶으신 ML 엔지니어 조건(필터)이 걸린 벡터 검색의 지연과 메모리를 줄이고 싶으신 분들 구좌·서비스마다 늘어나는 추천 모델을 줄이고 싶은 추천·검색 조직의 엔지니어와 기획자 ​ 키워드 Recommendation System / Candidate Generation (Retrieval) Universal Embedding (Bi-encoder · Contrastive Learning) Matryoshka Representation Learning (MRL) Filtered Vector Retrieval (Roaring Bitmap · Brute-force vs ANN) Embedding Serving Optimization ​ 목차 PART 1. 왜 통합 임베딩인가 2025년의 크림: 추천 구좌마다 모델이 따로 있었다 목표: 여러 목적에 쓸 수 있는 범용 임베딩 하나 구좌마다 ‘누구에게 · 무엇을 · 어떻게’가 다르다 통합 임베딩은 후보 생성에 직접, 랭킹에도 입력으로 설계 원칙: 모든 질문이 ‘벡터 + 조건’이 된다 PART 2. v1 모델 — 하나의 공간을 만들다 하나의 인코더가 검색어와 상품을 모두 읽는다 학습: InfoNCE를 받쳐 주는 일곱 가지 장치 학습은 상품 하나, 나머지는 모두 집계로 그림으로 보면: 모두가 상품 공간 위의 점 PART 3. v1 리트리벌 — 하나의 API로 꺼내 쓰다 질문 하나 = 요청 하나 조건별 상품 목록을 미리 만들어 두고 꺼내 쓰기 구좌 전용 모델 없이 붙은 첫 구좌들과 타겟 집단 추천 PART 4. 써 보니 드러난 v1의 한계 모델: 가끔 붕괴하고, 768차원은 무거웠다 리트리벌: 큰 조건을 감당하지 못했다 리트리벌: 조건을 자유롭게 조합할 수 없었다 v1의 한계, 한눈에 PART 5. v2 — 한계를 하나씩 걷어내다 모델 1차: 학습을 안정시키다 모델 2차: 하나의 벡터, 여러 해상도 (MRL) 좌표계: 회전으로 맞추려 했지만, 통하지 않았다 필터: Roaring Bitmap으로 조건을 실행할 때 조합 왜 근사 검색(ANN)이 아니라 후보 전부를 계산하나 점수 계산: 계산량은 그대로, 메모리 낭비만 없앴다 결과: 응답 지연은 약 4배 빠르게, 메모리는 1/6로 API: 조건 칸 하나 → 조건 리스트 v1의 한계 → v2의 처방 PART 6. 지금의 쓰임과 다음 확장 지금: 하나의 API가 채우는 지면과 구좌 비슷한 브랜드: 브랜드 벡터만으로는 부족했다 리트리벌 밖에서도 같은 벡터 다음으로 — 멀티벡터, 지면 확장, 마케팅 타겟팅 ​ ◎ NAVER Engineering Day란? ​ NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기) 올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다. ​ [동영상 제공 채널 안내] 네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다. 앞으로

Argo Workflows와 SageMaker로 추천 ML 파이프라인 구축기

추천 모델과 임베딩, 검색 인덱스를 한 세대로 묶어 매일 안전하게 교체하는 파이프라인 구축기

버그 티켓, AI에게 맡겨봤습니다 — QUBA 개발기

버그 티켓, AI에게 맡겨봤습니다 — QUBA 개발기 QA가 등록한 Jira 버그 티켓을 AI Agent가 먼저 조사하고, 원인과 수정안까지 제안한다면 어떨까요? 사이드 프로젝트로 시작한 버그 처리 자동화 Agent ‘QUBA’의 설계 과정과, 분석 품질을 좌우한 데이터 임베딩·RAG…

사내 지식으로 Agentic RAG 만들기 (3/3) : 관측 가능한 RAG, 운영되는 도구로

글. 박이슬(스노우) / 공통플랫폼개발팀 안녕하세요, 여기어때컴퍼니 공통플랫폼개발팀 스노우입니다. 1편에서는 Confluence와 Jira에 흩어진 문서를 모아 검색 가능한 형태로 바꿨고, 2편에서는 그 위에 LightRAG와 Navigator를 얹었습니다. 여기까지 오면 질문을 던졌을 때 답이 돌아옵니다. 그런데 만들고 나서 가장 오래 붙잡고 있었던 건 검색이 아니었습니다. 만든 것이 제대로 동작하는지 확인하는 일이었습니다. 이번 편은 그 이야기입니다. 질의를 던졌을 때 무엇이 오갔는지 보이게 만들고, 그게 맞는 답인지 채점하고, 그렇게 검증한 검색을 에이전트가 쓸 수 있게 내보내기까지. 그리고 마지막에는 그렇게 만든 도구가 지금 어디에서 어떻게 쓰이고 있는지까지의 이야기입니다. LLM Observability와 LLM 평가하기 LLM과 RAG는 잘 돌아가고 있는지 눈으로 확인하기 어려운 시스템입니다. LLM의 입출력은 자연어이다 보니, 지금 모델이 좋은 답변을 했는지 못했는지를 판단하기가 굉장히 어렵습니다. 답이 그럴듯하면 맞아 보입니다. 근거 문서들을 함께 돌려주니 더 그래 보입니다. 실제로는 엉뚱한 문서를 집어왔는데도 모델이 매끄럽게 문장을 만들어내면, 읽는 사람은 그걸 알아차리기가 어렵습니다. 비용도 마찬가지입니다. 문서 하나를 처리하는 데 LLM 호출이 몇 번이나 붙는지, 그게 한 달에 얼마가 되는지는 청구서가 오기 전까지 알 수 없습니다. 이런 문제점을 해결해주는 도구로써 최근에 LLM에 특화된 APM(Application Performance Monitoring)들이 나왔습니다. 그 중 저희는 Langfuse를 선택했습니다. LLM 애플리케이션에 특화된 오픈소스 관측 플랫폼으로, 요청 하나가 어떤 경로를 거쳤는지를 trace 단위로 기록하고 보여주는 모니터링 툴입니다. Langfuse trace 추적 예시 일반적인 APM과 다른 점은, 프롬프트와 응답 전문, 사용 토큰, 모델별 단가에 따른 비용이 호출마다 남는다는 점입니다. 검색 → 프롬프트 조립 → 생성으로 이어지는 여러 단계를 하나의 trace로 묶어 보여주기 때문에, 어느 단계에서 시간이 걸렸고 어디서 토큰이 나갔는지를 한 화면에서 확인할 수 있습니다. RAG 평가 파이프라인 구축 Langfuse를 붙이면서 어디에 시간과 비용이 나가는지 보이게 됐습니다. 다만 검색 결과가 좋은지 나쁜지는 여전히 알 수 없었습니다. trace에 남는 건 무엇이 오갔는지, 그게 맞는 답인지가 아니기 때문입니다. Langfuse에는 Experiment라는 이름으로 해당 기능을 지원하고 있습니다. 데이터셋을 만들고, 평가체계를 구축하고, 실험을 돌려 결과를 남기는 것까지 하나의 플랫폼 안에서 가능합니다. 이번 프로젝트에서는 이 기능을 최대한 활용하였습니다. 무엇을 물어볼 것인가 RAG 시스템을 평가하기 위해선, 먼저 평가대상인 질문-답변 쌍을 제작해야했습니다. 검색이 실패하는 방식은 하나가 아니기 때문에 먼저 사내 지식을 기반으로 답변할 수 있는 질문 유형을 일곱 가지로 나누고, 유형별로 질문과 정답 쌍을 작성했습니다. 유형을 나눠서 데이터셋을 생성한다면, 평가 이후 어디가 약한지가 점수와 함께 드러날 것이라고 생각했습니다. 검색이 제대로 됐는가 질문셋이 준비됐으니 이제 확인할 차례입니다. RAG에서 답이 틀리는 경로는 크게 둘인데, 애초에 엉뚱한 문서를 가져왔거나 문서는 맞는데 모델이 잘못 읽은 경우입니다 앞쪽은 정보 검색 분야에서 오래 쓰인 지표들로 확인할 수 있습니다. Recall@5 : 정답 문서가 상위 5개 안에 들어왔는가 Hit Rate : 정답 문서를 한 번이라도 회수했는가 MRR : 정답 문서가 몇 번째로 올라왔는가 질문마다 정답 문서를 지정해뒀기 때문에 리트리버가 돌려준 목록과 대조하면 자동으로 계산됩니다. Langfuse Python SDK로 데이터셋을 불러와 실험을 돌리고, 이 지표들을 계산하는 evaluator를 붙였습니다. LLM을 거치지 않으니 빠르고, 같은 입력에는 항상 같은 값이 나옵니다. 그래서 답은 좋아졌는가 (LLM-as-a-judg

사내 지식으로 Agentic RAG 만들기 (2/3) : 검색을 얹기, LightRAG와 Navigator

글. 김수비(소피) / 공통플랫폼개발팀 안녕하세요, 여기어때컴퍼니 공통플랫폼개발팀 소피입니다. 1편에서는 검색을 만들기 전에 바닥을 다졌습니다. Confluence와 Jira에 흩어진 문서를 증분으로 모으고, 검색에 쓸 수 없는 JSON을 Markdown으로 바꾸고, 이미지에는 대체 텍스트를 붙였습니다. 이미지가 보이지 않던 문제는 거기서 답이 됐습니다. 남은 문제는 하나였습니다. 맞는 키워드를 모르면 계속 헤매는 문제. 에이전트가 단어를 바꿔가며 검색과 열람을 6~7번씩 왕복하다 겨우 답을 내는, 느리고 비싼 검색이었습니다. 이건 문서를 잘 쌓아두는 것만으로는 풀리지 않습니다. 그 위에 얹을 검색이 따로 필요합니다. 이번 편이 그 검색 이야기입니다. 의미로 문서를 찾아내는 LightRAG와 문서가 놓인 자리를 따라 걷는 Navigator. 두 리트리버를 차례로 풀어보겠습니다. 프로젝트의 추상화된 전체 아키텍처 벡터 검색만으로는 부족했다 처음 떠올린 건 전통적인 RAG 구조였습니다. 문서를 잘게 잘라 임베딩해두고, 질문과 가까운 청크를 꺼내 모델에게 넘기는 방식입니다. 그런데 사내 질문에 대입해 보니 이 구조로는 부족했습니다. “공통 게이트웨이에 필터를 하나 추가하려면?”의 답은 가이드 문서, 요청 프로세스 문서, 과거 Jira 이슈에 등에 조금씩 나뉘어 있는데, 벡터 검색은 비슷한 청크를 꺼내줄 뿐 그 조각들이 서로 어떤 관계인지는 알려주지 않습니다. 조각을 잇는 일이 매번 모델의 추측으로 남고, 추측에 기댄 답은 틀리기 쉽습니다. 필요한 건 “비슷한 문서”가 아니라 “이 개념이 어디에서 어떻게 이어지는지”였습니다. LightRAG란 무엇인가 이 문제의식에 맞는 접근이 GraphRAG였습니다. 문서에서 개념(Entity)과 관계(Relation)을 미리 뽑아 지식 그래프로 만들어 두고, 검색할 때 그래프를 따라 관련 개념까지 함께 끌어오는 방식입니다. 문서를 넣는 시점에 “공통 게이트웨이”라는 개념과 “라우팅 요청 프로세스”라는 개념이 연결돼 있다는 것을 그래프로 만들어 두면, 검색 시점에는 그 연결을 따라가기만 하면 됩니다. 조각을 잇는 일을 매 질문마다 모델의 추측에 맡기는 대신, 인덱싱할 때 한번만 해두는 것입니다. GraphRAG 계열로 저희가 고른 것이 LightRAG입니다. LightRAG는 GraphRAG 방식을 경량화한 오픈소스 프레임워크로, 문서에서 Entity/Relation을 추출해 지식 그래프를 구성한 뒤 그래프 탐색과 벡터 검색을 결합합니다. LightRAG 지식 그래프 구성 예시 LightRAG의 구성은 다음과 같습니다. LightRAG 파이프라인 동작을 요약하면 문서를 넣으면 LightRAG가 토큰 단위로 청킹하고, 각 청크를 LLM에 넘겨 Entity와 Relation을 추출해 그래프를 쌓습니다. 그리고 Entity, Relation, 청크 원문 세 갈래를 각각 임베딩해 둡니다. 질문이 들어오면 LLM이 질문에서 키워드를 추출하고, 그 키워드로 세 벡터 인덱스와 그래프를 함께 탐색해 결과를 합칩니다. LightRAG에 문서 넣고 검색하기 LightRAG에 문서 넣기 파이프라인의 마지막 단계는 정제된 문서를 LightRAG에 업로드하는 것입니다. 여기서는 LightRAG의 동작 방식인 갱신 방식과 비동기 인덱싱 두 가지를 고려했습니다. LightRAG의 업로드 API에는 upsert가 없어서, 같은 ID로 다시 올리면 갱신되는 게 아니라 “duplicated”로 조용히 무시됩니다. 하루 세 번 문서를 증분으로 밀어 넣는 저희 파이프라인에서는 수정본이 그대로 버려지는 셈이라, 갱신을 삭제 → 삭제 완료 대기 → 재업로드 3단계로 풀었습니다. 삭제 역시 비동기라 요청 접수가 곧 완료는 아니기 때문에, 문서 목록을 재조회해 실제로 사라진 것을 확인한 뒤 재업로드합니다. 인덱싱도 비동기입니다. 업로드가 성공해도 뒤에서 도는 Entity 추출이 LLM 호출 한도(429)에 걸리면 문서는 failed로 남아, 파이프라인은 성공했는데 검색에서는 빠진 문서가 생깁니다. 그래서 인덱싱이 끝날 시점에 실

[플랫폼설계] DevOps에서 Platform Engineering으로: kt cloud의 여정

kt cloud Platform엔지니어링팀 이지은 님 요약 SUMMARY 이 글에서는 DevOps에서 Platform Engineering으로 전환하며 개발자의 인지 부담을 줄이기 위해 Platform Portal과 골든 패스를 설계하는 과정을 다룹니다. 셀프서비스·GitOps·정책 자동화와 RAG 기반 AI 에이전트로 개발자 경험을 개선하는 방향을 정리합니다. #PlatformEngineering #PlatformPortal #GoldenPath #GitOps #DeveloperExperience "이 YAML은 누가 작성하나요?" kt cloud에서 NEXT 프로젝트를 진행하던 시절, 회의에서 심심치 않게 오가던 질문입니다. 배포 파이프라인을 작성하고 수정하는 건 개발자 몫이었고, Kubernetes 매니페스트를 손보는 것도, CI 스크립트가 실패하면 원인을 추적하는 것도 결국 개발자에게 돌아왔습니다. 당시 조직 이름은 CICD 였습니다. 이름 그대로, 지속적 통합과 배포 자동화가 핵심 미션이었습니다. DevOps 철학이 퍼지던 시대의 흐름을 잘 반영한 이름이기도 했습니다. "만든 사람이 운영도 한다(You build it, you run it)"는 원칙 아래, 개발자들은 기능 개발과 배포 운영을 동시에 책임졌습니다. 그런데 클라우드 네이티브 생태계가 생각보다 훨씬 빠르게, 훨씬 복잡하게 성장하면서 문제가 발생했습니다. 인지 부담이라는 현실 개발자 한 명이 하루 동안 마주하는 것들을 나열해보면 이렇습니다. 기능 개발을 위한 비즈니스 로직 구현 ArgoCD SyncPolicy 조정, App yaml 작성 Kyverno 정책 위반으로 인한 배포 실패 원인 추적 Harbor 이미지 레지스트리 Push, Pull, Tagging 설정 Image CVE 취약점 조치 GitHub Actions 워크플로우 디버깅 비즈니스 가치를 만들어내는 행위는 첫 번째뿐입니다. 나머지는 인프라 복잡성이 만들어낸 부수적 업무입니다. 이것을 인지 부담(Cognitive Tax)이라 부릅니다. 개발자가 핵심 업무에 쓸 수 있는 두뇌 자원을 인프라 운영이 잠식하는 현상입니다. DevOps는 본래 사일로를 제거하자는 철학이었습니다. 하지만 많은 조직에서 이 철학은 "개발자가 운영까지 다 하면 된다"는 방식으로 실천됐고, 결과적으로 모든 팀원이 전문적인 인프라 지식을 갖춰야 한다는 암묵적인 요구로 이어졌습니다. 실제로 NEXT 프로젝트 시절을 돌이켜보면, 각 서비스 팀이 비슷한 배포 파이프라인을 각자 조금씩 다른 방식으로 작성하고 있었습니다. GitHub Actions 워크플로우, Helm values 파일 구조도 제각각이었습니다. 동일한 문제를 열 팀이 열 번 푸는 구조였고, 각자 조금씩 다른 버그를 품고 있었습니다. 아래 다이어그램은 이 변화의 흐름을 잘 보여줍니다. Image: AI-Generated Content 조직의 이름이 바뀌었다는 것 2026년, CICD에서 Platform엔지니어링팀으로 조직 이름이 바뀌었습니다. 단순한 명칭 변경이 아니었습니다. 업무의 철학이 달라졌습니다. 배포 자동화 도구를 만들고 관리하는 것에서, 개발자가 더 잘 개발할 수 있는 환경 자체를 설계하는 것으로 미션이 바뀐 것입니다. kt cloud의 플랫폼 엔지니어링 여정이 본격적으로 시작된 시점이었습니다. 이 전환을 촉발한 질문은 세 가지였습니다. 첫째, 개발자가 새 서비스를 시작할 때 왜 이렇게 많은 것을 직접 설정해야 하는가? 둘째, 보안 정책과 표준을 지키면서도 속도를 낼 수 있는 방법은 무엇인가? 셋째, AI가 발전하고 있는 지금, 플랫폼이 더 지능적으로 개발자를 도울 수 있지 않을까? 업무 방식이 달라졌다 명칭 변경과 함께 실제 업무 프로세스도 달라지기 시작했습니다. 가장 큰 변화는 티켓 기반 요청에서 셀프서비스로의 전환입니다. 이전에는 개발팀이 새로운 서비스 생성이 필요하면 CICD팀에 Slack 메시지를 보내거나 Jira 티켓을 등록해야 했습니다. ArgoCD 프로젝트 생성, Harbor 프로젝트 할당, Vault 시크릿 경로 구성 같은 작업들이 모

측정할 수 없으면 개선할 수 없다 - AI Pick 추천 카드를 위한 sLLM 정렬 학습기

안녕하세요! 😆 'ItemLM: 상품 정보 기반의 임베딩 생성기', 'T4 GPU 1장으로 일궈낸 올리브영의 Gemma 3 기반 sLLM…

통합임베딩으로 개인화 푸시 CTR +21.3%를 만든 과정

유저를 한 번 이해하고, 모든 결정이 공유하는 Layer 0 1편: MATCH란 무엇인가 2편: MATCH Console & MAI 3편: 통합임베딩으로 개인화 푸시 안녕하세요. 무신사 Core-E Personalization 팀에서 개인화 모델을 개발하고 있는 오승모, 방효석입니다. 이 시리즈에서는 MATCH를 중심으로 데이터를 더 나은 결정으로 바꾸는 방법을 이야기해 왔습니다. 운영자가 규칙을 직접 만드는 대신 모델이 유저 단위의 결정을 만들고, 여러 결정의 우선순위를 시스템이 판단하는 과정도 소개했습니다. 그런데 이 모든 이야기에는 하나의 공통된 전제가 깔려 있습니다. “시스템이 유저를 충분히 이해하고 있다”는 전제입니다. 어떤 유저에게 어떤 기획전을 보내야 하는지 결정하려면, 시스템 어딘가에는 그 유저의 취향과 관심사를 표현하는 공통된 표현이 존재해야 합니다. 모델마다 유저를 제각각 이해한다면, 아무리 좋은 의사결정 로직을 만들어도 결국 그 한계를 넘기 어렵습니다. 이 공통된 기반을 만드는 일은 개별 서비스의 모델을 잘 만드는 일과는 성격이 다릅니다. 새 모델의 성과는 지표로 바로 보이지만, 유저에 대한 이해를 쌓는 일은 그 자체로는 눈에 보이는 숫자를 만들지 않습니다. 대신 그 위에 올라서는 모든 결정의 품질을 좌우합니다. 이번 글은 무신사의 모든 모델과 의사결정이 공유하는 유저 표현층, Layer 0(통합임베딩)을 구축하고 이를 개인화 푸시에 처음 적용한 과정을 담았습니다. 왜 통합임베딩이 필요했는가 1편에서는 개별 최적화가 아무리 정교해져도 전체 경험에는 두 가지 갭이 남는다고 이야기했습니다. 하나는 여러 시스템이 서로 다른 결정을 내리면서 생기는 일관성의 격차, 다른 하나는 각 시스템의 학습이 저마다의 사일로(Silo)에 갇혀 서로에게 이어지지 않는 학습의 격차입니다. 통합임베딩이 겨냥한 것은 그중에서도 학습의 격차입니다. 그동안 무신사의 유저 단위 의사결정은 대부분 각자의 전용 모델로 구현되어 왔습니다. 새로운 결정이 하나 생길 때마다 그 서비스만을 위한 로그를 모으고, 피처를 설계하고, 학습 파이프라인을 만들고, 서빙과 모니터링을 붙이는 일이 반복되었습니다. 문제는 모델의 수가 아니라, 같은 유저를 여러 번 배우는 구조였습니다. 추천 모델은 상품 반응을, 푸시 모델은 클릭을, 쿠폰 모델은 구매를 학습합니다. 모두 같은 유저를 대상으로 하지만, 각 모델이 쌓은 유저 이해는 서로 공유되지 않았습니다. 그래서 새 모델을 만들 때마다 유저를 처음부터 다시 배워야 했고, 유저에 대한 이해는 모델 수만큼 조각나 있었습니다. 개인화 푸시는 이런 구조를 가장 잘 보여주는 사례였습니다. 오랫동안 DeepFM 기반 CTR 예측 모델로 운영되며 유저와 기획전 피처를 입력으로 클릭 확률을 예측했습니다. 모델 자체의 성능이 나빴던 것은 아닙니다. 문제는 시간이 지나면서 구조 자체가 유지하기 어려운 형태로 변했다는 점이었습니다. 먼저 운영 지식이 점차 사라졌습니다. 모델의 운영 주체가 여러 차례 바뀌면서 어떤 피처를 왜 넣었는지, 장애가 발생했을 때 무엇을 점검해야 하는지 같은 맥락이 함께 사라졌습니다. 파이프라인은 매일 정상적으로 동작했지만 예측 품질의 변동을 설명할 수 있는 사람은 없었습니다. 시리즈 1편에서 이야기했던 “담당자가 바뀌면 마케팅 자산이 리셋된다”는 현상이 모델 레이어에서도 똑같이 일어나고 있었던 것입니다. 전용 학습 파이프라인을 유지하는 비용도 적지 않았습니다. 개인화 푸시만을 위한 데이터 생성, 피처 가공, 모델 학습 파이프라인을 매일 돌려야 했고, 사이클이 멈추면 그날의 발송 품질도 함께 흔들렸습니다. 세일즈 푸시와 라이브 푸시처럼 같은 앱푸시 채널 안에서도 서로 다른 모델과 파이프라인이 각각 운영되고 있었습니다. 이런 문제들은 모두 같은 원인에서 비롯되었습니다. 유저를 이해하는 책임을 각 모델이 따로 가지고 있었기 때문입니다. 모델이 하나 늘어날 때마다 유저를 이해하기 위한 학습과 운영도 함께 늘어났고, 그 비용 역시 계속 쌓였습니다. 그래서 방향을 바꿨습니다. 결정마다 새로운 모델을 만드는 대신

LLM은 왜 Graph DB를 필요로 할까?

RAG에서 GraphRAG, AI Agent까지 생성형 AI와 LLM의 활용이 확대되면서 기업이 보유한 데이터를 AI와 연결하는 방법도 빠르게 발전하고 있습니다. 대표적인 방식이 RAG(Retrieval-Augmented Generation)입니다. RAG는 사용자의 질문과 관련된 정보를 검색하고, 검색 결과를 LLM의 Context로 제공하여 보다 정확하고 근거 있는 답변을 생성하도록 합니다. 하지만 실제 기업의 데이터는 문서만으로 구성되어 있지 않습니다. 고객과 계약, 기업과 투자자, 직원과 프로젝트처럼 수많은 … LLM은 왜 Graph DB를 필요로 할까? 더 보기 »

토스증권 추천과 검색은 어떻게 진화하고 있을까?

추천, RAG, 그래프 검색을 만들며 마주한 문제와 선택

사내 지식으로 Agentic RAG 만들기 (1/3) : RAG 파이프라인의 바닥 다지기

[ AI-DLC 사례 1: 검색 ] AI-DLC로 3일, 뷰티 자연어 검색을 만드는 여정

목차 [ AI-DLC 사례 1: 검색 ] AI-DLC로 3일, 뷰티 자연어 검색을 만드는 여정 [ AI-DLC 사례 2: 추천 ] AI로 코딩은 빨라졌는데, 왜 실험은 여전히 어려웠을까?     개요 9월 GS SHOP에 고객과 대화하며 상품을 찾아주는 쇼핑Agent 서비스가 오픈할 예정입니다. 기존 검색 서비스에서는 고객이 "샴푸", "손상모 샴푸"처럼 짧은 검색어를 입력했다면, 쇼핑Agent에서는 원하는 조건을 자연어 문장으로 표현할 수 있습니다.   "건조한 두피와 손상모발 동시에 관리하는 샴푸" 그런데 문장을 받아줄 검색이 아직 없었습니다. GS SHOP 검색의 주축은 단어 검색과 임베딩 검색이고, 문장에 담긴 여러 조건을 나눠서 다루는 단계가 없었기 때문입니다. 2026년 7월 7일부터 9일까지, 저희 검색추천파트 4명은 AI-DLC(AI-Driven Development Life Cycle) 라는 개발 방법론으로 이 문제를 풀어봤습니다. 요구사항 정의부터 운영 엔드포