RAG/벡터DB 시니어 테스트 · 코드품질 면접
새 면접Q. RAG 시스템에서 검색 품질과 생성 품질을 분리하여 테스트하는 전략을 설계한다면 어떻게 접근하시겠습니까? 각 레이어별 테스트 방법과 평가 지표를 설명해주세요.
임베딩-검색-재순위-생성의 파이프라인을 레이어별로 나누어 각각 독립적으로 검증할 수 있는 방법을 생각해보세요.
RAG 시스템은 크게 검색(Retrieval)과 생성(Generation) 레이어로 분리하여 테스트합니다. 검색 레이어는 단위 테스트로 임베딩 품질(코사인 유사도), 벡터 검색 정확도(Recall@K, MRR), 재순위 성능(NDCG)을 각각 측정합니다. 생성 레이어는 Mock 검색 결과를 주입하여 LLM 응답의 일관성, 환각(hallucination) 여부, 컨텍스트 충실도를 테스트합니다. 통합 테스트에서는 Golden Dataset을 활용해 end-to-end 정확도와 응답 시간을 측정하며, A/B 테스트로 실제 사용자 만족도를 추적합니다. 각 레이어의 실패를 독립적으로 추적할 수 있도록 테스트를 분리하는 것이 핵심입니다.
- • 검색과 생성 레이어를 분리하여 독립적으로 테스트
- • 검색 레이어는 Recall@K, MRR, NDCG 등 IR 메트릭 활용
- • 생성 레이어는 Mock 데이터로 환각과 컨텍스트 충실도 검증
- • Golden Dataset 기반 end-to-end 통합 테스트 구축
RAG 시스템의 품질 저하가 검색 실패인지 생성 실패인지 빠르게 파악하여 개선 포인트를 명확히 할 때 사용됩니다.
환각(hallucination)을 자동으로 탐지하는 테스트를 구현한다면 어떤 방법을 사용하시겠습니까?
Q. 벡터DB를 사용하는 애플리케이션에서 통합 테스트를 작성할 때, 테스트 환경 구성과 데이터 격리 전략을 어떻게 설계하시겠습니까? 특히 CI/CD 파이프라인에서 고려해야 할 사항을 포함해 설명해주세요.
테스트용 벡터DB 인스턴스 관리, 테스트 데이터 생성/정리, 병렬 테스트 실행 시 격리 방법을 고려해보세요.
벡터DB 통합 테스트는 Testcontainers나 Docker Compose를 활용해 격리된 테스트 인스턴스를 생성합니다. 각 테스트 케이스마다 고유한 컬렉션/인덱스 네임스페이스를 사용하여 병렬 실행 시 충돌을 방지합니다. 테스트 픽스처로 작은 규모의 실제 임베딩 데이터를 준비하되, 시드를 고정하여 재현성을 보장합니다. CI/CD에서는 경량 벡터DB(Qdrant, ChromaDB)를 사용하거나, 프로덕션과 동일한 DB라도 리소스를 최소화한 설정을 적용합니다. 테스트 후 자동 정리(teardown)를 보장하고, 실패 시 로그와 벡터DB 상태를 캡처하여 디버깅을 지원합니다.
- • Testcontainers로 격리된 벡터DB 인스턴스 생성
- • 고유 네임스페이스로 병렬 테스트 격리
- • 시드 고정으로 재현 가능한 테스트 데이터 생성
- • CI/CD에서 경량 설정과 자동 정리 전략 적용
벡터DB 업그레이드나 스키마 변경 시 기존 기능이 정상 동작하는지 자동으로 검증할 때 사용됩니다.
프로덕션 벡터DB가 수백만 개의 벡터를 저장하는 경우, 통합 테스트에서 성능 검증은 어떻게 하시겠습니까?
Q. 레거시 RAG 시스템에서 임베딩 생성, 벡터 검색, 프롬프트 구성, LLM 호출이 하나의 거대한 함수에 결합되어 있습니다. 이를 테스트 가능하고 유지보수 가능한 구조로 리팩토링하는 전략을 제시하고, 리팩토링 과정에서 기존 동작을 보장하는 방법을 설명해주세요.
단일 책임 원칙을 적용하여 각 단계를 분리하고, 리팩토링 전후의 동작 일치를 검증하는 테스트 전략을 생각해보세요.
먼저 기존 함수의 동작을 보장하는 Characterization Test(Golden Master Test)를 작성하여 다양한 입력에 대한 출력을 기록합니다. 그 다음 Extract Method 패턴으로 임베딩 생성, 벡터 검색, 재순위, 프롬프트 구성, LLM 호출을 각각 독립 함수로 분리하고, 각 함수마다 단위 테스트를 추가합니다. 의존성 주입을 도입하여 벡터DB 클라이언트와 LLM 클라이언트를 인터페이스화하고, Mock 객체로 테스트 가능하게 만듭니다. Strategy 패턴을 적용해 검색 전략과 재순위 알고리즘을 교체 가능하게 설계합니다. 리팩토링 각 단계마다 Characterization Test를 실행하여 기존 동작이 유지되는지 확인하며, 모든 테스트가 통과한 후에만 다음 단계로 진행합니다.
- • Characterization Test로 기존 동작 보존 검증
- • Extract Method로 각 책임을 독립 함수로 분리
- • 의존성 주입으로 외부 서비스 Mock 가능하게 설계
- • Strategy 패턴으로 알고리즘 교체 가능성 확보
- • 단계별 테스트 실행으로 안전한 리팩토링 보장
초기 프로토타입으로 만든 RAG 시스템을 프로덕션 수준으로 개선하거나, 새로운 검색 알고리즘을 안전하게 도입할 때 사용됩니다.
리팩토링 과정에서 성능 저하가 발생할 수 있는 지점은 어디이며, 어떻게 모니터링하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!