기업용 AI 챗봇 구축 전에 준비해야 할 데이터와 접근 정책

사내 AI 챗봇을 만들기로 정하고 나면 대개 모델부터 고릅니다. 어느 모델이 더 똑똑한지, 어떤 방식으로 문서를 붙일지를 먼저 논의합니다. 그런데 실제로 프로젝트가 멈추는 자리는 모델이 아니라 그 앞입니다. 어떤 자료를 넣어도 되는지, 권한이 다른 사람에게 같은 답이 나가도 되는지, 개인정보가 답변과 기록으로 새지 않는지를 정하지 않은 채 개발부터 시작하면, 시연은 통과하고 운영 승인에서 막힙니다.

이 글은 챗봇을 어떻게 만드는가가 아니라 만들기 전에 무엇을 정해 두어야 하는가를 다룹니다. 다루는 항목은 다섯 가지입니다. 넣을 데이터와 뺄 데이터를 가르는 일, 권한이 다른 사람에게 다른 답이 나가게 하는 일, 개인정보·기밀이 새는 자리를 막는 일, 데이터가 어디에 저장되고 학습에 쓰이는지 확인하는 일, 답이 틀렸을 때 걸러내는 일입니다. 모두 기술 난이도의 문제가 아니라 착수 전에 내려야 할 결정이라는 공통점이 있습니다. 결정을 미루고 개발을 먼저 하면 나중에 데이터 흐름 자체를 되돌려야 하고, 그 시점에는 비용이 훨씬 커집니다.

넣어도 되는 데이터와 빼야 할 데이터

준비의 첫 단계는 자료를 늘리는 것이 아니라 좁히는 것입니다. 사내에 있는 문서를 전부 넣으면 챗봇이 똑똑해질 것 같지만, 실제로는 반대 방향으로 문제가 생깁니다. 넣을 자료가 많을수록 그 안에 섞여 있는 개인정보와 기밀, 그리고 이미 폐기된 옛 문서를 걸러 낼 일도 함께 늘어나기 때문입니다.

자료를 세 갈래로 나눠 보시면 판단이 쉬워집니다.

• 넣어도 되는 것 — 공개해도 문제가 없거나 사내 누구나 봐도 되는 자료입니다. 제품 설명, 공개된 정책, 자주 묻는 질문의 답 같은 것이 여기 속합니다. 이 범위부터 시작하면 초기 위험이 가장 낮습니다.
• 가리거나 분리해서 넣는 것 — 내용은 필요하지만 그 안에 개인정보나 특정 수치가 섞여 있는 자료입니다. 사람 이름과 연락처를 지우고 넣거나, 권한이 있는 사람에게만 보이도록 분리해 넣습니다.
• 넣지 않는 것 — 유출됐을 때 피해가 크고 챗봇이 굳이 답할 필요가 없는 자료입니다. 계약 원본, 인사 기록, 미공개 재무 자료 같은 것입니다.

여기서 자주 빠뜨리는 것이 폐기본 문제입니다. 최신본과 옛 버전이 같은 폴더에 섞여 있으면 챗봇은 둘을 구분하지 못하고, 폐기된 규정을 성실하게 요약해 답으로 내놓습니다. 사람이 틀린 문서를 인용하는 것보다 더 위험한 이유는, 챗봇의 답에는 근거가 붙어 있어 신뢰도가 높아 보이기 때문입니다. 그래서 넣을 자료를 고르는 일에는 무엇을 넣을지뿐 아니라 어느 버전이 유효한지 정리하는 일이 함께 들어갑니다.

이 구분은 개발자가 아니라 자료를 아는 현업과 법무가 내려야 하는 결정입니다. 담당자가 정해지지 않은 채 “일단 다 넣고 나중에 거르자”로 시작하면, 그 “나중에”는 대개 운영 승인이 막힌 뒤에 옵니다.

권한이 다른 사람에게 다른 답이 나가야 할 때

가장 자주, 그리고 가장 늦게 발견되는 문제가 이것입니다. 같은 챗봇에 같은 질문을 해도 묻는 사람의 권한에 따라 답이 달라져야 하는데, 그 통제를 어느 단계에서 거느냐를 잘못 잡으면 방어가 성립하지 않습니다.

핵심 원칙은 하나입니다. 접근 권한은 답을 만든 뒤에 걸러 내면 이미 늦습니다. 챗봇이 일단 모든 문서를 훑어 답을 만들고, 그 답에서 민감한 부분만 지우는 방식은 안전해 보이지만 그렇지 않습니다. 지우기 전의 내용이 이미 모델 입력으로 들어갔고, 그 입력은 뒤에서 다룰 로그에도 남기 때문입니다. 통제는 반드시 챗봇이 근거 자료를 찾는 검색 단계에서 걸려야 합니다. 원리를 더 깊이 보시려면 RAG란 무엇인가에서 검색과 생성이 어떻게 나뉘는지 확인하실 수 있습니다.

검색 단계에서 권한을 반영하려면 세 가지가 이어져 있어야 합니다.

• 신원 전달 — 챗봇이 답을 만들 때 “지금 묻는 사람이 누구인가”를 함께 받아야 합니다. 로그인한 사람의 부서·직급 같은 정보가 검색 요청에 실려야, 그 사람이 볼 수 있는 범위 안에서만 근거를 찾습니다. 이 정보가 끊기면 아래 두 가지를 아무리 잘 준비해도 소용이 없습니다.
• 자료별 접근 범위 — 넣은 문서마다 “누가 볼 수 있는가”가 붙어 있어야 합니다. 문서가 조각으로 나뉘어 저장되는 구조라면 그 조각 단위까지 접근 범위가 유지되는지 확인해야 합니다. 원본에는 권한이 걸려 있었는데 조각으로 쪼개는 과정에서 그 정보가 떨어져 나가는 경우가 실제로 자주 있습니다.
• 변경 반영 — 사람이 부서를 옮기거나 퇴사했을 때, 그 변경이 챗봇의 검색 범위에 곧바로 반영되어야 합니다. 사내 계정 체계에서 권한을 한곳으로 모아 관리하고 챗봇이 그 기준을 따르도록 해 두지 않으면, 나간 사람이 여전히 옛 권한으로 답을 받는 구간이 생깁니다.

이 셋을 검색 단계에서 실제로 반영하는 구현은 AI 문서검색 솔루션이 다루는 범위입니다. 이 글에서 정해 두어야 할 것은 구현 방식이 아니라 그 앞의 결정입니다 — 우리 자료 중 사람마다 다르게 보여야 하는 것이 무엇이고, 그 기준을 어디서 관리할 것인가입니다. 판단의 기준은 간단합니다. “이 사람에게는 나가면 안 되는 문장”이 하나라도 있으면, 그 통제는 생성이 아니라 검색 단계에서 걸려야 합니다.

개인정보·기밀이 새는 자리

데이터를 잘 골라 넣고 권한도 검색 단계에서 걸었다면 큰 줄기는 잡힌 것이지만, 새는 자리는 답변 본문 말고도 여러 곳에 있습니다. 미리 짚어 두지 않으면 대개 법무 검토나 사고가 난 뒤에 드러납니다.

• 답변 본문 — 근거 자료에 개인정보가 섞여 있으면 답변에도 그대로 나올 수 있습니다. 개인정보를 감지해 가리는 안전장치를 두는 것이 도움이 되며, Amazon Bedrock Guardrails 같은 기능은 민감정보 필터, 특정 주제 차단, 근거와 답변이 어긋나는지 확인하는 검증을 제공합니다. 다만 이런 장치는 새는 양을 줄이는 그물이지 완전 방지가 아닙니다. AWS 문서도 차단·마스킹을 “돕는다”고 설명합니다. 장치 하나에 방어를 몰아두지 마시고, 애초에 넣지 않을 자료를 먼저 줄여 그물이 감당할 몫을 낮추는 편이 안전합니다.
• 로그 — 여기가 가장 자주 잊히는 자리입니다. 챗봇은 대개 질문과 답변, 그리고 근거로 쓴 문서 조각을 기록으로 남깁니다. 개인정보가 질문이나 근거에 들어갔다면 그 로그에도 남습니다. 그래서 로그를 얼마나 오래 보관하고, 누가 열람할 수 있으며, 언제 지우는지를 착수 전에 정해야 합니다. 답변만 검열하고 로그를 방치하면 지운 내용이 다른 곳에 그대로 쌓입니다.
• 입력 창 — 사용자가 질문에 직접 개인정보나 기밀을 적어 넣는 경로입니다. AWS의 데이터 보호 안내도 자유 입력 칸에 기밀·민감 정보를 넣지 말 것을 권고합니다. 사내 자료 못지않게 사용자가 스스로 입력하는 내용도 관리 대상이며, 이는 시스템 설계만으로 막기 어려워 사용 안내와 함께 다뤄야 합니다.
• 전송 구간 — 데이터가 오가는 경로가 암호화되어 있는지, 외부로 나가는 지점이 어디인지도 확인 항목입니다.

같은 맥락에서, 개인정보를 주소창(URL)이나 자유 입력 칸으로 받는 설계는 권하지 않습니다. 빌드업웍스도 자사 시스템에서 개인정보를 주소창으로 받지 않는 것을 원칙으로 두고 있습니다. 한 번 그런 경로로 들어간 정보는 여러 곳의 기록에 흩어져 나중에 회수하기가 어렵기 때문입니다. 데이터 보호와 접근 통제를 어디까지 함께 다루는지는 통합 보안 서비스 범위에 나눠 적혀 있습니다.

데이터는 어디에 저장되고 학습에 쓰이는가

승인 단계에서 자주 나오는 질문이 “우리 데이터가 AI 학습에 쓰이느냐”입니다. 이 질문에는 감이 아니라 문서로 답할 수 있어야 하고, 답은 어떤 서비스를 쓰느냐에 따라 달라집니다.

확인해야 할 것은 세 가지입니다.

• 저장 위치와 리전 — 데이터가 어느 나라, 어느 리전에 저장되는지입니다. 국내 개인정보를 다룬다면 저장 위치가 규정 검토의 대상이 되며, 기준은 개인정보보호위원회 자료에서 확인하실 수 있습니다.
• 학습 활용 여부 — 우리가 넣은 입력과 챗봇의 출력이 모델을 개선하는 데 쓰이는지, 제공사와 공유되는지입니다. 예를 들어 Amazon Bedrock은 고객의 입력·출력을 기반 모델 개선에 사용하지 않고 모델 제공사와도 공유하지 않는다고 명시하고 있습니다. 다만 이는 서비스마다 다르므로, 특히 무료로 공개된 챗봇 도구에 사내 자료를 붙여 쓰는 경우에는 처리 방침이 전혀 다를 수 있다는 점을 함께 보셔야 합니다.
• 접근 주체 — 저장된 데이터에 클라우드 제공사나 우리 시스템의 어떤 권한이 닿을 수 있는지입니다. 최소한의 권한만 부여하는 원칙은 AWS IAM 보안 모범 사례가 정리해 두었고, 챗봇이 자료에 접근하는 권한도 이 원칙을 따라 필요한 만큼만 좁게 두어야 합니다.

이 세 가지를 특정 모델의 이름이나 버전으로 외우실 필요는 없습니다. 모델과 요금 구간은 시간이 지나며 바뀌므로, 정해 두어야 할 것은 “이 항목들을 도입 전에 공식 문서와 계약으로 확인한다”는 절차 자체입니다.

답이 틀렸을 때의 통제

준비를 아무리 해도 챗봇은 틀린 답을 내놓을 수 있습니다. 그래서 마지막 준비 항목은 정확도를 높이는 방법이 아니라 틀렸을 때 그것을 걸러 내고 기록하는 체계를 정하는 것입니다.

• 사람 검증 지점 — 답이 그대로 최종 결정에 쓰이면 안 되는 업무가 있습니다. 계약 조건이나 규정 해석처럼 틀렸을 때 피해가 큰 영역은 챗봇의 답을 초안으로 두고 사람이 확인하는 단계를 명시적으로 넣어야 합니다. 앞서 말한 근거 검증 장치가 답과 원문이 어긋나는지를 걸러 주긴 하지만, 그 자체가 사람의 판단을 대신하지는 못합니다.
• 오답 신고 경로 — 사용자가 틀린 답을 발견했을 때 그것을 알릴 자리가 있어야 합니다. 신고가 쌓이면 어떤 문서가 문제인지, 어느 질문에서 자주 틀리는지가 보이고, 그것이 다음 개선의 출발점이 됩니다.
• 감사 로그 — 누가 언제 무엇을 물었고 어떤 근거로 답이 나갔는지가 남아 있어야, 문제가 생겼을 때 무엇이 어디서 새었는지 되짚을 수 있습니다. 다만 이 로그 자체가 앞 절에서 다룬 개인정보가 새는 자리이기도 하므로, 보관 기간과 열람 권한을 함께 정해 두는 것이 전제입니다.

빌드업웍스의 경험에서는, 이 세 가지를 착수 전에 정해 둔 프로젝트가 운영 단계에서 훨씬 덜 흔들립니다. 검증과 신고와 기록이 준비되어 있으면 챗봇이 한 번 틀려도 그것을 사고가 아니라 개선 재료로 다룰 수 있기 때문입니다.

한 가지 덧붙이면, 챗봇의 바탕이 되는 모델 자체를 새로 만들거나 학습시키는 일은 이 글의 준비 범위와 다른 영역입니다. 빌드업웍스는 데이터 연동과 권한 반영, 검증 체계를 갖춘 시스템을 구축하며, 모델 개발·학습이나 데이터 사이언스가 필요한 경우에는 해당 분야의 파트너와 연결해 드립니다. 구축 범위는 AI · 앱 개발 서비스에 정리돼 있습니다.

챗봇이 답이 아닌 경우

준비를 마쳤더라도 챗봇이라는 형태 자체가 맞지 않는 자리가 있습니다. 이 구분을 먼저 하면, 준비에 들인 노력이 엉뚱한 그릇에 담기는 일을 피할 수 있습니다.

• 질문이 소수의 정형 조회일 때. 물어보는 것이 몇 가지로 정해져 있고 답이 표의 한 칸에서 나온다면, 대화형 챗봇보다 잘 정리된 검색이나 조회 화면이 더 빠르고 정확합니다.
• 오답이 곧 사고인 업무일 때. 법적 효력이 있는 회신이나 안전 판단처럼 틀린 답을 허용할 수 없는 영역에서는, 챗봇이 최종 답을 내는 구조 자체가 맞지 않습니다. 담당자가 근거를 빨리 찾도록 돕는 보조 도구로 한정하는 편이 낫습니다.
• 자료 대부분이 민감해 통제 비용이 이득을 넘을 때. 넣을 수 있는 자료가 거의 남지 않을 만큼 민감정보가 많다면, 챗봇을 세우고 지키는 비용이 그 챗봇이 답할 수 있는 범위의 값어치를 넘어설 수 있습니다.

착수 전 점검표

지금까지의 다섯 갈래를 질문으로 바꾸면 아래와 같습니다. 각 항목에 문서로 답할 수 있으면 그만큼 준비된 것이고, 감으로만 답할 수 있다면 그 자리가 나중에 막히는 지점입니다.

• 챗봇에 넣을 자료의 범위가 정해져 있고, 그 안에서 넣을 것·가릴 것·뺄 것이 항목 단위로 갈려 있습니까. 최신본과 폐기본이 정리돼 있습니까
• 권한이 다른 사람에게 다른 답이 나가야 하는 자료가 있습니까. 있다면 그 통제가 답을 만든 뒤가 아니라 검색 단계에서 걸리도록 계획돼 있습니까
• 챗봇이 답을 만들 때 묻는 사람의 신원을 함께 받고, 사람이 나가거나 부서를 옮기면 그 변경이 반영됩니까
• 답변·로그·입력 창·전송 구간 각각에서 개인정보가 새지 않도록 처리 기준이 있습니까. 로그의 보관 기간과 열람 권한이 정해져 있습니까
• 데이터의 저장 위치와 리전, 학습 활용 여부를 공식 문서와 계약으로 확인했습니까
• 답이 틀렸을 때 사람이 확인하는 지점, 오답을 신고하는 경로, 되짚을 감사 로그가 정해져 있습니까

이 여섯 질문 중 “아니오”가 많다면, 지금 필요한 것은 더 좋은 모델이 아니라 이 항목들을 먼저 문서로 채우는 일입니다. 특히 검색 단계 권한과 로그 처리 두 가지는 개발이 끝난 뒤에 되돌리기가 가장 어렵기 때문에, 순서상 가장 앞에 두시는 편이 좋습니다.

다음 단계

지금 우리 조직이 이 항목들에서 어디쯤 있는지부터 확인하시는 것이 순서상 먼저입니다. AI 준비도 진단은 데이터·보안·거버넌스 상태를 항목별로 짚어 주고, 보안 진단은 접근 통제가 얼마나 정리돼 있는지를 확인해 줍니다. 두 진단 모두 연락처를 남기지 않아도 결과를 바로 보실 수 있습니다.

준비가 어느 정도 선 상태에서 실제 구축을 검토하신다면 AI · 앱 개발 서비스 범위에서 데이터 연동과 권한 반영이 어디까지 저희 몫인지, 데이터 보호와 접근 통제까지 함께 보시려면 통합 보안 서비스 범위에서 어디부터 별도인지 나눠 적어 둔 부분을 확인하십시오. 구축 규모에 따른 비용 기준은 구축 요금 안내에 정리돼 있습니다. 검색 근거와 원문 각주가 실제로 어떻게 확인되는지 먼저 눌러 보고 싶으시면 아래 데모를 열어 보시고, 우리 자료와 권한 구조에 맞는 준비를 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• Amazon Bedrock — Guardrails
• Amazon Bedrock — Data protection
• Amazon Bedrock — Security, privacy, and responsible AI
• AWS IAM — 보안 모범 사례
• 개인정보보호위원회