27B보다 2.4B가 더 나았던 문서 RAG 모델 선택기

AI 자동화2026년 8월 1일글: 홍서진, Duolabs9분 읽기blog blog-series document-rag-series llm model-openai-gpt-5 model-selection rag technical-note

문서 검색과 질의응답을 결합한 RAG 시스템을 만들 때 가장 먼저 떠오르는 질문은 대개 비슷합니다.

답변 모델은 클수록 좋은 것 아닐까요?

일반적인 언어 능력만 비교하면 큰 모델이 유리할 가능성이 높습니다. 하지만 실제 서비스에서는 모델이 얼마나 빨리 응답하는지, 다른 작업과 GPU를 함께 사용할 수 있는지, 검색된 근거를 충실히 따르는지가 더 중요할 수 있습니다.

듀오랩스는 문서 RAG의 답변 모델을 고르는 과정에서 27B 모델과 2.4B 모델을 실제 문서 질문으로 비교했습니다. 결과는 예상과 달랐습니다. 27B 모델은 제한 시간 안에 답변을 마치지 못했고, 2.4B 모델은 약 3.7초 만에 더 안정적인 답을 내놓았습니다.

이 글은 작은 모델이 항상 더 좋다는 주장이 아닙니다. RAG 모델은 크기가 아니라 전체 시스템 안에서의 역할과 제약으로 선택해야 한다는 실측 기록입니다.

RAG에서 답변 모델이 맡는 일

RAG는 모델이 모든 사실을 기억해 답하는 방식이 아닙니다. 먼저 검색기가 질문과 관련된 문서를 찾고, 답변 모델은 그 근거를 읽어 내용을 정리합니다.

사용자 질문
    ↓
관련 문서 검색
    ↓
근거 선별 및 정렬
    ↓
근거를 바탕으로 답변 생성

검색 품질이 충분하다는 전제에서 답변 모델이 잘해야 하는 일은 다음과 같습니다.

질문의 의도를 파악합니다.
검색 결과에서 필요한 내용을 찾습니다.
서로 충돌하는 근거를 구분합니다.
근거에 없는 내용을 만들어내지 않습니다.
사용자가 읽기 쉬운 형태로 답변을 정리합니다.

이 역할에는 거대한 사전 지식보다 문맥 준수 능력과 안정적인 응답 시간이 더 중요할 때가 있습니다.

첫 선택은 27B 모델이었습니다

처음에는 27B급 모델을 답변 생성에 사용하려고 했습니다. 더 큰 모델이라면 복잡한 질문과 긴 문서를 잘 처리할 것이라는 기대가 있었습니다.

하지만 실제 문서를 넣어 시험하자 예상과 다른 문제가 나타났습니다.

항목	27B 모델	2.4B 모델
실제 문서 질문 응답	180초 내 완료하지 못함	약 3.7초
사용한 GPU 메모리	약 18.2GB	약 4.2GB
다른 모델과 공존	어려움	가능
상충 근거 처리	제한 시간으로 측정하지 못함	의도대로 처리

이 수치는 특정 하드웨어와 당시 설정에서 측정한 결과입니다. 다른 GPU나 양자화 방식, 컨텍스트 길이를 사용하면 값은 달라질 수 있습니다. 다만 운영 판단에 필요한 차이는 충분히 분명했습니다.

큰 모델이 느린 것보다 더 큰 문제

응답 시간이 길다는 것만으로도 사용자 경험에는 문제가 됩니다. 그러나 더 까다로운 문제는 모델이 GPU 메모리에 안정적으로 머물지 못했다는 점입니다.

모델 서버에는 일정 시간 모델을 메모리에 유지하는 옵션이 있습니다. 이를 사용하면 매 요청마다 모델을 다시 불러오는 비용을 줄일 수 있습니다. 하지만 설정만으로 물리적인 GPU 메모리 한계를 없앨 수는 없습니다.

다른 서비스가 모델을 추가로 올리자 전체 사용량이 GPU 용량에 가까워졌고, 27B 모델은 메모리에서 내려갔습니다. 이후 요청에서는 모델을 다시 불러오는 데 약 11.6초가 추가되었습니다. 생성 속도도 초당 약 2.5토큰 수준으로 낮아졌습니다.

이 상황에서는 평균 응답 시간보다 첫 요청과 재로딩 이후 요청의 편차가 더 큰 문제가 됩니다. 어떤 사용자는 바로 답을 받고, 어떤 사용자는 모델 로딩부터 기다려야 하기 때문입니다.

작은 모델이 근거를 더 잘 따른 사례

속도만 빠르고 답변이 부정확하다면 작은 모델을 선택할 이유가 없습니다. 그래서 일부러 서로 충돌하는 문서를 함께 넣었습니다.

오래된 문서에는 이전 값이 적혀 있습니다.
최근 문서에는 변경된 값이 적혀 있습니다.
프롬프트에는 값이 다르면 최신 근거를 따르도록 지시했습니다.

2.4B 모델은 최근 문서를 기준으로 답하면서 이전 문서와 값이 다르다는 점도 함께 밝혔습니다. 반면 비교 대상으로 사용한 다른 8B 모델은 두 문서에 없는 조건을 덧붙여 새로운 값을 만들어냈습니다.

이 결과가 모든 질문에서 2.4B 모델이 더 정확하다는 뜻은 아닙니다. 다만 모델 크기만으로 근거 충실도를 예측할 수 없다는 점은 확인할 수 있었습니다.

RAG에서는 유창한 설명보다 다음 기준이 더 중요합니다.

근거 밖의 내용을 추가하지 않는가?
문서가 충돌할 때 차이를 인식하는가?
최신 문서와 폐기된 문서를 구분하는가?
답을 찾지 못했을 때 모른다고 말하는가?

모델보다 먼저 고쳐야 했던 근거 형식

초기 테스트에서는 모델 두 종류가 모두 오래된 문서의 값을 선택했습니다. 원인을 살펴보니 검색 결과에 문서의 수정일이 포함되어 있지 않았습니다.

사람은 문서 목록에서 날짜를 보고 최신 자료를 판단합니다. 하지만 모델에 전달한 근거에 날짜가 없다면 오래된 문서와 최신 문서는 같은 무게를 갖습니다.

그래서 각 근거에 수정일을 함께 전달했습니다.

[문서 A · 수정: 2026-07-28]
현재 적용되는 기준은 ...

[문서 B · 수정: 2025-11-03]
이전 기준은 ...

여기에 “값이 다르면 최근 문서를 우선하되, 이전 값이 존재했다는 사실도 설명한다”는 규칙을 추가하자 두 모델 모두 올바른 근거를 선택했습니다.

모델을 교체하기 전에 모델이 판단에 필요한 메타데이터를 받고 있는지부터 확인해야 하는 이유입니다.

모델 선택은 실제 질문으로 검증해야 합니다

일반 벤치마크 점수만으로 사내 문서 RAG의 품질을 판단하기는 어렵습니다. 실제 서비스에서는 조직의 문서 구조와 질문 유형이 성능을 결정하기 때문입니다.

다음과 같은 평가 세트를 준비하면 모델을 비교하기 수월합니다.

1. 단일 근거 질문

한 문서에 답이 명확히 있는 질문입니다. 검색된 내용을 빠짐없이 요약하는지 확인합니다.

2. 여러 문서를 합쳐야 하는 질문

서로 다른 문서의 내용을 조합해야 답할 수 있는 질문입니다. 일부 근거만 보고 성급하게 결론을 내리지 않는지 확인합니다.

3. 상충 근거 질문

최신 문서와 오래된 문서의 내용이 다른 질문입니다. 날짜와 우선순위 규칙을 제대로 적용하는지 확인합니다.

4. 답이 없는 질문

문서에 존재하지 않는 내용을 묻습니다. 그럴듯한 답을 만들어내지 않고 근거가 부족하다고 말하는지 확인합니다.

5. 동시 요청

한 명이 사용할 때의 속도만 측정하면 운영 병목을 놓칠 수 있습니다. 여러 요청이 들어왔을 때 대기 시간이 어떻게 늘어나는지도 함께 봐야 합니다.

실무 체크리스트

실제 문서와 실제 사용자 질문으로 평가했나요?
첫 응답뿐 아니라 모델이 메모리에서 내려간 뒤의 응답도 측정했나요?
GPU 메모리를 다른 서비스와 함께 사용할 수 있나요?
상충하는 문서를 넣어 근거 우선순위를 확인했나요?
문서 수정일과 상태를 근거에 포함했나요?
답이 없는 질문에서 추측하지 않는지 확인했나요?
동시 요청 시 대기 시간과 실패 방식을 정했나요?

듀오랩스가 보는 관점

문서 RAG의 답변 모델은 가장 큰 모델이 아니라 서비스의 제약 안에서 근거를 안정적으로 따르는 모델이어야 합니다.

큰 모델을 선택하고 응답을 오래 기다리게 하는 것보다, 작은 모델에 좋은 검색 결과와 충분한 메타데이터를 제공하는 편이 더 나은 경험을 만들 수 있습니다. 모델 크기에 쓰는 자원을 문서 품질, 검색 평가, 근거 표시와 실패 처리에 투자하는 것이 효과적일 때도 많습니다.

이번 실험에서 2.4B 모델은 타협안이 아니었습니다. 해당 환경과 문서 질문에서는 속도, 자원 사용량, 근거 충실도를 함께 만족한 더 현실적인 선택이었습니다.

다음 글에서는 이 답변 모델 앞단에서 동작하는 문서 청킹, 임베딩, 하이브리드 검색과 관리자·공개 서비스의 인덱스를 분리한 구조를 살펴보겠습니다.