챗봇 화면부터 그리면 실패합니다

[이미지 삽입: 왼쪽에는 “무엇이든 물어보세요”만 적힌 평범한 AI 챗봇 화면, 오른쪽에는 문서 검색·출처 표시·권한 관리·답변 평가가 연결된 RAG 서비스 구조도]

“사내 문서를 학습시켜서 질문에 답하는 AI 서비스를 만들고 싶습니다.”

요즘 기획자와 PM이라면 한 번쯤 받아봤을 요청입니다.

고객센터 상담 기록을 검색하는 AI, 사내 규정을 찾아주는 업무 도우미, 제품 매뉴얼을 기반으로 답변하는 챗봇처럼 RAG를 활용할 수 있는 영역은 빠르게 늘어나고 있습니다.

하지만 막상 기획서를 작성하려고 하면 대부분 비슷한 문제에 부딪힙니다.

“일단 챗봇 화면부터 그려야 하나?”

“문서를 넣으면 AI가 알아서 답해주는 것 아닌가?”

“검색 정확도는 어떤 기준으로 검수해야 하지?”

결론부터 말하면, RAG 서비스 기획의 핵심은 챗봇 UI가 아니라 ‘어떤 근거를 찾아서, 어떤 조건으로 답변하게 할 것인가’를 설계하는 것입니다.

RAG 서비스는 일반적인 AI 챗봇과 무엇이 다를까요?

RAG는 Retrieval-Augmented Generation의 약자입니다.

쉽게 말하면, AI가 자신의 기존 지식만으로 답하는 것이 아니라 우리가 연결한 문서나 데이터에서 관련 내용을 먼저 찾고, 그 근거를 바탕으로 답변하는 방식입니다.

예를 들어 사용자가 다음과 같이 질문했다고 가정해 보겠습니다.

“우리 회사의 재택근무 신청 기준을 알려줘.”

일반적인 생성형 AI는 자신이 알고 있는 일반적인 재택근무 정책을 답변할 수 있습니다.

반면 RAG 서비스는 사내 인사 규정, 최신 공지사항, 부서별 운영 지침에서 관련 내용을 검색한 뒤 답변합니다.

즉, RAG 서비스의 품질은 AI 모델 하나로 결정되지 않습니다.

어떤 문서를 연결했는지, 검색 범위를 어떻게 정했는지, 어떤 문서를 우선할지, 근거가 없을 때 어떻게 대응할지가 함께 설계되어야 합니다.

❌ 많은 RAG 서비스 기획서가 실패하는 이유

RAG 프로젝트를 시작할 때 가장 흔한 실수는 “AI 챗봇을 만든다”는 관점에서 기획하는 것입니다.

이렇게 시작하면 화면은 빠르게 나오지만, 실제 사용 단계에서 문제가 발생합니다.

1. 답변 대상과 범위가 너무 넓습니다

“사내 모든 질문에 답하는 AI”처럼 범위를 잡으면 서비스가 무엇을 잘해야 하는지 평가하기 어렵습니다.

인사 규정, 제품 정보, 계약서, 회의록, 고객 문의는 문서 구조도 다르고 필요한 답변 방식도 다릅니다.

처음부터 모든 문서를 연결하면 검색 결과가 섞이고, 사용자는 원하는 답변을 받지 못할 가능성이 높아집니다.

2. 문서가 있다는 사실만 확인합니다

많은 기획서에서 데이터 관련 항목은 다음과 같이 끝납니다.

사내 문서 연동
PDF 업로드
데이터베이스 연결

하지만 실제 서비스 품질을 결정하는 것은 문서의 존재가 아닙니다.

문서가 최신인지, 중복 문서가 있는지, 접근 권한은 어떻게 다른지, 표와 이미지가 제대로 읽히는지까지 확인해야 합니다.

3. 정답 기준이 없습니다

기획서에는 “높은 정확도의 답변 제공”이라고 적혀 있지만, 정확도가 무엇을 의미하는지는 정의되어 있지 않은 경우가 많습니다.

RAG 서비스에서는 최소한 다음 항목을 구분해야 합니다.

올바른 문서를 찾았는가
문서 내용을 왜곡하지 않았는가
질문에 필요한 내용만 답했는가
답변의 출처를 확인할 수 있는가
근거가 없을 때 답변을 멈췄는가

4. 예외 상황이 빠져 있습니다

RAG 서비스는 항상 답을 찾을 수 있는 것이 아닙니다.

문서에 정보가 없거나, 서로 다른 문서의 내용이 충돌하거나, 사용자가 권한이 없는 문서를 요청할 수도 있습니다.

이때 AI가 그럴듯한 답변을 만들어내면 서비스 신뢰도는 빠르게 떨어집니다.

RAG 서비스에서 중요한 것은 모든 질문에 답하는 능력이 아니라, 답할 수 없는 질문을 안전하게 구분하는 능력입니다.

💡 RAG 서비스 기획서는 6개의 질문에 답해야 합니다

RAG 서비스 기획서를 작성할 때는 기능 목록부터 만들기보다 다음 6가지 질문에 먼저 답해야 합니다.

누가 사용하는가?
어떤 질문을 해결하는가?
어떤 문서를 검색하는가?
어떤 기준으로 답변하는가?
답변 결과를 어떻게 검증하는가?
운영 중 문서를 어떻게 관리하는가?

이 6가지 질문을 기준으로 기획서를 구성하면 개발자, 디자이너, 데이터 담당자와의 커뮤니케이션도 훨씬 명확해집니다.

STEP 1. 서비스 목적과 사용자 시나리오를 정의합니다

가장 먼저 해야 할 일은 RAG를 도입하는 것이 아니라, 사용자가 해결하려는 문제를 정의하는 것입니다.

“사내 지식 검색 AI 구축”처럼 기술 중심으로 목적을 작성하지 마세요.

대신 사용자가 어떤 상황에서 얼마나 불편을 겪고 있는지 구체적으로 작성해야 합니다.

나쁜 목적 정의

“생성형 AI와 RAG를 활용한 사내 챗봇을 구축한다.”

좋은 목적 정의

“신입 직원이 사내 규정과 업무 절차를 찾는 데 평균 20분 이상 소요되는 문제를 줄이고, 검증된 사내 문서를 근거로 3분 이내에 필요한 정보를 확인할 수 있도록 한다.”

이처럼 서비스 목적에는 다음 요소가 포함되어야 합니다.

주요 사용자
사용자가 겪는 문제
해결할 질문 유형
기대하는 업무 변화
성공 여부를 확인할 지표

사용자 시나리오 예시

사용자: 입사 3개월 이내의 신규 직원

상황: 경조사 휴가 신청 기준을 확인하려고 함

기존 행동: 인트라넷 검색 → 관련 문서 여러 개 확인 → 인사팀에 재문의

RAG 서비스 사용: 질문 입력 → 관련 규정 검색 → 조건별 답변 제공 → 원문 확인

기대 결과: 문의 시간 단축, 인사팀 반복 문의 감소

[이미지 삽입: 사용자 질문 → 관련 문서 검색 → 근거 기반 답변 → 원문 확인으로 이어지는 사용자 흐름]

STEP 2. 질문 범위와 답변 범위를 분리합니다

사용자가 질문할 수 있다고 해서 AI가 반드시 답해야 하는 것은 아닙니다.

기획서에는 답변 가능한 범위, 제한적으로 답변하는 범위, 답변하지 않는 범위를 명확히 구분해야 합니다.

답변 가능 범위

사내 복지 규정
휴가 신청 절차
비용 처리 기준
제품 매뉴얼
고객 응대 가이드

제한적 답변 범위

부서별로 기준이 다른 내용
승인권자의 판단이 필요한 내용
최신 공지에 따라 자주 변경되는 내용
법률적 해석이 필요한 내용

답변 불가 범위

인사 평가 결과
다른 직원의 개인정보
공개되지 않은 계약 정보
시스템에 등록되지 않은 문서
추측이 필요한 질문

기획서에는 각 범위별로 AI가 어떻게 행동할지도 작성해야 합니다.

예를 들어 근거 문서를 찾지 못했을 때는 다음과 같이 설계할 수 있습니다.

“관련 문서에서 확인 가능한 내용을 찾지 못했습니다. 질문을 조금 더 구체적으로 입력하거나 담당 부서에 문의해 주세요.”

근거가 없을 때 답변을 생성하지 않는 정책은 선택 기능이 아니라 필수 안전장치입니다.

STEP 3. 데이터와 문서 정책을 설계합니다

RAG 서비스의 성능은 연결된 문서의 품질을 넘어서기 어렵습니다.

따라서 기획자는 단순히 “PDF 연동”이라고 쓰는 것이 아니라, 데이터가 서비스에 들어오고 관리되는 전체 흐름을 설계해야 합니다.

기획서에 포함해야 할 문서 항목

문서 종류
문서 소유 부서
파일 형식
업데이트 주기
보안 등급
사용 가능 대상
최신 버전 판단 기준
삭제 및 보관 정책
중복 문서 처리 방식

문서 우선순위 예시

동일한 주제의 문서가 여러 개 검색될 때 어떤 문서를 우선해야 하는지도 정해야 합니다.

1순위: 최신 공식 규정

2순위: 공식 공지사항

3순위: 부서 운영 가이드

4순위: 교육 자료

5순위: 과거 회의록 및 참고 문서

예를 들어 2026년 인사 규정과 2024년 교육 자료가 동시에 검색된다면, 최신 공식 규정을 우선해야 합니다.

이 우선순위가 없다면 AI는 오래된 문서를 근거로 답할 수 있습니다.

문서 전처리 기준도 필요합니다

RAG 시스템은 긴 문서를 일정한 단위로 나누어 검색합니다.

이 작업을 흔히 청킹이라고 부릅니다.

청킹은 문서를 작은 검색 단위로 나누는 작업입니다.

기획자가 기술적인 세부 값을 모두 결정할 필요는 없지만, 어떤 기준으로 내용이 나뉘어야 하는지는 정의해야 합니다.

예를 들어 휴가 규정 문서를 단순히 글자 수로 자르면 다음과 같은 문제가 생길 수 있습니다.

휴가 대상자는 앞부분에 있음
사용 가능 일수는 다음 부분에 있음
신청 절차는 다른 부분에 있음

검색 결과에 일부 정보만 포함되면 답변이 불완전해질 수 있습니다.

따라서 다음과 같은 의미 단위로 나누는 것이 좋습니다.

적용 대상
신청 조건
사용 가능 일수
승인 절차
예외 사항
문의 부서

기획자는 문서를 어떻게 자를지보다, 하나의 답변에 어떤 정보가 함께 있어야 하는지를 정의해야 합니다.

STEP 4. 검색과 답변 정책을 구체화합니다

RAG 서비스의 핵심 흐름은 크게 두 단계입니다.

첫 번째는 관련 문서를 찾는 검색 단계입니다.

두 번째는 검색된 문서를 바탕으로 답변을 만드는 생성 단계입니다.

기획서에서도 이 두 단계를 분리해서 작성해야 합니다.

1) 검색 단계 기획

검색 단계에서는 다음 질문에 답해야 합니다.

검색 대상 문서는 어디까지인가?
문서 제목과 본문 중 무엇을 검색하는가?
최신 문서를 우선하는가?
사용자의 부서와 권한을 반영하는가?
검색 결과를 몇 개까지 활용하는가?
유사한 질문을 어떻게 처리하는가?

예를 들어 사용자가 “회사 노트북을 외부로 가져가도 되나요?”라고 질문할 수 있습니다.

문서에는 “정보기기 반출 정책”이라는 표현만 있을 수도 있습니다.

이때 단어가 정확히 일치하지 않아도 관련 문서를 찾을 수 있도록 동의어와 유사 표현을 고려해야 합니다.

노트북 → 정보기기, 업무용 PC
외부 반출 → 반출, 사외 이동
재택근무 → 원격근무, 자택근무

2) 답변 생성 단계 기획

답변 형식도 사용 목적에 따라 달라져야 합니다.

단순 정보 검색 서비스라면 짧은 요약이 적합합니다.

업무 처리 지원 서비스라면 조건, 절차, 예외 사항까지 구조화해서 보여줘야 합니다.

답변 템플릿 예시

요약

업무용 노트북은 사전 승인 후 외부 반출이 가능합니다.

필요 조건

부서장 승인
보안 프로그램 설치
반출 신청서 제출

주의사항

해외 반출은 정보보안팀의 별도 승인이 필요합니다.

근거 문서

정보기기 반출 정책 제4조, 2026년 3월 개정본

이처럼 답변 템플릿을 정의해두면 답변 품질이 안정되고, 사용자가 필요한 정보를 빠르게 찾을 수 있습니다.

STEP 5. 화면보다 먼저 예외 흐름을 설계합니다

RAG 서비스 화면 기획에서는 정상적인 답변 화면만 그리기 쉽습니다.

하지만 실제 사용성은 예외 상황에서 결정됩니다.

기획서에는 최소한 다음 상황을 포함해야 합니다.

상황 1. 검색 결과가 없는 경우

답변을 생성하지 않음
질문 재작성 예시 제공
담당 부서 또는 기존 검색 서비스 안내

상황 2. 문서 내용이 서로 충돌하는 경우

최신 문서를 우선 표시
충돌한 문서를 함께 안내
확정적인 표현 대신 확인 필요 상태로 표시

상황 3. 사용자 권한이 없는 경우

문서 내용과 제목을 노출하지 않음
접근 권한이 없다는 메시지만 제공
권한 요청 절차 안내

상황 4. 질문이 너무 넓은 경우

사용자 질문: “우리 회사 복지 알려줘.”

응답 예시:

“복지 항목이 다양합니다. 아래에서 확인하고 싶은 항목을 선택해 주세요.”

건강검진
교육비
경조사
휴가
식대 및 교통비

상황 5. 답변 확신도가 낮은 경우

단정적인 표현 사용 금지
관련 문서 후보를 보여줌
사용자에게 추가 조건 입력 요청

[이미지 삽입: 정상 답변, 검색 결과 없음, 권한 없음, 문서 충돌 상황을 비교한 4분할 UI]

STEP 6. 평가 지표를 사용자 관점에서 정의합니다

RAG 서비스의 성과를 단순히 “정확도 90%”로만 표현하면 부족합니다.

검색, 답변, 사용자 경험, 운영 효율을 나누어 평가해야 합니다.

검색 품질 지표

필요한 문서가 검색 결과에 포함되었는가
가장 중요한 문서가 상단에 노출되었는가
오래되거나 관련 없는 문서가 섞이지 않았는가

답변 품질 지표

답변이 근거 문서와 일치하는가
문서에 없는 내용을 만들어내지 않았는가
질문의 핵심을 빠뜨리지 않았는가
출처가 올바르게 연결되었는가

사용자 경험 지표

사용자가 답변을 이해할 수 있는가
원문을 쉽게 확인할 수 있는가
재질문 없이 문제를 해결할 수 있는가
답변이 너무 길거나 복잡하지 않은가

비즈니스 지표

반복 문의 감소율
정보 검색 시간 감소
상담 처리 시간 단축
문서 조회율 증가
사용자 재사용률

평가 질문 세트도 함께 작성하세요

RAG 서비스는 실제 질문으로 테스트해야 합니다.

기획 단계에서 최소 30~50개의 대표 질문을 미리 작성해두는 것이 좋습니다.

질문은 다음과 같이 유형별로 구성할 수 있습니다.

문서에 정답이 명확히 있는 질문
여러 문서를 함께 봐야 하는 질문
질문 표현이 모호한 경우
오래된 문서와 최신 문서가 함께 있는 경우
답변할 수 없는 질문
권한이 필요한 질문
오탈자와 구어체가 포함된 질문

대표 질문 세트는 QA 단계에서 만드는 것이 아니라, 서비스 범위를 정할 때부터 준비해야 합니다.

실무에서 바로 쓰는 RAG 서비스 기획서 목차

아래 구조를 기준으로 기획서를 작성하면 주요 논의 사항을 빠뜨리지 않고 정리할 수 있습니다.

1. 프로젝트 개요

프로젝트 배경
해결하려는 문제
서비스 목표
주요 사용자
기대 효과

2. 서비스 범위

지원하는 질문
지원하지 않는 질문
대상 문서
사용 부서
권한 정책

3. 핵심 사용자 시나리오

질문 입력
검색
답변 생성
출처 확인
추가 질문
피드백 등록

4. 데이터 정책

문서 유형
문서 수집 방식
업데이트 주기
최신 문서 기준
중복 문서 처리
문서 삭제 정책
접근 권한

5. 검색 정책

검색 범위
우선순위
필터 조건
유사어 처리
검색 결과 개수
문서 선택 기준

6. 답변 정책

답변 구조
문체
출처 표시
근거 없는 답변 방지
답변 길이
주의 문구

7. 예외 처리

검색 결과 없음
문서 충돌
권한 부족
모호한 질문
서비스 장애
답변 생성 실패

8. 화면 설계

메인 질문 화면
답변 화면
출처 확인 화면
문서 미리보기
피드백 화면
관리자 화면

9. 평가 및 운영

테스트 질문 세트
품질 평가 기준
사용자 피드백 반영
문서 업데이트 관리
답변 로그 분석
개선 주기

10. 단계별 출시 계획

PoC 범위
MVP 범위
정식 출시 범위
확장 기능

MVP는 Minimum Viable Product의 약자로, 핵심 가설을 검증할 수 있는 최소 기능 제품을 의미합니다.

처음부터 모든 기능을 넣지 마세요

RAG 서비스는 작은 범위에서 검증한 뒤 확장하는 것이 좋습니다.

1단계: PoC

PoC는 기술적으로 가능한지 확인하는 실험 단계입니다.

문서 20~50개
사용자 질문 30개
단일 부서
기본 검색 및 답변
관리자만 사용

2단계: MVP

실제 사용자 그룹 적용
출처 표시
권한 관리
사용자 피드백
문서 업데이트 기능
품질 평가 대시보드

3단계: 정식 서비스

여러 부서 확장
외부 시스템 연동
개인화 검색
질문 추천
업무 실행 기능 연결
운영 자동화

처음부터 전사 문서를 모두 연결하면 문제가 발생했을 때 원인을 찾기 어렵습니다.

한 가지 사용자, 한 가지 문서군, 한 가지 핵심 질문 유형부터 시작하는 것이 가장 안전합니다.

☑ 좋은 RAG 서비스 기획서는 이렇게 다릅니다

좋은 RAG 기획서는 기능을 많이 적은 문서가 아닙니다.

서비스가 어떤 근거로 답하고, 어떤 상황에서는 답하지 않아야 하는지 명확하게 정의한 문서입니다.

RAG 서비스 기획서를 제대로 작성하면 다음과 같은 변화가 생깁니다.

개발팀이 검색과 생성 요구사항을 명확하게 이해할 수 있습니다.
데이터 담당자가 어떤 문서를 정리해야 하는지 알 수 있습니다.
디자이너가 정상 화면뿐 아니라 예외 화면까지 설계할 수 있습니다.
QA 담당자가 무엇을 기준으로 품질을 검수해야 하는지 알 수 있습니다.
운영팀이 문서 업데이트와 오류 대응 절차를 준비할 수 있습니다.
사용자에게 신뢰할 수 있는 답변 경험을 제공할 수 있습니다.

기획자가 꼭 기억해야 할 한 문장

RAG 서비스는 AI가 답변하는 서비스가 아니라, 신뢰할 수 있는 정보를 찾아 전달하는 서비스입니다.

화려한 챗봇 UI보다 먼저 정의해야 할 것은 질문 범위, 문서 정책, 검색 우선순위, 답변 기준, 예외 처리입니다.

이 기준이 명확해야 모델이나 기술이 바뀌더라도 서비스 품질을 유지할 수 있습니다.

👉 이제 빈 기획서 화면에서 “챗봇 기능”부터 적지 마세요.

먼저 사용자가 자주 묻는 질문 30개를 모으고, 각 질문의 정답이 들어 있는 문서와 답변 불가 조건을 연결해 보세요.

그 목록이 바로 RAG 서비스 기획서의 가장 중요한 시작점입니다.

[실전 적용하기]

아래 항목부터 한 장으로 정리해 보세요.

핵심 사용자 1명
해결할 질문 유형 3개
연결할 문서군 1개
답변하지 않을 질문 5개
대표 테스트 질문 30개
답변 성공 기준 3개

이 한 장이 완성되면, 그다음부터는 화면과 기능이 아니라 근거와 정책을 중심으로 RAG 서비스를 설계할 수 있습니다.