챗봇 작성의 베스트 프랙티스 - 무엇이든 답하는 상자로 끝내지 않고, 업무에서 도움 되는 도선으로 만든다

이 글은 Web 사이트용 문의 챗봇, 사내 FAQ 봇, 1차 대응 봇을 만들 때의 일반론을 정리하는 것입니다. 먼저 결론을 말하면, 잘 되는 챗봇은 「모델의 똑똑함」보다 앞서 역할, 지식 소스, 권한, 인계 조건, 평가 방법이 정리되어 있습니다.

챗봇 이야기가 되면 무심코 「어느 모델을 사용할지」 「RAG로 할지」 「멀티 에이전트로 할지」부터 들어가기 쉽습니다. 하지만 실무에서 효과가 있는 순서는 조금 다릅니다.

먼저 정해야 할 것은 누구의, 어느 일을, 어디까지 줄일지입니다. 이 순서가 무너지면 대화는 그럴듯해도 문의에도 업무 효율에도 이어지지 않습니다.

기술계・B2B 사이트에서는 특히 이 경향이 강합니다. 가치가 있는 것은 잡담이 길게 이어지는 것이 아닙니다. 서비스 내용을 정확하게 안내하고, 필요하면 적절한 페이지나 담당자에게 연결하는 것입니다. 현재의 주요 개발 가이드에서도 본번 품질에서는 평가, 그라운딩, 가드레일, 인계를 따로따로 설계하는 전제가 강하게 나와 있습니다.¹²³⁴⁵⁶

1. 먼저 결론

꽤 거칠지만 실무에서 사용하기 쉬운 말로 하면 이렇습니다.

1. 챗봇은 처음에 용도를 1개 정하는 편이 강합니다.
2. 모델보다 앞서 무엇을 근거로 답할지를 정할 필요가 있습니다.
3. 출전을 낼 수 없는 답과 사람에게 건네야 할 답을 구분할 필요가 있습니다.
4. 고위험 처리일수록 권한과 확인 단계를 얇게 해서는 안 됩니다.
5. 본번 운용에서는 대화 로그와 평가 세트가 없으면 개선이 거의 감이 됩니다.
6. Web 사이트에 놓는다면 대화를 길게 이어가는 것보다 페이지 이해와 문의 도선을 돕는 것 쪽이 가치가 되기 쉽습니다.

챗봇은 잘 만들면 편리합니다. 다만, 무엇이든 답하는 종합 창구로서 너무 넓히면 정밀도, 운용, 책임 범위가 한 번에 무너집니다. 처음에는 좁게 만들고, 확실히 도움 되는 영역부터 넓히는 편이 결과적으로 빠릅니다.⁷

2. 먼저 전체상을 둔다

먼저 전체상입니다.

flowchart LR
    A[사용자 질문] --> B{대응 범위 내인가}
    B -->|Yes| C[지식 검색 / 툴 호출]
    B -->|No| H[문의 페이지 / 담당자 안내]
    C --> D{권한・안전 조건을 만족하는가}
    D -->|Yes| E[출전 포함 답변 + 다음 액션]
    D -->|No| F[사람에게 인계]
    E --> G[로그 / 평가 / 개선]
    F --> G
    H --> G

이 그림에서 중요한 것은 챗봇은 1개의 prompt가 아니라 도선, 지식, 권한, 평가를 포함하는 구조라는 점입니다. 질문에 답하는 것만으로 끝나는 것이 아니라 답하는 조건, 답하지 않는 조건, 다음에 무엇을 안내할지까지 포함해 설계할 필요가 있습니다.

현재의 주요 도구군도 이 사고방식으로 만들어져 있습니다. Google Cloud는 webhook이나 handoff rules, evaluation을 별도 기능으로 가지고, OpenAI는 model snapshot의 고정이나 evals를 본번 운용의 기본으로 안내하고 있습니다.¹²⁸³⁴ 즉, 프롬프트만으로 전부 해결하려고 하지 않는 것이 최초의 베스트 프랙티스입니다.

3. 처음에 정해야 할 것은 「누구의, 무엇의 일을 줄일지」

챗봇을 만들기 전에 우선 용도를 1개로 좁힙니다. 여기가 애매하면 평가 축도 지식 설계도 정해지지 않습니다.

용도를 대략 표로 하면 이렇습니다.

이 중에서 최초의 1개로서 만들기 쉬운 것은 대상이 좁고, 답의 정본을 정하기 쉬운 것입니다. 예를 들어,

• 제품 FAQ의 1차 답변
• 문의 전의 서비스 안내
• 사내 순서서의 검색

부근은 시작하기 쉽습니다.

반대로,

• 계약 판단
• 금액 확정
• 예외 승인
• 고객별 개별 조건이 강한 문의

와 같은 것은 처음부터 주전장으로 하지 않는 편이 안전합니다.

또한, 처음부터 multi-agent로 할 필요가 있는 케이스는 많지 않습니다. Microsoft도 single-agent는 구현을 단순하게 하고 운용 부하를 낮추며 예측하기 쉬운 실행 모델이 된다고 정리하고 있으며, 명확한 분리 이유가 없는 한 우선 single-agent로 검증하는 흐름을 권하고 있습니다.⁷

4. 대화 설계는 모델 선정보다 먼저

챗봇이 실패하기 쉬운 이유 중 하나는 대화의 입구와 출구가 정해져 있지 않은 것입니다. 「일단 자유 입력으로 뭐든지 괜찮습니다」로 하면 할 수 있는 것과 할 수 없는 것의 경계가 애매해집니다.

4.1 대화의 입구를 고정한다

최초의 메시지에서는 대응 범위를 먼저 보여주는 편이 안정됩니다. 예를 들어 Web 사이트용이라면,

• 대응 가능한 상담 내용
• 즉시 안내할 수 있는 페이지
• 상담 시에 필요한 최소 정보

를 처음에 내놓으면 대화의 흔들림이 줄어듭니다.

버튼이나 퀵 리플라이를 사용할 수 있다면,

• 요금을 알고 싶다
• 대응 가부를 알고 싶다
• 사례를 보고 싶다
• 문의하고 싶다

처럼 최초의 분기를 두면 자유 입력만보다 꽤 안정됩니다.

4.2 묻는 정보는 최소한으로 한다

사용자에게 질문할 항목은 답이나 라우팅을 바꾸는 것만으로 충분합니다. 물어보는 편이 좋을 것 같으니까로 항목을 늘리면 이탈이 늘어납니다.

예를 들어,

• 업종
• 상담 종별
• 기존 시스템의 유무
• 긴급도

가 다음의 안내를 바꾸면 묻는 의미가 있습니다. 반대로, 즉시 사용하지 않는 정보는 뒤로 돌리는 편이 좋습니다.

4.3 답변의 끝내는 법을 정한다

좋은 답변은 본문만으로 끝나지 않습니다.

1. 결론
2. 근거 또는 참조처
3. 다음에 취할 수 있는 행동

순으로 끝나면 대화가 업무에 접속하기 쉬워집니다.

특히 Web 사이트용에서는 대화 내에서 완결시키는 것보다,

• 해당 서비스 페이지로 진행한다
• 사례를 본다
• 문의 폼으로 진행한다

처럼 다음 한 걸음이 명확한 편이 가치가 됩니다.

4.4 고위험 이야기는 전용 경로로 나눈다

인증, PII, 금액, 계약, 예외 승인과 같은 고위험 영역은 통상의 안내 플로우와 같은 경로에 섞지 않는 편이 안전합니다. Google Cloud의 handoff rules에서도 고위험 요구는 특정 agent로 돌리는 예가 명시되어 있습니다.³

5. 지식 설계가 품질의 대반을 정한다

챗봇의 품질은 모델보다 지식으로 무너지기 쉽습니다. 답의 원본이 되는 정보가 애매하면 어느 모델에서도 안정되지 않습니다.

5.1 먼저 「무엇을 정본으로 할지」를 정한다

최저한 다음은 정해 두고 싶습니다.

• 어느 문서나 페이지를 정본으로 할지
• 누가 업데이트 책임자인가
• 어느 빈도로 업데이트되는가
• 언제 오래된 정보를 버릴지

여기가 없으면 봇은 오래된 정보와 새로운 정보를 동시에 주워 옵니다. 그리고 그 부정합은 꽤 높은 확률로 사용자에게 보입니다.

5.2 페이지 단위가 아니라 의미 단위로 자른다

RAG에서 자주 있는 실패는 PDF나 페이지를 그대로 쑤셔 넣고 끝내는 것입니다. 실제로는,

• 1개의 제도 설명
• 1개의 순서
• 1개의 FAQ
• 1개의 주의사항

처럼 의미의 덩어리로 다루는 편이 답변이 안정됩니다.

Microsoft는 RAG 품질이 콘텐츠 준비에 의존한다고 하고, chunking, vectorization, hybrid search, semantic ranking을 기본선으로서 안내하고 있습니다.⁵ OpenAI의 file search에서도 쿼리 재작성, 복수 검색, keyword + semantic search, reranking을 전제로 하고 있습니다.⁹ 즉 베스트 프랙티스는 「문서를 넣는 것」이 아니라 「문서를 검색 가능한 지식으로 변환하는 것」입니다.

5.3 출전과 업데이트 날짜를 보여준다

사용자가 안심할 수 있는 것은 잘 말하는 봇이 아닙니다. 근거를 따라갈 수 있는 봇입니다.

• 어느 페이지를 보고 답했는가
• 어느 문서의 어느 항목인가
• 언제 업데이트된 정보인가

를 보여줄 수 있는 설계로 해 두면, 오답 시의 조사도 쉬워집니다.

OpenAI의 web search는 출전 포함 답변을 반환하는 전제로 설계되어 있으며, Microsoft Copilot Studio도 grounded, cited responses를 안내하고 있습니다.¹⁰¹¹ 사이트 내나 사내 문서에서 답하는 경우도, 이 「근거를 따라갈 수 있는」 상태를 목표로 하는 편이 운용하기 쉽습니다.

5.4 최신 정보는 외부 검색으로 나눈다

신선도가 중요한 테마는 고정 지식만으로 답하지 않는 편이 좋습니다.

예를 들어,

• 영업일
• 가격 개정
• 채용 정보
• 장해 정보
• 법 개정이나 제도 변경

과 같은 것입니다.

이 종류의 질문은 업데이트원의 사이트나 API를 별도 경로로 참조하거나, 명시적으로 「최신 정보는 이 페이지를 확인해 주세요」라고 반환하는 편이 안전합니다. 공개 사이트를 지식 소스로 사용하는 경우도, 어느 도메인을 신뢰할지를 먼저 좁혀야 합니다. Copilot Studio도 구성된 도메인에 좁힌 검색과 citations, relevance check를 전제로 하고 있습니다.¹¹

6. 프롬프트는 장문의 인격 설정보다 짧은 운용 규칙

챗봇의 prompt에서 정말로 효과 있는 것은 긴 인격 설정보다 짧고 명확한 운용 규칙입니다.

최저한 다음 4층으로 나누면 정리하기 쉽습니다.

1. 역할
2. 참조해도 좋은 지식과 도구
3. 답해도 좋은 조건 / 인계하는 조건
4. 답변 형식

예를 들어 역할은 「문의 전의 안내를 한다」 「사내 순서를 안내한다」처럼 짧게 쓸 수 있습니다. 답변 형식도 「결론 → 근거 → 다음 액션」으로 충분합니다.

반대로 약한 prompt는 다음과 같이 되기 쉽습니다.

• 인격 설정만 길다
• 답의 근거가 애매
• 도구를 사용하는 조건이 불명
• 인계 조건이 쓰여 있지 않다

6.1 구조화된 출력을 사용한다

주문 상황, 예약 슬롯, 문의 분류처럼 후단의 처리로 연결하는 장면에서는 자유문만으로 하지 않는 편이 안전합니다. OpenAI에서도 Structured Outputs를 사용한 JSON 반환을 안내하고 있습니다.¹

사람에게 보여주는 문장과 기계가 받는 값은 나누는 편이 좋습니다. 예를 들어,

• 표시문: 사용자에게 보여주는 설명
• intent: 문의 종별
• confidence: 판정 확도
• next_action: 다음의 도선

처럼 나누는 것만으로도 운용이 안정됩니다.

6.2 model version을 고정하고, 평가하고 나서 바꾼다

본번계에서는 「어제와 오늘 조금 답하는 법이 다르다」가 사고가 됩니다. OpenAI는 production applications에서 model snapshot을 pin하고, prompt의 behavior를 측정하는 evals를 만들 것을 권하고 있습니다.¹ 또, 최적화는 evals → prompt engineering → fine-tuning의 지속 루프로 진행하는 전제가 명시되어 있습니다.²

6.3 일별로 model을 나눈다

전부를 1개의 model에 짊어지게 할 필요도 없습니다. OpenAI도 저 레이턴시로 명확한 처리는 GPT계, 복잡하고 애매함이 높은 판단은 reasoning계, 라는 구분 사용을 안내하고 있습니다.¹²

실무에서는,

• FAQ 답변이나 분류는 가벼운 model
• 예외 판정이나 복잡한 요약은 reasoning model
• 고위험 판단은 인간

처럼 나누면 비용과 품질 양쪽이 안정되기 쉽습니다.

7. 안전 설계는 「위험한 질문을 튕기는」 것만으로는 부족

안전 설계라고 하면 유해 질문의 블록만을 상상하기 쉽습니다. 하지만 실무에서 중요한 것은 그것뿐만이 아닙니다.

7.1 prompt injection을 전제로 한다

LLM계의 봇에서는 prompt injection을 전제로 하는 편이 좋습니다. Microsoft는 direct와 indirect의 2종류로 정리하고 있으며, 외부 사이트나 파일 속에 심어진 hidden instruction에 의해 session이 탈취될 가능성도 나타내고 있습니다.⁶¹³

즉, 외부 문서나 Web 페이지를 읽게 하는 봇에서는,

• 외부 콘텐츠를 system instruction과 동렬로 다루지 않는다
• 도구 실행 권한을 최소화한다
• 고위험 처리 전에 확인을 넣는다

가 필요합니다.

7.2 권한은 최소화한다

「읽을 수 있는 자료는 전부 읽을 수 있다」 「실행할 수 있는 조작은 전부 실행할 수 있다」는 위험합니다. Microsoft의 security guidance에서도 least privilege와 외부 콘텐츠의 영향 분리가 중요하다고 정리되어 있습니다.⁶

사내 봇이라면 특히,

• 부서별 열람 권한
• 고객별 정보 분리
• 개인 정보를 포함하는 문서의 제외

를 먼저 정할 필요가 있습니다.

7.3 개인 정보와 인증은 별도 레이어로 다룬다

「봇이 좋은 느낌으로 마스크해 줄 것」이라고 생각하지 않는 편이 안전합니다. Microsoft의 public website grounding의 설명에서도, 사용자가 입력한 personal data는 자동으로 scrub / mask되는 것이 아니라는 것이 명기되어 있습니다.¹¹

개인 정보나 고객 고유 데이터를 다룬다면,

• 인증은 앱 측에서 한다
• 취득할 수 있는 정보를 좁힌다
• 감사 로그를 남긴다
• 답변 전에 본인 확인 조건을 만족한다

라는 설계가 필요합니다.

7.4 안전은 개발의 마지막이 아니라 처음부터 돌린다

NIST의 Generative AI Profile도, 리스크는 설계, 개발, 이용, 평가의 각 단계에서 관리하는 전제를 두고 있습니다.¹⁴ 즉 안전 설계는 릴리스 전의 최후의 체크 항목이 아닙니다. 처음부터 사양에 넣어야 하는 것입니다.

8. 사람에게 건네는 조건을 처음부터 정한다

「모르면 담당자에게 인계합니다」라고 1문만 쓰고 끝나는 설계는 약합니다. 실제로는 어떤 조건에서 어디로 무엇을 첨부해서 건넬지까지 정할 필요가 있습니다.

예를 들어 다음 조건은 처음부터 두기 쉽습니다.

• 인증이 필요한 질문
• 계약이나 금액의 확정이 필요한 질문
• 출전을 낼 수 없는 질문
• 2회 이상 잘 안내할 수 없었던 질문
• 고정이나 긴급성이 높은 상담
• 법무, 노무, 의료 등 고위험 영역의 상담

Google Cloud의 handoff rules에서는 instruction 기반의 handoff보다 deterministic한 제어를 사용할 수 있는 것이 명시되어 있습니다.³ 고위험 영역일수록 「아마 건넨다」가 아니라 「이 조건이라면 반드시 건넨다」 쪽이 운용하기 쉽습니다.

인계 시에 사람에게 건네야 할 정보도 먼저 정해 두면 편합니다.

• 여기까지의 대화 이력
• 취득한 항목
• 참조한 페이지나 문서
• 봇이 막힌 이유
• 다음에 확인해 주었으면 하는 점

이 5가지가 갖춰지는 것만으로도 인계 후의 수 되돌림이 꽤 줄어듭니다.

9. 평가 없는 개선은 거의 운에 맡기는 것

챗봇 개선에서 가장 위험한 것은 대화를 몇 건 보고 「꽤 좋아진 것 같다」로 진행하는 것입니다. 이것이면 prompt를 만질 때마다 다른 부분이 망가집니다.

OpenAI는 먼저 evals를 쓰고 실운용에 가까운 입력으로 돌릴 것을 권하고 있습니다.² 즉 개선의 출발점은 prompt가 아니라 평가 세트입니다.

9.1 최저한 원하는 지표

Google Cloud의 CX Agent Studio에서도 user goal satisfaction, tool correctness, hallucinations 등이 평가 지표로서 정리되어 있습니다.⁴ 이 사고방식은 어느 구현에서도 꽤 유용할 수 있습니다.

9.2 개선은 비장의 무기가 아니라 루프로 돌린다

개선의 순서는 대체로 다음으로 충분합니다.

flowchart LR
    A[평가 세트를 만든다] --> B[현상 prompt / model을 계측]
    B --> C[실패 예를 분류]
    C --> D[지식 / prompt / routing / handoff를 수정]
    D --> E[재평가]
    E --> F[본번 감시]
    F --> A

이 루프가 없으면 개선은 개인의 감에 의존합니다. 반대로 이 루프가 있으면 「무엇이 좋아지고, 무엇이 나빠졌는지」를 쫓기 쉬워집니다.

10. Web 사이트에 놓는다면 문의 도선과 일체로 설계한다

기업 사이트에 놓는 챗봇은 채팅 그 자체가 주역이라고는 한정되지 않습니다. 많은 경우는,

• 무엇의 회사인지를 전한다
• 어느 서비스 페이지를 봐야 할지를 안내한다
• 사례나 FAQ를 보여준다
• 문의 전의 불안을 줄인다

를 위한 보조선으로서 설계하는 편이 자연스럽습니다.

특히 기술계・B2B 사이트에서는 서비스 설명이 복잡합니다. 그래서 채팅으로 전부를 다 말하기보다 적절한 페이지로 안내하는 편이 강한 장면이 많습니다.

예를 들어 다음 흐름은 꽤 상성이 좋습니다.

1. 상담 종별을 확인한다
2. 해당 서비스 페이지를 안내한다
3. 필요하면 관련 사례나 FAQ를 낸다
4. 아직 불명점이 있으면 최소한만 묻는다
5. 문의 폼으로 연결한다

이 형태라면 채팅은 영업이나 문의 도선의 보조가 됩니다. 반대로 페이지 도선과 분리해서 놓으면 「말할 수 있지만 앞으로 나아가지 않는 상자」가 되기 쉽습니다.

11. 90일로 토대를 만드는 진행 방식

크게 시작할 필요는 없습니다. 90일로 토대를 만든다면 다음 순이 현실적입니다.

0-2주: 용도와 정본을 정한다

• 무엇의 문의를 줄이고 싶은지 정한다
• 대상 사용자를 정한다
• 정본 문서와 업데이트 책임자를 정한다
• 사람에게 건네는 조건을 정한다

3-6주: 작게 시제한다

• 주요 시나리오만으로 prototype을 만든다
• 입구 메시지와 분기를 만든다
• 출전 포함 답변을 반환할 수 있도록 한다
• 평가 세트를 20~50 케이스 만든다

7-10주: 파일럿에서 다듬는다

• 실사용자의 로그를 본다
• 막히는 질문을 분류한다
• prompt보다 먼저 지식과 routing을 고친다
• 잘 되지 않는 영역은 인계 조건을 강화한다

11-12주: 본번 운용의 형을 정한다

• 주차에 보는 지표를 정한다
• prompt / model version을 고정 관리한다
• 업데이트 플로우와 책임자를 정한다
• 2개째의 용도로 넓힐지 판단한다

이 순으로 진행하면 처음부터 크게 만들어 무너질 확률을 낮출 수 있습니다.

12. 자주 있는 실패

마지막으로 꽤 자주 있는 실패를 정리합니다.

12.1 무엇이든 답하는 종합 창구로 만든다

처음부터 스코프를 너무 넓히면 정밀도도 책임 범위도 애매해집니다. 용도를 1개로 좁히는 편이 강합니다.

12.2 정본과 업데이트 책임자가 없다

RAG의 구조가 있어도 원 정보가 정리되어 있지 않으면 안정되지 않습니다. 지식 운용은 별도 일입니다.

12.3 출전 없이 단정한다

그럴듯한 답은 운용에서 가장 위험합니다. 근거를 따라갈 수 없는 답변은 나중에 고치기 어렵습니다.

12.4 고위험 처리를 갑자기 실행시킨다

송금, 계약 갱신, 개인 정보 참조와 같은 조작은 확인이나 사람의 승인을 빼서는 안 됩니다.

12.5 사람에게 인계가 애매

「필요에 따라 담당자에게」라고만 쓰여 있으면 현장에서는 막힙니다. 조건, 수신처, 첨부 정보까지 정할 필요가 있습니다.

12.6 평가 세트가 없다

개선 때마다 좋아졌는지 나빠졌는지 모르게 됩니다. 이것은 꽤 많습니다.

12.7 처음부터 multi-agent로 한다

agent를 늘리면 설계 자유도는 올라갑니다. 다만 동시에 latency, 상태 관리, 감시, 디버그, 권한 관리도 무거워집니다. 필요한 분리 이유가 없는 한 우선 1개로 시도하는 편이 안전합니다.⁷

13. 정리

챗봇 작성의 베스트 프랙티스를 한마디로 말하면, 모델 선정보다 앞서 역할, 지식, 권한, 인계, 평가를 정할 것입니다.

특히 중요한 것은 다음 5점입니다.

• 용도를 1개로 좁힌다
• 정본과 출전을 정한다
• 고위험 영역을 나눈다
• 사람에게 건네는 조건을 명문화한다
• 실운용에 가까운 평가를 돌린다

Web 사이트용이든 사내용이든 이 순서는 꽤 공통입니다. 챗봇을 「잘 말하는 것」으로서가 아니라 「업무의 어디를 짧게 하고, 어디서 사람에게 연결할지를 정리하는 것」으로서 설계하면 실패하기 어려워집니다.

관련 기사

• 기업의 홈페이지는 왜 만들어야 하는가 - 회사 안내로 끝내지 않고 이익으로 이어가는 사고방식
• 기사와 서비스 페이지를 어떻게 연결할까 - 내부 링크 설계의 기본
• 서비스 페이지를 어떻게 만들까 - 기술계・B2B용의 정리 순서
• 문의가 오지 않는 사이트에서 먼저 고쳐야 할 3곳
• SEO 대책과 Google 광고의 베스트 프랙티스 - 일반론으로 잡는 검색 집객의 설계도

참고 자료

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.