LLM 성능과 속도의 트레이드오프: 모델 교체 대신 RAG 구조 개선 선택

왜 이 생각이 필요했나

동숲 프로젝트에 적용한 모델은 gpt-oss:20b입니다. 오픈소스로 제공되는 모델이었고, 테스트한 후보 모델 중 답변의 일관성과 응답 품질이 가장 안정적이라고 판단하여 선택했습니다.

하지만 Ollama 환경에서 모델을 직접 구동하면서 제한된 서버 자원으로 인해 응답 속도 문제가 발생했습니다. 특히 사용자가 질문을 입력한 뒤 답변을 반환하기까지 시간이 오래 걸렸고, 실제 서비스에서는 답변 품질뿐만 아니라 사용자 경험을 위한 응답 시간 역시 중요한 요소라는 점을 체감했습니다.

이를 해결하기 위해 두 가지 방향을 고민했습니다.

첫 번째는 더 작은 모델로 교체하여 추론 속도를 개선하는 방식이고, 두 번째는 현재 모델을 유지하면서 RAG 구조와 데이터 처리 방식을 개선하는 방식입니다.

다른 모델 검토

Ollama에서 사용할 수 있는 여러 모델을 대상으로 품질과 속도를 비교했습니다.

우선순위	모델	이유
1	`gpt-oss:20b`	답변 생성 품질과 일관성이 가장 안정적이었음.
2	`qwen3:14b`	모델 크기가 작아 속도 측면에서는 장점이 있었지만 답변 품질이 부족했음.
3	`qwen3:8b`	응답 속도는 빠르지만 한국어 문맥 이해와 답변 품질에 한계가 있었음.
4	`qwen3:30b`	품질 비교용 후보였지만 제한된 환경에서는 추론 시간이 너무 길었음.

적용 방식

인프라 : OCI(Oracle Cloud Infrastructure) 사용
구성 : 인스턴스 1개, Docker 컨테이너 기반 운영
컨테이너 : Ollama 컨테이너 생성 후 모델 가동

테스트 케이스는 다음과 같이 구성했습니다.

학생성공지원팀 전화번호 알려줘
호텔관광학과 담당자 연락처 알려줘
졸업식 언제야?
졸업학점 알려줘
기숙사 정보 알려줘

결론 : 모델 크기를 줄이면 응답 속도는 개선할 수 있었지만 답변 품질과 일관성이 떨어졌습니다. 반대로 현재 모델보다 큰 모델은 더 높은 품질을 기대할 수 있지만 제한된 서버 환경에서는 서비스 적용이 어려웠습니다. 결국 모델 크기 조절만으로는 품질과 속도의 균형점을 찾기 어렵다고 판단했고, 기존 모델을 유지하면서 RAG 구조 개선을 통해 전체 시스템 성능을 개선하는 방향으로 접근했습니다.

모델 교체 대신 선택한 개선 방향

1. Hybrid Search 도입

2. 문서 정제와 메타데이터 구조화

1. Hybrid Search 도입

기존 검색 방식에서는 사용자의 질문 표현과 실제 문서 표현이 다를 경우 적절한 근거 문서를 찾지 못하는 문제가 있었습니다.

예를 들어 사용자가 “학생성공지원팀 전화번호 알려줘”라고 질문하더라도 실제 문서에는 부서명, 담당 업무, 연락처가 서로 다른 형태로 저장되어 있을 수 있습니다.

이를 개선하기 위해 BM25 기반 키워드 검색과 SentenceTransformer 임베딩 기반 의미 검색을 결합한 Hybrid Search를 적용했습니다.

BM25는 정확한 키워드 매칭에 강점이 있고, 임베딩 기반 검색은 표현이 다르더라도 의미적으로 유사한 문서를 찾는 데 강점이 있습니다.

두 방식을 결합하여 검색 정확도를 높이고, LLM이 더 적절한 근거 문서를 기반으로 답변을 생성할 수 있도록 구성했습니다.

2. 문서 정제와 메타데이터 구조화

RAG 시스템에서 중요한 것은 단순히 많은 데이터를 저장하는 것이 아니라, LLM이 활용하기 좋은 형태로 데이터를 구성하는 것이라고 판단했습니다.

학교 홈페이지에서 수집한 공지사항, 학사 일정, 대학 규정집, 부서 정보 데이터에는 메뉴, UI 요소, 중복 문장 등 검색에 불필요한 정보가 포함되어 있었습니다.

이를 해결하기 위해 다음과 같은 데이터 정제 과정을 적용했습니다.

제목, 본문, URL 분리
문서 유형 구분
부서, 작성일, 연락처 등 메타데이터 구성
불필요한 UI 텍스트 제거
문단 단위 chunking

이를 통해 LLM이 참고하는 context의 품질을 높이고, 불필요한 정보 전달을 줄였습니다.

적용하면서 고려한 점

추가 기술을 적용하면서 가장 중요하게 고려한 부분은 제한된 인프라 환경에서 실제 서비스 가능한 수준인가였습니다.

Reranker나 더 큰 모델을 적용하면 품질 향상을 기대할 수 있지만, 추가적인 연산 과정으로 인해 응답 시간이 증가할 가능성이 있었습니다.

동숲 프로젝트는 OCI 환경에서 Ollama 기반 LLM을 운영하고 있었기 때문에, 무거운 모델이나 복잡한 구조를 추가하기보다는 현재 환경에서 효과를 낼 수 있는 방향을 선택했습니다.

따라서 모델 자체의 크기를 증가시키는 대신 검색 과정과 데이터 품질을 개선하여 LLM이 더 정확한 정보를 기반으로 답변하도록 구성했습니다.

결과와 기대 효과

모델 교체 대신 RAG 구조 개선을 선택하면서, 단순히 LLM 자체의 성능에 의존하는 구조에서 벗어날 수 있었습니다.

Hybrid Search를 통해 질문 의도에 맞는 문서를 더 안정적으로 검색할 수 있었고, 문서 정제와 메타데이터 구조화를 통해 LLM에게 전달되는 context 품질을 향상시킬 수 있었습니다.

모델 자체의 추론 속도를 직접 줄인 것은 아니지만, 잘못된 검색 결과나 불필요한 context 전달을 줄여 전체 RAG 파이프라인의 효율성을 개선할 수 있었습니다.

결과적으로 동숲 프로젝트에서는 모델을 교체하는 것보다 현재 환경에서 가장 적합한 모델을 유지하고, 검색과 데이터 처리 구조를 개선하는 것이 더 현실적인 해결 방법이라고 판단했습니다.

배운 점

이번 경험을 통해 LLM 서비스의 성능 개선은 단순히 더 큰 모델이나 더 빠른 모델을 선택하는 문제가 아니라는 것을 배웠습니다.

작은 모델은 빠르지만 품질 문제가 발생했고, 큰 모델은 품질은 좋지만 서비스 환경에서는 속도 문제가 발생했습니다.

결국 중요한 것은 모델 하나의 성능이 아니라, 모델, 검색 구조, 데이터 품질, 인프라 환경을 함께 고려한 전체 시스템의 균형이었습니다.

특히 RAG 기반 서비스에서는 LLM 자체보다 어떤 정보를 어떻게 제공하는지가 답변 품질에 큰 영향을 준다는 것을 경험했습니다.

동숲 프로젝트를 통해 제한된 서버 환경에서도 모델 교체만이 정답이 아니라, Hybrid Search와 데이터 구조 개선을 통해 충분히 서비스 품질을 개선할 수 있다는 것을 배웠습니다.