AI 챗봇 앱 개발 외주 설계: RAG·권한·검수를 한 흐름으로
AI 챗봇 앱 개발 외주에서 RAG 자료 관리, 사용자별 접근 권한, API 키 보안, 장애 대응과 품질 검수 기준을 어떻게 설계할지 고객지원 앱 예시로 정리했습니다.
AI 챗봇을 앱에 붙일 때 가장 큰 변수는 채팅 UI가 아니라 무슨 자료를 근거로, 누구에게, 어디까지 답하고 실행할지입니다. 고객지원 앱을 예로 들어 첫 버전의 기능 범위와 서버 구조, 검수 기준을 정리합니다.
1. ‘답변’과 ‘실행’을 나눠 범위를 정합니다
“예약 변경 방법을 알려줘”는 승인된 도움말을 찾아 설명하는 일입니다. “내 예약을 취소해 줘”는 로그인한 사용자의 데이터를 읽고 상태를 바꾸는 일입니다. 둘을 모두 ‘AI 상담’으로 묶으면 필요한 권한·API·검수 범위가 흐려집니다.
첫 출시 범위를 ① 공개 문서 안내 ② 개인 데이터 조회 ③ 실제 작업 실행으로 나눠 보세요. ①만 출시한다면 답변 뒤 기존 예약 화면으로 연결할 수 있습니다. ②에는 서버의 사용자 인증과 데이터 접근 제어가, ③에는 변경 전 확인·승인·실패 복구 흐름이 추가됩니다. 모델이 어떤 작업을 제안하더라도 실제 데이터 변경 권한은 서버가 판단해야 합니다.
2. RAG보다 먼저 ‘정답 자료’를 관리합니다
검색 증강 생성(RAG)은 질문과 관련된 문서를 찾아 모델의 답변에 참고시키는 방식입니다. 그러나 문서가 오래됐거나 서로 충돌하면 검색을 붙여도 신뢰할 수 있는 답은 나오기 어렵습니다.
운영자가 승인한 문서만 수집하고, 각 문서에 버전·수정일·적용 시점·담당자를 남겨두세요. 문서가 바뀌면 검색 색인에 언제 반영되는지 확인해야 합니다. 답변에는 참조한 문서나 페이지 링크를 함께 제공하고, 근거가 없으면 답변을 보류하는 기준을 정하는 편이 안전합니다.
예를 들어 환불 규정이 바뀌었다면 이전 공지가 아니라 현재 적용되는 규정을 우선해야 합니다. 이 우선순위는 프롬프트 한 줄보다 자료의 수집·폐기·검수 절차로 관리하는 것이 안정적입니다.
3. 검색 전에 사용자 권한을 확인합니다
개인 예약을 다루는 챗봇이라면 질문을 받은 서버가 먼저 로그인과 사용자 권한을 확인해야 합니다. 그다음 허용된 자료만 검색 대상으로 보내야 합니다. 전체 예약을 검색한 뒤 모델에게 “다른 사람 것은 말하지 마”라고 지시하는 방식은 권한 관리가 아닙니다.
외부 AI 서비스의 API 키는 앱에 포함하지 않고 서버에서 보관합니다. 모델에 전달하는 데이터도 답변에 필요한 최소 범위로 줄입니다. 또한 검색된 문서나 사용자 입력에는 “이전 지시를 무시하라” 같은 악의적인 문장이 섞일 수 있습니다. 이를 명령이 아닌 신뢰할 수 없는 데이터로 취급하고, 서버의 권한 규칙을 우회하지 못하도록 설계해야 합니다.
4. 모르는 경우와 장애도 제품 동작으로 설계합니다
근거 문서를 찾지 못했거나 답변이 확실하지 않다면 그럴듯하게 추측하는 것보다 “확인 가능한 안내가 없습니다”라고 말하고 고객센터 또는 기존 화면으로 연결하는 편이 낫습니다. 타임아웃·서비스 오류·사용량 한도 초과 때의 문구와 재시도 기준도 함께 정합니다.
운영비는 모델 이름 하나만으로 결정되지 않습니다. 질문 수, 입력·출력 길이, 검색에 포함되는 자료량, 재시도와 모니터링 범위가 영향을 줍니다. 견적에는 초기 구축비와 출시 후 AI API 사용료를 분리하고, 요청 한도·비용 알림·장애 대응 주체를 명시하세요. 사용량 예측은 가정치이고, 실제 요금은 선택한 제공업체의 현재 가격표와 운영 데이터로 다시 계산해야 합니다.
5. ‘답변이 자연스럽다’ 대신 테스트 목록으로 검수합니다
의뢰인과 개발사가 공통으로 사용할 질문 세트를 만드세요. 정상 질문뿐 아니라 오래된 규정, 존재하지 않는 규정, 다른 사용자의 예약, 외부 AI 서비스 오류를 포함해야 합니다.
- 근거 문서가 있을 때 최신 버전을 인용하며 답하는가?
- 근거가 없을 때 지어내지 않고 안전한 다음 행동을 제시하는가?
- 다른 계정의 데이터 조회와 변경 요청이 서버에서 차단되는가?
- AI 서비스가 느리거나 중단돼도 사용자가 계속 진행할 방법이 있는가?
- 문서나 모델을 교체한 뒤 같은 테스트를 반복할 수 있는가?
검수 결과에는 답변 내용뿐 아니라 참조 문서, 응답 시간, 오류 유형, 대략적인 요청당 비용을 기록해 두면 출시 후 개선 우선순위를 정하기 쉽습니다. 인수인계에는 자료 업데이트 방법, API 계정 소유권, 비용 알림, 장애 확인 위치와 테스트 목록을 포함하세요.
견적 요청서에 넣을 최소 정보
첫 버전에서 답할 질문 3~5개, 공식 근거 자료 1~2개, 사용자별 정보 접근 여부, 실제 작업 실행 여부, 월 예상 문의량과 실패 시 연결할 화면을 적어 보세요. 이 정도만 있어도 개발사가 서로 다른 가정으로 견적을 내는 일을 줄일 수 있습니다.
키플은 앱 화면부터 서버 데이터 흐름, 출시와 운영까지 범위를 함께 정리합니다. 앱 개발 방식과 포트폴리오 보기
이 글의 예약 서비스는 구조 설명을 위한 가상 예시입니다. 서비스의 데이터·법적 요구사항·보안 위협에 따라 실제 설계와 검수 범위는 달라집니다.
자주 묻는 질문
AI 챗봇 앱 외주 견적에서 가장 먼저 정할 것은 무엇인가요?
공개 문서 안내만 할지, 로그인한 사용자의 정보를 조회할지, 실제 예약 변경까지 실행할지를 구분하세요. 각 단계에 필요한 서버 권한과 검수 범위가 달라집니다.
RAG를 붙이면 최신 정보와 사용자 권한 문제가 해결되나요?
아닙니다. 승인된 문서의 버전과 갱신 절차를 관리해야 하고, 사용자별 접근 권한은 검색 전에 서버에서 확인해야 합니다. 근거가 없을 때 답을 보류하는 기준도 필요합니다.