사내 문서를 읽고 답하는 AI 챗봇을 만들 때, 모델부터 고르면 중요한 설계가 뒤로 밀린다. 누가 어떤 문서를 조회하는지, 질문과 답변이 어디에 저장되는지, 모델 장애 때 업무를 어떻게 이어가는지가 먼저 정해져야 한다. 사내 생성형 AI 서비스는 모델에 인증·검색·데이터 저장·운영 통제를 결합한 업무 시스템이다.
‘사내 서비스’가 반드시 ‘사내 GPU 서버’를 뜻하지는 않는다. 외부 모델 API를 이용하면서 내부 인증과 데이터 접근을 통제할 수도 있고, 모델까지 직접 운영할 수도 있다. 구축 방식은 데이터가 이동할 수 있는 범위와 운영 역량을 기준으로 선택해야 한다.
모델 운영 방식과 데이터 경계를 먼저 정한다
기본 선택지는 관리형 모델 API, 직접 호스팅, 두 방식을 조합한 구성이다. 아래 표는 특정 제품의 기능 비교가 아니라 설계 시 확인할 항목을 정리한 것이다.
| 방식 | 기업이 준비할 주요 인프라 | 도입 전에 확인할 조건 |
|---|---|---|
| 관리형 모델 API | 사내 앱, 인증, 검색·저장소, API 연결과 사용량 통제 | 전송 데이터 범위, 처리 위치, 보존·학습 이용 조건, 호출 한도 |
| 직접 호스팅 | 위 구성에 모델 추론 서버, 가속기·메모리, 배포·확장 체계 추가 | 모델 라이선스, 성능, 패치, 장애 대응과 운영 인력 |
| 혼합 구성 | 데이터 분류에 따른 모델 연결 정책과 공통 통제 | 모델별 전송 허용 범위, 장애 시 대체 경로의 적합성 |
관리형 API를 쓰면 모델을 실행하는 장비를 직접 운영하는 부담을 줄일 수 있지만, 데이터 처리 조건은 별도로 확인해야 한다. 직접 호스팅도 자동으로 안전해지는 것은 아니다. 저장소 권한, 관리자 접근, 외부 연결과 취약점 관리는 여전히 기업의 책임이다.
실무적으로는 ‘외부 전송 금지’, ‘조건부 전송 가능’, ‘일반 업무 자료’처럼 처리 기준을 먼저 정하는 편이 좋다. 장애가 났다는 이유로 전송 금지 자료를 외부 모델에 보내는 대체 경로를 만들면 처음 정한 경계가 무너진다.
서비스는 요청 경로와 문서 적재 경로를 나눠 설계한다
사내 문서 질의응답을 위한 일반적인 요청 경로는 다음과 같다.
- 사용자가 사내 계정으로 로그인하고 질문을 입력한다.
- 애플리케이션이 사용자와 요청 권한을 확인한다.
- 검색 계층이 해당 사용자가 읽을 수 있는 문서 조각을 찾는다.
- 애플리케이션이 질문과 허용된 자료를 모델에 전달한다.
- 응답을 검사한 뒤 근거 문서와 함께 사용자에게 반환한다.
검색으로 찾은 자료를 모델 입력에 붙이는 방식을 RAG, 즉 검색 증강 생성이라고 한다. 검색에는 키워드 검색이나 벡터 검색을 사용할 수 있다. 벡터 검색은 텍스트의 의미를 숫자 표현으로 바꾸는 임베딩을 활용하며, 모든 서비스에 별도 벡터 데이터베이스가 필요한 것은 아니다.
문서 적재는 이 요청 경로와 구분한다. 원본 문서를 수집하고, 텍스트를 추출하고, 조각으로 나눈 뒤 검색 인덱스에 넣는다. 이때 문서 식별자, 버전, 출처, 접근권한을 함께 관리해야 갱신과 삭제를 추적할 수 있다. 사용자 업로드 파일이 있다면 파일 형식·크기 제한과 악성 파일 검사도 별도 경로에 둔다.
Microsoft의 기업용 채팅 참조 아키텍처도 UI, 지식 저장소, 모델, 요청 처리 계층을 구분하고 사설 연결과 서비스 간 인증을 결합한다. 이를 특정 클라우드의 필수 부품 목록으로 보기보다, 구성 요소별 책임을 나누는 참고 구조로 활용할 수 있다.
로그인 권한과 문서 열람 권한은 다르다
SSO로 회사 계정의 로그인 여부를 확인해도 모든 사내 문서에 접근할 수 있는 것은 아니다. 일반 직원이 인사 문서를 읽지 못한다면 AI 검색에서도 같은 제한이 적용되어야 한다. 권한 없는 문서는 모델에 전달하기 전에 제외해야 한다. 답변에 표시하지 말라는 지시만으로는 접근 통제가 되지 않는다.
Azure AI Search의 보안 필터 문서는 사용자·그룹 식별자를 이용해 검색 결과를 제한하는 패턴을 설명한다. 이 패턴의 식별자는 필터에 쓰이는 문자열이므로, 애플리케이션이 인증된 사용자 정보를 바탕으로 필터를 구성하고 모든 검색 요청에 적용해야 한다.
예를 들어 부서별 문서를 하나의 인덱스에 모으는 설계를 택했다면, 문서 조각에도 원본의 접근권한을 연결해야 한다. 클라이언트가 임의로 보낸 부서명이나 그룹 목록을 신뢰해서는 안 된다. 권한 정보가 없거나 확인에 실패하면 해당 자료를 제외하는 처리도 필요하다.
운영 중에는 인사 이동과 권한 회수의 반영이 중요하다. 원본에서 삭제된 문서가 검색 인덱스, 응답 캐시, 과거 대화에 남을 수 있기 때문이다. 권한 변경 시 인덱스와 캐시를 언제 갱신할지, 과거 대화를 다시 열 때 어떤 권한을 확인할지 정해야 한다. 캐시 공유 범위에도 사용자와 권한 조건을 반영한다.
네트워크 보안과 AI 입력 통제를 함께 둔다
인터넷에 노출되는 진입점, 애플리케이션, 검색·저장소, 모델 연결, 관리 구간을 구분하고 필요한 통신만 허용한다. 외부 API를 사용한다면 목적지와 전송 가능한 데이터 범위를 제한하고, API 키는 사용자 브라우저가 아니라 서버의 비밀정보 관리 체계에서 다룬다. 개발·운영 환경과 서비스 계정의 권한도 분리한다.
사설 연결은 네트워크 노출을 줄이지만, 문서 접근권한이나 입력 내용까지 검사하지 않는다. WAF 역시 일반적인 웹 공격 대응과 별개로 AI가 해석하는 지시의 위험을 완전히 해결하지는 못한다.
OWASP는 프롬프트 인젝션이 사용자 입력뿐 아니라 외부 파일이나 웹페이지를 통해서도 발생하며, RAG만으로 제거되지 않는다고 설명한다. 따라서 검색 문서는 참조 데이터로 취급하고 시스템 지시와 구분해야 한다. 입력·출력 검사도 필요하지만 이를 완전한 방어로 가정해서는 안 된다.
업무 도구를 연결하면 피해 범위도 커진다. 조회 서비스와 메일 발송·문서 수정·결재 실행 기능은 권한을 나누고, 도구 호출 때 서버가 다시 사용자 권한과 인자를 검증하도록 설계한다. 영향이 큰 작업에는 사용자 확인 단계를 둔다. 모델이 제안한 작업이라는 이유로 실행 권한을 부여하지 않는다.
용량 산정은 동시 요청과 토큰 길이로 검증한다
직원 수만으로 GPU 수량이나 API 용량을 정하기 어렵다. 같은 인원이라도 짧은 질문을 가끔 보내는 서비스와 긴 문서를 동시에 요약하는 서비스는 부하가 다르다. 직접 호스팅에서는 모델 크기와 정밀도뿐 아니라 동시 요청 처리에 필요한 메모리까지 고려해야 한다.
시험에는 짧은 질의, 긴 문서 요약, 검색을 거치는 요청을 포함한다. 동시 요청을 늘리면서 첫 응답이 나오기까지의 시간, 전체 응답 시간, 처리량과 실패율을 측정한다. 검색·임베딩·추론을 나눠 측정해야 병목이 있는 계층을 찾을 수 있다. AWS의 모델 엔드포인트 부하 시험 지침도 평균 부하와 극단적인 부하에서 성능 기준을 확보하도록 권고한다.
비용 검토에는 모델 호출료나 GPU 외에 검색 인덱스, 문서 처리, 저장소, 로그, 네트워크와 운영 인력을 포함한다. 사용자별 요청 한도, 입력·출력 길이 제한, 대량 작업의 대기열을 두면 특정 작업이 전체 서비스를 점유하는 상황을 줄일 수 있다. 구체적인 한도는 업무 시험 결과로 정한다.
로그·복구·품질 평가까지 운영 범위에 포함한다
AWS의 모델 지표 모니터링 지침은 호출 수, 지연, 토큰 사용량, 오류와 호출 제한 등을 관찰하도록 안내한다. 사내 서비스에서는 여기에 문서 검색 실패, 권한 거부, 근거 없는 응답, 문서 갱신 지연을 함께 확인하는 구성이 유용하다.
로그에 질문·문서 원문·답변을 모두 남기면 새로운 민감정보 저장소가 생긴다. 요청 식별자, 처리 시간, 모델·프롬프트 버전, 참조 문서 식별자를 중심으로 기록하고 원문 기록은 목적에 따라 최소화한다. 저장한 대화와 로그에도 접근권한, 보존기간, 삭제 절차를 적용해야 한다.
복구 계획은 모델 서버 재시작만으로 끝나지 않는다. 원본 문서, 권한 정보, 인덱스 재생성 절차, 서비스 설정을 함께 복구할 수 있어야 한다. 검색이 실패하면 사내 규정에 대한 답변을 중단하거나 검색 불가를 명확히 표시하는 정책도 정한다. 근거 없이 만들어 낸 답변이 업무 지침으로 사용되지 않도록 하기 위해서다.
운영 전 검증에는 다른 부서 문서 접근 시도, 권한 회수 뒤 재조회, 악성 지시가 포함된 문서, 모델 시간 초과, 복구 후 권한 일치 여부를 포함한다. 모델이나 프롬프트를 바꿀 때는 기존 평가 질문으로 품질과 권한 통제를 다시 확인한다.
구축 완료의 기준은 안전하게 운영할 수 있는 상태다
첫 적용 범위는 읽기 중심의 제한된 업무로 정하고, 문서 소유자와 운영 담당자를 명확히 두는 편이 현실적이다. 본문에서 제시한 구성은 설계 기준이며, 모든 기업이 같은 장비나 제품을 도입해야 한다는 뜻은 아니다.
시연에서 답변이 잘 나오는지만 확인해서는 부족하다. 서비스 오픈 전에는 권한 없는 문서가 모델 입력에 들어가지 않는지, 외부 연결이 허용 범위를 지키는지, 장애·권한 변경·데이터 삭제를 담당자가 처리할 수 있는지 확인해야 한다. 이 조건을 충족하는 범위에서 사용자를 확대해야 사내 생성형 AI가 지속 가능한 업무 서비스가 된다.