기관이나 기업이 외부 LLM을 업무에 쓰려고 승인 절차를 밟는다면, 모델을 어떤 방식으로 쓸지까지 구체적으로 정해 승인해야 합니다. 개인용 채팅 앱, 기업용 워크스페이스, 개발자용 API, 클라우드 관리형 서비스는 같은 이름의 모델을 쓰더라도 데이터를 다루는 조건이 서로 다릅니다.
그래서 외부 LLM 승인 체크리스트에서는 민감한 데이터가 업무 흐름에 들어가기 전에 이 차이부터 분명히 해야 합니다. 검토하는 서비스의 제품 형태, 계정, 엔드포인트(요청을 받는 접속 주소), 켜 둔 기능을 정확히 적고, 서비스 제공사가 통제하는 범위와 기관이 내부 환경에 둘 수 있는 범위를 나눠 둡니다. 특정 회사를 믿을 만한 곳으로 정해 두기보다는, 실제 업무마다 쓸 설정을 하나씩 정해 승인 범위를 좁혀야 합니다.
이렇게 범위를 정해 승인하고 설정이 바뀔 때마다 다시 검토하면, 데이터를 AI-Ready Data(AI 레디 데이터) 상태로 유지하는 데에도 도움이 됩니다. AI-Ready Data는 쓰려는 AI 업무와 모델에 맞게 준비되어 있고, 데이터나 모델이 바뀐 뒤에도 다시 검증할 수 있는 데이터를 말합니다.
이 블로그의 이전 글 직접 만든 AI 에이전트를 기관 DMZ에서 쓰기 전 확인할 기준과 반출할 수 없는 문서로 RAG를 운영할 때 원문이 갈 곳을 정하는 방법은 모두 외부 모델로 요청을 보내는 경로(모델 경로)가 이미 승인되어 있다는 전제에서 출발했습니다. 이번 글에서는 그 경로를 어떤 기준으로 승인하는지 살펴봅니다.
핵심 요약
- 모델 이름과 함께 서비스 형태와 설정까지 정확히 지정해 승인합니다.
- 학습 활용, 보관, 악용 모니터링, 애플리케이션 상태, 파일, 캐시, 도구는 각각 따로 확인합니다.
- 이름 같은 원본 값과 매핑 정보(어떤 값을 어떤 표식으로 바꿨는지 적은 대응표)는 기관 안에 두고, 외부 모델에는 원본 값을 [성명_A] 같은 표식으로 바꾼 작업본만 보내되, 보내기 전에 제대로 바뀌었는지 확인합니다.
- 승인하기 전에 서비스 제공사 쪽에 남는 데이터를 확인하고, 기관 쪽 로그, 재시도와 오류 처리 기록, 결과를 보내는 곳도 함께 봅니다.
- 계정 등급, 엔드포인트, 모델, 기능, 약관, 모니터링 도구, 결과를 보내는 곳 가운데 하나라도 바뀌면 검토를 다시 합니다.
같은 모델 이름이라도 데이터를 다루는 조건은 다릅니다
검토할 때는 어떤 모델을 쓰는지보다 어떤 서비스가 요청을 받는지부터 물어야 합니다. 같은 모델이라도 개인용 채팅 앱인지, 기업용 워크스페이스나 개발자용 API, 클라우드 관리형 서비스인지에 따라 학습 활용, 대화 기록, 파일, 정책 적용, 보관, 삭제 설정이 서로 다를 수 있습니다.
서비스 제공사 문서를 보면 이 차이가 구체적으로 드러납니다. OpenAI의 API 데이터 관리 안내는 악용 모니터링 로그와 애플리케이션 상태를 구분하고, 엔드포인트와 기능별 보관 방식을 따로 적어 두었습니다. Anthropic의 상업용 제품 정책은 Claude for Work와 Anthropic API를 개인용 요금제와 구분합니다. Google의 Gemini API 약관은 유료 서비스와 무료 서비스를 나누고, 제출한 콘텐츠를 서로 다르게 처리한다고 설명합니다.
이 문서들을 살펴보면, 「기본 설정에서는 학습에 쓰지 않는다」는 문장만으로는 승인 근거로 부족하다는 점을 알 수 있습니다. 학습에 쓰지 않더라도, 악용 모니터링이나 제품 운영을 위해, 또는 대화 기록, 파일, 캐시, 도구, 그라운딩(검색 결과로 답의 근거를 보강하는 기능) 같은 기능을 위해 서비스에 데이터가 남을 수 있습니다. 어떤 설정은 계정이나 기능에 따라 달라지고, 어떤 설정은 서비스 제공사의 별도 승인을 받아야 켤 수 있습니다. 켜는 순간 일부 기능을 못 쓰게 되는 설정도 있습니다.
그래서 서비스 제공사가 제시하는 조건을 따지기 전에, 승인할 대상부터 아래와 같이 정확히 적어 둡니다.
- 제품과 서비스 이름
- 조직, 워크스페이스, 테넌트, 클라우드 프로젝트
- 개인용, 비즈니스용, 엔터프라이즈용, 개발자용 가운데 어떤 계정인지
- 결제 상태와 리전
- 모델과 엔드포인트
- 파일, 대화 기록, 캐시, 검색, 그라운딩, 도구, 커넥터, 백그라운드 처리 기능
- 실제로 켜 둔 보관, 삭제, 데이터 미보관(Zero Data Retention, ZDR) 설정
구매 기록이나 서비스 제공사 이름으로는 이 목록을 대신할 수 없습니다. 승인은 요청을 실제로 처리하는 경로와 그 경로에 적용된 설정을 기준으로 내려야 합니다.
LLM Capsule을 쓰면 외부 모델로 보내는 내용이 달라집니다
LLM Capsule은 AI를 위한 컨텍스트 보존 데이터 레이어입니다. 기관 안에 설치해 쓰는 구성에서는 원본 값과 매핑 정보(어떤 값을 어떤 표식으로 바꿨는지 적은 대응표)는 기관 환경 안에 보관하고, 승인한 모델 경로로는 원본 값을 표식으로 바꾼 문서, 즉 작업본을 보냅니다. 답변이 돌아오면 기관 환경 안에서 표식을 원본 값으로 되돌리는데, 이 과정을 복원(Reconstruction)이라고 합니다. 복원한 결과를 어디로 보낼지는 기관이 정하고, 실제로 그곳으로만 전달되는지는 배포 단계에서 기관이 직접 확인합니다.
계약서 두 건의 갱신 조항을 모델로 비교하는 업무를 가정해 보겠습니다. 계약서에 적힌 대표자 성명 같은 원본 값은 기관 안에 남고, 외부 서비스에는 [성명_A]처럼 항목 이름을 담은 표식으로 바꾼 작업본이 전달됩니다. 한 요청 안에서는 같은 값이 늘 같은 표식으로 바뀌기 때문에, 두 계약서에 같은 대표자가 나오면 둘 다 [성명_A]가 되어 작업본만 보고도 같은 사람이라는 것을 알 수 있습니다. 다만 기본 설정에서는 금액과 날짜도 표식으로 바뀌기 때문에, 모델로 조항 문구는 비교할 수 있어도 갱신 금액이나 기간을 계산해 비교할 수는 없습니다. 회사명은 기본 설정에서 바뀌지 않으며, 상대 회사 이름이나 내부 사업 코드, 계약 식별번호까지 바꾸려면 커스텀 필터(기관이 직접 정하는 치환 규칙)에 넣어야 합니다. 답변이 돌아오면 요청한 업무 흐름 안에서 표식을 원본 값으로 복원합니다.
이렇게 하면 모델 경로로 넘어가는 내용은 바뀌지만, 그 경로를 승인받는 절차까지 건너뛸 수 있는 것은 아닙니다. 표식으로 바뀌는 것은 치환 대상인 값뿐이라, 작업본에도 기밀 문장이나 원문의 맥락, 기관이 민감하게 여기는 정보의 조합이 남을 수 있으므로, 이 작업본에도 서비스 제공사의 계약 조건과 기관의 데이터 처리 규정이 그대로 적용됩니다.
배포를 검토할 때는 아래 내용을 짐작하지 말고 직접 확인합니다.
- 원본 기록이 승인된 환경 안에서 먼저 치환 단계를 거치는지
- 밖으로 나가는 요청에 예상한 표식 형태가 담겼는지
- 매핑 정보가 모델 서비스로 복사되지 않는지
- 복원이 승인된 요청자, 범위, 결과를 보내는 곳으로만 제한되는지
- 로그, 추적 기록, 재시도, 오류 처리 과정에서 원본 값이 밖으로 나가는 경로가 다시 생기지 않는지
서비스 제공사 쪽 기록과 기관 쪽 사본은 따로 확인합니다
LLM Capsule은 외부 서비스 제공사의 로그, 대화 기록, 캐시, 정책 검토, 연결된 도구, 삭제 방식을 통제하지 않습니다. 기관 쪽 API 게이트웨이, 대기열, 추적 플랫폼, 고객 지원 도구, 결과를 받는 애플리케이션에 생기는 사본도 마찬가지입니다.
OpenAI의 문서는 기본 악용 모니터링 로그를 최대 30일 보관한다고 명시하고, 기능별로 남는 애플리케이션 상태와, 데이터 미보관을 적용할 수 있는 엔드포인트를 따로 적어 두었습니다. 데이터 미보관과 수정된 악용 모니터링(Modified Abuse Monitoring)을 적용하려면 OpenAI의 사전 승인을 받아야 합니다. Anthropic의 안내는 API 입력과 출력을 보통 30일 안에 삭제한다고 명시하면서, Files API처럼 보관 기간을 이용자가 정하는 서비스, 이용 정책 위반 대응, 법적 요구, 별도 계약 같은 예외도 함께 적어 두었습니다. Google의 문서는 유료 서비스에서도 악용 모니터링을 위해 요청과 응답을 일정 기간 기록한다고 적고, 컨텍스트 캐싱, 그라운딩, Files API 같은 기능마다 남는 상태와 끄는 방법을 따로 정리합니다. 검색 그라운딩처럼 저장을 끌 수 없는 기능도 있습니다.
이 내용은 특정 시점에 특정 서비스를 기준으로 확인한 것이며, 회사나 모델 전체에 그대로 해당하지는 않습니다. 약관과 제품 동작은 바뀔 수 있으므로, 검토 담당자는 출처 주소, 확인한 날짜, 계정 설정, 승인 환경에서 확보한 증거를 함께 보관해야 합니다.
기관 쪽 사본도 같은 수준으로 살펴봅니다. 치환한 요청도 API 게이트웨이, 재시도 대기열, 실패 기록, 분산 추적 기록, 기술 지원을 요청할 때 보내는 자료 묶음에 복제되곤 합니다. 모델 호출 자체는 의도한 경로로 이뤄졌더라도, 복원한 결과가 엉뚱한 티켓이나 문서, 다른 사용자의 세션에 기록되는 경우도 있습니다. 요청 하나를 원본 기록에서 최종 저장 위치까지 추적할 수 있어야 데이터가 어디까지 전달되는지 끝까지 확인했다고 할 수 있습니다.
OpenAI, Anthropic, Google을 서비스 단위로 검토합니다
아래 표는 검토할 때 채우는 양식으로, 서비스 제공사의 순위를 매긴 것은 아닙니다. 검토 중인 제품과 설정에 맞춰 채우고, 보관 기간과 기능 동작, 적용 조건은 바뀔 수 있으니 승인 직전에 관련 정책 문서를 모두 다시 확인합니다.
숫자 하나만 적어 두면 실제로 쓰는 기능 조합에서 무엇이 남는지 판단하기 어려워지기 때문에, 이 표에는 서비스 제공사별 보관 기간 칸을 일부러 두지 않았습니다.
승인 판단에 쓸 근거를 한 묶음으로 준비합니다
시스템을 설계한 담당자는 제안한 업무 흐름을 뒷받침하는 근거를 한 묶음으로 승인 담당자에게 넘길 수 있어야 합니다. 이 묶음에는 원본 기록, 치환한 작업본, 서비스 형태, 결과를 되돌려 받는 방식, 운영 중에 생기는 사본을 확인할 수 있게 담되, 필요 없는 원본 값은 넣지 않습니다. 기관이 보안성검토 같은 절차를 밟을 때도 이 묶음을 서비스 형태와 데이터 경로를 설명하는 자료로 쓸 수 있지만, 통과 여부는 각 기관의 기준에 따라 정해집니다.
최소한 아래 내용은 남겨 둡니다.
- 승인한 제품, 계정, 테넌트나 프로젝트, 결제 상태, 리전, 모델, 엔드포인트
- 켜 둔 기능(파일, 대화 기록, 캐시, 검색, 그라운딩, 도구, 커넥터, 백그라운드 처리)
- 해당 서비스 형태에 현재 적용되는 학습 활용, 피드백, 악용 검토, 보관, 삭제, 데이터 미보관 조건
- 원본 값과 매핑 정보가 빠져 있음을 보여 주는 외부 요청 예시(민감한 값은 지운 것)
- 복원을 허용하는 정책과 매핑 범위
- 결과를 보내는 최종 위치와, 그곳에 허용된 결과만 기록됐다는 증거
- 기관 쪽 로그, 추적 기록, 대기열, 재시도, 오류, 캐시, 지원용 사본 목록
실패 상황도 같은 검토에서 시험합니다. 선택 기능 하나를 끄거나 켜 보고, 그 변화가 승인 기록에 드러나는지 봅니다. 모델 답변에 형식이 바뀐 표식이나 처음 보는 표식이 섞여 돌아왔을 때, 복원 단계에서 원본 값을 추정해 채워 넣지 않는지 확인합니다. 서비스 제공사 오류, 재시도, 결과 기록 거부 같은 상황을 일부러 만들어 보고, 경로마다 실패 표시가 남는지와 그 기록에서 민감한 값이 지워져 있는지도 점검합니다.
애플리케이션 코드는 그대로여도 엔드포인트, 모델 계열, 계정 등급, 캐싱 옵션이 바뀌거나 그라운딩 서비스, 연결 도구, 서비스 약관, 모니터링 플랫폼, 결과를 보내는 곳이 달라지면 처음 승인한 범위도 달라질 수 있으므로, 이런 재검토 조건도 묶음에 함께 적어 둡니다.
업무 하나마다 설정 하나씩 승인합니다
외부 모델 승인은 실제로 시험해 확인할 수 있을 만큼 범위를 좁혀야 합니다. 업무 흐름과 데이터 분류, 요청자를 적고 서비스 형태, 모델 경로, 켜 둔 기능, 복원 범위, 결과를 보내는 곳까지 정한 뒤, 어떤 변화가 생기면 다시 검토할지도 밝혀 둡니다.
이렇게 승인해 두면 서비스 제공사 이름에 기대지 않고도 승인한 외부 모델을 꾸준히 업무에 활용할 수 있습니다. LLM Capsule은 설치형 구성에서 모델 경로로 무엇이 넘어가는지를 다루고, 서비스 제공사 검토는 그 서비스가 무엇을 저장하거나 볼 수 있는지를 다룹니다. 두 가지 확인 결과는 배포 단계에서 모은 증거 묶음 하나에 함께 담습니다.
원본 값이 기관 안에 남는지, 서비스 설정을 정확히 지정했는지, 결과가 승인된 곳으로만 돌아가는지를 모두 확인한 뒤에 그 업무 흐름을 승인합니다.
가지고 계신 업무 문서로 치환과 복원이 어떻게 동작하는지 보고 싶다면 내 데이터로 직접 해보기 페이지에서 요청하세요. 첫 상담 뒤 LLM Capsule을 기관 환경에 배포하고 그 안에서 문서를 넣어 보는 방식이며, 결과 검토까지 보통 2~4주가 걸립니다. LLM Capsule이 기관 환경의 어디에 설치되고 어떤 데이터가 기관 밖으로 나가는지 먼저 짚어 보려면, 같은 페이지에서 아키텍처 리뷰를 고르시면 됩니다.
