[RAG] 데이터 파이프라인(ETL) 관점에서 본 LLM 인덱싱 자동화

RAG 시스템을 처음 만들 때 대부분 문서를 한 번 임베딩해서 벡터 인덱스에 넣습니다. 초기 데모 단계에서는 잘 동작합니다. 그런데 운영 단계로 넘어가면 문제가 생깁니다. 문서가 계속 바뀌는데 인덱스는 그대로라는 상황입니다. 

LLM RAG 시스템에서 인덱싱 동기화 문제

RAG 시스템에서 가장 흔하게 발생하는 문제 중 하나는 데이터 동기화입니다. 원본 데이터는 계속 업데이트되는데 벡터 인덱스는 업데이트되지 않는 경우입니다.

저희 서비스에서도 FAQ 챗봇을 운영하면서 같은 문제가 발생했습니다. FAQ 데이터는 MySQL에 저장되어 있었고 Elasticsearch 벡터 인덱스에 임베딩을 저장하는 구조였습니다.

초기에는 문서가 약 2만 개 정도였습니다. 수동으로 임베딩을 생성하고 인덱싱했습니다. 테스트 환경에서는 문제가 없었습니다.

문제가 생긴 것은 운영 이후였습니다. 하루에 약 300에서 500개의 문서가 수정되기 시작했습니다. 신규 문서도 계속 추가되었습니다.

벡터 인덱스와 실제 데이터가 점점 어긋나기 시작했습니다. 사용자 질문에서 최신 문서가 검색되지 않는 상황이 발생했습니다. 생각보다 자주 발생합니다.

 

운영에서 나타난 문제 패턴

로그를 보면 특정 문서는 검색 결과에 나오지 않았습니다. 이유를 확인해보니 인덱스가 업데이트되지 않았습니다.

문서 수정은 하루 수백 건이었는데 인덱싱은 일주일에 한 번 정도 수동으로 실행하고 있었습니다. 이 구조는 운영에서 오래 버티기 어렵습니다.

그래서 ETL 기반 인덱싱 자동화를 도입하게 되었습니다.

 

LLM 인덱싱 자동화 방식 비교

인덱싱 자동화를 만들기 전에 두 가지 방법을 비교했습니다. 배치 방식과 이벤트 기반 방식이었습니다.

방법 A 배치 기반 ETL

정해진 시간에 데이터를 읽고 임베딩을 생성하는 방식입니다.

장점은 구현이 단순합니다. 하루 한 번 또는 한 시간마다 실행하면 됩니다. 운영도 비교적 쉽습니다.

하지만 단점이 있습니다. 데이터 반영이 느립니다. 문서 수정 이후 인덱스 반영까지 시간이 걸립니다.

 

방법 B 이벤트 기반 인덱싱

문서가 변경될 때마다 이벤트를 발생시키고 인덱싱 작업을 실행하는 방식입니다.

장점은 데이터 동기화가 빠르다는 점입니다. 거의 실시간으로 인덱스가 업데이트됩니다.

단점은 시스템 복잡도가 올라간다는 점입니다. 메시지 큐나 스트리밍 시스템이 필요합니다.

결론적으로 저희는 두 방식을 조합했습니다. 기본은 이벤트 기반이고 장애 대비용으로 배치 ETL을 추가했습니다. 운영에서는 이런 이중 구조가 꽤 안정적입니다.

 

ETL 기반 LLM 인덱싱 자동화 구현

전체 구조는 다음과 같이 만들었습니다. 데이터 변경 이벤트를 Kafka로 보내고 인덱싱 워커가 이를 처리하는 방식입니다.

Spring Boot 서비스에서 문서 변경 이벤트를 발행했습니다.

public class FaqService {

    public void updateFaq(Faq faq){

        faqRepository.save(faq);

        // 운영 팁
        // DB 트랜잭션 이후 이벤트 발행합니다
        // 안 그러면 롤백 상황에서 데이터 불일치 발생합니다

        kafkaProducer.send("faq-update", faq.getId());
    }

}

인덱싱 워커는 이벤트를 받아서 임베딩을 생성하고 Elasticsearch에 저장합니다.

public class IndexingWorker {

    public void process(Long faqId){

        Faq faq = faqRepository.findById(faqId);

        // 임베딩 생성
        float[] embedding = embeddingClient.embed(faq.getContent());

        // 벡터 인덱스 저장
        elasticsearchClient.index(faqId, embedding);

    }

}

운영 결과

이 구조를 적용한 이후 인덱스 동기화 문제가 거의 사라졌습니다.

문서 수정 이후 약 5초에서 10초 사이에 인덱스가 업데이트되었습니다.

또 하나 장점은 확장성이었습니다. 인덱싱 워커를 여러 개 실행하면 처리량을 쉽게 늘릴 수 있습니다.

하루 약 1만 건 정도 문서 변경 이벤트를 처리하고 있습니다. 시스템 부하는 크지 않습니다. 체감상 안정적으로 돌아가고 있습니다.

 

LLM 인덱싱 자동화의 현실적인 결론

RAG 시스템에서 인덱싱 자동화는 선택이 아니라 필수입니다. 데이터가 조금만 늘어나도 수동 인덱싱은 운영이 어렵습니다.

특히 문서 변경이 많은 서비스라면 ETL 기반 구조가 필요합니다.

다만 이벤트 기반 인덱싱은 운영 복잡도가 올라갑니다. Kafka 같은 인프라를 관리해야 합니다.

그래서 처음에는 단순한 배치 ETL로 시작하는 것도 좋은 방법입니다. 데이터 규모가 커지면 이벤트 기반으로 확장하면 됩니다.

운영 경험상 RAG 시스템의 품질은 결국 데이터 파이프라인에서 결정됩니다. 임베딩 모델보다 데이터 동기화 구조가 더 중요할 때도 많습니다.