나는 현재 생성형 AI를 활용한 검색 서비스를 개발 중이다. 처음에는 메타의 Llama 모델을 사용하다가 최근 알리바바의 Qwen3 모델로 변경하여 RAG(Retrieval-Augmented Generation) 기술을 적용하고 있다. 이 과정에서 나는 RAG의 적용 방식을 두고 개발업체와 의견이 갈리는 경험을 했다.
나의 초기 생각은 'LLM이 가진 기존 지식 + 내부 문서'를 융합하여 더 풍부한 답변을 만드는 것이었다. 하지만 개발업체는 '오직 내부 문서'만으로 답변을 생성하는 것이 RAG의 올바른 방향이라고 주장했다.
이 글은 나의 이런 고민을 정리하고, 중소기업이 온프레미스 환경에서 sLLM(소형 거대 언어 모델)을 구축할 때 고려해야 할 사항, 특히 RAG 적용 방안에 대한 두 가지 접근법을 비교 분석하기 위해 작성해 본다.
1. 왜 중소기업은 '온프레미스 sLLM'을 고민하는가?
대기업처럼 막대한 자본이 없는 중소기업이 OpenAI의 ChatGPT API를 사용하지 않고, 굳이 복잡한 온프레미스 sLLM 구축을 고민하는 이유는 명확하다.
보안: 가장 결정적인 이유다. 기업의 민감한 내부 데이터를 외부 클라우드 서비스로 전송하지 않고, 우리 회사 서버 안에서만 안전하게 처리할 수 있다.
비용: 초기 구축 비용은 들지만, API 호출당 과금되는 방식이 아니므로 장기적으로 대규모 사용 시 비용을 절감할 수 있다.
sLLM의 발전: Llama, Qwen, Mistral 등 오픈소스 sLLM의 성능이 비약적으로 발전하여, 비교적 적은 컴퓨팅 자원으로도 충분히 활용 가능한 수준에 도달했다.
2. RAG 적용의 두 가지 접근법: 당신의 AI는 '창작자'인가, '답변자'인가?
RAG는 LLM이 답변을 생성할 때, 외부 지식 DB(우리의 경우 내부 문서)에서 관련 정보를 '검색(Retrieval)'하여, 그 내용을 '참고(Augmented)'해서 답변을 '생성(Generation)'하는 기술이다. 환각(Hallucination)을 줄이는 핵심 기술이지만, 그 적용 방식에 따라 AI의 역할이 완전히 달라진다.
2.1 접근법 A (개발업체의 제안): 순수 내부 문서 기반 답변 (Grounded Answering) 이 방식에서 LLM은 '제공된 문서의 내용을 충실하게 이해하고 요약하는 답변자'의 역할만 수행한다. LLM이 가진 자체적인 일반 지식은 철저히 배제된다.
장점
환각 최소화: 답변이 100% 내부 문서에 근거하므로, AI가 사실이 아닌 내용을 지어낼 확률이 거의 없다.
정보 출처 명확: 모든 답변은 특정 문서를 근거로 하므로, 답변의 신뢰도를 확보하고 검증하기 쉽다.
단점
제한된 답변 범위: 내가 우려했듯, 내부 문서에 없는 내용을 질문하면 "알 수 없습니다"라고 답변할 수밖에 없다.
답변의 깊이 부족: 참고하는 문서의 내용이 짧으면, AI의 답변 역시 단편적이고 짧아질 수밖에 없다.
2.2 접근법 B (나의 초기 생각): LLM 지식 + 내부 문서 융합 답변 (Creative Answering) 이 방식에서 LLM은 '내부 문서를 중심으로 하되, 자신의 배경지식을 활용하여 내용을 더 풍부하게 만드는 창작자'의 역할을 수행한다.
장점
폭넓은 답변 범위: 내부 문서에 없는 내용이라도, LLM의 일반 지식을 활용하여 어느 정도 답변을 제공할 수 있다.
더 풍부하고 자연스러운 답변: 단순한 요약을 넘어, 추가적인 배경 설명이나 예시를 덧붙여 훨씬 더 깊이 있고 자연스러운 답변을 생성할 수 있다.
단점
환각 발생 가능성 증가: 내부 문서의 사실과 LLM의 (검증되지 않은) 일반 지식이 섞이면서, 그럴듯하지만 사실이 아닌 정보가 생성될 위험이 있다.
정보 출처의 모호성: 답변의 어느 부분이 내부 문서에서 왔고, 어느 부분이 LLM의 자체 지식인지 구분하기 어려워 신뢰도 문제가 발생할 수 있다.
3. 실무자를 위한 제안: 어떤 접근법을 선택해야 하는가?
결론적으로, 두 접근법 중 어느 하나가 절대적으로 옳은 것은 아니다. 만들고자 하는 '서비스의 목적'에 따라 선택이 달라져야 한다.
접근법 A (내부 문서 기반)가 적합한 경우
서비스 예시: 사내 규정 챗봇, 기술 매뉴얼 검색, 과거 계약서 조회, 고객 지원(CS) 답변 시스템
핵심 요구사항: '정확성'과 '신뢰성'이 무엇보다 중요할 때. AI가 창의성을 발휘하면 안 되는 경우.
접근법 B (융합 기반)가 적합한 경우
서비스 예시: 아이디어 발상 도우미, 시장 조사 보고서 초안 작성, 블로그 글이나 마케팅 문구 생성
핵심 요구사항: '창의성'과 '풍부한 내용'이 더 중요할 때. 약간의 사실관계 오류는 후속 검토로 보완할 수 있는 경우.
[실무자를 위한 샘플 프롬프트 예제]
LLM의 행동을 통제하는 가장 직접적인 방법은 프롬프트다.
접근법 A를 위한 프롬프트:
너는 지금부터 '내부 문서 분석 전문가' 역할을 맡는다. 아래에 제공되는 [문서]의 내용만을 기반으로 질문에 답변해야 한다. [문서]에 내용이 없으면, 반드시 '자료에 없는 내용입니다'라고만 답변해라. 절대로 너의 기존 지식을 사용해서는 안 된다.접근법 B를 위한 프롬프트:
너는 지금부터 '친절한 비즈니스 분석가' 역할을 맡는다. 아래 [문서]의 내용을 최우선으로 참고하여 질문에 답변하되, 답변을 더 풍부하고 이해하기 쉽게 만들기 위해 너의 일반적인 지식을 활용하여 추가적인 설명을 덧붙여도 좋다. 단, [문서]의 내용과 너의 지식은 명확히 구분하여 설명해라.
4. 결론
온프레미스 sLLM 구축은 단순히 모델을 설치하는 기술적인 문제를 넘어, 우리 회사에 맞는 AI의 역할을 정의하는 전략적인 과정이다. 개발업체와의 논의에서 핵심은 '어떤 RAG가 진짜인가'가 아니라, '우리가 만들 서비스에 어떤 RAG가 더 적합한가'가 되어야 한다.
이러한 명확한 기준을 가지고 접근할 때, 중소기업도 성공적으로 우리만의 생성형 AI 서비스를 구축할 수 있을 것이다.
5. 그 후 1년, 실제로는 이렇게 됐다 (2026년 10월 추가)
이 글을 쓰고 1년이 지났다. 그동안 바뀐 것부터 표로 정리하면 이렇다.
| 항목 | 1년 전 (이 글을 쓸 때) | 지금 |
|---|---|---|
| RAG 방식 | A(내부 문서만)와 B(융합) 사이에서 고민 | A, 내부 문서 기반 |
| 모델 | Llama → Qwen3 | Gemma 4 |
| GPU | - | A100 80GB |
| 가장 큰 고민 | AI가 어떤 방식으로 답할까 | 검색, 특히 벡터 검색 |
5.1 결국 A로 갔다
나는 B처럼 LLM의 지식과 내부 문서를 섞고 싶었다. 하지만 막상 해 보니 그게 쉽게 되지 않았다. 지금은 내부 문서에 근거해서 답하는 A 방식으로 가고 있다.
5.2 모델은 생각보다 중요하지 않았다
Llama로 시작해서 Qwen3로 바꿨고, 지금은 Gemma 4를 쓴다. GPU는 A100 80GB다. 모델을 두 번 바꿔 보니, 모델 자체는 그리 중요하지 않은 것 같다.
5.3 진짜 문제는 검색이었다
RAG는 검색해 온 문서 조각을 보고 답을 만든다. 검색이 엉뚱한 조각을 가져오면 모델이 아무리 좋아도 답이 틀린다. 내가 써 보니 특히 벡터 검색이 좀 애매했다.
벡터 검색은 뜻이 비슷한 문장을 찾는 데는 강하다. 반대로 문서 번호, 버전(R1, R2), 사람 이름처럼 글자가 정확히 맞아야 하는 것에는 약하다. 문서 쪽 문제는 따로 정리해 두었다. AI-Ready 데이터 글에서 R1·R2 중복, 동명이인 문제를 다뤘다.
그래서 검색 쪽에 두 가지를 적용했다.
- 하이브리드 검색: 키워드 검색과 벡터 검색을 함께 쓴다. 정확히 맞아야 하는 단어는 키워드 검색이, 뜻이 비슷한 문장은 벡터 검색이 맡는 식이다.
- 재정렬(reranker): 검색해 온 조각들을 질문과 얼마나 맞는지 한 번 더 따져서 순위를 다시 매긴다.
두 가지를 작은 예제로 직접 돌려 본 과정은 RAG 검색 이해하기 4편에 정리했다.
5.4 완료는 없다
이 일에 완료라는 건 없는 것 같다. 계속 고도화하고 발전시켜 나가야 한다.
1년 전 제목에 던진 질문, "당신의 AI는 창작자인가, 답변자인가?"에 대한 지금의 답은 답변자다. 그리고 좋은 답변자를 만드는 건 모델보다 검색과 문서였다.
함께 읽으면 좋은 글 (AI 친화 문서 시리즈)
댓글
댓글 쓰기