AI챗봇 설계의 딜레마: 규칙과 자유 사이에서 길을 찾다

솔직히 고백하자면, 처음 생성형 AI 기술이 폭발적으로 성장했을 때 저는 모든 것을 LLM(Large Language Model)으로 해결할 수 있을 거라 믿었습니다. 규칙 기반(Rule-based) 시나리오는 구시대의 유물처럼 느껴졌고, GPT나 Claude 같은 모델이 알아서 척척 대답해 주는 미래가 당장 눈앞에 와 있는 것 같았죠. 하지만 실제 프로덕션 환경에서 서비스를 운영하면서 이 순진한 생각은 뼈아픈 시행착오로 돌아왔습니다. 오늘은 제가 현장에서 몸으로 부딪히며 깨달은, 규칙 기반 시스템과 생성형 AI를 결합한 하이브리드 설계 전략에 대해 이야기해 보려 합니다.

저희 팀이 처음 야심 차게 내놓았던 순수 생성형 AI 기반 챗봇 프로젝트는 그야말로 '환각(Hallucination) 파티'였습니다. 고객이 환불 규정을 물어보면 AI는 너무나 친절하고 유창하게 "물론이죠! 3년 내라면 언제든 전액 환불해 드립니다"라고 답했습니다. 실제 회사 규정은 7일 이내 환불이었는데도 말이죠. 반대로 기존의 딱딱한 시나리오 봇은 "배송이 늦는데 언제 오나요?"라는 질문에 "죄송합니다. 이해하지 못했습니다. 메뉴에서 선택해 주세요"라는 기계적인 답변만 반복하며 고객의 화를 돋우고 있었고요.

기술 리더로서 막막했습니다. LLM의 유연함은 필요했지만, 비즈니스의 정확성을 포기할 수는 없었습니다. 프롬프트 엔지니어링을 아무리 정교하게 다듬어도 확률론적 모델이 주는 불확실성을 100% 제거하는 건 불가능에 가까웠습니다. 반대로 모든 케이스를 if-else로 짜 넣는 건 리소스 낭비이자 유지보수의 지옥으로 가는 급행열차였죠.

결국 우리는 인정해야 했습니다. AI챗봇에게 필요한 것은 무조건적인 자유도 아니고, 완벽한 통제도 아니라는 사실을요. 이 둘을 적재적소에 배치하는 '하이브리드 아키텍처'가 유일한 해답이었습니다.

우리가 도입한 하이브리드 전략의 핵심은 '의도 분류(Intent Classification)'와 '영역 분리'였습니다. 사용자의 질문이 들어오면 가장 먼저 가벼운 AI 모델이 이 질문의 성격을 파악합니다. 이것이 명확한 사실 확인이 필요한 영역인지, 아니면 공감이나 일반적인 정보 제공이 필요한 영역인지를 판단하는 것이죠.

예를 들어, "내 주문 배송 현황 알려줘"나 "비밀번호 변경 어떻게 해?" 같은 질문은 명확한 절차와 데이터가 필요합니다. 이런 질문은 LLM에게 넘기지 않고, 미리 정의된 규칙 기반 워크플로우로 연결합니다. DB에서 정확한 배송 상태를 조회해서 보여주거나, 비밀번호 변경 페이지로 안내하는 버튼을 띄워주는 식입니다. 여기엔 창의성이 개입할 여지가 없어야 합니다. 오로지 정확도만이 생명입니다.

반면 "이 제품이랑 저 제품 중에 뭐가 더 나아요?"라거나 "선물용으로 추천해 줄 수 있어?" 같은 맥락적이고 주관적인 질문은 생성형 AI의 영역입니다. 이때는 RAG(Retrieval-Augmented Generation)를 활용해 우리 회사의 제품 상세 정보를 참고 자료로 넘겨주고, LLM이 이를 바탕으로 자연스럽게 답변하도록 유도합니다.

이 구조를 도입하고 나서야 비로소 숨통이 트였습니다. 중요한 것은 기술 그 자체가 아니라, 기술이 적용될 '맥락'을 파악하는 것이었습니다. 개발자들은 흔히 최신 기술 스택을 도입하는 것에만 열광하곤 합니다. 저 또한 그랬습니다. 하지만 CTO로서 의사결정을 내릴 때는 "이 기술이 비즈니스 리스크를 얼마나 줄여주는가?"를 먼저 고민해야 합니다.

성공적인 하이브리드 챗봇을 설계하기 위해 개발팀과 기획팀이 반드시 점검해야 할 포인트들이 있습니다.

첫째, '실수하면 치명적인가?'를 자문해 보세요. 결제, 환불, 개인정보 조회와 같은 영역은 99%의 정확도도 부족합니다. 100%여야 합니다. 이런 기능은 타협 없이 규칙 기반으로 설계하세요. Function Calling 기능을 활용해 API를 직접 호출하고, 그 결과값만 건조하게 보여주는 것이 오히려 사용자 경험(UX) 측면에서 신뢰를 줍니다.

둘째, 'Router' 모델의 성능에 투자하세요. 하이브리드 구조에서 가장 중요한 건 사용자의 발화 의도를 초반에 얼마나 정확하게 분류하느냐입니다. 저희는 거대 모델 대신, 의도 분류에 특화된 작고 빠른 모델을 별도로 파인튜닝하여 레이턴시(Latency)를 줄이고 정확도를 높였습니다. 엉뚱한 길로 안내하는 내비게이션은 아무리 차가 좋아도 소용없으니까요.

셋째, AI의 답변을 검증하는 안전장치를 마련하세요. 생성형 모델이 답변을 생성한 후에도, 금칙어나 민감한 정보가 포함되었는지 확인하는 후처리 로직(Post-processing)이 필요합니다. "네, 고객님 계좌번호는..." 같은 말을 AI가 멋대로 뱉지 않도록 말이죠.

지금도 많은 기업이 AI챗봇 도입을 고민하며 두 가지 극단 사이에서 방황하고 있을 겁니다. 너무 딱딱해서 쓸모없는 챗봇을 만들거나, 너무 똑똑해서 거짓말까지 잘하는 챗봇을 만들거나요. 기술은 도구일 뿐입니다. 망치만 들고 있으면 모든 게 못으로 보인다는 말처럼, LLM이라는 거대한 망치만 쥐고 모든 문제를 해결하려 들지 마세요. 때로는 정밀한 드라이버 같은 규칙 기반 로직이 훨씬 효과적일 때가 있습니다.

결국 좋은 엔지니어링이란 화려한 기술의 나열이 아니라, 적절한 기술들의 조화로운 배치에서 나옵니다. 여러분이 만들고 있는 서비스가 사용자에게 신뢰를 주면서도 유연한 대화를 제공할 수 있도록, 이 하이브리드 전략이 작은 힌트가 되었으면 좋겠습니다. 기술의 파도 속에서 균형을 잡는 일, 그것이 우리 기술 리더들이 해야 할 진짜 역할이니까요.