RAG를 사용하지 않고 Claude Haiku 4.5로 FAQ 챗봇을 만든 이유

회계사 사무소(士業事務所) 대상의 생성형 AI 도입 지원을 가정하여, FAQ 자동 응답 챗봇을 만들었습니다. 결론부터 말하자면, FAQ가 15건 정도라면 RAG는 필요하지 않습니다. 시스템 프롬프트에 전체 내용을 삽입하는 것만으로도 정확도와 비용 면에서 충분했습니다. 본 기사에서는 RAG를 선택하지 않은 이유와 실제로 어떤 기준으로 판단을 내렸는지 정리합니다.

대상 독자는 생성형 AI를 활용한 문의 응대 시스템 구축을 검토하는 분들, 특히 'RAG를 구현해야 할지 고민하는' 단계에 있는 분들입니다.

무엇을 만들었나

가상의 세무사 사무소를 가정한 문의 창구입니다.

• 챗 UI에서 자주 묻는 질문(FAQ)을 자연스러운 대화 형식으로 들을 수 있습니다.

• 수록된 15건의 FAQ를 기반으로 AI가 답변을 생성합니다.

• FAQ에 없는 개별적이고 구체적인 질문(세액 계산 등)에는 답하지 않고, 담당자에게 연결하도록 안내합니다.

• 수록된 FAQ는 화면에서도 목록으로 표시할 수 있습니다.

• 기술 스택은 다음과 같습니다:

Next.js 16 (App Router), TypeScript, Tailwind CSS v4, **Anthropic API (Claude Haiku 4.5)**입니다.

• 왜 만들었나

생성형 AI의 업무 도입 지원은 실적이 없으면 신뢰받기 어려운 영역이라고 생각합니다. 그래서 영업을 하기 전에, 작더라도 작동하는 시제품(PoC)을 하나 만들었습니다. 전문직 사무소를 선택한 이유는 '문의 응대 1차 창구'라는 업무가 모든 사무소에 존재하며, 게다가 '잘못된 답변을 해서는 안 된다'는 제약이 명확하게 적용되기 때문입니다.

구성

チャットUI (src/app/page.tsx)
│ fetch('/api/chat')
▼
...

FAQ 15건을 그대로 시스템 프롬프트에 삽입하는, 상당히 단순한 구조입니다. 벡터 검색이나 DB는 사용하지 않았습니다.

판단 ①: 왜 RAG를 사용하지 않았나

생성형 AI로 검색 기능을 구현하려고 하면 무의식적으로 RAG(임베딩으로 벡터 검색을 수행하고 관련 문서만 프롬프트에 전달하는 구성)를 적용하고 싶어집니다. 이번에는 그렇게 하지 않았습니다.

이유는 간단합니다. FAQ가 15건밖에 없기 때문입니다. 건당 수십~수백 자로 계산해도, 전부 합쳐도 많아야 몇 천 자 정도입니다. Claude의 컨텍스트 윈도우(context window) 기준으로 보면 오차 범위 내이며, 매번 전체 내용을 전달해도 속도나 비용에 거의 변화가 없습니다.

반면 RAG를 구현하려면 임베딩 모델 선정, 벡터 DB 준비, 검색 정확도 튜닝 등 별도의 비용이 추가됩니다. FAQ가 15건 정도일 때 이를 적용하는 것은 명백히 과잉 장비(over-equipped)입니다.

기준을 세우자면 'FAQ 전체를 프롬프트에 매번 넣어도 실용적으로 문제가 없는 건수'라고 생각합니다. 이번 경우는 수십~수백 건 정도가 그 경계선이 될 것 같으며, 사무소 측에서 FAQ를 늘려 토큰 수가 명확하게 증가할 경우 RAG 구성으로 전환하는 순서를 정했습니다.

판단 ②: 잘못된 세무 자문을 내지 않기 위한 제어

전문직 대상 챗봇에서 가장 무서운 것은 AI가 그럴듯한 세무 개별 자문을 해버리는 것입니다. 시스템 프롬프트의 답변 규칙은 다음과 같습니다:

- FAQ에 기재된 내용은 그것을 바탕으로 자연스러운 문장으로 답변한다.
- FAQ에 없는 질문(개별 세액 계산, 구체적인 수치 시뮬레이션 등)에는 정확한 답변이 불가능함을 전달하고, '담당자에게 연락드리겠습니다'와 같이 안내한다.

핵심은 '모르는 것을 물었을 때 답하지 않는다'가 아니라, **'FAQ 범위를 벗어난 것은 개별 구체적인 이야기로 취급하여 반드시 사람에게 넘긴다'**고 명시한 것입니다. 사무소에 따라서는 '일반적인 제도 설명이라면 AI에게 맡겨도 되지만, 개별 금액 이야기는 반드시 사람이 확인해야 한다'는 경계가 있을 것이므로, 이 부분을 프롬프트 측에서 고정했습니다.

판단 ③: 왜 Haiku 4.5인가

FAQ 답변은 복잡한 추론이 필요한 작업이 아닙니다. '전달된 FAQ 중에서 비슷한 것을 찾아 자연스러운 문장으로 만드는 것'이 거의 전부입니다. 여기에 상위 모델을 사용할 이유가 없으므로, 응답 속도와 비용을 우선하여 Haiku 4.5를 사용했습니다.

문의 창구는 '바로 돌아온다' 자체가 가치이기 때문에, 어느 정도의 지능보다는 속도를 택하는 판단입니다. 반면 사무소 측의 업무 흐름 정리나 복잡한 요건 청취 AI를 만든다면, 여기서는 상위 모델로 변경할 것이라고 생각합니다.

어려웠던 점

솔직히 이번에는 크게 막힌 부분은 없었습니다. 구성이 단순해서(UI에서 호출하는 API가 1개, 외부 의존성은 Anthropic API만) 스코프도 'FAQ에 답한다/답하지 않는다'의 두 가지 선택지로 한정했기 때문에, 예상치 못한 문제에 부딪힐 여지 자체가 적었던 것 같습니다. 복잡한 것을 하려고 하면 막히지만, 이번에는 일부러 그렇게 하지 않았다는 것이 실태에 가깝습니다.

한계점과 다음 계획

현재 구성에는 명확한 한계가 있습니다.

• FAQ를 추가하거나 수정할 때마다 코드를 고치고 재배포해야 한다(비엔지니어 사무실 직원이 업데이트할 수 없음)
• FAQ가 수백 건 규모로 늘어나면, 매번 전체 내용을 임베딩하는 구성은 토큰 비용이 무시할 수 없게 된다
• 사무소별로 FAQ 세트를 분리하고 싶을 경우(다중 클라이언트 대응)는 현재의 '사무소당 1개 코드' 구성으로는 처리하기 어렵다
  다음으로 진행한다면, FAQ를 코드에서 분리하여 데이터베이스화하고, 건수가 늘어난 단계에서 embedding 기반의 RAG 구성으로 전환할 계획입니다. 아울러, 사무실 직원이 직접 FAQ를 편집할 수 있는 관리 화면도 필요할 것 같습니다.

요약

FAQ가 수십 건 규모라면, RAG를 구축하지 않고 시스템 프롬프트에 직접 임베딩하는 것으로 충분하다는 것이 이번 결론입니다. 판단의 기준은 'FAQ 전체 내용을 매번 전달해도 실용적으로 문제가 없는가'이며, 규모가 커지면 RAG 구성으로 전환을 검토하겠다는 순서로 잡았습니다.
마찬가지로 'AI 도입은 좋아 보이는데, 어디까지 구현해야 할까'에서 고민하는 분들께 도움이 되었으면 좋겠습니다. 판단이 갈릴 것 같은 부분이 있다면 댓글로 알려주세요.
소스 코드 공개는 검토 중입니다 (민감 정보는 포함되어 있지 않습니다).