Search
moon
sun

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

URL
생성 일시
2026/10/10 01:06
최종 편집 일시
2026/10/10 01:06
태그
여기어때
파일과 미디어
|| 글. 김수비(소피) / 공통플랫폼개발팀 안녕하세요, 여기어때컴퍼니 공통플랫폼개발팀 소피입니다. 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로 남아, 파이프라인은 성공했는데 검색에서는 빠진 문서가 생깁니다. 그래