비전공자의 챗봇 구축 경험 정리 : Rule-based, RAG 기반 LLM 챗봇

챗봇 기술은 이제 단순한 자동 응답을 넘어서 어느 기업에나 쓰이고 있고, 생성형 AI를 활용한 자연스러운 대화까지 확장되고 있다. 어쩌다 보니 챗봇 관련 프로젝트에 자주 참여하게 되었고 Rule-based 기반의 query형 챗봇부터 RAG 기반 LLM 챗봇까지 다양하게 경험할 수 있었다. 사실 내가 이걸 완전히 이해하고 시작했던 건 절대 아니고 지금도 부족한 지식으로 프로젝트에 참여 중이라..그래서 이번 기회에 내가 다뤄봤던 챗봇 기술들을 아주 간단하게 정리해보려고 한다.

1. Rule-based 챗봇

인턴십 당시, 사내 메신저용 챗봇을 기획하고 제작한 적이 있다. 어느 사내용 챗봇이나 엄청난 기능을 갖추기 어렵다고 생각하긴 하지만 이 프로젝트는 제약이 정말 많았는데,

• 외부 API 연동 불가 (폐쇄망 보안 환경)
• 노코드 환경 (개밸자가 아닌 사람도 구축하고 관리가능 할 수 있도록)
• 키워드 기반 처리 (자연어 이해 없이 정해진 흐름만 지원)

그래서 Microsoft Adaptive Card를 활용해서 버튼형 UI로만 대화가 가능했고 기본적으로는 Rule-based 챗봇 + 카드 UI 조합이었다. 노코드 툴에 사내 DB를 연결하는 방식으로 구성해서 자연스러운 대화는 거의 불가능했다. (사실상 일방형 소통에 가까웠다.) 당시 기획했던 챗봇은 거의 고객경험지수(NPS)를 조회하는 용도로만 사용했기 때문에 질문 패턴도 단순했고, 자연어 처리 기능이 빠져 있어도 큰 불편은 없었다. 기획할 당시엔 버튼 흐름이 너무 복잡하게 느껴지지 않도록 최대한 단순화했고 Depth도 깊지 않게 구성하려고 신경 썼던 기억이 있다. 챗봇은 GPT 같은 LLM을 붙일 수 없는 구조라서 챗봇이라기보다는 그냥 단순한 자동화 인터페이스에 가까웠다. (PoC까지만 참여했고 이후 실제 서비스로 구현됐는지는 잘 모른다.)

2. RAG 기반 LLM 챗봇 : GPT API와의 통합

부트캠프 팀 프로젝트에서는 외부 LLM API(GPT-3.5)를 연동해 RAG 구조로 챗봇을 만들었다. 상대적으로 저렴한 버전의 GPT API를 사용했지만 응답 품질은 꽤 괜찮았다. 다만, 캐시에 저장된 내용을 제대로 기억하지 못하는 문제가 있었는데 이게 추론을 못하는 GPT 자체의 한계인지 아니면 로직의 문제인지는 정확히 판단하기 어려웠다. 질문이 들어오면 내부 문서(DB)에서 관련 내용을 먼저 검색하고 → 그 결과를 GPT에게 넘겨주고 → 자연어로 답변을 생성하는 구조였다. 예전 Rule-based 챗봇은 예외 상황이 발생할 때마다 조건을 계속 추가해야 했고 대화 흐름(Depth)이 조금만 복잡해져도 아예 로직을 새로 설계 해야하는 경우도 있었다. 반면 RAG 기반 챗봇은 GPT가 검색된 문서를 바탕으로 자연스럽고 유연한 답변을 생성하기 때문에 운영자가 따로 규칙을 수정하거나 예외를 일일이 처리할 필요가 거의 없었다. RAG 문서 구성도 어렵지 않았다. 대부분의 데이터는 사내 FAQ를 크롤링해서 만들었고 그걸 기준으로 어떻게 문서를 검색할지 챗봇 형태로 만드는 데는 큰 어려움이 없었다. 아마 난이도가 낮은 프로젝트를 주셔서 그런 것 같다..
 

2-1) RAG 구조

RAG는 질문 → 관련 문서 검색 → GPT에게 넘겨서 응답 생성 이런 흐름이다.
GPT가 모든 정보를 알고 있는 건 아니기 때문에 내부 데이터를 연결해줘야 실제로 쓸만한 챗봇이 된다.
 
구성 요소

• 벡터DB
• 문서 임베딩 기술 : 문서를 숫자로 바꿔서 검색 가능하게 함 (코사인 유사도 활용)
• 프롬프트 구성 : 우리가 원하는 정보를 GPT가 이해할 수 있는 구조로 질문을 바꿔주는 역할

LLM을 연결하면서 프롬프트 엔지니어링을 제대로 해보게됬는데, 프롬프트 엔지니어링을 해보면서 느낀건 생각보다 모델을 따로 파인튜닝하지 않아도, 프롬프트만 잘 설계하면 원하는 답변을 꽤 정확하게 끌어낼 수 있다는 점이었다. 처음엔 그냥 지피티한테 말하는 거라고 생각했는데 프롬프트를 어떻게 짜느냐에 따라 성능이 확연히 달라졌다. 단순히 질문만 던지는 게 아니라 예시를 포함하거나 문서 내용을 어떤 방식으로 연결하느냐에 따라 결과가 완전히 달라졌다.
처음엔 few-shot과 zero-shot 프롬프트를 단순히 구분만 했는데, 내가 다루는 프로젝트들이 대부분 사내용이고, 도메인 특화 내용이 많다 보니 관련 예시를 넣는 few-shot 방식이 정확도는 높았지만, 데이터가 다양해야 하는 상황에선 오히려 제약이 생겼다. 결국 zero-shot prompting을 구조적으로 활용하는 방향으로 갔다. 문서 기반 응답에선 검색된 문서 + 질문을 어떻게 조합하느냐가 핵심이었고, 그걸 설계하는 게 결국 프롬프팅 능력이었다.

2-2) LangChain 구조

RAG 구조를 구현할 때 자주 사용하는 프레임워크다. LangChain은 GPT 같은 LLM을 실제 서비스에 연결할 수 있도록 도와주는 프레임워크다. 직접 프롬프트를 만들고, 문서를 검색하고, GPT한테 질문하는 과정을 이어서 자동화해준다.
 
보통 RAG 구조를 LangChain으로 구성하면 이런 흐름이 된다:

[사용자 질문]
      ↓
[문서 검색]
      ↓
[검색된 문서 + 질문 → 프롬프트 구성]
      ↓
[LLM 응답 생성]
      ↓
[최종 답변]

 
LangChain은 이 과정에서 각각을 따로따로 만들 필요 없이 컴포넌트 단위로 조립하듯이 구성할 수 있게 해준다.
 
 
LangChain에서 자주 쓰는 주요 컴포넌트

LLM	LLM API를 호출(GPT 호출)
PromptTemplate	GPT에 보낼 프롬프트를 자동 생성
Retriever	사용자의 질문에 맞는 문서를 찾는 역할
DocumentLoader	pdf와 같은 문서를 불러옴
TextSplitter	문서를 청크 단위로 나눔 (너무 길면 잘 안되기 때문이다..)
RetrievalQA	질문-응답 흐름을 구성해주는 모듈

 
사실 언어모델을 직접 파인튜닝하는 것보다 LangChain으로 바로 연결하는 게 훨씬 빠르고, 성능도 좋았다. 비용이나 시간 면에서도 훨씬 효율적이라 만족스러웠다.
 
지금도 챗봇 관련 프로젝트에 참여 중이고 이번에는 RAG 시스템을 처음부터 구축하는 과정을 경험하고 있다. 예전 부트캠프에서 했던 팀 프로젝트와는 차원이 다르게 데이터 구축 과정에서부터 훨씬 신경 쓸 게 많고 복잡하다.
아직은 완전한 RAG 구조가 적용되진 않았고 질문 키워드를 기반으로 답변을 뽑아내는 방식이라고 드는 정도의 챗봇이라 좀 불완전하긴 하다. 솔직히 문맥을 전혀 이해하지 못한다.. 근데 경쟁사의 챗봇은 더 심했던 것 같다...
그래도 일단 로직에 맞는 대답은 하고 있고, UI도 예전에 인턴십에서 만들었던 버튼형 구조랑 비슷해서 이제 업그레이드 되는 과정을 보겠구나 라는 생각이 들기도 했다.
그래도 앞으로 RAG 도입 예정이라고 하니 좀 더 공부해서 업무에도 잘 녹여보는 게 목표다.