규제 산업에서는 보안 수준을 높일수록 AI 도입이 안전하다고 가정하는 경우가 많다. 하지만 보호 범위가 넓어지면 운영 비용과 기술 변화에 대응하는 속도도 달라지기 때문에 보안 요구를 배포 방식 하나로 환원하기 어렵다.
프라이빗 AI의 세 가지 경계
기업용 AI에서 프라이빗은 하나의 설정이 아니다. 보호 대상은 세 가지다. 문서와 질문이 외부로 나가지 않게 하는 데이터 유입, 모델과 운영 정보를 내부에 두는 모델 운영, 임베딩과 벡터DB, 검색 로그를 보호하는 검색, 메모리다.
규제가 세 영역을 모두 내부에 두라고 요구하는 것은 아니다. 데이터 유입은 고객 관리 키를 적용한 SaaS나 고객 클라우드의 단일 테넌트 환경으로 통제한다. 모델까지 내부에서 돌려야 한다면 자체 하드웨어나 고객 계정에 데이터 플레인(모델이 실제로 데이터를 처리하는 인프라 영역)을 둬야 한다. 검색, 메모리는 임베딩 생성 위치, 벡터DB, 검색 로그를 따로 확인해야 실제 데이터 경계를 알 수 있다.
규제도 온프레미스를 유일한 답으로 제시하지 않는다. EU AI Act는 고위험 AI에 문서화, 추적성, 인간의 감독과 증거를 요구한다. DORA는 제3자 계약의 감사권, 보안 요건, 출구전략을 다룬다. 물리적 격리는 규정이나 감사 기준이 명시적으로 요구할 때 선택하면 된다.
다만 그 선택 기준이 되는 데이터 분류는 쉽지 않다. 조직의 55%는 주요 시스템 전체에 자동 분류를 적용하지 못했다. 무엇을 격리할지 증명하기 어려우니 전부 격리하는 RFP(제안요청서)가 나온다. 기술이 문제일까. 정보와 책임이 불명확해서 이런 RFP가 나온다.
5% 때문에 100%를 가둘 것인가
배포 방식은 회사 단위가 아니라 워크로드 단위로 정해진다.
| 방식 | 특징 |
|---|---|
| 에어갭 | 인터넷 경로를 끊어 보안은 강하지만 운영 부담이 크다 |
| 고객 클라우드 단일 테넌트 | 관리가 쉽고 업데이트가 빠르다 |
| 하이브리드 | 요청의 민감도에 따라 두 환경을 함께 쓴다 |
은행 질의 중 미공개 중요정보를 다루는 요청이 5%라면 에어갭도 그 수요에 맞춰 구축할 수 있다. 나머지 95%는 암호화된 환경이나 고객 계정에서 처리한다. 모든 질의를 에어갭에 넣으면 어떨까. 같은 목적에 최대 20배의 설비가 필요하다.
대신 라우팅을 증명해야 한다. 데이터 등급별 처리 환경, 사용자 권한, 분류 실패 시 기본 경계를 표로 만들고 실제 요청이 규칙대로 이동했는지 기록한다. 감사는 GPU의 위치가 아니라 분류와 접근 통제가 제대로 작동했다는 증거를 본다.
같은 논리로 모델도 용도에 맞게 나눈다. 쿠버네티스 클러스터의 평균 GPU 사용률은 5%에 그쳤다. 정형 추출과 분류에는 소형 모델을, 복잡한 추론과 긴 도구 호출에는 프론티어 모델을 쓰면 과잉 설비를 줄인다.
구매가가 정말 총비용일까
RFP 비용표에는 대개 하드웨어, 라이선스, 구축비와 지원료만 들어간다. 모델과 런타임 업데이트, 평가 데이터 관리, 스테이징, 감사 대응에 드는 반복 비용은 자주 빠진다. 19개 구축 사례에서 이를 포함한 온프레미스 TCO(총소유비용)는 제시 가격의 1.8~3.5배였다.
운영은 서버 관리로 끝나지 않는다. 모델 저장, 배포, 모니터링, 업그레이드, 접근 통제, 평가, 장애 대응이 모두 필요하다. 단일 클러스터를 프로덕션 수준으로 유지하는 데도 1.5~2명의 전담 인력이 든다.
게다가 소프트웨어는 더 빨리 변한다. vLLM은 2025년 11월부터 2주 간격으로 새 버전을 내고 있다. CUDA나 PyTorch 요구사항이 바뀔 때마다 성능 평가와 보안 검토를 다시 해야 한다. 에어갭을 택하면 이 부담까지 내부 플랫폼팀이 떠안는다.
3년이 지나면 장비 가치가 떨어지고 모델 성능도 낮아진다. 문서 분류는 구형 모델로 버틸 수 있지만 장기 에이전트 작업은 업데이트 지연에 민감하다. 온프레미스 비용이 구매가뿐일까. 인력, 업데이트 속도, 장비의 잔존가치까지 합친 값이다.
가장 민감한 1건이 전체를 결정해야 하나
가장 민감한 데이터 하나를 회사 전체의 기준으로 삼으면 어떻게 될까. 결론은 100% 에어갭이다. 워크로드별로 판단하면 외부 반출이 금지된 데이터와 질의만 분리할 수 있다. 근거는 업계 관행이나 경쟁사의 사례가 아니라, 해당 업무의 반출을 금지한 규정 문장이어야 한다.
계약에서 배포까지
벤더 심사에서는 그 경계가 실제로 지켜지는지, 임베딩 생성 위치와 벡터DB의 소유 환경부터 확인한다. 검색 로그의 보관 기간과 접근자, 질의와 검색 결과의 학습 사용 여부도 계약 전에 정한다. 운영 책임은 고객, 벤더, 공동 책임 중 하나로 명시한다. ‘관리형 서비스’라는 말만으로는 장애나 감사 때 담당 조직을 가릴 수 없다.
계약에는 가동률뿐 아니라 모델 품질 저하 SLA도 넣는다. 데이터 반출과 삭제 검증, 평가 데이터 이전, 장애 대응 절차까지 출구계획에 포함한다. 도입 초기 90일에는 실제 질의 50~500건으로 평가셋을 만들고, 부하 시험 뒤 사용자를 5%, 25%, 50%, 100% 순으로 늘리며 품질과 응답 시간을 함께 기록한다.
새 모델을 들일 때마다 평가와 보안 검토, 카나리 배포(신버전을 소수 사용자에게 먼저 내보내 검증하는 배포 방식)를 반복할 수 있어야 한다. 업데이트가 매번 별도 프로젝트가 되면 모델은 금세 뒤처진다. 기업의 퍼블릭 클라우드 추론 비중은 56%에서 41%로 줄었고, 56%는 프라이빗 클라우드를 사용 중이거나 도입할 계획이라고 답했다. 기업이 원하는 것도 무조건적인 단절이 아니라 데이터 위치와 운영 책임을 직접 통제하는 환경이다.
결국 필요한 문서는 데이터 등급별 라우팅 표와 각 환경의 근거가 되는 규정 인용문이다. 이 둘이 있으면 민감한 5%만 에어갭에 두고 나머지는 빠르게 업데이트할 수 있다. 근거 없이 100% 에어갭을 택하면 데이터 분류를 끝내지 못한 비용을 하드웨어 구매로 떠넘기게 된다.
보안 결정이 오래 유지되는지는 처음 선택한 배포 방식보다 이후의 변경을 얼마나 일관되게 설명하는지에 달려 있다. 규정과 모델이 달라져도 판단 근거가 남아 있으면 인프라는 고정된 설비가 아니라 조정 가능한 운영 조건이 된다.