회사 홈페이지에 AI 상담 챗봇, 붙일 만한가 — 도입 전에 계산할 네 가지

초록

"우리 홈페이지에도 AI 상담 챗봇을 붙이고 싶다"는 요청이 부쩍 늘었습니다. 그런데 이 요청은 대부분 기술 선택 문제로 들어와서 자료 문제로 끝납니다. 챗봇이 회사 자료를 근거로 답하려면 그 자료가 문장으로 존재해야 하는데, 상당수 회사에서 그 자료는 담당자 머릿속과 카카오톡 대화와 이미지 PDF에 흩어져 있습니다. 이 글은 도입 판단을 네 개의 계산으로 나눕니다. 첫째, 우리 자료가 답변 가능한 상태인가. 둘째, 구축비와 별개로 매달 얼마가 나가는가. 셋째, 틀리게 답했을 때 누가 책임지고 그 위험을 어떻게 줄이는가. 넷째, 챗봇 말고 더 싼 해법이 같은 문제를 푸는가. 각 계산의 판정 기준과 흔한 실패 양상을 정리하고, 마지막에 도입을 권하는 조건과 말리는 조건을 명시합니다. 특정 솔루션의 우열은 다루지 않습니다.

1. 서론

챗봇 요청은 대개 이런 문장으로 옵니다.

"요즘 다들 하니까 우리도 하나 있어야 할 것 같아요."

이 문장 자체는 문제가 아닙니다. 문제는 이 요청 뒤에 무엇을 해결하려는지가 비어 있다는 점입니다. 그래서 견적을 내려고 하면 첫 질문에서 막힙니다. "챗봇이 어떤 질문에 답해야 합니까?"

답이 안 나오는 경우가 절반쯤 됩니다. 그리고 답이 안 나오는 상태에서 만든 챗봇이 어떻게 되는지는 예측 가능합니다. 열어 놓고 3개월쯤 지나면 아무도 안 쓰고, 6개월쯤 지나면 잘못된 답을 했다는 문의가 한 번 들어오고, 그 뒤 조용히 내립니다.

반대로 잘 되는 경우도 분명히 있습니다. 차이는 모델이 아니라 준비 상태에서 갈립니다. 이 글은 그 준비 상태를 네 가지로 나눠 계산해 보는 절차입니다.

먼저 용어 하나만 정리하겠습니다.

2. 우리가 말하는 챗봇이 어떤 종류인가

"AI 챗봇"이라는 한 단어 안에 성격이 아주 다른 세 가지가 들어 있습니다. 견적이 열 배 차이 나는 이유가 여기 있습니다.

유형 1 — 시나리오형 (규칙 기반)

버튼을 눌러 가며 정해진 길을 따라가는 방식입니다. "배송 조회 → 주문번호 입력 → 결과 표시". 엄밀히 말하면 AI가 아니지만 사용자에게는 챗봇으로 보입니다.

장점: 절대 틀린 말을 하지 않습니다. 비용이 낮고 예측 가능합니다.
단점: 예상하지 못한 질문에 아무것도 못 합니다.
적합: 질문 종류가 열 개 미만이고 대부분 조회성일 때.

유형 2 — 문서 기반 응답형 (RAG)

회사 문서를 미리 넣어 두고, 질문이 오면 관련 문서 조각을 찾아 그걸 근거로 문장을 만들어 답하는 방식입니다. 요즘 "AI 챗봇"이라고 하면 대개 이걸 가리킵니다. 구조는 RAG의 기본 개념에서 다룬 것과 같습니다.

장점: 문서에 있는 내용이면 자유로운 질문에 답합니다. 근거 문서를 함께 보여 줄 수 있습니다.
단점: 문서가 없으면 아무것도 못 합니다. 문서가 틀렸으면 틀리게 답합니다.
적합: 제품 사양, 정책, 절차처럼 문서화된 정보를 자주 묻는 경우.

유형 3 — 업무 수행형 (에이전트)

답만 하는 게 아니라 실제로 뭔가를 하는 방식입니다. 재고를 조회하고, 예약을 잡고, 견적서를 만들고, 티켓을 생성합니다. 사내 시스템과 연동이 필요합니다.

장점: 실제 업무 시간을 줄입니다.
단점: 연동 비용이 본체보다 큽니다. 잘못 실행했을 때의 피해가 잘못 답했을 때보다 큽니다. 권한 설계가 필수입니다.
적합: 반복 업무량이 확실히 크고, 연동할 시스템에 API가 있을 때.

대부분의 기업 홈페이지가 실제로 필요한 것은 유형 2입니다. 그리고 요청은 유형 3의 기대치로 들어옵니다. 이 간극을 먼저 좁혀야 견적이 성립합니다.

이 글의 나머지는 유형 2를 기준으로 씁니다.

3. 계산 하나 — 우리 자료는 답변 가능한 상태인가

가장 중요한 계산입니다. 그리고 가장 자주 건너뜁니다.

RAG는 마술이 아닙니다. 넣어 준 문서 안에 답이 문장으로 있어야 답합니다. 없으면 모릅니다고 하거나, 더 나쁘게는 그럴듯하게 지어냅니다.

그래서 도입 전에 해 볼 일이 있습니다. 30분이면 됩니다.

3-1. 30분 판정 절차

1단계. 고객센터나 영업 담당자에게 최근 한 달간 실제로 받은 질문 20개를 적어 달라고 합니다. 가정하지 말고 실제로 받은 것으로.

2단계. 각 질문 옆에 "이 답이 문서로 어디에 있는가"를 적습니다. 홈페이지 어느 페이지, 어느 PDF 몇 쪽, 어느 엑셀 파일.

3단계. 세 칸으로 분류합니다.

분류	뜻
A	문서에 문장으로 있음
B	문서에 있긴 한데 이미지·표 캡처·손으로 그린 도면 안에 있음
C	문서에 없음. 담당자가 그때그때 판단함

판정은 이렇습니다.

A가 15개 이상 → 지금 도입해도 됩니다. 첫날부터 쓸 만합니다.
A가 8~14개 → 문서 정리를 선행하면 됩니다. 대개 2~4주 작업이고, 이건 챗봇 비용이 아니라 별도 작업입니다.
A가 7개 이하 → 지금 챗봇을 붙이면 실패합니다. 순서를 바꿔야 합니다.

세 번째 경우가 생각보다 많습니다. 그리고 이 경우 챗봇 업체는 대개 "저희가 문서화도 도와드립니다"라고 합니다. 도와줄 수는 있지만, 회사가 판단 기준을 갖고 있지 않은 것을 외부가 대신 만들어 줄 수는 없습니다. C 항목이 많다는 것은 그 회사의 답이 상황마다 다르다는 뜻이고, 그건 문서화의 문제가 아니라 정책의 문제입니다.

3-2. B 항목의 함정

B — 이미지 안에 있는 정보 — 는 특히 주의해야 합니다. 제조업·건설업·의료기기처럼 사양표와 도면이 많은 업종에서 흔한데, 이런 자료는 그대로 넣으면 검색되지 않습니다.

선택지는 셋입니다.

텍스트로 옮긴다 — 정확하지만 사람 손이 듭니다. 사양표 100장이면 그만큼 시간이 듭니다.
자동 인식(OCR·문서 파싱)을 쓴다 — 빠르지만 표 구조가 복잡하면 값이 어긋납니다. 어긋난 사양표는 없는 것보다 위험합니다.
그 영역은 챗봇 범위에서 뺀다 — "사양은 담당자 연결" 로 넘깁니다. 가장 자주 채택되는 현실적 답입니다.

3번을 택하는 것이 실패가 아닙니다. 챗봇의 범위를 정하는 것이 설계의 일부입니다.

3-3. 문서가 최신인가

또 하나. 문서가 있어도 낡았으면 낡은 답을 합니다. 그리고 챗봇은 사람과 달리 "이건 예전 자료라 지금은 다를 텐데요"라고 덧붙이지 않습니다. 자신 있게 옛 가격을 말합니다.

도입 전에 넣을 문서 목록을 뽑고, 각각 최종 수정일을 적어 보십시오. 2년 이상 손대지 않은 문서가 절반을 넘으면, 챗봇은 그 낡음을 증폭해서 고객에게 전달하는 장치가 됩니다.

4. 계산 둘 — 매달 얼마가 나가는가

챗봇 견적에서 구축비만 보면 판단이 어긋납니다. 이건 만들고 끝나는 물건이 아니라 켜 두는 동안 계속 돈이 나가는 물건입니다.

반복 비용은 네 갈래로 나뉩니다.

4-1. 모델 호출 비용

질문 한 번에 얼마씩 나갑니다. 계산 구조는 이렇습니다.

월 비용 ≈ 월 질문 수 × 질문당 평균 토큰 × 단가

여기서 "질문당 평균 토큰"이 함정입니다. 사용자가 입력한 짧은 문장만 들어가는 게 아니라, 찾아온 문서 조각이 통째로 함께 들어갑니다. 그래서 실제 입력량은 사용자 질문의 수십 배가 됩니다. 대화가 이어지면 앞의 대화도 함께 들어가므로 더 늘어납니다.

대략의 감을 잡는 예시입니다. (단가는 모델·시점에 따라 달라지므로 구조를 보는 용도로만 쓰십시오.)

항목	가정
월 질문 수	1,000건
질문당 입력	사용자 질문 100 + 문서 조각 4,000 + 대화 이력 900 ≈ 5,000 토큰
질문당 출력	400 토큰

질문 수가 열 배가 되면 이 항목은 거의 정확히 열 배가 됩니다. 트래픽에 비례하는 유일한 항목이므로, 홍보를 크게 해서 방문자가 급증하는 상황을 함께 고려해야 합니다.

줄이는 방법은 있습니다. 문서 조각을 덜 넣거나(정확도와 맞바꿈), 대화 이력을 짧게 자르거나, 자주 나오는 질문은 캐시로 처리하거나, 간단한 질문은 작은 모델로 보내는 방식입니다. 다만 이건 최적화이고, 처음부터 할 일은 아닙니다.

4-2. 검색 인프라 비용

문서를 저장하고 찾는 쪽입니다. 벡터 DB나 검색 엔진을 별도 서비스로 쓰면 월 고정비가 붙고, 직접 운영하면 서버 비용과 관리 시간이 붙습니다.

문서 양이 수천 건 수준이면 이 비용은 크지 않습니다. 수십만 건 이상으로 가면 여기가 주 비용이 됩니다.

4-3. 문서 갱신 비용

가장 자주 누락되는 항목입니다.

가격이 바뀌었을 때, 제품이 단종됐을 때, 정책이 변경됐을 때 누가 챗봇의 문서를 갱신합니까? 이 질문에 이름이 안 나오면 챗봇은 6개월 안에 틀린 말을 하기 시작합니다.

현실적인 형태는 둘 중 하나입니다.

자동 동기화 — 홈페이지나 사내 문서 시스템이 원본이고, 바뀌면 자동으로 반영됩니다. 초기 구축비가 더 들지만 운영이 안정적입니다. 가능하면 이쪽입니다.
수동 갱신 — 담당자가 관리 화면에서 올립니다. 싸지만, 담당자가 바뀌면 끊깁니다.

수동을 택한다면 월 담당 시간을 견적에 명시적으로 넣으십시오. 월 2시간이라도 숫자로 적어 두면 담당자가 정해집니다.

4-4. 개선 비용

열고 나면 반드시 나옵니다. 답이 이상한 질문, 아예 못 알아듣는 표현, 엉뚱한 문서를 물고 오는 경우. 이걸 보고 고치는 작업이 초기 3개월에 몰립니다.

이 기간의 대응을 계약에 넣어 두지 않으면, 열자마자 "추가 개발"로 청구되거나 아니면 방치됩니다. 구축 후 3개월 튜닝을 범위에 포함시키는 편이 양쪽에 낫습니다.

4-5. 정리

항목	성격	트래픽 비례
모델 호출	종량	○
검색 인프라	고정 또는 문서량 비례	△
문서 갱신	사람 시간	×
개선·튜닝	초기 집중 후 감소	△

이 표를 견적서 옆에 놓고, 각 칸에 숫자와 담당자가 들어가는지 확인하십시오. 빈칸이 있으면 그 항목은 나중에 논쟁이 됩니다. 3년 관점에서 이런 반복 비용이 어떻게 누적되는지는 외주 개발의 총소유비용에서 다룬 구조와 같습니다.

5. 계산 셋 — 틀리게 답했을 때

이 부분을 안 정하고 여는 회사가 많습니다. 그리고 이건 기술 문제가 아니라 회사가 감수할 위험의 문제라서, 업체가 대신 정해 줄 수 없습니다.

5-1. 무엇이 문제인가

챗봇은 모르는 것을 모른다고 하지 않을 때가 있습니다. 문서에 없는 값을, 문서에 있는 다른 값들을 참고해 그럴듯하게 만들어 냅니다. 사용자 입장에서는 회사가 공식적으로 답한 것으로 읽힙니다.

위험의 크기는 업종에 따라 크게 다릅니다.

상황	위험
영업시간을 틀리게 답함	낮음. 사과하고 정정
제품 사양을 틀리게 답함	중간. 오발주·반품
가격·할인 조건을 틀리게 답함	중간~높음. 이행 요구 가능
의료·법률·금융 관련 답변	높음. 규제 영역
안전 관련 사용법을 틀리게 답함	매우 높음

아래 두 줄에 해당한다면 자유 응답형 챗봇을 공개 페이지에 두는 것 자체를 재고해야 합니다. 그 영역은 시나리오형으로 좁히거나, 사내 직원용으로만 쓰고 고객 응대는 사람이 하는 구조가 안전합니다.

5-2. 줄이는 장치

완전히 없앨 수는 없지만, 아래 장치들이 실질적으로 도움이 됩니다.

근거 표시. 답변 아래에 참조한 문서와 링크를 붙입니다. 사용자가 확인할 수 있고, 근거 없는 답은 눈에 띕니다. 가장 비용 대비 효과가 큰 장치입니다.

모르면 모른다고 하도록 강제. 찾아온 문서에 답이 없으면 지어내지 말고 담당자 연결로 넘기게 만듭니다. 프롬프트만으로는 완전하지 않으므로, 검색 결과의 관련도가 기준 이하이면 아예 생성하지 않고 넘기는 규칙을 코드 쪽에 두는 편이 확실합니다.

금지 주제 목록. 가격 확약, 납기 확약, 법적 해석, 경쟁사 비교 같은 주제는 답하지 않고 사람에게 넘기도록 지정합니다.

면책 문구. "안내 내용은 참고용이며 정확한 조건은 담당자 확인이 필요합니다." 만능은 아니지만, 무엇이 공식 답변인지의 경계를 만듭니다. 표시 위치는 대화창 안, 답변 근처여야 의미가 있습니다.

사람으로 넘기는 경로. 모든 대화에 "상담원 연결" 또는 "문의 남기기"가 한 번의 클릭 거리에 있어야 합니다. 챗봇의 목적이 사람을 완전히 대체하는 것이 아니라 사람에게 갈 질문을 줄이는 것이라면, 이 경로는 실패가 아니라 설계입니다.

대화 기록 보존. 무엇을 물었고 무엇을 답했는지가 남아 있어야 분쟁 시 확인이 됩니다. 그리고 개선의 재료가 됩니다.

5-3. 개인정보 문제

대화창에 사용자가 무엇을 입력할지는 통제할 수 없습니다. 주문번호, 전화번호, 심하면 주민등록번호를 넣는 사람도 있습니다.

미리 정해야 할 것들입니다.

대화 내용을 어디에 얼마나 보관하는가
외부 모델 API로 나가는가. 나간다면 그 사실이 개인정보 처리방침에 반영되어 있는가
처리위탁 고지가 필요한 범위인가
입력값에서 민감정보를 걸러내는 처리를 넣을 것인가

이건 기능이 아니라 준수 사항이고, 나중에 붙이면 구조를 바꿔야 하는 경우가 생깁니다. 설계 단계에서 정하십시오. 개인정보 처리방침과 쿠키 안내를 어디까지 맞춰야 하는지는 개인 사이트 쿠키·개인정보 안내에서 최소 기준을 정리해 두었습니다.

6. 계산 넷 — 챗봇 말고 더 싼 해법이 같은 문제를 푸는가

이 질문을 마지막에 두는 이유는, 앞의 세 계산을 해 보고 나면 답이 바뀌는 경우가 많기 때문입니다.

챗봇 요청 뒤에 있는 진짜 문제는 대개 이 중 하나입니다.

문제 A — "고객이 같은 걸 계속 물어본다"

챗봇보다 먼저 볼 것: 그 질문들의 답이 홈페이지에서 찾을 수 있는 위치에 있는가.

같은 질문이 반복된다는 것은 답이 없다는 뜻이거나, 있는데 못 찾는다는 뜻입니다. 후자라면 FAQ를 잘 만들고 사이트 검색을 고치는 편이 훨씬 쌉니다. 그리고 그렇게 정리한 FAQ는 나중에 챗봇을 붙일 때 그대로 재료가 됩니다. 버려지는 작업이 아닙니다.

게다가 잘 쓴 FAQ는 검색과 AI 답변에도 노출됩니다. 챗봇은 우리 사이트에 들어온 사람에게만 작동하지만, FAQ 문서는 들어오지 않은 사람에게도 닿습니다. 이 차이는 AI 검색 노출을 다루는 순서에서 다룬 내용과 이어집니다.

문제 B — "상담 인력이 부족하다"

챗봇보다 먼저 볼 것: 들어오는 문의의 유형별 비중.

단순 조회(배송, 재고, 영업시간)가 대부분이면 시나리오형이나 조회 기능으로 충분하고 훨씬 쌉니다. 판단이 필요한 질문이 대부분이면 챗봇은 그 일을 못 덜어 줍니다.

문제 C — "문의가 안 들어온다"

챗봇보다 먼저 볼 것: 문의 폼이 어디 있고 몇 개를 물어보는가.

이 경우 챗봇은 대개 효과가 없습니다. 문의가 안 들어오는 이유는 대화 상대가 없어서가 아니라 사이트에 들어온 사람이 적거나, 들어와서 무엇을 해야 할지 모르거나, 문의 폼이 너무 많은 걸 물어봐서입니다.

다만 예외가 있습니다. B2B에서 방문자 수가 적고 건당 가치가 클 때, 대화형 인터페이스가 문의 전환을 실제로 올리는 경우가 있습니다. 이때는 목적이 "상담 대체"가 아니라 "리드 수집"이므로 설계가 완전히 달라집니다. 필요한 것은 방대한 문서가 아니라 몇 개의 질문으로 상대를 분류하고 연락처를 받는 흐름입니다. 이 경우 유형 1로도 충분한 경우가 많습니다.

문제 D — "경쟁사가 했다"

챗봇보다 먼저 볼 것: 경쟁사 챗봇에 실제로 다섯 개쯤 질문해 보기.

절반 이상은 잘 작동하지 않습니다. 확인하고 나면 판단이 달라지는 경우가 많습니다.

7. 그래서 언제 도입할 만한가

앞의 네 계산을 통과 조건으로 묶으면 이렇습니다.

권할 만한 조건 (넷 중 셋 이상 해당)

3장의 20개 질문 중 A 분류가 15개 이상이거나, 문서 정리에 4주를 쓸 각오가 되어 있다
문서의 원본이 한 곳에 있고 바뀔 때 갱신할 담당자가 정해져 있다
잘못 답해도 사과와 정정으로 수습되는 범위의 정보만 다룬다
월 문의량이 실제로 부담이 될 만큼 있다 (사이트 방문자가 하루 열 명인데 챗봇을 붙이는 경우가 실제로 있습니다)

말리는 조건 (하나라도 해당하면 재고)

답의 근거가 문서가 아니라 담당자 판단에 있다
규제 영역(의료·법률·금융)이거나 안전 관련 정보를 다룬다
문서 갱신 담당자를 지정할 수 없다
"일단 만들어 보고 콘텐츠는 나중에 채우자"는 계획이다
도입 목적이 "요즘 다들 하니까"에서 더 구체화되지 않는다

특히 4번이 위험합니다. 챗봇은 콘텐츠 없이 껍데기부터 만들 수 있는 물건이라서, 완성된 것처럼 보이는 빈 껍데기가 되기 쉽습니다. 그리고 그 상태로 오픈하면 첫인상이 나빠지고, 나중에 제대로 채워도 사람들이 다시 오지 않습니다.

8. 도입하기로 했다면 — 범위를 좁히는 법

전사 통합 챗봇을 처음부터 만들지 마십시오. 실패 확률이 가장 높은 형태입니다.

권하는 순서는 이렇습니다.

1단계. 한 영역만. 제품군 하나, 또는 FAQ 상위 20개만. 문서 범위가 좁을수록 정확도가 올라갑니다. 이건 기술적 사실입니다. 후보 문서가 적으면 엉뚱한 걸 물고 올 확률이 줄어듭니다.

2단계. 내부 공개부터. 고객에게 열기 전에 직원이 2~4주 씁니다. 직원은 답이 틀린 걸 알아볼 수 있고, 고객은 못 알아봅니다. 이 기간에 나오는 오답이 가장 값싼 오답입니다.

3단계. 제한 공개. 특정 페이지에서만 노출하거나, 영업시간에만 띄웁니다. 문제가 생겼을 때 사람이 즉시 개입할 수 있는 상태에서 시작합니다.

4단계. 전면 공개와 확장. 대화 로그에서 답을 못 한 질문 목록을 뽑아 문서를 보강합니다. 이 목록이 다음 확장의 근거가 됩니다.

이 순서를 지키면, 3단계에서 "이건 아니다"라고 판단하고 멈춰도 잃는 것이 적습니다. 반대로 처음부터 전면 공개로 가면 멈추는 것 자체가 사건이 됩니다.

평가는 무엇으로 하는가

"잘 되고 있다"를 감으로 판단하지 않으려면 지표가 필요합니다. 실무에서 쓸 만한 것들입니다.

지표	보는 이유
대화 시작률	띄워 놨는데 아무도 안 누르면 위치·문구 문제
해결 없이 이탈한 비율	답이 도움이 안 됐다는 신호
사람에게 넘긴 비율	너무 높으면 범위가 안 맞음. 너무 낮아도 의심
답을 못 한 질문 목록	다음에 채울 문서 목록
문의 폼 유입 변화	챗봇이 문의를 막고 있지는 않은지

마지막 항목이 중요합니다. 챗봇이 문의를 대신 받아 처리한 것과, 문의하려던 사람을 챗봇이 붙잡아 놓쳐 버린 것은 겉으로 비슷해 보입니다. 도입 전 문의 건수를 기록해 두십시오. 나중에 비교할 기준선이 없으면 판단이 불가능합니다.

9. 견적서에서 확인할 항목

챗봇 견적을 받았다면 아래가 항목으로 들어 있는지 보십시오. 없다면 나중에 추가 비용이 되거나, 아예 빠진 채로 납품됩니다.

넣을 문서의 목록과 형식 — 몇 건인지, 이미지 PDF는 어떻게 처리하는지
문서 갱신 방식 — 자동 동기화인지 수동인지. 수동이면 관리 화면이 제공되는지
모델 비용 부담 주체 — 우리 계정인지 업체 계정인지. 업체 계정이면 나중에 단가가 어떻게 되는지
답을 못 할 때의 동작 — 무엇을 답하고 어디로 넘기는지
근거 문서 표시 여부
대화 로그 보관 위치·기간과 우리가 열람할 수 있는지
개인정보 처리 경로 — 외부로 나가는 데이터의 범위
오픈 후 튜닝 기간과 그 기간에 포함되는 작업
종료 조건 — 그만두기로 하면 문서와 로그를 어떤 형태로 돌려받는지

마지막 항목이 자주 빠집니다. 챗봇은 특정 업체 플랫폼에 묶이기 쉬운 물건이라, 나갈 때의 조건을 처음에 적어 두지 않으면 나중에 협상력이 없습니다.

10. 결론

세 문장으로 정리합니다.

첫째, 챗봇의 성패는 모델이 아니라 문서에서 갈립니다. 실제로 받은 질문 20개를 적고, 그 답이 문서 어디에 문장으로 있는지 세어 보는 30분이 견적 비교보다 먼저입니다. 이 숫자가 낮으면 어떤 솔루션을 써도 결과는 같습니다.

둘째, 구축비가 아니라 유지 구조를 보십시오. 모델 호출비는 트래픽에 비례해 늘고, 문서 갱신은 사람 시간을 계속 먹습니다. 갱신 담당자 이름이 안 나오는 챗봇은 시간이 지나며 회사가 공식적으로 틀린 말을 하는 장치가 됩니다.

셋째, 챗봇이 유일한 답이 아닌 경우가 많습니다. 반복 질문이 문제라면 FAQ 개편이 더 싸고, 그 작업은 나중에 챗봇을 붙일 때 그대로 재사용됩니다. 순서를 이렇게 잡으면 어느 단계에서 멈춰도 손해가 없습니다.

도입을 결정했다면 범위를 좁게, 내부부터, 근거를 표시하는 형태로 시작하십시오. 좁게 시작한 챗봇은 넓힐 수 있지만, 넓게 시작해 실패한 챗봇은 다시 열기 어렵습니다.

챗봇을 포함해 개편 범위를 잡아 대략의 비용 구간을 보고 싶다면 외주 개발 비용 계산기에서 필요한 기능을 골라 확인할 수 있습니다. RAG의 내부 동작을 좀 더 알고 싶다면 RAG 구현 편에 코드 수준으로 정리해 두었습니다.

초록